[PATCH v2 1/4] staging : comedi : fix type issues in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a type issues like
i.e Prefer kernel type 'u8' over 'uint8_t'
Prefer kernel type 'u16' over 'uint16_t'
Prefer kernel type 'u32' over 'uint32_t'
Prefer kernel type 's16' over 'int16_t'
Prefer kernel type 's32' over 'int32_t'
found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
changes since v1: Rework
---
 drivers/staging/comedi/drivers/s626.c | 212 +-
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index c5e0863..a399d7b 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -75,24 +75,24 @@ struct s626_buffer_dma {
 };
 
 struct s626_private {
-   uint8_t ai_cmd_running; /* ai_cmd is running */
+   u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
 * units of the timer */
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
 * units of the timer */
-   uint16_t counter_int_enabs; /* counter interrupt enable mask
+   u16 counter_int_enabs;  /* counter interrupt enable mask
 * for MISC2 register */
-   uint8_t adc_items;  /* number of items in ADC poll list */
+   u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
 * program */
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
 * and hold DAC data */
-   uint32_t *dac_wbuf; /* pointer to logical adrs of DMA buffer
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
 * used to hold DAC data */
-   uint16_t dacpol;/* image of DAC polarity register */
-   uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
-   uint32_t i2c_adrs;  /* I2C device address for onboard EEPROM
+   u16 dacpol; /* image of DAC polarity register */
+   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
 * (board rev dependent) */
 };
 
@@ -304,10 +304,10 @@ static uint8_t s626_i2c_read(struct comedi_device *dev, 
uint8_t addr)
 /* ***  DAC FUNCTIONS *** */
 
 /* TrimDac LogicalChan-to-PhysicalChan mapping table. */
-static const uint8_t s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
+static const u8 s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
 
 /* TrimDac LogicalChan-to-EepromAdrs mapping table. */
-static const uint8_t s626_trimadrs[] = {
+static const u8 s626_trimadrs[] = {
0x40, 0x41, 0x42, 0x50, 0x51, 0x52, 0x53, 0x60, 0x61, 0x62, 0x63
 };
 
@@ -516,12 +516,12 @@ static int s626_send_dac(struct comedi_device *dev, 
uint32_t val)
  * Private helper function: Write setpoint to an application DAC channel.
  */
 static int s626_set_dac(struct comedi_device *dev,
-   uint16_t chan, int16_t dacdata)
+   u16 chan, s16 dacdata)
 {
struct s626_private *devpriv = dev->private;
-   uint16_t signmask;
-   uint32_t ws_image;
-   uint32_t val;
+   u16 signmask;
+   u32 ws_image;
+   u32 val;
 
/*
 * Adjust DAC data polarity and set up Polarity Control Register image.
@@ -535,7 +535,7 @@ static int s626_set_dac(struct comedi_device *dev,
}
 
/* Limit DAC setpoint value to valid range. */
-   if ((uint16_t)dacdata > 0x1FFF)
+   if ((u16)dacdata > 0x1FFF)
dacdata = 0x1FFF;
 
/*
@@ -575,23 +575,23 @@ static int s626_set_dac(struct comedi_device *dev,
 * (write to non-existent trimdac). */
val |= 0x4000;  /* Address the two main dual-DAC devices
 * (TSL's chip select enables target device). */
-   val |= ((uint32_t)(chan & 1) << 15);/* Address the DAC channel
+   val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
 * within the device. */
-   val |= (uint32_t)dacdata;   /* Include DAC setpoint data. */
+   val |= (u32)dacdata;/* Include DAC setpoint data. */
return s626_send_dac(dev, val);
 }
 
 static int s626_write_trim_dac(struct comedi_device *dev,
-  uint8_t logical_chan, uint8_t dac_data)
+   

[PATCH v2 1/4] staging : comedi : fix type issues in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a type issues like
i.e Prefer kernel type 'u8' over 'uint8_t'
Prefer kernel type 'u16' over 'uint16_t'
Prefer kernel type 'u32' over 'uint32_t'
Prefer kernel type 's16' over 'int16_t'
Prefer kernel type 's32' over 'int32_t'
found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
changes since v1: Rework
---
 drivers/staging/comedi/drivers/s626.c | 212 +-
 1 file changed, 106 insertions(+), 106 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index c5e0863..a399d7b 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -75,24 +75,24 @@ struct s626_buffer_dma {
 };
 
 struct s626_private {
-   uint8_t ai_cmd_running; /* ai_cmd is running */
+   u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
 * units of the timer */
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
 * units of the timer */
-   uint16_t counter_int_enabs; /* counter interrupt enable mask
+   u16 counter_int_enabs;  /* counter interrupt enable mask
 * for MISC2 register */
-   uint8_t adc_items;  /* number of items in ADC poll list */
+   u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
 * program */
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
 * and hold DAC data */
-   uint32_t *dac_wbuf; /* pointer to logical adrs of DMA buffer
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
 * used to hold DAC data */
-   uint16_t dacpol;/* image of DAC polarity register */
-   uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
-   uint32_t i2c_adrs;  /* I2C device address for onboard EEPROM
+   u16 dacpol; /* image of DAC polarity register */
+   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
 * (board rev dependent) */
 };
 
@@ -304,10 +304,10 @@ static uint8_t s626_i2c_read(struct comedi_device *dev, 
uint8_t addr)
 /* ***  DAC FUNCTIONS *** */
 
 /* TrimDac LogicalChan-to-PhysicalChan mapping table. */
-static const uint8_t s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
+static const u8 s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
 
 /* TrimDac LogicalChan-to-EepromAdrs mapping table. */
-static const uint8_t s626_trimadrs[] = {
+static const u8 s626_trimadrs[] = {
0x40, 0x41, 0x42, 0x50, 0x51, 0x52, 0x53, 0x60, 0x61, 0x62, 0x63
 };
 
@@ -516,12 +516,12 @@ static int s626_send_dac(struct comedi_device *dev, 
uint32_t val)
  * Private helper function: Write setpoint to an application DAC channel.
  */
 static int s626_set_dac(struct comedi_device *dev,
-   uint16_t chan, int16_t dacdata)
+   u16 chan, s16 dacdata)
 {
struct s626_private *devpriv = dev->private;
-   uint16_t signmask;
-   uint32_t ws_image;
-   uint32_t val;
+   u16 signmask;
+   u32 ws_image;
+   u32 val;
 
/*
 * Adjust DAC data polarity and set up Polarity Control Register image.
@@ -535,7 +535,7 @@ static int s626_set_dac(struct comedi_device *dev,
}
 
/* Limit DAC setpoint value to valid range. */
-   if ((uint16_t)dacdata > 0x1FFF)
+   if ((u16)dacdata > 0x1FFF)
dacdata = 0x1FFF;
 
/*
@@ -575,23 +575,23 @@ static int s626_set_dac(struct comedi_device *dev,
 * (write to non-existent trimdac). */
val |= 0x4000;  /* Address the two main dual-DAC devices
 * (TSL's chip select enables target device). */
-   val |= ((uint32_t)(chan & 1) << 15);/* Address the DAC channel
+   val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
 * within the device. */
-   val |= (uint32_t)dacdata;   /* Include DAC setpoint data. */
+   val |= (u32)dacdata;/* Include DAC setpoint data. */
return s626_send_dac(dev, val);
 }
 
 static int s626_write_trim_dac(struct comedi_device *dev,
-  uint8_t logical_chan, uint8_t dac_data)
+  u8 

[PATCH v2 3/4] Staging: comedi:Fix unsigned int to bare use of unsigned issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
found by the checkpatch.pl tool

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
changes since v1: No change
---
 drivers/staging/comedi/drivers/s626.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index edcd466..790ca41 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -728,7 +728,7 @@ static u16 s626_get_mode_a(struct comedi_device *dev,
u16 cra;
u16 crb;
u16 setup;
-   unsigned cntsrc, clkmult, clkpol, encmode;
+   unsigned int cntsrc, clkmult, clkpol, encmode;
 
/* Fetch CRA and CRB register images. */
cra = s626_debi_read(dev, S626_LP_CRA(chan));
@@ -783,7 +783,7 @@ static u16 s626_get_mode_b(struct comedi_device *dev,
u16 cra;
u16 crb;
u16 setup;
-   unsigned cntsrc, clkmult, clkpol, encmode;
+   unsigned int cntsrc, clkmult, clkpol, encmode;
 
/* Fetch CRA and CRB register images. */
cra = s626_debi_read(dev, S626_LP_CRA(chan));
@@ -858,7 +858,7 @@ static void s626_set_mode_a(struct comedi_device *dev,
struct s626_private *devpriv = dev->private;
u16 cra;
u16 crb;
-   unsigned cntsrc, clkmult, clkpol;
+   unsigned int cntsrc, clkmult, clkpol;
 
/* Initialize CRA and CRB images. */
/* Preload trigger is passed through. */
@@ -936,7 +936,7 @@ static void s626_set_mode_b(struct comedi_device *dev,
struct s626_private *devpriv = dev->private;
u16 cra;
u16 crb;
-   unsigned cntsrc, clkmult, clkpol;
+   unsigned int cntsrc, clkmult, clkpol;
 
/* Initialize CRA and CRB images. */
/* IndexSrc is passed through. */
-- 
1.9.1

[PATCH v2 2/4] Staging: comedi: Fix WARNING issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a Block comments
issues found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
changes since v1: No change
---
 drivers/staging/comedi/drivers/s626.c | 60 +++
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index a399d7b..edcd466 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -76,24 +76,38 @@ struct s626_buffer_dma {
 
 struct s626_private {
u8 ai_cmd_running;  /* ai_cmd is running */
-   unsigned int ai_sample_timer;   /* time between samples in
-* units of the timer */
+   unsigned int ai_sample_timer;   /*
+* time between samples in
+* units of the timer
+*/
int ai_convert_count;   /* conversion counter */
-   unsigned int ai_convert_timer;  /* time between conversion in
-* units of the timer */
-   u16 counter_int_enabs;  /* counter interrupt enable mask
-* for MISC2 register */
+   unsigned int ai_convert_timer;  /*
+* time between conversion in
+* units of the timer
+*/
+   u16 counter_int_enabs;  /*
+* counter interrupt enable mask
+* for MISC2 register
+*/
u8 adc_items;   /* number of items in ADC poll list */
-   struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
-* program */
-   struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
-* and hold DAC data */
-   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
-* used to hold DAC data */
+   struct s626_buffer_dma rps_buf; /*
+* DMA buffer used to hold ADC (RPS1)
+* program
+*/
+   struct s626_buffer_dma ana_buf; /*
+* DMA buffer used to receive ADC data
+* and hold DAC data
+*/
+   u32 *dac_wbuf;  /*
+* pointer to logical adrs of DMA buffer
+* used to hold DAC data
+*/
u16 dacpol; /* image of DAC polarity register */
u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
-   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
-* (board rev dependent) */
+   u32 i2c_adrs;   /*
+* I2C device address for onboard EEPROM
+* (board rev dependent)
+*/
 };
 
 /* Counter overflow/index event flag masks for RDMISC2. */
@@ -571,12 +585,18 @@ static int s626_set_dac(struct comedi_device *dev,
 * to a  non-existent TrimDac channel) that serves to keep the clock
 * running after the packet has been sent to the target DAC.
 */
-   val = 0x0F00;   /* Continue clock after target DAC data
-* (write to non-existent trimdac). */
-   val |= 0x4000;  /* Address the two main dual-DAC devices
-* (TSL's chip select enables target device). */
-   val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
-* within the device. */
+   val = 0x0F00;   /*
+* Continue clock after target DAC data
+* (write to non-existent trimdac).
+*/
+   val |= 0x4000;  /*
+* Address the two main dual-DAC devices
+* (TSL's chip select enables target device).
+*/
+   val |= ((u32)(chan & 1) << 15); /*
+* Address the DAC channel
+* within the device.
+*/
val |= 

[PATCH v2 4/4] Staging: comedi: fix line over 80 characters issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a  line over 80
characters issues found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
changes since v1: No change
---
 drivers/staging/comedi/drivers/s626.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 790ca41..b5cd946 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -2520,7 +2520,8 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, dev->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 
0);
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc,
+0);
if (ret)
return ret;
}
-- 
1.9.1

[PATCH v2 3/4] Staging: comedi:Fix unsigned int to bare use of unsigned issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
found by the checkpatch.pl tool

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
changes since v1: No change
---
 drivers/staging/comedi/drivers/s626.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index edcd466..790ca41 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -728,7 +728,7 @@ static u16 s626_get_mode_a(struct comedi_device *dev,
u16 cra;
u16 crb;
u16 setup;
-   unsigned cntsrc, clkmult, clkpol, encmode;
+   unsigned int cntsrc, clkmult, clkpol, encmode;
 
/* Fetch CRA and CRB register images. */
cra = s626_debi_read(dev, S626_LP_CRA(chan));
@@ -783,7 +783,7 @@ static u16 s626_get_mode_b(struct comedi_device *dev,
u16 cra;
u16 crb;
u16 setup;
-   unsigned cntsrc, clkmult, clkpol, encmode;
+   unsigned int cntsrc, clkmult, clkpol, encmode;
 
/* Fetch CRA and CRB register images. */
cra = s626_debi_read(dev, S626_LP_CRA(chan));
@@ -858,7 +858,7 @@ static void s626_set_mode_a(struct comedi_device *dev,
struct s626_private *devpriv = dev->private;
u16 cra;
u16 crb;
-   unsigned cntsrc, clkmult, clkpol;
+   unsigned int cntsrc, clkmult, clkpol;
 
/* Initialize CRA and CRB images. */
/* Preload trigger is passed through. */
@@ -936,7 +936,7 @@ static void s626_set_mode_b(struct comedi_device *dev,
struct s626_private *devpriv = dev->private;
u16 cra;
u16 crb;
-   unsigned cntsrc, clkmult, clkpol;
+   unsigned int cntsrc, clkmult, clkpol;
 
/* Initialize CRA and CRB images. */
/* IndexSrc is passed through. */
-- 
1.9.1

[PATCH v2 2/4] Staging: comedi: Fix WARNING issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a Block comments
issues found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
changes since v1: No change
---
 drivers/staging/comedi/drivers/s626.c | 60 +++
 1 file changed, 40 insertions(+), 20 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index a399d7b..edcd466 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -76,24 +76,38 @@ struct s626_buffer_dma {
 
 struct s626_private {
u8 ai_cmd_running;  /* ai_cmd is running */
-   unsigned int ai_sample_timer;   /* time between samples in
-* units of the timer */
+   unsigned int ai_sample_timer;   /*
+* time between samples in
+* units of the timer
+*/
int ai_convert_count;   /* conversion counter */
-   unsigned int ai_convert_timer;  /* time between conversion in
-* units of the timer */
-   u16 counter_int_enabs;  /* counter interrupt enable mask
-* for MISC2 register */
+   unsigned int ai_convert_timer;  /*
+* time between conversion in
+* units of the timer
+*/
+   u16 counter_int_enabs;  /*
+* counter interrupt enable mask
+* for MISC2 register
+*/
u8 adc_items;   /* number of items in ADC poll list */
-   struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
-* program */
-   struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
-* and hold DAC data */
-   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
-* used to hold DAC data */
+   struct s626_buffer_dma rps_buf; /*
+* DMA buffer used to hold ADC (RPS1)
+* program
+*/
+   struct s626_buffer_dma ana_buf; /*
+* DMA buffer used to receive ADC data
+* and hold DAC data
+*/
+   u32 *dac_wbuf;  /*
+* pointer to logical adrs of DMA buffer
+* used to hold DAC data
+*/
u16 dacpol; /* image of DAC polarity register */
u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
-   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
-* (board rev dependent) */
+   u32 i2c_adrs;   /*
+* I2C device address for onboard EEPROM
+* (board rev dependent)
+*/
 };
 
 /* Counter overflow/index event flag masks for RDMISC2. */
@@ -571,12 +585,18 @@ static int s626_set_dac(struct comedi_device *dev,
 * to a  non-existent TrimDac channel) that serves to keep the clock
 * running after the packet has been sent to the target DAC.
 */
-   val = 0x0F00;   /* Continue clock after target DAC data
-* (write to non-existent trimdac). */
-   val |= 0x4000;  /* Address the two main dual-DAC devices
-* (TSL's chip select enables target device). */
-   val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
-* within the device. */
+   val = 0x0F00;   /*
+* Continue clock after target DAC data
+* (write to non-existent trimdac).
+*/
+   val |= 0x4000;  /*
+* Address the two main dual-DAC devices
+* (TSL's chip select enables target device).
+*/
+   val |= ((u32)(chan & 1) << 15); /*
+* Address the DAC channel
+* within the device.
+*/
val |= (u32)dacdata;/* Include DAC 

[PATCH v2 4/4] Staging: comedi: fix line over 80 characters issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a  line over 80
characters issues found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
changes since v1: No change
---
 drivers/staging/comedi/drivers/s626.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 790ca41..b5cd946 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -2520,7 +2520,8 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, dev->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 
0);
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc,
+0);
if (ret)
return ret;
}
-- 
1.9.1

Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

[Aleksa Sarai]

Hi Tejun,

>> > Unfortunately, cgroup hierarchy isn't designed to support this sort
>> > of automatic delegation.  Unpriv processes would be able to escape
>> > constraints on v1 with some controllers and on v2 controllers have to
>> > be explicitly enabled by root for delegated scope to have access to
>> > them.
>>
>> Not necessarily.  We also talked about pinning the cgroup tree so that
>> once you enter the cgroup namespace, your current cgroup directory
>> becomes your root, meaning you can't cd back into the ancestors and
>> thus can't write their tasks file, meaning, I think, that it should be
>> impossible to escape ancestor constraints.
>
> I wish it were that clean.  Unfortunately, on v1, some controllers
> (memory and blkio depending on settings, netcls and netprio always)
> simply aren't properly hierarchical and if you have write perm to
> subdirectory you can escape the constraints of your ancestors.
> Whether you can cd back up or not doesn't matter at all, so we can't
> allow delegation by default.

I see two options here, which would allow us to have subtree
delegation without losing hierarchical structure:

1. Don't enable subtree delegation on v1 hierarchies. This would be
the simplest solution, and would cut out most people from using this
feature today -- but it would mean less work around trying to figure
out which hierarchies are safe to delegate (we make it explicit that
when you enable a cgroup on v2 that it must be safe to delegate by an
unprivileged user). We also get the benefit of having the more strict
cgroup.procs write rules.
2. Don't do subtree delegation on hierarchies that aren't
hierarchical. This would have to be done in collaboration with the
controllers (since cgroup core doesn't know which is hierarchical),
and would allow all users of cgroups today to get subtree delegation.

>> > Why does an unpriv NS need to have cgroup delegated to it without
>> > cooperation from cgroup manager?
>>
>> There's actually many answers to this.  The one I'm insterested in is
>> the ability for applications to make use of container features without
>> having to ask permission from some orchestration engine.  The problem
>
> What's "container features"?  Do you mean resource control by that?

Yes. Also the device cgroup. And ignoring the container usecase, it
would be useful to regular programs if they could use cgroup resource
accounting as part of their regular operation. Regular processes can
use rlimits -- why can't they use cgroups without needing cooperation
from an admin process (which makes for security and administration
issues).

>> most people are looking at is how do I prevent the cgroup manager from
>> running as root, because that's a security problem waiting to happen.
>
> It's distributing system wide resources so the top of the tree will
> always be owned by root and delegating subtrees is a fairly minimal
> operation.  I don't see how that would necessarily lead to security
> problems.

If I understand correctly, the security issues James is referring to
is that the cgroup manager could have a bug in it (and because the
cgroup interface is the filesystem, it would probably be some kind of
write-to-any-path bug). This is an intrinsic part of the model of "you
need to have cooperation with an admin process in order to use
resource limiting for your own processes".

-- 
Aleksa Sarai (cyphar)
www.cyphar.com

Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

[Aleksa Sarai]

Hi Tejun,

>> > Unfortunately, cgroup hierarchy isn't designed to support this sort
>> > of automatic delegation.  Unpriv processes would be able to escape
>> > constraints on v1 with some controllers and on v2 controllers have to
>> > be explicitly enabled by root for delegated scope to have access to
>> > them.
>>
>> Not necessarily.  We also talked about pinning the cgroup tree so that
>> once you enter the cgroup namespace, your current cgroup directory
>> becomes your root, meaning you can't cd back into the ancestors and
>> thus can't write their tasks file, meaning, I think, that it should be
>> impossible to escape ancestor constraints.
>
> I wish it were that clean.  Unfortunately, on v1, some controllers
> (memory and blkio depending on settings, netcls and netprio always)
> simply aren't properly hierarchical and if you have write perm to
> subdirectory you can escape the constraints of your ancestors.
> Whether you can cd back up or not doesn't matter at all, so we can't
> allow delegation by default.

I see two options here, which would allow us to have subtree
delegation without losing hierarchical structure:

1. Don't enable subtree delegation on v1 hierarchies. This would be
the simplest solution, and would cut out most people from using this
feature today -- but it would mean less work around trying to figure
out which hierarchies are safe to delegate (we make it explicit that
when you enable a cgroup on v2 that it must be safe to delegate by an
unprivileged user). We also get the benefit of having the more strict
cgroup.procs write rules.
2. Don't do subtree delegation on hierarchies that aren't
hierarchical. This would have to be done in collaboration with the
controllers (since cgroup core doesn't know which is hierarchical),
and would allow all users of cgroups today to get subtree delegation.

>> > Why does an unpriv NS need to have cgroup delegated to it without
>> > cooperation from cgroup manager?
>>
>> There's actually many answers to this.  The one I'm insterested in is
>> the ability for applications to make use of container features without
>> having to ask permission from some orchestration engine.  The problem
>
> What's "container features"?  Do you mean resource control by that?

Yes. Also the device cgroup. And ignoring the container usecase, it
would be useful to regular programs if they could use cgroup resource
accounting as part of their regular operation. Regular processes can
use rlimits -- why can't they use cgroups without needing cooperation
from an admin process (which makes for security and administration
issues).

>> most people are looking at is how do I prevent the cgroup manager from
>> running as root, because that's a security problem waiting to happen.
>
> It's distributing system wide resources so the top of the tree will
> always be owned by root and delegating subtrees is a fairly minimal
> operation.  I don't see how that would necessarily lead to security
> problems.

If I understand correctly, the security issues James is referring to
is that the cgroup manager could have a bug in it (and because the
cgroup interface is the filesystem, it would probably be some kind of
write-to-any-path bug). This is an intrinsic part of the model of "you
need to have cooperation with an admin process in order to use
resource limiting for your own processes".

-- 
Aleksa Sarai (cyphar)
www.cyphar.com

[patch] IB/hfi1: fix some indenting

[Dan Carpenter]

That extra tabs are misleading.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/infiniband/hw/hfi1/init.c 
b/drivers/infiniband/hw/hfi1/init.c
index 5cc492e..0d28a5a 100644
--- a/drivers/infiniband/hw/hfi1/init.c
+++ b/drivers/infiniband/hw/hfi1/init.c
@@ -1337,7 +1337,7 @@ static void cleanup_device_data(struct hfi1_devdata *dd)
dma_free_coherent(>pcidev->dev, sizeof(u64),
  (void *)dd->rcvhdrtail_dummy_kvaddr,
  dd->rcvhdrtail_dummy_physaddr);
- dd->rcvhdrtail_dummy_kvaddr = NULL;
+   dd->rcvhdrtail_dummy_kvaddr = NULL;
}
 
for (ctxt = 0; tmp && ctxt < dd->num_rcv_contexts; ctxt++) {

[patch] IB/hfi1: fix some indenting

[Dan Carpenter]

That extra tabs are misleading.

Signed-off-by: Dan Carpenter 

diff --git a/drivers/infiniband/hw/hfi1/init.c 
b/drivers/infiniband/hw/hfi1/init.c
index 5cc492e..0d28a5a 100644
--- a/drivers/infiniband/hw/hfi1/init.c
+++ b/drivers/infiniband/hw/hfi1/init.c
@@ -1337,7 +1337,7 @@ static void cleanup_device_data(struct hfi1_devdata *dd)
dma_free_coherent(>pcidev->dev, sizeof(u64),
  (void *)dd->rcvhdrtail_dummy_kvaddr,
  dd->rcvhdrtail_dummy_physaddr);
- dd->rcvhdrtail_dummy_kvaddr = NULL;
+   dd->rcvhdrtail_dummy_kvaddr = NULL;
}
 
for (ctxt = 0; tmp && ctxt < dd->num_rcv_contexts; ctxt++) {

[patch v2] usb: f_fs: off by one bug in _ffs_func_bind()

[Dan Carpenter]

This loop is supposed to set all the .num[] values to -1 but it's off by
one so it skips the first element and sets one element past the end of
the array.

I've cleaned up the loop a little as well.

Fixes: ddf8abd25994 ('USB: f_fs: the FunctionFS driver')
Signed-off-by: Dan Carpenter 
---
v2: move the eps_ptr assignment outside the loop.

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 73515d5..d26eb64 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2729,6 +2729,7 @@ static int _ffs_func_bind(struct usb_configuration *c,
func->ffs->ss_descs_count;
 
int fs_len, hs_len, ss_len, ret, i;
+   struct ffs_ep *eps_ptr;
 
/* Make it a single chunk, less management later on */
vla_group(d);
@@ -2777,12 +2778,9 @@ static int _ffs_func_bind(struct usb_configuration *c,
   ffs->raw_descs_length);
 
memset(vla_ptr(vlabuf, d, inums), 0xff, d_inums__sz);
-   for (ret = ffs->eps_count; ret; --ret) {
-   struct ffs_ep *ptr;
-
-   ptr = vla_ptr(vlabuf, d, eps);
-   ptr[ret].num = -1;
-   }
+   eps_ptr = vla_ptr(vlabuf, d, eps);
+   for (i = 0; i < ffs->eps_count; i++)
+   eps_ptr[i].num = -1;
 
/* Save pointers
 * d_eps == vlabuf, func->eps used to kfree vlabuf later

[patch v2] usb: f_fs: off by one bug in _ffs_func_bind()

[Dan Carpenter]

This loop is supposed to set all the .num[] values to -1 but it's off by
one so it skips the first element and sets one element past the end of
the array.

I've cleaned up the loop a little as well.

Fixes: ddf8abd25994 ('USB: f_fs: the FunctionFS driver')
Signed-off-by: Dan Carpenter 
---
v2: move the eps_ptr assignment outside the loop.

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index 73515d5..d26eb64 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -2729,6 +2729,7 @@ static int _ffs_func_bind(struct usb_configuration *c,
func->ffs->ss_descs_count;
 
int fs_len, hs_len, ss_len, ret, i;
+   struct ffs_ep *eps_ptr;
 
/* Make it a single chunk, less management later on */
vla_group(d);
@@ -2777,12 +2778,9 @@ static int _ffs_func_bind(struct usb_configuration *c,
   ffs->raw_descs_length);
 
memset(vla_ptr(vlabuf, d, inums), 0xff, d_inums__sz);
-   for (ret = ffs->eps_count; ret; --ret) {
-   struct ffs_ep *ptr;
-
-   ptr = vla_ptr(vlabuf, d, eps);
-   ptr[ret].num = -1;
-   }
+   eps_ptr = vla_ptr(vlabuf, d, eps);
+   for (i = 0; i < ffs->eps_count; i++)
+   eps_ptr[i].num = -1;
 
/* Save pointers
 * d_eps == vlabuf, func->eps used to kfree vlabuf later

IOV iterator bug in net tree (was Re: Deadlock when running DevStack on latest pull of net tree)

[Alexander Duyck]

On Fri, May 27, 2016 at 11:21 AM, Alexander Duyck
 wrote:
> I started out this morning by trying to run DevStack on the latest
> "net' kernel and it looks like I am hanging on some sort of locking
> problem with RabbitMQ.  Specifically I am seeing one CPU jump to 100%
> with perf showing that I am spinning on a lock.
>
> I'm working to bisect it now, but just thought I would put it out
> there if anybody had already root caused this issue.  Below is a few
> traces to the spin lock call on the spinning CPU:

I misread the perf trace.  I wasn't spinning on a lock I was spinning
on the IOV iterator.  It just happened to push the lock to the top of
the perf trace.  I bisected it down to the recent change in
iterate_and_advance which was already fixed in Linus's tree in commit
19f18459330f "do 'fold checks into iterate_and_advance()" right'.

- Alex

IOV iterator bug in net tree (was Re: Deadlock when running DevStack on latest pull of net tree)

[Alexander Duyck]

On Fri, May 27, 2016 at 11:21 AM, Alexander Duyck
 wrote:
> I started out this morning by trying to run DevStack on the latest
> "net' kernel and it looks like I am hanging on some sort of locking
> problem with RabbitMQ.  Specifically I am seeing one CPU jump to 100%
> with perf showing that I am spinning on a lock.
>
> I'm working to bisect it now, but just thought I would put it out
> there if anybody had already root caused this issue.  Below is a few
> traces to the spin lock call on the spinning CPU:

I misread the perf trace.  I wasn't spinning on a lock I was spinning
on the IOV iterator.  It just happened to push the lock to the top of
the perf trace.  I bisected it down to the recent change in
iterate_and_advance which was already fixed in Linus's tree in commit
19f18459330f "do 'fold checks into iterate_and_advance()" right'.

- Alex

Re: linux-next memleak after IO on dax mountpoint

[Xiong Zhou]

On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote:
...
> Still working on to id which commit in this merge causes this issuer,

Narrowed down to:

37e5823 block: add offset in blk_add_request_payload()
e048948 blk-mq: Export tagset iter function
58b4560 nvme: add helper nvme_map_len()
03b5929 nvme: rewrite discard support
8093f7c nvme: add helper nvme_setup_cmd()
21f033f NVMe: Skip async events for degraded controllers
82b4552 nvme: Use blk-mq helper for IO termination
93e9d8e block: add ability to flag write back caching on a device
519a7e1 dm: switch to using blk_queue_write_cache()
bb8d261 nvme: introduce a controller state machine
92911a5 nvme: tighten up state check for namespace scanning
5955be2 nvme: move namespace scanning to core
f866fc4 nvme: move AER handling to common code
0bf77e9 nvme: switch to RCU freeing the namespace
9082e87 block: remove struct bio_batch
38f2525 block: add __blkdev_issue_discard
57aac2f lightnvm: fix "warning: ‘ret’ may be used uninitialized"
ecfb40c lightnvm: handle submit_io failure
1145e63 lightnvm: implement nvm_submit_ppa_list
22e8c97 lightnvm: move block fold outside of get_bb_tbl()
7f7c5d0 lightnvm: avoid memory leak when lun_map kcalloc fails
5136061 lightnvm: introduce nvm_for_each_lun_ppa() macro
e11903f lightnvm: refactor device ops->get_bb_tbl()
5ebc7d9 lightnvm: make nvm_set_rqd_ppalist() aware of vblks
a63d5cf lightnvm: move responsibility for bad blk mgmt to target
00ee6cc lightnvm: refactor set_bb_tbl for accepting ppa list
003fad3 lightnvm: enable metadata to be sent to device
04a8aa1 lightnvm: expose gennvm_mark_blk to targets


These commits can not be reverted cleanly. 

Re: linux-next memleak after IO on dax mountpoint

[Xiong Zhou]

On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote:
...
> Still working on to id which commit in this merge causes this issuer,

Narrowed down to:

37e5823 block: add offset in blk_add_request_payload()
e048948 blk-mq: Export tagset iter function
58b4560 nvme: add helper nvme_map_len()
03b5929 nvme: rewrite discard support
8093f7c nvme: add helper nvme_setup_cmd()
21f033f NVMe: Skip async events for degraded controllers
82b4552 nvme: Use blk-mq helper for IO termination
93e9d8e block: add ability to flag write back caching on a device
519a7e1 dm: switch to using blk_queue_write_cache()
bb8d261 nvme: introduce a controller state machine
92911a5 nvme: tighten up state check for namespace scanning
5955be2 nvme: move namespace scanning to core
f866fc4 nvme: move AER handling to common code
0bf77e9 nvme: switch to RCU freeing the namespace
9082e87 block: remove struct bio_batch
38f2525 block: add __blkdev_issue_discard
57aac2f lightnvm: fix "warning: ‘ret’ may be used uninitialized"
ecfb40c lightnvm: handle submit_io failure
1145e63 lightnvm: implement nvm_submit_ppa_list
22e8c97 lightnvm: move block fold outside of get_bb_tbl()
7f7c5d0 lightnvm: avoid memory leak when lun_map kcalloc fails
5136061 lightnvm: introduce nvm_for_each_lun_ppa() macro
e11903f lightnvm: refactor device ops->get_bb_tbl()
5ebc7d9 lightnvm: make nvm_set_rqd_ppalist() aware of vblks
a63d5cf lightnvm: move responsibility for bad blk mgmt to target
00ee6cc lightnvm: refactor set_bb_tbl for accepting ppa list
003fad3 lightnvm: enable metadata to be sent to device
04a8aa1 lightnvm: expose gennvm_mark_blk to targets


These commits can not be reverted cleanly. 

Re: [PATCH] pv-qspinlock: Try to re-hash the lock after spurious_wakeup

[Waiman Long]

On 05/27/2016 06:32 AM, xinhui wrote:


On 2016年05月27日 02:31, Waiman Long wrote:

On 05/25/2016 02:09 AM, Pan Xinhui wrote:

In pv_wait_head_or_lock, if there is a spurious_wakeup, and it fails to
get the lock as there is lock stealing, then after a short spin, we 
need

hash the lock again and enter pv_wait to yield.

Currently after a spurious_wakeup, as l->locked is not _Q_SLOW_VAL,
pv_wait might do nothing and return directly, that is not
paravirt-friendly because pv_wait_head_or_lock will just spin on the
lock then.

Signed-off-by: Pan Xinhui
---
  kernel/locking/qspinlock_paravirt.h | 39 
+

  1 file changed, 31 insertions(+), 8 deletions(-)


Is this a problem you can easily reproduce on PPC? I have not 
observed this issue when testing on x86.



Hi, Waiman
I notice the spurious_wakeup count is very high when I do 
benchmark tests and stress tests. So after a simple investigation,

I find pv_wait_head_or_lock() just keep loops.



That shouldn't happen in normal case. When testing on x86, I typically 
get the following stat data for an over-commited guest:


pv_lock_slowpath=9256211
pv_lock_stealing=36398363
pv_spurious_wakeup=311
pv_wait_again=294
pv_wait_early=3255605
pv_wait_head=173
pv_wait_node=3256280

The queue head don't call pv_wait that often. There are a bit of 
spurious wakeup, but it is mostly caused by lock stealing. How long is a 
cpu_relax() in PPC takes?


Here is my story, in my pv-qspinlcok patchset V1&, pv_wait on 
ppc ignore the first two parameters of *ptr and val, that makes 
lock_stealing hit too much.


The pvqspinlock code does depend on pv_wait() doing a final check to see 
if the lock value change. The code may not work reliably without that.


and when I change SPIN_THRESHOLD to a small value, system is very much 
unstable because waiter will enter pv_wait quickly and no one will 
kick waiter's cpu if

we enter pv_wait twice thanks to the lock_stealing.
So what I do in my pv-qspinlcok patchset V3 is that add if (*ptr 
== val) in pv_wait. However as I mentioned above, then spurious_wakeup 
count is too high, that also means our cpu

slice is wasted.


The SPIN_THRESHOLD should be sufficiently big. A small value will cause 
too many waits and wake-up's which may not be good. Anyway, more testing 
and tuning may be needed to make the pvqspinlock code work well with PPC.


Cheers,
Longman

Re: [PATCH] pv-qspinlock: Try to re-hash the lock after spurious_wakeup

[Waiman Long]

On 05/27/2016 06:32 AM, xinhui wrote:


On 2016年05月27日 02:31, Waiman Long wrote:

On 05/25/2016 02:09 AM, Pan Xinhui wrote:

In pv_wait_head_or_lock, if there is a spurious_wakeup, and it fails to
get the lock as there is lock stealing, then after a short spin, we 
need

hash the lock again and enter pv_wait to yield.

Currently after a spurious_wakeup, as l->locked is not _Q_SLOW_VAL,
pv_wait might do nothing and return directly, that is not
paravirt-friendly because pv_wait_head_or_lock will just spin on the
lock then.

Signed-off-by: Pan Xinhui
---
  kernel/locking/qspinlock_paravirt.h | 39 
+

  1 file changed, 31 insertions(+), 8 deletions(-)


Is this a problem you can easily reproduce on PPC? I have not 
observed this issue when testing on x86.



Hi, Waiman
I notice the spurious_wakeup count is very high when I do 
benchmark tests and stress tests. So after a simple investigation,

I find pv_wait_head_or_lock() just keep loops.



That shouldn't happen in normal case. When testing on x86, I typically 
get the following stat data for an over-commited guest:


pv_lock_slowpath=9256211
pv_lock_stealing=36398363
pv_spurious_wakeup=311
pv_wait_again=294
pv_wait_early=3255605
pv_wait_head=173
pv_wait_node=3256280

The queue head don't call pv_wait that often. There are a bit of 
spurious wakeup, but it is mostly caused by lock stealing. How long is a 
cpu_relax() in PPC takes?


Here is my story, in my pv-qspinlcok patchset V1&, pv_wait on 
ppc ignore the first two parameters of *ptr and val, that makes 
lock_stealing hit too much.


The pvqspinlock code does depend on pv_wait() doing a final check to see 
if the lock value change. The code may not work reliably without that.


and when I change SPIN_THRESHOLD to a small value, system is very much 
unstable because waiter will enter pv_wait quickly and no one will 
kick waiter's cpu if

we enter pv_wait twice thanks to the lock_stealing.
So what I do in my pv-qspinlcok patchset V3 is that add if (*ptr 
== val) in pv_wait. However as I mentioned above, then spurious_wakeup 
count is too high, that also means our cpu

slice is wasted.


The SPIN_THRESHOLD should be sufficiently big. A small value will cause 
too many waits and wake-up's which may not be good. Anyway, more testing 
and tuning may be needed to make the pvqspinlock code work well with PPC.


Cheers,
Longman

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

[Peter Chen]

On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote:
> + Arnd
> 
> [...]
> 
> >> >> Solution
> >> >> 
> >> >> This is very similar to the MMC pwrseq behavior so the idea is to:
> >> >> 1. Move MMC pwrseq drivers to generic place,
> >> >
> >> > You can do that, but I'm going to NAK any use of pwrseq bindings outside
> >> > of MMC. I think it is the wrong way to do things. The DT should describe
> >>
> >> Huh, I didn't know that was your view of the mmc pwrseq bindings. Why
> >> didn't you NAK them before?
> >
> > Unfortunately, either I missed it or it was a time I couldn't spend much
> > time on reviews.
> 
> Okay, I guess it's common issue among maintainers. The problem with DT
> is that it gets really hard to be fixed up later. :-)
> 
> >
> >> > the devices. If they happen to be "simple" then the core can walk the
> >> > tree and do any setup. For example, look for "reset-gpios" and toggle
> >> > that GPIO. There is no need for a special node.
> >> >
> >> >> 2. Extend the pwrseq-simple with regulator toggling,
> >> >> 3. Add support to USB hub and port core for pwrseq,
> >> >
> >> > We discussed this for USB already[1] and is why we defined how to add
> >> > USB child devices. The idea is not to add pwrseq to that.
> >>
> >> I am not familiar with the USB discussion.
> >>
> >> Still, let me give you some more background to the mmc pwrseq. The
> >> idea from the mmc pwrseq bindings comes from the power-domain DT
> >> bindings, as I thought these things were a bit related.
> >> In both cases they are not directly a property of the device, but more
> >> describing a HW dependency to allow the device to work.
> >
> > I could see this as a board level power domain. However the difference
> > is we are not generally exposing internal SOC details the same way as
> > board level components. Perhaps we could extend power domains to board
> > level, but that is not what was done here.
> >
> >> One could probably use a child node instead of a phandle, but that
> >> wasn't chosen back then. Of course you are the DT expert, but could
> >> you perhaps tell me why a child node is better for cases like this?
> >
> > If there is a control path hierarchy, then we try to model that in DT
> > with child nodes. In cases of SDIO and USB, there is a clear hierarchy.
> > Ignoring the discovery ordering problem, we already have defined ways to
> > describe GPIO connections, regulators, etc. to devices. Describing those
> > things separately from the device to solve a particular issue that is
> > really a kernel limitation is what I don't like.
> 
> Okay, I see.
> 
> To move forward in trying to make mmc pwrseq a generic pwrseq, could
> we perhaps allow both cases?
> 
> In the mmc case, there are already deployed bindings so we need to
> cope with these by using the phandle option, but for USB etc we could
> force the child node option.
> As long as we agree that we keep using a compatible string for the
> child node as well, both options should be able to co-exist and we
> should probably be able to managed them both from a common pwrseq
> driver framework.
> 
> Although, I do remember from an older conversations around some of
> mine submission for the mmc pwrseq code, that some people (maybe
> Arnd?) wasn't keen on adding a new framework for this. Perhaps that
> has changed?
> 

All, how we move on for this?

1. Using a generic driver to manage both mmc and USB (and further
subsystem), USB and further subsystem do not use pwrseq node in dts.
2. USB creates the similar driver under drivers/usb for its own use. 

Which one do you prefer, thanks.

-- 

Best Regards,
Peter Chen

Re: [RFC v2 00/13] usb/mmc/power: Fix USB/LAN when TFTP booting

[Peter Chen]

On Tue, May 10, 2016 at 01:02:08PM +0200, Ulf Hansson wrote:
> + Arnd
> 
> [...]
> 
> >> >> Solution
> >> >> 
> >> >> This is very similar to the MMC pwrseq behavior so the idea is to:
> >> >> 1. Move MMC pwrseq drivers to generic place,
> >> >
> >> > You can do that, but I'm going to NAK any use of pwrseq bindings outside
> >> > of MMC. I think it is the wrong way to do things. The DT should describe
> >>
> >> Huh, I didn't know that was your view of the mmc pwrseq bindings. Why
> >> didn't you NAK them before?
> >
> > Unfortunately, either I missed it or it was a time I couldn't spend much
> > time on reviews.
> 
> Okay, I guess it's common issue among maintainers. The problem with DT
> is that it gets really hard to be fixed up later. :-)
> 
> >
> >> > the devices. If they happen to be "simple" then the core can walk the
> >> > tree and do any setup. For example, look for "reset-gpios" and toggle
> >> > that GPIO. There is no need for a special node.
> >> >
> >> >> 2. Extend the pwrseq-simple with regulator toggling,
> >> >> 3. Add support to USB hub and port core for pwrseq,
> >> >
> >> > We discussed this for USB already[1] and is why we defined how to add
> >> > USB child devices. The idea is not to add pwrseq to that.
> >>
> >> I am not familiar with the USB discussion.
> >>
> >> Still, let me give you some more background to the mmc pwrseq. The
> >> idea from the mmc pwrseq bindings comes from the power-domain DT
> >> bindings, as I thought these things were a bit related.
> >> In both cases they are not directly a property of the device, but more
> >> describing a HW dependency to allow the device to work.
> >
> > I could see this as a board level power domain. However the difference
> > is we are not generally exposing internal SOC details the same way as
> > board level components. Perhaps we could extend power domains to board
> > level, but that is not what was done here.
> >
> >> One could probably use a child node instead of a phandle, but that
> >> wasn't chosen back then. Of course you are the DT expert, but could
> >> you perhaps tell me why a child node is better for cases like this?
> >
> > If there is a control path hierarchy, then we try to model that in DT
> > with child nodes. In cases of SDIO and USB, there is a clear hierarchy.
> > Ignoring the discovery ordering problem, we already have defined ways to
> > describe GPIO connections, regulators, etc. to devices. Describing those
> > things separately from the device to solve a particular issue that is
> > really a kernel limitation is what I don't like.
> 
> Okay, I see.
> 
> To move forward in trying to make mmc pwrseq a generic pwrseq, could
> we perhaps allow both cases?
> 
> In the mmc case, there are already deployed bindings so we need to
> cope with these by using the phandle option, but for USB etc we could
> force the child node option.
> As long as we agree that we keep using a compatible string for the
> child node as well, both options should be able to co-exist and we
> should probably be able to managed them both from a common pwrseq
> driver framework.
> 
> Although, I do remember from an older conversations around some of
> mine submission for the mmc pwrseq code, that some people (maybe
> Arnd?) wasn't keen on adding a new framework for this. Perhaps that
> has changed?
> 

All, how we move on for this?

1. Using a generic driver to manage both mmc and USB (and further
subsystem), USB and further subsystem do not use pwrseq node in dts.
2. USB creates the similar driver under drivers/usb for its own use. 

Which one do you prefer, thanks.

-- 

Best Regards,
Peter Chen

[GIT PULL] target updates for v4.7-rc1

[Nicholas A. Bellinger]

Hi Linus,

Here are the outstanding target pending updates for v4.7-rc1.

Please go ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next

The highlights this round include:

- Allow external PR/ALUA metadata path be defined at runtime via
  top level configfs attribute. (Lee)
- Fix target session shutdown bug for ib_srpt multi-channel. (hch)
- Make TFO close_session() and shutdown_session() optional. (hch)
- Drop se_sess->sess_kref + convert tcm_qla2xxx to internal kref. (hch)
- Add tcm_qla2xxx endpoint attribute for basic FC jammer. (Laurence)
- Refactor iscsi-target RX/TX PDU encode/decode into common code. (Varun)
- Extend iscsit_transport with xmit_pdu, release_cmd, get_rx_pdu,
  validate_parameters, and get_r2t_ttt for generic ISO offload. (Varun)
- Initial merge of cxgb iscsi-segment offload target driver. (Varun)

The bulk of the changes are Chelsio's new driver, along with a number of
iscsi-target common code improvements made by Varun + Co along the way.

Thank you,

--nab

Christoph Hellwig (7):
  target: consolidate and fix session shutdown
  target: remove acl_stop
  target: make ->shutdown_session optional
  target: make close_session optional
  tcm_qla2xxx: introduce a private sess_kref
  iscsi-target: remove usage of ->shutdown_session
  target: remove sess_kref and ->shutdown_session

Colin Ian King (1):
  target: need_to_release is always false, remove redundant check and
kfree

Imran Haider (1):
  iscsi-target: graceful disconnect on invalid mapping to iovec

Laurence Oberman (1):
  tcm_qla2xxx Add SCSI command jammer/discard capability

Lee Duncan (2):
  target: make target db location configurable
  target: use new "dbroot" target attribute

Nicholas Bellinger (4):
  iscsi-target: Make iscsi_tpg_np driver show/store use generic code
  iscsi-target: Convert transport drivers to signal rdma_shutdown
  cxgbit: Use type ISCSI_CXGBIT + cxgbit tpg_np attribute
  iscsi-target: Fix early sk_data_ready LOGIN_FLAGS_READY race

Varun Prakash (13):
  iscsi-target: add int (*iscsit_xmit_pdu)()
  iscsi-target: add void (*iscsit_release_cmd)()
  iscsi-target: add void (*iscsit_get_rx_pdu)()
  iscsi-target: split iscsi_target_rx_thread()
  iscsi-target: add int (*iscsit_validate_params)()
  iscsi-target: add void (*iscsit_get_r2t_ttt)()
  iscsi-target: move iscsit_thread_check_cpumask()
  iscsi-target: use conn_transport->transport_type in text rsp
  iscsi-target: add new offload transport type
  iscsi-target: clear tx_thread_active
  iscsi-target: call complete on conn_logout_comp
  iscsi-target: export symbols
  cxgbit: add files for cxgbit.ko

 Documentation/scsi/tcm_qla2xxx.txt|   22 +
 Documentation/target/tcm_mod_builder.py   |   16 -
 drivers/infiniband/ulp/isert/ib_isert.c   |   11 +
 drivers/infiniband/ulp/srpt/ib_srpt.c |9 -
 drivers/scsi/qla2xxx/Kconfig  |9 +
 drivers/scsi/qla2xxx/qla_target.c |   56 +-
 drivers/scsi/qla2xxx/qla_target.h |4 +-
 drivers/scsi/qla2xxx/tcm_qla2xxx.c|   59 +-
 drivers/scsi/qla2xxx/tcm_qla2xxx.h|1 +
 drivers/target/iscsi/Kconfig  |2 +
 drivers/target/iscsi/Makefile |1 +
 drivers/target/iscsi/cxgbit/Kconfig   |7 +
 drivers/target/iscsi/cxgbit/Makefile  |6 +
 drivers/target/iscsi/cxgbit/cxgbit.h  |  353 
 drivers/target/iscsi/cxgbit/cxgbit_cm.c   | 2086 +
 drivers/target/iscsi/cxgbit/cxgbit_ddp.c  |  325 
 drivers/target/iscsi/cxgbit/cxgbit_lro.h  |   72 +
 drivers/target/iscsi/cxgbit/cxgbit_main.c |  702 +++
 drivers/target/iscsi/cxgbit/cxgbit_target.c   | 1561 +++
 drivers/target/iscsi/iscsi_target.c   |  701 +++
 drivers/target/iscsi/iscsi_target_configfs.c  |  158 +-
 drivers/target/iscsi/iscsi_target_datain_values.c |1 +
 drivers/target/iscsi/iscsi_target_erl0.c  |2 +-
 drivers/target/iscsi/iscsi_target_login.c |   17 +-
 drivers/target/iscsi/iscsi_target_nego.c  |   19 +-
 drivers/target/iscsi/iscsi_target_parameters.c|1 +
 drivers/target/iscsi/iscsi_target_util.c  |5 +
 drivers/target/loopback/tcm_loop.c|   12 -
 drivers/target/sbp/sbp_target.c   |   12 -
 drivers/target/target_core_alua.c |6 +-
 drivers/target/target_core_configfs.c |   70 +-
 drivers/target/target_core_internal.h |6 +
 drivers/target/target_core_pr.c   |2 +-
 drivers/target/target_core_rd.c   |4 -
 drivers/target/target_core_tpg.c  |   83 +-
 drivers/target/target_core_transport.c|   26 +-
 drivers/target/tcm_fc/tcm_fc.h|1 -
 drivers/target/tcm_fc/tfc_conf.c  |1 -
 

[GIT PULL] target updates for v4.7-rc1

[Nicholas A. Bellinger]

Hi Linus,

Here are the outstanding target pending updates for v4.7-rc1.

Please go ahead and pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next

The highlights this round include:

- Allow external PR/ALUA metadata path be defined at runtime via
  top level configfs attribute. (Lee)
- Fix target session shutdown bug for ib_srpt multi-channel. (hch)
- Make TFO close_session() and shutdown_session() optional. (hch)
- Drop se_sess->sess_kref + convert tcm_qla2xxx to internal kref. (hch)
- Add tcm_qla2xxx endpoint attribute for basic FC jammer. (Laurence)
- Refactor iscsi-target RX/TX PDU encode/decode into common code. (Varun)
- Extend iscsit_transport with xmit_pdu, release_cmd, get_rx_pdu,
  validate_parameters, and get_r2t_ttt for generic ISO offload. (Varun)
- Initial merge of cxgb iscsi-segment offload target driver. (Varun)

The bulk of the changes are Chelsio's new driver, along with a number of
iscsi-target common code improvements made by Varun + Co along the way.

Thank you,

--nab

Christoph Hellwig (7):
  target: consolidate and fix session shutdown
  target: remove acl_stop
  target: make ->shutdown_session optional
  target: make close_session optional
  tcm_qla2xxx: introduce a private sess_kref
  iscsi-target: remove usage of ->shutdown_session
  target: remove sess_kref and ->shutdown_session

Colin Ian King (1):
  target: need_to_release is always false, remove redundant check and
kfree

Imran Haider (1):
  iscsi-target: graceful disconnect on invalid mapping to iovec

Laurence Oberman (1):
  tcm_qla2xxx Add SCSI command jammer/discard capability

Lee Duncan (2):
  target: make target db location configurable
  target: use new "dbroot" target attribute

Nicholas Bellinger (4):
  iscsi-target: Make iscsi_tpg_np driver show/store use generic code
  iscsi-target: Convert transport drivers to signal rdma_shutdown
  cxgbit: Use type ISCSI_CXGBIT + cxgbit tpg_np attribute
  iscsi-target: Fix early sk_data_ready LOGIN_FLAGS_READY race

Varun Prakash (13):
  iscsi-target: add int (*iscsit_xmit_pdu)()
  iscsi-target: add void (*iscsit_release_cmd)()
  iscsi-target: add void (*iscsit_get_rx_pdu)()
  iscsi-target: split iscsi_target_rx_thread()
  iscsi-target: add int (*iscsit_validate_params)()
  iscsi-target: add void (*iscsit_get_r2t_ttt)()
  iscsi-target: move iscsit_thread_check_cpumask()
  iscsi-target: use conn_transport->transport_type in text rsp
  iscsi-target: add new offload transport type
  iscsi-target: clear tx_thread_active
  iscsi-target: call complete on conn_logout_comp
  iscsi-target: export symbols
  cxgbit: add files for cxgbit.ko

 Documentation/scsi/tcm_qla2xxx.txt|   22 +
 Documentation/target/tcm_mod_builder.py   |   16 -
 drivers/infiniband/ulp/isert/ib_isert.c   |   11 +
 drivers/infiniband/ulp/srpt/ib_srpt.c |9 -
 drivers/scsi/qla2xxx/Kconfig  |9 +
 drivers/scsi/qla2xxx/qla_target.c |   56 +-
 drivers/scsi/qla2xxx/qla_target.h |4 +-
 drivers/scsi/qla2xxx/tcm_qla2xxx.c|   59 +-
 drivers/scsi/qla2xxx/tcm_qla2xxx.h|1 +
 drivers/target/iscsi/Kconfig  |2 +
 drivers/target/iscsi/Makefile |1 +
 drivers/target/iscsi/cxgbit/Kconfig   |7 +
 drivers/target/iscsi/cxgbit/Makefile  |6 +
 drivers/target/iscsi/cxgbit/cxgbit.h  |  353 
 drivers/target/iscsi/cxgbit/cxgbit_cm.c   | 2086 +
 drivers/target/iscsi/cxgbit/cxgbit_ddp.c  |  325 
 drivers/target/iscsi/cxgbit/cxgbit_lro.h  |   72 +
 drivers/target/iscsi/cxgbit/cxgbit_main.c |  702 +++
 drivers/target/iscsi/cxgbit/cxgbit_target.c   | 1561 +++
 drivers/target/iscsi/iscsi_target.c   |  701 +++
 drivers/target/iscsi/iscsi_target_configfs.c  |  158 +-
 drivers/target/iscsi/iscsi_target_datain_values.c |1 +
 drivers/target/iscsi/iscsi_target_erl0.c  |2 +-
 drivers/target/iscsi/iscsi_target_login.c |   17 +-
 drivers/target/iscsi/iscsi_target_nego.c  |   19 +-
 drivers/target/iscsi/iscsi_target_parameters.c|1 +
 drivers/target/iscsi/iscsi_target_util.c  |5 +
 drivers/target/loopback/tcm_loop.c|   12 -
 drivers/target/sbp/sbp_target.c   |   12 -
 drivers/target/target_core_alua.c |6 +-
 drivers/target/target_core_configfs.c |   70 +-
 drivers/target/target_core_internal.h |6 +
 drivers/target/target_core_pr.c   |2 +-
 drivers/target/target_core_rd.c   |4 -
 drivers/target/target_core_tpg.c  |   83 +-
 drivers/target/target_core_transport.c|   26 +-
 drivers/target/tcm_fc/tcm_fc.h|1 -
 drivers/target/tcm_fc/tfc_conf.c  |1 -
 

Re: [PATCH v4] platform/chrome: Add Chrome OS keyboard backlight LEDs support

[Olof Johansson]

On Fri, May 27, 2016 at 5:34 PM, Dmitry Torokhov
 wrote:
> On Wed, May 11, 2016 at 11:06 AM, Olof Johansson  wrote:
>> On Wed, Mar 09, 2016 at 04:25:21PM -0800, Dmitry Torokhov wrote:
>>> From: Simon Que 
>>>
>>> This is a driver for ACPI-based keyboard backlight LEDs found on
>>> Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports
>>> backlight as "chromeos::kbd_backlight" LED class device in sysfs.
>>>
>>> Signed-off-by: Simon Que 
>>> Signed-off-by: Duncan Laurie 
>>> Tested-by: Evan McClain 
>>> Signed-off-by: Dmitry Torokhov 
>>> ---
>>>
>>> Changes from previous submissions:
>>>
>>> v3->v4:
>>> - resend with proper authorship information
>>
>> Ack. Applied v3, fixing up author.
>
> Any chance it will make 4.7?

Yep.


-Olof

Re: [PATCH v4] platform/chrome: Add Chrome OS keyboard backlight LEDs support

[Olof Johansson]

On Fri, May 27, 2016 at 5:34 PM, Dmitry Torokhov
 wrote:
> On Wed, May 11, 2016 at 11:06 AM, Olof Johansson  wrote:
>> On Wed, Mar 09, 2016 at 04:25:21PM -0800, Dmitry Torokhov wrote:
>>> From: Simon Que 
>>>
>>> This is a driver for ACPI-based keyboard backlight LEDs found on
>>> Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports
>>> backlight as "chromeos::kbd_backlight" LED class device in sysfs.
>>>
>>> Signed-off-by: Simon Que 
>>> Signed-off-by: Duncan Laurie 
>>> Tested-by: Evan McClain 
>>> Signed-off-by: Dmitry Torokhov 
>>> ---
>>>
>>> Changes from previous submissions:
>>>
>>> v3->v4:
>>> - resend with proper authorship information
>>
>> Ack. Applied v3, fixing up author.
>
> Any chance it will make 4.7?

Yep.


-Olof

Re: [PATCH] Revert "platform/chrome: chromeos_laptop: Add Leon Touch"

[Olof Johansson]

On Thu, May 26, 2016 at 4:07 AM, Enric Balletbo i Serra
 wrote:
> Hi Benson, Olof
>
> On 26/05/16 03:59, Benson Leung wrote:
>> This reverts commit bff3c624dc7261a084a4d25a0b09c3fb0fec872a.
>>
>> Board "Leon" is otherwise known as "Toshiba CB35" and we already have
>> the entry that supports that board as of this commit :
>> 963cb6f platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch
>>
>> Remove this duplicate.
>>
>> Signed-off-by: Benson Leung 
>> ---
>>  drivers/platform/chrome/chromeos_laptop.c | 15 ---
>>  1 file changed, 15 deletions(-)
>>
>> diff --git a/drivers/platform/chrome/chromeos_laptop.c 
>> b/drivers/platform/chrome/chromeos_laptop.c
>> index 8398a7d..e8a44a9 100644
>> --- a/drivers/platform/chrome/chromeos_laptop.c
>> +++ b/drivers/platform/chrome/chromeos_laptop.c
>> @@ -514,13 +514,6 @@ static struct chromeos_laptop cr48 = {
>>   },
>>  };
>>
>> -static struct chromeos_laptop leon = {
>> - .i2c_peripherals = {
>> - /* Touchpad. */
>> - { .add = setup_cyapa_tp, I2C_ADAPTER_DESIGNWARE_0 },
>> - },
>> -};
>> -
>>  #define _CBDD(board_) \
>>   .callback = chromeos_laptop_dmi_matched, \
>>   .driver_data = (void *)_
>> @@ -608,14 +601,6 @@ static struct dmi_system_id chromeos_laptop_dmi_table[] 
>> __initdata = {
>>   },
>>   _CBDD(cr48),
>>   },
>> - {
>> - .ident = "Leon",
>> - .matches = {
>> - DMI_MATCH(DMI_BIOS_VENDOR, "coreboot"),
>> - DMI_MATCH(DMI_PRODUCT_NAME, "Leon"),
>> - },
>> - _CBDD(leon),
>> - },
>>   { }
>>  };
>>  MODULE_DEVICE_TABLE(dmi, chromeos_laptop_dmi_table);
>>
>
> I think my patch is not applied in mainline yet, I'm not sure if Olof has the 
> patch in his working tree but in such case maybe he can simply remove the 
> patch instead of apply and then revert it?
>
> Just an opinion, thanks.

Yeah, good point. Done, even though it meant a full rebase right
before I send the pull request. :-/


-Olof

Re: [PATCH] Revert "platform/chrome: chromeos_laptop: Add Leon Touch"

[Olof Johansson]

On Thu, May 26, 2016 at 4:07 AM, Enric Balletbo i Serra
 wrote:
> Hi Benson, Olof
>
> On 26/05/16 03:59, Benson Leung wrote:
>> This reverts commit bff3c624dc7261a084a4d25a0b09c3fb0fec872a.
>>
>> Board "Leon" is otherwise known as "Toshiba CB35" and we already have
>> the entry that supports that board as of this commit :
>> 963cb6f platform/chrome: chromeos_laptop - Add Toshiba CB35 Touch
>>
>> Remove this duplicate.
>>
>> Signed-off-by: Benson Leung 
>> ---
>>  drivers/platform/chrome/chromeos_laptop.c | 15 ---
>>  1 file changed, 15 deletions(-)
>>
>> diff --git a/drivers/platform/chrome/chromeos_laptop.c 
>> b/drivers/platform/chrome/chromeos_laptop.c
>> index 8398a7d..e8a44a9 100644
>> --- a/drivers/platform/chrome/chromeos_laptop.c
>> +++ b/drivers/platform/chrome/chromeos_laptop.c
>> @@ -514,13 +514,6 @@ static struct chromeos_laptop cr48 = {
>>   },
>>  };
>>
>> -static struct chromeos_laptop leon = {
>> - .i2c_peripherals = {
>> - /* Touchpad. */
>> - { .add = setup_cyapa_tp, I2C_ADAPTER_DESIGNWARE_0 },
>> - },
>> -};
>> -
>>  #define _CBDD(board_) \
>>   .callback = chromeos_laptop_dmi_matched, \
>>   .driver_data = (void *)_
>> @@ -608,14 +601,6 @@ static struct dmi_system_id chromeos_laptop_dmi_table[] 
>> __initdata = {
>>   },
>>   _CBDD(cr48),
>>   },
>> - {
>> - .ident = "Leon",
>> - .matches = {
>> - DMI_MATCH(DMI_BIOS_VENDOR, "coreboot"),
>> - DMI_MATCH(DMI_PRODUCT_NAME, "Leon"),
>> - },
>> - _CBDD(leon),
>> - },
>>   { }
>>  };
>>  MODULE_DEVICE_TABLE(dmi, chromeos_laptop_dmi_table);
>>
>
> I think my patch is not applied in mainline yet, I'm not sure if Olof has the 
> patch in his working tree but in such case maybe he can simply remove the 
> patch instead of apply and then revert it?
>
> Just an opinion, thanks.

Yeah, good point. Done, even though it meant a full rebase right
before I send the pull request. :-/


-Olof

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

[Kees Cook]

On Fri, May 27, 2016 at 4:20 PM, Andy Lutomirski  wrote:
> On May 27, 2016 3:38 PM, "Kees Cook"  wrote:
>>
>> On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski  
>> wrote:
>> > On May 27, 2016 11:42 AM, "Kees Cook"  wrote:
>> >>
>> >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski  
>> >> wrote:
>> >> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook  
>> >> > wrote:
>> >> >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski  
>> >> >> wrote:
>> >> >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook  
>> >> >>> wrote:
>> >>  One problem with seccomp was that ptrace could be used to change a
>> >>  syscall after seccomp filtering had completed. This was a well 
>> >>  documented
>> >>  limitation, and it was recommended to block ptrace when defining a 
>> >>  filter
>> >>  to avoid this problem. This can be quite a limitation for containers 
>> >>  or
>> >>  other places where ptrace is desired even under seccomp filters.
>> >> 
>> >>  Since seccomp filtering has been split into pre-trace and trace 
>> >>  phases
>> >>  (phase1 and phase2 respectively), it's possible to re-run phase1 
>> >>  seccomp
>> >>  after ptrace. This makes that change, and updates the test suite for
>> >>  both SECCOMP_RET_TRACE and PTRACE_SYSCALL manipulation.
>> >> >>>
>> >> >>> I like fixing the hole, but I don't like this fix.
>> >> >>>
>> >> >>> The two-phase seccomp mechanism is messy.  I wrote it because it was a
>> >> >>> huge speedup.  Since then, I've made a ton of changes to the way that
>> >> >>> x86 syscalls work, and there are two relevant effects: the slow path
>> >> >>> is quite fast, and the phase-1-only path isn't really a win any more.
>> >> >>>
>> >> >>> I suggest that we fix the by simplifying the code instead of making it
>> >> >>> even more complicated.  Let's back out the two-phase mechanism (but
>> >> >>> keep the ability for arch code to supply seccomp_data) and then just
>> >> >>> reorder it so that seccomp happens after ptrace.  The result should be
>> >> >>> considerably simpler.  (We'll still have to answer the question of
>> >> >>> what happens when a SECCOMP_RET_TRACE event changes the syscall, but
>> >> >>> maybe the answer is to just let it through -- after all,
>> >> >>> SECCOMP_RET_TRACE might be a request by a tracer to do its own
>> >> >>> internal filtering.)
>> >> >>
>> >> >> I'm really against this. I think seccomp needs to stay first,
>> >> >
>> >> > Why?  What use case is improved with it going first?
>> >>
>> >> I feel that the critical purpose of seccomp is to minimize attack
>> >> surface. To that end, I am strongly against anything coming before it
>> >> in the syscall path. I really do not want ptrace going first, I think
>> >> it's just asking for bugs.
>> >
>> > I disagree in this case.  There's no actual code surface opened up.
>> > If seccomp allows even a single syscall through and there's a ptracer
>> > attached, then the ptrace code is exposed.  As far as ptrace is
>> > concerned, the syscall number is just a number, and ptrace has
>> > basically no awareness of the arguments.
>>
>> No, I completely disagree: there is a significant amount of surface
>> exposed. With a tracer attached there is significantly more happening
>> before the filter would be checked. Even less obvious things like
>> signal delivery, etc get exposed. Seccomp must be first -- this is
>> it's basic design principle. Bugs creep in, unexpected combinations
>> creep in, etc. Seccomp must mitigate this and be first on the syscall
>> path. The paranoia of this design principle must remain in place, even
>> at the expense of some inelegant results.
>
> But this only works if the filter is literally "deny everything".  If
> there is even a single syscall allowed and a ptracer is attached, then
> the whole ptrace machinery is exposed anyway.

That's an excellent point. Thanks for persisting on this, I'm starting
to come around. :)

> Users who are this paranoid about attack surface need to disable
> ptrace, full stop.  If you can do the ptrace(2) syscall, then you can
> invoke all the nasty code paths by yourself, and there is nothing
> seccomp can do about it.  All seccomp can do is prevent ptrace from
> generating a syscall that would otherwise be filtered out.
>
> Let's look at the actual supposed attack surface:
>
> if (unlikely(work & _TIF_SYSCALL_EMU))
> ret = -1L;
>
> if ((ret || test_thread_flag(TIF_SYSCALL_TRACE)) &&
> tracehook_report_syscall_entry(regs))
> ret = -1L;
>
> That's all.

Yeah, looking through this, I see that audit isn't part of this, so
I'm much more relaxed.

> The only way that TIF_SYSCALL_EMU or TIF_SYSCALL_TRACE gets set is if
> a ptracer is attached and uses PTRACE_SYSEMU, PTRACE_SYSCALL or
> similar.  If that has happened, then 

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

[Kees Cook]

On Fri, May 27, 2016 at 4:20 PM, Andy Lutomirski  wrote:
> On May 27, 2016 3:38 PM, "Kees Cook"  wrote:
>>
>> On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski  
>> wrote:
>> > On May 27, 2016 11:42 AM, "Kees Cook"  wrote:
>> >>
>> >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski  
>> >> wrote:
>> >> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook  
>> >> > wrote:
>> >> >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski  
>> >> >> wrote:
>> >> >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook  
>> >> >>> wrote:
>> >>  One problem with seccomp was that ptrace could be used to change a
>> >>  syscall after seccomp filtering had completed. This was a well 
>> >>  documented
>> >>  limitation, and it was recommended to block ptrace when defining a 
>> >>  filter
>> >>  to avoid this problem. This can be quite a limitation for containers 
>> >>  or
>> >>  other places where ptrace is desired even under seccomp filters.
>> >> 
>> >>  Since seccomp filtering has been split into pre-trace and trace 
>> >>  phases
>> >>  (phase1 and phase2 respectively), it's possible to re-run phase1 
>> >>  seccomp
>> >>  after ptrace. This makes that change, and updates the test suite for
>> >>  both SECCOMP_RET_TRACE and PTRACE_SYSCALL manipulation.
>> >> >>>
>> >> >>> I like fixing the hole, but I don't like this fix.
>> >> >>>
>> >> >>> The two-phase seccomp mechanism is messy.  I wrote it because it was a
>> >> >>> huge speedup.  Since then, I've made a ton of changes to the way that
>> >> >>> x86 syscalls work, and there are two relevant effects: the slow path
>> >> >>> is quite fast, and the phase-1-only path isn't really a win any more.
>> >> >>>
>> >> >>> I suggest that we fix the by simplifying the code instead of making it
>> >> >>> even more complicated.  Let's back out the two-phase mechanism (but
>> >> >>> keep the ability for arch code to supply seccomp_data) and then just
>> >> >>> reorder it so that seccomp happens after ptrace.  The result should be
>> >> >>> considerably simpler.  (We'll still have to answer the question of
>> >> >>> what happens when a SECCOMP_RET_TRACE event changes the syscall, but
>> >> >>> maybe the answer is to just let it through -- after all,
>> >> >>> SECCOMP_RET_TRACE might be a request by a tracer to do its own
>> >> >>> internal filtering.)
>> >> >>
>> >> >> I'm really against this. I think seccomp needs to stay first,
>> >> >
>> >> > Why?  What use case is improved with it going first?
>> >>
>> >> I feel that the critical purpose of seccomp is to minimize attack
>> >> surface. To that end, I am strongly against anything coming before it
>> >> in the syscall path. I really do not want ptrace going first, I think
>> >> it's just asking for bugs.
>> >
>> > I disagree in this case.  There's no actual code surface opened up.
>> > If seccomp allows even a single syscall through and there's a ptracer
>> > attached, then the ptrace code is exposed.  As far as ptrace is
>> > concerned, the syscall number is just a number, and ptrace has
>> > basically no awareness of the arguments.
>>
>> No, I completely disagree: there is a significant amount of surface
>> exposed. With a tracer attached there is significantly more happening
>> before the filter would be checked. Even less obvious things like
>> signal delivery, etc get exposed. Seccomp must be first -- this is
>> it's basic design principle. Bugs creep in, unexpected combinations
>> creep in, etc. Seccomp must mitigate this and be first on the syscall
>> path. The paranoia of this design principle must remain in place, even
>> at the expense of some inelegant results.
>
> But this only works if the filter is literally "deny everything".  If
> there is even a single syscall allowed and a ptracer is attached, then
> the whole ptrace machinery is exposed anyway.

That's an excellent point. Thanks for persisting on this, I'm starting
to come around. :)

> Users who are this paranoid about attack surface need to disable
> ptrace, full stop.  If you can do the ptrace(2) syscall, then you can
> invoke all the nasty code paths by yourself, and there is nothing
> seccomp can do about it.  All seccomp can do is prevent ptrace from
> generating a syscall that would otherwise be filtered out.
>
> Let's look at the actual supposed attack surface:
>
> if (unlikely(work & _TIF_SYSCALL_EMU))
> ret = -1L;
>
> if ((ret || test_thread_flag(TIF_SYSCALL_TRACE)) &&
> tracehook_report_syscall_entry(regs))
> ret = -1L;
>
> That's all.

Yeah, looking through this, I see that audit isn't part of this, so
I'm much more relaxed.

> The only way that TIF_SYSCALL_EMU or TIF_SYSCALL_TRACE gets set is if
> a ptracer is attached and uses PTRACE_SYSEMU, PTRACE_SYSCALL or
> similar.  If that has happened, then there's very, very little that
> seccomp can possibly do to reduce attack surface.  First, literally
> any syscall that results in SECCOMP_RET_OK will cause all of the same
> 

Re: [PATCH v2] watchdog: Add a device managed API for watchdog_register_device()

[Guenter Roeck]

On 05/27/2016 08:33 AM, Neil Armstrong wrote:

This helps in reducing code in .remove callbacks and sometimes
dropping .remove callbacks entirely.

Changes since v1 at 
http://lkml.kernel.org/r/1464251510-15554-1-git-send-email-narmstr...@baylibre.com
 :
- Fix brackets in devm_watchdog_register_device()


Hi Neil,

For future patches: Change log after '---', please.


Signed-off-by: Neil Armstrong 


Reviewed-by: Guenter Roeck 

Thanks,
Guenter


---
  Documentation/driver-model/devres.txt |  3 +++
  drivers/watchdog/watchdog_core.c  | 37 +++
  include/linux/watchdog.h  |  3 +++
  3 files changed, 43 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index c63eea0..589296b 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -357,3 +357,6 @@ SLAVE DMA ENGINE

  SPI
devm_spi_register_master()
+
+WATCHDOG
+  devm_watchdog_register_device()
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 981a668..7c5e3dc 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -329,6 +329,43 @@ void watchdog_unregister_device(struct watchdog_device 
*wdd)

  EXPORT_SYMBOL_GPL(watchdog_unregister_device);

+static void devm_watchdog_unregister_device(struct device *dev, void *res)
+{
+   watchdog_unregister_device(*(struct watchdog_device **)res);
+}
+
+/**
+ * devm_watchdog_register_device() - resource managed 
watchdog_register_device()
+ * @dev: device that is registering this watchdog device
+ * @wdd: watchdog device
+ *
+ * Managed watchdog_register_device(). For watchdog device registered by this
+ * function,  watchdog_unregister_device() is automatically called on driver
+ * detach. See watchdog_register_device() for more information.
+ */
+int devm_watchdog_register_device(struct device *dev,
+   struct watchdog_device *wdd)
+{
+   struct watchdog_device **rcwdd;
+   int ret;
+
+   rcwdd = devres_alloc(devm_watchdog_unregister_device, sizeof(*wdd),
+GFP_KERNEL);
+   if (!rcwdd)
+   return -ENOMEM;
+
+   ret = watchdog_register_device(wdd);
+   if (!ret) {
+   *rcwdd = wdd;
+   devres_add(dev, rcwdd);
+   } else {
+   devres_free(rcwdd);
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(devm_watchdog_register_device);
+
  static int __init watchdog_deferred_registration(void)
  {
mutex_lock(_deferred_reg_mutex);
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 51732d6c..6b75e38 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -180,4 +180,7 @@ extern int watchdog_init_timeout(struct watchdog_device 
*wdd,
  extern int watchdog_register_device(struct watchdog_device *);
  extern void watchdog_unregister_device(struct watchdog_device *);

+/* devres register variant */
+int devm_watchdog_register_device(struct device *dev, struct watchdog_device 
*);
+
  #endif  /* ifndef _LINUX_WATCHDOG_H */

Re: [PATCH v2] watchdog: Add a device managed API for watchdog_register_device()

[Guenter Roeck]

On 05/27/2016 08:33 AM, Neil Armstrong wrote:

This helps in reducing code in .remove callbacks and sometimes
dropping .remove callbacks entirely.

Changes since v1 at 
http://lkml.kernel.org/r/1464251510-15554-1-git-send-email-narmstr...@baylibre.com
 :
- Fix brackets in devm_watchdog_register_device()


Hi Neil,

For future patches: Change log after '---', please.


Signed-off-by: Neil Armstrong 


Reviewed-by: Guenter Roeck 

Thanks,
Guenter


---
  Documentation/driver-model/devres.txt |  3 +++
  drivers/watchdog/watchdog_core.c  | 37 +++
  include/linux/watchdog.h  |  3 +++
  3 files changed, 43 insertions(+)

diff --git a/Documentation/driver-model/devres.txt 
b/Documentation/driver-model/devres.txt
index c63eea0..589296b 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -357,3 +357,6 @@ SLAVE DMA ENGINE

  SPI
devm_spi_register_master()
+
+WATCHDOG
+  devm_watchdog_register_device()
diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 981a668..7c5e3dc 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -329,6 +329,43 @@ void watchdog_unregister_device(struct watchdog_device 
*wdd)

  EXPORT_SYMBOL_GPL(watchdog_unregister_device);

+static void devm_watchdog_unregister_device(struct device *dev, void *res)
+{
+   watchdog_unregister_device(*(struct watchdog_device **)res);
+}
+
+/**
+ * devm_watchdog_register_device() - resource managed 
watchdog_register_device()
+ * @dev: device that is registering this watchdog device
+ * @wdd: watchdog device
+ *
+ * Managed watchdog_register_device(). For watchdog device registered by this
+ * function,  watchdog_unregister_device() is automatically called on driver
+ * detach. See watchdog_register_device() for more information.
+ */
+int devm_watchdog_register_device(struct device *dev,
+   struct watchdog_device *wdd)
+{
+   struct watchdog_device **rcwdd;
+   int ret;
+
+   rcwdd = devres_alloc(devm_watchdog_unregister_device, sizeof(*wdd),
+GFP_KERNEL);
+   if (!rcwdd)
+   return -ENOMEM;
+
+   ret = watchdog_register_device(wdd);
+   if (!ret) {
+   *rcwdd = wdd;
+   devres_add(dev, rcwdd);
+   } else {
+   devres_free(rcwdd);
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(devm_watchdog_register_device);
+
  static int __init watchdog_deferred_registration(void)
  {
mutex_lock(_deferred_reg_mutex);
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index 51732d6c..6b75e38 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -180,4 +180,7 @@ extern int watchdog_init_timeout(struct watchdog_device 
*wdd,
  extern int watchdog_register_device(struct watchdog_device *);
  extern void watchdog_unregister_device(struct watchdog_device *);

+/* devres register variant */
+int devm_watchdog_register_device(struct device *dev, struct watchdog_device 
*);
+
  #endif  /* ifndef _LINUX_WATCHDOG_H */

[PATCH 2/4] mfd: cros_ec: add EC_PWM function definitions

[Brian Norris]

The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is
attached to the EC, rather than the main host SoC. The API provides
functionality-based (e.g., keyboard light, backlight) or index-based
addressing of the PWM(s). Duty cycles are represented by a 16-bit value,
where 0 maps to 0% duty cycle and U16_MAX maps to 100%. The period
cannot be controlled.

This command set is more generic than, e.g.,
EC_CMD_PWM_{GET,SET}_KEYBOARD_BACKLIGHT and could possibly used to
replace it on future products.

Let's update the command header to include the definitions.

Signed-off-by: Brian Norris 
---
 include/linux/mfd/cros_ec_commands.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/include/linux/mfd/cros_ec_commands.h 
b/include/linux/mfd/cros_ec_commands.h
index 13b630c10d4c..d673575e0ada 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -949,6 +949,37 @@ struct ec_params_pwm_set_fan_duty {
uint32_t percent;
 } __packed;
 
+#define EC_CMD_PWM_SET_DUTY 0x25
+/* 16 bit duty cycle, 65535 = 100% */
+#define EC_PWM_MAX_DUTY 65535
+
+enum ec_pwm_type {
+   /* All types, indexed by board-specific enum pwm_channel */
+   EC_PWM_TYPE_GENERIC = 0,
+   /* Keyboard backlight */
+   EC_PWM_TYPE_KB_LIGHT,
+   /* Display backlight */
+   EC_PWM_TYPE_DISPLAY_LIGHT,
+   EC_PWM_TYPE_COUNT,
+};
+
+struct ec_params_pwm_set_duty {
+   uint16_t duty; /* Duty cycle, EC_PWM_MAX_DUTY = 100% */
+   uint8_t pwm_type;  /* ec_pwm_type */
+   uint8_t index; /* Type-specific index, or 0 if unique */
+} __packed;
+
+#define EC_CMD_PWM_GET_DUTY 0x26
+
+struct ec_params_pwm_get_duty {
+   uint8_t pwm_type;  /* ec_pwm_type */
+   uint8_t index; /* Type-specific index, or 0 if unique */
+} __packed;
+
+struct ec_response_pwm_get_duty {
+   uint16_t duty; /* Duty cycle, EC_PWM_MAX_DUTY = 100% */
+} __packed;
+
 /*/
 /*
  * Lightbar commands. This looks worse than it is. Since we only use one HOST
-- 
2.8.0.rc3.226.g39d4020

[PATCH 3/4] doc: dt: pwm: add binding for ChromeOS EC PWM

[Brian Norris]

The ChromeOS Embedded Controller can support controlling its attached
PWMs via its host-command interface. The number of supported PWMs varies
on a per-board basis, so we define a "google,max-pwms" property to
handle this. And because the EC only allows specifying the duty cycle
and not the period, we don't specify the period via pwm-cells, and
instead have only support 1 cell -- to specify the index.

Signed-off-by: Brian Norris 
---
 .../devicetree/bindings/pwm/google,cros-ec-pwm.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt 
b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
new file mode 100644
index ..f1c9540fc23f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
@@ -0,0 +1,25 @@
+* PWM controlled by ChromeOS EC
+
+Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller
+(EC) and controlled via a host-command interface.
+
+An EC PWM node should be only found as a sub-node of the EC node (see
+Documentation/devicetree/bindings/mfd/cros-ec.txt).
+
+Required properties:
+- compatible: Must contain "google,cros-ec-pwm"
+- #pwm-cells: Should be 1. The cell specifies the PWM index.
+- google,max-pwms: Specifies the number of PWMs supported by the EC.
+
+Example:
+   cros-ec@0 {
+   compatible = "google,cros-ec-spi";
+
+   ...
+
+   cros_ec_pwm: ec-pwm {
+   compatible = "google,cros-ec-pwm";
+   #pwm-cells = <1>;
+   google,max-pwms = <4>;
+   };
+   };
-- 
2.8.0.rc3.226.g39d4020

[PATCH 2/4] mfd: cros_ec: add EC_PWM function definitions

[Brian Norris]

The EC_CMD_PWM_{GET,SET}_DUTY commands allow us to control a PWM that is
attached to the EC, rather than the main host SoC. The API provides
functionality-based (e.g., keyboard light, backlight) or index-based
addressing of the PWM(s). Duty cycles are represented by a 16-bit value,
where 0 maps to 0% duty cycle and U16_MAX maps to 100%. The period
cannot be controlled.

This command set is more generic than, e.g.,
EC_CMD_PWM_{GET,SET}_KEYBOARD_BACKLIGHT and could possibly used to
replace it on future products.

Let's update the command header to include the definitions.

Signed-off-by: Brian Norris 
---
 include/linux/mfd/cros_ec_commands.h | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/include/linux/mfd/cros_ec_commands.h 
b/include/linux/mfd/cros_ec_commands.h
index 13b630c10d4c..d673575e0ada 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -949,6 +949,37 @@ struct ec_params_pwm_set_fan_duty {
uint32_t percent;
 } __packed;
 
+#define EC_CMD_PWM_SET_DUTY 0x25
+/* 16 bit duty cycle, 65535 = 100% */
+#define EC_PWM_MAX_DUTY 65535
+
+enum ec_pwm_type {
+   /* All types, indexed by board-specific enum pwm_channel */
+   EC_PWM_TYPE_GENERIC = 0,
+   /* Keyboard backlight */
+   EC_PWM_TYPE_KB_LIGHT,
+   /* Display backlight */
+   EC_PWM_TYPE_DISPLAY_LIGHT,
+   EC_PWM_TYPE_COUNT,
+};
+
+struct ec_params_pwm_set_duty {
+   uint16_t duty; /* Duty cycle, EC_PWM_MAX_DUTY = 100% */
+   uint8_t pwm_type;  /* ec_pwm_type */
+   uint8_t index; /* Type-specific index, or 0 if unique */
+} __packed;
+
+#define EC_CMD_PWM_GET_DUTY 0x26
+
+struct ec_params_pwm_get_duty {
+   uint8_t pwm_type;  /* ec_pwm_type */
+   uint8_t index; /* Type-specific index, or 0 if unique */
+} __packed;
+
+struct ec_response_pwm_get_duty {
+   uint16_t duty; /* Duty cycle, EC_PWM_MAX_DUTY = 100% */
+} __packed;
+
 /*/
 /*
  * Lightbar commands. This looks worse than it is. Since we only use one HOST
-- 
2.8.0.rc3.226.g39d4020

[PATCH 3/4] doc: dt: pwm: add binding for ChromeOS EC PWM

[Brian Norris]

The ChromeOS Embedded Controller can support controlling its attached
PWMs via its host-command interface. The number of supported PWMs varies
on a per-board basis, so we define a "google,max-pwms" property to
handle this. And because the EC only allows specifying the duty cycle
and not the period, we don't specify the period via pwm-cells, and
instead have only support 1 cell -- to specify the index.

Signed-off-by: Brian Norris 
---
 .../devicetree/bindings/pwm/google,cros-ec-pwm.txt | 25 ++
 1 file changed, 25 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt

diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt 
b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
new file mode 100644
index ..f1c9540fc23f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
@@ -0,0 +1,25 @@
+* PWM controlled by ChromeOS EC
+
+Google's ChromeOS EC PWM is a simple PWM attached to the Embedded Controller
+(EC) and controlled via a host-command interface.
+
+An EC PWM node should be only found as a sub-node of the EC node (see
+Documentation/devicetree/bindings/mfd/cros-ec.txt).
+
+Required properties:
+- compatible: Must contain "google,cros-ec-pwm"
+- #pwm-cells: Should be 1. The cell specifies the PWM index.
+- google,max-pwms: Specifies the number of PWMs supported by the EC.
+
+Example:
+   cros-ec@0 {
+   compatible = "google,cros-ec-spi";
+
+   ...
+
+   cros_ec_pwm: ec-pwm {
+   compatible = "google,cros-ec-pwm";
+   #pwm-cells = <1>;
+   google,max-pwms = <4>;
+   };
+   };
-- 
2.8.0.rc3.226.g39d4020

[PATCH 0/4] pwm: add support for ChromeOS EC PWM

[Brian Norris]

Hi,

This series adds support for the new ChromeOS EC PWM API, so we can control,
e.g., the backlight when it's attached to the EC. It uses Boris's latest
"atomic" hooks for the PWM API (i.e., the ->apply() callback), which were
recently merged.

It seems nice to have the cros_ec_cmd_xfer_status() helper, which we have
locally in the ChromeOS kernel, and which has been part of another larger patch
series:

https://lkml.org/lkml/2016/4/12/342

So I've picked it into this series as well. Obviously, I don't care which one
is taken, but AFAICT, Tomeu's USB PD series isn't extremely active right now.

As this touches MFD (sort of), drivers/platform/chrome/, and drivers/pwm/, I'm
not sure who it should all go through: Lee, Thierry, or Olof?

Anyway, please review.

Regards,
Brian

Brian Norris (3):
  mfd: cros_ec: add EC_PWM function definitions
  doc: dt: pwm: add binding for ChromeOS EC PWM
  pwm: add ChromeOS EC PWM driver

Tomeu Vizoso (1):
  mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

 .../devicetree/bindings/pwm/google,cros-ec-pwm.txt |  25 +++
 drivers/platform/chrome/cros_ec_proto.c|  15 ++
 drivers/pwm/Kconfig|   7 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-cros-ec.c  | 230 +
 include/linux/mfd/cros_ec.h|  18 ++
 include/linux/mfd/cros_ec_commands.h   |  31 +++
 7 files changed, 327 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
 create mode 100644 drivers/pwm/pwm-cros-ec.c

-- 
2.8.0.rc3.226.g39d4020

[PATCH 4/4] pwm: add ChromeOS EC PWM driver

[Brian Norris]

Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control
one or more PWMs attached to the Embedded Controller. Because the EC
allows us to modify the duty cycle (as a percentage, where U16_MAX is
100%) but not the period, we assign the period a fixed value of
EC_PWM_MAX_DUTY and reject all attempts to change it.

Signed-off-by: Brian Norris 
---
 drivers/pwm/Kconfig   |   7 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-cros-ec.c | 230 ++
 3 files changed, 238 insertions(+)
 create mode 100644 drivers/pwm/pwm-cros-ec.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c182efc62c7b..4f2b16a50f42 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -137,6 +137,13 @@ config PWM_CRC
  Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
  control.
 
+config PWM_CROS_EC
+   tristate "ChromeOS EC PWM driver"
+   depends on MFD_CROS_EC
+   help
+ PWM driver for exposing a PWM attached to the ChromeOS Embedded
+ Controller.
+
 config PWM_EP93XX
tristate "Cirrus Logic EP93xx PWM support"
depends on ARCH_EP93XX
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index dd35bc121a18..ffde923cf3df 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_PWM_BFIN)+= pwm-bfin.o
 obj-$(CONFIG_PWM_BRCMSTB)  += pwm-brcmstb.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
 obj-$(CONFIG_PWM_CRC)  += pwm-crc.o
+obj-$(CONFIG_PWM_CROS_EC)  += pwm-cros-ec.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
 obj-$(CONFIG_PWM_FSL_FTM)  += pwm-fsl-ftm.o
 obj-$(CONFIG_PWM_IMG)  += pwm-img.o
diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
new file mode 100644
index ..cf65e44fe355
--- /dev/null
+++ b/drivers/pwm/pwm-cros-ec.c
@@ -0,0 +1,230 @@
+/*
+ * Copyright (C) 2016 Google, Inc
+ *
+ * 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.
+ *
+ * Expose a PWM controlled by the ChromeOS EC to the host processor.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct cros_ec_pwm_device - Driver data for EC PWM
+ *
+ * @dev: Device node
+ * @ec: Pointer to EC device
+ * @chip: PWM controller chip
+ */
+struct cros_ec_pwm_device {
+   struct device *dev;
+   struct cros_ec_device *ec;
+   struct pwm_chip chip;
+};
+
+static inline struct cros_ec_pwm_device *pwm_to_cros_ec_pwm(struct pwm_chip *c)
+{
+   return container_of(c, struct cros_ec_pwm_device, chip);
+}
+
+static int cros_ec_pwm_set_duty(struct cros_ec_pwm_device *ec_pwm,
+  struct pwm_device *pwm,
+  uint16_t duty)
+{
+   struct cros_ec_device *ec = ec_pwm->ec;
+   struct ec_params_pwm_set_duty *params;
+   struct cros_ec_command *msg;
+   int ret;
+
+   msg = kzalloc(sizeof(*msg) + sizeof(*params), GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+   params = (void *)>data[0];
+
+   msg->version = 0;
+   msg->command = EC_CMD_PWM_SET_DUTY;
+   msg->insize = 0;
+   msg->outsize = sizeof(*params);
+
+   params->duty = duty;
+   params->pwm_type = EC_PWM_TYPE_GENERIC;
+   params->index = pwm->hwpwm;
+
+   ret = cros_ec_cmd_xfer_status(ec, msg);
+   kfree(msg);
+   return ret;
+}
+
+static int cros_ec_pwm_get_duty(struct cros_ec_pwm_device *ec_pwm,
+   struct pwm_device *pwm)
+{
+   struct cros_ec_device *ec = ec_pwm->ec;
+   struct ec_params_pwm_get_duty *params;
+   struct ec_response_pwm_get_duty *resp;
+   struct cros_ec_command *msg;
+   int ret;
+
+   msg = kzalloc(sizeof(*msg) + max(sizeof(*params), sizeof(*resp)),
+   GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+   params = (void *)>data[0];
+   resp = (void *)>data[0];
+
+   msg->version = 0;
+   msg->command = EC_CMD_PWM_GET_DUTY;
+   msg->insize = sizeof(*params);
+   msg->outsize = sizeof(*resp);
+
+   params->pwm_type = EC_PWM_TYPE_GENERIC;
+   params->index = pwm->hwpwm;
+
+   ret = cros_ec_cmd_xfer_status(ec, msg);
+   if (ret < 0)
+   goto out;
+
+   ret = resp->duty;
+
+out:
+   kfree(msg);
+   return ret;
+}
+
+static int cros_ec_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+struct pwm_state *state)
+{
+   struct cros_ec_pwm_device *ec_pwm = pwm_to_cros_ec_pwm(chip);
+
+   /* The EC won't let us change the period */
+   if (state->period != EC_PWM_MAX_DUTY)
+   return -EINVAL;
+
+   return cros_ec_pwm_set_duty(ec_pwm, pwm, state->duty_cycle);
+}
+
+static void 

[PATCH 1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

[Brian Norris]

From: Tomeu Vizoso 

So that callers of cros_ec_cmd_xfer don't have to repeat boilerplate
code when checking for errors from the EC side.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Benson Leung 
Signed-off-by: Brian Norris 
---
Stolen from:
  https://lkml.org/lkml/2016/4/12/342
  https://patchwork.kernel.org/patch/8810001/

 drivers/platform/chrome/cros_ec_proto.c | 15 +++
 include/linux/mfd/cros_ec.h | 18 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index 990308ca384f..75eb90d2e4f9 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -380,3 +380,18 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
return ret;
 }
 EXPORT_SYMBOL(cros_ec_cmd_xfer);
+
+int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
+   struct cros_ec_command *msg)
+{
+   int ret;
+
+   ret = cros_ec_cmd_xfer(ec_dev, msg);
+   if (ret < 0)
+   dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
+   else if (msg->result != EC_RES_SUCCESS)
+   return -EECRESULT - msg->result;
+
+   return ret;
+}
+EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index a677c2bd485c..b43153f1aca5 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -40,6 +40,9 @@
 #define EC_MAX_REQUEST_OVERHEAD1
 #define EC_MAX_RESPONSE_OVERHEAD   2
 
+/* ec_command return value for non-success result from EC */
+#define EECRESULT 1000
+
 /*
  * Command interface between EC and AP, for LPC, I2C and SPI interfaces.
  */
@@ -224,6 +227,21 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
 struct cros_ec_command *msg);
 
 /**
+ * cros_ec_cmd_xfer_status - Send a command to the ChromeOS EC
+ *
+ * This function is identical to cros_ec_cmd_xfer, except it returns succes
+ * status only if both the command was transmitted successfully and the EC
+ * replied with success status. It's not necessary to check msg->result when
+ * using this function.
+ *
+ * @ec_dev: EC device
+ * @msg: Message to write
+ * @return: Num. of bytes transferred on success, <0 on failure
+ */
+int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
+   struct cros_ec_command *msg);
+
+/**
  * cros_ec_remove - Remove a ChromeOS EC
  *
  * Call this to deregister a ChromeOS EC, then clean up any private data.
-- 
2.8.0.rc3.226.g39d4020

[PATCH 0/4] pwm: add support for ChromeOS EC PWM

[Brian Norris]

Hi,

This series adds support for the new ChromeOS EC PWM API, so we can control,
e.g., the backlight when it's attached to the EC. It uses Boris's latest
"atomic" hooks for the PWM API (i.e., the ->apply() callback), which were
recently merged.

It seems nice to have the cros_ec_cmd_xfer_status() helper, which we have
locally in the ChromeOS kernel, and which has been part of another larger patch
series:

https://lkml.org/lkml/2016/4/12/342

So I've picked it into this series as well. Obviously, I don't care which one
is taken, but AFAICT, Tomeu's USB PD series isn't extremely active right now.

As this touches MFD (sort of), drivers/platform/chrome/, and drivers/pwm/, I'm
not sure who it should all go through: Lee, Thierry, or Olof?

Anyway, please review.

Regards,
Brian

Brian Norris (3):
  mfd: cros_ec: add EC_PWM function definitions
  doc: dt: pwm: add binding for ChromeOS EC PWM
  pwm: add ChromeOS EC PWM driver

Tomeu Vizoso (1):
  mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

 .../devicetree/bindings/pwm/google,cros-ec-pwm.txt |  25 +++
 drivers/platform/chrome/cros_ec_proto.c|  15 ++
 drivers/pwm/Kconfig|   7 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/pwm-cros-ec.c  | 230 +
 include/linux/mfd/cros_ec.h|  18 ++
 include/linux/mfd/cros_ec_commands.h   |  31 +++
 7 files changed, 327 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.txt
 create mode 100644 drivers/pwm/pwm-cros-ec.c

-- 
2.8.0.rc3.226.g39d4020

[PATCH 4/4] pwm: add ChromeOS EC PWM driver

[Brian Norris]

Use the new ChromeOS EC EC_CMD_PWM_{GET,SET}_DUTY commands to control
one or more PWMs attached to the Embedded Controller. Because the EC
allows us to modify the duty cycle (as a percentage, where U16_MAX is
100%) but not the period, we assign the period a fixed value of
EC_PWM_MAX_DUTY and reject all attempts to change it.

Signed-off-by: Brian Norris 
---
 drivers/pwm/Kconfig   |   7 ++
 drivers/pwm/Makefile  |   1 +
 drivers/pwm/pwm-cros-ec.c | 230 ++
 3 files changed, 238 insertions(+)
 create mode 100644 drivers/pwm/pwm-cros-ec.c

diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index c182efc62c7b..4f2b16a50f42 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -137,6 +137,13 @@ config PWM_CRC
  Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
  control.
 
+config PWM_CROS_EC
+   tristate "ChromeOS EC PWM driver"
+   depends on MFD_CROS_EC
+   help
+ PWM driver for exposing a PWM attached to the ChromeOS Embedded
+ Controller.
+
 config PWM_EP93XX
tristate "Cirrus Logic EP93xx PWM support"
depends on ARCH_EP93XX
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index dd35bc121a18..ffde923cf3df 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_PWM_BFIN)+= pwm-bfin.o
 obj-$(CONFIG_PWM_BRCMSTB)  += pwm-brcmstb.o
 obj-$(CONFIG_PWM_CLPS711X) += pwm-clps711x.o
 obj-$(CONFIG_PWM_CRC)  += pwm-crc.o
+obj-$(CONFIG_PWM_CROS_EC)  += pwm-cros-ec.o
 obj-$(CONFIG_PWM_EP93XX)   += pwm-ep93xx.o
 obj-$(CONFIG_PWM_FSL_FTM)  += pwm-fsl-ftm.o
 obj-$(CONFIG_PWM_IMG)  += pwm-img.o
diff --git a/drivers/pwm/pwm-cros-ec.c b/drivers/pwm/pwm-cros-ec.c
new file mode 100644
index ..cf65e44fe355
--- /dev/null
+++ b/drivers/pwm/pwm-cros-ec.c
@@ -0,0 +1,230 @@
+/*
+ * Copyright (C) 2016 Google, Inc
+ *
+ * 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.
+ *
+ * Expose a PWM controlled by the ChromeOS EC to the host processor.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * struct cros_ec_pwm_device - Driver data for EC PWM
+ *
+ * @dev: Device node
+ * @ec: Pointer to EC device
+ * @chip: PWM controller chip
+ */
+struct cros_ec_pwm_device {
+   struct device *dev;
+   struct cros_ec_device *ec;
+   struct pwm_chip chip;
+};
+
+static inline struct cros_ec_pwm_device *pwm_to_cros_ec_pwm(struct pwm_chip *c)
+{
+   return container_of(c, struct cros_ec_pwm_device, chip);
+}
+
+static int cros_ec_pwm_set_duty(struct cros_ec_pwm_device *ec_pwm,
+  struct pwm_device *pwm,
+  uint16_t duty)
+{
+   struct cros_ec_device *ec = ec_pwm->ec;
+   struct ec_params_pwm_set_duty *params;
+   struct cros_ec_command *msg;
+   int ret;
+
+   msg = kzalloc(sizeof(*msg) + sizeof(*params), GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+   params = (void *)>data[0];
+
+   msg->version = 0;
+   msg->command = EC_CMD_PWM_SET_DUTY;
+   msg->insize = 0;
+   msg->outsize = sizeof(*params);
+
+   params->duty = duty;
+   params->pwm_type = EC_PWM_TYPE_GENERIC;
+   params->index = pwm->hwpwm;
+
+   ret = cros_ec_cmd_xfer_status(ec, msg);
+   kfree(msg);
+   return ret;
+}
+
+static int cros_ec_pwm_get_duty(struct cros_ec_pwm_device *ec_pwm,
+   struct pwm_device *pwm)
+{
+   struct cros_ec_device *ec = ec_pwm->ec;
+   struct ec_params_pwm_get_duty *params;
+   struct ec_response_pwm_get_duty *resp;
+   struct cros_ec_command *msg;
+   int ret;
+
+   msg = kzalloc(sizeof(*msg) + max(sizeof(*params), sizeof(*resp)),
+   GFP_KERNEL);
+   if (!msg)
+   return -ENOMEM;
+   params = (void *)>data[0];
+   resp = (void *)>data[0];
+
+   msg->version = 0;
+   msg->command = EC_CMD_PWM_GET_DUTY;
+   msg->insize = sizeof(*params);
+   msg->outsize = sizeof(*resp);
+
+   params->pwm_type = EC_PWM_TYPE_GENERIC;
+   params->index = pwm->hwpwm;
+
+   ret = cros_ec_cmd_xfer_status(ec, msg);
+   if (ret < 0)
+   goto out;
+
+   ret = resp->duty;
+
+out:
+   kfree(msg);
+   return ret;
+}
+
+static int cros_ec_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+struct pwm_state *state)
+{
+   struct cros_ec_pwm_device *ec_pwm = pwm_to_cros_ec_pwm(chip);
+
+   /* The EC won't let us change the period */
+   if (state->period != EC_PWM_MAX_DUTY)
+   return -EINVAL;
+
+   return cros_ec_pwm_set_duty(ec_pwm, pwm, state->duty_cycle);
+}
+
+static void cros_ec_pwm_get_state(struct pwm_chip 

[PATCH 1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper

[Brian Norris]

From: Tomeu Vizoso 

So that callers of cros_ec_cmd_xfer don't have to repeat boilerplate
code when checking for errors from the EC side.

Signed-off-by: Tomeu Vizoso 
Reviewed-by: Benson Leung 
Signed-off-by: Brian Norris 
---
Stolen from:
  https://lkml.org/lkml/2016/4/12/342
  https://patchwork.kernel.org/patch/8810001/

 drivers/platform/chrome/cros_ec_proto.c | 15 +++
 include/linux/mfd/cros_ec.h | 18 ++
 2 files changed, 33 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec_proto.c 
b/drivers/platform/chrome/cros_ec_proto.c
index 990308ca384f..75eb90d2e4f9 100644
--- a/drivers/platform/chrome/cros_ec_proto.c
+++ b/drivers/platform/chrome/cros_ec_proto.c
@@ -380,3 +380,18 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
return ret;
 }
 EXPORT_SYMBOL(cros_ec_cmd_xfer);
+
+int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
+   struct cros_ec_command *msg)
+{
+   int ret;
+
+   ret = cros_ec_cmd_xfer(ec_dev, msg);
+   if (ret < 0)
+   dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
+   else if (msg->result != EC_RES_SUCCESS)
+   return -EECRESULT - msg->result;
+
+   return ret;
+}
+EXPORT_SYMBOL(cros_ec_cmd_xfer_status);
diff --git a/include/linux/mfd/cros_ec.h b/include/linux/mfd/cros_ec.h
index a677c2bd485c..b43153f1aca5 100644
--- a/include/linux/mfd/cros_ec.h
+++ b/include/linux/mfd/cros_ec.h
@@ -40,6 +40,9 @@
 #define EC_MAX_REQUEST_OVERHEAD1
 #define EC_MAX_RESPONSE_OVERHEAD   2
 
+/* ec_command return value for non-success result from EC */
+#define EECRESULT 1000
+
 /*
  * Command interface between EC and AP, for LPC, I2C and SPI interfaces.
  */
@@ -224,6 +227,21 @@ int cros_ec_cmd_xfer(struct cros_ec_device *ec_dev,
 struct cros_ec_command *msg);
 
 /**
+ * cros_ec_cmd_xfer_status - Send a command to the ChromeOS EC
+ *
+ * This function is identical to cros_ec_cmd_xfer, except it returns succes
+ * status only if both the command was transmitted successfully and the EC
+ * replied with success status. It's not necessary to check msg->result when
+ * using this function.
+ *
+ * @ec_dev: EC device
+ * @msg: Message to write
+ * @return: Num. of bytes transferred on success, <0 on failure
+ */
+int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
+   struct cros_ec_command *msg);
+
+/**
  * cros_ec_remove - Remove a ChromeOS EC
  *
  * Call this to deregister a ChromeOS EC, then clean up any private data.
-- 
2.8.0.rc3.226.g39d4020

Re: [PATCH] f2fs: fix to redirty page if fail to gc data page

[Chao Yu]

Ping,

On 2016/5/21 13:19, Chao Yu wrote:
> From: Chao Yu 
> 
> If we fail to move data page during foreground GC, we should give another
> chance to writeback that page which was set dirty previously by writer.
> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/gc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 38d56f6..ee213a8 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -653,12 +653,15 @@ static void move_data_page(struct inode *inode, block_t 
> bidx, int gc_type)
>   .page = page,
>   .encrypted_page = NULL,
>   };
> + bool is_dirty = PageDirty(page);
> +
>   set_page_dirty(page);
>   f2fs_wait_on_page_writeback(page, DATA, true);
>   if (clear_page_dirty_for_io(page))
>   inode_dec_dirty_pages(inode);
>   set_cold_data(page);
> - do_write_data_page();
> + if (do_write_data_page() && is_dirty)
> + set_page_dirty(page);
>   clear_cold_data(page);
>   }
>  out:
> 

Re: [PATCH] f2fs: fix to redirty page if fail to gc data page

[Chao Yu]

Ping,

On 2016/5/21 13:19, Chao Yu wrote:
> From: Chao Yu 
> 
> If we fail to move data page during foreground GC, we should give another
> chance to writeback that page which was set dirty previously by writer.
> 
> Signed-off-by: Chao Yu 
> ---
>  fs/f2fs/gc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
> index 38d56f6..ee213a8 100644
> --- a/fs/f2fs/gc.c
> +++ b/fs/f2fs/gc.c
> @@ -653,12 +653,15 @@ static void move_data_page(struct inode *inode, block_t 
> bidx, int gc_type)
>   .page = page,
>   .encrypted_page = NULL,
>   };
> + bool is_dirty = PageDirty(page);
> +
>   set_page_dirty(page);
>   f2fs_wait_on_page_writeback(page, DATA, true);
>   if (clear_page_dirty_for_io(page))
>   inode_dec_dirty_pages(inode);
>   set_cold_data(page);
> - do_write_data_page();
> + if (do_write_data_page() && is_dirty)
> + set_page_dirty(page);
>   clear_cold_data(page);
>   }
>  out:
> 

Re: [PATCH v4] platform/chrome: Add Chrome OS keyboard backlight LEDs support

[Dmitry Torokhov]

On Wed, May 11, 2016 at 11:06 AM, Olof Johansson  wrote:
> On Wed, Mar 09, 2016 at 04:25:21PM -0800, Dmitry Torokhov wrote:
>> From: Simon Que 
>>
>> This is a driver for ACPI-based keyboard backlight LEDs found on
>> Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports
>> backlight as "chromeos::kbd_backlight" LED class device in sysfs.
>>
>> Signed-off-by: Simon Que 
>> Signed-off-by: Duncan Laurie 
>> Tested-by: Evan McClain 
>> Signed-off-by: Dmitry Torokhov 
>> ---
>>
>> Changes from previous submissions:
>>
>> v3->v4:
>> - resend with proper authorship information
>
> Ack. Applied v3, fixing up author.

Any chance it will make 4.7?

Thanks.

-- 
Dmitry

Re: [PATCH v4] platform/chrome: Add Chrome OS keyboard backlight LEDs support

[Dmitry Torokhov]

On Wed, May 11, 2016 at 11:06 AM, Olof Johansson  wrote:
> On Wed, Mar 09, 2016 at 04:25:21PM -0800, Dmitry Torokhov wrote:
>> From: Simon Que 
>>
>> This is a driver for ACPI-based keyboard backlight LEDs found on
>> Chromebooks. The driver locates \\_SB.KBLT ACPI device and exports
>> backlight as "chromeos::kbd_backlight" LED class device in sysfs.
>>
>> Signed-off-by: Simon Que 
>> Signed-off-by: Duncan Laurie 
>> Tested-by: Evan McClain 
>> Signed-off-by: Dmitry Torokhov 
>> ---
>>
>> Changes from previous submissions:
>>
>> v3->v4:
>> - resend with proper authorship information
>
> Ack. Applied v3, fixing up author.

Any chance it will make 4.7?

Thanks.

-- 
Dmitry

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

[Linus Torvalds]

On Fri, May 27, 2016 at 5:17 PM, Boris Ostrovsky
 wrote:
>
> It does fix it.

Ok, I've committed that in my tree, will do my usual build test and push out.

> This is not the first time we've hit this and people have always been
> changing code to initialize fields in execution path (and I didn't fix
> it here myself because I wasn't sure where to do that).  I guess we
> could have been just adding braces all along.

Well, adding the braces also requires that you get the *order* of the
member initialization right, since the braces will be unnamed.

In this case, the unnamed union was the first member, so the trivial
patch worked, but that's not always the case.

In fact, in this case, I think an alternate and possibly better fix
would have been to just remove the ".data = { 0 }" initializer
entirely, since in its absence it would have been initialized to zero
anyway.

But since you already tested my uglier "just add a brace like the
error message suggests" that's the one I'll be committing.

It's a fairly annoying failure of older compilers, exactly because
people with newer compilers won't even realize that they are causing
problems.

   Linus

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

[Linus Torvalds]

On Fri, May 27, 2016 at 5:17 PM, Boris Ostrovsky
 wrote:
>
> It does fix it.

Ok, I've committed that in my tree, will do my usual build test and push out.

> This is not the first time we've hit this and people have always been
> changing code to initialize fields in execution path (and I didn't fix
> it here myself because I wasn't sure where to do that).  I guess we
> could have been just adding braces all along.

Well, adding the braces also requires that you get the *order* of the
member initialization right, since the braces will be unnamed.

In this case, the unnamed union was the first member, so the trivial
patch worked, but that's not always the case.

In fact, in this case, I think an alternate and possibly better fix
would have been to just remove the ".data = { 0 }" initializer
entirely, since in its absence it would have been initialized to zero
anyway.

But since you already tested my uglier "just add a brace like the
error message suggests" that's the one I'll be committing.

It's a fairly annoying failure of older compilers, exactly because
people with newer compilers won't even realize that they are causing
problems.

   Linus

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

[yunhong jiang]

On Fri, 27 May 2016 11:49:26 +0200
Paolo Bonzini  wrote:

> 
> 
> On 26/05/2016 22:33, yunhong jiang wrote:
> > On Thu, 26 May 2016 12:26:27 +0200
> > Paolo Bonzini  wrote:
> > 
> >>
> >>
> >> On 25/05/2016 04:47, Wanpeng Li wrote:
> >>> From: Wanpeng Li 
> >>>
> >>> If an emulated lapic timer will fire soon(in the scope of 10us the
> >>> base of dynamic halt-polling, lower-end of message passing
> >>> workload latency TCP_RR's poll time < 10us) we can treat it as a
> >>> short halt, and poll to wait it fire, the fire callback
> >>> apic_timer_fn() will set KVM_REQ_PENDING_TIMER, and this flag
> >>> will be check during busy poll. This can avoid context switch
> >>> overhead and the latency which we wake up vCPU.
> >>
> >> As discussed on IRC, I would like to understand why the adaptive
> > 
> > Glad to know the IRC channel. Is #kvm channel on freenode the IRC
> > you are talking about?
> 
> No, it's #qemu on irc.oftc.net

Thanks for the information.

--jyh

> 
> Thanks,
> 
> Paolo

Re: [PATCH v5] KVM: halt-polling: poll for the upcoming fire timers

[yunhong jiang]

On Fri, 27 May 2016 11:49:26 +0200
Paolo Bonzini  wrote:

> 
> 
> On 26/05/2016 22:33, yunhong jiang wrote:
> > On Thu, 26 May 2016 12:26:27 +0200
> > Paolo Bonzini  wrote:
> > 
> >>
> >>
> >> On 25/05/2016 04:47, Wanpeng Li wrote:
> >>> From: Wanpeng Li 
> >>>
> >>> If an emulated lapic timer will fire soon(in the scope of 10us the
> >>> base of dynamic halt-polling, lower-end of message passing
> >>> workload latency TCP_RR's poll time < 10us) we can treat it as a
> >>> short halt, and poll to wait it fire, the fire callback
> >>> apic_timer_fn() will set KVM_REQ_PENDING_TIMER, and this flag
> >>> will be check during busy poll. This can avoid context switch
> >>> overhead and the latency which we wake up vCPU.
> >>
> >> As discussed on IRC, I would like to understand why the adaptive
> > 
> > Glad to know the IRC channel. Is #kvm channel on freenode the IRC
> > you are talking about?
> 
> No, it's #qemu on irc.oftc.net

Thanks for the information.

--jyh

> 
> Thanks,
> 
> Paolo

[git pull] Input updates for 4.7-rc0 (part 2)

[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. Just a few more driver
fixes; new drivers will be coming in the next merge window.

There will be a trivial conflict in drivers/input/misc/pwm-beeper.c,
please keep both parts so you'll end up with the following chunk:

/*
 * FIXME: pwm_apply_args() should be removed when switching to
 * the atomic PWM API.
 */
pwm_apply_args(beeper->pwm);

INIT_WORK(>work, pwm_beeper_work);


Changelog:
-

Cameron Gutman (1):
  Input: xpad - prevent spurious input from wired Xbox 360 controllers

Manfred Schlaegl (1):
  Input: pwm-beeper - fix - scheduling while atomic

Pavel Rojtberg (3):
  Input: xpad - move pending clear to the correct location
  Input: xpad - add more third-party controllers
  Input: xpad - xbox one elite controller support

Ricky Liang (1):
  Input: uinput - handle compat ioctl for UI_SET_PHYS


Diffstat:


 drivers/input/joystick/xpad.c   | 18 +--
 drivers/input/misc/pwm-beeper.c | 69 -
 drivers/input/misc/uinput.c |  6 
 3 files changed, 70 insertions(+), 23 deletions(-)

-- 
Dmitry

[git pull] Input updates for 4.7-rc0 (part 2)

[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. Just a few more driver
fixes; new drivers will be coming in the next merge window.

There will be a trivial conflict in drivers/input/misc/pwm-beeper.c,
please keep both parts so you'll end up with the following chunk:

/*
 * FIXME: pwm_apply_args() should be removed when switching to
 * the atomic PWM API.
 */
pwm_apply_args(beeper->pwm);

INIT_WORK(>work, pwm_beeper_work);


Changelog:
-

Cameron Gutman (1):
  Input: xpad - prevent spurious input from wired Xbox 360 controllers

Manfred Schlaegl (1):
  Input: pwm-beeper - fix - scheduling while atomic

Pavel Rojtberg (3):
  Input: xpad - move pending clear to the correct location
  Input: xpad - add more third-party controllers
  Input: xpad - xbox one elite controller support

Ricky Liang (1):
  Input: uinput - handle compat ioctl for UI_SET_PHYS


Diffstat:


 drivers/input/joystick/xpad.c   | 18 +--
 drivers/input/misc/pwm-beeper.c | 69 -
 drivers/input/misc/uinput.c |  6 
 3 files changed, 70 insertions(+), 23 deletions(-)

-- 
Dmitry

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

[Boris Ostrovsky]

- torva...@linux-foundation.org wrote:

> On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky
>  wrote:
> >
> > This breaks on older compilers:
> >
> >   CC  fs/nfs/nfs4state.o
> > /home/build/linux-linus/fs/nfs/nfs4state.c:69: error: unknown field
> > ‘data’ specified in initializer
> 
> Does the attached patch fix it for you?
> 
> I don't have easy access to the old compiler, but I _think_ the
> trivial patch of just adding braces around the data initializer
> should
> make old gcc's happy


It does fix it.

This is not the first time we've hit this and people have always been changing 
code to initialize fields in execution path (and I didn't fix it here myself 
because I wasn't sure where to do that). I guess we could have been just adding 
braces all along.


Thanks.
-boris

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

[Boris Ostrovsky]

- torva...@linux-foundation.org wrote:

> On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky
>  wrote:
> >
> > This breaks on older compilers:
> >
> >   CC  fs/nfs/nfs4state.o
> > /home/build/linux-linus/fs/nfs/nfs4state.c:69: error: unknown field
> > ‘data’ specified in initializer
> 
> Does the attached patch fix it for you?
> 
> I don't have easy access to the old compiler, but I _think_ the
> trivial patch of just adding braces around the data initializer
> should
> make old gcc's happy


It does fix it.

This is not the first time we've hit this and people have always been changing 
code to initialize fields in execution path (and I didn't fix it here myself 
because I wasn't sure where to do that). I guess we could have been just adding 
braces all along.


Thanks.
-boris

[git pull] vfs fixes

[Al Viro]

work.lookups followups - update docs, restore killability of
the places that used to take ->i_mutex killably now that we have
down_write_killable() merged.  Additionally, it turns out that I missed
a prereq for security_d_instantiate() stuff - ->getxattr() wasn't the
only thing that could be called before dentry is attached to inode; with
smack we needed the same treatment applied to ->setxattr() as well.

The following changes since commit 0985b65d3ba2c09f10a594b73df45c1f7f68d317:

  Merge branch 'work.iov_iter' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2016-05-25 15:59:09 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to 3767e255b390d72f9a33c08d9e86c5f21f25860f:

  switch ->setxattr() to passing dentry and inode separately (2016-05-27 
20:09:16 -0400)


Al Viro (5):
  update D/f/directory-locking
  add down_write_killable_nested()
  restore killability of old mutex_lock_killable(>i_mutex) users
  switch xattr_handler->set() to passing dentry and inode separately
  switch ->setxattr() to passing dentry and inode separately

 Documentation/filesystems/directory-locking| 32 ++
 Documentation/filesystems/porting  |  7 +
 .../staging/lustre/lustre/llite/llite_internal.h   |  4 +--
 drivers/staging/lustre/lustre/llite/xattr.c|  6 ++--
 fs/9p/acl.c|  6 ++--
 fs/9p/xattr.c  |  5 ++--
 fs/bad_inode.c |  4 +--
 fs/btrfs/ioctl.c   | 18 +---
 fs/btrfs/xattr.c   | 12 
 fs/ceph/xattr.c|  7 +++--
 fs/cifs/xattr.c|  9 +++---
 fs/ecryptfs/crypto.c   |  9 +++---
 fs/ecryptfs/ecryptfs_kernel.h  |  4 +--
 fs/ecryptfs/inode.c|  7 +++--
 fs/ecryptfs/mmap.c |  3 +-
 fs/ext2/xattr_security.c   |  7 +++--
 fs/ext2/xattr_trusted.c|  7 +++--
 fs/ext2/xattr_user.c   |  9 +++---
 fs/ext4/xattr_security.c   |  7 +++--
 fs/ext4/xattr_trusted.c|  7 +++--
 fs/ext4/xattr_user.c   |  9 +++---
 fs/f2fs/xattr.c| 12 
 fs/fuse/dir.c  |  6 ++--
 fs/gfs2/xattr.c|  6 ++--
 fs/hfs/attr.c  |  6 ++--
 fs/hfs/hfs_fs.h|  2 +-
 fs/hfsplus/xattr.c | 12 
 fs/hfsplus/xattr.h |  2 +-
 fs/hfsplus/xattr_security.c|  7 +++--
 fs/hfsplus/xattr_trusted.c |  7 +++--
 fs/hfsplus/xattr_user.c|  7 +++--
 fs/jffs2/security.c|  7 +++--
 fs/jffs2/xattr_trusted.c   |  7 +++--
 fs/jffs2/xattr_user.c  |  7 +++--
 fs/jfs/xattr.c | 14 --
 fs/kernfs/inode.c  | 11 
 fs/kernfs/kernfs-internal.h|  3 +-
 fs/libfs.c |  5 ++--
 fs/nfs/nfs4proc.c  | 19 ++---
 fs/ocfs2/xattr.c   | 23 +---
 fs/orangefs/xattr.c| 10 ---
 fs/overlayfs/inode.c   |  5 ++--
 fs/overlayfs/overlayfs.h   |  5 ++--
 fs/overlayfs/readdir.c |  4 +--
 fs/posix_acl.c |  6 ++--
 fs/readdir.c   | 12 
 fs/reiserfs/xattr_security.c   |  9 +++---
 fs/reiserfs/xattr_trusted.c|  9 +++---
 fs/reiserfs/xattr_user.c   |  9 +++---
 fs/ubifs/xattr.c   |  7 ++---
 fs/xattr.c | 10 ---
 fs/xfs/xfs_xattr.c |  9 +++---
 include/linux/fs.h |  3 +-
 include/linux/rwsem.h  |  2 ++
 include/linux/xattr.h  |  7 +++--
 kernel/locking/rwsem.c | 16 +++
 mm/shmem.c |  7 +++--
 security/smack/smack_lsm.c |  2 +-
 58 files changed, 265 insertions(+), 209 

[git pull] vfs fixes

[Al Viro]

work.lookups followups - update docs, restore killability of
the places that used to take ->i_mutex killably now that we have
down_write_killable() merged.  Additionally, it turns out that I missed
a prereq for security_d_instantiate() stuff - ->getxattr() wasn't the
only thing that could be called before dentry is attached to inode; with
smack we needed the same treatment applied to ->setxattr() as well.

The following changes since commit 0985b65d3ba2c09f10a594b73df45c1f7f68d317:

  Merge branch 'work.iov_iter' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2016-05-25 15:59:09 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to 3767e255b390d72f9a33c08d9e86c5f21f25860f:

  switch ->setxattr() to passing dentry and inode separately (2016-05-27 
20:09:16 -0400)


Al Viro (5):
  update D/f/directory-locking
  add down_write_killable_nested()
  restore killability of old mutex_lock_killable(>i_mutex) users
  switch xattr_handler->set() to passing dentry and inode separately
  switch ->setxattr() to passing dentry and inode separately

 Documentation/filesystems/directory-locking| 32 ++
 Documentation/filesystems/porting  |  7 +
 .../staging/lustre/lustre/llite/llite_internal.h   |  4 +--
 drivers/staging/lustre/lustre/llite/xattr.c|  6 ++--
 fs/9p/acl.c|  6 ++--
 fs/9p/xattr.c  |  5 ++--
 fs/bad_inode.c |  4 +--
 fs/btrfs/ioctl.c   | 18 +---
 fs/btrfs/xattr.c   | 12 
 fs/ceph/xattr.c|  7 +++--
 fs/cifs/xattr.c|  9 +++---
 fs/ecryptfs/crypto.c   |  9 +++---
 fs/ecryptfs/ecryptfs_kernel.h  |  4 +--
 fs/ecryptfs/inode.c|  7 +++--
 fs/ecryptfs/mmap.c |  3 +-
 fs/ext2/xattr_security.c   |  7 +++--
 fs/ext2/xattr_trusted.c|  7 +++--
 fs/ext2/xattr_user.c   |  9 +++---
 fs/ext4/xattr_security.c   |  7 +++--
 fs/ext4/xattr_trusted.c|  7 +++--
 fs/ext4/xattr_user.c   |  9 +++---
 fs/f2fs/xattr.c| 12 
 fs/fuse/dir.c  |  6 ++--
 fs/gfs2/xattr.c|  6 ++--
 fs/hfs/attr.c  |  6 ++--
 fs/hfs/hfs_fs.h|  2 +-
 fs/hfsplus/xattr.c | 12 
 fs/hfsplus/xattr.h |  2 +-
 fs/hfsplus/xattr_security.c|  7 +++--
 fs/hfsplus/xattr_trusted.c |  7 +++--
 fs/hfsplus/xattr_user.c|  7 +++--
 fs/jffs2/security.c|  7 +++--
 fs/jffs2/xattr_trusted.c   |  7 +++--
 fs/jffs2/xattr_user.c  |  7 +++--
 fs/jfs/xattr.c | 14 --
 fs/kernfs/inode.c  | 11 
 fs/kernfs/kernfs-internal.h|  3 +-
 fs/libfs.c |  5 ++--
 fs/nfs/nfs4proc.c  | 19 ++---
 fs/ocfs2/xattr.c   | 23 +---
 fs/orangefs/xattr.c| 10 ---
 fs/overlayfs/inode.c   |  5 ++--
 fs/overlayfs/overlayfs.h   |  5 ++--
 fs/overlayfs/readdir.c |  4 +--
 fs/posix_acl.c |  6 ++--
 fs/readdir.c   | 12 
 fs/reiserfs/xattr_security.c   |  9 +++---
 fs/reiserfs/xattr_trusted.c|  9 +++---
 fs/reiserfs/xattr_user.c   |  9 +++---
 fs/ubifs/xattr.c   |  7 ++---
 fs/xattr.c | 10 ---
 fs/xfs/xfs_xattr.c |  9 +++---
 include/linux/fs.h |  3 +-
 include/linux/rwsem.h  |  2 ++
 include/linux/xattr.h  |  7 +++--
 kernel/locking/rwsem.c | 16 +++
 mm/shmem.c |  7 +++--
 security/smack/smack_lsm.c |  2 +-
 58 files changed, 265 insertions(+), 209 

Re: [PATCH v4 08/10] powerpc/powernv: Add platform support for stop instruction

[Ram Pai]

On Tue, May 24, 2016 at 06:45:12PM +0530, Shreyas B. Prabhu wrote:
> POWER ISA v3 defines a new idle processor core mechanism. In summary,
>  a) new instruction named stop is added. This instruction replaces
>   instructions like nap, sleep, rvwinkle.
>  b) new per thread SPR named Processor Stop Status and Control Register
>   (PSSCR) is added which controls the behavior of stop instruction.
> 
> PSSCR layout:
> --
> | PLS | /// | SD | ESL | EC | PSLL | /// | TR | MTL | RL |
> --
> 0  4 41   4243   44 4854   5660
> 
> PSSCR key fields:
>   Bits 0:3  - Power-Saving Level Status. This field indicates the lowest
>   power-saving state the thread entered since stop instruction was last
>   executed.
> 
>   Bit 42 - Enable State Loss
>   0 - No state is lost irrespective of other fields
>   1 - Allows state loss
> 
>   Bits 44:47 - Power-Saving Level Limit
>   This limits the power-saving level that can be entered into.
> 
>   Bits 60:63 - Requested Level
>   Used to specify which power-saving level must be entered on executing
>   stop instruction
> 
> This patch adds support for stop instruction and PSSCR handling.
> 
> Signed-off-by: Shreyas B. Prabhu 
> ---
> Changes in v4:
> ==
>  - Added PSSCR layout to commit message
>  - Improved / Fixed comments
>  - Fixed whitespace error in paca.h
>  - Using MAX_POSSIBLE_STOP_STATE macro instead of hardcoding 0xF has 
>max possible stop state
> 
> Changes in v3:
> ==
>  - Instead of introducing new file idle_power_stop.S, P9 idle support
>is added to idle_power_common.S using CPU_FTR sections.
>  - Fixed r4 reg clobbering in power_stop0
>  - Improved comments
> 
> Changes in v2:
> ==
>  - Using CPU_FTR_ARCH_300 bit instead of CPU_FTR_STOP_INST
> 
>  arch/powerpc/include/asm/cpuidle.h|   2 +
>  arch/powerpc/include/asm/kvm_book3s_asm.h |   2 +-
>  arch/powerpc/include/asm/machdep.h|   1 +
>  arch/powerpc/include/asm/opal-api.h   |  11 ++-
>  arch/powerpc/include/asm/paca.h   |   2 +
>  arch/powerpc/include/asm/ppc-opcode.h |   4 +
>  arch/powerpc/include/asm/processor.h  |   1 +
>  arch/powerpc/include/asm/reg.h|  11 +++
>  arch/powerpc/kernel/asm-offsets.c |   2 +
>  arch/powerpc/kernel/idle_power_common.S   | 149 
> +++---
>  arch/powerpc/platforms/powernv/idle.c |  84 ++---
>  11 files changed, 239 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/cpuidle.h 
> b/arch/powerpc/include/asm/cpuidle.h
> index d2f99ca..3d7fc06 100644
> --- a/arch/powerpc/include/asm/cpuidle.h
> +++ b/arch/powerpc/include/asm/cpuidle.h
> @@ -13,6 +13,8 @@
>  #ifndef __ASSEMBLY__
>  extern u32 pnv_fastsleep_workaround_at_entry[];
>  extern u32 pnv_fastsleep_workaround_at_exit[];
> +
> +extern u64 pnv_first_deep_stop_state;
>  #endif
>  
>  #endif
> diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h 
> b/arch/powerpc/include/asm/kvm_book3s_asm.h
> index 72b6225..d318d43 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_asm.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
> @@ -162,7 +162,7 @@ struct kvmppc_book3s_shadow_vcpu {
>  
>  /* Values for kvm_state */
>  #define KVM_HWTHREAD_IN_KERNEL   0
> -#define KVM_HWTHREAD_IN_NAP  1
> +#define KVM_HWTHREAD_IN_IDLE 1
>  #define KVM_HWTHREAD_IN_KVM  2
>  
>  #endif /* __ASM_KVM_BOOK3S_ASM_H__ */
> diff --git a/arch/powerpc/include/asm/machdep.h 
> b/arch/powerpc/include/asm/machdep.h
> index 6bdcd0d..ae3b155 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -262,6 +262,7 @@ struct machdep_calls {
>  extern void e500_idle(void);
>  extern void power4_idle(void);
>  extern void power7_idle(void);
> +extern void power_stop0(void);
>  extern void ppc6xx_idle(void);
>  extern void book3e_idle(void);
>  
> diff --git a/arch/powerpc/include/asm/opal-api.h 
> b/arch/powerpc/include/asm/opal-api.h
> index 9bb8ddf..7f3f8c6 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -162,13 +162,20 @@
>  
>  /* Device tree flags */
>  
> -/* Flags set in power-mgmt nodes in device tree if
> - * respective idle states are supported in the platform.
> +/*
> + * Flags set in power-mgmt nodes in device tree describing
> + * idle states that are supported in the platform.
>   */
> +
> +#define OPAL_PM_TIMEBASE_STOP0x0002
> +#define OPAL_PM_LOSE_HYP_CONTEXT 0x2000
> +#define OPAL_PM_LOSE_FULL_CONTEXT0x4000
>  #define OPAL_PM_NAP_ENABLED  0x0001
>  #define OPAL_PM_SLEEP_ENABLED0x0002
>  #define OPAL_PM_WINKLE_ENABLED   0x0004
>  #define OPAL_PM_SLEEP_ENABLED_ER10x0008 /* with workaround */
> 

Re: [PATCH v4 08/10] powerpc/powernv: Add platform support for stop instruction

[Ram Pai]

On Tue, May 24, 2016 at 06:45:12PM +0530, Shreyas B. Prabhu wrote:
> POWER ISA v3 defines a new idle processor core mechanism. In summary,
>  a) new instruction named stop is added. This instruction replaces
>   instructions like nap, sleep, rvwinkle.
>  b) new per thread SPR named Processor Stop Status and Control Register
>   (PSSCR) is added which controls the behavior of stop instruction.
> 
> PSSCR layout:
> --
> | PLS | /// | SD | ESL | EC | PSLL | /// | TR | MTL | RL |
> --
> 0  4 41   4243   44 4854   5660
> 
> PSSCR key fields:
>   Bits 0:3  - Power-Saving Level Status. This field indicates the lowest
>   power-saving state the thread entered since stop instruction was last
>   executed.
> 
>   Bit 42 - Enable State Loss
>   0 - No state is lost irrespective of other fields
>   1 - Allows state loss
> 
>   Bits 44:47 - Power-Saving Level Limit
>   This limits the power-saving level that can be entered into.
> 
>   Bits 60:63 - Requested Level
>   Used to specify which power-saving level must be entered on executing
>   stop instruction
> 
> This patch adds support for stop instruction and PSSCR handling.
> 
> Signed-off-by: Shreyas B. Prabhu 
> ---
> Changes in v4:
> ==
>  - Added PSSCR layout to commit message
>  - Improved / Fixed comments
>  - Fixed whitespace error in paca.h
>  - Using MAX_POSSIBLE_STOP_STATE macro instead of hardcoding 0xF has 
>max possible stop state
> 
> Changes in v3:
> ==
>  - Instead of introducing new file idle_power_stop.S, P9 idle support
>is added to idle_power_common.S using CPU_FTR sections.
>  - Fixed r4 reg clobbering in power_stop0
>  - Improved comments
> 
> Changes in v2:
> ==
>  - Using CPU_FTR_ARCH_300 bit instead of CPU_FTR_STOP_INST
> 
>  arch/powerpc/include/asm/cpuidle.h|   2 +
>  arch/powerpc/include/asm/kvm_book3s_asm.h |   2 +-
>  arch/powerpc/include/asm/machdep.h|   1 +
>  arch/powerpc/include/asm/opal-api.h   |  11 ++-
>  arch/powerpc/include/asm/paca.h   |   2 +
>  arch/powerpc/include/asm/ppc-opcode.h |   4 +
>  arch/powerpc/include/asm/processor.h  |   1 +
>  arch/powerpc/include/asm/reg.h|  11 +++
>  arch/powerpc/kernel/asm-offsets.c |   2 +
>  arch/powerpc/kernel/idle_power_common.S   | 149 
> +++---
>  arch/powerpc/platforms/powernv/idle.c |  84 ++---
>  11 files changed, 239 insertions(+), 30 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/cpuidle.h 
> b/arch/powerpc/include/asm/cpuidle.h
> index d2f99ca..3d7fc06 100644
> --- a/arch/powerpc/include/asm/cpuidle.h
> +++ b/arch/powerpc/include/asm/cpuidle.h
> @@ -13,6 +13,8 @@
>  #ifndef __ASSEMBLY__
>  extern u32 pnv_fastsleep_workaround_at_entry[];
>  extern u32 pnv_fastsleep_workaround_at_exit[];
> +
> +extern u64 pnv_first_deep_stop_state;
>  #endif
>  
>  #endif
> diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h 
> b/arch/powerpc/include/asm/kvm_book3s_asm.h
> index 72b6225..d318d43 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_asm.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
> @@ -162,7 +162,7 @@ struct kvmppc_book3s_shadow_vcpu {
>  
>  /* Values for kvm_state */
>  #define KVM_HWTHREAD_IN_KERNEL   0
> -#define KVM_HWTHREAD_IN_NAP  1
> +#define KVM_HWTHREAD_IN_IDLE 1
>  #define KVM_HWTHREAD_IN_KVM  2
>  
>  #endif /* __ASM_KVM_BOOK3S_ASM_H__ */
> diff --git a/arch/powerpc/include/asm/machdep.h 
> b/arch/powerpc/include/asm/machdep.h
> index 6bdcd0d..ae3b155 100644
> --- a/arch/powerpc/include/asm/machdep.h
> +++ b/arch/powerpc/include/asm/machdep.h
> @@ -262,6 +262,7 @@ struct machdep_calls {
>  extern void e500_idle(void);
>  extern void power4_idle(void);
>  extern void power7_idle(void);
> +extern void power_stop0(void);
>  extern void ppc6xx_idle(void);
>  extern void book3e_idle(void);
>  
> diff --git a/arch/powerpc/include/asm/opal-api.h 
> b/arch/powerpc/include/asm/opal-api.h
> index 9bb8ddf..7f3f8c6 100644
> --- a/arch/powerpc/include/asm/opal-api.h
> +++ b/arch/powerpc/include/asm/opal-api.h
> @@ -162,13 +162,20 @@
>  
>  /* Device tree flags */
>  
> -/* Flags set in power-mgmt nodes in device tree if
> - * respective idle states are supported in the platform.
> +/*
> + * Flags set in power-mgmt nodes in device tree describing
> + * idle states that are supported in the platform.
>   */
> +
> +#define OPAL_PM_TIMEBASE_STOP0x0002
> +#define OPAL_PM_LOSE_HYP_CONTEXT 0x2000
> +#define OPAL_PM_LOSE_FULL_CONTEXT0x4000
>  #define OPAL_PM_NAP_ENABLED  0x0001
>  #define OPAL_PM_SLEEP_ENABLED0x0002
>  #define OPAL_PM_WINKLE_ENABLED   0x0004
>  #define OPAL_PM_SLEEP_ENABLED_ER10x0008 /* with workaround */
> +#define OPAL_PM_STOP_INST_FAST 

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

[Linus Torvalds]

On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky
 wrote:
>
> This breaks on older compilers:
>
>   CC  fs/nfs/nfs4state.o
> /home/build/linux-linus/fs/nfs/nfs4state.c:69: error: unknown field
> ‘data’ specified in initializer

Does the attached patch fix it for you?

I don't have easy access to the old compiler, but I _think_ the
trivial patch of just adding braces around the data initializer should
make old gcc's happy

  Linus
 fs/nfs/nfs4state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 5075592df145..9679f4749364 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -66,7 +66,7 @@
 #define OPENOWNER_POOL_SIZE8
 
 const nfs4_stateid zero_stateid = {
-   .data = { 0 },
+   { .data = { 0 } },
.type = NFS4_SPECIAL_STATEID_TYPE,
 };
 static DEFINE_MUTEX(nfs_clid_init_mutex);

Re: [GIT PULL] Please pull NFS client changes for Linux 4.7

[Linus Torvalds]

On Fri, May 27, 2016 at 10:14 AM, Boris Ostrovsky
 wrote:
>
> This breaks on older compilers:
>
>   CC  fs/nfs/nfs4state.o
> /home/build/linux-linus/fs/nfs/nfs4state.c:69: error: unknown field
> ‘data’ specified in initializer

Does the attached patch fix it for you?

I don't have easy access to the old compiler, but I _think_ the
trivial patch of just adding braces around the data initializer should
make old gcc's happy

  Linus
 fs/nfs/nfs4state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 5075592df145..9679f4749364 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -66,7 +66,7 @@
 #define OPENOWNER_POOL_SIZE8
 
 const nfs4_stateid zero_stateid = {
-   .data = { 0 },
+   { .data = { 0 } },
.type = NFS4_SPECIAL_STATEID_TYPE,
 };
 static DEFINE_MUTEX(nfs_clid_init_mutex);

Re: [PATCH] Input: pwm-beeper - fix: scheduling while atomic

[Dmitry Torokhov]

On Fri, May 27, 2016 at 11:14:27AM +0200, Manfred Schlaegl wrote:
> Pwm config may sleep so defer it using a worker.
> 
> On a Freescale i.MX53 based board we ran into "BUG: scheduling while
> atomic" because input_inject_event locks interrupts, but
> imx_pwm_config_v2 sleeps.
> 
> Tested on Freescale i.MX53 SoC with 4.6.0.
> 
> Signed-off-by: Manfred Schlaegl 

Applied, thank you.

> ---
>  drivers/input/misc/pwm-beeper.c | 69 
> -
>  1 file changed, 48 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> index 8d71332..5f9655d 100644
> --- a/drivers/input/misc/pwm-beeper.c
> +++ b/drivers/input/misc/pwm-beeper.c
> @@ -20,21 +20,40 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct pwm_beeper {
>   struct input_dev *input;
>   struct pwm_device *pwm;
> + struct work_struct work;
>   unsigned long period;
>  };
>  
>  #define HZ_TO_NANOSECONDS(x) (10UL/(x))
>  
> +static void __pwm_beeper_set(struct pwm_beeper *beeper)
> +{
> + unsigned long period = beeper->period;
> +
> + if (period) {
> + pwm_config(beeper->pwm, period / 2, period);
> + pwm_enable(beeper->pwm);
> + } else
> + pwm_disable(beeper->pwm);
> +}
> +
> +static void pwm_beeper_work(struct work_struct *work)
> +{
> + struct pwm_beeper *beeper =
> + container_of(work, struct pwm_beeper, work);
> +
> + __pwm_beeper_set(beeper);
> +}
> +
>  static int pwm_beeper_event(struct input_dev *input,
>   unsigned int type, unsigned int code, int value)
>  {
> - int ret = 0;
>   struct pwm_beeper *beeper = input_get_drvdata(input);
> - unsigned long period;
>  
>   if (type != EV_SND || value < 0)
>   return -EINVAL;
> @@ -49,22 +68,31 @@ static int pwm_beeper_event(struct input_dev *input,
>   return -EINVAL;
>   }
>  
> - if (value == 0) {
> - pwm_disable(beeper->pwm);
> - } else {
> - period = HZ_TO_NANOSECONDS(value);
> - ret = pwm_config(beeper->pwm, period / 2, period);
> - if (ret)
> - return ret;
> - ret = pwm_enable(beeper->pwm);
> - if (ret)
> - return ret;
> - beeper->period = period;
> - }
> + if (value == 0)
> + beeper->period = 0;
> + else
> + beeper->period = HZ_TO_NANOSECONDS(value);
> +
> + schedule_work(>work);
>  
>   return 0;
>  }
>  
> +static void pwm_beeper_stop(struct pwm_beeper *beeper)
> +{
> + cancel_work_sync(>work);
> +
> + if (beeper->period)
> + pwm_disable(beeper->pwm);
> +}
> +
> +static void pwm_beeper_close(struct input_dev *input)
> +{
> + struct pwm_beeper *beeper = input_get_drvdata(input);
> +
> + pwm_beeper_stop(beeper);
> +}
> +
>  static int pwm_beeper_probe(struct platform_device *pdev)
>  {
>   unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
> @@ -93,6 +121,8 @@ static int pwm_beeper_probe(struct platform_device *pdev)
>*/
>   pwm_apply_args(beeper->pwm);
>  
> + INIT_WORK(>work, pwm_beeper_work);
> +
>   beeper->input = input_allocate_device();
>   if (!beeper->input) {
>   dev_err(>dev, "Failed to allocate input device\n");
> @@ -112,6 +142,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
>   beeper->input->sndbit[0] = BIT(SND_TONE) | BIT(SND_BELL);
>  
>   beeper->input->event = pwm_beeper_event;
> + beeper->input->close = pwm_beeper_close;
>  
>   input_set_drvdata(beeper->input, beeper);
>  
> @@ -141,7 +172,6 @@ static int pwm_beeper_remove(struct platform_device *pdev)
>  
>   input_unregister_device(beeper->input);
>  
> - pwm_disable(beeper->pwm);
>   pwm_free(beeper->pwm);
>  
>   kfree(beeper);
> @@ -153,8 +183,7 @@ static int __maybe_unused pwm_beeper_suspend(struct 
> device *dev)
>  {
>   struct pwm_beeper *beeper = dev_get_drvdata(dev);
>  
> - if (beeper->period)
> - pwm_disable(beeper->pwm);
> + pwm_beeper_stop(beeper);
>  
>   return 0;
>  }
> @@ -163,10 +192,8 @@ static int __maybe_unused pwm_beeper_resume(struct 
> device *dev)
>  {
>   struct pwm_beeper *beeper = dev_get_drvdata(dev);
>  
> - if (beeper->period) {
> - pwm_config(beeper->pwm, beeper->period / 2, beeper->period);
> - pwm_enable(beeper->pwm);
> - }
> + if (beeper->period)
> + __pwm_beeper_set(beeper);
>  
>   return 0;
>  }
> -- 
> 2.1.4
> 

-- 
Dmitry

Re: [PATCH] Input: pwm-beeper - fix: scheduling while atomic

[Dmitry Torokhov]

On Fri, May 27, 2016 at 11:14:27AM +0200, Manfred Schlaegl wrote:
> Pwm config may sleep so defer it using a worker.
> 
> On a Freescale i.MX53 based board we ran into "BUG: scheduling while
> atomic" because input_inject_event locks interrupts, but
> imx_pwm_config_v2 sleeps.
> 
> Tested on Freescale i.MX53 SoC with 4.6.0.
> 
> Signed-off-by: Manfred Schlaegl 

Applied, thank you.

> ---
>  drivers/input/misc/pwm-beeper.c | 69 
> -
>  1 file changed, 48 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/input/misc/pwm-beeper.c b/drivers/input/misc/pwm-beeper.c
> index 8d71332..5f9655d 100644
> --- a/drivers/input/misc/pwm-beeper.c
> +++ b/drivers/input/misc/pwm-beeper.c
> @@ -20,21 +20,40 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  struct pwm_beeper {
>   struct input_dev *input;
>   struct pwm_device *pwm;
> + struct work_struct work;
>   unsigned long period;
>  };
>  
>  #define HZ_TO_NANOSECONDS(x) (10UL/(x))
>  
> +static void __pwm_beeper_set(struct pwm_beeper *beeper)
> +{
> + unsigned long period = beeper->period;
> +
> + if (period) {
> + pwm_config(beeper->pwm, period / 2, period);
> + pwm_enable(beeper->pwm);
> + } else
> + pwm_disable(beeper->pwm);
> +}
> +
> +static void pwm_beeper_work(struct work_struct *work)
> +{
> + struct pwm_beeper *beeper =
> + container_of(work, struct pwm_beeper, work);
> +
> + __pwm_beeper_set(beeper);
> +}
> +
>  static int pwm_beeper_event(struct input_dev *input,
>   unsigned int type, unsigned int code, int value)
>  {
> - int ret = 0;
>   struct pwm_beeper *beeper = input_get_drvdata(input);
> - unsigned long period;
>  
>   if (type != EV_SND || value < 0)
>   return -EINVAL;
> @@ -49,22 +68,31 @@ static int pwm_beeper_event(struct input_dev *input,
>   return -EINVAL;
>   }
>  
> - if (value == 0) {
> - pwm_disable(beeper->pwm);
> - } else {
> - period = HZ_TO_NANOSECONDS(value);
> - ret = pwm_config(beeper->pwm, period / 2, period);
> - if (ret)
> - return ret;
> - ret = pwm_enable(beeper->pwm);
> - if (ret)
> - return ret;
> - beeper->period = period;
> - }
> + if (value == 0)
> + beeper->period = 0;
> + else
> + beeper->period = HZ_TO_NANOSECONDS(value);
> +
> + schedule_work(>work);
>  
>   return 0;
>  }
>  
> +static void pwm_beeper_stop(struct pwm_beeper *beeper)
> +{
> + cancel_work_sync(>work);
> +
> + if (beeper->period)
> + pwm_disable(beeper->pwm);
> +}
> +
> +static void pwm_beeper_close(struct input_dev *input)
> +{
> + struct pwm_beeper *beeper = input_get_drvdata(input);
> +
> + pwm_beeper_stop(beeper);
> +}
> +
>  static int pwm_beeper_probe(struct platform_device *pdev)
>  {
>   unsigned long pwm_id = (unsigned long)dev_get_platdata(>dev);
> @@ -93,6 +121,8 @@ static int pwm_beeper_probe(struct platform_device *pdev)
>*/
>   pwm_apply_args(beeper->pwm);
>  
> + INIT_WORK(>work, pwm_beeper_work);
> +
>   beeper->input = input_allocate_device();
>   if (!beeper->input) {
>   dev_err(>dev, "Failed to allocate input device\n");
> @@ -112,6 +142,7 @@ static int pwm_beeper_probe(struct platform_device *pdev)
>   beeper->input->sndbit[0] = BIT(SND_TONE) | BIT(SND_BELL);
>  
>   beeper->input->event = pwm_beeper_event;
> + beeper->input->close = pwm_beeper_close;
>  
>   input_set_drvdata(beeper->input, beeper);
>  
> @@ -141,7 +172,6 @@ static int pwm_beeper_remove(struct platform_device *pdev)
>  
>   input_unregister_device(beeper->input);
>  
> - pwm_disable(beeper->pwm);
>   pwm_free(beeper->pwm);
>  
>   kfree(beeper);
> @@ -153,8 +183,7 @@ static int __maybe_unused pwm_beeper_suspend(struct 
> device *dev)
>  {
>   struct pwm_beeper *beeper = dev_get_drvdata(dev);
>  
> - if (beeper->period)
> - pwm_disable(beeper->pwm);
> + pwm_beeper_stop(beeper);
>  
>   return 0;
>  }
> @@ -163,10 +192,8 @@ static int __maybe_unused pwm_beeper_resume(struct 
> device *dev)
>  {
>   struct pwm_beeper *beeper = dev_get_drvdata(dev);
>  
> - if (beeper->period) {
> - pwm_config(beeper->pwm, beeper->period / 2, beeper->period);
> - pwm_enable(beeper->pwm);
> - }
> + if (beeper->period)
> + __pwm_beeper_set(beeper);
>  
>   return 0;
>  }
> -- 
> 2.1.4
> 

-- 
Dmitry

[PATCH] ARM: dts: imx: ventana: Add ext watchdog reset

[Tim Harvey]

bc677ff42e81bbf78308a7b66cf7b63b0f5c26b0 adds a device-tree property
to specify that an external watchdog reset is used to reset other
portions of the board and not just the IMX6 SoC.

This adds the property to the proper watchdog as well as the pinmux for
the Gateworks Ventana boards that use this external watchdog reset to
reset the PMIC which will reset all the PMIC power rails and not just
a chip-level IMX6 reset. This helps to work around various system issues
that can cause a hang when coming out of reset.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 17 +
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw553x.dtsi |  1 +
 7 files changed, 78 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index 9d7ab6c..1340e27 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -228,6 +228,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+};
+
  {
imx6qdl-gw51xx {
pinctrl_enet: enetgrp {
@@ -364,5 +370,11 @@
MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x1b0b0 
/* OTG_PWR_EN */
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT8__WDOG1_B  0x1b0b0
+   >;
+   };
};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index 7191b84..8bf1020 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -353,6 +353,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+};
+
  {
imx6qdl-gw52xx {
pinctrl_audmux: audmuxgrp {
@@ -549,5 +555,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT   0x170f9
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT8__WDOG1_B  0x1b0b0
+   >;
+   };
};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 0fada07..e5f4b6c 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -350,6 +350,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+};
+
  {
imx6qdl-gw53xx {
pinctrl_audmux: audmuxgrp {
@@ -538,5 +544,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT   0x170f9
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT8__WDOG1_B  0x1b0b0
+   >;
+   };
};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index d6dbe2a..5a8dbab 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -453,6 +453,17 @@
status = "okay";
 };
 
+ {
+   status = "disabled";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+   status = "okay";
+};
+
  {
imx6qdl-gw54xx {
pinctrl_audmux: audmuxgrp {
@@ -654,5 +665,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT   0x170f9
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT3__WDOG2_B0x1b0b0
+   >;
+   };
};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 118bea5..4b9fef8 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -239,6 +239,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+};
+
  {
imx6qdl-gw51xx {
pinctrl_flexcan1: flexcan1grp {
@@ -333,5 +339,11 @@
MX6QDL_PAD_GPIO_1__USB_OTG_ID   0x17059
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+ 

[PATCH] ARM: dts: imx: ventana: Add ext watchdog reset

[Tim Harvey]

bc677ff42e81bbf78308a7b66cf7b63b0f5c26b0 adds a device-tree property
to specify that an external watchdog reset is used to reset other
portions of the board and not just the IMX6 SoC.

This adds the property to the proper watchdog as well as the pinmux for
the Gateworks Ventana boards that use this external watchdog reset to
reset the PMIC which will reset all the PMIC power rails and not just
a chip-level IMX6 reset. This helps to work around various system issues
that can cause a hang when coming out of reset.

Signed-off-by: Tim Harvey 
---
 arch/arm/boot/dts/imx6qdl-gw51xx.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 17 +
 arch/arm/boot/dts/imx6qdl-gw551x.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi | 12 
 arch/arm/boot/dts/imx6qdl-gw553x.dtsi |  1 +
 7 files changed, 78 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
index 9d7ab6c..1340e27 100644
--- a/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw51xx.dtsi
@@ -228,6 +228,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+};
+
  {
imx6qdl-gw51xx {
pinctrl_enet: enetgrp {
@@ -364,5 +370,11 @@
MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x1b0b0 
/* OTG_PWR_EN */
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT8__WDOG1_B  0x1b0b0
+   >;
+   };
};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
index 7191b84..8bf1020 100644
--- a/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw52xx.dtsi
@@ -353,6 +353,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+};
+
  {
imx6qdl-gw52xx {
pinctrl_audmux: audmuxgrp {
@@ -549,5 +555,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT   0x170f9
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT8__WDOG1_B  0x1b0b0
+   >;
+   };
};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
index 0fada07..e5f4b6c 100644
--- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi
@@ -350,6 +350,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+};
+
  {
imx6qdl-gw53xx {
pinctrl_audmux: audmuxgrp {
@@ -538,5 +544,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT   0x170f9
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX6QDL_PAD_DISP0_DAT8__WDOG1_B  0x1b0b0
+   >;
+   };
};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
index d6dbe2a..5a8dbab 100644
--- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi
@@ -453,6 +453,17 @@
status = "okay";
 };
 
+ {
+   status = "disabled";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+   status = "okay";
+};
+
  {
imx6qdl-gw54xx {
pinctrl_audmux: audmuxgrp {
@@ -654,5 +665,11 @@
MX6QDL_PAD_NANDF_CS1__SD3_VSELECT   0x170f9
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT3__WDOG2_B0x1b0b0
+   >;
+   };
};
 };
diff --git a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi 
b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
index 118bea5..4b9fef8 100644
--- a/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-gw551x.dtsi
@@ -239,6 +239,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_wdog>;
+   fsl,ext-reset-output;
+};
+
  {
imx6qdl-gw51xx {
pinctrl_flexcan1: flexcan1grp {
@@ -333,5 +339,11 @@
MX6QDL_PAD_GPIO_1__USB_OTG_ID   0x17059
>;
};
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

[Linus Torvalds]

On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann  wrote:
>
> This patch changes all users of IS_ERR_VALUE() that I could find
> on 32-bit ARM randconfig builds and x86 allmodconfig. For the
> moment, this doesn't change the definition of IS_ERR_VALUE()
> because there are probably still architecture specific users
> elsewhere.

Patch applied with the fixups from Al Viro edited in.

I also ended up removing a few other users (due to the vm_brk()
interface), and then made IS_ERR_VALUE() do the "void *" cast so that
integer use of a non-pointer size should now complain.

It works for me and has no new warnings in my allmodconfig build, and
with your ARM work that is presumably clean too. But other
architectures may see new warnings.

People who got affected by this should check their subsystem code for
the changes.

  Linus

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

[Linus Torvalds]

On Fri, May 27, 2016 at 2:23 PM, Arnd Bergmann  wrote:
>
> This patch changes all users of IS_ERR_VALUE() that I could find
> on 32-bit ARM randconfig builds and x86 allmodconfig. For the
> moment, this doesn't change the definition of IS_ERR_VALUE()
> because there are probably still architecture specific users
> elsewhere.

Patch applied with the fixups from Al Viro edited in.

I also ended up removing a few other users (due to the vm_brk()
interface), and then made IS_ERR_VALUE() do the "void *" cast so that
integer use of a non-pointer size should now complain.

It works for me and has no new warnings in my allmodconfig build, and
with your ARM work that is presumably clean too. But other
architectures may see new warnings.

People who got affected by this should check their subsystem code for
the changes.

  Linus

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

[Andy Lutomirski]

On May 27, 2016 3:38 PM, "Kees Cook"  wrote:
>
> On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski  wrote:
> > On May 27, 2016 11:42 AM, "Kees Cook"  wrote:
> >>
> >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski  
> >> wrote:
> >> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook  wrote:
> >> >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski  
> >> >> wrote:
> >> >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook  
> >> >>> wrote:
> >>  One problem with seccomp was that ptrace could be used to change a
> >>  syscall after seccomp filtering had completed. This was a well 
> >>  documented
> >>  limitation, and it was recommended to block ptrace when defining a 
> >>  filter
> >>  to avoid this problem. This can be quite a limitation for containers 
> >>  or
> >>  other places where ptrace is desired even under seccomp filters.
> >> 
> >>  Since seccomp filtering has been split into pre-trace and trace phases
> >>  (phase1 and phase2 respectively), it's possible to re-run phase1 
> >>  seccomp
> >>  after ptrace. This makes that change, and updates the test suite for
> >>  both SECCOMP_RET_TRACE and PTRACE_SYSCALL manipulation.
> >> >>>
> >> >>> I like fixing the hole, but I don't like this fix.
> >> >>>
> >> >>> The two-phase seccomp mechanism is messy.  I wrote it because it was a
> >> >>> huge speedup.  Since then, I've made a ton of changes to the way that
> >> >>> x86 syscalls work, and there are two relevant effects: the slow path
> >> >>> is quite fast, and the phase-1-only path isn't really a win any more.
> >> >>>
> >> >>> I suggest that we fix the by simplifying the code instead of making it
> >> >>> even more complicated.  Let's back out the two-phase mechanism (but
> >> >>> keep the ability for arch code to supply seccomp_data) and then just
> >> >>> reorder it so that seccomp happens after ptrace.  The result should be
> >> >>> considerably simpler.  (We'll still have to answer the question of
> >> >>> what happens when a SECCOMP_RET_TRACE event changes the syscall, but
> >> >>> maybe the answer is to just let it through -- after all,
> >> >>> SECCOMP_RET_TRACE might be a request by a tracer to do its own
> >> >>> internal filtering.)
> >> >>
> >> >> I'm really against this. I think seccomp needs to stay first,
> >> >
> >> > Why?  What use case is improved with it going first?
> >>
> >> I feel that the critical purpose of seccomp is to minimize attack
> >> surface. To that end, I am strongly against anything coming before it
> >> in the syscall path. I really do not want ptrace going first, I think
> >> it's just asking for bugs.
> >
> > I disagree in this case.  There's no actual code surface opened up.
> > If seccomp allows even a single syscall through and there's a ptracer
> > attached, then the ptrace code is exposed.  As far as ptrace is
> > concerned, the syscall number is just a number, and ptrace has
> > basically no awareness of the arguments.
>
> No, I completely disagree: there is a significant amount of surface
> exposed. With a tracer attached there is significantly more happening
> before the filter would be checked. Even less obvious things like
> signal delivery, etc get exposed. Seccomp must be first -- this is
> it's basic design principle. Bugs creep in, unexpected combinations
> creep in, etc. Seccomp must mitigate this and be first on the syscall
> path. The paranoia of this design principle must remain in place, even
> at the expense of some inelegant results.

But this only works if the filter is literally "deny everything".  If
there is even a single syscall allowed and a ptracer is attached, then
the whole ptrace machinery is exposed anyway.

Users who are this paranoid about attack surface need to disable
ptrace, full stop.  If you can do the ptrace(2) syscall, then you can
invoke all the nasty code paths by yourself, and there is nothing
seccomp can do about it.  All seccomp can do is prevent ptrace from
generating a syscall that would otherwise be filtered out.

Let's look at the actual supposed attack surface:


if (unlikely(work & _TIF_SYSCALL_EMU))
ret = -1L;

if ((ret || test_thread_flag(TIF_SYSCALL_TRACE)) &&
tracehook_report_syscall_entry(regs))
ret = -1L;

That's all.

The only way that TIF_SYSCALL_EMU or TIF_SYSCALL_TRACE gets set is if
a ptracer is attached and uses PTRACE_SYSEMU, PTRACE_SYSCALL or
similar.  If that has happened, then there's very, very little that
seccomp can possibly do to reduce attack surface.  First, literally
any syscall that results in SECCOMP_RET_OK will cause all of the same
kernel code paths to run.  Second, most of those code paths can be
triggered without any syscall at all by using PTRACE_SINGLESTEP
instead.

So I challenge you to find a realistic scenario (i.e. something that a
real program 

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

[Andy Lutomirski]

On May 27, 2016 3:38 PM, "Kees Cook"  wrote:
>
> On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski  wrote:
> > On May 27, 2016 11:42 AM, "Kees Cook"  wrote:
> >>
> >> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski  
> >> wrote:
> >> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook  wrote:
> >> >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski  
> >> >> wrote:
> >> >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook  
> >> >>> wrote:
> >>  One problem with seccomp was that ptrace could be used to change a
> >>  syscall after seccomp filtering had completed. This was a well 
> >>  documented
> >>  limitation, and it was recommended to block ptrace when defining a 
> >>  filter
> >>  to avoid this problem. This can be quite a limitation for containers 
> >>  or
> >>  other places where ptrace is desired even under seccomp filters.
> >> 
> >>  Since seccomp filtering has been split into pre-trace and trace phases
> >>  (phase1 and phase2 respectively), it's possible to re-run phase1 
> >>  seccomp
> >>  after ptrace. This makes that change, and updates the test suite for
> >>  both SECCOMP_RET_TRACE and PTRACE_SYSCALL manipulation.
> >> >>>
> >> >>> I like fixing the hole, but I don't like this fix.
> >> >>>
> >> >>> The two-phase seccomp mechanism is messy.  I wrote it because it was a
> >> >>> huge speedup.  Since then, I've made a ton of changes to the way that
> >> >>> x86 syscalls work, and there are two relevant effects: the slow path
> >> >>> is quite fast, and the phase-1-only path isn't really a win any more.
> >> >>>
> >> >>> I suggest that we fix the by simplifying the code instead of making it
> >> >>> even more complicated.  Let's back out the two-phase mechanism (but
> >> >>> keep the ability for arch code to supply seccomp_data) and then just
> >> >>> reorder it so that seccomp happens after ptrace.  The result should be
> >> >>> considerably simpler.  (We'll still have to answer the question of
> >> >>> what happens when a SECCOMP_RET_TRACE event changes the syscall, but
> >> >>> maybe the answer is to just let it through -- after all,
> >> >>> SECCOMP_RET_TRACE might be a request by a tracer to do its own
> >> >>> internal filtering.)
> >> >>
> >> >> I'm really against this. I think seccomp needs to stay first,
> >> >
> >> > Why?  What use case is improved with it going first?
> >>
> >> I feel that the critical purpose of seccomp is to minimize attack
> >> surface. To that end, I am strongly against anything coming before it
> >> in the syscall path. I really do not want ptrace going first, I think
> >> it's just asking for bugs.
> >
> > I disagree in this case.  There's no actual code surface opened up.
> > If seccomp allows even a single syscall through and there's a ptracer
> > attached, then the ptrace code is exposed.  As far as ptrace is
> > concerned, the syscall number is just a number, and ptrace has
> > basically no awareness of the arguments.
>
> No, I completely disagree: there is a significant amount of surface
> exposed. With a tracer attached there is significantly more happening
> before the filter would be checked. Even less obvious things like
> signal delivery, etc get exposed. Seccomp must be first -- this is
> it's basic design principle. Bugs creep in, unexpected combinations
> creep in, etc. Seccomp must mitigate this and be first on the syscall
> path. The paranoia of this design principle must remain in place, even
> at the expense of some inelegant results.

But this only works if the filter is literally "deny everything".  If
there is even a single syscall allowed and a ptracer is attached, then
the whole ptrace machinery is exposed anyway.

Users who are this paranoid about attack surface need to disable
ptrace, full stop.  If you can do the ptrace(2) syscall, then you can
invoke all the nasty code paths by yourself, and there is nothing
seccomp can do about it.  All seccomp can do is prevent ptrace from
generating a syscall that would otherwise be filtered out.

Let's look at the actual supposed attack surface:


if (unlikely(work & _TIF_SYSCALL_EMU))
ret = -1L;

if ((ret || test_thread_flag(TIF_SYSCALL_TRACE)) &&
tracehook_report_syscall_entry(regs))
ret = -1L;

That's all.

The only way that TIF_SYSCALL_EMU or TIF_SYSCALL_TRACE gets set is if
a ptracer is attached and uses PTRACE_SYSEMU, PTRACE_SYSCALL or
similar.  If that has happened, then there's very, very little that
seccomp can possibly do to reduce attack surface.  First, literally
any syscall that results in SECCOMP_RET_OK will cause all of the same
kernel code paths to run.  Second, most of those code paths can be
triggered without any syscall at all by using PTRACE_SINGLESTEP
instead.

So I challenge you to find a realistic scenario (i.e. something that a
real program might actually program into seccomp) in which running
seccomp before ptrace avoids even a single line of code worth of
attack surface.

On the flip side, 

[PATCH] tty/serial: atmel: fix RS485 half duplex with DMA

[Alexandre Belloni]

When using DMA, half duplex doesn't work properly because rx is not stopped
before starting tx. Ensure we call atmel_stop_rx() in the DMA case.

Signed-off-by: Alexandre Belloni 
---
 drivers/tty/serial/atmel_serial.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index 954941dd8124..f9c798cba83f 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -482,19 +482,21 @@ static void atmel_start_tx(struct uart_port *port)
 {
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-   if (atmel_use_pdc_tx(port)) {
-   if (atmel_uart_readl(port, ATMEL_PDC_PTSR) & ATMEL_PDC_TXTEN)
-   /* The transmitter is already running.  Yes, we
-  really need this.*/
-   return;
+   if (atmel_use_pdc_tx(port) && (atmel_uart_readl(port, ATMEL_PDC_PTSR)
+  & ATMEL_PDC_TXTEN))
+   /* The transmitter is already running.  Yes, we
+  really need this.*/
+   return;
 
+   if (atmel_use_pdc_tx(port) || atmel_use_dma_tx(port))
if ((port->rs485.flags & SER_RS485_ENABLED) &&
!(port->rs485.flags & SER_RS485_RX_DURING_TX))
atmel_stop_rx(port);
 
+   if (atmel_use_pdc_tx(port))
/* re-enable PDC transmit */
atmel_uart_writel(port, ATMEL_PDC_PTCR, ATMEL_PDC_TXTEN);
-   }
+
/* Enable interrupts */
atmel_uart_writel(port, ATMEL_US_IER, atmel_port->tx_done_mask);
 }
-- 
2.8.1

[PATCH] tty/serial: atmel: fix RS485 half duplex with DMA

[Alexandre Belloni]

When using DMA, half duplex doesn't work properly because rx is not stopped
before starting tx. Ensure we call atmel_stop_rx() in the DMA case.

Signed-off-by: Alexandre Belloni 
---
 drivers/tty/serial/atmel_serial.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index 954941dd8124..f9c798cba83f 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -482,19 +482,21 @@ static void atmel_start_tx(struct uart_port *port)
 {
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
 
-   if (atmel_use_pdc_tx(port)) {
-   if (atmel_uart_readl(port, ATMEL_PDC_PTSR) & ATMEL_PDC_TXTEN)
-   /* The transmitter is already running.  Yes, we
-  really need this.*/
-   return;
+   if (atmel_use_pdc_tx(port) && (atmel_uart_readl(port, ATMEL_PDC_PTSR)
+  & ATMEL_PDC_TXTEN))
+   /* The transmitter is already running.  Yes, we
+  really need this.*/
+   return;
 
+   if (atmel_use_pdc_tx(port) || atmel_use_dma_tx(port))
if ((port->rs485.flags & SER_RS485_ENABLED) &&
!(port->rs485.flags & SER_RS485_RX_DURING_TX))
atmel_stop_rx(port);
 
+   if (atmel_use_pdc_tx(port))
/* re-enable PDC transmit */
atmel_uart_writel(port, ATMEL_PDC_PTCR, ATMEL_PDC_TXTEN);
-   }
+
/* Enable interrupts */
atmel_uart_writel(port, ATMEL_US_IER, atmel_port->tx_done_mask);
 }
-- 
2.8.1

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

[David Miller]

From: Nick Alcock 
Date: Fri, 27 May 2016 22:44:56 +0100

> Good move. Segfaulting the process is fine! :) Any process that does
> this sort of thing is clearly either terminally buggy, written by an
> idiot who doesn't know what he's doing (i.e. my original patch) or
> malicious. These all deserve SEGVs.
> 
> (I still don't understand why this leads to spurious TLB faults, though.
> Filling the userland CPU registers with garbage is bad, but should still
> be reasonably harmless to the kernel, surely?)

I'm trying to figure out the same thing myself.

Even the unaligned stack pointer should be gracefully handled by the
kernel, so I think it has to be some other element of the register
state restore sequence.

The one area that deserves auditing is %tstate.  This is a privileged
register which we treat partially as non-privileged.  Specifically we
allow the user to modify the condition codes and the %asi register
which is encoded into here.

But I just went over that a few times.  We are really careful to mask
and only change those specific fields.

I'll keep plugging away at this and also play with your patches to
reproduce the bug.

Re: [4.1.x -- 4.6.x and probably HEAD] Reproducible unprivileged panic/TLB BUG on sparc via a stack-protected rt_sigaction() ka_restorer, courtesy of the glibc testsuite

[David Miller]

From: Nick Alcock 
Date: Fri, 27 May 2016 22:44:56 +0100

> Good move. Segfaulting the process is fine! :) Any process that does
> this sort of thing is clearly either terminally buggy, written by an
> idiot who doesn't know what he's doing (i.e. my original patch) or
> malicious. These all deserve SEGVs.
> 
> (I still don't understand why this leads to spurious TLB faults, though.
> Filling the userland CPU registers with garbage is bad, but should still
> be reasonably harmless to the kernel, surely?)

I'm trying to figure out the same thing myself.

Even the unaligned stack pointer should be gracefully handled by the
kernel, so I think it has to be some other element of the register
state restore sequence.

The one area that deserves auditing is %tstate.  This is a privileged
register which we treat partially as non-privileged.  Specifically we
allow the user to modify the condition codes and the %asi register
which is encoded into here.

But I just went over that a few times.  We are really careful to mask
and only change those specific fields.

I'll keep plugging away at this and also play with your patches to
reproduce the bug.

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

[Casey Schaufler]

On 5/27/2016 1:24 PM, Al Viro wrote:
> On Fri, May 27, 2016 at 12:48:23PM -0700, Linus Torvalds wrote:
>> On Fri, May 27, 2016 at 12:43 PM, Al Viro  wrote:
>>> Amended and force-pushed...
>> Ok, I'll ignore that branch for now, in the hopes that there will be
>> actual testing success. Please send a full pull request at that point,
>> ok?
> Sure.  FWIW, the original bug report had been from +0900, so it's what,
> about 5am Saturday morning there?  Let's hope somebody will be there
> today, weekend or not...
>
Al, I have verified that upstream has the problem and that
your vfs.git smack-fix branch works correctly.

Re: [BUG] Panic when systemd boot do mkdir on tmpfs mounted path with smack enabled environment

[Casey Schaufler]

On 5/27/2016 1:24 PM, Al Viro wrote:
> On Fri, May 27, 2016 at 12:48:23PM -0700, Linus Torvalds wrote:
>> On Fri, May 27, 2016 at 12:43 PM, Al Viro  wrote:
>>> Amended and force-pushed...
>> Ok, I'll ignore that branch for now, in the hopes that there will be
>> actual testing success. Please send a full pull request at that point,
>> ok?
> Sure.  FWIW, the original bug report had been from +0900, so it's what,
> about 5am Saturday morning there?  Let's hope somebody will be there
> today, weekend or not...
>
Al, I have verified that upstream has the problem and that
your vfs.git smack-fix branch works correctly.

Re: [PATCH] fpga: zynq-fpga: fix build failure

[Moritz Fischer]

Hi Sudip,

On Fri, May 27, 2016 at 3:55 AM, Sudip Mukherjee
 wrote:
> While building m32r allmodconfig the build is failing with the error:
> ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined!
>
> Xilinx Zynq FPGA is using DMA but there was no dependency while
> building.
>
> Signed-off-by: Sudip Mukherjee 
Acked-by: Moritz Fischer 

Thanks,

Moritz

Re: [PATCH] fpga: zynq-fpga: fix build failure

[Moritz Fischer]

Hi Sudip,

On Fri, May 27, 2016 at 3:55 AM, Sudip Mukherjee
 wrote:
> While building m32r allmodconfig the build is failing with the error:
> ERROR: "bad_dma_ops" [drivers/fpga/zynq-fpga.ko] undefined!
>
> Xilinx Zynq FPGA is using DMA but there was no dependency while
> building.
>
> Signed-off-by: Sudip Mukherjee 
Acked-by: Moritz Fischer 

Thanks,

Moritz

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

[Kees Cook]

On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski  wrote:
> On May 27, 2016 11:42 AM, "Kees Cook"  wrote:
>>
>> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski  wrote:
>> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook  wrote:
>> >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski  
>> >> wrote:
>> >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook  wrote:
>>  One problem with seccomp was that ptrace could be used to change a
>>  syscall after seccomp filtering had completed. This was a well 
>>  documented
>>  limitation, and it was recommended to block ptrace when defining a 
>>  filter
>>  to avoid this problem. This can be quite a limitation for containers or
>>  other places where ptrace is desired even under seccomp filters.
>> 
>>  Since seccomp filtering has been split into pre-trace and trace phases
>>  (phase1 and phase2 respectively), it's possible to re-run phase1 seccomp
>>  after ptrace. This makes that change, and updates the test suite for
>>  both SECCOMP_RET_TRACE and PTRACE_SYSCALL manipulation.
>> >>>
>> >>> I like fixing the hole, but I don't like this fix.
>> >>>
>> >>> The two-phase seccomp mechanism is messy.  I wrote it because it was a
>> >>> huge speedup.  Since then, I've made a ton of changes to the way that
>> >>> x86 syscalls work, and there are two relevant effects: the slow path
>> >>> is quite fast, and the phase-1-only path isn't really a win any more.
>> >>>
>> >>> I suggest that we fix the by simplifying the code instead of making it
>> >>> even more complicated.  Let's back out the two-phase mechanism (but
>> >>> keep the ability for arch code to supply seccomp_data) and then just
>> >>> reorder it so that seccomp happens after ptrace.  The result should be
>> >>> considerably simpler.  (We'll still have to answer the question of
>> >>> what happens when a SECCOMP_RET_TRACE event changes the syscall, but
>> >>> maybe the answer is to just let it through -- after all,
>> >>> SECCOMP_RET_TRACE might be a request by a tracer to do its own
>> >>> internal filtering.)
>> >>
>> >> I'm really against this. I think seccomp needs to stay first,
>> >
>> > Why?  What use case is improved with it going first?
>>
>> I feel that the critical purpose of seccomp is to minimize attack
>> surface. To that end, I am strongly against anything coming before it
>> in the syscall path. I really do not want ptrace going first, I think
>> it's just asking for bugs.
>
> I disagree in this case.  There's no actual code surface opened up.
> If seccomp allows even a single syscall through and there's a ptracer
> attached, then the ptrace code is exposed.  As far as ptrace is
> concerned, the syscall number is just a number, and ptrace has
> basically no awareness of the arguments.

No, I completely disagree: there is a significant amount of surface
exposed. With a tracer attached there is significantly more happening
before the filter would be checked. Even less obvious things like
signal delivery, etc get exposed. Seccomp must be first -- this is
it's basic design principle. Bugs creep in, unexpected combinations
creep in, etc. Seccomp must mitigate this and be first on the syscall
path. The paranoia of this design principle must remain in place, even
at the expense of some inelegant results.

>> >> and I
>> >> like the two-phase split because it gives us a lot of flexibility on
>> >> other architectures.
>> >
>> > I thought so too when I wrote it, and I even tried a bit to evangelize
>> > it to other arch maintainers.  So far, it's used *only* in x86, and it
>> > would IMO be a cleanup to stop using it in x86 now.  Given my
>> > experience cleanup up the x86 syscall path, my current advice to other
>> > arch maintainers would be to try hard to avoid having a context in
>> > which syscall args are known but ptrace can't be invoked (as x86 had
>> > before Linux 4.5).
>>
>> Well, I've got most of the ARM 2-phase port done, but haven't gotten
>> it all the way finished. But I could be talked into removing the
>> 2-phase just from the perspective of reducing complexity.
>
> Does it help anything?  It's certainly more complex and harder to audit.
>
> On x86, it used to save hundreds of cycles.  Now it's probably five
> cycles or so at most.  It could even be a loss because of increased
> code size.

Yeah, on ARM I wasn't seeing much benefit, so I'm okay with dropping 2-phase.

>> >> And we can't just let through RET_TRACE because
>> >> we'll have exactly the same problem: a process can add a RET_TRACE
>> >> filter for some syscall and then change it arbitrarily to escape the
>> >> filtering. The non-trace returns of seccomp need to be check first and
>> >> after ptrace manipulations. The patch seems like the best approach and
>> >> it covers all the corners.
>> >
>> > But RET_TRACE really is special.
>> >
>> > Suppose you have a 

Re: [PATCH] seccomp: plug syscall-dodging ptrace hole

[Kees Cook]

On Fri, May 27, 2016 at 12:52 PM, Andy Lutomirski  wrote:
> On May 27, 2016 11:42 AM, "Kees Cook"  wrote:
>>
>> On Thu, May 26, 2016 at 9:45 PM, Andy Lutomirski  wrote:
>> > On Thu, May 26, 2016 at 7:41 PM, Kees Cook  wrote:
>> >> On Thu, May 26, 2016 at 7:10 PM, Andy Lutomirski  
>> >> wrote:
>> >>> On Thu, May 26, 2016 at 2:04 PM, Kees Cook  wrote:
>>  One problem with seccomp was that ptrace could be used to change a
>>  syscall after seccomp filtering had completed. This was a well 
>>  documented
>>  limitation, and it was recommended to block ptrace when defining a 
>>  filter
>>  to avoid this problem. This can be quite a limitation for containers or
>>  other places where ptrace is desired even under seccomp filters.
>> 
>>  Since seccomp filtering has been split into pre-trace and trace phases
>>  (phase1 and phase2 respectively), it's possible to re-run phase1 seccomp
>>  after ptrace. This makes that change, and updates the test suite for
>>  both SECCOMP_RET_TRACE and PTRACE_SYSCALL manipulation.
>> >>>
>> >>> I like fixing the hole, but I don't like this fix.
>> >>>
>> >>> The two-phase seccomp mechanism is messy.  I wrote it because it was a
>> >>> huge speedup.  Since then, I've made a ton of changes to the way that
>> >>> x86 syscalls work, and there are two relevant effects: the slow path
>> >>> is quite fast, and the phase-1-only path isn't really a win any more.
>> >>>
>> >>> I suggest that we fix the by simplifying the code instead of making it
>> >>> even more complicated.  Let's back out the two-phase mechanism (but
>> >>> keep the ability for arch code to supply seccomp_data) and then just
>> >>> reorder it so that seccomp happens after ptrace.  The result should be
>> >>> considerably simpler.  (We'll still have to answer the question of
>> >>> what happens when a SECCOMP_RET_TRACE event changes the syscall, but
>> >>> maybe the answer is to just let it through -- after all,
>> >>> SECCOMP_RET_TRACE might be a request by a tracer to do its own
>> >>> internal filtering.)
>> >>
>> >> I'm really against this. I think seccomp needs to stay first,
>> >
>> > Why?  What use case is improved with it going first?
>>
>> I feel that the critical purpose of seccomp is to minimize attack
>> surface. To that end, I am strongly against anything coming before it
>> in the syscall path. I really do not want ptrace going first, I think
>> it's just asking for bugs.
>
> I disagree in this case.  There's no actual code surface opened up.
> If seccomp allows even a single syscall through and there's a ptracer
> attached, then the ptrace code is exposed.  As far as ptrace is
> concerned, the syscall number is just a number, and ptrace has
> basically no awareness of the arguments.

No, I completely disagree: there is a significant amount of surface
exposed. With a tracer attached there is significantly more happening
before the filter would be checked. Even less obvious things like
signal delivery, etc get exposed. Seccomp must be first -- this is
it's basic design principle. Bugs creep in, unexpected combinations
creep in, etc. Seccomp must mitigate this and be first on the syscall
path. The paranoia of this design principle must remain in place, even
at the expense of some inelegant results.

>> >> and I
>> >> like the two-phase split because it gives us a lot of flexibility on
>> >> other architectures.
>> >
>> > I thought so too when I wrote it, and I even tried a bit to evangelize
>> > it to other arch maintainers.  So far, it's used *only* in x86, and it
>> > would IMO be a cleanup to stop using it in x86 now.  Given my
>> > experience cleanup up the x86 syscall path, my current advice to other
>> > arch maintainers would be to try hard to avoid having a context in
>> > which syscall args are known but ptrace can't be invoked (as x86 had
>> > before Linux 4.5).
>>
>> Well, I've got most of the ARM 2-phase port done, but haven't gotten
>> it all the way finished. But I could be talked into removing the
>> 2-phase just from the perspective of reducing complexity.
>
> Does it help anything?  It's certainly more complex and harder to audit.
>
> On x86, it used to save hundreds of cycles.  Now it's probably five
> cycles or so at most.  It could even be a loss because of increased
> code size.

Yeah, on ARM I wasn't seeing much benefit, so I'm okay with dropping 2-phase.

>> >> And we can't just let through RET_TRACE because
>> >> we'll have exactly the same problem: a process can add a RET_TRACE
>> >> filter for some syscall and then change it arbitrarily to escape the
>> >> filtering. The non-trace returns of seccomp need to be check first and
>> >> after ptrace manipulations. The patch seems like the best approach and
>> >> it covers all the corners.
>> >
>> > But RET_TRACE really is special.
>> >
>> > Suppose you have a tracer and you use SECCOMP_RET_TRACE.  If the
>> > tracer sees a syscall, approves, and calls PTRACE_CONT, then the
>> > syscall 

[PATCH v2 2/2] iommu/vt-d: use marco for dmar_domain's second level size and shift

[Wei Yang]

In the origin commit, the size of the second level is hard coded to an
integer, 256.

This patch defines two marco for the second level size and shift.

Signed-off-by: Wei Yang 
---
 drivers/iommu/intel-iommu.c | 12 ++--
 include/linux/intel-iommu.h |  2 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 1c8b587..dd050d7 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -616,7 +616,7 @@ static struct kmem_cache *iommu_devinfo_cache;
 static struct dmar_domain* get_iommu_domain(struct intel_iommu *iommu, u16 did)
 {
struct dmar_domain **domains;
-   int idx = did >> 8;
+   int idx = did >> DMAR_DOMS_SHIFT;
 
domains = iommu->domains[idx];
if (!domains)
@@ -629,10 +629,10 @@ static void set_iommu_domain(struct intel_iommu *iommu, 
u16 did,
 struct dmar_domain *domain)
 {
struct dmar_domain **domains;
-   int idx = did >> 8;
+   int idx = did >> DMAR_DOMS_SHIFT;
 
if (!iommu->domains[idx]) {
-   size_t size = 256 * sizeof(struct dmar_domain *);
+   size_t size = DMAR_DOMS_SIZE * sizeof(struct dmar_domain *);
iommu->domains[idx] = kzalloc(size, GFP_ATOMIC);
}
 
@@ -1634,11 +1634,11 @@ static int iommu_init_domains(struct intel_iommu *iommu)
return -ENOMEM;
}
 
-   size = DIV_ROUND_UP(ndomains, 256) * sizeof(struct dmar_domain **);
+   size = DIV_ROUND_UP(ndomains, DMAR_DOMS_SIZE) * sizeof(struct 
dmar_domain **);
iommu->domains = kzalloc(size, GFP_KERNEL);
 
if (iommu->domains) {
-   size = 256 * sizeof(struct dmar_domain *);
+   size = DMAR_DOMS_SIZE * sizeof(struct dmar_domain *);
iommu->domains[0] = kzalloc(size, GFP_KERNEL);
}
 
@@ -1699,7 +1699,7 @@ static void disable_dmar_iommu(struct intel_iommu *iommu)
 static void free_dmar_iommu(struct intel_iommu *iommu)
 {
if ((iommu->domains) && (iommu->domain_ids)) {
-   int elems = DIV_ROUND_UP(cap_ndoms(iommu->cap), 256);
+   int elems = DIV_ROUND_UP(cap_ndoms(iommu->cap), DMAR_DOMS_SIZE);
int i;
 
for (i = 0; i < elems; i++)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 2d9b650..afcb7bf 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -412,6 +412,8 @@ struct intel_iommu {
 
 #ifdef CONFIG_INTEL_IOMMU
unsigned long   *domain_ids; /* bitmap of domains */
+#define DMAR_DOMS_SHIFT 8
+#define DMAR_DOMS_SIZE (1 << DMAR_DOMS_SHIFT )
struct dmar_domain ***domains; /* ptr to domains */
spinlock_t  lock; /* protect context, domain ids */
struct root_entry *root_entry; /* virtual address */
-- 
2.5.0

[PATCH v2 2/2] iommu/vt-d: use marco for dmar_domain's second level size and shift

[Wei Yang]

In the origin commit, the size of the second level is hard coded to an
integer, 256.

This patch defines two marco for the second level size and shift.

Signed-off-by: Wei Yang 
---
 drivers/iommu/intel-iommu.c | 12 ++--
 include/linux/intel-iommu.h |  2 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 1c8b587..dd050d7 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -616,7 +616,7 @@ static struct kmem_cache *iommu_devinfo_cache;
 static struct dmar_domain* get_iommu_domain(struct intel_iommu *iommu, u16 did)
 {
struct dmar_domain **domains;
-   int idx = did >> 8;
+   int idx = did >> DMAR_DOMS_SHIFT;
 
domains = iommu->domains[idx];
if (!domains)
@@ -629,10 +629,10 @@ static void set_iommu_domain(struct intel_iommu *iommu, 
u16 did,
 struct dmar_domain *domain)
 {
struct dmar_domain **domains;
-   int idx = did >> 8;
+   int idx = did >> DMAR_DOMS_SHIFT;
 
if (!iommu->domains[idx]) {
-   size_t size = 256 * sizeof(struct dmar_domain *);
+   size_t size = DMAR_DOMS_SIZE * sizeof(struct dmar_domain *);
iommu->domains[idx] = kzalloc(size, GFP_ATOMIC);
}
 
@@ -1634,11 +1634,11 @@ static int iommu_init_domains(struct intel_iommu *iommu)
return -ENOMEM;
}
 
-   size = DIV_ROUND_UP(ndomains, 256) * sizeof(struct dmar_domain **);
+   size = DIV_ROUND_UP(ndomains, DMAR_DOMS_SIZE) * sizeof(struct 
dmar_domain **);
iommu->domains = kzalloc(size, GFP_KERNEL);
 
if (iommu->domains) {
-   size = 256 * sizeof(struct dmar_domain *);
+   size = DMAR_DOMS_SIZE * sizeof(struct dmar_domain *);
iommu->domains[0] = kzalloc(size, GFP_KERNEL);
}
 
@@ -1699,7 +1699,7 @@ static void disable_dmar_iommu(struct intel_iommu *iommu)
 static void free_dmar_iommu(struct intel_iommu *iommu)
 {
if ((iommu->domains) && (iommu->domain_ids)) {
-   int elems = DIV_ROUND_UP(cap_ndoms(iommu->cap), 256);
+   int elems = DIV_ROUND_UP(cap_ndoms(iommu->cap), DMAR_DOMS_SIZE);
int i;
 
for (i = 0; i < elems; i++)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 2d9b650..afcb7bf 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -412,6 +412,8 @@ struct intel_iommu {
 
 #ifdef CONFIG_INTEL_IOMMU
unsigned long   *domain_ids; /* bitmap of domains */
+#define DMAR_DOMS_SHIFT 8
+#define DMAR_DOMS_SIZE (1 << DMAR_DOMS_SHIFT )
struct dmar_domain ***domains; /* ptr to domains */
spinlock_t  lock; /* protect context, domain ids */
struct root_entry *root_entry; /* virtual address */
-- 
2.5.0

[PATCH v2 1/2] iommu/vt-d: reduce extra first level entry in iommu->domains

[Wei Yang]

In commit <8bf478163e69> ("iommu/vt-d: Split up iommu->domains array"), it
it splits iommu->domains in two levels. Each first level contains 256
entries of second level. In case of the ndomains is exact a multiple of
256, it would have one more extra first level entry for current
implementation.

This patch refines this calculation to reduce the extra first level entry
when ndomains is exact a multiple of 256.

Signed-off-by: Wei Yang 
---
 drivers/iommu/intel-iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d7fa268..1c8b587 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1634,7 +1634,7 @@ static int iommu_init_domains(struct intel_iommu *iommu)
return -ENOMEM;
}
 
-   size = ((ndomains >> 8) + 1) * sizeof(struct dmar_domain **);
+   size = DIV_ROUND_UP(ndomains, 256) * sizeof(struct dmar_domain **);
iommu->domains = kzalloc(size, GFP_KERNEL);
 
if (iommu->domains) {
@@ -1699,7 +1699,7 @@ static void disable_dmar_iommu(struct intel_iommu *iommu)
 static void free_dmar_iommu(struct intel_iommu *iommu)
 {
if ((iommu->domains) && (iommu->domain_ids)) {
-   int elems = (cap_ndoms(iommu->cap) >> 8) + 1;
+   int elems = DIV_ROUND_UP(cap_ndoms(iommu->cap), 256);
int i;
 
for (i = 0; i < elems; i++)
-- 
2.5.0

[PATCH v2 1/2] iommu/vt-d: reduce extra first level entry in iommu->domains

[Wei Yang]

In commit <8bf478163e69> ("iommu/vt-d: Split up iommu->domains array"), it
it splits iommu->domains in two levels. Each first level contains 256
entries of second level. In case of the ndomains is exact a multiple of
256, it would have one more extra first level entry for current
implementation.

This patch refines this calculation to reduce the extra first level entry
when ndomains is exact a multiple of 256.

Signed-off-by: Wei Yang 
---
 drivers/iommu/intel-iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index d7fa268..1c8b587 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -1634,7 +1634,7 @@ static int iommu_init_domains(struct intel_iommu *iommu)
return -ENOMEM;
}
 
-   size = ((ndomains >> 8) + 1) * sizeof(struct dmar_domain **);
+   size = DIV_ROUND_UP(ndomains, 256) * sizeof(struct dmar_domain **);
iommu->domains = kzalloc(size, GFP_KERNEL);
 
if (iommu->domains) {
@@ -1699,7 +1699,7 @@ static void disable_dmar_iommu(struct intel_iommu *iommu)
 static void free_dmar_iommu(struct intel_iommu *iommu)
 {
if ((iommu->domains) && (iommu->domain_ids)) {
-   int elems = (cap_ndoms(iommu->cap) >> 8) + 1;
+   int elems = DIV_ROUND_UP(cap_ndoms(iommu->cap), 256);
int i;
 
for (i = 0; i < elems; i++)
-- 
2.5.0

[PATCH v2 0/2] fix and cleanup for iommu/vt-d

[Wei Yang]

The first patch tries to improve the calculation of the dmar_domain first
level entry.

The second patch defines two marco for dmar_domains second level size and
shift instead of using an integer.

---
v2:
* use DIV_ROUND_UP instead of ALIGN for the calculation.
  Thanks Robin Murphy 
* adds patch 2 for comment


Wei Yang (2):
  iommu/vt-d: reduce extra first level entry in iommu->domains
  iommu/vt-d: use marco for dmar_domain's second level size and shift

 drivers/iommu/intel-iommu.c | 12 ++--
 include/linux/intel-iommu.h |  2 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.5.0

[PATCH v2 0/2] fix and cleanup for iommu/vt-d

[Wei Yang]

The first patch tries to improve the calculation of the dmar_domain first
level entry.

The second patch defines two marco for dmar_domains second level size and
shift instead of using an integer.

---
v2:
* use DIV_ROUND_UP instead of ALIGN for the calculation.
  Thanks Robin Murphy 
* adds patch 2 for comment


Wei Yang (2):
  iommu/vt-d: reduce extra first level entry in iommu->domains
  iommu/vt-d: use marco for dmar_domain's second level size and shift

 drivers/iommu/intel-iommu.c | 12 ++--
 include/linux/intel-iommu.h |  2 ++
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.5.0

mmotm 2016-05-27-15-19 uploaded

[akpm]

The mm-of-the-moment snapshot 2016-05-27-15-19 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.6:
(patches marked "*" will be included in linux-next)

  origin.patch
* ocfs2-o2hb-add-negotiate-timer.patch
* ocfs2-o2hb-add-nego_timeout-message.patch
* ocfs2-o2hb-add-negotiate_approve-message.patch
* ocfs2-o2hb-add-some-user-debug-log.patch
* ocfs2-o2hb-dont-negotiate-if-last-hb-fail.patch
* ocfs2-o2hb-fix-hb-hung-time.patch
* ocfs2-bump-up-o2cb-network-protocol-version.patch
* 
direct-io-fix-direct-write-stale-data-exposure-from-concurrent-buffered-read.patch
* mm-oom-do-not-reap-task-if-there-are-live-threads-in-threadgroup.patch
* maintainers-add-kexec_corec-and-kexec_filec.patch
* maintainers-kdump-maintainers-update.patch
* mm-use-early_pfn_to_nid-in-page_ext_init.patch
* mm-use-early_pfn_to_nid-in-register_page_bootmem_info_node.patch
* oom_reaper-close-race-with-exiting-task.patch
* mm-thp-avoid-false-positive-vm_bug_on_page-in-page_move_anon_rmap.patch
* mm-cma-silence-warnings-due-to-max-usage.patch
* mm-memcontrol-fix-the-margin-computation-in-mem_cgroup_margin.patch
* mm-memcontrol-move-comments-for-get_mctgt_type-to-proper-position.patch
* mm-disable-deferred_struct_page_init-on-no_bootmem.patch
  i-need-old-gcc.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
* mm-fix-overflow-in-vm_map_ram.patch
* mm-fix-overflow-in-vm_map_ram-fix.patch
* kdump-fix-dmesg-gdbmacro-to-work-with-record-based-printk.patch
* mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites.patch
* reiserfs-avoid-uninitialized-variable-use.patch
* 
memcg-add-rcu-locking-around-css_for_each_descendant_pre-in-memcg_offline_kmem.patch
* z3fold-avoid-modifying-headless-page-and-minor-cleanup.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch
* ocfs2-fix-a-redundant-re-initialization.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
  mm.patch
* mm-memcontrol-remove-the-useless-parameter-for-mc_handle_swap_pte.patch
* mm-init-fix-zone-boundary-creation.patch
* memory-hotplug-add-move_pfn_range.patch
* memory-hotplug-more-general-validation-of-zone-during-online.patch
* memory-hotplug-use-zone_can_shift-for-sysfs-valid_zones-attribute.patch
* mm-zap-zone_oom_locked.patch
* mm-oom-add-memcg-to-oom_control.patch
* mm-memblock-if-nr_new-is-0-just-return.patch
* mm-make-optimistic-check-for-swapin-readahead.patch
* mm-make-optimistic-check-for-swapin-readahead-fix-2.patch
* mm-make-optimistic-check-for-swapin-readahead-fix-3.patch
* mm-make-swapin-readahead-to-improve-thp-collapse-rate.patch
* 

mmotm 2016-05-27-15-19 uploaded

[akpm]

The mm-of-the-moment snapshot 2016-05-27-15-19 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (4.x
or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 4.6:
(patches marked "*" will be included in linux-next)

  origin.patch
* ocfs2-o2hb-add-negotiate-timer.patch
* ocfs2-o2hb-add-nego_timeout-message.patch
* ocfs2-o2hb-add-negotiate_approve-message.patch
* ocfs2-o2hb-add-some-user-debug-log.patch
* ocfs2-o2hb-dont-negotiate-if-last-hb-fail.patch
* ocfs2-o2hb-fix-hb-hung-time.patch
* ocfs2-bump-up-o2cb-network-protocol-version.patch
* 
direct-io-fix-direct-write-stale-data-exposure-from-concurrent-buffered-read.patch
* mm-oom-do-not-reap-task-if-there-are-live-threads-in-threadgroup.patch
* maintainers-add-kexec_corec-and-kexec_filec.patch
* maintainers-kdump-maintainers-update.patch
* mm-use-early_pfn_to_nid-in-page_ext_init.patch
* mm-use-early_pfn_to_nid-in-register_page_bootmem_info_node.patch
* oom_reaper-close-race-with-exiting-task.patch
* mm-thp-avoid-false-positive-vm_bug_on_page-in-page_move_anon_rmap.patch
* mm-cma-silence-warnings-due-to-max-usage.patch
* mm-memcontrol-fix-the-margin-computation-in-mem_cgroup_margin.patch
* mm-memcontrol-move-comments-for-get_mctgt_type-to-proper-position.patch
* mm-disable-deferred_struct_page_init-on-no_bootmem.patch
  i-need-old-gcc.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
* mm-fix-overflow-in-vm_map_ram.patch
* mm-fix-overflow-in-vm_map_ram-fix.patch
* kdump-fix-dmesg-gdbmacro-to-work-with-record-based-printk.patch
* mm-check-the-return-value-of-lookup_page_ext-for-all-call-sites.patch
* reiserfs-avoid-uninitialized-variable-use.patch
* 
memcg-add-rcu-locking-around-css_for_each_descendant_pre-in-memcg_offline_kmem.patch
* z3fold-avoid-modifying-headless-page-and-minor-cleanup.patch
* arm-arch-arm-include-asm-pageh-needs-personalityh.patch
* fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch
* ocfs2-fix-a-redundant-re-initialization.patch
* 
block-restore-proc-partitions-to-not-display-non-partitionable-removable-devices.patch
  mm.patch
* mm-memcontrol-remove-the-useless-parameter-for-mc_handle_swap_pte.patch
* mm-init-fix-zone-boundary-creation.patch
* memory-hotplug-add-move_pfn_range.patch
* memory-hotplug-more-general-validation-of-zone-during-online.patch
* memory-hotplug-use-zone_can_shift-for-sysfs-valid_zones-attribute.patch
* mm-zap-zone_oom_locked.patch
* mm-oom-add-memcg-to-oom_control.patch
* mm-memblock-if-nr_new-is-0-just-return.patch
* mm-make-optimistic-check-for-swapin-readahead.patch
* mm-make-optimistic-check-for-swapin-readahead-fix-2.patch
* mm-make-optimistic-check-for-swapin-readahead-fix-3.patch
* mm-make-swapin-readahead-to-improve-thp-collapse-rate.patch
* 

Re: [PATCH v2 0/3] ACPI / button: Clarify initial lid state

[Valdis . Kletnieks]

On Fri, 27 May 2016 15:15:43 +0800, Lv Zheng said:
> The initial _LID returning value is not reliable after boot/resume because
> the BIOS vendors may implement it by returning a cached value that is only
> updated when a lid notification is received.
> This causes strange things happening after resuming. This patchset fixes
> the issue according to this fact.
>
> Lv Zheng (3):
>   ACPI / button: Remove initial lid state notification
>   ACPI / button: Refactor functions to eliminate redundant code
>   ACPI / button: Send "open" state after boot/resume

If it sends an "open" status, what happens if the machine was in fact
suspended with lid open, but is then resumed in a dock with an external
monitor?

(I'd test it myself, but I don't have suspend/resume configured on my laptop)


pgpPc2GIKWdye.pgp
Description: PGP signature

Re: [PATCH v2 0/3] ACPI / button: Clarify initial lid state

[Valdis . Kletnieks]

On Fri, 27 May 2016 15:15:43 +0800, Lv Zheng said:
> The initial _LID returning value is not reliable after boot/resume because
> the BIOS vendors may implement it by returning a cached value that is only
> updated when a lid notification is received.
> This causes strange things happening after resuming. This patchset fixes
> the issue according to this fact.
>
> Lv Zheng (3):
>   ACPI / button: Remove initial lid state notification
>   ACPI / button: Refactor functions to eliminate redundant code
>   ACPI / button: Send "open" state after boot/resume

If it sends an "open" status, what happens if the machine was in fact
suspended with lid open, but is then resumed in a dock with an external
monitor?

(I'd test it myself, but I don't have suspend/resume configured on my laptop)


pgpPc2GIKWdye.pgp
Description: PGP signature

[PATCH v5 4/4] watchdog: ebc-c384_wdt: Allow build for X86_64

[William Breathitt Gray]

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the WinSystems EBC-C384 watchdog timer
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Wim Van Sebroeck 
Reviewed-by: Guenter Roeck 
Signed-off-by: William Breathitt Gray 
---
 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b54f26c..b4b3e25 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -746,7 +746,7 @@ config ALIM7101_WDT
 
 config EBC_C384_WDT
tristate "WinSystems EBC-C384 Watchdog Timer"
-   depends on X86 && ISA
+   depends on X86 && ISA_BUS_API
select WATCHDOG_CORE
help
  Enables watchdog timer support for the watchdog timer on the
-- 
2.7.3

[PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64

[William Breathitt Gray]

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
allowing them to build for X86_64 as they are expected to.

Cc: Alexandre Courbot 
Cc: Linus Walleij 
Reviewed-by: Guenter Roeck 
Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 48da857..dc6da77 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
 
 config GPIO_104_DIO_48E
tristate "ACCES 104-DIO-48E GPIO support"
-   depends on ISA
+   depends on ISA_BUS_API
select GPIOLIB_IRQCHIP
help
  Enables GPIO support for the ACCES 104-DIO-48E series (104-DIO-48E,
@@ -540,7 +540,7 @@ config GPIO_104_DIO_48E
 
 config GPIO_104_IDIO_16
tristate "ACCES 104-IDIO-16 GPIO support"
-   depends on ISA
+   depends on ISA_BUS_API
select GPIOLIB_IRQCHIP
help
  Enables GPIO support for the ACCES 104-IDIO-16 family (104-IDIO-16,
@@ -551,7 +551,7 @@ config GPIO_104_IDIO_16
 
 config GPIO_104_IDI_48
tristate "ACCES 104-IDI-48 GPIO support"
-   depends on ISA
+   depends on ISA_BUS_API
select GPIOLIB_IRQCHIP
help
  Enables GPIO support for the ACCES 104-IDI-48 family (104-IDI-48A,
@@ -627,7 +627,7 @@ config GPIO_TS5500
 
 config GPIO_WS16C48
tristate "WinSystems WS16C48 GPIO support"
-   depends on ISA
+   depends on ISA_BUS_API
select GPIOLIB_IRQCHIP
help
  Enables GPIO support for the WinSystems WS16C48. The base port
-- 
2.7.3

[PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64

[William Breathitt Gray]

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus
allowing them to build for X86_64 as they are expected to.

Cc: Alexandre Courbot 
Cc: Linus Walleij 
Reviewed-by: Guenter Roeck 
Signed-off-by: William Breathitt Gray 
---
 drivers/gpio/Kconfig | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 48da857..dc6da77 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -530,7 +530,7 @@ menu "Port-mapped I/O GPIO drivers"
 
 config GPIO_104_DIO_48E
tristate "ACCES 104-DIO-48E GPIO support"
-   depends on ISA
+   depends on ISA_BUS_API
select GPIOLIB_IRQCHIP
help
  Enables GPIO support for the ACCES 104-DIO-48E series (104-DIO-48E,
@@ -540,7 +540,7 @@ config GPIO_104_DIO_48E
 
 config GPIO_104_IDIO_16
tristate "ACCES 104-IDIO-16 GPIO support"
-   depends on ISA
+   depends on ISA_BUS_API
select GPIOLIB_IRQCHIP
help
  Enables GPIO support for the ACCES 104-IDIO-16 family (104-IDIO-16,
@@ -551,7 +551,7 @@ config GPIO_104_IDIO_16
 
 config GPIO_104_IDI_48
tristate "ACCES 104-IDI-48 GPIO support"
-   depends on ISA
+   depends on ISA_BUS_API
select GPIOLIB_IRQCHIP
help
  Enables GPIO support for the ACCES 104-IDI-48 family (104-IDI-48A,
@@ -627,7 +627,7 @@ config GPIO_TS5500
 
 config GPIO_WS16C48
tristate "WinSystems WS16C48 GPIO support"
-   depends on ISA
+   depends on ISA_BUS_API
select GPIOLIB_IRQCHIP
help
  Enables GPIO support for the WinSystems WS16C48. The base port
-- 
2.7.3

[PATCH v5 4/4] watchdog: ebc-c384_wdt: Allow build for X86_64

[William Breathitt Gray]

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the WinSystems EBC-C384 watchdog timer
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Wim Van Sebroeck 
Reviewed-by: Guenter Roeck 
Signed-off-by: William Breathitt Gray 
---
 drivers/watchdog/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index b54f26c..b4b3e25 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -746,7 +746,7 @@ config ALIM7101_WDT
 
 config EBC_C384_WDT
tristate "WinSystems EBC-C384 Watchdog Timer"
-   depends on X86 && ISA
+   depends on X86 && ISA_BUS_API
select WATCHDOG_CORE
help
  Enables watchdog timer support for the watchdog timer on the
-- 
2.7.3

[PATCH v5 3/4] iio: stx104: Allow build for X86_64

[William Breathitt Gray]

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Hartmut Knaack 
Cc: Lars-Peter Clausen 
Cc: Peter Meerwald-Stadler 
Cc: Jonathan Cameron 
Reviewed-by: Guenter Roeck 
Signed-off-by: William Breathitt Gray 
---
 drivers/iio/dac/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index e63b957..f7c71da 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -247,7 +247,7 @@ config MCP4922
 
 config STX104
tristate "Apex Embedded Systems STX104 DAC driver"
-   depends on X86 && ISA
+   depends on X86 && ISA_BUS_API
help
  Say yes here to build support for the 2-channel DAC on the Apex
  Embedded Systems STX104 integrated analog PC/104 card. The base port
-- 
2.7.3

[PATCH v5 3/4] iio: stx104: Allow build for X86_64

[William Breathitt Gray]

With the introduction of the ISA_BUS_API Kconfig option, ISA-style
drivers may be built for X86_64 architectures. This patch changes the
ISA Kconfig option dependency of the Apex Embedded Systems STX104 DAC
driver to ISA_BUS_API, thus allowing it to build for X86_64 as it is
expected to.

Cc: Hartmut Knaack 
Cc: Lars-Peter Clausen 
Cc: Peter Meerwald-Stadler 
Cc: Jonathan Cameron 
Reviewed-by: Guenter Roeck 
Signed-off-by: William Breathitt Gray 
---
 drivers/iio/dac/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index e63b957..f7c71da 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -247,7 +247,7 @@ config MCP4922
 
 config STX104
tristate "Apex Embedded Systems STX104 DAC driver"
-   depends on X86 && ISA
+   depends on X86 && ISA_BUS_API
help
  Say yes here to build support for the 2-channel DAC on the Apex
  Embedded Systems STX104 integrated analog PC/104 card. The base port
-- 
2.7.3

[PATCH v5 1/4] isa: Allow ISA-style drivers on modern systems

[William Breathitt Gray]

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patch introduces the
ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
options added as required.

Cc: Linus Torvalds 
Reviewed-by: Guenter Roeck 
Signed-off-by: William Breathitt Gray 
---
 arch/Kconfig  | 3 +++
 arch/x86/Kconfig  | 9 +
 drivers/base/Makefile | 2 +-
 include/linux/isa.h   | 2 +-
 4 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index b16e74e..9d9942f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -598,6 +598,9 @@ config HAVE_STACK_VALIDATION
  Architecture supports the 'objtool check' host tool command, which
  performs compile-time stack metadata validation.
 
+config ISA_BUS_API
+   def_bool ISA
+
 #
 # ABI hall of shame
 #
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0a7b885..d9a94da 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2439,6 +2439,15 @@ config PCI_CNB20LE_QUIRK
 
 source "drivers/pci/Kconfig"
 
+config ISA_BUS
+   bool "ISA-style bus support on modern systems" if EXPERT
+   select ISA_BUS_API
+   help
+ Enables ISA-style drivers on modern systems. This is necessary to
+ support PC/104 devices on X86_64 platforms.
+
+ If unsure, say N.
+
 # x86_64 have no ISA slots, but can have ISA-style DMA.
 config ISA_DMA_API
bool "ISA-style DMA support" if (X86_64 && EXPERT)
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6b2a84e..2609ba2 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_ISA)  += isa.o
+obj-$(CONFIG_ISA_BUS_API)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
 obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
diff --git a/include/linux/isa.h b/include/linux/isa.h
index 5ab8528..384ab9b 100644
--- a/include/linux/isa.h
+++ b/include/linux/isa.h
@@ -22,7 +22,7 @@ struct isa_driver {
 
 #define to_isa_driver(x) container_of((x), struct isa_driver, driver)
 
-#ifdef CONFIG_ISA
+#ifdef CONFIG_ISA_BUS_API
 int isa_register_driver(struct isa_driver *, unsigned int);
 void isa_unregister_driver(struct isa_driver *);
 #else
-- 
2.7.3

[PATCH v5 1/4] isa: Allow ISA-style drivers on modern systems

[William Breathitt Gray]

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patch introduces the
ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
options added as required.

Cc: Linus Torvalds 
Reviewed-by: Guenter Roeck 
Signed-off-by: William Breathitt Gray 
---
 arch/Kconfig  | 3 +++
 arch/x86/Kconfig  | 9 +
 drivers/base/Makefile | 2 +-
 include/linux/isa.h   | 2 +-
 4 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index b16e74e..9d9942f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -598,6 +598,9 @@ config HAVE_STACK_VALIDATION
  Architecture supports the 'objtool check' host tool command, which
  performs compile-time stack metadata validation.
 
+config ISA_BUS_API
+   def_bool ISA
+
 #
 # ABI hall of shame
 #
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0a7b885..d9a94da 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2439,6 +2439,15 @@ config PCI_CNB20LE_QUIRK
 
 source "drivers/pci/Kconfig"
 
+config ISA_BUS
+   bool "ISA-style bus support on modern systems" if EXPERT
+   select ISA_BUS_API
+   help
+ Enables ISA-style drivers on modern systems. This is necessary to
+ support PC/104 devices on X86_64 platforms.
+
+ If unsure, say N.
+
 # x86_64 have no ISA slots, but can have ISA-style DMA.
 config ISA_DMA_API
bool "ISA-style DMA support" if (X86_64 && EXPERT)
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index 6b2a84e..2609ba2 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -10,7 +10,7 @@ obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
 obj-$(CONFIG_HAS_DMA)  += dma-mapping.o
 obj-$(CONFIG_HAVE_GENERIC_DMA_COHERENT) += dma-coherent.o
-obj-$(CONFIG_ISA)  += isa.o
+obj-$(CONFIG_ISA_BUS_API)  += isa.o
 obj-$(CONFIG_FW_LOADER)+= firmware_class.o
 obj-$(CONFIG_NUMA) += node.o
 obj-$(CONFIG_MEMORY_HOTPLUG_SPARSE) += memory.o
diff --git a/include/linux/isa.h b/include/linux/isa.h
index 5ab8528..384ab9b 100644
--- a/include/linux/isa.h
+++ b/include/linux/isa.h
@@ -22,7 +22,7 @@ struct isa_driver {
 
 #define to_isa_driver(x) container_of((x), struct isa_driver, driver)
 
-#ifdef CONFIG_ISA
+#ifdef CONFIG_ISA_BUS_API
 int isa_register_driver(struct isa_driver *, unsigned int);
 void isa_unregister_driver(struct isa_driver *);
 #else
-- 
2.7.3

[PATCH v5 0/4] Allow ISA-style drivers on modern systems

[William Breathitt Gray]

Changes in v5:
  - Add explicit X86 dependency to CONFIG_STX104 and CONFIG_EBC_C384_WDT
since these drivers were developed with X86 architectures in mind

Changes in v4:
  - Remove unnecessary explicit "default n" from the X86 ISA_BUS Kconfig
option since Kconfig options are disabled by default

Changes in v3:
  - Remove redundant X86 dependency from the X86 ISA_BUS Kconfig option

Changes in v2:
  - Adjusted preprocessor compilation conditional in include/linux/isa.h
to use CONFIG_ISA_BUS_API in order to link the correct ISA bus
driver function definitions when available
  - Move ISA_BUS_API Kconfig option to arch/Kconfig, thus making it
available to all architectures instead of just X86
  - X86 ISA_BUS Kconfig option should be disabled by default; ISA
devices typically do not have a way to be probed, so users should
be required to explicitly enable ISA bus driver support, lest a
selected driver be loaded with the misguided expectation of a safe
hardware probe

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patchset introduces
the ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
option added as required.

An earlier attempt to allow the ISA bus driver to build for X86_64 took
an inappropriate approach resulting in legacy ISA drivers becoming
enabled unconditionally on untested and unsupported architectures.
Commit 51e68d055cba ("x86 isa: add back X86_32 dependency on
CONFIG_ISA"), added to restrict the ISA bus driver to only X86_32,
causes several drivers intended for X86_64 to be restricted to X86_32 as
well.

This patchset replaces the ISA Kconfig option dependency of several
drivers to ISA_BUS_API, so that they may build for X86_64 as intended.
The respective drivers are as follows:
* ACCES 104-IDIO-16 GPIO driver
* ACCES 104-IDI-48 GPIO driver
* ACCES 104-DIO-48E GPIO driver
* Apex Embedded Systems STX104 DAC driver
* WinSystems EBC-C384 watchdog timer driver
* WinSystems WS16C48 GPIO driver

William Breathitt Gray (4):
  isa: Allow ISA-style drivers on modern systems
  gpio: Allow PC/104 devices on X86_64
  iio: stx104: Allow build for X86_64
  watchdog: ebc-c384_wdt: Allow build for X86_64

 arch/Kconfig | 3 +++
 arch/x86/Kconfig | 9 +
 drivers/base/Makefile| 2 +-
 drivers/gpio/Kconfig | 8 
 drivers/iio/dac/Kconfig  | 2 +-
 drivers/watchdog/Kconfig | 2 +-
 include/linux/isa.h  | 2 +-
 7 files changed, 20 insertions(+), 8 deletions(-)

-- 
2.7.3

[PATCH v5 0/4] Allow ISA-style drivers on modern systems

[William Breathitt Gray]

Changes in v5:
  - Add explicit X86 dependency to CONFIG_STX104 and CONFIG_EBC_C384_WDT
since these drivers were developed with X86 architectures in mind

Changes in v4:
  - Remove unnecessary explicit "default n" from the X86 ISA_BUS Kconfig
option since Kconfig options are disabled by default

Changes in v3:
  - Remove redundant X86 dependency from the X86 ISA_BUS Kconfig option

Changes in v2:
  - Adjusted preprocessor compilation conditional in include/linux/isa.h
to use CONFIG_ISA_BUS_API in order to link the correct ISA bus
driver function definitions when available
  - Move ISA_BUS_API Kconfig option to arch/Kconfig, thus making it
available to all architectures instead of just X86
  - X86 ISA_BUS Kconfig option should be disabled by default; ISA
devices typically do not have a way to be probed, so users should
be required to explicitly enable ISA bus driver support, lest a
selected driver be loaded with the misguided expectation of a safe
hardware probe

Several modern devices, such as PC/104 cards, are expected to run on
modern systems via an ISA bus interface. Since ISA is a legacy interface
for most modern architectures, ISA support should remain disabled in
general. Support for ISA-style drivers should be enabled on a per driver
basis.

To allow ISA-style drivers on modern systems, this patchset introduces
the ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
build conditionally on the ISA_BUS_API Kconfig option, which defaults to
the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
ISA_BUS_API Kconfig option to be selected on architectures which do not
enable ISA (e.g. X86_64).

The ISA_BUS Kconfig option is currently only implemented for X86
architectures. Other architectures may have their own ISA_BUS Kconfig
option added as required.

An earlier attempt to allow the ISA bus driver to build for X86_64 took
an inappropriate approach resulting in legacy ISA drivers becoming
enabled unconditionally on untested and unsupported architectures.
Commit 51e68d055cba ("x86 isa: add back X86_32 dependency on
CONFIG_ISA"), added to restrict the ISA bus driver to only X86_32,
causes several drivers intended for X86_64 to be restricted to X86_32 as
well.

This patchset replaces the ISA Kconfig option dependency of several
drivers to ISA_BUS_API, so that they may build for X86_64 as intended.
The respective drivers are as follows:
* ACCES 104-IDIO-16 GPIO driver
* ACCES 104-IDI-48 GPIO driver
* ACCES 104-DIO-48E GPIO driver
* Apex Embedded Systems STX104 DAC driver
* WinSystems EBC-C384 watchdog timer driver
* WinSystems WS16C48 GPIO driver

William Breathitt Gray (4):
  isa: Allow ISA-style drivers on modern systems
  gpio: Allow PC/104 devices on X86_64
  iio: stx104: Allow build for X86_64
  watchdog: ebc-c384_wdt: Allow build for X86_64

 arch/Kconfig | 3 +++
 arch/x86/Kconfig | 9 +
 drivers/base/Makefile| 2 +-
 drivers/gpio/Kconfig | 8 
 drivers/iio/dac/Kconfig  | 2 +-
 drivers/watchdog/Kconfig | 2 +-
 include/linux/isa.h  | 2 +-
 7 files changed, 20 insertions(+), 8 deletions(-)

-- 
2.7.3

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

[Al Viro]

On Fri, May 27, 2016 at 11:23:25PM +0200, Arnd Bergmann wrote:

> @@ -837,7 +837,7 @@ static int load_flat_shared_library(int id, struct 
> lib_info *libs)
>  
>   res = prepare_binprm();
>  
> - if (!IS_ERR_VALUE(res))
> + if (res >= 0)

if (res == 0), please - prepare_binprm() returns 0 or -E...

> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -521,7 +521,7 @@ static int p9_check_errors(struct p9_client *c, struct 
> p9_req_t *req)
>   if (p9_is_proto_dotu(c))
>   err = -ecode;
>  
> - if (!err || !IS_ERR_VALUE(err)) {
> + if (!err || !IS_ERR_VALUE((unsigned long)err)) {

Not really - it's actually
if (p9_is_proto_dotu(c) && ecode < 512)
err = -ecode;

if (!err) {
...
> @@ -608,7 +608,7 @@ static int p9_check_zc_errors(struct p9_client *c, struct 
> p9_req_t *req,
>   if (p9_is_proto_dotu(c))
>   err = -ecode;
>  
> - if (!err || !IS_ERR_VALUE(err)) {
> + if (!err || !IS_ERR_VALUE((unsigned long)err)) {

Ditto.

Re: [PATCH] remove lots of IS_ERR_VALUE abuses

[Al Viro]

On Fri, May 27, 2016 at 11:23:25PM +0200, Arnd Bergmann wrote:

> @@ -837,7 +837,7 @@ static int load_flat_shared_library(int id, struct 
> lib_info *libs)
>  
>   res = prepare_binprm();
>  
> - if (!IS_ERR_VALUE(res))
> + if (res >= 0)

if (res == 0), please - prepare_binprm() returns 0 or -E...

> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -521,7 +521,7 @@ static int p9_check_errors(struct p9_client *c, struct 
> p9_req_t *req)
>   if (p9_is_proto_dotu(c))
>   err = -ecode;
>  
> - if (!err || !IS_ERR_VALUE(err)) {
> + if (!err || !IS_ERR_VALUE((unsigned long)err)) {

Not really - it's actually
if (p9_is_proto_dotu(c) && ecode < 512)
err = -ecode;

if (!err) {
...
> @@ -608,7 +608,7 @@ static int p9_check_zc_errors(struct p9_client *c, struct 
> p9_req_t *req,
>   if (p9_is_proto_dotu(c))
>   err = -ecode;
>  
> - if (!err || !IS_ERR_VALUE(err)) {
> + if (!err || !IS_ERR_VALUE((unsigned long)err)) {

Ditto.