[GIT PULL] mtd: Fixes for 5.0/5.0-rc8
Hello Linus, Here are 2 fixes for 5.0 (or -rc8 if you end up delaying the release). Regards, Boris The following changes since commit d13937116f1e82bf508a6325111b322c30c85eb9: Linux 5.0-rc6 (2019-02-10 14:42:20 -0800) are available in the Git repository at: git://git.infradead.org/linux-mtd.git tags/mtd/fixes-for-5.0-rc8 for you to fetch changes up to 3e35730dd7540bad2d4e002703996391d9be49a0: mtd: powernv_flash: Fix device registration error (2019-02-13 14:19:40 +0100) - Don't add a digit to MTD-backed nvmem device names - Make sure powernv flash names are unique Aneesh Kumar K.V (2): mtd: Use mtd->name when registering nvmem device mtd: powernv_flash: Fix device registration error drivers/mtd/devices/powernv_flash.c | 2 +- drivers/mtd/mtdcore.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
[PATCH] drm: bridge: dw-hdmi: Fix overflow workaround for Rockchip SoCs
The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
also been identified as needing this workaround with a single iteration.
Fixes: be41fc55f1aa ("drm: bridge: dw-hdmi: Handle overflow workaround based on
device version")
Signed-off-by: Jonas Karlman
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 64c3cf027518..14223c0ee784 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1655,6 +1655,8 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
* iteration for others.
* The Amlogic Meson GX SoCs (v2.01a) have been identified as needing
* the workaround with a single iteration.
+* The Rockchip RK3288 SoC (v2.00a) and RK3328/RK3399 SoCs (v2.11a) have
+* been identified as needing the workaround with a single iteration.
*/
switch (hdmi->version) {
@@ -1663,7 +1665,9 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
break;
case 0x131a:
case 0x132a:
+ case 0x200a:
case 0x201a:
+ case 0x211a:
case 0x212a:
count = 1;
break;
--
2.17.1
Re: [RFC PATCH RT 0/2] Add PINNED_HARD mode to hrtimers
On 19/02/19 18:19, Sebastian Andrzej Siewior wrote: > On 2019-02-14 14:37:14 [+0100], Juri Lelli wrote: > > Hi, > Hi, > > > Now, I'm sending this and an RFC, as I'm wondering if the first behavior > > is actually what we want, and it is not odd at all for reasons that are > > not evident to me at the moment. In this case this posting might also > > function as a question: why we need things to work as they are today? > > There is /proc/sys/kernel/timer_migration which should disable this but > I think you know that already. > > So this is a NO_HZ feature. Basically try to move all the timers to a > designated CPU so all others can deep idle while one CPU does the work. > Ideally you have no timer which is pending / will expire if you go idle. > And then, once the timer fires the housekeeping CPU does the work so > chances are that the CPU, that programmed the timer, may remain idle. Right. > In this case you prepare the wakeup and then wake the CPU anyway. There > should be no downside to this unless the housekeeping CPU is busy and in > irq-off regions which would increase the latency. Also in case of > cyclictest -d0 > > the one CPU would have to process all timers. So the latency will be > worse compared to every CPU does its own wakeup. And on RT you probably > do not want to do deep idle anyway. Mmm, right. But, still very much dependent on the workload, I understand you are saying? So, no one size fits all solution. Thanks, - Juri
RE: [PATCH V7 1/4] dt-bindings: fsl: scu: add thermal binding
> From: Anson Huang
> Sent: Wednesday, February 20, 2019 2:54 PM
>
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> controller, the system controller is in charge of system power, clock and
> thermal sensors etc. management, Linux kernel has to communicate with
> system controller via MU (message unit) IPC to get temperature from thermal
> sensors, this patch adds binding doc for i.MX system controller thermal
> driver.
>
> Signed-off-by: Anson Huang
> Reviewed-by: Rob Herring
> ---
> Changes since V6:
> - put "imx,sensor-resource-id" property in thermal zone nodes.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 27
> ++
> 1 file changed, 27 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index 72d481c..ad96881 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -122,6 +122,27 @@ RTC bindings based on SCU Message Protocol
> Required properties:
> - compatible: should be "fsl,imx8qxp-sc-rtc";
>
> +Thermal bindings based on SCU Message Protocol
> +
> +
> +Required properties:
> +- compatible : Must be "fsl,imx-sc-thermal";
> +- tsens-num : Total number of thermal sensors supported;
We properly don't need this property if the number of sensor
is fixed on a specific SoC.
> +- #thermal-sensor-cells : Should be 1. See
> + Documentation/devicetree/bindings/thermal/thermal.txt
> + for a description.
> +
> +Required properties for thermal zone nodes:
> +- imx,sensor-resource-id : This property should be defined in each thermal
After a further looking at it, I wonder this property may not needed either.
> zone
> +of thermal-zones node, it passes each thermal zone's
> +resource id for thermal driver to get temperature via
> +SCU IPC.
> +
> +For thermal zone nodes, please refer to below binding
> +doc for details:
> +
> +[1] Documentation/devicetree/bindings/thermal/thermal.txt
> +
> Example (imx8qxp):
> -
> lsio_mu1: mailbox@5d1c {
> @@ -168,6 +189,12 @@ firmware {
> rtc: rtc {
> compatible = "fsl,imx8qxp-sc-rtc";
> };
> +
> + tsens: thermal-sensor {
> + compatible = "fsl,imx8qxp-sc-thermal";
> + tsens-num = <1>;
> + #thermal-sensor-cells = <1>;
This looks may not correct if sensor cells is 1 but the sensor number
Is also 1.
So we probably better remove tsens-num property.
Regards
Dong Aisheng
> + };
> };
> };
>
> --
> 2.7.4
[PATCH v3 8/9] ARM: dts: milbeaut: Add device tree set for the Milbeaut M10V board
Add devicetree for Milbeaut M10V SoC and M10V Evaluation board.
Signed-off-by: Sugaya Taichi
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/milbeaut-m10v-evb.dts | 32 +++
arch/arm/boot/dts/milbeaut-m10v.dtsi| 95 +
3 files changed, 128 insertions(+)
create mode 100644 arch/arm/boot/dts/milbeaut-m10v-evb.dts
create mode 100644 arch/arm/boot/dts/milbeaut-m10v.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index bd40148..f697d87 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1233,6 +1233,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt7623n-bananapi-bpi-r2.dtb \
mt8127-moose.dtb \
mt8135-evbp1.dtb
+dtb-$(CONFIG_ARCH_MILBEAUT) += milbeaut-m10v-evb.dtb
dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-ast2500-evb.dtb \
diff --git a/arch/arm/boot/dts/milbeaut-m10v-evb.dts
b/arch/arm/boot/dts/milbeaut-m10v-evb.dts
new file mode 100644
index 000..614f60c
--- /dev/null
+++ b/arch/arm/boot/dts/milbeaut-m10v-evb.dts
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Socionext Milbeaut M10V Evaluation Board */
+/dts-v1/;
+#include "milbeaut-m10v.dtsi"
+
+/ {
+ model = "Socionext M10V EVB";
+ compatible = "socionext,milbeaut-m10v-evb", "socionext,sc2000a";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ bootargs = "rootwait earlycon";
+ stdout-path = "serial0:115200n8";
+ };
+
+ clocks {
+ uclk40xi: uclk40xi {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <4000>;
+ };
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0x4000 0x8000>;
+ };
+
+};
diff --git a/arch/arm/boot/dts/milbeaut-m10v.dtsi
b/arch/arm/boot/dts/milbeaut-m10v.dtsi
new file mode 100644
index 000..aa7c6ca
--- /dev/null
+++ b/arch/arm/boot/dts/milbeaut-m10v.dtsi
@@ -0,0 +1,95 @@
+// SPDX-License-Identifier: GPL-2.0
+#include
+#include
+#include
+#include
+
+/ {
+ compatible = "socionext,sc2000a";
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ enable-method = "socionext,milbeaut-m10v-smp";
+ cpu@f00 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf00>;
+ };
+ cpu@f01 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf01>;
+ };
+ cpu@f02 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf02>;
+ };
+ cpu@f03 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a7";
+ reg = <0xf03>;
+ };
+ };
+
+ timer { /* The Generic Timer */
+ compatible = "arm,armv7-timer";
+ interrupts = ,
+ ,
+ ,
+ ;
+ clock-frequency = <4000>;
+ always-on;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ interrupt-parent = <>;
+
+ gic: interrupt-controller@1d00 {
+ compatible = "arm,cortex-a7-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0x1d001000 0x1000>,
+ <0x1d002000 0x1000>; /* CPU I/f base and size */
+ };
+
+ timer@1e50 { /* 32-bit Reload Timers */
+ compatible = "socionext,milbeaut-timer";
+ reg = <0x1e50 0x20>;
+ interrupts = <0 91 4>;
+ };
+
+ uart1: serial@1e700010 { /* PE4, PE5 */
+ /* Enable this as ttyUSI0 */
+ compatible = "socionext,milbeaut-usio-uart";
+ reg = <0x1e700010 0x10>;
+ interrupts = <0 141 0x4>, <0 149 0x4>;
+ interrupt-names = "rx", "tx";
+ };
+
+ };
+
+ sram@0 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0 0x0 0x1>;
+ smp-sram@f100 {
+ compatible =
[PATCH v3 9/9] ARM: configs: Add Milbeaut M10V defconfig
This patch adds the minimal defconfig for the Milbeaut M10V. Signed-off-by: Sugaya Taichi --- arch/arm/configs/milbeaut_m10v_defconfig | 175 +++ arch/arm/configs/multi_v7_defconfig | 2 + 2 files changed, 177 insertions(+) create mode 100644 arch/arm/configs/milbeaut_m10v_defconfig diff --git a/arch/arm/configs/milbeaut_m10v_defconfig b/arch/arm/configs/milbeaut_m10v_defconfig new file mode 100644 index 000..a263211 --- /dev/null +++ b/arch/arm/configs/milbeaut_m10v_defconfig @@ -0,0 +1,175 @@ +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_DEBUG_SEMIHOSTING=y +CONFIG_DEFAULT_HOSTNAME="mlbel" +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_FHANDLE=y +CONFIG_NO_HZ_FULL=y +CONFIG_NO_HZ_FULL_ALL=y +CONFIG_NO_HZ_FULL_SYSIDLE=y +CONFIG_NO_HZ_FULL_SYSIDLE_SMALL=4 +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_TASKSTATS=y +CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_CGROUPS=y +CONFIG_CGROUP_DEBUG=y +CONFIG_CPUSETS=y +CONFIG_CGROUP_SCHED=y +CONFIG_CFS_BANDWIDTH=y +CONFIG_RT_GROUP_SCHED=y +CONFIG_NAMESPACES=y +CONFIG_USER_NS=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_CC_OPTIMIZE_FOR_SIZE=y +CONFIG_KALLSYMS_ALL=y +# CONFIG_COMPAT_BRK is not set +CONFIG_SLAB=y +CONFIG_PROFILING=y +# CONFIG_OPROFILE=m +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +CONFIG_ARCH_MILBEAUT=y +CONFIG_ARCH_MILBEAUT_M10V=y +# CONFIG_CACHE_L2X0 is not set +CONFIG_ARM_ERRATA_754322=y +CONFIG_ARM_ERRATA_775420=y +CONFIG_SMP=y +# CONFIG_ARM_CPU_TOPOLOGY is not set +CONFIG_HAVE_ARM_ARCH_TIMER=y +CONFIG_PREEMPT=y +CONFIG_THUMB2_KERNEL=y +CONFIG_HIGHMEM=y +# CONFIG_COMPACTION is not set +CONFIG_CMA=y +# CONFIG_ATAGS is not set +CONFIG_ZBOOT_ROM_TEXT=0x0 +CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_KEXEC=y +CONFIG_CPU_FREQ=y +CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y +CONFIG_CPUFREQ_DT=y +CONFIG_CPU_IDLE=y +CONFIG_VFP=y +CONFIG_NEON=y +CONFIG_KERNEL_MODE_NEON=y +CONFIG_WQ_POWER_EFFICIENT_DEFAULT=y +CONFIG_UNIX=y +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_DMA_CMA=y +CONFIG_CMA_SIZE_MBYTES=16 +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_LOOP_MIN_COUNT=2 +CONFIG_BLK_DEV_RAM=y +CONFIG_SCSI=y +CONFIG_BLK_DEV_SD=y +CONFIG_VETH=y +CONFIG_INPUT_POLLDEV=y +# CONFIG_INPUT_MOUSEDEV is not set +CONFIG_INPUT_EVDEV=y +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +CONFIG_SERIO_LIBPS2=y +CONFIG_LEGACY_PTY_COUNT=4 +CONFIG_GPIOLIB=y +CONFIG_GPIO_SYSFS=y +# CONFIG_HWMON is not set +CONFIG_WATCHDOG=y +CONFIG_SOFT_WATCHDOG=m +CONFIG_REGULATOR=y +CONFIG_REGULATOR_DEBUG=y +CONFIG_REGULATOR_S6AP412=y +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_CAMERA_SUPPORT=y +CONFIG_MEDIA_CONTROLLER=y +CONFIG_VIDEO_ADV_DEBUG=y +CONFIG_SOC_CAMERA=y +CONFIG_SOC_CAMERA_PLATFORM=y +# CONFIG_VGA_ARB is not set +CONFIG_DMADEVICES=y +CONFIG_UIO=y +# CONFIG_IOMMU_SUPPORT is not set +CONFIG_RESET_CONTROLLER=y +CONFIG_EXT4_FS=y +# CONFIG_EXT4_USE_FOR_EXT23 is not set +# CONFIG_XFS_FS is not set +CONFIG_FANOTIFY=y +CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y +CONFIG_QUOTA=y +CONFIG_AUTOFS4_FS=y +# CONFIG_FUSE_FS is not set +CONFIG_FSCACHE=y +CONFIG_FSCACHE_STATS=y +CONFIG_FSCACHE_HISTOGRAM=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_FAT_DEFAULT_CODEPAGE=932 +CONFIG_TMPFS=y +CONFIG_TMPFS_POSIX_ACL=y +CONFIG_ROMFS_FS=y +CONFIG_ROMFS_BACKED_BY_BOTH=y +CONFIG_NFS_FS=m +CONFIG_NLS_CODEPAGE_437=y +CONFIG_NLS_CODEPAGE_737=y +CONFIG_NLS_CODEPAGE_775=y +CONFIG_NLS_CODEPAGE_850=y +CONFIG_NLS_CODEPAGE_852=y +CONFIG_NLS_CODEPAGE_855=y +CONFIG_NLS_CODEPAGE_857=y +CONFIG_NLS_CODEPAGE_860=y +CONFIG_NLS_CODEPAGE_861=y +CONFIG_NLS_CODEPAGE_862=y +CONFIG_NLS_CODEPAGE_863=y +CONFIG_NLS_CODEPAGE_864=y +CONFIG_NLS_CODEPAGE_865=y +CONFIG_NLS_CODEPAGE_866=y +CONFIG_NLS_CODEPAGE_869=y +CONFIG_NLS_CODEPAGE_936=y +CONFIG_NLS_CODEPAGE_950=y +CONFIG_NLS_CODEPAGE_932=y +CONFIG_NLS_CODEPAGE_949=y +CONFIG_NLS_CODEPAGE_874=y +CONFIG_NLS_ISO8859_8=y +CONFIG_NLS_CODEPAGE_1250=y +CONFIG_NLS_CODEPAGE_1251=y +CONFIG_NLS_ASCII=y +CONFIG_NLS_ISO8859_1=y +CONFIG_NLS_ISO8859_2=y +CONFIG_NLS_ISO8859_3=y +CONFIG_NLS_ISO8859_4=y +CONFIG_NLS_ISO8859_5=y +CONFIG_NLS_ISO8859_6=y +CONFIG_NLS_ISO8859_7=y +CONFIG_NLS_ISO8859_9=y +CONFIG_NLS_ISO8859_13=y +CONFIG_NLS_ISO8859_14=y +CONFIG_NLS_ISO8859_15=y +CONFIG_NLS_KOI8_R=y +CONFIG_NLS_KOI8_U=y +CONFIG_NLS_MAC_ROMAN=y +CONFIG_NLS_MAC_CELTIC=y +CONFIG_NLS_MAC_CENTEURO=y +CONFIG_NLS_MAC_CROATIAN=y +CONFIG_NLS_MAC_CYRILLIC=y +CONFIG_NLS_MAC_GAELIC=y +CONFIG_NLS_MAC_GREEK=y +CONFIG_NLS_MAC_ICELAND=y +CONFIG_NLS_MAC_INUIT=y +CONFIG_NLS_MAC_ROMANIAN=y +CONFIG_NLS_MAC_TURKISH=y +CONFIG_NLS_UTF8=y +CONFIG_PRINTK_TIME=y +CONFIG_HEADERS_CHECK=y +CONFIG_RCU_TORTURE_TEST=m +CONFIG_RCU_CPU_STALL_TIMEOUT=60 +CONFIG_KGDB=y +CONFIG_KEYS=y +CONFIG_ENCRYPTED_KEYS=y +CONFIG_SECURITY=y +CONFIG_FONTS=y diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 5bee34a..6753805 100644 --- a/arch/arm/configs/multi_v7_defconfig
[PATCH v3 7/9] dt-bindings: serial: Add Milbeaut serial driver description
Add DT bindings document for Milbeaut serial driver.
Signed-off-by: Sugaya Taichi
---
.../devicetree/bindings/serial/milbeaut-uart.txt| 21 +
1 file changed, 21 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/milbeaut-uart.txt
diff --git a/Documentation/devicetree/bindings/serial/milbeaut-uart.txt
b/Documentation/devicetree/bindings/serial/milbeaut-uart.txt
new file mode 100644
index 000..3d2fb1a
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/milbeaut-uart.txt
@@ -0,0 +1,21 @@
+Socionext Milbeaut UART controller
+
+Required properties:
+- compatible: should be "socionext,milbeaut-usio-uart".
+- reg: offset and length of the register set for the device.
+- interrupts: two interrupts specifier.
+- interrupt-names: should be "rx", "tx".
+- clocks: phandle to the input clock.
+
+Optional properties:
+- auto-flow-control: flow control enable.
+
+Example:
+ usio1: usio_uart@1e700010 {
+ compatible = "socionext,milbeaut-usio-uart";
+ reg = <0x1e700010 0x10>;
+ interrupts = <0 141 0x4>, <0 149 0x4>;
+ interrupt-names = "rx", "tx";
+ clocks = < 2>;
+ auto-flow-control;
+ };
--
1.9.1
[PATCH v3 6/9] clocksource/drivers/timer-milbeaut: Introduce timer for Milbeaut SoCs
Add timer driver for Milbeaut SoCs series.
The timer has two 32-bit width down counters, one of which is configured
as a clockevent device and the other is configured as a clock source.
Signed-off-by: Sugaya Taichi
Acked-by: Daniel Lezcano
---
drivers/clocksource/Kconfig | 9 ++
drivers/clocksource/Makefile | 1 +
drivers/clocksource/timer-milbeaut.c | 161 +++
3 files changed, 171 insertions(+)
create mode 100644 drivers/clocksource/timer-milbeaut.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a9e26f6..9101b8f 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -634,4 +634,13 @@ config GX6605S_TIMER
help
This option enables support for gx6605s SOC's timer.
+config MILBEAUT_TIMER
+ bool "Milbeaut timer driver" if COMPILE_TEST
+ depends on OF
+ depends on ARM
+ select TIMER_OF
+ select CLKSRC_MMIO
+ help
+ Enables the support for Milbeaut timer driver.
+
endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index cdd210f..6f2543b 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_CLKSRC_TI_32K) += timer-ti-32k.o
obj-$(CONFIG_CLKSRC_NPS) += timer-nps.o
obj-$(CONFIG_OXNAS_RPS_TIMER) += timer-oxnas-rps.o
obj-$(CONFIG_OWL_TIMER)+= timer-owl.o
+obj-$(CONFIG_MILBEAUT_TIMER) += timer-milbeaut.o
obj-$(CONFIG_SPRD_TIMER) += timer-sprd.o
obj-$(CONFIG_NPCM7XX_TIMER)+= timer-npcm7xx.o
obj-$(CONFIG_RDA_TIMER)+= timer-rda.o
diff --git a/drivers/clocksource/timer-milbeaut.c
b/drivers/clocksource/timer-milbeaut.c
new file mode 100644
index 000..f2019a8
--- /dev/null
+++ b/drivers/clocksource/timer-milbeaut.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Socionext Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include "timer-of.h"
+
+#define MLB_TMR_TMCSR_OFS 0x0
+#define MLB_TMR_TMR_OFS0x4
+#define MLB_TMR_TMRLR1_OFS 0x8
+#define MLB_TMR_TMRLR2_OFS 0xc
+#define MLB_TMR_REGSZPCH 0x10
+
+#define MLB_TMR_TMCSR_OUTL BIT(5)
+#define MLB_TMR_TMCSR_RELD BIT(4)
+#define MLB_TMR_TMCSR_INTE BIT(3)
+#define MLB_TMR_TMCSR_UF BIT(2)
+#define MLB_TMR_TMCSR_CNTE BIT(1)
+#define MLB_TMR_TMCSR_TRG BIT(0)
+
+#define MLB_TMR_TMCSR_CSL_DIV2 0
+#define MLB_TMR_DIV_CNT2
+
+#define MLB_TMR_SRC_CH (1)
+#define MLB_TMR_EVT_CH (0)
+
+#define MLB_TMR_SRC_CH_OFS (MLB_TMR_REGSZPCH * MLB_TMR_SRC_CH)
+#define MLB_TMR_EVT_CH_OFS (MLB_TMR_REGSZPCH * MLB_TMR_EVT_CH)
+
+#define MLB_TMR_SRC_TMCSR_OFS (MLB_TMR_SRC_CH_OFS + MLB_TMR_TMCSR_OFS)
+#define MLB_TMR_SRC_TMR_OFS(MLB_TMR_SRC_CH_OFS + MLB_TMR_TMR_OFS)
+#define MLB_TMR_SRC_TMRLR1_OFS (MLB_TMR_SRC_CH_OFS + MLB_TMR_TMRLR1_OFS)
+#define MLB_TMR_SRC_TMRLR2_OFS (MLB_TMR_SRC_CH_OFS + MLB_TMR_TMRLR2_OFS)
+
+#define MLB_TMR_EVT_TMCSR_OFS (MLB_TMR_EVT_CH_OFS + MLB_TMR_TMCSR_OFS)
+#define MLB_TMR_EVT_TMR_OFS(MLB_TMR_EVT_CH_OFS + MLB_TMR_TMR_OFS)
+#define MLB_TMR_EVT_TMRLR1_OFS (MLB_TMR_EVT_CH_OFS + MLB_TMR_TMRLR1_OFS)
+#define MLB_TMR_EVT_TMRLR2_OFS (MLB_TMR_EVT_CH_OFS + MLB_TMR_TMRLR2_OFS)
+
+#define MLB_TIMER_RATING 500
+
+static irqreturn_t mlb_timer_interrupt(int irq, void *dev_id)
+{
+ struct clock_event_device *clk = dev_id;
+ struct timer_of *to = to_timer_of(clk);
+ u32 val;
+
+ val = readl_relaxed(timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
+ val &= ~MLB_TMR_TMCSR_UF;
+ writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
+
+ clk->event_handler(clk);
+
+ return IRQ_HANDLED;
+}
+
+static int mlb_set_state_periodic(struct clock_event_device *clk)
+{
+ struct timer_of *to = to_timer_of(clk);
+ u32 val = MLB_TMR_TMCSR_CSL_DIV2;
+
+ writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
+
+ writel_relaxed(to->of_clk.period, timer_of_base(to) +
+ MLB_TMR_EVT_TMRLR1_OFS);
+ val |= MLB_TMR_TMCSR_RELD | MLB_TMR_TMCSR_CNTE |
+ MLB_TMR_TMCSR_TRG | MLB_TMR_TMCSR_INTE;
+ writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
+ return 0;
+}
+
+static int mlb_set_state_oneshot(struct clock_event_device *clk)
+{
+ struct timer_of *to = to_timer_of(clk);
+ u32 val = MLB_TMR_TMCSR_CSL_DIV2;
+
+ writel_relaxed(val, timer_of_base(to) + MLB_TMR_EVT_TMCSR_OFS);
+ return 0;
+}
+
+static int mlb_clkevt_next_event(unsigned long event,
+ struct clock_event_device *clk)
+{
+ struct timer_of *to = to_timer_of(clk);
+
+ writel_relaxed(event, timer_of_base(to) + MLB_TMR_EVT_TMRLR1_OFS);
+ writel_relaxed(MLB_TMR_TMCSR_CSL_DIV2 |
+ MLB_TMR_TMCSR_CNTE | MLB_TMR_TMCSR_INTE |
+
linux-next: Tree for Feb 20
Hi all, Changes since 20190219: The asm-generic tree lost its build failure. The v4l-dvb tree lost its build failure. The net-next tree gained a conflict against the bpf tree. The kvm tree still had its build failure so I used a supplied patch. The akpm-current tree gained a build failure due to an interaction with the drm tree for which I applied a merge fix patch. Non-merge commits (relative to Linus' tree): 8846 9249 files changed, 416125 insertions(+), 220692 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 296 trees (counting Linus' and 69 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (b5372fe5dc84 exec: load_script: Do not exec truncated interpreter path) Merging fixes/master (ed3ce4cfc919 adfs: mark expected switch fall-throughs) Merging kspp-gustavo/for-next/kspp (6f6c95f09001 ASN.1: mark expected switch fall-through) Merging kbuild-current/fixes (207a369e3c08 sh: fix build error for invisible CONFIG_BUILTIN_DTB_SOURCE) Merging arc-current/for-curr (3a939df742e5 ARC: enable uboot support unconditionally) Merging arm-current/fixes (fc67e6f120a3 ARM: 8835/1: dma-mapping: Clear DMA ops on teardown) Merging arm64-fixes/for-next/fixes (0738c8b5915c arm64/neon: Disable -Wincompatible-pointer-types when building with Clang) Merging m68k-current/for-linus (bed1369f5190 m68k: Fix memblock-related crashes) Merging powerpc-fixes/fixes (a58007621be3 powerpc/64s: Fix possible corruption on big endian due to pgd/pud_present()) Merging sparc/master (b71acb0e3721 Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (5cd856a5ef9a Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf) Merging bpf/master (f6be4d16039b selftests/bpf: make sure signal interrupts BPF_PROG_TEST_RUN) Merging ipsec/master (660899ddf06a xfrm: Fix inbound traffic via XFRM interfaces across network namespaces) Merging netfilter/master (c93a49b9769e ipvs: fix warning on unused variable) Merging ipvs/master (b2e3d68d1251 netfilter: nft_compat: destroy function must not have side effects) Merging wireless-drivers/master (d04ca383860b mt76x0u: fix suspend/resume) Merging mac80211/master (83e37e0bdd14 mac80211: Restore vif beacon interval if start ap fails) Merging rdma-fixes/for-rc (48396e80fb65 RDMA/srp: Rework SCSI device reset handling) Merging sound-current/for-linus (268836649c07 Merge tag 'asoc-fix-v5.0-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus) Merging sound-asoc-fixes/for-linus (e080eee63441 Merge branch 'asoc-5.0' into asoc-linus) Merging regmap-fixes/for-linus (f17b5f06cb92 Linux 5.0-rc4) Merging regulator-fixes/for-linus (86d2d637fd84 Merge branch 'regulator-5.0' into regulator-linus) Merging spi-fixes/for-linus (5035e90c71bf Merge branch 'spi-5.0' into spi-linus) Merging pci-current/for-linus (f57a98e1b713 PCI: Work around Synopsys duplicate Device ID (HAPS USB3, NXP i.MX)) Merging driver-core.current/driver-core-linus (d13937116f1e Linux 5.0-rc6) Merging tty.current/tty-linus (d13937116f1e Linux 5.0-rc6) Merging usb.current/usb-linus (d13937116f1e Linux 5.0-rc6) Merging usb-gadget-fixes/fixes (a53469a68eb8 usb: phy: am335x:
[PATCH v3 5/9] dt-bindings: timer: Add Milbeaut M10V timer description
Add DT bindings document for Milbeaut M10V timer.
Signed-off-by: Sugaya Taichi
Reviewed-by: Rob Herring
---
.../bindings/timer/socionext,milbeaut-timer.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
diff --git
a/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
new file mode 100644
index 000..ac44c4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt
@@ -0,0 +1,17 @@
+Milbeaut SoCs Timer Controller
+
+Required properties:
+
+- compatible : should be "socionext,milbeaut-timer".
+- reg : Specifies base physical address and size of the registers.
+- interrupts : The interrupt of the first timer.
+- clocks: phandle to the input clk.
+
+Example:
+
+timer {
+ compatible = "socionext,milbeaut-timer";
+ reg = <0x1e50 0x20>
+ interrupts = <0 91 4>;
+ clocks = < 4>;
+};
--
1.9.1
[PATCH v3 4/9] ARM: milbeaut: Add basic support for Milbeaut m10v SoC
This adds the basic M10V SoC support under arch/arm.
Since all cores are activated in the custom bootloader before booting
linux, it is necessary to wait for the secondary-cores using cpu-enable-
method and special sram.
Signed-off-by: Sugaya Taichi
---
arch/arm/Kconfig | 2 +
arch/arm/Makefile| 1 +
arch/arm/mach-milbeaut/Kconfig | 20 ++
arch/arm/mach-milbeaut/Makefile | 1 +
arch/arm/mach-milbeaut/platsmp.c | 143 +++
5 files changed, 167 insertions(+)
create mode 100644 arch/arm/mach-milbeaut/Kconfig
create mode 100644 arch/arm/mach-milbeaut/Makefile
create mode 100644 arch/arm/mach-milbeaut/platsmp.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 664e918..c8cb752 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -750,6 +750,8 @@ source "arch/arm/mach-mediatek/Kconfig"
source "arch/arm/mach-meson/Kconfig"
+source "arch/arm/mach-milbeaut/Kconfig"
+
source "arch/arm/mach-mmp/Kconfig"
source "arch/arm/mach-moxart/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 9db3c58..0e9 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -190,6 +190,7 @@ machine-$(CONFIG_ARCH_MV78XX0) += mv78xx0
machine-$(CONFIG_ARCH_MVEBU) += mvebu
machine-$(CONFIG_ARCH_MXC) += imx
machine-$(CONFIG_ARCH_MEDIATEK)+= mediatek
+machine-$(CONFIG_ARCH_MILBEAUT)+= milbeaut
machine-$(CONFIG_ARCH_MXS) += mxs
machine-$(CONFIG_ARCH_NETX)+= netx
machine-$(CONFIG_ARCH_NOMADIK) += nomadik
diff --git a/arch/arm/mach-milbeaut/Kconfig b/arch/arm/mach-milbeaut/Kconfig
new file mode 100644
index 000..6a576fd
--- /dev/null
+++ b/arch/arm/mach-milbeaut/Kconfig
@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: GPL-2.0
+menuconfig ARCH_MILBEAUT
+ bool "Socionext Milbeaut SoCs"
+ depends on ARCH_MULTI_V7
+ select ARM_GIC
+ help
+ This enables support for Socionext Milbeaut SoCs
+
+if ARCH_MILBEAUT
+
+config ARCH_MILBEAUT_M10V
+ bool "Milbeaut SC2000/M10V platform"
+ select ARM_ARCH_TIMER
+ select MILBEAUT_TIMER
+ select PINCTRL
+ select PINCTRL_MILBEAUT
+ help
+ Support for Socionext's MILBEAUT M10V based systems
+
+endif
diff --git a/arch/arm/mach-milbeaut/Makefile b/arch/arm/mach-milbeaut/Makefile
new file mode 100644
index 000..ce5ea06
--- /dev/null
+++ b/arch/arm/mach-milbeaut/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_SMP) += platsmp.o
diff --git a/arch/arm/mach-milbeaut/platsmp.c b/arch/arm/mach-milbeaut/platsmp.c
new file mode 100644
index 000..591543c
--- /dev/null
+++ b/arch/arm/mach-milbeaut/platsmp.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright: (C) 2018 Socionext Inc.
+ * Copyright: (C) 2015 Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#define M10V_MAX_CPU 4
+#define KERNEL_UNBOOT_FLAG 0x12345678
+
+static void __iomem *m10v_smp_base;
+
+static int m10v_boot_secondary(unsigned int l_cpu, struct task_struct *idle)
+{
+ unsigned int mpidr, cpu, cluster;
+
+ if (!m10v_smp_base)
+ return -ENXIO;
+
+ mpidr = cpu_logical_map(l_cpu);
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+
+ if (cpu >= M10V_MAX_CPU)
+ return -EINVAL;
+
+ pr_info("%s: cpu %u l_cpu %u cluster %u\n",
+ __func__, cpu, l_cpu, cluster);
+
+ writel(__pa_symbol(secondary_startup), m10v_smp_base + cpu * 4);
+ arch_send_wakeup_ipi_mask(cpumask_of(l_cpu));
+
+ return 0;
+}
+
+static void m10v_smp_init(unsigned int max_cpus)
+{
+ unsigned int mpidr, cpu, cluster;
+ struct device_node *np;
+
+ np = of_find_compatible_node(NULL, NULL, "socionext,milbeaut-smp-sram");
+ if (!np)
+ return;
+
+ m10v_smp_base = of_iomap(np, 0);
+ if (!m10v_smp_base)
+ return;
+
+ mpidr = read_cpuid_mpidr();
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+ cluster = MPIDR_AFFINITY_LEVEL(mpidr, 1);
+ pr_info("MCPM boot on cpu_%u cluster_%u\n", cpu, cluster);
+
+ for (cpu = 0; cpu < M10V_MAX_CPU; cpu++)
+ writel(KERNEL_UNBOOT_FLAG, m10v_smp_base + cpu * 4);
+}
+
+static void m10v_cpu_die(unsigned int l_cpu)
+{
+ gic_cpu_if_down(0);
+ v7_exit_coherency_flush(louis);
+ wfi();
+}
+
+static int m10v_cpu_kill(unsigned int l_cpu)
+{
+ unsigned int mpidr, cpu;
+
+ mpidr = cpu_logical_map(l_cpu);
+ cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
+
+ writel(KERNEL_UNBOOT_FLAG, m10v_smp_base + cpu * 4);
+
+ return 1;
+}
+
+static struct smp_operations m10v_smp_ops __initdata = {
+ .smp_prepare_cpus = m10v_smp_init,
+ .smp_boot_secondary = m10v_boot_secondary,
+ .cpu_die=
[PATCH v3 1/9] dt-bindings: sram: milbeaut: Add binding for Milbeaut smp-sram
The Milbeaut M10V SoC needs a part of sram for smp, so this adds the
M10V sram compatible and binding.
Signed-off-by: Sugaya Taichi
Reviewed-by: Rob Herring
---
.../devicetree/bindings/sram/milbeaut-smp-sram.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sram/milbeaut-smp-sram.txt
diff --git a/Documentation/devicetree/bindings/sram/milbeaut-smp-sram.txt
b/Documentation/devicetree/bindings/sram/milbeaut-smp-sram.txt
new file mode 100644
index 000..194f6a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sram/milbeaut-smp-sram.txt
@@ -0,0 +1,24 @@
+Milbeaut SRAM for smp bringup
+
+Milbeaut SoCs use a part of the sram for the bringup of the secondary cores.
+Once they get powered up in the bootloader, they stay at the specific part
+of the sram.
+Therefore the part needs to be added as the sub-node of mmio-sram.
+
+Required sub-node properties:
+- compatible : should be "socionext,milbeaut-smp-sram"
+
+Example:
+
+sram: sram@0 {
+compatible = "mmio-sram";
+reg = <0x0 0x1>;
+#address-cells = <1>;
+#size-cells = <1>;
+ranges = <0 0x0 0x1>;
+
+smp-sram@f100 {
+compatible = "socionext,milbeaut-smp-sram";
+reg = <0xf100 0x20>;
+};
+};
--
1.9.1
[PATCH v3 2/9] dt-bindings: arm: Add SMP enable-method for Milbeaut
This adds a compatible string "socionext,milbeaut-m10v-smp" for Milbeaut M10V to the 32 bit ARM CPU device tree binding. Signed-off-by: Sugaya Taichi Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/arm/cpus.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 298c17b..365dcf3 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -228,6 +228,7 @@ patternProperties: - renesas,r9a06g032-smp - rockchip,rk3036-smp - rockchip,rk3066-smp + - socionext,milbeaut-m10v-smp - ste,dbx500-smp cpu-release-addr: -- 1.9.1
[PATCH v3 3/9] dt-bindings: Add documentation for Milbeaut SoCs
This adds a DT binding documentation for the M10V and its evaluation board. Signed-off-by: Sugaya Taichi --- .../bindings/arm/socionext/milbeaut.yaml | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml diff --git a/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml b/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml new file mode 100644 index 000..522396f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml @@ -0,0 +1,22 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/milbeaut.yaml# +$schema: http://devicetree.org/meta-schemas/milbeaut.yaml# + +title: Milbeaut platforms device tree bindings + +maintainers: + - Taichi Sugaya + - Takao Orito + +properties: + $nodename: +const: '/' + compatible: +oneOf: + - items: + - enum: + - socionext,milbeaut-m10v-evb + - const: socionext,sc2000a +... -- 1.9.1
[PATCH v3 0/9] Add basic support for Socionext Milbeaut M10V SoC
Hi, Here is the series of patches the initial support for SC2000(M10V) of Milbeaut SoCs. "M10V" is the internal name of SC2000, so commonly used in source code. SC2000 is a SoC of the Milbeaut series. equipped with a DSP optimized for computer vision. It also features advanced functionalities such as 360-degree, real-time spherical stitching with multi cameras, image stabilization for without mechanical gimbals, and rolling shutter correction. More detail is below: https://www.socionext.com/en/products/assp/milbeaut/SC2000.html Specifications for developers are below: - Quad-core 32bit Cortex-A7 on ARMv7-A architecture - NEON support - DSP - GPU - MAX 3GB DDR3 - Cortex-M0 for power control - NAND Flash Interface - SD UHS-I - SD UHS-II - SDIO - USB2.0 HOST / Device - USB3.0 HOST / Device - PCI express Gen2 - Ethernet Engine - I2C - UART - SPI - PWM Support is quite minimal for now, since it only includes timer, clock, pictrl and serial controller drivers, so we can only boot to userspace through initramfs. Support for the other peripherals will come eventually. Changes since v2: * Drop clk, pinctrl, and serial driver. * Drop unneeded options from defconfig. * Convert milbeaut soc binding to yaml. * Fix serial driver binding. * Change serial id of aliases in DT. * Add platform checking when entering suspend/resume. * Drop pr_err()s. Changes since v1: * Change file names. * Change #define names. * Refine cpu-enable-method and bindigs. * Add documentation for Milbeaut SoCs. * Add more infomation for timer driver. * Add sched_clock to timer driver. * Refine whole of clk driver. * Add earlycon instead of earlyprintk. * Refine Device Tree. Sugaya Taichi (9): dt-bindings: sram: milbeaut: Add binding for Milbeaut smp-sram dt-bindings: arm: Add SMP enable-method for Milbeaut dt-bindings: Add documentation for Milbeaut SoCs ARM: milbeaut: Add basic support for Milbeaut m10v SoC dt-bindings: timer: Add Milbeaut M10V timer description clocksource/drivers/timer-milbeaut: Introduce timer for Milbeaut SoCs dt-bindings: serial: Add Milbeaut serial driver description ARM: dts: milbeaut: Add device tree set for the Milbeaut M10V board ARM: configs: Add Milbeaut M10V defconfig Documentation/devicetree/bindings/arm/cpus.yaml| 1 + .../bindings/arm/socionext/milbeaut.yaml | 22 +++ .../devicetree/bindings/serial/milbeaut-uart.txt | 21 +++ .../devicetree/bindings/sram/milbeaut-smp-sram.txt | 24 +++ .../bindings/timer/socionext,milbeaut-timer.txt| 17 ++ arch/arm/Kconfig | 2 + arch/arm/Makefile | 1 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/milbeaut-m10v-evb.dts| 32 arch/arm/boot/dts/milbeaut-m10v.dtsi | 95 +++ arch/arm/configs/milbeaut_m10v_defconfig | 175 + arch/arm/configs/multi_v7_defconfig| 2 + arch/arm/mach-milbeaut/Kconfig | 20 +++ arch/arm/mach-milbeaut/Makefile| 1 + arch/arm/mach-milbeaut/platsmp.c | 143 + drivers/clocksource/Kconfig| 9 ++ drivers/clocksource/Makefile | 1 + drivers/clocksource/timer-milbeaut.c | 161 +++ 18 files changed, 728 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/socionext/milbeaut.yaml create mode 100644 Documentation/devicetree/bindings/serial/milbeaut-uart.txt create mode 100644 Documentation/devicetree/bindings/sram/milbeaut-smp-sram.txt create mode 100644 Documentation/devicetree/bindings/timer/socionext,milbeaut-timer.txt create mode 100644 arch/arm/boot/dts/milbeaut-m10v-evb.dts create mode 100644 arch/arm/boot/dts/milbeaut-m10v.dtsi create mode 100644 arch/arm/configs/milbeaut_m10v_defconfig create mode 100644 arch/arm/mach-milbeaut/Kconfig create mode 100644 arch/arm/mach-milbeaut/Makefile create mode 100644 arch/arm/mach-milbeaut/platsmp.c create mode 100644 drivers/clocksource/timer-milbeaut.c -- 1.9.1
Re: [PATCH][next] usb: typec: mux: fix an unsigned less than zero check
On Tue, Feb 19, 2019 at 03:19:18PM +, Colin King wrote:
> From: Colin Ian King
>
> The checks of a negative nval indicating an error an never be true
> as nval is currently a size_t which is of course unsigned and hence
> never less than zero. Fix this by making nval an int.
>
> Detected by CoverityScan, CID#1476863 ("Unsigned compared against 0)
> and CID#1476948 ("Loop bound")
>
> Fixes: 96a6d031ca99 ("usb: typec: mux: Find the muxes by also matching
> against the device node")
> Signed-off-by: Colin Ian King
> ---
> drivers/usb/typec/mux.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
> index b94e2920eb38..64d2ed3fecb8 100644
> --- a/drivers/usb/typec/mux.c
> +++ b/drivers/usb/typec/mux.c
> @@ -126,10 +126,9 @@ static void *typec_mux_match(struct device_connection
> *con, int ep, void *data)
> {
> const struct typec_altmode_desc *desc = data;
> struct typec_mux *mux;
> - size_t nval;
> bool match;
> u16 *val;
> - int i;
> + int i, nval;
>
> if (!con->fwnode) {
> list_for_each_entry(mux, _list, entry)
> --
> 2.20.1
This one has already a fix:
https://lkml.org/lkml/2019/2/19/56
thanks,
--
heikki
Re: [PATCHv7] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr
On Mon, Feb 18, 2019 at 9:48 AM Dave Young wrote: > > On 02/15/19 at 11:24am, Borislav Petkov wrote: > > On Tue, Feb 12, 2019 at 04:48:16AM +0800, Dave Young wrote: > > > Even we make it automatic in kernel, but we have to have some default > > > value for swiotlb in case crashkernel can not find a free region under 4G. > > > So this default value can not work for every use cases, people need > > > manually use crashkernel=,low and crashkernel=,high in case > > > crashkernel=X does not work. > > > > Why would the user need to find swiotlb range? The kernel has all the > > information it requires at its finger tips in order to decide properly. > > > > The user wants a crashkernel range, the kernel tries the low range => > > no workie, then it tries the next range => workie but needs to allocate > > swiotlb range so that DMA can happen too. Doh, then the kernel does > > allocate that too. > > It is ideal if kernel can do it automatically, but I'm not sure if > kernel can predict the swiotlb reserved size automatically. > Agreed, I think it is hard to decide the reserved size automatically. We do not know the requirement for memory of ZONE_DMA32 at boot time. The requirement depends on how many DMA32 devices, and the dynamic payload of them. > Let's add more people to seek for comments. > > > > > Why would the user need to do anything here?! > > > > -- > > Regards/Gruss, > > Boris. > > > > Good mailing practices for 400: avoid top-posting and trim the reply.
Re: [f2fs-dev] [PATCH] f2fs: don't clear CP_QUOTA_NEED_FSCK_FLAG
On 2019/2/20 15:25, Chao Yu wrote: > On 2019/2/20 15:08, Jaegeuk Kim wrote: >> On 02/18, Chao Yu wrote: >>> On 2019/2/16 12:55, Jaegeuk Kim wrote: On 02/13, Chao Yu wrote: > On 2019/2/12 10:33, Jaegeuk Kim wrote: >> If we met this once, let fsck.f2fs clear this only. >> Note that, this addresses all the subtle fault injection test. >> >> Signed-off-by: Jaegeuk Kim >> --- >> fs/f2fs/checkpoint.c | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c >> index 03fea4efd64b..10a3ada28715 100644 >> --- a/fs/f2fs/checkpoint.c >> +++ b/fs/f2fs/checkpoint.c >> @@ -1267,8 +1267,6 @@ static void update_ckpt_flags(struct f2fs_sb_info >> *sbi, struct cp_control *cpc) >> >> if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) >> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >> -else >> -__clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > > I didn't get it, previously, if we didn't persist all quota file's data in > checkpoint, then we will tag CP_QUOTA_NEED_FSCK_FLAG in CP area, but in > current > checkpoint, we have persisted all quota file's data, quota files are > consistent > with all other files in filesystem, why we can't remove this NEED_FSCK > flag..? I said it's subtle. So, I guessed 1) set CP_QUOTA_NEED_FSCK_FLAG, 2) clear >>> >>> I know it's subtle... and I agreed we can fix it like this in upstream >>> first, but in our product, it's not rare that we hit the >>> QUOTA_SKIP_FLUSH(its value is 4) case, later we may encounter long latency >>> caused by quota repairing of fsck. >>> SBI_QUOTA_SKIP_FLUSH by checkpoint, 3) clear CP_QUOTA_NEED_FSCK_FLAG by another checkpoint? >>> >>> But later if QUOTA_NEED_REPAIR is set, we will set QUOTA_NEED_FSCK_FLAG >>> again, right? >>> >>> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) >>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >>> >>> >>> So in order to figure out whether this is caused by out-of-order execution >>> of below assignments: >>> >>> if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) >>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >>> else >>> __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- clear >>> flag later >>> >>> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) >>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- set flag >>> first >>> >>> >>> Could you have a try: >>> >>> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR) || >>> is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) >>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >>> else >>> __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >> >> What does this mean? I'm in doubt we have a missing case where we clear this > > Cpu pipeline / compiler can make code out-of-order execution, which means: > > a = 1; > b = 2; > > may actually be executed as the order of: > > b = 2; > a = 1; > > So I doubt that below two line codes can be executed out-of-order: > > else > __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- clear flag later > > if () > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- set flag first > >> flag, CP_QUOTA_NEED_FSCK_FLAG. > > Agreed, I've checked each operation in f2fs_quota_operations yesterday, and > didn't find any missing places yet... Oh, I mean the place where set SBI_QUOTA_NEED_REPAIR, I also doubt we missed to set the flag. Thanks, > > Thanks, > >> >>> >>> Thanks, >>> > > Thanks, > >> >> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) >> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >> . >> >> . >> > > > > ___ > Linux-f2fs-devel mailing list > linux-f2fs-de...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > . >
Re: [f2fs-dev] [PATCH] f2fs: don't clear CP_QUOTA_NEED_FSCK_FLAG
On 2019/2/20 15:08, Jaegeuk Kim wrote: > On 02/18, Chao Yu wrote: >> On 2019/2/16 12:55, Jaegeuk Kim wrote: >>> On 02/13, Chao Yu wrote: On 2019/2/12 10:33, Jaegeuk Kim wrote: > If we met this once, let fsck.f2fs clear this only. > Note that, this addresses all the subtle fault injection test. > > Signed-off-by: Jaegeuk Kim > --- > fs/f2fs/checkpoint.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > index 03fea4efd64b..10a3ada28715 100644 > --- a/fs/f2fs/checkpoint.c > +++ b/fs/f2fs/checkpoint.c > @@ -1267,8 +1267,6 @@ static void update_ckpt_flags(struct f2fs_sb_info > *sbi, struct cp_control *cpc) > > if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > - else > - __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); I didn't get it, previously, if we didn't persist all quota file's data in checkpoint, then we will tag CP_QUOTA_NEED_FSCK_FLAG in CP area, but in current checkpoint, we have persisted all quota file's data, quota files are consistent with all other files in filesystem, why we can't remove this NEED_FSCK flag..? >>> >>> I said it's subtle. So, I guessed 1) set CP_QUOTA_NEED_FSCK_FLAG, 2) clear >> >> I know it's subtle... and I agreed we can fix it like this in upstream >> first, but in our product, it's not rare that we hit the >> QUOTA_SKIP_FLUSH(its value is 4) case, later we may encounter long latency >> caused by quota repairing of fsck. >> >>> SBI_QUOTA_SKIP_FLUSH by checkpoint, 3) clear CP_QUOTA_NEED_FSCK_FLAG by >>> another >>> checkpoint? >> >> But later if QUOTA_NEED_REPAIR is set, we will set QUOTA_NEED_FSCK_FLAG >> again, right? >> >> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) >> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >> >> >> So in order to figure out whether this is caused by out-of-order execution >> of below assignments: >> >> if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) >> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >> else >> __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- clear >> flag later >> >> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) >> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- set flag >> first >> >> >> Could you have a try: >> >> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR) || >> is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) >> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); >> else >> __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > > What does this mean? I'm in doubt we have a missing case where we clear this Cpu pipeline / compiler can make code out-of-order execution, which means: a = 1; b = 2; may actually be executed as the order of: b = 2; a = 1; So I doubt that below two line codes can be executed out-of-order: else __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- clear flag later if () __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- set flag first > flag, CP_QUOTA_NEED_FSCK_FLAG. Agreed, I've checked each operation in f2fs_quota_operations yesterday, and didn't find any missing places yet... Thanks, > >> >> Thanks, >> >>> Thanks, > > if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > >>> >>> . >>> > > . >
REPLY ME
Hello Friend, I'm "Mrs.TAN ROBE" married to Mr. ROBE ( an International Contractor and Oil Merchant/ jointly in Exposition of Agro Equipment ) who died in the Burkina Faso attack, i am 64 years old and diagnosed of cancer for about 2 years ago and my husband informed me that he deposited the sum of (Four Million Seven Hundred Thousand pounds Only) with a BANK in UNITED KINGDOM. I want you to help me to use this money for a charity project before I die, for the Poor, Less-privileged and ORPHANAGES in your country. Please kindly respond quickly for further details. Yours fairly friend, Mrs. TAN ROBE
[REPOST PATCH v4 3/3] scsi: ufs-bsg: Allow reading descriptors
Add this functionality, placing the descriptor being read in the actual
data buffer in the bio.
That is, for both read and write descriptors query upiu, we are using
the job's request_payload. This in turn, is mapped back in user land to
the applicable sg_io_v4 xferp: dout_xferp for write descriptor,
and din_xferp for read descriptor.
Signed-off-by: Avri Altman
Reviewed-by: Evan Green
Reviewed-by: Bean Huo
---
Documentation/scsi/ufs.txt | 7 ++-
drivers/scsi/ufs/ufs_bsg.c | 20
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/Documentation/scsi/ufs.txt b/Documentation/scsi/ufs.txt
index 78fe7cb..1769f71 100644
--- a/Documentation/scsi/ufs.txt
+++ b/Documentation/scsi/ufs.txt
@@ -150,9 +150,14 @@ send SG_IO with the applicable sg_io_v4:
if (dir == SG_DXFER_TO_DEV) {
io_hdr_v4.dout_xfer_len = (uint32_t)byte_cnt;
io_hdr_v4.dout_xferp = (uintptr_t)(__u64)buff;
+ } else {
+ io_hdr_v4.din_xfer_len = (uint32_t)byte_cnt;
+ io_hdr_v4.din_xferp = (uintptr_t)(__u64)buff;
}
-If you wish to write a descriptor, use the dout_xferp sg_io_v4.
+If you wish to read or write a descriptor, use the appropriate xferp of
+sg_io_v4.
+
UFS Specifications can be found at,
UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 2fd0769..869e71f 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -48,12 +48,8 @@ static int ufs_bsg_alloc_desc_buffer(struct ufs_hba *hba,
struct bsg_job *job,
struct utp_upiu_query *qr;
u8 *descp;
- if (desc_op == UPIU_QUERY_OPCODE_READ_DESC) {
- dev_err(hba->dev, "unsupported opcode %d\n", desc_op);
- return -ENOTSUPP;
- }
-
- if (desc_op != UPIU_QUERY_OPCODE_WRITE_DESC)
+ if (desc_op != UPIU_QUERY_OPCODE_WRITE_DESC &&
+ desc_op != UPIU_QUERY_OPCODE_READ_DESC)
goto out;
qr = _request->upiu_req.qr;
@@ -71,8 +67,10 @@ static int ufs_bsg_alloc_desc_buffer(struct ufs_hba *hba,
struct bsg_job *job,
if (!descp)
return -ENOMEM;
- sg_copy_to_buffer(job->request_payload.sg_list,
- job->request_payload.sg_cnt, descp, *desc_len);
+ if (desc_op == UPIU_QUERY_OPCODE_WRITE_DESC)
+ sg_copy_to_buffer(job->request_payload.sg_list,
+ job->request_payload.sg_cnt, descp,
+ *desc_len);
*desc_buff = descp;
@@ -140,6 +138,12 @@ static int ufs_bsg_request(struct bsg_job *job)
if (!desc_buff)
goto out;
+ if (desc_op == UPIU_QUERY_OPCODE_READ_DESC && desc_len)
+ bsg_reply->reply_payload_rcv_len =
+ sg_copy_from_buffer(job->request_payload.sg_list,
+ job->request_payload.sg_cnt,
+ desc_buff, desc_len);
+
kfree(desc_buff);
out:
--
1.9.1
[REPOST PATCH v4 2/3] scsi: ufs: Allow reading descriptor via raw upiu
Allow to read descriptors via raw upiu. This in fact was forbidden just
as a precaution, as ufs-bsg actually enforces which functionality is
supported.
Signed-off-by: Avri Altman
Reviewed-by: Evan Green
Reviewed-by: Bean Huo
---
drivers/scsi/ufs/ufshcd.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 5ca4581..7b5b601 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5780,6 +5780,20 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba
*hba,
/* just copy the upiu response as it is */
memcpy(rsp_upiu, lrbp->ucd_rsp_ptr, sizeof(*rsp_upiu));
+ if (desc_buff && desc_op == UPIU_QUERY_OPCODE_READ_DESC) {
+ u8 *descp = (u8 *)lrbp->ucd_rsp_ptr + sizeof(*rsp_upiu);
+ u16 resp_len = be32_to_cpu(lrbp->ucd_rsp_ptr->header.dword_2) &
+ MASK_QUERY_DATA_SEG_LEN;
+
+ if (*buff_len >= resp_len) {
+ memcpy(desc_buff, descp, resp_len);
+ *buff_len = resp_len;
+ } else {
+ dev_warn(hba->dev, "rsp size is bigger than buffer");
+ *buff_len = 0;
+ err = -EINVAL;
+ }
+ }
ufshcd_put_dev_cmd_tag(hba, tag);
wake_up(>dev_cmd.tag_wq);
@@ -5815,11 +5829,6 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
int ocs_value;
u8 tm_f = be32_to_cpu(req_upiu->header.dword_1) >> 16 & MASK_TM_FUNC;
- if (desc_buff && desc_op != UPIU_QUERY_OPCODE_WRITE_DESC) {
- err = -ENOTSUPP;
- goto out;
- }
-
switch (msgcode) {
case UPIU_TRANSACTION_NOP_OUT:
cmd_type = DEV_CMD_TYPE_NOP;
@@ -5860,7 +5869,6 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
break;
}
-out:
return err;
}
--
1.9.1
[REPOST PATCH v4 1/3] scsi: ufs-bsg: Change the calling convention for write descriptor
When we had a write descriptor query upiu, we appended the descriptor
right after the bsg request. This was fine as the bsg driver allows to
allocate whatever buffer we needed in its job request.
Still, the proper way to deliver payload, however small (we only write
config descriptors of 144 bytes), is by using the job request payload
data buffer.
So change this ABI now, while ufs-bsg is still new, and nobody is
actually using it.
Signed-off-by: Avri Altman
Reviewed-by: Evan Green
Reviewed-by: Bean Huo
---
Documentation/scsi/ufs.txt | 6 ++
drivers/scsi/ufs/ufs_bsg.c | 47 +-
2 files changed, 32 insertions(+), 21 deletions(-)
diff --git a/Documentation/scsi/ufs.txt b/Documentation/scsi/ufs.txt
index 520b5b0..78fe7cb 100644
--- a/Documentation/scsi/ufs.txt
+++ b/Documentation/scsi/ufs.txt
@@ -147,6 +147,12 @@ send SG_IO with the applicable sg_io_v4:
io_hdr_v4.max_response_len = reply_len;
io_hdr_v4.request_len = request_len;
io_hdr_v4.request = (__u64)request_upiu;
+ if (dir == SG_DXFER_TO_DEV) {
+ io_hdr_v4.dout_xfer_len = (uint32_t)byte_cnt;
+ io_hdr_v4.dout_xferp = (uintptr_t)(__u64)buff;
+ }
+
+If you wish to write a descriptor, use the dout_xferp sg_io_v4.
UFS Specifications can be found at,
UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 775bb4e..2fd0769 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -27,15 +27,11 @@ static int ufs_bsg_get_query_desc_size(struct ufs_hba *hba,
int *desc_len,
static int ufs_bsg_verify_query_size(struct ufs_hba *hba,
unsigned int request_len,
-unsigned int reply_len,
-int desc_len, enum query_opcode desc_op)
+unsigned int reply_len)
{
int min_req_len = sizeof(struct ufs_bsg_request);
int min_rsp_len = sizeof(struct ufs_bsg_reply);
- if (desc_op == UPIU_QUERY_OPCODE_WRITE_DESC)
- min_req_len += desc_len;
-
if (min_req_len > request_len || min_rsp_len > reply_len) {
dev_err(hba->dev, "not enough space assigned\n");
return -EINVAL;
@@ -44,14 +40,13 @@ static int ufs_bsg_verify_query_size(struct ufs_hba *hba,
return 0;
}
-static int ufs_bsg_verify_query_params(struct ufs_hba *hba,
- struct ufs_bsg_request *bsg_request,
- unsigned int request_len,
- unsigned int reply_len,
- uint8_t *desc_buff, int *desc_len,
- enum query_opcode desc_op)
+static int ufs_bsg_alloc_desc_buffer(struct ufs_hba *hba, struct bsg_job *job,
+uint8_t **desc_buff, int *desc_len,
+enum query_opcode desc_op)
{
+ struct ufs_bsg_request *bsg_request = job->request;
struct utp_upiu_query *qr;
+ u8 *descp;
if (desc_op == UPIU_QUERY_OPCODE_READ_DESC) {
dev_err(hba->dev, "unsupported opcode %d\n", desc_op);
@@ -67,11 +62,19 @@ static int ufs_bsg_verify_query_params(struct ufs_hba *hba,
return -EINVAL;
}
- if (ufs_bsg_verify_query_size(hba, request_len, reply_len, *desc_len,
- desc_op))
+ if (*desc_len > job->request_payload.payload_len) {
+ dev_err(hba->dev, "Illegal desc size\n");
return -EINVAL;
+ }
+
+ descp = kzalloc(*desc_len, GFP_KERNEL);
+ if (!descp)
+ return -ENOMEM;
- desc_buff = (uint8_t *)(bsg_request + 1);
+ sg_copy_to_buffer(job->request_payload.sg_list,
+ job->request_payload.sg_cnt, descp, *desc_len);
+
+ *desc_buff = descp;
out:
return 0;
@@ -91,7 +94,7 @@ static int ufs_bsg_request(struct bsg_job *job)
enum query_opcode desc_op = UPIU_QUERY_OPCODE_NOP;
int ret;
- ret = ufs_bsg_verify_query_size(hba, req_len, reply_len, 0, desc_op);
+ ret = ufs_bsg_verify_query_size(hba, req_len, reply_len);
if (ret)
goto out;
@@ -101,9 +104,8 @@ static int ufs_bsg_request(struct bsg_job *job)
switch (msgcode) {
case UPIU_TRANSACTION_QUERY_REQ:
desc_op = bsg_request->upiu_req.qr.opcode;
- ret = ufs_bsg_verify_query_params(hba, bsg_request, req_len,
- reply_len, desc_buff,
- _len, desc_op);
+ ret = ufs_bsg_alloc_desc_buffer(hba, job, _buff,
+ _len, desc_op);
if (ret)
Re: [PATCH] KVM: MMU: record maximum physical address width in kvm_mmu_extended_role
Hi Paolo, any comments on this patch? And the other one(kvm: x86: Return
LA57 feature based on hardware capability )? :-)
On Fri, Feb 01, 2019 at 12:09:23AM +0800, Yu Zhang wrote:
> Previously, commit 7dcd57552008 ("x86/kvm/mmu: check if tdp/shadow
> MMU reconfiguration is needed") offered some optimization to avoid
> the unnecessary reconfiguration. Yet one scenario is broken - when
> cpuid changes VM's maximum physical address width, reconfiguration
> is needed to reset the reserved bits. Also, the TDP may need to
> reset its shadow_root_level when this value is changed.
>
> To fix this, a new field, maxphyaddr, is introduced in the extended
> role structure to keep track of the configured guest physical address
> width.
>
> Signed-off-by: Yu Zhang
> ---
> Cc: Paolo Bonzini
> Cc: "Radim Krčmář"
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/x86/include/asm/kvm_host.h | 1 +
> arch/x86/kvm/mmu.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 4660ce9..be87f71 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -299,6 +299,7 @@ struct kvm_mmu_memory_cache {
> unsigned int cr4_smap:1;
> unsigned int cr4_smep:1;
> unsigned int cr4_la57:1;
> + unsigned int maxphyaddr:6;
> };
> };
>
> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
> index ce770b4..2b74505 100644
> --- a/arch/x86/kvm/mmu.c
> +++ b/arch/x86/kvm/mmu.c
> @@ -4769,6 +4769,7 @@ static union kvm_mmu_extended_role
> kvm_calc_mmu_role_ext(struct kvm_vcpu *vcpu)
> ext.cr4_pse = !!is_pse(vcpu);
> ext.cr4_pke = !!kvm_read_cr4_bits(vcpu, X86_CR4_PKE);
> ext.cr4_la57 = !!kvm_read_cr4_bits(vcpu, X86_CR4_LA57);
> + ext.maxphyaddr = cpuid_maxphyaddr(vcpu);
>
> ext.valid = 1;
>
> --
> 1.9.1
>
Thanks
Yu
[REPOST PATCH v4 0/3] scsi: ufs-bsg: Add read descriptor
UFS Protocol Information Units (UPIU) are UFS packets that travel between the host and the device on the UniPro bus. Our previous series added the capability to send UPIUs to the ufs driver. It does not cover all the possible UPIU types - we are mainly focused on device management, provisioning, testing and validation, so it covers UPIUs that falls in that box. Our intension is to publish ufs-utils soon - an open source user space utility that relies on that infrastructure to perform those tasks. This short series is adding one last functionality needed by ufs-utils that was somehow left behind - allowing reading descriptors as well. Repost of v4 and adds tags already received. While at it, it turns out that quite a few people are waiting for ufs-utils, e.g. https://www.spinics.net/lists/linux-scsi/msg127807.html. So I expect that the small, but vibrant community of ufs users, will try to expand this infrastructure even further. V3->v4: Improve code readability in ufs-bsg: Allow reading descriptors Update Reviewed-by tag. V2->v3: Add a prep patch with write descriptor calling convention changes. Elaborate the commit log of ufs-bsg: Allow reading descriptors Add Reviewed-by tag. v1->v2: Withdraw from the attempt to change the reply buffer, instead place the descriptor being read in the actual data buffer in the bio. Avri Altman (3): scsi: ufs-bsg: Change the calling convention for write descriptor scsi: ufs: Allow reading descriptor via raw upiu scsi: ufs-bsg: Allow reading descriptors Documentation/scsi/ufs.txt | 11 drivers/scsi/ufs/ufs_bsg.c | 63 ++ drivers/scsi/ufs/ufshcd.c | 20 ++- 3 files changed, 61 insertions(+), 33 deletions(-) -- 1.9.1
Re: [PATCH] xsysace: Fix error handling in ace_setup
On 19. 02. 19 17:49, Guenter Roeck wrote:
> If xace hardware reports a bad version number, the error handling code
> in ace_setup() calls put_disk(), followed by queue cleanup. However, since
> the disk data structure has the queue pointer set, put_disk() also
> cleans and releases the queue. This results in blk_cleanup_queue()
> accessing an already released data structure, which in turn may result
> in a crash such as the following.
>
> [ 10.681671] BUG: Kernel NULL pointer dereference at 0x0040
> [ 10.681826] Faulting instruction address: 0xc0431480
> [ 10.682072] Oops: Kernel access of bad area, sig: 11 [#1]
> [ 10.682251] BE PAGE_SIZE=4K PREEMPT Xilinx Virtex440
> [ 10.682387] Modules linked in:
> [ 10.682528] CPU: 0 PID: 1 Comm: swapper Tainted: GW
> 5.0.0-rc6-next-20190218+ #2
> [ 10.682733] NIP: c0431480 LR: c043147c CTR: c0422ad8
> [ 10.682863] REGS: cf82fbe0 TRAP: 0300 Tainted: GW
> (5.0.0-rc6-next-20190218+)
> [ 10.683065] MSR: 00029000 CR: 22000222 XER:
> [ 10.683236] DEAR: 0040 ESR:
> [ 10.683236] GPR00: c043147c cf82fc90 cf82ccc0
> 0002
> [ 10.683236] GPR08: c04310bc 22000222
> c0002c54
> [ 10.683236] GPR16: 0001 c09aa39c c09021b0 c09021dc 0007
> c0a68c08
> [ 10.683236] GPR24: 0001 ced6d400 ced6dcf0 c0815d9c
> cedf0800
> [ 10.684331] NIP [c0431480] blk_mq_run_hw_queue+0x28/0x114
> [ 10.684473] LR [c043147c] blk_mq_run_hw_queue+0x24/0x114
> [ 10.684602] Call Trace:
> [ 10.684671] [cf82fc90] [c043147c] blk_mq_run_hw_queue+0x24/0x114
> (unreliable)
> [ 10.684854] [cf82fcc0] [c04315bc] blk_mq_run_hw_queues+0x50/0x7c
> [ 10.685002] [cf82fce0] [c0422b24] blk_set_queue_dying+0x30/0x68
> [ 10.685154] [cf82fcf0] [c0423ec0] blk_cleanup_queue+0x34/0x14c
> [ 10.685306] [cf82fd10] [c054d73c] ace_probe+0x3dc/0x508
> [ 10.685445] [cf82fd50] [c052d740] platform_drv_probe+0x4c/0xb8
> [ 10.685592] [cf82fd70] [c052abb0] really_probe+0x20c/0x32c
> [ 10.685728] [cf82fda0] [c052ae58] driver_probe_device+0x68/0x464
> [ 10.685877] [cf82fdc0] [c052b500] device_driver_attach+0xb4/0xe4
> [ 10.686024] [cf82fde0] [c052b5dc] __driver_attach+0xac/0xfc
> [ 10.686161] [cf82fe00] [c0528428] bus_for_each_dev+0x80/0xc0
> [ 10.686314] [cf82fe30] [c0529b3c] bus_add_driver+0x144/0x234
> [ 10.686457] [cf82fe50] [c052c46c] driver_register+0x88/0x15c
> [ 10.686610] [cf82fe60] [c09de288] ace_init+0x4c/0xac
> [ 10.686742] [cf82fe80] [c0002730] do_one_initcall+0xac/0x330
> [ 10.686888] [cf82fee0] [c09aafd0] kernel_init_freeable+0x34c/0x478
> [ 10.687043] [cf82ff30] [c0002c6c] kernel_init+0x18/0x114
> [ 10.687188] [cf82ff40] [c000f2f0] ret_from_kernel_thread+0x14/0x1c
> [ 10.687349] Instruction dump:
> [ 10.687435] 3863ffd4 4bfffd70 9421ffd0 7c0802a6 93c10028 7c9e2378 93e1002c
> 38810008
> [ 10.687637] 7c7f1b78 90010034 4bfffc25 813f008c <81290040> 75290100
> 4182002c 80810008
> [ 10.688056] ---[ end trace 13c9ff51d41b9d40 ]---
>
> Fix the problem by setting the disk queue pointer to NULL before calling
> put_disk(). A more comprehensive fix might be to rearrange the code
> to check the hardware version before initializing data structures,
> but I don't know if this would have undesirable side effects, and
> it would increase the complexity of backporting the fix to older kernels.
>
> Fixes: 74489a91dd43a ("Add support for Xilinx SystemACE CompactFlash
> interface")
> Signed-off-by: Guenter Roeck
> ---
> drivers/block/xsysace.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/block/xsysace.c b/drivers/block/xsysace.c
> index 87ccef4bd69e..32a21b8d1d85 100644
> --- a/drivers/block/xsysace.c
> +++ b/drivers/block/xsysace.c
> @@ -1090,6 +1090,8 @@ static int ace_setup(struct ace_device *ace)
> return 0;
>
> err_read:
> + /* prevent double queue cleanup */
> + ace->gd->queue = NULL;
> put_disk(ace->gd);
> err_alloc_disk:
> blk_cleanup_queue(ace->queue);
>
This driver is quite old and we are not actively using/testing it.
Are you wiring that up with qemu?
Maybe it should be labeled differently in MAINTAINERS file.
Anyway whatever fix is fine for me.
Acked-by: Michal Simek
Thanks,
Michal
Re: [f2fs-dev] [PATCH] f2fs: don't clear CP_QUOTA_NEED_FSCK_FLAG
On 02/18, Chao Yu wrote: > On 2019/2/16 12:55, Jaegeuk Kim wrote: > > On 02/13, Chao Yu wrote: > >> On 2019/2/12 10:33, Jaegeuk Kim wrote: > >>> If we met this once, let fsck.f2fs clear this only. > >>> Note that, this addresses all the subtle fault injection test. > >>> > >>> Signed-off-by: Jaegeuk Kim > >>> --- > >>> fs/f2fs/checkpoint.c | 2 -- > >>> 1 file changed, 2 deletions(-) > >>> > >>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c > >>> index 03fea4efd64b..10a3ada28715 100644 > >>> --- a/fs/f2fs/checkpoint.c > >>> +++ b/fs/f2fs/checkpoint.c > >>> @@ -1267,8 +1267,6 @@ static void update_ckpt_flags(struct f2fs_sb_info > >>> *sbi, struct cp_control *cpc) > >>> > >>> if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) > >>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > >>> - else > >>> - __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > >> > >> I didn't get it, previously, if we didn't persist all quota file's data in > >> checkpoint, then we will tag CP_QUOTA_NEED_FSCK_FLAG in CP area, but in > >> current > >> checkpoint, we have persisted all quota file's data, quota files are > >> consistent > >> with all other files in filesystem, why we can't remove this NEED_FSCK > >> flag..? > > > > I said it's subtle. So, I guessed 1) set CP_QUOTA_NEED_FSCK_FLAG, 2) clear > > I know it's subtle... and I agreed we can fix it like this in upstream > first, but in our product, it's not rare that we hit the > QUOTA_SKIP_FLUSH(its value is 4) case, later we may encounter long latency > caused by quota repairing of fsck. > > > SBI_QUOTA_SKIP_FLUSH by checkpoint, 3) clear CP_QUOTA_NEED_FSCK_FLAG by > > another > > checkpoint? > > But later if QUOTA_NEED_REPAIR is set, we will set QUOTA_NEED_FSCK_FLAG > again, right? > > if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > > > So in order to figure out whether this is caused by out-of-order execution > of below assignments: > > if (is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > else > __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- clear > flag later > > if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); --- set flag > first > > > Could you have a try: > > if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR) || > is_sbi_flag_set(sbi, SBI_QUOTA_SKIP_FLUSH)) > __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > else > __clear_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); What does this mean? I'm in doubt we have a missing case where we clear this flag, CP_QUOTA_NEED_FSCK_FLAG. > > Thanks, > > > > >> > >> Thanks, > >> > >>> > >>> if (is_sbi_flag_set(sbi, SBI_QUOTA_NEED_REPAIR)) > >>> __set_ckpt_flags(ckpt, CP_QUOTA_NEED_FSCK_FLAG); > >>> > > > > . > >
Re: linux-next: Fixes tag needs some work in the kvm tree
Thanks for the notification, Stephen.
@Paolo, should I resubmit the patch to correct?
On Sat, Feb 16, 2019 at 06:34:33PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> aa8359972cfc ("KVM: x86/mmu: Differentiate between nr zapped and list
> unstable")
>
> Fixes tag
>
> Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return
>
> has these problem(s):
>
> - Subject has leading but no trailing quotes
> Please do not split Fixes tags over more than one line
>
> In commit
>
> 4d3f8e4ff75e ("kvm: vmx: Fix typos in vmentry/vmexit control setting")
>
> Fixes tag
>
> Fixes: 'commit f99e3daf94ff ("KVM: x86: Add Intel PT virtualization work
> mode")'
>
> has these problem(s):
>
> - No SHA1 recognised
> The leading word 'commit' is unexpected and the surrounding single
> quotes likewise.
> Please just use
> git log -1 --format='Fixes: %h ("%s")'
>
> --
> Cheers,
> Stephen Rothwell
B.R.
Yu
Re: [PATCH] MAINTAINERS: add linux-security-module mailing list to TPM drivers
On Tue, Feb 19, 2019 at 08:58:46PM -0700, Jerry Snitselaar wrote: > I've seen requests to add linux-security-module to tpm patch > submissions a couple of times recently, so just add the list > to MAINTAINERS so get_maintainers.pl will mention it. > > Cc: Peter Huewe > Cc: Jarkko Sakkinen > Cc: Jason Gunthorpe > Signed-off-by: Jerry Snitselaar I guess James should say something about this. /Jarkko
Re: [RFC PATCH 00/27] Containers and using authenticated filesystems
On Tue, Feb 19, 2019 at 6:42 PM David Howells wrote: > Eric W. Biederman wrote: ... > > Looking at your description you are introducing a container id. > > Yes. For audit logging, which was why I cc'd Richard. Not to pile on, but it is more important to CC the audit mailing list. You can obviously still CC Richard, but you should send it to the entire mailing list. -- paul moore www.paul-moore.com
Re: [PATCH RESEND net] net: phy: xgmiitorgmii: Support generic PHY status read
Hi, On 19. 02. 19 18:25, Andrew Lunn wrote: >> Thanks for the suggestion! So I had a closer look at that driver to try >> and see what could go wrong and it looks like I found a few things >> there. > > Hi Paul > > Yes, this driver has issues. If i remember correctly, it got merged > while i was on vacation. I pointed out a few issues, but the authors > never responded. Feel free to fix it up. Will be good to know who was that person. I can't do much this week with this because responsible person for this driver is out of office this week. That's why please give us some time to get back to this. Thanks, Michal
Re: [RFC PATCH 02/27] containers: Implement containers as kernel objects
On Tue, Feb 19, 2019 at 10:46 PM James Bottomley wrote: > On Wed, 2019-02-20 at 11:04 +0800, Ian Kent wrote: > > On Tue, 2019-02-19 at 18:20 -0800, James Bottomley wrote: > > > On Tue, 2019-02-19 at 23:06 +, David Howells wrote: > > > > James Bottomley wrote: > > > > > > > > > I thought we got agreement years ago that containers don't > > > > > exist in Linux as a single entity: they're currently a > > > > > collection of cgroups and namespaces some of which may and some > > > > > of which may not be local to the entity the orchestration > > > > > system thinks of as a "container". > > > > > > > > I wasn't party to that agreement and don't feel particularly > > > > bound by it. > > > > > > That's not at all relevant, is it? The point is we have widespread > > > uses of namespaces and cgroups that span containers today meaning > > > that a "container id" becomes a problematic concept. What we > > > finally got to with the audit people was an unmodifiable label > > > which the orchestration system can set ... can't you just use that? > > > > Sorry James, I fail to see how assigning an id to a collection of > > objects constitutes a problem or how that could restrict the way a > > container is used. > > Rather than rehash the whole argument again, what's the reason you > can't use the audit label? It seems to do what you want in a way that > doesn't cause problems. If you can just use it there's little point > arguing over what is effectively a moot issue. Ignoring for a moment whether or not the audit container ID is applicable here, one of the things I've been focused on with the audit container ID work is trying to make it difficult for other subsystems to use it. I've taken this stance not because I don't think something like a container ID would be useful outside the audit subsystem, but rather because I'm afraid of how it might be abused by other subsystems and that abuse might threaten the existence of the audit container ID. If there is a willingness to implement a general kernel container ID that behaves similarly to how the audit container ID is envisioned, I'd much rather do that then implement something which is audit specific. -- paul moore www.paul-moore.com
Re: [PATCH v2 5/5] base: soc: Export soc_device_register/unregister APIs
On Wed, Feb 20, 2019 at 10:29:46AM +0530, Vaishali Thakkar wrote: > From: Vinod Koul > > Qcom Socinfo driver can be built as a module, so > export these two APIs. > > Signed-off-by: Vinod Koul > Signed-off-by: Vaishali Thakkar > --- > Changes since v1: > - None This is fixing a build breakage introduced by an earlier patch. Please rearange the patches so that breakage never happens. Also, any chance you can properly "thread" your patches so they all show up together? git send-email does this automatically... thanks, greg k-h
[PATCH V7 4/4] arm64: dts: imx: add i.MX8QXP thermal support
Add i.MX8QXP CPU thermal zone support.
Signed-off-by: Anson Huang
---
Changes since V6:
- add fallback compatible string "fsl,imx-sc-thermal" according to i.MX
SC thermal driver
update.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 28
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 4c3dd95..24b03d6 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
/ {
interrupt-parent = <>;
@@ -116,6 +117,12 @@
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal",
"fsl,imx-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+ };
};
timer {
@@ -443,4 +450,25 @@
power-domains = < IMX_SC_R_GPIO_7>;
};
};
+
+ thermal_zones: thermal-zones {
+ cpu-thermal0 {
+ polling-delay-passive = <250>;
+ polling-delay = <2000>;
+ thermal-sensors = < 0>;
+ imx,sensor-resource-id = <355>;
+ trips {
+ cpu_alert0: trip0 {
+ temperature = <107000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+ cpu_crit0: trip1 {
+ temperature = <127000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+ };
+ };
};
--
2.7.4
Re: [PATCH v2] powerpc/prom_init: add __init markers to all functions
Le 20/02/2019 à 06:53, Masahiro Yamada a écrit :
It is fragile to rely on the compiler's optimization to avoid the
section mismatch. Some functions may not be necessarily inlined
when the compiler's inlining heuristic changes.
Add __init markers consistently.
As for prom_getprop() and prom_getproplen(), they are marked as
'inline', so inlining is guaranteed because PowerPC never enables
CONFIG_OPTIMIZE_INLINING. However, it would be better to leave the
inlining decision to the compiler. I replaced 'inline' with __init.
I added __maybe_unused to prom_getproplen() because it is currently
relying on the side-effect of 'inline'; GCC does not report
-Wunused-function warnings for functions with 'inline' marker.
__maybe_unused is really a bad trick that should be avoided, as it hides
unused functions.
Why is it a problem to keep prom_getproplen() as 'static inline' ? Most
small helpers are defined that way. Usually they are in an included
header file, but what's really the problem with having it here directly ?
Christophe
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Add __maybe_unsed to prom_getproplen()
- Add __init to enter_prom() as well
arch/powerpc/kernel/prom_init.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index f33ff41..1bad0ac 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -138,9 +138,9 @@ extern void __start(unsigned long r3, unsigned long r4,
unsigned long r5,
unsigned long r9);
#ifdef CONFIG_PPC64
-extern int enter_prom(struct prom_args *args, unsigned long entry);
+extern int __init enter_prom(struct prom_args *args, unsigned long entry);
#else
-static inline int enter_prom(struct prom_args *args, unsigned long entry)
+static int __init enter_prom(struct prom_args *args, unsigned long entry)
{
return ((int (*)(struct prom_args *))entry)(args);
}
@@ -501,19 +501,20 @@ static int __init prom_next_node(phandle *nodep)
}
}
-static inline int prom_getprop(phandle node, const char *pname,
+static int __init prom_getprop(phandle node, const char *pname,
void *value, size_t valuelen)
{
return call_prom("getprop", 4, 1, node, ADDR(pname),
(u32)(unsigned long) value, (u32) valuelen);
}
-static inline int prom_getproplen(phandle node, const char *pname)
+static int __init __maybe_unused prom_getproplen(phandle node,
+const char *pname)
{
return call_prom("getproplen", 2, 1, node, ADDR(pname));
}
-static void add_string(char **str, const char *q)
+static void __init add_string(char **str, const char *q)
{
char *p = *str;
@@ -523,7 +524,7 @@ static void add_string(char **str, const char *q)
*str = p;
}
-static char *tohex(unsigned int x)
+static char __init *tohex(unsigned int x)
{
static const char digits[] __initconst = "0123456789abcdef";
static char result[9] __prombss;
@@ -570,7 +571,7 @@ static int __init prom_setprop(phandle node, const char
*nodename,
#define islower(c)('a' <= (c) && (c) <= 'z')
#define toupper(c)(islower(c) ? ((c) - 'a' + 'A') : (c))
-static unsigned long prom_strtoul(const char *cp, const char **endp)
+static unsigned long __init prom_strtoul(const char *cp, const char **endp)
{
unsigned long result = 0, base = 10, value;
@@ -595,7 +596,7 @@ static unsigned long prom_strtoul(const char *cp, const char **endp)
return result;
}
-static unsigned long prom_memparse(const char *ptr, const char **retptr)
+static unsigned long __init prom_memparse(const char *ptr, const char **retptr)
{
unsigned long ret = prom_strtoul(ptr, retptr);
int shift = 0;
@@ -2924,7 +2925,7 @@ static void __init fixup_device_tree_pasemi(void)
prom_setprop(iob, name, "device_type", "isa", sizeof("isa"));
}
#else /* !CONFIG_PPC_PASEMI_NEMO */
-static inline void fixup_device_tree_pasemi(void) { }
+static void __init fixup_device_tree_pasemi(void) { }
#endif
static void __init fixup_device_tree(void)
@@ -2986,15 +2987,15 @@ static void __init prom_check_initrd(unsigned long r3,
unsigned long r4)
#ifdef CONFIG_PPC64
#ifdef CONFIG_RELOCATABLE
-static void reloc_toc(void)
+static void __init reloc_toc(void)
{
}
-static void unreloc_toc(void)
+static void __init unreloc_toc(void)
{
}
#else
-static void __reloc_toc(unsigned long offset, unsigned long nr_entries)
+static void __init __reloc_toc(unsigned long offset, unsigned long nr_entries)
{
unsigned long i;
unsigned long *toc_entry;
@@ -3008,7 +3009,7 @@ static void __reloc_toc(unsigned long offset, unsigned
long nr_entries)
}
}
-static void reloc_toc(void)
+static void __init reloc_toc(void)
{
[PATCH V7 3/4] defconfig: arm64: add i.MX system controller thermal support
This patch enables CONFIG_IMX_SC_THERMAL as module. Signed-off-by: Anson Huang --- No changes since V6. --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2d9c390..52d503e 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -413,6 +413,7 @@ CONFIG_SENSORS_INA2XX=m CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y CONFIG_CPU_THERMAL=y CONFIG_THERMAL_EMULATION=y +CONFIG_IMX_SC_THERMAL=m CONFIG_ROCKCHIP_THERMAL=m CONFIG_RCAR_THERMAL=y CONFIG_RCAR_GEN3_THERMAL=y -- 2.7.4
[PATCH V7 2/4] thermal: imx_sc: add i.MX system controller thermal support
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and thermal sensors etc..
This patch adds i.MX system controller thermal driver support,
Linux kernel has to communicate with system controller via MU
(message unit) IPC to get each thermal sensor's temperature,
it supports multiple sensors which are passed from device tree,
please see the binding doc for details.
Signed-off-by: Anson Huang
---
Changes since V6:
- use "fsl,imx-sc-thermal" compatible to make SC thermal driver more
generic for other i.MX8 SoCs
with system controller inside.
---
drivers/thermal/Kconfig | 11 +++
drivers/thermal/Makefile | 1 +
drivers/thermal/imx_sc_thermal.c | 161 +++
3 files changed, 173 insertions(+)
create mode 100644 drivers/thermal/imx_sc_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 58bb7d7..fec0ef5 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -223,6 +223,17 @@ config IMX_THERMAL
cpufreq is used as the cooling device to throttle CPUs when the
passive trip is crossed.
+config IMX_SC_THERMAL
+ tristate "Temperature sensor driver for NXP i.MX SoCs with System
Controller"
+ depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
+ depends on OF
+ help
+ Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
+ system controller inside, Linux kernel has to communicate with system
+ controller via MU (message unit) IPC to get temperature from thermal
+ sensor. It supports one critical trip point and one
+ passive trip point for each thermal sensor.
+
config MAX77620_THERMAL
tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
depends on MFD_MAX77620
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 486d682..4062627 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o
obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
obj-$(CONFIG_TANGO_THERMAL)+= tango_thermal.o
obj-$(CONFIG_IMX_THERMAL) += imx_thermal.o
+obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
obj-$(CONFIG_QORIQ_THERMAL)+= qoriq_thermal.o
obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
diff --git a/drivers/thermal/imx_sc_thermal.c b/drivers/thermal/imx_sc_thermal.c
new file mode 100644
index 000..1a8b978
--- /dev/null
+++ b/drivers/thermal/imx_sc_thermal.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2018-2019 NXP.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "thermal_core.h"
+
+#define IMX_SC_MISC_FUNC_GET_TEMP 13
+#define IMX_SC_C_TEMP 0
+
+static struct imx_sc_ipc *thermal_ipc_handle;
+
+struct imx_sc_sensor {
+ struct thermal_zone_device *tzd;
+ u32 resource_id;
+};
+
+struct imx_sc_thermal_data {
+ struct imx_sc_sensor *sensor;
+};
+
+struct req_get_temp {
+ u16 resource_id;
+ u8 type;
+} __packed;
+
+struct resp_get_temp {
+ u16 celsius;
+ u8 tenths;
+} __packed;
+
+struct imx_sc_msg_misc_get_temp {
+ struct imx_sc_rpc_msg hdr;
+ union {
+ struct req_get_temp req;
+ struct resp_get_temp resp;
+ } data;
+} __packed;
+
+static int imx_sc_thermal_get_temp(void *data, int *temp)
+{
+ struct imx_sc_msg_misc_get_temp msg;
+ struct imx_sc_rpc_msg *hdr =
+ struct imx_sc_sensor *sensor = data;
+ int ret;
+
+ msg.data.req.resource_id = sensor->resource_id;
+ msg.data.req.type = IMX_SC_C_TEMP;
+
+ hdr->ver = IMX_SC_RPC_VERSION;
+ hdr->svc = IMX_SC_RPC_SVC_MISC;
+ hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
+ hdr->size = 2;
+
+ ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
+ if (ret) {
+ pr_err("read temp sensor %d failed, ret %d\n",
+ sensor->resource_id, ret);
+ return ret;
+ }
+
+ *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
+
+ return 0;
+}
+
+static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
+ .get_temp = imx_sc_thermal_get_temp,
+};
+
+static int imx_sc_thermal_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev->dev.of_node;
+ struct device_node *sensor_np = NULL;
+ struct imx_sc_thermal_data *data;
+ struct imx_sc_sensor *sensors;
+ u32 sensor_num;
+ int ret, i;
+
+ ret = imx_scu_get_handle(_ipc_handle);
+ if (ret)
+ return ret;
+
+ data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ ret =
[PATCH V7 1/4] dt-bindings: fsl: scu: add thermal binding
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and thermal sensors etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get temperature from thermal sensors, this patch adds
binding doc for i.MX system controller thermal driver.
Signed-off-by: Anson Huang
Reviewed-by: Rob Herring
---
Changes since V6:
- put "imx,sensor-resource-id" property in thermal zone nodes.
---
.../devicetree/bindings/arm/freescale/fsl,scu.txt | 27 ++
1 file changed, 27 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index 72d481c..ad96881 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -122,6 +122,27 @@ RTC bindings based on SCU Message Protocol
Required properties:
- compatible: should be "fsl,imx8qxp-sc-rtc";
+Thermal bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible : Must be "fsl,imx-sc-thermal";
+- tsens-num : Total number of thermal sensors supported;
+- #thermal-sensor-cells : Should be 1. See
+ Documentation/devicetree/bindings/thermal/thermal.txt
+ for a description.
+
+Required properties for thermal zone nodes:
+- imx,sensor-resource-id : This property should be defined in each thermal zone
+ of thermal-zones node, it passes each thermal zone's
+ resource id for thermal driver to get temperature via
+ SCU IPC.
+
+ For thermal zone nodes, please refer to below binding
+ doc for details:
+
+[1] Documentation/devicetree/bindings/thermal/thermal.txt
+
Example (imx8qxp):
-
lsio_mu1: mailbox@5d1c {
@@ -168,6 +189,12 @@ firmware {
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
+
+ tsens: thermal-sensor {
+ compatible = "fsl,imx8qxp-sc-thermal";
+ tsens-num = <1>;
+ #thermal-sensor-cells = <1>;
+ };
};
};
--
2.7.4
Zdravstvujte vas interesuyut klientskie bazy dannyh?
Zdravstvujte vas interesuyut klientskie bazy dannyh?
Re: [PATCH v2 2/4] crypto: hisilicon: Add queue management driver for HiSilicon QM module
On 2019/2/20 12:10, Herbert Xu wrote: > On Sat, Feb 02, 2019 at 10:25:43AM +0800, Zhou Wang wrote: >> >> In fact, I planned to register to acomp later. >> >> It also makes sense to use scomp if hardware engine is faster than CPU. >> So how about registering to scomp firstly, then we register this engine to >> acomp later? > > Sorry, but the fact that you're doing a busy-wait for completion > means that scomp is not an appropriate choice. OK. I will use acomp in next version. Thanks, Zhou > > Cheers, >
Re: linux-next: Fixes tag needs some work in the net-next tree
From: Vinod Koul
Date: Wed, 20 Feb 2019 10:10:55 +0530
> On 20-02-19, 09:31, Stephen Rothwell wrote:
>> Hi all,
>>
>> In commit
>>
>> a968b5e9d587 ("net: dsa: qca8k: Enable delay for RGMII_ID mode")
>>
>> Fixes tag
>>
>> Fixes: 40269aa9f40a ("net: dsa: qca8k: disable delay for RGMII mode")
>>
>> has these problem(s):
>>
>> - Target SHA1 does not exist
>>
>> Did you mean:
>>
>> Fixes: 5ecdd77c61c8 ("net: dsa: qca8k: disable delay for RGMII mode")
>
> Yes looks like I messed up the commit id.. Not sure why :(
>
> Dave would you like to drop this and me sending updated patch or
> something else..
>
> Sorry about the miss
Doesn't work that way, something in my tree is there forever.
Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On 2/19/19 10:34 PM, Brendan Higgins wrote: > On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand wrote: > >> I have not read through the patches in any detail. I have read some of >> the code to try to understand the patches to the devicetree unit tests. >> So that may limit how valid my comments below are. > > No problem. > >> >> I found the code difficult to read in places where it should have been >> much simpler to read. Structuring the code in a pseudo object oriented >> style meant that everywhere in a code path that I encountered a dynamic >> function call, I had to go find where that dynamic function call was >> initialized (and being the cautious person that I am, verify that >> no where else was the value of that dynamic function call). With >> primitive vi and tags, that search would have instead just been a >> simple key press (or at worst a few keys) if hard coded function >> calls were done instead of dynamic function calls. In the code paths >> that I looked at, I did not see any case of a dynamic function being >> anything other than the value it was originally initialized as. >> There may be such cases, I did not read the entire patch set. There >> may also be cases envisioned in the architects mind of how this >> flexibility may be of future value. Dunno. > > Yeah, a lot of it is intended to make architecture specific > implementations and some other future work easier. Some of it is also > for testing purposes. Admittedly some is for neither reason, but given > the heavy usage elsewhere, I figured there was no harm since it was > all private internal usage anyway. > Increasing the cost for me (and all the other potential code readers) to read the code is harm.
Re: [PATCH] kasan: turn off asan-stack for clang-8 and earlier
On Wed, Feb 20, 2019 at 1:34 AM Kostya Serebryany wrote:
>
> On Tue, Feb 19, 2019 at 2:43 PM Nick Desaulniers
> wrote:
> >
> > + Evgenii, Kostya for KASAN
> >
> > On Tue, Feb 19, 2019 at 2:17 PM Qian Cai wrote:
> > >
> > > On Tue, 2019-02-19 at 22:49 +0100, Arnd Bergmann wrote:
> > > > Building an arm64 allmodconfig kernel with clang results in over 140
> > > > warnings
> > > > about overly large stack frames, the worst ones being:
> > > >
> > > > drivers/gpu/drm/panel/panel-sitronix-st7789v.c:196:12: error: stack
> > > > frame size
> > > > of 20224 bytes in function 'st7789v_prepare'
> > > > drivers/video/fbdev/omap2/omapfb/displays/panel-tpo-td028ttec1.c:196:12:
> > > > error: stack frame size of 13120 bytes in function
> > > > 'td028ttec1_panel_enable'
> > > > drivers/usb/host/max3421-hcd.c:1395:1: error: stack frame size of 10048
> > > > bytes
> > > > in function 'max3421_spi_thread'
> > > > drivers/net/wan/slic_ds26522.c:209:12: error: stack frame size of 9664
> > > > bytes
> > > > in function 'slic_ds26522_probe'
> > > > drivers/crypto/ccp/ccp-ops.c:2434:5: error: stack frame size of 8832
> > > > bytes in
> > > > function 'ccp_run_cmd'
> > > > drivers/media/dvb-frontends/stv0367.c:1005:12: error: stack frame size
> > > > of 7840
> > > > bytes in function 'stv0367ter_algo'
> > > >
> > > > None of these happen with gcc today, and almost all of these are the
> > > > result
> > > > of a single known bug in llvm. Hopefully it will eventually get fixed
> > > > with
> > > > the
> > > > clang-9 release.
>
> I am not confident we can fix this in clang.
> The difference between gcc and clang, AFAICT, is not in the asan
> instrumentation, but in inining.
> Looking at the reproducer from https://bugs.llvm.org/show_bug.cgi?id=38809#c4,
> if I change ltv350qv_write_reg to always inline, gcc also produces a
> huge 10K stack frame,
> and making it noinline fixes the stack frame for both gcc and clang.
Does your gcc have fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 ?
For me gcc rejects to inline it:
gcc version 7.3.0 (Debian 7.3.0-5)
$ gcc /tmp/test.c -Wframe-larger-than=128 -c -fsanitize=kernel-address
-O2 --param asan-stack=1
/tmp/test.c:23:13: warning: always_inline function might not be
inlinable [-Wattributes]
static void ltv350qv_write_reg(void) {
^~
/tmp/test.c: In function ‘ltv350qv_power_on’:
/tmp/test.c:57:1: warning: the frame size of 416 bytes is larger than
128 bytes [-Wframe-larger-than=]
}
^
linux-next: build failure after merge of the akpm-current tree
Hi all,
After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/nouveau/nouveau_dmem.c:299:11: error: initialization of
'vm_fault_t (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned
int, const struct page *, unsigned int, pmd_t *)' {aka 'unsigned int
(*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned int, const
struct page *, unsigned int, struct *)'} from incompatible pointer
type 'int (*)(struct hmm_devmem *, struct vm_area_struct *, long unsigned int,
const struct page *, unsigned int, pmd_t *)' {aka 'int (*)(struct hmm_devmem
*, struct vm_area_struct *, long unsigned int, const struct page *, unsigned
int, struct *)'} [-Werror=incompatible-pointer-types]
.fault = nouveau_dmem_fault,
^~
drivers/gpu/drm/nouveau/nouveau_dmem.c:299:11: note: (near initialization for
'nouveau_dmem_devmem_ops.fault')
Caused by commit
5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM")
from the drm tree interacting with commit
ed814eb7f91d ("mm/hmm: convert to use vm_fault_t")
from the akpm-current tree.
I added this merge fix patch:
From: Stephen Rothwell
Date: Wed, 20 Feb 2019 17:36:18 +1100
Subject: [PATCH] drm/nouveau/dmem: update for struct hmm_devmem_ops member
change
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c
b/drivers/gpu/drm/nouveau/nouveau_dmem.c
index 8be7a83ced9b..e2539f64de60 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
@@ -261,7 +261,7 @@ static const struct migrate_vma_ops
nouveau_dmem_fault_migrate_ops = {
.finalize_and_map = nouveau_dmem_fault_finalize_and_map,
};
-static int
+static vm_fault_t
nouveau_dmem_fault(struct hmm_devmem *devmem,
struct vm_area_struct *vma,
unsigned long addr,
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpImOAcpHdDp.pgp
Description: OpenPGP digital signature
KASAN: use-after-free Read in h5_reset_rx
Hello, syzbot found the following crash on: HEAD commit:7a92eb7cc1dc Add linux-next specific files for 20190215 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=10b2f400c0 kernel config: https://syzkaller.appspot.com/x/.config?x=b16fd68f18a50133 dashboard link: https://syzkaller.appspot.com/bug?extid=899a33dc0fa0dbaf06a6 compiler: gcc (GCC) 9.0.0 20181231 (experimental) Unfortunately, I don't have any reproducer for this crash yet. IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+899a33dc0fa0dbaf0...@syzkaller.appspotmail.com Bluetooth: Invalid header checksum == BUG: KASAN: use-after-free in h5_reset_rx+0xe0/0x100 drivers/bluetooth/hci_h5.c:544 Read of size 8 at addr 88809117be18 by task kworker/u4:4/880 CPU: 1 PID: 880 Comm: kworker/u4:4 Not tainted 5.0.0-rc6-next-20190215 #36 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events_unbound flush_to_ldisc Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187 kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317 __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132 h5_reset_rx+0xe0/0x100 drivers/bluetooth/hci_h5.c:544 h5_rx_3wire_hdr+0x2f5/0x3c0 drivers/bluetooth/hci_h5.c:455 h5_recv+0x30a/0x4c0 drivers/bluetooth/hci_h5.c:578 hci_uart_tty_receive+0x22b/0x530 drivers/bluetooth/hci_ldisc.c:607 tty_ldisc_receive_buf+0x164/0x1c0 drivers/tty/tty_buffer.c:465 tty_port_default_receive_buf+0x7d/0xb0 drivers/tty/tty_port.c:38 receive_buf drivers/tty/tty_buffer.c:481 [inline] flush_to_ldisc+0x228/0x390 drivers/tty/tty_buffer.c:533 process_one_work+0x98e/0x1790 kernel/workqueue.c:2267 worker_thread+0x98/0xe40 kernel/workqueue.c:2413 kthread+0x357/0x430 kernel/kthread.c:253 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352 Allocated by task 6242: save_stack+0x45/0xd0 mm/kasan/common.c:75 set_track mm/kasan/common.c:87 [inline] __kasan_kmalloc mm/kasan/common.c:497 [inline] __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:470 kasan_kmalloc+0x9/0x10 mm/kasan/common.c:511 kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615 kmalloc include/linux/slab.h:548 [inline] kzalloc include/linux/slab.h:743 [inline] h5_open+0x4e4/0x5f0 drivers/bluetooth/hci_h5.c:222 hci_uart_set_proto drivers/bluetooth/hci_ldisc.c:686 [inline] hci_uart_tty_ioctl+0x2d4/0xa70 drivers/bluetooth/hci_ldisc.c:748 tty_ioctl+0xac9/0x14d0 drivers/tty/tty_io.c:2664 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe Freed by task 6242: save_stack+0x45/0xd0 mm/kasan/common.c:75 set_track mm/kasan/common.c:87 [inline] __kasan_slab_free+0x102/0x150 mm/kasan/common.c:459 kasan_slab_free+0xe/0x10 mm/kasan/common.c:467 __cache_free mm/slab.c:3491 [inline] kfree+0xcf/0x230 mm/slab.c:3816 h5_close+0x11a/0x150 drivers/bluetooth/hci_h5.c:266 hci_uart_set_proto drivers/bluetooth/hci_ldisc.c:696 [inline] hci_uart_tty_ioctl+0x839/0xa70 drivers/bluetooth/hci_ldisc.c:748 tty_ioctl+0xac9/0x14d0 drivers/tty/tty_io.c:2664 vfs_ioctl fs/ioctl.c:46 [inline] file_ioctl fs/ioctl.c:509 [inline] do_vfs_ioctl+0xd6e/0x1390 fs/ioctl.c:696 ksys_ioctl+0xab/0xd0 fs/ioctl.c:713 __do_sys_ioctl fs/ioctl.c:720 [inline] __se_sys_ioctl fs/ioctl.c:718 [inline] __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718 do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe The buggy address belongs to the object at 88809117bb40 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 728 bytes inside of 1024-byte region [88809117bb40, 88809117bf40) The buggy address belongs to the page: page:ea0002445e80 count:1 mapcount:0 mapping:88812c3f0ac0 index:0x0 compound_mapcount: 0 flags: 0x1fffc010200(slab|head) raw: 01fffc010200 ea000226a888 ea97a788 88812c3f0ac0 raw: 88809117a040 00010007 page dumped because: kasan: bad access detected Memory state around the buggy address: 88809117bd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 88809117bd80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 88809117be00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ 88809117be80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb 88809117bf00: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc ==
Re: [RFC v4 08/17] kunit: test: add support for test abort
On 2/19/19 7:39 PM, Brendan Higgins wrote:
> On Mon, Feb 18, 2019 at 11:52 AM Frank Rowand wrote:
>>
>> On 2/14/19 1:37 PM, Brendan Higgins wrote:
>>> Add support for aborting/bailing out of test cases. Needed for
>>> implementing assertions.
>>>
>>> Signed-off-by: Brendan Higgins
>>> ---
>>> Changes Since Last Version
>>> - This patch is new introducing a new cross-architecture way to abort
>>>out of a test case (needed for KUNIT_ASSERT_*, see next patch for
>>>details).
>>> - On a side note, this is not a complete replacement for the UML abort
>>>mechanism, but covers the majority of necessary functionality. UML
>>>architecture specific featurs have been dropped from the initial
>>>patchset.
>>> ---
>>> include/kunit/test.h | 24 +
>>> kunit/Makefile | 3 +-
>>> kunit/test-test.c| 127 ++
>>> kunit/test.c | 208 +--
>>> 4 files changed, 353 insertions(+), 9 deletions(-)
>>> create mode 100644 kunit/test-test.c
>>
>> < snip >
>>
>>> diff --git a/kunit/test.c b/kunit/test.c
>>> index d18c50d5ed671..6e5244642ab07 100644
>>> --- a/kunit/test.c
>>> +++ b/kunit/test.c
>>> @@ -6,9 +6,9 @@
>>> * Author: Brendan Higgins
>>> */
>>>
>>> -#include
>>> #include
>>> -#include
>>> +#include
>>> +#include
>>> #include
>>>
>>> static bool kunit_get_success(struct kunit *test)
>>> @@ -32,6 +32,27 @@ static void kunit_set_success(struct kunit *test, bool
>>> success)
>>> spin_unlock_irqrestore(>lock, flags);
>>> }
>>>
>>> +static bool kunit_get_death_test(struct kunit *test)
>>> +{
>>> + unsigned long flags;
>>> + bool death_test;
>>> +
>>> + spin_lock_irqsave(>lock, flags);
>>> + death_test = test->death_test;
>>> + spin_unlock_irqrestore(>lock, flags);
>>> +
>>> + return death_test;
>>> +}
>>> +
>>> +static void kunit_set_death_test(struct kunit *test, bool death_test)
>>> +{
>>> + unsigned long flags;
>>> +
>>> + spin_lock_irqsave(>lock, flags);
>>> + test->death_test = death_test;
>>> + spin_unlock_irqrestore(>lock, flags);
>>> +}
>>> +
>>> static int kunit_vprintk_emit(const struct kunit *test,
>>> int level,
>>> const char *fmt,
>>> @@ -70,13 +91,29 @@ static void kunit_fail(struct kunit *test, struct
>>> kunit_stream *stream)
>>> stream->commit(stream);
>>> }
>>>
>>> +static void __noreturn kunit_abort(struct kunit *test)
>>> +{
>>> + kunit_set_death_test(test, true);
>>> +
>>> + test->try_catch.throw(>try_catch);
>>> +
>>> + /*
>>> + * Throw could not abort from test.
>>> + */
>>> + kunit_err(test, "Throw could not abort from test!");
>>> + show_stack(NULL, NULL);
>>> + BUG();
>>
>> kunit_abort() is what will be call as the result of an assert failure.
>
> Yep. Does that need clarified somewhere.
>>
>> BUG(), which is a panic, which is crashing the system is not acceptable
>> in the Linux kernel. You will just annoy Linus if you submit this.
>
> Sorry, I thought this was an acceptable use case since, a) this should
> never be compiled in a production kernel, b) we are in a pretty bad,
> unpredictable state if we get here and keep going. I think you might
> have said elsewhere that you think "a" is not valid? In any case, I
> can replace this with a WARN, would that be acceptable?
A WARN may or may not make sense, depending on the context. It may
be sufficient to simply report a test failure (as in the old version
of case (2) below.
Answers to "a)" and "b)":
a) it might be in a production kernel
a') it is not acceptable in my development kernel either
b) No. You don't crash a developer's kernel either unless it is
required to avoid data corruption.
b') And you can not do replacements like:
(1) in of_unittest_check_tree_linkage()
- old -
if (!of_root)
return;
- new -
KUNIT_ASSERT_NOT_ERR_OR_NULL(test, of_root);
(2) in of_unittest_property_string()
- old -
/* of_property_read_string_index() tests */
rc = of_property_read_string_index(np, "string-property", 0, strings);
unittest(rc == 0 && !strcmp(strings[0], "foobar"),
"of_property_read_string_index() failure; rc=%i\n", rc);
- new -
/* of_property_read_string_index() tests */
rc = of_property_read_string_index(np, "string-property", 0, strings);
KUNIT_ASSERT_EQ(test, rc, 0);
KUNIT_EXPECT_STREQ(test, strings[0], "foobar");
If a test fails, that is no reason to abort testing. The remainder of the unit
tests can still run. There may be cascading failures, but that is ok.
RE: [PATCH V3 2/4] dt-bindings: irq: imx-irqsteer: add multi output interrupts support
> From: Rob Herring [mailto:r...@kernel.org] > Sent: Thursday, February 14, 2019 6:30 AM > On Mon, Feb 11, 2019 at 03:34:23PM +, Marc Zyngier wrote: > > On 31/01/2019 08:03, Aisheng Dong wrote: > > > One irqsteer channel can support up to 8 output interrupts. > > > > > > Cc: Marc Zyngier > > > Cc: Rob Herring > > > Cc: Lucas Stach > > > Cc: Shawn Guo > > > Cc: devicet...@vger.kernel.org > > > Signed-off-by: Dong Aisheng > > > --- > > > ChangeLog: > > > v2->v3: > > > * fix a typo > > > v1->v2: > > > * remove one unnecessary note. > > > --- > > > .../devicetree/bindings/interrupt-controller/fsl,irqsteer.txt| 5 > +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqstee > > > r.txt > > > b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqstee > > > r.txt > > > index 6d0a41b..582991c 100644 > > > --- > > > a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqstee > > > r.txt > > > +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irq > > > +++ steer.txt > > > @@ -6,8 +6,9 @@ Required properties: > > > - "fsl,imx8m-irqsteer" > > > - "fsl,imx-irqsteer" > > > - reg: Physical base address and size of registers. > > > -- interrupts: Should contain the parent interrupt line used to > > > multiplex the > > > - input interrupts. > > > +- interrupts: Should contain the up to 8 parent interrupt lines > > > +used to > > > + multiplex the input interrupts. They should be specified > > > +sequentially > > > + from output 0 to 7. > > > - clocks: Should contain one clock for entry in clock-names > > >see Documentation/devicetree/bindings/clock/clock-bindings.txt > > > - clock-names: > > > > > > > I'd like an Ack from a DT person, as this is a change to an existing > > binding. > > It's fine as long as old kernels ignore extra entries and new kernels still > support > a single entry. Otherwise, it needs a explanation. Yes, it's like that. No compatibility break. Regards Dong Aisheng > > Rob
RE: [PATCH V3 1/4] dt-binding: irq: imx-irqsteer: use irq number instead of group number
> From: Rob Herring [mailto:r...@kernel.org] > Sent: Thursday, February 14, 2019 6:27 AM> > On Mon, Feb 11, 2019 at 03:35:40PM +, Marc Zyngier wrote: > > On 31/01/2019 08:03, Aisheng Dong wrote: > > > Not all 64 interrupts may be used in one group. e.g. most irqsteer > > > in imx8qxp and imx8qm subsystems supports only 32 interrupts. > > > > > > As the IP integration parameters are Channel number and interrupts > > > number, let's use fsl,irqs-num to represents how many interrupts > > > supported by this irqsteer channel. > > > > > > Cc: Marc Zyngier > > > Cc: Rob Herring > > > Cc: Shawn Guo > > > Cc: devicet...@vger.kernel.org > > > Reviewed-by: Lucas Stach > > > Signed-off-by: Dong Aisheng > > > --- > > > ChangeLog: > > > v1->v2: > > > * change property name fsl,irqs-per-chan to fsl,num-irqs. > > > --- > > > .../devicetree/bindings/interrupt-controller/fsl,irqsteer.txt | 6 > +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git > > > a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqstee > > > r.txt > > > b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqstee > > > r.txt > > > index 45790ce..6d0a41b 100644 > > > --- > > > a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqstee > > > r.txt > > > +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irq > > > +++ steer.txt > > > @@ -16,8 +16,8 @@ Required properties: > > > - #interrupt-cells: Specifies the number of cells needed to encode an > > >interrupt source. The value must be 1. > > > - fsl,channel: The output channel that all input IRQs should be steered > into. > > > -- fsl,irq-groups: Number of IRQ groups managed by this controller > instance. > > > - Each group manages 64 input interrupts. > > > +- fsl,num-irqs: Number of input interrupts of this channel. > > > + Should be multiple of 32 input interrupts and up to 512 interrupts. > > > > > > Example: > > > > > > @@ -28,7 +28,7 @@ Example: > > > clocks = < IMX8MQ_CLK_DISP_APB_ROOT>; > > > clock-names = "ipg"; > > > fsl,channel = <0>; > > > - fsl,irq-groups = <1>; > > > + fsl,num-irqs = <64>; > > > interrupt-controller; > > > #interrupt-cells = <1>; > > > }; > > > > > > > This is a change to an existing binding, so I'd need the Ack from a DT > > maintainer before I can queue this. > > The DT maintainer doesn't care as long as there's an explanation that says > it's > breaking compatibility and why it is okay to do so. This one doesn't do that. > Got it. I will add them and resend, thanks for the suggestion. Regards Dong Aisheng > Rob
Re: [RFC v4 00/17] kunit: introduce KUnit, the Linux kernel unit testing framework
On Mon, Feb 18, 2019 at 12:02 PM Frank Rowand wrote: > I have not read through the patches in any detail. I have read some of > the code to try to understand the patches to the devicetree unit tests. > So that may limit how valid my comments below are. No problem. > > I found the code difficult to read in places where it should have been > much simpler to read. Structuring the code in a pseudo object oriented > style meant that everywhere in a code path that I encountered a dynamic > function call, I had to go find where that dynamic function call was > initialized (and being the cautious person that I am, verify that > no where else was the value of that dynamic function call). With > primitive vi and tags, that search would have instead just been a > simple key press (or at worst a few keys) if hard coded function > calls were done instead of dynamic function calls. In the code paths > that I looked at, I did not see any case of a dynamic function being > anything other than the value it was originally initialized as. > There may be such cases, I did not read the entire patch set. There > may also be cases envisioned in the architects mind of how this > flexibility may be of future value. Dunno. Yeah, a lot of it is intended to make architecture specific implementations and some other future work easier. Some of it is also for testing purposes. Admittedly some is for neither reason, but given the heavy usage elsewhere, I figured there was no harm since it was all private internal usage anyway.
Re: [PATCH v2 -next] tpm: Fix the type of the return value in calc_tpm2_event_size()
On Wed, Feb 20, 2019 at 10:23:00AM +0800, YueHaibing wrote:
> calc_tpm2_event_size() has an invalid signature because
> it returns a 'size_t' where as its signature says that
> it returns 'int'.
>
> Fixes: 4d23cc323cdb ("tpm: add securityfs support for TPM 2.0 firmware event
> log")
> Suggested-by: Jarkko Sakkinen
> Signed-off-by: YueHaibing
Two remarks:
- git config user.name "Yue Haibing"
- "Cc: sta...@vger.kernel.org" before the fixes tag.
Thanks.
/Jarkko
Re: [PATCH v1 1/2] drm/mediatek: separate mipi_tx to different file
Hi, Jitao:
On Tue, 2019-02-19 at 17:14 +0800, Jitao Shi wrote:
> Different IC has different mipi_tx setting of dsi.
> This patch separates the mipi_tx hardware relate part for mt8173.
>
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/Makefile | 1 +
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 350 ++
> drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 51 +++
> drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 290 +++
> 4 files changed, 377 insertions(+), 315 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
>
[snip]
>
> +static void mtk_mipi_tx_clk_get_ops(struct mtk_mipi_tx *mipi_tx,
> + const struct clk_ops **ops)
> +{
> + if (mipi_tx && mipi_tx->driver_data &&
> + mipi_tx->driver_data->mipi_tx_clk_ops)
> + *ops = mipi_tx->driver_data->mipi_tx_clk_ops;
> + else
> + dev_err(mipi_tx->dev, "Failed to get clk ops of phy\n");
Any where call mtk_mipi_tx_clk_get_ops() would make sure mipi_tx is not
NULL, so you need not to check mipi_tx. And the checking of driver_data
and mipi_tx_clk_ops looks unnecessary because any one who implement this
driver would never let this happen. So this function just need do the
assignment and therefore this assignment could just do in probe().
Regards,
CK
> +}
> +
> static int mtk_mipi_tx_probe(struct platform_device *pdev)
> {
> struct device *dev = >dev;
> struct mtk_mipi_tx *mipi_tx;
> struct resource *mem;
> - struct clk *ref_clk;
> const char *ref_clk_name;
> struct clk_init_data clk_init = {
> - .ops = _mipi_tx_pll_ops,
> .num_parents = 1,
> .parent_names = (const char * const *)_clk_name,
> .flags = CLK_SET_RATE_GATE,
> @@ -408,6 +132,7 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
> return -ENOMEM;
>
> mipi_tx->driver_data = of_device_get_match_data(dev);
> +
> mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> mipi_tx->regs = devm_ioremap_resource(dev, mem);
> if (IS_ERR(mipi_tx->regs)) {
> @@ -416,13 +141,14 @@ static int mtk_mipi_tx_probe(struct platform_device
> *pdev)
> return ret;
> }
>
> - ref_clk = devm_clk_get(dev, NULL);
> - if (IS_ERR(ref_clk)) {
> - ret = PTR_ERR(ref_clk);
> + mipi_tx->ref_clk = devm_clk_get(dev, NULL);
> + if (IS_ERR(mipi_tx->ref_clk)) {
> + ret = PTR_ERR(mipi_tx->ref_clk);
> dev_err(dev, "Failed to get reference clock: %d\n", ret);
> return ret;
> }
> - ref_clk_name = __clk_get_name(ref_clk);
> +
> + ref_clk_name = __clk_get_name(mipi_tx->ref_clk);
>
> ret = of_property_read_string(dev->of_node, "clock-output-names",
> _init.name);
> @@ -431,6 +157,8 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
> return ret;
> }
>
> + mtk_mipi_tx_clk_get_ops(mipi_tx, _init.ops);
> +
> mipi_tx->pll_hw.init = _init;
> mipi_tx->pll = devm_clk_register(dev, _tx->pll_hw);
> if (IS_ERR(mipi_tx->pll)) {
> @@ -465,20 +193,12 @@ static int mtk_mipi_tx_remove(struct platform_device
> *pdev)
> return 0;
> }
>
> -static const struct mtk_mipitx_data mt2701_mipitx_data = {
> - .mppll_preserve = (3 << 8)
> -};
> -
> -static const struct mtk_mipitx_data mt8173_mipitx_data = {
> - .mppll_preserve = (0 << 8)
> -};
> -
> static const struct of_device_id mtk_mipi_tx_match[] = {
> { .compatible = "mediatek,mt2701-mipi-tx",
> .data = _mipitx_data },
> { .compatible = "mediatek,mt8173-mipi-tx",
> .data = _mipitx_data },
> - {},
> + { },
> };
>
Re: [PATCH v4 3/3] i2c: at91: added slave mode support
Hi, On Fri, Feb 15, 2019 at 10:18:47AM +0100, Wolfram Sang wrote: > On Tue, Jan 15, 2019 at 11:43:51PM +0100, Wolfram Sang wrote: > > > > > All errors (new ones prefixed by >>): > > > > > > >> ERROR: "at91_init_twi_bus_slave" [drivers/i2c/busses/i2c-at91.ko] > > > >> undefined! > > > >> ERROR: "at91_twi_probe_slave" [drivers/i2c/busses/i2c-at91.ko] > > > >> undefined! > > > > That needs to be fixed. Rest looks good to me! > > Ludovic, do you have time to fix it? I would really like to apply this > series for the next merge window. > Sorry it's in my todo list but I didn't have time to handle it. I'll try to fix it beginning of next week. Regards Ludovic > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: ext4 corruption on alpha with 4.20.0-09062-gd8372ba8ce28
Could https://lore.kernel.org/linux-mm/20190219123212.29838-1-lar...@axis.com/T/#u be relevant? Tried it, still broken. I wrote: But my kernel config had memory compaction (that turned on page migration) and bounce buffers. I do not remember why I found them necessary but I will try without them. First, I found out that both the problematic alphas had memory compaction and page migration and bounce buffers turned on, and working alphas had them off. Next, turing off these options makes the problematic alphas work. -- Meelis Roos
RE: [PATCH v4 2/6] usb:common Separated decoding functions from dwc3 driver.
Hi, >On Thu, Feb 14, 2019 at 07:45:10PM +, Pawel Laszczak wrote: >> Patch moves some decoding functions from driver/usb/dwc3/debug.h driver >> to driver/usb/common/debug.c file. These moved functions include: >> dwc3_decode_get_status >> dwc3_decode_set_clear_feature >> dwc3_decode_set_address >> dwc3_decode_get_set_descriptor >> dwc3_decode_get_configuration >> dwc3_decode_set_configuration >> dwc3_decode_get_intf >> dwc3_decode_set_intf >> dwc3_decode_synch_frame >> dwc3_decode_set_sel >> dwc3_decode_set_isoch_delay >> dwc3_decode_ctrl >> >> These functions are used also in inroduced cdns3 driver. >> >> All functions prefixes were changed from dwc3 to usb. >> Also, function's parameters has been extended according to the name >> of fields in standard SETUP packet. >> Additionally, patch adds usb_decode_ctrl function to >> include/linux/usb/ch9.h file. >> >> Signed-off-by: Pawel Laszczak >> --- >> drivers/usb/common/Makefile | 2 +- >> drivers/usb/common/debug.c | 270 >> drivers/usb/dwc3/debug.h| 249 - >> drivers/usb/dwc3/trace.h| 2 +- >> include/linux/usb/ch9.h | 25 >> 5 files changed, 297 insertions(+), 251 deletions(-) >> create mode 100644 drivers/usb/common/debug.c >> >> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile >> index fb4d5ef4165c..3d3d2962ea4b 100644 >> --- a/drivers/usb/common/Makefile >> +++ b/drivers/usb/common/Makefile >> @@ -4,7 +4,7 @@ >> # >> >> obj-$(CONFIG_USB_COMMON) += usb-common.o >> -usb-common-y += common.o >> +usb-common-y += common.o debug.o > >It's nice to have these in a common place, but you just bloated all of >the USB-enabled systems in the world for the use of 2 odd-ball system >controllers that almost no one has :) > >So, any way to only pull in this file if you actually need these >functions? > Yes, I'm using these functions a lot for debugging. It's only way to check what driver does. We are also going to upstreaming 3.1 controller so there will be a third driver using them :). I'm not sure If anyone will use them on host side, so we can consider whether they should be in usb/common directory. Maybe usb/gadget will be better place. Felipe, do you have any comments in this topic? Thanks Pawel
deal
-- Dear Friend, Greetings and how are you today? I'm sorry if this message is found in the spam of your email box as that will certainly be a network misharp and I want us to discuss about the sum of Fourty Million Dollars discovered in my office and I'll give you more details when I hear from you. Regards Jean Kabore --
Re: [RFC PATCH] kbuild: support llvm-ar
Hi Jordan, On Thu, Feb 7, 2019 at 9:56 AM Jordan Rupprecht wrote: > > I have a patch up for review that fixes the second case of chopping > off the directory when nesting thin archives: > https://reviews.llvm.org/D57842. I'll commit it tomorrow if there are > no more comments. Sorry for late reply. Now I tested the latest llvm-ar, and it worked perfectly for kbuild. Thanks for your work! -- Best Regards Masahiro Yamada
Re: [PATCH -next] btrfs: Fix type conversion in btrfs_read_root_item
On Wed, Feb 20, 2019 at 08:58:43AM +0300, Dan Carpenter wrote:
> On Wed, Feb 20, 2019 at 03:08:40AM +, YueHaibing wrote:
> > btrfs_item_size_nr return value is u32, convert it to int may result
> > in truncation.Also read_extent_buffer expect a unsigned param, so
> > min_t should use type u32 to compare.
> >
> > Fixes: 8ea05e3a4262 ("Btrfs: introduce subvol uuids and times")
> > Signed-off-by: YueHaibing
> > ---
> > fs/btrfs/root-tree.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
> > index 02d1a57af78b..893d12fbfda0 100644
> > --- a/fs/btrfs/root-tree.c
> > +++ b/fs/btrfs/root-tree.c
> > @@ -21,12 +21,12 @@ static void btrfs_read_root_item(struct extent_buffer
> > *eb, int slot,
> > struct btrfs_root_item *item)
> > {
> > uuid_le uuid;
> > - int len;
> > + u32 len;
> > int need_reset = 0;
> >
> > len = btrfs_item_size_nr(eb, slot);
> > read_extent_buffer(eb, item, btrfs_item_ptr_offset(eb, slot),
> > - min_t(int, len, (int)sizeof(*item)));
>
> Yeah, min_t() should normally cast to unsigned and the extra cast is
> silly.
>
Btw, I shouldn't have had to dig through the patch to find the *real*
reason you wrote it. A better description would have said:
There is a messy cast here:
min_t(int, len, (int)sizeof(*item)));
min_t() should normally cast to unsigned. It's not possible for
"len" to be negative, but if it were then then we definitely
wouldn't want to pass negatives to read_extent_buffer(). Also there
is an extra cast.
This patch shouldn't affect runtime, it's just a clean up.
regards,
dan carpenter
Re: [PATCH 03/11] x86 topology: Add CPUID.1F multi-die/package support
On Tue, Feb 19, 2019 at 9:59 PM Like Xu wrote: > > -/* leaf 0xb sub-leaf types */ > > +/* extended topology sub-leaf types */ > > #define INVALID_TYPE0 > > #define SMT_TYPE1 > > #define CORE_TYPE 2 > > +#define DIE_TYPE 5 > > This patch set is going to export die topology via sysfs > while the extended topology sub-leaf type could be one of followings: > SMT/Core/Module/Tile/Die according to CPUID.1F from SDM. > > Why not choose to export module/tile topology as well? Excellent question. (and thank you for reading the SDM:-) While it is true that there are shipping products with software-visible CPU modules and tiles, they shipped before this mechanism was available. As a result, there are currently zero products that use this mechanism to enumerate modules and tiles. If future products have software-visible modules and tiles, and they choose to use this mechanism, we can add support for them. But I do not advocate adding code to the kernel "just in case". In contrast, the need to support multi-die/package products as soon as possible is quite clear. thanks, Len Brown, Intel Open Source Technology Center
[PATCH -next] tee: fix possible error pointer ctx dereferencing
Add check for valid ctx pointer and then only dereference ctx to
configure supp_nowait flag.
Fixes: 42bf4152d8a7 ("tee: add supp_nowait flag in tee_context struct")
Reported-by: Dan Carpenter
Signed-off-by: Sumit Garg
---
drivers/tee/tee_core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c
index 25f3b9c..06fbfc0 100644
--- a/drivers/tee/tee_core.c
+++ b/drivers/tee/tee_core.c
@@ -993,7 +993,9 @@ tee_client_open_context(struct tee_context *start,
* tee_client_open_session() if any in kernel client requires
* different behaviour.
*/
- ctx->supp_nowait = true;
+ if (!IS_ERR(ctx))
+ ctx->supp_nowait = true;
+
return ctx;
}
EXPORT_SYMBOL_GPL(tee_client_open_context);
--
2.7.4
Re: [PATCH -next] btrfs: Fix type conversion in btrfs_read_root_item
On Wed, Feb 20, 2019 at 03:08:40AM +, YueHaibing wrote:
> btrfs_item_size_nr return value is u32, convert it to int may result
> in truncation.Also read_extent_buffer expect a unsigned param, so
> min_t should use type u32 to compare.
>
> Fixes: 8ea05e3a4262 ("Btrfs: introduce subvol uuids and times")
> Signed-off-by: YueHaibing
> ---
> fs/btrfs/root-tree.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
> index 02d1a57af78b..893d12fbfda0 100644
> --- a/fs/btrfs/root-tree.c
> +++ b/fs/btrfs/root-tree.c
> @@ -21,12 +21,12 @@ static void btrfs_read_root_item(struct extent_buffer
> *eb, int slot,
> struct btrfs_root_item *item)
> {
> uuid_le uuid;
> - int len;
> + u32 len;
> int need_reset = 0;
>
> len = btrfs_item_size_nr(eb, slot);
> read_extent_buffer(eb, item, btrfs_item_ptr_offset(eb, slot),
> - min_t(int, len, (int)sizeof(*item)));
Yeah, min_t() should normally cast to unsigned and the extra cast is
silly.
> +min_t(u32, len, sizeof(*item)));
regards,
dan carpenter
[PATCH v2] powerpc/prom_init: add __init markers to all functions
It is fragile to rely on the compiler's optimization to avoid the
section mismatch. Some functions may not be necessarily inlined
when the compiler's inlining heuristic changes.
Add __init markers consistently.
As for prom_getprop() and prom_getproplen(), they are marked as
'inline', so inlining is guaranteed because PowerPC never enables
CONFIG_OPTIMIZE_INLINING. However, it would be better to leave the
inlining decision to the compiler. I replaced 'inline' with __init.
I added __maybe_unused to prom_getproplen() because it is currently
relying on the side-effect of 'inline'; GCC does not report
-Wunused-function warnings for functions with 'inline' marker.
Signed-off-by: Masahiro Yamada
---
Changes in v2:
- Add __maybe_unsed to prom_getproplen()
- Add __init to enter_prom() as well
arch/powerpc/kernel/prom_init.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index f33ff41..1bad0ac 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -138,9 +138,9 @@ extern void __start(unsigned long r3, unsigned long r4,
unsigned long r5,
unsigned long r9);
#ifdef CONFIG_PPC64
-extern int enter_prom(struct prom_args *args, unsigned long entry);
+extern int __init enter_prom(struct prom_args *args, unsigned long entry);
#else
-static inline int enter_prom(struct prom_args *args, unsigned long entry)
+static int __init enter_prom(struct prom_args *args, unsigned long entry)
{
return ((int (*)(struct prom_args *))entry)(args);
}
@@ -501,19 +501,20 @@ static int __init prom_next_node(phandle *nodep)
}
}
-static inline int prom_getprop(phandle node, const char *pname,
+static int __init prom_getprop(phandle node, const char *pname,
void *value, size_t valuelen)
{
return call_prom("getprop", 4, 1, node, ADDR(pname),
(u32)(unsigned long) value, (u32) valuelen);
}
-static inline int prom_getproplen(phandle node, const char *pname)
+static int __init __maybe_unused prom_getproplen(phandle node,
+const char *pname)
{
return call_prom("getproplen", 2, 1, node, ADDR(pname));
}
-static void add_string(char **str, const char *q)
+static void __init add_string(char **str, const char *q)
{
char *p = *str;
@@ -523,7 +524,7 @@ static void add_string(char **str, const char *q)
*str = p;
}
-static char *tohex(unsigned int x)
+static char __init *tohex(unsigned int x)
{
static const char digits[] __initconst = "0123456789abcdef";
static char result[9] __prombss;
@@ -570,7 +571,7 @@ static int __init prom_setprop(phandle node, const char
*nodename,
#define islower(c) ('a' <= (c) && (c) <= 'z')
#define toupper(c) (islower(c) ? ((c) - 'a' + 'A') : (c))
-static unsigned long prom_strtoul(const char *cp, const char **endp)
+static unsigned long __init prom_strtoul(const char *cp, const char **endp)
{
unsigned long result = 0, base = 10, value;
@@ -595,7 +596,7 @@ static unsigned long prom_strtoul(const char *cp, const
char **endp)
return result;
}
-static unsigned long prom_memparse(const char *ptr, const char **retptr)
+static unsigned long __init prom_memparse(const char *ptr, const char **retptr)
{
unsigned long ret = prom_strtoul(ptr, retptr);
int shift = 0;
@@ -2924,7 +2925,7 @@ static void __init fixup_device_tree_pasemi(void)
prom_setprop(iob, name, "device_type", "isa", sizeof("isa"));
}
#else /* !CONFIG_PPC_PASEMI_NEMO */
-static inline void fixup_device_tree_pasemi(void) { }
+static void __init fixup_device_tree_pasemi(void) { }
#endif
static void __init fixup_device_tree(void)
@@ -2986,15 +2987,15 @@ static void __init prom_check_initrd(unsigned long r3,
unsigned long r4)
#ifdef CONFIG_PPC64
#ifdef CONFIG_RELOCATABLE
-static void reloc_toc(void)
+static void __init reloc_toc(void)
{
}
-static void unreloc_toc(void)
+static void __init unreloc_toc(void)
{
}
#else
-static void __reloc_toc(unsigned long offset, unsigned long nr_entries)
+static void __init __reloc_toc(unsigned long offset, unsigned long nr_entries)
{
unsigned long i;
unsigned long *toc_entry;
@@ -3008,7 +3009,7 @@ static void __reloc_toc(unsigned long offset, unsigned
long nr_entries)
}
}
-static void reloc_toc(void)
+static void __init reloc_toc(void)
{
unsigned long offset = reloc_offset();
unsigned long nr_entries =
@@ -3019,7 +3020,7 @@ static void reloc_toc(void)
mb();
}
-static void unreloc_toc(void)
+static void __init unreloc_toc(void)
{
unsigned long offset = reloc_offset();
unsigned long nr_entries =
--
2.7.4
Re: [PATCH v5 05/10] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
Hi Tony, On 19/02/19 11:26 PM, Tony Lindgren wrote: > * Tony Lindgren [190219 17:11]: >> * Lokesh Vutla [190219 16:19]: >>> yes. How different is this from any of the above mentioned drivers using >>> firmware specific ids. Like sci pm domain[1] driver utilizes the same >>> device id for enabling any device in the system. Similarly clock >>> driver[2] uses the same device ids and clock ids specified by firmware. >>> There are more which similarly represents firmware ids from DT. >>> >>> [1] Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt >>> [2] Documentation/devicetree/bindings/clock/ti,sci-clk.txt >> >> That's horrible. We really must not use any firmware invented >> numbers in the device as they do not describe hardware. > > No firmware invented numbers in the device tree I mean naturally. > Drivers do whatever they need to do to deal with the firmware. Let's look at these similar other examples available inside Linux: 1: ./Documentation/devicetree/bindings/arm/arm,scmi.txt mentions the following: - #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands. - #power-domain-cells : Should be 1. Contains the device or the power domain ID value used by SCMI commands. 2: Documentation/devicetree/bindings/arm/arm,scpi.txt mentions the following: - #power-domain-cells : Should be 1. Contains the device or the power domain ID value used by SCPI commands. 3: Documentation/devicetree/bindings/firmware/nvidia,tegra186-bpmp.txt the firmware specified identifier are defined in the following header files: include/dt-bindings/clock/tegra186-clock.h include/dt-bindings/power/tegra186-powergate.h include/dt-bindings/reset/tegra186-reset.h 4. Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt mentions the following: "Output clocks are registered based on clock information received from firmware. Output clocks indexes are mentioned in include/dt-bindings/clock/xlnx,zynqmp-clk.h." 5. Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt mentions the following: - #power-domain-cells: Must be 1. Contains the Resource ID used by SCU commands. See detailed Resource ID list from: include/dt-bindings/firmware/imx/rsrc.h - The clock consumer should specify the desired clock by having the clock ID in its "clocks" phandle cell. See the full list of clock IDs from: include/dt-bindings/clock/imx8qxp-clock. 6. Documentation/devicetree/bindings/arm/psci.txt have the following properties: - cpu_suspend : Function ID for CPU_SUSPEND operation - cpu_off : Function ID for CPU_OFF operation - cpu_on: Function ID for CPU_ON operation - migrate : Function ID for MIGRATE operation All the above examples uses the firmware identifiers for devices/clocks or for other functionalities and use them directly in DT. These are all somewhat similar to TI sysfw which runs on a micro-controller and tries to abstract certain functionalities from HLOS. There are many more such examples but I listed only a few users. The feedback you are providing is not going to work for any of the above listed firmware interfaces. Thanks and regards, Lokesh
RE: [PATCH V3 2/4] firmware: imx: enable imx scu general irq function
> From: Anson Huang
> Sent: Tuesday, February 19, 2019 11:11 AM
>
> The System Controller Firmware (SCFW) controls RTC, thermal and WDOG etc.,
> these resources' interrupt function are managed by SCU. When any IRQ
> pending, SCU will notify Linux via MU general interrupt channel #3, and Linux
> kernel needs to call SCU APIs to get IRQ status and notify each module to
> handle the interrupt.
>
> Since there is no data transmission for SCU IRQ notification, so doorbell mode
> is used for this MU channel, and SCU driver will use notifier mechanism to
> broadcast to every module which registers the SCU block notifier.
>
> Signed-off-by: Anson Huang
> ---
> No change since V2.
> ---
> drivers/firmware/imx/imx-scu.c | 101
> +++
> include/linux/firmware/imx/sci.h | 3 ++
> 2 files changed, 104 insertions(+)
>
> diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c
> index 2bb1a19..e93bea5 100644
> --- a/drivers/firmware/imx/imx-scu.c
> +++ b/drivers/firmware/imx/imx-scu.c
> @@ -7,6 +7,7 @@
> *
> */
>
> +#include
> #include
> #include
> #include
> @@ -21,6 +22,8 @@
>
> #define SCU_MU_CHAN_NUM 8
> #define MAX_RX_TIMEOUT (msecs_to_jiffies(30))
> +#define IMX_SC_IRQ_FUNC_STATUS 2
> +#define IMX_SC_IRQ_NUM_GROUP 6
>
> struct imx_sc_chan {
> struct imx_sc_ipc *sc_ipc;
> @@ -77,7 +80,23 @@ static int imx_sc_linux_errmap[IMX_SC_ERR_LAST] = {
> -EIO,/* IMX_SC_ERR_FAIL */
> };
>
> +struct imx_sc_msg_irq_get_status {
> + struct imx_sc_rpc_msg hdr;
> + union {
> + struct {
> + u16 resource;
> + u8 group;
> + u8 reserved;
> + } send;
} __packed req
> + struct {
> + u32 status;
> + } receive;
resp
> + } data;
> +} __packed;
No need __packed anymore
> +
> static struct imx_sc_ipc *imx_sc_ipc_handle;
> +static struct work_struct imx_sc_general_irq_work; static
> +BLOCKING_NOTIFIER_HEAD(imx_scu_notifier_chain);
>
> static inline int imx_sc_to_linux_errno(int errno) { @@ -194,6 +213,86 @@
> int imx_scu_call_rpc(struct imx_sc_ipc *sc_ipc, void *msg, bool have_resp) }
> EXPORT_SYMBOL(imx_scu_call_rpc);
>
> +int imx_scu_register_notifier(struct notifier_block *nb) {
> + return blocking_notifier_chain_register(_scu_notifier_chain, nb);
> +} EXPORT_SYMBOL(imx_scu_register_notifier);
> +
> +int imx_scu_unregister_notifier(struct notifier_block *nb) {
> + return blocking_notifier_chain_unregister(_scu_notifier_chain,
> +nb); } EXPORT_SYMBOL(imx_scu_unregister_notifier);
> +
> +static int imx_scu_notifier_call_chain(unsigned long status, u8 *group)
> +{
> + return blocking_notifier_call_chain(_scu_notifier_chain,
> + status, (void *)group);
> +}
> +
> +static void imx_scu_general_irq_work_handler(struct work_struct *work)
> +{
> + struct imx_sc_msg_irq_get_status msg;
> + struct imx_sc_rpc_msg *hdr =
> + u32 irq_status;
> + int ret;
> + u8 i;
> +
> + for (i = 0; i < IMX_SC_IRQ_NUM_GROUP; i++) {
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_IRQ;
> + hdr->func = IMX_SC_IRQ_FUNC_STATUS;
> + hdr->size = 2;
> +
> + msg.data.send.resource = IMX_SC_R_MU_1A;
Please make sure if it's fixed to MU_1A.
> + msg.data.send.group = i;
> +
> + ret = imx_scu_call_rpc(imx_sc_ipc_handle, , true);
> + if (ret) {
> + pr_err("get irq status failed, ret %d\n", ret);
> + return;
> + }
> +
> + irq_status = msg.data.receive.status;
> + if (!irq_status)
> + continue;
> +
> + imx_scu_notifier_call_chain(irq_status, );
> + }
> +}
> +
> +static void imx_scu_rxdb_callback(struct mbox_client *c, void *msg) {
> + schedule_work(_sc_general_irq_work);
> +}
> +
> +static int imx_scu_enable_general_irq_channel(struct device *dev) {
> + struct mbox_client *cl;
> + struct mbox_chan *ch;
> + int ret = 0;
> +
> + cl = devm_kzalloc(dev, sizeof(*cl), GFP_KERNEL);
> + if (!cl)
> + return -ENOMEM;
> +
> + cl->dev = dev;
> + cl->rx_callback = imx_scu_rxdb_callback;
> +
> + /* SCU general IRQ uses general interrupt channel 3 */
> + ch = mbox_request_channel_byname(cl, "gi3");
> + if (IS_ERR(ch)) {
> + ret = PTR_ERR(ch);
> + dev_err(dev, "failed to request mbox chan gi3, ret %d\n", ret);
> + return ret;
return PTR_ERR(ch)
> + }
> +
> + INIT_WORK(_sc_general_irq_work,
> imx_scu_general_irq_work_handler);
> +
> + return ret;
> +}
> +
> static int imx_scu_probe(struct platform_device *pdev) {
> struct device *dev = >dev;
> @@ -246,6 +345,8 @@ static int imx_scu_probe(struct platform_device
>
[PATCH] r8152: Fix an error on RTL8153-BD MAC Address Passthrough support
From: David Chen
RTL8153-BD is used in Dell DA300 type-C dongle.
Added RTL8153-BD support to activate MAC address pass through on DA300.
Apply correction on previously submitted patch in net.git tree.
Signed-off-by: David Chen
---
drivers/net/usb/r8152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ada6baf8847a..86c8c64fbb0f 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1179,7 +1179,7 @@ static int vendor_mac_passthru_addr_read(struct r8152
*tp, struct sockaddr *sa)
} else {
/* test for RTL8153-BND and RTL8153-BD */
ocp_data = ocp_read_byte(tp, MCU_TYPE_USB, USB_MISC_1);
- if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK)) {
+ if ((ocp_data & BND_MASK) == 0 && (ocp_data & BD_MASK) == 0) {
netif_dbg(tp, probe, tp->netdev,
"Invalid variant for MAC pass through\n");
return -ENODEV;
--
2.19.1
Re
Good day, I did send you an email on charity works and I dont know if you got it.Please reach me for updates or let me know if to resend Pablo Mancilla
Re: linux-next: Fixes tag needs some work in the net-next tree
Hi Vinod, On Wed, 20 Feb 2019 10:10:55 +0530 Vinod Koul wrote: > > Dave would you like to drop this and me sending updated patch or > something else.. Dave doesn't rebase/reset net-next, so we will just have to use this as a learning experience :-) -- Cheers, Stephen Rothwell pgpUuF3aMJ8b1.pgp Description: OpenPGP digital signature
RE: [PATCH V3 1/4] dt-bindings: fsl: scu: add general interrupt support
> From: Anson Huang
> Sent: Tuesday, February 19, 2019 11:11 AM
> Subject: [PATCH V3 1/4] dt-bindings: fsl: scu: add general interrupt support
>
> Add scu general interrupt function support.
>
> Signed-off-by: Anson Huang
> Reviewed-by: Rob Herring
> ---
> No change since V2.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 18
> --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index f388ec6..e5def3e 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -22,9 +22,11 @@ Required properties:
> ---
> - compatible:should be "fsl,imx-scu".
> - mbox-names:should include "tx0", "tx1", "tx2", "tx3",
> -"rx0", "rx1", "rx2", "rx3".
> -- mboxes:List of phandle of 4 MU channels for tx and 4 MU channels
> - for rx. All 8 MU channels must be in the same MU instance.
> +"rx0", "rx1", "rx2", "rx3",
> +"gi3".
Should it be optional as SCU firmware does not require it for normal function?
And as MU also support sending interrupt via GIRn register,
How about using gip3 to distinguish sending general purpose interrupt?
Regards
Dong Aisheng
> +- mboxes:List of phandle of 4 MU channels for tx, 4 MU channels for
> + rx, and 1 MU channel for general interrupt. All 9 MU channels
> + must be in the same MU instance.
> Cross instances are not allowed. The MU instance can only
> be one of LSIO MU0~M4 for imx8qxp and imx8qm. Users need
> to make sure use the one which is not conflict with other @@
> -34,6
> +36,7 @@ Required properties:
> Channel 1 must be "tx1" or "rx1".
> Channel 2 must be "tx2" or "rx2".
> Channel 3 must be "tx3" or "rx3".
> + General interrupt channel must be "gi3".
This can be:
General interrupt Rx channel must be "gip3"
Regards
Dong Aisheng
> e.g.
> mboxes = <_mu1 0 0
> _mu1 0 1
> @@ -42,7 +45,8 @@ Required properties:
> _mu1 1 0
> _mu1 1 1
> _mu1 1 2
> - _mu1 1 3>;
> + _mu1 1 3
> + _mu1 3 3>;
> See Documentation/devicetree/bindings/mailbox/fsl,mu.txt
> for detailed mailbox binding.
>
> @@ -153,7 +157,8 @@ firmware {
> scu {
> compatible = "fsl,imx-scu";
> mbox-names = "tx0", "tx1", "tx2", "tx3",
> - "rx0", "rx1", "rx2", "rx3";
> + "rx0", "rx1", "rx2", "rx3",
> + "gi3";
> mboxes = <_mu1 0 0
> _mu1 0 1
> _mu1 0 2
> @@ -161,7 +166,8 @@ firmware {
> _mu1 1 0
> _mu1 1 1
> _mu1 1 2
> - _mu1 1 3>;
> + _mu1 1 3
> + _mu1 3 3>;
>
> clk: clk {
> compatible = "fsl,imx8qxp-clk", "fsl,scu-clk";
> --
> 2.7.4
[RESEND PATCH 0/7] Add FOLL_LONGTERM to GUP fast and use it
From: Ira Weiny Resending these as I had only 1 minor comment which I believe we have covered in this series. I was anticipating these going through the mm tree as they depend on a cleanup patch there and the IB changes are very minor. But they could just as well go through the IB tree. NOTE: This series depends on my clean up patch to remove the write parameter from gup_fast_permitted()[1] HFI1, qib, and mthca, use get_user_pages_fast() due to it performance advantages. These pages can be held for a significant time. But get_user_pages_fast() does not protect against mapping of FS DAX pages. Introduce FOLL_LONGTERM and use this flag in get_user_pages_fast() which retains the performance while also adding the FS DAX checks. XDP has also shown interest in using this functionality.[2] In addition we change get_user_pages() to use the new FOLL_LONGTERM flag and remove the specialized get_user_pages_longterm call. [1] https://lkml.org/lkml/2019/2/11/237 [2] https://lkml.org/lkml/2019/2/11/1789 Ira Weiny (7): mm/gup: Replace get_user_pages_longterm() with FOLL_LONGTERM mm/gup: Change write parameter to flags in fast walk mm/gup: Change GUP fast to use flags rather than a write 'bool' mm/gup: Add FOLL_LONGTERM capability to GUP fast IB/hfi1: Use the new FOLL_LONGTERM flag to get_user_pages_fast() IB/qib: Use the new FOLL_LONGTERM flag to get_user_pages_fast() IB/mthca: Use the new FOLL_LONGTERM flag to get_user_pages_fast() arch/mips/mm/gup.c | 11 +- arch/powerpc/kvm/book3s_64_mmu_hv.c | 4 +- arch/powerpc/kvm/e500_mmu.c | 2 +- arch/powerpc/mm/mmu_context_iommu.c | 4 +- arch/s390/kvm/interrupt.c | 2 +- arch/s390/mm/gup.c | 12 +- arch/sh/mm/gup.c| 11 +- arch/sparc/mm/gup.c | 9 +- arch/x86/kvm/paging_tmpl.h | 2 +- arch/x86/kvm/svm.c | 2 +- drivers/fpga/dfl-afu-dma-region.c | 2 +- drivers/gpu/drm/via/via_dmablit.c | 3 +- drivers/infiniband/core/umem.c | 5 +- drivers/infiniband/hw/hfi1/user_pages.c | 5 +- drivers/infiniband/hw/mthca/mthca_memfree.c | 3 +- drivers/infiniband/hw/qib/qib_user_pages.c | 8 +- drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +- drivers/infiniband/hw/usnic/usnic_uiom.c| 9 +- drivers/media/v4l2-core/videobuf-dma-sg.c | 6 +- drivers/misc/genwqe/card_utils.c| 2 +- drivers/misc/vmw_vmci/vmci_host.c | 2 +- drivers/misc/vmw_vmci/vmci_queue_pair.c | 6 +- drivers/platform/goldfish/goldfish_pipe.c | 3 +- drivers/rapidio/devices/rio_mport_cdev.c| 4 +- drivers/sbus/char/oradax.c | 2 +- drivers/scsi/st.c | 3 +- drivers/staging/gasket/gasket_page_table.c | 4 +- drivers/tee/tee_shm.c | 2 +- drivers/vfio/vfio_iommu_spapr_tce.c | 3 +- drivers/vfio/vfio_iommu_type1.c | 3 +- drivers/vhost/vhost.c | 2 +- drivers/video/fbdev/pvr2fb.c| 2 +- drivers/virt/fsl_hypervisor.c | 2 +- drivers/xen/gntdev.c| 2 +- fs/orangefs/orangefs-bufmap.c | 2 +- include/linux/mm.h | 17 +- kernel/futex.c | 2 +- lib/iov_iter.c | 7 +- mm/gup.c| 220 mm/gup_benchmark.c | 5 +- mm/util.c | 8 +- net/ceph/pagevec.c | 2 +- net/rds/info.c | 2 +- net/rds/rdma.c | 3 +- 44 files changed, 232 insertions(+), 180 deletions(-) -- 2.20.1
[RESEND PATCH 1/7] mm/gup: Replace get_user_pages_longterm() with FOLL_LONGTERM
From: Ira Weiny
Rather than have a separate get_user_pages_longterm() call,
introduce FOLL_LONGTERM and change the longterm callers to use
it.
This patch does not change any functionality.
FOLL_LONGTERM can only be supported with get_user_pages() as it
requires vmas to determine if DAX is in use.
Signed-off-by: Ira Weiny
---
drivers/infiniband/core/umem.c | 5 +-
drivers/infiniband/hw/qib/qib_user_pages.c | 8 +-
drivers/infiniband/hw/usnic/usnic_uiom.c | 9 +-
drivers/media/v4l2-core/videobuf-dma-sg.c | 6 +-
drivers/vfio/vfio_iommu_type1.c| 3 +-
include/linux/mm.h | 13 +-
mm/gup.c | 138 -
mm/gup_benchmark.c | 5 +-
8 files changed, 101 insertions(+), 86 deletions(-)
diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index b69d3efa8712..120a40df91b4 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -185,10 +185,11 @@ struct ib_umem *ib_umem_get(struct ib_udata *udata,
unsigned long addr,
while (npages) {
down_read(>mmap_sem);
- ret = get_user_pages_longterm(cur_base,
+ ret = get_user_pages(cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof (struct page *)),
-gup_flags, page_list, vma_list);
+gup_flags | FOLL_LONGTERM,
+page_list, vma_list);
if (ret < 0) {
up_read(>mmap_sem);
goto umem_release;
diff --git a/drivers/infiniband/hw/qib/qib_user_pages.c
b/drivers/infiniband/hw/qib/qib_user_pages.c
index ef8bcf366ddc..1b9368261035 100644
--- a/drivers/infiniband/hw/qib/qib_user_pages.c
+++ b/drivers/infiniband/hw/qib/qib_user_pages.c
@@ -114,10 +114,10 @@ int qib_get_user_pages(unsigned long start_page, size_t
num_pages,
down_read(>mm->mmap_sem);
for (got = 0; got < num_pages; got += ret) {
- ret = get_user_pages_longterm(start_page + got * PAGE_SIZE,
- num_pages - got,
- FOLL_WRITE | FOLL_FORCE,
- p + got, NULL);
+ ret = get_user_pages(start_page + got * PAGE_SIZE,
+num_pages - got,
+FOLL_LONGTERM | FOLL_WRITE | FOLL_FORCE,
+p + got, NULL);
if (ret < 0) {
up_read(>mm->mmap_sem);
goto bail_release;
diff --git a/drivers/infiniband/hw/usnic/usnic_uiom.c
b/drivers/infiniband/hw/usnic/usnic_uiom.c
index 06862a6af185..1d9a182ac163 100644
--- a/drivers/infiniband/hw/usnic/usnic_uiom.c
+++ b/drivers/infiniband/hw/usnic/usnic_uiom.c
@@ -143,10 +143,11 @@ static int usnic_uiom_get_pages(unsigned long addr,
size_t size, int writable,
ret = 0;
while (npages) {
- ret = get_user_pages_longterm(cur_base,
- min_t(unsigned long, npages,
- PAGE_SIZE / sizeof(struct page *)),
- gup_flags, page_list, NULL);
+ ret = get_user_pages(cur_base,
+min_t(unsigned long, npages,
+PAGE_SIZE / sizeof(struct page *)),
+gup_flags | FOLL_LONGTERM,
+page_list, NULL);
if (ret < 0)
goto out;
diff --git a/drivers/media/v4l2-core/videobuf-dma-sg.c
b/drivers/media/v4l2-core/videobuf-dma-sg.c
index 08929c087e27..870a2a526e0b 100644
--- a/drivers/media/v4l2-core/videobuf-dma-sg.c
+++ b/drivers/media/v4l2-core/videobuf-dma-sg.c
@@ -186,12 +186,12 @@ static int videobuf_dma_init_user_locked(struct
videobuf_dmabuf *dma,
dprintk(1, "init user [0x%lx+0x%lx => %d pages]\n",
data, size, dma->nr_pages);
- err = get_user_pages_longterm(data & PAGE_MASK, dma->nr_pages,
-flags, dma->pages, NULL);
+ err = get_user_pages(data & PAGE_MASK, dma->nr_pages,
+flags | FOLL_LONGTERM, dma->pages, NULL);
if (err != dma->nr_pages) {
dma->nr_pages = (err >= 0) ? err : 0;
- dprintk(1, "get_user_pages_longterm: err=%d [%d]\n", err,
+ dprintk(1, "get_user_pages: err=%d [%d]\n", err,
dma->nr_pages);
return err < 0 ? err : -EINVAL;
}
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 73652e21efec..1500bd0bb6da 100644
---
[RESEND PATCH 6/7] IB/qib: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/qib/qib_user_sdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/qib/qib_user_sdma.c
b/drivers/infiniband/hw/qib/qib_user_sdma.c
index 31c523b2a9f5..b53cc0240e02 100644
--- a/drivers/infiniband/hw/qib/qib_user_sdma.c
+++ b/drivers/infiniband/hw/qib/qib_user_sdma.c
@@ -673,7 +673,7 @@ static int qib_user_sdma_pin_pages(const struct qib_devdata
*dd,
else
j = npages;
- ret = get_user_pages_fast(addr, j, 0, pages);
+ ret = get_user_pages_fast(addr, j, FOLL_LONGTERM, pages);
if (ret != j) {
i = 0;
j = ret;
--
2.20.1
[RESEND PATCH 2/7] mm/gup: Change write parameter to flags in fast walk
From: Ira Weiny
In order to support more options in the GUP fast walk, change
the write parameter to flags throughout the call stack.
This patch does not change functionality and passes FOLL_WRITE
where write was previously used.
Signed-off-by: Ira Weiny
---
mm/gup.c | 52 ++--
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index ee96eaff118c..681388236106 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1417,7 +1417,7 @@ static void undo_dev_pagemap(int *nr, int nr_start,
struct page **pages)
#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL
static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
-int write, struct page **pages, int *nr)
+unsigned int flags, struct page **pages, int *nr)
{
struct dev_pagemap *pgmap = NULL;
int nr_start = *nr, ret = 0;
@@ -1435,7 +1435,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
unsigned long end,
if (pte_protnone(pte))
goto pte_unmap;
- if (!pte_access_permitted(pte, write))
+ if (!pte_access_permitted(pte, flags & FOLL_WRITE))
goto pte_unmap;
if (pte_devmap(pte)) {
@@ -1487,7 +1487,7 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
unsigned long end,
* useful to have gup_huge_pmd even if we can't operate on ptes.
*/
static int gup_pte_range(pmd_t pmd, unsigned long addr, unsigned long end,
-int write, struct page **pages, int *nr)
+unsigned int flags, struct page **pages, int *nr)
{
return 0;
}
@@ -1570,12 +1570,12 @@ static int __gup_device_huge_pud(pud_t pud, pud_t
*pudp, unsigned long addr,
#endif
static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp, unsigned long addr,
- unsigned long end, int write, struct page **pages, int *nr)
+ unsigned long end, unsigned int flags, struct page **pages, int
*nr)
{
struct page *head, *page;
int refs;
- if (!pmd_access_permitted(orig, write))
+ if (!pmd_access_permitted(orig, flags & FOLL_WRITE))
return 0;
if (pmd_devmap(orig))
@@ -1608,12 +1608,12 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp,
unsigned long addr,
}
static int gup_huge_pud(pud_t orig, pud_t *pudp, unsigned long addr,
- unsigned long end, int write, struct page **pages, int *nr)
+ unsigned long end, unsigned int flags, struct page **pages, int
*nr)
{
struct page *head, *page;
int refs;
- if (!pud_access_permitted(orig, write))
+ if (!pud_access_permitted(orig, flags & FOLL_WRITE))
return 0;
if (pud_devmap(orig))
@@ -1646,13 +1646,13 @@ static int gup_huge_pud(pud_t orig, pud_t *pudp,
unsigned long addr,
}
static int gup_huge_pgd(pgd_t orig, pgd_t *pgdp, unsigned long addr,
- unsigned long end, int write,
+ unsigned long end, unsigned int flags,
struct page **pages, int *nr)
{
int refs;
struct page *head, *page;
- if (!pgd_access_permitted(orig, write))
+ if (!pgd_access_permitted(orig, flags & FOLL_WRITE))
return 0;
BUILD_BUG_ON(pgd_devmap(orig));
@@ -1683,7 +1683,7 @@ static int gup_huge_pgd(pgd_t orig, pgd_t *pgdp, unsigned
long addr,
}
static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
- int write, struct page **pages, int *nr)
+ unsigned int flags, struct page **pages, int *nr)
{
unsigned long next;
pmd_t *pmdp;
@@ -1705,7 +1705,7 @@ static int gup_pmd_range(pud_t pud, unsigned long addr,
unsigned long end,
if (pmd_protnone(pmd))
return 0;
- if (!gup_huge_pmd(pmd, pmdp, addr, next, write,
+ if (!gup_huge_pmd(pmd, pmdp, addr, next, flags,
pages, nr))
return 0;
@@ -1715,9 +1715,9 @@ static int gup_pmd_range(pud_t pud, unsigned long addr,
unsigned long end,
* pmd format and THP pmd format
*/
if (!gup_huge_pd(__hugepd(pmd_val(pmd)), addr,
-PMD_SHIFT, next, write, pages, nr))
+PMD_SHIFT, next, flags, pages, nr))
return 0;
- } else if (!gup_pte_range(pmd, addr, next, write, pages, nr))
+ } else if (!gup_pte_range(pmd, addr, next, flags, pages, nr))
return 0;
} while (pmdp++, addr = next, addr != end);
@@ -1725,7 +1725,7 @@ static int gup_pmd_range(pud_t pud, unsigned long addr,
unsigned long end,
}
static int
[RESEND PATCH 7/7] IB/mthca: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
From: Ira Weiny Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against FS DAX pages being mapped. Signed-off-by: Ira Weiny --- drivers/infiniband/hw/mthca/mthca_memfree.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c b/drivers/infiniband/hw/mthca/mthca_memfree.c index 112d2f38e0de..8ff0e90d7564 100644 --- a/drivers/infiniband/hw/mthca/mthca_memfree.c +++ b/drivers/infiniband/hw/mthca/mthca_memfree.c @@ -472,7 +472,8 @@ int mthca_map_user_db(struct mthca_dev *dev, struct mthca_uar *uar, goto out; } - ret = get_user_pages_fast(uaddr & PAGE_MASK, 1, FOLL_WRITE, pages); + ret = get_user_pages_fast(uaddr & PAGE_MASK, 1, + FOLL_WRITE | FOLL_LONGTERM, pages); if (ret < 0) goto out; -- 2.20.1
Re: [PATCH v2 13/15] ARM: dts: milbeaut: Add device tree set for the Milbeaut M10V board
Hi,
On 2019/02/19 19:11, Arnd Bergmann wrote:
On Tue, Feb 19, 2019 at 6:11 AM Sugaya, Taichi
wrote:
Hi,
Thank you for you comments.
On 2019/02/18 21:09, Arnd Bergmann wrote:
On Fri, Feb 8, 2019 at 1:28 PM Sugaya Taichi
wrote:
+
+ aliases {
+ serial1 =
+ };
Maybe start with serial0 here? It seems unusual to start
counting at 1.
The M10V evaluation board(EVB) uses a console with uart ch1, so this
alias number is derived from the used channel one.
Therefore it is no problem to change the alias number to 0.
The alias should normally reflect whatever is printed on the board,
if there are no labels, the convention is to start with zero, regardless
of what internal uart is connected to it.
I got it.
I use a "serial0" beacause there are no labels about uart ch on M10V EVB.
Thanks,
Sugaya Taichi
Arnd
[RESEND PATCH 5/7] IB/hfi1: Use the new FOLL_LONGTERM flag to get_user_pages_fast()
From: Ira Weiny
Use the new FOLL_LONGTERM to get_user_pages_fast() to protect against
FS DAX pages being mapped.
Signed-off-by: Ira Weiny
---
drivers/infiniband/hw/hfi1/user_pages.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c
b/drivers/infiniband/hw/hfi1/user_pages.c
index 78ccacaf97d0..6a7f9cd5a94e 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -104,9 +104,11 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, unsigned
long vaddr, size_t np
bool writable, struct page **pages)
{
int ret;
+ unsigned int gup_flags = writable ? FOLL_WRITE : 0;
- ret = get_user_pages_fast(vaddr, npages, writable ? FOLL_WRITE : 0,
- pages);
+ gup_flags |= FOLL_LONGTERM;
+
+ ret = get_user_pages_fast(vaddr, npages, gup_flags, pages);
if (ret < 0)
return ret;
--
2.20.1
[RESEND PATCH 3/7] mm/gup: Change GUP fast to use flags rather than a write 'bool'
From: Ira Weiny
To facilitate additional options to get_user_pages_fast() change the
singular write parameter to be gup_flags.
This patch does not change any functionality. New functionality will
follow in subsequent patches.
Some of the get_user_pages_fast() call sites were unchanged because they
already passed FOLL_WRITE or 0 for the write parameter.
Signed-off-by: Ira Weiny
---
arch/mips/mm/gup.c | 11 ++-
arch/powerpc/kvm/book3s_64_mmu_hv.c| 4 ++--
arch/powerpc/kvm/e500_mmu.c| 2 +-
arch/powerpc/mm/mmu_context_iommu.c| 4 ++--
arch/s390/kvm/interrupt.c | 2 +-
arch/s390/mm/gup.c | 12 ++--
arch/sh/mm/gup.c | 11 ++-
arch/sparc/mm/gup.c| 9 +
arch/x86/kvm/paging_tmpl.h | 2 +-
arch/x86/kvm/svm.c | 2 +-
drivers/fpga/dfl-afu-dma-region.c | 2 +-
drivers/gpu/drm/via/via_dmablit.c | 3 ++-
drivers/infiniband/hw/hfi1/user_pages.c| 3 ++-
drivers/misc/genwqe/card_utils.c | 2 +-
drivers/misc/vmw_vmci/vmci_host.c | 2 +-
drivers/misc/vmw_vmci/vmci_queue_pair.c| 6 --
drivers/platform/goldfish/goldfish_pipe.c | 3 ++-
drivers/rapidio/devices/rio_mport_cdev.c | 4 +++-
drivers/sbus/char/oradax.c | 2 +-
drivers/scsi/st.c | 3 ++-
drivers/staging/gasket/gasket_page_table.c | 4 ++--
drivers/tee/tee_shm.c | 2 +-
drivers/vfio/vfio_iommu_spapr_tce.c| 3 ++-
drivers/vhost/vhost.c | 2 +-
drivers/video/fbdev/pvr2fb.c | 2 +-
drivers/virt/fsl_hypervisor.c | 2 +-
drivers/xen/gntdev.c | 2 +-
fs/orangefs/orangefs-bufmap.c | 2 +-
include/linux/mm.h | 4 ++--
kernel/futex.c | 2 +-
lib/iov_iter.c | 7 +--
mm/gup.c | 10 +-
mm/util.c | 8
net/ceph/pagevec.c | 2 +-
net/rds/info.c | 2 +-
net/rds/rdma.c | 3 ++-
36 files changed, 81 insertions(+), 65 deletions(-)
diff --git a/arch/mips/mm/gup.c b/arch/mips/mm/gup.c
index 0d14e0d8eacf..4c2b4483683c 100644
--- a/arch/mips/mm/gup.c
+++ b/arch/mips/mm/gup.c
@@ -235,7 +235,7 @@ int __get_user_pages_fast(unsigned long start, int
nr_pages, int write,
* get_user_pages_fast() - pin user pages in memory
* @start: starting user address
* @nr_pages: number of pages from start to pin
- * @write: whether pages will be written to
+ * @gup_flags: flags modifying pin behaviour
* @pages: array that receives pointers to the pages pinned.
* Should be at least nr_pages long.
*
@@ -247,8 +247,8 @@ int __get_user_pages_fast(unsigned long start, int
nr_pages, int write,
* requested. If nr_pages is 0 or negative, returns 0. If no pages
* were pinned, returns -errno.
*/
-int get_user_pages_fast(unsigned long start, int nr_pages, int write,
- struct page **pages)
+int get_user_pages_fast(unsigned long start, int nr_pages,
+ unsigned int gup_flags, struct page **pages)
{
struct mm_struct *mm = current->mm;
unsigned long addr, len, end;
@@ -273,7 +273,8 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
next = pgd_addr_end(addr, end);
if (pgd_none(pgd))
goto slow;
- if (!gup_pud_range(pgd, addr, next, write, pages, ))
+ if (!gup_pud_range(pgd, addr, next, gup_flags & FOLL_WRITE,
+ pages, ))
goto slow;
} while (pgdp++, addr = next, addr != end);
local_irq_enable();
@@ -289,7 +290,7 @@ int get_user_pages_fast(unsigned long start, int nr_pages,
int write,
pages += nr;
ret = get_user_pages_unlocked(start, (end - start) >> PAGE_SHIFT,
- pages, write ? FOLL_WRITE : 0);
+ pages, gup_flags);
/* Have to be a bit careful with return values */
if (nr > 0) {
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index bd2dcfbf00cd..8fcb0a921e46 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -582,7 +582,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct
kvm_vcpu *vcpu,
/* If writing != 0, then the HPTE must allow writing, if we get here */
write_ok = writing;
hva = gfn_to_hva_memslot(memslot, gfn);
- npages = get_user_pages_fast(hva, 1, writing, pages);
+ npages = get_user_pages_fast(hva, 1,
[RESEND PATCH 4/7] mm/gup: Add FOLL_LONGTERM capability to GUP fast
From: Ira Weiny
DAX pages were previously unprotected from longterm pins when users
called get_user_pages_fast().
Use the new FOLL_LONGTERM flag to check for DEVMAP pages and fall
back to regular GUP processing if a DEVMAP page is encountered.
Signed-off-by: Ira Weiny
---
mm/gup.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/mm/gup.c b/mm/gup.c
index 6f32d36b3c5b..f7e759c523bb 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1439,6 +1439,9 @@ static int gup_pte_range(pmd_t pmd, unsigned long addr,
unsigned long end,
goto pte_unmap;
if (pte_devmap(pte)) {
+ if (unlikely(flags & FOLL_LONGTERM))
+ goto pte_unmap;
+
pgmap = get_dev_pagemap(pte_pfn(pte), pgmap);
if (unlikely(!pgmap)) {
undo_dev_pagemap(nr, nr_start, pages);
@@ -1578,8 +1581,11 @@ static int gup_huge_pmd(pmd_t orig, pmd_t *pmdp,
unsigned long addr,
if (!pmd_access_permitted(orig, flags & FOLL_WRITE))
return 0;
- if (pmd_devmap(orig))
+ if (pmd_devmap(orig)) {
+ if (unlikely(flags & FOLL_LONGTERM))
+ return 0;
return __gup_device_huge_pmd(orig, pmdp, addr, end, pages, nr);
+ }
refs = 0;
page = pmd_page(orig) + ((addr & ~PMD_MASK) >> PAGE_SHIFT);
@@ -1904,8 +1910,20 @@ int get_user_pages_fast(unsigned long start, int
nr_pages,
start += nr << PAGE_SHIFT;
pages += nr;
- ret = get_user_pages_unlocked(start, nr_pages - nr, pages,
- gup_flags);
+ if (gup_flags & FOLL_LONGTERM) {
+ down_read(>mm->mmap_sem);
+ ret = __gup_longterm_locked(current, current->mm,
+ start, nr_pages - nr,
+ pages, NULL, gup_flags);
+ up_read(>mm->mmap_sem);
+ } else {
+ /*
+* retain FAULT_FOLL_ALLOW_RETRY optimization if
+* possible
+*/
+ ret = get_user_pages_unlocked(start, nr_pages - nr,
+ pages, gup_flags);
+ }
/* Have to be a bit careful with return values */
if (nr > 0) {
--
2.20.1
Re: [RFC PATCH 00/31] Generating physically contiguous memory after page allocation
On 2/19/19 9:19 PM, Zi Yan wrote: > On 19 Feb 2019, at 19:18, Mike Kravetz wrote: >> Another high level question. One of the benefits of this approach is >> that exchanging pages does not require N free pages as you describe >> above. This assumes that the vma which we are trying to make contiguous >> is already populated. If it is not populated, then you also need to >> have N free pages. Correct? If this is true, then is the expected use >> case to first populate a vma, and then try to make contiguous? I would >> assume that if it is not populated and a request to make contiguous is >> given, we should try to allocate/populate the vma with contiguous pages >> at that time? > > Yes, I assume the pages within the VMA are already populated but not > contiguous > yet. > > My approach considers memory contiguity as an on-demand resource. In some > phases > of an application, accelerators or RDMA controllers would process/transfer > data > in one > or more VMAs, at which time contiguous memory can help reduce address > translation > overheads or lift certain constraints. And different VMAs could be processed > at > different program phases, thus it might be hard to get contiguous memory for > all > these VMAs at the allocation time using alloc_contig_pages(). My approach can > help get contiguous memory later, when the demand comes. > > For some cases, you definitely can use alloc_contig_pages() to give users > a contiguous area at page allocation time, if you know the user is going to > use > this > area for accelerator data processing or as a RDMA buffer and the area size is > fixed. > > In addition, we can also use khugepaged approach, having a daemon periodically > scan VMAs and use alloc_contig_pages() to convert non-contiguous pages in a > VMA > to contiguous pages, but it would require N free pages during the conversion. > > In sum, my approach complements alloc_contig_pages() and provides more > flexibility. > It is not trying to replaces alloc_contig_pages(). Thank you for the explanation. That makes sense. I have mostly been thinking about contiguous memory from an allocation perspective and did not really consider other use cases. -- Mike Kravetz
[PATCH v1 2/2] arm64: dts: renesas: r8a7796: use extended audio dmac register
Basic audio dmac register only supports busif from 0 to 3, in order to use busif4 ~ busif7, extended audio dmac register need to be used Signed-off-by: Jiada Wang --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi index 0648d12778ed..1ca487480c79 100644 --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi @@ -1775,7 +1775,7 @@ <0 0xec5a 0 0x100>, /* ADG */ <0 0xec54 0 0x1000>, /* SSIU */ <0 0xec541000 0 0x280>, /* SSI */ - <0 0xec74 0 0x200>; /* Audio DMAC peri peri*/ + <0 0xec76 0 0x200>; /* Audio DMAC peri peri*/ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; clocks = < CPG_MOD 1005>, -- 2.19.2
[PATCH v1 0/2] rsnd: dts: change to use extended audio dmac register
According to user reference manual for R-CAR H3 and M3-W SoCs, in order to access busif4 ~ busif7, extended audio dmac registers (PDMASAREn, PDMADAREn, PDMACHCREn) need to be used, rather than basic audio dmac registers (PDMASARn, PDMADARn, PDMACHCRn) This patch set updates H3 (= r8a7795) and M3-W (= r8a7796) to use extended audio dmac registers Jiada Wang (2): arm64: dts: renesas: r8a7795: use extended audio dmac register arm64: dts: renesas: r8a7796: use extended audio dmac register arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.19.2
[PATCH v1 1/2] arm64: dts: renesas: r8a7795: use extended audio dmac register
Basic audio dmac register only supports busif from 0 to 3, in order to use busif4 ~ busif7, extended audio dmac register need to be used. Signed-off-by: Jiada Wang --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renesas/r8a7795.dtsi index af9605d5db27..3adf0663451a 100644 --- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi @@ -1836,7 +1836,7 @@ <0 0xec5a 0 0x100>, /* ADG */ <0 0xec54 0 0x1000>, /* SSIU */ <0 0xec541000 0 0x280>, /* SSI */ - <0 0xec74 0 0x200>; /* Audio DMAC peri peri*/ + <0 0xec76 0 0x200>; /* Audio DMAC peri peri*/ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; clocks = < CPG_MOD 1005>, -- 2.19.2
Re: [RFC PATCH 00/31] Generating physically contiguous memory after page allocation
On 19 Feb 2019, at 19:18, Mike Kravetz wrote: On 2/19/19 6:33 PM, Zi Yan wrote: On 19 Feb 2019, at 17:42, Mike Kravetz wrote: On 2/15/19 2:08 PM, Zi Yan wrote: Thanks for working on this issue! I have not yet had a chance to take a look at the code. However, I do have some general questions/comments on the approach. Thanks for replying. The code is very intrusive and has a lot of hacks, so it is OK for us to discuss the general idea first. :) Patch structure The patchset I developed to generate physically contiguous memory/arbitrary sized pages merely moves pages around. There are three components in this patchset: 1) a new page migration mechanism, called exchange pages, that exchanges the content of two in-use pages instead of performing two back-to-back page migration. It saves on overheads and avoids page reclaim and memory compaction in the page allocation path, although it is not strictly required if enough free memory is available in the system. 2) a new mechanism that utilizes both page migration and exchange pages to produce physically contiguous memory/arbitrary sized pages without allocating any new pages, unlike what khugepaged does. It works on per-VMA basis, creating physically contiguous memory out of each VMA, which is virtually contiguous. A simple range tree is used to ensure no two VMAs are overlapping with each other in the physical address space. This appears to be a new approach to generating contiguous areas. Previous attempts had relied on finding a contiguous area that can then be used for various purposes including user mappings. Here, you take an existing mapping and make it contiguous. [RFC PATCH 04/31] mm: add mem_defrag functionality talks about creating a (VPN, PFN) anchor pair for each vma and then using this pair as the base for creating a contiguous area. I'm curious, how 'fixed' is the anchor? As you know, there could be a non-movable page in the PFN range. As a result, you will not be able to create a contiguous area starting at that PFN. In such a case, do we try another PFN? I know this could result in much page shuffling. I'm just trying to figure out how we satisfy a user who really wants a contiguous area. Is there some method to keep trying? Good question. The anchor is determined on a per-VMA basis, which can be changed easily, but in this patchiest, I used a very simple strategy — making all VMAs not overlapping in the physical address space to get maximum overall contiguity and not changing anchors even if non-moveable pages are encountered when generating physically contiguous pages. Basically, first VMA1 in the virtual address space has its anchor as (VMA1_start_VPN, ZONE_start_PFN), second VMA1 has its anchor as (VMA2_start_VPN, ZONE_start_PFN + VMA1_size), and so on. This makes all VMA not overlapping in physical address space during contiguous memory generation. When there is a non-moveable page, the anchor will not be changed, because no matter whether we assign a new anchor or not, the contiguous pages stops at the non-moveable page. If we are trying to get a new anchor, more effort is needed to avoid overlapping new anchor with existing contiguous pages. Any overlapping will nullify the existing contiguous pages. To satisfy a user who wants a contiguous area with N pages, the minimal distance between any two non-moveable pages should be bigger than N pages in the system memory. Otherwise, nothing would work. If there is such an area (PFN1, PFN1+N) in the physical address space, you can set the anchor to (VPN_USER, PFN1) and use exchange_pages() to generate a contiguous area with N pages. Instead, alloc_contig_pages(PFN1, PFN1+N, …) could also work, but only at page allocation time. It also requires the system has N free pages when alloc_contig_pages() are migrating the pages in (PFN1, PFN1+N) away, or you need to swap pages to make the space. Let me know if this makes sense to you. Yes, that is how I expected the implementation would work. Thank you. Another high level question. One of the benefits of this approach is that exchanging pages does not require N free pages as you describe above. This assumes that the vma which we are trying to make contiguous is already populated. If it is not populated, then you also need to have N free pages. Correct? If this is true, then is the expected use case to first populate a vma, and then try to make contiguous? I would assume that if it is not populated and a request to make contiguous is given, we should try to allocate/populate the vma with contiguous pages at that time? Yes, I assume the pages within the VMA are already populated but not contiguous yet. My approach considers memory contiguity as an on-demand resource. In some phases of an application, accelerators or RDMA controllers would process/transfer data in one or more VMAs, at which time contiguous memory can help reduce
[PATCH 06/10] staging: mt7621-mmc: Bill the caller for I/O time
When waiting on completions, use the _io variant so the caller is
charged as using I/O.
This should have no effect on the module's functionality, only improve
CPU accounting.
Signed-off-by: George Hilliard
---
drivers/staging/mt7621-mmc/sd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 97ed7510e96d..f12f9d6611c9 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -494,7 +494,7 @@ static unsigned int msdc_command_resp(struct msdc_host
*host,
//sdr_set_bits(host->base + MSDC_INTEN, wints);
spin_unlock(>lock);
- if (!wait_for_completion_timeout(>cmd_done, 10 * timeout)) {
+ if (!wait_for_completion_io_timeout(>cmd_done, 10 * timeout)) {
dev_err(mmc_dev(host->mmc),
"%d -> XXX CMD<%d> wait_for_completion timeout
ARG<0x%.8x>\n",
host->id, opcode, cmd->arg);
@@ -697,7 +697,7 @@ static int msdc_do_request(struct mmc_host *mmc, struct
mmc_request *mrq)
msdc_dma_start(host);
spin_unlock(>lock);
- if (!wait_for_completion_timeout(>xfer_done,
DAT_TIMEOUT)) {
+ if (!wait_for_completion_io_timeout(>xfer_done,
DAT_TIMEOUT)) {
dev_err(mmc_dev(host->mmc),
"%d -> XXX CMD<%d> wait xfer_done<%d>
timeout!!\n",
host->id, cmd->opcode,
--
2.20.1
[PATCH 02/10] staging: mt7621-mmc: Remove obsolete comments
These comments don't contain useful code or alternate implementation
ideas. Remove them.
Signed-off-by: George Hilliard
---
drivers/staging/mt7621-mmc/sd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 4b26ec896a96..1d357b898952 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -100,7 +100,6 @@ static int cd_active_low = 1;
struct msdc_hw msdc0_hw = {
.clk_src= 0,
.flags = MSDC_CD_PIN_EN | MSDC_REMOVABLE,
-// .flags = MSDC_WP_PIN_EN | MSDC_CD_PIN_EN | MSDC_REMOVABLE,
};
/* end of +++ */
@@ -1671,7 +1670,6 @@ static int msdc_drv_probe(struct platform_device *pdev)
host->timeout_clks = DEFAULT_DTOC * 65536;
host->mrq = NULL;
- //init_MUTEX(>sem); /* we don't need to support multiple threads
access */
dma_coerce_mask_and_coherent(mmc_dev(mmc), DMA_BIT_MASK(32));
--
2.20.1
[PATCH 03/10] staging: mt7621-mmc: Remove references to nonexistent mt7621_spi_ops
This struct does not exist, and when it is looked up in the
compatibility tree, it returns null. Remove these nonfunctional lines.
Signed-off-by: George Hilliard
---
drivers/staging/mt7621-spi/spi-mt7621.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/staging/mt7621-spi/spi-mt7621.c
b/drivers/staging/mt7621-spi/spi-mt7621.c
index b509f9fe3346..d260b42ff328 100644
--- a/drivers/staging/mt7621-spi/spi-mt7621.c
+++ b/drivers/staging/mt7621-spi/spi-mt7621.c
@@ -58,8 +58,6 @@ struct mt7621_spi {
unsigned intspeed;
struct clk *clk;
int pending_write;
-
- struct mt7621_spi_ops *ops;
};
static inline struct mt7621_spi *spidev_to_mt7621_spi(struct spi_device *spi)
@@ -330,13 +328,11 @@ static int mt7621_spi_probe(struct platform_device *pdev)
struct resource *r;
int status = 0;
struct clk *clk;
- struct mt7621_spi_ops *ops;
int ret;
match = of_match_device(mt7621_spi_match, >dev);
if (!match)
return -EINVAL;
- ops = (struct mt7621_spi_ops *)match->data;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
base = devm_ioremap_resource(>dev, r);
@@ -375,7 +371,6 @@ static int mt7621_spi_probe(struct platform_device *pdev)
rs->clk = clk;
rs->master = master;
rs->sys_freq = clk_get_rate(rs->clk);
- rs->ops = ops;
rs->pending_write = 0;
dev_info(>dev, "sys_freq: %u\n", rs->sys_freq);
--
2.20.1
[PATCH 10/10] staging: mt7621-mmc: Immediately notify mmc layer of card change detection
There is no need to delay notifying the mmc layer. Schedule the delayed
work to run immediately.
Signed-off-by: George Hilliard
---
drivers/staging/mt7621-mmc/sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 472318a979cb..0a7f8384edf8 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -1355,7 +1355,7 @@ static irqreturn_t msdc_irq(int irq, void *dev_id)
if (intsts & MSDC_INT_CDSC) {
if (host->mmc->caps & MMC_CAP_NEEDS_POLL)
return IRQ_HANDLED;
- schedule_delayed_work(>card_delaywork, HZ);
+ schedule_delayed_work(>card_delaywork, 0);
/* tuning when plug card ? */
}
--
2.20.1
[PATCH 08/10] staging: mt7621-mmc: Check for nonzero number of scatterlist entries
The buffer descriptor setup loop is correct only if it is setting up at least one bd struct. Besides, there is an error somewhere if dma_map_sg() returns 0. So add a paranoid check for this condition. Signed-off-by: George Hilliard --- drivers/staging/mt7621-mmc/sd.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c index 942c0d63d710..736e1d23b391 100644 --- a/drivers/staging/mt7621-mmc/sd.c +++ b/drivers/staging/mt7621-mmc/sd.c @@ -594,7 +594,12 @@ static void msdc_dma_setup(struct msdc_host *host, struct msdc_dma *dma, struct bd *bd; u32 j; - BUG_ON(sglen > MAX_BD_NUM); /* not support currently */ + // Shouldn't happen; we configure the mmc host layer + // based on MAX_BD_NUM: + BUG_ON(sglen > MAX_BD_NUM); + // Correct setup below requires at least one bd + // (and dma_map_sg should not return 0): + BUG_ON(sglen == 0); gpd = dma->gpd; bd = dma->bd; -- 2.20.1
mt7621-mmc driver improvements
This is a series of patches to provide a little TLC for the mt7621-mmc driver. My original goal was to get it working on the MT7688, and I have succeeded. I suspect it will now work on any of the MT762x line. The main change was getting the driver to use the pinctrl subsystem instead of hand-jamming the pinctrl registers -- the bit offsets were only correct for the MT7621. Because of this change, the driver now expects a pinctrl device reference in the mmc controller's device tree node; without it, it will bail out. This could break existing setups that don't specify it because it "just worked" up until now. So currently I just let the old behavior fall away because this is a staging driver. But if this is a problem, the old behavior could be added back as a fallback. Beyond that, there are largely code cleanups and a couple other correctness fixes that I hope are self-explanatory. The TODO list is largely unchanged, aside from the couple of TODO comments in the code that I have addressed. Ultimately, I think this driver could potentially be merged with the "real" mtk-mmc driver as the TODO suggests, but someone who is more familiar with the IP core will have to do that. Mediatek documentation (that I can find) is very sparse. Besides, their codebases have begun to diverge. Feedback welcome!
[PATCH 07/10] staging: mt7621-mmc: Initialize completions a single time during probe
The module was initializing completions whenever it was going to wait on them, and not when the completion was allocated. This is incorrect according to the completion docs: Calling init_completion() on the same completion object twice is most likely a bug [...] Re-initialization is also unnecessary because the module never uses complete_all(). Fix this by only ever initializing the completion a single time. Signed-off-by: George Hilliard --- drivers/staging/mt7621-mmc/sd.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c index f12f9d6611c9..942c0d63d710 100644 --- a/drivers/staging/mt7621-mmc/sd.c +++ b/drivers/staging/mt7621-mmc/sd.c @@ -468,7 +468,9 @@ static unsigned int msdc_command_start(struct msdc_host *host, host->cmd = cmd; host->cmd_rsp = resp; - init_completion(>cmd_done); + // The completion should have been consumed by the previous command + // response handler, because the mmc requests should be serialized + BUG_ON(completion_done(>cmd_done)); sdr_set_bits(host->base + MSDC_INTEN, wints); sdc_send_cmd(rawcmd, cmd->arg); @@ -490,7 +492,6 @@ static unsigned int msdc_command_resp(struct msdc_host *host, MSDC_INT_ACMD19_DONE; BUG_ON(in_interrupt()); - //init_completion(>cmd_done); //sdr_set_bits(host->base + MSDC_INTEN, wints); spin_unlock(>lock); @@ -674,7 +675,10 @@ static int msdc_do_request(struct mmc_host *mmc, struct mmc_request *mrq) //msdc_clr_fifo(host); /* no need */ msdc_dma_on(); /* enable DMA mode first!! */ - init_completion(>xfer_done); + + // The completion should have been consumed by the previous xfer + // response handler, because the mmc requests should be serialized + BUG_ON(completion_done(>xfer_done)); /* start the command first*/ if (msdc_command_start(host, cmd, CMD_TIMEOUT) != 0) @@ -693,7 +697,6 @@ static int msdc_do_request(struct mmc_host *mmc, struct mmc_request *mrq) /* for read, the data coming too fast, then CRC error * start DMA no business with CRC. */ - //init_completion(>xfer_done); msdc_dma_start(host); spin_unlock(>lock); @@ -1708,6 +1711,8 @@ static int msdc_drv_probe(struct platform_device *pdev) } msdc_init_gpd_bd(host, >dma); + init_completion(>cmd_done); + init_completion(>xfer_done); INIT_DELAYED_WORK(>card_delaywork, msdc_tasklet_card); spin_lock_init(>lock); msdc_init_hw(host); -- 2.20.1
[PATCH 09/10] staging: mt7621-mmc: Remove redundant host->mmc->f_max write
This is set once during initialization and never changed. Don't bother
setting it again in the interrupt handler.
Signed-off-by: George Hilliard
---
drivers/staging/mt7621-mmc/sd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 736e1d23b391..472318a979cb 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -210,7 +210,6 @@ static void msdc_tasklet_card(struct work_struct *work)
host->card_inserted = inserted;
if (!host->suspend) {
- host->mmc->f_max = HOST_MAX_MCLK;
mmc_detect_change(host->mmc, msecs_to_jiffies(20));
}
--
2.20.1
[PATCH 05/10] staging: mt7621-mmc: Use pinctrl subsystem to select SDXC pin mode
The driver previously grabbed the SD pins for itself, ignoring the pin
controller. Replace this direct register access with appropriate calls
to the pinctrl subsystem.
This also allows this driver to work on related devices that have a
different pin controller mapping, such as the MT7688. The hardcoded
bit index was incorrect on that device.
This change could break SD controller functionality on existing devices
whose device trees do not specify a pin controller and state for the SD
node.
Signed-off-by: George Hilliard
---
drivers/staging/mt7621-mmc/sd.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index a7c7ec0d7bbb..97ed7510e96d 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1599,6 +1600,8 @@ static int msdc_drv_probe(struct platform_device *pdev)
struct msdc_host *host;
struct msdc_hw *hw;
int ret;
+ struct pinctrl *pctrl;
+ struct pinctrl_state *pins_default;
hw = _hw;
@@ -1671,6 +1674,25 @@ static int msdc_drv_probe(struct platform_device *pdev)
host->mrq = NULL;
+ /* Read pin control settings from device tree */
+ pctrl = devm_pinctrl_get(>dev);
+ if (IS_ERR(pctrl)) {
+ ret = PTR_ERR(pctrl);
+ dev_err(>dev, "Cannot find pinctrl in device tree\n");
+ goto host_free;
+ }
+
+ pins_default = pinctrl_lookup_state(pctrl, PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(pins_default)) {
+ ret = PTR_ERR(pins_default);
+ dev_err(>dev, "Cannot find pinctrl state default\n");
+ goto host_free;
+ }
+
+ ret = pinctrl_select_state(pctrl, pins_default);
+ if (ret < 0)
+ dev_warn(>dev, "Cannot select pinctrl state\n");
+
dma_coerce_mask_and_coherent(mmc_dev(mmc), DMA_BIT_MASK(32));
/* using dma_alloc_coherent*/ /* todo: using 1, for all 4 slots */
@@ -1822,12 +1844,6 @@ static struct platform_driver mt_msdc_driver = {
static int __init mt_msdc_init(void)
{
int ret;
- u32 reg;
-
- // Set the pins for sdxc to sdxc mode
- //FIXME: this should be done by pinctl and not by the sd driver
- reg = readl((void __iomem *)(RALINK_SYSCTL_BASE + 0x60)) & ~(0x3 << 18);
- writel(reg, (void __iomem *)(RALINK_SYSCTL_BASE + 0x60));
ret = platform_driver_register(_msdc_driver);
if (ret) {
--
2.20.1
[PATCH 04/10] staging: mt7621-mmc: Fix warning when reloading module with debug msgs enabled
The kernel complained:
[ 510.277151] WARNING: CPU: 0 PID: 395 at fs/proc/generic.c:360
proc_register+0xf0/0x108
[ 510.292891] proc_dir_entry '/proc/msdc_debug' already registered
when doing a modprobe/rmmod/modprobe of this module if debug messages
are compiled in. Fix this by removing the proc entry when the module is
unloaded.
Signed-off-by: George Hilliard
---
drivers/staging/mt7621-mmc/dbg.c | 15 ---
drivers/staging/mt7621-mmc/dbg.h | 3 ++-
drivers/staging/mt7621-mmc/sd.c | 4
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/mt7621-mmc/dbg.c b/drivers/staging/mt7621-mmc/dbg.c
index 69b38c7e3179..5764b80893e9 100644
--- a/drivers/staging/mt7621-mmc/dbg.c
+++ b/drivers/staging/mt7621-mmc/dbg.c
@@ -295,9 +295,18 @@ static const struct file_operations msdc_debug_fops = {
.release= single_release,
};
-void msdc_debug_proc_init(void)
+// Keep ahold of the proc entry we create so it can be freed during
+// module removal
+struct proc_dir_entry *msdc_debug_proc_entry;
+
+void __init msdc_debug_proc_init(void)
{
- proc_create("msdc_debug", 0660, NULL, _debug_fops);
+ msdc_debug_proc_entry = proc_create("msdc_debug", 0660,
+ NULL, _debug_fops);
+}
+
+void __exit msdc_debug_proc_deinit(void)
+{
+ proc_remove(msdc_debug_proc_entry);
}
-EXPORT_SYMBOL_GPL(msdc_debug_proc_init);
#endif
diff --git a/drivers/staging/mt7621-mmc/dbg.h b/drivers/staging/mt7621-mmc/dbg.h
index 2d447b2d92ae..d100324aa3fe 100644
--- a/drivers/staging/mt7621-mmc/dbg.h
+++ b/drivers/staging/mt7621-mmc/dbg.h
@@ -93,7 +93,8 @@ enum msdc_dbg {
extern unsigned int sd_debug_zone[4];
#define TAG "msdc"
-void msdc_debug_proc_init(void);
+void __init msdc_debug_proc_init(void);
+void __exit msdc_debug_proc_deinit(void);
u32 msdc_time_calc(u32 old_L32, u32 old_H32, u32 new_L32, u32 new_H32);
void msdc_performance(u32 opcode, u32 sizes, u32 bRx, u32 ticks);
diff --git a/drivers/staging/mt7621-mmc/sd.c b/drivers/staging/mt7621-mmc/sd.c
index 1d357b898952..a7c7ec0d7bbb 100644
--- a/drivers/staging/mt7621-mmc/sd.c
+++ b/drivers/staging/mt7621-mmc/sd.c
@@ -1843,6 +1843,10 @@ static int __init mt_msdc_init(void)
static void __exit mt_msdc_exit(void)
{
+#if defined(MT6575_SD_DEBUG)
+ msdc_debug_proc_deinit();
+#endif
+
platform_driver_unregister(_msdc_driver);
}
--
2.20.1
[PATCH 01/10] staging: mt7621-mmc: fix unused variable compiler warning
The compiler complains: drivers/staging/mt7621-mmc/dbg.c: In function ‘msdc_debug_proc_write’: drivers/staging/mt7621-mmc/dbg.c:237:12: warning: unused variable ‘size’ [-Wunused-variable] int mode, size; ^~~~ drivers/staging/mt7621-mmc/dbg.c:237:6: warning: unused variable ‘mode’ [-Wunused-variable] int mode, size; ^~~~ Remove these declarations. Signed-off-by: George Hilliard --- drivers/staging/mt7621-mmc/dbg.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/mt7621-mmc/dbg.c b/drivers/staging/mt7621-mmc/dbg.c index c7c091fa1da0..69b38c7e3179 100644 --- a/drivers/staging/mt7621-mmc/dbg.c +++ b/drivers/staging/mt7621-mmc/dbg.c @@ -233,7 +233,6 @@ static ssize_t msdc_debug_proc_write(struct file *file, int cmd, p1, p2; int id, zone; - int mode, size; if (count == 0) return -1; -- 2.20.1
Re: [PATCH v2 04/15] ARM: milbeaut: Add basic support for Milbeaut m10v SoC
Hi,
On 2019/02/19 18:21, Arnd Bergmann wrote:
On Tue, Feb 19, 2019 at 8:12 AM Sugaya, Taichi
wrote:
On 2019/02/18 21:15, Arnd Bergmann wrote:
On Fri, Feb 8, 2019 at 1:26 PM Sugaya Taichi
wrote:
+static int __init m10v_pm_init(void)
+{
+ suspend_set_ops(_pm_ops);
+
+ return 0;
+}
+late_initcall(m10v_pm_init);
This requires a check to ensure you are actually on the right platform,
otherwise you break suspend/resume in a multiplatform kernel running
on anything other than milbeaut.
OK.
I think the solution is adding a "if statement with mlbeaut compatible"
above suspend_set_ops(_pm_ops).
Right, you can either use a call to of_machine_is_compatible(),
or you add a machine descriptor with OF_MACHINE_START()
and use this as the init_late() callback.
Yeah, I will use "of_machine_is_compatible()".
Thanks,
Sugaya Taichi
Arnd
RE: [PATCH v6 0/9] vfio/mdev: IOMMU aware mediated device
> From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Friday, February 15, 2019 4:15 AM > To: Lu Baolu > Subject: Re: [PATCH v6 0/9] vfio/mdev: IOMMU aware mediated device > > On Wed, 13 Feb 2019 12:02:52 +0800 > Lu Baolu wrote: > > > Hi, > > > > The Mediate Device is a framework for fine-grained physical device > > sharing across the isolated domains. Currently the mdev framework is > > designed to be independent of the platform IOMMU support. As the > > result, the DMA isolation relies on the mdev parent device in a vendor > > specific way. > > > > There are several cases where a mediated device could be protected and > > isolated by the platform IOMMU. For example, Intel vt-d rev3.0 [1] > > introduces a new translation mode called 'scalable mode', which > > enables PASID-granular translations. The vt-d scalable mode is the key > > ingredient for Scalable I/O Virtualization [2] [3] which allows > > sharing a device in minimal possible granularity (ADI - Assignable > > Device Interface). > > > > A mediated device backed by an ADI could be protected and isolated by > > the IOMMU since 1) the parent device supports tagging an unique PASID > > to all DMA traffic out of the mediated device; and 2) the DMA > > translation unit (IOMMU) supports the PASID granular translation. > > We can apply IOMMU protection and isolation to this kind of devices > > just as what we are doing with an assignable PCI device. > > > > In order to distinguish the IOMMU-capable mediated devices from those > > which still need to rely on parent devices, this patch set adds one > > new member in struct mdev_device. > > > > * iommu_device > > - This, if set, indicates that the mediated device could > > be fully isolated and protected by IOMMU via attaching > > an iommu domain to this device. If empty, it indicates > > using vendor defined isolation. > > > > Below helpers are added to set and get above iommu device in mdev core > > implementation. > > > > * mdev_set/get_iommu_device(dev, iommu_device) > > - Set or get the iommu device which represents this mdev > > in IOMMU's device scope. Drivers don't need to set the > > iommu device if it uses vendor defined isolation. > > > > The mdev parent device driver could opt-in that the mdev could be > > fully isolated and protected by the IOMMU when the mdev is being > > created by invoking mdev_set_iommu_device() in its @create(). > > > > In the vfio_iommu_type1_attach_group(), a domain allocated through > > iommu_domain_alloc() will be attached to the mdev iommu device if an > > iommu device has been set. Otherwise, the dummy external domain will > > be used and all the DMA isolation and protection are routed to parent > > driver as the result. > > > > On IOMMU side, a basic requirement is allowing to attach multiple > > domains to a PCI device if the device advertises the capability and > > the IOMMU hardware supports finer granularity translations than the > > normal PCI Source ID based translation. > > > > As the result, a PCI device could work in two modes: normal mode and > > auxiliary mode. In the normal mode, a pci device could be isolated in > > the Source ID granularity; the pci device itself could be assigned to > > a user application by attaching a single domain to it. In the > > auxiliary mode, a pci device could be isolated in finer granularity, > > hence subsets of the device could be assigned to different user level > > application by attaching a different domain to each subset. > > > > Below APIs are introduced in iommu generic layer for aux-domain > > purpose: > > > > * iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX) > > - Check whether both IOMMU and device support IOMMU aux > > domain feature. Below aux-domain specific interfaces > > are available only after this returns true. > > > > * iommu_dev_enable/disable_feature(dev, IOMMU_DEV_FEAT_AUX) > > - Enable/disable device specific aux-domain feature. > > > > * iommu_dev_feature_enabled(dev, IOMMU_DEV_FEAT_AUX) > > - Check whether the aux domain specific feature enabled or > > not. > > > > * iommu_aux_attach_device(domain, dev) > > - Attaches @domain to @dev in the auxiliary mode. Multiple > > domains could be attached to a single device in the > > auxiliary mode with each domain representing an isolated > > address space for an assignable subset of the device. > > > > * iommu_aux_detach_device(domain, dev) > > - Detach @domain which has been attached to @dev in the > > auxiliary mode. > > > > * iommu_aux_get_pasid(domain, dev) > > - Return ID used for finer-granularity DMA translation. > > For the Intel Scalable IOV usage model, this will be > > a PASID. The device which supports Scalable IOV needs > > to write this ID to the device register so that DMA > > requests could be tagged with a right PASID prefix. > > > > In order for the ease of discussion, sometimes we call "a domain in > > auxiliary mode' or simply 'an auxiliary
Re: [PATCH 0/4] cpufreq: Assorted cleanups related to cpufreq_set_policy()
On 20-02-19, 00:21, Rafael J. Wysocki wrote: > Hi, > > There are a few things related to cpufreq_set_policy() and > cpufreq_update_policy() > that increase the level of confusion thereof quite unnecessarily, so this > series > attempts to clean them up. Please refer to the patch changelogs for details. > > Please let me know if you see any problems with these patches. Acked-by: Viresh Kumar -- viresh
[PATCH v2 5/5] base: soc: Export soc_device_register/unregister APIs
From: Vinod Koul
Qcom Socinfo driver can be built as a module, so
export these two APIs.
Signed-off-by: Vinod Koul
Signed-off-by: Vaishali Thakkar
---
Changes since v1:
- None
---
drivers/base/soc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/soc.c b/drivers/base/soc.c
index b0933b9fe67f..7c0c5ca5953d 100644
--- a/drivers/base/soc.c
+++ b/drivers/base/soc.c
@@ -164,6 +164,7 @@ struct soc_device *soc_device_register(struct
soc_device_attribute *soc_dev_attr
out1:
return ERR_PTR(ret);
}
+EXPORT_SYMBOL_GPL(soc_device_register);
/* Ensure soc_dev->attr is freed prior to calling soc_device_unregister. */
void soc_device_unregister(struct soc_device *soc_dev)
@@ -173,6 +174,7 @@ void soc_device_unregister(struct soc_device *soc_dev)
device_unregister(_dev->dev);
early_soc_dev_attr = NULL;
}
+EXPORT_SYMBOL_GPL(soc_device_unregister);
static int __init soc_bus_register(void)
{
--
2.17.1
[PATCH v2 2/5] soc: qcom: Add socinfo driver
From: Imran Khan
The Qualcomm socinfo driver exposes information about the SoC, its
version and its serial number to user space.
Signed-off-by: Imran Khan
[Bjorn: Extract code to platform_driver, split patch in multiple]
Signed-off-by: Bjorn Andersson
[Vaishali: Simplify declarations, introduce qcom_socinfo struc, Fix
memory leak, Remove extra code and Misc code refactoring]
Signed-off-by: Vaishali Thakkar
---
Changes since v1:
- None
---
drivers/soc/qcom/Kconfig | 8 ++
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/smem.c| 8 ++
drivers/soc/qcom/socinfo.c | 197 +
4 files changed, 214 insertions(+)
create mode 100644 drivers/soc/qcom/socinfo.c
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index fcbf8a2e4080..1e31eda07934 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -144,6 +144,14 @@ config QCOM_SMSM
Say yes here to support the Qualcomm Shared Memory State Machine.
The state machine is represented by bits in shared memory.
+config QCOM_SOCINFO
+ tristate "Qualcomm socinfo driver"
+ depends on QCOM_SMEM
+ select SOC_BUS
+ help
+Say yes here to support the Qualcomm socinfo driver, providing
+information about the SoC to user space.
+
config QCOM_WCNSS_CTRL
tristate "Qualcomm WCNSS control driver"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index f25b54cd6cf8..c817da4f4140 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -14,6 +14,7 @@ qcom_rpmh-y += rpmh-rsc.o
qcom_rpmh-y+= rpmh.o
obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
obj-$(CONFIG_QCOM_SMEM) += smem.o
+obj-$(CONFIG_QCOM_SOCINFO) += socinfo.o
obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
obj-$(CONFIG_QCOM_SMP2P) += smp2p.o
obj-$(CONFIG_QCOM_SMSM)+= smsm.o
diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
index f80d040601fd..efe0b053ef82 100644
--- a/drivers/soc/qcom/smem.c
+++ b/drivers/soc/qcom/smem.c
@@ -276,6 +276,7 @@ struct qcom_smem {
struct smem_partition_header *partitions[SMEM_HOST_COUNT];
size_t cacheline[SMEM_HOST_COUNT];
u32 item_count;
+ struct platform_device *socinfo;
unsigned num_regions;
struct smem_region regions[];
@@ -971,11 +972,18 @@ static int qcom_smem_probe(struct platform_device *pdev)
__smem = smem;
+ smem->socinfo = platform_device_register_data(>dev,
"qcom-socinfo",
+ PLATFORM_DEVID_NONE, NULL,
+ 0);
+ if (IS_ERR(smem->socinfo))
+ dev_err(>dev, "failed to register socinfo device\n");
+
return 0;
}
static int qcom_smem_remove(struct platform_device *pdev)
{
+
hwspin_lock_free(__smem->hwlock);
__smem = NULL;
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
new file mode 100644
index ..02078049fac7
--- /dev/null
+++ b/drivers/soc/qcom/socinfo.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2009-2017, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2017-2019, Linaro Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * SoC version type with major number in the upper 16 bits and minor
+ * number in the lower 16 bits.
+ */
+#define SOCINFO_MAJOR(ver) (((ver) >> 16) & 0x)
+#define SOCINFO_MINOR(ver) ((ver) & 0x)
+
+#define SMEM_SOCINFO_BUILD_ID_LENGTH 32
+
+/*
+ * SMEM item ids, used to acquire handles to respective
+ * SMEM region.
+ */
+#define SMEM_HW_SW_BUILD_ID137
+
+/* Socinfo SMEM item structure */
+struct socinfo {
+ __le32 fmt;
+ __le32 id;
+ __le32 ver;
+ char build_id[SMEM_SOCINFO_BUILD_ID_LENGTH];
+ /* Version 2 */
+ __le32 raw_id;
+ __le32 raw_ver;
+ /* Version 3 */
+ __le32 hw_plat;
+ /* Version 4 */
+ __le32 plat_ver;
+ /* Version 5 */
+ __le32 accessory_chip;
+ /* Version 6 */
+ __le32 hw_plat_subtype;
+ /* Version 7 */
+ __le32 pmic_model;
+ __le32 pmic_die_rev;
+ /* Version 8 */
+ __le32 pmic_model_1;
+ __le32 pmic_die_rev_1;
+ __le32 pmic_model_2;
+ __le32 pmic_die_rev_2;
+ /* Version 9 */
+ __le32 foundry_id;
+ /* Version 10 */
+ __le32 serial_num;
+ /* Version 11 */
+ __le32 num_pmics;
+ __le32 pmic_array_offset;
+ /* Version 12 */
+ __le32 chip_family;
+ __le32 raw_device_family;
+ __le32 raw_device_num;
+};
+
+struct qcom_socinfo {
+ struct soc_device *soc_dev;
+ struct soc_device_attribute attr;
+};
+
+struct soc_of_id {
+ unsigned int id;
[PATCH v2 3/5] soc: qcom: socinfo: Expose custom attributes
The Qualcomm socinfo provides a number of additional attributes,
add these to the socinfo driver and expose them via debugfs
functionality.
Signed-off-by: Vaishali Thakkar
---
Changes since v1:
- Remove unnecessary debugfs dir creation check
- Align ifdefs to left
- Fix function signatures for debugfs init/exit
---
drivers/soc/qcom/socinfo.c | 198 +
1 file changed, 198 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 02078049fac7..5f4bef216ae1 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -4,6 +4,7 @@
* Copyright (c) 2017-2019, Linaro Ltd.
*/
+#include
#include
#include
#include
@@ -29,6 +30,28 @@
*/
#define SMEM_HW_SW_BUILD_ID137
+#ifdef CONFIG_DEBUG_FS
+/* pmic model info */
+static const char *const pmic_model[] = {
+ [0] = "Unknown PMIC model",
+ [9] = "PM8994",
+ [11] = "PM8916",
+ [13] = "PM8058",
+ [14] = "PM8028",
+ [15] = "PM8901",
+ [16] = "PM8027",
+ [17] = "ISL9519",
+ [18] = "PM8921",
+ [19] = "PM8018",
+ [20] = "PM8015",
+ [21] = "PM8014",
+ [22] = "PM8821",
+ [23] = "PM8038",
+ [24] = "PM8922",
+ [25] = "PM8917",
+};
+#endif /* CONFIG_DEBUG_FS */
+
/* Socinfo SMEM item structure */
struct socinfo {
__le32 fmt;
@@ -70,6 +93,10 @@ struct socinfo {
struct qcom_socinfo {
struct soc_device *soc_dev;
struct soc_device_attribute attr;
+#ifdef CONFIG_DEBUG_FS
+ struct dentry *dbg_root;
+#endif /* CONFIG_DEBUG_FS */
+ struct socinfo *socinfo;
};
struct soc_of_id {
@@ -133,6 +160,171 @@ static const char *socinfo_machine(struct device *dev,
unsigned int id)
return NULL;
}
+#ifdef CONFIG_DEBUG_FS
+
+#define UINT_SHOW(name, attr) \
+static int qcom_show_##name(struct seq_file *seq, void *p) \
+{ \
+ struct socinfo *socinfo = seq->private; \
+ seq_printf(seq, "%u\n", le32_to_cpu(socinfo->attr));\
+ return 0; \
+} \
+static int qcom_open_##name(struct inode *inode, struct file *file)\
+{ \
+ return single_open(file, qcom_show_##name, inode->i_private); \
+} \
+ \
+static const struct file_operations qcom_ ##name## _ops = {\
+ .open = qcom_open_##name, \
+ .read = seq_read, \
+ .llseek = seq_lseek,\
+ .release = single_release, \
+}
+
+#define DEBUGFS_UINT_ADD(name) \
+ debugfs_create_file(__stringify(name), 0400,\
+ qcom_socinfo->dbg_root, \
+ qcom_socinfo->socinfo, _ ##name## _ops)
+
+#define HEX_SHOW(name, attr) \
+static int qcom_show_##name(struct seq_file *seq, void *p) \
+{ \
+ struct socinfo *socinfo = seq->private; \
+ seq_printf(seq, "0x%x\n", le32_to_cpu(socinfo->attr)); \
+ return 0; \
+} \
+static int qcom_open_##name(struct inode *inode, struct file *file)\
+{ \
+ return single_open(file, qcom_show_##name, inode->i_private); \
+} \
+ \
+static const struct file_operations qcom_ ##name## _ops = {\
+ .open = qcom_open_##name, \
+ .read = seq_read, \
+ .llseek = seq_lseek,\
+ .release = single_release, \
+}
+
+#define DEBUGFS_HEX_ADD(name) \
+ debugfs_create_file(__stringify(name), 0400,\
+ qcom_socinfo->dbg_root, \
+ qcom_socinfo->socinfo, _ ##name## _ops)
+
+
+#define QCOM_OPEN(name, _func)
[PATCH v2 4/5] soc: qcom: socinfo: Expose image information
The socinfo driver provides information about version of the various
images loaded in the system. Expose this to user space for debugging
purpose.
Signed-off-by: Vaishali Thakkar
---
Changes since v1:
- None
---
drivers/soc/qcom/socinfo.c | 210 +
1 file changed, 210 insertions(+)
diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index 5f4bef216ae1..f6a931ca8953 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -31,6 +31,25 @@
#define SMEM_HW_SW_BUILD_ID137
#ifdef CONFIG_DEBUG_FS
+#define SMEM_IMAGE_VERSION_BLOCKS_COUNT32
+#define SMEM_IMAGE_VERSION_SIZE4096
+#define SMEM_IMAGE_VERSION_NAME_SIZE 75
+#define SMEM_IMAGE_VERSION_VARIANT_SIZE20
+#define SMEM_IMAGE_VERSION_OEM_SIZE32
+
+/*
+ * SMEM Image table indices
+ */
+#define SMEM_IMAGE_TABLE_BOOT_INDEX 0
+#define SMEM_IMAGE_TABLE_TZ_INDEX 1
+#define SMEM_IMAGE_TABLE_RPM_INDEX 3
+#define SMEM_IMAGE_TABLE_APPS_INDEX 10
+#define SMEM_IMAGE_TABLE_MPSS_INDEX 11
+#define SMEM_IMAGE_TABLE_ADSP_INDEX 12
+#define SMEM_IMAGE_TABLE_CNSS_INDEX 13
+#define SMEM_IMAGE_TABLE_VIDEO_INDEX14
+#define SMEM_IMAGE_VERSION_TABLE 469
+
/* pmic model info */
static const char *const pmic_model[] = {
[0] = "Unknown PMIC model",
@@ -90,11 +109,21 @@ struct socinfo {
__le32 raw_device_num;
};
+#ifdef CONFIG_DEBUG_FS
+struct smem_image_version {
+ char name[SMEM_IMAGE_VERSION_NAME_SIZE];
+ char variant[SMEM_IMAGE_VERSION_VARIANT_SIZE];
+ char pad;
+ char oem[SMEM_IMAGE_VERSION_OEM_SIZE];
+};
+#endif /* CONFIG_DEBUG_FS */
+
struct qcom_socinfo {
struct soc_device *soc_dev;
struct soc_device_attribute attr;
#ifdef CONFIG_DEBUG_FS
struct dentry *dbg_root;
+ struct dentry *boot, *tz, *rpm, *apps, *mpss, *adsp, *cnss, *video;
#endif /* CONFIG_DEBUG_FS */
struct socinfo *socinfo;
};
@@ -298,8 +327,97 @@ QCOM_OPEN(pmic_model, qcom_show_pmic_model);
QCOM_OPEN(platform_subtype, qcom_show_platform_subtype);
QCOM_OPEN(pmic_die_revision, qcom_show_pmic_die_revision);
+#define IMAGE_SHOW_NAME(attr)\
+static int show_ ##attr## _name(struct seq_file *seq, void *p) \
+{\
+ struct smem_image_version *image_version = seq->private; \
+ seq_puts(seq, image_version->name); \
+ seq_puts(seq, "\n"); \
+ return 0; \
+}\
+static int open_ ##attr## _name(struct inode *inode, struct file *file)
\
+{\
+ return single_open(file, show_ ##attr## _name, inode->i_private); \
+}\
+ \
+static const struct file_operations qcom_ ##attr## _name_ops = { \
+ .open = open_ ##attr## _name, \
+ .read = seq_read, \
+ .llseek = seq_lseek, \
+ .release = single_release,\
+}\
+
+#define DEBUGFS_IMAGE_NAME(fname, attr, index) \
+debugfs_create_file(__stringify(fname), 0400, qcom_socinfo->attr,\
+ _image_version[index], _ ##attr## _name_ops)
+
+#define IMAGE_SHOW_VARIANT(attr)\
+static int show_ ##attr## _variant(struct seq_file *seq, void *p) \
+{ \
+ struct smem_image_version *image_version = seq->private; \
+ seq_puts(seq, image_version->variant); \
+ seq_puts(seq, "\n"); \
+ return 0;\
+} \
+static int open_ ##attr## _variant(struct inode *inode, struct file *file) \
+{\
+ return single_open(file, show_ ##attr## _variant, inode->i_private); \
+} \
+\
+static const struct file_operations qcom_ ##attr## _variant_ops = { \
+
[PATCH v2 0/5] soc: qcom: Add SoC info driver
This patchset adds SoC info driver which can provide information such as Chip ID, Chip family and serial number about Qualcomm SoCs to user space via sysfs. Furthermore, it allows userspace to get information about custom attributes and various image version information via debugfs. The patchset cleanly applies on top of v5.0-rc6. Changes since v1: - Align ifdefs to left, remove unnecessary debugfs dir creation check and fix function signatures in patch 3 - Fix comment for teh case when serial number is not available in patch 1 Vaishali Thakkar (5): base: soc: Add serial_number attribute to soc soc: qcom: Add socinfo driver soc: qcom: socinfo: Expose custom attributes soc: qcom: socinfo: Expose image information base: soc: Export soc_device_register/unregister APIs Documentation/ABI/testing/sysfs-devices-soc | 7 + drivers/base/soc.c | 9 + drivers/soc/qcom/Kconfig| 8 + drivers/soc/qcom/Makefile | 1 + drivers/soc/qcom/smem.c | 8 + drivers/soc/qcom/socinfo.c | 605 include/linux/sys_soc.h | 1 + 7 files changed, 639 insertions(+) create mode 100644 drivers/soc/qcom/socinfo.c -- 2.17.1
