Re: [RFC PATCH 1/5] mm: print more information about mapping in __dump_page
On Fri 23-11-18 16:04:04, Andrew Morton wrote:
> On Wed, 7 Nov 2018 11:18:26 +0100 Michal Hocko wrote:
>
> > From: Michal Hocko
> >
> > __dump_page prints the mapping pointer but that is quite unhelpful
> > for many reports because the pointer itself only helps to distinguish
> > anon/ksm mappings from other ones (because of lowest bits
> > set). Sometimes it would be much more helpful to know what kind of
> > mapping that is actually and if we know this is a file mapping then also
> > try to resolve the dentry name.
> >
> > ...
> >
> > --- a/mm/debug.c
> > +++ b/mm/debug.c
> >
> > ...
> >
> > @@ -70,6 +71,18 @@ void __dump_page(struct page *page, const char *reason)
> > if (PageCompound(page))
> > pr_cont(" compound_mapcount: %d", compound_mapcount(page));
> > pr_cont("\n");
> > + if (PageAnon(page))
> > + pr_emerg("anon ");
> > + else if (PageKsm(page))
> > + pr_emerg("ksm ");
> > + else if (mapping) {
> > + pr_emerg("%ps ", mapping->a_ops);
> > + if (mapping->host->i_dentry.first) {
> > + struct dentry *dentry;
> > + dentry = container_of(mapping->host->i_dentry.first,
> > struct dentry, d_u.d_alias);
> > + pr_emerg("name:\"%*s\" ", dentry->d_name.len,
> > dentry->d_name.name);
> > + }
> > + }
>
> There has to be a better way of printing the filename. It is so often
> needed.
>
> The (poorly named and gleefully undocumented)
> take_dentry_name_snapshot() looks promising. However it's unclear that
> __dump_page() is always called from contexts where
> take_dentry_name_snapshot() and release_dentry_name_snapshot() can be
> safely called. Probably it's OK, but how to guarantee it?
http://lkml.kernel.org/r/20181125080834.gb12...@dhcp22.suse.cz as
suggested by Tetsuo?
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sat, 24 Nov 2018 23:14:13 +0100
Tomasz Duszynski wrote:
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, two modifiers are introduced used for distinguishing
> between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> IIO_MOD_PM10 and IIO_MOD_PM2p5.
I initially wondered why these particular numbers and why don't
we provide an attribute specify this separately?
However google suggests these two are pretty much the only
ones anyone worries about in pollution sensors. I ended
up fairly quickly at the EPA website
https://www.epa.gov/pm-pollution/table-historical-particulate-matter-pm-national-ambient-air-quality-standards-naaqs
which tells me these two have be used since about 1987.
So I think the modifier route is the right approach here
(I think we've gotten this wrong in the past such as light
sensor colours where the list keeps on growing).
I would like a reference or two in the docs though to point
people to these definitions.
Thanks,
Jonathan
>
> Signed-off-by: Tomasz Duszynski
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> drivers/iio/industrialio-core.c | 3 +++
> include/uapi/linux/iio/types.h | 3 +++
> tools/iio/iio_event_monitor.c | 6 ++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ce0ed140660d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> Contact: linux-...@vger.kernel.org
> Description:
> Raw (unscaled) phase difference reading from channel Y
> - that can be processed to radians.
> \ No newline at end of file
> + that can be processed to radians.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Mass concentration reading of particulate matter in ug / m3.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..2a9ef600c1fb 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..465044b42af5 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> + IIO_MASSCONCENTRATION,
> };
>
> enum iio_modifier {
> @@ -87,6 +88,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> + IIO_MOD_PM2p5,
> + IIO_MOD_PM10,
> };
>
> enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f0fcfeddba2b 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_ev_type_text[] = {
> @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> static bool event_is_known(struct iio_event_data *event)
> @@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_GRAVITY:
> case IIO_PO
Re: [PATCH 2/3] iio: chemical: add support for Sensirion SPS30 sensor
On Sat, 24 Nov 2018 23:14:14 +0100
Tomasz Duszynski wrote:
> Add support for Sensirion SPS30 particulate matter sensor.
>
> Signed-off-by: Tomasz Duszynski
A few things inline.
I'm particularly curious as to why we are ignoring two of the particle
sizes that the sensor seems to capture?
Also, a 'potential' race in remove that I'd like us to make
'obviously' correct rather than requiring hard thought on whether
it would be a problem.
Thanks,
Jonathan
> ---
> drivers/iio/chemical/Kconfig | 11 ++
> drivers/iio/chemical/Makefile | 1 +
> drivers/iio/chemical/sps30.c | 359 ++
> 3 files changed, 371 insertions(+)
> create mode 100644 drivers/iio/chemical/sps30.c
>
> diff --git a/drivers/iio/chemical/Kconfig b/drivers/iio/chemical/Kconfig
> index b8e005be4f87..40057ecf8130 100644
> --- a/drivers/iio/chemical/Kconfig
> +++ b/drivers/iio/chemical/Kconfig
> @@ -61,6 +61,17 @@ config IAQCORE
> iAQ-Core Continuous/Pulsed VOC (Volatile Organic Compounds)
> sensors
>
> +config SPS30
> + tristate "SPS30 Particulate Matter sensor"
> + depends on I2C
> + select CRC8
> + help
> + Say Y here to build support for the Sensirion SPS30 Particulate
> + Matter sensor.
> +
> + To compile this driver as a module, choose M here: the module will
> + be called sps30.
> +
> config VZ89X
> tristate "SGX Sensortech MiCS VZ89X VOC sensor"
> depends on I2C
> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
> index 2f4c4ba4d781..9f42f4252151 100644
> --- a/drivers/iio/chemical/Makefile
> +++ b/drivers/iio/chemical/Makefile
> @@ -9,4 +9,5 @@ obj-$(CONFIG_BME680_I2C) += bme680_i2c.o
> obj-$(CONFIG_BME680_SPI) += bme680_spi.o
> obj-$(CONFIG_CCS811) += ccs811.o
> obj-$(CONFIG_IAQCORE)+= ams-iaq-core.o
> +obj-$(CONFIG_SPS30) += sps30.o
> obj-$(CONFIG_VZ89X) += vz89x.o
> diff --git a/drivers/iio/chemical/sps30.c b/drivers/iio/chemical/sps30.c
> new file mode 100644
> index ..bf802621ae7f
> --- /dev/null
> +++ b/drivers/iio/chemical/sps30.c
> @@ -0,0 +1,359 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Sensirion SPS30 Particulate Matter sensor driver
> + *
> + * Copyright (c) Tomasz Duszynski
> + *
> + * I2C slave address: 0x69
> + *
> + * TODO:
> + * - support for turning on fan cleaning
> + * - support for reading/setting auto cleaning interval
> + */
> +
> +#define pr_fmt(fmt) "sps30: " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SPS30_CRC8_POLYNOMIAL 0x31
> +
> +/* SPS30 commands */
> +#define SPS30_START_MEAS 0x0010
> +#define SPS30_STOP_MEAS 0x0104
> +#define SPS30_RESET 0xd304
> +#define SPS30_READ_DATA_READY_FLAG 0x0202
> +#define SPS30_READ_DATA 0x0300
> +#define SPS30_READ_SERIAL 0xD033
> +
> +#define SPS30_CHAN(_index, _mod) { \
> + .type = IIO_MASSCONCENTRATION, \
> + .modified = 1, \
> + .channel2 = IIO_MOD_ ## _mod, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED), \
> + .scan_index = _index, \
> + .scan_type = { \
> + .sign = 'u', \
> + .realbits = 12, \
> + .storagebits = 32, \
That is unusual. Why do we need 32 bits to store a 12 bit value?
16 should be plenty. It'll make a difference to the buffer
sizes if people just want to stream data and don't care about
timestamps as it'll halve the memory usage.
Also, convention has always been to got for next 8,16,32,64 above
the realbits if there isn't a reason not to (shifting etc)
How did we end up with 12 bits off the floating point conversion
anyway? Needs some docs.
> + .endianness = IIO_CPU, \
> + }, \
> +}
> +
> +enum {
> + PM1p0, /* just a placeholder */
> + PM2p5,
> + PM4p0, /* just a placeholder */
> + PM10,
> +};
> +
> +struct sps30_state {
> + struct i2c_client *client;
> + /* guards against concurrent access to sensor registers */
> + struct mutex lock;
> +};
> +
> +DECLARE_CRC8_TABLE(sps30_crc8_table);
> +
I think you are fine locking wise, but it would be good to add a note
on what locks are expected to be held on entering this function.
Without locks it's obviously very racey!
> +static int sps30_write_then_read(struct sps30_state *state, u8 *buf,
> + int buf_size, u8 *data, int data_size)
> +{
> + /* every two received data bytes are checksummed */
> + u8 tmp[data_size + data_size / 2];
> + int ret, i;
> +
> + /*
> + * Sensor does not support repeated start so instead of
> + * sending two i2c messages in a row we just send one by one.
> + */
> + ret = i2c_master_send(state->client, buf, buf_size);
> + if (ret != buf_size)
> + return ret < 0 ? ret : -EIO;
> +
> + if (!data)
> + return 0;
> +
> + ret = i2c_master_recv(state->client, tmp, sizeof(tmp));
> +
Re: [PATCH 3/3] iio: chemical: sps30: add device tree support
On Sat, 24 Nov 2018 23:14:15 +0100
Tomasz Duszynski wrote:
> Add device tree support for Sensirion SPS30 particulate
> matter sensor.
>
> Signed-off-by: Tomasz Duszynski
one comment inine, around the fact we are trying to move
to generic names in DT where ever possible. Now we don't
have a suitable one (IIRC) yet so time to make one up ;)
+CC Rob for his input on that.
> ---
> .../bindings/iio/chemical/sensirion,sps30.txt| 12
> 1 file changed, 12 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
>
> diff --git
> a/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
> b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
> new file mode 100644
> index ..6eee2709b5b6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.txt
> @@ -0,0 +1,12 @@
> +* Sensirion SPS30 particulate matter sensor
> +
> +Required properties:
> +- compatible: must be "sensirion,sps30"
> +- reg: the I2C address of the sensor
> +
> +Example:
> +
> +sps30@69 {
We should define a generic type. Rob, what would work for this
one?
particlesensor@69?
> + compatible = "sensirion,sps30";
> + reg = <0x69>;
> +};
For your Perusal
Dearest , Its really good to see your Prompt Response it show how Responsible and diligent you will be in handling the sum of $10.5 MILLION if placed in your care and for investment Purposes in your Country . These said Funds have being placed in Safekeeping in DEUTSCHE BANK in SOUTH AFRICA for long, under these very noble Transaction all you have to do is open an escrow and Offshore Non Resident account with the Bank online and I would instruct my Account Officer to credit your Account with the said $10.5 Million. After which you can then transfer by your self via your online details to your Designated Account in your Country. All the same send to me all details below: 1.Full Names. 2. Detailed Residential and Official Addresses. 3.Occupation. 4.Age. 5. Direct Cell Phone and Landline numbers . Looking forward to good and fruitful working Relationship and my regards to your FAMILY. Regards John William
RFC: script to convert vsprintf uses of %pf to %ps and %pF to %pS
commit 04b8eb7a4ccd ("symbol lookup: introduce dereference_symbol_descriptor()}"
deprecated vsprintf extension %pf and %pF.
There are approximately these total uses of the symbolic
lookup vsprintf extensions %p[SsFf]:
$ git grep '".*[^%]%p[SsFf]' | \
grep -oh '%p[SsFf]' | sort | uniq -c | sort -rn
231 %pS
65 %ps
60 %pf
47 %pF
which is about a 3:1 ratio favoring %pS
so a script to convert all the %pf uses to %ps and %pF uses to %pS
could be useful.
There are a few files that appear should not be converted.
$ git grep -w --name-only -i '%pf'| \
grep -vP '^(?:Documentation|tools|include/linux/freezer.h)'| \
xargs sed -i -e 's/%pf/%ps/g' -e 's/%pF/%pS/g'
If that script above is run, it leaves the following patch
to be applied:
---
Documentation/core-api/printk-formats.rst | 10 --
lib/vsprintf.c| 12 ++--
2 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/Documentation/core-api/printk-formats.rst
b/Documentation/core-api/printk-formats.rst
index ff48b55040ef..ab5a6d1b05c0 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -70,8 +70,6 @@ Symbols/Function Pointers
%pS versatile_init+0x0/0x110
%ps versatile_init
- %pF versatile_init+0x0/0x110
- %pf versatile_init
%pSRversatile_init+0x9/0x110
(with __builtin_extract_return_addr() translation)
%pB prev_fn_of_versatile_init+0x88/0x88
@@ -81,14 +79,6 @@ The ``S`` and ``s`` specifiers are used for printing a
pointer in symbolic
format. They result in the symbol name with (S) or without (s)
offsets. If KALLSYMS are disabled then the symbol address is printed instead.
-Note, that the ``F`` and ``f`` specifiers are identical to ``S`` (``s``)
-and thus deprecated. We have ``F`` and ``f`` because on ia64, ppc64 and
-parisc64 function pointers are indirect and, in fact, are function
-descriptors, which require additional dereferencing before we can lookup
-the symbol. As of now, ``S`` and ``s`` perform dereferencing on those
-platforms (when needed), so ``F`` and ``f`` exist for compatibility
-reasons only.
-
The ``B`` specifier results in the symbol name with offsets and should be
used when printing stack backtraces. The specifier takes into
consideration the effect of compiler optimisations which may occur
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 37a54a6dd594..393002bf5298 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -795,7 +795,7 @@ char *symbol_string(char *buf, char *end, void *ptr,
#ifdef CONFIG_KALLSYMS
if (*fmt == 'B')
sprint_backtrace(sym, value);
- else if (*fmt != 'f' && *fmt != 's')
+ else if (*fmt != 's')
sprint_symbol(sym, value);
else
sprint_symbol_no_offset(sym, value);
@@ -1756,9 +1756,7 @@ char *device_node_string(char *buf, char *end, struct
device_node *dn,
*
* - 'S' For symbolic direct pointers (or function descriptors) with offset
* - 's' For symbolic direct pointers (or function descriptors) without offset
- * - 'F' Same as 'S'
- * - 'f' Same as 's'
- * - '[FfSs]R' as above with __builtin_extract_return_addr() translation
+ * - '[Ss]R' as above with __builtin_extract_return_addr() translation
* - 'B' For backtraced symbolic direct pointers with offset
* - 'R' For decoded struct resource, e.g., [mem 0x0-0x1f 64bit pref]
* - 'r' For raw struct resource, e.g., [mem 0x0-0x1f flags 0x201]
@@ -1872,8 +1870,6 @@ char *pointer(const char *fmt, char *buf, char *end, void
*ptr,
}
switch (*fmt) {
- case 'F':
- case 'f':
case 'S':
case 's':
ptr = dereference_symbol_descriptor(ptr);
@@ -2603,8 +2599,6 @@ int vbin_printf(u32 *bin_buf, size_t size, const char
*fmt, va_list args)
/* Dereference of functions is still OK */
case 'S':
case 's':
- case 'F':
- case 'f':
case 'x':
case 'K':
save_arg(void *);
@@ -2779,8 +2773,6 @@ int bstr_printf(char *buf, size_t size, const char *fmt,
const u32 *bin_buf)
switch (*fmt) {
case 'S':
case 's':
- case 'F':
- case 'f':
case 'x':
case 'K':
process = true;
---
[PATCH] staging: pi433: fix potential null dereference
Add a test for successful call to cdev_alloc() to avoid
potential null dereference. Issue reported by smatch.
Signed-off-by: Michael Straube
---
drivers/staging/pi433/pi433_if.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index 786478671190..d72de2105053 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -1245,6 +1245,10 @@ static int pi433_probe(struct spi_device *spi)
/* create cdev */
device->cdev = cdev_alloc();
+ if (!device->cdev) {
+ dev_dbg(device->dev, "allocation of cdev failed");
+ goto cdev_failed;
+ }
device->cdev->owner = THIS_MODULE;
cdev_init(device->cdev, &pi433_fops);
retval = cdev_add(device->cdev, device->devt, 1);
--
2.19.2
[PATCH] arm64: mm: Add spaces around + operator
Add spaces around '+' to follow kernel coding style.
Signed-off-by: Liu Xiang
---
arch/arm64/mm/mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index d1d6601..1dbd7be 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -853,7 +853,7 @@ void __set_fixmap(enum fixed_addresses idx,
set_pte(ptep, pfn_pte(phys >> PAGE_SHIFT, flags));
} else {
pte_clear(&init_mm, addr, ptep);
- flush_tlb_kernel_range(addr, addr+PAGE_SIZE);
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
}
}
--
1.9.1
[PATCH] asm-generic: Add spaces around & operator
Add spaces around '&' to follow kernel coding style. Signed-off-by: Liu Xiang --- include/asm-generic/fixmap.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/asm-generic/fixmap.h b/include/asm-generic/fixmap.h index 827e4d3..d6e8da3 100644 --- a/include/asm-generic/fixmap.h +++ b/include/asm-generic/fixmap.h @@ -18,7 +18,7 @@ #include #define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT)) -#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT) +#define __virt_to_fix(x) ((FIXADDR_TOP - ((x) & PAGE_MASK)) >> PAGE_SHIFT) #ifndef __ASSEMBLY__ /* -- 1.9.1
[PATCH] openrisc: Add spaces around & operator
Add spaces around '&' to follow kernel coding style.
Signed-off-by: Liu Xiang
---
arch/openrisc/include/asm/fixmap.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/openrisc/include/asm/fixmap.h
b/arch/openrisc/include/asm/fixmap.h
index 5a01595..75c7a77 100644
--- a/arch/openrisc/include/asm/fixmap.h
+++ b/arch/openrisc/include/asm/fixmap.h
@@ -55,7 +55,7 @@ enum fixed_addresses {
#define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT))
-#define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT)
+#define __virt_to_fix(x) ((FIXADDR_TOP - ((x) & PAGE_MASK)) >>
PAGE_SHIFT)
/*
* 'index to address' translation. If anyone tries to use the idx
--
1.9.1
Question about "regulator: core: Only count load for enabled consumers" in -next
Hi all,
I see errors like the following in linux next-20181123 when trying to
boot a mainline kernel on a LG Nexus 5 phone:
[ 14.495056] mmc1: Card stuck in wrong state! mmcblk1 card_busy_detect
status: 0xe00
[ 14.495185] mmc1: cache flush error -110
[ 14.601547] mmc1: Reset 0x1 never completed.
[ 14.601572] mmc1: sdhci: SDHCI REGISTER DUMP ===
[ 14.604882] mmc1: sdhci: Sys addr: 0x | Version: 0x3802
[ 14.611240] mmc1: sdhci: Blk size: 0x4000 | Blk cnt: 0x
[ 14.617664] mmc1: sdhci: Argument: 0x | Trn mode: 0x
[ 14.624064] mmc1: sdhci: Present: 0x01e8 | Host ctl: 0x
[ 14.630508] mmc1: sdhci: Power: 0x | Blk gap: 0x
[ 14.636930] mmc1: sdhci: Wake-up: 0x | Clock:0x0003
[ 14.643335] mmc1: sdhci: Timeout: 0x | Int stat: 0x
[ 14.649778] mmc1: sdhci: Int enab: 0x | Sig enab: 0x
[ 14.656200] mmc1: sdhci: ACmd stat: 0x | Slot int: 0x
[ 14.662606] mmc1: sdhci: Caps: 0x642dc8b2 | Caps_1: 0x8007
[ 14.669051] mmc1: sdhci: Cmd: 0x | Max curr: 0x
[ 14.675469] mmc1: sdhci: Resp[0]: 0x | Resp[1]: 0x
[ 14.681877] mmc1: sdhci: Resp[2]: 0x | Resp[3]: 0x
[ 14.688320] mmc1: sdhci: Host ctl2: 0x
[ 14.694720] mmc1: sdhci: ADMA Err: 0x | ADMA Ptr: 0x70042330
[ 14.699080] mmc1: sdhci:
I bisected the issue to the following commit:
5451781dadf8 ("regulator: core: Only count load for enabled consumers")
We have to increase the load for the sdhci in device tree in order for
the phone to boot properly. This change was made with the commit:
03864e57770a ("ARM: dts: qcom: msm8974-hammerhead: increase load on l20
for sdhci")
Is there a change that I should make in device tree to get the SD card
working again on the phone?
Thanks,
Brian
Re: [PATCH 1/3] x86: add support for Huawei WMI hotkeys.
On Wed 2018-10-31 15:19:36, Ayman Bagabas wrote: > This driver adds support for missing hotkeys on some Huawei laptops. > Currently, only Huawei Matebook X Pro is supported. The driver > recognizes the following keys: brightness keys, micmute, wlan, and > Huawei special key. The brightness keys are ignored since they work out > of the box. > > Signed-off-by: Ayman Bagabas > --- > drivers/platform/x86/Kconfig | 13 ++ > drivers/platform/x86/Makefile | 1 + > drivers/platform/x86/huawei_wmi.c | 225 ++ > 3 files changed, 239 insertions(+) > create mode 100644 drivers/platform/x86/huawei_wmi.c > > diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig > index 0c1aa6c314f5..c6813981e45c 100644 > --- a/drivers/platform/x86/Kconfig > +++ b/drivers/platform/x86/Kconfig > @@ -1229,6 +1229,19 @@ config I2C_MULTI_INSTANTIATE > To compile this driver as a module, choose M here: the module > will be called i2c-multi-instantiate. > > +config HUAWEI_LAPTOP > + tristate "Huawei WMI hotkeys driver" > + depends on ACPI > + depends on ACPI_WMI > + depends on INPUT > + select INPUT_SPARSEKMAP > + help > + This driver provides support for Huawei WMI hotkeys. > + It enables the missing keys and adds support to micmute > + led found on these laptops.q > + Supported devices are: > + - Matebook X Pro Extra q. Plus we normally say module name in Kconfig help text. See above. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH] clocksource/drivers/integrator-ap: add missing of_node_put()
On 25/11/2018 05:25, Frank Lee wrote:
> On Sun, Nov 25, 2018 at 3:49 AM Daniel Lezcano
> wrote:
>>
>> On 24/11/2018 15:58, Frank Lee wrote:
>>> On Thu, Nov 22, 2018 at 11:23 PM Yangtao Li wrote:
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
integrator_ap_timer_init_of() doesn't do that, so fix it.
Signed-off-by: Yangtao Li
---
drivers/clocksource/timer-integrator-ap.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/timer-integrator-ap.c
b/drivers/clocksource/timer-integrator-ap.c
index 76e526f58620..1f04069470bb 100644
--- a/drivers/clocksource/timer-integrator-ap.c
+++ b/drivers/clocksource/timer-integrator-ap.c
@@ -177,7 +177,7 @@ static int __init integrator_ap_timer_init_of(struct
device_node *node)
{
const char *path;
void __iomem *base;
- int err;
+ int err,rc = 0;
int irq;
struct clk *clk;
unsigned long rate;
@@ -210,26 +210,34 @@ static int __init integrator_ap_timer_init_of(struct
device_node *node)
"arm,timer-secondary", &path);
if (err) {
pr_warn("Failed to read property\n");
- return err;
+ rc = err;
+ goto out_put_pri_node;
}
sec_node = of_find_node_by_path(path);
- if (node == pri_node)
+ if (node == pri_node){
/* The primary timer lacks IRQ, use as clocksource */
- return integrator_clocksource_init(rate, base);
+ rc = integrator_clocksource_init(rate, base);
+ goto out;
+ }
if (node == sec_node) {
/* The secondary timer will drive the clock event */
irq = irq_of_parse_and_map(node, 0);
- return integrator_clockevent_init(rate, base, irq);
+ rc = integrator_clockevent_init(rate, base, irq);
+ goto out;
}
pr_info("Timer @%p unused\n", base);
clk_disable_unprepare(clk);
+out:
+ of_node_put(sec_node);
+out_put_pri_node:
+ of_node_put(pri_node);
- return 0;
+ return rc;
}
TIMER_OF_DECLARE(integrator_ap_timer, "arm,integrator-timer",
--
2.17.0
>>> Hi Daniel：
>>>
>>> How about this?
>>
>> Hi,
>>
>> I think there is a simpler fix. The pri_node and the sec_node are used
>> as an identifier to compare against the current node, we can directly
>> drop the refcount after getting the node from path as it is not used as
>> pointer. In addition, a single variable is needed, so we end up with a
>> fix like that.
>>
>> alias_node = of_find_node_by_path(path);
>> of_node_put(alias_node);
>> if (node == alias_node)
>> return integrator_clocksource_init(rate, base);
>
> Daniel,
>
> OK,I will simplify it like you said.Although I think of_node_put
> should be called
> after we don't use node.
Except I'm missing something, we don't use the alias_node at any time.
The node itself has already a refcount which gives us the guarantee it
is valid.
I agree it can appear a bit strange to put the node right after getting
it but in our case the alias_node is used as an ID, not a pointer, so it
is fine.
--
Facebook |
Twitter |
Re: [PATCH v2] clocksource/drivers/integrator-ap: add missing of_node_put()
On 25/11/2018 06:00, Yangtao Li wrote:
> of_find_node_by_path() acquires a reference to the node
> returned by it and that reference needs to be dropped by its caller.
> integrator_ap_timer_init_of() doesn't do that.The pri_node and the
> sec_node are used as an identifier to compare against the current node,
> we can directly drop the refcount after getting the node from path as
> it is not used aspointer. In addition, a single variable is needed,
> so fix it.
I can apply the patch after adding a comment in the code below or
alternatively you can resend a V3 after adding a comment yourself.
What is your preference?
> Signed-off-by: Yangtao Li
> ---
> Changes in v2:
> -update changeelog
> -simplify fix
> -change two variable to one
> ---
> drivers/clocksource/timer-integrator-ap.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/clocksource/timer-integrator-ap.c
> b/drivers/clocksource/timer-integrator-ap.c
> index 76e526f58620..bbd0977d579a 100644
> --- a/drivers/clocksource/timer-integrator-ap.c
> +++ b/drivers/clocksource/timer-integrator-ap.c
> @@ -181,8 +181,7 @@ static int __init integrator_ap_timer_init_of(struct
> device_node *node)
> int irq;
> struct clk *clk;
> unsigned long rate;
> - struct device_node *pri_node;
> - struct device_node *sec_node;
> + struct device_node *alias_node;
>
> base = of_io_request_and_map(node, 0, "integrator-timer");
> if (IS_ERR(base))
> @@ -204,7 +203,14 @@ static int __init integrator_ap_timer_init_of(struct
> device_node *node)
> return err;
> }
>
> - pri_node = of_find_node_by_path(path);
> + alias_node = of_find_node_by_path(path);
> +
> + /* Drop the refcount of node */
> + of_node_put(alias_node);
> +
> + if (node == alias_node)
> + /* The primary timer lacks IRQ, use as clocksource */
> + return integrator_clocksource_init(rate, base);
>
> err = of_property_read_string(of_aliases,
> "arm,timer-secondary", &path);
> @@ -213,14 +219,12 @@ static int __init integrator_ap_timer_init_of(struct
> device_node *node)
> return err;
> }
>
> + alias_node = of_find_node_by_path(path);
>
> - sec_node = of_find_node_by_path(path);
> -
> - if (node == pri_node)
> - /* The primary timer lacks IRQ, use as clocksource */
> - return integrator_clocksource_init(rate, base);
> + /* Drop the refcount of node */
> + of_node_put(alias_node);
>
> - if (node == sec_node) {
> + if (node == alias_node) {
> /* The secondary timer will drive the clock event */
> irq = irq_of_parse_and_map(node, 0);
> return integrator_clockevent_init(rate, base, irq);
>
--
Facebook |
Twitter |
Re: [PATCH v2] clocksource/drivers/integrator-ap: add missing of_node_put()
On Sun, Nov 25, 2018 at 5:43 PM Daniel Lezcano
wrote:
>
> On 25/11/2018 06:00, Yangtao Li wrote:
> > of_find_node_by_path() acquires a reference to the node
> > returned by it and that reference needs to be dropped by its caller.
> > integrator_ap_timer_init_of() doesn't do that.The pri_node and the
> > sec_node are used as an identifier to compare against the current node,
> > we can directly drop the refcount after getting the node from path as
> > it is not used aspointer. In addition, a single variable is needed,
> > so fix it.
>
> I can apply the patch after adding a comment in the code below or
> alternatively you can resend a V3 after adding a comment yourself.
>
> What is your preference?
Hi Daniel:
You can add a comment in the code below,then apply the patch.
Thanks,
Yangtao
>
> > Signed-off-by: Yangtao Li
> > ---
> > Changes in v2:
> > -update changeelog
> > -simplify fix
> > -change two variable to one
> > ---
> > drivers/clocksource/timer-integrator-ap.c | 22 +-
> > 1 file changed, 13 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/clocksource/timer-integrator-ap.c
> > b/drivers/clocksource/timer-integrator-ap.c
> > index 76e526f58620..bbd0977d579a 100644
> > --- a/drivers/clocksource/timer-integrator-ap.c
> > +++ b/drivers/clocksource/timer-integrator-ap.c
> > @@ -181,8 +181,7 @@ static int __init integrator_ap_timer_init_of(struct
> > device_node *node)
> > int irq;
> > struct clk *clk;
> > unsigned long rate;
> > - struct device_node *pri_node;
> > - struct device_node *sec_node;
> > + struct device_node *alias_node;
> >
> > base = of_io_request_and_map(node, 0, "integrator-timer");
> > if (IS_ERR(base))
> > @@ -204,7 +203,14 @@ static int __init integrator_ap_timer_init_of(struct
> > device_node *node)
> > return err;
> > }
> >
> > - pri_node = of_find_node_by_path(path);
> > + alias_node = of_find_node_by_path(path);
> > +
> > + /* Drop the refcount of node */
> > + of_node_put(alias_node);
> > +
> > + if (node == alias_node)
> > + /* The primary timer lacks IRQ, use as clocksource */
> > + return integrator_clocksource_init(rate, base);
> >
> > err = of_property_read_string(of_aliases,
> > "arm,timer-secondary", &path);
> > @@ -213,14 +219,12 @@ static int __init integrator_ap_timer_init_of(struct
> > device_node *node)
> > return err;
> > }
> >
> > + alias_node = of_find_node_by_path(path);
> >
> > - sec_node = of_find_node_by_path(path);
> > -
> > - if (node == pri_node)
> > - /* The primary timer lacks IRQ, use as clocksource */
> > - return integrator_clocksource_init(rate, base);
> > + /* Drop the refcount of node */
> > + of_node_put(alias_node);
> >
> > - if (node == sec_node) {
> > + if (node == alias_node) {
> > /* The secondary timer will drive the clock event */
> > irq = irq_of_parse_and_map(node, 0);
> > return integrator_clockevent_init(rate, base, irq);
> >
>
>
> --
> Facebook |
> Twitter |
>
Re: [PATCH 00/16] x86/microcode/AMD: Improve container verification
On Wed 2018-11-07 18:02:02, Borislav Petkov wrote: > From: Borislav Petkov > > Hi all, > > this is work which got started by Maciej a while ago. I have finally had > the time to redo all the ideas properly, split it in self-contained, > logical chunks and test it. > > Reveiew and comments are appreciated. Unfortunately, this is not too useful cover letter. It does not tell us what the goals if the series are, for example :-(. Pavel > Thx. > > Borislav Petkov (11): > x86/microcode/AMD: Move verify_patch_size() up in the file > x86/microcode/AMD: Clean up per-family patch size checks > x86/microcode/AMD: Cleanup verify_patch_size() more > x86/microcode/AMD: Concentrate patch verification > x86/microcode/AMD: Simplify patch family detection > x86/microcode/AMD: Move patch family check to verify_patch() > x86/microcode/AMD: Move chipset-specific check into verify_patch() > x86/microcode/AMD: Change verify_patch()'s return value > x86/microcode/AMD: Convert early parser to the new verification routines > x86/microcode/AMD: Fix container size's type > x86/microcode/AMD: Update copyright > > Maciej S. Szmigiero (5): > x86/microcode/AMD: Subtract SECTION_HDR_SIZE from file leftover length > x86/microcode/AMD: Add microcode container verification > x86/microcode/AMD: Check microcode container data in the late loader > x86/microcode/AMD: Convert CPU equivalence table variable into a struct > x86/microcode/AMD: Check the equivalence table size when scanning it > > arch/x86/kernel/cpu/microcode/amd.c | 469 ++-- > 1 file changed, 307 insertions(+), 162 deletions(-) > -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v3 7/7] staging:iio:ad2s90: Move out of staging
On Fri, 23 Nov 2018 22:23:12 -0200
Matheus Tavares wrote:
> Move ad2s90 resolver driver out of staging to the main tree.
>
> Signed-off-by: Matheus Tavares
> Signed-off-by: Victor Colombo
Hi.
One totally trivial comment inline, but if you want to clean
that up, do it after we have moved this out of staging
(unless respinning for some other reason).
However, I would like to let this sit on the mailing list for
a little longer to let others comment and perhaps to pick up
a review of the DT binding doc (which looks fine to me, but
I am forever missing issues in those!)
Good work and I'll probably pick this up later in the week.
Thanks,
Jonathan
> ---
> Changes in v3:
> - none
>
> Changes in v2:
> - Disabled git move detection, to see the whole code, as Jonathan
> suggested
>
> drivers/iio/resolver/Kconfig | 10 ++
> drivers/iio/resolver/Makefile | 1 +
> drivers/iio/resolver/ad2s90.c | 131 ++
> drivers/staging/iio/resolver/Kconfig | 10 --
> drivers/staging/iio/resolver/Makefile | 1 -
> drivers/staging/iio/resolver/ad2s90.c | 131 --
> 6 files changed, 142 insertions(+), 142 deletions(-)
> create mode 100644 drivers/iio/resolver/ad2s90.c
> delete mode 100644 drivers/staging/iio/resolver/ad2s90.c
>
> diff --git a/drivers/iio/resolver/Kconfig b/drivers/iio/resolver/Kconfig
> index 2ced9f22aa70..786801be54f6 100644
> --- a/drivers/iio/resolver/Kconfig
> +++ b/drivers/iio/resolver/Kconfig
> @@ -3,6 +3,16 @@
> #
> menu "Resolver to digital converters"
>
> +config AD2S90
> + tristate "Analog Devices ad2s90 driver"
> + depends on SPI
> + help
> + Say yes here to build support for Analog Devices spi resolver
> + to digital converters, ad2s90, provides direct access via sysfs.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called ad2s90.
> +
> config AD2S1200
> tristate "Analog Devices ad2s1200/ad2s1205 driver"
> depends on SPI
> diff --git a/drivers/iio/resolver/Makefile b/drivers/iio/resolver/Makefile
> index 4e1dccae07e7..398d82d50028 100644
> --- a/drivers/iio/resolver/Makefile
> +++ b/drivers/iio/resolver/Makefile
> @@ -2,4 +2,5 @@
> # Makefile for Resolver/Synchro drivers
> #
>
> +obj-$(CONFIG_AD2S90) += ad2s90.o
> obj-$(CONFIG_AD2S1200) += ad2s1200.o
> diff --git a/drivers/iio/resolver/ad2s90.c b/drivers/iio/resolver/ad2s90.c
> new file mode 100644
> index ..a41f5cb10da5
> --- /dev/null
> +++ b/drivers/iio/resolver/ad2s90.c
> @@ -0,0 +1,131 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ad2s90.c simple support for the ADI Resolver to Digital Converters: AD2S90
> + *
> + * Copyright (c) 2010-2010 Analog Devices Inc.
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
We are into the truely trivial realms now - alphabetical order preferred
for includes.
> +
> +#include
> +#include
> +
> +/*
> + * Although chip's max frequency is 2Mhz, it needs 600ns between CS and the
> + * first falling edge of SCLK, so frequency should be at most 1 / (2 * 6e-7)
> + */
> +#define AD2S90_MAX_SPI_FREQ_HZ 83
> +
> +struct ad2s90_state {
> + struct mutex lock; /* lock to protect rx buffer */
> + struct spi_device *sdev;
> + u8 rx[2] cacheline_aligned;
> +};
> +
> +static int ad2s90_read_raw(struct iio_dev *indio_dev,
> +struct iio_chan_spec const *chan,
> +int *val,
> +int *val2,
> +long m)
> +{
> + int ret;
> + struct ad2s90_state *st = iio_priv(indio_dev);
> +
> + if (chan->type != IIO_ANGL)
> + return -EINVAL;
> +
> + switch (m) {
> + case IIO_CHAN_INFO_SCALE:
> + /* 2 * Pi / 2^12 */
> + *val = 6283; /* mV */
> + *val2 = 12;
> + return IIO_VAL_FRACTIONAL_LOG2;
> + case IIO_CHAN_INFO_RAW:
> + mutex_lock(&st->lock);
> + ret = spi_read(st->sdev, st->rx, 2);
> + if (ret < 0) {
> + mutex_unlock(&st->lock);
> + return ret;
> + }
> + *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >> 4);
> +
> + mutex_unlock(&st->lock);
> +
> + return IIO_VAL_INT;
> + default:
> + break;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static const struct iio_info ad2s90_info = {
> + .read_raw = ad2s90_read_raw,
> +};
> +
> +static const struct iio_chan_spec ad2s90_chan = {
> + .type = IIO_ANGL,
> + .indexed = 1,
> + .channel = 0,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
> +};
> +
> +static int ad2s90_probe(struct spi_device *spi)
> +{
> + struct iio_dev *indio_dev;
> + struct ad2s90_state *st;
> +
> + if (spi->max_speed_hz > AD2S90_MAX_SPI_FREQ_HZ) {
> + dev_err(&spi->dev,
Re: [PATCH v2] staging: iio: ad5933: add device tree support
On Sat, 24 Nov 2018 11:18:57 -0200
Marcelo Schmitt wrote:
> Add a of_device_id struct variable and subsequent call to
> MODULE_DEVICE_TABLE macro to complete device tree support.
>
> Signed-off-by: Marcelo Schmitt
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it. Note we'll need a binding
doc for this before it can leave staging.
Thanks,
Jonathan
> ---
> drivers/staging/iio/impedance-analyzer/ad5933.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index edb8b540bbf1..6faa2700dc8d 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -771,9 +771,18 @@ static const struct i2c_device_id ad5933_id[] = {
>
> MODULE_DEVICE_TABLE(i2c, ad5933_id);
>
> +static const struct of_device_id ad5933_of_match[] = {
> + { .compatible = "adi,ad5933" },
> + { .compatible = "adi,ad5934" },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, ad5933_of_match);
> +
> static struct i2c_driver ad5933_driver = {
> .driver = {
> .name = "ad5933",
> + .of_match_table = ad5933_of_match,
> },
> .probe = ad5933_probe,
> .remove = ad5933_remove,
Re: [PATCH v3 3/4] iio: adc: add STMPE ADC devicetree bindings
On Fri, 23 Nov 2018 15:24:10 +0100
Philippe Schenker wrote:
> From: Stefan Agner
>
> This adds the devicetree bindings for the STMPE ADC.
>
> Signed-off-by: Stefan Agner
> Signed-off-by: Max Krummenacher
> Signed-off-by: Philippe Schenker
Clearly this will need review from input and mfd.
I've suggested inline that you split the realignment out to a
separate patch for reviewability reasons.
> ---
>
> Changes in v3:
> - Reformatted documentation for touchscreen to use tabs and have a better
>overview of the settings.
> - Added note which adc-settings will take precedence.
> - changed typo in sample-time setting from 144 clocks to 124 clocks, as
> stated
>in the datasheet.
>
> Changes in v2:
> - Moved the bindings for ADC to the overlying mfd.
> - Reformatted for better readability
>
> .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 +++
> .../bindings/input/touchscreen/stmpe.txt | 60 ---
> .../devicetree/bindings/mfd/stmpe.txt | 28 ++---
> 3 files changed, 80 insertions(+), 29 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> new file mode 100644
> index ..480e66422625
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> @@ -0,0 +1,21 @@
> +STMPE ADC driver
> +
> +
> +Required properties:
> + - compatible: "st,stmpe-adc"
> +
> +Optional properties:
> +Note that the ADC is shared with the STMPE touchscreen. ADC related settings
> +have to be done in the mfd.
> +- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
> + requestable due to different usage (e.g. touch)
> +
> +Node name must be stmpe_adc and should be child node of stmpe node to
> +which it belongs.
> +
> +Example:
> +
> + stmpe_adc {
Can we use adc { here to match standard naming?
> + compatible = "st,stmpe-adc";
> + st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
> + };
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> index 127baa31a77a..414586513a02 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> @@ -5,36 +5,52 @@ Required properties:
> - compatible: "st,stmpe-ts"
>
> Optional properties:
> -- st,sample-time: ADC converstion time in number of clock. (0 -> 36 clocks,
> 1 ->
> - 44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96 clocks,
> 6
> - -> 144 clocks), recommended is 4.
> -- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
> -- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
> - reference)
> -- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5
> MHz)
> -- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 -> 4
> - samples, 3 -> 8 samples)
> -- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us,
> 2 ->
> - 100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms)
> recommended
> - is 3
> -- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 -> 500
> us, 3
> - -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is 2
>
> -- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) =
> Count of
> - the fractional part) recommended is 7
> -- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA
> typical 35
> - mA max, 1 -> 50 mA typical 80 mA max)
> +- st,ave-ctrl: Sample average control
> + 0 -> 1 sample
> + 1 -> 2 samples
> + 2 -> 4 samples
> + 3 -> 8 samples
> +- st,touch-det-delay : Touch detect interrupt delay (recommended is 3)
> + 0 -> 10 us 5 -> 5 ms
> + 1 -> 50 us 6 -> 10 ms
> + 2 -> 100 us 7 -> 50 ms
> + 3 -> 500 us
> + 4-> 1 ms
> +- st,settling: Panel driver settling time (recommended is 2)
> + 0 -> 10 us 5 -> 10 ms
> + 1 -> 100 us 6 for 50 ms
> + 2 -> 500 us 7 -> 100 ms
> + 3 -> 1 ms
> + 4 -> 5 ms
> +- st,fraction-z : Length of the fractional part in z
> (recommended is 7)
> + (fraction-z ([0..7]) = Count of the fractional part)
> +- st,i-drive : current limit value of the touchscreen drivers
> + 0 -> 20
Re: [PATCH v4] staging: olpc_dcon: olpc_dcon_xo_1.c: Switch to the gpio descriptor interface
Hi!
> Use the gpiod interface instead of the deprecated old non-descriptor
> interface in olpc_dcon_xo_1.c.
>
> Signed-off-by: Nishad Kamdar
You may want to cc: lkund...@v3.sk, he was doing great work on OLPC
lately...
Best regards,
Pavel
> ---
> Changes in v4:
> - Move changelog after signed-off line.
> Changes in v3:
> - Resolve a few compilation errors.
> Changes in v2:
> - Resolve a few compilation errors.
> - Add a level of indirection to read and write gpios.
> ---
> drivers/staging/olpc_dcon/olpc_dcon_xo_1.c | 90 +++---
> 1 file changed, 47 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/staging/olpc_dcon/olpc_dcon_xo_1.c
> b/drivers/staging/olpc_dcon/olpc_dcon_xo_1.c
> index ff145d493e1b..80b8d4153414 100644
> --- a/drivers/staging/olpc_dcon/olpc_dcon_xo_1.c
> +++ b/drivers/staging/olpc_dcon/olpc_dcon_xo_1.c
> @@ -11,35 +11,51 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> #include
> -#include
> +#include
> #include
> +#include
> #include
>
> #include "olpc_dcon.h"
>
> +enum dcon_gpios {
> + OLPC_DCON_STAT0,
> + OLPC_DCON_STAT1,
> + OLPC_DCON_IRQ,
> + OLPC_DCON_LOAD,
> + OLPC_DCON_BLANK,
> +};
> +
> +struct dcon_gpio {
> + const char *name;
> + unsigned long flags;
> +};
> +
> +static const struct dcon_gpio gpios_asis[] = {
> + [OLPC_DCON_STAT0] = { .name = "dcon_stat0", .flags = GPIOD_ASIS },
> + [OLPC_DCON_STAT1] = { .name = "dcon_stat1", .flags = GPIOD_ASIS },
> + [OLPC_DCON_IRQ] = { .name = "dcon_irq", .flags = GPIOD_ASIS },
> + [OLPC_DCON_LOAD] = { .name = "dcon_load", .flags = GPIOD_ASIS },
> + [OLPC_DCON_BLANK] = { .name = "dcon_blank", .flags = GPIOD_ASIS },
> +};
> +
> +struct gpio_desc *gpios[5];
> +
> static int dcon_init_xo_1(struct dcon_priv *dcon)
> {
> unsigned char lob;
> -
> - if (gpio_request(OLPC_GPIO_DCON_STAT0, "OLPC-DCON")) {
> - pr_err("failed to request STAT0 GPIO\n");
> - return -EIO;
> - }
> - if (gpio_request(OLPC_GPIO_DCON_STAT1, "OLPC-DCON")) {
> - pr_err("failed to request STAT1 GPIO\n");
> - goto err_gp_stat1;
> - }
> - if (gpio_request(OLPC_GPIO_DCON_IRQ, "OLPC-DCON")) {
> - pr_err("failed to request IRQ GPIO\n");
> - goto err_gp_irq;
> - }
> - if (gpio_request(OLPC_GPIO_DCON_LOAD, "OLPC-DCON")) {
> - pr_err("failed to request LOAD GPIO\n");
> - goto err_gp_load;
> - }
> - if (gpio_request(OLPC_GPIO_DCON_BLANK, "OLPC-DCON")) {
> - pr_err("failed to request BLANK GPIO\n");
> - goto err_gp_blank;
> + int ret, i;
> + struct dcon_gpio *pin = &gpios_asis[0];
> +
> + for (i = 0; i < ARRAY_SIZE(gpios_asis); i++) {
> + gpios[i] = devm_gpiod_get(&dcon->client->dev, pin[i].name,
> + pin[i].flags);
> + if (IS_ERR(gpios[i])) {
> + ret = PTR_ERR(gpios[i]);
> + pr_err("failed to request %s GPIO: %d\n", pin[i].name,
> +ret);
> + return ret;
> + }
> }
>
> /* Turn off the event enable for GPIO7 just to be safe */
> @@ -61,12 +77,12 @@ static int dcon_init_xo_1(struct dcon_priv *dcon)
> dcon->pending_src = dcon->curr_src;
>
> /* Set the directions for the GPIO pins */
> - gpio_direction_input(OLPC_GPIO_DCON_STAT0);
> - gpio_direction_input(OLPC_GPIO_DCON_STAT1);
> - gpio_direction_input(OLPC_GPIO_DCON_IRQ);
> - gpio_direction_input(OLPC_GPIO_DCON_BLANK);
> - gpio_direction_output(OLPC_GPIO_DCON_LOAD,
> - dcon->curr_src == DCON_SOURCE_CPU);
> + gpiod_direction_input(gpios[OLPC_DCON_STAT0]);
> + gpiod_direction_input(gpios[OLPC_DCON_STAT1]);
> + gpiod_direction_input(gpios[OLPC_DCON_IRQ]);
> + gpiod_direction_input(gpios[OLPC_DCON_BLANK]);
> + gpiod_direction_output(gpios[OLPC_DCON_LOAD],
> +dcon->curr_src == DCON_SOURCE_CPU);
>
> /* Set up the interrupt mappings */
>
> @@ -84,7 +100,7 @@ static int dcon_init_xo_1(struct dcon_priv *dcon)
> /* Register the interrupt handler */
> if (request_irq(DCON_IRQ, &dcon_interrupt, 0, "DCON", dcon)) {
> pr_err("failed to request DCON's irq\n");
> - goto err_req_irq;
> + return -EIO;
> }
>
> /* Clear INV_EN for GPIO7 (DCONIRQ) */
> @@ -125,18 +141,6 @@ static int dcon_init_xo_1(struct dcon_priv *dcon)
> cs5535_gpio_set(OLPC_GPIO_DCON_BLANK, GPIO_EVENTS_ENABLE);
>
> return 0;
> -
> -err_req_irq:
> - gpio_free(OLPC_GPIO_DCON_BLANK);
> -err_gp_blank:
> - gpio_free(OLPC_GPIO_DCON_LOAD);
> -err_gp_load:
> - gpio_free(OLPC_GPIO_DCON_IRQ);
> -err_gp_irq:
> - gpio_free(OLPC_GPIO_DCON_STAT1);
> -err_gp_stat1:
> - gpio_free(OLPC_GPI
Re: [PATCH v3 2/4] iio: adc: add STMPE ADC driver using IIO framework
On Fri, 23 Nov 2018 15:24:09 +0100 Philippe Schenker wrote: > From: Stefan Agner > > This adds an ADC driver for the STMPE device using the industrial > input/output interface. The driver supports raw reading of values. > The driver depends on the MFD STMPE driver. If the touchscreen > block is enabled too, only four of the 8 ADC channels are available. > > Signed-off-by: Stefan Agner > Signed-off-by: Max Krummenacher > Signed-off-by: Philippe Schenker Given the dt related refactoring in here is mixed up somewhat with the ADC driver, I would like to see that as a precursor patch. Another area that I think needs a rethink is balance between enable and disable. The enable is in the mfd call, but the disable in the iio driver remove which isn't right. Not immediately sure what we do about that, but it should be one or the other. I'd previously missed your use of the IIO core mlock. Please don't use that in a driver directly. It has very carefully defined locking semantics which aren't even in use here. A locally defined lock with well documented scope is much better. We 'used' to abuse mlock for this and have spent years slowly unwinding that. Thanks, Jonathan > --- > > Changes in v3: > - Undo ADC-settings related code-deletions in stmpe-ts.c that the code is >backwards-compatible to older devicetrees. > > Changes in v2: > - Code formatting > - Move code to setup ADC to MFD device, as it is used by both drivers >adc and touchscreen > - Removed unused includes > - Defined the macro STMPE_START_ONE_TEMP_CONV with other macros. > - Added new macro that defines the channel of the temperature sensor. >Took new name for STMPE_MAX_ADC->STMPE_ADC_LAST_NR and used it throughout >the code for better readability. > - Added mutex_unlock where missing. > > drivers/iio/adc/Kconfig | 7 + > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/stmpe-adc.c | 326 +++ > drivers/input/touchscreen/stmpe-ts.c | 36 +-- > drivers/mfd/Kconfig | 3 +- > drivers/mfd/stmpe.c | 81 +++ > include/linux/mfd/stmpe.h| 9 + > 7 files changed, 437 insertions(+), 26 deletions(-) > create mode 100644 drivers/iio/adc/stmpe-adc.c > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index a52fea8749a9..224f2067494d 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -734,6 +734,13 @@ config STM32_DFSDM_ADC > This driver can also be built as a module. If so, the module > will be called stm32-dfsdm-adc. > > +config STMPE_ADC > + tristate "STMicroelectronics STMPE ADC driver" > + depends on OF && MFD_STMPE > + help > + Say yes here to build support for ST Microelectronics STMPE > + built-in ADC block (stmpe811). > + > config STX104 > tristate "Apex Embedded Systems STX104 driver" > depends on PC104 && X86 > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > index a6e6a0b659e2..cba889c30bf9 100644 > --- a/drivers/iio/adc/Makefile > +++ b/drivers/iio/adc/Makefile > @@ -69,6 +69,7 @@ obj-$(CONFIG_STM32_ADC_CORE) += stm32-adc-core.o > obj-$(CONFIG_STM32_ADC) += stm32-adc.o > obj-$(CONFIG_STM32_DFSDM_CORE) += stm32-dfsdm-core.o > obj-$(CONFIG_STM32_DFSDM_ADC) += stm32-dfsdm-adc.o > +obj-$(CONFIG_STMPE_ADC) += stmpe-adc.o > obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o > obj-$(CONFIG_TI_ADC0832) += ti-adc0832.o > obj-$(CONFIG_TI_ADC084S021) += ti-adc084s021.o > diff --git a/drivers/iio/adc/stmpe-adc.c b/drivers/iio/adc/stmpe-adc.c > new file mode 100644 > index ..bea3f3c27bb5 > --- /dev/null > +++ b/drivers/iio/adc/stmpe-adc.c > @@ -0,0 +1,326 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * STMicroelectronics STMPE811 IIO ADC Driver > + * > + * 4 channel, 10/12-bit ADC > + * > + * Copyright (C) 2013-2018 Toradex AG > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#define STMPE_REG_INT_STA0x0B > +#define STMPE_REG_ADC_INT_EN 0x0E > +#define STMPE_REG_ADC_INT_STA0x0F > + > +#define STMPE_REG_ADC_CTRL1 0x20 > +#define STMPE_REG_ADC_CTRL2 0x21 > +#define STMPE_REG_ADC_CAPT 0x22 > +#define STMPE_REG_ADC_DATA_CH(channel) (0x30 + 2 * (channel)) > + > +#define STMPE_REG_TEMP_CTRL 0x60 > +#define STMPE_TEMP_CTRL_ENABLE BIT(0) > +#define STMPE_TEMP_CTRL_ACQ BIT(1) > +#define STMPE_TEMP_CTRL_THRES_EN BIT(3) > +#define STMPE_START_ONE_TEMP_CONV(STMPE_TEMP_CTRL_ENABLE | \ > + STMPE_TEMP_CTRL_ACQ | \ > + STMPE_TEMP_CTRL_THRES_EN) > +#define STMPE_REG_TEMP_DATA 0x61 > +#define STMPE_REG_TEMP_TH0x63 > +#define STMPE_ADC_LAST_NR7 > +#define STMPE_TEMP_CHANNEL (STMPE_ADC_LAS
Re: [PATCH] iio: adc: meson-saradc: check for devm_kasprintf failure
On Thu, 22 Nov 2018 22:44:55 +0100
Martin Blumenstingl wrote:
> On Thu, Nov 22, 2018 at 8:52 AM Nicholas Mc Guire wrote:
> >
> > devm_kasprintf() may return NULL on failure of internal allocation thus
> > the assignments to init.name are not safe if not checked. On error
> > meson_sar_adc_clk_init() returns negative values so -ENOMEM in the
> > (unlikely) failure case of devm_kasprintf() should be fine here.
> >
> > Signed-off-by: Nicholas Mc Guire
> > Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in
> > Amlogic Meson SoCs")
> Acked-by: Martin Blumenstingl
>
> thank you for the patch!
> I tested the non-error case on my Odroid-C1 and it still works fine.
Applied. I also added a tested by tag for you Martin as it's always nice
for the log to reflect when people make the effort!
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
>
>
> Regards
> Martin
Re: [PATCH 1/1] iio: adc: meson-saradc: fix internal clock names
On Thu, 22 Nov 2018 23:01:11 +0100
Martin Blumenstingl wrote:
> Before this patch we are registering the internal clocks (for example on
> Meson8b, where the SAR ADC IP block implements the divider and gate
> clocks) with the following names:
> - /soc/cbus@c110/adc@8680#adc_div
> - /soc/cbus@c110/adc@8680#adc_en
>
> This is bad because the common clock framework uses the clock to create
> a directory in /clk. With such name, the directory creation
> (silently) fails and the debugfs entry ends up being created at the
> debugfs root.
>
> With this change, the new clock names are:
> - c1108680.adc#adc_div
> - c1108680.adc#adc_en
>
> This matches the clock naming scheme used in the PWM, Ethernet and MMC
> drivers. It also fixes the problem with debugfs.
> The idea is shamelessly taken from commit b96e9eb62841c5 ("pwm: meson:
> Fix mux clock names").
>
> Fixes: 3921db46a8c5bc ("iio: Convert to using %pOF instead of full_name")
> Signed-off-by: Martin Blumenstingl
As this is debugfs I am not going to push this through the fast path.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/meson_saradc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c
> index 6155d26091eb..729becb2d3d9 100644
> --- a/drivers/iio/adc/meson_saradc.c
> +++ b/drivers/iio/adc/meson_saradc.c
> @@ -656,8 +656,8 @@ static int meson_sar_adc_clk_init(struct iio_dev
> *indio_dev,
> struct clk_init_data init;
> const char *clk_parents[1];
>
> - init.name = devm_kasprintf(&indio_dev->dev, GFP_KERNEL, "%pOF#adc_div",
> -indio_dev->dev.of_node);
> + init.name = devm_kasprintf(&indio_dev->dev, GFP_KERNEL, "%s#adc_div",
> +dev_name(indio_dev->dev.parent));
> if (!init.name)
> return -ENOMEM;
>
> @@ -678,8 +678,8 @@ static int meson_sar_adc_clk_init(struct iio_dev
> *indio_dev,
> if (WARN_ON(IS_ERR(priv->adc_div_clk)))
> return PTR_ERR(priv->adc_div_clk);
>
> - init.name = devm_kasprintf(&indio_dev->dev, GFP_KERNEL, "%pOF#adc_en",
> -indio_dev->dev.of_node);
> + init.name = devm_kasprintf(&indio_dev->dev, GFP_KERNEL, "%s#adc_en",
> +dev_name(indio_dev->dev.parent));
> if (!init.name)
> return -ENOMEM;
>
Re: [PATCH 2/3] iio: chemical: add support for Sensirion SPS30 sensor
On Sat, Nov 24, 2018 at 11:14:14PM +0100, Tomasz Duszynski wrote:
> Add support for Sensirion SPS30 particulate matter sensor.
>
> Signed-off-by: Tomasz Duszynski
> ---
> drivers/iio/chemical/Kconfig | 11 ++
> drivers/iio/chemical/Makefile | 1 +
> drivers/iio/chemical/sps30.c | 359 ++
> 3 files changed, 371 insertions(+)
> create mode 100644 drivers/iio/chemical/sps30.c
[]
> +#define pr_fmt(fmt) "sps30: " fmt
I don't see its usage ?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SPS30_CRC8_POLYNOMIAL 0x31
> +
> +/* SPS30 commands */
> +#define SPS30_START_MEAS 0x0010
> +#define SPS30_STOP_MEAS 0x0104
> +#define SPS30_RESET 0xd304
> +#define SPS30_READ_DATA_READY_FLAG 0x0202
> +#define SPS30_READ_DATA 0x0300
> +#define SPS30_READ_SERIAL 0xD033
Could you please put a tab and align these macros.
#define SPS30_START_MEAS 0x0010
#define SPS30_STOP_MEAS 0x0104
> +static int sps30_write_then_read(struct sps30_state *state, u8 *buf,
> + int buf_size, u8 *data, int data_size)
> +{
> + /* every two received data bytes are checksummed */
> + u8 tmp[data_size + data_size / 2];
No VLAs!
https://lore.kernel.org/lkml/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qpxydaacu1rq...@mail.gmail.com/
> + int ret, i;
> +
> + /*
> + * Sensor does not support repeated start so instead of
> + * sending two i2c messages in a row we just send one by one.
> + */
> + ret = i2c_master_send(state->client, buf, buf_size);
> + if (ret != buf_size)
> + return ret < 0 ? ret : -EIO;
> +
> + if (!data)
> + return 0;
> +
> + ret = i2c_master_recv(state->client, tmp, sizeof(tmp));
> + if (ret != sizeof(tmp))
> + return ret < 0 ? ret : -EIO;
> +
> + for (i = 0; i < sizeof(tmp); i += 3) {
> + u8 crc = crc8(sps30_crc8_table, &tmp[i], 2, CRC8_INIT_VALUE);
> +
> + if (crc != tmp[i + 2]) {
> + dev_err(&state->client->dev,
> + "data integrity check failed\n");
> + return -EIO;
> + }
> +
> + *data++ = tmp[i];
> + *data++ = tmp[i + 1];
> + }
> +
> + return 0;
> +}
> +
> +static int sps30_do_cmd(struct sps30_state *state, u16 cmd, u8 *data, int
> size)
> +{
> + /* depending on the command up to 3 bytes may be needed for argument */
> + u8 buf[sizeof(cmd) + 3] = { cmd >> 8, cmd };
This is fine, since sizeof returns constant integer expression.
> + switch (cmd) {
> + case SPS30_START_MEAS:
> + buf[2] = 0x03;
> + buf[3] = 0x00;
> + buf[4] = 0xac; /* precomputed crc */
> + return sps30_write_then_read(state, buf, 5, NULL, 0);
> + case SPS30_STOP_MEAS:
> + case SPS30_RESET:
> + return sps30_write_then_read(state, buf, 2, NULL, 0);
> + case SPS30_READ_DATA_READY_FLAG:
> + case SPS30_READ_DATA:
> + case SPS30_READ_SERIAL:
> + return sps30_write_then_read(state, buf, 2, data, size);
> + default:
> + return -EINVAL;
> + };
> +}
> +static int sps30_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct sps30_state *state = iio_priv(indio_dev);
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_PROCESSED:
> + switch (chan->type) {
> + case IIO_MASSCONCENTRATION:
> + mutex_lock(&state->lock);
> + switch (chan->channel2) {
> + case IIO_MOD_PM2p5:
I think lock should be placed here
> + ret = sps30_do_meas(state, val, val2);
... and unlock here.
> + break;
> + case IIO_MOD_PM10:
> + ret = sps30_do_meas(state, val2, val);
> + break;
> + default:
> + break;
> + }
> + mutex_unlock(&state->lock);
> + if (ret)
> + return ret;
> +
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> + break;
> + default:
> + return -EINVAL;
> + }
> +}
[]
> +static int sps30_probe(struct i2c_client *client)
> +{
> + struct iio_dev *indio_dev;
> + struct sps30_state *state;
> + u8 buf[32] = { };
This is not valid in ISO-C but only in C++.
Instead,
u8 buf[32] = {0};
> + int ret;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> + return -EOPNOTSUPP;
> +
> + indio_dev = devm_iio_device_alloc(&cl
Re: [PATCH] staging: iio: ad5933: replaced kfifo by triggered_buffer
On Thu, 22 Nov 2018 10:53:47 -0200
Marcelo Schmitt wrote:
> Previously, there was an implicit creation of a kfifo which was replaced
> by a call to triggered_buffer_setup, which is already implemented in iio
> infrastructure.
>
> Signed-off-by: Marcelo Schmitt
I'm a little surprised that this would work without screaming a lot as
it will register an interrupt with no handlers. Do you have this
device to test? It's rapidly heading in the direction of too complex
a driver to fix without test hardware. Also, semantically this change
is not sensible as it implies an operating mode which the driver
is not using.
There are fundamental questions about how we handle an autotriggered
sweep that need answering before this driver can move forwards.
It needs some concept of a higher level trigger rather than a per
sample one like we typically use in IIO.
The main focus in the short term should be around defining that ABI
as it may fundamentally change the structure of the driver.
If you want to take this on (and it'll be a big job I think!) then
it may be possible to source some hardware to support that effort.
Thanks,
Jonathan
> ---
> .../staging/iio/impedance-analyzer/Kconfig| 2 +-
> .../staging/iio/impedance-analyzer/ad5933.c | 25 ---
> 2 files changed, 6 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/staging/iio/impedance-analyzer/Kconfig
> b/drivers/staging/iio/impedance-analyzer/Kconfig
> index dd97b6bb3fd0..d0af5aa55dc0 100644
> --- a/drivers/staging/iio/impedance-analyzer/Kconfig
> +++ b/drivers/staging/iio/impedance-analyzer/Kconfig
> @@ -7,7 +7,7 @@ config AD5933
> tristate "Analog Devices AD5933, AD5934 driver"
> depends on I2C
> select IIO_BUFFER
> - select IIO_KFIFO_BUF
> + select IIO_TRIGGERED_BUFFER
> help
> Say yes here to build support for Analog Devices Impedance Converter,
> Network Analyzer, AD5933/4, provides direct access via sysfs.
> diff --git a/drivers/staging/iio/impedance-analyzer/ad5933.c
> b/drivers/staging/iio/impedance-analyzer/ad5933.c
> index f9bcb8310e21..edb8b540bbf1 100644
> --- a/drivers/staging/iio/impedance-analyzer/ad5933.c
> +++ b/drivers/staging/iio/impedance-analyzer/ad5933.c
> @@ -20,7 +20,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> /* AD5933/AD5934 Registers */
> #define AD5933_REG_CONTROL_HB0x80/* R/W, 1 byte */
> @@ -615,22 +615,6 @@ static const struct iio_buffer_setup_ops
> ad5933_ring_setup_ops = {
> .postdisable = ad5933_ring_postdisable,
> };
>
> -static int ad5933_register_ring_funcs_and_init(struct iio_dev *indio_dev)
> -{
> - struct iio_buffer *buffer;
> -
> - buffer = iio_kfifo_allocate();
> - if (!buffer)
> - return -ENOMEM;
> -
> - iio_device_attach_buffer(indio_dev, buffer);
> -
> - /* Ring buffer functions - here trigger setup related */
> - indio_dev->setup_ops = &ad5933_ring_setup_ops;
> -
> - return 0;
> -}
> -
> static void ad5933_work(struct work_struct *work)
> {
> struct ad5933_state *st = container_of(work,
> @@ -744,7 +728,8 @@ static int ad5933_probe(struct i2c_client *client,
> indio_dev->channels = ad5933_channels;
> indio_dev->num_channels = ARRAY_SIZE(ad5933_channels);
>
> - ret = ad5933_register_ring_funcs_and_init(indio_dev);
> + ret = iio_triggered_buffer_setup(indio_dev, NULL, NULL,
> + &ad5933_ring_setup_ops);
The absence of either of the interrupt related callbacks made me
wonder what is going on here. The upshot is that this device
isn't operating in a triggered buffer style at all so we really
shouldn't be using that infrastructure - even if it's convenient.
It'll allocate an interrupt with neither a top half nor a thread
function. I'm not sure what the core will do about that but it
seems unlikely to be happy about it!
> if (ret)
> goto error_disable_reg;
>
> @@ -759,7 +744,7 @@ static int ad5933_probe(struct i2c_client *client,
> return 0;
>
> error_unreg_ring:
> - iio_kfifo_free(indio_dev->buffer);
> + iio_triggered_buffer_cleanup(indio_dev);
> error_disable_reg:
> regulator_disable(st->reg);
>
> @@ -772,7 +757,7 @@ static int ad5933_remove(struct i2c_client *client)
> struct ad5933_state *st = iio_priv(indio_dev);
>
> iio_device_unregister(indio_dev);
> - iio_kfifo_free(indio_dev->buffer);
> + iio_triggered_buffer_cleanup(indio_dev);
> regulator_disable(st->reg);
>
> return 0;
Re: [PATCH] staging: iio: ad7780: Add gain & filter gpio support
On Thu, 22 Nov 2018 11:01:00 +
"Popa, Stefan Serban" wrote:
> On Mi, 2018-11-21 at 16:04 -0200, Giuliano Belinassi wrote:
> > Previously, the AD7780 driver only supported gpio for the 'powerdown'
> > pin. This commit adds suppport for the 'gain' and 'filter' pin.
> Hey,
>
> Comments inline.
> >
> > Signed-off-by: Giuliano Belinassi
> > ---
> > drivers/staging/iio/adc/ad7780.c | 61 --
> > include/linux/iio/adc/ad_sigma_delta.h | 5 +++
> > 2 files changed, 62 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/staging/iio/adc/ad7780.c
> > b/drivers/staging/iio/adc/ad7780.c
> > index c4a85789c2db..69794f06dbcd 100644
> > --- a/drivers/staging/iio/adc/ad7780.c
> > +++ b/drivers/staging/iio/adc/ad7780.c
> > @@ -39,6 +39,9 @@
> > #define AD7170_PATTERN (AD7780_PAT0 | AD7170_PAT2)
> > #define AD7170_PATTERN_MASK(AD7780_PAT0 | AD7780_PAT1 |
> > AD7170_PAT2)
> >
> > +#define AD7780_GAIN_GPIO 0
> > +#define AD7780_FILTER_GPIO 1
> > +
> > struct ad7780_chip_info {
> > struct iio_chan_specchannel;
> > unsigned intpattern_mask;
> > @@ -50,6 +53,8 @@ struct ad7780_state {
> > const struct ad7780_chip_info *chip_info;
> > struct regulator*reg;
> > struct gpio_desc*powerdown_gpio;
> > + struct gpio_desc*gain_gpio;
> > + struct gpio_desc*filter_gpio;
> > unsigned intgain;
> >
> > struct ad_sigma_delta sd;
> > @@ -115,18 +120,51 @@ static int ad7780_read_raw(struct iio_dev
> > *indio_dev,
> > return -EINVAL;
> > }
> >
> > +static int ad7780_write_raw(struct iio_dev *indio_dev,
> > + struct iio_chan_spec const *chan,
> > + int val,
> > + int val2,
> > + long m)
> > +{
> > + struct ad7780_state *st = iio_priv(indio_dev);
> > +
> > + if (m != IIO_CHAN_INFO_RAW)
> > + return -EINVAL;
> > +
> > + if (st->chip_info->is_ad778x) {
> > + switch(val) {
> > + case AD7780_GAIN_GPIO:
>
> I think that instead of setting the gain directly, we should use
> the IIO_CHAN_INFO_SCALE attribute. At page 12 of the ad7780 datasheet there
> is a formula from which the output code can be calculated:
> Code = 2^(N − 1)
> × [(AIN × Gain /VREF) + 1]. So, by setting the scale from user space, the
> driver can calculate the correct gain by using the formula above. Also, it
> would be useful to introduce scale available.
> Furthermore, there is a new
> ad7124 adc driver which does this exact thing. Take a look here: https://gi
> thub.com/analogdevicesinc/linux/blob/master/drivers/iio/adc/ad7124.c#L337.
>
> > + gpiod_set_value(st->gain_gpio, val2);
> > + break;
> > + case AD7780_FILTER_GPIO:
>
> The attribute that should be used to configure the filter gpio is
> IIO_CHAN_INFO_SAMP_FREQ. So, we should have 10 Hz and 16.7 Hz available
> sampling frequencies. If from user space the 10 Hz sampling freq is
> requested, then we set the FILTER pin high, while for 16.7 Hz the FILTER
> pin will be low.
Absolutely agreed with Stefan here. If it had been decoupled from sampling
frequency (sometimes they are) then we have specific controls for filters
as well. Here it directly effects the sampling frequency.
Please in future avoid any driver specific control like you have here.
I haven't really worked out what the interface is beyond some sort
of bitmap passed through a write to a magic channel?
If there isn't an existing interface in IIO for what you want to do
please propose one rather than doing something that will only work
with a particular userspace. One of the primary purposes of having
a subsystem is to standardise interfaces. This definitely doesn't
do that!
Will be good to have the support along the lines Stefan suggested though!
Thanks,
Jonathan
>
> > + gpiod_set_value(st->filter_gpio, val2);
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static int ad7780_postprocess_sample(struct ad_sigma_delta *sigma_delta,
> > unsigned int raw_sample)
> > {
> > struct ad7780_state *st = ad_sigma_delta_to_ad7780(sigma_delta);
> > const struct ad7780_chip_info *chip_info = st->chip_info;
> > + int val;
> >
> > if ((raw_sample & AD7780_ERR) ||
> > ((raw_sample & chip_info->pattern_mask) != chip_info-
> > >pattern))
> > return -EIO;
> >
> > if (chip_info->is_ad778x) {
> > - if (raw_sample & AD7780_GAIN)
> > + val = raw_sample & AD7780_GAIN;
> > +
> > + if (val != gpiod_get_value(st->gain_gpio))
> > + return -EIO;
> > +
> > + if (val)
> > st->gain = 1;
> > else
> > st->gain = 12
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
On Sat, Nov 24, 2018 at 05:07:17PM -0800, Tony Lindgren wrote: > * Russell King - ARM Linux [181124 20:10]: > > On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote: > > > Hi, > > > > > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote: > > > > On 22/11/2018 17.12, Russell King - ARM Linux wrote: > > > > > I'm also not sure about this: > > > > > > > > > > if (cpu_is_omap15xx()) > > > > > end++; > > > > > > > > > > in dma_dest_len() - is that missing from the omap-dma driver? It > > > > > looks > > > > > like a work-around for some problem on OMAP15xx, but I can't make > > > > > sense > > > > > about why it's in the UDC driver rather than the legacy DMA driver. > > > > > > > > afaik no other legacy drivers were doing similar thing, this must be > > > > something which is needed for the omap_udc driver to fix up something? > > > > > > Here's the patch that added it: > > > https://marc.info/?l=linux-omap&m=119634396324221&w=2 > > > > > > "Make DMA-OUT behave on the 1510 ... the 1510 CPC register was just > > > off-by-one with respect to the 1611 CDAC" > > > > ... which suggests that's a problem with the CPC register itself, and > > we should fix that in the DMAengine driver rather than the USB gadget > > driver. > > > > Tony, any input on this? > > Yeah that sounds like some hardware work-around for 15xx as described > in the DMA_DEST_LAST macro reading CSAC on 15xx instead of CDAC. Seems > like it should be done in the dmaengine driver.. My guess is that other > dma users never needed to read CSAC register? Hmm, reading the OMAP1510 TRM for the CPC register, it seems that omap-dma won't handle this particularly well. The fact that the register only updates after the last request in an element or frame means that if we try to use this value as the current source / destination address before the first transfer, it can be wildly wrong. Saving the current value at the beginning of a request, and detecting if it's changed (like omap_udc) isn't going to work well in the generic case. If, say, the register happens to contain 0x0004, and our next transfer is using 32-bit elements in element sync mode starting at address with lsb 16 bits as 0, it would mean we'd see 0x0004 in this register after the _second_ element has been transferred, and we'd assume that the register hasn't yet changed - but we would have in reality transferred two elements. However, omap-dma.c zeros the CPC register before each transfer, which is interesting, because in one place the OMAP1510 TRM says that the CPC register is read/write, but in the actual description of this register, it says it's read-only. What it also means is that, in such a case, after the 2nd element has been transferred, where the register contains 0x0004, the address we'd be looking for (to calculate the residual) should be 0x0008, not 0x0005, so we actually need to be adding the number of bytes according to element size. Looking at omap-dma.c, someone has added support for the residue granularity: if (__dma_omap15xx(od->plat->dma_attr)) od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR; else od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST; If OMAP15xx is truely descriptor granularity, then we can't use omap-dma for omap_udc, because omap_udc needs to know exactly how many bytes were transferred. So... hmm, OMAP15xx DMA looks like a complete mess, and the only way to know what would and wouldn't work is to actually have the hardware. I think we're better off leaving omap-udc well alone, and if it's now broken with DMA, then that's unfortunate - it would require someone with the hardware to diagnose the problem and fix it. I think trying to convert it to dmaengine would be risking way more problems than its worth. -- RMK's Patch system: http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: WARNING in sysfs_remove_group (2)
syzbot has found a reproducer for the following crash on: HEAD commit:e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1659a62b40 kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446 dashboard link: https://syzkaller.appspot.com/bug?extid=34cbd0f790e5ab87f63b compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14dad1f540 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1211db8340 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+34cbd0f790e5ab87f...@syzkaller.appspotmail.com kobject_add_internal failed for hci3 (error: -2 parent: bluetooth) [ cut here ] Bluetooth: Can't register HCI device sysfs group 'power' not found for kobject 'hci0' WARNING: CPU: 1 PID: 6615 at fs/sysfs/group.c:255 sysfs_remove_group+0x15b/0x1b0 fs/sysfs/group.c:253 kobject: 'bluetooth' (99b926db): kobject_add_internal: parent: 'virtual', set: '(null)' Kernel panic - not syncing: panic_on_warn set ... CPU: 1 PID: 6615 Comm: syz-executor148 Not tainted 4.20.0-rc3+ #128 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x244/0x39d lib/dump_stack.c:113 panic+0x2ad/0x55c kernel/panic.c:188 kobject: 'hci4' (b7b152ea): kobject_add_internal: parent: 'bluetooth', set: 'devices' __warn.cold.8+0x20/0x45 kernel/panic.c:540 kobject: 'hci3' (de75fad9): kobject_add_internal: parent: 'bluetooth', set: 'devices' report_bug+0x254/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:271 do_invalid_op+0x36/0x40 arch/x86/kernel/traps.c:290 kobject: 'hci4' (b7b152ea): kobject_uevent_env invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:969 RIP: 0010:sysfs_remove_group+0x15b/0x1b0 fs/sysfs/group.c:253 kobject: 'hci1' (5f181f76): kobject_add_internal: parent: 'bluetooth', set: 'devices' Code: 48 89 d9 49 8b 55 00 48 b8 00 00 00 00 00 fc ff df 48 c1 e9 03 80 3c 01 00 75 41 48 8b 33 48 c7 c7 a0 bb 37 88 e8 85 2e 4f ff <0f> 0b eb 92 e8 3c 1d c9 ff e9 d0 fe ff ff 48 89 df e8 2f 1d c9 ff RSP: 0018:8881b01878b8 EFLAGS: 00010282 RAX: RBX: 887c3640 RCX: RDX: RSI: 8165eaf5 RDI: 0005 RBP: 8881b01878e0 R08: 8881abd72700 R09: ed103b5e3ef8 R10: ed103b5e3ef8 R11: 8881daf1f7c7 R12: R13: 8881abf02890 R14: 887c3be0 R15: 8881abf02880 dpm_sysfs_add+0x1cf/0x210 drivers/base/power/sysfs.c:678 device_add+0x8d8/0x18e0 drivers/base/core.c:1902 kobject: 'hci4' (b7b152ea): fill_kobj_path: path = '/devices/virtual/bluetooth/hci4' kobject: 'hci5' (72db0368): kobject_add_internal: parent: 'bluetooth', set: 'devices' kobject: 'hci3' (de75fad9): kobject_uevent_env hci_register_dev+0x3b3/0x9c0 net/bluetooth/hci_core.c:3261 kobject: 'hci1' (5f181f76): kobject_uevent_env __vhci_create_device+0x2c1/0x580 drivers/bluetooth/hci_vhci.c:139 kobject: 'hci5' (72db0368): kobject_uevent_env vhci_create_device drivers/bluetooth/hci_vhci.c:163 [inline] vhci_get_user drivers/bluetooth/hci_vhci.c:219 [inline] vhci_write+0x2de/0x470 drivers/bluetooth/hci_vhci.c:299 kobject: 'hci1' (5f181f76): fill_kobj_path: path = '/devices/virtual/bluetooth/hci1' call_write_iter include/linux/fs.h:1857 [inline] new_sync_write fs/read_write.c:474 [inline] __vfs_write+0x6b8/0x9f0 fs/read_write.c:487 kobject: 'hci2' (8e0439e5): kobject_add_internal: parent: 'bluetooth', set: 'devices' vfs_write+0x1fc/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 kobject: 'hci3' (de75fad9): fill_kobj_path: path = '/devices/virtual/bluetooth/hci3' __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 kobject: 'rfkill466' (8955fb87): kobject_add_internal: parent: 'hci4', set: 'devices' kobject: 'hci5' (72db0368): fill_kobj_path: path = '/devices/virtual/bluetooth/hci5' entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440e49 Code: e8 ac e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 0b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00 kobject: 'rfkill466' (8955fb87): kobject_uevent_env RSP: 002b:7ffd93629a18 EFLAGS: 0213 ORIG_RAX: 0001 RAX: ffda RBX: RCX: 00440e49 RDX: 0002 RSI: 20c0 RDI: 0003 RBP: R08: 004002c8 R09:
Re: [PATCH] ALSA: pcm: Fix starvation on down_write_nonblock()
Hi Chanho, I love your patch! Yet something to improve: [auto build test ERROR on sound/for-next] [also build test ERROR on v4.20-rc3 next-20181123] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chanho-Min/ALSA-pcm-Fix-starvation-on-down_write_nonblock/20181124-182630 base: https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git for-next config: x86_64-allmodconfig (attached as .config) compiler: gcc-7 (Debian 7.3.0-1) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): include/linux/slab.h:332:43: warning: dubious: x & !y include/linux/slab.h:332:43: warning: dubious: x & !y include/linux/slab.h:332:43: warning: dubious: x & !y include/linux/slab.h:332:43: warning: dubious: x & !y sound/core/pcm_native.c:590:51: warning: incorrect type in assignment (different base types) sound/core/pcm_native.c:590:51:expected restricted snd_pcm_state_t [usertype] state sound/core/pcm_native.c:590:51:got int [signed] state sound/core/pcm_native.c:755:38: warning: incorrect type in argument 2 (different base types) sound/core/pcm_native.c:755:38:expected int [signed] state sound/core/pcm_native.c:755:38:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:767:38: warning: incorrect type in argument 2 (different base types) sound/core/pcm_native.c:767:38:expected int [signed] state sound/core/pcm_native.c:767:38:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:816:38: warning: incorrect type in argument 2 (different base types) sound/core/pcm_native.c:816:38:expected int [signed] state sound/core/pcm_native.c:816:38:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1226:32: warning: incorrect type in assignment (different base types) sound/core/pcm_native.c:1226:32:expected restricted snd_pcm_state_t [usertype] state sound/core/pcm_native.c:1226:32:got int [signed] state sound/core/pcm_native.c:1250:31: warning: incorrect type in argument 3 (different base types) sound/core/pcm_native.c:1250:31:expected int [signed] state sound/core/pcm_native.c:1250:31:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1257:40: warning: incorrect type in argument 3 (different base types) sound/core/pcm_native.c:1257:40:expected int [signed] state sound/core/pcm_native.c:1257:40:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1283:28: warning: restricted snd_pcm_state_t degrades to integer sound/core/pcm_native.c:1285:40: warning: incorrect type in assignment (different base types) sound/core/pcm_native.c:1285:40:expected restricted snd_pcm_state_t [usertype] state sound/core/pcm_native.c:1285:40:got int [signed] state sound/core/pcm_native.c:1309:64: warning: incorrect type in argument 3 (different base types) sound/core/pcm_native.c:1309:64:expected int [signed] state sound/core/pcm_native.c:1309:64:got restricted snd_pcm_state_t [usertype] state sound/core/pcm_native.c:1325:38: warning: incorrect type in argument 3 (different base types) sound/core/pcm_native.c:1325:38:expected int [signed] state sound/core/pcm_native.c:1325:38:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1684:38: warning: incorrect type in argument 2 (different base types) sound/core/pcm_native.c:1684:38:expected int [signed] state sound/core/pcm_native.c:1684:38:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1750:61: warning: incorrect type in argument 2 (different base types) sound/core/pcm_native.c:1750:61:expected int [signed] state sound/core/pcm_native.c:1750:61:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1751:63: warning: incorrect type in argument 2 (different base types) sound/core/pcm_native.c:1751:63:expected int [signed] state sound/core/pcm_native.c:1751:63:got restricted snd_pcm_state_t [usertype] sound/core/pcm_native.c:1768:76: warning: incorrect type in initializer (different base types) sound/core/pcm_native.c:1768:76:expected int [signed] new_state sound/core/pcm_native.c:1768:76:got restricted snd_pcm_state_t include/linux/slab.h:332:43: warning: dubious: x & !y >> sound/core/pcm_native.c:99:17: error: undefined identifier 'msleep' >> sound/core/pcm_native.c:99:23: error: not a function sound/core/pcm_native.c:2089:26: warning: restricted snd_pcm_format_t degrades to integer sound/core/pcm_native.c:2093:54: warning: incorrect type in argument 1 (different base types) sound/core/pcm_native.c:2093:54:expected restricted snd_pcm_format_t [usertype] format sound/core/pcm_native.c:2093:54:got unsigned int
Re: [PATCH v2 1/2] staging: iio: ad7606: Move out of staging
On Tue, 20 Nov 2018 17:43:46 +0200 Stefan Popa wrote: > Move ad7606 ADC driver out of staging and into the mainline. > > Signed-off-by: Stefan Popa One idle thought, how much would the performance suffer if we moved the parallel path over to the new gpiod_get/set_raw_array_value and friends? If would relax some of the constraints on where this could be used. There are some ordering issues in probe that need fixing. There are also a few places where it feels 'racey' and might need more comments to say why data is definitely ready when we try to read it for example. So nearly there, but one more cleanup series I think! Thanks, Jonathan > --- > Changes in v2: > - Simplified the Kconfig menu. > - Added SPDX-License-Identifier. > - Ordered the includes alphabetically. > - Used a threaded interrupt. > - Replaced ad7606_poll_bh_to_ring() with ad7606_trigger_handler(). > - Used a trigger. > - Replaced wait_event_interruptible() with > wait_for_completion_timeout(). > - Replaced wake_up_interruptible() with complete(). > - Used devm_iio_triggered_buffer_setup(). > - Added buffer_ops. > - Used single line comments where needed. > - Removed the gap between docs and struct. > - Added ad7606_of_match[]. > > MAINTAINERS | 7 + > drivers/iio/adc/Kconfig | 28 ++ > drivers/iio/adc/Makefile | 3 + > drivers/iio/adc/ad7606.c | 608 > +++ > drivers/iio/adc/ad7606.h | 107 ++ > drivers/iio/adc/ad7606_par.c | 110 +++ > drivers/iio/adc/ad7606_spi.c | 88 + > drivers/staging/iio/adc/Kconfig | 34 -- > drivers/staging/iio/adc/Makefile | 3 - > drivers/staging/iio/adc/ad7606.c | 565 > drivers/staging/iio/adc/ad7606.h | 106 -- > drivers/staging/iio/adc/ad7606_par.c | 113 --- > drivers/staging/iio/adc/ad7606_spi.c | 79 - > 13 files changed, 951 insertions(+), 900 deletions(-) > create mode 100644 drivers/iio/adc/ad7606.c > create mode 100644 drivers/iio/adc/ad7606.h > create mode 100644 drivers/iio/adc/ad7606_par.c > create mode 100644 drivers/iio/adc/ad7606_spi.c > delete mode 100644 drivers/staging/iio/adc/ad7606.c > delete mode 100644 drivers/staging/iio/adc/ad7606.h > delete mode 100644 drivers/staging/iio/adc/ad7606_par.c > delete mode 100644 drivers/staging/iio/adc/ad7606_spi.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index f642044..843545d 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -839,6 +839,13 @@ S: Supported > F: drivers/iio/dac/ad5758.c > F: Documentation/devicetree/bindings/iio/dac/ad5758.txt > > +ANALOG DEVICES INC AD7606 DRIVER > +M: Stefan Popa > +L: linux-...@vger.kernel.org > +W: http://ez.analog.com/community/linux-device-drivers > +S: Supported > +F: drivers/iio/adc/ad7606.c > + > ANALOG DEVICES INC AD9389B DRIVER > M: Hans Verkuil > L: linux-me...@vger.kernel.org > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig > index a52fea8..c3f61c9 100644 > --- a/drivers/iio/adc/Kconfig > +++ b/drivers/iio/adc/Kconfig > @@ -58,6 +58,34 @@ config AD7476 > To compile this driver as a module, choose M here: the > module will be called ad7476. > > +config AD7606 > + tristate > + depends on GPIOLIB || COMPILE_TEST > + depends on HAS_IOMEM > + select IIO_BUFFER > + select IIO_TRIGGERED_BUFFER > + > +config AD7606_IFACE_PARALLEL > + tristate "Analog Devices AD7606 ADC driver with parallel interface > support" > + select AD7606 > + help > + Say yes here to build parallel interface support for Analog Devices: > + ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters > (ADC). > + > + To compile this driver as a module, choose M here: the > + module will be called ad7606_parallel. > + > +config AD7606_IFACE_SPI > + tristate "Analog Devices AD7606 ADC driver with spi interface support" > + depends on SPI > + select AD7606 > + help > + Say yes here to build spi interface support for Analog Devices: > + ad7605-4, ad7606, ad7606-6, ad7606-4 analog to digital converters > (ADC). > + > + To compile this driver as a module, choose M here: the > + module will be called ad7606_spi. > + > config AD7766 > tristate "Analog Devices AD7766/AD7767 ADC driver" > depends on SPI_MASTER > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile > index a6e6a0b..b734f4f 100644 > --- a/drivers/iio/adc/Makefile > +++ b/drivers/iio/adc/Makefile > @@ -8,6 +8,9 @@ obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o > obj-$(CONFIG_AD7266) += ad7266.o > obj-$(CONFIG_AD7291) += ad7291.o > obj-$(CONFIG_AD7298) += ad7298.o > +obj-$(CONFIG_AD7606_IFACE_PARALLEL) += ad7606_par.o > +obj-$(CONFIG_AD7606_IFACE_SPI) += ad7606_spi.o > +obj-$(CONFIG_AD760
Re: [PATCH v2 2/2] dt-bindings: iio: adc: Add docs for AD7606 ADC
On Tue, 20 Nov 2018 17:44:37 +0200
Stefan Popa wrote:
> Document support for AD7606 Analog to Digital Converter.
>
> Signed-off-by: Stefan Popa
This looks good to me, but given my recent inability to pick up on the
subtle (and not so subtle) issues in DT patches, I'd like a review
from the DT side if possible. The first patch needs some additional
changes, but they probably don't effect the bindings.
Thanks,
Jonathan
> ---
> Changes in v2:
> - fixed indentation issues.
> - used gpios instead of gpio.
> - added vendor prefix for conversion-start-gpios, first-data-gpios,
> and range-gpios.
>
> .../devicetree/bindings/iio/adc/adi,ad7606.txt | 54
> ++
> MAINTAINERS| 1 +
> 2 files changed, 55 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
> b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
> new file mode 100644
> index 000..02fae23
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7606.txt
> @@ -0,0 +1,54 @@
> +Analog Devices AD7606 Simultaneous Sampling ADC
> +
> +Required properties for the AD7606:
> +
> +- compatible: Must be one of
> + * "adi,ad7605-4"
> + * "adi,ad7606-8"
> + * "adi,ad7606-6"
> + * "adi,ad7606-4"
> +- reg: SPI chip select number for the device
> +- spi-max-frequency: Max SPI frequency to use
> + see: Documentation/devicetree/bindings/spi/spi-bus.txt
> +- spi-cpha: See Documentation/devicetree/bindings/spi/spi-bus.txt
> +- avcc-supply: phandle to the Avcc power supply
> +- interrupts: IRQ line for the ADC
> + see:
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +- adi,conversion-start-gpios: must be the device tree identifier of the
> CONVST pin.
> + This logic input is used to initiate conversions on the analog
> + input channels.
> +
> +Optional properties:
> +
> +- reset-gpios: must be the device tree identifier of the RESET pin. If
> specified,
> +it will be asserted during driver probe.
> +- standby-gpios: must be the device tree identifier of the STBY pin. This
> pin is used
> + to place the AD7606 into one of two power-down modes, Standby
> mode or
> + Shutdown mode.
> +- adi,first-data-gpios: must be the device tree identifier of the FRSTDATA
> pin.
> + The FRSTDATA output indicates when the first channel, V1, is
> + being read back on either the parallel, byte or serial
> interface.
> +- adi,range-gpios: must be the device tree identifier of the RANGE pin. The
> polarity on
> + this pin determines the input range of the analog input channels.
> If
> + this pin is tied to a logic high, the analog input range is ±10V
> for
> + all channels. If this pin is tied to a logic low, the analog
> input range
> + is ±5V for all channels.
> +
> +Example:
> +
> + adc@0 {
> + compatible = "adi,ad7606-8";
> + reg = <0>;
> + spi-max-frequency = <100>;
> + spi-cpol;
> +
> + avcc-supply = <&adc_vref>;
> +
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-parent = <&gpio>;
> +
> + adi,conversion-start-gpios = <&gpio 17 0>;
> + reset-gpios = <&gpio 27 0>;
> + adi,first-data-gpios = <&gpio 22 0>;
> + standby-gpios = <&gpio 24 0>;
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 843545d..6d63db4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -845,6 +845,7 @@ L:linux-...@vger.kernel.org
> W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/adc/ad7606.c
> +F: Documentation/devicetree/bindings/iio/adc/ad7606.txt
>
> ANALOG DEVICES INC AD9389B DRIVER
> M: Hans Verkuil
Re: [PATCH v2 1/5] Staging: iio: adt7316: Add of_device_id table
On Tue, 20 Nov 2018 22:22:30 +0530
Shreeya Patel wrote:
> When the kernel starts up, it kicks off compiled-in drivers
> that match “compatible” entries it finds in the device tree.
> At a later stage (when /lib/modules is available), all kernel modules
> that match “compatible” entries in the device tree are loaded.
>
> But if there is no dt table then there should be a fall back path
> with which desired kernel modules can be loaded. Hence, add
> of_device_id table in the i2c driver to be able to use when there
> is no dt table.
The patch is fine, but this description is confusing.
of_device_id is a device tree table (confusing naming in the
kernel, but of is open firmware, a standard from which device tree
emerged).
I've just dropped this second paragraph from the description to
avoid confusion.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
>
> Signed-off-by: Shreeya Patel
> ---
>
> Changes in v2:
> - Make the commit message appropriate and assign of_match_table
> in the driver structure.
>
> drivers/staging/iio/addac/adt7316-i2c.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/staging/iio/addac/adt7316-i2c.c
> b/drivers/staging/iio/addac/adt7316-i2c.c
> index 473e5e34ec00..41bc4ca008bc 100644
> --- a/drivers/staging/iio/addac/adt7316-i2c.c
> +++ b/drivers/staging/iio/addac/adt7316-i2c.c
> @@ -126,9 +126,22 @@ static const struct i2c_device_id adt7316_i2c_id[] = {
>
> MODULE_DEVICE_TABLE(i2c, adt7316_i2c_id);
>
> +static const struct of_device_id adt7316_of_match[] = {
> + { .compatible = "adi,adt7316" },
> + { .compatible = "adi,adt7317" },
> + { .compatible = "adi,adt7318" },
> + { .compatible = "adi,adt7516" },
> + { .compatible = "adi,adt7517" },
> + { .compatible = "adi,adt7519" },
> + { },
> +};
> +
> +MODULE_DEVICE_TABLE(of, adt7316_of_match);
> +
> static struct i2c_driver adt7316_driver = {
> .driver = {
> .name = "adt7316",
> + .of_match_table = adt7316_of_match,
> .pm = ADT7316_PM_OPS,
> },
> .probe = adt7316_i2c_probe,
Re: [PATCH v2 2/5] Staging: iio: adt7316: Use device tree data to set ldac_pin
On Tue, 20 Nov 2018 22:24:36 +0530
Shreeya Patel wrote:
> Make the driver use device tree instead of the platform data.
> Hence, use devm_gpiod_get_optional function to get the data from
> device tree for ldac-pin and accordingly make the needed changes
> in the driver.
>
> Signed-off-by: Shreeya Patel
Sorry, missed this previously. This is definitely a non standard
gpio name, so should be prefixed in the binding and here with
adi,
I'll fix up, but please check I didn't mess it up!
Applied with that change to the togreg branch of iio.git.
Thanks,
Jonathan
> ---
> drivers/staging/iio/addac/adt7316.c | 14 ++
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/iio/addac/adt7316.c
> b/drivers/staging/iio/addac/adt7316.c
> index 3f22d1088713..deb2f7b40f60 100644
> --- a/drivers/staging/iio/addac/adt7316.c
> +++ b/drivers/staging/iio/addac/adt7316.c
> @@ -177,7 +177,7 @@
>
> struct adt7316_chip_info {
> struct adt7316_bus bus;
> - u16 ldac_pin;
> + struct gpio_desc*ldac_pin;
> u16 int_mask; /* 0x2f */
> u8 config1;
> u8 config2;
> @@ -950,8 +950,8 @@ static ssize_t adt7316_store_update_DAC(struct device
> *dev,
> if (ret)
> return -EIO;
> } else {
> - gpio_set_value(chip->ldac_pin, 0);
> - gpio_set_value(chip->ldac_pin, 1);
> + gpiod_set_value(chip->ldac_pin, 0);
> + gpiod_set_value(chip->ldac_pin, 1);
> }
>
> return len;
> @@ -2120,7 +2120,13 @@ int adt7316_probe(struct device *dev, struct
> adt7316_bus *bus,
> else
> return -ENODEV;
>
> - chip->ldac_pin = adt7316_platform_data[1];
> + chip->ldac_pin = devm_gpiod_get_optional(dev, "ldac", GPIOD_OUT_LOW);
> + if (IS_ERR(chip->ldac_pin)) {
> + ret = PTR_ERR(chip->ldac_pin);
> + dev_err(dev, "Failed to request ldac GPIO: %d\n", ret);
> + return ret;
> + }
> +
> if (chip->ldac_pin) {
> chip->config3 |= ADT7316_DA_EN_VIA_DAC_LDCA;
> if ((chip->id & ID_FAMILY_MASK) == ID_ADT75XX)
Re: [PATCH v2 3/5] Staging: iio: adt7316: Switch irq_flags to a local variable
On Tue, 20 Nov 2018 22:26:58 +0530
Shreeya Patel wrote:
> There is no need to store irq_flags into the structure as it
> is always set to the same thing. Hence switch irq_flags to a
> local variable.
>
> Signed-off-by: Shreeya Patel
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/staging/iio/addac/adt7316-i2c.c | 1 -
> drivers/staging/iio/addac/adt7316-spi.c | 1 -
> drivers/staging/iio/addac/adt7316.c | 8
> drivers/staging/iio/addac/adt7316.h | 1 -
> 4 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/iio/addac/adt7316-i2c.c
> b/drivers/staging/iio/addac/adt7316-i2c.c
> index 41bc4ca008bc..ac91163656b5 100644
> --- a/drivers/staging/iio/addac/adt7316-i2c.c
> +++ b/drivers/staging/iio/addac/adt7316-i2c.c
> @@ -104,7 +104,6 @@ static int adt7316_i2c_probe(struct i2c_client *client,
> struct adt7316_bus bus = {
> .client = client,
> .irq = client->irq,
> - .irq_flags = IRQF_TRIGGER_LOW,
> .read = adt7316_i2c_read,
> .write = adt7316_i2c_write,
> .multi_read = adt7316_i2c_multi_read,
> diff --git a/drivers/staging/iio/addac/adt7316-spi.c
> b/drivers/staging/iio/addac/adt7316-spi.c
> index 5cd22743e140..e75827e326a6 100644
> --- a/drivers/staging/iio/addac/adt7316-spi.c
> +++ b/drivers/staging/iio/addac/adt7316-spi.c
> @@ -94,7 +94,6 @@ static int adt7316_spi_probe(struct spi_device *spi_dev)
> struct adt7316_bus bus = {
> .client = spi_dev,
> .irq = spi_dev->irq,
> - .irq_flags = IRQF_TRIGGER_LOW,
> .read = adt7316_spi_read,
> .write = adt7316_spi_write,
> .multi_read = adt7316_spi_multi_read,
> diff --git a/drivers/staging/iio/addac/adt7316.c
> b/drivers/staging/iio/addac/adt7316.c
> index deb2f7b40f60..dfae22619287 100644
> --- a/drivers/staging/iio/addac/adt7316.c
> +++ b/drivers/staging/iio/addac/adt7316.c
> @@ -2102,6 +2102,7 @@ int adt7316_probe(struct device *dev, struct
> adt7316_bus *bus,
> struct adt7316_chip_info *chip;
> struct iio_dev *indio_dev;
> unsigned short *adt7316_platform_data = dev->platform_data;
> + int irq_flags = IRQF_TRIGGER_LOW;
> int ret = 0;
>
> indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
> @@ -2146,19 +2147,18 @@ int adt7316_probe(struct device *dev, struct
> adt7316_bus *bus,
>
> if (chip->bus.irq > 0) {
> if (adt7316_platform_data[0])
> - chip->bus.irq_flags = adt7316_platform_data[0];
> + irq_flags = adt7316_platform_data[0];
>
> ret = devm_request_threaded_irq(dev, chip->bus.irq,
> NULL,
> adt7316_event_handler,
> - chip->bus.irq_flags |
> - IRQF_ONESHOT,
> + irq_flags | IRQF_ONESHOT,
> indio_dev->name,
> indio_dev);
> if (ret)
> return ret;
>
> - if (chip->bus.irq_flags & IRQF_TRIGGER_HIGH)
> + if (irq_flags & IRQF_TRIGGER_HIGH)
> chip->config1 |= ADT7316_INT_POLARITY;
> }
>
> diff --git a/drivers/staging/iio/addac/adt7316.h
> b/drivers/staging/iio/addac/adt7316.h
> index ec40fbb698a6..fd7c5c92b599 100644
> --- a/drivers/staging/iio/addac/adt7316.h
> +++ b/drivers/staging/iio/addac/adt7316.h
> @@ -17,7 +17,6 @@
> struct adt7316_bus {
> void *client;
> int irq;
> - int irq_flags;
> int (*read)(void *client, u8 reg, u8 *data);
> int (*write)(void *client, u8 reg, u8 val);
> int (*multi_read)(void *client, u8 first_reg, u8 count, u8 *data);
Re: [PATCH v2 4/5] Staging: iio: adt7316: Change the name from irq_flags to irq_type
On Tue, 20 Nov 2018 22:28:36 +0530
Shreeya Patel wrote:
> Most of the drivers in IIO uses irq_type as the name for
> storing the interrupt type and hence change the name from
> irq_flags to irq_type for maintaining the consistency.
>
> Signed-off-by: Shreeya Patel
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with.
Thanks,
Jonathan
> ---
> drivers/staging/iio/addac/adt7316.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/iio/addac/adt7316.c
> b/drivers/staging/iio/addac/adt7316.c
> index dfae22619287..9c72538baf9e 100644
> --- a/drivers/staging/iio/addac/adt7316.c
> +++ b/drivers/staging/iio/addac/adt7316.c
> @@ -2102,7 +2102,7 @@ int adt7316_probe(struct device *dev, struct
> adt7316_bus *bus,
> struct adt7316_chip_info *chip;
> struct iio_dev *indio_dev;
> unsigned short *adt7316_platform_data = dev->platform_data;
> - int irq_flags = IRQF_TRIGGER_LOW;
> + int irq_type = IRQF_TRIGGER_LOW;
> int ret = 0;
>
> indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
> @@ -2147,18 +2147,18 @@ int adt7316_probe(struct device *dev, struct
> adt7316_bus *bus,
>
> if (chip->bus.irq > 0) {
> if (adt7316_platform_data[0])
> - irq_flags = adt7316_platform_data[0];
> + irq_type = adt7316_platform_data[0];
>
> ret = devm_request_threaded_irq(dev, chip->bus.irq,
> NULL,
> adt7316_event_handler,
> - irq_flags | IRQF_ONESHOT,
> + irq_type | IRQF_ONESHOT,
> indio_dev->name,
> indio_dev);
> if (ret)
> return ret;
>
> - if (irq_flags & IRQF_TRIGGER_HIGH)
> + if (irq_type & IRQF_TRIGGER_HIGH)
> chip->config1 |= ADT7316_INT_POLARITY;
> }
>
Re: [PATCH v2 5/5] Staging: iio: adt7316: Use device tree data to assign irq_type
On Wed, 21 Nov 2018 15:02:52 +0530
Shreeya Patel wrote:
> On Wed, 2018-11-21 at 08:21 +, Ardelean, Alexandru wrote:
> > On Tue, 2018-11-20 at 22:30 +0530, Shreeya Patel wrote:
> > > ADT7316 driver no more uses platform data and hence use device tree
> > > data instead of platform data for assigning irq_type field.
> > > Switch case figures out the type of irq and if it's the default
> > > case
> > > then assign the default value to the irq_type i.e.
> > > irq_type = IRQF_TRIGGER_LOW
> > >
> >
> > 1 comment inline
> >
> > > Signed-off-by: Shreeya Patel
> > > ---
> > > drivers/staging/iio/addac/adt7316.c | 21 +
> > > 1 file changed, 17 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/addac/adt7316.c
> > > b/drivers/staging/iio/addac/adt7316.c
> > > index 9c72538baf9e..c647875a64f5 100644
> > > --- a/drivers/staging/iio/addac/adt7316.c
> > > +++ b/drivers/staging/iio/addac/adt7316.c
> > > @@ -2101,8 +2101,7 @@ int adt7316_probe(struct device *dev, struct
> > > adt7316_bus *bus,
> > > {
> > > struct adt7316_chip_info *chip;
> > > struct iio_dev *indio_dev;
> > > - unsigned short *adt7316_platform_data = dev-
> > > >platform_data;
> > > - int irq_type = IRQF_TRIGGER_LOW;
> > > + int irq_type;
> > > int ret = 0;
> > >
> > > indio_dev = devm_iio_device_alloc(dev, sizeof(*chip));
> > > @@ -2146,8 +2145,22 @@ int adt7316_probe(struct device *dev, struct
> > > adt7316_bus *bus,
> > > indio_dev->modes = INDIO_DIRECT_MODE;
> > >
> > > if (chip->bus.irq > 0) {
> > > - if (adt7316_platform_data[0])
> > > - irq_type = adt7316_platform_data[0];
> > > + irq_type =
> > > + irqd_get_trigger_type(irq_get_irq_data(chi
> > > p-
> > > > bus.irq));
> > >
> > > +
> > > + switch (irq_type) {
> > > + case IRQF_TRIGGER_HIGH:
> > > + case IRQF_TRIGGER_RISING:
> > > + break;
> > > + case IRQF_TRIGGER_LOW:
> > > + case IRQF_TRIGGER_FALLING:
> > > + break;
> > > + default:
> > > + dev_info(dev, "mode %d unsupported, using
> > > IRQF_TRIGGER_LOW\n",
> > > + irq_type);
> > > + irq_type = IRQF_TRIGGER_LOW;
> > > + break;
> > > + }
> >
> > It would be an idea to move this part [together with
> > devm_request_threaded_irq()] into a "adt7316_setup_irq()" function.
> > To un-
> > clutter the code in the adt7316_probe() function.
> >
>
> Yes, seems like a good idea!
> Even other drivers are doing the same as you told me to do...thanks :)
>
> I'll do the change after Jonathan picks up the other patches and will
> wait for some other reviews to come up if there are any.
Agreed. This suggested change is good, so I'll leave this patch for now
on the basis it probably makes sense to do it as a short series focused
on that one element.
Thanks,
Jonathan
>
> Thanks
>
> > >
> > > ret = devm_request_threaded_irq(dev, chip-
> > > >bus.irq,
> > > NULL,
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
On Sun, Nov 25, 2018 at 11:11:05AM +, Russell King - ARM Linux wrote:
> On Sat, Nov 24, 2018 at 05:07:17PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [181124 20:10]:
> > > On Fri, Nov 23, 2018 at 08:52:15PM +0200, Aaro Koskinen wrote:
> > > > Hi,
> > > >
> > > > On Fri, Nov 23, 2018 at 02:35:04PM +0200, Peter Ujfalusi wrote:
> > > > > On 22/11/2018 17.12, Russell King - ARM Linux wrote:
> > > > > > I'm also not sure about this:
> > > > > >
> > > > > > if (cpu_is_omap15xx())
> > > > > > end++;
> > > > > >
> > > > > > in dma_dest_len() - is that missing from the omap-dma driver? It
> > > > > > looks
> > > > > > like a work-around for some problem on OMAP15xx, but I can't make
> > > > > > sense
> > > > > > about why it's in the UDC driver rather than the legacy DMA driver.
> > > > >
> > > > > afaik no other legacy drivers were doing similar thing, this must be
> > > > > something which is needed for the omap_udc driver to fix up something?
> > > >
> > > > Here's the patch that added it:
> > > > https://marc.info/?l=linux-omap&m=119634396324221&w=2
> > > >
> > > > "Make DMA-OUT behave on the 1510 ... the 1510 CPC register was just
> > > > off-by-one with respect to the 1611 CDAC"
> > >
> > > ... which suggests that's a problem with the CPC register itself, and
> > > we should fix that in the DMAengine driver rather than the USB gadget
> > > driver.
> > >
> > > Tony, any input on this?
> >
> > Yeah that sounds like some hardware work-around for 15xx as described
> > in the DMA_DEST_LAST macro reading CSAC on 15xx instead of CDAC. Seems
> > like it should be done in the dmaengine driver.. My guess is that other
> > dma users never needed to read CSAC register?
>
> Hmm, reading the OMAP1510 TRM for the CPC register, it seems that
> omap-dma won't handle this particularly well. The fact that the
> register only updates after the last request in an element or frame
> means that if we try to use this value as the current source /
> destination address before the first transfer, it can be wildly
> wrong.
>
> Saving the current value at the beginning of a request, and detecting
> if it's changed (like omap_udc) isn't going to work well in the
> generic case. If, say, the register happens to contain 0x0004, and
> our next transfer is using 32-bit elements in element sync mode
> starting at address with lsb 16 bits as 0, it would mean we'd see
> 0x0004 in this register after the _second_ element has been
> transferred, and we'd assume that the register hasn't yet changed -
> but we would have in reality transferred two elements.
>
> However, omap-dma.c zeros the CPC register before each transfer,
> which is interesting, because in one place the OMAP1510 TRM says
> that the CPC register is read/write, but in the actual description
> of this register, it says it's read-only.
>
> What it also means is that, in such a case, after the 2nd element has
> been transferred, where the register contains 0x0004, the address
> we'd be looking for (to calculate the residual) should be 0x0008,
> not 0x0005, so we actually need to be adding the number of bytes
> according to element size.
>
> Looking at omap-dma.c, someone has added support for the residue
> granularity:
>
> if (__dma_omap15xx(od->plat->dma_attr))
> od->ddev.residue_granularity =
> DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
> else
> od->ddev.residue_granularity = DMA_RESIDUE_GRANULARITY_BURST;
I'll point out that this was introduced by:
commit c9bd0946da243a8eb86b44ff613e2c813f9b683b
Author: Janusz Krzysztofik
Date: Tue Jun 5 18:59:57 2018 +0200
dmaengine: ti: omap-dma: Fix OMAP1510 incorrect residue_granularity
...
It was verified already before that omap_get_dma_src_pos() from
arch/arm/plat-omap/dma.c didn't work correctly for OMAP1510 - see
commit 1bdd7419910c ("ASoC: OMAP: fix OMAP1510 broken PCM pointer
callback") for details. Apparently the same applies to its successor,
omap_dma_get_src_pos() from drivers/dma/ti/omap-dma.c.
So, this now presents us with bigger problems - if we fix it now for
omap_udc, should the above commit be reverted, and if we do revert
the above commit, will it regress OMAP1510 audio.
The intention of omap-dma was always to report an accurate residue.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH 1/3] iio: adc: stm32-adc: move self-calibration to prepare routine
On Tue, 20 Nov 2018 11:12:30 +0100
Fabrice Gasnier wrote:
> Move self-calibration routine to prepare routine.
> - This is precursor patch to ease power management handling.
> - This also allow to factorize few error cases (error handling).
>
> Signed-off-by: Fabrice Gasnier
one trivial point inline. Otherwise seems a sensible bit of refactoring.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc.c | 59
> ++---
> 1 file changed, 24 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 3784118..dca8733 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -199,11 +199,13 @@ struct stm32_adc_trig_info {
> * @calfact_s: Calibration offset for single ended channels
> * @calfact_d: Calibration offset in differential
> * @lincalfact: Linearity calibration factor
> + * @calibrated: Indicates calibration status
> */
> struct stm32_adc_calib {
> u32 calfact_s;
> u32 calfact_d;
> u32 lincalfact[STM32H7_LINCALFACT_NUM];
> + boolcalibrated;
> };
>
> /**
> @@ -251,7 +253,6 @@ struct stm32_adc_regspec {
> * @trigs: external trigger sources
> * @clk_required:clock is required
> * @has_vregready: vregready status flag presence
> - * @selfcalib: optional routine for self-calibration
> * @prepare: optional prepare routine (power-up, enable)
> * @start_conv: routine to start conversions
> * @stop_conv: routine to stop conversions
> @@ -264,7 +265,6 @@ struct stm32_adc_cfg {
> struct stm32_adc_trig_info *trigs;
> bool clk_required;
> bool has_vregready;
> - int (*selfcalib)(struct stm32_adc *);
> int (*prepare)(struct stm32_adc *);
> void (*start_conv)(struct stm32_adc *, bool dma);
> void (*stop_conv)(struct stm32_adc *);
> @@ -777,6 +777,7 @@ static void stm32h7_adc_disable(struct stm32_adc *adc)
> /**
> * stm32h7_adc_read_selfcalib() - read calibration shadow regs, save result
> * @adc: stm32 adc instance
> + * Note: Must be called once ADC is enabled, so LINCALRDYW[1..6] are writable
> */
> static int stm32h7_adc_read_selfcalib(struct stm32_adc *adc)
> {
> @@ -784,11 +785,6 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> int i, ret;
> u32 lincalrdyw_mask, val;
>
> - /* Enable adc so LINCALRDYW1..6 bits are writable */
> - ret = stm32h7_adc_enable(adc);
> - if (ret)
> - return ret;
> -
> /* Read linearity calibration */
> lincalrdyw_mask = STM32H7_LINCALRDYW6;
> for (i = STM32H7_LINCALFACT_NUM - 1; i >= 0; i--) {
> @@ -801,7 +797,7 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> 100, STM32_ADC_TIMEOUT_US);
> if (ret) {
> dev_err(&indio_dev->dev, "Failed to read calfact\n");
> - goto disable;
> + return ret;
> }
>
> val = stm32_adc_readl(adc, STM32H7_ADC_CALFACT2);
> @@ -817,11 +813,9 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> *adc)
> adc->cal.calfact_s >>= STM32H7_CALFACT_S_SHIFT;
> adc->cal.calfact_d = (val & STM32H7_CALFACT_D_MASK);
> adc->cal.calfact_d >>= STM32H7_CALFACT_D_SHIFT;
> + adc->cal.calibrated = true;
>
> -disable:
> - stm32h7_adc_disable(adc);
> -
> - return ret;
> + return 0;
> }
>
> /**
> @@ -898,9 +892,9 @@ static int stm32h7_adc_restore_selfcalib(struct stm32_adc
> *adc)
> #define STM32H7_ADC_CALIB_TIMEOUT_US 10
>
> /**
> - * stm32h7_adc_selfcalib() - Procedure to calibrate ADC (from power down)
> + * stm32h7_adc_selfcalib() - Procedure to calibrate ADC
> * @adc: stm32 adc instance
> - * Exit from power down, calibrate ADC, then return to power down.
> + * Note: Must be called once ADC is out of power down.
> */
> static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> {
> @@ -908,9 +902,8 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> int ret;
> u32 val;
>
> - ret = stm32h7_adc_exit_pwr_down(adc);
> - if (ret)
> - return ret;
> + if (adc->cal.calibrated)
> + return adc->cal.calibrated;
return true seems more logical given this is a boolean.
>
> /*
>* Select calibration mode:
> @@ -927,7 +920,7 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> STM32H7_ADC_CALIB_TIMEOUT_US);
> if (ret) {
> dev_err(&indio_dev->dev, "calibration failed\n");
> - goto pwr_dwn;
> + goto out;
> }
>
> /*
> @@ -944,18 +937,13 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> STM32H7
Re: WARNING in sysfs_remove_group (2)
On 2018/11/25 20:21, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit: e195ca6cb6f2 Merge branch 'for-linus' of git://git.kernel... > git tree: upstream > console output: https://syzkaller.appspot.com/x/log.txt?x=1659a62b40 > kernel config: https://syzkaller.appspot.com/x/.config?x=73e2bc0cb6463446 > dashboard link: https://syzkaller.appspot.com/bug?extid=34cbd0f790e5ab87f63b > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syz repro: https://syzkaller.appspot.com/x/repro.syz?x=14dad1f540 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1211db8340 C reproducer is essentially same with below one. #syz dup: WARNING in kernfs_get
Re: [PATCH 1/3] iio: adc: stm32-adc: move self-calibration to prepare routine
On Sun, 25 Nov 2018 13:03:39 +
Jonathan Cameron wrote:
> On Tue, 20 Nov 2018 11:12:30 +0100
> Fabrice Gasnier wrote:
>
> > Move self-calibration routine to prepare routine.
> > - This is precursor patch to ease power management handling.
> > - This also allow to factorize few error cases (error handling).
> >
> > Signed-off-by: Fabrice Gasnier
> one trivial point inline. Otherwise seems a sensible bit of refactoring.
Given this was the only 'issue' I found in the whole set I've
just applied it with that changed.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/adc/stm32-adc.c | 59
> > ++---
> > 1 file changed, 24 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> > index 3784118..dca8733 100644
> > --- a/drivers/iio/adc/stm32-adc.c
> > +++ b/drivers/iio/adc/stm32-adc.c
> > @@ -199,11 +199,13 @@ struct stm32_adc_trig_info {
> > * @calfact_s: Calibration offset for single ended channels
> > * @calfact_d: Calibration offset in differential
> > * @lincalfact: Linearity calibration factor
> > + * @calibrated: Indicates calibration status
> > */
> > struct stm32_adc_calib {
> > u32 calfact_s;
> > u32 calfact_d;
> > u32 lincalfact[STM32H7_LINCALFACT_NUM];
> > + boolcalibrated;
> > };
> >
> > /**
> > @@ -251,7 +253,6 @@ struct stm32_adc_regspec {
> > * @trigs: external trigger sources
> > * @clk_required: clock is required
> > * @has_vregready: vregready status flag presence
> > - * @selfcalib: optional routine for self-calibration
> > * @prepare: optional prepare routine (power-up, enable)
> > * @start_conv:routine to start conversions
> > * @stop_conv: routine to stop conversions
> > @@ -264,7 +265,6 @@ struct stm32_adc_cfg {
> > struct stm32_adc_trig_info *trigs;
> > bool clk_required;
> > bool has_vregready;
> > - int (*selfcalib)(struct stm32_adc *);
> > int (*prepare)(struct stm32_adc *);
> > void (*start_conv)(struct stm32_adc *, bool dma);
> > void (*stop_conv)(struct stm32_adc *);
> > @@ -777,6 +777,7 @@ static void stm32h7_adc_disable(struct stm32_adc *adc)
> > /**
> > * stm32h7_adc_read_selfcalib() - read calibration shadow regs, save result
> > * @adc: stm32 adc instance
> > + * Note: Must be called once ADC is enabled, so LINCALRDYW[1..6] are
> > writable
> > */
> > static int stm32h7_adc_read_selfcalib(struct stm32_adc *adc)
> > {
> > @@ -784,11 +785,6 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> > int i, ret;
> > u32 lincalrdyw_mask, val;
> >
> > - /* Enable adc so LINCALRDYW1..6 bits are writable */
> > - ret = stm32h7_adc_enable(adc);
> > - if (ret)
> > - return ret;
> > -
> > /* Read linearity calibration */
> > lincalrdyw_mask = STM32H7_LINCALRDYW6;
> > for (i = STM32H7_LINCALFACT_NUM - 1; i >= 0; i--) {
> > @@ -801,7 +797,7 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> >100, STM32_ADC_TIMEOUT_US);
> > if (ret) {
> > dev_err(&indio_dev->dev, "Failed to read calfact\n");
> > - goto disable;
> > + return ret;
> > }
> >
> > val = stm32_adc_readl(adc, STM32H7_ADC_CALFACT2);
> > @@ -817,11 +813,9 @@ static int stm32h7_adc_read_selfcalib(struct stm32_adc
> > *adc)
> > adc->cal.calfact_s >>= STM32H7_CALFACT_S_SHIFT;
> > adc->cal.calfact_d = (val & STM32H7_CALFACT_D_MASK);
> > adc->cal.calfact_d >>= STM32H7_CALFACT_D_SHIFT;
> > + adc->cal.calibrated = true;
> >
> > -disable:
> > - stm32h7_adc_disable(adc);
> > -
> > - return ret;
> > + return 0;
> > }
> >
> > /**
> > @@ -898,9 +892,9 @@ static int stm32h7_adc_restore_selfcalib(struct
> > stm32_adc *adc)
> > #define STM32H7_ADC_CALIB_TIMEOUT_US 10
> >
> > /**
> > - * stm32h7_adc_selfcalib() - Procedure to calibrate ADC (from power down)
> > + * stm32h7_adc_selfcalib() - Procedure to calibrate ADC
> > * @adc: stm32 adc instance
> > - * Exit from power down, calibrate ADC, then return to power down.
> > + * Note: Must be called once ADC is out of power down.
> > */
> > static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> > {
> > @@ -908,9 +902,8 @@ static int stm32h7_adc_selfcalib(struct stm32_adc *adc)
> > int ret;
> > u32 val;
> >
> > - ret = stm32h7_adc_exit_pwr_down(adc);
> > - if (ret)
> > - return ret;
> > + if (adc->cal.calibrated)
> > + return adc->cal.calibrated;
> return true seems more logical given this is a boolean.
>
> >
> > /*
> > * Select calibrat
Re: [PATCH 2/3] iio: adc: stm32-adc: add power management support
On Tue, 20 Nov 2018 11:12:31 +0100
Fabrice Gasnier wrote:
> Add support for runtime PM & sleep. Move all regulator and clock management
> to dedicated HW start/stop routines. Then rely on (runtime) PM OPS to
> call them.
>
> Signed-off-by: Fabrice Gasnier
Whilst I'll be the first to admit that runtime pm in particular
gives me a headache everytime I try to review a patch with it in, this
looks good to me.
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc-core.c | 182
> +++
> drivers/iio/adc/stm32-adc.c | 169
> 2 files changed, 258 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc-core.c
> b/drivers/iio/adc/stm32-adc-core.c
> index ca432e7..2327ec1 100644
> --- a/drivers/iio/adc/stm32-adc-core.c
> +++ b/drivers/iio/adc/stm32-adc-core.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -48,15 +49,19 @@
> #define STM32H7_CKMODE_SHIFT 16
> #define STM32H7_CKMODE_MASK GENMASK(17, 16)
>
> +#define STM32_ADC_CORE_SLEEP_DELAY_MS2000
> +
> /**
> * stm32_adc_common_regs - stm32 common registers, compatible dependent data
> * @csr: common status register offset
> + * @ccr: common control register offset
> * @eoc1:adc1 end of conversion flag in @csr
> * @eoc2:adc2 end of conversion flag in @csr
> * @eoc3:adc3 end of conversion flag in @csr
> */
> struct stm32_adc_common_regs {
> u32 csr;
> + u32 ccr;
> u32 eoc1_msk;
> u32 eoc2_msk;
> u32 eoc3_msk;
> @@ -85,6 +90,7 @@ struct stm32_adc_priv_cfg {
> * @vref:regulator reference
> * @cfg: compatible configuration data
> * @common: common data for all ADC instances
> + * @ccr_bak: backup CCR in low power mode
> */
> struct stm32_adc_priv {
> int irq[STM32_ADC_MAX_ADCS];
> @@ -94,6 +100,7 @@ struct stm32_adc_priv {
> struct regulator*vref;
> const struct stm32_adc_priv_cfg *cfg;
> struct stm32_adc_common common;
> + u32 ccr_bak;
> };
>
> static struct stm32_adc_priv *to_stm32_adc_priv(struct stm32_adc_common *com)
> @@ -265,6 +272,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
> *pdev,
> /* STM32F4 common registers definitions */
> static const struct stm32_adc_common_regs stm32f4_adc_common_regs = {
> .csr = STM32F4_ADC_CSR,
> + .ccr = STM32F4_ADC_CCR,
> .eoc1_msk = STM32F4_EOC1,
> .eoc2_msk = STM32F4_EOC2,
> .eoc3_msk = STM32F4_EOC3,
> @@ -273,6 +281,7 @@ static int stm32h7_adc_clk_sel(struct platform_device
> *pdev,
> /* STM32H7 common registers definitions */
> static const struct stm32_adc_common_regs stm32h7_adc_common_regs = {
> .csr = STM32H7_ADC_CSR,
> + .ccr = STM32H7_ADC_CCR,
> .eoc1_msk = STM32H7_EOC_MST,
> .eoc2_msk = STM32H7_EOC_SLV,
> };
> @@ -379,6 +388,61 @@ static void stm32_adc_irq_remove(struct platform_device
> *pdev,
> }
> }
>
> +static int stm32_adc_core_hw_start(struct device *dev)
> +{
> + struct stm32_adc_common *common = dev_get_drvdata(dev);
> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
> + int ret;
> +
> + ret = regulator_enable(priv->vref);
> + if (ret < 0) {
> + dev_err(dev, "vref enable failed\n");
> + return ret;
> + }
> +
> + if (priv->bclk) {
> + ret = clk_prepare_enable(priv->bclk);
> + if (ret < 0) {
> + dev_err(dev, "bus clk enable failed\n");
> + goto err_regulator_disable;
> + }
> + }
> +
> + if (priv->aclk) {
> + ret = clk_prepare_enable(priv->aclk);
> + if (ret < 0) {
> + dev_err(dev, "adc clk enable failed\n");
> + goto err_bclk_disable;
> + }
> + }
> +
> + writel_relaxed(priv->ccr_bak, priv->common.base + priv->cfg->regs->ccr);
> +
> + return 0;
> +
> +err_bclk_disable:
> + if (priv->bclk)
> + clk_disable_unprepare(priv->bclk);
> +err_regulator_disable:
> + regulator_disable(priv->vref);
> +
> + return ret;
> +}
> +
> +static void stm32_adc_core_hw_stop(struct device *dev)
> +{
> + struct stm32_adc_common *common = dev_get_drvdata(dev);
> + struct stm32_adc_priv *priv = to_stm32_adc_priv(common);
> +
> + /* Backup CCR that may be lost (depends on power state to achieve) */
> + priv->ccr_bak = readl_relaxed(priv->common.base + priv->cfg->regs->ccr);
> + if (priv->aclk)
> + clk_disable_unprepare(priv->aclk);
> + if (priv->bclk)
> + clk_disable_unprepare(priv->bclk);
> + regulator_disable(priv->vref);
> +}
> +
> static int stm
Re: [PATCH 3/3] iio: adc: stm32-adc: switch off running adc when going to low power
On Tue, 20 Nov 2018 11:12:32 +0100
Fabrice Gasnier wrote:
> Switch off ADC when going to low power mode, in case it has been left
> running in buffer mode. Then re-enable it when resuming.
>
> Signed-off-by: Fabrice Gasnier
My suspicion is that we have other drivers not correctly handing this
case, but as far as I can see you have it well covered here.
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/adc/stm32-adc.c | 79
> -
> 1 file changed, 63 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/iio/adc/stm32-adc.c b/drivers/iio/adc/stm32-adc.c
> index 32c9c61..2a9891c 100644
> --- a/drivers/iio/adc/stm32-adc.c
> +++ b/drivers/iio/adc/stm32-adc.c
> @@ -1518,7 +1518,7 @@ static int stm32_adc_dma_start(struct iio_dev
> *indio_dev)
> return 0;
> }
>
> -static int stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> +static int __stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> {
> struct stm32_adc *adc = iio_priv(indio_dev);
> struct device *dev = indio_dev->dev.parent;
> @@ -1542,10 +1542,6 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
> goto err_clr_trig;
> }
>
> - ret = iio_triggered_buffer_postenable(indio_dev);
> - if (ret < 0)
> - goto err_stop_dma;
> -
> /* Reset adc buffer index */
> adc->bufi = 0;
>
> @@ -1556,9 +1552,6 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
>
> return 0;
>
> -err_stop_dma:
> - if (adc->dma_chan)
> - dmaengine_terminate_all(adc->dma_chan);
> err_clr_trig:
> stm32_adc_set_trig(indio_dev, NULL);
> err_pm_put:
> @@ -1568,20 +1561,30 @@ static int stm32_adc_buffer_postenable(struct iio_dev
> *indio_dev)
> return ret;
> }
>
> -static int stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> +static int stm32_adc_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + int ret;
> +
> + ret = iio_triggered_buffer_postenable(indio_dev);
> + if (ret < 0)
> + return ret;
> +
> + ret = __stm32_adc_buffer_postenable(indio_dev);
> + if (ret < 0)
> + iio_triggered_buffer_predisable(indio_dev);
> +
> + return ret;
> +}
> +
> +static void __stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> {
> struct stm32_adc *adc = iio_priv(indio_dev);
> struct device *dev = indio_dev->dev.parent;
> - int ret;
>
> adc->cfg->stop_conv(adc);
> if (!adc->dma_chan)
> stm32_adc_conv_irq_disable(adc);
>
> - ret = iio_triggered_buffer_predisable(indio_dev);
> - if (ret < 0)
> - dev_err(&indio_dev->dev, "predisable failed\n");
> -
> if (adc->dma_chan)
> dmaengine_terminate_all(adc->dma_chan);
>
> @@ -1590,6 +1593,17 @@ static int stm32_adc_buffer_predisable(struct iio_dev
> *indio_dev)
>
> pm_runtime_mark_last_busy(dev);
> pm_runtime_put_autosuspend(dev);
> +}
> +
> +static int stm32_adc_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + int ret;
> +
> + __stm32_adc_buffer_predisable(indio_dev);
> +
> + ret = iio_triggered_buffer_predisable(indio_dev);
> + if (ret < 0)
> + dev_err(&indio_dev->dev, "predisable failed\n");
>
> return ret;
> }
> @@ -2013,6 +2027,40 @@ static int stm32_adc_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> +#if defined(CONFIG_PM_SLEEP)
> +static int stm32_adc_suspend(struct device *dev)
> +{
> + struct stm32_adc *adc = dev_get_drvdata(dev);
> + struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> +
> + if (iio_buffer_enabled(indio_dev))
> + __stm32_adc_buffer_predisable(indio_dev);
> +
> + return pm_runtime_force_suspend(dev);
> +}
> +
> +static int stm32_adc_resume(struct device *dev)
> +{
> + struct stm32_adc *adc = dev_get_drvdata(dev);
> + struct iio_dev *indio_dev = iio_priv_to_dev(adc);
> + int ret;
> +
> + ret = pm_runtime_force_resume(dev);
> + if (ret < 0)
> + return ret;
> +
> + if (!iio_buffer_enabled(indio_dev))
> + return 0;
> +
> + ret = stm32_adc_update_scan_mode(indio_dev,
> + indio_dev->active_scan_mask);
> + if (ret < 0)
> + return ret;
> +
> + return __stm32_adc_buffer_postenable(indio_dev);
> +}
> +#endif
> +
> #if defined(CONFIG_PM)
> static int stm32_adc_runtime_suspend(struct device *dev)
> {
> @@ -2026,8 +2074,7 @@ static int stm32_adc_runtime_resume(struct device *dev)
> #endif
>
> static const struct dev_pm_ops stm32_adc_pm_ops = {
> - SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> - pm_runtime_force_resume)
> + SET_SYSTEM_SLEEP_PM_OPS(stm32_adc_suspend, stm32_adc_resume)
> SET_RUNTIME_PM_OPS(stm32_adc_runtime_suspend, stm32_ad
Re: [PATCH] iio: st_sensors: Fix the sleep time for sampling
On Wed, 21 Nov 2018 13:13:40 +0800 Jian-Hong Pan wrote: > Denis CIOCCA 於 2018年11月20日 週二 上午3:05寫道： > > > > Hi Jian, > > > > Not clear to me why should be + instead of *. > > > > ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling > > time) [s] > > 1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms] > > n * 1000 * (1/Hz) = n times period in milliseconds (n times sample sampling > > time) [ms] > > > > In your case you assume bootime is in milliseconds. > > Yes, I assume that according to the original comment. > > >Maybe we can change the comment and use 'number of samples ...'. > > Making the meaning more clear is better. > > However, does the bootime of the measurement need as the long time to > be enabled? > If the sampling rate is 1Hz and n is 2, then they will do msleep with > 2000 ms for each st_sensors_read_info_raw. Superficially that seems correct as we need to be sure that a reading has occurred. If you want it to be quicker than the ODR should be set faster so that the reading shows up reasonably quickly. At 1Hz and you want to drop 2 samples, it will indeed take 2 seconds. I'm not understanding why this is unexpected? Jonathan > > Regards, > Jian-Hong Pan > > > > > > > -Original Message- > > From: linux-iio-ow...@vger.kernel.org On > > Behalf Of Jian-Hong Pan > > Sent: Sunday, November 18, 2018 10:12 PM > > To: Jonathan Cameron ; Hartmut Knaack ; > > Lars-Peter Clausen ; Peter Meerwald-Stadler > > ; Dominique Martinet > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > li...@endlessm.com; Jian-Hong Pan > > Subject: [PATCH] iio: st_sensors: Fix the sleep time for sampling > > > > According to the description of st_sensor_settings and st_sensor_data > > structures' comments: > > - bootime: samples to discard when sensor passing from power-down to > > power-up. > > - odr: Output data rate of the sensor [Hz]. > > > > The sleep time should be > > sdata->sensor_settings->bootime + 1000 / sdata->odr ms. > > > > Signed-off-by: Jian-Hong Pan > > --- > > drivers/iio/common/st_sensors/st_sensors_core.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/iio/common/st_sensors/st_sensors_core.c > > b/drivers/iio/common/st_sensors/st_sensors_core.c > > index 26fbd1bd9413..6b87ea657a92 100644 > > --- a/drivers/iio/common/st_sensors/st_sensors_core.c > > +++ b/drivers/iio/common/st_sensors/st_sensors_core.c > > @@ -594,7 +594,7 @@ int st_sensors_read_info_raw(struct iio_dev *indio_dev, > > if (err < 0) > > goto out; > > > > - msleep((sdata->sensor_settings->bootime * 1000) / > > sdata->odr); > > + msleep(sdata->sensor_settings->bootime + 1000 / sdata->odr); > > err = st_sensors_read_axis_data(indio_dev, ch, val); > > if (err < 0) > > goto out; > > -- > > 2.11.0 > >
Re: [PATCH 2/2] iio: adc: ti_am335x_tscadc: Improve accuracy of measurement
On Mon, 19 Nov 2018 12:12:36 +0530
Vignesh R wrote:
> When performing single ended measurements with TSCADC, its recommended
> to set negative input (SEL_INM_SWC_3_0) of ADC step to ADC's VREFN in the
> corresponding STEP_CONFIGx register.
> Also, the positive(SEL_RFP_SWC_2_0) and negative(SEL_RFM_SWC_1_0)
> reference voltage for ADC step needs to be set to VREFP and VREFN
> respectively in STEP_CONFIGx register.
> Without these changes, there may be variation of as much as ~2% in the
> ADC's digital output which is bad for precise measurement.
>
> Signed-off-by: Vignesh R
Given the header changes in mfd and the fact not much is going on with this
driver in IIO at the moment, I'm happy for this to go through the mfd tree.
Acked-by: Jonathan Cameron
Thanks,
Jonathan
> ---
> drivers/iio/adc/ti_am335x_adc.c | 5 -
> include/linux/mfd/ti_am335x_tscadc.h | 4
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
> index cafb1dcadc48..9d984f2a8ba7 100644
> --- a/drivers/iio/adc/ti_am335x_adc.c
> +++ b/drivers/iio/adc/ti_am335x_adc.c
> @@ -142,7 +142,10 @@ static void tiadc_step_config(struct iio_dev *indio_dev)
> stepconfig |= STEPCONFIG_MODE_SWCNT;
>
> tiadc_writel(adc_dev, REG_STEPCONFIG(steps),
> - stepconfig | STEPCONFIG_INP(chan));
> + stepconfig | STEPCONFIG_INP(chan) |
> + STEPCONFIG_INM_ADCREFM |
> + STEPCONFIG_RFP_VREFP |
> + STEPCONFIG_RFM_VREFN);
>
> if (adc_dev->open_delay[i] > STEPDELAY_OPEN_MASK) {
> dev_warn(dev, "chan %d open delay truncating to
> 0x3\n",
> diff --git a/include/linux/mfd/ti_am335x_tscadc.h
> b/include/linux/mfd/ti_am335x_tscadc.h
> index b9a53e013bff..483168403ae5 100644
> --- a/include/linux/mfd/ti_am335x_tscadc.h
> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> @@ -78,6 +78,8 @@
> #define STEPCONFIG_YNN BIT(8)
> #define STEPCONFIG_XNP BIT(9)
> #define STEPCONFIG_YPN BIT(10)
> +#define STEPCONFIG_RFP(val) ((val) << 12)
> +#define STEPCONFIG_RFP_VREFP (0x3 << 12)
> #define STEPCONFIG_INM_MASK (0xF << 15)
> #define STEPCONFIG_INM(val) ((val) << 15)
> #define STEPCONFIG_INM_ADCREFM STEPCONFIG_INM(8)
> @@ -86,6 +88,8 @@
> #define STEPCONFIG_INP_AN4 STEPCONFIG_INP(4)
> #define STEPCONFIG_INP_ADCREFM STEPCONFIG_INP(8)
> #define STEPCONFIG_FIFO1 BIT(26)
> +#define STEPCONFIG_RFM(val) ((val) << 23)
> +#define STEPCONFIG_RFM_VREFN (0x3 << 23)
>
> /* Delay register */
> #define STEPDELAY_OPEN_MASK (0x3 << 0)
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
>
> Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> is de facto standard. Existing air quality sensors usually follow
> this convention and are capable of returning measurements using
> this unit.
>
> IIO currently does not offer suitable channel type for this
> type of measurements hence this patch adds this.
>
> In addition, two modifiers are introduced used for distinguishing
> between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> IIO_MOD_PM10 and IIO_MOD_PM2p5.
>
> Signed-off-by: Tomasz Duszynski
> ---
> Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> drivers/iio/industrialio-core.c | 3 +++
> include/uapi/linux/iio/types.h | 3 +++
> tools/iio/iio_event_monitor.c | 6 ++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 8127a08e366d..ce0ed140660d 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> Contact: linux-...@vger.kernel.org
> Description:
> Raw (unscaled) phase difference reading from channel Y
> - that can be processed to radians.
> \ No newline at end of file
> + that can be processed to radians.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> +KernelVersion: 4.21
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Mass concentration reading of particulate matter in ug / m3.
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..2a9ef600c1fb 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_modifier_names[] = {
> @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> /* relies on pairs of these shared then separate */
> diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> index 92baabc103ac..465044b42af5 100644
> --- a/include/uapi/linux/iio/types.h
> +++ b/include/uapi/linux/iio/types.h
> @@ -46,6 +46,7 @@ enum iio_chan_type {
> IIO_GRAVITY,
> IIO_POSITIONRELATIVE,
> IIO_PHASE,
> + IIO_MASSCONCENTRATION,
So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
per cubic meter?
> };
>
> enum iio_modifier {
> @@ -87,6 +88,8 @@ enum iio_modifier {
> IIO_MOD_VOC,
> IIO_MOD_LIGHT_UV,
> IIO_MOD_LIGHT_DUV,
> + IIO_MOD_PM2p5,
I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
a bit non-standard for iio defines/enum.
- Matt
> + IIO_MOD_PM10,
> };
>
> enum iio_event_type {
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index ac2de6b7e89f..f0fcfeddba2b 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> [IIO_GRAVITY] = "gravity",
> [IIO_POSITIONRELATIVE] = "positionrelative",
> [IIO_PHASE] = "phase",
> + [IIO_MASSCONCENTRATION] = "massconcentration",
> };
>
> static const char * const iio_ev_type_text[] = {
> @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> [IIO_MOD_Q] = "q",
> [IIO_MOD_CO2] = "co2",
> [IIO_MOD_VOC] = "voc",
> + [IIO_MOD_PM2p5] = "pm2p5",
> + [IIO_MOD_PM10] = "pm10",
> };
>
> static bool event_is_known(struct iio_event_data *event)
> @@ -156,6 +159,7 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_GRAVITY:
> case IIO_POSITIONRELATIVE:
> case IIO_PHASE:
> + case IIO_MASSCONCENTRATION:
> break;
> default:
> return false;
> @@ -200,6 +204,8 @@ static bool event_is_known(struct iio_event_data *event)
> case IIO_MOD_Q:
> case IIO_MOD_CO2:
> case IIO_MOD_VOC:
> + case IIO_MOD_PM2p5:
> + case IIO_MOD_PM10:
> break;
> default:
> return false;
> --
> 2.19.2
>
Re: [PATCH v4 0/2] dmaengine: add UniPhier MIO DMAC driver
On Sat, Nov 24, 2018 at 11:16 PM Vinod Koul wrote: > > On 12-10-18, 01:41, Masahiro Yamada wrote: > > 1/2: DT-binding > > 2/2: driver > > Applied this series, thanks Thanks. > While building I noticed that we get few warns when compiling with > C=1, I would prefer you fix them. Please send fixes on top of the > applied patches. My code is fine. If you are talking about the following, your sparse is too old. Upgrade your sparse. ./include/linux/overflow.h:285:13: error: undefined identifier '__builtin_mul_overflow' ./include/linux/overflow.h:285:13: error: incorrect type in conditional ./include/linux/overflow.h:285:13:got void ./include/linux/overflow.h:287:13: error: undefined identifier '__builtin_add_overflow' ./include/linux/overflow.h:287:13: error: incorrect type in conditional ./include/linux/overflow.h:287:13:got void ./include/linux/overflow.h:285:13: warning: call with no type! ./include/linux/overflow.h:287:13: warning: call with no type! > Thanks > -- > ~Vinod -- Best Regards Masahiro Yamada
Re: [PATCH v4 1/3] kernel.h: disable type-checks in container_of() for Sparse
On Sat, Nov 24, 2018 at 6:06 PM Miguel Ojeda
wrote:
>
> On Fri, Nov 23, 2018 at 10:14 PM Luc Van Oostenryck
> wrote:
> >
> > On Thu, Nov 22, 2018 at 12:14:20PM +0900, Masahiro Yamada wrote:
> > > When I tried to enable BUILD_BUG_ON for Sparse, the kbuild test robot
> > > reported lots of "unknown expression" warnings from container_of(),
> > > which seemed false positive.
> > >
> > > I addressed this in [1], but fixing Sparse is the right thing to do.
> > >
> > > The issue was fixed by Sparse commit 0eb8175d3e9c ("fix expansion of
> > > function designator"), but it will take time until the fixed version
> > > of Sparse is widely available.
> > >
> > > Disable the container_of() type checks for Sparse for now.
> >
> > I would prefer that developers upgrade their version of sparse but ...
> >
> > Reviewed-by: Luc Van Oostenryck
>
> Indeed. If someone is writing code for the latest kernels, I think it
> is reasonable to assume they are able to use the latest sparse too,
> since it is not required for compilation anyway.
I am OK with either way.
I leave this to Andrew.
--
Best Regards
Masahiro Yamada
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, 25 Nov 2018 05:51:32 -0800
Matt Ranostay wrote:
> On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> >
> > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > is de facto standard. Existing air quality sensors usually follow
> > this convention and are capable of returning measurements using
> > this unit.
> >
> > IIO currently does not offer suitable channel type for this
> > type of measurements hence this patch adds this.
> >
> > In addition, two modifiers are introduced used for distinguishing
> > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> >
> > Signed-off-by: Tomasz Duszynski
> > ---
> > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > drivers/iio/industrialio-core.c | 3 +++
> > include/uapi/linux/iio/types.h | 3 +++
> > tools/iio/iio_event_monitor.c | 6 ++
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > b/Documentation/ABI/testing/sysfs-bus-iio
> > index 8127a08e366d..ce0ed140660d 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > Contact: linux-...@vger.kernel.org
> > Description:
> > Raw (unscaled) phase difference reading from channel Y
> > - that can be processed to radians.
> > \ No newline at end of file
> > + that can be processed to radians.
> > +
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > +KernelVersion: 4.21
> > +Contact: linux-...@vger.kernel.org
> > +Description:
> > + Mass concentration reading of particulate matter in ug / m3.
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index a062cfddc5af..2a9ef600c1fb 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_modifier_names[] = {
> > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > + [IIO_MOD_PM10] = "pm10",
> > };
> >
> > /* relies on pairs of these shared then separate */
> > diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> > index 92baabc103ac..465044b42af5 100644
> > --- a/include/uapi/linux/iio/types.h
> > +++ b/include/uapi/linux/iio/types.h
> > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > IIO_GRAVITY,
> > IIO_POSITIONRELATIVE,
> > IIO_PHASE,
> > + IIO_MASSCONCENTRATION,
>
> So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> per cubic meter?
Currently concentration is defined as a percentage reading of a substance
(which does make me wonder if it is meant to be percentage of the volume or
percentage of the mass?) Either way, if can't convert to a density measurement
as it's a unit free ratio (I think).
>
> > };
> >
> > enum iio_modifier {
> > @@ -87,6 +88,8 @@ enum iio_modifier {
> > IIO_MOD_VOC,
> > IIO_MOD_LIGHT_UV,
> > IIO_MOD_LIGHT_DUV,
> > + IIO_MOD_PM2p5,
>
> I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> a bit non-standard for iio defines/enum.
It is a bit odd and will get us scripted reports so maybe best to
just go upper case and not worry about it.
Jonathan
>
> - Matt
>
> > + IIO_MOD_PM10,
> > };
> >
> > enum iio_event_type {
> > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > index ac2de6b7e89f..f0fcfeddba2b 100644
> > --- a/tools/iio/iio_event_monitor.c
> > +++ b/tools/iio/iio_event_monitor.c
> > @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_ev_type_text[] = {
> > @@ -115,6 +116,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > + [IIO_MOD_PM10]
Re: [PATCH] iio: hid-sensor-hub: clean up indentation, remove extraneous tab
On Sun, 18 Nov 2018 16:27:57 +
Colin King wrote:
> From: Colin Ian King
>
> The statement is indented too much by one level, fix this by
> removing the extraneous tab.
>
> Signed-off-by: Colin Ian King
Applied to the togreg branch of iio.git and pushed out as testing
because lots of other stuff in there needs build testing.
thanks,
Jonathan
> ---
> drivers/iio/common/hid-sensors/hid-sensor-attributes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> index ed3849d6fc6a..b2143d7b4ccb 100644
> --- a/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> +++ b/drivers/iio/common/hid-sensors/hid-sensor-attributes.c
> @@ -336,7 +336,7 @@ static void adjust_exponent_nano(int *val0, int *val1,
> int scale0,
> scale1 = scale1 % pow_10(8 - i);
> }
> *val0 += res;
> - *val1 = scale1 * pow_10(exp);
> + *val1 = scale1 * pow_10(exp);
> } else if (exp < 0) {
> exp = abs(exp);
> if (exp > 9) {
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
wrote:
>
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski
> > > ---
> > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > drivers/iio/industrialio-core.c | 3 +++
> > > include/uapi/linux/iio/types.h | 3 +++
> > > tools/iio/iio_event_monitor.c | 6 ++
> > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > Contact: linux-...@vger.kernel.org
> > > Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > - that can be processed to radians.
> > > \ No newline at end of file
> > > + that can be processed to radians.
> > > +
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact: linux-...@vger.kernel.org
> > > +Description:
> > > + Mass concentration reading of particulate matter in ug /
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY] = "gravity",
> > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > };
> > >
> > > static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > + [IIO_MOD_PM10] = "pm10",
> > > };
> > >
> > > /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > + IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?) Either way, if can't convert to a density
> measurement
> as it's a unit free ratio (I think).
Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
etc) ones are mass/density because on how they work.
But the electro-conductivity sensor that is using IIO_CONCENTRATION
channels is likely from percentage of volume.
- Matt
>
> >
> > > };
> > >
> > > enum iio_modifier {
> > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > IIO_MOD_VOC,
> > > IIO_MOD_LIGHT_UV,
> > > IIO_MOD_LIGHT_DUV,
> > > + IIO_MOD_PM2p5,
> >
> > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > a bit non-standard for iio defines/enum.
> It is a bit odd and will get us scripted reports so maybe best to
> just go upper case and not worry about it.
>
> Jonathan
> >
> > - Matt
> >
> > > + IIO_MOD_PM10,
> > > };
> > >
> > > enum iio_event_type {
> > > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > > index ac2de6b7e89f..f0fcfeddba2b 100644
> > > --- a/tools/iio/iio_event_monitor.c
> > > +++ b/tools/iio/iio_event_monitor.c
> > > @@ -60,6 +60,7 @@ static c
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: > On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > > > At a high level, addressing these issues is straight forward. First, > > > the driver needs to support authorization equivalent to that which is > > > implemented in the current Intel Launch Enclave, ie. control over the > > > SGX_FLAGS_PROVISION_KEY attribute. > > > > I agree, hence my email :) > > Started to scratch my head that is it really an issue that any enclave > can provision in the end? > > Direct quote from your first response: > > "In particular, the ability to run enclaves with the provisioning bit set > is somewhat sensitive, since it effectively allows access to a stable > fingerprint of the system." > > As can be seen from the key derivation table this does not exactly hold > so you should refine your original argument before we can consider any > type of change. > > I just don't see what it is so wrong for any enclave to be able to tell > that it really is an enclave. I mean I can understand why Greg wants LE although I don't understand what benefit does it bring to anyone to lock in for enclave to allow to identify itself. What you are proposing does not really bring any additional security if we consider a threat model where the kernel is an adversary but it makes the software stack more clanky to use. /Jarkko
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 08:35:07AM +, Jonathan Cameron wrote:
> On Sat, 24 Nov 2018 23:14:13 +0100
> Tomasz Duszynski wrote:
>
> > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > is de facto standard. Existing air quality sensors usually follow
> > this convention and are capable of returning measurements using
> > this unit.
> >
> > IIO currently does not offer suitable channel type for this
> > type of measurements hence this patch adds this.
> >
> > In addition, two modifiers are introduced used for distinguishing
> > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> I initially wondered why these particular numbers and why don't
> we provide an attribute specify this separately?
>
> However google suggests these two are pretty much the only
> ones anyone worries about in pollution sensors. I ended
> up fairly quickly at the EPA website
> https://www.epa.gov/pm-pollution/table-historical-particulate-matter-pm-national-ambient-air-quality-standards-naaqs
> which tells me these two have be used since about 1987.
>
Usually sensors can measure more than just PM10 and PM2.5. Fairy
common is measurement of PM1.0. SPS30 additionally measures PM4.0
but frankly I don't now know exactly what's the real usecase for that.
> So I think the modifier route is the right approach here
> (I think we've gotten this wrong in the past such as light
> sensor colours where the list keeps on growing).
>
> I would like a reference or two in the docs though to point
> people to these definitions.
>
Okay, will add something reasonable so everyone interested
could get the basic idea quickly.
> Thanks,
>
> Jonathan
>
> >
> > Signed-off-by: Tomasz Duszynski
> > ---
> > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > drivers/iio/industrialio-core.c | 3 +++
> > include/uapi/linux/iio/types.h | 3 +++
> > tools/iio/iio_event_monitor.c | 6 ++
> > 4 files changed, 22 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > b/Documentation/ABI/testing/sysfs-bus-iio
> > index 8127a08e366d..ce0ed140660d 100644
> > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > Contact: linux-...@vger.kernel.org
> > Description:
> > Raw (unscaled) phase difference reading from channel Y
> > - that can be processed to radians.
> > \ No newline at end of file
> > + that can be processed to radians.
> > +
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > +What:
> > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > +KernelVersion: 4.21
> > +Contact: linux-...@vger.kernel.org
> > +Description:
> > + Mass concentration reading of particulate matter in ug / m3.
> > diff --git a/drivers/iio/industrialio-core.c
> > b/drivers/iio/industrialio-core.c
> > index a062cfddc5af..2a9ef600c1fb 100644
> > --- a/drivers/iio/industrialio-core.c
> > +++ b/drivers/iio/industrialio-core.c
> > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > };
> >
> > static const char * const iio_modifier_names[] = {
> > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > [IIO_MOD_Q] = "q",
> > [IIO_MOD_CO2] = "co2",
> > [IIO_MOD_VOC] = "voc",
> > + [IIO_MOD_PM2p5] = "pm2p5",
> > + [IIO_MOD_PM10] = "pm10",
> > };
> >
> > /* relies on pairs of these shared then separate */
> > diff --git a/include/uapi/linux/iio/types.h b/include/uapi/linux/iio/types.h
> > index 92baabc103ac..465044b42af5 100644
> > --- a/include/uapi/linux/iio/types.h
> > +++ b/include/uapi/linux/iio/types.h
> > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > IIO_GRAVITY,
> > IIO_POSITIONRELATIVE,
> > IIO_PHASE,
> > + IIO_MASSCONCENTRATION,
> > };
> >
> > enum iio_modifier {
> > @@ -87,6 +88,8 @@ enum iio_modifier {
> > IIO_MOD_VOC,
> > IIO_MOD_LIGHT_UV,
> > IIO_MOD_LIGHT_DUV,
> > + IIO_MOD_PM2p5,
> > + IIO_MOD_PM10,
> > };
> >
> > enum iio_event_type {
> > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > index ac2de6b7e89f..f0fcfeddba2b 100644
> > --- a/tools/iio/iio_event_monitor.c
> > +++ b/tools/iio/iio_event_monitor.c
> > @@ -60,6 +60,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > [IIO_GRAVITY] = "gravity",
> > [IIO_POSITIONRELATIVE] = "positionrelative",
> > [IIO_PHASE] = "phase",
> > + [IIO
WARNING: bad usercopy in corrupted (2)
Hello, syzbot found the following crash on: HEAD commit:aea0a897af9e ptp: Fix pass zero to ERR_PTR() in ptp_clock_.. git tree: net-next console output: https://syzkaller.appspot.com/x/log.txt?x=101b91d540 kernel config: https://syzkaller.appspot.com/x/.config?x=c36a72af2123e78a dashboard link: https://syzkaller.appspot.com/bug?extid=d89b30c46434c433dbf8 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=170f6a4740 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12e1df7b40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+d89b30c46434c433d...@syzkaller.appspotmail.com [ cut here ] DEBUG_LOCKS_WARN_ON(!hlock->nest_lock) [ cut here ] Bad or missing usercopy whitelist? Kernel memory overwrite attempt detected to SLAB object 'task_struct' (offset 1432, size 2)! WARNING: CPU: 1 PID: 38 at mm/usercopy.c:83 usercopy_warn+0xee/0x110 mm/usercopy.c:78 Kernel panic - not syncing: panic_on_warn set ... list_add corruption. next->prev should be prev (8881daf2d798), but was 0b7e0c8e49cc0400. (next=8881d9b4a4f0). CPU: 1 PID: 38 Comm: ���ف���d �� Not tainted 4.20.0-rc3+ #312 [ cut here ] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 kernel BUG at lib/list_debug.c:25! [ cut here ] invalid opcode: [#1] PREEMPT SMP KASAN kernel BUG at mm/slab.c:4425! CPU: 0 PID: 8652 Comm: syz-executor607 Not tainted 4.20.0-rc3+ #312 WARNING: CPU: 1 PID: 38 at kernel/rcu/tree_plugin.h:438 __rcu_read_unlock+0x266/0x2e0 kernel/rcu/tree_plugin.h:432 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Modules linked in: RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23 CPU: 1 PID: 38 Comm: ���ف���d �� Not tainted 4.20.0-rc3+ #312 Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37 d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48 c7 c7 a0 d2 60 88 48 89 de e8 6b 37 d2 fd 0f 0b Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RSP: :8881dae07588 EFLAGS: 00010082 usercopy: Kernel memory overwrite attempt detected to SLAB object 'signal_cache' (offset 1328, size 23)! RAX: 0075 RBX: 8881d9b4a4f0 RCX: [ cut here ] RDX: RSI: 8165eaf5 RDI: 0005 kernel BUG at mm/usercopy.c:102! RBP: 8881dae075a0 R08: 8881d25ce100 R09: ed103b5c5020 R10: ed103b5c5020 R11: 8881dae28107 R12: 8881bd890230 R13: dc00 R14: 8881dae07980 R15: 8881daf2d798 FS: 0083c880() GS:8881dae0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7fff14476600 CR3: 0001d2a59000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __list_add include/linux/list.h:60 [inline] list_add include/linux/list.h:79 [inline] list_move include/linux/list.h:171 [inline] detach_tasks kernel/sched/fair.c:7298 [inline] load_balance+0x1b8d/0x39a0 kernel/sched/fair.c:8731 rebalance_domains+0x845/0xdc0 kernel/sched/fair.c:9109 run_rebalance_domains+0x38d/0x500 kernel/sched/fair.c:9731 __do_softirq+0x308/0xb7e kernel/softirq.c:292 invoke_softirq kernel/softirq.c:373 [inline] irq_exit+0x17f/0x1c0 kernel/softirq.c:413 exiting_irq arch/x86/include/asm/apic.h:536 [inline] smp_apic_timer_interrupt+0x1cb/0x760 arch/x86/kernel/apic/apic.c:1061 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:804 RIP: 0033:0x4005dd Code: c9 00 04 00 66 0f 1f 84 00 00 00 00 00 48 8b 05 f1 2e 2d 00 48 85 c0 74 11 bf 3c e8 4b 00 b9 0e 00 00 00 48 89 c6 f3 a6 75 01 48 89 c7 e9 9a ec 01 00 66 2e 0f 1f 84 00 00 00 00 00 8b 05 4a RSP: 002b:7fff144765a8 EFLAGS: 0246 ORIG_RAX: ff13 RAX: RBX: 0002 RCX: 006d2190 RDX: 00402410 RSI: RDI: RBP: 006cc0a8 R08: R09: R10: R11: 0246 R12: 0001 R13: 006d2180 R14: R15: Modules linked in: ---[ end trace eeb5734c13709e17 ]--- invalid opcode: [#2] PREEMPT SMP KASAN CPU: 1 PID: 38 Comm: ���ف���d �� Tainted: G D 4.20.0-rc3+ #312 RIP: 0010:__list_add_valid.cold.2+0xf/0x2a lib/list_debug.c:23 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Code: d1 60 88 e8 a1 37 d2 fd 0f 0b 48 89 de 48 c7 c7 60 d1 60 88 e8 90 37 d2 fd 0f 0b 48 89 d9 48 c7 c7 20 d2 60 88 e8 7f 37 d2 fd <0f> 0b 48 89 f1 48 c7 c7 a0 d2 60 88 48 89 de
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 02:03:16PM +, Jonathan Cameron wrote:
> On Sun, 25 Nov 2018 05:51:32 -0800
> Matt Ranostay wrote:
>
> > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski wrote:
> > >
> > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > is de facto standard. Existing air quality sensors usually follow
> > > this convention and are capable of returning measurements using
> > > this unit.
> > >
> > > IIO currently does not offer suitable channel type for this
> > > type of measurements hence this patch adds this.
> > >
> > > In addition, two modifiers are introduced used for distinguishing
> > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > >
> > > Signed-off-by: Tomasz Duszynski
> > > ---
> > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > drivers/iio/industrialio-core.c | 3 +++
> > > include/uapi/linux/iio/types.h | 3 +++
> > > tools/iio/iio_event_monitor.c | 6 ++
> > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > index 8127a08e366d..ce0ed140660d 100644
> > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > Contact: linux-...@vger.kernel.org
> > > Description:
> > > Raw (unscaled) phase difference reading from channel Y
> > > - that can be processed to radians.
> > > \ No newline at end of file
> > > + that can be processed to radians.
> > > +
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > +What:
> > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > +KernelVersion: 4.21
> > > +Contact: linux-...@vger.kernel.org
> > > +Description:
> > > + Mass concentration reading of particulate matter in ug /
> > > m3.
> > > diff --git a/drivers/iio/industrialio-core.c
> > > b/drivers/iio/industrialio-core.c
> > > index a062cfddc5af..2a9ef600c1fb 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] = {
> > > [IIO_GRAVITY] = "gravity",
> > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > [IIO_PHASE] = "phase",
> > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > };
> > >
> > > static const char * const iio_modifier_names[] = {
> > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > [IIO_MOD_Q] = "q",
> > > [IIO_MOD_CO2] = "co2",
> > > [IIO_MOD_VOC] = "voc",
> > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > + [IIO_MOD_PM10] = "pm10",
> > > };
> > >
> > > /* relies on pairs of these shared then separate */
> > > diff --git a/include/uapi/linux/iio/types.h
> > > b/include/uapi/linux/iio/types.h
> > > index 92baabc103ac..465044b42af5 100644
> > > --- a/include/uapi/linux/iio/types.h
> > > +++ b/include/uapi/linux/iio/types.h
> > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > IIO_GRAVITY,
> > > IIO_POSITIONRELATIVE,
> > > IIO_PHASE,
> > > + IIO_MASSCONCENTRATION,
> >
> > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > per cubic meter?
>
> Currently concentration is defined as a percentage reading of a substance
> (which does make me wonder if it is meant to be percentage of the volume or
> percentage of the mass?) Either way, if can't convert to a density
> measurement
> as it's a unit free ratio (I think).
>
And this is the main reason behind introducing a new channel type.
> >
> > > };
> > >
> > > enum iio_modifier {
> > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > IIO_MOD_VOC,
> > > IIO_MOD_LIGHT_UV,
> > > IIO_MOD_LIGHT_DUV,
> > > + IIO_MOD_PM2p5,
> >
> > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > a bit non-standard for iio defines/enum.
> It is a bit odd and will get us scripted reports so maybe best to
> just go upper case and not worry about it.
>
Initially I came up with IIO_MOD_PM2_5 but eventually replaced
underscore with 'p' meaning 'decimal point'. Anyway, I am okay with the
suggested change.
> Jonathan
> >
> > - Matt
> >
> > > + IIO_MOD_PM10,
> > > };
> > >
> > > enum iio_event_type {
> > > diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> > > index ac2de6b7e89f..f0fcfeddba2b 100644
> > > --- a/tools/iio/iio_event_monitor.c
> > > +++ b/tools/iio/iio_event_monitor.c
> > > @@ -60,6 +60,7 @@ static const char * con
Re: [PATCH 1/3] iio: add IIO_MASSCONCENTRATION channel type
On Sun, Nov 25, 2018 at 06:14:44AM -0800, Matt Ranostay wrote:
> On Sun, Nov 25, 2018 at 6:03 AM Jonathan Cameron
> wrote:
> >
> > On Sun, 25 Nov 2018 05:51:32 -0800
> > Matt Ranostay wrote:
> >
> > > On Sat, Nov 24, 2018 at 2:14 PM Tomasz Duszynski
> > > wrote:
> > > >
> > > > Measuring particulate matter in ug / m3 (micro-grams per cubic meter)
> > > > is de facto standard. Existing air quality sensors usually follow
> > > > this convention and are capable of returning measurements using
> > > > this unit.
> > > >
> > > > IIO currently does not offer suitable channel type for this
> > > > type of measurements hence this patch adds this.
> > > >
> > > > In addition, two modifiers are introduced used for distinguishing
> > > > between coarse (PM10) and fine particles (PM2p5) measurements, i.e
> > > > IIO_MOD_PM10 and IIO_MOD_PM2p5.
> > > >
> > > > Signed-off-by: Tomasz Duszynski
> > > > ---
> > > > Documentation/ABI/testing/sysfs-bus-iio | 11 ++-
> > > > drivers/iio/industrialio-core.c | 3 +++
> > > > include/uapi/linux/iio/types.h | 3 +++
> > > > tools/iio/iio_event_monitor.c | 6 ++
> > > > 4 files changed, 22 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-bus-iio
> > > > b/Documentation/ABI/testing/sysfs-bus-iio
> > > > index 8127a08e366d..ce0ed140660d 100644
> > > > --- a/Documentation/ABI/testing/sysfs-bus-iio
> > > > +++ b/Documentation/ABI/testing/sysfs-bus-iio
> > > > @@ -1684,4 +1684,13 @@ KernelVersion: 4.18
> > > > Contact: linux-...@vger.kernel.org
> > > > Description:
> > > > Raw (unscaled) phase difference reading from channel Y
> > > > - that can be processed to radians.
> > > > \ No newline at end of file
> > > > + that can be processed to radians.
> > > > +
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm2p5_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm2p5_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentration_pm10_input
> > > > +What:
> > > > /sys/bus/iio/devices/iio:deviceX/in_massconcentrationY_pm10_input
> > > > +KernelVersion: 4.21
> > > > +Contact: linux-...@vger.kernel.org
> > > > +Description:
> > > > + Mass concentration reading of particulate matter in ug
> > > > / m3.
> > > > diff --git a/drivers/iio/industrialio-core.c
> > > > b/drivers/iio/industrialio-core.c
> > > > index a062cfddc5af..2a9ef600c1fb 100644
> > > > --- a/drivers/iio/industrialio-core.c
> > > > +++ b/drivers/iio/industrialio-core.c
> > > > @@ -87,6 +87,7 @@ static const char * const iio_chan_type_name_spec[] =
> > > > {
> > > > [IIO_GRAVITY] = "gravity",
> > > > [IIO_POSITIONRELATIVE] = "positionrelative",
> > > > [IIO_PHASE] = "phase",
> > > > + [IIO_MASSCONCENTRATION] = "massconcentration",
> > > > };
> > > >
> > > > static const char * const iio_modifier_names[] = {
> > > > @@ -127,6 +128,8 @@ static const char * const iio_modifier_names[] = {
> > > > [IIO_MOD_Q] = "q",
> > > > [IIO_MOD_CO2] = "co2",
> > > > [IIO_MOD_VOC] = "voc",
> > > > + [IIO_MOD_PM2p5] = "pm2p5",
> > > > + [IIO_MOD_PM10] = "pm10",
> > > > };
> > > >
> > > > /* relies on pairs of these shared then separate */
> > > > diff --git a/include/uapi/linux/iio/types.h
> > > > b/include/uapi/linux/iio/types.h
> > > > index 92baabc103ac..465044b42af5 100644
> > > > --- a/include/uapi/linux/iio/types.h
> > > > +++ b/include/uapi/linux/iio/types.h
> > > > @@ -46,6 +46,7 @@ enum iio_chan_type {
> > > > IIO_GRAVITY,
> > > > IIO_POSITIONRELATIVE,
> > > > IIO_PHASE,
> > > > + IIO_MASSCONCENTRATION,
> > >
> > > So I'm guessing IIO_CONCENTRATION can't be scaled to the micro-grams
> > > per cubic meter?
> >
> > Currently concentration is defined as a percentage reading of a substance
> > (which does make me wonder if it is meant to be percentage of the volume or
> > percentage of the mass?) Either way, if can't convert to a density
> > measurement
> > as it's a unit free ratio (I think).
>
> Seems like it can be both.. guessing all the atmosphere ( CO2, VOC,
> etc) ones are mass/density because on how they work.
Hmm, but still percentage was picked up for IIO_CONCENTRATION which does
really match PM expectations. Perhaps if units were sticked to modifiers
it whould be easier to reuse that.
> But the electro-conductivity sensor that is using IIO_CONCENTRATION
> channels is likely from percentage of volume.
>
> - Matt
>
> >
> > >
> > > > };
> > > >
> > > > enum iio_modifier {
> > > > @@ -87,6 +88,8 @@ enum iio_modifier {
> > > > IIO_MOD_VOC,
> > > > IIO_MOD_LIGHT_UV,
> > > > IIO_MOD_LIGHT_DUV,
> > > > + IIO_MOD_PM2p5,
> > >
> > > I know this is unit of measure but the lowercase p in IIO_MOD_PM2p5 is
> > > a bit non-s
The "udl" driver crashes the kernel.
When I connect my Displaylink DL-165 adapter to my Debian/testing machine, the "udl" driver is loaded and the following error messages appears in kernel logs: Nov 7 20:47:30 wzdell kernel: [ 205.871354] usb 4-1.2: new high-speed USB device number 4 using ehci-pci Nov 7 20:47:35 wzdell kernel: [ 211.209020] usb 4-1.2: New USB device found, idVendor=17e9, idProduct=0290, bcdDevice= 0.01 Nov 7 20:47:35 wzdell kernel: [ 211.209027] usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Nov 7 20:47:35 wzdell kernel: [ 211.209032] usb 4-1.2: Product: DL-165 Adapter Nov 7 20:47:35 wzdell kernel: [ 211.209036] usb 4-1.2: Manufacturer: DisplayLink Nov 7 20:47:35 wzdell kernel: [ 211.209040] usb 4-1.2: SerialNumber: 102140 Nov 7 20:47:35 wzdell mtp-probe: checking bus 4, device 4: "/sys/devices/pci:00/:00:1d.0/usb4/4-1/4-1.2" Nov 7 20:47:35 wzdell mtp-probe: bus: 4, device: 4 was not an MTP device Nov 7 20:47:35 wzdell kernel: [ 211.269753] [drm] vendor descriptor length:22 data:22 5f 01 00 20 05 00 01 03 04 02 Nov 7 20:47:35 wzdell kernel: [ 211.320940] [drm] Cannot find any crtc or sizes Nov 7 20:47:35 wzdell kernel: [ 211.320962] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Nov 7 20:47:35 wzdell kernel: [ 211.320963] [drm] No driver support for vblank timestamp query. Nov 7 20:47:35 wzdell kernel: [ 211.320999] [drm] Initialized udl 0.0.1 20120220 for 4-1.2:1.0 on minor 1 Nov 7 20:47:35 wzdell kernel: [ 211.321002] [drm] Initialized udl on minor 1 Nov 7 20:47:35 wzdell kernel: [ 211.321078] usbcore: registered new interface driver udl Nov 7 20:47:37 wzdell kernel: [ 212.700722] WARNING: CPU: 0 PID: 1024 at /build/linux-iActNR/linux-4.18.10/drivers/gpu/drm/drm_gem.c:893 drm_gem_object_put+0x34/0x40 [drm] Nov 7 20:47:37 wzdell kernel: [ 212.700726] Modules linked in: udl rfcomm ctr ccm cpufreq_userspace cpufreq_conservative cpufreq_powersave bnep bbswitch(O) nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 nft_counter xt_owner xt_state xt_conntrack nf_conntrack libcrc32c nft_compat nf_tables nfnetlink binfmt_misc intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass uvcvideo arc4 iwldvm videobuf2_vmalloc mac80211 videobuf2_memops videobuf2_v4l2 snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel videobuf2_common snd_hda_codec videodev snd_hda_core snd_hwdep snd_pcm snd_timer media snd soundcore i915 btusb btrtl btbcm btintel bluetooth iwlwifi dell_laptop dell_wmi dell_smbios mei_me drbg ansi_cprng mei ecdh_generic wmi_bmof dcdbas cfg80211 drm_kms_helper sparse_keymap dell_wmi_descriptor Nov 7 20:47:37 wzdell kernel: [ 212.700822] intel_cstate drm intel_uncore intel_rapl_perf dell_smm_hwmon evdev iTCO_wdt iTCO_vendor_support joydev rfkill video serio_raw i2c_algo_bit pcspkr sg pcc_cpufreq wmi dell_smo8800 button battery ac parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 crc32c_generic fscrypto ecb algif_skcipher af_alg dm_crypt dm_mod sr_mod cdrom sd_mod ums_realtek uas usb_storage crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc ahci libahci aesni_intel xhci_pci aes_x86_64 ehci_pci crypto_simd libata xhci_hcd ehci_hcd cryptd glue_helper psmouse scsi_mod i2c_i801 r8169 lpc_ich mii usbcore usb_common thermal Nov 7 20:47:37 wzdell kernel: [ 212.700925] CPU: 0 PID: 1024 Comm: Xorg Tainted: G O 4.18.0-2-amd64 #1 Debian 4.18.10-2 Nov 7 20:47:37 wzdell kernel: [ 212.700927] Hardware name: Dell Inc. Dell System Vostro 3750/0VP036, BIOS A14 09/26/2012 Nov 7 20:47:37 wzdell kernel: [ 212.700955] RIP: 0010:drm_gem_object_put+0x34/0x40 [drm] Nov 7 20:47:37 wzdell kernel: [ 212.700957] Code: 53 48 8b 47 08 48 8b 40 68 48 a9 f8 ff ff ff 74 19 48 89 fb e8 7d c3 02 de 84 c0 75 02 5b c3 48 89 df 5b e9 ee fc ff ff f3 c3 <0f> 0b eb e3 0f 1f 84 00 00 00 00 00 66 66 66 66 90 48 8b 42 08 48 Nov 7 20:47:37 wzdell kernel: [ 212.701035] RSP: 0018:ac86826bbd00 EFLAGS: 00010246 Nov 7 20:47:37 wzdell kernel: [ 212.701039] RAX: RBX: 95fc65313800 RCX: Nov 7 20:47:37 wzdell kernel: [ 212.701042] RDX: RSI: 95fc662b0610 RDI: 95fc65313800 Nov 7 20:47:37 wzdell kernel: [ 212.701045] RBP: 95fc31f1a020 R08: 95fc662b0610 R09: 95fc662b06c0 Nov 7 20:47:37 wzdell kernel: [ 212.701047] R10: 0010 R11: 0040 R12: Nov 7 20:47:37 wzdell kernel: [ 212.701050] R13: ac86826bbdc8 R14: ac86826bbdc0 R15: 00b3 Nov 7 20:47:37 wzdell kernel: [ 212.701054] FS: 7f78c0ceba80() GS:95fc7e40() knlGS: Nov 7 20:47:37 wzdell kernel: [ 212.701057] CS: 0010 DS: ES: CR0: 80050033 Nov 7 20:47:37 wzdell kernel: [ 212.701060] CR2: 7f78abdfac94 CR3: 0004287fe002 CR4: 000606f0 Nov 7 20:47:37 wzdell kernel: [ 212.701063] Call Trace: Nov 7 20:47:37 wzdell ke
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
>> On Nov 25, 2018, at 6:53 AM, Jarkko Sakkinen >> wrote: >> >> On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: >> On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: At a high level, addressing these issues is straight forward. First, the driver needs to support authorization equivalent to that which is implemented in the current Intel Launch Enclave, ie. control over the SGX_FLAGS_PROVISION_KEY attribute. >>> >>> I agree, hence my email :) >> >> Started to scratch my head that is it really an issue that any enclave >> can provision in the end? >> >> Direct quote from your first response: >> >> "In particular, the ability to run enclaves with the provisioning bit set >> is somewhat sensitive, since it effectively allows access to a stable >> fingerprint of the system." >> >> As can be seen from the key derivation table this does not exactly hold >> so you should refine your original argument before we can consider any >> type of change. >> >> I just don't see what it is so wrong for any enclave to be able to tell >> that it really is an enclave. > > I mean I can understand why Greg wants LE although I don't understand > what benefit does it bring to anyone to lock in for enclave to allow > to identify itself. > > What you are proposing does not really bring any additional security if > we consider a threat model where the kernel is an adversary but it makes > the software stack more clanky to use. Agreed. What I’m proposing adds additional security if the kernel is *not* compromised. There are other ways to accomplish it that might be better in some respects. For example, there could be /dev/sgx and /dev/sgx_rights/provision. The former exposes the whole sgx API, except that it doesn’t allow provisioning by default. The latter does nothing by itself. To run a provisioning enclave, you open both nodes, then do something like: ioctl(sgx, SGX_IOC_ADD_RIGHT, sgx_provisioning); This requires extra syscalls, but it doesn’t have the combinatorial explosion problem.
[PATCH] MAINTAINERS: change Sparse's maintainer
I'm taking over the maintainance of Sparse so add myself as maintainer and move Christopher's info to CREDITS. Signed-off-by: Luc Van Oostenryck --- CREDITS | 4 MAINTAINERS | 3 +-- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/CREDITS b/CREDITS index 5befd2d71..3d3e79cef 100644 --- a/CREDITS +++ b/CREDITS @@ -2200,6 +2200,10 @@ S: Post Office Box 371 S: North Little Rock, Arkansas 72115 S: USA +N: Christopher Li +E: spa...@chrisli.org +D: Sparse maintainer 2009 - 2018 + N: Stephan Linz E: l...@mazet.de E: stephan.l...@gmx.de diff --git a/MAINTAINERS b/MAINTAINERS index 0abecc528..68c7435f2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -13977,11 +13977,10 @@ F:drivers/tty/serial/sunzilog.h F: drivers/tty/vcc.c SPARSE CHECKER -M: "Christopher Li" +M: "Luc Van Oostenryck" L: linux-spa...@vger.kernel.org W: https://sparse.wiki.kernel.org/ T: git git://git.kernel.org/pub/scm/devel/sparse/sparse.git -T: git git://git.kernel.org/pub/scm/devel/sparse/chrisl/sparse.git S: Maintained F: include/linux/compiler.h -- 2.19.0
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
Hi,
On Sun, Nov 25, 2018 at 11:11:05AM +, Russell King - ARM Linux wrote:
> I think we're better off leaving omap-udc well alone, and if it's
> now broken with DMA, then that's unfortunate - it would require
> someone with the hardware to diagnose the problem and fix it. I
> think trying to convert it to dmaengine would be risking way more
> problems than its worth.
Well, there's also an option to use dmaengine only for 16xx at the
beginning.
My current guess is that 15xx DMA has been broken at least since
65111084c63d ("USB: more omap_udc updates (dma and omap1710)").
There are two changes in that patch that broke it:
"use 16 bit DMA access" ==> CPC off-by-one becomes now off-by-two...?
"allow burst/pack for memory access" ==> no idea why
Below changes get traffic going with DMA & g_ether...
A.
diff --git a/drivers/usb/gadget/udc/omap_udc.c
b/drivers/usb/gadget/udc/omap_udc.c
index fcf13ef33b31..8094a0380057 100644
--- a/drivers/usb/gadget/udc/omap_udc.c
+++ b/drivers/usb/gadget/udc/omap_udc.c
@@ -498,7 +498,7 @@ static u16 dma_dest_len(struct omap_ep *ep, dma_addr_t
start)
end |= start & (0x << 16);
if (cpu_is_omap15xx())
- end++;
+ end += 2;
if (end < start)
end += 0x1;
return end - start;
@@ -730,10 +730,12 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
ep->ep.name, dma_error, ep, &ep->lch);
if (status == 0) {
omap_writew(reg, UDC_TXDMA_CFG);
- /* EMIFF or SDRC */
- omap_set_dma_src_burst_mode(ep->lch,
- OMAP_DMA_DATA_BURST_4);
- omap_set_dma_src_data_pack(ep->lch, 1);
+ if (!cpu_is_omap15xx()) {
+ /* EMIFF or SDRC */
+ omap_set_dma_src_burst_mode(ep->lch,
+ OMAP_DMA_DATA_BURST_4);
+ omap_set_dma_src_data_pack(ep->lch, 1);
+ }
/* TIPB */
omap_set_dma_dest_params(ep->lch,
OMAP_DMA_PORT_TIPB,
@@ -753,10 +755,12 @@ static void dma_channel_claim(struct omap_ep *ep,
unsigned channel)
OMAP_DMA_AMODE_CONSTANT,
UDC_DATA_DMA,
0, 0);
- /* EMIFF or SDRC */
- omap_set_dma_dest_burst_mode(ep->lch,
- OMAP_DMA_DATA_BURST_4);
- omap_set_dma_dest_data_pack(ep->lch, 1);
+ if (!cpu_is_omap15xx()) {
+ /* EMIFF or SDRC */
+ omap_set_dma_dest_burst_mode(ep->lch,
+ OMAP_DMA_DATA_BURST_4);
+ omap_set_dma_dest_data_pack(ep->lch, 1);
+ }
}
}
if (status)
[PATCH] staging: greybus: Parenthesis alignment
Some parameters are aligned with parentheses.
Some parentheses was opened at end of line.
Signed-off-by: Cristian Sicilia
---
Changes on v2:
* There was some function that was splitted in two line,
as suggested, is better to keep it in one line.
drivers/staging/greybus/audio_manager_module.c | 4 +-
drivers/staging/greybus/audio_manager_sysfs.c | 22 ++--
drivers/staging/greybus/audio_module.c | 20 ++--
drivers/staging/greybus/audio_topology.c | 63 ++--
drivers/staging/greybus/bootrom.c | 25 ++---
drivers/staging/greybus/camera.c | 12 +--
drivers/staging/greybus/connection.c | 82 +++
drivers/staging/greybus/control.c | 53 +-
drivers/staging/greybus/es2.c | 70 ++---
drivers/staging/greybus/gpio.c | 39 +++
drivers/staging/greybus/hid.c | 18 ++--
drivers/staging/greybus/i2c.c | 21 ++--
drivers/staging/greybus/module.c | 19 ++--
drivers/staging/greybus/operation.c| 135 +
drivers/staging/greybus/svc.c | 93 +
15 files changed, 343 insertions(+), 333 deletions(-)
diff --git a/drivers/staging/greybus/audio_manager_module.c
b/drivers/staging/greybus/audio_manager_module.c
index 52342e8..2bfd804 100644
--- a/drivers/staging/greybus/audio_manager_module.c
+++ b/drivers/staging/greybus/audio_manager_module.c
@@ -25,8 +25,8 @@ struct gb_audio_manager_module_attribute {
const char *buf, size_t count);
};
-static ssize_t gb_audio_module_attr_show(
- struct kobject *kobj, struct attribute *attr, char *buf)
+static ssize_t gb_audio_module_attr_show(struct kobject *kobj,
+struct attribute *attr, char *buf)
{
struct gb_audio_manager_module_attribute *attribute;
struct gb_audio_manager_module *module;
diff --git a/drivers/staging/greybus/audio_manager_sysfs.c
b/drivers/staging/greybus/audio_manager_sysfs.c
index 283fbed..ab882cc 100644
--- a/drivers/staging/greybus/audio_manager_sysfs.c
+++ b/drivers/staging/greybus/audio_manager_sysfs.c
@@ -11,9 +11,9 @@
#include "audio_manager.h"
#include "audio_manager_private.h"
-static ssize_t manager_sysfs_add_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_add_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
struct gb_audio_manager_module_descriptor desc = { {0} };
@@ -36,9 +36,9 @@ static ssize_t manager_sysfs_add_store(
static struct kobj_attribute manager_add_attribute =
__ATTR(add, 0664, NULL, manager_sysfs_add_store);
-static ssize_t manager_sysfs_remove_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_remove_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
int id;
@@ -57,9 +57,9 @@ static ssize_t manager_sysfs_remove_store(
static struct kobj_attribute manager_remove_attribute =
__ATTR(remove, 0664, NULL, manager_sysfs_remove_store);
-static ssize_t manager_sysfs_dump_store(
- struct kobject *kobj, struct kobj_attribute *attr,
- const char *buf, size_t count)
+static ssize_t manager_sysfs_dump_store(struct kobject *kobj,
+ struct kobj_attribute *attr,
+ const char *buf, size_t count)
{
int id;
@@ -81,8 +81,8 @@ static ssize_t manager_sysfs_dump_store(
static struct kobj_attribute manager_dump_attribute =
__ATTR(dump, 0664, NULL, manager_sysfs_dump_store);
-static void manager_sysfs_init_attribute(
- struct kobject *kobj, struct kobj_attribute *kattr)
+static void manager_sysfs_init_attribute(struct kobject *kobj,
+struct kobj_attribute *kattr)
{
int err;
diff --git a/drivers/staging/greybus/audio_module.c
b/drivers/staging/greybus/audio_module.c
index d065334..300a2b4 100644
--- a/drivers/staging/greybus/audio_module.c
+++ b/drivers/staging/greybus/audio_module.c
@@ -18,7 +18,7 @@
*/
static int gbaudio_request_jack(struct gbaudio_module_info *module,
- struct gb_audio_jack_event_request *req)
+ struct gb_audio_jack_event_request *req)
{
int report;
struct snd_jack *jack = module->headset_jack.jack;
@@ -26,8 +26,8 @@ static int gbaudio_request_jack(struct gbaudio_module_info
*module,
if (!jack) {
dev_err_ratelimited(module->dev,
- "Invalid ja
Re: [PATCH] dmaengine: ti: omap-dma: Configure LCH_TYPE for OMAP1
* Aaro Koskinen [181125 16:58]: > Below changes get traffic going with DMA & g_ether... Oh cool, if you have dma and g_ether working, you should test it with a variable size ping test loop :) That should expose any issues within few minutes. Below is the test script I was using earlier, the tusb6010 comment there is probably no longer valid. Regards, Tony 8< #!/bin/bash # # At least tusb6010 dma needs 32-bit aligned buffers. # That can be done by setting no_skb_reserve with: # musb->g.quirk_avoids_skb_reserve = 1; # device=$1 size=$2 wraps=0 while [ 1 ]; do #echo "Pinging with size $size" if ! ping -w0 -c1 -s$size $device > /dev/null 2>&1; then break; fi size=$(expr $size + 1) if [ $size -gt 8192 ]; then wraps=$(expr $wraps + 1) echo "wrapping ($wraps) at $size" size=1 fi done echo "Test ran up to $size"
Re: Question about "regulator: core: Only count load for enabled consumers" in -next
Hi,
On Sun, Nov 25, 2018 at 1:37 AM Brian Masney wrote:
> I bisected the issue to the following commit:
>
> 5451781dadf8 ("regulator: core: Only count load for enabled consumers")
>
> We have to increase the load for the sdhci in device tree in order for
> the phone to boot properly. This change was made with the commit:
>
> 03864e57770a ("ARM: dts: qcom: msm8974-hammerhead: increase load on l20
> for sdhci")
You have a 200 mA system load on this regulator? I guess this is a
workaround for drivers that don't set the load properly themselves?
I wonder if there is a bug in my patch where the system load doesn't
take effect if nobody ever calls set_load. Let's see... Does the
below fix things for you? It's totally untested and whitespace
damaged but I wanted to get a response out quick and I'm just walking
out the door. I'll test more / dig more either tonight or at work
tomorrow:
+++ b/drivers/regulator/core.c
@@ -1344,6 +1344,12 @@ static int set_machine_constraints(struct
regulator_dev *rdev,
rdev_err(rdev, "failed to set initial mode: %d\n", ret);
return ret;
}
+ } else if (rdev->constraints->system_load) {
+ /*
+* We'll only apply the initial system load if an
+* initial mode wasn't specified.
+*/
+ drms_uA_update(rdev);
}
Re: [PATCH] KVM: X86: Fix scan ioapic use-before-initialization
On 20/11/18 09:34, Wanpeng Li wrote:
> From: Wanpeng Li
>
> Reported by syzkaller:
>
> BUG: unable to handle kernel NULL pointer dereference at 01c8
> PGD 8003ec4da067 P4D 8003ec4da067 PUD 3f7bfa067 PMD 0
> Oops: [#1] PREEMPT SMP PTI
> CPU: 7 PID: 5059 Comm: debug Tainted: G OE 4.19.0-rc5 #16
> RIP: 0010:__lock_acquire+0x1a6/0x1990
> Call Trace:
> lock_acquire+0xdb/0x210
> _raw_spin_lock+0x38/0x70
> kvm_ioapic_scan_entry+0x3e/0x110 [kvm]
> vcpu_enter_guest+0x167e/0x1910 [kvm]
> kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
> kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
> do_vfs_ioctl+0xa5/0x690
> ksys_ioctl+0x6d/0x80
> __x64_sys_ioctl+0x1a/0x20
> do_syscall_64+0x83/0x6e0
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The reason is that the testcase writes hyperv synic HV_X64_MSR_SINT6 msr
> and triggers scan ioapic logic to load synic vectors into EOI exit bitmap.
> However, irqchip is not initialized by this simple testcase, ioapic/apic
> objects should not be accessed.
> This can be triggered by the following program:
>
> #define _GNU_SOURCE
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> uint64_t r[3] = {0x, 0x,
> 0x};
>
> int main(void)
> {
> syscall(__NR_mmap, 0x2000, 0x100, 3, 0x32, -1, 0);
> long res = 0;
> memcpy((void*)0x2040, "/dev/kvm", 9);
> res = syscall(__NR_openat, 0xff9c, 0x2040, 0, 0);
> if (res != -1)
> r[0] = res;
> res = syscall(__NR_ioctl, r[0], 0xae01, 0);
> if (res != -1)
> r[1] = res;
> res = syscall(__NR_ioctl, r[1], 0xae41, 0);
> if (res != -1)
> r[2] = res;
> memcpy(
> (void*)0x2080,
>
> "\x01\x00\x00\x00\x00\x5b\x61\xbb\x96\x00\x00\x40\x00\x00\x00\x00\x01\x00"
>
> "\x08\x00\x00\x00\x00\x00\x0b\x77\xd1\x78\x4d\xd8\x3a\xed\xb1\x5c\x2e\x43"
>
> "\xaa\x43\x39\xd6\xff\xf5\xf0\xa8\x98\xf2\x3e\x37\x29\x89\xde\x88\xc6\x33"
>
> "\xfc\x2a\xdb\xb7\xe1\x4c\xac\x28\x61\x7b\x9c\xa9\xbc\x0d\xa0\x63\xfe\xfe"
>
> "\xe8\x75\xde\xdd\x19\x38\xdc\x34\xf5\xec\x05\xfd\xeb\x5d\xed\x2e\xaf\x22"
>
> "\xfa\xab\xb7\xe4\x42\x67\xd0\xaf\x06\x1c\x6a\x35\x67\x10\x55\xcb",
> 106);
> syscall(__NR_ioctl, r[2], 0x4008ae89, 0x2080);
> syscall(__NR_ioctl, r[2], 0xae80, 0);
> return 0;
> }
>
> This patch fixes it by bailing out scan ioapic if ioapic is not initialized
> in
> kernel.
>
> Reported-by: Wei Wu
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Wei Wu
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/x86.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 66d66d7..14b2bc4 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -7455,7 +7455,8 @@ static void vcpu_scan_ioapic(struct kvm_vcpu *vcpu)
> else {
> if (vcpu->arch.apicv_active)
> kvm_x86_ops->sync_pir_to_irr(vcpu);
> - kvm_ioapic_scan_entry(vcpu, vcpu->arch.ioapic_handled_vectors);
> + if (ioapic_in_kernel(vcpu->kvm))
> + kvm_ioapic_scan_entry(vcpu,
> vcpu->arch.ioapic_handled_vectors);
> }
>
> if (is_guest_mode(vcpu))
>
Queued, thanks.
Paolo
Re: [PATCH] KVM: LAPIC: Fix pv ipis use-before-initialization
On 20/11/18 02:39, Wanpeng Li wrote:
> Reported by syzkaller:
>
> BUG: unable to handle kernel NULL pointer dereference at 0014
> PGD 80040410c067 P4D 80040410c067 PUD 40410d067 PMD 0
> Oops: [#1] PREEMPT SMP PTI
> CPU: 3 PID: 2567 Comm: poc Tainted: G OE 4.19.0-rc5 #16
> RIP: 0010:kvm_pv_send_ipi+0x94/0x350 [kvm]
> Call Trace:
> kvm_emulate_hypercall+0x3cc/0x700 [kvm]
> handle_vmcall+0xe/0x10 [kvm_intel]
> vmx_handle_exit+0xc1/0x11b0 [kvm_intel]
> vcpu_enter_guest+0x9fb/0x1910 [kvm]
> kvm_arch_vcpu_ioctl_run+0x35c/0x610 [kvm]
> kvm_vcpu_ioctl+0x3e9/0x6d0 [kvm]
> do_vfs_ioctl+0xa5/0x690
> ksys_ioctl+0x6d/0x80
> __x64_sys_ioctl+0x1a/0x20
> do_syscall_64+0x83/0x6e0
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The reason is that the apic map has not yet been initialized, the testcase
> triggers pv_send_ipi interface by vmcall which results in kvm->arch.apic_map
> is dereferenced. This patch fixes it by checking whether or not apic map is
> NULL and bailing out immediately if that is the case.
>
> Fixes: 4180bf1b65 (KVM: X86: Implement "send IPI" hypercall)
> Reported-by: Wei Wu
> Cc: Paolo Bonzini
> Cc: Radim Krčmář
> Cc: Wei Wu
> Signed-off-by: Wanpeng Li
> ---
> arch/x86/kvm/lapic.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 3cd227f..09e3a12 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -576,6 +576,11 @@ int kvm_pv_send_ipi(struct kvm *kvm, unsigned long
> ipi_bitmap_low,
> rcu_read_lock();
> map = rcu_dereference(kvm->arch.apic_map);
>
> + if (unlikely(!map)) {
> + count = -EOPNOTSUPP;
> + goto out;
> + }
> +
> if (min > map->max_apic_id)
> goto out;
> /* Bits above cluster_size are masked in the caller. */
>
Queued, thanks.
Paolo
Re: [PATCH] KVM: x86: fix empty-body warnings
On 08/11/18 09:48, Yi Wang wrote:
> We get the following warnings about empty statements when building
> with 'W=1':
>
> arch/x86/kvm/lapic.c:632:53: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1907:42: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1936:65: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
> arch/x86/kvm/lapic.c:1975:44: warning: suggest braces around empty body in an
> ‘if’ statement [-Wempty-body]
>
> Rework the debug helper macro to get rid of these warnings.
>
> Signed-off-by: Yi Wang
> ---
> arch/x86/kvm/lapic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 89db20f..53b8c8e 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -55,7 +55,7 @@
> #define PRIo64 "o"
>
> /* #define apic_debug(fmt,arg...) printk(KERN_WARNING fmt,##arg) */
> -#define apic_debug(fmt, arg...)
> +#define apic_debug(fmt, arg...) do {} while (0)
>
> /* 14 is the version for Xeon and Pentium 8.4.8*/
> #define APIC_VERSION (0x14UL | ((KVM_APIC_LVT_NUM - 1) <<
> 16))
>
Queued, thanks.
Paolo
Re: [PATCH] svm: Add mutex_lock to protect apic_access_page_done on AMD systems
On 12/11/18 14:37, j...@8bytes.org wrote: > On Mon, Nov 12, 2018 at 12:23:14PM +, Suthikulpanit, Suravee wrote: >> From: Wei Wang >> >> There is a race condition when accessing kvm->arch.apic_access_page_done. >> Due to it, x86_set_memory_region will fail when creating the second vcpu >> for a svm guest. >> >> Add a mutex_lock to serialize the accesses to apic_access_page_done. >> This lock is also used by vmx for the same purpose. >> >> Signed-off-by: Wei Wang >> Signed-off-by: Amadeusz Juskowiak >> Signed-off-by: Julian Stecklina >> Signed-off-by: Suravee Suthikulpanit > Reviewed-by: Joerg Roedel Queued, thanks. Paolo
Re: [PATCH] x86/kvm/vmx: fix old-style function declaration
On 08/11/18 04:22, Yi Wang wrote:
> The inline keyword which is not at the beginning of the function
> declaration may trigger the following build warnings, so let's fix it:
>
> arch/x86/kvm/vmx.c:1309:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:5947:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:5985:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
> arch/x86/kvm/vmx.c:6023:1: warning: ‘inline’ is not at beginning of
> declaration [-Wold-style-declaration]
>
> Signed-off-by: Yi Wang
> ---
> arch/x86/kvm/vmx.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index 4555077..cd8355b 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -1306,7 +1306,7 @@ static void vmx_get_segment(struct kvm_vcpu *vcpu,
> static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
> u16 error_code);
> static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
> -static void __always_inline vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type);
>
> static DEFINE_PER_CPU(struct vmcs *, vmxarea);
> @@ -5944,7 +5944,7 @@ static void free_vpid(int vpid)
> spin_unlock(&vmx_vpid_lock);
> }
>
> -static void __always_inline vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_disable_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type)
> {
> int f = sizeof(unsigned long);
> @@ -5982,7 +5982,7 @@ static void __always_inline
> vmx_disable_intercept_for_msr(unsigned long *msr_bit
> }
> }
>
> -static void __always_inline vmx_enable_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_enable_intercept_for_msr(unsigned long
> *msr_bitmap,
>u32 msr, int type)
> {
> int f = sizeof(unsigned long);
> @@ -6020,7 +6020,7 @@ static void __always_inline
> vmx_enable_intercept_for_msr(unsigned long *msr_bitm
> }
> }
>
> -static void __always_inline vmx_set_intercept_for_msr(unsigned long
> *msr_bitmap,
> +static __always_inline void vmx_set_intercept_for_msr(unsigned long
> *msr_bitmap,
> u32 msr, int type, bool
> value)
> {
> if (value)
>
Queued, thanks.
Paolo
Re: [GIT PULL] XArray updates
The pull request you sent on Sat, 24 Nov 2018 09:32:09 -0800: > git://git.infradead.org/users/willy/linux-dax.git xarray has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e2125dac22f2c9c66c412cd8e049a7305af59f73 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] dma-mapping fixes for 4.20
The pull request you sent on Sun, 25 Nov 2018 09:35:52 +0100: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-4.20-3 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/d6d460b89378b1bc6715574cdafd748ba59d5a27 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Please pull NFS client changes
The pull request you sent on Sun, 25 Nov 2018 03:04:11 +: > git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.20-4 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/17c2f540863a6c0faa3f0ede3c785d9427bcaf80 Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
[PATCH] KVM: x86: Trace changes to active TSC offset regardless if vCPU in guest-mode
For some reason, kvm_x86_ops->write_l1_tsc_offset() skipped trace
of change to active TSC offset in case vCPU is in guest-mode.
This patch changes write_l1_tsc_offset() behavior to trace any change
to active TSC offset to aid debugging. The VMX code is changed to
look more similar to SVM, which is in my opinion nicer.
Based on a patch by Liran Alon.
Signed-off-by: Paolo Bonzini
---
Untested still, but throwing it out because it seems pretty
obvious...
arch/x86/kvm/svm.c | 9 +
arch/x86/kvm/vmx.c | 34 +-
2 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index a24733aade4c..0d1a74069a9e 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1456,10 +1456,11 @@ static u64 svm_write_l1_tsc_offset(struct kvm_vcpu
*vcpu, u64 offset)
g_tsc_offset = svm->vmcb->control.tsc_offset -
svm->nested.hsave->control.tsc_offset;
svm->nested.hsave->control.tsc_offset = offset;
- } else
- trace_kvm_write_tsc_offset(vcpu->vcpu_id,
- svm->vmcb->control.tsc_offset,
- offset);
+ }
+
+ trace_kvm_write_tsc_offset(vcpu->vcpu_id,
+ svm->vmcb->control.tsc_offset - g_tsc_offset,
+ offset);
svm->vmcb->control.tsc_offset = offset + g_tsc_offset;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 764c23dc444f..e7d3f7d35355 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3466,24 +3466,24 @@ static u64 vmx_read_l1_tsc_offset(struct kvm_vcpu *vcpu)
static u64 vmx_write_l1_tsc_offset(struct kvm_vcpu *vcpu, u64 offset)
{
- u64 active_offset = offset;
- if (is_guest_mode(vcpu)) {
- /*
-* We're here if L1 chose not to trap WRMSR to TSC. According
-* to the spec, this should set L1's TSC; The offset that L1
-* set for L2 remains unchanged, and still needs to be added
-* to the newly set TSC to get L2's TSC.
-*/
- struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
- if (nested_cpu_has(vmcs12, CPU_BASED_USE_TSC_OFFSETING))
- active_offset += vmcs12->tsc_offset;
- } else {
- trace_kvm_write_tsc_offset(vcpu->vcpu_id,
- vmcs_read64(TSC_OFFSET), offset);
- }
+ struct vmcs12 *vmcs12 = get_vmcs12(vcpu);
+ u64 g_tsc_offset = 0;
+
+ /*
+* We're here if L1 chose not to trap WRMSR to TSC. According
+* to the spec, this should set L1's TSC; The offset that L1
+* set for L2 remains unchanged, and still needs to be added
+* to the newly set TSC to get L2's TSC.
+*/
+ if (is_guest_mode(vcpu) &&
+ (vmcs12->cpu_based_vm_exec_control & CPU_BASED_USE_TSC_OFFSETING))
+ g_tsc_offset = vmcs12->tsc_offset;
- vmcs_write64(TSC_OFFSET, active_offset);
- return active_offset;
+ trace_kvm_write_tsc_offset(vcpu->vcpu_id,
+ vcpu->arch.tsc_offset - g_tsc_offset,
+ offset);
+ vmcs_write64(TSC_OFFSET, offset + g_tsc_offset);
+ return offset + g_tsc_offset;
}
/*
--
1.8.3.1
[PATCH] clk: rockchip: add clock ID of ACODEC for rk3328
This patch adds clock ID of audio CODEC (ACODEC) for rk3328. Signed-off-by: Katsuhiro Suzuki --- include/dt-bindings/clock/rk3328-cru.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/dt-bindings/clock/rk3328-cru.h b/include/dt-bindings/clock/rk3328-cru.h index 9d5f799469ee..bcaa4559ab1b 100644 --- a/include/dt-bindings/clock/rk3328-cru.h +++ b/include/dt-bindings/clock/rk3328-cru.h @@ -172,6 +172,7 @@ #define PCLK_HDCP 232 #define PCLK_DCF 233 #define PCLK_SARADC234 +#define PCLK_ACODECPHY 235 /* hclk gates */ #define HCLK_PERI 308 -- 2.19.1
[PATCH] clk: rockchip: add clock gate of ACODEC for rk3328
This patch adds small changes into clock gate definition to enable
ACODEC for rk3328.
Signed-off-by: Katsuhiro Suzuki
---
drivers/clk/rockchip/clk-rk3328.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3328.c
b/drivers/clk/rockchip/clk-rk3328.c
index 1eb46aa8b2fa..faa94adb2a37 100644
--- a/drivers/clk/rockchip/clk-rk3328.c
+++ b/drivers/clk/rockchip/clk-rk3328.c
@@ -804,7 +804,7 @@ static struct rockchip_clk_branch rk3328_clk_branches[]
__initdata = {
GATE(PCLK_USB3_GRF, "pclk_usb3_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 2, GFLAGS),
GATE(PCLK_USB2_GRF, "pclk_usb2_grf", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 14, GFLAGS),
GATE(0, "pclk_ddrphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 13, GFLAGS),
- GATE(0, "pclk_acodecphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 5, GFLAGS),
+ GATE(PCLK_ACODECPHY, "pclk_acodecphy", "pclk_phy_pre", 0,
RK3328_CLKGATE_CON(17), 5, GFLAGS),
GATE(PCLK_HDMIPHY, "pclk_hdmiphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 7, GFLAGS),
GATE(0, "pclk_vdacphy", "pclk_phy_pre", CLK_IGNORE_UNUSED,
RK3328_CLKGATE_CON(17), 8, GFLAGS),
GATE(0, "pclk_phy_niu", "pclk_phy_pre", 0, RK3328_CLKGATE_CON(15), 15,
GFLAGS),
--
2.19.1
Re: [PATCH] mm: put_and_wait_on_page_locked() while page is migrated
On Sat, Nov 24, 2018 at 7:21 PM Hugh Dickins wrote: > > Linus, I'm addressing this patch to you because I see from Tim Chen's > thread that it would interest you, and you were disappointed not to > root cause the issue back then. I'm not pushing for you to fast-track > this into 4.20-rc, but I expect Andrew will pick it up for mmotm, and > thence linux-next. Or you may spot a terrible defect, but I hope not. The only terrible defect I spot is that I wish the change to the 'lock' argument in wait_on_page_bit_common() came with a comment explaining the new semantics. The old semantics were somewhat obvious (even if not documented): if 'lock' was set, we'd make the wait exclusive, and we'd lock the page before returning. That kind of matches the intuitive meaning for the function prototype, and it's pretty obvious in the callers too. The new semantics don't have the same kind of really intuitive meaning, I feel. That "-1" doesn't mean "unlock", it means "drop page reference", so there is no longer a fairly intuitive and direct mapping between the argument name and type and the behavior of the function. So I don't hate the concept of the patch at all, but I do ask to: - better documentation. This might not be "documentation" at all, maybe that "lock" variable should just be renamed (because it's not about just locking any more), and would be better off as a tristate enum called "behavior" that has "LOCK, DROP, WAIT" values? - while it sounds likely that this is indeed the same issue that plagues us with the insanely long wait-queues, it would be *really* nice to have that actually confirmed. Does somebody still have access to the customer load that triggered the horrible scaling issues before? In particular, on that second issue: the "fixes" that went in for the wait-queues didn't really fix any real scalability problem, it really just fixed the excessive irq latency issues due to the long traversal holding a lock. If this really fixes the fundamental issue, that should show up as an actual performance difference, I'd expect.. End result: I like and approve of the patch, but I'd like it a lot more if the code behavior was clarified a bit, and I'd really like to close the loop on that old nasty page wait queue issue... Linus
Re: [PATCH v17 18/23] platform/x86: Intel SGX driver
On Sun, Nov 25, 2018 at 08:22:35AM -0800, Andy Lutomirski wrote: Good morning to everyone, I hope the weekend continues to proceed well. Proposal follows below for kernel based policy management of enclaves if people want to skip forward. > >> On Nov 25, 2018, at 6:53 AM, Jarkko Sakkinen > >> wrote: > >> > >> On Sat, Nov 24, 2018 at 09:21:14AM -0800, Jarkko Sakkinen wrote: > >> On Thu, Nov 22, 2018 at 07:21:08AM -0800, Andy Lutomirski wrote: > At a high level, addressing these issues is straight forward. First, > the driver needs to support authorization equivalent to that which is > implemented in the current Intel Launch Enclave, ie. control over the > SGX_FLAGS_PROVISION_KEY attribute. > >>> > >>> I agree, hence my email :) > >> > >> Started to scratch my head that is it really an issue that any enclave > >> can provision in the end? > >> > >> Direct quote from your first response: > >> > >> "In particular, the ability to run enclaves with the provisioning bit set > >> is somewhat sensitive, since it effectively allows access to a stable > >> fingerprint of the system." > >> > >> As can be seen from the key derivation table this does not exactly hold > >> so you should refine your original argument before we can consider any > >> type of change. > >> > >> I just don't see what it is so wrong for any enclave to be able to tell > >> that it really is an enclave. > > I mean I can understand why Greg wants LE although I don't understand > > what benefit does it bring to anyone to lock in for enclave to allow > > to identify itself. > > > > What you are proposing does not really bring any additional security if > > we consider a threat model where the kernel is an adversary but it makes > > the software stack more clanky to use. > Agreed. What I'm proposing adds additional security if the kernel is > *not* compromised. Let me use this to stress a concept that I believe is important in this discussion. SGX is enabling technology that allows developers to create software architectures that will deliver their stated security and privacy guarantees irrespective of platform state. It does this by linking 'islands' of execution (enclaves) together through a web of cryptographic guarantees. The notion of a launch enclave is critical to establishing these guarantees. As soon as the kernel becomes involved in implementing SGX security policy the architecture becomes vulnerable to kernel and/or privilege modification attacks. We've talked at length about the provisioning bit, I won't go into details unless people are interested, but the EPID provisioning protocol implements an SGX mediated cryptographic contract that a perpetual platform identifier will not be disclosed to anyone but Intel. The launch enclave is critical to that guarantee. It is completely understandable why a locked down, (non-FLC) hardware platform, is undesirable in this community. That doesn't mean that a launch enclave as a concept is unneeded or necessarily evil. In an FLC environment the kernel assumes responsibility for SGX privacy and security. This means that we need to do at least as well with a kernel based model as to what is currently available. > There are other ways to accomplish it that might be better in some > respects. For example, there could be /dev/sgx and > /dev/sgx_rights/provision. The former exposes the whole sgx API, > except that it doesn???t allow provisioning by default. The latter > does nothing by itself. To run a provisioning enclave, you open both > nodes, then do something like: > > ioctl(sgx, SGX_IOC_ADD_RIGHT, sgx_provisioning); > > This requires extra syscalls, but it doesn't have the combinatorial > explosion problem. Here is a proposal for the driver to add the needed policy control that is 'SGXy' in nature. The 'SGXy' way is to use MRSIGNER values as the currency for security policy management. The driver should establish the equivalent of three linked lists, maintainable via /sysfs pseudo-files or equivalent plumbing. The lists are referenced by the kernel to enforce the following policies. 1.) The right to initialize an enclave without special attributes. 2.) The right to initialize an enclave with the PROVISION_KEY attribute set. 3.) The right to initialize an enclave with the LICENSE_KEY attribute set. The lists are populated with MRSIGNER values of enclaves that are allowed to initialize under the specified conditions. The driver should either establish a 'seal' file or value, ie. MRSIGNER value of all zero's, that once written will not allow further modifications of the list(s). This will allow cryptographically guaranteed policies to be setup at early boot that will limit the ability of subsequent DAC compromises to affect policy management. The lists are obviously vulnerable to a kernel compromise but the vulnerability scope is significantly limited vs. 'can I get root or some other userid'. If we are really concerned about the scope of that
[patch V2 09/28] x86/Kconfig: Select SCHED_SMT if SMP enabled
CONFIG_SCHED_SMT is enabled by all distros, so there is not a real point to have it configurable. The runtime overhead in the core scheduler code is minimal because the actual SMT scheduling parts are conditional on a static key. This allows to expose the scheduler's SMT state static key to the speculation control code. Alternatively the scheduler's static key could be made always available when CONFIG_SMP is enabled, but that's just adding an unused static key to every other architecture for nothing. Signed-off-by: Thomas Gleixner --- arch/x86/Kconfig |8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1001,13 +1001,7 @@ config NR_CPUS to the kernel image. config SCHED_SMT - bool "SMT (Hyperthreading) scheduler support" - depends on SMP - ---help--- - SMT scheduler support improves the CPU scheduler's decision making - when dealing with Intel Pentium 4 chips with HyperThreading at a - cost of slightly increased overhead in some places. If unsure say - N here. + def_bool y if SMP config SCHED_MC def_bool y
[patch V2 11/28] x86/speculation: Rework SMT state change
arch_smt_update() is only called when the sysfs SMT control knob is
changed. This means that when SMT is enabled in the sysfs control knob the
system is considered to have SMT active even if all siblings are offline.
To allow finegrained control of the speculation mitigations, the actual SMT
state is more interesting than the fact that siblings could be enabled.
Rework the code, so arch_smt_update() is invoked from each individual CPU
hotplug function, and simplify the update function while at it.
Signed-off-by: Thomas Gleixner
---
v1 -> v2: Adapt to new header sched/smt.h
---
arch/x86/kernel/cpu/bugs.c | 11 +--
include/linux/sched/smt.h |2 ++
kernel/cpu.c | 15 +--
3 files changed, 16 insertions(+), 12 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
@@ -344,16 +345,14 @@ void arch_smt_update(void)
return;
mutex_lock(&spec_ctrl_mutex);
- mask = x86_spec_ctrl_base;
- if (cpu_smt_control == CPU_SMT_ENABLED)
+
+ mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
+ if (sched_smt_active())
mask |= SPEC_CTRL_STIBP;
- else
- mask &= ~SPEC_CTRL_STIBP;
if (mask != x86_spec_ctrl_base) {
pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
- cpu_smt_control == CPU_SMT_ENABLED ?
- "Enabling" : "Disabling");
+ mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
x86_spec_ctrl_base = mask;
on_each_cpu(update_stibp_msr, NULL, 1);
}
--- a/include/linux/sched/smt.h
+++ b/include/linux/sched/smt.h
@@ -15,4 +15,6 @@ static __always_inline bool sched_smt_ac
static inline bool sched_smt_active(void) { return false; }
#endif
+void arch_smt_update(void);
+
#endif
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -367,6 +368,12 @@ static void lockdep_release_cpus_lock(vo
#endif /* CONFIG_HOTPLUG_CPU */
+/*
+ * Architectures that need SMT-specific errata handling during SMT hotplug
+ * should override this.
+ */
+void __weak arch_smt_update(void) { }
+
#ifdef CONFIG_HOTPLUG_SMT
enum cpuhp_smt_control cpu_smt_control __read_mostly = CPU_SMT_ENABLED;
EXPORT_SYMBOL_GPL(cpu_smt_control);
@@ -1011,6 +1018,7 @@ static int __ref _cpu_down(unsigned int
* concurrent CPU hotplug via cpu_add_remove_lock.
*/
lockup_detector_cleanup();
+ arch_smt_update();
return ret;
}
@@ -1139,6 +1147,7 @@ static int _cpu_up(unsigned int cpu, int
ret = cpuhp_up_callbacks(cpu, st, target);
out:
cpus_write_unlock();
+ arch_smt_update();
return ret;
}
@@ -2055,12 +2064,6 @@ static void cpuhp_online_cpu_device(unsi
kobject_uevent(&dev->kobj, KOBJ_ONLINE);
}
-/*
- * Architectures that need SMT-specific errata handling during SMT hotplug
- * should override this.
- */
-void __weak arch_smt_update(void) { };
-
static int cpuhp_smt_disable(enum cpuhp_smt_control ctrlval)
{
int cpu, ret = 0;
[patch V2 05/28] x86/speculation: Disable STIBP when enhanced IBRS is in use
If enhanced IBRS is active, STIBP is redundant for mitigating Spectre v2
user space exploits from hyperthread sibling.
Disable STIBP when enhanced IBRS is used.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c |7 +++
1 file changed, 7 insertions(+)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -321,6 +321,10 @@ static bool stibp_needed(void)
if (spectre_v2_enabled == SPECTRE_V2_NONE)
return false;
+ /* Enhanced IBRS makes using STIBP unnecessary. */
+ if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
+ return false;
+
if (!boot_cpu_has(X86_FEATURE_STIBP))
return false;
@@ -846,6 +850,9 @@ static ssize_t l1tf_show_state(char *buf
static char *stibp_state(void)
{
+ if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
+ return "";
+
if (x86_spec_ctrl_base & SPEC_CTRL_STIBP)
return ", STIBP";
else
[patch V2 04/28] x86/speculation: Reorganize cpu_show_common()
The Spectre V2 printout in cpu_show_common() handles conditionals for the
various mitigation methods directly in the sprintf() argument list. That's
hard to read and will become unreadable if more complex decisions need to
be made for a particular method.
Move the conditionals for STIBP and IBPB string selection into helper
functions, so they can be extended later on.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -844,6 +844,22 @@ static ssize_t l1tf_show_state(char *buf
}
#endif
+static char *stibp_state(void)
+{
+ if (x86_spec_ctrl_base & SPEC_CTRL_STIBP)
+ return ", STIBP";
+ else
+ return "";
+}
+
+static char *ibpb_state(void)
+{
+ if (boot_cpu_has(X86_FEATURE_USE_IBPB))
+ return ", IBPB";
+ else
+ return "";
+}
+
static ssize_t cpu_show_common(struct device *dev, struct device_attribute
*attr,
char *buf, unsigned int bug)
{
@@ -865,9 +881,9 @@ static ssize_t cpu_show_common(struct de
case X86_BUG_SPECTRE_V2:
return sprintf(buf, "%s%s%s%s%s%s\n",
spectre_v2_strings[spectre_v2_enabled],
- boot_cpu_has(X86_FEATURE_USE_IBPB) ? ", IBPB" :
"",
+ ibpb_state(),
boot_cpu_has(X86_FEATURE_USE_IBRS_FW) ? ",
IBRS_FW" : "",
- (x86_spec_ctrl_base & SPEC_CTRL_STIBP) ? ",
STIBP" : "",
+ stibp_state(),
boot_cpu_has(X86_FEATURE_RSB_CTXSW) ? ", RSB
filling" : "",
spectre_v2_module_string());
[patch V2 22/28] ptrace: Remove unused ptrace_may_access_sched() and MODE_IBRS
The IBPB control code in x86 removed the usage. Remove the functionality
which was introduced for this.
Signed-off-by: Thomas Gleixner
---
include/linux/ptrace.h | 17 -
kernel/ptrace.c| 10 --
2 files changed, 27 deletions(-)
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -64,15 +64,12 @@ extern void exit_ptrace(struct task_stru
#define PTRACE_MODE_NOAUDIT0x04
#define PTRACE_MODE_FSCREDS0x08
#define PTRACE_MODE_REALCREDS 0x10
-#define PTRACE_MODE_SCHED 0x20
-#define PTRACE_MODE_IBPB 0x40
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH |
PTRACE_MODE_REALCREDS)
-#define PTRACE_MODE_SPEC_IBPB (PTRACE_MODE_ATTACH_REALCREDS | PTRACE_MODE_IBPB)
/**
* ptrace_may_access - check whether the caller is permitted to access
@@ -90,20 +87,6 @@ extern void exit_ptrace(struct task_stru
*/
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
-/**
- * ptrace_may_access - check whether the caller is permitted to access
- * a target task.
- * @task: target task
- * @mode: selects type of access and caller credentials
- *
- * Returns true on success, false on denial.
- *
- * Similar to ptrace_may_access(). Only to be called from context switch
- * code. Does not call into audit and the regular LSM hooks due to locking
- * constraints.
- */
-extern bool ptrace_may_access_sched(struct task_struct *task, unsigned int
mode);
-
static inline int ptrace_reparented(struct task_struct *child)
{
return !same_thread_group(child->real_parent, child->parent);
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -261,9 +261,6 @@ static int ptrace_check_attach(struct ta
static int ptrace_has_cap(struct user_namespace *ns, unsigned int mode)
{
- if (mode & PTRACE_MODE_SCHED)
- return false;
-
if (mode & PTRACE_MODE_NOAUDIT)
return has_ns_capability_noaudit(current, ns, CAP_SYS_PTRACE);
else
@@ -331,16 +328,9 @@ static int __ptrace_may_access(struct ta
!ptrace_has_cap(mm->user_ns, mode)))
return -EPERM;
- if (mode & PTRACE_MODE_SCHED)
- return 0;
return security_ptrace_access_check(task, mode);
}
-bool ptrace_may_access_sched(struct task_struct *task, unsigned int mode)
-{
- return __ptrace_may_access(task, mode | PTRACE_MODE_SCHED);
-}
-
bool ptrace_may_access(struct task_struct *task, unsigned int mode)
{
int err;
[patch V2 21/28] x86/speculation: Prepare for conditional IBPB in switch_mm()
The IBPB speculation barrier is issued from switch_mm() when the kernel
switches to a user space task with a different mm than the user space task
which ran last on the same CPU.
An additional optimization is to avoid IBPB when the incoming task can be
ptraced by the outgoing task. This optimization only works when switching
directly between two user space tasks. When switching from a kernel task to
a user space task the optimization fails because the previous task cannot
be accessed anymore. So for quite some scenarios the optimization is just
adding overhead.
The upcoming conditional IBPB support will issue IBPB only for user space
tasks which have the TIF_SPEC_IB bit set. This requires to handle the
following cases:
1) Switch from a user space task (potential attacker) which has
TIF_SPEC_IB set to a user space task (potential victim) which has
TIF_SPEC_IB not set.
2) Switch from a user space task (potential attacker) which has
TIF_SPEC_IB not set to a user space task (potential victim) which has
TIF_SPEC_IB set.
This needs to be optimized for the case where the IBPB can be avoided when
only kernel threads ran in between user space tasks which belong to the
same process.
The current check whether two tasks belong to the same context is using the
tasks context id. While correct, it's simpler to use the mm pointer because
it allows to mangle the TIF_SPEC_IB bit into it. The context id based
mechanism requires extra storage, which creates worse code.
When a task is scheduled out its TIF_SPEC_IB bit is mangled as bit 0 into
the per CPU storage which is used to track the last user space mm which was
running on a CPU. This bit can be used together with the TIF_SPEC_IB bit of
the incoming task to make the decision whether IBPB needs to be issued or
not to cover the two cases above.
As conditional IBPB is going to be the default, remove the dubious ptrace
check for the IBPB always case and simply issue IBPB always when the
process changes.
Move the storage to a different place in the struct as the original one
created a hole.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/nospec-branch.h |2
arch/x86/include/asm/tlbflush.h |8 +-
arch/x86/kernel/cpu/bugs.c | 29 +++--
arch/x86/mm/tlb.c| 109 +--
4 files changed, 110 insertions(+), 38 deletions(-)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -312,6 +312,8 @@ do {
\
} while (0)
DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+DECLARE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
+DECLARE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
#endif /* __ASSEMBLY__ */
--- a/arch/x86/include/asm/tlbflush.h
+++ b/arch/x86/include/asm/tlbflush.h
@@ -169,10 +169,14 @@ struct tlb_state {
#define LOADED_MM_SWITCHING ((struct mm_struct *)1)
+ /* Last user mm for optimizing IBPB */
+ union {
+ struct mm_struct*last_user_mm;
+ unsigned long last_user_mm_ibpb;
+ };
+
u16 loaded_mm_asid;
u16 next_asid;
- /* last user mm's ctx id */
- u64 last_ctx_id;
/*
* We can be in one of several states:
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -56,6 +56,10 @@ u64 __ro_after_init x86_amd_ls_cfg_ssbd_
/* Control conditional STIPB in switch_to() */
DEFINE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+/* Control conditional IBPB in switch_mm() */
+DEFINE_STATIC_KEY_FALSE(switch_mm_cond_ibpb);
+/* Control unconditional IBPB in switch_mm() */
+DEFINE_STATIC_KEY_FALSE(switch_mm_always_ibpb);
void __init check_bugs(void)
{
@@ -331,7 +335,17 @@ spectre_v2_user_select_mitigation(enum s
/* Initialize Indirect Branch Prediction Barrier */
if (boot_cpu_has(X86_FEATURE_IBPB)) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
- pr_info("Spectre v2 mitigation: Enabling Indirect Branch
Prediction Barrier\n");
+
+ switch (mode) {
+ case SPECTRE_V2_USER_STRICT:
+ static_branch_enable(&switch_mm_always_ibpb);
+ break;
+ default:
+ break;
+ }
+
+ pr_info("mitigation: Enabling %s Indirect Branch Prediction
Barrier\n",
+ mode == SPECTRE_V2_USER_STRICT ? "always-on" :
"conditional");
}
/* If enhanced IBRS is enabled no STIPB required */
@@ -955,10 +969,15 @@ static char *stibp_state(void)
static char *ibpb_state(void)
{
- if (boot_cpu_has(X86_FEATURE_USE_IBPB))
- return ", IBPB";
- else
- return "";
+ if (boot_cpu_has(X86_FEATURE_IBPB)) {
+ switch (spectre_v2_user) {
+ case SPECTRE_V2_USER_NONE:
+ return ", IBPB: disabled";
+
[patch V2 17/28] x86/speculation: Add command line control for indirect branch speculation
Add command line control for user space indirect branch speculation
mitigations. The new option is: spectre_v2_user=
The initial options are:
- on: Unconditionally enabled
- off: Unconditionally disabled
-auto: Kernel selects mitigation (default off for now)
When the spectre_v2= command line argument is either 'on' or 'off' this
implies that the application to application control follows that state even
if a contradicting spectre_v2_user= argument is supplied.
Originally-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
V1 -> V2: Change the option to spectre_v2_user=
---
Documentation/admin-guide/kernel-parameters.txt | 32 +
arch/x86/include/asm/nospec-branch.h| 10 +
arch/x86/kernel/cpu/bugs.c | 133
3 files changed, 156 insertions(+), 19 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4194,9 +4194,13 @@
spectre_v2= [X86] Control mitigation of Spectre variant 2
(indirect branch speculation) vulnerability.
+ The default operation protects the kernel from
+ user space attacks.
- on - unconditionally enable
- off - unconditionally disable
+ on - unconditionally enable, implies
+ spectre_v2_user=on
+ off - unconditionally disable, implies
+ spectre_v2_user=off
auto - kernel detects whether your CPU model is
vulnerable
@@ -4206,6 +4210,12 @@
CONFIG_RETPOLINE configuration option, and the
compiler with which the kernel was built.
+ Selecting 'on' will also enable the mitigation
+ against user space to user space task attacks.
+
+ Selecting 'off' will disable both the kernel and
+ the user space protections.
+
Specific mitigations can also be selected manually:
retpoline - replace indirect branches
@@ -4215,6 +4225,24 @@
Not specifying this option is equivalent to
spectre_v2=auto.
+ spectre_v2_user=
+ [X86] Control mitigation of Spectre variant 2
+ (indirect branch speculation) vulnerability between
+ user space tasks
+
+ on - Unconditionally enable mitigations. Is
+ enforced by spectre_v2=on
+
+ off - Unconditionally disable mitigations. Is
+ enforced by spectre_v2=off
+
+ auto- Kernel selects the mitigation depending on
+ the available CPU features and vulnerability.
+ Default is off.
+
+ Not specifying this option is equivalent to
+ spectre_v2_user=auto.
+
spec_store_bypass_disable=
[HW] Control Speculative Store Bypass (SSB) Disable
mitigation
(Speculative Store Bypass vulnerability)
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -3,6 +3,8 @@
#ifndef _ASM_X86_NOSPEC_BRANCH_H_
#define _ASM_X86_NOSPEC_BRANCH_H_
+#include
+
#include
#include
#include
@@ -226,6 +228,12 @@ enum spectre_v2_mitigation {
SPECTRE_V2_IBRS_ENHANCED,
};
+/* The indirect branch speculation control variants */
+enum spectre_v2_user_mitigation {
+ SPECTRE_V2_USER_NONE,
+ SPECTRE_V2_USER_STRICT,
+};
+
/* The Speculative Store Bypass disable variants */
enum ssb_mitigation {
SPEC_STORE_BYPASS_NONE,
@@ -303,6 +311,8 @@ do {
\
preempt_enable(); \
} while (0)
+DECLARE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+
#endif /* __ASSEMBLY__ */
/*
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -54,6 +54,9 @@ static u64 __ro_after_init x86_spec_ctrl
u64 __ro_after_init x86_amd_ls_cfg_base;
u64 __ro_after_init x86_amd_ls_cfg_ssbd_mask;
+/* Control conditional STIPB in switch_to() */
+DEFINE_STATIC_KEY_FALSE(switch_to_cond_stibp);
+
void __init check_bugs(void)
{
identify_boot_cpu();
@@ -199,6 +202,9 @@ static void x86_amd_ssb_disable(void)
static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
SPECTRE_V2_NONE;
+static enum spectre_v2_user_mitigation spectre_v2_user __ro_after_init =
+ SPECTRE_V2_USER_NONE;
+
#ifdef RETPOLINE
static bool spectre_v2_bad_module;
@@ -237,6 +243,104 @@ enum spectre_v2_mitig
[patch V2 18/28] x86/speculation: Prepare for per task indirect branch speculation control
To avoid the overhead of STIBP always on, it's necessary to allow per task
control of STIBP.
Add a new task flag TIF_SPEC_IB and evaluate it during context switch if
SMT is active and flag evaluation is enabled by the speculation control
code. Add the conditional evaluation to x86_virt_spec_ctrl() as well so the
guest/host switch works properly.
This has no effect because TIF_SPEC_IB cannot be set yet and the static key
which controls evaluation is off. Preparatory patch for adding the control
code.
[ tglx: Simplify the context switch logic and make the TIF evaluation
depend on SMP=y and on the static key controlling the conditional
update. Rename it to TIF_SPEC_IB because it controls both STIBP and
IBPB ]
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
v1 -> v2: Remove pointless include. Use consistent comments.
---
arch/x86/include/asm/msr-index.h |5 +++--
arch/x86/include/asm/spec-ctrl.h | 12
arch/x86/include/asm/thread_info.h |5 -
arch/x86/kernel/cpu/bugs.c |4
arch/x86/kernel/process.c | 23 +--
5 files changed, 44 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -41,9 +41,10 @@
#define MSR_IA32_SPEC_CTRL 0x0048 /* Speculation Control */
#define SPEC_CTRL_IBRS (1 << 0) /* Indirect Branch
Restricted Speculation */
-#define SPEC_CTRL_STIBP(1 << 1) /* Single Thread
Indirect Branch Predictors */
+#define SPEC_CTRL_STIBP_SHIFT 1 /* Single Thread Indirect
Branch Predictor (STIBP) bit */
+#define SPEC_CTRL_STIBP(1 << SPEC_CTRL_STIBP_SHIFT)
/* STIBP mask */
#define SPEC_CTRL_SSBD_SHIFT 2 /* Speculative Store Bypass
Disable bit */
-#define SPEC_CTRL_SSBD (1 << SPEC_CTRL_SSBD_SHIFT) /*
Speculative Store Bypass Disable */
+#define SPEC_CTRL_SSBD (1 << SPEC_CTRL_SSBD_SHIFT) /*
Speculative Store Bypass Disable */
#define MSR_IA32_PRED_CMD 0x0049 /* Prediction Command */
#define PRED_CMD_IBPB (1 << 0) /* Indirect Branch
Prediction Barrier */
--- a/arch/x86/include/asm/spec-ctrl.h
+++ b/arch/x86/include/asm/spec-ctrl.h
@@ -53,12 +53,24 @@ static inline u64 ssbd_tif_to_spec_ctrl(
return (tifn & _TIF_SSBD) >> (TIF_SSBD - SPEC_CTRL_SSBD_SHIFT);
}
+static inline u64 stibp_tif_to_spec_ctrl(u64 tifn)
+{
+ BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
+ return (tifn & _TIF_SPEC_IB) >> (TIF_SPEC_IB - SPEC_CTRL_STIBP_SHIFT);
+}
+
static inline unsigned long ssbd_spec_ctrl_to_tif(u64 spec_ctrl)
{
BUILD_BUG_ON(TIF_SSBD < SPEC_CTRL_SSBD_SHIFT);
return (spec_ctrl & SPEC_CTRL_SSBD) << (TIF_SSBD -
SPEC_CTRL_SSBD_SHIFT);
}
+static inline unsigned long stibp_spec_ctrl_to_tif(u64 spec_ctrl)
+{
+ BUILD_BUG_ON(TIF_SPEC_IB < SPEC_CTRL_STIBP_SHIFT);
+ return (spec_ctrl & SPEC_CTRL_STIBP) << (TIF_SPEC_IB -
SPEC_CTRL_STIBP_SHIFT);
+}
+
static inline u64 ssbd_tif_to_amd_ls_cfg(u64 tifn)
{
return (tifn & _TIF_SSBD) ? x86_amd_ls_cfg_ssbd_mask : 0ULL;
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -83,6 +83,7 @@ struct thread_info {
#define TIF_SYSCALL_EMU6 /* syscall emulation active */
#define TIF_SYSCALL_AUDIT 7 /* syscall auditing active */
#define TIF_SECCOMP8 /* secure computing */
+#define TIF_SPEC_IB9 /* Indirect branch speculation
mitigation */
#define TIF_USER_RETURN_NOTIFY 11 /* notify kernel of userspace return */
#define TIF_UPROBE 12 /* breakpointed or singlestepping */
#define TIF_PATCH_PENDING 13 /* pending live patching update */
@@ -110,6 +111,7 @@ struct thread_info {
#define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
#define _TIF_SECCOMP (1 << TIF_SECCOMP)
+#define _TIF_SPEC_IB (1 << TIF_SPEC_IB)
#define _TIF_USER_RETURN_NOTIFY(1 << TIF_USER_RETURN_NOTIFY)
#define _TIF_UPROBE(1 << TIF_UPROBE)
#define _TIF_PATCH_PENDING (1 << TIF_PATCH_PENDING)
@@ -146,7 +148,8 @@ struct thread_info {
/* flags to check in __switch_to() */
#define _TIF_WORK_CTXSW
\
- (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP|_TIF_SSBD)
+ (_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP| \
+_TIF_SSBD|_TIF_SPEC_IB)
#define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
#define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -148,6 +148,10 @@ x86_virt_spec_ctrl(u64 guest_spec_ctrl,
static_cpu_has(X86_FEATURE_AMD_SSBD))
[patch V2 28/28] x86/speculation: Provide IBPB always command line options
Provide the possibility to enable IBPB always in combination with 'prctl'
and 'seccomp'.
Add the extra command line options and rework the IBPB selection to
evaluate the command instead of the mode selected by the STIPB switch case.
Signed-off-by: Thomas Gleixner
---
Documentation/admin-guide/kernel-parameters.txt | 12
arch/x86/kernel/cpu/bugs.c | 34
2 files changed, 35 insertions(+), 11 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4241,11 +4241,23 @@
per thread. The mitigation control state
is inherited on fork.
+ prctl,ibpb
+ - Like "prctl" above, but only STIBP is
+ controlled per thread. IBPB is issued
+ always when switching between different user
+ space processes.
+
seccomp
- Same as "prctl" above, but all seccomp
threads will enable the mitigation unless
they explicitly opt out.
+ seccomp,ibpb
+ - Like "seccomp" above, but only STIBP is
+ controlled per thread. IBPB is issued
+ always when switching between different
+ user space processes.
+
auto- Kernel selects the mitigation depending on
the available CPU features and vulnerability.
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -256,7 +256,9 @@ enum spectre_v2_user_cmd {
SPECTRE_V2_USER_CMD_AUTO,
SPECTRE_V2_USER_CMD_FORCE,
SPECTRE_V2_USER_CMD_PRCTL,
+ SPECTRE_V2_USER_CMD_PRCTL_IBPB,
SPECTRE_V2_USER_CMD_SECCOMP,
+ SPECTRE_V2_USER_CMD_SECCOMP_IBPB,
};
static const char * const spectre_v2_user_strings[] = {
@@ -271,11 +273,13 @@ static const struct {
enum spectre_v2_user_cmdcmd;
boolsecure;
} v2_user_options[] __initdata = {
- { "auto", SPECTRE_V2_USER_CMD_AUTO, false },
- { "off",SPECTRE_V2_USER_CMD_NONE, false },
- { "on", SPECTRE_V2_USER_CMD_FORCE, true },
- { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
- { "seccomp",SPECTRE_V2_USER_CMD_SECCOMP,false },
+ { "auto", SPECTRE_V2_USER_CMD_AUTO, false },
+ { "off",SPECTRE_V2_USER_CMD_NONE, false },
+ { "on", SPECTRE_V2_USER_CMD_FORCE, true },
+ { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
+ { "prctl,ibpb", SPECTRE_V2_USER_CMD_PRCTL_IBPB, false },
+ { "seccomp",SPECTRE_V2_USER_CMD_SECCOMP,false },
+ { "seccomp,ibpb", SPECTRE_V2_USER_CMD_SECCOMP_IBPB, false },
};
static void __init spec_v2_user_print_cond(const char *reason, bool secure)
@@ -321,6 +325,7 @@ spectre_v2_user_select_mitigation(enum s
{
enum spectre_v2_user_mitigation mode = SPECTRE_V2_USER_NONE;
bool smt_possible = IS_ENABLED(CONFIG_SMP);
+ enum spectre_v2_user_cmd cmd;
if (!boot_cpu_has(X86_FEATURE_IBPB) && !boot_cpu_has(X86_FEATURE_STIBP))
return;
@@ -329,17 +334,20 @@ spectre_v2_user_select_mitigation(enum s
cpu_smt_control == CPU_SMT_NOT_SUPPORTED)
smt_possible = false;
- switch (spectre_v2_parse_user_cmdline(v2_cmd)) {
+ cmd = spectre_v2_parse_user_cmdline(v2_cmd);
+ switch (cmd) {
case SPECTRE_V2_USER_CMD_NONE:
goto set_mode;
case SPECTRE_V2_USER_CMD_FORCE:
mode = SPECTRE_V2_USER_STRICT;
break;
case SPECTRE_V2_USER_CMD_PRCTL:
+ case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
mode = SPECTRE_V2_USER_PRCTL;
break;
case SPECTRE_V2_USER_CMD_AUTO:
case SPECTRE_V2_USER_CMD_SECCOMP:
+ case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
if (IS_ENABLED(CONFIG_SECCOMP))
mode = SPECTRE_V2_USER_SECCOMP;
else
@@ -351,12 +359,15 @@ spectre_v2_user_select_mitigation(enum s
if (boot_cpu_has(X86_FEATURE_IBPB)) {
setup_force_cpu_cap(X86_FEATURE_USE_IBPB);
- switch (mode) {
- case SPECTRE_V2_USER_STRICT:
+ switch (cmd) {
+ case SPECTRE_V2_USER_CMD_FORCE:
+ case SPECTRE_V2_USER_CMD_PRCTL_IBPB:
+ case SPECTRE_V2_USER_CMD_SECCOMP_IBPB:
static_branch_enable(&sw
[patch V2 13/28] x86/speculation: Reorder the spec_v2 code
Reorder the code so it is better grouped.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c | 168 ++---
1 file changed, 84 insertions(+), 84 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -124,29 +124,6 @@ void __init check_bugs(void)
#endif
}
-/* The kernel command line selection */
-enum spectre_v2_mitigation_cmd {
- SPECTRE_V2_CMD_NONE,
- SPECTRE_V2_CMD_AUTO,
- SPECTRE_V2_CMD_FORCE,
- SPECTRE_V2_CMD_RETPOLINE,
- SPECTRE_V2_CMD_RETPOLINE_GENERIC,
- SPECTRE_V2_CMD_RETPOLINE_AMD,
-};
-
-static const char *spectre_v2_strings[] = {
- [SPECTRE_V2_NONE] = "Vulnerable",
- [SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic
retpoline",
- [SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD
retpoline",
- [SPECTRE_V2_IBRS_ENHANCED] = "Mitigation: Enhanced IBRS",
-};
-
-#undef pr_fmt
-#define pr_fmt(fmt) "Spectre V2 : " fmt
-
-static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
- SPECTRE_V2_NONE;
-
void
x86_virt_spec_ctrl(u64 guest_spec_ctrl, u64 guest_virt_spec_ctrl, bool
setguest)
{
@@ -216,6 +193,12 @@ static void x86_amd_ssb_disable(void)
wrmsrl(MSR_AMD64_LS_CFG, msrval);
}
+#undef pr_fmt
+#define pr_fmt(fmt) "Spectre V2 : " fmt
+
+static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
+ SPECTRE_V2_NONE;
+
#ifdef RETPOLINE
static bool spectre_v2_bad_module;
@@ -237,18 +220,6 @@ static inline const char *spectre_v2_mod
static inline const char *spectre_v2_module_string(void) { return ""; }
#endif
-static void __init spec2_print_if_insecure(const char *reason)
-{
- if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
- pr_info("%s selected on command line.\n", reason);
-}
-
-static void __init spec2_print_if_secure(const char *reason)
-{
- if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
- pr_info("%s selected on command line.\n", reason);
-}
-
static inline bool match_option(const char *arg, int arglen, const char *opt)
{
int len = strlen(opt);
@@ -256,24 +227,53 @@ static inline bool match_option(const ch
return len == arglen && !strncmp(arg, opt, len);
}
+/* The kernel command line selection for spectre v2 */
+enum spectre_v2_mitigation_cmd {
+ SPECTRE_V2_CMD_NONE,
+ SPECTRE_V2_CMD_AUTO,
+ SPECTRE_V2_CMD_FORCE,
+ SPECTRE_V2_CMD_RETPOLINE,
+ SPECTRE_V2_CMD_RETPOLINE_GENERIC,
+ SPECTRE_V2_CMD_RETPOLINE_AMD,
+};
+
+static const char *spectre_v2_strings[] = {
+ [SPECTRE_V2_NONE] = "Vulnerable",
+ [SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic
retpoline",
+ [SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD
retpoline",
+ [SPECTRE_V2_IBRS_ENHANCED] = "Mitigation: Enhanced IBRS",
+};
+
static const struct {
const char *option;
enum spectre_v2_mitigation_cmd cmd;
bool secure;
} mitigation_options[] = {
- { "off", SPECTRE_V2_CMD_NONE, false },
- { "on",SPECTRE_V2_CMD_FORCE, true },
- { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
- { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false },
- { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
- { "auto", SPECTRE_V2_CMD_AUTO, false },
+ { "off",SPECTRE_V2_CMD_NONE, false },
+ { "on", SPECTRE_V2_CMD_FORCE, true },
+ { "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
+ { "retpoline,amd", SPECTRE_V2_CMD_RETPOLINE_AMD, false },
+ { "retpoline,generic", SPECTRE_V2_CMD_RETPOLINE_GENERIC, false },
+ { "auto", SPECTRE_V2_CMD_AUTO, false },
};
+static void __init spec2_print_if_insecure(const char *reason)
+{
+ if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ pr_info("%s selected on command line.\n", reason);
+}
+
+static void __init spec2_print_if_secure(const char *reason)
+{
+ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ pr_info("%s selected on command line.\n", reason);
+}
+
static enum spectre_v2_mitigation_cmd __init spectre_v2_parse_cmdline(void)
{
+ enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
char arg[20];
int ret, i;
- enum spectre_v2_mitigation_cmd cmd = SPECTRE_V2_CMD_AUTO;
if (cmdline_find_option_bool(boot_command_line, "nospectre_v2"))
return SPECTRE_V2_CMD_NONE;
@@ -317,48 +317,6 @@ static enum spectre_v2_mitigation_cmd __
return cmd;
}
-static bool stibp_needed(void)
-{
- if (spectre_v2_enabled == SPECTRE_V2_NONE)
- return false;
[patch V2 19/28] x86/process: Consolidate and simplify switch_to_xtra() code
Move the conditional invocation of __switch_to_xtra() into an inline
function so the logic can be shared between 32 and 64 bit.
Remove the handthrough of the TSS pointer and retrieve the pointer directly
in the bitmap handling function. Use this_cpu_ptr() instead of the
per_cpu() indirection.
This is a preparatory change so integration of conditional indirect branch
speculation optimization happens only in one place.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/switch_to.h |3 ---
arch/x86/kernel/process.c| 12 +++-
arch/x86/kernel/process.h| 24
arch/x86/kernel/process_32.c | 10 +++---
arch/x86/kernel/process_64.c | 10 +++---
5 files changed, 37 insertions(+), 22 deletions(-)
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -11,9 +11,6 @@ struct task_struct *__switch_to_asm(stru
__visible struct task_struct *__switch_to(struct task_struct *prev,
struct task_struct *next);
-struct tss_struct;
-void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
- struct tss_struct *tss);
/* This runs runs on the previous thread's stack. */
static inline void prepare_switch_to(struct task_struct *next)
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -40,6 +40,8 @@
#include
#include
+#include "process.h"
+
/*
* per-CPU TSS segments. Threads are completely 'soft' on Linux,
* no more per-task TSS's. The TSS size is kept cacheline-aligned
@@ -252,11 +254,12 @@ void arch_setup_new_exec(void)
enable_cpuid();
}
-static inline void switch_to_bitmap(struct tss_struct *tss,
- struct thread_struct *prev,
+static inline void switch_to_bitmap(struct thread_struct *prev,
struct thread_struct *next,
unsigned long tifp, unsigned long tifn)
{
+ struct tss_struct *tss = this_cpu_ptr(&cpu_tss_rw);
+
if (tifn & _TIF_IO_BITMAP) {
/*
* Copy the relevant range of the IO bitmap.
@@ -461,8 +464,7 @@ void speculation_ctrl_update(unsigned lo
preempt_enable();
}
-void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p,
- struct tss_struct *tss)
+void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p)
{
struct thread_struct *prev, *next;
unsigned long tifp, tifn;
@@ -472,7 +474,7 @@ void __switch_to_xtra(struct task_struct
tifn = READ_ONCE(task_thread_info(next_p)->flags);
tifp = READ_ONCE(task_thread_info(prev_p)->flags);
- switch_to_bitmap(tss, prev, next, tifp, tifn);
+ switch_to_bitmap(prev, next, tifp, tifn);
propagate_user_return_notify(prev_p, next_p);
--- /dev/null
+++ b/arch/x86/kernel/process.h
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Code shared between 32 and 64 bit
+
+void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p);
+
+/*
+ * This needs to be inline to optimize for the common case where no extra
+ * work needs to be done.
+ */
+static inline void switch_to_extra(struct task_struct *prev,
+ struct task_struct *next)
+{
+ unsigned long next_tif = task_thread_info(next)->flags;
+ unsigned long prev_tif = task_thread_info(prev)->flags;
+
+ /*
+* __switch_to_xtra() handles debug registers, i/o bitmaps,
+* speculation mitigations etc.
+*/
+ if (unlikely(next_tif & _TIF_WORK_CTXSW_NEXT ||
+prev_tif & _TIF_WORK_CTXSW_PREV))
+ __switch_to_xtra(prev, next);
+}
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -59,6 +59,8 @@
#include
#include
+#include "process.h"
+
void __show_regs(struct pt_regs *regs, enum show_regs_mode mode)
{
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;
@@ -232,7 +234,6 @@ EXPORT_SYMBOL_GPL(start_thread);
struct fpu *prev_fpu = &prev->fpu;
struct fpu *next_fpu = &next->fpu;
int cpu = smp_processor_id();
- struct tss_struct *tss = &per_cpu(cpu_tss_rw, cpu);
/* never put a printk in __switch_to... printk() calls wake_up*()
indirectly */
@@ -264,12 +265,7 @@ EXPORT_SYMBOL_GPL(start_thread);
if (get_kernel_rpl() && unlikely(prev->iopl != next->iopl))
set_iopl_mask(next->iopl);
- /*
-* Now maybe handle debug registers and/or IO bitmaps
-*/
- if (unlikely(task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV ||
-task_thread_info(next_p)->flags & _TIF_WORK_CTXSW_NEXT))
- __switch_to_xtra(prev_p, next_p, tss);
+ switch_to_extra(prev_p, next_p);
/*
* Leave lazy mode, flushing any hypercalls made here.
--- a/arch/x86/kernel/p
[patch V2 26/28] x86/speculation: Enable prctl mode for spectre_v2_user
Now that all prerequisites are in place:
- Add the prctl command line option
- Default the 'auto' mode to 'prctl'
- When SMT state changes, update the static key which controls the
conditional STIBP evaluation on context switch.
- At init update the static key which controls the conditional IBPB
evaluation on context switch.
Signed-off-by: Thomas Gleixner
---
V1 -> V2: Fix comments
s/app2app/user/
Make the IBPB printout depend on the static keys as it can be
independent of the mode, e.g. when SMT is not supported.
Remove the CONFIG_SMP conditional
---
Documentation/admin-guide/kernel-parameters.txt |7 +++-
arch/x86/kernel/cpu/bugs.c | 41 ++--
2 files changed, 38 insertions(+), 10 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4236,9 +4236,14 @@
off - Unconditionally disable mitigations. Is
enforced by spectre_v2=off
+ prctl - Indirect branch speculation is enabled,
+ but mitigation can be enabled via prctl
+ per thread. The mitigation control state
+ is inherited on fork.
+
auto- Kernel selects the mitigation depending on
the available CPU features and vulnerability.
- Default is off.
+ Default is prctl.
Not specifying this option is equivalent to
spectre_v2_user=auto.
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -255,11 +255,13 @@ enum spectre_v2_user_cmd {
SPECTRE_V2_USER_CMD_NONE,
SPECTRE_V2_USER_CMD_AUTO,
SPECTRE_V2_USER_CMD_FORCE,
+ SPECTRE_V2_USER_CMD_PRCTL,
};
static const char * const spectre_v2_user_strings[] = {
[SPECTRE_V2_USER_NONE] = "User space: Vulnerable",
[SPECTRE_V2_USER_STRICT]= "User space: Mitigation: STIBP
protection",
+ [SPECTRE_V2_USER_PRCTL] = "User space: Mitigation: STIBP via
prctl",
};
static const struct {
@@ -270,6 +272,7 @@ static const struct {
{ "auto", SPECTRE_V2_USER_CMD_AUTO, false },
{ "off",SPECTRE_V2_USER_CMD_NONE, false },
{ "on", SPECTRE_V2_USER_CMD_FORCE, true },
+ { "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
};
static void __init spec_v2_user_print_cond(const char *reason, bool secure)
@@ -324,12 +327,15 @@ spectre_v2_user_select_mitigation(enum s
smt_possible = false;
switch (spectre_v2_parse_user_cmdline(v2_cmd)) {
- case SPECTRE_V2_USER_CMD_AUTO:
case SPECTRE_V2_USER_CMD_NONE:
goto set_mode;
case SPECTRE_V2_USER_CMD_FORCE:
mode = SPECTRE_V2_USER_STRICT;
break;
+ case SPECTRE_V2_USER_CMD_AUTO:
+ case SPECTRE_V2_USER_CMD_PRCTL:
+ mode = SPECTRE_V2_USER_PRCTL;
+ break;
}
/* Initialize Indirect Branch Prediction Barrier */
@@ -340,6 +346,9 @@ spectre_v2_user_select_mitigation(enum s
case SPECTRE_V2_USER_STRICT:
static_branch_enable(&switch_mm_always_ibpb);
break;
+ case SPECTRE_V2_USER_PRCTL:
+ static_branch_enable(&switch_mm_cond_ibpb);
+ break;
default:
break;
}
@@ -352,6 +361,12 @@ spectre_v2_user_select_mitigation(enum s
if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
return;
+ /*
+* If SMT is not possible or STIBP is not available clear the STIPB
+* mode.
+*/
+ if (!smt_possible || !boot_cpu_has(X86_FEATURE_STIBP))
+ mode = SPECTRE_V2_USER_NONE;
set_mode:
spectre_v2_user = mode;
/* Only print the STIBP mode when SMT possible */
@@ -552,6 +567,15 @@ static void update_stibp_strict(void)
on_each_cpu(update_stibp_msr, NULL, 1);
}
+/* Update the static key controlling the evaluation of TIF_SPEC_IB */
+static void update_indir_branch_cond(void)
+{
+ if (sched_smt_active())
+ static_branch_enable(&switch_to_cond_stibp);
+ else
+ static_branch_disable(&switch_to_cond_stibp);
+}
+
void arch_smt_update(void)
{
/* Enhanced IBRS implies STIBP. No update required. */
@@ -567,6 +591,7 @@ void arch_smt_update(void)
update_stibp_strict();
break;
case SPECTRE_V2_USER_PRCTL:
+ update_indir_branch_cond();
break;
}
@@ -1042,7 +1067,8 @@ static char *stibp_state(void)
case SPECTRE_V
[patch V2 23/28] x86/speculation: Split out TIF update
The update of the TIF_SSBD flag and the conditional speculation control MSR
update is done in the ssb_prctl_set() function directly. The upcoming prctl
support for controlling indirect branch speculation via STIBP needs the
same mechanism.
Split the code out and make it reusable. Reword the comment about updates
for other tasks.
Signed-off-by: Thomas Gleixner
---
V1 -> V2: Update comment.
---
arch/x86/kernel/cpu/bugs.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -702,10 +702,29 @@ static void ssb_select_mitigation(void)
#undef pr_fmt
#define pr_fmt(fmt) "Speculation prctl: " fmt
-static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
+static void task_update_spec_tif(struct task_struct *tsk, int tifbit, bool on)
{
bool update;
+ if (on)
+ update = !test_and_set_tsk_thread_flag(tsk, tifbit);
+ else
+ update = test_and_clear_tsk_thread_flag(tsk, tifbit);
+
+ /*
+* Immediately update the speculation control MSRs for the current
+* task, but for a non-current task delay setting the CPU
+* mitigation until it is scheduled next.
+*
+* This can only happen for SECCOMP mitigation. For PRCTL it's
+* always the current task.
+*/
+ if (tsk == current && update)
+ speculation_ctrl_update_current();
+}
+
+static int ssb_prctl_set(struct task_struct *task, unsigned long ctrl)
+{
if (ssb_mode != SPEC_STORE_BYPASS_PRCTL &&
ssb_mode != SPEC_STORE_BYPASS_SECCOMP)
return -ENXIO;
@@ -716,28 +735,20 @@ static int ssb_prctl_set(struct task_str
if (task_spec_ssb_force_disable(task))
return -EPERM;
task_clear_spec_ssb_disable(task);
- update = test_and_clear_tsk_thread_flag(task, TIF_SSBD);
+ task_update_spec_tif(task, TIF_SSBD, false);
break;
case PR_SPEC_DISABLE:
task_set_spec_ssb_disable(task);
- update = !test_and_set_tsk_thread_flag(task, TIF_SSBD);
+ task_update_spec_tif(task, TIF_SSBD, true);
break;
case PR_SPEC_FORCE_DISABLE:
task_set_spec_ssb_disable(task);
task_set_spec_ssb_force_disable(task);
- update = !test_and_set_tsk_thread_flag(task, TIF_SSBD);
+ task_update_spec_tif(task, TIF_SSBD, true);
break;
default:
return -ERANGE;
}
-
- /*
-* If being set on non-current task, delay setting the CPU
-* mitigation until it is next scheduled.
-*/
- if (task == current && update)
- speculation_ctrl_update_current();
-
return 0;
}
[patch V2 25/28] x86/speculation: Add prctl() control for indirect branch speculation
Add the PR_SPEC_INDIRECT_BRANCH option for the PR_GET_SPECULATION_CTRL and
PR_SET_SPECULATION_CTRL prctls to allow fine grained per task control of
indirect branch speculation via STIBP and IBPB.
Invocations:
Check indirect branch speculation status with
- prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
Enable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE, 0,
0);
Disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE, 0,
0);
Force disable indirect branch speculation with
- prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH,
PR_SPEC_FORCE_DISABLE, 0, 0);
See Documentation/userspace-api/spec_ctrl.rst.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
V1 -> V2: s/INDIR_/INDIRECT_/ in ABI
s/INDIR_BRANCH/IB/ for internal functions and defines
s/app2app/user/
Merge the DISABLE cases
---
Documentation/userspace-api/spec_ctrl.rst |9
arch/x86/include/asm/nospec-branch.h |1
arch/x86/kernel/cpu/bugs.c| 67 ++
include/linux/sched.h |9
include/uapi/linux/prctl.h|1
tools/include/uapi/linux/prctl.h |1
6 files changed, 88 insertions(+)
--- a/Documentation/userspace-api/spec_ctrl.rst
+++ b/Documentation/userspace-api/spec_ctrl.rst
@@ -92,3 +92,12 @@ Speculation misfeature controls
* prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_ENABLE, 0,
0);
* prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_DISABLE, 0,
0);
* prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS,
PR_SPEC_FORCE_DISABLE, 0, 0);
+
+- PR_SPEC_INDIR_BRANCH: Indirect Branch Speculation in User Processes
+(Mitigate Spectre V2 style attacks against user
processes)
+
+ Invocations:
+ * prctl(PR_GET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, 0, 0, 0);
+ * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_ENABLE,
0, 0);
+ * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_DISABLE,
0, 0);
+ * prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH,
PR_SPEC_FORCE_DISABLE, 0, 0);
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -232,6 +232,7 @@ enum spectre_v2_mitigation {
enum spectre_v2_user_mitigation {
SPECTRE_V2_USER_NONE,
SPECTRE_V2_USER_STRICT,
+ SPECTRE_V2_USER_PRCTL,
};
/* The Speculative Store Bypass disable variants */
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -566,6 +566,8 @@ void arch_smt_update(void)
case SPECTRE_V2_USER_STRICT:
update_stibp_strict();
break;
+ case SPECTRE_V2_USER_PRCTL:
+ break;
}
mutex_unlock(&spec_ctrl_mutex);
@@ -756,12 +758,50 @@ static int ssb_prctl_set(struct task_str
return 0;
}
+static int ib_prctl_set(struct task_struct *task, unsigned long ctrl)
+{
+ switch (ctrl) {
+ case PR_SPEC_ENABLE:
+ if (spectre_v2_user == SPECTRE_V2_USER_NONE)
+ return 0;
+ /*
+* Indirect branch speculation is always disabled in strict
+* mode.
+*/
+ if (spectre_v2_user == SPECTRE_V2_USER_STRICT)
+ return -EPERM;
+ task_clear_spec_ib_disable(task);
+ task_update_spec_tif(task, TIF_SPEC_IB, false);
+ break;
+ case PR_SPEC_DISABLE:
+ case PR_SPEC_FORCE_DISABLE:
+ /*
+* Indirect branch speculation is always allowed when
+* mitigation is force disabled.
+*/
+ if (spectre_v2_user == SPECTRE_V2_USER_NONE)
+ return -EPERM;
+ if (spectre_v2_user == SPECTRE_V2_USER_STRICT)
+ return 0;
+ task_set_spec_ib_disable(task);
+ if (ctrl == PR_SPEC_FORCE_DISABLE)
+ task_set_spec_ib_force_disable(task);
+ task_update_spec_tif(task, TIF_SPEC_IB, true);
+ break;
+ default:
+ return -ERANGE;
+ }
+ return 0;
+}
+
int arch_prctl_spec_ctrl_set(struct task_struct *task, unsigned long which,
unsigned long ctrl)
{
switch (which) {
case PR_SPEC_STORE_BYPASS:
return ssb_prctl_set(task, ctrl);
+ case PR_SPEC_INDIRECT_BRANCH:
+ return ib_prctl_set(task, ctrl);
default:
return -ENODEV;
}
@@ -794,11 +834,34 @@ static int ssb_prctl_get(struct task_str
}
}
+static int ib_prctl_get(struct task_struct *task)
+{
+ if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ return PR_SPEC_NOT_AFFECTED;
+
+ swi
[patch V2 16/28] x86/speculation: Unify conditional spectre v2 print functions
There is no point in having two functions and a conditional at the call
site.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -257,15 +257,9 @@ static const struct {
{ "auto", SPECTRE_V2_CMD_AUTO, false },
};
-static void __init spec2_print_if_insecure(const char *reason)
+static void __init spec_v2_print_cond(const char *reason, bool secure)
{
- if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
- pr_info("%s selected on command line.\n", reason);
-}
-
-static void __init spec2_print_if_secure(const char *reason)
-{
- if (!boot_cpu_has_bug(X86_BUG_SPECTRE_V2))
+ if (boot_cpu_has_bug(X86_BUG_SPECTRE_V2) != secure)
pr_info("%s selected on command line.\n", reason);
}
@@ -309,11 +303,8 @@ static enum spectre_v2_mitigation_cmd __
return SPECTRE_V2_CMD_AUTO;
}
- if (mitigation_options[i].secure)
- spec2_print_if_secure(mitigation_options[i].option);
- else
- spec2_print_if_insecure(mitigation_options[i].option);
-
+ spec_v2_print_cond(mitigation_options[i].option,
+ mitigation_options[i].secure);
return cmd;
}
[patch V2 24/28] x86/speculation: Prepare arch_smt_update() for PRCTL mode
The upcoming fine grained per task STIBP control needs to be updated on CPU
hotplug as well.
Split out the code which controls the strict mode so the prctl control code
can be added later. Mark the SMP function call argument __unused while at it.
Signed-off-by: Thomas Gleixner
---
v1 -> v2: s/app2app/user/. Mark smp function argument __unused
---
arch/x86/kernel/cpu/bugs.c | 46 -
1 file changed, 25 insertions(+), 21 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -530,40 +530,44 @@ static void __init spectre_v2_select_mit
arch_smt_update();
}
-static bool stibp_needed(void)
+static void update_stibp_msr(void * __unused)
{
- /* Enhanced IBRS makes using STIBP unnecessary. */
- if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
- return false;
-
- /* Check for strict user mitigation mode */
- return spectre_v2_user == SPECTRE_V2_USER_STRICT;
+ wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
}
-static void update_stibp_msr(void *info)
+/* Update x86_spec_ctrl_base in case SMT state changed. */
+static void update_stibp_strict(void)
{
- wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
+ u64 mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
+
+ if (sched_smt_active())
+ mask |= SPEC_CTRL_STIBP;
+
+ if (mask == x86_spec_ctrl_base)
+ return;
+
+ pr_info("Spectre v2 user space SMT mitigation: STIBP %s\n",
+ mask & SPEC_CTRL_STIBP ? "always-on" : "off");
+ x86_spec_ctrl_base = mask;
+ on_each_cpu(update_stibp_msr, NULL, 1);
}
void arch_smt_update(void)
{
- u64 mask;
-
- if (!stibp_needed())
+ /* Enhanced IBRS implies STIBP. No update required. */
+ if (spectre_v2_enabled == SPECTRE_V2_IBRS_ENHANCED)
return;
mutex_lock(&spec_ctrl_mutex);
- mask = x86_spec_ctrl_base & ~SPEC_CTRL_STIBP;
- if (sched_smt_active())
- mask |= SPEC_CTRL_STIBP;
-
- if (mask != x86_spec_ctrl_base) {
- pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
- mask & SPEC_CTRL_STIBP ? "Enabling" : "Disabling");
- x86_spec_ctrl_base = mask;
- on_each_cpu(update_stibp_msr, NULL, 1);
+ switch (spectre_v2_user) {
+ case SPECTRE_V2_USER_NONE:
+ break;
+ case SPECTRE_V2_USER_STRICT:
+ update_stibp_strict();
+ break;
}
+
mutex_unlock(&spec_ctrl_mutex);
}
[patch V2 27/28] x86/speculation: Add seccomp Spectre v2 user space protection mode
If 'prctl' mode of user space protection from spectre v2 is selected
on the kernel command-line, STIBP and IBPB are applied on tasks which
restrict their indirect branch speculation via prctl.
SECCOMP enables the SSBD mitigation for sandboxed tasks already, so it
makes sense to prevent spectre v2 user space to user space attacks as
well.
The mitigation guide documents how STIPB works:
Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
prevents the predicted targets of indirect branches on any logical
processor of that core from being controlled by software that executes
(or executed previously) on another logical processor of the same core.
Ergo setting STIBP protects the task itself from being attacked from a task
running on a different hyper-thread and protects the tasks running on
different hyper-threads from being attacked.
IBPB is issued when the task switches out, so malicious sandbox code cannot
mistrain the branch predictor for the next user space task on the same
logical processor.
Signed-off-by: Jiri Kosina
Signed-off-by: Thomas Gleixner
---
Documentation/admin-guide/kernel-parameters.txt |9 -
arch/x86/include/asm/nospec-branch.h|1 +
arch/x86/kernel/cpu/bugs.c | 17 -
3 files changed, 25 insertions(+), 2 deletions(-)
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4241,9 +4241,16 @@
per thread. The mitigation control state
is inherited on fork.
+ seccomp
+ - Same as "prctl" above, but all seccomp
+ threads will enable the mitigation unless
+ they explicitly opt out.
+
auto- Kernel selects the mitigation depending on
the available CPU features and vulnerability.
- Default is prctl.
+
+ Default mitigation:
+ If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
Not specifying this option is equivalent to
spectre_v2_user=auto.
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -233,6 +233,7 @@ enum spectre_v2_user_mitigation {
SPECTRE_V2_USER_NONE,
SPECTRE_V2_USER_STRICT,
SPECTRE_V2_USER_PRCTL,
+ SPECTRE_V2_USER_SECCOMP,
};
/* The Speculative Store Bypass disable variants */
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -256,12 +256,14 @@ enum spectre_v2_user_cmd {
SPECTRE_V2_USER_CMD_AUTO,
SPECTRE_V2_USER_CMD_FORCE,
SPECTRE_V2_USER_CMD_PRCTL,
+ SPECTRE_V2_USER_CMD_SECCOMP,
};
static const char * const spectre_v2_user_strings[] = {
[SPECTRE_V2_USER_NONE] = "User space: Vulnerable",
[SPECTRE_V2_USER_STRICT]= "User space: Mitigation: STIBP
protection",
[SPECTRE_V2_USER_PRCTL] = "User space: Mitigation: STIBP via
prctl",
+ [SPECTRE_V2_USER_SECCOMP] = "User space: Mitigation: STIBP via
seccomp and prctl",
};
static const struct {
@@ -273,6 +275,7 @@ static const struct {
{ "off",SPECTRE_V2_USER_CMD_NONE, false },
{ "on", SPECTRE_V2_USER_CMD_FORCE, true },
{ "prctl", SPECTRE_V2_USER_CMD_PRCTL, false },
+ { "seccomp",SPECTRE_V2_USER_CMD_SECCOMP,false },
};
static void __init spec_v2_user_print_cond(const char *reason, bool secure)
@@ -332,10 +335,16 @@ spectre_v2_user_select_mitigation(enum s
case SPECTRE_V2_USER_CMD_FORCE:
mode = SPECTRE_V2_USER_STRICT;
break;
- case SPECTRE_V2_USER_CMD_AUTO:
case SPECTRE_V2_USER_CMD_PRCTL:
mode = SPECTRE_V2_USER_PRCTL;
break;
+ case SPECTRE_V2_USER_CMD_AUTO:
+ case SPECTRE_V2_USER_CMD_SECCOMP:
+ if (IS_ENABLED(CONFIG_SECCOMP))
+ mode = SPECTRE_V2_USER_SECCOMP;
+ else
+ mode = SPECTRE_V2_USER_PRCTL;
+ break;
}
/* Initialize Indirect Branch Prediction Barrier */
@@ -347,6 +356,7 @@ spectre_v2_user_select_mitigation(enum s
static_branch_enable(&switch_mm_always_ibpb);
break;
case SPECTRE_V2_USER_PRCTL:
+ case SPECTRE_V2_USER_SECCOMP:
static_branch_enable(&switch_mm_cond_ibpb);
break;
default:
@@ -591,6 +601,7 @@ void arch_smt_update(void)
update_stibp_strict();
break;
case SPECTRE_V2_USER_PRCTL:
+ case SPECTRE_V2_USER_SECCOMP:
update_indir_branch_cond();
[patch V2 10/28] sched/smt: Expose sched_smt_present static key
Make the scheduler's 'sched_smt_present' static key globaly available, so
it can be used in the x86 speculation control code.
Provide a query function and a stub for the CONFIG_SMP=n case.
Signed-off-by: Thomas Gleixner
---
v1 -> v2: Move SMT stuff to separate header. Unbreaks ia64 build
---
include/linux/sched/smt.h | 18 ++
kernel/sched/sched.h |4 +---
2 files changed, 19 insertions(+), 3 deletions(-)
--- /dev/null
+++ b/include/linux/sched/smt.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_SCHED_SMT_H
+#define _LINUX_SCHED_SMT_H
+
+#include
+
+#ifdef CONFIG_SCHED_SMT
+extern struct static_key_false sched_smt_present;
+
+static __always_inline bool sched_smt_active(void)
+{
+ return static_branch_likely(&sched_smt_present);
+}
+#else
+static inline bool sched_smt_active(void) { return false; }
+#endif
+
+#endif
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -936,9 +937,6 @@ static inline int cpu_of(struct rq *rq)
#ifdef CONFIG_SCHED_SMT
-
-extern struct static_key_false sched_smt_present;
-
extern void __update_idle_core(struct rq *rq);
static inline void update_idle_core(struct rq *rq)
[patch V2 20/28] x86/speculation: Avoid __switch_to_xtra() calls
The TIF_SPEC_IB bit does not need to be evaluated in the decision to invoke
__switch_to_xtra() when:
- CONFIG_SMP is disabled
- The conditional STIPB mode is disabled
The TIF_SPEC_IB bit still controls IBPB in both cases so the TIF work mask
checks might invoke __switch_to_xtra() for nothing if TIF_SPEC_IB is the
only set bit in the work masks.
Optimize it out by masking the bit at compile time for CONFIG_SMP=n and at
run time when the static key controlling the conditional STIBP mode is
disabled.
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/thread_info.h | 13 +++--
arch/x86/kernel/process.h | 15 +++
2 files changed, 26 insertions(+), 2 deletions(-)
--- a/arch/x86/include/asm/thread_info.h
+++ b/arch/x86/include/asm/thread_info.h
@@ -147,9 +147,18 @@ struct thread_info {
_TIF_FSCHECK)
/* flags to check in __switch_to() */
-#define _TIF_WORK_CTXSW
\
+#define _TIF_WORK_CTXSW_BASE \
(_TIF_IO_BITMAP|_TIF_NOCPUID|_TIF_NOTSC|_TIF_BLOCKSTEP| \
-_TIF_SSBD|_TIF_SPEC_IB)
+_TIF_SSBD)
+
+/*
+ * Avoid calls to __switch_to_xtra() on UP as STIBP is not evaluated.
+ */
+#ifdef CONFIG_SMP
+# define _TIF_WORK_CTXSW (_TIF_WORK_CTXSW_BASE | _TIF_SPEC_IB)
+#else
+# define _TIF_WORK_CTXSW (_TIF_WORK_CTXSW_BASE)
+#endif
#define _TIF_WORK_CTXSW_PREV (_TIF_WORK_CTXSW|_TIF_USER_RETURN_NOTIFY)
#define _TIF_WORK_CTXSW_NEXT (_TIF_WORK_CTXSW)
--- a/arch/x86/kernel/process.h
+++ b/arch/x86/kernel/process.h
@@ -2,6 +2,8 @@
//
// Code shared between 32 and 64 bit
+#include
+
void __switch_to_xtra(struct task_struct *prev_p, struct task_struct *next_p);
/*
@@ -14,6 +16,19 @@ static inline void switch_to_extra(struc
unsigned long next_tif = task_thread_info(next)->flags;
unsigned long prev_tif = task_thread_info(prev)->flags;
+ if (IS_ENABLED(CONFIG_SMP)) {
+ /*
+* Avoid __switch_to_xtra() invocation when conditional
+* STIPB is disabled and the only different bit is
+* TIF_SPEC_IB. For CONFIG_SMP=n TIF_SPEC_IB is not
+* in the TIF_WORK_CTXSW masks.
+*/
+ if (!static_branch_likely(&switch_to_cond_stibp)) {
+ prev_tif &= ~_TIF_SPEC_IB;
+ next_tif &= ~_TIF_SPEC_IB;
+ }
+ }
+
/*
* __switch_to_xtra() handles debug registers, i/o bitmaps,
* speculation mitigations etc.
[patch V2 14/28] x86/speculation: Mark string arrays const correctly
checkpatch.pl muttered when reshuffling the code:
WARNING: static const char * array should probably be static const char * const
Fix up all the string arrays.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -237,7 +237,7 @@ enum spectre_v2_mitigation_cmd {
SPECTRE_V2_CMD_RETPOLINE_AMD,
};
-static const char *spectre_v2_strings[] = {
+static const char * const spectre_v2_strings[] = {
[SPECTRE_V2_NONE] = "Vulnerable",
[SPECTRE_V2_RETPOLINE_GENERIC] = "Mitigation: Full generic
retpoline",
[SPECTRE_V2_RETPOLINE_AMD] = "Mitigation: Full AMD
retpoline",
@@ -476,7 +476,7 @@ enum ssb_mitigation_cmd {
SPEC_STORE_BYPASS_CMD_SECCOMP,
};
-static const char *ssb_strings[] = {
+static const char * const ssb_strings[] = {
[SPEC_STORE_BYPASS_NONE]= "Vulnerable",
[SPEC_STORE_BYPASS_DISABLE] = "Mitigation: Speculative Store Bypass
disabled",
[SPEC_STORE_BYPASS_PRCTL] = "Mitigation: Speculative Store Bypass
disabled via prctl",
@@ -816,7 +816,7 @@ early_param("l1tf", l1tf_cmdline);
#define L1TF_DEFAULT_MSG "Mitigation: PTE Inversion"
#if IS_ENABLED(CONFIG_KVM_INTEL)
-static const char *l1tf_vmx_states[] = {
+static const char * const l1tf_vmx_states[] = {
[VMENTER_L1D_FLUSH_AUTO]= "auto",
[VMENTER_L1D_FLUSH_NEVER] = "vulnerable",
[VMENTER_L1D_FLUSH_COND]= "conditional cache flushes",
[patch V2 08/28] sched/smt: Make sched_smt_present track topology
Currently the 'sched_smt_present' static key is enabled when at CPU bringup SMT topology is observed, but it is never disabled. However there is demand to also disable the key when the topology changes such that there is no SMT present anymore. Implement this by making the key count the number of cores that have SMT enabled. In particular, the SMT topology bits are set before interrrupts are enabled and similarly, are cleared after interrupts are disabled for the last time and the CPU dies. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner --- kernel/sched/core.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -5738,15 +5738,10 @@ int sched_cpu_activate(unsigned int cpu) #ifdef CONFIG_SCHED_SMT /* -* The sched_smt_present static key needs to be evaluated on every -* hotplug event because at boot time SMT might be disabled when -* the number of booted CPUs is limited. -* -* If then later a sibling gets hotplugged, then the key would stay -* off and SMT scheduling would never be functional. +* When going up, increment the number of cores with SMT present. */ - if (cpumask_weight(cpu_smt_mask(cpu)) > 1) - static_branch_enable_cpuslocked(&sched_smt_present); + if (cpumask_weight(cpu_smt_mask(cpu)) == 2) + static_branch_inc_cpuslocked(&sched_smt_present); #endif set_cpu_active(cpu, true); @@ -5790,6 +5785,14 @@ int sched_cpu_deactivate(unsigned int cp */ synchronize_rcu_mult(call_rcu, call_rcu_sched); +#ifdef CONFIG_SCHED_SMT + /* +* When going down, decrement the number of cores with SMT present. +*/ + if (cpumask_weight(cpu_smt_mask(cpu)) == 2) + static_branch_dec_cpuslocked(&sched_smt_present); +#endif + if (!sched_smp_initialized) return 0;
[patch V2 12/28] x86/l1tf: Show actual SMT state
Use the now exposed real SMT state, not the SMT sysfs control knob
state. This reflects the state of the system when the mitigation status is
queried.
This does not change the warning in the VMX launch code. There the
dependency on the control knob makes sense because siblings could be
brought online anytime after launching the VM.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -832,13 +832,14 @@ static ssize_t l1tf_show_state(char *buf
if (l1tf_vmx_mitigation == VMENTER_L1D_FLUSH_EPT_DISABLED ||
(l1tf_vmx_mitigation == VMENTER_L1D_FLUSH_NEVER &&
-cpu_smt_control == CPU_SMT_ENABLED))
+sched_smt_active())) {
return sprintf(buf, "%s; VMX: %s\n", L1TF_DEFAULT_MSG,
l1tf_vmx_states[l1tf_vmx_mitigation]);
+ }
return sprintf(buf, "%s; VMX: %s, SMT %s\n", L1TF_DEFAULT_MSG,
l1tf_vmx_states[l1tf_vmx_mitigation],
- cpu_smt_control == CPU_SMT_ENABLED ? "vulnerable" :
"disabled");
+ sched_smt_active() ? "vulnerable" : "disabled");
}
#else
static ssize_t l1tf_show_state(char *buf)
[patch V2 06/28] x86/speculation: Rename SSBD update functions
During context switch, the SSBD bit in SPEC_CTRL MSR is updated according
to changes of the TIF_SSBD flag in the current and next running task.
Currently, only the bit controlling speculative store bypass disable in
SPEC_CTRL MSR is updated and the related update functions all have
"speculative_store" or "ssb" in their names.
For enhanced mitigation control other bits in SPEC_CTRL MSR need to be
updated as well, which makes the SSB names inadequate.
Rename the "speculative_store*" functions to a more generic name.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/include/asm/spec-ctrl.h |6 +++---
arch/x86/kernel/cpu/bugs.c |4 ++--
arch/x86/kernel/process.c| 12 ++--
3 files changed, 11 insertions(+), 11 deletions(-)
--- a/arch/x86/include/asm/spec-ctrl.h
+++ b/arch/x86/include/asm/spec-ctrl.h
@@ -70,11 +70,11 @@ extern void speculative_store_bypass_ht_
static inline void speculative_store_bypass_ht_init(void) { }
#endif
-extern void speculative_store_bypass_update(unsigned long tif);
+extern void speculation_ctrl_update(unsigned long tif);
-static inline void speculative_store_bypass_update_current(void)
+static inline void speculation_ctrl_update_current(void)
{
- speculative_store_bypass_update(current_thread_info()->flags);
+ speculation_ctrl_update(current_thread_info()->flags);
}
#endif
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -200,7 +200,7 @@ x86_virt_spec_ctrl(u64 guest_spec_ctrl,
tif = setguest ? ssbd_spec_ctrl_to_tif(guestval) :
ssbd_spec_ctrl_to_tif(hostval);
- speculative_store_bypass_update(tif);
+ speculation_ctrl_update(tif);
}
}
EXPORT_SYMBOL_GPL(x86_virt_spec_ctrl);
@@ -632,7 +632,7 @@ static int ssb_prctl_set(struct task_str
* mitigation until it is next scheduled.
*/
if (task == current && update)
- speculative_store_bypass_update_current();
+ speculation_ctrl_update_current();
return 0;
}
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -395,27 +395,27 @@ static __always_inline void amd_set_ssb_
wrmsrl(MSR_AMD64_VIRT_SPEC_CTRL, ssbd_tif_to_spec_ctrl(tifn));
}
-static __always_inline void intel_set_ssb_state(unsigned long tifn)
+static __always_inline void spec_ctrl_update_msr(unsigned long tifn)
{
u64 msr = x86_spec_ctrl_base | ssbd_tif_to_spec_ctrl(tifn);
wrmsrl(MSR_IA32_SPEC_CTRL, msr);
}
-static __always_inline void __speculative_store_bypass_update(unsigned long
tifn)
+static __always_inline void __speculation_ctrl_update(unsigned long tifn)
{
if (static_cpu_has(X86_FEATURE_VIRT_SSBD))
amd_set_ssb_virt_state(tifn);
else if (static_cpu_has(X86_FEATURE_LS_CFG_SSBD))
amd_set_core_ssb_state(tifn);
else
- intel_set_ssb_state(tifn);
+ spec_ctrl_update_msr(tifn);
}
-void speculative_store_bypass_update(unsigned long tif)
+void speculation_ctrl_update(unsigned long tif)
{
preempt_disable();
- __speculative_store_bypass_update(tif);
+ __speculation_ctrl_update(tif);
preempt_enable();
}
@@ -452,7 +452,7 @@ void __switch_to_xtra(struct task_struct
set_cpuid_faulting(!!(tifn & _TIF_NOCPUID));
if ((tifp ^ tifn) & _TIF_SSBD)
- __speculative_store_bypass_update(tifn);
+ __speculation_ctrl_update(tifn);
}
/*
[patch V2 15/28] x86/speculataion: Mark command line parser data __initdata
No point to keep that around.
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -248,7 +248,7 @@ static const struct {
const char *option;
enum spectre_v2_mitigation_cmd cmd;
bool secure;
-} mitigation_options[] = {
+} mitigation_options[] __initdata = {
{ "off",SPECTRE_V2_CMD_NONE, false },
{ "on", SPECTRE_V2_CMD_FORCE, true },
{ "retpoline", SPECTRE_V2_CMD_RETPOLINE, false },
@@ -486,7 +486,7 @@ static const char * const ssb_strings[]
static const struct {
const char *option;
enum ssb_mitigation_cmd cmd;
-} ssb_mitigation_options[] = {
+} ssb_mitigation_options[] __initdata = {
{ "auto", SPEC_STORE_BYPASS_CMD_AUTO },/* Platform decides */
{ "on", SPEC_STORE_BYPASS_CMD_ON }, /* Disable Speculative
Store Bypass */
{ "off",SPEC_STORE_BYPASS_CMD_NONE },/* Don't touch
Speculative Store Bypass */
[patch V2 02/28] x86/speculation: Clean up spectre_v2_parse_cmdline()
Remove the unnecessary 'else' statement in spectre_v2_parse_cmdline()
to save an indentation level.
Signed-off-by: Tim Chen
Signed-off-by: Thomas Gleixner
---
arch/x86/kernel/cpu/bugs.c | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -276,22 +276,21 @@ static enum spectre_v2_mitigation_cmd __
if (cmdline_find_option_bool(boot_command_line, "nospectre_v2"))
return SPECTRE_V2_CMD_NONE;
- else {
- ret = cmdline_find_option(boot_command_line, "spectre_v2", arg,
sizeof(arg));
- if (ret < 0)
- return SPECTRE_V2_CMD_AUTO;
- for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
- if (!match_option(arg, ret,
mitigation_options[i].option))
- continue;
- cmd = mitigation_options[i].cmd;
- break;
- }
+ ret = cmdline_find_option(boot_command_line, "spectre_v2", arg,
sizeof(arg));
+ if (ret < 0)
+ return SPECTRE_V2_CMD_AUTO;
- if (i >= ARRAY_SIZE(mitigation_options)) {
- pr_err("unknown option (%s). Switching to AUTO
select\n", arg);
- return SPECTRE_V2_CMD_AUTO;
- }
+ for (i = 0; i < ARRAY_SIZE(mitigation_options); i++) {
+ if (!match_option(arg, ret, mitigation_options[i].option))
+ continue;
+ cmd = mitigation_options[i].cmd;
+ break;
+ }
+
+ if (i >= ARRAY_SIZE(mitigation_options)) {
+ pr_err("unknown option (%s). Switching to AUTO select\n", arg);
+ return SPECTRE_V2_CMD_AUTO;
}
if ((cmd == SPECTRE_V2_CMD_RETPOLINE ||
