- Linux-stable-mirror - lists.linaro.org

[PATCH v2] arm64: compat: Reduce address limit

by Vincenzo Frascino

Currently, compat tasks running on arm64 can allocate memory up to TASK_SIZE_32 (UL(0x100000000)). This means that mmap() allocations, if we treat them as returning an array, are not compliant with the sections 6.5.8 of the C standard (C99) which states that: "If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P". Redefine TASK_SIZE_32 to address the issue. Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Will Deacon <will.deacon(a)arm.com> Cc: Jann Horn <jannh(a)google.com> Cc: <stable(a)vger.kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Signed-off-by: Vincenzo Frascino <vincenzo.frascino(a)arm.com> --- arch/arm64/include/asm/processor.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h index 5d9ce62bdebd..9c831d9d3cd2 100644 --- a/arch/arm64/include/asm/processor.h +++ b/arch/arm64/include/asm/processor.h @@ -57,7 +57,15 @@ #define TASK_SIZE_64 (UL(1) << vabits_user) #ifdef CONFIG_COMPAT +#ifdef CONFIG_ARM64_64K_PAGES +/* + * With CONFIG_ARM64_64K_PAGES enabled, the last page is occupied + * by the compact vectors page. + */ #define TASK_SIZE_32 UL(0x100000000) +#else +#define TASK_SIZE_32 (UL(0x100000000) - PAGE_SIZE) +#endif /* CONFIG_ARM64_64K_PAGES */ #define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \ TASK_SIZE_32 : TASK_SIZE_64) #define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \ -- 2.21.0

6 years, 5 months

3
2
0 0

[PATCH v4 3/3] x86/perf/amd: Remove need to check "running" bit in NMI handler

by Lendacky, Thomas

Spurious interrupt support was adding to perf in: commit 63e6be6d98e1 ("perf, x86: Catch spurious interrupts after disabling counters") The two previous patches (resolving the race condition when disabling a PMC and NMI latency mitigation) allow for the removal of this older spurious interrupt support. Currently in x86_pmu_stop(), the bit for the PMC in the active_mask bitmap is cleared before disabling the PMC, which sets up a race condition. This race condition was mitigated by introducing the running bitmap. That race condition can be eliminated by first disabling the PMC, waiting for PMC reset on overflow and then clearing the bit for the PMC in the active_mask bitmap. The NMI handler will not re-enable a disabled counter. If x86_pmu_stop() is called from the perf NMI handler, the NMI latency mitigation support will guard against any unhandled NMI messages. Cc: <stable(a)vger.kernel.org> # 4.14.x- Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> --- arch/x86/events/amd/core.c | 19 ++++++++++++++++++- arch/x86/events/core.c | 13 +++---------- 2 files changed, 21 insertions(+), 11 deletions(-) diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c index 8f06ec0e673b..22d6667c7063 100644 --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -490,6 +490,23 @@ static void amd_pmu_disable_all(void) } } +static void amd_pmu_disable_event(struct perf_event *event) +{ + x86_pmu_disable_event(event); + + /* + * This can be called from NMI context (via x86_pmu_stop). The counter + * may have overflowed, but either way, we'll never see it get reset + * by the NMI if we're already in the NMI. And the NMI latency support + * below will take care of any pending NMI that might have been + * generated by the overflow. + */ + if (in_nmi()) + return; + + amd_pmu_wait_on_overflow(event->hw.idx); +} + /* * Because of NMI latency, if multiple PMC counters are active or other sources * of NMIs are received, the perf NMI handler can handle one or more overflowed @@ -737,7 +754,7 @@ static __initconst const struct x86_pmu amd_pmu = { .disable_all = amd_pmu_disable_all, .enable_all = x86_pmu_enable_all, .enable = x86_pmu_enable_event, - .disable = x86_pmu_disable_event, + .disable = amd_pmu_disable_event, .hw_config = amd_pmu_hw_config, .schedule_events = x86_schedule_events, .eventsel = MSR_K7_EVNTSEL0, diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c index e2b1447192a8..81911e11a15d 100644 --- a/arch/x86/events/core.c +++ b/arch/x86/events/core.c @@ -1349,8 +1349,9 @@ void x86_pmu_stop(struct perf_event *event, int flags) struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); struct hw_perf_event *hwc = &event->hw; - if (__test_and_clear_bit(hwc->idx, cpuc->active_mask)) { + if (test_bit(hwc->idx, cpuc->active_mask)) { x86_pmu.disable(event); + __clear_bit(hwc->idx, cpuc->active_mask); cpuc->events[hwc->idx] = NULL; WARN_ON_ONCE(hwc->state & PERF_HES_STOPPED); hwc->state |= PERF_HES_STOPPED; @@ -1447,16 +1448,8 @@ int x86_pmu_handle_irq(struct pt_regs *regs) apic_write(APIC_LVTPC, APIC_DM_NMI); for (idx = 0; idx < x86_pmu.num_counters; idx++) { - if (!test_bit(idx, cpuc->active_mask)) { - /* - * Though we deactivated the counter some cpus - * might still deliver spurious interrupts still - * in flight. Catch them: - */ - if (__test_and_clear_bit(idx, cpuc->running)) - handled++; + if (!test_bit(idx, cpuc->active_mask)) continue; - } event = cpuc->events[idx]; -- 2.17.1

6 years, 5 months

1
0
0 0

[PATCH v4 2/3] x86/perf/amd: Resolve NMI latency issues for active PMCs

by Lendacky, Thomas

On AMD processors, the detection of an overflowed PMC counter in the NMI handler relies on the current value of the PMC. So, for example, to check for overflow on a 48-bit counter, bit 47 is checked to see if it is 1 (not overflowed) or 0 (overflowed). When the perf NMI handler executes it does not know in advance which PMC counters have overflowed. As such, the NMI handler will process all active PMC counters that have overflowed. NMI latency in newer AMD processors can result in multiple overflowed PMC counters being processed in one NMI and then a subsequent NMI, that does not appear to be a back-to-back NMI, not finding any PMC counters that have overflowed. This may appear to be an unhandled NMI resulting in either a panic or a series of messages, depending on how the kernel was configured. To mitigate this issue, add an AMD handle_irq callback function, amd_pmu_handle_irq(), that will invoke the common x86_pmu_handle_irq() function and upon return perform some additional processing that will indicate if the NMI has been handled or would have been handled had an earlier NMI not handled the overflowed PMC. Using a per-CPU variable, a minimum value of the number of active PMCs or 2 will be set whenever a PMC is active. This is used to indicate the possible number of NMIs that can still occur. The value of 2 is used for when an NMI does not arrive at the LAPIC in time to be collapsed into an already pending NMI. Each time the function is called without having handled an overflowed counter, the per-CPU value is checked. If the value is non-zero, it is decremented and the NMI indicates that it handled the NMI. If the value is zero, then the NMI indicates that it did not handle the NMI. Cc: <stable(a)vger.kernel.org> # 4.14.x- Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> --- arch/x86/events/amd/core.c | 56 +++++++++++++++++++++++++++++++++++++- 1 file changed, 55 insertions(+), 1 deletion(-) diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c index beb132593622..8f06ec0e673b 100644 --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -4,10 +4,13 @@ #include <linux/init.h> #include <linux/slab.h> #include <linux/delay.h> +#include <linux/nmi.h> #include <asm/apicdef.h> #include "../perf_event.h" +static DEFINE_PER_CPU(unsigned int, perf_nmi_counter); + static __initconst const u64 amd_hw_cache_event_ids [PERF_COUNT_HW_CACHE_MAX] [PERF_COUNT_HW_CACHE_OP_MAX] @@ -487,6 +490,57 @@ static void amd_pmu_disable_all(void) } } +/* + * Because of NMI latency, if multiple PMC counters are active or other sources + * of NMIs are received, the perf NMI handler can handle one or more overflowed + * PMC counters outside of the NMI associated with the PMC overflow. If the NMI + * doesn't arrive at the LAPIC in time to become a pending NMI, then the kernel + * back-to-back NMI support won't be active. This PMC handler needs to take into + * account that this can occur, otherwise this could result in unknown NMI + * messages being issued. Examples of this is PMC overflow while in the NMI + * handler when multiple PMCs are active or PMC overflow while handling some + * other source of an NMI. + * + * Attempt to mitigate this by using the number of active PMCs to determine + * whether to return NMI_HANDLED if the perf NMI handler did not handle/reset + * any PMCs. The per-CPU perf_nmi_counter variable is set to a minimum of the + * number of active PMCs or 2. The value of 2 is used in case an NMI does not + * arrive at the LAPIC in time to be collapsed into an already pending NMI. + */ +static int amd_pmu_handle_irq(struct pt_regs *regs) +{ + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); + int active, handled; + + /* + * Obtain the active count before calling x86_pmu_handle_irq() since + * it is possible that x86_pmu_handle_irq() may make a counter + * inactive (through x86_pmu_stop). + */ + active = __bitmap_weight(cpuc->active_mask, X86_PMC_IDX_MAX); + + /* Process any counter overflows */ + handled = x86_pmu_handle_irq(regs); + + /* + * If a counter was handled, record the number of possible remaining + * NMIs that can occur. + */ + if (handled) { + this_cpu_write(perf_nmi_counter, + min_t(unsigned int, 2, active)); + + return handled; + } + + if (!this_cpu_read(perf_nmi_counter)) + return NMI_DONE; + + this_cpu_dec(perf_nmi_counter); + + return NMI_HANDLED; +} + static struct event_constraint * amd_get_event_constraints(struct cpu_hw_events *cpuc, int idx, struct perf_event *event) @@ -679,7 +733,7 @@ static ssize_t amd_event_sysfs_show(char *page, u64 config) static __initconst const struct x86_pmu amd_pmu = { .name = "AMD", - .handle_irq = x86_pmu_handle_irq, + .handle_irq = amd_pmu_handle_irq, .disable_all = amd_pmu_disable_all, .enable_all = x86_pmu_enable_all, .enable = x86_pmu_enable_event, -- 2.17.1

6 years, 5 months

1
0
0 0

[PATCH v4 1/3] x86/perf/amd: Resolve race condition when disabling PMC

by Lendacky, Thomas

On AMD processors, the detection of an overflowed counter in the NMI handler relies on the current value of the counter. So, for example, to check for overflow on a 48 bit counter, bit 47 is checked to see if it is 1 (not overflowed) or 0 (overflowed). There is currently a race condition present when disabling and then updating the PMC. Increased NMI latency in newer AMD processors makes this race condition more pronounced. If the counter value has overflowed, it is possible to update the PMC value before the NMI handler can run. The updated PMC value is not an overflowed value, so when the perf NMI handler does run, it will not find an overflowed counter. This may appear as an unknown NMI resulting in either a panic or a series of messages, depending on how the kernel is configured. To eliminate this race condition, the PMC value must be checked after disabling the counter. Add an AMD function, amd_pmu_disable_all(), that will wait for the NMI handler to reset any active and overflowed counter after calling x86_pmu_disable_all(). Cc: <stable(a)vger.kernel.org> # 4.14.x- Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> --- arch/x86/events/amd/core.c | 64 ++++++++++++++++++++++++++++++++++++-- 1 file changed, 61 insertions(+), 3 deletions(-) diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c index 7d2d7c801dba..beb132593622 100644 --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -3,6 +3,7 @@ #include <linux/types.h> #include <linux/init.h> #include <linux/slab.h> +#include <linux/delay.h> #include <asm/apicdef.h> #include "../perf_event.h" @@ -429,6 +430,63 @@ static void amd_pmu_cpu_dead(int cpu) } } +/* + * When a PMC counter overflows, an NMI is used to process the event and + * reset the counter. NMI latency can result in the counter being updated + * before the NMI can run, which can result in what appear to be spurious + * NMIs. This function is intended to wait for the NMI to run and reset + * the counter to avoid possible unhandled NMI messages. + */ +#define OVERFLOW_WAIT_COUNT 50 +static void amd_pmu_wait_on_overflow(int idx) +{ + unsigned int i; + u64 counter; + + /* + * Wait for the counter to be reset if it has overflowed. This loop + * should exit very, very quickly, but just in case, don't wait + * forever... + */ + for (i = 0; i < OVERFLOW_WAIT_COUNT; i++) { + rdmsrl(x86_pmu_event_addr(idx), counter); + if (counter & (1ULL << (x86_pmu.cntval_bits - 1))) + break; + + /* Might be in IRQ context, so can't sleep */ + udelay(1); + } +} + +static void amd_pmu_disable_all(void) +{ + struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events); + int idx; + + x86_pmu_disable_all(); + + /* + * This shouldn't be called from NMI context, but add a safeguard here + * to return, since if we're in NMI context we can't wait for an NMI + * to reset an overflowed counter value. + */ + if (in_nmi()) + return; + + /* + * Check each counter for overflow and wait for it to be reset by the + * NMI if it has overflowed. This relies on the fact that all active + * counters are always enabled when this function is caled and + * ARCH_PERFMON_EVENTSEL_INT is always set. + */ + for (idx = 0; idx < x86_pmu.num_counters; idx++) { + if (!test_bit(idx, cpuc->active_mask)) + continue; + + amd_pmu_wait_on_overflow(idx); + } +} + static struct event_constraint * amd_get_event_constraints(struct cpu_hw_events *cpuc, int idx, struct perf_event *event) @@ -622,7 +680,7 @@ static ssize_t amd_event_sysfs_show(char *page, u64 config) static __initconst const struct x86_pmu amd_pmu = { .name = "AMD", .handle_irq = x86_pmu_handle_irq, - .disable_all = x86_pmu_disable_all, + .disable_all = amd_pmu_disable_all, .enable_all = x86_pmu_enable_all, .enable = x86_pmu_enable_event, .disable = x86_pmu_disable_event, @@ -732,7 +790,7 @@ void amd_pmu_enable_virt(void) cpuc->perf_ctr_virt_mask = 0; /* Reload all events */ - x86_pmu_disable_all(); + amd_pmu_disable_all(); x86_pmu_enable_all(0); } EXPORT_SYMBOL_GPL(amd_pmu_enable_virt); @@ -750,7 +808,7 @@ void amd_pmu_disable_virt(void) cpuc->perf_ctr_virt_mask = AMD64_EVENTSEL_HOSTONLY; /* Reload all events */ - x86_pmu_disable_all(); + amd_pmu_disable_all(); x86_pmu_enable_all(0); } EXPORT_SYMBOL_GPL(amd_pmu_disable_virt); -- 2.17.1

6 years, 5 months

1
0
0 0

[PATCH] staging: most: core: use device description as name

by Christian Gromm

This patch uses the device description to clearly identity a device attached to the bus. It is needed as the currently useed mdevX notation is not sufficiant in case more than one network interface controller is being used at the same time. Cc: stable(a)vger.kernel.org Signed-off-by: Christian Gromm <christian.gromm(a)microchip.com> --- drivers/staging/most/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/most/core.c b/drivers/staging/most/core.c index a5df53e..e0a6806 100644 --- a/drivers/staging/most/core.c +++ b/drivers/staging/most/core.c @@ -1467,7 +1467,7 @@ int most_register_interface(struct most_interface *iface) INIT_LIST_HEAD(&iface->p->channel_list); iface->p->dev_id = id; - snprintf(iface->p->name, STRING_SIZE, "mdev%d", id); + strcpy(iface->p->name, iface->description); iface->dev.init_name = iface->p->name; iface->dev.bus = &mc.bus; iface->dev.parent = &mc.dev; -- 2.7.4

6 years, 5 months

1
0
0 0

patch "iio: ad_sigma_delta: select channel when reading register" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: ad_sigma_delta: select channel when reading register to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From fccfb9ce70ed4ea7a145f77b86de62e38178517f Mon Sep 17 00:00:00 2001 From: Dragos Bogdan <dragos.bogdan(a)analog.com> Date: Tue, 19 Mar 2019 12:47:00 +0200 Subject: iio: ad_sigma_delta: select channel when reading register The desired channel has to be selected in order to correctly fill the buffer with the corresponding data. The `ad_sd_write_reg()` already does this, but for the `ad_sd_read_reg_raw()` this was omitted. Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices") Signed-off-by: Dragos Bogdan <dragos.bogdan(a)analog.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad_sigma_delta.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/adc/ad_sigma_delta.c b/drivers/iio/adc/ad_sigma_delta.c index ff5f2da2e1b1..54d9978b2740 100644 --- a/drivers/iio/adc/ad_sigma_delta.c +++ b/drivers/iio/adc/ad_sigma_delta.c @@ -121,6 +121,7 @@ static int ad_sd_read_reg_raw(struct ad_sigma_delta *sigma_delta, if (sigma_delta->info->has_registers) { data[0] = reg << sigma_delta->info->addr_shift; data[0] |= sigma_delta->info->read_mask; + data[0] |= sigma_delta->comm; spi_message_add_tail(&t[0], &m); } spi_message_add_tail(&t[1], &m); -- 2.21.0

6 years, 5 months

1
0
0 0

patch "iio: cros_ec: Fix the maths for gyro scale calculation" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: cros_ec: Fix the maths for gyro scale calculation to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 3d02d7082e5823598090530c3988a35f69689943 Mon Sep 17 00:00:00 2001 From: Gwendal Grignou <gwendal(a)chromium.org> Date: Wed, 13 Mar 2019 12:40:02 +0100 Subject: iio: cros_ec: Fix the maths for gyro scale calculation Calculation did not use IIO_DEGREE_TO_RAD and implemented a variant to avoid precision loss as we aim a nano value. The offset added to avoid rounding error, though, doesn't give us a close result to the expected value. E.g. For 1000dps, the result should be: (1000 * pi ) / 180 >> 15 ~= 0.000532632218 But with current calculation we get $ cat scale 0.000547890 Fix the calculation by just doing the maths involved for a nano value val * pi * 10e12 / (180 * 2^15) so we get a closer result. $ cat scale 0.000532632 Fixes: c14dca07a31d ("iio: cros_ec_sensors: add ChromeOS EC Contiguous Sensors driver") Signed-off-by: Gwendal Grignou <gwendal(a)chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c index 89cb0066a6e0..8d76afb87d87 100644 --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c @@ -103,9 +103,10 @@ static int cros_ec_sensors_read(struct iio_dev *indio_dev, * Do not use IIO_DEGREE_TO_RAD to avoid precision * loss. Round to the nearest integer. */ - *val = div_s64(val64 * 314159 + 9000000ULL, 1000); - *val2 = 18000 << (CROS_EC_SENSOR_BITS - 1); - ret = IIO_VAL_FRACTIONAL; + *val = 0; + *val2 = div_s64(val64 * 3141592653ULL, + 180 << (CROS_EC_SENSOR_BITS - 1)); + ret = IIO_VAL_INT_PLUS_NANO; break; case MOTIONSENSE_TYPE_MAG: /* -- 2.21.0

6 years, 5 months

1
0
0 0

patch "iio: dac: mcp4725: add missing powerdown bits in store eeprom" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: dac: mcp4725: add missing powerdown bits in store eeprom to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 06003531502d06bc89d32528f6ec96bf978790f9 Mon Sep 17 00:00:00 2001 From: Jean-Francois Dagenais <jeff.dagenais(a)gmail.com> Date: Wed, 6 Mar 2019 15:56:06 -0500 Subject: iio: dac: mcp4725: add missing powerdown bits in store eeprom When issuing the write DAC register and write eeprom command, the two powerdown bits (PD0 and PD1) are assumed by the chip to be present in the bytes sent. Leaving them at 0 implies "powerdown disabled" which is a different state that the current one. By adding the current state of the powerdown in the i2c write, the chip will correctly power-on exactly like as it is at the moment of store_eeprom call. This is documented in MCP4725's datasheet, FIGURE 6-2: "Write Commands for DAC Input Register and EEPROM" and MCP4726's datasheet, FIGURE 6-3: "Write All Memory Command". Signed-off-by: Jean-Francois Dagenais <jeff.dagenais(a)gmail.com> Acked-by: Peter Meerwald-Stadler <pmeerw(a)pmeerw.net> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/dac/mcp4725.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/iio/dac/mcp4725.c b/drivers/iio/dac/mcp4725.c index 6d71fd905e29..c701a45469f6 100644 --- a/drivers/iio/dac/mcp4725.c +++ b/drivers/iio/dac/mcp4725.c @@ -92,6 +92,7 @@ static ssize_t mcp4725_store_eeprom(struct device *dev, inoutbuf[0] = 0x60; /* write EEPROM */ inoutbuf[0] |= data->ref_mode << 3; + inoutbuf[0] |= data->powerdown ? ((data->powerdown_mode + 1) << 1) : 0; inoutbuf[1] = data->dac_value >> 4; inoutbuf[2] = (data->dac_value & 0xf) << 4; -- 2.21.0

6 years, 5 months

1
0
0 0

patch "io: accel: kxcjk1013: restore the range after resume." added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled io: accel: kxcjk1013: restore the range after resume. to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From fe2d3df639a7940a125a33d6460529b9689c5406 Mon Sep 17 00:00:00 2001 From: "he, bo" <bo.he(a)intel.com> Date: Wed, 6 Mar 2019 10:32:20 +0800 Subject: io: accel: kxcjk1013: restore the range after resume. On some laptops, kxcjk1013 is powered off when system enters S3. We need restore the range regiter during resume. Otherwise, the sensor doesn't work properly after S3. Signed-off-by: he, bo <bo.he(a)intel.com> Signed-off-by: Chen, Hu <hu1.chen(a)intel.com> Reviewed-by: Hans de Goede <hdegoede(a)redhat.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/accel/kxcjk-1013.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c index 7096e577b23f..50f3ff386bea 100644 --- a/drivers/iio/accel/kxcjk-1013.c +++ b/drivers/iio/accel/kxcjk-1013.c @@ -1437,6 +1437,8 @@ static int kxcjk1013_resume(struct device *dev) mutex_lock(&data->mutex); ret = kxcjk1013_set_mode(data, OPERATION); + if (ret == 0) + ret = kxcjk1013_set_range(data, data->range); mutex_unlock(&data->mutex); return ret; -- 2.21.0

6 years, 5 months

1
0
0 0

patch "iio:chemical:bme680: Fix SPI read interface" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio:chemical:bme680: Fix SPI read interface to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 73f3bc6da506711302bb67572440eb84b1ec4a2c Mon Sep 17 00:00:00 2001 From: Mike Looijmans <mike.looijmans(a)topic.nl> Date: Wed, 6 Mar 2019 08:31:48 +0100 Subject: iio:chemical:bme680: Fix SPI read interface The SPI interface implementation was completely broken. When using the SPI interface, there are only 7 address bits, the upper bit is controlled by a page select register. The core needs access to both ranges, so implement register read/write for both regions. The regmap paging functionality didn't agree with a register that needs to be read and modified, so I implemented a custom paging algorithm. This fixes that the device wouldn't even probe in SPI mode. The SPI interface then isn't different from I2C, merged them into the core, and the I2C/SPI named registers are no longer needed. Implemented register value caching for the registers to reduce the I2C/SPI data transfers considerably. The calibration set reads as all zeroes until some undefined point in time, and I couldn't determine what makes it valid. The datasheet mentions these registers but does not provide any hints on when they become valid, and they aren't even enumerated in the memory map. So check the calibration and retry reading it from the device after each measurement until it provides something valid. Despite the size this is suitable for a stable backport given that it seems the SPI support never worked. Signed-off-by: Mike Looijmans <mike.looijmans(a)topic.nl> Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor"); Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/chemical/bme680.h | 6 +- drivers/iio/chemical/bme680_core.c | 38 ++++++++++ drivers/iio/chemical/bme680_i2c.c | 21 ------ drivers/iio/chemical/bme680_spi.c | 115 +++++++++++++++++++---------- 4 files changed, 118 insertions(+), 62 deletions(-) diff --git a/drivers/iio/chemical/bme680.h b/drivers/iio/chemical/bme680.h index 0ae89b87e2d6..4edc5d21cb9f 100644 --- a/drivers/iio/chemical/bme680.h +++ b/drivers/iio/chemical/bme680.h @@ -2,11 +2,9 @@ #ifndef BME680_H_ #define BME680_H_ -#define BME680_REG_CHIP_I2C_ID 0xD0 -#define BME680_REG_CHIP_SPI_ID 0x50 +#define BME680_REG_CHIP_ID 0xD0 #define BME680_CHIP_ID_VAL 0x61 -#define BME680_REG_SOFT_RESET_I2C 0xE0 -#define BME680_REG_SOFT_RESET_SPI 0x60 +#define BME680_REG_SOFT_RESET 0xE0 #define BME680_CMD_SOFTRESET 0xB6 #define BME680_REG_STATUS 0x73 #define BME680_SPI_MEM_PAGE_BIT BIT(4) diff --git a/drivers/iio/chemical/bme680_core.c b/drivers/iio/chemical/bme680_core.c index fefe32b5b69d..ccde4c65ff93 100644 --- a/drivers/iio/chemical/bme680_core.c +++ b/drivers/iio/chemical/bme680_core.c @@ -63,9 +63,23 @@ struct bme680_data { s32 t_fine; }; +static const struct regmap_range bme680_volatile_ranges[] = { + regmap_reg_range(BME680_REG_MEAS_STAT_0, BME680_REG_GAS_R_LSB), + regmap_reg_range(BME680_REG_STATUS, BME680_REG_STATUS), + regmap_reg_range(BME680_T2_LSB_REG, BME680_GH3_REG), +}; + +static const struct regmap_access_table bme680_volatile_table = { + .yes_ranges = bme680_volatile_ranges, + .n_yes_ranges = ARRAY_SIZE(bme680_volatile_ranges), +}; + const struct regmap_config bme680_regmap_config = { .reg_bits = 8, .val_bits = 8, + .max_register = 0xef, + .volatile_table = &bme680_volatile_table, + .cache_type = REGCACHE_RBTREE, }; EXPORT_SYMBOL(bme680_regmap_config); @@ -316,6 +330,10 @@ static s16 bme680_compensate_temp(struct bme680_data *data, s64 var1, var2, var3; s16 calc_temp; + /* If the calibration is invalid, attempt to reload it */ + if (!calib->par_t2) + bme680_read_calib(data, calib); + var1 = (adc_temp >> 3) - (calib->par_t1 << 1); var2 = (var1 * calib->par_t2) >> 11; var3 = ((var1 >> 1) * (var1 >> 1)) >> 12; @@ -865,8 +883,28 @@ int bme680_core_probe(struct device *dev, struct regmap *regmap, { struct iio_dev *indio_dev; struct bme680_data *data; + unsigned int val; int ret; + ret = regmap_write(regmap, BME680_REG_SOFT_RESET, + BME680_CMD_SOFTRESET); + if (ret < 0) { + dev_err(dev, "Failed to reset chip\n"); + return ret; + } + + ret = regmap_read(regmap, BME680_REG_CHIP_ID, &val); + if (ret < 0) { + dev_err(dev, "Error reading chip ID\n"); + return ret; + } + + if (val != BME680_CHIP_ID_VAL) { + dev_err(dev, "Wrong chip ID, got %x expected %x\n", + val, BME680_CHIP_ID_VAL); + return -ENODEV; + } + indio_dev = devm_iio_device_alloc(dev, sizeof(*data)); if (!indio_dev) return -ENOMEM; diff --git a/drivers/iio/chemical/bme680_i2c.c b/drivers/iio/chemical/bme680_i2c.c index b2f805b6b36a..de9c9e3d23ea 100644 --- a/drivers/iio/chemical/bme680_i2c.c +++ b/drivers/iio/chemical/bme680_i2c.c @@ -23,8 +23,6 @@ static int bme680_i2c_probe(struct i2c_client *client, { struct regmap *regmap; const char *name = NULL; - unsigned int val; - int ret; regmap = devm_regmap_init_i2c(client, &bme680_regmap_config); if (IS_ERR(regmap)) { @@ -33,25 +31,6 @@ static int bme680_i2c_probe(struct i2c_client *client, return PTR_ERR(regmap); } - ret = regmap_write(regmap, BME680_REG_SOFT_RESET_I2C, - BME680_CMD_SOFTRESET); - if (ret < 0) { - dev_err(&client->dev, "Failed to reset chip\n"); - return ret; - } - - ret = regmap_read(regmap, BME680_REG_CHIP_I2C_ID, &val); - if (ret < 0) { - dev_err(&client->dev, "Error reading I2C chip ID\n"); - return ret; - } - - if (val != BME680_CHIP_ID_VAL) { - dev_err(&client->dev, "Wrong chip ID, got %x expected %x\n", - val, BME680_CHIP_ID_VAL); - return -ENODEV; - } - if (id) name = id->name; diff --git a/drivers/iio/chemical/bme680_spi.c b/drivers/iio/chemical/bme680_spi.c index d0b7bdd3f066..3b838068a7e4 100644 --- a/drivers/iio/chemical/bme680_spi.c +++ b/drivers/iio/chemical/bme680_spi.c @@ -12,28 +12,93 @@ #include "bme680.h" +struct bme680_spi_bus_context { + struct spi_device *spi; + u8 current_page; +}; + +/* + * In SPI mode there are only 7 address bits, a "page" register determines + * which part of the 8-bit range is active. This function looks at the address + * and writes the page selection bit if needed + */ +static int bme680_regmap_spi_select_page( + struct bme680_spi_bus_context *ctx, u8 reg) +{ + struct spi_device *spi = ctx->spi; + int ret; + u8 buf[2]; + u8 page = (reg & 0x80) ? 0 : 1; /* Page "1" is low range */ + + if (page == ctx->current_page) + return 0; + + /* + * Data sheet claims we're only allowed to change bit 4, so we must do + * a read-modify-write on each and every page select + */ + buf[0] = BME680_REG_STATUS; + ret = spi_write_then_read(spi, buf, 1, buf + 1, 1); + if (ret < 0) { + dev_err(&spi->dev, "failed to set page %u\n", page); + return ret; + } + + buf[0] = BME680_REG_STATUS; + if (page) + buf[1] |= BME680_SPI_MEM_PAGE_BIT; + else + buf[1] &= ~BME680_SPI_MEM_PAGE_BIT; + + ret = spi_write(spi, buf, 2); + if (ret < 0) { + dev_err(&spi->dev, "failed to set page %u\n", page); + return ret; + } + + ctx->current_page = page; + + return 0; +} + static int bme680_regmap_spi_write(void *context, const void *data, size_t count) { - struct spi_device *spi = context; + struct bme680_spi_bus_context *ctx = context; + struct spi_device *spi = ctx->spi; + int ret; u8 buf[2]; memcpy(buf, data, 2); + + ret = bme680_regmap_spi_select_page(ctx, buf[0]); + if (ret) + return ret; + /* * The SPI register address (= full register address without bit 7) * and the write command (bit7 = RW = '0') */ buf[0] &= ~0x80; - return spi_write_then_read(spi, buf, 2, NULL, 0); + return spi_write(spi, buf, 2); } static int bme680_regmap_spi_read(void *context, const void *reg, size_t reg_size, void *val, size_t val_size) { - struct spi_device *spi = context; + struct bme680_spi_bus_context *ctx = context; + struct spi_device *spi = ctx->spi; + int ret; + u8 addr = *(const u8 *)reg; + + ret = bme680_regmap_spi_select_page(ctx, addr); + if (ret) + return ret; - return spi_write_then_read(spi, reg, reg_size, val, val_size); + addr |= 0x80; /* bit7 = RW = '1' */ + + return spi_write_then_read(spi, &addr, 1, val, val_size); } static struct regmap_bus bme680_regmap_bus = { @@ -46,8 +111,8 @@ static struct regmap_bus bme680_regmap_bus = { static int bme680_spi_probe(struct spi_device *spi) { const struct spi_device_id *id = spi_get_device_id(spi); + struct bme680_spi_bus_context *bus_context; struct regmap *regmap; - unsigned int val; int ret; spi->bits_per_word = 8; @@ -57,45 +122,21 @@ static int bme680_spi_probe(struct spi_device *spi) return ret; } + bus_context = devm_kzalloc(&spi->dev, sizeof(*bus_context), GFP_KERNEL); + if (!bus_context) + return -ENOMEM; + + bus_context->spi = spi; + bus_context->current_page = 0xff; /* Undefined on warm boot */ + regmap = devm_regmap_init(&spi->dev, &bme680_regmap_bus, - &spi->dev, &bme680_regmap_config); + bus_context, &bme680_regmap_config); if (IS_ERR(regmap)) { dev_err(&spi->dev, "Failed to register spi regmap %d\n", (int)PTR_ERR(regmap)); return PTR_ERR(regmap); } - ret = regmap_write(regmap, BME680_REG_SOFT_RESET_SPI, - BME680_CMD_SOFTRESET); - if (ret < 0) { - dev_err(&spi->dev, "Failed to reset chip\n"); - return ret; - } - - /* after power-on reset, Page 0(0x80-0xFF) of spi_mem_page is active */ - ret = regmap_read(regmap, BME680_REG_CHIP_SPI_ID, &val); - if (ret < 0) { - dev_err(&spi->dev, "Error reading SPI chip ID\n"); - return ret; - } - - if (val != BME680_CHIP_ID_VAL) { - dev_err(&spi->dev, "Wrong chip ID, got %x expected %x\n", - val, BME680_CHIP_ID_VAL); - return -ENODEV; - } - /* - * select Page 1 of spi_mem_page to enable access to - * to registers from address 0x00 to 0x7F. - */ - ret = regmap_write_bits(regmap, BME680_REG_STATUS, - BME680_SPI_MEM_PAGE_BIT, - BME680_SPI_MEM_PAGE_1_VAL); - if (ret < 0) { - dev_err(&spi->dev, "failed to set page 1 of spi_mem_page\n"); - return ret; - } - return bme680_core_probe(&spi->dev, regmap, id->name); } -- 2.21.0

6 years, 5 months

1
0
0 0

patch "iio:chemical:bme680: Fix, report temperature in millidegrees" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio:chemical:bme680: Fix, report temperature in millidegrees to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 9436f45dd53595e21566a8c6627411077dfdb776 Mon Sep 17 00:00:00 2001 From: Mike Looijmans <mike.looijmans(a)topic.nl> Date: Wed, 6 Mar 2019 08:31:47 +0100 Subject: iio:chemical:bme680: Fix, report temperature in millidegrees The standard unit for temperature is millidegrees Celcius. Adapt the driver to report in millidegrees instead of degrees. Signed-off-by: Mike Looijmans <mike.looijmans(a)topic.nl> Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor"); Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/chemical/bme680_core.c | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/drivers/iio/chemical/bme680_core.c b/drivers/iio/chemical/bme680_core.c index 70c1fe4366f4..fefe32b5b69d 100644 --- a/drivers/iio/chemical/bme680_core.c +++ b/drivers/iio/chemical/bme680_core.c @@ -583,8 +583,7 @@ static int bme680_gas_config(struct bme680_data *data) return ret; } -static int bme680_read_temp(struct bme680_data *data, - int *val, int *val2) +static int bme680_read_temp(struct bme680_data *data, int *val) { struct device *dev = regmap_get_device(data->regmap); int ret; @@ -617,10 +616,9 @@ static int bme680_read_temp(struct bme680_data *data, * compensate_press/compensate_humid to get compensated * pressure/humidity readings. */ - if (val && val2) { - *val = comp_temp; - *val2 = 100; - return IIO_VAL_FRACTIONAL; + if (val) { + *val = comp_temp * 10; /* Centidegrees to millidegrees */ + return IIO_VAL_INT; } return ret; @@ -635,7 +633,7 @@ static int bme680_read_press(struct bme680_data *data, s32 adc_press; /* Read and compensate temperature to get a reading of t_fine */ - ret = bme680_read_temp(data, NULL, NULL); + ret = bme680_read_temp(data, NULL); if (ret < 0) return ret; @@ -668,7 +666,7 @@ static int bme680_read_humid(struct bme680_data *data, u32 comp_humidity; /* Read and compensate temperature to get a reading of t_fine */ - ret = bme680_read_temp(data, NULL, NULL); + ret = bme680_read_temp(data, NULL); if (ret < 0) return ret; @@ -761,7 +759,7 @@ static int bme680_read_raw(struct iio_dev *indio_dev, case IIO_CHAN_INFO_PROCESSED: switch (chan->type) { case IIO_TEMP: - return bme680_read_temp(data, val, val2); + return bme680_read_temp(data, val); case IIO_PRESSURE: return bme680_read_press(data, val, val2); case IIO_HUMIDITYRELATIVE: -- 2.21.0

6 years, 5 months

1
0
0 0

patch "iio: adc: at91: disable adc channel interrupt in timeout case" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: at91: disable adc channel interrupt in timeout case to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 09c6bdee51183a575bf7546890c8c137a75a2b44 Mon Sep 17 00:00:00 2001 From: Georg Ottinger <g.ottinger(a)abatec.at> Date: Wed, 30 Jan 2019 14:42:02 +0100 Subject: iio: adc: at91: disable adc channel interrupt in timeout case Having a brief look at at91_adc_read_raw() it is obvious that in the case of a timeout the setting of AT91_ADC_CHDR and AT91_ADC_IDR registers is omitted. If 2 different channels are queried we can end up with a situation where two interrupts are enabled, but only one interrupt is cleared in the interrupt handler. Resulting in a interrupt loop and a system hang. Signed-off-by: Georg Ottinger <g.ottinger(a)abatec.at> Acked-by: Ludovic Desroches <ludovic.desroches(a)microchip.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/at91_adc.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c index 75d2f73582a3..596841a3c4db 100644 --- a/drivers/iio/adc/at91_adc.c +++ b/drivers/iio/adc/at91_adc.c @@ -704,23 +704,29 @@ static int at91_adc_read_raw(struct iio_dev *idev, ret = wait_event_interruptible_timeout(st->wq_data_avail, st->done, msecs_to_jiffies(1000)); - if (ret == 0) - ret = -ETIMEDOUT; - if (ret < 0) { - mutex_unlock(&st->lock); - return ret; - } - - *val = st->last_value; + /* Disable interrupts, regardless if adc conversion was + * successful or not + */ at91_adc_writel(st, AT91_ADC_CHDR, AT91_ADC_CH(chan->channel)); at91_adc_writel(st, AT91_ADC_IDR, BIT(chan->channel)); - st->last_value = 0; - st->done = false; + if (ret > 0) { + /* a valid conversion took place */ + *val = st->last_value; + st->last_value = 0; + st->done = false; + ret = IIO_VAL_INT; + } else if (ret == 0) { + /* conversion timeout */ + dev_err(&idev->dev, "ADC Channel %d timeout.\n", + chan->channel); + ret = -ETIMEDOUT; + } + mutex_unlock(&st->lock); - return IIO_VAL_INT; + return ret; case IIO_CHAN_INFO_SCALE: *val = st->vref_mv; -- 2.21.0

6 years, 5 months

1
0
0 0

patch "iio: gyro: mpu3050: fix chip ID reading" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: gyro: mpu3050: fix chip ID reading to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 409a51e0a4a5f908763191fae2c29008632eb712 Mon Sep 17 00:00:00 2001 From: Sergey Larin <cerg2010cerg2010(a)mail.ru> Date: Sat, 2 Mar 2019 19:54:55 +0300 Subject: iio: gyro: mpu3050: fix chip ID reading According to the datasheet, the last bit of CHIP_ID register controls I2C bus, and the first one is unused. Handle this correctly. Note that there are chips out there that have a value such that the id check currently fails. Signed-off-by: Sergey Larin <cerg2010cerg2010(a)mail.ru> Reviewed-by: Linus Walleij <linus.walleij(a)linaro.org> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/gyro/mpu3050-core.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/iio/gyro/mpu3050-core.c b/drivers/iio/gyro/mpu3050-core.c index 77fac81a3adc..5ddebede31a6 100644 --- a/drivers/iio/gyro/mpu3050-core.c +++ b/drivers/iio/gyro/mpu3050-core.c @@ -29,7 +29,8 @@ #include "mpu3050.h" -#define MPU3050_CHIP_ID 0x69 +#define MPU3050_CHIP_ID 0x68 +#define MPU3050_CHIP_ID_MASK 0x7E /* * Register map: anything suffixed *_H is a big-endian high byte and always @@ -1176,8 +1177,9 @@ int mpu3050_common_probe(struct device *dev, goto err_power_down; } - if (val != MPU3050_CHIP_ID) { - dev_err(dev, "unsupported chip id %02x\n", (u8)val); + if ((val & MPU3050_CHIP_ID_MASK) != MPU3050_CHIP_ID) { + dev_err(dev, "unsupported chip id %02x\n", + (u8)(val & MPU3050_CHIP_ID_MASK)); ret = -ENODEV; goto err_power_down; } -- 2.21.0

6 years, 5 months

1
0
0 0

patch "staging: iio: ad7192: Fix ad7193 channel address" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: iio: ad7192: Fix ad7193 channel address to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 7ce0f216221856a17fc4934b39284678a5fef2e9 Mon Sep 17 00:00:00 2001 From: Mircea Caprioru <mircea.caprioru(a)analog.com> Date: Wed, 20 Feb 2019 13:08:20 +0200 Subject: staging: iio: ad7192: Fix ad7193 channel address This patch fixes the differential channels addresses for the ad7193. Signed-off-by: Mircea Caprioru <mircea.caprioru(a)analog.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/staging/iio/adc/ad7192.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/staging/iio/adc/ad7192.c b/drivers/staging/iio/adc/ad7192.c index acdbc07fd259..2fc8bc22b57b 100644 --- a/drivers/staging/iio/adc/ad7192.c +++ b/drivers/staging/iio/adc/ad7192.c @@ -109,10 +109,10 @@ #define AD7192_CH_AIN3 BIT(6) /* AIN3 - AINCOM */ #define AD7192_CH_AIN4 BIT(7) /* AIN4 - AINCOM */ -#define AD7193_CH_AIN1P_AIN2M 0x000 /* AIN1(+) - AIN2(-) */ -#define AD7193_CH_AIN3P_AIN4M 0x001 /* AIN3(+) - AIN4(-) */ -#define AD7193_CH_AIN5P_AIN6M 0x002 /* AIN5(+) - AIN6(-) */ -#define AD7193_CH_AIN7P_AIN8M 0x004 /* AIN7(+) - AIN8(-) */ +#define AD7193_CH_AIN1P_AIN2M 0x001 /* AIN1(+) - AIN2(-) */ +#define AD7193_CH_AIN3P_AIN4M 0x002 /* AIN3(+) - AIN4(-) */ +#define AD7193_CH_AIN5P_AIN6M 0x004 /* AIN5(+) - AIN6(-) */ +#define AD7193_CH_AIN7P_AIN8M 0x008 /* AIN7(+) - AIN8(-) */ #define AD7193_CH_TEMP 0x100 /* Temp senseor */ #define AD7193_CH_AIN2P_AIN2M 0x200 /* AIN2(+) - AIN2(-) */ #define AD7193_CH_AIN1 0x401 /* AIN1 - AINCOM */ -- 2.21.0

6 years, 5 months

1
0
0 0

patch "iio: Fix scan mask selection" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: Fix scan mask selection to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 20ea39ef9f2f911bd01c69519e7d69cfec79fde3 Mon Sep 17 00:00:00 2001 From: Lars-Peter Clausen <lars(a)metafoo.de> Date: Wed, 20 Feb 2019 17:11:32 +0200 Subject: iio: Fix scan mask selection The trialmask is expected to have all bits set to 0 after allocation. Currently kmalloc_array() is used which does not zero the memory and so random bits are set. This results in random channels being enabled when they shouldn't. Replace kmalloc_array() with kcalloc() which has the same interface but zeros the memory. Note the fix is actually required earlier than the below fixes tag, but will require a manual backport due to move from kmalloc to kmalloc_array. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> Signed-off-by: Alexandru Ardelean <alexandru.ardelean(a)analog.com> Fixes commit 057ac1acdfc4 ("iio: Use kmalloc_array() in iio_scan_mask_set()"). Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/industrialio-buffer.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/iio/industrialio-buffer.c b/drivers/iio/industrialio-buffer.c index cd5bfe39591b..dadd921a4a30 100644 --- a/drivers/iio/industrialio-buffer.c +++ b/drivers/iio/industrialio-buffer.c @@ -320,9 +320,8 @@ static int iio_scan_mask_set(struct iio_dev *indio_dev, const unsigned long *mask; unsigned long *trialmask; - trialmask = kmalloc_array(BITS_TO_LONGS(indio_dev->masklength), - sizeof(*trialmask), - GFP_KERNEL); + trialmask = kcalloc(BITS_TO_LONGS(indio_dev->masklength), + sizeof(*trialmask), GFP_KERNEL); if (trialmask == NULL) return -ENOMEM; if (!indio_dev->masklength) { -- 2.21.0

6 years, 5 months

1
0
0 0

patch "Staging: iio: meter: fixed typo" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Staging: iio: meter: fixed typo to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 0a8a29be499cbb67df79370aaf5109085509feb8 Mon Sep 17 00:00:00 2001 From: Leonard Pollak <leonardp(a)tr-host.de> Date: Wed, 13 Feb 2019 11:19:52 +0100 Subject: Staging: iio: meter: fixed typo This patch fixes an obvious typo, which will cause erroneously returning the Peak Voltage instead of the Peak Current. Signed-off-by: Leonard Pollak <leonardp(a)tr-host.de> Cc: <Stable(a)vger.kernel.org> Acked-by: Michael Hennerich <michael.hennerich(a)analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/staging/iio/meter/ade7854.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/iio/meter/ade7854.c b/drivers/staging/iio/meter/ade7854.c index 029c3bf42d4d..07774c000c5a 100644 --- a/drivers/staging/iio/meter/ade7854.c +++ b/drivers/staging/iio/meter/ade7854.c @@ -269,7 +269,7 @@ static IIO_DEV_ATTR_VPEAK(0644, static IIO_DEV_ATTR_IPEAK(0644, ade7854_read_32bit, ade7854_write_32bit, - ADE7854_VPEAK); + ADE7854_IPEAK); static IIO_DEV_ATTR_APHCAL(0644, ade7854_read_16bit, ade7854_write_16bit, -- 2.21.0

6 years, 5 months

1
0
0 0

patch "iio/gyro/bmg160: Use millidegrees for temperature scale" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio/gyro/bmg160: Use millidegrees for temperature scale to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 40a7198a4a01037003c7ca714f0d048a61e729ac Mon Sep 17 00:00:00 2001 From: Mike Looijmans <mike.looijmans(a)topic.nl> Date: Wed, 13 Feb 2019 08:41:47 +0100 Subject: iio/gyro/bmg160: Use millidegrees for temperature scale Standard unit for temperature is millidegrees Celcius, whereas this driver was reporting in degrees. Fix the scale factor in the driver. Signed-off-by: Mike Looijmans <mike.looijmans(a)topic.nl> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/gyro/bmg160_core.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c index 63ca31628a93..92c07ab826eb 100644 --- a/drivers/iio/gyro/bmg160_core.c +++ b/drivers/iio/gyro/bmg160_core.c @@ -582,11 +582,10 @@ static int bmg160_read_raw(struct iio_dev *indio_dev, case IIO_CHAN_INFO_LOW_PASS_FILTER_3DB_FREQUENCY: return bmg160_get_filter(data, val); case IIO_CHAN_INFO_SCALE: - *val = 0; switch (chan->type) { case IIO_TEMP: - *val2 = 500000; - return IIO_VAL_INT_PLUS_MICRO; + *val = 500; + return IIO_VAL_INT; case IIO_ANGL_VEL: { int i; @@ -594,6 +593,7 @@ static int bmg160_read_raw(struct iio_dev *indio_dev, for (i = 0; i < ARRAY_SIZE(bmg160_scale_table); ++i) { if (bmg160_scale_table[i].dps_range == data->dps_range) { + *val = 0; *val2 = bmg160_scale_table[i].scale; return IIO_VAL_INT_PLUS_MICRO; } -- 2.21.0

6 years, 5 months

1
0
0 0

Re: Please merge IPv6 fix for drop fragment smaller than MTU

by Greg Kroah-Hartman

On Mon, Apr 01, 2019 at 03:34:52PM -0600, Captain Wiggum wrote: > Hi Greg, > > An error was introduced in 4.9.134 (and the other LTS branches also). > This causes 18 test cases from the TAHI IPv6 test suite to fail. > I added you to the mail thread about this subject a month back. > It has been fixed in upstream for some time now, but not in the LTS branches. > Please merge this undo-patch into the LTS branches. > > $ git diff a8444b1ccb20339774af58e40ad42296074fb484 > a8444b1ccb20339774af58e40ad42296074fb484~ > > diff --git a/net/ipv6/netfilter/nf_conntrack_reasm.c > b/net/ipv6/netfilter/nf_conntrack_reasm.c > index b815417..ff49d1f 100644 > --- a/net/ipv6/netfilter/nf_conntrack_reasm.c > +++ b/net/ipv6/netfilter/nf_conntrack_reasm.c > @@ -564,10 +564,6 @@ int nf_ct_frag6_gather(struct net *net, struct > sk_buff *skb, u32 user) > hdr = ipv6_hdr(skb); > fhdr = (struct frag_hdr *)skb_transport_header(skb); > > - if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU && > - fhdr->frag_off & htons(IP6_MF)) > - return -EINVAL; > - > skb_orphan(skb); > fq = fq_find(net, fhdr->identification, user, hdr, > skb->dev ? skb->dev->ifindex : 0); > diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c > index 78656bb..dbe726c 100644 > --- a/net/ipv6/reassembly.c > +++ b/net/ipv6/reassembly.c > @@ -516,10 +516,6 @@ static int ipv6_frag_rcv(struct sk_buff *skb) > return 1; > } > > - if (skb->len - skb_network_offset(skb) < IPV6_MIN_MTU && > - fhdr->frag_off & htons(IP6_MF)) > - goto fail_hdr; > - > iif = skb->dev ? skb->dev->ifindex : 0; > fq = fq_find(net, fhdr->identification, hdr, iif); > if (fq) { I can't take a random, white-space damaged patch to a stable kernel tree without it being submitted in a format that I can apply it in at the very least :( Also, please always cc: stable(a)vger.kernel.org for stable kernel things, the documentation: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html should have explained all of this, and if not, please let us know what needs to be improved there. If you can resend this there, and mention the needed follow-on patches, I will be glad to queue it up. thanks, greg k-h

6 years, 5 months

1
0
0 0

[For Stable] mm: memcontrol: fix excessive complexity in memory.stat reporting

by Vaibhav Rustagi

In linux stable kernel (tested on 4.14), reading memory.stat in case of tens of thousands of ghost cgroups pinned by lingering page cache takes up to 100 ms ~ 700 ms to complete the reading. Repro steps (tested on 4.14 kernel): $ cat /tmp/make_zombies mkdir /tmp/fs mount -t tmpfs nodev /tmp/fs for i in {1..10000}; do mkdir /sys/fs/cgroup/memory/z$i (echo $BASHPID >> /sys/fs/cgroup/memory/z$i/cgroup.procs && echo $i > /tmp/fs/$i) done # establish baseline $ perf stat -r3 cat /sys/fs/cgroup/memory/memory.stat > /dev/null 0.011642670 seconds time elapsed $ bash /tmp/make_zombies $ perf stat -r3 cat /sys/fs/cgroup/memory/memory.stat > /dev/null 0.134939281 seconds time elapsed $ rmdir /sys/fs/cgroup/memory/z* $ perf stat -r3 cat /sys/fs/cgroup/memory/memory.stat > /dev/null 0.135323145 seconds time elapsed # even after rmdir we have zombies, so still slow. The fix is already present in linux master (since 4.16) by following commits: c9019e9bf42e66d028d70d2da6206cad4dd9250d mm: memcontrol: eliminate raw access to stat and event counters 284542656e22c43fdada8c8cc0ca9ede8453eed7 mm: memcontrol: implement lruvec stat functions on top of each other a983b5ebee57209c99f68c8327072f25e0e6e3da mm: memcontrol: fix excessive complexity in memory.stat reporting c3cc39118c3610eb6ab4711bc624af7fc48a35fe mm: memcontrol: fix NR_WRITEBACK leak in memcg and system stats e27be240df53f1a20c659168e722b5d9f16cc7f4 mm: memcg: make sure memory.events is uptodate when waking pollers I would like to request cherry-picking the above commits to linux-stable branch - 4.14. Thanks, Vaibhav

6 years, 5 months

2
1
0 0

stable-rc/linux-4.9.y boot: 102 boots: 1 failed, 83 passed with 18 offline (v4.9.166-57-gddec8bf2f297)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 102 boots: 1 failed, 83 passed with 18 offline (v4.9.166-57-gddec8bf2f297) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.166-57-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.166-57-gddec8bf2f297 Git Commit: ddec8bf2f297c9844b75e4fdf2620e39c230dd93 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 51 unique boards, 22 SoC families, 15 builds out of 197 Boot Regressions Detected: arm64: defconfig: gcc-7: qcom-qdf2400: lab-linaro-lkft: new failure (last pass: v4.9.166-58-g68d6c327732b) Boot Failure Detected: arm64: defconfig: gcc-7: qcom-qdf2400: 1 failed lab Offline Platforms: arm: bcm2835_defconfig: gcc-7 bcm2835-rpi-b: 1 offline lab multi_v7_defconfig: gcc-7 alpine-db: 1 offline lab at91-sama5d4_xplained: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab sunxi_defconfig: gcc-7 sun5i-r8-chip: 1 offline lab socfpga_defconfig: gcc-7 socfpga_cyclone5_de0_sockit: 1 offline lab tegra_defconfig: gcc-7 tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab sama5_defconfig: gcc-7 at91-sama5d4_xplained: 1 offline lab qcom_defconfig: gcc-7 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab arm64: defconfig: gcc-7 apq8016-sbc: 1 offline lab juno-r2: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 5 months

1
0
0 0

[PATCH v2] ARM: dts: imx: Fix the AR803X phy-mode

by Fabio Estevam

Commit 6d4cd041f0af ("net: phy: at803x: disable delay only for RGMII mode") exposed an issue on imx DTS files using AR8031/AR8035 PHYs. The end result is that the boards can no longer obtain an IP address via UDHCP, for example. Quoting Andrew Lunn: "The problem here is, all the DTs were broken since day 0. However, because the PHY driver was also broken, nobody noticed and it worked. Now that the PHY driver has been fixed, all the bugs in the DTs now become an issue" To fix this problem, the phy-mode property needs to be "rgmii-id", which has the following meaning as per Documentation/devicetree/bindings/net/ethernet.txt: "RGMII with internal RX and TX delays provided by the PHY, the MAC should not add the RX or TX delays in this case)" Tested on imx6-sabresd, imx6sx-sdb and imx7d-pico boards with successfully restored networking. Based on the initial submission from Steve Twiss for the imx6qdl-sabresd. Cc: <stable(a)vger.kernel.org> # 4.9+ Signed-off-by: Fabio Estevam <festevam(a)gmail.com> Tested-by: Baruch Siach <baruch(a)tkos.co.il> Tested-by: Soeren Moch <smoch(a)web.de> Tested-by: Steve Twiss <stwiss.opensource(a)diasemi.com> Tested-by: Adam Thomson <Adam.Thomson(a)diasemi.com> Signed-off-by: Steve Twiss <stwiss.opensource(a)diasemi.com> Tested-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- Changes since v1: - Also fix imx6-logicpd and imx6q-marsboard arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi | 2 +- arch/arm/boot/dts/imx6dl-riotboard.dts | 2 +- arch/arm/boot/dts/imx6q-marsboard.dts | 2 +- arch/arm/boot/dts/imx6q-tbs2910.dts | 2 +- arch/arm/boot/dts/imx6qdl-apf6.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-sr-som.dtsi | 2 +- arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 2 +- arch/arm/boot/dts/imx6sx-sabreauto.dts | 2 +- arch/arm/boot/dts/imx6sx-sdb.dtsi | 2 +- arch/arm/boot/dts/imx7d-pico.dtsi | 2 +- 12 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi b/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi index fb01fa6e4224..3cae139e6396 100644 --- a/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi +++ b/arch/arm/boot/dts/imx6-logicpd-baseboard.dtsi @@ -216,7 +216,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-duration = <10>; phy-reset-gpios = <&gpio1 24 GPIO_ACTIVE_LOW>; phy-supply = <&reg_enet>; diff --git a/arch/arm/boot/dts/imx6dl-riotboard.dts b/arch/arm/boot/dts/imx6dl-riotboard.dts index 65c184bb8fb0..d9de49efa802 100644 --- a/arch/arm/boot/dts/imx6dl-riotboard.dts +++ b/arch/arm/boot/dts/imx6dl-riotboard.dts @@ -92,7 +92,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>; interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>, <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>; diff --git a/arch/arm/boot/dts/imx6q-marsboard.dts b/arch/arm/boot/dts/imx6q-marsboard.dts index d8ccb533b6b7..84b30bd6908f 100644 --- a/arch/arm/boot/dts/imx6q-marsboard.dts +++ b/arch/arm/boot/dts/imx6q-marsboard.dts @@ -110,7 +110,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-gpios = <&gpio3 31 GPIO_ACTIVE_LOW>; status = "okay"; }; diff --git a/arch/arm/boot/dts/imx6q-tbs2910.dts b/arch/arm/boot/dts/imx6q-tbs2910.dts index 2ce8399a10ba..bfff87ce2e1f 100644 --- a/arch/arm/boot/dts/imx6q-tbs2910.dts +++ b/arch/arm/boot/dts/imx6q-tbs2910.dts @@ -98,7 +98,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; status = "okay"; }; diff --git a/arch/arm/boot/dts/imx6qdl-apf6.dtsi b/arch/arm/boot/dts/imx6qdl-apf6.dtsi index 1ebf29f43a24..4738c3c1ab50 100644 --- a/arch/arm/boot/dts/imx6qdl-apf6.dtsi +++ b/arch/arm/boot/dts/imx6qdl-apf6.dtsi @@ -51,7 +51,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-duration = <10>; phy-reset-gpios = <&gpio1 24 GPIO_ACTIVE_LOW>; status = "okay"; diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi index 1280de50a984..f3404dd10537 100644 --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi @@ -292,7 +292,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>, <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>; fsl,err006687-workaround-present; diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi index a0705066ccba..185fb17a3500 100644 --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi @@ -202,7 +202,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>; status = "okay"; }; diff --git a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi index 4ccb7afc4b35..6d7f6b9035bc 100644 --- a/arch/arm/boot/dts/imx6qdl-sr-som.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sr-som.dtsi @@ -53,7 +53,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_microsom_enet_ar8035>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-duration = <2>; phy-reset-gpios = <&gpio4 15 GPIO_ACTIVE_LOW>; status = "okay"; diff --git a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi index b7d5fb421404..50d9a989e06a 100644 --- a/arch/arm/boot/dts/imx6qdl-wandboard.dtsi +++ b/arch/arm/boot/dts/imx6qdl-wandboard.dtsi @@ -224,7 +224,7 @@ &fec { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-reset-gpios = <&gpio3 29 GPIO_ACTIVE_LOW>; interrupts-extended = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>, <&intc 0 119 IRQ_TYPE_LEVEL_HIGH>; diff --git a/arch/arm/boot/dts/imx6sx-sabreauto.dts b/arch/arm/boot/dts/imx6sx-sabreauto.dts index b0ee324afe58..315044ccd65f 100644 --- a/arch/arm/boot/dts/imx6sx-sabreauto.dts +++ b/arch/arm/boot/dts/imx6sx-sabreauto.dts @@ -75,7 +75,7 @@ &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-handle = <&ethphy1>; fsl,magic-packet; status = "okay"; diff --git a/arch/arm/boot/dts/imx6sx-sdb.dtsi b/arch/arm/boot/dts/imx6sx-sdb.dtsi index 08ede56c3f10..f6972deb5e39 100644 --- a/arch/arm/boot/dts/imx6sx-sdb.dtsi +++ b/arch/arm/boot/dts/imx6sx-sdb.dtsi @@ -191,7 +191,7 @@ pinctrl-names = "default"; pinctrl-0 = <&pinctrl_enet1>; phy-supply = <&reg_enet_3v3>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-handle = <&ethphy1>; phy-reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW>; status = "okay"; diff --git a/arch/arm/boot/dts/imx7d-pico.dtsi b/arch/arm/boot/dts/imx7d-pico.dtsi index 3fd595a71202..6f50ebf31a0a 100644 --- a/arch/arm/boot/dts/imx7d-pico.dtsi +++ b/arch/arm/boot/dts/imx7d-pico.dtsi @@ -92,7 +92,7 @@ <&clks IMX7D_ENET1_TIME_ROOT_CLK>; assigned-clock-parents = <&clks IMX7D_PLL_ENET_MAIN_100M_CLK>; assigned-clock-rates = <0>, <100000000>; - phy-mode = "rgmii"; + phy-mode = "rgmii-id"; phy-handle = <&ethphy0>; fsl,magic-packet; phy-reset-gpios = <&gpio6 11 GPIO_ACTIVE_LOW>; -- 2.17.1

6 years, 5 months

2
1
0 0

stable-rc/linux-4.19.y boot: 119 boots: 0 failed, 102 passed with 16 offline, 1 untried/unknown (v4.19.32-135-g01a3983fac4e)

by kernelci.org bot

stable-rc/linux-4.19.y boot: 119 boots: 0 failed, 102 passed with 16 offline, 1 untried/unknown (v4.19.32-135-g01a3983fac4e) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.32-13… Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.32-135-g01a3983fac4e Git Commit: 01a3983fac4e760561475e7fa8908721c63be26b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 66 unique boards, 24 SoC families, 14 builds out of 206 Offline Platforms: arm: bcm2835_defconfig: gcc-7 bcm2835-rpi-b: 1 offline lab multi_v7_defconfig: gcc-7 alpine-db: 1 offline lab at91-sama5d4_xplained: 1 offline lab qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab socfpga_cyclone5_de0_sockit: 1 offline lab sun5i-r8-chip: 1 offline lab tegra124-jetson-tk1: 1 offline lab tegra_defconfig: gcc-7 tegra124-jetson-tk1: 1 offline lab sunxi_defconfig: gcc-7 sun5i-r8-chip: 1 offline lab sama5_defconfig: gcc-7 at91-sama5d4_xplained: 1 offline lab qcom_defconfig: gcc-7 qcom-apq8064-cm-qs600: 1 offline lab qcom-apq8064-ifc6410: 1 offline lab arm64: defconfig: gcc-7 apq8016-sbc: 1 offline lab juno-r2: 1 offline lab mt7622-rfb1: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 5 months

1
0
0 0

stable-rc/linux-3.18.y boot: 53 boots: 1 failed, 46 passed with 6 offline (v3.18.137-51-g18a36d1a7cff)

by kernelci.org bot

stable-rc/linux-3.18.y boot: 53 boots: 1 failed, 46 passed with 6 offline (v3.18.137-51-g18a36d1a7cff) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-3.18.y/kernel/v3.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-3.18.y/kernel/v3.18.137-5… Tree: stable-rc Branch: linux-3.18.y Git Describe: v3.18.137-51-g18a36d1a7cff Git Commit: 18a36d1a7cff7087bfe30635ba8fc456dffd7566 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 23 unique boards, 12 SoC families, 13 builds out of 189 Boot Failure Detected: x86_64: x86_64_defconfig: gcc-7: minnowboard-turbot-E3826: 1 failed lab Offline Platforms: arm: bcm2835_defconfig: gcc-7 bcm2835-rpi-b: 1 offline lab tegra_defconfig: gcc-7 tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab multi_v7_defconfig: gcc-7 tegra124-jetson-tk1: 1 offline lab tegra20-iris-512: 1 offline lab sama5_defconfig: gcc-7 at91-sama5d4ek: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 5 months

1
0
0 0

[PATCH stable only] nvmet: set loop queue's segment boundary mask as PAGE_SIZE - 1

by Ming Lei

NVMe target only accepts single-page sg list, either file or block device backed target code follows this assumption. However, loop target is one exception, given the sg list is from the host queue directly. This patch sets loop queue's segment boundary mask as PAGE_SIZE - 1 for following NVMe target assumption. Reported-by: Yi Zhang <yi.zhang(a)redhat.com> Fixes: 3a85a5de29ea ("nvme-loop: add a NVMe loopback host driver") Cc: Yi Zhang <yi.zhang(a)redhat.com> Cc: Sagi Grimberg <sagi(a)grimberg.me> Cc: Chaitanya Kulkarni <chaitanya.kulkarni(a)wdc.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Ming Lei <ming.lei(a)redhat.com> --- drivers/nvme/target/loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/nvme/target/loop.c b/drivers/nvme/target/loop.c index b9f623ab01f3..7194f86b9dac 100644 --- a/drivers/nvme/target/loop.c +++ b/drivers/nvme/target/loop.c @@ -549,6 +549,9 @@ static int nvme_loop_create_io_queues(struct nvme_loop_ctrl *ctrl) if (ret) goto out_cleanup_connect_q; + /* target only accepts single-page sg list */ + blk_queue_segment_boundary(ctrl->ctrl.connect_q, PAGE_SIZE - 1); + return 0; out_cleanup_connect_q: -- 2.9.5

6 years, 5 months

3
4
0 0

✅ PASS: Test report for kernel 5.0.6-7505a89.cki+ (stable)

by CKI Project

Hello, We ran automated tests on a recent commit from this kernel tree: Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Commit: 7505a8986041 - Linux 5.0.6-rc1 The results of these automated tests are provided below. Overall result: PASSED Compile: OK Tests: OK Please reply to this email if you have any questions about the tests that we ran or if you have any suggestions on how to make future tests more effective. ,-. ,-. ( C ) ( K ) Continuous `-',-.`-' Kernel ( I ) Integration `-' ______________________________________________________________________________ Compile testing --------------- We compiled the kernel for 3 architectures: aarch64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/aarch64/7505a898604161f421b3c51248… kernel build: https://artifacts.cki-project.org/builds/aarch64/7505a898604161f421b3c51248… ppc64le: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/ppc64le/7505a898604161f421b3c51248… kernel build: https://artifacts.cki-project.org/builds/ppc64le/7505a898604161f421b3c51248… x86_64: make options: make INSTALL_MOD_STRIP=1 -j64 targz-pkg -j64 configuration: https://artifacts.cki-project.org/builds/x86_64/7505a898604161f421b3c512483… kernel build: https://artifacts.cki-project.org/builds/x86_64/7505a898604161f421b3c512483… Hardware testing ---------------- We booted each kernel and ran the following tests: aarch64: ✅ Boot test [0] ✅ LTP lite - release 20190115 [1] ✅ Loopdev Sanity [2] ✅ xfstests: ext4 [3] ✅ xfstests: xfs [3] ✅ Memory function: memfd_create [4] ✅ AMTU (Abstract Machine Test Utility) [5] ✅ Ethernet drivers sanity [6] 🚧 ✅ Networking route: pmtu [7] 🚧 ❎ audit: audit testsuite test [8] ✅ httpd: mod_ssl smoke sanity [9] ✅ httpd: php sanity [10] 🚧 ✅ iotop: sanity [11] 🚧 ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport ✅ redhat-rpm-config: detect-kabi-provides sanity [12] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [13] 🚧 ✅ tuned: tune-processes-through-perf [14] ✅ Usex - version 1.9-29 [15] 🚧 ❎ Storage blktests [16] ✅ lvm thinp sanity [17] ppc64le: ✅ Boot test [0] ✅ LTP lite - release 20190115 [1] ✅ Loopdev Sanity [2] ✅ xfstests: ext4 [3] ✅ xfstests: xfs [3] ✅ Memory function: memfd_create [4] ✅ AMTU (Abstract Machine Test Utility) [5] ✅ Ethernet drivers sanity [6] 🚧 ✅ Networking route: pmtu [7] 🚧 ❎ audit: audit testsuite test [8] ✅ httpd: mod_ssl smoke sanity [9] ✅ httpd: php sanity [10] 🚧 ✅ iotop: sanity [11] 🚧 ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport ✅ redhat-rpm-config: detect-kabi-provides sanity [12] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [13] 🚧 ✅ selinux-policy: serge-testsuite [18] 🚧 ✅ tuned: tune-processes-through-perf [14] ✅ Usex - version 1.9-29 [15] 🚧 ❎ Storage blktests [16] ✅ lvm thinp sanity [17] x86_64: ✅ Boot test [0] ✅ LTP lite - release 20190115 [1] ✅ Loopdev Sanity [2] ✅ xfstests: ext4 [3] ✅ xfstests: xfs [3] ✅ Memory function: memfd_create [4] ✅ AMTU (Abstract Machine Test Utility) [5] ✅ Ethernet drivers sanity [6] 🚧 ✅ Networking route: pmtu [7] 🚧 ❎ audit: audit testsuite test [8] ✅ httpd: mod_ssl smoke sanity [9] ✅ httpd: php sanity [10] 🚧 ✅ iotop: sanity [11] 🚧 ✅ /CoreOS/net-snmp/Regression/bz251332-tcp-transport ✅ redhat-rpm-config: detect-kabi-provides sanity [12] ✅ redhat-rpm-config: kabi-whitelist-not-found sanity [13] 🚧 ✅ selinux-policy: serge-testsuite [18] 🚧 ✅ tuned: tune-processes-through-perf [14] ✅ Usex - version 1.9-29 [15] 🚧 ❎ Storage blktests [16] ✅ lvm thinp sanity [17] Test source: [0]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [1]: https://github.com/CKI-project/tests-beaker/archive/master.zip#distribution… [2]: https://github.com/CKI-project/tests-beaker/archive/master.zip#filesystems/… [3]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/filesystems… [4]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/memory/func… [5]: https://github.com/CKI-project/tests-beaker/archive/master.zip#misc/amtu [6]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [7]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/networking/… [8]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/aud… [9]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [10]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/htt… [11]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/iot… [12]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/red… [13]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/red… [14]: https://github.com/CKI-project/tests-beaker/archive/master.zip#packages/tun… [15]: https://github.com/CKI-project/tests-beaker/archive/master.zip#standards/us… [16]: https://github.com/CKI-project/tests-beaker/archive/master.zip#storage/blk [17]: https://github.com/CKI-project/tests-beaker/archive/master.zip#storage/lvm/… [18]: https://github.com/CKI-project/tests-beaker/archive/master.zip#/packages/se… Waived tests (marked with 🚧) ----------------------------- This test run included waived tests. Such tests are executed but their results are not taken into account. Tests are waived when their results are not reliable enough, e.g. when they're just introduced or are being fixed.

6 years, 5 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror