Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 5:35 PM, Linus Torvalds
 wrote:
>
> Your mailer is crap, and destroys utf-8 characters. In particular:
>
> -M: Michał Mirosław 

Using pseudo-MIME-encoding, that was actually (before my cut-and-paste
mangled it even more):

Micha=c3=85=c2=82 Miros=c3=85=c2=82aw

> should be
>
> -M:  Michał Mirosław 

And the correct utf-8 is

Micha=C5=82 Miros=C5=82aw

and it *looks* like what happened is that something thought the input
was Latin1, and converted the Latin1 to UTF-8.

So the utf-8 character 'ł' (two bytes: =C5=82) was seen as two Latin1
character bytes: =c5 and =82.

And then each of those were converted mindlessly to utf-8, so the 'c5'
character became '=C3=85' and the '82' character became '=c2=82'.

So you have something that believes that a source file was latin1.

May I suggest just making absolutely *everything* on your system use a
utf-8 locale?

Because in this day and age, anything but utf-8 is just woefully
broken crud. "Just say no".

   Linus

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 5:35 PM, Linus Torvalds
 wrote:
>
> Your mailer is crap, and destroys utf-8 characters. In particular:
>
> -M: Michał Mirosław 

Using pseudo-MIME-encoding, that was actually (before my cut-and-paste
mangled it even more):

Micha=c3=85=c2=82 Miros=c3=85=c2=82aw

> should be
>
> -M:  Michał Mirosław 

And the correct utf-8 is

Micha=C5=82 Miros=C5=82aw

and it *looks* like what happened is that something thought the input
was Latin1, and converted the Latin1 to UTF-8.

So the utf-8 character 'ł' (two bytes: =C5=82) was seen as two Latin1
character bytes: =c5 and =82.

And then each of those were converted mindlessly to utf-8, so the 'c5'
character became '=C3=85' and the '82' character became '=c2=82'.

So you have something that believes that a source file was latin1.

May I suggest just making absolutely *everything* on your system use a
utf-8 locale?

Because in this day and age, anything but utf-8 is just woefully
broken crud. "Just say no".

   Linus

Re: [RFC PATCH v2 1/3] hwmon: pmbus: Add fan control support

[Andrew Jeffery]

On Thu, 2017-07-20 at 00:35 +0930, Joel Stanley wrote:
> > On Tue, Jul 18, 2017 at 1:06 PM, Andrew Jeffery  wrote:
> > Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.
> 
> Nice! I had a bit of a read. I'm not a pmbus expert, so most of the
> review is nitpicks about types, etc.
> 
> I'll defer to Guenter for the real stuff.

Thanks for taking a look.

A lot of the issues are a case of overzealous caution so I didn't trip
myself up during development. A lot of it can be cleaned up. I won't
respond to all of them.

> 
> > 
> > Fans in a PMBus device are driven by the configuration of two registers:
> > FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
> > and the tacho operate (if installed), while FAN_COMMAND_x sets the
> > desired fan rate. The unit of FAN_COMMAND_x is dependent on the
> > operational fan mode, RPM or PWM percent duty, as determined by the
> > corresponding FAN_CONFIG_x_y.
> > 
> > The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
> > FAN_COMMAND_x is implemented with the addition of virtual registers and
> > generic implementations in the core:
> > 
> > 1. PMBUS_VIRT_FAN_TARGET_x
> > 2. PMBUS_VIRT_PWM_x
> > 3. PMBUS_VIRT_PWM_ENABLE_x
> > 
> > The facilitate the necessary side-effects of each access. Examples of
> > the read case, assuming m = 1, b = 0, R = 0:
> > 
> >  Read |  With  || Gives
> >  ---
> >    Attribute  | FAN_CONFIG_x_y | FAN_COMMAND_y || Value
> >  --++---
> >   fanX_target | ~PB_FAN_z_RPM  | 0x0001|| 1
> >   pwm1| ~PB_FAN_z_RPM  | 0x0064|| 255
> >   pwmX_enable | ~PB_FAN_z_RPM  | 0x0001|| 1
> >   fanX_target |  PB_FAN_z_RPM  | 0x0001|| 1
> >   pwm1|  PB_FAN_z_RPM  | 0x0064|| 0
> >   pwmX_enable |  PB_FAN_z_RPM  | 0x0001|| 1
> > 
> > And the write case:
> > 
> >  Write| With  ||   Sets
> >  -+---+++---
> >    Attribute  | Value || FAN_CONFIG_x_y | FAN_COMMAND_x
> >  -+---+++---
> >   fanX_target | 1 ||  PB_FAN_z_RPM  | 0x0001
> >   pwmX| 255   || ~PB_FAN_z_RPM  | 0x0064
> >   pwmX_enable | 1 || ~PB_FAN_z_RPM  | 0x0064
> > 
> > Also, the DIRECT mode scaling of some controllers is different between
> > RPM and PWM percent duty control modes, so PSC_PWM is introduced to
> > capture the necessary coefficients.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> > 
> > v1 -> v2:
> > * Convert to using virtual registers
> > * Drop struct pmbus_fan_ctrl
> > * Introduce PSC_PWM
> > * Drop struct pmbus_coeffs
> > * Drop additional callbacks
> > 
> >  drivers/hwmon/pmbus/pmbus.h  |  19 
> >  drivers/hwmon/pmbus/pmbus_core.c | 215 
> > +++
> >  2 files changed, 217 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
> > index bfcb13bae34b..226a37bd525f 100644
> > --- a/drivers/hwmon/pmbus/pmbus.h
> > +++ b/drivers/hwmon/pmbus/pmbus.h
> > @@ -190,6 +190,20 @@ enum pmbus_regs {
> > PMBUS_VIRT_VMON_UV_FAULT_LIMIT,
> > PMBUS_VIRT_VMON_OV_FAULT_LIMIT,
> > PMBUS_VIRT_STATUS_VMON,
> > +
> > +   /* Fan control */
> > +   PMBUS_VIRT_FAN_TARGET_1,
> > +   PMBUS_VIRT_FAN_TARGET_2,
> > +   PMBUS_VIRT_FAN_TARGET_3,
> > +   PMBUS_VIRT_FAN_TARGET_4,
> > +   PMBUS_VIRT_PWM_1,
> > +   PMBUS_VIRT_PWM_2,
> > +   PMBUS_VIRT_PWM_3,
> > +   PMBUS_VIRT_PWM_4,
> > +   PMBUS_VIRT_PWM_ENABLE_1,
> > +   PMBUS_VIRT_PWM_ENABLE_2,
> > +   PMBUS_VIRT_PWM_ENABLE_3,
> > +   PMBUS_VIRT_PWM_ENABLE_4,
> >  };
> > 
> >  /*
> > @@ -223,6 +237,8 @@ enum pmbus_regs {
> >  #define PB_FAN_1_RPM   BIT(6)
> >  #define PB_FAN_1_INSTALLED BIT(7)
> > 
> > +enum pmbus_fan_mode { percent = 0, rpm };
> > +
> >  /*
> >   * STATUS_BYTE, STATUS_WORD (lower)
> >   */
> > @@ -313,6 +329,7 @@ enum pmbus_sensor_classes {
> > PSC_POWER,
> > PSC_TEMPERATURE,
> > PSC_FAN,
> > +   PSC_PWM,
> > PSC_NUM_CLASSES /* Number of power sensor classes */
> >  };
> > 
> > @@ -413,6 +430,8 @@ int pmbus_write_byte_data(struct i2c_client *client, 
> > int page, u8 reg,
> >   u8 value);
> >  int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
> >    u8 mask, u8 value);
> > +int pmbus_update_fan(struct i2c_client *client, int page, int id,
> > +int config, int mask, int command);
> >  void pmbus_clear_faults(struct i2c_client *client);
> >  bool pmbus_check_byte_register(struct 

Re: [RFC PATCH v2 1/3] hwmon: pmbus: Add fan control support

[Andrew Jeffery]

On Thu, 2017-07-20 at 00:35 +0930, Joel Stanley wrote:
> > On Tue, Jul 18, 2017 at 1:06 PM, Andrew Jeffery  wrote:
> > Expose fanX_target, pwmX and pwmX_enable hwmon sysfs attributes.
> 
> Nice! I had a bit of a read. I'm not a pmbus expert, so most of the
> review is nitpicks about types, etc.
> 
> I'll defer to Guenter for the real stuff.

Thanks for taking a look.

A lot of the issues are a case of overzealous caution so I didn't trip
myself up during development. A lot of it can be cleaned up. I won't
respond to all of them.

> 
> > 
> > Fans in a PMBus device are driven by the configuration of two registers:
> > FAN_CONFIG_x_y and FAN_COMMAND_x: FAN_CONFIG_x_y dictates how the fan
> > and the tacho operate (if installed), while FAN_COMMAND_x sets the
> > desired fan rate. The unit of FAN_COMMAND_x is dependent on the
> > operational fan mode, RPM or PWM percent duty, as determined by the
> > corresponding FAN_CONFIG_x_y.
> > 
> > The mapping of fanX_target, pwmX and pwmX_enable onto FAN_CONFIG_x_y and
> > FAN_COMMAND_x is implemented with the addition of virtual registers and
> > generic implementations in the core:
> > 
> > 1. PMBUS_VIRT_FAN_TARGET_x
> > 2. PMBUS_VIRT_PWM_x
> > 3. PMBUS_VIRT_PWM_ENABLE_x
> > 
> > The facilitate the necessary side-effects of each access. Examples of
> > the read case, assuming m = 1, b = 0, R = 0:
> > 
> >  Read |  With  || Gives
> >  ---
> >    Attribute  | FAN_CONFIG_x_y | FAN_COMMAND_y || Value
> >  --++---
> >   fanX_target | ~PB_FAN_z_RPM  | 0x0001|| 1
> >   pwm1| ~PB_FAN_z_RPM  | 0x0064|| 255
> >   pwmX_enable | ~PB_FAN_z_RPM  | 0x0001|| 1
> >   fanX_target |  PB_FAN_z_RPM  | 0x0001|| 1
> >   pwm1|  PB_FAN_z_RPM  | 0x0064|| 0
> >   pwmX_enable |  PB_FAN_z_RPM  | 0x0001|| 1
> > 
> > And the write case:
> > 
> >  Write| With  ||   Sets
> >  -+---+++---
> >    Attribute  | Value || FAN_CONFIG_x_y | FAN_COMMAND_x
> >  -+---+++---
> >   fanX_target | 1 ||  PB_FAN_z_RPM  | 0x0001
> >   pwmX| 255   || ~PB_FAN_z_RPM  | 0x0064
> >   pwmX_enable | 1 || ~PB_FAN_z_RPM  | 0x0064
> > 
> > Also, the DIRECT mode scaling of some controllers is different between
> > RPM and PWM percent duty control modes, so PSC_PWM is introduced to
> > capture the necessary coefficients.
> > 
> > > > Signed-off-by: Andrew Jeffery 
> > ---
> > 
> > v1 -> v2:
> > * Convert to using virtual registers
> > * Drop struct pmbus_fan_ctrl
> > * Introduce PSC_PWM
> > * Drop struct pmbus_coeffs
> > * Drop additional callbacks
> > 
> >  drivers/hwmon/pmbus/pmbus.h  |  19 
> >  drivers/hwmon/pmbus/pmbus_core.c | 215 
> > +++
> >  2 files changed, 217 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/hwmon/pmbus/pmbus.h b/drivers/hwmon/pmbus/pmbus.h
> > index bfcb13bae34b..226a37bd525f 100644
> > --- a/drivers/hwmon/pmbus/pmbus.h
> > +++ b/drivers/hwmon/pmbus/pmbus.h
> > @@ -190,6 +190,20 @@ enum pmbus_regs {
> > PMBUS_VIRT_VMON_UV_FAULT_LIMIT,
> > PMBUS_VIRT_VMON_OV_FAULT_LIMIT,
> > PMBUS_VIRT_STATUS_VMON,
> > +
> > +   /* Fan control */
> > +   PMBUS_VIRT_FAN_TARGET_1,
> > +   PMBUS_VIRT_FAN_TARGET_2,
> > +   PMBUS_VIRT_FAN_TARGET_3,
> > +   PMBUS_VIRT_FAN_TARGET_4,
> > +   PMBUS_VIRT_PWM_1,
> > +   PMBUS_VIRT_PWM_2,
> > +   PMBUS_VIRT_PWM_3,
> > +   PMBUS_VIRT_PWM_4,
> > +   PMBUS_VIRT_PWM_ENABLE_1,
> > +   PMBUS_VIRT_PWM_ENABLE_2,
> > +   PMBUS_VIRT_PWM_ENABLE_3,
> > +   PMBUS_VIRT_PWM_ENABLE_4,
> >  };
> > 
> >  /*
> > @@ -223,6 +237,8 @@ enum pmbus_regs {
> >  #define PB_FAN_1_RPM   BIT(6)
> >  #define PB_FAN_1_INSTALLED BIT(7)
> > 
> > +enum pmbus_fan_mode { percent = 0, rpm };
> > +
> >  /*
> >   * STATUS_BYTE, STATUS_WORD (lower)
> >   */
> > @@ -313,6 +329,7 @@ enum pmbus_sensor_classes {
> > PSC_POWER,
> > PSC_TEMPERATURE,
> > PSC_FAN,
> > +   PSC_PWM,
> > PSC_NUM_CLASSES /* Number of power sensor classes */
> >  };
> > 
> > @@ -413,6 +430,8 @@ int pmbus_write_byte_data(struct i2c_client *client, 
> > int page, u8 reg,
> >   u8 value);
> >  int pmbus_update_byte_data(struct i2c_client *client, int page, u8 reg,
> >    u8 mask, u8 value);
> > +int pmbus_update_fan(struct i2c_client *client, int page, int id,
> > +int config, int mask, int command);
> >  void pmbus_clear_faults(struct i2c_client *client);
> >  bool pmbus_check_byte_register(struct i2c_client *client, int page, int 
> > 

[PATCH] thermal: intel_pch_thermal: Read large temp values correctly

[Ed Swierk]

On all supported platforms, the TS Reading (TSR) field in the
Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78
degrees C) are plausible, so don't mask out the topmost bit. And the
register itself is 16 bits wide, so use readw() rather than readl().

Signed-off-by: Ed Swierk 
---
 drivers/thermal/intel_pch_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/intel_pch_thermal.c 
b/drivers/thermal/intel_pch_thermal.c
index 9889c90..318fc1b 100644
--- a/drivers/thermal/intel_pch_thermal.c
+++ b/drivers/thermal/intel_pch_thermal.c
@@ -49,7 +49,7 @@
 #define WPT_TSGPEN 0x84/* General Purpose Event Enables */
 
 /*  Wildcat Point-LP  PCH Thermal Register bit definitions */
-#define WPT_TEMP_TSR   0x00ff  /* Temp TS Reading */
+#define WPT_TEMP_TSR   0x01ff  /* Temp TS Reading */
 #define WPT_TSC_CPDE   0x01/* Catastrophic Power-Down Enable */
 #define WPT_TSS_TSDSS  0x10/* Thermal Sensor Dynamic Shutdown Status */
 #define WPT_TSS_GPES   0x08/* GPE status */
@@ -174,9 +174,9 @@ static int pch_wpt_init(struct pch_thermal_device *ptd, int 
*nr_trips)
 
 static int pch_wpt_get_temp(struct pch_thermal_device *ptd, int *temp)
 {
-   u8 wpt_temp;
+   u16 wpt_temp;
 
-   wpt_temp = WPT_TEMP_TSR & readl(ptd->hw_base + WPT_TEMP);
+   wpt_temp = WPT_TEMP_TSR & readw(ptd->hw_base + WPT_TEMP);
 
/* Resolution of 1/2 degree C and an offset of -50C */
*temp = (wpt_temp * 1000 / 2 - 5);
-- 
1.9.1

[PATCH] thermal: intel_pch_thermal: Read large temp values correctly

[Ed Swierk]

On all supported platforms, the TS Reading (TSR) field in the
Temperature (TEMP) register is 9 bits wide. Values above 0x100 (78
degrees C) are plausible, so don't mask out the topmost bit. And the
register itself is 16 bits wide, so use readw() rather than readl().

Signed-off-by: Ed Swierk 
---
 drivers/thermal/intel_pch_thermal.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/thermal/intel_pch_thermal.c 
b/drivers/thermal/intel_pch_thermal.c
index 9889c90..318fc1b 100644
--- a/drivers/thermal/intel_pch_thermal.c
+++ b/drivers/thermal/intel_pch_thermal.c
@@ -49,7 +49,7 @@
 #define WPT_TSGPEN 0x84/* General Purpose Event Enables */
 
 /*  Wildcat Point-LP  PCH Thermal Register bit definitions */
-#define WPT_TEMP_TSR   0x00ff  /* Temp TS Reading */
+#define WPT_TEMP_TSR   0x01ff  /* Temp TS Reading */
 #define WPT_TSC_CPDE   0x01/* Catastrophic Power-Down Enable */
 #define WPT_TSS_TSDSS  0x10/* Thermal Sensor Dynamic Shutdown Status */
 #define WPT_TSS_GPES   0x08/* GPE status */
@@ -174,9 +174,9 @@ static int pch_wpt_init(struct pch_thermal_device *ptd, int 
*nr_trips)
 
 static int pch_wpt_get_temp(struct pch_thermal_device *ptd, int *temp)
 {
-   u8 wpt_temp;
+   u16 wpt_temp;
 
-   wpt_temp = WPT_TEMP_TSR & readl(ptd->hw_base + WPT_TEMP);
+   wpt_temp = WPT_TEMP_TSR & readw(ptd->hw_base + WPT_TEMP);
 
/* Resolution of 1/2 degree C and an offset of -50C */
*temp = (wpt_temp * 1000 / 2 - 5);
-- 
1.9.1

[PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

The APM X-Gene PCIe root port does not support ACS at this point.
However, the hw provides isolation and source validation through
the SMMU. Turn on ACS but disable all the peer to peer features.

Signed-off-by: Feng Kan 
---
 drivers/pci/quirks.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..0f8f1cd 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 
acs_flags)
return acs_flags ? 0 : 1;
 }
 
+static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
+{
+   /*
+* XGene root matching this quirk do not allow peer-to-peer
+* transactions with others, allowing masking out these bits as if they
+* were unimplemented in the ACS capability.
+*/
+   acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
+  PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
+
+   return acs_flags ? 0 : 1;
+}
+
 /*
  * Many Intel PCH root ports do provide ACS-like features to disable peer
  * transactions and validate bus numbers in requests, but do not provide an
@@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, 
u16 acs_flags)
{ 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
/* Cavium ThunderX */
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
+   /* APM XGene */
+   { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
{ 0 }
 };
 
-- 
1.8.3.1

[PATCH V2] pci: quirk: Apply APM ACS quirk to XGene devices

[Feng Kan]

The APM X-Gene PCIe root port does not support ACS at this point.
However, the hw provides isolation and source validation through
the SMMU. Turn on ACS but disable all the peer to peer features.

Signed-off-by: Feng Kan 
---
 drivers/pci/quirks.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 085fb78..0f8f1cd 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev *dev, u16 
acs_flags)
return acs_flags ? 0 : 1;
 }
 
+static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
+{
+   /*
+* XGene root matching this quirk do not allow peer-to-peer
+* transactions with others, allowing masking out these bits as if they
+* were unimplemented in the ACS capability.
+*/
+   acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
+  PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
+
+   return acs_flags ? 0 : 1;
+}
+
 /*
  * Many Intel PCH root ports do provide ACS-like features to disable peer
  * transactions and validate bus numbers in requests, but do not provide an
@@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, 
u16 acs_flags)
{ 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
/* Cavium ThunderX */
{ PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
+   /* APM XGene */
+   { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
{ 0 }
 };
 
-- 
1.8.3.1

[PATCH] thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

[Ed Swierk]

Using the TSDSS flag to determine whether the thermal sensor is
enabled is problematic. Broadwell-DE (Xeon D-1500) does not support
dynamic shutdown and the TSDSS flag always reads 0 (contrary to the
current datasheet). Even on hardware supporting dynamic shutdown, the
driver does nothing to configure it, and the dynamic shutdown state
should not prevent the driver from loading. The ETS flag itself
indicates whether the thermal sensor is enabled, so use it instead of
the TSDSS flag on all hardware platforms.

Signed-off-by: Ed Swierk 
---
 drivers/thermal/intel_pch_thermal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/intel_pch_thermal.c 
b/drivers/thermal/intel_pch_thermal.c
index 2b49e8d..9889c90 100644
--- a/drivers/thermal/intel_pch_thermal.c
+++ b/drivers/thermal/intel_pch_thermal.c
@@ -125,7 +125,7 @@ static int pch_wpt_init(struct pch_thermal_device *ptd, int 
*nr_trips)
*nr_trips = 0;
 
/* Check if BIOS has already enabled thermal sensor */
-   if (WPT_TSS_TSDSS & readb(ptd->hw_base + WPT_TSS)) {
+   if (WPT_TSEL_ETS & readb(ptd->hw_base + WPT_TSEL)) {
ptd->bios_enabled = true;
goto read_trips;
}
@@ -141,7 +141,7 @@ static int pch_wpt_init(struct pch_thermal_device *ptd, int 
*nr_trips)
}
 
writeb(tsel|WPT_TSEL_ETS, ptd->hw_base + WPT_TSEL);
-   if (!(WPT_TSS_TSDSS & readb(ptd->hw_base + WPT_TSS))) {
+   if (!(WPT_TSEL_ETS & readb(ptd->hw_base + WPT_TSEL))) {
dev_err(>pdev->dev, "Sensor can't be enabled\n");
return -ENODEV;
}
-- 
1.9.1

[PATCH] thermal: intel_pch_thermal: Fix enable check on Broadwell-DE

[Ed Swierk]

Using the TSDSS flag to determine whether the thermal sensor is
enabled is problematic. Broadwell-DE (Xeon D-1500) does not support
dynamic shutdown and the TSDSS flag always reads 0 (contrary to the
current datasheet). Even on hardware supporting dynamic shutdown, the
driver does nothing to configure it, and the dynamic shutdown state
should not prevent the driver from loading. The ETS flag itself
indicates whether the thermal sensor is enabled, so use it instead of
the TSDSS flag on all hardware platforms.

Signed-off-by: Ed Swierk 
---
 drivers/thermal/intel_pch_thermal.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/thermal/intel_pch_thermal.c 
b/drivers/thermal/intel_pch_thermal.c
index 2b49e8d..9889c90 100644
--- a/drivers/thermal/intel_pch_thermal.c
+++ b/drivers/thermal/intel_pch_thermal.c
@@ -125,7 +125,7 @@ static int pch_wpt_init(struct pch_thermal_device *ptd, int 
*nr_trips)
*nr_trips = 0;
 
/* Check if BIOS has already enabled thermal sensor */
-   if (WPT_TSS_TSDSS & readb(ptd->hw_base + WPT_TSS)) {
+   if (WPT_TSEL_ETS & readb(ptd->hw_base + WPT_TSEL)) {
ptd->bios_enabled = true;
goto read_trips;
}
@@ -141,7 +141,7 @@ static int pch_wpt_init(struct pch_thermal_device *ptd, int 
*nr_trips)
}
 
writeb(tsel|WPT_TSEL_ETS, ptd->hw_base + WPT_TSEL);
-   if (!(WPT_TSS_TSDSS & readb(ptd->hw_base + WPT_TSS))) {
+   if (!(WPT_TSEL_ETS & readb(ptd->hw_base + WPT_TSEL))) {
dev_err(>pdev->dev, "Sensor can't be enabled\n");
return -ENODEV;
}
-- 
1.9.1

[PATCH v5] Bluetooth: btusb: Fix memory leak in play_deferred

[Jeffy Chen]

Currently we are calling usb_submit_urb directly to submit deferred tx
urbs after unanchor them.

So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb
and cause memory leak:
unreferenced object 0xffc0ce0fa400 (size 256):
...
  backtrace:
[] __save_stack_trace+0x48/0x6c
[] create_object+0x138/0x254
[] kmemleak_alloc+0x58/0x8c
[] __kmalloc+0x1d4/0x2a0
[] usb_alloc_urb+0x30/0x60
[] alloc_ctrl_urb+0x38/0x120 [btusb]
[] btusb_send_frame+0x64/0xf8 [btusb]

Put those urbs in tx_anchor to avoid the leak, and also fix the error
handling.

Signed-off-by: Jeffy Chen 
---

Changes in v5:
Fix compile warning reported by "kbuild test robot":
drivers/bluetooth/btusb.c:3288:3: warning: 'err' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
This 'err' would be set in the send loop, and would be used in the
cleanup rest urb code outside the loop.

Changes in v4:
Drop the rest deferred urbs when error happens.

Changes in v3:
Put the deferred urbs in tx_anchor.

Changes in v2:
Call usb_free_urb instead of reusing submit_tx_urb.

 drivers/bluetooth/btusb.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 0d533b2..91fdd60 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3263,16 +3263,33 @@ static int btusb_suspend(struct usb_interface *intf, 
pm_message_t message)
 static void play_deferred(struct btusb_data *data)
 {
struct urb *urb;
-   int err;
+   int err = 0;
 
while ((urb = usb_get_from_anchor(>deferred))) {
+   usb_anchor_urb(urb, >tx_anchor);
+
err = usb_submit_urb(urb, GFP_ATOMIC);
-   if (err < 0)
+   if (err < 0) {
+   if (err != -EPERM && err != -ENODEV)
+   BT_ERR("%s urb %p submission failed (%d)",
+  data->hdev->name, urb, -err);
+   kfree(urb->setup_packet);
+   usb_unanchor_urb(urb);
+   usb_free_urb(urb);
break;
+   }
 
data->tx_in_flight++;
+   usb_free_urb(urb);
+   }
+
+   /* Cleanup the rest deferred urbs. */
+   while ((urb = usb_get_from_anchor(>deferred))) {
+   BT_ERR("%s urb %p submission failed (%d)",
+  data->hdev->name, urb, -err);
+   kfree(urb->setup_packet);
+   usb_free_urb(urb);
}
-   usb_scuttle_anchored_urbs(>deferred);
 }
 
 static int btusb_resume(struct usb_interface *intf)
-- 
2.1.4

[PATCH v5] Bluetooth: btusb: Fix memory leak in play_deferred

[Jeffy Chen]

Currently we are calling usb_submit_urb directly to submit deferred tx
urbs after unanchor them.

So the usb_giveback_urb_bh would failed to unref it in usb_unanchor_urb
and cause memory leak:
unreferenced object 0xffc0ce0fa400 (size 256):
...
  backtrace:
[] __save_stack_trace+0x48/0x6c
[] create_object+0x138/0x254
[] kmemleak_alloc+0x58/0x8c
[] __kmalloc+0x1d4/0x2a0
[] usb_alloc_urb+0x30/0x60
[] alloc_ctrl_urb+0x38/0x120 [btusb]
[] btusb_send_frame+0x64/0xf8 [btusb]

Put those urbs in tx_anchor to avoid the leak, and also fix the error
handling.

Signed-off-by: Jeffy Chen 
---

Changes in v5:
Fix compile warning reported by "kbuild test robot":
drivers/bluetooth/btusb.c:3288:3: warning: 'err' may be used uninitialized in 
this function [-Wmaybe-uninitialized]
This 'err' would be set in the send loop, and would be used in the
cleanup rest urb code outside the loop.

Changes in v4:
Drop the rest deferred urbs when error happens.

Changes in v3:
Put the deferred urbs in tx_anchor.

Changes in v2:
Call usb_free_urb instead of reusing submit_tx_urb.

 drivers/bluetooth/btusb.c | 23 ---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 0d533b2..91fdd60 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3263,16 +3263,33 @@ static int btusb_suspend(struct usb_interface *intf, 
pm_message_t message)
 static void play_deferred(struct btusb_data *data)
 {
struct urb *urb;
-   int err;
+   int err = 0;
 
while ((urb = usb_get_from_anchor(>deferred))) {
+   usb_anchor_urb(urb, >tx_anchor);
+
err = usb_submit_urb(urb, GFP_ATOMIC);
-   if (err < 0)
+   if (err < 0) {
+   if (err != -EPERM && err != -ENODEV)
+   BT_ERR("%s urb %p submission failed (%d)",
+  data->hdev->name, urb, -err);
+   kfree(urb->setup_packet);
+   usb_unanchor_urb(urb);
+   usb_free_urb(urb);
break;
+   }
 
data->tx_in_flight++;
+   usb_free_urb(urb);
+   }
+
+   /* Cleanup the rest deferred urbs. */
+   while ((urb = usb_get_from_anchor(>deferred))) {
+   BT_ERR("%s urb %p submission failed (%d)",
+  data->hdev->name, urb, -err);
+   kfree(urb->setup_packet);
+   usb_free_urb(urb);
}
-   usb_scuttle_anchored_urbs(>deferred);
 }
 
 static int btusb_resume(struct usb_interface *intf)
-- 
2.1.4

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 5:26 PM, Linus Torvalds
 wrote:
> On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap  wrote:
>>
>> Must be small and stupid.  It applies cleanly for me.
>> Do you have changes that are not pushed out publicly?
>
> Nope, my private tree matches the public one.

Oh, I see it.

Your mailer is crap, and destroys utf-8 characters. In particular:

-M: Michał Mirosław 

should be

-M:  Michał Mirosław 

I'm not sure what part of your flow is broken, because your mailer
*claims* that it used

Content-Type: text/plain; charset=utf-8

but it very much did not. When you attached that file, it did some odd
character conversion crud.

There may be other examples of this, but that's the one I see and the
one that caused that to fail in that hunk.

  Linus

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 5:26 PM, Linus Torvalds
 wrote:
> On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap  wrote:
>>
>> Must be small and stupid.  It applies cleanly for me.
>> Do you have changes that are not pushed out publicly?
>
> Nope, my private tree matches the public one.

Oh, I see it.

Your mailer is crap, and destroys utf-8 characters. In particular:

-M: Michał Mirosław 

should be

-M:  Michał Mirosław 

I'm not sure what part of your flow is broken, because your mailer
*claims* that it used

Content-Type: text/plain; charset=utf-8

but it very much did not. When you attached that file, it did some odd
character conversion crud.

There may be other examples of this, but that's the one I see and the
one that caused that to fail in that hunk.

  Linus

Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t

[Kees Cook]

On Wed, Jul 19, 2017 at 4:20 PM, Kees Cook  wrote:
> On Wed, Jul 19, 2017 at 4:11 PM, Davidlohr Bueso  wrote:
>> May I suggest using mmtests with the following config file:
>>
>> https://github.com/gormanm/mmtests/blob/7e070a810bc0af92e592e5121d0ea75fada51aeb/configs/config-global-dhp__workload-ipc-scale-short
>>
>> It will run two of Manfred's ipcscale sem benchmarks.
>
> I'll see if I can figure out how to use this for testing the fast
> refcount protection:
> https://lkml.org/lkml/2017/7/18/1223
>
> Then we could see:
>
> before conversion
> after conversion
> with CONFIG_REFCOUNT_FULL
> with fast refcount protection

I have no idea how to read this report. It seems to be mostly noise
(multiple baseline runs seem to show greater variability than compared
against the other possible results).

Test runs were atomic_t, atomic_t-2, refcount_t, refcount-full, and
refcount-fast. (Two baselines, refcount_t conversion, with FULL, and
with the fast implementation.) Output here:
http://pastebin.ubuntu.com/25129382/

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH 1/3] ipc: convert ipc_namespace.count from atomic_t to refcount_t

[Kees Cook]

On Wed, Jul 19, 2017 at 4:20 PM, Kees Cook  wrote:
> On Wed, Jul 19, 2017 at 4:11 PM, Davidlohr Bueso  wrote:
>> May I suggest using mmtests with the following config file:
>>
>> https://github.com/gormanm/mmtests/blob/7e070a810bc0af92e592e5121d0ea75fada51aeb/configs/config-global-dhp__workload-ipc-scale-short
>>
>> It will run two of Manfred's ipcscale sem benchmarks.
>
> I'll see if I can figure out how to use this for testing the fast
> refcount protection:
> https://lkml.org/lkml/2017/7/18/1223
>
> Then we could see:
>
> before conversion
> after conversion
> with CONFIG_REFCOUNT_FULL
> with fast refcount protection

I have no idea how to read this report. It seems to be mostly noise
(multiple baseline runs seem to show greater variability than compared
against the other possible results).

Test runs were atomic_t, atomic_t-2, refcount_t, refcount-full, and
refcount-fast. (Two baselines, refcount_t conversion, with FULL, and
with the fast implementation.) Output here:
http://pastebin.ubuntu.com/25129382/

-Kees

-- 
Kees Cook
Pixel Security

[PATCH v2 1/7] driver core: emit uevents when device is bound to a driver

[Dmitry Torokhov]

There are certain touch controllers that may come up in either normal
(application) or boot mode, depending on whether firmware/configuration is
corrupted when they are powered on. In boot mode the kernel does not create
input device instance (because it does not necessarily know the
characteristics of the input device in question).

Another number of controllers does not store firmware in a non-volatile
memory, and they similarly need to have firmware loaded before input device
instance is created. There are also other types of devices with similar
behavior.

There is a desire to be able to trigger firmware loading via udev, but it
has to happen only when driver is bound to a physical device (i2c or spi).
These udev actions can not use ADD events, as those happen too early, so we
are introducing BIND and UNBIND events that are emitted at the right
moment.

Also, many drivers create additional driver-specific device attributes
when binding to the device, to provide userspace with additional controls.
The new events allow userspace to adjust these driver-specific attributes
without worrying that they are not there yet.

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/dd.c   | 4 
 include/linux/kobject.h | 2 ++
 lib/kobject_uevent.c| 2 ++
 3 files changed, 8 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4882f06d12df..c17fefc77345 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -259,6 +259,8 @@ static void driver_bound(struct device *dev)
if (dev->bus)
blocking_notifier_call_chain(>bus->p->bus_notifier,
 BUS_NOTIFY_BOUND_DRIVER, dev);
+
+   kobject_uevent(>kobj, KOBJ_BIND);
 }
 
 static int driver_sysfs_add(struct device *dev)
@@ -848,6 +850,8 @@ static void __device_release_driver(struct device *dev, 
struct device *parent)
blocking_notifier_call_chain(>bus->p->bus_notifier,
 BUS_NOTIFY_UNBOUND_DRIVER,
 dev);
+
+   kobject_uevent(>kobj, KOBJ_UNBIND);
}
 }
 
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index ca85cb80e99a..12f5ddccb97c 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -57,6 +57,8 @@ enum kobject_action {
KOBJ_MOVE,
KOBJ_ONLINE,
KOBJ_OFFLINE,
+   KOBJ_BIND,
+   KOBJ_UNBIND,
KOBJ_MAX
 };
 
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index 9a2b811966eb..4682e8545b5c 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -50,6 +50,8 @@ static const char *kobject_actions[] = {
[KOBJ_MOVE] =   "move",
[KOBJ_ONLINE] = "online",
[KOBJ_OFFLINE] ="offline",
+   [KOBJ_BIND] =   "bind",
+   [KOBJ_UNBIND] = "unbind",
 };
 
 /**
-- 
2.14.0.rc0.284.gd933b75aa4-goog

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap  wrote:
>
> Must be small and stupid.  It applies cleanly for me.
> Do you have changes that are not pushed out publicly?

Nope, my private tree matches the public one.

The failure happens at the chunk for line 5086, fwiw.

You don't seem to have used git to generate the patch, so it doesn't
show the git blob ID's (which is a really nice way to show exactly
which version of a file the diff was generated against).

My current MAINTAINER file has git object ID
02994f42aacb07e79b9facf9881e3f0983929c0b

Linus

[PATCH v2 1/7] driver core: emit uevents when device is bound to a driver

[Dmitry Torokhov]

There are certain touch controllers that may come up in either normal
(application) or boot mode, depending on whether firmware/configuration is
corrupted when they are powered on. In boot mode the kernel does not create
input device instance (because it does not necessarily know the
characteristics of the input device in question).

Another number of controllers does not store firmware in a non-volatile
memory, and they similarly need to have firmware loaded before input device
instance is created. There are also other types of devices with similar
behavior.

There is a desire to be able to trigger firmware loading via udev, but it
has to happen only when driver is bound to a physical device (i2c or spi).
These udev actions can not use ADD events, as those happen too early, so we
are introducing BIND and UNBIND events that are emitted at the right
moment.

Also, many drivers create additional driver-specific device attributes
when binding to the device, to provide userspace with additional controls.
The new events allow userspace to adjust these driver-specific attributes
without worrying that they are not there yet.

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/dd.c   | 4 
 include/linux/kobject.h | 2 ++
 lib/kobject_uevent.c| 2 ++
 3 files changed, 8 insertions(+)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 4882f06d12df..c17fefc77345 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -259,6 +259,8 @@ static void driver_bound(struct device *dev)
if (dev->bus)
blocking_notifier_call_chain(>bus->p->bus_notifier,
 BUS_NOTIFY_BOUND_DRIVER, dev);
+
+   kobject_uevent(>kobj, KOBJ_BIND);
 }
 
 static int driver_sysfs_add(struct device *dev)
@@ -848,6 +850,8 @@ static void __device_release_driver(struct device *dev, 
struct device *parent)
blocking_notifier_call_chain(>bus->p->bus_notifier,
 BUS_NOTIFY_UNBOUND_DRIVER,
 dev);
+
+   kobject_uevent(>kobj, KOBJ_UNBIND);
}
 }
 
diff --git a/include/linux/kobject.h b/include/linux/kobject.h
index ca85cb80e99a..12f5ddccb97c 100644
--- a/include/linux/kobject.h
+++ b/include/linux/kobject.h
@@ -57,6 +57,8 @@ enum kobject_action {
KOBJ_MOVE,
KOBJ_ONLINE,
KOBJ_OFFLINE,
+   KOBJ_BIND,
+   KOBJ_UNBIND,
KOBJ_MAX
 };
 
diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c
index 9a2b811966eb..4682e8545b5c 100644
--- a/lib/kobject_uevent.c
+++ b/lib/kobject_uevent.c
@@ -50,6 +50,8 @@ static const char *kobject_actions[] = {
[KOBJ_MOVE] =   "move",
[KOBJ_ONLINE] = "online",
[KOBJ_OFFLINE] ="offline",
+   [KOBJ_BIND] =   "bind",
+   [KOBJ_UNBIND] = "unbind",
 };
 
 /**
-- 
2.14.0.rc0.284.gd933b75aa4-goog

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 5:19 PM, Randy Dunlap  wrote:
>
> Must be small and stupid.  It applies cleanly for me.
> Do you have changes that are not pushed out publicly?

Nope, my private tree matches the public one.

The failure happens at the chunk for line 5086, fwiw.

You don't seem to have used git to generate the patch, so it doesn't
show the git blob ID's (which is a really nice way to show exactly
which version of a file the diff was generated against).

My current MAINTAINER file has git object ID
02994f42aacb07e79b9facf9881e3f0983929c0b

Linus

[PATCH v2 3/7] driver core: add device_{add|remove}_group() helpers

[Dmitry Torokhov]

We have helpers that work with NULL terminated array of groups, but many
drivers only create a single supplemental group, and do not want to declare
a group array. Let's provide them with helpers working with a single group.

Signed-off-by: Dmitry Torokhov 
---
 include/linux/device.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index 10cf209a4e82..7698a513b35e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1205,6 +1205,22 @@ extern int __must_check device_add_groups(struct device 
*dev,
 extern void device_remove_groups(struct device *dev,
 const struct attribute_group **groups);
 
+static inline int __must_check device_add_group(struct device *dev,
+   const struct attribute_group *grp)
+{
+   const struct attribute_group *groups[] = { grp, NULL };
+
+   return device_add_groups(dev, groups);
+}
+
+static inline void device_remove_group(struct device *dev,
+  const struct attribute_group *grp)
+{
+   const struct attribute_group *groups[] = { grp, NULL };
+
+   return device_remove_groups(dev, groups);
+}
+
 /*
  * Platform "fixup" functions - allow the platform to have their say
  * about devices and actions that the general device layer doesn't
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 3/7] driver core: add device_{add|remove}_group() helpers

[Dmitry Torokhov]

We have helpers that work with NULL terminated array of groups, but many
drivers only create a single supplemental group, and do not want to declare
a group array. Let's provide them with helpers working with a single group.

Signed-off-by: Dmitry Torokhov 
---
 include/linux/device.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/linux/device.h b/include/linux/device.h
index 10cf209a4e82..7698a513b35e 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1205,6 +1205,22 @@ extern int __must_check device_add_groups(struct device 
*dev,
 extern void device_remove_groups(struct device *dev,
 const struct attribute_group **groups);
 
+static inline int __must_check device_add_group(struct device *dev,
+   const struct attribute_group *grp)
+{
+   const struct attribute_group *groups[] = { grp, NULL };
+
+   return device_add_groups(dev, groups);
+}
+
+static inline void device_remove_group(struct device *dev,
+  const struct attribute_group *grp)
+{
+   const struct attribute_group *groups[] = { grp, NULL };
+
+   return device_remove_groups(dev, groups);
+}
+
 /*
  * Platform "fixup" functions - allow the platform to have their say
  * about devices and actions that the general device layer doesn't
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 6/7] Input: synaptics_rmi4 - use devm_device_add_group() for attributes in F01

[Dmitry Torokhov]

Now that we have proper managed API to create device attributes, let's
start using it instead of the manual unwinding.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/rmi4/rmi_f01.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index aa1aabfdbe7c..ae966e333a2f 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -570,18 +570,14 @@ static int rmi_f01_probe(struct rmi_function *fn)
 
dev_set_drvdata(>dev, f01);
 
-   error = sysfs_create_group(>rmi_dev->dev.kobj, _f01_attr_group);
+   error = devm_device_add_group(>rmi_dev->dev, _f01_attr_group);
if (error)
-   dev_warn(>dev, "Failed to create sysfs group: %d\n", error);
+   dev_warn(>dev,
+"Failed to create attribute group: %d\n", error);
 
return 0;
 }
 
-static void rmi_f01_remove(struct rmi_function *fn)
-{
-   sysfs_remove_group(>rmi_dev->dev.kobj, _f01_attr_group);
-}
-
 static int rmi_f01_config(struct rmi_function *fn)
 {
struct f01_data *f01 = dev_get_drvdata(>dev);
@@ -721,7 +717,6 @@ struct rmi_function_handler rmi_f01_handler = {
},
.func   = 0x01,
.probe  = rmi_f01_probe,
-   .remove = rmi_f01_remove,
.config = rmi_f01_config,
.attention  = rmi_f01_attention,
.suspend= rmi_f01_suspend,
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 0/7] New bind/unbingd uevents

[Dmitry Torokhov]

Hi Greg,

Here is the v2 of bind/unbind uevent patch series.  The new bind/unbind
will allow triggering firmware update through udev, and the new device
sysfs API will cut down on some boilerplate code in drivers.

As you requested, I moved the new functions to device.h, in the process I
exported existing device_add_groups() and device_remove_groups() and called
the new functions devm_device_{add|remove}_group[s]() to get away from the
sysfs "rawness".

Below is also a patch to systemd to stop dropping the new attributes
(why they think they need to inspect and discard the data they do not
understand is beyond me).

Thanks,
Dmitry

V2:
- made device_{add|remove}_groups() public
- added device_{add|remove}_group() helpers
- the new devm APIs are moved into device.h and "sysfs" suffix dropped
- added 3 patches showing use in the drivers

V1: initial [re]post

Dmitry Torokhov (7):
  driver core: emit uevents when device is bound to a driver
  driver core: make device_{add|remove}_groups() public
  driver core: add device_{add|remove}_group() helpers
  driver core: add devm_device_add_group() and friends
  Input: gpio_keys - use devm_device_add_group() for attributes
  Input: synaptics_rmi4 - use devm_device_add_group() for attributes in F01
  Input: axp20x-pek - switch to using devm_device_add_group()

 drivers/base/base.h|   5 --
 drivers/base/core.c| 132 +
 drivers/base/dd.c  |   4 ++
 drivers/input/keyboard/gpio_keys.c |  16 +
 drivers/input/misc/axp20x-pek.c|  18 +
 drivers/input/rmi4/rmi_f01.c   |  11 +---
 include/linux/device.h |  30 +
 include/linux/kobject.h|   2 +
 lib/kobject_uevent.c   |   2 +
 9 files changed, 176 insertions(+), 44 deletions(-)

-- >8 --

>From 6d10e621578dffcca0ad785e4a73196aa25350f6 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov 
Date: Mon, 17 Jul 2017 20:10:17 -0700
Subject: [PATCH] Add handling for bind/unbind actions

Newer kernels will emit uevents with "bind" and "unbind" actions. These
uevents will be issued when driver is bound to or unbound from a device.
"Bind" events are helpful when device requires a firmware to operate
properly, and driver is unable to create a child device before firmware
is properly loaded.

For some reason systemd validates actions and drops the ones it does not
know, instead of passing them on through as old udev did, so we need to
explicitly teach it about them.
---
 src/libsystemd/sd-device/device-internal.h | 2 ++
 src/libsystemd/sd-device/device-private.c  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/src/libsystemd/sd-device/device-internal.h 
b/src/libsystemd/sd-device/device-internal.h
index f4783deef..0505a2730 100644
--- a/src/libsystemd/sd-device/device-internal.h
+++ b/src/libsystemd/sd-device/device-internal.h
@@ -104,6 +104,8 @@ typedef enum DeviceAction {
 DEVICE_ACTION_MOVE,
 DEVICE_ACTION_ONLINE,
 DEVICE_ACTION_OFFLINE,
+DEVICE_ACTION_BIND,
+DEVICE_ACTION_UNBIND,
 _DEVICE_ACTION_MAX,
 _DEVICE_ACTION_INVALID = -1,
 } DeviceAction;
diff --git a/src/libsystemd/sd-device/device-private.c 
b/src/libsystemd/sd-device/device-private.c
index b4cd676c1..8839c3266 100644
--- a/src/libsystemd/sd-device/device-private.c
+++ b/src/libsystemd/sd-device/device-private.c
@@ -466,6 +466,8 @@ static const char* const 
device_action_table[_DEVICE_ACTION_MAX] = {
 [DEVICE_ACTION_MOVE] = "move",
 [DEVICE_ACTION_ONLINE] = "online",
 [DEVICE_ACTION_OFFLINE] = "offline",
+[DEVICE_ACTION_BIND] = "bind",
+[DEVICE_ACTION_UNBIND] = "unbind",
 };
 
 DEFINE_STRING_TABLE_LOOKUP(device_action, DeviceAction);

[PATCH v2 6/7] Input: synaptics_rmi4 - use devm_device_add_group() for attributes in F01

[Dmitry Torokhov]

Now that we have proper managed API to create device attributes, let's
start using it instead of the manual unwinding.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/rmi4/rmi_f01.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index aa1aabfdbe7c..ae966e333a2f 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -570,18 +570,14 @@ static int rmi_f01_probe(struct rmi_function *fn)
 
dev_set_drvdata(>dev, f01);
 
-   error = sysfs_create_group(>rmi_dev->dev.kobj, _f01_attr_group);
+   error = devm_device_add_group(>rmi_dev->dev, _f01_attr_group);
if (error)
-   dev_warn(>dev, "Failed to create sysfs group: %d\n", error);
+   dev_warn(>dev,
+"Failed to create attribute group: %d\n", error);
 
return 0;
 }
 
-static void rmi_f01_remove(struct rmi_function *fn)
-{
-   sysfs_remove_group(>rmi_dev->dev.kobj, _f01_attr_group);
-}
-
 static int rmi_f01_config(struct rmi_function *fn)
 {
struct f01_data *f01 = dev_get_drvdata(>dev);
@@ -721,7 +717,6 @@ struct rmi_function_handler rmi_f01_handler = {
},
.func   = 0x01,
.probe  = rmi_f01_probe,
-   .remove = rmi_f01_remove,
.config = rmi_f01_config,
.attention  = rmi_f01_attention,
.suspend= rmi_f01_suspend,
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 0/7] New bind/unbingd uevents

[Dmitry Torokhov]

Hi Greg,

Here is the v2 of bind/unbind uevent patch series.  The new bind/unbind
will allow triggering firmware update through udev, and the new device
sysfs API will cut down on some boilerplate code in drivers.

As you requested, I moved the new functions to device.h, in the process I
exported existing device_add_groups() and device_remove_groups() and called
the new functions devm_device_{add|remove}_group[s]() to get away from the
sysfs "rawness".

Below is also a patch to systemd to stop dropping the new attributes
(why they think they need to inspect and discard the data they do not
understand is beyond me).

Thanks,
Dmitry

V2:
- made device_{add|remove}_groups() public
- added device_{add|remove}_group() helpers
- the new devm APIs are moved into device.h and "sysfs" suffix dropped
- added 3 patches showing use in the drivers

V1: initial [re]post

Dmitry Torokhov (7):
  driver core: emit uevents when device is bound to a driver
  driver core: make device_{add|remove}_groups() public
  driver core: add device_{add|remove}_group() helpers
  driver core: add devm_device_add_group() and friends
  Input: gpio_keys - use devm_device_add_group() for attributes
  Input: synaptics_rmi4 - use devm_device_add_group() for attributes in F01
  Input: axp20x-pek - switch to using devm_device_add_group()

 drivers/base/base.h|   5 --
 drivers/base/core.c| 132 +
 drivers/base/dd.c  |   4 ++
 drivers/input/keyboard/gpio_keys.c |  16 +
 drivers/input/misc/axp20x-pek.c|  18 +
 drivers/input/rmi4/rmi_f01.c   |  11 +---
 include/linux/device.h |  30 +
 include/linux/kobject.h|   2 +
 lib/kobject_uevent.c   |   2 +
 9 files changed, 176 insertions(+), 44 deletions(-)

-- >8 --

>From 6d10e621578dffcca0ad785e4a73196aa25350f6 Mon Sep 17 00:00:00 2001
From: Dmitry Torokhov 
Date: Mon, 17 Jul 2017 20:10:17 -0700
Subject: [PATCH] Add handling for bind/unbind actions

Newer kernels will emit uevents with "bind" and "unbind" actions. These
uevents will be issued when driver is bound to or unbound from a device.
"Bind" events are helpful when device requires a firmware to operate
properly, and driver is unable to create a child device before firmware
is properly loaded.

For some reason systemd validates actions and drops the ones it does not
know, instead of passing them on through as old udev did, so we need to
explicitly teach it about them.
---
 src/libsystemd/sd-device/device-internal.h | 2 ++
 src/libsystemd/sd-device/device-private.c  | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/src/libsystemd/sd-device/device-internal.h 
b/src/libsystemd/sd-device/device-internal.h
index f4783deef..0505a2730 100644
--- a/src/libsystemd/sd-device/device-internal.h
+++ b/src/libsystemd/sd-device/device-internal.h
@@ -104,6 +104,8 @@ typedef enum DeviceAction {
 DEVICE_ACTION_MOVE,
 DEVICE_ACTION_ONLINE,
 DEVICE_ACTION_OFFLINE,
+DEVICE_ACTION_BIND,
+DEVICE_ACTION_UNBIND,
 _DEVICE_ACTION_MAX,
 _DEVICE_ACTION_INVALID = -1,
 } DeviceAction;
diff --git a/src/libsystemd/sd-device/device-private.c 
b/src/libsystemd/sd-device/device-private.c
index b4cd676c1..8839c3266 100644
--- a/src/libsystemd/sd-device/device-private.c
+++ b/src/libsystemd/sd-device/device-private.c
@@ -466,6 +466,8 @@ static const char* const 
device_action_table[_DEVICE_ACTION_MAX] = {
 [DEVICE_ACTION_MOVE] = "move",
 [DEVICE_ACTION_ONLINE] = "online",
 [DEVICE_ACTION_OFFLINE] = "offline",
+[DEVICE_ACTION_BIND] = "bind",
+[DEVICE_ACTION_UNBIND] = "unbind",
 };
 
 DEFINE_STRING_TABLE_LOOKUP(device_action, DeviceAction);

[PATCH v2 2/7] driver core: make device_{add|remove}_groups() public

[Dmitry Torokhov]

Many drivers create additional driver-specific device attributes when
binding to the device. To avoid them calling SYSFS API directly, let's
export these helpers.

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/base.h| 5 -
 drivers/base/core.c| 2 ++
 include/linux/device.h | 5 +
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index e19b1008e5fb..539432a14b5c 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -126,11 +126,6 @@ extern int driver_add_groups(struct device_driver *drv,
 extern void driver_remove_groups(struct device_driver *drv,
 const struct attribute_group **groups);
 
-extern int device_add_groups(struct device *dev,
-const struct attribute_group **groups);
-extern void device_remove_groups(struct device *dev,
-const struct attribute_group **groups);
-
 extern char *make_class_name(const char *name, struct kobject *kobj);
 
 extern int devres_release_all(struct device *dev);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbecaf9293be..14f8cf5c8b05 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1026,12 +1026,14 @@ int device_add_groups(struct device *dev, const struct 
attribute_group **groups)
 {
return sysfs_create_groups(>kobj, groups);
 }
+EXPORT_SYMBOL_GPL(device_add_groups);
 
 void device_remove_groups(struct device *dev,
  const struct attribute_group **groups)
 {
sysfs_remove_groups(>kobj, groups);
 }
+EXPORT_SYMBOL_GPL(device_remove_groups);
 
 static int device_add_attrs(struct device *dev)
 {
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..10cf209a4e82 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1200,6 +1200,11 @@ struct device *device_create_with_groups(struct class 
*cls,
 const char *fmt, ...);
 extern void device_destroy(struct class *cls, dev_t devt);
 
+extern int __must_check device_add_groups(struct device *dev,
+   const struct attribute_group **groups);
+extern void device_remove_groups(struct device *dev,
+const struct attribute_group **groups);
+
 /*
  * Platform "fixup" functions - allow the platform to have their say
  * about devices and actions that the general device layer doesn't
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 2/7] driver core: make device_{add|remove}_groups() public

[Dmitry Torokhov]

Many drivers create additional driver-specific device attributes when
binding to the device. To avoid them calling SYSFS API directly, let's
export these helpers.

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/base.h| 5 -
 drivers/base/core.c| 2 ++
 include/linux/device.h | 5 +
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index e19b1008e5fb..539432a14b5c 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -126,11 +126,6 @@ extern int driver_add_groups(struct device_driver *drv,
 extern void driver_remove_groups(struct device_driver *drv,
 const struct attribute_group **groups);
 
-extern int device_add_groups(struct device *dev,
-const struct attribute_group **groups);
-extern void device_remove_groups(struct device *dev,
-const struct attribute_group **groups);
-
 extern char *make_class_name(const char *name, struct kobject *kobj);
 
 extern int devres_release_all(struct device *dev);
diff --git a/drivers/base/core.c b/drivers/base/core.c
index bbecaf9293be..14f8cf5c8b05 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1026,12 +1026,14 @@ int device_add_groups(struct device *dev, const struct 
attribute_group **groups)
 {
return sysfs_create_groups(>kobj, groups);
 }
+EXPORT_SYMBOL_GPL(device_add_groups);
 
 void device_remove_groups(struct device *dev,
  const struct attribute_group **groups)
 {
sysfs_remove_groups(>kobj, groups);
 }
+EXPORT_SYMBOL_GPL(device_remove_groups);
 
 static int device_add_attrs(struct device *dev)
 {
diff --git a/include/linux/device.h b/include/linux/device.h
index 9ef518af5515..10cf209a4e82 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1200,6 +1200,11 @@ struct device *device_create_with_groups(struct class 
*cls,
 const char *fmt, ...);
 extern void device_destroy(struct class *cls, dev_t devt);
 
+extern int __must_check device_add_groups(struct device *dev,
+   const struct attribute_group **groups);
+extern void device_remove_groups(struct device *dev,
+const struct attribute_group **groups);
+
 /*
  * Platform "fixup" functions - allow the platform to have their say
  * about devices and actions that the general device layer doesn't
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 7/7] Input: axp20x-pek - switch to using devm_device_add_group()

[Dmitry Torokhov]

Now that we have proper managed API to create device attributes, let's
use it instead of installing a custom devm action.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/misc/axp20x-pek.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index 38c79ebff033..cfeb0e943de6 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -182,13 +182,6 @@ static irqreturn_t axp20x_pek_irq(int irq, void *pwr)
return IRQ_HANDLED;
 }
 
-static void axp20x_remove_sysfs_group(void *_data)
-{
-   struct device *dev = _data;
-
-   sysfs_remove_group(>kobj, _attribute_group);
-}
-
 static int axp20x_pek_probe_input_device(struct axp20x_pek *axp20x_pek,
 struct platform_device *pdev)
 {
@@ -313,22 +306,13 @@ static int axp20x_pek_probe(struct platform_device *pdev)
return error;
}
 
-   error = sysfs_create_group(>dev.kobj, _attribute_group);
+   error = devm_device_add_group(>dev, _attribute_group);
if (error) {
dev_err(>dev, "Failed to create sysfs attributes: %d\n",
error);
return error;
}
 
-   error = devm_add_action(>dev,
-   axp20x_remove_sysfs_group, >dev);
-   if (error) {
-   axp20x_remove_sysfs_group(>dev);
-   dev_err(>dev, "Failed to add sysfs cleanup action: %d\n",
-   error);
-   return error;
-   }
-
platform_set_drvdata(pdev, axp20x_pek);
 
return 0;
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 4/7] driver core: add devm_device_add_group() and friends

[Dmitry Torokhov]

Many drivers create additional driver-specific device attributes when
binding to the device, and providing managed version of
device_create_group() will simplify unbinding and error handling in probe
path for such drivers.

Without managed version driver writers either have to mix manual and
managed resources, which is prone to errors, or open-code this function by
providing a wrapper to device_add_group() and use it with devm_add_action()
or devm_add_action_or_reset().

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/core.c| 130 +
 include/linux/device.h |   9 
 2 files changed, 139 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 14f8cf5c8b05..09723532725d 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1035,6 +1035,136 @@ void device_remove_groups(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(device_remove_groups);
 
+union device_attr_group_devres {
+   const struct attribute_group *group;
+   const struct attribute_group **groups;
+};
+
+static int devm_attr_group_match(struct device *dev, void *res, void *data)
+{
+   return ((union device_attr_group_devres *)res)->group == data;
+}
+
+static void devm_attr_group_remove(struct device *dev, void *res)
+{
+   union device_attr_group_devres *devres = res;
+   const struct attribute_group *group = devres->group;
+
+   dev_dbg(dev, "%s: removing group %p\n", __func__, group);
+   sysfs_remove_group(>kobj, group);
+}
+
+static void devm_attr_groups_remove(struct device *dev, void *res)
+{
+   union device_attr_group_devres *devres = res;
+   const struct attribute_group **groups = devres->groups;
+
+   dev_dbg(dev, "%s: removing groups %p\n", __func__, groups);
+   sysfs_remove_groups(>kobj, groups);
+}
+
+/**
+ * devm_device_add_group - given a device, create a managed attribute group
+ * @dev:   The device to create the group for
+ * @grp:   The attribute group to create
+ *
+ * This function creates a group for the first time.  It will explicitly
+ * warn and error if any of the attribute files being created already exist.
+ *
+ * Returns 0 on success or error code on failure.
+ */
+int devm_device_add_group(struct device *dev, const struct attribute_group 
*grp)
+{
+   union device_attr_group_devres *devres;
+   int error;
+
+   devres = devres_alloc(devm_attr_group_remove,
+ sizeof(*devres), GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   error = sysfs_create_group(>kobj, grp);
+   if (error) {
+   devres_free(devres);
+   return error;
+   }
+
+   devres->group = grp;
+   devres_add(dev, devres);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_device_add_group);
+
+/**
+ * devm_device_remove_group: remove a managed group from a device
+ * @dev:   device to remove the group from
+ * @grp:   group to remove
+ *
+ * This function removes a group of attributes from a device. The attributes
+ * previously have to have been created for this group, otherwise it will fail.
+ */
+void devm_device_remove_group(struct device *dev,
+ const struct attribute_group *grp)
+{
+   WARN_ON(devres_release(dev, devm_attr_group_remove,
+  devm_attr_group_match,
+  /* cast away const */ (void *)grp));
+}
+EXPORT_SYMBOL_GPL(devm_device_remove_group);
+
+/**
+ * devm_device_add_groups - create a bunch of managed attribute groups
+ * @dev:   The device to create the group for
+ * @groups:The attribute groups to create, NULL terminated
+ *
+ * This function creates a bunch of managed attribute groups.  If an error
+ * occurs when creating a group, all previously created groups will be
+ * removed, unwinding everything back to the original state when this
+ * function was called.  It will explicitly warn and error if any of the
+ * attribute files being created already exist.
+ *
+ * Returns 0 on success or error code from sysfs_create_group on failure.
+ */
+int devm_device_add_groups(struct device *dev,
+  const struct attribute_group **groups)
+{
+   union device_attr_group_devres *devres;
+   int error;
+
+   devres = devres_alloc(devm_attr_groups_remove,
+ sizeof(*devres), GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   error = sysfs_create_groups(>kobj, groups);
+   if (error) {
+   devres_free(devres);
+   return error;
+   }
+
+   devres->groups = groups;
+   devres_add(dev, devres);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_device_add_groups);
+
+/**
+ * devm_device_remove_groups - remove a list of managed groups
+ *
+ * @dev:   The device for the groups to be removed from
+ * @groups:NULL terminated list of groups to be removed
+ *
+ * If groups is 

[PATCH v2 7/7] Input: axp20x-pek - switch to using devm_device_add_group()

[Dmitry Torokhov]

Now that we have proper managed API to create device attributes, let's
use it instead of installing a custom devm action.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/misc/axp20x-pek.c | 18 +-
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
index 38c79ebff033..cfeb0e943de6 100644
--- a/drivers/input/misc/axp20x-pek.c
+++ b/drivers/input/misc/axp20x-pek.c
@@ -182,13 +182,6 @@ static irqreturn_t axp20x_pek_irq(int irq, void *pwr)
return IRQ_HANDLED;
 }
 
-static void axp20x_remove_sysfs_group(void *_data)
-{
-   struct device *dev = _data;
-
-   sysfs_remove_group(>kobj, _attribute_group);
-}
-
 static int axp20x_pek_probe_input_device(struct axp20x_pek *axp20x_pek,
 struct platform_device *pdev)
 {
@@ -313,22 +306,13 @@ static int axp20x_pek_probe(struct platform_device *pdev)
return error;
}
 
-   error = sysfs_create_group(>dev.kobj, _attribute_group);
+   error = devm_device_add_group(>dev, _attribute_group);
if (error) {
dev_err(>dev, "Failed to create sysfs attributes: %d\n",
error);
return error;
}
 
-   error = devm_add_action(>dev,
-   axp20x_remove_sysfs_group, >dev);
-   if (error) {
-   axp20x_remove_sysfs_group(>dev);
-   dev_err(>dev, "Failed to add sysfs cleanup action: %d\n",
-   error);
-   return error;
-   }
-
platform_set_drvdata(pdev, axp20x_pek);
 
return 0;
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 4/7] driver core: add devm_device_add_group() and friends

[Dmitry Torokhov]

Many drivers create additional driver-specific device attributes when
binding to the device, and providing managed version of
device_create_group() will simplify unbinding and error handling in probe
path for such drivers.

Without managed version driver writers either have to mix manual and
managed resources, which is prone to errors, or open-code this function by
providing a wrapper to device_add_group() and use it with devm_add_action()
or devm_add_action_or_reset().

Signed-off-by: Dmitry Torokhov 
---
 drivers/base/core.c| 130 +
 include/linux/device.h |   9 
 2 files changed, 139 insertions(+)

diff --git a/drivers/base/core.c b/drivers/base/core.c
index 14f8cf5c8b05..09723532725d 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1035,6 +1035,136 @@ void device_remove_groups(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(device_remove_groups);
 
+union device_attr_group_devres {
+   const struct attribute_group *group;
+   const struct attribute_group **groups;
+};
+
+static int devm_attr_group_match(struct device *dev, void *res, void *data)
+{
+   return ((union device_attr_group_devres *)res)->group == data;
+}
+
+static void devm_attr_group_remove(struct device *dev, void *res)
+{
+   union device_attr_group_devres *devres = res;
+   const struct attribute_group *group = devres->group;
+
+   dev_dbg(dev, "%s: removing group %p\n", __func__, group);
+   sysfs_remove_group(>kobj, group);
+}
+
+static void devm_attr_groups_remove(struct device *dev, void *res)
+{
+   union device_attr_group_devres *devres = res;
+   const struct attribute_group **groups = devres->groups;
+
+   dev_dbg(dev, "%s: removing groups %p\n", __func__, groups);
+   sysfs_remove_groups(>kobj, groups);
+}
+
+/**
+ * devm_device_add_group - given a device, create a managed attribute group
+ * @dev:   The device to create the group for
+ * @grp:   The attribute group to create
+ *
+ * This function creates a group for the first time.  It will explicitly
+ * warn and error if any of the attribute files being created already exist.
+ *
+ * Returns 0 on success or error code on failure.
+ */
+int devm_device_add_group(struct device *dev, const struct attribute_group 
*grp)
+{
+   union device_attr_group_devres *devres;
+   int error;
+
+   devres = devres_alloc(devm_attr_group_remove,
+ sizeof(*devres), GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   error = sysfs_create_group(>kobj, grp);
+   if (error) {
+   devres_free(devres);
+   return error;
+   }
+
+   devres->group = grp;
+   devres_add(dev, devres);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_device_add_group);
+
+/**
+ * devm_device_remove_group: remove a managed group from a device
+ * @dev:   device to remove the group from
+ * @grp:   group to remove
+ *
+ * This function removes a group of attributes from a device. The attributes
+ * previously have to have been created for this group, otherwise it will fail.
+ */
+void devm_device_remove_group(struct device *dev,
+ const struct attribute_group *grp)
+{
+   WARN_ON(devres_release(dev, devm_attr_group_remove,
+  devm_attr_group_match,
+  /* cast away const */ (void *)grp));
+}
+EXPORT_SYMBOL_GPL(devm_device_remove_group);
+
+/**
+ * devm_device_add_groups - create a bunch of managed attribute groups
+ * @dev:   The device to create the group for
+ * @groups:The attribute groups to create, NULL terminated
+ *
+ * This function creates a bunch of managed attribute groups.  If an error
+ * occurs when creating a group, all previously created groups will be
+ * removed, unwinding everything back to the original state when this
+ * function was called.  It will explicitly warn and error if any of the
+ * attribute files being created already exist.
+ *
+ * Returns 0 on success or error code from sysfs_create_group on failure.
+ */
+int devm_device_add_groups(struct device *dev,
+  const struct attribute_group **groups)
+{
+   union device_attr_group_devres *devres;
+   int error;
+
+   devres = devres_alloc(devm_attr_groups_remove,
+ sizeof(*devres), GFP_KERNEL);
+   if (!devres)
+   return -ENOMEM;
+
+   error = sysfs_create_groups(>kobj, groups);
+   if (error) {
+   devres_free(devres);
+   return error;
+   }
+
+   devres->groups = groups;
+   devres_add(dev, devres);
+   return 0;
+}
+EXPORT_SYMBOL_GPL(devm_device_add_groups);
+
+/**
+ * devm_device_remove_groups - remove a list of managed groups
+ *
+ * @dev:   The device for the groups to be removed from
+ * @groups:NULL terminated list of groups to be removed
+ *
+ * If groups is not NULL, remove the 

[PATCH v2 5/7] Input: gpio_keys - use devm_device_add_group() for attributes

[Dmitry Torokhov]

Now that we have proper managed API to create device attributes, let's
start using it instead of the manual unwinding.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/keyboard/gpio_keys.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/input/keyboard/gpio_keys.c 
b/drivers/input/keyboard/gpio_keys.c
index f52812db91bc..e9f0ebf3267a 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -827,7 +827,7 @@ static int gpio_keys_probe(struct platform_device *pdev)
 
fwnode_handle_put(child);
 
-   error = sysfs_create_group(>kobj, _keys_attr_group);
+   error = devm_device_add_group(dev, _keys_attr_group);
if (error) {
dev_err(dev, "Unable to export keys/switches, error: %d\n",
error);
@@ -838,22 +838,11 @@ static int gpio_keys_probe(struct platform_device *pdev)
if (error) {
dev_err(dev, "Unable to register input device, error: %d\n",
error);
-   goto err_remove_group;
+   return error;
}
 
device_init_wakeup(dev, wakeup);
 
-   return 0;
-
-err_remove_group:
-   sysfs_remove_group(>kobj, _keys_attr_group);
-   return error;
-}
-
-static int gpio_keys_remove(struct platform_device *pdev)
-{
-   sysfs_remove_group(>dev.kobj, _keys_attr_group);
-
return 0;
 }
 
@@ -912,7 +901,6 @@ static SIMPLE_DEV_PM_OPS(gpio_keys_pm_ops, 
gpio_keys_suspend, gpio_keys_resume);
 
 static struct platform_driver gpio_keys_device_driver = {
.probe  = gpio_keys_probe,
-   .remove = gpio_keys_remove,
.driver = {
.name   = "gpio-keys",
.pm = _keys_pm_ops,
-- 
2.14.0.rc0.284.gd933b75aa4-goog

[PATCH v2 5/7] Input: gpio_keys - use devm_device_add_group() for attributes

[Dmitry Torokhov]

Now that we have proper managed API to create device attributes, let's
start using it instead of the manual unwinding.

Signed-off-by: Dmitry Torokhov 
---
 drivers/input/keyboard/gpio_keys.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/drivers/input/keyboard/gpio_keys.c 
b/drivers/input/keyboard/gpio_keys.c
index f52812db91bc..e9f0ebf3267a 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -827,7 +827,7 @@ static int gpio_keys_probe(struct platform_device *pdev)
 
fwnode_handle_put(child);
 
-   error = sysfs_create_group(>kobj, _keys_attr_group);
+   error = devm_device_add_group(dev, _keys_attr_group);
if (error) {
dev_err(dev, "Unable to export keys/switches, error: %d\n",
error);
@@ -838,22 +838,11 @@ static int gpio_keys_probe(struct platform_device *pdev)
if (error) {
dev_err(dev, "Unable to register input device, error: %d\n",
error);
-   goto err_remove_group;
+   return error;
}
 
device_init_wakeup(dev, wakeup);
 
-   return 0;
-
-err_remove_group:
-   sysfs_remove_group(>kobj, _keys_attr_group);
-   return error;
-}
-
-static int gpio_keys_remove(struct platform_device *pdev)
-{
-   sysfs_remove_group(>dev.kobj, _keys_attr_group);
-
return 0;
 }
 
@@ -912,7 +901,6 @@ static SIMPLE_DEV_PM_OPS(gpio_keys_pm_ops, 
gpio_keys_suspend, gpio_keys_resume);
 
 static struct platform_driver gpio_keys_device_driver = {
.probe  = gpio_keys_probe,
-   .remove = gpio_keys_remove,
.driver = {
.name   = "gpio-keys",
.pm = _keys_pm_ops,
-- 
2.14.0.rc0.284.gd933b75aa4-goog

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

[Paul Moore]

On Wed, Jul 19, 2017 at 8:03 PM, Paul Moore  wrote:
> On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook  wrote:
>> The SELinux bprm_secureexec hook can be merged with the bprm_set_creds
>> hook since it's dealing with the same information, and all of the details
>> are finalized during the first call to the bprm_set_creds hook via
>> prepare_binprm() (subsequent calls due to binfmt_script, etc, are ignored
>> via bprm->called_set_creds).
>>
>> Here, the test can just happen at the end of the bprm_set_creds hook,
>> and the bprm_secureexec hook can be dropped.
>>
>> Cc: Paul Moore 
>> Cc: Stephen Smalley 
>> Signed-off-by: Kees Cook 
>> ---
>>  security/selinux/hooks.c | 24 +---
>>  1 file changed, 5 insertions(+), 19 deletions(-)
>
> This seems reasonable in the context of the other changes.
>
> Stephen just posted an AT_SECURE test for the selinux-testsuite on the
> SELinux mailing list, it would be nice to ensure that this patchset
> doesn't run afoul of that.

Quick follow-up: I just merged Stephen's test into the test suite:

* https://github.com/SELinuxProject/selinux-testsuite

> Acked-by: Paul Moore 
>
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 0f1450a06b02..18038f73a2f7 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -2413,30 +2413,17 @@ static int selinux_bprm_set_creds(struct 
>> linux_binprm *bprm)
>>
>> /* Clear any possibly unsafe personality bits on exec: */
>> bprm->per_clear |= PER_CLEAR_ON_SETID;
>> -   }
>> -
>> -   return 0;
>> -}
>> -
>> -static int selinux_bprm_secureexec(struct linux_binprm *bprm)
>> -{
>> -   const struct task_security_struct *tsec = current_security();
>> -   u32 sid, osid;
>> -   int atsecure = 0;
>> -
>> -   sid = tsec->sid;
>> -   osid = tsec->osid;
>>
>> -   if (osid != sid) {
>> /* Enable secure mode for SIDs transitions unless
>>the noatsecure permission is granted between
>>the two SIDs, i.e. ahp returns 0. */
>> -   atsecure = avc_has_perm(osid, sid,
>> -   SECCLASS_PROCESS,
>> -   PROCESS__NOATSECURE, NULL);
>> +   rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
>> + SECCLASS_PROCESS, PROCESS__NOATSECURE,
>> + NULL);
>> +   bprm->secureexec |= !!rc;
>> }
>>
>> -   return !!atsecure;
>> +   return 0;
>>  }
>>
>>  static int match_file(const void *p, struct file *file, unsigned fd)
>> @@ -6151,7 +6138,6 @@ static struct security_hook_list selinux_hooks[] 
>> __lsm_ro_after_init = {
>> LSM_HOOK_INIT(bprm_set_creds, selinux_bprm_set_creds),
>> LSM_HOOK_INIT(bprm_committing_creds, selinux_bprm_committing_creds),
>> LSM_HOOK_INIT(bprm_committed_creds, selinux_bprm_committed_creds),
>> -   LSM_HOOK_INIT(bprm_secureexec, selinux_bprm_secureexec),
>>
>> LSM_HOOK_INIT(sb_alloc_security, selinux_sb_alloc_security),
>> LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security),
>> --
>> 2.7.4
>
> --
> paul moore
> www.paul-moore.com



-- 
paul moore
www.paul-moore.com

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

[Paul Moore]

On Wed, Jul 19, 2017 at 8:03 PM, Paul Moore  wrote:
> On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook  wrote:
>> The SELinux bprm_secureexec hook can be merged with the bprm_set_creds
>> hook since it's dealing with the same information, and all of the details
>> are finalized during the first call to the bprm_set_creds hook via
>> prepare_binprm() (subsequent calls due to binfmt_script, etc, are ignored
>> via bprm->called_set_creds).
>>
>> Here, the test can just happen at the end of the bprm_set_creds hook,
>> and the bprm_secureexec hook can be dropped.
>>
>> Cc: Paul Moore 
>> Cc: Stephen Smalley 
>> Signed-off-by: Kees Cook 
>> ---
>>  security/selinux/hooks.c | 24 +---
>>  1 file changed, 5 insertions(+), 19 deletions(-)
>
> This seems reasonable in the context of the other changes.
>
> Stephen just posted an AT_SECURE test for the selinux-testsuite on the
> SELinux mailing list, it would be nice to ensure that this patchset
> doesn't run afoul of that.

Quick follow-up: I just merged Stephen's test into the test suite:

* https://github.com/SELinuxProject/selinux-testsuite

> Acked-by: Paul Moore 
>
>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>> index 0f1450a06b02..18038f73a2f7 100644
>> --- a/security/selinux/hooks.c
>> +++ b/security/selinux/hooks.c
>> @@ -2413,30 +2413,17 @@ static int selinux_bprm_set_creds(struct 
>> linux_binprm *bprm)
>>
>> /* Clear any possibly unsafe personality bits on exec: */
>> bprm->per_clear |= PER_CLEAR_ON_SETID;
>> -   }
>> -
>> -   return 0;
>> -}
>> -
>> -static int selinux_bprm_secureexec(struct linux_binprm *bprm)
>> -{
>> -   const struct task_security_struct *tsec = current_security();
>> -   u32 sid, osid;
>> -   int atsecure = 0;
>> -
>> -   sid = tsec->sid;
>> -   osid = tsec->osid;
>>
>> -   if (osid != sid) {
>> /* Enable secure mode for SIDs transitions unless
>>the noatsecure permission is granted between
>>the two SIDs, i.e. ahp returns 0. */
>> -   atsecure = avc_has_perm(osid, sid,
>> -   SECCLASS_PROCESS,
>> -   PROCESS__NOATSECURE, NULL);
>> +   rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
>> + SECCLASS_PROCESS, PROCESS__NOATSECURE,
>> + NULL);
>> +   bprm->secureexec |= !!rc;
>> }
>>
>> -   return !!atsecure;
>> +   return 0;
>>  }
>>
>>  static int match_file(const void *p, struct file *file, unsigned fd)
>> @@ -6151,7 +6138,6 @@ static struct security_hook_list selinux_hooks[] 
>> __lsm_ro_after_init = {
>> LSM_HOOK_INIT(bprm_set_creds, selinux_bprm_set_creds),
>> LSM_HOOK_INIT(bprm_committing_creds, selinux_bprm_committing_creds),
>> LSM_HOOK_INIT(bprm_committed_creds, selinux_bprm_committed_creds),
>> -   LSM_HOOK_INIT(bprm_secureexec, selinux_bprm_secureexec),
>>
>> LSM_HOOK_INIT(sb_alloc_security, selinux_sb_alloc_security),
>> LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security),
>> --
>> 2.7.4
>
> --
> paul moore
> www.paul-moore.com



-- 
paul moore
www.paul-moore.com

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Randy Dunlap]

On 07/19/2017 05:08 PM, Linus Torvalds wrote:
> On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton
>  wrote:
>>
>> Linus, can you please grab this?
> 
> Ugh. It doesn't apply cleanly. Probably for some really small stupid reason.

Must be small and stupid.  It applies cleanly for me.
Do you have changes that are not pushed out publicly?


> I can easily just look at the reject and fix it, but I don't really
> want to. Why? Because I hate the MAINTAINERS file.


-- 
~Randy

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Randy Dunlap]

On 07/19/2017 05:08 PM, Linus Torvalds wrote:
> On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton
>  wrote:
>>
>> Linus, can you please grab this?
> 
> Ugh. It doesn't apply cleanly. Probably for some really small stupid reason.

Must be small and stupid.  It applies cleanly for me.
Do you have changes that are not pushed out publicly?


> I can easily just look at the reject and fix it, but I don't really
> want to. Why? Because I hate the MAINTAINERS file.


-- 
~Randy

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Randy Dunlap]

On 07/19/2017 05:08 PM, Linus Torvalds wrote:
> On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton
>  wrote:
>>
>> Linus, can you please grab this?
> 
> Ugh. It doesn't apply cleanly. Probably for some really small stupid reason.
> 
> I can easily just look at the reject and fix it, but I don't really
> want to. Why? Because I hate the MAINTAINERS file.
> 
> It's the most painful file for merging too, because everybody touches
> it - kind of like the old "one single Kconfig file" was back in the
> bad old days.
> 
> For example, just during this merge window:
> 
> $ git rev-list --count --no-merges v4.12.. MAINTAINERS
> 112
> 
> and while most of them obviously didn't cause any conflicts (there
> were four this cycle), it's still my least favourite "stupid work".
> That file pretty consistently gets 100+ changes to it:
> 
>   v4.1: 87
>   v4.2: 109
>   v4.3: 94
>   v4.4: 91
>   v4.5: 118
>   v4.6: 98
>   v4.7: 112
>   v4.8: 121
>   v4.9: 128
>   v4.10: 135
>   v4.11: 78
>   v4.12: 127
> 
> So I'm wondering if
> 
>  (a) we could add a script to do the alphabetical ordering properly.

Yeah, I have already thought about that one.  I may get around tuit
one day.  Or maybe Joe could/would.

>  (b) we could split this thing up some sane way.

makes sense.

> Anybody got any ideas?

  (c) funnel all changes thru Andrew (but really foo should be able to make
changes to her MAINTAINERS entry)

> I'm throwing out _one_ idea: split it up by the main F: line, so that
> maintainership information ends up being hierarchical like the Kconfig
> files.  Teach "get_maintainer.pl" to just do "find . -name
> MAINTAINERS" instead?
> 
> I'm not saying that's a great idea (quite often the "main F: line"
> might be ambiguous), but it's the most obvious one.
> 
> This is not a _huge_ problem, but it has been a slight annoyance for a
> long time now. So it would be good to maybe at least discuss it a bit.


-- 
~Randy

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Randy Dunlap]

On 07/19/2017 05:08 PM, Linus Torvalds wrote:
> On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton
>  wrote:
>>
>> Linus, can you please grab this?
> 
> Ugh. It doesn't apply cleanly. Probably for some really small stupid reason.
> 
> I can easily just look at the reject and fix it, but I don't really
> want to. Why? Because I hate the MAINTAINERS file.
> 
> It's the most painful file for merging too, because everybody touches
> it - kind of like the old "one single Kconfig file" was back in the
> bad old days.
> 
> For example, just during this merge window:
> 
> $ git rev-list --count --no-merges v4.12.. MAINTAINERS
> 112
> 
> and while most of them obviously didn't cause any conflicts (there
> were four this cycle), it's still my least favourite "stupid work".
> That file pretty consistently gets 100+ changes to it:
> 
>   v4.1: 87
>   v4.2: 109
>   v4.3: 94
>   v4.4: 91
>   v4.5: 118
>   v4.6: 98
>   v4.7: 112
>   v4.8: 121
>   v4.9: 128
>   v4.10: 135
>   v4.11: 78
>   v4.12: 127
> 
> So I'm wondering if
> 
>  (a) we could add a script to do the alphabetical ordering properly.

Yeah, I have already thought about that one.  I may get around tuit
one day.  Or maybe Joe could/would.

>  (b) we could split this thing up some sane way.

makes sense.

> Anybody got any ideas?

  (c) funnel all changes thru Andrew (but really foo should be able to make
changes to her MAINTAINERS entry)

> I'm throwing out _one_ idea: split it up by the main F: line, so that
> maintainership information ends up being hierarchical like the Kconfig
> files.  Teach "get_maintainer.pl" to just do "find . -name
> MAINTAINERS" instead?
> 
> I'm not saying that's a great idea (quite often the "main F: line"
> might be ambiguous), but it's the most obvious one.
> 
> This is not a _huge_ problem, but it has been a slight annoyance for a
> long time now. So it would be good to maybe at least discuss it a bit.


-- 
~Randy

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 5:08 PM, Linus Torvalds
 wrote:
>
> I'm throwing out _one_ idea: split it up by the main F: line, so that
> maintainership information ends up being hierarchical like the Kconfig
> files.  Teach "get_maintainer.pl" to just do "find . -name
> MAINTAINERS" instead?

For a more radical change, get rid of the MAINTAINERS file entirely,
and put the information into the Kconfig files - kind of like the
"help" text, except with the rules.

It's probably not really workable, but in many ways the maintainership
often tends to more closely match the configuration than the tree
layout, and some of the fields would actually make sense for the help
thing (eg the whole support status, but also the web-page with
status/info pointer).

Again - just throwing this out as a "please discuss" thing.

Linus

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 5:08 PM, Linus Torvalds
 wrote:
>
> I'm throwing out _one_ idea: split it up by the main F: line, so that
> maintainership information ends up being hierarchical like the Kconfig
> files.  Teach "get_maintainer.pl" to just do "find . -name
> MAINTAINERS" instead?

For a more radical change, get rid of the MAINTAINERS file entirely,
and put the information into the Kconfig files - kind of like the
"help" text, except with the rules.

It's probably not really workable, but in many ways the maintainership
often tends to more closely match the configuration than the tree
layout, and some of the fields would actually make sense for the help
thing (eg the whole support status, but also the web-page with
status/info pointer).

Again - just throwing this out as a "please discuss" thing.

Linus

Re: [RFC 06/22] kvm: Adapt assembly for PIE support

[H. Peter Anvin]

,Chris Metcalf ,"Paul E . 
McKenney" ,Andrew Morton 
,Christopher Li ,Dou Liyang 
,Masahiro Yamada 
,Daniel Borkmann ,Markus 
Trippelsdorf ,Peter Foley ,Steven 
Rostedt ,Tim Chen ,Catalin 
Marinas ,Matthew Wilcox 
,Michal Hocko ,Rob Landley 
,Jiri Kosina ,"H . J . Lu" 
,Paul Bolle ,Baoquan He 
,Daniel Micay ,the arch/x86 maintainers 
,"linux-cry...@vger.kernel.org" 
,Linux Kernel Mailing List 
,xen-de...@lists.xenproject.org,kvm list
,linux-pm ,linux-arch 
,Linux-Sparse ,Kernel 
Hardening 
From: h...@zytor.com
Message-ID: <83ba7600-bc8d-4c91-812c-dd2a0bf44...@zytor.com>

On July 19, 2017 3:58:07 PM PDT, Ard Biesheuvel  
wrote:
>On 19 July 2017 at 23:27, H. Peter Anvin  wrote:
>> On 07/19/17 08:40, Thomas Garnier wrote:

 This doesn't look right.  It's accessing a per-cpu variable.  The
 per-cpu section is an absolute, zero-based section and not subject
>to
 relocation.
>>>
>>> PIE does not respect the zero-based section, it tries to have
>>> everything relative. Patch 16/22 also adapt per-cpu to work with PIE
>>> (while keeping the zero absolute design by default).
>>>
>>
>> This is silly.  The right thing is for PIE is to be explicitly
>absolute,
>> without (%rip).  The use of (%rip) memory references for percpu is
>just
>> an optimization.
>>
>
>Sadly, there is an issue in binutils that may prevent us from doing
>this as cleanly as we would want.
>
>For historical reasons, bfd.ld emits special symbols like
>__GLOBAL_OFFSET_TABLE__ as absolute symbols with a section index of
>SHN_ABS, even though it is quite obvious that they are relative like
>any other symbol that points into the image. Unfortunately, this means
>that binutils needs to emit R_X86_64_RELATIVE relocations even for
>SHN_ABS symbols, which means we lose the ability to use both absolute
>and relocatable symbols in the same PIE image (unless the reloc tool
>can filter them out)
>
>More info here:
>https://sourceware.org/bugzilla/show_bug.cgi?id=19818

The reloc tool already has the ability to filter symbols.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

[H. Peter Anvin]

,"Paul E . McKenney" ,Andrew 
Morton ,Christopher Li ,Dou 
Liyang ,Masahiro Yamada 
,Daniel Borkmann ,Markus 
Trippelsdorf ,Peter Foley ,Steven 
Rostedt ,Tim Chen ,Ard 
Biesheuvel ,Catalin Marinas 
,Matthew Wilcox ,Michal Hocko 
,Rob Landley ,Jiri Kosina 
,"H . J . Lu" ,Paul Bolle 
,Baoquan He ,Daniel Micay 
,the arch/x86 maintainers 
,linux-cry...@vger.kernel.org,LKML 
,xen-de...@lists.xenproject.org,kvm list 
,Linux PM list
,linux-arch 
,linux-spa...@vger.kernel.org,Kernel Hardening 

From: h...@zytor.com
Message-ID: <0ef6faaa-a99c-4f0d-9e4a-ad25e9395...@zytor.com>

On July 19, 2017 4:25:56 PM PDT, Thomas Garnier  wrote:
>On Wed, Jul 19, 2017 at 4:08 PM, H. Peter Anvin  wrote:
>> On 07/19/17 15:47, Thomas Garnier wrote:
>>> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin 
>wrote:
 On 07/18/17 15:33, Thomas Garnier wrote:
> The x86 relocation tool generates a list of 32-bit signed
>integers. There
> was no need to use 64-bit integers because all addresses where
>above the 2G
> top of the memory.
>
> This change add a large-reloc option to generate 64-bit unsigned
>integers.
> It can be used when the kernel plan to go below the top 2G and
>32-bit
> integers are not enough.

 Why on Earth?  This would only be necessary if the *kernel itself*
>was
 more than 2G, which isn't going to happen for the forseeable
>future.
>>>
>>> Because the relocation integer is an absolute address, not an offset
>>> in the binary. Next iteration, I can try using a 32-bit offset for
>>> everyone.
>>
>> It is an absolute address *as the kernel was originally linked*, for
>> obvious reasons.
>
>Sure when the kernel was just above 0x8000, it doesn't
>work when it goes down to 0x. That's why using an
>offset might make more sense in general.
>
>>
>> -hpa
>>

What is the motivation for changing the pre linked address at all?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [RFC 06/22] kvm: Adapt assembly for PIE support

[H. Peter Anvin]

,Chris Metcalf ,"Paul E . 
McKenney" ,Andrew Morton 
,Christopher Li ,Dou Liyang 
,Masahiro Yamada 
,Daniel Borkmann ,Markus 
Trippelsdorf ,Peter Foley ,Steven 
Rostedt ,Tim Chen ,Catalin 
Marinas ,Matthew Wilcox 
,Michal Hocko ,Rob Landley 
,Jiri Kosina ,"H . J . Lu" 
,Paul Bolle ,Baoquan He 
,Daniel Micay ,the arch/x86 maintainers 
,"linux-cry...@vger.kernel.org" 
,Linux Kernel Mailing List 
,xen-de...@lists.xenproject.org,kvm list
,linux-pm ,linux-arch 
,Linux-Sparse ,Kernel 
Hardening 
From: h...@zytor.com
Message-ID: <83ba7600-bc8d-4c91-812c-dd2a0bf44...@zytor.com>

On July 19, 2017 3:58:07 PM PDT, Ard Biesheuvel  
wrote:
>On 19 July 2017 at 23:27, H. Peter Anvin  wrote:
>> On 07/19/17 08:40, Thomas Garnier wrote:

 This doesn't look right.  It's accessing a per-cpu variable.  The
 per-cpu section is an absolute, zero-based section and not subject
>to
 relocation.
>>>
>>> PIE does not respect the zero-based section, it tries to have
>>> everything relative. Patch 16/22 also adapt per-cpu to work with PIE
>>> (while keeping the zero absolute design by default).
>>>
>>
>> This is silly.  The right thing is for PIE is to be explicitly
>absolute,
>> without (%rip).  The use of (%rip) memory references for percpu is
>just
>> an optimization.
>>
>
>Sadly, there is an issue in binutils that may prevent us from doing
>this as cleanly as we would want.
>
>For historical reasons, bfd.ld emits special symbols like
>__GLOBAL_OFFSET_TABLE__ as absolute symbols with a section index of
>SHN_ABS, even though it is quite obvious that they are relative like
>any other symbol that points into the image. Unfortunately, this means
>that binutils needs to emit R_X86_64_RELATIVE relocations even for
>SHN_ABS symbols, which means we lose the ability to use both absolute
>and relocatable symbols in the same PIE image (unless the reloc tool
>can filter them out)
>
>More info here:
>https://sourceware.org/bugzilla/show_bug.cgi?id=19818

The reloc tool already has the ability to filter symbols.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations

[H. Peter Anvin]

,"Paul E . McKenney" ,Andrew 
Morton ,Christopher Li ,Dou 
Liyang ,Masahiro Yamada 
,Daniel Borkmann ,Markus 
Trippelsdorf ,Peter Foley ,Steven 
Rostedt ,Tim Chen ,Ard 
Biesheuvel ,Catalin Marinas 
,Matthew Wilcox ,Michal Hocko 
,Rob Landley ,Jiri Kosina 
,"H . J . Lu" ,Paul Bolle 
,Baoquan He ,Daniel Micay 
,the arch/x86 maintainers 
,linux-cry...@vger.kernel.org,LKML 
,xen-de...@lists.xenproject.org,kvm list 
,Linux PM list
,linux-arch 
,linux-spa...@vger.kernel.org,Kernel Hardening 

From: h...@zytor.com
Message-ID: <0ef6faaa-a99c-4f0d-9e4a-ad25e9395...@zytor.com>

On July 19, 2017 4:25:56 PM PDT, Thomas Garnier  wrote:
>On Wed, Jul 19, 2017 at 4:08 PM, H. Peter Anvin  wrote:
>> On 07/19/17 15:47, Thomas Garnier wrote:
>>> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin 
>wrote:
 On 07/18/17 15:33, Thomas Garnier wrote:
> The x86 relocation tool generates a list of 32-bit signed
>integers. There
> was no need to use 64-bit integers because all addresses where
>above the 2G
> top of the memory.
>
> This change add a large-reloc option to generate 64-bit unsigned
>integers.
> It can be used when the kernel plan to go below the top 2G and
>32-bit
> integers are not enough.

 Why on Earth?  This would only be necessary if the *kernel itself*
>was
 more than 2G, which isn't going to happen for the forseeable
>future.
>>>
>>> Because the relocation integer is an absolute address, not an offset
>>> in the binary. Next iteration, I can try using a 32-bit offset for
>>> everyone.
>>
>> It is an absolute address *as the kernel was originally linked*, for
>> obvious reasons.
>
>Sure when the kernel was just above 0x8000, it doesn't
>work when it goes down to 0x. That's why using an
>offset might make more sense in general.
>
>>
>> -hpa
>>

What is the motivation for changing the pre linked address at all?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[PATCH] sparc64: Register hugepages during arch init

[Nitin Gupta]

Add hstate for each supported hugepage size using
arch initcall. This change fixes some hugepage
parameter parsing inconsistencies:

case 1: no hugepage parameters

 Without hugepage parameters, only a hugepages-8192kB entry is visible
 in sysfs.  It's different from x86_64 where both 2M and 1G hugepage
 sizes are available.

case 2: default_hugepagesz=[64K|256M|2G]

 When specifying only a default_hugepagesz parameter, the default
 hugepage size isn't really changed and it stays at 8M. This is again
 different from x86_64.

Orabug: 25869946

Reviewed-by: Bob Picco 
Signed-off-by: Nitin Gupta 
---
 arch/sparc/mm/init_64.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 3c40ebd..fed73f1 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -325,6 +325,29 @@ static void __update_mmu_tsb_insert(struct mm_struct *mm, 
unsigned long tsb_inde
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
+static void __init add_huge_page_size(unsigned long size)
+{
+   unsigned int order;
+
+   if (size_to_hstate(size))
+   return;
+
+   order = ilog2(size) - PAGE_SHIFT;
+   hugetlb_add_hstate(order);
+}
+
+static int __init hugetlbpage_init(void)
+{
+   add_huge_page_size(1UL << HPAGE_64K_SHIFT);
+   add_huge_page_size(1UL << HPAGE_SHIFT);
+   add_huge_page_size(1UL << HPAGE_256MB_SHIFT);
+   add_huge_page_size(1UL << HPAGE_2GB_SHIFT);
+
+   return 0;
+}
+
+arch_initcall(hugetlbpage_init);
+
 static int __init setup_hugepagesz(char *string)
 {
unsigned long long hugepage_size;
@@ -364,7 +387,7 @@ static int __init setup_hugepagesz(char *string)
goto out;
}
 
-   hugetlb_add_hstate(hugepage_shift - PAGE_SHIFT);
+   add_huge_page_size(hugepage_size);
rc = 1;
 
 out:
-- 
2.9.2

[PATCH] sparc64: Register hugepages during arch init

[Nitin Gupta]

Add hstate for each supported hugepage size using
arch initcall. This change fixes some hugepage
parameter parsing inconsistencies:

case 1: no hugepage parameters

 Without hugepage parameters, only a hugepages-8192kB entry is visible
 in sysfs.  It's different from x86_64 where both 2M and 1G hugepage
 sizes are available.

case 2: default_hugepagesz=[64K|256M|2G]

 When specifying only a default_hugepagesz parameter, the default
 hugepage size isn't really changed and it stays at 8M. This is again
 different from x86_64.

Orabug: 25869946

Reviewed-by: Bob Picco 
Signed-off-by: Nitin Gupta 
---
 arch/sparc/mm/init_64.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index 3c40ebd..fed73f1 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -325,6 +325,29 @@ static void __update_mmu_tsb_insert(struct mm_struct *mm, 
unsigned long tsb_inde
 }
 
 #ifdef CONFIG_HUGETLB_PAGE
+static void __init add_huge_page_size(unsigned long size)
+{
+   unsigned int order;
+
+   if (size_to_hstate(size))
+   return;
+
+   order = ilog2(size) - PAGE_SHIFT;
+   hugetlb_add_hstate(order);
+}
+
+static int __init hugetlbpage_init(void)
+{
+   add_huge_page_size(1UL << HPAGE_64K_SHIFT);
+   add_huge_page_size(1UL << HPAGE_SHIFT);
+   add_huge_page_size(1UL << HPAGE_256MB_SHIFT);
+   add_huge_page_size(1UL << HPAGE_2GB_SHIFT);
+
+   return 0;
+}
+
+arch_initcall(hugetlbpage_init);
+
 static int __init setup_hugepagesz(char *string)
 {
unsigned long long hugepage_size;
@@ -364,7 +387,7 @@ static int __init setup_hugepagesz(char *string)
goto out;
}
 
-   hugetlb_add_hstate(hugepage_shift - PAGE_SHIFT);
+   add_huge_page_size(hugepage_size);
rc = 1;
 
 out:
-- 
2.9.2

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton
 wrote:
>
> Linus, can you please grab this?

Ugh. It doesn't apply cleanly. Probably for some really small stupid reason.

I can easily just look at the reject and fix it, but I don't really
want to. Why? Because I hate the MAINTAINERS file.

It's the most painful file for merging too, because everybody touches
it - kind of like the old "one single Kconfig file" was back in the
bad old days.

For example, just during this merge window:

$ git rev-list --count --no-merges v4.12.. MAINTAINERS
112

and while most of them obviously didn't cause any conflicts (there
were four this cycle), it's still my least favourite "stupid work".
That file pretty consistently gets 100+ changes to it:

  v4.1: 87
  v4.2: 109
  v4.3: 94
  v4.4: 91
  v4.5: 118
  v4.6: 98
  v4.7: 112
  v4.8: 121
  v4.9: 128
  v4.10: 135
  v4.11: 78
  v4.12: 127

So I'm wondering if

 (a) we could add a script to do the alphabetical ordering properly.

 (b) we could split this thing up some sane way.

Anybody got any ideas?

I'm throwing out _one_ idea: split it up by the main F: line, so that
maintainership information ends up being hierarchical like the Kconfig
files.  Teach "get_maintainer.pl" to just do "find . -name
MAINTAINERS" instead?

I'm not saying that's a great idea (quite often the "main F: line"
might be ambiguous), but it's the most obvious one.

This is not a _huge_ problem, but it has been a slight annoyance for a
long time now. So it would be good to maybe at least discuss it a bit.

Hmm?

   Linus

Re: [PATCH RESEND v4] MAINTAINERS: fix lots of alphabetic ordering

[Linus Torvalds]

On Wed, Jul 19, 2017 at 2:44 PM, Andrew Morton
 wrote:
>
> Linus, can you please grab this?

Ugh. It doesn't apply cleanly. Probably for some really small stupid reason.

I can easily just look at the reject and fix it, but I don't really
want to. Why? Because I hate the MAINTAINERS file.

It's the most painful file for merging too, because everybody touches
it - kind of like the old "one single Kconfig file" was back in the
bad old days.

For example, just during this merge window:

$ git rev-list --count --no-merges v4.12.. MAINTAINERS
112

and while most of them obviously didn't cause any conflicts (there
were four this cycle), it's still my least favourite "stupid work".
That file pretty consistently gets 100+ changes to it:

  v4.1: 87
  v4.2: 109
  v4.3: 94
  v4.4: 91
  v4.5: 118
  v4.6: 98
  v4.7: 112
  v4.8: 121
  v4.9: 128
  v4.10: 135
  v4.11: 78
  v4.12: 127

So I'm wondering if

 (a) we could add a script to do the alphabetical ordering properly.

 (b) we could split this thing up some sane way.

Anybody got any ideas?

I'm throwing out _one_ idea: split it up by the main F: line, so that
maintainership information ends up being hierarchical like the Kconfig
files.  Teach "get_maintainer.pl" to just do "find . -name
MAINTAINERS" instead?

I'm not saying that's a great idea (quite often the "main F: line"
might be ambiguous), but it's the most obvious one.

This is not a _huge_ problem, but it has been a slight annoyance for a
long time now. So it would be good to maybe at least discuss it a bit.

Hmm?

   Linus

Re: commit 16ecba59 breaks 82574L under heavy load.

[Benjamin Poirier]

On 2017/07/19 10:19, Lennart Sorensen wrote:
> On Tue, Jul 18, 2017 at 04:14:35PM -0700, Benjamin Poirier wrote:
> > Thanks for the detailed analysis.
> > 
> > Refering to the original discussion around this patch series, it seemed like
> > the IMS bit for a condition had to be set for the Other interrupt to be 
> > raised
> > for that condition.
> > 
> > https://lkml.org/lkml/2015/11/4/683
> > 
> > In this case however, E1000_ICR_RXT0 is not set in IMS so Other shouldn't be
> > raised for Receiver Overrun. Apparently something is going on...
> > 
> > I can reproduce the spurious Other interrupts with a simple mdelay()
> > With the debugging patch at the end of the mail I see stuff like this
> > while blasting with udp frames:
> >   -0 [086] d.h1 15338.742675: e1000_msix_other: got Other 
> > interrupt, count 15127
> ><...>-54504 [086] d.h. 15338.742724: e1000_msix_other: got Other 
> > interrupt, count 1
> ><...>-54504 [086] d.h. 15338.742774: e1000_msix_other: got Other 
> > interrupt, count 1
> ><...>-54504 [086] d.h. 15338.742824: e1000_msix_other: got Other 
> > interrupt, count 1
> >   -0 [086] d.h1 15340.745123: e1000_msix_other: got Other 
> > interrupt, count 27584
> ><...>-54504 [086] d.h. 15340.745172: e1000_msix_other: got Other 
> > interrupt, count 1
> ><...>-54504 [086] d.h. 15340.745222: e1000_msix_other: got Other 
> > interrupt, count 1
> ><...>-54504 [086] d.h. 15340.745272: e1000_msix_other: got Other 
> > interrupt, count 1
> > 
> > > hence sets the flag that (unfortunately) means both link is down and link
> > > state should be checked.  Since this now happens 3000 times per second,
> > > the chances of it happening while the watchdog_task is checking the link
> > > state becomes pretty high, and it if does happen to coincice, then the
> > > watchdog_task will reset the adapter, which causes a real loss of link.
> > 
> > Through which path does watchdog_task reset the adapter? I didn't
> > reproduce that.
> 
> The other interrupt happens and sets get_link_status to true.  At some
> point the watchdog_task runs on some core and calls e1000e_has_link,
> which then calls check_for_link to find out the current link status.
> While e1000e_check_for_copper_link is checking the link state and
> after updating get_link_status to false to indicate link is up, another
> interrupt occurs and another core handles it and changes get_link_status
> to true again.  So by the time e1000e_has_link goes to determine the
> return value, get_link_state has changed back again so now it returns
> link down, and as a result the watchdog_task calls reset, because we
> have packets in the transmit queue (we were busy forwarding over 10
> packets per second when it happened).

Ah I see. Thanks again.

In your previous mail,
On 2017/07/18 10:21, Lennart Sorensen wrote:
[...]
> I tried checking what the bits in the ICR actually were under these
> conditions, and it would appear that the only bit set is 24 (the Other
> Causes interrupt bit).  So I don't know what the real cause is although

Are you sure about this? In my testing, while triggering the overrun
with the msleep, I read ICR when entering e1000_msix_other() and RXO is
consistently set.

I'm working on a patch that uses that fact to handle the situation and
limit the interrupt.

Re: commit 16ecba59 breaks 82574L under heavy load.

[Benjamin Poirier]

On 2017/07/19 10:19, Lennart Sorensen wrote:
> On Tue, Jul 18, 2017 at 04:14:35PM -0700, Benjamin Poirier wrote:
> > Thanks for the detailed analysis.
> > 
> > Refering to the original discussion around this patch series, it seemed like
> > the IMS bit for a condition had to be set for the Other interrupt to be 
> > raised
> > for that condition.
> > 
> > https://lkml.org/lkml/2015/11/4/683
> > 
> > In this case however, E1000_ICR_RXT0 is not set in IMS so Other shouldn't be
> > raised for Receiver Overrun. Apparently something is going on...
> > 
> > I can reproduce the spurious Other interrupts with a simple mdelay()
> > With the debugging patch at the end of the mail I see stuff like this
> > while blasting with udp frames:
> >   -0 [086] d.h1 15338.742675: e1000_msix_other: got Other 
> > interrupt, count 15127
> ><...>-54504 [086] d.h. 15338.742724: e1000_msix_other: got Other 
> > interrupt, count 1
> ><...>-54504 [086] d.h. 15338.742774: e1000_msix_other: got Other 
> > interrupt, count 1
> ><...>-54504 [086] d.h. 15338.742824: e1000_msix_other: got Other 
> > interrupt, count 1
> >   -0 [086] d.h1 15340.745123: e1000_msix_other: got Other 
> > interrupt, count 27584
> ><...>-54504 [086] d.h. 15340.745172: e1000_msix_other: got Other 
> > interrupt, count 1
> ><...>-54504 [086] d.h. 15340.745222: e1000_msix_other: got Other 
> > interrupt, count 1
> ><...>-54504 [086] d.h. 15340.745272: e1000_msix_other: got Other 
> > interrupt, count 1
> > 
> > > hence sets the flag that (unfortunately) means both link is down and link
> > > state should be checked.  Since this now happens 3000 times per second,
> > > the chances of it happening while the watchdog_task is checking the link
> > > state becomes pretty high, and it if does happen to coincice, then the
> > > watchdog_task will reset the adapter, which causes a real loss of link.
> > 
> > Through which path does watchdog_task reset the adapter? I didn't
> > reproduce that.
> 
> The other interrupt happens and sets get_link_status to true.  At some
> point the watchdog_task runs on some core and calls e1000e_has_link,
> which then calls check_for_link to find out the current link status.
> While e1000e_check_for_copper_link is checking the link state and
> after updating get_link_status to false to indicate link is up, another
> interrupt occurs and another core handles it and changes get_link_status
> to true again.  So by the time e1000e_has_link goes to determine the
> return value, get_link_state has changed back again so now it returns
> link down, and as a result the watchdog_task calls reset, because we
> have packets in the transmit queue (we were busy forwarding over 10
> packets per second when it happened).

Ah I see. Thanks again.

In your previous mail,
On 2017/07/18 10:21, Lennart Sorensen wrote:
[...]
> I tried checking what the bits in the ICR actually were under these
> conditions, and it would appear that the only bit set is 24 (the Other
> Causes interrupt bit).  So I don't know what the real cause is although

Are you sure about this? In my testing, while triggering the overrun
with the msleep, I read ICR when entering e1000_msix_other() and RXO is
consistently set.

I'm working on a patch that uses that fact to handle the situation and
limit the interrupt.

Re: [PATCH] scsi: mpt3sas_scsih: remove unnecessary statics

[James Bottomley]

On Wed, 2017-07-19 at 17:06 -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variables raid_device.
> Such variables are initialized before being used, on
> every execution path throughout the functions. The
> static has no benefit and, removing it reduces the
> object file size.
> 
> This issue was detected using Coccinelle and the following semantic
> patch:
> 
> @bad exists@
> position p;
> identifier x;
> type T;
> @@
> 
> static T x@p;
> ...
> x = <+...x...+>
> 
> @@
> identifier x;
> expression e;
> type T;
> position p != bad.p;
> @@
> 
> -static
>  T x@p;
>  ... when != x
>  when strict
> ?x = e;
> 
> In the following log you can see a significant difference in the
> object file size. This log is the output of the size command, before
> and after the code change:
> 
> before:
>    textdata bss dec hex filename
>  126304   303841280  157968   26910
> drivers/scsi/mpt3sas/mpt3sas_scsih.o
> 
> after:
>    textdata bss dec hex filename
>  126292   302401152  157684   267f4
> drivers/scsi/mpt3sas/mpt3sas_scsih.o

I've got to say I'm deeply uneasy about using a data/bss size reduction
as the benchmark for saying something shouldn't be declared static.  In
this particular case the reduction is minimal, so it probably doesn't
matter; however, if the reduction were more significant, changing from
static to dynamic (i.e. on stack) allocation would increase the risk
that we'd blow the kernel stack.  Indeed one reason you might find
static declarations in functions is precisely to avoid blowing the
stack, so we wouldn't want to reverse them.

Other reasons for having static allocations instead of dynamic ones is
that you need to DMA to/from the structure (you can't DMA to stack) or
because you want to preserve values across function invocations.

There are definite reasons why statics in functions are a bad idea:
they prevent recursion and trip up code analysis, but in none of the
above cases would the fix be to remove the static qualifier.

James

Re: [PATCH] scsi: mpt3sas_scsih: remove unnecessary statics

[James Bottomley]

On Wed, 2017-07-19 at 17:06 -0500, Gustavo A. R. Silva wrote:
> Remove unnecessary static on local variables raid_device.
> Such variables are initialized before being used, on
> every execution path throughout the functions. The
> static has no benefit and, removing it reduces the
> object file size.
> 
> This issue was detected using Coccinelle and the following semantic
> patch:
> 
> @bad exists@
> position p;
> identifier x;
> type T;
> @@
> 
> static T x@p;
> ...
> x = <+...x...+>
> 
> @@
> identifier x;
> expression e;
> type T;
> position p != bad.p;
> @@
> 
> -static
>  T x@p;
>  ... when != x
>  when strict
> ?x = e;
> 
> In the following log you can see a significant difference in the
> object file size. This log is the output of the size command, before
> and after the code change:
> 
> before:
>    textdata bss dec hex filename
>  126304   303841280  157968   26910
> drivers/scsi/mpt3sas/mpt3sas_scsih.o
> 
> after:
>    textdata bss dec hex filename
>  126292   302401152  157684   267f4
> drivers/scsi/mpt3sas/mpt3sas_scsih.o

I've got to say I'm deeply uneasy about using a data/bss size reduction
as the benchmark for saying something shouldn't be declared static.  In
this particular case the reduction is minimal, so it probably doesn't
matter; however, if the reduction were more significant, changing from
static to dynamic (i.e. on stack) allocation would increase the risk
that we'd blow the kernel stack.  Indeed one reason you might find
static declarations in functions is precisely to avoid blowing the
stack, so we wouldn't want to reverse them.

Other reasons for having static allocations instead of dynamic ones is
that you need to DMA to/from the structure (you can't DMA to stack) or
because you want to preserve values across function invocations.

There are definite reasons why statics in functions are a bad idea:
they prevent recursion and trip up code analysis, but in none of the
above cases would the fix be to remove the static qualifier.

James

Re: linux-next: Tree for Jul 19 (drivers/sfi)

[Randy Dunlap]

On 07/18/2017 09:54 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20170718:
> 

on i386:

../drivers/sfi/sfi_core.c: In function 'sfi_map_memory':
../drivers/sfi/sfi_core.c:104:3: error: implicit declaration of function 
'memremap' [-Werror=implicit-function-declaration]
   return memremap(phys, size, MEMREMAP_WB);
   ^
../drivers/sfi/sfi_core.c:104:31: error: 'MEMREMAP_WB' undeclared (first use in 
this function)
   return memremap(phys, size, MEMREMAP_WB);
   ^
../drivers/sfi/sfi_core.c:104:31: note: each undeclared identifier is reported 
only once for each function it appears in
../drivers/sfi/sfi_core.c: In function 'sfi_unmap_memory':
../drivers/sfi/sfi_core.c:115:3: error: implicit declaration of function 
'memunmap' [-Werror=implicit-function-declaration]
   memunmap(virt);
   ^
../drivers/sfi/sfi_core.c: In function 'sfi_map_memory':
../drivers/sfi/sfi_core.c:107:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^



-- 
~Randy

Re: linux-next: Tree for Jul 19 (drivers/sfi)

[Randy Dunlap]

On 07/18/2017 09:54 PM, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20170718:
> 

on i386:

../drivers/sfi/sfi_core.c: In function 'sfi_map_memory':
../drivers/sfi/sfi_core.c:104:3: error: implicit declaration of function 
'memremap' [-Werror=implicit-function-declaration]
   return memremap(phys, size, MEMREMAP_WB);
   ^
../drivers/sfi/sfi_core.c:104:31: error: 'MEMREMAP_WB' undeclared (first use in 
this function)
   return memremap(phys, size, MEMREMAP_WB);
   ^
../drivers/sfi/sfi_core.c:104:31: note: each undeclared identifier is reported 
only once for each function it appears in
../drivers/sfi/sfi_core.c: In function 'sfi_unmap_memory':
../drivers/sfi/sfi_core.c:115:3: error: implicit declaration of function 
'memunmap' [-Werror=implicit-function-declaration]
   memunmap(virt);
   ^
../drivers/sfi/sfi_core.c: In function 'sfi_map_memory':
../drivers/sfi/sfi_core.c:107:1: warning: control reaches end of non-void 
function [-Wreturn-type]
 }
 ^



-- 
~Randy

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

[Paul Moore]

On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook  wrote:
> The SELinux bprm_secureexec hook can be merged with the bprm_set_creds
> hook since it's dealing with the same information, and all of the details
> are finalized during the first call to the bprm_set_creds hook via
> prepare_binprm() (subsequent calls due to binfmt_script, etc, are ignored
> via bprm->called_set_creds).
>
> Here, the test can just happen at the end of the bprm_set_creds hook,
> and the bprm_secureexec hook can be dropped.
>
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Signed-off-by: Kees Cook 
> ---
>  security/selinux/hooks.c | 24 +---
>  1 file changed, 5 insertions(+), 19 deletions(-)

This seems reasonable in the context of the other changes.

Stephen just posted an AT_SECURE test for the selinux-testsuite on the
SELinux mailing list, it would be nice to ensure that this patchset
doesn't run afoul of that.

Acked-by: Paul Moore 

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 0f1450a06b02..18038f73a2f7 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2413,30 +2413,17 @@ static int selinux_bprm_set_creds(struct linux_binprm 
> *bprm)
>
> /* Clear any possibly unsafe personality bits on exec: */
> bprm->per_clear |= PER_CLEAR_ON_SETID;
> -   }
> -
> -   return 0;
> -}
> -
> -static int selinux_bprm_secureexec(struct linux_binprm *bprm)
> -{
> -   const struct task_security_struct *tsec = current_security();
> -   u32 sid, osid;
> -   int atsecure = 0;
> -
> -   sid = tsec->sid;
> -   osid = tsec->osid;
>
> -   if (osid != sid) {
> /* Enable secure mode for SIDs transitions unless
>the noatsecure permission is granted between
>the two SIDs, i.e. ahp returns 0. */
> -   atsecure = avc_has_perm(osid, sid,
> -   SECCLASS_PROCESS,
> -   PROCESS__NOATSECURE, NULL);
> +   rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> + SECCLASS_PROCESS, PROCESS__NOATSECURE,
> + NULL);
> +   bprm->secureexec |= !!rc;
> }
>
> -   return !!atsecure;
> +   return 0;
>  }
>
>  static int match_file(const void *p, struct file *file, unsigned fd)
> @@ -6151,7 +6138,6 @@ static struct security_hook_list selinux_hooks[] 
> __lsm_ro_after_init = {
> LSM_HOOK_INIT(bprm_set_creds, selinux_bprm_set_creds),
> LSM_HOOK_INIT(bprm_committing_creds, selinux_bprm_committing_creds),
> LSM_HOOK_INIT(bprm_committed_creds, selinux_bprm_committed_creds),
> -   LSM_HOOK_INIT(bprm_secureexec, selinux_bprm_secureexec),
>
> LSM_HOOK_INIT(sb_alloc_security, selinux_sb_alloc_security),
> LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security),
> --
> 2.7.4

-- 
paul moore
www.paul-moore.com

Re: [PATCH v3 04/15] selinux: Refactor to remove bprm_secureexec hook

[Paul Moore]

On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook  wrote:
> The SELinux bprm_secureexec hook can be merged with the bprm_set_creds
> hook since it's dealing with the same information, and all of the details
> are finalized during the first call to the bprm_set_creds hook via
> prepare_binprm() (subsequent calls due to binfmt_script, etc, are ignored
> via bprm->called_set_creds).
>
> Here, the test can just happen at the end of the bprm_set_creds hook,
> and the bprm_secureexec hook can be dropped.
>
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Signed-off-by: Kees Cook 
> ---
>  security/selinux/hooks.c | 24 +---
>  1 file changed, 5 insertions(+), 19 deletions(-)

This seems reasonable in the context of the other changes.

Stephen just posted an AT_SECURE test for the selinux-testsuite on the
SELinux mailing list, it would be nice to ensure that this patchset
doesn't run afoul of that.

Acked-by: Paul Moore 

> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 0f1450a06b02..18038f73a2f7 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -2413,30 +2413,17 @@ static int selinux_bprm_set_creds(struct linux_binprm 
> *bprm)
>
> /* Clear any possibly unsafe personality bits on exec: */
> bprm->per_clear |= PER_CLEAR_ON_SETID;
> -   }
> -
> -   return 0;
> -}
> -
> -static int selinux_bprm_secureexec(struct linux_binprm *bprm)
> -{
> -   const struct task_security_struct *tsec = current_security();
> -   u32 sid, osid;
> -   int atsecure = 0;
> -
> -   sid = tsec->sid;
> -   osid = tsec->osid;
>
> -   if (osid != sid) {
> /* Enable secure mode for SIDs transitions unless
>the noatsecure permission is granted between
>the two SIDs, i.e. ahp returns 0. */
> -   atsecure = avc_has_perm(osid, sid,
> -   SECCLASS_PROCESS,
> -   PROCESS__NOATSECURE, NULL);
> +   rc = avc_has_perm(old_tsec->sid, new_tsec->sid,
> + SECCLASS_PROCESS, PROCESS__NOATSECURE,
> + NULL);
> +   bprm->secureexec |= !!rc;
> }
>
> -   return !!atsecure;
> +   return 0;
>  }
>
>  static int match_file(const void *p, struct file *file, unsigned fd)
> @@ -6151,7 +6138,6 @@ static struct security_hook_list selinux_hooks[] 
> __lsm_ro_after_init = {
> LSM_HOOK_INIT(bprm_set_creds, selinux_bprm_set_creds),
> LSM_HOOK_INIT(bprm_committing_creds, selinux_bprm_committing_creds),
> LSM_HOOK_INIT(bprm_committed_creds, selinux_bprm_committed_creds),
> -   LSM_HOOK_INIT(bprm_secureexec, selinux_bprm_secureexec),
>
> LSM_HOOK_INIT(sb_alloc_security, selinux_sb_alloc_security),
> LSM_HOOK_INIT(sb_free_security, selinux_sb_free_security),
> --
> 2.7.4

-- 
paul moore
www.paul-moore.com

Re: [PATCH] ARM: dts: bcm283x: Move the BCM2837 DT contents from arm64 to arm.

[Scott Branden]

Hi Eric,

suggestion inline


On 17-07-19 01:19 PM, Eric Anholt wrote:

BCM2837 is somewhat unusual in that we build its DT on both arm32 and
arm64.  Most devices are being run in arm32 mode.

Having the body of the DT for 2837 separate from 2835/6 has been a
source of pain, as we often need to make changes that span both
directories simultaneously (for example, the thermal changes for 4.13,
and pinmuxing changes earlier).  Other changes are made more
complicated than they need to be, such as the SDHOST enabling, because
we end up splitting a single change into a 283[56] half and a 2837
half.

Signed-off-by: Eric Anholt 
---

I had asked about what we could do about our DT merging troubles back
in https://lkml.org/lkml/2017/5/16/707 with no response.  I'm hoping
we can take this patch as a resolution to that, and submit (almost
all) future RPi DT changes through the arm32 dt tree.


  arch/arm/boot/dts/bcm2837-rpi-3-b.dts  | 42 +-
  .../dts/broadcom => arm/boot/dts}/bcm2837.dtsi |  0
  arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   | 42 +-
  3 files changed, 42 insertions(+), 42 deletions(-)
  rename arch/{arm64/boot/dts/broadcom => arm/boot/dts}/bcm2837.dtsi (100%)

diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts 
b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index c72a27d908b6..972f14db28ac 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -1 +1,41 @@
-#include "arm64/broadcom/bcm2837-rpi-3-b.dts"
+/dts-v1/;
+#include "bcm2837.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
+#include "bcm283x-rpi-usb-host.dtsi"
If you're moving this back to the arm directory why not change the 
include path and remove the 4 symlinks in arm64/boot/dts/broadcom?


+#include "arm/bcm2837.dtsi"
+#include "arm/bcm2835-rpi.dtsi"
+#include "arm/bcm283x-rpi-smsc9514.dtsi"
+#include "arm/bcm283x-rpi-usb-host.dtsi"



+
+/ {
+   compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
+   model = "Raspberry Pi 3 Model B";
+
+   memory {
+   reg = <0 0x4000>;
+   };
+
+   leds {
+   act {
+   gpios = < 47 0>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+/* SDHCI is used to control the SDIO for wireless */
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio34>;
+   status = "okay";
+   bus-width = <4>;
+   non-removable;
+};
+
+/* SDHOST is used to drive the SD card */
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio48>;
+   status = "okay";
+   bus-width = <4>;
+};
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm/boot/dts/bcm2837.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/broadcom/bcm2837.dtsi
rename to arch/arm/boot/dts/bcm2837.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 972f14db28ac..699d340a3437 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,41 +1 @@
-/dts-v1/;
-#include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
-#include "bcm283x-rpi-smsc9514.dtsi"
-#include "bcm283x-rpi-usb-host.dtsi"
-
-/ {
-   compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
-   model = "Raspberry Pi 3 Model B";
-
-   memory {
-   reg = <0 0x4000>;
-   };
-
-   leds {
-   act {
-   gpios = < 47 0>;
-   };
-   };
-};
-
- {
-   status = "okay";
-};
-
-/* SDHCI is used to control the SDIO for wireless */
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_gpio34>;
-   status = "okay";
-   bus-width = <4>;
-   non-removable;
-};
-
-/* SDHOST is used to drive the SD card */
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_gpio48>;
-   status = "okay";
-   bus-width = <4>;
-};
+#include "arm/bcm2837-rpi-3-b.dts"

Re: [PATCH] ARM: dts: bcm283x: Move the BCM2837 DT contents from arm64 to arm.

[Scott Branden]

Hi Eric,

suggestion inline


On 17-07-19 01:19 PM, Eric Anholt wrote:

BCM2837 is somewhat unusual in that we build its DT on both arm32 and
arm64.  Most devices are being run in arm32 mode.

Having the body of the DT for 2837 separate from 2835/6 has been a
source of pain, as we often need to make changes that span both
directories simultaneously (for example, the thermal changes for 4.13,
and pinmuxing changes earlier).  Other changes are made more
complicated than they need to be, such as the SDHOST enabling, because
we end up splitting a single change into a 283[56] half and a 2837
half.

Signed-off-by: Eric Anholt 
---

I had asked about what we could do about our DT merging troubles back
in https://lkml.org/lkml/2017/5/16/707 with no response.  I'm hoping
we can take this patch as a resolution to that, and submit (almost
all) future RPi DT changes through the arm32 dt tree.


  arch/arm/boot/dts/bcm2837-rpi-3-b.dts  | 42 +-
  .../dts/broadcom => arm/boot/dts}/bcm2837.dtsi |  0
  arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts   | 42 +-
  3 files changed, 42 insertions(+), 42 deletions(-)
  rename arch/{arm64/boot/dts/broadcom => arm/boot/dts}/bcm2837.dtsi (100%)

diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts 
b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
index c72a27d908b6..972f14db28ac 100644
--- a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
+++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts
@@ -1 +1,41 @@
-#include "arm64/broadcom/bcm2837-rpi-3-b.dts"
+/dts-v1/;
+#include "bcm2837.dtsi"
+#include "bcm2835-rpi.dtsi"
+#include "bcm283x-rpi-smsc9514.dtsi"
+#include "bcm283x-rpi-usb-host.dtsi"
If you're moving this back to the arm directory why not change the 
include path and remove the 4 symlinks in arm64/boot/dts/broadcom?


+#include "arm/bcm2837.dtsi"
+#include "arm/bcm2835-rpi.dtsi"
+#include "arm/bcm283x-rpi-smsc9514.dtsi"
+#include "arm/bcm283x-rpi-usb-host.dtsi"



+
+/ {
+   compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
+   model = "Raspberry Pi 3 Model B";
+
+   memory {
+   reg = <0 0x4000>;
+   };
+
+   leds {
+   act {
+   gpios = < 47 0>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+/* SDHCI is used to control the SDIO for wireless */
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio34>;
+   status = "okay";
+   bus-width = <4>;
+   non-removable;
+};
+
+/* SDHOST is used to drive the SD card */
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio48>;
+   status = "okay";
+   bus-width = <4>;
+};
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837.dtsi 
b/arch/arm/boot/dts/bcm2837.dtsi
similarity index 100%
rename from arch/arm64/boot/dts/broadcom/bcm2837.dtsi
rename to arch/arm/boot/dts/bcm2837.dtsi
diff --git a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts 
b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
index 972f14db28ac..699d340a3437 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
+++ b/arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
@@ -1,41 +1 @@
-/dts-v1/;
-#include "bcm2837.dtsi"
-#include "bcm2835-rpi.dtsi"
-#include "bcm283x-rpi-smsc9514.dtsi"
-#include "bcm283x-rpi-usb-host.dtsi"
-
-/ {
-   compatible = "raspberrypi,3-model-b", "brcm,bcm2837";
-   model = "Raspberry Pi 3 Model B";
-
-   memory {
-   reg = <0 0x4000>;
-   };
-
-   leds {
-   act {
-   gpios = < 47 0>;
-   };
-   };
-};
-
- {
-   status = "okay";
-};
-
-/* SDHCI is used to control the SDIO for wireless */
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_gpio34>;
-   status = "okay";
-   bus-width = <4>;
-   non-removable;
-};
-
-/* SDHOST is used to drive the SD card */
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_gpio48>;
-   status = "okay";
-   bus-width = <4>;
-};
+#include "arm/bcm2837-rpi-3-b.dts"

[PATCH -next] staging: pi433: depends on SPI

[Randy Dunlap]

From: Randy Dunlap 

The pi433 driver uses SPI interfaces so it should depend on SPI.
Also, the "default n" can be removed since that is already the
default.

Fixes these build errors when SPI is not enabled:

drivers/staging/pi433/pi433_if.o: In function `pi433_probe':
pi433_if.c:(.text+0x1135): undefined reference to `spi_setup'
pi433_if.c:(.text+0x1177): undefined reference to `spi_write_then_read'
drivers/staging/pi433/pi433_if.o: In function `pi433_init':
pi433_if.c:(.init.text+0xb8): undefined reference to `__spi_register_driver'
drivers/staging/pi433/rf69.o: In function `rf69_read_fifo':
rf69.c:(.text+0x102): undefined reference to `spi_sync'
drivers/staging/pi433/rf69.o: In function `rf69_write_fifo':
rf69.c:(.text+0x248): undefined reference to `spi_sync'
drivers/staging/pi433/rf69.o: In function `rf69_read_reg':
rf69.c:(.text+0x290): undefined reference to `spi_write_then_read'
drivers/staging/pi433/rf69.o: In function `rf69_write_reg':
rf69.c:(.text+0x523): undefined reference to `spi_sync'

Signed-off-by: Randy Dunlap 
Cc: Marcus Wolf 
---
 drivers/staging/pi433/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- next-2017-0719.orig/drivers/staging/pi433/Kconfig
+++ next-2017-0719/drivers/staging/pi433/Kconfig
@@ -1,6 +1,6 @@
 config PI433
 tristate "Pi433 - a 433MHz radio module for Raspberry Pi"
-default n
+depends on SPI
 ---help---
   This option allows you to enable support for the radio module Pi433.
 

[PATCH -next] staging: pi433: depends on SPI

[Randy Dunlap]

From: Randy Dunlap 

The pi433 driver uses SPI interfaces so it should depend on SPI.
Also, the "default n" can be removed since that is already the
default.

Fixes these build errors when SPI is not enabled:

drivers/staging/pi433/pi433_if.o: In function `pi433_probe':
pi433_if.c:(.text+0x1135): undefined reference to `spi_setup'
pi433_if.c:(.text+0x1177): undefined reference to `spi_write_then_read'
drivers/staging/pi433/pi433_if.o: In function `pi433_init':
pi433_if.c:(.init.text+0xb8): undefined reference to `__spi_register_driver'
drivers/staging/pi433/rf69.o: In function `rf69_read_fifo':
rf69.c:(.text+0x102): undefined reference to `spi_sync'
drivers/staging/pi433/rf69.o: In function `rf69_write_fifo':
rf69.c:(.text+0x248): undefined reference to `spi_sync'
drivers/staging/pi433/rf69.o: In function `rf69_read_reg':
rf69.c:(.text+0x290): undefined reference to `spi_write_then_read'
drivers/staging/pi433/rf69.o: In function `rf69_write_reg':
rf69.c:(.text+0x523): undefined reference to `spi_sync'

Signed-off-by: Randy Dunlap 
Cc: Marcus Wolf 
---
 drivers/staging/pi433/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- next-2017-0719.orig/drivers/staging/pi433/Kconfig
+++ next-2017-0719/drivers/staging/pi433/Kconfig
@@ -1,6 +1,6 @@
 config PI433
 tristate "Pi433 - a 433MHz radio module for Raspberry Pi"
-default n
+depends on SPI
 ---help---
   This option allows you to enable support for the radio module Pi433.
 

Re: [PATCH v3 02/15] exec: Rename bprm->cred_prepared to called_set_creds

[Paul Moore]

On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook  wrote:
> The cred_prepared bprm flag has a misleading name. It has nothing to do
> with the bprm_prepare_cred hook, and actually tracks if bprm_set_creds has
> been called. Rename this flag and improve its comment.
>
> Cc: David Howells 
> Cc: John Johansen 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Casey Schaufler 
> Cc: James Morris 
> Signed-off-by: Kees Cook 
> ---
>  fs/binfmt_flat.c   | 2 +-
>  fs/exec.c  | 2 +-
>  include/linux/binfmts.h| 8 ++--
>  security/apparmor/domain.c | 2 +-
>  security/selinux/hooks.c   | 2 +-
>  security/smack/smack_lsm.c | 2 +-
>  security/tomoyo/tomoyo.c   | 2 +-
>  7 files changed, 12 insertions(+), 8 deletions(-)

Acked-by: Paul Moore 

-- 
paul moore
www.paul-moore.com

Re: [PATCH v3 02/15] exec: Rename bprm->cred_prepared to called_set_creds

[Paul Moore]

On Tue, Jul 18, 2017 at 6:25 PM, Kees Cook  wrote:
> The cred_prepared bprm flag has a misleading name. It has nothing to do
> with the bprm_prepare_cred hook, and actually tracks if bprm_set_creds has
> been called. Rename this flag and improve its comment.
>
> Cc: David Howells 
> Cc: John Johansen 
> Cc: Paul Moore 
> Cc: Stephen Smalley 
> Cc: Casey Schaufler 
> Cc: James Morris 
> Signed-off-by: Kees Cook 
> ---
>  fs/binfmt_flat.c   | 2 +-
>  fs/exec.c  | 2 +-
>  include/linux/binfmts.h| 8 ++--
>  security/apparmor/domain.c | 2 +-
>  security/selinux/hooks.c   | 2 +-
>  security/smack/smack_lsm.c | 2 +-
>  security/tomoyo/tomoyo.c   | 2 +-
>  7 files changed, 12 insertions(+), 8 deletions(-)

Acked-by: Paul Moore 

-- 
paul moore
www.paul-moore.com

Re: [PATCH 3.18 00/28] 3.18.62-stable review

[Shuah Khan]

On 07/19/2017 05:15 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.62 release.
> There are 28 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 11:13:09 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.62-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 3.18 00/28] 3.18.62-stable review

[Shuah Khan]

On 07/19/2017 05:15 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.62 release.
> There are 28 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 11:13:09 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.62-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-3.18.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/57] 4.4.78-stable review

[Shuah Khan]

On 07/19/2017 05:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.78 release.
> There are 57 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 11:12:31 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.78-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.4 00/57] 4.4.78-stable review

[Shuah Khan]

On 07/19/2017 05:12 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.78 release.
> There are 57 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 11:12:31 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.78-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

[Wanpeng Li]

From: Wanpeng Li 

This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y 
or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it tries 
to emulate invalid guest state task-switch:

kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
kvm_emulate_insn: 42000:0:0f 0b (0x2)
kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
kvm_inj_exception: #UD (0x0)
kvm_entry: vcpu 0
kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
kvm_emulate_insn: 42000:0:0f 0b (0x2)
kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
kvm_inj_exception: #UD (0x0)
..

It appears that the task-switch emulation updates rflags (and vm86 
flag) only after the segments are loaded, causing vmx->emulation_required 
to be set, when in fact invalid guest state emulation is not needed.

This patch fixes it by updating vmx->emulation_required after the 
rflags (and vm86 flag) is updated in task-switch emulation.

Thanks Radim for moving the update to vmx__set_flags and adding Paolo's 
suggestion for the check.

Suggested-by: Nadav Amit 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Nadav Amit 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 84e62ac..287639e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2326,6 +2326,11 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
__vmx_load_host_state(to_vmx(vcpu));
 }
 
+static bool emulation_required(struct kvm_vcpu *vcpu)
+{
+   return emulate_invalid_guest_state && !guest_state_valid(vcpu);
+}
+
 static void vmx_decache_cr0_guest_bits(struct kvm_vcpu *vcpu);
 
 /*
@@ -2363,6 +2368,9 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu *vcpu)
 
 static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
 {
+   unsigned long old_rflags = vmx_get_rflags(vcpu);
+   unsigned long save_rflags = rflags;
+
__set_bit(VCPU_EXREG_RFLAGS, (ulong *)>arch.regs_avail);
to_vmx(vcpu)->rflags = rflags;
if (to_vmx(vcpu)->rmode.vm86_active) {
@@ -2370,6 +2378,9 @@ static void vmx_set_rflags(struct kvm_vcpu *vcpu, 
unsigned long rflags)
rflags |= X86_EFLAGS_IOPL | X86_EFLAGS_VM;
}
vmcs_writel(GUEST_RFLAGS, rflags);
+
+   if ((old_rflags ^ save_rflags) & X86_EFLAGS_VM)
+   to_vmx(vcpu)->emulation_required = emulation_required(vcpu);
 }
 
 static u32 vmx_get_pkru(struct kvm_vcpu *vcpu)
@@ -3857,11 +3868,6 @@ static __init int alloc_kvm_area(void)
return 0;
 }
 
-static bool emulation_required(struct kvm_vcpu *vcpu)
-{
-   return emulate_invalid_guest_state && !guest_state_valid(vcpu);
-}
-
 static void fix_pmode_seg(struct kvm_vcpu *vcpu, int seg,
struct kvm_segment *save)
 {
-- 
2.7.4

[PATCH v2] KVM: VMX: Fix invalid guest state detection after task-switch emulation

[Wanpeng Li]

From: Wanpeng Li 

This can be reproduced by EPT=1, unrestricted_guest=N, emulate_invalid_state=Y 
or EPT=0, the trace of kvm-unit-tests/taskswitch2.flat is like below, it tries 
to emulate invalid guest state task-switch:

kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
kvm_emulate_insn: 42000:0:0f 0b (0x2)
kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
kvm_inj_exception: #UD (0x0)
kvm_entry: vcpu 0
kvm_exit: reason TASK_SWITCH rip 0x0 info 4058 0
kvm_emulate_insn: 42000:0:0f 0b (0x2)
kvm_emulate_insn: 42000:0:0f 0b (0x2) failed
kvm_inj_exception: #UD (0x0)
..

It appears that the task-switch emulation updates rflags (and vm86 
flag) only after the segments are loaded, causing vmx->emulation_required 
to be set, when in fact invalid guest state emulation is not needed.

This patch fixes it by updating vmx->emulation_required after the 
rflags (and vm86 flag) is updated in task-switch emulation.

Thanks Radim for moving the update to vmx__set_flags and adding Paolo's 
suggestion for the check.

Suggested-by: Nadav Amit 
Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Nadav Amit 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kvm/vmx.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 84e62ac..287639e 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2326,6 +2326,11 @@ static void vmx_vcpu_put(struct kvm_vcpu *vcpu)
__vmx_load_host_state(to_vmx(vcpu));
 }
 
+static bool emulation_required(struct kvm_vcpu *vcpu)
+{
+   return emulate_invalid_guest_state && !guest_state_valid(vcpu);
+}
+
 static void vmx_decache_cr0_guest_bits(struct kvm_vcpu *vcpu);
 
 /*
@@ -2363,6 +2368,9 @@ static unsigned long vmx_get_rflags(struct kvm_vcpu *vcpu)
 
 static void vmx_set_rflags(struct kvm_vcpu *vcpu, unsigned long rflags)
 {
+   unsigned long old_rflags = vmx_get_rflags(vcpu);
+   unsigned long save_rflags = rflags;
+
__set_bit(VCPU_EXREG_RFLAGS, (ulong *)>arch.regs_avail);
to_vmx(vcpu)->rflags = rflags;
if (to_vmx(vcpu)->rmode.vm86_active) {
@@ -2370,6 +2378,9 @@ static void vmx_set_rflags(struct kvm_vcpu *vcpu, 
unsigned long rflags)
rflags |= X86_EFLAGS_IOPL | X86_EFLAGS_VM;
}
vmcs_writel(GUEST_RFLAGS, rflags);
+
+   if ((old_rflags ^ save_rflags) & X86_EFLAGS_VM)
+   to_vmx(vcpu)->emulation_required = emulation_required(vcpu);
 }
 
 static u32 vmx_get_pkru(struct kvm_vcpu *vcpu)
@@ -3857,11 +3868,6 @@ static __init int alloc_kvm_area(void)
return 0;
 }
 
-static bool emulation_required(struct kvm_vcpu *vcpu)
-{
-   return emulate_invalid_guest_state && !guest_state_valid(vcpu);
-}
-
 static void fix_pmode_seg(struct kvm_vcpu *vcpu, int seg,
struct kvm_segment *save)
 {
-- 
2.7.4

[PATCH 1/4] can: dev: Add support for limiting configured bitrate

[Franklin S Cooper Jr]

Various CAN or CAN-FD IP may be able to run at a faster rate than
what the transceiver the CAN node is connected to. This can lead to
unexpected errors. However, CAN transceivers typically have fixed
limitations and provide no means to discover these limitations at
runtime. Therefore, add support for a fixed-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/net/can/dev.c   | 48 
 include/linux/can/dev.h |  5 +
 2 files changed, 53 insertions(+)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 365a8cc..fbab87d 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MOD_DESC "CAN device driver interface"
@@ -806,6 +807,21 @@ int open_candev(struct net_device *dev)
return -EINVAL;
}
 
+   if (priv->max_trans_arbitration_speed > 0 &&
+   priv->bittiming.bitrate > priv->max_trans_arbitration_speed) {
+   netdev_err(dev, "arbitration bitrate surpasses transceiver 
capabilities of %d bps\n",
+  priv->max_trans_arbitration_speed);
+   return -EINVAL;
+   }
+
+   if (priv->max_trans_data_speed  >= 0 &&
+   (priv->ctrlmode & CAN_CTRLMODE_FD) &&
+   (priv->data_bittiming.bitrate > priv->max_trans_data_speed)) {
+   netdev_err(dev, "canfd data bitrate surpasses transceiver 
capabilities of %d bps\n",
+  priv->max_trans_data_speed);
+   return -EINVAL;
+   }
+
/* Switch carrier on if device was stopped while in bus-off state */
if (!netif_carrier_ok(dev))
netif_carrier_on(dev);
@@ -814,6 +830,38 @@ int open_candev(struct net_device *dev)
 }
 EXPORT_SYMBOL_GPL(open_candev);
 
+#ifdef CONFIG_OF
+void of_transceiver_is_fixed(struct net_device *dev)
+{
+   struct device_node *dn;
+   struct can_priv *priv = netdev_priv(dev);
+   u32 max_frequency;
+   struct device_node *np;
+
+   np = dev->dev.parent->of_node;
+
+   /* New binding */
+   dn = of_get_child_by_name(np, "fixed-transceiver");
+   if (!dn)
+   return;
+
+   of_property_read_u32(dn, "max-arbitration-speed", _frequency);
+
+   if (max_frequency > 0)
+   priv->max_trans_arbitration_speed = max_frequency;
+   else
+   priv->max_trans_arbitration_speed = -1;
+
+   of_property_read_u32(dn, "max-data-speed", _frequency);
+
+   if (max_frequency >= 0)
+   priv->max_trans_data_speed = max_frequency;
+   else
+   priv->max_trans_data_speed = -1;
+}
+EXPORT_SYMBOL(of_transceiver_is_fixed);
+#endif
+
 /*
  * Common close function for cleanup before the device gets closed.
  *
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 141b05a..aec72b5 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -69,6 +69,9 @@ struct can_priv {
unsigned int echo_skb_max;
struct sk_buff **echo_skb;
 
+   unsigned int max_trans_arbitration_speed;
+   unsigned int max_trans_data_speed;
+
 #ifdef CONFIG_CAN_LEDS
struct led_trigger *tx_led_trig;
char tx_led_trig_name[CAN_LED_NAME_SZ];
@@ -165,6 +168,8 @@ void can_put_echo_skb(struct sk_buff *skb, struct 
net_device *dev,
 unsigned int can_get_echo_skb(struct net_device *dev, unsigned int idx);
 void can_free_echo_skb(struct net_device *dev, unsigned int idx);
 
+void of_transceiver_is_fixed(struct net_device *dev);
+
 struct sk_buff *alloc_can_skb(struct net_device *dev, struct can_frame **cf);
 struct sk_buff *alloc_canfd_skb(struct net_device *dev,
struct canfd_frame **cfd);
-- 
2.10.0

[PATCH 1/4] can: dev: Add support for limiting configured bitrate

[Franklin S Cooper Jr]

Various CAN or CAN-FD IP may be able to run at a faster rate than
what the transceiver the CAN node is connected to. This can lead to
unexpected errors. However, CAN transceivers typically have fixed
limitations and provide no means to discover these limitations at
runtime. Therefore, add support for a fixed-transceiver node that
can be reused by other CAN peripheral drivers to determine for both
CAN and CAN-FD what the max bitrate that can be used. If the user
tries to configure CAN to pass these maximum bitrates it will throw
an error.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/net/can/dev.c   | 48 
 include/linux/can/dev.h |  5 +
 2 files changed, 53 insertions(+)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 365a8cc..fbab87d 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MOD_DESC "CAN device driver interface"
@@ -806,6 +807,21 @@ int open_candev(struct net_device *dev)
return -EINVAL;
}
 
+   if (priv->max_trans_arbitration_speed > 0 &&
+   priv->bittiming.bitrate > priv->max_trans_arbitration_speed) {
+   netdev_err(dev, "arbitration bitrate surpasses transceiver 
capabilities of %d bps\n",
+  priv->max_trans_arbitration_speed);
+   return -EINVAL;
+   }
+
+   if (priv->max_trans_data_speed  >= 0 &&
+   (priv->ctrlmode & CAN_CTRLMODE_FD) &&
+   (priv->data_bittiming.bitrate > priv->max_trans_data_speed)) {
+   netdev_err(dev, "canfd data bitrate surpasses transceiver 
capabilities of %d bps\n",
+  priv->max_trans_data_speed);
+   return -EINVAL;
+   }
+
/* Switch carrier on if device was stopped while in bus-off state */
if (!netif_carrier_ok(dev))
netif_carrier_on(dev);
@@ -814,6 +830,38 @@ int open_candev(struct net_device *dev)
 }
 EXPORT_SYMBOL_GPL(open_candev);
 
+#ifdef CONFIG_OF
+void of_transceiver_is_fixed(struct net_device *dev)
+{
+   struct device_node *dn;
+   struct can_priv *priv = netdev_priv(dev);
+   u32 max_frequency;
+   struct device_node *np;
+
+   np = dev->dev.parent->of_node;
+
+   /* New binding */
+   dn = of_get_child_by_name(np, "fixed-transceiver");
+   if (!dn)
+   return;
+
+   of_property_read_u32(dn, "max-arbitration-speed", _frequency);
+
+   if (max_frequency > 0)
+   priv->max_trans_arbitration_speed = max_frequency;
+   else
+   priv->max_trans_arbitration_speed = -1;
+
+   of_property_read_u32(dn, "max-data-speed", _frequency);
+
+   if (max_frequency >= 0)
+   priv->max_trans_data_speed = max_frequency;
+   else
+   priv->max_trans_data_speed = -1;
+}
+EXPORT_SYMBOL(of_transceiver_is_fixed);
+#endif
+
 /*
  * Common close function for cleanup before the device gets closed.
  *
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 141b05a..aec72b5 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -69,6 +69,9 @@ struct can_priv {
unsigned int echo_skb_max;
struct sk_buff **echo_skb;
 
+   unsigned int max_trans_arbitration_speed;
+   unsigned int max_trans_data_speed;
+
 #ifdef CONFIG_CAN_LEDS
struct led_trigger *tx_led_trig;
char tx_led_trig_name[CAN_LED_NAME_SZ];
@@ -165,6 +168,8 @@ void can_put_echo_skb(struct sk_buff *skb, struct 
net_device *dev,
 unsigned int can_get_echo_skb(struct net_device *dev, unsigned int idx);
 void can_free_echo_skb(struct net_device *dev, unsigned int idx);
 
+void of_transceiver_is_fixed(struct net_device *dev);
+
 struct sk_buff *alloc_can_skb(struct net_device *dev, struct can_frame **cf);
 struct sk_buff *alloc_canfd_skb(struct net_device *dev,
struct canfd_frame **cfd);
-- 
2.10.0

[PATCH 4/4] can: m_can: Add call to of_transceiver_is_fixed

[Franklin S Cooper Jr]

Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/net/can/m_can/m_can.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index f4947a7..db1882c 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1649,6 +1649,8 @@ static int m_can_plat_probe(struct platform_device *pdev)
 
devm_can_led_init(dev);
 
+   of_transceiver_is_fixed(dev);
+
dev_info(>dev, "%s device registered (irq=%d, version=%d)\n",
 KBUILD_MODNAME, dev->irq, priv->version);
 
-- 
2.10.0

[PATCH 4/4] can: m_can: Add call to of_transceiver_is_fixed

[Franklin S Cooper Jr]

Add call to new generic functions that provides support via a binding
to limit the arbitration rate and/or data rate imposed by the physical
transceiver connected to the MCAN peripheral.

Signed-off-by: Franklin S Cooper Jr 
---
 drivers/net/can/m_can/m_can.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index f4947a7..db1882c 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1649,6 +1649,8 @@ static int m_can_plat_probe(struct platform_device *pdev)
 
devm_can_led_init(dev);
 
+   of_transceiver_is_fixed(dev);
+
dev_info(>dev, "%s device registered (irq=%d, version=%d)\n",
 KBUILD_MODNAME, dev->irq, priv->version);
 
-- 
2.10.0

Re: [PATCH 4.9 00/72] 4.9.39-stable review

[Shuah Khan]

On 07/19/2017 04:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.39 release.
> There are 72 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 10:23:57 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.39-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.9 00/72] 4.9.39-stable review

[Shuah Khan]

On 07/19/2017 04:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.39 release.
> There are 72 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 10:23:57 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.39-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

Re: [PATCH 4.11 00/88] 4.11.12-stable review

[Shuah Khan]

On 07/19/2017 04:07 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.11.12 release.
> There are 88 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 10:07:36 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.11.12-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.11.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH 0/4] can: Add new binding to limit bit rate used

[Franklin S Cooper Jr]

Add a new generic binding that CAN drivers can use to specify the max
arbitration and data bit rate supported by a transceiver. This is
useful since in some instances the maximum speeds may be limited by
the transceiver used. However, transceivers may not provide a means
to determine this limitation at runtime. Therefore, create a new binding
that mimics "fixed-link" that allows a user to hardcode the max speeds
that can be used.

Also add support for this new binding in the MCAN driver.

Note this is an optional subnode so even if a driver adds support for
parsing fixed-transceiver the user does not have to define it in their
device tree.

Franklin S Cooper Jr (4):
  can: dev: Add support for limiting configured bitrate
  can: fixed-transceiver: Add documentation for CAN fixed transceiver
bindings
  can: m_can: Update documentation to mention new fixed transceiver
binding
  can: m_can: Add call to of_transceiver_is_fixed

 .../bindings/net/can/fixed-transceiver.txt | 31 ++
 .../devicetree/bindings/net/can/m_can.txt  | 10 +
 drivers/net/can/dev.c  | 48 ++
 drivers/net/can/m_can/m_can.c  |  2 +
 include/linux/can/dev.h|  5 +++
 5 files changed, 96 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt

-- 
2.10.0

Re: [PATCH 4.11 00/88] 4.11.12-stable review

[Shuah Khan]

On 07/19/2017 04:07 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.11.12 release.
> There are 88 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 10:07:36 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.11.12-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.11.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH 0/4] can: Add new binding to limit bit rate used

[Franklin S Cooper Jr]

Add a new generic binding that CAN drivers can use to specify the max
arbitration and data bit rate supported by a transceiver. This is
useful since in some instances the maximum speeds may be limited by
the transceiver used. However, transceivers may not provide a means
to determine this limitation at runtime. Therefore, create a new binding
that mimics "fixed-link" that allows a user to hardcode the max speeds
that can be used.

Also add support for this new binding in the MCAN driver.

Note this is an optional subnode so even if a driver adds support for
parsing fixed-transceiver the user does not have to define it in their
device tree.

Franklin S Cooper Jr (4):
  can: dev: Add support for limiting configured bitrate
  can: fixed-transceiver: Add documentation for CAN fixed transceiver
bindings
  can: m_can: Update documentation to mention new fixed transceiver
binding
  can: m_can: Add call to of_transceiver_is_fixed

 .../bindings/net/can/fixed-transceiver.txt | 31 ++
 .../devicetree/bindings/net/can/m_can.txt  | 10 +
 drivers/net/can/dev.c  | 48 ++
 drivers/net/can/m_can/m_can.c  |  2 +
 include/linux/can/dev.h|  5 +++
 5 files changed, 96 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt

-- 
2.10.0

[PATCH 3/4] can: m_can: Update documentation to mention new fixed transceiver binding

[Franklin S Cooper Jr]

Add information regarding fixed transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.

Signed-off-by: Franklin S Cooper Jr 
---
 Documentation/devicetree/bindings/net/can/m_can.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt 
b/Documentation/devicetree/bindings/net/can/m_can.txt
index 9e33177..4440e4b 100644
--- a/Documentation/devicetree/bindings/net/can/m_can.txt
+++ b/Documentation/devicetree/bindings/net/can/m_can.txt
@@ -43,6 +43,11 @@ Required properties:
  Please refer to 2.4.1 Message RAM Configuration in
  Bosch M_CAN user manual for details.
 
+Optional properties:
+- fixed-transceiver: Fixed-transceiver subnode describing maximum speed
+ that can be used for CAN and/or CAN-FD modes.  See
+ 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
+ for details.
 Example:
 SoC dtsi:
 m_can1: can@020e8000 {
@@ -64,4 +69,9 @@ Board dts:
pinctrl-names = "default";
pinctrl-0 = <_m_can1>;
status = "enabled";
+
+   fixed-transceiver@0 {
+   max-arbitration-speed = <100>;
+   max-data-speed = <500>;
+   };
 };
-- 
2.10.0

[PATCH 3/4] can: m_can: Update documentation to mention new fixed transceiver binding

[Franklin S Cooper Jr]

Add information regarding fixed transceiver binding. This is especially
important for MCAN since the IP allows CAN FD mode to run significantly
faster than what most transceivers are capable of.

Signed-off-by: Franklin S Cooper Jr 
---
 Documentation/devicetree/bindings/net/can/m_can.txt | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/can/m_can.txt 
b/Documentation/devicetree/bindings/net/can/m_can.txt
index 9e33177..4440e4b 100644
--- a/Documentation/devicetree/bindings/net/can/m_can.txt
+++ b/Documentation/devicetree/bindings/net/can/m_can.txt
@@ -43,6 +43,11 @@ Required properties:
  Please refer to 2.4.1 Message RAM Configuration in
  Bosch M_CAN user manual for details.
 
+Optional properties:
+- fixed-transceiver: Fixed-transceiver subnode describing maximum speed
+ that can be used for CAN and/or CAN-FD modes.  See
+ 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
+ for details.
 Example:
 SoC dtsi:
 m_can1: can@020e8000 {
@@ -64,4 +69,9 @@ Board dts:
pinctrl-names = "default";
pinctrl-0 = <_m_can1>;
status = "enabled";
+
+   fixed-transceiver@0 {
+   max-arbitration-speed = <100>;
+   max-data-speed = <500>;
+   };
 };
-- 
2.10.0

Re: [PATCH 4.12 00/84] 4.12.3-stable review

[Shuah Khan]

On 07/19/2017 03:43 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.12.3 release.
> There are 84 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 09:22:37 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.12.3-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.12.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

[Franklin S Cooper Jr]

Add documentation to describe usage of the new fixed transceiver binding.
This new binding is applicable for any CAN device therefore it exist as
its own document.

Signed-off-by: Franklin S Cooper Jr 
---
 .../bindings/net/can/fixed-transceiver.txt | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt

diff --git a/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt 
b/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
new file mode 100644
index 000..7c093c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
@@ -0,0 +1,31 @@
+Fixed transceiver Device Tree binding
+--
+
+CAN transceiver typically limits the max speed in standard CAN and CAN FD
+modes. Typically these limitations are static and the transceivers themselves
+provide no way to detect this limitation at runtime. For this situation,
+the "fixed-transceiver" node can be used.
+
+Properties:
+
+Optional:
+ max-arbitration-speed: a positive value non 0 value that determines the max
+speed CAN can run in non CAN-FD mode or during the
+arbitration phase in CAN-FD mode.
+
+ max-data-speed:a positive value that determines the max data rate
+that can be used in CAN-FD mode. A value of 0
+implies CAN-FD is not supported by the transceiver.
+
+Examples:
+
+Based on Texas Instrument's TCAN1042HGV CAN Transceiver
+
+m_can0 {
+   
+   fixed-transceiver@0 {
+   max-arbitration-speed = <100>;
+   max-data-speed = <500>;
+   };
+   ...
+};
-- 
2.10.0

Re: [PATCH 4.12 00/84] 4.12.3-stable review

[Shuah Khan]

On 07/19/2017 03:43 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.12.3 release.
> There are 84 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Fri Jul 21 09:22:37 UTC 2017.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.12.3-rc1.gz
> or in the git tree and branch at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.12.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 

Compiled and booted on my test system. No dmesg regressions.

thanks,
-- Shuah

[PATCH 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

[Franklin S Cooper Jr]

Add documentation to describe usage of the new fixed transceiver binding.
This new binding is applicable for any CAN device therefore it exist as
its own document.

Signed-off-by: Franklin S Cooper Jr 
---
 .../bindings/net/can/fixed-transceiver.txt | 31 ++
 1 file changed, 31 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/can/fixed-transceiver.txt

diff --git a/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt 
b/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
new file mode 100644
index 000..7c093c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/fixed-transceiver.txt
@@ -0,0 +1,31 @@
+Fixed transceiver Device Tree binding
+--
+
+CAN transceiver typically limits the max speed in standard CAN and CAN FD
+modes. Typically these limitations are static and the transceivers themselves
+provide no way to detect this limitation at runtime. For this situation,
+the "fixed-transceiver" node can be used.
+
+Properties:
+
+Optional:
+ max-arbitration-speed: a positive value non 0 value that determines the max
+speed CAN can run in non CAN-FD mode or during the
+arbitration phase in CAN-FD mode.
+
+ max-data-speed:a positive value that determines the max data rate
+that can be used in CAN-FD mode. A value of 0
+implies CAN-FD is not supported by the transceiver.
+
+Examples:
+
+Based on Texas Instrument's TCAN1042HGV CAN Transceiver
+
+m_can0 {
+   
+   fixed-transceiver@0 {
+   max-arbitration-speed = <100>;
+   max-data-speed = <500>;
+   };
+   ...
+};
-- 
2.10.0

Re: [PATCH] rtlwifi: remove useless code

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:41:06 -0500

> Remove useless local variables last_read_point and last_txw_point and
> the code related.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] net: tulip: remove useless code in tulip_init_one()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:43:33 -0500

> Remove useless local variable multiport_cnt and the code related.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] wireless: airo: remove unnecessary static in writerids()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:37:11 -0500

> Remove unnecessary static on local function pointer _writer_.
> Such pointer is initialized before being used, on every
> execution path throughout the function. The static has no
> benefit and, removing it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
 ...
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] liquidio: lio_vf_main: remove unnecessary static in setup_io_queues()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:50:15 -0500

> Remove unnecessary static on local variables cpu_id_modulus and cpu_id.
> Such variables are initialized before being used, on every execution
> path throughout the function. The static has no benefit and, removing
> it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
 ...
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] rtlwifi: remove useless code

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:41:06 -0500

> Remove useless local variables last_read_point and last_txw_point and
> the code related.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] net: tulip: remove useless code in tulip_init_one()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:43:33 -0500

> Remove useless local variable multiport_cnt and the code related.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] wireless: airo: remove unnecessary static in writerids()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:37:11 -0500

> Remove unnecessary static on local function pointer _writer_.
> Such pointer is initialized before being used, on every
> execution path throughout the function. The static has no
> benefit and, removing it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
 ...
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] liquidio: lio_vf_main: remove unnecessary static in setup_io_queues()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:50:15 -0500

> Remove unnecessary static on local variables cpu_id_modulus and cpu_id.
> Such variables are initialized before being used, on every execution
> path throughout the function. The static has no benefit and, removing
> it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
 ...
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] qlcnic: remove unnecessary static in qlcnic_dump_fw()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:45:29 -0500

> Remove unnecessary static on local variable fw_dump_ops.
> Such variable is initialized before being used, on every
> execution path throughout the function. The static has no
> benefit and, removing it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
 ...
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] net: ethernet: mediatek: remove useless code in mtk_poll_tx()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:48:06 -0500

> Remove useless local variable _condition_ and the code related.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] net: ethernet: mediatek: remove useless code in mtk_poll_tx()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:48:06 -0500

> Remove useless local variable _condition_ and the code related.
> 
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] qlcnic: remove unnecessary static in qlcnic_dump_fw()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:45:29 -0500

> Remove unnecessary static on local variable fw_dump_ops.
> Such variable is initialized before being used, on every
> execution path throughout the function. The static has no
> benefit and, removing it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
 ...
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] liquidio: lio_main: remove unnecessary static in setup_io_queues()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:53:48 -0500

> Remove unnecessary static on local variables cpu_id_modulus and cpu_id.
> Such variables are initialized before being used, on every execution
> path throughout the function. The static has no benefit and, removing
> it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
...
> Signed-off-by: Gustavo A. R. Silva 

Applied.

Re: [PATCH] liquidio: lio_main: remove unnecessary static in setup_io_queues()

[David Miller]

From: "Gustavo A. R. Silva" 
Date: Tue, 18 Jul 2017 15:53:48 -0500

> Remove unnecessary static on local variables cpu_id_modulus and cpu_id.
> Such variables are initialized before being used, on every execution
> path throughout the function. The static has no benefit and, removing
> it reduces the object file size.
> 
> This issue was detected using Coccinelle and the following semantic patch:
...
> Signed-off-by: Gustavo A. R. Silva 

Applied.