* [PATCH v5 1/4] ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
This commit adds include file guards to ts72xx.h
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- None
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.h b/arch/arm/mach-ep93xx/ts72xx.h
index 8a3206a54b39..7b7490f10fa9 100644
--- a/arch/arm/mach-ep93xx/ts72xx.h
+++ b/arch/arm/mach-ep93xx/ts72xx.h
@@ -12,6 +12,9 @@
* febfd000 22800000 4K options register #2
*/
+#ifndef __TS72XX_H_
+#define __TS72XX_H_
+
#define TS72XX_MODEL_PHYS_BASE 0x22000000
#define TS72XX_MODEL_VIRT_BASE IOMEM(0xfebff000)
#define TS72XX_MODEL_SIZE 0x00001000
@@ -83,3 +86,4 @@ static inline int is_ts9420_installed(void)
TS72XX_OPTIONS2_TS9420);
}
#endif
+#endif /* __TS72XX_H_ */
--
2.11.0
^ permalink raw reply related
* [PATCH v5 2/4] ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept parameters
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
This commit extend the ts72xx_register_flash() to accept passed parameters,
which makes it more reusable.
Now it is possible to accept ep93xx flash start address and partitions.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Acked-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes for v4:
- None
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 20 ++++++++------------
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index f386ebae0163..141ae4c65a81 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -123,8 +123,6 @@ static struct platform_nand_data ts72xx_nand_data = {
.nr_chips = 1,
.chip_offset = 0,
.chip_delay = 15,
- .partitions = ts72xx_nand_parts,
- .nr_partitions = ARRAY_SIZE(ts72xx_nand_parts),
},
.ctrl = {
.cmd_ctrl = ts72xx_nand_hwcontrol,
@@ -148,8 +146,8 @@ static struct platform_device ts72xx_nand_flash = {
.num_resources = ARRAY_SIZE(ts72xx_nand_resource),
};
-
-static void __init ts72xx_register_flash(void)
+void __init ts72xx_register_flash(struct mtd_partition *parts, int n,
+ resource_size_t start)
{
/*
* TS7200 has NOR flash all other TS72xx board have NAND flash.
@@ -157,16 +155,12 @@ static void __init ts72xx_register_flash(void)
if (board_is_ts7200()) {
ep93xx_register_flash(2, EP93XX_CS6_PHYS_BASE, SZ_16M);
} else {
- resource_size_t start;
-
- if (is_ts9420_installed())
- start = EP93XX_CS7_PHYS_BASE;
- else
- start = EP93XX_CS6_PHYS_BASE;
-
ts72xx_nand_resource[0].start = start;
ts72xx_nand_resource[0].end = start + SZ_16M - 1;
+ ts72xx_nand_data.chip.partitions = parts;
+ ts72xx_nand_data.chip.nr_partitions = n;
+
platform_device_register(&ts72xx_nand_flash);
}
}
@@ -257,7 +251,9 @@ static struct ep93xx_spi_info ts72xx_spi_info __initdata = {
static void __init ts72xx_init_machine(void)
{
ep93xx_init_devices();
- ts72xx_register_flash();
+ ts72xx_register_flash(ts72xx_nand_parts, ARRAY_SIZE(ts72xx_nand_parts),
+ is_ts9420_installed() ?
+ EP93XX_CS7_PHYS_BASE : EP93XX_CS6_PHYS_BASE);
platform_device_register(&ts72xx_rtc_device);
platform_device_register(&ts72xx_wdt_device);
--
2.11.0
^ permalink raw reply related
* [PATCH v5 3/4] ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
This patch extends readability of ts72xx.c code.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- New patch
Changes for v3:
- None
Changes to v4:
- Adjust the code to be applicable to linux-next/master
Changes for v5:
- None
---
arch/arm/mach-ep93xx/ts72xx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 141ae4c65a81..17af9d834b51 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -31,6 +31,9 @@
#include "soc.h"
#include "ts72xx.h"
+/*************************************************************************
+ * IO map
+ *************************************************************************/
static struct map_desc ts72xx_io_desc[] __initdata = {
{
.virtual = (unsigned long)TS72XX_MODEL_VIRT_BASE,
@@ -201,10 +204,16 @@ static struct platform_device ts72xx_wdt_device = {
.num_resources = ARRAY_SIZE(ts72xx_wdt_resources),
};
+/*************************************************************************
+ * ETH
+ *************************************************************************/
static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
.phy_id = 1,
};
+/*************************************************************************
+ * TS72XX support code
+ *************************************************************************/
#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
/* Relative to EP93XX_CS1_PHYS_BASE */
--
2.11.0
^ permalink raw reply related
* [PATCH v5 4/4] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
From: Lukasz Majewski @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
The BK3 board is a derivative of the ts72xx reference design.
Signed-off-by: Lukasz Majewski <lukma@denx.de>
---
Changes for v2:
- Place bk3 support code to the ts72xx.c file
Changes for v3:
- Add SD card support (via SPI) for BK3
- Remove definition of apb:i2s bus
- Remove board registration of CPLD WDT device
- Add I2S platform device to BK3
- Add MAINTAINERS entry for BK3 maintainer
Changes for v4:
- Adjust the code to be applicable on top of linux-next/master
Changes for v5:
- Combine map_io to be reused across all ts72xx boards
---
MAINTAINERS | 6 ++
arch/arm/mach-ep93xx/Kconfig | 7 +++
arch/arm/mach-ep93xx/ts72xx.c | 136 ++++++++++++++++++++++++++++++++++++++++++
arch/arm/mach-ep93xx/ts72xx.h | 5 ++
arch/arm/tools/mach-types | 1 +
5 files changed, 155 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d195739f892..17e1263b085d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1258,6 +1258,12 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Supported
F: drivers/net/ethernet/cavium/thunder/
+ARM/CIRRUS LOGIC BK3 MACHINE SUPPORT
+M: Lukasz Majewski <lukma@denx.de>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Maintained
+F: arch/arm/mach-ep93xx/ts72xx.c
+
ARM/CIRRUS LOGIC CLPS711X ARM ARCHITECTURE
M: Alexander Shiyan <shc_work@mail.ru>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
diff --git a/arch/arm/mach-ep93xx/Kconfig b/arch/arm/mach-ep93xx/Kconfig
index 61a75ca3684e..c095236d7ff8 100644
--- a/arch/arm/mach-ep93xx/Kconfig
+++ b/arch/arm/mach-ep93xx/Kconfig
@@ -21,6 +21,13 @@ config MACH_ADSSPHERE
Say 'Y' here if you want your kernel to support the ADS
Sphere board.
+config MACH_BK3
+ bool "Support Liebherr BK3.1"
+ select MACH_TS72XX
+ help
+ Say 'Y' here if you want your kernel to support the
+ Liebherr controller BK3.1.
+
config MACH_EDB93XX
bool
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 17af9d834b51..c089a2a4fe30 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -19,10 +19,15 @@
#include <linux/mtd/rawnand.h>
#include <linux/mtd/partitions.h>
#include <linux/spi/spi.h>
+#include <linux/spi/flash.h>
+#include <linux/spi/mmc_spi.h>
+#include <linux/mmc/host.h>
#include <linux/platform_data/spi-ep93xx.h>
#include <mach/gpio-ep93xx.h>
#include <mach/hardware.h>
+#include <mach/irqs.h>
+#include <mach/gpio-ep93xx.h>
#include <asm/mach-types.h>
#include <asm/mach/map.h>
@@ -50,6 +55,11 @@ static struct map_desc ts72xx_io_desc[] __initdata = {
.pfn = __phys_to_pfn(TS72XX_OPTIONS2_PHYS_BASE),
.length = TS72XX_OPTIONS2_SIZE,
.type = MT_DEVICE,
+ }, {
+ .virtual = (unsigned long)TS72XX_CPLDVER_VIRT_BASE,
+ .pfn = __phys_to_pfn(TS72XX_CPLDVER_PHYS_BASE),
+ .length = TS72XX_CPLDVER_SIZE,
+ .type = MT_DEVICE,
}
};
@@ -212,6 +222,69 @@ static struct ep93xx_eth_data __initdata ts72xx_eth_data = {
};
/*************************************************************************
+ * SPI SD/MMC host
+ *************************************************************************/
+#define BK3_EN_SDCARD_PHYS_BASE 0x12400000
+#define BK3_EN_SDCARD_PWR 0x0
+#define BK3_DIS_SDCARD_PWR 0x0C
+static void bk3_mmc_spi_setpower(struct device *dev, unsigned int vdd)
+{
+ void __iomem *pwr_sd = ioremap(BK3_EN_SDCARD_PHYS_BASE, SZ_4K);
+
+ if (!pwr_sd) {
+ pr_err("Failed to enable SD card power!");
+ return;
+ }
+
+ pr_debug("%s: SD card pwr %s VDD:0x%x\n", __func__,
+ !!vdd ? "ON" : "OFF", vdd);
+
+ if (!!vdd)
+ __raw_writeb(BK3_EN_SDCARD_PWR, pwr_sd);
+ else
+ __raw_writeb(BK3_DIS_SDCARD_PWR, pwr_sd);
+
+ iounmap(pwr_sd);
+}
+
+static struct mmc_spi_platform_data bk3_spi_mmc_data = {
+ .detect_delay = 500,
+ .powerup_msecs = 100,
+ .ocr_mask = MMC_VDD_32_33 | MMC_VDD_33_34,
+ .caps = MMC_CAP_NONREMOVABLE,
+ .setpower = bk3_mmc_spi_setpower,
+};
+
+/*************************************************************************
+ * SPI Bus - SD card access
+ *************************************************************************/
+static struct spi_board_info bk3_spi_board_info[] __initdata = {
+ {
+ .modalias = "mmc_spi",
+ .platform_data = &bk3_spi_mmc_data,
+ .max_speed_hz = 7.4E6,
+ .bus_num = 0,
+ .chip_select = 0,
+ .mode = SPI_MODE_0,
+ },
+};
+
+/*
+ * This is a stub -> the FGPIO[3] pin is not connected on the schematic
+ * The all work is performed automatically by !SPI_FRAME (SFRM1) and
+ * goes through CPLD
+ */
+static int bk3_spi_chipselects[] __initdata = {
+ EP93XX_GPIO_LINE_F(3),
+};
+
+static struct ep93xx_spi_info bk3_spi_master __initdata = {
+ .chipselect = bk3_spi_chipselects,
+ .num_chipselect = ARRAY_SIZE(bk3_spi_chipselects),
+ .use_dma = 1,
+};
+
+/*************************************************************************
* TS72XX support code
*************************************************************************/
#if IS_ENABLED(CONFIG_FPGA_MGR_TS73XX)
@@ -285,3 +358,66 @@ MACHINE_START(TS72XX, "Technologic Systems TS-72xx SBC")
.init_late = ep93xx_init_late,
.restart = ep93xx_restart,
MACHINE_END
+
+/*************************************************************************
+ * EP93xx I2S audio peripheral handling
+ *************************************************************************/
+static struct resource ep93xx_i2s_resource[] = {
+ DEFINE_RES_MEM(EP93XX_I2S_PHYS_BASE, 0x100),
+ DEFINE_RES_IRQ_NAMED(IRQ_EP93XX_SAI, "spilink i2s slave"),
+};
+
+static struct platform_device ep93xx_i2s_device = {
+ .name = "ep93xx-spilink-i2s",
+ .id = -1,
+ .num_resources = ARRAY_SIZE(ep93xx_i2s_resource),
+ .resource = ep93xx_i2s_resource,
+};
+
+/*************************************************************************
+ * BK3 support code
+ *************************************************************************/
+static struct mtd_partition bk3_nand_parts[] = {
+ {
+ .name = "System",
+ .offset = 0x00000000,
+ .size = 0x01e00000,
+ }, {
+ .name = "Data",
+ .offset = 0x01e00000,
+ .size = 0x05f20000
+ }, {
+ .name = "RedBoot",
+ .offset = 0x07d20000,
+ .size = 0x002e0000,
+ .mask_flags = MTD_WRITEABLE, /* force RO */
+ },
+};
+
+static void __init bk3_init_machine(void)
+{
+ ep93xx_init_devices();
+
+ ts72xx_register_flash(bk3_nand_parts, ARRAY_SIZE(bk3_nand_parts),
+ EP93XX_CS6_PHYS_BASE);
+
+ ep93xx_register_eth(&ts72xx_eth_data, 1);
+
+ ep93xx_register_spi(&bk3_spi_master, bk3_spi_board_info,
+ ARRAY_SIZE(bk3_spi_board_info));
+
+ /* Configure ep93xx's I2S to use AC97 pins */
+ ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_I2SONAC97);
+ platform_device_register(&ep93xx_i2s_device);
+}
+
+MACHINE_START(BK3, "Liebherr controller BK3.1")
+ /* Maintainer: Lukasz Majewski <lukma@denx.de> */
+ .atag_offset = 0x100,
+ .map_io = ts72xx_map_io,
+ .init_irq = ep93xx_init_irq,
+ .init_time = ep93xx_timer_init,
+ .init_machine = bk3_init_machine,
+ .init_late = ep93xx_init_late,
+ .restart = ep93xx_restart,
+MACHINE_END
diff --git a/arch/arm/mach-ep93xx/ts72xx.h b/arch/arm/mach-ep93xx/ts72xx.h
index 7b7490f10fa9..00b4941d29c9 100644
--- a/arch/arm/mach-ep93xx/ts72xx.h
+++ b/arch/arm/mach-ep93xx/ts72xx.h
@@ -10,6 +10,7 @@
* febff000 22000000 4K model number register (bits 0-2)
* febfe000 22400000 4K options register
* febfd000 22800000 4K options register #2
+ * febfc000 23400000 4K CPLD version register
*/
#ifndef __TS72XX_H_
@@ -42,6 +43,10 @@
#define TS72XX_OPTIONS2_TS9420 0x04
#define TS72XX_OPTIONS2_TS9420_BOOT 0x02
+#define TS72XX_CPLDVER_PHYS_BASE 0x23400000
+#define TS72XX_CPLDVER_VIRT_BASE IOMEM(0xfebfc000)
+#define TS72XX_CPLDVER_SIZE 0x00001000
+
#ifndef __ASSEMBLY__
static inline int ts72xx_model(void)
diff --git a/arch/arm/tools/mach-types b/arch/arm/tools/mach-types
index a9313b66f770..4eac94c1eb6f 100644
--- a/arch/arm/tools/mach-types
+++ b/arch/arm/tools/mach-types
@@ -345,6 +345,7 @@ mxlads MACH_MXLADS MXLADS 1851
linkstation_mini MACH_LINKSTATION_MINI LINKSTATION_MINI 1858
afeb9260 MACH_AFEB9260 AFEB9260 1859
imx27ipcam MACH_IMX27IPCAM IMX27IPCAM 1871
+bk3 MACH_BK3 BK3 1880
rd88f6183ap_ge MACH_RD88F6183AP_GE RD88F6183AP_GE 1894
realview_pba8 MACH_REALVIEW_PBA8 REALVIEW_PBA8 1897
realview_pbx MACH_REALVIEW_PBX REALVIEW_PBX 1901
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v5 2/2] net: thunderx: add timestamping support
From: Richard Cochran @ 2017-12-11 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211141435.2915-3-aleksey.makarov@cavium.com>
On Mon, Dec 11, 2017 at 05:14:31PM +0300, Aleksey Makarov wrote:
> @@ -880,6 +889,46 @@ static void nic_pause_frame(struct nicpf *nic, int vf, struct pfc *cfg)
> }
> }
>
> +/* Enable or disable HW timestamping by BGX for pkts received on a LMAC */
> +static void nic_config_timestamp(struct nicpf *nic, int vf, struct set_ptp *ptp)
> +{
> + struct pkind_cfg *pkind;
> + u8 lmac, bgx_idx;
> + u64 pkind_val, pkind_idx;
> +
> + if (vf >= nic->num_vf_en)
> + return;
> +
> + bgx_idx = NIC_GET_BGX_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
> + lmac = NIC_GET_LMAC_FROM_VF_LMAC_MAP(nic->vf_lmac_map[vf]);
> +
> + pkind_idx = lmac + bgx_idx * MAX_LMAC_PER_BGX;
> + pkind_val = nic_reg_read(nic, NIC_PF_PKIND_0_15_CFG | (pkind_idx << 3));
> + pkind = (struct pkind_cfg *)&pkind_val;
> +
> + if (ptp->enable && !pkind->hdr_sl) {
> + /* Skiplen to exclude 8byte timestamp while parsing pkt
> + * If not configured, will result in L2 errors.
> + */
> + pkind->hdr_sl = 4;
> + /* Adjust max packet length allowed */
> + pkind->maxlen += (pkind->hdr_sl * 2);
> + bgx_config_timestamping(nic->node, bgx_idx, lmac, true);
> + nic_reg_write(nic,
> + NIC_PF_RX_ETYPE_0_7 | (1 << 3),
> + (ETYPE_ALG_ENDPARSE << 16) | ETH_P_1588);
don't need three lines for this function call.
> + } else if (!ptp->enable && pkind->hdr_sl) {
> + pkind->maxlen -= (pkind->hdr_sl * 2);
> + pkind->hdr_sl = 0;
> + bgx_config_timestamping(nic->node, bgx_idx, lmac, false);
> + nic_reg_write(nic,
> + NIC_PF_RX_ETYPE_0_7 | (1 << 3),
> + (1ULL << 16) | ETH_P_8021Q); /* reset value */
here neither. Also avoid comment on the LHS. If 1<<16 means "reset"
then just define a macro.
> + }
> +
> + nic_reg_write(nic, NIC_PF_PKIND_0_15_CFG | (pkind_idx << 3), pkind_val);
> +}
> +
Thanks,
Richard
^ permalink raw reply
* [PATCH v5 0/4] ARM: ep93xx: ts72xx: Add support for BK3 board
From: Hartley Sweeten @ 2017-12-11 23:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211233625.5689-1-lukma@denx.de>
On Monday, December 11, 2017 4:36 PM, Lukasz Majewski wrote:
> This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design.
>
> This patchset consists of following patches:
>
> - ts72xx.[c|h] cosmetic cleanup/improvement
> - Rewrite ts72xx.c to be reusable by bk3
> - The Liebherr's BK3 board has been added with re-using code of
> ts72xx.c (detalied list of changes can be found in patch 4/4)
>
> This series applies on top of linux-next/master (next-20171211)
>
> Lukasz Majewski (4):
> ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file
> ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept
> parameters
> ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code
> ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative
>
> MAINTAINERS | 6 ++
> arch/arm/mach-ep93xx/Kconfig | 7 ++
> arch/arm/mach-ep93xx/ts72xx.c | 165 +++++++++++++++++++++++++++++++++++++++---
> arch/arm/mach-ep93xx/ts72xx.h | 9 +++
> arch/arm/tools/mach-types | 1 +
> 5 files changed, 176 insertions(+), 12 deletions(-)
Looks good. Thanks!
Acked-by: H Hartley Sweeten <hsweeten@visionengravers.com>
^ permalink raw reply
* [GIT PULL] Amlogic 32-bit DT changes for v4.16
From: Kevin Hilman @ 2017-12-12 0:27 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt
for you to fetch changes up to 71a3dfd07ce1a69060bf040f28799171aa6a4ed3:
ARM: meson: enable MESON_IRQ_GPIO also for MACH_MESON8 (2017-12-11 15:58:46 -0800)
----------------------------------------------------------------
Amlogic 32-bit DT changes for v4.16
- meson8: GPIO IRQ support
- switch to stable UART bindings w/correct clock
- add more L2 cache settings
- drop unused ADC clock
----------------------------------------------------------------
Martin Blumenstingl (6):
ARM: dts: meson8b: add more L2 cache settings
ARM: dts: meson8: add more L2 cache settings
ARM: dts: meson8: use stable UART bindings with correct gate clock
ARM: dts: meson8b: use stable UART bindings with correct gate clock
ARM: dts: meson8: enable the GPIO interrupt controller
ARM: meson: enable MESON_IRQ_GPIO also for MACH_MESON8
Xingyu Chen (1):
ARM: dts: meson: drop "sana" clock from SAR ADC
arch/arm/boot/dts/meson8.dtsi | 29 ++++++++++++++++++++++-------
arch/arm/boot/dts/meson8b.dtsi | 24 +++++++++++++++++-------
arch/arm/mach-meson/Kconfig | 1 +
3 files changed, 40 insertions(+), 14 deletions(-)
^ permalink raw reply
* [GIT PULL] Amlogic 64-bit DT updates for v4.16
From: Kevin Hilman @ 2017-12-12 0:28 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic.git tags/amlogic-dt64
for you to fetch changes up to 3106507e1004dd398ef75d0caf048f97ba2dfd0b:
ARM64: dts: meson-gxm: fix q200 interrupt number (2017-12-08 10:47:28 -0800)
----------------------------------------------------------------
Amlogic 64-bit DT updates for v4.16
- meson-gx: add VPU power domain support
- odroid-c2: add HDMI and CEC nodes
- misc cleanups
----------------------------------------------------------------
Jerome Brunet (1):
ARM64: dts: meson-gxm: fix q200 interrupt number
Kevin Hilman (1):
ARM64: dts: amlogic: use generic bus node names
Martin Blumenstingl (2):
ARM64: dts: meson: add comments with the GPIO for the PHY interrupts
ARM64: dts: meson-gxm: add the PHY interrupt line on Khadas VIM2
Neil Armstrong (4):
ARM64: dts: meson-gx: add VPU power domain
ARM64: dts: meson-gx: Add HDMI_5V regulator on selected boards
ARM64: dts: meson-gx: grow reset controller memory zone
ARM64: dts: odroid-c2: Add HDMI and CEC Nodes
Xingyu Chen (1):
ARM64: dts: meson: drop "sana" clock from SAR ADC
arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 4 ++--
arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 19 +++++++++++++++----
arch/arm64/boot/dts/amlogic/meson-gxbb-nanopi-k2.dts | 1 +
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 32 ++++++++++++++++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 1 +
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 46 ++++++++++++++++++++++++++++++++++++++++++++--
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-p212.dtsi | 12 ++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 46 ++++++++++++++++++++++++++++++++++++++++++++--
arch/arm64/boot/dts/amlogic/meson-gxm-khadas-vim2.dts | 15 +++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxm-q200.dts | 3 ++-
12 files changed, 192 insertions(+), 11 deletions(-)
^ permalink raw reply
* [PATCH] arm: dts: uniphier: add efuse node for UniPhier 32bit SoC
From: Keiji Hayashibara @ 2017-12-12 0:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNARmYfnYpACrUtYccBPyjnvXg0ymA=WZ=+nGAtanaXZk1w@mail.gmail.com>
Hello Yamada-san,
Sorry, I will be careful next time.
I was checking with the command of
"get_maintainer.pl -f arch/arm/boot/dts/".
Thank you.
Best Regards,
Keiji Hayashibara
> From: Masahiro Yamada [mailto:yamada.masahiro at socionext.com]
> Sent: Tuesday, December 12, 2017 1:06 AM
>
> 2017-12-04 17:12 GMT+09:00 Keiji Hayashibara <hayashibara.keiji@socionext.com>:
> > Add efuse node for UniPhier LD4, Pro4, sLD8, Pro5 and PXs2.
> > This efuse node is included in soc-glue.
> >
> > Signed-off-by: Keiji Hayashibara <hayashibara.keiji@socionext.com>
> > ---
> > arch/arm/boot/dts/uniphier-ld4.dtsi | 18 ++++++++++++++++++
> > arch/arm/boot/dts/uniphier-pro4.dtsi | 23 +++++++++++++++++++++++
> > arch/arm/boot/dts/uniphier-pro5.dtsi | 33
> > +++++++++++++++++++++++++++++++++
> > arch/arm/boot/dts/uniphier-pxs2.dtsi | 18 ++++++++++++++++++
> > arch/arm/boot/dts/uniphier-sld8.dtsi | 18 ++++++++++++++++++
> > 5 files changed, 110 insertions(+)
>
>
> Applied to linux-uniphier,
> but please reconsider To: list next time.
>
> This patch was addressed to Rob and Mark, but they do not pick up platform DT patches.
>
>
> You do not need to get Rob's Ack for a patch like this.
>
>
> Binding is a contract between operation system and DT.
>
> The binding for this
> (Documentation/devicetree/bindings/nvmem/uniphier-efuse.txt)
> was approved by Rob and merged in the mainline.
>
> Given that this patch follows the binding correctly, it should be safe.
>
> Thanks.
>
>
>
> > diff --git a/arch/arm/boot/dts/uniphier-ld4.dtsi
> > b/arch/arm/boot/dts/uniphier-ld4.dtsi
> > index 01fc3e1..6883f3b 100644
> > --- a/arch/arm/boot/dts/uniphier-ld4.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-ld4.dtsi
> > @@ -273,6 +273,24 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-ld4-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 130 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x130 0x8>;
> > + };
> > + };
> > +
> > timer at 60000200 {
> > compatible = "arm,cortex-a9-global-timer";
> > reg = <0x60000200 0x20>; diff --git
> > a/arch/arm/boot/dts/uniphier-pro4.dtsi
> > b/arch/arm/boot/dts/uniphier-pro4.dtsi
> > index 7955c3a..150726b 100644
> > --- a/arch/arm/boot/dts/uniphier-pro4.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-pro4.dtsi
> > @@ -294,6 +294,29 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-pro4-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 130 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x130 0x8>;
> > + };
> > +
> > + efuse at 200 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x200 0x14>;
> > + };
> > + };
> > +
> > aidet: aidet at 5fc20000 {
> > compatible = "socionext,uniphier-pro4-aidet";
> > reg = <0x5fc20000 0x200>; diff --git
> > a/arch/arm/boot/dts/uniphier-pro5.dtsi
> > b/arch/arm/boot/dts/uniphier-pro5.dtsi
> > index 6589b8a..f291dd6 100644
> > --- a/arch/arm/boot/dts/uniphier-pro5.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-pro5.dtsi
> > @@ -355,6 +355,39 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-pro5-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 130 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x130 0x8>;
> > + };
> > +
> > + efuse at 200 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x200 0x28>;
> > + };
> > +
> > + efuse at 300 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x300 0x14>;
> > + };
> > +
> > + efuse at 400 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x400 0x8>;
> > + };
> > + };
> > +
> > aidet: aidet at 5fc20000 {
> > compatible = "socionext,uniphier-pro5-aidet";
> > reg = <0x5fc20000 0x200>; diff --git
> > a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> > b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> > index d82d6d8..8e54e87 100644
> > --- a/arch/arm/boot/dts/uniphier-pxs2.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-pxs2.dtsi
> > @@ -375,6 +375,24 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-pxs2-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 200 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x200 0x58>;
> > + };
> > + };
> > +
> > aidet: aidet at 5fc20000 {
> > compatible = "socionext,uniphier-pxs2-aidet";
> > reg = <0x5fc20000 0x200>; diff --git
> > a/arch/arm/boot/dts/uniphier-sld8.dtsi
> > b/arch/arm/boot/dts/uniphier-sld8.dtsi
> > index 7188536..afafe7c 100644
> > --- a/arch/arm/boot/dts/uniphier-sld8.dtsi
> > +++ b/arch/arm/boot/dts/uniphier-sld8.dtsi
> > @@ -277,6 +277,24 @@
> > };
> > };
> >
> > + soc-glue at 5f900000 {
> > + compatible = "socionext,uniphier-sld8-soc-glue-debug",
> > + "simple-mfd";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges = <0 0x5f900000 0x2000>;
> > +
> > + efuse at 100 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x100 0x28>;
> > + };
> > +
> > + efuse at 200 {
> > + compatible = "socionext,uniphier-efuse";
> > + reg = <0x200 0x14>;
> > + };
> > + };
> > +
> > timer at 60000200 {
> > compatible = "arm,cortex-a9-global-timer";
> > reg = <0x60000200 0x20>;
> > --
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe devicetree"
> > in the body of a message to majordomo at vger.kernel.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Best Regards
> Masahiro Yamada
^ permalink raw reply
* [PATCH v5 2/9] ACPI/PPTT: Add Processor Properties Topology Table parsing
From: Rafael J. Wysocki @ 2017-12-12 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201222330.18863-3-jeremy.linton@arm.com>
On Friday, December 1, 2017 11:23:23 PM CET Jeremy Linton wrote:
> ACPI 6.2 adds a new table, which describes how processing units
> are related to each other in tree like fashion. Caches are
> also sprinkled throughout the tree and describe the properties
> of the caches in relation to other caches and processing units.
>
> Add the code to parse the cache hierarchy and report the total
> number of levels of cache for a given core using
> acpi_find_last_cache_level() as well as fill out the individual
> cores cache information with cache_setup_acpi() once the
> cpu_cacheinfo structure has been populated by the arch specific
> code.
>
> An additional patch later in the set adds the ability to report
> peers in the topology using find_acpi_cpu_topology()
> to report a unique ID for each processing unit at a given level
> in the tree. These unique id's can then be used to match related
> processing units which exist as threads, COD (clusters
> on die), within a given package, etc.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
This is only going to be used by ARM64 for the time being, so I need
someone from that camp to review this.
Sudeep, Hanjun, Lorenzo?
Thanks,
Rafael
^ permalink raw reply
* [PATCH v5 4/9] drivers: base cacheinfo: Add support for ACPI based firmware tables
From: Rafael J. Wysocki @ 2017-12-12 1:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201222330.18863-5-jeremy.linton@arm.com>
On Friday, December 1, 2017 11:23:25 PM CET Jeremy Linton wrote:
> Add a entry to to struct cacheinfo to maintain a reference to the PPTT
> node which can be used to match identical caches across cores. Also
> stub out cache_setup_acpi() so that individual architectures can
> enable ACPI topology parsing.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> ---
> drivers/acpi/pptt.c | 1 +
> drivers/base/cacheinfo.c | 20 ++++++++++++++------
> include/linux/cacheinfo.h | 13 ++++++++++++-
> 3 files changed, 27 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> index 0f8a1631af33..a35e457cefb7 100644
> --- a/drivers/acpi/pptt.c
> +++ b/drivers/acpi/pptt.c
> @@ -329,6 +329,7 @@ static void update_cache_properties(struct cacheinfo *this_leaf,
> {
> int valid_flags = 0;
>
> + this_leaf->firmware_node = cpu_node;
> if (found_cache->flags & ACPI_PPTT_SIZE_PROPERTY_VALID) {
> this_leaf->size = found_cache->size;
> valid_flags++;
> diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
> index eb3af2739537..ba89f9310e6f 100644
> --- a/drivers/base/cacheinfo.c
> +++ b/drivers/base/cacheinfo.c
> @@ -86,7 +86,10 @@ static int cache_setup_of_node(unsigned int cpu)
> static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
> struct cacheinfo *sib_leaf)
> {
> - return sib_leaf->of_node == this_leaf->of_node;
> + if (acpi_disabled)
> + return sib_leaf->of_node == this_leaf->of_node;
> + else
> + return sib_leaf->firmware_node == this_leaf->firmware_node;
> }
>
> /* OF properties to query for a given cache type */
> @@ -215,6 +218,11 @@ static inline bool cache_leaves_are_shared(struct cacheinfo *this_leaf,
> }
> #endif
>
> +int __weak cache_setup_acpi(unsigned int cpu)
> +{
> + return -ENOTSUPP;
> +}
> +
> static int cache_shared_cpu_map_setup(unsigned int cpu)
> {
> struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
> @@ -225,11 +233,11 @@ static int cache_shared_cpu_map_setup(unsigned int cpu)
> if (this_cpu_ci->cpu_map_populated)
> return 0;
>
> - if (of_have_populated_dt())
> + if (!acpi_disabled)
> + ret = cache_setup_acpi(cpu);
> + else if (of_have_populated_dt())
> ret = cache_setup_of_node(cpu);
> - else if (!acpi_disabled)
> - /* No cache property/hierarchy support yet in ACPI */
> - ret = -ENOTSUPP;
> +
> if (ret)
> return ret;
>
> @@ -286,7 +294,7 @@ static void cache_shared_cpu_map_remove(unsigned int cpu)
>
> static void cache_override_properties(unsigned int cpu)
> {
> - if (of_have_populated_dt())
> + if (acpi_disabled && of_have_populated_dt())
> return cache_of_override_properties(cpu);
> }
>
> diff --git a/include/linux/cacheinfo.h b/include/linux/cacheinfo.h
> index 3d9805297cda..7ebff157ae6c 100644
> --- a/include/linux/cacheinfo.h
> +++ b/include/linux/cacheinfo.h
> @@ -37,6 +37,8 @@ enum cache_type {
> * @of_node: if devicetree is used, this represents either the cpu node in
> * case there's no explicit cache node or the cache node itself in the
> * device tree
> + * @firmware_node: When not using DT, this may contain pointers to other
> + * firmware based values. Particularly ACPI/PPTT unique values.
> * @disable_sysfs: indicates whether this node is visible to the user via
> * sysfs or not
> * @priv: pointer to any private data structure specific to particular
> @@ -65,8 +67,8 @@ struct cacheinfo {
> #define CACHE_ALLOCATE_POLICY_MASK \
> (CACHE_READ_ALLOCATE | CACHE_WRITE_ALLOCATE)
> #define CACHE_ID BIT(4)
> -
> struct device_node *of_node;
> + void *firmware_node;
What about converting this to using struct fwnode instead of adding
fields to it?
> bool disable_sysfs;
> void *priv;
> };
> @@ -99,6 +101,15 @@ int func(unsigned int cpu) \
> struct cpu_cacheinfo *get_cpu_cacheinfo(unsigned int cpu);
> int init_cache_level(unsigned int cpu);
> int populate_cache_leaves(unsigned int cpu);
> +int cache_setup_acpi(unsigned int cpu);
> +int acpi_find_last_cache_level(unsigned int cpu);
> +#ifndef CONFIG_ACPI
> +int acpi_find_last_cache_level(unsigned int cpu)
> +{
> + /*ACPI kernels should be built with PPTT support*/
> + return 0;
> +}
> +#endif
>
> const struct attribute_group *cache_get_priv_group(struct cacheinfo *this_leaf);
>
>
Thanks,
Rafael
^ permalink raw reply
* [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code
From: Rafael J. Wysocki @ 2017-12-12 1:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171201222330.18863-7-jeremy.linton@arm.com>
On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
> The PPTT can be used to determine the groupings of CPU's at
> given levels in the system. Lets add a few routines to the PPTT
> parsing code to return a unique id for each unique level in the
> processor hierarchy. This can then be matched to build
> thread/core/cluster/die/package/etc mappings for each processing
> element in the system.
>
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Why can't this be folded into patch [2/9]?
Thanks,
Rafael
^ permalink raw reply
* [PATCH v1 4/4] arm64: dts: mediatek: add mt2712 cpufreq related device nodes
From: Rafael J. Wysocki @ 2017-12-12 1:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211075719.GD25177@vireshk-i7>
On Monday, December 11, 2017 8:57:19 AM CET Viresh Kumar wrote:
> On 08-12-17, 14:07, Andrew-sh Cheng wrote:
> > Add opp v2 information,
> > and also add clocks, regulators and opp information into cpu nodes
> >
> > Signed-off-by: Andrew-sh Cheng <andrew-sh.cheng@mediatek.com>
> > ---
> > arch/arm64/boot/dts/mediatek/mt2712-evb.dts | 27 ++++++++++++++
> > arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 57 +++++++++++++++++++++++++++++
> > 2 files changed, 84 insertions(+)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Of course, DT bindings require ACKs from DT maintainers to be applied.
^ permalink raw reply
* [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
From: gengdongjiu @ 2017-12-12 1:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211132914.GJ22781@e103592.cambridge.arm.com>
On 2017/12/11 21:29, Dave Martin wrote:
>> Thanks for the point out.
>> In fact, this feature only adds two instructions:
>> FP16 * FP16 + FP32
>> FP16 * FP16 - FP32
>>
>> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it
>> will call "FHM", I think call it "FMLXL" may be better, which can
>> stand for FMLAL/FMLSL instructions.
> Although "FHM" is cryptic, I think it makes sense to keep this as "FHM"
> to match the ISAR0 field name -- we've tended to follow this policy
> for other extension names unless there's a much better or more obvious
> name available
Agree with you, I also think the "FHM" is better.
>
> For "FMLXL", new instructions might be added in the future that match
> the same pattern, and then "FMLXL" could become ambiguous. So maybe
> this is not the best choice.
Ok.
>
>>> Maybe something like "widening half-precision floating-point multiply
>>> accumulate" is acceptable wording consistent with the existing
>>> architecture, but I just made that up, so it's not official ;)
>> how about something like "performing a multiplication of each FP16
>> element of one vector with the corresponding FP16 element of a second
>> vector, and to add or subtract this without an intermediate rounding
>> to the corresponding FP32 element in a third vector."?
> We could have that, I guess.
Ok, thanks!
>
>>>> instructions set. Let the userspace know about it via a
>>>> HWCAP bit and MRS emulation.
^ permalink raw reply
* [RESEND PATCH] arm64: v8.4: Support for new floating point multiplication variant
From: gengdongjiu @ 2017-12-12 2:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ebb6a36-0e09-1ac1-7785-cc9d4e4147fb@arm.com>
On 2017/12/12 2:58, Suzuki K Poulose wrote:
> Hi gengdongjiu
>
> Sorry for the late response. I have a similar patch to add the support for "FHM", which I was about to post it this week.
Suzuki, you are welcome.
May be you can not post again to avoid the duplicate review, thanks!
>
> On 11/12/17 13:29, Dave Martin wrote:
>> On Mon, Dec 11, 2017 at 08:47:00PM +0800, gengdongjiu wrote:
>>>
>>> On 2017/12/11 19:59, Dave P Martin wrote:
>>>> On Sat, Dec 09, 2017 at 03:28:42PM +0000, Dongjiu Geng wrote:
>>>>> ARM v8.4 extensions include support for new floating point
>>>>> multiplication variant instructions to the AArch64 SIMD
>>>>
>>>> Do we have any human-readable description of what the new instructions
>>>> do?
>>>>
>>>> Since the v8.4 spec itself only describes these as "New Floating
>>>> Point Multiplication Variant", I wonder what "FHM" actually stands
>>>> for.
>>> Thanks for the point out.
>>> In fact, this feature only adds two instructions:
>>> FP16 * FP16 + FP32
>>> FP16 * FP16 - FP32
>>>
>>> The spec call this bit to ID_AA64ISAR0_EL1.FHM, I do not know why it
>>> will call "FHM", I? think call it "FMLXL" may be better, which can
>>> stand for FMLAL/FMLSL instructions.
>>
>> Although "FHM" is cryptic, I think it makes sense to keep this as "FHM"
>> to match the ISAR0 field name -- we've tended to follow this policy
>> for other extension names unless there's a much better or more obvious
>> name available.
>>
>> For "FMLXL", new instructions might be added in the future that match
>> the same pattern, and then "FMLXL" could become ambiguous.? So maybe
>> this is not the best choice.
>
> I think the FHM stands for "FP Half precision Multiplication instructions". I vote for keeping the feature bit in sync with the register bit definition. i.e, FHM.
agree with you
>
> However, my version of the patch names the HWCAP bit "asimdfml", following the compiler name for the feature option "fp16fml", which
> is not perfect either. I think FHM is the safe option here.
yes, "FHM" is safe here.
>
>>
>>>> Maybe something like "widening half-precision floating-point multiply
>>>> accumulate" is acceptable wording consistent with the existing
>>>> architecture, but I just made that up, so it's not official ;)
>>>
>>> how about something like "performing a multiplication of each FP16
>>> element of one vector with the corresponding FP16 element of a second
>>> vector, and to add or subtract this without an intermediate rounding
>>> to the corresponding FP32 element in a third vector."?
>>
>> We could have that, I guess.
>>
>
> I agree, and that matches the feature description.
Ok, thanks!
>
>
^ permalink raw reply
* [PATCH net-next v5 2/2] net: ethernet: socionext: add AVE ethernet driver
From: Masami Hiramatsu @ 2017-12-12 2:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211134627.GU10595@n2100.armlinux.org.uk>
Hi Russell,
2017-12-11 22:46 GMT+09:00 Russell King - ARM Linux <linux@armlinux.org.uk>:
> On Mon, Dec 11, 2017 at 10:34:17PM +0900, Masami Hiramatsu wrote:
>> IMHO, even if we use SPDX license identifier, I recommend to use
>> C-style comments as many other files do, since it is C code.
>> If SPDX identifier requires C++ style, that is SPDX parser's issue
>> and should be fixed to get it from C-style comment.
>
> See the numerous emails on this subject already. The issue of C
> vs C++ comments has come up many times by many different people, but
> the result is the same. That's not going to happen. Linux kernel
> C files are required to use "//" for the SPDX identifier by order
> of Linus Torvalds.
OK, I got it.
>
> Linus has also revealed in that discussion that he has a preference
> for "//" style commenting for single comments, so it seems that the
> kernel coding style may change - but there is no desire for patches
> to "clean up" single line comments to use "//".
Thank you for making it clear.
Then what I'm considering is copyright notice lines. Those are usually
treat as the header lines, not single line. So
> +// SDPX-License-Identifier: GPL-2.0
> +// sni_ave.c - Socionext UniPhier AVE ethernet driver
> +// Copyright 2014 Panasonic Corporation
> +// Copyright 2015-2017 Socionext Inc.
is acceptable? or should we keep C-style header lines for new drivers?
> +// SDPX-License-Identifier: GPL-2.0
> +/*
> + * sni_ave.c - Socionext UniPhier AVE ethernet driver
> + * Copyright 2014 Panasonic Corporation
> + * Copyright 2015-2017 Socionext Inc.
> + */
I just concern that those lines are not "single". that's all. :)
>
> For further information, and to see the discussion that has already
> happened, the arguments that have been made about style, see the
> threads for the patch series that tglx has been posting wrt documenting
> the SPDX stuff for the kernel.
OK, got it.
https://lkml.org/lkml/2017/11/16/663
Thanks,
>
> Thanks (let's stop rehashing the same arguments.)
>
--
Masami Hiramatsu
^ permalink raw reply
* [Patch v6 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder
From: Smitha T Murthy @ 2017-12-12 2:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5b96b332-71a9-083a-2242-8bdf5554f010@linaro.org>
On Sat, 2017-12-09 at 20:48 +0200, Stanimir Varbanov wrote:
> Hi Smitha,
>
> Thanks for the patches!
>
> On 12/08/2017 11:08 AM, Smitha T Murthy wrote:
> > Add v4l2 controls for HEVC encoder
> >
> > Signed-off-by: Smitha T Murthy <smitha.t@samsung.com>
> > Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
> > ---
> > drivers/media/v4l2-core/v4l2-ctrls.c | 118 +++++++++++++++++++++++++++++++++++
> > include/uapi/linux/v4l2-controls.h | 92 ++++++++++++++++++++++++++-
> > 2 files changed, 209 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 4e53a86..3f98318 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -480,6 +480,56 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > NULL,
> > };
> >
> > + static const char * const hevc_profile[] = {
> > + "Main",
>
> You forgot "Main 10" profile.
>
Sorry I forgot to update it, I will fix it in the next version.
> > + "Main Still Picture",
> > + NULL,
> > + };
> > + static const char * const hevc_level[] = {
> > + "1",
> > + "2",
> > + "2.1",
> > + "3",
> > + "3.1",
> > + "4",
> > + "4.1",
> > + "5",
> > + "5.1",
> > + "5.2",
> > + "6",
> > + "6.1",
> > + "6.2",
> > + NULL,
> > + };
> > + static const char * const hevc_hierarchial_coding_type[] = {
> > + "B",
> > + "P",
> > + NULL,
> > + };
> > + static const char * const hevc_refresh_type[] = {
> > + "None",
> > + "CRA",
> > + "IDR",
> > + NULL,
> > + };
> > + static const char * const hevc_size_of_length_field[] = {
> > + "0",
> > + "1",
> > + "2",
> > + "4",
> > + NULL,
> > + };
> > + static const char * const hevc_tier_flag[] = {
> > + "Main",
> > + "High",
> > + NULL,
> > + };
> > + static const char * const hevc_loop_filter_mode[] = {
> > + "Disabled",
> > + "Enabled",
> > + "Disabled at slice boundary",
> > + "NULL",
> > + };
> >
> > switch (id) {
> > case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> > @@ -575,6 +625,20 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > return dv_it_content_type;
> > case V4L2_CID_DETECT_MD_MODE:
> > return detect_md_mode;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> > + return hevc_profile;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> > + return hevc_level;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE:
> > + return hevc_hierarchial_coding_type;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE:
> > + return hevc_refresh_type;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
> > + return hevc_size_of_length_field;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:
>
> Could you drop _FLAG suffix? Looking (briefly) into the spec they not
> specify `tier flag` but just `tier`.
>
Yes I will remove it.
> > + return hevc_tier_flag;
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE:
> > + return hevc_loop_filter_mode;
> >
> > default:
> > return NULL;
> > @@ -776,6 +840,53 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP: return "VPX P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX Profile";
> >
> > + /* HEVC controls */
> > + case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC I-Frame QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC P-Frame QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP: return "HEVC B-Frame QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP: return "HEVC Minimum QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP: return "HEVC Maximum QP Value";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE: return "HEVC Profile";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL: return "HEVC Level";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG: return "HEVC Tier Flag";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION: return "HEVC Frame Rate Resolution";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH: return "HEVC Maximum Coding Unit Depth";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC Refresh Type";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED: return "HEVC Constant Intra Prediction";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU: return "HEVC Lossless Encoding";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT: return "HEVC Wavefront";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE: return "HEVC Loop Filter";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP: return "HEVC QP Values";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE: return "HEVC Hierarchical Coding Type";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER: return "HEVC Hierarchical Coding Layer";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP: return "HEVC Hierarchical Lay 0 QP";
>
> s/Lay/Layer here and below
>
Ok I will change it.
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP: return "HEVC Hierarchical Lay 1 QP";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP: return "HEVC Hierarchical Lay 2 QP";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP: return "HEVC Hierarchical Lay 3 QP";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_QP: return "HEVC Hierarchical Lay 4 QP";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_QP: return "HEVC Hierarchical Lay 5 QP";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP: return "HEVC Hierarchical Lay 6 QP";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_BR: return "HEVC Hierarchical Lay 0 Bit Rate";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_BR: return "HEVC Hierarchical Lay 1 Bit Rate";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_BR: return "HEVC Hierarchical Lay 2 Bit Rate";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_BR: return "HEVC Hierarchical Lay 3 Bit Rate";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_BR: return "HEVC Hierarchical Lay 4 Bit Rate";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_BR: return "HEVC Hierarchical Lay 5 Bit Rate";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR: return "HEVC Hierarchical Lay 6 Bit Rate";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_GENERAL_PB: return "HEVC General PB";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_TEMPORAL_ID: return "HEVC Temporal ID";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_STRONG_SMOOTHING: return "HEVC Strong Intra Smoothing";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_INTRA_PU_SPLIT: return "HEVC Intra PU Split";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_TMV_PREDICTION: return "HEVC TMV Prediction";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_MAX_NUM_MERGE_MV_MINUS1: return "HEVC Max Number of Candidate MVs";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_WITHOUT_STARTCODE: return "HEVC ENC Without Startcode";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_PERIOD: return "HEVC Num of I-Frame b/w 2 IDR";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LF_BETA_OFFSET_DIV2: return "HEVC Loop Filter Beta Offset";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LF_TC_OFFSET_DIV2: return "HEVC Loop Filter TC Offset";
> > + case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD: return "HEVC Size of Length Field";
> > + case V4L2_CID_MPEG_VIDEO_REF_NUMBER_FOR_PFRAMES: return "Reference Frames for a P-Frame";
> > + case V4L2_CID_MPEG_VIDEO_PREPEND_SPSPPS_TO_IDR: return "Prepend SPS and PPS to IDR";
> > +
> > /* CAMERA controls */
> > /* Keep the order of the 'case's the same as in v4l2-controls.h! */
> > case V4L2_CID_CAMERA_CLASS: return "Camera Controls";
> > @@ -1069,6 +1180,13 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> > case V4L2_CID_TUNE_DEEMPHASIS:
> > case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
> > case V4L2_CID_DETECT_MD_MODE:
> > + case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> > + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE:
> > + case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE:
> > + case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
> > + case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:
> > + case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE:
> > *type = V4L2_CTRL_TYPE_MENU;
> > break;
> > case V4L2_CID_LINK_FREQ:
> > diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> > index 31bfc68..a4b8489 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -588,6 +588,97 @@ enum v4l2_vp8_golden_frame_sel {
> > #define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
> > #define V4L2_CID_MPEG_VIDEO_VPX_PROFILE (V4L2_CID_MPEG_BASE+511)
> >
> > +/* CIDs for HEVC encoding. Number gaps are for compatibility */
> > +
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (V4L2_CID_MPEG_BASE + 512)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (V4L2_CID_MPEG_BASE + 513)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (V4L2_CID_MPEG_BASE + 514)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (V4L2_CID_MPEG_BASE + 515)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (V4L2_CID_MPEG_BASE + 516)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (V4L2_CID_MPEG_BASE + 517)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE (V4L2_CID_MPEG_BASE + 518)
> > +enum v4l2_mpeg_video_hevc_hier_coding_type {
> > + V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B = 0,
> > + V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P = 1,
> > +};
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (V4L2_CID_MPEG_BASE + 519)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP (V4L2_CID_MPEG_BASE + 520)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP (V4L2_CID_MPEG_BASE + 521)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP (V4L2_CID_MPEG_BASE + 522)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP (V4L2_CID_MPEG_BASE + 523)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_QP (V4L2_CID_MPEG_BASE + 524)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_QP (V4L2_CID_MPEG_BASE + 525)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP (V4L2_CID_MPEG_BASE + 526)
> > +#define V4L2_CID_MPEG_VIDEO_HEVC_PROFILE (V4L2_CID_MPEG_BASE + 527)
> > +enum v4l2_mpeg_video_hevc_profile {
> > + V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN = 0,
>
> you forgot V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN10 profile.
>
Sorry I will correct it in the next patch series.
> > + V4L2_MPEG_VIDEO_HEVC_PROFILE_MAIN_STILL_PICTURE = 1,
> > +};
>
> <snip>
>
Thank you for the review.
Regards,
Smitha
^ permalink raw reply
* [PATCH 13/13] arc: do not use __print_symbol()
From: Sergey Senozhatsky @ 2017-12-12 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12708a61-ebc7-8f3f-cef6-4a725047de6d@synopsys.com>
On (12/11/17 08:28), Vineet Gupta wrote:
> On 12/11/2017 04:53 AM, Sergey Senozhatsky wrote:
> > __print_symbol() uses extra stack space to sprintf() symbol
> > information and then to feed that buffer to printk()
> >
> > char buffer[KSYM_SYMBOL_LEN];
> >
> > sprint_symbol(buffer, address);
> > printk(fmt, buffer);
> >
> > Replace __print_symbol() with a direct printk("%pS") call.
> >
> > Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
> > Cc: Vineet Gupta <vgupta@synopsys.com>
>
> Applied to arc for-curr
thanks.
-ss
^ permalink raw reply
* [PATCH 08/13] x86: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-12 2:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211174459.l2ugmyi6kcr33zxp@pd.tnic>
On (12/11/17 18:45), Borislav Petkov wrote:
> For the mce.c bit above:
>
> Acked-by: Borislav Petkov <bp@suse.de>
thanks.
-ss
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Sergey Senozhatsky @ 2017-12-12 2:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513009569.26342.43.camel@perches.com>
On (12/11/17 08:26), Joe Perches wrote:
> On Mon, 2017-12-11 at 21:50 +0900, Sergey Senozhatsky wrote:
> > print_symbol
>
> Yay.
>
> Just about exactly 5 years earlier...
> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137121.html
indeed :)
hopefully it won't take us another 5 years to finally
---
include/linux/kallsyms.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
index 7288f9c395b6..794fd35cad4b 100644
--- a/include/linux/kallsyms.h
+++ b/include/linux/kallsyms.h
@@ -176,7 +176,8 @@ void __check_printsym_format(const char *fmt, ...)
{
}
-static inline void print_symbol(const char *fmt, unsigned long addr)
+static inline void __deprecated print_symbol(const char *fmt,
+ unsigned long addr)
{
__check_printsym_format(fmt, "");
__print_symbol(fmt, (unsigned long)
---
-ss
^ permalink raw reply related
* [PATCH 11/13] irq debug: do not use print_symbol()
From: Sergey Senozhatsky @ 2017-12-12 2:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <063a776096964e8192c94e38413edbe0@AcuMS.aculab.com>
On (12/11/17 12:55), David Laight wrote:
> > kernel/irq/debug.h | 8 +++-----
> > 1 file changed, 3 insertions(+), 5 deletions(-)
> >
> > diff --git a/kernel/irq/debug.h b/kernel/irq/debug.h
> > index 17f05ef8f575..5766e15c1160 100644
> > --- a/kernel/irq/debug.h
> > +++ b/kernel/irq/debug.h
> ...
> > @@ -15,13 +13,13 @@ static inline void print_irq_desc(unsigned int irq, struct irq_desc *desc)
> > printk("irq %d, desc: %p, depth: %d, count: %d, unhandled: %d\n",
> > irq, desc, desc->depth, desc->irq_count, desc->irqs_unhandled);
> > printk("->handle_irq(): %p, ", desc->handle_irq);
> > - print_symbol("%s\n", (unsigned long)desc->handle_irq);
> > + pr_cont("%pS\n", desc->handle_irq);
>
> Looks like you can (and should) use a single printk() instead of pr_cont.
thanks, good point. those pr_cont()-s basically just replicate
the old behaviour; but it'll be better to get tid of them. will
follow up shortly.
-ss
^ permalink raw reply
* [PATCH 00/13] replace print_symbol() with printk()-s
From: Joe Perches @ 2017-12-12 3:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212024757.GC7798@jagdpanzerIV>
On Tue, 2017-12-12 at 11:47 +0900, Sergey Senozhatsky wrote:
> On (12/11/17 08:26), Joe Perches wrote:
> > On Mon, 2017-12-11 at 21:50 +0900, Sergey Senozhatsky wrote:
> > > print_symbol
> > Yay.
> > Just about exactly 5 years earlier...
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/137121.html
>
> indeed :)
>
> hopefully it won't take us another 5 years to finally
[]
> diff --git a/include/linux/kallsyms.h b/include/linux/kallsyms.h
[]
> -static inline void print_symbol(const char *fmt, unsigned long addr)
> +static inline void __deprecated print_symbol(const char *fmt,
> + unsigned long addr)
> {
> __check_printsym_format(fmt, "");
> __print_symbol(fmt, (unsigned long)
As far as I'm concerned, as soon as there is
no longer a single user in the kernel tree,
better to delete it instead.
^ permalink raw reply
* [PATCH 0/2] Fixes for SW PAN
From: Vinayak Menon @ 2017-12-12 3:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d2e49626-5c8a-470a-33d9-619475aa3525@codeaurora.org>
On 12/7/2017 2:25 PM, Vinayak Menon wrote:
> On 12/6/2017 11:56 PM, Will Deacon wrote:
>> On Wed, Dec 06, 2017 at 06:18:01PM +0000, Catalin Marinas wrote:
>>> On Wed, Dec 06, 2017 at 06:07:07PM +0000, Will Deacon wrote:
>>>> On Wed, Dec 06, 2017 at 06:01:35PM +0000, Catalin Marinas wrote:
>>>>> On Wed, Dec 06, 2017 at 05:56:42PM +0000, Will Deacon wrote:
>>>>>> On Wed, Dec 06, 2017 at 11:01:46PM +0530, Vinayak Menon wrote:
>>>>>>> On 12/6/2017 4:46 PM, Will Deacon wrote:
>>>>>>>> After lots of collective head scratching in response to Vinayak's mail
>>>>>>>> here:
>>>>>>>>
>>>>>>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-December/545641.html
>>>>>>>>
>>>>>>>> It turns out that we have a problem with SW PAN and kernel threads, where
>>>>>>>> the saved ttbr0 value for a kernel thread can be stale and subsequently
>>>>>>>> inherited by other kernel threads over a fork.
>>>>>>>>
>>>>>>>> These two patches attempt to fix that. We've not be able to reproduce
>>>>>>>> the exact failure reported above, but I added some assertions to the
>>>>>>>> uaccess routines to check for discrepancies between the active_mm pgd
>>>>>>>> and the saved ttbr0 value (ignoring the zero page) and these no longer
>>>>>>>> fire with these changes, but do fire without them if EFI runtime services
>>>>>>>> are enabled on my Seattle board.
>>>>>>> Thanks Will. So these 2 patches fix the case of kthreads having a stale saved ttbr0. The callstack I had shared
>>>>>>> in the original issue description was not of a kthread (its user task with PF_KTHREAD not set. The tsk->mm was
>>>>>>> set to NULL by exit_mm I think). So do you think this could be a different problem ?
>>>>>>> I had a look at the dumps again and what I see is that, the PA part of the saved ttbr0
>>>>>>> (from thread_info) is not the same as the pa(tsk->active_mm->pgd). The PA derived from saved ttbr0 actually
>>>>>>> points to a page which is "now" owned by slab.
>>>>>> Having not been able to reproduce the failure you described, I can't give
>>>>>> you a good answer to this.
>> Looking at the code (again), if we context switch in do_exit after exit_mm,
>> then the thread behaves an awful lot like a kernel thread: current->mm is
>> NULL and we're in lazy TLB mode.
> Yes, that could be the case.
> I am going to try out these 2 patches and see if the issue gets resolved. It usually takes more
> than a day to reproduce the problem. Will update you as soon as I get the results.
The patches seem to fix the issue. The original issue with non-kthreads is not seen even after 3 days of testing. Thanks Will.
>> Furthermore, that context switch will drop
>> the last reference to the old mm and the pgd will finally be freed.
>>
>> So I think my patches will solve your case too because we'll call
>> enter_lazy_tlb again when getting scheduled back in. If you have any way
>> to test them, that would be great.
^ permalink raw reply
* [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times
From: Xie XiuQi @ 2017-12-12 3:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211160536.11600-1-gengdongjiu@huawei.com>
Hi Dongjiu,
On 2017/12/12 0:05, Dongjiu Geng wrote:
> do_sea() calls arm64_notify_die() which will always signal
> user-space. It also returns whether APEI claimed the external
> abort as a RAS notification. If it returns failure do_mem_abort()
> will signal user-space too.
>
> do_mem_abort() wants to know if we handled the error, we always
> call arm64_notify_die() so can always return success.
>
> Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
> ---
> 1. Address James's comments to update the commit messages
> 2. Address James's comments to not change the si_code for SIGBUS
> ---
> arch/arm64/mm/fault.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> index b64958b..38b9f3e 100644
> --- a/arch/arm64/mm/fault.c
> +++ b/arch/arm64/mm/fault.c
> @@ -610,7 +610,6 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> {
> struct siginfo info;
> const struct fault_info *inf;
> - int ret = 0;
>
> inf = esr_to_fault_info(esr);
> pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
> @@ -625,7 +624,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> if (interrupts_enabled(regs))
> nmi_enter();
>
> - ret = ghes_notify_sea();
> + ghes_notify_sea();
>
> if (interrupts_enabled(regs))
> nmi_exit();
> @@ -640,7 +639,7 @@ static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
> info.si_addr = (void __user *)addr;
> arm64_notify_die("", regs, &info, esr);
>
> - return ret;
> + return 0;
It looks good to me. do_sea() has done all necessary action for SEA, so it should always return 0,
no matter ghes_notify_sea() return true or false.
Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
> }
>
> static const struct fault_info fault_info[] = {
> --
> 2.10.1
>
--
Thanks,
Xie XiuQi
^ permalink raw reply
* [RESEND PATCH V2] arm64: fault: avoid send SIGBUS two times
From: gengdongjiu @ 2017-12-12 4:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <316b5416-1268-1e9b-ae07-aa6cd31db8a8@huawei.com>
On 2017/12/12 11:31, Xie XiuQi wrote:
>> + return 0;
> It looks good to me. do_sea() has done all necessary action for SEA, so it should always return 0,
> no matter ghes_notify_sea() return true or false.
yes, it is.
>
> Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com>
Thanks XiuQi's review and comments.
>
>> }
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox