* [U-Boot] [PATCH v3 3/4] colibri_pxa270: drop edit, elf, fpga, hush, regex et al. for space reason
From: Marcel Ziswiler @ 2016-11-14 20:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1479156028-30553-1-git-send-email-marcel.ziswiler@toradex.com>
With em humble DM and Kconfig migraters U-Boot binary size keeps
increasing. Drop a bunch of less needed stuff to save another precious
20+ KB.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
Changes in v3: None
Changes in v2:
- Introduce new patch saving more precious space.
configs/colibri_pxa270_defconfig | 6 +++++-
include/configs/colibri_pxa270.h | 4 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/configs/colibri_pxa270_defconfig b/configs/colibri_pxa270_defconfig
index 85740c2..0b5c20d 100644
--- a/configs/colibri_pxa270_defconfig
+++ b/configs/colibri_pxa270_defconfig
@@ -1,13 +1,16 @@
CONFIG_ARM=y
CONFIG_TARGET_COLIBRI_PXA270=y
# CONFIG_DISPLAY_BOARDINFO is not set
-CONFIG_HUSH_PARSER=y
CONFIG_SYS_PROMPT="$ "
+# CONFIG_CMD_ELF is not set
# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_EXPORTENV is not set
+# CONFIG_CMD_IMPORTENV is not set
# CONFIG_CMD_LOADB is not set
# CONFIG_CMD_LOADS is not set
CONFIG_CMD_MMC=y
CONFIG_CMD_USB=y
+# CONFIG_CMD_FPGA is not set
# CONFIG_CMD_SETEXPR is not set
CONFIG_CMD_DHCP=y
CONFIG_CMD_PING=y
@@ -16,5 +19,6 @@ CONFIG_CMD_FAT=y
CONFIG_PXA_SERIAL=y
CONFIG_USB=y
CONFIG_USB_STORAGE=y
+# CONFIG_REGEX is not set
CONFIG_OF_LIBFDT=y
# CONFIG_EFI_LOADER is not set
diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h
index 53efe3a..9f7c4a5 100644
--- a/include/configs/colibri_pxa270.h
+++ b/include/configs/colibri_pxa270.h
@@ -97,8 +97,8 @@
#define CONFIG_SYS_MAXARGS 16
#define CONFIG_SYS_BARGSIZE CONFIG_SYS_CBSIZE
#define CONFIG_SYS_DEVICE_NULLDEV 1
-#define CONFIG_CMDLINE_EDITING 1
-#define CONFIG_AUTO_COMPLETE 1
+#undef CONFIG_CMDLINE_EDITING /* Saves 2.5 KB */
+#undef CONFIG_AUTO_COMPLETE /* Saves 2.5 KB */
/*
* Clock Configuration
--
2.5.5
^ permalink raw reply related
* [U-Boot] [PATCH v3 2/4] serial: pxa: integrate optional driver model handling
From: Marcel Ziswiler @ 2016-11-14 20:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1479156028-30553-1-git-send-email-marcel.ziswiler@toradex.com>
Optional driver model handling integration.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Changes in v3:
- Drop spurious newline.
- Add Marek's reviewed-by.
Changes in v2: None
drivers/serial/serial_pxa.c | 183 +++++++++++++++++++++-------------
include/dm/platform_data/serial_pxa.h | 56 +++++++++++
2 files changed, 169 insertions(+), 70 deletions(-)
create mode 100644 include/dm/platform_data/serial_pxa.h
diff --git a/drivers/serial/serial_pxa.c b/drivers/serial/serial_pxa.c
index 1eb19ec..ea5971b 100644
--- a/drivers/serial/serial_pxa.c
+++ b/drivers/serial/serial_pxa.c
@@ -14,6 +14,9 @@
*
* Copyright (C) 1999 2000 2001 Erik Mouw (J.A.K.Mouw at its.tudelft.nl)
*
+ * Modified to add driver model (DM) support
+ * (C) Copyright 2016 Marcel Ziswiler <marcel.ziswiler@toradex.com>
+ *
* SPDX-License-Identifier: GPL-2.0+
*/
@@ -21,73 +24,17 @@
#include <asm/arch/pxa-regs.h>
#include <asm/arch/regs-uart.h>
#include <asm/io.h>
+#include <dm.h>
+#include <dm/platform_data/serial_pxa.h>
#include <linux/compiler.h>
#include <serial.h>
#include <watchdog.h>
DECLARE_GLOBAL_DATA_PTR;
-/*
- * The numbering scheme differs here for PXA25x, PXA27x and PXA3xx so we can
- * easily handle enabling of clock.
- */
-#ifdef CONFIG_CPU_MONAHANS
-#define UART_CLK_BASE CKENA_21_BTUART
-#define UART_CLK_REG CKENA
-#define BTUART_INDEX 0
-#define FFUART_INDEX 1
-#define STUART_INDEX 2
-#elif CONFIG_CPU_PXA25X
-#define UART_CLK_BASE (1 << 4) /* HWUART */
-#define UART_CLK_REG CKEN
-#define HWUART_INDEX 0
-#define STUART_INDEX 1
-#define FFUART_INDEX 2
-#define BTUART_INDEX 3
-#else /* PXA27x */
-#define UART_CLK_BASE CKEN5_STUART
-#define UART_CLK_REG CKEN
-#define STUART_INDEX 0
-#define FFUART_INDEX 1
-#define BTUART_INDEX 2
-#endif
-
-/*
- * Only PXA250 has HWUART, to avoid poluting the code with more macros,
- * artificially introduce this.
- */
-#ifndef CONFIG_CPU_PXA25X
-#define HWUART_INDEX 0xff
-#endif
-
-static uint32_t pxa_uart_get_baud_divider(void)
-{
- if (gd->baudrate == 1200)
- return 768;
- else if (gd->baudrate == 9600)
- return 96;
- else if (gd->baudrate == 19200)
- return 48;
- else if (gd->baudrate == 38400)
- return 24;
- else if (gd->baudrate == 57600)
- return 16;
- else if (gd->baudrate == 115200)
- return 8;
- else /* Unsupported baudrate */
- return 0;
-}
-
-static struct pxa_uart_regs *pxa_uart_index_to_regs(uint32_t uart_index)
+static uint32_t pxa_uart_get_baud_divider(int baudrate)
{
- switch (uart_index) {
- case FFUART_INDEX: return (struct pxa_uart_regs *)FFUART_BASE;
- case BTUART_INDEX: return (struct pxa_uart_regs *)BTUART_BASE;
- case STUART_INDEX: return (struct pxa_uart_regs *)STUART_BASE;
- case HWUART_INDEX: return (struct pxa_uart_regs *)HWUART_BASE;
- default:
- return NULL;
- }
+ return 921600 / baudrate;
}
static void pxa_uart_toggle_clock(uint32_t uart_index, int enable)
@@ -110,20 +57,14 @@ static void pxa_uart_toggle_clock(uint32_t uart_index, int enable)
/*
* Enable clock and set baud rate, parity etc.
*/
-void pxa_setbrg_dev(uint32_t uart_index)
+void pxa_setbrg_common(struct pxa_uart_regs *uart_regs, int port, int baudrate)
{
- uint32_t divider = 0;
- struct pxa_uart_regs *uart_regs;
-
- divider = pxa_uart_get_baud_divider();
+ uint32_t divider = pxa_uart_get_baud_divider(baudrate);
if (!divider)
hang();
- uart_regs = pxa_uart_index_to_regs(uart_index);
- if (!uart_regs)
- hang();
- pxa_uart_toggle_clock(uart_index, 1);
+ pxa_uart_toggle_clock(port, 1);
/* Disable interrupts and FIFOs */
writel(0, &uart_regs->ier);
@@ -139,13 +80,38 @@ void pxa_setbrg_dev(uint32_t uart_index)
writel(IER_UUE, &uart_regs->ier);
}
+#ifndef CONFIG_DM_SERIAL
+static struct pxa_uart_regs *pxa_uart_index_to_regs(uint32_t uart_index)
+{
+ switch (uart_index) {
+ case FFUART_INDEX: return (struct pxa_uart_regs *)FFUART_BASE;
+ case BTUART_INDEX: return (struct pxa_uart_regs *)BTUART_BASE;
+ case STUART_INDEX: return (struct pxa_uart_regs *)STUART_BASE;
+ case HWUART_INDEX: return (struct pxa_uart_regs *)HWUART_BASE;
+ default:
+ return NULL;
+ }
+}
+
+/*
+ * Enable clock and set baud rate, parity etc.
+ */
+void pxa_setbrg_dev(uint32_t uart_index)
+{
+ struct pxa_uart_regs *uart_regs = pxa_uart_index_to_regs(uart_index);
+ if (!uart_regs)
+ panic("Failed getting UART registers\n");
+
+ pxa_setbrg_common(uart_regs, uart_index, gd->baudrate);
+}
+
/*
* Initialise the serial port with the given baudrate. The settings
* are always 8 data bits, no parity, 1 stop bit, no start bits.
*/
int pxa_init_dev(unsigned int uart_index)
{
- pxa_setbrg_dev (uart_index);
+ pxa_setbrg_dev(uart_index);
return 0;
}
@@ -297,3 +263,80 @@ void pxa_serial_initialize(void)
serial_register(&serial_stuart_device);
#endif
}
+#endif /* CONFIG_DM_SERIAL */
+
+#ifdef CONFIG_DM_SERIAL
+static int pxa_serial_probe(struct udevice *dev)
+{
+ struct pxa_serial_platdata *plat = dev->platdata;
+
+ pxa_setbrg_common((struct pxa_uart_regs *)plat->base, plat->port,
+ plat->baudrate);
+ return 0;
+}
+
+static int pxa_serial_putc(struct udevice *dev, const char ch)
+{
+ struct pxa_serial_platdata *plat = dev->platdata;
+ struct pxa_uart_regs *uart_regs = (struct pxa_uart_regs *)plat->base;
+
+ /* Wait for last character to go. */
+ if (!(readl(&uart_regs->lsr) & LSR_TEMT))
+ return -EAGAIN;
+
+ writel(ch, &uart_regs->thr);
+
+ return 0;
+}
+
+static int pxa_serial_getc(struct udevice *dev)
+{
+ struct pxa_serial_platdata *plat = dev->platdata;
+ struct pxa_uart_regs *uart_regs = (struct pxa_uart_regs *)plat->base;
+
+ /* Wait for a character to arrive. */
+ if (!(readl(&uart_regs->lsr) & LSR_DR))
+ return -EAGAIN;
+
+ return readl(&uart_regs->rbr) & 0xff;
+}
+
+int pxa_serial_setbrg(struct udevice *dev, int baudrate)
+{
+ struct pxa_serial_platdata *plat = dev->platdata;
+ struct pxa_uart_regs *uart_regs = (struct pxa_uart_regs *)plat->base;
+ int port = plat->port;
+
+ pxa_setbrg_common(uart_regs, port, baudrate);
+
+ return 0;
+}
+
+static int pxa_serial_pending(struct udevice *dev, bool input)
+{
+ struct pxa_serial_platdata *plat = dev->platdata;
+ struct pxa_uart_regs *uart_regs = (struct pxa_uart_regs *)plat->base;
+
+ if (input)
+ return readl(&uart_regs->lsr) & LSR_DR ? 1 : 0;
+ else
+ return readl(&uart_regs->lsr) & LSR_TEMT ? 0 : 1;
+
+ return 0;
+}
+
+static const struct dm_serial_ops pxa_serial_ops = {
+ .putc = pxa_serial_putc,
+ .pending = pxa_serial_pending,
+ .getc = pxa_serial_getc,
+ .setbrg = pxa_serial_setbrg,
+};
+
+U_BOOT_DRIVER(serial_pxa) = {
+ .name = "serial_pxa",
+ .id = UCLASS_SERIAL,
+ .probe = pxa_serial_probe,
+ .ops = &pxa_serial_ops,
+ .flags = DM_FLAG_PRE_RELOC,
+};
+#endif /* CONFIG_DM_SERIAL */
diff --git a/include/dm/platform_data/serial_pxa.h b/include/dm/platform_data/serial_pxa.h
new file mode 100644
index 0000000..b19a4a6
--- /dev/null
+++ b/include/dm/platform_data/serial_pxa.h
@@ -0,0 +1,56 @@
+/*
+ * Copyright (c) 2016 Marcel Ziswiler <marcel.ziswiler@toradex.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#ifndef __SERIAL_PXA_H
+#define __SERIAL_PXA_H
+
+/*
+ * The numbering scheme differs here for PXA25x, PXA27x and PXA3xx so we can
+ * easily handle enabling of clock.
+ */
+#ifdef CONFIG_CPU_MONAHANS
+#define UART_CLK_BASE CKENA_21_BTUART
+#define UART_CLK_REG CKENA
+#define BTUART_INDEX 0
+#define FFUART_INDEX 1
+#define STUART_INDEX 2
+#elif CONFIG_CPU_PXA25X
+#define UART_CLK_BASE (1 << 4) /* HWUART */
+#define UART_CLK_REG CKEN
+#define HWUART_INDEX 0
+#define STUART_INDEX 1
+#define FFUART_INDEX 2
+#define BTUART_INDEX 3
+#else /* PXA27x */
+#define UART_CLK_BASE CKEN5_STUART
+#define UART_CLK_REG CKEN
+#define STUART_INDEX 0
+#define FFUART_INDEX 1
+#define BTUART_INDEX 2
+#endif
+
+/*
+ * Only PXA250 has HWUART, to avoid poluting the code with more macros,
+ * artificially introduce this.
+ */
+#ifndef CONFIG_CPU_PXA25X
+#define HWUART_INDEX 0xff
+#endif
+
+/*
+ * struct pxa_serial_platdata - information about a PXA port
+ *
+ * @base: Uart port base register address
+ * @port: Uart port index, for cpu with pinmux for uart / gpio
+ * baudrtatre: Uart port baudrate
+ */
+struct pxa_serial_platdata {
+ struct pxa_uart_regs *base;
+ int port;
+ int baudrate;
+};
+
+#endif /* __SERIAL_PXA_H */
--
2.5.5
^ permalink raw reply related
* [U-Boot] [PATCH v3 1/4] serial: pxa: use kconfig for serial configuration
From: Marcel Ziswiler @ 2016-11-14 20:40 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1479156028-30553-1-git-send-email-marcel.ziswiler@toradex.com>
Migrate the PXA serial driver to be configured via Kconfig.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Marek Vasut <marex@denx.de>
---
Changes in v3:
- Add Marek's reviewed-by.
Changes in v2: None
configs/colibri_pxa270_defconfig | 1 +
configs/h2200_defconfig | 1 +
configs/zipitz2_defconfig | 1 +
drivers/serial/Kconfig | 6 ++++++
include/configs/colibri_pxa270.h | 1 -
include/configs/h2200.h | 2 --
include/configs/zipitz2.h | 1 -
scripts/config_whitelist.txt | 1 -
8 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/configs/colibri_pxa270_defconfig b/configs/colibri_pxa270_defconfig
index 9a57041..85740c2 100644
--- a/configs/colibri_pxa270_defconfig
+++ b/configs/colibri_pxa270_defconfig
@@ -13,6 +13,7 @@ CONFIG_CMD_DHCP=y
CONFIG_CMD_PING=y
CONFIG_CMD_EXT2=y
CONFIG_CMD_FAT=y
+CONFIG_PXA_SERIAL=y
CONFIG_USB=y
CONFIG_USB_STORAGE=y
CONFIG_OF_LIBFDT=y
diff --git a/configs/h2200_defconfig b/configs/h2200_defconfig
index c1b359e..a47159a 100644
--- a/configs/h2200_defconfig
+++ b/configs/h2200_defconfig
@@ -24,3 +24,4 @@ CONFIG_SYS_PROMPT="> "
# CONFIG_CMD_NFS is not set
CONFIG_CMD_PING=y
# CONFIG_CMD_MISC is not set
+CONFIG_PXA_SERIAL=y
diff --git a/configs/zipitz2_defconfig b/configs/zipitz2_defconfig
index 8eb9be4..5846579 100644
--- a/configs/zipitz2_defconfig
+++ b/configs/zipitz2_defconfig
@@ -14,6 +14,7 @@ CONFIG_CMD_USB=y
CONFIG_CMD_CACHE=y
CONFIG_CMD_EXT2=y
CONFIG_CMD_FAT=y
+CONFIG_PXA_SERIAL=y
CONFIG_USB=y
CONFIG_USB_STORAGE=y
CONFIG_LCD=y
diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 56c024f..620dd82 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -407,4 +407,10 @@ config MSM_SERIAL
for example APQ8016 and MSM8916.
Single baudrate is supported in current implementation (115200).
+config PXA_SERIAL
+ bool "PXA serial port support"
+ help
+ If you have a machine based on a Marvell XScale PXA2xx CPU you
+ can enable its onboard serial ports by enabling this option.
+
endmenu
diff --git a/include/configs/colibri_pxa270.h b/include/configs/colibri_pxa270.h
index b15ed72..53efe3a 100644
--- a/include/configs/colibri_pxa270.h
+++ b/include/configs/colibri_pxa270.h
@@ -47,7 +47,6 @@
/*
* Serial Console Configuration
*/
-#define CONFIG_PXA_SERIAL
#define CONFIG_FFUART 1
#define CONFIG_CONS_INDEX 3
#define CONFIG_BAUDRATE 115200
diff --git a/include/configs/h2200.h b/include/configs/h2200.h
index 8e77982..18b5488 100644
--- a/include/configs/h2200.h
+++ b/include/configs/h2200.h
@@ -107,8 +107,6 @@
/*
* Serial port
*/
-
-#define CONFIG_PXA_SERIAL
#define CONFIG_FFUART
#define CONFIG_CONS_INDEX 3
diff --git a/include/configs/zipitz2.h b/include/configs/zipitz2.h
index ed2c9ac..97dfc0e 100644
--- a/include/configs/zipitz2.h
+++ b/include/configs/zipitz2.h
@@ -49,7 +49,6 @@
* Serial Console Configuration
* STUART - the lower serial port on Colibri board
*/
-#define CONFIG_PXA_SERIAL
#define CONFIG_STUART 1
#define CONFIG_CONS_INDEX 2
#define CONFIG_BAUDRATE 115200
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index c0571c3..ab8e6cd 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -3740,7 +3740,6 @@ CONFIG_PWM_IMX
CONFIG_PXA_LCD
CONFIG_PXA_MMC_GENERIC
CONFIG_PXA_PWR_I2C
-CONFIG_PXA_SERIAL
CONFIG_PXA_STD_I2C
CONFIG_PXA_VGA
CONFIG_PXA_VIDEO
--
2.5.5
^ permalink raw reply related
* [U-Boot] [PATCH v3 0/4] serial: pxa: kconfig and optional driver model integration
From: Marcel Ziswiler @ 2016-11-14 20:40 UTC (permalink / raw)
To: u-boot
This series integrates both Kconfig as well as optional driver model
support for the PXA serial driver. As I do not have any of the other
hardware available for testing for now I only transitioned the
Colibri PXA270 to actually make use of DM_SERIAL. As space on this
mostly NOR based hardware is rather constrained I decided against
also integrating device tree support for now but rather use olde
platform data. Your input on this is more than welcome.
Changes in v3:
- Add Marek's reviewed-by.
- Drop spurious newline.
- Add Marek's reviewed-by.
Changes in v2:
- Introduce new patch saving more precious space.
- Drop baudrate checks.
- Use panic instead of just hang() to more gracefully handle
failure case.
- Drop superfluous parenthesis around plat->base.
- Capitalise header file gating macro.
- Replace tab with space after #define.
Marcel Ziswiler (4):
serial: pxa: use kconfig for serial configuration
serial: pxa: integrate optional driver model handling
colibri_pxa270: drop edit, elf, fpga, hush, regex et al. for space
reason
colibri_pxa270: transition to driver model for serial
board/toradex/colibri_pxa270/colibri_pxa270.c | 18 ++-
configs/colibri_pxa270_defconfig | 9 +-
configs/h2200_defconfig | 1 +
configs/zipitz2_defconfig | 1 +
drivers/serial/Kconfig | 6 +
drivers/serial/serial_pxa.c | 183 ++++++++++++++++----------
include/configs/colibri_pxa270.h | 7 +-
include/configs/h2200.h | 2 -
include/configs/zipitz2.h | 1 -
include/dm/platform_data/serial_pxa.h | 56 ++++++++
scripts/config_whitelist.txt | 1 -
11 files changed, 203 insertions(+), 82 deletions(-)
create mode 100644 include/dm/platform_data/serial_pxa.h
--
2.5.5
^ permalink raw reply
* Re: [AMDGPU][CIK] PRIME with DRI3 + stalls rendering
From: Shawn Starr @ 2016-11-14 20:40 UTC (permalink / raw)
To: amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
Cc: Michel Dänzer, Mario Kleiner
In-Reply-To: <472120da-9ec1-3963-484f-24add93f8eb6-otUistvHUpPR7s880joybQ@public.gmane.org>
On Monday, November 14, 2016 10:40:17 AM EST Michel Dänzer wrote:
> On 13/11/16 06:59 AM, Shawn Starr wrote:
> > I'm currently trying the new fence patches that prevent tearing in PRIME
> > on
> > Bonaire CIK, it works with no tearing with latest patches from Mario, but
> > there is significant frame stalls, even though the performance is higher
> > than running the AMDGPU as dedicated.
>
> Please elaborate on what "frame stalls" means exactly.
It looks like vsync issues, even though if I try vblank_mode=# it still shows
stalling.
I'll have to make a video to show the results and post link here.
Thanks,
Shawn
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [Buildroot] [PATCH v1 1/2] lcms2: fix lcms2.pc.in thread library dependency (for static linking)
From: Peter Seiderer @ 2016-11-14 20:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161113143404.27eefe75@free-electrons.com>
On Sun, 13 Nov 2016 14:34:04 +0100, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> On Fri, 11 Nov 2016 23:54:10 +0100, Peter Seiderer wrote:
> > Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> > ---
> > ...Fix-lcms2.pc.in-thread-library-dependency.patch | 26 ++++++++++++++++++++++
> > 1 file changed, 26 insertions(+)
> > create mode 100644 package/lcms2/0001-Fix-lcms2.pc.in-thread-library-dependency.patch
>
> Applied to master, thanks. Please submit the patch upstream. Thanks!
O.k, done [1]...
Regards,
Peter
[1] https://github.com/mm2/Little-CMS/pull/106
>
> Thomas
^ permalink raw reply
* [Buildroot] [PATCH v2] config: bump U-Boot to 2016.11 in synopsys defconfigs
From: Thomas Petazzoni @ 2016-11-14 20:38 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479146820-46777-1-git-send-email-vzakhar@synopsys.com>
Hello,
On Mon, 14 Nov 2016 21:07:00 +0300, Vlad Zakharov wrote:
> With this commit we upgrade U-Boot version to 2016.11
> in "snps_axs101_defconfig" and "snps_axs103_defconfig".
>
> Important fixes: new version fixes U-Boot build for arc700.
> Since gcc-6.x "-marc700" option is no longer supported,
> "-mcpu=arc700" should be used instead.
>
> We haven't sent it before as we were waiting for U-Boot
> 2016.11 release.
>
> Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
> ---
> Changes v1..v2
> - Replace 2016.11-rc3 release candidate with 2016.11 release version
Applied to master, after slightly tweaking the commit title. Thanks!
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [git commit] configs/snps_axs*: bump U-Boot to 2016.11
From: Thomas Petazzoni @ 2016-11-14 20:37 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=c418476aa85e8158c3e309bb08c7bdf77665c70c
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
With this commit we upgrade U-Boot version to 2016.11 in
"snps_axs101_defconfig" and "snps_axs103_defconfig".
Important fixes: new version fixes U-Boot build for arc700. Since
gcc-6.x "-marc700" option is no longer supported, "-mcpu=arc700"
should be used instead.
We haven't sent it before as we were waiting for U-Boot 2016.11
release.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
configs/snps_axs101_defconfig | 2 +-
configs/snps_axs103_defconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/configs/snps_axs101_defconfig b/configs/snps_axs101_defconfig
index eea7a50..07564b4 100644
--- a/configs/snps_axs101_defconfig
+++ b/configs/snps_axs101_defconfig
@@ -21,6 +21,6 @@ BR2_LINUX_KERNEL_DEFCONFIG="axs101"
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.07"
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.11"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="axs101"
BR2_TARGET_UBOOT_NEEDS_DTC=y
diff --git a/configs/snps_axs103_defconfig b/configs/snps_axs103_defconfig
index 08c55de..d2a838e 100644
--- a/configs/snps_axs103_defconfig
+++ b/configs/snps_axs103_defconfig
@@ -22,6 +22,6 @@ BR2_LINUX_KERNEL_DEFCONFIG="axs103_smp"
BR2_TARGET_UBOOT=y
BR2_TARGET_UBOOT_BUILD_SYSTEM_KCONFIG=y
BR2_TARGET_UBOOT_CUSTOM_VERSION=y
-BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.07"
+BR2_TARGET_UBOOT_CUSTOM_VERSION_VALUE="2016.11"
BR2_TARGET_UBOOT_BOARD_DEFCONFIG="axs103"
BR2_TARGET_UBOOT_NEEDS_DTC=y
^ permalink raw reply related
* [Buildroot] [PATCH next v1] lcms2: bump version to 2.8
From: Thomas Petazzoni @ 2016-11-14 20:36 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1479154612-21070-1-git-send-email-ps.report@gmx.net>
Hello,
On Mon, 14 Nov 2016 21:16:52 +0100, Peter Seiderer wrote:
> For ChangeLog see [1].
>
> [1] https://github.com/mm2/Little-CMS/blob/master/ChangeLog
>
> Signed-off-by: Peter Seiderer <ps.report@gmx.net>
> ---
> package/lcms2/lcms2.hash | 7 +++----
> package/lcms2/lcms2.mk | 4 ++--
> 2 files changed, 5 insertions(+), 6 deletions(-)
Applied to next, thanks.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [Buildroot] [git commit branch/next] lcms2: bump version to 2.8
From: Thomas Petazzoni @ 2016-11-14 20:36 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=4309b96f3a38a2ed40389612c28a47917595667b
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/next
For ChangeLog see [1].
[1] https://github.com/mm2/Little-CMS/blob/master/ChangeLog
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
package/lcms2/lcms2.hash | 7 +++----
package/lcms2/lcms2.mk | 4 ++--
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/package/lcms2/lcms2.hash b/package/lcms2/lcms2.hash
index 908822f..1cf1017 100644
--- a/package/lcms2/lcms2.hash
+++ b/package/lcms2/lcms2.hash
@@ -1,5 +1,4 @@
-# From http://sourceforge.net/projects/lcms/files/lcms/2.7/
-sha1 625f0d74bad4a0f6f917120fd992437d26f754d2 lcms2-2.7.tar.gz
-md5 06c1626f625424a811fb4b5eb070839d lcms2-2.7.tar.gz
+# From https://sourceforge.net/projects/lcms/files/lcms/2.8
+sha1 e9535ec4a572b8fc7a1c405c35e6f4dc97714197 lcms2-2.8.tar.gz
# Locally computed:
-sha256 4524234ae7de185e6b6da5d31d6875085b2198bc63b1211f7dde6e2d197d6a53 lcms2-2.7.tar.gz
+sha256 66d02b229d2ea9474e62c2b6cd6720fde946155cd1d0d2bffdab829790a0fb22 lcms2-2.8.tar.gz
diff --git a/package/lcms2/lcms2.mk b/package/lcms2/lcms2.mk
index 265af29..8d0609e 100644
--- a/package/lcms2/lcms2.mk
+++ b/package/lcms2/lcms2.mk
@@ -4,8 +4,8 @@
#
################################################################################
-LCMS2_VERSION = 2.7
-LCMS2_SITE = http://downloads.sourceforge.net/lcms/lcms
+LCMS2_VERSION = 2.8
+LCMS2_SITE = http://downloads.sourceforge.net/project/lcms/lcms/$(LCMS2_VERSION)
LCMS2_LICENSE = MIT
LCMS2_LICENSE_FILES = COPYING
LCMS2_INSTALL_STAGING = YES
^ permalink raw reply related
* [GIT PULL] RTC fixes for 4.9
From: Alexandre Belloni @ 2016-11-14 20:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: rtc-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
Hi Linus,
Here are a few driver fixes for 4.9. It has been calm for a while so I
don't expect more for this cycle.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.9-2
for you to fetch changes up to efce21fc43e00a76aee7b0a1eda73730ed2d5d3a:
rtc: omap: prevent disabling of clock/module during suspend (2016-11-04 23:11:39 +0100)
----------------------------------------------------------------
RTC for 4.9 #2
Drivers:
- asm9260: fix module autoload
- cmos: fix crashes
- omap: fix clock handling
----------------------------------------------------------------
Javier Martinez Canillas (1):
rtc: asm9260: fix module autoload
LABBE Corentin (1):
rtc: cmos: remove all __exit_p annotations
Lokesh Vutla (1):
rtc: omap: Fix selecting external osc
Tero Kristo (1):
rtc: omap: prevent disabling of clock/module during suspend
Ville Syrjälä (1):
rtc: cmos: Don't enable interrupts in the middle of the interrupt handler
drivers/rtc/rtc-asm9260.c | 1 +
drivers/rtc/rtc-cmos.c | 15 ++++++++-------
drivers/rtc/rtc-omap.c | 38 ++++++++++++++++++++++++++++++--------
3 files changed, 39 insertions(+), 15 deletions(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH kvm-unit-tests v2 09/17] x86/vmexit: leverage pci_scan_bars()
From: Peter Xu @ 2016-11-14 20:35 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, rkrcmar, agordeev, jan.kiszka, pbonzini
In-Reply-To: <20161110192758.eqazpjk3243pttb5@hawk.localdomain>
On Thu, Nov 10, 2016 at 08:27:58PM +0100, Andrew Jones wrote:
[...]
> > @@ -389,17 +389,12 @@ int main(int ac, char **av)
> > ret = pci_find_dev(PCI_VENDOR_ID_REDHAT, PCI_DEVICE_ID_REDHAT_TEST);
> > if (ret != PCIDEVADDR_INVALID) {
> > pci_dev_init(&pcidev, ret);
> > - for (i = 0; i < PCI_TESTDEV_NUM_BARS; i++) {
> > - if (!pci_bar_is_valid(&pcidev, i)) {
> > - continue;
> > - }
> > - if (pci_bar_is_memory(&pcidev, i)) {
> > - membar = pci_bar_get_addr(&pcidev, i);
> > - pci_test.memaddr = ioremap(membar, PAGE_SIZE);
> > - } else {
> > - pci_test.iobar = pci_bar_get_addr(&pcidev, i);
> > - }
> > - }
> > + pci_scan_bars(&pcidev);
> > + assert(pci_bar_is_memory(&pcidev, PCI_TESTDEV_BAR_MEM));
> > + assert(!pci_bar_is_memory(&pcidev, PCI_TESTDEV_BAR_IO));
> > + membar = pcidev.bar[PCI_TESTDEV_BAR_MEM];
>
> nit: I'd drop 'membar' and just pass pcidev.bar to ioremap
Below printf() is using it as well. I kept it in case anyone is using
the below printf for any reason.
>
> > + pci_test.memaddr = ioremap(membar, PAGE_SIZE);
> > + pci_test.iobar = pcidev.bar[PCI_TESTDEV_BAR_IO];
> > printf("pci-testdev at 0x%x membar %lx iobar %x\n",
> > pcidev.bdf, membar, pci_test.iobar);
> > }
> > --
> > 2.7.4
> >
Thanks,
-- peterx
^ permalink raw reply
* Re: [RFC][PATCH 5/7] kref: Implement kref_put_lock()
From: Kees Cook @ 2016-11-14 20:35 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Greg KH, Will Deacon, Reshetova, Elena, Arnd Bergmann,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, David Windsor, LKML
In-Reply-To: <20161114174446.690415221@infradead.org>
On Mon, Nov 14, 2016 at 9:39 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> Because home-rolling your own is _awesome_, stop doing it. Provide
> kref_put_lock(), just like kref_put_mutex() but for a spinlock.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> ---
> include/linux/kref.h | 21 +++++++++++++++------
> net/sunrpc/svcauth.c | 15 ++++++++++-----
> 2 files changed, 25 insertions(+), 11 deletions(-)
>
> --- a/include/linux/kref.h
> +++ b/include/linux/kref.h
> @@ -86,12 +86,21 @@ static inline int kref_put_mutex(struct
> struct mutex *lock)
> {
> WARN_ON(release == NULL);
This WARN_ON makes sense, yes, though it seems like it should be deal
with differently. If it's NULL, we'll just Oops when we call release()
later... Seems like this should saturate the kref or something else
similar.
> - if (unlikely(!atomic_add_unless(&kref->refcount, -1, 1))) {
> - mutex_lock(lock);
> - if (unlikely(!atomic_dec_and_test(&kref->refcount))) {
> - mutex_unlock(lock);
> - return 0;
> - }
> +
> + if (atomic_dec_and_mutex_lock(&kref->refcount, lock)) {
> + release(kref);
> + return 1;
> + }
> + return 0;
> +}
> +
> +static inline int kref_put_lock(struct kref *kref,
> + void (*release)(struct kref *kref),
> + spinlock_t *lock)
> +{
> + WARN_ON(release == NULL);
> +
> + if (atomic_dec_and_lock(&kref->refcount, lock)) {
> release(kref);
> return 1;
> }
> --- a/net/sunrpc/svcauth.c
> +++ b/net/sunrpc/svcauth.c
> @@ -127,13 +127,18 @@ static struct hlist_head auth_domain_tab
> static spinlock_t auth_domain_lock =
> __SPIN_LOCK_UNLOCKED(auth_domain_lock);
>
> +static void auth_domain_release(struct kref *kref)
> +{
> + struct auth_domain *dom = container_of(kref, struct auth_domain, ref);
> +
> + hlist_del(&dom->hash);
> + dom->flavour->domain_release(dom);
> + spin_unlock(&auth_domain_lock);
> +}
> +
> void auth_domain_put(struct auth_domain *dom)
> {
> - if (atomic_dec_and_lock(&dom->ref.refcount, &auth_domain_lock)) {
> - hlist_del(&dom->hash);
> - dom->flavour->domain_release(dom);
> - spin_unlock(&auth_domain_lock);
> - }
> + kref_put_lock(&dom->ref, auth_domain_release, &auth_domain_lock);
> }
> EXPORT_SYMBOL_GPL(auth_domain_put);
>
>
>
--
Kees Cook
Nexus Security
^ permalink raw reply
* [rtc-linux] [GIT PULL] RTC fixes for 4.9
From: Alexandre Belloni @ 2016-11-14 20:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: rtc-linux, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2039 bytes --]
Hi Linus,
Here are a few driver fixes for 4.9. It has been calm for a while so I
don't expect more for this cycle.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/rtc-4.9-2
for you to fetch changes up to efce21fc43e00a76aee7b0a1eda73730ed2d5d3a:
rtc: omap: prevent disabling of clock/module during suspend (2016-11-04 23:11:39 +0100)
----------------------------------------------------------------
RTC for 4.9 #2
Drivers:
- asm9260: fix module autoload
- cmos: fix crashes
- omap: fix clock handling
----------------------------------------------------------------
Javier Martinez Canillas (1):
rtc: asm9260: fix module autoload
LABBE Corentin (1):
rtc: cmos: remove all __exit_p annotations
Lokesh Vutla (1):
rtc: omap: Fix selecting external osc
Tero Kristo (1):
rtc: omap: prevent disabling of clock/module during suspend
Ville Syrjälä (1):
rtc: cmos: Don't enable interrupts in the middle of the interrupt handler
drivers/rtc/rtc-asm9260.c | 1 +
drivers/rtc/rtc-cmos.c | 15 ++++++++-------
drivers/rtc/rtc-omap.c | 38 ++++++++++++++++++++++++++++++--------
3 files changed, 39 insertions(+), 15 deletions(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
You received this message because you are subscribed to "rtc-linux".
Membership options at http://groups.google.com/group/rtc-linux .
Please read http://groups.google.com/group/rtc-linux/web/checklist
before submitting a driver.
---
You received this message because you are subscribed to the Google Groups "rtc-linux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Possible to prevent dom0 accessing guest memory?
From: Andy Smith @ 2016-11-14 20:35 UTC (permalink / raw)
To: xen-devel
In-Reply-To: <CAFLBxZY-pBVGYYTUxnyerf3kjh09UZuUG5C3uhbbTZRxk5Cajg@mail.gmail.com>
Hi George,
On Mon, Nov 14, 2016 at 05:09:01PM +0000, George Dunlap wrote:
> There is probably a way to configure Xen to make it possible to build
> domains while making a full dump-core difficult to implement even by a
> motivated attacker; but that would be quite a bit more work (and very
> bespoke to your own particular situation).
I think if it could be made extremely difficult for a compromised
dom0 to dump guest memory then that would be useful to a wide range
of Xen users, as compromise of general purpose Linux hosts (like
most people's dom0s) is pretty commonplace.
Though I was reminded off-list (thanks for that), that Intel SGX and
AMD SME include features which can protect guest memory from other
guests/host/dom0, so perhaps that is a more sensible direction to go
in.
Thanks,
Andy
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH v3] mm, thp: propagation of conditional compilation in khugepaged.c
From: Jérémy Lefaure @ 2016-11-14 20:34 UTC (permalink / raw)
To: Andrew Morton, Kirill A. Shutemov; +Cc: linux-mm, Jérémy Lefaure
Commit b46e756f5e47 ("thp: extract khugepaged from mm/huge_memory.c")
moved code from huge_memory.c to khugepaged.c. Some of this code should
be compiled only when CONFIG_SYSFS is enabled but the condition around
this code was not moved into khugepaged.c. The result is a compilation
error when CONFIG_SYSFS is disabled:
mm/built-in.o: In function `khugepaged_defrag_store':
khugepaged.c:(.text+0x2d095): undefined reference to
`single_hugepage_flag_store'
mm/built-in.o: In function `khugepaged_defrag_show':
khugepaged.c:(.text+0x2d0ab): undefined reference to
`single_hugepage_flag_show'
This commit adds the #ifdef CONFIG_SYSFS around the code related to
sysfs.
Signed-off-by: JA(C)rA(C)my Lefaure <jeremy.lefaure@lse.epita.fr>
---
Sorry for the typo in v2. Thank you Kirill.
I hope that everything is ok this time.
mm/khugepaged.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index 728d779..87e1a7ca 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -103,6 +103,7 @@ static struct khugepaged_scan khugepaged_scan = {
.mm_head = LIST_HEAD_INIT(khugepaged_scan.mm_head),
};
+#ifdef CONFIG_SYSFS
static ssize_t scan_sleep_millisecs_show(struct kobject *kobj,
struct kobj_attribute *attr,
char *buf)
@@ -295,6 +296,7 @@ struct attribute_group khugepaged_attr_group = {
.attrs = khugepaged_attr,
.name = "khugepaged",
};
+#endif /* CONFIG_SYSFS */
#define VM_NO_KHUGEPAGED (VM_SPECIAL | VM_HUGETLB)
--
2.10.2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply related
* [Buildroot] [git commit] config: bump linux kernel to 4.8.6 in synopsys defconfigs
From: Thomas Petazzoni @ 2016-11-14 20:34 UTC (permalink / raw)
To: buildroot
commit: https://git.buildroot.net/buildroot/commit/?id=dab808e6ae634e08040a96bd06ea4910fed93633
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master
With this commit we update ARC defconfigs with the following:
- "snps_axs101_defconfig", "snps_axs103_defconfig" and
"snps_hs38_smp_vdk_defconfig":
- bump linux kernel version to 4.8.6
- set up host linux headers to 4.8
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
[Thomas: as reported by Alexey, this commit is in fact a bug fix: it
makes the defconfig work properly. Indeed, since the ARC compiler has
moved to gcc 6.x, the ABI has changed, and a Linux 4.8+ kernel is
needed for userspace to work on ARC.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
configs/snps_axs101_defconfig | 6 +++---
configs/snps_axs103_defconfig | 6 +++---
configs/snps_hs38_smp_vdk_defconfig | 6 +++---
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/configs/snps_axs101_defconfig b/configs/snps_axs101_defconfig
index f272853..eea7a50 100644
--- a/configs/snps_axs101_defconfig
+++ b/configs/snps_axs101_defconfig
@@ -8,13 +8,13 @@ BR2_TARGET_ROOTFS_INITRAMFS=y
BR2_SYSTEM_DHCP="eth0"
BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay"
-# Linux headers same as kernel, a 4.7 series
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y
+# Linux headers same as kernel, a 4.8 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_8=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.7"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.8.6"
BR2_LINUX_KERNEL_DEFCONFIG="axs101"
# Bootloader
diff --git a/configs/snps_axs103_defconfig b/configs/snps_axs103_defconfig
index 75596c9..08c55de 100644
--- a/configs/snps_axs103_defconfig
+++ b/configs/snps_axs103_defconfig
@@ -9,13 +9,13 @@ BR2_TARGET_ROOTFS_INITRAMFS=y
BR2_SYSTEM_DHCP="eth0"
BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay"
-# Linux headers same as kernel, a 4.7 series
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y
+# Linux headers same as kernel, a 4.8 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_8=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.7"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.8.6"
BR2_LINUX_KERNEL_DEFCONFIG="axs103_smp"
# Bootloader
diff --git a/configs/snps_hs38_smp_vdk_defconfig b/configs/snps_hs38_smp_vdk_defconfig
index 32922f8..d4dcd1b 100644
--- a/configs/snps_hs38_smp_vdk_defconfig
+++ b/configs/snps_hs38_smp_vdk_defconfig
@@ -8,12 +8,12 @@ BR2_TARGET_GENERIC_ISSUE="Welcome to the HS38 VDK Software Development Platform"
BR2_ROOTFS_OVERLAY="board/synopsys/axs10x/fs-overlay"
BR2_TARGET_ROOTFS_EXT2=y
-# Linux headers same as kernel, a 4.7 series
-BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_7=y
+# Linux headers same as kernel, a 4.8 series
+BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_8=y
# Kernel
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.7"
+BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.8.6"
BR2_LINUX_KERNEL_DEFCONFIG="vdk_hs38_smp"
BR2_LINUX_KERNEL_VMLINUX=y
^ permalink raw reply related
* Re: [PATCH kvm-unit-tests v2 08/17] pci: provide pci_scan_bars()
From: Peter Xu @ 2016-11-14 20:33 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, rkrcmar, agordeev, jan.kiszka, pbonzini
In-Reply-To: <20161110192419.ex77s7inrmejmt7r@hawk.localdomain>
On Thu, Nov 10, 2016 at 08:24:19PM +0100, Andrew Jones wrote:
[...]
> > +void pci_scan_bars(struct pci_dev *dev)
> > +{
> > + int i = 0;
> > +
> > + for (i = 0; i < PCI_BAR_NUM; i++) {
> > + if (!pci_bar_is_valid(dev, i))
> > + continue;
> > + dev->bar[i] = pci_bar_get_addr(dev, i);
>
> What happens when you get_addr a 64-bit bar in the middle?
> Shouldn't we skip that?
Hmm yes... Do you like this?
---------8<----------
diff --git a/lib/pci.c b/lib/pci.c
index 0593699..2a58b30 100644
--- a/lib/pci.c
+++ b/lib/pci.c
@@ -230,11 +230,15 @@ void pci_print(void)
void pci_scan_bars(struct pci_dev *dev)
{
- int i = 0;
+ int i;
+
+ memset(&dev->bar[0], 0, sizeof(dev->bar));
for (i = 0; i < PCI_BAR_NUM; i++) {
if (!pci_bar_is_valid(dev, i))
continue;
dev->bar[i] = pci_bar_get_addr(dev, i);
+ if (pci_bar_is64(dev, i))
+ i++;
}
}
--------->8----------
pci_bar_is64() is called twice per bar, but I think it's okay here
since it's during init and the whole scan is called only once for 6
bars.
Thanks,
-- peterx
^ permalink raw reply related
* Re: [kernel-hardening] Re: [RFC v4 PATCH 00/13] HARDENED_ATOMIC
From: Kees Cook @ 2016-11-14 20:31 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Will Deacon, Greg KH, David Windsor,
kernel-hardening@lists.openwall.com, Elena Reshetova,
Arnd Bergmann, Thomas Gleixner, Ingo Molnar, H. Peter Anvin
In-Reply-To: <20161111201704.GQ3117@twins.programming.kicks-ass.net>
On Fri, Nov 11, 2016 at 12:17 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Fri, Nov 11, 2016 at 10:04:42AM -0800, Kees Cook wrote:
>
>> I'm totally open about how to get there, but things can't just be opt-in.
>
> There really is no alternative.
I realize you feel that way, but if we can find a way to squeeze
mistakes down to impossible or very small, that has a strong effect on
the future of avoiding exploitation of these kinds of things.
> refcount_t; should only have: inc, inc_not_zero, dec_and_test
Sounds good. Two questions remain:
- how to deal with existing refcounting atomic_t users that want _add and _sub?
- keeping this fast enough that it can be used even in very sensitive
places (net, fs, etc).
> stats_t; should only have: add,sub
Seems right, though why not inc/dec? And shouldn't it have a _read of some kind?
Keeping the implementation details of refcount_t and stats_t opaque to
the users should discourage misuse...
> atomic_t; has:
>
> {add,inc,sub,dec} + {and,or,xor,notand}
>
> {add,inc,sub,dec}_return * {,relaxed,release,acquire}
>
> (fetch_{add,inc,sub,dec} + {and,or,xor,notand}) * {,relaxed,release,acquire}
>
> {sub,add,inc,dec}_and_test
>
> {cmpxchg,xchg}
>
> add_unless,inc_not_zero,{inc,dec}_unless_negative,dec_if_positive
>
> That is so much more than either refcount_t or stats_t should have, and
> the whole wrap/nowrap thing only matters to part of the ops.
>
> Like said, atomic_cmpxchg_wrap() is utter crap, that's a function name
> that doesn't make sense, and you guys should have realized that the
> moment you typed it.
>
> Its fantasy to think you can 'implement' atomic_t with refcount_t or
> anything else. You're chasing unicorns.
So, here's another suggestion on how to avoid this being opt-in: we
change atomic_t's name along with adding refcount_t and stats_t. We
need some way to distinguish "true" atomic users from the refcount_t
and stats_t, without needing to hope we can educate future driver
writers. Then, after transition to refcount_t, stats_t, and
bikeshed_atomic_t, we can catch misuse by having a CONFIG that forces
new/remaining atomic_t into refcount_t (which will blow up the build
if a driver uses anything besides inc, inc_not_zero, dec_and_test,
etc).
Regardless, adding refcount_t and stats_t will already make the audit
work of finding misused atomic_t SO much better, so since this is a
precondition to any other crazier ideas, it looks like we can all
agree on doing those pieces first.
-Kees
--
Kees Cook
Nexus Security
^ permalink raw reply
* Help with LED subsystem maintainance
From: Pavel Machek @ 2016-11-14 20:31 UTC (permalink / raw)
To: j.anaszewski, jacek.anaszewski, linux-leds, kernel list
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]
Hi!
Would it make sense to list me as a co-maintainer for the LED
subsystem?
I'd leave patch collection / git tree maintenance to you, but I guess
I can help with design, locking, etc...
Thanks and best regards,
Pavel
Signed-off-by: Pavel Machek <pavel@ucw.cz>
diff --git a/MAINTAINERS b/MAINTAINERS
index 01bff8e..d2934e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6884,6 +6884,7 @@ F: drivers/scsi/53c700*
LED SUBSYSTEM
M: Richard Purdie <rpurdie@rpsys.net>
M: Jacek Anaszewski <j.anaszewski@samsung.com>
+M: Pavel Machek <pavel@ucw.cz>
L: linux-leds@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds.git
S: Maintained
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply related
* Re: [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible
From: Julien Grall @ 2016-11-14 20:30 UTC (permalink / raw)
To: Andrii Anisov, Stefano Stabellini; +Cc: Peng Fan, Peng Fan, wei.liu2, xen-devel
In-Reply-To: <CAC1WxdiM51AVzkSuqQW92WFw=cDCRm2AzQQjyNSddxnPaEqMpg@mail.gmail.com>
Hi Andrii,
On 14/11/2016 03:11, Andrii Anisov wrote:
>> There are many reasons: for example because you want Dom0 to be Linux
>> and the storage driver domain to be FreeBSD. Or because you want the
>> network driver domain to be QNX.
> What we estimate now is a thin Dom0 without any drivers running with
> ramdisk. All drivers would be moved to a special guest domain.
You may want to give a look what has been done on x86 with the
"Dedicated hardware domain".
Another solution, is rather than moving the devices in a separate
domain, you move the toolstack. The latter may cause less trouble on
platform without SMMU.
Regards,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] tracing: ignore FTRACE_FL_DISABLED while walking dyn_ftrace records
From: Alexei Starovoitov @ 2016-11-14 20:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: Alexei Starovoitov, Dave Jones, Martin KaFai Lau, linux-kernel,
kernel-team
In-Reply-To: <20161114142428.1091961b@gandalf.local.home>
On Mon, Nov 14, 2016 at 02:24:28PM -0500, Steven Rostedt wrote:
> On Mon, 7 Nov 2016 15:14:20 -0800
> Alexei Starovoitov <ast@fb.com> wrote:
>
> > ftrace_shutdown() checks for sanity of ftrace records
> > and if dyn_ftrace->flags is not zero, it will warn.
> > It can happen that 'flags' are set to FTRACE_FL_DISABLED at this point,
> > since some module was loaded, but before ftrace_module_enable()
> > cleared the flags for this module.
> >
> > In other words the module.c is doing:
> > ftrace_module_init(mod); // calls ftrace_update_code() that sets flags=FTRACE_FL_DISABLED
> > ... // here ftrace_shutdown() is called that warns, since
> > err = prepare_coming_module(mod); // didn't have a chance to clear FTRACE_FL_DISABLED
> >
> > Fix it by ignoring disabled records.
> > It's similar to what __ftrace_hash_rec_update() is already doing.
> >
>
> Alexei,
>
> Do you have a clear reproducer of this bug?
Nope. No reproducer. It's very rare. Only stack trace that I posted earlier.
Since it kills ftrace everything that depends on it later spews a ton
of other warnings. So it's an important fix.
^ permalink raw reply
* Re: How can OSD udev rules race with lvm at boot time ?
From: Ruben Kerkhof @ 2016-11-14 20:29 UTC (permalink / raw)
To: Loic Dachary; +Cc: Ceph Development
In-Reply-To: <29b296db-034b-f91d-b7fe-b3f3f86a1df1@dachary.org>
On Mon, Nov 14, 2016 at 11:26 AM, Loic Dachary <loic@dachary.org> wrote:
> Hi,
Hi Loic,
I really appreciate you looking into this. While as a workaround for
this issue I stopped using LVM on my Ceph nodes, I'd like to go back
to LVM eventually.
>
> It looks like OSD udev rules race with LVM at boot time. In a nutshell, if /var/lib/ceph is on a LVM volume different from /, udev may fire events trying to start OSDs before the LVM volume is mounted and fail. This problem has been reported a few times over the past months and I believe it is real.
Just thinking out loud, but does udev make any guarantees at all about
filesystems being available (and writable) when udev rules run?
> I don't think there is any safeguard preventing such a race and it makes sense to me that it can happen sometimes. I'd like to reproduce it reliably to assert this is the reason why it happens. And, more importantly, to figure out a fix and verify it works. So far all my attemps have failed: the OSD comes back up every time. The details about this issue are at http://tracker.ceph.com/issues/17889
>
> If someone has ideas about how to handle this, it would be most welcome :-)
I'm trying to follow how osds are activated since this has been a
mystery for me so far.
Please bear with my, but this is how I understand it works:
- the ceph udev rules call ceph-disk trigger when udev detects a
device / partition suitable for ceph based on GPT uuids.
- ceph-disk trigger restarts an instantiated service, let's say
ceph-disk@/dev/sda.service. (properly escaped). This is asynchronous.
- ceph-disk.service calls ceph-disk trigger --sync /dev/sda
- ceph-disk trigger --sync /dev/sda calls ceph-disk activate /dev/sda
Now the first thing ceph-disk/main.py does (always) is mkdir
/var/lib/ceph, and take a file lock on
/var/lib/ceph/tmp/ceph-disk.prepare.lock and
/var/lib/ceph/tmp/ceph-disk.activate.lock.
Unless I'm mistaken this doesn't actually seem to be needed in the
ceph-disk trigger case.
Then we could add a RequiresMountsFor=/var/lib/ceph to
ceph-disk.service and be done with it.
As for how to reproduce the issue, one thought that comes to mind is
if you're testing this in a vm, perhaps you could put and I/O cap on
the disks, and this will improve your change of invoking the race.
>
> Cheers
>
> --
> Loïc Dachary, Artisan Logiciel Libre
Kind regards,
Ruben Kerkhof
^ permalink raw reply
* [PATCH v2] tile: handle __ro_after_init like parisc does
From: Chris Metcalf @ 2016-11-14 20:29 UTC (permalink / raw)
To: Heiko Carstens, Kees Cook, Martin Schwidefsky, linux-kernel; +Cc: Chris Metcalf
In-Reply-To: <20161108071543.GA3528@osiris>
The tile architecture already marks RO_DATA as read-only in
the kernel, so grouping RO_AFTER_INIT_DATA with RO_DATA, as is
done by default, means the kernel faults in init when it tries
to write to RO_AFTER_INIT_DATA. For now, just arrange that
__ro_after_init is handled like __write_once, i.e. __read_mostly.
Signed-off-by: Chris Metcalf <cmetcalf@mellanox.com>
---
arch/tile/include/asm/cache.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/tile/include/asm/cache.h b/arch/tile/include/asm/cache.h
index 6160761d5f61..4810e48dbbbf 100644
--- a/arch/tile/include/asm/cache.h
+++ b/arch/tile/include/asm/cache.h
@@ -61,4 +61,7 @@
*/
#define __write_once __read_mostly
+/* __ro_after_init is the generic name for the tile arch __write_once. */
+#define __ro_after_init __read_mostly
+
#endif /* _ASM_TILE_CACHE_H */
--
2.7.2
^ permalink raw reply related
* Re: corrupt leaf, slot offset bad
From: Kai Krakow @ 2016-11-14 20:28 UTC (permalink / raw)
To: linux-btrfs
In-Reply-To: <20161011140949.GA5284@localhost.localdomain>
Am Tue, 11 Oct 2016 07:09:49 -0700
schrieb Liu Bo <bo.li.liu@oracle.com>:
> On Tue, Oct 11, 2016 at 02:48:09PM +0200, David Sterba wrote:
> > Hi,
> >
> > looks like a lot of random bitflips.
> >
> > On Mon, Oct 10, 2016 at 11:50:14PM +0200, aron@aron.ws wrote:
> > > item 109 has a few strange chars in its name (and it's
> > > truncated): 1-x86_64.pkg.tar.xz 0x62 0x14 0x0a 0x0a
> > >
> > > item 105 key (261 DIR_ITEM 54556048) itemoff 11723
> > > itemsize 72 location key (606286 INODE_ITEM 0) type FILE
> > > namelen 42 datalen 0 name:
> > > python2-gobject-3.20.1-1-x86_64.pkg.tar.xz item 106 key (261
> > > DIR_ITEM 56363628) itemoff 11660 itemsize 63 location key (894298
> > > INODE_ITEM 0) type FILE namelen 33 datalen 0 name:
> > > unrar-1:5.4.5-1-x86_64.pkg.tar.xz item 107 key (261 DIR_ITEM
> > > 66963651) itemoff 11600 itemsize 60 location key (1178 INODE_ITEM
> > > 0) type FILE namelen 30 datalen 0 name:
> > > glibc-2.23-5-x86_64.pkg.tar.xz item 108 key (261 DIR_ITEM
> > > 68561395) itemoff 11532 itemsize 68 location key (660578
> > > INODE_ITEM 0) type FILE namelen 38 datalen 0 name:
> > > squashfs-tools-4.3-4-x86_64.pkg.tar.xz item 109 key (261 DIR_ITEM
> > > 76859450) itemoff 11483 itemsize 65 location key (2397184
> > > UNKNOWN.0 7091317839824617472) type 45 namelen 13102 datalen
> > > 13358 name: 1-x86_64.pkg.tar.xzb\x14
> >
> > namelen must be smaller than 255, but the number itself does not
> > look like a bitflip (0x332e), the name looks like a fragment of.
> >
> > The location key is random garbage, likely an overwritten memory,
> > 7091317839824617472 == 0x62696c0100230000 contains ascii 'bil', the
> > key type is unknown but should be INODE_ITEM.
> >
> > > data
> > > item 110 key (261 DIR_ITEM 9799832789237604651) itemoff
> > > 11405 itemsize 62
> > > location key (388547 INODE_ITEM 0) type FILE
> > > namelen 32 datalen 0 name:
> > > intltool-0.51.0-1-any.pkg.tar.xz item 111 key (261 DIR_ITEM
> > > 81211850) itemoff 11344 itemsize 131133
> >
> > itemsize 131133 == 0x2003d is a clear bitflip, 0x3d == 61,
> > corresponds to the expected item size.
> >
> > There's possibly other random bitflips in the keys or other
> > structures. It's hard to estimate the damage and thus the scope of
> > restorable data.
>
> It makes sense since this's a ssd we may have only one copy for
> metadata.
>
> Thanks,
>
> -liubo
>From this point of view it doesn't make sense to store only one copy of
meta data on SSD... The bit flip probably happened in RAM when taking
the other garbage into account, so dup meta data could have helped here.
If the SSD firmware would collapse duplicate meta data into single
blobs, that's perfectly fine. If the dup meta data arrives with bits
flipped, it won't be deduplicated. So this is fine, too.
BTW: I cannot believe that SSD firmwares really do the quite expensive
job of deduplication other than maybe internal compression. Maybe there
are some drives out there but most won't deduplicate. It's just too
little gain for too much complexity. So I personally would always
switch on duplicate meta data even for SSD. It shouldn't add to wear
leveling too much if you do the usual SSD optimization anyways (like
noatime).
PS: I suggest doing an extensive memtest86 before trying any repairs on
this system... Are you probably mixing different model DIMMs in dual
channel slots? Most of the times I've seen bitflips, this was the
culprit...
--
Regards,
Kai
Replies to list-only preferred.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.