Re: [PATCH] input: Use platform-provided devices as i8042 serio parents
On Fri, 2014-03-07 at 09:54 -0800, Dmitry Torokhov wrote: > Hi Matthew, > > On Sun, Feb 23, 2014 at 12:03:16PM -0500, Matthew Garrett wrote: > > i8042 devices exposed via platform firmware interfaces such as ACPI or > > Device Tree may provide additional information of use to userspace. Right > > now we don't associate the serio devices with the firmware device, and so > > there's no straightforward way for userspace to make use of that > > information. This patch simply moves the serio parent device to the firmware > > provided device. > > Hmm, are we sure it will not mess up power management now that children > serio ports are disconnected from i8042 device? Urh. Yeah, that's a point - we probably no longer guarantee that the i8042 resume code runs before any driver resume code. That's inconvenient. We could probably add resume callbacks to the PNP devices, but then we need to ensure that they only run once. I think we can do that without too much trouble, but it's not going to be beautiful. -- Matthew Garrett
[PATCH RFC v2 08/11] tty: xuartps: Rename Kconfig symbols
Rename the config symbols for the Cadence UART to reflect the driver
rebranding:
SERIAL_XILINX_PS_UART(_CONSOLE) -> SERIAL_CADENCE_UART(_CONSOLE)
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/Kconfig | 6 +++---
drivers/tty/serial/Makefile| 2 +-
drivers/tty/serial/xilinx_uartps.c | 8
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 1294284342bc..8c340dbf9e53 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1367,7 +1367,7 @@ config SERIAL_MXS_AUART_CONSOLE
help
Enable a MXS AUART port to be the system console.
-config SERIAL_XILINX_PS_UART
+config SERIAL_CADENCE_UART
tristate "Cadence (Xilinx Zynq) UART support"
depends on OF
select SERIAL_CORE
@@ -1375,9 +1375,9 @@ config SERIAL_XILINX_PS_UART
This driver supports the Cadence UART. It is found e.g. in Xilinx
Zynq.
-config SERIAL_XILINX_PS_UART_CONSOLE
+config SERIAL_CADENCE_UART_CONSOLE
bool "Cadence UART console support"
- depends on SERIAL_XILINX_PS_UART=y
+ depends on SERIAL_CADENCE_UART=y
select SERIAL_CORE_CONSOLE
help
Enable a Cadence UART port to be the system console.
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 3680854fef41..4b57523a34c7 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -79,7 +79,7 @@ obj-$(CONFIG_SERIAL_PCH_UART) += pch_uart.o
obj-$(CONFIG_SERIAL_MSM_SMD) += msm_smd_tty.o
obj-$(CONFIG_SERIAL_MXS_AUART) += mxs-auart.o
obj-$(CONFIG_SERIAL_LANTIQ)+= lantiq.o
-obj-$(CONFIG_SERIAL_XILINX_PS_UART) += xilinx_uartps.o
+obj-$(CONFIG_SERIAL_CADENCE_UART) += xilinx_uartps.o
obj-$(CONFIG_SERIAL_SIRFSOC) += sirfsoc_uart.o
obj-$(CONFIG_SERIAL_TEGRA) += serial-tegra.o
obj-$(CONFIG_SERIAL_AR933X) += ar933x_uart.o
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index 0b27efef1cb6..7bfd19a7273d 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -13,7 +13,7 @@
* still shows in the file name, function/symbol name prefixes.
*/
-#if defined(CONFIG_SERIAL_XILINX_PS_UART_CONSOLE) &&
defined(CONFIG_MAGIC_SYSRQ)
+#if defined(CONFIG_SERIAL_CADENCE_UART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ)
#define SUPPORT_SYSRQ
#endif
@@ -1030,7 +1030,7 @@ static struct uart_port *cdns_uart_get_port(void)
return port;
}
-#ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE
+#ifdef CONFIG_SERIAL_CADENCE_UART_CONSOLE
/**
* cdns_uart_console_wait_tx - Wait for the TX to be full
* @port: Handle to the uart port structure
@@ -1150,7 +1150,7 @@ static int __init cdns_uart_console_init(void)
console_initcall(cdns_uart_console_init);
-#endif /* CONFIG_SERIAL_XILINX_PS_UART_CONSOLE */
+#endif /* CONFIG_SERIAL_CADENCE_UART_CONSOLE */
static struct uart_driver cdns_uart_uart_driver = {
.owner = THIS_MODULE,
@@ -1159,7 +1159,7 @@ static struct uart_driver cdns_uart_uart_driver = {
.major = CDNS_UART_MAJOR,
.minor = CDNS_UART_MINOR,
.nr = CDNS_UART_NR_PORTS,
-#ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE
+#ifdef CONFIG_SERIAL_CADENCE_UART_CONSOLE
.cons = _uart_console,
#endif
};
--
1.9.0.1.g4196000
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 01/11] tty: xuartps: Clean up
This is all white space and comment clean up. Mostly reformatting comments. Signed-off-by: Soren Brinkmann --- drivers/tty/serial/xilinx_uartps.c | 294 ++--- 1 file changed, 111 insertions(+), 183 deletions(-) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index f619ad5b5eae..1c6e1a68ae95 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -1,14 +1,13 @@ /* * Xilinx PS UART driver * - * 2011 - 2013 (C) Xilinx Inc. + * 2011 - 2014 (C) Xilinx Inc. * * This program is free software; you can redistribute it * and/or modify it under the terms of the GNU General Public * License as published by the Free Software Foundation; * either version 2 of the License, or (at your option) any * later version. - * */ #if defined(CONFIG_SERIAL_XILINX_PS_UART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) @@ -49,39 +48,27 @@ static int rx_timeout = 10; module_param(rx_timeout, uint, S_IRUGO); MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255"); -/Register Map/ -/** UART - * - * Register offsets for the UART. - * - */ -#define XUARTPS_CR_OFFSET 0x00 /* Control Register [8:0] */ -#define XUARTPS_MR_OFFSET 0x04 /* Mode Register [10:0] */ -#define XUARTPS_IER_OFFSET 0x08 /* Interrupt Enable [10:0] */ -#define XUARTPS_IDR_OFFSET 0x0C /* Interrupt Disable [10:0] */ -#define XUARTPS_IMR_OFFSET 0x10 /* Interrupt Mask [10:0] */ -#define XUARTPS_ISR_OFFSET 0x14 /* Interrupt Status [10:0]*/ -#define XUARTPS_BAUDGEN_OFFSET 0x18 /* Baud Rate Generator [15:0] */ -#define XUARTPS_RXTOUT_OFFSET 0x1C /* RX Timeout [7:0] */ -#define XUARTPS_RXWM_OFFSET0x20 /* RX FIFO Trigger Level [5:0] */ -#define XUARTPS_MODEMCR_OFFSET 0x24 /* Modem Control [5:0] */ -#define XUARTPS_MODEMSR_OFFSET 0x28 /* Modem Status [8:0] */ -#define XUARTPS_SR_OFFSET 0x2C /* Channel Status [11:0] */ -#define XUARTPS_FIFO_OFFSET0x30 /* FIFO [15:0] or [7:0] */ -#define XUARTPS_BAUDDIV_OFFSET 0x34 /* Baud Rate Divider [7:0] */ -#define XUARTPS_FLOWDEL_OFFSET 0x38 /* Flow Delay [15:0] */ -#define XUARTPS_IRRX_PWIDTH_OFFSET 0x3C /* IR Minimum Received Pulse - Width [15:0] */ -#define XUARTPS_IRTX_PWIDTH_OFFSET 0x40 /* IR Transmitted pulse - Width [7:0] */ -#define XUARTPS_TXWM_OFFSET0x44 /* TX FIFO Trigger Level [5:0] */ - -/** Control Register - * - * The Control register (CR) controls the major functions of the device. - * - * Control Register Bit Definitions - */ +/* Register offsets for the UART. */ +#define XUARTPS_CR_OFFSET 0x00 /* Control Register */ +#define XUARTPS_MR_OFFSET 0x04 /* Mode Register */ +#define XUARTPS_IER_OFFSET 0x08 /* Interrupt Enable */ +#define XUARTPS_IDR_OFFSET 0x0C /* Interrupt Disable */ +#define XUARTPS_IMR_OFFSET 0x10 /* Interrupt Mask */ +#define XUARTPS_ISR_OFFSET 0x14 /* Interrupt Status */ +#define XUARTPS_BAUDGEN_OFFSET 0x18 /* Baud Rate Generator */ +#define XUARTPS_RXTOUT_OFFSET 0x1C /* RX Timeout */ +#define XUARTPS_RXWM_OFFSET0x20 /* RX FIFO Trigger Level */ +#define XUARTPS_MODEMCR_OFFSET 0x24 /* Modem Control */ +#define XUARTPS_MODEMSR_OFFSET 0x28 /* Modem Status */ +#define XUARTPS_SR_OFFSET 0x2C /* Channel Status */ +#define XUARTPS_FIFO_OFFSET0x30 /* FIFO */ +#define XUARTPS_BAUDDIV_OFFSET 0x34 /* Baud Rate Divider */ +#define XUARTPS_FLOWDEL_OFFSET 0x38 /* Flow Delay */ +#define XUARTPS_IRRX_PWIDTH_OFFSET 0x3C /* IR Minimum Received Pulse Width */ +#define XUARTPS_IRTX_PWIDTH_OFFSET 0x40 /* IR Transmitted pulse Width */ +#define XUARTPS_TXWM_OFFSET0x44 /* TX FIFO Trigger Level */ + +/* Control Register Bit Definitions */ #define XUARTPS_CR_STOPBRK 0x0100 /* Stop TX break */ #define XUARTPS_CR_STARTBRK0x0080 /* Set TX break */ #define XUARTPS_CR_TX_DIS 0x0020 /* TX disabled. */ @@ -92,14 +79,11 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255"); #define XUARTPS_CR_RXRST 0x0001 /* RX logic reset */ #define XUARTPS_CR_RST_TO 0x0040 /* Restart Timeout Counter */ -/** Mode Register - * +/* + * Mode Register: * The mode register (MR) defines the mode of transfer as well as the data * format. If this register is modified during transmission or reception, * data validity cannot be guaranteed. - * - * Mode Register Bit Definitions - * */ #define XUARTPS_MR_CLKSEL 0x0001 /* Pre-scalar selection */ #define XUARTPS_MR_CHMODE_L_LOOP 0x0200 /* Local loop back mode */ @@ -118,8 +102,8 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255"); #define XUARTPS_MR_CHARLEN_7_BIT 0x0004 /* 7 bits data */ #define XUARTPS_MR_CHARLEN_8_BIT 0x /* 8 bits data */ -/** Interrupt Registers - * +/* + * Interrupt Registers: *
[PATCH RFC v2 03/11] tty: xuartps: Refactor read-modify-writes
A lot of read-modify-write sequences used a one-line statement which nests a readl() within a writel(). Convert this into code sequences that make the three steps more obvious. Signed-off-by: Soren Brinkmann --- drivers/tty/serial/xilinx_uartps.c | 52 ++ 1 file changed, 24 insertions(+), 28 deletions(-) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index b00060052316..a4bd6242e72d 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -437,9 +437,9 @@ static int xuartps_clk_notifier_cb(struct notifier_block *nb, spin_lock_irqsave(>port->lock, flags); /* Disable the TX and RX to set baud rate */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); spin_unlock_irqrestore(>port->lock, flags); @@ -464,9 +464,9 @@ static int xuartps_clk_notifier_cb(struct notifier_block *nb, spin_lock_irqsave(>port->lock, flags); /* Set TX/RX Reset */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TXRST | XUARTPS_CR_RXRST; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); while (xuartps_readl(XUARTPS_CR_OFFSET) & (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST)) @@ -479,10 +479,9 @@ static int xuartps_clk_notifier_cb(struct notifier_block *nb, */ xuartps_writel(rx_timeout, XUARTPS_RXTOUT_OFFSET); ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); - xuartps_writel( - (ctrl_reg & ~(XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS)) | - (XUARTPS_CR_TX_EN | XUARTPS_CR_RX_EN), - XUARTPS_CR_OFFSET); + ctrl_reg &= ~(XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS); + ctrl_reg |= XUARTPS_CR_TX_EN | XUARTPS_CR_RX_EN; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); spin_unlock_irqrestore(>port->lock, flags); @@ -631,9 +630,9 @@ static void xuartps_set_termios(struct uart_port *port, } /* Disable the TX and RX to set baud rate */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); /* * Min baud rate = 6bps and Max Baud Rate is 10Mbps for 100Mhz clk @@ -651,20 +650,18 @@ static void xuartps_set_termios(struct uart_port *port, uart_update_timeout(port, termios->c_cflag, baud); /* Set TX/RX Reset */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST), - XUARTPS_CR_OFFSET); - ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TXRST | XUARTPS_CR_RXRST; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); /* * Clear the RX disable and TX disable bits and then set the TX enable * bit and RX enable bit to enable the transmitter and receiver. */ - xuartps_writel( - (ctrl_reg & ~(XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS)) - | (XUARTPS_CR_TX_EN | XUARTPS_CR_RX_EN), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg &= ~(XUARTPS_CR_TX_DIS | XUARTPS_CR_RX_DIS); + ctrl_reg |= XUARTPS_CR_TX_EN | XUARTPS_CR_RX_EN; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); xuartps_writel(rx_timeout, XUARTPS_RXTOUT_OFFSET); @@ -1245,9 +1242,9 @@ static int xuartps_resume(struct device *device) spin_lock_irqsave(>lock, flags); /* Set TX/RX Reset */ - xuartps_writel(xuartps_readl(XUARTPS_CR_OFFSET) | - (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST), - XUARTPS_CR_OFFSET); + ctrl_reg = xuartps_readl(XUARTPS_CR_OFFSET); + ctrl_reg |= XUARTPS_CR_TXRST | XUARTPS_CR_RXRST; + xuartps_writel(ctrl_reg, XUARTPS_CR_OFFSET); while (xuartps_readl(XUARTPS_CR_OFFSET) & (XUARTPS_CR_TXRST | XUARTPS_CR_RXRST))
[PATCH RFC v2 04/11] tty: xuartps: Remove bogus comment and register write
Signed-off-by: Soren Brinkmann --- drivers/tty/serial/xilinx_uartps.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index a4bd6242e72d..a39c2d290902 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -1082,11 +1082,7 @@ static void xuartps_console_write(struct console *co, const char *s, xuartps_writel(ctrl, XUARTPS_CR_OFFSET); - /* restore interrupt state, it seems like there may be a h/w bug -* in that the interrupt enable register should not need to be -* written based on the data sheet -*/ - xuartps_writel(~imr, XUARTPS_IDR_OFFSET); + /* restore interrupt state */ xuartps_writel(imr, XUARTPS_IER_OFFSET); if (locked) -- 1.9.0.1.g4196000 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 06/11] tty: xuartps: Change driver name to 'cdns-uart'
Signed-off-by: Soren Brinkmann --- I'm not sure about this change. Is this acceptable or already too much? I think the name is used for some sysfs entries. Sören --- drivers/tty/serial/xilinx_uartps.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index b4a2a68b5e0e..3be1da41c2a8 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -31,7 +31,7 @@ #include #define XUARTPS_TTY_NAME "ttyPS" -#define XUARTPS_NAME "xuartps" +#define XUARTPS_NAME "cdns-uart" #define XUARTPS_MAJOR 0 /* use dynamic node allocation */ #define XUARTPS_MINOR 0 /* works best with devtmpfs */ #define XUARTPS_NR_PORTS 2 -- 1.9.0.1.g4196000 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 11/11] ARM: zynq: DT: Migrate UART to Cadence binding
The Zynq UART is Cadence IP and the driver has been renamed accordingly.
Migrate the DT to use the new binding for the UART driver.
Signed-off-by: Soren Brinkmann
Acked-by: Peter Crosthwaite
---
arch/arm/boot/dts/zynq-7000.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index 8b67b19392ec..0ed0d4b0579a 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -67,19 +67,19 @@
};
uart0: uart@e000 {
- compatible = "xlnx,xuartps";
+ compatible = "xlnx,xuartps", "cdns,uart-r1p8";
status = "disabled";
clocks = < 23>, < 40>;
- clock-names = "ref_clk", "aper_clk";
+ clock-names = "uart_clk", "pclk";
reg = <0xE000 0x1000>;
interrupts = <0 27 4>;
};
uart1: uart@e0001000 {
- compatible = "xlnx,xuartps";
+ compatible = "xlnx,xuartps", "cdns,uart-r1p8";
status = "disabled";
clocks = < 24>, < 41>;
- clock-names = "ref_clk", "aper_clk";
+ clock-names = "uart_clk", "pclk";
reg = <0xE0001000 0x1000>;
interrupts = <0 50 4>;
};
--
1.9.0.1.g4196000
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 10/11] tty: cadence: Document DT binding
Add binding documentation for the Cadence UART.
Signed-off-by: Soren Brinkmann
Acked-by: Peter Crosthwaite
---
.../devicetree/bindings/serial/cdns,uart.txt | 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/serial/cdns,uart.txt
diff --git a/Documentation/devicetree/bindings/serial/cdns,uart.txt
b/Documentation/devicetree/bindings/serial/cdns,uart.txt
new file mode 100644
index ..a3eb154c32ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/cdns,uart.txt
@@ -0,0 +1,20 @@
+Binding for Cadence UART Controller
+
+Required properties:
+- compatible : should be "cdns,uart-r1p8", or "xlnx,xuartps"
+- reg: Should contain UART controller registers location and length.
+- interrupts: Should contain UART controller interrupts.
+- clocks: Must contain phandles to the UART clocks
+ See ../clocks/clock-bindings.txt for details.
+- clock-names: Tuple to identify input clocks, must contain "uart_clk" and
"pclk"
+ See ../clocks/clock-bindings.txt for details.
+
+
+Example:
+ uart@e000 {
+ compatible = "cdns,uart-r1p8";
+ clocks = < 23>, < 40>;
+ clock-names = "uart_clk", "pclk";
+ reg = <0xE000 0x1000>;
+ interrupts = <0 27 4>;
+ };
--
1.9.0.1.g4196000
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 02/11] tty: xuartps: Print warning in clock notifier
Print a warning if the clock notifier rejects a clock frequency change
to facilitate debugging (see:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/304329/focus=304379)
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/xilinx_uartps.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index 1c6e1a68ae95..b00060052316 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -429,8 +429,10 @@ static int xuartps_clk_notifier_cb(struct notifier_block
*nb,
* frequency.
*/
if (!xuartps_calc_baud_divs(ndata->new_rate, xuartps->baud,
- , , ))
+ , , )) {
+ dev_warn(port->dev, "clock rate change rejected\n");
return NOTIFY_BAD;
+ }
spin_lock_irqsave(>port->lock, flags);
--
1.9.0.1.g4196000
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 09/11] ARM: multi_v7_defconfig: Adopt to UART driver renaming
The Xilinx UARTPS driver has been renamed to Cadence UART. Remove the stale Xilinx UARTPS config options and add Cadence UART instead. Signed-off-by: Soren Brinkmann Acked-by: Peter Crosthwaite --- arch/arm/configs/multi_v7_defconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index ee6982976d66..4054c97a97e8 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -151,8 +151,8 @@ CONFIG_SERIAL_VT8500_CONSOLE=y CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_OMAP=y CONFIG_SERIAL_OMAP_CONSOLE=y -CONFIG_SERIAL_XILINX_PS_UART=y -CONFIG_SERIAL_XILINX_PS_UART_CONSOLE=y +CONFIG_SERIAL_CADENCE_UART=y +CONFIG_SERIAL_CADENCE_UART_CONSOLE=y CONFIG_SERIAL_FSL_LPUART=y CONFIG_SERIAL_FSL_LPUART_CONSOLE=y CONFIG_SERIAL_ST_ASC=y -- 1.9.0.1.g4196000 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 00/11] tty: xuartps: Rebranding
A second iteration of this series. I added some more to the cleanup parts. The more you look at things the more things to fix you find. The read-modify-write refactoring is more or less a result of the prefix substitution. With the changed prefix for better indentation is necessary, and I think it makes the code more readably in general. The controversial part, the re-branding: I split this up into 4 separate patches, starting at 5/8. Each going a little further and I'd like to know which ones are wanted/okay and which rather not. And whether the wanted ones should be squashed. The first one is pretty much the light-weight changes Alan suggested. The second changes the driver name. I don't know if that is acceptable. I think the name is used in some sysfs nodes. Does that make it part of the userspace API? And I don't know if the name might be used elsewhere? The third is mostly a search and replace of 'xuartps' with 'cdns-uart'. A noisy change but it should not impact anything else. I thought it might be nice to have more generic names since they show in stack traces and the xuartps thing may not be that meaningful on non-Zynq platforms - though there is non for this driver as of now. Similar the Kconfig symbol renaming. Probably not worth it, but might clarify things a bit. The defconfig update would - obviously - only needed if the Kconfig change is done. Which is probably another reason to not change the config symbol. In the documentation I added xlnx,xuartps as valid compatible string, but refrained from documenting the Zynq-specific clock names. The driver, though, allows them, but prints a warning. The DT update would silence the afore-mentioned warning by migrating to the new clock names. Thanks, Sören Soren Brinkmann (11): tty: xuartps: Clean up tty: xuartps: Print warning in clock notifier tty: xuartps: Refactor read-modify-writes tty: xuartps: Remove bogus comment and register write tty: xuartps: Rebrand driver as Cadence UART tty: xuartps: Change driver name to 'cdns-uart' tty: xuartps: Replace function and symbol prefix tty: xuartps: Rename Kconfig symbols ARM: multi_v7_defconfig: Adopt to UART driver renaming tty: cadence: Document DT binding ARM: zynq: DT: Migrate UART to Cadence binding .../devicetree/bindings/serial/cdns,uart.txt | 20 + arch/arm/boot/dts/zynq-7000.dtsi |8 +- arch/arm/configs/multi_v7_defconfig|4 +- drivers/tty/serial/Kconfig | 15 +- drivers/tty/serial/Makefile|2 +- drivers/tty/serial/xilinx_uartps.c | 1123 ++-- include/uapi/linux/serial_core.h |2 +- 7 files changed, 569 insertions(+), 605 deletions(-) create mode 100644 Documentation/devicetree/bindings/serial/cdns,uart.txt -- 1.9.0.1.g4196000 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC v2 05/11] tty: xuartps: Rebrand driver as Cadence UART
Zynq's UART is Cadence IP. Make this visible in the prompt in kconfig
and additional comments in the driver.
Signed-off-by: Soren Brinkmann
---
drivers/tty/serial/Kconfig | 9 +++--
drivers/tty/serial/xilinx_uartps.c | 77 +++---
include/uapi/linux/serial_core.h | 2 +-
3 files changed, 52 insertions(+), 36 deletions(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index a3815eaed421..1294284342bc 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1368,18 +1368,19 @@ config SERIAL_MXS_AUART_CONSOLE
Enable a MXS AUART port to be the system console.
config SERIAL_XILINX_PS_UART
- tristate "Xilinx PS UART support"
+ tristate "Cadence (Xilinx Zynq) UART support"
depends on OF
select SERIAL_CORE
help
- This driver supports the Xilinx PS UART port.
+ This driver supports the Cadence UART. It is found e.g. in Xilinx
+ Zynq.
config SERIAL_XILINX_PS_UART_CONSOLE
- bool "Xilinx PS UART console support"
+ bool "Cadence UART console support"
depends on SERIAL_XILINX_PS_UART=y
select SERIAL_CORE_CONSOLE
help
- Enable a Xilinx PS UART port to be the system console.
+ Enable a Cadence UART port to be the system console.
config SERIAL_AR933X
tristate "AR933X serial port support"
diff --git a/drivers/tty/serial/xilinx_uartps.c
b/drivers/tty/serial/xilinx_uartps.c
index a39c2d290902..b4a2a68b5e0e 100644
--- a/drivers/tty/serial/xilinx_uartps.c
+++ b/drivers/tty/serial/xilinx_uartps.c
@@ -1,5 +1,5 @@
/*
- * Xilinx PS UART driver
+ * Cadence UART driver (found in Xilinx Zynq)
*
* 2011 - 2014 (C) Xilinx Inc.
*
@@ -8,6 +8,9 @@
* License as published by the Free Software Foundation;
* either version 2 of the License, or (at your option) any
* later version.
+ *
+ * This driver has originally been pushed by Xilinx using a Zynq-branding. This
+ * still shows in the file name, function/symbol name prefixes.
*/
#if defined(CONFIG_SERIAL_XILINX_PS_UART_CONSOLE) &&
defined(CONFIG_MAGIC_SYSRQ)
@@ -147,15 +150,15 @@ MODULE_PARM_DESC(rx_timeout, "Rx timeout, 1-255");
/**
* struct xuartps - device data
* @port: Pointer to the UART port
- * @refclk:Reference clock
- * @aperclk: APB clock
+ * @uartclk: Reference clock
+ * @pclk: APB clock
* @baud: Current baud rate
* @clk_rate_change_nb:Notifier block for clock changes
*/
struct xuartps {
struct uart_port*port;
- struct clk *refclk;
- struct clk *aperclk;
+ struct clk *uartclk;
+ struct clk *pclk;
unsigned intbaud;
struct notifier_block clk_rate_change_nb;
};
@@ -1187,8 +1190,8 @@ static int xuartps_suspend(struct device *device)
if (console_suspend_enabled && !may_wake) {
struct xuartps *xuartps = port->private_data;
- clk_disable(xuartps->refclk);
- clk_disable(xuartps->aperclk);
+ clk_disable(xuartps->uartclk);
+ clk_disable(xuartps->pclk);
} else {
unsigned long flags = 0;
@@ -1232,8 +1235,8 @@ static int xuartps_resume(struct device *device)
if (console_suspend_enabled && !may_wake) {
struct xuartps *xuartps = port->private_data;
- clk_enable(xuartps->aperclk);
- clk_enable(xuartps->refclk);
+ clk_enable(xuartps->pclk);
+ clk_enable(xuartps->uartclk);
spin_lock_irqsave(>lock, flags);
@@ -1287,26 +1290,37 @@ static int xuartps_probe(struct platform_device *pdev)
if (!xuartps_data)
return -ENOMEM;
- xuartps_data->aperclk = devm_clk_get(>dev, "aper_clk");
- if (IS_ERR(xuartps_data->aperclk)) {
- dev_err(>dev, "aper_clk clock not found.\n");
- return PTR_ERR(xuartps_data->aperclk);
+ xuartps_data->pclk = devm_clk_get(>dev, "pclk");
+ if (IS_ERR(xuartps_data->pclk)) {
+ xuartps_data->pclk = devm_clk_get(>dev, "aper_clk");
+ if (!IS_ERR(xuartps_data->pclk))
+ dev_err(>dev, "clock name 'aper_clk' is
deprecated.\n");
+ }
+ if (IS_ERR(xuartps_data->pclk)) {
+ dev_err(>dev, "pclk clock not found.\n");
+ return PTR_ERR(xuartps_data->pclk);
+ }
+
+ xuartps_data->uartclk = devm_clk_get(>dev, "uart_clk");
+ if (IS_ERR(xuartps_data->uartclk)) {
+ xuartps_data->uartclk = devm_clk_get(>dev, "ref_clk");
+ if (!IS_ERR(xuartps_data->uartclk))
+ dev_err(>dev, "clock name 'ref_clk' is
deprecated.\n");
}
- xuartps_data->refclk = devm_clk_get(>dev, "ref_clk");
- if
Re: [RFC][PATCH 0/5] arch: atomic rework
On Fri, Mar 07, 2014 at 07:33:25PM +0100, Torvald Riegel wrote:
> On Wed, 2014-03-05 at 10:15 -0800, Paul E. McKenney wrote:
> > On Wed, Mar 05, 2014 at 05:54:59PM +0100, Torvald Riegel wrote:
> > > On Tue, 2014-03-04 at 13:35 -0800, Paul E. McKenney wrote:
> > > > On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote:
> > > > > On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
> > > > > > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
> > > > > > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
> > > > > >
> > > > > > On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
> > > > > > > On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote:
> > > > > > > > xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com
> > > > > > > > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC)
> > > > > > > >
> > > > > > > > On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote:
> > > > > > > > > +oDo not use the results from the boolean "&&" and "||"
> > > > > > > > > when
> > > > > > > > > + dereferencing. For example, the following (rather
> > > > > > > > > improbable)
> > > > > > > > > + code is buggy:
> > > > > > > > > +
> > > > > > > > > + int a[2];
> > > > > > > > > + int index;
> > > > > > > > > + int force_zero_index = 1;
> > > > > > > > > +
> > > > > > > > > + ...
> > > > > > > > > +
> > > > > > > > > + r1 = rcu_dereference(i1)
> > > > > > > > > + r2 = a[r1 && force_zero_index]; /* BUGGY!!! */
> > > > > > > > > +
> > > > > > > > > + The reason this is buggy is that "&&" and "||" are
> > > > > > > > > often compiled
> > > > > > > > > + using branches. While weak-memory machines such as ARM
> > > > > > > > > or PowerPC
> > > > > > > > > + do order stores after such branches, they can speculate
> > > > > > > > > loads,
> > > > > > > > > + which can result in misordering bugs.
> > > > > > > > > +
> > > > > > > > > +oDo not use the results from relational operators ("==",
> > > > > > > > > "!=",
> > > > > > > > > + ">", ">=", "<", or "<=") when dereferencing. For
> > > > > > > > > example,
> > > > > > > > > + the following (quite strange) code is buggy:
> > > > > > > > > +
> > > > > > > > > + int a[2];
> > > > > > > > > + int index;
> > > > > > > > > + int flip_index = 0;
> > > > > > > > > +
> > > > > > > > > + ...
> > > > > > > > > +
> > > > > > > > > + r1 = rcu_dereference(i1)
> > > > > > > > > + r2 = a[r1 != flip_index]; /* BUGGY!!! */
> > > > > > > > > +
> > > > > > > > > + As before, the reason this is buggy is that relational
> > > > > > > > > operators
> > > > > > > > > + are often compiled using branches. And as before,
> > > > > > > > > although
> > > > > > > > > + weak-memory machines such as ARM or PowerPC do order
> > > > > > > > > stores
> > > > > > > > > + after such branches, but can speculate loads, which can
> > > > > > > > > again
> > > > > > > > > + result in misordering bugs.
> > > > > > > >
> > > > > > > > Those two would be allowed by the wording I have recently
> > > > > > > > proposed,
> > > > > > > > AFAICS. r1 != flip_index would result in two possible values
> > > > > > > > (unless
> > > > > > > > there are further constraints due to the type of r1 and the
> > > > > > > > values that
> > > > > > > > flip_index can have).
> > > > > > >
> > > > > > > And I am OK with the value_dep_preserving type providing
> > > > > > > more/better
> > > > > > > guarantees than we get by default from current compilers.
> > > > > > >
> > > > > > > One question, though. Suppose that the code did not want a value
> > > > > > > dependency to be tracked through a comparison operator. What does
> > > > > > > the developer do in that case? (The reason I ask is that I have
> > > > > > > not yet found a use case in the Linux kernel that expects a value
> > > > > > > dependency to be tracked through a comparison.)
> > > > > >
> > > > > > Hmm. I suppose use an explicit cast to non-vdp before or after the
> > > > > > comparison?
> > > > >
> > > > > That should work well assuming that things like "if", "while", and
> > > > > "?:"
> > > > > conditions are happy to take a vdp. This assumes that p->a only
> > > > > returns
> > > > > vdp if field "a" is declared vdp, otherwise we have vdps running wild
> > > > > through the program. ;-)
> > > > >
> > > > > The other thing that can happen is that a vdp can get handed off to
> > > > > another synchronization mechanism, for example, to reference counting:
> > > > >
> > > > > p = atomic_load_explicit(, memory_order_consume);
> > > > > if (do_something_with(p->a)) {
> > > > > /* fast path protected by RCU. */
> > > > > return 0;
> > > > > }
> > > > > if (atomic_inc_not_zero(>refcnt) {
> > > > > /* slow path protected by
Re: [qemu64,+smep,+smap] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/cpu/amd.c:220 init_amd()
On Fri, Mar 07, 2014 at 10:56:11AM -0800, H. Peter Anvin wrote: > On 03/06/2014 09:50 PM, Fengguang Wu wrote: > >> > >> Unfortunately these things are hard to fix in Qemu. > > > > OK. As an alternative, is it possible to pass one of the below CPUID flags > > in > > the Qemu command line, so as to quiet the warning? > > > > I don't see the AMD SMP CPUID flag in there. > > Boris, could you help? The problem is that "qemu -cpu > qemu64,+smep,+smap" identifies as an AMD CPU which triggers a > warning/taint because the SMP flag isn't set. qemu64 triggers this ? That spew comes from amd_k7_smp_check() which should only run on family 6, which was all 32bit. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] module: LLVMLinux: Remove unused function warning from __param_check macro
From: Mark Charlebois
This code makes a compile time type check that is optimized away. Clang
complains that it generates an unused function.
I believe GCC won't complain for a static inline fuction but would if it
was just a static function.
Adding the unused attribute to the function declaration removes the warning.
This code works for both gcc and clang.
Signed-off-by: Mark Charlebois
Signed-off-by: Behan Webster
---
include/linux/moduleparam.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index c3eb102..5ce1f67 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -346,6 +346,7 @@ static inline void destroy_params(const struct kernel_param
*params,
/* The macros to do compile-time type checking stolen from Jakub
Jelinek, who IIRC came up with this idea for the 2.4 module init code. */
#define __param_check(name, p, type) \
+ static inline type *__check_##name(void) __attribute__ ((unused)); \
static inline type *__check_##name(void) { return(p); }
extern struct kernel_param_ops param_ops_byte;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [systemd-devel] Suspending access to opened/active /dev/nodes during application runtime
On Fri, Mar 07, 2014 at 07:46:44PM +0100, Lukasz Pawelczyk wrote: > Problem: > Has anyone thought about a mechanism to limit/remove an access to a > device during an application runtime? Meaning we have an application > that has an open file descriptor to some /dev/node and depending on > *something* it gains or looses the access to it gracefully (with or > without a notification, but without any fatal consequences). > > Example: > LXC. Imagine we have 2 separate containers. Both running full operating > systems. Specifically with 2 X servers. Both running concurrently of > course. Both need the same input devices (e.g. we have just one mouse). Stop right there. If they "both" need an input device, then they should use the "shared" input device stream, i.e. evdev. And it goes the same for every type of device the kernel is exposing to userspace, if you want to "share" them, then you need to work on changing the kernel to be able to handle shared devices. And odds are, you will get back a big "as-if" comment from the kernel developers, as for almost all devices, they can't be shared, for very good reasons. So work down the list of devices you really need access to, and either work to provide a way for the kernel to mediate them, or, work to only have one "container" access to one device, and not have all containers access to it at the same time. This has been discussed many times in the past, on mailing lists and in person at the Linux Plumbers conference last year. This isn't a systemd issue, it is a "you are using the kernel in ways it was not designed to be used" issue. good luck, you will need it... greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/6] documentation: bindings: document PMIC8921/8058 RTC
On Wed, Mar 05, 2014 at 05:31:27PM -0800, Stephen Boyd wrote: > On 03/05/14 16:00, Josh Cartwright wrote: > > On Wed, Mar 05, 2014 at 12:58:55PM -0800, Stephen Boyd wrote: > >> On 03/05/14 11:29, Josh Cartwright wrote: > >>> diff --git a/Documentation/devicetree/bindings/rtc/qcom,pm8xxx-rtc.txt > >>> b/Documentation/devicetree/bindings/rtc/qcom,pm8xxx-rtc.txt > >>> new file mode 100644 > >>> index 000..699bd30 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/rtc/qcom,pm8xxx-rtc.txt > >>> @@ -0,0 +1,29 @@ > >>> +* Real-Time Clock for Qualcomm 8058/8921 PMICs > >>> + > >>> +Required properties: > >>> +- compatible: should be one of the following. > >>> +* "qcom,pm8058-rtc" > >>> +* "qcom,pm8921-rtc" > >>> +- reg: base address of the register region > >>> +- reg-names: corresponding reg names for the regions listed in the 'reg' > >>> + property, must contain: > >>> + "rtc_base" - base of the RTC register region > >> optional reg-names? > >> > >>> +- interrupts: interrupt list for the RTC, must contain a single interrupt > >>> + specifier for the alarm interrupt > >>> +- interrupt-names: corresponding interrupt names for the interrupts > >>> listed in > >>> + the 'interrupts' property, must contain: > >>> + "alarm" - summary interrupt for PMIC peripherals > >> optional interrupt-names? > > It isn't clear to me why these should be made optional, I hope Rob > > provides some clarification in the sdhci-msm thread. > > Looks like the driver isn't using either of these properties, so I'm not > sure why they're needed. Maybe they should just be removed. The driver does make use of platform_get_irq_byname(pdev, "alarm"), and I expect to make use of platform_get_resource_byname(pdev, IORESOURCE_REG, "rtc_base") in the near future. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/5] arch: atomic rework
On Fri, Mar 07, 2014 at 06:45:57PM +0100, Torvald Riegel wrote:
> xagsmtp5.20140307174618.3...@vmsdvm6.vnet.ibm.com
> X-Xagent-Gateway: vmsdvm6.vnet.ibm.com (XAGSMTP5 at VMSDVM6)
>
> On Wed, 2014-03-05 at 10:01 -0800, Paul E. McKenney wrote:
> > On Wed, Mar 05, 2014 at 05:26:36PM +0100, Torvald Riegel wrote:
> > > xagsmtp3.20140305162928.8...@uk1vsc.vnet.ibm.com
> > > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP3 at UK1VSC)
> > >
> > > On Tue, 2014-03-04 at 11:00 -0800, Paul E. McKenney wrote:
> > > > On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
> > > > > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
> > > > > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
> > > > >
> > > > > On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
> > > > > > On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote:
> > > > > > > xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com
> > > > > > > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC)
> > > > > > >
> > > > > > > On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote:
> > > > > > > > +o Do not use the results from the boolean "&&" and "||"
> > > > > > > > when
> > > > > > > > + dereferencing. For example, the following (rather
> > > > > > > > improbable)
> > > > > > > > + code is buggy:
> > > > > > > > +
> > > > > > > > + int a[2];
> > > > > > > > + int index;
> > > > > > > > + int force_zero_index = 1;
> > > > > > > > +
> > > > > > > > + ...
> > > > > > > > +
> > > > > > > > + r1 = rcu_dereference(i1)
> > > > > > > > + r2 = a[r1 && force_zero_index]; /* BUGGY!!! */
> > > > > > > > +
> > > > > > > > + The reason this is buggy is that "&&" and "||" are
> > > > > > > > often compiled
> > > > > > > > + using branches. While weak-memory machines such as ARM
> > > > > > > > or PowerPC
> > > > > > > > + do order stores after such branches, they can speculate
> > > > > > > > loads,
> > > > > > > > + which can result in misordering bugs.
> > > > > > > > +
> > > > > > > > +o Do not use the results from relational operators ("==",
> > > > > > > > "!=",
> > > > > > > > + ">", ">=", "<", or "<=") when dereferencing. For
> > > > > > > > example,
> > > > > > > > + the following (quite strange) code is buggy:
> > > > > > > > +
> > > > > > > > + int a[2];
> > > > > > > > + int index;
> > > > > > > > + int flip_index = 0;
> > > > > > > > +
> > > > > > > > + ...
> > > > > > > > +
> > > > > > > > + r1 = rcu_dereference(i1)
> > > > > > > > + r2 = a[r1 != flip_index]; /* BUGGY!!! */
> > > > > > > > +
> > > > > > > > + As before, the reason this is buggy is that relational
> > > > > > > > operators
> > > > > > > > + are often compiled using branches. And as before,
> > > > > > > > although
> > > > > > > > + weak-memory machines such as ARM or PowerPC do order
> > > > > > > > stores
> > > > > > > > + after such branches, but can speculate loads, which can
> > > > > > > > again
> > > > > > > > + result in misordering bugs.
> > > > > > >
> > > > > > > Those two would be allowed by the wording I have recently
> > > > > > > proposed,
> > > > > > > AFAICS. r1 != flip_index would result in two possible values
> > > > > > > (unless
> > > > > > > there are further constraints due to the type of r1 and the
> > > > > > > values that
> > > > > > > flip_index can have).
> > > > > >
> > > > > > And I am OK with the value_dep_preserving type providing more/better
> > > > > > guarantees than we get by default from current compilers.
> > > > > >
> > > > > > One question, though. Suppose that the code did not want a value
> > > > > > dependency to be tracked through a comparison operator. What does
> > > > > > the developer do in that case? (The reason I ask is that I have
> > > > > > not yet found a use case in the Linux kernel that expects a value
> > > > > > dependency to be tracked through a comparison.)
> > > > >
> > > > > Hmm. I suppose use an explicit cast to non-vdp before or after the
> > > > > comparison?
> > > >
> > > > That should work well assuming that things like "if", "while", and "?:"
> > > > conditions are happy to take a vdp.
> > >
> > > I currently don't see a reason why that should be disallowed. If we
> > > have allowed an implicit conversion to non-vdp, I believe that should
> > > follow.
> >
> > I am a bit nervous about a silent implicit conversion from vdp to
> > non-vdp in the general case.
>
> Why are you nervous about it?
If someone expects the vdp to propagate into some function that might
be compiled with aggressive optimizations that break this expectation,
it would be good for that someone to know about it.
Ah! I am assuming that the compiler is -not- emitting memory barriers
at vdp-to-non-vdp transitions. In that case,
Re: [qemu64,+smep,+smap] WARNING: CPU: 1 PID: 0 at arch/x86/kernel/cpu/amd.c:220 init_amd()
On 03/06/2014 09:50 PM, Fengguang Wu wrote: >> >> Unfortunately these things are hard to fix in Qemu. > > OK. As an alternative, is it possible to pass one of the below CPUID flags in > the Qemu command line, so as to quiet the warning? > I don't see the AMD SMP CPUID flag in there. Boris, could you help? The problem is that "qemu -cpu qemu64,+smep,+smap" identifies as an AMD CPU which triggers a warning/taint because the SMP flag isn't set. > > Recognized CPUID flags: > pbe ia64 tm ht ss sse2 sse fxsr mmx acpi ds clflush pn pse36 pat cmov mca > pge mtrr sep apic cx8 mce pae msr tsc pse de vme fpu > hypervisor rdrand f16c avx osxsave xsave aes tsc-deadline popcnt movbe > x2apic sse4.2|sse4_2 sse4.1|sse4_1 dca pcid pdcm xtpr cx16 fma cid ssse3 tm2 > est smx vmx ds_cpl monitor dtes64 pclmulqdq|pclmuldq pni|sse3 > smap adx rdseed rtm invpcid erms bmi2 smep avx2 hle bmi1 fsgsbase > 3dnow 3dnowext lm|i64 rdtscp pdpe1gb fxsr_opt|ffxsr mmxext nx|xd syscall > perfctr_nb perfctr_core topoext tbm nodeid_msr tce fma4 lwp wdt skinit xop > ibs osvw 3dnowprefetch misalignsse sse4a abm cr8legacy extapic svm cmp_legacy > lahf_lm > pmm-en pmm phe-en phe ace2-en ace2 xcrypt-en xcrypt xstore-en xstore > kvm_pv_eoi kvm_steal_time kvm_asyncpf kvmclock kvm_mmu kvm_nopiodelay > kvmclock > pfthreshold pause_filter decodeassists flushbyasid vmcb_clean tsc_scale > nrip_save svm_lock lbrv npt > -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold wrote: > Hi Fengguang, > > i have build a kernel with the config, but my kvm is unable to start it. > I will try to find a way to test your kernek config. > > One thing is the crash point: > > The function sysenter_setup was modified by Andy, maybe he has an idea > what fails. *sigh* My host kernel is currently fscked up and won't run KVM. Also, I want to confirm that I'm reproducing exactly what you're seeing, and I think it depends on the toolchain. Can you (Fenguang) do: $ ls -l arch/x86/vdso/vdso32*.so -rwxrwxr-x. 1 luto luto 4096 Mar 7 10:19 arch/x86/vdso/vdso32-int80.so -rwxrwxr-x. 1 luto luto 4116 Mar 7 10:19 arch/x86/vdso/vdso32-sysenter.so (Of course, triggering this depends on which image gets selected.) Note that we have a .so file that exceeds 4k, i.e. one page. Then read the relevant code and wonder what everyone was smoking when they wrote it. There are so many buffer overflows, screwed up initializations, unnecessary and incorrect copies, etc, that I don't even want to speculate on what the first failure will be when the image is bigger than a page. It's easy enough to fix, but someone should figure out what the impact will be on the compat vdso case. I wonder how hard it would be to change the compat vdso do be a dummy image a la the x86_64 fake vsyscall page so that old code can keep working (maybe with a performance hit) and new code can use a sane image. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xtensa: enable sorting extable at build time
On Fri, Mar 7, 2014 at 10:39 PM, David Daney wrote: > On 03/07/2014 01:56 AM, Max Filippov wrote: >> >> On Tue, Feb 18, 2014 at 3:48 PM, Max Filippov wrote: >>> >>> Signed-off-by: Max Filippov >>> --- >>> arch/xtensa/Kconfig | 1 + >>> scripts/sortextable.c | 5 + >>> 2 files changed, 6 insertions(+) >> >> >> Ping? >> David, is this OK for scripts/sortextable.c? > > > If you wish, you can add Acked-by: me. Thanks. > But I am not the maintainer of the file, so you will have to get someone > else to merge it. I guess we can merge this patch through the xtensa tree unless there are any objections. -- Thanks. -- Max -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Suspending access to opened/active /dev/nodes during application runtime
Problem: Has anyone thought about a mechanism to limit/remove an access to a device during an application runtime? Meaning we have an application that has an open file descriptor to some /dev/node and depending on *something* it gains or looses the access to it gracefully (with or without a notification, but without any fatal consequences). Example: LXC. Imagine we have 2 separate containers. Both running full operating systems. Specifically with 2 X servers. Both running concurrently of course. Both need the same input devices (e.g. we have just one mouse). This creates a security problem when we want to have completely separate environments. One container is active (being displayed on a monitor and controlled with a mouse) while the other container runs evtest /dev/input/something and grabs the secret password user typed in the other. Solutions: The complete solution would comprise of 2 parts: - a mechanism that would allow to temporally "hide" a device from an open file descriptor. - a mechanism for deciding whether application/process/namespace should have an access to a specific device at a specific moment Let's focus on the first problem only, as it would need to be solved first anyway. I haven't found anything that would allow me to do it. There are a lot mechanisms that make it possible to restrict an access during open(): - DAC - ACL (controlled by hand or with uaccess) - LSM (in general) - device cgroups But all of those can't do a thing when the device is already opened and an application has a file descriptor. I don't see such mechanism in kernel sources either. I do imagine that it would not be possible for every device to handle such a thing (dri comes to mind) without breaking something (graphics card state in dri example). But there is class of simple input/output devices that would handle this without problems. I did implement some proof-of-concept solution for an evdev driver by allowing or disallowing events that go to evdev_client structure using some arbitrary condition. But this is far from a generic solution. My proof-of-concept is somewhat similar to this (I just found it): http://www.spinics.net/lists/linux-input/msg25547.html Though a little bit wider in scope. But neither is flawless nor generic. Has anyone had any thoughts about a similar problem? -- Regards Havner -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/11] kexec: Support for loading ELF x86_64 images
On Fri, Mar 07, 2014 at 06:12:33PM +0100, Borislav Petkov wrote:
> > > > +/* Fill in fields which are usually present in bzImage */
> > > > +static int init_linux_parameters(struct boot_params *params)
> > > > +{
> > > > + /*
> > > > +* FIXME: It is odd that the information which comes from kernel
> > > > +* has to be faked by loading kernel. I guess it is limitation
> > > > of
> > > > +* ELF format. Right now keeping it same as kexec-tools
> > > > +* implementation. But this most likely needs fixing.
> > > > +*/
> > > > + memcpy(>hdr.header, "HdrS", 4);
> > > > + params->hdr.version = 0x0206;
> > > > + params->hdr.initrd_addr_max = 0x37FF;
> > > > + params->hdr.cmdline_size = 2048;
> > > > + return 0;
> > > > +}
...
> Well, this is mandated by the boot protocol, no?
>
> "If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
> the boot protocol version is "old". Loading an old kernel, the
> following parameters should be assumed:
>
> Image type = zImage
> initrd not supported
> Real-mode kernel must be located at 0x9."
>
> About version 0x0206:
>
> Field name: cmdline_size
> Type: read
> Offset/size:0x238/4
> Protocol: 2.06+
>
> The maximum size of the command line without the terminating
> zero. This means that the command line can contain at most
> cmdline_size characters. With protocol version 2.05 and earlier, the
> maximum size was 255.
>
> So according to the protocol, cmdline_size should be set by
> kexec_file_load and not hardcoded to 2K, if we're mandating protocol
> version 2.06.
Btw, all those fields above are of type "read", which means,
"For each field, some are information from the kernel to the bootloader
("read"),... "
Now, if we assume that the first kernel is the bootloader and it loads
the second kernel, then the first kernel shouldn't be setting all those
fields *at* *all* because it violates the boot protocol. And that's a
no-no.
Generally, how important is that use case for loading ELF images? If no
one is actually using it, why even bother?
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On Fri, Mar 7, 2014 at 10:05 AM, Thomas Graf wrote: > On 03/07/2014 06:19 PM, Pravin Shelar wrote: >> >> On Fri, Mar 7, 2014 at 7:58 AM, Thomas Graf wrote: >>> >>> On 03/07/2014 05:46 AM, Pravin Shelar wrote: But I found bug in datapath user-space queue code. I am not sure how this can work with skb fragments and MMAP-netlink socket. Here is what happens, OVS allocates netlink skb and adds fragments to skb using skb_zero_copy(), then calls genlmsg_unicast(). But if netlink sock is mmped then netlink-send queues netlink allocated skb->head (linear data of skb) and ignore skb frags. Currently this is not problem with OVS vswitchd since it does not use netlink MMAP sockets. But if vswitchd stats using MMAP-netlink socket, it can break it. >>> >>> >>> >>> The secret is out ;-) >>> >>> I was very surprised too when I noticed that it worked. It's not just >>> OVS, it's nfqueue as well. The reason is that an netlink mmaped skb is >>> setup with a giant tailroom in netlink_ring_setup_skb(): >>> >>> skb->end= skb->tail + size; >>> >> For OVS use-case, the size is linear part of skb. so I think for >> mmap-netlink socket it will fail. > > > Could you rephrase? I'm not sure I understand correctly. > I meant OVS (queue_userspace_packet) passes skb_zerocopy_headlen() to genlmsg_new_unicast(). > The tailroom size equals to the configured frame payload size of > the ring buffer. So as long as the frame size chosen is large > enough to hold whatever pieces comes out of skb_gso_segment() we are > fine. That said, I agree that we should fix this properly before we > enable mmap on the OVS user space side. I see. So this work assuming that userspace sets nl_mmap_req.nm_frame_size large enough. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On Fri, Mar 7, 2014 at 9:59 AM, Thomas Graf wrote: > On 03/07/2014 06:28 PM, Pravin Shelar wrote: >> >> Problem is mapping SKBTX_DEV_ZEROCOPY pages to userspace. skb_zerocopy >> is not doing that. >> >> Unless I missing something, Current netlink code can not handle >> skb-frags with zero copy. So we have to copy skb anyways and no need >> to orphan-frags here. >> If you are planning on handling skb-frags without copying then >> skb_orphan_frags should be done in netlink. > > > If you look at the second part of skb_zerocopy() this is exactly what > it is doing unless the target skb has sufficient linear space > preallocated. At least unless mmap is enabled in which case we would > have to copy again until we have implemented a way to pass page refs > via the nl ring buffer. > What is problem with passing page ref with get_page() to new skb as long as it is accessed kernel? I think we should set SKBTX_DEV_ZEROCOPY flag for new skb in skb_zerocopy() to track such pages but no need call skb_orphan_frags(). > So I think Zoltan is correct in orphaning frags that come from f.e. > a tun device via zerocopy_sg_from_iovec(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xtensa: enable sorting extable at build time
On 03/07/2014 01:56 AM, Max Filippov wrote: On Tue, Feb 18, 2014 at 3:48 PM, Max Filippov wrote: Signed-off-by: Max Filippov --- arch/xtensa/Kconfig | 1 + scripts/sortextable.c | 5 + 2 files changed, 6 insertions(+) Ping? David, is this OK for scripts/sortextable.c? If you wish, you can add Acked-by: me. But I am not the maintainer of the file, so you will have to get someone else to merge it. David Daney diff --git a/arch/xtensa/Kconfig b/arch/xtensa/Kconfig index 1ccaf91..381370d 100644 --- a/arch/xtensa/Kconfig +++ b/arch/xtensa/Kconfig @@ -14,6 +14,7 @@ config XTENSA select GENERIC_PCI_IOMAP select ARCH_WANT_IPC_PARSE_VERSION select ARCH_WANT_OPTIONAL_GPIOLIB + select BUILDTIME_EXTABLE_SORT select CLONE_BACKWARDS select IRQ_DOMAIN select HAVE_OPROFILE diff --git a/scripts/sortextable.c b/scripts/sortextable.c index cc49062..1052d48 100644 --- a/scripts/sortextable.c +++ b/scripts/sortextable.c @@ -35,6 +35,10 @@ #define EM_ARCOMPACT 93 #endif +#ifndef EM_XTENSA +#define EM_XTENSA 94 +#endif + #ifndef EM_AARCH64 #define EM_AARCH64 183 #endif @@ -281,6 +285,7 @@ do_file(char const *const fname) case EM_AARCH64: case EM_MICROBLAZE: case EM_MIPS: + case EM_XTENSA: break; } /* end switch */ -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5][RFC][CFT] resizable namespace.c hashes
On Fri, Mar 07, 2014 at 09:17:19AM -0800, Andi Kleen wrote: > Al Viro writes: > > > * switch allocation to alloc_large_system_hash() > > * make sizes overridable by boot parameters (mhash_entries=, > > mphash_entries=) > > * switch mountpoint_hashtable from list_head to hlist_head > > So how much memory does this use on a standard system (<4GB memory)? Two hash chains per megabyte. IOW, 2Gb => 4096 of them. Could drive it lower, probably, but I'm a bit nervous about _really_ low-end boxen. Right now it matches your variant at 128Mb box. > How much memory does it use on a large system (0.5TB)? Probably over the top - alloc_large_system_hash() has that problem in general. 0.5Tb would amount to 2^20 hash chains. Which is probably too much, but then dentry hash on the same box will be 2^26 hash chains and inode hash - 2^25 chains. > How good is your hash function. Would jhash be more appropiate > and allow smaller hash tables? How the hell does hash function affect the average chain length? And yes, they are pretty evenly distributed. And while we are at it, what the hell does jhash have to do with the whole thing? No strings involved - the hash key is a pair of pointers. To objects allocated by kmem_cache_alloc(), so their middle bits are already fairly random. > Perhaps just want a tree here. _What_ tree? Andi, WTF are you talking about? That hash is a mapping from (parent vfsmount, mountpoint dentry) to child vfsmount. Sure, we do have the mount tree - all children of given vfsmount are on a cyclic list anchored in it. And iterating through those is painfully slow on realistic setups. Have a bunch of nfs4 referrals on one fs, and you are welcome to a hundred of vfsmounts on the child list of one. Create a bunch of bindings in assorted places in /usr, have *any* mountpoint in /usr pay the price when we cross it on pathname resolution. Same with /, since there tends to be a bunch of mounts on directories in root filesystem. FWIW, on the box I'm typing at right now - /proc, /sys, /dev, /run, /tmp, /home, /usr, /var. 8 of them. On the box I'm sshed into: /proc, /sys, /dev, /run, /usr, /media, /var, /tmp, /boot, /archive - 10. And traversing that would be the price on *any* pathname resolution trying to cross from root to e.g. /home or /usr. To get an equally bad behaviour on the current setup (even with the ridiculously small hash table size set by your patch back in 2002), you'd need ~2000 mounts. And it very easily degrades even more - consider e.g. a box that has a shitload of stuff automounted under /home. It can easily go well past 10 simultaneous ones... We could keep a per-mountpoint list, anchored in dentry. And pay with an extra pointer in each struct dentry out there. Which will cost a lot more. Or, we could anchor them in struct mountpoint and do hash lookup *and* list search on each mountpoint crossing - one to find struct mountpoint by struct dentry, another to look for vfsmount with the right parent. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/5] arch: atomic rework
On Wed, 2014-03-05 at 10:15 -0800, Paul E. McKenney wrote:
> On Wed, Mar 05, 2014 at 05:54:59PM +0100, Torvald Riegel wrote:
> > On Tue, 2014-03-04 at 13:35 -0800, Paul E. McKenney wrote:
> > > On Tue, Mar 04, 2014 at 11:00:32AM -0800, Paul E. McKenney wrote:
> > > > On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
> > > > > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
> > > > > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
> > > > >
> > > > > On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
> > > > > > On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote:
> > > > > > > xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com
> > > > > > > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC)
> > > > > > >
> > > > > > > On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote:
> > > > > > > > +o Do not use the results from the boolean "&&" and "||"
> > > > > > > > when
> > > > > > > > + dereferencing. For example, the following (rather
> > > > > > > > improbable)
> > > > > > > > + code is buggy:
> > > > > > > > +
> > > > > > > > + int a[2];
> > > > > > > > + int index;
> > > > > > > > + int force_zero_index = 1;
> > > > > > > > +
> > > > > > > > + ...
> > > > > > > > +
> > > > > > > > + r1 = rcu_dereference(i1)
> > > > > > > > + r2 = a[r1 && force_zero_index]; /* BUGGY!!! */
> > > > > > > > +
> > > > > > > > + The reason this is buggy is that "&&" and "||" are
> > > > > > > > often compiled
> > > > > > > > + using branches. While weak-memory machines such as ARM
> > > > > > > > or PowerPC
> > > > > > > > + do order stores after such branches, they can speculate
> > > > > > > > loads,
> > > > > > > > + which can result in misordering bugs.
> > > > > > > > +
> > > > > > > > +o Do not use the results from relational operators ("==",
> > > > > > > > "!=",
> > > > > > > > + ">", ">=", "<", or "<=") when dereferencing. For
> > > > > > > > example,
> > > > > > > > + the following (quite strange) code is buggy:
> > > > > > > > +
> > > > > > > > + int a[2];
> > > > > > > > + int index;
> > > > > > > > + int flip_index = 0;
> > > > > > > > +
> > > > > > > > + ...
> > > > > > > > +
> > > > > > > > + r1 = rcu_dereference(i1)
> > > > > > > > + r2 = a[r1 != flip_index]; /* BUGGY!!! */
> > > > > > > > +
> > > > > > > > + As before, the reason this is buggy is that relational
> > > > > > > > operators
> > > > > > > > + are often compiled using branches. And as before,
> > > > > > > > although
> > > > > > > > + weak-memory machines such as ARM or PowerPC do order
> > > > > > > > stores
> > > > > > > > + after such branches, but can speculate loads, which can
> > > > > > > > again
> > > > > > > > + result in misordering bugs.
> > > > > > >
> > > > > > > Those two would be allowed by the wording I have recently
> > > > > > > proposed,
> > > > > > > AFAICS. r1 != flip_index would result in two possible values
> > > > > > > (unless
> > > > > > > there are further constraints due to the type of r1 and the
> > > > > > > values that
> > > > > > > flip_index can have).
> > > > > >
> > > > > > And I am OK with the value_dep_preserving type providing more/better
> > > > > > guarantees than we get by default from current compilers.
> > > > > >
> > > > > > One question, though. Suppose that the code did not want a value
> > > > > > dependency to be tracked through a comparison operator. What does
> > > > > > the developer do in that case? (The reason I ask is that I have
> > > > > > not yet found a use case in the Linux kernel that expects a value
> > > > > > dependency to be tracked through a comparison.)
> > > > >
> > > > > Hmm. I suppose use an explicit cast to non-vdp before or after the
> > > > > comparison?
> > > >
> > > > That should work well assuming that things like "if", "while", and "?:"
> > > > conditions are happy to take a vdp. This assumes that p->a only returns
> > > > vdp if field "a" is declared vdp, otherwise we have vdps running wild
> > > > through the program. ;-)
> > > >
> > > > The other thing that can happen is that a vdp can get handed off to
> > > > another synchronization mechanism, for example, to reference counting:
> > > >
> > > > p = atomic_load_explicit(, memory_order_consume);
> > > > if (do_something_with(p->a)) {
> > > > /* fast path protected by RCU. */
> > > > return 0;
> > > > }
> > > > if (atomic_inc_not_zero(>refcnt) {
> > > > /* slow path protected by reference counting. */
> > > > return do_something_else_with((struct foo *)p); /*
> > > > CHANGE */
> > > > }
> > > > /* Needed slow path, but raced with deletion. */
> > > > return
Re: [PATCH v4 1/4] pci: APM X-Gene PCIe controller driver
Thanks for reviewing and the comments. I will surely include them in
next version.
-Tanmay
On Fri, Mar 7, 2014 at 12:37 AM, Jingoo Han wrote:
> On Thursday, March 06, 2014 3:06 PM, Tanmay Inamdar wrote:
>>
>
> Hi Tanmay Inamdar,
>
> I added some minor comments. :-)
>
>> This patch adds the AppliedMicro X-Gene SOC PCIe controller driver.
>> X-Gene PCIe controller supports maxmum upto 8 lanes and GEN3 speed.
>
> Would you fix the followings?
>
> s/maxmum/maximum
> s/upto/up to
>
>> X-Gene SOC supports maximum 5 PCIe ports.
>>
>> Signed-off-by: Tanmay Inamdar
>> ---
>> drivers/pci/host/Kconfig | 10 +
>> drivers/pci/host/Makefile|1 +
>> drivers/pci/host/pci-xgene.c | 739
>> ++
>> 3 files changed, 750 insertions(+)
>> create mode 100644 drivers/pci/host/pci-xgene.c
>
> [.]
>
>> --- /dev/null
>> +++ b/drivers/pci/host/pci-xgene.c
>
> [.]
>
>> +
>> +static int xgene_pcie_parse_map_dma_ranges(struct xgene_pcie_port *port)
>> +{
>> + struct device_node *np = port->node;
>> + struct of_pci_range range;
>> + struct of_pci_range_parser parser;
>> + struct device *dev = port->dev;
>> + u8 ib_reg_mask = 0;
>> +
>> + if (pci_dma_range_parser_init(, np)) {
>> + dev_err(dev, "missing dma-ranges property\n");
>> + return -EINVAL;
>> + }
>> +
>> + /* Get the dma-ranges from DT */
>> + for_each_of_pci_range(, ) {
>> + u64 end = range.cpu_addr + range.size - 1;
>> + dev_dbg(port->dev, "0x%08x 0x%016llx..0x%016llx ->
>> 0x%016llx\n",
>> + range.flags, range.cpu_addr, end, range.pci_addr);
>> + xgene_pcie_setup_ib_reg(port, , _reg_mask);
>> + }
>> + return 0;
>> +}
>> +
>> +static int __init xgene_pcie_probe_bridge(struct platform_device *pdev)
>
> Please, remove '__init' marker in order to fix section mismatch
> warning.
>
>> +{
>> + struct device_node *np = of_node_get(pdev->dev.of_node);
>> + struct xgene_pcie_port *port;
>> + struct pci_host_bridge *bridge;
>> + resource_size_t lastbus;
>> + u32 lanes = 0, speed = 0;
>> + u64 cfg_addr = 0;
>> + int ret;
>> +
>> + port = devm_kzalloc(>dev, sizeof(*port), GFP_KERNEL);
>> + if (!port)
>> + return -ENOMEM;
>> + port->node = np;
>> + port->dev = >dev;
>> +
>> + ret = xgene_pcie_map_reg(port, pdev, _addr);
>> + if (ret)
>> + return ret;
>> +
>> + ret = xgene_pcie_init_port(port);
>> + if (ret)
>> + return ret;
>> + xgene_pcie_program_core(port->csr_base);
>> + xgene_pcie_setup_root_complex(port);
>> +
>> + bridge = of_create_pci_host_bridge(>dev, _pcie_ops, port);
>> + if (IS_ERR_OR_NULL(bridge))
>> + return PTR_ERR(bridge);
>> +
>> + ret = xgene_pcie_map_ranges(port, bridge, cfg_addr);
>> + if (ret)
>> + return ret;
>> +
>> + ret = xgene_pcie_parse_map_dma_ranges(port);
>> + if (ret)
>> + return ret;
>> +
>> + xgene_pcie_poll_linkup(port, , );
>> + if (!port->link_up)
>> + dev_info(port->dev, "(rc) link down\n");
>> + else
>> + dev_info(port->dev, "(rc) x%d gen-%d link up\n",
>> + lanes, speed + 1);
>> + platform_set_drvdata(pdev, port);
>> + lastbus = pci_rescan_bus(bridge->bus);
>> + pci_bus_update_busn_res_end(bridge->bus, lastbus);
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id xgene_pcie_match_table[] __initconst = {
>
> Please, remove '__initconst' marker in order to fix section mismatch
> warning.
>
>> + {.compatible = "apm,xgene-pcie",},
>> + {},
>> +};
>> +
>> +static struct platform_driver xgene_pcie_driver = {
>> + .driver = {
>> +.name = "xgene-pcie",
>> +.owner = THIS_MODULE,
>> +.of_match_table = of_match_ptr(xgene_pcie_match_table),
>> + },
>
> Please fix this indent style, as below:
>
> + },
>
> See you later. :-)
>
> Best regards,
> Jingoo Han
>
>> + .probe = xgene_pcie_probe_bridge,
>> +};
>> +module_platform_driver(xgene_pcie_driver);
>> +
>> +MODULE_AUTHOR("Tanmay Inamdar ");
>> +MODULE_DESCRIPTION("APM X-Gene PCIe driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
On Fri, Mar 07, 2014 at 11:16:10PM +0530, Kishon Vijay Abraham I wrote: > On Friday 07 March 2014 11:10 PM, Felipe Balbi wrote: > >On Fri, Mar 07, 2014 at 11:09:02PM +0530, Kishon Vijay Abraham I wrote: > >>On Friday 07 March 2014 10:20 PM, Felipe Balbi wrote: > >>>On Fri, Mar 07, 2014 at 10:18:08PM +0530, Kishon Vijay Abraham I wrote: > No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/. > Also removed the unused members of struct omap_usb (after phy-omap-pipe3 > started using it's own header file) > >>> > >>>does this depend in any other patch ? I get the following when applying > >>>*only* this patch on top of v3.14-rc5: > >> > >>yeah.. this is for linux-phy tree. I'll take this patch. > > > >looks like you're doing two things at once (renaming the header and > >removing some unnecessary fields). At least mention the second thing. > > The second line of the commit message mentions just that ;-) hmmm, my parser didn't read that, nevermind ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH -mm] mm,numa,mprotect: always continue after finding a stable thp page
On Fri, Mar 07, 2014 at 03:09:23PM +, Mel Gorman wrote:
> On Fri, Mar 07, 2014 at 02:06:50PM +, Mel Gorman wrote:
> > On Thu, Mar 06, 2014 at 05:52:47PM -0500, Rik van Riel wrote:
> > > On 03/06/2014 05:31 PM, Rik van Riel wrote:
> > > >On Thu, 06 Mar 2014 16:12:28 -0500
> > > >Sasha Levin wrote:
> > > >
> > > >>While fuzzing with trinity inside a KVM tools guest running latest
> > > >>-next kernel I've hit the
> > > >>following spew. This seems to be introduced by your patch "mm,numa:
> > > >>reorganize change_pmd_range()".
> > > >
> > > >That patch should not introduce any functional changes, except for
> > > >the VM_BUG_ON that catches the fact that we fell through to the 4kB
> > > >pte handling code, despite having just handled a THP pmd...
> > > >
> > > >Does this patch fix the issue?
> > > >
> > > >Mel, am I overlooking anything obvious? :)
> > > >
> > > >---8<---
> > > >
> > > >Subject: mm,numa,mprotect: always continue after finding a stable thp
> > > >page
> > > >
> > > >When turning a thp pmds into a NUMA one, change_huge_pmd will
> > > >return 0 when the pmd already is a NUMA pmd.
> > >
> > > I did miss something obvious. In this case, the code returns 1.
> > >
> > > >However, change_pmd_range would fall through to the code that
> > > >handles 4kB pages, instead of continuing on to the next pmd.
> > >
> > > Maybe the case that I missed is when khugepaged is in the
> > > process of collapsing pages into a transparent huge page?
> > >
> > > If the virtual CPU gets de-scheduled by the host for long
> > > enough, it would be possible for khugepaged to run on
> > > another virtual CPU, and turn the pmd into a THP pmd,
> > > before that VM_BUG_ON test.
> > >
> > > I see that khugepaged takes the mmap_sem for writing in the
> > > collapse code, and it looks like task_numa_work takes the
> > > mmap_sem for reading, so I guess that may not be possible?
> > >
> >
> > mmap_sem will prevent a parallel collapse but what prevents something
> > like the following?
> >
> > do_huge_pmd_wp_page
> > change_pmd_range
> > if (!pmd_trans_huge(*pmd) && pmd_none_or_clear_bad(pmd))
> > continue;
> > pmdp_clear_flush(vma,
> > haddr, pmd);
> > if (pmd_trans_huge(*pmd)) {
> > path not taken
> > }
> >
> > page_add_new_anon_rmap(new_page, vma, haddr);
> > set_pmd_at(mm, haddr,
> > pmd, entry);
> > VM_BUG_ON(pmd_trans_huge(*pmd));
> >
> > We do not hold the page table lock during the pmd_trans_huge check and we
> > do not recheck it under PTF lock in change_pte_range()
> >
>
> This is a completely untested prototype. It rechecks pmd_trans_huge
> under the lock and falls through if it hit a parallel split. It's not
> perfect because it could decide to fall through just because there was
> no prot_numa work to do but it's for illustration purposes. Secondly,
> I noted that you are calling invalidate for every pmd range. Is that not
> a lot of invalidations? We could do the same by just tracking the address
> of the first invalidation.
>
And there were other minor issues. This is still untested but Sasha,
can you try it out please? I discussed this with Rik on IRC for a bit and
reckon this should be sufficient if the correct race has been identified.
The race can only really happen for prot_numa updates and it's ok to bail on
those updates if a race occurs because all we miss is a few hinting faults.
That simplifies the patch considerably but throw in some comments to
explain it
diff --git a/mm/mprotect.c b/mm/mprotect.c
index 2afc40e..72061a2 100644
--- a/mm/mprotect.c
+++ b/mm/mprotect.c
@@ -46,6 +46,17 @@ static unsigned long change_pte_range(struct vm_area_struct
*vma, pmd_t *pmd,
unsigned long pages = 0;
pte = pte_offset_map_lock(mm, pmd, addr, );
+
+ /*
+* For a prot_numa update we only hold mmap_sem for read so there is a
+* potential race with faulting where a pmd was temporarily none so
+* recheck it under the lock and bail if we race
+*/
+ if (prot_numa && unlikely(pmd_trans_huge(*pmd))) {
+ pte_unmap_unlock(pte, ptl);
+ return 0;
+ }
+
arch_enter_lazy_mmu_mode();
do {
oldpte = *pte;
@@ -141,12 +152,13 @@ static inline unsigned long change_pmd_range(struct
vm_area_struct *vma,
pages += HPAGE_PMD_NR;
nr_huge_updates++;
}
+
+ /* huge pmd was handled */
continue;
}
}
/* fall through, the trans huge pmd just split */
}
-
proposed patch to ideapad-laptop module for Yoga 2 Pro
The Lenovo Ideapad Yoga laptops have a VPC2004 ACPI device, so the
ideapad-laptop module loads for them. The module enables the Airplane Mode
and Novo keys of the laptop. Most of the other features of this module
are harmless for these laptops. However, the laptops do not have hardware
RF kill switches and when the module loads it turns off the WiFi.
This patch adds a flag (rfkill_present) to the ideapad_private data
indicating whether the laptop has an RF kill switch. On initialization,
there is a check whether the laptop is a Yoga 2 Pro by matching against the
DMI product version of the system information. If there is a match the flag
is set to false, otherwise it is set to true. All manipulations of the
rfkill structures are conditioned on this flag being true.
This is a minimal change to make the ideapad-laptop module work correctly
for Yoga 2 Pro Ideapads. The initialization check should be generalized for
other Ideapads that do not have RF kill switches, particularly other Yogas,
but I do not have precise information on their DMI version information.
What should be done to get this patchapplied?
Peter F. Patel-Schneider
---
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -84,6 +85,7 @@ struct ideapad_private {
struct input_dev *inputdev;
struct backlight_device *blightdev;
struct dentry *debug;
+bool rfkill_present;
unsigned long cfg;
};
@@ -474,13 +476,15 @@ static void ideapad_sync_rfk_state(struct
ideapad_private *priv)
unsigned long hw_blocked;
int i;
-if (read_ec_data(priv->adev->handle, VPCCMD_R_RF, _blocked))
-return;
-hw_blocked = !hw_blocked;
+if (priv->rfkill_present) {
+if (read_ec_data(priv->adev->handle, VPCCMD_R_RF, _blocked))
+return;
+hw_blocked = !hw_blocked;
-for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
-if (priv->rfk[i])
-rfkill_set_hw_state(priv->rfk[i], hw_blocked);
+for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
+if (priv->rfk[i])
+rfkill_set_hw_state(priv->rfk[i], hw_blocked);
+}
}
static int ideapad_register_rfkill(struct ideapad_private *priv, int dev)
@@ -825,6 +829,7 @@ static int ideapad_acpi_add(struct platform_device *pdev)
int cfg;
struct ideapad_private *priv;
struct acpi_device *adev;
+char const *s;
ret = acpi_bus_get_device(ACPI_HANDLE(>dev), );
if (ret)
@@ -842,6 +847,15 @@ static int ideapad_acpi_add(struct platform_device *pdev)
priv->adev = adev;
priv->platform_device = pdev;
+/* check for Yoga 2 Pro, which has no rfkill switches */
+s = dmi_get_system_info(DMI_PRODUCT_VERSION);
+if (s && !(strncmp(s, "Lenovo Yoga 2 Pro", 17)) ) {
+priv->rfkill_present = false;
+} else {
+priv->rfkill_present = true;
+}
+
+
ret = ideapad_sysfs_init(priv);
if (ret)
goto sysfs_failed;
@@ -854,11 +868,13 @@ static int ideapad_acpi_add(struct platform_device *pdev)
if (ret)
goto input_failed;
-for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++) {
-if (test_bit(ideapad_rfk_data[i].cfgbit, >cfg))
-ideapad_register_rfkill(priv, i);
-else
-priv->rfk[i] = NULL;
+if (priv->rfkill_present) {
+for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++) {
+if (test_bit(ideapad_rfk_data[i].cfgbit, >cfg))
+ideapad_register_rfkill(priv, i);
+else
+priv->rfk[i] = NULL;
+}
}
ideapad_sync_rfk_state(priv);
ideapad_sync_touchpad_state(priv);
@@ -877,8 +893,10 @@ static int ideapad_acpi_add(struct platform_device *pdev)
notification_failed:
ideapad_backlight_exit(priv);
backlight_failed:
-for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
-ideapad_unregister_rfkill(priv, i);
+if (priv->rfkill_present) {
+for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
+ideapad_unregister_rfkill(priv, i);
+}
ideapad_input_exit(priv);
input_failed:
ideapad_debugfs_exit(priv);
@@ -897,8 +915,10 @@ static int ideapad_acpi_remove(struct platform_device
*pdev)
acpi_remove_notify_handler(priv->adev->handle,
ACPI_DEVICE_NOTIFY, ideapad_acpi_notify);
ideapad_backlight_exit(priv);
-for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
-ideapad_unregister_rfkill(priv, i);
+if (priv->rfkill_present) {
+for (i = 0; i < IDEAPAD_RFKILL_DEV_NUM; i++)
+ideapad_unregister_rfkill(priv, i);
+}
ideapad_input_exit(priv);
ideapad_debugfs_exit(priv);
ideapad_sysfs_exit(priv);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [PATCH 4/4] x86: Fix order of warning messages when ftrace modifies code
On Fri, 7 Mar 2014 09:43:29 +0100 Petr Mládek wrote: > This patch is nice to have but it is rather cosmetic. I do not mind > that much about it. Feel free to drop, accept, or just merge into > any other commit. > OK, I just added it to my 3.16 queue. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tools/net/Makefile: Define PACKAGE to fix bfd build problems
From: Markos Chandras Date: Fri, 7 Mar 2014 09:18:28 + > On 03/06/2014 05:54 PM, David Miller wrote: >> From: Markos Chandras >> Date: Thu, 6 Mar 2014 09:15:54 + >> >>> Fixes the following build problem with binutils-2.24 >>> >>> gcc -Wall -O2 -c -o bpf_jit_disasm.o bpf_jit_disasm.c >>> In file included from bpf_jit_disasm.c:25:0: >>> /usr/include/bfd.h:35:2: error: #error config.h must be included >>> before this header >>> #error config.h must be included before this header >>> >>> This is similar to commit 3ce711a6abc27abce1554e1d671a8762b7187690 >>> "perf tools: bfd.h/libbfd detection fails with recent binutils" >>> >>> See: https://sourceware.org/bugzilla/show_bug.cgi?id=14243 >>> >>> CC: David S. Miller >>> CC: Daniel Borkmann >>> Signed-off-by: Markos Chandras >> >> I think your subject needs to be adjusted, this patch doesn't fix a >> "bfd" >> build problem. >> > Hi David, > > Thanks for the comment. Well it's problem caused by the bfd > header. However, I suppose you can remove the 'bfd' word from the > subject as I understand it's confusing. Would you be able to fix this > before you apply this patch or should I send a new patch? Please send a new patch, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] x86: Fix order of warning messages when ftrace modifies code
H. Peter,
I just added this to my 3.16 queue. But can you give an Acked-by for it
too. That way I don't forget to ask you later (3.16 is a ways away ;-)
I'd add it to my 3.15 queue, but I'm trying not to make changes to it
unless they are more significant.
-- Steve
On Mon, 17 Feb 2014 16:22:53 +0100
Petr Mladek wrote:
> The colon at the end of the printk message suggests that it should get printed
> before the details printed by ftrace_bug().
>
> When touching the line, let's use the preferred pr_warn() macro as suggested
> by checkpatch.pl.
>
> Signed-off-by: Petr Mladek
> ---
> arch/x86/kernel/ftrace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 525a9f954c8b..ad7c38f5206b 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -622,8 +622,8 @@ void ftrace_replace_code(int enable)
> return;
>
> remove_breakpoints:
> + pr_warn("Failed on %s (%d):\n", report, count);
> ftrace_bug(ret, rec ? rec->ip : 0);
> - printk(KERN_WARNING "Failed on %s (%d):\n", report, count);
> for_ftrace_rec_iter(iter) {
> int err;
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Tachometer speed returned rather than absolute fan speed?
On Fri, Mar 07, 2014 at 03:47:08PM +, Laszlo Papp wrote: > On Fri, Mar 7, 2014 at 3:37 PM, Jean Delvare wrote: > >> > I'm quite confused. While I admit that the term "tachometer speed" is > >> > awkward, the max6650 driver is reporting fan speeds in RPM as every > >> > other hwmon driver. So I really have no idea what you think is wrong. > >> > What did you think "tachometer speed" was, if not the fan speed? Does > >> > the max6650 driver not return correct fan speeds for you? > > That is some strange behavior. If I do "echo 1 > pwm1_enable; echo 0 > > pwm1; cat fan1_input", I still see 30 for the connected fan, whereas I > can see it stopped. Is this an expected behavior? I would expect zero > as a user. > I seem to recall that I had seen that as well, with no fan connected. Maybe the tachometer registers always read at least '1'. I would think it is wrong, but we'll have to understand the chip a bit better to be able to provide a fix. Unless you already have a fix ready, of course. I'll try to re-test tonight if I find the time. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 31/48] uv: Replace __get_cpu_var
On Wed, 5 Mar 2014, Mike Travis wrote: > I haven't had much chance yet to look over your proposed changes but > FYI, the counters are strictly feedback to insure that there are not > unhandled NMI events from the perf subsystem. The exact count is > irrelevant. IOW, counts in the double or triple digits is okay, > counts > 100,000 is definitely not okay (there are multiple millions > of perf events every 'perf top' refresh.) > > I'm not sure if this alters how you want to approach the changes. Gotta patch here that converts all the atomic per cpu counters to int but the local64_t definitions look very strange to me. I have never seen a local64_t definition that is global and used for a counters. That can only work if there is only one and exactly one processor that is modifying the count. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On 03/07/2014 06:19 PM, Pravin Shelar wrote: On Fri, Mar 7, 2014 at 7:58 AM, Thomas Graf wrote: On 03/07/2014 05:46 AM, Pravin Shelar wrote: But I found bug in datapath user-space queue code. I am not sure how this can work with skb fragments and MMAP-netlink socket. Here is what happens, OVS allocates netlink skb and adds fragments to skb using skb_zero_copy(), then calls genlmsg_unicast(). But if netlink sock is mmped then netlink-send queues netlink allocated skb->head (linear data of skb) and ignore skb frags. Currently this is not problem with OVS vswitchd since it does not use netlink MMAP sockets. But if vswitchd stats using MMAP-netlink socket, it can break it. The secret is out ;-) I was very surprised too when I noticed that it worked. It's not just OVS, it's nfqueue as well. The reason is that an netlink mmaped skb is setup with a giant tailroom in netlink_ring_setup_skb(): skb->end= skb->tail + size; For OVS use-case, the size is linear part of skb. so I think for mmap-netlink socket it will fail. Could you rephrase? I'm not sure I understand correctly. The tailroom size equals to the configured frame payload size of the ring buffer. So as long as the frame size chosen is large enough to hold whatever pieces comes out of skb_gso_segment() we are fine. That said, I agree that we should fix this properly before we enable mmap on the OVS user space side. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On 03/07/2014 06:28 PM, Pravin Shelar wrote: Problem is mapping SKBTX_DEV_ZEROCOPY pages to userspace. skb_zerocopy is not doing that. Unless I missing something, Current netlink code can not handle skb-frags with zero copy. So we have to copy skb anyways and no need to orphan-frags here. If you are planning on handling skb-frags without copying then skb_orphan_frags should be done in netlink. If you look at the second part of skb_zerocopy() this is exactly what it is doing unless the target skb has sufficient linear space preallocated. At least unless mmap is enabled in which case we would have to copy again until we have implemented a way to pass page refs via the nl ring buffer. So I think Zoltan is correct in orphaning frags that come from f.e. a tun device via zerocopy_sg_from_iovec(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset: Add optional resets and stubs
Hi Philipp, On Fri, Mar 07, 2014 at 03:30:23PM +0100, Philipp Zabel wrote: > This patch adds device_reset_optional and (devm_)reset_control_get_optional > variants that drivers can use to indicate they can function without control > over the reset line. For those functions, stubs are added so the drivers can > be compiled with CONFIG_RESET_CONTROLLER disabled. > Also, device_reset is annotated with __must_check. Drivers ignoring the return > value should use device_reset_optional instead. > > Signed-off-by: Philipp Zabel Reviewed-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[ANNOUNCE] 3.2.55-rt79
Dear RT Folks,
I'm pleased to announce the 3.2.55-rt79 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v3.2-rt
Head SHA1: 1db3983893d2a70342a3af66a2ea1608dc068dfa
Or to build 3.2.55-rt79 directly, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.55.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.55-rt79.patch.xz
You can also build from 3.2.55-rt78 by applying the incremental patch:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/incr/patch-3.2.55-rt78-rt79.patch.xz
Enjoy,
-- Steve
Changes from v3.2.55-rt78:
---
Sebastian Andrzej Siewior (3):
Revert "x86: Disable IST stacks for debug/int 3/stack fault for
PREEMPT_RT"
kernel/hrtimer: be non-freezeable in cpu_chill()
arm/unwind: use a raw_spin_lock
Steven Rostedt (1):
rt: Make cpu_chill() use hrtimer instead of msleep()
Steven Rostedt (Red Hat) (1):
Linux 3.2.55-rt79
Tiejun Chen (1):
rcutree/rcu_bh_qs: disable irq while calling rcu_preempt_qs()
arch/arm/kernel/unwind.c | 14 +++---
arch/x86/include/asm/page_64_types.h | 21 ++---
arch/x86/kernel/cpu/common.c | 2 --
arch/x86/kernel/dumpstack_64.c | 4
include/linux/delay.h| 2 +-
kernel/hrtimer.c | 19 +++
kernel/rcutree.c | 5 +
localversion-rt | 2 +-
8 files changed, 39 insertions(+), 30 deletions(-)
---
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..bbafc67 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -87,7 +87,7 @@ extern const struct unwind_idx __start_unwind_idx[];
static const struct unwind_idx *__origin_unwind_idx;
extern const struct unwind_idx __stop_unwind_idx[];
-static DEFINE_SPINLOCK(unwind_lock);
+static DEFINE_RAW_SPINLOCK(unwind_lock);
static LIST_HEAD(unwind_tables);
/* Convert a prel31 symbol to an absolute address */
@@ -195,7 +195,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned
long addr)
/* module unwind tables */
struct unwind_table *table;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_for_each_entry(table, _tables, list) {
if (addr >= table->begin_addr &&
addr < table->end_addr) {
@@ -207,7 +207,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned
long addr)
break;
}
}
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
}
pr_debug("%s: idx = %p\n", __func__, idx);
@@ -469,9 +469,9 @@ struct unwind_table *unwind_table_add(unsigned long start,
unsigned long size,
tab->begin_addr = text_addr;
tab->end_addr = text_addr + text_size;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_add_tail(>list, _tables);
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
return tab;
}
@@ -483,9 +483,9 @@ void unwind_table_del(struct unwind_table *tab)
if (!tab)
return;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_del(>list);
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
kfree(tab);
}
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 0883ecd..7639dbf 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -14,21 +14,12 @@
#define IRQ_STACK_ORDER 2
#define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
-#ifdef CONFIG_PREEMPT_RT_FULL
-# define STACKFAULT_STACK 0
-# define DOUBLEFAULT_STACK 1
-# define NMI_STACK 2
-# define DEBUG_STACK 0
-# define MCE_STACK 3
-# define N_EXCEPTION_STACKS 3 /* hw limit: 7 */
-#else
-# define STACKFAULT_STACK 1
-# define DOUBLEFAULT_STACK 2
-# define NMI_STACK 3
-# define DEBUG_STACK 4
-# define MCE_STACK 5
-# define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
-#endif
+#define STACKFAULT_STACK 1
+#define DOUBLEFAULT_STACK 2
+#define NMI_STACK 3
+#define DEBUG_STACK 4
+#define MCE_STACK 5
+#define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
#define PUD_PAGE_SIZE (_AC(1, UL) << PUD_SHIFT)
#define PUD_PAGE_MASK (~(PUD_PAGE_SIZE-1))
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index edc013e..ca93cc7 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1050,9 +1050,7 @@
[git pull v2] device mapper fixes to include in 3.14-rc6
Hi Linus, Seems you haven't pulled tags/dm-3.14-fixes-2 yet, but either way please pull tags/dm-3.14-fixes-3 Sorry for requesting that you pull another tag so quickly but a late breaking yet _very_ important bug fix for dm thin-provisioning and dm cache has landed based on a really helpful bug report from last night (see commit cebc2de). The following changes since commit e0d849fad746cb36a6822e4595d8ba9bf0adf7fa: dm cache: fix truncation bug when mapping I/O to >2TB fast device (2014-02-28 09:23:02 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/dm-3.14-fixes-3 for you to fetch changes up to cebc2de44d3bce53e46476e774126c298ca2c8a9: dm space map metadata: fix refcount decrement below 0 which caused corruption (2014-03-07 12:02:47 -0500) Please pull, thanks! Mike A dm-cache memory allocation failure fix, fix DM's Kconfig identation, a dm-snapshot metadata corruption fix for bug introduced in 3.14-rc1, an important refcount < 0 fix for the DM persistent data library's space map metadata interface which fixes corruption reported by a few dm-thinp users, and last but not least: more extensive fixes than ideal for dm-thinp's data resize capability (which has had growing pain much like we've seen from -ENOSPC handling of filesystems that mature). The end result is dm-thinp now handles metadata operation failure and no data space error conditions much better than before. Heinz Mauelshagen (1): dm cache mq: fix memory allocation failure for large cache devices Joe Thornber (4): dm thin: fix out of data space handling dm thin: fix deadlock in __requeue_bio_list dm thin: fix noflush suspend IO queueing dm space map metadata: fix refcount decrement below 0 which caused corruption Mike Snitzer (4): dm: fix Kconfig indentation dm thin: synchronize the pool mode during suspend dm thin: ensure user takes action to validate data and metadata consistency dm thin: fix Documentation for held metadata root feature Mikulas Patocka (1): dm snapshot: fix metadata corruption Documentation/device-mapper/cache.txt | 11 +- Documentation/device-mapper/thin-provisioning.txt | 34 ++- drivers/md/Kconfig | 10 - drivers/md/dm-cache-policy-mq.c| 4 +- drivers/md/dm-snap-persistent.c| 3 + drivers/md/dm-thin-metadata.c | 37 ++- drivers/md/dm-thin-metadata.h | 11 + drivers/md/dm-thin.c | 304 - drivers/md/persistent-data/Kconfig | 10 + drivers/md/persistent-data/dm-space-map-metadata.c | 113 ++-- 10 files changed, 425 insertions(+), 112 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] 3.4.82-rt101
Dear RT Folks,
I'm pleased to announce the 3.4.82-rt101 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v3.4-rt
Head SHA1: 01a1d70707d15d64c4f013d78b520642e0c6d6bb
Or to build 3.4.82-rt101 directly, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.82.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.82-rt101.patch.xz
You can also build from 3.4.82-rt100 by applying the incremental patch:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/incr/patch-3.4.82-rt100-rt101.patch.xz
Enjoy,
-- Steve
Changes from v3.4.82-rt100:
---
Sebastian Andrzej Siewior (3):
Revert "x86: Disable IST stacks for debug/int 3/stack fault for
PREEMPT_RT"
kernel/hrtimer: be non-freezeable in cpu_chill()
arm/unwind: use a raw_spin_lock
Steven Rostedt (1):
rt: Make cpu_chill() use hrtimer instead of msleep()
Steven Rostedt (Red Hat) (1):
Linux 3.4.82-rt101
Tiejun Chen (1):
rcutree/rcu_bh_qs: disable irq while calling rcu_preempt_qs()
arch/arm/kernel/unwind.c | 14 +++---
arch/x86/include/asm/page_64_types.h | 21 ++---
arch/x86/kernel/cpu/common.c | 2 --
arch/x86/kernel/dumpstack_64.c | 4
include/linux/delay.h| 2 +-
kernel/hrtimer.c | 19 +++
kernel/rcutree.c | 5 +
localversion-rt | 2 +-
8 files changed, 39 insertions(+), 30 deletions(-)
---
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..bbafc67 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -87,7 +87,7 @@ extern const struct unwind_idx __start_unwind_idx[];
static const struct unwind_idx *__origin_unwind_idx;
extern const struct unwind_idx __stop_unwind_idx[];
-static DEFINE_SPINLOCK(unwind_lock);
+static DEFINE_RAW_SPINLOCK(unwind_lock);
static LIST_HEAD(unwind_tables);
/* Convert a prel31 symbol to an absolute address */
@@ -195,7 +195,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned
long addr)
/* module unwind tables */
struct unwind_table *table;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_for_each_entry(table, _tables, list) {
if (addr >= table->begin_addr &&
addr < table->end_addr) {
@@ -207,7 +207,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned
long addr)
break;
}
}
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
}
pr_debug("%s: idx = %p\n", __func__, idx);
@@ -469,9 +469,9 @@ struct unwind_table *unwind_table_add(unsigned long start,
unsigned long size,
tab->begin_addr = text_addr;
tab->end_addr = text_addr + text_size;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_add_tail(>list, _tables);
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
return tab;
}
@@ -483,9 +483,9 @@ void unwind_table_del(struct unwind_table *tab)
if (!tab)
return;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_del(>list);
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
kfree(tab);
}
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 0883ecd..7639dbf 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -14,21 +14,12 @@
#define IRQ_STACK_ORDER 2
#define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
-#ifdef CONFIG_PREEMPT_RT_FULL
-# define STACKFAULT_STACK 0
-# define DOUBLEFAULT_STACK 1
-# define NMI_STACK 2
-# define DEBUG_STACK 0
-# define MCE_STACK 3
-# define N_EXCEPTION_STACKS 3 /* hw limit: 7 */
-#else
-# define STACKFAULT_STACK 1
-# define DOUBLEFAULT_STACK 2
-# define NMI_STACK 3
-# define DEBUG_STACK 4
-# define MCE_STACK 5
-# define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
-#endif
+#define STACKFAULT_STACK 1
+#define DOUBLEFAULT_STACK 2
+#define NMI_STACK 3
+#define DEBUG_STACK 4
+#define MCE_STACK 5
+#define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
#define PUD_PAGE_SIZE (_AC(1, UL) << PUD_SHIFT)
#define PUD_PAGE_MASK (~(PUD_PAGE_SIZE-1))
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f743261..cf79302 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1056,9 +1056,7 @@
[ANNOUNCE] 3.8.13.14-rt28
Dear RT Folks,
I'm pleased to announce the 3.8.13.14-rt28 stable release.
You can get this release via the git tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git
branch: v3.8-rt
Head SHA1: 4e356430b57e27543c552b19adf7cb0ce37197d3
Or to build 3.8.13.14-rt28 directly, the following patches should be applied:
http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.8.tar.xz
http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.8.13.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/stable/patch-3.8.13.14.xz
http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/patch-3.8.13.14-rt28.patch.xz
You can also build from 3.8.13.14-rt27 by applying the incremental patch:
http://www.kernel.org/pub/linux/kernel/projects/rt/3.8/incr/patch-3.8.13.14-rt27-rt28.patch.xz
Enjoy,
-- Steve
Changes from v3.8.13.14-rt27:
---
Nicholas Mc Guire (1):
net: ip_send_unicast_reply: add missing local serialization
Paul E. McKenney (1):
rcu: Eliminate softirq processing from rcutree
Sebastian Andrzej Siewior (3):
Revert "x86: Disable IST stacks for debug/int 3/stack fault for
PREEMPT_RT"
kernel/hrtimer: be non-freezeable in cpu_chill()
arm/unwind: use a raw_spin_lock
Steven Rostedt (1):
rt: Make cpu_chill() use hrtimer instead of msleep()
Steven Rostedt (Red Hat) (1):
Linux 3.8.13.14-rt28
Tiejun Chen (1):
rcutree/rcu_bh_qs: disable irq while calling rcu_preempt_qs()
arch/arm/kernel/unwind.c | 14 ++--
arch/x86/include/asm/page_64_types.h | 21 ++
arch/x86/kernel/cpu/common.c | 2 -
arch/x86/kernel/dumpstack_64.c | 4 --
include/linux/delay.h| 2 +-
kernel/hrtimer.c | 19 +
kernel/rcutree.c | 119 +++
kernel/rcutree.h | 3 +-
kernel/rcutree_plugin.h | 133 ---
localversion-rt | 2 +-
net/ipv4/ip_output.c | 9 ++-
11 files changed, 159 insertions(+), 169 deletions(-)
---
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..bbafc67 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -87,7 +87,7 @@ extern const struct unwind_idx __start_unwind_idx[];
static const struct unwind_idx *__origin_unwind_idx;
extern const struct unwind_idx __stop_unwind_idx[];
-static DEFINE_SPINLOCK(unwind_lock);
+static DEFINE_RAW_SPINLOCK(unwind_lock);
static LIST_HEAD(unwind_tables);
/* Convert a prel31 symbol to an absolute address */
@@ -195,7 +195,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned
long addr)
/* module unwind tables */
struct unwind_table *table;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_for_each_entry(table, _tables, list) {
if (addr >= table->begin_addr &&
addr < table->end_addr) {
@@ -207,7 +207,7 @@ static const struct unwind_idx *unwind_find_idx(unsigned
long addr)
break;
}
}
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
}
pr_debug("%s: idx = %p\n", __func__, idx);
@@ -469,9 +469,9 @@ struct unwind_table *unwind_table_add(unsigned long start,
unsigned long size,
tab->begin_addr = text_addr;
tab->end_addr = text_addr + text_size;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_add_tail(>list, _tables);
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
return tab;
}
@@ -483,9 +483,9 @@ void unwind_table_del(struct unwind_table *tab)
if (!tab)
return;
- spin_lock_irqsave(_lock, flags);
+ raw_spin_lock_irqsave(_lock, flags);
list_del(>list);
- spin_unlock_irqrestore(_lock, flags);
+ raw_spin_unlock_irqrestore(_lock, flags);
kfree(tab);
}
diff --git a/arch/x86/include/asm/page_64_types.h
b/arch/x86/include/asm/page_64_types.h
index 65b85f4..320f7bb 100644
--- a/arch/x86/include/asm/page_64_types.h
+++ b/arch/x86/include/asm/page_64_types.h
@@ -14,21 +14,12 @@
#define IRQ_STACK_ORDER 2
#define IRQ_STACK_SIZE (PAGE_SIZE << IRQ_STACK_ORDER)
-#ifdef CONFIG_PREEMPT_RT_FULL
-# define STACKFAULT_STACK 0
-# define DOUBLEFAULT_STACK 1
-# define NMI_STACK 2
-# define DEBUG_STACK 0
-# define MCE_STACK 3
-# define N_EXCEPTION_STACKS 3 /* hw limit: 7 */
-#else
-# define STACKFAULT_STACK 1
-# define DOUBLEFAULT_STACK 2
-# define NMI_STACK 3
-# define DEBUG_STACK 4
-# define MCE_STACK 5
-# define N_EXCEPTION_STACKS 5 /* hw limit: 7 */
-#endif
+#define STACKFAULT_STACK 1
+#define
Re: [PATCH] i2c: mv64xxx: Fix compilation breakage
On Fri, Mar 07, 2014 at 06:29:49PM +0100, Wolfram Sang wrote: > > > > Another question is... why do we need to check pd->dev.of_node here? > > > If CONFIG_RESET_CONTROLLER is set, we always try to get the reset > > > controller node, so drv_data->rstc is either going to be a valid > > > pointer, or it's going to be an error pointer - neither > > > reset_control_get() nor devm_reset_control_get return NULL. > > > > Hmmm, right. I'll fix this in a later version. > > > > Wolfram, do you want me to respin the patch making use of > > reset_get_optional introduced by Philip in its other mail? > > I think I'd prefer both issues fixed with one patch like in "fixing up > reset controller handling". You mean the of_node check and the use of reset_control_get_optional, right? > And you might want to give a Tested- or Reviewed-by tag to Philipp's > patch if you are going to use it. Yes, I will. I'll only have access to the hardware on monday though, so I won't be able to actually test it before then. Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] input: Use platform-provided devices as i8042 serio parents
Hi Matthew, On Sun, Feb 23, 2014 at 12:03:16PM -0500, Matthew Garrett wrote: > i8042 devices exposed via platform firmware interfaces such as ACPI or > Device Tree may provide additional information of use to userspace. Right > now we don't associate the serio devices with the firmware device, and so > there's no straightforward way for userspace to make use of that > information. This patch simply moves the serio parent device to the firmware > provided device. Hmm, are we sure it will not mess up power management now that children serio ports are disconnected from i8042 device? I also wonder if we need to restructure the whole thing so that we create AUX and KBD ports separately and convert i8042 code into a library of sorts... Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86: Do not disable preemption in int3 on 32bit
From: Steven Rostedt
Preemption must be disabled before enabling interrupts in do_trap
on x86_64 because the stack in use for int3 and debug is a per CPU
stack set by th IST. But 32bit does not have an IST and the stack
still belongs to the current task and there is no problem in scheduling
out the task.
Keep preemption enabled on X86_32 when enabling interrupts for
do_trap().
The name of the function is changed from preempt_conditional_sti/cli()
to conditional_sti/cli_ist(), to annotate that this function is used
when the stack is on the IST.
Signed-off-by: Steven Rostedt
Signed-off-by: Thomas Gleixner
Signed-off-by: Sebastian Andrzej Siewior
---
arch/x86/kernel/traps.c | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 57409f6..48dab0c 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -86,9 +86,21 @@ static inline void conditional_sti(struct pt_regs *regs)
local_irq_enable();
}
-static inline void preempt_conditional_sti(struct pt_regs *regs)
+static inline void conditional_sti_ist(struct pt_regs *regs)
{
+#ifdef CONFIG_X86_64
+ /*
+* X86_64 uses a per CPU stack on the IST for certain traps
+* like int3. The task can not be preempted when using one
+* of these stacks, thus preemption must be disabled, otherwise
+* the stack can be corrupted if the task is scheduled out,
+* and another task comes in and uses this stack.
+*
+* On x86_32 the task keeps its own stack and it is OK if the
+* task schedules out.
+*/
preempt_count_inc();
+#endif
if (regs->flags & X86_EFLAGS_IF)
local_irq_enable();
}
@@ -99,11 +111,13 @@ static inline void conditional_cli(struct pt_regs *regs)
local_irq_disable();
}
-static inline void preempt_conditional_cli(struct pt_regs *regs)
+static inline void conditional_cli_ist(struct pt_regs *regs)
{
if (regs->flags & X86_EFLAGS_IF)
local_irq_disable();
+#ifdef CONFIG_X86_64
preempt_count_dec();
+#endif
}
static int __kprobes
@@ -232,9 +246,9 @@ dotraplinkage void do_stack_segment(struct pt_regs *regs,
long error_code)
prev_state = exception_enter();
if (notify_die(DIE_TRAP, "stack segment", regs, error_code,
X86_TRAP_SS, SIGBUS) != NOTIFY_STOP) {
- preempt_conditional_sti(regs);
+ conditional_sti_ist(regs);
do_trap(X86_TRAP_SS, SIGBUS, "stack segment", regs, error_code,
NULL);
- preempt_conditional_cli(regs);
+ conditional_cli_ist(regs);
}
exception_exit(prev_state);
}
@@ -343,9 +357,9 @@ dotraplinkage void __kprobes notrace do_int3(struct pt_regs
*regs, long error_co
* as we may switch to the interrupt stack.
*/
debug_stack_usage_inc();
- preempt_conditional_sti(regs);
+ conditional_sti_ist(regs);
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL);
- preempt_conditional_cli(regs);
+ conditional_cli_ist(regs);
debug_stack_usage_dec();
exit:
exception_exit(prev_state);
@@ -451,12 +465,12 @@ dotraplinkage void __kprobes do_debug(struct pt_regs
*regs, long error_code)
debug_stack_usage_inc();
/* It's safe to allow irq's after DR6 has been saved */
- preempt_conditional_sti(regs);
+ conditional_sti_ist(regs);
if (regs->flags & X86_VM_MASK) {
handle_vm86_trap((struct kernel_vm86_regs *) regs, error_code,
X86_TRAP_DB);
- preempt_conditional_cli(regs);
+ conditional_cli_ist(regs);
debug_stack_usage_dec();
goto exit;
}
@@ -476,7 +490,7 @@ dotraplinkage void __kprobes do_debug(struct pt_regs *regs,
long error_code)
si_code = get_si_code(tsk->thread.debugreg6);
if (tsk->thread.debugreg6 & (DR_STEP | DR_TRAP_BITS) || user_icebp)
send_sigtrap(tsk, regs, error_code, si_code);
- preempt_conditional_cli(regs);
+ conditional_cli_ist(regs);
debug_stack_usage_dec();
exit:
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/5] arch: atomic rework
On Wed, 2014-03-05 at 10:01 -0800, Paul E. McKenney wrote:
> On Wed, Mar 05, 2014 at 05:26:36PM +0100, Torvald Riegel wrote:
> > xagsmtp3.20140305162928.8...@uk1vsc.vnet.ibm.com
> > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP3 at UK1VSC)
> >
> > On Tue, 2014-03-04 at 11:00 -0800, Paul E. McKenney wrote:
> > > On Mon, Mar 03, 2014 at 09:46:19PM +0100, Torvald Riegel wrote:
> > > > xagsmtp2.20140303204700.3...@vmsdvma.vnet.ibm.com
> > > > X-Xagent-Gateway: vmsdvma.vnet.ibm.com (XAGSMTP2 at VMSDVMA)
> > > >
> > > > On Mon, 2014-03-03 at 11:20 -0800, Paul E. McKenney wrote:
> > > > > On Mon, Mar 03, 2014 at 07:55:08PM +0100, Torvald Riegel wrote:
> > > > > > xagsmtp2.20140303190831.9...@uk1vsc.vnet.ibm.com
> > > > > > X-Xagent-Gateway: uk1vsc.vnet.ibm.com (XAGSMTP2 at UK1VSC)
> > > > > >
> > > > > > On Fri, 2014-02-28 at 16:50 -0800, Paul E. McKenney wrote:
> > > > > > > +oDo not use the results from the boolean "&&" and "||"
> > > > > > > when
> > > > > > > + dereferencing. For example, the following (rather improbable)
> > > > > > > + code is buggy:
> > > > > > > +
> > > > > > > + int a[2];
> > > > > > > + int index;
> > > > > > > + int force_zero_index = 1;
> > > > > > > +
> > > > > > > + ...
> > > > > > > +
> > > > > > > + r1 = rcu_dereference(i1)
> > > > > > > + r2 = a[r1 && force_zero_index]; /* BUGGY!!! */
> > > > > > > +
> > > > > > > + The reason this is buggy is that "&&" and "||" are often
> > > > > > > compiled
> > > > > > > + using branches. While weak-memory machines such as ARM or
> > > > > > > PowerPC
> > > > > > > + do order stores after such branches, they can speculate loads,
> > > > > > > + which can result in misordering bugs.
> > > > > > > +
> > > > > > > +oDo not use the results from relational operators ("==",
> > > > > > > "!=",
> > > > > > > + ">", ">=", "<", or "<=") when dereferencing. For example,
> > > > > > > + the following (quite strange) code is buggy:
> > > > > > > +
> > > > > > > + int a[2];
> > > > > > > + int index;
> > > > > > > + int flip_index = 0;
> > > > > > > +
> > > > > > > + ...
> > > > > > > +
> > > > > > > + r1 = rcu_dereference(i1)
> > > > > > > + r2 = a[r1 != flip_index]; /* BUGGY!!! */
> > > > > > > +
> > > > > > > + As before, the reason this is buggy is that relational operators
> > > > > > > + are often compiled using branches. And as before, although
> > > > > > > + weak-memory machines such as ARM or PowerPC do order stores
> > > > > > > + after such branches, but can speculate loads, which can again
> > > > > > > + result in misordering bugs.
> > > > > >
> > > > > > Those two would be allowed by the wording I have recently proposed,
> > > > > > AFAICS. r1 != flip_index would result in two possible values
> > > > > > (unless
> > > > > > there are further constraints due to the type of r1 and the values
> > > > > > that
> > > > > > flip_index can have).
> > > > >
> > > > > And I am OK with the value_dep_preserving type providing more/better
> > > > > guarantees than we get by default from current compilers.
> > > > >
> > > > > One question, though. Suppose that the code did not want a value
> > > > > dependency to be tracked through a comparison operator. What does
> > > > > the developer do in that case? (The reason I ask is that I have
> > > > > not yet found a use case in the Linux kernel that expects a value
> > > > > dependency to be tracked through a comparison.)
> > > >
> > > > Hmm. I suppose use an explicit cast to non-vdp before or after the
> > > > comparison?
> > >
> > > That should work well assuming that things like "if", "while", and "?:"
> > > conditions are happy to take a vdp.
> >
> > I currently don't see a reason why that should be disallowed. If we
> > have allowed an implicit conversion to non-vdp, I believe that should
> > follow.
>
> I am a bit nervous about a silent implicit conversion from vdp to
> non-vdp in the general case.
Why are you nervous about it?
> However, when the result is being used by
> a conditional, the silent implicit conversion makes a lot of sense.
> Is that distinction something that the compiler can handle easily?
I think so. I'm not a language lawyer, but we have other such
conversions in the standard (e.g., int to boolean, between int and
float) and I currently don't see a fundamental difference to those. But
we'll have to ask the language folks (or SG1 or LEWG) to really verify
that.
> On the other hand, silent implicit conversion from non-vdp to vdp
> is very useful for common code that can be invoked both by RCU
> readers and by updaters.
I'd be more nervous about that because then there's less obstacles to
one programmer expecting a vdp to indicate a dependency vs. another
programmer putting non-vdp into vdp.
For this case of common code (which I agree is a valid concern), would
it be a lot of programmer overhead to add explicit casts from non-vdp to
vdp?
Re: [PATCH v6] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
On Friday 07 March 2014 11:10 PM, Felipe Balbi wrote: On Fri, Mar 07, 2014 at 11:09:02PM +0530, Kishon Vijay Abraham I wrote: On Friday 07 March 2014 10:20 PM, Felipe Balbi wrote: On Fri, Mar 07, 2014 at 10:18:08PM +0530, Kishon Vijay Abraham I wrote: No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/. Also removed the unused members of struct omap_usb (after phy-omap-pipe3 started using it's own header file) does this depend in any other patch ? I get the following when applying *only* this patch on top of v3.14-rc5: yeah.. this is for linux-phy tree. I'll take this patch. looks like you're doing two things at once (renaming the header and removing some unnecessary fields). At least mention the second thing. The second line of the commit message mentions just that ;-) Regards Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V1 2/2] input: misc: da9063: OnKey driver
Hi Steve,
On Fri, Mar 07, 2014 at 12:37:45PM +, Opensource [Steve Twiss] wrote:
> From: Opensource [Steve Twiss]
>
> Add the OnKey driver for DA9063.
>
>
> Signed-off-by: Opensource [Steve Twiss]
> ---
> Checks performed with next-20140307/scripts/checkpatch.pl
> da9063-onkey.ctotal: 0 errors, 0 warnings, 202 lines checked
> Kconfig total: 0 errors, 11 warnings, 679 lines checked
> Makefile total: 0 errors, 0 warnings, 66 lines checked
>
> Hello,
>
> This is a RFC for the Dialog DA9063 Onkey driver.
>
> Dependencies:
>
> This driver makes use of the name field "ONKEY" as part of the
> function call: platform_get_irq_byname();
>
> This driver is therefore dependent on this change to the name field
> in the properties of the the OnKey IORESOURCE_IRQ resource structure
> (part of the mfd_cell Onkey resource inside da9063-core.c). This
> change will be added as part of the final set when I submit all patches
> as a single PATCH set.
>
> This patch applies against kernel version linux-next next-20140307
>
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
>
>
>
> drivers/input/misc/Kconfig| 10 ++
> drivers/input/misc/Makefile |1 +
> drivers/input/misc/da9063-onkey.c | 202
> +
> 3 files changed, 213 insertions(+)
> create mode 100644 drivers/input/misc/da9063-onkey.c
>
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 762e6d2..3deb008 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -522,6 +522,16 @@ config INPUT_DA9055_ONKEY
> To compile this driver as a module, choose M here: the module
> will be called da9055_onkey.
>
> +config INPUT_DA9063_ONKEY
> + tristate "Dialog DA9063 OnKey"
> + depends on MFD_DA9063
> + help
> + Support the ONKEY of Dialog DA9063 Power Management IC as an
> + input device reporting power button statue.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called da9063-onkey.
> +
> config INPUT_DM355EVM
> tristate "TI DaVinci DM355 EVM Keypad and IR Remote"
> depends on MFD_DM355EVM_MSP
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index cda71fc..f40caa7 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_INPUT_CMA3000_I2C) +=
> cma3000_d0x_i2c.o
> obj-$(CONFIG_INPUT_COBALT_BTNS) += cobalt_btns.o
> obj-$(CONFIG_INPUT_DA9052_ONKEY) += da9052_onkey.o
> obj-$(CONFIG_INPUT_DA9055_ONKEY) += da9055_onkey.o
> +obj-$(CONFIG_INPUT_DA9063_ONKEY) += da9063-onkey.o
> obj-$(CONFIG_INPUT_DM355EVM) += dm355evm_keys.o
> obj-$(CONFIG_INPUT_GP2A) += gp2ap002a00f.o
> obj-$(CONFIG_INPUT_GPIO_BEEPER) += gpio-beeper.o
> diff --git a/drivers/input/misc/da9063-onkey.c
> b/drivers/input/misc/da9063-onkey.c
> new file mode 100644
> index 000..654f52b
> --- /dev/null
> +++ b/drivers/input/misc/da9063-onkey.c
> @@ -0,0 +1,202 @@
> +/* da9063-onkey.c - Onkey device driver for DA9063
> + * Copyright (C) 2013 Dialog Semiconductor Ltd.
> + *
> + * This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Library General Public
> + * License as published by the Free Software Foundation; either
> + * version 2 of the License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Library General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +struct da9063_onkey {
> + struct da9063 *hw;
> + struct delayed_work work;
> + struct input_dev *input;
> + bool key_power;
> +};
> +
> +static void da9063_poll_on(struct work_struct *work)
> +{
> + struct da9063_onkey *onkey = container_of(work, struct da9063_onkey,
> + work.work);
> + unsigned int val;
> + int poll = 1;
Please use booleans for boolean data:
bool poll = true;
> + int ret;
> +
> + /* poll to see when the pin is deasserted */
> + ret = regmap_read(onkey->hw->regmap, DA9063_REG_STATUS_A, );
> +
Re: [PATCH v6] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
On Fri, Mar 07, 2014 at 11:09:02PM +0530, Kishon Vijay Abraham I wrote: > On Friday 07 March 2014 10:20 PM, Felipe Balbi wrote: > >On Fri, Mar 07, 2014 at 10:18:08PM +0530, Kishon Vijay Abraham I wrote: > >>No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/. > >>Also removed the unused members of struct omap_usb (after phy-omap-pipe3 > >>started using it's own header file) > > > >does this depend in any other patch ? I get the following when applying > >*only* this patch on top of v3.14-rc5: > > yeah.. this is for linux-phy tree. I'll take this patch. looks like you're doing two things at once (renaming the header and removing some unnecessary fields). At least mention the second thing. cheers -- balbi signature.asc Description: Digital signature
Re: Enhancement for PLE handler in KVM
On Fri, Mar 07, 2014 at 02:26:19PM +, Li, Bin (Bin) wrote: > Can we have "per-VM PLE values"? > > My understanding is that the ple values are kvm module setting which applying > to all VMs in the system. > And all vms must be stopped first, then unload kvm-intel, reload kvm-intel > with new ple setting. > > /sbin/modprobe -r kvm-intel > /sbin/modprobe kvm-intel ple_window=16384 > > Regards > Bin Yes, but it can be made per-VM (its a VMCS field). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/8] of: Reduce indentation in of_graph_get_next_endpoint
Hi Laurent, Am Freitag, den 07.03.2014, 01:12 +0100 schrieb Laurent Pinchart: > Hi Philipp, > > Thank you for the patch. > > I've submitted a fix for the of_graph_get_next_endpoint() function, but it > hasn't been applied yet due to the patch series that contained it needing > more > work. > > The patch is available at https://patchwork.linuxtv.org/patch/21946/. I can > rebase it on top of this series, but I still wanted to let you know about it > in case you would like to integrate it. Thank you for the pointer. A pity about the timing, this will mostly revert my indentation patch. I'd be glad if you could rebase on top of the merged series. While we look at of_graph_get_next_endpoint(), could you explain the reason behind the extra reference count increase on the prev node: /* * Avoid dropping prev node refcount to 0 when getting the next * child below. */ of_node_get(prev); This unfortunately makes using the function in for_each style macros a hassle. If that part wasn't there and all users that want to keep using prev after the call were expected to increase refcount themselves, we could have a #define of_graph_for_each_endpoint(parent, endpoint) \ for (endpoint = of_graph_get_next_endpoint(parent, NULL); \ endpoint != NULL; \ endpoint = of_graph_get_next_endpoint(parent, endpoint)) regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
On Friday 07 March 2014 10:20 PM, Felipe Balbi wrote:
On Fri, Mar 07, 2014 at 10:18:08PM +0530, Kishon Vijay Abraham I wrote:
No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)
does this depend in any other patch ? I get the following when applying
*only* this patch on top of v3.14-rc5:
yeah.. this is for linux-phy tree. I'll take this patch.
Thanks
Kishon
drivers/phy/phy-omap-usb2.c: In function ‘omap_usb2_suspend’:
drivers/phy/phy-omap-usb2.c:106:21: error: ‘struct omap_usb’ has no member
named ‘is_suspended’
if (suspend && !phy->is_suspended) {
^
drivers/phy/phy-omap-usb2.c:109:6: error: ‘struct omap_usb’ has no member named
‘is_suspended’
phy->is_suspended = 1;
^
drivers/phy/phy-omap-usb2.c:110:28: error: ‘struct omap_usb’ has no member
named ‘is_suspended’
} else if (!suspend && phy->is_suspended) {
^
drivers/phy/phy-omap-usb2.c:117:6: error: ‘struct omap_usb’ has no member named
‘is_suspended’
phy->is_suspended = 0;
^
drivers/phy/phy-omap-usb2.c: In function ‘omap_usb2_probe’:
drivers/phy/phy-omap-usb2.c:194:5: error: ‘struct omap_usb’ has no member named
‘is_suspended’
phy->is_suspended = 1;
^
make[1]: *** [drivers/phy/phy-omap-usb2.o] Error 1
make: *** [drivers/phy/] Error 2
make: *** Waiting for unfinished jobs
CC [M] drivers/usb/phy/phy-mxs-usb.o
drivers/usb/phy/phy-omap-usb3.c:22:32: fatal error: linux/usb/omap_usb.h: No
such file or directory
#include
^
compilation terminated.
make[1]: *** [drivers/usb/phy/phy-omap-usb3.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [drivers/usb/phy/] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v2 5/5] Staging: comedi: addi-data: tidy up counter register map defines in hwdrv_apci1564.c
On Friday, March 07, 2014 1:38 AM, Chase Southwood wrote: > This patch fixes the register map defines for the counter registers such > that they are all the real offsets to each register, rather than a mix of > real offsets and adders to those offsets. > > Signed-off-by: Chase Southwood > --- > > 2: Simplified commit message, fixed indentation and whitespace damage. > I have test applied this patch, it should work now. > v2 also fixes several build breakages, and I have compile tested as well. > Everything should be fixed. Chase, Looks better, the patches apply now. The register map whitespace is still a bit of a mess. This is what it looks like after applying all 5 patches: /* * devpriv->i_IobaseAmcc Register Map */ #define APCI1564_DI_REG 0x04 #define APCI1564_DI_INT_MODE1_REG 0x08 #define APCI1564_DI_INT_MODE2_REG 0x0c #define APCI1564_DI_INT_STATUS_REG 0x10 #define APCI1564_DI_IRQ_REG 0x14 #define APCI1564_DO_REG 0x18 #define APCI1564_DO_INT_CTRL_REG0x1c #define APCI1564_DO_INT_STATUS_REG 0x20 #define APCI1564_DO_IRQ_REG 0x24 #define APCI1564_WDOG_REG 0x28 #define APCI1564_WDOG_RELOAD_REG0x2c #define APCI1564_WDOG_TIMEBASE_REG 0x30 #define APCI1564_WDOG_CTRL_REG 0x34 #define APCI1564_WDOG_STATUS_REG0x38 #define APCI1564_WDOG_IRQ_REG 0x3c #define APCI1564_WDOG_WARN_TIMEVAL_REG 0x40 #define APCI1564_WDOG_WARN_TIMEBASE_REG 0x44 #define APCI1564_TIMER_REG 0x48 #define APCI1564_TIMER_RELOAD_REG 0x4c #define APCI1564_TIMER_TIMEBASE_REG 0x50 #define APCI1564_TIMER_CTRL_REG 0x54 #define APCI1564_TIMER_STATUS_REG 0x58 #define APCI1564_TIMER_IRQ_REG 0x5c #define APCI1564_TIMER_WARN_TIMEVAL_REG 0x60 #define APCI1564_TIMER_WARN_TIMEBASE_REG0x64 /* * devpriv->iobase Register Map */ #define APCI1564_TCW_REG(x) (0x00 + ((x) * 0x20)) #define APCI1564_TCW_RELOAD_REG(x) (0x04 + ((x) * 0x20)) #define APCI1564_TCW_TIMEBASE_REG(x)(0x08 + ((x) * 0x20)) #define APCI1564_TCW_CTRL_REG(x)(0x0c + ((x) * 0x20)) #define APCI1564_TCW_STATUS_REG(x) (0x10 + ((x) * 0x20)) #define APCI1564_TCW_IRQ_REG(x) (0x14 + ((x) * 0x20)) #define APCI1564_TCW_WARN_TIMEVAL_REG(x)(0x18 + ((x) * 0x20)) #define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20)) Check your tab settings in your editor. Normal tab spacing is 8 characters. It looks like all the defines align properly at column 49 which is one tab after the define on this line: #define APCI1564_TCW_WARN_TIMEBASE_REG(x) (0x1c + ((x) * 0x20)) Other than that the patches look good. Regards, Hartley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On Fri, Mar 7, 2014 at 4:29 AM, Zoltan Kiss wrote: > On 07/03/14 04:46, Pravin Shelar wrote: >> >> On Thu, Mar 6, 2014 at 9:09 AM, Zoltan Kiss >> wrote: >>> >>> Do you have any feedback on this? I'm also adding KVM list as they might >>> be >>> interested in this. >>> >>> Zoli >>> >>> >>> On 28/02/14 19:16, Zoltan Kiss wrote: The kernel datapath now switched to zerocopy Netlink messages, but that also means that the pages on frags array are sent straight to userspace. If those pages came outside the kernel, we have to swap them out with local copies. Signed-off-by: Zoltan Kiss >> >> >> I do not think this is required, netlink zero copy only maps >> pre-allocated buffers to user-space. > > How do you mean "pre-allocated"? By who? > by netlink, ref. netlink_alloc_skb(). > As far as I've seen the skb in this function came straight from the device > (vif in our case), and skb_zerocopy just copy the frags to user_skb, which > is sent to the userspace. Those frags contain pages from guest, and it's a > bad idea to pass them to userspace: e.g if userspace dies in the meantime, > what happens with them? Also, in Xen's case they are actually not mapped to > userspace, so accessing them can lead to garbage. > AFAIK Netlink does not handle skb-frags for zero-copy case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v15 3/3] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose
PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
arch/arm64/boot/dts/apm-storm.dtsi | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi
b/arch/arm64/boot/dts/apm-storm.dtsi
index d37d736..c78ddcf 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -176,6 +176,51 @@
reg-names = "csr-reg";
clock-output-names = "eth8clk";
};
+
+ sataphy1clk: sataphy1clk@1f21c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f21c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy1clk";
+ status = "disabled";
+ csr-offset = <0x4>;
+ csr-mask = <0x00>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
+
+ sataphy2clk: sataphy1clk@1f22c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f22c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy2clk";
+ status = "ok";
+ csr-offset = <0x4>;
+ csr-mask = <0x3a>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
+
+ sataphy3clk: sataphy1clk@1f23c000 {
+ compatible = "apm,xgene-device-clock";
+ #clock-cells = <1>;
+ clocks = < 0>;
+ clock-names = "socplldiv2";
+ reg = <0x0 0x1f23c000 0x0 0x1000>;
+ reg-names = "csr-reg";
+ clock-output-names = "sataphy3clk";
+ status = "ok";
+ csr-offset = <0x4>;
+ csr-mask = <0x3a>;
+ enable-offset = <0x0>;
+ enable-mask = <0x06>;
+ };
};
serial0: serial@1c02 {
@@ -187,5 +232,35 @@
interrupt-parent = <>;
interrupts = <0x0 0x4c 0x4>;
};
+
+ phy1: phy@1f21a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f21a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = < 0>;
+ status = "disabled";
+ apm,tx-boost-gain = <30 30 30 30 30 30>;
+ apm,tx-eye-tuning = <2 10 10 2 10 10>;
+ };
+
+ phy2: phy@1f22a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f22a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = < 0>;
+ status = "ok";
+ apm,tx-boost-gain = <30 30 30 30 30 30>;
+ apm,tx-eye-tuning = <1 10 10 2 10 10>;
+ };
+
+ phy3: phy@1f23a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f23a000 0x0 0x100>;
+ #phy-cells = <1>;
+ clocks = < 0>;
+ status = "ok";
+ apm,tx-boost-gain = <31 31 31 31 31 31>;
+ apm,tx-eye-tuning = <2 10 10 2 10 10>;
+ };
};
};
--
1.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: mv64xxx: Fix compilation breakage
> > Another question is... why do we need to check pd->dev.of_node here? > > If CONFIG_RESET_CONTROLLER is set, we always try to get the reset > > controller node, so drv_data->rstc is either going to be a valid > > pointer, or it's going to be an error pointer - neither > > reset_control_get() nor devm_reset_control_get return NULL. > > Hmmm, right. I'll fix this in a later version. > > Wolfram, do you want me to respin the patch making use of > reset_get_optional introduced by Philip in its other mail? I think I'd prefer both issues fixed with one patch like in "fixing up reset controller handling". And you might want to give a Tested- or Reviewed-by tag to Philipp's patch if you are going to use it. signature.asc Description: Digital signature
[PATCH v15 0/3] PHY: Add APM X-Gene SoC 15Gbps Multi-purpose PHY support
This patch adds support for APM X-Gene SoC 15Gbps Multi-purpose PHY. This is the physical layer interface for the corresponding host controller. This driver uses the PHY generic framework. v15: * Fix all check patch warning and re-run checkpatch to confirm v14: * Fix function xgene_phy_xlate to check valid mode and parameter count * Clean up probe function on error checking v13: * Remove PHY patch for initial version as only Gen3 speed is supported * Remove function xgene_phy_sata_force_gen and xgene_phy_set_speed * Minor comment update to header and function xgene_phy_hw_init v12: * Add driver depend on HAS_IOMEM and OF * Fix comment typo in header file phy-xgene. * Change all macro shift value in hex to decimal * Add time out for while loop to function sds_wr and sds_rd * Set proper return value if failed to get IO resource 0 * Move devm_of_phy_provider_register to last operation in probe function * Remove driver registration print statement * Replace module init/exit with module_platform_driver * Change license to GPL v2 v11: * Add comment to function phy_set_speed * Add commit log for documentation patch file * Minor comment update to function xgene_phy_force_lat_summer_cal and xgene_phy_sata_force_gen v10 * Update comment for function xgene_phy_force_lat_summer_cal and xgene_phy_sata_force_gen with function style fully-winged style v9 * Update CMU parameter setting for register 13 * Add required delay when configure CMU PLL, Manual Calibration PLL, and VCO PLL * Add comment for CMU PLL calibration loop delay of 10us * Add required delay for stopping and starting summer calibrations * Update comment for summer and latch calibration delays * Update comment for PHY reset Rx delay and decrease max sleep time from 500 to 150us * Always program the DFE (equalizer) setting to 0x7e00 as with original version * Fix Tx speed selection to always using Gen3 setting when force to an specified generation speed v8 * Update binding documentation * Remove XGENE_PHY_DTS and XGENE_PHY_EXT_DTS defines * Remove support for internal clock * Remove support for external reference CMU * Remove the need for external reference resource DTS entry and its related code v7 * Add/Update PHY CMU/lane parameters and its default values * Rename variable enable_manual_cal to preA3Chip * Remove function phy_rd, phy_wr, and phy_wr_flush * Change function cmu_wr, cmu_rd, cmu_toggle1to0, cmu_clrbits, cmu_setbits, serdes_wr, serdes_rd, serdes_clrbits, and serdes_setbits to take context instead void * * Remove function serdes_toggle1to0 * Decrease the polling time from 10ms to 1ms on CMU calibration complete detection * Move all SATA specify code in function xgene_phy_hw_initialize into function xgene_phy_hw_init_sata * Add usleep_range after starting summer/latch calibrations * Add usleep_range between receiver reset (function xgene_phy_reset_rxd) * Save and restore PHY register 31 instead writing 0 in function xgene_phy_gen_avg_val * Update function xgene_phy_sata_force_gen programming sequences * Add support to reset the receiver lane in function xgene_phy_set_speed if speed is 0 * Update PHY parameters in DTS per controller * Some minor code clean up v6 * Move PHY document to Documentation/devicetree/binding/phy * Remove _ADDR from all register defines * Update clock-names property for sataphy1clk, sataphy2clk, and sataphy3clk v5 * Update DTS binding documentation * Remove direct clock access and use clock interface instead * Change override parameters to decimal instead hex values * Change apm,tx-amplitude, apm,tx-pre-cursor1, apm,tx-pre-cursor2, apm,tx-post-cursor to be unit of uV v4 * Update documentation with 'apm,' instead 'apm-' * Change DTS override parameter to have 'apm,' * Add select GENERIC_PHY to Kconfig PHY_XGENE * Make override parameters to be pair of three values instead one * Some minor comment and indentation changes * Remove error register addition offset * Add ULL to constants * Use module_init instead subsys_initcall * Make DTS node based on first register address * Update override setting values v3 * Major re-write of the code based on various review comments * Support external clock only at the moment * Support SATA mode only at the moment * No UEFI support at the moment v2 * Remove port knowledge from functions * Make all functions static * Remove ID completely * Make resource requirement based on compatible type * Rename override PHY parameters with more descriptive name * Add override PHY parameter for per controller, per port, and per speed * Patch the generic PHY frame to expose set_speed operation v1 * Initial version Signed-off-by: Loc Ho Signed-off-by: Tuan Phan Signed-off-by: Suman Tripathi --- Loc Ho (3): Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation PHY: add APM X-Gene SoC 15Gbps Multi-purpose PHY driver arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On Fri, Mar 7, 2014 at 8:23 AM, Thomas Graf wrote:
> On 02/28/2014 08:16 PM, Zoltan Kiss wrote:
>>
>> The kernel datapath now switched to zerocopy Netlink messages, but that
>> also
>> means that the pages on frags array are sent straight to userspace. If
>> those
>> pages came outside the kernel, we have to swap them out with local copies.
>>
>> Signed-off-by: Zoltan Kiss
>> ---
>> net/openvswitch/datapath.c |6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
>> index 36f8872..ffb563c 100644
>> --- a/net/openvswitch/datapath.c
>> +++ b/net/openvswitch/datapath.c
>> @@ -464,6 +464,12 @@ static int queue_userspace_packet(struct datapath
>> *dp, struct sk_buff *skb,
>> }
>> nla->nla_len = nla_attr_size(skb->len);
>>
>> + if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC))) {
>> + err = -ENOMEM;
>> + skb_tx_error(skb);
>> + goto out;
>> + }
>> +
>> skb_zerocopy(user_skb, skb, skb->len, hlen);
>>
>> /* Pad OVS_PACKET_ATTR_PACKET if linear copy was performed */
>
>
> How about we move the call to skb_orphan_frags() into skb_zerocopy()
> itself and call it before we actually reference the frags?
>
Problem is mapping SKBTX_DEV_ZEROCOPY pages to userspace. skb_zerocopy
is not doing that.
Unless I missing something, Current netlink code can not handle
skb-frags with zero copy. So we have to copy skb anyways and no need
to orphan-frags here.
If you are planning on handling skb-frags without copying then
skb_orphan_frags should be done in netlink.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v15 1/3] Documentation: Add APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding documentation
This patch adds the APM X-Gene SoC 15Gbps Multi-purpose PHY driver binding
documentation.
Signed-off-by: Loc Ho
Signed-off-by: Tuan Phan
Signed-off-by: Suman Tripathi
---
.../devicetree/bindings/phy/apm-xgene-phy.txt | 79
1 files changed, 79 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
new file mode 100644
index 000..5f3a65a
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
@@ -0,0 +1,79 @@
+* APM X-Gene 15Gbps Multi-purpose PHY nodes
+
+PHY nodes are defined to describe on-chip 15Gbps Multi-purpose PHY. Each
+PHY (pair of lanes) has its own node.
+
+Required properties:
+- compatible : Shall be "apm,xgene-phy".
+- reg : PHY memory resource is the SDS PHY access resource.
+- #phy-cells : Shall be 1 as it expects one argument for setting
+ the mode of the PHY. Possible values are 0 (SATA),
+ 1 (SGMII), 2 (PCIe), 3 (USB), and 4 (XFI).
+
+Optional properties:
+- status : Shall be "ok" if enabled or "disabled" if disabled.
+ Default is "ok".
+- clocks : Reference to the clock entry.
+- apm,tx-eye-tuning: Manual control to fine tune the capture of the serial
+ bit lines from the automatic calibrated position.
+ Two set of 3-tuple setting for each (up to 3)
+ supported link speed on the host. Range from 0 to
+ 127 in unit of one bit period. Default is 10.
+- apm,tx-eye-direction : Eye tuning manual control direction. 0 means sample
+ data earlier than the nominal sampling point. 1 means
+ sample data later than the nominal sampling point.
+ Two set of 3-tuple setting for each (up to 3)
+ supported link speed on the host. Default is 0.
+- apm,tx-boost-gain: Frequency boost AC (LSB 3-bit) and DC (2-bit)
+ gain control. Two set of 3-tuple setting for each
+ (up to 3) supported link speed on the host. Range is
+ between 0 to 31 in unit of dB. Default is 3.
+- apm,tx-amplitude : Amplitude control. Two set of 3-tuple setting for
+ each (up to 3) supported link speed on the host.
+ Range is between 0 to 199500 in unit of uV.
+ Default is 199500 uV.
+- apm,tx-pre-cursor1 : 1st pre-cursor emphasis taps control. Two set of
+ 3-tuple setting for each (up to 3) supported link
+ speed on the host. Range is 0 to 273000 in unit of
+ uV. Default is 0.
+- apm,tx-pre-cursor2 : 2st pre-cursor emphasis taps control. Two set of
+ 3-tuple setting for each (up to 3) supported link
+ speed on the host. Range is 0 to 127400 in unit uV.
+ Default is 0x0.
+- apm,tx-post-cursor : Post-cursor emphasis taps control. Two set of
+ 3-tuple setting for Gen1, Gen2, and Gen3. Range is
+ between 0 to 0x1f in unit of 18.2mV. Default is 0xf.
+- apm,tx-speed : Tx operating speed. One set of 3-tuple for each
+ supported link speed on the host.
+ 0 = 1-2Gbps
+ 1 = 2-4Gbps (1st tuple default)
+ 2 = 4-8Gbps
+ 3 = 8-15Gbps (2nd tuple default)
+ 4 = 2.5-4Gbps
+ 5 = 4-5Gbps
+ 6 = 5-6Gbps
+ 7 = 6-16Gbps (3rd tuple default)
+
+NOTE: PHY override parameters are board specific setting.
+
+Example:
+ phy1: phy@1f21a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f21a000 0x0 0x100>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
+
+ phy2: phy@1f22a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f22a000 0x0 0x100>;
+ #phy-cells = <1>;
+ status = "ok";
+ };
+
+ phy3: phy@1f23a000 {
+ compatible = "apm,xgene-phy";
+ reg = <0x0 0x1f23a000 0x0 0x100>;
+ #phy-cells = <1>;
+ status = "ok";
+ };
--
1.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH] net: inetfilter: LLVMLinux: vlais-netfilter
On Thu, Mar 06, 2014 at 11:56:08AM -0800, beh...@converseincode.com wrote: > From: Mark Charlebois > > Replaced non-standard C use of Variable Length Arrays In Structs (VLAIS) in > xt_repldata.h with a C99 compliant flexible array member and then calculated > offsets to the other struct members. These other members aren't referenced by > name in this code, however this patch maintains the same memory layout and > padding as was previously accomplished using VLAIS. > > Had the original structure been ordered differently, with the entries VLA at > the end, then it could have been a flexible member, and this patch would have > been a lot simpler. However since the data stored in this structure is > ultimately exported to userspace, the order of this structure can't be > changed. > > This patch makes no attempt to change the existing behavior, merely the way in > which the current layout is accomplished using standard C99 constructs. As > such > the code can now be compiled with either gcc or clang. I think we already agreed on not accepting macro tricks to get this compiling with clang: http://comments.gmane.org/gmane.comp.security.firewalls.netfilter.devel/45138 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i386: Remove unneeded test of 'task' in dump_trace() (again)
On Fri, Mar 7, 2014, at 16:52, Steven Rostedt wrote: > > Commit 028a690a1ebc8b "i386: Remove unneeded test of 'task' in dump_trace()" > correctly removed the unneeded 'task != NULL' check because it would > be set to current if it was NULL. > > Commit 2bc5f927d489 "i386: split out dumpstack code from traps_32.c" > moved the code from traps_32.c to its own file dump_stack.c for > preparation of the i386 / x86_64 merge. > > Commit 8a541665b906 "dumpstack: x86: various small unification steps" > worked to make i386 and x86_64 dump_stack logic similar. But this > actually reverted the correct change from 028a690a1ebc8b. > > Commit d0caf292505d "x86/dumpstack: Remove unneeded check in dump_trace()" > removed the unneeded "task != NULL" check for x86_64 but left that same > unneeded check for i386, that was added because x86_64 had it! > > This chain of events ironically had i386 add back the unneeded task != NULL > check because x86_64 did it, and then the fix for x86_64 was fixed > by Dan. And even more ironically, it was Dan's smatch bot that told > me that a change to dump_stack_32 I made may be wrong if current can > be NULL (it can't), as there was a check for it by assigning task to > current, and then checking if task is NULL. > > Reported-by: Dan Carpenter > Cc: Jesper Juhl > Cc: Alexander van Heukelum Great archeology ;) Acked-by: Alexander van Heukelum > Signed-off-by: Steven Rostedt > --- > arch/x86/kernel/dumpstack_32.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c > index dca820b..5abd4cd 100644 > --- a/arch/x86/kernel/dumpstack_32.c > +++ b/arch/x86/kernel/dumpstack_32.c > @@ -53,7 +53,7 @@ void dump_trace(struct task_struct *task, struct pt_regs > *regs, > unsigned long dummy; > > stack = > - if (task && task != current) > + if (task != current) > stack = (unsigned long *)task->thread.sp; > } > > -- > 1.8.1.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 03/11] mm, mempolicy: remove per-process flag
David Rientjes writes: > > Per-process flags are a scarce resource so we should free them up > whenever possible and make them available. We'll be using it shortly for > memcg oom reserves. I'm not convinced TCP_RR is a meaningfull benchmark for slab. The shortness seems like an artificial problem. Just add another flag word to the task_struct? That would seem to be the obvious way. People will need it sooner or later anyways. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 10/11] kexec: Support for loading ELF x86_64 images
On Fri, Feb 28, 2014 at 12:11:43PM -0500, Vivek Goyal wrote:
> I was rather thinking of arch/x86/kernel/kexec. But that's for some other
> day. Not part of this patchset. This is alredy too big and I don't want
> to make any changes which are nice to have and bloat the patch size.
Ok.
Btw, we were talking about the "kernel" part of the path. And, as Ingo
said, it is all kernel so arch/x86/kexec should be perfectly fine.
...
> > > + for (i = 0; i < ehdr->e_phnum; i++) {
> > > + if (phdrs[i].p_type != PT_LOAD)
> > > + continue;
> >
> > newline
>
> What's that?
Ah, that's: "please add an empty line here" for better readability.
> > > +/* Fill in fields which are usually present in bzImage */
> > > +static int init_linux_parameters(struct boot_params *params)
> > > +{
> > > + /*
> > > + * FIXME: It is odd that the information which comes from kernel
> > > + * has to be faked by loading kernel. I guess it is limitation of
> > > + * ELF format. Right now keeping it same as kexec-tools
> > > + * implementation. But this most likely needs fixing.
> > > + */
> > > + memcpy(>hdr.header, "HdrS", 4);
> > > + params->hdr.version = 0x0206;
> > > + params->hdr.initrd_addr_max = 0x37FF;
> > > + params->hdr.cmdline_size = 2048;
> > > + return 0;
> > > +}
> >
> > Why a separate function? Its body is small enough to be merged into
> > elf_x86_64_load.
>
> Actually this logic shows the limitation of ELF format kernel image.
> This information should be exported by the image so that loader can
> do some verifications. But instead loader is hardcoding this info and
> faking things.
>
> For example, it should be kernel which tells what's the maximum command
> line size it can handle and then loader can return error if user specified
> command line size is greater than what new kernel can handle.
>
> Similarly, what's the max address initrd can be loaded at.
>
> Actually I have copied this code from kexec-tools. And I am wondering
> if some of this is
>
> I am not sure why we set hdr.version and hdr.header. Are there any
> assumptions in booth path kernel is making. May be some other code
> down the line is parsing it or it is completely redundant. I think
> I will play with removing setting of hdr.version and hdr.header and
> see how does it go.
Well, this is mandated by the boot protocol, no?
"If the "HdrS" (0x53726448) magic number is not found at offset 0x202,
the boot protocol version is "old". Loading an old kernel, the
following parameters should be assumed:
Image type = zImage
initrd not supported
Real-mode kernel must be located at 0x9."
About version 0x0206:
Field name: cmdline_size
Type: read
Offset/size:0x238/4
Protocol: 2.06+
The maximum size of the command line without the terminating
zero. This means that the command line can contain at most
cmdline_size characters. With protocol version 2.05 and earlier, the
maximum size was 255.
So according to the protocol, cmdline_size should be set by
kexec_file_load and not hardcoded to 2K, if we're mandating protocol
version 2.06.
Maybe hpa can comment on all this.
> so I put it in a separate function because user space code had it that
> way. Also because I did not like this part of the code and this looks
> like a limitation of ELF format, I wanted to isolate it in a separate
> function so that it is easy to spot it.
Right.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: mv64xxx: Fix compilation breakage
On Fri, Mar 07, 2014 at 04:08:36PM +, Russell King - ARM Linux wrote: > On Fri, Mar 07, 2014 at 03:59:30PM +0100, Maxime Ripard wrote: > > @@ -900,7 +902,8 @@ mv64xxx_i2c_probe(struct platform_device *pd) > > exit_free_irq: > > free_irq(drv_data->irq, drv_data); > > exit_reset: > > - if (pd->dev.of_node && !IS_ERR(drv_data->rstc)) > > + if (pd->dev.of_node && IS_ENABLED(CONFIG_RESET_CONTROLLER) && > > + !IS_ERR(drv_data->rstc)) > > reset_control_assert(drv_data->rstc); > > Another question is... why do we need to check pd->dev.of_node here? > If CONFIG_RESET_CONTROLLER is set, we always try to get the reset > controller node, so drv_data->rstc is either going to be a valid > pointer, or it's going to be an error pointer - neither > reset_control_get() nor devm_reset_control_get return NULL. Hmmm, right. I'll fix this in a later version. Wolfram, do you want me to respin the patch making use of reset_get_optional introduced by Philip in its other mail? -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On Fri, Mar 7, 2014 at 7:58 AM, Thomas Graf wrote:
> On 03/07/2014 05:46 AM, Pravin Shelar wrote:
>>
>> But I found bug in datapath user-space queue code. I am not sure how
>> this can work with skb fragments and MMAP-netlink socket.
>> Here is what happens, OVS allocates netlink skb and adds fragments to
>> skb using skb_zero_copy(), then calls genlmsg_unicast().
>> But if netlink sock is mmped then netlink-send queues netlink
>> allocated skb->head (linear data of skb) and ignore skb frags.
>>
>> Currently this is not problem with OVS vswitchd since it does not use
>> netlink MMAP sockets. But if vswitchd stats using MMAP-netlink socket,
>> it can break it.
>
>
> The secret is out ;-)
>
> I was very surprised too when I noticed that it worked. It's not just
> OVS, it's nfqueue as well. The reason is that an netlink mmaped skb is
> setup with a giant tailroom in netlink_ring_setup_skb():
>
> skb->end= skb->tail + size;
>
For OVS use-case, the size is linear part of skb. so I think for
mmap-netlink socket it will fail.
> and skb_zerocopy() will consume whatever tailroom is available first:
>
> /* dont bother with small payloads */
> if (len <= skb_tailroom(to)) {
> skb_copy_bits(from, 0, skb_put(to, len), len);
> return;
> }
>
> I was planning to fix this while adding GSO support to the upcall as
> that is the moment when this bug would really surface.
ok.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/7] x86: mm: new tunable for single vs full TLB flush
On 03/06/2014 05:37 PM, Davidlohr Bueso wrote: > On Wed, 2014-03-05 at 16:45 -0800, Dave Hansen wrote: >> From: Dave Hansen >> + >> +If you believe that invlpg is being called too often, you can >> +lower the tunable: >> + >> +/sys/debug/kernel/x86/tlb_single_page_flush_ceiling >> + > > Whenever this tunable needs to be updated, most users will not know what > a invlpg is and won't think in terms of pages either. How about making > this in units of Kb instead? But then again most of those users won't be > looking into tlb flushing issues anyways, so... Yeah, talking about the instruction directly in the documentation is probably going a bit far. I'll see if I can uplevel it a bit. It's obviously not a big deal to change it to be pages vs. kb, but for something that's as *COMPLETELY* developer-focused, I think we can keep it in pages. We don't want users fooling with this. > While obvious, tt should also mention that this does not apply to > hugepages. Good point. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: oops in slab/leaks_show
Joonsoo recently changed the handling of the freelist in SLAB. CCing him. On Thu, 6 Mar 2014, Dave Jones wrote: > I pretty much always use SLUB for my fuzzing boxes, but thought I'd give SLAB > a try > for a change.. It blew up when something tried to read /proc/slab_allocators > (Just cat it, and you should see the oops below) > > Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC > Modules linked in: fuse hidp snd_seq_dummy tun rfcomm bnep llc2 af_key > can_raw ipt_ULOG can_bcm nfnetlink scsi_transport_iscsi nfc caif_socket caif > af_802154 phonet af_rxrpc can pppoe pppox ppp_generic slhc irda crc_ccitt rds > rose x25 atm netrom appletalk ipx p8023 psnap p8022 llc ax25 cfg80211 xfs > coretemp hwmon x86_pkg_temp_thermal kvm_intel kvm crct10dif_pclmul > crc32c_intel ghash_clmulni_intel libcrc32c usb_debug microcode > snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic pcspkr btusb > bluetooth 6lowpan_iphc rfkill snd_hda_intel snd_hda_codec snd_hwdep snd_seq > snd_seq_device snd_pcm snd_timer e1000e snd ptp shpchp soundcore pps_core > serio_raw > CPU: 1 PID: 9386 Comm: trinity-c33 Not tainted 3.14.0-rc5+ #131 > task: 8801aa46e890 ti: 880076924000 task.ti: 880076924000 > RIP: 0010:[] [] handle_slab+0x8a/0x180 > RSP: 0018:880076925de0 EFLAGS: 00010002 > RAX: 1000 RBX: RCX: 5ce85ce7 > RDX: ea00079be100 RSI: 1000 RDI: 880107458000 > RBP: 880076925e18 R08: 0001 R09: > R10: R11: 000f R12: 8801e6f84000 > R13: ea00079be100 R14: 880107458000 R15: 88022bb8d2c0 > FS: 7fb769e45740() GS:88024d04() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 8801e6f84ff8 CR3: a22db000 CR4: 001407e0 > DR0: 02695000 DR1: 02695000 DR2: > DR3: DR6: fffe0ff0 DR7: 00070602 > Stack: > 8802339dcfc0 88022bb8d2c0 880107458000 88022bb8d2c0 > 8802339dd008 8802339dcfc0 ea00079be100 880076925e68 > aa1ad9be 880203fe4f00 88022bb8d318 76925e98 > Call Trace: > [] leaks_show+0xce/0x240 > [] seq_read+0x28e/0x490 > [] proc_reg_read+0x3d/0x80 > [] vfs_read+0x9b/0x160 > [] SyS_read+0x58/0xb0 > [] tracesys+0xd4/0xd9 > Code: f5 00 00 00 0f 1f 44 00 00 48 63 c8 44 3b 0c 8a 0f 84 e3 00 00 00 83 c0 > 01 44 39 c0 72 eb 41 f6 47 1a 01 0f 84 e9 00 00 00 89 f0 <4d> 8b 4c 04 f8 4d > 85 c9 0f 84 88 00 00 00 49 8b 7e 08 4d 8d 46 > RIP [] handle_slab+0x8a/0x180 > RSP > CR2: 8801e6f84ff8 > > > 2b:*4d 8b 4c 04 f8 mov-0x8(%r12,%rax,1),%r9 <-- > trapping instruction > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5][RFC][CFT] resizable namespace.c hashes
Al Viro writes: > * switch allocation to alloc_large_system_hash() > * make sizes overridable by boot parameters (mhash_entries=, mphash_entries=) > * switch mountpoint_hashtable from list_head to hlist_head So how much memory does this use on a standard system (<4GB memory)? How much memory does it use on a large system (0.5TB)? How good is your hash function. Would jhash be more appropiate and allow smaller hash tables? Perhaps just want a tree here. -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]: > On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote: > > This might end up not being relevant. And this is surely documented > > somewhere, but anyhow: > > - what git magic returns the hashes of the 15 commits that merge commit > > 96702be56037 added to the tree; and > > "git show 96702be56037" gives: > > commit 96702be560374ee7e7139a34cab03554129abbb4 > Merge: 04f982beb900 d56dbf5bab8c > ... > > 04f982beb900 is the previous HEAD, d56dbf5bab8c is the head of the > branch merged by this commit. "git log 04f982beb900..96702be56037" > shows the commits merged. Thanks. Fairly obvious, actually. Not sure why I didn't think of this myself. > > - how can I use the list of those hashes to limit the range of commits > > to do a git bisect? > > I'm not a git bisect expert, but I *think* you should be able to do > something like this: > > git bisect start > git bisect bad 96702be56037 > git bisect good 04f982beb900 > > (assuming you've verified that 96702be56037 really *is* bad and > 04f982beb900 really *is* good), and git should checkout something in > the middle and you can build and test it, then use "git bisect good" > or "git bisect bad" depending on the result. Makes sense. Thanks again. 04f982beb900 appears to be good. So if 96702be56037 turns out to be bad bisecting might not turn into the ordeal it usually is. (On this machine, with my workflow, bisecting an v3.x..v3.x+1-rcy range takes a few days.) Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/5] irqchip: armanda: Sanitize set_irq_affinity()
On Fri, 7 Mar 2014, Gregory CLEMENT wrote: > On 06/03/2014 20:05, Jason Cooper wrote: > > Thomas, > > > > nit: s/armanda/armada/ in the patch subject. > > > > Gregory, > > > > Mind providing an Ack on this? > > Well sorry but with this patch the kernel doesn't > work anymore. > > I am investigating to find if some part could be kept. It might be the readback of the routing register. I don't have the datasheet of this. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] rt,blk,mq: Make blk_mq_cpu_notify_lock a raw spinlock
On Fri, 2014-03-07 at 17:00 +0100, Sebastian Andrzej Siewior wrote: > * Mike Galbraith | 2014-03-03 05:57:26 [+0100]: > > > block/blk-mq-cpu.c | 14 +++--- > > This got in v3.13-rc1, are you running some kind of backported version > of this in v3.12 or do you have your own v3.13-rt? It's 3.12, but with a few (koff) backports. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/7] x86: mm: set TLB flush tunable to sane value
On 03/06/2014 05:55 PM, Davidlohr Bueso wrote: > On Wed, 2014-03-05 at 16:45 -0800, Dave Hansen wrote: >> From: Dave Hansen >> >> Now that we have some shiny new tracepoints, we can actually >> figure out what the heck is going on. >> >> During a kernel compile, 60% of the flush_tlb_mm_range() calls >> are for a single page. It breaks down like this: > > It would be interesting to see similar data for opposite workloads with > more random access patterns. That's normally when things start getting > fun in the tlb world. First of all, thanks for testing. It's much appreciated! Any suggestions for opposite workloads? I've seen this tunable have really heavy effects on ebizzy. It fits almost entirely within the itlb and if we are doing full flushes, it eats the itlb and increases the misses about 10x. Even putting this tunable above 500 pages (which is pretty insane) didn't help it. Things that thrash the TLB don't really care if someone invalidates their TLB since they're thrashing it anyway. I've had a really hard time finding workloads that _care_ or are affected by small changes in this tunable. That's one of the reasons I tried to simplify it: it's just not worth the complexity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: slub: fix leak of 'name' in sysfs_slab_add
On Fri, 7 Mar 2014, Dave Jones wrote: > > Since this function was modified in the mmotm tree, I would propose > > something like this on top of mmotm to avoid further merge conflicts: > > Looks good to me. Acked-by: Christoph Lameter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] slub: Replace __this_cpu_inc usage w/ SLUB_STATS
On Thu, 6 Mar 2014, Josh Cartwright wrote: > Although, I'm wondering how exact these statistics need to be. Is > making them preemption safe even a concern? Not sure about that. You solution makes it preempt safe. If is can be tolerated that its racy then raw_cpu_inc() could be used. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] reset: Add optional resets and stubs
Hi Wolfram, Am Freitag, den 07.03.2014, 16:39 +0100 schrieb Wolfram Sang: > On Fri, Mar 07, 2014 at 03:30:23PM +0100, Philipp Zabel wrote: > > This patch adds device_reset_optional and (devm_)reset_control_get_optional > > variants that drivers can use to indicate they can function without control > > over the reset line. For those functions, stubs are added so the drivers can > > be compiled with CONFIG_RESET_CONTROLLER disabled. > > Also, device_reset is annotated with __must_check. Drivers ignoring the > > return > > value should use device_reset_optional instead. > > > > Signed-off-by: Philipp Zabel > > Yay, thanks for fixing that! Do you pick it up yourself? yes, I can do that. Does this work for all interested parties? regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the akpm tree
On Thu, 6 Mar 2014, Andrew Morton wrote: > > So, by "the whole series" do you mean just/all these: > > > > percpu-add-raw_cpu_ops.patch > > ... > > sh-replace-__get_cpu_var-uses.patch > > Yep. Commented out in http://ozlabs.org/~akpm/mmots/series > > > If so, I will remove them from my tree today (if you don't get around to > > a new mmotm before then). > > Cool. I need at least the initial 5 patches that establish the framework in -next and do the debugging in order to make further progress on this one. The rest are bits and pieces that may require some detail work. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 2/2] Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"
From: > On Fri, 7 Mar 2014, David Laight wrote: > > > From: Alan Stern > > > On Fri, 7 Mar 2014, David Laight wrote: > > > > > > > From: Mathias Nyman > > > > > This reverts commit 3804fad45411b48233b48003e33a78f290d227c8. > > > > > > > > > > This commit, together with commit > > > > > 247bf557273dd775505fb9240d2d152f4f20d304 > > > > > "xhci 1.0: Limit arbitrarily-aligned scatter gather." were > > > > > origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a > > > > > devices > > > > > working together with scatter gather. xHCI 1.0 hosts pose some > > > > > requirement on how transfer > > > > > buffers are aligned, setting this requirement for 1.0 hosts caused > > > > > USB 3.0 mass > > > > > storage devices to fail more frequently. > > > > > > > > This patch doesn't need to be reverted. > > > > > > Yes, it does. > > > > > > > Provided the xhci driver doesn't set the flag to say that arbitrary > > > > scatter > > > > gather is supported (ie usb_device_no_sg_constraint(dev->udev)) is > > > > false) > > > > the ax88179_178a driver won't request transmits that need fragmenting. > > > > > > True. But xhci-hcd _will_ set the flag, because of patch 1 in this > > > series. In other words, patch 1 makes patch 2 necessary. > > > > I was reading patch 2 first. > > It would seem to be better to modify patch 1 - so it doesn't set the flag. > > Then the changes are limited to the usb tree, and the change to net wouldn't > > need to be reapplied in order to test scatter-gather when it is properly > > fixed. > > > The point is that the no_sg_constraint was added in order to allow > > the ax88179_178a driver to send arbitrarily aligned transfers. > > Nothing else looks at it (well didn't when I scanned the tree a while back). > > > > In effect all the other transfer requests were assumed to be suitably > > aligned. > > > > The check that caused things to fail was the one added to xhci relatively > > recently that verified the alignment of the fragments. > > (Actually the check was added to usbcore, not to xhci-hcd.) > > The _real_ problem here seems to be that "no_sg_constraint" is > ambiguous. Originally it was meant to refer to the constraint that all > SG elements except the last must be a multiple of the maxpacket size. > For that purpose, the check added to usbcore was entirely appropriate, > as was setting the flag in xhci-hcd. Probably true - but the only code that looked at it was in usbnet. The check in usbcore is very recent. > But now it turns out that the ax88179 driver is violating a _different_ > constraint: that Link TRBs must occur only at 1-KB boundaries. The > "no_sg_constraint" flag was never meant to describe this. In other > words, the flag issue is separate from the problem facing ax88179. Really that means that the xhci controller couldn't actually support the alignments it said it could - rather than the ax88179 driver sending packets that didn't meet that the rules. > The appropriate way to address this new problem for the future is to > remove the second constraint by adding correct support for TD > fragments into xhci-hcd. Indeed. > The appropriate way to address the problem > right now in the -stable kernels is to prevent ax88179 from using SG -- > and not by abusing the "no_sg_constraint" flag, which is not directly > related to the TD fragment problem. I'd say that if the no_sg_constraint flag is set the ax88179 driver could reasonably expect to send its fragment lists. So it is best not to set the no_sg_constraint flag, and then remove the checks against it that are needed to allow the transfers from the disk system not be rejected - even though we know that some of them might not actually work. Otherwise you'll need to add yet another flag when the sg support is fixed. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the akpm tree
On Thu, 6 Mar 2014, Stephen Rothwell wrote: > > I have reverted that commit for today. > > I suspect that this whole series may need more review and work. Toss the bits that do not build for now. These can then be handled in individual patches since the overall framework is present. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] agp/intel: can't ioremap flush page - no chipset flushing
On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote: > Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]: >> I wouldn't start bisecting yet, but if you're in the mood, this >> commit: 96702be56037 "Merge branch 'pci/resource' into next" looks >> like a good place to start, so you could try the pre-merge commit: >> 04f982beb900 "Merge branch 'pci/msi' into next". If 04f982beb900 is >> good, there are only about 15 commits on the pci/resource branch to >> look at. > > This might end up not being relevant. And this is surely documented > somewhere, but anyhow: > - what git magic returns the hashes of the 15 commits that merge commit > 96702be56037 added to the tree; and "git show 96702be56037" gives: commit 96702be560374ee7e7139a34cab03554129abbb4 Merge: 04f982beb900 d56dbf5bab8c ... 04f982beb900 is the previous HEAD, d56dbf5bab8c is the head of the branch merged by this commit. "git log 04f982beb900..96702be56037" shows the commits merged. > - how can I use the list of those hashes to limit the range of commits > to do a git bisect? I'm not a git bisect expert, but I *think* you should be able to do something like this: git bisect start git bisect bad 96702be56037 git bisect good 04f982beb900 (assuming you've verified that 96702be56037 really *is* bad and 04f982beb900 really *is* good), and git should checkout something in the middle and you can build and test it, then use "git bisect good" or "git bisect bad" depending on the result. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
serial core: crash / race condition on unbind
When unbinding a serial driver, uart_remove_one_port() clears
uart_state.uart_port:
state->uart_port = NULL;
If the serial port is still in use (e.g. by getty), uart_close() will be
called later:
static void uart_close(struct tty_struct *tty, struct file *filp)
{
struct uart_state *state = tty->driver_data;
struct uart_port *uport;
...
if (!state)
return;
uport = state->uart_port;
uport is NULL
...
pr_debug("uart_close(%d) called\n", uport->line);
If debugging is enabled, it will already crash here while dereferencing uport
(this one is easily fixed)
if (tty_port_close_start(port, tty, filp) == 0)
return;
...
uart_flush_buffer(tty);
uart_flush_buffer() will try to obtain the port's spinlock:
static void uart_flush_buffer(struct tty_struct *tty)
{
struct uart_state *state = tty->driver_data;
struct uart_port *port;
...
port = state->uart_port;
port is NULL
...
spin_lock_irqsave(>lock, flags);
Crash!!
It doesn't always crash, though.
Sometimes uart_close() returns after the tty_port_close_start() above,
without a crash (bypassing e.g. the call to uart_change_pm() :-(
Sometimes it crashs in uart_chars_in_buffer(), which also tries to take the
spinlock:
tty_port_close_start()
tty_wait_until_sent_from_close()
tty_wait_until_sent()
tty_chars_in_buffer()
uart_chars_in_buffer()
spin_lock_irqsave(>uart_port->lock, flags);
I'm not that familiar with the internals of the serial core. Perhaps
uart_close()
should return early if uport is NULL, just like if state is NULL?
However, that means the uart_change_pm(state, UART_PM_STATE_OFF)
is bypassed again.
This is with sh-sci, but I don't think the driver matters.
Thanks for your comments and suggestions!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] CLK: ti: dra7: Initialize USB_DPLL
* Tero Kristo [140307 05:46]:
> On 03/07/2014 03:09 PM, Roger Quadros wrote:
> >USB_DPLL must be initialized and locked at boot so that
> >USB modules can work.
> >
> >Also program USB_DLL_M2 output to half rate.
> >
> >CC: Mike Turquette
> >CC: Tero Kristo
> >Signed-off-by: Roger Quadros
> >---
> > drivers/clk/ti/clk-7xx.c | 11 +++
> > 1 file changed, 11 insertions(+)
> >
> >diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
> >index 9977653..f89f3c2 100644
> >--- a/drivers/clk/ti/clk-7xx.c
> >+++ b/drivers/clk/ti/clk-7xx.c
> >@@ -18,6 +18,7 @@
> >
> > #define DRA7_DPLL_ABE_DEFFREQ 361267200
> > #define DRA7_DPLL_GMAC_DEFFREQ 10
> >+#define DRA7_DPLL_USB_DEFFREQ 96000
> >
> >
> > static struct ti_dt_clk dra7xx_clks[] = {
> >@@ -328,5 +329,15 @@ int __init dra7xx_dt_clk_init(void)
> > if (rc)
> > pr_err("%s: failed to configure GMAC DPLL!\n", __func__);
> >
> >+dpll_ck = clk_get_sys(NULL, "dpll_usb_ck");
> >+rc = clk_set_rate(dpll_ck, DRA7_DPLL_USB_DEFFREQ);
> >+if (rc)
> >+pr_err("%s: failed to configure USB DPLL!\n", __func__);
> >+
> >+dpll_ck = clk_get_sys(NULL, "dpll_usb_m2_ck");
> >+rc = clk_set_rate(dpll_ck, DRA7_DPLL_USB_DEFFREQ/2);
> >+if (rc)
> >+pr_err("%s: failed to set USB_DPLL M2 OUT\n", __func__);
> >+
>
> I would rather see this done using the default-rate mechanism provided here:
>
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg101300.html
>
> However, this remains to be commented by Mike whether the patch is
> okay or not.
Yes let's wait for that and not add hacks for new features.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/4] checkpatch: enhance compatible string checking
On 03/07/2014 05:08 PM, Joe Perches wrote: > On Fri, 2014-03-07 at 14:26 +0100, Florian Vaussard wrote: >> Joe: I have split your patch to perform atomic changes. I also >> merged one part into one of my patch. I added your S-o-B on the >> corresponding patches, I let you check if you are OK with the changes. > > Could you please send a clean V4 without my SOB and add > Andrew Morton to the cc's? > Do I remove your SOB from all 4 patches? > Andrew is generally the path to get checkpatch changes > upstream. > Sure. Regards, Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 5/5] Staging: comedi: addi-data: tidy up counter register map defines in hwdrv_apci1564.c
On Friday, March 07, 2014 1:32 AM, Chase Southwood wrote: >>On Thursday, March 6, 2014 11:59 AM, Hartley Sweeten >> wrote: >> This one is incomplete and breaks the build. >> Be sure to do a build after each patch to make sure it works. > > Hartley, > I'm sorry for this, it appears that this whole patch series was sloppy > and quite untested by myself. I have made up a fixed patchset and have > tested everything this time around, I trust that you should have a better > time reviewing this one. I will not let this happen again in the future. Not a problem. Just make sure to test any patches before posting them. :-) I'm looking over your new series now. Hartley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
On Fri, Mar 07, 2014 at 10:18:08PM +0530, Kishon Vijay Abraham I wrote:
> No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
> Also removed the unused members of struct omap_usb (after phy-omap-pipe3
> started using it's own header file)
does this depend in any other patch ? I get the following when applying
*only* this patch on top of v3.14-rc5:
drivers/phy/phy-omap-usb2.c: In function ‘omap_usb2_suspend’:
drivers/phy/phy-omap-usb2.c:106:21: error: ‘struct omap_usb’ has no member
named ‘is_suspended’
if (suspend && !phy->is_suspended) {
^
drivers/phy/phy-omap-usb2.c:109:6: error: ‘struct omap_usb’ has no member named
‘is_suspended’
phy->is_suspended = 1;
^
drivers/phy/phy-omap-usb2.c:110:28: error: ‘struct omap_usb’ has no member
named ‘is_suspended’
} else if (!suspend && phy->is_suspended) {
^
drivers/phy/phy-omap-usb2.c:117:6: error: ‘struct omap_usb’ has no member named
‘is_suspended’
phy->is_suspended = 0;
^
drivers/phy/phy-omap-usb2.c: In function ‘omap_usb2_probe’:
drivers/phy/phy-omap-usb2.c:194:5: error: ‘struct omap_usb’ has no member named
‘is_suspended’
phy->is_suspended = 1;
^
make[1]: *** [drivers/phy/phy-omap-usb2.o] Error 1
make: *** [drivers/phy/] Error 2
make: *** Waiting for unfinished jobs
CC [M] drivers/usb/phy/phy-mxs-usb.o
drivers/usb/phy/phy-omap-usb3.c:22:32: fatal error: linux/usb/omap_usb.h: No
such file or directory
#include
^
compilation terminated.
make[1]: *** [drivers/usb/phy/phy-omap-usb3.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [drivers/usb/phy/] Error 2
--
balbi
signature.asc
Description: Digital signature
RE: [PATCH 2/2] Revert "USBNET: ax88179_178a: enable tso if usb host supports sg dma"
On Fri, 7 Mar 2014, David Laight wrote: > From: Alan Stern > > On Fri, 7 Mar 2014, David Laight wrote: > > > > > From: Mathias Nyman > > > > This reverts commit 3804fad45411b48233b48003e33a78f290d227c8. > > > > > > > > This commit, together with commit > > > > 247bf557273dd775505fb9240d2d152f4f20d304 > > > > "xhci 1.0: Limit arbitrarily-aligned scatter gather." were > > > > origially added to get xHCI 1.0 hosts and usb ethernet ax88179_178a > > > > devices > > > > working together with scatter gather. xHCI 1.0 hosts pose some > > > > requirement on how transfer > > > > buffers are aligned, setting this requirement for 1.0 hosts caused USB > > > > 3.0 mass > > > > storage devices to fail more frequently. > > > > > > This patch doesn't need to be reverted. > > > > Yes, it does. > > > > > Provided the xhci driver doesn't set the flag to say that arbitrary > > > scatter > > > gather is supported (ie usb_device_no_sg_constraint(dev->udev)) is false) > > > the ax88179_178a driver won't request transmits that need fragmenting. > > > > True. But xhci-hcd _will_ set the flag, because of patch 1 in this > > series. In other words, patch 1 makes patch 2 necessary. > > I was reading patch 2 first. > It would seem to be better to modify patch 1 - so it doesn't set the flag. > Then the changes are limited to the usb tree, and the change to net wouldn't > need to be reapplied in order to test scatter-gather when it is properly > fixed. > The point is that the no_sg_constraint was added in order to allow > the ax88179_178a driver to send arbitrarily aligned transfers. > Nothing else looks at it (well didn't when I scanned the tree a while back). > > In effect all the other transfer requests were assumed to be suitably > aligned. > > The check that caused things to fail was the one added to xhci relatively > recently that verified the alignment of the fragments. (Actually the check was added to usbcore, not to xhci-hcd.) The _real_ problem here seems to be that "no_sg_constraint" is ambiguous. Originally it was meant to refer to the constraint that all SG elements except the last must be a multiple of the maxpacket size. For that purpose, the check added to usbcore was entirely appropriate, as was setting the flag in xhci-hcd. But now it turns out that the ax88179 driver is violating a _different_ constraint: that Link TRBs must occur only at 1-KB boundaries. The "no_sg_constraint" flag was never meant to describe this. In other words, the flag issue is separate from the problem facing ax88179. The appropriate way to address this new problem for the future is to remove the second constraint by adding correct support for TD fragments into xhci-hcd. The appropriate way to address the problem right now in the -stable kernels is to prevent ax88179 from using SG -- and not by abusing the "no_sg_constraint" flag, which is not directly related to the TD fragment problem. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] regulator: pbias: Fix is_enabled callback implementation
On Friday 07 March 2014 09:11 PM, Axel Lin wrote:
The is_enabled implementation is wrong in some cases:
e.g. for pbias_mmc_omap5: emable_mask is : BIT(27) | BIT(25) | BIT(26)
Hi Axel,
s/emable_mask/enable_mask
However, pbias_regulator_enable() only sets BIT(26) | BIT(22) bits.
You mixed up enable_mask of omap5 with .enable of omap4 :-)
above comment should be
"However, pbias_regulator_enable() only sets BIT(27) | BIT(26) bits"
Other than that
Acked-by: Balaji T K
So is_enabled callback will always return false in this case.
Fix the logic to compare the register value with info->enable rather than
info->enable_mask.
Signed-off-by: Axel Lin
---
drivers/regulator/pbias-regulator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/pbias-regulator.c
b/drivers/regulator/pbias-regulator.c
index ded3b35..d89a1d8 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -108,7 +108,7 @@ static int pbias_regulator_is_enable(struct regulator_dev
*rdev)
regmap_read(data->syscon, data->pbias_reg, );
- return (value & info->enable_mask) == info->enable_mask;
+ return (value & info->enable_mask) == info->enable;
}
static struct regulator_ops pbias_regulator_voltage_ops = {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6] phy: omap-usb2: move omap_usb.h from linux/usb/ to linux/phy/
No functional change. Moved omap_usb.h from linux/usb/ to linux/phy/.
Also removed the unused members of struct omap_usb (after phy-omap-pipe3
started using it's own header file)
Signed-off-by: Kishon Vijay Abraham I
---
Changes from v5:
fixes the following compilation error
drivers/usb/phy/phy-twl6030-usb.c:30:32:
fatal error: linux/usb/omap_usb.h: No such file or directory
drivers/phy/phy-omap-usb2.c |2 +-
drivers/usb/phy/phy-twl6030-usb.c |2 +-
include/linux/{usb => phy}/omap_usb.h |3 ---
3 files changed, 2 insertions(+), 5 deletions(-)
rename include/linux/{usb => phy}/omap_usb.h (95%)
diff --git a/drivers/phy/phy-omap-usb2.c b/drivers/phy/phy-omap-usb2.c
index 705af5a..9c3f056 100644
--- a/drivers/phy/phy-omap-usb2.c
+++ b/drivers/phy/phy-omap-usb2.c
@@ -21,7 +21,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/drivers/usb/phy/phy-twl6030-usb.c
b/drivers/usb/phy/phy-twl6030-usb.c
index 214172b..04778cf 100644
--- a/drivers/usb/phy/phy-twl6030-usb.c
+++ b/drivers/usb/phy/phy-twl6030-usb.c
@@ -27,7 +27,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
diff --git a/include/linux/usb/omap_usb.h b/include/linux/phy/omap_usb.h
similarity index 95%
rename from include/linux/usb/omap_usb.h
rename to include/linux/phy/omap_usb.h
index 6ae2936..19d343c3 100644
--- a/include/linux/usb/omap_usb.h
+++ b/include/linux/phy/omap_usb.h
@@ -33,13 +33,10 @@ struct usb_dpll_params {
struct omap_usb {
struct usb_phy phy;
struct phy_companion*comparator;
- void __iomem*pll_ctrl_base;
struct device *dev;
struct device *control_dev;
struct clk *wkupclk;
- struct clk *sys_clk;
struct clk *optclk;
- u8 is_suspended:1;
};
#definephy_to_omapusb(x) container_of((x), struct omap_usb, phy)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] regulator: pbias: Convert to use regulator_[enable|is_enabled]_regmap
On Friday 07 March 2014 09:20 PM, Axel Lin wrote:
Since commit ca5d1b3524b4d
"regulator: helpers: Modify helpers enabling multi-bit control",
we can set enable_val setting for device that use multiple bits for control
when using regmap enable/disable/bypass ops.
Signed-off-by: Axel Lin
---
Note:
This patch depends on below commit which is only in regulator tree now:
http://git.kernel.org/cgit/linux/kernel/git/broonie/regulator.git/commit/?h=topic/enable
I sent this for reveiw and test now.
if it works, I'll resend it once 3.5-rc1 is released.
Hi,
I tested this series with above dependent commit and it works as excepted
So you can add my,
Tested-by: Balaji T K
Thanks for doing regmap conversion, now pbias driver looks as minimal as
possible.
drivers/regulator/pbias-regulator.c | 25 +++--
1 file changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/regulator/pbias-regulator.c
b/drivers/regulator/pbias-regulator.c
index 6d38be3..708ddbb 100644
--- a/drivers/regulator/pbias-regulator.c
+++ b/drivers/regulator/pbias-regulator.c
@@ -49,33 +49,13 @@ static const unsigned int pbias_volt_table[] = {
300
};
-static int pbias_regulator_enable(struct regulator_dev *rdev)
-{
- struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
- const struct pbias_reg_info *info = data->info;
-
- return regmap_update_bits(data->syscon, rdev->desc->enable_reg,
- info->enable_mask, info->enable);
-}
-
-static int pbias_regulator_is_enable(struct regulator_dev *rdev)
-{
- struct pbias_regulator_data *data = rdev_get_drvdata(rdev);
- const struct pbias_reg_info *info = data->info;
- int value;
-
- regmap_read(data->syscon, rdev->desc->enable_reg, );
-
- return (value & info->enable_mask) == info->enable;
-}
-
static struct regulator_ops pbias_regulator_voltage_ops = {
.list_voltage = regulator_list_voltage_table,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
- .enable = pbias_regulator_enable,
+ .enable = regulator_enable_regmap,
.disable = regulator_disable_regmap,
- .is_enabled = pbias_regulator_is_enable,
+ .is_enabled = regulator_is_enabled_regmap,
};
static const struct pbias_reg_info pbias_mmc_omap2430 = {
@@ -180,6 +160,7 @@ static int pbias_regulator_probe(struct platform_device
*pdev)
drvdata[data_idx].desc.vsel_mask = info->vmode;
drvdata[data_idx].desc.enable_reg = res->start;
drvdata[data_idx].desc.enable_mask = info->enable_mask;
+ drvdata[data_idx].desc.enable_val = info->enable;
cfg.init_data = pbias_matches[idx].init_data;
cfg.driver_data = [data_idx];
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug] PCI: Enable INTx if BIOS left them disabled - triggers during rescan
[+cc Yinghai, Rajat] On Fri, Mar 7, 2014 at 7:33 AM, Andreas Noever wrote: > Hi, > > After upgrading to the latest RC I noticed that suprise removal > stopped working. Linux did not notice that the devices where gone. > Bisection points to > > 1f42db786b14a31bf807fc41ee5583a00c08fcb1 PCI: Enable INTx if BIOS left > them disabled > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1f42db786b14a31bf807fc41ee5583a00c08fcb1 > > It seems that the above patch is triggered on the bridge itself (!) > when a new device is added below it. At this point the hotplug driver > for the bridge has already enabled MSI. Reenabling INTX kills MSI and > prevents later suprise removal notifications. > > The following stacktrace is from a "echo 1 > rescan" on the bridge: > do_pci_enable_device+0x59/0x140 > pci_reenable_device+0x1f/0x30 > pci_assign_unassigned_bridge_resources+0x123/0x160 > pci_rescan_bus_bridge_resize+0x28/0x40 > dev_bus_rescan_store+0x85/0xa0 > dev_attr_store+0x18/0x30 > sysfs_kf_write+0x3d/0x50 > kernfs_fop_write+0xd2/0x140 > vfs_write+0xba/0x1e0 > SyS_write+0x49/0xa0 > system_call_fastpath+0x1a/0x1f > > Similarly for a hotplug event: > do_pci_enable_device+0x59/0x140 > pci_reenable_device+0x1f/0x30 > pci_assign_unassigned_bridge_resources+0x123/0x160 > pciehp_configure_device+0x90/0x160 > pciehp_enable_slot+0x163/0x280 > pciehp_power_thread+0xb8/0xe0 > process_one_work+0x167/0x420 > worker_thread+0x121/0x3a0 > > In both cases DisINTx is turned off and the hotplug driver stops > reacting to events. Thanks a lot for noticing and bisecting this! I opened a bugzilla report at https://bugzilla.kernel.org/show_bug.cgi?id=71691 It seems like clearing DisINTx has some effect on MSI. I don't see anything in the spec that would suggest this (I'm looking at the PCIe r3.0 spec, sec 7.5.1.1). Can somebody point out a connection between DisINTx and MSI? If not, maybe we'll need some sort of quirk to deal with this. Andrea, can you attach a complete dmesg log and "lspci -vv" output to the bugzilla? Thanks again! Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] regulator: pbias: Convert to use regmap helper functions
On Friday 07 March 2014 09:13 PM, Axel Lin wrote: This patch converts this driver to use the regmap helper functions provided by regulator core. Signed-off-by: Axel Lin Acked-by: Balaji T K --- drivers/regulator/pbias-regulator.c | 74 ++--- 1 file changed, 19 insertions(+), 55 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] of: Fix of_graph_parse_endpoint stub for !CONFIG_OF builds
Hi Russell, Am Freitag, den 07.03.2014, 15:49 + schrieb Russell King - ARM Linux: > On Fri, Mar 07, 2014 at 04:06:10PM +0100, Philipp Zabel wrote: > > I have also updated the git branch. The following changes since commit > > d484700a36952c6675aa47dec4d7a536929aa922: > > > > of: Warn if of_graph_parse_endpoint is called with the root node > > (2014-03-06 17:41:54 +0100) > > > > are available in the git repository at: > > > > git://git.pengutronix.de/git/pza/linux.git topic/of-graph > > > > for you to fetch changes up to 00fd9619120db1d6a19be2f9e3df6f76234b311b: > > > > of: Fix of_graph_parse_endpoint stub for !CONFIG_OF builds (2014-03-07 > > 16:02:46 +0100) > > Thanks, I'll re-pull it shortly. The other good news is that I've thrown > your patches on top of the previous pull, merged them into my test tree > and everything seems to work as it should on the SolidRun Hummingboard. > > What base have you used for those imx-drm patches? I assume it would > be something like a merge of my imx-drm commits and the of-graph branch? I have based the topic/imx-drm-dt branch on the staging-next branch of the staging tree, at the time it was created: 17b02809cfa77abcab155ce3afbb1467e7f0744f "Merge 3.14-rc5 into staging-next" The topic/imx-drm-dt branch is not based on topic/of-graph at all. > Let me put this a different way: I'd be happy to pull those changes if > they're sensibly based in your git tree. Thanks! regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk for Seagate Momentus SpinPoint M8 (2BA30001)
Via commit 87809942d3fa "libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk
for Seagate Momentus SpinPoint M8" we added a quirk for disks named
"ST1000LM024 HN-M101MBB" with firmware revision "2AR10001".
As reported on https://bugzilla.redhat.com/show_bug.cgi?id=1073901,
we need to also add firmware revision 2BA30001 as it is broken as well.
Reported-by: Nicholas
Signed-off-by: Michele Baldessari
Tested-by: Guilherme Amadio
---
drivers/ata/libata-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 1a3dbd1b196e..87a489a22306 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4175,6 +4175,7 @@ static const struct ata_blacklist_entry
ata_device_blacklist [] = {
/* Seagate Momentus SpinPoint M8 seem to have FPMDA_AA issues */
{ "ST1000LM024 HN-M101MBB", "2AR10001", ATA_HORKAGE_BROKEN_FPDMA_AA },
+ { "ST1000LM024 HN-M101MBB", "2BA30001", ATA_HORKAGE_BROKEN_FPDMA_AA },
/* Blacklist entries taken from Silicon Image 3124/3132
Windows driver .inf file - also several Linux problem reports */
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:264 dev_watchdog+0x276/0x280()
On 07.03.2014 00:32, poma wrote: > ... > After a few dozen tests with the vanilla commits, and with the same > amount of rawhide kernels ... > https://bugzilla.redhat.com/attachment.cgi?id=871694 > > Dan, Francois you are both welcome with comments! > Thanks. Thomas U2. :) No barking w-dog, but now the network traffic is totally busted! https://bugzilla.redhat.com/attachment.cgi?id=871947 "ping: sendmsg: No buffer space available ..." poma -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] asm-generic: rwsem: de-PPCify rwsem.h
On Friday 07 March 2014, Will Deacon wrote: > asm-generic/rwsem.h used to live under arch/powerpc. During its > liberation to common code, a few references to its former home where > preserved, in particular the definition of RWSEM_ACTIVE_MASK is > predicated on CONFIG_PPC64. > > This patch updates the ifdefs and comments to architecturally neutral > versions. > > Cc: Arnd Bergmann > Acked-by: Richard Kuo > Signed-off-by: Will Deacon > --- > > Hi Arnd, > > Any chance you could queue this for 3.15 please? It means I can easily > move arm64 over to the asm-generic rwsem implementation afterwards. > Acked-by: Arnd Bergmann I don't expect any conflicts, so just put it in the arm64 tree along with the patch to use it. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] phy: omap-usb2: Add clock names to Documentation binding
On Fri, Mar 07, 2014 at 09:53:03PM +0530, Kishon Vijay Abraham I wrote: > Felipe, > > On Friday 07 March 2014 09:34 PM, Felipe Balbi wrote: > >On Fri, Mar 07, 2014 at 03:09:08PM +0200, Roger Quadros wrote: > >>Add "wkupclk" and "refclk" information to DT binding information. > >> > >>Signed-off-by: Roger Quadros > >>--- > > > >so, should I take this one ? > > yes.. the ti-phy.txt is only in your tree. yeah, I know that, but I need to know if this is safe to be applied as in "it won't change anymore". -- balbi signature.asc Description: Digital signature
Re: [RFC V1] MAINTAINERS: Addition of Dialog Semiconductor files
On Fri, 2014-03-07 at 11:30 +, Opensource [Steve Twiss] wrote: > Dialog Semiconductor would like to add a new section called DIALOG > SEMICONDUCTOR DRIVERS which contains the new support mailing list > for Dialog supported drivers. That's a fine idea. It's generally better to have a person rather than an exploder as a maintainer. It's also fine to have an exploder listed too. If "support.opensou...@diasemi.com" is actually a public mailing list (like linux-kernel), then it should use an "L: " entry. > Regards, > Steve Twiss, Dialog Semiconductor Ltd. Maybe you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/8] phy: omap-usb2: Add clock names to Documentation binding
Felipe, On Friday 07 March 2014 09:34 PM, Felipe Balbi wrote: On Fri, Mar 07, 2014 at 03:09:08PM +0200, Roger Quadros wrote: Add "wkupclk" and "refclk" information to DT binding information. Signed-off-by: Roger Quadros --- so, should I take this one ? yes.. the ti-phy.txt is only in your tree. Thanks Kishon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] openvswitch: Orphan frags before sending to userspace via Netlink to avoid guest stall
On 02/28/2014 08:16 PM, Zoltan Kiss wrote:
The kernel datapath now switched to zerocopy Netlink messages, but that also
means that the pages on frags array are sent straight to userspace. If those
pages came outside the kernel, we have to swap them out with local copies.
Signed-off-by: Zoltan Kiss
---
net/openvswitch/datapath.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 36f8872..ffb563c 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -464,6 +464,12 @@ static int queue_userspace_packet(struct datapath *dp,
struct sk_buff *skb,
}
nla->nla_len = nla_attr_size(skb->len);
+ if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC))) {
+ err = -ENOMEM;
+ skb_tx_error(skb);
+ goto out;
+ }
+
skb_zerocopy(user_skb, skb, skb->len, hlen);
/* Pad OVS_PACKET_ATTR_PACKET if linear copy was performed */
How about we move the call to skb_orphan_frags() into skb_zerocopy()
itself and call it before we actually reference the frags?
It's not just OVS affected but nfqueue as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
