* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 16:41 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 16:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linaro-kernel, QCA ath9k Development, Intel Linux Wireless,
Viresh Kumar, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
global_lock is defined as an unsigned long and accessing only its lower
32 bits from sysfs is incorrect, as we need to consider other 32 bits
for big endian 64 bit systems. There are no such platforms yet, but the
code needs to be robust for such a case.
Fix that by passing a local variable to debugfs_create_bool() and
assigning its value to global_lock later.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V3->V4:
- Create a local variable instead of changing type of global_lock
(Rafael)
- Drop the stable tag
- BCC'd a lot of people (rather than cc'ing them) to make sure
- the series reaches them
- mailing lists do not block the patchset due to long cc list
- and we don't spam the BCC'd people for every reply
---
drivers/acpi/ec_sys.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b4c216bab22b..b44b91331a56 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
+ u32 val;
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
@@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
goto error;
- if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
- (u32 *)&first_ec->global_lock))
+ if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
goto error;
+ first_ec->global_lock = val;
+
if (write_support)
mode = 0600;
if (!debugfs_create_file("io", mode, dev_dir, ec, &acpi_ec_io_ops))
--
2.4.0
^ permalink raw reply related [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 16:41 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 16:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Viresh Kumar,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, QCA ath9k Development,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Intel Linux Wireless,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-edac-u79uwXL29TY76Z2rM5mHXA
global_lock is defined as an unsigned long and accessing only its lower
32 bits from sysfs is incorrect, as we need to consider other 32 bits
for big endian 64 bit systems. There are no such platforms yet, but the
code needs to be robust for such a case.
Fix that by passing a local variable to debugfs_create_bool() and
assigning its value to global_lock later.
Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
V3->V4:
- Create a local variable instead of changing type of global_lock
(Rafael)
- Drop the stable tag
- BCC'd a lot of people (rather than cc'ing them) to make sure
- the series reaches them
- mailing lists do not block the patchset due to long cc list
- and we don't spam the BCC'd people for every reply
---
drivers/acpi/ec_sys.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b4c216bab22b..b44b91331a56 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
+ u32 val;
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
@@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
goto error;
- if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
- (u32 *)&first_ec->global_lock))
+ if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
goto error;
+ first_ec->global_lock = val;
+
if (write_support)
mode = 0600;
if (!debugfs_create_file("io", mode, dev_dir, ec, &acpi_ec_io_ops))
--
2.4.0
^ permalink raw reply related [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 16:41 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 16:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linaro-kernel, QCA ath9k Development, Intel Linux Wireless,
Viresh Kumar, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
global_lock is defined as an unsigned long and accessing only its lower
32 bits from sysfs is incorrect, as we need to consider other 32 bits
for big endian 64 bit systems. There are no such platforms yet, but the
code needs to be robust for such a case.
Fix that by passing a local variable to debugfs_create_bool() and
assigning its value to global_lock later.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V3->V4:
- Create a local variable instead of changing type of global_lock
(Rafael)
- Drop the stable tag
- BCC'd a lot of people (rather than cc'ing them) to make sure
- the series reaches them
- mailing lists do not block the patchset due to long cc list
- and we don't spam the BCC'd people for every reply
---
drivers/acpi/ec_sys.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b4c216bab22b..b44b91331a56 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
+ u32 val;
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
@@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
goto error;
- if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
- (u32 *)&first_ec->global_lock))
+ if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
goto error;
+ first_ec->global_lock = val;
+
if (write_support)
mode = 0600;
if (!debugfs_create_file("io", mode, dev_dir, ec, &acpi_ec_io_ops))
--
2.4.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 16:41 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 16:41 UTC (permalink / raw)
To: linux-arm-kernel
global_lock is defined as an unsigned long and accessing only its lower
32 bits from sysfs is incorrect, as we need to consider other 32 bits
for big endian 64 bit systems. There are no such platforms yet, but the
code needs to be robust for such a case.
Fix that by passing a local variable to debugfs_create_bool() and
assigning its value to global_lock later.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
---
V3->V4:
- Create a local variable instead of changing type of global_lock
(Rafael)
- Drop the stable tag
- BCC'd a lot of people (rather than cc'ing them) to make sure
- the series reaches them
- mailing lists do not block the patchset due to long cc list
- and we don't spam the BCC'd people for every reply
---
drivers/acpi/ec_sys.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b4c216bab22b..b44b91331a56 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
+ u32 val;
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
@@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
goto error;
- if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
- (u32 *)&first_ec->global_lock))
+ if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
goto error;
+ first_ec->global_lock = val;
+
if (write_support)
mode = 0600;
if (!debugfs_create_file("io", mode, dev_dir, ec, &acpi_ec_io_ops))
--
2.4.0
^ permalink raw reply related [flat|nested] 135+ messages in thread
* [PATCH V4 2/2] debugfs: Pass bool pointer to debugfs_create_bool()
2015-09-25 16:41 ` Viresh Kumar
(?)
@ 2015-09-25 16:41 ` Viresh Kumar
-1 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 16:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linaro-kernel, QCA ath9k Development, Intel Linux Wireless,
Viresh Kumar, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument,
when all it needs is a boolean pointer.
It would be better to update this API to make it accept 'bool *'
instead, as that will make it more consistent and often more convenient.
Over that bool takes just a byte (mostly).
That required updates to all user sites as well, in the same commit
updating the API. regmap core was also using
debugfs_{read|write}_file_bool(), directly and variable types were
updated for that to be bool as well.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
V3->V4:
- Updated commit log to make it clear
- Drop 'global_lock = !!tmp' change, as that's not required at all.
- s/u32/bool for ec_sys.c
- Added Ack from Charles.
- BCC'd a lot of people (rather than cc'ing them) to make sure
- the series reaches them
- mailing lists do not block the patchset due to long cc list
- and we don't spam the BCC'd people for every reply
---
Documentation/filesystems/debugfs.txt | 2 +-
arch/arm64/kernel/debug-monitors.c | 4 ++--
drivers/acpi/ec_sys.c | 2 +-
drivers/acpi/internal.h | 2 +-
drivers/base/regmap/internal.h | 6 +++---
drivers/base/regmap/regcache-lzo.c | 4 ++--
drivers/base/regmap/regcache.c | 24 ++++++++++++------------
drivers/bluetooth/hci_qca.c | 4 ++--
drivers/iommu/amd_iommu_init.c | 2 +-
drivers/iommu/amd_iommu_types.h | 2 +-
drivers/misc/mei/mei_dev.h | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4 ++--
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.h | 4 ++--
drivers/net/wireless/b43/debugfs.c | 18 +++++++++---------
drivers/net/wireless/b43/debugfs.h | 2 +-
drivers/net/wireless/b43legacy/debugfs.c | 10 +++++-----
drivers/net/wireless/b43legacy/debugfs.h | 2 +-
drivers/net/wireless/iwlegacy/common.h | 6 +++---
drivers/net/wireless/iwlwifi/mvm/mvm.h | 6 +++---
drivers/scsi/snic/snic_trc.c | 4 ++--
drivers/scsi/snic/snic_trc.h | 2 +-
drivers/uwb/uwb-debug.c | 2 +-
fs/debugfs/file.c | 6 +++---
include/linux/debugfs.h | 4 ++--
include/linux/edac.h | 2 +-
include/linux/fault-inject.h | 2 +-
kernel/futex.c | 4 ++--
lib/dma-debug.c | 2 +-
mm/failslab.c | 8 ++++----
mm/page_alloc.c | 8 ++++----
sound/soc/codecs/wm_adsp.h | 2 +-
34 files changed, 79 insertions(+), 79 deletions(-)
diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt
index 463f595733e8..4f45f71149cb 100644
--- a/Documentation/filesystems/debugfs.txt
+++ b/Documentation/filesystems/debugfs.txt
@@ -105,7 +105,7 @@ a variable of type size_t.
Boolean values can be placed in debugfs with:
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value);
+ struct dentry *parent, bool *value);
A read on the resulting file will yield either Y (for non-zero values) or
N, followed by a newline. If written to, it will accept either upper- or
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index cebf78661a55..1c4cd4a0d7cc 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -58,7 +58,7 @@ static u32 mdscr_read(void)
* Allow root to disable self-hosted debug from userspace.
* This is useful if you want to connect an external JTAG debugger.
*/
-static u32 debug_enabled = 1;
+static bool debug_enabled = true;
static int create_debug_debugfs_entry(void)
{
@@ -69,7 +69,7 @@ fs_initcall(create_debug_debugfs_entry);
static int __init early_debug_disable(char *buf)
{
- debug_enabled = 0;
+ debug_enabled = false;
return 0;
}
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b44b91331a56..f025b044a1cf 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,7 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
- u32 val;
+ bool val;
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 9e426210c2a8..5a72e2b140fc 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -138,7 +138,7 @@ struct acpi_ec {
unsigned long gpe;
unsigned long command_addr;
unsigned long data_addr;
- unsigned long global_lock;
+ bool global_lock;
unsigned long flags;
unsigned long reference_count;
struct mutex mutex;
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index cc557886ab23..5b907f2c62b9 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -122,9 +122,9 @@ struct regmap {
unsigned int num_reg_defaults_raw;
/* if set, only the cache is modified not the HW */
- u32 cache_only;
+ bool cache_only;
/* if set, only the HW is modified not the cache */
- u32 cache_bypass;
+ bool cache_bypass;
/* if set, remember to free reg_defaults_raw */
bool cache_free;
@@ -132,7 +132,7 @@ struct regmap {
const void *reg_defaults_raw;
void *cache;
/* if set, the cache contains newer data than the HW */
- u32 cache_dirty;
+ bool cache_dirty;
/* if set, the HW registers are known to match map->reg_defaults */
bool no_sync_defaults;
diff --git a/drivers/base/regmap/regcache-lzo.c b/drivers/base/regmap/regcache-lzo.c
index 2d53f6f138e1..736e0d378567 100644
--- a/drivers/base/regmap/regcache-lzo.c
+++ b/drivers/base/regmap/regcache-lzo.c
@@ -355,9 +355,9 @@ static int regcache_lzo_sync(struct regmap *map, unsigned int min,
if (ret > 0 && val == map->reg_defaults[ret].def)
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, i, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret)
return ret;
dev_dbg(map->dev, "Synced register %#x, value %#x\n",
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index 6f8a13ec32a4..4c07802986b2 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -54,11 +54,11 @@ static int regcache_hw_init(struct regmap *map)
return -ENOMEM;
if (!map->reg_defaults_raw) {
- u32 cache_bypass = map->cache_bypass;
+ bool cache_bypass = map->cache_bypass;
dev_warn(map->dev, "No cache defaults, reading back from HW\n");
/* Bypass the cache access till data read from HW*/
- map->cache_bypass = 1;
+ map->cache_bypass = true;
tmp_buf = kmalloc(map->cache_size_raw, GFP_KERNEL);
if (!tmp_buf) {
ret = -ENOMEM;
@@ -285,9 +285,9 @@ static int regcache_default_sync(struct regmap *map, unsigned int min,
if (!regcache_reg_needs_sync(map, reg, val))
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, reg, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret) {
dev_err(map->dev, "Unable to sync register %#x. %d\n",
reg, ret);
@@ -315,7 +315,7 @@ int regcache_sync(struct regmap *map)
int ret = 0;
unsigned int i;
const char *name;
- unsigned int bypass;
+ bool bypass;
BUG_ON(!map->cache_ops);
@@ -333,7 +333,7 @@ int regcache_sync(struct regmap *map)
map->async = true;
/* Apply any patch first */
- map->cache_bypass = 1;
+ map->cache_bypass = true;
for (i = 0; i < map->patch_regs; i++) {
ret = _regmap_write(map, map->patch[i].reg, map->patch[i].def);
if (ret != 0) {
@@ -342,7 +342,7 @@ int regcache_sync(struct regmap *map)
goto out;
}
}
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (map->cache_ops->sync)
ret = map->cache_ops->sync(map, 0, map->max_register);
@@ -384,7 +384,7 @@ int regcache_sync_region(struct regmap *map, unsigned int min,
{
int ret = 0;
const char *name;
- unsigned int bypass;
+ bool bypass;
BUG_ON(!map->cache_ops);
@@ -637,11 +637,11 @@ static int regcache_sync_block_single(struct regmap *map, void *block,
if (!regcache_reg_needs_sync(map, regtmp, val))
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, regtmp, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret != 0) {
dev_err(map->dev, "Unable to sync register %#x. %d\n",
regtmp, ret);
@@ -668,14 +668,14 @@ static int regcache_sync_block_raw_flush(struct regmap *map, const void **data,
dev_dbg(map->dev, "Writing %zu bytes for %d registers from 0x%x-0x%x\n",
count * val_bytes, count, base, cur - map->reg_stride);
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_raw_write(map, base, *data, count * val_bytes);
if (ret)
dev_err(map->dev, "Unable to sync registers %#x-%#x. %d\n",
base, cur - map->reg_stride, ret);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
*data = NULL;
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 6b9b91267959..509477681661 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -80,8 +80,8 @@ struct qca_data {
spinlock_t hci_ibs_lock; /* HCI_IBS state lock */
u8 tx_ibs_state; /* HCI_IBS transmit side power state*/
u8 rx_ibs_state; /* HCI_IBS receive side power state */
- u32 tx_vote; /* Clock must be on for TX */
- u32 rx_vote; /* Clock must be on for RX */
+ bool tx_vote; /* Clock must be on for TX */
+ bool rx_vote; /* Clock must be on for RX */
struct timer_list tx_idle_timer;
u32 tx_idle_delay;
struct timer_list wake_retrans_timer;
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 5ef347a13cb5..c59314523f4c 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -138,7 +138,7 @@ u16 amd_iommu_last_bdf; /* largest PCI device id we have
to handle */
LIST_HEAD(amd_iommu_unity_map); /* a list of required unity mappings
we find in ACPI */
-u32 amd_iommu_unmap_flush; /* if true, flush on every unmap */
+bool amd_iommu_unmap_flush; /* if true, flush on every unmap */
LIST_HEAD(amd_iommu_list); /* list of all AMD IOMMUs in the
system */
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index f65908841be0..861550a1ad1f 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -674,7 +674,7 @@ extern unsigned long *amd_iommu_pd_alloc_bitmap;
* If true, the addresses will be flushed on unmap time, not when
* they are reused
*/
-extern u32 amd_iommu_unmap_flush;
+extern bool amd_iommu_unmap_flush;
/* Smallest max PASID supported by any IOMMU in the system */
extern u32 amd_iommu_max_pasid;
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index e25ee16c658e..d74b6aa8ae27 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -528,7 +528,7 @@ struct mei_device {
DECLARE_BITMAP(host_clients_map, MEI_CLIENTS_MAX);
unsigned long me_client_index;
- u32 allow_fixed_address;
+ bool allow_fixed_address;
struct mei_cl wd_cl;
enum mei_wd_states wd_state;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index fa0c7b54ec7a..5384f999c24b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -767,8 +767,8 @@ struct adapter {
bool tid_release_task_busy;
struct dentry *debugfs_root;
- u32 use_bd; /* Use SGE Back Door intfc for reading SGE Contexts */
- u32 trace_rss; /* 1 implies that different RSS flit per filter is
+ bool use_bd; /* Use SGE Back Door intfc for reading SGE Contexts */
+ bool trace_rss; /* 1 implies that different RSS flit per filter is
* used per filter else if 0 default RSS flit is
* used for all 4 filters.
*/
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 12542144fe12..b6a08177b6ee 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -680,7 +680,7 @@ struct ath10k {
bool monitor_started;
unsigned int filter_flags;
unsigned long dev_flags;
- u32 dfs_block_radar_events;
+ bool dfs_block_radar_events;
/* protected by conf_mutex */
bool radar_enabled;
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index fa6e89e5c421..ba12f7f4061d 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1367,7 +1367,7 @@ struct ath5k_hw {
u8 ah_retry_long;
u8 ah_retry_short;
- u32 ah_use_32khz_clock;
+ bool ah_use_32khz_clock;
u8 ah_coverage_class;
bool ah_ack_bitrate_high;
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1dd0339de372..8823fadada89 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -385,7 +385,7 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
ah->config.dma_beacon_response_time = 1;
ah->config.sw_beacon_response_time = 6;
- ah->config.cwm_ignore_extcca = 0;
+ ah->config.cwm_ignore_extcca = false;
ah->config.analog_shiftreg = 1;
ah->config.rx_intr_mitigation = true;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index e8454db17634..52971b48ab6a 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -332,14 +332,14 @@ enum ath9k_hw_hang_checks {
struct ath9k_ops_config {
int dma_beacon_response_time;
int sw_beacon_response_time;
- u32 cwm_ignore_extcca;
+ bool cwm_ignore_extcca;
u32 pcie_waen;
u8 analog_shiftreg;
u32 ofdm_trig_low;
u32 ofdm_trig_high;
u32 cck_trig_high;
u32 cck_trig_low;
- u32 enable_paprd;
+ bool enable_paprd;
int serialize_regmode;
bool rx_intr_mitigation;
bool tx_intr_mitigation;
diff --git a/drivers/net/wireless/b43/debugfs.c b/drivers/net/wireless/b43/debugfs.c
index e807bd930647..b4bcd94aff6c 100644
--- a/drivers/net/wireless/b43/debugfs.c
+++ b/drivers/net/wireless/b43/debugfs.c
@@ -676,15 +676,15 @@ static void b43_add_dynamic_debug(struct b43_wldev *dev)
e->dyn_debug_dentries[id] = d; \
} while (0)
- add_dyn_dbg("debug_xmitpower", B43_DBG_XMITPOWER, 0);
- add_dyn_dbg("debug_dmaoverflow", B43_DBG_DMAOVERFLOW, 0);
- add_dyn_dbg("debug_dmaverbose", B43_DBG_DMAVERBOSE, 0);
- add_dyn_dbg("debug_pwork_fast", B43_DBG_PWORK_FAST, 0);
- add_dyn_dbg("debug_pwork_stop", B43_DBG_PWORK_STOP, 0);
- add_dyn_dbg("debug_lo", B43_DBG_LO, 0);
- add_dyn_dbg("debug_firmware", B43_DBG_FIRMWARE, 0);
- add_dyn_dbg("debug_keys", B43_DBG_KEYS, 0);
- add_dyn_dbg("debug_verbose_stats", B43_DBG_VERBOSESTATS, 0);
+ add_dyn_dbg("debug_xmitpower", B43_DBG_XMITPOWER, false);
+ add_dyn_dbg("debug_dmaoverflow", B43_DBG_DMAOVERFLOW, false);
+ add_dyn_dbg("debug_dmaverbose", B43_DBG_DMAVERBOSE, false);
+ add_dyn_dbg("debug_pwork_fast", B43_DBG_PWORK_FAST, false);
+ add_dyn_dbg("debug_pwork_stop", B43_DBG_PWORK_STOP, false);
+ add_dyn_dbg("debug_lo", B43_DBG_LO, false);
+ add_dyn_dbg("debug_firmware", B43_DBG_FIRMWARE, false);
+ add_dyn_dbg("debug_keys", B43_DBG_KEYS, false);
+ add_dyn_dbg("debug_verbose_stats", B43_DBG_VERBOSESTATS, false);
#undef add_dyn_dbg
}
diff --git a/drivers/net/wireless/b43/debugfs.h b/drivers/net/wireless/b43/debugfs.h
index 50517b801cb4..d05377745011 100644
--- a/drivers/net/wireless/b43/debugfs.h
+++ b/drivers/net/wireless/b43/debugfs.h
@@ -68,7 +68,7 @@ struct b43_dfsentry {
u32 shm32read_addr_next;
/* Enabled/Disabled list for the dynamic debugging features. */
- u32 dyn_debug[__B43_NR_DYNDBG];
+ bool dyn_debug[__B43_NR_DYNDBG];
/* Dentries for the dynamic debugging entries. */
struct dentry *dyn_debug_dentries[__B43_NR_DYNDBG];
};
diff --git a/drivers/net/wireless/b43legacy/debugfs.c b/drivers/net/wireless/b43legacy/debugfs.c
index 1965edb765a2..090910ea259e 100644
--- a/drivers/net/wireless/b43legacy/debugfs.c
+++ b/drivers/net/wireless/b43legacy/debugfs.c
@@ -369,11 +369,11 @@ static void b43legacy_add_dynamic_debug(struct b43legacy_wldev *dev)
e->dyn_debug_dentries[id] = d; \
} while (0)
- add_dyn_dbg("debug_xmitpower", B43legacy_DBG_XMITPOWER, 0);
- add_dyn_dbg("debug_dmaoverflow", B43legacy_DBG_DMAOVERFLOW, 0);
- add_dyn_dbg("debug_dmaverbose", B43legacy_DBG_DMAVERBOSE, 0);
- add_dyn_dbg("debug_pwork_fast", B43legacy_DBG_PWORK_FAST, 0);
- add_dyn_dbg("debug_pwork_stop", B43legacy_DBG_PWORK_STOP, 0);
+ add_dyn_dbg("debug_xmitpower", B43legacy_DBG_XMITPOWER, false);
+ add_dyn_dbg("debug_dmaoverflow", B43legacy_DBG_DMAOVERFLOW, false);
+ add_dyn_dbg("debug_dmaverbose", B43legacy_DBG_DMAVERBOSE, false);
+ add_dyn_dbg("debug_pwork_fast", B43legacy_DBG_PWORK_FAST, false);
+ add_dyn_dbg("debug_pwork_stop", B43legacy_DBG_PWORK_STOP, false);
#undef add_dyn_dbg
}
diff --git a/drivers/net/wireless/b43legacy/debugfs.h b/drivers/net/wireless/b43legacy/debugfs.h
index ae3b0d0fa849..9ee32158b947 100644
--- a/drivers/net/wireless/b43legacy/debugfs.h
+++ b/drivers/net/wireless/b43legacy/debugfs.h
@@ -47,7 +47,7 @@ struct b43legacy_dfsentry {
struct b43legacy_txstatus_log txstatlog;
/* Enabled/Disabled list for the dynamic debugging features. */
- u32 dyn_debug[__B43legacy_NR_DYNDBG];
+ bool dyn_debug[__B43legacy_NR_DYNDBG];
/* Dentries for the dynamic debugging entries. */
struct dentry *dyn_debug_dentries[__B43legacy_NR_DYNDBG];
};
diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index 5b972798bdff..ce52cf114fde 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -1425,9 +1425,9 @@ struct il_priv {
#endif /* CONFIG_IWLEGACY_DEBUGFS */
struct work_struct txpower_work;
- u32 disable_sens_cal;
- u32 disable_chain_noise_cal;
- u32 disable_tx_power_cal;
+ bool disable_sens_cal;
+ bool disable_chain_noise_cal;
+ bool disable_tx_power_cal;
struct work_struct run_time_calib_work;
struct timer_list stats_periodic;
struct timer_list watchdog;
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index b95a07ec9e36..72e8a03a5293 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -649,7 +649,7 @@ struct iwl_mvm {
const struct iwl_fw_bcast_filter *bcast_filters;
#ifdef CONFIG_IWLWIFI_DEBUGFS
struct {
- u32 override; /* u32 for debugfs_create_bool */
+ bool override;
struct iwl_bcast_filter_cmd cmd;
} dbgfs_bcast_filtering;
#endif
@@ -673,7 +673,7 @@ struct iwl_mvm {
bool disable_power_off;
bool disable_power_off_d3;
- u32 scan_iter_notif_enabled; /* must be u32 for debugfs_create_bool */
+ bool scan_iter_notif_enabled;
struct debugfs_blob_wrapper nvm_hw_blob;
struct debugfs_blob_wrapper nvm_sw_blob;
@@ -729,7 +729,7 @@ struct iwl_mvm {
int n_nd_channels;
bool net_detect;
#ifdef CONFIG_IWLWIFI_DEBUGFS
- u32 d3_wake_sysassert; /* must be u32 for debugfs_create_bool */
+ bool d3_wake_sysassert;
bool d3_test_active;
bool store_d3_resume_sram;
void *d3_resume_sram;
diff --git a/drivers/scsi/snic/snic_trc.c b/drivers/scsi/snic/snic_trc.c
index 28a40a7ade38..f00ebf4717e0 100644
--- a/drivers/scsi/snic/snic_trc.c
+++ b/drivers/scsi/snic/snic_trc.c
@@ -148,7 +148,7 @@ snic_trc_init(void)
trc->max_idx = (tbuf_sz / SNIC_TRC_ENTRY_SZ);
trc->rd_idx = trc->wr_idx = 0;
- trc->enable = 1;
+ trc->enable = true;
SNIC_INFO("Trace Facility Enabled.\n Trace Buffer SZ %lu Pages.\n",
tbuf_sz / PAGE_SIZE);
ret = 0;
@@ -169,7 +169,7 @@ snic_trc_free(void)
{
struct snic_trc *trc = &snic_glob->trc;
- trc->enable = 0;
+ trc->enable = false;
snic_trc_debugfs_term();
if (trc->buf) {
diff --git a/drivers/scsi/snic/snic_trc.h b/drivers/scsi/snic/snic_trc.h
index 427faee5f97e..b37f8867bfde 100644
--- a/drivers/scsi/snic/snic_trc.h
+++ b/drivers/scsi/snic/snic_trc.h
@@ -45,7 +45,7 @@ struct snic_trc {
u32 max_idx; /* Max Index into trace buffer */
u32 rd_idx;
u32 wr_idx;
- u32 enable; /* Control Variable for Tracing */
+ bool enable; /* Control Variable for Tracing */
struct dentry *trc_enable; /* debugfs file object */
struct dentry *trc_file;
diff --git a/drivers/uwb/uwb-debug.c b/drivers/uwb/uwb-debug.c
index 0b1e5a9449b5..991374b13571 100644
--- a/drivers/uwb/uwb-debug.c
+++ b/drivers/uwb/uwb-debug.c
@@ -55,7 +55,7 @@
struct uwb_dbg {
struct uwb_pal pal;
- u32 accept;
+ bool accept;
struct list_head rsvs;
struct dentry *root_d;
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 6c55ade071c3..b70c20fae502 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -439,7 +439,7 @@ ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
char buf[3];
- u32 *val = file->private_data;
+ bool *val = file->private_data;
if (*val)
buf[0] = 'Y';
@@ -457,7 +457,7 @@ ssize_t debugfs_write_file_bool(struct file *file, const char __user *user_buf,
char buf[32];
size_t buf_size;
bool bv;
- u32 *val = file->private_data;
+ bool *val = file->private_data;
buf_size = min(count, (sizeof(buf)-1));
if (copy_from_user(buf, user_buf, buf_size))
@@ -503,7 +503,7 @@ static const struct file_operations fops_bool = {
* code.
*/
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value)
+ struct dentry *parent, bool *value)
{
return debugfs_create_file(name, mode, parent, value, &fops_bool);
}
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 9beb636b97eb..8321fe3058d6 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -92,7 +92,7 @@ struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
struct dentry *debugfs_create_atomic_t(const char *name, umode_t mode,
struct dentry *parent, atomic_t *value);
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value);
+ struct dentry *parent, bool *value);
struct dentry *debugfs_create_blob(const char *name, umode_t mode,
struct dentry *parent,
@@ -243,7 +243,7 @@ static inline struct dentry *debugfs_create_atomic_t(const char *name, umode_t m
static inline struct dentry *debugfs_create_bool(const char *name, umode_t mode,
struct dentry *parent,
- u32 *value)
+ bool *value)
{
return ERR_PTR(-ENODEV);
}
diff --git a/include/linux/edac.h b/include/linux/edac.h
index da3b72e95db3..7c6b7ba55589 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -772,7 +772,7 @@ struct mem_ctl_info {
#ifdef CONFIG_EDAC_DEBUG
struct dentry *debugfs;
u8 fake_inject_layer[EDAC_MAX_LAYERS];
- u32 fake_inject_ue;
+ bool fake_inject_ue;
u16 fake_inject_count;
#endif
};
diff --git a/include/linux/fault-inject.h b/include/linux/fault-inject.h
index 798fad9e420d..3159a7dba034 100644
--- a/include/linux/fault-inject.h
+++ b/include/linux/fault-inject.h
@@ -18,7 +18,7 @@ struct fault_attr {
atomic_t times;
atomic_t space;
unsigned long verbose;
- u32 task_filter;
+ bool task_filter;
unsigned long stacktrace_depth;
unsigned long require_start;
unsigned long require_end;
diff --git a/kernel/futex.c b/kernel/futex.c
index 6e443efc65f4..395b967841b4 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -267,10 +267,10 @@ static struct futex_hash_bucket *futex_queues;
static struct {
struct fault_attr attr;
- u32 ignore_private;
+ bool ignore_private;
} fail_futex = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_private = 0,
+ .ignore_private = false,
};
static int __init setup_fail_futex(char *str)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index dace71fe41f7..fcb65d2a0b94 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -100,7 +100,7 @@ static LIST_HEAD(free_entries);
static DEFINE_SPINLOCK(free_entries_lock);
/* Global disable flag - will be set in case of an error */
-static u32 global_disable __read_mostly;
+static bool global_disable __read_mostly;
/* Early initialization disable flag, set at the end of dma_debug_init */
static bool dma_debug_initialized __read_mostly;
diff --git a/mm/failslab.c b/mm/failslab.c
index fefaabaab76d..98fb490311eb 100644
--- a/mm/failslab.c
+++ b/mm/failslab.c
@@ -3,12 +3,12 @@
static struct {
struct fault_attr attr;
- u32 ignore_gfp_wait;
- int cache_filter;
+ bool ignore_gfp_wait;
+ bool cache_filter;
} failslab = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_gfp_wait = 1,
- .cache_filter = 0,
+ .ignore_gfp_wait = true,
+ .cache_filter = false,
};
bool should_failslab(size_t size, gfp_t gfpflags, unsigned long cache_flags)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 48aaf7b9f253..805bbad2e24e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2159,13 +2159,13 @@ struct page *buffered_rmqueue(struct zone *preferred_zone,
static struct {
struct fault_attr attr;
- u32 ignore_gfp_highmem;
- u32 ignore_gfp_wait;
+ bool ignore_gfp_highmem;
+ bool ignore_gfp_wait;
u32 min_order;
} fail_page_alloc = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_gfp_wait = 1,
- .ignore_gfp_highmem = 1,
+ .ignore_gfp_wait = true,
+ .ignore_gfp_highmem = true,
.min_order = 1,
};
diff --git a/sound/soc/codecs/wm_adsp.h b/sound/soc/codecs/wm_adsp.h
index 579a6350fb01..2d117cf0e953 100644
--- a/sound/soc/codecs/wm_adsp.h
+++ b/sound/soc/codecs/wm_adsp.h
@@ -53,7 +53,7 @@ struct wm_adsp {
int fw;
int fw_ver;
- u32 running;
+ bool running;
struct list_head ctl_list;
--
2.4.0
^ permalink raw reply related [flat|nested] 135+ messages in thread
* [PATCH V4 2/2] debugfs: Pass bool pointer to debugfs_create_bool()
@ 2015-09-25 16:41 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 16:41 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linaro-kernel, QCA ath9k Development, Intel Linux Wireless,
Viresh Kumar, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument,
when all it needs is a boolean pointer.
It would be better to update this API to make it accept 'bool *'
instead, as that will make it more consistent and often more convenient.
Over that bool takes just a byte (mostly).
That required updates to all user sites as well, in the same commit
updating the API. regmap core was also using
debugfs_{read|write}_file_bool(), directly and variable types were
updated for that to be bool as well.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
V3->V4:
- Updated commit log to make it clear
- Drop 'global_lock = !!tmp' change, as that's not required at all.
- s/u32/bool for ec_sys.c
- Added Ack from Charles.
- BCC'd a lot of people (rather than cc'ing them) to make sure
- the series reaches them
- mailing lists do not block the patchset due to long cc list
- and we don't spam the BCC'd people for every reply
---
Documentation/filesystems/debugfs.txt | 2 +-
arch/arm64/kernel/debug-monitors.c | 4 ++--
drivers/acpi/ec_sys.c | 2 +-
drivers/acpi/internal.h | 2 +-
drivers/base/regmap/internal.h | 6 +++---
drivers/base/regmap/regcache-lzo.c | 4 ++--
drivers/base/regmap/regcache.c | 24 ++++++++++++------------
drivers/bluetooth/hci_qca.c | 4 ++--
drivers/iommu/amd_iommu_init.c | 2 +-
drivers/iommu/amd_iommu_types.h | 2 +-
drivers/misc/mei/mei_dev.h | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4 ++--
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.h | 4 ++--
drivers/net/wireless/b43/debugfs.c | 18 +++++++++---------
drivers/net/wireless/b43/debugfs.h | 2 +-
drivers/net/wireless/b43legacy/debugfs.c | 10 +++++-----
drivers/net/wireless/b43legacy/debugfs.h | 2 +-
drivers/net/wireless/iwlegacy/common.h | 6 +++---
drivers/net/wireless/iwlwifi/mvm/mvm.h | 6 +++---
drivers/scsi/snic/snic_trc.c | 4 ++--
drivers/scsi/snic/snic_trc.h | 2 +-
drivers/uwb/uwb-debug.c | 2 +-
fs/debugfs/file.c | 6 +++---
include/linux/debugfs.h | 4 ++--
include/linux/edac.h | 2 +-
include/linux/fault-inject.h | 2 +-
kernel/futex.c | 4 ++--
lib/dma-debug.c | 2 +-
mm/failslab.c | 8 ++++----
mm/page_alloc.c | 8 ++++----
sound/soc/codecs/wm_adsp.h | 2 +-
34 files changed, 79 insertions(+), 79 deletions(-)
diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt
index 463f595733e8..4f45f71149cb 100644
--- a/Documentation/filesystems/debugfs.txt
+++ b/Documentation/filesystems/debugfs.txt
@@ -105,7 +105,7 @@ a variable of type size_t.
Boolean values can be placed in debugfs with:
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value);
+ struct dentry *parent, bool *value);
A read on the resulting file will yield either Y (for non-zero values) or
N, followed by a newline. If written to, it will accept either upper- or
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index cebf78661a55..1c4cd4a0d7cc 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -58,7 +58,7 @@ static u32 mdscr_read(void)
* Allow root to disable self-hosted debug from userspace.
* This is useful if you want to connect an external JTAG debugger.
*/
-static u32 debug_enabled = 1;
+static bool debug_enabled = true;
static int create_debug_debugfs_entry(void)
{
@@ -69,7 +69,7 @@ fs_initcall(create_debug_debugfs_entry);
static int __init early_debug_disable(char *buf)
{
- debug_enabled = 0;
+ debug_enabled = false;
return 0;
}
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b44b91331a56..f025b044a1cf 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,7 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
- u32 val;
+ bool val;
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 9e426210c2a8..5a72e2b140fc 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -138,7 +138,7 @@ struct acpi_ec {
unsigned long gpe;
unsigned long command_addr;
unsigned long data_addr;
- unsigned long global_lock;
+ bool global_lock;
unsigned long flags;
unsigned long reference_count;
struct mutex mutex;
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index cc557886ab23..5b907f2c62b9 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -122,9 +122,9 @@ struct regmap {
unsigned int num_reg_defaults_raw;
/* if set, only the cache is modified not the HW */
- u32 cache_only;
+ bool cache_only;
/* if set, only the HW is modified not the cache */
- u32 cache_bypass;
+ bool cache_bypass;
/* if set, remember to free reg_defaults_raw */
bool cache_free;
@@ -132,7 +132,7 @@ struct regmap {
const void *reg_defaults_raw;
void *cache;
/* if set, the cache contains newer data than the HW */
- u32 cache_dirty;
+ bool cache_dirty;
/* if set, the HW registers are known to match map->reg_defaults */
bool no_sync_defaults;
diff --git a/drivers/base/regmap/regcache-lzo.c b/drivers/base/regmap/regcache-lzo.c
index 2d53f6f138e1..736e0d378567 100644
--- a/drivers/base/regmap/regcache-lzo.c
+++ b/drivers/base/regmap/regcache-lzo.c
@@ -355,9 +355,9 @@ static int regcache_lzo_sync(struct regmap *map, unsigned int min,
if (ret > 0 && val == map->reg_defaults[ret].def)
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, i, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret)
return ret;
dev_dbg(map->dev, "Synced register %#x, value %#x\n",
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index 6f8a13ec32a4..4c07802986b2 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -54,11 +54,11 @@ static int regcache_hw_init(struct regmap *map)
return -ENOMEM;
if (!map->reg_defaults_raw) {
- u32 cache_bypass = map->cache_bypass;
+ bool cache_bypass = map->cache_bypass;
dev_warn(map->dev, "No cache defaults, reading back from HW\n");
/* Bypass the cache access till data read from HW*/
- map->cache_bypass = 1;
+ map->cache_bypass = true;
tmp_buf = kmalloc(map->cache_size_raw, GFP_KERNEL);
if (!tmp_buf) {
ret = -ENOMEM;
@@ -285,9 +285,9 @@ static int regcache_default_sync(struct regmap *map, unsigned int min,
if (!regcache_reg_needs_sync(map, reg, val))
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, reg, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret) {
dev_err(map->dev, "Unable to sync register %#x. %d\n",
reg, ret);
@@ -315,7 +315,7 @@ int regcache_sync(struct regmap *map)
int ret = 0;
unsigned int i;
const char *name;
- unsigned int bypass;
+ bool bypass;
BUG_ON(!map->cache_ops);
@@ -333,7 +333,7 @@ int regcache_sync(struct regmap *map)
map->async = true;
/* Apply any patch first */
- map->cache_bypass = 1;
+ map->cache_bypass = true;
for (i = 0; i < map->patch_regs; i++) {
ret = _regmap_write(map, map->patch[i].reg, map->patch[i].def);
if (ret != 0) {
@@ -342,7 +342,7 @@ int regcache_sync(struct regmap *map)
goto out;
}
}
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (map->cache_ops->sync)
ret = map->cache_ops->sync(map, 0, map->max_register);
@@ -384,7 +384,7 @@ int regcache_sync_region(struct regmap *map, unsigned int min,
{
int ret = 0;
const char *name;
- unsigned int bypass;
+ bool bypass;
BUG_ON(!map->cache_ops);
@@ -637,11 +637,11 @@ static int regcache_sync_block_single(struct regmap *map, void *block,
if (!regcache_reg_needs_sync(map, regtmp, val))
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, regtmp, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret != 0) {
dev_err(map->dev, "Unable to sync register %#x. %d\n",
regtmp, ret);
@@ -668,14 +668,14 @@ static int regcache_sync_block_raw_flush(struct regmap *map, const void **data,
dev_dbg(map->dev, "Writing %zu bytes for %d registers from 0x%x-0x%x\n",
count * val_bytes, count, base, cur - map->reg_stride);
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_raw_write(map, base, *data, count * val_bytes);
if (ret)
dev_err(map->dev, "Unable to sync registers %#x-%#x. %d\n",
base, cur - map->reg_stride, ret);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
*data = NULL;
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 6b9b91267959..509477681661 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -80,8 +80,8 @@ struct qca_data {
spinlock_t hci_ibs_lock; /* HCI_IBS state lock */
u8 tx_ibs_state; /* HCI_IBS transmit side power state*/
u8 rx_ibs_state; /* HCI_IBS receive side power state */
- u32 tx_vote; /* Clock must be on for TX */
- u32 rx_vote; /* Clock must be on for RX */
+ bool tx_vote; /* Clock must be on for TX */
+ bool rx_vote; /* Clock must be on for RX */
struct timer_list tx_idle_timer;
u32 tx_idle_delay;
struct timer_list wake_retrans_timer;
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 5ef347a13cb5..c59314523f4c 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -138,7 +138,7 @@ u16 amd_iommu_last_bdf; /* largest PCI device id we have
to handle */
LIST_HEAD(amd_iommu_unity_map); /* a list of required unity mappings
we find in ACPI */
-u32 amd_iommu_unmap_flush; /* if true, flush on every unmap */
+bool amd_iommu_unmap_flush; /* if true, flush on every unmap */
LIST_HEAD(amd_iommu_list); /* list of all AMD IOMMUs in the
system */
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index f65908841be0..861550a1ad1f 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -674,7 +674,7 @@ extern unsigned long *amd_iommu_pd_alloc_bitmap;
* If true, the addresses will be flushed on unmap time, not when
* they are reused
*/
-extern u32 amd_iommu_unmap_flush;
+extern bool amd_iommu_unmap_flush;
/* Smallest max PASID supported by any IOMMU in the system */
extern u32 amd_iommu_max_pasid;
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index e25ee16c658e..d74b6aa8ae27 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -528,7 +528,7 @@ struct mei_device {
DECLARE_BITMAP(host_clients_map, MEI_CLIENTS_MAX);
unsigned long me_client_index;
- u32 allow_fixed_address;
+ bool allow_fixed_address;
struct mei_cl wd_cl;
enum mei_wd_states wd_state;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index fa0c7b54ec7a..5384f999c24b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -767,8 +767,8 @@ struct adapter {
bool tid_release_task_busy;
struct dentry *debugfs_root;
- u32 use_bd; /* Use SGE Back Door intfc for reading SGE Contexts */
- u32 trace_rss; /* 1 implies that different RSS flit per filter is
+ bool use_bd; /* Use SGE Back Door intfc for reading SGE Contexts */
+ bool trace_rss; /* 1 implies that different RSS flit per filter is
* used per filter else if 0 default RSS flit is
* used for all 4 filters.
*/
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 12542144fe12..b6a08177b6ee 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -680,7 +680,7 @@ struct ath10k {
bool monitor_started;
unsigned int filter_flags;
unsigned long dev_flags;
- u32 dfs_block_radar_events;
+ bool dfs_block_radar_events;
/* protected by conf_mutex */
bool radar_enabled;
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index fa6e89e5c421..ba12f7f4061d 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1367,7 +1367,7 @@ struct ath5k_hw {
u8 ah_retry_long;
u8 ah_retry_short;
- u32 ah_use_32khz_clock;
+ bool ah_use_32khz_clock;
u8 ah_coverage_class;
bool ah_ack_bitrate_high;
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1dd0339de372..8823fadada89 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -385,7 +385,7 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
ah->config.dma_beacon_response_time = 1;
ah->config.sw_beacon_response_time = 6;
- ah->config.cwm_ignore_extcca = 0;
+ ah->config.cwm_ignore_extcca = false;
ah->config.analog_shiftreg = 1;
ah->config.rx_intr_mitigation = true;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index e8454db17634..52971b48ab6a 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -332,14 +332,14 @@ enum ath9k_hw_hang_checks {
struct ath9k_ops_config {
int dma_beacon_response_time;
int sw_beacon_response_time;
- u32 cwm_ignore_extcca;
+ bool cwm_ignore_extcca;
u32 pcie_waen;
u8 analog_shiftreg;
u32 ofdm_trig_low;
u32 ofdm_trig_high;
u32 cck_trig_high;
u32 cck_trig_low;
- u32 enable_paprd;
+ bool enable_paprd;
int serialize_regmode;
bool rx_intr_mitigation;
bool tx_intr_mitigation;
diff --git a/drivers/net/wireless/b43/debugfs.c b/drivers/net/wireless/b43/debugfs.c
index e807bd930647..b4bcd94aff6c 100644
--- a/drivers/net/wireless/b43/debugfs.c
+++ b/drivers/net/wireless/b43/debugfs.c
@@ -676,15 +676,15 @@ static void b43_add_dynamic_debug(struct b43_wldev *dev)
e->dyn_debug_dentries[id] = d; \
} while (0)
- add_dyn_dbg("debug_xmitpower", B43_DBG_XMITPOWER, 0);
- add_dyn_dbg("debug_dmaoverflow", B43_DBG_DMAOVERFLOW, 0);
- add_dyn_dbg("debug_dmaverbose", B43_DBG_DMAVERBOSE, 0);
- add_dyn_dbg("debug_pwork_fast", B43_DBG_PWORK_FAST, 0);
- add_dyn_dbg("debug_pwork_stop", B43_DBG_PWORK_STOP, 0);
- add_dyn_dbg("debug_lo", B43_DBG_LO, 0);
- add_dyn_dbg("debug_firmware", B43_DBG_FIRMWARE, 0);
- add_dyn_dbg("debug_keys", B43_DBG_KEYS, 0);
- add_dyn_dbg("debug_verbose_stats", B43_DBG_VERBOSESTATS, 0);
+ add_dyn_dbg("debug_xmitpower", B43_DBG_XMITPOWER, false);
+ add_dyn_dbg("debug_dmaoverflow", B43_DBG_DMAOVERFLOW, false);
+ add_dyn_dbg("debug_dmaverbose", B43_DBG_DMAVERBOSE, false);
+ add_dyn_dbg("debug_pwork_fast", B43_DBG_PWORK_FAST, false);
+ add_dyn_dbg("debug_pwork_stop", B43_DBG_PWORK_STOP, false);
+ add_dyn_dbg("debug_lo", B43_DBG_LO, false);
+ add_dyn_dbg("debug_firmware", B43_DBG_FIRMWARE, false);
+ add_dyn_dbg("debug_keys", B43_DBG_KEYS, false);
+ add_dyn_dbg("debug_verbose_stats", B43_DBG_VERBOSESTATS, false);
#undef add_dyn_dbg
}
diff --git a/drivers/net/wireless/b43/debugfs.h b/drivers/net/wireless/b43/debugfs.h
index 50517b801cb4..d05377745011 100644
--- a/drivers/net/wireless/b43/debugfs.h
+++ b/drivers/net/wireless/b43/debugfs.h
@@ -68,7 +68,7 @@ struct b43_dfsentry {
u32 shm32read_addr_next;
/* Enabled/Disabled list for the dynamic debugging features. */
- u32 dyn_debug[__B43_NR_DYNDBG];
+ bool dyn_debug[__B43_NR_DYNDBG];
/* Dentries for the dynamic debugging entries. */
struct dentry *dyn_debug_dentries[__B43_NR_DYNDBG];
};
diff --git a/drivers/net/wireless/b43legacy/debugfs.c b/drivers/net/wireless/b43legacy/debugfs.c
index 1965edb765a2..090910ea259e 100644
--- a/drivers/net/wireless/b43legacy/debugfs.c
+++ b/drivers/net/wireless/b43legacy/debugfs.c
@@ -369,11 +369,11 @@ static void b43legacy_add_dynamic_debug(struct b43legacy_wldev *dev)
e->dyn_debug_dentries[id] = d; \
} while (0)
- add_dyn_dbg("debug_xmitpower", B43legacy_DBG_XMITPOWER, 0);
- add_dyn_dbg("debug_dmaoverflow", B43legacy_DBG_DMAOVERFLOW, 0);
- add_dyn_dbg("debug_dmaverbose", B43legacy_DBG_DMAVERBOSE, 0);
- add_dyn_dbg("debug_pwork_fast", B43legacy_DBG_PWORK_FAST, 0);
- add_dyn_dbg("debug_pwork_stop", B43legacy_DBG_PWORK_STOP, 0);
+ add_dyn_dbg("debug_xmitpower", B43legacy_DBG_XMITPOWER, false);
+ add_dyn_dbg("debug_dmaoverflow", B43legacy_DBG_DMAOVERFLOW, false);
+ add_dyn_dbg("debug_dmaverbose", B43legacy_DBG_DMAVERBOSE, false);
+ add_dyn_dbg("debug_pwork_fast", B43legacy_DBG_PWORK_FAST, false);
+ add_dyn_dbg("debug_pwork_stop", B43legacy_DBG_PWORK_STOP, false);
#undef add_dyn_dbg
}
diff --git a/drivers/net/wireless/b43legacy/debugfs.h b/drivers/net/wireless/b43legacy/debugfs.h
index ae3b0d0fa849..9ee32158b947 100644
--- a/drivers/net/wireless/b43legacy/debugfs.h
+++ b/drivers/net/wireless/b43legacy/debugfs.h
@@ -47,7 +47,7 @@ struct b43legacy_dfsentry {
struct b43legacy_txstatus_log txstatlog;
/* Enabled/Disabled list for the dynamic debugging features. */
- u32 dyn_debug[__B43legacy_NR_DYNDBG];
+ bool dyn_debug[__B43legacy_NR_DYNDBG];
/* Dentries for the dynamic debugging entries. */
struct dentry *dyn_debug_dentries[__B43legacy_NR_DYNDBG];
};
diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index 5b972798bdff..ce52cf114fde 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -1425,9 +1425,9 @@ struct il_priv {
#endif /* CONFIG_IWLEGACY_DEBUGFS */
struct work_struct txpower_work;
- u32 disable_sens_cal;
- u32 disable_chain_noise_cal;
- u32 disable_tx_power_cal;
+ bool disable_sens_cal;
+ bool disable_chain_noise_cal;
+ bool disable_tx_power_cal;
struct work_struct run_time_calib_work;
struct timer_list stats_periodic;
struct timer_list watchdog;
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index b95a07ec9e36..72e8a03a5293 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -649,7 +649,7 @@ struct iwl_mvm {
const struct iwl_fw_bcast_filter *bcast_filters;
#ifdef CONFIG_IWLWIFI_DEBUGFS
struct {
- u32 override; /* u32 for debugfs_create_bool */
+ bool override;
struct iwl_bcast_filter_cmd cmd;
} dbgfs_bcast_filtering;
#endif
@@ -673,7 +673,7 @@ struct iwl_mvm {
bool disable_power_off;
bool disable_power_off_d3;
- u32 scan_iter_notif_enabled; /* must be u32 for debugfs_create_bool */
+ bool scan_iter_notif_enabled;
struct debugfs_blob_wrapper nvm_hw_blob;
struct debugfs_blob_wrapper nvm_sw_blob;
@@ -729,7 +729,7 @@ struct iwl_mvm {
int n_nd_channels;
bool net_detect;
#ifdef CONFIG_IWLWIFI_DEBUGFS
- u32 d3_wake_sysassert; /* must be u32 for debugfs_create_bool */
+ bool d3_wake_sysassert;
bool d3_test_active;
bool store_d3_resume_sram;
void *d3_resume_sram;
diff --git a/drivers/scsi/snic/snic_trc.c b/drivers/scsi/snic/snic_trc.c
index 28a40a7ade38..f00ebf4717e0 100644
--- a/drivers/scsi/snic/snic_trc.c
+++ b/drivers/scsi/snic/snic_trc.c
@@ -148,7 +148,7 @@ snic_trc_init(void)
trc->max_idx = (tbuf_sz / SNIC_TRC_ENTRY_SZ);
trc->rd_idx = trc->wr_idx = 0;
- trc->enable = 1;
+ trc->enable = true;
SNIC_INFO("Trace Facility Enabled.\n Trace Buffer SZ %lu Pages.\n",
tbuf_sz / PAGE_SIZE);
ret = 0;
@@ -169,7 +169,7 @@ snic_trc_free(void)
{
struct snic_trc *trc = &snic_glob->trc;
- trc->enable = 0;
+ trc->enable = false;
snic_trc_debugfs_term();
if (trc->buf) {
diff --git a/drivers/scsi/snic/snic_trc.h b/drivers/scsi/snic/snic_trc.h
index 427faee5f97e..b37f8867bfde 100644
--- a/drivers/scsi/snic/snic_trc.h
+++ b/drivers/scsi/snic/snic_trc.h
@@ -45,7 +45,7 @@ struct snic_trc {
u32 max_idx; /* Max Index into trace buffer */
u32 rd_idx;
u32 wr_idx;
- u32 enable; /* Control Variable for Tracing */
+ bool enable; /* Control Variable for Tracing */
struct dentry *trc_enable; /* debugfs file object */
struct dentry *trc_file;
diff --git a/drivers/uwb/uwb-debug.c b/drivers/uwb/uwb-debug.c
index 0b1e5a9449b5..991374b13571 100644
--- a/drivers/uwb/uwb-debug.c
+++ b/drivers/uwb/uwb-debug.c
@@ -55,7 +55,7 @@
struct uwb_dbg {
struct uwb_pal pal;
- u32 accept;
+ bool accept;
struct list_head rsvs;
struct dentry *root_d;
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 6c55ade071c3..b70c20fae502 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -439,7 +439,7 @@ ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
char buf[3];
- u32 *val = file->private_data;
+ bool *val = file->private_data;
if (*val)
buf[0] = 'Y';
@@ -457,7 +457,7 @@ ssize_t debugfs_write_file_bool(struct file *file, const char __user *user_buf,
char buf[32];
size_t buf_size;
bool bv;
- u32 *val = file->private_data;
+ bool *val = file->private_data;
buf_size = min(count, (sizeof(buf)-1));
if (copy_from_user(buf, user_buf, buf_size))
@@ -503,7 +503,7 @@ static const struct file_operations fops_bool = {
* code.
*/
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value)
+ struct dentry *parent, bool *value)
{
return debugfs_create_file(name, mode, parent, value, &fops_bool);
}
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 9beb636b97eb..8321fe3058d6 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -92,7 +92,7 @@ struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
struct dentry *debugfs_create_atomic_t(const char *name, umode_t mode,
struct dentry *parent, atomic_t *value);
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value);
+ struct dentry *parent, bool *value);
struct dentry *debugfs_create_blob(const char *name, umode_t mode,
struct dentry *parent,
@@ -243,7 +243,7 @@ static inline struct dentry *debugfs_create_atomic_t(const char *name, umode_t m
static inline struct dentry *debugfs_create_bool(const char *name, umode_t mode,
struct dentry *parent,
- u32 *value)
+ bool *value)
{
return ERR_PTR(-ENODEV);
}
diff --git a/include/linux/edac.h b/include/linux/edac.h
index da3b72e95db3..7c6b7ba55589 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -772,7 +772,7 @@ struct mem_ctl_info {
#ifdef CONFIG_EDAC_DEBUG
struct dentry *debugfs;
u8 fake_inject_layer[EDAC_MAX_LAYERS];
- u32 fake_inject_ue;
+ bool fake_inject_ue;
u16 fake_inject_count;
#endif
};
diff --git a/include/linux/fault-inject.h b/include/linux/fault-inject.h
index 798fad9e420d..3159a7dba034 100644
--- a/include/linux/fault-inject.h
+++ b/include/linux/fault-inject.h
@@ -18,7 +18,7 @@ struct fault_attr {
atomic_t times;
atomic_t space;
unsigned long verbose;
- u32 task_filter;
+ bool task_filter;
unsigned long stacktrace_depth;
unsigned long require_start;
unsigned long require_end;
diff --git a/kernel/futex.c b/kernel/futex.c
index 6e443efc65f4..395b967841b4 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -267,10 +267,10 @@ static struct futex_hash_bucket *futex_queues;
static struct {
struct fault_attr attr;
- u32 ignore_private;
+ bool ignore_private;
} fail_futex = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_private = 0,
+ .ignore_private = false,
};
static int __init setup_fail_futex(char *str)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index dace71fe41f7..fcb65d2a0b94 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -100,7 +100,7 @@ static LIST_HEAD(free_entries);
static DEFINE_SPINLOCK(free_entries_lock);
/* Global disable flag - will be set in case of an error */
-static u32 global_disable __read_mostly;
+static bool global_disable __read_mostly;
/* Early initialization disable flag, set at the end of dma_debug_init */
static bool dma_debug_initialized __read_mostly;
diff --git a/mm/failslab.c b/mm/failslab.c
index fefaabaab76d..98fb490311eb 100644
--- a/mm/failslab.c
+++ b/mm/failslab.c
@@ -3,12 +3,12 @@
static struct {
struct fault_attr attr;
- u32 ignore_gfp_wait;
- int cache_filter;
+ bool ignore_gfp_wait;
+ bool cache_filter;
} failslab = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_gfp_wait = 1,
- .cache_filter = 0,
+ .ignore_gfp_wait = true,
+ .cache_filter = false,
};
bool should_failslab(size_t size, gfp_t gfpflags, unsigned long cache_flags)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 48aaf7b9f253..805bbad2e24e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2159,13 +2159,13 @@ struct page *buffered_rmqueue(struct zone *preferred_zone,
static struct {
struct fault_attr attr;
- u32 ignore_gfp_highmem;
- u32 ignore_gfp_wait;
+ bool ignore_gfp_highmem;
+ bool ignore_gfp_wait;
u32 min_order;
} fail_page_alloc = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_gfp_wait = 1,
- .ignore_gfp_highmem = 1,
+ .ignore_gfp_wait = true,
+ .ignore_gfp_highmem = true,
.min_order = 1,
};
diff --git a/sound/soc/codecs/wm_adsp.h b/sound/soc/codecs/wm_adsp.h
index 579a6350fb01..2d117cf0e953 100644
--- a/sound/soc/codecs/wm_adsp.h
+++ b/sound/soc/codecs/wm_adsp.h
@@ -53,7 +53,7 @@ struct wm_adsp {
int fw;
int fw_ver;
- u32 running;
+ bool running;
struct list_head ctl_list;
--
2.4.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related [flat|nested] 135+ messages in thread
* [PATCH V4 2/2] debugfs: Pass bool pointer to debugfs_create_bool()
@ 2015-09-25 16:41 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 16:41 UTC (permalink / raw)
To: linux-arm-kernel
Its a bit odd that debugfs_create_bool() takes 'u32 *' as an argument,
when all it needs is a boolean pointer.
It would be better to update this API to make it accept 'bool *'
instead, as that will make it more consistent and often more convenient.
Over that bool takes just a byte (mostly).
That required updates to all user sites as well, in the same commit
updating the API. regmap core was also using
debugfs_{read|write}_file_bool(), directly and variable types were
updated for that to be bool as well.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
V3->V4:
- Updated commit log to make it clear
- Drop 'global_lock = !!tmp' change, as that's not required at all.
- s/u32/bool for ec_sys.c
- Added Ack from Charles.
- BCC'd a lot of people (rather than cc'ing them) to make sure
- the series reaches them
- mailing lists do not block the patchset due to long cc list
- and we don't spam the BCC'd people for every reply
---
Documentation/filesystems/debugfs.txt | 2 +-
arch/arm64/kernel/debug-monitors.c | 4 ++--
drivers/acpi/ec_sys.c | 2 +-
drivers/acpi/internal.h | 2 +-
drivers/base/regmap/internal.h | 6 +++---
drivers/base/regmap/regcache-lzo.c | 4 ++--
drivers/base/regmap/regcache.c | 24 ++++++++++++------------
drivers/bluetooth/hci_qca.c | 4 ++--
drivers/iommu/amd_iommu_init.c | 2 +-
drivers/iommu/amd_iommu_types.h | 2 +-
drivers/misc/mei/mei_dev.h | 2 +-
drivers/net/ethernet/chelsio/cxgb4/cxgb4.h | 4 ++--
drivers/net/wireless/ath/ath10k/core.h | 2 +-
drivers/net/wireless/ath/ath5k/ath5k.h | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.h | 4 ++--
drivers/net/wireless/b43/debugfs.c | 18 +++++++++---------
drivers/net/wireless/b43/debugfs.h | 2 +-
drivers/net/wireless/b43legacy/debugfs.c | 10 +++++-----
drivers/net/wireless/b43legacy/debugfs.h | 2 +-
drivers/net/wireless/iwlegacy/common.h | 6 +++---
drivers/net/wireless/iwlwifi/mvm/mvm.h | 6 +++---
drivers/scsi/snic/snic_trc.c | 4 ++--
drivers/scsi/snic/snic_trc.h | 2 +-
drivers/uwb/uwb-debug.c | 2 +-
fs/debugfs/file.c | 6 +++---
include/linux/debugfs.h | 4 ++--
include/linux/edac.h | 2 +-
include/linux/fault-inject.h | 2 +-
kernel/futex.c | 4 ++--
lib/dma-debug.c | 2 +-
mm/failslab.c | 8 ++++----
mm/page_alloc.c | 8 ++++----
sound/soc/codecs/wm_adsp.h | 2 +-
34 files changed, 79 insertions(+), 79 deletions(-)
diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt
index 463f595733e8..4f45f71149cb 100644
--- a/Documentation/filesystems/debugfs.txt
+++ b/Documentation/filesystems/debugfs.txt
@@ -105,7 +105,7 @@ a variable of type size_t.
Boolean values can be placed in debugfs with:
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value);
+ struct dentry *parent, bool *value);
A read on the resulting file will yield either Y (for non-zero values) or
N, followed by a newline. If written to, it will accept either upper- or
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index cebf78661a55..1c4cd4a0d7cc 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -58,7 +58,7 @@ static u32 mdscr_read(void)
* Allow root to disable self-hosted debug from userspace.
* This is useful if you want to connect an external JTAG debugger.
*/
-static u32 debug_enabled = 1;
+static bool debug_enabled = true;
static int create_debug_debugfs_entry(void)
{
@@ -69,7 +69,7 @@ fs_initcall(create_debug_debugfs_entry);
static int __init early_debug_disable(char *buf)
{
- debug_enabled = 0;
+ debug_enabled = false;
return 0;
}
diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
index b44b91331a56..f025b044a1cf 100644
--- a/drivers/acpi/ec_sys.c
+++ b/drivers/acpi/ec_sys.c
@@ -110,7 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
struct dentry *dev_dir;
char name[64];
umode_t mode = 0400;
- u32 val;
+ bool val;
if (ec_device_count == 0) {
acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index 9e426210c2a8..5a72e2b140fc 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -138,7 +138,7 @@ struct acpi_ec {
unsigned long gpe;
unsigned long command_addr;
unsigned long data_addr;
- unsigned long global_lock;
+ bool global_lock;
unsigned long flags;
unsigned long reference_count;
struct mutex mutex;
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index cc557886ab23..5b907f2c62b9 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -122,9 +122,9 @@ struct regmap {
unsigned int num_reg_defaults_raw;
/* if set, only the cache is modified not the HW */
- u32 cache_only;
+ bool cache_only;
/* if set, only the HW is modified not the cache */
- u32 cache_bypass;
+ bool cache_bypass;
/* if set, remember to free reg_defaults_raw */
bool cache_free;
@@ -132,7 +132,7 @@ struct regmap {
const void *reg_defaults_raw;
void *cache;
/* if set, the cache contains newer data than the HW */
- u32 cache_dirty;
+ bool cache_dirty;
/* if set, the HW registers are known to match map->reg_defaults */
bool no_sync_defaults;
diff --git a/drivers/base/regmap/regcache-lzo.c b/drivers/base/regmap/regcache-lzo.c
index 2d53f6f138e1..736e0d378567 100644
--- a/drivers/base/regmap/regcache-lzo.c
+++ b/drivers/base/regmap/regcache-lzo.c
@@ -355,9 +355,9 @@ static int regcache_lzo_sync(struct regmap *map, unsigned int min,
if (ret > 0 && val == map->reg_defaults[ret].def)
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, i, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret)
return ret;
dev_dbg(map->dev, "Synced register %#x, value %#x\n",
diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c
index 6f8a13ec32a4..4c07802986b2 100644
--- a/drivers/base/regmap/regcache.c
+++ b/drivers/base/regmap/regcache.c
@@ -54,11 +54,11 @@ static int regcache_hw_init(struct regmap *map)
return -ENOMEM;
if (!map->reg_defaults_raw) {
- u32 cache_bypass = map->cache_bypass;
+ bool cache_bypass = map->cache_bypass;
dev_warn(map->dev, "No cache defaults, reading back from HW\n");
/* Bypass the cache access till data read from HW*/
- map->cache_bypass = 1;
+ map->cache_bypass = true;
tmp_buf = kmalloc(map->cache_size_raw, GFP_KERNEL);
if (!tmp_buf) {
ret = -ENOMEM;
@@ -285,9 +285,9 @@ static int regcache_default_sync(struct regmap *map, unsigned int min,
if (!regcache_reg_needs_sync(map, reg, val))
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, reg, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret) {
dev_err(map->dev, "Unable to sync register %#x. %d\n",
reg, ret);
@@ -315,7 +315,7 @@ int regcache_sync(struct regmap *map)
int ret = 0;
unsigned int i;
const char *name;
- unsigned int bypass;
+ bool bypass;
BUG_ON(!map->cache_ops);
@@ -333,7 +333,7 @@ int regcache_sync(struct regmap *map)
map->async = true;
/* Apply any patch first */
- map->cache_bypass = 1;
+ map->cache_bypass = true;
for (i = 0; i < map->patch_regs; i++) {
ret = _regmap_write(map, map->patch[i].reg, map->patch[i].def);
if (ret != 0) {
@@ -342,7 +342,7 @@ int regcache_sync(struct regmap *map)
goto out;
}
}
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (map->cache_ops->sync)
ret = map->cache_ops->sync(map, 0, map->max_register);
@@ -384,7 +384,7 @@ int regcache_sync_region(struct regmap *map, unsigned int min,
{
int ret = 0;
const char *name;
- unsigned int bypass;
+ bool bypass;
BUG_ON(!map->cache_ops);
@@ -637,11 +637,11 @@ static int regcache_sync_block_single(struct regmap *map, void *block,
if (!regcache_reg_needs_sync(map, regtmp, val))
continue;
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_write(map, regtmp, val);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
if (ret != 0) {
dev_err(map->dev, "Unable to sync register %#x. %d\n",
regtmp, ret);
@@ -668,14 +668,14 @@ static int regcache_sync_block_raw_flush(struct regmap *map, const void **data,
dev_dbg(map->dev, "Writing %zu bytes for %d registers from 0x%x-0x%x\n",
count * val_bytes, count, base, cur - map->reg_stride);
- map->cache_bypass = 1;
+ map->cache_bypass = true;
ret = _regmap_raw_write(map, base, *data, count * val_bytes);
if (ret)
dev_err(map->dev, "Unable to sync registers %#x-%#x. %d\n",
base, cur - map->reg_stride, ret);
- map->cache_bypass = 0;
+ map->cache_bypass = false;
*data = NULL;
diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 6b9b91267959..509477681661 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -80,8 +80,8 @@ struct qca_data {
spinlock_t hci_ibs_lock; /* HCI_IBS state lock */
u8 tx_ibs_state; /* HCI_IBS transmit side power state*/
u8 rx_ibs_state; /* HCI_IBS receive side power state */
- u32 tx_vote; /* Clock must be on for TX */
- u32 rx_vote; /* Clock must be on for RX */
+ bool tx_vote; /* Clock must be on for TX */
+ bool rx_vote; /* Clock must be on for RX */
struct timer_list tx_idle_timer;
u32 tx_idle_delay;
struct timer_list wake_retrans_timer;
diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 5ef347a13cb5..c59314523f4c 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -138,7 +138,7 @@ u16 amd_iommu_last_bdf; /* largest PCI device id we have
to handle */
LIST_HEAD(amd_iommu_unity_map); /* a list of required unity mappings
we find in ACPI */
-u32 amd_iommu_unmap_flush; /* if true, flush on every unmap */
+bool amd_iommu_unmap_flush; /* if true, flush on every unmap */
LIST_HEAD(amd_iommu_list); /* list of all AMD IOMMUs in the
system */
diff --git a/drivers/iommu/amd_iommu_types.h b/drivers/iommu/amd_iommu_types.h
index f65908841be0..861550a1ad1f 100644
--- a/drivers/iommu/amd_iommu_types.h
+++ b/drivers/iommu/amd_iommu_types.h
@@ -674,7 +674,7 @@ extern unsigned long *amd_iommu_pd_alloc_bitmap;
* If true, the addresses will be flushed on unmap time, not when
* they are reused
*/
-extern u32 amd_iommu_unmap_flush;
+extern bool amd_iommu_unmap_flush;
/* Smallest max PASID supported by any IOMMU in the system */
extern u32 amd_iommu_max_pasid;
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index e25ee16c658e..d74b6aa8ae27 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -528,7 +528,7 @@ struct mei_device {
DECLARE_BITMAP(host_clients_map, MEI_CLIENTS_MAX);
unsigned long me_client_index;
- u32 allow_fixed_address;
+ bool allow_fixed_address;
struct mei_cl wd_cl;
enum mei_wd_states wd_state;
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
index fa0c7b54ec7a..5384f999c24b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4.h
@@ -767,8 +767,8 @@ struct adapter {
bool tid_release_task_busy;
struct dentry *debugfs_root;
- u32 use_bd; /* Use SGE Back Door intfc for reading SGE Contexts */
- u32 trace_rss; /* 1 implies that different RSS flit per filter is
+ bool use_bd; /* Use SGE Back Door intfc for reading SGE Contexts */
+ bool trace_rss; /* 1 implies that different RSS flit per filter is
* used per filter else if 0 default RSS flit is
* used for all 4 filters.
*/
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index 12542144fe12..b6a08177b6ee 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -680,7 +680,7 @@ struct ath10k {
bool monitor_started;
unsigned int filter_flags;
unsigned long dev_flags;
- u32 dfs_block_radar_events;
+ bool dfs_block_radar_events;
/* protected by conf_mutex */
bool radar_enabled;
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index fa6e89e5c421..ba12f7f4061d 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -1367,7 +1367,7 @@ struct ath5k_hw {
u8 ah_retry_long;
u8 ah_retry_short;
- u32 ah_use_32khz_clock;
+ bool ah_use_32khz_clock;
u8 ah_coverage_class;
bool ah_ack_bitrate_high;
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 1dd0339de372..8823fadada89 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -385,7 +385,7 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
ah->config.dma_beacon_response_time = 1;
ah->config.sw_beacon_response_time = 6;
- ah->config.cwm_ignore_extcca = 0;
+ ah->config.cwm_ignore_extcca = false;
ah->config.analog_shiftreg = 1;
ah->config.rx_intr_mitigation = true;
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index e8454db17634..52971b48ab6a 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -332,14 +332,14 @@ enum ath9k_hw_hang_checks {
struct ath9k_ops_config {
int dma_beacon_response_time;
int sw_beacon_response_time;
- u32 cwm_ignore_extcca;
+ bool cwm_ignore_extcca;
u32 pcie_waen;
u8 analog_shiftreg;
u32 ofdm_trig_low;
u32 ofdm_trig_high;
u32 cck_trig_high;
u32 cck_trig_low;
- u32 enable_paprd;
+ bool enable_paprd;
int serialize_regmode;
bool rx_intr_mitigation;
bool tx_intr_mitigation;
diff --git a/drivers/net/wireless/b43/debugfs.c b/drivers/net/wireless/b43/debugfs.c
index e807bd930647..b4bcd94aff6c 100644
--- a/drivers/net/wireless/b43/debugfs.c
+++ b/drivers/net/wireless/b43/debugfs.c
@@ -676,15 +676,15 @@ static void b43_add_dynamic_debug(struct b43_wldev *dev)
e->dyn_debug_dentries[id] = d; \
} while (0)
- add_dyn_dbg("debug_xmitpower", B43_DBG_XMITPOWER, 0);
- add_dyn_dbg("debug_dmaoverflow", B43_DBG_DMAOVERFLOW, 0);
- add_dyn_dbg("debug_dmaverbose", B43_DBG_DMAVERBOSE, 0);
- add_dyn_dbg("debug_pwork_fast", B43_DBG_PWORK_FAST, 0);
- add_dyn_dbg("debug_pwork_stop", B43_DBG_PWORK_STOP, 0);
- add_dyn_dbg("debug_lo", B43_DBG_LO, 0);
- add_dyn_dbg("debug_firmware", B43_DBG_FIRMWARE, 0);
- add_dyn_dbg("debug_keys", B43_DBG_KEYS, 0);
- add_dyn_dbg("debug_verbose_stats", B43_DBG_VERBOSESTATS, 0);
+ add_dyn_dbg("debug_xmitpower", B43_DBG_XMITPOWER, false);
+ add_dyn_dbg("debug_dmaoverflow", B43_DBG_DMAOVERFLOW, false);
+ add_dyn_dbg("debug_dmaverbose", B43_DBG_DMAVERBOSE, false);
+ add_dyn_dbg("debug_pwork_fast", B43_DBG_PWORK_FAST, false);
+ add_dyn_dbg("debug_pwork_stop", B43_DBG_PWORK_STOP, false);
+ add_dyn_dbg("debug_lo", B43_DBG_LO, false);
+ add_dyn_dbg("debug_firmware", B43_DBG_FIRMWARE, false);
+ add_dyn_dbg("debug_keys", B43_DBG_KEYS, false);
+ add_dyn_dbg("debug_verbose_stats", B43_DBG_VERBOSESTATS, false);
#undef add_dyn_dbg
}
diff --git a/drivers/net/wireless/b43/debugfs.h b/drivers/net/wireless/b43/debugfs.h
index 50517b801cb4..d05377745011 100644
--- a/drivers/net/wireless/b43/debugfs.h
+++ b/drivers/net/wireless/b43/debugfs.h
@@ -68,7 +68,7 @@ struct b43_dfsentry {
u32 shm32read_addr_next;
/* Enabled/Disabled list for the dynamic debugging features. */
- u32 dyn_debug[__B43_NR_DYNDBG];
+ bool dyn_debug[__B43_NR_DYNDBG];
/* Dentries for the dynamic debugging entries. */
struct dentry *dyn_debug_dentries[__B43_NR_DYNDBG];
};
diff --git a/drivers/net/wireless/b43legacy/debugfs.c b/drivers/net/wireless/b43legacy/debugfs.c
index 1965edb765a2..090910ea259e 100644
--- a/drivers/net/wireless/b43legacy/debugfs.c
+++ b/drivers/net/wireless/b43legacy/debugfs.c
@@ -369,11 +369,11 @@ static void b43legacy_add_dynamic_debug(struct b43legacy_wldev *dev)
e->dyn_debug_dentries[id] = d; \
} while (0)
- add_dyn_dbg("debug_xmitpower", B43legacy_DBG_XMITPOWER, 0);
- add_dyn_dbg("debug_dmaoverflow", B43legacy_DBG_DMAOVERFLOW, 0);
- add_dyn_dbg("debug_dmaverbose", B43legacy_DBG_DMAVERBOSE, 0);
- add_dyn_dbg("debug_pwork_fast", B43legacy_DBG_PWORK_FAST, 0);
- add_dyn_dbg("debug_pwork_stop", B43legacy_DBG_PWORK_STOP, 0);
+ add_dyn_dbg("debug_xmitpower", B43legacy_DBG_XMITPOWER, false);
+ add_dyn_dbg("debug_dmaoverflow", B43legacy_DBG_DMAOVERFLOW, false);
+ add_dyn_dbg("debug_dmaverbose", B43legacy_DBG_DMAVERBOSE, false);
+ add_dyn_dbg("debug_pwork_fast", B43legacy_DBG_PWORK_FAST, false);
+ add_dyn_dbg("debug_pwork_stop", B43legacy_DBG_PWORK_STOP, false);
#undef add_dyn_dbg
}
diff --git a/drivers/net/wireless/b43legacy/debugfs.h b/drivers/net/wireless/b43legacy/debugfs.h
index ae3b0d0fa849..9ee32158b947 100644
--- a/drivers/net/wireless/b43legacy/debugfs.h
+++ b/drivers/net/wireless/b43legacy/debugfs.h
@@ -47,7 +47,7 @@ struct b43legacy_dfsentry {
struct b43legacy_txstatus_log txstatlog;
/* Enabled/Disabled list for the dynamic debugging features. */
- u32 dyn_debug[__B43legacy_NR_DYNDBG];
+ bool dyn_debug[__B43legacy_NR_DYNDBG];
/* Dentries for the dynamic debugging entries. */
struct dentry *dyn_debug_dentries[__B43legacy_NR_DYNDBG];
};
diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index 5b972798bdff..ce52cf114fde 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -1425,9 +1425,9 @@ struct il_priv {
#endif /* CONFIG_IWLEGACY_DEBUGFS */
struct work_struct txpower_work;
- u32 disable_sens_cal;
- u32 disable_chain_noise_cal;
- u32 disable_tx_power_cal;
+ bool disable_sens_cal;
+ bool disable_chain_noise_cal;
+ bool disable_tx_power_cal;
struct work_struct run_time_calib_work;
struct timer_list stats_periodic;
struct timer_list watchdog;
diff --git a/drivers/net/wireless/iwlwifi/mvm/mvm.h b/drivers/net/wireless/iwlwifi/mvm/mvm.h
index b95a07ec9e36..72e8a03a5293 100644
--- a/drivers/net/wireless/iwlwifi/mvm/mvm.h
+++ b/drivers/net/wireless/iwlwifi/mvm/mvm.h
@@ -649,7 +649,7 @@ struct iwl_mvm {
const struct iwl_fw_bcast_filter *bcast_filters;
#ifdef CONFIG_IWLWIFI_DEBUGFS
struct {
- u32 override; /* u32 for debugfs_create_bool */
+ bool override;
struct iwl_bcast_filter_cmd cmd;
} dbgfs_bcast_filtering;
#endif
@@ -673,7 +673,7 @@ struct iwl_mvm {
bool disable_power_off;
bool disable_power_off_d3;
- u32 scan_iter_notif_enabled; /* must be u32 for debugfs_create_bool */
+ bool scan_iter_notif_enabled;
struct debugfs_blob_wrapper nvm_hw_blob;
struct debugfs_blob_wrapper nvm_sw_blob;
@@ -729,7 +729,7 @@ struct iwl_mvm {
int n_nd_channels;
bool net_detect;
#ifdef CONFIG_IWLWIFI_DEBUGFS
- u32 d3_wake_sysassert; /* must be u32 for debugfs_create_bool */
+ bool d3_wake_sysassert;
bool d3_test_active;
bool store_d3_resume_sram;
void *d3_resume_sram;
diff --git a/drivers/scsi/snic/snic_trc.c b/drivers/scsi/snic/snic_trc.c
index 28a40a7ade38..f00ebf4717e0 100644
--- a/drivers/scsi/snic/snic_trc.c
+++ b/drivers/scsi/snic/snic_trc.c
@@ -148,7 +148,7 @@ snic_trc_init(void)
trc->max_idx = (tbuf_sz / SNIC_TRC_ENTRY_SZ);
trc->rd_idx = trc->wr_idx = 0;
- trc->enable = 1;
+ trc->enable = true;
SNIC_INFO("Trace Facility Enabled.\n Trace Buffer SZ %lu Pages.\n",
tbuf_sz / PAGE_SIZE);
ret = 0;
@@ -169,7 +169,7 @@ snic_trc_free(void)
{
struct snic_trc *trc = &snic_glob->trc;
- trc->enable = 0;
+ trc->enable = false;
snic_trc_debugfs_term();
if (trc->buf) {
diff --git a/drivers/scsi/snic/snic_trc.h b/drivers/scsi/snic/snic_trc.h
index 427faee5f97e..b37f8867bfde 100644
--- a/drivers/scsi/snic/snic_trc.h
+++ b/drivers/scsi/snic/snic_trc.h
@@ -45,7 +45,7 @@ struct snic_trc {
u32 max_idx; /* Max Index into trace buffer */
u32 rd_idx;
u32 wr_idx;
- u32 enable; /* Control Variable for Tracing */
+ bool enable; /* Control Variable for Tracing */
struct dentry *trc_enable; /* debugfs file object */
struct dentry *trc_file;
diff --git a/drivers/uwb/uwb-debug.c b/drivers/uwb/uwb-debug.c
index 0b1e5a9449b5..991374b13571 100644
--- a/drivers/uwb/uwb-debug.c
+++ b/drivers/uwb/uwb-debug.c
@@ -55,7 +55,7 @@
struct uwb_dbg {
struct uwb_pal pal;
- u32 accept;
+ bool accept;
struct list_head rsvs;
struct dentry *root_d;
diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index 6c55ade071c3..b70c20fae502 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -439,7 +439,7 @@ ssize_t debugfs_read_file_bool(struct file *file, char __user *user_buf,
size_t count, loff_t *ppos)
{
char buf[3];
- u32 *val = file->private_data;
+ bool *val = file->private_data;
if (*val)
buf[0] = 'Y';
@@ -457,7 +457,7 @@ ssize_t debugfs_write_file_bool(struct file *file, const char __user *user_buf,
char buf[32];
size_t buf_size;
bool bv;
- u32 *val = file->private_data;
+ bool *val = file->private_data;
buf_size = min(count, (sizeof(buf)-1));
if (copy_from_user(buf, user_buf, buf_size))
@@ -503,7 +503,7 @@ static const struct file_operations fops_bool = {
* code.
*/
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value)
+ struct dentry *parent, bool *value)
{
return debugfs_create_file(name, mode, parent, value, &fops_bool);
}
diff --git a/include/linux/debugfs.h b/include/linux/debugfs.h
index 9beb636b97eb..8321fe3058d6 100644
--- a/include/linux/debugfs.h
+++ b/include/linux/debugfs.h
@@ -92,7 +92,7 @@ struct dentry *debugfs_create_size_t(const char *name, umode_t mode,
struct dentry *debugfs_create_atomic_t(const char *name, umode_t mode,
struct dentry *parent, atomic_t *value);
struct dentry *debugfs_create_bool(const char *name, umode_t mode,
- struct dentry *parent, u32 *value);
+ struct dentry *parent, bool *value);
struct dentry *debugfs_create_blob(const char *name, umode_t mode,
struct dentry *parent,
@@ -243,7 +243,7 @@ static inline struct dentry *debugfs_create_atomic_t(const char *name, umode_t m
static inline struct dentry *debugfs_create_bool(const char *name, umode_t mode,
struct dentry *parent,
- u32 *value)
+ bool *value)
{
return ERR_PTR(-ENODEV);
}
diff --git a/include/linux/edac.h b/include/linux/edac.h
index da3b72e95db3..7c6b7ba55589 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -772,7 +772,7 @@ struct mem_ctl_info {
#ifdef CONFIG_EDAC_DEBUG
struct dentry *debugfs;
u8 fake_inject_layer[EDAC_MAX_LAYERS];
- u32 fake_inject_ue;
+ bool fake_inject_ue;
u16 fake_inject_count;
#endif
};
diff --git a/include/linux/fault-inject.h b/include/linux/fault-inject.h
index 798fad9e420d..3159a7dba034 100644
--- a/include/linux/fault-inject.h
+++ b/include/linux/fault-inject.h
@@ -18,7 +18,7 @@ struct fault_attr {
atomic_t times;
atomic_t space;
unsigned long verbose;
- u32 task_filter;
+ bool task_filter;
unsigned long stacktrace_depth;
unsigned long require_start;
unsigned long require_end;
diff --git a/kernel/futex.c b/kernel/futex.c
index 6e443efc65f4..395b967841b4 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -267,10 +267,10 @@ static struct futex_hash_bucket *futex_queues;
static struct {
struct fault_attr attr;
- u32 ignore_private;
+ bool ignore_private;
} fail_futex = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_private = 0,
+ .ignore_private = false,
};
static int __init setup_fail_futex(char *str)
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index dace71fe41f7..fcb65d2a0b94 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -100,7 +100,7 @@ static LIST_HEAD(free_entries);
static DEFINE_SPINLOCK(free_entries_lock);
/* Global disable flag - will be set in case of an error */
-static u32 global_disable __read_mostly;
+static bool global_disable __read_mostly;
/* Early initialization disable flag, set at the end of dma_debug_init */
static bool dma_debug_initialized __read_mostly;
diff --git a/mm/failslab.c b/mm/failslab.c
index fefaabaab76d..98fb490311eb 100644
--- a/mm/failslab.c
+++ b/mm/failslab.c
@@ -3,12 +3,12 @@
static struct {
struct fault_attr attr;
- u32 ignore_gfp_wait;
- int cache_filter;
+ bool ignore_gfp_wait;
+ bool cache_filter;
} failslab = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_gfp_wait = 1,
- .cache_filter = 0,
+ .ignore_gfp_wait = true,
+ .cache_filter = false,
};
bool should_failslab(size_t size, gfp_t gfpflags, unsigned long cache_flags)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 48aaf7b9f253..805bbad2e24e 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -2159,13 +2159,13 @@ struct page *buffered_rmqueue(struct zone *preferred_zone,
static struct {
struct fault_attr attr;
- u32 ignore_gfp_highmem;
- u32 ignore_gfp_wait;
+ bool ignore_gfp_highmem;
+ bool ignore_gfp_wait;
u32 min_order;
} fail_page_alloc = {
.attr = FAULT_ATTR_INITIALIZER,
- .ignore_gfp_wait = 1,
- .ignore_gfp_highmem = 1,
+ .ignore_gfp_wait = true,
+ .ignore_gfp_highmem = true,
.min_order = 1,
};
diff --git a/sound/soc/codecs/wm_adsp.h b/sound/soc/codecs/wm_adsp.h
index 579a6350fb01..2d117cf0e953 100644
--- a/sound/soc/codecs/wm_adsp.h
+++ b/sound/soc/codecs/wm_adsp.h
@@ -53,7 +53,7 @@ struct wm_adsp {
int fw;
int fw_ver;
- u32 running;
+ bool running;
struct list_head ctl_list;
--
2.4.0
^ permalink raw reply related [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 17:42 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2015-09-25 17:42 UTC (permalink / raw)
To: Viresh Kumar, Greg Kroah-Hartman
Cc: linaro-kernel, QCA ath9k Development, Intel Linux Wireless,
linux-doc, linux-kernel, linux-arm-kernel, linux-acpi,
linux-bluetooth, iommu, netdev, linux-wireless, linux-scsi,
linux-usb, linux-edac, linux-mm, alsa-devel
On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
Err, surely that wasn't what Rafael meant, since it's clearly
impossible to use a pointer to the stack, assign to it once, and the
expect anything to wkr at all ...
johannes
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 17:42 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2015-09-25 17:42 UTC (permalink / raw)
To: Viresh Kumar, Greg Kroah-Hartman
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, QCA ath9k Development,
Intel Linux Wireless, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-edac-u79uwXL29TY76Z2rM5mHXA
On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
> Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
Err, surely that wasn't what Rafael meant, since it's clearly
impossible to use a pointer to the stack, assign to it once, and the
expect anything to wkr at all ...
johannes
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 17:42 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2015-09-25 17:42 UTC (permalink / raw)
To: Viresh Kumar, Greg Kroah-Hartman
Cc: linaro-kernel, QCA ath9k Development, Intel Linux Wireless,
linux-doc, linux-kernel, linux-arm-kernel, linux-acpi,
linux-bluetooth, iommu, netdev, linux-wireless, linux-scsi,
linux-usb, linux-edac, linux-mm, alsa-devel
On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
Err, surely that wasn't what Rafael meant, since it's clearly
impossible to use a pointer to the stack, assign to it once, and the
expect anything to wkr at all ...
johannes
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 17:42 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2015-09-25 17:42 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
Err, surely that wasn't what Rafael meant, since it's clearly
impossible to use a pointer to the stack, assign to it once, and the
expect anything to wkr at all ...
johannes
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:47 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 18:47 UTC (permalink / raw)
To: Johannes Berg
Cc: Greg Kroah-Hartman, linaro-kernel, QCA ath9k Development,
Intel Linux Wireless, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
On 25-09-15, 19:42, Johannes Berg wrote:
> On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> > V3->V4:
> > - Create a local variable instead of changing type of global_lock
> > (Rafael)
>
> Err, surely that wasn't what Rafael meant, since it's clearly
> impossible to use a pointer to the stack, assign to it once, and the
> expect anything to wkr at all ...
Sorry, I am not sure on what wouldn't work with this patch but this is
what Rafael said, and I don't think I wrote it differently :)
Rafael wrote:
> Actually, what about adding a local u32 variable, say val, here and doing
>
> > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> > goto error;
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > - (u32 *)&first_ec->global_lock))
> > + &first_ec->global_lock))
>
> if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
>
> > goto error;
>
> first_ec->global_lock = val;
>
> And then you can turn val into bool just fine without changing the structure
> definition.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:47 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 18:47 UTC (permalink / raw)
To: Johannes Berg
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, QCA ath9k Development,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Intel Linux Wireless,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-edac-u79uwXL29TY76Z2rM5mHXA
On 25-09-15, 19:42, Johannes Berg wrote:
> On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
>
> > Signed-off-by: Viresh Kumar <viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> > ---
> > V3->V4:
> > - Create a local variable instead of changing type of global_lock
> > (Rafael)
>
> Err, surely that wasn't what Rafael meant, since it's clearly
> impossible to use a pointer to the stack, assign to it once, and the
> expect anything to wkr at all ...
Sorry, I am not sure on what wouldn't work with this patch but this is
what Rafael said, and I don't think I wrote it differently :)
Rafael wrote:
> Actually, what about adding a local u32 variable, say val, here and doing
>
> > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> > goto error;
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > - (u32 *)&first_ec->global_lock))
> > + &first_ec->global_lock))
>
> if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
>
> > goto error;
>
> first_ec->global_lock = val;
>
> And then you can turn val into bool just fine without changing the structure
> definition.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:47 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 18:47 UTC (permalink / raw)
To: Johannes Berg
Cc: Greg Kroah-Hartman, linaro-kernel, QCA ath9k Development,
Intel Linux Wireless, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
On 25-09-15, 19:42, Johannes Berg wrote:
> On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> > V3->V4:
> > - Create a local variable instead of changing type of global_lock
> > (Rafael)
>
> Err, surely that wasn't what Rafael meant, since it's clearly
> impossible to use a pointer to the stack, assign to it once, and the
> expect anything to wkr at all ...
Sorry, I am not sure on what wouldn't work with this patch but this is
what Rafael said, and I don't think I wrote it differently :)
Rafael wrote:
> Actually, what about adding a local u32 variable, say val, here and doing
>
> > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> > goto error;
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > - (u32 *)&first_ec->global_lock))
> > + &first_ec->global_lock))
>
> if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
>
> > goto error;
>
> first_ec->global_lock = val;
>
> And then you can turn val into bool just fine without changing the structure
> definition.
--
viresh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:47 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 18:47 UTC (permalink / raw)
To: linux-arm-kernel
On 25-09-15, 19:42, Johannes Berg wrote:
> On Fri, 2015-09-25 at 09:41 -0700, Viresh Kumar wrote:
>
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> > ---
> > V3->V4:
> > - Create a local variable instead of changing type of global_lock
> > (Rafael)
>
> Err, surely that wasn't what Rafael meant, since it's clearly
> impossible to use a pointer to the stack, assign to it once, and the
> expect anything to wkr at all ...
Sorry, I am not sure on what wouldn't work with this patch but this is
what Rafael said, and I don't think I wrote it differently :)
Rafael wrote:
> Actually, what about adding a local u32 variable, say val, here and doing
>
> > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> > goto error;
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > - (u32 *)&first_ec->global_lock))
> > + &first_ec->global_lock))
>
> if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
>
> > goto error;
>
> first_ec->global_lock = val;
>
> And then you can turn val into bool just fine without changing the structure
> definition.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-25 18:47 ` Viresh Kumar
(?)
@ 2015-09-25 18:49 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2015-09-25 18:49 UTC (permalink / raw)
To: Viresh Kumar
Cc: Greg Kroah-Hartman, linaro-kernel, QCA ath9k Development,
Intel Linux Wireless, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
> Rafael wrote:
> > Actually, what about adding a local u32 variable, say val, here and
> > doing
> >
> > > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32
> > > *)&first_ec->gpe))
> > > goto error;
> > > if (!debugfs_create_bool("use_global_lock", 0444,
> > > dev_dir,
> > > - (u32 *)&first_ec->global_lock))
> > > + &first_ec->global_lock))
> >
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > &val))
> >
> > > goto error;
> >
> > first_ec->global_lock = val;
> >
> > And then you can turn val into bool just fine without changing the
> > structure
> > definition.
Ok, then, but that means Rafael is completely wrong ...
debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
it can't be on the stack. You also don't get a call when it changes.
If you cannot change the struct definition then you must implement a
debugfs file with its own read/write handlers.
johannes
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:49 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2015-09-25 18:49 UTC (permalink / raw)
To: Viresh Kumar
Cc: Greg Kroah-Hartman, linaro-kernel, QCA ath9k Development,
Intel Linux Wireless, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
> Rafael wrote:
> > Actually, what about adding a local u32 variable, say val, here and
> > doing
> >
> > > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32
> > > *)&first_ec->gpe))
> > > goto error;
> > > if (!debugfs_create_bool("use_global_lock", 0444,
> > > dev_dir,
> > > - (u32 *)&first_ec->global_lock))
> > > + &first_ec->global_lock))
> >
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > &val))
> >
> > > goto error;
> >
> > first_ec->global_lock = val;
> >
> > And then you can turn val into bool just fine without changing the
> > structure
> > definition.
Ok, then, but that means Rafael is completely wrong ...
debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
it can't be on the stack. You also don't get a call when it changes.
If you cannot change the struct definition then you must implement a
debugfs file with its own read/write handlers.
johannes
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:49 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2015-09-25 18:49 UTC (permalink / raw)
To: linux-arm-kernel
> Rafael wrote:
> > Actually, what about adding a local u32 variable, say val, here and
> > doing
> >
> > > if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32
> > > *)&first_ec->gpe))
> > > goto error;
> > > if (!debugfs_create_bool("use_global_lock", 0444,
> > > dev_dir,
> > > - (u32 *)&first_ec->global_lock))
> > > + &first_ec->global_lock))
> >
> > if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> > &val))
> >
> > > goto error;
> >
> > first_ec->global_lock = val;
> >
> > And then you can turn val into bool just fine without changing the
> > structure
> > definition.
Ok, then, but that means Rafael is completely wrong ...
debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
it can't be on the stack. You also don't get a call when it changes.
If you cannot change the struct definition then you must implement a
debugfs file with its own read/write handlers.
johannes
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:52 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 18:52 UTC (permalink / raw)
To: Johannes Berg
Cc: Greg Kroah-Hartman, linaro-kernel, QCA ath9k Development,
Intel Linux Wireless, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
On 25-09-15, 20:49, Johannes Berg wrote:
> Ok, then, but that means Rafael is completely wrong ...
> debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> it can't be on the stack. You also don't get a call when it changes.
Ahh, ofcourse. My bad as well...
I think we can change structure definition but will wait for Rafael's
comment before that.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:52 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 18:52 UTC (permalink / raw)
To: Johannes Berg
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, QCA ath9k Development,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Intel Linux Wireless,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-edac-u79uwXL29TY76Z2rM5mHXA
On 25-09-15, 20:49, Johannes Berg wrote:
> Ok, then, but that means Rafael is completely wrong ...
> debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> it can't be on the stack. You also don't get a call when it changes.
Ahh, ofcourse. My bad as well...
I think we can change structure definition but will wait for Rafael's
comment before that.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:52 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 18:52 UTC (permalink / raw)
To: Johannes Berg
Cc: Greg Kroah-Hartman, linaro-kernel, QCA ath9k Development,
Intel Linux Wireless, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
On 25-09-15, 20:49, Johannes Berg wrote:
> Ok, then, but that means Rafael is completely wrong ...
> debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> it can't be on the stack. You also don't get a call when it changes.
Ahh, ofcourse. My bad as well...
I think we can change structure definition but will wait for Rafael's
comment before that.
--
viresh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 18:52 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 18:52 UTC (permalink / raw)
To: linux-arm-kernel
On 25-09-15, 20:49, Johannes Berg wrote:
> Ok, then, but that means Rafael is completely wrong ...
> debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> it can't be on the stack. You also don't get a call when it changes.
Ahh, ofcourse. My bad as well...
I think we can change structure definition but will wait for Rafael's
comment before that.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-25 16:41 ` Viresh Kumar
(?)
@ 2015-09-25 20:18 ` Rafael J. Wysocki
-1 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:18 UTC (permalink / raw)
To: Viresh Kumar, Greg Kroah-Hartman
Cc: linaro-kernel, QCA ath9k Development, Intel Linux Wireless,
linux-doc, linux-kernel, linux-arm-kernel, linux-acpi,
linux-bluetooth, iommu, netdev, linux-wireless, linux-scsi,
linux-usb, linux-edac, linux-mm, alsa-devel
On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems. There are no such platforms yet, but the
> code needs to be robust for such a case.
>
> Fix that by passing a local variable to debugfs_create_bool() and
> assigning its value to global_lock later.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Greg, please take this one if the [2/2] looks good to you.
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
> - Drop the stable tag
> - BCC'd a lot of people (rather than cc'ing them) to make sure
> - the series reaches them
> - mailing lists do not block the patchset due to long cc list
> - and we don't spam the BCC'd people for every reply
> ---
> drivers/acpi/ec_sys.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..b44b91331a56 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
> struct dentry *dev_dir;
> char name[64];
> umode_t mode = 0400;
> + u32 val;
>
> if (ec_device_count == 0) {
> acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
> @@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
>
> if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> goto error;
> - if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> - (u32 *)&first_ec->global_lock))
> + if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
> goto error;
>
> + first_ec->global_lock = val;
> +
> if (write_support)
> mode = 0600;
> if (!debugfs_create_file("io", mode, dev_dir, ec, &acpi_ec_io_ops))
>
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:18 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:18 UTC (permalink / raw)
To: Viresh Kumar, Greg Kroah-Hartman
Cc: linaro-kernel, QCA ath9k Development, Intel Linux Wireless,
linux-doc, linux-kernel, linux-arm-kernel, linux-acpi,
linux-bluetooth, iommu, netdev, linux-wireless, linux-scsi,
linux-usb, linux-edac, linux-mm, alsa-devel
On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems. There are no such platforms yet, but the
> code needs to be robust for such a case.
>
> Fix that by passing a local variable to debugfs_create_bool() and
> assigning its value to global_lock later.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Greg, please take this one if the [2/2] looks good to you.
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
> - Drop the stable tag
> - BCC'd a lot of people (rather than cc'ing them) to make sure
> - the series reaches them
> - mailing lists do not block the patchset due to long cc list
> - and we don't spam the BCC'd people for every reply
> ---
> drivers/acpi/ec_sys.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..b44b91331a56 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
> struct dentry *dev_dir;
> char name[64];
> umode_t mode = 0400;
> + u32 val;
>
> if (ec_device_count == 0) {
> acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
> @@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
>
> if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> goto error;
> - if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> - (u32 *)&first_ec->global_lock))
> + if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
> goto error;
>
> + first_ec->global_lock = val;
> +
> if (write_support)
> mode = 0600;
> if (!debugfs_create_file("io", mode, dev_dir, ec, &acpi_ec_io_ops))
>
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:18 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:18 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems. There are no such platforms yet, but the
> code needs to be robust for such a case.
>
> Fix that by passing a local variable to debugfs_create_bool() and
> assigning its value to global_lock later.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Greg, please take this one if the [2/2] looks good to you.
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
> - Drop the stable tag
> - BCC'd a lot of people (rather than cc'ing them) to make sure
> - the series reaches them
> - mailing lists do not block the patchset due to long cc list
> - and we don't spam the BCC'd people for every reply
> ---
> drivers/acpi/ec_sys.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..b44b91331a56 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
> struct dentry *dev_dir;
> char name[64];
> umode_t mode = 0400;
> + u32 val;
>
> if (ec_device_count == 0) {
> acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
> @@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec, unsigned int ec_device_count)
>
> if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32 *)&first_ec->gpe))
> goto error;
> - if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> - (u32 *)&first_ec->global_lock))
> + if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
> goto error;
>
> + first_ec->global_lock = val;
> +
> if (write_support)
> mode = 0600;
> if (!debugfs_create_file("io", mode, dev_dir, ec, &acpi_ec_io_ops))
>
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-25 20:18 ` Rafael J. Wysocki
(?)
@ 2015-09-25 20:22 ` Rafael J. Wysocki
-1 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:22 UTC (permalink / raw)
To: Viresh Kumar
Cc: Greg Kroah-Hartman, linaro-kernel, QCA ath9k Development,
Intel Linux Wireless, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
On Friday, September 25, 2015 10:18:13 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64 bit systems. There are no such platforms yet, but the
> > code needs to be robust for such a case.
> >
> > Fix that by passing a local variable to debugfs_create_bool() and
> > assigning its value to global_lock later.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Greg, please take this one if the [2/2] looks good to you.
Ouch, turns out it was a bad idea. Please scratch that.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:22 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:22 UTC (permalink / raw)
To: Viresh Kumar
Cc: Greg Kroah-Hartman, linaro-kernel, QCA ath9k Development,
Intel Linux Wireless, linux-doc, linux-kernel, linux-arm-kernel,
linux-acpi, linux-bluetooth, iommu, netdev, linux-wireless,
linux-scsi, linux-usb, linux-edac, linux-mm, alsa-devel
On Friday, September 25, 2015 10:18:13 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64 bit systems. There are no such platforms yet, but the
> > code needs to be robust for such a case.
> >
> > Fix that by passing a local variable to debugfs_create_bool() and
> > assigning its value to global_lock later.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Greg, please take this one if the [2/2] looks good to you.
Ouch, turns out it was a bad idea. Please scratch that.
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:22 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:22 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, September 25, 2015 10:18:13 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> > for big endian 64 bit systems. There are no such platforms yet, but the
> > code needs to be robust for such a case.
> >
> > Fix that by passing a local variable to debugfs_create_bool() and
> > assigning its value to global_lock later.
> >
> > Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Greg, please take this one if the [2/2] looks good to you.
Ouch, turns out it was a bad idea. Please scratch that.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-25 20:33 ` Rafael J. Wysocki
` (3 preceding siblings ...)
(?)
@ 2015-09-25 20:25 ` Viresh Kumar
-1 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 20:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> You're going to change that into bool in the next patch, right?
Yeah.
> So what if bool is a byte and the field is not word-aligned
Its between two 'unsigned long' variables today, and the struct isn't packed.
So, it will be aligned, isn't it?
> and changing
> that byte requires a read-modify-write. How do we ensure that things remain
> consistent in that case?
I didn't understood why a read-modify-write is special here? That's
what will happen
to most of the non-word-sized fields anyway?
Probably I didn't understood what you meant..
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:25 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 20:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:
On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> You're going to change that into bool in the next patch, right?
Yeah.
> So what if bool is a byte and the field is not word-aligned
Its between two 'unsigned long' variables today, and the struct isn't packed.
So, it will be aligned, isn't it?
> and changing
> that byte requires a read-modify-write. How do we ensure that things remain
> consistent in that case?
I didn't understood why a read-modify-write is special here? That's
what will happen
to most of the non-word-sized fields anyway?
Probably I didn't understood what you meant..
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:25 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 20:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> You're going to change that into bool in the next patch, right?
Yeah.
> So what if bool is a byte and the field is not word-aligned
Its between two 'unsigned long' variables today, and the struct isn't packed.
So, it will be aligned, isn't it?
> and changing
> that byte requires a read-modify-write. How do we ensure that things remain
> consistent in that case?
I didn't understood why a read-modify-write is special here? That's
what will happen
to most of the non-word-sized fields anyway?
Probably I didn't understood what you meant..
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:25 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 20:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:
On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> You're going to change that into bool in the next patch, right?
Yeah.
> So what if bool is a byte and the field is not word-aligned
Its between two 'unsigned long' variables today, and the struct isn't packed.
So, it will be aligned, isn't it?
> and changing
> that byte requires a read-modify-write. How do we ensure that things remain
> consistent in that case?
I didn't understood why a read-modify-write is special here? That's
what will happen
to most of the non-word-sized fields anyway?
Probably I didn't understood what you meant..
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:25 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 20:25 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> You're going to change that into bool in the next patch, right?
Yeah.
> So what if bool is a byte and the field is not word-aligned
Its between two 'unsigned long' variables today, and the struct isn't packed.
So, it will be aligned, isn't it?
> and changing
> that byte requires a read-modify-write. How do we ensure that things remain
> consistent in that case?
I didn't understood why a read-modify-write is special here? That's
what will happen
to most of the non-word-sized fields anyway?
Probably I didn't understood what you meant..
--
viresh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:25 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 20:25 UTC (permalink / raw)
To: linux-arm-kernel
On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> You're going to change that into bool in the next patch, right?
Yeah.
> So what if bool is a byte and the field is not word-aligned
Its between two 'unsigned long' variables today, and the struct isn't packed.
So, it will be aligned, isn't it?
> and changing
> that byte requires a read-modify-write. How do we ensure that things remain
> consistent in that case?
I didn't understood why a read-modify-write is special here? That's
what will happen
to most of the non-word-sized fields anyway?
Probably I didn't understood what you meant..
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-25 18:52 ` Viresh Kumar
(?)
@ 2015-09-25 20:26 ` Rafael J. Wysocki
-1 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:26 UTC (permalink / raw)
To: Viresh Kumar
Cc: Johannes Berg, Greg Kroah-Hartman, linaro-kernel,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
linux-kernel, linux-arm-kernel, linux-acpi, linux-bluetooth,
iommu, netdev, linux-wireless, linux-scsi, linux-usb, linux-edac,
linux-mm, alsa-devel
On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> On 25-09-15, 20:49, Johannes Berg wrote:
> > Ok, then, but that means Rafael is completely wrong ...
> > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > it can't be on the stack. You also don't get a call when it changes.
>
> Ahh, ofcourse. My bad as well...
Well, sorry about the wrong suggestion.
> I think we can change structure definition but will wait for Rafael's
> comment before that.
OK, change the structure then.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:26 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:26 UTC (permalink / raw)
To: Viresh Kumar
Cc: Johannes Berg, Greg Kroah-Hartman, linaro-kernel,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
linux-kernel, linux-arm-kernel, linux-acpi, linux-bluetooth,
iommu, netdev, linux-wireless, linux-scsi, linux-usb, linux-edac,
linux-mm, alsa-devel
On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> On 25-09-15, 20:49, Johannes Berg wrote:
> > Ok, then, but that means Rafael is completely wrong ...
> > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > it can't be on the stack. You also don't get a call when it changes.
>
> Ahh, ofcourse. My bad as well...
Well, sorry about the wrong suggestion.
> I think we can change structure definition but will wait for Rafael's
> comment before that.
OK, change the structure then.
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:26 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:26 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> On 25-09-15, 20:49, Johannes Berg wrote:
> > Ok, then, but that means Rafael is completely wrong ...
> > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > it can't be on the stack. You also don't get a call when it changes.
>
> Ahh, ofcourse. My bad as well...
Well, sorry about the wrong suggestion.
> I think we can change structure definition but will wait for Rafael's
> comment before that.
OK, change the structure then.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:33 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:33 UTC (permalink / raw)
To: Viresh Kumar
Cc: Johannes Berg, Greg Kroah-Hartman, linaro-kernel,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
linux-kernel, linux-arm-kernel, linux-acpi, linux-bluetooth,
iommu, netdev, linux-wireless, linux-scsi, linux-usb, linux-edac,
linux-mm, alsa-devel
On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> > On 25-09-15, 20:49, Johannes Berg wrote:
> > > Ok, then, but that means Rafael is completely wrong ...
> > > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > > it can't be on the stack. You also don't get a call when it changes.
> >
> > Ahh, ofcourse. My bad as well...
>
> Well, sorry about the wrong suggestion.
>
> > I think we can change structure definition but will wait for Rafael's
> > comment before that.
>
> OK, change the structure then.
But here's a question.
You're going to change that into bool in the next patch, right?
So what if bool is a byte and the field is not word-aligned and changing
that byte requires a read-modify-write. How do we ensure that things remain
consistent in that case?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:33 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:33 UTC (permalink / raw)
To: Viresh Kumar
Cc: alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, QCA ath9k Development,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Intel Linux Wireless,
linux-acpi-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Johannes Berg,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-edac-u79uwXL29TY76Z2rM5mHXA
On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> > On 25-09-15, 20:49, Johannes Berg wrote:
> > > Ok, then, but that means Rafael is completely wrong ...
> > > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > > it can't be on the stack. You also don't get a call when it changes.
> >
> > Ahh, ofcourse. My bad as well...
>
> Well, sorry about the wrong suggestion.
>
> > I think we can change structure definition but will wait for Rafael's
> > comment before that.
>
> OK, change the structure then.
But here's a question.
You're going to change that into bool in the next patch, right?
So what if bool is a byte and the field is not word-aligned and changing
that byte requires a read-modify-write. How do we ensure that things remain
consistent in that case?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:33 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:33 UTC (permalink / raw)
To: Viresh Kumar
Cc: Johannes Berg, Greg Kroah-Hartman, linaro-kernel,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
linux-kernel, linux-arm-kernel, linux-acpi, linux-bluetooth,
iommu, netdev, linux-wireless, linux-scsi, linux-usb, linux-edac,
linux-mm, alsa-devel
On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> > On 25-09-15, 20:49, Johannes Berg wrote:
> > > Ok, then, but that means Rafael is completely wrong ...
> > > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > > it can't be on the stack. You also don't get a call when it changes.
> >
> > Ahh, ofcourse. My bad as well...
>
> Well, sorry about the wrong suggestion.
>
> > I think we can change structure definition but will wait for Rafael's
> > comment before that.
>
> OK, change the structure then.
But here's a question.
You're going to change that into bool in the next patch, right?
So what if bool is a byte and the field is not word-aligned and changing
that byte requires a read-modify-write. How do we ensure that things remain
consistent in that case?
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:33 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:33 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> > On 25-09-15, 20:49, Johannes Berg wrote:
> > > Ok, then, but that means Rafael is completely wrong ...
> > > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > > it can't be on the stack. You also don't get a call when it changes.
> >
> > Ahh, ofcourse. My bad as well...
>
> Well, sorry about the wrong suggestion.
>
> > I think we can change structure definition but will wait for Rafael's
> > comment before that.
>
> OK, change the structure then.
But here's a question.
You're going to change that into bool in the next patch, right?
So what if bool is a byte and the field is not word-aligned and changing
that byte requires a read-modify-write. How do we ensure that things remain
consistent in that case?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:58 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:58 UTC (permalink / raw)
To: Viresh Kumar
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > You're going to change that into bool in the next patch, right?
>
> Yeah.
>
> > So what if bool is a byte and the field is not word-aligned
>
> Its between two 'unsigned long' variables today, and the struct isn't packed.
> So, it will be aligned, isn't it?
>
> > and changing
> > that byte requires a read-modify-write. How do we ensure that things remain
> > consistent in that case?
>
> I didn't understood why a read-modify-write is special here? That's
> what will happen
> to most of the non-word-sized fields anyway?
>
> Probably I didn't understood what you meant..
Say you have three adjacent fields in a structure, x, y, z, each one byte long.
Initially, all of them are equal to 0.
CPU A writes 1 to x and CPU B writes 2 to y at the same time.
What's the result?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:58 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:58 UTC (permalink / raw)
To: Viresh Kumar
Cc: moder ated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev-u79uwXL29TY76Z2rM5mHXA,
Johannes Berg
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > You're going to change that into bool in the next patch, right?
>
> Yeah.
>
> > So what if bool is a byte and the field is not word-aligned
>
> Its between two 'unsigned long' variables today, and the struct isn't packed.
> So, it will be aligned, isn't it?
>
> > and changing
> > that byte requires a read-modify-write. How do we ensure that things remain
> > consistent in that case?
>
> I didn't understood why a read-modify-write is special here? That's
> what will happen
> to most of the non-word-sized fields anyway?
>
> Probably I didn't understood what you meant..
Say you have three adjacent fields in a structure, x, y, z, each one byte long.
Initially, all of them are equal to 0.
CPU A writes 1 to x and CPU B writes 2 to y at the same time.
What's the result?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:58 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:58 UTC (permalink / raw)
To: Viresh Kumar
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > You're going to change that into bool in the next patch, right?
>
> Yeah.
>
> > So what if bool is a byte and the field is not word-aligned
>
> Its between two 'unsigned long' variables today, and the struct isn't packed.
> So, it will be aligned, isn't it?
>
> > and changing
> > that byte requires a read-modify-write. How do we ensure that things remain
> > consistent in that case?
>
> I didn't understood why a read-modify-write is special here? That's
> what will happen
> to most of the non-word-sized fields anyway?
>
> Probably I didn't understood what you meant..
Say you have three adjacent fields in a structure, x, y, z, each one byte long.
Initially, all of them are equal to 0.
CPU A writes 1 to x and CPU B writes 2 to y at the same time.
What's the result?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:58 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:58 UTC (permalink / raw)
To: Viresh Kumar
Cc: moder ated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER
MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev-u79uwXL29TY76Z2rM5mHXA,
Johannes Berg
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > You're going to change that into bool in the next patch, right?
>
> Yeah.
>
> > So what if bool is a byte and the field is not word-aligned
>
> Its between two 'unsigned long' variables today, and the struct isn't packed.
> So, it will be aligned, isn't it?
>
> > and changing
> > that byte requires a read-modify-write. How do we ensure that things remain
> > consistent in that case?
>
> I didn't understood why a read-modify-write is special here? That's
> what will happen
> to most of the non-word-sized fields anyway?
>
> Probably I didn't understood what you meant..
Say you have three adjacent fields in a structure, x, y, z, each one byte long.
Initially, all of them are equal to 0.
CPU A writes 1 to x and CPU B writes 2 to y at the same time.
What's the result?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:58 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:58 UTC (permalink / raw)
To: Viresh Kumar
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > You're going to change that into bool in the next patch, right?
>
> Yeah.
>
> > So what if bool is a byte and the field is not word-aligned
>
> Its between two 'unsigned long' variables today, and the struct isn't packed.
> So, it will be aligned, isn't it?
>
> > and changing
> > that byte requires a read-modify-write. How do we ensure that things remain
> > consistent in that case?
>
> I didn't understood why a read-modify-write is special here? That's
> what will happen
> to most of the non-word-sized fields anyway?
>
> Probably I didn't understood what you meant..
Say you have three adjacent fields in a structure, x, y, z, each one byte long.
Initially, all of them are equal to 0.
CPU A writes 1 to x and CPU B writes 2 to y at the same time.
What's the result?
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 20:58 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 20:58 UTC (permalink / raw)
To: linux-arm-kernel
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > You're going to change that into bool in the next patch, right?
>
> Yeah.
>
> > So what if bool is a byte and the field is not word-aligned
>
> Its between two 'unsigned long' variables today, and the struct isn't packed.
> So, it will be aligned, isn't it?
>
> > and changing
> > that byte requires a read-modify-write. How do we ensure that things remain
> > consistent in that case?
>
> I didn't understood why a read-modify-write is special here? That's
> what will happen
> to most of the non-word-sized fields anyway?
>
> Probably I didn't understood what you meant..
Say you have three adjacent fields in a structure, x, y, z, each one byte long.
Initially, all of them are equal to 0.
CPU A writes 1 to x and CPU B writes 2 to y at the same time.
What's the result?
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-25 20:58 ` Rafael J. Wysocki
` (3 preceding siblings ...)
(?)
@ 2015-09-25 21:44 ` Viresh Kumar
-1 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 21:44 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25-09-15, 22:58, Rafael J. Wysocki wrote:
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
But then two CPUs can update the same variable as well, and we must
have proper locking in place to fix that.
Anyway, that problem isn't here for sure as its between two
unsigned-longs. So, should I just move it to bool and resend ?
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 21:44 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 21:44 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:
On 25-09-15, 22:58, Rafael J. Wysocki wrote:
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
But then two CPUs can update the same variable as well, and we must
have proper locking in place to fix that.
Anyway, that problem isn't here for sure as its between two
unsigned-longs. So, should I just move it to bool and resend ?
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 21:44 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 21:44 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25-09-15, 22:58, Rafael J. Wysocki wrote:
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
But then two CPUs can update the same variable as well, and we must
have proper locking in place to fix that.
Anyway, that problem isn't here for sure as its between two
unsigned-longs. So, should I just move it to bool and resend ?
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 21:44 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 21:44 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:
On 25-09-15, 22:58, Rafael J. Wysocki wrote:
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
But then two CPUs can update the same variable as well, and we must
have proper locking in place to fix that.
Anyway, that problem isn't here for sure as its between two
unsigned-longs. So, should I just move it to bool and resend ?
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 21:44 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 21:44 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Johannes Berg, Greg Kroah-Hartman, Linaro Kernel Mailman List,
QCA ath9k Development, Intel Linux Wireless, linux-doc,
Linux Kernel Mailing List, linux-arm-kernel, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25-09-15, 22:58, Rafael J. Wysocki wrote:
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
But then two CPUs can update the same variable as well, and we must
have proper locking in place to fix that.
Anyway, that problem isn't here for sure as its between two
unsigned-longs. So, should I just move it to bool and resend ?
--
viresh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 21:44 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-25 21:44 UTC (permalink / raw)
To: linux-arm-kernel
On 25-09-15, 22:58, Rafael J. Wysocki wrote:
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
But then two CPUs can update the same variable as well, and we must
have proper locking in place to fix that.
Anyway, that problem isn't here for sure as its between two
unsigned-longs. So, should I just move it to bool and resend ?
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-25 21:44 ` Viresh Kumar
` (2 preceding siblings ...)
(?)
@ 2015-09-25 22:19 ` Rafael J. Wysocki
-1 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 22:19 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 25-09-15, 22:58, Rafael J. Wysocki wrote:
>> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
>> Initially, all of them are equal to 0.
>>
>> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>>
>> What's the result?
>
> But then two CPUs can update the same variable as well, and we must
> have proper locking in place to fix that.
Right.
So if you allow something like debugfs to update your structure, how
do you make sure there is the proper locking?
Is that not a problem in all of the places modified by the [2/2]?
How can the future users of the API know what to do to avoid potential
problems with it?
>
> Anyway, that problem isn't here for sure as its between two
> unsigned-longs. So, should I just move it to bool and resend ?
I guess it might be more convenient to fold this into the other patch,
because we seem to be splitting hairs here.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 22:19 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 22:19 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM, ULTRA-WIDEBAND
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 25-09-15, 22:58, Rafael J. Wysocki wrote:
>> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
>> Initially, all of them are equal to 0.
>>
>> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>>
>> What's the result?
>
> But then two CPUs can update the same variable as well, and we must
> have proper locking in place to fix that.
Right.
So if you allow something like debugfs to update your structure, how
do you make sure there is the proper locking?
Is that not a problem in all of the places modified by the [2/2]?
How can the future users of the API know what to do to avoid potential
problems with it?
>
> Anyway, that problem isn't here for sure as its between two
> unsigned-longs. So, should I just move it to bool and resend ?
I guess it might be more convenient to fold this into the other patch,
because we seem to be splitting hairs here.
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 22:19 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 22:19 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 25-09-15, 22:58, Rafael J. Wysocki wrote:
>> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
>> Initially, all of them are equal to 0.
>>
>> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>>
>> What's the result?
>
> But then two CPUs can update the same variable as well, and we must
> have proper locking in place to fix that.
Right.
So if you allow something like debugfs to update your structure, how
do you make sure there is the proper locking?
Is that not a problem in all of the places modified by the [2/2]?
How can the future users of the API know what to do to avoid potential
problems with it?
>
> Anyway, that problem isn't here for sure as its between two
> unsigned-longs. So, should I just move it to bool and resend ?
I guess it might be more convenient to fold this into the other patch,
because we seem to be splitting hairs here.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 22:19 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 22:19 UTC (permalink / raw)
To: Viresh Kumar
Cc: Rafael J. Wysocki, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 25-09-15, 22:58, Rafael J. Wysocki wrote:
>> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
>> Initially, all of them are equal to 0.
>>
>> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>>
>> What's the result?
>
> But then two CPUs can update the same variable as well, and we must
> have proper locking in place to fix that.
Right.
So if you allow something like debugfs to update your structure, how
do you make sure there is the proper locking?
Is that not a problem in all of the places modified by the [2/2]?
How can the future users of the API know what to do to avoid potential
problems with it?
>
> Anyway, that problem isn't here for sure as its between two
> unsigned-longs. So, should I just move it to bool and resend ?
I guess it might be more convenient to fold this into the other patch,
because we seem to be splitting hairs here.
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-25 22:19 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-25 22:19 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 25-09-15, 22:58, Rafael J. Wysocki wrote:
>> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
>> Initially, all of them are equal to 0.
>>
>> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>>
>> What's the result?
>
> But then two CPUs can update the same variable as well, and we must
> have proper locking in place to fix that.
Right.
So if you allow something like debugfs to update your structure, how
do you make sure there is the proper locking?
Is that not a problem in all of the places modified by the [2/2]?
How can the future users of the API know what to do to avoid potential
problems with it?
>
> Anyway, that problem isn't here for sure as its between two
> unsigned-longs. So, should I just move it to bool and resend ?
I guess it might be more convenient to fold this into the other patch,
because we seem to be splitting hairs here.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 18:40 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-26 18:40 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> So if you allow something like debugfs to update your structure, how
> do you make sure there is the proper locking?
Not really sure at all.. Isn't there some debugfs locking that will
jump in, to avoid updation of fields to the same device?
> Is that not a problem in all of the places modified by the [2/2]?
Right, but its not new AFAICT.
We already have u32 fields in those structs and on 64 bit machines
we have the same read-update-write problems for two consecutive
u32's. Right?
> How can the future users of the API know what to do to avoid potential
> problems with it?
No idea really :)
>> Anyway, that problem isn't here for sure as its between two
>> unsigned-longs. So, should I just move it to bool and resend ?
>
> I guess it might be more convenient to fold this into the other patch,
> because we seem to be splitting hairs here.
I can and that's what I did. But then Arnd asked me to separate it
out. I can fold it back if that's what you want.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 18:40 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-26 18:40 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Rafael J. Wysocki, QCA ath9k Development,
Linux Kernel Mailing List, Intel Linux Wireless, Linux ACPI,
open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> So if you allow something like debugfs to update your structure, how
> do you make sure there is the proper locking?
Not really sure at all.. Isn't there some debugfs locking that will
jump in, to avoid updation of fields to the same device?
> Is that not a problem in all of the places modified by the [2/2]?
Right, but its not new AFAICT.
We already have u32 fields in those structs and on 64 bit machines
we have the same read-update-write problems for two consecutive
u32's. Right?
> How can the future users of the API know what to do to avoid potential
> problems with it?
No idea really :)
>> Anyway, that problem isn't here for sure as its between two
>> unsigned-longs. So, should I just move it to bool and resend ?
>
> I guess it might be more convenient to fold this into the other patch,
> because we seem to be splitting hairs here.
I can and that's what I did. But then Arnd asked me to separate it
out. I can fold it back if that's what you want.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 18:40 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-26 18:40 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> So if you allow something like debugfs to update your structure, how
> do you make sure there is the proper locking?
Not really sure at all.. Isn't there some debugfs locking that will
jump in, to avoid updation of fields to the same device?
> Is that not a problem in all of the places modified by the [2/2]?
Right, but its not new AFAICT.
We already have u32 fields in those structs and on 64 bit machines
we have the same read-update-write problems for two consecutive
u32's. Right?
> How can the future users of the API know what to do to avoid potential
> problems with it?
No idea really :)
>> Anyway, that problem isn't here for sure as its between two
>> unsigned-longs. So, should I just move it to bool and resend ?
>
> I guess it might be more convenient to fold this into the other patch,
> because we seem to be splitting hairs here.
I can and that's what I did. But then Arnd asked me to separate it
out. I can fold it back if that's what you want.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 18:40 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-26 18:40 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Rafael J. Wysocki, QCA ath9k Development,
Linux Kernel Mailing List, Intel Linux Wireless, Linux ACPI,
open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> So if you allow something like debugfs to update your structure, how
> do you make sure there is the proper locking?
Not really sure at all.. Isn't there some debugfs locking that will
jump in, to avoid updation of fields to the same device?
> Is that not a problem in all of the places modified by the [2/2]?
Right, but its not new AFAICT.
We already have u32 fields in those structs and on 64 bit machines
we have the same read-update-write problems for two consecutive
u32's. Right?
> How can the future users of the API know what to do to avoid potential
> problems with it?
No idea really :)
>> Anyway, that problem isn't here for sure as its between two
>> unsigned-longs. So, should I just move it to bool and resend ?
>
> I guess it might be more convenient to fold this into the other patch,
> because we seem to be splitting hairs here.
I can and that's what I did. But then Arnd asked me to separate it
out. I can fold it back if that's what you want.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 18:40 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-26 18:40 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Rafael J. Wysocki, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> So if you allow something like debugfs to update your structure, how
> do you make sure there is the proper locking?
Not really sure at all.. Isn't there some debugfs locking that will
jump in, to avoid updation of fields to the same device?
> Is that not a problem in all of the places modified by the [2/2]?
Right, but its not new AFAICT.
We already have u32 fields in those structs and on 64 bit machines
we have the same read-update-write problems for two consecutive
u32's. Right?
> How can the future users of the API know what to do to avoid potential
> problems with it?
No idea really :)
>> Anyway, that problem isn't here for sure as its between two
>> unsigned-longs. So, should I just move it to bool and resend ?
>
> I guess it might be more convenient to fold this into the other patch,
> because we seem to be splitting hairs here.
I can and that's what I did. But then Arnd asked me to separate it
out. I can fold it back if that's what you want.
--
viresh
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 18:40 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-26 18:40 UTC (permalink / raw)
To: linux-arm-kernel
On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> So if you allow something like debugfs to update your structure, how
> do you make sure there is the proper locking?
Not really sure at all.. Isn't there some debugfs locking that will
jump in, to avoid updation of fields to the same device?
> Is that not a problem in all of the places modified by the [2/2]?
Right, but its not new AFAICT.
We already have u32 fields in those structs and on 64 bit machines
we have the same read-update-write problems for two consecutive
u32's. Right?
> How can the future users of the API know what to do to avoid potential
> problems with it?
No idea really :)
>> Anyway, that problem isn't here for sure as its between two
>> unsigned-longs. So, should I just move it to bool and resend ?
>
> I guess it might be more convenient to fold this into the other patch,
> because we seem to be splitting hairs here.
I can and that's what I did. But then Arnd asked me to separate it
out. I can fold it back if that's what you want.
--
viresh
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-26 18:40 ` Viresh Kumar
` (2 preceding siblings ...)
(?)
@ 2015-09-26 19:33 ` Arnd Bergmann
-1 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-26 19:33 UTC (permalink / raw)
To: linaro-kernel
Cc: Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Rafael J. Wysocki, QCA ath9k Development,
Linux Kernel Mailing List, Intel Linux Wireless, Linux ACPI,
open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev, Johannes Berg,
Linux Memory Management List, linux-arm-kernel,
open list:EDAC-CORE
On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > So if you allow something like debugfs to update your structure, how
> > do you make sure there is the proper locking?
>
> Not really sure at all.. Isn't there some debugfs locking that will
> jump in, to avoid updation of fields to the same device?
No, if you need any locking to access variable, you cannot use the
simple debugfs helpers but have to provide your own functions.
> >> Anyway, that problem isn't here for sure as its between two
> >> unsigned-longs. So, should I just move it to bool and resend ?
> >
> > I guess it might be more convenient to fold this into the other patch,
> > because we seem to be splitting hairs here.
>
> I can and that's what I did. But then Arnd asked me to separate it
> out. I can fold it back if that's what you want.
It still makes sense to keep it separate I think, the patch is clearly
different from the other parts.
Arnd
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:33 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-26 19:33 UTC (permalink / raw)
To: linaro-kernel
Cc: Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Rafael J. Wysocki, QCA ath9k Development,
Linux Kernel Mailing List, Intel Linux Wireless, Linux ACPI,
open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev
On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > So if you allow something like debugfs to update your structure, how
> > do you make sure there is the proper locking?
>
> Not really sure at all.. Isn't there some debugfs locking that will
> jump in, to avoid updation of fields to the same device?
No, if you need any locking to access variable, you cannot use the
simple debugfs helpers but have to provide your own functions.
> >> Anyway, that problem isn't here for sure as its between two
> >> unsigned-longs. So, should I just move it to bool and resend ?
> >
> > I guess it might be more convenient to fold this into the other patch,
> > because we seem to be splitting hairs here.
>
> I can and that's what I did. But then Arnd asked me to separate it
> out. I can fold it back if that's what you want.
It still makes sense to keep it separate I think, the patch is clearly
different from the other parts.
Arnd
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:33 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-26 19:33 UTC (permalink / raw)
To: linaro-kernel
Cc: Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Rafael J. Wysocki, QCA ath9k Development,
Linux Kernel Mailing List, Intel Linux Wireless, Linux ACPI,
open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev, Johannes Berg,
Linux Memory Management List, linux-arm-kernel,
open list:EDAC-CORE
On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > So if you allow something like debugfs to update your structure, how
> > do you make sure there is the proper locking?
>
> Not really sure at all.. Isn't there some debugfs locking that will
> jump in, to avoid updation of fields to the same device?
No, if you need any locking to access variable, you cannot use the
simple debugfs helpers but have to provide your own functions.
> >> Anyway, that problem isn't here for sure as its between two
> >> unsigned-longs. So, should I just move it to bool and resend ?
> >
> > I guess it might be more convenient to fold this into the other patch,
> > because we seem to be splitting hairs here.
>
> I can and that's what I did. But then Arnd asked me to separate it
> out. I can fold it back if that's what you want.
It still makes sense to keep it separate I think, the patch is clearly
different from the other parts.
Arnd
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:33 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-26 19:33 UTC (permalink / raw)
To: linaro-kernel
Cc: Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Rafael J. Wysocki, QCA ath9k Development,
Linux Kernel Mailing List, Intel Linux Wireless, Linux ACPI,
open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev, Johannes Berg,
Linux Memory Management List, linux-arm-kernel,
open list:EDAC-CORE
On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > So if you allow something like debugfs to update your structure, how
> > do you make sure there is the proper locking?
>
> Not really sure at all.. Isn't there some debugfs locking that will
> jump in, to avoid updation of fields to the same device?
No, if you need any locking to access variable, you cannot use the
simple debugfs helpers but have to provide your own functions.
> >> Anyway, that problem isn't here for sure as its between two
> >> unsigned-longs. So, should I just move it to bool and resend ?
> >
> > I guess it might be more convenient to fold this into the other patch,
> > because we seem to be splitting hairs here.
>
> I can and that's what I did. But then Arnd asked me to separate it
> out. I can fold it back if that's what you want.
It still makes sense to keep it separate I think, the patch is clearly
different from the other parts.
Arnd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:33 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-26 19:33 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > So if you allow something like debugfs to update your structure, how
> > do you make sure there is the proper locking?
>
> Not really sure at all.. Isn't there some debugfs locking that will
> jump in, to avoid updation of fields to the same device?
No, if you need any locking to access variable, you cannot use the
simple debugfs helpers but have to provide your own functions.
> >> Anyway, that problem isn't here for sure as its between two
> >> unsigned-longs. So, should I just move it to bool and resend ?
> >
> > I guess it might be more convenient to fold this into the other patch,
> > because we seem to be splitting hairs here.
>
> I can and that's what I did. But then Arnd asked me to separate it
> out. I can fold it back if that's what you want.
It still makes sense to keep it separate I think, the patch is clearly
different from the other parts.
Arnd
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:52 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-26 19:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > You're going to change that into bool in the next patch, right?
> >
> > Yeah.
> >
> > > So what if bool is a byte and the field is not word-aligned
> >
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> >
> > > and changing
> > > that byte requires a read-modify-write. How do we ensure that things remain
> > > consistent in that case?
> >
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> >
> > Probably I didn't understood what you meant..
>
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
I think every CPU's cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2. If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed). However, it was such a
problem that even the later alpha chips had byte extensions.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:52 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-26 19:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Viresh Kumar,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, Linux Memory Management List,
Greg Kroah-Hartman
On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > > You're going to change that into bool in the next patch, right?
> >
> > Yeah.
> >
> > > So what if bool is a byte and the field is not word-aligned
> >
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> >
> > > and changing
> > > that byte requires a read-modify-write. How do we ensure that things remain
> > > consistent in that case?
> >
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> >
> > Probably I didn't understood what you meant..
>
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
I think every CPU's cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2. If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed). However, it was such a
problem that even the later alpha chips had byte extensions.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:52 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-26 19:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > You're going to change that into bool in the next patch, right?
> >
> > Yeah.
> >
> > > So what if bool is a byte and the field is not word-aligned
> >
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> >
> > > and changing
> > > that byte requires a read-modify-write. How do we ensure that things remain
> > > consistent in that case?
> >
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> >
> > Probably I didn't understood what you meant..
>
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
I think every CPU's cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2. If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed). However, it was such a
problem that even the later alpha chips had byte extensions.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:52 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-26 19:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Viresh Kumar,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, Linux Memory Management List,
Greg Kroah-Hartman
On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org> wrote:
> > > You're going to change that into bool in the next patch, right?
> >
> > Yeah.
> >
> > > So what if bool is a byte and the field is not word-aligned
> >
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> >
> > > and changing
> > > that byte requires a read-modify-write. How do we ensure that things remain
> > > consistent in that case?
> >
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> >
> > Probably I didn't understood what you meant..
>
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
I think every CPU's cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2. If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed). However, it was such a
problem that even the later alpha chips had byte extensions.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:52 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-26 19:52 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > You're going to change that into bool in the next patch, right?
> >
> > Yeah.
> >
> > > So what if bool is a byte and the field is not word-aligned
> >
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> >
> > > and changing
> > > that byte requires a read-modify-write. How do we ensure that things remain
> > > consistent in that case?
> >
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> >
> > Probably I didn't understood what you meant..
>
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
I think every CPU's cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2. If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed). However, it was such a
problem that even the later alpha chips had byte extensions.
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-26 19:52 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-26 19:52 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > You're going to change that into bool in the next patch, right?
> >
> > Yeah.
> >
> > > So what if bool is a byte and the field is not word-aligned
> >
> > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > So, it will be aligned, isn't it?
> >
> > > and changing
> > > that byte requires a read-modify-write. How do we ensure that things remain
> > > consistent in that case?
> >
> > I didn't understood why a read-modify-write is special here? That's
> > what will happen
> > to most of the non-word-sized fields anyway?
> >
> > Probably I didn't understood what you meant..
>
> Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> Initially, all of them are equal to 0.
>
> CPU A writes 1 to x and CPU B writes 2 to y at the same time.
>
> What's the result?
I think every CPU's cache architecure guarantees adjacent store
integrity, even in the face of SMP, so it's x==1 and y==2. If you're
thinking of old alpha SMP system where the lowest store width is 32 bits
and thus you have to do RMW to update a byte, this was usually fixed by
padding (assuming the structure is not packed). However, it was such a
problem that even the later alpha chips had byte extensions.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-25 16:41 ` Viresh Kumar
` (5 preceding siblings ...)
(?)
@ 2015-09-27 5:31 ` Jiri Slaby
2015-09-27 14:35 ` Viresh Kumar
-1 siblings, 1 reply; 135+ messages in thread
From: Jiri Slaby @ 2015-09-27 5:31 UTC (permalink / raw)
To: Viresh Kumar
Cc: iommu, linux-acpi, linux-bluetooth, linux-scsi,
Intel Linux Wireless, alsa-devel, linux-usb, linaro-kernel,
linux-doc, linux-kernel, linux-edac, QCA ath9k Development,
linux-wireless, linux-mm, linux-arm-kernel, Greg Kroah-Hartman,
netdev
[-- Attachment #1: Type: text/plain, Size: 2262 bytes --]
Dne 25. 9. 2015 18:42 napsal uživatel "Viresh Kumar" <
viresh.kumar@linaro.org>:
>
> global_lock is defined as an unsigned long and accessing only its lower
> 32 bits from sysfs is incorrect, as we need to consider other 32 bits
> for big endian 64 bit systems. There are no such platforms yet, but the
> code needs to be robust for such a case.
>
> Fix that by passing a local variable to debugfs_create_bool() and
> assigning its value to global_lock later.
But this has to crash whenever the file is read as val's storage is gone at
that moment already, right?
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> V3->V4:
> - Create a local variable instead of changing type of global_lock
> (Rafael)
> - Drop the stable tag
> - BCC'd a lot of people (rather than cc'ing them) to make sure
> - the series reaches them
> - mailing lists do not block the patchset due to long cc list
> - and we don't spam the BCC'd people for every reply
> ---
> drivers/acpi/ec_sys.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/ec_sys.c b/drivers/acpi/ec_sys.c
> index b4c216bab22b..b44b91331a56 100644
> --- a/drivers/acpi/ec_sys.c
> +++ b/drivers/acpi/ec_sys.c
> @@ -110,6 +110,7 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec,
unsigned int ec_device_count)
> struct dentry *dev_dir;
> char name[64];
> umode_t mode = 0400;
> + u32 val;
>
> if (ec_device_count == 0) {
> acpi_ec_debugfs_dir = debugfs_create_dir("ec", NULL);
> @@ -127,10 +128,11 @@ static int acpi_ec_add_debugfs(struct acpi_ec *ec,
unsigned int ec_device_count)
>
> if (!debugfs_create_x32("gpe", 0444, dev_dir, (u32
*)&first_ec->gpe))
> goto error;
> - if (!debugfs_create_bool("use_global_lock", 0444, dev_dir,
> - (u32 *)&first_ec->global_lock))
> + if (!debugfs_create_bool("use_global_lock", 0444, dev_dir, &val))
> goto error;
>
> + first_ec->global_lock = val;
> +
> if (write_support)
> mode = 0600;
> if (!debugfs_create_file("io", mode, dev_dir, ec,
&acpi_ec_io_ops))
> --
> 2.4.0
>
[-- Attachment #2: Type: text/html, Size: 2975 bytes --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-26 19:52 ` James Bottomley
` (2 preceding siblings ...)
(?)
@ 2015-09-27 14:09 ` Rafael J. Wysocki
-1 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:09 UTC (permalink / raw)
To: James Bottomley
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Saturday, September 26, 2015 12:52:08 PM James Bottomley wrote:
> On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> > On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > You're going to change that into bool in the next patch, right?
> > >
> > > Yeah.
> > >
> > > > So what if bool is a byte and the field is not word-aligned
> > >
> > > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > > So, it will be aligned, isn't it?
> > >
> > > > and changing
> > > > that byte requires a read-modify-write. How do we ensure that things remain
> > > > consistent in that case?
> > >
> > > I didn't understood why a read-modify-write is special here? That's
> > > what will happen
> > > to most of the non-word-sized fields anyway?
> > >
> > > Probably I didn't understood what you meant..
> >
> > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > Initially, all of them are equal to 0.
> >
> > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> >
> > What's the result?
>
> I think every CPU's cache architecure guarantees adjacent store
> integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> thinking of old alpha SMP system where the lowest store width is 32 bits
> and thus you have to do RMW to update a byte, this was usually fixed by
> padding (assuming the structure is not packed). However, it was such a
> problem that even the later alpha chips had byte extensions.
OK, thanks!
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:09 UTC (permalink / raw)
To: James Bottomley
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM, UWB
On Saturday, September 26, 2015 12:52:08 PM James Bottomley wrote:
> On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> > On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > You're going to change that into bool in the next patch, right?
> > >
> > > Yeah.
> > >
> > > > So what if bool is a byte and the field is not word-aligned
> > >
> > > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > > So, it will be aligned, isn't it?
> > >
> > > > and changing
> > > > that byte requires a read-modify-write. How do we ensure that things remain
> > > > consistent in that case?
> > >
> > > I didn't understood why a read-modify-write is special here? That's
> > > what will happen
> > > to most of the non-word-sized fields anyway?
> > >
> > > Probably I didn't understood what you meant..
> >
> > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > Initially, all of them are equal to 0.
> >
> > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> >
> > What's the result?
>
> I think every CPU's cache architecure guarantees adjacent store
> integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> thinking of old alpha SMP system where the lowest store width is 32 bits
> and thus you have to do RMW to update a byte, this was usually fixed by
> padding (assuming the structure is not packed). However, it was such a
> problem that even the later alpha chips had byte extensions.
OK, thanks!
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:09 UTC (permalink / raw)
To: James Bottomley
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Saturday, September 26, 2015 12:52:08 PM James Bottomley wrote:
> On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> > On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > You're going to change that into bool in the next patch, right?
> > >
> > > Yeah.
> > >
> > > > So what if bool is a byte and the field is not word-aligned
> > >
> > > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > > So, it will be aligned, isn't it?
> > >
> > > > and changing
> > > > that byte requires a read-modify-write. How do we ensure that things remain
> > > > consistent in that case?
> > >
> > > I didn't understood why a read-modify-write is special here? That's
> > > what will happen
> > > to most of the non-word-sized fields anyway?
> > >
> > > Probably I didn't understood what you meant..
> >
> > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > Initially, all of them are equal to 0.
> >
> > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> >
> > What's the result?
>
> I think every CPU's cache architecure guarantees adjacent store
> integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> thinking of old alpha SMP system where the lowest store width is 32 bits
> and thus you have to do RMW to update a byte, this was usually fixed by
> padding (assuming the structure is not packed). However, it was such a
> problem that even the later alpha chips had byte extensions.
OK, thanks!
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:09 UTC (permalink / raw)
To: James Bottomley
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Saturday, September 26, 2015 12:52:08 PM James Bottomley wrote:
> On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> > On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > You're going to change that into bool in the next patch, right?
> > >
> > > Yeah.
> > >
> > > > So what if bool is a byte and the field is not word-aligned
> > >
> > > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > > So, it will be aligned, isn't it?
> > >
> > > > and changing
> > > > that byte requires a read-modify-write. How do we ensure that things remain
> > > > consistent in that case?
> > >
> > > I didn't understood why a read-modify-write is special here? That's
> > > what will happen
> > > to most of the non-word-sized fields anyway?
> > >
> > > Probably I didn't understood what you meant..
> >
> > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > Initially, all of them are equal to 0.
> >
> > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> >
> > What's the result?
>
> I think every CPU's cache architecure guarantees adjacent store
> integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> thinking of old alpha SMP system where the lowest store width is 32 bits
> and thus you have to do RMW to update a byte, this was usually fixed by
> padding (assuming the structure is not packed). However, it was such a
> problem that even the later alpha chips had byte extensions.
OK, thanks!
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:09 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:09 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday, September 26, 2015 12:52:08 PM James Bottomley wrote:
> On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> > On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > > On 25 September 2015 at 13:33, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > You're going to change that into bool in the next patch, right?
> > >
> > > Yeah.
> > >
> > > > So what if bool is a byte and the field is not word-aligned
> > >
> > > Its between two 'unsigned long' variables today, and the struct isn't packed.
> > > So, it will be aligned, isn't it?
> > >
> > > > and changing
> > > > that byte requires a read-modify-write. How do we ensure that things remain
> > > > consistent in that case?
> > >
> > > I didn't understood why a read-modify-write is special here? That's
> > > what will happen
> > > to most of the non-word-sized fields anyway?
> > >
> > > Probably I didn't understood what you meant..
> >
> > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > Initially, all of them are equal to 0.
> >
> > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> >
> > What's the result?
>
> I think every CPU's cache architecure guarantees adjacent store
> integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> thinking of old alpha SMP system where the lowest store width is 32 bits
> and thus you have to do RMW to update a byte, this was usually fixed by
> padding (assuming the structure is not packed). However, it was such a
> problem that even the later alpha chips had byte extensions.
OK, thanks!
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-26 19:33 ` Arnd Bergmann
` (3 preceding siblings ...)
(?)
@ 2015-09-27 14:10 ` Rafael J. Wysocki
-1 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linaro-kernel, Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev, Johannes Berg,
Linux Memory Management List, linux-arm-kernel,
open list:EDAC-CORE
On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > So if you allow something like debugfs to update your structure, how
> > > do you make sure there is the proper locking?
> >
> > Not really sure at all.. Isn't there some debugfs locking that will
> > jump in, to avoid updation of fields to the same device?
>
> No, if you need any locking to access variable, you cannot use the
> simple debugfs helpers but have to provide your own functions.
>
> > >> Anyway, that problem isn't here for sure as its between two
> > >> unsigned-longs. So, should I just move it to bool and resend ?
> > >
> > > I guess it might be more convenient to fold this into the other patch,
> > > because we seem to be splitting hairs here.
> >
> > I can and that's what I did. But then Arnd asked me to separate it
> > out. I can fold it back if that's what you want.
>
> It still makes sense to keep it separate I think, the patch is clearly
> different from the other parts.
I just don't see much point in going from unsigned long to u32 and then
from 32 to bool if we can go directly to bool in one go.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linaro-kernel, Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev@vger.kernel.org
On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > So if you allow something like debugfs to update your structure, how
> > > do you make sure there is the proper locking?
> >
> > Not really sure at all.. Isn't there some debugfs locking that will
> > jump in, to avoid updation of fields to the same device?
>
> No, if you need any locking to access variable, you cannot use the
> simple debugfs helpers but have to provide your own functions.
>
> > >> Anyway, that problem isn't here for sure as its between two
> > >> unsigned-longs. So, should I just move it to bool and resend ?
> > >
> > > I guess it might be more convenient to fold this into the other patch,
> > > because we seem to be splitting hairs here.
> >
> > I can and that's what I did. But then Arnd asked me to separate it
> > out. I can fold it back if that's what you want.
>
> It still makes sense to keep it separate I think, the patch is clearly
> different from the other parts.
I just don't see much point in going from unsigned long to u32 and then
from 32 to bool if we can go directly to bool in one go.
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linaro-kernel, Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev, Johannes Berg,
Linux Memory Management List, linux-arm-kernel,
open list:EDAC-CORE
On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > So if you allow something like debugfs to update your structure, how
> > > do you make sure there is the proper locking?
> >
> > Not really sure at all.. Isn't there some debugfs locking that will
> > jump in, to avoid updation of fields to the same device?
>
> No, if you need any locking to access variable, you cannot use the
> simple debugfs helpers but have to provide your own functions.
>
> > >> Anyway, that problem isn't here for sure as its between two
> > >> unsigned-longs. So, should I just move it to bool and resend ?
> > >
> > > I guess it might be more convenient to fold this into the other patch,
> > > because we seem to be splitting hairs here.
> >
> > I can and that's what I did. But then Arnd asked me to separate it
> > out. I can fold it back if that's what you want.
>
> It still makes sense to keep it separate I think, the patch is clearly
> different from the other parts.
I just don't see much point in going from unsigned long to u32 and then
from 32 to bool if we can go directly to bool in one go.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linaro-kernel, Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev@vger.kernel.org
On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > So if you allow something like debugfs to update your structure, how
> > > do you make sure there is the proper locking?
> >
> > Not really sure at all.. Isn't there some debugfs locking that will
> > jump in, to avoid updation of fields to the same device?
>
> No, if you need any locking to access variable, you cannot use the
> simple debugfs helpers but have to provide your own functions.
>
> > >> Anyway, that problem isn't here for sure as its between two
> > >> unsigned-longs. So, should I just move it to bool and resend ?
> > >
> > > I guess it might be more convenient to fold this into the other patch,
> > > because we seem to be splitting hairs here.
> >
> > I can and that's what I did. But then Arnd asked me to separate it
> > out. I can fold it back if that's what you want.
>
> It still makes sense to keep it separate I think, the patch is clearly
> different from the other parts.
I just don't see much point in going from unsigned long to u32 and then
from 32 to bool if we can go directly to bool in one go.
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:10 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linaro-kernel, Viresh Kumar, Rafael J. Wysocki,
open list:NETWORKING DRIVERS (WIRELESS),
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:TARGET SUBSYSTEM, linux-doc, Greg Kroah-Hartman,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, netdev, Johannes Berg,
Linux Memory Management List, linux-arm-kernel,
open list:EDAC-CORE
On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > So if you allow something like debugfs to update your structure, how
> > > do you make sure there is the proper locking?
> >
> > Not really sure at all.. Isn't there some debugfs locking that will
> > jump in, to avoid updation of fields to the same device?
>
> No, if you need any locking to access variable, you cannot use the
> simple debugfs helpers but have to provide your own functions.
>
> > >> Anyway, that problem isn't here for sure as its between two
> > >> unsigned-longs. So, should I just move it to bool and resend ?
> > >
> > > I guess it might be more convenient to fold this into the other patch,
> > > because we seem to be splitting hairs here.
> >
> > I can and that's what I did. But then Arnd asked me to separate it
> > out. I can fold it back if that's what you want.
>
> It still makes sense to keep it separate I think, the patch is clearly
> different from the other parts.
I just don't see much point in going from unsigned long to u32 and then
from 32 to bool if we can go directly to bool in one go.
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:10 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-27 14:10 UTC (permalink / raw)
To: linux-arm-kernel
On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > So if you allow something like debugfs to update your structure, how
> > > do you make sure there is the proper locking?
> >
> > Not really sure at all.. Isn't there some debugfs locking that will
> > jump in, to avoid updation of fields to the same device?
>
> No, if you need any locking to access variable, you cannot use the
> simple debugfs helpers but have to provide your own functions.
>
> > >> Anyway, that problem isn't here for sure as its between two
> > >> unsigned-longs. So, should I just move it to bool and resend ?
> > >
> > > I guess it might be more convenient to fold this into the other patch,
> > > because we seem to be splitting hairs here.
> >
> > I can and that's what I did. But then Arnd asked me to separate it
> > out. I can fold it back if that's what you want.
>
> It still makes sense to keep it separate I think, the patch is clearly
> different from the other parts.
I just don't see much point in going from unsigned long to u32 and then
from 32 to bool if we can go directly to bool in one go.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:35 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-27 14:35 UTC (permalink / raw)
To: Jiri Slaby
Cc: open list:AMD IOMMU (AMD-VI),
Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:TARGET SUBSYSTEM, Intel Linux Wireless,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linaro Kernel Mailman List, linux-doc, Linux Kernel Mailing List,
open list:EDAC-CORE, QCA ath9k Development,
open list:NETWORKING DRIVERS (WIRELESS),
Linux Memory Management List, linux-arm-kernel,
Greg Kroah-Hartman, netdev
On 26 September 2015 at 22:31, Jiri Slaby <jirislaby@gmail.com> wrote:
> But this has to crash whenever the file is read as val's storage is gone at
> that moment already, right?
Yeah, its fixed now in the new version. This was a *really* bad idea :(
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:35 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-27 14:35 UTC (permalink / raw)
To: Jiri Slaby
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
open list:BLUETOOTH DRIVERS,
open list:NETWORKING DRIVERS (WIRELESS),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
QCA ath9k Development, Intel Linux Wireless, Linux ACPI,
open list:AMD IOMMU (AMD-VI),
netdev-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman
On 26 September 2015 at 22:31, Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> But this has to crash whenever the file is read as val's storage is gone at
> that moment already, right?
Yeah, its fixed now in the new version. This was a *really* bad idea :(
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:35 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-27 14:35 UTC (permalink / raw)
To: Jiri Slaby
Cc: open list:AMD IOMMU (AMD-VI),
Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:TARGET SUBSYSTEM, Intel Linux Wireless,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linaro Kernel Mailman List, linux-doc, Linux Kernel Mailing List,
open list:EDAC-CORE, QCA ath9k Development,
open list:NETWORKING DRIVERS (WIRELESS),
Linux Memory Management List, linux-arm-kernel,
Greg Kroah-Hartman, netdev
On 26 September 2015 at 22:31, Jiri Slaby <jirislaby@gmail.com> wrote:
> But this has to crash whenever the file is read as val's storage is gone at
> that moment already, right?
Yeah, its fixed now in the new version. This was a *really* bad idea :(
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:35 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-27 14:35 UTC (permalink / raw)
To: Jiri Slaby
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
open list:BLUETOOTH DRIVERS,
open list:NETWORKING DRIVERS (WIRELESS),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Linux Kernel Mailing List,
QCA ath9k Development, Intel Linux Wireless, Linux ACPI,
open list:AMD IOMMU (AMD-VI),
netdev-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman, Linux
On 26 September 2015 at 22:31, Jiri Slaby <jirislaby-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> But this has to crash whenever the file is read as val's storage is gone at
> that moment already, right?
Yeah, its fixed now in the new version. This was a *really* bad idea :(
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:35 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-27 14:35 UTC (permalink / raw)
To: Jiri Slaby
Cc: open list:AMD IOMMU (AMD-VI),
Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:TARGET SUBSYSTEM, Intel Linux Wireless,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linaro Kernel Mailman List, linux-doc, Linux Kernel Mailing List,
open list:EDAC-CORE, QCA ath9k Development,
open list:NETWORKING DRIVERS (WIRELESS),
Linux Memory Management List, linux-arm-kernel,
Greg Kroah-Hartman, netdev
On 26 September 2015 at 22:31, Jiri Slaby <jirislaby@gmail.com> wrote:
> But this has to crash whenever the file is read as val's storage is gone at
> that moment already, right?
Yeah, its fixed now in the new version. This was a *really* bad idea :(
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-27 14:35 ` Viresh Kumar
0 siblings, 0 replies; 135+ messages in thread
From: Viresh Kumar @ 2015-09-27 14:35 UTC (permalink / raw)
To: linux-arm-kernel
On 26 September 2015 at 22:31, Jiri Slaby <jirislaby@gmail.com> wrote:
> But this has to crash whenever the file is read as val's storage is gone at
> that moment already, right?
Yeah, its fixed now in the new version. This was a *really* bad idea :(
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-27 14:10 ` Rafael J. Wysocki
` (3 preceding siblings ...)
(?)
@ 2015-09-28 8:24 ` Arnd Bergmann
-1 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-28 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rafael J. Wysocki, open list:BLUETOOTH DRIVERS,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel, open list:TARGET SUBSYSTEM, Rafael J. Wysocki,
Viresh Kumar, linux-doc, open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linux Memory Management List, Greg Kroah-Hartman, Johannes Berg,
netdev, open list:EDAC-CORE
On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > So if you allow something like debugfs to update your structure, how
> > > > do you make sure there is the proper locking?
> > >
> > > Not really sure at all.. Isn't there some debugfs locking that will
> > > jump in, to avoid updation of fields to the same device?
> >
> > No, if you need any locking to access variable, you cannot use the
> > simple debugfs helpers but have to provide your own functions.
> >
> > > >> Anyway, that problem isn't here for sure as its between two
> > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > >
> > > > I guess it might be more convenient to fold this into the other patch,
> > > > because we seem to be splitting hairs here.
> > >
> > > I can and that's what I did. But then Arnd asked me to separate it
> > > out. I can fold it back if that's what you want.
> >
> > It still makes sense to keep it separate I think, the patch is clearly
> > different from the other parts.
>
> I just don't see much point in going from unsigned long to u32 and then
> from 32 to bool if we can go directly to bool in one go.
It's only important to keep the 34-file multi-subsystem trivial cleanup
that doesn't change any functionality separate from the bugfix. If you
like to avoid patching one of the files twice, the alternative would
be to first change the API for all other instances from u32 to bool
and leave ACPI alone, and then do the second patch that changes ACPI
from long to bool.
Arnd
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:24 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-28 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rafael J. Wysocki, open list:BLUETOOTH DRIVERS,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel, open list:TARGET SUBSYSTEM, Rafael J. Wysocki,
Viresh Kumar, linux-doc, open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEB AND (UWB) SUBSYSTEM:,
Linux Memory Management List
On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > So if you allow something like debugfs to update your structure, how
> > > > do you make sure there is the proper locking?
> > >
> > > Not really sure at all.. Isn't there some debugfs locking that will
> > > jump in, to avoid updation of fields to the same device?
> >
> > No, if you need any locking to access variable, you cannot use the
> > simple debugfs helpers but have to provide your own functions.
> >
> > > >> Anyway, that problem isn't here for sure as its between two
> > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > >
> > > > I guess it might be more convenient to fold this into the other patch,
> > > > because we seem to be splitting hairs here.
> > >
> > > I can and that's what I did. But then Arnd asked me to separate it
> > > out. I can fold it back if that's what you want.
> >
> > It still makes sense to keep it separate I think, the patch is clearly
> > different from the other parts.
>
> I just don't see much point in going from unsigned long to u32 and then
> from 32 to bool if we can go directly to bool in one go.
It's only important to keep the 34-file multi-subsystem trivial cleanup
that doesn't change any functionality separate from the bugfix. If you
like to avoid patching one of the files twice, the alternative would
be to first change the API for all other instances from u32 to bool
and leave ACPI alone, and then do the second patch that changes ACPI
from long to bool.
Arnd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:24 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-28 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rafael J. Wysocki, open list:BLUETOOTH DRIVERS,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel, open list:TARGET SUBSYSTEM, Rafael J. Wysocki,
Viresh Kumar, linux-doc, open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linux Memory Management List, Greg Kroah-Hartman, Johannes Berg,
netdev, open list:EDAC-CORE
On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > So if you allow something like debugfs to update your structure, how
> > > > do you make sure there is the proper locking?
> > >
> > > Not really sure at all.. Isn't there some debugfs locking that will
> > > jump in, to avoid updation of fields to the same device?
> >
> > No, if you need any locking to access variable, you cannot use the
> > simple debugfs helpers but have to provide your own functions.
> >
> > > >> Anyway, that problem isn't here for sure as its between two
> > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > >
> > > > I guess it might be more convenient to fold this into the other patch,
> > > > because we seem to be splitting hairs here.
> > >
> > > I can and that's what I did. But then Arnd asked me to separate it
> > > out. I can fold it back if that's what you want.
> >
> > It still makes sense to keep it separate I think, the patch is clearly
> > different from the other parts.
>
> I just don't see much point in going from unsigned long to u32 and then
> from 32 to bool if we can go directly to bool in one go.
It's only important to keep the 34-file multi-subsystem trivial cleanup
that doesn't change any functionality separate from the bugfix. If you
like to avoid patching one of the files twice, the alternative would
be to first change the API for all other instances from u32 to bool
and leave ACPI alone, and then do the second patch that changes ACPI
from long to bool.
Arnd
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:24 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-28 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rafael J. Wysocki, open list:BLUETOOTH DRIVERS,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel, open list:TARGET SUBSYSTEM, Rafael J. Wysocki,
Viresh Kumar, linux-doc, open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEB AND (UWB) SUBSYSTEM:,
Linux Memory Management List
On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > So if you allow something like debugfs to update your structure, how
> > > > do you make sure there is the proper locking?
> > >
> > > Not really sure at all.. Isn't there some debugfs locking that will
> > > jump in, to avoid updation of fields to the same device?
> >
> > No, if you need any locking to access variable, you cannot use the
> > simple debugfs helpers but have to provide your own functions.
> >
> > > >> Anyway, that problem isn't here for sure as its between two
> > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > >
> > > > I guess it might be more convenient to fold this into the other patch,
> > > > because we seem to be splitting hairs here.
> > >
> > > I can and that's what I did. But then Arnd asked me to separate it
> > > out. I can fold it back if that's what you want.
> >
> > It still makes sense to keep it separate I think, the patch is clearly
> > different from the other parts.
>
> I just don't see much point in going from unsigned long to u32 and then
> from 32 to bool if we can go directly to bool in one go.
It's only important to keep the 34-file multi-subsystem trivial cleanup
that doesn't change any functionality separate from the bugfix. If you
like to avoid patching one of the files twice, the alternative would
be to first change the API for all other instances from u32 to bool
and leave ACPI alone, and then do the second patch that changes ACPI
from long to bool.
Arnd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:24 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-28 8:24 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rafael J. Wysocki, open list:BLUETOOTH DRIVERS,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel, open list:TARGET SUBSYSTEM, Rafael J. Wysocki,
Viresh Kumar, linux-doc, open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linux Memory Management List, Greg Kroah-Hartman, Johannes Berg,
netdev, open list:EDAC-CORE
On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > So if you allow something like debugfs to update your structure, how
> > > > do you make sure there is the proper locking?
> > >
> > > Not really sure at all.. Isn't there some debugfs locking that will
> > > jump in, to avoid updation of fields to the same device?
> >
> > No, if you need any locking to access variable, you cannot use the
> > simple debugfs helpers but have to provide your own functions.
> >
> > > >> Anyway, that problem isn't here for sure as its between two
> > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > >
> > > > I guess it might be more convenient to fold this into the other patch,
> > > > because we seem to be splitting hairs here.
> > >
> > > I can and that's what I did. But then Arnd asked me to separate it
> > > out. I can fold it back if that's what you want.
> >
> > It still makes sense to keep it separate I think, the patch is clearly
> > different from the other parts.
>
> I just don't see much point in going from unsigned long to u32 and then
> from 32 to bool if we can go directly to bool in one go.
It's only important to keep the 34-file multi-subsystem trivial cleanup
that doesn't change any functionality separate from the bugfix. If you
like to avoid patching one of the files twice, the alternative would
be to first change the API for all other instances from u32 to bool
and leave ACPI alone, and then do the second patch that changes ACPI
from long to bool.
Arnd
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:24 ` Arnd Bergmann
0 siblings, 0 replies; 135+ messages in thread
From: Arnd Bergmann @ 2015-09-28 8:24 UTC (permalink / raw)
To: linux-arm-kernel
On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > So if you allow something like debugfs to update your structure, how
> > > > do you make sure there is the proper locking?
> > >
> > > Not really sure at all.. Isn't there some debugfs locking that will
> > > jump in, to avoid updation of fields to the same device?
> >
> > No, if you need any locking to access variable, you cannot use the
> > simple debugfs helpers but have to provide your own functions.
> >
> > > >> Anyway, that problem isn't here for sure as its between two
> > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > >
> > > > I guess it might be more convenient to fold this into the other patch,
> > > > because we seem to be splitting hairs here.
> > >
> > > I can and that's what I did. But then Arnd asked me to separate it
> > > out. I can fold it back if that's what you want.
> >
> > It still makes sense to keep it separate I think, the patch is clearly
> > different from the other parts.
>
> I just don't see much point in going from unsigned long to u32 and then
> from 32 to bool if we can go directly to bool in one go.
It's only important to keep the 34-file multi-subsystem trivial cleanup
that doesn't change any functionality separate from the bugfix. If you
like to avoid patching one of the files twice, the alternative would
be to first change the API for all other instances from u32 to bool
and leave ACPI alone, and then do the second patch that changes ACPI
from long to bool.
Arnd
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:58 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 8:58 UTC (permalink / raw)
To: 'Rafael J. Wysocki', James Bottomley
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
RnJvbTogUmFmYWVsIEouIFd5c29ja2kNCj4gU2VudDogMjcgU2VwdGVtYmVyIDIwMTUgMTU6MDkN
Ci4uLg0KPiA+ID4gU2F5IHlvdSBoYXZlIHRocmVlIGFkamFjZW50IGZpZWxkcyBpbiBhIHN0cnVj
dHVyZSwgeCwgeSwgeiwgZWFjaCBvbmUgYnl0ZSBsb25nLg0KPiA+ID4gSW5pdGlhbGx5LCBhbGwg
b2YgdGhlbSBhcmUgZXF1YWwgdG8gMC4NCj4gPiA+DQo+ID4gPiBDUFUgQSB3cml0ZXMgMSB0byB4
IGFuZCBDUFUgQiB3cml0ZXMgMiB0byB5IGF0IHRoZSBzYW1lIHRpbWUuDQo+ID4gPg0KPiA+ID4g
V2hhdCdzIHRoZSByZXN1bHQ/DQo+ID4NCj4gPiBJIHRoaW5rIGV2ZXJ5IENQVSdzICBjYWNoZSBh
cmNoaXRlY3VyZSBndWFyYW50ZWVzIGFkamFjZW50IHN0b3JlDQo+ID4gaW50ZWdyaXR5LCBldmVu
IGluIHRoZSBmYWNlIG9mIFNNUCwgc28gaXQncyB4PT0xIGFuZCB5PT0yLiAgSWYgeW91J3JlDQo+
ID4gdGhpbmtpbmcgb2Ygb2xkIGFscGhhIFNNUCBzeXN0ZW0gd2hlcmUgdGhlIGxvd2VzdCBzdG9y
ZSB3aWR0aCBpcyAzMiBiaXRzDQo+ID4gYW5kIHRodXMgeW91IGhhdmUgdG8gZG8gUk1XIHRvIHVw
ZGF0ZSBhIGJ5dGUsIHRoaXMgd2FzIHVzdWFsbHkgZml4ZWQgYnkNCj4gPiBwYWRkaW5nIChhc3N1
bWluZyB0aGUgc3RydWN0dXJlIGlzIG5vdCBwYWNrZWQpLiAgSG93ZXZlciwgaXQgd2FzIHN1Y2gg
YQ0KPiA+IHByb2JsZW0gdGhhdCBldmVuIHRoZSBsYXRlciBhbHBoYSBjaGlwcyBoYWQgYnl0ZSBl
eHRlbnNpb25zLg0KDQpEb2VzIGxpbnV4IHN0aWxsIHN1cHBvcnQgdGhvc2Ugb2xkIEFscGhhcz8N
Cg0KVGhlIHg4NiBjcHVzIHdpbGwgYWxzbyBkbyAzMmJpdCB3aWRlIHJtdyBjeWNsZXMgZm9yIHRo
ZSAnYml0JyBvcGVyYXRpb25zLg0KDQo+IE9LLCB0aGFua3MhDQoNCllvdSBzdGlsbCBoYXZlIHRv
IGVuc3VyZSB0aGUgY29tcGlsZXIgZG9lc24ndCBkbyB3aWRlciBybXcgY3ljbGVzLg0KSSBiZWxp
ZXZlIHRoZSByZWNlbnQgdmVyc2lvbnMgb2YgZ2NjIHdvbid0IGRvIHdpZGVyIGFjY2Vzc2VzIGZv
ciB2b2xhdGlsZSBkYXRhLg0KDQoJRGF2aWQNCg0K
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:58 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 8:58 UTC (permalink / raw)
To: 'Rafael J. Wysocki', James Bottomley
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Viresh Kumar,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, Linux Memory Management List,
Greg Kroah-Hartman
From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the result?
> >
> > I think every CPU's cache architecure guarantees adjacent store
> > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > thinking of old alpha SMP system where the lowest store width is 32 bits
> > and thus you have to do RMW to update a byte, this was usually fixed by
> > padding (assuming the structure is not packed). However, it was such a
> > problem that even the later alpha chips had byte extensions.
Does linux still support those old Alphas?
The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> OK, thanks!
You still have to ensure the compiler doesn't do wider rmw cycles.
I believe the recent versions of gcc won't do wider accesses for volatile data.
David
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:58 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 8:58 UTC (permalink / raw)
To: 'Rafael J. Wysocki', James Bottomley
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1188 bytes --]
From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the result?
> >
> > I think every CPU's cache architecure guarantees adjacent store
> > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > thinking of old alpha SMP system where the lowest store width is 32 bits
> > and thus you have to do RMW to update a byte, this was usually fixed by
> > padding (assuming the structure is not packed). However, it was such a
> > problem that even the later alpha chips had byte extensions.
Does linux still support those old Alphas?
The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> OK, thanks!
You still have to ensure the compiler doesn't do wider rmw cycles.
I believe the recent versions of gcc won't do wider accesses for volatile data.
David
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:58 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 8:58 UTC (permalink / raw)
To: 'Rafael J. Wysocki', James Bottomley
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
Linaro Kernel Mailman List, open list:TARGET SUBSYSTEM,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Viresh Kumar,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:BLUETOOTH DRIVERS, Linux Memory Management List,
Greg Kroah-Hartman
From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the result?
> >
> > I think every CPU's cache architecure guarantees adjacent store
> > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > thinking of old alpha SMP system where the lowest store width is 32 bits
> > and thus you have to do RMW to update a byte, this was usually fixed by
> > padding (assuming the structure is not packed). However, it was such a
> > problem that even the later alpha chips had byte extensions.
Does linux still support those old Alphas?
The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> OK, thanks!
You still have to ensure the compiler doesn't do wider rmw cycles.
I believe the recent versions of gcc won't do wider accesses for volatile data.
David
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:58 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 8:58 UTC (permalink / raw)
To: 'Rafael J. Wysocki', James Bottomley
Cc: Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1155 bytes --]
From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the result?
> >
> > I think every CPU's cache architecure guarantees adjacent store
> > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > thinking of old alpha SMP system where the lowest store width is 32 bits
> > and thus you have to do RMW to update a byte, this was usually fixed by
> > padding (assuming the structure is not packed). However, it was such a
> > problem that even the later alpha chips had byte extensions.
Does linux still support those old Alphas?
The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> OK, thanks!
You still have to ensure the compiler doesn't do wider rmw cycles.
I believe the recent versions of gcc won't do wider accesses for volatile data.
David
N‹§²æìr¸›zǧu©ž²Æ {\b†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 8:58 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 8:58 UTC (permalink / raw)
To: linux-arm-kernel
From: Rafael J. Wysocki
> Sent: 27 September 2015 15:09
...
> > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > Initially, all of them are equal to 0.
> > >
> > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > >
> > > What's the result?
> >
> > I think every CPU's cache architecure guarantees adjacent store
> > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > thinking of old alpha SMP system where the lowest store width is 32 bits
> > and thus you have to do RMW to update a byte, this was usually fixed by
> > padding (assuming the structure is not packed). However, it was such a
> > problem that even the later alpha chips had byte extensions.
Does linux still support those old Alphas?
The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> OK, thanks!
You still have to ensure the compiler doesn't do wider rmw cycles.
I believe the recent versions of gcc won't do wider accesses for volatile data.
David
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-28 8:24 ` Arnd Bergmann
` (3 preceding siblings ...)
(?)
@ 2015-09-28 13:07 ` Rafael J. Wysocki
-1 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-28 13:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, open list:BLUETOOTH DRIVERS,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel, open list:TARGET SUBSYSTEM, Rafael J. Wysocki,
Viresh Kumar, linux-doc, open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linux Memory Management List, Greg Kroah-Hartman, Johannes Berg,
netdev, open list:EDAC-CORE
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > So if you allow something like debugfs to update your structure, how
> > > > > do you make sure there is the proper locking?
> > > >
> > > > Not really sure at all.. Isn't there some debugfs locking that will
> > > > jump in, to avoid updation of fields to the same device?
> > >
> > > No, if you need any locking to access variable, you cannot use the
> > > simple debugfs helpers but have to provide your own functions.
> > >
> > > > >> Anyway, that problem isn't here for sure as its between two
> > > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > > >
> > > > > I guess it might be more convenient to fold this into the other patch,
> > > > > because we seem to be splitting hairs here.
> > > >
> > > > I can and that's what I did. But then Arnd asked me to separate it
> > > > out. I can fold it back if that's what you want.
> > >
> > > It still makes sense to keep it separate I think, the patch is clearly
> > > different from the other parts.
> >
> > I just don't see much point in going from unsigned long to u32 and then
> > from 32 to bool if we can go directly to bool in one go.
>
> It's only important to keep the 34-file multi-subsystem trivial cleanup
> that doesn't change any functionality separate from the bugfix.
Which isn't a bugfix really, because the EC code is not run on any big-endian
systems to my knowledge. And it won't matter after the [2/2] anyway.
And the changelog of it doesn't really makes sense, because it talks about
future systems, but after the [2/2] no future systems will run that code in
the first place.
> If you like to avoid patching one of the files twice, the alternative would
> be to first change the API for all other instances from u32 to bool
> and leave ACPI alone, and then do the second patch that changes ACPI
> from long to bool.
My point is that this patch doesn't matter. It doesn't really fix anything
and the result of it goes away after the second patch.
The only marginal value of having it as a separate commit is in case if
(a) we need to revert the [2/2] for some reason and (b) ACPI-based ARM systems
(the big-endian ones) become full-hardware at one point. You know what the
chances of that are, though. :-)
That said I've ACKed the patch, because I don't care that much. I'm not exactly
sure why you care either.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 13:07 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-28 13:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Linux ACPI,
open list:TARGET SUBSYSTEM, Rafael J. Wysocki, Viresh Kumar,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Greg Kroah-Hartman, netdev-u79uwXL29TZUIDd8j+nm9g
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > > > > So if you allow something like debugfs to update your structure, how
> > > > > do you make sure there is the proper locking?
> > > >
> > > > Not really sure at all.. Isn't there some debugfs locking that will
> > > > jump in, to avoid updation of fields to the same device?
> > >
> > > No, if you need any locking to access variable, you cannot use the
> > > simple debugfs helpers but have to provide your own functions.
> > >
> > > > >> Anyway, that problem isn't here for sure as its between two
> > > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > > >
> > > > > I guess it might be more convenient to fold this into the other patch,
> > > > > because we seem to be splitting hairs here.
> > > >
> > > > I can and that's what I did. But then Arnd asked me to separate it
> > > > out. I can fold it back if that's what you want.
> > >
> > > It still makes sense to keep it separate I think, the patch is clearly
> > > different from the other parts.
> >
> > I just don't see much point in going from unsigned long to u32 and then
> > from 32 to bool if we can go directly to bool in one go.
>
> It's only important to keep the 34-file multi-subsystem trivial cleanup
> that doesn't change any functionality separate from the bugfix.
Which isn't a bugfix really, because the EC code is not run on any big-endian
systems to my knowledge. And it won't matter after the [2/2] anyway.
And the changelog of it doesn't really makes sense, because it talks about
future systems, but after the [2/2] no future systems will run that code in
the first place.
> If you like to avoid patching one of the files twice, the alternative would
> be to first change the API for all other instances from u32 to bool
> and leave ACPI alone, and then do the second patch that changes ACPI
> from long to bool.
My point is that this patch doesn't matter. It doesn't really fix anything
and the result of it goes away after the second patch.
The only marginal value of having it as a separate commit is in case if
(a) we need to revert the [2/2] for some reason and (b) ACPI-based ARM systems
(the big-endian ones) become full-hardware at one point. You know what the
chances of that are, though. :-)
That said I've ACKed the patch, because I don't care that much. I'm not exactly
sure why you care either.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 13:07 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-28 13:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, open list:BLUETOOTH DRIVERS,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel, open list:TARGET SUBSYSTEM, Rafael J. Wysocki,
Viresh Kumar, linux-doc, open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linux Memory Management List, Greg Kroah-Hartman, Johannes Berg,
netdev, open list:EDAC-CORE
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > So if you allow something like debugfs to update your structure, how
> > > > > do you make sure there is the proper locking?
> > > >
> > > > Not really sure at all.. Isn't there some debugfs locking that will
> > > > jump in, to avoid updation of fields to the same device?
> > >
> > > No, if you need any locking to access variable, you cannot use the
> > > simple debugfs helpers but have to provide your own functions.
> > >
> > > > >> Anyway, that problem isn't here for sure as its between two
> > > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > > >
> > > > > I guess it might be more convenient to fold this into the other patch,
> > > > > because we seem to be splitting hairs here.
> > > >
> > > > I can and that's what I did. But then Arnd asked me to separate it
> > > > out. I can fold it back if that's what you want.
> > >
> > > It still makes sense to keep it separate I think, the patch is clearly
> > > different from the other parts.
> >
> > I just don't see much point in going from unsigned long to u32 and then
> > from 32 to bool if we can go directly to bool in one go.
>
> It's only important to keep the 34-file multi-subsystem trivial cleanup
> that doesn't change any functionality separate from the bugfix.
Which isn't a bugfix really, because the EC code is not run on any big-endian
systems to my knowledge. And it won't matter after the [2/2] anyway.
And the changelog of it doesn't really makes sense, because it talks about
future systems, but after the [2/2] no future systems will run that code in
the first place.
> If you like to avoid patching one of the files twice, the alternative would
> be to first change the API for all other instances from u32 to bool
> and leave ACPI alone, and then do the second patch that changes ACPI
> from long to bool.
My point is that this patch doesn't matter. It doesn't really fix anything
and the result of it goes away after the second patch.
The only marginal value of having it as a separate commit is in case if
(a) we need to revert the [2/2] for some reason and (b) ACPI-based ARM systems
(the big-endian ones) become full-hardware at one point. You know what the
chances of that are, though. :-)
That said I've ACKed the patch, because I don't care that much. I'm not exactly
sure why you care either.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 13:07 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-28 13:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel-cunTk1MwBs8s++Sfvej+rw, Linux ACPI,
open list:TARGET SUBSYSTEM, Rafael J. Wysocki, Viresh Kumar,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:, Greg Kroah-Hartman,
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> > > > > So if you allow something like debugfs to update your structure, how
> > > > > do you make sure there is the proper locking?
> > > >
> > > > Not really sure at all.. Isn't there some debugfs locking that will
> > > > jump in, to avoid updation of fields to the same device?
> > >
> > > No, if you need any locking to access variable, you cannot use the
> > > simple debugfs helpers but have to provide your own functions.
> > >
> > > > >> Anyway, that problem isn't here for sure as its between two
> > > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > > >
> > > > > I guess it might be more convenient to fold this into the other patch,
> > > > > because we seem to be splitting hairs here.
> > > >
> > > > I can and that's what I did. But then Arnd asked me to separate it
> > > > out. I can fold it back if that's what you want.
> > >
> > > It still makes sense to keep it separate I think, the patch is clearly
> > > different from the other parts.
> >
> > I just don't see much point in going from unsigned long to u32 and then
> > from 32 to bool if we can go directly to bool in one go.
>
> It's only important to keep the 34-file multi-subsystem trivial cleanup
> that doesn't change any functionality separate from the bugfix.
Which isn't a bugfix really, because the EC code is not run on any big-endian
systems to my knowledge. And it won't matter after the [2/2] anyway.
And the changelog of it doesn't really makes sense, because it talks about
future systems, but after the [2/2] no future systems will run that code in
the first place.
> If you like to avoid patching one of the files twice, the alternative would
> be to first change the API for all other instances from u32 to bool
> and leave ACPI alone, and then do the second patch that changes ACPI
> from long to bool.
My point is that this patch doesn't matter. It doesn't really fix anything
and the result of it goes away after the second patch.
The only marginal value of having it as a separate commit is in case if
(a) we need to revert the [2/2] for some reason and (b) ACPI-based ARM systems
(the big-endian ones) become full-hardware at one point. You know what the
chances of that are, though. :-)
That said I've ACKed the patch, because I don't care that much. I'm not exactly
sure why you care either.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 13:07 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-28 13:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, open list:BLUETOOTH DRIVERS,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...,
linaro-kernel, open list:TARGET SUBSYSTEM, Rafael J. Wysocki,
Viresh Kumar, linux-doc, open list:NETWORKING DRIVERS (WIRELESS),
QCA ath9k Development, Linux Kernel Mailing List,
Intel Linux Wireless, Linux ACPI, open list:AMD IOMMU (AMD-VI),
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
Linux Memory Management List, Greg Kroah-Hartman, Johannes Berg,
netdev, open list:EDAC-CORE
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > So if you allow something like debugfs to update your structure, how
> > > > > do you make sure there is the proper locking?
> > > >
> > > > Not really sure at all.. Isn't there some debugfs locking that will
> > > > jump in, to avoid updation of fields to the same device?
> > >
> > > No, if you need any locking to access variable, you cannot use the
> > > simple debugfs helpers but have to provide your own functions.
> > >
> > > > >> Anyway, that problem isn't here for sure as its between two
> > > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > > >
> > > > > I guess it might be more convenient to fold this into the other patch,
> > > > > because we seem to be splitting hairs here.
> > > >
> > > > I can and that's what I did. But then Arnd asked me to separate it
> > > > out. I can fold it back if that's what you want.
> > >
> > > It still makes sense to keep it separate I think, the patch is clearly
> > > different from the other parts.
> >
> > I just don't see much point in going from unsigned long to u32 and then
> > from 32 to bool if we can go directly to bool in one go.
>
> It's only important to keep the 34-file multi-subsystem trivial cleanup
> that doesn't change any functionality separate from the bugfix.
Which isn't a bugfix really, because the EC code is not run on any big-endian
systems to my knowledge. And it won't matter after the [2/2] anyway.
And the changelog of it doesn't really makes sense, because it talks about
future systems, but after the [2/2] no future systems will run that code in
the first place.
> If you like to avoid patching one of the files twice, the alternative would
> be to first change the API for all other instances from u32 to bool
> and leave ACPI alone, and then do the second patch that changes ACPI
> from long to bool.
My point is that this patch doesn't matter. It doesn't really fix anything
and the result of it goes away after the second patch.
The only marginal value of having it as a separate commit is in case if
(a) we need to revert the [2/2] for some reason and (b) ACPI-based ARM systems
(the big-endian ones) become full-hardware at one point. You know what the
chances of that are, though. :-)
That said I've ACKed the patch, because I don't care that much. I'm not exactly
sure why you care either.
Thanks,
Rafael
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 13:07 ` Rafael J. Wysocki
0 siblings, 0 replies; 135+ messages in thread
From: Rafael J. Wysocki @ 2015-09-28 13:07 UTC (permalink / raw)
To: linux-arm-kernel
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > > On 25 September 2015 at 15:19, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > So if you allow something like debugfs to update your structure, how
> > > > > do you make sure there is the proper locking?
> > > >
> > > > Not really sure at all.. Isn't there some debugfs locking that will
> > > > jump in, to avoid updation of fields to the same device?
> > >
> > > No, if you need any locking to access variable, you cannot use the
> > > simple debugfs helpers but have to provide your own functions.
> > >
> > > > >> Anyway, that problem isn't here for sure as its between two
> > > > >> unsigned-longs. So, should I just move it to bool and resend ?
> > > > >
> > > > > I guess it might be more convenient to fold this into the other patch,
> > > > > because we seem to be splitting hairs here.
> > > >
> > > > I can and that's what I did. But then Arnd asked me to separate it
> > > > out. I can fold it back if that's what you want.
> > >
> > > It still makes sense to keep it separate I think, the patch is clearly
> > > different from the other parts.
> >
> > I just don't see much point in going from unsigned long to u32 and then
> > from 32 to bool if we can go directly to bool in one go.
>
> It's only important to keep the 34-file multi-subsystem trivial cleanup
> that doesn't change any functionality separate from the bugfix.
Which isn't a bugfix really, because the EC code is not run on any big-endian
systems to my knowledge. And it won't matter after the [2/2] anyway.
And the changelog of it doesn't really makes sense, because it talks about
future systems, but after the [2/2] no future systems will run that code in
the first place.
> If you like to avoid patching one of the files twice, the alternative would
> be to first change the API for all other instances from u32 to bool
> and leave ACPI alone, and then do the second patch that changes ACPI
> from long to bool.
My point is that this patch doesn't matter. It doesn't really fix anything
and the result of it goes away after the second patch.
The only marginal value of having it as a separate commit is in case if
(a) we need to revert the [2/2] for some reason and (b) ACPI-based ARM systems
(the big-endian ones) become full-hardware at one point. You know what the
chances of that are, though. :-)
That said I've ACKed the patch, because I don't care that much. I'm not exactly
sure why you care either.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:26 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 14:26 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > >
> > > > What's the result?
> > >
> > > I think every CPU's cache architecure guarantees adjacent store
> > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > padding (assuming the structure is not packed). However, it was such a
> > > problem that even the later alpha chips had byte extensions.
>
> Does linux still support those old Alphas?
>
> The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
That's different: it's an atomic RMW operation. The problem with the
alpha was that the operation wasn't atomic (meaning that it can't be
interrupted and no intermediate output states are visible).
> > OK, thanks!
>
> You still have to ensure the compiler doesn't do wider rmw cycles.
> I believe the recent versions of gcc won't do wider accesses for volatile data.
I don't understand this comment. You seem to be implying gcc would do a
64 bit RMW for a 32 bit store ... that would be daft when a single
instruction exists to perform the operation on all architectures.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:26 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 14:26 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev-u79uwXL29TY76Z2rM5mHXA,
open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM
On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > >
> > > > What's the result?
> > >
> > > I think every CPU's cache architecure guarantees adjacent store
> > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > padding (assuming the structure is not packed). However, it was such a
> > > problem that even the later alpha chips had byte extensions.
>
> Does linux still support those old Alphas?
>
> The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
That's different: it's an atomic RMW operation. The problem with the
alpha was that the operation wasn't atomic (meaning that it can't be
interrupted and no intermediate output states are visible).
> > OK, thanks!
>
> You still have to ensure the compiler doesn't do wider rmw cycles.
> I believe the recent versions of gcc won't do wider accesses for volatile data.
I don't understand this comment. You seem to be implying gcc would do a
64 bit RMW for a 32 bit store ... that would be daft when a single
instruction exists to perform the operation on all architectures.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:26 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 14:26 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > >
> > > > What's the result?
> > >
> > > I think every CPU's cache architecure guarantees adjacent store
> > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > padding (assuming the structure is not packed). However, it was such a
> > > problem that even the later alpha chips had byte extensions.
>
> Does linux still support those old Alphas?
>
> The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
That's different: it's an atomic RMW operation. The problem with the
alpha was that the operation wasn't atomic (meaning that it can't be
interrupted and no intermediate output states are visible).
> > OK, thanks!
>
> You still have to ensure the compiler doesn't do wider rmw cycles.
> I believe the recent versions of gcc won't do wider accesses for volatile data.
I don't understand this comment. You seem to be implying gcc would do a
64 bit RMW for a 32 bit store ... that would be daft when a single
instruction exists to perform the operation on all architectures.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:26 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 14:26 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc-u79uwXL29TY76Z2rM5mHXA,
Linux Kernel Mailing List,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Linux ACPI,
open list:BLUETOOTH DRIVERS, open list:AMD IOMMU (AMD-VI),
netdev-u79uwXL29TY76Z2rM5mHXA,
open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM
On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > >
> > > > What's the result?
> > >
> > > I think every CPU's cache architecure guarantees adjacent store
> > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > padding (assuming the structure is not packed). However, it was such a
> > > problem that even the later alpha chips had byte extensions.
>
> Does linux still support those old Alphas?
>
> The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
That's different: it's an atomic RMW operation. The problem with the
alpha was that the operation wasn't atomic (meaning that it can't be
interrupted and no intermediate output states are visible).
> > OK, thanks!
>
> You still have to ensure the compiler doesn't do wider rmw cycles.
> I believe the recent versions of gcc won't do wider accesses for volatile data.
I don't understand this comment. You seem to be implying gcc would do a
64 bit RMW for a 32 bit store ... that would be daft when a single
instruction exists to perform the operation on all architectures.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:26 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 14:26 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > >
> > > > What's the result?
> > >
> > > I think every CPU's cache architecure guarantees adjacent store
> > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > padding (assuming the structure is not packed). However, it was such a
> > > problem that even the later alpha chips had byte extensions.
>
> Does linux still support those old Alphas?
>
> The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
That's different: it's an atomic RMW operation. The problem with the
alpha was that the operation wasn't atomic (meaning that it can't be
interrupted and no intermediate output states are visible).
> > OK, thanks!
>
> You still have to ensure the compiler doesn't do wider rmw cycles.
> I believe the recent versions of gcc won't do wider accesses for volatile data.
I don't understand this comment. You seem to be implying gcc would do a
64 bit RMW for a 32 bit store ... that would be daft when a single
instruction exists to perform the operation on all architectures.
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:26 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 14:26 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> From: Rafael J. Wysocki
> > Sent: 27 September 2015 15:09
> ...
> > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > Initially, all of them are equal to 0.
> > > >
> > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > >
> > > > What's the result?
> > >
> > > I think every CPU's cache architecure guarantees adjacent store
> > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > padding (assuming the structure is not packed). However, it was such a
> > > problem that even the later alpha chips had byte extensions.
>
> Does linux still support those old Alphas?
>
> The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
That's different: it's an atomic RMW operation. The problem with the
alpha was that the operation wasn't atomic (meaning that it can't be
interrupted and no intermediate output states are visible).
> > OK, thanks!
>
> You still have to ensure the compiler doesn't do wider rmw cycles.
> I believe the recent versions of gcc won't do wider accesses for volatile data.
I don't understand this comment. You seem to be implying gcc would do a
64 bit RMW for a 32 bit store ... that would be daft when a single
instruction exists to perform the operation on all architectures.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-28 14:26 ` James Bottomley
` (3 preceding siblings ...)
(?)
@ 2015-09-28 14:50 ` David Laight
-1 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 14:50 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
RnJvbTogSmFtZXMgQm90dG9tbGV5IFttYWlsdG86SmFtZXMuQm90dG9tbGV5QEhhbnNlblBhcnRu
ZXJzaGlwLmNvbV0NCj4gU2VudDogMjggU2VwdGVtYmVyIDIwMTUgMTU6MjcNCj4gT24gTW9uLCAy
MDE1LTA5LTI4IGF0IDA4OjU4ICswMDAwLCBEYXZpZCBMYWlnaHQgd3JvdGU6DQo+ID4gRnJvbTog
UmFmYWVsIEouIFd5c29ja2kNCj4gPiA+IFNlbnQ6IDI3IFNlcHRlbWJlciAyMDE1IDE1OjA5DQo+
ID4gLi4uDQo+ID4gPiA+ID4gU2F5IHlvdSBoYXZlIHRocmVlIGFkamFjZW50IGZpZWxkcyBpbiBh
IHN0cnVjdHVyZSwgeCwgeSwgeiwgZWFjaCBvbmUgYnl0ZSBsb25nLg0KPiA+ID4gPiA+IEluaXRp
YWxseSwgYWxsIG9mIHRoZW0gYXJlIGVxdWFsIHRvIDAuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBD
UFUgQSB3cml0ZXMgMSB0byB4IGFuZCBDUFUgQiB3cml0ZXMgMiB0byB5IGF0IHRoZSBzYW1lIHRp
bWUuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXaGF0J3MgdGhlIHJlc3VsdD8NCj4gPiA+ID4NCj4g
PiA+ID4gSSB0aGluayBldmVyeSBDUFUncyAgY2FjaGUgYXJjaGl0ZWN1cmUgZ3VhcmFudGVlcyBh
ZGphY2VudCBzdG9yZQ0KPiA+ID4gPiBpbnRlZ3JpdHksIGV2ZW4gaW4gdGhlIGZhY2Ugb2YgU01Q
LCBzbyBpdCdzIHg9PTEgYW5kIHk9PTIuICBJZiB5b3UncmUNCj4gPiA+ID4gdGhpbmtpbmcgb2Yg
b2xkIGFscGhhIFNNUCBzeXN0ZW0gd2hlcmUgdGhlIGxvd2VzdCBzdG9yZSB3aWR0aCBpcyAzMiBi
aXRzDQo+ID4gPiA+IGFuZCB0aHVzIHlvdSBoYXZlIHRvIGRvIFJNVyB0byB1cGRhdGUgYSBieXRl
LCB0aGlzIHdhcyB1c3VhbGx5IGZpeGVkIGJ5DQo+ID4gPiA+IHBhZGRpbmcgKGFzc3VtaW5nIHRo
ZSBzdHJ1Y3R1cmUgaXMgbm90IHBhY2tlZCkuICBIb3dldmVyLCBpdCB3YXMgc3VjaCBhDQo+ID4g
PiA+IHByb2JsZW0gdGhhdCBldmVuIHRoZSBsYXRlciBhbHBoYSBjaGlwcyBoYWQgYnl0ZSBleHRl
bnNpb25zLg0KPiA+DQo+ID4gRG9lcyBsaW51eCBzdGlsbCBzdXBwb3J0IHRob3NlIG9sZCBBbHBo
YXM/DQo+ID4NCj4gPiBUaGUgeDg2IGNwdXMgd2lsbCBhbHNvIGRvIDMyYml0IHdpZGUgcm13IGN5
Y2xlcyBmb3IgdGhlICdiaXQnIG9wZXJhdGlvbnMuDQo+IA0KPiBUaGF0J3MgZGlmZmVyZW50OiBp
dCdzIGFuIGF0b21pYyBSTVcgb3BlcmF0aW9uLiAgVGhlIHByb2JsZW0gd2l0aCB0aGUNCj4gYWxw
aGEgd2FzIHRoYXQgdGhlIG9wZXJhdGlvbiB3YXNuJ3QgYXRvbWljIChtZWFuaW5nIHRoYXQgaXQg
Y2FuJ3QgYmUNCj4gaW50ZXJydXB0ZWQgYW5kIG5vIGludGVybWVkaWF0ZSBvdXRwdXQgc3RhdGVz
IGFyZSB2aXNpYmxlKS4NCg0KSXQgaXMgb25seSBhdG9taWMgaWYgcHJlZml4ZWQgYnkgdGhlICds
b2NrJyBwcmVmaXguDQpOb3JtYWxseSB0aGUgcmVhZCBhbmQgd3JpdGUgYXJlIHNlcGFyYXRlIGJ1
cyBjeWNsZXMuDQogDQo+ID4gWW91IHN0aWxsIGhhdmUgdG8gZW5zdXJlIHRoZSBjb21waWxlciBk
b2Vzbid0IGRvIHdpZGVyIHJtdyBjeWNsZXMuDQo+ID4gSSBiZWxpZXZlIHRoZSByZWNlbnQgdmVy
c2lvbnMgb2YgZ2NjIHdvbid0IGRvIHdpZGVyIGFjY2Vzc2VzIGZvciB2b2xhdGlsZSBkYXRhLg0K
PiANCj4gSSBkb24ndCB1bmRlcnN0YW5kIHRoaXMgY29tbWVudC4gIFlvdSBzZWVtIHRvIGJlIGlt
cGx5aW5nIGdjYyB3b3VsZCBkbyBhDQo+IDY0IGJpdCBSTVcgZm9yIGEgMzIgYml0IHN0b3JlIC4u
LiB0aGF0IHdvdWxkIGJlIGRhZnQgd2hlbiBhIHNpbmdsZQ0KPiBpbnN0cnVjdGlvbiBleGlzdHMg
dG8gcGVyZm9ybSB0aGUgb3BlcmF0aW9uIG9uIGFsbCBhcmNoaXRlY3R1cmVzLg0KDQpSZWFkIHRo
ZSBvYmplY3QgY29kZSBhbmQgd2VlcC4uLg0KSXQgaXMgbW9zdCBsaWtlbHkgdG8gaGFwcGVuIGZv
ciBvcGVyYXRpb25zIHRoYXQgYXJlIHJtdyAoZWcgYml0IHNldCkuDQpGb3IgaW5zdGFuY2UgdGhl
IGFybSBjcHUgaGFzIGxpbWl0ZWQgb2Zmc2V0cyBmb3IgMTZiaXQgYWNjZXNzZXMsIGZvcg0Kbm9y
bWFsIHN0cnVjdHVyZXMgdGhlIGNvbXBpbGVyIGlzIGxpa2VseSB0byB1c2UgYSAzMmJpdCBybXcg
c2VxdWVuY2UNCmZvciBhIDE2Yml0IGZpZWxkIHRoYXQgaGFzIGEgbGFyZ2Ugb2Zmc2V0Lg0KVGhl
IEMgbGFuZ3VhZ2UgYWxsb3dzIHRoZSBjb21waWxlciB0byBkbyBpdCBmb3IgYW55IGFjY2VzcyAo
SUlSQyBpbmNsdWRpbmcNCnZvbGF0aWxlcykuDQoNCglEYXZpZA0KDQo=
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:50 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 14:50 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM
From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: 28 September 2015 15:27
> On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > From: Rafael J. Wysocki
> > > Sent: 27 September 2015 15:09
> > ...
> > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > Initially, all of them are equal to 0.
> > > > >
> > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > >
> > > > > What's the result?
> > > >
> > > > I think every CPU's cache architecure guarantees adjacent store
> > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > padding (assuming the structure is not packed). However, it was such a
> > > > problem that even the later alpha chips had byte extensions.
> >
> > Does linux still support those old Alphas?
> >
> > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
>
> That's different: it's an atomic RMW operation. The problem with the
> alpha was that the operation wasn't atomic (meaning that it can't be
> interrupted and no intermediate output states are visible).
It is only atomic if prefixed by the 'lock' prefix.
Normally the read and write are separate bus cycles.
> > You still have to ensure the compiler doesn't do wider rmw cycles.
> > I believe the recent versions of gcc won't do wider accesses for volatile data.
>
> I don't understand this comment. You seem to be implying gcc would do a
> 64 bit RMW for a 32 bit store ... that would be daft when a single
> instruction exists to perform the operation on all architectures.
Read the object code and weep...
It is most likely to happen for operations that are rmw (eg bit set).
For instance the arm cpu has limited offsets for 16bit accesses, for
normal structures the compiler is likely to use a 32bit rmw sequence
for a 16bit field that has a large offset.
The C language allows the compiler to do it for any access (IIRC including
volatiles).
David
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:50 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 14:50 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2319 bytes --]
From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: 28 September 2015 15:27
> On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > From: Rafael J. Wysocki
> > > Sent: 27 September 2015 15:09
> > ...
> > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > Initially, all of them are equal to 0.
> > > > >
> > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > >
> > > > > What's the result?
> > > >
> > > > I think every CPU's cache architecure guarantees adjacent store
> > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > padding (assuming the structure is not packed). However, it was such a
> > > > problem that even the later alpha chips had byte extensions.
> >
> > Does linux still support those old Alphas?
> >
> > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
>
> That's different: it's an atomic RMW operation. The problem with the
> alpha was that the operation wasn't atomic (meaning that it can't be
> interrupted and no intermediate output states are visible).
It is only atomic if prefixed by the 'lock' prefix.
Normally the read and write are separate bus cycles.
> > You still have to ensure the compiler doesn't do wider rmw cycles.
> > I believe the recent versions of gcc won't do wider accesses for volatile data.
>
> I don't understand this comment. You seem to be implying gcc would do a
> 64 bit RMW for a 32 bit store ... that would be daft when a single
> instruction exists to perform the operation on all architectures.
Read the object code and weep...
It is most likely to happen for operations that are rmw (eg bit set).
For instance the arm cpu has limited offsets for 16bit accesses, for
normal structures the compiler is likely to use a 32bit rmw sequence
for a 16bit field that has a large offset.
The C language allows the compiler to do it for any access (IIRC including
volatiles).
David
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:50 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 14:50 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM
From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: 28 September 2015 15:27
> On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > From: Rafael J. Wysocki
> > > Sent: 27 September 2015 15:09
> > ...
> > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > Initially, all of them are equal to 0.
> > > > >
> > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > >
> > > > > What's the result?
> > > >
> > > > I think every CPU's cache architecure guarantees adjacent store
> > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > padding (assuming the structure is not packed). However, it was such a
> > > > problem that even the later alpha chips had byte extensions.
> >
> > Does linux still support those old Alphas?
> >
> > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
>
> That's different: it's an atomic RMW operation. The problem with the
> alpha was that the operation wasn't atomic (meaning that it can't be
> interrupted and no intermediate output states are visible).
It is only atomic if prefixed by the 'lock' prefix.
Normally the read and write are separate bus cycles.
> > You still have to ensure the compiler doesn't do wider rmw cycles.
> > I believe the recent versions of gcc won't do wider accesses for volatile data.
>
> I don't understand this comment. You seem to be implying gcc would do a
> 64 bit RMW for a 32 bit store ... that would be daft when a single
> instruction exists to perform the operation on all architectures.
Read the object code and weep...
It is most likely to happen for operations that are rmw (eg bit set).
For instance the arm cpu has limited offsets for 16bit accesses, for
normal structures the compiler is likely to use a 32bit rmw sequence
for a 16bit field that has a large offset.
The C language allows the compiler to do it for any access (IIRC including
volatiles).
David
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:50 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 14:50 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> Sent: 28 September 2015 15:27
> On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > From: Rafael J. Wysocki
> > > Sent: 27 September 2015 15:09
> > ...
> > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > Initially, all of them are equal to 0.
> > > > >
> > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > >
> > > > > What's the result?
> > > >
> > > > I think every CPU's cache architecure guarantees adjacent store
> > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > padding (assuming the structure is not packed). However, it was such a
> > > > problem that even the later alpha chips had byte extensions.
> >
> > Does linux still support those old Alphas?
> >
> > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
>
> That's different: it's an atomic RMW operation. The problem with the
> alpha was that the operation wasn't atomic (meaning that it can't be
> interrupted and no intermediate output states are visible).
It is only atomic if prefixed by the 'lock' prefix.
Normally the read and write are separate bus cycles.
> > You still have to ensure the compiler doesn't do wider rmw cycles.
> > I believe the recent versions of gcc won't do wider accesses for volatile data.
>
> I don't understand this comment. You seem to be implying gcc would do a
> 64 bit RMW for a 32 bit store ... that would be daft when a single
> instruction exists to perform the operation on all architectures.
Read the object code and weep...
It is most likely to happen for operations that are rmw (eg bit set).
For instance the arm cpu has limited offsets for 16bit accesses, for
normal structures the compiler is likely to use a 32bit rmw sequence
for a 16bit field that has a large offset.
The C language allows the compiler to do it for any access (IIRC including
volatiles).
David
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 14:50 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 14:50 UTC (permalink / raw)
To: linux-arm-kernel
From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com]
> Sent: 28 September 2015 15:27
> On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > From: Rafael J. Wysocki
> > > Sent: 27 September 2015 15:09
> > ...
> > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > Initially, all of them are equal to 0.
> > > > >
> > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > >
> > > > > What's the result?
> > > >
> > > > I think every CPU's cache architecure guarantees adjacent store
> > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > padding (assuming the structure is not packed). However, it was such a
> > > > problem that even the later alpha chips had byte extensions.
> >
> > Does linux still support those old Alphas?
> >
> > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
>
> That's different: it's an atomic RMW operation. The problem with the
> alpha was that the operation wasn't atomic (meaning that it can't be
> interrupted and no intermediate output states are visible).
It is only atomic if prefixed by the 'lock' prefix.
Normally the read and write are separate bus cycles.
> > You still have to ensure the compiler doesn't do wider rmw cycles.
> > I believe the recent versions of gcc won't do wider accesses for volatile data.
>
> I don't understand this comment. You seem to be implying gcc would do a
> 64 bit RMW for a 32 bit store ... that would be daft when a single
> instruction exists to perform the operation on all architectures.
Read the object code and weep...
It is most likely to happen for operations that are rmw (eg bit set).
For instance the arm cpu has limited offsets for 16bit accesses, for
normal structures the compiler is likely to use a 32bit rmw sequence
for a 16bit field that has a large offset.
The C language allows the compiler to do it for any access (IIRC including
volatiles).
David
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-28 14:50 ` David Laight
` (3 preceding siblings ...)
(?)
@ 2015-09-28 15:11 ` James Bottomley
-1 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 15:11 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Mon, 2015-09-28 at 14:50 +0000, David Laight wrote:
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
> > > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > > Initially, all of them are equal to 0.
> > > > > >
> > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > > >
> > > > > > What's the result?
> > > > >
> > > > > I think every CPU's cache architecure guarantees adjacent store
> > > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > > padding (assuming the structure is not packed). However, it was such a
> > > > > problem that even the later alpha chips had byte extensions.
> > >
> > > Does linux still support those old Alphas?
> > >
> > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> >
> > That's different: it's an atomic RMW operation. The problem with the
> > alpha was that the operation wasn't atomic (meaning that it can't be
> > interrupted and no intermediate output states are visible).
>
> It is only atomic if prefixed by the 'lock' prefix.
> Normally the read and write are separate bus cycles.
The essential point is that x86 has atomic bit ops and byte writes.
Early alpha did not.
> > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> >
> > I don't understand this comment. You seem to be implying gcc would do a
> > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > instruction exists to perform the operation on all architectures.
>
> Read the object code and weep...
> It is most likely to happen for operations that are rmw (eg bit set).
> For instance the arm cpu has limited offsets for 16bit accesses, for
> normal structures the compiler is likely to use a 32bit rmw sequence
> for a 16bit field that has a large offset.
> The C language allows the compiler to do it for any access (IIRC including
> volatiles).
I think you might be confusing different things. Most RISC CPUs can't
do 32 bit store immediates because there aren't enough bits in their
arsenal, so they tend to split 32 bit loads into a left and right part
(first the top then the offset). This (and other things) are mostly
what you see in code. However, 32 bit register stores are still atomic,
which is all we require. It's not really the compiler's fault, it's
mostly an architectural limitation.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:11 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 15:11 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM
On Mon, 2015-09-28 at 14:50 +0000, David Laight wrote:
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
> > > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > > Initially, all of them are equal to 0.
> > > > > >
> > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > > >
> > > > > > What's the result?
> > > > >
> > > > > I think every CPU's cache architecure guarantees adjacent store
> > > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > > padding (assuming the structure is not packed). However, it was such a
> > > > > problem that even the later alpha chips had byte extensions.
> > >
> > > Does linux still support those old Alphas?
> > >
> > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> >
> > That's different: it's an atomic RMW operation. The problem with the
> > alpha was that the operation wasn't atomic (meaning that it can't be
> > interrupted and no intermediate output states are visible).
>
> It is only atomic if prefixed by the 'lock' prefix.
> Normally the read and write are separate bus cycles.
The essential point is that x86 has atomic bit ops and byte writes.
Early alpha did not.
> > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> >
> > I don't understand this comment. You seem to be implying gcc would do a
> > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > instruction exists to perform the operation on all architectures.
>
> Read the object code and weep...
> It is most likely to happen for operations that are rmw (eg bit set).
> For instance the arm cpu has limited offsets for 16bit accesses, for
> normal structures the compiler is likely to use a 32bit rmw sequence
> for a 16bit field that has a large offset.
> The C language allows the compiler to do it for any access (IIRC including
> volatiles).
I think you might be confusing different things. Most RISC CPUs can't
do 32 bit store immediates because there aren't enough bits in their
arsenal, so they tend to split 32 bit loads into a left and right part
(first the top then the offset). This (and other things) are mostly
what you see in code. However, 32 bit register stores are still atomic,
which is all we require. It's not really the compiler's fault, it's
mostly an architectural limitation.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:11 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 15:11 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Mon, 2015-09-28 at 14:50 +0000, David Laight wrote:
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
> > > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > > Initially, all of them are equal to 0.
> > > > > >
> > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > > >
> > > > > > What's the result?
> > > > >
> > > > > I think every CPU's cache architecure guarantees adjacent store
> > > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > > padding (assuming the structure is not packed). However, it was such a
> > > > > problem that even the later alpha chips had byte extensions.
> > >
> > > Does linux still support those old Alphas?
> > >
> > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> >
> > That's different: it's an atomic RMW operation. The problem with the
> > alpha was that the operation wasn't atomic (meaning that it can't be
> > interrupted and no intermediate output states are visible).
>
> It is only atomic if prefixed by the 'lock' prefix.
> Normally the read and write are separate bus cycles.
The essential point is that x86 has atomic bit ops and byte writes.
Early alpha did not.
> > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> >
> > I don't understand this comment. You seem to be implying gcc would do a
> > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > instruction exists to perform the operation on all architectures.
>
> Read the object code and weep...
> It is most likely to happen for operations that are rmw (eg bit set).
> For instance the arm cpu has limited offsets for 16bit accesses, for
> normal structures the compiler is likely to use a 32bit rmw sequence
> for a 16bit field that has a large offset.
> The C language allows the compiler to do it for any access (IIRC including
> volatiles).
I think you might be confusing different things. Most RISC CPUs can't
do 32 bit store immediates because there aren't enough bits in their
arsenal, so they tend to split 32 bit loads into a left and right part
(first the top then the offset). This (and other things) are mostly
what you see in code. However, 32 bit register stores are still atomic,
which is all we require. It's not really the compiler's fault, it's
mostly an architectural limitation.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:11 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 15:11 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM
On Mon, 2015-09-28 at 14:50 +0000, David Laight wrote:
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
> > > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > > Initially, all of them are equal to 0.
> > > > > >
> > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > > >
> > > > > > What's the result?
> > > > >
> > > > > I think every CPU's cache architecure guarantees adjacent store
> > > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > > padding (assuming the structure is not packed). However, it was such a
> > > > > problem that even the later alpha chips had byte extensions.
> > >
> > > Does linux still support those old Alphas?
> > >
> > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> >
> > That's different: it's an atomic RMW operation. The problem with the
> > alpha was that the operation wasn't atomic (meaning that it can't be
> > interrupted and no intermediate output states are visible).
>
> It is only atomic if prefixed by the 'lock' prefix.
> Normally the read and write are separate bus cycles.
The essential point is that x86 has atomic bit ops and byte writes.
Early alpha did not.
> > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> >
> > I don't understand this comment. You seem to be implying gcc would do a
> > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > instruction exists to perform the operation on all architectures.
>
> Read the object code and weep...
> It is most likely to happen for operations that are rmw (eg bit set).
> For instance the arm cpu has limited offsets for 16bit accesses, for
> normal structures the compiler is likely to use a 32bit rmw sequence
> for a 16bit field that has a large offset.
> The C language allows the compiler to do it for any access (IIRC including
> volatiles).
I think you might be confusing different things. Most RISC CPUs can't
do 32 bit store immediates because there aren't enough bits in their
arsenal, so they tend to split 32 bit loads into a left and right part
(first the top then the offset). This (and other things) are mostly
what you see in code. However, 32 bit register stores are still atomic,
which is all we require. It's not really the compiler's fault, it's
mostly an architectural limitation.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:11 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 15:11 UTC (permalink / raw)
To: David Laight
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
On Mon, 2015-09-28 at 14:50 +0000, David Laight wrote:
> From: James Bottomley [mailto:James.Bottomley@HansenPartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
> > > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > > Initially, all of them are equal to 0.
> > > > > >
> > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > > >
> > > > > > What's the result?
> > > > >
> > > > > I think every CPU's cache architecure guarantees adjacent store
> > > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > > padding (assuming the structure is not packed). However, it was such a
> > > > > problem that even the later alpha chips had byte extensions.
> > >
> > > Does linux still support those old Alphas?
> > >
> > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> >
> > That's different: it's an atomic RMW operation. The problem with the
> > alpha was that the operation wasn't atomic (meaning that it can't be
> > interrupted and no intermediate output states are visible).
>
> It is only atomic if prefixed by the 'lock' prefix.
> Normally the read and write are separate bus cycles.
The essential point is that x86 has atomic bit ops and byte writes.
Early alpha did not.
> > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> >
> > I don't understand this comment. You seem to be implying gcc would do a
> > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > instruction exists to perform the operation on all architectures.
>
> Read the object code and weep...
> It is most likely to happen for operations that are rmw (eg bit set).
> For instance the arm cpu has limited offsets for 16bit accesses, for
> normal structures the compiler is likely to use a 32bit rmw sequence
> for a 16bit field that has a large offset.
> The C language allows the compiler to do it for any access (IIRC including
> volatiles).
I think you might be confusing different things. Most RISC CPUs can't
do 32 bit store immediates because there aren't enough bits in their
arsenal, so they tend to split 32 bit loads into a left and right part
(first the top then the offset). This (and other things) are mostly
what you see in code. However, 32 bit register stores are still atomic,
which is all we require. It's not really the compiler's fault, it's
mostly an architectural limitation.
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:11 ` James Bottomley
0 siblings, 0 replies; 135+ messages in thread
From: James Bottomley @ 2015-09-28 15:11 UTC (permalink / raw)
To: linux-arm-kernel
On Mon, 2015-09-28 at 14:50 +0000, David Laight wrote:
> From: James Bottomley [mailto:James.Bottomley at HansenPartnership.com]
> > Sent: 28 September 2015 15:27
> > On Mon, 2015-09-28 at 08:58 +0000, David Laight wrote:
> > > From: Rafael J. Wysocki
> > > > Sent: 27 September 2015 15:09
> > > ...
> > > > > > Say you have three adjacent fields in a structure, x, y, z, each one byte long.
> > > > > > Initially, all of them are equal to 0.
> > > > > >
> > > > > > CPU A writes 1 to x and CPU B writes 2 to y at the same time.
> > > > > >
> > > > > > What's the result?
> > > > >
> > > > > I think every CPU's cache architecure guarantees adjacent store
> > > > > integrity, even in the face of SMP, so it's x==1 and y==2. If you're
> > > > > thinking of old alpha SMP system where the lowest store width is 32 bits
> > > > > and thus you have to do RMW to update a byte, this was usually fixed by
> > > > > padding (assuming the structure is not packed). However, it was such a
> > > > > problem that even the later alpha chips had byte extensions.
> > >
> > > Does linux still support those old Alphas?
> > >
> > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> >
> > That's different: it's an atomic RMW operation. The problem with the
> > alpha was that the operation wasn't atomic (meaning that it can't be
> > interrupted and no intermediate output states are visible).
>
> It is only atomic if prefixed by the 'lock' prefix.
> Normally the read and write are separate bus cycles.
The essential point is that x86 has atomic bit ops and byte writes.
Early alpha did not.
> > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> >
> > I don't understand this comment. You seem to be implying gcc would do a
> > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > instruction exists to perform the operation on all architectures.
>
> Read the object code and weep...
> It is most likely to happen for operations that are rmw (eg bit set).
> For instance the arm cpu has limited offsets for 16bit accesses, for
> normal structures the compiler is likely to use a 32bit rmw sequence
> for a 16bit field that has a large offset.
> The C language allows the compiler to do it for any access (IIRC including
> volatiles).
I think you might be confusing different things. Most RISC CPUs can't
do 32 bit store immediates because there aren't enough bits in their
arsenal, so they tend to split 32 bit loads into a left and right part
(first the top then the offset). This (and other things) are mostly
what you see in code. However, 32 bit register stores are still atomic,
which is all we require. It's not really the compiler's fault, it's
mostly an architectural limitation.
James
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
2015-09-28 15:11 ` James Bottomley
` (3 preceding siblings ...)
(?)
@ 2015-09-28 15:31 ` David Laight
-1 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 15:31 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
RnJvbTogSmFtZXMgQm90dG9tbGV5IA0KPiBTZW50OiAyOCBTZXB0ZW1iZXIgMjAxNSAxNjoxMg0K
PiA+ID4gPiBUaGUgeDg2IGNwdXMgd2lsbCBhbHNvIGRvIDMyYml0IHdpZGUgcm13IGN5Y2xlcyBm
b3IgdGhlICdiaXQnIG9wZXJhdGlvbnMuDQo+ID4gPg0KPiA+ID4gVGhhdCdzIGRpZmZlcmVudDog
aXQncyBhbiBhdG9taWMgUk1XIG9wZXJhdGlvbi4gIFRoZSBwcm9ibGVtIHdpdGggdGhlDQo+ID4g
PiBhbHBoYSB3YXMgdGhhdCB0aGUgb3BlcmF0aW9uIHdhc24ndCBhdG9taWMgKG1lYW5pbmcgdGhh
dCBpdCBjYW4ndCBiZQ0KPiA+ID4gaW50ZXJydXB0ZWQgYW5kIG5vIGludGVybWVkaWF0ZSBvdXRw
dXQgc3RhdGVzIGFyZSB2aXNpYmxlKS4NCj4gPg0KPiA+IEl0IGlzIG9ubHkgYXRvbWljIGlmIHBy
ZWZpeGVkIGJ5IHRoZSAnbG9jaycgcHJlZml4Lg0KPiA+IE5vcm1hbGx5IHRoZSByZWFkIGFuZCB3
cml0ZSBhcmUgc2VwYXJhdGUgYnVzIGN5Y2xlcy4NCj4gDQo+IFRoZSBlc3NlbnRpYWwgcG9pbnQg
aXMgdGhhdCB4ODYgaGFzIGF0b21pYyBiaXQgb3BzIGFuZCBieXRlIHdyaXRlcy4NCj4gRWFybHkg
YWxwaGEgZGlkIG5vdC4NCg0KRWFybHkgYWxwaGEgZGlkbid0IGhhdmUgYW55IGJ5dGUgYWNjZXNz
ZXMuDQoNCk9uIHg4NiBpZiB5b3UgaGF2ZSB0aGUgZm9sbG93aW5nOg0KCXN0cnVjdCB7DQoJCWNo
YXIgIGE7DQoJCXZvbGF0aWxlIGNoYXIgYjsNCgl9ICpmb287DQoJZm9vLT5hIHw9IDQ7DQoNClRo
ZSBjb21waWxlciBpcyBsaWtlbHkgdG8gZ2VuZXJhdGUgYSAnYmlzICM0LCAwKHJieCknIChvciBz
aW1pbGFyKQ0KYW5kIHRoZSBjcHUgd2lsbCBkbyB0d28gMzJiaXQgbWVtb3J5IGN5Y2xlcyB0aGF0
IHJlYWQgYW5kIHdyaXRlDQp0aGUgJ3ZvbGF0aWxlJyBmaWVsZCAnYicuDQooZ2NjIGRlZmluaXRl
bHkgdXNlZCB0byBkbyB0aGlzLi4uKQ0KDQpBIGxvdCBvZiBmaWVsZHMgd2VyZSBtYWRlIDMyYml0
IChhbmQgcHJvYmFibHkgbm90IGJpdGZpZWxkcykgaW4gdGhlIGxpbnV4DQprZXJuZWwgdHJlZSBh
IHllYXIgb3IgdHdvIGFnbyB0byBhdm9pZCB0aGlzIHZlcnkgcHJvYmxlbS4NCg0KPiA+ID4gPiBZ
b3Ugc3RpbGwgaGF2ZSB0byBlbnN1cmUgdGhlIGNvbXBpbGVyIGRvZXNuJ3QgZG8gd2lkZXIgcm13
IGN5Y2xlcy4NCj4gPiA+ID4gSSBiZWxpZXZlIHRoZSByZWNlbnQgdmVyc2lvbnMgb2YgZ2NjIHdv
bid0IGRvIHdpZGVyIGFjY2Vzc2VzIGZvciB2b2xhdGlsZSBkYXRhLg0KPiA+ID4NCj4gPiA+IEkg
ZG9uJ3QgdW5kZXJzdGFuZCB0aGlzIGNvbW1lbnQuICBZb3Ugc2VlbSB0byBiZSBpbXBseWluZyBn
Y2Mgd291bGQgZG8gYQ0KPiA+ID4gNjQgYml0IFJNVyBmb3IgYSAzMiBiaXQgc3RvcmUgLi4uIHRo
YXQgd291bGQgYmUgZGFmdCB3aGVuIGEgc2luZ2xlDQo+ID4gPiBpbnN0cnVjdGlvbiBleGlzdHMg
dG8gcGVyZm9ybSB0aGUgb3BlcmF0aW9uIG9uIGFsbCBhcmNoaXRlY3R1cmVzLg0KPiA+DQo+ID4g
UmVhZCB0aGUgb2JqZWN0IGNvZGUgYW5kIHdlZXAuLi4NCj4gPiBJdCBpcyBtb3N0IGxpa2VseSB0
byBoYXBwZW4gZm9yIG9wZXJhdGlvbnMgdGhhdCBhcmUgcm13IChlZyBiaXQgc2V0KS4NCj4gPiBG
b3IgaW5zdGFuY2UgdGhlIGFybSBjcHUgaGFzIGxpbWl0ZWQgb2Zmc2V0cyBmb3IgMTZiaXQgYWNj
ZXNzZXMsIGZvcg0KPiA+IG5vcm1hbCBzdHJ1Y3R1cmVzIHRoZSBjb21waWxlciBpcyBsaWtlbHkg
dG8gdXNlIGEgMzJiaXQgcm13IHNlcXVlbmNlDQo+ID4gZm9yIGEgMTZiaXQgZmllbGQgdGhhdCBo
YXMgYSBsYXJnZSBvZmZzZXQuDQo+ID4gVGhlIEMgbGFuZ3VhZ2UgYWxsb3dzIHRoZSBjb21waWxl
ciB0byBkbyBpdCBmb3IgYW55IGFjY2VzcyAoSUlSQyBpbmNsdWRpbmcNCj4gPiB2b2xhdGlsZXMp
Lg0KPiANCj4gSSB0aGluayB5b3UgbWlnaHQgYmUgY29uZnVzaW5nIGRpZmZlcmVudCB0aGluZ3Mu
ICBNb3N0IFJJU0MgQ1BVcyBjYW4ndA0KPiBkbyAzMiBiaXQgc3RvcmUgaW1tZWRpYXRlcyBiZWNh
dXNlIHRoZXJlIGFyZW4ndCBlbm91Z2ggYml0cyBpbiB0aGVpcg0KPiBhcnNlbmFsLCBzbyB0aGV5
IHRlbmQgdG8gc3BsaXQgMzIgYml0IGxvYWRzIGludG8gYSBsZWZ0IGFuZCByaWdodCBwYXJ0DQo+
IChmaXJzdCB0aGUgdG9wIHRoZW4gdGhlIG9mZnNldCkuICBUaGlzIChhbmQgb3RoZXIgdGhpbmdz
KSBhcmUgbW9zdGx5DQo+IHdoYXQgeW91IHNlZSBpbiBjb2RlLiAgSG93ZXZlciwgMzIgYml0IHJl
Z2lzdGVyIHN0b3JlcyBhcmUgc3RpbGwgYXRvbWljLA0KPiB3aGljaCBpcyBhbGwgd2UgcmVxdWly
ZS4gIEl0J3Mgbm90IHJlYWxseSB0aGUgY29tcGlsZXIncyBmYXVsdCwgaXQncw0KPiBtb3N0bHkg
YW4gYXJjaGl0ZWN0dXJhbCBsaW1pdGF0aW9uLg0KDQpObywgSSdtIG5vdCB0YWxraW5nIGFib3V0
IGhvdyAzMmJpdCBjb25zdGFudHMgYXJlIGdlbmVyYXRlZC4NCkknbSB0YWxraW5nIGFib3V0IHN0
cnVjdHVyZSBvZmZzZXRzLg0KDQoJRGF2aWQNCg0K
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:31 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 15:31 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2580 bytes --]
From: James Bottomley
> Sent: 28 September 2015 16:12
> > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> > >
> > > That's different: it's an atomic RMW operation. The problem with the
> > > alpha was that the operation wasn't atomic (meaning that it can't be
> > > interrupted and no intermediate output states are visible).
> >
> > It is only atomic if prefixed by the 'lock' prefix.
> > Normally the read and write are separate bus cycles.
>
> The essential point is that x86 has atomic bit ops and byte writes.
> Early alpha did not.
Early alpha didn't have any byte accesses.
On x86 if you have the following:
struct {
char a;
volatile char b;
} *foo;
foo->a |= 4;
The compiler is likely to generate a 'bis #4, 0(rbx)' (or similar)
and the cpu will do two 32bit memory cycles that read and write
the 'volatile' field 'b'.
(gcc definitely used to do this...)
A lot of fields were made 32bit (and probably not bitfields) in the linux
kernel tree a year or two ago to avoid this very problem.
> > > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> > >
> > > I don't understand this comment. You seem to be implying gcc would do a
> > > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > > instruction exists to perform the operation on all architectures.
> >
> > Read the object code and weep...
> > It is most likely to happen for operations that are rmw (eg bit set).
> > For instance the arm cpu has limited offsets for 16bit accesses, for
> > normal structures the compiler is likely to use a 32bit rmw sequence
> > for a 16bit field that has a large offset.
> > The C language allows the compiler to do it for any access (IIRC including
> > volatiles).
>
> I think you might be confusing different things. Most RISC CPUs can't
> do 32 bit store immediates because there aren't enough bits in their
> arsenal, so they tend to split 32 bit loads into a left and right part
> (first the top then the offset). This (and other things) are mostly
> what you see in code. However, 32 bit register stores are still atomic,
> which is all we require. It's not really the compiler's fault, it's
> mostly an architectural limitation.
No, I'm not talking about how 32bit constants are generated.
I'm talking about structure offsets.
David
N‹§²æìr¸›zǧu©ž²Æ {\b†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:31 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 15:31 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2582 bytes --]
From: James Bottomley
> Sent: 28 September 2015 16:12
> > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> > >
> > > That's different: it's an atomic RMW operation. The problem with the
> > > alpha was that the operation wasn't atomic (meaning that it can't be
> > > interrupted and no intermediate output states are visible).
> >
> > It is only atomic if prefixed by the 'lock' prefix.
> > Normally the read and write are separate bus cycles.
>
> The essential point is that x86 has atomic bit ops and byte writes.
> Early alpha did not.
Early alpha didn't have any byte accesses.
On x86 if you have the following:
struct {
char a;
volatile char b;
} *foo;
foo->a |= 4;
The compiler is likely to generate a 'bis #4, 0(rbx)' (or similar)
and the cpu will do two 32bit memory cycles that read and write
the 'volatile' field 'b'.
(gcc definitely used to do this...)
A lot of fields were made 32bit (and probably not bitfields) in the linux
kernel tree a year or two ago to avoid this very problem.
> > > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> > >
> > > I don't understand this comment. You seem to be implying gcc would do a
> > > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > > instruction exists to perform the operation on all architectures.
> >
> > Read the object code and weep...
> > It is most likely to happen for operations that are rmw (eg bit set).
> > For instance the arm cpu has limited offsets for 16bit accesses, for
> > normal structures the compiler is likely to use a 32bit rmw sequence
> > for a 16bit field that has a large offset.
> > The C language allows the compiler to do it for any access (IIRC including
> > volatiles).
>
> I think you might be confusing different things. Most RISC CPUs can't
> do 32 bit store immediates because there aren't enough bits in their
> arsenal, so they tend to split 32 bit loads into a left and right part
> (first the top then the offset). This (and other things) are mostly
> what you see in code. However, 32 bit register stores are still atomic,
> which is all we require. It's not really the compiler's fault, it's
> mostly an architectural limitation.
No, I'm not talking about how 32bit constants are generated.
I'm talking about structure offsets.
David
ÿôèº{.nÇ+‰·Ÿ®‰†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a¢f£¢·hšïêÿ‘êçz_è®\x03(階ŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨èÚ&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:31 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 15:31 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2580 bytes --]
From: James Bottomley
> Sent: 28 September 2015 16:12
> > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> > >
> > > That's different: it's an atomic RMW operation. The problem with the
> > > alpha was that the operation wasn't atomic (meaning that it can't be
> > > interrupted and no intermediate output states are visible).
> >
> > It is only atomic if prefixed by the 'lock' prefix.
> > Normally the read and write are separate bus cycles.
>
> The essential point is that x86 has atomic bit ops and byte writes.
> Early alpha did not.
Early alpha didn't have any byte accesses.
On x86 if you have the following:
struct {
char a;
volatile char b;
} *foo;
foo->a |= 4;
The compiler is likely to generate a 'bis #4, 0(rbx)' (or similar)
and the cpu will do two 32bit memory cycles that read and write
the 'volatile' field 'b'.
(gcc definitely used to do this...)
A lot of fields were made 32bit (and probably not bitfields) in the linux
kernel tree a year or two ago to avoid this very problem.
> > > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> > >
> > > I don't understand this comment. You seem to be implying gcc would do a
> > > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > > instruction exists to perform the operation on all architectures.
> >
> > Read the object code and weep...
> > It is most likely to happen for operations that are rmw (eg bit set).
> > For instance the arm cpu has limited offsets for 16bit accesses, for
> > normal structures the compiler is likely to use a 32bit rmw sequence
> > for a 16bit field that has a large offset.
> > The C language allows the compiler to do it for any access (IIRC including
> > volatiles).
>
> I think you might be confusing different things. Most RISC CPUs can't
> do 32 bit store immediates because there aren't enough bits in their
> arsenal, so they tend to split 32 bit loads into a left and right part
> (first the top then the offset). This (and other things) are mostly
> what you see in code. However, 32 bit register stores are still atomic,
> which is all we require. It's not really the compiler's fault, it's
> mostly an architectural limitation.
No, I'm not talking about how 32bit constants are generated.
I'm talking about structure offsets.
David
N‹§²æìr¸›zǧu©ž²Æ {\b†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ
^ permalink raw reply [flat|nested] 135+ messages in thread
* RE: [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:31 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 15:31 UTC (permalink / raw)
To: 'James Bottomley'
Cc: 'Rafael J. Wysocki',
Viresh Kumar, Johannes Berg, Greg Kroah-Hartman,
Linaro Kernel Mailman List, QCA ath9k Development,
Intel Linux Wireless, linux-doc, Linux Kernel Mailing List,
linux-arm-kernel, Linux ACPI, open list:BLUETOOTH DRIVERS,
open list:AMD IOMMU (AMD-VI),
netdev, open list:NETWORKING DRIVERS (WIRELESS),
open list:TARGET SUBSYSTEM,
open list:ULTRA-WIDEBAND (UWB) SUBSYSTEM:,
open list:EDAC-CORE, Linux Memory Management List,
moderated list:SOUND - SOC LAYER / DYNAMIC AUDIO POWER MANAGEM...
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2580 bytes --]
From: James Bottomley
> Sent: 28 September 2015 16:12
> > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> > >
> > > That's different: it's an atomic RMW operation. The problem with the
> > > alpha was that the operation wasn't atomic (meaning that it can't be
> > > interrupted and no intermediate output states are visible).
> >
> > It is only atomic if prefixed by the 'lock' prefix.
> > Normally the read and write are separate bus cycles.
>
> The essential point is that x86 has atomic bit ops and byte writes.
> Early alpha did not.
Early alpha didn't have any byte accesses.
On x86 if you have the following:
struct {
char a;
volatile char b;
} *foo;
foo->a |= 4;
The compiler is likely to generate a 'bis #4, 0(rbx)' (or similar)
and the cpu will do two 32bit memory cycles that read and write
the 'volatile' field 'b'.
(gcc definitely used to do this...)
A lot of fields were made 32bit (and probably not bitfields) in the linux
kernel tree a year or two ago to avoid this very problem.
> > > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> > >
> > > I don't understand this comment. You seem to be implying gcc would do a
> > > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > > instruction exists to perform the operation on all architectures.
> >
> > Read the object code and weep...
> > It is most likely to happen for operations that are rmw (eg bit set).
> > For instance the arm cpu has limited offsets for 16bit accesses, for
> > normal structures the compiler is likely to use a 32bit rmw sequence
> > for a 16bit field that has a large offset.
> > The C language allows the compiler to do it for any access (IIRC including
> > volatiles).
>
> I think you might be confusing different things. Most RISC CPUs can't
> do 32 bit store immediates because there aren't enough bits in their
> arsenal, so they tend to split 32 bit loads into a left and right part
> (first the top then the offset). This (and other things) are mostly
> what you see in code. However, 32 bit register stores are still atomic,
> which is all we require. It's not really the compiler's fault, it's
> mostly an architectural limitation.
No, I'm not talking about how 32bit constants are generated.
I'm talking about structure offsets.
David
N‹§²æìr¸›zǧu©ž²Æ {\b†éì¹»\x1c®&Þ–)îÆi¢žØ^n‡r¶‰šŽŠÝ¢j$½§$¢¸\x05¢¹¨è§~Š'.)îÄÃ,yèm¶ŸÿÃ\f%Š{±šj+ƒðèž×¦j)Z†·Ÿ
^ permalink raw reply [flat|nested] 135+ messages in thread
* [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock'
@ 2015-09-28 15:31 ` David Laight
0 siblings, 0 replies; 135+ messages in thread
From: David Laight @ 2015-09-28 15:31 UTC (permalink / raw)
To: linux-arm-kernel
From: James Bottomley
> Sent: 28 September 2015 16:12
> > > > The x86 cpus will also do 32bit wide rmw cycles for the 'bit' operations.
> > >
> > > That's different: it's an atomic RMW operation. The problem with the
> > > alpha was that the operation wasn't atomic (meaning that it can't be
> > > interrupted and no intermediate output states are visible).
> >
> > It is only atomic if prefixed by the 'lock' prefix.
> > Normally the read and write are separate bus cycles.
>
> The essential point is that x86 has atomic bit ops and byte writes.
> Early alpha did not.
Early alpha didn't have any byte accesses.
On x86 if you have the following:
struct {
char a;
volatile char b;
} *foo;
foo->a |= 4;
The compiler is likely to generate a 'bis #4, 0(rbx)' (or similar)
and the cpu will do two 32bit memory cycles that read and write
the 'volatile' field 'b'.
(gcc definitely used to do this...)
A lot of fields were made 32bit (and probably not bitfields) in the linux
kernel tree a year or two ago to avoid this very problem.
> > > > You still have to ensure the compiler doesn't do wider rmw cycles.
> > > > I believe the recent versions of gcc won't do wider accesses for volatile data.
> > >
> > > I don't understand this comment. You seem to be implying gcc would do a
> > > 64 bit RMW for a 32 bit store ... that would be daft when a single
> > > instruction exists to perform the operation on all architectures.
> >
> > Read the object code and weep...
> > It is most likely to happen for operations that are rmw (eg bit set).
> > For instance the arm cpu has limited offsets for 16bit accesses, for
> > normal structures the compiler is likely to use a 32bit rmw sequence
> > for a 16bit field that has a large offset.
> > The C language allows the compiler to do it for any access (IIRC including
> > volatiles).
>
> I think you might be confusing different things. Most RISC CPUs can't
> do 32 bit store immediates because there aren't enough bits in their
> arsenal, so they tend to split 32 bit loads into a left and right part
> (first the top then the offset). This (and other things) are mostly
> what you see in code. However, 32 bit register stores are still atomic,
> which is all we require. It's not really the compiler's fault, it's
> mostly an architectural limitation.
No, I'm not talking about how 32bit constants are generated.
I'm talking about structure offsets.
David
^ permalink raw reply [flat|nested] 135+ messages in thread
end of thread, other threads:[~2015-09-28 15:32 UTC | newest]
Thread overview: 135+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-09-25 16:41 [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Viresh Kumar
2015-09-25 16:41 ` Viresh Kumar
2015-09-25 16:41 ` Viresh Kumar
2015-09-25 16:41 ` Viresh Kumar
2015-09-25 16:41 ` [PATCH V4 2/2] debugfs: Pass bool pointer to debugfs_create_bool() Viresh Kumar
2015-09-25 16:41 ` Viresh Kumar
2015-09-25 16:41 ` Viresh Kumar
2015-09-25 17:42 ` [PATCH V4 1/2] ACPI / EC: Fix broken 64bit big-endian users of 'global_lock' Johannes Berg
2015-09-25 17:42 ` Johannes Berg
2015-09-25 17:42 ` Johannes Berg
2015-09-25 17:42 ` Johannes Berg
2015-09-25 18:47 ` Viresh Kumar
2015-09-25 18:47 ` Viresh Kumar
2015-09-25 18:47 ` Viresh Kumar
2015-09-25 18:47 ` Viresh Kumar
2015-09-25 18:49 ` Johannes Berg
2015-09-25 18:49 ` Johannes Berg
2015-09-25 18:49 ` Johannes Berg
2015-09-25 18:52 ` Viresh Kumar
2015-09-25 18:52 ` Viresh Kumar
2015-09-25 18:52 ` Viresh Kumar
2015-09-25 18:52 ` Viresh Kumar
2015-09-25 20:26 ` Rafael J. Wysocki
2015-09-25 20:26 ` Rafael J. Wysocki
2015-09-25 20:26 ` Rafael J. Wysocki
2015-09-25 20:33 ` Rafael J. Wysocki
2015-09-25 20:33 ` Rafael J. Wysocki
2015-09-25 20:33 ` Rafael J. Wysocki
2015-09-25 20:33 ` Rafael J. Wysocki
2015-09-25 20:25 ` Viresh Kumar
2015-09-25 20:25 ` Viresh Kumar
2015-09-25 20:25 ` Viresh Kumar
2015-09-25 20:25 ` Viresh Kumar
2015-09-25 20:25 ` Viresh Kumar
2015-09-25 20:25 ` Viresh Kumar
2015-09-25 20:58 ` Rafael J. Wysocki
2015-09-25 20:58 ` Rafael J. Wysocki
2015-09-25 20:58 ` Rafael J. Wysocki
2015-09-25 20:58 ` Rafael J. Wysocki
2015-09-25 20:58 ` Rafael J. Wysocki
2015-09-25 20:58 ` Rafael J. Wysocki
2015-09-25 21:44 ` Viresh Kumar
2015-09-25 21:44 ` Viresh Kumar
2015-09-25 21:44 ` Viresh Kumar
2015-09-25 21:44 ` Viresh Kumar
2015-09-25 21:44 ` Viresh Kumar
2015-09-25 21:44 ` Viresh Kumar
2015-09-25 22:19 ` Rafael J. Wysocki
2015-09-25 22:19 ` Rafael J. Wysocki
2015-09-25 22:19 ` Rafael J. Wysocki
2015-09-25 22:19 ` Rafael J. Wysocki
2015-09-25 22:19 ` Rafael J. Wysocki
2015-09-26 18:40 ` Viresh Kumar
2015-09-26 18:40 ` Viresh Kumar
2015-09-26 18:40 ` Viresh Kumar
2015-09-26 18:40 ` Viresh Kumar
2015-09-26 18:40 ` Viresh Kumar
2015-09-26 18:40 ` Viresh Kumar
2015-09-26 19:33 ` Arnd Bergmann
2015-09-26 19:33 ` Arnd Bergmann
2015-09-26 19:33 ` Arnd Bergmann
2015-09-26 19:33 ` Arnd Bergmann
2015-09-26 19:33 ` Arnd Bergmann
2015-09-27 14:10 ` Rafael J. Wysocki
2015-09-27 14:10 ` Rafael J. Wysocki
2015-09-27 14:10 ` Rafael J. Wysocki
2015-09-27 14:10 ` Rafael J. Wysocki
2015-09-27 14:10 ` Rafael J. Wysocki
2015-09-27 14:10 ` Rafael J. Wysocki
2015-09-28 8:24 ` Arnd Bergmann
2015-09-28 8:24 ` Arnd Bergmann
2015-09-28 8:24 ` Arnd Bergmann
2015-09-28 8:24 ` Arnd Bergmann
2015-09-28 8:24 ` Arnd Bergmann
2015-09-28 8:24 ` Arnd Bergmann
2015-09-28 13:07 ` Rafael J. Wysocki
2015-09-28 13:07 ` Rafael J. Wysocki
2015-09-28 13:07 ` Rafael J. Wysocki
2015-09-28 13:07 ` Rafael J. Wysocki
2015-09-28 13:07 ` Rafael J. Wysocki
2015-09-28 13:07 ` Rafael J. Wysocki
2015-09-26 19:52 ` James Bottomley
2015-09-26 19:52 ` James Bottomley
2015-09-26 19:52 ` James Bottomley
2015-09-26 19:52 ` James Bottomley
2015-09-26 19:52 ` James Bottomley
2015-09-26 19:52 ` James Bottomley
2015-09-27 14:09 ` Rafael J. Wysocki
2015-09-27 14:09 ` Rafael J. Wysocki
2015-09-27 14:09 ` Rafael J. Wysocki
2015-09-27 14:09 ` Rafael J. Wysocki
2015-09-27 14:09 ` Rafael J. Wysocki
2015-09-28 8:58 ` David Laight
2015-09-28 8:58 ` David Laight
2015-09-28 8:58 ` David Laight
2015-09-28 8:58 ` David Laight
2015-09-28 8:58 ` David Laight
2015-09-28 8:58 ` David Laight
2015-09-28 14:26 ` James Bottomley
2015-09-28 14:26 ` James Bottomley
2015-09-28 14:26 ` James Bottomley
2015-09-28 14:26 ` James Bottomley
2015-09-28 14:26 ` James Bottomley
2015-09-28 14:26 ` James Bottomley
2015-09-28 14:50 ` David Laight
2015-09-28 14:50 ` David Laight
2015-09-28 14:50 ` David Laight
2015-09-28 14:50 ` David Laight
2015-09-28 14:50 ` David Laight
2015-09-28 14:50 ` David Laight
2015-09-28 15:11 ` James Bottomley
2015-09-28 15:11 ` James Bottomley
2015-09-28 15:11 ` James Bottomley
2015-09-28 15:11 ` James Bottomley
2015-09-28 15:11 ` James Bottomley
2015-09-28 15:11 ` James Bottomley
2015-09-28 15:31 ` David Laight
2015-09-28 15:31 ` David Laight
2015-09-28 15:31 ` David Laight
2015-09-28 15:31 ` David Laight
2015-09-28 15:31 ` David Laight
2015-09-28 15:31 ` David Laight
2015-09-25 20:18 ` Rafael J. Wysocki
2015-09-25 20:18 ` Rafael J. Wysocki
2015-09-25 20:18 ` Rafael J. Wysocki
2015-09-25 20:22 ` Rafael J. Wysocki
2015-09-25 20:22 ` Rafael J. Wysocki
2015-09-25 20:22 ` Rafael J. Wysocki
2015-09-27 5:31 ` Jiri Slaby
2015-09-27 14:35 ` Viresh Kumar
2015-09-27 14:35 ` Viresh Kumar
2015-09-27 14:35 ` Viresh Kumar
2015-09-27 14:35 ` Viresh Kumar
2015-09-27 14:35 ` Viresh Kumar
2015-09-27 14:35 ` Viresh Kumar
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.