[no subject]

[Gerardina Viquez Beltrán]

Herzlichen Glückwunsch, Sie haben € 650.000,00 bei den monatlichen 
Gewinnspielen von Euro Millions / Google Promo am  Januar 2018 gewonnen.

Kontaktieren Sie unseren Schadenversicherer E-Mail: eurosilli...@gmail.com

1. Vollständiger Name;
2. Adresse;
3. Sex;
4. Alter;
5. Beruf;
6. Telefon;

[no subject]

[Gerardina Viquez Beltrán]

Herzlichen Glückwunsch, Sie haben € 650.000,00 bei den monatlichen 
Gewinnspielen von Euro Millions / Google Promo am  Januar 2018 gewonnen.

Kontaktieren Sie unseren Schadenversicherer E-Mail: eurosilli...@gmail.com

1. Vollständiger Name;
2. Adresse;
3. Sex;
4. Alter;
5. Beruf;
6. Telefon;

Re: [PATCH 1/3] dt-bindings: pwrap: mediatek: add MT6351 PMIC support for MT6797

[Sean Wang]

On Tue, 2018-01-23 at 11:36 +0800, argus@mediatek.com wrote:
> From: Argus Lin 
> 
> We add MT6351 PMIC support for MT6797 SoCs.
> 
> Change-Id: I362b2305f674813ffb03ce6f54f7fc4c378b8fd2

should remove change-id, also in the other patches

> Signed-off-by: Argus Lin 
> ---
>  Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt 
> b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> index bf80e3f96f8c..dd573ba5d9a7 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> @@ -22,6 +22,7 @@ Required properties in pwrap device node.
>   "mediatek,mt7622-pwrap" for MT7622 SoCs
>   "mediatek,mt8135-pwrap" for MT8135 SoCs
>   "mediatek,mt8173-pwrap" for MT8173 SoCs
> + "mediatek,mt6797-pwrap" for MT6797 SoCs

should be better if add it in alphabetical order

>  - interrupts: IRQ for pwrap in SOC
>  - reg-names: Must include the following entries:
>"pwrap": Main registers base

Re: [PATCH 1/3] dt-bindings: pwrap: mediatek: add MT6351 PMIC support for MT6797

[Sean Wang]

On Tue, 2018-01-23 at 11:36 +0800, argus@mediatek.com wrote:
> From: Argus Lin 
> 
> We add MT6351 PMIC support for MT6797 SoCs.
> 
> Change-Id: I362b2305f674813ffb03ce6f54f7fc4c378b8fd2

should remove change-id, also in the other patches

> Signed-off-by: Argus Lin 
> ---
>  Documentation/devicetree/bindings/soc/mediatek/pwrap.txt | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt 
> b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> index bf80e3f96f8c..dd573ba5d9a7 100644
> --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt
> @@ -22,6 +22,7 @@ Required properties in pwrap device node.
>   "mediatek,mt7622-pwrap" for MT7622 SoCs
>   "mediatek,mt8135-pwrap" for MT8135 SoCs
>   "mediatek,mt8173-pwrap" for MT8173 SoCs
> + "mediatek,mt6797-pwrap" for MT6797 SoCs

should be better if add it in alphabetical order

>  - interrupts: IRQ for pwrap in SOC
>  - reg-names: Must include the following entries:
>"pwrap": Main registers base

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

On 22/01/18 13:00, Lars-Peter Clausen wrote:
> On 01/22/2018 01:50 PM, Kieran Bingham wrote:
>> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
>> ports. Each map has it own I²C address and acts as a standard slave
>> device on the I²C bus.
>>
>> Allow a device tree node to override the default addresses so that
>> address conflicts with other devices on the same bus may be resolved at
>> the board description level.
>>
>> Signed-off-by: Kieran Bingham 
> 
> I've been working on the same thing, but you've beat me to it! Patch looks
> mostly OK, but I think you are missing this piece:
> 
> https://github.com/analogdevicesinc/linux/commit/ba9b57507cb78724a606eb24104e22fea942437d#diff-2cf1828c644e351adefabe9509410400L553

Ah yes - Thanks, - you're correct - I had missed that bit.

Added locally for a v2.
--
Kieran

>> ---
>>  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
>>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
>>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 
>> ++
>>  3 files changed, 37 insertions(+), 13 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> index 0047b1394c70..f6bb9f6d3f48 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -70,6 +70,9 @@ Optional properties:
>>rather than generate its own timings for HDMI output.
>>  - clocks: from common clock binding: reference to the CEC clock.
>>  - clock-names: from common clock binding: must be "cec".
>> +- reg-names : Names of maps with programmable addresses.
>> +It can contain any map needing a non-default address.
>> +Possible maps names are : "main", "edid", "cec", "packet"
>>  
>>  Required nodes:
>>  
>> @@ -88,7 +91,12 @@ Example
>>  
>>  adv7511w: hdmi@39 {
>>  compatible = "adi,adv7511w";
>> -reg = <39>;
>> +/*
>> + * The EDID page will be accessible on address 0x66 on the i2c
>> + * bus. All other maps continue to use their default addresses.
>> + */
>> +reg = <0x39 0x66>;
>> +reg-names = "main", "edid";
>>  interrupt-parent = <>;
>>  interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
>>  clocks = <_clock>;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> index d034b2cb5eee..7d81ce3808e0 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -53,8 +53,10 @@
>>  #define ADV7511_REG_POWER   0x41
>>  #define ADV7511_REG_STATUS  0x42
>>  #define ADV7511_REG_EDID_I2C_ADDR   0x43
>> +#define ADV7511_REG_EDID_I2C_ADDR_DEFAULT   0x3f
>>  #define ADV7511_REG_PACKET_ENABLE1  0x44
>>  #define ADV7511_REG_PACKET_I2C_ADDR 0x45
>> +#define ADV7511_REG_PACKET_I2C_ADDR_DEFAULT 0x38
>>  #define ADV7511_REG_DSD_ENABLE  0x46
>>  #define ADV7511_REG_VIDEO_INPUT_CFG20x48
>>  #define ADV7511_REG_INFOFRAME_UPDATE0x4a
>> @@ -89,6 +91,7 @@
>>  #define ADV7511_REG_TMDS_CLOCK_INV  0xde
>>  #define ADV7511_REG_ARC_CTRL0xdf
>>  #define ADV7511_REG_CEC_I2C_ADDR0xe1
>> +#define ADV7511_REG_CEC_I2C_ADDR_DEFAULT0x3c
>>  #define ADV7511_REG_CEC_CTRL0xe2
>>  #define ADV7511_REG_CHIP_ID_HIGH0xf5
>>  #define ADV7511_REG_CHIP_ID_LOW 0xf6
>> @@ -322,6 +325,7 @@ struct adv7511 {
>>  struct i2c_client *i2c_main;
>>  struct i2c_client *i2c_edid;
>>  struct i2c_client *i2c_cec;
>> +struct i2c_client *i2c_packet;
>>  
>>  struct regmap *regmap;
>>  struct regmap *regmap_cec;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> index efa29db5fc2b..7ec33837752b 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> @@ -969,8 +969,8 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
>>  {
>>  int ret;
>>  
>> -adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
>> - adv->i2c_main->addr - 1);
>> +adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
>> +ADV7511_REG_CEC_I2C_ADDR_DEFAULT);
>>  if (!adv->i2c_cec)
>>  return -ENOMEM;
>>  i2c_set_clientdata(adv->i2c_cec, adv);
>> @@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
>> struct i2c_device_id *id)
>>  struct adv7511_link_config link_config;
>>  struct adv7511 *adv7511;
>>  struct device *dev = >dev;
>> -unsigned int 

Re: [PATCH 2/2] drm: adv7511: Add support for i2c_new_secondary_device

[Kieran Bingham]

On 22/01/18 13:00, Lars-Peter Clausen wrote:
> On 01/22/2018 01:50 PM, Kieran Bingham wrote:
>> The ADV7511 has four 256-byte maps that can be accessed via the main I²C
>> ports. Each map has it own I²C address and acts as a standard slave
>> device on the I²C bus.
>>
>> Allow a device tree node to override the default addresses so that
>> address conflicts with other devices on the same bus may be resolved at
>> the board description level.
>>
>> Signed-off-by: Kieran Bingham 
> 
> I've been working on the same thing, but you've beat me to it! Patch looks
> mostly OK, but I think you are missing this piece:
> 
> https://github.com/analogdevicesinc/linux/commit/ba9b57507cb78724a606eb24104e22fea942437d#diff-2cf1828c644e351adefabe9509410400L553

Ah yes - Thanks, - you're correct - I had missed that bit.

Added locally for a v2.
--
Kieran

>> ---
>>  .../bindings/display/bridge/adi,adv7511.txt| 10 +-
>>  drivers/gpu/drm/bridge/adv7511/adv7511.h   |  4 +++
>>  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c   | 36 
>> ++
>>  3 files changed, 37 insertions(+), 13 deletions(-)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt 
>> b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> index 0047b1394c70..f6bb9f6d3f48 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
>> @@ -70,6 +70,9 @@ Optional properties:
>>rather than generate its own timings for HDMI output.
>>  - clocks: from common clock binding: reference to the CEC clock.
>>  - clock-names: from common clock binding: must be "cec".
>> +- reg-names : Names of maps with programmable addresses.
>> +It can contain any map needing a non-default address.
>> +Possible maps names are : "main", "edid", "cec", "packet"
>>  
>>  Required nodes:
>>  
>> @@ -88,7 +91,12 @@ Example
>>  
>>  adv7511w: hdmi@39 {
>>  compatible = "adi,adv7511w";
>> -reg = <39>;
>> +/*
>> + * The EDID page will be accessible on address 0x66 on the i2c
>> + * bus. All other maps continue to use their default addresses.
>> + */
>> +reg = <0x39 0x66>;
>> +reg-names = "main", "edid";
>>  interrupt-parent = <>;
>>  interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
>>  clocks = <_clock>;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h 
>> b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> index d034b2cb5eee..7d81ce3808e0 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
>> @@ -53,8 +53,10 @@
>>  #define ADV7511_REG_POWER   0x41
>>  #define ADV7511_REG_STATUS  0x42
>>  #define ADV7511_REG_EDID_I2C_ADDR   0x43
>> +#define ADV7511_REG_EDID_I2C_ADDR_DEFAULT   0x3f
>>  #define ADV7511_REG_PACKET_ENABLE1  0x44
>>  #define ADV7511_REG_PACKET_I2C_ADDR 0x45
>> +#define ADV7511_REG_PACKET_I2C_ADDR_DEFAULT 0x38
>>  #define ADV7511_REG_DSD_ENABLE  0x46
>>  #define ADV7511_REG_VIDEO_INPUT_CFG20x48
>>  #define ADV7511_REG_INFOFRAME_UPDATE0x4a
>> @@ -89,6 +91,7 @@
>>  #define ADV7511_REG_TMDS_CLOCK_INV  0xde
>>  #define ADV7511_REG_ARC_CTRL0xdf
>>  #define ADV7511_REG_CEC_I2C_ADDR0xe1
>> +#define ADV7511_REG_CEC_I2C_ADDR_DEFAULT0x3c
>>  #define ADV7511_REG_CEC_CTRL0xe2
>>  #define ADV7511_REG_CHIP_ID_HIGH0xf5
>>  #define ADV7511_REG_CHIP_ID_LOW 0xf6
>> @@ -322,6 +325,7 @@ struct adv7511 {
>>  struct i2c_client *i2c_main;
>>  struct i2c_client *i2c_edid;
>>  struct i2c_client *i2c_cec;
>> +struct i2c_client *i2c_packet;
>>  
>>  struct regmap *regmap;
>>  struct regmap *regmap_cec;
>> diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
>> b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> index efa29db5fc2b..7ec33837752b 100644
>> --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
>> @@ -969,8 +969,8 @@ static int adv7511_init_cec_regmap(struct adv7511 *adv)
>>  {
>>  int ret;
>>  
>> -adv->i2c_cec = i2c_new_dummy(adv->i2c_main->adapter,
>> - adv->i2c_main->addr - 1);
>> +adv->i2c_cec = i2c_new_secondary_device(adv->i2c_main, "cec",
>> +ADV7511_REG_CEC_I2C_ADDR_DEFAULT);
>>  if (!adv->i2c_cec)
>>  return -ENOMEM;
>>  i2c_set_clientdata(adv->i2c_cec, adv);
>> @@ -1082,8 +1082,6 @@ static int adv7511_probe(struct i2c_client *i2c, const 
>> struct i2c_device_id *id)
>>  struct adv7511_link_config link_config;
>>  struct adv7511 *adv7511;
>>  struct device *dev = >dev;
>> -unsigned int main_i2c_addr = i2c->addr << 1;

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

[Ingo Molnar]

* Ingo Molnar  wrote:

> * David Woodhouse  wrote:
> 
> > But wait, why did I say "mostly"? Well, not everyone has a retpoline
> > compiler yet... but OK, screw them; they need to update.
> > 
> > Then there's Skylake, and that generation of CPU cores. For complicated
> > reasons they actually end up being vulnerable not just on indirect
> > branches, but also on a 'ret' in some circumstances (such as 16+ CALLs
> > in a deep chain).
> > 
> > The IBRS solution, ugly though it is, did address that. Retpoline
> > doesn't. There are patches being floated to detect and prevent deep
> > stacks, and deal with some of the other special cases that bite on SKL,
> > but those are icky too. And in fact IBRS performance isn't anywhere
> > near as bad on this generation of CPUs as it is on earlier CPUs
> > *anyway*, which makes it not quite so insane to *contemplate* using it
> > as Intel proposed.
> 
> There's another possible method to avoid deep stacks on Skylake, without 
> compiler 
> support:
> 
>   - Use the existing mcount based function tracing live patching machinery
> (CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack 
> depth 
> tracking tracer which would issue a retpoline when stack depth crosses 
> boundaries of ~16 entries.

The patch below demonstrates the principle, it forcibly enables dynamic ftrace 
patching (CONFIG_DYNAMIC_FTRACE=y et al) and turns mcount/__fentry__ into a RET:

  81a01a40 <__fentry__>:
  81a01a40:   c3  retq   

This would have to be extended with (very simple) call stack depth tracking 
(just 
3 more instructions would do in the fast path I believe) and a suitable SkyLake 
workaround (and also has to play nice with the ftrace callbacks).

On non-SkyLake the overhead would be 0 cycles.

On SkyLake this would add an overhead of maybe 2-3 cycles per function call and 
obviously all this code and data would be very cache hot. Given that the 
average 
number of function calls per system call is around a dozen, this would be 
_much_ 
faster than any microcode/MSR based approach.

Is there a testcase for the SkyLake 16-deep-call-stack problem that I could 
run? 
Is there a description of the exact speculative execution vulnerability that 
has 
to be addressed to begin with?

If this approach is workable I'd much prefer it to any MSR writes in the 
syscall 
entry path not just because it's fast enough in practice to not be turned off 
by 
everyone, but also because everyone would agree that per function call overhead 
needs to go away on new CPUs. Both deployment and backporting is also _much_ 
more 
flexible, simpler, faster and more complete than microcode/firmware or compiler 
based solutions.

Assuming the vulnerability can be addressed via this route that is, which is a 
big 
assumption!

Thanks,

Ingo

 arch/x86/Kconfig| 3 +++
 arch/x86/kernel/ftrace_64.S | 1 +
 2 files changed, 4 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 423e4b64e683..df471538a79c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -133,6 +133,8 @@ config X86
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS
+   select DYNAMIC_FTRACE
+   select DYNAMIC_FTRACE_WITH_REGS
select HAVE_EBPF_JITif X86_64
select HAVE_EFFICIENT_UNALIGNED_ACCESS
select HAVE_EXIT_THREAD
@@ -140,6 +142,7 @@ config X86
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
+   select FUNCTION_TRACER
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT
select HAVE_IDE
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 7cb8ba08beb9..1e219e0f2887 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -19,6 +19,7 @@ EXPORT_SYMBOL(__fentry__)
 # define function_hook mcount
 EXPORT_SYMBOL(mcount)
 #endif
+   ret
 
 /* All cases save the original rbp (8 bytes) */
 #ifdef CONFIG_FRAME_POINTER

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

[Ingo Molnar]

* Ingo Molnar  wrote:

> * David Woodhouse  wrote:
> 
> > But wait, why did I say "mostly"? Well, not everyone has a retpoline
> > compiler yet... but OK, screw them; they need to update.
> > 
> > Then there's Skylake, and that generation of CPU cores. For complicated
> > reasons they actually end up being vulnerable not just on indirect
> > branches, but also on a 'ret' in some circumstances (such as 16+ CALLs
> > in a deep chain).
> > 
> > The IBRS solution, ugly though it is, did address that. Retpoline
> > doesn't. There are patches being floated to detect and prevent deep
> > stacks, and deal with some of the other special cases that bite on SKL,
> > but those are icky too. And in fact IBRS performance isn't anywhere
> > near as bad on this generation of CPUs as it is on earlier CPUs
> > *anyway*, which makes it not quite so insane to *contemplate* using it
> > as Intel proposed.
> 
> There's another possible method to avoid deep stacks on Skylake, without 
> compiler 
> support:
> 
>   - Use the existing mcount based function tracing live patching machinery
> (CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack 
> depth 
> tracking tracer which would issue a retpoline when stack depth crosses 
> boundaries of ~16 entries.

The patch below demonstrates the principle, it forcibly enables dynamic ftrace 
patching (CONFIG_DYNAMIC_FTRACE=y et al) and turns mcount/__fentry__ into a RET:

  81a01a40 <__fentry__>:
  81a01a40:   c3  retq   

This would have to be extended with (very simple) call stack depth tracking 
(just 
3 more instructions would do in the fast path I believe) and a suitable SkyLake 
workaround (and also has to play nice with the ftrace callbacks).

On non-SkyLake the overhead would be 0 cycles.

On SkyLake this would add an overhead of maybe 2-3 cycles per function call and 
obviously all this code and data would be very cache hot. Given that the 
average 
number of function calls per system call is around a dozen, this would be 
_much_ 
faster than any microcode/MSR based approach.

Is there a testcase for the SkyLake 16-deep-call-stack problem that I could 
run? 
Is there a description of the exact speculative execution vulnerability that 
has 
to be addressed to begin with?

If this approach is workable I'd much prefer it to any MSR writes in the 
syscall 
entry path not just because it's fast enough in practice to not be turned off 
by 
everyone, but also because everyone would agree that per function call overhead 
needs to go away on new CPUs. Both deployment and backporting is also _much_ 
more 
flexible, simpler, faster and more complete than microcode/firmware or compiler 
based solutions.

Assuming the vulnerability can be addressed via this route that is, which is a 
big 
assumption!

Thanks,

Ingo

 arch/x86/Kconfig| 3 +++
 arch/x86/kernel/ftrace_64.S | 1 +
 2 files changed, 4 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 423e4b64e683..df471538a79c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -133,6 +133,8 @@ config X86
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS
+   select DYNAMIC_FTRACE
+   select DYNAMIC_FTRACE_WITH_REGS
select HAVE_EBPF_JITif X86_64
select HAVE_EFFICIENT_UNALIGNED_ACCESS
select HAVE_EXIT_THREAD
@@ -140,6 +142,7 @@ config X86
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
+   select FUNCTION_TRACER
select HAVE_GCC_PLUGINS
select HAVE_HW_BREAKPOINT
select HAVE_IDE
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 7cb8ba08beb9..1e219e0f2887 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -19,6 +19,7 @@ EXPORT_SYMBOL(__fentry__)
 # define function_hook mcount
 EXPORT_SYMBOL(mcount)
 #endif
+   ret
 
 /* All cases save the original rbp (8 bytes) */
 #ifdef CONFIG_FRAME_POINTER

Re: [PATCH v2 12/12] x86/jailhouse: Initialize PCI support

[Jan Kiszka]

On 2018-01-22 23:26, Bjorn Helgaas wrote:
> On Mon, Nov 27, 2017 at 09:11:54AM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka 
>>
>> With this change, PCI devices can be detected and used inside a non-root
>> cell.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
>>  arch/x86/kernel/jailhouse.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
>> index 8ff21e1534de..70b857d4b1f5 100644
>> --- a/arch/x86/kernel/jailhouse.c
>> +++ b/arch/x86/kernel/jailhouse.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -108,6 +109,19 @@ static void jailhouse_no_restart(void)
>>  machine_halt();
>>  }
>>  
>> +static int __init jailhouse_pci_arch_init(void)
>> +{
>> +pci_direct_init(1);
>> +
>> +/*
>> + * There are no bridges on the virtual PCI root bus under Jailhouse,
>> + * thus no other way to discover all devices than a full scan.
>> + */
>> +pcibios_last_bus = 0xff;
> 
> Can you help me understand the comment here?  If the virtual root bus
> is bus 00, are you saying the guest might see devices on bus 00 and
> bus 01, with no bus 00 bridge that leads to bus 01?

Exactly, and there is even no root bridge for bus 0 as well. We just
hand out the devices. We try hard to keep it that simple in order to
avoid emulation bloat in the hypervisor (which < 9K LoC on Intel right now).

> 
> I suspect you mean something different because you say elsewhere that
> ARM "just works" because DT provides more configurability.  But even
> on ARM with DT, we probe the root bus and only probe other buses when
> we find bridges leading to them.

This statement about ARM probably does not apply to incomplete PCI
hierarchy. I guess we cannot fill that gap with device tree
descriptions, but I also didn't run into that scenario yet as most ARM
systems we tested do not even allow to partition PCI buses (many IOMMU
implementations on SoCs, where available at all, consider the root
complex as single device).

> 
> So I suspect the purpose of this may be to discover devices that are
> below host bridges not exposed by ACPI.  For example, my BIOS may
> expose one host bridge:
> 
>   ACPI: PCI Root Bridge [PCI0] (domain  [bus 00-7e])
> 
> but the chipset may implement devices on bus 7f even though the BIOS
> did not advertise the host bridge leading to that bus.  This is a case
> of a missing host bridge, not a missing bridge on the root bus.
> 
> Can you show an example "lspci -v" output to make this concrete?

We we go, using a QEMU/KVM setup
(... -device pci-bridge,chassis_nr=1,id=b1
-device e1000e,addr=1.0,netdev=net,bus=b1):

# lspci -v
00:0e.0 Unassigned class [ff01]: Red Hat, Inc Inter-VM shared memory
Subsystem: Red Hat, Inc Inter-VM shared memory
Flags: bus master, fast devsel, latency 0
Memory at 1 (64-bit, non-prefetchable) [size=256]
Memory at 10100 (64-bit, non-prefetchable) [size=32]
Capabilities: [50] MSI-X: Enable+ Count=1 Masked-
Kernel driver in use: ivshmem-net

01:01.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
Subsystem: Intel Corporation Device 
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at fe84 (32-bit, non-prefetchable) [size=128K]
Memory at fe86 (32-bit, non-prefetchable) [size=128K]
I/O ports at c000 [disabled] [size=32]
Memory at fe88 (32-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 52-54-00-ff-ff-12-34-56
Kernel driver in use: e1000e

Jan

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

Re: [PATCH v2 12/12] x86/jailhouse: Initialize PCI support

[Jan Kiszka]

On 2018-01-22 23:26, Bjorn Helgaas wrote:
> On Mon, Nov 27, 2017 at 09:11:54AM +0100, Jan Kiszka wrote:
>> From: Jan Kiszka 
>>
>> With this change, PCI devices can be detected and used inside a non-root
>> cell.
>>
>> Signed-off-by: Jan Kiszka 
>> ---
>>  arch/x86/kernel/jailhouse.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
>> index 8ff21e1534de..70b857d4b1f5 100644
>> --- a/arch/x86/kernel/jailhouse.c
>> +++ b/arch/x86/kernel/jailhouse.c
>> @@ -18,6 +18,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -108,6 +109,19 @@ static void jailhouse_no_restart(void)
>>  machine_halt();
>>  }
>>  
>> +static int __init jailhouse_pci_arch_init(void)
>> +{
>> +pci_direct_init(1);
>> +
>> +/*
>> + * There are no bridges on the virtual PCI root bus under Jailhouse,
>> + * thus no other way to discover all devices than a full scan.
>> + */
>> +pcibios_last_bus = 0xff;
> 
> Can you help me understand the comment here?  If the virtual root bus
> is bus 00, are you saying the guest might see devices on bus 00 and
> bus 01, with no bus 00 bridge that leads to bus 01?

Exactly, and there is even no root bridge for bus 0 as well. We just
hand out the devices. We try hard to keep it that simple in order to
avoid emulation bloat in the hypervisor (which < 9K LoC on Intel right now).

> 
> I suspect you mean something different because you say elsewhere that
> ARM "just works" because DT provides more configurability.  But even
> on ARM with DT, we probe the root bus and only probe other buses when
> we find bridges leading to them.

This statement about ARM probably does not apply to incomplete PCI
hierarchy. I guess we cannot fill that gap with device tree
descriptions, but I also didn't run into that scenario yet as most ARM
systems we tested do not even allow to partition PCI buses (many IOMMU
implementations on SoCs, where available at all, consider the root
complex as single device).

> 
> So I suspect the purpose of this may be to discover devices that are
> below host bridges not exposed by ACPI.  For example, my BIOS may
> expose one host bridge:
> 
>   ACPI: PCI Root Bridge [PCI0] (domain  [bus 00-7e])
> 
> but the chipset may implement devices on bus 7f even though the BIOS
> did not advertise the host bridge leading to that bus.  This is a case
> of a missing host bridge, not a missing bridge on the root bus.
> 
> Can you show an example "lspci -v" output to make this concrete?

We we go, using a QEMU/KVM setup
(... -device pci-bridge,chassis_nr=1,id=b1
-device e1000e,addr=1.0,netdev=net,bus=b1):

# lspci -v
00:0e.0 Unassigned class [ff01]: Red Hat, Inc Inter-VM shared memory
Subsystem: Red Hat, Inc Inter-VM shared memory
Flags: bus master, fast devsel, latency 0
Memory at 1 (64-bit, non-prefetchable) [size=256]
Memory at 10100 (64-bit, non-prefetchable) [size=32]
Capabilities: [50] MSI-X: Enable+ Count=1 Masked-
Kernel driver in use: ivshmem-net

01:01.0 Ethernet controller: Intel Corporation 82574L Gigabit Network
Connection
Subsystem: Intel Corporation Device 
Flags: bus master, fast devsel, latency 0, IRQ 11
Memory at fe84 (32-bit, non-prefetchable) [size=128K]
Memory at fe86 (32-bit, non-prefetchable) [size=128K]
I/O ports at c000 [disabled] [size=32]
Memory at fe88 (32-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [a0] MSI-X: Enable+ Count=5 Masked-
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 52-54-00-ff-ff-12-34-56
Kernel driver in use: e1000e

Jan

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

[PATCH V2] tty: fix data race between tty_init_dev and flush of buf

[Gaurav Kohli]

There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty->disc_data
may be NULL.

CPU0CPU1

 000|n_tty_receive_buf_common() n_tty_open()
-001|n_tty_receive_buf2()   tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline)  tty_ldisc_setup()

Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.

Signed-off-by: Gaurav Kohli 
---

Changes since V1:
- Fix compilation, In case TTY is disabled in build.

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index dc60aee..4b506f2 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1323,6 +1323,9 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
"%s: %s driver does not set tty->port. This will crash 
the kernel later. Fix the driver!\n",
__func__, tty->driver->name);
 
+   retval = tty_ldisc_lock(tty, 5 * HZ);
+   if (retval)
+   goto err_release_lock;
tty->port->itty = tty;
 
/*
@@ -1333,6 +1336,7 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
retval = tty_ldisc_setup(tty, tty->link);
if (retval)
goto err_release_tty;
+   tty_ldisc_unlock(tty);
/* Return the tty locked so that it cannot vanish under the caller */
return tty;
 
@@ -1345,9 +1349,11 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
 
/* call the tty release_tty routine to clean out this slot */
 err_release_tty:
-   tty_unlock(tty);
+   tty_ldisc_unlock(tty);
tty_info_ratelimited(tty, "ldisc open failed (%d), clearing slot %d\n",
 retval, idx);
+err_release_lock:
+   tty_unlock(tty);
release_tty(tty, idx);
return ERR_PTR(retval);
 }
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 24ec5c7..4e7946c 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -337,7 +337,7 @@ static inline void __tty_ldisc_unlock(struct tty_struct 
*tty)
ldsem_up_write(>ldisc_sem);
 }
 
-static int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout)
+int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout)
 {
int ret;
 
@@ -348,7 +348,7 @@ static int tty_ldisc_lock(struct tty_struct *tty, unsigned 
long timeout)
return 0;
 }
 
-static void tty_ldisc_unlock(struct tty_struct *tty)
+void tty_ldisc_unlock(struct tty_struct *tty)
 {
clear_bit(TTY_LDISC_HALTED, >flags);
__tty_ldisc_unlock(tty);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 7ac8ba2..0a6c71e 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -405,6 +405,8 @@ static inline bool tty_throttled(struct tty_struct *tty)
 extern struct tty_struct *tty_kopen(dev_t device);
 extern void tty_kclose(struct tty_struct *tty);
 extern int tty_dev_name_to_number(const char *name, dev_t *number);
+extern int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout);
+extern void tty_ldisc_unlock(struct tty_struct *tty);
 #else
 static inline void tty_kref_put(struct tty_struct *tty)
 { }
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH V2] tty: fix data race between tty_init_dev and flush of buf

[Gaurav Kohli]

There can be a race, if receive_buf call comes before
tty initialization completes in n_tty_open and tty->disc_data
may be NULL.

CPU0CPU1

 000|n_tty_receive_buf_common() n_tty_open()
-001|n_tty_receive_buf2()   tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline)  tty_ldisc_setup()

Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.

Signed-off-by: Gaurav Kohli 
---

Changes since V1:
- Fix compilation, In case TTY is disabled in build.

diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index dc60aee..4b506f2 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -1323,6 +1323,9 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
"%s: %s driver does not set tty->port. This will crash 
the kernel later. Fix the driver!\n",
__func__, tty->driver->name);
 
+   retval = tty_ldisc_lock(tty, 5 * HZ);
+   if (retval)
+   goto err_release_lock;
tty->port->itty = tty;
 
/*
@@ -1333,6 +1336,7 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
retval = tty_ldisc_setup(tty, tty->link);
if (retval)
goto err_release_tty;
+   tty_ldisc_unlock(tty);
/* Return the tty locked so that it cannot vanish under the caller */
return tty;
 
@@ -1345,9 +1349,11 @@ struct tty_struct *tty_init_dev(struct tty_driver 
*driver, int idx)
 
/* call the tty release_tty routine to clean out this slot */
 err_release_tty:
-   tty_unlock(tty);
+   tty_ldisc_unlock(tty);
tty_info_ratelimited(tty, "ldisc open failed (%d), clearing slot %d\n",
 retval, idx);
+err_release_lock:
+   tty_unlock(tty);
release_tty(tty, idx);
return ERR_PTR(retval);
 }
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index 24ec5c7..4e7946c 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -337,7 +337,7 @@ static inline void __tty_ldisc_unlock(struct tty_struct 
*tty)
ldsem_up_write(>ldisc_sem);
 }
 
-static int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout)
+int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout)
 {
int ret;
 
@@ -348,7 +348,7 @@ static int tty_ldisc_lock(struct tty_struct *tty, unsigned 
long timeout)
return 0;
 }
 
-static void tty_ldisc_unlock(struct tty_struct *tty)
+void tty_ldisc_unlock(struct tty_struct *tty)
 {
clear_bit(TTY_LDISC_HALTED, >flags);
__tty_ldisc_unlock(tty);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 7ac8ba2..0a6c71e 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -405,6 +405,8 @@ static inline bool tty_throttled(struct tty_struct *tty)
 extern struct tty_struct *tty_kopen(dev_t device);
 extern void tty_kclose(struct tty_struct *tty);
 extern int tty_dev_name_to_number(const char *name, dev_t *number);
+extern int tty_ldisc_lock(struct tty_struct *tty, unsigned long timeout);
+extern void tty_ldisc_unlock(struct tty_struct *tty);
 #else
 static inline void tty_kref_put(struct tty_struct *tty)
 { }
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. 
is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: possible deadlock in perf_trace_destroy (2)

[Dmitry Vyukov]

On Tue, Jan 23, 2018 at 12:19 AM, Peter Zijlstra  wrote:
> On Mon, Jan 22, 2018 at 05:20:13PM -0500, Steven Rostedt wrote:
>>
>> Peter,
>>
>> Isn't this the same as what you mentioned (and had a hack patch for)
>> before?
>>
>>  
>> http://lkml.kernel.org/r/20180109133651.gb2...@hirez.programming.kicks-ass.net
>>
>
> Looks like it. Just haven't managed to get those patches merged. I'll
> try and get that sorted tomorrow. Thanks for the reminder.

Please add the following tag to the commit:
Reported-by: 
syzbot+c9695f0404c72c8f0b7abbac660d986af9008...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

Re: possible deadlock in perf_trace_destroy (2)

[Dmitry Vyukov]

On Tue, Jan 23, 2018 at 12:19 AM, Peter Zijlstra  wrote:
> On Mon, Jan 22, 2018 at 05:20:13PM -0500, Steven Rostedt wrote:
>>
>> Peter,
>>
>> Isn't this the same as what you mentioned (and had a hack patch for)
>> before?
>>
>>  
>> http://lkml.kernel.org/r/20180109133651.gb2...@hirez.programming.kicks-ass.net
>>
>
> Looks like it. Just haven't managed to get those patches merged. I'll
> try and get that sorted tomorrow. Thanks for the reminder.

Please add the following tag to the commit:
Reported-by: 
syzbot+c9695f0404c72c8f0b7abbac660d986af9008...@syzkaller.appspotmail.com
It will help syzbot understand when the bug is fixed.

[PATCH] ARM: dts: imx6sx: add pu power domain support

[Anson Huang]

Add PU power domain support, GPU is the only
module inside PU power domain, and PU power
is supplied by LDO_SOC.

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx6sx.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index fd78793..42ef4c6 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -188,6 +188,7 @@
 < IMX6SX_CLK_GPU>,
 < IMX6SX_CLK_GPU>;
clock-names = "bus", "core", "shader";
+   power-domains = <_pu>;
};
 
dma_apbh: dma-apbh@1804000 {
@@ -767,6 +768,13 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   pd_pu: power-domain@1 {
+   reg = <1>;
+   #power-domain-cells = <0>;
+   power-supply = <_soc>;
+   clocks = < IMX6SX_CLK_GPU>;
+   };
+
pd_pci: power-domain@3 {
reg = <3>;
#power-domain-cells = <0>;
-- 
2.7.4

[PATCH] ARM: dts: imx6sx: add pu power domain support

[Anson Huang]

Add PU power domain support, GPU is the only
module inside PU power domain, and PU power
is supplied by LDO_SOC.

Signed-off-by: Anson Huang 
---
 arch/arm/boot/dts/imx6sx.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi
index fd78793..42ef4c6 100644
--- a/arch/arm/boot/dts/imx6sx.dtsi
+++ b/arch/arm/boot/dts/imx6sx.dtsi
@@ -188,6 +188,7 @@
 < IMX6SX_CLK_GPU>,
 < IMX6SX_CLK_GPU>;
clock-names = "bus", "core", "shader";
+   power-domains = <_pu>;
};
 
dma_apbh: dma-apbh@1804000 {
@@ -767,6 +768,13 @@
#address-cells = <1>;
#size-cells = <0>;
 
+   pd_pu: power-domain@1 {
+   reg = <1>;
+   #power-domain-cells = <0>;
+   power-supply = <_soc>;
+   clocks = < IMX6SX_CLK_GPU>;
+   };
+
pd_pci: power-domain@3 {
reg = <3>;
#power-domain-cells = <0>;
-- 
2.7.4

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

On (01/23/18 15:40), Sergey Senozhatsky wrote:
> 
> Why do we even use irq_work for printk_safe?
> 

... perhaps because of

wq: pool->lock -> printk -> call_console_drivers -> printk -> vprintk_safe -> 
wq: pool->lock

Which is a "many things have gone wrong" type of scenario. Maybe we
can workaround it somehow, hm. Tejun, can we have lockless WQ? ;)

-ss

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

On (01/23/18 15:40), Sergey Senozhatsky wrote:
> 
> Why do we even use irq_work for printk_safe?
> 

... perhaps because of

wq: pool->lock -> printk -> call_console_drivers -> printk -> vprintk_safe -> 
wq: pool->lock

Which is a "many things have gone wrong" type of scenario. Maybe we
can workaround it somehow, hm. Tejun, can we have lockless WQ? ;)

-ss

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

[Ingo Molnar]

* David Woodhouse  wrote:

> But wait, why did I say "mostly"? Well, not everyone has a retpoline
> compiler yet... but OK, screw them; they need to update.
> 
> Then there's Skylake, and that generation of CPU cores. For complicated
> reasons they actually end up being vulnerable not just on indirect
> branches, but also on a 'ret' in some circumstances (such as 16+ CALLs
> in a deep chain).
> 
> The IBRS solution, ugly though it is, did address that. Retpoline
> doesn't. There are patches being floated to detect and prevent deep
> stacks, and deal with some of the other special cases that bite on SKL,
> but those are icky too. And in fact IBRS performance isn't anywhere
> near as bad on this generation of CPUs as it is on earlier CPUs
> *anyway*, which makes it not quite so insane to *contemplate* using it
> as Intel proposed.

There's another possible method to avoid deep stacks on Skylake, without 
compiler 
support:

  - Use the existing mcount based function tracing live patching machinery
(CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack depth 
tracking tracer which would issue a retpoline when stack depth crosses 
boundaries of ~16 entries.

The overhead of that would _still_ very likely be much cheaper than a hundreds 
(thousands) of cycle expensive MSR write at every kernel entry (syscall entry, 
IRQ 
entry, etc.).

Note the huge number of advantages:

 - All distro kernels already enable the mcount based patching options, so 
there's
   literally zero overhead to anything except SkyLake.

 - It is fully kernel patching based and can be activated on Skylake only

 - It doesn't require any microcode updates, so it will work on all existing 
CPUs
   with no firmware or microcode modificatons

 - It doesn't require any compiler updates

 - SkyLake performance is very likely to be much less fragile than relying on a 
   hastily deployed microcode hack

 - The "SkyLake stack depth tracer" can be tested on other CPUs as well in 
debug 
   builds, broadening the testing base

 - The tracer is very obviously simple and reviewable, and we can forget about 
it
   in the far future.

 - It's much more backportable to older kernels: should there be a new class of
   exploits then this machinery could be updated to cover that too - while 
   upgrades to newer kernels would give the higher performant solution.

Yes, there are some practical complications like always enabling 
CONFIG_FUNCTION_TRACER=y on x86, plus the ftrace interaction has to be sorted 
out, 
but in practice it's enabled on all major distros anyway, due to ftrace.

Is there any reason why this wouldn't work?

Thanks,

Ingo

Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation

[Ingo Molnar]

* David Woodhouse  wrote:

> But wait, why did I say "mostly"? Well, not everyone has a retpoline
> compiler yet... but OK, screw them; they need to update.
> 
> Then there's Skylake, and that generation of CPU cores. For complicated
> reasons they actually end up being vulnerable not just on indirect
> branches, but also on a 'ret' in some circumstances (such as 16+ CALLs
> in a deep chain).
> 
> The IBRS solution, ugly though it is, did address that. Retpoline
> doesn't. There are patches being floated to detect and prevent deep
> stacks, and deal with some of the other special cases that bite on SKL,
> but those are icky too. And in fact IBRS performance isn't anywhere
> near as bad on this generation of CPUs as it is on earlier CPUs
> *anyway*, which makes it not quite so insane to *contemplate* using it
> as Intel proposed.

There's another possible method to avoid deep stacks on Skylake, without 
compiler 
support:

  - Use the existing mcount based function tracing live patching machinery
(CONFIG_FUNCTION_TRACER=y) to install a _very_ fast and simple stack depth 
tracking tracer which would issue a retpoline when stack depth crosses 
boundaries of ~16 entries.

The overhead of that would _still_ very likely be much cheaper than a hundreds 
(thousands) of cycle expensive MSR write at every kernel entry (syscall entry, 
IRQ 
entry, etc.).

Note the huge number of advantages:

 - All distro kernels already enable the mcount based patching options, so 
there's
   literally zero overhead to anything except SkyLake.

 - It is fully kernel patching based and can be activated on Skylake only

 - It doesn't require any microcode updates, so it will work on all existing 
CPUs
   with no firmware or microcode modificatons

 - It doesn't require any compiler updates

 - SkyLake performance is very likely to be much less fragile than relying on a 
   hastily deployed microcode hack

 - The "SkyLake stack depth tracer" can be tested on other CPUs as well in 
debug 
   builds, broadening the testing base

 - The tracer is very obviously simple and reviewable, and we can forget about 
it
   in the far future.

 - It's much more backportable to older kernels: should there be a new class of
   exploits then this machinery could be updated to cover that too - while 
   upgrades to newer kernels would give the higher performant solution.

Yes, there are some practical complications like always enabling 
CONFIG_FUNCTION_TRACER=y on x86, plus the ftrace interaction has to be sorted 
out, 
but in practice it's enabled on all major distros anyway, due to ftrace.

Is there any reason why this wouldn't work?

Thanks,

Ingo

Re: [PATCH v6 22/36] nds32: Debugging support

[Vincent Chen]

2018-01-18 18:37 GMT+08:00 Arnd Bergmann :
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu  wrote:
>> From: Greentime Hu 
>>
>> This patch adds ptrace support.
>>
>> Signed-off-by: Vincent Chen 
>> Signed-off-by: Greentime Hu 
>
> I must have missed this patch earlier, unfortunately I don't think
> this is ready:
>
>> +long arch_ptrace(struct task_struct *child, long request, unsigned long 
>> addr,
>> +unsigned long data)
>> +{
>> +   int ret;
>> +
>> +   switch (request) {
>> +   case PTRACE_PEEKUSR:
>> +   ret =
>> +   ptrace_read_user(child, addr, (unsigned long __user 
>> *)data);
>> +   break;
>> +
>> +   case PTRACE_POKEUSR:
>> +   ret = ptrace_write_user(child, addr, data);
>> +   break;
>> +
>> +   case PTRACE_GETREGS:
>> +   ret = ptrace_getregs(child, (void __user *)data);
>> +   break;
>> +
>> +   case PTRACE_SETREGS:
>> +   ret = ptrace_setregs(child, (void __user *)data);
>> +   break;
>> +
>> +   case PTRACE_GETFPREGS:
>> +   ret = ptrace_getfpregs(child, (void __user *)data);
>> +   break;
>> +
>> +   case PTRACE_SETFPREGS:
>> +   ret = ptrace_setfpregs(child, (void __user *)data);
>> +   break;
>> +
>> +   default:
>> +   ret = ptrace_request(child, request, addr, data);
>> +   break;
>> +   }
>> +
>> +   return ret;
>> +}
>
> It appears that you are implementing the old-style ptrace handling
> with architecture specific commands. Please have a look at how
> this is done in risc-v or arm64. If this takes more too much time
> to address, I'd suggest using an empty stub function for sys_ptrace
> and adding it back at a later point, but not send the current version
> upstream.
>
>  Arnd

Dear Arnd:

Thanks for your comments.

After referring to risc-v and arm64, I realize that PTRACE_GETREGSET
and PTRACE_SETREGSET is used to replace arch specific command.
The needed port for the two ptrace commands had done in current
version patch.

Could I keep them and just removing the code for old-style ptrace
handling in the next version patch?

Thanks

Vincent

Re: [PATCH v6 22/36] nds32: Debugging support

[Vincent Chen]

2018-01-18 18:37 GMT+08:00 Arnd Bergmann :
> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu  wrote:
>> From: Greentime Hu 
>>
>> This patch adds ptrace support.
>>
>> Signed-off-by: Vincent Chen 
>> Signed-off-by: Greentime Hu 
>
> I must have missed this patch earlier, unfortunately I don't think
> this is ready:
>
>> +long arch_ptrace(struct task_struct *child, long request, unsigned long 
>> addr,
>> +unsigned long data)
>> +{
>> +   int ret;
>> +
>> +   switch (request) {
>> +   case PTRACE_PEEKUSR:
>> +   ret =
>> +   ptrace_read_user(child, addr, (unsigned long __user 
>> *)data);
>> +   break;
>> +
>> +   case PTRACE_POKEUSR:
>> +   ret = ptrace_write_user(child, addr, data);
>> +   break;
>> +
>> +   case PTRACE_GETREGS:
>> +   ret = ptrace_getregs(child, (void __user *)data);
>> +   break;
>> +
>> +   case PTRACE_SETREGS:
>> +   ret = ptrace_setregs(child, (void __user *)data);
>> +   break;
>> +
>> +   case PTRACE_GETFPREGS:
>> +   ret = ptrace_getfpregs(child, (void __user *)data);
>> +   break;
>> +
>> +   case PTRACE_SETFPREGS:
>> +   ret = ptrace_setfpregs(child, (void __user *)data);
>> +   break;
>> +
>> +   default:
>> +   ret = ptrace_request(child, request, addr, data);
>> +   break;
>> +   }
>> +
>> +   return ret;
>> +}
>
> It appears that you are implementing the old-style ptrace handling
> with architecture specific commands. Please have a look at how
> this is done in risc-v or arm64. If this takes more too much time
> to address, I'd suggest using an empty stub function for sys_ptrace
> and adding it back at a later point, but not send the current version
> upstream.
>
>  Arnd

Dear Arnd:

Thanks for your comments.

After referring to risc-v and arm64, I realize that PTRACE_GETREGSET
and PTRACE_SETREGSET is used to replace arch specific command.
The needed port for the two ptrace commands had done in current
version patch.

Could I keep them and just removing the code for old-style ptrace
handling in the next version patch?

Thanks

Vincent

Re: backport Rewrite sync_core() to use IRET-to-self to stable kernels?

[gre...@linuxfoundation.org]

On Mon, Jan 22, 2018 at 07:06:29PM -0800, Andy Lutomirski wrote:
> On Mon, Jan 22, 2018 at 6:59 PM, Zhang, Ning A  wrote:
> > hello, Greg, Andy, Thomas
> >
> > would you like to backport these two patches to LTS kernel?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/arch/x86/include/asm/processor.h?h=v4.14.14=1c52d859cb2d417e7216d3e56bb7fea88444cec9
> >
> > x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/arch/x86/include/asm/processor.h?h=v4.14.14=c198b121b1a1d7a7171770c634cd49191bac4477
> >
> > x86/asm: Rewrite sync_core() to use IRET-to-self
> >
> 
> I'd be in favor of backporting
> 1c52d859cb2d417e7216d3e56bb7fea88444cec9.  I see no compelling reason
> to backport the other one, since it doesn't fix a bug.  Greg, can you
> do this?

I'll work on this after this round of stable kernels are released.

thanks,

greg k-h

Re: backport Rewrite sync_core() to use IRET-to-self to stable kernels?

[gre...@linuxfoundation.org]

On Mon, Jan 22, 2018 at 07:06:29PM -0800, Andy Lutomirski wrote:
> On Mon, Jan 22, 2018 at 6:59 PM, Zhang, Ning A  wrote:
> > hello, Greg, Andy, Thomas
> >
> > would you like to backport these two patches to LTS kernel?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/arch/x86/include/asm/processor.h?h=v4.14.14=1c52d859cb2d417e7216d3e56bb7fea88444cec9
> >
> > x86/asm/32: Make sync_core() handle missing CPUID on all 32-bit kernels
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/arch/x86/include/asm/processor.h?h=v4.14.14=c198b121b1a1d7a7171770c634cd49191bac4477
> >
> > x86/asm: Rewrite sync_core() to use IRET-to-self
> >
> 
> I'd be in favor of backporting
> 1c52d859cb2d417e7216d3e56bb7fea88444cec9.  I see no compelling reason
> to backport the other one, since it doesn't fix a bug.  Greg, can you
> do this?

I'll work on this after this round of stable kernels are released.

thanks,

greg k-h

Re: [PATCH v2] ARM: dts: ls1021a: add nodes for on-chip ram

[Shawn Guo]

On Wed, Jan 03, 2018 at 04:45:45PM +0100, Rasmus Villemoes wrote:
> Although the two nodes constitute one contiguous 128K region, still
> describe them separately:
> 
> - That's how they are described in the reference manual: "Each OCRAM
>   occupies a 64 KB of address region...", and the names ocram1 and
>   ocram2 are also as used in the manual.
> 
> - The two areas are treated differently by the boot ROM code: OCRAM2 is
>   zero-initialized, while, again quoting the RM, "software must perform
>   the zero initialization of OCRAM1."
> 
> Signed-off-by: Rasmus Villemoes 

Applied, thanks.

Re: [PATCH v2] ARM: dts: ls1021a: add nodes for on-chip ram

[Shawn Guo]

On Wed, Jan 03, 2018 at 04:45:45PM +0100, Rasmus Villemoes wrote:
> Although the two nodes constitute one contiguous 128K region, still
> describe them separately:
> 
> - That's how they are described in the reference manual: "Each OCRAM
>   occupies a 64 KB of address region...", and the names ocram1 and
>   ocram2 are also as used in the manual.
> 
> - The two areas are treated differently by the boot ROM code: OCRAM2 is
>   zero-initialized, while, again quoting the RM, "software must perform
>   the zero initialization of OCRAM1."
> 
> Signed-off-by: Rasmus Villemoes 

Applied, thanks.

Re: selftests: run all tests

[Michael Ellerman]

Borislav Petkov  writes:

> On Tue, Jan 16, 2018 at 12:44:28PM +0100, Borislav Petkov wrote:
>> Ah, that was hidden in the included lib.mk, thanks.
>> 
>> I wonder if we should make it more user-friendly by adding a help target
>> like for the main Makefile...
>
> One more point:
>
> What I do is copy the x86/ folder to a test box and run all tests there.
> If the lib.mk is not copied, run_tests is missing

OK, that's not really supported I guess.

If you're happy building on your host system, you can do:

$ make -C tools/testing/selftests/ TARGETS=x86 install

And then you'll have:

$ find tools/testing/selftests/install/
tools/testing/selftests/install/
tools/testing/selftests/install/x86
tools/testing/selftests/install/x86/mpx-mini-test_64
tools/testing/selftests/install/x86/iopl_64
tools/testing/selftests/install/x86/sysret_rip_64
tools/testing/selftests/install/x86/protection_keys_64
tools/testing/selftests/install/x86/sysret_ss_attrs_64
tools/testing/selftests/install/x86/syscall_nt_64
tools/testing/selftests/install/x86/test_mremap_vdso_64
tools/testing/selftests/install/x86/ioperm_64
tools/testing/selftests/install/x86/ptrace_syscall_64
tools/testing/selftests/install/x86/sigreturn_64
tools/testing/selftests/install/x86/fsgsbase_64
tools/testing/selftests/install/x86/5lvl_64
tools/testing/selftests/install/x86/check_initial_reg_state_64
tools/testing/selftests/install/x86/ldt_gdt_64
tools/testing/selftests/install/x86/single_step_syscall_64
tools/testing/selftests/install/x86/test_vdso_64
tools/testing/selftests/install/run_kselftest.sh

You can rsync that wherever, and run it manually or with the
run_kselftest.sh script.

cheers

Re: selftests: run all tests

[Michael Ellerman]

Borislav Petkov  writes:

> On Tue, Jan 16, 2018 at 12:44:28PM +0100, Borislav Petkov wrote:
>> Ah, that was hidden in the included lib.mk, thanks.
>> 
>> I wonder if we should make it more user-friendly by adding a help target
>> like for the main Makefile...
>
> One more point:
>
> What I do is copy the x86/ folder to a test box and run all tests there.
> If the lib.mk is not copied, run_tests is missing

OK, that's not really supported I guess.

If you're happy building on your host system, you can do:

$ make -C tools/testing/selftests/ TARGETS=x86 install

And then you'll have:

$ find tools/testing/selftests/install/
tools/testing/selftests/install/
tools/testing/selftests/install/x86
tools/testing/selftests/install/x86/mpx-mini-test_64
tools/testing/selftests/install/x86/iopl_64
tools/testing/selftests/install/x86/sysret_rip_64
tools/testing/selftests/install/x86/protection_keys_64
tools/testing/selftests/install/x86/sysret_ss_attrs_64
tools/testing/selftests/install/x86/syscall_nt_64
tools/testing/selftests/install/x86/test_mremap_vdso_64
tools/testing/selftests/install/x86/ioperm_64
tools/testing/selftests/install/x86/ptrace_syscall_64
tools/testing/selftests/install/x86/sigreturn_64
tools/testing/selftests/install/x86/fsgsbase_64
tools/testing/selftests/install/x86/5lvl_64
tools/testing/selftests/install/x86/check_initial_reg_state_64
tools/testing/selftests/install/x86/ldt_gdt_64
tools/testing/selftests/install/x86/single_step_syscall_64
tools/testing/selftests/install/x86/test_vdso_64
tools/testing/selftests/install/run_kselftest.sh

You can rsync that wherever, and run it manually or with the
run_kselftest.sh script.

cheers

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

On (01/23/18 15:40), Sergey Senozhatsky wrote:
[..]
> Why do we even use irq_work for printk_safe?
> 
> Okay... So, how about this. For printk_safe we use system_wq for flushing.
> IOW, we flush from a task running exactly on the same CPU which hit printk
> recursion, not from IRQ. From vprintk_safe() recursion, we queue work on
> *that* CPU. Which gives us the following thing: if CPU stuck in
> console_unlock() loop with preemption disabled, then system_wq does not
> schedule on that CPU and we, thus, don't flush printk_safe buffer from that
> CPU. But if CPU can reschedule, then we are kinda OK to flush printk_safe
> buffer, printing extra messages from that CPU will not lock it up, because
> it's in preemptible context.
> 
> Thoughts?

A slightly reworked version:
a) Do not check console_locked
b) Do not have irq_work fast path for printk_safe buffer
 c) Which lets to union WQ/IRQ work structs - we use only IRQ work for
NMI buffers, and only WQ work for SAFE buffers
 d) And also to refactor the code

From: Sergey Senozhatsky 
Subject: [PATCH] printk/safe: use system_wq to flush printk_safe buffers

---
 kernel/printk/printk_safe.c | 52 ++---
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 3e3c2004bb23..6c8c82cedccb 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -49,7 +50,12 @@ static int printk_safe_irq_ready __read_mostly;
 struct printk_safe_seq_buf {
atomic_tlen;/* length of written data */
atomic_tmessage_lost;
-   struct irq_work work;   /* IRQ work that flushes the buffer */
+   union {
+   /* IRQ work that flushes NMI buffer */
+   struct irq_work irq_flush_work;
+   /* WQ work that flushes SAFE buffer */
+   struct work_struct  wq_flush_work;
+   };
unsigned char   buffer[SAFE_LOG_BUF_LEN];
 };
 
@@ -61,10 +67,18 @@ static DEFINE_PER_CPU(struct printk_safe_seq_buf, 
nmi_print_seq);
 #endif
 
 /* Get flushed in a more safe context. */
-static void queue_flush_work(struct printk_safe_seq_buf *s)
+static void queue_irq_flush_work(struct printk_safe_seq_buf *s)
 {
if (printk_safe_irq_ready)
-   irq_work_queue(>work);
+   irq_work_queue(>irq_flush_work);
+}
+
+static void queue_wq_flush_work(struct printk_safe_seq_buf *s)
+{
+   if (printk_safe_irq_ready)
+   queue_work_on(smp_processor_id(),
+   system_wq,
+   >wq_flush_work);
 }
 
 /*
@@ -89,7 +103,6 @@ static __printf(2, 0) int printk_safe_log_store(struct 
printk_safe_seq_buf *s,
/* The trailing '\0' is not counted into len. */
if (len >= sizeof(s->buffer) - 1) {
atomic_inc(>message_lost);
-   queue_flush_work(s);
return 0;
}
 
@@ -112,7 +125,6 @@ static __printf(2, 0) int printk_safe_log_store(struct 
printk_safe_seq_buf *s,
if (atomic_cmpxchg(>len, len, len + add) != len)
goto again;
 
-   queue_flush_work(s);
return add;
 }
 
@@ -186,12 +198,10 @@ static void report_message_lost(struct 
printk_safe_seq_buf *s)
  * Flush data from the associated per-CPU buffer. The function
  * can be called either via IRQ work or independently.
  */
-static void __printk_safe_flush(struct irq_work *work)
+static void __printk_safe_flush(struct printk_safe_seq_buf *s)
 {
static raw_spinlock_t read_lock =
__RAW_SPIN_LOCK_INITIALIZER(read_lock);
-   struct printk_safe_seq_buf *s =
-   container_of(work, struct printk_safe_seq_buf, work);
unsigned long flags;
size_t len;
int i;
@@ -243,6 +253,22 @@ static void __printk_safe_flush(struct irq_work *work)
raw_spin_unlock_irqrestore(_lock, flags);
 }
 
+static void irq_flush_work_fn(struct irq_work *work)
+{
+   struct printk_safe_seq_buf *s =
+   container_of(work, struct printk_safe_seq_buf, irq_flush_work);
+
+   __printk_safe_flush(s);
+}
+
+static void wq_flush_work_fn(struct work_struct *work)
+{
+   struct printk_safe_seq_buf *s =
+   container_of(work, struct printk_safe_seq_buf, wq_flush_work);
+
+   __printk_safe_flush(s);
+}
+
 /**
  * printk_safe_flush - flush all per-cpu nmi buffers.
  *
@@ -256,9 +282,9 @@ void printk_safe_flush(void)
 
for_each_possible_cpu(cpu) {
 #ifdef CONFIG_PRINTK_NMI
-   __printk_safe_flush(_cpu(nmi_print_seq, cpu).work);
+   __printk_safe_flush(this_cpu_ptr(_print_seq));
 #endif
-   __printk_safe_flush(_cpu(safe_print_seq, cpu).work);
+   __printk_safe_flush(this_cpu_ptr(_print_seq));
}
 

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

On (01/23/18 15:40), Sergey Senozhatsky wrote:
[..]
> Why do we even use irq_work for printk_safe?
> 
> Okay... So, how about this. For printk_safe we use system_wq for flushing.
> IOW, we flush from a task running exactly on the same CPU which hit printk
> recursion, not from IRQ. From vprintk_safe() recursion, we queue work on
> *that* CPU. Which gives us the following thing: if CPU stuck in
> console_unlock() loop with preemption disabled, then system_wq does not
> schedule on that CPU and we, thus, don't flush printk_safe buffer from that
> CPU. But if CPU can reschedule, then we are kinda OK to flush printk_safe
> buffer, printing extra messages from that CPU will not lock it up, because
> it's in preemptible context.
> 
> Thoughts?

A slightly reworked version:
a) Do not check console_locked
b) Do not have irq_work fast path for printk_safe buffer
 c) Which lets to union WQ/IRQ work structs - we use only IRQ work for
NMI buffers, and only WQ work for SAFE buffers
 d) And also to refactor the code

From: Sergey Senozhatsky 
Subject: [PATCH] printk/safe: use system_wq to flush printk_safe buffers

---
 kernel/printk/printk_safe.c | 52 ++---
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 3e3c2004bb23..6c8c82cedccb 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "internal.h"
 
@@ -49,7 +50,12 @@ static int printk_safe_irq_ready __read_mostly;
 struct printk_safe_seq_buf {
atomic_tlen;/* length of written data */
atomic_tmessage_lost;
-   struct irq_work work;   /* IRQ work that flushes the buffer */
+   union {
+   /* IRQ work that flushes NMI buffer */
+   struct irq_work irq_flush_work;
+   /* WQ work that flushes SAFE buffer */
+   struct work_struct  wq_flush_work;
+   };
unsigned char   buffer[SAFE_LOG_BUF_LEN];
 };
 
@@ -61,10 +67,18 @@ static DEFINE_PER_CPU(struct printk_safe_seq_buf, 
nmi_print_seq);
 #endif
 
 /* Get flushed in a more safe context. */
-static void queue_flush_work(struct printk_safe_seq_buf *s)
+static void queue_irq_flush_work(struct printk_safe_seq_buf *s)
 {
if (printk_safe_irq_ready)
-   irq_work_queue(>work);
+   irq_work_queue(>irq_flush_work);
+}
+
+static void queue_wq_flush_work(struct printk_safe_seq_buf *s)
+{
+   if (printk_safe_irq_ready)
+   queue_work_on(smp_processor_id(),
+   system_wq,
+   >wq_flush_work);
 }
 
 /*
@@ -89,7 +103,6 @@ static __printf(2, 0) int printk_safe_log_store(struct 
printk_safe_seq_buf *s,
/* The trailing '\0' is not counted into len. */
if (len >= sizeof(s->buffer) - 1) {
atomic_inc(>message_lost);
-   queue_flush_work(s);
return 0;
}
 
@@ -112,7 +125,6 @@ static __printf(2, 0) int printk_safe_log_store(struct 
printk_safe_seq_buf *s,
if (atomic_cmpxchg(>len, len, len + add) != len)
goto again;
 
-   queue_flush_work(s);
return add;
 }
 
@@ -186,12 +198,10 @@ static void report_message_lost(struct 
printk_safe_seq_buf *s)
  * Flush data from the associated per-CPU buffer. The function
  * can be called either via IRQ work or independently.
  */
-static void __printk_safe_flush(struct irq_work *work)
+static void __printk_safe_flush(struct printk_safe_seq_buf *s)
 {
static raw_spinlock_t read_lock =
__RAW_SPIN_LOCK_INITIALIZER(read_lock);
-   struct printk_safe_seq_buf *s =
-   container_of(work, struct printk_safe_seq_buf, work);
unsigned long flags;
size_t len;
int i;
@@ -243,6 +253,22 @@ static void __printk_safe_flush(struct irq_work *work)
raw_spin_unlock_irqrestore(_lock, flags);
 }
 
+static void irq_flush_work_fn(struct irq_work *work)
+{
+   struct printk_safe_seq_buf *s =
+   container_of(work, struct printk_safe_seq_buf, irq_flush_work);
+
+   __printk_safe_flush(s);
+}
+
+static void wq_flush_work_fn(struct work_struct *work)
+{
+   struct printk_safe_seq_buf *s =
+   container_of(work, struct printk_safe_seq_buf, wq_flush_work);
+
+   __printk_safe_flush(s);
+}
+
 /**
  * printk_safe_flush - flush all per-cpu nmi buffers.
  *
@@ -256,9 +282,9 @@ void printk_safe_flush(void)
 
for_each_possible_cpu(cpu) {
 #ifdef CONFIG_PRINTK_NMI
-   __printk_safe_flush(_cpu(nmi_print_seq, cpu).work);
+   __printk_safe_flush(this_cpu_ptr(_print_seq));
 #endif
-   __printk_safe_flush(_cpu(safe_print_seq, cpu).work);
+   __printk_safe_flush(this_cpu_ptr(_print_seq));
}
 }
 
@@ -300,6 +326,7 @@ 

Re: [RFC PATCH] ftrace: Fix depth filtering when func_stack is enabled.

[Nikolay Borisov]

On 23.01.2018 01:16, Steven Rostedt wrote:
> On Mon, 22 Jan 2018 15:50:04 +0200
> Nikolay Borisov  wrote:
> 
> 
>> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
>> index 27f7ad12c4b1..b721f1f3f3c0 100644
>> --- a/kernel/trace/trace_functions.c
>> +++ b/kernel/trace/trace_functions.c
>> @@ -181,14 +181,11 @@ function_stack_trace_call(unsigned long ip, unsigned 
>> long parent_ip,
>>  pc = preempt_count();
>>  trace_function(tr, ip, parent_ip, flags, pc);
>>  /*
>> - * skip over 5 funcs:
>> - *__ftrace_trace_stack,
>> - *__trace_stack,
>> + * skip over 2 funcs:
>>   *function_stack_trace_call
>> - *ftrace_list_func
> 
> Thanks, but this breaks when you are not using ORC unwinder.

Actually I've tested this with the frame_pointer unwinder, I haven't got
ORC to work at all. So this patch fixes the issue where the FP unwinder
prints out shorter stacktraces than required.

> 
>>   *ftrace_call
>>   */
>> -__trace_stack(tr, flags, 5, pc);
>> +__trace_stack(tr, flags, 2, pc);
>>  }
>>  
>>  atomic_dec(>disabled);
> 
> 
> There's a bit of ORC unwinder breakage that I'm still dealing with. I
> also have patches to handle the differences between ORC and FP, in the
> __trace_stack() usages. I'm hoping to have this all fixed by tomorrow,
> as I'll be traveling after that.

Great, please CC me on the patches so that I can test them.

> 
> Thanks!
> 
> -- Steve
> 
> 

Re: [RFC PATCH] ftrace: Fix depth filtering when func_stack is enabled.

[Nikolay Borisov]

On 23.01.2018 01:16, Steven Rostedt wrote:
> On Mon, 22 Jan 2018 15:50:04 +0200
> Nikolay Borisov  wrote:
> 
> 
>> diff --git a/kernel/trace/trace_functions.c b/kernel/trace/trace_functions.c
>> index 27f7ad12c4b1..b721f1f3f3c0 100644
>> --- a/kernel/trace/trace_functions.c
>> +++ b/kernel/trace/trace_functions.c
>> @@ -181,14 +181,11 @@ function_stack_trace_call(unsigned long ip, unsigned 
>> long parent_ip,
>>  pc = preempt_count();
>>  trace_function(tr, ip, parent_ip, flags, pc);
>>  /*
>> - * skip over 5 funcs:
>> - *__ftrace_trace_stack,
>> - *__trace_stack,
>> + * skip over 2 funcs:
>>   *function_stack_trace_call
>> - *ftrace_list_func
> 
> Thanks, but this breaks when you are not using ORC unwinder.

Actually I've tested this with the frame_pointer unwinder, I haven't got
ORC to work at all. So this patch fixes the issue where the FP unwinder
prints out shorter stacktraces than required.

> 
>>   *ftrace_call
>>   */
>> -__trace_stack(tr, flags, 5, pc);
>> +__trace_stack(tr, flags, 2, pc);
>>  }
>>  
>>  atomic_dec(>disabled);
> 
> 
> There's a bit of ORC unwinder breakage that I'm still dealing with. I
> also have patches to handle the differences between ORC and FP, in the
> __trace_stack() usages. I'm hoping to have this all fixed by tomorrow,
> as I'll be traveling after that.

Great, please CC me on the patches so that I can test them.

> 
> Thanks!
> 
> -- Steve
> 
> 

Re: [PATCH 2/5] PCI: Move managed resource alloc to devres

[Ladislav Michl]

On Mon, Jan 22, 2018 at 03:33:52PM -0800, Dmitry Torokhov wrote:
> On Sun, Jan 21, 2018 at 10:15:39PM +0100, Ladislav Michl wrote:
> > devm_pci_remap_cfgspace() is using devm_ioremap_release()
> > devres release function. Move it to devres along with
> > similar PCI functions to allow hiding devm_ioremap_release()
> > from public.
> 
> So we are sharing this function:
> 
> void devm_ioremap_release(struct device *dev, void *res)
> {
>   iounmap(*(void __iomem **)res);
> }
> 
> and we want to hide it, and for that we are moving a lot of PCI-specific
> stuff into lib/devres.c. If anything, I'd say we should move more PCI
> stuff _out_ of lib/devres.c, and if we wait to make local copy and call
> it devm_pci_cfgspace_release() that woudl be fine with me.

Well, that's fine with me too. Will send v2 without all these changes.

> Anyway, up to the maintainers.
> 
> Thanks.

Thank you,
ladis

Re: [PATCH 2/5] PCI: Move managed resource alloc to devres

[Ladislav Michl]

On Mon, Jan 22, 2018 at 03:33:52PM -0800, Dmitry Torokhov wrote:
> On Sun, Jan 21, 2018 at 10:15:39PM +0100, Ladislav Michl wrote:
> > devm_pci_remap_cfgspace() is using devm_ioremap_release()
> > devres release function. Move it to devres along with
> > similar PCI functions to allow hiding devm_ioremap_release()
> > from public.
> 
> So we are sharing this function:
> 
> void devm_ioremap_release(struct device *dev, void *res)
> {
>   iounmap(*(void __iomem **)res);
> }
> 
> and we want to hide it, and for that we are moving a lot of PCI-specific
> stuff into lib/devres.c. If anything, I'd say we should move more PCI
> stuff _out_ of lib/devres.c, and if we wait to make local copy and call
> it devm_pci_cfgspace_release() that woudl be fine with me.

Well, that's fine with me too. Will send v2 without all these changes.

> Anyway, up to the maintainers.
> 
> Thanks.

Thank you,
ladis

Re: [PATCH 4.4 00/53] 4.4.113-stable review

[Sumit Semwal]

Hi Greg,

On 23 January 2018 at 12:09, Greg Kroah-Hartman
 wrote:
> On Tue, Jan 23, 2018 at 01:19:07AM +0530, Naresh Kamboju wrote:
>> On 22 January 2018 at 14:09, Greg Kroah-Hartman
>>  wrote:
>> > This is the start of the stable review cycle for the 4.4.113 release.
>> > There are 53 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 Wed Jan 24 08:38:52 UTC 2018.
>> > 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.113-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
>>
>> Results from Linaro’s test farm.
>> No regressions on arm64, arm and x86_64.
>
> Thanks for letting me know how they all worked.
>
>> NOTE:
>> On arm64 Hikey620 device cpufreq test failed.
>> We are suspecting due to missing config on Hikey620
>> CONFIG_HI6220_MBOX=y
>> You may ignore this now. because it is coming from internal tree.
>> https://git.linaro.org/lkft/arm64-stable-rc.git
>
> Is this new?  That shouldn't have been something that changed in this
> kernel release, maybe a few releases ago?  There has been a push to sync
> some of the hikey patches into the stable tree to make testing like this
> easier for you to do, hopefully it isn't breaking anything...

This is a 'new' one, due to me changing over to a tree with minimal
hikey patches for stable and stable-rc testing. I missed to cherry
pick the hikey mailbox driver patch.
With that corrected, we are back to the same numbers, and the cpufreq
tests also pass.

>
> thanks,
>
> greg k-h

Best,
Sumit.

Re: [PATCH 4.4 00/53] 4.4.113-stable review

[Sumit Semwal]

Hi Greg,

On 23 January 2018 at 12:09, Greg Kroah-Hartman
 wrote:
> On Tue, Jan 23, 2018 at 01:19:07AM +0530, Naresh Kamboju wrote:
>> On 22 January 2018 at 14:09, Greg Kroah-Hartman
>>  wrote:
>> > This is the start of the stable review cycle for the 4.4.113 release.
>> > There are 53 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 Wed Jan 24 08:38:52 UTC 2018.
>> > 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.113-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
>>
>> Results from Linaro’s test farm.
>> No regressions on arm64, arm and x86_64.
>
> Thanks for letting me know how they all worked.
>
>> NOTE:
>> On arm64 Hikey620 device cpufreq test failed.
>> We are suspecting due to missing config on Hikey620
>> CONFIG_HI6220_MBOX=y
>> You may ignore this now. because it is coming from internal tree.
>> https://git.linaro.org/lkft/arm64-stable-rc.git
>
> Is this new?  That shouldn't have been something that changed in this
> kernel release, maybe a few releases ago?  There has been a push to sync
> some of the hikey patches into the stable tree to make testing like this
> easier for you to do, hopefully it isn't breaking anything...

This is a 'new' one, due to me changing over to a tree with minimal
hikey patches for stable and stable-rc testing. I missed to cherry
pick the hikey mailbox driver patch.
With that corrected, we are back to the same numbers, and the cpufreq
tests also pass.

>
> thanks,
>
> greg k-h

Best,
Sumit.

Re: [PATCH] powerpc: pseries: use irq_of_parse_and_map helper

[Michael Ellerman]

Rob Herring  writes:

> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call
> of_irq_parse_and_map instead which does the same thing. This gets us closer
> to making the former 2 functions static.
>
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Rob Herring 
> ---
>  arch/powerpc/platforms/pseries/event_sources.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)

Sorry NAK, this doesn't boot.

> diff --git a/arch/powerpc/platforms/pseries/event_sources.c 
> b/arch/powerpc/platforms/pseries/event_sources.c
> index 6eeb0d4bab61..b0d8c146fe7b 100644
> --- a/arch/powerpc/platforms/pseries/event_sources.c
> +++ b/arch/powerpc/platforms/pseries/event_sources.c
> @@ -16,7 +16,8 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
>   */
>
> -#include 
> +#include 
> +#include 
>
>  #include "pseries.h"
>
> @@ -25,15 +26,11 @@ void request_event_sources_irqs(struct device_node *np,
>   const char *name)
>  {
>   int i, index, count = 0;
> - struct of_phandle_args oirq;
>   unsigned int virqs[16];
>
>   /* First try to do a proper OF tree parsing */
> - for (index = 0; of_irq_parse_one(np, index, ) == 0;
> -  index++) {
> - if (count > 15)
> - break;
> - virqs[count] = irq_create_of_mapping();
> + for (index = 0; count < 16; index++) {
> + virqs[count] = irq_of_parse_and_map(np, index);
>   if (!virqs[count]) {
>   pr_err("event-sources: Unable to allocate "
>  "interrupt number for %pOF\n",

   np);
WARN_ON(1);
} else {
count++;
}
}


Which is an infinite loop if we have less than 16 irqs, and spews the
warning continuously.

Are you trying to remove the low-level routines or is this just a
cleanup?

The patch below works, it loses the error handling if the interrupts
property is corrupt/empty, but that's probably overly paranoid anyway.

cheers

diff --git a/arch/powerpc/platforms/pseries/event_sources.c 
b/arch/powerpc/platforms/pseries/event_sources.c
index 6eeb0d4bab61..25c38077c894 100644
--- a/arch/powerpc/platforms/pseries/event_sources.c
+++ b/arch/powerpc/platforms/pseries/event_sources.c
@@ -16,7 +16,8 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
  */
 
-#include 
+#include 
+#include 
 
 #include "pseries.h"
 
@@ -24,34 +25,16 @@ void request_event_sources_irqs(struct device_node *np,
irq_handler_t handler,
const char *name)
 {
-   int i, index, count = 0;
-   struct of_phandle_args oirq;
-   unsigned int virqs[16];
+   unsigned int virq;
+   int i, rc;
 
-   /* First try to do a proper OF tree parsing */
-   for (index = 0; of_irq_parse_one(np, index, ) == 0;
-index++) {
-   if (count > 15)
+   for (i = 0; i < 16; i++) {
+   virq = irq_of_parse_and_map(np, i);
+   if (!virq)
break;
-   virqs[count] = irq_create_of_mapping();
-   if (!virqs[count]) {
-   pr_err("event-sources: Unable to allocate "
-  "interrupt number for %pOF\n",
-  np);
-   WARN_ON(1);
-   } else {
-   count++;
-   }
-   }
 
-   /* Now request them */
-   for (i = 0; i < count; i++) {
-   if (request_irq(virqs[i], handler, 0, name, NULL)) {
-   pr_err("event-sources: Unable to request interrupt "
-  "%d for %pOF\n", virqs[i], np);
-   WARN_ON(1);
-   return;
-   }
+   rc = request_irq(virq, handler, 0, name, NULL);
+   WARN(rc, "event-sources: Unable to request interrupt %d for 
%pOF\n",
+virq, np);
}
 }
-

Re: [PATCH] powerpc: pseries: use irq_of_parse_and_map helper

[Michael Ellerman]

Rob Herring  writes:

> Instead of calling both of_irq_parse_one and irq_create_of_mapping, call
> of_irq_parse_and_map instead which does the same thing. This gets us closer
> to making the former 2 functions static.
>
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: linuxppc-...@lists.ozlabs.org
> Signed-off-by: Rob Herring 
> ---
>  arch/powerpc/platforms/pseries/event_sources.c | 11 ---
>  1 file changed, 4 insertions(+), 7 deletions(-)

Sorry NAK, this doesn't boot.

> diff --git a/arch/powerpc/platforms/pseries/event_sources.c 
> b/arch/powerpc/platforms/pseries/event_sources.c
> index 6eeb0d4bab61..b0d8c146fe7b 100644
> --- a/arch/powerpc/platforms/pseries/event_sources.c
> +++ b/arch/powerpc/platforms/pseries/event_sources.c
> @@ -16,7 +16,8 @@
>   * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
>   */
>
> -#include 
> +#include 
> +#include 
>
>  #include "pseries.h"
>
> @@ -25,15 +26,11 @@ void request_event_sources_irqs(struct device_node *np,
>   const char *name)
>  {
>   int i, index, count = 0;
> - struct of_phandle_args oirq;
>   unsigned int virqs[16];
>
>   /* First try to do a proper OF tree parsing */
> - for (index = 0; of_irq_parse_one(np, index, ) == 0;
> -  index++) {
> - if (count > 15)
> - break;
> - virqs[count] = irq_create_of_mapping();
> + for (index = 0; count < 16; index++) {
> + virqs[count] = irq_of_parse_and_map(np, index);
>   if (!virqs[count]) {
>   pr_err("event-sources: Unable to allocate "
>  "interrupt number for %pOF\n",

   np);
WARN_ON(1);
} else {
count++;
}
}


Which is an infinite loop if we have less than 16 irqs, and spews the
warning continuously.

Are you trying to remove the low-level routines or is this just a
cleanup?

The patch below works, it loses the error handling if the interrupts
property is corrupt/empty, but that's probably overly paranoid anyway.

cheers

diff --git a/arch/powerpc/platforms/pseries/event_sources.c 
b/arch/powerpc/platforms/pseries/event_sources.c
index 6eeb0d4bab61..25c38077c894 100644
--- a/arch/powerpc/platforms/pseries/event_sources.c
+++ b/arch/powerpc/platforms/pseries/event_sources.c
@@ -16,7 +16,8 @@
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
  */
 
-#include 
+#include 
+#include 
 
 #include "pseries.h"
 
@@ -24,34 +25,16 @@ void request_event_sources_irqs(struct device_node *np,
irq_handler_t handler,
const char *name)
 {
-   int i, index, count = 0;
-   struct of_phandle_args oirq;
-   unsigned int virqs[16];
+   unsigned int virq;
+   int i, rc;
 
-   /* First try to do a proper OF tree parsing */
-   for (index = 0; of_irq_parse_one(np, index, ) == 0;
-index++) {
-   if (count > 15)
+   for (i = 0; i < 16; i++) {
+   virq = irq_of_parse_and_map(np, i);
+   if (!virq)
break;
-   virqs[count] = irq_create_of_mapping();
-   if (!virqs[count]) {
-   pr_err("event-sources: Unable to allocate "
-  "interrupt number for %pOF\n",
-  np);
-   WARN_ON(1);
-   } else {
-   count++;
-   }
-   }
 
-   /* Now request them */
-   for (i = 0; i < count; i++) {
-   if (request_irq(virqs[i], handler, 0, name, NULL)) {
-   pr_err("event-sources: Unable to request interrupt "
-  "%d for %pOF\n", virqs[i], np);
-   WARN_ON(1);
-   return;
-   }
+   rc = request_irq(virq, handler, 0, name, NULL);
+   WARN(rc, "event-sources: Unable to request interrupt %d for 
%pOF\n",
+virq, np);
}
 }
-

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

Hello,

On (01/21/18 23:15), Sergey Senozhatsky wrote:
[..]
> we have printk recursion from console drivers. it's redirected to
> printk_safe and we queue an IRQ work to flush the buffer
> 
>  printk
>   console_unlock
>call_console_drivers
> net_console
>  printk
>   printk_save -> irq_work queue
> 
> now console_unlock() enables local IRQs, we have the printk_safe
> flush. but printk_safe flush does not call into the console_unlock(),
> it uses printk_deferred() version of printk
> 
> IRQ work
> 
>  prink_safe_flush
>   printk_deferred -> irq_work queue
> 
> 
> so we schedule another IRQ work (deferred printk work), which eventually
> tries to lock console_sem
> 
> IRQ work
>  wake_up_klogd_work_func()
>   if (console_trylock())
>console_unlock()

Why do we even use irq_work for printk_safe?

Okay... So, how about this. For printk_safe we use system_wq for flushing.
IOW, we flush from a task running exactly on the same CPU which hit printk
recursion, not from IRQ. From vprintk_safe() recursion, we queue work on
*that* CPU. Which gives us the following thing: if CPU stuck in
console_unlock() loop with preemption disabled, then system_wq does not
schedule on that CPU and we, thus, don't flush printk_safe buffer from that
CPU. But if CPU can reschedule, then we are kinda OK to flush printk_safe
buffer, printing extra messages from that CPU will not lock it up, because
it's in preemptible context.

Thoughts?


Something like this:

From: Sergey Senozhatsky 
Subject: [PATCH] printk/safe: use slowpath flush for printk_safe

---
 kernel/printk/printk_safe.c | 53 -
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 3e3c2004bb23..c641853a5fa9 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "internal.h"
 
@@ -50,6 +52,7 @@ struct printk_safe_seq_buf {
atomic_tlen;/* length of written data */
atomic_tmessage_lost;
struct irq_work work;   /* IRQ work that flushes the buffer */
+   struct work_struct  slowpath_flush_work;
unsigned char   buffer[SAFE_LOG_BUF_LEN];
 };
 
@@ -61,12 +64,20 @@ static DEFINE_PER_CPU(struct printk_safe_seq_buf, 
nmi_print_seq);
 #endif
 
 /* Get flushed in a more safe context. */
-static void queue_flush_work(struct printk_safe_seq_buf *s)
+static void queue_irq_flush_work(struct printk_safe_seq_buf *s)
 {
if (printk_safe_irq_ready)
irq_work_queue(>work);
 }
 
+static void queue_slowpath_flush_work(struct printk_safe_seq_buf *s)
+{
+   if (printk_safe_irq_ready)
+   queue_work_on(smp_processor_id(),
+   system_wq,
+   >slowpath_flush_work);
+}
+
 /*
  * Add a message to per-CPU context-dependent buffer. NMI and printk-safe
  * have dedicated buffers, because otherwise printk-safe preempted by
@@ -89,7 +100,7 @@ static __printf(2, 0) int printk_safe_log_store(struct 
printk_safe_seq_buf *s,
/* The trailing '\0' is not counted into len. */
if (len >= sizeof(s->buffer) - 1) {
atomic_inc(>message_lost);
-   queue_flush_work(s);
+   queue_irq_flush_work(s);
return 0;
}
 
@@ -112,7 +123,6 @@ static __printf(2, 0) int printk_safe_log_store(struct 
printk_safe_seq_buf *s,
if (atomic_cmpxchg(>len, len, len + add) != len)
goto again;
 
-   queue_flush_work(s);
return add;
 }
 
@@ -243,6 +253,35 @@ static void __printk_safe_flush(struct irq_work *work)
raw_spin_unlock_irqrestore(_lock, flags);
 }
 
+/* NMI buffers are always flushed */
+static void flush_nmi_buffer(struct irq_work *work)
+{
+   __printk_safe_flush(work);
+}
+
+/* printk_safe buffers flushing, on the contrary, can be postponed */
+static void flush_printk_safe_buffer(struct irq_work *work)
+{
+   struct printk_safe_seq_buf *s =
+   container_of(work, struct printk_safe_seq_buf, work);
+
+   if (is_console_locked()) {
+   queue_slowpath_flush_work(s);
+   return;
+   }
+
+   __printk_safe_flush(work);
+}
+
+static void slowpath_flush_work_fn(struct work_struct *work)
+{
+   struct printk_safe_seq_buf *s =
+   container_of(work, struct printk_safe_seq_buf,
+   slowpath_flush_work);
+
+   __printk_safe_flush(>work);
+}
+
 /**
  * printk_safe_flush - flush all per-cpu nmi buffers.
  *
@@ -300,6 +339,7 @@ static __printf(1, 0) int vprintk_nmi(const char *fmt, 
va_list args)
 {
struct printk_safe_seq_buf *s = this_cpu_ptr(_print_seq);
 
+   queue_irq_flush_work(s);
return printk_safe_log_store(s, fmt, args);
 }
 
@@ -343,6 +383,7 @@ 

Re: [PATCH v5 0/2] printk: Console owner and waiter logic cleanup

[Sergey Senozhatsky]

Hello,

On (01/21/18 23:15), Sergey Senozhatsky wrote:
[..]
> we have printk recursion from console drivers. it's redirected to
> printk_safe and we queue an IRQ work to flush the buffer
> 
>  printk
>   console_unlock
>call_console_drivers
> net_console
>  printk
>   printk_save -> irq_work queue
> 
> now console_unlock() enables local IRQs, we have the printk_safe
> flush. but printk_safe flush does not call into the console_unlock(),
> it uses printk_deferred() version of printk
> 
> IRQ work
> 
>  prink_safe_flush
>   printk_deferred -> irq_work queue
> 
> 
> so we schedule another IRQ work (deferred printk work), which eventually
> tries to lock console_sem
> 
> IRQ work
>  wake_up_klogd_work_func()
>   if (console_trylock())
>console_unlock()

Why do we even use irq_work for printk_safe?

Okay... So, how about this. For printk_safe we use system_wq for flushing.
IOW, we flush from a task running exactly on the same CPU which hit printk
recursion, not from IRQ. From vprintk_safe() recursion, we queue work on
*that* CPU. Which gives us the following thing: if CPU stuck in
console_unlock() loop with preemption disabled, then system_wq does not
schedule on that CPU and we, thus, don't flush printk_safe buffer from that
CPU. But if CPU can reschedule, then we are kinda OK to flush printk_safe
buffer, printing extra messages from that CPU will not lock it up, because
it's in preemptible context.

Thoughts?


Something like this:

From: Sergey Senozhatsky 
Subject: [PATCH] printk/safe: use slowpath flush for printk_safe

---
 kernel/printk/printk_safe.c | 53 -
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 3e3c2004bb23..c641853a5fa9 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "internal.h"
 
@@ -50,6 +52,7 @@ struct printk_safe_seq_buf {
atomic_tlen;/* length of written data */
atomic_tmessage_lost;
struct irq_work work;   /* IRQ work that flushes the buffer */
+   struct work_struct  slowpath_flush_work;
unsigned char   buffer[SAFE_LOG_BUF_LEN];
 };
 
@@ -61,12 +64,20 @@ static DEFINE_PER_CPU(struct printk_safe_seq_buf, 
nmi_print_seq);
 #endif
 
 /* Get flushed in a more safe context. */
-static void queue_flush_work(struct printk_safe_seq_buf *s)
+static void queue_irq_flush_work(struct printk_safe_seq_buf *s)
 {
if (printk_safe_irq_ready)
irq_work_queue(>work);
 }
 
+static void queue_slowpath_flush_work(struct printk_safe_seq_buf *s)
+{
+   if (printk_safe_irq_ready)
+   queue_work_on(smp_processor_id(),
+   system_wq,
+   >slowpath_flush_work);
+}
+
 /*
  * Add a message to per-CPU context-dependent buffer. NMI and printk-safe
  * have dedicated buffers, because otherwise printk-safe preempted by
@@ -89,7 +100,7 @@ static __printf(2, 0) int printk_safe_log_store(struct 
printk_safe_seq_buf *s,
/* The trailing '\0' is not counted into len. */
if (len >= sizeof(s->buffer) - 1) {
atomic_inc(>message_lost);
-   queue_flush_work(s);
+   queue_irq_flush_work(s);
return 0;
}
 
@@ -112,7 +123,6 @@ static __printf(2, 0) int printk_safe_log_store(struct 
printk_safe_seq_buf *s,
if (atomic_cmpxchg(>len, len, len + add) != len)
goto again;
 
-   queue_flush_work(s);
return add;
 }
 
@@ -243,6 +253,35 @@ static void __printk_safe_flush(struct irq_work *work)
raw_spin_unlock_irqrestore(_lock, flags);
 }
 
+/* NMI buffers are always flushed */
+static void flush_nmi_buffer(struct irq_work *work)
+{
+   __printk_safe_flush(work);
+}
+
+/* printk_safe buffers flushing, on the contrary, can be postponed */
+static void flush_printk_safe_buffer(struct irq_work *work)
+{
+   struct printk_safe_seq_buf *s =
+   container_of(work, struct printk_safe_seq_buf, work);
+
+   if (is_console_locked()) {
+   queue_slowpath_flush_work(s);
+   return;
+   }
+
+   __printk_safe_flush(work);
+}
+
+static void slowpath_flush_work_fn(struct work_struct *work)
+{
+   struct printk_safe_seq_buf *s =
+   container_of(work, struct printk_safe_seq_buf,
+   slowpath_flush_work);
+
+   __printk_safe_flush(>work);
+}
+
 /**
  * printk_safe_flush - flush all per-cpu nmi buffers.
  *
@@ -300,6 +339,7 @@ static __printf(1, 0) int vprintk_nmi(const char *fmt, 
va_list args)
 {
struct printk_safe_seq_buf *s = this_cpu_ptr(_print_seq);
 
+   queue_irq_flush_work(s);
return printk_safe_log_store(s, fmt, args);
 }
 
@@ -343,6 +383,7 @@ static __printf(1, 0) int 

Re: [PATCH 4.4 00/53] 4.4.113-stable review

[Greg Kroah-Hartman]

On Tue, Jan 23, 2018 at 01:19:07AM +0530, Naresh Kamboju wrote:
> On 22 January 2018 at 14:09, Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 4.4.113 release.
> > There are 53 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 Wed Jan 24 08:38:52 UTC 2018.
> > 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.113-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
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Thanks for letting me know how they all worked.

> NOTE:
> On arm64 Hikey620 device cpufreq test failed.
> We are suspecting due to missing config on Hikey620
> CONFIG_HI6220_MBOX=y
> You may ignore this now. because it is coming from internal tree.
> https://git.linaro.org/lkft/arm64-stable-rc.git

Is this new?  That shouldn't have been something that changed in this
kernel release, maybe a few releases ago?  There has been a push to sync
some of the hikey patches into the stable tree to make testing like this
easier for you to do, hopefully it isn't breaking anything...

thanks,

greg k-h

Re: [PATCH 4.4 00/53] 4.4.113-stable review

[Greg Kroah-Hartman]

On Tue, Jan 23, 2018 at 01:19:07AM +0530, Naresh Kamboju wrote:
> On 22 January 2018 at 14:09, Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 4.4.113 release.
> > There are 53 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 Wed Jan 24 08:38:52 UTC 2018.
> > 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.113-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
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm and x86_64.

Thanks for letting me know how they all worked.

> NOTE:
> On arm64 Hikey620 device cpufreq test failed.
> We are suspecting due to missing config on Hikey620
> CONFIG_HI6220_MBOX=y
> You may ignore this now. because it is coming from internal tree.
> https://git.linaro.org/lkft/arm64-stable-rc.git

Is this new?  That shouldn't have been something that changed in this
kernel release, maybe a few releases ago?  There has been a push to sync
some of the hikey patches into the stable tree to make testing like this
easier for you to do, hopefully it isn't breaking anything...

thanks,

greg k-h

Re: [PATCH 4.4 00/53] 4.4.113-stable review

[Greg Kroah-Hartman]

On Mon, Jan 22, 2018 at 01:07:27PM -0700, Shuah Khan wrote:
> On 01/22/2018 01:39 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.113 release.
> > There are 53 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 Wed Jan 24 08:38:52 UTC 2018.
> > 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.113-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 for testing all 3 of these and letting me know.

greg k-h

Re: [PATCH 4.4 00/53] 4.4.113-stable review

[Greg Kroah-Hartman]

On Mon, Jan 22, 2018 at 01:07:27PM -0700, Shuah Khan wrote:
> On 01/22/2018 01:39 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.113 release.
> > There are 53 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 Wed Jan 24 08:38:52 UTC 2018.
> > 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.113-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 for testing all 3 of these and letting me know.

greg k-h

Re: [PATCH v10 01/27] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

[Ram Pai]

Andrew,

Please apply the following two patches to your tree.

[PATCH v10 01/27] mm, powerpc, x86: define VM_PKEY_BITx bits if 
CONFIG_ARCH_HAS_PKEYS is enabled
[PATCH v10 02/27] mm, powerpc, x86: introduce an additional vma bit for powerpc 
pkey

I have not heard any complaints on these changes. 
Dave Hansen had comments/suggestions in the initial revisions, which 
have been incorporated.

Michael Ellermen has accepted the rest of the powerpc related patches 
in this series.

Thanks,
RP




On Thu, Jan 18, 2018 at 05:50:22PM -0800, Ram Pai wrote:
> VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> is enabled. Powerpc also needs these bits. Hence lets define the
> VM_PKEY_BITx bits for any architecture that enables
> CONFIG_ARCH_HAS_PKEYS.
> 
> Signed-off-by: Ram Pai 
> ---
>  fs/proc/task_mmu.c |4 ++--
>  include/linux/mm.h |9 +
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 339e4c1..b139617 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -674,13 +674,13 @@ static void show_smap_vma_flags(struct seq_file *m, 
> struct vm_area_struct *vma)
>   [ilog2(VM_MERGEABLE)]   = "mg",
>   [ilog2(VM_UFFD_MISSING)]= "um",
>   [ilog2(VM_UFFD_WP)] = "uw",
> -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> +#ifdef CONFIG_ARCH_HAS_PKEYS
>   /* These come out via ProtectionKey: */
>   [ilog2(VM_PKEY_BIT0)]   = "",
>   [ilog2(VM_PKEY_BIT1)]   = "",
>   [ilog2(VM_PKEY_BIT2)]   = "",
>   [ilog2(VM_PKEY_BIT3)]   = "",
> -#endif
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
>   };
>   size_t i;
>  
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ea818ff..01381d3 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -228,15 +228,16 @@ extern int overcommit_kbytes_handler(struct ctl_table 
> *, int, void __user *,
>  #define VM_HIGH_ARCH_4   BIT(VM_HIGH_ARCH_BIT_4)
>  #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */
>  
> -#if defined(CONFIG_X86)
> -# define VM_PAT  VM_ARCH_1   /* PAT reserves whole VMA at 
> once (x86) */
> -#if defined (CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS)
> +#ifdef CONFIG_ARCH_HAS_PKEYS
>  # define VM_PKEY_SHIFT   VM_HIGH_ARCH_BIT_0
>  # define VM_PKEY_BIT0VM_HIGH_ARCH_0  /* A protection key is a 4-bit 
> value */
>  # define VM_PKEY_BIT1VM_HIGH_ARCH_1
>  # define VM_PKEY_BIT2VM_HIGH_ARCH_2
>  # define VM_PKEY_BIT3VM_HIGH_ARCH_3
> -#endif
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
> +
> +#if defined(CONFIG_X86)
> +# define VM_PAT  VM_ARCH_1   /* PAT reserves whole VMA at 
> once (x86) */
>  #elif defined(CONFIG_PPC)
>  # define VM_SAO  VM_ARCH_1   /* Strong Access Ordering 
> (powerpc) */
>  #elif defined(CONFIG_PARISC)
> -- 
> 1.7.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linux-2Dmm.org_=DwIBAg=jf_iaSHvJObTbx-siA1ZOg=m-UrKChQVkZtnPpjbF6YY99NbT8FBByQ-E-ygV8luxw=PsCrC-HVeq8M98fNireZs4GUBJvMwNZme7wZ1YdjMqs=V90akzFmL1g-sNEcgmcUn_XJgJ8EaYmmsAS3AcVYScw=
>  .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Ram Pai

Re: [PATCH v10 01/27] mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled

[Ram Pai]

Andrew,

Please apply the following two patches to your tree.

[PATCH v10 01/27] mm, powerpc, x86: define VM_PKEY_BITx bits if 
CONFIG_ARCH_HAS_PKEYS is enabled
[PATCH v10 02/27] mm, powerpc, x86: introduce an additional vma bit for powerpc 
pkey

I have not heard any complaints on these changes. 
Dave Hansen had comments/suggestions in the initial revisions, which 
have been incorporated.

Michael Ellermen has accepted the rest of the powerpc related patches 
in this series.

Thanks,
RP




On Thu, Jan 18, 2018 at 05:50:22PM -0800, Ram Pai wrote:
> VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> is enabled. Powerpc also needs these bits. Hence lets define the
> VM_PKEY_BITx bits for any architecture that enables
> CONFIG_ARCH_HAS_PKEYS.
> 
> Signed-off-by: Ram Pai 
> ---
>  fs/proc/task_mmu.c |4 ++--
>  include/linux/mm.h |9 +
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 339e4c1..b139617 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -674,13 +674,13 @@ static void show_smap_vma_flags(struct seq_file *m, 
> struct vm_area_struct *vma)
>   [ilog2(VM_MERGEABLE)]   = "mg",
>   [ilog2(VM_UFFD_MISSING)]= "um",
>   [ilog2(VM_UFFD_WP)] = "uw",
> -#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> +#ifdef CONFIG_ARCH_HAS_PKEYS
>   /* These come out via ProtectionKey: */
>   [ilog2(VM_PKEY_BIT0)]   = "",
>   [ilog2(VM_PKEY_BIT1)]   = "",
>   [ilog2(VM_PKEY_BIT2)]   = "",
>   [ilog2(VM_PKEY_BIT3)]   = "",
> -#endif
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
>   };
>   size_t i;
>  
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index ea818ff..01381d3 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -228,15 +228,16 @@ extern int overcommit_kbytes_handler(struct ctl_table 
> *, int, void __user *,
>  #define VM_HIGH_ARCH_4   BIT(VM_HIGH_ARCH_BIT_4)
>  #endif /* CONFIG_ARCH_USES_HIGH_VMA_FLAGS */
>  
> -#if defined(CONFIG_X86)
> -# define VM_PAT  VM_ARCH_1   /* PAT reserves whole VMA at 
> once (x86) */
> -#if defined (CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS)
> +#ifdef CONFIG_ARCH_HAS_PKEYS
>  # define VM_PKEY_SHIFT   VM_HIGH_ARCH_BIT_0
>  # define VM_PKEY_BIT0VM_HIGH_ARCH_0  /* A protection key is a 4-bit 
> value */
>  # define VM_PKEY_BIT1VM_HIGH_ARCH_1
>  # define VM_PKEY_BIT2VM_HIGH_ARCH_2
>  # define VM_PKEY_BIT3VM_HIGH_ARCH_3
> -#endif
> +#endif /* CONFIG_ARCH_HAS_PKEYS */
> +
> +#if defined(CONFIG_X86)
> +# define VM_PAT  VM_ARCH_1   /* PAT reserves whole VMA at 
> once (x86) */
>  #elif defined(CONFIG_PPC)
>  # define VM_SAO  VM_ARCH_1   /* Strong Access Ordering 
> (powerpc) */
>  #elif defined(CONFIG_PARISC)
> -- 
> 1.7.1
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linux-2Dmm.org_=DwIBAg=jf_iaSHvJObTbx-siA1ZOg=m-UrKChQVkZtnPpjbF6YY99NbT8FBByQ-E-ygV8luxw=PsCrC-HVeq8M98fNireZs4GUBJvMwNZme7wZ1YdjMqs=V90akzFmL1g-sNEcgmcUn_XJgJ8EaYmmsAS3AcVYScw=
>  .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Ram Pai

Re: [PATCH 4.14 00/89] 4.14.15-stable review

[Greg Kroah-Hartman]

On Mon, Jan 22, 2018 at 11:10:20AM -0800, Guenter Roeck wrote:
> On Mon, Jan 22, 2018 at 09:44:40AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.15 release.
> > There are 89 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.
> > 
> 
> Note: This is for v4.14.14-91-gf7e703b.
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 126 pass: 126 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.14 00/89] 4.14.15-stable review

[Greg Kroah-Hartman]

On Mon, Jan 22, 2018 at 11:10:20AM -0800, Guenter Roeck wrote:
> On Mon, Jan 22, 2018 at 09:44:40AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.15 release.
> > There are 89 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.
> > 
> 
> Note: This is for v4.14.14-91-gf7e703b.
> 
> Build results:
>   total: 145 pass: 145 fail: 0
> Qemu test results:
>   total: 126 pass: 126 fail: 0
> 
> Details are available at http://kerneltests.org/builders.

Thanks for testing all of these and letting me know.

greg k-h

[PATCH] staging: lustre: lnet/selftest: fix compile error on UP build

[NeilBrown]

When compiled without CONFIG_SMP, we get a compile error
as ->ctb_parts is not defined.

There is already a function, cfs_cpt_cpumask(), which will get the
cpumask we need, and which handles the UP case by returning a NULL pointer.
So use that and handle NULL.
Also avoid the #ifdef by allocating a cpumask_var and copying
into it, rather than sharing the mask.

Reported-by: kbuild test robot 
Fixes: 6106c0f82481 ("staging: lustre: lnet: convert selftest to use 
workqueues")
Signed-off-by: NeilBrown ctb_parts[i].cpt_cpumask;
-   #else
-   cpumask_copy(attrs.cpumask, 
lnet_cpt_table()->ctb_parts[i].cpt_cpumask);
-   #endif
-   attrs.no_numa = false;
-   apply_workqueue_attrs(lst_test_wq[i], );
+
+   if (mask && alloc_cpumask_var(, GFP_KERNEL)) {
+   cpumask_copy(attrs.cpumask, *mask);
+   apply_workqueue_attrs(lst_test_wq[i], );
+   free_cpumask_var(attrs.cpumask);
+   }
}
 
rc = srpc_startup();
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

[PATCH] staging: lustre: lnet/selftest: fix compile error on UP build

[NeilBrown]

When compiled without CONFIG_SMP, we get a compile error
as ->ctb_parts is not defined.

There is already a function, cfs_cpt_cpumask(), which will get the
cpumask we need, and which handles the UP case by returning a NULL pointer.
So use that and handle NULL.
Also avoid the #ifdef by allocating a cpumask_var and copying
into it, rather than sharing the mask.

Reported-by: kbuild test robot 
Fixes: 6106c0f82481 ("staging: lustre: lnet: convert selftest to use 
workqueues")
Signed-off-by: NeilBrown ctb_parts[i].cpt_cpumask;
-   #else
-   cpumask_copy(attrs.cpumask, 
lnet_cpt_table()->ctb_parts[i].cpt_cpumask);
-   #endif
-   attrs.no_numa = false;
-   apply_workqueue_attrs(lst_test_wq[i], );
+
+   if (mask && alloc_cpumask_var(, GFP_KERNEL)) {
+   cpumask_copy(attrs.cpumask, *mask);
+   apply_workqueue_attrs(lst_test_wq[i], );
+   free_cpumask_var(attrs.cpumask);
+   }
}
 
rc = srpc_startup();
-- 
2.14.0.rc0.dirty



signature.asc
Description: PGP signature

Re: [PATCH v2] mkfs.f2fs: expand scalability of nat bitmap

[Chao Yu]

On 2018/1/23 7:00, Jaegeuk Kim wrote:
> On 01/17, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2018/1/17 8:47, Jaegeuk Kim wrote:
>>> Hi Chao,
>>>
>>> On 01/15, Chao Yu wrote:
 Previously, our total node number (nat_bitmap) and total nat segment count
 will not monotonously increase along with image size, and max nat_bitmap 
 size
 is limited by "CHECKSUM_OFFSET - sizeof(struct f2fs_checkpoint) + 1", it is
 with bad scalability when user wants to create more inode/node in larger 
 image.

 So this patch tries to relieve the limitation, by default, limitting total 
 nat
 entry number with 20% of total block number.

 Before:
 image_size(GB) nat_bitmap  sit_bitmap  nat_segment 
 sit_segment
 16 383664  36  2
 32 383664  72  2
 64 3772128 116 4
 1283708192 114 6
 2563580320 110 10
>>
>> As you see, nat_segment count will reduce when image size increases
>> starting from 64GB, that means nat segment count will not monotonously
>> increase when image size is increasing, so it would be better to active
>> this when image size is larger than 32GB?
>>
>> IMO, configuring basic nid ratio to fixed value like ext4 ("free inode" :
>> "free block" is about 1 : 4) would be better:
>> a. It will be easy for user to predict nid count or nat segment count with
>> fix-sized image;
>> b. If user wants to reserve more nid count, we can support -N option in
>> mkfs.f2fs to specify total nid count as user wish.
> 
> My concern is about a CTS failure in terms of # of free inodes.

You mean testSaneInodes()?

final long maxsize = stat.f_blocks * stat.f_frsize;
final long maxInodes = maxsize / 4096;
final long minsize = stat.f_bavail * stat.f_frsize;
final long minInodes = minsize / 32768;

The range is about [1/8, 1], so our 20% threshold can just let it passed,
right?

Thanks,

> 
> Thanks,
> 
>>
>> How do you think?
>>
>> Thanks,
>>
 5123260640 100 20
 1024   2684121682  38
 2048   1468243244  76
 4096   39004800120 150

 After:
 image_size(GB) nat_bitmap  sit_bitmap  nat_segment 
 sit_segment
 16 256 64  8   2
 32 512 64  16  2
 64 960 128 30  4
 1281856192 58  6
 2563712320 116 10
>>>
>>> Can we activate this, if size is larger than 256GB or something around that?
>>>
>>> Thanks,
>>>
 5127424640 232 20
 1024   14787   1216462 38
 2048   29504   2432922 76
 4096   59008   48001844150

 Signed-off-by: Chao Yu 
 ---
 v2:
 - add CP_LARGE_NAT_BITMAP_FLAG flag to indicate new layout of nat/sit 
 bitmap.
  fsck/f2fs.h| 19 +--
  fsck/resize.c  | 35 +--
  include/f2fs_fs.h  |  8 ++--
  lib/libf2fs.c  |  1 +
  mkfs/f2fs_format.c | 45 +++--
  5 files changed, 60 insertions(+), 48 deletions(-)

 diff --git a/fsck/f2fs.h b/fsck/f2fs.h
 index f5970d9dafc0..8a5ce365282d 100644
 --- a/fsck/f2fs.h
 +++ b/fsck/f2fs.h
 @@ -239,6 +239,12 @@ static inline unsigned int ofs_of_node(struct 
 f2fs_node *node_blk)
return flag >> OFFSET_BIT_SHIFT;
  }
  
 +static inline bool is_set_ckpt_flags(struct f2fs_checkpoint *cp, unsigned 
 int f)
 +{
 +  unsigned int ckpt_flags = le32_to_cpu(cp->ckpt_flags);
 +  return ckpt_flags & f ? 1 : 0;
 +}
 +
  static inline unsigned long __bitmap_size(struct f2fs_sb_info *sbi, int 
 flag)
  {
struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
 @@ -256,6 +262,13 @@ static inline void *__bitmap_ptr(struct f2fs_sb_info 
 *sbi, int flag)
  {
struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
int offset;
 +
 +  if (is_set_ckpt_flags(ckpt, CP_LARGE_NAT_BITMAP_FLAG)) {
 +  offset = (flag == SIT_BITMAP) ?
 +  le32_to_cpu(ckpt->nat_ver_bitmap_bytesize) : 0;
 +  return >sit_nat_version_bitmap + offset;
 +  }
 +
if 

Re: [PATCH v2] mkfs.f2fs: expand scalability of nat bitmap

[Chao Yu]

On 2018/1/23 7:00, Jaegeuk Kim wrote:
> On 01/17, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2018/1/17 8:47, Jaegeuk Kim wrote:
>>> Hi Chao,
>>>
>>> On 01/15, Chao Yu wrote:
 Previously, our total node number (nat_bitmap) and total nat segment count
 will not monotonously increase along with image size, and max nat_bitmap 
 size
 is limited by "CHECKSUM_OFFSET - sizeof(struct f2fs_checkpoint) + 1", it is
 with bad scalability when user wants to create more inode/node in larger 
 image.

 So this patch tries to relieve the limitation, by default, limitting total 
 nat
 entry number with 20% of total block number.

 Before:
 image_size(GB) nat_bitmap  sit_bitmap  nat_segment 
 sit_segment
 16 383664  36  2
 32 383664  72  2
 64 3772128 116 4
 1283708192 114 6
 2563580320 110 10
>>
>> As you see, nat_segment count will reduce when image size increases
>> starting from 64GB, that means nat segment count will not monotonously
>> increase when image size is increasing, so it would be better to active
>> this when image size is larger than 32GB?
>>
>> IMO, configuring basic nid ratio to fixed value like ext4 ("free inode" :
>> "free block" is about 1 : 4) would be better:
>> a. It will be easy for user to predict nid count or nat segment count with
>> fix-sized image;
>> b. If user wants to reserve more nid count, we can support -N option in
>> mkfs.f2fs to specify total nid count as user wish.
> 
> My concern is about a CTS failure in terms of # of free inodes.

You mean testSaneInodes()?

final long maxsize = stat.f_blocks * stat.f_frsize;
final long maxInodes = maxsize / 4096;
final long minsize = stat.f_bavail * stat.f_frsize;
final long minInodes = minsize / 32768;

The range is about [1/8, 1], so our 20% threshold can just let it passed,
right?

Thanks,

> 
> Thanks,
> 
>>
>> How do you think?
>>
>> Thanks,
>>
 5123260640 100 20
 1024   2684121682  38
 2048   1468243244  76
 4096   39004800120 150

 After:
 image_size(GB) nat_bitmap  sit_bitmap  nat_segment 
 sit_segment
 16 256 64  8   2
 32 512 64  16  2
 64 960 128 30  4
 1281856192 58  6
 2563712320 116 10
>>>
>>> Can we activate this, if size is larger than 256GB or something around that?
>>>
>>> Thanks,
>>>
 5127424640 232 20
 1024   14787   1216462 38
 2048   29504   2432922 76
 4096   59008   48001844150

 Signed-off-by: Chao Yu 
 ---
 v2:
 - add CP_LARGE_NAT_BITMAP_FLAG flag to indicate new layout of nat/sit 
 bitmap.
  fsck/f2fs.h| 19 +--
  fsck/resize.c  | 35 +--
  include/f2fs_fs.h  |  8 ++--
  lib/libf2fs.c  |  1 +
  mkfs/f2fs_format.c | 45 +++--
  5 files changed, 60 insertions(+), 48 deletions(-)

 diff --git a/fsck/f2fs.h b/fsck/f2fs.h
 index f5970d9dafc0..8a5ce365282d 100644
 --- a/fsck/f2fs.h
 +++ b/fsck/f2fs.h
 @@ -239,6 +239,12 @@ static inline unsigned int ofs_of_node(struct 
 f2fs_node *node_blk)
return flag >> OFFSET_BIT_SHIFT;
  }
  
 +static inline bool is_set_ckpt_flags(struct f2fs_checkpoint *cp, unsigned 
 int f)
 +{
 +  unsigned int ckpt_flags = le32_to_cpu(cp->ckpt_flags);
 +  return ckpt_flags & f ? 1 : 0;
 +}
 +
  static inline unsigned long __bitmap_size(struct f2fs_sb_info *sbi, int 
 flag)
  {
struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
 @@ -256,6 +262,13 @@ static inline void *__bitmap_ptr(struct f2fs_sb_info 
 *sbi, int flag)
  {
struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
int offset;
 +
 +  if (is_set_ckpt_flags(ckpt, CP_LARGE_NAT_BITMAP_FLAG)) {
 +  offset = (flag == SIT_BITMAP) ?
 +  le32_to_cpu(ckpt->nat_ver_bitmap_bytesize) : 0;
 +  return >sit_nat_version_bitmap + offset;
 +  }
 +
if (le32_to_cpu(F2FS_RAW_SUPER(sbi)->cp_payload) > 0) {

Re: [PATCH] mm: Pin address_space before dereferencing it while isolating an LRU page

[Minchan Kim]

On Thu, Jan 04, 2018 at 10:25:12AM +, Mel Gorman wrote:
> Minchan Kim asked the following question -- what locks protects
> address_space destroying when race happens between inode trauncation and
> __isolate_lru_page? Jan Kara clarified by describing the race as follows
> 
> CPU1CPU2
> 
> truncate(inode) __isolate_lru_page()
>   ...
>   truncate_inode_page(mapping, page);
> delete_from_page_cache(page)
>   spin_lock_irqsave(>tree_lock, flags);
> __delete_from_page_cache(page, NULL)
>   page_cache_tree_delete(..)
> ...   mapping = 
> page_mapping(page);
> page->mapping = NULL;
> ...
>   spin_unlock_irqrestore(>tree_lock, flags);
>   page_cache_free_page(mapping, page)
> put_page(page)
>   if (put_page_testzero(page)) -> false
> - inode now has no pages and can be freed including embedded address_space
> 
>   if (mapping && 
> !mapping->a_ops->migratepage)
> - we've dereferenced mapping which is potentially already free.
> 
> The race is theoritically possible but unlikely. Before the
> delete_from_page_cache, truncate_cleanup_page is called so the page is
> likely to be !PageDirty or PageWriteback which gets skipped by the only
> caller that checks the mappping in __isolate_lru_page. Even if the race
> occurs, a substantial amount of work has to happen during a tiny window
> with no preemption but it could potentially be done using a virtual machine
> to artifically slow one CPU or halt it during the critical window.
> 
> This patch should eliminate the race with truncation by try-locking the page
> before derefencing mapping and aborting if the lock was not acquired. There
> was a suggestion from Huang Ying to use RCU as a side-effect to prevent
> mapping being freed. However, I do not like the solution as it's an
> unconventional means of preserving a mapping and it's not a context where
> rcu_read_lock is obviously protecting rcu data.
> 
> Fixes: c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware 
> again")
> Signed-off-by: Mel Gorman 
Acked-by: Minchan Kim 

Thanks for the patch.

Re: [PATCH] mm: Pin address_space before dereferencing it while isolating an LRU page

[Minchan Kim]

On Thu, Jan 04, 2018 at 10:25:12AM +, Mel Gorman wrote:
> Minchan Kim asked the following question -- what locks protects
> address_space destroying when race happens between inode trauncation and
> __isolate_lru_page? Jan Kara clarified by describing the race as follows
> 
> CPU1CPU2
> 
> truncate(inode) __isolate_lru_page()
>   ...
>   truncate_inode_page(mapping, page);
> delete_from_page_cache(page)
>   spin_lock_irqsave(>tree_lock, flags);
> __delete_from_page_cache(page, NULL)
>   page_cache_tree_delete(..)
> ...   mapping = 
> page_mapping(page);
> page->mapping = NULL;
> ...
>   spin_unlock_irqrestore(>tree_lock, flags);
>   page_cache_free_page(mapping, page)
> put_page(page)
>   if (put_page_testzero(page)) -> false
> - inode now has no pages and can be freed including embedded address_space
> 
>   if (mapping && 
> !mapping->a_ops->migratepage)
> - we've dereferenced mapping which is potentially already free.
> 
> The race is theoritically possible but unlikely. Before the
> delete_from_page_cache, truncate_cleanup_page is called so the page is
> likely to be !PageDirty or PageWriteback which gets skipped by the only
> caller that checks the mappping in __isolate_lru_page. Even if the race
> occurs, a substantial amount of work has to happen during a tiny window
> with no preemption but it could potentially be done using a virtual machine
> to artifically slow one CPU or halt it during the critical window.
> 
> This patch should eliminate the race with truncation by try-locking the page
> before derefencing mapping and aborting if the lock was not acquired. There
> was a suggestion from Huang Ying to use RCU as a side-effect to prevent
> mapping being freed. However, I do not like the solution as it's an
> unconventional means of preserving a mapping and it's not a context where
> rcu_read_lock is obviously protecting rcu data.
> 
> Fixes: c82449352854 ("mm: compaction: make isolate_lru_page() filter-aware 
> again")
> Signed-off-by: Mel Gorman 
Acked-by: Minchan Kim 

Thanks for the patch.

Re: [net-next: PATCH v4 1/7] device property: Introduce fwnode_get_mac_address()

[Marcin Wojtas]

Hi Rafael,

> > if (res)
> > return res;
> >
> > -   return device_get_mac_addr(dev, "address", addr, alen);
> > +   return fwnode_get_mac_addr(fwnode, "address", addr, alen);
> > +}
> > +EXPORT_SYMBOL(fwnode_get_mac_address);
>
> That should be EXPORT_SYMBOL_GPL().
>
> I have overlooked that previously, sorry about that.

The series landed yesterday in net-next, so I need to send a fix on
top. Would you be ok with single patch fixing all EXPORT_SYMBOL()
occurences? Those would be 2 new routines:
- fwnode_get_mac_address
- fwnode_irq_get
and  2 already existing in the file:
- device_get_mac_address
- fwnode_graph_parse_endpoint

Please let know, how you prefer to handle it?

Best regards,
Marcin

>
> > +
> > +/**
> > + * device_get_mac_address - Get the MAC for a given device
> > + * @dev:   Pointer to the device
> > + * @addr:  Address of buffer to store the MAC in
> > + * @alen:  Length of the buffer pointed to by addr, should be ETH_ALEN
> > + */
> > +void *device_get_mac_address(struct device *dev, char *addr, int alen)
> > +{
> > +   return fwnode_get_mac_address(dev_fwnode(dev), addr, alen);
> >  }
> >  EXPORT_SYMBOL(device_get_mac_address);
>
> Same here.
>
> Generally speaking, you should use EXPORT_SYMBOL_GPL() everywhere
> unless there's a specific reason for not doing that in which cases
> that specific reason has to be clearly spelled out at least in the
> changelog of the patch, but really better in a code comment.
>
> >
> > diff --git a/include/linux/property.h b/include/linux/property.h
> > index f6189a3..35620e0 100644
> > --- a/include/linux/property.h
> > +++ b/include/linux/property.h
> > @@ -279,6 +279,8 @@ int device_get_phy_mode(struct device *dev);
> >
> >  void *device_get_mac_address(struct device *dev, char *addr, int alen);
> >
> > +void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
> > +char *addr, int alen);
> >  struct fwnode_handle *fwnode_graph_get_next_endpoint(
> > const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
> >  struct fwnode_handle *
> > --

Re: [net-next: PATCH v4 1/7] device property: Introduce fwnode_get_mac_address()

[Marcin Wojtas]

Hi Rafael,

> > if (res)
> > return res;
> >
> > -   return device_get_mac_addr(dev, "address", addr, alen);
> > +   return fwnode_get_mac_addr(fwnode, "address", addr, alen);
> > +}
> > +EXPORT_SYMBOL(fwnode_get_mac_address);
>
> That should be EXPORT_SYMBOL_GPL().
>
> I have overlooked that previously, sorry about that.

The series landed yesterday in net-next, so I need to send a fix on
top. Would you be ok with single patch fixing all EXPORT_SYMBOL()
occurences? Those would be 2 new routines:
- fwnode_get_mac_address
- fwnode_irq_get
and  2 already existing in the file:
- device_get_mac_address
- fwnode_graph_parse_endpoint

Please let know, how you prefer to handle it?

Best regards,
Marcin

>
> > +
> > +/**
> > + * device_get_mac_address - Get the MAC for a given device
> > + * @dev:   Pointer to the device
> > + * @addr:  Address of buffer to store the MAC in
> > + * @alen:  Length of the buffer pointed to by addr, should be ETH_ALEN
> > + */
> > +void *device_get_mac_address(struct device *dev, char *addr, int alen)
> > +{
> > +   return fwnode_get_mac_address(dev_fwnode(dev), addr, alen);
> >  }
> >  EXPORT_SYMBOL(device_get_mac_address);
>
> Same here.
>
> Generally speaking, you should use EXPORT_SYMBOL_GPL() everywhere
> unless there's a specific reason for not doing that in which cases
> that specific reason has to be clearly spelled out at least in the
> changelog of the patch, but really better in a code comment.
>
> >
> > diff --git a/include/linux/property.h b/include/linux/property.h
> > index f6189a3..35620e0 100644
> > --- a/include/linux/property.h
> > +++ b/include/linux/property.h
> > @@ -279,6 +279,8 @@ int device_get_phy_mode(struct device *dev);
> >
> >  void *device_get_mac_address(struct device *dev, char *addr, int alen);
> >
> > +void *fwnode_get_mac_address(struct fwnode_handle *fwnode,
> > +char *addr, int alen);
> >  struct fwnode_handle *fwnode_graph_get_next_endpoint(
> > const struct fwnode_handle *fwnode, struct fwnode_handle *prev);
> >  struct fwnode_handle *
> > --

Re: [Patch v6 00/12] Add MFC v10.10 support

[Smitha T Murthy]

On Mon, 2018-01-22 at 13:18 +0100, Hans Verkuil wrote:
> Hi Smitha,
> 
> Thank you for this v6 series!
> 
> You can add my:
> 
> Acked-by: Hans Verkuil 
> 
> to patches 1-9 and 11. See my review for patches 10 and 12. The comments
> are minor, so I hope I can Ack v7 once it's posted and this can be merged
> for 4.17.
> 
> Regards,
> 
>   Hans
> 
Thank you so much for the review.
I will update the same by this week and post.

Regards,
Smitha
> On 08/12/17 10:08, Smitha T Murthy wrote:
> > This patch series adds MFC v10.10 support. MFC v10.10 is used in some
> > of Exynos7 variants.
> > 
> > This adds support for following:
> > 
> > * Add support for HEVC encoder and decoder
> > * Add support for VP9 decoder
> > * Update Documentation for control id definitions
> > * Update computation of min scratch buffer size requirement for V8 onwards
> > 
> > Changes since v5:
> >  - Addressed review comments by Kamil Debski .
> >  - Addressed review comments by 
> >Stanimir Varbanov .
> >  - Addressed review comments by Hans Verkuil .
> >  - Rebased on latest git://linuxtv.org/snawrocki/samsung.git
> >for-v4.15/media/next.
> >  - Applied r-o-b from Andrzej, Stanimir on respective patches.
> >  - Applied acked-by from Kamil, Hans on respective patches.
> > 
> > Smitha T Murthy (12):
> >   [media] s5p-mfc: Rename IS_MFCV8 macro
> >   [media] s5p-mfc: Adding initial support for MFC v10.10
> >   [media] s5p-mfc: Use min scratch buffer size as provided by F/W
> >   [media] s5p-mfc: Support MFCv10.10 buffer requirements
> >   [media] videodev2.h: Add v4l2 definition for HEVC
> >   [media] v4l2-ioctl: add HEVC format description
> >   Documentation: v4l: Documentation for HEVC v4l2 definition
> >   [media] s5p-mfc: Add support for HEVC decoder
> >   [media] s5p-mfc: Add VP9 decoder support
> >   [media] v4l2: Add v4l2 control IDs for HEVC encoder
> >   [media] s5p-mfc: Add support for HEVC encoder
> >   Documention: v4l: Documentation for HEVC CIDs
> > 
> >  .../devicetree/bindings/media/s5p-mfc.txt  |   1 +
> >  Documentation/media/uapi/v4l/extended-controls.rst | 395 +++
> >  Documentation/media/uapi/v4l/pixfmt-compressed.rst |   5 +
> >  drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |  88 
> >  drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   2 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc.c   |  28 ++
> >  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c|   9 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  68 ++-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |   6 +-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |  48 +-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   | 555 
> > -
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h   |  14 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 397 +--
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|  15 +
> >  drivers/media/v4l2-core/v4l2-ctrls.c   | 118 +
> >  drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
> >  include/uapi/linux/v4l2-controls.h |  92 +++-
> >  include/uapi/linux/videodev2.h |   1 +
> >  18 files changed, 1765 insertions(+), 78 deletions(-)
> >  create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > 
> 
> 
> 

Re: [Patch v6 00/12] Add MFC v10.10 support

[Smitha T Murthy]

On Mon, 2018-01-22 at 13:18 +0100, Hans Verkuil wrote:
> Hi Smitha,
> 
> Thank you for this v6 series!
> 
> You can add my:
> 
> Acked-by: Hans Verkuil 
> 
> to patches 1-9 and 11. See my review for patches 10 and 12. The comments
> are minor, so I hope I can Ack v7 once it's posted and this can be merged
> for 4.17.
> 
> Regards,
> 
>   Hans
> 
Thank you so much for the review.
I will update the same by this week and post.

Regards,
Smitha
> On 08/12/17 10:08, Smitha T Murthy wrote:
> > This patch series adds MFC v10.10 support. MFC v10.10 is used in some
> > of Exynos7 variants.
> > 
> > This adds support for following:
> > 
> > * Add support for HEVC encoder and decoder
> > * Add support for VP9 decoder
> > * Update Documentation for control id definitions
> > * Update computation of min scratch buffer size requirement for V8 onwards
> > 
> > Changes since v5:
> >  - Addressed review comments by Kamil Debski .
> >  - Addressed review comments by 
> >Stanimir Varbanov .
> >  - Addressed review comments by Hans Verkuil .
> >  - Rebased on latest git://linuxtv.org/snawrocki/samsung.git
> >for-v4.15/media/next.
> >  - Applied r-o-b from Andrzej, Stanimir on respective patches.
> >  - Applied acked-by from Kamil, Hans on respective patches.
> > 
> > Smitha T Murthy (12):
> >   [media] s5p-mfc: Rename IS_MFCV8 macro
> >   [media] s5p-mfc: Adding initial support for MFC v10.10
> >   [media] s5p-mfc: Use min scratch buffer size as provided by F/W
> >   [media] s5p-mfc: Support MFCv10.10 buffer requirements
> >   [media] videodev2.h: Add v4l2 definition for HEVC
> >   [media] v4l2-ioctl: add HEVC format description
> >   Documentation: v4l: Documentation for HEVC v4l2 definition
> >   [media] s5p-mfc: Add support for HEVC decoder
> >   [media] s5p-mfc: Add VP9 decoder support
> >   [media] v4l2: Add v4l2 control IDs for HEVC encoder
> >   [media] s5p-mfc: Add support for HEVC encoder
> >   Documention: v4l: Documentation for HEVC CIDs
> > 
> >  .../devicetree/bindings/media/s5p-mfc.txt  |   1 +
> >  Documentation/media/uapi/v4l/extended-controls.rst | 395 +++
> >  Documentation/media/uapi/v4l/pixfmt-compressed.rst |   5 +
> >  drivers/media/platform/s5p-mfc/regs-mfc-v10.h  |  88 
> >  drivers/media/platform/s5p-mfc/regs-mfc-v8.h   |   2 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc.c   |  28 ++
> >  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c|   9 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_common.h|  68 ++-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c  |   6 +-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c   |  48 +-
> >  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c   | 555 
> > -
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h   |  14 +
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c| 397 +--
> >  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h|  15 +
> >  drivers/media/v4l2-core/v4l2-ctrls.c   | 118 +
> >  drivers/media/v4l2-core/v4l2-ioctl.c   |   1 +
> >  include/uapi/linux/v4l2-controls.h |  92 +++-
> >  include/uapi/linux/videodev2.h |   1 +
> >  18 files changed, 1765 insertions(+), 78 deletions(-)
> >  create mode 100644 drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> > 
> 
> 
> 

Re: [Patch v6 12/12] Documention: v4l: Documentation for HEVC CIDs

[Smitha T Murthy]

On Mon, 2018-01-22 at 13:15 +0100, Hans Verkuil wrote:
> On 08/12/17 10:08, Smitha T Murthy wrote:
> > Added V4l2 controls for HEVC encoder
> > 
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  Documentation/media/uapi/v4l/extended-controls.rst | 395 
> > +
> >  1 file changed, 395 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> > b/Documentation/media/uapi/v4l/extended-controls.rst
> > index a3e81c1..3c92763 100644
> > --- a/Documentation/media/uapi/v4l/extended-controls.rst
> > +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> > @@ -1960,6 +1960,401 @@ enum v4l2_vp8_golden_frame_sel -
> >  1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> >  
> >  
> > +High Efficiency Video Coding (HEVC/H.265) Control Reference
> > +---
> > +
> > +The HEVC/H.265 controls include controls for encoding parameters of 
> > HEVC/H.265
> > +video codec.
> > +
> > +
> > +.. _hevc-control-id:
> > +
> > +HEVC/H.265 Control IDs
> > +^^
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)``
> > +Minimum quantization parameter for HEVC.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)``
> > +Maximum quantization parameter for HEVC.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)``
> > +Quantization parameter for an I frame for HEVC.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (integer)``
> > +Quantization parameter for a P frame for HEVC.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (integer)``
> > +Quantization parameter for a B frame for HEVC.
> 
> I assume these values all have to be in the range MIN_QP to MAX_QP?
> If so, then this should be documented I think.
> 
Yes they should be in the limit. I will mention the range in next
version.

> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)``
> > +HIERARCHICAL_QP allows host to specify the quantization parameter 
> > values
> 
> host -> the host
ok I will change it.
> 
> > +for each temporal layer through HIERARCHICAL_QP_LAYER. This is valid 
> > only
> > +if HIERARCHICAL_CODING_LAYER is greater than 1. Setting the control 
> > value
> > +to 1 enables setting of the QP values for the layers.
> > +
> > +.. _v4l2-hevc-hier-coding-type:
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE``
> > +(enum)
> > +
> > +enum v4l2_mpeg_video_hevc_hier_coding_type -
> > +Selects the hierarchical coding type for encoding. Possible values are:
> > +
> > +.. raw:: latex
> > +
> > +\begin{adjustbox}{width=\columnwidth}
> > +
> > +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> > +
> > +.. flat-table::
> > +:header-rows:  0
> > +:stub-columns: 0
> > +
> > +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B``
> > +  - Use the B frame for hierarchical coding.
> > +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P``
> > +  - Use the P frame for hierarchical coding.
> > +
> > +.. raw:: latex
> > +
> > +\end{adjustbox}
> > +
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)``
> > +Selects the hierarchical coding layer. In normal encoding
> > +(non-hierarchial coding), it should be zero. Possible values are 0 ~ 6.
> 
> Use - instead of ~. Or just say: [0, 6]
> 
ok I will change it.
> > +0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL 
> > CODING
> > +LAYER 1 and so on.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 0.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 1.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 2.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 3.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 4.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 5.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 6.
> > +For HEVC it can have a value of 0-51.
> 
> How do these controls relate to MIN_QP and MAX_QP?
> 
Here each layer will adhere to MAX_QP and MIN_QP set.
> > +
> > +.. _v4l2-hevc-profile:
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_PROFILE``
> > 

Re: [Patch v6 12/12] Documention: v4l: Documentation for HEVC CIDs

[Smitha T Murthy]

On Mon, 2018-01-22 at 13:15 +0100, Hans Verkuil wrote:
> On 08/12/17 10:08, Smitha T Murthy wrote:
> > Added V4l2 controls for HEVC encoder
> > 
> > Signed-off-by: Smitha T Murthy 
> > ---
> >  Documentation/media/uapi/v4l/extended-controls.rst | 395 
> > +
> >  1 file changed, 395 insertions(+)
> > 
> > diff --git a/Documentation/media/uapi/v4l/extended-controls.rst 
> > b/Documentation/media/uapi/v4l/extended-controls.rst
> > index a3e81c1..3c92763 100644
> > --- a/Documentation/media/uapi/v4l/extended-controls.rst
> > +++ b/Documentation/media/uapi/v4l/extended-controls.rst
> > @@ -1960,6 +1960,401 @@ enum v4l2_vp8_golden_frame_sel -
> >  1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
> >  
> >  
> > +High Efficiency Video Coding (HEVC/H.265) Control Reference
> > +---
> > +
> > +The HEVC/H.265 controls include controls for encoding parameters of 
> > HEVC/H.265
> > +video codec.
> > +
> > +
> > +.. _hevc-control-id:
> > +
> > +HEVC/H.265 Control IDs
> > +^^
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP (integer)``
> > +Minimum quantization parameter for HEVC.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP (integer)``
> > +Maximum quantization parameter for HEVC.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP (integer)``
> > +Quantization parameter for an I frame for HEVC.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP (integer)``
> > +Quantization parameter for a P frame for HEVC.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP (integer)``
> > +Quantization parameter for a B frame for HEVC.
> 
> I assume these values all have to be in the range MIN_QP to MAX_QP?
> If so, then this should be documented I think.
> 
Yes they should be in the limit. I will mention the range in next
version.

> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP (boolean)``
> > +HIERARCHICAL_QP allows host to specify the quantization parameter 
> > values
> 
> host -> the host
ok I will change it.
> 
> > +for each temporal layer through HIERARCHICAL_QP_LAYER. This is valid 
> > only
> > +if HIERARCHICAL_CODING_LAYER is greater than 1. Setting the control 
> > value
> > +to 1 enables setting of the QP values for the layers.
> > +
> > +.. _v4l2-hevc-hier-coding-type:
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE``
> > +(enum)
> > +
> > +enum v4l2_mpeg_video_hevc_hier_coding_type -
> > +Selects the hierarchical coding type for encoding. Possible values are:
> > +
> > +.. raw:: latex
> > +
> > +\begin{adjustbox}{width=\columnwidth}
> > +
> > +.. tabularcolumns:: |p{11.0cm}|p{10.0cm}|
> > +
> > +.. flat-table::
> > +:header-rows:  0
> > +:stub-columns: 0
> > +
> > +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_B``
> > +  - Use the B frame for hierarchical coding.
> > +* - ``V4L2_MPEG_VIDEO_HEVC_HIERARCHICAL_CODING_P``
> > +  - Use the P frame for hierarchical coding.
> > +
> > +.. raw:: latex
> > +
> > +\end{adjustbox}
> > +
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_LAYER (integer)``
> > +Selects the hierarchical coding layer. In normal encoding
> > +(non-hierarchial coding), it should be zero. Possible values are 0 ~ 6.
> 
> Use - instead of ~. Or just say: [0, 6]
> 
ok I will change it.
> > +0 indicates HIERARCHICAL CODING LAYER 0, 1 indicates HIERARCHICAL 
> > CODING
> > +LAYER 1 and so on.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 0.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 1.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 2.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 3.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 4.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 5.
> > +For HEVC it can have a value of 0-51.
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP (integer)``
> > +Indicates quantization parameter for hierarchical coding layer 6.
> > +For HEVC it can have a value of 0-51.
> 
> How do these controls relate to MIN_QP and MAX_QP?
> 
Here each layer will adhere to MAX_QP and MIN_QP set.
> > +
> > +.. _v4l2-hevc-profile:
> > +
> > +``V4L2_CID_MPEG_VIDEO_HEVC_PROFILE``
> > +(enum)
> > +
> > 

Re: Re: [PATCH v4] net: qcom/emac: extend DMA mask to 46bits

[Wang, Dongsheng]

Thanks.

Cheers,
-Dongsheng

On 2018/1/23 12:48:27, "Timur Tabi"  wrote:

>On 1/22/18 10:25 PM, Wang Dongsheng wrote:
>>Bit TPD3[31] is used as a timestamp bit if PTP is enabled, but
>>it's used as an address bit if PTP is disabled.  Since PTP isn't
>>supported by the driver, we can extend the DMA address to 46 bits.
>>
>>Signed-off-by: Wang Dongsheng
>
>Acked-by: Timur Tabi 
>
>--
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
>Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
>Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: Re: [PATCH v4] net: qcom/emac: extend DMA mask to 46bits

[Wang, Dongsheng]

Thanks.

Cheers,
-Dongsheng

On 2018/1/23 12:48:27, "Timur Tabi"  wrote:

>On 1/22/18 10:25 PM, Wang Dongsheng wrote:
>>Bit TPD3[31] is used as a timestamp bit if PTP is enabled, but
>>it's used as an address bit if PTP is disabled.  Since PTP isn't
>>supported by the driver, we can extend the DMA address to 46 bits.
>>
>>Signed-off-by: Wang Dongsheng
>
>Acked-by: Timur Tabi 
>
>--
>Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
>Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
>Code Aurora Forum, a Linux Foundation Collaborative Project.

problematic rc9 futex changes.

[Dave Jones]

c1e2f0eaf015fb: "futex: Avoid violating the 10th rule of futex" seems to
make up a few new rules to violate.

Coverity picked up these two problems in the same code:


First it or's a value with stack garbage.

___
*** CID 1427826:  Uninitialized variables  (UNINIT)
/kernel/futex.c: 2316 in fixup_pi_state_owner()
2310 
2311raw_spin_lock_irq(_state->pi_mutex.wait_lock);
2312 
2313oldowner = pi_state->owner;
2314/* Owner died? */
2315if (!pi_state->owner)
>>> CID 1427826:  Uninitialized variables  (UNINIT)
>>> Using uninitialized value "newtid".
2316newtid |= FUTEX_OWNER_DIED;
2317 
2318/*
2319 * We are here because either:
2320 *
2321 *  - we stole the lock and pi_state->owner needs updating to 
reflect

Then it notices that value is never read from before it's written
anyway.

*** CID 1427824:  Code maintainability issues  (UNUSED_VALUE)
/kernel/futex.c: 2316 in fixup_pi_state_owner()
2310 
2311raw_spin_lock_irq(_state->pi_mutex.wait_lock);
2312 
2313oldowner = pi_state->owner;
2314/* Owner died? */
2315if (!pi_state->owner)
>>> CID 1427824:  Code maintainability issues  (UNUSED_VALUE)
>>> Assigning value from "newtid | 0x4000U" to "newtid" here, but that 
>>> stored value is overwritten before it can be used.
2316newtid |= FUTEX_OWNER_DIED;
2317 
2318/*
2319 * We are here because either:
2320 *
2321 *  - we stole the lock and pi_state->owner needs updating to 
reflect


(The next reference of newtid being..

2369 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;


Dave

problematic rc9 futex changes.

[Dave Jones]

c1e2f0eaf015fb: "futex: Avoid violating the 10th rule of futex" seems to
make up a few new rules to violate.

Coverity picked up these two problems in the same code:


First it or's a value with stack garbage.

___
*** CID 1427826:  Uninitialized variables  (UNINIT)
/kernel/futex.c: 2316 in fixup_pi_state_owner()
2310 
2311raw_spin_lock_irq(_state->pi_mutex.wait_lock);
2312 
2313oldowner = pi_state->owner;
2314/* Owner died? */
2315if (!pi_state->owner)
>>> CID 1427826:  Uninitialized variables  (UNINIT)
>>> Using uninitialized value "newtid".
2316newtid |= FUTEX_OWNER_DIED;
2317 
2318/*
2319 * We are here because either:
2320 *
2321 *  - we stole the lock and pi_state->owner needs updating to 
reflect

Then it notices that value is never read from before it's written
anyway.

*** CID 1427824:  Code maintainability issues  (UNUSED_VALUE)
/kernel/futex.c: 2316 in fixup_pi_state_owner()
2310 
2311raw_spin_lock_irq(_state->pi_mutex.wait_lock);
2312 
2313oldowner = pi_state->owner;
2314/* Owner died? */
2315if (!pi_state->owner)
>>> CID 1427824:  Code maintainability issues  (UNUSED_VALUE)
>>> Assigning value from "newtid | 0x4000U" to "newtid" here, but that 
>>> stored value is overwritten before it can be used.
2316newtid |= FUTEX_OWNER_DIED;
2317 
2318/*
2319 * We are here because either:
2320 *
2321 *  - we stole the lock and pi_state->owner needs updating to 
reflect


(The next reference of newtid being..

2369 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;


Dave

linux-next: Signed-off-by missing for commit in the arm-soc tree

[Stephen Rothwell]

Hi all,

Commit

  8dd0e9b5f7fa ("of: platform: fix OF node refcount leak")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

linux-next: Signed-off-by missing for commit in the arm-soc tree

[Stephen Rothwell]

Hi all,

Commit

  8dd0e9b5f7fa ("of: platform: fix OF node refcount leak")

is missing a Signed-off-by from its committer.

-- 
Cheers,
Stephen Rothwell

Re: [Patch v6 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder

[Smitha T Murthy]

On Mon, 2018-01-22 at 12:08 +0100, Hans Verkuil wrote:
> On 08/12/17 10:08, Smitha T Murthy wrote:
> > Add v4l2 controls for HEVC encoder
> > 
> > Signed-off-by: Smitha T Murthy 
> > Reviewed-by: Andrzej Hajda 
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c | 118 
> > +++
> >  include/uapi/linux/v4l2-controls.h   |  92 ++-
> >  2 files changed, 209 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 4e53a86..3f98318 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -480,6 +480,56 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > NULL,
> > };
> >  
> > +   static const char * const hevc_profile[] = {
> > +   "Main",
> > +   "Main Still Picture",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_level[] = {
> > +   "1",
> > +   "2",
> > +   "2.1",
> > +   "3",
> > +   "3.1",
> > +   "4",
> > +   "4.1",
> > +   "5",
> > +   "5.1",
> > +   "5.2",
> > +   "6",
> > +   "6.1",
> > +   "6.2",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_hierarchial_coding_type[] = {
> > +   "B",
> > +   "P",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_refresh_type[] = {
> > +   "None",
> > +   "CRA",
> > +   "IDR",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_size_of_length_field[] = {
> > +   "0",
> > +   "1",
> > +   "2",
> > +   "4",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_tier_flag[] = {
> > +   "Main",
> > +   "High",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_loop_filter_mode[] = {
> > +   "Disabled",
> > +   "Enabled",
> > +   "Disabled at slice boundary",
> > +   "NULL",
> > +   };
> >  
> > switch (id) {
> > case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> > @@ -575,6 +625,20 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > return dv_it_content_type;
> > case V4L2_CID_DETECT_MD_MODE:
> > return detect_md_mode;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> > +   return hevc_profile;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> > +   return hevc_level;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE:
> > +   return hevc_hierarchial_coding_type;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE:
> > +   return hevc_refresh_type;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
> > +   return hevc_size_of_length_field;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:
> > +   return hevc_tier_flag;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE:
> > +   return hevc_loop_filter_mode;
> >  
> > default:
> > return NULL;
> > @@ -776,6 +840,53 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
> > P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:   return "VPX 
> > Profile";
> >  
> > +   /* HEVC controls */
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:   return "HEVC 
> > I-Frame QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:   return "HEVC 
> > P-Frame QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP:   return "HEVC 
> > B-Frame QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP:   return "HEVC 
> > Minimum QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP:   return "HEVC 
> > Maximum QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:  return "HEVC 
> > Profile";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC 
> > Level";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC 
> > Tier Flag";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION:return "HEVC 
> > Frame Rate Resolution";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH:  return "HEVC 
> > Maximum Coding Unit Depth";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC 
> > Refresh Type";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED: return "HEVC 
> > Constant Intra Prediction";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU:  return "HEVC 
> > Lossless Encoding";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT:return "HEVC 
> > Wavefront";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE: return "HEVC 
> > Loop Filter";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP:

Re: [Patch v6 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder

[Smitha T Murthy]

On Mon, 2018-01-22 at 12:08 +0100, Hans Verkuil wrote:
> On 08/12/17 10:08, Smitha T Murthy wrote:
> > Add v4l2 controls for HEVC encoder
> > 
> > Signed-off-by: Smitha T Murthy 
> > Reviewed-by: Andrzej Hajda 
> > ---
> >  drivers/media/v4l2-core/v4l2-ctrls.c | 118 
> > +++
> >  include/uapi/linux/v4l2-controls.h   |  92 ++-
> >  2 files changed, 209 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
> > b/drivers/media/v4l2-core/v4l2-ctrls.c
> > index 4e53a86..3f98318 100644
> > --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> > +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> > @@ -480,6 +480,56 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > NULL,
> > };
> >  
> > +   static const char * const hevc_profile[] = {
> > +   "Main",
> > +   "Main Still Picture",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_level[] = {
> > +   "1",
> > +   "2",
> > +   "2.1",
> > +   "3",
> > +   "3.1",
> > +   "4",
> > +   "4.1",
> > +   "5",
> > +   "5.1",
> > +   "5.2",
> > +   "6",
> > +   "6.1",
> > +   "6.2",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_hierarchial_coding_type[] = {
> > +   "B",
> > +   "P",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_refresh_type[] = {
> > +   "None",
> > +   "CRA",
> > +   "IDR",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_size_of_length_field[] = {
> > +   "0",
> > +   "1",
> > +   "2",
> > +   "4",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_tier_flag[] = {
> > +   "Main",
> > +   "High",
> > +   NULL,
> > +   };
> > +   static const char * const hevc_loop_filter_mode[] = {
> > +   "Disabled",
> > +   "Enabled",
> > +   "Disabled at slice boundary",
> > +   "NULL",
> > +   };
> >  
> > switch (id) {
> > case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
> > @@ -575,6 +625,20 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
> > return dv_it_content_type;
> > case V4L2_CID_DETECT_MD_MODE:
> > return detect_md_mode;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
> > +   return hevc_profile;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
> > +   return hevc_level;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_TYPE:
> > +   return hevc_hierarchial_coding_type;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE:
> > +   return hevc_refresh_type;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_SIZE_OF_LENGTH_FIELD:
> > +   return hevc_size_of_length_field;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:
> > +   return hevc_tier_flag;
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE:
> > +   return hevc_loop_filter_mode;
> >  
> > default:
> > return NULL;
> > @@ -776,6 +840,53 @@ const char *v4l2_ctrl_get_name(u32 id)
> > case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX 
> > P-Frame QP Value";
> > case V4L2_CID_MPEG_VIDEO_VPX_PROFILE:   return "VPX 
> > Profile";
> >  
> > +   /* HEVC controls */
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP:   return "HEVC 
> > I-Frame QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP:   return "HEVC 
> > P-Frame QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_B_FRAME_QP:   return "HEVC 
> > B-Frame QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP:   return "HEVC 
> > Minimum QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_QP:   return "HEVC 
> > Maximum QP Value";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:  return "HEVC 
> > Profile";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:return "HEVC 
> > Level";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_TIER_FLAG:return "HEVC 
> > Tier Flag";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_FRAME_RATE_RESOLUTION:return "HEVC 
> > Frame Rate Resolution";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_MAX_PARTITION_DEPTH:  return "HEVC 
> > Maximum Coding Unit Depth";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_REFRESH_TYPE: return "HEVC 
> > Refresh Type";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_CONST_INTRA_PRED: return "HEVC 
> > Constant Intra Prediction";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LOSSLESS_CU:  return "HEVC 
> > Lossless Encoding";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_WAVEFRONT:return "HEVC 
> > Wavefront";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_LOOP_FILTER_MODE: return "HEVC 
> > Loop Filter";
> > +   case V4L2_CID_MPEG_VIDEO_HEVC_HIER_QP:  return "HEVC QP 
> > Values";
> > +   

Re: [PATCH v4] net: qcom/emac: extend DMA mask to 46bits

[Timur Tabi]

On 1/22/18 10:25 PM, Wang Dongsheng wrote:

Bit TPD3[31] is used as a timestamp bit if PTP is enabled, but
it's used as an address bit if PTP is disabled.  Since PTP isn't
supported by the driver, we can extend the DMA address to 46 bits.

Signed-off-by: Wang Dongsheng


Acked-by: Timur Tabi 

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v4] net: qcom/emac: extend DMA mask to 46bits

[Timur Tabi]

On 1/22/18 10:25 PM, Wang Dongsheng wrote:

Bit TPD3[31] is used as a timestamp bit if PTP is enabled, but
it's used as an address bit if PTP is disabled.  Since PTP isn't
supported by the driver, we can extend the DMA address to 46 bits.

Signed-off-by: Wang Dongsheng


Acked-by: Timur Tabi 

--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Ping Re: [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

[Michael Ellerman]

Vincent Legoll  writes:

> No need to get into the submenu to disable all VIRTIO-related
> config entries.
>
> This makes it easier to disable all VIRTIO config options
> without entering the submenu. It will also enable one
> to see that en/dis-abled state from the outside menu.
>
> This is only intended to change menuconfig UI, not change
> the config dependencies.
>
> v2: Added "default y" to avoid breaking existing configs
> v3: Fixed wrong indentation, added *-by from Randy
>
> Signed-off-by: Vincent Legoll 
> Reviewed-by: Randy Dunlap 
> Tested-by: Randy Dunlap  # works for me
> ---
>  drivers/virtio/Kconfig | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

This has been broken in linux-next for ~6 weeks now, can we please merge
this and get it fixed.

cheers

Ping Re: [PATCH] virtio: make VIRTIO a menuconfig to ease disabling it all

[Michael Ellerman]

Vincent Legoll  writes:

> No need to get into the submenu to disable all VIRTIO-related
> config entries.
>
> This makes it easier to disable all VIRTIO config options
> without entering the submenu. It will also enable one
> to see that en/dis-abled state from the outside menu.
>
> This is only intended to change menuconfig UI, not change
> the config dependencies.
>
> v2: Added "default y" to avoid breaking existing configs
> v3: Fixed wrong indentation, added *-by from Randy
>
> Signed-off-by: Vincent Legoll 
> Reviewed-by: Randy Dunlap 
> Tested-by: Randy Dunlap  # works for me
> ---
>  drivers/virtio/Kconfig | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)

This has been broken in linux-next for ~6 weeks now, can we please merge
this and get it fixed.

cheers

[PATCH v4] net: qcom/emac: extend DMA mask to 46bits

[Wang Dongsheng]

Bit TPD3[31] is used as a timestamp bit if PTP is enabled, but
it's used as an address bit if PTP is disabled.  Since PTP isn't
supported by the driver, we can extend the DMA address to 46 bits.

Signed-off-by: Wang Dongsheng 
---
v4:
- Changes: PATCH's description.
v3:
- Add: comments for TPD_BUFFER_ADDR_H_SET.
- Remove: "Dynamic fix TPD_BUFFER_ADDR_H_SET size."
v2:
- Add: Dynamic fix TPD_BUFFER_ADDR_H_SET size.
- Add: Comments for DMA MASK.
- Changes: PATCH subject.
- Modify: DMA MASK to 46bits.
---
 drivers/net/ethernet/qualcomm/emac/emac-mac.h | 3 ++-
 drivers/net/ethernet/qualcomm/emac/emac.c | 7 +--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.h 
b/drivers/net/ethernet/qualcomm/emac/emac-mac.h
index 5028fb4..4beedb8 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.h
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.h
@@ -114,8 +114,9 @@ struct emac_tpd {
 #define TPD_INSTC_SET(tpd, val)BITS_SET((tpd)->word[3], 17, 
17, val)
 /* High-14bit Buffer Address, So, the 64b-bit address is
  * {DESC_CTRL_11_TX_DATA_HIADDR[17:0],(register) BUFFER_ADDR_H, BUFFER_ADDR_L}
+ * Extend TPD_BUFFER_ADDR_H to [31, 18], because we never enable timestamping.
  */
-#define TPD_BUFFER_ADDR_H_SET(tpd, val)BITS_SET((tpd)->word[3], 18, 
30, val)
+#define TPD_BUFFER_ADDR_H_SET(tpd, val)BITS_SET((tpd)->word[3], 18, 
31, val)
 /* Format D. Word offset from the 1st byte of this packet to start to calculate
  * the custom checksum.
  */
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c 
b/drivers/net/ethernet/qualcomm/emac/emac.c
index 38c924bd..13235ba 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -615,8 +615,11 @@ static int emac_probe(struct platform_device *pdev)
u32 reg;
int ret;
 
-   /* The TPD buffer address is limited to 45 bits. */
-   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(45));
+   /* The TPD buffer address is limited to:
+* 1. PTP:  45bits. (Driver doesn't support yet.)
+* 2. NON-PTP:  46bits.
+*/
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(46));
if (ret) {
dev_err(>dev, "could not set DMA mask\n");
return ret;
-- 
2.7.4

[PATCH v4] net: qcom/emac: extend DMA mask to 46bits

[Wang Dongsheng]

Bit TPD3[31] is used as a timestamp bit if PTP is enabled, but
it's used as an address bit if PTP is disabled.  Since PTP isn't
supported by the driver, we can extend the DMA address to 46 bits.

Signed-off-by: Wang Dongsheng 
---
v4:
- Changes: PATCH's description.
v3:
- Add: comments for TPD_BUFFER_ADDR_H_SET.
- Remove: "Dynamic fix TPD_BUFFER_ADDR_H_SET size."
v2:
- Add: Dynamic fix TPD_BUFFER_ADDR_H_SET size.
- Add: Comments for DMA MASK.
- Changes: PATCH subject.
- Modify: DMA MASK to 46bits.
---
 drivers/net/ethernet/qualcomm/emac/emac-mac.h | 3 ++-
 drivers/net/ethernet/qualcomm/emac/emac.c | 7 +--
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.h 
b/drivers/net/ethernet/qualcomm/emac/emac-mac.h
index 5028fb4..4beedb8 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.h
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.h
@@ -114,8 +114,9 @@ struct emac_tpd {
 #define TPD_INSTC_SET(tpd, val)BITS_SET((tpd)->word[3], 17, 
17, val)
 /* High-14bit Buffer Address, So, the 64b-bit address is
  * {DESC_CTRL_11_TX_DATA_HIADDR[17:0],(register) BUFFER_ADDR_H, BUFFER_ADDR_L}
+ * Extend TPD_BUFFER_ADDR_H to [31, 18], because we never enable timestamping.
  */
-#define TPD_BUFFER_ADDR_H_SET(tpd, val)BITS_SET((tpd)->word[3], 18, 
30, val)
+#define TPD_BUFFER_ADDR_H_SET(tpd, val)BITS_SET((tpd)->word[3], 18, 
31, val)
 /* Format D. Word offset from the 1st byte of this packet to start to calculate
  * the custom checksum.
  */
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c 
b/drivers/net/ethernet/qualcomm/emac/emac.c
index 38c924bd..13235ba 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -615,8 +615,11 @@ static int emac_probe(struct platform_device *pdev)
u32 reg;
int ret;
 
-   /* The TPD buffer address is limited to 45 bits. */
-   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(45));
+   /* The TPD buffer address is limited to:
+* 1. PTP:  45bits. (Driver doesn't support yet.)
+* 2. NON-PTP:  46bits.
+*/
+   ret = dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(46));
if (ret) {
dev_err(>dev, "could not set DMA mask\n");
return ret;
-- 
2.7.4

[PATCH RESEND] perf/core: Fix installing cgroup event into cpu

[linxiulei]

From: "leilei.lin" 

Do not install cgroup event into the CPU context if the cgroup
is not running on this CPU

While there is no task of cgroup running specified CPU, current
kernel still install cgroup event into CPU context, that causes
another cgroup event can't be installed into this CPU.

Signed-off-by: leilei.lin 
---
 kernel/events/core.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4df5b69..19c587b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2284,6 +2284,7 @@ static int  __perf_install_in_context(void *info)
struct perf_event_context *ctx = event->ctx;
struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
struct perf_event_context *task_ctx = cpuctx->task_ctx;
+   struct perf_cgroup *cgrp;
bool reprogram = true;
int ret = 0;
 
@@ -2311,6 +2312,19 @@ static int  __perf_install_in_context(void *info)
raw_spin_lock(_ctx->lock);
}
 
+   if (event->cgrp) {
+   /*
+* Only care about cgroup events.
+*
+* If only the task belongs to cgroup of this event,
+* we will continue the installment
+*/
+   cgrp = perf_cgroup_from_task(current, ctx);
+   if (!cgroup_is_descendant(cgrp->css.cgroup,
+   event->cgrp->css.cgroup))
+   goto unlock;
+   }
+
if (reprogram) {
ctx_sched_out(ctx, cpuctx, EVENT_TIME);
add_event_to_ctx(event, ctx);
-- 
2.8.4.31.g9ed660f

[PATCH RESEND] perf/core: Fix installing cgroup event into cpu

[linxiulei]

From: "leilei.lin" 

Do not install cgroup event into the CPU context if the cgroup
is not running on this CPU

While there is no task of cgroup running specified CPU, current
kernel still install cgroup event into CPU context, that causes
another cgroup event can't be installed into this CPU.

Signed-off-by: leilei.lin 
---
 kernel/events/core.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4df5b69..19c587b 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2284,6 +2284,7 @@ static int  __perf_install_in_context(void *info)
struct perf_event_context *ctx = event->ctx;
struct perf_cpu_context *cpuctx = __get_cpu_context(ctx);
struct perf_event_context *task_ctx = cpuctx->task_ctx;
+   struct perf_cgroup *cgrp;
bool reprogram = true;
int ret = 0;
 
@@ -2311,6 +2312,19 @@ static int  __perf_install_in_context(void *info)
raw_spin_lock(_ctx->lock);
}
 
+   if (event->cgrp) {
+   /*
+* Only care about cgroup events.
+*
+* If only the task belongs to cgroup of this event,
+* we will continue the installment
+*/
+   cgrp = perf_cgroup_from_task(current, ctx);
+   if (!cgroup_is_descendant(cgrp->css.cgroup,
+   event->cgrp->css.cgroup))
+   goto unlock;
+   }
+
if (reprogram) {
ctx_sched_out(ctx, cpuctx, EVENT_TIME);
add_event_to_ctx(event, ctx);
-- 
2.8.4.31.g9ed660f

Re: [PATCH v4 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Dmitry Torokhov]

Hi Mylène,

On Fri, Dec 01, 2017 at 04:39:56PM +0100, Mylène Josserand wrote:
> This is the basic driver for the Cypress TrueTouch Gen5 touchscreen
> controllers. This driver supports only the I2C bus but it uses regmap
> so SPI support could be added later.
> The touchscreen can retrieve some defined zone that are handled as
> buttons (according to the hardware). That is why it handles
> button and multitouch events.
> 
> Reviewed-by: Maxime Ripard 
> Signed-off-by: Mylène Josserand 
> ---
>  drivers/input/touchscreen/Kconfig   |   16 +
>  drivers/input/touchscreen/Makefile  |1 +
>  drivers/input/touchscreen/cyttsp5.c | 1110 
> +++
>  3 files changed, 1127 insertions(+)
>  create mode 100644 drivers/input/touchscreen/cyttsp5.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 0cfdb7cb610e..28eea6d5f1bb 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -238,6 +238,22 @@ config TOUCHSCREEN_CYTTSP4_SPI
> To compile this driver as a module, choose M here: the
> module will be called cyttsp4_spi.
>  
> +config TOUCHSCREEN_CYTTSP5
> + tristate "Cypress TrueTouch Gen5 Touchscreen Driver"
> + depends on OF

Does it have to be? Please use generic device properties
(device_property_* API) and it can be used with ACPI and static board
files, of needed.

> + select REGMAP_I2C
> + select CRC_ITU_T
> + help
> +   Driver for Parade TrueTouch Standard Product
> +   Generation 5 touchscreen controllers.
> +   I2C bus interface support only.
> +
> +   Say Y here if you have a Cypress Gen5 touchscreen.
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called cyttsp5.
> +
>  config TOUCHSCREEN_DA9034
>   tristate "Touchscreen support for Dialog Semiconductor DA9034"
>   depends on PMIC_DA903X
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index d2a2b3b7af27..e7d124901dd9 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_TOUCHSCREEN_CYTTSP_SPI)+= cyttsp_spi.o
>  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_CORE)   += cyttsp4_core.o
>  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_I2C)+= cyttsp4_i2c.o 
> cyttsp_i2c_common.o
>  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_SPI)+= cyttsp4_spi.o
> +obj-$(CONFIG_TOUCHSCREEN_CYTTSP5)+= cyttsp5.o
>  obj-$(CONFIG_TOUCHSCREEN_DA9034) += da9034-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_DA9052) += da9052_tsi.o
>  obj-$(CONFIG_TOUCHSCREEN_DYNAPRO)+= dynapro.o
> diff --git a/drivers/input/touchscreen/cyttsp5.c 
> b/drivers/input/touchscreen/cyttsp5.c
> new file mode 100644
> index ..a41feea2cd5a
> --- /dev/null
> +++ b/drivers/input/touchscreen/cyttsp5.c
> @@ -0,0 +1,1110 @@
> +/*
> + * Parade TrueTouch(TM) Standard Product V5 Module.
> + * For use with Parade touchscreen controllers.
> + *
> + * Copyright (C) 2015 Parade Technologies
> + * Copyright (C) 2012-2015 Cypress Semiconductor
> + * Copyright (C) 2017 Free Electrons
> + *
> + * Author: Mylène Josserand 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2, and only version 2, as published by the
> + * Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CYTTSP5_NAME "cyttsp5"
> +#define CY_I2C_DATA_SIZE (2 * 256)
> +#define HID_VERSION  0x0100
> +#define CY_MAX_INPUT 512
> +#define CYTTSP5_PREALLOCATED_CMD_BUFFER  32
> +#define CY_BITS_PER_BTN  1
> +#define CY_NUM_BTN_EVENT_ID  ((1 << CY_BITS_PER_BTN) - 1)
> +
> +#define MAX_AREA 255
> +#define HID_OUTPUT_BL_SOP0x1
> +#define HID_OUTPUT_BL_EOP0x17
> +#define HID_OUTPUT_BL_LAUNCH_APP 0x3B
> +#define HID_OUTPUT_BL_LAUNCH_APP_SIZE11
> +#define HID_OUTPUT_GET_SYSINFO   0x2
> +#define HID_OUTPUT_GET_SYSINFO_SIZE  5
> +
> +#define HID_DESC_REG 0x1
> +#define HID_INPUT_REG0x3
> +#define HID_OUTPUT_REG   0x4
> +
> +#define REPORT_ID_TOUCH   

Re: [PATCH v4 1/2] Input: Add driver for Cypress Generation 5 touchscreen

[Dmitry Torokhov]

Hi Mylène,

On Fri, Dec 01, 2017 at 04:39:56PM +0100, Mylène Josserand wrote:
> This is the basic driver for the Cypress TrueTouch Gen5 touchscreen
> controllers. This driver supports only the I2C bus but it uses regmap
> so SPI support could be added later.
> The touchscreen can retrieve some defined zone that are handled as
> buttons (according to the hardware). That is why it handles
> button and multitouch events.
> 
> Reviewed-by: Maxime Ripard 
> Signed-off-by: Mylène Josserand 
> ---
>  drivers/input/touchscreen/Kconfig   |   16 +
>  drivers/input/touchscreen/Makefile  |1 +
>  drivers/input/touchscreen/cyttsp5.c | 1110 
> +++
>  3 files changed, 1127 insertions(+)
>  create mode 100644 drivers/input/touchscreen/cyttsp5.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 0cfdb7cb610e..28eea6d5f1bb 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -238,6 +238,22 @@ config TOUCHSCREEN_CYTTSP4_SPI
> To compile this driver as a module, choose M here: the
> module will be called cyttsp4_spi.
>  
> +config TOUCHSCREEN_CYTTSP5
> + tristate "Cypress TrueTouch Gen5 Touchscreen Driver"
> + depends on OF

Does it have to be? Please use generic device properties
(device_property_* API) and it can be used with ACPI and static board
files, of needed.

> + select REGMAP_I2C
> + select CRC_ITU_T
> + help
> +   Driver for Parade TrueTouch Standard Product
> +   Generation 5 touchscreen controllers.
> +   I2C bus interface support only.
> +
> +   Say Y here if you have a Cypress Gen5 touchscreen.
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called cyttsp5.
> +
>  config TOUCHSCREEN_DA9034
>   tristate "Touchscreen support for Dialog Semiconductor DA9034"
>   depends on PMIC_DA903X
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index d2a2b3b7af27..e7d124901dd9 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_TOUCHSCREEN_CYTTSP_SPI)+= cyttsp_spi.o
>  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_CORE)   += cyttsp4_core.o
>  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_I2C)+= cyttsp4_i2c.o 
> cyttsp_i2c_common.o
>  obj-$(CONFIG_TOUCHSCREEN_CYTTSP4_SPI)+= cyttsp4_spi.o
> +obj-$(CONFIG_TOUCHSCREEN_CYTTSP5)+= cyttsp5.o
>  obj-$(CONFIG_TOUCHSCREEN_DA9034) += da9034-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_DA9052) += da9052_tsi.o
>  obj-$(CONFIG_TOUCHSCREEN_DYNAPRO)+= dynapro.o
> diff --git a/drivers/input/touchscreen/cyttsp5.c 
> b/drivers/input/touchscreen/cyttsp5.c
> new file mode 100644
> index ..a41feea2cd5a
> --- /dev/null
> +++ b/drivers/input/touchscreen/cyttsp5.c
> @@ -0,0 +1,1110 @@
> +/*
> + * Parade TrueTouch(TM) Standard Product V5 Module.
> + * For use with Parade touchscreen controllers.
> + *
> + * Copyright (C) 2015 Parade Technologies
> + * Copyright (C) 2012-2015 Cypress Semiconductor
> + * Copyright (C) 2017 Free Electrons
> + *
> + * Author: Mylène Josserand 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2, and only version 2, as published by the
> + * Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CYTTSP5_NAME "cyttsp5"
> +#define CY_I2C_DATA_SIZE (2 * 256)
> +#define HID_VERSION  0x0100
> +#define CY_MAX_INPUT 512
> +#define CYTTSP5_PREALLOCATED_CMD_BUFFER  32
> +#define CY_BITS_PER_BTN  1
> +#define CY_NUM_BTN_EVENT_ID  ((1 << CY_BITS_PER_BTN) - 1)
> +
> +#define MAX_AREA 255
> +#define HID_OUTPUT_BL_SOP0x1
> +#define HID_OUTPUT_BL_EOP0x17
> +#define HID_OUTPUT_BL_LAUNCH_APP 0x3B
> +#define HID_OUTPUT_BL_LAUNCH_APP_SIZE11
> +#define HID_OUTPUT_GET_SYSINFO   0x2
> +#define HID_OUTPUT_GET_SYSINFO_SIZE  5
> +
> +#define HID_DESC_REG 0x1
> +#define HID_INPUT_REG0x3
> +#define HID_OUTPUT_REG   0x4
> +
> +#define REPORT_ID_TOUCH  0x1
> +#define REPORT_ID_BTN0x3
> +#define REPORT_SIZE_5 

Re: [patch v9 0/4] drivers/platform: Replace module x86/mlxcpld-hotplug with mellanox/mlxreg-hotplug

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:52PM +, Vadim Pasternak wrote:
> The patchset:
>  - replaces modules include/linux/platform_data/mlxcpld-hotplug.h and
>drivers/platform/x86/mlxcpld-hotplug.c with the modules
>include/linux/platform_data/mlxreg.h and
>drivers/platform/mellanox/mlxreg-hotplug.c;
>relevant Makefile and Kconfig are updated;
>  - modifies Mellanox hotplug driver for making it architecture
>independent. Drivers has been tested for x86 and ARM based systems.
>  - includes code cleanup;
>  - introduces regmap interface for mlxreg-hotplug driver to allow hotplug
>event functionality over programmable devices logic, when these devices
>can be attached to different interfaces types, like I2C, LPC, SPI;
>driver drivers/platform/x86/mlx-platform.c is updated according to new
>interface.

This series is still not dividing up changes into small functional chunks. It
"ping pongs" (adding then later removing code), and makes it difficult to review
functional changes by surrounding them with non-functional transformations. As
I've attempted to break this apart myself, I've discovered a few issues with the
code - see the responses to the individual patches.

You can find my broken up version here:
http://git.infradead.org/linux-platform-drivers-x86.git/shortlog/refs/heads/review-dvhart-mellanox-v10

In particular, please see:
http://git.infradead.org/linux-platform-drivers-x86.git/commit/4f0057fc3da29c04e2cefca9dc5b17577b3e4988

Vadim, please respond to my questions re the individual patches, and I'll
increment the patches in the above branch before pushing this up to testing.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 0/4] drivers/platform: Replace module x86/mlxcpld-hotplug with mellanox/mlxreg-hotplug

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:52PM +, Vadim Pasternak wrote:
> The patchset:
>  - replaces modules include/linux/platform_data/mlxcpld-hotplug.h and
>drivers/platform/x86/mlxcpld-hotplug.c with the modules
>include/linux/platform_data/mlxreg.h and
>drivers/platform/mellanox/mlxreg-hotplug.c;
>relevant Makefile and Kconfig are updated;
>  - modifies Mellanox hotplug driver for making it architecture
>independent. Drivers has been tested for x86 and ARM based systems.
>  - includes code cleanup;
>  - introduces regmap interface for mlxreg-hotplug driver to allow hotplug
>event functionality over programmable devices logic, when these devices
>can be attached to different interfaces types, like I2C, LPC, SPI;
>driver drivers/platform/x86/mlx-platform.c is updated according to new
>interface.

This series is still not dividing up changes into small functional chunks. It
"ping pongs" (adding then later removing code), and makes it difficult to review
functional changes by surrounding them with non-functional transformations. As
I've attempted to break this apart myself, I've discovered a few issues with the
code - see the responses to the individual patches.

You can find my broken up version here:
http://git.infradead.org/linux-platform-drivers-x86.git/shortlog/refs/heads/review-dvhart-mellanox-v10

In particular, please see:
http://git.infradead.org/linux-platform-drivers-x86.git/commit/4f0057fc3da29c04e2cefca9dc5b17577b3e4988

Vadim, please respond to my questions re the individual patches, and I'll
increment the patches in the above branch before pushing this up to testing.

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH] x86/ftrace: Fix ORC unwinding from ftrace handlers

[Josh Poimboeuf]

Steven Rostedt discovered that the ftrace stack tracer is broken when
it's used with the ORC unwinder.  The problem is that objtool is
instructed by the Makefile to ignore the ftrace_64.S code, so it doesn't
generate any ORC data for it.

Fix it by making the asm code objtool-friendly:

- Objtool doesn't like the fact that save_mcount_regs pushes RBP at the
  beginning, but it's never restored (directly, at least).  So just skip
  the original RBP push, which is only needed for frame pointers anyway.

- Annotate some functions as normal callable functions with
  ENTRY/ENDPROC.

- Add an empty unwind hint to return_to_handler().  The return address
  isn't on the stack, so there's nothing ORC can do there.  It will just
  punt in the unlikely case it tries to unwind from that code.

With all that fixed, remove the OBJECT_FILES_NON_STANDARD Makefile
annotation so objtool can read the file.

Reported-by: Steven Rostedt 
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/kernel/Makefile|  5 -
 arch/x86/kernel/ftrace_64.S | 24 +++-
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index aed9296dccd3..29786c87e864 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -29,10 +29,13 @@ KASAN_SANITIZE_stacktrace.o := n
 KASAN_SANITIZE_paravirt.o  := n
 
 OBJECT_FILES_NON_STANDARD_relocate_kernel_$(BITS).o:= y
-OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
 OBJECT_FILES_NON_STANDARD_test_nx.o:= y
 OBJECT_FILES_NON_STANDARD_paravirt_patch_$(BITS).o := y
 
+ifdef CONFIG_FRAME_POINTER
+OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
+endif
+
 # If instrumentation of this dir is enabled, boot hangs during first second.
 # Probably could be more selective here, but note that files related to irqs,
 # boot, dumpstack/stacktrace, etc are either non-interesting or can lead to
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 7cb8ba08beb9..ef61f540cf0a 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
.code64
.section .entry.text, "ax"
@@ -20,7 +21,6 @@ EXPORT_SYMBOL(__fentry__)
 EXPORT_SYMBOL(mcount)
 #endif
 
-/* All cases save the original rbp (8 bytes) */
 #ifdef CONFIG_FRAME_POINTER
 # ifdef CC_USING_FENTRY
 /* Save parent and function stack frames (rip and rbp) */
@@ -31,7 +31,7 @@ EXPORT_SYMBOL(mcount)
 # endif
 #else
 /* No need to save a stack frame */
-# define MCOUNT_FRAME_SIZE 8
+# define MCOUNT_FRAME_SIZE 0
 #endif /* CONFIG_FRAME_POINTER */
 
 /* Size of stack used to save mcount regs in save_mcount_regs */
@@ -64,10 +64,10 @@ EXPORT_SYMBOL(mcount)
  */
 .macro save_mcount_regs added=0
 
-   /* Always save the original rbp */
+#ifdef CONFIG_FRAME_POINTER
+   /* Save the original rbp */
pushq %rbp
 
-#ifdef CONFIG_FRAME_POINTER
/*
 * Stack traces will stop at the ftrace trampoline if the frame pointer
 * is not set up properly. If fentry is used, we need to save a frame
@@ -105,7 +105,11 @@ EXPORT_SYMBOL(mcount)
 * Save the original RBP. Even though the mcount ABI does not
 * require this, it helps out callers.
 */
+#ifdef CONFIG_FRAME_POINTER
movq MCOUNT_REG_SIZE-8(%rsp), %rdx
+#else
+   movq %rbp, %rdx
+#endif
movq %rdx, RBP(%rsp)
 
/* Copy the parent address into %rsi (second parameter) */
@@ -148,7 +152,7 @@ EXPORT_SYMBOL(mcount)
 
 ENTRY(function_hook)
retq
-END(function_hook)
+ENDPROC(function_hook)
 
 ENTRY(ftrace_caller)
/* save_mcount_regs fills in first two parameters */
@@ -184,7 +188,7 @@ GLOBAL(ftrace_graph_call)
 /* This is weak to keep gas from relaxing the jumps */
 WEAK(ftrace_stub)
retq
-END(ftrace_caller)
+ENDPROC(ftrace_caller)
 
 ENTRY(ftrace_regs_caller)
/* Save the current flags before any operations that can change them */
@@ -255,7 +259,7 @@ GLOBAL(ftrace_regs_caller_end)
 
jmp ftrace_epilogue
 
-END(ftrace_regs_caller)
+ENDPROC(ftrace_regs_caller)
 
 
 #else /* ! CONFIG_DYNAMIC_FTRACE */
@@ -313,9 +317,10 @@ ENTRY(ftrace_graph_caller)
restore_mcount_regs
 
retq
-END(ftrace_graph_caller)
+ENDPROC(ftrace_graph_caller)
 
-GLOBAL(return_to_handler)
+ENTRY(return_to_handler)
+   UNWIND_HINT_EMPTY
subq  $24, %rsp
 
/* Save the return values */
@@ -330,4 +335,5 @@ GLOBAL(return_to_handler)
movq (%rsp), %rax
addq $24, %rsp
JMP_NOSPEC %rdi
+END(return_to_handler)
 #endif
-- 
2.14.3

[PATCH] x86/ftrace: Fix ORC unwinding from ftrace handlers

[Josh Poimboeuf]

Steven Rostedt discovered that the ftrace stack tracer is broken when
it's used with the ORC unwinder.  The problem is that objtool is
instructed by the Makefile to ignore the ftrace_64.S code, so it doesn't
generate any ORC data for it.

Fix it by making the asm code objtool-friendly:

- Objtool doesn't like the fact that save_mcount_regs pushes RBP at the
  beginning, but it's never restored (directly, at least).  So just skip
  the original RBP push, which is only needed for frame pointers anyway.

- Annotate some functions as normal callable functions with
  ENTRY/ENDPROC.

- Add an empty unwind hint to return_to_handler().  The return address
  isn't on the stack, so there's nothing ORC can do there.  It will just
  punt in the unlikely case it tries to unwind from that code.

With all that fixed, remove the OBJECT_FILES_NON_STANDARD Makefile
annotation so objtool can read the file.

Reported-by: Steven Rostedt 
Signed-off-by: Josh Poimboeuf 
---
 arch/x86/kernel/Makefile|  5 -
 arch/x86/kernel/ftrace_64.S | 24 +++-
 2 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index aed9296dccd3..29786c87e864 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -29,10 +29,13 @@ KASAN_SANITIZE_stacktrace.o := n
 KASAN_SANITIZE_paravirt.o  := n
 
 OBJECT_FILES_NON_STANDARD_relocate_kernel_$(BITS).o:= y
-OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
 OBJECT_FILES_NON_STANDARD_test_nx.o:= y
 OBJECT_FILES_NON_STANDARD_paravirt_patch_$(BITS).o := y
 
+ifdef CONFIG_FRAME_POINTER
+OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
+endif
+
 # If instrumentation of this dir is enabled, boot hangs during first second.
 # Probably could be more selective here, but note that files related to irqs,
 # boot, dumpstack/stacktrace, etc are either non-interesting or can lead to
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 7cb8ba08beb9..ef61f540cf0a 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 
.code64
.section .entry.text, "ax"
@@ -20,7 +21,6 @@ EXPORT_SYMBOL(__fentry__)
 EXPORT_SYMBOL(mcount)
 #endif
 
-/* All cases save the original rbp (8 bytes) */
 #ifdef CONFIG_FRAME_POINTER
 # ifdef CC_USING_FENTRY
 /* Save parent and function stack frames (rip and rbp) */
@@ -31,7 +31,7 @@ EXPORT_SYMBOL(mcount)
 # endif
 #else
 /* No need to save a stack frame */
-# define MCOUNT_FRAME_SIZE 8
+# define MCOUNT_FRAME_SIZE 0
 #endif /* CONFIG_FRAME_POINTER */
 
 /* Size of stack used to save mcount regs in save_mcount_regs */
@@ -64,10 +64,10 @@ EXPORT_SYMBOL(mcount)
  */
 .macro save_mcount_regs added=0
 
-   /* Always save the original rbp */
+#ifdef CONFIG_FRAME_POINTER
+   /* Save the original rbp */
pushq %rbp
 
-#ifdef CONFIG_FRAME_POINTER
/*
 * Stack traces will stop at the ftrace trampoline if the frame pointer
 * is not set up properly. If fentry is used, we need to save a frame
@@ -105,7 +105,11 @@ EXPORT_SYMBOL(mcount)
 * Save the original RBP. Even though the mcount ABI does not
 * require this, it helps out callers.
 */
+#ifdef CONFIG_FRAME_POINTER
movq MCOUNT_REG_SIZE-8(%rsp), %rdx
+#else
+   movq %rbp, %rdx
+#endif
movq %rdx, RBP(%rsp)
 
/* Copy the parent address into %rsi (second parameter) */
@@ -148,7 +152,7 @@ EXPORT_SYMBOL(mcount)
 
 ENTRY(function_hook)
retq
-END(function_hook)
+ENDPROC(function_hook)
 
 ENTRY(ftrace_caller)
/* save_mcount_regs fills in first two parameters */
@@ -184,7 +188,7 @@ GLOBAL(ftrace_graph_call)
 /* This is weak to keep gas from relaxing the jumps */
 WEAK(ftrace_stub)
retq
-END(ftrace_caller)
+ENDPROC(ftrace_caller)
 
 ENTRY(ftrace_regs_caller)
/* Save the current flags before any operations that can change them */
@@ -255,7 +259,7 @@ GLOBAL(ftrace_regs_caller_end)
 
jmp ftrace_epilogue
 
-END(ftrace_regs_caller)
+ENDPROC(ftrace_regs_caller)
 
 
 #else /* ! CONFIG_DYNAMIC_FTRACE */
@@ -313,9 +317,10 @@ ENTRY(ftrace_graph_caller)
restore_mcount_regs
 
retq
-END(ftrace_graph_caller)
+ENDPROC(ftrace_graph_caller)
 
-GLOBAL(return_to_handler)
+ENTRY(return_to_handler)
+   UNWIND_HINT_EMPTY
subq  $24, %rsp
 
/* Save the return values */
@@ -330,4 +335,5 @@ GLOBAL(return_to_handler)
movq (%rsp), %rax
addq $24, %rsp
JMP_NOSPEC %rdi
+END(return_to_handler)
 #endif
-- 
2.14.3

Re: [patch v9 3/4] platform/mellanox: mlxreg-hotplug: Code cleanup

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:55PM +, Vadim Pasternak wrote:
> Removing unnecessary includes.
...
> diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c 
> b/drivers/platform/mellanox/mlxreg-hotplug.c
> index 2866c76..556e612 100644
> --- a/drivers/platform/mellanox/mlxreg-hotplug.c
> +++ b/drivers/platform/mellanox/mlxreg-hotplug.c
> @@ -41,8 +41,6 @@
>  #include 
>  #include 
>  #include 
> -#include 

But spinlock IS required. Just because some other include eventually also
includes it doesn't meet we can drop it here. We use functions defined in
spinlock.h, so it needs to be included.

I've updated this in my branch...

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 3/4] platform/mellanox: mlxreg-hotplug: Code cleanup

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:55PM +, Vadim Pasternak wrote:
> Removing unnecessary includes.
...
> diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c 
> b/drivers/platform/mellanox/mlxreg-hotplug.c
> index 2866c76..556e612 100644
> --- a/drivers/platform/mellanox/mlxreg-hotplug.c
> +++ b/drivers/platform/mellanox/mlxreg-hotplug.c
> @@ -41,8 +41,6 @@
>  #include 
>  #include 
>  #include 
> -#include 

But spinlock IS required. Just because some other include eventually also
includes it doesn't meet we can drop it here. We use functions defined in
spinlock.h, so it needs to be included.

I've updated this in my branch...

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 3/4] platform/mellanox: mlxreg-hotplug: Code cleanup

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:55PM +, Vadim Pasternak wrote:

As I continue to pick these patches apart into their individual functional
changes, I'm finding more issues...

> Renaming field bus in structure mlxreg_hotplug_device to nr to have a name
> consistent with Linux i2c naming.
> 
> Removing unnecessary includes.
> 
> Removing from mlxreg_hotplug_device_create dev_err to upper layer should
> produce error on EFAULT return.
> 

But the only caller doesn't check the return code. Where did you expect for this
error to be detected?

> Relocation mlxreg_hotplug_device_create/destroy to the beginning of the
> mlxreg-hotplug.c in order to have attribute related code at the same
> location.
> 
> Add to structure mlxreg_hotplug_device device node handle for devices
> defined in device table tree;
> 

The above should *really* be several changes. Start with the non-functional
preparatory changes, followed by single functional change. Also, it seems to me
adding the device node prior to enabling building on ARM would make sense??

I've broken this up, verified incremental build, and rewritten the commit
messages. I have this sitting in a local branch currently.

I need you to respond to the question above re the create call, but I'll make
the change myself.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 3/4] platform/mellanox: mlxreg-hotplug: Code cleanup

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:55PM +, Vadim Pasternak wrote:

As I continue to pick these patches apart into their individual functional
changes, I'm finding more issues...

> Renaming field bus in structure mlxreg_hotplug_device to nr to have a name
> consistent with Linux i2c naming.
> 
> Removing unnecessary includes.
> 
> Removing from mlxreg_hotplug_device_create dev_err to upper layer should
> produce error on EFAULT return.
> 

But the only caller doesn't check the return code. Where did you expect for this
error to be detected?

> Relocation mlxreg_hotplug_device_create/destroy to the beginning of the
> mlxreg-hotplug.c in order to have attribute related code at the same
> location.
> 
> Add to structure mlxreg_hotplug_device device node handle for devices
> defined in device table tree;
> 

The above should *really* be several changes. Start with the non-functional
preparatory changes, followed by single functional change. Also, it seems to me
adding the device node prior to enabling building on ARM would make sense??

I've broken this up, verified incremental build, and rewritten the commit
messages. I have this sitting in a local branch currently.

I need you to respond to the question above re the create call, but I'll make
the change myself.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 1/4] platform/x86: Move Mellanox hardware platform hotplug driver to platform/mellanox

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:53PM +, Vadim Pasternak wrote:
> It moves drivers/platform/x86/mlxcpld-hotplug.c to
> drivers/platform/mellanox/mlxreg-hotplug.c and
> include/linux/platform_data/mlxcpld-hotplug.h to
> include/linux/platform_data/mlxreg.h for making hotplug driver usable for
> the different machine architectures.
> 
> Signed-off-by: Vadim Pasternak 
> Acked-by: Andy Shevchenko 
> ---
> v9->v8:
>  Comments pointed out by Darren:
>  - make removing of X86_64 dependency of mlx-platform to a separate patch
>since it is not related to the moving hotplug driver to
>platform/mellanox;
> v7->v8:
> v6->v7:
>  Fixes added by Vadim:
>  - remove dependency on X86_64 to allow also X86 architecture;
> v5->v6:
>  Fixes added by Vadim:
>  - add SPD license record to Kconfig and Makefile;
> v4->v5:
>  Comments pointed out by Andy:
>  - arrange MAINTAINERS in correct alphabetic order;
> v3->v4:
>  Comments pointed out by Darren:
>  - Refactor the patches to provide the changes in patchset in incremental
>order;
>  - Modify MAINTAINERS records;
>  - Use git-mv for the replaced files;
>   Commnets pointed out by Colin:
>  - Make structures mlxplat_dev and mlxplat_hotplug static;
> ---
>  MAINTAINERS|   7 +-
>  drivers/platform/Kconfig   |   2 +
>  drivers/platform/Makefile  |   1 +
>  drivers/platform/mellanox/Kconfig  |  25 +++
>  drivers/platform/mellanox/Makefile |   6 +
>  .../mlxreg-hotplug.c}  | 223 
> ++---
>  drivers/platform/x86/Kconfig   |   8 -
>  drivers/platform/x86/Makefile  |   1 -
>  drivers/platform/x86/mlx-platform.c|  18 +-
>  .../platform_data/{mlxcpld-hotplug.h => mlxreg.h}  |  25 ++-
>  10 files changed, 170 insertions(+), 146 deletions(-)
>  create mode 100644 drivers/platform/mellanox/Kconfig
>  create mode 100644 drivers/platform/mellanox/Makefile
>  rename drivers/platform/{x86/mlxcpld-hotplug.c => mellanox/mlxreg-hotplug.c} 
> (65%)
>  rename include/linux/platform_data/{mlxcpld-hotplug.h => mlxreg.h} (84%)
> 

...

> diff --git a/drivers/platform/x86/mlxcpld-hotplug.c 
> b/drivers/platform/mellanox/mlxreg-hotplug.c
> similarity index 65%
> rename from drivers/platform/x86/mlxcpld-hotplug.c
> rename to drivers/platform/mellanox/mlxreg-hotplug.c
> index aff3686..2866c76 100644
> --- a/drivers/platform/x86/mlxcpld-hotplug.c
> +++ b/drivers/platform/mellanox/mlxreg-hotplug.c
> @@ -1,7 +1,6 @@
>  /*
> - * drivers/platform/x86/mlxcpld-hotplug.c
> - * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
> - * Copyright (c) 2016 Vadim Pasternak 
> + * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
> + * Copyright (c) 2017 Vadim Pasternak 

Copyright should persist across git rename. I've updated this to 2016-2018 on
both lines.

>  /* Offset of event and mask registers from status register */
> -#define MLXCPLD_HOTPLUG_EVENT_OFF1
> -#define MLXCPLD_HOTPLUG_MASK_OFF 2
> -#define MLXCPLD_HOTPLUG_AGGR_MASK_OFF1
> +#define MLXREG_HOTPLUG_EVENT_OFF 1
> +#define MLXREG_HOTPLUG_MASK_OFF  2
> +#define MLXREG_HOTPLUG_AGGR_MASK_OFF 1

This, and much of what follows, is an additional change from the move, but it is
not called out in the changelog. I've added a note to the changelog about
renaming from MLXCPLD to MLXREG.

No need to resend.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 1/4] platform/x86: Move Mellanox hardware platform hotplug driver to platform/mellanox

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:53PM +, Vadim Pasternak wrote:
> It moves drivers/platform/x86/mlxcpld-hotplug.c to
> drivers/platform/mellanox/mlxreg-hotplug.c and
> include/linux/platform_data/mlxcpld-hotplug.h to
> include/linux/platform_data/mlxreg.h for making hotplug driver usable for
> the different machine architectures.
> 
> Signed-off-by: Vadim Pasternak 
> Acked-by: Andy Shevchenko 
> ---
> v9->v8:
>  Comments pointed out by Darren:
>  - make removing of X86_64 dependency of mlx-platform to a separate patch
>since it is not related to the moving hotplug driver to
>platform/mellanox;
> v7->v8:
> v6->v7:
>  Fixes added by Vadim:
>  - remove dependency on X86_64 to allow also X86 architecture;
> v5->v6:
>  Fixes added by Vadim:
>  - add SPD license record to Kconfig and Makefile;
> v4->v5:
>  Comments pointed out by Andy:
>  - arrange MAINTAINERS in correct alphabetic order;
> v3->v4:
>  Comments pointed out by Darren:
>  - Refactor the patches to provide the changes in patchset in incremental
>order;
>  - Modify MAINTAINERS records;
>  - Use git-mv for the replaced files;
>   Commnets pointed out by Colin:
>  - Make structures mlxplat_dev and mlxplat_hotplug static;
> ---
>  MAINTAINERS|   7 +-
>  drivers/platform/Kconfig   |   2 +
>  drivers/platform/Makefile  |   1 +
>  drivers/platform/mellanox/Kconfig  |  25 +++
>  drivers/platform/mellanox/Makefile |   6 +
>  .../mlxreg-hotplug.c}  | 223 
> ++---
>  drivers/platform/x86/Kconfig   |   8 -
>  drivers/platform/x86/Makefile  |   1 -
>  drivers/platform/x86/mlx-platform.c|  18 +-
>  .../platform_data/{mlxcpld-hotplug.h => mlxreg.h}  |  25 ++-
>  10 files changed, 170 insertions(+), 146 deletions(-)
>  create mode 100644 drivers/platform/mellanox/Kconfig
>  create mode 100644 drivers/platform/mellanox/Makefile
>  rename drivers/platform/{x86/mlxcpld-hotplug.c => mellanox/mlxreg-hotplug.c} 
> (65%)
>  rename include/linux/platform_data/{mlxcpld-hotplug.h => mlxreg.h} (84%)
> 

...

> diff --git a/drivers/platform/x86/mlxcpld-hotplug.c 
> b/drivers/platform/mellanox/mlxreg-hotplug.c
> similarity index 65%
> rename from drivers/platform/x86/mlxcpld-hotplug.c
> rename to drivers/platform/mellanox/mlxreg-hotplug.c
> index aff3686..2866c76 100644
> --- a/drivers/platform/x86/mlxcpld-hotplug.c
> +++ b/drivers/platform/mellanox/mlxreg-hotplug.c
> @@ -1,7 +1,6 @@
>  /*
> - * drivers/platform/x86/mlxcpld-hotplug.c
> - * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
> - * Copyright (c) 2016 Vadim Pasternak 
> + * Copyright (c) 2017 Mellanox Technologies. All rights reserved.
> + * Copyright (c) 2017 Vadim Pasternak 

Copyright should persist across git rename. I've updated this to 2016-2018 on
both lines.

>  /* Offset of event and mask registers from status register */
> -#define MLXCPLD_HOTPLUG_EVENT_OFF1
> -#define MLXCPLD_HOTPLUG_MASK_OFF 2
> -#define MLXCPLD_HOTPLUG_AGGR_MASK_OFF1
> +#define MLXREG_HOTPLUG_EVENT_OFF 1
> +#define MLXREG_HOTPLUG_MASK_OFF  2
> +#define MLXREG_HOTPLUG_AGGR_MASK_OFF 1

This, and much of what follows, is an additional change from the move, but it is
not called out in the changelog. I've added a note to the changelog about
renaming from MLXCPLD to MLXREG.

No need to resend.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 4/4] platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface

[Darren Hart]

On Mon, Jan 22, 2018 at 07:49:46PM -0800, Darren Hart wrote:
> On Wed, Jan 17, 2018 at 06:21:56PM +, Vadim Pasternak wrote:
> > +#define MLXREG_CORE_LABEL_MAX_SIZE 32
> > +
> >  /**
> >   * struct mlxreg_hotplug_device - I2C device data:
> > + *
> >   * @adapter: I2C device adapter;
> >   * @client: I2C device client;
> >   * @brdinfo: device board information;
> >   * @nr: I2C device adapter number, to which device is to be attached;
> > - * @np - pointer to node platform associated with attribute;
> 
> We just added this in 3/4. This should have just been skipped and done as it 
> is
> here directly, and only enabling ARM support at the end.

Apologies, I was still working on this email when I accidentally sent it instead
of postponing it. The above is true, but I'm working on fixing it in my branch.

No need to resend at this point.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 4/4] platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface

[Darren Hart]

On Mon, Jan 22, 2018 at 07:49:46PM -0800, Darren Hart wrote:
> On Wed, Jan 17, 2018 at 06:21:56PM +, Vadim Pasternak wrote:
> > +#define MLXREG_CORE_LABEL_MAX_SIZE 32
> > +
> >  /**
> >   * struct mlxreg_hotplug_device - I2C device data:
> > + *
> >   * @adapter: I2C device adapter;
> >   * @client: I2C device client;
> >   * @brdinfo: device board information;
> >   * @nr: I2C device adapter number, to which device is to be attached;
> > - * @np - pointer to node platform associated with attribute;
> 
> We just added this in 3/4. This should have just been skipped and done as it 
> is
> here directly, and only enabling ARM support at the end.

Apologies, I was still working on this email when I accidentally sent it instead
of postponing it. The above is true, but I'm working on fixing it in my branch.

No need to resend at this point.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [patch v9 4/4] platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:56PM +, Vadim Pasternak wrote:
> Restructure mlxreg header for unification of hotplug item definitions.
> 
> Unify hotplug items to allow any kind of item (power controller, fan
> eeprom, psu eeprom, asic health) in common way.
> 
> Use a hardware independent regmap interface, enabling the support of
> hotplug events over programmable devices attached to different bus
> types, such as I2C, LPC, or SPI
> 
> [dvhart: Simplify exit path]
> Simplify exit path: Several functions use a "goto access_error" pattern
> result in a duplicated exit path at the end of the function. Address this
> by using a single exit path, and checking for (ret) prior to printing the
> error message. This adds a conditional, but only in the failure case, and
> simplifies the exit path.
> 
> [dvhart: Cleanup local variable declarations]
> Cleanup local variable declarations: Make the local variable declarations
> more consistent throughout the driver. Separate inline initial assignments
> when it cleans up the declaration block.
> 
> Signed-off-by: Vadim Pasternak 
> Acked-by: Andy Shevchenko 
> ---
> v8->v9:
>  Fixes provideded by Vadim:
>  - Simplify exit path in mlxreg-hotplug
>  - Cleanup local variable declarations
>driver. Separate inline initial assignments when it cleans up the
>declaration block.
> v7->v8
> v6->v7
>  Fixes added by Vadim:
>  - Remove include  in mlxreg-hotplug.c in this patch.
> v5->v6:
>  Fixes added by Vadim:
>  - rename mlxreg_core_led_platform_data to common name
>mlxreg_core_platform_data;
>  - add cell_low and mask_low fields to
>mlxreg_core_hotplug_platform_data for low aggregation interrupt
>registers and check for these fields in mlxreg_hotplug_set_irq and
>mlxreg_hotplug_unset_irq;
> v4->v5:
>  Comments pointed out by Andy:
>  - use suffix OFFSET instead of ADDR for aggregation registers;
>  - return back MACROS;
>  - rearrange mlxreg_hotplug_attr_init routine;
> ---
>  drivers/platform/mellanox/Kconfig  |   1 +
>  drivers/platform/mellanox/mlxreg-hotplug.c | 608 
> +
>  drivers/platform/x86/mlx-platform.c| 231 ---
>  include/linux/platform_data/mlxreg.h   | 126 --
>  4 files changed, 630 insertions(+), 336 deletions(-)
> 
> diff --git a/drivers/platform/mellanox/Kconfig 
> b/drivers/platform/mellanox/Kconfig
> index 0267e1d..591bccd 100644
> --- a/drivers/platform/mellanox/Kconfig
> +++ b/drivers/platform/mellanox/Kconfig
> @@ -16,6 +16,7 @@ if MELLANOX_PLATFORM
>  
>  config MLXREG_HOTPLUG
>   tristate "Mellanox platform hotplug driver support"
> + depends on REGMAP
>   depends on HWMON
>   depends on I2C
>   ---help---
> diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c 
> b/drivers/platform/mellanox/mlxreg-hotplug.c
> index 556e612..18f3f3f 100644
> --- a/drivers/platform/mellanox/mlxreg-hotplug.c
> +++ b/drivers/platform/mellanox/mlxreg-hotplug.c
> @@ -37,92 +37,88 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> -/* Offset of event and mask registers from status register */
> +/* Offset of event and mask registers from status register. */
>  #define MLXREG_HOTPLUG_EVENT_OFF 1
> -#define MLXREG_HOTPLUG_MASK_OFF  2
> +#define MLXREG_HOTPLUG_MASK_OFF  2
>  #define MLXREG_HOTPLUG_AGGR_MASK_OFF 1
>  
> -#define MLXREG_HOTPLUG_ATTRS_NUM 8
> +/* ASIC health parameters. */
> +#define MLXREG_HOTPLUG_HEALTH_MASK   0x02
> +#define MLXREG_HOTPLUG_RST_CNTR  3
>  
> -/**
> - * enum mlxreg_hotplug_attr_type - sysfs attributes for hotplug events:
> - * @MLXREG_HOTPLUG_ATTR_TYPE_PSU: power supply unit attribute;
> - * @MLXREG_HOTPLUG_ATTR_TYPE_PWR: power cable attribute;
> - * @MLXREG_HOTPLUG_ATTR_TYPE_FAN: FAN drawer attribute;
> - */
> -enum mlxreg_hotplug_attr_type {
> - MLXREG_HOTPLUG_ATTR_TYPE_PSU,
> - MLXREG_HOTPLUG_ATTR_TYPE_PWR,
> - MLXREG_HOTPLUG_ATTR_TYPE_FAN,
> -};
> +#define MLXREG_HOTPLUG_ATTRS_MAX 24
>  
>  /**
>   * struct mlxreg_hotplug_priv_data - platform private data:
> - * @irq: platform interrupt number;
> + * @irq: platform device interrupt number;
>   * @pdev: platform device;
>   * @plat: platform data;
> + * @dwork: delayed work template;
> + * @lock: spin lock;
>   * @hwmon: hwmon device;
>   * @mlxreg_hotplug_attr: sysfs attributes array;
>   * @mlxreg_hotplug_dev_attr: sysfs sensor device attribute array;
>   * @group: sysfs attribute group;
>   * @groups: list of sysfs attribute group for hwmon registration;
> - * @dwork: delayed work template;
> - * @lock: spin lock;
> + * @cell: location of top aggregation interrupt register;
> + * @mask: top aggregation interrupt common mask;
>   * @aggr_cache: last value of aggregation register status;
> - * @psu_cache: last value of PSU register status;
> - * @pwr_cache: last value of power register status;
> - * 

Re: [patch v9 4/4] platform/mellanox: mlxreg-hotplug: Modify to use a regmap interface

[Darren Hart]

On Wed, Jan 17, 2018 at 06:21:56PM +, Vadim Pasternak wrote:
> Restructure mlxreg header for unification of hotplug item definitions.
> 
> Unify hotplug items to allow any kind of item (power controller, fan
> eeprom, psu eeprom, asic health) in common way.
> 
> Use a hardware independent regmap interface, enabling the support of
> hotplug events over programmable devices attached to different bus
> types, such as I2C, LPC, or SPI
> 
> [dvhart: Simplify exit path]
> Simplify exit path: Several functions use a "goto access_error" pattern
> result in a duplicated exit path at the end of the function. Address this
> by using a single exit path, and checking for (ret) prior to printing the
> error message. This adds a conditional, but only in the failure case, and
> simplifies the exit path.
> 
> [dvhart: Cleanup local variable declarations]
> Cleanup local variable declarations: Make the local variable declarations
> more consistent throughout the driver. Separate inline initial assignments
> when it cleans up the declaration block.
> 
> Signed-off-by: Vadim Pasternak 
> Acked-by: Andy Shevchenko 
> ---
> v8->v9:
>  Fixes provideded by Vadim:
>  - Simplify exit path in mlxreg-hotplug
>  - Cleanup local variable declarations
>driver. Separate inline initial assignments when it cleans up the
>declaration block.
> v7->v8
> v6->v7
>  Fixes added by Vadim:
>  - Remove include  in mlxreg-hotplug.c in this patch.
> v5->v6:
>  Fixes added by Vadim:
>  - rename mlxreg_core_led_platform_data to common name
>mlxreg_core_platform_data;
>  - add cell_low and mask_low fields to
>mlxreg_core_hotplug_platform_data for low aggregation interrupt
>registers and check for these fields in mlxreg_hotplug_set_irq and
>mlxreg_hotplug_unset_irq;
> v4->v5:
>  Comments pointed out by Andy:
>  - use suffix OFFSET instead of ADDR for aggregation registers;
>  - return back MACROS;
>  - rearrange mlxreg_hotplug_attr_init routine;
> ---
>  drivers/platform/mellanox/Kconfig  |   1 +
>  drivers/platform/mellanox/mlxreg-hotplug.c | 608 
> +
>  drivers/platform/x86/mlx-platform.c| 231 ---
>  include/linux/platform_data/mlxreg.h   | 126 --
>  4 files changed, 630 insertions(+), 336 deletions(-)
> 
> diff --git a/drivers/platform/mellanox/Kconfig 
> b/drivers/platform/mellanox/Kconfig
> index 0267e1d..591bccd 100644
> --- a/drivers/platform/mellanox/Kconfig
> +++ b/drivers/platform/mellanox/Kconfig
> @@ -16,6 +16,7 @@ if MELLANOX_PLATFORM
>  
>  config MLXREG_HOTPLUG
>   tristate "Mellanox platform hotplug driver support"
> + depends on REGMAP
>   depends on HWMON
>   depends on I2C
>   ---help---
> diff --git a/drivers/platform/mellanox/mlxreg-hotplug.c 
> b/drivers/platform/mellanox/mlxreg-hotplug.c
> index 556e612..18f3f3f 100644
> --- a/drivers/platform/mellanox/mlxreg-hotplug.c
> +++ b/drivers/platform/mellanox/mlxreg-hotplug.c
> @@ -37,92 +37,88 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
> -/* Offset of event and mask registers from status register */
> +/* Offset of event and mask registers from status register. */
>  #define MLXREG_HOTPLUG_EVENT_OFF 1
> -#define MLXREG_HOTPLUG_MASK_OFF  2
> +#define MLXREG_HOTPLUG_MASK_OFF  2
>  #define MLXREG_HOTPLUG_AGGR_MASK_OFF 1
>  
> -#define MLXREG_HOTPLUG_ATTRS_NUM 8
> +/* ASIC health parameters. */
> +#define MLXREG_HOTPLUG_HEALTH_MASK   0x02
> +#define MLXREG_HOTPLUG_RST_CNTR  3
>  
> -/**
> - * enum mlxreg_hotplug_attr_type - sysfs attributes for hotplug events:
> - * @MLXREG_HOTPLUG_ATTR_TYPE_PSU: power supply unit attribute;
> - * @MLXREG_HOTPLUG_ATTR_TYPE_PWR: power cable attribute;
> - * @MLXREG_HOTPLUG_ATTR_TYPE_FAN: FAN drawer attribute;
> - */
> -enum mlxreg_hotplug_attr_type {
> - MLXREG_HOTPLUG_ATTR_TYPE_PSU,
> - MLXREG_HOTPLUG_ATTR_TYPE_PWR,
> - MLXREG_HOTPLUG_ATTR_TYPE_FAN,
> -};
> +#define MLXREG_HOTPLUG_ATTRS_MAX 24
>  
>  /**
>   * struct mlxreg_hotplug_priv_data - platform private data:
> - * @irq: platform interrupt number;
> + * @irq: platform device interrupt number;
>   * @pdev: platform device;
>   * @plat: platform data;
> + * @dwork: delayed work template;
> + * @lock: spin lock;
>   * @hwmon: hwmon device;
>   * @mlxreg_hotplug_attr: sysfs attributes array;
>   * @mlxreg_hotplug_dev_attr: sysfs sensor device attribute array;
>   * @group: sysfs attribute group;
>   * @groups: list of sysfs attribute group for hwmon registration;
> - * @dwork: delayed work template;
> - * @lock: spin lock;
> + * @cell: location of top aggregation interrupt register;
> + * @mask: top aggregation interrupt common mask;
>   * @aggr_cache: last value of aggregation register status;
> - * @psu_cache: last value of PSU register status;
> - * @pwr_cache: last value of power register status;
> - * @fan_cache: last value of FAN register status;
>  

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

[Manu Gautam]

Hi,


On 1/22/2018 6:31 PM, Roger Quadros wrote:
> Adding/removing host/gadget controller before .pm_complete()
> causes a lock-up. Let's prevent any dual-role state change
> between .pm_prepare() and .pm_complete() to fix this.

What kind of lock-up are you seeing? Some hardware lockup or software deadlock?
IMO using a freezable_wq for drd_work should address that?


>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/dwc3/core.c | 31 +++
>  drivers/usb/dwc3/core.h |  5 +
>  drivers/usb/dwc3/drd.c  | 10 ++
>  3 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 42379cc..85388dd 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1414,6 +1414,33 @@ static int dwc3_runtime_idle(struct device *dev)
>  #endif /* CONFIG_PM */
>  
>  #ifdef CONFIG_PM_SLEEP
> +static int dwc3_prepare(struct device *dev)
> +{
> + struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long   flags;
> +
> + if (dwc->dr_mode == USB_DR_MODE_OTG) {
> + spin_lock_irqsave(>lock, flags);
> + dwc->dr_keep_role = true;
> + spin_unlock_irqrestore(>lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static void dwc3_complete(struct device *dev)
> +{
> + struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long   flags;
> +
> + if (dwc->dr_mode == USB_DR_MODE_OTG) {
> + spin_lock_irqsave(>lock, flags);
> + dwc->dr_keep_role = false;
> + spin_unlock_irqrestore(>lock, flags);
> + dwc3_drd_update(dwc);
> + }
> +}
> +
>  static int dwc3_suspend(struct device *dev)
>  {
>   struct dwc3 *dwc = dev_get_drvdata(dev);
> @@ -1451,6 +1478,10 @@ static const struct dev_pm_ops dwc3_dev_pm_ops = {
>   SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
>   SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
>   dwc3_runtime_idle)
> +#ifdef CONFIG_PM_SLEEP
> + .prepare = dwc3_prepare,
> + .complete = dwc3_complete,
> +#endif
>  };
>  
>  #ifdef CONFIG_OF
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 4a4a4c9..f5eb474 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -786,6 +786,7 @@ struct dwc3_scratchpad_array {
>   * @dr_mode: requested mode of operation
>   * @current_dr_role: current role of operation when in dual-role mode
>   * @desired_dr_role: desired role of operation when in dual-role mode
> + * @dr_keep_role: keep the current dual-role irrespective of ID changes
>   * @edev: extcon handle
>   * @edev_nb: extcon notifier
>   * @hsphy_mode: UTMI phy mode, one of following:
> @@ -901,6 +902,7 @@ struct dwc3 {
>   enum usb_dr_modedr_mode;
>   u32 current_dr_role;
>   u32 desired_dr_role;
> + booldr_keep_role;
>   struct extcon_dev   *edev;
>   struct notifier_block   edev_nb;
>   enum usb_phy_interface  hsphy_mode;
> @@ -1227,11 +1229,14 @@ static inline int 
> dwc3_send_gadget_generic_command(struct dwc3 *dwc,
>  #if IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
>  int dwc3_drd_init(struct dwc3 *dwc);
>  void dwc3_drd_exit(struct dwc3 *dwc);
> +void dwc3_drd_update(struct dwc3 *dwc);
>  #else
>  static inline int dwc3_drd_init(struct dwc3 *dwc)
>  { return 0; }
>  static inline void dwc3_drd_exit(struct dwc3 *dwc)
>  { }
> +static inline void dwc3_drd_update(struct dwc3 *dwc);
> +{ }
>  #endif
>  
>  /* power management interface */
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index cc8ab9a..177a8be 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -13,7 +13,7 @@
>  #include "core.h"
>  #include "gadget.h"
>  
> -static void dwc3_drd_update(struct dwc3 *dwc)
> +void dwc3_drd_update(struct dwc3 *dwc)
>  {
>   int id;
>  
> @@ -31,9 +31,11 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
>  {
>   struct dwc3 *dwc = container_of(nb, struct dwc3, edev_nb);
>  
> - dwc3_set_mode(dwc, event ?
> -   DWC3_GCTL_PRTCAP_HOST :
> -   DWC3_GCTL_PRTCAP_DEVICE);
> + if (!dwc->dr_keep_role) {
> + dwc3_set_mode(dwc, event ?
> +   DWC3_GCTL_PRTCAP_HOST :
> +   DWC3_GCTL_PRTCAP_DEVICE);
> + }
>  
>   return NOTIFY_DONE;
>  }

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/2] usb: dwc3: drd: Fix lock-up on ID change during system suspend/resume

[Manu Gautam]

Hi,


On 1/22/2018 6:31 PM, Roger Quadros wrote:
> Adding/removing host/gadget controller before .pm_complete()
> causes a lock-up. Let's prevent any dual-role state change
> between .pm_prepare() and .pm_complete() to fix this.

What kind of lock-up are you seeing? Some hardware lockup or software deadlock?
IMO using a freezable_wq for drd_work should address that?


>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/dwc3/core.c | 31 +++
>  drivers/usb/dwc3/core.h |  5 +
>  drivers/usb/dwc3/drd.c  | 10 ++
>  3 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 42379cc..85388dd 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1414,6 +1414,33 @@ static int dwc3_runtime_idle(struct device *dev)
>  #endif /* CONFIG_PM */
>  
>  #ifdef CONFIG_PM_SLEEP
> +static int dwc3_prepare(struct device *dev)
> +{
> + struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long   flags;
> +
> + if (dwc->dr_mode == USB_DR_MODE_OTG) {
> + spin_lock_irqsave(>lock, flags);
> + dwc->dr_keep_role = true;
> + spin_unlock_irqrestore(>lock, flags);
> + }
> +
> + return 0;
> +}
> +
> +static void dwc3_complete(struct device *dev)
> +{
> + struct dwc3 *dwc = dev_get_drvdata(dev);
> + unsigned long   flags;
> +
> + if (dwc->dr_mode == USB_DR_MODE_OTG) {
> + spin_lock_irqsave(>lock, flags);
> + dwc->dr_keep_role = false;
> + spin_unlock_irqrestore(>lock, flags);
> + dwc3_drd_update(dwc);
> + }
> +}
> +
>  static int dwc3_suspend(struct device *dev)
>  {
>   struct dwc3 *dwc = dev_get_drvdata(dev);
> @@ -1451,6 +1478,10 @@ static const struct dev_pm_ops dwc3_dev_pm_ops = {
>   SET_SYSTEM_SLEEP_PM_OPS(dwc3_suspend, dwc3_resume)
>   SET_RUNTIME_PM_OPS(dwc3_runtime_suspend, dwc3_runtime_resume,
>   dwc3_runtime_idle)
> +#ifdef CONFIG_PM_SLEEP
> + .prepare = dwc3_prepare,
> + .complete = dwc3_complete,
> +#endif
>  };
>  
>  #ifdef CONFIG_OF
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 4a4a4c9..f5eb474 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -786,6 +786,7 @@ struct dwc3_scratchpad_array {
>   * @dr_mode: requested mode of operation
>   * @current_dr_role: current role of operation when in dual-role mode
>   * @desired_dr_role: desired role of operation when in dual-role mode
> + * @dr_keep_role: keep the current dual-role irrespective of ID changes
>   * @edev: extcon handle
>   * @edev_nb: extcon notifier
>   * @hsphy_mode: UTMI phy mode, one of following:
> @@ -901,6 +902,7 @@ struct dwc3 {
>   enum usb_dr_modedr_mode;
>   u32 current_dr_role;
>   u32 desired_dr_role;
> + booldr_keep_role;
>   struct extcon_dev   *edev;
>   struct notifier_block   edev_nb;
>   enum usb_phy_interface  hsphy_mode;
> @@ -1227,11 +1229,14 @@ static inline int 
> dwc3_send_gadget_generic_command(struct dwc3 *dwc,
>  #if IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
>  int dwc3_drd_init(struct dwc3 *dwc);
>  void dwc3_drd_exit(struct dwc3 *dwc);
> +void dwc3_drd_update(struct dwc3 *dwc);
>  #else
>  static inline int dwc3_drd_init(struct dwc3 *dwc)
>  { return 0; }
>  static inline void dwc3_drd_exit(struct dwc3 *dwc)
>  { }
> +static inline void dwc3_drd_update(struct dwc3 *dwc);
> +{ }
>  #endif
>  
>  /* power management interface */
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index cc8ab9a..177a8be 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -13,7 +13,7 @@
>  #include "core.h"
>  #include "gadget.h"
>  
> -static void dwc3_drd_update(struct dwc3 *dwc)
> +void dwc3_drd_update(struct dwc3 *dwc)
>  {
>   int id;
>  
> @@ -31,9 +31,11 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
>  {
>   struct dwc3 *dwc = container_of(nb, struct dwc3, edev_nb);
>  
> - dwc3_set_mode(dwc, event ?
> -   DWC3_GCTL_PRTCAP_HOST :
> -   DWC3_GCTL_PRTCAP_DEVICE);
> + if (!dwc->dr_keep_role) {
> + dwc3_set_mode(dwc, event ?
> +   DWC3_GCTL_PRTCAP_HOST :
> +   DWC3_GCTL_PRTCAP_DEVICE);
> + }
>  
>   return NOTIFY_DONE;
>  }

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

[jianchao.wang]

Hi Jason

Thanks for your kindly response.

On 01/22/2018 11:47 PM, Jason Gunthorpe wrote:
>>> Yeah, mlx4 NICs in Google fleet receive trillions of packets per
>>> second, and we never noticed an issue.
>>>
>>> Although we are using a slightly different driver, using order-0 pages
>>> and fast pages recycling.
>>>
>>>
>> The driver we use will will set the page reference count to (size of 
>> pages)/stride, the
>> pages will be freed by networking stack when the reference become zero, and 
>> the order-3
>> pages maybe allocated soon, this give NIC device a chance to corrupt the 
>> pages which have
>>  been allocated by others, such as slab.
> But it looks like the wmb() is placed when stuffing new rx descriptors
> into the device - how can it prevent corruption of pages where
> ownership was transfered from device to the host? That sounds more like a
> rmb() is missing someplace to me...
> 
The device may see the prod_db updating before rx_desc updating.
Then it will get stale rx_descs.
These stale rx_descs may contain pages that has been freed to host.
 

> (Granted the missing wmb() is a bug, but it may not be fully solving this
>  issue??)the wmb() here fix one of the customer's test case.

Thanks
Jianchao

Re: [PATCH] net/mlx4_en: ensure rx_desc updating reaches HW before prod db updating

[jianchao.wang]

Hi Jason

Thanks for your kindly response.

On 01/22/2018 11:47 PM, Jason Gunthorpe wrote:
>>> Yeah, mlx4 NICs in Google fleet receive trillions of packets per
>>> second, and we never noticed an issue.
>>>
>>> Although we are using a slightly different driver, using order-0 pages
>>> and fast pages recycling.
>>>
>>>
>> The driver we use will will set the page reference count to (size of 
>> pages)/stride, the
>> pages will be freed by networking stack when the reference become zero, and 
>> the order-3
>> pages maybe allocated soon, this give NIC device a chance to corrupt the 
>> pages which have
>>  been allocated by others, such as slab.
> But it looks like the wmb() is placed when stuffing new rx descriptors
> into the device - how can it prevent corruption of pages where
> ownership was transfered from device to the host? That sounds more like a
> rmb() is missing someplace to me...
> 
The device may see the prod_db updating before rx_desc updating.
Then it will get stale rx_descs.
These stale rx_descs may contain pages that has been freed to host.
 

> (Granted the missing wmb() is a bug, but it may not be fully solving this
>  issue??)the wmb() here fix one of the customer's test case.

Thanks
Jianchao

[PATCH net-next 1/4] net: core: Fix kernel-doc for carrier_* attributes

[Florian Fainelli]

Fix the documentation warning:

include/linux/netdevice.h:1939: warning: Excess struct member 'carrier_changes' 
description in 'net_device'

Reported-by: kbuild test robot 
Fixes: b2d3bcfa26a7 ("net: core: Expose number of link up/down transitions")
Signed-off-by: Florian Fainelli 
---
 include/linux/netdevice.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 837e9cb7e358..581495f4e487 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1469,8 +1469,6 @@ enum netdev_priv_flags {
  * @base_addr: Device I/O address
  * @irq:   Device IRQ number
  *
- * @carrier_changes:   Stats to monitor carrier on<->off transitions
- *
  * @state: Generic network queuing layer state, see netdev_state_t
  * @dev_list:  The global list of network devices
  * @napi_list: List entry used for polling NAPI devices
@@ -1506,6 +1504,8 @@ enum netdev_priv_flags {
  * do not use this in drivers
  * @rx_nohandler:  nohandler dropped packets by core network on
  * inactive devices, do not use this in drivers
+ * @carrier_up_count:  Number of times the carrier has been up
+ * @carrier_down_count:Number of times the carrier has been down
  *
  * @wireless_handlers: List of functions to handle Wireless Extensions,
  * instead of ioctl,
-- 
2.14.1

[PATCH net-next 1/4] net: core: Fix kernel-doc for carrier_* attributes

[Florian Fainelli]

Fix the documentation warning:

include/linux/netdevice.h:1939: warning: Excess struct member 'carrier_changes' 
description in 'net_device'

Reported-by: kbuild test robot 
Fixes: b2d3bcfa26a7 ("net: core: Expose number of link up/down transitions")
Signed-off-by: Florian Fainelli 
---
 include/linux/netdevice.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 837e9cb7e358..581495f4e487 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1469,8 +1469,6 @@ enum netdev_priv_flags {
  * @base_addr: Device I/O address
  * @irq:   Device IRQ number
  *
- * @carrier_changes:   Stats to monitor carrier on<->off transitions
- *
  * @state: Generic network queuing layer state, see netdev_state_t
  * @dev_list:  The global list of network devices
  * @napi_list: List entry used for polling NAPI devices
@@ -1506,6 +1504,8 @@ enum netdev_priv_flags {
  * do not use this in drivers
  * @rx_nohandler:  nohandler dropped packets by core network on
  * inactive devices, do not use this in drivers
+ * @carrier_up_count:  Number of times the carrier has been up
+ * @carrier_down_count:Number of times the carrier has been down
  *
  * @wireless_handlers: List of functions to handle Wireless Extensions,
  * instead of ioctl,
-- 
2.14.1

[PATCH net-next 2/4] net: phy: sfp: Fix kernel doc warning

[Florian Fainelli]

We forgot to update the kernel doc header above sfp_register_upstream()

Fixes: c19bb00070dd ("sfp: convert to fwnode")
Signed-off-by: Florian Fainelli 
---
 drivers/net/phy/sfp-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index bdc4bb3c8288..8961209ee949 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -441,7 +441,7 @@ EXPORT_SYMBOL_GPL(sfp_upstream_stop);
 
 /**
  * sfp_register_upstream() - Register the neighbouring device
- * @np: device node for the SFP bus
+ * @fwnode: firmware node for the SFP bus
  * @ndev: network device associated with the interface
  * @upstream: the upstream private data
  * @ops: the upstream's  sfp_upstream_ops
-- 
2.14.1

[PATCH net-next 2/4] net: phy: sfp: Fix kernel doc warning

[Florian Fainelli]

We forgot to update the kernel doc header above sfp_register_upstream()

Fixes: c19bb00070dd ("sfp: convert to fwnode")
Signed-off-by: Florian Fainelli 
---
 drivers/net/phy/sfp-bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index bdc4bb3c8288..8961209ee949 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -441,7 +441,7 @@ EXPORT_SYMBOL_GPL(sfp_upstream_stop);
 
 /**
  * sfp_register_upstream() - Register the neighbouring device
- * @np: device node for the SFP bus
+ * @fwnode: firmware node for the SFP bus
  * @ndev: network device associated with the interface
  * @upstream: the upstream private data
  * @ops: the upstream's  sfp_upstream_ops
-- 
2.14.1