* Re: [PATCH] btrfs: Add comment for BTRFS_ROOT_REF_COWS
From: David Sterba @ 2020-02-14 16:53 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
In-Reply-To: <20200212074651.33008-1-wqu@suse.com>
On Wed, Feb 12, 2020 at 03:46:51PM +0800, Qu Wenruo wrote:
> This bit is being used in too many locations while there is still no
> good enough explaination for how this bit is used.
>
> Not to mention its name really doesn't make much sense.
>
> So this patch will add my explanation on this bit, considering only
> subvolume trees, along with its reloc trees have this bit, to me it
> looks like this bit shows whether tree blocks of a root can be shared.
I think there's more tan just sharing, it should say something about
reference counted sharing. See eg. btrfs_block_can_be_shared:
864 /*
865 * Tree blocks not in reference counted trees and tree roots
866 * are never shared. If a block was allocated after the last
867 * snapshot and the block was not allocated by tree relocation,
868 * we know the block is not shared.
869 */
And there can be more specialities found when grepping for REF_COWS. The
comment explaination should be complete or at least mention what's not
documenting. The I find the suggested version insufficient but don't
have a concrete suggestions for improvement. By reading the comment and
going through code I don't feel any wiser.
^ permalink raw reply
* [PATCH AUTOSEL 4.14 078/186] b43legacy: Fix -Wcast-function-type
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Phong Tran, Larry Finger, Kees Cook, Kalle Valo, Sasha Levin,
linux-wireless, b43-dev, netdev
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Phong Tran <tranmanphong@gmail.com>
[ Upstream commit 475eec112e4267232d10f4afe2f939a241692b6c ]
correct usage prototype of callback in tasklet_init().
Report by https://github.com/KSPP/linux/issues/20
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wireless/broadcom/b43legacy/main.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c b/drivers/net/wireless/broadcom/b43legacy/main.c
index f1e3dad576292..f435bd0f8b5b5 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -1304,8 +1304,9 @@ static void handle_irq_ucode_debug(struct b43legacy_wldev *dev)
}
/* Interrupt handler bottom-half */
-static void b43legacy_interrupt_tasklet(struct b43legacy_wldev *dev)
+static void b43legacy_interrupt_tasklet(unsigned long data)
{
+ struct b43legacy_wldev *dev = (struct b43legacy_wldev *)data;
u32 reason;
u32 dma_reason[ARRAY_SIZE(dev->dma_reason)];
u32 merged_dma_reason = 0;
@@ -3775,7 +3776,7 @@ static int b43legacy_one_core_attach(struct ssb_device *dev,
b43legacy_set_status(wldev, B43legacy_STAT_UNINIT);
wldev->bad_frames_preempt = modparam_bad_frames_preempt;
tasklet_init(&wldev->isr_tasklet,
- (void (*)(unsigned long))b43legacy_interrupt_tasklet,
+ b43legacy_interrupt_tasklet,
(unsigned long)wldev);
if (modparam_pio)
wldev->__using_pio = true;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 024/141] scsi: ufs: Fix ufshcd_probe_hba() reture value in case ufshcd_scsi_add_wlus() fails
From: Sasha Levin @ 2020-02-14 16:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, linux-scsi, Martin K . Petersen, linux-mediatek,
Alim Akhtar, Bean Huo, Stanley Chu, linux-arm-kernel, Asutosh Das
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: Bean Huo <beanhuo@micron.com>
[ Upstream commit b9fc5320212efdfb4e08b825aaa007815fd11d16 ]
A non-zero error value likely being returned by ufshcd_scsi_add_wlus() in
case of failure of adding the WLs, but ufshcd_probe_hba() doesn't use this
value, and doesn't report this failure to upper caller. This patch is to
fix this issue.
Fixes: 2a8fa600445c ("ufs: manually add well known logical units")
Link: https://lore.kernel.org/r/20200120130820.1737-2-huobean@gmail.com
Reviewed-by: Asutosh Das <asutoshd@codeaurora.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Bean Huo <beanhuo@micron.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/scsi/ufs/ufshcd.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 094e879af1213..394df57894e6b 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5347,7 +5347,8 @@ static int ufshcd_probe_hba(struct ufs_hba *hba)
ufshcd_init_icc_levels(hba);
/* Add required well known logical units to scsi mid layer */
- if (ufshcd_scsi_add_wlus(hba))
+ ret = ufshcd_scsi_add_wlus(hba);
+ if (ret)
goto out;
scsi_scan_host(hba->host);
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 075/186] isdn: don't mark kcapi_proc_exit as __exit
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Arnd Bergmann, kbuild test robot, kernelci . org bot,
Olof's autobuilder, Stephen Rothwell, Greg Kroah-Hartman,
Sasha Levin, netdev
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Arnd Bergmann <arnd@arndb.de>
[ Upstream commit b33bdf8020c94438269becc6dace9ed49257c4ba ]
As everybody pointed out by now, my patch to clean up CAPI introduced
a link time warning, as the two parts of the capi driver are now in
one module and the exit function may need to be called in the error
path of the init function:
>> WARNING: drivers/isdn/capi/kernelcapi.o(.text+0xea4): Section mismatch in reference from the function kcapi_exit() to the function .exit.text:kcapi_proc_exit()
The function kcapi_exit() references a function in an exit section.
Often the function kcapi_proc_exit() has valid usage outside the exit section
and the fix is to remove the __exit annotation of kcapi_proc_exit.
Remove the incorrect __exit annotation.
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: kernelci.org bot <bot@kernelci.org>
Reported-by: Olof's autobuilder <build@lixom.net>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20191216194909.1983639-1-arnd@arndb.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/isdn/capi/kcapi_proc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/isdn/capi/kcapi_proc.c b/drivers/isdn/capi/kcapi_proc.c
index 68db3c5a10636..d6ca626219c93 100644
--- a/drivers/isdn/capi/kcapi_proc.c
+++ b/drivers/isdn/capi/kcapi_proc.c
@@ -309,7 +309,7 @@ kcapi_proc_init(void)
proc_create("capi/driver", 0, NULL, &proc_driver_ops);
}
-void __exit
+void
kcapi_proc_exit(void)
{
remove_proc_entry("capi/driver", NULL);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 052/141] arm: dts: allwinner: H3: Add PMU node
From: Sasha Levin @ 2020-02-14 16:19 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Andre Przywara, Maxime Ripard, linux-arm-kernel,
devicetree
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: Andre Przywara <andre.przywara@arm.com>
[ Upstream commit 0388a110747bec0c9d9de995842bb2a03a26aae1 ]
Add the Performance Monitoring Unit (PMU) device tree node to the H3
.dtsi, which tells DT users which interrupts are triggered by PMU
overflow events on each core. The numbers come from the manual and have
been checked in U-Boot and with perf in Linux.
Tested with perf record and taskset on an OrangePi Zero.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/boot/dts/sun8i-h3.dtsi | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index f4ba088b225ed..08d65f252e172 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -60,25 +60,34 @@
reg = <0>;
};
- cpu@1 {
+ cpu1: cpu@1 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <1>;
};
- cpu@2 {
+ cpu2: cpu@2 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <2>;
};
- cpu@3 {
+ cpu3: cpu@3 {
compatible = "arm,cortex-a7";
device_type = "cpu";
reg = <3>;
};
};
+ pmu {
+ compatible = "arm,cortex-a7-pmu";
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
+ };
+
timer {
compatible = "arm,armv7-timer";
interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW)>,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 037/186] tracing: Fix very unlikely race of registering two stat tracers
From: Sasha Levin @ 2020-02-14 16:14 UTC (permalink / raw)
To: linux-kernel, stable; +Cc: Steven Rostedt (VMware), Luis Henriques, Sasha Levin
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
[ Upstream commit dfb6cd1e654315168e36d947471bd2a0ccd834ae ]
Looking through old emails in my INBOX, I came across a patch from Luis
Henriques that attempted to fix a race of two stat tracers registering the
same stat trace (extremely unlikely, as this is done in the kernel, and
probably doesn't even exist). The submitted patch wasn't quite right as it
needed to deal with clean up a bit better (if two stat tracers were the
same, it would have the same files).
But to make the code cleaner, all we needed to do is to keep the
all_stat_sessions_mutex held for most of the registering function.
Link: http://lkml.kernel.org/r/1410299375-20068-1-git-send-email-luis.henriques@canonical.com
Fixes: 002bb86d8d42f ("tracing/ftrace: separate events tracing and stats tracing engine")
Reported-by: Luis Henriques <luis.henriques@canonical.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/trace/trace_stat.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/kernel/trace/trace_stat.c b/kernel/trace/trace_stat.c
index bf68af63538b4..92b76f9e25edd 100644
--- a/kernel/trace/trace_stat.c
+++ b/kernel/trace/trace_stat.c
@@ -306,7 +306,7 @@ static int init_stat_file(struct stat_session *session)
int register_stat_tracer(struct tracer_stat *trace)
{
struct stat_session *session, *node;
- int ret;
+ int ret = -EINVAL;
if (!trace)
return -EINVAL;
@@ -317,17 +317,15 @@ int register_stat_tracer(struct tracer_stat *trace)
/* Already registered? */
mutex_lock(&all_stat_sessions_mutex);
list_for_each_entry(node, &all_stat_sessions, session_list) {
- if (node->ts == trace) {
- mutex_unlock(&all_stat_sessions_mutex);
- return -EINVAL;
- }
+ if (node->ts == trace)
+ goto out;
}
- mutex_unlock(&all_stat_sessions_mutex);
+ ret = -ENOMEM;
/* Init the session */
session = kzalloc(sizeof(*session), GFP_KERNEL);
if (!session)
- return -ENOMEM;
+ goto out;
session->ts = trace;
INIT_LIST_HEAD(&session->session_list);
@@ -336,15 +334,16 @@ int register_stat_tracer(struct tracer_stat *trace)
ret = init_stat_file(session);
if (ret) {
destroy_session(session);
- return ret;
+ goto out;
}
+ ret = 0;
/* Register */
- mutex_lock(&all_stat_sessions_mutex);
list_add_tail(&session->session_list, &all_stat_sessions);
+ out:
mutex_unlock(&all_stat_sessions_mutex);
- return 0;
+ return ret;
}
void unregister_stat_tracer(struct tracer_stat *trace)
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 069/186] padata: always acquire cpu_hotplug_lock before pinst->lock
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Daniel Jordan, Eric Biggers, Herbert Xu, Steffen Klassert,
linux-crypto, Sasha Levin
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Daniel Jordan <daniel.m.jordan@oracle.com>
[ Upstream commit 38228e8848cd7dd86ccb90406af32de0cad24be3 ]
lockdep complains when padata's paths to update cpumasks via CPU hotplug
and sysfs are both taken:
# echo 0 > /sys/devices/system/cpu/cpu1/online
# echo ff > /sys/kernel/pcrypt/pencrypt/parallel_cpumask
======================================================
WARNING: possible circular locking dependency detected
5.4.0-rc8-padata-cpuhp-v3+ #1 Not tainted
------------------------------------------------------
bash/205 is trying to acquire lock:
ffffffff8286bcd0 (cpu_hotplug_lock.rw_sem){++++}, at: padata_set_cpumask+0x2b/0x120
but task is already holding lock:
ffff8880001abfa0 (&pinst->lock){+.+.}, at: padata_set_cpumask+0x26/0x120
which lock already depends on the new lock.
padata doesn't take cpu_hotplug_lock and pinst->lock in a consistent
order. Which should be first? CPU hotplug calls into padata with
cpu_hotplug_lock already held, so it should have priority.
Fixes: 6751fb3c0e0c ("padata: Use get_online_cpus/put_online_cpus")
Signed-off-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/padata.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/padata.c b/kernel/padata.c
index 87540ce72aea6..40aea129a76d9 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -626,8 +626,8 @@ int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type,
struct cpumask *serial_mask, *parallel_mask;
int err = -EINVAL;
- mutex_lock(&pinst->lock);
get_online_cpus();
+ mutex_lock(&pinst->lock);
switch (cpumask_type) {
case PADATA_CPU_PARALLEL:
@@ -645,8 +645,8 @@ int padata_set_cpumask(struct padata_instance *pinst, int cpumask_type,
err = __padata_set_cpumasks(pinst, parallel_mask, serial_mask);
out:
- put_online_cpus();
mutex_unlock(&pinst->lock);
+ put_online_cpus();
return err;
}
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 067/186] tty: omap-serial: remove set but unused variable
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Xiongfeng Wang, Hulk Robot, Greg Kroah-Hartman, Sasha Levin,
linux-serial
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Xiongfeng Wang <wangxiongfeng2@huawei.com>
[ Upstream commit e83c6587c47caa2278aa3bd603b5a85eddc4cec9 ]
Fix the following warning:
drivers/tty/serial/omap-serial.c: In function serial_omap_rlsi:
drivers/tty/serial/omap-serial.c:496:16: warning: variable ch set but not used [-Wunused-but-set-variable]
The character read is useless according to the table 23-246 of the omap4
TRM. So we can drop it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Link: https://lore.kernel.org/r/1575617863-32484-1-git-send-email-wangxiongfeng2@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/omap-serial.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 26a22b100df10..517f984c89128 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -497,10 +497,13 @@ static unsigned int check_modem_status(struct uart_omap_port *up)
static void serial_omap_rlsi(struct uart_omap_port *up, unsigned int lsr)
{
unsigned int flag;
- unsigned char ch = 0;
+ /*
+ * Read one data character out to avoid stalling the receiver according
+ * to the table 23-246 of the omap4 TRM.
+ */
if (likely(lsr & UART_LSR_DR))
- ch = serial_in(up, UART_RX);
+ serial_in(up, UART_RX);
up->port.icount.rx++;
flag = TTY_NORMAL;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 068/186] arm64: dts: qcom: msm8996: Disable USB2 PHY suspend by core
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Manu Gautam, Paolo Pisati, Bjorn Andersson, Sasha Levin,
linux-arm-msm, devicetree
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Manu Gautam <mgautam@codeaurora.org>
[ Upstream commit d026c96b25b7ce5df89526aad2df988d553edb4d ]
QUSB2 PHY on msm8996 doesn't work well when autosuspend by
dwc3 core using USB2PHYCFG register is enabled. One of the
issue seen is that PHY driver reports PLL lock failure and
fails phy_init() if dwc3 core has USB2 PHY suspend enabled.
Fix this by using quirks to disable USB2 PHY LPM/suspend and
dwc3 core already takes care of explicitly suspending PHY
during suspend if quirks are specified.
Signed-off-by: Manu Gautam <mgautam@codeaurora.org>
Signed-off-by: Paolo Pisati <p.pisati@gmail.com>
Link: https://lore.kernel.org/r/20191209151501.26993-1-p.pisati@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 6f372ec055dd3..da2949586c7a3 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -788,6 +788,8 @@
interrupts = <0 138 0>;
phys = <&hsusb_phy2>;
phy-names = "usb2-phy";
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
};
};
@@ -817,6 +819,8 @@
interrupts = <0 131 0>;
phys = <&hsusb_phy1>, <&ssusb_phy_0>;
phy-names = "usb2-phy", "usb3-phy";
+ snps,dis_u2_susphy_quirk;
+ snps,dis_enblslpm_quirk;
};
};
};
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 060/141] Revert "tty/serial: atmel: fix out of range clock divider handling"
From: Sasha Levin @ 2020-02-14 16:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Stephen Rothwell, Greg Kroah-Hartman, linux-serial,
David Engraf, linux-arm-kernel
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 6dbd54e4154dfe386b3333687de15be239576617 ]
This reverts commit 751d0017334db9c4d68a8909c59f662a6ecbcec6.
The wrong commit got added to the tty-next tree, the correct one is in
the tty-linus branch.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: David Engraf <david.engraf@sysgo.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/tty/serial/atmel_serial.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
index 325f9db2da86c..255be61b4073a 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -2200,6 +2200,9 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
mode |= ATMEL_US_USMODE_NORMAL;
}
+ /* set the mode, clock divisor, parity, stop bits and data size */
+ atmel_uart_writel(port, ATMEL_US_MR, mode);
+
/*
* Set the baud rate:
* Fractional baudrate allows to setup output frequency more
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 063/186] net/wan/fsl_ucc_hdlc: reject muram offsets above 64K
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Rasmus Villemoes, Qiang Zhao, Timur Tabi, David S . Miller,
Li Yang, Sasha Levin, netdev, linuxppc-dev
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Rasmus Villemoes <linux@rasmusvillemoes.dk>
[ Upstream commit 148587a59f6b85831695e0497d9dd1af5f0495af ]
Qiang Zhao points out that these offsets get written to 16-bit
registers, and there are some QE platforms with more than 64K
muram. So it is possible that qe_muram_alloc() gives us an allocation
that can't actually be used by the hardware, so detect and reject
that.
Reported-by: Qiang Zhao <qiang.zhao@nxp.com>
Reviewed-by: Timur Tabi <timur@kernel.org>
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Acked-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/wan/fsl_ucc_hdlc.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 571a1ff8f81f2..6a26cef621935 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -240,6 +240,11 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
ret = -ENOMEM;
goto free_riptr;
}
+ if (riptr != (u16)riptr || tiptr != (u16)tiptr) {
+ dev_err(priv->dev, "MURAM allocation out of addressable range\n");
+ ret = -ENOMEM;
+ goto free_tiptr;
+ }
/* Set RIPTR, TIPTR */
iowrite16be(riptr, &priv->ucc_pram->riptr);
--
2.20.1
^ permalink raw reply related
* Re: [ISSUE] The time cost of IOSQE_IO_LINK
From: Jens Axboe @ 2020-02-14 16:18 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Carter Li 李通洲, Pavel Begunkov, io-uring
In-Reply-To: <5995f84e-8a6c-e774-6bb5-5b9b87a9cd3c@kernel.dk>
On 2/14/20 8:47 AM, Jens Axboe wrote:
>> I suspect you meant to put that in finish_task_switch() which is the
>> tail end of every schedule(), schedule_tail() is the tail end of
>> clone().
>>
>> Or maybe you meant to put it in (and rename) sched_update_worker() which
>> is after every schedule() but in a preemptible context -- much saner
>> since you don't want to go add an unbounded amount of work in a
>> non-preemptible context.
>>
>> At which point you already have your callback: io_wq_worker_running(),
>> or is this for any random task?
>
> Let me try and clarify - this isn't for the worker tasks, this is for
> any task that is using io_uring. In fact, it's particularly not for the
> worker threads, just the task itself.
>
> I basically want the handler to be called when:
>
> 1) The task is scheduled in. The poll will complete and stuff some items
> on that task list, and I want to task to process them as it wakes up.
>
> 2) The task is going to sleep, don't want to leave entries around while
> the task is sleeping.
>
> 3) I need it to be called from "normal" context, with ints enabled,
> preempt enabled, etc.
>
> sched_update_worker() (with a rename) looks ideal for #1, and the
> context is sane for me. Just need a good spot to put the hook call for
> schedule out. I think this:
>
> if (tsk->flags & (PF_WQ_WORKER | PF_IO_WORKER)) {
> preempt_disable();
> if (tsk->flags & PF_WQ_WORKER)
> wq_worker_sleeping(tsk);
> else
> io_wq_worker_sleeping(tsk);
> preempt_enable_no_resched();
> }
>
> just needs to go into another helper, and then I can call it there
> outside of the preempt.
>
> I'm sure there are daemons lurking here, but I'll test and see how it
> goes...
Here's a stab at cleaning it up:
https://git.kernel.dk/cgit/linux-block/log/?h=io_uring-task-poll
top two patches. First one simply cleans up the sched_update_worker(),
so we now have sched_in_update() and sched_out_update(). No changes in
this patch, just moves the worker sched-out handling into a helper.
2nd patch then utilizes this to flush the per-task requests that may
have been queued up.
--
Jens Axboe
^ permalink raw reply
* [PATCH AUTOSEL 4.14 027/186] arm64: cpufeature: Fix the type of no FP/SIMD capability
From: Sasha Levin @ 2020-02-14 16:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Suzuki K Poulose, Will Deacon, Mark Rutland, Ard Biesheuvel,
Catalin Marinas, Sasha Levin, linux-arm-kernel
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Suzuki K Poulose <suzuki.poulose@arm.com>
[ Upstream commit 449443c03d8cfdacf7313e17779a2594ebf87e6d ]
The NO_FPSIMD capability is defined with scope SYSTEM, which implies
that the "absence" of FP/SIMD on at least one CPU is detected only
after all the SMP CPUs are brought up. However, we use the status
of this capability for every context switch. So, let us change
the scope to LOCAL_CPU to allow the detection of this capability
as and when the first CPU without FP is brought up.
Also, the current type allows hotplugged CPU to be brought up without
FP/SIMD when all the current CPUs have FP/SIMD and we have the userspace
up. Fix both of these issues by changing the capability to
BOOT_RESTRICTED_LOCAL_CPU_FEATURE.
Fixes: 82e0191a1aa11abf ("arm64: Support systems without FP/ASIMD")
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm64/kernel/cpufeature.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 09c6499bc500e..c477fd34a9120 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1103,7 +1103,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
{
/* FP/SIMD is not implemented */
.capability = ARM64_HAS_NO_FPSIMD,
- .type = ARM64_CPUCAP_SYSTEM_FEATURE,
+ .type = ARM64_CPUCAP_BOOT_RESTRICTED_CPU_LOCAL_FEATURE,
.min_field_value = 0,
.matches = has_no_fpsimd,
},
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 058/186] drm/radeon: remove set but not used variable 'dig_connector'
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Hulk Robot, Alex Deucher, Sasha Levin, amd-gfx,
dri-devel
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit 3f47f0301594c4f930a32bd7d8125cfdeb6b4b6e ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/atombios_dp.c: In function radeon_dp_get_panel_mode:
drivers/gpu/drm/radeon/atombios_dp.c:415:36: warning: variable dig_connector set but not used [-Wunused-but-set-variable]
It is not used since commit 379dfc25e257 ("drm/radeon/dp:
switch to the common i2c over aux code")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/radeon/atombios_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c b/drivers/gpu/drm/radeon/atombios_dp.c
index fd7682bf335dc..b381fb17694b1 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -412,7 +412,6 @@ int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
struct radeon_connector *radeon_connector = to_radeon_connector(connector);
- struct radeon_connector_atom_dig *dig_connector;
int panel_mode = DP_PANEL_MODE_EXTERNAL_DP_MODE;
u16 dp_bridge = radeon_connector_encoder_get_dp_bridge_encoder_id(connector);
u8 tmp;
@@ -423,8 +422,6 @@ int radeon_dp_get_panel_mode(struct drm_encoder *encoder,
if (!radeon_connector->con_priv)
return panel_mode;
- dig_connector = radeon_connector->con_priv;
-
if (dp_bridge != ENCODER_OBJECT_ID_NONE) {
/* DP bridge chips */
if (drm_dp_dpcd_readb(&radeon_connector->ddc_bus->aux,
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v8 18/19] dmaengine: tegra-apb: Remove unused function argument
From: Dmitry Osipenko @ 2020-02-14 16:54 UTC (permalink / raw)
To: Jon Hunter, Laxman Dewangan, Vinod Koul, Dan Williams,
Thierry Reding, Michał Mirosław
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <d9a1bd6a-bd26-36ad-7d94-57801a2aa616-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
14.02.2020 17:16, Jon Hunter пишет:
...
> Acked-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>
> Thanks!
> Jon
>
Jon, thank you very much!
In the patchwork I see that you acked all the patches, but my Gmail
missed 2 of 4 emails, maybe the missing emails will arrive a day later :)
^ permalink raw reply
* [PATCH AUTOSEL 4.14 057/186] drm/radeon: remove set but not used variable 'backbias_response_time'
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Hulk Robot, Alex Deucher, Sasha Levin, amd-gfx,
dri-devel
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit ac52caecbcf2c30ce95b2536c1caf2643c49b91c ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/si_dpm.c: In function si_program_response_times:
drivers/gpu/drm/radeon/si_dpm.c:3640:29: warning: variable backbias_response_time set but not used [-Wunused-but-set-variable]
It is introduced by commit a9e61410921b ("drm/radeon/kms:
add dpm support for SI (v7)"), but never used, so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/radeon/si_dpm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c
index 9e5645e4cb55b..5b0de6e296f1c 100644
--- a/drivers/gpu/drm/radeon/si_dpm.c
+++ b/drivers/gpu/drm/radeon/si_dpm.c
@@ -3638,14 +3638,13 @@ static int si_notify_smc_display_change(struct radeon_device *rdev,
static void si_program_response_times(struct radeon_device *rdev)
{
- u32 voltage_response_time, backbias_response_time, acpi_delay_time, vbi_time_out;
+ u32 voltage_response_time, acpi_delay_time, vbi_time_out;
u32 vddc_dly, acpi_dly, vbi_dly;
u32 reference_clock;
si_write_smc_soft_register(rdev, SI_SMC_SOFT_REGISTER_mvdd_chg_time, 1);
voltage_response_time = (u32)rdev->pm.dpm.voltage_response_time;
- backbias_response_time = (u32)rdev->pm.dpm.backbias_response_time;
if (voltage_response_time == 0)
voltage_response_time = 1000;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v8 18/19] dmaengine: tegra-apb: Remove unused function argument
From: Dmitry Osipenko @ 2020-02-14 16:54 UTC (permalink / raw)
To: Jon Hunter, Laxman Dewangan, Vinod Koul, Dan Williams,
Thierry Reding, Michał Mirosław
Cc: dmaengine, linux-tegra, linux-kernel
In-Reply-To: <d9a1bd6a-bd26-36ad-7d94-57801a2aa616@nvidia.com>
14.02.2020 17:16, Jon Hunter пишет:
...
> Acked-by: Jon Hunter <jonathanh@nvidia.com>
>
> Thanks!
> Jon
>
Jon, thank you very much!
In the patchwork I see that you acked all the patches, but my Gmail
missed 2 of 4 emails, maybe the missing emails will arrive a day later :)
^ permalink raw reply
* Re: [PATCH v1 08/14] tests/vm: Added configuration file support
From: Alex Bennée @ 2020-02-14 16:53 UTC (permalink / raw)
To: Robert Foley; +Cc: fam, peter.puhov, philmd, qemu-devel
In-Reply-To: <20200205212920.467-9-robert.foley@linaro.org>
Robert Foley <robert.foley@linaro.org> writes:
> Changes to tests/vm/basevm.py to allow accepting a configuration file
> as a parameter. Allows for specifying VM options such as
> cpu, machine, memory, and arbitrary qemu arguments for specifying options
> such as NUMA configuration.
> Also added an example conf_example_aarch64.yml and conf_example_x86.yml.
>
> Signed-off-by: Robert Foley <robert.foley@linaro.org>
> ---
> tests/vm/Makefile.include | 2 ++
> tests/vm/basevm.py | 29 +++++++++++++++++-
> tests/vm/conf_example_aarch64.yml | 51 +++++++++++++++++++++++++++++++
> tests/vm/conf_example_x86.yml | 50 ++++++++++++++++++++++++++++++
> 4 files changed, 131 insertions(+), 1 deletion(-)
> create mode 100644 tests/vm/conf_example_aarch64.yml
> create mode 100644 tests/vm/conf_example_x86.yml
>
> diff --git a/tests/vm/Makefile.include b/tests/vm/Makefile.include
> index 778e506755..e9ed33226d 100644
> --- a/tests/vm/Makefile.include
> +++ b/tests/vm/Makefile.include
> @@ -35,6 +35,8 @@ vm-help vm-test:
> @echo " V=1 - Enable verbose ouput on host and guest commands"
> @echo " QEMU=/path/to/qemu - Change path to QEMU binary"
> @echo " QEMU_IMG=/path/to/qemu-img - Change path to qemu-img tool"
> + @echo " QEMU_CONFIG=/path/conf.yml - Change path to VM configuration .yml file."
> + @echo " See conf_example_*.yml for file format details."
>
> vm-build-all: $(addprefix vm-build-, $(IMAGES))
>
> diff --git a/tests/vm/basevm.py b/tests/vm/basevm.py
> index 33004934af..f488d4103c 100755
> --- a/tests/vm/basevm.py
> +++ b/tests/vm/basevm.py
> @@ -32,6 +32,7 @@ import shutil
> import multiprocessing
> import traceback
> from socket_thread import SocketThread
> +import yaml
So this throws my setup on my Gentoo SynQuacer. Is this meant to be in
the standard library or is this a separate dependency?
--
Alex Bennée
^ permalink raw reply
* [PATCH AUTOSEL 4.9 069/141] drm/mediatek: handle events when enabling/disabling crtc
From: Sasha Levin @ 2020-02-14 16:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, dri-devel, linux-mediatek, Bibby Hsieh, CK Hu,
linux-arm-kernel
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: Bibby Hsieh <bibby.hsieh@mediatek.com>
[ Upstream commit 411f5c1eacfebb1f6e40b653d29447cdfe7282aa ]
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
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 | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 01a21dd835b57..1ed60da76a0ce 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -306,6 +306,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
{
struct drm_device *drm = mtk_crtc->base.dev;
+ struct drm_crtc *crtc = &mtk_crtc->base;
int i;
DRM_DEBUG_DRIVER("%s\n", __func__);
@@ -327,6 +328,13 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
mtk_disp_mutex_unprepare(mtk_crtc->mutex);
pm_runtime_put(drm->dev);
+
+ if (crtc->state->event && !crtc->state->active) {
+ spin_lock_irq(&crtc->dev->event_lock);
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ spin_unlock_irq(&crtc->dev->event_lock);
+ }
}
static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [RFC PATCH v1] pin_on_cpu: Introduce thread CPU pinning system call
From: Mathieu Desnoyers @ 2020-02-14 16:54 UTC (permalink / raw)
To: Florian Weimer
Cc: H. Peter Anvin, Chris Lameter, Jann Horn, Peter Zijlstra,
Thomas Gleixner, linux-kernel, Joel Fernandes, Ingo Molnar,
Catalin Marinas, Dave Watson, Will Deacon, shuah, Andi Kleen,
linux-kselftest, Russell King, Michael Kerrisk, Paul, Paul Turner,
Boqun Feng, Josh Triplett, rostedt, Ben Maurer, linux-api,
Andy Lutomirski
In-Reply-To: <87blql5hfb.fsf@oldenburg2.str.redhat.com>
----- On Jan 30, 2020, at 6:10 AM, Florian Weimer fweimer@redhat.com wrote:
> * Mathieu Desnoyers:
>
>> It brings an interesting idea to the table though. Let's assume for now that
>> the only intended use of pin_on_cpu(2) would be to allow rseq(2) critical
>> sections to update per-cpu data on specific cpu number targets. In fact,
>> considering that userspace can be preempted at any point, we still need a
>> mechanism to guarantee atomicity with respect to other threads running on
>> the same runqueue, which rseq(2) provides. Therefore, that assumption does
>> not appear too far-fetched.
>>
>> There are 2 scenarios we need to consider here:
>>
>> A) pin_on_cpu(2) targets a CPU which is not part of the affinity mask.
>>
>> This case is easy: pin_on_cpu can return an error, and the caller needs to act
>> accordingly (e.g. figure out that this is a design error and report it, or
>> decide that it really did not want to touch that per-cpu data that badly and
>> make the entire process fall-back to a mechanism which does not use per-cpu
>> data at all from that point onwards)
>
> Affinity masks currently are not like process memory: there is an
> expectation that they can be altered from outside the process.
Yes, that's my main issue.
> Given that the caller may not have any ways to recover from the
> suggested pin_on_cpu behavior, that seems problematic.
Indeed.
>
> What I would expect is that if pin_on_cpu cannot achieve implied
> exclusion by running on the associated CPU, it acquires a lock that
> prevents others pin_on_cpu calls from entering the critical section, and
> tasks in the same task group from running on that CPU (if the CPU
> becomes available to the task group). The second part should maintain
> exclusion of rseq sequences even if their fast path is not changed.
I try to avoid mutual exclusion over shared memory as rseq fallback whenever
I can, so we can use rseq from lock-free algorithms without losing lock-freedom.
> (On the other hand, I'm worried that per-CPU data structures are a dead
> end for user space unless we get containerized affinity masks, so that
> contains only see resources that are actually available to them.)
I'm currently implementing a prototype of the following ideas, and I'm curious to
read your thoughts on those:
I'm adding a "affinity_pinned" flag to the task struct of each thread. It can
be set and cleared only by the owner thread through pin_on_cpu syscall commands.
When the affinity is pinned by a thread, trying to change its affinity (from an
external thread, or possibly from itself) will fail.
Whenever a thread would (temporarily) pin itself on a specific CPU, it would
also pin its affinity mask as a side-effect. When a thread unpins from a CPU,
the affinity mask stays pinned. The purpose of keeping this affinity pinned
state per-thread is to ensure we don't end up with tiny race windows where
changing the thread's affinity mask "typically" works, but fails once in a
while because it's done concurrently with a 1ms long cpu pinning. This would
lead to flaky code, and I try hard to avoid that.
How changing this affinity should fail (from sched_setaffinity and cpusets) is a
big unanswered question. I see two major alternatives so far:
1) We deliver a signal to the target thread (SIGKILL ? SIGSEGV ?), considering
that failure to be able to change its affinity mask means we need to send a
signal. How exactly would the killed application recover (or if it should)
is still unclear.
2) Return an error to the sched_setaffinity or cpusets caller, and let it deal
with the error as it sees fit: ignore it, log it, or send a signal.
I think option (2) provides the most flexiblity, and moves policy outside of
the kernel, which is a good thing. However, looking at how cpusets seems to
simply ignore errors when setting a task's cpumask, I wonder if asking from
cpusets to handle any kind of error is asking too much. :-/
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* [PATCH AUTOSEL 4.14 014/186] pxa168fb: Fix the function used to release some memory in an error handling path
From: Sasha Levin @ 2020-02-14 16:14 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Christophe JAILLET, Lubomir Rintel, YueHaibing,
Bartlomiej Zolnierkiewicz, Sasha Levin, dri-devel, linux-fbdev
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
[ Upstream commit 3c911fe799d1c338d94b78e7182ad452c37af897 ]
In the probe function, some resources are allocated using 'dma_alloc_wc()',
they should be released with 'dma_free_wc()', not 'dma_free_coherent()'.
We already use 'dma_free_wc()' in the remove function, but not in the
error handling path of the probe function.
Also, remove a useless 'PAGE_ALIGN()'. 'info->fix.smem_len' is already
PAGE_ALIGNed.
Fixes: 638772c7553f ("fb: add support of LCD display controller on pxa168/910 (base layer)")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Lubomir Rintel <lkundrak@v3.sk>
CC: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190831100024.3248-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/video/fbdev/pxa168fb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/pxa168fb.c b/drivers/video/fbdev/pxa168fb.c
index d059d04c63acd..20195d3dbf088 100644
--- a/drivers/video/fbdev/pxa168fb.c
+++ b/drivers/video/fbdev/pxa168fb.c
@@ -769,8 +769,8 @@ static int pxa168fb_probe(struct platform_device *pdev)
failed_free_clk:
clk_disable_unprepare(fbi->clk);
failed_free_fbmem:
- dma_free_coherent(fbi->dev, info->fix.smem_len,
- info->screen_base, fbi->fb_start_dma);
+ dma_free_wc(fbi->dev, info->fix.smem_len,
+ info->screen_base, fbi->fb_start_dma);
failed_free_info:
kfree(info);
@@ -804,7 +804,7 @@ static int pxa168fb_remove(struct platform_device *pdev)
irq = platform_get_irq(pdev, 0);
- dma_free_wc(fbi->dev, PAGE_ALIGN(info->fix.smem_len),
+ dma_free_wc(fbi->dev, info->fix.smem_len,
info->screen_base, info->fix.smem_start);
clk_disable_unprepare(fbi->clk);
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 055/186] drm/gma500: remove set but not used variable 'channel_eq'
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Hulk Robot, Daniel Vetter, Sasha Levin, dri-devel
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit a7adabeece570b8a566dd592219410456676796e ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/cdv_intel_dp.c: In function cdv_intel_dp_complete_link_train:
drivers/gpu/drm/gma500/cdv_intel_dp.c:1596:7: warning: variable channel_eq set but not used [-Wunused-but-set-variable]
It is never used, so remove it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1573902268-117518-1-git-send-email-zhengbin13@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_dp.c b/drivers/gpu/drm/gma500/cdv_intel_dp.c
index c52f9adf5e04c..af2cc63f3dcce 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_dp.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_dp.c
@@ -1593,7 +1593,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder *encoder)
{
struct drm_device *dev = encoder->base.dev;
struct cdv_intel_dp *intel_dp = encoder->dev_priv;
- bool channel_eq = false;
int tries, cr_tries;
u32 reg;
uint32_t DP = intel_dp->DP;
@@ -1601,7 +1600,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder *encoder)
/* channel equalization */
tries = 0;
cr_tries = 0;
- channel_eq = false;
DRM_DEBUG_KMS("\n");
reg = DP | DP_LINK_TRAIN_PAT_2;
@@ -1647,7 +1645,6 @@ cdv_intel_dp_complete_link_train(struct gma_encoder *encoder)
if (cdv_intel_channel_eq_ok(encoder)) {
DRM_DEBUG_KMS("PT2 train is done\n");
- channel_eq = true;
break;
}
--
2.20.1
^ permalink raw reply related
* [igt-dev] [PATCH i-g-t] tests/kms_rotation_crc: Speed up by not testing every format
From: Ville Syrjala @ 2020-02-14 16:55 UTC (permalink / raw)
To: igt-dev
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
As we did with kms_plane_scaling let's not test every pixel
format for rotation fails either. Instead we test each "class"
of formats as defined by igt_reduce_format(). The hope being
that there are no specific bugs in the hw for different
swizzles of the same underlying base format.
On KBL:
$ time ./build/tests/kms_rotation_crc --r sprite-rotation-90
- real 0m39,851s
- user 0m1,037s
- sys 0m12,895s
+ real 0m16,773s
+ user 0m0,357s
+ sys 0m5,475s
As per the usual recipe we add an --extended cmdline knob to
force the full coverage.
Only cuts ~30% of the total kms_rotation_crc runtime though.
There are other subtests which take over 80s on this particular
machine, so further work is clearly required to get the testing
time to sane levels.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
tests/kms_rotation_crc.c | 58 +++++++++++++++++++++++++++++++++++++---
1 file changed, 55 insertions(+), 3 deletions(-)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 2a7b10e990e2..fc4c13389953 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -23,6 +23,7 @@
*/
#include "igt.h"
+#include "igt_vec.h"
#include <math.h>
#define MAX_FENCES 32
@@ -65,6 +66,7 @@ typedef struct {
struct p_struct *multiplaneoldview;
struct p_point planepos[MAXMULTIPLANESAMOUNT];
+ bool extended;
} data_t;
typedef struct {
@@ -371,6 +373,28 @@ static void test_single_case(data_t *data, enum pipe pipe,
}
}
+static bool test_format(data_t *data,
+ struct igt_vec *tested_formats,
+ uint32_t format)
+{
+ if (!igt_fb_supported_format(format))
+ return false;
+
+ if (!is_i915_device(data->gfx_fd) ||
+ data->extended)
+ return true;
+
+ format = igt_reduce_format(format);
+
+ /* only test each format "class" once */
+ if (igt_vec_index(tested_formats, &format) >= 0)
+ return false;
+
+ igt_vec_push(tested_formats, &format);
+
+ return true;
+}
+
static void test_plane_rotation(data_t *data, int plane_type, bool test_bad_format)
{
igt_display_t *display = &data->display;
@@ -408,15 +432,21 @@ static void test_plane_rotation(data_t *data, int plane_type, bool test_bad_form
continue;
if (!data->override_fmt) {
+ struct igt_vec tested_formats;
+
+ igt_vec_init(&tested_formats, sizeof(uint32_t));
+
for (j = 0; j < plane->drm_plane->count_formats; j++) {
uint32_t format = plane->drm_plane->formats[j];
- if (!igt_fb_supported_format(format))
+ if (!test_format(data, &tested_formats, format))
continue;
test_single_case(data, pipe, output, plane, i,
format, test_bad_format);
}
+
+ igt_vec_fini(&tested_formats);
} else {
test_single_case(data, pipe, output, plane, i,
data->override_fmt, test_bad_format);
@@ -738,7 +768,30 @@ static const char *tiling_test_str(uint64_t tiling)
}
}
-igt_main
+static int opt_handler(int opt, int opt_index, void *_data)
+{
+ data_t *data = _data;
+
+ switch (opt) {
+ case 'e':
+ data->extended = true;
+ break;
+ }
+
+ return IGT_OPT_HANDLER_SUCCESS;
+}
+
+static const struct option long_opts[] = {
+ { .name = "extended", .has_arg = false, .val = 'e', },
+ {}
+};
+
+static const char help_str[] =
+ " --extended\t\tRun the extended tests\n";
+
+static data_t data;
+
+igt_main_args("", long_opts, help_str, opt_handler, &data)
{
struct rot_subtest {
unsigned plane;
@@ -771,7 +824,6 @@ igt_main
{ 0, 0 }
};
- data_t data = {};
int gen = 0;
igt_fixture {
--
2.24.1
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev
^ permalink raw reply related
* [PATCH AUTOSEL 4.14 054/186] drm/gma500: remove set but not used variable 'is_hdmi','is_crt'
From: Sasha Levin @ 2020-02-14 16:15 UTC (permalink / raw)
To: linux-kernel, stable
Cc: zhengbin, Hulk Robot, Daniel Vetter, Sasha Levin, dri-devel
In-Reply-To: <20200214161715.18113-1-sashal@kernel.org>
From: zhengbin <zhengbin13@huawei.com>
[ Upstream commit 834c43a97f341d319aa7b74099bbce2c4e75bc72 ]
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/gma500/cdv_intel_display.c: In function cdv_intel_crtc_mode_set:
drivers/gpu/drm/gma500/cdv_intel_display.c:594:7: warning: variable is_hdmi set but not used [-Wunused-but-set-variable]
drivers/gpu/drm/gma500/cdv_intel_display.c: In function cdv_intel_crtc_mode_set:
drivers/gpu/drm/gma500/cdv_intel_display.c:593:7: warning: variable is_crt set but not used [-Wunused-but-set-variable]
They are not used since commit acd7ef927e06 ("gma500:
Update the Cedarview clock handling")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/1573828027-122323-4-git-send-email-zhengbin13@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/gpu/drm/gma500/cdv_intel_display.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 17db4b4749d5a..9854fdd7c51cf 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -590,8 +590,8 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
struct gma_clock_t clock;
u32 dpll = 0, dspcntr, pipeconf;
bool ok;
- bool is_crt = false, is_lvds = false, is_tv = false;
- bool is_hdmi = false, is_dp = false;
+ bool is_lvds = false, is_tv = false;
+ bool is_dp = false;
struct drm_mode_config *mode_config = &dev->mode_config;
struct drm_connector *connector;
const struct gma_limit_t *limit;
@@ -615,10 +615,7 @@ static int cdv_intel_crtc_mode_set(struct drm_crtc *crtc,
is_tv = true;
break;
case INTEL_OUTPUT_ANALOG:
- is_crt = true;
- break;
case INTEL_OUTPUT_HDMI:
- is_hdmi = true;
break;
case INTEL_OUTPUT_DISPLAYPORT:
is_dp = true;
--
2.20.1
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 069/141] drm/mediatek: handle events when enabling/disabling crtc
From: Sasha Levin @ 2020-02-14 16:20 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, dri-devel, linux-mediatek, Bibby Hsieh, CK Hu,
linux-arm-kernel
In-Reply-To: <20200214162122.19794-1-sashal@kernel.org>
From: Bibby Hsieh <bibby.hsieh@mediatek.com>
[ Upstream commit 411f5c1eacfebb1f6e40b653d29447cdfe7282aa ]
The driver currently handles vblank events only when updating planes on
an already enabled CRTC. The atomic update API however allows requesting
an event when enabling or disabling a CRTC. This currently leads to
event objects being leaked in the kernel and to events not being sent
out. Fix it.
Signed-off-by: Bibby Hsieh <bibby.hsieh@mediatek.com>
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 | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
index 01a21dd835b57..1ed60da76a0ce 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
@@ -306,6 +306,7 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
{
struct drm_device *drm = mtk_crtc->base.dev;
+ struct drm_crtc *crtc = &mtk_crtc->base;
int i;
DRM_DEBUG_DRIVER("%s\n", __func__);
@@ -327,6 +328,13 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
mtk_disp_mutex_unprepare(mtk_crtc->mutex);
pm_runtime_put(drm->dev);
+
+ if (crtc->state->event && !crtc->state->active) {
+ spin_lock_irq(&crtc->dev->event_lock);
+ drm_crtc_send_vblank_event(crtc, crtc->state->event);
+ crtc->state->event = NULL;
+ spin_unlock_irq(&crtc->dev->event_lock);
+ }
}
static void mtk_drm_crtc_enable(struct drm_crtc *crtc)
--
2.20.1
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
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.