[PATCH v1 4/6] vmbus: Switch to use new generic UUID API

[Andy Shevchenko]

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: de...@linuxdriverproject.org
Signed-off-by: Andy Shevchenko 
---
 drivers/hv/channel.c|  4 +-
 drivers/hv/channel_mgmt.c   | 18 
 drivers/hv/hyperv_vmbus.h   |  4 +-
 drivers/hv/vmbus_drv.c  | 43 ++
 include/linux/hyperv.h  | 98 -
 include/linux/mod_devicetable.h |  2 +-
 include/uapi/linux/hyperv.h |  6 +--
 7 files changed, 79 insertions(+), 96 deletions(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index e9bf0bb87ac4..ecc11df389e1 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -225,8 +225,8 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 
send_ringbuffer_size,
 EXPORT_SYMBOL_GPL(vmbus_open);
 
 /* Used for Hyper-V Socket: a guest client's connect() to the host */
-int vmbus_send_tl_connect_request(const uuid_le *shv_guest_servie_id,
- const uuid_le *shv_host_servie_id)
+int vmbus_send_tl_connect_request(const guid_t *shv_guest_servie_id,
+ const guid_t *shv_host_servie_id)
 {
struct vmbus_channel_tl_connect_request conn_msg;
 
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 4bbb8dea4727..28550e1e2cec 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -141,7 +141,7 @@ static const struct vmbus_device vmbus_devs[] = {
 };
 
 static const struct {
-   uuid_le guid;
+   guid_t guid;
 } vmbus_unsupported_devs[] = {
{ HV_AVMA1_GUID },
{ HV_AVMA2_GUID },
@@ -171,26 +171,26 @@ static void vmbus_rescind_cleanup(struct vmbus_channel 
*channel)
spin_unlock_irqrestore(&vmbus_connection.channelmsg_lock, flags);
 }
 
-static bool is_unsupported_vmbus_devs(const uuid_le *guid)
+static bool is_unsupported_vmbus_devs(const guid_t *guid)
 {
int i;
 
for (i = 0; i < ARRAY_SIZE(vmbus_unsupported_devs); i++)
-   if (!uuid_le_cmp(*guid, vmbus_unsupported_devs[i].guid))
+   if (guid_equal(guid, &vmbus_unsupported_devs[i].guid))
return true;
return false;
 }
 
 static u16 hv_get_dev_type(const struct vmbus_channel *channel)
 {
-   const uuid_le *guid = &channel->offermsg.offer.if_type;
+   const guid_t *guid = &channel->offermsg.offer.if_type;
u16 i;
 
if (is_hvsock_channel(channel) || is_unsupported_vmbus_devs(guid))
return HV_UNKNOWN;
 
for (i = HV_IDE; i < HV_UNKNOWN; i++) {
-   if (!uuid_le_cmp(*guid, vmbus_devs[i].guid))
+   if (guid_equal(guid, &vmbus_devs[i].guid))
return i;
}
pr_info("Unknown GUID: %pUl\n", guid);
@@ -452,10 +452,10 @@ static void vmbus_process_offer(struct vmbus_channel 
*newchannel)
mutex_lock(&vmbus_connection.channel_mutex);
 
list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
-   if (!uuid_le_cmp(channel->offermsg.offer.if_type,
-   newchannel->offermsg.offer.if_type) &&
-   !uuid_le_cmp(channel->offermsg.offer.if_instance,
-   newchannel->offermsg.offer.if_instance)) {
+   if (guid_equal(&channel->offermsg.offer.if_type,
+   &newchannel->offermsg.offer.if_type) &&
+   guid_equal(&channel->offermsg.offer.if_instance,
+   &newchannel->offermsg.offer.if_instance)) {
fnew = false;
break;
}
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 1b6a5e0dfa75..e32a816a55d1 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -378,8 +378,8 @@ extern const struct vmbus_channel_message_table_entry
 
 /* General vmbus interface */
 
-struct hv_device *vmbus_device_create(const uuid_le *type,
- const uuid_le *instance,
+struct hv_device *vmbus_device_create(const guid_t *type,
+ const guid_t *instance,
  struct vmbus_channel *channel);
 
 int vmbus_device_register(struct hv_device *child_device_obj);
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index ed84e96715a0..04e3acddebd4 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -535,21 +535,12 @@ static int vmbus_uevent(struct device *device, struct 
kobj_uevent_env *env)
return ret;
 }
 
-static const uuid_le null_guid;
-
-static inline bool is_null_guid(const uuid_le *guid)
-{
-   if (uuid_le_cmp(*guid, null_guid))
-   return false;
-   return true;
-}
-
 /*
  * Return a matching hv_vmbus_device_i

[PATCH v1 6/6] device property: Switch to use new generic UUID API

[Andy Shevchenko]

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Cc: "Rafael J. Wysocki" 
Cc: Mika Westerberg 
Cc: linux-a...@vger.kernel.org
Signed-off-by: Andy Shevchenko 
---
 drivers/acpi/property.c | 50 -
 1 file changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
index 917c789f953d..a7fdbe083a7e 100644
--- a/drivers/acpi/property.c
+++ b/drivers/acpi/property.c
@@ -24,16 +24,14 @@ static int acpi_data_get_property_array(struct 
acpi_device_data *data,
acpi_object_type type,
const union acpi_object **obj);
 
-/* ACPI _DSD device properties UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
-static const u8 prp_uuid[16] = {
-   0x14, 0xd8, 0xff, 0xda, 0xba, 0x6e, 0x8c, 0x4d,
-   0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01
-};
-/* ACPI _DSD data subnodes UUID: dbb8e3e6-5886-4ba6-8795-1319f52a966b */
-static const u8 ads_uuid[16] = {
-   0xe6, 0xe3, 0xb8, 0xdb, 0x86, 0x58, 0xa6, 0x4b,
-   0x87, 0x95, 0x13, 0x19, 0xf5, 0x2a, 0x96, 0x6b
-};
+/* ACPI _DSD device properties GUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301 */
+static const guid_t prp_guid =
+   GUID_INIT(0xdaffd814, 0x6eba, 0x4d8c,
+ 0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01);
+/* ACPI _DSD data subnodes GUID: dbb8e3e6-5886-4ba6-8795-1319f52a966b */
+static const guid_t ads_guid =
+   GUID_INIT(0xdbb8e3e6, 0x5886, 0x4ba6,
+ 0x87, 0x95, 0x13, 0x19, 0xf5, 0x2a, 0x96, 0x6b);
 
 static bool acpi_enumerate_nondev_subnodes(acpi_handle scope,
   const union acpi_object *desc,
@@ -190,22 +188,23 @@ static bool acpi_enumerate_nondev_subnodes(acpi_handle 
scope,
 {
int i;
 
-   /* Look for the ACPI data subnodes UUID. */
+   /* Look for the ACPI data subnodes GUID. */
for (i = 0; i < desc->package.count; i += 2) {
-   const union acpi_object *uuid, *links;
+   const union acpi_object *guid, *links;
 
-   uuid = &desc->package.elements[i];
+   guid = &desc->package.elements[i];
links = &desc->package.elements[i + 1];
 
/*
-* The first element must be a UUID and the second one must be
+* The first element must be a GUID and the second one must be
 * a package.
 */
-   if (uuid->type != ACPI_TYPE_BUFFER || uuid->buffer.length != 16
-   || links->type != ACPI_TYPE_PACKAGE)
+   if (guid->type != ACPI_TYPE_BUFFER ||
+   guid->buffer.length != 16 ||
+   links->type != ACPI_TYPE_PACKAGE)
break;
 
-   if (memcmp(uuid->buffer.pointer, ads_uuid, sizeof(ads_uuid)))
+   if (!guid_equal((guid_t *)guid->buffer.pointer, &ads_guid))
continue;
 
return acpi_add_nondev_subnodes(scope, links, &data->subnodes,
@@ -298,26 +297,27 @@ static bool acpi_extract_properties(const union 
acpi_object *desc,
if (desc->package.count % 2)
return false;
 
-   /* Look for the device properties UUID. */
+   /* Look for the device properties GUID. */
for (i = 0; i < desc->package.count; i += 2) {
-   const union acpi_object *uuid, *properties;
+   const union acpi_object *guid, *properties;
 
-   uuid = &desc->package.elements[i];
+   guid = &desc->package.elements[i];
properties = &desc->package.elements[i + 1];
 
/*
-* The first element must be a UUID and the second one must be
+* The first element must be a GUID and the second one must be
 * a package.
 */
-   if (uuid->type != ACPI_TYPE_BUFFER || uuid->buffer.length != 16
-   || properties->type != ACPI_TYPE_PACKAGE)
+   if (guid->type != ACPI_TYPE_BUFFER ||
+   guid->buffer.length != 16 ||
+   properties->type != ACPI_TYPE_PACKAGE)
break;
 
-   if (memcmp(uuid->buffer.pointer, prp_uuid, sizeof(prp_uuid)))
+   if (!guid_equal((guid_t *)guid->buffer.pointer, &prp_guid))
continue;
 
/*
-* We found the matching UUID. Now validate the format of the
+* We found the matching GUID. Now validate the format of the
 * package immediately following it.
 */
if (!acpi_properties_format_valid(properties))
-- 
2.11.0

[PATCH v1 1/6] efi: Switch to use new generic UUID API

[Andy Shevchenko]

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Signed-off-by: Andy Shevchenko 
---
 drivers/firmware/efi/cper.c | 10 ++---
 include/linux/cper.h| 94 ++---
 include/linux/efi.h |  4 +-
 3 files changed, 54 insertions(+), 54 deletions(-)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 48a8f69da42a..684e65c11dde 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -534,7 +534,7 @@ static void
 cper_estatus_print_section(const char *pfx, struct acpi_hest_generic_data 
*gdata,
   int sec_no)
 {
-   uuid_le *sec_type = (uuid_le *)gdata->section_type;
+   guid_t *sec_type = (guid_t *)gdata->section_type;
__u16 severity;
char newpfx[64];
 
@@ -545,12 +545,12 @@ cper_estatus_print_section(const char *pfx, struct 
acpi_hest_generic_data *gdata
printk("%s""Error %d, type: %s\n", pfx, sec_no,
   cper_severity_str(severity));
if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
-   printk("%s""fru_id: %pUl\n", pfx, (uuid_le *)gdata->fru_id);
+   printk("%s""fru_id: %pUl\n", pfx, gdata->fru_id);
if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
printk("%s""fru_text: %.20s\n", pfx, gdata->fru_text);
 
snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
-   if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_GENERIC)) {
+   if (guid_equal(sec_type, &CPER_SEC_PROC_GENERIC)) {
struct cper_sec_proc_generic *proc_err = 
acpi_hest_get_payload(gdata);
 
printk("%s""section_type: general processor error\n", newpfx);
@@ -558,7 +558,7 @@ cper_estatus_print_section(const char *pfx, struct 
acpi_hest_generic_data *gdata
cper_print_proc_generic(newpfx, proc_err);
else
goto err_section_too_small;
-   } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PLATFORM_MEM)) {
+   } else if (guid_equal(sec_type, &CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata);
 
printk("%s""section_type: memory error\n", newpfx);
@@ -568,7 +568,7 @@ cper_estatus_print_section(const char *pfx, struct 
acpi_hest_generic_data *gdata
   gdata->error_data_length);
else
goto err_section_too_small;
-   } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PCIE)) {
+   } else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie = acpi_hest_get_payload(gdata);
 
printk("%s""section_type: PCIe error\n", newpfx);
diff --git a/include/linux/cper.h b/include/linux/cper.h
index 4c671fc2081e..723e952fde0d 100644
--- a/include/linux/cper.h
+++ b/include/linux/cper.h
@@ -74,36 +74,36 @@ enum {
  * Corrected Machine Check
  */
 #define CPER_NOTIFY_CMC
\
-   UUID_LE(0x2DCE8BB1, 0xBDD7, 0x450e, 0xB9, 0xAD, 0x9C, 0xF4, \
-   0xEB, 0xD4, 0xF8, 0x90)
+   GUID_INIT(0x2DCE8BB1, 0xBDD7, 0x450e, 0xB9, 0xAD, 0x9C, 0xF4,   \
+ 0xEB, 0xD4, 0xF8, 0x90)
 /* Corrected Platform Error */
 #define CPER_NOTIFY_CPE
\
-   UUID_LE(0x4E292F96, 0xD843, 0x4a55, 0xA8, 0xC2, 0xD4, 0x81, \
-   0xF2, 0x7E, 0xBE, 0xEE)
+   GUID_INIT(0x4E292F96, 0xD843, 0x4a55, 0xA8, 0xC2, 0xD4, 0x81,   \
+ 0xF2, 0x7E, 0xBE, 0xEE)
 /* Machine Check Exception */
 #define CPER_NOTIFY_MCE
\
-   UUID_LE(0xE8F56FFE, 0x919C, 0x4cc5, 0xBA, 0x88, 0x65, 0xAB, \
-   0xE1, 0x49, 0x13, 0xBB)
+   GUID_INIT(0xE8F56FFE, 0x919C, 0x4cc5, 0xBA, 0x88, 0x65, 0xAB,   \
+ 0xE1, 0x49, 0x13, 0xBB)
 /* PCI Express Error */
 #define CPER_NOTIFY_PCIE   \
-   UUID_LE(0xCF93C01F, 0x1A16, 0x4dfc, 0xB8, 0xBC, 0x9C, 0x4D, \
-   0xAF, 0x67, 0xC1, 0x04)
+   GUID_INIT(0xCF93C01F, 0x1A16, 0x4dfc, 0xB8, 0xBC, 0x9C, 0x4D,   \
+ 0xAF, 0x67, 0xC1, 0x04)
 /* INIT Record (for IPF) */
 #define CPER_NOTIFY_INIT   \
-   UUID_LE(0xCC5263E8, 0x9308, 0x454a, 0x89, 0xD0, 0x34, 0x0B, \
-   0xD3, 0x9B, 0xC9, 0x8E)
+   GUID_INIT(0xCC5263E8, 0x9308, 0x454a, 0x89, 0xD0, 0x34, 0x0B,   \
+ 0xD3, 0x9B, 0xC9, 0x8E)
 /* Non-Maskable Interrupt */
 #define CPER_NOTIFY_NMI
\
-   UUID_LE(0x5BAD89FF, 0xB7E6, 0x42c9, 0x81, 0x4A, 0xCF, 0x24, \
-   0x85, 0xD6, 0xE9, 0x8A)
+   GUID

[PATCH v1 5/6] uuid: Kill uapi/uuid.h

[Andy Shevchenko]

There is no more users for uapi/uuid.h. Remove it for good.

Anyone needs it in user space better to use libuuid.

Signed-off-by: Andy Shevchenko 
---
 include/linux/uuid.h  | 20 +++-
 include/uapi/linux/uuid.h | 42 --
 scripts/mod/file2alias.c  |  4 ++--
 3 files changed, 21 insertions(+), 45 deletions(-)
 delete mode 100644 include/uapi/linux/uuid.h

diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index 2251e1925ea4..3bc3e88c9fbd 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid.h
@@ -16,7 +16,19 @@
 #ifndef _LINUX_UUID_H_
 #define _LINUX_UUID_H_
 
-#include 
+#include 
+#include 
+
+typedef struct {
+   __u8 b[16];
+} guid_t;
+
+#define GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) 
\
+((guid_t)  \
+{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
+   (b) & 0xff, ((b) >> 8) & 0xff,  \
+   (c) & 0xff, ((c) >> 8) & 0xff,  \
+   (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
 
 #define UUID_SIZE 16
 
@@ -84,12 +96,18 @@ int guid_parse(const char *uuid, guid_t *u);
 int uuid_parse(const char *uuid, uuid_t *u);
 
 /* backwards compatibility, don't use in new code */
+typedef guid_t uuid_le;
 typedef uuid_t uuid_be;
 #define UUID_BE(a, _b, c, d0, d1, d2, d3, d4, d5, d6, d7) \
UUID_INIT(a, _b, c, d0, d1, d2, d3, d4, d5, d6, d7)
+#define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)   \
+   GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)
 #define NULL_UUID_BE   \
UUID_BE(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, \
 0x00, 0x00, 0x00, 0x00)
+#define NULL_UUID_LE   \
+   UUID_LE(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, \
+0x00, 0x00, 0x00, 0x00)
 
 #define uuid_le_gen(u) guid_gen(u)
 #define uuid_be_gen(u) uuid_gen(u)
diff --git a/include/uapi/linux/uuid.h b/include/uapi/linux/uuid.h
deleted file mode 100644
index 8ef82f433877..
--- a/include/uapi/linux/uuid.h
+++ /dev/null
@@ -1,42 +0,0 @@
-/*
- * UUID/GUID definition
- *
- * Copyright (C) 2010, Intel Corp.
- * Huang Ying 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License version
- * 2 as published by the Free Software Foundation;
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#ifndef _UAPI_LINUX_UUID_H_
-#define _UAPI_LINUX_UUID_H_
-
-#include 
-#include 
-
-typedef struct {
-   __u8 b[16];
-} guid_t;
-
-#define GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7) 
\
-((guid_t)  \
-{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
-   (b) & 0xff, ((b) >> 8) & 0xff,  \
-   (c) & 0xff, ((c) >> 8) & 0xff,  \
-   (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
-
-/* backwards compatibility, don't use in new code */
-typedef guid_t uuid_le;
-#define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)   \
-   GUID_INIT(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)
-#define NULL_UUID_LE   \
-   UUID_LE(0x, 0x, 0x, 0x00, 0x00, 0x00, 0x00, \
-0x00, 0x00, 0x00, 0x00)
-
-#endif /* _UAPI_LINUX_UUID_H_ */
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 29d6699d5a06..1c68709123aa 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -36,7 +36,7 @@ typedef uint16_t  __u16;
 typedef unsigned char  __u8;
 typedef struct {
__u8 b[16];
-} uuid_le;
+} guid_t;
 
 /* Big exception to the "don't include kernel headers into userspace, which
  * even potentially has different endianness and word sizes, since
@@ -134,7 +134,7 @@ static inline void add_wildcard(char *str)
strcat(str + len, "*");
 }
 
-static inline void add_uuid(char *str, uuid_le uuid)
+static inline void add_uuid(char *str, guid_t uuid)
 {
int len = strlen(str);
 
-- 
2.11.0

[PATCH v1 2/6] mei: Switch to use new generic UUID API

[Andy Shevchenko]

There are new types and helpers that are supposed to be used in new code.

As a preparation to get rid of legacy types and API functions do
the conversion here.

Cc: Tomas Winkler 
Cc: Guenter Roeck 
Cc: Samuel Ortiz 
Signed-off-by: Andy Shevchenko 
---
 drivers/misc/mei/bus-fixup.c| 35 +++
 drivers/misc/mei/bus.c  | 14 +++---
 drivers/misc/mei/client.c   | 21 ++---
 drivers/misc/mei/client.h   | 12 ++--
 drivers/misc/mei/hbm.c  |  2 +-
 drivers/misc/mei/hw.h   |  2 +-
 drivers/misc/mei/main.c |  2 +-
 drivers/nfc/mei_phy.h   |  5 +++--
 drivers/watchdog/mei_wdt.c  |  5 +++--
 include/linux/mei_cl_bus.h  |  2 +-
 include/linux/mod_devicetable.h |  6 +++---
 include/uapi/linux/mei.h|  4 +---
 samples/mei/mei-amt-version.c   | 21 +
 13 files changed, 73 insertions(+), 58 deletions(-)

diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 0208c4b027c5..9eaac4f2d427 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -27,21 +27,27 @@
 #include "mei_dev.h"
 #include "client.h"
 
-#define MEI_UUID_NFC_INFO UUID_LE(0xd2de1625, 0x382d, 0x417d, \
-   0x48, 0xa4, 0xef, 0xab, 0xba, 0x8a, 0x12, 0x06)
+#define MEI_UUID_NFC_INFO  \
+   GUID_INIT(0xd2de1625, 0x382d, 0x417d,   \
+ 0x48, 0xa4, 0xef, 0xab, 0xba, 0x8a, 0x12, 0x06)
 
-static const uuid_le mei_nfc_info_guid = MEI_UUID_NFC_INFO;
+static const guid_t mei_nfc_info_guid = MEI_UUID_NFC_INFO;
 
-#define MEI_UUID_NFC_HCI UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
-   0x94, 0xd4, 0x50, 0x26, 0x67, 0x23, 0x77, 0x5c)
+#define MEI_UUID_NFC_HCI   \
+   GUID_INIT(0x0bb17a78, 0x2a8e, 0x4c50,   \
+ 0x94, 0xd4, 0x50, 0x26, 0x67, 0x23, 0x77, 0x5c)
 
-#define MEI_UUID_WD UUID_LE(0x05B79A6F, 0x4628, 0x4D7F, \
-   0x89, 0x9D, 0xA9, 0x15, 0x14, 0xCB, 0x32, 0xAB)
+#define MEI_UUID_WD\
+   GUID_INIT(0x05B79A6F, 0x4628, 0x4D7F,   \
+ 0x89, 0x9D, 0xA9, 0x15, 0x14, 0xCB, 0x32, 0xAB)
 
-#define MEI_UUID_MKHIF_FIX UUID_LE(0x55213584, 0x9a29, 0x4916, \
-   0xba, 0xdf, 0xf, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
+#define MEI_UUID_MKHIF_FIX \
+   GUID_INIT(0x55213584, 0x9a29, 0x4916,   \
+ 0xba, 0xdf, 0x0f, 0xb7, 0xed, 0x68, 0x2a, 0xeb)
 
-#define MEI_UUID_ANY NULL_UUID_LE
+#define MEI_UUID_ANY   \
+   GUID_INIT(0x, 0x, 0x,   \
+ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00)
 
 /**
  * number_of_connections - determine whether an client be on the bus
@@ -391,7 +397,7 @@ static void mei_nfc(struct mei_cl_device *cldev)
 
 static struct mei_fixup {
 
-   const uuid_le uuid;
+   const guid_t uuid;
void (*hook)(struct mei_cl_device *cldev);
 } mei_fixups[] = {
MEI_FIXUP(MEI_UUID_ANY, number_of_connections),
@@ -409,15 +415,12 @@ static struct mei_fixup {
 void mei_cl_bus_dev_fixup(struct mei_cl_device *cldev)
 {
struct mei_fixup *f;
-   const uuid_le *uuid = mei_me_cl_uuid(cldev->me_cl);
+   const guid_t *uuid = mei_me_cl_uuid(cldev->me_cl);
int i;
 
for (i = 0; i < ARRAY_SIZE(mei_fixups); i++) {
-
f = &mei_fixups[i];
-   if (uuid_le_cmp(f->uuid, MEI_UUID_ANY) == 0 ||
-   uuid_le_cmp(f->uuid, *uuid) == 0)
+   if (guid_is_null(&f->uuid) || guid_equal(&f->uuid, uuid))
f->hook(cldev);
}
 }
-
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 40c79089e548..c5165f2ec842 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -417,7 +417,7 @@ EXPORT_SYMBOL_GPL(mei_cldev_set_drvdata);
  *
  * Return: me client uuid
  */
-const uuid_le *mei_cldev_uuid(const struct mei_cl_device *cldev)
+const guid_t *mei_cldev_uuid(const struct mei_cl_device *cldev)
 {
return mei_me_cl_uuid(cldev->me_cl);
 }
@@ -606,7 +606,7 @@ struct mei_cl_device_id *mei_cl_device_find(struct 
mei_cl_device *cldev,
struct mei_cl_driver *cldrv)
 {
const struct mei_cl_device_id *id;
-   const uuid_le *uuid;
+   const guid_t *uuid;
u8 version;
bool match;
 
@@ -614,8 +614,8 @@ struct mei_cl_device_id *mei_cl_device_find(struct 
mei_cl_device *cldev,
version = mei_me_cl_ver(cldev->me_cl);
 
id = cldrv->id_table;
-   while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
-   if (!uuid_le_cmp(*uuid, id->uuid)) {
+   while (!guid_is

[PATCH] llist: clang: introduce member_address_is_nonnull()

[Alexander Potapenko]

Currently llist_for_each_entry() and llist_for_each_entry_safe() iterate
until &pos->member != NULL.  But when building the kernel with Clang, the
compiler assumes &pos->member cannot be NULL if the member's offset is
greater than 0 (which would be equivalent to the object being
non-contiguous in memory). Therefore the loop condition is always true,
and the loops become infinite.

To work around this, introduce the member_address_is_nonnull() macro,
which casts object pointer to uintptr_t, thus letting the member pointer
to be NULL.

Signed-off-by: Alexander Potapenko 
---
 include/linux/llist.h | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/include/linux/llist.h b/include/linux/llist.h
index d11738110a7a..a7cdaeddad35 100644
--- a/include/linux/llist.h
+++ b/include/linux/llist.h
@@ -92,6 +92,23 @@ static inline void init_llist_head(struct llist_head *list)
 #define llist_entry(ptr, type, member) \
container_of(ptr, type, member)
 
+/**
+ * member_address_is_nonnull - check whether the member address is not NULL
+ * @ptr:   the object pointer (struct type * that contains the llist_node)
+ * @member:the name of the llist_node within the struct.
+ *
+ * This macro is conceptually the same as
+ * &ptr->member != NULL
+ * , but it works around the fact that compilers can decide that taking a 
member
+ * address is never a NULL pointer.
+ *
+ * Real objects that start at a high address and have a member at NULL are
+ * unlikely to exist, but such pointers may be returned e.g. by the
+ * container_of() macro.
+ */
+#define member_address_is_nonnull(ptr, member) \
+   ((uintptr_t)(ptr) + offsetof(typeof(*(ptr)), member) != 0)
+
 /**
  * llist_for_each - iterate over some deleted entries of a lock-less list
  * @pos:   the &struct llist_node to use as a loop cursor
@@ -145,7 +162,7 @@ static inline void init_llist_head(struct llist_head *list)
  */
 #define llist_for_each_entry(pos, node, member)
\
for ((pos) = llist_entry((node), typeof(*(pos)), member);   \
-&(pos)->member != NULL;\
+member_address_is_nonnull(pos, member);\
 (pos) = llist_entry((pos)->member.next, typeof(*(pos)), member))
 
 /**
@@ -167,7 +184,7 @@ static inline void init_llist_head(struct llist_head *list)
  */
 #define llist_for_each_entry_safe(pos, n, node, member)
   \
for (pos = llist_entry((node), typeof(*pos), member);  \
-&pos->member != NULL &&   \
+member_address_is_nonnull(pos, member) && \
(n = llist_entry(pos->member.next, typeof(*n), member), true); \
 pos = n)
 
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH] device-dax: fix sysfs duplicate warnings

[Dan Williams]

Fix warnings of the form...

 WARNING: CPU: 10 PID: 4983 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
 sysfs: cannot create duplicate filename '/class/dax/dax12.0'
 Call Trace:
  dump_stack+0x63/0x86
  __warn+0xcb/0xf0
  warn_slowpath_fmt+0x5a/0x80
  ? kernfs_path_from_node+0x4f/0x60
  sysfs_warn_dup+0x62/0x80
  sysfs_do_create_link_sd.isra.2+0x97/0xb0
  sysfs_create_link+0x25/0x40
  device_add+0x266/0x630
  devm_create_dax_dev+0x2cf/0x340 [dax]
  dax_pmem_probe+0x1f5/0x26e [dax_pmem]
  nvdimm_bus_probe+0x71/0x120

...by reusing the namespace id for the device-dax instance name.

Now that we have decided that there will never by more than one
device-dax instance per libnvdimm-namespace parent device [1], we can
directly reuse the namepace ids. There are some possible follow-on
cleanups, but those are saved for a later patch to simplify the -stable
backport.

[1]: https://lists.01.org/pipermail/linux-nvdimm/2016-December/008266.html

Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple pmem...")
Cc: Jeff Moyer 
Cc: 
Reported-by: Dariusz Dokupil 
Signed-off-by: Dan Williams 
---
 drivers/dax/device-dax.h |2 +-
 drivers/dax/device.c |   24 
 drivers/dax/pmem.c   |   12 +++-
 3 files changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/dax/device-dax.h b/drivers/dax/device-dax.h
index fdcd9769ffde..688b051750bd 100644
--- a/drivers/dax/device-dax.h
+++ b/drivers/dax/device-dax.h
@@ -21,5 +21,5 @@ struct dax_region *alloc_dax_region(struct device *parent,
int region_id, struct resource *res, unsigned int align,
void *addr, unsigned long flags);
 struct dev_dax *devm_create_dev_dax(struct dax_region *dax_region,
-   struct resource *res, int count);
+   int id, struct resource *res, int count);
 #endif /* __DEVICE_DAX_H__ */
diff --git a/drivers/dax/device.c b/drivers/dax/device.c
index 44d72e5e64cc..e9f3b3e4bbf4 100644
--- a/drivers/dax/device.c
+++ b/drivers/dax/device.c
@@ -529,7 +529,8 @@ static void dev_dax_release(struct device *dev)
struct dax_region *dax_region = dev_dax->region;
struct dax_device *dax_dev = dev_dax->dax_dev;
 
-   ida_simple_remove(&dax_region->ida, dev_dax->id);
+   if (dev_dax->id >= 0)
+   ida_simple_remove(&dax_region->ida, dev_dax->id);
dax_region_put(dax_region);
put_dax(dax_dev);
kfree(dev_dax);
@@ -559,7 +560,7 @@ static void unregister_dev_dax(void *dev)
 }
 
 struct dev_dax *devm_create_dev_dax(struct dax_region *dax_region,
-   struct resource *res, int count)
+   int id, struct resource *res, int count)
 {
struct device *parent = dax_region->dev;
struct dax_device *dax_dev;
@@ -590,10 +591,16 @@ struct dev_dax *devm_create_dev_dax(struct dax_region 
*dax_region,
if (i < count)
goto err_id;
 
-   dev_dax->id = ida_simple_get(&dax_region->ida, 0, 0, GFP_KERNEL);
-   if (dev_dax->id < 0) {
-   rc = dev_dax->id;
-   goto err_id;
+   if (id < 0) {
+   id = ida_simple_get(&dax_region->ida, 0, 0, GFP_KERNEL);
+   dev_dax->id = id;
+   if (id < 0) {
+   rc = id;
+   goto err_id;
+   }
+   } else {
+   /* region provider owns @id lifetime */
+   dev_dax->id = -1;
}
 
/*
@@ -625,7 +632,7 @@ struct dev_dax *devm_create_dev_dax(struct dax_region 
*dax_region,
dev->parent = parent;
dev->groups = dax_attribute_groups;
dev->release = dev_dax_release;
-   dev_set_name(dev, "dax%d.%d", dax_region->id, dev_dax->id);
+   dev_set_name(dev, "dax%d.%d", dax_region->id, id);
 
rc = cdev_device_add(cdev, dev);
if (rc) {
@@ -641,7 +648,8 @@ struct dev_dax *devm_create_dev_dax(struct dax_region 
*dax_region,
return dev_dax;
 
  err_dax:
-   ida_simple_remove(&dax_region->ida, dev_dax->id);
+   if (dev_dax->id >= 0)
+   ida_simple_remove(&dax_region->ida, dev_dax->id);
  err_id:
kfree(dev_dax);
 
diff --git a/drivers/dax/pmem.c b/drivers/dax/pmem.c
index 9f2a0b4fd801..8d8c852ba8f2 100644
--- a/drivers/dax/pmem.c
+++ b/drivers/dax/pmem.c
@@ -58,13 +58,12 @@ static void dax_pmem_percpu_kill(void *data)
 
 static int dax_pmem_probe(struct device *dev)
 {
-   int rc;
void *addr;
struct resource res;
+   int rc, id, region_id;
struct nd_pfn_sb *pfn_sb;
struct dev_dax *dev_dax;
struct dax_pmem *dax_pmem;
-   struct nd_region *nd_region;
struct nd_namespace_io *nsio;
struct dax_region *dax_region;
struct nd_namespace_common *ndns;
@@ -123,14 +122,17 @@ static int dax_pmem_probe(struct device *dev)
/* adjust the dax_region resource to the start of data */
res.start +

Re: [PATCH] MAINTAINERS: fpga: Update email and add patchwork URL

[Alan Tull]

On Wed, Jul 19, 2017 at 11:37 AM, Moritz Fischer  wrote:
> Add Q: entry for patchwork and update my email address.
>
> Signed-off-by: Moritz Fischer 
> Cc: Alan Tull 
> Cc: linux-f...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Acked-by: Alan Tull 
> ---
>  MAINTAINERS | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index f42daf7..ea690a6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -5213,10 +5213,11 @@ K:  fmc_d.*register
>
>  FPGA MANAGER FRAMEWORK
>  M: Alan Tull 
> -R: Moritz Fischer 
> +R: Moritz Fischer 
>  L: linux-f...@vger.kernel.org
>  S: Maintained
>  T: git git://git.kernel.org/pub/scm/linux/kernel/git/atull/linux-fpga.git
> +Q: http://patchwork.kernel.org/project/linux-fpga/list/
>  F: Documentation/fpga/
>  F: Documentation/devicetree/bindings/fpga/
>  F: drivers/fpga/
> --
> 2.7.4
>

[PATCH] ath10k_htt_rx_amsdu_allowed(): use ath10k_dbg()

[Gabriel Craciunescu]

From: Gabriel Craciunescu 

Each time we get disconencted from AP we get flooded with messages like:

...
ath10k_pci :03:00.0: no channel configured; ignoring frame(s)!

ath10k_warn: 155 callbacks suppressed
...

Use ath10k_dbg() here too.

Signed-off-by: Gabriel Craciunescu 
---
 drivers/net/wireless/ath/ath10k/htt_rx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 398dda978d6e..75d9b59b7e63 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -1514,7 +1514,7 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k *ar,
 */
 
if (!rx_status->freq) {
-   ath10k_warn(ar, "no channel configured; ignoring frame(s)!\n");
+   ath10k_dbg(ar, ATH10K_DBG_HTT, "no channel configured; ignoring 
frame(s)!\n");
return false;
}
 
-- 
2.13.3

[PATCH] trace-cmd record: Add --quiet (-q) option

[Will Hawkins]

trace-cmd record will output information about the
number of missed trace events, the size of the data
written to the data file from events on each CPU,
etc. When tracing programs that rely on specific
output from a command, this output can cause mis-
matches that cause failures. This is particularly
true for SPEC.

When run with the --quiet (-q) option, trace-cmd
record squelches this extraneous output.

Signed-off-by: Will Hawkins 
---
 trace-cmd-local.h |  2 ++
 trace-cmd.c   |  1 +
 trace-local.h |  1 +
 trace-output.c|  9 ++---
 trace-record.c| 17 +
 trace-usage.c |  4 +++-
 6 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/trace-cmd-local.h b/trace-cmd-local.h
index 9412f9d..b9425ee 100644
--- a/trace-cmd-local.h
+++ b/trace-cmd-local.h
@@ -25,6 +25,8 @@
 #include "trace-cmd.h"
 #include "event-utils.h"
 
+extern int quiet;
+
 static ssize_t __do_write(int fd, const void *data, size_t size)
 {
ssize_t tot = 0;
diff --git a/trace-cmd.c b/trace-cmd.c
index 0f71e12..5a10605 100644
--- a/trace-cmd.c
+++ b/trace-cmd.c
@@ -31,6 +31,7 @@ int silence_warnings;
 int show_status;
 
 int debug;
+int quiet;
 
 void warning(const char *fmt, ...)
 {
diff --git a/trace-local.h b/trace-local.h
index fa987bc..87635a0 100644
--- a/trace-local.h
+++ b/trace-local.h
@@ -27,6 +27,7 @@
 #include "event-utils.h"
 
 extern int debug;
+extern int quiet;
 
 /* fix stupid glib guint64 typecasts and printf formats */
 typedef unsigned long long u64;
diff --git a/trace-output.c b/trace-output.c
index e2ab0db..bfe6331 100644
--- a/trace-output.c
+++ b/trace-output.c
@@ -1146,8 +1146,9 @@ static int __tracecmd_append_cpu_data(struct 
tracecmd_output *handle,
goto out_free;
 
for (i = 0; i < cpus; i++) {
-   fprintf(stderr, "CPU%d data recorded at offset=0x%llx\n",
-   i, (unsigned long long) offsets[i]);
+   if (!quiet)
+   fprintf(stderr, "CPU%d data recorded at 
offset=0x%llx\n",
+   i, (unsigned long long) offsets[i]);
offset = lseek64(handle->fd, offsets[i], SEEK_SET);
if (offset == (off64_t)-1) {
warning("could not seek to %lld\n", offsets[i]);
@@ -1160,7 +1161,9 @@ static int __tracecmd_append_cpu_data(struct 
tracecmd_output *handle,
check_size, sizes[i]);
goto out_free;
}
-   fprintf(stderr, "%llu bytes in size\n", (unsigned long 
long)check_size);
+   if (!quiet)
+   fprintf(stderr, "%llu bytes in size\n",
+   (unsigned long long)check_size);
}
 
free(offsets);
diff --git a/trace-record.c b/trace-record.c
index 1b55043..1f4eef4 100644
--- a/trace-record.c
+++ b/trace-record.c
@@ -2983,10 +2983,12 @@ static void print_stat(struct buffer_instance *instance)
int cpu;
 
if (!is_top_instance(instance))
-   printf("\nBuffer: %s\n\n", instance->name);
+   if (!quiet)
+   printf("\nBuffer: %s\n\n", instance->name);
 
for (cpu = 0; cpu < cpu_count; cpu++)
-   trace_seq_do_printf(&instance->s_print[cpu]);
+   if (!quiet)
+   trace_seq_do_printf(&instance->s_print[cpu]);
 }
 
 enum {
@@ -3742,7 +3744,8 @@ static void check_plugin(const char *plugin)
}
die ("Plugin '%s' does not exist", plugin);
  out:
-   fprintf(stderr, "  plugin '%s'\n", plugin);
+   if (!quiet)
+   fprintf(stderr, "  plugin '%s'\n", plugin);
free(buf);
 }
 
@@ -4158,6 +4161,7 @@ void update_first_instance(struct buffer_instance 
*instance, int topt)
 
 enum {
 
+   OPT_quiet   = 246,
OPT_debug   = 247,
OPT_max_graph_depth = 248,
OPT_tsoffset= 249,
@@ -4369,6 +4373,7 @@ void trace_record (int argc, char **argv)
{"ts-offset", required_argument, NULL, OPT_tsoffset},
{"max-graph-depth", required_argument, NULL, 
OPT_max_graph_depth},
{"debug", no_argument, NULL, OPT_debug},
+   {"quiet", no_argument, NULL, OPT_quiet},
{"help", no_argument, NULL, '?'},
{NULL, 0, NULL, 0}
};
@@ -4376,7 +4381,7 @@ void trace_record (int argc, char **argv)
if (extract)
opts = "+haf:Fp:co:O:sr:g:l:n:P:N:tb:B:ksiT";
else
-   opts = 
"+hae:f:Fp:cC:dDGo:O:s:r:vg:l:n:P:N:tb:R:B:ksSiTm:M:H:";
+   opts = 
"+hae:f:Fp:cC:dDGo:O:s:r:vg:l:n:P:N:tb:R:B:ksSiTm:M:H:q";
c = getopt_long (argc-1, argv+1, opts, long_options, 
&option_index);
if (c == -1)
break;
@@ -4641,6 +4646,10 @@ void trac

Re: [PATCH v1] crypto: caam - set hwrng quality level

[Oleksij Rempel]

On Wed, Jul 19, 2017 at 04:53:21PM +, Horia Geantă wrote:
> On 7/19/2017 7:32 PM, Oleksij Rempel wrote:
> > On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote:
> >> On 7/19/2017 10:45 AM, Oleksij Rempel wrote:
> >>> According documentation, it is NIST certified TRNG.
> >>> So, set high quality to let the HWRNG framework automatically use it.
> >>>
> >>> Signed-off-by: Oleksij Rempel 
> >>> ---
> >>>  drivers/crypto/caam/caamrng.c | 6 ++
> >>>  1 file changed, 6 insertions(+)
> >>>
> >>> diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
> >>> index 41398da3edf4..684c0bc88dfd 100644
> >>> --- a/drivers/crypto/caam/caamrng.c
> >>> +++ b/drivers/crypto/caam/caamrng.c
> >>> @@ -292,10 +292,16 @@ static int caam_init_rng(struct caam_rng_ctx *ctx, 
> >>> struct device *jrdev)
> >>>   return 0;
> >>>  }
> >>>  
> >>> +/*
> >>> + * hwrng register struct
> >>> + * The trng is suppost to have 100% entropy, and thus
> >>> + * we register with a very high quality value.
> >>> + */
> >>>  static struct hwrng caam_rng = {
> >>>   .name   = "rng-caam",
> >>>   .cleanup= caam_cleanup,
> >>>   .read   = caam_read,
> >>> + .quality= 999,
> >>
> >> Why not 1024, i.e. where is 999 coming from?
> > 
> > It comes from s390-trng.c driver.
> > Should I use 1024 instead?
> > 
> AFAICT the range for quality is from 0 to 1024 (no entropy -> perfect
> entropy).
> 
> 1024 should be used since I'd expect a HW TRNG to provide perfect
> entropy unless otherwise stated.

I assume 1024 can be given only on verified HW with accessible verilog
files and compared with resulting chip :)
May be this would be a good example https://www.sifive.com/

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v2 1/4] time: rtc-lib: Add rtc_show_time(const char *prefix_msg)

[Mark Salyzyn]

On 07/19/2017 05:03 AM, Prarit Bhargava wrote:


On 07/19/2017 03:23 AM, Thomas Gleixner wrote:

On Tue, 18 Jul 2017, Mark Salyzyn wrote:

On 07/18/2017 03:35 PM, Thomas Gleixner wrote:

There was some discussion about making the clock source for dmesg time
stamps selectable, so you can use MONOTONIC, REALTIME, BOOTTIME. The
patches looked sensible, but there was some showstopper vs. the user space
dmesg utility. See:

The timestamps are useful for the 'second' purpose of these patches when
dmesg time is BOOTTIME or MONOTONIC, and can be turned off if REALTIME
is selected. Having rtc_show_time a single point for switching this no doubt
helps,
not hinders, that dmesg issue.

The inflection points would still serve a purpose, still need
suspend/resume/hibernate/restore. The reboot messages are _only_ useful to
us with their timestamps, as I checked and the only tools that use those are
for log synchronization. We may be able to do away with them on REALTIME
dmesg'ing; but the standardization of the message as a marker would have a
legacy purpose (!)

NB: We have a similar configuration for the user space logger, which can be
configured to report in MONOTONIC time. We have yet to have a vendor
use the feature, opting for REALTIME logging for user space activities.
Our klogd (which runs at background priority and is batched) manages a
histogram relationship between MONOTONIC and REALTIME helped by these
prints and incorporates the REALTIME dmesg logs merged into our user
space logging database.

There is another option to remedy this and the dmesg tooling issues:

Instead of switching the time stamps in dmesg to a different clock we might
as well have an optional secondary timestamp. So instead of:

  [  341.590930] wlan0: associated

you would get:

  [  341.590930] [ sec.usec] wlan0: associated

where the second time stamp would be CLOCK_REALTIME/BOOTTIME.

That should also solve Prarits problem, hmm?

It would but I would prefer a single time stamp be printed than two.  I think
two timestamps is adding confusion to the output from a end-users point of view.


Agreed, and so many tools will be in pain (toybox, busybox, for 
instance). Not that I disagree, but API changes should always get an 
environmental assessment ...



Mark, why don't we get together and fixup my original patchset to make sure it
meets your needs?  It will fix both of our issues albeit not necessarily in the
text format you want it.
I am currently retesting with the rtc format patch rolled out 
separately, could probably roll into your set.


-- Mark

Re: [PATCH] mmc: core: Fix access to HS400-ES devices

[Doug Anderson]

Hi,

On Tue, Mar 14, 2017 at 9:22 AM, Ulf Hansson  wrote:
> On 1 March 2017 at 23:11, Guenter Roeck  wrote:
>> HS400-ES devices fail to initialize with the following error messages.
>>
>> mmc1: power class selection to bus width 8 ddr 0 failed
>> mmc1: error -110 whilst initialising MMC card
>>
>> This was seen on Samsung Chromebook Plus. Code analysis points to
>> commit 3d4ef329757c ("mmc: core: fix multi-bit bus width without
>> high-speed mode"), which attempts to set the bus width for all but
>> HS200 devices unconditionally. However, for HS400-ES, the bus width
>> is already selected.
>>
>> Cc: Anssi Hannula 
>> Cc: Douglas Anderson 
>> Cc: Brian Norris 
>> Fixes: 3d4ef329757c ("mmc: core: fix multi-bit bus width ...")
>> Signed-off-by: Guenter Roeck 
>
> Sorry for the delay. Been traveling.
>
> Applied for fixes, thanks!

+stable

The commit 3d4ef329757c ("mmc: core: fix multi-bit bus width without
high-speed mode") got backported to many stable branches, so probably
this commit 773dc118756b ("mmc: core: Fix access to HS400-ES devices")
also needs to get picked to the same stable branches.

In the very least v4.9 and v4.4 stable includes the broken patch but
not this fix.

-Doug

Re: [PATCH] ath10k_htt_rx_amsdu_allowed(): use ath10k_dbg()

[Gabriel C]

On 19.07.2017 18:26, Joe Perches wrote:

On Wed, 2017-07-19 at 17:37 +0200, Gabriel C wrote:

  Each time we get disconencted from AP we get flooded with messages 
like:

  ...
  ath10k_pci :03:00.0: no channel configured; ignoring frame(s)!
  
  ath10k_warn: 155 callbacks suppressed


[]


diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c

[]

@@ -1514,7 +1514,7 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k *ar,
   */

  if (!rx_status->freq) {
-   ath10k_warn(ar, "no channel configured; ignoring frame(s)!\n");
+   ath10k_dbg(ar, ATH10K_DBG_HTT, "no channel configured; ignoring 
frame(s)!\n");
  return false;
  }


Hi.  This doesn't apply because of tab to space conversions.

Please use git send-email to send your patch.


Yes you are right .. I think newer thunderbird just doesn't work anymore to 
send patches.

Will have a look to setup git send-email and resend.



Maybe read Documentation/process/email-clients.rst



I use tbird to send patches forver but it seems latest updates here broke it 
some sort.

Re: [PATCH] ibm_rtl: remove unnecessary static in ibm_rtl_write()

[Andy Shevchenko]

On Wed, Jul 19, 2017 at 1:01 AM, Gustavo A. R. Silva
 wrote:
> Remove unnecessary static on local variable cmd_port_val. Such variable
> is initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces the
> object file size.
>
> This issue was detected using Coccinelle and the following semantic patch:
> https://github.com/GustavoARSilva/coccinelle/blob/master/static/static_unused.cocci
>
> In the following log you can see a difference in the object file size.
> This log is the output of the size command, before and after the code
> change:
>
> before:
>textdata bss dec hex filename
>3932 3440 51278841ecc drivers/platform/x86/ibm_rtl.o
>
> after:
>textdata bss dec hex filename
>38873384 44877191e27 drivers/platform/x86/ibm_rtl.o
>

Pushed to testing, thanks,

> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/platform/x86/ibm_rtl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/ibm_rtl.c b/drivers/platform/x86/ibm_rtl.c
> index c62e5e1..610ac83 100644
> --- a/drivers/platform/x86/ibm_rtl.c
> +++ b/drivers/platform/x86/ibm_rtl.c
> @@ -103,7 +103,7 @@ static void rtl_port_unmap(void __iomem *addr)
>  static int ibm_rtl_write(u8 value)
>  {
> int ret = 0, count = 0;
> -   static u32 cmd_port_val;
> +   u32 cmd_port_val;
>
> RTL_DEBUG("%s(%d)\n", __func__, value);
>
> --
> 2.5.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] msi-wmi: remove unnecessary static in msi_wmi_notify()

[Andy Shevchenko]

On Wed, Jul 19, 2017 at 12:49 AM, Gustavo A. R. Silva
 wrote:
> Remove unnecessary static on local variable _key_. Such variable is
> initialized before being used, on every execution path throughout
> the function. The static has no benefit and, removing it reduces
> the object file size.
>
> This issue was detected using Coccinelle and the following semantic patch:
> https://github.com/GustavoARSilva/coccinelle/blob/master/static/static_unused.cocci
>
> In the following log you can see a significant difference in the object
> file size. Also, there is a significant difference in the bss segment.
> This log is the output of the size command, before and after the code
> change:
>
> before:
>textdata bss dec hex filename
>65303736 320   10586295a drivers/platform/x86/msi-wmi.o
>
> after:
>textdata bss dec hex filename
>64943648 256   10398289e drivers/platform/x86/msi-wmi.o
>

Pushed to testing, thanks.

P.S. Please, use subsystem prefix next time.

> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/platform/x86/msi-wmi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/platform/x86/msi-wmi.c b/drivers/platform/x86/msi-wmi.c
> index f6209b7..6201382 100644
> --- a/drivers/platform/x86/msi-wmi.c
> +++ b/drivers/platform/x86/msi-wmi.c
> @@ -184,7 +184,7 @@ static const struct backlight_ops msi_backlight_ops = {
>  static void msi_wmi_notify(u32 value, void *context)
>  {
> struct acpi_buffer response = { ACPI_ALLOCATE_BUFFER, NULL };
> -   static struct key_entry *key;
> +   struct key_entry *key;
> union acpi_object *obj;
> acpi_status status;
>
> --
> 2.5.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [RFC PATCH v2 3/3] pmbus: Add MAX31785 driver

[Guenter Roeck]

On Thu, Jul 20, 2017 at 12:35:09AM +0930, Joel Stanley wrote:
> On Tue, Jul 18, 2017 at 1:06 PM, Andrew Jeffery  wrote:
> > The driver features fan control and basic dual-tachometer support.
> 
> Say something about the hardware?
> 
>  max31785 is a fancy fan controller with temp measurement, pwm, tach,
> breakfast making from Maxim.
> 
> 
> >
> > The fan control makes use of the new virtual registers exposed by the
> > pmbus core, mixing use of the default implementations with some
> > overrides via the read/write handlers. FAN_COMMAND_1 on the MAX31785
> > breaks the values into bands that depend on the RPM or PWM control mode.
> >
> > The dual tachometer feature is implemented in hardware with a TACHSEL
> > input to indicate the rotor under measurement, and exposed on the bus by
> > extending the READ_FAN_SPEED_1 word with two extra bytes*.
> > The need to read the non-standard four-byte response leads to a cut-down
> > implementation of i2c_smbus_xfer_emulated() included in the driver.
> > Further, to expose the second rotor tachometer value to userspace,
> > virtual fans are implemented by re-routing the FAN_CONFIG_1_2 register
> > from the undefined (in hardware) pages 23-28 to the same register on
> > pages 0-5, and similarly re-routing READ_FAN_SPEED_1 requests on 23-28
> > to pages 0-5 but extracting the second word of the four-byte response.
> >
> > * The documentation recommends the slower rotor be associated with
> > TACHSEL=0, which is the input used by the controller's closed-loop fan
> > management.
> >
> > Signed-off-by: Andrew Jeffery 
> > ---
> > v1 -> v2:
> >
> > * Implement in terms of virtual registers
> > * Add support for dual-tachometer readings through 'virtual fans' (unused 
> > pages)
> >
> >  drivers/hwmon/pmbus/Kconfig|  10 ++
> >  drivers/hwmon/pmbus/Makefile   |   1 +
> >  drivers/hwmon/pmbus/max31785.c | 372 
> > +
> >  3 files changed, 383 insertions(+)
> >  create mode 100644 drivers/hwmon/pmbus/max31785.c
> >
> > diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
> > index cad1229b7e17..5f2f3c6c7499 100644
> > --- a/drivers/hwmon/pmbus/Kconfig
> > +++ b/drivers/hwmon/pmbus/Kconfig
> > @@ -95,6 +95,16 @@ config SENSORS_MAX20751
> >   This driver can also be built as a module. If so, the module will
> >   be called max20751.
> >
> > +config SENSORS_MAX31785
> > +   tristate "Maxim MAX31785 and compatibles"
> > +   default n
> > +   help
> > + If you say yes here you get hardware monitoring support for Maxim
> > + MAX31785.
> > +
> > + This driver can also be built as a module. If so, the module will
> > + be called max31785.
> > +
> >  config SENSORS_MAX34440
> > tristate "Maxim MAX34440 and compatibles"
> > default n
> > diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
> > index 562132054aaf..4ea548a8af46 100644
> > --- a/drivers/hwmon/pmbus/Makefile
> > +++ b/drivers/hwmon/pmbus/Makefile
> > @@ -10,6 +10,7 @@ obj-$(CONFIG_SENSORS_LTC2978) += ltc2978.o
> >  obj-$(CONFIG_SENSORS_LTC3815)  += ltc3815.o
> >  obj-$(CONFIG_SENSORS_MAX16064) += max16064.o
> >  obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
> > +obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
> >  obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
> >  obj-$(CONFIG_SENSORS_MAX8688)  += max8688.o
> >  obj-$(CONFIG_SENSORS_TPS40422) += tps40422.o
> > diff --git a/drivers/hwmon/pmbus/max31785.c b/drivers/hwmon/pmbus/max31785.c
> > new file mode 100644
> > index ..1baa961f2eb1
> > --- /dev/null
> > +++ b/drivers/hwmon/pmbus/max31785.c
> > @@ -0,0 +1,372 @@
> > +/*
> > + * Copyright (C) 2017 IBM Corp.
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License as published by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "pmbus.h"
> > +
> > +#define MFR_FAN_CONFIG_DUAL_TACH   BIT(12)
> > +#define MFR_FAN_CONFIG_TSFOBIT(9)
> > +#define MFR_FAN_CONFIG_TACHO   BIT(8)
> > +
> > +#define MAX31785_CAP_DUAL_TACH BIT(0)
> > +
> > +struct max31785 {
> > +   struct pmbus_driver_info info;
> > +
> > +   u32 capabilities;
> > +};
> > +
> > +enum max31785_regs {
> > +   PMBUS_MFR_FAN_CONFIG= 0xF1,
> > +   PMBUS_MFR_READ_FAN_PWM  = 0xF3,
> > +   PMBUS_MFR_FAN_FAULT_LIMIT   = 0xF5,
> > +   PMBUS_MFR_FAN_WARN_LIMIT= 0xF6,
> > +   PMBUS_MFR_FAN_PWM_AVG   = 0xF8,
> > +};
> > +
> > +#define to_max31785(_c) container_of(pmbus_get_info(_c), struct max31785, 
> > info)
> > +
> > +static int max31785_read_byte_data(struct i2c_client *client, int page,
> > +  int reg)
> > +{
> > +   struct

RE: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Luck, Tony]

>> Later when GHES gives you a NODE/CARD/MODULE) in an error record.  You need
>> to match these up. But SMBIOS only gave you two strings "Locator" and "Bank
>> Locator" which have no defined syntax. You are at the mercy of the BIOS 
>> writer
>> to put in something parseable.
>
> Well, at some point it is only so much we can do, right?
>
> I mean, if FW says it wants to do firmware-first and we go and adhere
> to that, it should be expected that said FW vendor marks the silkscreen
> labels and DMI data accordingly.
>
> I mean, it is time for FW to put its money where its mouth is, no?
>
> How else would you do this?

By thinking a bit more and realizing that what I wrote up above misses that
at byte offset 78 in the UEFI memory error section there is "Module Handle"
which tells you which SMBIOS entry to use.

So this should work just fine (as long as BIOS fills out all these fields ...
there's a "Validation Bits" mask at the start of the error structure that says
which fields have been populated).

-Tony

Re: [PATCH v2 1/3] mux: Add mux_control_get_optional() API

[Stephen Boyd]

Quoting Peter Rosin (2017-07-19 00:15:38)
> On 2017-07-19 04:08, Stephen Boyd wrote:
> > Quoting Peter Rosin (2017-07-17 01:20:14)
> >> On 2017-07-14 23:40, Stephen Boyd wrote:
> >>> @@ -441,6 +447,8 @@ struct mux_control *mux_control_get(struct device 
> >>> *dev, const char *mux_name)
> >>>   if (mux_name) {
> >>>   index = of_property_match_string(np, "mux-control-names",
> >>>mux_name);
> >>> + if (index == -EINVAL && optional)
> >>> + return NULL;
> >>
> >> What about -ENODATA?
> > 
> > At this point in the code we're finding the index of a mux-control-names
> > property so I was trying to handle the case where there isn't a
> > mux-control-names property at all
> 
> Yes, you indeed need to check for -EINVAL to catch that. No argument
> about that.

Ok.

> 
> >   but we're looking for something
> > optional anyway. If there is a property, then we would see some other
> > error if something went wrong and then pass the error up. There is a
> > hole where there isn't a mux-control-names property and we're looking
> > for something that's optional, but there is a mux-control property. Do
> > we care though? The DT seems broken then.
> 
> I was thinking about the case where mux-control-names names *other* muxes
> but not the one asked for in this call. That's not broken and should be
> handled. The way I read it, you get -ENODATA in that case?

Yes that would return -ENODATA. Similarly, it would be returned if we
had a boolean mux-control-names property (which is completely broken).

> 
> >> And if an optional mux is found here, but lookup
> >> fails later in e.g. the of_parse_phandle_with_args call, then I think
> >> an error should be returned. Because that seems like an indication that
> >> DT specifies that there *should* be a mux, but then there isn't one.
> > 
> > of_parse_phandle_with_args() would return ENOENT when there isn't a
> > mux-control property in DT. So I've trapped that case and returned an
> > "optional mux" pointer of NULL. I think we handle the case you mention,
> > where some index is found but it returns an error, because that would
> > return some error besides -ENOENT.
> > 
> > Sorry, I'm not really following what you're suggesting. Maybe it got
> > mixed up with the NULL vs. non-NULL return value from mux_control_get().
> 
> What I mean is that if you have passed a mux_name and the index of that
> name was indeed found in the of_property_match_string call, then any
> failure from of_parse_phandle_with_args indicates a bad DT and should
> IMO result in an error. I.e., when evaluating the result from
> of_parse_phandle_with_args, you should account for the optional param
> if and only if mux_name is NULL.
> 
> You can do that by e.g. setting optional to false after looking up the
> mux_name index (because at that point the mux is no longer considered
> optional). E.g. as the last statement in the if (!mux_name) block.
> 

Ok got it. I'll rework the logic.

[PATCH 2/3] arm/syscalls: Optimize work flags assembly check

[Thomas Garnier]

Remove the double branch and use tsteq instead.

Suggested-by: Russell King 
Signed-off-by: Thomas Garnier 
---
 arch/arm/kernel/entry-common.S | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index e33c32d56193..6e094b639d83 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -42,8 +42,7 @@ ret_fast_syscall:
disable_irq_notrace @ disable interrupts
ldr r1, [tsk, #TI_FLAGS]@ re-check for syscall tracing
tst r1, #_TIF_SYSCALL_WORK
-   bne fast_work_pending
-   tst r1, #_TIF_WORK_MASK
+   tsteq   r1, #_TIF_WORK_MASK
bne fast_work_pending
 
/* perform architecture specific actions before user return */
@@ -70,14 +69,12 @@ ret_fast_syscall:
disable_irq_notrace @ disable interrupts
ldr r1, [tsk, #TI_FLAGS]@ re-check for syscall tracing
tst r1, #_TIF_SYSCALL_WORK
-   bne fast_work_pending
-   tst r1, #_TIF_WORK_MASK
+   tsteq   r1, #_TIF_WORK_MASK
beq no_work_pending
  UNWIND(.fnend )
 ENDPROC(ret_fast_syscall)
 
/* Slower path - fall through to work_pending */
-fast_work_pending:
 #endif
 
tst r1, #_TIF_SYSCALL_WORK
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH 1/3] arm/syscalls: Move address limit check in loop

[Thomas Garnier]

The work pending loop can call set_fs after addr_limit_user_check
removed the _TIF_FSCHECK flag. To prevent the infinite loop, move
the addr_limit_user_check call at the beginning of the loop.

Fixes: 73ac5d6a2b6a ("arm/syscalls: Check address limit on user-mode return")
Reported-by: Leonard Crestez 
Signed-off-by: Thomas Garnier 
---
 arch/arm/kernel/signal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index 3a48b54c6405..f4574287d14b 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -573,10 +573,10 @@ do_work_pending(struct pt_regs *regs, unsigned int 
thread_flags, int syscall)
 */
trace_hardirqs_off();
 
-   /* Check valid user FS if needed */
-   addr_limit_user_check();
-
do {
+   /* Check valid user FS if needed */
+   addr_limit_user_check();
+
if (likely(thread_flags & _TIF_NEED_RESCHED)) {
schedule();
} else {
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH 3/3] arm64/syscalls: Move address limit check in loop

[Thomas Garnier]

The original bug was reported on arm but I am fixing arm64 too because
it has a similar code pattern.

The work pending loop can call set_fs after addr_limit_user_check
removed the _TIF_FSCHECK flag. To prevent the infinite loop, move the
addr_limit_user_check call at the beginning of the loop.

Fixes: cf7de27ab351 ("arm64/syscalls: Check address limit on user-mode return")
Reported-by: Leonard Crestez 
Signed-off-by: Thomas Garnier 
---
 arch/arm64/kernel/signal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index e3e3293d1123..8e2705983e1d 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -751,10 +751,10 @@ asmlinkage void do_notify_resume(struct pt_regs *regs,
 */
trace_hardirqs_off();
 
-   /* Check valid user FS if needed */
-   addr_limit_user_check();
-
do {
+   /* Check valid user FS if needed */
+   addr_limit_user_check();
+
if (thread_flags & _TIF_NEED_RESCHED) {
schedule();
} else {
-- 
2.14.0.rc0.284.gd933b75aa4-goog

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

[Stephen Hemminger]

On Wed, 19 Jul 2017 13:48:03 -0400 (EDT)
Mohammed Gamal  wrote:

> - Original Message -
> > On Wed, 19 Jul 2017 15:19:28 +0200
> > Mohammed Gamal  wrote:
> >   
> > > This condition already uses an object of type ipv6hdr in the line above.
> > > Use the object directly instead of calling ipv6_hdr
> > > 
> > > Signed-off-by: Mohammed Gamal 
> > > ---
> > >  drivers/net/hyperv/netvsc_drv.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/hyperv/netvsc_drv.c
> > > b/drivers/net/hyperv/netvsc_drv.c
> > > index 63c98bb..06d591c 100644
> > > --- a/drivers/net/hyperv/netvsc_drv.c
> > > +++ b/drivers/net/hyperv/netvsc_drv.c
> > > @@ -339,7 +339,7 @@ static u32 net_checksum_info(struct sk_buff *skb)
> > >  
> > >   if (ip6->nexthdr == IPPROTO_TCP)
> > >   return TRANSPORT_INFO_IPV6_TCP;
> > > - else if (ipv6_hdr(skb)->nexthdr == IPPROTO_UDP)
> > > + else if (ip6->nexthdr == IPPROTO_UDP)
> > >   return TRANSPORT_INFO_IPV6_UDP;
> > >   }
> > >
> > 
> > Patch looks fine.
> > Network patches go through net...@vger.kernel.org not linux driver mailing
> > list.
> > I will add it to my next patch of patches that are going to netdev for
> > net-next.
> >   
> Thanks for the heads up. Will take that into consideration next time.
> 
> It's worth pointing out that MAINTAINERS points that files under 
> drivers/net/hyperv are to be sent to de...@linuxdriverproject.org.
> Perhaps that should be updated.

MAINTAINERS doesn't have a good way to handle dual sub-trees.

Re: [PATCH v4 3/3] KVM: nVMX: Emulate EPTP switching for the L1 hypervisor

[Bandan Das]

Radim Krčmář  writes:

> 2017-07-17 13:58-0400, Bandan Das:
>> Radim Krčmář  writes:
>> ...
 > and no other mentions of a VM exit, so I think that the VM exit happens
 > only under these conditions:
 >
 >   — The EPT memory type (bits 2:0) must be a value supported by the
 > processor as indicated in the IA32_VMX_EPT_VPID_CAP MSR (see
 > Appendix A.10).
 >   — Bits 5:3 (1 less than the EPT page-walk length) must be 3, indicating
 > an EPT page-walk length of 4; see Section 28.2.2.
 >   — Bit 6 (enable bit for accessed and dirty flags for EPT) must be 0 if
 > bit 21 of the IA32_VMX_EPT_VPID_CAP MSR (see Appendix A.10) is read
 > as 0, indicating that the processor does not support accessed and
 > dirty flags for EPT.
 >   — Reserved bits 11:7 and 63:N (where N is the processor’s
 > physical-address width) must all be 0.
 >
 > And it looks like we need parts of nested_ept_init_mmu_context() to
 > properly handle VMX_EPT_AD_ENABLE_BIT.
 
 I completely ignored AD and the #VE sections. I will add a TODO item
 in the comment section.
>>>
>>> AFAIK, we don't support #VE, but AD would be nice to handle from the
>>> beginning.  (I think that caling nested_ept_init_mmu_context() as-is
>>> isn't that bad.)
>> 
>> I went back to the spec to take a look at the AD handling. It doesn't look
>> like anything needs to be done since nested_ept_init_mmu_context() is already
>> being called with the correct eptp in prepare_vmcs02 ? Anything else that
>> needs to be done for AD handling in vmfunc context ?
>
> AD is decided by EPTP bit 6, so it can be toggled by EPTP switching and
> we don't call prepare_vmcs02() after emulating VMFUNC vm exit.
> We want to forward the new AD configuration to KVM's MMU.

Thanks, I had incorrectly assumed that prepare_vmcs02 will be called after
an exit unconditionally. I will work something up soon.

Bandan

Re: [PATCH] libkmod-elf: resolve CRC if module is built with MODULE_REL_CRCS

[Lucas De Marchi]

On Wed, Jul 19, 2017 at 7:56 AM, Yauheni Kaliuta
 wrote:
> Normally exported symbol's crc is stored as absolute (SHN_ABS)
> value of special named symbol __crc_.
>
> When the kernel and modules are built with the config option
> CONFIG_MODULE_REL_CRCS, all the CRCs are put in a special section
> and the __crc_ symbols values are offsets in the
> section. See patch description of the commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=56067812d5b0e737ac2063e94a50f76b810d6ca3
>
> Add kmod support of this configuration.
>
> Signed-off-by: Yauheni Kaliuta 
> ---
>  libkmod/libkmod-elf.c | 30 +-
>  1 file changed, 29 insertions(+), 1 deletion(-)
>
> diff --git a/libkmod/libkmod-elf.c b/libkmod/libkmod-elf.c
> index 90da89aebbaf..ef4a8a3142a1 100644
> --- a/libkmod/libkmod-elf.c
> +++ b/libkmod/libkmod-elf.c
> @@ -747,6 +747,31 @@ static inline uint8_t kmod_symbol_bind_from_elf(uint8_t 
> elf_value)
> }
>  }
>
> +static uint64_t kmod_elf_resolve_crc(const struct kmod_elf *elf, uint64_t 
> crc, uint16_t shndx)
> +{
> +   int err;
> +   uint64_t off, size;
> +   uint32_t nameoff;
> +
> +   if (shndx == SHN_ABS || shndx == SHN_UNDEF)
> +   return crc;
> +
> +   err = elf_get_section_info(elf, shndx, &off, &size, &nameoff);
> +   if (err < 0) {
> +   ELFDBG("Cound not find section index %"PRIu16" for crc", 
> shndx);
> +   return (uint64_t)-1;
> +   }
> +
> +   if (crc > (size - sizeof(uint32_t))) {
> +   ELFDBG("CRC offset %"PRIu64" is too big, section %"PRIu16" 
> size is %"PRIu64"\n",
> +  crc, shndx, size);
> +   return (uint64_t)-1;
> +   }
> +
> +   crc = elf_get_uint(elf, off + crc, sizeof(uint32_t));
> +   return crc;
> +}
> +
>  /* array will be allocated with strings in a single malloc, just free *array 
> */
>  int kmod_elf_get_symbols(const struct kmod_elf *elf, struct kmod_modversion 
> **array)
>  {
> @@ -830,6 +855,7 @@ int kmod_elf_get_symbols(const struct kmod_elf *elf, 
> struct kmod_modversion **ar
> uint32_t name_off;
> uint64_t crc;
> uint8_t info, bind;
> +   uint16_t shndx;
>
>  #define READV(field)   \
> elf_get_uint(elf, sym_off + offsetof(typeof(*s), field),\
> @@ -839,11 +865,13 @@ int kmod_elf_get_symbols(const struct kmod_elf *elf, 
> struct kmod_modversion **ar
> name_off = READV(st_name);
> crc = READV(st_value);
> info = READV(st_info);
> +   shndx = READV(st_shndx);
> } else {
> Elf64_Sym *s;
> name_off = READV(st_name);
> crc = READV(st_value);
> info = READV(st_info);
> +   shndx = READV(st_shndx);
> }
>  #undef READV
> name = elf_get_mem(elf, str_off + name_off);
> @@ -856,7 +884,7 @@ int kmod_elf_get_symbols(const struct kmod_elf *elf, 
> struct kmod_modversion **ar
> else
> bind = ELF64_ST_BIND(info);
>
> -   a[count].crc = crc;
> +   a[count].crc = kmod_elf_resolve_crc(elf, crc, shndx);
> a[count].bind = kmod_symbol_bind_from_elf(bind);
> a[count].symbol = itr;
> slen = strlen(name);
> --

LGTM. I'll give this a try and apply.  Do you think it's possible to
build an out-of-tree module with this option so we can add one to the
testsuite?


Lucas De Marchi

Re: [PATCH v3 1/5] mm: add vm_insert_mixed_mkwrite()

[Ross Zwisler]

On Wed, Jul 19, 2017 at 04:16:59PM +0200, Jan Kara wrote:
> On Wed 28-06-17 16:01:48, Ross Zwisler wrote:
> > To be able to use the common 4k zero page in DAX we need to have our PTE
> > fault path look more like our PMD fault path where a PTE entry can be
> > marked as dirty and writeable as it is first inserted, rather than waiting
> > for a follow-up dax_pfn_mkwrite() => finish_mkwrite_fault() call.
> > 
> > Right now we can rely on having a dax_pfn_mkwrite() call because we can
> > distinguish between these two cases in do_wp_page():
> > 
> > case 1: 4k zero page => writable DAX storage
> > case 2: read-only DAX storage => writeable DAX storage
> > 
> > This distinction is made by via vm_normal_page().  vm_normal_page() returns
> > false for the common 4k zero page, though, just as it does for DAX ptes.
> > Instead of special casing the DAX + 4k zero page case, we will simplify our
> > DAX PTE page fault sequence so that it matches our DAX PMD sequence, and
> > get rid of dax_pfn_mkwrite() completely.
> > 
> > This means that insert_pfn() needs to follow the lead of insert_pfn_pmd()
> > and allow us to pass in a 'mkwrite' flag.  If 'mkwrite' is set insert_pfn()
> > will do the work that was previously done by wp_page_reuse() as part of the
> > dax_pfn_mkwrite() call path.
> > 
> > Signed-off-by: Ross Zwisler 
> 
> Just one small comment below.
> 
> > @@ -1658,14 +1658,26 @@ static int insert_pfn(struct vm_area_struct *vma, 
> > unsigned long addr,
> > if (!pte)
> > goto out;
> > retval = -EBUSY;
> > -   if (!pte_none(*pte))
> > -   goto out_unlock;
> > +   if (!pte_none(*pte)) {
> > +   if (mkwrite) {
> > +   entry = *pte;
> > +   goto out_mkwrite;
> 
> Can we maybe check here that (pte_pfn(*pte) == pfn_t_to_pfn(pfn)) and
> return -EBUSY otherwise? That way we are sure insert_pfn() isn't doing
> anything we don't expect 

Sure, that's fine.  I'll add it as a WARN_ON_ONCE() so it's a very loud
failure.  If the pfns don't match I think we're insane (and would have been
insane prior to this patch series as well) because we are getting a page fault
and somehow have a different PFN already mapped at that location.

> and if I understand the code right, we need to
> invalidate all zero page mappings at given file offset (via
> unmap_mapping_range()) before mapping an allocated block there and thus the
> case of filling the hole won't be affected by this?

Correct.  Here's the call tree if we already have a zero page mapped and are
now faulting in an allocated block:

dax_iomap_pte_fault()
  dax_insert_mapping()
dax_insert_mapping_entry()
  unmap_mapping_range() for our zero page
vm_insert_mixed_mkwrite() installs the new PTE. We have pte_none(), so we
skip the new mkwrite goto in insert_pfn().

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

[Tejun Heo]

Hello, Waiman.

On Wed, Jul 19, 2017 at 01:09:38PM -0400, Waiman Long wrote:
> For me, that is the only good reason why we should keep the current
> behavior. So I am fine with that.
> 
> + cgrp->dom_cgrp = cgrp->dom_cgrp;
> 
> However, I am still puzzled by above line of code, should it be just
> 
>   cgrp->dom_cgrp = cgrp;

Oh I see.  Yeah, that's just a silly (harmless) bug.  The field gets
properly initialized in init_cgroup_housekeeping().  I'll remove that
line.

Thanks!

-- 
tejun

Re: [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

[Colin Ian King]

On 19/07/17 18:32, Alexandre Belloni wrote:
> Hi,
> 
> On 19/07/2017 at 17:57:02 +0100, Colin King wrote:
>> From: Colin Ian King 
>>
>> There are two error return paths that do not kfree clk_data and
>> we end up with a memory leak. Fix these with a kfree error exit
>> path.
>>
>> Detected by CoverityScan, CID#1402959 ("Resource Leak")
>>
> 
> I think that patch fixes the same issue (and more):
> http://patchwork.ozlabs.org/patch/787151/

Yep, that's true.

> 
>> Signed-off-by: Colin Ian King 
>> ---
>>  drivers/rtc/rtc-sun6i.c | 8 ++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
>> index 39cbc1238b92..61502221ab6e 100644
>> --- a/drivers/rtc/rtc-sun6i.c
>> +++ b/drivers/rtc/rtc-sun6i.c
>> @@ -204,7 +204,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
>> *node)
>>  rtc->base = of_io_request_and_map(node, 0, of_node_full_name(node));
>>  if (IS_ERR(rtc->base)) {
>>  pr_crit("Can't map RTC registers");
>> -return;
>> +goto err;
>>  }
>>  
>>  /* Switch to the external, more precise, oscillator */
>> @@ -216,7 +216,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
>> *node)
>>  
>>  /* Deal with old DTs */
>>  if (!of_get_property(node, "clocks", NULL))
>> -return;
>> +goto err;
>>  
>>  rtc->int_osc = clk_hw_register_fixed_rate_with_accuracy(NULL,
>>  "rtc-int-osc",
>> @@ -246,6 +246,10 @@ static void __init sun6i_rtc_clk_init(struct 
>> device_node *node)
>>  clk_data->num = 1;
>>  clk_data->hws[0] = &rtc->hw;
>>  of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
>> +return;
>> +
>> +err:
>> +kfree(clk_data);
>>  }
>>  CLK_OF_DECLARE_DRIVER(sun6i_rtc_clk, "allwinner,sun6i-a31-rtc",
>>sun6i_rtc_clk_init);
>> -- 
>> 2.11.0
>>
> 

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

[Mohammed Gamal]

- Original Message -
> On Wed, 19 Jul 2017 15:19:28 +0200
> Mohammed Gamal  wrote:
> 
> > This condition already uses an object of type ipv6hdr in the line above.
> > Use the object directly instead of calling ipv6_hdr
> > 
> > Signed-off-by: Mohammed Gamal 
> > ---
> >  drivers/net/hyperv/netvsc_drv.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/hyperv/netvsc_drv.c
> > b/drivers/net/hyperv/netvsc_drv.c
> > index 63c98bb..06d591c 100644
> > --- a/drivers/net/hyperv/netvsc_drv.c
> > +++ b/drivers/net/hyperv/netvsc_drv.c
> > @@ -339,7 +339,7 @@ static u32 net_checksum_info(struct sk_buff *skb)
> >  
> > if (ip6->nexthdr == IPPROTO_TCP)
> > return TRANSPORT_INFO_IPV6_TCP;
> > -   else if (ipv6_hdr(skb)->nexthdr == IPPROTO_UDP)
> > +   else if (ip6->nexthdr == IPPROTO_UDP)
> > return TRANSPORT_INFO_IPV6_UDP;
> > }
> >  
> 
> Patch looks fine.
> Network patches go through net...@vger.kernel.org not linux driver mailing
> list.
> I will add it to my next patch of patches that are going to netdev for
> net-next.
> 
Thanks for the heads up. Will take that into consideration next time.

It's worth pointing out that MAINTAINERS points that files under 
drivers/net/hyperv are to be sent to de...@linuxdriverproject.org.
Perhaps that should be updated.

[PATCH] net: tehuti: don't process data if it has not been copied from userspace

[Colin King]

From: Colin Ian King 

The array data is only populated with valid information from userspace
if cmd != SIOCDEVPRIVATE, other cases the array contains garbage on
the stack. The subsequent switch statement acts on a subcommand in
data[0] which could be any garbage value if cmd is SIOCDEVPRIVATE which
seems incorrect to me.  Instead, just return EOPNOTSUPP for the case
where cmd == SIOCDEVPRIVATE to avoid this issue.

As a side note, I suspect that the original intention of the code
was for this ioctl to work just for cmd == SIOCDEVPRIVATE (and the
current logic is reversed). However, I don't wont to change the current
semantics in case any userspace code relies on this existing behaviour.

Detected by CoverityScan, CID#139647 ("Uninitialized scalar variable")

Signed-off-by: Colin Ian King 
---
 drivers/net/ethernet/tehuti/tehuti.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/tehuti/tehuti.c 
b/drivers/net/ethernet/tehuti/tehuti.c
index 711fbbbc4b1f..163d8d16bc24 100644
--- a/drivers/net/ethernet/tehuti/tehuti.c
+++ b/drivers/net/ethernet/tehuti/tehuti.c
@@ -654,6 +654,8 @@ static int bdx_ioctl_priv(struct net_device *ndev, struct 
ifreq *ifr, int cmd)
RET(-EFAULT);
}
DBG("%d 0x%x 0x%x\n", data[0], data[1], data[2]);
+   } else {
+   return -EOPNOTSUPP;
}
 
if (!capable(CAP_SYS_RAWIO))
-- 
2.11.0

Re: [PATCH] Revert "x86/uaccess: Add stack frame output operand in get_user() inline asm"

[Josh Poimboeuf]

On Thu, Jul 13, 2017 at 02:57:04PM -0700, Matthias Kaehlcke wrote:
> El Thu, Jul 13, 2017 at 04:34:06PM -0500 Josh Poimboeuf ha dit:
> 
> > On Thu, Jul 13, 2017 at 02:12:45PM -0700, Matthias Kaehlcke wrote:
> > > El Thu, Jul 13, 2017 at 03:34:16PM -0500 Josh Poimboeuf ha dit:
> > > > And yet another one to try (clobbering sp) :-)
> > > > 
> > > > diff --git a/arch/x86/include/asm/uaccess.h 
> > > > b/arch/x86/include/asm/uaccess.h
> > > > index 11433f9..21f0c39 100644
> > > > --- a/arch/x86/include/asm/uaccess.h
> > > > +++ b/arch/x86/include/asm/uaccess.h
> > > > @@ -166,12 +166,12 @@ __typeof__(__builtin_choose_expr(sizeof(x) > 
> > > > sizeof(0UL), 0ULL, 0UL))
> > > >  ({ 
> > > > \
> > > > int __ret_gu;   
> > > > \
> > > > register __inttype(*(ptr)) __val_gu asm("%"_ASM_DX);
> > > > \
> > > > -   register void *__sp asm(_ASM_SP);   
> > > > \
> > > > __chk_user_ptr(ptr);
> > > > \
> > > > might_fault();  
> > > > \
> > > > -   asm volatile("call __get_user_%P4"  
> > > > \
> > > > -: "=a" (__ret_gu), "=r" (__val_gu), "+r" (__sp)
> > > > \
> > > > -: "0" (ptr), "i" (sizeof(*(ptr;
> > > > \
> > > > +   asm volatile("call __get_user_%P3"  
> > > > \
> > > > +: "=a" (__ret_gu), "=r" (__val_gu) 
> > > > \
> > > > +: "0" (ptr), "i" (sizeof(*(ptr)))  
> > > > \
> > > > +: "sp");   
> > > > \
> > > > (x) = (__force __typeof__(*(ptr))) __val_gu;
> > > > \
> > > > __builtin_expect(__ret_gu, 0);  
> > > > \
> > > >  })
> > > 
> > > This compiles with both gcc and clang, clang does not corrupt the
> > > stack pointer. I wouldn't be able to tell though if it forces a stack
> > > frame if it doesn't already exist, as the original patch intends.
> > 
> > Whether it forces the stack frame on clang is a very minor issue
> > compared to the double fault.
> 
> I totally agree, I was mainly concerned about not breaking the
> solution that currently works with gcc.
> 
> > That really only matters when you want to use
> > CONFIG_STACK_VALIDATION to get 100% reliable stacktraces with frame
> > pointers.  And that feature is currently very GCC-specific.  So you
> > probably don't need to worry about that for now, at least until you want
> > to do live patching with a clang-compiled kernel.
> 
> Eventually I expect that there will be interest in live patching
> clang-compiled kernels, however at this stage it probably isn't an
> overly important feature.
> 
> > IIRC, clobbering SP does at least force the stack frame on GCC, though I
> > need to double check that.  I can try to work up an official patch in
> > the next week or so (need to do some testing first).
> 
> Sounds great.
> 
> Thanks again for looking into this and coming up with a solution!

After doing some testing, I don't think this approach is going to work
after all.  In addition to forcing the stack frame, it also causes GCC
to add an unnecessary extra instruction to the epilogue of each affected
function:

  lea-0x10(%rbp),%rsp

We shouldn't be inserting extra instructions like that.  I also don't
think the other suggestion of turning the '__sp' register variable into
a global variable is a very good solution either, as that just wastes
memory for no reason.

It would be nice if both compilers could agree on a way to support this.

-- 
Josh

Re: [PATCH] documentation: Fix two-CPU control-dependency example

[Paul E. McKenney]

On Mon, Jul 17, 2017 at 05:24:42PM +0900, Akira Yokosawa wrote:
> >From b798b9b631e237d285aa8699da00bfb8ced33bea Mon Sep 17 00:00:00 2001
> From: Akira Yokosawa 
> Date: Mon, 17 Jul 2017 16:25:33 +0900
> Subject: [PATCH] documentation: Fix two-CPU control-dependency example
> 
> In commit 5646f7acc95f ("memory-barriers: Fix control-ordering
> no-transitivity example"), the operator in "if" statement of
> the two-CPU example was modified from ">=" to ">".
> Now the example misses the point because there is no party
> who will modify "x" nor "y". So each CPU performs only the
> READ_ONCE().
> 
> The point of this example is to use control dependency for ordering,
> and the WRITE_ONCE() should always be executed.
> 
> So it was correct prior to the above mentioned commit. Partial
> revert of the commit (with context adjustments regarding other
> changes thereafter) restores the point.
> 
> Note that the three-CPU example demonstrating the lack of
> transitivity stands regardless of this partial revert.
> 
> Signed-off-by: Akira Yokosawa 

Hello, Akira,

You are quite right that many compilers would generate straightforward
code for the code fragment below, and in that case, the assertion could
never trigger due to either TSO or control dependencies, depending on
the architecture this was running on.

However, if the compiler was too smart for our good, it could figure
out that "x" and "y" only take on the values zero and one, so that
the "if" would always be taken.  At that point, the compiler could
simply ignore the "if" with the result shown below.

> ---
>  Documentation/memory-barriers.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/memory-barriers.txt 
> b/Documentation/memory-barriers.txt
> index c4ddfcd..c1ebe99 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -851,7 +851,7 @@ demonstrated by two related examples, with the initial 
> values of
>   CPU 0 CPU 1
>   ===   ===
>   r1 = READ_ONCE(x);r2 = READ_ONCE(y);
> - if (r1 > 0)   if (r2 > 0)
> + if (r1 >= 0)  if (r2 >= 0)
> WRITE_ONCE(y, 1); WRITE_ONCE(x, 1);
> 
>   assert(!(r1 == 1 && r2 == 1));

Original program:

CPU 0 CPU 1
===   ===
r1 = READ_ONCE(x);r2 = READ_ONCE(y);
if (r1 >= 0)  if (r2 >= 0)
  WRITE_ONCE(y, 1); WRITE_ONCE(x, 1);

assert(!(r1 == 1 && r2 == 1));

Enthusiastically optimized program:

CPU 0 CPU 1
===   ===
r1 = READ_ONCE(x);r2 = READ_ONCE(y);
WRITE_ONCE(y, 1); WRITE_ONCE(x, 1);

assert(!(r1 == 1 && r2 == 1));

This optimized version could trigger the assertion.

So we do need to stick with the ">" comparison.

That said, I very much welcome critical reviews of memory-barriers.txt,
so please do feel free to continue doing that!

Thanx, Paul

[PATCH 2/3] livepatch: add atomic replace

[Jason Baron]

When doing cumulative patches, if patch A introduces a change to function 1,
and patch B reverts the change to function 1 and introduces changes to say
function 2 and 3 as well, the change that patch A introduced to function 1
is still present.

Introduce atomic replace, by first creating a 'no_op' klp_func for all
the functions that are reverted by patch B. The reason that 'no_op'
klp_funcs are created, instead of just unregistering directly from the ftrace
function hook, is to ensure that the consistency model is properly preserved.
By introducing the 'no_op' functions, 'atomic revert' leverages the existing
consistency model code. Then, after transition to the new code, 'atomic
revert' unregisters the ftrace handlers that are associated with the 'no_op'
klp_funcs, such that that we run the original un-patched function with no
additional no_op function overhead.

Since 'atomic replace' has completely replaced any previous livepatch modules,
it explicitly disables the previous patch, in the example- patch A, such that
the livepatch module associated with patch A can be completely removed (rmmod).
Patch A is now in a permanently disabled state. But if patch A is removed from
the kernel with rmmod, it can be re-inserted (insmod), and act as an atomic
replace on top of patch B.

Signed-off-by: Jason Baron 
Cc: Josh Poimboeuf 
Cc: Jessica Yu 
Cc: Jiri Kosina 
Cc: Miroslav Benes 
Cc: Petr Mladek 
---
 include/linux/livepatch.h |   8 ++-
 kernel/livepatch/core.c   | 124 ++
 kernel/livepatch/core.h   |   4 ++
 kernel/livepatch/patch.c  |  14 +++--
 kernel/livepatch/patch.h  |   1 +
 kernel/livepatch/transition.c |  61 -
 6 files changed, 202 insertions(+), 10 deletions(-)

diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 5038337..6fd7222 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -49,6 +49,7 @@
  * @new_size:  size of the new function
  * @patched:   the func has been added to the klp_ops list
  * @transition:the func is currently being applied or reverted
+ * @no_op: this is a no_op function used to compelete revert a function
  *
  * The patched and transition variables define the func's patching state.  When
  * patching, a func is always in one of the following states:
@@ -86,6 +87,7 @@ struct klp_func {
unsigned long old_size, new_size;
bool patched;
bool transition;
+   bool no_op;
 };
 
 /**
@@ -132,6 +134,7 @@ struct klp_object {
  * @kobj:  kobject for sysfs resources
  * @obj_list:  head of list for dynamically allocated struct klp_object
  * @enabled:   the patch is enabled (but operation may be incomplete)
+ * @replaced:  the patch has been replaced an can not be re-enabled
  * @finish:for waiting till it is safe to remove the patch module
  */
 struct klp_patch {
@@ -145,6 +148,7 @@ struct klp_patch {
struct kobject kobj;
struct list_head obj_list;
bool enabled;
+   bool replaced;
struct completion finish;
 };
 
@@ -201,8 +205,8 @@ static inline struct klp_func *func_iter_next(struct 
func_iter *iter)
struct klp_func *func;
struct klp_func_no_op *func_no_op;
 
-   if (iter->func->old_name || iter->func->new_func ||
-   iter->func->old_sympos) {
+   if (iter->func && (iter->func->old_name || iter->func->new_func ||
+  iter->func->old_sympos)) {
func = iter->func;
iter->func++;
} else {
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index e63f478..bf353da 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -352,6 +352,9 @@ static int __klp_enable_patch(struct klp_patch *patch)
if (klp_transition_patch)
return -EBUSY;
 
+   if (patch->replaced)
+   return -EINVAL;
+
if (WARN_ON(patch->enabled))
return -EINVAL;
 
@@ -602,6 +605,118 @@ static void klp_free_patch(struct klp_patch *patch)
list_del(&patch->list);
 }
 
+void klp_patch_free_no_ops(struct klp_patch *patch)
+{
+   struct obj_iter o_iter;
+   struct func_iter f_iter;
+   struct klp_object *obj, *tmp_obj;
+   struct klp_func *func;
+   struct klp_func_no_op *func_no_op;
+
+   klp_for_each_object(patch, obj, &o_iter) {
+   klp_for_each_func(obj, func, &f_iter) {
+   if (func->no_op) {
+   func_no_op = container_of(func,
+ struct klp_func_no_op,
+ orig_func);
+   list_del_init(&func_no_op->func_entry);
+   kfree(func_no_op);
+   }
+   }
+   }
+   list_for_each_entry_safe(obj, tmp_obj, &patch->obj_list, obj_entry) 

Re: [PATCH] c6x: Convert to using %pOF instead of full_name

[Mark Salter]

On Tue, 2017-07-18 at 16:42 -0500, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
> 
> Signed-off-by: Rob Herring 
> Cc: Mark Salter 
> Cc: Aurelien Jacquiot 
> Cc: linux-c6x-...@linux-c6x.org
> ---
>  arch/c6x/platforms/megamod-pic.c | 22 +++---
>  arch/c6x/platforms/plldata.c |  4 ++--
>  arch/c6x/platforms/timer64.c |  8 
>  3 files changed, 17 insertions(+), 17 deletions(-)

For the c6x bits:
Acked-by: Mark Salter 

[PATCH] drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()

[Matthias Kaehlcke]

Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
transcoders") misses some pieces, due to a problem with the patch
format, this patch adds the remaining bits.

Fixes: a21960339c8c ("drm/i915: Consistently use enum pipe for PCH
transcoders")

Signed-off-by: Matthias Kaehlcke 
---
 drivers/gpu/drm/i915/intel_display.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a89d0fd1c2e1..5c7054c3be0e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5347,8 +5347,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
return;
 
if (intel_crtc->config->has_pch_encoder)
-   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
- false);
+   intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
 
intel_encoders_pre_pll_enable(crtc, pipe_config, old_state);
 
@@ -5433,8 +5432,7 @@ static void haswell_crtc_enable(struct intel_crtc_state 
*pipe_config,
intel_wait_for_vblank(dev_priv, pipe);
intel_wait_for_vblank(dev_priv, pipe);
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
-   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
- true);
+   intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
}
 
/* If we change the relative order between pipe/planes enabling, we need
@@ -5531,8 +5529,7 @@ static void haswell_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
 
if (intel_crtc->config->has_pch_encoder)
-   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
- false);
+   intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
 
intel_encoders_disable(crtc, old_crtc_state, old_state);
 
@@ -5560,8 +5557,7 @@ static void haswell_crtc_disable(struct intel_crtc_state 
*old_crtc_state,
intel_encoders_post_disable(crtc, old_crtc_state, old_state);
 
if (old_crtc_state->has_pch_encoder)
-   intel_set_pch_fifo_underrun_reporting(dev_priv, TRANSCODER_A,
- true);
+   intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
 }
 
 static void i9xx_pfit_enable(struct intel_crtc *crtc)
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH] fs: convert sync_file_range to use errseq_t based error-tracking

[Jeff Layton]

From: Jeff Layton 

sync_file_range doesn't call down into the filesystem directly at all.
It only kicks off writeback of pagecache pages and optionally waits
on the result.

Convert sync_file_range to use errseq_t based error tracking, under the
assumption that most users will prefer this behavior when errors occur.

Signed-off-by: Jeff Layton 
---
 fs/sync.c  |  4 ++--
 include/linux/fs.h |  2 ++
 mm/filemap.c   | 22 ++
 3 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/fs/sync.c b/fs/sync.c
index 2a54c1f22035..27d6b8bbcb6a 100644
--- a/fs/sync.c
+++ b/fs/sync.c
@@ -342,7 +342,7 @@ SYSCALL_DEFINE4(sync_file_range, int, fd, loff_t, offset, 
loff_t, nbytes,
 
ret = 0;
if (flags & SYNC_FILE_RANGE_WAIT_BEFORE) {
-   ret = filemap_fdatawait_range(mapping, offset, endbyte);
+   ret = file_fdatawait_range(f.file, offset, endbyte);
if (ret < 0)
goto out_put;
}
@@ -355,7 +355,7 @@ SYSCALL_DEFINE4(sync_file_range, int, fd, loff_t, offset, 
loff_t, nbytes,
}
 
if (flags & SYNC_FILE_RANGE_WAIT_AFTER)
-   ret = filemap_fdatawait_range(mapping, offset, endbyte);
+   ret = file_fdatawait_range(f.file, offset, endbyte);
 
 out_put:
fdput(f);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 7b5d6816542b..fb615e1eb1d4 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2544,6 +2544,8 @@ extern int filemap_fdatawait_range(struct address_space 
*, loff_t lstart,
   loff_t lend);
 extern bool filemap_range_has_page(struct address_space *, loff_t lstart,
  loff_t lend);
+extern int __must_check file_fdatawait_range(struct file *file, loff_t lstart,
+   loff_t lend);
 extern int filemap_write_and_wait(struct address_space *mapping);
 extern int filemap_write_and_wait_range(struct address_space *mapping,
loff_t lstart, loff_t lend);
diff --git a/mm/filemap.c b/mm/filemap.c
index a49702445ce0..bb17590d7c67 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -476,6 +476,28 @@ int filemap_fdatawait_range(struct address_space *mapping, 
loff_t start_byte,
 EXPORT_SYMBOL(filemap_fdatawait_range);
 
 /**
+ * file_fdatawait_range - wait for writeback to complete
+ * @file:  file pointing to address space structure to wait for
+ * @start_byte:offset in bytes where the range starts
+ * @end_byte:  offset in bytes where the range ends (inclusive)
+ *
+ * Walk the list of under-writeback pages of the address space that file
+ * refers to, in the given range and wait for all of them.  Check error
+ * status of the address space vs. the file->f_wb_err cursor and return it.
+ *
+ * Since the error status of the file is advanced by this function,
+ * callers are responsible for checking the return value and handling and/or
+ * reporting the error.
+ */
+int file_fdatawait_range(struct file *file, loff_t start_byte, loff_t end_byte)
+{
+   struct address_space *mapping = file->f_mapping;
+
+   __filemap_fdatawait_range(mapping, start_byte, end_byte);
+   return file_check_and_advance_wb_err(file);
+}
+
+/**
  * filemap_fdatawait_keep_errors - wait for writeback without clearing errors
  * @mapping: address space structure to wait for
  *
-- 
2.13.3

Re: [PATCH 095/102] watchdog: rt2880: explicitly request exclusive reset control

[Guenter Roeck]

On Wed, Jul 19, 2017 at 05:26:39PM +0200, Philipp Zabel wrote:
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
> 
> No functional changes.
> 
> Cc: Wim Van Sebroeck 
> Cc: Guenter Roeck 
> Cc: linux-watch...@vger.kernel.org
> Signed-off-by: Philipp Zabel 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/rt2880_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/rt2880_wdt.c b/drivers/watchdog/rt2880_wdt.c
> index 05524baf7dccb..0d481a63cab14 100644
> --- a/drivers/watchdog/rt2880_wdt.c
> +++ b/drivers/watchdog/rt2880_wdt.c
> @@ -152,7 +152,7 @@ static int rt288x_wdt_probe(struct platform_device *pdev)
>   if (IS_ERR(rt288x_wdt_clk))
>   return PTR_ERR(rt288x_wdt_clk);
>  
> - rt288x_wdt_reset = devm_reset_control_get(&pdev->dev, NULL);
> + rt288x_wdt_reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
>   if (!IS_ERR(rt288x_wdt_reset))
>   reset_control_deassert(rt288x_wdt_reset);
>  
> -- 
> 2.11.0
> 

Re: [PATCH 096/102] watchdog: zx2967: explicitly request exclusive reset control

[Guenter Roeck]

On Wed, Jul 19, 2017 at 05:26:40PM +0200, Philipp Zabel wrote:
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
> 
> No functional changes.
> 
> Cc: Wim Van Sebroeck 
> Cc: Guenter Roeck 
> Cc: linux-watch...@vger.kernel.org
> Signed-off-by: Philipp Zabel 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/zx2967_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
> index 69ec5855584b1..9261f7c77f6de 100644
> --- a/drivers/watchdog/zx2967_wdt.c
> +++ b/drivers/watchdog/zx2967_wdt.c
> @@ -229,7 +229,7 @@ static int zx2967_wdt_probe(struct platform_device *pdev)
>   }
>   clk_set_rate(wdt->clock, ZX2967_WDT_CLK_FREQ);
>  
> - rstc = devm_reset_control_get(dev, NULL);
> + rstc = devm_reset_control_get_exclusive(dev, NULL);
>   if (IS_ERR(rstc)) {
>   dev_err(dev, "failed to get rstc");
>   ret = PTR_ERR(rstc);
> -- 
> 2.11.0
> 

Re: [PATCH 094/102] watchdog: mt7621: explicitly request exclusive reset control

[Guenter Roeck]

On Wed, Jul 19, 2017 at 05:26:38PM +0200, Philipp Zabel wrote:
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
> 
> No functional changes.
> 
> Cc: Wim Van Sebroeck 
> Cc: Guenter Roeck 
> Cc: linux-watch...@vger.kernel.org
> Signed-off-by: Philipp Zabel 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/mt7621_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/mt7621_wdt.c b/drivers/watchdog/mt7621_wdt.c
> index 48a06067075d5..f6f4c1bf24c95 100644
> --- a/drivers/watchdog/mt7621_wdt.c
> +++ b/drivers/watchdog/mt7621_wdt.c
> @@ -135,7 +135,7 @@ static int mt7621_wdt_probe(struct platform_device *pdev)
>   if (IS_ERR(mt7621_wdt_base))
>   return PTR_ERR(mt7621_wdt_base);
>  
> - mt7621_wdt_reset = devm_reset_control_get(&pdev->dev, NULL);
> + mt7621_wdt_reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
>   if (!IS_ERR(mt7621_wdt_reset))
>   reset_control_deassert(mt7621_wdt_reset);
>  
> -- 
> 2.11.0
> 

Re: [PATCH 093/102] watchdog: asm9260: explicitly request exclusive reset control

[Guenter Roeck]

On Wed, Jul 19, 2017 at 05:26:37PM +0200, Philipp Zabel wrote:
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
> 
> No functional changes.
> 
> Cc: Wim Van Sebroeck 
> Cc: Guenter Roeck 
> Cc: linux-watch...@vger.kernel.org
> Signed-off-by: Philipp Zabel 

Reviewed-by: Guenter Roeck 

> ---
>  drivers/watchdog/asm9260_wdt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/watchdog/asm9260_wdt.c b/drivers/watchdog/asm9260_wdt.c
> index 53da001f0838e..186fac4cccf5a 100644
> --- a/drivers/watchdog/asm9260_wdt.c
> +++ b/drivers/watchdog/asm9260_wdt.c
> @@ -296,7 +296,7 @@ static int asm9260_wdt_probe(struct platform_device *pdev)
>   if (ret)
>   return ret;
>  
> - priv->rst = devm_reset_control_get(&pdev->dev, "wdt_rst");
> + priv->rst = devm_reset_control_get_exclusive(&pdev->dev, "wdt_rst");
>   if (IS_ERR(priv->rst))
>   return PTR_ERR(priv->rst);
>  
> -- 
> 2.11.0
> 

Re: [PATCH v2 9/9] perf annotate: Use the sample period when calculating the percentage

[Taeung Song]

On 07/19/2017 01:23 AM, Namhyung Kim wrote:

On Fri, Jul 14, 2017 at 02:46:20AM +0900, Taeung Song wrote:

Currently the percentages of perf-annotate are calculated
with number of samples, not the sample period.
So fix it to correspond with perf-report using the sample period
for the calculation.


Not sure someone still wants the old behavior.  Maybe it'd be better
to honor --show-nr-samples option.




You mean that if users use --show-nr-samples option,
we can calculate the percent values with number of samples, right ?



Cc: Namhyung Kim 
Cc: Jiri Olsa 
Signed-off-by: Taeung Song 
---
  tools/perf/util/annotate.c | 11 ++-
  1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index d9bdedf..28a6d11 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -988,7 +988,7 @@ double disasm__calc_percent(struct annotation *notes, int 
evidx, s64 offset,
if (h->total_samples) {


It seems checking total_period here is clearer and safer.  But I guess
it would have same effect 99.9% but still..




I got it.



sample->nr_samples = hits;
sample->period = p;
-   percent = 100.0 * hits / h->total_samples;
+   percent = 100.0 * p / h->total_period;
}
}
  
@@ -1730,8 +1730,9 @@ static int symbol__get_source_line(struct symbol *sym, struct map *map,

start = map__rip_2objdump(map, sym->start);
  
  	for (i = 0; i < len; i++) {

-   u64 offset, nr_samples;
+   u64 offset;
double percent_max = 0.0;
+   struct sym_hist_entry sample;
  
  		src_line->nr_pcnt = nr_pcnt;
  
@@ -1739,15 +1740,15 @@ static int symbol__get_source_line(struct symbol *sym, struct map *map,

double percent = 0.0;
  
  			h = annotation__histogram(notes, evidx + k);

-   nr_samples = h->addr[i].nr_samples;
+   sample = h->addr[i];
  
  			if (h->total_samples)


Ditto.

Thanks,
Namhyung




ok

Thanks,
Taeung


-   percent = 100.0 * nr_samples / h->total_samples;
+   percent = 100.0 * sample.period / 
h->total_period;
  
  			if (percent > percent_max)

percent_max = percent;
src_line->samples[k].percent = percent;
-   src_line->samples[k].nr = nr_samples;
+   src_line->samples[k].nr = sample.nr_samples;
}
  
  		if (percent_max <= 0.5)

--
2.7.4

[PATCH 0/3] livepatch: introduce atomic replace

[Jason Baron]

Hi,

In testing livepatch, I found that when doing cumulative patches, if a patched
function is completed reverted by a subsequent patch (back to its original 
state)
livepatch does not revert the funtion to its original state. Specifically, if
patch A introduces a change to function 1, and patch B reverts the change to
function 1 and introduces changes to say function 2 and 3 as well, the change
that patch A introducd to function 1 is still present. This could be addressed
by first completely removing patch A (disable and then rmmod) and then inserting
patch B (insmod and enable), but this leaves an unpatched window. In discussing
this issue with Josh on the kpatch mailing list, he mentioned that we could get
'atomic replace working properly', and that is the direction of this patchset:
https://www.redhat.com/archives/kpatch/2017-June/msg5.html

Patches:

1) livepatch: Add klp_object and klp_func iterators
Just a prep patch for the 'atomic revert' feature

2) livepatch: add atomic replace
Core feature

3) livepatch: Add a sysctl livepatch_mode for atomic replace
Introduces a knob for enabling atomic replace. I hate knobs and perhaps
its possible to default to cumulative replace? Although I suspect there
are workflows relying on the existing behavior - I'm not sure. It may
be desirable to associate the knob with the patch itself as in the
'immediate' flag, such that we don't introduce a global sysctl that
likely would also need to built-in, if there are patches in the initrd.

Thanks,

-Jason

Jason Baron (3):
  livepatch: Add klp_object and klp_func iterators
  livepatch: add atomic replace
  livepatch: Add a sysctl livepatch_mode for atomic revert

 include/linux/livepatch.h | 118 ++--
 kernel/livepatch/core.c   | 154 --
 kernel/livepatch/core.h   |   4 ++
 kernel/livepatch/patch.c  |  23 ---
 kernel/livepatch/patch.h  |   1 +
 kernel/livepatch/transition.c |  79 +++---
 kernel/sysctl.c   |  12 
 7 files changed, 362 insertions(+), 29 deletions(-)

-- 
2.6.1

[PATCH 3/3] livepatch: Add a sysctl livepatch_mode for atomic replace

[Jason Baron]

Introduce a sysctl knob such that by default livepatch is not in
'atomic replace' mode. A '0' in /proc/sys/kernel/livepatch_mode means the
current default mode, while a '1' means do atomic replace.

Signed-off-by: Jason Baron 
Cc: Josh Poimboeuf 
Cc: Jessica Yu 
Cc: Jiri Kosina 
Cc: Miroslav Benes 
Cc: Petr Mladek 
---
 include/linux/livepatch.h |  8 
 kernel/livepatch/core.c   |  5 +
 kernel/sysctl.c   | 12 
 3 files changed, 25 insertions(+)

diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 6fd7222..08e760a 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -35,6 +35,14 @@
 #define KLP_UNPATCHED   0
 #define KLP_PATCHED 1
 
+/* livepatch mode */
+
+extern int sysctl_livepatch_mode;
+enum {
+   LIVEPATCH_MODE_DEFAULT,
+   LIVEPATCH_MODE_REPLACE,
+};
+
 /**
  * struct klp_func - function structure for live patching
  * @old_name:  name of the function to be patched
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index bf353da..b1df5c4 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -49,6 +49,8 @@ static LIST_HEAD(klp_patches);
 
 static struct kobject *klp_root_kobj;
 
+int sysctl_livepatch_mode;
+
 static bool klp_is_module(struct klp_object *obj)
 {
return obj->name;
@@ -643,6 +645,9 @@ static int klp_init_patch_no_ops(struct klp_patch *patch)
if (patch->list.prev == &klp_patches)
return 0;
 
+   if (sysctl_livepatch_mode != LIVEPATCH_MODE_REPLACE)
+   return 0;
+
prev_patch = list_prev_entry(patch, list);
klp_for_each_object(prev_patch, prev_obj, &prev_o_iter) {
if (!klp_is_object_loaded(prev_obj))
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 4dfba1a..3a0a1f6 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -67,6 +67,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1203,6 +1204,17 @@ static struct ctl_table kern_table[] = {
.extra2 = &one,
},
 #endif
+#ifdef CONFIG_LIVEPATCH
+   {
+   .procname   = "livepatch_mode",
+   .data   = &sysctl_livepatch_mode,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = proc_dointvec_minmax,
+   .extra1 = &zero,
+   .extra2 = &one,
+   },
+#endif
{ }
 };
 
-- 
2.6.1

Re: [PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

[Alexandre Belloni]

Hi,

On 19/07/2017 at 17:57:02 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> There are two error return paths that do not kfree clk_data and
> we end up with a memory leak. Fix these with a kfree error exit
> path.
> 
> Detected by CoverityScan, CID#1402959 ("Resource Leak")
> 

I think that patch fixes the same issue (and more):
http://patchwork.ozlabs.org/patch/787151/

> Signed-off-by: Colin Ian King 
> ---
>  drivers/rtc/rtc-sun6i.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
> index 39cbc1238b92..61502221ab6e 100644
> --- a/drivers/rtc/rtc-sun6i.c
> +++ b/drivers/rtc/rtc-sun6i.c
> @@ -204,7 +204,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
> *node)
>   rtc->base = of_io_request_and_map(node, 0, of_node_full_name(node));
>   if (IS_ERR(rtc->base)) {
>   pr_crit("Can't map RTC registers");
> - return;
> + goto err;
>   }
>  
>   /* Switch to the external, more precise, oscillator */
> @@ -216,7 +216,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
> *node)
>  
>   /* Deal with old DTs */
>   if (!of_get_property(node, "clocks", NULL))
> - return;
> + goto err;
>  
>   rtc->int_osc = clk_hw_register_fixed_rate_with_accuracy(NULL,
>   "rtc-int-osc",
> @@ -246,6 +246,10 @@ static void __init sun6i_rtc_clk_init(struct device_node 
> *node)
>   clk_data->num = 1;
>   clk_data->hws[0] = &rtc->hw;
>   of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
> + return;
> +
> +err:
> + kfree(clk_data);
>  }
>  CLK_OF_DECLARE_DRIVER(sun6i_rtc_clk, "allwinner,sun6i-a31-rtc",
> sun6i_rtc_clk_init);
> -- 
> 2.11.0
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH 7/7] staging: fsl-mc: allow the driver compile multi-arch

[kbuild test robot]

Hi Laurentiu,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.13-rc1 next-20170718]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/laurentiu-tudor-nxp-com/staging-fsl-mc-make-the-driver-compile-on-other-architectures/20170718-021715
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc 

All error/warnings (new ones prefixed by >>):

   In file included from kernel/irq/chip.c:14:0:
>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
 msi_alloc_info_t *arg);
 ^~~~
   include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
msi_alloc_info_t *arg);
^~~~
   include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
   msi_alloc_info_t *arg);
   ^~~~
   include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
 void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
 ^~~~
   include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
 void  (*set_desc)(msi_alloc_info_t *arg,
   ^~~~
   include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
   int nvec, msi_alloc_info_t *args);
 ^~~~
   include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
int virq, int nvec, msi_alloc_info_t *args);
^~~~
--
   In file included from kernel/irq/msi.c:16:0:
>> include/linux/msi.h:225:10: error: unknown type name 'msi_alloc_info_t'
 msi_alloc_info_t *arg);
 ^~~~
   include/linux/msi.h:229:9: error: unknown type name 'msi_alloc_info_t'
msi_alloc_info_t *arg);
^~~~
   include/linux/msi.h:238:12: error: unknown type name 'msi_alloc_info_t'
   msi_alloc_info_t *arg);
   ^~~~
   include/linux/msi.h:239:22: error: unknown type name 'msi_alloc_info_t'
 void  (*msi_finish)(msi_alloc_info_t *arg, int retval);
 ^~~~
   include/linux/msi.h:240:20: error: unknown type name 'msi_alloc_info_t'
 void  (*set_desc)(msi_alloc_info_t *arg,
   ^~~~
   include/linux/msi.h:308:18: error: unknown type name 'msi_alloc_info_t'
   int nvec, msi_alloc_info_t *args);
 ^~~~
   include/linux/msi.h:310:29: error: unknown type name 'msi_alloc_info_t'
int virq, int nvec, msi_alloc_info_t *args);
^~~~
   kernel/irq/msi.c: In function 'msi_domain_alloc':
>> kernel/irq/msi.c:126:29: error: 'struct msi_domain_ops' has no member named 
>> 'get_hwirq'
 irq_hw_number_t hwirq = ops->get_hwirq(info, arg);
^~
>> kernel/irq/msi.c:139:12: error: 'struct msi_domain_ops' has no member named 
>> 'msi_init'; did you mean 'msi_free'?
  ret = ops->msi_init(domain, info, virq + i, hwirq + i, arg);
   ^~
   kernel/irq/msi.c: At top level:
>> kernel/irq/msi.c:201:11: error: unknown type name 'msi_alloc_info_t'
  msi_alloc_info_t *arg)
  ^~~~
>> kernel/irq/msi.c:221:2: error: unknown field 'get_hwirq' specified in 
>> initializer
 .get_hwirq = msi_domain_ops_get_hwirq,
 ^
>> kernel/irq/msi.c:222:2: error: unknown field 'msi_init' specified in 
>> initializer
 .msi_init = msi_domain_ops_init,
 ^
>> kernel/irq/msi.c:222:14: error: 'msi_domain_ops_init' undeclared here (not 
>> in a function)
 .msi_init = msi_domain_ops_init,
 ^~~
>> kernel/irq/msi.c:224:2: error: unknown field 'msi_prepare' specified in 
>> initializer
 .msi_prepare = msi_domain_ops_prepare,
 ^
>> kernel/irq/msi.c:225:2: error: unknown field 'set_desc' specified in 
>> initializer
 .set_desc = msi_domain_ops_set_desc,
 ^
   In file included from include/uapi/linux/posix_types.h:4:0,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from kernel/irq/msi.c:12:
   include/linux/stddef.h:7:14: warning: excess elements in struct initializer
#define NULL ((void *)0)
 ^
>> kernel/irq/msi.c:195:34: note: in expansion of macro 'NULL'
#define msi_domain_ops_set_desc  NULL
 ^~~~
>> kernel/irq/msi.c:225:14: note: in expansion of macro 
>> 'msi_domain_ops_set_desc

[PATCH 1/3] livepatch: Add klp_object and klp_func iterators

[Jason Baron]

In preparation to introducing atomic replace, introduce iterators for klp_func
and klp_object, such that objects and functions can be dynmically allocated
(needed for atomic replace). Note that this patch is careful, not to grow the
size of klp_func as that's the most common data structure. This patch is
intended to effectively be a no-op until atomic replace is introduced.

Signed-off-by: Jason Baron 
Cc: Josh Poimboeuf 
Cc: Jessica Yu 
Cc: Jiri Kosina 
Cc: Miroslav Benes 
Cc: Petr Mladek 
---
 include/linux/livepatch.h | 106 --
 kernel/livepatch/core.c   |  25 +++---
 kernel/livepatch/patch.c  |   9 ++--
 kernel/livepatch/transition.c |  18 ---
 4 files changed, 137 insertions(+), 21 deletions(-)

diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
index 194991e..5038337 100644
--- a/include/linux/livepatch.h
+++ b/include/linux/livepatch.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if IS_ENABLED(CONFIG_LIVEPATCH)
 
@@ -88,10 +89,23 @@ struct klp_func {
 };
 
 /**
+ * struct klp_func_no_op - internal object used to link no_op functions, which
+  avoids the need to bloat struct klp_func
+ * @orig_func: embeds struct klp_func
+ * @func_entry:used link struct klp_func_no_op to struct klp_object
+ */
+struct klp_func_no_op {
+   struct klp_func orig_func;
+   struct list_head func_entry;
+};
+
+/**
  * struct klp_object - kernel object structure for live patching
  * @name:  module name (or NULL for vmlinux)
  * @funcs: function entries for functions to be patched in the object
  * @kobj:  kobject for sysfs resources
+ * @func_list: head of list for struct klp_func_no_op
+ * @obj_entry: used to link struct klp_object to struct klp_patch
  * @mod:   kernel module associated with the patched object
  * (NULL for vmlinux)
  * @patched:   the object's funcs have been added to the klp_ops list
@@ -103,6 +117,8 @@ struct klp_object {
 
/* internal */
struct kobject kobj;
+   struct list_head func_list;
+   struct list_head obj_entry;
struct module *mod;
bool patched;
 };
@@ -114,6 +130,7 @@ struct klp_object {
  * @immediate:  patch all funcs immediately, bypassing safety mechanisms
  * @list:  list node for global list of registered patches
  * @kobj:  kobject for sysfs resources
+ * @obj_list:  head of list for dynamically allocated struct klp_object
  * @enabled:   the patch is enabled (but operation may be incomplete)
  * @finish:for waiting till it is safe to remove the patch module
  */
@@ -126,17 +143,96 @@ struct klp_patch {
/* internal */
struct list_head list;
struct kobject kobj;
+   struct list_head obj_list;
bool enabled;
struct completion finish;
 };
 
-#define klp_for_each_object(patch, obj) \
+struct obj_iter {
+   struct klp_object *obj;
+   struct list_head *obj_list_head;
+   struct list_head *obj_list_pos;
+};
+
+static inline struct klp_object *obj_iter_next(struct obj_iter *iter)
+{
+   struct klp_object *obj;
+
+   if (iter->obj->funcs || iter->obj->name) {
+   obj = iter->obj;
+   iter->obj++;
+   } else {
+   if (iter->obj_list_pos == iter->obj_list_head) {
+   obj = NULL;
+   } else {
+   obj = list_entry(iter->obj_list_pos, struct klp_object,
+obj_entry);
+   iter->obj_list_pos = iter->obj_list_pos->next;
+   }
+   }
+
+   return obj;
+}
+
+static inline struct klp_object *obj_iter_init(struct klp_patch *patch,
+  struct obj_iter *iter)
+{
+   iter->obj = patch->objs;
+   iter->obj_list_head = &patch->obj_list;
+   iter->obj_list_pos = iter->obj_list_head->next;
+
+   return obj_iter_next(iter);
+}
+
+#define klp_for_each_object(patch, obj, iter) \
+   for (obj = obj_iter_init(patch, iter); obj; obj = obj_iter_next(iter))
+
+#define klp_for_each_object_core(patch, obj) \
for (obj = patch->objs; obj->funcs || obj->name; obj++)
 
-#define klp_for_each_func(obj, func) \
-   for (func = obj->funcs; \
-func->old_name || func->new_func || func->old_sympos; \
-func++)
+struct func_iter {
+   struct klp_func *func;
+   struct list_head *func_list_head;
+   struct list_head *func_list_pos;
+};
+
+static inline struct klp_func *func_iter_next(struct func_iter *iter)
+{
+   struct klp_func *func;
+   struct klp_func_no_op *func_no_op;
+
+   if (iter->func->old_name || iter->func->new_func ||
+   iter->func->old_sympos) {
+   func = iter->func;
+   iter->func++;
+   } else {
+   if (iter->func_list_pos == iter->func_list_head) {
+   func 

Re: [PATCH v2 1/2] video/hdmi: Introduce helpers for the HDMI audio infoframe payload

[Doug Anderson]

Hi

On Tue, Jul 18, 2017 at 5:49 PM, Chris Zhong  wrote:
> Hi Doug
>
>
>
> On Tuesday, July 18, 2017 11:16 PM, Doug Anderson wrote:
>>
>> Hi,
>>
>> On Tue, Jul 18, 2017 at 4:20 AM, Chris Zhong  wrote:
>>>
>>> The DP is using the same audio infoframe payload as hdmi, per DP 1.3
>>> spec, but it has a different header. Provide a new interface here,
>>> it just packs the payload.
>>>
>>> Signed-off-by: Chris Zhong 
>>> ---
>>>
>>> Changes in v2: None
>>>
>>>   drivers/video/hdmi.c | 66
>>> ++--
>>>   include/linux/hdmi.h |  3 ++-
>>>   2 files changed, 50 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
>>> index 1cf907e..e0b041e 100644
>>> --- a/drivers/video/hdmi.c
>>> +++ b/drivers/video/hdmi.c
>>> @@ -240,6 +240,49 @@ int hdmi_audio_infoframe_init(struct
>>> hdmi_audio_infoframe *frame)
>>>   EXPORT_SYMBOL(hdmi_audio_infoframe_init);
>>>
>>>   /**
>>> + * hdmi_audio_infoframe_pack_payload() - write HDMI audio infoframe
>>> payload to
>>> + * binary buffer
>>> + * @frame: HDMI audio infoframe
>>> + * @buffer: destination buffer
>>> + * @size: size of buffer
>>> + *
>>> + * Packs the information contained in the @frame structure into a binary
>>> + * representation that can be written into the corresponding controller
>>> + * registers.
>>> + *
>>> + * Returns 0 on success or a negative error code on failure.
>>> + */
>>> +ssize_t hdmi_audio_infoframe_pack_payload(struct hdmi_audio_infoframe
>>> *frame,
>>> + void *buffer, size_t size)
>>> +{
>>> +   unsigned char channels;
>>> +   u8 *ptr = buffer;
>>> +
>>> +   if (size < frame->length)
>>
>> You also need to return -ENOSPC if (size < 5).  That's because below
>> you always write 5 elements into this array.  I'll leave it to someone
>> with actual DRM experience to say whether they want a #define of some
>> sort here.  Probably they do since someone made a #define for
>> "HDMI_INFOFRAME_HEADER_SIZE".
>>
>> Also: you don't use frame->length anywhere in this function and it
>> doesn't seem to be related with packing the payload.  Seems like you
>> shouldn't check it here.
>
> Actually, I think it should be "if (size < HDMI_AUDIO_INFOFRAME_SIZE)"

Ah, OK.  My main point was that this function needed to make sense on
its own.  ...and the function in your patch writes to [0] through [4]
without actually confirming that there are at least 5 elements.  I'd
be OK with:

  if ((size < frame->length || size < HDMI_AUDIO_INFOFRAME_SIZE)


>>> +   return -ENOSPC;
>>> +
>>> +   memset(buffer, 0, size);
>>
>> I don't think the memset belongs here.  It seems like all this
>> function is doing is setting up ptr[0] through ptr[4] and the memset()
>> doesn't belong with that, does it?
>>
> I think the length of payload is 10 Bytes(DB1~DB10), per audio infoframe
> Format,
> but we only use the front 5 Bytes, the back 5 bytes must be 0. If we take
> the 10
> bytes as a whole, it make sense.

OK, memset() here makes sense with what you say about the frame
needing to be 10 bytes big.

-Doug

[PATCH] drm: disable vblank only if it got previously enabled

[Tobias Klausmann]

mimic the behavior of vblank_disable_fn(), another caller of
drm_vblank_disable_and_save().

This avoids oopsing, while trying to disable vblank on a not connected display:

[   12.768079] WARNING: CPU: 0 PID: 274 at drivers/gpu/drm/drm_vblank.c:609 
drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm]
[   12.768080] Modules linked in: bnep snd_hda_codec_hdmi rtsx_usb_sdmmc 
uvcvideo rtsx_usb_ms mmc_core videobuf2_vmalloc memstick videobuf2_memops 
videobuf2_v4l2 videobuf2_core rtsx_usb videodev btusb btrtl arc4 
snd_hda_codec_realtek snd_hda_codec_generic joydev nls_iso8859_1 hid_multitouch 
nls_cp437 intel_rapl x86_pkg_temp_thermal intel_powerclamp vfat coretemp fat 
kvm_intel iTCO_wdt iTCO_vendor_support kvm irqbypass crct10dif_pclmul 
crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel ath10k_pci 
snd_hda_intel ath10k_core aes_x86_64 snd_hda_codec crypto_simd ath glue_helper 
cryptd snd_hda_core mac80211 snd_hwdep snd_pcm pcspkr r8169 cfg80211 mii 
snd_timer acer_wmi snd sparse_keymap wmi_bmof idma64 hci_uart virt_dma mei_me 
soundcore i2c_i801 mei btbcm shpchp intel_lpss_pci intel_pch_thermal
[   12.768130]  serdev btqca ucsi_acpi btintel typec_ucsi thermal typec 
bluetooth ecdh_generic battery ac pinctrl_sunrisepoint rfkill intel_lpss_acpi 
pinctrl_intel intel_lpss acpi_pad nouveau serio_raw i915 mxm_wmi ttm 
i2c_algo_bit drm_kms_helper xhci_pci syscopyarea sysfillrect sysimgblt xhci_hcd 
fb_sys_fops usbcore drm i2c_hid wmi video button sg efivarfs
[   12.768158] CPU: 0 PID: 274 Comm: kworker/0:2 Not tainted 
4.12.0-desktop-debug-drm+ #2
[   12.768160] Hardware name: Acer Aspire VN7-593G/Pluto_KLS, BIOS V1.04 
03/30/2017
[   12.768164] Workqueue: pm pm_runtime_work
[   12.768166] task: 889bf1627040 task.stack: 9541013e4000
[   12.768180] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x296/0x320 [drm]
[   12.768181] RSP: 0018:9541013e7b30 EFLAGS: 00010086
[   12.768183] RAX: 001c RBX: 889b4cebd000 RCX: 0004
[   12.768184] RDX: 8004 RSI: 87a2d952 RDI: 
[   12.768186] RBP: 9541013e7b90 R08: 0001 R09: 039f
[   12.768187] R10: c05fe530 R11:  R12: 
[   12.768188] R13: 9541013e7ba4 R14: 889bf0426088 R15: 889bf0426000
[   12.768190] FS:  () GS:889bfec0() 
knlGS:
[   12.768191] CS:  0010 DS:  ES:  CR0: 80050033
[   12.768192] CR2: 00edb16580b8 CR3: 00020cc09000 CR4: 003406f0
[   12.768193] Call Trace:
[   12.768198]  ? enqueue_task_fair+0x64/0x600
[   12.768211]  ? drm_get_last_vbltimestamp+0x47/0x70 [drm]
[   12.768223]  ? drm_update_vblank_count+0x65/0x240 [drm]
[   12.768227]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768238]  ? drm_vblank_disable_and_save+0x55/0xc0 [drm]
[   12.768250]  ? drm_crtc_vblank_off+0xa9/0x1e0 [drm]
[   12.768253]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768299]  ? nouveau_display_fini+0x56/0xd0 [nouveau]
[   12.768339]  ? nouveau_display_suspend+0x51/0x110 [nouveau]
[   12.768378]  ? nouveau_do_suspend+0x76/0x1c0 [nouveau]
[   12.768413]  ? nouveau_pmops_runtime_suspend+0x54/0xb0 [nouveau]
[   12.768416]  ? pci_pm_runtime_suspend+0x5c/0x160
[   12.768419]  ? __rpm_callback+0xb6/0x1e0
[   12.768423]  ? kobject_uevent_env+0x111/0x5e0
[   12.768425]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768427]  ? rpm_callback+0x1f/0x70
[   12.768429]  ? pci_pm_runtime_resume+0xa0/0xa0
[   12.768431]  ? rpm_suspend+0x11f/0x640
[   12.768441]  ? drm_fb_helper_hotplug_event+0x9a/0xe0 [drm_kms_helper]
[   12.768447]  ? output_poll_execute+0x17b/0x1a0 [drm_kms_helper]
[   12.768449]  ? pm_runtime_work+0x64/0xa0
[   12.768453]  ? process_one_work+0x1db/0x410
[   12.768456]  ? worker_thread+0x47/0x3d0
[   12.768459]  ? process_one_work+0x410/0x410
[   12.768461]  ? kthread+0x117/0x130
[   12.768463]  ? kthread_create_on_node+0x40/0x40
[   12.768466]  ? ret_from_fork+0x25/0x30
[   12.768468] Code: 80 3d 26 f3 01 00 00 0f 85 ad fd ff ff 48 8b 43 20 48 c7 
c7 31 a2 20 c0 c6 05 0e f3 01 00 01 48 8b b0 60 01 00 00 e8 75 2e ec c6 <0f> ff 
e9 88 fd ff ff 31 f6 44 88 55 b0 e8 38 fa ed c6 44 0f b6
[   12.768508] ---[ end trace d9bb853af3659bd5 ]---

Signed-off-by: Tobias Klausmann 
---
 drivers/gpu/drm/drm_vblank.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index a233a6be934a..4a21756bf2bd 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -1140,8 +1140,11 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
 
/* Avoid redundant vblank disables without previous
 * drm_crtc_vblank_on(). */
-   if (drm_core_check_feature(dev, DRIVER_ATOMIC) || !vblank->inmodeset)
+   if (drm_core_check_feature(dev, DRIVER_ATOMIC) || (!vblank->inmodeset &&
+   vblank->enabled)) {
+   DRM_DEBUG("disabling vblank on crtc %

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

[Theodore Ts'o]

On Wed, Jul 19, 2017 at 08:22:18AM +0200, Stephan Müller wrote:
> In the email [1] I have expressed the core concerns I see -- none of them 
> address the need to keep the Jitter RNG as one noise source. To address 
> those, 
> a very deep dive into random.c needs to be made.

That's simply not true.  The other issues besides the Jitter RNG are
really nits.

One of your complaints is the fact that we collect both interrupt
timing and HID/block timings.  First of all, we could eliminate the
HID/block timings since in practice we get the vast majority of our
entropy from the interrupt timing.  I keep it because we have a real
theoretical basis for their being unpredictability from the HID/block
timings.  For example, [1].

[1] http://world.std.com/~dtd/random/forward.pdf

The fact that there might be double count from the perspective of
entropy is not really an issue because we do a "fast mix" of 64
interrupts before we mix into the primary interrupt pool.  And when we
do mix into the primary pool we count that only as a single bit of
entropy.  The reason why I'm being super cautious here is because some
of these interrupts might be timer interrupts, or come from other
sources that might be correlated to the clock interrupt.  The
conservative assumption here is that at least one of the interrupts
out of 64, on average, will come from something that the adversary can
not anticipate, such as coming from a NIC or wireless device, and that
we will get at least one bit's worth of unpredictability.

The fact that we also mix in the jiffies plus the keyboard/mouse scan
code, is something that happens immediately.  So even if you think we
should not count the fast mix interrupt count, the fact that we mix
the timing values from 64 interrupts before we credit the entropy
counter by a single bit is sufficiently conservative; we're talking
about 1/64th of a bit here.

But if you **really** think mixing in the timing of the HID event
(gathered via a different mechanism --- jiffies vs cycle counter, and
including the the keyboard scan), a patch to disable
add_keyboard_randomness() is pretty trivial.  It doesn't justify a
complete rewrite of the random core.

(BTW, granted this is anecdata, but on my laptop, the CRNG is fully
initialized before systemd has even started and before the root file
system is mounted.  And after that point the entropy initialization
only matters for the legacy apps that use /dev/random, which doesn't
even exist in your proposed RNG, since everything just uses a
ChaCha20-based CRNG.)


Another one of your complaints is a straw-man argument ("I understand
that this pathological case is not present for the legacy
/dev/random...").  First of all, how we do entropy estimation after
the CRNG boot is far less important, because the primary recommended
interface is /dev/urandom or better yet getrandom(2).  Secondly, we
*don't* allow transfer of small quantums of entropy.  There is a
minimum transfer limit of 64 bits, and that can easily be increased to
128 bits if one really cared.  I've never really considered recovery
from state compromise to be that important, but if one did care,
increasing that limit is a two line patch.


I could go on, but the bottom line is that, quite frankly, I don't
consider your criticsms to be particular compelling or convincing.

Regards,

- Ted

[PATCH 0/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

[Mark Salter]

Rafael,

What do you think of this one? I was submitted a long time ago but
there was never any real resolution to it.


Loc Ho (1):
  acpi: apei: Enable APEI multiple GHES source to share an single
external IRQ

 drivers/acpi/apei/ghes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
2.13.3

[PATCH 1/1] acpi: apei: Enable APEI multiple GHES source to share an single external IRQ

[Mark Salter]

From: Loc Ho 

This patch allows APEI generic error source table with external
IRQ to share an single IRQ.

Signed-off-by: Tuan Phan 
Signed-off-by: Loc Ho 
Signed-off-by: Mark Salter 
---
 drivers/acpi/apei/ghes.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index d661d452b238..eed09fc664e8 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -1157,7 +1157,8 @@ static int ghes_probe(struct platform_device *ghes_dev)
   generic->header.source_id);
goto err_edac_unreg;
}
-   rc = request_irq(ghes->irq, ghes_irq_func, 0, "GHES IRQ", ghes);
+   rc = request_irq(ghes->irq, ghes_irq_func, IRQF_SHARED,
+"GHES IRQ", ghes);
if (rc) {
pr_err(GHES_PFX "Failed to register IRQ for generic 
hardware error source: %d\n",
   generic->header.source_id);
-- 
2.13.3

Re: [kernel-hardening] Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

[Thomas Garnier]

On Wed, Jul 19, 2017 at 10:06 AM, Russell King - ARM Linux
 wrote:
> On Wed, Jul 19, 2017 at 05:58:20PM +0300, Leonard Crestez wrote:
>> On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote:
>> > On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez 
>> >  wrote:
>> > > On Tue, 2017-07-18 at 09:04 -0700, Thomas Garnier wrote:
>> > > > On Tue, Jul 18, 2017 at 7:36 AM, Leonard Crestez 
>> > > >  wrote:
>> > > > > On Wed, 2017-06-14 at 18:12 -0700, Thomas Garnier wrote:
>> > > > > >
>> > > > > > Ensure the address limit is a user-mode segment before returning to
>> > > > > > user-mode. Otherwise a process can corrupt kernel-mode memory and
>> > > > > > elevate privileges [1].
>> > > > > >
>> > > > > > The set_fs function sets the TIF_SETFS flag to force a slow path on
>> > > > > > return. In the slow path, the address limit is checked to be 
>> > > > > > USER_DS if
>> > > > > > needed.
>> > > > > >
>> > > > > > The TIF_SETFS flag is added to _TIF_WORK_MASK shifting 
>> > > > > > _TIF_SYSCALL_WORK
>> > > > > > for arm instruction immediate support. The global work mask is too 
>> > > > > > big
>> > > > > > to used on a single instruction so adapt ret_fast_syscall.
>> > > > > >
>> > > > > > @@ -571,6 +572,10 @@ do_work_pending(struct pt_regs *regs, 
>> > > > > > unsigned int thread_flags, int syscall)
>> > > > > >* Update the trace code with the current status.
>> > > > > >*/
>> > > > > >   trace_hardirqs_off();
>> > > > > > +
>> > > > > > + /* Check valid user FS if needed */
>> > > > > > + addr_limit_user_check();
>> > > > > > +
>> > > > > >   do {
>> > > > > >   if (likely(thread_flags & _TIF_NEED_RESCHED)) {
>> > > > > >   schedule();
>> > > > > This patch made it's way into linux-next next-20170717 and it seems 
>> > > > > to
>> > > > > cause hangs when booting some boards over NFS (found via bisection). 
>> > > > > I
>> > > > > don't know exactly what determines the issue but I can reproduce 
>> > > > > hangs
>> > > > > if even if I just boot with init=/bin/bash and do stuff like
>> > > > >
>> > > > > # sleep 1 & sleep 1 & sleep 1 & wait; wait; wait; echo done!
>> > > > >
>> > > > > When this happens sysrq-t shows a sleep task hung in the 'R' state
>> > > > > spinning in do_work_pending, so maybe there is a potential infinite
>> > > > > loop here?
>> > > > >
>> > > > > The addr_limit_user_check at the start of do_work_pending will check
>> > > > > for TIF_FSCHECK once and clear it but the function loops while
>> > > > > (thread_flags & _TIF_WORK_MASK), so it if TIF_FSCHECK is set again 
>> > > > > then
>> > > > > the loop will never terminate. Does this make sense?
>> > > >
>> > > > Yes, it does. Thanks for looking into this.
>> > > >
>> > > > Can you try this change?
>> > > >
>> > > > diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
>> > > > index 3a48b54c6405..bc6ad7789568 100644
>> > > > --- a/arch/arm/kernel/signal.c
>> > > > +++ b/arch/arm/kernel/signal.c
>> > > > @@ -573,12 +573,11 @@ do_work_pending(struct pt_regs *regs, unsigned
>> > > > int thread_flags, int syscall)
>> > > >   */
>> > > >   trace_hardirqs_off();
>> > > >
>> > > > - /* Check valid user FS if needed */
>> > > > - addr_limit_user_check();
>> > > > -
>> > > >   do {
>> > > >   if (likely(thread_flags & _TIF_NEED_RESCHED)) {
>> > > >   schedule();
>> > > > + } else if (thread_flags & _TIF_FSCHECK) {
>> > > > + addr_limit_user_check();
>> > > >   } else {
>> > > >   if (unlikely(!user_mode(regs)))
>> > > >   return 0;
>> > > This does seem to work, it no longer hangs on boot in my setup. This is
>> > > obviously only a very superficial test.
>> > >
>> > > The new location of this check seems weird, it's not clear why it
>> > > should be on an else path. Perhaps it should be moved to right before
>> > > where current_thread_info()->flags is fetched again?
>>
>> > I was hitting bug when I tried that.I think that's because you
>> > basically let the signal handler do pending work before you check the
>> > flag, that's not a good idea.
>>
>> > > If the purpose is hardening against buggy kernel code doing bad set_fs
>> > > calls shouldn't this flag also be checked before looking at
>> > > TIF_NEED_RESCHED and calling schedule()?
>> > I am not sure to be honest. I expected schedule to only schedule the
>> > processor to another task which would be fine given only the current
>> > task have a bogus fs. I will put it first in case there is an edge
>> > case scenario I missed.
>> >
>> > What do you think? Let me know and I will look at changes all
>> > architectures and testing them.
>>
>> I don't know and I'd rather not guess on security issues. It's better
>> if someone else reviews the code.
>>
>> Unless there is a very quick fix maybe this series should be removed or
>> reverted from linux-next? A diagnosis of "system calls can sometimes
>> hang on return" seems serious even for linux-next. Since it happens
>> very rarely in most setups I can easily imagine some

Re: [PATCH v2] xen: xen-pciback: remove DRIVER_ATTR() usage

[Juergen Gross]

On 19/07/17 17:17, Greg KH wrote:
> On Wed, Jul 19, 2017 at 04:51:02PM +0200, Juergen Gross wrote:
>> On 19/07/17 16:43, Greg KH wrote:
>>> From: Greg Kroah-Hartman 
>>>
>>> It's better to be explicit and use the DRIVER_ATTR_RW() and
>>> DRIVER_ATTR_RO() macros when defining a driver's sysfs file.
>>>
>>> Bonus is this fixes up a checkpatch.pl warning.
>>>
>>> This is part of a series to drop DRIVER_ATTR() from the tree entirely.
>>>
>>> Cc: Boris Ostrovsky 
>>> Cc: Juergen Gross 
>>> Signed-off-by: Greg Kroah-Hartman 
>>
>> Reviewed-by: Juergen Gross 
>>
>> I'll take this through the Xen tree, unless you want to use your tree.
> 
> If I can take it through mine, then I could drop DRIVER_ATTR() from the
> whole tree for the next kernel release, which would be ideal.
> 
> But if you want to take it, that's fine, I can wait another release, no
> rush.

In this case just use your tree. I don't think there are any pending
conflicting patches right now.


Juergen

Re: [PATCH v2 8/9] perf annotate browser: Support the toggle number of samples with a 'e' hotkey

[Taeung Song]

On 07/19/2017 01:18 AM, Namhyung Kim wrote:

On Fri, Jul 14, 2017 at 02:46:16AM +0900, Taeung Song wrote:

Cc: Namhyung Kim 
Cc: Milian Wolff 
Cc: Jiri Olsa 
Signed-off-by: Taeung Song 


Hmm.. IIUC there're 3 modes of annotation view: percent, period and
sample, right?  The existing 't' hotkey seems to toggle between
percent and period.  And you added 'e' for sample and percent, right?

I'm not sure percent by sample and percent by period are both needed.
If so, I think it's better to add a hotkey to toggle between percent
and value (both for period and sample).  And existing key should
toggle between sample and period.

If percent by sample is not meaningful, I'd rather make the hotkey to
circulate through percent, period and sample.

Thanks,
Namhyung




I agree on it. It seems to be better than two hot key !
I'll change this patch based on your comment.

Arnaldo, what do you think about this ?

  On annotate TUI browser
  hot key: 't'
  circulating: "Percent" -> "Sample" -> "Period" -> "Percent" -> ...


Thanks,
Taeung


---
  tools/perf/ui/browsers/annotate.c | 18 +-
  1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/tools/perf/ui/browsers/annotate.c 
b/tools/perf/ui/browsers/annotate.c
index 34b3189..19173b1 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -41,6 +41,7 @@ static struct annotate_browser_opt {
 jump_arrows,
 show_linenr,
 show_nr_jumps,
+show_nr_samples,
 show_total_period;
  } annotate_browser__opts = {
.use_offset = true,
@@ -156,6 +157,9 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
if (annotate_browser__opts.show_total_period) {
ui_browser__printf(browser, "%10" PRIu64 " ",
   
bdl->samples[i].sample.period);
+   } else if (annotate_browser__opts.show_nr_samples) {
+   ui_browser__printf(browser, "%6" PRIu64 " ",
+  
bdl->samples[i].sample.nr_samples);
} else {
ui_browser__printf(browser, "%6.2f ",
   bdl->samples[i].percent);
@@ -169,6 +173,8 @@ static void annotate_browser__write(struct ui_browser 
*browser, void *entry, int
else  {
if (annotate_browser__opts.show_total_period)
ui_browser__printf(browser, "%*s", 11, "Event 
count");
+   else if (annotate_browser__opts.show_nr_samples)
+   ui_browser__printf(browser, "%*s", 7, 
"Samples");
else
ui_browser__printf(browser, "%*s", 7, 
"Percent");
}
@@ -834,6 +840,7 @@ static int annotate_browser__run(struct annotate_browser 
*browser,
"o Toggle disassembler output/simplified view\n"
"s Toggle source code view\n"
"t Toggle total period view\n"
+   "e Toggle number of samples\n"
"/ Search string\n"
"k Toggle line numbers\n"
"r Run available scripts\n"
@@ -914,6 +921,12 @@ static int annotate_browser__run(struct annotate_browser 
*browser,
  !annotate_browser__opts.show_total_period;
annotate_browser__update_addr_width(browser);
continue;
+   case 'e':
+   annotate_browser__opts.show_total_period = false;
+   annotate_browser__opts.show_nr_samples =
+   !annotate_browser__opts.show_nr_samples;
+   annotate_browser__update_addr_width(browser);
+   continue;
case K_LEFT:
case K_ESC:
case 'q':
@@ -934,9 +947,11 @@ static int annotate_browser__run(struct annotate_browser 
*browser,
  int map_symbol__tui_annotate(struct map_symbol *ms, struct perf_evsel *evsel,
 struct hist_browser_timer *hbt)
  {
-   /* Set default value for show_total_period.  */
+   /* Set default value for show_total_period and show_nr_samples  */
annotate_browser__opts.show_total_period =
  symbol_conf.show_total_period;
+   annotate_browser__opts.show_nr_samples =
+   symbol_conf.show_nr_samples;
  
  	return symbol__tui_annotate(ms->sym, ms->map, evsel, hbt);

  }
@@ -1187,6 +1202,7 @@ static struct annotate_config {
ANNOTATE_CFG(jump_arrows),
ANNOTATE_CFG(show_linenr),
ANNOTATE_CFG(show_nr_jumps),
+   ANNOTATE_CFG(show_nr_samples),
ANNOTATE_CFG(show_total_period),
AN

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

[Waiman Long]

On 07/19/2017 12:29 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Jul 18, 2017 at 01:23:14PM -0400, Waiman Long wrote:
>>> If we could get rid of the invalid state completely that way, I'd
>>> completely agree with you but that isn't the case here as you noted
>>> yourself, so the choice between the two isn't something trivially
>>> clear.  Both choices come with their pros and cons.  We can absoultely
>>> discuss them comparing the pros and cons.
>> I am not advocating on removing the invalid state now as I note about
> Yeah, removing invalid state would be great but we can't at least yet.
>
>> sibling cgroups. I am just saying that there is no point in not doing an
>> automatic conversion to threaded for newly created children of threaded
>> cgroups (not thread root). I don't see any cons in doing that.
> So, the cons I see is inconsistency, now and in the future.
>
> This may seem less clear with system root because we can have both
> domain and theraded children below it, which makes a newly created
> cgroup being a domain seem natural.  More importantly, we can't do it
> any other way because we'd break existing users otherwise - creating a
> threaded cgroup would cause future first level cgroups to be threaded
> which will be very unexpected.
>
> Let's think about a non-root threaded domain.  At least for now, a
> non-root threaded domain is terminal - they can't host valid domain
> children.  As the alternative term "thread root" implies, the threaded
> domain can be the root of a threaded subtree and nothing else, so it's
> kinda weird to make a new child cgroup there start out as a domain
> which can't be used, just like it'd be for the second level descendant
> cgroup.
>
> However, the alternative is even stranger.  Let's say we make the
> first level child automatically threaded, but that is inconsistent
> with when we first enable threaded mode.  We either would have to turn
> all siblings at the same time or disallow enabling threaded mode if
> there are domain siblings, which I fear would be unnecessarily
> restrictive.
>
> Another point is that what if we eventually make non-root threaded
> roots able to host domain children?  Making children automatically
> threaded wouldn't make any sense then, right?  I'll come back to this
> later.
>
> So, it looks like if we're gonna automatically turn on threaded mode
> for new cgroups, the only thing we can do right now is what you're
> suggesting; however, we didn't arrive there through some
> straight-forward intuition or overall design.  It started as a simple
> idea (I want it to be automatic) but the end result is a contorted
> destination shaped by constraints and happenstance.
>
> To me, behaving differently on the first-level threaded children than
> on second+ level ones is too strange to be justified by the
> convenience of not having to turn on threaded on new cgroups.

OK, I get your point of being inconsistent. However, I don't think that
is a big deal.

> On top of that, what happens if we get to implement PeterZ's idea of
> skipping over threaded internal cgroups to allow domains under
> threaded subtrees?  That'd imply that we'd be able to host domains
> under threaded domains too.  The end result would be completely
> non-sensical.  We'd be defaulting to different modes for different
> reasons where half of those reasons won't hold anymore.  This isn't
> surprising given that there's nothing actually consistent about the
> suggested default behavior.

For me, that is the only good reason why we should keep the current
behavior. So I am fine with that.

+ cgrp->dom_cgrp = cgrp->dom_cgrp;

However, I am still puzzled by above line of code, should it be just

  cgrp->dom_cgrp = cgrp;

Cheers,
Longman

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

[Russell King - ARM Linux]

On Wed, Jul 19, 2017 at 05:58:20PM +0300, Leonard Crestez wrote:
> On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote:
> > On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez  
> > wrote:
> > > On Tue, 2017-07-18 at 09:04 -0700, Thomas Garnier wrote:
> > > > On Tue, Jul 18, 2017 at 7:36 AM, Leonard Crestez 
> > > >  wrote:
> > > > > On Wed, 2017-06-14 at 18:12 -0700, Thomas Garnier wrote:
> > > > > > 
> > > > > > Ensure the address limit is a user-mode segment before returning to
> > > > > > user-mode. Otherwise a process can corrupt kernel-mode memory and
> > > > > > elevate privileges [1].
> > > > > > 
> > > > > > The set_fs function sets the TIF_SETFS flag to force a slow path on
> > > > > > return. In the slow path, the address limit is checked to be 
> > > > > > USER_DS if
> > > > > > needed.
> > > > > > 
> > > > > > The TIF_SETFS flag is added to _TIF_WORK_MASK shifting 
> > > > > > _TIF_SYSCALL_WORK
> > > > > > for arm instruction immediate support. The global work mask is too 
> > > > > > big
> > > > > > to used on a single instruction so adapt ret_fast_syscall.
> > > > > > 
> > > > > > @@ -571,6 +572,10 @@ do_work_pending(struct pt_regs *regs, unsigned 
> > > > > > int thread_flags, int syscall)
> > > > > >    * Update the trace code with the current status.
> > > > > >    */
> > > > > >   trace_hardirqs_off();
> > > > > > +
> > > > > > + /* Check valid user FS if needed */
> > > > > > + addr_limit_user_check();
> > > > > > +
> > > > > >   do {
> > > > > >   if (likely(thread_flags & _TIF_NEED_RESCHED)) {
> > > > > >   schedule();
> > > > > This patch made it's way into linux-next next-20170717 and it seems to
> > > > > cause hangs when booting some boards over NFS (found via bisection). I
> > > > > don't know exactly what determines the issue but I can reproduce hangs
> > > > > if even if I just boot with init=/bin/bash and do stuff like
> > > > > 
> > > > > # sleep 1 & sleep 1 & sleep 1 & wait; wait; wait; echo done!
> > > > > 
> > > > > When this happens sysrq-t shows a sleep task hung in the 'R' state
> > > > > spinning in do_work_pending, so maybe there is a potential infinite
> > > > > loop here?
> > > > > 
> > > > > The addr_limit_user_check at the start of do_work_pending will check
> > > > > for TIF_FSCHECK once and clear it but the function loops while
> > > > > (thread_flags & _TIF_WORK_MASK), so it if TIF_FSCHECK is set again 
> > > > > then
> > > > > the loop will never terminate. Does this make sense?
> > > > 
> > > > Yes, it does. Thanks for looking into this.
> > > > 
> > > > Can you try this change?
> > > > 
> > > > diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
> > > > index 3a48b54c6405..bc6ad7789568 100644
> > > > --- a/arch/arm/kernel/signal.c
> > > > +++ b/arch/arm/kernel/signal.c
> > > > @@ -573,12 +573,11 @@ do_work_pending(struct pt_regs *regs, unsigned
> > > > int thread_flags, int syscall)
> > > >   */
> > > >   trace_hardirqs_off();
> > > > 
> > > > - /* Check valid user FS if needed */
> > > > - addr_limit_user_check();
> > > > -
> > > >   do {
> > > >   if (likely(thread_flags & _TIF_NEED_RESCHED)) {
> > > >   schedule();
> > > > + } else if (thread_flags & _TIF_FSCHECK) {
> > > > + addr_limit_user_check();
> > > >   } else {
> > > >   if (unlikely(!user_mode(regs)))
> > > >   return 0;
> > > This does seem to work, it no longer hangs on boot in my setup. This is
> > > obviously only a very superficial test.
> > > 
> > > The new location of this check seems weird, it's not clear why it
> > > should be on an else path. Perhaps it should be moved to right before
> > > where current_thread_info()->flags is fetched again?
> 
> > I was hitting bug when I tried that.I think that's because you
> > basically let the signal handler do pending work before you check the
> > flag, that's not a good idea.
> 
> > > If the purpose is hardening against buggy kernel code doing bad set_fs
> > > calls shouldn't this flag also be checked before looking at
> > > TIF_NEED_RESCHED and calling schedule()?
> > I am not sure to be honest. I expected schedule to only schedule the
> > processor to another task which would be fine given only the current
> > task have a bogus fs. I will put it first in case there is an edge
> > case scenario I missed.
> > 
> > What do you think? Let me know and I will look at changes all
> > architectures and testing them.
> 
> I don't know and I'd rather not guess on security issues. It's better
> if someone else reviews the code.
> 
> Unless there is a very quick fix maybe this series should be removed or
> reverted from linux-next? A diagnosis of "system calls can sometimes
> hang on return" seems serious even for linux-next. Since it happens
> very rarely in most setups I can easily imagine somebody spending a lot
> of time digging at this.

Probably best to revert.  I stopped looking at these patches during
the discussion, as the discussion seemed to be mainly around other
architectu

[PATCH 2/2] arm64: dts: move rpi into rpi directory

[Scott Branden]

Place rpi into its own subdirectory.  This helps as the number
of Broadcom boards grow and we can separate them per SoC.

Signed-off-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/Makefile  | 3 +--
 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi  | 1 -
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi | 1 -
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi | 1 -
 arch/arm64/boot/dts/broadcom/bcm283x.dtsi  | 1 -
 arch/arm64/boot/dts/broadcom/rpi/Makefile  | 5 +
 arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi  | 1 +
 arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837-rpi-3-b.dts | 0
 arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837.dtsi| 0
 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi | 1 +
 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-usb-host.dtsi | 1 +
 arch/arm64/boot/dts/broadcom/rpi/bcm283x.dtsi  | 1 +
 12 files changed, 10 insertions(+), 6 deletions(-)
 delete mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
 delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
 delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi
 delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/rpi/Makefile
 create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi
 rename arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837-rpi-3-b.dts (100%)
 rename arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837.dtsi (100%)
 create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-usb-host.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x.dtsi

diff --git a/arch/arm64/boot/dts/broadcom/Makefile 
b/arch/arm64/boot/dts/broadcom/Makefile
index 3eaef38..1708ff5 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,6 +1,5 @@
-dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
-
 dts-dirs   += northstar2
+dts-dirs   += rpi
 dts-dirs   += stingray
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
deleted file mode 12
index 3937b77..000
--- a/arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
+++ /dev/null
@@ -1 +0,0 @@
-../../../../arm/boot/dts/bcm2835-rpi.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
deleted file mode 12
index dca7c05..000
--- a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
+++ /dev/null
@@ -1 +0,0 @@
-../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi
deleted file mode 12
index cbeebe3..000
--- a/arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi
+++ /dev/null
@@ -1 +0,0 @@
-../../../../arm/boot/dts/bcm283x-rpi-usb-host.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm283x.dtsi 
b/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
deleted file mode 12
index 5f54e4c..000
--- a/arch/arm64/boot/dts/broadcom/bcm283x.dtsi
+++ /dev/null
@@ -1 +0,0 @@
-../../../../arm/boot/dts/bcm283x.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/rpi/Makefile 
b/arch/arm64/boot/dts/broadcom/rpi/Makefile
new file mode 100644
index 000..d1a5606
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/rpi/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi 
b/arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi
new file mode 12
index 000..06e5aa0
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi
@@ -0,0 +1 @@
+../../../../../arm/boot/dts/bcm2835-rpi.dtsi
\ No newline at end of file
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/rpi/bcm2837-rpi-3-b.dts
similarity index 100%
rename from arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
rename to arch/arm64/boot/dts/broadcom/rpi/bcm2837-rpi-3-b.dts
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm64/boot/dts/broadcom/rpi/bcm2837.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/broadcom/bcm2837.dtsi
rename to arch/arm64/boot/dts/broadcom/rpi/bcm2837.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi 
b/arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi
new file mode 12
index 000..3eff817
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi
@@ -0,0 +1 @@
+../../../../../arm/boot/dts/bcm283x-rpi-smsc9514.dtsi
\ No newline at

[PATCH 1/2] arm64: dts: move ns2 into northstar2 directory

[Scott Branden]

Place northstar2 into its own subdirectory.  This helps as the number
of Broadcom boards grow and we can separate them per SoC.

Signed-off-by: Scott Branden 
---
 arch/arm64/boot/dts/broadcom/Makefile| 4 ++--
 arch/arm64/boot/dts/broadcom/northstar2/Makefile | 6 ++
 arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-clock.dtsi | 0
 arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-svk.dts| 0
 arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-xmc.dts| 0
 arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2.dtsi   | 0
 6 files changed, 8 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/boot/dts/broadcom/northstar2/Makefile
 rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-clock.dtsi (100%)
 rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-svk.dts (100%)
 rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-xmc.dts (100%)
 rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2.dtsi (100%)

diff --git a/arch/arm64/boot/dts/broadcom/Makefile 
b/arch/arm64/boot/dts/broadcom/Makefile
index f11bdd6..3eaef38 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,7 +1,7 @@
 dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
-dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
 
-dts-dirs   := stingray
+dts-dirs   += northstar2
+dts-dirs   += stingray
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
 clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/broadcom/northstar2/Makefile 
b/arch/arm64/boot/dts/broadcom/northstar2/Makefile
new file mode 100644
index 000..e01a148
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/northstar2/Makefile
@@ -0,0 +1,6 @@
+dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb
+dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-xmc.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/broadcom/ns2-clock.dtsi 
b/arch/arm64/boot/dts/broadcom/northstar2/ns2-clock.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/broadcom/ns2-clock.dtsi
rename to arch/arm64/boot/dts/broadcom/northstar2/ns2-clock.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/ns2-svk.dts 
b/arch/arm64/boot/dts/broadcom/northstar2/ns2-svk.dts
similarity index 100%
rename from arch/arm64/boot/dts/broadcom/ns2-svk.dts
rename to arch/arm64/boot/dts/broadcom/northstar2/ns2-svk.dts
diff --git a/arch/arm64/boot/dts/broadcom/ns2-xmc.dts 
b/arch/arm64/boot/dts/broadcom/northstar2/ns2-xmc.dts
similarity index 100%
rename from arch/arm64/boot/dts/broadcom/ns2-xmc.dts
rename to arch/arm64/boot/dts/broadcom/northstar2/ns2-xmc.dts
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi 
b/arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/broadcom/ns2.dtsi
rename to arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi
-- 
2.5.0

[PATCH 0/2] arm64: dts: cleanup Broadcom boards per SoC

[Scott Branden]

Separate Broadcom boards per SoC to assist in cleaner management of boards.
This has already been done for Stingray and is done here for RPI and NS2.

If this is problematic for RPI please let me know and RPI patch can be
dropped from patch series.

Scott Branden (2):
  arm64: dts: move ns2 into northstar2 directory
  arm64: dts: move rpi into rpi directory

 arch/arm64/boot/dts/broadcom/Makefile| 7 +++
 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi| 1 -
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi   | 1 -
 arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi   | 1 -
 arch/arm64/boot/dts/broadcom/bcm283x.dtsi| 1 -
 arch/arm64/boot/dts/broadcom/northstar2/Makefile | 6 ++
 arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-clock.dtsi | 0
 arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-svk.dts| 0
 arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-xmc.dts| 0
 arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2.dtsi   | 0
 arch/arm64/boot/dts/broadcom/rpi/Makefile| 5 +
 arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi| 1 +
 arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837-rpi-3-b.dts   | 0
 arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837.dtsi  | 0
 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi   | 1 +
 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-usb-host.dtsi   | 1 +
 arch/arm64/boot/dts/broadcom/rpi/bcm283x.dtsi| 1 +
 17 files changed, 18 insertions(+), 8 deletions(-)
 delete mode 12 arch/arm64/boot/dts/broadcom/bcm2835-rpi.dtsi
 delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-smsc9514.dtsi
 delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x-rpi-usb-host.dtsi
 delete mode 12 arch/arm64/boot/dts/broadcom/bcm283x.dtsi
 create mode 100644 arch/arm64/boot/dts/broadcom/northstar2/Makefile
 rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-clock.dtsi (100%)
 rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-svk.dts (100%)
 rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2-xmc.dts (100%)
 rename arch/arm64/boot/dts/broadcom/{ => northstar2}/ns2.dtsi (100%)
 create mode 100644 arch/arm64/boot/dts/broadcom/rpi/Makefile
 create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm2835-rpi.dtsi
 rename arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837-rpi-3-b.dts (100%)
 rename arch/arm64/boot/dts/broadcom/{ => rpi}/bcm2837.dtsi (100%)
 create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-smsc9514.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x-rpi-usb-host.dtsi
 create mode 12 arch/arm64/boot/dts/broadcom/rpi/bcm283x.dtsi

-- 
2.5.0

[PATCH v2 1/2] power: supply: move HDQ interface for bq27xxx from w1 to power/supply

[Andrew F. Davis]

The HDQ interface driver should be in this folder just like the I2C
interface driver. Move this driver out of drivers/w1/slave and into
drivers/power/supply.

Signed-off-by: Andrew F. Davis 
Acked-by: Pali Rohár 
Acked-by: Sebastian Reichel 
---
 drivers/power/supply/Kconfig | 9 +
 drivers/power/supply/Makefile| 1 +
 .../slaves/w1_bq27000.c => power/supply/bq27xxx_battery_hdq.c}   | 2 --
 drivers/w1/slaves/Kconfig| 6 --
 drivers/w1/slaves/Makefile   | 1 -
 5 files changed, 10 insertions(+), 9 deletions(-)
 rename drivers/{w1/slaves/w1_bq27000.c => power/supply/bq27xxx_battery_hdq.c} 
(98%)

diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 969f5005669c..af6397224a82 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -198,6 +198,15 @@ config BATTERY_BQ27XXX_I2C
  Say Y here to enable support for batteries with BQ27xxx chips
  connected over an I2C bus.
 
+config BATTERY_BQ27XXX_HDQ
+   tristate "BQ27xxx HDQ support"
+   depends on BATTERY_BQ27XXX
+   depends on W1
+   default y
+   help
+ Say Y here to enable support for batteries with BQ27xxx chips
+ connected over an HDQ bus.
+
 config BATTERY_BQ27XXX_DT_UPDATES_NVM
bool "BQ27xxx support for update of NVM/flash data memory"
depends on BATTERY_BQ27XXX_I2C
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index a41f40957847..946a5e6be860 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_BATTERY_SBS) += sbs-battery.o
 obj-$(CONFIG_CHARGER_SBS)  += sbs-charger.o
 obj-$(CONFIG_BATTERY_BQ27XXX)  += bq27xxx_battery.o
 obj-$(CONFIG_BATTERY_BQ27XXX_I2C) += bq27xxx_battery_i2c.o
+obj-$(CONFIG_BATTERY_BQ27XXX_HDQ) += bq27xxx_battery_hdq.o
 obj-$(CONFIG_BATTERY_DA9030)   += da9030_battery.o
 obj-$(CONFIG_BATTERY_DA9052)   += da9052-battery.o
 obj-$(CONFIG_CHARGER_DA9150)   += da9150-charger.o
diff --git a/drivers/w1/slaves/w1_bq27000.c 
b/drivers/power/supply/bq27xxx_battery_hdq.c
similarity index 98%
rename from drivers/w1/slaves/w1_bq27000.c
rename to drivers/power/supply/bq27xxx_battery_hdq.c
index 8046ac45381a..f4df67eb9d2c 100644
--- a/drivers/w1/slaves/w1_bq27000.c
+++ b/drivers/power/supply/bq27xxx_battery_hdq.c
@@ -1,6 +1,4 @@
 /*
- * drivers/w1/slaves/w1_bq27000.c
- *
  * Copyright (C) 2007 Texas Instruments, Inc.
  *
  * This file is licensed under the terms of the GNU General Public License
diff --git a/drivers/w1/slaves/Kconfig b/drivers/w1/slaves/Kconfig
index fb68465908f2..dc4437683956 100644
--- a/drivers/w1/slaves/Kconfig
+++ b/drivers/w1/slaves/Kconfig
@@ -140,10 +140,4 @@ config W1_SLAVE_DS28E04
 
  If you are unsure, say N.
 
-config W1_SLAVE_BQ27000
-   tristate "BQ27000 slave support"
-   help
- Say Y here if you want to use a hdq
- bq27000 slave support.
-
 endmenu
diff --git a/drivers/w1/slaves/Makefile b/drivers/w1/slaves/Makefile
index 54c63e420302..e59441a5e157 100644
--- a/drivers/w1/slaves/Makefile
+++ b/drivers/w1/slaves/Makefile
@@ -15,5 +15,4 @@ obj-$(CONFIG_W1_SLAVE_DS2438) += w1_ds2438.o
 obj-$(CONFIG_W1_SLAVE_DS2760)  += w1_ds2760.o
 obj-$(CONFIG_W1_SLAVE_DS2780)  += w1_ds2780.o
 obj-$(CONFIG_W1_SLAVE_DS2781)  += w1_ds2781.o
-obj-$(CONFIG_W1_SLAVE_BQ27000) += w1_bq27000.o
 obj-$(CONFIG_W1_SLAVE_DS28E04) += w1_ds28e04.o
-- 
2.13.0

[PATCH v2 0/2] Remove BQ27xxx platform interface

[Andrew F. Davis]

To finish the work started in this patch[0] we needed to reorganize
the 1-wire subsystem a bit, this is done here[1]. After that is taken
this series can remove the need for a platform driver for supporting
1-wire connected BQ27xxx devices.

Thanks,
Andrew

Changes from v1:
 - Rebased on v4.13-rc1
 - [1] has been taken, this series can now be merged

[0] https://patchwork.kernel.org/patch/7684371/
[1] https://lkml.org/lkml/2017/3/16/604

Andrew F. Davis (2):
  power: supply: move HDQ interface for bq27xxx from w1 to power/supply
  power: supply: bq27xxx: move platform driver code into
bq27xxx_battery_hdq.c

 drivers/power/supply/Kconfig   |   9 ++
 drivers/power/supply/Makefile  |   1 +
 drivers/power/supply/bq27xxx_battery.c | 104 --
 drivers/power/supply/bq27xxx_battery_hdq.c | 135 +
 drivers/w1/slaves/Kconfig  |   6 --
 drivers/w1/slaves/Makefile |   1 -
 drivers/w1/slaves/w1_bq27000.c | 117 -
 include/linux/power/bq27xxx_battery.h  |  17 
 8 files changed, 145 insertions(+), 245 deletions(-)
 create mode 100644 drivers/power/supply/bq27xxx_battery_hdq.c
 delete mode 100644 drivers/w1/slaves/w1_bq27000.c

-- 
2.13.0

Re: [PATCH v2 0/9] perf annotate: Fix --show-total-period and support --show-nr-samples

[Taeung Song]

Hi Namhyung,

I'm late.
Thanks for your review.

On 07/19/2017 01:07 AM, Namhyung Kim wrote:

Hi Taeung,

On Fri, Jul 14, 2017 at 02:45:44AM +0900, Taeung Song wrote:

Hello,

Currently the --show-total-period option of perf-annotate
is different from perf-report's.

It has two problem like below:
(Reported by Namhyung Kim and Milian Wolff)

   1) Wrong column i.e. 'Percent' (even though using --show-total-period)
   2) Show number of samples, not period

So fix this option on both the annotate stdio and TUI browser.
And support --show-nr-samples into perf-anntate
so that it correpond with perf-report's.

The code is available on 'perf/ann-fix-period-v2' branch at

   git://github.com/taeung/linux-perf.git

Thanks,
Taeung

v2:
- Separate the first patch into respective paches for easy review (Arnaldo)
- Add a patch to introduce 'struct sym_hist_entry' (Arnaldo)
- disasm__calc_percent() could receive a pointer to a struct sym_hist_entry
   instead of two pointer (Arnaldo)
- Add a sym_hist_entry into struct disasm_line_samples (Arnaldo)
- Fix a case that can't switch 'the total period view' to
   'the number of samples view' on the annotate TUI browser (Arnaldo)
- Calculate the percentage with 'period', not number of samples

Taeung Song (9):
   perf annotate: Introduce struct sym_hist_entry
   perf annotate: Properly rename 'sum' to 'total_samples' in struct
 sym_hist
   perf annotate: Fix wrong --show-total-period option showing number of
 samples
   perf annotate: Show the proper header when using --show-total-period
   perf anntoate browser: Fix the toggle total period view to show
 period, not number of samples
   perf annotate browser: Show the proper header when using
 --show-total-period
   perf annotate: Support --show-nr-samples option
   perf annotate browser: Support the toggle number of samples with a 'e'
 hotkey
   perf annotate: Use the sample period when calculating the percentage


It seems I didn't receive the patch 3 and 5 for some reason.  Anyway
I have a few comments.

Thanks,
Namhyung




Oops, I won't miss out your email when sending the patchset v3.

Thanks,
Taeung



  tools/perf/builtin-annotate.c |   6 +-
  tools/perf/builtin-report.c   |  13 ++--
  tools/perf/builtin-top.c  |   6 +-
  tools/perf/ui/browsers/annotate.c |  42 ++---
  tools/perf/ui/gtk/annotate.c  |   4 +-
  tools/perf/util/annotate.c| 125 ++
  tools/perf/util/annotate.h|  15 +++--
  7 files changed, 148 insertions(+), 63 deletions(-)

--
2.7.4

[PATCH v2 2/2] power: supply: bq27xxx: move platform driver code into bq27xxx_battery_hdq.c

[Andrew F. Davis]

When the BQ27xxx driver was originally written the w1 subsystem only
allowed device drivers for w1 attached devices to live in the w1
subsystem. Kernel driver subsystems expect that the driver for a device
live in the directory of the subsystem for which it implements
functionality, not in the directory of the bus that it is attached. To
work around this, the BQ27xxx driver was implemented as a platform device
driver and the interface driver would instantiate this device from within
the w1 directory, then pass a w1 read callback as platform data.

As we can now have the w1 interface driver in the power/supply directory
(like we do already with the i2c interface driver) we can remove this
middle-layer platform driver.

Signed-off-by: Andrew F. Davis 
Acked-by: Pali Rohár 
Acked-by: Sebastian Reichel 
---
 drivers/power/supply/bq27xxx_battery.c | 104 
 drivers/power/supply/bq27xxx_battery_hdq.c | 250 -
 include/linux/power/bq27xxx_battery.h  |  17 --
 3 files changed, 135 insertions(+), 236 deletions(-)
 rewrite drivers/power/supply/bq27xxx_battery_hdq.c (72%)

diff --git a/drivers/power/supply/bq27xxx_battery.c 
b/drivers/power/supply/bq27xxx_battery.c
index ed44439d0112..079083b31293 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -1938,110 +1938,6 @@ void bq27xxx_battery_teardown(struct 
bq27xxx_device_info *di)
 }
 EXPORT_SYMBOL_GPL(bq27xxx_battery_teardown);
 
-static int bq27xxx_battery_platform_read(struct bq27xxx_device_info *di, u8 
reg,
-bool single)
-{
-   struct device *dev = di->dev;
-   struct bq27xxx_platform_data *pdata = dev->platform_data;
-   unsigned int timeout = 3;
-   int upper, lower;
-   int temp;
-
-   if (!single) {
-   /* Make sure the value has not changed in between reading the
-* lower and the upper part */
-   upper = pdata->read(dev, reg + 1);
-   do {
-   temp = upper;
-   if (upper < 0)
-   return upper;
-
-   lower = pdata->read(dev, reg);
-   if (lower < 0)
-   return lower;
-
-   upper = pdata->read(dev, reg + 1);
-   } while (temp != upper && --timeout);
-
-   if (timeout == 0)
-   return -EIO;
-
-   return (upper << 8) | lower;
-   }
-
-   return pdata->read(dev, reg);
-}
-
-static int bq27xxx_battery_platform_probe(struct platform_device *pdev)
-{
-   struct bq27xxx_device_info *di;
-   struct bq27xxx_platform_data *pdata = pdev->dev.platform_data;
-
-   if (!pdata) {
-   dev_err(&pdev->dev, "no platform_data supplied\n");
-   return -EINVAL;
-   }
-
-   if (!pdata->read) {
-   dev_err(&pdev->dev, "no hdq read callback supplied\n");
-   return -EINVAL;
-   }
-
-   if (!pdata->chip) {
-   dev_err(&pdev->dev, "no device supplied\n");
-   return -EINVAL;
-   }
-
-   di = devm_kzalloc(&pdev->dev, sizeof(*di), GFP_KERNEL);
-   if (!di)
-   return -ENOMEM;
-
-   platform_set_drvdata(pdev, di);
-
-   di->dev = &pdev->dev;
-   di->chip = pdata->chip;
-   di->name = pdata->name ?: dev_name(&pdev->dev);
-   di->bus.read = bq27xxx_battery_platform_read;
-
-   return bq27xxx_battery_setup(di);
-}
-
-static int bq27xxx_battery_platform_remove(struct platform_device *pdev)
-{
-   struct bq27xxx_device_info *di = platform_get_drvdata(pdev);
-
-   bq27xxx_battery_teardown(di);
-
-   return 0;
-}
-
-static const struct platform_device_id bq27xxx_battery_platform_id_table[] = {
-   { "bq27000-battery", },
-   { /* sentinel */ }
-};
-MODULE_DEVICE_TABLE(platform, bq27xxx_battery_platform_id_table);
-
-#ifdef CONFIG_OF
-static const struct of_device_id bq27xxx_battery_platform_of_match_table[] = {
-   { .compatible = "ti,bq27000" },
-   {},
-};
-MODULE_DEVICE_TABLE(of, bq27xxx_battery_platform_of_match_table);
-#endif
-
-static struct platform_driver bq27xxx_battery_platform_driver = {
-   .probe  = bq27xxx_battery_platform_probe,
-   .remove = bq27xxx_battery_platform_remove,
-   .driver = {
-   .name = "bq27000-battery",
-   .of_match_table = 
of_match_ptr(bq27xxx_battery_platform_of_match_table),
-   },
-   .id_table = bq27xxx_battery_platform_id_table,
-};
-module_platform_driver(bq27xxx_battery_platform_driver);
-
-MODULE_ALIAS("platform:bq27000-battery");
-
 MODULE_AUTHOR("Rodolfo Giometti ");
 MODULE_DESCRIPTION("BQ27xxx battery monitor driver");
 MODULE_LICENSE("GPL");
diff --git a/drivers/power/supply/bq27xxx_battery_hdq.c 
b/drivers/power/supply/bq27xxx_battery_hdq.c
dissimilarity index 72%
index f4df67eb9d2c..9aff896c9802 100644
--- 

Re: [PATCH v2 1/2] platform: Add driver for RAVE Supervisory Processor

[Andrey Smirnov]

On Tue, Jul 18, 2017 at 11:48 AM, Andy Shevchenko
 wrote:
> On Tue, Jul 18, 2017 at 8:56 PM, Andrey Smirnov
>  wrote:
>> Add a driver for RAVE Supervisory Processor, an MCU implementing
>> varoius bits of housekeeping functionality (watchdoging, backlight
>> control, LED control, etc) on RAVE family of products by Zodiac
>> Inflight Innovations.
>>
>> This driver implementes core MFD/serdev device as well as
>> communication subroutines necessary for commanding the device.
>
>> +/**
>> + * struct rave_sp - RAVE supervisory processor core
>> + *
>> + * @serdev:Pointer to underlying serdev
>> + * @deframer:  Stored state of the protocol deframer
>> + * @ackid: ACK ID used in last reply sent to the device
>> + * @bus_lock:  Lock to serialize access to the device
>> + * @reply_lock:Lock protecting @reply
>> + * @reply: Pointer to memory to store reply payload
>
>> + *
>
> Do you need it?

Not sure what this is in reference too. The @reply field?

>
>> + * @part_number_firmware:  String containing firmware part number
>
>> + * (retrived once during probing)
>
> No need to repeat this over each parameter. Just move it to (long)
> description part and tell that
> "part_*, copper_*, and silicon_* parameters are retrived once during probing."
>

OK, will change in v3.

>> +static void
>> +devm_rave_sp_unregister_event_notifier(struct device *dev, void *res)
>
> static devm_*?!
> It looks let's say interesting... (yes, better to provide releasing
> devres API as well)
>

It's just a callback provided to devres_alloc call below. It could and
should not be used as external API, but I can remove devm_ prefix from
the name if that makes things better. As for providing API for manual
unregistered -- there are no potential users of that functionality in
any of the corresponding MFD cell drivers, so I'd rather not add code
that'll never get used.

>> +static const char *devm_rave_sp_version(struct device *dev, const char *buf)
>> +{
>> +   return devm_kasprintf(dev, GFP_KERNEL, "%02d%02d%02d.%c%c\n",
>> + buf[0], le16_to_cpup((const __le16 *)&buf[1]),
>
> To cpu_P_?!

Yes, I am not sure why you are surprised. It's used with &buf[1] and
it all seems legit, did I miss something?

> __le16 and %02d?
> Are you sure?
>

Yeah, legacy userspace daemon that, among other things, was in charge
of implementing similar to this driver's functionality was reporting
that particular version string in such buggy way. For the sake of
backwards compatibility I do the same. I'll add some commentary to
explain that.

>> + buf[3], buf[4], buf[5]);
>> +}
>
>> +static ssize_t
>> +rave_sp_show_part_number(char *buf, const char *version, size_t 
>> version_length)
>> +{
>> +   memcpy(buf, version, version_length + 1);
>> +   return version_length;
>
> Looks suspicious. If it's string, use snprintf(), it it might have
> garbage, use %pE.
>

Will change to snprintf in v3.

>> +}
>
>> +   return sprintf(buf, "%04x\n", le16_to_cpup((__le16 *)status));
>
> cpu_P_?!
>

Status is declared as "u8 status[2]", so this should be OK, no?

>> +static int rave_sp_common_get_boot_source(struct rave_sp *sp)
>> +{
>> +   u8 cmd[] = {
>> +   [0] = RAVE_SP_CMD_BOOT_SOURCE,
>> +   [1] = 0,
>> +   [2] = RAVE_SP_BOOT_SOURCE_SET,
>> +   [3] = 0,
>> +   };
>> +   u8 boot_source;
>
>> +   const int ret = rave_sp_exec(sp, cmd, sizeof(cmd),
>> +&boot_source, sizeof(boot_source));
>
> Why not
>
> const int ret;
>
> ret = rave_sp_exec(sp, cmd, sizeof(cmd), &boot_source, 
> sizeof(boot_source));
>

You'd have to drop the "const" qualifier from "ret" in order for that
snippet to compile, which I was trying to avoid. I'll drop the const
and move the call one line down in v3.

>> +   return (ret < 0) ? ret : boot_source;
>
> Ditto for every similar cases.
>
>> +}
>
>> +static void csum_8b2c(const u8 *buf, size_t size, u8 *crc)
>> +{
>
>> +   *crc = *buf++;
>
>> +   size--;
>> +
>> +   while (size--)
>
> *crc = 0;
>
> while (size--)
> *crc += *buf++;
>
>  ?

I partially unrolled that look specifically because I wanted to avoid
having that "useless" "*crc = 0" line.

>
>> +   *crc += *buf++;
>> +
>> +   *crc = 1 + ~(*crc);
>> +}
>
> I dunno if lib/crc8.c helps here, worth to check.
>

I did check it out, but I am not sure I can use it: I am hesitant to
outright deny the possibility, but I can't think of a straight
conversion from "2's complement of sum of all bytes" to polynomial
division. Besides csum_8b2c() implements checksum algorithm as it is
described in ICD, so it has the advantage of being easier to double
check.

>> +static void *stuff(unsigned char *dest, const unsigned char *src, size_t n)
>> +{
>
>> +   size_t

Re: [PATCH 071/102] remoteproc/keystone: explicitly request exclusive reset control

[Suman Anna]

On 07/19/2017 10:26 AM, Philipp Zabel wrote:
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
> 
> No functional changes.
> 
> Cc: Ohad Ben-Cohen 
> Cc: Bjorn Andersson 
> Cc: linux-remotep...@vger.kernel.org
> Signed-off-by: Philipp Zabel 

Acked-by: Suman Anna 

> ---
>  drivers/remoteproc/keystone_remoteproc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/remoteproc/keystone_remoteproc.c 
> b/drivers/remoteproc/keystone_remoteproc.c
> index 5f776bfd674a0..920fef072b364 100644
> --- a/drivers/remoteproc/keystone_remoteproc.c
> +++ b/drivers/remoteproc/keystone_remoteproc.c
> @@ -410,7 +410,7 @@ static int keystone_rproc_probe(struct platform_device 
> *pdev)
>   if (ret)
>   goto free_rproc;
>  
> - ksproc->reset = devm_reset_control_get(dev, NULL);
> + ksproc->reset = devm_reset_control_get_exclusive(dev, NULL);
>   if (IS_ERR(ksproc->reset)) {
>   ret = PTR_ERR(ksproc->reset);
>   goto free_rproc;
> 

[PATCH] rtc: sun6i: ensure clk_data is kfree'd on error

[Colin King]

From: Colin Ian King 

There are two error return paths that do not kfree clk_data and
we end up with a memory leak. Fix these with a kfree error exit
path.

Detected by CoverityScan, CID#1402959 ("Resource Leak")

Signed-off-by: Colin Ian King 
---
 drivers/rtc/rtc-sun6i.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index 39cbc1238b92..61502221ab6e 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -204,7 +204,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node)
rtc->base = of_io_request_and_map(node, 0, of_node_full_name(node));
if (IS_ERR(rtc->base)) {
pr_crit("Can't map RTC registers");
-   return;
+   goto err;
}
 
/* Switch to the external, more precise, oscillator */
@@ -216,7 +216,7 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node)
 
/* Deal with old DTs */
if (!of_get_property(node, "clocks", NULL))
-   return;
+   goto err;
 
rtc->int_osc = clk_hw_register_fixed_rate_with_accuracy(NULL,
"rtc-int-osc",
@@ -246,6 +246,10 @@ static void __init sun6i_rtc_clk_init(struct device_node 
*node)
clk_data->num = 1;
clk_data->hws[0] = &rtc->hw;
of_clk_add_hw_provider(node, of_clk_hw_onecell_get, clk_data);
+   return;
+
+err:
+   kfree(clk_data);
 }
 CLK_OF_DECLARE_DRIVER(sun6i_rtc_clk, "allwinner,sun6i-a31-rtc",
  sun6i_rtc_clk_init);
-- 
2.11.0

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Kani, Toshimitsu]

On Wed, 2017-07-19 at 18:22 +0200, Borislav Petkov wrote:
> On Wed, Jul 19, 2017 at 04:10:07PM +, Kani, Toshimitsu wrote:
> > I do prefer to avoid any white / black listing.  But I do not see
> > how it solves the buggy DMI/SMBIOS info as an example of firmware
> > bugs we may have to deal with.
> 
> So how do you want to deal with this?
> 
> Maintain an evergrowing whitelist of platforms which are OK and then
> the moment a new platform comes along, you send a patch to add it to
> that whitelist?
> 
> I'm sure you can see the problems with that approach.

Since ghes_edac has not been used for a long time, I have a feeling
that not so many vendors want to use it.  In the case of HPE, we do not
need to update with each platform since "HPE" "Server" will cover all
platforms we need.

Thanks,
-Toshi

Re: [RFC PATCH v1 00/11] Create fast idle path for short idle periods

[Paul E. McKenney]

On Wed, Jul 19, 2017 at 10:03:22AM -0500, Christopher Lameter wrote:
> On Wed, 19 Jul 2017, Paul E. McKenney wrote:
> 
> > > Do we have any problem if we skip RCU idle enter/exit under a fast idle 
> > > scenario?
> > > My understanding is, if tick is not stopped, then we don't need inform 
> > > RCU in
> > > idle path, it can be informed in irq exit.
> >
> > Indeed, the problem arises when the tick is stopped.
> 
> Well is there a boundary when you would want the notification calls? I
> would think that even an idle period of a couple of seconds does not
> necessarily require a callback to rcu. Had some brokenness here where RCU
> calls did not occur for hours or so. At some point the system ran out of
> memory but thats far off.

Yeah, I should spell this out more completely, shouldn't I?  And get
it into the documentation if it isn't already there...  Where it is
currently at best hinted at.  :-/

1.  If a CPU is either idle or executing in usermode, and RCU believes
it is non-idle, the scheduling-clock tick had better be running.
Otherwise, you will get RCU CPU stall warnings.  Or at best,
very long (11-second) grace periods, with a pointless IPI waking
the CPU each time.

2.  If a CPU is in a portion of the kernel that executes RCU read-side
critical sections, and RCU believes this CPU to be idle, you can get
random memory corruption.  DON'T DO THIS!!!

This is one reason to test with lockdep, which will complain
about this sort of thing.

3.  If a CPU is in a portion of the kernel that is absolutely
positively no-joking guaranteed to never execute any RCU read-side
critical sections, and RCU believes this CPU to to be idle,
no problem.  This sort of thing is used by some architectures
for light-weight exception handlers, which can then avoid the
overhead of rcu_irq_enter() and rcu_irq_exit().  Some go further
and avoid the entireties of irq_enter() and irq_exit().

Just make very sure you are running some of your tests with
CONFIG_PROVE_RCU=y.

4.  If a CPU is executing in the kernel with the scheduling-clock
interrupt disabled and RCU believes this CPU to be non-idle,
and if the CPU goes idle (from an RCU perspective) every few
jiffies, no problem.  It is usually OK for there to be the
occasional gap between idle periods of up to a second or so.

If the gap grows too long, you get RCU CPU stall warnings.

5.  If a CPU is either idle or executing in usermode, and RCU believes
it to be idle, of course no problem.

6.  If a CPU is executing in the kernel, the kernel code
path is passing through quiescent states at a reasonable
frequency (preferably about once per few jiffies, but the
occasional excursion to a second or so is usually OK) and the
scheduling-clock interrupt is enabled, of course no problem.

If the gap between a successive pair of quiescent states grows
too long, you get RCU CPU stall warnings.

For purposes of comparison, the default time until RCU CPU stall warning
in mainline is 21 seconds.  A number of distros set this to 60 seconds.
Back in the 90s, the analogous timeout for DYNIX/ptx was 1.5 seconds.  :-/

Hence "a second or so" instead of your "a couple of seconds".  ;-)

Please see below for the corresponding patch to RCU's requirements.
Thoughts?

Thanx, Paul



commit 693c9bfa43f92570dd362d8834440b418bbb994a
Author: Paul E. McKenney 
Date:   Wed Jul 19 09:52:58 2017 -0700

doc: Set down RCU's scheduling-clock-interrupt needs

This commit documents the situations in which RCU needs the
scheduling-clock interrupt to be enabled, along with the consequences
of failing to meet RCU's needs in this area.

Signed-off-by: Paul E. McKenney 

diff --git a/Documentation/RCU/Design/Requirements/Requirements.html 
b/Documentation/RCU/Design/Requirements/Requirements.html
index 95b30fa25d56..7980bee5607f 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -2080,6 +2080,8 @@ Some of the relevant points of interest are as follows:
Scheduler and RCU.
Tracing and RCU.
Energy Efficiency.
+   
+   Scheduling-Clock Interrupts and RCU.
Memory Efficiency.

Performance, Scalability, Response Time, and Reliability.
@@ -2532,6 +2534,113 @@ I learned of many of these requirements via angry phone 
calls:
 Flaming me on the Linux-kernel mailing list was apparently not
 sufficient to fully vent their ire at RCU's energy-efficiency bugs!
 
+
+Scheduling-Clock Interrupts and RCU
+
+
+The kernel transitions between in-kernel non-idle execution, userspace
+execution, and the idle loop.
+Depending on kerne

Re: [PATCH v1] crypto: caam - set hwrng quality level

[Horia Geantă]

On 7/19/2017 7:32 PM, Oleksij Rempel wrote:
> On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote:
>> On 7/19/2017 10:45 AM, Oleksij Rempel wrote:
>>> According documentation, it is NIST certified TRNG.
>>> So, set high quality to let the HWRNG framework automatically use it.
>>>
>>> Signed-off-by: Oleksij Rempel 
>>> ---
>>>  drivers/crypto/caam/caamrng.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
>>> index 41398da3edf4..684c0bc88dfd 100644
>>> --- a/drivers/crypto/caam/caamrng.c
>>> +++ b/drivers/crypto/caam/caamrng.c
>>> @@ -292,10 +292,16 @@ static int caam_init_rng(struct caam_rng_ctx *ctx, 
>>> struct device *jrdev)
>>> return 0;
>>>  }
>>>  
>>> +/*
>>> + * hwrng register struct
>>> + * The trng is suppost to have 100% entropy, and thus
>>> + * we register with a very high quality value.
>>> + */
>>>  static struct hwrng caam_rng = {
>>> .name   = "rng-caam",
>>> .cleanup= caam_cleanup,
>>> .read   = caam_read,
>>> +   .quality= 999,
>>
>> Why not 1024, i.e. where is 999 coming from?
> 
> It comes from s390-trng.c driver.
> Should I use 1024 instead?
> 
AFAICT the range for quality is from 0 to 1024 (no entropy -> perfect
entropy).

1024 should be used since I'd expect a HW TRNG to provide perfect
entropy unless otherwise stated.

[Cc-ing Harald and Martin for awareness wrt. s390/trng.]

Thanks,
Horia

Re: [PATCH 0/6] FlexRM driver improvements

[Scott Branden]

Patch series all looks good.


On 17-07-19 02:55 AM, Anup Patel wrote:

This patchset does various improvments to Broadcom FlexRM
mailbox controller driver and also adds FlexRM DT nodes
for Stingray SOC.

The patches are based on Linux-4.13-rc1 and can also be
found at flexrm-imp-v1 branch of
https://github.com/Broadcom/arm64-linux.git

Anup Patel (6):
   mailbox: bcm-flexrm-mailbox: Set IRQ affinity hint for FlexRM ring
 IRQs
   mailbox: bcm-flexrm-mailbox: Add debugfs support
   mailbox: bcm-flexrm-mailbox: Fix mask used in CMPL_START_ADDR_VALUE()
   mailbox: Make message send queue size dynamic in Linux mailbox
   mailbox: bcm-flexrm-mailbox: Set msg_queue_len for each channel
   arm64: dts: Add FlexRM DT nodes for Stingray

  .../boot/dts/broadcom/stingray/stingray-fs4.dtsi   |  54 +++
  .../arm64/boot/dts/broadcom/stingray/stingray.dtsi |   2 +
  drivers/mailbox/bcm-flexrm-mailbox.c   | 160 -
  drivers/mailbox/mailbox.c  |  15 +-
  include/linux/mailbox_controller.h |   5 +-
  5 files changed, 227 insertions(+), 9 deletions(-)
  create mode 100644 arch/arm64/boot/dts/broadcom/stingray/stingray-fs4.dtsi


Regards,
 Scott

Re: [PATCH v10 2/3] arm/syscalls: Check address limit on user-mode return

[Thomas Garnier]

On Wed, Jul 19, 2017 at 7:58 AM, Leonard Crestez
 wrote:
> On Tue, 2017-07-18 at 12:04 -0700, Thomas Garnier wrote:
>> On Tue, Jul 18, 2017 at 10:18 AM, Leonard Crestez  
>> wrote:
>> > On Tue, 2017-07-18 at 09:04 -0700, Thomas Garnier wrote:
>> > > On Tue, Jul 18, 2017 at 7:36 AM, Leonard Crestez 
>> > >  wrote:
>> > > > On Wed, 2017-06-14 at 18:12 -0700, Thomas Garnier wrote:
>> > > > >
>> > > > > Ensure the address limit is a user-mode segment before returning to
>> > > > > user-mode. Otherwise a process can corrupt kernel-mode memory and
>> > > > > elevate privileges [1].
>> > > > >
>> > > > > The set_fs function sets the TIF_SETFS flag to force a slow path on
>> > > > > return. In the slow path, the address limit is checked to be USER_DS 
>> > > > > if
>> > > > > needed.
>> > > > >
>> > > > > The TIF_SETFS flag is added to _TIF_WORK_MASK shifting 
>> > > > > _TIF_SYSCALL_WORK
>> > > > > for arm instruction immediate support. The global work mask is too 
>> > > > > big
>> > > > > to used on a single instruction so adapt ret_fast_syscall.
>> > > > >
>> > > > > @@ -571,6 +572,10 @@ do_work_pending(struct pt_regs *regs, unsigned 
>> > > > > int thread_flags, int syscall)
>> > > > >* Update the trace code with the current status.
>> > > > >*/
>> > > > >   trace_hardirqs_off();
>> > > > > +
>> > > > > + /* Check valid user FS if needed */
>> > > > > + addr_limit_user_check();
>> > > > > +
>> > > > >   do {
>> > > > >   if (likely(thread_flags & _TIF_NEED_RESCHED)) {
>> > > > >   schedule();
>> > > > This patch made it's way into linux-next next-20170717 and it seems to
>> > > > cause hangs when booting some boards over NFS (found via bisection). I
>> > > > don't know exactly what determines the issue but I can reproduce hangs
>> > > > if even if I just boot with init=/bin/bash and do stuff like
>> > > >
>> > > > # sleep 1 & sleep 1 & sleep 1 & wait; wait; wait; echo done!
>> > > >
>> > > > When this happens sysrq-t shows a sleep task hung in the 'R' state
>> > > > spinning in do_work_pending, so maybe there is a potential infinite
>> > > > loop here?
>> > > >
>> > > > The addr_limit_user_check at the start of do_work_pending will check
>> > > > for TIF_FSCHECK once and clear it but the function loops while
>> > > > (thread_flags & _TIF_WORK_MASK), so it if TIF_FSCHECK is set again then
>> > > > the loop will never terminate. Does this make sense?
>> > >
>> > > Yes, it does. Thanks for looking into this.
>> > >
>> > > Can you try this change?
>> > >
>> > > diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
>> > > index 3a48b54c6405..bc6ad7789568 100644
>> > > --- a/arch/arm/kernel/signal.c
>> > > +++ b/arch/arm/kernel/signal.c
>> > > @@ -573,12 +573,11 @@ do_work_pending(struct pt_regs *regs, unsigned
>> > > int thread_flags, int syscall)
>> > >   */
>> > >   trace_hardirqs_off();
>> > >
>> > > - /* Check valid user FS if needed */
>> > > - addr_limit_user_check();
>> > > -
>> > >   do {
>> > >   if (likely(thread_flags & _TIF_NEED_RESCHED)) {
>> > >   schedule();
>> > > + } else if (thread_flags & _TIF_FSCHECK) {
>> > > + addr_limit_user_check();
>> > >   } else {
>> > >   if (unlikely(!user_mode(regs)))
>> > >   return 0;
>> > This does seem to work, it no longer hangs on boot in my setup. This is
>> > obviously only a very superficial test.
>> >
>> > The new location of this check seems weird, it's not clear why it
>> > should be on an else path. Perhaps it should be moved to right before
>> > where current_thread_info()->flags is fetched again?
>
>> I was hitting bug when I tried that.I think that's because you
>> basically let the signal handler do pending work before you check the
>> flag, that's not a good idea.
>
>> > If the purpose is hardening against buggy kernel code doing bad set_fs
>> > calls shouldn't this flag also be checked before looking at
>> > TIF_NEED_RESCHED and calling schedule()?
>> I am not sure to be honest. I expected schedule to only schedule the
>> processor to another task which would be fine given only the current
>> task have a bogus fs. I will put it first in case there is an edge
>> case scenario I missed.
>>
>> What do you think? Let me know and I will look at changes all
>> architectures and testing them.
>
> I don't know and I'd rather not guess on security issues. It's better
> if someone else reviews the code.
>
> Unless there is a very quick fix maybe this series should be removed or
> reverted from linux-next? A diagnosis of "system calls can sometimes
> hang on return" seems serious even for linux-next. Since it happens
> very rarely in most setups I can easily imagine somebody spending a lot
> of time digging at this.

I will send fixes for each architecture in the meantime.

>
> --
> Regards,
> Leonard



-- 
Thomas

Re: [PATCH 5/5] vfio: platform: reset: Add Broadcom FlexRM reset module

[Scott Branden]

Hi Anup,

NAK - as indicated in internal review please use unmodified Broadcom 
legal header in its own comment block.



On 17-07-19 02:33 AM, Anup Patel wrote:

This patch adds low-level reset for Broadcom FlexRM to
VFIO platform.

It will do the following:
1. Disable/Deactivate each FlexRM ring
2. Flush each FlexRM ring

The cleanup sequence for FlexRM rings is adapted from
Broadcom FlexRM mailbox driver.

Signed-off-by: Anup Patel 
Reviewed-by: Oza Oza 
Reviewed-by: Scott Branden 
---
  drivers/vfio/platform/reset/Kconfig|  9 +++
  drivers/vfio/platform/reset/Makefile   |  1 +
  .../vfio/platform/reset/vfio_platform_bcmflexrm.c  | 91 ++
  3 files changed, 101 insertions(+)
  create mode 100644 drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c

diff --git a/drivers/vfio/platform/reset/Kconfig 
b/drivers/vfio/platform/reset/Kconfig
index 705..8d8d226 100644
--- a/drivers/vfio/platform/reset/Kconfig
+++ b/drivers/vfio/platform/reset/Kconfig
@@ -13,3 +13,12 @@ config VFIO_PLATFORM_AMDXGBE_RESET
  Enables the VFIO platform driver to handle reset for AMD XGBE
  
  	  If you don't know what to do here, say N.

+
+config VFIO_PLATFORM_BCMFLEXRM_RESET
+   tristate "VFIO support for Broadcom FlexRM reset"
+   depends on VFIO_PLATFORM
+   depends on ARCH_BCM_IPROC || COMPILE_TEST
+   help
+ Enables the VFIO platform driver to handle reset for Broadcom FlexRM
+
+ If you don't know what to do here, say N.
diff --git a/drivers/vfio/platform/reset/Makefile 
b/drivers/vfio/platform/reset/Makefile
index 93f4e23..8d9874b 100644
--- a/drivers/vfio/platform/reset/Makefile
+++ b/drivers/vfio/platform/reset/Makefile
@@ -5,3 +5,4 @@ ccflags-y += -Idrivers/vfio/platform
  
  obj-$(CONFIG_VFIO_PLATFORM_CALXEDAXGMAC_RESET) += vfio-platform-calxedaxgmac.o

  obj-$(CONFIG_VFIO_PLATFORM_AMDXGBE_RESET) += vfio-platform-amdxgbe.o
+obj-$(CONFIG_VFIO_PLATFORM_BCMFLEXRM_RESET) += vfio_platform_bcmflexrm.o
diff --git a/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c 
b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
new file mode 100644
index 000..a890472
--- /dev/null
+++ b/drivers/vfio/platform/reset/vfio_platform_bcmflexrm.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ *

*/
Place additional comments in different comment block.
/*

+ * This driver provides reset support for Broadcom FlexRM ring manager
+ * to VFIO platform.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vfio_platform_private.h"
+
+/* FlexRM configuration */
+#define RING_REGS_SIZE 0x1
+#define RING_VER_MAGIC 0x76303031
+
+/* Per-Ring register offsets */
+#define RING_VER   0x000
+#define RING_CONTROL   0x034
+#define RING_FLUSH_DONE0x038
+
+/* Register RING_CONTROL fields */
+#define CONTROL_FLUSH_SHIFT5
+#define CONTROL_ACTIVE_SHIFT   4
+
+/* Register RING_FLUSH_DONE fields */
+#define FLUSH_DONE_MASK0x1
+
+static void vfio_platform_bcmflexrm_shutdown(void __iomem *ring)
+{
+   unsigned int timeout;
+
+   /* Disable/inactivate ring */
+   writel_relaxed(0x0, ring + RING_CONTROL);
+
+   /* Flush ring with timeout of 1s */
+   timeout = 1000;
+   writel_relaxed(BIT(CONTROL_FLUSH_SHIFT), ring + RING_CONTROL);
+   do {
+   if (readl_relaxed(ring + RING_FLUSH_DONE) & FLUSH_DONE_MASK)
+   break;
+   mdelay(1);
+   } while (timeout--);
+
+   if (!timeout)
+   pr_warn("VFIO FlexRM shutdown timedout\n");
+}
+
+static int vfio_platform_bcmflexrm_reset(struct vfio_platform_device *vdev)
+{
+   void __iomem *ring;
+   struct vfio_platform_region *reg = &vdev->regions[0];
+
+   /* Map FlexRM ring registers if not mapped */
+   if (!reg->ioaddr) {
+   reg->ioaddr = ioremap_nocache(reg->addr, reg->size);
+   if (!reg->ioaddr)
+   return -ENOMEM;
+   }
+
+   /* Discover and shutdown each FlexRM ring */
+   for (ring = reg->ioaddr;
+ring < (reg->ioaddr + reg->size); ring += RING_REGS_SIZE) {
+   if (rea

Re: [PATCH v2] drm/i915: Consistently use enum pipe for PCH transcoders

[Matthias Kaehlcke]

El Wed, Jul 19, 2017 at 08:30:36AM +0200 Daniel Vetter ha dit:

> On Tue, Jul 18, 2017 at 01:48:53PM -0700, Matthias Kaehlcke wrote:
> > Hi Daniel,
> > 
> > El Tue, Jul 18, 2017 at 08:39:50AM +0200 Daniel Vetter ha dit:
> > 
> > > On Mon, Jul 17, 2017 at 11:14:03AM -0700, Matthias Kaehlcke wrote:
> > > > The current code uses in some instances enum transcoder for PCH
> > > > transcoders and enum pipe in others. This is error prone and clang
> > > > raises warnings like this:
> > > > 
> > > > drivers/gpu/drm/i915/intel_dp.c:3546:51: warning: implicit conversion
> > > >   from enumeration type 'enum pipe' to different enumeration type
> > > >   'enum transcoder' [-Wenum-conversion]
> > > > intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
> > > > 
> > > > Consistently use the type enum pipe for PCH transcoders.
> > > > 
> > > > Signed-off-by: Matthias Kaehlcke 
> > > 
> > > Somehow git apply-mbox could parse it, but manually applying using patch
> > > worked. Not sure what's going on, maybe double-check it's all right.
> > 
> > Not sure what happened, one of the patch fragments only has one '@'
> > instead of two, with that fixed the patch applies.
> > 
> > Unfortunately the manual application missed some fragments:
> > 
> > drivers/gpu/drm/i915/intel_display.c:5350:51: warning: implicit
> >   conversion from enumeration type 'enum transcoder' to different
> >   enumeration type 'enum pipe' [-Wenum-conversion]
> > intel_set_pch_fifo_underrun_reporting(dev_priv, 
> > TRANSCODER_A,
> > ~   ^~~~
> > drivers/gpu/drm/i915/intel_display.c:5436:51: warning: implicit
> >   conversion from enumeration type 'enum transcoder' to different
> >   enumeration type 'enum pipe' [-Wenum-conversion]
> > intel_set_pch_fifo_underrun_reporting(dev_priv, 
> > TRANSCODER_A,
> > ~   ^~~~
> > drivers/gpu/drm/i915/intel_display.c:5534:51: warning: implicit
> >   conversion from enumeration type 'enum transcoder' to different
> >   enumeration type 'enum pipe' [-Wenum-conversion]
> > intel_set_pch_fifo_underrun_reporting(dev_priv, 
> > TRANSCODER_A,
> > ~   ^~~~
> > drivers/gpu/drm/i915/intel_display.c:5563:51: warning: implicit
> >   conversion from enumeration type 'enum transcoder' to different
> >   enumeration type 'enum pipe' [-Wenum-conversion]
> > intel_set_pch_fifo_underrun_reporting(dev_priv, 
> > TRANSCODER_A,
> > 
> > 
> > What would be the best way forward from here? Revert the manual
> > application and apply again, or a fixup patch?
> 
> Drat I screwed up :-( drm-intel-next-queued is non-rebasing, that means I
> need a fixup patch. I should have checked more carefully that I have all
> the hunks, but patch -p1 seemed happy ...

Ok, I will send a fixup patch shortly

Matthias

Re: [PATCH] netvsc: Remove redundant use of ipv6_hdr()

[Stephen Hemminger]

On Wed, 19 Jul 2017 15:19:28 +0200
Mohammed Gamal  wrote:

> This condition already uses an object of type ipv6hdr in the line above.
> Use the object directly instead of calling ipv6_hdr
> 
> Signed-off-by: Mohammed Gamal 
> ---
>  drivers/net/hyperv/netvsc_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
> index 63c98bb..06d591c 100644
> --- a/drivers/net/hyperv/netvsc_drv.c
> +++ b/drivers/net/hyperv/netvsc_drv.c
> @@ -339,7 +339,7 @@ static u32 net_checksum_info(struct sk_buff *skb)
>  
>   if (ip6->nexthdr == IPPROTO_TCP)
>   return TRANSPORT_INFO_IPV6_TCP;
> - else if (ipv6_hdr(skb)->nexthdr == IPPROTO_UDP)
> + else if (ip6->nexthdr == IPPROTO_UDP)
>   return TRANSPORT_INFO_IPV6_UDP;
>   }
>  

Patch looks fine.
Network patches go through net...@vger.kernel.org not linux driver mailing list.
I will add it to my next patch of patches that are going to netdev for net-next.

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Kani, Toshimitsu]

On Tue, 2017-07-18 at 18:15 -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 18 Jul 2017 19:58:54 +
 :
> We had a similar discussion several years ago when I wrote this
> driver. On that time, I talked with Red Hat, HP, Dell, Intel people
> and with some customers with large clusters.
> 
> The way it is, ghes_edac is a poor man's driver. What it hopefully
> provide is a detection that an error happened, without really telling
> the user what component should be replaced.

"poor man's driver" is a bit misleading, but yes, firmware-first
platforms have RAS features built-into the platforms, and they do not
need intelligence in EDAC drivers, which may conflict with the
platform's RAS features.  I cannot speak for other vendors, but HPE
platforms log errors and provide FRU info.  ghes_edac allows to report
errors to OS management tools like rasdaemon in addition to platform-
specific managements.

> Ok, on machines with their own error reporting mechanism (like
> HP servers), a sys admin can look on some proprietary software
> (or bios), in order to identify what happened.
> 
> Yet, BIOS doesn't provide any glue about what's the memory
> architecture, as it maps memory as if it was a single DIMM memory:
> 
> (from ghes_edac_register)
> 
>   layers[0].type = EDAC_MC_LAYER_ALL_MEM;
>   layers[0].size = num_dimm;
>   layers[0].is_virt_csrow = true;
> 
> So, even on systems where the BIOS actually knows how the memory
> cards are wired, it will mask the memory controller data.
> 
> Now, the EDAC driver can also be used to identify what
> channels are used. That helps the sys admin to know if the
> memories are connected in a way that it will be using multiple
> channels, or not, helping to setup the machine to obtain
> the maximum possible performance.
> 
> So, for example, on my Intel-based HP server, I can check
> such info with:
> 
> $ ras-mc-ctl --mainboard
> ras-mc-ctl: mainboard: HP model ProLiant ML350 Gen9
> $ ras-mc-ctl --layout
>    +-
> --+
>    |mc0|mc1  
>   |
>    | channel0  | channel1  | channel2  | channel0  | channel1  |
> channel2  |
> ---+-
> --+
> slot2: | 0 MB  | 0 MB  | 0 MB  | 0 MB  | 0
> MB  | 0 MB  |
> slot1: | 0 MB  | 0 MB  | 0 MB  | 0 MB  | 0
> MB  | 0 MB  |
> slot0: |  16384 MB  | 0 MB  |  16384 MB  |  16384 MB  | 0
> MB  |  16384 MB  |
> ---+-
> --+
> 
> So, I know that both CPUs will be connected to my memories, and,
> on both, it is using 2 channels.
> 
> If I was using the ghes driver, that information would be hidden.
> 
> So, due to all problems with ghes, it is enabled only if there are no
> better solution, e. g. on systems where there's no way to talk
> directly to the hardware (like on E7 Xeon machines, where the memory
> controller is actually on a separate chip that are controlled only by
> the BIOS).

Thanks for the info!  That's very helpful.  I will check to see if
ghes_edac provides enough info that we need.
-Toshi

Re: [PATCH] mm/mremap: Fail map duplication attempts for private mappings

[Mike Kravetz]

On 07/13/2017 12:11 PM, Vlastimil Babka wrote:
> [+CC linux-api]
> 
> On 07/13/2017 05:58 PM, Mike Kravetz wrote:
>> mremap will create a 'duplicate' mapping if old_size == 0 is
>> specified.  Such duplicate mappings make no sense for private
>> mappings.  If duplication is attempted for a private mapping,
>> mremap creates a separate private mapping unrelated to the
>> original mapping and makes no modifications to the original.
>> This is contrary to the purpose of mremap which should return
>> a mapping which is in some way related to the original.
>>
>> Therefore, return EINVAL in the case where if an attempt is
>> made to duplicate a private mapping.
>>
>> Signed-off-by: Mike Kravetz 
> 
> Acked-by: Vlastimil Babka 

After considering Michal's concerns with follow on patch, it appears
this patch provides the most desired behavior.  Any other concerns
or issues with this patch?

If this moves forward, I will create man page updates to describe the
mremap(old_size == 0) behavior.

-- 
Mike Kravetz

> 
>> ---
>>  mm/mremap.c | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/mm/mremap.c b/mm/mremap.c
>> index cd8a1b1..076f506 100644
>> --- a/mm/mremap.c
>> +++ b/mm/mremap.c
>> @@ -383,6 +383,13 @@ static struct vm_area_struct *vma_to_resize(unsigned 
>> long addr,
>>  if (!vma || vma->vm_start > addr)
>>  return ERR_PTR(-EFAULT);
>>  
>> +/*
>> + * !old_len  is a special case where a mapping is 'duplicated'.
>> + * Do not allow this for private mappings.
>> + */
>> +if (!old_len && !(vma->vm_flags & (VM_SHARED | VM_MAYSHARE)))
>> +return ERR_PTR(-EINVAL);
>> +
>>  if (is_vm_hugetlb_page(vma))
>>  return ERR_PTR(-EINVAL);
>>  
>>
> 

[PATCH] MAINTAINERS: fpga: Update email and add patchwork URL

[Moritz Fischer]

Add Q: entry for patchwork and update my email address.

Signed-off-by: Moritz Fischer 
Cc: Alan Tull 
Cc: linux-f...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f42daf7..ea690a6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5213,10 +5213,11 @@ K:  fmc_d.*register
 
 FPGA MANAGER FRAMEWORK
 M: Alan Tull 
-R: Moritz Fischer 
+R: Moritz Fischer 
 L: linux-f...@vger.kernel.org
 S: Maintained
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/atull/linux-fpga.git
+Q: http://patchwork.kernel.org/project/linux-fpga/list/
 F: Documentation/fpga/
 F: Documentation/devicetree/bindings/fpga/
 F: drivers/fpga/
-- 
2.7.4

Re: [PATCH 4.12 00/84] 4.12.3-stable review

[Shuah Khan]

On 07/19/2017 10:29 AM, kernelci.org bot wrote:
> stable-rc/linux-4.12.y boot: 166 boots: 5 failed, 161 passed 
> (v4.12.2-85-g908a8d27d1c5)
> 
> Full Boot Summary: 
> https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
> Full Build Summary: 
> https://kernelci.org/build/stable-rc/branch/linux-4.12.y/kernel/v4.12.2-85-g908a8d27d1c5/
> 
> Tree: stable-rc
> Branch: linux-4.12.y
> Git Describe: v4.12.2-85-g908a8d27d1c5
> Git Commit: 908a8d27d1c52aaafab80d7267e8e61f9a174ecc
> Git URL: 
> http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Tested: 44 unique boards, 14 SoC families, 24 builds out of 204
> 
> Boot Regressions Detected:
> 
> arm:
> 
> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> exynos5422-odroidxu3:
> lab-collabora: new failure (last pass: v4.12.2)

I am seeing boot failure on odroid-xu4 with 4.13-rc1 with exynos_defconfig.
4.12 is fine.

I am debugging this and based on this report it sounds like it might be
easier for me to start with 4.12 and try to isolate the change. Will keep
you posted.

-- Shuah

> 
> Boot Failures Detected:
> 
> arm:
> 
> multi_v7_defconfig
> imx6ul-pico-hobbit_rootfs:nfs: 1 failed lab
> 
> tegra_defconfig
> tegra124-jetson-tk1_rootfs:nfs: 1 failed lab
> 
> mvebu_v5_defconfig
> kirkwood-openblocks_a7_rootfs:nfs: 1 failed lab
> 
> multi_v7_defconfig+CONFIG_PROVE_LOCKING=y
> exynos5422-odroidxu3: 1 failed lab
> omap4-panda: 1 failed lab
> 
> ---
> For more info write to 
> 

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

[Tejun Heo]

Hello, Peter.

On Wed, Jul 19, 2017 at 04:07:28PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 18, 2017 at 02:47:14PM -0400, Tejun Heo wrote:
> > Were there other things that caught your eyes?
> 
> I didn't immediately see the point of "domain (threaded" output, and I

I'll probably drop the parens but I think it's meaningful to show the
state to userland as it affects what users can and can't do.

> think it might be useful to have a "threaded" column in /proc/cgroups.

Will add that.  We *might* want cgroup.controllers_threaded too but we
can think about that later.

> But no, I've been over this a few times now and I think we're good.
> 
> Yes, I think we can work with this. Thanks!

Awesome.  I'll update the patchset.

Thanks a lot for the inputs and patience!

-- 
tejun

Re: [PATCH V3 8/9] cpufreq: Add CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING cpufreq driver flag

[Dominik Brodowski]

On Wed, Jul 19, 2017 at 03:42:48PM +0530, Viresh Kumar wrote:
> The policy->transition_latency field is used for multiple purposes
> today and its not straight forward at all. This is how it is used:
> 
> A. Set the correct transition_latency value.
> 
> B. Set it to CPUFREQ_ETERNAL because:
>1. We don't want automatic dynamic switching (with
>   ondemand/conservative) to happen at all.
>2. We don't know the transition latency.
> 
> This patch handles the B.1. case in a more readable way. A new flag for
> the cpufreq drivers is added to disallow use of cpufreq governors which
> have dynamic_switching flag set.
> 
> All the current cpufreq drivers which are setting transition_latency
> unconditionally to CPUFREQ_ETERNAL are updated to use it. They don't
> need to set transition_latency anymore.
> 
> There shouldn't be any functional change after this patch.
> 
> Signed-off-by: Viresh Kumar 

Looks good to me, so feel free to add:

Reviewed-by: Dominik Brodowski 

Best,
Dominik


signature.asc
Description: PGP signature

Re: [PATCH v1] crypto: caam - set hwrng quality level

[Oleksij Rempel]

On Wed, Jul 19, 2017 at 12:49:47PM +, Horia Geantă wrote:
> On 7/19/2017 10:45 AM, Oleksij Rempel wrote:
> > According documentation, it is NIST certified TRNG.
> > So, set high quality to let the HWRNG framework automatically use it.
> > 
> > Signed-off-by: Oleksij Rempel 
> > ---
> >  drivers/crypto/caam/caamrng.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
> > index 41398da3edf4..684c0bc88dfd 100644
> > --- a/drivers/crypto/caam/caamrng.c
> > +++ b/drivers/crypto/caam/caamrng.c
> > @@ -292,10 +292,16 @@ static int caam_init_rng(struct caam_rng_ctx *ctx, 
> > struct device *jrdev)
> > return 0;
> >  }
> >  
> > +/*
> > + * hwrng register struct
> > + * The trng is suppost to have 100% entropy, and thus
> > + * we register with a very high quality value.
> > + */
> >  static struct hwrng caam_rng = {
> > .name   = "rng-caam",
> > .cleanup= caam_cleanup,
> > .read   = caam_read,
> > +   .quality= 999,
> 
> Why not 1024, i.e. where is 999 coming from?

It comes from s390-trng.c driver.
Should I use 1024 instead?

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 5/6] cgroup: implement cgroup v2 thread support

[Tejun Heo]

Hello,

On Tue, Jul 18, 2017 at 01:23:14PM -0400, Waiman Long wrote:
> > If we could get rid of the invalid state completely that way, I'd
> > completely agree with you but that isn't the case here as you noted
> > yourself, so the choice between the two isn't something trivially
> > clear.  Both choices come with their pros and cons.  We can absoultely
> > discuss them comparing the pros and cons.
>
> I am not advocating on removing the invalid state now as I note about

Yeah, removing invalid state would be great but we can't at least yet.

> sibling cgroups. I am just saying that there is no point in not doing an
> automatic conversion to threaded for newly created children of threaded
> cgroups (not thread root). I don't see any cons in doing that.

So, the cons I see is inconsistency, now and in the future.

This may seem less clear with system root because we can have both
domain and theraded children below it, which makes a newly created
cgroup being a domain seem natural.  More importantly, we can't do it
any other way because we'd break existing users otherwise - creating a
threaded cgroup would cause future first level cgroups to be threaded
which will be very unexpected.

Let's think about a non-root threaded domain.  At least for now, a
non-root threaded domain is terminal - they can't host valid domain
children.  As the alternative term "thread root" implies, the threaded
domain can be the root of a threaded subtree and nothing else, so it's
kinda weird to make a new child cgroup there start out as a domain
which can't be used, just like it'd be for the second level descendant
cgroup.

However, the alternative is even stranger.  Let's say we make the
first level child automatically threaded, but that is inconsistent
with when we first enable threaded mode.  We either would have to turn
all siblings at the same time or disallow enabling threaded mode if
there are domain siblings, which I fear would be unnecessarily
restrictive.

Another point is that what if we eventually make non-root threaded
roots able to host domain children?  Making children automatically
threaded wouldn't make any sense then, right?  I'll come back to this
later.

So, it looks like if we're gonna automatically turn on threaded mode
for new cgroups, the only thing we can do right now is what you're
suggesting; however, we didn't arrive there through some
straight-forward intuition or overall design.  It started as a simple
idea (I want it to be automatic) but the end result is a contorted
destination shaped by constraints and happenstance.

To me, behaving differently on the first-level threaded children than
on second+ level ones is too strange to be justified by the
convenience of not having to turn on threaded on new cgroups.

On top of that, what happens if we get to implement PeterZ's idea of
skipping over threaded internal cgroups to allow domains under
threaded subtrees?  That'd imply that we'd be able to host domains
under threaded domains too.  The end result would be completely
non-sensical.  We'd be defaulting to different modes for different
reasons where half of those reasons won't hold anymore.  This isn't
surprising given that there's nothing actually consistent about the
suggested default behavior.

So, that's why I think it'd be better to be simple here, even if that
adds a bit of hassle when creating threded children.  It is simple and
consistent and can stay that way even if we make the hierarchy more
flexible in the future.

Thanks.

-- 
tejun

Re: [PATCH v3 3/5] dax: use common 4k zero page for dax mmap reads

[Ross Zwisler]

On Wed, Jul 19, 2017 at 05:33:14PM +0200, Jan Kara wrote:
> On Wed 28-06-17 16:01:50, Ross Zwisler wrote:
> > Another major change is that we remove dax_pfn_mkwrite() from our fault
> > flow, and instead rely on the page fault itself to make the PTE dirty and
> > writeable.  The following description from the patch adding the
> > vm_insert_mixed_mkwrite() call explains this a little more:
> > 
> > ***
> >   To be able to use the common 4k zero page in DAX we need to have our PTE
> >   fault path look more like our PMD fault path where a PTE entry can be
> >   marked as dirty and writeable as it is first inserted, rather than
> >   waiting for a follow-up dax_pfn_mkwrite() => finish_mkwrite_fault() call.
> > 
> >   Right now we can rely on having a dax_pfn_mkwrite() call because we can
> >   distinguish between these two cases in do_wp_page():
> > 
> > case 1: 4k zero page => writable DAX storage
> > case 2: read-only DAX storage => writeable DAX storage
> > 
> >   This distinction is made by via vm_normal_page().  vm_normal_page()
> >   returns false for the common 4k zero page, though, just as it does for
> >   DAX ptes.  Instead of special casing the DAX + 4k zero page case, we will
> >   simplify our DAX PTE page fault sequence so that it matches our DAX PMD
> >   sequence, and get rid of dax_pfn_mkwrite() completely.
> > 
> >   This means that insert_pfn() needs to follow the lead of insert_pfn_pmd()
> >   and allow us to pass in a 'mkwrite' flag.  If 'mkwrite' is set
> >   insert_pfn() will do the work that was previously done by wp_page_reuse()
> >   as part of the dax_pfn_mkwrite() call path.
> > ***
> 
> Hum, thinking about this in context of this patch... So what if we have
> allocated storage, a process faults it read-only, we map it to page tables
> writeprotected. Then the process writes through mmap to the area - the code
> in handle_pte_fault() ends up in do_wp_page() if I'm reading it right.

Yep.

> Then, since we are missing ->pfn_mkwrite() handlers, the PTE will be marked
> writeable but radix tree entry stays clean - bug. Am I missing something?

I don't think we ever end up with a writeable PTE but with a clean radix tree
entry.  When we get the write fault we do a full fault through
dax_iomap_pte_fault() and dax_insert_mapping().

dax_insert_mapping() sets up the dirty radix tree entry via
dax_insert_mapping_entry() before it does anything with the page tables via
vm_insert_mixed_mkwrite().

So, this mkwrite fault path is exactly the path we would have taken if the
initial read to real storage hadn't happened, and we end up in the same end
state - with a dirty DAX radix tree entry and a writeable PTE.

Re: [PATCH] ath10k_htt_rx_amsdu_allowed(): use ath10k_dbg()

[Joe Perches]

On Wed, 2017-07-19 at 17:37 +0200, Gabriel C wrote:
>  Each time we get disconencted from AP we get flooded with messages 
> like:
> 
>  ...
>  ath10k_pci :03:00.0: no channel configured; ignoring frame(s)!
>  
>  ath10k_warn: 155 callbacks suppressed

[]

> diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
> b/drivers/net/wireless/ath/ath10k/htt_rx.c
[]
> @@ -1514,7 +1514,7 @@ static bool ath10k_htt_rx_amsdu_allowed(struct ath10k 
> *ar,
>   */
> 
>  if (!rx_status->freq) {
> -   ath10k_warn(ar, "no channel configured; ignoring 
> frame(s)!\n");
> +   ath10k_dbg(ar, ATH10K_DBG_HTT, "no channel configured; 
> ignoring frame(s)!\n");
>  return false;
>  }

Hi.  This doesn't apply because of tab to space conversions.

Please use git send-email to send your patch.

Maybe read Documentation/process/email-clients.rst

[PATCH v4 2/3] of: overlay: correctly apply overlay node with unit-address

[frowand . list]

From: Frank Rowand 

Correct existing node name detection when overlay node name has
a unit-address.

Expected test result is overlay will update the nodes and properties
for /testcase-data-2/fairway-1/ride@100/ after this commit.

Before this commit:

   Console error message near end of unittest:
  OF: Duplicate name in fairway-1, renamed to "ride@100#1"

   $ cd /proc/device-tree/testcase-data-2/fairway-1/
   $ # extra node: ride@100#1
   $ ls
   #address-cells  linux,phandle   phandle ride@200
   #size-cells nameride@100status
   compatible  orientation ride@100#1
   $ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/
   $ ls track@30/incline-up
   ls: track@30/incline-up: No such file or directory
   $ ls track@40/incline-up
   ls: track@40/incline-up: No such file or directory

After this commit:

   Console error message no longer occurs

   $ cd /proc/device-tree/testcase-data-2/fairway-1/
   $ # no extra node: ride@100#1
   $ ls
   #address-cells  compatible  namephandle ride@200
   #size-cells linux,phandle   orientation ride@100status
   $ cd /proc/device-tree/testcase-data-2/fairway-1/ride@100/
   $ ls track@30/incline-up
   track@30/incline-up
   $ ls track@40/incline-up
   track@40/incline-up

Signed-off-by: Frank Rowand 
---
 drivers/of/overlay.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index c0e4ee1cd1ba..bd3c32f2d411 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -130,7 +130,10 @@ static int of_overlay_apply_single_device_node(struct 
of_overlay *ov,
return -ENOMEM;
 
/* NOTE: Multiple mods of created nodes not supported */
-   tchild = of_get_child_by_name(target, cname);
+   for_each_child_of_node(target, tchild)
+   if (!of_node_cmp(cname, kbasename(tchild->full_name)))
+   break;
+
if (tchild != NULL) {
/* new overlay phandle value conflicts with existing value */
if (child->phandle)
-- 
Frank Rowand 

[PATCH v4 1/3] of: overlay: add overlay unittest data for node names and symbols

[frowand . list]

From: Frank Rowand 

Add nodes and properties to overlay_base and overlay dts files to
test for
   - incorrect existing node name detection when overlay node name
 has a unit-address
   - adding overlay __symbols__ properties to live tree when an
 overlay is added to the live tree

The following console messages will appear near the end of unittest
until the code errors are corrected:

   OF: Duplicate name in fairway-1, renamed to "ride@100#1"

   ### dt-test ### FAIL of_unittest_overlay_high_level():2296 Adding overlay 
'overlay_bad_symbol' failed

   ### dt-test ### end of unittest - 190 passed, 1 failed

Signed-off-by: Frank Rowand 
---
 drivers/of/unittest-data/Makefile   | 19 ++-
 drivers/of/unittest-data/overlay.dts| 25 -
 drivers/of/unittest-data/overlay_bad_symbol.dts | 22 ++
 drivers/of/unittest-data/overlay_base.dts   | 11 +++
 drivers/of/unittest.c   | 10 --
 5 files changed, 79 insertions(+), 8 deletions(-)
 create mode 100644 drivers/of/unittest-data/overlay_bad_symbol.dts

diff --git a/drivers/of/unittest-data/Makefile 
b/drivers/of/unittest-data/Makefile
index 6e00a9c69e58..2d135fba94c1 100644
--- a/drivers/of/unittest-data/Makefile
+++ b/drivers/of/unittest-data/Makefile
@@ -1,18 +1,27 @@
 obj-y += testcases.dtb.o
+
+targets += testcases.dtb testcases.dtb.S
+
+ifdef CONFIG_OF_OVERLAY
+
 obj-y += overlay.dtb.o
 obj-y += overlay_bad_phandle.dtb.o
+obj-y += overlay_bad_symbol.dtb.o
 obj-y += overlay_base.dtb.o
 
-targets += testcases.dtb testcases.dtb.S
 targets += overlay.dtb overlay.dtb.S
 targets += overlay_bad_phandle.dtb overlay_bad_phandle.dtb.S
+targets += overlay_bad_symbol.dtb overlay_bad_symbol.dtb.S
 targets += overlay_base.dtb overlay_base.dtb.S
 
-.PRECIOUS: \
-   $(obj)/%.dtb.S \
-   $(obj)/%.dtb
-
 # enable creation of __symbols__ node
 DTC_FLAGS_overlay := -@
 DTC_FLAGS_overlay_bad_phandle := -@
+DTC_FLAGS_overlay_bad_symbol := -@
 DTC_FLAGS_overlay_base := -@
+
+endif
+
+.PRECIOUS: \
+   $(obj)/%.dtb.S \
+   $(obj)/%.dtb
diff --git a/drivers/of/unittest-data/overlay.dts 
b/drivers/of/unittest-data/overlay.dts
index 6cd7e6a0c13e..60abf5b55cae 100644
--- a/drivers/of/unittest-data/overlay.dts
+++ b/drivers/of/unittest-data/overlay.dts
@@ -25,7 +25,22 @@
#size-cells = <1>;
status = "ok";
 
-   ride@200 {
+   ride@100 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   track@30 {
+   incline-up = < 48 32 16 >;
+   };
+
+   track@40 {
+   incline-up = < 47 31 15 >;
+   };
+   };
+
+   ride_200: ride@200 {
+   #address-cells = <1>;
+   #size-cells = <1>;
compatible = "ot,ferris-wheel";
reg = < 0x0200 0x100 >;
hvac-provider = < &hvac_2 >;
@@ -36,6 +51,14 @@
spin-rph = < 30 >;
gondolas = < 16 >;
gondola-capacity = < 6 >;
+
+   ride_200_left: track@10 {
+   reg = < 0x0010 0x10 >;
+   };
+
+   ride_200_right: track@20 {
+   reg = < 0x0020 0x10 >;
+   };
};
};
};
diff --git a/drivers/of/unittest-data/overlay_bad_symbol.dts 
b/drivers/of/unittest-data/overlay_bad_symbol.dts
new file mode 100644
index ..09261cb9a67e
--- /dev/null
+++ b/drivers/of/unittest-data/overlay_bad_symbol.dts
@@ -0,0 +1,22 @@
+/dts-v1/;
+/plugin/;
+
+/ {
+
+   fragment@0 {
+   target = <&electric_1>;
+
+   __overlay__ {
+
+   // This label should cause an error when the overlay
+   // is applied.  There is already a symbol hvac_1
+   // in the base tree
+   hvac_1: hvac-medium-2 {
+   compatible = "ot,hvac-medium";
+   heat-range = < 50 75 >;
+   cool-range = < 60 80 >;
+   };
+
+   };
+   };
+};
diff --git a/drivers/of/unittest-data/overlay_base.dts 
b/drivers/of/unittest-data/overlay_base.dts
index 5566b27fb61a..453d0bd83320 100644
--- a/drivers/of/unittest-data/overlay_base.dts
+++ b/drivers/of/unittest-data/overlay_base.dts
@@ -44,6 +44,8 @@
orientation =

[PATCH v4 3/3] of: overlay: add overlay symbols to live device tree

[frowand . list]

From: Frank Rowand 

Add overlay __symbols__ properties to live tree when an overlay
is added to the live tree so that the symbols are available to
subsequent overlays.

Expected test result is new __symbols__ entries for labels from
the overlay after this commit.

Before this commit:

   Console error message near end of unittest:
  ### dt-test ### FAIL of_unittest_overlay_high_level():2296 Adding overlay 
'overlay_bad_symbol' failed
  ### dt-test ### end of unittest - 190 passed, 1 failed

   The new unittest "fails" because the expected result of loading the
   new overlay is an error instead of success.

   $ # node hvac-medium-2 exists because the overlay loaded
   $ # since the duplicate symbol was not detected
   $ cd /proc/device-tree/testcase-data-2/substation@100/
   $ ls
   compatible hvac-medium-2  motor-8reg
   hvac-large-1   linux,phandle  name   status
   hvac-medium-1  motor-1phandle

   $ cd /proc/device-tree/__symbols__/
   $ ls
   electric_1   lights_1 name rides_1  spin_ctrl_2
   hvac_1   lights_2 retail_1 spin_ctrl_1

After this commit:

   Previous console error message no longer occurs, but expected error
   occurs:
  OF: overlay: Failed to apply prop @/__symbols__/hvac_1
  OF: overlay: apply failed '/__symbols__'
  ### dt-test ### end of unittest - 191 passed, 0 failed

   $ # node hvac-medium-2 does not exist because the overlay
   $ # properly failed to load due to the duplicate symbol
   $ cd /proc/device-tree/testcase-data-2/substation@100/
   $ ls
   compatible hvac-medium-1  motor-1name   reg
   hvac-large-1   linux,phandle  motor-8phandlestatus

   $ cd /proc/device-tree/__symbols__/
   $ ls
   electric_1  lights_1retail_1ride_200_right  spin_ctrl_2
   hvac_1  lights_2ride_200rides_1
   hvac_2  nameride_200_left   spin_ctrl_1
   $ cat ride_200; echo
   /testcase-data-2/fairway-1/ride@200
   $ cat ride_200_left ; echo
   /testcase-data-2/fairway-1/ride@200/track@10
   $ cat ride_200_right ; echo
   /testcase-data-2/fairway-1/ride@200/track@20

Signed-off-by: Frank Rowand 
---
 drivers/of/overlay.c | 116 +++
 1 file changed, 107 insertions(+), 9 deletions(-)

diff --git a/drivers/of/overlay.c b/drivers/of/overlay.c
index bd3c32f2d411..b7fe9817b644 100644
--- a/drivers/of/overlay.c
+++ b/drivers/of/overlay.c
@@ -35,6 +35,7 @@
 struct of_overlay_info {
struct device_node *target;
struct device_node *overlay;
+   bool is_symbols_node;
 };
 
 /**
@@ -55,7 +56,8 @@ struct of_overlay {
 };
 
 static int of_overlay_apply_one(struct of_overlay *ov,
-   struct device_node *target, const struct device_node *overlay);
+   struct device_node *target, const struct device_node *overlay,
+   bool is_symbols_node);
 
 static BLOCKING_NOTIFIER_HEAD(of_overlay_chain);
 
@@ -92,10 +94,74 @@ static int of_overlay_notify(struct of_overlay *ov,
return 0;
 }
 
+static struct property *dup_and_fixup_symbol_prop(struct of_overlay *ov,
+   const struct property *prop)
+{
+   struct of_overlay_info *ovinfo;
+   struct property *new;
+   const char *overlay_name;
+   char *label_path;
+   char *symbol_path;
+   const char *target_path;
+   int k;
+   int label_path_len;
+   int overlay_name_len;
+   int target_path_len;
+
+   if (!prop->value)
+   return NULL;
+   symbol_path = prop->value;
+
+   new = kzalloc(sizeof(*new), GFP_KERNEL);
+   if (!new)
+   return NULL;
+
+   for (k = 0; k < ov->count; k++) {
+   ovinfo = &ov->ovinfo_tab[k];
+   overlay_name = ovinfo->overlay->full_name;
+   overlay_name_len = strlen(overlay_name);
+   if (!strncasecmp(symbol_path, overlay_name, overlay_name_len))
+   break;
+   }
+
+   if (k >= ov->count)
+   goto err_free;
+
+   target_path = ovinfo->target->full_name;
+   target_path_len = strlen(target_path);
+
+   label_path = symbol_path + overlay_name_len;
+   label_path_len = strlen(label_path);
+
+   new->name = kstrdup(prop->name, GFP_KERNEL);
+   new->length = target_path_len + label_path_len + 1;
+   new->value = kzalloc(new->length, GFP_KERNEL);
+
+   if (!new->name || !new->value)
+   goto err_free;
+
+   strcpy(new->value, target_path);
+   strcpy(new->value + target_path_len, label_path);
+
+   /* mark the property as dynamic */
+   of_property_set_flag(new, OF_DYNAMIC);
+
+   return new;
+
+ err_free:
+   kfree(new->name);
+   kfree(new->value);
+   kfree(new);
+   return NULL;
+
+
+}
+
 static int of_overlay_apply_single_property(struct of_overlay *ov,
-   struct device_node *target, struct property *pro

[PATCH v4 0/3] of: overlay: load overlay symbols into live device tree

[frowand . list]

From: Frank Rowand 

Symbols in a loaded overlay are not currently available to subsequently
loaded overlays because the properties in the overlay's __symbols__
node are not loaded into the live device tree.

Patch 1 is unittests to test patches 2 and 3.

Patch 2 fixes a problem discovered while developing patch 3.  If
a node name in an overlay has a unit-address then the overlay
code does not correctly match the node name against an existing
node in the live tree.

Patch 3 adds the properties in an overlay's __symbol__ node to
the overlay changeset.

changes since v3:
  - fix make W=2 warnings in overlay_base.dts and overlay.dts
  - update the test results in the patch comments to match the
.dts changes

changes since v2:
  - test on 4.13-rc1
  - remove redundant comments from patch headers of patch 0 and patch 1
  - guard make of overlay .dtb files with CONFIG_OF_OVERLAY
  - guard unittest.c references to overlay .dtb files with
CONFIG_OF_OVERLAY

changes since v1:
  - patch 2: Use for_each_child_of_node() instead of open coding,
which allowed removing the new function child_by_full_name().



Frank Rowand (3):
  of: overlay: add overlay unittest data for node names and symbols
  of: overlay: correctly apply overlay node with unit-address
  of: overlay: add overlay symbols to live device tree

 drivers/of/overlay.c| 121 ++--
 drivers/of/unittest-data/Makefile   |  19 +++-
 drivers/of/unittest-data/overlay.dts|  25 -
 drivers/of/unittest-data/overlay_bad_symbol.dts |  22 +
 drivers/of/unittest-data/overlay_base.dts   |  11 +++
 drivers/of/unittest.c   |  10 +-
 6 files changed, 190 insertions(+), 18 deletions(-)
 create mode 100644 drivers/of/unittest-data/overlay_bad_symbol.dts

-- 
Frank Rowand 

Re: [PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

[Nadav Amit]

Radim Krčmář  wrote:

> 2017-07-19 08:14-0700, Nadav Amit:
>> Radim Krčmář  wrote:
>>> @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu 
>>> *vcpu)
>>> 
>>> static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
>>> {
>>> +   unsigned long old_rflags = to_vmx(vcpu)->rflags;
>> 
>> It assumes rflags was decached from the VMCS before. Probably it is true, 
>> but…
> 
> Right, it's better to use accessors everywhere, thanks.
> The line should read:
> 
> + unsigned long old_rflags = vmx_get_rflags(vcpu);
> 
> ---8<---
> This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y
> or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it
> tries to emulate invalid guest state task-switch:
> 
> kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
> kvm_emulate_insn: 42000:0:0f 0b (0x2)
> kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
> kvm_inj_exception: #UD (0x0)
> kvm_entry: vcpu 0
> kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
> kvm_emulate_insn: 42000:0:0f 0b (0x2)
> kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
> kvm_inj_exception: #UD (0x0)
> 
> It appears that the task-switch emulation updates rflags (and vm86 flag)
> only after the segments are loaded, causing vmx->emulation_required to
> be set, when in fact invalid guest state emulation is not needed.
> 
> This patch fixes it by updating vmx->emulation_required after the rflags
> (and vm86 flag) is updated.
> 
> Suggested-by: Nadav Amit 
> Signed-off-by: Wanpeng Li 
> [Wanpeng wrote the commit message with initial patch and Radim moved the
> update to vmx_set_rflags and added Paolo's suggestion for the check.]
> Signed-off-by: Radim Krčmář 
> ---
> arch/x86/kvm/vmx.c | 15 ++-
> 1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 84e62acf2dd8..a776aea0043a 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -2326,6 +2326,11 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
>   __vmx_load_host_state(to_vmx(vcpu));
> }
> 
> +static bool emulation_required(struct kvm_vcpu *vcpu)
> +{
> + return emulate_invalid_guest_state && !guest_state_valid(vcpu);
> +}
> +
> static void vmx_decache_cr0_guest_bits(struct kvm_vcpu *vcpu);
> 
> /*
> @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu 
> *vcpu)
> 
> static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
> {
> + unsigned long old_rflags = vmx_get_rflags(vcpu);
> +
>   __set_bit(VCPU_EXREG_RFLAGS, (ulong *)&vcpu->arch.regs_avail);
>   to_vmx(vcpu)->rflags = rflags;
>   if (to_vmx(vcpu)->rmode.vm86_active) {
> @@ -2370,6 +2377,9 @@ static void vmx_set_rflags(struct kvm_vcpu *vcpu, 
> unsigned long rflags)
>   rflags |= X86_EFLAGS_IOPL | X86_EFLAGS_VM;
>   }
>   vmcs_writel(GUEST_RFLAGS, rflags);
> +
> + if ((old_rflags ^ rflags) & X86_EFLAGS_VM)
> + to_vmx(vcpu)->emulation_required = emulation_required(vcpu);

Sorry for not pointing it before, but here you compare the old_rflags with
the new rflags but after you already “massaged” it. So the value you compare
with is not what the guest “sees”.

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Borislav Petkov]

On Wed, Jul 19, 2017 at 04:10:07PM +, Kani, Toshimitsu wrote:
> I do prefer to avoid any white / black listing.  But I do not see how
> it solves the buggy DMI/SMBIOS info as an example of firmware bugs we
> may have to deal with.

So how do you want to deal with this?

Maintain an evergrowing whitelist of platforms which are OK and then the
moment a new platform comes along, you send a patch to add it to that
whitelist?

I'm sure you can see the problems with that approach.

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [PATCH v5 1/1] KVM: trigger uevents when creating or destroying a VM

[Radim Krčmář]

2017-07-17 18:27+0200, Claudio Imbrenda:
> On Mon, 17 Jul 2017 17:53:51 +0200
> David Hildenbrand  wrote:
> > > + tmp = strchrnul(p + 1, '-');> +
> > > *tmp = '\0';
> > > + add_uevent_var(env, "PID=%s", p);

When we're at it ... PID exists regardless of debugfs, so it would be
nice to provide it unconditionally.
(This interface looks like it was added to discourage the use of debugfs
 directory notifier in simple cases.)

I guess we cannot use task_pid_nr(current) on the KVM_EVENT_DESTROY_VM
path, so saving the PID in struct kvm would be better, IMO (it wastes
memory with larger number of VMs, but the code is harder to break).

> > > + tmp = dentry_path_raw(kvm->debugfs_dentry,
> > > +   pathbuf + len,
> > > +   PATH_MAX - len);
> > > + if (!IS_ERR(tmp)) {  
> > 
> > Why not
> > 
> > tmp = dentry_path_raw(kvm->debugfs_dentry, pathbuf, PATH_MAX);
> > if (!IS_ERR(tmp)) {
> > add_uevent_var(env, "STATS_PATH=s", tmp);
> > }
> > 
> > and avoid len / pvar / memcpy? And keep internal env size checking
> > consistent.
> 
> that would be true, but then we would copy the buffer with the path
> twice, once for dentry_path_raw and once for add_uevent_var.
> 
> the env size is consistent, since that would count the bytes
> effectively present in the buffer, and note that kobject_uevent_env only
> wants a char**, no length, so there are no consistency issues. 
> 
> I agree that your solution looks better (and I had actually considered
> implementing it like that initially), but it can potentially be slower.
> I don't really have any strong preference.
> 
> Paolo: which solution do you like the most? 

I slightly prefer the simpler version as performance of the path is not
that critical.

Please note that the original patch is already in 4.13 (it was ok and my
nitpicking would just make it miss the merge window :]), so the code
improvements need to be a new patch,

thanks.

[PATCH] staging: lustre: lnet: fix incorrect arguments order calling lstcon_session_new

[Colin King]

From: Colin Ian King 

The arguments args->lstio_ses_force and args->lstio_ses_timeout are
in the incorrect order. Fix this by swapping them around.

Detected by CoverityScan, CID#1226833 ("Arguments in wrong order")

Signed-off-by: Colin Ian King 
---
 drivers/staging/lustre/lnet/selftest/conctl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/lustre/lnet/selftest/conctl.c 
b/drivers/staging/lustre/lnet/selftest/conctl.c
index 6ca7192b03b7..043eafb5ea40 100644
--- a/drivers/staging/lustre/lnet/selftest/conctl.c
+++ b/drivers/staging/lustre/lnet/selftest/conctl.c
@@ -69,8 +69,8 @@ lst_session_new_ioctl(struct lstio_session_new_args *args)
rc = lstcon_session_new(name,
args->lstio_ses_key,
args->lstio_ses_feats,
-   args->lstio_ses_force,
args->lstio_ses_timeout,
+   args->lstio_ses_force,
args->lstio_ses_idp);
 
LIBCFS_FREE(name, args->lstio_ses_nmlen + 1);
-- 
2.11.0

[PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

[Radim Krčmář]

2017-07-19 08:14-0700, Nadav Amit:
> Radim Krčmář  wrote:
> > @@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu 
> > *vcpu)
> > 
> > static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
> > {
> > +   unsigned long old_rflags = to_vmx(vcpu)->rflags;
> 
> It assumes rflags was decached from the VMCS before. Probably it is true, but…

Right, it's better to use accessors everywhere, thanks.
The line should read:

+   unsigned long old_rflags = vmx_get_rflags(vcpu);

---8<---
This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y
or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it
tries to emulate invalid guest state task-switch:

kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
kvm_emulate_insn: 42000:0:0f 0b (0x2)
kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
kvm_inj_exception: #UD (0x0)
kvm_entry: vcpu 0
kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
kvm_emulate_insn: 42000:0:0f 0b (0x2)
kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
kvm_inj_exception: #UD (0x0)

It appears that the task-switch emulation updates rflags (and vm86 flag)
only after the segments are loaded, causing vmx->emulation_required to
be set, when in fact invalid guest state emulation is not needed.

This patch fixes it by updating vmx->emulation_required after the rflags
(and vm86 flag) is updated.

Suggested-by: Nadav Amit 
Signed-off-by: Wanpeng Li 
[Wanpeng wrote the commit message with initial patch and Radim moved the
 update to vmx_set_rflags and added Paolo's suggestion for the check.]
Signed-off-by: Radim Krčmář 
---
 arch/x86/kvm/vmx.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 84e62acf2dd8..a776aea0043a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2326,6 +2326,11 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
__vmx_load_host_state(to_vmx(vcpu));
 }
 
+static bool emulation_required(struct kvm_vcpu *vcpu)
+{
+   return emulate_invalid_guest_state && !guest_state_valid(vcpu);
+}
+
 static void vmx_decache_cr0_guest_bits(struct kvm_vcpu *vcpu);
 
 /*
@@ -2363,6 +2368,8 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu *vcpu)
 
 static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
 {
+   unsigned long old_rflags = vmx_get_rflags(vcpu);
+
__set_bit(VCPU_EXREG_RFLAGS, (ulong *)&vcpu->arch.regs_avail);
to_vmx(vcpu)->rflags = rflags;
if (to_vmx(vcpu)->rmode.vm86_active) {
@@ -2370,6 +2377,9 @@ static void vmx_set_rflags(struct kvm_vcpu *vcpu, 
unsigned long rflags)
rflags |= X86_EFLAGS_IOPL | X86_EFLAGS_VM;
}
vmcs_writel(GUEST_RFLAGS, rflags);
+
+   if ((old_rflags ^ rflags) & X86_EFLAGS_VM)
+   to_vmx(vcpu)->emulation_required = emulation_required(vcpu);
 }
 
 static u32 vmx_get_pkru(struct kvm_vcpu *vcpu)
@@ -3857,11 +3867,6 @@ static __init int alloc_kvm_area(void)
return 0;
 }
 
-static bool emulation_required(struct kvm_vcpu *vcpu)
-{
-   return emulate_invalid_guest_state && !guest_state_valid(vcpu);
-}
-
 static void fix_pmode_seg(struct kvm_vcpu *vcpu, int seg,
struct kvm_segment *save)
 {
-- 
2.13.2

Re: Kernel BUG at fs/namei.c:248

[Naresh Kamboju]

On 19 July 2017 at 19:24, Al Viro  wrote:
> On Wed, Jul 19, 2017 at 03:54:54PM +0530, Naresh Kamboju wrote:
>> Linux version:
>> Linux version 4.13.0-rc1-00059-g74cbd96 (buildslave@x86-64-07) (gcc
>> version 6.2.1 20161016 (Linaro GCC 6.2-2016.11)) #1 SMP PREEMPT Tue
>> Jul 18 19:09:37 UTC 2017
>>
>> [ 1245.412625] kernel BUG at
>> /srv/oe/build/tmp-rpb-glibc/work-shared/hikey/kernel-source/fs/namei.c:248!
>
> Interesting... Looks like double-put or memory corruptor of some sort.
> Nothing obvious jumps out at the first glance; I'll look into that when
> I get back to better connectivity tonight.

I am able to reproduce this BUG by running zram test cases multiple
times in a row.
http://people.linaro.org/~naresh.kamboju/zram.tar.gz

Ref:
LKFT: linux-mainline: Kernel BUG at fs/namei.c:248
https://bugs.linaro.org/show_bug.cgi?id=3140

Re: [PATCH v3 1/3] of: overlay: add overlay unittest data for node names and symbols

[Frank Rowand]

On 07/19/17 06:39, Rob Herring wrote:
> On Tue, Jul 18, 2017 at 10:52 PM,   wrote:
>> From: Frank Rowand 
>>
>> Add nodes and properties to overlay_base and overlay dts files to
>> test for
>>- incorrect existing node name detection when overlay node name
>>  has a unit-address
>>- adding overlay __symbols__ properties to live tree when an
>>  overlay is added to the live tree
>>
>> The following console messages will appear near the end of unittest
>> until the code errors are corrected:
>>
>>OF: Duplicate name in fairway-1, renamed to "ride@100#1"
>>
>>### dt-test ### FAIL of_unittest_overlay_high_level():2296 Adding overlay 
>> 'overlay_bad_symbol' failed
>>
>>### dt-test ### end of unittest - 190 passed, 1 failed
>>
>> Signed-off-by: Frank Rowand 
>> ---
> 
>> diff --git a/drivers/of/unittest-data/overlay.dts 
>> b/drivers/of/unittest-data/overlay.dts
>> index 6cd7e6a0c13e..81140adbe770 100644
>> --- a/drivers/of/unittest-data/overlay.dts
>> +++ b/drivers/of/unittest-data/overlay.dts
>> @@ -25,7 +25,18 @@
>> #size-cells = <1>;
>> status = "ok";
>>
>> -   ride@200 {
>> +   ride@100 {
>> +
>> +   track@3 {
> 
> These need a reg property.

OK.

I changed track@3 to track@30, and track@4 to track@40.
Then I added the reg property to .../ride@100/track@30/ and
.../ride@100/track@40/ in the base dts since those nodes
exist in the base dts.  As a result, W=2 will still warn
about a missing reg property for these two nodes in
the overlay.

> 
>> +   incline_up = < 48 32 16 >;
> 
> Don't use '_'.

OK.

> 
> Build with W=2 to check dtc warnings.

OK.

> 
> Rob
> 

Re: [PATCH 6/8] x86: add MULTIUSER dependency for KVM

[Radim Krčmář]

2017-07-19 16:18+0200, Arnd Bergmann:
> On Wed, Jul 19, 2017 at 4:11 PM, Radim Krčmář  wrote:
> > 2017-07-19 14:53+0200, Arnd Bergmann:
> >> KVM tries to select 'TASKSTATS', which had additional dependencies:
> >>
> >> warning: (KVM) selects TASKSTATS which has unmet direct dependencies (NET 
> >> && MULTIUSER)
> >>
> >> Signed-off-by: Arnd Bergmann 
> >> ---
> >
> > Hm, do you know why Kconfig warns instead of propagating the
> > dependencies?
> 
> Kconfig propagates 'depends on' dependencies, but cannot turn a 'select'
> into 'depends on', as those two mean different things.
> 
> Another solution to the problem would be to use 'depends on TASKSTATS'.

Good point, 'select' seems misused here.

There is no reason to depend on TASKSTATS (nor NET+MULTIUSER), we only
suggest to enable it with KVM.  KVM uses sched_info_on() to handle any
any possible resulting configuration, c9aaa8957f20 ("KVM: Steal time
implementation").

KVM would work as intended if 'select' would not enable the option if
its dependencies failed (instead of unconditionally forcing the option).

Is the preferred way to encode it:

  'default y if KVM' in config TASK_DELAY_ACCT
  (that adds a non-local and enigmatic dependency and also needlessly
   expands the possible configuration space)

or

  'select TASKSTATS if NET && MULTIUSER' in config KVM
  (that is going to break when dependencies of TASKSTATS change again)

?

thanks.

Re: [PATCH 002/102] ARM: socfpga: explicitly request exclusive reset control

[Moritz Fischer]

On Wed, Jul 19, 2017 at 05:25:06PM +0200, Philipp Zabel wrote:
> Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
> reset lines") started to transition the reset control request API calls
> to explicitly state whether the driver needs exclusive or shared reset
> control behavior. Convert all drivers requesting exclusive resets to the
> explicit API call so the temporary transition helpers can be removed.
> 
> No functional changes.
> 
> Cc: Alan Tull 
> Cc: Moritz Fischer 
> Cc: linux-f...@vger.kernel.org
> Signed-off-by: Philipp Zabel 
Acked-By: Moritz Fischer 
> ---
>  drivers/fpga/altera-hps2fpga.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/fpga/altera-hps2fpga.c b/drivers/fpga/altera-hps2fpga.c
> index 3066b805f2d07..a18ff430c9af1 100644
> --- a/drivers/fpga/altera-hps2fpga.c
> +++ b/drivers/fpga/altera-hps2fpga.c
> @@ -145,7 +145,8 @@ static int alt_fpga_bridge_probe(struct platform_device 
> *pdev)
>   of_id = of_match_device(altera_fpga_of_match, dev);
>   priv = (struct altera_hps2fpga_data *)of_id->data;
>  
> - priv->bridge_reset = of_reset_control_get_by_index(dev->of_node, 0);
> + priv->bridge_reset = 
> of_reset_control_get_exclusive_by_index(dev->of_node,
> +  0);
>   if (IS_ERR(priv->bridge_reset)) {
>   dev_err(dev, "Could not get %s reset control\n", priv->name);
>   return PTR_ERR(priv->bridge_reset);
> -- 
> 2.11.0
> 

Thanks,

Moritz


signature.asc
Description: PGP signature

Applied "ASoC: tegra: explicitly request exclusive reset control" to the asoc tree

[Mark Brown]

The patch

   ASoC: tegra: explicitly request exclusive reset control

has been applied to the asoc tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 181e8ce6a6c9a25ffbf10b09d8481f134c5a79ba Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Wed, 19 Jul 2017 17:26:44 +0200
Subject: [PATCH] ASoC: tegra: explicitly request exclusive reset control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.

No functional changes.

Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: alsa-de...@alsa-project.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Philipp Zabel 
Signed-off-by: Mark Brown 
---
 sound/soc/tegra/tegra30_ahub.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/tegra/tegra30_ahub.c b/sound/soc/tegra/tegra30_ahub.c
index 8c10ae7982ba..43679aeeb12b 100644
--- a/sound/soc/tegra/tegra30_ahub.c
+++ b/sound/soc/tegra/tegra30_ahub.c
@@ -544,8 +544,8 @@ static int tegra30_ahub_probe(struct platform_device *pdev)
soc_data->mod_list_mask))
continue;
 
-   rst = reset_control_get(&pdev->dev,
-   configlink_mods[i].rst_name);
+   rst = reset_control_get_exclusive(&pdev->dev,
+ configlink_mods[i].rst_name);
if (IS_ERR(rst)) {
dev_err(&pdev->dev, "Can't get reset %s\n",
configlink_mods[i].rst_name);
-- 
2.13.2

Re: [PATCH 3/3] ghes_edac: add platform check to enable ghes_edac

[Kani, Toshimitsu]

On Wed, 2017-07-19 at 07:52 +0200, Borislav Petkov wrote:
> On Tue, Jul 18, 2017 at 09:20:44PM +, Kani, Toshimitsu wrote:
> > I agree that 'osc_sb_apei_support_acked' should be checked when
> > enabling ghes_edac.  I do not know the details of existing issues,
> > but it sounds unlikely that this will address all of them since
> > bugs can be everywhere.
> 
> No, see below.
> 
> > For instance, ghes_edac relies on DMI/SMBIOS info, unlike
> > other EDAC drivers, which can be buggy regardless of this _OSC
> > info.
> 
> That's the problem with firmware. You can't really fix it and it is
> buggy as hell.

Right, and that's what I was told as an issue for ghes_edac.  This is
why this patch introduces a white-list to preclude all buggy firmwares
that are unknown to us...

> > I agree that making ghes_edac as a normal module is a good thing,
> > but I do not think it's going to solve this issue.
> 
> Of course it will - if the firmware says it wants to look at the
> errors first, then it gets to do so. This is the whole handling of
> hardware errors in the firmware deal. I admit, sometimes it makes
> sense because the firmware has the most intimate knowledge of the
> platform and, in a perfect world, we won't ever need to have
> platform-specific EDAC drivers.
>
> But, we don't live in a perfect world. And the vendor execution of
> the whole firmware-error-handling deal is an abomination at best.
> 
> So, if we realize that the firmware is buggy, we can use a platform
> list to blacklist it (^hint hint^) and have a parameter to disable
> ghes_edac from loading.

Setting blacklist needs us to enable ghes_edac and find all buggy
firmwares to date.  I think this is too disturbing for people who are
happily using regular edac drivers today even though their platforms
have GHES.

> But we'll deal with that when we get to cross that bridge. Right now,
> I'd like to do the loading spec-conform and not fiddle with white-,
> black-, or any-other-color lists.

I do prefer to avoid any white / black listing.  But I do not see how
it solves the buggy DMI/SMBIOS info as an example of firmware bugs we
may have to deal with.

Thanks,
-Toshi

Applied "spi: tegra20-sflash: explicitly request exclusive reset control" to the spi tree

[Mark Brown]

The patch

   spi: tegra20-sflash: explicitly request exclusive reset control

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From e60dfe0782f251bb529f233e259dffdc8d786624 Mon Sep 17 00:00:00 2001
From: Philipp Zabel 
Date: Wed, 19 Jul 2017 17:26:24 +0200
Subject: [PATCH] spi: tegra20-sflash: explicitly request exclusive reset
 control

Commit a53e35db70d1 ("reset: Ensure drivers are explicit when requesting
reset lines") started to transition the reset control request API calls
to explicitly state whether the driver needs exclusive or shared reset
control behavior. Convert all drivers requesting exclusive resets to the
explicit API call so the temporary transition helpers can be removed.

No functional changes.

Cc: Laxman Dewangan 
Cc: Mark Brown 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: linux-...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Signed-off-by: Philipp Zabel 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-tegra20-sflash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-tegra20-sflash.c b/drivers/spi/spi-tegra20-sflash.c
index 2c797ee2664d..22893a7e0aa0 100644
--- a/drivers/spi/spi-tegra20-sflash.c
+++ b/drivers/spi/spi-tegra20-sflash.c
@@ -485,7 +485,7 @@ static int tegra_sflash_probe(struct platform_device *pdev)
goto exit_free_irq;
}
 
-   tsd->rst = devm_reset_control_get(&pdev->dev, "spi");
+   tsd->rst = devm_reset_control_get_exclusive(&pdev->dev, "spi");
if (IS_ERR(tsd->rst)) {
dev_err(&pdev->dev, "can not get reset\n");
ret = PTR_ERR(tsd->rst);
-- 
2.13.2