Re: [PATCH v2] serial: exar: Fix stuck MSIs

[Jan Kiszka]

On 2017-04-24 14:07, Andy Shevchenko wrote:
> On Mon, 2017-04-24 at 12:30 +0200, Jan Kiszka wrote:
>> After migrating 8250_exar to MSI in 172c33cb61da, we can get stuck
>> without further interrupts because of the special wake-up event these
>> chips send. They are only cleared by reading INT0. As we fail to do so
>> during startup and shutdown, we can leave the interrupt line asserted,
>> which is fatal with edge-triggered MSIs.
>>
>> Add the required reading of INT0 to startup and shutdown. Also account
>> for the fact that a pending wake-up interrupt means we have to return
>> 1
>> from exar_handle_irq. Drop the unneeded reading of INT1..3 along with
>> this - those never reset anything.
>>
>> An alternative approach would have been disabling the wake-up
>> interrupt.
>> Unfortunately, this feature (REGB[17] = 1) is not available on the
>> XR17D15X.
> 
> FWIW:
> Reviewed-by: Andy Shevchenko 
> 

Ping. Needs to go into stable 4.11 now as well.

Jan

>>
>> Fixes: 172c33cb61da ("serial: exar: Enable MSI support")
>> Signed-off-by: Jan Kiszka 
>> ---
>>
>> Changes in v2:
>>  - mention removal of INT1..3 reading in commit log [Andy]
>>(no functional changes)
>>
>>  drivers/tty/serial/8250/8250_port.c | 19 ++-
>>  1 file changed, 10 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_port.c
>> b/drivers/tty/serial/8250/8250_port.c
>> index 6119516ef5fc..3a3667880fcf 100644
>> --- a/drivers/tty/serial/8250/8250_port.c
>> +++ b/drivers/tty/serial/8250/8250_port.c
>> @@ -47,6 +47,7 @@
>>  /*
>>   * These are definitions for the Exar XR17V35X and XR17(C|D)15X
>>   */
>> +#define UART_EXAR_INT0  0x80
>>  #define UART_EXAR_SLEEP 0x8b/* Sleep mode */
>>  #define UART_EXAR_DVID  0x8d/* Device
>> identification */
>>  
>> @@ -1869,17 +1870,13 @@ static int
>> serial8250_default_handle_irq(struct uart_port *port)
>>  static int exar_handle_irq(struct uart_port *port)
>>  {
>>  unsigned int iir = serial_port_in(port, UART_IIR);
>> -int ret;
>> +int ret = 0;
>>  
>> -ret = serial8250_handle_irq(port, iir);
>> +if (((port->type == PORT_XR17V35X) || (port->type ==
>> PORT_XR17D15X)) &&
>> +serial_port_in(port, UART_EXAR_INT0) != 0)
>> +ret = 1;
>>  
>> -if ((port->type == PORT_XR17V35X) ||
>> -   (port->type == PORT_XR17D15X)) {
>> -serial_port_in(port, 0x80);
>> -serial_port_in(port, 0x81);
>> -serial_port_in(port, 0x82);
>> -serial_port_in(port, 0x83);
>> -}
>> +ret |= serial8250_handle_irq(port, iir);
>>  
>>  return ret;
>>  }
>> @@ -2177,6 +2174,8 @@ int serial8250_do_startup(struct uart_port
>> *port)
>>  serial_port_in(port, UART_RX);
>>  serial_port_in(port, UART_IIR);
>>  serial_port_in(port, UART_MSR);
>> +if ((port->type == PORT_XR17V35X) || (port->type ==
>> PORT_XR17D15X))
>> +serial_port_in(port, UART_EXAR_INT0);
>>  
>>  /*
>>   * At this point, there's no way the LSR could still be 0xff;
>> @@ -2335,6 +2334,8 @@ int serial8250_do_startup(struct uart_port
>> *port)
>>  serial_port_in(port, UART_RX);
>>  serial_port_in(port, UART_IIR);
>>  serial_port_in(port, UART_MSR);
>> +if ((port->type == PORT_XR17V35X) || (port->type ==
>> PORT_XR17D15X))
>> +serial_port_in(port, UART_EXAR_INT0);
>>  up->lsr_saved_flags = 0;
>>  up->msr_saved_flags = 0;
>>  
> 

-- 
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [patch v4 resend 2/2] kcmp: Add KCMP_EPOLL_TFD mode to compare epoll target files

[Cyrill Gorcunov]

On Sat, May 13, 2017 at 09:55:14AM +0300, Cyrill Gorcunov wrote:
> On Fri, May 12, 2017 at 06:45:09PM -0700, Andrei Vagin wrote:
> > On Sat, May 13, 2017 at 01:53:40AM +0300, Cyrill Gorcunov wrote:
> > > On Sat, May 13, 2017 at 12:41:30AM +0200, Jann Horn wrote:
> > > > [resending as plaintext]
> > > > 
> > > > I realize that the existing kcmp code has the same issue, but:
> > > > 
> > > > Why are you not taking a reference to filp or filp_tgt? This can end up
> > > > performing a comparison between a pointer to a freed struct file and a
> > > > pointer to a struct file that was allocated afterwards, right? So it can
> > > > return a false "is equal" result when the two files aren't actually the 
> > > > same
> > > > if one of the target tasks is running? This looks like it unnecessarily
> > > > exposes information about whether an allocation reuses the memory of
> > > > a previously freed allocation.
> > > 
> > > It work with unlocked data on purpose for speed sake. Moreover even
> > > if we grap a reference it is valid _only_ during comparision operation,
> > > next we drop ref and it can be easily freed by os. Thus it's up to
> > > a caller to keep references to files/task and other resources used.
> > 
> > Looks like we can take rcu_read_lock() to guarantee that these objects
> > will not be freed, and rcu_read_lock() should not affect perfomance too 
> > much.
> 
> Rather they should be get_file_rcu/fput. Still I'm not convinced we need it,
> but fine will update both: plain KCMP_FILE and KCMP_EPOLL_TFD since it won't
> hurt performance.

>From manpage we wrote:

   Note the kcmp() is not protected against false positives which may occur
   if tasks are running.  One should stop tasks by sending SIGSTOP (see  
sig‐
   nal(7)) prior to inspection with this system call to obtain meaningful 
results.

So no, not going to uglify source code and add get/put files there.

Cyrill

Re: [kernel-hardening] Re: [PATCH v9 1/4] syscalls: Verify address limit before returning to user-mode

[Christoph Hellwig]

On Fri, May 12, 2017 at 10:30:44PM +0200, Peter Zijlstra wrote:
> On stack variable length arrays get implemented by the compiler doing
> alloca(), and we sadly have a few of those around.

I've just got rid of one of those and I wish they would appear
entirely as they are horrible in so many different ways.  Sparse
warns about them, btw.

[PATCH 5/8] gpio: exar: Fix reading of directions and values

[Jan Kiszka]

First, the logic for translating a register bit to the return code of
exar_get_direction and exar_get_value were wrong. And second, there was
a flip regarding the register bank in exar_get_direction.

Signed-off-by: Jan Kiszka 
---
 drivers/gpio/gpio-exar.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index d6ffb3d89b9c..98bd3eb1290e 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int reg)
value = readb(exar_gpio->regs + reg);
mutex_unlock(&exar_gpio->lock);
 
-   return !!value;
+   return value;
 }
 
 static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
@@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, 
unsigned int offset)
addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
val = exar_get(chip, addr) >> (offset % 8);
 
-   return !!val;
+   return val & 1;
 }
 
 static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
@@ -89,10 +89,10 @@ static int exar_get_value(struct gpio_chip *chip, unsigned 
int offset)
unsigned int addr;
int val;
 
-   addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI;
+   addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
val = exar_get(chip, addr) >> (offset % 8);
 
-   return !!val;
+   return val & 1;
 }
 
 static void exar_set_value(struct gpio_chip *chip, unsigned int offset,
-- 
2.12.0

[PATCH 2/8] gpio: exar: Fix passing in of parent PCI device

[Jan Kiszka]

This fixes reloading of the driver for the same device: First of all,
the driver sets drvdata to its own value during probing and does not
restore the original value on exit. But this won't help anyway as the
core clears drvdata after the driver left.

Use stable platform_data instead.

Signed-off-by: Jan Kiszka 
---
 drivers/gpio/gpio-exar.c| 2 +-
 drivers/tty/serial/8250/8250_exar.c | 8 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 081076771217..0a2085faf271 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -119,7 +119,7 @@ static int exar_direction_input(struct gpio_chip *chip, 
unsigned int offset)
 
 static int gpio_exar_probe(struct platform_device *pdev)
 {
-   struct pci_dev *pcidev = platform_get_drvdata(pdev);
+   struct pci_dev *pcidev = *(struct pci_dev **)pdev->dev.platform_data;
struct exar_gpio_chip *exar_gpio;
void __iomem *p;
int index, ret;
diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
index b4fa585156c7..2d056d1eeca3 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -196,8 +196,12 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
if (!pdev)
return NULL;
 
-   platform_set_drvdata(pdev, pcidev);
-   if (platform_device_add(pdev) < 0) {
+   /*
+* platform_device_add_data kmemdups the data, therefore we can safely
+* pass a stack reference.
+*/
+   if (platform_device_add_data(pdev, &pcidev, sizeof(pcidev)) < 0 ||
+   platform_device_add(pdev) < 0) {
platform_device_put(pdev);
return NULL;
}
-- 
2.12.0

[PATCH 1/8] serial: exar: Preconfigure xr17v35x MPIOs as output

[Jan Kiszka]

This is the safe default for GPIOs with unknown external wiring.

Signed-off-by: Jan Kiszka 
---
 drivers/tty/serial/8250/8250_exar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
index 1270ff163f63..b4fa585156c7 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -177,13 +177,13 @@ static void setup_gpio(u8 __iomem *p)
writeb(0x00, p + UART_EXAR_MPIOLVL_7_0);
writeb(0x00, p + UART_EXAR_MPIO3T_7_0);
writeb(0x00, p + UART_EXAR_MPIOINV_7_0);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_7_0);
+   writeb(0xff, p + UART_EXAR_MPIOSEL_7_0);
writeb(0x00, p + UART_EXAR_MPIOOD_7_0);
writeb(0x00, p + UART_EXAR_MPIOINT_15_8);
writeb(0x00, p + UART_EXAR_MPIOLVL_15_8);
writeb(0x00, p + UART_EXAR_MPIO3T_15_8);
writeb(0x00, p + UART_EXAR_MPIOINV_15_8);
-   writeb(0x00, p + UART_EXAR_MPIOSEL_15_8);
+   writeb(0xff, p + UART_EXAR_MPIOSEL_15_8);
writeb(0x00, p + UART_EXAR_MPIOOD_15_8);
 }
 
-- 
2.12.0

[PATCH 7/8] gpio-exar/8250-exar: Make set of exported GPIOs configurable

[Jan Kiszka]

On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
rest is required to operate the UART. To allow modeling this case,
use device properties to specify a (consecutive) pin subset for
exporting by the gpio-exar driver.

Signed-off-by: Jan Kiszka 
---
 drivers/gpio/gpio-exar.c| 31 ++-
 drivers/tty/serial/8250/8250_exar.c | 16 
 2 files changed, 34 insertions(+), 13 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 98bd3eb1290e..e2cb1d83e4b0 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -31,6 +31,7 @@ struct exar_gpio_chip {
int index;
void __iomem *regs;
char name[20];
+   unsigned int first_gpio;
 };
 
 static void exar_update(struct gpio_chip *chip, unsigned int reg, int val,
@@ -51,9 +52,11 @@ static void exar_update(struct gpio_chip *chip, unsigned int 
reg, int val,
 static int exar_set_direction(struct gpio_chip *chip, int direction,
  unsigned int offset)
 {
-   unsigned int bank = offset / 8;
-   unsigned int addr;
+   struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+   unsigned int bank, addr;
 
+   offset += exar_gpio->first_gpio;
+   bank = offset / 8;
addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
exar_update(chip, addr, direction, offset % 8);
return 0;
@@ -73,10 +76,12 @@ static int exar_get(struct gpio_chip *chip, unsigned int 
reg)
 
 static int exar_get_direction(struct gpio_chip *chip, unsigned int offset)
 {
-   unsigned int bank = offset / 8;
-   unsigned int addr;
+   struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+   unsigned int bank, addr;
int val;
 
+   offset += exar_gpio->first_gpio;
+   bank = offset / 8;
addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
val = exar_get(chip, addr) >> (offset % 8);
 
@@ -85,10 +90,12 @@ static int exar_get_direction(struct gpio_chip *chip, 
unsigned int offset)
 
 static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
 {
-   unsigned int bank = offset / 8;
-   unsigned int addr;
+   struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+   unsigned int bank, addr;
int val;
 
+   offset += exar_gpio->first_gpio;
+   bank = offset / 8;
addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
val = exar_get(chip, addr) >> (offset % 8);
 
@@ -98,9 +105,11 @@ static int exar_get_value(struct gpio_chip *chip, unsigned 
int offset)
 static void exar_set_value(struct gpio_chip *chip, unsigned int offset,
   int value)
 {
-   unsigned int bank = offset / 8;
-   unsigned int addr;
+   struct exar_gpio_chip *exar_gpio = gpiochip_get_data(chip);
+   unsigned int bank, addr;
 
+   offset += exar_gpio->first_gpio;
+   bank = offset / 8;
addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;
exar_update(chip, addr, value, offset % 8);
 }
@@ -123,6 +132,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
struct exar_gpio_chip *exar_gpio;
void __iomem *p;
int index, ret;
+   u32 val;
 
if (pcidev->vendor != PCI_VENDOR_ID_EXAR)
return -ENODEV;
@@ -152,9 +162,12 @@ static int gpio_exar_probe(struct platform_device *pdev)
exar_gpio->gpio_chip.get = exar_get_value;
exar_gpio->gpio_chip.set = exar_set_value;
exar_gpio->gpio_chip.base = -1;
-   exar_gpio->gpio_chip.ngpio = 16;
+   device_property_read_u32(&pdev->dev, "ngpio", &val);
+   exar_gpio->gpio_chip.ngpio = val;
exar_gpio->regs = p;
exar_gpio->index = index;
+   device_property_read_u32(&pdev->dev, "first_gpio", &val);
+   exar_gpio->first_gpio = val;
 
ret = devm_gpiochip_add_data(&pdev->dev,
 &exar_gpio->gpio_chip, exar_gpio);
diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
index 2d056d1eeca3..8e9c0e9495f5 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -188,8 +189,14 @@ static void setup_gpio(u8 __iomem *p)
 }
 
 static void *
-xr17v35x_register_gpio(struct pci_dev *pcidev)
+xr17v35x_register_gpio(struct pci_dev *pcidev, unsigned int first_gpio,
+  unsigned int ngpio)
 {
+   struct property_entry properties[] = {
+   PROPERTY_ENTRY_U32("first_gpio", first_gpio),
+   PROPERTY_ENTRY_U32("ngpio", ngpio),
+   { }
+   };
struct platform_device *pdev;
 
pdev = platform_device_alloc("gpio_exar", PLATFORM_DEVID_AUTO);
@@ -197,10 +204,11 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
return NULL;
 
/*
-* 

[PATCH 1/2] dt-bindings: timer: add nxp tpm timer binding doc

[Dong Aisheng]

Adding NXP Low Power Timer/Pulse Width Modulation Module (TPM)
binding doc.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: devicet...@vger.kernel.org
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Shawn Guo 
Cc: Bai Ping 
Signed-off-by: Dong Aisheng 
---
 .../devicetree/bindings/timer/nxp,tpm-timer.txt| 28 ++
 1 file changed, 28 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt 
b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
new file mode 100644
index 000..b4aa7dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/nxp,tpm-timer.txt
@@ -0,0 +1,28 @@
+NXP Low Power Timer/Pulse Width Modulation Module (TPM)
+
+The Timer/PWM Module (TPM) supports input capture, output compare,
+and the generation of PWM signals to control electric motor and power
+management applications. The counter, compare and capture registers
+are clocked by an asynchronous clock that can remain enabled in low
+power modes. TPM can support global counter bus where one TPM drives
+the counter bus for the others, provided bit width is the same.
+
+Required properties:
+
+- compatible : should be "fsl,imx7ulp-tpm"
+- reg :Specifies base physical address and size of the 
register sets
+   for the clock event device and clock source device.
+- interrupts : Should be the clock event device interrupt.
+- clocks : The clocks provided by the SoC to drive the timer, must contain
+   an entry for each entry in clock-names.
+- clock-names : Must include the following entries: "igp" and "per".
+
+Example:
+tpm5: tpm@4026 {
+   compatible = "fsl,imx7ulp-tpm";
+   reg = <0x4026 0x1000>;
+   interrupts = ;
+   clocks = <&clks IMX7ULP_CLK_NIC1_BUS_DIV>,
+<&clks IMX7ULP_CLK_LPTPM5>;
+   clock-names = "ipg", "per";
+};
-- 
2.7.4

[PATCH 3/8] gpio: exar: Allocate resources on behalf of the platform device

[Jan Kiszka]

Do not allocate resources on behalf of the parent device but on our own.
Otherwise, cleanup does not properly work if gpio-exar is removed but
not the parent device.

Signed-off-by: Jan Kiszka 
---
 drivers/gpio/gpio-exar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 0a2085faf271..9138ee087c5d 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -139,7 +139,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
if (!p)
return -ENOMEM;
 
-   exar_gpio = devm_kzalloc(&pcidev->dev, sizeof(*exar_gpio), GFP_KERNEL);
+   exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL);
if (!exar_gpio)
return -ENOMEM;
 
@@ -160,7 +160,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
exar_gpio->regs = p;
exar_gpio->index = index;
 
-   ret = devm_gpiochip_add_data(&pcidev->dev,
+   ret = devm_gpiochip_add_data(&pdev->dev,
 &exar_gpio->gpio_chip, exar_gpio);
if (ret)
goto err_destroy;
-- 
2.12.0

[PATCH 2/2] timer: imx-tpm: add imx tpm timer support

[Dong Aisheng]

IMX Timer/PWM Module (TPM) supports both timer and pwm function while
this patch only adds the timer support. PWM would be added later.

The TPM counter, compare and capture registers are clocked by an
asynchronous clock that can remain enabled in low power modes.

Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Shawn Guo 
Signed-off-by: Anson Huang 
Signed-off-by: Bai Ping 
Signed-off-by: Dong Aisheng 
---
 drivers/clocksource/Kconfig |   5 +
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-imx-tpm.c | 204 
 3 files changed, 210 insertions(+)
 create mode 100644 drivers/clocksource/timer-imx-tpm.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 3356ab8..03dfd6a 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -590,6 +590,11 @@ config CLKSRC_IMX_GPT
depends on ARM && CLKDEV_LOOKUP
select CLKSRC_MMIO
 
+config CLKSRC_IMX_TPM
+   bool "Clocksource using i.MX TPM" if COMPILE_TEST
+   depends on ARM && CLKDEV_LOOKUP && GENERIC_CLOCKEVENTS
+   select CLKSRC_MMIO
+
 config CLKSRC_ST_LPC
bool "Low power clocksource found in the LPC" if COMPILE_TEST
select CLKSRC_OF if OF
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index d227d13..7a8c0d1 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -67,6 +67,7 @@ obj-$(CONFIG_CLKSRC_VERSATILE)+= versatile.o
 obj-$(CONFIG_CLKSRC_MIPS_GIC)  += mips-gic-timer.o
 obj-$(CONFIG_CLKSRC_TANGO_XTAL)+= tango_xtal.o
 obj-$(CONFIG_CLKSRC_IMX_GPT)   += timer-imx-gpt.o
+obj-$(CONFIG_CLKSRC_IMX_TPM)   += timer-imx-tpm.o
 obj-$(CONFIG_ASM9260_TIMER)+= asm9260_timer.o
 obj-$(CONFIG_H8300_TMR8)   += h8300_timer8.o
 obj-$(CONFIG_H8300_TMR16)  += h8300_timer16.o
diff --git a/drivers/clocksource/timer-imx-tpm.c 
b/drivers/clocksource/timer-imx-tpm.c
new file mode 100644
index 000..f8a8a04
--- /dev/null
+++ b/drivers/clocksource/timer-imx-tpm.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ * Copyright 2017 NXP
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TPM_SC 0x10
+#define TPM_SC_CMOD_INC_PER_CNT(0x1 << 3)
+#define TPM_SC_CMOD_DIV_DEFAULT0x3
+#define TPM_CNT0x14
+#define TPM_MOD0x18
+#define TPM_STATUS 0x1c
+#define TPM_STATUS_CH0FBIT(0)
+#define TPM_C0SC   0x20
+#define TPM_C0SC_CHIE  BIT(6)
+#define TPM_C0SC_MODE_SHIFT2
+#define TPM_C0SC_MODE_MASK 0x3c
+#define TPM_C0SC_MODE_SW_COMPARE   0x4
+#define TPM_C0V0x24
+
+static void __iomem *timer_base;
+static struct clock_event_device clockevent_tpm;
+
+static inline void tpm_timer_disable(void)
+{
+   unsigned int val;
+
+   /* channel disable */
+   val = __raw_readl(timer_base + TPM_C0SC);
+   val &= ~(TPM_C0SC_MODE_MASK | TPM_C0SC_CHIE);
+   __raw_writel(val, timer_base + TPM_C0SC);
+}
+
+static inline void tpm_timer_enable(void)
+{
+   unsigned int val;
+
+   /* channel enabled in sw compare mode */
+   val = __raw_readl(timer_base + TPM_C0SC);
+   val |= (TPM_C0SC_MODE_SW_COMPARE << TPM_C0SC_MODE_SHIFT) |
+  TPM_C0SC_CHIE;
+   __raw_writel(val, timer_base + TPM_C0SC);
+}
+
+static inline void tpm_irq_acknowledge(void)
+{
+   __raw_writel(TPM_STATUS_CH0F, timer_base + TPM_STATUS);
+}
+
+static struct delay_timer tpm_delay_timer;
+
+static unsigned long tpm_read_current_timer(void)
+{
+   return __raw_readl(timer_base + TPM_CNT);
+}
+
+static u64 notrace tpm_read_sched_clock(void)
+{
+   return __raw_readl(timer_base + TPM_CNT);
+}
+
+static int __init tpm_clocksource_init(unsigned long rate)
+{
+   tpm_delay_timer.read_current_timer = &tpm_read_current_timer;
+   tpm_delay_timer.freq = rate;
+   register_current_timer_delay(&tpm_delay_timer);
+
+   sched_clock_register(tpm_read_sched_clock, 32, rate);
+
+   return clocksource_mmio_init(timer_base + TPM_CNT, "imx-tpm",
+rate, 200, 32, clocksource_mmio_readl_up);
+}
+
+static int tpm_set_next_event(unsigned long delta,
+   struct clock_event_device *evt)
+{
+   unsigned long next, now;
+
+   next = __raw_readl(timer_base + TPM_CNT) + delta;
+   __raw_writel(next, timer_base + TPM_C0V);
+   now = __raw_readl(timer_base + T

[PATCH 4/8] gpio: exar: Fix iomap request

[Jan Kiszka]

The UART driver already maps the resource for us. Trying to do this here
only fails and leaves us with a non-working device.

Signed-off-by: Jan Kiszka 
---
 drivers/gpio/gpio-exar.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
index 9138ee087c5d..d6ffb3d89b9c 100644
--- a/drivers/gpio/gpio-exar.c
+++ b/drivers/gpio/gpio-exar.c
@@ -128,14 +128,10 @@ static int gpio_exar_probe(struct platform_device *pdev)
return -ENODEV;
 
/*
-* Map the pci device to get the register addresses.
-* We will need to read and write those registers to control
-* the GPIO pins.
-* Using managed functions will save us from unmaping on exit.
-* As the device is enabled using managed functions by the
-* UART driver we can also use managed functions here.
+* The UART driver must have mapped region 0 prior to registering this
+* device - use it.
 */
-   p = pcim_iomap(pcidev, 0, 0);
+   p = pcim_iomap_table(pcidev)[0];
if (!p)
return -ENOMEM;
 
-- 
2.12.0

[PATCH 8/8] serial: exar: Add support for IOT2040 device

[Jan Kiszka]

This implements the setup of RS232 and the switch-over to RS485 or RS422
for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
to switch between the different modes. The external logic is controlled
via MPIO pins of the EXAR controller.

Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
an LED.

As the XR17V352 used on the IOT2040 is not equipped with an external
EEPROM, it cannot present itself as IOT2040-variant via subvendor/
subdevice IDs. Thus, we have to check via DMI for the target platform.

Co-developed with Sascha Weisenberger.

Signed-off-by: Sascha Weisenberger 
Signed-off-by: Jan Kiszka 
---
 drivers/tty/serial/8250/8250_exar.c | 121 ++--
 1 file changed, 116 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_exar.c 
b/drivers/tty/serial/8250/8250_exar.c
index 8e9c0e9495f5..62fe0f1ddcfe 100644
--- a/drivers/tty/serial/8250/8250_exar.c
+++ b/drivers/tty/serial/8250/8250_exar.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -61,6 +62,43 @@
 #define UART_EXAR_MPIOSEL_15_8 0x99/* MPIOSEL[15:8] */
 #define UART_EXAR_MPIOOD_15_8  0x9a/* MPIOOD[15:8] */
 
+#define UART_EXAR_RS485_DLY(x) (x << 4)
+
+/*
+ * IOT2040 MPIO wiring semantics:
+ *
+ * MPIOPortFunction
+ * 
+ * 0   2   Mode bit 0
+ * 1   2   Mode bit 1
+ * 2   2   Terminate bus
+ * 3   -   
+ * 4   3   Mode bit 0
+ * 5   3   Mode bit 1
+ * 6   3   Terminate bus
+ * 7   -   
+ * 8   2   Enable
+ * 9   3   Enable
+ * 10  -   Red LED
+ * 11..15  -   
+ */
+
+/* IOT2040 MPIOs 0..7 */
+#define IOT2040_UART_MODE_RS2320x01
+#define IOT2040_UART_MODE_RS4850x02
+#define IOT2040_UART_MODE_RS4220x03
+#define IOT2040_UART_TERMINATE_BUS 0x04
+
+#define IOT2040_UART1_MASK 0x0f
+#define IOT2040_UART2_SHIFT4
+
+#define IOT2040_UARTS_DEFAULT_MODE 0x11/* both RS232 */
+#define IOT2040_UARTS_GPIO_LO_MODE 0x88/* reserved pins as input */
+
+/* IOT2040 MPIOs 8..15 */
+#define IOT2040_UARTS_ENABLE   0x03
+#define IOT2040_UARTS_GPIO_HI_MODE 0xF8/* enable & LED as outputs */
+
 struct exar8250;
 
 /**
@@ -217,6 +255,65 @@ xr17v35x_register_gpio(struct pci_dev *pcidev, unsigned 
int first_gpio,
return pdev;
 }
 
+static int iot2040_rs485_config(struct uart_port *port,
+   struct serial_rs485 *rs485)
+{
+   u8 __iomem *p = port->membase;
+   u8 mask = IOT2040_UART1_MASK;
+   u8 mode, value;
+   bool is_rs485 = false;
+
+   if (rs485->flags & SER_RS485_ENABLED) {
+   is_rs485 = true;
+   if (rs485->flags & SER_RS485_RX_DURING_TX)
+   mode = IOT2040_UART_MODE_RS422;
+   else
+   mode = IOT2040_UART_MODE_RS485;
+
+   if (rs485->flags & SER_RS485_TERMINATE_BUS)
+   mode |= IOT2040_UART_TERMINATE_BUS;
+   } else {
+   mode = IOT2040_UART_MODE_RS232;
+   }
+
+   if (port->line == 3) {
+   mask <<= IOT2040_UART2_SHIFT;
+   mode <<= IOT2040_UART2_SHIFT;
+   }
+
+   value = readb(p + UART_EXAR_MPIOLVL_7_0);
+   value &= ~mask;
+   value |= mode;
+   writeb(value, p + UART_EXAR_MPIOLVL_7_0);
+
+   value = readb(p + UART_EXAR_FCTR);
+   if (is_rs485)
+   value |= UART_FCTR_EXAR_485;
+   else
+   value &= ~UART_FCTR_EXAR_485;
+   writeb(value, p + UART_EXAR_FCTR);
+
+   if (is_rs485)
+   writeb(UART_EXAR_RS485_DLY(4), p + UART_MSR);
+
+   return 0;
+}
+
+static int iot2000_setup_gpio(struct pci_dev *pcidev,
+ struct uart_8250_port *port)
+{
+   u8 __iomem *p = port->port.membase;
+
+   writeb(IOT2040_UARTS_DEFAULT_MODE, p + UART_EXAR_MPIOLVL_7_0);
+   writeb(IOT2040_UARTS_GPIO_LO_MODE, p + UART_EXAR_MPIOSEL_7_0);
+   writeb(IOT2040_UARTS_ENABLE, p + UART_EXAR_MPIOLVL_15_8);
+   writeb(IOT2040_UARTS_GPIO_HI_MODE, p + UART_EXAR_MPIOSEL_15_8);
+
+   port->port.private_data = xr17v35x_register_gpio(pcidev, 10, 1);
+
+   return 0;
+}
+
 static int
 pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev *pcidev,
   struct uart_8250_port *port, int idx)
@@ -224,10 +321,20 @@ pci_xr17v35x_setup(struct exar8250 *priv, struct pci_dev 
*pcidev,
const struct exar8250_board *board = priv->board;
unsigned int offset = idx * 0x400;
unsigned int baud = 7812500;
+   bool is_iot2040;
u8 __iomem *p;
int ret;
 
port->port.uartclk = baud * 16;
+
+   is_iot2040 =
+   strcmp(dmi_get_system_info(DMI_BOARD_NAME),
+  "SIM

[PATCH 6/8] serial: uapi: Add support for bus termination

[Jan Kiszka]

The Siemens IOT2040 comes with a RS485 interface that allows to enable
or disable bus termination via software. Add a bit to the flags field of
serial_rs485 that applications can set in order to request this feature
from the hardware. This seems generic enough to add it for everyone.
Existing driver will simply ignore it when set.

Signed-off-by: Sascha Weisenberger 
Signed-off-by: Jan Kiszka 
---
 include/uapi/linux/serial.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h
index 5d59c3ebf459..d2667ecd54ac 100644
--- a/include/uapi/linux/serial.h
+++ b/include/uapi/linux/serial.h
@@ -122,6 +122,9 @@ struct serial_rs485 {
 #define SER_RS485_RTS_AFTER_SEND   (1 << 2)/* Logical level for
   RTS pin after sent*/
 #define SER_RS485_RX_DURING_TX (1 << 4)
+#define SER_RS485_TERMINATE_BUS(1 << 5)/* Enable bus
+  termination
+  (if supported) */
__u32   delay_rts_before_send;  /* Delay before send (milliseconds) */
__u32   delay_rts_after_send;   /* Delay after send (milliseconds) */
__u32   padding[5]; /* Memory is cheap, new structs
-- 
2.12.0

[PATCH 0/8] serial/gpio: exar: Fixes and support for IOT2000

[Jan Kiszka]

This makes the gpio-exar driver usable, which was prevented by a number
of fatal bugs, and adds support for the SIMATIC IOT2040 to the 8250-exar
driver and, indirectly, to gpio-exar as well. It's a cross-subsystem
series, so I'm also cross-posting to the serial and gpio lists.

Jan

Jan Kiszka (8):
  serial: exar: Preconfigure xr17v35x MPIOs as output
  gpio: exar: Fix passing in of parent PCI device
  gpio: exar: Allocate resources on behalf of the platform device
  gpio: exar: Fix iomap request
  gpio: exar: Fix reading of directions and values
  serial: uapi: Add support for bus termination
  gpio-exar/8250-exar: Make set of exported GPIOs configurable
  serial: exar: Add support for IOT2040 device

 drivers/gpio/gpio-exar.c|  55 --
 drivers/tty/serial/8250/8250_exar.c | 145 +---
 include/uapi/linux/serial.h |   3 +
 3 files changed, 169 insertions(+), 34 deletions(-)

-- 
2.12.0

Re: [PATCH] usb: gadget: f_fs: use memdup_user

[Dan Carpenter]

On Sat, May 13, 2017 at 11:15:59AM +0800, Geliang Tang wrote:
> Use memdup_user() helper instead of open-coding to simplify the code.
> 
> Signed-off-by: Geliang Tang 
> ---
>  drivers/usb/gadget/function/f_fs.c | 11 +++
>  1 file changed, 3 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/usb/gadget/function/f_fs.c 
> b/drivers/usb/gadget/function/f_fs.c
> index 71dd27c..5754538 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -3692,14 +3692,9 @@ static char *ffs_prepare_buffer(const char __user 
> *buf, size_t len)
>   if (unlikely(!len))
>   return NULL;
>  
> - data = kmalloc(len, GFP_KERNEL);
> - if (unlikely(!data))
> - return ERR_PTR(-ENOMEM);
> -
> - if (unlikely(copy_from_user(data, buf, len))) {
> - kfree(data);
> - return ERR_PTR(-EFAULT);
> - }
> + data = memdup_user(buf, len);
> + if (unlikely(IS_ERR(data)))

Don't use likely/unlikely() here.  It's not a fast path.

regards,
dan carpenter

[PATCH linux-next] kcmp: fs/epoll -- Wrap kcmp code with CONFIG_CHECKPOINT_RESTORE

[Cyrill Gorcunov]

kcmp syscall is build iif CONFIG_CHECKPOINT_RESTORE is selected,
so wrap appropriate helpers in epoll code with the config to
build it conditionally.

Signed-off-by: Cyrill Gorcunov 
Reported-by: Andrew Morton 
CC: Andrey Vagin 
CC: Al Viro 
CC: Pavel Emelyanov 
CC: Michael Kerrisk 
CC: Jason Baron 
CC: Andy Lutomirski 
---
 fs/eventpoll.c|2 ++
 include/linux/eventpoll.h |2 ++
 2 files changed, 4 insertions(+)

Index: linux-ml.git/fs/eventpoll.c
===
--- linux-ml.git.orig/fs/eventpoll.c
+++ linux-ml.git/fs/eventpoll.c
@@ -1077,6 +1077,7 @@ static struct epitem *ep_find(struct eve
return epir;
 }
 
+#ifdef CONFIG_CHECKPOINT_RESTORE
 static struct epitem *ep_find_tfd(struct eventpoll *ep, int tfd, unsigned long 
toff)
 {
struct rb_node *rbp;
@@ -1118,6 +1119,7 @@ struct file *get_epoll_tfile_raw_ptr(str
 
return file_raw;
 }
+#endif /* CONFIG_CHECKPOINT_RESTORE */
 
 /*
  * This is the callback that is passed to the wait queue wakeup
Index: linux-ml.git/include/linux/eventpoll.h
===
--- linux-ml.git.orig/include/linux/eventpoll.h
+++ linux-ml.git/include/linux/eventpoll.h
@@ -23,7 +23,9 @@ struct file;
 
 #ifdef CONFIG_EPOLL
 
+#ifdef CONFIG_CHECKPOINT_RESTORE
 struct file *get_epoll_tfile_raw_ptr(struct file *file, int tfd, unsigned long 
toff);
+#endif
 
 /* Used to initialize the epoll bits inside the "struct file" */
 static inline void eventpoll_init_file(struct file *file)

[PATCH 0/2] Industry-pack bus: Adjustments for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 13 May 2017 10:45:54 +0200

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation in 
ipack_device_read_id()
  Improve a size determination in ipack_bus_register()

 drivers/ipack/ipack.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

-- 
2.12.3

[PATCH 1/2] ipack: Delete an error message for a failed memory allocation in ipack_device_read_id()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 13 May 2017 10:20:07 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 drivers/ipack/ipack.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
index 12102448fddd..575c4f29e0f7 100644
--- a/drivers/ipack/ipack.c
+++ b/drivers/ipack/ipack.c
@@ -402,7 +402,6 @@ static int ipack_device_read_id(struct ipack_device *dev)
 * ID ROM contents */
dev->id = kmalloc(dev->id_avail, GFP_KERNEL);
if (!dev->id) {
-   dev_err(&dev->dev, "dev->id alloc failed.\n");
ret = -ENOMEM;
goto out;
}
-- 
2.12.3

[PATCH 2/2] ipack: Improve a size determination in ipack_bus_register()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 13 May 2017 10:37:06 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

Signed-off-by: Markus Elfring 
---
 drivers/ipack/ipack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ipack/ipack.c b/drivers/ipack/ipack.c
index 575c4f29e0f7..a1e07a77d4e6 100644
--- a/drivers/ipack/ipack.c
+++ b/drivers/ipack/ipack.c
@@ -212,7 +212,7 @@ struct ipack_bus_device *ipack_bus_register(struct device 
*parent, int slots,
int bus_nr;
struct ipack_bus_device *bus;
 
-   bus = kzalloc(sizeof(struct ipack_bus_device), GFP_KERNEL);
+   bus = kzalloc(sizeof(*bus), GFP_KERNEL);
if (!bus)
return NULL;
 
-- 
2.12.3

Re: [PATCH 21/36] fs: locks: Fix some troubles at kernel-doc comments

[Mauro Carvalho Chehab]

Hi Jeff,

Em Fri, 12 May 2017 10:02:56 -0400
Jeff Layton  escreveu:

> On Fri, 2017-05-12 at 11:00 -0300, Mauro Carvalho Chehab wrote:
> > There are a few syntax violations that cause outputs of
> > a few comments to not be properly parsed in ReST format.
> > 
> > No functional changes.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >  fs/locks.c | 18 --
> >  1 file changed, 8 insertions(+), 10 deletions(-)
> > 
> > diff --git a/fs/locks.c b/fs/locks.c
> > index 26811321d39b..bdce708e4251 100644
> > --- a/fs/locks.c
> > +++ b/fs/locks.c
> > @@ -1858,8 +1858,8 @@ EXPORT_SYMBOL(generic_setlease);
> >   *
> >   * Call this to establish a lease on the file. The "lease" argument is not
> >   * used for F_UNLCK requests and may be NULL. For commands that set or 
> > alter
> > - * an existing lease, the (*lease)->fl_lmops->lm_break operation must be 
> > set;
> > - * if not, this function will return -ENOLCK (and generate a scary-looking
> > + * an existing lease, the ``(*lease)->fl_lmops->lm_break`` operation must 
> > be
> > + * set; if not, this function will return -ENOLCK (and generate a 
> > scary-looking
> >   * stack trace).
> >   *
> >   * The "priv" pointer is passed directly to the lm_setup function as-is. It
> > @@ -1972,15 +1972,13 @@ EXPORT_SYMBOL(locks_lock_inode_wait);
> >   * @cmd: the type of lock to apply.
> >   *
> >   * Apply a %FL_FLOCK style lock to an open file descriptor.
> > - * The @cmd can be one of
> > + * The @cmd can be one of:
> >   *
> > - * %LOCK_SH -- a shared lock.
> > - *
> > - * %LOCK_EX -- an exclusive lock.
> > - *
> > - * %LOCK_UN -- remove an existing lock.
> > - *
> > - * %LOCK_MAND -- a `mandatory' flock.  This exists to emulate Windows 
> > Share Modes.
> > + * - %LOCK_SH -- a shared lock.
> > + * - %LOCK_EX -- an exclusive lock.
> > + * - %LOCK_UN -- remove an existing lock.
> > + * - %LOCK_MAND -- a 'mandatory' flock.
> > + *   This exists to emulate Windows Share Modes.
> >   *
> >   * %LOCK_MAND can be combined with %LOCK_READ or %LOCK_WRITE to allow other
> >   * processes read and write access respectively.  
> 
> LGTM. Do you need me or Bruce to pick this one up?

Feel free to pick it, if it works best for you.

> Reviewed-by: Jeff Layton 


Thanks,
Mauro

Re: [PATCH 03/36] docs-rst: convert kernel-locking to ReST

[Mauro Carvalho Chehab]

Em Fri, 12 May 2017 18:57:13 +0200
Markus Heiser  escreveu:

> Am 12.05.2017 um 15:59 schrieb Mauro Carvalho Chehab 
> :
> 
> > Use pandoc to convert documentation to ReST by calling
> > Documentation/sphinx/tmplcvt script.
> > 
> > - Manually adjust tables with got broken by conversion
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> > Documentation/DocBook/Makefile|1 -
> > Documentation/DocBook/kernel-locking.tmpl | 2151 
> > -
> > Documentation/kernel-hacking/hacking.rst  |  811 +++
> > Documentation/kernel-hacking/index.rst|  814 +--
> > Documentation/kernel-hacking/locking.rst  | 1453 +++
> > 5 files changed, 2268 insertions(+), 2962 deletions(-)
> > delete mode 100644 Documentation/DocBook/kernel-locking.tmpl
> > create mode 100644 Documentation/kernel-hacking/hacking.rst
> > create mode 100644 Documentation/kernel-hacking/locking.rst
> > 
> > ...  
> 
> > diff --git a/Documentation/kernel-hacking/index.rst 
> > b/Documentation/kernel-hacking/index.rst
> > index 1a456b60a7cf..b3d8fe56d310 100644
> > --- a/Documentation/kernel-hacking/index.rst
> > +++ b/Documentation/kernel-hacking/index.rst
> > @@ -1,811 +1,5 @@
> > -
> > -Unreliable Guide To Hacking The Linux Kernel
> > -
> > +.. toctree::
> > +   :maxdepth: 2  
> 
> Every .rst file needs a title, otherwise  is inserted,
> see breadcrumb at the top :
> 
>  https://mchehab.fedorapeople.org/kernel_docs/kernel-hacking/index.html

Thanks for review!

I'll fold it with the enclosed path.

diff --git a/Documentation/conf.py b/Documentation/conf.py
index bfa95c881956..0ce8001a50b6 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -352,7 +352,7 @@ latex_documents = [
  'The kernel development community', 'manual'),
 ('kernel-documentation', 'kernel-documentation.tex', 'The Linux Kernel 
Documentation',
  'The kernel development community', 'manual'),
-('kernel-hacking/index', 'kernel-hacking.tex', 'Unreliable Guide To 
Hacking The Linux Kernel',
+('kernel-hacking/index', 'kernel-hacking.tex', 'Kernel Hacking Guides',
  'The kernel development community', 'manual'),
 ('process/index', 'development-process.tex', 'Linux Kernel Development 
Documentation',
  'The kernel development community', 'manual'),
diff --git a/Documentation/kernel-hacking/conf.py 
b/Documentation/kernel-hacking/conf.py
index 4facca74a6f0..3d8acf0f33ad 100644
--- a/Documentation/kernel-hacking/conf.py
+++ b/Documentation/kernel-hacking/conf.py
@@ -1,6 +1,6 @@
 # -*- coding: utf-8; mode: python -*-
 
-project = "Unreliable Guide To Hacking The Linux Kernel"
+project = "Kernel Hacking Guides"
 
 tags.add("subproject")
 
diff --git a/Documentation/kernel-hacking/index.rst 
b/Documentation/kernel-hacking/index.rst
index b3d8fe56d310..fcb0eda3cca3 100644
--- a/Documentation/kernel-hacking/index.rst
+++ b/Documentation/kernel-hacking/index.rst
@@ -1,3 +1,7 @@
+=
+Kernel Hacking Guides
+=
+
 .. toctree::
:maxdepth: 2
 
diff --git a/Documentation/kernel-hacking/hacking.rst 
b/Documentation/kernel-hacking/hacking.rst
index 1a456b60a7cf..58831decd5ae 100644
--- a/Documentation/kernel-hacking/hacking.rst
+++ b/Documentation/kernel-hacking/hacking.rst
@@ -764,7 +764,7 @@ Some favorites from browsing the source. Feel free to add 
to this list.
  #define PTR_ERR(ptr)((long)(ptr))
  #define IS_ERR(ptr) ((unsigned long)(ptr) > (unsigned long)(-1000))
 
-``arch/x86/include/asm/uaccess_32.h:``::
+``arch/x86/include/asm/uaccess_32.h``::
 
 #define copy_to_user(to,from,n) \
 (__builtin_constant_p(n) ?  \
@@ -772,7 +772,7 @@ Some favorites from browsing the source. Feel free to add 
to this list.
  __generic_copy_to_user((to),(from),(n)))
 
 
-``arch/sparc/kernel/head.S:``::
+``arch/sparc/kernel/head.S``::
 
 /*
  * Sun people can't spell worth damn. "compatability" indeed.
@@ -791,7 +791,7 @@ Some favorites from browsing the source. Feel free to add 
to this list.
 .asciz "compatible"
 
 
-``arch/sparc/lib/checksum.S:``::
+``arch/sparc/lib/checksum.S``::
 
 /* Sun, you just can't beat me, you just can't.  Stop trying,
  * give up.  I'm serious, I am going to kick the living shit


Thanks,
Mauro

Re: Is there an recommended way to refer to bitkeepr commits?

[Thomas Gleixner]

On Fri, 12 May 2017, Eric W. Biederman wrote:
> Which leaves me perplexed.  The hashes from tglx's current tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
> on kernel.org and the hashes in your full history tree differ.
> Given that they are in theory the same tree this distrubs me.
> 
> Case in point in the commit connected to:
> "[PATCH] linux-2.5.66-signal-cleanup.patch"
> in tglx's tree is:   da334d91ff7001d234863fc7692de1ff90bed57a

That's the proper sha1 for my tree. I jsut verified it against the original
tree which I still have in my archive.

> *scratches my head*
> 
> Something appears to have changed somewhere.

Correct. That full history git rewrote the commits in my bitkeeper import.

history.git:

  commit 7a2deb32924142696b8174cdf9b38cd72a11fc96
  Author: Linus Torvalds 
  Date:   Mon Feb 4 17:40:40 2002 -0800

Import changeset

full-history:

  commit 26245c315da55330cb25dbfdd80be62db41dedb2
  Author: linus1 
  Date:   Thu Jan 4 12:00:00 2001 -0600

Import changeset

and as a consequence all other commits have different shas as well.

Sigh

Thanks,

tglx

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

[Mauro Carvalho Chehab]

Em Fri, 12 May 2017 15:19:17 -0700
Darren Hart  escreveu:

> On Sat, May 13, 2017 at 12:11:09AM +0200, Peter Zijlstra wrote:
> > On Fri, May 12, 2017 at 06:51:50PM -0300, Mauro Carvalho Chehab wrote:  
> > > >  * Return:
> > > >  *  *  0 - ready to wait
> > > >  *  *  1 - acquired the lock
> > > >  *  * <0 - error
> > > > 
> > > > I'm fine with either though, just curious if this would be an 
> > > > improvement, or if
> > > > we have an established policy (which I didn't find in the docs on 
> > > > docs...).  
> > > 
> > > I prefer myself to use "-". IMHO, a dash is visually less polluted
> > > than an asterisk, when reading text files, but I guess this is a
> > > matter of taste.  
> > 
> > Not to mention it just reads very awkward in a comment. I don't much
> > care about it in any other context.  
> 
> Agreed, the - is better (and equally functional - so yay).
> 
> > 
> > And I really _really_ hate to see that rest crap spread here. Can't we
> > just delete all that nonsense and go back to 80 column 7bit ASCII ?
> >   
> 
> Depending on the source this could be a genuine appeal or satire :-D
> 
> In this case, I don't think the ReST changes (with -) make the comment block 
> any
> less readable in the C files.
> 
> > It is an incentive not to use kerneldoc..

Very few kerneldoc markups need changes due to ReST introduction, and
usually is just whitespace/blank lines adjustment. Ok, someone could
try to improve the script to make it smarter[1], but, on my experiences
addressing it, usually doing the required changes make it visually
better on both C file and on PDF/LaTeX/HTML outputs.

[1] probably rewriting the entire script to work more like a lexical
interpreter than a bunch of rejex expressions.

> I like the kerneldoc if for no other reason that it helps keeps formatting
> consistent. I would object if I started seeing XML or some other horrible
> formatting style showing up in the code, but this honestly seems like a fairly
> minimal imposition... but that's me.

IMHO, the best thing with kerneldoc is that it helps to keep the
documentation updated, as it warns when someone change the function
arguments without updating the comments.

Thanks,
Mauro

Re: [PATCH 01/36] docs-rst: convert kernel-hacking to ReST

[Mauro Carvalho Chehab]

Em Fri, 12 May 2017 18:35:29 +0200
Markus Heiser  escreveu:

> Am 12.05.2017 um 15:59 schrieb Mauro Carvalho Chehab 
> :
> 
> > Use pandoc to convert documentation to ReST by calling
> > Documentation/sphinx/tmplcvt script.
> > 
> > - Manually adjusted to use ..note and ..warning
> > - Minor fixes for it to be parsed without errors
> > - Use **bold** for emphasis.
> > 
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> > Documentation/DocBook/Makefile|2 +-
> > Documentation/DocBook/kernel-hacking.tmpl | 1312 
> > -
> > Documentation/conf.py |2 +
> > Documentation/index.rst   |1 +
> > Documentation/kernel-hacking/conf.py  |   10 +
> > Documentation/kernel-hacking/index.rst|  794 +
> > 6 files changed, 808 insertions(+), 1313 deletions(-)
> > delete mode 100644 Documentation/DocBook/kernel-hacking.tmpl
> > create mode 100644 Documentation/kernel-hacking/conf.py
> > create mode 100644 Documentation/kernel-hacking/index.rst
> > 
> >   
> 
> 
> > +:c:func:`cpu_to_be32()`/:c:func:`be32_to_cpu()`/:c:func:`cpu_to_le32()`/:c:func:`le32_to_cpu()`
> >  ``include/asm/byteorder.h``
> > +---
> > +  
> 
> Hi Mauro, just my bikeshedding:
> 
> what do you think, do we really need to refer functions in titles?
> As far as I know, there is no use-case where we can get any benefit
> from. So I recommend to write titles more simple, e.g.:
> 
>   cpu_to_be32()/be32_to_cpu()/cpu_to_le32()/le32_to_cpu() 
> include/asm/byteorder.h
> 
> .. which is long enough ;)

There are some functions there that are only mentioned at the title,
like: local_bh_disable().

IMHO, it is a good idea to add a cross-reference to those, as it
helps the reader to get further information if needed. So, except if
this would cause Sphinx to crash, I prefer to keep the references.

What I did, instead, on patch 02/36 is to move all header references
to be outside the title:

+:c:func:`cpu_to_be32()`/:c:func:`be32_to_cpu()`/:c:func:`cpu_to_le32()`/:c:func:`le32_to_cpu()`
+---
+
+Defined in ``include/asm/byteorder.h``
 

With reduces the displayed title to something reasonable.

Thanks,
Mauro

[PATCH 1/2] fdt: correctly handle uncompressed node names

[Sascha Silbe]

When handling uncompressed node names, we need to compare the last
component rather than the entire string.

Signed-off-by: Sascha Silbe 
---
 scripts/dtc/libfdt/fdt_ro.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/dtc/libfdt/fdt_ro.c b/scripts/dtc/libfdt/fdt_ro.c
index 3d00d2eee0e3..ca03ff87429c 100644
--- a/scripts/dtc/libfdt/fdt_ro.c
+++ b/scripts/dtc/libfdt/fdt_ro.c
@@ -64,6 +64,9 @@ static int _fdt_nodename_eq(const void *fdt, int offset,
/* short match */
return 0;
 
+   if (*p == '/')
+   /* Uncompressed node name. Only compare the last part. */
+   p = strrchr(p, '/') + 1;
if (memcmp(p, s, len) != 0)
return 0;
 
-- 
2.11.0

[PATCH 2/2] of: fdt: fix unflattening of FDTs containing uncompressed paths

[Sascha Silbe]

Probably since commit dfbd4c6eff35 ("drivers/of: Split
unflatten_dt_node()"), unflattening an FDT containing uncompressed
node names (e.g. "/gpio@d4019000/gpio@0") will abort after scanning
the root node because fpsize wasn't updated to include the path len.

Signed-off-by: Sascha Silbe 
---
 drivers/of/fdt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index e5ce4b59e162..2d5414e644b3 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -309,6 +309,8 @@ static unsigned int populate_node(const void *blob,
fpsize += l;
allocl = fpsize;
}
+   } else {
+   fpsize += allocl;
}
 
np = unflatten_dt_alloc(mem, sizeof(struct device_node) + allocl,
-- 
2.11.0

[PATCH 0/2] FDT fixes for running on native Open Firmware

[Sascha Silbe]

Two fixes for bugs in the FDT code I discovered while trying to get
the mainline kernel to run on OLPC XO-1.75. XOs are running Open
Firmware natively, not just passing down some blob.

Sascha Silbe (2):
  fdt: correctly handle uncompressed node names
  of: fdt: fix unflattening of FDTs containing uncompressed paths

 drivers/of/fdt.c| 2 ++
 scripts/dtc/libfdt/fdt_ro.c | 3 +++
 2 files changed, 5 insertions(+)

-- 
2.11.0

Re: [PATCH v1] samples/bpf: Add a .gitignore for binaries

[Mickaël Salaün]

On 13/02/2017 02:43, David Ahern wrote:
> On 2/12/17 2:23 PM, Mickaël Salaün wrote:
>> diff --git a/samples/bpf/.gitignore b/samples/bpf/.gitignore
>> new file mode 100644
>> index ..a7562a5ef4c2
>> --- /dev/null
>> +++ b/samples/bpf/.gitignore
>> @@ -0,0 +1,32 @@
>> +fds_example
>> +lathist
> 
> ...
> 
> Listing each target is going to be a PITA to maintain. It would be
> better to put targets into a build directory (bin?) and ignore the
> directory.
> 

It would require a lot of modifications to the Makefile and more
complexity. It seems much more simple for everyone to stick to a simple
gitignore file easily maintainable:
$ awk '$1 == "hostprogs-y" { print $3 }' < Makefile > .gitignore

Alexei, Daniel, what do you think about this? Do you want me to send a
v2 with the new tests?

 Mickaël



signature.asc
Description: OpenPGP digital signature

You Just Won Qatar Foundation Donation**Treat Urgently

[QATAR]

Dear Beneficiary,

You have been selected to receive (950,000.00 EURO) as charity donations / aid 
from the Qatar Foundation. Please kindly provide the
below information details mention.


1. Your Full Name:
2. Country:
3. Marital Status:
4. Age:
5. Occupation:
6. Telephone:
7. Home Address:

Note: This donation funds  will be send to you Via ATM Master Card

Yours sincerely,
Engineer Saad Al Muhannadi.
President of the Qatar Foundation.

Re: [PATCH] serial: altera_jtaguart: adding iounmap()

[Tobias Klauser]

On 2017-05-12 at 23:36:22 +0200, Alexey Khoroshilov  
wrote:
> The driver does ioremap(port->mapbase, ALTERA_JTAGUART_SIZE),
> but there is no any iounmap().
> 
> Found by Linux Driver Verification project (linuxtesting.org).
> 
> Signed-off-by: Alexey Khoroshilov 

Acked-by: Tobias Klauser 

Thanks!

[PATCH 4/5] mtd: adjust kernel-docs to avoid Sphinx/kerneldoc warnings

[Mauro Carvalho Chehab]

./drivers/mtd/nand/nand_bbt.c:1: warning: no structured comments found
./include/linux/mtd/nand.h:785: ERROR: Unexpected indentation.
./drivers/mtd/nand/nand_base.c:449: WARNING: Definition list ends without a 
blank line; unexpected unindent.
./drivers/mtd/nand/nand_base.c:1161: ERROR: Unexpected indentation.
./drivers/mtd/nand/nand_base.c:1162: WARNING: Block quote ends without a blank 
line; unexpected unindent.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/mtdnand.rst | 3 ---
 drivers/mtd/nand/nand_base.c | 7 +--
 include/linux/mtd/nand.h | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/driver-api/mtdnand.rst 
b/Documentation/driver-api/mtdnand.rst
index e670f8b15a79..4fe3bf00299b 100644
--- a/Documentation/driver-api/mtdnand.rst
+++ b/Documentation/driver-api/mtdnand.rst
@@ -970,9 +970,6 @@ hints" for an explanation.
 .. kernel-doc:: drivers/mtd/nand/nand_base.c
:export:
 
-.. kernel-doc:: drivers/mtd/nand/nand_bbt.c
-   :export:
-
 .. kernel-doc:: drivers/mtd/nand/nand_ecc.c
:export:
 
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index b0524f8accb6..c8988c01e0d7 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -442,10 +442,12 @@ static int nand_default_block_markbad(struct mtd_info 
*mtd, loff_t ofs)
  * specify how to write bad block markers to OOB (chip->block_markbad).
  *
  * We try operations in the following order:
+ *
  *  (1) erase the affected block, to allow OOB marker to be written cleanly
  *  (2) write bad block marker to OOB area of affected block (unless flag
  *  NAND_BBT_NO_OOB_BBM is present)
  *  (3) update the BBT
+ *
  * Note that we retain the first error encountered in (2) or (3), finish the
  * procedures, and dump the error in the end.
 */
@@ -1155,9 +1157,10 @@ int nand_reset(struct nand_chip *chip, int chipnr)
  * @mtd: mtd info
  * @ofs: offset to start unlock from
  * @len: length to unlock
- * @invert: when = 0, unlock the range of blocks within the lower and
+ * @invert:
+ *- when = 0, unlock the range of blocks within the lower and
  *upper boundary address
- *  when = 1, unlock the range of blocks outside the boundaries
+ *- when = 1, unlock the range of blocks outside the boundaries
  *of the lower and upper boundary address
  *
  * Returs unlock status.
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 9591e0fbe5bd..3d5b20379ba3 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -779,7 +779,7 @@ nand_get_sdr_timings(const struct nand_data_interface *conf)
  * Minimum amount of bit errors per @ecc_step_ds guaranteed
  * to be correctable. If unknown, set to zero.
  * @ecc_step_ds:   [INTERN] ECC step required by the @ecc_strength_ds,
- *  also from the datasheet. It is the recommended ECC step
+ * also from the datasheet. It is the recommended ECC step
  * size, if known; if unknown, set to zero.
  * @onfi_timing_mode_default: [INTERN] default ONFI timing mode. This field is
  *   set to the actually used ONFI mode if the chip is
-- 
2.9.3

[PATCH 2/5] docs-rst: convert mtdnand book to ReST

[Mauro Carvalho Chehab]

Use pandoc to convert documentation to ReST by calling
Documentation/sphinx/tmplcvt script.

The tables were manually adjusted to fit into 80 columns.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/DocBook/Makefile   |1 -
 Documentation/DocBook/mtdnand.tmpl   | 1291 --
 Documentation/driver-api/index.rst   |1 +
 Documentation/driver-api/mtdnand.rst | 1020 +++
 4 files changed, 1021 insertions(+), 1292 deletions(-)
 delete mode 100644 Documentation/DocBook/mtdnand.tmpl
 create mode 100644 Documentation/driver-api/mtdnand.rst

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 0a82f6253682..226e5e9fc801 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -8,7 +8,6 @@
 
 DOCBOOKS := \
lsm.xml \
-   mtdnand.xml \
sh.xml
 
 ifeq ($(DOCBOOKS),)
diff --git a/Documentation/DocBook/mtdnand.tmpl 
b/Documentation/DocBook/mtdnand.tmpl
deleted file mode 100644
index b442921bca54..
--- a/Documentation/DocBook/mtdnand.tmpl
+++ /dev/null
@@ -1,1291 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []>
-
-
- 
-  MTD NAND Driver Programming Interface
-  
-  
-   
-Thomas
-Gleixner
-
- 
-  t...@linutronix.de
- 
-
-   
-  
-
-  
-   2004
-   Thomas Gleixner
-  
-
-  
-   
- This documentation is free software; you can redistribute
- it and/or modify it under the terms of the GNU General Public
- License version 2 as published by the Free Software Foundation.
-   
-  
-   
- This program 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 General Public License for more details.
-   
-  
-   
- You should have received a copy of the GNU General Public
- License along with this program; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
-   
-  
-   
- For more details see the file COPYING in the source
- distribution of Linux.
-   
-  
- 
-
-
-
-  
-  Introduction
-  
-   The generic NAND driver supports almost all NAND and AG-AND based
-   chips and connects them to the Memory Technology Devices (MTD)
-   subsystem of the Linux Kernel.
-  
-  
-   This documentation is provided for developers who want to implement
-   board drivers or filesystem drivers suitable for NAND devices.
-  
-  
-  
-  
- Known Bugs And Assumptions
-  
-   None.   
-  
-  
-
-  
- Documentation hints
- 
- The function and structure docs are autogenerated. Each function and 
- struct member has a short description which is marked with an [XXX] 
identifier.
- The following chapters explain the meaning of those identifiers.
- 
- 
-   Function identifiers [XXX]
-   
-   The functions are marked with [XXX] identifiers in the short
-   comment. The identifiers explain the usage and scope of the
-   functions. Following identifiers are used:
-   
-   
-   
-   [MTD Interface]
-   These functions provide the interface to the MTD kernel API. 
-   They are not replaceable and provide functionality
-   which is complete hardware independent.
-   
-   
-   [NAND Interface]
-   These functions are exported and provide the interface to the 
NAND kernel API. 
-   
-   
-   [GENERIC]
-   Generic functions are not replaceable and provide functionality
-   which is complete hardware independent.
-   
-   
-   [DEFAULT]
-   Default functions provide hardware related functionality which 
is suitable
-   for most of the implementations. These functions can be 
replaced by the
-   board driver if necessary. Those functions are called via 
pointers in the
-   NAND chip description structure. The board driver can set the 
functions which
-   should be replaced by board dependent functions before calling 
nand_scan().
-   If the function pointer is NULL on entry to nand_scan() then 
the pointer
-   is set to the default function which is suitable for the 
detected chip type.
-   
-   
- 
- 
-   Struct member identifiers [XXX]
-   
-   The struct members are marked with [XXX] identifiers in the 
-   comment. The identifiers explain the usage and scope of the
-   members. Following identifiers are used:
-   
-   
-   
-   [INTERN]
-   These members are for NAND driver internal use only and must 
not be
-   modified. Most of the

[PATCH 5/5] docs-rst: convert sh book to ReST

[Mauro Carvalho Chehab]

Use pandoc to convert documentation to ReST by calling
Documentation/sphinx/tmplcvt script.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/DocBook/Makefile |   4 +-
 Documentation/DocBook/sh.tmpl  | 105 -
 Documentation/conf.py  |   2 +
 Documentation/index.rst|  11 +
 Documentation/sh/index.rst |  59 +++
 5 files changed, 73 insertions(+), 108 deletions(-)
 delete mode 100644 Documentation/DocBook/sh.tmpl
 create mode 100644 Documentation/sh/index.rst

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 226e5e9fc801..efba7f980895 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -6,9 +6,7 @@
 # To add a new book the only step required is to add the book to the
 # list of DOCBOOKS.
 
-DOCBOOKS := \
-   lsm.xml \
-   sh.xml
+DOCBOOKS := lsm.xml
 
 ifeq ($(DOCBOOKS),)
 
diff --git a/Documentation/DocBook/sh.tmpl b/Documentation/DocBook/sh.tmpl
deleted file mode 100644
index 4a38f604fa66..
--- a/Documentation/DocBook/sh.tmpl
+++ /dev/null
@@ -1,105 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []>
-
-
- 
-  SuperH Interfaces Guide
-  
-  
-   
-Paul
-Mundt
-
- 
-  let...@linux-sh.org
- 
-
-   
-  
-
-  
-   2008-2010
-   Paul Mundt
-  
-  
-   2008-2010
-   Renesas Technology Corp.
-  
-  
-   2010
-   Renesas Electronics Corp.
-  
-
-  
-   
- This documentation is free software; you can redistribute
- it and/or modify it under the terms of the GNU General Public
- License version 2 as published by the Free Software Foundation.
-   
-  
-   
- This program 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 General Public License for more details.
-   
-  
-   
- You should have received a copy of the GNU General Public
- License along with this program; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
-   
-  
-   
- For more details see the file COPYING in the source
- distribution of Linux.
-   
-  
- 
-
-
-
-  
-Memory Management
-
-SH-4
-  
-Store Queue API
-!Earch/sh/kernel/cpu/sh4/sq.c
-  
-
-
-  SH-5
-  
-   TLB Interfaces
-!Iarch/sh/mm/tlb-sh5.c
-!Iarch/sh/include/asm/tlb_64.h
-  
-
-  
-  
-Machine Specific Interfaces
-
-  mach-dreamcast
-!Iarch/sh/boards/mach-dreamcast/rtc.c
-
-
-  mach-x3proto
-!Earch/sh/boards/mach-x3proto/ilsel.c
-
-  
-  
-Busses
-
-  SuperHyway
-!Edrivers/sh/superhyway/superhyway.c
-
-
-
-  Maple
-!Edrivers/sh/maple/maple.c
-
-  
-
diff --git a/Documentation/conf.py b/Documentation/conf.py
index dfe14f7525d0..77d47bb1df1d 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -375,6 +375,8 @@ latex_documents = [
  'The kernel development community', 'manual'),
 ('security/index', 'security.tex', 'The kernel security subsystem manual',
  'The kernel development community', 'manual'),
+('sh/index', 'sh.tex', 'SuperH architecture implementation manual',
+ 'The kernel development community', 'manual'),
 ('sound/index', 'sound.tex', 'Linux Sound Subsystem Documentation',
  'The kernel development community', 'manual'),
 ('userspace-api/index', 'userspace-api.tex', 'The Linux kernel user-space 
API guide',
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 25c4da41da6b..e9017bb3a6ce 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -76,6 +76,17 @@ needed).
crypto/index
filesystems/index
 
+Architecture-specific documentation
+---
+
+These books provide programming details about architecture-specific
+implementation.
+
+.. toctree::
+   :maxdepth: 2
+
+   sh/index
+
 Korean translations
 ---
 
diff --git a/Documentation/sh/index.rst b/Documentation/sh/index.rst
new file mode 100644
index ..bc8db7ba894a
--- /dev/null
+++ b/Documentation/sh/index.rst
@@ -0,0 +1,59 @@
+===
+SuperH Interfaces Guide
+===
+
+:Author: Paul Mundt
+
+Memory Management
+=
+
+SH-4
+
+
+Store Queue API
+~~~
+
+.. kernel-doc:: arch/sh/kernel/cpu/sh4/sq.c
+   :export:
+
+SH-5
+
+
+TLB Interfaces
+~~
+
+.. kernel-doc:: arch/sh/mm/tlb-sh5.c
+   :internal:
+
+.. kernel-doc:: arch/sh/include/asm/tlb_64.h
+   :internal:
+
+Machine Specific Interfaces
+===
+
+mach-dreamcast
+--
+
+.. kernel-doc:: arch/sh/boards/mach-dreamcast/rtc.c
+   :internal:
+
+mach-x3proto
+
+
+.. kernel-doc:: arch/sh/boards/mach-x3proto/ilsel.c
+   :export:
+
+Busses

[PATCH 3/5] mtdnand.rst: Fix some typos and group the "::" with previous line

[Mauro Carvalho Chehab]

Typo:
ored -> ordered

While here, group the :: with the previous paragraph, in order
to make it visually better when reading as a text file.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/driver-api/mtdnand.rst | 24 +++-
 1 file changed, 7 insertions(+), 17 deletions(-)

diff --git a/Documentation/driver-api/mtdnand.rst 
b/Documentation/driver-api/mtdnand.rst
index 8723175f955e..e670f8b15a79 100644
--- a/Documentation/driver-api/mtdnand.rst
+++ b/Documentation/driver-api/mtdnand.rst
@@ -843,10 +843,8 @@ Chip option constants
 Constants for chip id table
 ~~~
 
-These constants are defined in nand.h. They are ored together to
-describe the chip functionality.
-
-::
+These constants are defined in nand.h. They are ordered together to
+describe the chip functionality::
 
 /* Buswitdh is 16 bit */
 #define NAND_BUSWIDTH_160x0002
@@ -867,10 +865,8 @@ describe the chip functionality.
 Constants for runtime options
 ~
 
-These constants are defined in nand.h. They are ored together to
-describe the functionality.
-
-::
+These constants are defined in nand.h. They are ordered together to
+describe the functionality::
 
 /* The hw ecc generator provides a syndrome instead a ecc value on read
  * This can only work if we have the ecc bytes directly behind the
@@ -881,9 +877,7 @@ describe the functionality.
 ECC selection constants
 ---
 
-Use these constants to select the ECC algorithm.
-
-::
+Use these constants to select the ECC algorithm::
 
 /* No ECC. Usage is not recommended ! */
 #define NAND_ECC_NONE   0
@@ -903,9 +897,7 @@ Hardware control related constants
 --
 
 These constants describe the requested hardware access function when the
-boardspecific hardware control function is called
-
-::
+boardspecific hardware control function is called::
 
 /* Select the chip by setting nCE to low */
 #define NAND_CTL_SETNCE 1
@@ -929,9 +921,7 @@ Bad block table related constants
 -
 
 These constants describe the options used for bad block table
-descriptors.
-
-::
+descriptors::
 
 /* Options for the bad block table descriptors */
 
-- 
2.9.3

[PATCH 0/5] Convert more books to ReST

[Mauro Carvalho Chehab]

This patch series convert the following books to ReST:
- librs
- mtdnand
- sh

And it is based on my previous series of conversion patches.

After this series, there will be just one DocBook pending conversion:
- lsm (Linux Security Modules)

This book is very outdated: no changes since the Kernel moved 
to git, in 2005 (except for a minor editorial fix in 2008).

I took a look on the described API: it doesn't seem to be describing
the current security implementation.

The best here is if someone that works with LSM to convert it to
ReST with:
$ Documentation/sphinx/tmplcvt Documentation/DocBook/lsm.tmpl lsm.rst

And fix the document to produce something that reflects the current
implementation. If nobody is interested, then maybe we could just
drop it.

-

This patch series is based on my past 00/36 patch series, applied on
the top of docs tree (next branch).

The full patch series is on this tree is at:

   https://git.linuxtv.org//mchehab/experimental.git/log/?h=docbook

And the HTML output at:

  http://www.infradead.org/~mchehab/kernel_docs/
  https://mchehab.fedorapeople.org/kernel_docs/ 

Mauro Carvalho Chehab (5):
  docs-rst: convert librs book to ReST
  docs-rst: convert mtdnand book to ReST
  mtdnand.rst: Fix some typos and group the "::" with previous line
  mtd: adjust kernel-docs to avoid Sphinx/kerneldoc warnings
  docs-rst: convert sh book to ReST

 Documentation/DocBook/Makefile   |5 +-
 Documentation/DocBook/librs.tmpl |  289 
 Documentation/DocBook/mtdnand.tmpl   | 1291 --
 Documentation/DocBook/sh.tmpl|  105 ---
 Documentation/conf.py|2 +
 Documentation/core-api/index.rst |1 +
 Documentation/core-api/librs.rst |  212 ++
 Documentation/driver-api/index.rst   |1 +
 Documentation/driver-api/mtdnand.rst | 1007 ++
 Documentation/index.rst  |   11 +
 Documentation/sh/index.rst   |   59 ++
 drivers/mtd/nand/nand_base.c |7 +-
 include/linux/mtd/nand.h |2 +-
 13 files changed, 1300 insertions(+), 1692 deletions(-)
 delete mode 100644 Documentation/DocBook/librs.tmpl
 delete mode 100644 Documentation/DocBook/mtdnand.tmpl
 delete mode 100644 Documentation/DocBook/sh.tmpl
 create mode 100644 Documentation/core-api/librs.rst
 create mode 100644 Documentation/driver-api/mtdnand.rst
 create mode 100644 Documentation/sh/index.rst

-- 
2.9.3

[PATCH 1/5] docs-rst: convert librs book to ReST

[Mauro Carvalho Chehab]

Use pandoc to convert documentation to ReST by calling
Documentation/sphinx/tmplcvt script.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/DocBook/Makefile   |   2 +-
 Documentation/DocBook/librs.tmpl | 289 ---
 Documentation/core-api/index.rst |   1 +
 Documentation/core-api/librs.rst | 212 
 4 files changed, 214 insertions(+), 290 deletions(-)
 delete mode 100644 Documentation/DocBook/librs.tmpl
 create mode 100644 Documentation/core-api/librs.rst

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index baedb14f3b40..0a82f6253682 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -8,7 +8,7 @@
 
 DOCBOOKS := \
lsm.xml \
-   mtdnand.xml librs.xml \
+   mtdnand.xml \
sh.xml
 
 ifeq ($(DOCBOOKS),)
diff --git a/Documentation/DocBook/librs.tmpl b/Documentation/DocBook/librs.tmpl
deleted file mode 100644
index 94f21361e0ed..
--- a/Documentation/DocBook/librs.tmpl
+++ /dev/null
@@ -1,289 +0,0 @@
-
-http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []>
-
-
- 
-  Reed-Solomon Library Programming Interface
-  
-  
-   
-Thomas
-Gleixner
-
- 
-  t...@linutronix.de
- 
-
-   
-  
-
-  
-   2004
-   Thomas Gleixner
-  
-
-  
-   
- This documentation is free software; you can redistribute
- it and/or modify it under the terms of the GNU General Public
- License version 2 as published by the Free Software Foundation.
-   
-  
-   
- This program 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 General Public License for more details.
-   
-  
-   
- You should have received a copy of the GNU General Public
- License along with this program; if not, write to the Free
- Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- MA 02111-1307 USA
-   
-  
-   
- For more details see the file COPYING in the source
- distribution of Linux.
-   
-  
- 
-
-
-
-  
-  Introduction
-  
-   The generic Reed-Solomon Library provides encoding, decoding
-   and error correction functions.
-  
-  
-   Reed-Solomon codes are used in communication and storage
-   applications to ensure data integrity. 
-  
-  
-   This documentation is provided for developers who want to utilize
-   the functions provided by the library.
-  
-  
-  
-  
- Known Bugs And Assumptions
-  
-   None.   
-  
-  
-
-  
-   Usage
-   
-   This chapter provides examples of how to use the library.
-   
-   
-   Initializing
-   
-   The init function init_rs returns a pointer to an
-   rs decoder structure, which holds the necessary
-   information for encoding, decoding and error correction
-   with the given polynomial. It either uses an existing
-   matching decoder or creates a new one. On creation all
-   the lookup tables for fast en/decoding are created.
-   The function may take a while, so make sure not to 
-   call it in critical code paths.
-   
-   
-/* the Reed Solomon control structure */
-static struct rs_control *rs_decoder;
-
-/* Symbolsize is 10 (bits)
- * Primitive polynomial is x^10+x^3+1
- * first consecutive root is 0
- * primitive element to generate roots = 1
- * generator polynomial degree (number of roots) = 6
- */
-rs_decoder = init_rs (10, 0x409, 0, 1, 6);
-   
-   
-   
-   Encoding
-   
-   The encoder calculates the Reed-Solomon code over
-   the given data length and stores the result in 
-   the parity buffer. Note that the parity buffer must
-   be initialized before calling the encoder.
-   
-   
-   The expanded data can be inverted on the fly by
-   providing a non-zero inversion mask. The expanded data 
is
-   XOR'ed with the mask. This is used e.g. for FLASH
-   ECC, where the all 0xFF is inverted to an all 0x00.
-   The Reed-Solomon code for all 0x00 is all 0x00. The
-   code is inverted before storing to FLASH so it is 0xFF
-   too. This prevents that reading from an erased FLASH
-   results in ECC errors.
-   
-   
-   The databytes are expanded to the given symbol size
-   on the fly. There is no support for encoding continuous
-   bitstreams with 

[PATCH] kbuild: add ARM support for tar-pkg

[Sascha Silbe]

The fallback code for "unknown" architectures doesn't work on ARM
because for ARM (and a couple of other architectures) KBUILD_IMAGE
contains only the file name, not the full path. Having an explicit
rule also avoids printing the warning for unknown architectures.

Signed-off-by: Sascha Silbe 
---
 scripts/package/buildtar | 5 +
 1 file changed, 5 insertions(+)

diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index e046bff33589..cbcc4496c025 100755
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -108,6 +108,11 @@ case "${ARCH}" in
cp -v -- "${objtree}/vmlinux" 
"${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
fi
;;
+   arm)
+   if [ -f "${objtree}/arch/${ARCH}/boot/${KBUILD_IMAGE}" ]; then
+   cp -v -- "${objtree}/arch/${ARCH}/boot/${KBUILD_IMAGE}" 
"${tmpdir}/boot/${KBUILD_IMAGE}-${KERNELRELEASE}"
+   fi
+   ;;
*)
[ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" 
"${tmpdir}/boot/vmlinux-kbuild-${KERNELRELEASE}"
echo "" >&2
-- 
2.11.0

[PATCH 2/2] ARM: davinci: PM: Do not free useful resources in normal path in 'davinci_pm_init'

[Christophe JAILLET]

This looks spurious to iounmap resources in the normal path of this init
function.
The 3 ioremap'ed fields of 'pm_config' can be accessed later on in other
functions, so it is likely that we should return 'success' before unrolling
everything.

Fixes: aa9aa1ec2df6 ("ARM: davinci: PM: rework init, remove platform device")
Signed-off-by: Christophe JAILLET 
---
This patch is just a *guess*. The end of the function looks more like a
error handling code rather than a normal path.
---
 arch/arm/mach-davinci/pm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index d282b0783ecf..163d865abbf9 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -161,6 +161,7 @@ int __init davinci_pm_init(void)
davinci_cpu_suspend_sz);
 
suspend_set_ops(&davinci_pm_ops);
+   return 0;
 
 no_sram_mem:
iounmap(pm_config.ddrpsc_reg_base);
-- 
2.11.0

[GIT PULL] UML changes for v4.12-rc1

[Richard Weinberger]

Linus,

The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12:

  Linux 4.11 (2017-04-30 19:47:48 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml.git for-linus-4.12-rc1

for you to fetch changes up to ce4586063f1af780b1c6b7e344907e6f9c1ba59a:

  um: Add missing NR_CPUS include (2017-05-04 08:15:10 +0200)

This pull request contains updates for UML:
- No new stuff, just fixes



Masami Hiramatsu (1):
  um: Fix to call read_initrd after init_bootmem

Matthias Kaehlcke (1):
  um: Include kbuild.h instead of duplicating its macros

Nikola Kotur (1):
  um: Set number of CPUs

Richard Weinberger (3):
  um: Fix _print_addr()
  um: Fix PTRACE_POKEUSER on x86_64
  um: Add missing NR_CPUS include

 arch/um/Kconfig.common | 5 +
 arch/um/kernel/initrd.c| 4 +---
 arch/um/kernel/sysrq.c | 6 ++
 arch/um/kernel/um_arch.c   | 6 ++
 arch/um/os-Linux/skas/process.c| 4 +---
 arch/x86/um/ptrace_64.c| 2 +-
 arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +
 7 files changed, 17 insertions(+), 19 deletions(-)

[PATCH 1/2] ARM: davinci: PM: Free resources in error handling path in 'davinci_pm_init'

[Christophe JAILLET]

If 'sram_alloc' fails, we need to free already allocated resources.

Fixes: aa9aa1ec2df6 ("ARM: davinci: PM: rework init, remove platform device")
Signed-off-by: Christophe JAILLET 
---
 arch/arm/mach-davinci/pm.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
index efb80354f303..d282b0783ecf 100644
--- a/arch/arm/mach-davinci/pm.c
+++ b/arch/arm/mach-davinci/pm.c
@@ -153,7 +153,8 @@ int __init davinci_pm_init(void)
davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
if (!davinci_sram_suspend) {
pr_err("PM: cannot allocate SRAM memory\n");
-   return -ENOMEM;
+   ret = -ENOMEM;
+   goto no_sram_mem;
}
 
davinci_sram_push(davinci_sram_suspend, davinci_cpu_suspend,
@@ -161,6 +162,8 @@ int __init davinci_pm_init(void)
 
suspend_set_ops(&davinci_pm_ops);
 
+no_sram_mem:
+   iounmap(pm_config.ddrpsc_reg_base);
 no_ddrpsc_mem:
iounmap(pm_config.ddrpll_reg_base);
 no_ddrpll_mem:
-- 
2.11.0

[GIT PULL] UBI/UBIFS updates for 4.12-rc1

[Richard Weinberger]

Linus,

The following changes since commit a351e9b9fc24e982ec2f0e76379a49826036da12:

  Linux 4.11 (2017-04-30 19:47:48 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-ubifs.git tags/upstream-4.12-rc1

for you to fetch changes up to 7bccd12d27b7e358823feb5429731b8ee698b173:

  ubi: Add debugfs file for tracking PEB state (2017-05-08 20:49:02 +0200)


This pull request contains updates for both UBI and UBIFS:
- New config option CONFIG_UBIFS_FS_SECURITY
- Minor improvements
- Random fixes


Andy Shevchenko (2):
  ubi: Fix section mismatch
  ubi: Make mtd parameter readable

Ben Shelton (1):
  ubi: Add debugfs file for tracking PEB state

Colin Ian King (1):
  ubifs: Fix cut and paste error on sb type comparisons

Hyunchul Lee (1):
  ubifs: Add CONFIG_UBIFS_FS_SECURITY to disable/enable security labels

Rabin Vincent (1):
  ubi: fastmap: Fix slab corruption

Rock Lee (1):
  ubifs: Fix a typo in comment of ioctl2ubifs & ubifs2ioctl

Stefan Agner (1):
  ubifs: Remove unnecessary assignment

 drivers/mtd/ubi/build.c   |  10 ++--
 drivers/mtd/ubi/debug.c   | 126 +-
 drivers/mtd/ubi/fastmap.c |  33 ++--
 fs/ubifs/Kconfig  |  13 +
 fs/ubifs/debug.c  |   4 +-
 fs/ubifs/ioctl.c  |   6 +--
 fs/ubifs/recovery.c   |   1 -
 fs/ubifs/ubifs.h  |  14 +-
 fs/ubifs/xattr.c  |   6 +++
 9 files changed, 195 insertions(+), 18 deletions(-)

[PATCH 12622/12622] Staging: ccree: ssi_cipher: fix brace coding style issue

[Ammly Fredrick]

Fixed some coding style issues after running scripts/checkpatch.pl

Fixed spelling in ssi_blkcipher_complete(), should be counter not couter.

Signed-off-by: Ammly Fredrick 
---
 drivers/staging/ccree/ssi_cipher.c | 72 ++
 1 file changed, 34 insertions(+), 38 deletions(-)

diff --git a/drivers/staging/ccree/ssi_cipher.c 
b/drivers/staging/ccree/ssi_cipher.c
index 664ed7e52cf2..37ed4e5133fc 100644
--- a/drivers/staging/ccree/ssi_cipher.c
+++ b/drivers/staging/ccree/ssi_cipher.c
@@ -72,7 +72,7 @@ static void ssi_ablkcipher_complete(struct device *dev, void 
*ssi_req, void __io
 static int validate_keys_sizes(struct ssi_ablkcipher_ctx *ctx_p, uint32_t 
size) {
switch (ctx_p->flow_mode){
case S_DIN_to_AES:
-   switch (size){
+   switch (size) {
case CC_AES_128_BIT_KEY_SIZE:
case CC_AES_192_BIT_KEY_SIZE:
if (likely((ctx_p->cipher_mode != DRV_CIPHER_XTS) &&
@@ -82,8 +82,8 @@ static int validate_keys_sizes(struct ssi_ablkcipher_ctx 
*ctx_p, uint32_t size)
break;
case CC_AES_256_BIT_KEY_SIZE:
return 0;
-   case (CC_AES_192_BIT_KEY_SIZE*2):
-   case (CC_AES_256_BIT_KEY_SIZE*2):
+   case (CC_AES_192_BIT_KEY_SIZE * 2):
+   case (CC_AES_256_BIT_KEY_SIZE * 2):
if (likely((ctx_p->cipher_mode == DRV_CIPHER_XTS) ||
   (ctx_p->cipher_mode == DRV_CIPHER_ESSIV) ||
   (ctx_p->cipher_mode == 
DRV_CIPHER_BITLOCKER)))
@@ -94,7 +94,7 @@ static int validate_keys_sizes(struct ssi_ablkcipher_ctx 
*ctx_p, uint32_t size)
}
case S_DIN_to_DES:
if (likely(size == DES3_EDE_KEY_SIZE ||
-   size == DES_KEY_SIZE))
+size == DES_KEY_SIZE))
return 0;
break;
 #if SSI_CC_HAS_MULTI2
@@ -105,16 +105,15 @@ static int validate_keys_sizes(struct ssi_ablkcipher_ctx 
*ctx_p, uint32_t size)
 #endif
default:
break;
-
}
return -EINVAL;
 }
 
 
 static int validate_data_size(struct ssi_ablkcipher_ctx *ctx_p, unsigned int 
size) {
-   switch (ctx_p->flow_mode){
+   switch (ctx_p->flow_mode) {
case S_DIN_to_AES:
-   switch (ctx_p->cipher_mode){
+   switch (ctx_p->cipher_mode) {
case DRV_CIPHER_XTS:
if ((size >= SSI_MIN_AES_XTS_SIZE) &&
(size <= SSI_MAX_AES_XTS_SIZE) && 
@@ -172,9 +171,8 @@ static unsigned int get_max_keysize(struct crypto_tfm *tfm)
return ssi_alg->crypto_alg.cra_ablkcipher.max_keysize;
}
 
-   if ((ssi_alg->crypto_alg.cra_flags & CRYPTO_ALG_TYPE_MASK) == 
CRYPTO_ALG_TYPE_BLKCIPHER) {
+   if ((ssi_alg->crypto_alg.cra_flags & CRYPTO_ALG_TYPE_MASK) == 
CRYPTO_ALG_TYPE_BLKCIPHER)
return ssi_alg->crypto_alg.cra_blkcipher.max_keysize;
-   }
 
return 0;
 }
@@ -199,7 +197,7 @@ static int ssi_blkcipher_init(struct crypto_tfm *tfm)
dev = &ctx_p->drvdata->plat_dev->dev;
 
/* Allocate key buffer, cache line aligned */
-   ctx_p->user.key = kmalloc(max_key_buf_size, GFP_KERNEL|GFP_DMA);
+   ctx_p->user.key = kmalloc(max_key_buf_size, GFP_KERNEL | GFP_DMA);
if (!ctx_p->user.key) {
SSI_LOG_ERR("Allocating key buffer in context failed\n");
rc = -ENOMEM;
@@ -260,11 +258,11 @@ static void ssi_blkcipher_exit(struct crypto_tfm *tfm)
 }
 
 
-typedef struct tdes_keys{
+typedef struct tdes_keys {
 u8  key1[DES_KEY_SIZE];
 u8  key2[DES_KEY_SIZE];
 u8  key3[DES_KEY_SIZE];
-}tdes_keys_t;
+} tdes_keys_t;
 
 static const u8 zero_buff[] = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
@@ -294,9 +292,9 @@ static int ssi_fips_verify_xts_keys(const u8 *key, unsigned 
int keylen)
 /* Weak key is define as key that its first half (128/256 lsb) equals 
its second half (128/256 msb) */
 int singleKeySize = keylen >> 1;
 
-   if (unlikely(memcmp(key, &key[singleKeySize], singleKeySize) == 0)) {
+   if (unlikely(memcmp(key, &key[singleKeySize], singleKeySize) == 0))
return -ENOEXEC;
-   }
+
 #endif /* CCREE_FIPS_SUPPORT */
 
 return 0;
@@ -340,12 +338,12 @@ static int ssi_blkcipher_setkey(struct crypto_tfm *tfm,
 
 #if SSI_CC_HAS_MULTI2
/*last byte of key buffer is round number and should not be a part of 
key size*/
-   if (ctx_p->flow_mode == S_DIN_to_MULTI2) {
-   keylen -=1;
-   }
+   if (ctx_p->flow_mode == S_DIN_to_MULTI2)
+   keylen -= 1;
+   
 #endif /*SSI_CC_HAS_MULTI2*/
 
-   if (unlikely(validate_keys_sizes(ctx_p,keylen) != 0)) {
+   if (unlikely(validate_k

Re: [PATCH v9 3/3] printk: fix double printing with earlycon

[Sergey Senozhatsky]

On (05/12/17 14:57), Petr Mladek wrote:
[..]
> I have tried to reproduce the problem and started kernel with
> console=ttyS1 console=ttyS0 in qemu. It created:
> 
>   console_cmdline = {{
>   .name = "ttyS";
>   .index = 1; // from ttyS1
>  },{
>   .name = "ttyS"
>   .index = 0; // from ttyS0
>  }};
>   preferred_console = 1;  // ttyuS0;
> 
> 
> Then register_console() is called twice here. First time
> from con_init() that registers:
> 
>   static struct console vt_console_driver = {
>   .name   = "tty",
>   .write  = vt_console_print,
>   .device = vt_console_device,
>   .unblank= unblank_screen,
>   .flags  = CON_PRINTBUFFER,
>   .index  = -1,
>   };
> 
>   It does not match and it is not enabled here.
> 
> 
> 2nd times from univ8250_console_init() that registers:
> 
>   static struct console univ8250_console = {
>   .name   = "ttyS",
>   .write  = univ8250_console_write,
>   .device = uart_console_device,
>   .setup  = univ8250_console_setup,
>   .match  = univ8250_console_match,
>   .flags  = CON_PRINTBUFFER | CON_ANYTIME,
>   .index  = -1,
>   .data   = &serial8250_reg,
>   };
> 
>   It matches both console_cmdline entries because index = -1.
>   The first tested is selected.

yes, that's what I observed on my host. I didn't try it with qemu,
just 86_64. and the behaviour was different.

[..]
> In fact, it always was kind of random because both init calls are
> defined as
> 
>   console_initcall(con_init);
>   console_initcall(univ8250_console_init);
> 
> They are put into special elf section and called from console_init()
> the following way:
> 
>   call = __con_initcall_start;
>   while (call < __con_initcall_end) {
>   (*call)();
>   call++;
>   }
> 
> By other words, the order depends on the linking order which is
> kind of weak order enforcement.
> 
> I am not sure if we broke some backward compatibility or actually made
> it more predictable in the long term.

well, we changed the behaviour. some automated scripts somewhere might
get broken. so may be this is the case when "a bug" becomes "a feature".
well, just saying.

-ss

[PATCH 00/17] convert/reorganize Documentation/security/

[Kees Cook]

Hi,

This ReSTifies everything under Documentation/security/, and reorganizes
some of it (mainly the LSMs) under /admin-guide/ per Jon's request. Since
/security/ is already being indexed under the kernel development portion
of the sphinx index, I didn't move it, keeping only things that were
directly related to internal kernel development (keys, creds, etc).

I also updated some path references, and MAINTAINERS lines. Some of the
conversion could probably do with some tweaks, but I think this is a
good first step in the right direction.

-Kees

[PATCH 01/17] doc: ReSTify seccomp_filter.txt

[Kees Cook]

This updates seccomp_filter.txt for ReST markup, and moves it under the
user-space API index, since it describes how application author can use
seccomp.

Signed-off-by: Kees Cook 
---
 Documentation/userspace-api/index.rst  |   1 +
 .../seccomp_filter.rst}| 116 +++--
 MAINTAINERS|   1 +
 3 files changed, 62 insertions(+), 56 deletions(-)
 rename Documentation/{prctl/seccomp_filter.txt => 
userspace-api/seccomp_filter.rst} (71%)

diff --git a/Documentation/userspace-api/index.rst 
b/Documentation/userspace-api/index.rst
index a9d01b44a659..15ff12342db8 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -16,6 +16,7 @@ place where this information is gathered.
 .. toctree::
:maxdepth: 2
 
+   seccomp_filter
unshare
 
 .. only::  subproject and html
diff --git a/Documentation/prctl/seccomp_filter.txt 
b/Documentation/userspace-api/seccomp_filter.rst
similarity index 71%
rename from Documentation/prctl/seccomp_filter.txt
rename to Documentation/userspace-api/seccomp_filter.rst
index 1e469ef75778..f71eb5ef1f2d 100644
--- a/Documentation/prctl/seccomp_filter.txt
+++ b/Documentation/userspace-api/seccomp_filter.rst
@@ -1,8 +1,9 @@
-   SECure COMPuting with filters
-   =
+===
+Seccomp BPF (SECure COMPuting with filters)
+===
 
 Introduction
-
+
 
 A large number of system calls are exposed to every userland process
 with many of them going unused for the entire lifetime of the process.
@@ -27,7 +28,7 @@ pointers which constrains all filters to solely evaluating 
the system
 call arguments directly.
 
 What it isn't
--
+=
 
 System call filtering isn't a sandbox.  It provides a clearly defined
 mechanism for minimizing the exposed kernel surface.  It is meant to be
@@ -40,13 +41,13 @@ system calls in socketcall() is allowed, for instance) 
which could be
 construed, incorrectly, as a more complete sandboxing solution.
 
 Usage
--
+=
 
 An additional seccomp mode is added and is enabled using the same
 prctl(2) call as the strict seccomp.  If the architecture has
-CONFIG_HAVE_ARCH_SECCOMP_FILTER, then filters may be added as below:
+``CONFIG_HAVE_ARCH_SECCOMP_FILTER``, then filters may be added as below:
 
-PR_SET_SECCOMP:
+``PR_SET_SECCOMP``:
Now takes an additional argument which specifies a new filter
using a BPF program.
The BPF program will be executed over struct seccomp_data
@@ -55,24 +56,25 @@ PR_SET_SECCOMP:
acceptable values to inform the kernel which action should be
taken.
 
-   Usage:
+   Usage::
+
prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, prog);
 
The 'prog' argument is a pointer to a struct sock_fprog which
will contain the filter program.  If the program is invalid, the
-   call will return -1 and set errno to EINVAL.
+   call will return -1 and set errno to ``EINVAL``.
 
-   If fork/clone and execve are allowed by @prog, any child
+   If ``fork``/``clone`` and ``execve`` are allowed by @prog, any child
processes will be constrained to the same filters and system
call ABI as the parent.
 
-   Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or
-   run with CAP_SYS_ADMIN privileges in its namespace.  If these are not
-   true, -EACCES will be returned.  This requirement ensures that filter
+   Prior to use, the task must call ``prctl(PR_SET_NO_NEW_PRIVS, 1)`` or
+   run with ``CAP_SYS_ADMIN`` privileges in its namespace.  If these are 
not
+   true, ``-EACCES`` will be returned.  This requirement ensures that 
filter
programs cannot be applied to child processes with greater privileges
than the task that installed them.
 
-   Additionally, if prctl(2) is allowed by the attached filter,
+   Additionally, if ``prctl(2)`` is allowed by the attached filter,
additional filters may be layered on which will increase evaluation
time, but allow for further decreasing the attack surface during
execution of a process.
@@ -80,51 +82,52 @@ PR_SET_SECCOMP:
 The above call returns 0 on success and non-zero on error.
 
 Return values
--
+=
+
 A seccomp filter may return any of the following values. If multiple
 filters exist, the return value for the evaluation of a given system
 call will always use the highest precedent value. (For example,
-SECCOMP_RET_KILL will always take precedence.)
+``SECCOMP_RET_KILL`` will always take precedence.)
 
 In precedence order, they are:
 
-SECCOMP_RET_KILL:
+``SECCOMP_RET_KILL``:
Results in the task exiting immediately without executing the
-   system call.  The exit status of the task (status & 0x7f) will
-   be 

[PATCH 11/17] doc: ReSTify Yama.txt

[Kees Cook]

Adjusts for ReST markup and moves under LSM admin guide.

Signed-off-by: Kees Cook 
---
 .../Yama.txt => admin-guide/LSM/Yama.rst}  | 55 --
 Documentation/admin-guide/LSM/index.rst|  1 +
 Documentation/security/00-INDEX|  2 -
 MAINTAINERS|  1 +
 security/yama/Kconfig  |  3 +-
 5 files changed, 33 insertions(+), 29 deletions(-)
 rename Documentation/{security/Yama.txt => admin-guide/LSM/Yama.rst} (60%)

diff --git a/Documentation/security/Yama.txt 
b/Documentation/admin-guide/LSM/Yama.rst
similarity index 60%
rename from Documentation/security/Yama.txt
rename to Documentation/admin-guide/LSM/Yama.rst
index d9ee7d7a6c7f..13468ea696b7 100644
--- a/Documentation/security/Yama.txt
+++ b/Documentation/admin-guide/LSM/Yama.rst
@@ -1,13 +1,14 @@
+
+Yama
+
+
 Yama is a Linux Security Module that collects system-wide DAC security
 protections that are not handled by the core kernel itself. This is
-selectable at build-time with CONFIG_SECURITY_YAMA, and can be controlled
-at run-time through sysctls in /proc/sys/kernel/yama:
-
-- ptrace_scope
+selectable at build-time with ``CONFIG_SECURITY_YAMA``, and can be controlled
+at run-time through sysctls in ``/proc/sys/kernel/yama``:
 
-==
-
-ptrace_scope:
+ptrace_scope
+
 
 As Linux grows in popularity, it will become a larger target for
 malware. One particularly troubling weakness of the Linux process
@@ -25,47 +26,49 @@ exist and remain possible if ptrace is allowed to operate 
as before.
 Since ptrace is not commonly used by non-developers and non-admins, system
 builders should be allowed the option to disable this debugging system.
 
-For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
+For a solution, some applications use ``prctl(PR_SET_DUMPABLE, ...)`` to
 specifically disallow such ptrace attachment (e.g. ssh-agent), but many
 do not. A more general solution is to only allow ptrace directly from a
 parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
-work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
+work), or with ``CAP_SYS_PTRACE`` (i.e. "gdb --pid=PID", and "strace -p PID"
 still work as root).
 
 In mode 1, software that has defined application-specific relationships
 between a debugging process and its inferior (crash handlers, etc),
-prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
-other process (and its descendants) are allowed to call PTRACE_ATTACH
+``prctl(PR_SET_PTRACER, pid, ...)`` can be used. An inferior can declare which
+other process (and its descendants) are allowed to call ``PTRACE_ATTACH``
 against it. Only one such declared debugging process can exists for
 each inferior at a time. For example, this is used by KDE, Chromium, and
 Firefox's crash handlers, and by Wine for allowing only Wine processes
 to ptrace each other. If a process wishes to entirely disable these ptrace
-restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)
+restrictions, it can call ``prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)``
 so that any otherwise allowed process (even those in external pid namespaces)
 may attach.
 
-The sysctl settings (writable only with CAP_SYS_PTRACE) are:
+The sysctl settings (writable only with ``CAP_SYS_PTRACE``) are:
 
-0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other
+0 - classic ptrace permissions:
+a process can ``PTRACE_ATTACH`` to any other
 process running under the same uid, as long as it is dumpable (i.e.
 did not transition uids, start privileged, or have called
-prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is
+``prctl(PR_SET_DUMPABLE...)`` already). Similarly, ``PTRACE_TRACEME`` is
 unchanged.
 
-1 - restricted ptrace: a process must have a predefined relationship
-with the inferior it wants to call PTRACE_ATTACH on. By default,
+1 - restricted ptrace:
+a process must have a predefined relationship
+with the inferior it wants to call ``PTRACE_ATTACH`` on. By default,
 this relationship is that of only its descendants when the above
 classic criteria is also met. To change the relationship, an
-inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare
-an allowed debugger PID to call PTRACE_ATTACH on the inferior.
-Using PTRACE_TRACEME is unchanged.
+inferior can call ``prctl(PR_SET_PTRACER, debugger, ...)`` to declare
+an allowed debugger PID to call ``PTRACE_ATTACH`` on the inferior.
+Using ``PTRACE_TRACEME`` is unchanged.
 
-2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace
-with PTRACE_ATTACH, or through children calling PTRACE_TRACEME.
+2 - admin-only attach:
+only processes with ``CAP_SYS_PTRACE`` may use ptrace
+with ``PTRACE_ATTACH``, or through children calling 

[PATCH 15/17] doc: ReSTify keys-ecryptfs.txt

[Kees Cook]

Adjusts for ReST markup and moves under keys security devel index.

Cc: David Howells 
Cc: Tyler Hicks 
Signed-off-by: Kees Cook 
---
 Documentation/security/00-INDEX   |  2 --
 .../security/{keys-ecryptfs.txt => keys/ecryptfs.rst} | 19 ---
 Documentation/security/keys/index.rst |  1 +
 3 files changed, 13 insertions(+), 9 deletions(-)
 rename Documentation/security/{keys-ecryptfs.txt => keys/ecryptfs.rst} (91%)

diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index a840095bb11c..08a6e7a195ef 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -1,7 +1,5 @@
 00-INDEX
- this file.
-keys-ecryptfs.txt
-   - description of the encryption keys for the ecryptfs filesystem.
 keys-request-key.txt
- description of the kernel key request service.
 keys-trusted-encrypted.txt
diff --git a/Documentation/security/keys-ecryptfs.txt 
b/Documentation/security/keys/ecryptfs.rst
similarity index 91%
rename from Documentation/security/keys-ecryptfs.txt
rename to Documentation/security/keys/ecryptfs.rst
index c3bbeba63562..4920f3a8ea75 100644
--- a/Documentation/security/keys-ecryptfs.txt
+++ b/Documentation/security/keys/ecryptfs.rst
@@ -1,4 +1,6 @@
-   Encrypted keys for the eCryptfs filesystem
+==
+Encrypted keys for the eCryptfs filesystem
+==
 
 ECryptfs is a stacked filesystem which transparently encrypts and decrypts each
 file using a randomly generated File Encryption Key (FEK).
@@ -35,20 +37,23 @@ controlled environment.  Another advantage is that the key 
is not exposed to
 threats of malicious software, because it is available in clear form only at
 kernel level.
 
-Usage:
+Usage::
+
keyctl add encrypted name "new ecryptfs key-type:master-key-name keylen" 
ring
keyctl add encrypted name "load hex_blob" ring
keyctl update keyid "update key-type:master-key-name"
 
-name:= '<16 hexadecimal characters>'
-key-type:= 'trusted' | 'user'
-keylen:= 64
+Where::
+
+   name:= '<16 hexadecimal characters>'
+   key-type:= 'trusted' | 'user'
+   keylen:= 64
 
 
 Example of encrypted key usage with the eCryptfs filesystem:
 
 Create an encrypted key "1000100010001000" of length 64 bytes with format
-'ecryptfs' and save it using a previously loaded user key "test":
+'ecryptfs' and save it using a previously loaded user key "test"::
 
 $ keyctl add encrypted 1000100010001000 "new ecryptfs user:test 64" @u
 19184530
@@ -62,7 +67,7 @@ Create an encrypted key "1000100010001000" of length 64 bytes 
with format
 $ keyctl pipe 19184530 > ecryptfs.blob
 
 Mount an eCryptfs filesystem using the created encrypted key "1000100010001000"
-into the '/secret' directory:
+into the '/secret' directory::
 
 $ mount -i -t ecryptfs -oecryptfs_sig=1000100010001000,\
   ecryptfs_cipher=aes,ecryptfs_key_bytes=32 /secret /secret
diff --git a/Documentation/security/keys/index.rst 
b/Documentation/security/keys/index.rst
index ddfe7e4726e6..d34f663354bb 100644
--- a/Documentation/security/keys/index.rst
+++ b/Documentation/security/keys/index.rst
@@ -6,3 +6,4 @@ Kernel Keys
:maxdepth: 1
 
core
+   ecryptfs
-- 
2.7.4

[PATCH 12/17] doc: ReSTify LoadPin.txt

[Kees Cook]

Adjusts for ReST markup and moves under LSM admin guide.

Signed-off-by: Kees Cook 
---
 .../{security/LoadPin.txt => admin-guide/LSM/LoadPin.rst}| 12 
 Documentation/admin-guide/LSM/index.rst  |  1 +
 MAINTAINERS  |  1 +
 3 files changed, 10 insertions(+), 4 deletions(-)
 rename Documentation/{security/LoadPin.txt => admin-guide/LSM/LoadPin.rst} 
(73%)

diff --git a/Documentation/security/LoadPin.txt 
b/Documentation/admin-guide/LSM/LoadPin.rst
similarity index 73%
rename from Documentation/security/LoadPin.txt
rename to Documentation/admin-guide/LSM/LoadPin.rst
index e11877f5d3d4..32070762d24c 100644
--- a/Documentation/security/LoadPin.txt
+++ b/Documentation/admin-guide/LSM/LoadPin.rst
@@ -1,3 +1,7 @@
+===
+LoadPin
+===
+
 LoadPin is a Linux Security Module that ensures all kernel-loaded files
 (modules, firmware, etc) all originate from the same filesystem, with
 the expectation that such a filesystem is backed by a read-only device
@@ -5,13 +9,13 @@ such as dm-verity or CDROM. This allows systems that have a 
verified
 and/or unchangeable filesystem to enforce module and firmware loading
 restrictions without needing to sign the files individually.
 
-The LSM is selectable at build-time with CONFIG_SECURITY_LOADPIN, and
+The LSM is selectable at build-time with ``CONFIG_SECURITY_LOADPIN``, and
 can be controlled at boot-time with the kernel command line option
-"loadpin.enabled". By default, it is enabled, but can be disabled at
-boot ("loadpin.enabled=0").
+"``loadpin.enabled``". By default, it is enabled, but can be disabled at
+boot ("``loadpin.enabled=0``").
 
 LoadPin starts pinning when it sees the first file loaded. If the
 block device backing the filesystem is not read-only, a sysctl is
-created to toggle pinning: /proc/sys/kernel/loadpin/enabled. (Having
+created to toggle pinning: ``/proc/sys/kernel/loadpin/enabled``. (Having
 a mutable filesystem means pinning is mutable too, but having the
 sysctl allows for easy testing on systems with a mutable filesystem.)
diff --git a/Documentation/admin-guide/LSM/index.rst 
b/Documentation/admin-guide/LSM/index.rst
index e5ba2c69b8ef..41f5262359f9 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -34,6 +34,7 @@ the one "major" module (e.g. SELinux) if there is one 
configured.
:maxdepth: 1
 
apparmor
+   LoadPin
SELinux
tomoyo
Yama
diff --git a/MAINTAINERS b/MAINTAINERS
index c72830e888f1..3c1560c75aa6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11567,6 +11567,7 @@ M:  Kees Cook 
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
lsm/loadpin
 S: Supported
 F: security/loadpin/
+F: Documentation/admin-guide/LSM/LoadPin.rst
 
 YAMA SECURITY MODULE
 M: Kees Cook 
-- 
2.7.4

[PATCH 14/17] doc: ReSTify keys.txt

[Kees Cook]

This creates a new section in the security development index for kernel
keys, and adjusts for ReST markup.

Cc: David Howells 
Signed-off-by: Kees Cook 
---
 Documentation/crypto/asymmetric-keys.txt   |   2 +-
 Documentation/security/00-INDEX|   2 -
 Documentation/security/index.rst   |   1 +
 Documentation/security/{keys.txt => keys/core.rst} | 314 ++---
 Documentation/security/keys/index.rst  |   8 +
 MAINTAINERS|   2 +-
 include/linux/key.h|   2 +-
 7 files changed, 163 insertions(+), 168 deletions(-)
 rename Documentation/security/{keys.txt => keys/core.rst} (89%)
 create mode 100644 Documentation/security/keys/index.rst

diff --git a/Documentation/crypto/asymmetric-keys.txt 
b/Documentation/crypto/asymmetric-keys.txt
index 5ad6480e3fb9..b82b6ad48488 100644
--- a/Documentation/crypto/asymmetric-keys.txt
+++ b/Documentation/crypto/asymmetric-keys.txt
@@ -265,7 +265,7 @@ mandatory:
 
  The caller passes a pointer to the following struct with all of the fields
  cleared, except for data, datalen and quotalen [see
- Documentation/security/keys.txt].
+ Documentation/security/keys/core.rst].
 
struct key_preparsed_payload {
char*description;
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index cdb2294ec047..a840095bb11c 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -6,5 +6,3 @@ keys-request-key.txt
- description of the kernel key request service.
 keys-trusted-encrypted.txt
- info on the Trusted and Encrypted keys in the kernel key ring service.
-keys.txt
-   - description of the kernel key retention service.
diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst
index 94ba1cfc01c5..298a94a33f05 100644
--- a/Documentation/security/index.rst
+++ b/Documentation/security/index.rst
@@ -7,6 +7,7 @@ Security Documentation
 
credentials
IMA-templates
+   keys/index
LSM
self-protection
tpm/index
diff --git a/Documentation/security/keys.txt 
b/Documentation/security/keys/core.rst
similarity index 89%
rename from Documentation/security/keys.txt
rename to Documentation/security/keys/core.rst
index cd5019934d7f..0d831a7afe4f 100644
--- a/Documentation/security/keys.txt
+++ b/Documentation/security/keys/core.rst
@@ -1,6 +1,6 @@
-
-KERNEL KEY RETENTION SERVICE
-
+
+Kernel Key Retention Service
+
 
 This service allows cryptographic keys, authentication tokens, cross-domain
 user mappings, and similar to be cached in the kernel for the use of
@@ -29,8 +29,7 @@ This document has the following sections:
- Garbage collection
 
 
-
-KEY OVERVIEW
+Key Overview
 
 
 In this context, keys represent units of cryptographic data, authentication
@@ -47,14 +46,14 @@ Each key has a number of attributes:
- State.
 
 
- (*) Each key is issued a serial number of type key_serial_t that is unique for
+  *  Each key is issued a serial number of type key_serial_t that is unique for
  the lifetime of that key. All serial numbers are positive non-zero 32-bit
  integers.
 
  Userspace programs can use a key's serial numbers as a way to gain access
  to it, subject to permission checking.
 
- (*) Each key is of a defined "type". Types must be registered inside the
+  *  Each key is of a defined "type". Types must be registered inside the
  kernel by a kernel service (such as a filesystem) before keys of that type
  can be added or used. Userspace programs cannot define new types directly.
 
@@ -64,18 +63,18 @@ Each key has a number of attributes:
  Should a type be removed from the system, all the keys of that type will
  be invalidated.
 
- (*) Each key has a description. This should be a printable string. The key
+  *  Each key has a description. This should be a printable string. The key
  type provides an operation to perform a match between the description on a
  key and a criterion string.
 
- (*) Each key has an owner user ID, a group ID and a permissions mask. These
+  *  Each key has an owner user ID, a group ID and a permissions mask. These
  are used to control what a process may do to a key from userspace, and
  whether a kernel service will be able to find the key.
 
- (*) Each key can be set to expire at a specific time by the key type's
+  *  Each key can be set to expire at a specific time by the key type's
  instantiation function. Keys can also be immortal.
 
- (*) Each key can have a payload. This is a quantity of data that represent the
+  *  Each key can have a payload. This is a quantity of data that represent the
  actua

[PATCH 17/17] doc: ReSTify keys-trusted-encrypted.txt

[Kees Cook]

Adjusts for ReST markup and moves under keys security devel index.

Cc: David Howells 
Cc: Mimi Zohar 
Signed-off-by: Kees Cook 
---
 Documentation/security/00-INDEX|  4 ---
 Documentation/security/conf.py |  8 --
 Documentation/security/keys/index.rst  |  1 +
 .../trusted-encrypted.rst} | 32 ++
 MAINTAINERS|  4 +--
 security/keys/encrypted-keys/encrypted.c   |  2 +-
 security/keys/encrypted-keys/masterkey_trusted.c   |  2 +-
 security/keys/trusted.c|  2 +-
 8 files changed, 26 insertions(+), 29 deletions(-)
 delete mode 100644 Documentation/security/00-INDEX
 delete mode 100644 Documentation/security/conf.py
 rename Documentation/security/{keys-trusted-encrypted.txt => 
keys/trusted-encrypted.rst} (93%)

diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
deleted file mode 100644
index c8dbbc227326..
--- a/Documentation/security/00-INDEX
+++ /dev/null
@@ -1,4 +0,0 @@
-00-INDEX
-   - this file.
-keys-trusted-encrypted.txt
-   - info on the Trusted and Encrypted keys in the kernel key ring service.
diff --git a/Documentation/security/conf.py b/Documentation/security/conf.py
deleted file mode 100644
index 472fc9a8eb67..
--- a/Documentation/security/conf.py
+++ /dev/null
@@ -1,8 +0,0 @@
-project = "The kernel security subsystem manual"
-
-tags.add("subproject")
-
-latex_documents = [
-('index', 'security.tex', project,
- 'The kernel development community', 'manual'),
-]
diff --git a/Documentation/security/keys/index.rst 
b/Documentation/security/keys/index.rst
index d7ddbc1c2502..647d58f2588e 100644
--- a/Documentation/security/keys/index.rst
+++ b/Documentation/security/keys/index.rst
@@ -8,3 +8,4 @@ Kernel Keys
core
ecryptfs
request-key
+   trusted-encrypted
diff --git a/Documentation/security/keys-trusted-encrypted.txt 
b/Documentation/security/keys/trusted-encrypted.rst
similarity index 93%
rename from Documentation/security/keys-trusted-encrypted.txt
rename to Documentation/security/keys/trusted-encrypted.rst
index b20a993a32af..7b503831bdea 100644
--- a/Documentation/security/keys-trusted-encrypted.txt
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -1,4 +1,6 @@
-   Trusted and Encrypted Keys
+==
+Trusted and Encrypted Keys
+==
 
 Trusted and Encrypted Keys are two new key types added to the existing kernel
 key ring service.  Both of these new types are variable length symmetric keys,
@@ -20,7 +22,8 @@ By default, trusted keys are sealed under the SRK, which has 
the default
 authorization value (20 zeros).  This can be set at takeownership time with the
 trouser's utility: "tpm_takeownership -u -z".
 
-Usage:
+Usage::
+
 keyctl add trusted name "new keylen [options]" ring
 keyctl add trusted name "load hex_blob [pcrlock=pcrnum]" ring
 keyctl update key "update [options]"
@@ -64,19 +67,22 @@ The decrypted portion of encrypted keys can contain either 
a simple symmetric
 key or a more complex structure. The format of the more complex structure is
 application specific, which is identified by 'format'.
 
-Usage:
+Usage::
+
 keyctl add encrypted name "new [format] key-type:master-key-name keylen"
 ring
 keyctl add encrypted name "load hex_blob" ring
 keyctl update keyid "update key-type:master-key-name"
 
-format:= 'default | ecryptfs'
-key-type:= 'trusted' | 'user'
+Where::
+
+   format:= 'default | ecryptfs'
+   key-type:= 'trusted' | 'user'
 
 
 Examples of trusted and encrypted key usage:
 
-Create and save a trusted key named "kmk" of length 32 bytes:
+Create and save a trusted key named "kmk" of length 32 bytes::
 
 $ keyctl add trusted kmk "new 32" @u
 440502848
@@ -99,7 +105,7 @@ Create and save a trusted key named "kmk" of length 32 bytes:
 
 $ keyctl pipe 440502848 > kmk.blob
 
-Load a trusted key from the saved blob:
+Load a trusted key from the saved blob::
 
 $ keyctl add trusted kmk "load `cat kmk.blob`" @u
 268728824
@@ -114,7 +120,7 @@ Load a trusted key from the saved blob:
 f1f8fff03ad0acb083725535636addb08d73dedb9832da198081e5deae84bfaf0409c22b
 e4a8aea2b607ec96931e6f4d4fe563ba
 
-Reseal a trusted key under new pcr values:
+Reseal a trusted key under new pcr values::
 
 $ keyctl update 268728824 "update pcrinfo=`cat pcr.blob`"
 $ keyctl print 268728824
@@ -135,11 +141,13 @@ compromised by a user level problem, and when sealed to 
specific boot PCR
 values, protects against boot and offline attacks.  Create and save an
 encrypted key "evm" using the above trusted key "kmk":
 
-option 1: omitting 'format'
+option 1: omitting 'format'::
+
 $ keyctl add encrypted evm "new trusted:kmk 32" @u
 159771175
 
-option 2: explicitly defining 'format' as 'default'
+option 2: explicitly def

[PATCH 16/17] doc: ReSTify keys-request-key.txt

[Kees Cook]

Adjusts for ReST markup and moves under keys security devel index.

Cc: David Howells 
Signed-off-by: Kees Cook 
---
 Documentation/filesystems/nfs/idmapper.txt |  2 +-
 Documentation/networking/dns_resolver.txt  |  2 +-
 Documentation/security/00-INDEX|  2 -
 Documentation/security/keys/index.rst  |  1 +
 .../{keys-request-key.txt => keys/request-key.rst} | 69 +++---
 security/keys/request_key.c|  2 +-
 security/keys/request_key_auth.c   |  2 +-
 7 files changed, 38 insertions(+), 42 deletions(-)
 rename Documentation/security/{keys-request-key.txt => keys/request-key.rst} 
(78%)

diff --git a/Documentation/filesystems/nfs/idmapper.txt 
b/Documentation/filesystems/nfs/idmapper.txt
index fe03d10bb79a..b86831acd583 100644
--- a/Documentation/filesystems/nfs/idmapper.txt
+++ b/Documentation/filesystems/nfs/idmapper.txt
@@ -55,7 +55,7 @@ request-key will find the first matching line and 
corresponding program.  In
 this case, /some/other/program will handle all uid lookups and
 /usr/sbin/nfs.idmap will handle gid, user, and group lookups.
 
-See  for more information
+See  for more information
 about the request-key function.
 
 
diff --git a/Documentation/networking/dns_resolver.txt 
b/Documentation/networking/dns_resolver.txt
index d86adcdae420..eaa8f9a6fd5d 100644
--- a/Documentation/networking/dns_resolver.txt
+++ b/Documentation/networking/dns_resolver.txt
@@ -143,7 +143,7 @@ the key will be discarded and recreated when the data it 
holds has expired.
 dns_query() returns a copy of the value attached to the key, or an error if
 that is indicated instead.
 
-See  for further
+See  for further
 information about request-key function.
 
 
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index 08a6e7a195ef..c8dbbc227326 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -1,6 +1,4 @@
 00-INDEX
- this file.
-keys-request-key.txt
-   - description of the kernel key request service.
 keys-trusted-encrypted.txt
- info on the Trusted and Encrypted keys in the kernel key ring service.
diff --git a/Documentation/security/keys/index.rst 
b/Documentation/security/keys/index.rst
index d34f663354bb..d7ddbc1c2502 100644
--- a/Documentation/security/keys/index.rst
+++ b/Documentation/security/keys/index.rst
@@ -7,3 +7,4 @@ Kernel Keys
 
core
ecryptfs
+   request-key
diff --git a/Documentation/security/keys-request-key.txt 
b/Documentation/security/keys/request-key.rst
similarity index 78%
rename from Documentation/security/keys-request-key.txt
rename to Documentation/security/keys/request-key.rst
index 51987bfecfed..5cdcee28479e 100644
--- a/Documentation/security/keys-request-key.txt
+++ b/Documentation/security/keys/request-key.rst
@@ -1,19 +1,19 @@
- ===
- KEY REQUEST SERVICE
- ===
+===
+Key Request Service
+===
 
 The key request service is part of the key retention service (refer to
 Documentation/security/keys.txt).  This document explains more fully how
 the requesting algorithm works.
 
 The process starts by either the kernel requesting a service by calling
-request_key*():
+``request_key*()``::
 
struct key *request_key(const struct key_type *type,
const char *description,
const char *callout_info);
 
-or:
+or::
 
struct key *request_key_with_auxdata(const struct key_type *type,
 const char *description,
@@ -21,14 +21,14 @@ or:
 size_t callout_len,
 void *aux);
 
-or:
+or::
 
struct key *request_key_async(const struct key_type *type,
  const char *description,
  const char *callout_info,
  size_t callout_len);
 
-or:
+or::
 
struct key *request_key_async_with_auxdata(const struct key_type *type,
   const char *description,
@@ -36,7 +36,7 @@ or:
   size_t callout_len,
   void *aux);
 
-Or by userspace invoking the request_key system call:
+Or by userspace invoking the request_key system call::
 
key_serial_t request_key(const char *type,
 const char *description,
@@ -67,38 +67,37 @@ own upcall mechanisms.  If they do, then those should be 
substituted for the
 forking and execution of /sbin/request-key.
 
 
-===
-THE PROCESS
+The Process
 ===
 
 A request proceeds in the following manner:
 
- (1) Process A calls request_key() [the userspace syscall 

[PATCH 08/17] doc: ReSTify SELinux.txt

[Kees Cook]

Adjusts for ReST markup and moves under LSM admin guide.

Cc: Paul Moore 
Signed-off-by: Kees Cook 
---
 .../SELinux.txt => admin-guide/LSM/SELinux.rst}| 18 --
 Documentation/admin-guide/LSM/index.rst|  5 +
 Documentation/security/00-INDEX|  2 --
 MAINTAINERS|  1 +
 scripts/selinux/README |  2 +-
 5 files changed, 19 insertions(+), 9 deletions(-)
 rename Documentation/{security/SELinux.txt => admin-guide/LSM/SELinux.rst} 
(71%)

diff --git a/Documentation/security/SELinux.txt 
b/Documentation/admin-guide/LSM/SELinux.rst
similarity index 71%
rename from Documentation/security/SELinux.txt
rename to Documentation/admin-guide/LSM/SELinux.rst
index 07eae00f3314..f722c9b4173a 100644
--- a/Documentation/security/SELinux.txt
+++ b/Documentation/admin-guide/LSM/SELinux.rst
@@ -1,27 +1,33 @@
+===
+SELinux
+===
+
 If you want to use SELinux, chances are you will want
 to use the distro-provided policies, or install the
 latest reference policy release from
+
http://oss.tresys.com/projects/refpolicy
 
 However, if you want to install a dummy policy for
-testing, you can do using 'mdp' provided under
+testing, you can do using ``mdp`` provided under
 scripts/selinux.  Note that this requires the selinux
 userspace to be installed - in particular you will
 need checkpolicy to compile a kernel, and setfiles and
 fixfiles to label the filesystem.
 
1. Compile the kernel with selinux enabled.
-   2. Type 'make' to compile mdp.
+   2. Type ``make`` to compile ``mdp``.
3. Make sure that you are not running with
   SELinux enabled and a real policy.  If
   you are, reboot with selinux disabled
   before continuing.
-   4. Run install_policy.sh:
+   4. Run install_policy.sh::
+
cd scripts/selinux
sh install_policy.sh
 
 Step 4 will create a new dummy policy valid for your
 kernel, with a single selinux user, role, and type.
-It will compile the policy, will set your SELINUXTYPE to
-dummy in /etc/selinux/config, install the compiled policy
-as 'dummy', and relabel your filesystem.
+It will compile the policy, will set your ``SELINUXTYPE`` to
+``dummy`` in ``/etc/selinux/config``, install the compiled policy
+as ``dummy``, and relabel your filesystem.
diff --git a/Documentation/admin-guide/LSM/index.rst 
b/Documentation/admin-guide/LSM/index.rst
index 7e892b9b58aa..cc0e04d63bf9 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -29,3 +29,8 @@ will always include the capability module. The list reflects 
the
 order in which checks are made. The capability module will always
 be first, followed by any "minor" modules (e.g. Yama) and then
 the one "major" module (e.g. SELinux) if there is one configured.
+
+.. toctree::
+   :maxdepth: 1
+
+   SELinux
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index 190a023a7e72..aaa0195418b3 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -1,7 +1,5 @@
 00-INDEX
- this file.
-SELinux.txt
-   - how to get started with the SELinux security enhancement.
 Smack.txt
- documentation on the Smack Linux Security Module.
 Yama.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index f2261713043c..c85108b4f6c7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11551,6 +11551,7 @@ S:  Supported
 F: include/linux/selinux*
 F: security/selinux/
 F: scripts/selinux/
+F: Documentation/admin-guide/LSM/SELinux.rst
 
 APPARMOR SECURITY MODULE
 M: John Johansen 
diff --git a/scripts/selinux/README b/scripts/selinux/README
index 4d020ecb7524..5ba679c5be18 100644
--- a/scripts/selinux/README
+++ b/scripts/selinux/README
@@ -1,2 +1,2 @@
-Please see Documentation/security/SELinux.txt for information on
+Please see Documentation/admin-guide/LSM/SELinux.rst for information on
 installing a dummy SELinux policy.
-- 
2.7.4

[PATCH 07/17] doc: ReSTify and split LSM.txt

[Kees Cook]

The existing LSM.txt file covered both usage and development, so split
this into two files, one under admin-guide and one under kernel
development.

Cc: James Morris 
Signed-off-by: Kees Cook 
---
 .../LSM.txt => admin-guide/LSM/index.rst}  | 22 ++
 Documentation/admin-guide/index.rst|  1 +
 Documentation/security/00-INDEX|  2 --
 Documentation/security/LSM.rst | 14 ++
 Documentation/security/index.rst   |  1 +
 5 files changed, 22 insertions(+), 18 deletions(-)
 rename Documentation/{security/LSM.txt => admin-guide/LSM/index.rst} (62%)
 create mode 100644 Documentation/security/LSM.rst

diff --git a/Documentation/security/LSM.txt 
b/Documentation/admin-guide/LSM/index.rst
similarity index 62%
rename from Documentation/security/LSM.txt
rename to Documentation/admin-guide/LSM/index.rst
index c2683f28ed36..7e892b9b58aa 100644
--- a/Documentation/security/LSM.txt
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -1,12 +1,13 @@
-Linux Security Module framework

+===
+Linux Security Module Usage
+===
 
 The Linux Security Module (LSM) framework provides a mechanism for
 various security checks to be hooked by new kernel extensions. The name
 "module" is a bit of a misnomer since these extensions are not actually
 loadable kernel modules. Instead, they are selectable at build-time via
 CONFIG_DEFAULT_SECURITY and can be overridden at boot-time via the
-"security=..." kernel command line argument, in the case where multiple
+``"security=..."`` kernel command line argument, in the case where multiple
 LSMs were built into a given kernel.
 
 The primary users of the LSM interface are Mandatory Access Control
@@ -19,23 +20,12 @@ in the core functionality of Linux itself.
 Without a specific LSM built into the kernel, the default LSM will be the
 Linux capabilities system. Most LSMs choose to extend the capabilities
 system, building their checks on top of the defined capability hooks.
-For more details on capabilities, see capabilities(7) in the Linux
+For more details on capabilities, see ``capabilities(7)`` in the Linux
 man-pages project.
 
 A list of the active security modules can be found by reading
-/sys/kernel/security/lsm. This is a comma separated list, and
+``/sys/kernel/security/lsm``. This is a comma separated list, and
 will always include the capability module. The list reflects the
 order in which checks are made. The capability module will always
 be first, followed by any "minor" modules (e.g. Yama) and then
 the one "major" module (e.g. SELinux) if there is one configured.
-
-Based on https://lkml.org/lkml/2007/10/26/215,
-a new LSM is accepted into the kernel when its intent (a description of
-what it tries to protect against and in what cases one would expect to
-use it) has been appropriately documented in Documentation/security/.
-This allows an LSM's code to be easily compared to its goals, and so
-that end users and distros can make a more informed decision about which
-LSMs suit their requirements.
-
-For extensive documentation on the available LSM hook interfaces, please
-see include/linux/security.h.
diff --git a/Documentation/admin-guide/index.rst 
b/Documentation/admin-guide/index.rst
index 8c60a8a32a1a..e14c374aaf60 100644
--- a/Documentation/admin-guide/index.rst
+++ b/Documentation/admin-guide/index.rst
@@ -61,6 +61,7 @@ configure specific aspects of kernel behavior to your liking.
java
ras
pm/index
+   LSM/index
 
 .. only::  subproject and html
 
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index c4df62a9ae5b..190a023a7e72 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -1,7 +1,5 @@
 00-INDEX
- this file.
-LSM.txt
-   - description of the Linux Security Module framework.
 SELinux.txt
- how to get started with the SELinux security enhancement.
 Smack.txt
diff --git a/Documentation/security/LSM.rst b/Documentation/security/LSM.rst
new file mode 100644
index ..d75778b0fa10
--- /dev/null
+++ b/Documentation/security/LSM.rst
@@ -0,0 +1,14 @@
+=
+Linux Security Module Development
+=
+
+Based on https://lkml.org/lkml/2007/10/26/215,
+a new LSM is accepted into the kernel when its intent (a description of
+what it tries to protect against and in what cases one would expect to
+use it) has been appropriately documented in ``Documentation/security/LSM``.
+This allows an LSM's code to be easily compared to its goals, and so
+that end users and distros can make a more informed decision about which
+LSMs suit their requirements.
+
+For extensive documentation on the available LSM hook interfaces, please
+see ``include/linux/lsm_hooks.h``.
diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst
index 4212d

[PATCH 10/17] doc: ReSTify tomoyo.txt

[Kees Cook]

Adjusts for ReST markup and moves under LSM admin guide.

Cc: Tetsuo Handa 
Signed-off-by: Kees Cook 
---
 Documentation/admin-guide/LSM/index.rst|  1 +
 .../tomoyo.txt => admin-guide/LSM/tomoyo.rst}  | 22 --
 Documentation/security/00-INDEX|  2 --
 3 files changed, 17 insertions(+), 8 deletions(-)
 rename Documentation/{security/tomoyo.txt => admin-guide/LSM/tomoyo.rst} (85%)

diff --git a/Documentation/admin-guide/LSM/index.rst 
b/Documentation/admin-guide/LSM/index.rst
index a4db29410ea0..6aa4e0dc588b 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -35,3 +35,4 @@ the one "major" module (e.g. SELinux) if there is one 
configured.
 
apparmor
SELinux
+   tomoyo
diff --git a/Documentation/security/tomoyo.txt 
b/Documentation/admin-guide/LSM/tomoyo.rst
similarity index 85%
rename from Documentation/security/tomoyo.txt
rename to Documentation/admin-guide/LSM/tomoyo.rst
index 200a2d37cbc8..a5947218fa64 100644
--- a/Documentation/security/tomoyo.txt
+++ b/Documentation/admin-guide/LSM/tomoyo.rst
@@ -1,21 +1,30 @@
 What is TOMOYO? ---
+==
+TOMOYO
+==
+
+What is TOMOYO?
+===
 
 TOMOYO is a name-based MAC extension (LSM module) for the Linux kernel.
 
 LiveCD-based tutorials are available at
+
 http://tomoyo.sourceforge.jp/1.7/1st-step/ubuntu10.04-live/
-http://tomoyo.sourceforge.jp/1.7/1st-step/centos5-live/ .
+http://tomoyo.sourceforge.jp/1.7/1st-step/centos5-live/
+
 Though these tutorials use non-LSM version of TOMOYO, they are useful for you
 to know what TOMOYO is.
 
 How to enable TOMOYO? ---
+How to enable TOMOYO?
+=
 
-Build the kernel with CONFIG_SECURITY_TOMOYO=y and pass "security=tomoyo" on
+Build the kernel with ``CONFIG_SECURITY_TOMOYO=y`` and pass 
``security=tomoyo`` on
 kernel's command line.
 
 Please see http://tomoyo.sourceforge.jp/2.3/ for details.
 
 Where is documentation? ---
+Where is documentation?
+===
 
 User <-> Kernel interface documentation is available at
 http://tomoyo.sourceforge.jp/2.3/policy-reference.html .
@@ -42,7 +51,8 @@ History of TOMOYO?
   Realities of Mainlining
 http://sourceforge.jp/projects/tomoyo/docs/lfj2008.pdf
 
 What is future plan? ---
+What is future plan?
+
 
 We believe that inode based security and name based security are complementary
 and both should be used together. But unfortunately, so far, we cannot enable
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index 22ebdc02f0dc..04ef62511ea1 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -12,5 +12,3 @@ keys-trusted-encrypted.txt
- info on the Trusted and Encrypted keys in the kernel key ring service.
 keys.txt
- description of the kernel key retention service.
-tomoyo.txt
-   - documentation on the TOMOYO Linux Security Module.
-- 
2.7.4

[PATCH 09/17] doc: ReSTify apparmor.txt

[Kees Cook]

Adjusts for ReST markup and moves under LSM admin guide.

Cc: John Johansen 
Signed-off-by: Kees Cook 
---
 .../apparmor.txt => admin-guide/LSM/apparmor.rst}  | 36 ++
 Documentation/admin-guide/LSM/index.rst|  1 +
 Documentation/security/00-INDEX|  2 --
 MAINTAINERS|  1 +
 security/apparmor/match.c  |  2 +-
 security/apparmor/policy_unpack.c  |  2 +-
 6 files changed, 28 insertions(+), 16 deletions(-)
 rename Documentation/{security/apparmor.txt => admin-guide/LSM/apparmor.rst} 
(65%)

diff --git a/Documentation/security/apparmor.txt 
b/Documentation/admin-guide/LSM/apparmor.rst
similarity index 65%
rename from Documentation/security/apparmor.txt
rename to Documentation/admin-guide/LSM/apparmor.rst
index 93c1fd7d0635..3e9734bd0e05 100644
--- a/Documentation/security/apparmor.txt
+++ b/Documentation/admin-guide/LSM/apparmor.rst
@@ -1,4 +1,9 @@
 What is AppArmor? ---
+
+AppArmor
+
+
+What is AppArmor?
+=
 
 AppArmor is MAC style security extension for the Linux kernel.  It implements
 a task centered policy, with task "profiles" being created and loaded
@@ -6,34 +11,41 @@ from user space.  Tasks on the system that do not have a 
profile defined for
 them run in an unconfined state which is equivalent to standard Linux DAC
 permissions.
 
 How to enable/disable ---
+How to enable/disable
+=
+
+set ``CONFIG_SECURITY_APPARMOR=y``
 
-set CONFIG_SECURITY_APPARMOR=y
+If AppArmor should be selected as the default security module then set::
 
-If AppArmor should be selected as the default security module then
-   set CONFIG_DEFAULT_SECURITY="apparmor"
-   and CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
+   CONFIG_DEFAULT_SECURITY="apparmor"
+   CONFIG_SECURITY_APPARMOR_BOOTPARAM_VALUE=1
 
 Build the kernel
 
 If AppArmor is not the default security module it can be enabled by passing
-security=apparmor on the kernel's command line.
+``security=apparmor`` on the kernel's command line.
 
 If AppArmor is the default security module it can be disabled by passing
-apparmor=0, security= (where XXX is valid security module), on the
-kernel's command line
+``apparmor=0, security=`` (where ```` is valid security module), on the
+kernel's command line.
 
 For AppArmor to enforce any restrictions beyond standard Linux DAC permissions
 policy must be loaded into the kernel from user space (see the Documentation
 and tools links).
 
 Documentation ---
+Documentation
+=
 
-Documentation can be found on the wiki.
+Documentation can be found on the wiki, linked below.
 
 Links ---
+Links
+=
 
 Mailing List - appar...@lists.ubuntu.com
+
 Wiki - http://apparmor.wiki.kernel.org/
+
 User space tools - https://launchpad.net/apparmor
+
 Kernel module - 
git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git
diff --git a/Documentation/admin-guide/LSM/index.rst 
b/Documentation/admin-guide/LSM/index.rst
index cc0e04d63bf9..a4db29410ea0 100644
--- a/Documentation/admin-guide/LSM/index.rst
+++ b/Documentation/admin-guide/LSM/index.rst
@@ -33,4 +33,5 @@ the one "major" module (e.g. SELinux) if there is one 
configured.
 .. toctree::
:maxdepth: 1
 
+   apparmor
SELinux
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index aaa0195418b3..22ebdc02f0dc 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -4,8 +4,6 @@ Smack.txt
- documentation on the Smack Linux Security Module.
 Yama.txt
- documentation on the Yama Linux Security Module.
-apparmor.txt
-   - documentation on the AppArmor security extension.
 keys-ecryptfs.txt
- description of the encryption keys for the ecryptfs filesystem.
 keys-request-key.txt
diff --git a/MAINTAINERS b/MAINTAINERS
index c85108b4f6c7..184cdd32a67e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11560,6 +11560,7 @@ W:  apparmor.wiki.kernel.org
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git
 S: Supported
 F: security/apparmor/
+F: Documentation/admin-guide/LSM/apparmor.rst
 
 LOADPIN SECURITY MODULE
 M: Kees Cook 
diff --git a/security/apparmor/match.c b/security/apparmor/match.c
index 960c913381e2..72c604350e80 100644
--- a/security/apparmor/match.c
+++ b/security/apparmor/match.c
@@ -226,7 +226,7 @@ void aa_dfa_free_kref(struct kref *kref)
  * @flags: flags controlling what type of accept tables are acceptable
  *
  * Unpack a dfa that has been serialized.  To find information on the dfa
- * format look in Documentation/security/apparmor.txt
+ * format look in Documentation/admin-guide/LSM/apparmor.rst
  * Assumes the dfa @blob stream has been aligned on a 8 byte boundary
  *
  * Returns: an unpacked dfa ready for matching or ERR_PTR on failure
diff --git a/security/apparmor/policy_unpack.c 
b/security/apparmor/policy_unpack.c
index

[PATCH 13/17] doc: ReSTify Smack.txt

[Kees Cook]

Adjusts for ReST markup and moves under LSM admin guide.

Cc: Casey Schaufler 
Signed-off-by: Kees Cook 
---
 .../Smack.txt => admin-guide/LSM/Smack.rst}| 273 ++---
 Documentation/admin-guide/LSM/index.rst|   1 +
 Documentation/security/00-INDEX|   2 -
 MAINTAINERS|   2 +-
 4 files changed, 191 insertions(+), 87 deletions(-)
 rename Documentation/{security/Smack.txt => admin-guide/LSM/Smack.rst} (85%)

diff --git a/Documentation/security/Smack.txt 
b/Documentation/admin-guide/LSM/Smack.rst
similarity index 85%
rename from Documentation/security/Smack.txt
rename to Documentation/admin-guide/LSM/Smack.rst
index 945cc633d883..6a5826a13aea 100644
--- a/Documentation/security/Smack.txt
+++ b/Documentation/admin-guide/LSM/Smack.rst
@@ -1,3 +1,6 @@
+=
+Smack
+=
 
 
 "Good for you, you've decided to clean the elevator!"
@@ -14,6 +17,7 @@ available to determine which is best suited to the problem
 at hand.
 
 Smack consists of three major components:
+
 - The kernel
 - Basic utilities, which are helpful but not required
 - Configuration data
@@ -39,16 +43,24 @@ The current git repository for Smack user space is:
 This should make and install on most modern distributions.
 There are five commands included in smackutil:
 
-chsmack- display or set Smack extended attribute values
-smackctl   - load the Smack access rules
-smackaccess - report if a process with one label has access
-  to an object with another
+chsmack:
+   display or set Smack extended attribute values
+
+smackctl:
+   load the Smack access rules
+
+smackaccess:
+   report if a process with one label has access
+   to an object with another
 
 These two commands are obsolete with the introduction of
 the smackfs/load2 and smackfs/cipso2 interfaces.
 
-smackload  - properly formats data for writing to smackfs/load
-smackcipso - properly formats data for writing to smackfs/cipso
+smackload:
+   properly formats data for writing to smackfs/load
+
+smackcipso:
+   properly formats data for writing to smackfs/cipso
 
 In keeping with the intent of Smack, configuration data is
 minimal and not strictly required. The most important
@@ -56,15 +68,15 @@ configuration step is mounting the smackfs pseudo 
filesystem.
 If smackutil is installed the startup script will take care
 of this, but it can be manually as well.
 
-Add this line to /etc/fstab:
+Add this line to ``/etc/fstab``::
 
 smackfs /sys/fs/smackfs smackfs defaults 0 0
 
-The /sys/fs/smackfs directory is created by the kernel.
+The ``/sys/fs/smackfs`` directory is created by the kernel.
 
 Smack uses extended attributes (xattrs) to store labels on filesystem
 objects. The attributes are stored in the extended attribute security
-name space. A process must have CAP_MAC_ADMIN to change any of these
+name space. A process must have ``CAP_MAC_ADMIN`` to change any of these
 attributes.
 
 The extended attributes that Smack uses are:
@@ -73,14 +85,17 @@ SMACK64
Used to make access control decisions. In almost all cases
the label given to a new filesystem object will be the label
of the process that created it.
+
 SMACK64EXEC
The Smack label of a process that execs a program file with
this attribute set will run with this attribute's value.
+
 SMACK64MMAP
Don't allow the file to be mmapped by a process whose Smack
label does not allow all of the access permitted to a process
with the label contained in this attribute. This is a very
specific use case for shared libraries.
+
 SMACK64TRANSMUTE
Can only have the value "TRUE". If this attribute is present
on a directory when an object is created in the directory and
@@ -89,27 +104,29 @@ SMACK64TRANSMUTE
gets the label of the directory instead of the label of the
creating process. If the object being created is a directory
the SMACK64TRANSMUTE attribute is set as well.
+
 SMACK64IPIN
This attribute is only available on file descriptors for sockets.
Use the Smack label in this attribute for access control
decisions on packets being delivered to this socket.
+
 SMACK64IPOUT
This attribute is only available on file descriptors for sockets.
Use the Smack label in this attribute for access control
decisions on packets coming from this socket.
 
-There are multiple ways to set a Smack label on a file:
+There are multiple ways to set a Smack label on a file::
 
 # attr -S -s SMACK64 -V "value" path
 # chsmack -a value path
 
 A process can see the Smack label it is running with by
-reading /proc/self/attr/current. A process with CAP_MAC_ADMIN
+reading ``/proc/self/attr/current``. A process with ``CAP_MAC_ADMIN``
 can set the process Smack by writing there.
 
 Most Smack configuration is accomplished by writing to files
 in the smackfs filesyst

[PATCH 02/17] doc: ReSTify no_new_privs.txt

[Kees Cook]

This updates no_new_privs documentation to ReST markup and adds it to
the user-space API documentation.

Signed-off-by: Kees Cook 
---
 Documentation/userspace-api/index.rst  |  1 +
 .../no_new_privs.rst}  | 44 --
 2 files changed, 26 insertions(+), 19 deletions(-)
 rename Documentation/{prctl/no_new_privs.txt => 
userspace-api/no_new_privs.rst} (54%)

diff --git a/Documentation/userspace-api/index.rst 
b/Documentation/userspace-api/index.rst
index 15ff12342db8..7b2eb1b7d4ca 100644
--- a/Documentation/userspace-api/index.rst
+++ b/Documentation/userspace-api/index.rst
@@ -16,6 +16,7 @@ place where this information is gathered.
 .. toctree::
:maxdepth: 2
 
+   no_new_privs
seccomp_filter
unshare
 
diff --git a/Documentation/prctl/no_new_privs.txt 
b/Documentation/userspace-api/no_new_privs.rst
similarity index 54%
rename from Documentation/prctl/no_new_privs.txt
rename to Documentation/userspace-api/no_new_privs.rst
index f7be84fba910..d060ea217ea1 100644
--- a/Documentation/prctl/no_new_privs.txt
+++ b/Documentation/userspace-api/no_new_privs.rst
@@ -1,3 +1,7 @@
+==
+No New Privileges Flag
+==
+
 The execve system call can grant a newly-started program privileges that
 its parent did not have.  The most obvious examples are setuid/setgid
 programs and file capabilities.  To prevent the parent program from
@@ -5,53 +9,55 @@ gaining these privileges as well, the kernel and user code 
must be
 careful to prevent the parent from doing anything that could subvert the
 child.  For example:
 
- - The dynamic loader handles LD_* environment variables differently if
+ - The dynamic loader handles ``LD_*`` environment variables differently if
a program is setuid.
 
  - chroot is disallowed to unprivileged processes, since it would allow
-   /etc/passwd to be replaced from the point of view of a process that
+   ``/etc/passwd`` to be replaced from the point of view of a process that
inherited chroot.
 
  - The exec code has special handling for ptrace.
 
-These are all ad-hoc fixes.  The no_new_privs bit (since Linux 3.5) is a
+These are all ad-hoc fixes.  The ``no_new_privs`` bit (since Linux 3.5) is a
 new, generic mechanism to make it safe for a process to modify its
 execution environment in a manner that persists across execve.  Any task
-can set no_new_privs.  Once the bit is set, it is inherited across fork,
-clone, and execve and cannot be unset.  With no_new_privs set, execve
+can set ``no_new_privs``.  Once the bit is set, it is inherited across fork,
+clone, and execve and cannot be unset.  With ``no_new_privs`` set, ``execve()``
 promises not to grant the privilege to do anything that could not have
 been done without the execve call.  For example, the setuid and setgid
 bits will no longer change the uid or gid; file capabilities will not
 add to the permitted set, and LSMs will not relax constraints after
 execve.
 
-To set no_new_privs, use prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0).
+To set ``no_new_privs``, use::
+
+prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0);
 
 Be careful, though: LSMs might also not tighten constraints on exec
-in no_new_privs mode.  (This means that setting up a general-purpose
-service launcher to set no_new_privs before execing daemons may
+in ``no_new_privs`` mode.  (This means that setting up a general-purpose
+service launcher to set ``no_new_privs`` before execing daemons may
 interfere with LSM-based sandboxing.)
 
-Note that no_new_privs does not prevent privilege changes that do not
-involve execve.  An appropriately privileged task can still call
-setuid(2) and receive SCM_RIGHTS datagrams.
+Note that ``no_new_privs`` does not prevent privilege changes that do not
+involve ``execve()``.  An appropriately privileged task can still call
+``setuid(2)`` and receive SCM_RIGHTS datagrams.
 
-There are two main use cases for no_new_privs so far:
+There are two main use cases for ``no_new_privs`` so far:
 
  - Filters installed for the seccomp mode 2 sandbox persist across
execve and can change the behavior of newly-executed programs.
Unprivileged users are therefore only allowed to install such filters
-   if no_new_privs is set.
+   if ``no_new_privs`` is set.
 
- - By itself, no_new_privs can be used to reduce the attack surface
+ - By itself, ``no_new_privs`` can be used to reduce the attack surface
available to an unprivileged user.  If everything running with a
-   given uid has no_new_privs set, then that uid will be unable to
+   given uid has ``no_new_privs`` set, then that uid will be unable to
escalate its privileges by directly attacking setuid, setgid, and
fcap-using binaries; it will need to compromise something without the
-   no_new_privs bit set first.
+   ``no_new_privs`` bit set first.
 
 In the future, other potentially dangerous kernel features could become
-available to unprivileged tasks if no_new_privs is set.  In princip

[PATCH 06/17] doc: security: minor cleanups to build kernel-doc

[Kees Cook]

These fixes were needed to parse lsm_hooks.h kernel-doc. More work is
needed, but this is the first step.

Cc: Casey Schaufler 
Signed-off-by: Kees Cook 
---
 include/linux/lsm_hooks.h | 25 -
 1 file changed, 12 insertions(+), 13 deletions(-)

diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 080f34e66017..a1eeaf603d2f 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -29,6 +29,8 @@
 #include 
 
 /**
+ * union security_list_options - Linux Security Module hook function list
+ *
  * Security hooks for program execution operations.
  *
  * @bprm_set_creds:
@@ -193,8 +195,8 @@
  * @value will be set to the allocated attribute value.
  * @len will be set to the length of the value.
  * Returns 0 if @name and @value have been successfully set,
- * -EOPNOTSUPP if no security attribute is needed, or
- * -ENOMEM on memory allocation failure.
+ * -EOPNOTSUPP if no security attribute is needed, or
+ * -ENOMEM on memory allocation failure.
  * @inode_create:
  * Check permission to create a regular file.
  * @dir contains inode structure of the parent of the new file.
@@ -510,8 +512,7 @@
  * process @tsk.  Note that this hook is sometimes called from interrupt.
  * Note that the fown_struct, @fown, is never outside the context of a
  * struct file, so the file structure (and associated security information)
- * can always be obtained:
- * container_of(fown, struct file, f_owner)
+ * can always be obtained: container_of(fown, struct file, f_owner)
  * @tsk contains the structure of task receiving signal.
  * @fown contains the file owner information.
  * @sig is the signal that will be sent.  When 0, kernel sends SIGIO.
@@ -521,7 +522,7 @@
  * to receive an open file descriptor via socket IPC.
  * @file contains the file structure being received.
  * Return 0 if permission is granted.
- * @file_open
+ * @file_open:
  * Save open-time permission checking state for later use upon
  * file_permission, and recheck access if anything has changed
  * since inode_permission.
@@ -1143,7 +1144,7 @@
  * @sma contains the semaphore structure.  May be NULL.
  * @cmd contains the operation to be performed.
  * Return 0 if permission is granted.
- * @sem_semop
+ * @sem_semop:
  * Check permissions before performing operations on members of the
  * semaphore set @sma.  If the @alter flag is nonzero, the semaphore set
  * may be modified.
@@ -1153,20 +1154,20 @@
  * @alter contains the flag indicating whether changes are to be made.
  * Return 0 if permission is granted.
  *
- * @binder_set_context_mgr
+ * @binder_set_context_mgr:
  * Check whether @mgr is allowed to be the binder context manager.
  * @mgr contains the task_struct for the task being registered.
  * Return 0 if permission is granted.
- * @binder_transaction
+ * @binder_transaction:
  * Check whether @from is allowed to invoke a binder transaction call
  * to @to.
  * @from contains the task_struct for the sending task.
  * @to contains the task_struct for the receiving task.
- * @binder_transfer_binder
+ * @binder_transfer_binder:
  * Check whether @from is allowed to transfer a binder reference to @to.
  * @from contains the task_struct for the sending task.
  * @to contains the task_struct for the receiving task.
- * @binder_transfer_file
+ * @binder_transfer_file:
  * Check whether @from is allowed to transfer @file to @to.
  * @from contains the task_struct for the sending task.
  * @file contains the struct file being transferred.
@@ -1214,7 +1215,7 @@
  * @cred contains the credentials to use.
  * @ns contains the user namespace we want the capability in
  * @cap contains the capability .
- * @audit: Whether to write an audit message or not
+ * @audit contains whether to write an audit message or not
  * Return 0 if the capability is granted for @tsk.
  * @syslog:
  * Check permission before accessing the kernel message ring or changing
@@ -1336,9 +1337,7 @@
  * @inode we wish to get the security context of.
  * @ctx is a pointer in which to place the allocated security context.
  * @ctxlen points to the place to put the length of @ctx.
- * This is the main security structure.
  */
-
 union security_list_options {
int (*binder_set_context_mgr)(struct task_struct *mgr);
int (*binder_transaction)(struct task_struct *from,
-- 
2.7.4

[PATCH 05/17] doc: ReSTify self-protection.txt

[Kees Cook]

This updates the credentials API documentation to ReST markup and moves
it under the security subsection of kernel API documentation.

Signed-off-by: Kees Cook 
---
 Documentation/security/index.rst   |  1 +
 .../{self-protection.txt => self-protection.rst}   | 99 ++
 2 files changed, 64 insertions(+), 36 deletions(-)
 rename Documentation/security/{self-protection.txt => self-protection.rst} 
(83%)

diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst
index 415be8e0b013..4212d7ac58b6 100644
--- a/Documentation/security/index.rst
+++ b/Documentation/security/index.rst
@@ -7,4 +7,5 @@ Security Documentation
 
credentials
IMA-templates
+   self-protection
tpm/index
diff --git a/Documentation/security/self-protection.txt 
b/Documentation/security/self-protection.rst
similarity index 83%
rename from Documentation/security/self-protection.txt
rename to Documentation/security/self-protection.rst
index 141acfebe6ef..60c8bd8b77bf 100644
--- a/Documentation/security/self-protection.txt
+++ b/Documentation/security/self-protection.rst
@@ -1,4 +1,6 @@
-# Kernel Self-Protection
+==
+Kernel Self-Protection
+==
 
 Kernel self-protection is the design and implementation of systems and
 structures within the Linux kernel to protect against security flaws in
@@ -26,7 +28,8 @@ mentioning them, since these aspects need to be explored, 
dealt with,
 and/or accepted.
 
 
-## Attack Surface Reduction
+Attack Surface Reduction
+
 
 The most fundamental defense against security exploits is to reduce the
 areas of the kernel that can be used to redirect execution. This ranges
@@ -34,13 +37,15 @@ from limiting the exposed APIs available to userspace, 
making in-kernel
 APIs hard to use incorrectly, minimizing the areas of writable kernel
 memory, etc.
 
-### Strict kernel memory permissions
+Strict kernel memory permissions
+
 
 When all of kernel memory is writable, it becomes trivial for attacks
 to redirect execution flow. To reduce the availability of these targets
 the kernel needs to protect its memory with a tight set of permissions.
 
- Executable code and read-only data must not be writable
+Executable code and read-only data must not be writable
+~~~
 
 Any areas of the kernel with executable memory must not be writable.
 While this obviously includes the kernel text itself, we must consider
@@ -51,18 +56,19 @@ kernel, they are implemented in a way where the memory is 
temporarily
 made writable during the update, and then returned to the original
 permissions.)
 
-In support of this are CONFIG_STRICT_KERNEL_RWX and
-CONFIG_STRICT_MODULE_RWX, which seek to make sure that code is not
+In support of this are ``CONFIG_STRICT_KERNEL_RWX`` and
+``CONFIG_STRICT_MODULE_RWX``, which seek to make sure that code is not
 writable, data is not executable, and read-only data is neither writable
 nor executable.
 
 Most architectures have these options on by default and not user selectable.
 For some architectures like arm that wish to have these be selectable,
 the architecture Kconfig can select ARCH_OPTIONAL_KERNEL_RWX to enable
-a Kconfig prompt. CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT determines
+a Kconfig prompt. ``CONFIG_ARCH_OPTIONAL_KERNEL_RWX_DEFAULT`` determines
 the default setting when ARCH_OPTIONAL_KERNEL_RWX is enabled.
 
- Function pointers and sensitive variables must not be writable
+Function pointers and sensitive variables must not be writable
+~~
 
 Vast areas of kernel memory contain function pointers that are looked
 up by the kernel and used to continue execution (e.g. descriptor/vector
@@ -74,8 +80,8 @@ so that they live in the .rodata section instead of the .data 
section
 of the kernel, gaining the protection of the kernel's strict memory
 permissions as described above.
 
-For variables that are initialized once at __init time, these can
-be marked with the (new and under development) __ro_after_init
+For variables that are initialized once at ``__init`` time, these can
+be marked with the (new and under development) ``__ro_after_init``
 attribute.
 
 What remains are variables that are updated rarely (e.g. GDT). These
@@ -85,7 +91,8 @@ of their lifetime read-only. (For example, when being 
updated, only the
 CPU thread performing the update would be given uninterruptible write
 access to the memory.)
 
- Segregation of kernel memory from userspace memory
+Segregation of kernel memory from userspace memory
+~~
 
 The kernel must never execute userspace memory. The kernel must also never
 access userspace memory without explicit expectation to do so. These
@@ -95,10 +102,11 @@ By blocking userspace memory in this way, execution and 
data parsing
 cannot be passed to trivi

[PATCH 04/17] doc: ReSTify credentials.txt

[Kees Cook]

This updates the credentials API documentation to ReST markup and moves
it under the security subsection of kernel API documentation.

Cc: David Howells 
Signed-off-by: Kees Cook 
---
 Documentation/security/00-INDEX|   2 -
 .../security/{credentials.txt => credentials.rst}  | 275 ++---
 Documentation/security/index.rst   |   1 +
 include/linux/cred.h   |   2 +-
 kernel/cred.c  |   2 +-
 5 files changed, 127 insertions(+), 155 deletions(-)
 rename Documentation/security/{credentials.txt => credentials.rst} (72%)

diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index 414235c1fcfc..c4df62a9ae5b 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -10,8 +10,6 @@ Yama.txt
- documentation on the Yama Linux Security Module.
 apparmor.txt
- documentation on the AppArmor security extension.
-credentials.txt
-   - documentation about credentials in Linux.
 keys-ecryptfs.txt
- description of the encryption keys for the ecryptfs filesystem.
 keys-request-key.txt
diff --git a/Documentation/security/credentials.txt 
b/Documentation/security/credentials.rst
similarity index 72%
rename from Documentation/security/credentials.txt
rename to Documentation/security/credentials.rst
index 86257052e31a..038a7e19eff9 100644
--- a/Documentation/security/credentials.txt
+++ b/Documentation/security/credentials.rst
@@ -1,38 +1,18 @@
-
-CREDENTIALS IN LINUX
-
+
+Credentials in Linux
+
 
 By: David Howells 
 
-Contents:
-
- (*) Overview.
-
- (*) Types of credentials.
-
- (*) File markings.
-
- (*) Task credentials.
+.. contents:: :local:
 
- - Immutable credentials.
- - Accessing task credentials.
- - Accessing another task's credentials.
- - Altering credentials.
- - Managing credentials.
-
- (*) Open file credentials.
-
- (*) Overriding the VFS's use of credentials.
-
-
-
-OVERVIEW
+Overview
 
 
 There are several parts to the security check performed by Linux when one
 object acts upon another:
 
- (1) Objects.
+ 1. Objects.
 
  Objects are things in the system that may be acted upon directly by
  userspace programs.  Linux has a variety of actionable objects, including:
@@ -48,7 +28,7 @@ object acts upon another:
  As a part of the description of all these objects there is a set of
  credentials.  What's in the set depends on the type of object.
 
- (2) Object ownership.
+ 2. Object ownership.
 
  Amongst the credentials of most objects, there will be a subset that
  indicates the ownership of that object.  This is used for resource
@@ -57,7 +37,7 @@ object acts upon another:
  In a standard UNIX filesystem, for instance, this will be defined by the
  UID marked on the inode.
 
- (3) The objective context.
+ 3. The objective context.
 
  Also amongst the credentials of those objects, there will be a subset that
  indicates the 'objective context' of that object.  This may or may not be
@@ -67,7 +47,7 @@ object acts upon another:
  The objective context is used as part of the security calculation that is
  carried out when an object is acted upon.
 
- (4) Subjects.
+ 4. Subjects.
 
  A subject is an object that is acting upon another object.
 
@@ -77,10 +57,10 @@ object acts upon another:
 
  Objects other than tasks may under some circumstances also be subjects.
  For instance an open file may send SIGIO to a task using the UID and EUID
- given to it by a task that called fcntl(F_SETOWN) upon it.  In this case,
+ given to it by a task that called ``fcntl(F_SETOWN)`` upon it.  In this 
case,
  the file struct will have a subjective context too.
 
- (5) The subjective context.
+ 5. The subjective context.
 
  A subject has an additional interpretation of its credentials.  A subset
  of its credentials forms the 'subjective context'.  The subjective context
@@ -92,7 +72,7 @@ object acts upon another:
  from the real UID and GID that normally form the objective context of the
  task.
 
- (6) Actions.
+ 6. Actions.
 
  Linux has a number of actions available that a subject may perform upon an
  object.  The set of actions available depends on the nature of the subject
@@ -101,7 +81,7 @@ object acts upon another:
  Actions include reading, writing, creating and deleting files; forking or
  signalling and tracing tasks.
 
- (7) Rules, access control lists and security calculations.
+ 7. Rules, access control lists and security calculations.
 
  When a subject acts upon an object, a security calculation is made.  This
  involves taking the subjective context, the objective context and the
@@ -111,7 +91,7 @@ object acts upon ano

[PATCH 03/17] doc: ReSTify IMA-templates.txt

[Kees Cook]

Adjust IMA-templates.txt for ReST markup and add to the index for
security/, under the Kernel API Documentation.

Cc: Mimi Zohar 
Signed-off-by: Kees Cook 
---
 Documentation/security/00-INDEX|  2 -
 .../{IMA-templates.txt => IMA-templates.rst}   | 46 --
 Documentation/security/index.rst   |  4 +-
 3 files changed, 29 insertions(+), 23 deletions(-)
 rename Documentation/security/{IMA-templates.txt => IMA-templates.rst} (72%)

diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index 45c82fd3e9d3..414235c1fcfc 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -22,5 +22,3 @@ keys.txt
- description of the kernel key retention service.
 tomoyo.txt
- documentation on the TOMOYO Linux Security Module.
-IMA-templates.txt
-   - documentation on the template management mechanism for IMA.
diff --git a/Documentation/security/IMA-templates.txt 
b/Documentation/security/IMA-templates.rst
similarity index 72%
rename from Documentation/security/IMA-templates.txt
rename to Documentation/security/IMA-templates.rst
index 839b5dad9226..2cd0e273cc9a 100644
--- a/Documentation/security/IMA-templates.txt
+++ b/Documentation/security/IMA-templates.rst
@@ -1,9 +1,12 @@
-   IMA Template Management Mechanism
+=
+IMA Template Management Mechanism
+=
 
 
- INTRODUCTION 
+Introduction
+
 
-The original 'ima' template is fixed length, containing the filedata hash
+The original ``ima`` template is fixed length, containing the filedata hash
 and pathname. The filedata hash is limited to 20 bytes (md5/sha1).
 The pathname is a null terminated string, limited to 255 characters.
 To overcome these limitations and to add additional file metadata, it is
@@ -28,61 +31,64 @@ a new data type, developers define the field identifier and 
implement
 two functions, init() and show(), respectively to generate and display
 measurement entries. Defining a new template descriptor requires
 specifying the template format (a string of field identifiers separated
-by the '|' character) through the 'ima_template_fmt' kernel command line
+by the ``|`` character) through the ``ima_template_fmt`` kernel command line
 parameter. At boot time, IMA initializes the chosen template descriptor
 by translating the format into an array of template fields structures taken
 from the set of the supported ones.
 
-After the initialization step, IMA will call ima_alloc_init_template()
+After the initialization step, IMA will call ``ima_alloc_init_template()``
 (new function defined within the patches for the new template management
 mechanism) to generate a new measurement entry by using the template
 descriptor chosen through the kernel configuration or through the newly
-introduced 'ima_template' and 'ima_template_fmt' kernel command line 
parameters.
+introduced ``ima_template`` and ``ima_template_fmt`` kernel command line 
parameters.
 It is during this phase that the advantages of the new architecture are
 clearly shown: the latter function will not contain specific code to handle
-a given template but, instead, it simply calls the init() method of the 
template
+a given template but, instead, it simply calls the ``init()`` method of the 
template
 fields associated to the chosen template descriptor and store the result
 (pointer to allocated data and data length) in the measurement entry structure.
 
 The same mechanism is employed to display measurements entries.
-The functions ima[_ascii]_measurements_show() retrieve, for each entry,
+The functions ``ima[_ascii]_measurements_show()`` retrieve, for each entry,
 the template descriptor used to produce that entry and call the show()
 method for each item of the array of template fields structures.
 
 
 
- SUPPORTED TEMPLATE FIELDS AND DESCRIPTORS 
+Supported Template Fields and Descriptors
+=
 
 In the following, there is the list of supported template fields
-('': description), that can be used to define new template
+``('': description)``, that can be used to define new template
 descriptors by adding their identifier to the format string
 (support for more data types will be added later):
 
  - 'd': the digest of the event (i.e. the digest of a measured file),
-calculated with the SHA1 or MD5 hash algorithm;
+   calculated with the SHA1 or MD5 hash algorithm;
  - 'n': the name of the event (i.e. the file name), with size up to 255 bytes;
  - 'd-ng': the digest of the event, calculated with an arbitrary hash
-   algorithm (field format: [:]digest, where the digest
-   prefix is shown only if the hash algorithm is not SHA1 or MD5);
+   algorithm (field format: [:]digest, where the digest
+   prefix is shown only if the hash algorithm is not SHA1 or MD5);
  - 'n-ng': the name of the event, without size li

Re: [git pull] uaccess-related bits of vfs.git

[Adam Borowski]

On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote:
> On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote:
> > But the *first* thing I'd like to do would be to just get rid of
> > __get_user/__put_user as a thing. It really does generate nasty code,
> > and we might as well just make it do that function call.
> 
> But IMO the first step is not to convert __get_user()/__put_user() to
> aliases of get_user()/put_user() - it's to get rid of their infestations
> outside of arch/*.  They are concentrated in relatively few places, so
> we can deal with those individually and then just fucking ban their use
> outside of arch/*.  That's easy enough to watch for - simple git grep will do,
> so anything creeping back will be immediately spotted.

As someone from the peanuts gallery, I took a look for __put_user() in my
usual haunt, drivers/tty/vt/

* use 1: con_[gs]et_trans_*():
  Copies a linear array of 256 bytes/shorts, one by one.
  The obvious patch has 9 insertions(+), 22 deletions(-).

* use 2: con_[gs]et_unimap():
  Ditto, up to 65535*2 shorts, also in a nice linear array.

* use 3: tioclinux():
  Does a __put into a place that was checked only for read.  This got me
  frightened as it initially looked like something that can allow an user to
  write where they shouldn't.  Fortunately, it turns out the first argument
  to access_ok() is ignored on every single architecture -- why does it even
  exist then?  I imagined it's there for some odd arch that allows writes
  when in privileged mode, but unlike what the docs say, VERIFY_WRITE is
  exactly same as VERIFY_READ.

Ie, every use in this sample is wrong.  I suspect the rest of the kernel
should be similar.


Meow!
-- 
Don't be racist.  White, amber or black, all beers should be judged based
solely on their merits.  Heck, even if occasionally a cider applies for a
beer's job, why not?
On the other hand, corpo lager is not a race.

Re: [PATCH] nvme: Change our APST table to be no more aggressive than Intel RSTe

[Andy Lutomirski]

On Thu, May 11, 2017 at 9:06 PM, Andy Lutomirski  wrote:
> It seems like RSTe is much more conservative with transition timing
> that we are.  According to Mario, RSTe programs APST to transition from
> active states to the first idle state after 60ms and, thereafter, to
> 1000 * the exit latency of the target state.

Bad news, folks: this appears to be merely more stable, not all the way stable:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184/comments/65

I maintain my hypothesis that no one ever validated these disks and
that the very conservative parameters set by RSTe merely make it rare
to trigger the bug.  But maybe something else is going on.

Re: [PATCH 1/2] fdt: correctly handle uncompressed node names

[kbuild test robot]

Hi Sascha,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11 next-20170512]
[cannot apply to glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sascha-Silbe/fdt-correctly-handle-uncompressed-node-names/20170513-184012
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm64-alldefconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64 

All errors (new ones prefixed by >>):

   ./drivers/firmware/efi/libstub/lib.a(lib-fdt_ro.stub.o): In function 
`__efistub_fdt_subnode_offset_namelen':
>> __efistub_fdt_ro.c:(.init.text+0x248): undefined reference to 
>> `__efistub_strrchr'
   __efistub_fdt_ro.c:(.init.text+0x248): relocation truncated to fit: 
R_AARCH64_CALL26 against undefined symbol `__efistub_strrchr'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH][RFC] x86/irq: Spread vectors on different CPUs

[Chen Yu]

Currently we encountered the CPU offline problem on a 16 cores server
when doing hibernation:

CPU 31 disable failed: CPU has 62 vectors assigned and there are only 0 
available.

This is because:
1. One of the drivers has declare many vector resource via
   pci_enable_msix_range(), say, this driver might likely want
   to reserve 6 per logical CPU, then there would be 192 of them.
2. Besides, most of the vectors for this driver are allocated
   on CPU0 due to the current code strategy, so there would be
   insufficient slots left on CPU0 to receive any migrated
   IRQs from the other CPUs during CPU offine.
3. Furthermore, many vectors this driver reserved do no have
   any IRQ handler attached.

As a result, all vectors on CPU0 were used out and the last alive
CPU (31) failed to migrate its IRQs to the CPU0.

As we might have difficulty to reduce the number of vectors reserved
by that driver, there could be a compromising solution that, to spread
the vector allocation on different CPUs rather than always choosing
the *first* CPU in the cpumask. In this way, there would be a balanced
vector distribution. Because many vectors reserved but without used(point 3
above) will not be counted in during CPU offline, and they are now
on nonboot CPUs this problem will be solved.

Here's the trial version of this proposal and it works in my case,
it just tries to find the target CPU with the least vectors allocated(AKA,
the 'idlest' CPU). And the algorithm can be optimized but
firstly I'd like to get suggestions from you experts if this is in
the right direction, or what is the proper solution for such kind
of problems? Any comments/suggestions are appreciated.

Reported-by: Xiang Li 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "Anvin, H Peter" 
Cc: "Van De Ven, Arjan" 
Cc: "Brown, Len" 
Cc: "Wysocki, Rafael J" 
Cc: x...@kernel.org
Signed-off-by: Chen Yu 
---
 arch/x86/kernel/apic/vector.c | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index f3557a1..d220365 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -102,6 +102,27 @@ static void free_apic_chip_data(struct apic_chip_data 
*data)
}
 }
 
+static int pick_leisure_cpu(const struct cpumask *mask)
+{
+   int cpu, vector;
+   int min_nr_vector = NR_VECTORS;
+   int target_cpu = cpumask_first_and(mask, cpu_online_mask);
+
+   for_each_cpu_and(cpu, mask, cpu_online_mask) {
+   int nr_vectors = 0;
+
+   for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS; 
vector++) {
+   if (!IS_ERR_OR_NULL(per_cpu(vector_irq, cpu)[vector]))
+   nr_vectors++;
+   }
+   if (nr_vectors < min_nr_vector) {
+   min_nr_vector = nr_vectors;
+   target_cpu = cpu;
+   }
+   }
+   return target_cpu;
+}
+
 static int __assign_irq_vector(int irq, struct apic_chip_data *d,
   const struct cpumask *mask)
 {
@@ -131,7 +152,7 @@ static int __assign_irq_vector(int irq, struct 
apic_chip_data *d,
/* Only try and allocate irqs on cpus that are present */
cpumask_clear(d->old_domain);
cpumask_clear(searched_cpumask);
-   cpu = cpumask_first_and(mask, cpu_online_mask);
+   cpu = pick_leisure_cpu(mask);
while (cpu < nr_cpu_ids) {
int new_cpu, offset;
 
-- 
2.7.4

RE: [tpmdd-devel] [PATCH] Add "shutdown" to "struct class".

[Winkler, Tomas]

> The TPM class has some common shutdown code that must be executed for
> all drivers. This adds some needed functionality for that

The issue with this is, that on some platforms the only storage can be eMMC and 
TPM is using it,. It  has to be ensured that the storage device  won't go down 
before  TPM2_shutdown is called. 
And there is no direct device hierarchy to ensure an orderly shutdown. 
Tomas 

> 
> (In addition, update a comment to reflect an out-of-date path.)
> ---
>  drivers/base/core.c| 5 +
>  include/linux/device.h | 4 +++-
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c index
> bbecaf9293be..5c1648875e94 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2667,6 +2667,11 @@ void device_shutdown(void)
>   pm_runtime_get_noresume(dev);
>   pm_runtime_barrier(dev);
> 
> + if (dev->class && dev->class->shutdown) {
> + if (initcall_debug)
> + dev_info(dev, "shutdown\n");
> + dev->class->shutdown(dev);
> + }
>   if (dev->bus && dev->bus->shutdown) {
>   if (initcall_debug)
>   dev_info(dev, "shutdown\n");
> diff --git a/include/linux/device.h b/include/linux/device.h index
> 9ef518af5515..a150f8d3b3f1 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -378,6 +378,7 @@ int subsys_virtual_register(struct bus_type *subsys,
>   * @suspend: Used to put the device to sleep mode, usually to a low
> power
>   *   state.
>   * @resume:  Used to bring the device from the sleep mode.
> + * @shutdown:Called at shut-down time to quiesce the device.
>   * @ns_type: Callbacks so sysfs can detemine namespaces.
>   * @namespace:   Namespace of the device belongs to this class.
>   * @pm:  The default device power management operations of
> this class.
> @@ -407,6 +408,7 @@ struct class {
> 
>   int (*suspend)(struct device *dev, pm_message_t state);
>   int (*resume)(struct device *dev);
> + int (*shutdown)(struct device *dev);
> 
>   const struct kobj_ns_type_operations *ns_type;
>   const void *(*namespace)(struct device *dev); @@ -1228,7 +1230,7
> @@ static inline int devtmpfs_delete_node(struct device *dev) { return 0; }
> static inline int devtmpfs_mount(const char *mountpoint) { return 0; }
> #endif
> 
> -/* drivers/base/power/shutdown.c */
> +/* drivers/base/core.c */
>  extern void device_shutdown(void);
> 
>  /* debugging and troubleshooting/diagnostic helpers. */
> --
> 2.13.0.rc2.291.g57267f2277-goog
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> tpmdd-devel mailing list
> tpmdd-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tpmdd-devel

[PATCH] mmc: core: Delete an error message for a failed memory allocation in three functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 13 May 2017 14:40:08 +0200

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 drivers/mmc/core/sd.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index d109634fbfce..1d7542daecbe 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -294,12 +294,8 @@ static int mmc_read_switch(struct mmc_card *card)
err = -EIO;
 
status = kmalloc(64, GFP_KERNEL);
-   if (!status) {
-   pr_err("%s: could not allocate a buffer for "
-   "switch capabilities.\n",
-   mmc_hostname(card->host));
+   if (!status)
return -ENOMEM;
-   }
 
/*
 * Find out the card's support bits with a mode 0 operation.
@@ -359,11 +355,8 @@ int mmc_sd_switch_hs(struct mmc_card *card)
return 0;
 
status = kmalloc(64, GFP_KERNEL);
-   if (!status) {
-   pr_err("%s: could not allocate a buffer for "
-   "switch capabilities.\n", mmc_hostname(card->host));
+   if (!status)
return -ENOMEM;
-   }
 
err = mmc_sd_switch(card, 1, 0, 1, status);
if (err)
@@ -596,11 +589,8 @@ static int mmc_sd_init_uhs_card(struct mmc_card *card)
return 0;
 
status = kmalloc(64, GFP_KERNEL);
-   if (!status) {
-   pr_err("%s: could not allocate a buffer for "
-   "switch capabilities.\n", mmc_hostname(card->host));
+   if (!status)
return -ENOMEM;
-   }
 
/* Set 4-bit bus width */
if ((card->host->caps & MMC_CAP_4_BIT_DATA) &&
-- 
2.12.3

Re: [PATCH 1/2] fdt: correctly handle uncompressed node names

[kbuild test robot]

Hi Sascha,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.11 next-20170512]
[cannot apply to glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Sascha-Silbe/fdt-correctly-handle-uncompressed-node-names/20170513-184012
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-omap2plus_defconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   arch/arm/boot/compressed/fdt_ro.o: In function `fdt_subnode_offset_namelen':
>> arch/arm/boot/compressed/fdt_ro.c:69: undefined reference to `strrchr'
>> arch/arm/boot/compressed/fdt_ro.o:(.debug_addr+0x364): undefined reference 
>> to `strrchr'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH] mmc: atmel-mci: Delete an error message for a failed memory allocation in atmci_of_init()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 13 May 2017 15:05:28 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Link: 
http://events.linuxfoundation.org/sites/events/files/slides/LCJ16-Refactor_Strings-WSang_0.pdf
Signed-off-by: Markus Elfring 
---
 drivers/mmc/host/atmel-mci.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 388e4a3f13e6..584247464eb8 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -667,10 +667,8 @@ atmci_of_init(struct platform_device *pdev)
}
 
pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
-   if (!pdata) {
-   dev_err(&pdev->dev, "could not allocate memory for pdata\n");
+   if (!pdata)
return ERR_PTR(-ENOMEM);
-   }
 
for_each_child_of_node(np, cnp) {
if (of_property_read_u32(cnp, "reg", &slot_id)) {
-- 
2.12.3

Re: [PATCH 2/2] ARM: davinci: PM: Do not free useful resources in normal path in 'davinci_pm_init'

[walter harms]

Am 13.05.2017 13:40, schrieb Christophe JAILLET:
> This looks spurious to iounmap resources in the normal path of this init
> function.
> The 3 ioremap'ed fields of 'pm_config' can be accessed later on in other
> functions, so it is likely that we should return 'success' before unrolling
> everything.
> 
> Fixes: aa9aa1ec2df6 ("ARM: davinci: PM: rework init, remove platform device")
> Signed-off-by: Christophe JAILLET 
> ---
> This patch is just a *guess*. The end of the function looks more like a
> error handling code rather than a normal path.
> ---
>  arch/arm/mach-davinci/pm.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/mach-davinci/pm.c b/arch/arm/mach-davinci/pm.c
> index d282b0783ecf..163d865abbf9 100644
> --- a/arch/arm/mach-davinci/pm.c
> +++ b/arch/arm/mach-davinci/pm.c
> @@ -161,6 +161,7 @@ int __init davinci_pm_init(void)
>   davinci_cpu_suspend_sz);
>  
>   suspend_set_ops(&davinci_pm_ops);
> + return 0;
>  
>  no_sram_mem:
>   iounmap(pm_config.ddrpsc_reg_base);


looks like, but that would mean that is wrong also:

davinci_sram_suspend = sram_alloc(davinci_cpu_suspend_sz, NULL);
if (!davinci_sram_suspend) {
pr_err("PM: cannot allocate SRAM memory\n");
return -ENOMEM;
}

what means 1 iounmap missing.

re,
 wh

Re: [PATCH 2/8] gpio: exar: Fix passing in of parent PCI device

[Andy Shevchenko]

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
> This fixes reloading of the driver for the same device: First of all,
> the driver sets drvdata to its own value during probing and does not
> restore the original value on exit. But this won't help anyway as the
> core clears drvdata after the driver left.
>
> Use stable platform_data instead.

>From the above I didn't clearly get what device you are talking about.
GPIO?

Can you provide step by step what you did and what bug you got?

Regarding below it looks to me a bit hackish.

>  static int gpio_exar_probe(struct platform_device *pdev)
>  {
> -   struct pci_dev *pcidev = platform_get_drvdata(pdev);
> +   struct pci_dev *pcidev = *(struct pci_dev **)pdev->dev.platform_data;
> struct exar_gpio_chip *exar_gpio;
> void __iomem *p;
> int index, ret;
> diff --git a/drivers/tty/serial/8250/8250_exar.c 
> b/drivers/tty/serial/8250/8250_exar.c
> index b4fa585156c7..2d056d1eeca3 100644
> --- a/drivers/tty/serial/8250/8250_exar.c
> +++ b/drivers/tty/serial/8250/8250_exar.c
> @@ -196,8 +196,12 @@ xr17v35x_register_gpio(struct pci_dev *pcidev)
> if (!pdev)
> return NULL;
>
> -   platform_set_drvdata(pdev, pcidev);
> -   if (platform_device_add(pdev) < 0) {
> +   /*
> +* platform_device_add_data kmemdups the data, therefore we can safely
> +* pass a stack reference.
> +*/
> +   if (platform_device_add_data(pdev, &pcidev, sizeof(pcidev)) < 0 ||
> +   platform_device_add(pdev) < 0) {
> platform_device_put(pdev);
> return NULL;

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 3/8] gpio: exar: Allocate resources on behalf of the platform device

[Andy Shevchenko]

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
> Do not allocate resources on behalf of the parent device but on our own.
> Otherwise, cleanup does not properly work if gpio-exar is removed but
> not the parent device.

This sounds to me like a good catch.
FWIW:
Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: Jan Kiszka 
> ---
>  drivers/gpio/gpio-exar.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
> index 0a2085faf271..9138ee087c5d 100644
> --- a/drivers/gpio/gpio-exar.c
> +++ b/drivers/gpio/gpio-exar.c
> @@ -139,7 +139,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
> if (!p)
> return -ENOMEM;
>
> -   exar_gpio = devm_kzalloc(&pcidev->dev, sizeof(*exar_gpio), 
> GFP_KERNEL);
> +   exar_gpio = devm_kzalloc(&pdev->dev, sizeof(*exar_gpio), GFP_KERNEL);
> if (!exar_gpio)
> return -ENOMEM;
>
> @@ -160,7 +160,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
> exar_gpio->regs = p;
> exar_gpio->index = index;
>
> -   ret = devm_gpiochip_add_data(&pcidev->dev,
> +   ret = devm_gpiochip_add_data(&pdev->dev,
>  &exar_gpio->gpio_chip, exar_gpio);
> if (ret)
> goto err_destroy;
> --
> 2.12.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 4/8] gpio: exar: Fix iomap request

[Andy Shevchenko]

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
> The UART driver already maps the resource for us. Trying to do this here
> only fails and leaves us with a non-working device.

I hoped this had been tested previously...
FWIW:
Reviewed-by: Andy Shevchenko 

>
> Signed-off-by: Jan Kiszka 
> ---
>  drivers/gpio/gpio-exar.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpio/gpio-exar.c b/drivers/gpio/gpio-exar.c
> index 9138ee087c5d..d6ffb3d89b9c 100644
> --- a/drivers/gpio/gpio-exar.c
> +++ b/drivers/gpio/gpio-exar.c
> @@ -128,14 +128,10 @@ static int gpio_exar_probe(struct platform_device *pdev)
> return -ENODEV;
>
> /*
> -* Map the pci device to get the register addresses.
> -* We will need to read and write those registers to control
> -* the GPIO pins.
> -* Using managed functions will save us from unmaping on exit.
> -* As the device is enabled using managed functions by the
> -* UART driver we can also use managed functions here.
> +* The UART driver must have mapped region 0 prior to registering this
> +* device - use it.
>  */
> -   p = pcim_iomap(pcidev, 0, 0);
> +   p = pcim_iomap_table(pcidev)[0];
> if (!p)
> return -ENOMEM;
>
> --
> 2.12.0
>



-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 5/8] gpio: exar: Fix reading of directions and values

[Andy Shevchenko]

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
> First, the logic for translating a register bit to the return code of
> exar_get_direction and exar_get_value were wrong. And second, there was
> a flip regarding the register bank in exar_get_direction.

Again, I wish it was tested in the first place.

After addressing below:
FWIW:
Reviewed-by: Andy Shevchenko 

> @@ -68,7 +68,7 @@ static int exar_get(struct gpio_chip *chip, unsigned int 
> reg)
> value = readb(exar_gpio->regs + reg);
> mutex_unlock(&exar_gpio->lock);
>
> -   return !!value;
> +   return value;

This one is correct.

> @@ -80,7 +80,7 @@ static int exar_get_direction(struct gpio_chip *chip, 
> unsigned int offset)
> addr = bank ? EXAR_OFFSET_MPIOSEL_HI : EXAR_OFFSET_MPIOSEL_LO;
> val = exar_get(chip, addr) >> (offset % 8);
>
> -   return !!val;
> +   return val & 1;

It should be rather

val = exar_get(chip, addr) & BIT(offset % 8);

>  }
>
>  static int exar_get_value(struct gpio_chip *chip, unsigned int offset)
> @@ -89,10 +89,10 @@ static int exar_get_value(struct gpio_chip *chip, 
> unsigned int offset)
> unsigned int addr;
> int val;
>
> -   addr = bank ? EXAR_OFFSET_MPIOLVL_LO : EXAR_OFFSET_MPIOLVL_HI;
> +   addr = bank ? EXAR_OFFSET_MPIOLVL_HI : EXAR_OFFSET_MPIOLVL_LO;

Good catch!

> val = exar_get(chip, addr) >> (offset % 8);
>
> -   return !!val;
> +   return val & 1;

Ditto (see above).

-- 
With Best Regards,
Andy Shevchenko

Re: [RFC][PATCH 0/5] perf/tracing/cpuhotplug: Fix locking order

[Paul E. McKenney]

On Fri, May 12, 2017 at 05:34:48PM -0400, Steven Rostedt wrote:
> On Fri, 12 May 2017 21:49:56 +0200

[ . . . ]

> This means that text_mutex, which was taken by the alternative code, no
> longer is taken in cpu hotplug code. That means there's no longer a
> deadlock scenario, as we don't have anyplace(*) that grabs
> get_online_cpus() and takes the text_mutex. Removing that will
> simplify things tremendously!
> 
> (*) with one exception: perf.
> 
> Currently perf does a get_online_cpu() at a high level. Will it be
> possible to move that down, such that we don't have it taken when we do
> any software events?

Can perf get rid of get_online_cpus(), perhaps using the mutexes acquired
by perf_event_init_cpu() or by perf_event_exit_cpu()?

Thanx, Paul

Re: [git pull] uaccess-related bits of vfs.git

[Brian Gerst]

On Sat, May 13, 2017 at 8:05 AM, Adam Borowski  wrote:
> On Sat, May 13, 2017 at 07:57:45AM +0100, Al Viro wrote:
>> On Fri, May 12, 2017 at 06:00:44PM -0700, Linus Torvalds wrote:
>> > But the *first* thing I'd like to do would be to just get rid of
>> > __get_user/__put_user as a thing. It really does generate nasty code,
>> > and we might as well just make it do that function call.
>>
>> But IMO the first step is not to convert __get_user()/__put_user() to
>> aliases of get_user()/put_user() - it's to get rid of their infestations
>> outside of arch/*.  They are concentrated in relatively few places, so
>> we can deal with those individually and then just fucking ban their use
>> outside of arch/*.  That's easy enough to watch for - simple git grep will 
>> do,
>> so anything creeping back will be immediately spotted.
>
> As someone from the peanuts gallery, I took a look for __put_user() in my
> usual haunt, drivers/tty/vt/
>
> * use 1: con_[gs]et_trans_*():
>   Copies a linear array of 256 bytes/shorts, one by one.
>   The obvious patch has 9 insertions(+), 22 deletions(-).
>
> * use 2: con_[gs]et_unimap():
>   Ditto, up to 65535*2 shorts, also in a nice linear array.
>
> * use 3: tioclinux():
>   Does a __put into a place that was checked only for read.  This got me
>   frightened as it initially looked like something that can allow an user to
>   write where they shouldn't.  Fortunately, it turns out the first argument
>   to access_ok() is ignored on every single architecture -- why does it even
>   exist then?  I imagined it's there for some odd arch that allows writes
>   when in privileged mode, but unlike what the docs say, VERIFY_WRITE is
>   exactly same as VERIFY_READ.

The original i386 (no longer supported) ignored the write-protect bit
when in supervisor mode.

--
Brian Gerst

Re: [PATCH 7/8] gpio-exar/8250-exar: Make set of exported GPIOs configurable

[Andy Shevchenko]

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
> On the SIMATIC, IOT2040 only a single pin is exportable as GPIO, the
> rest is required to operate the UART. To allow modeling this case,
> use device properties to specify a (consecutive) pin subset for
> exporting by the gpio-exar driver.

> @@ -123,6 +132,7 @@ static int gpio_exar_probe(struct platform_device *pdev)
> struct exar_gpio_chip *exar_gpio;
> void __iomem *p;
> int index, ret;
> +   u32 val;
>
> if (pcidev->vendor != PCI_VENDOR_ID_EXAR)
> return -ENODEV;
> @@ -152,9 +162,12 @@ static int gpio_exar_probe(struct platform_device *pdev)
> exar_gpio->gpio_chip.get = exar_get_value;
> exar_gpio->gpio_chip.set = exar_set_value;
> exar_gpio->gpio_chip.base = -1;
> -   exar_gpio->gpio_chip.ngpio = 16;

> +   device_property_read_u32(&pdev->dev, "ngpio", &val);
> +   exar_gpio->gpio_chip.ngpio = val;

You have to check return code, otherwise you might end up with
uninitialized data.

> exar_gpio->regs = p;
> exar_gpio->index = index;
> +   device_property_read_u32(&pdev->dev, "first_gpio", &val);
> +   exar_gpio->first_gpio = val;

Ditto.

>  #include 
>  #include 
>  #include 

> +#include 

Alphabetical order, please.

>  static void *
> -xr17v35x_register_gpio(struct pci_dev *pcidev)
> +xr17v35x_register_gpio(struct pci_dev *pcidev, unsigned int first_gpio,
> +  unsigned int ngpio)
>  {
> +   struct property_entry properties[] = {

> +   PROPERTY_ENTRY_U32("first_gpio", first_gpio),

This should be documented in device tree bindings, otherwise it's a
linux software hook and I'm not sure it's the best what we can do
here.

> +   PROPERTY_ENTRY_U32("ngpio", ngpio),

This should be a registered property name (I see "ngpios" in the bindings).

> +   { }
> +   };
> struct platform_device *pdev;
>
> pdev = platform_device_alloc("gpio_exar", PLATFORM_DEVID_AUTO);


> /*
> -* platform_device_add_data kmemdups the data, therefore we can safely
> -* pass a stack reference.
> +* platform_device_add_data and platform_device_add_properties copy
> +* the data, therefore we can safely pass a stack references.
>  */

Can you formulate this in an order to reduce ping-ponging lines across
the series?

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 8/8] serial: exar: Add support for IOT2040 device

[Andy Shevchenko]

On Sat, May 13, 2017 at 10:29 AM, Jan Kiszka  wrote:
> This implements the setup of RS232 and the switch-over to RS485 or RS422
> for the Siemens IOT2040. That uses an EXAR XR17V352 with external logic
> to switch between the different modes. The external logic is controlled
> via MPIO pins of the EXAR controller.
>
> Only pin 10 can be exported as GPIO on the IOT2040. It is connected to
> an LED.
>
> As the XR17V352 used on the IOT2040 is not equipped with an external
> EEPROM, it cannot present itself as IOT2040-variant via subvendor/
> subdevice IDs. Thus, we have to check via DMI for the target platform.
>
> Co-developed with Sascha Weisenberger.
>

Please, refactor that using properly formed DMI structrure and use its
callback and driver data facilities/

stmmac's pattern that you obviously applied does not actually suit here.

-- 
With Best Regards,
Andy Shevchenko

[PATCH v2 00/18] ARM64: meson: DT cleanups

[Andreas Färber]

Hello Kevin,

This series fixes several cosmetic issues, on top of your for-next branch.

Patches 3-6 rename a node, the rest should all be non-functional changes.

PLEASE STOP merging random new nodes at the bottom of DT files!
Just like it's a convention to sort new nodes by unit address, it has been
a convention to sort by-label nodes by their label. As discussed here and
elsewhere, this helps avoid merge conflicts and makes nodes easy to find.
I don't care whether we order A0 before A or after, but adding new HDMI
or CVBS nodes at the very bottom is totally out of alphabetical order.
Since my v1 you really should've known that...

Similarly, Khadas Vim shouldn't have been merged with the "bcrmf" typo.

Which proves my point that we need to fix these issues now so that they
don't keep spreading (Broken Window Theory). New boards have not been
checked for sort order, only boards already touched in v1.

Board and Makefile order affect my pending R-Box Pro patches.
Node order affects Martin's pending Bluetooth patches among others.

Patches 7-9 (had and) have no dependency, please start applying.

Thanks,
Andreas

v1 -> v2:
* Rebased (new nodes/properties added)
* Chose a different name for the misnamed Wifi nodes (Rob)
* Added patch to fix another new misnamed Wifi node
* Dropped patch fixing a trailing white line error (resolved)
* Tweaked subjects

Cc: Kevin Hilman 
Cc: devicet...@vger.kernel.org
Cc: Rob Herring 
Cc: Neil Armstrong 
Cc: Martin Blumenstingl 

Andreas Färber (18):
  dt-bindings: arm: amlogic: Reorder boards
  arm64: dts: amlogic: Sort Makefile
  arm64: dts: meson-gxbb-vega-s95: Fix Wifi node name
  arm64: dts: meson-gxbb-p20x: Fix Wifi node name
  arm64: dts: meson-gx-p23x-q20x: Fix Wifi node name
  arm64: dts: meson-gxl-s905x-khadas-vim: Fix Wifi node name
  arm64: dts: meson-gxm-nexbox-a1: Drop UART comment
  arm64: dts: meson-gxl-s905x: Comment typo fix
  arm64: dts: meson-gxbb-wetek-hub: Reference CVBS node by label
  arm64: dts: meson-gxbb: Fix node order
  arm64: dts: meson-gxbb-odroidc2: Fix node order
  arm64: dts: meson-gxbb-vega-s95: Fix node order
  arm64: dts: meson-gxbb-nexbox-a95x: Fix node order
  arm64: dts: meson-gxbb-p20x: Fix node order
  arm64: dts: meson-gxl: Fix node order
  arm64: dts: meson-gxl-s905x-nexbox-a95x: Fix node order
  arm64: dts: meson-gxm-nexbox-a1: Fix node order
  arm64: dts: meson-gx-p23x-q20x: Fix node order

 Documentation/devicetree/bindings/arm/amlogic.txt  |  20 ++-
 arch/arm64/boot/dts/amlogic/Makefile   |   6 +-
 .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi |  60 
 .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts|  52 +++
 .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 108 ++---
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi   |  66 
 .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi  |  56 +++
 .../boot/dts/amlogic/meson-gxbb-wetek-hub.dts  |   6 +-
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi| 171 +++--
 .../dts/amlogic/meson-gxl-s905x-khadas-vim.dts |   2 +-
 .../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts|  52 +++
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi   |   2 +-
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi |  72 -
 .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts |  87 ++-
 14 files changed, 388 insertions(+), 372 deletions(-)

-- 
2.12.0

[PATCH v2 17/18] arm64: dts: meson-gxm-nexbox-a1: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 .../arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 86 +++---
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 920fac10de93..5f626d683088 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -113,10 +113,49 @@
};
 };
 
-&uart_AO {
+&cvbs_vdac_port {
+   cvbs_vdac_out: endpoint {
+   remote-endpoint = <&cvbs_connector_in>;
+   };
+};
+
+ðmac {
status = "okay";
-   pinctrl-0 = <&uart_ao_a_pins>;
+
+   pinctrl-0 = <ð_pins>;
pinctrl-names = "default";
+
+   /* Select external PHY by default */
+   phy-handle = <&external_phy>;
+
+   amlogic,tx-delay-ns = <2>;
+
+   snps,reset-gpio = <&gpio GPIOZ_14 0>;
+   snps,reset-delays-us = <0 1 100>;
+   snps,reset-active-low;
+
+   /* External PHY is in RGMII */
+   phy-mode = "rgmii";
+};
+
+&external_mdio {
+   external_phy: ethernet-phy@0 {
+   compatible = "ethernet-phy-id001c.c916", 
"ethernet-phy-ieee802.3-c22";
+   reg = <0>;
+   max-speed = <1000>;
+   };
+};
+
+&hdmi_tx {
+   status = "okay";
+   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
+   pinctrl-names = "default";
+};
+
+&hdmi_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <&hdmi_connector_in>;
+   };
 };
 
 &ir {
@@ -163,47 +202,8 @@
vqmmc-supply = <&vddio_boot>;
 };
 
-ðmac {
-   status = "okay";
-
-   pinctrl-0 = <ð_pins>;
-   pinctrl-names = "default";
-
-   /* Select external PHY by default */
-   phy-handle = <&external_phy>;
-
-   amlogic,tx-delay-ns = <2>;
-
-   snps,reset-gpio = <&gpio GPIOZ_14 0>;
-   snps,reset-delays-us = <0 1 100>;
-   snps,reset-active-low;
-
-   /* External PHY is in RGMII */
-   phy-mode = "rgmii";
-};
-
-&external_mdio {
-   external_phy: ethernet-phy@0 {
-   compatible = "ethernet-phy-id001c.c916", 
"ethernet-phy-ieee802.3-c22";
-   reg = <0>;
-   max-speed = <1000>;
-   };
-};
-
-&cvbs_vdac_port {
-   cvbs_vdac_out: endpoint {
-   remote-endpoint = <&cvbs_connector_in>;
-   };
-};
-
-&hdmi_tx {
+&uart_AO {
status = "okay";
-   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
+   pinctrl-0 = <&uart_ao_a_pins>;
pinctrl-names = "default";
 };
-
-&hdmi_tx_tmds_port {
-   hdmi_tx_tmds_out: endpoint {
-   remote-endpoint = <&hdmi_connector_in>;
-   };
-};
-- 
2.12.0

Re: Threads stuck in zap_pid_ns_processes()

[Guenter Roeck]

On 05/12/2017 01:03 PM, Eric W. Biederman wrote:

Guenter Roeck  writes:


Hi Eric,

On Fri, May 12, 2017 at 12:33:01PM -0500, Eric W. Biederman wrote:

Guenter Roeck  writes:


Hi Eric,

On Fri, May 12, 2017 at 08:26:27AM -0500, Eric W. Biederman wrote:

Vovo Yang  writes:


On Fri, May 12, 2017 at 7:19 AM, Eric W. Biederman
 wrote:

Guenter Roeck  writes:


What I know so far is
- We see this condition on a regular basis in the field. Regular is
  relative, of course - let's say maybe 1 in a Milion Chromebooks
  per day reports a crash because of it. That is not that many,
  but it adds up.
- We are able to reproduce the problem with a performance benchmark
  which opens 100 chrome tabs. While that is a lot, it should not
  result in a kernel hang/crash.
- Vovo proviced the test code last night. I don't know if this is
  exactly what is observed in the benchmark, or how it relates to the
  benchmark in the first place, but it is the first time we are actually
  able to reliably create a condition where the problem is seen.


Thank you.  I will be interesting to hear what is happening in the
chrome perfomance benchmark that triggers this.


What's happening in the benchmark:
1. A chrome renderer process was created with CLONE_NEWPID
2. The process crashed
3. Chrome breakpad service calls ptrace(PTRACE_ATTACH, ..) to attach to every
  threads of the crashed process to dump info
4. When breakpad detach the crashed process, the crashed process stuck in
  zap_pid_ns_processes()


Very interesting thank you.

So the question is specifically which interaction is causing this.

In the test case provided it was a sibling task in the pid namespace
dying and not being reaped.  Which may be what is happening with
breakpad.  So far I have yet to see kernel bug but I won't rule one out.



I am trying to understand what you are looking for. I would have thought
that both the test application as well as the Chrome functionality
described above show that there are situations where zap_pid_ns_processes()
can get stuck and cause hung task timeouts in conjunction with the use of
ptrace().

Your last sentence seems to suggest that you believe that the kernel might
do what it is expected to do. Assuming this is the case, what else would
you like to see ? A test application which matches exactly the Chrome use
case ? We can try to provide that, but I don't entirely understand how
that would change the situation. After all, we already know that it is
possible to get a thread into this condition, and we already have one
means to reproduce it.

Replacing TASK_UNINTERRUPTIBLE with TASK_INTERRUPTABLE works for both the
test application and the Chrome benchmark. The thread is still stuck in
zap_pid_ns_processes(), but it is now in S (sleep) state instead of D,
and no longer results in a hung task timeout. It remains in that state
until the parent process terminates. I am not entirely happy with it
since the processes are still stuck and may pile up over time, but at
least it solves the immediate problem for us.

Question now is what to do with that solution. We can of course apply
it locally to Chrome OS, but I would rather have it upstream - especially
since we have to assume that any users of Chrome on Linux, or more
generically anyone using ptrace in conjunction with CLONE_NEWPID, may
experience the same problem. Right now I have no idea how to get there,
though. Can you provide some guidance ?


Apologies for not being clear.  I intend to send a pull request with the


No worries.


the TASK_UINTERRUPTIBLE to TASK_INTERRUPTIBLE change to Linus in the
next week or so with a Cc stable and an appropriate Fixes tag.  So the
fix can be backported.


Great, that is good to know.


I have a more comprehensive change queued I will probably merge for 4.13
already but it just changes what kind of zombies you see.  It won't
remove the ``stuck'' zombies.

So what I am looking for now is:
Why are things getting stuck in your benchmark?

-  Is it a userspace bug?

  In which case we can figure out what userspace (aka breakpad) needs
   to do to avoid the problem.


I spent some time trying to understand what breakpad is doing. I don't
really see how it can be blamed. It attaches itself to a crashing thread,
gets the information it is looking for, and detaches itself. At the
same time, whatever it does, it seems to me that userspace should not
be able to create such a situation in the first place.


I suspect what is happening is that the thread breakpad is attached to
is killed by zap_pid_ns_processes.  At which point PTRACE_DETACH won't
work because the thread has been killed and waitpid(thread_pid,...)
needs to be used instead.



I think you nailed it. If I drop CLONE_NEWPID from the reproducer I get
a zombie process.

I guess the only question left is if zap_pid_ns_processes() should (or could)
somehow detect that situation and return instead of waiting forever.
What do you think ?

Thanks,
Guenter

[PATCH v2 03/18] arm64: dts: meson-gxbb-vega-s95: Fix Wifi node name

[Andreas Färber]

bcrmf -> brcmf -> wifi

Fixes: ab5b24fdd2d5 ("ARM64: dts: meson-gxbb-vega-s95: Add SD/SDIO/MMC and PWM 
nodes")
Cc: Martin Blumenstingl 
Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Renamed node brmcf -> wifi (Rob)
 
 arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index aefa66dff72d..f4bfee8e2e08 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -186,7 +186,7 @@
vmmc-supply = <&vcc_3v3>;
vqmmc-supply = <&vcc_1v8>;
 
-   brcmf: bcrmf@1 {
+   brcmf: wifi@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
};
-- 
2.12.0

[PATCH v2 04/18] arm64: dts: meson-gxbb-p20x: Fix Wifi node name

[Andreas Färber]

bcrmf -> brcmf -> wifi

Fixes: ab3943fe57a2 ("ARM64: dts: meson-gxbb: Add P20x Wifi SDIO support")
Cc: Neil Armstrong 
Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Renamed node brmcf -> wifi (Rob)
 
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 3c6c0b7f4187..a5be438a5c03 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -198,7 +198,7 @@
vmmc-supply = <&vddao_3v3>;
vqmmc-supply = <&vddio_boot>;
 
-   brcmf: bcrmf@1 {
+   brcmf: wifi@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
};
-- 
2.12.0

[PATCH v2 05/18] arm64: dts: meson-gx-p23x-q20x: Fix Wifi node name

[Andreas Färber]

bcrmf -> brcmf -> wifi

Fixes: bb51b5350d2f ("ARM64: dts: Add support for Meson GXM")
Cc: Neil Armstrong 
Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Renamed node brmcf -> wifi (Rob)
 
 arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index a84e27622639..25eed18a7439 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -154,7 +154,7 @@
vmmc-supply = <&vddao_3v3>;
vqmmc-supply = <&vddio_boot>;
 
-   brcmf: bcrmf@1 {
+   brcmf: wifi@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
};
-- 
2.12.0

[PATCH v2 13/18] arm64: dts: meson-gxbb-nexbox-a95x: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 .../boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts| 52 +++---
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
index 87198eafb04b..a1078b3e1c76 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-nexbox-a95x.dts
@@ -165,10 +165,10 @@
};
 };
 
-&uart_AO {
-   status = "okay";
-   pinctrl-0 = <&uart_ao_a_pins>;
-   pinctrl-names = "default";
+&cvbs_vdac_port {
+   cvbs_vdac_out: endpoint {
+   remote-endpoint = <&cvbs_connector_in>;
+   };
 };
 
 ðmac {
@@ -195,12 +195,32 @@
};
 };
 
+&hdmi_tx {
+   status = "okay";
+   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
+   pinctrl-names = "default";
+};
+
+&hdmi_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <&hdmi_connector_in>;
+   };
+};
+
 &ir {
status = "okay";
pinctrl-0 = <&remote_input_ao_pins>;
pinctrl-names = "default";
 };
 
+&pwm_ef {
+   status = "okay";
+   pinctrl-0 = <&pwm_e_pins>;
+   pinctrl-names = "default";
+   clocks = <&clkc CLKID_FCLK_DIV4>;
+   clock-names = "clkin0";
+};
+
 /* Wireless SDIO Module */
 &sd_emmc_a {
status = "okay";
@@ -260,28 +280,8 @@
vqmmc-supply = <&vddio_boot>;
 };
 
-&pwm_ef {
-   status = "okay";
-   pinctrl-0 = <&pwm_e_pins>;
-   pinctrl-names = "default";
-   clocks = <&clkc CLKID_FCLK_DIV4>;
-   clock-names = "clkin0";
-};
-
-&cvbs_vdac_port {
-   cvbs_vdac_out: endpoint {
-   remote-endpoint = <&cvbs_connector_in>;
-   };
-};
-
-&hdmi_tx {
+&uart_AO {
status = "okay";
-   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
+   pinctrl-0 = <&uart_ao_a_pins>;
pinctrl-names = "default";
 };
-
-&hdmi_tx_tmds_port {
-   hdmi_tx_tmds_out: endpoint {
-   remote-endpoint = <&hdmi_connector_in>;
-   };
-};
-- 
2.12.0

[PATCH v2 18/18] arm64: dts: meson-gx-p23x-q20x: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 58 +++---
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
index 25eed18a7439..dc478d094c11 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi
@@ -121,19 +121,42 @@
};
 };
 
-/* This UART is brought out to the DB9 connector */
-&uart_AO {
+&cvbs_vdac_port {
+   cvbs_vdac_out: endpoint {
+   remote-endpoint = <&cvbs_connector_in>;
+   };
+};
+
+ðmac {
status = "okay";
-   pinctrl-0 = <&uart_ao_a_pins>;
+};
+
+&hdmi_tx {
+   status = "okay";
+   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
pinctrl-names = "default";
 };
 
+&hdmi_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <&hdmi_connector_in>;
+   };
+};
+
 &ir {
status = "okay";
pinctrl-0 = <&remote_input_ao_pins>;
pinctrl-names = "default";
 };
 
+&pwm_ef {
+   status = "okay";
+   pinctrl-0 = <&pwm_e_pins>;
+   pinctrl-names = "default";
+   clocks = <&clkc CLKID_FCLK_DIV4>;
+   clock-names = "clkin0";
+};
+
 /* Wireless SDIO Module */
 &sd_emmc_a {
status = "okay";
@@ -198,32 +221,9 @@
vqmmc-supply = <&vddio_boot>;
 };
 
-&pwm_ef {
-   status = "okay";
-   pinctrl-0 = <&pwm_e_pins>;
-   pinctrl-names = "default";
-   clocks = <&clkc CLKID_FCLK_DIV4>;
-   clock-names = "clkin0";
-};
-
-ðmac {
-   status = "okay";
-};
-
-&cvbs_vdac_port {
-   cvbs_vdac_out: endpoint {
-   remote-endpoint = <&cvbs_connector_in>;
-   };
-};
-
-&hdmi_tx {
+/* This UART is brought out to the DB9 connector */
+&uart_AO {
status = "okay";
-   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
+   pinctrl-0 = <&uart_ao_a_pins>;
pinctrl-names = "default";
 };
-
-&hdmi_tx_tmds_port {
-   hdmi_tx_tmds_out: endpoint {
-   remote-endpoint = <&hdmi_connector_in>;
-   };
-};
-- 
2.12.0

[PATCH v2 02/18] arm64: dts: amlogic: Sort Makefile

[Andreas Färber]

Sort the .dtb files alphabetically to make clear where to add new ones.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new boards added)
 * Extended commit message
 
 arch/arm64/boot/dts/amlogic/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/Makefile 
b/arch/arm64/boot/dts/amlogic/Makefile
index b9ad2db7398b..14fa27ccd589 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -7,15 +7,15 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-meta.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-vega-s95-telos.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-wetek-hub.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxbb-wetek-play2.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-hwacom-amazetv.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-khadas-vim.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-nexbox-a95x.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-p212.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p230.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905d-p231.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-hwacom-amazetv.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxl-s905x-nexbox-a95x.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
 dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
-dtb-$(CONFIG_ARCH_MESON) += meson-gxm-nexbox-a1.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
-- 
2.12.0

[PATCH v2 16/18] arm64: dts: meson-gxl-s905x-nexbox-a95x: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 .../dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts| 52 +++---
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
index 8873c058fad2..6633a5d8fdd3 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-nexbox-a95x.dts
@@ -140,10 +140,10 @@
};
 };
 
-&uart_AO {
-   status = "okay";
-   pinctrl-0 = <&uart_ao_a_pins>;
-   pinctrl-names = "default";
+&cvbs_vdac_port {
+   cvbs_vdac_out: endpoint {
+   remote-endpoint = <&cvbs_connector_in>;
+   };
 };
 
 ðmac {
@@ -152,12 +152,32 @@
phy-handle = <&internal_phy>;
 };
 
+&hdmi_tx {
+   status = "okay";
+   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
+   pinctrl-names = "default";
+};
+
+&hdmi_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <&hdmi_connector_in>;
+   };
+};
+
 &ir {
status = "okay";
pinctrl-0 = <&remote_input_ao_pins>;
pinctrl-names = "default";
 };
 
+&pwm_ef {
+   status = "okay";
+   pinctrl-0 = <&pwm_e_pins>;
+   pinctrl-names = "default";
+   clocks = <&clkc CLKID_FCLK_DIV4>;
+   clock-names = "clkin0";
+};
+
 /* Wireless SDIO Module */
 &sd_emmc_a {
status = "okay";
@@ -217,28 +237,8 @@
vqmmc-supply = <&vddio_boot>;
 };
 
-&pwm_ef {
-   status = "okay";
-   pinctrl-0 = <&pwm_e_pins>;
-   pinctrl-names = "default";
-   clocks = <&clkc CLKID_FCLK_DIV4>;
-   clock-names = "clkin0";
-};
-
-&cvbs_vdac_port {
-   cvbs_vdac_out: endpoint {
-   remote-endpoint = <&cvbs_connector_in>;
-   };
-};
-
-&hdmi_tx {
+&uart_AO {
status = "okay";
-   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
+   pinctrl-0 = <&uart_ao_a_pins>;
pinctrl-names = "default";
 };
-
-&hdmi_tx_tmds_port {
-   hdmi_tx_tmds_out: endpoint {
-   remote-endpoint = <&hdmi_connector_in>;
-   };
-};
-- 
2.12.0

[PATCH v2 14/18] arm64: dts: meson-gxbb-p20x: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 62 
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index 0ec1d19522dd..d904deb1018c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -148,34 +148,36 @@
};
 };
 
-/* This UART is brought out to the DB9 connector */
-&uart_AO {
-   status = "okay";
-   pinctrl-0 = <&uart_ao_a_pins>;
-   pinctrl-names = "default";
+&cvbs_vdac_port {
+   cvbs_vdac_out: endpoint {
+   remote-endpoint = <&cvbs_connector_in>;
+   };
 };
 
-&ir {
+&hdmi_tx {
status = "okay";
-   pinctrl-0 = <&remote_input_ao_pins>;
+   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
pinctrl-names = "default";
 };
 
-&usb0_phy {
-   status = "okay";
-   phy-supply = <&usb_pwr>;
-};
-
-&usb1_phy {
-   status = "okay";
+&hdmi_tx_tmds_port {
+   hdmi_tx_tmds_out: endpoint {
+   remote-endpoint = <&hdmi_connector_in>;
+   };
 };
 
-&usb0 {
+&ir {
status = "okay";
+   pinctrl-0 = <&remote_input_ao_pins>;
+   pinctrl-names = "default";
 };
 
-&usb1 {
+&pwm_ef {
status = "okay";
+   pinctrl-0 = <&pwm_e_pins>;
+   pinctrl-names = "default";
+   clocks = <&clkc CLKID_FCLK_DIV4>;
+   clock-names = "clkin0";
 };
 
 /* Wireless SDIO Module */
@@ -242,28 +244,26 @@
vqmmc-supply = <&vddio_boot>;
 };
 
-&pwm_ef {
+/* This UART is brought out to the DB9 connector */
+&uart_AO {
status = "okay";
-   pinctrl-0 = <&pwm_e_pins>;
+   pinctrl-0 = <&uart_ao_a_pins>;
pinctrl-names = "default";
-   clocks = <&clkc CLKID_FCLK_DIV4>;
-   clock-names = "clkin0";
 };
 
-&cvbs_vdac_port {
-   cvbs_vdac_out: endpoint {
-   remote-endpoint = <&cvbs_connector_in>;
-   };
+&usb0_phy {
+   status = "okay";
+   phy-supply = <&usb_pwr>;
 };
 
-&hdmi_tx {
+&usb1_phy {
status = "okay";
-   pinctrl-0 = <&hdmi_hpd_pins>, <&hdmi_i2c_pins>;
-   pinctrl-names = "default";
 };
 
-&hdmi_tx_tmds_port {
-   hdmi_tx_tmds_out: endpoint {
-   remote-endpoint = <&hdmi_connector_in>;
-   };
+&usb0 {
+   status = "okay";
+};
+
+&usb1 {
+   status = "okay";
 };
-- 
2.12.0

[PATCH v2 06/18] arm64: dts: meson-gxl-s905x-khadas-vim: Fix Wifi node name

[Andreas Färber]

bcrmf -> brcmf -> wifi

Fixes: e15d2774b8c0 ("ARM64: dts: meson-gxl: add support for the Khadas VIM 
board")
Cc: Martin Blumenstingl 
Signed-off-by: Andreas Färber 
---
 v2: New
 
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
index 3c8b0b51ef27..6a81f0168da5 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-khadas-vim.dts
@@ -95,7 +95,7 @@
 };
 
 &sd_emmc_a {
-   brcmf: bcrmf@1 {
+   brcmf: wifi@1 {
reg = <1>;
compatible = "brcm,bcm4329-fmac";
};
-- 
2.12.0

[PATCH v2 15/18] arm64: dts: meson-gxl: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 72 +++---
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index d8e096dff10a..3efad5f0bca4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
@@ -193,6 +193,42 @@
};
 };
 
+&hdmi_tx {
+   compatible = "amlogic,meson-gxl-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
+   resets = <&reset RESET_HDMITX_CAPB3>,
+<&reset RESET_HDMI_SYSTEM_RESET>,
+<&reset RESET_HDMI_TX>;
+   reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
+   clocks = <&clkc CLKID_HDMI_PCLK>,
+<&clkc CLKID_CLK81>,
+<&clkc CLKID_GCLK_VENCI_INT0>;
+   clock-names = "isfr", "iahb", "venci";
+};
+
+&hiubus {
+   clkc: clock-controller@0 {
+   compatible = "amlogic,gxl-clkc", "amlogic,gxbb-clkc";
+   #clock-cells = <1>;
+   reg = <0x0 0x0 0x0 0x3db>;
+   };
+};
+
+&i2c_A {
+   clocks = <&clkc CLKID_I2C>;
+};
+
+&i2c_AO {
+   clocks = <&clkc CLKID_AO_I2C>;
+};
+
+&i2c_B {
+   clocks = <&clkc CLKID_I2C>;
+};
+
+&i2c_C {
+   clocks = <&clkc CLKID_I2C>;
+};
+
 &periphs {
pinctrl_periphs: pinctrl@4b0 {
compatible = "amlogic,meson-gxl-periphs-pinctrl";
@@ -501,30 +537,6 @@
};
 };
 
-&hiubus {
-   clkc: clock-controller@0 {
-   compatible = "amlogic,gxl-clkc", "amlogic,gxbb-clkc";
-   #clock-cells = <1>;
-   reg = <0x0 0x0 0x0 0x3db>;
-   };
-};
-
-&i2c_A {
-   clocks = <&clkc CLKID_I2C>;
-};
-
-&i2c_AO {
-   clocks = <&clkc CLKID_AO_I2C>;
-};
-
-&i2c_B {
-   clocks = <&clkc CLKID_I2C>;
-};
-
-&i2c_C {
-   clocks = <&clkc CLKID_I2C>;
-};
-
 &saradc {
compatible = "amlogic,meson-gxl-saradc", "amlogic,meson-saradc";
clocks = <&xtal>,
@@ -563,15 +575,3 @@
 &vpu {
compatible = "amlogic,meson-gxl-vpu", "amlogic,meson-gx-vpu";
 };
-
-&hdmi_tx {
-   compatible = "amlogic,meson-gxl-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
-   resets = <&reset RESET_HDMITX_CAPB3>,
-<&reset RESET_HDMI_SYSTEM_RESET>,
-<&reset RESET_HDMI_TX>;
-   reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
-   clocks = <&clkc CLKID_HDMI_PCLK>,
-<&clkc CLKID_CLK81>,
-<&clkc CLKID_GCLK_VENCI_INT0>;
-   clock-names = "isfr", "iahb", "venci";
-};
-- 
2.12.0

[PATCH v2 10/18] arm64: dts: meson-gxbb: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 171 +++-
 1 file changed, 91 insertions(+), 80 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 4afe1c46ec11..92dd5d1d73c8 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -97,13 +97,6 @@
};
 };
 
-ðmac {
-   clocks = <&clkc CLKID_ETH>,
-<&clkc CLKID_FCLK_DIV2>,
-<&clkc CLKID_MPLL2>;
-   clock-names = "stmmaceth", "clkin0", "clkin1";
-};
-
 &aobus {
pinctrl_aobus: pinctrl@14 {
compatible = "amlogic,meson-gxbb-aobus-pinctrl";
@@ -252,6 +245,97 @@
};
 };
 
+&apb {
+   mali: gpu@c {
+   compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
+   reg = <0x0 0xc 0x0 0x4>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   interrupt-names = "gp", "gpmmu", "pp", "pmu",
+   "pp0", "ppmmu0", "pp1", "ppmmu1",
+   "pp2", "ppmmu2";
+   clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
+   clock-names = "bus", "core";
+
+   /*
+* Mali clocking is provided by two identical clock paths
+* MALI_0 and MALI_1 muxed to a single clock by a glitch
+* free mux to safely change frequency while running.
+*/
+   assigned-clocks = <&clkc CLKID_MALI_0_SEL>,
+ <&clkc CLKID_MALI_0>,
+ <&clkc CLKID_MALI>; /* Glitch free mux */
+   assigned-clock-parents = <&clkc CLKID_FCLK_DIV3>,
+<0>, /* Do Nothing */
+<&clkc CLKID_MALI_0>;
+   assigned-clock-rates = <0>, /* Do Nothing */
+  <6>,
+  <0>; /* Do Nothing */
+   };
+};
+
+&cbus {
+   spifc: spi@8c80 {
+   compatible = "amlogic,meson-gxbb-spifc";
+   reg = <0x0 0x08c80 0x0 0x80>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   clocks = <&clkc CLKID_SPI>;
+   status = "disabled";
+   };
+};
+
+ðmac {
+   clocks = <&clkc CLKID_ETH>,
+<&clkc CLKID_FCLK_DIV2>,
+<&clkc CLKID_MPLL2>;
+   clock-names = "stmmaceth", "clkin0", "clkin1";
+};
+
+&hdmi_tx {
+   compatible = "amlogic,meson-gxbb-dw-hdmi", "amlogic,meson-gx-dw-hdmi";
+   resets = <&reset RESET_HDMITX_CAPB3>,
+<&reset RESET_HDMI_SYSTEM_RESET>,
+<&reset RESET_HDMI_TX>;
+   reset-names = "hdmitx_apb", "hdmitx", "hdmitx_phy";
+   clocks = <&clkc CLKID_HDMI_PCLK>,
+<&clkc CLKID_CLK81>,
+<&clkc CLKID_GCLK_VENCI_INT0>;
+   clock-names = "isfr", "iahb", "venci";
+};
+
+&hiubus {
+   clkc: clock-controller@0 {
+   compatible = "amlogic,gxbb-clkc";
+   #clock-cells = <1>;
+   reg = <0x0 0x0 0x0 0x3db>;
+   };
+};
+
+&i2c_A {
+   clocks = <&clkc CLKID_I2C>;
+};
+
+&i2c_AO {
+   clocks = <&clkc CLKID_AO_I2C>;
+};
+
+&i2c_B {
+   clocks = <&clkc CLKID_I2C>;
+};
+
+&i2c_C {
+   clocks = <&clkc CLKID_I2C>;
+};
+
 &periphs {
pinctrl_periphs: pinctrl@4b0 {
compatible = "amlogic,meson-gxbb-periphs-pinctrl";
@@ -521,67 +605,6 @@
};
 };
 
-&hiubus {
-   clkc: clock-controller@0 {
-   compatible = "amlogic,gxbb-clkc";
-   #clock-cells = <1>;
-   reg = <0x0 0x0 0x0 0x3db>;
-   };
-};
-
-&apb {
-   mali: gpu@c {
-   compatible = "amlogic,meson-gxbb-mali", "arm,mali-450";
-   reg = <0x0 0xc 0x0 0x4>;
-   interrupts = ,
-,
-,
-,
-,
-,
-,
-,
-,
-;
-   interrupt-names = "gp", "gpmmu", "pp", "pmu",
-   "pp0", "ppmmu0", "pp1", "ppmmu1",
-   "pp2", "ppmmu2";
-   clocks = <&clkc CLKID_CLK81>, <&clkc CLKID_MALI>;
-   clock-names = "bus", "core";
-
-   /*
-* Mali clocking is provided by two identical clock paths
- 

[PATCH v2 11/18] arm64: dts: meson-gxbb-odroidc2: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 108 ++---
 1 file changed, 54 insertions(+), 54 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 54a9c6a6b392..d147c853ab05 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -137,16 +137,6 @@
};
 };
 
-&scpi_clocks {
-   status = "disabled";
-};
-
-&uart_AO {
-   status = "okay";
-   pinctrl-0 = <&uart_ao_a_pins>;
-   pinctrl-names = "default";
-};
-
 ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
@@ -172,6 +162,33 @@
};
 };
 
+&gpio_ao {
+   /*
+* WARNING: The USB Hub on the Odroid-C2 needs a reset signal
+* to be turned high in order to be detected by the USB Controller
+* This signal should be handled by a USB specific power sequence
+* in order to reset the Hub when USB bus is powered down.
+*/
+   usb-hub {
+   gpio-hog;
+   gpios = ;
+   output-high;
+   line-name = "usb-hub-reset";
+   };
+};
+
+&i2c_A {
+   status = "okay";
+   pinctrl-0 = <&i2c_a_pins>;
+   pinctrl-names = "default";
+};
+
+&ir {
+   status = "okay";
+   pinctrl-0 = <&remote_input_ao_pins>;
+   pinctrl-names = "default";
+};
+
 &pinctrl_aobus {
gpio-line-names = "UART TX", "UART RX", "VCCK En", "TF 3V3/1V8 En",
  "USB HUB nRESET", "USB OTG Power En",
@@ -223,55 +240,15 @@
  "";
 };
 
-&ir {
-   status = "okay";
-   pinctrl-0 = <&remote_input_ao_pins>;
-   pinctrl-names = "default";
-};
-
-&i2c_A {
-   status = "okay";
-   pinctrl-0 = <&i2c_a_pins>;
-   pinctrl-names = "default";
-};
-
-&gpio_ao {
-   /*
-* WARNING: The USB Hub on the Odroid-C2 needs a reset signal
-* to be turned high in order to be detected by the USB Controller
-* This signal should be handled by a USB specific power sequence
-* in order to reset the Hub when USB bus is powered down.
-*/
-   usb-hub {
-   gpio-hog;
-   gpios = ;
-   output-high;
-   line-name = "usb-hub-reset";
-   };
-};
-
-&usb0_phy {
-   status = "okay";
-   phy-supply = <&usb_otg_pwr>;
-};
-
-&usb1_phy {
-   status = "okay";
-};
-
-&usb0 {
-   status = "okay";
-};
-
-&usb1 {
-   status = "okay";
-};
-
 &saradc {
status = "okay";
vref-supply = <&vcc1v8>;
 };
 
+&scpi_clocks {
+   status = "disabled";
+};
+
 /* SD */
 &sd_emmc_b {
status = "okay";
@@ -309,3 +286,26 @@
vmmc-supply = <&vcc3v3>;
vqmmc-supply = <&vcc1v8>;
 };
+
+&uart_AO {
+   status = "okay";
+   pinctrl-0 = <&uart_ao_a_pins>;
+   pinctrl-names = "default";
+};
+
+&usb0_phy {
+   status = "okay";
+   phy-supply = <&usb_otg_pwr>;
+};
+
+&usb1_phy {
+   status = "okay";
+};
+
+&usb0 {
+   status = "okay";
+};
+
+&usb1 {
+   status = "okay";
+};
-- 
2.12.0

[PATCH v2 09/18] arm64: dts: meson-gxbb-wetek-hub: Reference CVBS node by label

[Andreas Färber]

Makes the override safer.

Acked-by: Neil Armstrong 
Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Extended commit message
 
 arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
index a5be438a5c03..0ec1d19522dd 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
@@ -126,7 +126,7 @@
clock-names = "ext_clock";
};
 
-   cvbs-connector {
+   cvbs_connector: cvbs-connector {
compatible = "composite-video-connector";
 
port {
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
index f057fb48fee5..1878ac2b2b83 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-wetek-hub.dts
@@ -59,10 +59,10 @@
panic-indicator;
};
};
+};
 
-   cvbs-connector {
-   status = "disabled";
-   };
+&cvbs_connector {
+   status = "disabled";
 };
 
 ðmac {
-- 
2.12.0

[PATCH v2 07/18] arm64: dts: meson-gxm-nexbox-a1: Drop UART comment

[Andreas Färber]

Product pictures show no DB9 connector, so this seems copy&paste.

Acked-by: Neil Armstrong 
Signed-off-by: Andreas Färber 
---
 v1 -> v2: Unchanged
 
 arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts 
b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
index 11b0bf46a95c..920fac10de93 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm-nexbox-a1.dts
@@ -113,7 +113,6 @@
};
 };
 
-/* This UART is brought out to the DB9 connector */
 &uart_AO {
status = "okay";
pinctrl-0 = <&uart_ao_a_pins>;
-- 
2.12.0

[PATCH v2 12/18] arm64: dts: meson-gxbb-vega-s95: Fix node order

[Andreas Färber]

Sort nodes referenced by label alphabetically.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new nodes added)
 
 .../boot/dts/amlogic/meson-gxbb-vega-s95.dtsi  | 54 +++---
 1 file changed, 27 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
index f4bfee8e2e08..346753fb6324 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-vega-s95.dtsi
@@ -111,18 +111,6 @@
};
 };
 
-&uart_AO {
-   status = "okay";
-   pinctrl-0 = <&uart_ao_a_pins>;
-   pinctrl-names = "default";
-};
-
-&ir {
-   status = "okay";
-   pinctrl-0 = <&remote_input_ao_pins>;
-   pinctrl-names = "default";
-};
-
 ðmac {
status = "okay";
pinctrl-0 = <ð_rgmii_pins>;
@@ -149,21 +137,18 @@
};
 };
 
-&usb0_phy {
-   status = "okay";
-   phy-supply = <&usb_vbus>;
-};
-
-&usb1_phy {
-   status = "okay";
-};
-
-&usb0 {
+&ir {
status = "okay";
+   pinctrl-0 = <&remote_input_ao_pins>;
+   pinctrl-names = "default";
 };
 
-&usb1 {
+&pwm_ef {
status = "okay";
+   pinctrl-0 = <&pwm_e_pins>;
+   pinctrl-names = "default";
+   clocks = <&clkc CLKID_FCLK_DIV4>;
+   clock-names = "clkin0";
 };
 
 /* Wireless SDIO Module */
@@ -229,10 +214,25 @@
vmmcq-sumpply = <&vcc_1v8>;
 };
 
-&pwm_ef {
+&uart_AO {
status = "okay";
-   pinctrl-0 = <&pwm_e_pins>;
+   pinctrl-0 = <&uart_ao_a_pins>;
pinctrl-names = "default";
-   clocks = <&clkc CLKID_FCLK_DIV4>;
-   clock-names = "clkin0";
+};
+
+&usb0_phy {
+   status = "okay";
+   phy-supply = <&usb_vbus>;
+};
+
+&usb1_phy {
+   status = "okay";
+};
+
+&usb0 {
+   status = "okay";
+};
+
+&usb1 {
+   status = "okay";
 };
-- 
2.12.0

[PATCH v2 08/18] arm64: dts: meson-gxl-s905x: Comment typo fix

[Andreas Färber]

Reviewed-by: Neil Armstrong 
Signed-off-by: Andreas Färber 
---
 v1 -> v2: Unchanged
 
 arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
index 0f78d836edaf..3314a0b3dad9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxl-s905x.dtsi
@@ -48,7 +48,7 @@
compatible = "amlogic,s905x", "amlogic,meson-gxl";
 };
 
-/* S905X Only has access to its internal PHY */
+/* S905X only has access to its internal PHY */
 ðmac {
phy-mode = "rmii";
phy-handle = <&internal_phy>;
-- 
2.12.0

[PATCH v2 01/18] dt-bindings: arm: amlogic: Reorder boards

[Andreas Färber]

Enforce groupment by SoCs, and order alphabetically within the group
(with some exceptions). This should facilitate adding new boards.

Signed-off-by: Andreas Färber 
---
 v1 -> v2:
 * Rebased (new boards added)
 * Pointed out alphabetical order in the binding, too (Rob)
 
 Documentation/devicetree/bindings/arm/amlogic.txt | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt 
b/Documentation/devicetree/bindings/arm/amlogic.txt
index bfd5b558477d..cad5b5a48d92 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -29,26 +29,32 @@ Boards with the Amlogic Meson GXM S912 SoC shall have the 
following properties:
   Required root node property:
 compatible: "amlogic,s912", "amlogic,meson-gxm";
 
-Board compatible values:
+Board compatible values (alphabetically, grouped by SoC):
+
   - "geniatech,atv1200" (Meson6)
+
   - "minix,neo-x8" (Meson8)
-  - "tronfy,mxq" (Meson8b)
+
   - "hardkernel,odroid-c1" (Meson8b)
+  - "tronfy,mxq" (Meson8b)
+
+  - "amlogic,p200" (Meson gxbb)
+  - "amlogic,p201" (Meson gxbb)
+  - "hardkernel,odroid-c2" (Meson gxbb)
+  - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
   - "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb)
   - "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb)
   - "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb)
-  - "hardkernel,odroid-c2" (Meson gxbb)
-  - "amlogic,p200" (Meson gxbb)
-  - "amlogic,p201" (Meson gxbb)
   - "wetek,hub" (Meson gxbb)
   - "wetek,play2" (Meson gxbb)
+
   - "amlogic,p212" (Meson gxl s905x)
+  - "hwacom,amazetv" (Meson gxl s905x)
   - "khadas,vim" (Meson gxl s905x)
 
   - "amlogic,p230" (Meson gxl s905d)
   - "amlogic,p231" (Meson gxl s905d)
-  - "hwacom,amazetv" (Meson gxl s905x)
+
   - "amlogic,q200" (Meson gxm s912)
   - "amlogic,q201" (Meson gxm s912)
-  - "nexbox,a95x" (Meson gxbb or Meson gxl s905x)
   - "nexbox,a1" (Meson gxm s912)
-- 
2.12.0

[PATCH v1] staging: ccree: fix all whitespace errors

[Dhiru Kholia]

These whitespace issues were found by the checkpatch.pl script. This
patch helps in making the staging tree a bit cleaner.

Signed-off-by: Dhiru Kholia 
---
 drivers/staging/ccree/TODO|   2 +-
 drivers/staging/ccree/cc_bitops.h |   6 +-
 drivers/staging/ccree/cc_crypto_ctx.h |   8 +--
 drivers/staging/ccree/cc_hal.h|   6 +-
 drivers/staging/ccree/cc_hw_queue_defs.h  | 116 +++---
 drivers/staging/ccree/cc_lli_defs.h   |   6 +-
 drivers/staging/ccree/cc_pal_log.h|  12 ++--
 drivers/staging/ccree/cc_pal_log_plat.h   |   6 +-
 drivers/staging/ccree/cc_pal_types.h  |  42 +--
 drivers/staging/ccree/cc_pal_types_plat.h |   8 +--
 drivers/staging/ccree/cc_regs.h   |  10 +--
 11 files changed, 111 insertions(+), 111 deletions(-)

diff --git a/drivers/staging/ccree/TODO b/drivers/staging/ccree/TODO
index c9f5754..cabe633 100644
--- a/drivers/staging/ccree/TODO
+++ b/drivers/staging/ccree/TODO
@@ -20,7 +20,7 @@ a.k.a stuff fixing for this driver to move out of staging
 8.  Handle the many checkpatch errors.
 9.  Implement ahash import/export correctly.
 10. Go through a proper review of DT bindings and sysfs ABI
-11. Sort out FIPS mode: bake tests into testmgr, sort out behaviour on error, 
+11. Sort out FIPS mode: bake tests into testmgr, sort out behaviour on error,
 figure if 3DES weak key check is needed
 
 Kernel infrastructure items
diff --git a/drivers/staging/ccree/cc_bitops.h 
b/drivers/staging/ccree/cc_bitops.h
index 3a39565..ad3aeed 100644
--- a/drivers/staging/ccree/cc_bitops.h
+++ b/drivers/staging/ccree/cc_bitops.h
@@ -1,15 +1,15 @@
 /*
  * Copyright (C) 2012-2017 ARM Limited or its affiliates.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
- * 
+ *
  * This program 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 General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, see .
  */
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 9e10b26..f8ebd76 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -1,15 +1,15 @@
 /*
  * Copyright (C) 2012-2017 ARM Limited or its affiliates.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
- * 
+ *
  * This program 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 General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, see .
  */
@@ -163,7 +163,7 @@ enum drv_hash_mode {
DRV_HASH_SHA512 = 3,
DRV_HASH_SHA384 = 4,
DRV_HASH_MD5 = 5,
-   DRV_HASH_CBC_MAC = 6, 
+   DRV_HASH_CBC_MAC = 6,
DRV_HASH_XCBC_MAC = 7,
DRV_HASH_CMAC = 8,
DRV_HASH_MODE_NUM = 9,
diff --git a/drivers/staging/ccree/cc_hal.h b/drivers/staging/ccree/cc_hal.h
index 75a0ce3..dd1c66d 100644
--- a/drivers/staging/ccree/cc_hal.h
+++ b/drivers/staging/ccree/cc_hal.h
@@ -1,15 +1,15 @@
 /*
  * Copyright (C) 2012-2017 ARM Limited or its affiliates.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
- * 
+ *
  * This program 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 General Public License for more details.
- * 
+ *
  * You should have received a copy of the GNU General Public License
  * along with this program; if not, see .
  */
diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index fbaf1b6..8dca344 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -1,15 +1,15 @@
 /*
  * Copyright (C) 2012-2017 ARM Limited or its affiliates.
- * 
+ *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
- * 
+ *
  * This program is distributed in the hope that it will be useful,
  * but WITHOUT ANY WA

[git pull] Input updates for v4.11-rc0

[Dmitry Torokhov]

Hi Linus,

Please pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus

to receive updates for the input subsystem. You will get an updated xpad
driver with a few more recognized device IDs, and a new psxpad-spi
driver, allowing connecting Playstation 1 and 2 joypads via SPI bus.

Changelog:
-

Arnd Bergmann (1):
  Input: cros_ec_keyb - remove extraneous 'const'

Benjamin Valentin (3):
  Input: xpad - sort supported devices by USB ID
  Input: xpad - sync supported devices with xboxdrv
  Input: xpad - add USB IDs for Mad Catz Brawlstick and Razer Sabertooth

Tomohiro Yoshidomi (1):
  Input: add support for PlayStation 1/2 joypads connected via SPI

Diffstat:


 drivers/input/joystick/Kconfig|  21 ++
 drivers/input/joystick/Makefile   |   1 +
 drivers/input/joystick/psxpad-spi.c   | 401 ++
 drivers/input/joystick/xpad.c |  27 ++-
 drivers/input/keyboard/cros_ec_keyb.c |   2 +-
 5 files changed, 445 insertions(+), 7 deletions(-)
 create mode 100644 drivers/input/joystick/psxpad-spi.c

Thanks.

-- 
Dmitry