* [PATCH v5 5/6] dt-bindings: clock: Add and reorder ABI for X1000.
From: 周琰杰 (Zhou Yanjie) @ 2020-02-14 17:27 UTC (permalink / raw)
To: linux-mips
Cc: linux-clk, linux-kernel, devicetree, paul, mturquette, sboyd,
robh+dt, mark.rutland
In-Reply-To: <1581701262-110556-1-git-send-email-zhouyanjie@wanyeetech.com>
The SSI clock of X1000 not like JZ4770 and JZ4780, they are not
directly derived from the output of SSIPLL, but from the clock
obtained by dividing the frequency by 2. "X1000_CLK_SSIPLL_DIV2"
is added for this purpose, it must between "X1000_CLK_SSIPLL"
and "X1000_CLK_SSIMUX", otherwise an error will occurs when
initializing the clock. These ABIs are only used for X1000, and
I'm sure that no other devicetree out there is using these ABIs,
so we should be able to reorder them.
Signed-off-by: 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com>
---
Notes:
v5:
New patch.
include/dt-bindings/clock/x1000-cgu.h | 58 ++++++++++++++++++-----------------
1 file changed, 30 insertions(+), 28 deletions(-)
diff --git a/include/dt-bindings/clock/x1000-cgu.h b/include/dt-bindings/clock/x1000-cgu.h
index bbaebaf..5d6eec5 100644
--- a/include/dt-bindings/clock/x1000-cgu.h
+++ b/include/dt-bindings/clock/x1000-cgu.h
@@ -12,33 +12,35 @@
#ifndef __DT_BINDINGS_CLOCK_X1000_CGU_H__
#define __DT_BINDINGS_CLOCK_X1000_CGU_H__
-#define X1000_CLK_EXCLK 0
-#define X1000_CLK_RTCLK 1
-#define X1000_CLK_APLL 2
-#define X1000_CLK_MPLL 3
-#define X1000_CLK_SCLKA 4
-#define X1000_CLK_CPUMUX 5
-#define X1000_CLK_CPU 6
-#define X1000_CLK_L2CACHE 7
-#define X1000_CLK_AHB0 8
-#define X1000_CLK_AHB2PMUX 9
-#define X1000_CLK_AHB2 10
-#define X1000_CLK_PCLK 11
-#define X1000_CLK_DDR 12
-#define X1000_CLK_MAC 13
-#define X1000_CLK_MSCMUX 14
-#define X1000_CLK_MSC0 15
-#define X1000_CLK_MSC1 16
-#define X1000_CLK_SSIPLL 17
-#define X1000_CLK_SSIMUX 18
-#define X1000_CLK_SFC 19
-#define X1000_CLK_I2C0 20
-#define X1000_CLK_I2C1 21
-#define X1000_CLK_I2C2 22
-#define X1000_CLK_UART0 23
-#define X1000_CLK_UART1 24
-#define X1000_CLK_UART2 25
-#define X1000_CLK_SSI 26
-#define X1000_CLK_PDMA 27
+#define X1000_CLK_EXCLK 0
+#define X1000_CLK_RTCLK 1
+#define X1000_CLK_APLL 2
+#define X1000_CLK_MPLL 3
+#define X1000_CLK_SCLKA 4
+#define X1000_CLK_CPUMUX 5
+#define X1000_CLK_CPU 6
+#define X1000_CLK_L2CACHE 7
+#define X1000_CLK_AHB0 8
+#define X1000_CLK_AHB2PMUX 9
+#define X1000_CLK_AHB2 10
+#define X1000_CLK_PCLK 11
+#define X1000_CLK_DDR 12
+#define X1000_CLK_MAC 13
+#define X1000_CLK_MSCMUX 14
+#define X1000_CLK_MSC0 15
+#define X1000_CLK_MSC1 16
+#define X1000_CLK_OTG 17
+#define X1000_CLK_SSIPLL 18
+#define X1000_CLK_SSIPLL_DIV2 19
+#define X1000_CLK_SSIMUX 20
+#define X1000_CLK_SFC 21
+#define X1000_CLK_I2C0 22
+#define X1000_CLK_I2C1 23
+#define X1000_CLK_I2C2 24
+#define X1000_CLK_UART0 25
+#define X1000_CLK_UART1 26
+#define X1000_CLK_UART2 27
+#define X1000_CLK_SSI 28
+#define X1000_CLK_PDMA 29
#endif /* __DT_BINDINGS_CLOCK_X1000_CGU_H__ */
--
2.7.4
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 288/459] arm64: dts: rockchip: fix dwmmc clock name for px30
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Johan Jonker, Heiko Stuebner, Sasha Levin, devicetree,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Johan Jonker <jbx6244@gmail.com>
[ Upstream commit 7f2147350291569acd1df5a26dcdfc573916016f ]
An experimental test with the command below gives this error:
px30-evb.dt.yaml: dwmmc@ff390000: clock-names:2:
'ciu-drive' was expected
'ciu-drv' is not a valid dwmmc clock name,
so fix this by changing it to 'ciu-drive'.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20200110161200.22755-1-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/rockchip/px30.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
index eb992d60e6baf..9e09909a510a1 100644
--- a/arch/arm64/boot/dts/rockchip/px30.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
@@ -768,7 +768,7 @@
interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_SDMMC>, <&cru SCLK_SDMMC>,
<&cru SCLK_SDMMC_DRV>, <&cru SCLK_SDMMC_SAMPLE>;
- clock-names = "biu", "ciu", "ciu-drv", "ciu-sample";
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
max-frequency = <150000000>;
pinctrl-names = "default";
@@ -783,7 +783,7 @@
interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_SDIO>, <&cru SCLK_SDIO>,
<&cru SCLK_SDIO_DRV>, <&cru SCLK_SDIO_SAMPLE>;
- clock-names = "biu", "ciu", "ciu-drv", "ciu-sample";
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
max-frequency = <150000000>;
pinctrl-names = "default";
@@ -798,7 +798,7 @@
interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru HCLK_EMMC>, <&cru SCLK_EMMC>,
<&cru SCLK_EMMC_DRV>, <&cru SCLK_EMMC_SAMPLE>;
- clock-names = "biu", "ciu", "ciu-drv", "ciu-sample";
+ clock-names = "biu", "ciu", "ciu-drive", "ciu-sample";
fifo-depth = <0x100>;
max-frequency = <150000000>;
power-domains = <&power PX30_PD_MMC_NAND>;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 250/459] ASoC: Intel: sof_rt5682: Ignore the speaker amp when there isn't one.
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sam McNally, Pierre-Louis Bossart, Mark Brown, Sasha Levin,
alsa-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Sam McNally <sammc@chromium.org>
[ Upstream commit d4b74e218a8d0d6cf58e546627ab9d4d4f2645ab ]
Some members of the Google_Hatch family include a rt5682 jack codec, but
no speaker amplifier. This uses the same driver (sof_rt5682) as a
combination of rt5682 jack codec and max98357a speaker amplifier. Within
the sof_rt5682 driver, these cases are not currently distinguishable,
relying on a DMI quirk to decide the configuration. This causes an
incorrect configuration when only the rt5682 is present on a
Google_Hatch device.
For CML, the jack codec is used as the primary key when matching,
with a possible speaker amplifier described in quirk_data. The two cases
of interest are the second and third 10EC5682 entries in
snd_soc_acpi_intel_cml_machines[]. The second entry matches the
combination of rt5682 and max98357a, resulting in the quirk_data field
in the snd_soc_acpi_mach being non-null, pointing at
max98357a_spk_codecs, the snd_soc_acpi_codecs for the matched speaker
amplifier. The third entry matches just the rt5682, resulting in a null
quirk_data.
The sof_rt5682 driver's DMI data matching identifies that a speaker
amplifier is present for all Google_Hatch family devices. Detect cases
where there is no speaker amplifier by checking for a null quirk_data in
the snd_soc_acpi_mach and remove the speaker amplifier bit in that case.
Signed-off-by: Sam McNally <sammc@chromium.org>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20200103124921.v3.1.Ib87c4a7fbb3fc818ea12198e291b87dc2d5bc8c2@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/intel/boards/sof_rt5682.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/sound/soc/intel/boards/sof_rt5682.c b/sound/soc/intel/boards/sof_rt5682.c
index 9441ddfeea5e6..06b7d6c6c9a04 100644
--- a/sound/soc/intel/boards/sof_rt5682.c
+++ b/sound/soc/intel/boards/sof_rt5682.c
@@ -594,6 +594,14 @@ static int sof_audio_probe(struct platform_device *pdev)
dmi_check_system(sof_rt5682_quirk_table);
+ mach = (&pdev->dev)->platform_data;
+
+ /* A speaker amp might not be present when the quirk claims one is.
+ * Detect this via whether the machine driver match includes quirk_data.
+ */
+ if ((sof_rt5682_quirk & SOF_SPEAKER_AMP_PRESENT) && !mach->quirk_data)
+ sof_rt5682_quirk &= ~SOF_SPEAKER_AMP_PRESENT;
+
if (soc_intel_is_byt() || soc_intel_is_cht()) {
is_legacy_cpu = 1;
dmic_be_num = 0;
@@ -654,7 +662,6 @@ static int sof_audio_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&ctx->hdmi_pcm_list);
sof_audio_card_rt5682.dev = &pdev->dev;
- mach = (&pdev->dev)->platform_data;
/* set platform name for each dailink */
ret = snd_soc_fixup_dai_links_platform_name(&sof_audio_card_rt5682,
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 283/459] Input: edt-ft5x06 - work around first register access error
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Philipp Zabel, Marco Felsch, Andy Shevchenko, Dmitry Torokhov,
Sasha Levin, linux-input
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Philipp Zabel <p.zabel@pengutronix.de>
[ Upstream commit e112324cc0422c046f1cf54c56f333d34fa20885 ]
The EP0700MLP1 returns bogus data on the first register read access
(reading the threshold parameter from register 0x00):
edt_ft5x06 2-0038: crc error: 0xfc expected, got 0x40
It ignores writes until then. This patch adds a dummy read after which
the number of sensors and parameter read/writes work correctly.
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/input/touchscreen/edt-ft5x06.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 5525f1fb1526e..240e8de24cd24 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -1041,6 +1041,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
{
const struct edt_i2c_chip_data *chip_data;
struct edt_ft5x06_ts_data *tsdata;
+ u8 buf[2] = { 0xfc, 0x00 };
struct input_dev *input;
unsigned long irq_flags;
int error;
@@ -1110,6 +1111,12 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
return error;
}
+ /*
+ * Dummy read access. EP0700MLP1 returns bogus data on the first
+ * register read access and ignores writes.
+ */
+ edt_ft5x06_ts_readwrite(tsdata->client, 2, buf, 2, buf);
+
edt_ft5x06_ts_set_regs(tsdata);
edt_ft5x06_ts_get_defaults(&client->dev, tsdata);
edt_ft5x06_ts_get_parameters(tsdata);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 280/459] rcu: Use WRITE_ONCE() for assignments to ->pprev for hlist_nulls
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Paul E. McKenney, Eric Dumazet, Sasha Levin, rcu
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: "Paul E. McKenney" <paulmck@kernel.org>
[ Upstream commit 860c8802ace14c646864795e057349c9fb2d60ad ]
Eric Dumazet supplied a KCSAN report of a bug that forces use
of hlist_unhashed_lockless() from sk_unhashed():
------------------------------------------------------------------------
BUG: KCSAN: data-race in inet_unhash / inet_unhash
write to 0xffff8880a69a0170 of 8 bytes by interrupt on cpu 1:
__hlist_nulls_del include/linux/list_nulls.h:88 [inline]
hlist_nulls_del_init_rcu include/linux/rculist_nulls.h:36 [inline]
__sk_nulls_del_node_init_rcu include/net/sock.h:676 [inline]
inet_unhash+0x38f/0x4a0 net/ipv4/inet_hashtables.c:612
tcp_set_state+0xfa/0x3e0 net/ipv4/tcp.c:2249
tcp_done+0x93/0x1e0 net/ipv4/tcp.c:3854
tcp_write_err+0x7e/0xc0 net/ipv4/tcp_timer.c:56
tcp_retransmit_timer+0x9b8/0x16d0 net/ipv4/tcp_timer.c:479
tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:599
tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:619
call_timer_fn+0x5f/0x2f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0xc0c/0xcd0 kernel/time/timer.c:1786
__do_softirq+0x115/0x33f kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0xbb/0xe0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71
arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571
default_idle_call+0x1e/0x40 kernel/sched/idle.c:94
cpuidle_idle_call kernel/sched/idle.c:154 [inline]
do_idle+0x1af/0x280 kernel/sched/idle.c:263
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355
start_secondary+0x208/0x260 arch/x86/kernel/smpboot.c:264
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
read to 0xffff8880a69a0170 of 8 bytes by interrupt on cpu 0:
sk_unhashed include/net/sock.h:607 [inline]
inet_unhash+0x3d/0x4a0 net/ipv4/inet_hashtables.c:592
tcp_set_state+0xfa/0x3e0 net/ipv4/tcp.c:2249
tcp_done+0x93/0x1e0 net/ipv4/tcp.c:3854
tcp_write_err+0x7e/0xc0 net/ipv4/tcp_timer.c:56
tcp_retransmit_timer+0x9b8/0x16d0 net/ipv4/tcp_timer.c:479
tcp_write_timer_handler+0x42d/0x510 net/ipv4/tcp_timer.c:599
tcp_write_timer+0xd1/0xf0 net/ipv4/tcp_timer.c:619
call_timer_fn+0x5f/0x2f0 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1449 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0xc0c/0xcd0 kernel/time/timer.c:1786
__do_softirq+0x115/0x33f kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0xbb/0xe0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:536 [inline]
smp_apic_timer_interrupt+0xe6/0x280 arch/x86/kernel/apic/apic.c:1137
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:830
native_safe_halt+0xe/0x10 arch/x86/kernel/paravirt.c:71
arch_cpu_idle+0x1f/0x30 arch/x86/kernel/process.c:571
default_idle_call+0x1e/0x40 kernel/sched/idle.c:94
cpuidle_idle_call kernel/sched/idle.c:154 [inline]
do_idle+0x1af/0x280 kernel/sched/idle.c:263
cpu_startup_entry+0x1b/0x20 kernel/sched/idle.c:355
rest_init+0xec/0xf6 init/main.c:452
arch_call_rest_init+0x17/0x37
start_kernel+0x838/0x85e init/main.c:786
x86_64_start_reservations+0x29/0x2b arch/x86/kernel/head64.c:490
x86_64_start_kernel+0x72/0x76 arch/x86/kernel/head64.c:471
secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.4.0-rc6+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
------------------------------------------------------------------------
This commit therefore replaces C-language assignments with WRITE_ONCE()
in include/linux/list_nulls.h and include/linux/rculist_nulls.h.
Reported-by: Eric Dumazet <edumazet@google.com> # For KCSAN
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/list_nulls.h | 8 ++++----
include/linux/rculist_nulls.h | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/include/linux/list_nulls.h b/include/linux/list_nulls.h
index 3ef96743db8da..1ecd35664e0d3 100644
--- a/include/linux/list_nulls.h
+++ b/include/linux/list_nulls.h
@@ -72,10 +72,10 @@ static inline void hlist_nulls_add_head(struct hlist_nulls_node *n,
struct hlist_nulls_node *first = h->first;
n->next = first;
- n->pprev = &h->first;
+ WRITE_ONCE(n->pprev, &h->first);
h->first = n;
if (!is_a_nulls(first))
- first->pprev = &n->next;
+ WRITE_ONCE(first->pprev, &n->next);
}
static inline void __hlist_nulls_del(struct hlist_nulls_node *n)
@@ -85,13 +85,13 @@ static inline void __hlist_nulls_del(struct hlist_nulls_node *n)
WRITE_ONCE(*pprev, next);
if (!is_a_nulls(next))
- next->pprev = pprev;
+ WRITE_ONCE(next->pprev, pprev);
}
static inline void hlist_nulls_del(struct hlist_nulls_node *n)
{
__hlist_nulls_del(n);
- n->pprev = LIST_POISON2;
+ WRITE_ONCE(n->pprev, LIST_POISON2);
}
/**
diff --git a/include/linux/rculist_nulls.h b/include/linux/rculist_nulls.h
index 61974c4c566be..90f2e2232c6d7 100644
--- a/include/linux/rculist_nulls.h
+++ b/include/linux/rculist_nulls.h
@@ -34,7 +34,7 @@ static inline void hlist_nulls_del_init_rcu(struct hlist_nulls_node *n)
{
if (!hlist_nulls_unhashed(n)) {
__hlist_nulls_del(n);
- n->pprev = NULL;
+ WRITE_ONCE(n->pprev, NULL);
}
}
@@ -66,7 +66,7 @@ static inline void hlist_nulls_del_init_rcu(struct hlist_nulls_node *n)
static inline void hlist_nulls_del_rcu(struct hlist_nulls_node *n)
{
__hlist_nulls_del(n);
- n->pprev = LIST_POISON2;
+ WRITE_ONCE(n->pprev, LIST_POISON2);
}
/**
@@ -94,10 +94,10 @@ static inline void hlist_nulls_add_head_rcu(struct hlist_nulls_node *n,
struct hlist_nulls_node *first = h->first;
n->next = first;
- n->pprev = &h->first;
+ WRITE_ONCE(n->pprev, &h->first);
rcu_assign_pointer(hlist_nulls_first_rcu(h), n);
if (!is_a_nulls(first))
- first->pprev = &n->next;
+ WRITE_ONCE(first->pprev, &n->next);
}
/**
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 247/459] net: phy: fixed_phy: fix use-after-free when checking link GPIO
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Dmitry Torokhov, David S . Miller, Sasha Levin, netdev
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
[ Upstream commit d266f19f3ae7fbcaf92229639b78d2110ae44f33 ]
If we fail to locate GPIO for any reason other than deferral or
not-found-GPIO, we try to print device tree node info, however if might
be freed already as we called of_node_put() on it.
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/phy/fixed_phy.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 7c5265fd2b94d..4190f9ed5313d 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -212,16 +212,13 @@ static struct gpio_desc *fixed_phy_get_gpiod(struct device_node *np)
*/
gpiod = gpiod_get_from_of_node(fixed_link_node, "link-gpios", 0,
GPIOD_IN, "mdio");
- of_node_put(fixed_link_node);
- if (IS_ERR(gpiod)) {
- if (PTR_ERR(gpiod) == -EPROBE_DEFER)
- return gpiod;
-
+ if (IS_ERR(gpiod) && PTR_ERR(gpiod) != -EPROBE_DEFER) {
if (PTR_ERR(gpiod) != -ENOENT)
pr_err("error getting GPIO for fixed link %pOF, proceed without\n",
fixed_link_node);
gpiod = NULL;
}
+ of_node_put(fixed_link_node);
return gpiod;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 279/459] efi/x86: Don't panic or BUG() on non-critical error conditions
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Ard Biesheuvel, Andy Lutomirski, Ard Biesheuvel, Arvind Sankar,
Matthew Garrett, linux-efi, Ingo Molnar, Sasha Levin,
platform-driver-x86, x86
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Ard Biesheuvel <ardb@kernel.org>
[ Upstream commit e2d68a955e49d61fd0384f23e92058dc9b79be5e ]
The logic in __efi_enter_virtual_mode() does a number of steps in
sequence, all of which may fail in one way or the other. In most
cases, we simply print an error and disable EFI runtime services
support, but in some cases, we BUG() or panic() and bring down the
system when encountering conditions that we could easily handle in
the same way.
While at it, replace a pointless page-to-virt-phys conversion with
one that goes straight from struct page to physical.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Matthew Garrett <mjg59@google.com>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-14-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/x86/platform/efi/efi.c | 28 ++++++++++++++--------------
arch/x86/platform/efi/efi_64.c | 9 +++++----
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 8a4f389330396..01d7ca492741d 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -954,16 +954,14 @@ static void __init __efi_enter_virtual_mode(void)
if (efi_alloc_page_tables()) {
pr_err("Failed to allocate EFI page tables\n");
- clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
- return;
+ goto err;
}
efi_merge_regions();
new_memmap = efi_map_regions(&count, &pg_shift);
if (!new_memmap) {
pr_err("Error reallocating memory, EFI runtime non-functional!\n");
- clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
- return;
+ goto err;
}
pa = __pa(new_memmap);
@@ -977,8 +975,7 @@ static void __init __efi_enter_virtual_mode(void)
if (efi_memmap_init_late(pa, efi.memmap.desc_size * count)) {
pr_err("Failed to remap late EFI memory map\n");
- clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
- return;
+ goto err;
}
if (efi_enabled(EFI_DBG)) {
@@ -986,12 +983,11 @@ static void __init __efi_enter_virtual_mode(void)
efi_print_memmap();
}
- BUG_ON(!efi.systab);
+ if (WARN_ON(!efi.systab))
+ goto err;
- if (efi_setup_page_tables(pa, 1 << pg_shift)) {
- clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
- return;
- }
+ if (efi_setup_page_tables(pa, 1 << pg_shift))
+ goto err;
efi_sync_low_kernel_mappings();
@@ -1011,9 +1007,9 @@ static void __init __efi_enter_virtual_mode(void)
}
if (status != EFI_SUCCESS) {
- pr_alert("Unable to switch EFI into virtual mode (status=%lx)!\n",
- status);
- panic("EFI call to SetVirtualAddressMap() failed!");
+ pr_err("Unable to switch EFI into virtual mode (status=%lx)!\n",
+ status);
+ goto err;
}
efi_free_boot_services();
@@ -1042,6 +1038,10 @@ static void __init __efi_enter_virtual_mode(void)
/* clean DUMMY object */
efi_delete_dummy_variable();
+ return;
+
+err:
+ clear_bit(EFI_RUNTIME_SERVICES, &efi.flags);
}
void __init efi_enter_virtual_mode(void)
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 08ce8177c3af1..52a1e5192fa80 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -392,11 +392,12 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, unsigned num_pages)
return 0;
page = alloc_page(GFP_KERNEL|__GFP_DMA32);
- if (!page)
- panic("Unable to allocate EFI runtime stack < 4GB\n");
+ if (!page) {
+ pr_err("Unable to allocate EFI runtime stack < 4GB\n");
+ return 1;
+ }
- efi_scratch.phys_stack = virt_to_phys(page_address(page));
- efi_scratch.phys_stack += PAGE_SIZE; /* stack grows down */
+ efi_scratch.phys_stack = page_to_phys(page + 1); /* stack grows down */
npages = (_etext - _text) >> PAGE_SHIFT;
text = __pa(_text);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 277/459] ARM: dts: at91: sama5d3: fix maximum peripheral clock rates
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexandre Belloni, Karl Rudbæk Olsen, Sasha Levin,
linux-arm-kernel, devicetree
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
[ Upstream commit ee0aa926ddb0bd8ba59e33e3803b3b5804e3f5da ]
Currently the maximum rate for peripheral clock is calculated based on a
typical 133MHz MCK. The maximum frequency is defined in the datasheet as a
ratio to MCK. Some sama5d3 platforms are using a 166MHz MCK. Update the
device trees to match the maximum rate based on 166MHz.
Reported-by: Karl Rudbæk Olsen <karl@micro-technic.com>
Fixes: d2e8190b7916 ("ARM: at91/dt: define sama5d3 clocks")
Link: https://lore.kernel.org/r/20200110172007.1253659-1-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/sama5d3.dtsi | 28 ++++++++++++++--------------
arch/arm/boot/dts/sama5d3_can.dtsi | 4 ++--
arch/arm/boot/dts/sama5d3_uart.dtsi | 4 ++--
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d3.dtsi b/arch/arm/boot/dts/sama5d3.dtsi
index f770aace0efd6..203d40be70a51 100644
--- a/arch/arm/boot/dts/sama5d3.dtsi
+++ b/arch/arm/boot/dts/sama5d3.dtsi
@@ -1188,49 +1188,49 @@
usart0_clk: usart0_clk {
#clock-cells = <0>;
reg = <12>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
usart1_clk: usart1_clk {
#clock-cells = <0>;
reg = <13>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
usart2_clk: usart2_clk {
#clock-cells = <0>;
reg = <14>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
usart3_clk: usart3_clk {
#clock-cells = <0>;
reg = <15>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
uart0_clk: uart0_clk {
#clock-cells = <0>;
reg = <16>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
twi0_clk: twi0_clk {
reg = <18>;
#clock-cells = <0>;
- atmel,clk-output-range = <0 16625000>;
+ atmel,clk-output-range = <0 41500000>;
};
twi1_clk: twi1_clk {
#clock-cells = <0>;
reg = <19>;
- atmel,clk-output-range = <0 16625000>;
+ atmel,clk-output-range = <0 41500000>;
};
twi2_clk: twi2_clk {
#clock-cells = <0>;
reg = <20>;
- atmel,clk-output-range = <0 16625000>;
+ atmel,clk-output-range = <0 41500000>;
};
mci0_clk: mci0_clk {
@@ -1246,19 +1246,19 @@
spi0_clk: spi0_clk {
#clock-cells = <0>;
reg = <24>;
- atmel,clk-output-range = <0 133000000>;
+ atmel,clk-output-range = <0 166000000>;
};
spi1_clk: spi1_clk {
#clock-cells = <0>;
reg = <25>;
- atmel,clk-output-range = <0 133000000>;
+ atmel,clk-output-range = <0 166000000>;
};
tcb0_clk: tcb0_clk {
#clock-cells = <0>;
reg = <26>;
- atmel,clk-output-range = <0 133000000>;
+ atmel,clk-output-range = <0 166000000>;
};
pwm_clk: pwm_clk {
@@ -1269,7 +1269,7 @@
adc_clk: adc_clk {
#clock-cells = <0>;
reg = <29>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
dma0_clk: dma0_clk {
@@ -1300,13 +1300,13 @@
ssc0_clk: ssc0_clk {
#clock-cells = <0>;
reg = <38>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
ssc1_clk: ssc1_clk {
#clock-cells = <0>;
reg = <39>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
sha_clk: sha_clk {
diff --git a/arch/arm/boot/dts/sama5d3_can.dtsi b/arch/arm/boot/dts/sama5d3_can.dtsi
index cf06a018ed0f2..2470dd3fff25e 100644
--- a/arch/arm/boot/dts/sama5d3_can.dtsi
+++ b/arch/arm/boot/dts/sama5d3_can.dtsi
@@ -36,13 +36,13 @@
can0_clk: can0_clk {
#clock-cells = <0>;
reg = <40>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
can1_clk: can1_clk {
#clock-cells = <0>;
reg = <41>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
};
};
diff --git a/arch/arm/boot/dts/sama5d3_uart.dtsi b/arch/arm/boot/dts/sama5d3_uart.dtsi
index 4316bdbdc25dd..cb62adbd28ed6 100644
--- a/arch/arm/boot/dts/sama5d3_uart.dtsi
+++ b/arch/arm/boot/dts/sama5d3_uart.dtsi
@@ -41,13 +41,13 @@
uart0_clk: uart0_clk {
#clock-cells = <0>;
reg = <16>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
uart1_clk: uart1_clk {
#clock-cells = <0>;
reg = <17>;
- atmel,clk-output-range = <0 66000000>;
+ atmel,clk-output-range = <0 83000000>;
};
};
};
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 278/459] ARM: dts: at91: sama5d3: define clock rate range for tcb1
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Alexandre Belloni, Karl Rudbæk Olsen, Sasha Levin,
linux-arm-kernel, devicetree
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
[ Upstream commit a7e0f3fc01df4b1b7077df777c37feae8c9e8b6d ]
The clock rate range for the TCB1 clock is missing. define it in the device
tree.
Reported-by: Karl Rudbæk Olsen <karl@micro-technic.com>
Fixes: d2e8190b7916 ("ARM: at91/dt: define sama5d3 clocks")
Link: https://lore.kernel.org/r/20200110172007.1253659-2-alexandre.belloni@bootlin.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/sama5d3_tcb1.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sama5d3_tcb1.dtsi b/arch/arm/boot/dts/sama5d3_tcb1.dtsi
index 1584035daf515..215802b8db301 100644
--- a/arch/arm/boot/dts/sama5d3_tcb1.dtsi
+++ b/arch/arm/boot/dts/sama5d3_tcb1.dtsi
@@ -22,6 +22,7 @@
tcb1_clk: tcb1_clk {
#clock-cells = <0>;
reg = <27>;
+ atmel,clk-output-range = <0 166000000>;
};
};
};
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 273/459] RDMA/core: Fix locking in ib_uverbs_event_read
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Jason Gunthorpe, Yishai Hadas, Håkon Bugge, Sasha Levin,
linux-rdma
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Jason Gunthorpe <jgg@mellanox.com>
[ Upstream commit 14e23bd6d22123f6f3b2747701fa6cd4c6d05873 ]
This should not be using ib_dev to test for disassociation, during
disassociation is_closed is set under lock and the waitq is triggered.
Instead check is_closed and be sure to re-obtain the lock to test the
value after the wait_event returns.
Fixes: 036b10635739 ("IB/uverbs: Enable device removal when there are active user space applications")
Link: https://lore.kernel.org/r/1578504126-9400-12-git-send-email-yishaih@mellanox.com
Signed-off-by: Yishai Hadas <yishaih@mellanox.com>
Reviewed-by: Håkon Bugge <haakon.bugge@oracle.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/core/uverbs_main.c | 32 ++++++++++++---------------
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/infiniband/core/uverbs_main.c b/drivers/infiniband/core/uverbs_main.c
index db98111b47f42..f2a2d1246c198 100644
--- a/drivers/infiniband/core/uverbs_main.c
+++ b/drivers/infiniband/core/uverbs_main.c
@@ -220,7 +220,6 @@ void ib_uverbs_release_file(struct kref *ref)
}
static ssize_t ib_uverbs_event_read(struct ib_uverbs_event_queue *ev_queue,
- struct ib_uverbs_file *uverbs_file,
struct file *filp, char __user *buf,
size_t count, loff_t *pos,
size_t eventsz)
@@ -238,19 +237,16 @@ static ssize_t ib_uverbs_event_read(struct ib_uverbs_event_queue *ev_queue,
if (wait_event_interruptible(ev_queue->poll_wait,
(!list_empty(&ev_queue->event_list) ||
- /* The barriers built into wait_event_interruptible()
- * and wake_up() guarentee this will see the null set
- * without using RCU
- */
- !uverbs_file->device->ib_dev)))
+ ev_queue->is_closed)))
return -ERESTARTSYS;
+ spin_lock_irq(&ev_queue->lock);
+
/* If device was disassociated and no event exists set an error */
- if (list_empty(&ev_queue->event_list) &&
- !uverbs_file->device->ib_dev)
+ if (list_empty(&ev_queue->event_list) && ev_queue->is_closed) {
+ spin_unlock_irq(&ev_queue->lock);
return -EIO;
-
- spin_lock_irq(&ev_queue->lock);
+ }
}
event = list_entry(ev_queue->event_list.next, struct ib_uverbs_event, list);
@@ -285,8 +281,7 @@ static ssize_t ib_uverbs_async_event_read(struct file *filp, char __user *buf,
{
struct ib_uverbs_async_event_file *file = filp->private_data;
- return ib_uverbs_event_read(&file->ev_queue, file->uverbs_file, filp,
- buf, count, pos,
+ return ib_uverbs_event_read(&file->ev_queue, filp, buf, count, pos,
sizeof(struct ib_uverbs_async_event_desc));
}
@@ -296,9 +291,8 @@ static ssize_t ib_uverbs_comp_event_read(struct file *filp, char __user *buf,
struct ib_uverbs_completion_event_file *comp_ev_file =
filp->private_data;
- return ib_uverbs_event_read(&comp_ev_file->ev_queue,
- comp_ev_file->uobj.ufile, filp,
- buf, count, pos,
+ return ib_uverbs_event_read(&comp_ev_file->ev_queue, filp, buf, count,
+ pos,
sizeof(struct ib_uverbs_comp_event_desc));
}
@@ -321,7 +315,9 @@ static __poll_t ib_uverbs_event_poll(struct ib_uverbs_event_queue *ev_queue,
static __poll_t ib_uverbs_async_event_poll(struct file *filp,
struct poll_table_struct *wait)
{
- return ib_uverbs_event_poll(filp->private_data, filp, wait);
+ struct ib_uverbs_async_event_file *file = filp->private_data;
+
+ return ib_uverbs_event_poll(&file->ev_queue, filp, wait);
}
static __poll_t ib_uverbs_comp_event_poll(struct file *filp,
@@ -335,9 +331,9 @@ static __poll_t ib_uverbs_comp_event_poll(struct file *filp,
static int ib_uverbs_async_event_fasync(int fd, struct file *filp, int on)
{
- struct ib_uverbs_event_queue *ev_queue = filp->private_data;
+ struct ib_uverbs_async_event_file *file = filp->private_data;
- return fasync_helper(fd, filp, on, &ev_queue->async_queue);
+ return fasync_helper(fd, filp, on, &file->ev_queue.async_queue);
}
static int ib_uverbs_comp_event_fasync(int fd, struct file *filp, int on)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 274/459] IB/hfi1: Add software counter for ctxt0 seq drop
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Mike Marciniszyn, Kaike Wan, Dennis Dalessandro, Jason Gunthorpe,
Sasha Levin, linux-rdma
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Mike Marciniszyn <mike.marciniszyn@intel.com>
[ Upstream commit 5ffd048698ea5139743acd45e8ab388a683642b8 ]
All other code paths increment some form of drop counter.
This was missed in the original implementation.
Fixes: 82c2611daaf0 ("staging/rdma/hfi1: Handle packets with invalid RHF on context 0")
Link: https://lore.kernel.org/r/20200106134228.119356.96828.stgit@awfm-01.aw.intel.com
Reviewed-by: Kaike Wan <kaike.wan@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hfi1/chip.c | 10 ++++++++++
drivers/infiniband/hw/hfi1/chip.h | 1 +
drivers/infiniband/hw/hfi1/driver.c | 1 +
drivers/infiniband/hw/hfi1/hfi.h | 2 ++
4 files changed, 14 insertions(+)
diff --git a/drivers/infiniband/hw/hfi1/chip.c b/drivers/infiniband/hw/hfi1/chip.c
index 9b1fb84a3d45b..d5961918fe157 100644
--- a/drivers/infiniband/hw/hfi1/chip.c
+++ b/drivers/infiniband/hw/hfi1/chip.c
@@ -1685,6 +1685,14 @@ static u64 access_sw_pio_drain(const struct cntr_entry *entry,
return dd->verbs_dev.n_piodrain;
}
+static u64 access_sw_ctx0_seq_drop(const struct cntr_entry *entry,
+ void *context, int vl, int mode, u64 data)
+{
+ struct hfi1_devdata *dd = context;
+
+ return dd->ctx0_seq_drop;
+}
+
static u64 access_sw_vtx_wait(const struct cntr_entry *entry,
void *context, int vl, int mode, u64 data)
{
@@ -4249,6 +4257,8 @@ static struct cntr_entry dev_cntrs[DEV_CNTR_LAST] = {
access_sw_cpu_intr),
[C_SW_CPU_RCV_LIM] = CNTR_ELEM("RcvLimit", 0, 0, CNTR_NORMAL,
access_sw_cpu_rcv_limit),
+[C_SW_CTX0_SEQ_DROP] = CNTR_ELEM("SeqDrop0", 0, 0, CNTR_NORMAL,
+ access_sw_ctx0_seq_drop),
[C_SW_VTX_WAIT] = CNTR_ELEM("vTxWait", 0, 0, CNTR_NORMAL,
access_sw_vtx_wait),
[C_SW_PIO_WAIT] = CNTR_ELEM("PioWait", 0, 0, CNTR_NORMAL,
diff --git a/drivers/infiniband/hw/hfi1/chip.h b/drivers/infiniband/hw/hfi1/chip.h
index 4ca5ac8d7e9e4..bfccd4ae07a72 100644
--- a/drivers/infiniband/hw/hfi1/chip.h
+++ b/drivers/infiniband/hw/hfi1/chip.h
@@ -926,6 +926,7 @@ enum {
C_DC_PG_STS_TX_MBE_CNT,
C_SW_CPU_INTR,
C_SW_CPU_RCV_LIM,
+ C_SW_CTX0_SEQ_DROP,
C_SW_VTX_WAIT,
C_SW_PIO_WAIT,
C_SW_PIO_DRAIN,
diff --git a/drivers/infiniband/hw/hfi1/driver.c b/drivers/infiniband/hw/hfi1/driver.c
index 01aa1f132f55e..941b465244abe 100644
--- a/drivers/infiniband/hw/hfi1/driver.c
+++ b/drivers/infiniband/hw/hfi1/driver.c
@@ -734,6 +734,7 @@ static noinline int skip_rcv_packet(struct hfi1_packet *packet, int thread)
{
int ret;
+ packet->rcd->dd->ctx0_seq_drop++;
/* Set up for the next packet */
packet->rhqoff += packet->rsize;
if (packet->rhqoff >= packet->maxcnt)
diff --git a/drivers/infiniband/hw/hfi1/hfi.h b/drivers/infiniband/hw/hfi1/hfi.h
index fa45350a9a1d3..6590f56bb295f 100644
--- a/drivers/infiniband/hw/hfi1/hfi.h
+++ b/drivers/infiniband/hw/hfi1/hfi.h
@@ -1153,6 +1153,8 @@ struct hfi1_devdata {
char *boardname; /* human readable board info */
+ u64 ctx0_seq_drop;
+
/* reset value */
u64 z_int_counter;
u64 z_rcv_limit;
--
2.20.1
^ permalink raw reply related
* Re: [yocto] yocto.io: Add weekly full tests on master branch?
From: Richard Purdie @ 2020-02-14 17:29 UTC (permalink / raw)
To: Randy MacLeod, yocto
In-Reply-To: <15F354349D7F4F79.15837@lists.yoctoproject.org>
On Fri, 2020-02-14 at 17:14 +0000, Richard Purdie via
Lists.Yoctoproject.Org wrote:
> On Fri, 2020-02-14 at 12:08 -0500, Randy MacLeod wrote:
> > Hi,
> >
> > There are many tests run for master-next and reported here:
> > https://autobuilder.yocto.io/pub/non-release/
> > such as:
> >
> > https://autobuilder.yocto.io/pub/non-release/20200214-4/testresults/testresult-report.txt
> >
> > It would be nice to have a weekly or more frequent full test
> > run on the master branch. I suspect that some people know that
> > _certain_ master-next runs end up becoming the master branch
> > content
> > but that's not clear in the summary page.
> >
> > Is that reasonable and possible given the hardware available?
>
> Yes, it just needs someone to spend the time figuring out how to
> replace one of the regular master quick builds with a full build.
FWIW I've tried to enable this and it may work this weekend on Sunday
builds now.
In the process I think other things have now broken so there goes my
Friday evening :/.
Its on the master branch of
http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder2 and I'd give a
link but the git web services are broken atm. I've let Michael know.
Cheers,
Richard
^ permalink raw reply
* [PATCH AUTOSEL 5.4 270/459] drm/mediatek: Add gamma property according to hardware capability
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Yongqiang Niu, Hsin-Yi Wang, CK Hu, Sasha Levin, dri-devel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Yongqiang Niu <yongqiang.niu@mediatek.com>
[ Upstream commit 4cebc1de506fa753301266a5a23bb21bca52ad3a ]
If there is no gamma function in the crtc
display path, don't add gamma property
for crtc
Fixes: 2f3f4dda747c ("drm/mediatek: Add gamma correction.")
Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 0b3d284d19569..e6c049f4f08bb 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -537,6 +537,7 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
int pipe = priv->num_pipes;
int ret;
int i;
+ uint gamma_lut_size = 0;
if (!path)
return 0;
@@ -587,6 +588,9 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
}
mtk_crtc->ddp_comp[i] = comp;
+
+ if (comp->funcs && comp->funcs->gamma_set)
+ gamma_lut_size = MTK_LUT_SIZE;
}
mtk_crtc->layer_nr = mtk_ddp_comp_layer_nr(mtk_crtc->ddp_comp[0]);
@@ -609,8 +613,10 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
NULL, pipe);
if (ret < 0)
return ret;
- drm_mode_crtc_set_gamma_size(&mtk_crtc->base, MTK_LUT_SIZE);
- drm_crtc_enable_color_mgmt(&mtk_crtc->base, 0, false, MTK_LUT_SIZE);
+
+ if (gamma_lut_size)
+ drm_mode_crtc_set_gamma_size(&mtk_crtc->base, gamma_lut_size);
+ drm_crtc_enable_color_mgmt(&mtk_crtc->base, 0, false, gamma_lut_size);
priv->num_pipes++;
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 267/459] ARM: dts: stm32: Add power-supply for DSI panel on stm32f469-disco
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Benjamin Gaignard, Alexandre Torgue, Sasha Levin, linux-stm32,
linux-arm-kernel, devicetree
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Benjamin Gaignard <benjamin.gaignard@st.com>
[ Upstream commit 0ff15a86d0c5a3f004fee2e92d65b88e56a3bc58 ]
Add a fixed regulator and use it as power supply for DSI panel.
Fixes: 18c8866266 ("ARM: dts: stm32: Add display support on stm32f469-disco")
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/stm32f469-disco.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stm32f469-disco.dts b/arch/arm/boot/dts/stm32f469-disco.dts
index a3ff04940aec1..c6dc6d1a051b0 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -76,6 +76,13 @@
regulator-max-microvolt = <3300000>;
};
+ vdd_dsi: vdd-dsi {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_dsi";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
soc {
dma-ranges = <0xc0000000 0x0 0x10000000>;
};
@@ -155,6 +162,7 @@
compatible = "orisetech,otm8009a";
reg = <0>; /* dsi virtual channel (0..3) */
reset-gpios = <&gpioh 7 GPIO_ACTIVE_LOW>;
+ power-supply = <&vdd_dsi>;
status = "okay";
port {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 268/459] usbip: Fix unsafe unaligned pointer usage
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Shuah Khan, Greg Kroah-Hartman, Sasha Levin, linux-usb
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Shuah Khan <skhan@linuxfoundation.org>
[ Upstream commit 585c91f40d201bc564d4e76b83c05b3b5363fe7e ]
Fix unsafe unaligned pointer usage in usbip network interfaces. usbip tool
build fails with new gcc -Werror=address-of-packed-member checks.
usbip_network.c: In function ‘usbip_net_pack_usb_device’:
usbip_network.c:79:32: error: taking address of packed member of ‘struct usbip_usb_device’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
79 | usbip_net_pack_uint32_t(pack, &udev->busnum);
Fix with minor changes to pass by value instead of by address.
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20200109012416.2875-1-skhan@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/usb/usbip/src/usbip_network.c | 40 +++++++++++++++++------------
tools/usb/usbip/src/usbip_network.h | 12 +++------
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/tools/usb/usbip/src/usbip_network.c b/tools/usb/usbip/src/usbip_network.c
index d595d72693fbb..ed4dc8c142690 100644
--- a/tools/usb/usbip/src/usbip_network.c
+++ b/tools/usb/usbip/src/usbip_network.c
@@ -50,39 +50,39 @@ void usbip_setup_port_number(char *arg)
info("using port %d (\"%s\")", usbip_port, usbip_port_string);
}
-void usbip_net_pack_uint32_t(int pack, uint32_t *num)
+uint32_t usbip_net_pack_uint32_t(int pack, uint32_t num)
{
uint32_t i;
if (pack)
- i = htonl(*num);
+ i = htonl(num);
else
- i = ntohl(*num);
+ i = ntohl(num);
- *num = i;
+ return i;
}
-void usbip_net_pack_uint16_t(int pack, uint16_t *num)
+uint16_t usbip_net_pack_uint16_t(int pack, uint16_t num)
{
uint16_t i;
if (pack)
- i = htons(*num);
+ i = htons(num);
else
- i = ntohs(*num);
+ i = ntohs(num);
- *num = i;
+ return i;
}
void usbip_net_pack_usb_device(int pack, struct usbip_usb_device *udev)
{
- usbip_net_pack_uint32_t(pack, &udev->busnum);
- usbip_net_pack_uint32_t(pack, &udev->devnum);
- usbip_net_pack_uint32_t(pack, &udev->speed);
+ udev->busnum = usbip_net_pack_uint32_t(pack, udev->busnum);
+ udev->devnum = usbip_net_pack_uint32_t(pack, udev->devnum);
+ udev->speed = usbip_net_pack_uint32_t(pack, udev->speed);
- usbip_net_pack_uint16_t(pack, &udev->idVendor);
- usbip_net_pack_uint16_t(pack, &udev->idProduct);
- usbip_net_pack_uint16_t(pack, &udev->bcdDevice);
+ udev->idVendor = usbip_net_pack_uint16_t(pack, udev->idVendor);
+ udev->idProduct = usbip_net_pack_uint16_t(pack, udev->idProduct);
+ udev->bcdDevice = usbip_net_pack_uint16_t(pack, udev->bcdDevice);
}
void usbip_net_pack_usb_interface(int pack __attribute__((unused)),
@@ -129,6 +129,14 @@ ssize_t usbip_net_send(int sockfd, void *buff, size_t bufflen)
return usbip_net_xmit(sockfd, buff, bufflen, 1);
}
+static inline void usbip_net_pack_op_common(int pack,
+ struct op_common *op_common)
+{
+ op_common->version = usbip_net_pack_uint16_t(pack, op_common->version);
+ op_common->code = usbip_net_pack_uint16_t(pack, op_common->code);
+ op_common->status = usbip_net_pack_uint32_t(pack, op_common->status);
+}
+
int usbip_net_send_op_common(int sockfd, uint32_t code, uint32_t status)
{
struct op_common op_common;
@@ -140,7 +148,7 @@ int usbip_net_send_op_common(int sockfd, uint32_t code, uint32_t status)
op_common.code = code;
op_common.status = status;
- PACK_OP_COMMON(1, &op_common);
+ usbip_net_pack_op_common(1, &op_common);
rc = usbip_net_send(sockfd, &op_common, sizeof(op_common));
if (rc < 0) {
@@ -164,7 +172,7 @@ int usbip_net_recv_op_common(int sockfd, uint16_t *code, int *status)
goto err;
}
- PACK_OP_COMMON(0, &op_common);
+ usbip_net_pack_op_common(0, &op_common);
if (op_common.version != USBIP_VERSION) {
err("USBIP Kernel and tool version mismatch: %d %d:",
diff --git a/tools/usb/usbip/src/usbip_network.h b/tools/usb/usbip/src/usbip_network.h
index 555215eae43e9..83b4c5344f721 100644
--- a/tools/usb/usbip/src/usbip_network.h
+++ b/tools/usb/usbip/src/usbip_network.h
@@ -32,12 +32,6 @@ struct op_common {
} __attribute__((packed));
-#define PACK_OP_COMMON(pack, op_common) do {\
- usbip_net_pack_uint16_t(pack, &(op_common)->version);\
- usbip_net_pack_uint16_t(pack, &(op_common)->code);\
- usbip_net_pack_uint32_t(pack, &(op_common)->status);\
-} while (0)
-
/* ---------------------------------------------------------------------- */
/* Dummy Code */
#define OP_UNSPEC 0x00
@@ -163,11 +157,11 @@ struct op_devlist_reply_extra {
} while (0)
#define PACK_OP_DEVLIST_REPLY(pack, reply) do {\
- usbip_net_pack_uint32_t(pack, &(reply)->ndev);\
+ (reply)->ndev = usbip_net_pack_uint32_t(pack, (reply)->ndev);\
} while (0)
-void usbip_net_pack_uint32_t(int pack, uint32_t *num);
-void usbip_net_pack_uint16_t(int pack, uint16_t *num);
+uint32_t usbip_net_pack_uint32_t(int pack, uint32_t num);
+uint16_t usbip_net_pack_uint16_t(int pack, uint16_t num);
void usbip_net_pack_usb_device(int pack, struct usbip_usb_device *udev);
void usbip_net_pack_usb_interface(int pack, struct usbip_usb_interface *uinf);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 265/459] crypto: atmel-sha - fix error handling when setting hmac key
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Eric Biggers, Nicolas Ferre, Alexandre Belloni, Ludovic Desroches,
Tudor Ambarus, Herbert Xu, Sasha Levin, linux-crypto,
linux-arm-kernel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Eric Biggers <ebiggers@google.com>
[ Upstream commit b529f1983b2dcc46354f311feda92e07b6e9e2da ]
HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only
fail due to -ENOMEM. But atmel_sha_hmac_setkey() incorrectly treated
any error as a "bad key length" error. Fix it to correctly propagate
the -ENOMEM error code and not set any tfm result flags.
Fixes: 81d8750b2b59 ("crypto: atmel-sha - add support to hmac(shaX)")
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/crypto/atmel-sha.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index d32626458e67c..1f9c16395a3fc 100644
--- a/drivers/crypto/atmel-sha.c
+++ b/drivers/crypto/atmel-sha.c
@@ -1918,12 +1918,7 @@ static int atmel_sha_hmac_setkey(struct crypto_ahash *tfm, const u8 *key,
{
struct atmel_sha_hmac_ctx *hmac = crypto_ahash_ctx(tfm);
- if (atmel_sha_hmac_key_set(&hmac->hkey, key, keylen)) {
- crypto_ahash_set_flags(tfm, CRYPTO_TFM_RES_BAD_KEY_LEN);
- return -EINVAL;
- }
-
- return 0;
+ return atmel_sha_hmac_key_set(&hmac->hkey, key, keylen);
}
static int atmel_sha_hmac_init(struct ahash_request *req)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH RFC] memory: Don't allow to resize RAM while migrating
From: Peter Xu @ 2020-02-14 17:29 UTC (permalink / raw)
To: David Hildenbrand
Cc: Eduardo Habkost, Juan Quintela, Michael S. Tsirkin,
Richard Henderson, qemu-devel, Shameerali Kolothum Thodi,
Dr. David Alan Gilbert, Shannon Zhao, Paolo Bonzini,
Igor Mammedov, Alex Bennée
In-Reply-To: <bb33b209-2b15-4bbd-7fe9-3aa813e4c194@redhat.com>
On Fri, Feb 14, 2020 at 01:02:46PM +0100, David Hildenbrand wrote:
> From c0049ac2e95d6756037db918852c507fb88297d9 Mon Sep 17 00:00:00 2001
> From: David Hildenbrand <david@redhat.com>
> Date: Fri, 14 Feb 2020 13:01:03 +0100
> Subject: [PATCH v1] tmp
>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> migration/migration.c | 9 +++++++--
> migration/migration.h | 1 +
> migration/ram.c | 42 ++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 50 insertions(+), 2 deletions(-)
>
> diff --git a/migration/migration.c b/migration/migration.c
> index 3a21a4686c..0e7efe2920 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -175,13 +175,18 @@ void migration_object_init(void)
> }
> }
>
> +void migration_cancel(void)
> +{
> + migrate_fd_cancel(current_migration);
> +}
> +
> void migration_shutdown(void)
> {
> /*
> * Cancel the current migration - that will (eventually)
> * stop the migration using this structure
> */
> - migrate_fd_cancel(current_migration);
> + migration_cancel();
> object_unref(OBJECT(current_migration));
> }
>
> @@ -2019,7 +2024,7 @@ void qmp_migrate(const char *uri, bool has_blk, bool blk,
>
> void qmp_migrate_cancel(Error **errp)
> {
> - migrate_fd_cancel(migrate_get_current());
> + migration_cancel();
> }
>
> void qmp_migrate_continue(MigrationStatus state, Error **errp)
> diff --git a/migration/migration.h b/migration/migration.h
> index 8473ddfc88..79fd74afa5 100644
> --- a/migration/migration.h
> +++ b/migration/migration.h
> @@ -343,5 +343,6 @@ int foreach_not_ignored_block(RAMBlockIterFunc func, void *opaque);
> void migration_make_urgent_request(void);
> void migration_consume_urgent_request(void);
> bool migration_rate_limit(void);
> +void migration_cancel(void);
>
> #endif
> diff --git a/migration/ram.c b/migration/ram.c
> index ed23ed1c7c..f86f32b453 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -52,6 +52,7 @@
> #include "migration/colo.h"
> #include "block.h"
> #include "sysemu/sysemu.h"
> +#include "sysemu/runstate.h"
> #include "savevm.h"
> #include "qemu/iov.h"
> #include "multifd.h"
> @@ -3710,8 +3711,49 @@ static SaveVMHandlers savevm_ram_handlers = {
> .resume_prepare = ram_resume_prepare,
> };
>
> +static void ram_mig_ram_block_resized(RAMBlockNotifier *n, void *host,
> + size_t old_size, size_t new_size)
> +{
> + /*
> + * We don't care about resizes triggered on incoming migration (when
> + * syncing ram blocks), or of course, when no migration is going on.
> + */
> + if (migration_is_idle() || !runstate_is_running()) {
> + return;
> + }
I feel like migration_is_idle() check is enough. Firstly, I feel like
we allow migration even with VM stopped. At the meantime, if VM is
not running, I see no reason that this resizing will happen after all? :)
> +
> + if (!postcopy_is_running()) {
> + Error *err = NULL;
> +
> + /*
> + * Precopy code cannot deal with the size of ram blocks changing at
> + * random points in time. We're still running on the source, abort
> + * the migration and continue running here. Make sure to wait until
> + * migration was canceled.
> + */
> + error_setg(&err, "RAM resized during precopy.");
> + migrate_set_error(migrate_get_current(), err);
> + error_free(err);
> + migration_cancel();
> + } else {
> + /*
> + * Postcopy code cannot deal with the size of ram blocks changing at
> + * random points in time. We're running on the target. Fail hard.
> + *
> + * TODO: How to handle this in a better way?
> + */
> + error_report("RAM resized during postcopy.");
> + exit(-1);
Now I'm rethinking the postcopy case....
ram_dirty_bitmap_reload() should only happen during the postcopy
recovery, and when that happens the VM should be stopped on both
sides. Which means, ram resizing should not trigger there...
Thanks,
> + }
> +}
> +
> +static RAMBlockNotifier ram_mig_ram_notifier = {
> + .ram_block_resized = ram_mig_ram_block_resized,
> +};
> +
> void ram_mig_init(void)
> {
> qemu_mutex_init(&XBZRLE.lock);
> register_savevm_live("ram", 0, 4, &savevm_ram_handlers, &ram_state);
> + ram_block_notifier_add(&ram_mig_ram_notifier);
> }
> --
> 2.24.1
>
>
> Thoughts?
>
> --
> Thanks,
>
> David / dhildenb
>
>
--
Peter Xu
^ permalink raw reply
* [PATCH AUTOSEL 5.4 263/459] soc: fsl: qe: remove set but not used variable 'mm_gc'
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Chen Zhou, Li Yang, Sasha Levin,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit 6e62bd36e9ad85a22d92b1adce6a0336ea549733 ]
drivers/soc/fsl/qe/gpio.c: In function qe_pin_request:
drivers/soc/fsl/qe/gpio.c:163:26: warning: variable mm_gc set but not used [-Wunused-but-set-variable]
commit 1e714e54b5ca ("powerpc: qe_lib-gpio: use gpiochip data pointer")
left behind this unused variable.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Chen Zhou <chenzhou10@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/fsl/qe/gpio.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/soc/fsl/qe/gpio.c b/drivers/soc/fsl/qe/gpio.c
index f0c29ed8f0ff1..807df73728fc7 100644
--- a/drivers/soc/fsl/qe/gpio.c
+++ b/drivers/soc/fsl/qe/gpio.c
@@ -160,7 +160,6 @@ struct qe_pin *qe_pin_request(struct device_node *np, int index)
{
struct qe_pin *qe_pin;
struct gpio_chip *gc;
- struct of_mm_gpio_chip *mm_gc;
struct qe_gpio_chip *qe_gc;
int err;
unsigned long flags;
@@ -186,7 +185,6 @@ struct qe_pin *qe_pin_request(struct device_node *np, int index)
goto err0;
}
- mm_gc = to_of_mm_gpio_chip(gc);
qe_gc = gpiochip_get_data(gc);
spin_lock_irqsave(&qe_gc->lock, flags);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 225/459] ASoC: Intel: kbl_da7219_max98357a: remove unused variable 'constraints_16000' and 'ch_mono'
From: Sasha Levin @ 2020-02-14 15:57 UTC (permalink / raw)
To: linux-kernel, stable
Cc: YueHaibing, Hulk Robot, Mark Brown, Sasha Levin, alsa-devel
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: YueHaibing <yuehaibing@huawei.com>
[ Upstream commit c5614fb8e3d13be7bba79f71b798468a3a6224f7 ]
sound/soc/intel/boards/kbl_da7219_max98357a.c:343:48:
warning: constraints_16000 defined but not used [-Wunused-const-variable=]
sound/soc/intel/boards/kbl_da7219_max98357a.c:348:27:
warning: ch_mono defined but not used [-Wunused-const-variable=]
They are never used, so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20191224140237.36732-1-yuehaibing@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
sound/soc/intel/boards/kbl_da7219_max98357a.c | 13 -------------
1 file changed, 13 deletions(-)
diff --git a/sound/soc/intel/boards/kbl_da7219_max98357a.c b/sound/soc/intel/boards/kbl_da7219_max98357a.c
index 537a88932bb69..0d55319a0773c 100644
--- a/sound/soc/intel/boards/kbl_da7219_max98357a.c
+++ b/sound/soc/intel/boards/kbl_da7219_max98357a.c
@@ -336,19 +336,6 @@ static struct snd_soc_ops kabylake_dmic_ops = {
.startup = kabylake_dmic_startup,
};
-static const unsigned int rates_16000[] = {
- 16000,
-};
-
-static const struct snd_pcm_hw_constraint_list constraints_16000 = {
- .count = ARRAY_SIZE(rates_16000),
- .list = rates_16000,
-};
-
-static const unsigned int ch_mono[] = {
- 1,
-};
-
SND_SOC_DAILINK_DEF(dummy,
DAILINK_COMP_ARRAY(COMP_DUMMY()));
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 262/459] ARM: dts: meson8b: use the actual frequency for the GPU's 364MHz OPP
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Martin Blumenstingl, Kevin Hilman, Sasha Levin, devicetree,
linux-arm-kernel, linux-amlogic
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[ Upstream commit c3dd3315ab58b2cfa1916df55b0d0f9fbd94266f ]
The clock setup on Meson8 cannot achieve a Mali frequency of exactly
182.15MHz. The vendor driver uses "FCLK_DIV7 / 1" for this frequency,
which translates to 2550MHz / 7 / 1 = 364285714Hz.
Update the GPU operating point to that specific frequency to not confuse
myself when comparing the frequency from the .dts with the actual clock
rate on the system.
Fixes: c3ea80b6138cae ("ARM: dts: meson8b: add the Mali-450 MP2 GPU")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/meson8b.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 099bf8e711c94..1e8c5d7bc824a 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -125,8 +125,8 @@
opp-hz = /bits/ 64 <255000000>;
opp-microvolt = <1100000>;
};
- opp-364300000 {
- opp-hz = /bits/ 64 <364300000>;
+ opp-364285714 {
+ opp-hz = /bits/ 64 <364285714>;
opp-microvolt = <1100000>;
};
opp-425000000 {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 261/459] ARM: dts: meson8: use the actual frequency for the GPU's 182.1MHz OPP
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Martin Blumenstingl, Kevin Hilman, Sasha Levin, devicetree,
linux-arm-kernel, linux-amlogic
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[ Upstream commit fe634a7a9a57fb736e39fb71aa9adc6448a90f94 ]
The clock setup on Meson8 cannot achieve a Mali frequency of exactly
182.15MHz. The vendor driver uses "FCLK_DIV7 / 2" for this frequency,
which translates to 2550MHz / 7 / 2 = 182142857Hz.
Update the GPU operating point to that specific frequency to not confuse
myself when comparing the frequency from the .dts with the actual clock
rate on the system.
Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/meson8.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 3c534cd50ee3b..db2033f674c67 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -129,8 +129,8 @@
gpu_opp_table: gpu-opp-table {
compatible = "operating-points-v2";
- opp-182150000 {
- opp-hz = /bits/ 64 <182150000>;
+ opp-182142857 {
+ opp-hz = /bits/ 64 <182142857>;
opp-microvolt = <1150000>;
};
opp-318750000 {
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 259/459] soc: qcom: rpmhpd: Set 'active_only' for active only power domains
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Douglas Anderson, Rajendra Nayak, Stephen Boyd, Bjorn Andersson,
Sasha Levin, linux-arm-msm
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Douglas Anderson <dianders@chromium.org>
[ Upstream commit 5d0d4d42bed0090d3139e7c5ca1587d76d48add6 ]
The 'active_only' attribute was accidentally never set to true for any
power domains meaning that all the code handling this attribute was
dead.
NOTE that the RPM power domain code (as opposed to the RPMh one) gets
this right.
Acked-by: Rajendra Nayak <rnayak@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20190214173633.211000-1-dianders@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/soc/qcom/rpmhpd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/qcom/rpmhpd.c b/drivers/soc/qcom/rpmhpd.c
index 5741ec3fa814c..51850cc68b701 100644
--- a/drivers/soc/qcom/rpmhpd.c
+++ b/drivers/soc/qcom/rpmhpd.c
@@ -93,6 +93,7 @@ static struct rpmhpd sdm845_mx = {
static struct rpmhpd sdm845_mx_ao = {
.pd = { .name = "mx_ao", },
+ .active_only = true,
.peer = &sdm845_mx,
.res_name = "mx.lvl",
};
@@ -107,6 +108,7 @@ static struct rpmhpd sdm845_cx = {
static struct rpmhpd sdm845_cx_ao = {
.pd = { .name = "cx_ao", },
+ .active_only = true,
.peer = &sdm845_cx,
.parent = &sdm845_mx_ao.pd,
.res_name = "cx.lvl",
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 222/459] iommu/iova: Silence warnings under memory pressure
From: Sasha Levin @ 2020-02-14 15:57 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Qian Cai, Joerg Roedel, Sasha Levin, iommu
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Qian Cai <cai@lca.pw>
[ Upstream commit 944c9175397476199d4dd1028d87ddc582c35ee8 ]
When running heavy memory pressure workloads, this 5+ old system is
throwing endless warnings below because disk IO is too slow to recover
from swapping. Since the volume from alloc_iova_fast() could be large,
once it calls printk(), it will trigger disk IO (writing to the log
files) and pending softirqs which could cause an infinite loop and make
no progress for days by the ongoimng memory reclaim. This is the counter
part for Intel where the AMD part has already been merged. See the
commit 3d708895325b ("iommu/amd: Silence warnings under memory
pressure"). Since the allocation failure will be reported in
intel_alloc_iova(), so just call dev_err_once() there because even the
"ratelimited" is too much, and silence the one in alloc_iova_mem() to
avoid the expensive warn_alloc().
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
slab_out_of_memory: 66 callbacks suppressed
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
cache: iommu_iova, object size: 40, buffer size: 448, default order:
0, min order: 0
node 0: slabs: 1822, objs: 16398, free: 0
node 1: slabs: 2051, objs: 18459, free: 31
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
cache: iommu_iova, object size: 40, buffer size: 448, default order:
0, min order: 0
node 0: slabs: 1822, objs: 16398, free: 0
node 1: slabs: 2051, objs: 18459, free: 31
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
cache: iommu_iova, object size: 40, buffer size: 448, default order:
0, min order: 0
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
node 0: slabs: 697, objs: 4182, free: 0
node 0: slabs: 697, objs: 4182, free: 0
node 0: slabs: 697, objs: 4182, free: 0
node 0: slabs: 697, objs: 4182, free: 0
node 1: slabs: 381, objs: 2286, free: 27
node 1: slabs: 381, objs: 2286, free: 27
node 1: slabs: 381, objs: 2286, free: 27
node 1: slabs: 381, objs: 2286, free: 27
node 0: slabs: 1822, objs: 16398, free: 0
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
node 1: slabs: 2051, objs: 18459, free: 31
node 0: slabs: 697, objs: 4182, free: 0
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
node 1: slabs: 381, objs: 2286, free: 27
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
node 0: slabs: 697, objs: 4182, free: 0
node 1: slabs: 381, objs: 2286, free: 27
hpsa 0000:03:00.0: DMAR: Allocating 1-page iova failed
warn_alloc: 96 callbacks suppressed
kworker/11:1H: page allocation failure: order:0,
mode:0xa20(GFP_ATOMIC), nodemask=(null),cpuset=/,mems_allowed=0-1
CPU: 11 PID: 1642 Comm: kworker/11:1H Tainted: G B
Hardware name: HP ProLiant XL420 Gen9/ProLiant XL420 Gen9, BIOS U19
12/27/2015
Workqueue: kblockd blk_mq_run_work_fn
Call Trace:
dump_stack+0xa0/0xea
warn_alloc.cold.94+0x8a/0x12d
__alloc_pages_slowpath+0x1750/0x1870
__alloc_pages_nodemask+0x58a/0x710
alloc_pages_current+0x9c/0x110
alloc_slab_page+0xc9/0x760
allocate_slab+0x48f/0x5d0
new_slab+0x46/0x70
___slab_alloc+0x4ab/0x7b0
__slab_alloc+0x43/0x70
kmem_cache_alloc+0x2dd/0x450
SLUB: Unable to allocate memory on node -1, gfp=0xa20(GFP_ATOMIC)
alloc_iova+0x33/0x210
cache: skbuff_head_cache, object size: 208, buffer size: 640, default
order: 0, min order: 0
node 0: slabs: 697, objs: 4182, free: 0
alloc_iova_fast+0x62/0x3d1
node 1: slabs: 381, objs: 2286, free: 27
intel_alloc_iova+0xce/0xe0
intel_map_sg+0xed/0x410
scsi_dma_map+0xd7/0x160
scsi_queue_rq+0xbf7/0x1310
blk_mq_dispatch_rq_list+0x4d9/0xbc0
blk_mq_sched_dispatch_requests+0x24a/0x300
__blk_mq_run_hw_queue+0x156/0x230
blk_mq_run_work_fn+0x3b/0x40
process_one_work+0x579/0xb90
worker_thread+0x63/0x5b0
kthread+0x1e6/0x210
ret_from_fork+0x3a/0x50
Mem-Info:
active_anon:2422723 inactive_anon:361971 isolated_anon:34403
active_file:2285 inactive_file:1838 isolated_file:0
unevictable:0 dirty:1 writeback:5 unstable:0
slab_reclaimable:13972 slab_unreclaimable:453879
mapped:2380 shmem:154 pagetables:6948 bounce:0
free:19133 free_pcp:7363 free_cma:0
Signed-off-by: Qian Cai <cai@lca.pw>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/iommu/intel-iommu.c | 3 ++-
drivers/iommu/iova.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index dd5db856dcaf9..760a242d0801d 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -3401,7 +3401,8 @@ static unsigned long intel_alloc_iova(struct device *dev,
iova_pfn = alloc_iova_fast(&domain->iovad, nrpages,
IOVA_PFN(dma_mask), true);
if (unlikely(!iova_pfn)) {
- dev_err(dev, "Allocating %ld-page iova failed", nrpages);
+ dev_err_once(dev, "Allocating %ld-page iova failed\n",
+ nrpages);
return 0;
}
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index c7a914b9bbbc4..0e6a9536eca62 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -233,7 +233,7 @@ static DEFINE_MUTEX(iova_cache_mutex);
struct iova *alloc_iova_mem(void)
{
- return kmem_cache_zalloc(iova_cache, GFP_ATOMIC);
+ return kmem_cache_zalloc(iova_cache, GFP_ATOMIC | __GFP_NOWARN);
}
EXPORT_SYMBOL(alloc_iova_mem);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 5.4 257/459] RDMA/hns: Avoid printing address of mtt page
From: Sasha Levin @ 2020-02-14 15:58 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Wenpeng Liang, Weihang Li, Jason Gunthorpe, Sasha Levin,
linux-rdma
In-Reply-To: <20200214160149.11681-1-sashal@kernel.org>
From: Wenpeng Liang <liangwenpeng@huawei.com>
[ Upstream commit eca44507c3e908b7362696a4d6a11d90371334c6 ]
Address of a page shouldn't be printed in case of security issues.
Link: https://lore.kernel.org/r/1578313276-29080-2-git-send-email-liweihang@huawei.com
Signed-off-by: Wenpeng Liang <liangwenpeng@huawei.com>
Signed-off-by: Weihang Li <liweihang@huawei.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/infiniband/hw/hns/hns_roce_mr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hns/hns_roce_mr.c b/drivers/infiniband/hw/hns/hns_roce_mr.c
index 5f8416ba09a94..702b59f0dab91 100644
--- a/drivers/infiniband/hw/hns/hns_roce_mr.c
+++ b/drivers/infiniband/hw/hns/hns_roce_mr.c
@@ -1062,8 +1062,8 @@ int hns_roce_ib_umem_write_mtt(struct hns_roce_dev *hr_dev,
if (!(npage % (1 << (mtt->page_shift - PAGE_SHIFT)))) {
if (page_addr & ((1 << mtt->page_shift) - 1)) {
dev_err(dev,
- "page_addr 0x%llx is not page_shift %d alignment!\n",
- page_addr, mtt->page_shift);
+ "page_addr is not page_shift %d alignment!\n",
+ mtt->page_shift);
ret = -EINVAL;
goto out;
}
--
2.20.1
^ permalink raw reply related
* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Implement Wa_1606931601 (rev5)
From: Patchwork @ 2020-02-14 17:30 UTC (permalink / raw)
To: Anusha Srivatsa; +Cc: intel-gfx
In-Reply-To: <20200211234404.1728-1-anusha.srivatsa@intel.com>
== Series Details ==
Series: drm/i915/tgl: Implement Wa_1606931601 (rev5)
URL : https://patchwork.freedesktop.org/series/72433/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7922_full -> Patchwork_16530_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_16530_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_balancer@smoke:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110854])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@gem_exec_balancer@smoke.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb6/igt@gem_exec_balancer@smoke.html
* igt@gem_exec_schedule@pi-distinct-iova-bsd:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#677]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb6/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb1/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112146]) +7 similar issues
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb6/igt@gem_exec_schedule@preempt-other-chain-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb1/igt@gem_exec_schedule@preempt-other-chain-bsd.html
* igt@gen7_exec_parse@basic-offset:
- shard-hsw: [PASS][7] -> [FAIL][8] ([i915#694])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw2/igt@gen7_exec_parse@basic-offset.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw2/igt@gen7_exec_parse@basic-offset.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#79])
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#79])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl4/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl3/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([i915#180]) +1 similar issue
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-kbl7/igt@kms_flip@flip-vs-suspend-interruptible.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-kbl1/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_flip@flip-vs-wf_vblank-interruptible:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#34])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl5/igt@kms_flip@flip-vs-wf_vblank-interruptible.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl5/igt@kms_flip@flip-vs-wf_vblank-interruptible.html
* igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite:
- shard-glk: [PASS][17] -> [FAIL][18] ([i915#49])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk6/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk1/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-pwrite.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +5 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-apl3/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-apl6/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [i915#265])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl9/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl8/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_plane_lowres@pipe-a-tiling-x:
- shard-glk: [PASS][25] -> [FAIL][26] ([i915#899])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk6/igt@kms_plane_lowres@pipe-a-tiling-x.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk1/igt@kms_plane_lowres@pipe-a-tiling-x.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][27] -> [SKIP][28] ([fdo#109441]) +4 similar issues
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb4/igt@kms_psr@psr2_primary_page_flip.html
* igt@perf_pmu@busy-no-semaphores-vcs1:
- shard-iclb: [PASS][29] -> [SKIP][30] ([fdo#112080]) +13 similar issues
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb4/igt@perf_pmu@busy-no-semaphores-vcs1.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb5/igt@perf_pmu@busy-no-semaphores-vcs1.html
* igt@prime_busy@hang-bsd2:
- shard-iclb: [PASS][31] -> [SKIP][32] ([fdo#109276]) +19 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb1/igt@prime_busy@hang-bsd2.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb5/igt@prime_busy@hang-bsd2.html
#### Possible fixes ####
* igt@gem_ctx_isolation@bcs0-s3:
- shard-apl: [DMESG-WARN][33] ([i915#180]) -> [PASS][34] +4 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-apl8/igt@gem_ctx_isolation@bcs0-s3.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-apl2/igt@gem_ctx_isolation@bcs0-s3.html
* {igt@gem_ctx_persistence@engines-mixed-process@bcs0}:
- shard-skl: [FAIL][35] ([i915#679]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl7/igt@gem_ctx_persistence@engines-mixed-process@bcs0.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl6/igt@gem_ctx_persistence@engines-mixed-process@bcs0.html
* {igt@gem_ctx_persistence@engines-mixed-process@vcs0}:
- shard-skl: [INCOMPLETE][37] -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl7/igt@gem_ctx_persistence@engines-mixed-process@vcs0.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl6/igt@gem_ctx_persistence@engines-mixed-process@vcs0.html
* igt@gem_exec_balancer@hang:
- shard-tglb: [TIMEOUT][39] ([fdo#112271]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-tglb3/igt@gem_exec_balancer@hang.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-tglb3/igt@gem_exec_balancer@hang.html
* igt@gem_exec_schedule@pi-common-bsd:
- shard-iclb: [SKIP][41] ([i915#677]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb1/igt@gem_exec_schedule@pi-common-bsd.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb3/igt@gem_exec_schedule@pi-common-bsd.html
* igt@gem_exec_schedule@preemptive-hang-bsd:
- shard-iclb: [SKIP][43] ([fdo#112146]) -> [PASS][44] +8 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb7/igt@gem_exec_schedule@preemptive-hang-bsd.html
* igt@gen7_exec_parse@basic-allocation:
- shard-hsw: [FAIL][45] ([i915#694]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw6/igt@gen7_exec_parse@basic-allocation.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw5/igt@gen7_exec_parse@basic-allocation.html
* igt@i915_pm_dc@dc5-dpms:
- shard-iclb: [FAIL][47] ([i915#447]) -> [PASS][48]
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb3/igt@i915_pm_dc@dc5-dpms.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb1/igt@i915_pm_dc@dc5-dpms.html
* igt@i915_pm_dc@dc5-psr:
- shard-tglb: [SKIP][49] ([i915#668]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-tglb1/igt@i915_pm_dc@dc5-psr.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-tglb8/igt@i915_pm_dc@dc5-psr.html
* igt@i915_pm_dc@dc6-dpms:
- shard-iclb: [FAIL][51] ([i915#454]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb2/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- shard-glk: [DMESG-WARN][53] ([i915#118] / [i915#95]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-glk8/igt@i915_pm_rpm@modeset-stress-extra-wait.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-glk6/igt@i915_pm_rpm@modeset-stress-extra-wait.html
* igt@i915_selftest@live_workarounds:
- shard-tglb: [DMESG-FAIL][55] ([i915#1169]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-tglb3/igt@i915_selftest@live_workarounds.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-tglb1/igt@i915_selftest@live_workarounds.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [DMESG-WARN][57] ([i915#180]) -> [PASS][58] +2 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-kbl4/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-kbl1/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding:
- shard-skl: [FAIL][59] ([i915#54]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl2/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl1/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
* igt@kms_fbcon_fbt@psr-suspend:
- shard-skl: [INCOMPLETE][61] ([i915#69]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-skl3/igt@kms_fbcon_fbt@psr-suspend.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-skl6/igt@kms_fbcon_fbt@psr-suspend.html
* igt@kms_psr@psr2_sprite_blt:
- shard-iclb: [SKIP][63] ([fdo#109441]) -> [PASS][64] +2 similar issues
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb3/igt@kms_psr@psr2_sprite_blt.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
* igt@perf_pmu@busy-vcs1:
- shard-iclb: [SKIP][65] ([fdo#112080]) -> [PASS][66] +18 similar issues
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb8/igt@perf_pmu@busy-vcs1.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb4/igt@perf_pmu@busy-vcs1.html
* igt@prime_mmap_coherency@ioctl-errors:
- shard-hsw: [FAIL][67] ([i915#831]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw7/igt@prime_mmap_coherency@ioctl-errors.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw6/igt@prime_mmap_coherency@ioctl-errors.html
* igt@prime_vgem@fence-wait-bsd2:
- shard-iclb: [SKIP][69] ([fdo#109276]) -> [PASS][70] +24 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb3/igt@prime_vgem@fence-wait-bsd2.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb2/igt@prime_vgem@fence-wait-bsd2.html
* igt@prime_vgem@sync-blt:
- shard-tglb: [INCOMPLETE][71] ([i915#409]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-tglb1/igt@prime_vgem@sync-blt.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-tglb8/igt@prime_vgem@sync-blt.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [FAIL][73] ([IGT#28]) -> [SKIP][74] ([fdo#112080])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb4/igt@gem_ctx_isolation@vcs1-nonpriv.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb5/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_tiled_blits@normal:
- shard-hsw: [FAIL][75] ([i915#818]) -> [FAIL][76] ([i915#694])
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-hsw7/igt@gem_tiled_blits@normal.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-hsw1/igt@gem_tiled_blits@normal.html
* igt@i915_pm_rpm@sysfs-read:
- shard-snb: [INCOMPLETE][77] ([i915#82]) -> [SKIP][78] ([fdo#109271])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-snb6/igt@i915_pm_rpm@sysfs-read.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-snb6/igt@i915_pm_rpm@sysfs-read.html
* igt@kms_dp_dsc@basic-dsc-enable-edp:
- shard-iclb: [DMESG-WARN][79] ([i915#1226]) -> [SKIP][80] ([fdo#109349])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7922/shard-iclb2/igt@kms_dp_dsc@basic-dsc-enable-edp.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/shard-iclb4/igt@kms_dp_dsc@basic-dsc-enable-edp.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109349]: https://bugs.freedesktop.org/show_bug.cgi?id=109349
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[i915#1169]: https://gitlab.freedesktop.org/drm/intel/issues/1169
[i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1226]: https://gitlab.freedesktop.org/drm/intel/issues/1226
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
[i915#409]: https://gitlab.freedesktop.org/drm/intel/issues/409
[i915#447]: https://gitlab.freedesktop.org/drm/intel/issues/447
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#82]: https://gitlab.freedesktop.org/drm/intel/issues/82
[i915#831]: https://gitlab.freedesktop.org/drm/intel/issues/831
[i915#899]: https://gitlab.freedesktop.org/drm/intel/issues/899
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7922 -> Patchwork_16530
CI-20190529: 20190529
CI_DRM_7922: 0367f4b85f1fbbb1f0df1064803c97d35ed53f24 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5436: 00a64098aaae2ac3154841d76c7b034165380282 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16530: fc2fdf6349df81db142615b3c34cd20aa320e7c5 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16530/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.