Re: [PATCH 1/3] firmware/dmi_scan: Add dmi_save_release to save releases fields

[Jean Delvare]

Hi Erwan,

Sorry for the late answer.

On Wed, 18 Sep 2019 11:43:19 +0200, Erwan Velu wrote:
> In DMI type 0, there is several fields that encodes a release.

is -> are
encodes -> encode

> The dmi_save_release() function have the logic to check if the field is valid.
> If so, it reports the actual value.
> 
> Signed-off-by: Erwan Velu 
> ---
>  drivers/firmware/dmi_scan.c | 26 ++
>  1 file changed, 26 insertions(+)

This patch introduces a warning:

drivers/firmware/dmi_scan.c:185:20: warning: ‘dmi_save_release’ defined but not 
used [-Wunused-function]
 static void __init dmi_save_release(const struct dmi_header *dm, int slot,
^~~~

because you add a static function with no user. I understand that you
add a use later in the series, but it's not OK to introduce a warning
even if temporary. It also makes little sense to split the changes that
way as there is no way to cherry-pick one of the patches without the
rest. And it makes things more difficult to review too, as I can't
possibly judge if this function if right without also seeing where is
will be called and how.

So, please merge all the changes into a single patch.

> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index 35ed56b9c34f..202bd2c69d0f 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -181,6 +181,32 @@ static void __init dmi_save_ident(const struct 
> dmi_header *dm, int slot,
>   dmi_ident[slot] = p;
>  }
>  
> +static void __init dmi_save_release(const struct dmi_header *dm, int slot,
> + int index)
> +{
> + const u8 *d;
> + char *s;
> +
> + // If the table doesn't have the field, let's return

Please stick to C89-style comments (/* */) as used everywhere else in
this file.

> + if (dmi_ident[slot] || dm->length < index)
> + return;
> +
> + d = (u8 *) dm + index;
> +
> + // As per the specification,
> + // if the system doesn't have the field, the value is FF
> + if (d[0] == 0xFF)
> + return;

That's not exactly what the specification says. It says:

"If the system does not support the use of [the System BIOS Major
Release] field, the value is 0FFh for both this field and the System
BIOS Minor Release field." So unused is when both fields are 0xFF. You
can't test them independently.

Same goes for the Embedded Controller Firmware Release fields, even if
it is worded differently, the logic is the same.

> +
> + s = dmi_alloc(4);
> + if (!s)
> + return;
> +
> + sprintf(s, "%u", d[0]);
> +
> + dmi_ident[slot] = s;
> +}
> +
>  static void __init dmi_save_uuid(const struct dmi_header *dm, int slot,
>   int index)
>  {


-- 
Jean Delvare
SUSE L3 Support

Re: [PATCH v3] clk/ti/adpll: allocate room for terminating null

[Tony Lindgren]

* Stephen Kitt  [191019 14:07]:
> The buffer allocated in ti_adpll_clk_get_name doesn't account for the
> terminating null. This patch switches to devm_kasprintf to avoid
> overflowing.
> 
> Signed-off-by: Stephen Kitt 
> ---
> Changes since v2:
>   - Move "adpll" into the format string and drop base_name entirely.
> 
> Changes since v1:
>   - Use devm_kasprintf instead of manually allocating the target
> buffer.

Acked-by: Tony Lindgren 

> ---
>  drivers/clk/ti/adpll.c | 11 ++-
>  1 file changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/clk/ti/adpll.c b/drivers/clk/ti/adpll.c
> index fdfb90058504..bb2f2836dab2 100644
> --- a/drivers/clk/ti/adpll.c
> +++ b/drivers/clk/ti/adpll.c
> @@ -194,15 +194,8 @@ static const char *ti_adpll_clk_get_name(struct 
> ti_adpll_data *d,
>   if (err)
>   return NULL;
>   } else {
> - const char *base_name = "adpll";
> - char *buf;
> -
> - buf = devm_kzalloc(d->dev, 8 + 1 + strlen(base_name) + 1 +
> - strlen(postfix), GFP_KERNEL);
> - if (!buf)
> - return NULL;
> - sprintf(buf, "%08lx.%s.%s", d->pa, base_name, postfix);
> - name = buf;
> + name = devm_kasprintf(d->dev, GFP_KERNEL, "%08lx.adpll.%s",
> +   d->pa, postfix);
>   }
>  
>   return name;
> -- 
> 2.20.1
> 

[PATCH 5/5] arm64: dts: meson-gx: fix i2c compatible

[Neil Armstrong]

This fixes the following DT schemas check errors:
meson-gxbb-nanopi-k2.dt.yaml: i2c@8500: compatible: Additional items are not 
allowed ('amlogic,meson-gxbb-i2c' was unexpected)
meson-gxbb-nanopi-k2.dt.yaml: i2c@8500: compatible:0: 'amlogic,meson-gx-i2c' is 
not one of ['amlogic,meson6-i2c', 'amlogic,meson-gxbb-i2c', 
'amlogic,meson-axg-i2c']
meson-gxbb-nanopi-k2.dt.yaml: i2c@8500: compatible: ['amlogic,meson-gx-i2c', 
'amlogic,meson-gxbb-i2c'] is too long

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 042132bf5b76..10d5c97cba4f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -240,7 +240,7 @@
};
 
i2c_A: i2c@8500 {
-   compatible = "amlogic,meson-gx-i2c", 
"amlogic,meson-gxbb-i2c";
+   compatible = "amlogic,meson-gxbb-i2c";
reg = <0x0 0x08500 0x0 0x20>;
interrupts = ;
#address-cells = <1>;
@@ -290,7 +290,7 @@
};
 
i2c_B: i2c@87c0 {
-   compatible = "amlogic,meson-gx-i2c", 
"amlogic,meson-gxbb-i2c";
+   compatible = "amlogic,meson-gxbb-i2c";
reg = <0x0 0x087c0 0x0 0x20>;
interrupts = ;
#address-cells = <1>;
@@ -299,7 +299,7 @@
};
 
i2c_C: i2c@87e0 {
-   compatible = "amlogic,meson-gx-i2c", 
"amlogic,meson-gxbb-i2c";
+   compatible = "amlogic,meson-gxbb-i2c";
reg = <0x0 0x087e0 0x0 0x20>;
interrupts = ;
#address-cells = <1>;
@@ -415,7 +415,7 @@
};
 
i2c_AO: i2c@500 {
-   compatible = "amlogic,meson-gx-i2c", 
"amlogic,meson-gxbb-i2c";
+   compatible = "amlogic,meson-gxbb-i2c";
reg = <0x0 0x500 0x0 0x20>;
interrupts = ;
#address-cells = <1>;
-- 
2.22.0

Re: [PATCH v2 07/11] omap: remove old hsmmc.[ch] and in Makefile

[Tony Lindgren]

* H. Nikolaus Schaller  [191019 18:43]:
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -216,7 +216,6 @@ obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o
>  
>  # Platform specific device init code
>  
> -omap-hsmmc-$(CONFIG_MMC_OMAP_HS) := hsmmc.o
>  obj-y+= $(omap-hsmmc-m) 
> $(omap-hsmmc-y)

The related obj-y line can go now too, right?

And looks like common.h also has struct omap2_hsmmc_info
so maybe check by grepping for hsmmc_info to see it's gone.

Regards,

Tony

[PATCH 3/5] arm64: dts: meson-g12b-odroid-n2: add missing amlogic,s922x compatible

[Neil Armstrong]

This fixes the following DT schemas check errors:
meson-g12b-odroid-n2.dt.yaml: /: compatible: ['hardkernel,odroid-n2', 
'amlogic,g12b'] is not valid under any of the given schemas

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts 
b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
index 42f15405750c..0e54c1dc2842 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts
@@ -12,7 +12,7 @@
 #include 
 
 / {
-   compatible = "hardkernel,odroid-n2", "amlogic,g12b";
+   compatible = "hardkernel,odroid-n2", "amlogic,s922x", "amlogic,g12b";
model = "Hardkernel ODROID-N2";
 
aliases {
-- 
2.22.0

[PATCH 4/5] arm64: dts: meson-gx: cec node should be disabled by default

[Neil Armstrong]

This fixes the following DT schemas check errors:
meson-gxl-s905x-hwacom-amazetv.dt.yaml: cec@100: 'hdmi-phandle' is a required 
property
meson-gxm-rbox-pro.dt.yaml: cec@100: 'hdmi-phandle' is a required property

because CEC is not enabled on these boards.

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 6733050d735f..042132bf5b76 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -391,6 +391,7 @@
compatible = "amlogic,meson-gx-ao-cec";
reg = <0x0 0x00100 0x0 0x14>;
interrupts = ;
+   status = "disabled";
};
 
sec_AO: ao-secure@140 {
-- 
2.22.0

[PATCH 0/5] arm64: dts: meson: new fixes following YAML bindings schemas conversion

[Neil Armstrong]

This is the first set of DT fixes following the first YAML bindings conversion
at [1], [2], [3] and [4] and v5.4-rc1 bindings changes.

These are only cosmetic changes, and should not break drivers implementation
following the bindings.

[1] https://patchwork.kernel.org/patch/11202077/
[2] https://patchwork.kernel.org/patch/11202183/
[3] https://patchwork.kernel.org/patch/11202207/
[4] https://patchwork.kernel.org/patch/11202265/

Neil Armstrong (5):
  arm64: dts: meson-g12a: fix gpu irq order
  arm64: dts: meson-gxm: fix gpu irq order
  arm64: dts: meson-g12b-odroid-n2: add missing amlogic,s922x compatible
  arm64: dts: meson-gx: cec node should be disabled by default
  arm64: dts: meson-gx: fix i2c compatible

 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi| 6 +++---
 arch/arm64/boot/dts/amlogic/meson-g12b-odroid-n2.dts | 2 +-
 arch/arm64/boot/dts/amlogic/meson-gx.dtsi| 9 +
 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi   | 6 +++---
 4 files changed, 12 insertions(+), 11 deletions(-)

-- 
2.22.0

[PATCH 2/5] arm64: dts: meson-gxm: fix gpu irq order

[Neil Armstrong]

This fixes the following DT schemas check errors:
meson-gxm-khadas-vim2.dt.yaml: gpu@c: interrupt-names:0: 'job' was expected
meson-gxm-khadas-vim2.dt.yaml: gpu@c: interrupt-names:2: 'gpu' was expected

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
index a0e677d5a8f7..5ff64a0d2dcf 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxm.dtsi
@@ -96,10 +96,10 @@
compatible = "amlogic,meson-gxm-mali", "arm,mali-t820";
reg = <0x0 0xc 0x0 0x4>;
interrupt-parent = <>;
-   interrupts = ,
+   interrupts = ,
 ,
-;
-   interrupt-names = "gpu", "mmu", "job";
+;
+   interrupt-names = "job", "mmu", "gpu";
clocks = < CLKID_MALI>;
resets = < RESET_MALI_CAPB3>, < RESET_MALI>;
 
-- 
2.22.0

[PATCH 1/5] arm64: dts: meson-g12a: fix gpu irq order

[Neil Armstrong]

This fixes the following DT schemas check errors:
meson-g12b-s922x-khadas-vim3.dt.yaml: gpu@ffe4: interrupt-names:0: 'job' 
was expected
meson-g12b-s922x-khadas-vim3.dt.yaml: gpu@ffe4: interrupt-names:2: 'gpu' 
was expected

Signed-off-by: Neil Armstrong 
---
 arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi 
b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 3f39e020f74e..f9c52ada7fda 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -2388,10 +2388,10 @@
compatible = "amlogic,meson-g12a-mali", 
"arm,mali-bifrost";
reg = <0x0 0xffe4 0x0 0x4>;
interrupt-parent = <>;
-   interrupts = ,
+   interrupts = ,
 ,
-;
-   interrupt-names = "gpu", "mmu", "job";
+;
+   interrupt-names = "job", "mmu", "gpu";
clocks = < CLKID_MALI>;
resets = < RESET_DVALIN_CAPB3>, < 
RESET_DVALIN>;
 
-- 
2.22.0

RE: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant PHYs

[Pankaj Dubey]

> -Original Message-
> From: Andrew Murray 
> Sent: Monday, October 21, 2019 7:47 PM
> To: Pankaj Dubey 
> Cc: 'Anvesh Salveru' ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com;
> gustavo.pimen...@synopsys.com; jingooh...@gmail.com;
> lorenzo.pieral...@arm.com
> Subject: Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant
> PHYs
> 
> On Mon, Oct 21, 2019 at 07:44:25PM +0530, Pankaj Dubey wrote:
> >
> >
> > > -Original Message-
> > > From: Andrew Murray 
> > > Sent: Monday, October 21, 2019 7:34 PM
> > > To: Anvesh Salveru 
> > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > > bhelg...@google.com; gustavo.pimen...@synopsys.com;
> > > jingooh...@gmail.com; lorenzo.pieral...@arm.com; Pankaj Dubey
> > > 
> > > Subject: Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC
> > > Compliant PHYs
> > >
> > > On Mon, Oct 21, 2019 at 05:59:53PM +0530, Anvesh Salveru wrote:
> > > > Many platforms use DesignWare controller but the PHY can be
> > > > different in different platforms. If the PHY is compliant is to
> > > > ZRX-DC specification
> > >
> > > s/is to/to the/
> >
> > OK
> >
> > >
> > > > it helps in low power consumption during power states.
> > >
> > > s/in low/lower/
> > >
> > OK
> > > >
> > > > If current data rate is 8.0 GT/s or higher and PHY is not
> > > > compliant to ZRX-DC specification, then after every 100ms link
> > > > should transition to recovery state during the low power states.
> > > >
> > > > DesignWare controller provides GEN3_ZRXDC_NONCOMPL field in
> > > > GEN3_RELATED_OFF to specify about ZRX-DC compliant PHY.
> > > >
> > > > Platforms with ZRX-DC compliant PHY can set
"snps,phy-zrxdc-compliant"
> > > > property in controller DT node to specify this property to the
> > controller.
> > > >
> > > > Signed-off-by: Anvesh Salveru 
> > > > Signed-off-by: Pankaj Dubey 
> > > > ---
> > > >  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
> > > > drivers/pci/controller/dwc/pcie-designware.h | 3 +++
> > > >  2 files changed, 10 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > > index 820488dfeaed..6560d9f765d7 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > > @@ -556,4 +556,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
> > > >PCIE_PL_CHK_REG_CHK_REG_START;
> > > > dw_pcie_writel_dbi(pci,
PCIE_PL_CHK_REG_CONTROL_STATUS,
> > > val);
> > > > }
> > > > +
> > > > +   if (of_property_read_bool(np, "snps,phy-zrxdc-compliant")) {
> > > > +   val = dw_pcie_readl_dbi(pci,
PCIE_PORT_GEN3_RELATED);
> > > > +   val &= ~PORT_LOGIC_GEN3_ZRXDC_NONCOMPL;
> > > > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED,
val);
> > > > +   }
> > > > +
> > >
> > > Given that this duplicates tegra_pcie_prepare_host in
> > > pcie-tegra194.c, can
> > we
> > > update that driver to adopt this new binding?
> > >
> >
> > Yes, Thanks for highlighting this. Otherwise I was worried that we
> > have one more patch without real user :)
> 
> Indeed :|
> 
> Though besides Tegra, is there any other reason you are adding this?
> 

Yes. We have one internal PCIe RC driver (which we can't disclose/upstream
right now) has this issue and currently we are handling it using this DT
binding. So we would like to upstream common code, so other platform's
driver can use this.

> > We will update pcie-tegra194.c driver and post the patch to adopt this
> > binding.
> 
> It's much appreciated.
> 
> Andrew Murray
> 
> >
> > > Thanks,
> > >
> > > Andrew Murray
> > >
> > > >  }
> > > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > > index 5a18e94e52c8..427a55ec43c6 100644
> > > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > > @@ -60,6 +60,9 @@
> > > >  #define PCIE_MSI_INTR0_MASK0x82C
> > > >  #define PCIE_MSI_INTR0_STATUS  0x830
> > > >
> > > > +#define PCIE_PORT_GEN3_RELATED 0x890
> > > > +#define PORT_LOGIC_GEN3_ZRXDC_NONCOMPL BIT(0)
> > > > +
> > > >  #define PCIE_ATU_VIEWPORT  0x900
> > > >  #define PCIE_ATU_REGION_INBOUNDBIT(31)
> > > >  #define PCIE_ATU_REGION_OUTBOUND   0
> > > > --
> > > > 2.17.1
> > > >
> >

Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y

[Neil Armstrong]

Hi Anand,

On 21/10/2019 16:11, Anand Moon wrote:
> Hi Martin,
> 
> On Fri, 18 Oct 2019 at 23:40, Martin Blumenstingl
>  wrote:
>>
>> Hi Anand,
>>
>> On Fri, Oct 18, 2019 at 4:04 PM Anand Moon  wrote:
>> [...]
 Next step it to try narrow down the clock causing the issue.
 Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED
 to the flag of some clocks your clock controller (g12a I think) until

 The peripheral clock gates already have this flag (something we should
 fix someday) so don't bother looking there.

 Most likely the source of the pwm is getting disabled between the
 late_init call and the probe of the PWM module. Since the pwm is already
 active (w/o a driver), gating the clock source shuts dowm the power to
 the cores.

 Looking a the possible inputs in pwm driver, I'd bet on fdiv4.

>>>
>>> I had give this above steps a try but with little success.
>>> I am still looking into this much close.
>> it's not clear to me if you have only tested with the PWM and/or
>> FCLK_DIV4 clocks. can you please describe what you have tested so far?
>>
> Sorry for delayed response.
> 
> I had just looked into clk related to SD_EMMC_A/B/C,
> with adding CLK_IGNORE/CRITICAL.
> Also looked into clk_summary for eMMC and microSD card,
> to identify the root cause, but I failed to move ahead.
> 
>> for reference - my way of debugging this in the past was:
>> 1. add some printks to clk_disable_unused_subtree (right after the
>> clk_core_is_enabled check) to see which clocks are being disabled
>> 2. add CLK_IGNORE_UNUSED or CLK_IS_CRITICAL to the clocks which are
>> being disabled based on the information from step #1
>> 3. (at some point I had a working kernel with lots of clocks with
>> CLK_IGNORE_UNUSED/CLK_IS_CRITICAL)
>> 4. start dropping the CLK_IGNORE_UNUSED/CLK_IS_CRITICAL flags again
>> until you have traced it down to the clocks that are the actual issue
>> (so far I always had only one clock which caused issues, but it may be
>> multiple)
>> 5. investigate (and/or ask on the mailing list, Amlogic developers are
>> reading the mails here as well) for the few clocks from step #4
>>
> 
> Thanks for you valuable suggestion. I have your patch to debug this
> [0]  https://patchwork.kernel.org/patch/9725921/mbox/
> 
> So from the fist step I could identify that all the clk were getting closed
> after some core cpu clk was failing. Here is the log.
> 
> step1: [1] https://pastebin.com/p13F9HGG
> 
> so I marked these clk as CLK_IGNORE_UNUSED and finally
> I made it to boot using microSD card.
> 
> After this just I converted these CLK to CLK_IS_CRITICAL
> as mostly these are used the CPU clk for now.
> Here is boot log successful for as of now.
> 
> Finally: [2]  https://pastebin.com/qB6pMyGQ
> 
> I know clk maintainer are against marking flags as *CLK_IS_CRITICAL*
> But this is just the step to move ahead.

Thanks for the extensive debug.

> 
> Attach is my local clk and dts patch.Just for testing.
> [3] clk_critical.patch


Could you test with only the following changes:
diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index ea4c791f106d..f49f5463363e 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -298,6 +298,7 @@ static struct clk_regmap g12a_fclk_div2 = {
_fclk_div2_div.hw
},
.num_parents = 1,
+   .flags = CLK_IS_CRITICAL,
},
 };

@@ -672,7 +673,7 @@ static struct clk_regmap g12b_cpub_clk = {
_sys_pll.hw
},
.num_parents = 2,
-   .flags = CLK_SET_RATE_PARENT,
+   .flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL,
},
 };

> 
> Plz share your thought on this.
> 
>>> Well I am not the expert in clk or bus configuration.
>>> but after looking into the datasheet of for clk configuration
>>> I found some bus are not configured correctly.
>> did you find any reason which indicates that the problem is related to a bus?
>> the issues I had were due to clocks not being assigned to their
>> consumers in .dts - that can be anything (from a bus to something
>> different).
>>
> 
> Yes I feel each core bus should be independent
> as each clk PLL controls these bus.
> 
> for example datasheet: *6-5 Clock Connections*
> 
> What I feel currently missing with bus are
> clock gating (enable/disable of features).
> clock-controller
> reset-controller
> 
> Here is the current overview of bus topology
> using latest u-boot (dm tree).
> 
> [4] https://pastebin.com/MZ25bgiP
> 
> Bet Regards
> -Anand
> 

[PATCH] usbip: Fix free of unallocated memory in vhci tx

[Suwan Kim]

iso_buffer should be set to NULL after use and free in the while loop.
In the case of isochronous URB in the while loop, iso_buffer is
allocated and after sending it to server, buffer is deallocated. And
then, if the next URB in the while loop is not a isochronous pipe,
iso_buffer still holds the previously deallocated buffer address and
kfree tries to free wrong buffer address.

Fixes: ea44d190764b (“usbip: Implement SG support to vhci-hcd and stub driver”)
Reported-by: kbuild test robot 
Reported-by: Julia Lawall 
Signed-off-by: Suwan Kim 
---
 drivers/usb/usbip/vhci_tx.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/usbip/vhci_tx.c b/drivers/usb/usbip/vhci_tx.c
index c3803785f6ef..b290e810d11b 100644
--- a/drivers/usb/usbip/vhci_tx.c
+++ b/drivers/usb/usbip/vhci_tx.c
@@ -73,6 +73,7 @@ static int vhci_send_cmd_submit(struct vhci_device *vdev)
memset(_header, 0, sizeof(pdu_header));
memset(, 0, sizeof(msg));
memset(, 0, sizeof(iov));
+   iso_buffer = NULL;
 
usbip_dbg_vhci_tx("setup txdata urb seqnum %lu\n",
  priv->seqnum);
-- 
2.21.0

Re: [PATCH 1/3] mm, meminit: Recalculate pcpu batch and high limits after init completes

[Mel Gorman]

On Mon, Oct 21, 2019 at 10:01:24AM -0400, Qian Cai wrote:
> Warnings from linux-next,
> 
> [   14.265911][  T659] BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:935
> [   14.265992][  T659] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 
> 659, name: pgdatinit8
> [   14.266044][  T659] 1 lock held by pgdatinit8/659:

Fixed in v2 posted this morning. It should hit linux-next eventually.

-- 
Mel Gorman
SUSE Labs

[PATCH] powerpc/security: Fix debugfs data leak on 32-bit

[Geert Uytterhoeven]

"powerpc_security_features" is "unsigned long", i.e. 32-bit or 64-bit,
depending on the platform (PPC_FSL_BOOK3E or PPC_BOOK3S_64).  Hence
casting its address to "u64 *", and calling debugfs_create_x64() is
wrong, and leaks 32-bit of nearby data to userspace on 32-bit platforms.

While all currently defined SEC_FTR_* security feature flags fit in
32-bit, they all have "ULL" suffixes to make them 64-bit constants.
Hence fix the leak by changing the type of "powerpc_security_features"
(and the parameter types of its accessors) to "u64".  This also allows
to drop the cast.

Fixes: 398af571128fe75f ("powerpc/security: Show powerpc_security_features in 
debugfs")
Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.

Alternatively, powerpc_security_features could be changed to u32.
However, that would require using debugfs_create_x32() instead of
debugfs_create_x64(), which would change the debugfs file formatting
from "0x%016llx" to "0x%08llx".
---
 arch/powerpc/include/asm/security_features.h | 8 
 arch/powerpc/kernel/security.c   | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/include/asm/security_features.h 
b/arch/powerpc/include/asm/security_features.h
index 759597bf0fd867bd..a3e8ecd48dc7ffa0 100644
--- a/arch/powerpc/include/asm/security_features.h
+++ b/arch/powerpc/include/asm/security_features.h
@@ -9,7 +9,7 @@
 #define _ASM_POWERPC_SECURITY_FEATURES_H
 
 
-extern unsigned long powerpc_security_features;
+extern u64 powerpc_security_features;
 extern bool rfi_flush;
 
 /* These are bit flags */
@@ -24,17 +24,17 @@ void setup_stf_barrier(void);
 void do_stf_barrier_fixups(enum stf_barrier_type types);
 void setup_count_cache_flush(void);
 
-static inline void security_ftr_set(unsigned long feature)
+static inline void security_ftr_set(u64 feature)
 {
powerpc_security_features |= feature;
 }
 
-static inline void security_ftr_clear(unsigned long feature)
+static inline void security_ftr_clear(u64 feature)
 {
powerpc_security_features &= ~feature;
 }
 
-static inline bool security_ftr_enabled(unsigned long feature)
+static inline bool security_ftr_enabled(u64 feature)
 {
return !!(powerpc_security_features & feature);
 }
diff --git a/arch/powerpc/kernel/security.c b/arch/powerpc/kernel/security.c
index 7cfcb294b11ca7be..2e9a7e20d05c5f79 100644
--- a/arch/powerpc/kernel/security.c
+++ b/arch/powerpc/kernel/security.c
@@ -16,7 +16,7 @@
 #include 
 
 
-unsigned long powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
+u64 powerpc_security_features __read_mostly = SEC_FTR_DEFAULT;
 
 enum count_cache_flush_type {
COUNT_CACHE_FLUSH_NONE  = 0x1,
@@ -108,7 +108,7 @@ device_initcall(barrier_nospec_debugfs_init);
 static __init int security_feature_debugfs_init(void)
 {
debugfs_create_x64("security_features", 0400, powerpc_debugfs_root,
-  (u64 *)_security_features);
+  _security_features);
return 0;
 }
 device_initcall(security_feature_debugfs_init);
-- 
2.17.1

Re: [PATCH 0/3] Allow ZRAM to use any zpool-compatible backend

[Vitaly Wool]

On Tue, Oct 15, 2019 at 10:00 PM Minchan Kim  wrote:
>
> On Tue, Oct 15, 2019 at 09:39:35AM +0200, Vitaly Wool wrote:
> > Hi Minchan,
> >
> > On Mon, Oct 14, 2019 at 6:41 PM Minchan Kim  wrote:
> > >
> > > On Thu, Oct 10, 2019 at 11:04:14PM +0300, Vitaly Wool wrote:
> > > > The coming patchset is a new take on the old issue: ZRAM can currently 
> > > > be used only with zsmalloc even though this may not be the optimal 
> > > > combination for some configurations. The previous (unsuccessful) 
> > > > attempt dates back to 2015 [1] and is notable for the heated 
> > > > discussions it has caused.
> > > >
> > > > The patchset in [1] had basically the only goal of enabling ZRAM/zbud 
> > > > combo which had a very narrow use case. Things have changed 
> > > > substantially since then, and now, with z3fold used widely as a zswap 
> > > > backend, I, as the z3fold maintainer, am getting requests to 
> > > > re-interate on making it possible to use ZRAM with any zpool-compatible 
> > > > backend, first of all z3fold.
> > > >
> > > > The preliminary results for this work have been delivered at Linux 
> > > > Plumbers this year [2]. The talk at LPC, though having attracted 
> > > > limited interest, ended in a consensus to continue the work and pursue 
> > > > the goal of decoupling ZRAM from zsmalloc.
> > > >
> > > > The current patchset has been stress tested on arm64 and x86_64 
> > > > devices, including the Dell laptop I'm writing this message on now, not 
> > > > to mention several QEmu confugirations.
> > > >
> > > > [1] https://lkml.org/lkml/2015/9/14/356
> > > > [2] https://linuxplumbersconf.org/event/4/contributions/551/
> > >
> > > Please describe what's the usecase in real world, what's the benefit 
> > > zsmalloc
> > > cannot fulfill by desgin and how it's significant.
> >
> > I'm not entirely sure how to interpret the phrase "the benefit
> > zsmalloc cannot fulfill by design" but let me explain.
> > First, there are multi multi core systems where z3fold can provide
> > better throughput.
>
> Please include number in the description with workload.

Sure. So on an HMP 8-core ARM64 system with ZRAM, we run the following command:
fio --bs=4k --randrepeat=1 --randseed=100 --refill_buffers \
--buffer_compress_percentage=50 --scramble_buffers=1 \
--direct=1 --loops=15 --numjobs=4 --filename=/dev/block/zram0 \
 --name=seq-write --rw=write --stonewall --name=seq-read \
 --rw=read --stonewall --name=seq-readwrite --rw=rw --stonewall \
 --name=rand-readwrite --rw=randrw --stonewall

The results are the following:

zsmalloc:
Run status group 0 (all jobs):
  WRITE: io=61440MB, aggrb=1680.4MB/s, minb=430167KB/s,
maxb=440590KB/s, mint=35699msec, maxt=36564msec

Run status group 1 (all jobs):
   READ: io=61440MB, aggrb=1620.4MB/s, minb=414817KB/s,
maxb=414850KB/s, mint=37914msec, maxt=37917msec

Run status group 2 (all jobs):
  READ: io=30615MB, aggrb=897979KB/s, minb=224494KB/s,
maxb=228161KB/s, mint=34351msec, maxt=34912msec
  WRITE: io=30825MB, aggrb=904110KB/s, minb=226027KB/s,
maxb=229718KB/s, mint=34351msec, maxt=34912msec

Run status group 3 (all jobs):
   READ: io=30615MB, aggrb=772002KB/s, minb=193000KB/s,
maxb=193010KB/s, mint=40607msec, maxt=40609msec
  WRITE: io=30825MB, aggrb=777273KB/s, minb=194318KB/s,
maxb=194327KB/s, mint=40607msec, maxt=40609msec

z3fold:
Run status group 0 (all jobs):
  WRITE: io=61440MB, aggrb=1224.8MB/s, minb=313525KB/s,
maxb=329941KB/s, mint=47671msec, maxt=50167msec

Run status group 1 (all jobs):
   READ: io=61440MB, aggrb=3119.3MB/s, minb=798529KB/s,
maxb=862883KB/s, mint=18228msec, maxt=19697msec

Run status group 2 (all jobs):
   READ: io=30615MB, aggrb=937283KB/s, minb=234320KB/s,
maxb=234334KB/s, mint=33446msec, maxt=33448msec
  WRITE: io=30825MB, aggrb=943682KB/s, minb=235920KB/s,
maxb=235934KB/s, mint=33446msec, maxt=33448msec

Run status group 3 (all jobs):
   READ: io=30615MB, aggrb=829591KB/s, minb=207397KB/s,
maxb=210285KB/s, mint=37271msec, maxt=37790msec
  WRITE: io=30825MB, aggrb=835255KB/s, minb=208813KB/s,
maxb=211721KB/s, mint=37271msec, maxt=37790msec

So, z3fold is faster everywhere (including being *two* times faster on
read) except for sequential write which is the least important use
case in real world.

> > Then, there are low end systems with hardware
> > compression/decompression support which don't need zsmalloc
> > sophistication and would rather use zbud with ZRAM because the
> > compression ratio is relatively low.
>
> I couldn't imagine how it's bad with zsmalloc. Could you be more
> specific?


> > Finally, there are MMU-less systems targeting IOT and still running
> > Linux and having a compressed RAM disk is something that would help
> > these systems operate in a better way (for the benefit of the overall
> > Linux ecosystem, if you care about that, of course; well, some people
> > do).
>
> Could you write down what's the problem to use zsmalloc for MMU-less
> system? Maybe, it would be important point rather other 

Re: [PATCH] security/keyring: avoid pagefaults in keyring_read_iterator

[David Howells]

Chris von Recklinghausen  wrote:

> The put_user call from keyring_read_iterator caused a page fault which
> attempts to lock mm->mmap_sem and type->lock_class (key->sem) in the reverse
> order that keyring_read_iterator did, thus causing the circular locking
> dependency.
> 
> Remedy this by using access_ok and __put_user instead of put_user so we'll
> return an error instead of faulting in the page.

I wonder if it's better to create a kernel buffer outside of the lock in
keyctl_read_key().  Hmmm...  The reason I didn't want to do that is that
keyrings have don't have limits on the size.  Maybe that's not actually a
problem, since 1MiB would be able to hold a list of a quarter of a million
keys.

David

[PATCH v2 2/2] USB: dummy-hcd: use usb_urb_dir_in instead of usb_pipein

[Andrey Konovalov]

Commit fea3409112a9 ("USB: add direction bit to urb->transfer_flags") has
added a usb_urb_dir_in() helper function that can be used to determine
the direction of the URB. With that patch USB_DIR_IN control requests with
wLength == 0 are considered out requests by real USB HCDs. This patch
changes dummy-hcd to use the usb_urb_dir_in() helper to match that
behavior.

Signed-off-by: Andrey Konovalov 
---
 drivers/usb/gadget/udc/dummy_hcd.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/gadget/udc/dummy_hcd.c 
b/drivers/usb/gadget/udc/dummy_hcd.c
index a8f1e5707c14..4c9d1e49d5ed 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -1321,7 +1321,7 @@ static int dummy_perform_transfer(struct urb *urb, struct 
dummy_request *req,
u32 this_sg;
bool next_sg;
 
-   to_host = usb_pipein(urb->pipe);
+   to_host = usb_urb_dir_in(urb);
rbuf = req->req.buf + req->req.actual;
 
if (!urb->num_sgs) {
@@ -1409,7 +1409,7 @@ static int transfer(struct dummy_hcd *dum_hcd, struct urb 
*urb,
 
/* FIXME update emulated data toggle too */
 
-   to_host = usb_pipein(urb->pipe);
+   to_host = usb_urb_dir_in(urb);
if (unlikely(len == 0))
is_short = 1;
else {
@@ -1830,7 +1830,7 @@ static void dummy_timer(struct timer_list *t)
 
/* find the gadget's ep for this request (if configured) */
address = usb_pipeendpoint (urb->pipe);
-   if (usb_pipein(urb->pipe))
+   if (usb_urb_dir_in(urb))
address |= USB_DIR_IN;
ep = find_endpoint(dum, address);
if (!ep) {
@@ -2385,7 +2385,7 @@ static inline ssize_t show_urb(char *buf, size_t size, 
struct urb *urb)
s = "?";
break;
 } s; }),
-   ep, ep ? (usb_pipein(urb->pipe) ? "in" : "out") : "",
+   ep, ep ? (usb_urb_dir_in(urb) ? "in" : "out") : "",
({ char *s; \
switch (usb_pipetype(urb->pipe)) { \
case PIPE_CONTROL: \
-- 
2.23.0.866.gb869b98d4c-goog

[PATCH v2 1/2] USB: dummy-hcd: increase max number of devices to 32

[Andrey Konovalov]

When fuzzing the USB subsystem with syzkaller, we currently use 8 testing
processes within one VM. To isolate testing processes from one another it
is desirable to assign a dedicated USB bus to each of those, which means
we need at least 8 Dummy UDC/HCD devices.

This patch increases the maximum number of Dummy UDC/HCD devices to 32
(more than 8 in case we need more of them in the future).

Signed-off-by: Andrey Konovalov 
---
 drivers/usb/gadget/udc/dummy_hcd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/dummy_hcd.c 
b/drivers/usb/gadget/udc/dummy_hcd.c
index 3d499d93c083..a8f1e5707c14 100644
--- a/drivers/usb/gadget/udc/dummy_hcd.c
+++ b/drivers/usb/gadget/udc/dummy_hcd.c
@@ -2725,7 +2725,7 @@ static struct platform_driver dummy_hcd_driver = {
 };
 
 /*-*/
-#define MAX_NUM_UDC2
+#define MAX_NUM_UDC32
 static struct platform_device *the_udc_pdev[MAX_NUM_UDC];
 static struct platform_device *the_hcd_pdev[MAX_NUM_UDC];
 
-- 
2.23.0.866.gb869b98d4c-goog

cgroup_enable_task_cg_lists && PF_EXITING (Was: KCSAN: data-race in exit_signals / prepare_signal)

[Oleg Nesterov]

could you explain the usage of siglock/PF_EXITING in
cgroup_enable_task_cg_lists() ?

PF_EXITING is protected by cgroup_threadgroup_rwsem, not by
sighand->siglock.

Oleg.

[PATCH v2 0/2] USB: dummy-hcd: some updates

[Andrey Konovalov]

Changes in v2:
- Added missing Signed-off-by.
- Added better explanation as to why we need more Dummy devices.

Andrey Konovalov (2):
  USB: dummy-hcd: increase max number of devices to 32
  USB: dummy-hcd: use usb_urb_dir_in instead of usb_pipein

 drivers/usb/gadget/udc/dummy_hcd.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

-- 
2.23.0.866.gb869b98d4c-goog

[PATCH -next] scsi: cxgb4i: remove set but not used variable 'ppmax'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/scsi/cxgbi/cxgb4i/cxgb4i.c:2076:15:
 warning: variable ppmax set but not used [-Wunused-but-set-variable]
drivers/target/iscsi/cxgbit/cxgbit_ddp.c:300:15:
 warning: variable ppmax set but not used [-Wunused-but-set-variable]

It is not used since commit a248384e6420 ("cxgb4/libcxgb/
cxgb4i/cxgbit: enable eDRAM page pods for iSCSI")

Signed-off-by: YueHaibing 
---
 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c   | 2 --
 drivers/target/iscsi/cxgbit/cxgbit_ddp.c | 3 ---
 2 files changed, 5 deletions(-)

diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c 
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index da50e87..bc1086a 100644
--- a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
+++ b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
@@ -2073,7 +2073,6 @@ static int cxgb4i_ddp_init(struct cxgbi_device *cdev)
struct cxgb4_lld_info *lldi = cxgbi_cdev_priv(cdev);
struct net_device *ndev = cdev->ports[0];
struct cxgbi_tag_format tformat;
-   unsigned int ppmax;
int i, err;
 
if (!lldi->vr->iscsi.size) {
@@ -2082,7 +2081,6 @@ static int cxgb4i_ddp_init(struct cxgbi_device *cdev)
}
 
cdev->flags |= CXGBI_FLAG_USE_PPOD_OFLDQ;
-   ppmax = lldi->vr->iscsi.size >> PPOD_SIZE_SHIFT;
 
memset(, 0, sizeof(struct cxgbi_tag_format));
for (i = 0; i < 4; i++)
diff --git a/drivers/target/iscsi/cxgbit/cxgbit_ddp.c 
b/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
index 54bb1eb..af35251 100644
--- a/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
+++ b/drivers/target/iscsi/cxgbit/cxgbit_ddp.c
@@ -297,7 +297,6 @@ int cxgbit_ddp_init(struct cxgbit_device *cdev)
struct cxgb4_lld_info *lldi = >lldi;
struct net_device *ndev = cdev->lldi.ports[0];
struct cxgbi_tag_format tformat;
-   unsigned int ppmax;
int ret, i;
 
if (!lldi->vr->iscsi.size) {
@@ -305,8 +304,6 @@ int cxgbit_ddp_init(struct cxgbit_device *cdev)
return -EACCES;
}
 
-   ppmax = lldi->vr->iscsi.size >> PPOD_SIZE_SHIFT;
-
memset(, 0, sizeof(struct cxgbi_tag_format));
for (i = 0; i < 4; i++)
tformat.pgsz_order[i] = (lldi->iscsi_pgsz_order >> (i << 3))
-- 
2.7.4

[PATCH v1 2/2] mm/page_isolation.c: Convert SKIP_HWPOISON to MEMORY_OFFLINE

[David Hildenbrand]

We have two types of users of page isolation:
1. Memory offlining: Offline memory so it can be unplugged. Memory won't
 be touched.
2. Memory allocation: Allocate memory (e.g., alloc_contig_range()) to
  become the owner of the memory and make use of it.

For example, in case we want to offline memory, we can ignore (skip over)
PageHWPoison() pages, as the memory won't get used. We can allow to
offline memory. In contrast, we don't want to allow to allocate such
memory.

Let's generalize the approach so we can special case other types of
pages we want to skip over in case we offline memory. While at it, also
pass the same flags to test_pages_isolated().

Cc: Michal Hocko 
Cc: Oscar Salvador 
Cc: Andrew Morton 
Cc: Anshuman Khandual 
Cc: David Hildenbrand 
Cc: Pingfan Liu 
Cc: Qian Cai 
Cc: Pavel Tatashin 
Cc: Dan Williams 
Cc: Vlastimil Babka 
Cc: Mel Gorman 
Cc: Mike Rapoport 
Cc: Alexander Duyck 
Suggested-by: Michal Hocko 
Signed-off-by: David Hildenbrand 
---
 include/linux/page-isolation.h |  4 ++--
 mm/memory_hotplug.c|  8 +---
 mm/page_alloc.c|  4 ++--
 mm/page_isolation.c| 12 ++--
 4 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 1099c2fee20f..6861df759fad 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -30,7 +30,7 @@ static inline bool is_migrate_isolate(int migratetype)
 }
 #endif
 
-#define SKIP_HWPOISON  0x1
+#define MEMORY_OFFLINE 0x1
 #define REPORT_FAILURE 0x2
 
 bool has_unmovable_pages(struct zone *zone, struct page *page, int count,
@@ -58,7 +58,7 @@ undo_isolate_page_range(unsigned long start_pfn, unsigned 
long end_pfn,
  * Test all pages in [start_pfn, end_pfn) are isolated or not.
  */
 int test_pages_isolated(unsigned long start_pfn, unsigned long end_pfn,
-   bool skip_hwpoisoned_pages);
+   int isol_flags);
 
 struct page *alloc_migrate_target(struct page *page, unsigned long private);
 
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 5e6b2a312362..aa8abbd0d2e9 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1149,7 +1149,8 @@ static bool is_pageblock_removable_nolock(unsigned long 
pfn)
if (!zone_spans_pfn(zone, pfn))
return false;
 
-   return !has_unmovable_pages(zone, page, 0, MIGRATE_MOVABLE, 
SKIP_HWPOISON);
+   return !has_unmovable_pages(zone, page, 0, MIGRATE_MOVABLE,
+   MEMORY_OFFLINE);
 }
 
 /* Checks if this range of memory is likely to be hot-removable. */
@@ -1366,7 +1367,8 @@ static int
 check_pages_isolated_cb(unsigned long start_pfn, unsigned long nr_pages,
void *data)
 {
-   return test_pages_isolated(start_pfn, start_pfn + nr_pages, true);
+   return test_pages_isolated(start_pfn, start_pfn + nr_pages,
+  MEMORY_OFFLINE);
 }
 
 static int __init cmdline_parse_movable_node(char *p)
@@ -1477,7 +1479,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
/* set above range as isolated */
ret = start_isolate_page_range(start_pfn, end_pfn,
   MIGRATE_MOVABLE,
-  SKIP_HWPOISON | REPORT_FAILURE);
+  MEMORY_OFFLINE | REPORT_FAILURE);
if (ret < 0) {
reason = "failure to isolate range";
goto failed_removal;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index bf6b21f02154..b44712c7fdd7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8270,7 +8270,7 @@ bool has_unmovable_pages(struct zone *zone, struct page 
*page, int count,
 * The HWPoisoned page may be not in buddy system, and
 * page_count() is not 0.
 */
-   if ((flags & SKIP_HWPOISON) && PageHWPoison(page))
+   if (flags & MEMORY_OFFLINE && PageHWPoison(page))
continue;
 
if (__PageMovable(page))
@@ -8486,7 +8486,7 @@ int alloc_contig_range(unsigned long start, unsigned long 
end,
}
 
/* Make sure the range is really isolated. */
-   if (test_pages_isolated(outer_start, end, false)) {
+   if (test_pages_isolated(outer_start, end, 0)) {
pr_info_ratelimited("%s: [%lx, %lx) PFNs busy\n",
__func__, outer_start, end);
ret = -EBUSY;
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 89c19c0feadb..82b80aeb8a71 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -168,7 +168,8 @@ __first_valid_page(unsigned long pfn, unsigned long 
nr_pages)
  * @migratetype:   Migrate type to set in error recovery.
  * @flags: The following flags are allowed (they can be combined in
  * a bit mask)
- * 

[PATCH -next] scsi: cxlflash: remove set but not used variable 'ioarcb'

[YueHaibing]

Fixes gcc '-Wunused-but-set-variable' warning:

drivers/scsi/cxlflash/main.c:47:22: warning:
 variable ioarcb set but not used [-Wunused-but-set-variable]

It is never used, so can be removed.

Signed-off-by: YueHaibing 
---
 drivers/scsi/cxlflash/main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/scsi/cxlflash/main.c b/drivers/scsi/cxlflash/main.c
index 2dbf35f..fbd2ae4 100644
--- a/drivers/scsi/cxlflash/main.c
+++ b/drivers/scsi/cxlflash/main.c
@@ -44,14 +44,12 @@ static void process_cmd_err(struct afu_cmd *cmd, struct 
scsi_cmnd *scp)
struct afu *afu = cmd->parent;
struct cxlflash_cfg *cfg = afu->parent;
struct device *dev = >dev->dev;
-   struct sisl_ioarcb *ioarcb;
struct sisl_ioasa *ioasa;
u32 resid;
 
if (unlikely(!cmd))
return;
 
-   ioarcb = &(cmd->rcb);
ioasa = &(cmd->sa);
 
if (ioasa->rc.flags & SISL_RC_FLAGS_UNDERRUN) {
-- 
2.7.4

[PATCH v1 0/2] mm: Memory offlining + page isolation cleanups

[David Hildenbrand]

Two cleanups that popped up while working on (and discussing) virtio-mem:
https://lkml.org/lkml/2019/9/19/463

Tested with DIMMs on x86.

David Hildenbrand (2):
  mm/page_alloc.c: Don't set pages PageReserved() when offlining
  mm/page_isolation.c: Convert SKIP_HWPOISON to MEMORY_OFFLINE

 include/linux/page-isolation.h |  4 ++--
 mm/memory_hotplug.c|  8 +---
 mm/page_alloc.c|  9 +++--
 mm/page_isolation.c| 12 ++--
 4 files changed, 16 insertions(+), 17 deletions(-)

-- 
2.21.0

Re: [PATCH] usb: dwc3: select CONFIG_REGMAP_MMIO

[Neil Armstrong]

On 21/10/2019 16:18, Arnd Bergmann wrote:
> After many randconfig builds, one configuration caused a link
> error with dwc3-meson-g12a lacking the regmap-mmio code:
> 
> drivers/usb/dwc3/dwc3-meson-g12a.o: In function `dwc3_meson_g12a_probe':
> dwc3-meson-g12a.c:(.text+0x9f): undefined reference to 
> `__devm_regmap_init_mmio_clk'
> 
> Add the select statement that we have for all other users
> of that dependency.
> 
> Fixes: c3376f72 ("usb: dwc3: Add Amlogic G12A DWC3 glue")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/usb/dwc3/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
> index 89abc6078703..556a876c7896 100644
> --- a/drivers/usb/dwc3/Kconfig
> +++ b/drivers/usb/dwc3/Kconfig
> @@ -102,6 +102,7 @@ config USB_DWC3_MESON_G12A
> depends on ARCH_MESON || COMPILE_TEST
> default USB_DWC3
> select USB_ROLE_SWITCH
> + select REGMAP_MMIO
> help
>   Support USB2/3 functionality in Amlogic G12A platforms.
>Say 'Y' or 'M' if you have one such device.
> 

Acked-by: Neil Armstrong 

[PATCH v1 1/2] mm/page_alloc.c: Don't set pages PageReserved() when offlining

[David Hildenbrand]

We call __offline_isolated_pages() from __offline_pages() after all
pages were isolated and are either free (PageBuddy()) or PageHWPoison.
Nothing can stop us from offlining memory at this point.

In __offline_isolated_pages() we first set all affected memory sections
offline (offline_mem_sections(pfn, end_pfn)), to mark the memmap as
invalid (pfn_to_online_page() will no longer succeed), and then walk over
all pages to pull the free pages from the free lists (to the isolated
free lists, to be precise).

Note that re-onlining a memory block will result in the whole memmap
getting reinitialized, overwriting any old state. We already poision the
memmap when offlining is complete to find any access to
stale/uninitialized memmaps.

So, setting the pages PageReserved() is not helpful. The memap is marked
offline and all pageblocks are isolated. As soon as offline, the memmap
is stale either way.

This looks like a leftover from ancient times where we initialized the
memmap when adding memory and not when onlining it (the pages were set
PageReserved so re-onling would work as expected).

Cc: Andrew Morton 
Cc: Michal Hocko 
Cc: Vlastimil Babka 
Cc: Oscar Salvador 
Cc: Mel Gorman 
Cc: Mike Rapoport 
Cc: Dan Williams 
Cc: Wei Yang 
Cc: Alexander Duyck 
Cc: Anshuman Khandual 
Cc: Pavel Tatashin 
Signed-off-by: David Hildenbrand 
---
 mm/page_alloc.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ed8884dc0c47..bf6b21f02154 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -8667,7 +8667,7 @@ __offline_isolated_pages(unsigned long start_pfn, 
unsigned long end_pfn)
 {
struct page *page;
struct zone *zone;
-   unsigned int order, i;
+   unsigned int order;
unsigned long pfn;
unsigned long flags;
unsigned long offlined_pages = 0;
@@ -8695,7 +8695,6 @@ __offline_isolated_pages(unsigned long start_pfn, 
unsigned long end_pfn)
 */
if (unlikely(!PageBuddy(page) && PageHWPoison(page))) {
pfn++;
-   SetPageReserved(page);
offlined_pages++;
continue;
}
@@ -8709,8 +8708,6 @@ __offline_isolated_pages(unsigned long start_pfn, 
unsigned long end_pfn)
pfn, 1 << order, end_pfn);
 #endif
del_page_from_free_area(page, >free_area[order]);
-   for (i = 0; i < (1 << order); i++)
-   SetPageReserved((page+i));
pfn += (1 << order);
}
spin_unlock_irqrestore(>lock, flags);
-- 
2.21.0

[PATCH] usb: dwc3: select CONFIG_REGMAP_MMIO

[Arnd Bergmann]

After many randconfig builds, one configuration caused a link
error with dwc3-meson-g12a lacking the regmap-mmio code:

drivers/usb/dwc3/dwc3-meson-g12a.o: In function `dwc3_meson_g12a_probe':
dwc3-meson-g12a.c:(.text+0x9f): undefined reference to 
`__devm_regmap_init_mmio_clk'

Add the select statement that we have for all other users
of that dependency.

Fixes: c3376f72 ("usb: dwc3: Add Amlogic G12A DWC3 glue")
Signed-off-by: Arnd Bergmann 
---
 drivers/usb/dwc3/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 89abc6078703..556a876c7896 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -102,6 +102,7 @@ config USB_DWC3_MESON_G12A
depends on ARCH_MESON || COMPILE_TEST
default USB_DWC3
select USB_ROLE_SWITCH
+   select REGMAP_MMIO
help
  Support USB2/3 functionality in Amlogic G12A platforms.
 Say 'Y' or 'M' if you have one such device.
-- 
2.20.0

[PATCH] Revert "Bluetooth: hci_qca: Add delay for wcn3990 stability"

[Jeffrey Hugo]

This reverts commit cde9dde6e11a5ab54b6462cd46d82878926783bc.

The frame reassembly errors were root caused to a transient gpio issue.
The missing response was root caused to an issue with properly managing
RFR in the uart driver.  Addressing those root causes occurs outside of
hci_qca and eliminates the need for the 50ms delay, so remove it.

Signed-off-by: Jeffrey Hugo 
---
 drivers/bluetooth/hci_qca.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 8ae91e0f8102..c591a8ba9d93 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1155,10 +1155,8 @@ static int qca_set_speed(struct hci_uart *hu, enum 
qca_speed_type speed_type)
host_set_baudrate(hu, speed);
 
 error:
-   if (qca_is_wcn399x(soc_type)) {
-   msleep(50);
+   if (qca_is_wcn399x(soc_type))
hci_uart_set_flow_control(hu, false);
-   }
 
if (soc_type == QCA_WCN3990) {
/* Wait for the controller to send the vendor event
-- 
2.17.1

Re: [PATCH 0/7] add support for clocksource/clockevent DT selection

[Daniel Lezcano]

On 21/10/2019 10:58, claudiu.bez...@microchip.com wrote:
> Hi Daniel,
> 
> On 18.10.2019 23:24, Daniel Lezcano wrote:
>> Hi Claudiu,
>>
>> On 15/10/2019 11:23, claudiu.bez...@microchip.com wrote:
>>
>> [ ... ]
>>
>>> The timer clock source could be divided by MR.PRES + 1.
>>>
>>> So, I used the clock-frequency DT binding to let user choose the timer's
>>> frequency. Based on the value provided via this DT binding the best clock
>>> source and prescaler is chosen via mchp_pit64b_pres_prepare() function.
>>
>> I'm willing to take the driver but I doubt the purpose of the
>> clock-frequency is to let the user choose the frequency.
>>
> 
> I found this approach in the following already integrated drivers:
> drivers/clocksource/armv7m_systick.c
> drivers/clocksource/bcm2835_timer.c
> drivers/clocksource/bcm_kona_timer.c
> drivers/clocksource/mips-gic-timer.c
> drivers/clocksource/mps2-timer.c
> drivers/clocksource/timer-qcom.c
> drivers/clocksource/arm_arch_timer.c
> 
> Looking through the documentation of these, most of them document this DT
> property as the frequency of the clock that drivers the timer, but none of
> them seems to have some IP internal dividers so that the timer to tick at
> different frequency than the clock that feeds the IP. From the
> documentation of the above drivers;
> drivers/clocksource/armv7m_systick.c
>   - clock-frequency : The rate in HZ in input of the ARM SysTick
> 
> drivers/clocksource/bcm2835_timer.c
>   - clock-frequency : The frequency of the clock that drives the counter, 
> in
> Hz.
> drivers/clocksource/bcm_kona_timer.c
>   - clock-frequency: frequency that the clock operates
> 
> drivers/clocksource/mips-gic-timer.c
>   clock-frequency : Clock frequency at which the GIC timers operate.
> drivers/clocksource/mps2-timer.c
>   - clock-frequency : The rate in HZ in input of the ARM MPS2 timer
> 
> drivers/clocksource/timer-qcom.c
>   - clock-frequency : The frequency of the debug timer and the general
> purpose
> timer(s) in Hz in that order.
> 
> 
> This is why I also chose this DT bindings.
> 
> If you want I can stick to a fixed frequency hard coded in the driver.
> Please let me know if this would be OK for you.

Yes, the clock-frequency is used to specify the frequency when the
information can not be retrieved from the clock. The goal is not to
specify a frequency and compute from there a prescalar value.

Hardcoding the frequency is fine or hardcode the divider and compute the
frequency from the clock rate.



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant PHYs

[Andrew Murray]

On Mon, Oct 21, 2019 at 07:44:25PM +0530, Pankaj Dubey wrote:
> 
> 
> > -Original Message-
> > From: Andrew Murray 
> > Sent: Monday, October 21, 2019 7:34 PM
> > To: Anvesh Salveru 
> > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > bhelg...@google.com; gustavo.pimen...@synopsys.com;
> > jingooh...@gmail.com; lorenzo.pieral...@arm.com; Pankaj Dubey
> > 
> > Subject: Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant
> > PHYs
> > 
> > On Mon, Oct 21, 2019 at 05:59:53PM +0530, Anvesh Salveru wrote:
> > > Many platforms use DesignWare controller but the PHY can be different
> > > in different platforms. If the PHY is compliant is to ZRX-DC
> > > specification
> > 
> > s/is to/to the/
> 
> OK
> 
> > 
> > > it helps in low power consumption during power states.
> > 
> > s/in low/lower/
> > 
> OK
> > >
> > > If current data rate is 8.0 GT/s or higher and PHY is not compliant to
> > > ZRX-DC specification, then after every 100ms link should transition to
> > > recovery state during the low power states.
> > >
> > > DesignWare controller provides GEN3_ZRXDC_NONCOMPL field in
> > > GEN3_RELATED_OFF to specify about ZRX-DC compliant PHY.
> > >
> > > Platforms with ZRX-DC compliant PHY can set "snps,phy-zrxdc-compliant"
> > > property in controller DT node to specify this property to the
> controller.
> > >
> > > Signed-off-by: Anvesh Salveru 
> > > Signed-off-by: Pankaj Dubey 
> > > ---
> > >  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
> > > drivers/pci/controller/dwc/pcie-designware.h | 3 +++
> > >  2 files changed, 10 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > > b/drivers/pci/controller/dwc/pcie-designware.c
> > > index 820488dfeaed..6560d9f765d7 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > > @@ -556,4 +556,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
> > >  PCIE_PL_CHK_REG_CHK_REG_START;
> > >   dw_pcie_writel_dbi(pci, PCIE_PL_CHK_REG_CONTROL_STATUS,
> > val);
> > >   }
> > > +
> > > + if (of_property_read_bool(np, "snps,phy-zrxdc-compliant")) {
> > > + val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > > + val &= ~PORT_LOGIC_GEN3_ZRXDC_NONCOMPL;
> > > + dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > > + }
> > > +
> > 
> > Given that this duplicates tegra_pcie_prepare_host in pcie-tegra194.c, can
> we
> > update that driver to adopt this new binding?
> > 
> 
> Yes, Thanks for highlighting this. Otherwise I was worried that we have one
> more patch without real user :)

Indeed :|

Though besides Tegra, is there any other reason you are adding this?

> We will update pcie-tegra194.c driver and post the patch to adopt this
> binding.

It's much appreciated.

Andrew Murray

> 
> > Thanks,
> > 
> > Andrew Murray
> > 
> > >  }
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > > b/drivers/pci/controller/dwc/pcie-designware.h
> > > index 5a18e94e52c8..427a55ec43c6 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > > @@ -60,6 +60,9 @@
> > >  #define PCIE_MSI_INTR0_MASK  0x82C
> > >  #define PCIE_MSI_INTR0_STATUS0x830
> > >
> > > +#define PCIE_PORT_GEN3_RELATED   0x890
> > > +#define PORT_LOGIC_GEN3_ZRXDC_NONCOMPL   BIT(0)
> > > +
> > >  #define PCIE_ATU_VIEWPORT0x900
> > >  #define PCIE_ATU_REGION_INBOUND  BIT(31)
> > >  #define PCIE_ATU_REGION_OUTBOUND 0
> > > --
> > > 2.17.1
> > >
> 

Re: [PATCH net-next 08/16] net: dsa: use ports list to setup multiple master devices

[Andrew Lunn]

On Sun, Oct 20, 2019 at 08:03:34PM -0700, Florian Fainelli wrote:
> 
> 
> On 10/19/2019 8:19 PM, Vivien Didelot wrote:
> > Now that we have a potential list of CPU ports, make use of it instead
> > of only configuring the master device of an unique CPU port.
> 
> Out of your series, this is the only one that has possible side effects
> to existing set-up in that if you had multiple CPU ports defined, today,
> we would stop at the first one, whereas now, we will set them all up. I
> believe this is right way to do it, but have not had time to fire up a
> test on a BCM7278 w/ bcm_sf2 and this patch series to confirm that, will
> do that first thing tomorrow morning.

Hi Florian

The next patch might also change things, finding the first CPU port.
Is the order of the link list the same as searching the port array?

   Andrew

Re: [PATCH v6 3/4] arm64: use both ZONE_DMA and ZONE_DMA32

[Qian Cai]

> On Sep 11, 2019, at 2:25 PM, Nicolas Saenz Julienne  
> wrote:
> 
> So far all arm64 devices have supported 32 bit DMA masks for their
> peripherals. This is not true anymore for the Raspberry Pi 4 as most of
> it's peripherals can only address the first GB of memory on a total of
> up to 4 GB.
> 
> This goes against ZONE_DMA32's intent, as it's expected for ZONE_DMA32
> to be addressable with a 32 bit mask. So it was decided to re-introduce
> ZONE_DMA in arm64.
> 
> ZONE_DMA will contain the lower 1G of memory, which is currently the
> memory area addressable by any peripheral on an arm64 device.
> ZONE_DMA32 will contain the rest of the 32 bit addressable memory.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> Reviewed-by: Catalin Marinas 
> 
> ---
> 
> I kept the Reviewed-by as the last bug solution was proposed by Catalin
> 
> Changes in v6:
> - Fixed bug in max_zone_phys
> 
> Changes in v5:
> - Fixed swiotlb initialization
> 
> Changes in v4:
> - Fixed issue when NUMA=n and ZONE_DMA=n
> - Merged two max_zone_dma*_phys() functions
> 
> Changes in v3:
> - Used fixed size ZONE_DMA
> - Fix check befor swiotlb_init()
> 
> Changes in v2:
> - Update comment to reflect new zones split
> - ZONE_DMA will never be left empty
> 
> arch/arm64/Kconfig|  4 +++
> arch/arm64/include/asm/page.h |  2 ++
> arch/arm64/mm/init.c  | 54 +--
> 3 files changed, 45 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 6b6362b83004..2dbe0165bd15 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -267,6 +267,10 @@ config GENERIC_CSUM
> config GENERIC_CALIBRATE_DELAY
>   def_bool y
> 
> +config ZONE_DMA
> + bool "Support DMA zone" if EXPERT
> + default y
> +
> config ZONE_DMA32
>   bool "Support DMA32 zone" if EXPERT
>   default y
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index d39ddb258a04..7b8c98830101 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -38,4 +38,6 @@ extern int pfn_valid(unsigned long);
> 
> #include 
> 
> +#define ARCH_ZONE_DMA_BITS 30
> +
> #endif
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 8e9bc64c5878..44f07fdf7a59 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -56,6 +56,13 @@ EXPORT_SYMBOL(physvirt_offset);
> struct page *vmemmap __ro_after_init;
> EXPORT_SYMBOL(vmemmap);
> 
> +/*
> + * We create both ZONE_DMA and ZONE_DMA32. ZONE_DMA covers the first 1G of
> + * memory as some devices, namely the Raspberry Pi 4, have peripherals with
> + * this limited view of the memory. ZONE_DMA32 will cover the rest of the 32
> + * bit addressable memory area.
> + */
> +phys_addr_t arm64_dma_phys_limit __ro_after_init;
> phys_addr_t arm64_dma32_phys_limit __ro_after_init;
> 
> #ifdef CONFIG_KEXEC_CORE
> @@ -169,15 +176,16 @@ static void __init reserve_elfcorehdr(void)
> {
> }
> #endif /* CONFIG_CRASH_DUMP */
> +
> /*
> - * Return the maximum physical address for ZONE_DMA32 (DMA_BIT_MASK(32)). It
> - * currently assumes that for memory starting above 4G, 32-bit devices will
> - * use a DMA offset.
> + * Return the maximum physical address for a zone with a given address size
> + * limit. It currently assumes that for memory starting above 4G, 32-bit
> + * devices will use a DMA offset.
>  */
> -static phys_addr_t __init max_zone_dma32_phys(void)
> +static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
> {
> - phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 32);
> - return min(offset + (1ULL << 32), memblock_end_of_DRAM());
> + phys_addr_t offset = memblock_start_of_DRAM() & GENMASK_ULL(63, 
> zone_bits);
> + return min(offset + (1ULL << zone_bits), memblock_end_of_DRAM());
> }
> 
> #ifdef CONFIG_NUMA
> @@ -186,6 +194,9 @@ static void __init zone_sizes_init(unsigned long min, 
> unsigned long max)
> {
>   unsigned long max_zone_pfns[MAX_NR_ZONES]  = {0};
> 
> +#ifdef CONFIG_ZONE_DMA
> + max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
> +#endif
> #ifdef CONFIG_ZONE_DMA32
>   max_zone_pfns[ZONE_DMA32] = PFN_DOWN(arm64_dma32_phys_limit);
> #endif
> @@ -201,13 +212,18 @@ static void __init zone_sizes_init(unsigned long min, 
> unsigned long max)
>   struct memblock_region *reg;
>   unsigned long zone_size[MAX_NR_ZONES], zhole_size[MAX_NR_ZONES];
>   unsigned long max_dma32 = min;
> + unsigned long max_dma = min;
> 
>   memset(zone_size, 0, sizeof(zone_size));
> 
> - /* 4GB maximum for 32-bit only capable devices */
> +#ifdef CONFIG_ZONE_DMA
> + max_dma = PFN_DOWN(arm64_dma_phys_limit);
> + zone_size[ZONE_DMA] = max_dma - min;
> + max_dma32 = max_dma;
> +#endif
> #ifdef CONFIG_ZONE_DMA32
>   max_dma32 = PFN_DOWN(arm64_dma32_phys_limit);
> - zone_size[ZONE_DMA32] = max_dma32 - min;
> + zone_size[ZONE_DMA32] = max_dma32 - max_dma;
> #endif
>   zone_size[ZONE_NORMAL] 

Re: [PATCH v2 net-next] net: axienet: In kconfig add ARM64 as supported platform

[Michal Simek]

On 21. 10. 19 12:18, Radhey Shyam Pandey wrote:
> xilinx axi_emac driver is supported on ZynqMP UltraScale platform.
> So enable ARCH64 in kconfig. It also removes redundant ARCH_ZYNQ
> dependency. Basic sanity testing is done on zu+ mpsoc zcu102
> evaluation board.
> 
> Signed-off-by: Radhey Shyam Pandey 
> ---
> Changes for v2:
> Remove redundant ARCH_ZYNQ dependency.
> Modified commit description.
> ---
>  drivers/net/ethernet/xilinx/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/xilinx/Kconfig 
> b/drivers/net/ethernet/xilinx/Kconfig
> index 8d994ce..da11876 100644
> --- a/drivers/net/ethernet/xilinx/Kconfig
> +++ b/drivers/net/ethernet/xilinx/Kconfig
> @@ -6,7 +6,7 @@
>  config NET_VENDOR_XILINX
>   bool "Xilinx devices"
>   default y
> - depends on PPC || PPC32 || MICROBLAZE || ARCH_ZYNQ || MIPS || X86 || 
> ARM || COMPILE_TEST
> + depends on PPC || PPC32 || MICROBLAZE || MIPS || X86 || ARM || ARM64 || 
> COMPILE_TEST
>   ---help---
> If you have a network (Ethernet) card belonging to this class, say Y.
>  
> @@ -26,11 +26,11 @@ config XILINX_EMACLITE
>  
>  config XILINX_AXI_EMAC
>   tristate "Xilinx 10/100/1000 AXI Ethernet support"
> - depends on MICROBLAZE || X86 || ARM || COMPILE_TEST
> + depends on MICROBLAZE || X86 || ARM || ARM64 || COMPILE_TEST
>   select PHYLINK
>   ---help---
> This driver supports the 10/100/1000 Ethernet from Xilinx for the
> -   AXI bus interface used in Xilinx Virtex FPGAs.
> +   AXI bus interface used in Xilinx Virtex FPGAs and Soc's.
>  
>  config XILINX_LL_TEMAC
>   tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver"
> 

Acked-by: Michal Simek 

But I can image that others could prefer to remove all dependencies.

Thanks,
Michal

Re: [PATCH 1/2] dt-bindings: PCI: designware: Add binding for ZRX-DC PHY property

[Andrew Murray]

On Mon, Oct 21, 2019 at 05:55:55PM +0530, Anvesh Salveru wrote:
> Add support for ZRX-DC compliant PHYs. If PHY is not compliant to ZRX-DC
> specification, then after every 100ms link should transition to recovery
> state during the low power states which increases power consumption.
> 
> Platforms with ZRX-DC compliant PHY can use "snps,phy-zrxdc-compliant"
> property in DesignWare controller DT node.
> 
> Signed-off-by: Anvesh Salveru 
> Signed-off-by: Pankaj Dubey 
> ---
>  Documentation/devicetree/bindings/pci/designware-pcie.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt 
> b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> index 78494c4050f7..9507ac38ac89 100644
> --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
> @@ -38,6 +38,8 @@ Optional properties:
> for data corruption. CDM registers include standard PCIe configuration
> space registers, Port Logic registers, DMA and iATU (internal Address
> Translation Unit) registers.
> +- snps,phy-zrxdc-compliant: This property is needed if phy complies with the

Strictly speaking, this is a property of the phy - not the controller that
uses it.

If I understand correctly, there are some DW based PCI controllers that use
a phandle reference in DT to a Phy (such as fsl,imx6q-pcie.txt). Therefore
it feels like this is in the wrong place. Is there a reason this isn't
described in the Phy?

Thanks,

Andrew Murray

> +  ZRX-DC specification.
>  RC mode:
>  - num-viewport: number of view ports configured in hardware. If a platform
>does not specify it, the driver assumes 2.
> -- 
> 2.17.1
> 

[PATCH] pinctrl: qcom: sc7180: Add missing tile info in SDC_QDSD_PINGROUP/UFS_RESET

[Rajendra Nayak]

The SDC_QDSD_PINGROUP/UFS_RESET macros are missing the .tile info needed to
calculate the right register offsets. Adding them here and also
adjusting the offsets accordingly.

Fixes: f2ae04c45b1a ("pinctrl: qcom: Add SC7180 pinctrl driver")

Reported-by: Veerabhadrarao Badiganti 
Signed-off-by: Rajendra Nayak 
---
 drivers/pinctrl/qcom/pinctrl-sc7180.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-sc7180.c 
b/drivers/pinctrl/qcom/pinctrl-sc7180.c
index 6399c8a2bc22..d6cfad7417b1 100644
--- a/drivers/pinctrl/qcom/pinctrl-sc7180.c
+++ b/drivers/pinctrl/qcom/pinctrl-sc7180.c
@@ -77,6 +77,7 @@ enum {
.intr_cfg_reg = 0,  \
.intr_status_reg = 0,   \
.intr_target_reg = 0,   \
+   .tile = SOUTH,  \
.mux_bit = -1,  \
.pull_bit = pull,   \
.drv_bit = drv, \
@@ -102,6 +103,7 @@ enum {
.intr_cfg_reg = 0,  \
.intr_status_reg = 0,   \
.intr_target_reg = 0,   \
+   .tile = SOUTH,  \
.mux_bit = -1,  \
.pull_bit = 3,  \
.drv_bit = 0,   \
@@ -1087,14 +1089,14 @@ static const struct msm_pingroup sc7180_groups[] = {
[116] = PINGROUP(116, WEST, qup04, qup04, _, _, _, _, _, _, _),
[117] = PINGROUP(117, WEST, dp_hot, _, _, _, _, _, _, _, _),
[118] = PINGROUP(118, WEST, _, _, _, _, _, _, _, _, _),
-   [119] = UFS_RESET(ufs_reset, 0x97f000),
-   [120] = SDC_QDSD_PINGROUP(sdc1_rclk, 0x97a000, 15, 0),
-   [121] = SDC_QDSD_PINGROUP(sdc1_clk, 0x97a000, 13, 6),
-   [122] = SDC_QDSD_PINGROUP(sdc1_cmd, 0x97a000, 11, 3),
-   [123] = SDC_QDSD_PINGROUP(sdc1_data, 0x97a000, 9, 0),
-   [124] = SDC_QDSD_PINGROUP(sdc2_clk, 0x97b000, 14, 6),
-   [125] = SDC_QDSD_PINGROUP(sdc2_cmd, 0x97b000, 11, 3),
-   [126] = SDC_QDSD_PINGROUP(sdc2_data, 0x97b000, 9, 0),
+   [119] = UFS_RESET(ufs_reset, 0x7f000),
+   [120] = SDC_QDSD_PINGROUP(sdc1_rclk, 0x7a000, 15, 0),
+   [121] = SDC_QDSD_PINGROUP(sdc1_clk, 0x7a000, 13, 6),
+   [122] = SDC_QDSD_PINGROUP(sdc1_cmd, 0x7a000, 11, 3),
+   [123] = SDC_QDSD_PINGROUP(sdc1_data, 0x7a000, 9, 0),
+   [124] = SDC_QDSD_PINGROUP(sdc2_clk, 0x7b000, 14, 6),
+   [125] = SDC_QDSD_PINGROUP(sdc2_cmd, 0x7b000, 11, 3),
+   [126] = SDC_QDSD_PINGROUP(sdc2_data, 0x7b000, 9, 0),
 };
 
 static const struct msm_pinctrl_soc_data sc7180_pinctrl = {
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH v3 0/8] Arasan SDHCI enhancements and ZynqMP Tap Delays Handling

[Ulf Hansson]

On Thu, 17 Oct 2019 at 08:22, Manish Narani  wrote:
>
> This patch series does the following:
>  - Reorganize the Clock Handling in Arasan SD driver
>  - Adds new sampling clock in Arasan SD driver
>  - Adds support to set Clock Delays in SD Arasan Driver
>  - Add SDIO Tap Delay handling in ZynqMP firmware driver
>  - Add support for ZynqMP Tap Delays setting in Arasan SD driver
>
> Changes in v2:
> - Replaced the deprecated calls to clock framework APIs
> - Added support for dev_clk_get() call to work for SD card clock
> - Separated the clock data struct
> - Fragmented the patch series in smaller patches to make it more
>   readable
>
> Changes in v3:
> - Reverted "Replaced the deprecated calls to clock framework APIs"
> - Removed devm_clk_get() call which was added in v2
>
> Manish Narani (8):
>   mmc: sdhci-of-arasan: Separate out clk related data to another
> structure
>   dt-bindings: mmc: arasan: Update Documentation for the input clock
>   mmc: sdhci-of-arasan: Add sampling clock for a phy to use
>   dt-bindings: mmc: arasan: Add optional properties for Arasan SDHCI
>   mmc: sdhci-of-arasan: Add support to set clock phase delays for SD
>   firmware: xilinx: Add SDIO Tap Delay nodes
>   dt-bindings: mmc: arasan: Document 'xlnx,zynqmp-8.9a' controller
>   mmc: sdhci-of-arasan: Add support for ZynqMP Platform Tap Delays Setup
>
>  .../devicetree/bindings/mmc/arasan,sdhci.txt  |  40 +-
>  drivers/mmc/host/sdhci-of-arasan.c| 477 +-
>  include/linux/firmware/xlnx-zynqmp.h  |  13 +-
>  3 files changed, 498 insertions(+), 32 deletions(-)
>
> --
> 2.17.1
>

Manish, the series looks good to me. However, I expect you to post a
re-spin, to move some of the new DT bindings into common mmc DT
bindings, as Rob suggested.

So waiting for another version, before I apply it.

Kind regards
Uffe

RE: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant PHYs

[Pankaj Dubey]

> -Original Message-
> From: Andrew Murray 
> Sent: Monday, October 21, 2019 7:34 PM
> To: Anvesh Salveru 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> bhelg...@google.com; gustavo.pimen...@synopsys.com;
> jingooh...@gmail.com; lorenzo.pieral...@arm.com; Pankaj Dubey
> 
> Subject: Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant
> PHYs
> 
> On Mon, Oct 21, 2019 at 05:59:53PM +0530, Anvesh Salveru wrote:
> > Many platforms use DesignWare controller but the PHY can be different
> > in different platforms. If the PHY is compliant is to ZRX-DC
> > specification
> 
> s/is to/to the/

OK

> 
> > it helps in low power consumption during power states.
> 
> s/in low/lower/
> 
OK
> >
> > If current data rate is 8.0 GT/s or higher and PHY is not compliant to
> > ZRX-DC specification, then after every 100ms link should transition to
> > recovery state during the low power states.
> >
> > DesignWare controller provides GEN3_ZRXDC_NONCOMPL field in
> > GEN3_RELATED_OFF to specify about ZRX-DC compliant PHY.
> >
> > Platforms with ZRX-DC compliant PHY can set "snps,phy-zrxdc-compliant"
> > property in controller DT node to specify this property to the
controller.
> >
> > Signed-off-by: Anvesh Salveru 
> > Signed-off-by: Pankaj Dubey 
> > ---
> >  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
> > drivers/pci/controller/dwc/pcie-designware.h | 3 +++
> >  2 files changed, 10 insertions(+)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.c
> > b/drivers/pci/controller/dwc/pcie-designware.c
> > index 820488dfeaed..6560d9f765d7 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware.c
> > @@ -556,4 +556,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
> >PCIE_PL_CHK_REG_CHK_REG_START;
> > dw_pcie_writel_dbi(pci, PCIE_PL_CHK_REG_CONTROL_STATUS,
> val);
> > }
> > +
> > +   if (of_property_read_bool(np, "snps,phy-zrxdc-compliant")) {
> > +   val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> > +   val &= ~PORT_LOGIC_GEN3_ZRXDC_NONCOMPL;
> > +   dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> > +   }
> > +
> 
> Given that this duplicates tegra_pcie_prepare_host in pcie-tegra194.c, can
we
> update that driver to adopt this new binding?
> 

Yes, Thanks for highlighting this. Otherwise I was worried that we have one
more patch without real user :)
We will update pcie-tegra194.c driver and post the patch to adopt this
binding.

> Thanks,
> 
> Andrew Murray
> 
> >  }
> > diff --git a/drivers/pci/controller/dwc/pcie-designware.h
> > b/drivers/pci/controller/dwc/pcie-designware.h
> > index 5a18e94e52c8..427a55ec43c6 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware.h
> > +++ b/drivers/pci/controller/dwc/pcie-designware.h
> > @@ -60,6 +60,9 @@
> >  #define PCIE_MSI_INTR0_MASK0x82C
> >  #define PCIE_MSI_INTR0_STATUS  0x830
> >
> > +#define PCIE_PORT_GEN3_RELATED 0x890
> > +#define PORT_LOGIC_GEN3_ZRXDC_NONCOMPL BIT(0)
> > +
> >  #define PCIE_ATU_VIEWPORT  0x900
> >  #define PCIE_ATU_REGION_INBOUNDBIT(31)
> >  #define PCIE_ATU_REGION_OUTBOUND   0
> > --
> > 2.17.1
> >

Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()

[Jessica Yu]

+++ Petr Mladek [18/10/19 15:40 +0200]:

On Fri 2019-10-18 15:03:42, Jessica Yu wrote:

+++ Miroslav Benes [16/10/19 15:29 +0200]:
> On Wed, 16 Oct 2019, Miroslav Benes wrote:
> Thinking about it more... crazy idea. I think we could leverage these new
> ELF .text per vmlinux/module sections for the reinvention I was talking
> about. If we teach module loader to relocate (and apply alternatives and
> so on, everything in arch-specific module_finalize()) not the whole module
> in case of live patch modules, but separate ELF .text sections, it could
> solve the issue with late module patching we have. It is a variation on
> Steven's idea. When live patch module is loaded, only its section for
> present modules would be processed. Then whenever a to-be-patched module
> is loaded, its .text section in all present patch module would be
> processed.
>
> The upside is that almost no work would be required on patch modules
> creation side. The downside is that klp_modinfo must stay. Module loader
> needs to be hacked a lot in both cases. So it remains to be seen which
> idea is easier to implement.
>
> Jessica, do you think it would be feasible?

I think that does sound feasible. I'm trying to visualize how that
would look. I guess there would need to be various livepatching hooks
called during the different stages (apply_relocate_add(),
module_finalize(), module_enable_ro/x()).

So maybe something like the following?

When a livepatch module loads:
   apply_relocate_add()
   klp hook: apply .klp.rela.$objname relocations *only* for
   already loaded modules
   module_finalize()
   klp hook: apply .klp.arch.$objname changes for already loaded modules
   module_enable_ro()
   klp hook: only enable ro/x for .klp.text.$objname for already
   loaded modules


Just for record. We should also set ro for the not-yet used
.klp.text.$objname at this stage so that it can't be modified
easily "by accident".


If we also set ro protection already for .klp.text.$objname for
not-yet loaded modules, I think this would unfortunately mean we would
still have to do the protection flipping for late module patching that
Peter was trying to avoid, right?

That is, we *still* end up having to do the whole module_disable_ro()
-> apply_relocate_add() -> module_finalize() -> module_enable_ro()
thing for late module patching, except now we've moved that work to
the module loader instead of in klp_module_coming.. It sounds just as
complicated as the current way :/

However, I think this complaint would not apply if livepatch switches
to the one patch module per module model..

Re: [PATCH v4 15/16] module: Move where we mark modules RO,X

[Peter Zijlstra]

On Mon, Oct 21, 2019 at 08:53:12AM -0500, Josh Poimboeuf wrote:
> On Fri, Oct 18, 2019 at 09:35:40AM +0200, Peter Zijlstra wrote:
> > Now that set_all_modules_text_*() is gone, nothing depends on the
> > relation between ->state = COMING and the protection state anymore.
> > This enables moving the protection changes later, such that the COMING
> > notifier callbacks can more easily modify the text.
> > 
> > Signed-off-by: Peter Zijlstra (Intel) 
> > Cc: Jessica Yu 
> > ---
> >  kernel/module.c |8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > --- a/kernel/module.c
> > +++ b/kernel/module.c
> > @@ -3683,10 +3683,6 @@ static int complete_formation(struct mod
> > /* This relies on module_mutex for list integrity. */
> > module_bug_finalize(info->hdr, info->sechdrs, mod);
> >  
> > -   module_enable_ro(mod, false);
> > -   module_enable_nx(mod);
> > -   module_enable_x(mod);
> > -
> > /* Mark state as coming so strong_try_module_get() ignores us,
> >  * but kallsyms etc. can see us. */
> > mod->state = MODULE_STATE_COMING;
> > @@ -3852,6 +3848,10 @@ static int load_module(struct load_info
> > if (err)
> > goto bug_cleanup;
> >  
> > +   module_enable_ro(mod, false);
> > +   module_enable_nx(mod);
> > +   module_enable_x(mod);
> > +
> > /* Module is ready to execute: parsing args may do that. */
> > after_dashes = parse_args(mod->name, mod->args, mod->kp, mod->num_kp,
> >   -32768, 32767, mod,
> 
> [ Sorry if this was already discussed, I still have a large backlog. ]
> 
> Doesn't livepatch code also need to be modified?  We have:

Urgh bah.. I was too focussed on the other klp borkage :/ But yes,
arm64/ftrace and klp are the only two users of that function (outside of
module.c) and Mark was already writing a patch for arm64.

Means these last two patches need to wait a little until we've fixed
those.

Re: [PATCH 1/3] mm, meminit: Recalculate pcpu batch and high limits after init completes

[Michal Hocko]

On Mon 21-10-19 10:01:24, Qian Cai wrote:
> 
> 
> > On Oct 21, 2019, at 5:48 AM, Mel Gorman  wrote:
i[...]
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index c0b2e0306720..f972076d0f6b 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -1947,6 +1947,14 @@ void __init page_alloc_init_late(void)
> > /* Block until all are initialised */
> > wait_for_completion(_init_all_done_comp);
> > 
> > +   /*
> > +* The number of managed pages has changed due to the initialisation
> > +* so the pcpu batch and high limits needs to be updated or the limits
> > +* will be artificially small.
> > +*/
> > +   for_each_populated_zone(zone)
> > +   zone_pcp_update(zone);
> > +
> > /*
> >  * We initialized the rest of the deferred pages.  Permanently disable
> >  * on-demand struct page initialization.
> > -- 
> > 2.16.4
> > 
> > 
> 
> Warnings from linux-next,
> 
> [   14.265911][  T659] BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:935
> [   14.265992][  T659] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 
> 659, name: pgdatinit8
> [   14.266044][  T659] 1 lock held by pgdatinit8/659:
> [   14.266075][  T659]  #0: c000201ffca87b40 
> (&(>node_size_lock)->rlock){}, at: deferred_init_memmap+0xc4/0x26c

This is really surprising to say the least. I do not see any spinlock
held here. Besides that we do sleep in wait_for_completion already.
Is it possible that the patch has been misplaced? zone_pcp_update is
called from page_alloc_init_late which is a different context than
deferred_init_memmap which runs in a separate kthread.

> [   14.266160][  T659] irq event stamp: 26
> [   14.266194][  T659] hardirqs last  enabled at (25): [] 
> _raw_spin_unlock_irq+0x44/0x80
> [   14.266246][  T659] hardirqs last disabled at (26): [] 
> _raw_spin_lock_irqsave+0x3c/0xa0
> [   14.266299][  T659] softirqs last  enabled at (0): [] 
> copy_process+0x720/0x19b0
> [   14.266339][  T659] softirqs last disabled at (0): [<>] 0x0
> [   14.266400][  T659] CPU: 64 PID: 659 Comm: pgdatinit8 Not tainted 
> 5.4.0-rc4-next-20191021 #1
> [   14.266462][  T659] Call Trace:
> [   14.266494][  T659] [c0003d8efae0] [c0921cf4] 
> dump_stack+0xe8/0x164 (unreliable)
> [   14.266538][  T659] [c0003d8efb30] [c0157c54] 
> ___might_sleep+0x334/0x370
> [   14.266577][  T659] [c0003d8efbb0] [c094a784] 
> __mutex_lock+0x84/0xb20
> [   14.266627][  T659] [c0003d8efcc0] [c0954038] 
> zone_pcp_update+0x34/0x64
> [   14.266677][  T659] [c0003d8efcf0] [c0b9e6bc] 
> deferred_init_memmap+0x1b8/0x26c
> [   14.266740][  T659] [c0003d8efdb0] [c0149528] 
> kthread+0x1a8/0x1b0
> [   14.266792][  T659] [c0003d8efe20] [c000b748] 
> ret_from_kernel_thread+0x5c/0x74
> [   14.268288][  T659] node 8 initialised, 1879186 pages in 12200ms
> [   14.268527][  T659] pgdatinit8 (659) used greatest stack depth: 27984 
> bytes left
> [   15.589983][  T658] BUG: sleeping function called from invalid context at 
> kernel/locking/mutex.c:935
> [   15.590041][  T658] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 
> 658, name: pgdatinit0
> [   15.590078][  T658] 1 lock held by pgdatinit0/658:
> [   15.590108][  T658]  #0: c01fff5c7b40 
> (&(>node_size_lock)->rlock){}, at: deferred_init_memmap+0xc4/0x26c
> [   15.590192][  T658] irq event stamp: 18
> [   15.590224][  T658] hardirqs last  enabled at (17): [] 
> _raw_spin_unlock_irqrestore+0x94/0xd0
> [   15.590283][  T658] hardirqs last disabled at (18): [] 
> _raw_spin_lock_irqsave+0x3c/0xa0
> [   15.590332][  T658] softirqs last  enabled at (0): [] 
> copy_process+0x720/0x19b0
> [   15.590379][  T658] softirqs last disabled at (0): [<>] 0x0
> [   15.590414][  T658] CPU: 8 PID: 658 Comm: pgdatinit0 Tainted: GW   
>   5.4.0-rc4-next-20191021 #1
> [   15.590460][  T658] Call Trace:
> [   15.590491][  T658] [c0003d8cfae0] [c0921cf4] 
> dump_stack+0xe8/0x164 (unreliable)
> [   15.590541][  T658] [c0003d8cfb30] [c0157c54] 
> ___might_sleep+0x334/0x370
> [   15.590588][  T658] [c0003d8cfbb0] [c094a784] 
> __mutex_lock+0x84/0xb20
> [   15.590643][  T658] [c0003d8cfcc0] [c0954038] 
> zone_pcp_update+0x34/0x64
> [   15.590689][  T658] [c0003d8cfcf0] [c0b9e6bc] 
> deferred_init_memmap+0x1b8/0x26c
> [   15.590739][  T658] [c0003d8cfdb0] [c0149528] 
> kthread+0x1a8/0x1b0
> [   15.590790][  T658] [c0003d8cfe20] [c000b748] 
> ret_from_kernel_thread+0x5c/0x74

-- 
Michal Hocko
SUSE Labs

Re: [RFCv1 5/5] arm64/ARM: configs: Change CONFIG_PWM_MESON from m to y

[Anand Moon]

Hi Martin,

On Fri, 18 Oct 2019 at 23:40, Martin Blumenstingl
 wrote:
>
> Hi Anand,
>
> On Fri, Oct 18, 2019 at 4:04 PM Anand Moon  wrote:
> [...]
> > > Next step it to try narrow down the clock causing the issue.
> > > Remove clk_ignore_unused from the command line and add CLK_INGORE_UNUSED
> > > to the flag of some clocks your clock controller (g12a I think) until
> > >
> > > The peripheral clock gates already have this flag (something we should
> > > fix someday) so don't bother looking there.
> > >
> > > Most likely the source of the pwm is getting disabled between the
> > > late_init call and the probe of the PWM module. Since the pwm is already
> > > active (w/o a driver), gating the clock source shuts dowm the power to
> > > the cores.
> > >
> > > Looking a the possible inputs in pwm driver, I'd bet on fdiv4.
> > >
> >
> > I had give this above steps a try but with little success.
> > I am still looking into this much close.
> it's not clear to me if you have only tested with the PWM and/or
> FCLK_DIV4 clocks. can you please describe what you have tested so far?
>
Sorry for delayed response.

I had just looked into clk related to SD_EMMC_A/B/C,
with adding CLK_IGNORE/CRITICAL.
Also looked into clk_summary for eMMC and microSD card,
to identify the root cause, but I failed to move ahead.

> for reference - my way of debugging this in the past was:
> 1. add some printks to clk_disable_unused_subtree (right after the
> clk_core_is_enabled check) to see which clocks are being disabled
> 2. add CLK_IGNORE_UNUSED or CLK_IS_CRITICAL to the clocks which are
> being disabled based on the information from step #1
> 3. (at some point I had a working kernel with lots of clocks with
> CLK_IGNORE_UNUSED/CLK_IS_CRITICAL)
> 4. start dropping the CLK_IGNORE_UNUSED/CLK_IS_CRITICAL flags again
> until you have traced it down to the clocks that are the actual issue
> (so far I always had only one clock which caused issues, but it may be
> multiple)
> 5. investigate (and/or ask on the mailing list, Amlogic developers are
> reading the mails here as well) for the few clocks from step #4
>

Thanks for you valuable suggestion. I have your patch to debug this
[0]  https://patchwork.kernel.org/patch/9725921/mbox/

So from the fist step I could identify that all the clk were getting closed
after some core cpu clk was failing. Here is the log.

step1: [1] https://pastebin.com/p13F9HGG

so I marked these clk as CLK_IGNORE_UNUSED and finally
I made it to boot using microSD card.

After this just I converted these CLK to CLK_IS_CRITICAL
as mostly these are used the CPU clk for now.
Here is boot log successful for as of now.

Finally: [2]  https://pastebin.com/qB6pMyGQ

I know clk maintainer are against marking flags as *CLK_IS_CRITICAL*
But this is just the step to move ahead.

Attach is my local clk and dts patch.Just for testing.
[3] clk_critical.patch

Plz share your thought on this.

> > Well I am not the expert in clk or bus configuration.
> > but after looking into the datasheet of for clk configuration
> > I found some bus are not configured correctly.
> did you find any reason which indicates that the problem is related to a bus?
> the issues I had were due to clocks not being assigned to their
> consumers in .dts - that can be anything (from a bus to something
> different).
>

Yes I feel each core bus should be independent
as each clk PLL controls these bus.

for example datasheet: *6-5 Clock Connections*

What I feel currently missing with bus are
clock gating (enable/disable of features).
clock-controller
reset-controller

Here is the current overview of bus topology
using latest u-boot (dm tree).

[4] https://pastebin.com/MZ25bgiP

Bet Regards
-Anand


clk_critical.patch
Description: Binary data

[PATCH] x86/ftrace: Get rid of function_hook

[Borislav Petkov]

From: Borislav Petkov 

function_hook is used as a better name than the default __fentry__
which is the profiling counter which gcc adds before every function's
prologue. Thus, it is not called from C and cannot have the same
semantics as a pure C function - it saves/restores regs so that a C
function can be called.

Drop the function_hook symbol and use __fentry__ directly for better
alignment with gcc's documentation.

Switch the marking to SYM_CODE_START/_END which is reserved for
non-standard, special functions.

Signed-off-by: Borislav Petkov 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jiri Slaby 
Cc: Jonathan Corbet 
Cc: Josh Poimboeuf 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Peter Zijlstra 
Cc: "Steven Rostedt (VMware)" 
Cc: Thomas Gleixner 
Cc: x...@kernel.org
---
 Documentation/asm-annotations.rst |  4 ++--
 arch/x86/kernel/ftrace_32.S   |  8 +++-
 arch/x86/kernel/ftrace_64.S   | 13 ++---
 3 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/Documentation/asm-annotations.rst 
b/Documentation/asm-annotations.rst
index 29ccd6e61fe5..f55c2bb74d00 100644
--- a/Documentation/asm-annotations.rst
+++ b/Documentation/asm-annotations.rst
@@ -117,9 +117,9 @@ This section covers ``SYM_FUNC_*`` and ``SYM_CODE_*`` 
enumerated above.
   So in most cases, developers should write something like in the following
   example, having some asm instructions in between the macros, of course::
 
-SYM_FUNC_START(function_hook)
+SYM_FUNC_START(memset)
 ... asm insns ...
-SYM_FUNC_END(function_hook)
+SYM_FUNC_END(memset)
 
   In fact, this kind of annotation corresponds to the now deprecated ``ENTRY``
   and ``ENDPROC`` macros.
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 8ed1f5d371f0..77be7e7e5e59 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -12,18 +12,16 @@
 #include 
 #include 
 
-# define function_hook __fentry__
-EXPORT_SYMBOL(__fentry__)
-
 #ifdef CONFIG_FRAME_POINTER
 # define MCOUNT_FRAME  1   /* using frame = true  */
 #else
 # define MCOUNT_FRAME  0   /* using frame = false */
 #endif
 
-SYM_FUNC_START(function_hook)
+SYM_CODE_START(__fentry__)
ret
-SYM_FUNC_END(function_hook)
+SYM_CODE_END(__fentry__)
+EXPORT_SYMBOL(__fentry__)
 
 SYM_CODE_START(ftrace_caller)
 
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index 69c8d1b9119e..3029fe4f8547 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -14,9 +14,6 @@
.code64
.section .entry.text, "ax"
 
-# define function_hook __fentry__
-EXPORT_SYMBOL(__fentry__)
-
 #ifdef CONFIG_FRAME_POINTER
 /* Save parent and function stack frames (rip and rbp) */
 #  define MCOUNT_FRAME_SIZE(8+16*2)
@@ -132,9 +129,10 @@ EXPORT_SYMBOL(__fentry__)
 
 #ifdef CONFIG_DYNAMIC_FTRACE
 
-SYM_FUNC_START(function_hook)
+SYM_CODE_START(__fentry__)
retq
-SYM_FUNC_END(function_hook)
+SYM_CODE_END(__fentry__)
+EXPORT_SYMBOL(__fentry__)
 
 SYM_FUNC_START(ftrace_caller)
/* save_mcount_regs fills in first two parameters */
@@ -248,7 +246,7 @@ SYM_FUNC_END(ftrace_regs_caller)
 
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
-SYM_FUNC_START(function_hook)
+SYM_CODE_START(__fentry__)
cmpq $ftrace_stub, ftrace_trace_function
jnz trace
 
@@ -279,7 +277,8 @@ trace:
restore_mcount_regs
 
jmp fgraph_trace
-SYM_FUNC_END(function_hook)
+SYM_CODE_END(__fentry__)
+EXPORT_SYMBOL(__fentry__)
 #endif /* CONFIG_DYNAMIC_FTRACE */
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
-- 
2.21.0


-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH 2/3] watchdog/softlockup: Report the same softlockup regularly

[Peter Zijlstra]

On Mon, Oct 21, 2019 at 03:40:38PM +0200, Petr Mladek wrote:
> On Mon 2019-10-21 14:43:39, Peter Zijlstra wrote:
> > On Mon, Aug 19, 2019 at 12:47:31PM +0200, Petr Mladek wrote:
> > > Softlockup report means that there is no progress on the given CPU. It
> > > might be a "short" affair where the system gets recovered. But often
> > > the system stops being responsive and need to get rebooted.
> > > 
> > > The softlockup might be root of the problems or just a symptom. It might
> > > be a deadlock, livelock, or often repeated state.
> > > 
> > > Regular reports help to distinguish different situations. Fortunately,
> > > the watchdog is finally able to show correct information how long
> > > softlockup_fn() was not scheduled.
> > > 
> > > Report before this patch:
> > > 
> > > [  320.248948] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! 
> > > [cat:4916]
> > > 
> > > And after this patch:
> > > 
> > > [  480.372418] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! 
> > > [cat:4943]
> > > [  508.372359] watchdog: BUG: soft lockup - CPU#2 stuck for 52s! 
> > > [cat:4943]
> > > [  548.372359] watchdog: BUG: soft lockup - CPU#2 stuck for 89s! 
> > > [cat:4943]
> > > [  576.372351] watchdog: BUG: soft lockup - CPU#2 stuck for 115s! 
> > > [cat:4943]
> > > 
> > > Note that the horrible code never really worked before the accounting
> > > was fixed. The last working timestamp was regularly lost by the many
> > > touch*watchdog() calls.
> > 
> > So what's the point of patch 1? Just confusing people?
> 
> I was not sure what was the expected behavior. The code actually
> looked like only the first report was wanted. But it probably never
> worked that way.

Not that I can remember at least :-) I normally don't bother with the
actual time, and if I do then I look at the printk timestamps to figure
out how long thing've been stuck.

But this is indeed nicer..

> Should I squash the two patches and send it again, please?

Probably makes sense to squash it. That also avoids having to ever
expose that ugleh :-)

[PATCH 2/4] iio: adc: ad7091r5: Add scale and external VREF support

[Beniamin Bia]

From: Paul Cercueil 

The scale can now be obtained with the "in_voltage_scale" file.
By default, the scale returned corresponds to the internal VREF of 2.5V.

It is possible to use an external VREF (through the REFIN/REFOUT pin of
the chip), by passing a regulator to the driver. The scale will then be
calculated according to the voltage reported by the regulator.

Signed-off-by: Paul Cercueil 
Co-developed-by: Beniamin Bia 
Signed-off-by: Beniamin Bia 
---
 drivers/iio/adc/ad7091r-base.c | 42 +-
 drivers/iio/adc/ad7091r-base.h |  1 +
 drivers/iio/adc/ad7091r5.c |  5 
 3 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
index 140413329754..d416f0912531 100644
--- a/drivers/iio/adc/ad7091r-base.c
+++ b/drivers/iio/adc/ad7091r-base.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define AD7091R_REG_RESULT  0
 #define AD7091R_REG_CHANNEL 1
@@ -42,6 +43,7 @@ enum ad7091r_mode {
 struct ad7091r_state {
struct device *dev;
struct regmap *map;
+   struct regulator *reg;
const struct ad7091r_chip_info *chip_info;
enum ad7091r_mode mode;
 };
@@ -139,6 +141,21 @@ static int ad7091r_read_raw(struct iio_dev *iio_dev,
ret = IIO_VAL_INT;
break;
 
+   case IIO_CHAN_INFO_SCALE:
+   if (st->reg) {
+   ret = regulator_get_voltage(st->reg);
+   if (ret < 0)
+   goto unlock;
+
+   *val = ret / 1000;
+   } else {
+   *val = st->chip_info->vref_mV;
+   }
+
+   *val2 = chan->scan_type.realbits;
+   ret = IIO_VAL_FRACTIONAL_LOG2;
+   break;
+
default:
ret = -EINVAL;
break;
@@ -215,6 +232,18 @@ int ad7091r_probe(struct device *dev, const char *name,
return ret;
}
 
+   st->reg = devm_regulator_get_optional(dev, "vref");
+   if (IS_ERR(st->reg)) {
+   if (PTR_ERR(st->reg) == EPROBE_DEFER)
+   return -EPROBE_DEFER;
+
+   st->reg = NULL;
+   } else {
+   ret = regulator_enable(st->reg);
+   if (ret)
+   return ret;
+   }
+
/* Use command mode by default */
ret = ad7091r_set_mode(st, AD7091R_MODE_COMMAND);
if (ret < 0)
@@ -222,18 +251,29 @@ int ad7091r_probe(struct device *dev, const char *name,
 
ret = iio_device_register(iio_dev);
if (ret)
-   return ret;
+   goto err_disable_reg;
 
dev_dbg(dev, "Probed\n");
return 0;
+
+err_disable_reg:
+   if (st->reg)
+   regulator_disable(st->reg);
+
+   return ret;
 }
 EXPORT_SYMBOL_GPL(ad7091r_probe);
 
 int ad7091r_remove(struct device *dev)
 {
struct iio_dev *iio_dev = dev_get_drvdata(dev);
+   struct ad7091r_state *st = iio_priv(iio_dev);
 
iio_device_unregister(iio_dev);
+
+   if (st->reg)
+   regulator_disable(st->reg);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(ad7091r_remove);
diff --git a/drivers/iio/adc/ad7091r-base.h b/drivers/iio/adc/ad7091r-base.h
index 7a29f86ea82b..cec4fb75fecc 100644
--- a/drivers/iio/adc/ad7091r-base.h
+++ b/drivers/iio/adc/ad7091r-base.h
@@ -18,6 +18,7 @@ struct ad7091r_state;
 struct ad7091r_chip_info {
unsigned int num_channels;
const struct iio_chan_spec *channels;
+   unsigned int vref_mV;
 };
 
 extern const struct regmap_config ad7091r_regmap_config;
diff --git a/drivers/iio/adc/ad7091r5.c b/drivers/iio/adc/ad7091r5.c
index 1ba838c58c31..65bcd8bb692a 100644
--- a/drivers/iio/adc/ad7091r5.c
+++ b/drivers/iio/adc/ad7091r5.c
@@ -35,10 +35,13 @@ static const struct iio_event_spec ad7091r5_events[] = {
 #define AD7091R_CHANNEL(idx, bits, ev, num_ev) { \
.type = IIO_VOLTAGE, \
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
+   .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE), \
.indexed = 1, \
.channel = idx, \
.event_spec = ev, \
.num_event_specs = num_ev, \
+   .scan_type.storagebits = 16, \
+   .scan_type.realbits = bits, \
 }
 static const struct iio_chan_spec ad7091r5_channels_irq[] = {
AD7091R_CHANNEL(0, 12, ad7091r5_events, ARRAY_SIZE(ad7091r5_events)),
@@ -58,11 +61,13 @@ static const struct iio_chan_spec ad7091r5_channels_noirq[] 
= {
 static const struct ad7091r_chip_info ad7091r5_chip_info_irq = {
.channels = ad7091r5_channels_irq,
.num_channels = ARRAY_SIZE(ad7091r5_channels_irq),
+   .vref_mV = 2500,
 };
 
 static const struct ad7091r_chip_info ad7091r5_chip_info_noirq = {
.channels = ad7091r5_channels_noirq,
.num_channels = ARRAY_SIZE(ad7091r5_channels_noirq),
+   .vref_mV = 2500,
 };
 
 static int ad7091r5_i2c_probe(struct 

[PATCH 3/4] dt-binding: iio: Add documentation for AD7091R5

[Beniamin Bia]

Documentation for AD7091R5 ADC was added.

Signed-off-by: Beniamin Bia 
---
 .../bindings/iio/adc/adi,ad7091r5.yaml| 53 +++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml

diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml 
b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
new file mode 100644
index ..d041cd76804e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/adc/adi,ad7091r5.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD7091R5 4-Channel 12-Bit ADC
+
+maintainers:
+  - Beniamin Bia 
+
+description: |
+  Analog Devices AD7091R5 4-Channel 12-Bit ADC
+  
https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf
+
+properties:
+  compatible:
+enum:
+  - adi,ad7091R5
+
+  reg:
+maxItems: 1
+
+  avcc-supply:
+description:
+  Phandle to the Avcc power supply
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+
+required:
+  - compatible
+  - reg
+
+examples:
+  - |
+#include 
+#include 
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+adc@0 {
+compatible = "adi,ad7091r5";
+reg = <0x2F>;
+
+interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+interrupt-parent = <>;
+};
+};
+...
-- 
2.17.1

[PATCH 1/4] iio: adc: Add support for AD7091R5 ADC

[Beniamin Bia]

From: Paul Cercueil 

AD7091 is 4-Channel, I2C, Ultra Low Power,12-Bit ADC.

Datasheet:
Link: 
https://www.analog.com/media/en/technical-documentation/data-sheets/ad7091r-5.pdf

Signed-off-by: Paul Cercueil 
Co-developed-by: Beniamin Bia 
Signed-off-by: Beniamin Bia 
---
 drivers/iio/adc/Kconfig|   7 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/ad7091r-base.c | 273 +
 drivers/iio/adc/ad7091r-base.h |  30 
 drivers/iio/adc/ad7091r5.c | 108 +
 5 files changed, 419 insertions(+)
 create mode 100644 drivers/iio/adc/ad7091r-base.c
 create mode 100644 drivers/iio/adc/ad7091r-base.h
 create mode 100644 drivers/iio/adc/ad7091r5.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 7e3286265a38..80b1b9551749 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -22,6 +22,13 @@ config AD7124
  To compile this driver as a module, choose M here: the module will be
  called ad7124.
 
+config AD7091R5
+   tristate "Analog Devices AD7091R5 ADC Driver"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ Say yes here to build support for Analog Devices AD7091R-5 ADC.
+
 config AD7266
tristate "Analog Devices AD7265/AD7266 ADC driver"
depends on SPI_MASTER
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index ef9cc485fb67..55e44735aaac 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -6,6 +6,7 @@
 # When adding new entries keep the list in alphabetical order
 obj-$(CONFIG_AD_SIGMA_DELTA) += ad_sigma_delta.o
 obj-$(CONFIG_AD7124) += ad7124.o
+obj-$(CONFIG_AD7091R5) += ad7091r5.o ad7091r-base.o
 obj-$(CONFIG_AD7266) += ad7266.o
 obj-$(CONFIG_AD7291) += ad7291.o
 obj-$(CONFIG_AD7298) += ad7298.o
diff --git a/drivers/iio/adc/ad7091r-base.c b/drivers/iio/adc/ad7091r-base.c
new file mode 100644
index ..140413329754
--- /dev/null
+++ b/drivers/iio/adc/ad7091r-base.c
@@ -0,0 +1,273 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AD7091RX Analog to Digital converter driver
+ *
+ * Copyright 2014 Analog Devices Inc.
+ *
+ */
+
+#include "ad7091r-base.h"
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AD7091R_REG_RESULT  0
+#define AD7091R_REG_CHANNEL 1
+#define AD7091R_REG_CONF2
+#define AD7091R_REG_ALERT   3
+#define AD7091R_REG_CH_LOW_LIMIT(ch) ((ch) * 3 + 4)
+#define AD7091R_REG_CH_HIGH_LIMIT(ch) ((ch) * 3 + 5)
+#define AD7091R_REG_CH_HYSTERESIS(ch) ((ch) * 3 + 6)
+
+/* AD7091R_REG_RESULT */
+#define REG_RESULT_CH_ID(x)(((x) >> 13) & 0x3)
+#define REG_RESULT_CONV_RESULT(x)   ((x) & 0xfff)
+
+/* AD7091R_REG_CONF */
+#define REG_CONF_AUTO   BIT(8)
+#define REG_CONF_CMDBIT(10)
+
+#define REG_CONF_MODE_MASK  (REG_CONF_AUTO | REG_CONF_CMD)
+
+enum ad7091r_mode {
+   AD7091R_MODE_SAMPLE,
+   AD7091R_MODE_COMMAND,
+   AD7091R_MODE_AUTOCYCLE,
+};
+
+struct ad7091r_state {
+   struct device *dev;
+   struct regmap *map;
+   const struct ad7091r_chip_info *chip_info;
+   enum ad7091r_mode mode;
+};
+
+static int ad7091r_set_mode(struct ad7091r_state *st, enum ad7091r_mode mode)
+{
+   int ret;
+
+   switch (mode) {
+   case AD7091R_MODE_SAMPLE:
+   ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
+   REG_CONF_MODE_MASK, 0);
+   break;
+   case AD7091R_MODE_COMMAND:
+   ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
+   REG_CONF_MODE_MASK, REG_CONF_CMD);
+   break;
+   case AD7091R_MODE_AUTOCYCLE:
+   ret = regmap_update_bits(st->map, AD7091R_REG_CONF,
+   REG_CONF_MODE_MASK, REG_CONF_AUTO);
+   break;
+   default:
+   ret = -EINVAL;
+   break;
+   }
+
+   if (!ret)
+   st->mode = mode;
+   return ret;
+}
+
+static int ad7091r_set_channel(struct ad7091r_state *st, unsigned int channel)
+{
+   unsigned int foo;
+   int ret;
+
+   /* AD7091R_REG_CHANNEL is a 8-bit register */
+   ret = regmap_write(st->map, AD7091R_REG_CHANNEL,
+   BIT(channel) | (BIT(channel) << 8));
+   if (ret)
+   return ret;
+
+   /*
+*  There is a latency of one conversion before the channel conversion
+* sequence is updated
+*/
+   return regmap_read(st->map, AD7091R_REG_RESULT, );
+}
+
+static int ad7091r_read_one(struct iio_dev *iio_dev,
+   unsigned int channel, unsigned int *read_val)
+{
+   struct ad7091r_state *st = iio_priv(iio_dev);
+   unsigned int val;
+   int ret;
+
+   /* TODO: locking */
+   ret = ad7091r_set_channel(st, channel);
+   if (ret)
+   return ret;
+
+   ret = regmap_read(st->map, AD7091R_REG_RESULT, );
+   if (ret)
+   return ret;
+
+   if (REG_RESULT_CH_ID(val) != channel)

[PATCH 4/4] MAINTAINERS: add entry for AD7091R5 driver

[Beniamin Bia]

Add Beniamin Bia as a maintainer for AD7091R5 ADC.

Signed-off-by: Beniamin Bia 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 2e01d0f0b0e5..7f1e4b88688f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -893,6 +893,14 @@ S: Supported
 F: drivers/iio/dac/ad5758.c
 F: Documentation/devicetree/bindings/iio/dac/ad5758.txt
 
+ANALOG DEVICES INC AD7091R5 DRIVER
+M: Beniamin Bia 
+L: linux-...@vger.kernel.org
+W: http://ez.analog.com/community/linux-device-drivers
+S: Supported
+F: drivers/iio/adc/ad7091r5.c
+F: Documentation/devicetree/bindings/iio/adc/adi,ad7091r5.yaml
+
 ANALOG DEVICES INC AD7124 DRIVER
 M: Stefan Popa 
 L: linux-...@vger.kernel.org
-- 
2.17.1

Re: [RFC PATCH v2 11/16] mm,hwpoison: Rework soft offline for in-use pages

[Michal Hocko]

On Mon 21-10-19 15:48:48, Oscar Salvador wrote:
> On Fri, Oct 18, 2019 at 02:39:01PM +0200, Michal Hocko wrote:
> > 
> > I am sorry but I got lost in the above description and I cannot really
> > make much sense from the code either. Let me try to outline the way how
> > I think about this.
> > 
> > Say we have a pfn to hwpoison. We have effectivelly three possibilities
> > - page is poisoned already - done nothing to do
> > - page is managed by the buddy allocator - excavate from there
> > - page is in use
> > 
> > The last category is the most interesting one. There are essentially
> > three classes of pages
> > - freeable
> > - migrateable
> > - others
> > 
> > We cannot do really much about the last one, right? Do we mark them
> > HWPoison anyway?
> 
> We can only perform actions on LRU/Movable pages or hugetlb pages.

What would prevent other pages mapped via page tables to be handled as
well?

> So unless the page does not fall into those areas, we do not do anything
> with them.
> 
> > Freeable should be simply marked HWPoison and freed.
> > For all those migrateable, we simply do migrate and mark HWPoison.
> > Now the main question is how to handle HWPoison page when it is freed
> > - aka last reference is dropped. The main question is whether the last
> > reference is ever dropped. If yes then the free_pages_prepare should
> > never release it to the allocator (some compound destructors would have
> > to special case as well, e.g. hugetlb would have to hand over to the
> > allocator rather than a pool). If not then the page would be lingering
> > potentially with some state bound to it (e.g. memcg charge).  So I
> > suspect you want the former.
> 
> For non-hugetlb pages, we do not call put_page in the migration path,
> but we do it in page_handle_poison, after the page has been flagged as
> hwpoison.
> Then the check in free_papes_prepare will see that the page is hwpoison
> and will bail out, so the page is not released into the allocator/pcp lists.
> 
> Hugetlb pages follow a different methodology.
> They are dissolved, and then we split the higher-order page and take the
> page off the buddy.
> The problem is that while it is easy to hold a non-hugetlb page,
> doing the same for hugetlb pages is not that easy:
> 
> 1) we would need to hook in enqueue_hugetlb_page so the page is not enqueued
>into hugetlb freelists
> 2) when trying to free a hugetlb page, we would need to do as we do for 
> gigantic
>pages now, and that is breaking down the pages into order-0 pages and 
> release
>them to the buddy (so the check in free_papges_prepare would skip the
>hwpoison page).
>Trying to handle a higher-order hwpoison page in free_pages_prepare is
>a bit complicated.

I am not sure I see the problem. If you dissolve the hugetlb page then
there is no hugetlb page anymore and so you make it a regular high-order
page.

> There is one thing I was unsure though.
> Bailing out at the beginning of free_pages_prepare if the page is hwpoison
> means that the calls to
> 
> - __memcg_kmem_uncharge
> - page_cpupid_reset_last
> - reset_page_owner
> - ...
> 
> will not be performed.
> I thought this is right because the page is not really "free", it is just 
> unusable,
> so.. it should be still charged to the memcg?

If the page is free then it shouldn't pin the memcg or any other state.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v5 0/9] i2c: add support for filters

[Wolfram Sang]

On Mon, Oct 07, 2019 at 07:53:21AM +, eugen.hris...@microchip.com wrote:
> 
> 
> On 11.09.2019 11:24, Eugen Hristev - M18282 wrote:
> > From: Eugen Hristev 
> > 
> > Hello,
> > 
> > This series adds support for analog and digital filters for i2c controllers
> > 
> > This series is based on the series:
> > [PATCH v2 0/9] i2c: at91: filters support for at91 SoCs
> > and later
> > [PATCH v4 0/9] i2c: add support for filters
> > and enhanced to add the bindings for all controllers plus an extra bindings
> > for the width of the spikes in nanoseconds (digital filters) and cut-off
> > frequency (analog filters)
> > 
> > First, bindings are created for
> > 'i2c-analog-filter'
> > 'i2c-digital-filter'
> > 'i2c-digital-filter-width-ns'
> > 'i2c-analog-filter-cutoff-frequency'
> > 
> > The support is added in the i2c core to retrieve filter width/cutoff 
> > frequency
> > and add it to the timings structure.
> > Next, the at91 driver is enhanced for supporting digital filter, advanced
> > digital filter (with selectable spike width) and the analog filter.
> > 
> > Finally the device tree for two boards are modified to make use of the
> > new properties.
> > 
> > This series is the result of the comments on the ML in the direction
> > requested: to make the bindings globally available for i2c drivers.
> > 
> > Changes in v5:
> > - renamed i2c-filter-width-ns to i2c-digital-filter-width-ns as this
> > is applicable only to digital filter
> > - created new binding i2c-digital-filter-width-ns for analog filters.
> 
> Hello Wolfram and Peter,
> 
> Are you happy with the changes in this version? I haven't heard from you 
> since this latest update.
> I am interested to know if anymore changes are required or maybe we can 
> move further with this support.

So, I had a look now and I am happy. I will give Peter one more day to
comment, otherwise I'll apply it tomorrow.

Thanks for your patience and keeping at it!



signature.asc
Description: PGP signature

Re: [PATCH 2/2] PCI: dwc: Add support to handle ZRX-DC Compliant PHYs

[Andrew Murray]

On Mon, Oct 21, 2019 at 05:59:53PM +0530, Anvesh Salveru wrote:
> Many platforms use DesignWare controller but the PHY can be different in
> different platforms. If the PHY is compliant is to ZRX-DC specification

s/is to/to the/

> it helps in low power consumption during power states.

s/in low/lower/

> 
> If current data rate is 8.0 GT/s or higher and PHY is not compliant to
> ZRX-DC specification, then after every 100ms link should transition to
> recovery state during the low power states.
> 
> DesignWare controller provides GEN3_ZRXDC_NONCOMPL field in
> GEN3_RELATED_OFF to specify about ZRX-DC compliant PHY.
> 
> Platforms with ZRX-DC compliant PHY can set "snps,phy-zrxdc-compliant"
> property in controller DT node to specify this property to the controller.
> 
> Signed-off-by: Anvesh Salveru 
> Signed-off-by: Pankaj Dubey 
> ---
>  drivers/pci/controller/dwc/pcie-designware.c | 7 +++
>  drivers/pci/controller/dwc/pcie-designware.h | 3 +++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
> b/drivers/pci/controller/dwc/pcie-designware.c
> index 820488dfeaed..6560d9f765d7 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.c
> +++ b/drivers/pci/controller/dwc/pcie-designware.c
> @@ -556,4 +556,11 @@ void dw_pcie_setup(struct dw_pcie *pci)
>  PCIE_PL_CHK_REG_CHK_REG_START;
>   dw_pcie_writel_dbi(pci, PCIE_PL_CHK_REG_CONTROL_STATUS, val);
>   }
> +
> + if (of_property_read_bool(np, "snps,phy-zrxdc-compliant")) {
> + val = dw_pcie_readl_dbi(pci, PCIE_PORT_GEN3_RELATED);
> + val &= ~PORT_LOGIC_GEN3_ZRXDC_NONCOMPL;
> + dw_pcie_writel_dbi(pci, PCIE_PORT_GEN3_RELATED, val);
> + }
> +

Given that this duplicates tegra_pcie_prepare_host in pcie-tegra194.c, can
we update that driver to adopt this new binding?

Thanks,

Andrew Murray

>  }
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 5a18e94e52c8..427a55ec43c6 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -60,6 +60,9 @@
>  #define PCIE_MSI_INTR0_MASK  0x82C
>  #define PCIE_MSI_INTR0_STATUS0x830
>  
> +#define PCIE_PORT_GEN3_RELATED   0x890
> +#define PORT_LOGIC_GEN3_ZRXDC_NONCOMPL   BIT(0)
> +
>  #define PCIE_ATU_VIEWPORT0x900
>  #define PCIE_ATU_REGION_INBOUND  BIT(31)
>  #define PCIE_ATU_REGION_OUTBOUND 0
> -- 
> 2.17.1
> 

Re: [PATCH v2 3/5] perf report: Sort by sampled cycles percent per block for stdio

[Jiri Olsa]

On Mon, Oct 21, 2019 at 02:56:57PM +0800, Jin, Yao wrote:

SNIP

> > > Does it seem like what the c2c does?
> > 
> > well c2c has its own data output with multiline column titles,
> > hence it has its own separate dimension stuff, but your code
> > output is within the standard perf report right? single column
> > output.. why couldn't you use just sort_entry ?
> > 
> > jirka
> > 
> 
> Hi Jiri,
> 
> I've being thinking how to use sort_entry but I have some troubles.
> 
> In v2, I used "struct perf_hpp_fmt" to pass extra argument. For example,
> 
> static int64_t block_cycles_cov_sort(struct perf_hpp_fmt *fmt,
>struct hist_entry *left,
>struct hist_entry *right)
> {
>   struct block_fmt *block_fmt = container_of(fmt, ...);
>   struct report *rep = block_fmt->rep;
>   ...
> }
> 
> But if I just use sort_entry, I can't pass extra argument (it's not a good
> idea to add more fields in struct hist_entry).
> 
> int64_t sort__xxx_sort(struct hist_entry *left,
>  struct hist_entry *right)
> 
> And for entry print it's similar, I can't pass extra argument in.
> 
> In v2,
> static int block_cycles_pct_entry(struct perf_hpp_fmt *fmt,
> struct perf_hpp *hpp,
> struct hist_entry *he)
> {
>   struct block_fmt *block_fmt = container_of(fmt,...);
>   struct report *rep = block_fmt->rep;
>   ...
> }
> 
> But for se_snprintf, I can't pass extra argument in.
> 
> hist_entry__xxx_snprintf(struct hist_entry *he, char *bf,
>size_t size, unsigned int width)
> 
> That's why I feel headache for just using the sort_entry. :(

you might be right, I just want to omit another field output framework ;-) 
I'm checking on this and will let you know if I find some way

jirka

Re: [PATCH v2 4/4] KVM: x86/vPMU: Add lazy mechanism to release perf_event per vPMC

[Like Xu]

Hi Paolo,

On 2019/10/21 16:45, Paolo Bonzini wrote:

On 13/10/19 11:15, Like Xu wrote:

Currently, a host perf_event is created for a vPMC functionality emulation.
It’s unpredictable to determine if a disabled perf_event will be reused.
If they are disabled and are not reused for a considerable period of time,
those obsolete perf_events would increase host context switch overhead that
could have been avoided.

If the guest doesn't access (set_msr/get_msr/rdpmc) any of the vPMC's MSRs
during an entire vcpu sched time slice, and its independent enable bit of
the vPMC isn't set, we can predict that the guest has finished the use of
this vPMC, and then it's time to release non-reused perf_events in the
first call of vcpu_enter_guest() after the vcpu gets next scheduled in.

This lazy mechanism delays the event release time to the beginning of the
next scheduled time slice if vPMC's MSRs aren't accessed during this time
slice. If guest comes back to use this vPMC in next time slice, a new perf
event would be re-created via perf_event_create_kernel_counter() as usual.

Suggested-by: Wei W Wang 
Signed-off-by: Like Xu 
---
  arch/x86/include/asm/kvm_host.h | 15 
  arch/x86/kvm/pmu.c  | 43 +
  arch/x86/kvm/pmu.h  |  3 +++
  arch/x86/kvm/pmu_amd.c  | 13 ++
  arch/x86/kvm/vmx/pmu_intel.c| 25 +++
  arch/x86/kvm/x86.c  | 12 +
  6 files changed, 111 insertions(+)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 1aae4953..45f9cdae150b 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -472,6 +472,21 @@ struct kvm_pmu {
struct kvm_pmc fixed_counters[INTEL_PMC_MAX_FIXED];
struct irq_work irq_work;
u64 reprogram_pmi;
+
+   /* for vPMC being set, do not released its perf_event (if any) */
+   u64 lazy_release_ctrl;


Please use DECLARE_BITMAP(lazy_release_ctrl, X86_PMC_IDX_MAX).  I would
also rename the bitmap to pmc_in_use.


Thanks for introducing BITMAP and I would definitely use it if I knew.



I know you're just copying what reprogram_pmi does, but that has to be
fixed too. :)  I'll send a patch now.


+   /*
+* The gate to release perf_events not marked in
+* lazy_release_ctrl only once in a vcpu time slice.
+*/
+   bool need_cleanup;
+
+   /*
+* The total number of programmed perf_events and it helps to avoid
+* redundant check before cleanup if guest don't use vPMU at all.
+*/
+   u8 event_count;
  };
  
  struct kvm_pmu_ops;

diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
index 09d1a03c057c..7ab262f009f6 100644
--- a/arch/x86/kvm/pmu.c
+++ b/arch/x86/kvm/pmu.c
@@ -137,6 +137,7 @@ static void pmc_reprogram_counter(struct kvm_pmc *pmc, u32 
type,
}
  
  	pmc->perf_event = event;

+   pmc_to_pmu(pmc)->event_count++;
clear_bit(pmc->idx, (unsigned long*)_to_pmu(pmc)->reprogram_pmi);
  }
  
@@ -368,6 +369,7 @@ int kvm_pmu_rdpmc(struct kvm_vcpu *vcpu, unsigned idx, u64 *data)

if (!pmc)
return 1;
  
+	__set_bit(pmc->idx, (unsigned long *)>lazy_release_ctrl);

*data = pmc_read_counter(pmc) & mask;
return 0;
  }
@@ -385,11 +387,13 @@ bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
  
  int kvm_pmu_get_msr(struct kvm_vcpu *vcpu, u32 msr, u64 *data)

  {
+   kvm_x86_ops->pmu_ops->update_lazy_release_ctrl(vcpu, msr);


Instead of this new pmu_ops entry, please introduce two separate patches
to do the following:

1) rename the existing msr_idx_to_pmc to rdpmc_idx_to_pmc, and
is_valid_msr_idx to is_valid_rdpmc_idx (likewise for
kvm_pmu_is_valid_msr_idx).


It looks good to me and I'll apply it.



2) introduce a new callback msr_idx_to_pmc that returns a struct
kvm_pmc*, and change kvm_pmu_is_valid_msr to do


For callback msr_idx_to_pmc,
how do we deal with the input 'MSR_CORE_PERF_FIXED_CTR_CTRL'
which may return several fixed kvm_pmcs not just one?



bool kvm_pmu_is_valid_msr(struct kvm_vcpu *vcpu, u32 msr)
{
 return (kvm_x86_ops->pmu_ops->msr_idx_to_pmc(vcpu, msr) ||
kvm_x86_ops->pmu_ops->is_valid_msr(vcpu, msr));
}

and AMD can just return false from .is_valid_msr.

Once this change is done, this patch can use simply:

static int kvm_pmu_mark_pmc_in_use(struct kvm_vcpu *vcpu, u32 msr)


s/static int/static void/.


{
struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
struct kvm_pmc *pmc = kvm_x86_ops->pmu_ops->msr_idx_to_pmc(vcpu, msr);


We need 'if(pmc)' here.


__set_bit(pmc->idx, pmu->pmc_in_use);
}


return kvm_x86_ops->pmu_ops->get_msr(vcpu, msr, data);
  }
  
  int kvm_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)

  {
+   kvm_x86_ops->pmu_ops->update_lazy_release_ctrl(vcpu, msr_info->index);
return kvm_x86_ops->pmu_ops->set_msr(vcpu, msr_info);
  }
  
@@ -417,9 +421,48 

Re: [PATCH 4/5] perf tools: Support single perf.data file directory

[Arnaldo Carvalho de Melo]

Em Mon, Oct 21, 2019 at 03:42:39PM +0300, Adrian Hunter escreveu:
> On 7/10/19 3:06 PM, Adrian Hunter wrote:
> > On 7/10/19 2:20 PM, Jiri Olsa wrote:
> >> On Fri, Oct 04, 2019 at 11:31:20AM +0300, Adrian Hunter wrote:
> >>
> >> SNIP
> >>
> >>>   u8 pad[8] = {0};
> >>>  
> >>> - if (!perf_data__is_pipe(data) && !perf_data__is_dir(data)) {
> >>> + if (!perf_data__is_pipe(data) && perf_data__is_single_file(data)) {
> >>>   off_t file_offset;
> >>>   int fd = perf_data__fd(data);
> >>>   int err;
> >>> diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
> >>> index df173f0bf654..964ea101dba6 100644
> >>> --- a/tools/perf/util/data.c
> >>> +++ b/tools/perf/util/data.c
> >>> @@ -76,6 +76,13 @@ int perf_data__open_dir(struct perf_data *data)
> >>>   DIR *dir;
> >>>   int nr = 0;
> >>>  
> >>> + /*
> >>> +  * Directory containing a single regular perf data file which is already
> >>> +  * open, means there is nothing more to do here.
> >>> +  */
> >>> + if (perf_data__is_single_file(data))
> >>> + return 0;
> >>> +
> >>
> >> cool, I like this approach much more than the previous flag
> > 
> > Yes it is much nicer.  Thanks for your direction on that.
> > 
> >>
> >> any change you (if there's repost) or Arnaldo
> >> could squeeze in indent change below?
> > 
> > Sent a patch, to be applied before these.
> > 
> 
> That is:
> 
> "[PATCH] perf session: Fix indent in perf_session__new()"

Done it as a separate patch, etc.
 
> Any comments on this patch set Arnaldo?

-- 

- Arnaldo

Re: [PATCH 1/3] mm, meminit: Recalculate pcpu batch and high limits after init completes

[Qian Cai]

> On Oct 21, 2019, at 5:48 AM, Mel Gorman  wrote:
> 
> Deferred memory initialisation updates zone->managed_pages during
> the initialisation phase but before that finishes, the per-cpu page
> allocator (pcpu) calculates the number of pages allocated/freed in
> batches as well as the maximum number of pages allowed on a per-cpu list.
> As zone->managed_pages is not up to date yet, the pcpu initialisation
> calculates inappropriately low batch and high values.
> 
> This increases zone lock contention quite severely in some cases with the
> degree of severity depending on how many CPUs share a local zone and the
> size of the zone. A private report indicated that kernel build times were
> excessive with extremely high system CPU usage. A perf profile indicated
> that a large chunk of time was lost on zone->lock contention.
> 
> This patch recalculates the pcpu batch and high values after deferred
> initialisation completes for every populated zone in the system. It
> was tested on a 2-socket AMD EPYC 2 machine using a kernel compilation
> workload -- allmodconfig and all available CPUs.
> 
> mmtests configuration: config-workload-kernbench-max
> Configuration was modified to build on a fresh XFS partition.
> 
> kernbench
>5.4.0-rc3  5.4.0-rc3
>  vanilla   resetpcpu-v2
> Amean user-25613249.50 (   0.00%)16401.31 * -23.79%*
> Amean syst-25614760.30 (   0.00%) 4448.39 *  69.86%*
> Amean elsp-256  162.42 (   0.00%)  119.13 *  26.65%*
> Stddevuser-256   42.97 (   0.00%)   19.15 (  55.43%)
> Stddevsyst-256  336.87 (   0.00%)6.71 (  98.01%)
> Stddevelsp-2562.46 (   0.00%)0.39 (  84.03%)
> 
>   5.4.0-rc35.4.0-rc3
> vanilla resetpcpu-v2
> Duration User   39766.24 49221.79
> Duration System 44298.10 13361.67
> Duration Elapsed  519.11   388.87
> 
> The patch reduces system CPU usage by 69.86% and total build time by
> 26.65%. The variance of system CPU usage is also much reduced.
> 
> Before, this was the breakdown of batch and high values over all zones was.
> 
>256   batch: 1
>256   batch: 63
>512   batch: 7
>256   high:  0
>256   high:  378
>512   high:  42
> 
> 512 pcpu pagesets had a batch limit of 7 and a high limit of 42. After the 
> patch
> 
>256   batch: 1
>768   batch: 63
>256   high:  0
>768   high:  378
> 
> Cc: sta...@vger.kernel.org # v4.1+
> Signed-off-by: Mel Gorman 
> ---
> mm/page_alloc.c | 8 
> 1 file changed, 8 insertions(+)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c0b2e0306720..f972076d0f6b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1947,6 +1947,14 @@ void __init page_alloc_init_late(void)
>   /* Block until all are initialised */
>   wait_for_completion(_init_all_done_comp);
> 
> + /*
> +  * The number of managed pages has changed due to the initialisation
> +  * so the pcpu batch and high limits needs to be updated or the limits
> +  * will be artificially small.
> +  */
> + for_each_populated_zone(zone)
> + zone_pcp_update(zone);
> +
>   /*
>* We initialized the rest of the deferred pages.  Permanently disable
>* on-demand struct page initialization.
> -- 
> 2.16.4
> 
> 

Warnings from linux-next,

[   14.265911][  T659] BUG: sleeping function called from invalid context at 
kernel/locking/mutex.c:935
[   14.265992][  T659] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 
659, name: pgdatinit8
[   14.266044][  T659] 1 lock held by pgdatinit8/659:
[   14.266075][  T659]  #0: c000201ffca87b40 
(&(>node_size_lock)->rlock){}, at: deferred_init_memmap+0xc4/0x26c
[   14.266160][  T659] irq event stamp: 26
[   14.266194][  T659] hardirqs last  enabled at (25): [] 
_raw_spin_unlock_irq+0x44/0x80
[   14.266246][  T659] hardirqs last disabled at (26): [] 
_raw_spin_lock_irqsave+0x3c/0xa0
[   14.266299][  T659] softirqs last  enabled at (0): [] 
copy_process+0x720/0x19b0
[   14.266339][  T659] softirqs last disabled at (0): [<>] 0x0
[   14.266400][  T659] CPU: 64 PID: 659 Comm: pgdatinit8 Not tainted 
5.4.0-rc4-next-20191021 #1
[   14.266462][  T659] Call Trace:
[   14.266494][  T659] [c0003d8efae0] [c0921cf4] 
dump_stack+0xe8/0x164 (unreliable)
[   14.266538][  T659] [c0003d8efb30] [c0157c54] 
___might_sleep+0x334/0x370
[   14.266577][  T659] [c0003d8efbb0] [c09

[PATCH] dt-bindings: i2c: meson: convert to yaml

[Neil Armstrong]

Now that we have the DT validation in place, let's convert the device tree
bindings for the Amlogic I2C Controller over to YAML schemas.

Cc: Beniamino Galvani 
Signed-off-by: Neil Armstrong 
---
 .../bindings/i2c/amlogic,meson6-i2c.yaml  | 53 +++
 .../devicetree/bindings/i2c/i2c-meson.txt | 30 ---
 2 files changed, 53 insertions(+), 30 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
 delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-meson.txt

diff --git a/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml 
b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
new file mode 100644
index ..49cad273c8e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/amlogic,meson6-i2c.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright 2019 BayLibre, SAS
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/i2c/amlogic,meson6-i2c.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Amlogic Meson I2C Controller
+
+maintainers:
+  - Neil Armstrong 
+  - Beniamino Galvani 
+
+allOf:
+  - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+  compatible:
+enum:
+  - amlogic,meson6-i2c # Meson6, Meson8 and compatible SoCs
+  - amlogic,meson-gxbb-i2c # GXBB and compatible SoCs
+  - amlogic,meson-axg-i2c # AXG and compatible SoCs
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+minItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+examples:
+  - |
+i2c@c8100500 {
+compatible = "amlogic,meson6-i2c";
+reg = <0xc8100500 0x20>;
+interrupts = <92>;
+clocks = <>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+eeprom@52 {
+compatible = "atmel,24c32";
+reg = <0x52>;
+};
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-meson.txt 
b/Documentation/devicetree/bindings/i2c/i2c-meson.txt
deleted file mode 100644
index 13d410de077c..
--- a/Documentation/devicetree/bindings/i2c/i2c-meson.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-Amlogic Meson I2C controller
-
-Required properties:
- - compatible: must be:
-   "amlogic,meson6-i2c" for Meson8 and compatible SoCs
-   "amlogic,meson-gxbb-i2c" for GXBB and compatible SoCs
-   "amlogic,meson-axg-i2c"for AXG and compatible SoCs
-
- - reg: physical address and length of the device registers
- - interrupts: a single interrupt specifier
- - clocks: clock for the device
- - #address-cells: should be <1>
- - #size-cells: should be <0>
-
-For details regarding the following core I2C bindings see also i2c.txt.
-
-Optional properties:
-- clock-frequency: the desired I2C bus clock frequency in Hz; in
-  absence of this property the default value is used (100 kHz).
-
-Examples:
-
-   i2c@c8100500 {
-   compatible = "amlogic,meson6-i2c";
-   reg = <0xc8100500 0x20>;
-   interrupts = <0 92 1>;
-   clocks = <>;
-   #address-cells = <1>;
-   #size-cells = <0>;
-   };
-- 
2.22.0

Re: [PATCH] i2c: i2c-stm32f7: fix first byte to send in slave mode

[Wolfram Sang]

On Mon, Sep 30, 2019 at 05:28:01PM +0200, Fabrice Gasnier wrote:
> The slave-interface documentation [1] states "the bus driver should
> transmit the first byte" upon I2C_SLAVE_READ_REQUESTED slave event:
> - 'val': backend returns first byte to be sent
> The driver currently ignores the 1st byte to send on this event.
> 
> Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support")
> 
> [1] https://www.kernel.org/doc/Documentation/i2c/slave-interface
> 
> Signed-off-by: Fabrice Gasnier 

Applied to for-current, thanks!



signature.asc
Description: PGP signature

Re: [PATCH] i2c: i2c-stm32f7: fix a race in slave mode with arbitration loss irq

[Wolfram Sang]

On Tue, Oct 01, 2019 at 10:51:09AM +0200, Fabrice Gasnier wrote:
> When in slave mode, an arbitration loss (ARLO) may be detected before the
> slave had a chance to detect the stop condition (STOPF in ISR).
> This is seen when two master + slave adapters switch their roles. It
> provokes the i2c bus to be stuck, busy as SCL line is stretched.
> - the I2C_SLAVE_STOP event is never generated due to STOPF flag is set but
>   don't generate an irq (race with ARLO irq, STOPIE is masked). STOPF flag
>   remains set until next master xfer (e.g. when STOPIE irq get unmasked).
>   In this case, completion is generated too early: immediately upon new
>   transfer request (then it doesn't send all data).
> - Some data get stuck in TXDR register. As a consequence, the controller
>   stretches the SCL line: the bus gets busy until a future master transfer
>   triggers the bus busy / recovery mechanism (this can take time... and
>   may never happen at all)
> 
> So choice is to let the STOPF being detected by the slave isr handler,
> to properly handle this stop condition. E.g. don't mask IRQs in error
> handler, when the slave is running.
> 
> Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support")
> 
> Signed-off-by: Fabrice Gasnier 

Applied to for-current, thanks!



signature.asc
Description: PGP signature

[PATCH RESEND v4 1/3] mfd: wm8998: Remove some unused registers

[Charles Keepax]

Save a few bytes by removing some registers from the driver that are not
currently used and not intended to be used at any point in the future.

Signed-off-by: Charles Keepax 
---
 drivers/mfd/wm8998-tables.c   | 12 
 include/linux/mfd/arizona/registers.h |  7 ---
 2 files changed, 19 deletions(-)

diff --git a/drivers/mfd/wm8998-tables.c b/drivers/mfd/wm8998-tables.c
index ebf0eadd2075c..9b34a6d760949 100644
--- a/drivers/mfd/wm8998-tables.c
+++ b/drivers/mfd/wm8998-tables.c
@@ -806,12 +806,6 @@ static const struct reg_default wm8998_reg_default[] = {
{ 0x0EF3, 0x },/* R3827  - ISRC 2 CTRL 1 */
{ 0x0EF4, 0x0001 },/* R3828  - ISRC 2 CTRL 2 */
{ 0x0EF5, 0x },/* R3829  - ISRC 2 CTRL 3 */
-   { 0x1700, 0x },/* R5888  - FRF_COEFF_1 */
-   { 0x1701, 0x },/* R5889  - FRF_COEFF_2 */
-   { 0x1702, 0x },/* R5890  - FRF_COEFF_3 */
-   { 0x1703, 0x },/* R5891  - FRF_COEFF_4 */
-   { 0x1704, 0x },/* R5892  - DAC_COMP_1 */
-   { 0x1705, 0x },/* R5893  - DAC_COMP_2 */
 };
 
 static bool wm8998_readable_register(struct device *dev, unsigned int reg)
@@ -1492,12 +1486,6 @@ static bool wm8998_readable_register(struct device *dev, 
unsigned int reg)
case ARIZONA_ISRC_2_CTRL_1:
case ARIZONA_ISRC_2_CTRL_2:
case ARIZONA_ISRC_2_CTRL_3:
-   case ARIZONA_FRF_COEFF_1:
-   case ARIZONA_FRF_COEFF_2:
-   case ARIZONA_FRF_COEFF_3:
-   case ARIZONA_FRF_COEFF_4:
-   case ARIZONA_V2_DAC_COMP_1:
-   case ARIZONA_V2_DAC_COMP_2:
return true;
default:
return false;
diff --git a/include/linux/mfd/arizona/registers.h 
b/include/linux/mfd/arizona/registers.h
index bb1a2530ae279..49e24d1de8d47 100644
--- a/include/linux/mfd/arizona/registers.h
+++ b/include/linux/mfd/arizona/registers.h
@@ -1186,13 +1186,6 @@
 #define ARIZONA_DSP4_SCRATCH_1   0x1441
 #define ARIZONA_DSP4_SCRATCH_2   0x1442
 #define ARIZONA_DSP4_SCRATCH_3   0x1443
-#define ARIZONA_FRF_COEFF_1  0x1700
-#define ARIZONA_FRF_COEFF_2  0x1701
-#define ARIZONA_FRF_COEFF_3  0x1702
-#define ARIZONA_FRF_COEFF_4  0x1703
-#define ARIZONA_V2_DAC_COMP_10x1704
-#define ARIZONA_V2_DAC_COMP_20x1705
-
 
 /*
  * Field Definitions.
-- 
2.11.0

[PATCH RESEND v4 2/3] mfd: madera: Update DT binding document to support clock supplies

[Charles Keepax]

Add the 3 input clock sources for the chip into the device tree binding
document.

Reviewed-by: Rob Herring 
Signed-off-by: Charles Keepax 
---
 Documentation/devicetree/bindings/mfd/madera.txt | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/madera.txt 
b/Documentation/devicetree/bindings/mfd/madera.txt
index cad0f28005027..47e2b8bc60519 100644
--- a/Documentation/devicetree/bindings/mfd/madera.txt
+++ b/Documentation/devicetree/bindings/mfd/madera.txt
@@ -67,6 +67,14 @@ Optional properties:
 As defined in bindings/gpio.txt.
 Although optional, it is strongly recommended to use a hardware reset
 
+  - clocks: Should reference the clocks supplied on MCLK1, MCLK2 and MCLK3
+  - clock-names: May contain up to three strings:
+  "mclk1" for the clock supplied on MCLK1, recommended to be a high
+  quality audio reference clock
+  "mclk2" for the clock supplied on MCLK2, required to be an always on
+  32k clock
+  "mclk3" for the clock supplied on MCLK3
+
   - MICBIASx : Initial data for the MICBIAS regulators, as covered in
 Documentation/devicetree/bindings/regulator/regulator.txt.
 One for each MICBIAS generator (MICBIAS1, MICBIAS2, ...)
-- 
2.11.0

[PATCH RESEND v4 3/3] mfd: madera: Add support for requesting the supply clocks

[Charles Keepax]

Add the ability to get the clock for each clock input pin of the chip
and enable MCLK2 since that is expected to be a permanently enabled
32kHz clock.

Signed-off-by: Charles Keepax 
---
 drivers/mfd/madera-core.c   | 27 ++-
 include/linux/mfd/madera/core.h | 11 +++
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
index 29540cbf75934..a8cfadc1fc01e 100644
--- a/drivers/mfd/madera-core.c
+++ b/drivers/mfd/madera-core.c
@@ -450,6 +450,21 @@ int madera_dev_init(struct madera *madera)
   sizeof(madera->pdata));
}
 
+   madera->mclk[MADERA_MCLK1].id = "mclk1";
+   madera->mclk[MADERA_MCLK2].id = "mclk2";
+   madera->mclk[MADERA_MCLK3].id = "mclk3";
+
+   ret = devm_clk_bulk_get_optional(madera->dev, ARRAY_SIZE(madera->mclk),
+madera->mclk);
+   if (ret) {
+   dev_err(madera->dev, "Failed to get clocks: %d\n", ret);
+   return ret;
+   }
+
+   /* Not using devm_clk_get to prevent breakage of existing DTs */
+   if (!madera->mclk[MADERA_MCLK2].clk)
+   dev_warn(madera->dev, "Missing MCLK2, requires 32kHz clock\n");
+
ret = madera_get_reset_gpio(madera);
if (ret)
return ret;
@@ -660,13 +675,19 @@ int madera_dev_init(struct madera *madera)
}
 
/* Init 32k clock sourced from MCLK2 */
+   ret = clk_prepare_enable(madera->mclk[MADERA_MCLK2].clk);
+   if (ret) {
+   dev_err(madera->dev, "Failed to enable 32k clock: %d\n", ret);
+   goto err_reset;
+   }
+
ret = regmap_update_bits(madera->regmap,
MADERA_CLOCK_32K_1,
MADERA_CLK_32K_ENA_MASK | MADERA_CLK_32K_SRC_MASK,
MADERA_CLK_32K_ENA | MADERA_32KZ_MCLK2);
if (ret) {
dev_err(madera->dev, "Failed to init 32k clock: %d\n", ret);
-   goto err_reset;
+   goto err_clock;
}
 
pm_runtime_set_active(madera->dev);
@@ -687,6 +708,8 @@ int madera_dev_init(struct madera *madera)
 
 err_pm_runtime:
pm_runtime_disable(madera->dev);
+err_clock:
+   clk_disable_unprepare(madera->mclk[MADERA_MCLK2].clk);
 err_reset:
madera_enable_hard_reset(madera);
regulator_disable(madera->dcvdd);
@@ -713,6 +736,8 @@ int madera_dev_exit(struct madera *madera)
 */
pm_runtime_disable(madera->dev);
 
+   clk_disable_unprepare(madera->mclk[MADERA_MCLK2].clk);
+
regulator_disable(madera->dcvdd);
regulator_put(madera->dcvdd);
 
diff --git a/include/linux/mfd/madera/core.h b/include/linux/mfd/madera/core.h
index 7ffa696cce7ca..ad2c138105d4b 100644
--- a/include/linux/mfd/madera/core.h
+++ b/include/linux/mfd/madera/core.h
@@ -8,6 +8,7 @@
 #ifndef MADERA_CORE_H
 #define MADERA_CORE_H
 
+#include 
 #include 
 #include 
 #include 
@@ -29,6 +30,13 @@ enum madera_type {
CS42L92 = 9,
 };
 
+enum {
+   MADERA_MCLK1,
+   MADERA_MCLK2,
+   MADERA_MCLK3,
+   MADERA_NUM_MCLK
+};
+
 #define MADERA_MAX_CORE_SUPPLIES   2
 #define MADERA_MAX_GPIOS   40
 
@@ -155,6 +163,7 @@ struct snd_soc_dapm_context;
  * @irq_dev:   the irqchip child driver device
  * @irq_data:  pointer to irqchip data for the child irqchip driver
  * @irq:   host irq number from SPI or I2C configuration
+ * @mclk:  Structure holding clock supplies
  * @out_clamp: indicates output clamp state for each analogue output
  * @out_shorted:   indicates short circuit state for each analogue output
  * @hp_ena:bitflags of enable state for the headphone outputs
@@ -184,6 +193,8 @@ struct madera {
struct regmap_irq_chip_data *irq_data;
int irq;
 
+   struct clk_bulk_data mclk[MADERA_NUM_MCLK];
+
unsigned int num_micbias;
unsigned int num_childbias[MADERA_MAX_MICBIAS];
 
-- 
2.11.0

Re: [PATCH v3] usb: Add a new quirk to let buggy hub enable and disable LPM during suspend and resume

[Mathias Nyman]

On 18.10.2019 21.59, Greg Kroah-Hartman wrote:

On Thu, Oct 17, 2019 at 02:33:00PM +0800, Kai-Heng Feng wrote:




On Oct 4, 2019, at 03:04, Alan Stern  wrote:

On Fri, 4 Oct 2019, Kai-Heng Feng wrote:


Dell WD15 dock has a topology like this:
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 1M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/7p, 5000M
|__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=r8152, 
5000M

Their IDs:
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 002: ID 0424:5537 Standard Microsystems Corp.
Bus 004 Device 004: ID 0bda:8153 Realtek Semiconductor Corp.

Ethernet cannot be detected after plugging ethernet cable to the dock,
the hub and roothub get runtime resumed and runtime suspended
immediately:
...
[  433.315169] xhci_hcd :3a:00.0: hcd_pci_runtime_resume: 0
[  433.315204] usb usb4: usb auto-resume
[  433.315226] hub 4-0:1.0: hub_resume
[  433.315239] xhci_hcd :3a:00.0: Get port status 4-1 read: 0x10202e2, 
return 0x10343
[  433.315264] usb usb4-port1: status 0343 change 0001
[  433.315279] xhci_hcd :3a:00.0: clear port1 connect change, portsc: 
0x10002e2
[  433.315293] xhci_hcd :3a:00.0: Get port status 4-2 read: 0x2a0, return 
0x2a0
[  433.317012] xhci_hcd :3a:00.0: xhci_hub_status_data: stopping port 
polling.
[  433.422282] xhci_hcd :3a:00.0: Get port status 4-1 read: 0x10002e2, 
return 0x343

At this point the SMSC hub (usb 4-1) enters into compliance mode
(USB_SS_PORT_LS_COMP_MOD), and USB core tries to warm-reset it,

[  433.422307] usb usb4-port1: do warm reset
[  433.422311] usb 4-1: device reset not allowed in state 8
[  433.422339] hub 4-0:1.0: state 7 ports 2 chg 0002 evt 
[  433.422346] xhci_hcd :3a:00.0: Get port status 4-1 read: 0x10002e2, 
return 0x343
[  433.422356] usb usb4-port1: do warm reset
[  433.422358] usb 4-1: device reset not allowed in state 8
[  433.422428] xhci_hcd :3a:00.0: set port remote wake mask, actual port 0 
status  = 0xf0002e2
[  433.422455] xhci_hcd :3a:00.0: set port remote wake mask, actual port 1 
status  = 0xe0002a0
[  433.422465] hub 4-0:1.0: hub_suspend
[  433.422475] usb usb4: bus auto-suspend, wakeup 1
[  433.426161] xhci_hcd :3a:00.0: xhci_hub_status_data: stopping port 
polling.
[  433.466209] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.510204] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.554051] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.598235] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.642154] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.686204] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.730205] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.774203] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.818207] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.862040] xhci_hcd :3a:00.0: port 0 polling in bus suspend, waiting
[  433.862053] xhci_hcd :3a:00.0: xhci_hub_status_data: stopping port 
polling.
[  433.862077] xhci_hcd :3a:00.0: xhci_suspend: stopping port polling.
[  433.862096] xhci_hcd :3a:00.0: // Setting command ring address to 
0x8578fc001
[  433.862312] xhci_hcd :3a:00.0: hcd_pci_runtime_suspend: 0
[  433.862445] xhci_hcd :3a:00.0: PME# enabled
[  433.902376] xhci_hcd :3a:00.0: restoring config space at offset 0xc (was 
0x0, writing 0x20)
[  433.902395] xhci_hcd :3a:00.0: restoring config space at offset 0x4 (was 
0x10, writing 0x100403)
[  433.902490] xhci_hcd :3a:00.0: PME# disabled
[  433.902504] xhci_hcd :3a:00.0: enabling bus mastering
[  433.902547] xhci_hcd :3a:00.0: // Setting command ring address to 
0x8578fc001
[  433.902649] pcieport :00:1b.0: PME: Spurious native interrupt!
[  433.902839] xhci_hcd :3a:00.0: Port change event, 4-1, id 3, portsc: 
0xb0202e2
[  433.902842] xhci_hcd :3a:00.0: resume root hub
[  433.902845] xhci_hcd :3a:00.0: handle_port_status: starting port polling.
[  433.902877] xhci_hcd :3a:00.0: xhci_resume: starting port polling.
[  433.902889] xhci_hcd :3a:00.0: xhci_hub_status_data: stopping port 
polling.
[  433.902891] xhci_hcd :3a:00.0: hcd_pci_runtime_resume: 0
[  433.902919] usb usb4: usb wakeup-resume
[  433.902942] usb usb4: usb auto-resume
[  433.902966] hub 4-0:1.0: hub_resume
...

However the warm-reset never success, the asserted PCI PME keeps the
runtime-resume, warm-reset and runtime-suspend loop which never bring it back
and causing spurious interrupts floods.

After some trial and errors, the issue goes away if LPM on the SMSC hub
is disabled. Digging further, enabling and disabling LPM during runtime
resume and runtime suspend respectively can solve the issue.

So bring back the old LPM behavior as a quirk and use it for the SMSC
hub to solve the issue.

Fixes: 

Re: [PATCH -next RESEND] Documentation/admin-guide: fix sysctl Sphinx warning

[Dmitry Safonov]

Hi Randy,

On 10/21/19 3:44 AM, Randy Dunlap wrote:
> From: Randy Dunlap 
> 
> Fix Sphinx warning when building Documentation:
> 
> Documentation/admin-guide/sysctl/kernel.rst:397: WARNING: Title underline too 
> short.
> 
> hung_task_interval_warnings:
> ===

Thanks for the patch!

I'm in process of reworking the patch in akpm according to reviews,
I will incorporate your change in next version.

> 
> Signed-off-by: Randy Dunlap 
> Cc: Dmitry Safonov 
> Cc: Andrew Morton 
> Cc: Ingo Molnar 
> ---
>  Documentation/admin-guide/sysctl/kernel.rst |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-next-20191018.orig/Documentation/admin-guide/sysctl/kernel.rst
> +++ linux-next-20191018/Documentation/admin-guide/sysctl/kernel.rst
> @@ -394,7 +394,7 @@ This file shows up if CONFIG_DETECT_HUNG
>  
>  
>  hung_task_interval_warnings:
> -===
> +
>  
>  The same as hung_task_warnings, but set the number of interval
>  warnings to be issued about detected hung tasks during check
> 
> 

Thanks,
  Dmitry

Re: [PATCH v4 15/16] module: Move where we mark modules RO,X

[Josh Poimboeuf]

On Fri, Oct 18, 2019 at 09:35:40AM +0200, Peter Zijlstra wrote:
> Now that set_all_modules_text_*() is gone, nothing depends on the
> relation between ->state = COMING and the protection state anymore.
> This enables moving the protection changes later, such that the COMING
> notifier callbacks can more easily modify the text.
> 
> Signed-off-by: Peter Zijlstra (Intel) 
> Cc: Jessica Yu 
> ---
>  kernel/module.c |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3683,10 +3683,6 @@ static int complete_formation(struct mod
>   /* This relies on module_mutex for list integrity. */
>   module_bug_finalize(info->hdr, info->sechdrs, mod);
>  
> - module_enable_ro(mod, false);
> - module_enable_nx(mod);
> - module_enable_x(mod);
> -
>   /* Mark state as coming so strong_try_module_get() ignores us,
>* but kallsyms etc. can see us. */
>   mod->state = MODULE_STATE_COMING;
> @@ -3852,6 +3848,10 @@ static int load_module(struct load_info
>   if (err)
>   goto bug_cleanup;
>  
> + module_enable_ro(mod, false);
> + module_enable_nx(mod);
> + module_enable_x(mod);
> +
>   /* Module is ready to execute: parsing args may do that. */
>   after_dashes = parse_args(mod->name, mod->args, mod->kp, mod->num_kp,
> -32768, 32767, mod,

[ Sorry if this was already discussed, I still have a large backlog. ]

Doesn't livepatch code also need to be modified?  We have:

prepare_coming_module()
klp_module_coming()
klp_init_object_loaded()
module_disable_ro()
...
module_enable_ro()

which is done right before the above patch does module_enable_ro().

We could remove the disable-RO from that case, though we'd still need it
for another case (late module patching).

-- 
Josh

Re: [PATCH RFC 1/3] kcov: remote coverage support

[Dmitry Vyukov]

On Thu, Oct 17, 2019 at 7:44 PM Andrey Konovalov  wrote:
>
> Currently kcov can only collect coverage for syscalls that are issued
> from the current process. This patch adds support for KCOV_REMOTE_ENABLE,
> that makes it possible to collect coverage for arbitrary parts of the
> kernel code, provided that this part is annotated with kcov_remote_start
> and kcov_remote_stop.

Nitpick: () after function names is the common C style.

> This allows to collect coverage from two types of kernel background
> threads: the global ones, that are spawned during kernel boot and are
> always running (e.g. USB hub_event); and the local ones, that are spawned
> when a user interacts with some kernel interfaces (e.g. vhost).
>
> To enable collecting coverage from a global background thread, a unique
> global id must be assigned and passed to the corresponding
> kcov_remote_start annotation call. Then a userspace process can pass this
> id to the KCOV_REMOTE_ENABLE ioctl in the handles array field of the
> kcov_remote_arg struct. This will attach kcov device to the code section,
> that is referenced by this id. Multiple ids can be targeted with the same
> kcov device simultaneously.
>
> Since there might be many local background threads spawned from different
> userspace processes, we can't use a single global id per annotation.
> Instead, the userspace process passes an id through the common_handle
> field of the kcov_remote_arg struct. This id gets saved to the kcov_handle
> field in the current task_struct and needs to be passed to the newly
> spawned threads via custom annotations. Those threads should be in turn
> annotated with kcov_remote_start/kcov_remote_stop.
>
> Signed-off-by: Andrey Konovalov 
> ---
>  Documentation/dev-tools/kcov.rst |  99 +++
>  include/linux/kcov.h |   9 +
>  include/linux/sched.h|   6 +
>  include/uapi/linux/kcov.h|  11 +
>  kernel/kcov.c| 434 ---
>  5 files changed, 524 insertions(+), 35 deletions(-)
>
> diff --git a/Documentation/dev-tools/kcov.rst 
> b/Documentation/dev-tools/kcov.rst
> index 42b612677799..1cf0af95a801 100644
> --- a/Documentation/dev-tools/kcov.rst
> +++ b/Documentation/dev-tools/kcov.rst
> @@ -34,6 +34,7 @@ Profiling data will only become accessible once debugfs has 
> been mounted::
>
>  Coverage collection
>  ---
> +
>  The following program demonstrates coverage collection from within a test
>  program using kcov:
>
> @@ -128,6 +129,7 @@ only need to enable coverage (disable happens 
> automatically on thread end).
>
>  Comparison operands collection
>  --
> +
>  Comparison operands collection is similar to coverage collection:
>
>  .. code-block:: c
> @@ -202,3 +204,100 @@ Comparison operands collection is similar to coverage 
> collection:
>
>  Note that the kcov modes (coverage collection or comparison operands) are
>  mutually exclusive.
> +
> +Remote coverage collection
> +--
> +
> +With KCOV_ENABLE coverage is collected only for syscalls that are issued from
> +the current process. With KCOV_REMOTE_ENABLE it's possible to collect 
> coverage
> +for arbitrary parts of the kernel code, provided that this part is annotated
> +with kcov_remote_start/kcov_remote_stop.

Same here.

> +This allows to collect coverage from two types of kernel background threads:
> +the global ones, that are spawned during kernel boot and are always running
> +(e.g. USB hub_event); and the local ones, that are spawned when a user
> +interacts with some kernel interfaces (e.g. vhost).
> +
> +To enable collecting coverage from a global background thread, a unique 
> global
> +id must be assigned and passed to the corresponding kcov_remote_start 
> annotation
> +call. Then a userspace process can pass this id to the KCOV_REMOTE_ENABLE 
> ioctl
> +in the handles array field of the kcov_remote_arg struct. This will attach 
> kcov
> +device to the code section, that is referenced by this id. Multiple ids can 
> be
> +targeted with the same kcov device simultaneously.
> +
> +Since there might be many local background threads spawned from different
> +userspace processes, we can't use a single global id per annotation. Instead,
> +the userspace process passes an id through the common_handle field of the
> +kcov_remote_arg struct. This id gets saved to the kcov_handle field in the
> +current task_struct and needs to be passed to the newly spawned threads via
> +custom annotations. Those threads should be in turn annotated with
> +kcov_remote_start/kcov_remote_stop.
> +
> +.. code-block:: c
> +
> +struct kcov_remote_arg {
> +   unsignedtrace_mode;
> +   unsignedarea_size;
> +   unsignednum_handles;
> +   uint64_tcommon_handle;
> +   uint64_thandles[0];
> +};
> +
> +#define KCOV_REMOTE_MAX_HANDLES0x1

This is unused. I would remove it. I assume you just 

Re: [PATCH 4/5] perf tools: Support single perf.data file directory

[Jiri Olsa]

On Mon, Oct 21, 2019 at 10:46:11AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Oct 21, 2019 at 03:42:39PM +0300, Adrian Hunter escreveu:
> > On 7/10/19 3:06 PM, Adrian Hunter wrote:
> > > On 7/10/19 2:20 PM, Jiri Olsa wrote:
> > >> On Fri, Oct 04, 2019 at 11:31:20AM +0300, Adrian Hunter wrote:
> > >>
> > >> SNIP
> > >>
> > >>> u8 pad[8] = {0};
> > >>>  
> > >>> -   if (!perf_data__is_pipe(data) && !perf_data__is_dir(data)) {
> > >>> +   if (!perf_data__is_pipe(data) && 
> > >>> perf_data__is_single_file(data)) {
> > >>> off_t file_offset;
> > >>> int fd = perf_data__fd(data);
> > >>> int err;
> > >>> diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
> > >>> index df173f0bf654..964ea101dba6 100644
> > >>> --- a/tools/perf/util/data.c
> > >>> +++ b/tools/perf/util/data.c
> > >>> @@ -76,6 +76,13 @@ int perf_data__open_dir(struct perf_data *data)
> > >>> DIR *dir;
> > >>> int nr = 0;
> > >>>  
> > >>> +   /*
> > >>> +* Directory containing a single regular perf data file which 
> > >>> is already
> > >>> +* open, means there is nothing more to do here.
> > >>> +*/
> > >>> +   if (perf_data__is_single_file(data))
> > >>> +   return 0;
> > >>> +
> > >>
> > >> cool, I like this approach much more than the previous flag
> > > 
> > > Yes it is much nicer.  Thanks for your direction on that.
> > > 
> > >>
> > >> any change you (if there's repost) or Arnaldo
> > >> could squeeze in indent change below?
> > > 
> > > Sent a patch, to be applied before these.
> > > 
> > 
> > That is:
> > 
> > "[PATCH] perf session: Fix indent in perf_session__new()"
> > 
> > Any comments on this patch set Arnaldo?
> 
> I'll take a look at it later, I think Jiri is ok with it already?

yes, it's just indent fix

jirka

Re: [PATCH] seccomp: fix SECCOMP_USER_NOTIF_FLAG_CONTINUE test

[Tycho Andersen]

On Mon, Oct 21, 2019 at 11:10:55AM +0200, Christian Brauner wrote:
> The ifndef for SECCOMP_USER_NOTIF_FLAG_CONTINUE was placed under the
> ifndef for the SECCOMP_FILTER_FLAG_NEW_LISTENER feature. This will not
> work on systems that do support SECCOMP_FILTER_FLAG_NEW_LISTENER but do not
> support SECCOMP_USER_NOTIF_FLAG_CONTINUE. So move the latter ifndef out of
> the former ifndef's scope.
> 
> 2019-10-20 11:14:01 make run_tests -C seccomp
> make: Entering directory 
> '/usr/src/perf_selftests-x86_64-rhel-7.6-0eebfed2954f152259cae0ad57b91d3ea92968e8/tools/testing/selftests/seccomp'
> gcc -Wl,-no-as-needed -Wall  seccomp_bpf.c -lpthread -o seccomp_bpf
> seccomp_bpf.c: In function ‘user_notification_continue’:
> seccomp_bpf.c:3562:15: error: ‘SECCOMP_USER_NOTIF_FLAG_CONTINUE’ undeclared 
> (first use in this function)
>   resp.flags = SECCOMP_USER_NOTIF_FLAG_CONTINUE;
>^~~~
> seccomp_bpf.c:3562:15: note: each undeclared identifier is reported only once 
> for each function it appears in
> Makefile:12: recipe for target 'seccomp_bpf' failed
> make: *** [seccomp_bpf] Error 1
> make: Leaving directory 
> '/usr/src/perf_selftests-x86_64-rhel-7.6-0eebfed2954f152259cae0ad57b91d3ea92968e8/tools/testing/selftests/seccomp'
> 
> Reported-by: kernel test robot 
> Fixes: 0eebfed2954f ("seccomp: test SECCOMP_USER_NOTIF_FLAG_CONTINUE")
> Cc: linux-kselft...@vger.kernel.org
> Signed-off-by: Christian Brauner 

Reviewed-by: Tycho Andersen 

Re: [PATCH 5/5] rtc: rtc-rc5t583: add ricoh rc5t619 RTC driver

[Alexandre Belloni]

On 21/10/2019 15:19:09+0200, Stefan Agner wrote:
> On 2019-10-21 07:41, Andreas Kemnade wrote:
> > Add an RTC driver for the RTC device on Ricoh MFD rc5t619,
> > which is implemented as a variant of rn5t618
> > 
> > Signed-off-by: Andreas Kemnade 
> > ---
> >  drivers/rtc/Kconfig   |  10 +
> >  drivers/rtc/Makefile  |   1 +
> >  drivers/rtc/rtc-rc5t619.c | 476 
> > ++
> 
> Parts of this driver look very similar to drivers/rtc/rtc-rc5t583.c. Can
> it maybe shared?
> 

If this could be done it would be better. I can't find any public
datasheet though...

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

RE:PERSONAL LETTER FROM MRS RASHIA AMIRA

[Mr Barrister Hans Erich]

Greetings

My name is Barrister Hans Erich.

I have a client who is interested to invest in your country, she is a well 
known politician in her country and deserve a lucrative investment partnership 
with you outside her country without any delay   Please can you manage such 
investment please Kindly reply for further details.

Your full names -


Your urgent response will be appreciated

Thank you and God bless you.

Barrister Hans Erich

Yours sincerely,
Barrister Hans Erich

Re: [PATCH RFC v2 2/2] USB: ldusb: fix ring-buffer locking

[Greg Kroah-Hartman]

On Mon, Oct 21, 2019 at 10:56:27AM +0200, Johan Hovold wrote:
> On Fri, Oct 18, 2019 at 11:54:58AM -0700, Greg Kroah-Hartman wrote:
> > On Fri, Oct 18, 2019 at 05:19:55PM +0200, Johan Hovold wrote:
> > > The custom ring-buffer implementation was merged without any locking
> > > whatsoever, but a spinlock was later added by commit 9d33efd9a791
> > > ("USB: ldusb bugfix").
> > > 
> > > The lock did not cover the loads from the ring-buffer entry after
> > > determining the buffer was non-empty, nor the update of the tail index
> > > once the entry had been processed. The former could lead to stale data
> > > being returned, while the latter could lead to memory corruption on
> > > sufficiently weakly ordered architectures.
> > 
> > Ugh.
> > 
> > This almost looks sane, but what's the odds there is some other issue in
> > here as well?  Would it make sense to just convert the code to use the
> > "standard" ring buffer code instead?
> 
> Yeah, long term that may be the right thing to do, but I wanted a
> minimal fix addressing the issue at hand without having to reimplement
> the driver and fix all other (less-critical) issues in there...
> 
> For the ring-buffer corruption / info-leak issue, these two patches
> should be sufficient though.
> 
> Copying the ring-buffer entry to a temporary buffer while holding the
> lock might still be preferred to avoid having to deal with barrier
> subtleties. But unless someone speaks out against 2/2, I'd just go ahead
> and apply it.

Ok, feel free to resend this and I'll queue it up, it's gone from my
queue :(

thanks,

greg k-h

Re: [RFC PATCH v2 11/16] mm,hwpoison: Rework soft offline for in-use pages

[Oscar Salvador]

On Fri, Oct 18, 2019 at 02:39:01PM +0200, Michal Hocko wrote:
> 
> I am sorry but I got lost in the above description and I cannot really
> make much sense from the code either. Let me try to outline the way how
> I think about this.
> 
> Say we have a pfn to hwpoison. We have effectivelly three possibilities
> - page is poisoned already - done nothing to do
> - page is managed by the buddy allocator - excavate from there
> - page is in use
> 
> The last category is the most interesting one. There are essentially
> three classes of pages
> - freeable
> - migrateable
> - others
> 
> We cannot do really much about the last one, right? Do we mark them
> HWPoison anyway?

We can only perform actions on LRU/Movable pages or hugetlb pages.

So unless the page does not fall into those areas, we do not do anything
with them.

> Freeable should be simply marked HWPoison and freed.
> For all those migrateable, we simply do migrate and mark HWPoison.
> Now the main question is how to handle HWPoison page when it is freed
> - aka last reference is dropped. The main question is whether the last
> reference is ever dropped. If yes then the free_pages_prepare should
> never release it to the allocator (some compound destructors would have
> to special case as well, e.g. hugetlb would have to hand over to the
> allocator rather than a pool). If not then the page would be lingering
> potentially with some state bound to it (e.g. memcg charge).  So I
> suspect you want the former.

For non-hugetlb pages, we do not call put_page in the migration path,
but we do it in page_handle_poison, after the page has been flagged as
hwpoison.
Then the check in free_papes_prepare will see that the page is hwpoison
and will bail out, so the page is not released into the allocator/pcp lists.

Hugetlb pages follow a different methodology.
They are dissolved, and then we split the higher-order page and take the
page off the buddy.
The problem is that while it is easy to hold a non-hugetlb page,
doing the same for hugetlb pages is not that easy:

1) we would need to hook in enqueue_hugetlb_page so the page is not enqueued
   into hugetlb freelists
2) when trying to free a hugetlb page, we would need to do as we do for gigantic
   pages now, and that is breaking down the pages into order-0 pages and release
   them to the buddy (so the check in free_papges_prepare would skip the
   hwpoison page).
   Trying to handle a higher-order hwpoison page in free_pages_prepare is
   a bit complicated.
   
There is one thing I was unsure though.
Bailing out at the beginning of free_pages_prepare if the page is hwpoison
means that the calls to

- __memcg_kmem_uncharge
- page_cpupid_reset_last
- reset_page_owner
- ...

will not be performed.
I thought this is right because the page is not really "free", it is just 
unusable,
so.. it should be still charged to the memcg?

-- 
Oscar Salvador
SUSE L3

Re: linux-next: Tree for Oct 18 (objtool)

[Peter Zijlstra]

On Mon, Oct 21, 2019 at 03:19:48PM +0200, Christian Brauner wrote:
> On Mon, Oct 21, 2019 at 03:11:49PM +0200, Peter Zijlstra wrote:

> > By popular request; here's that alternative. Completely untested :-)
> 
> Am I not getting some mails? :)

You're not on the 'right' IRC channels :-)

> I prefer this one as it allows us to avoid working around this in
> usercopy.c. Should especially make if this potentially helps in other
> cases as well?

That was Josh's argument too.

Personally I think GCC is being a moron here, because with value range
analysis it should be able to prove the shift-UB cannot happen (the <
sizeof(unsigned long) conditions on both), but alas, it emits the UBSAN
calls anyway.

Re: [PATCH v3 3/3] PCI: pciehp: Add dmi table for in-band presence disabled

[Mika Westerberg]

On Thu, Oct 17, 2019 at 03:32:56PM -0400, Stuart Hayes wrote:
> Some systems have in-band presence detection disabled for hot-plug PCI
> slots, but do not report this in the slot capabilities 2 (SLTCAP2) register.
> On these systems, presence detect can become active well after the link is
> reported to be active, which can cause the slots to be disabled after a
> device is connected.
> 
> Add a dmi table to flag these systems as having in-band presence disabled.
> 
> Signed-off-by: Stuart Hayes 
> ---
>  drivers/pci/hotplug/pciehp_hpc.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/pci/hotplug/pciehp_hpc.c 
> b/drivers/pci/hotplug/pciehp_hpc.c
> index 02eb811a014f..4d377a2a62ce 100644
> --- a/drivers/pci/hotplug/pciehp_hpc.c
> +++ b/drivers/pci/hotplug/pciehp_hpc.c
> @@ -14,6 +14,7 @@
>  
>  #define dev_fmt(fmt) "pciehp: " fmt
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -26,6 +27,16 @@
>  #include "../pci.h"
>  #include "pciehp.h"
>  
> +static const struct dmi_system_id inband_presence_disabled_dmi_table[] = {
> + {
> + .ident = "Dell System",
> + .matches = {
> + DMI_MATCH(DMI_OEM_STRING, "Dell System"),

Sorry if this has been discussed previously already but isn't this going
to apply on all Dell systems, not just the affected ones? Is this the
intention?

[PATCH v2 ] iommu/vt-d: Fix panic after kexec -p for kdump

[John Donnelly]

This cures a panic on restart after a kexec -p operation on 5.3 and 5.4 kernels.

Fixes: 8af46c784ecfe ("iommu/vt-d: Implement is_attach_deferred iommu ops 
entry")

The underlying state of the iommu registers (iommu->flags &
VTD_FLAG_TRANS_PRE_ENABLED) on a restart results in a domain being marked as
"DEFER_DEVICE_DOMAIN_INFO" that produces an Oops in identity_mapping().

[   43.654737] BUG: kernel NULL pointer dereference, address:
0056
[   43.655720] #PF: supervisor read access in kernel mode
[   43.655720] #PF: error_code(0x) - not-present page
[   43.655720] PGD 0 P4D 0
[   43.655720] Oops:  [#1] SMP PTI
[   43.655720] CPU: 0 PID: 1 Comm: swapper/0 Not tainted
5.3.2-1940.el8uek.x86_64 #1
[   43.655720] Hardware name: Oracle Corporation ORACLE SERVER
X5-2/ASM,MOTHERBOARD,1U, BIOS 30140300 09/20/2018
[   43.655720] RIP: 0010:iommu_need_mapping+0x29/0xd0
[   43.655720] Code: 00 0f 1f 44 00 00 48 8b 97 70 02 00 00 48 83 fa ff
74 53 48 8d 4a ff b8 01 00 00 00 48 83 f9 fd 76 01 c3 48 8b 35 7f 58 e0
01 <48> 39 72 58 75 f2 55 48 89 e5 41 54 53 48 8b 87 28 02 00 00 4c 8b
[   43.655720] RSP: 0018:c901b9b0 EFLAGS: 00010246
[   43.655720] RAX: 0001 RBX: 1000 RCX:
fffd
[   43.655720] RDX: fffe RSI: 8880719b8000 RDI:
8880477460b0
[   43.655720] RBP: c901b9e8 R08:  R09:
888047c01700
[   43.655720] R10: 2194036fc692 R11:  R12:

[   43.655720] R13: 8880477460b0 R14: 0cc0 R15:
888072d2b558
[   43.655720] FS:  () GS:888071c0()
knlGS:
[   43.655720] CS:  0010 DS:  ES:  CR0: 80050033
[   43.655720] CR2: 0056 CR3: 7440a002 CR4:
001606b0
[   43.655720] Call Trace:
[   43.655720]  ? intel_alloc_coherent+0x2a/0x180
[   43.655720]  ? __schedule+0x2c2/0x650
[   43.655720]  dma_alloc_attrs+0x8c/0xd0
[   43.655720]  dma_pool_alloc+0xdf/0x200
[   43.655720]  ehci_qh_alloc+0x58/0x130
[   43.655720]  ehci_setup+0x287/0x7ba
[   43.655720]  ? _dev_info+0x6c/0x83
[   43.655720]  ehci_pci_setup+0x91/0x436
[   43.655720]  usb_add_hcd.cold.48+0x1d4/0x754
[   43.655720]  usb_hcd_pci_probe+0x2bc/0x3f0
[   43.655720]  ehci_pci_probe+0x39/0x40
[   43.655720]  local_pci_probe+0x47/0x80
[   43.655720]  pci_device_probe+0xff/0x1b0
[   43.655720]  really_probe+0xf5/0x3a0
[   43.655720]  driver_probe_device+0xbb/0x100
[   43.655720]  device_driver_attach+0x58/0x60
[   43.655720]  __driver_attach+0x8f/0x150
[   43.655720]  ? device_driver_attach+0x60/0x60
[   43.655720]  bus_for_each_dev+0x74/0xb0
[   43.655720]  driver_attach+0x1e/0x20
[   43.655720]  bus_add_driver+0x151/0x1f0
[   43.655720]  ? ehci_hcd_init+0xb2/0xb2
[   43.655720]  ? do_early_param+0x95/0x95
[   43.655720]  driver_register+0x70/0xc0
[   43.655720]  ? ehci_hcd_init+0xb2/0xb2
[   43.655720]  __pci_register_driver+0x57/0x60
[   43.655720]  ehci_pci_init+0x6a/0x6c
[   43.655720]  do_one_initcall+0x4a/0x1fa
[   43.655720]  ? do_early_param+0x95/0x95
[   43.655720]  kernel_init_freeable+0x1bd/0x262
[   43.655720]  ? rest_init+0xb0/0xb0
[   43.655720]  kernel_init+0xe/0x110
[   43.655720]  ret_from_fork+0x24/0x50
 

Signed-off-by: John Donnelly 
Reviewed-by: Lu Baolu 


---
 drivers/iommu/intel-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index c4e0e4a9ee9e..f83a9a302f8e 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -2783,7 +2783,7 @@ static int identity_mapping(struct device *dev)
struct device_domain_info *info;
 
info = dev->archdata.iommu;
-   if (info && info != DUMMY_DEVICE_DOMAIN_INFO)
+   if (info && info != DUMMY_DEVICE_DOMAIN_INFO && info != 
DEFER_DEVICE_DOMAIN_INFO)
return (info->domain == si_domain);
 
return 0;
-- 
2.20.1

Re: KCSAN: data-race in exit_signals / prepare_signal

[Oleg Nesterov]

On 10/21, Marco Elver wrote:
>
> On Mon, 21 Oct 2019 at 14:00, Oleg Nesterov  wrote:
> >
> > I think this is WONTFIX.
>
> If taking the spinlock is unnecessary (which AFAIK it probably is) and
> there are no other writers to this flag, you will still need a
> WRITE_ONCE(tsk->flags, tsk->flags | PF_EXITING) to avoid the
> data-race.

Or even WRITE_ONCE(tsk->flags, READ_ONCE(tsk->flags) | PF_EXITING) in
theory. But in practice, I do not think compiler can turn

curent->flags |= PF_EXITING;

into something which temporary clears another flag, say, PF_KTHREAD.

> However, if it is possible that there are concurrent writers setting
> other bits in flags,

No, only current taks should change its ->flags.

Oleg.

Re: [PATCH 4/5] perf tools: Support single perf.data file directory

[Arnaldo Carvalho de Melo]

Em Mon, Oct 21, 2019 at 03:42:39PM +0300, Adrian Hunter escreveu:
> On 7/10/19 3:06 PM, Adrian Hunter wrote:
> > On 7/10/19 2:20 PM, Jiri Olsa wrote:
> >> On Fri, Oct 04, 2019 at 11:31:20AM +0300, Adrian Hunter wrote:
> >>
> >> SNIP
> >>
> >>>   u8 pad[8] = {0};
> >>>  
> >>> - if (!perf_data__is_pipe(data) && !perf_data__is_dir(data)) {
> >>> + if (!perf_data__is_pipe(data) && perf_data__is_single_file(data)) {
> >>>   off_t file_offset;
> >>>   int fd = perf_data__fd(data);
> >>>   int err;
> >>> diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c
> >>> index df173f0bf654..964ea101dba6 100644
> >>> --- a/tools/perf/util/data.c
> >>> +++ b/tools/perf/util/data.c
> >>> @@ -76,6 +76,13 @@ int perf_data__open_dir(struct perf_data *data)
> >>>   DIR *dir;
> >>>   int nr = 0;
> >>>  
> >>> + /*
> >>> +  * Directory containing a single regular perf data file which is already
> >>> +  * open, means there is nothing more to do here.
> >>> +  */
> >>> + if (perf_data__is_single_file(data))
> >>> + return 0;
> >>> +
> >>
> >> cool, I like this approach much more than the previous flag
> > 
> > Yes it is much nicer.  Thanks for your direction on that.
> > 
> >>
> >> any change you (if there's repost) or Arnaldo
> >> could squeeze in indent change below?
> > 
> > Sent a patch, to be applied before these.
> > 
> 
> That is:
> 
> "[PATCH] perf session: Fix indent in perf_session__new()"
> 
> Any comments on this patch set Arnaldo?

I'll take a look at it later, I think Jiri is ok with it already?

- Arnaldo

Re: drm/komeda: Dump SC_ENH_* registers from scaler block

[Mihail Atanassov]

On Wednesday, 16 October 2019 09:17:39 BST james qian wang (Arm Technology 
China) wrote:
> On Tue, Oct 15, 2019 at 11:00:01AM +, Mihail Atanassov wrote:
> > Signed-off-by: Mihail Atanassov 
> > ---
> >  .../gpu/drm/arm/display/komeda/d71/d71_component.c | 14 +-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c 
> > b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > index c3d29c0b051b..7252fc387fba 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/d71/d71_component.c
> > @@ -703,7 +703,7 @@ static void d71_scaler_update(struct komeda_component 
> > *c,
> >  
> >  static void d71_scaler_dump(struct komeda_component *c, struct seq_file 
> > *sf)
> >  {
> > -   u32 v[9];
> > +   u32 v[10];
> >  
> > dump_block_header(sf, c->reg);
> >  
> > @@ -723,6 +723,18 @@ static void d71_scaler_dump(struct komeda_component 
> > *c, struct seq_file *sf)
> > seq_printf(sf, "SC_H_DELTA_PH:\t\t0x%X\n", v[6]);
> > seq_printf(sf, "SC_V_INIT_PH:\t\t0x%X\n", v[7]);
> > seq_printf(sf, "SC_V_DELTA_PH:\t\t0x%X\n", v[8]);
> > +
> > +   get_values_from_reg(c->reg, 0x130, 10, v);
> > +   seq_printf(sf, "SC_ENH_LIMITS:\t\t0x%X\n", v[0]);
> > +   seq_printf(sf, "SC_ENH_COEFF0:\t\t0x%X\n", v[1]);
> > +   seq_printf(sf, "SC_ENH_COEFF1:\t\t0x%X\n", v[2]);
> > +   seq_printf(sf, "SC_ENH_COEFF2:\t\t0x%X\n", v[3]);
> > +   seq_printf(sf, "SC_ENH_COEFF3:\t\t0x%X\n", v[4]);
> > +   seq_printf(sf, "SC_ENH_COEFF4:\t\t0x%X\n", v[5]);
> > +   seq_printf(sf, "SC_ENH_COEFF5:\t\t0x%X\n", v[6]);
> > +   seq_printf(sf, "SC_ENH_COEFF6:\t\t0x%X\n", v[7]);
> > +   seq_printf(sf, "SC_ENH_COEFF7:\t\t0x%X\n", v[8]);
> > +   seq_printf(sf, "SC_ENH_COEFF8:\t\t0x%X\n", v[9]);
> >  }
> >
> 
> Looks good to me.
> 
> Reviewed-by: James Qian Wang (Arm Technology China) 

Thanks, applied to drm-misc-next - 
2b6f5883edcc47ef6146832112a0125810d28f78.

> 
> >  static const struct komeda_component_funcs d71_scaler_funcs = {
> 


-- 
Mihail

[PATCH 21/57] perf vendor events arm64: Add some missing events for Hisi hip08 L3C PMU

[Arnaldo Carvalho de Melo]

From: John Garry 

Add some more missing events.

Signed-off-by: John Garry 
Reviewed-by: Shaokun Zhang 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Cc: linux...@huawei.com
Link: 
http://lore.kernel.org/lkml/1567612484-195727-4-git-send-email-john.ga...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../arm64/hisilicon/hip08/uncore-l3c.json | 56 +++
 1 file changed, 56 insertions(+)

diff --git a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-l3c.json 
b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-l3c.json
index ca48747642e1..f463d0acfaef 100644
--- a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-l3c.json
+++ b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-l3c.json
@@ -34,4 +34,60 @@
"PublicDescription": "l3c precharge commands",
"Unit": "hisi_sccl,l3c",
},
+   {
+   "EventCode": "0x20",
+   "EventName": "uncore_hisi_l3c.rd_spipe",
+   "BriefDescription": "Count of the number of read lines that come 
from this cluster of CPU core in spipe",
+   "PublicDescription": "Count of the number of read lines that come 
from this cluster of CPU core in spipe",
+   "Unit": "hisi_sccl,l3c",
+   },
+   {
+   "EventCode": "0x21",
+   "EventName": "uncore_hisi_l3c.wr_spipe",
+   "BriefDescription": "Count of the number of write lines that come 
from this cluster of CPU core in spipe",
+   "PublicDescription": "Count of the number of write lines that come 
from this cluster of CPU core in spipe",
+   "Unit": "hisi_sccl,l3c",
+   },
+   {
+   "EventCode": "0x22",
+   "EventName": "uncore_hisi_l3c.rd_hit_spipe",
+   "BriefDescription": "Count of the number of read lines that hits in 
spipe of this L3C",
+   "PublicDescription": "Count of the number of read lines that hits 
in spipe of this L3C",
+   "Unit": "hisi_sccl,l3c",
+   },
+   {
+   "EventCode": "0x23",
+   "EventName": "uncore_hisi_l3c.wr_hit_spipe",
+   "BriefDescription": "Count of the number of write lines that hits 
in spipe of this L3C",
+   "PublicDescription": "Count of the number of write lines that hits 
in spipe of this L3C",
+   "Unit": "hisi_sccl,l3c",
+   },
+   {
+   "EventCode": "0x29",
+   "EventName": "uncore_hisi_l3c.back_invalid",
+   "BriefDescription": "Count of the number of L3C back invalid 
operations",
+   "PublicDescription": "Count of the number of L3C back invalid 
operations",
+   "Unit": "hisi_sccl,l3c",
+   },
+   {
+   "EventCode": "0x40",
+   "EventName": "uncore_hisi_l3c.retry_cpu",
+   "BriefDescription": "Count of the number of retry that L3C 
suppresses the CPU operations",
+   "PublicDescription": "Count of the number of retry that L3C 
suppresses the CPU operations",
+   "Unit": "hisi_sccl,l3c",
+   },
+   {
+   "EventCode": "0x41",
+   "EventName": "uncore_hisi_l3c.retry_ring",
+   "BriefDescription": "Count of the number of retry that L3C 
suppresses the ring operations",
+   "PublicDescription": "Count of the number of retry that L3C 
suppresses the ring operations",
+   "Unit": "hisi_sccl,l3c",
+   },
+   {
+   "EventCode": "0x42",
+   "EventName": "uncore_hisi_l3c.prefetch_drop",
+   "BriefDescription": "Count of the number of prefetch drops from 
this L3C",
+   "PublicDescription": "Count of the number of prefetch drops from 
this L3C",
+   "Unit": "hisi_sccl,l3c",
+   },
 ]
-- 
2.21.0

[PATCH 22/57] perf vendor events arm64: Add some missing events for Hisi hip08 HHA PMU

[Arnaldo Carvalho de Melo]

From: John Garry 

Add some more missing events.

A trivial typo is also fixed.

Signed-off-by: John Garry 
Reviewed-by: Shaokun Zhang 
Cc: Alexander Shishkin 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Will Deacon 
Cc: linux...@huawei.com
Link: 
http://lore.kernel.org/lkml/1567612484-195727-5-git-send-email-john.ga...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 .../arm64/hisilicon/hip08/uncore-hha.json | 23 ++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-hha.json 
b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-hha.json
index 447d3064de90..3be418a248ea 100644
--- a/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-hha.json
+++ b/tools/perf/pmu-events/arch/arm64/hisilicon/hip08/uncore-hha.json
@@ -20,6 +20,13 @@
"PublicDescription": "The number of all operations received by the 
HHA from another SCCL in this socket",
"Unit": "hisi_sccl,hha",
},
+   {
+   "EventCode": "0x03",
+   "EventName": "uncore_hisi_hha.rx_ccix",
+   "BriefDescription": "Count of the number of operations that HHA has 
received from CCIX",
+   "PublicDescription": "Count of the number of operations that HHA 
has received from CCIX",
+   "Unit": "hisi_sccl,hha",
+   },
{
"EventCode": "0x1c",
"EventName": "uncore_hisi_hha.rd_ddr_64b",
@@ -29,7 +36,7 @@
},
{
"EventCode": "0x1d",
-   "EventName": "uncore_hisi_hha.wr_dr_64b",
+   "EventName": "uncore_hisi_hha.wr_ddr_64b",
"BriefDescription": "The number of write operations sent by HHA to 
DDRC which size is 64 bytes",
"PublicDescription": "The number of write operations sent by HHA to 
DDRC which size is 64 bytes",
"Unit": "hisi_sccl,hha",
@@ -48,4 +55,18 @@
"PublicDescription": "The number of write operations sent by HHA to 
DDRC which size is 128 bytes",
"Unit": "hisi_sccl,hha",
},
+   {
+   "EventCode": "0x20",
+   "EventName": "uncore_hisi_hha.spill_num",
+   "BriefDescription": "Count of the number of spill operations that 
the HHA has sent",
+   "PublicDescription": "Count of the number of spill operations that 
the HHA has sent",
+   "Unit": "hisi_sccl,hha",
+   },
+   {
+   "EventCode": "0x21",
+   "EventName": "uncore_hisi_hha.spill_success",
+   "BriefDescription": "Count of the number of successful spill 
operations that the HHA has sent",
+   "PublicDescription": "Count of the number of successful spill 
operations that the HHA has sent",
+   "Unit": "hisi_sccl,hha",
+   },
 ]
-- 
2.21.0

[PATCH 12/57] perf jvmti: Link against tools/lib/ctype.h to have weak strlcpy()

[Arnaldo Carvalho de Melo]

From: Thomas Richter 

The build of file libperf-jvmti.so succeeds but the resulting
object fails to load:

 # ~/linux/tools/perf/perf record -k mono -- java  \
  -XX:+PreserveFramePointer \
  -agentpath:/root/linux/tools/perf/libperf-jvmti.so \
   hog 10 123450
  Error occurred during initialization of VM
  Could not find agent library /root/linux/tools/perf/libperf-jvmti.so
  in absolute path, with error:
  /root/linux/tools/perf/libperf-jvmti.so: undefined symbol: _ctype

Add the missing _ctype symbol into the build script.

Fixes: 79743bc927f6 ("perf jvmti: Link against tools/lib/string.o to have weak 
strlcpy()")
Signed-off-by: Thomas Richter 
Cc: Heiko Carstens 
Cc: Vasily Gorbik 
Link: http://lore.kernel.org/lkml/20191008093841.59387-1-tmri...@linux.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/jvmti/Build | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/perf/jvmti/Build b/tools/perf/jvmti/Build
index 1e148bbdf820..202cadaaf097 100644
--- a/tools/perf/jvmti/Build
+++ b/tools/perf/jvmti/Build
@@ -2,7 +2,7 @@ jvmti-y += libjvmti.o
 jvmti-y += jvmti_agent.o
 
 # For strlcpy
-jvmti-y += libstring.o
+jvmti-y += libstring.o libctype.o
 
 CFLAGS_jvmti = -fPIC -DPIC -I$(JDIR)/include -I$(JDIR)/include/linux
 CFLAGS_REMOVE_jvmti  = -Wmissing-declarations
@@ -15,3 +15,7 @@ CFLAGS_libstring.o += -Wno-unused-parameter 
-DETC_PERFCONFIG="BUILD_STR($(ETC_PE
 $(OUTPUT)jvmti/libstring.o: ../lib/string.c FORCE
$(call rule_mkdir)
$(call if_changed_dep,cc_o_c)
+
+$(OUTPUT)jvmti/libctype.o: ../lib/ctype.c FORCE
+   $(call rule_mkdir)
+   $(call if_changed_dep,cc_o_c)
-- 
2.21.0

[PATCH 14/57] perf trace: Add syscall failure stats to -s/--summary and -S/--with-summary

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Just like strace has:

  # trace -s sleep 1

  Summary of events:

  sleep (32370), 80 events, 93.0%

syscallcalls  errors  total   min   avg   max   
stddev
  (msec)(msec)(msec)(msec)  
  (%)
---   --  - - - 
--
nanosleep  1  0  1000.402  1000.402  1000.402  1000.402 
 0.00%
mmap   8  0 0.023 0.002 0.003 0.004 
 8.49%
close  5  0 0.015 0.001 0.003 0.009 
51.39%
mprotect   4  0 0.014 0.002 0.003 0.005 
16.95%
openat 3  0 0.013 0.003 0.004 0.005 
14.29%
munmap 1  0 0.010 0.010 0.010 0.010 
 0.00%
read   4  0 0.005 0.001 0.001 0.002 
16.83%
brk4  0 0.004 0.001 0.001 0.002 
20.82%
access 1  1 0.004 0.004 0.004 0.004 
 0.00%
fstat  3  0 0.003 0.001 0.001 0.001 
12.17%
lseek  3  0 0.003 0.001 0.001 0.001 
11.45%
arch_prctl 2  1 0.002 0.001 0.001 0.001 
 2.30%
execve 1  0 0.000 0.000 0.000 0.000 
 0.00%

  #

  # perf trace -S sleep 1
 ?  ... [continued]: execve()) = 0
 0.028 brk(brk: NULL)  = 0x559f5bd96000
 0.033 arch_prctl(option: 0x3001, arg2: 0x7ffda8b715a0) = -1 EINVAL 
(Invalid argument)
 0.046 access(filename: "/etc/ld.so.preload", mode: R) = -1 ENOENT (No such 
file or directory)
 0.055 openat(dfd: CWD, filename: "/etc/ld.so.cache", flags: 
RDONLY|CLOEXEC) = 3
 0.060 fstat(fd: 3, statbuf: 0x7ffda8b707a0)   = 0
 0.062 mmap(addr: NULL, len: 134346, prot: READ, flags: PRIVATE, fd: 3, 
off: 0) = 0x7f3aedfc4000
 0.066 close(fd: 3)= 0
 0.079 openat(dfd: CWD, filename: "/lib64/libc.so.6", flags: 
RDONLY|CLOEXEC) = 3
 0.085 read(fd: 3, buf: 0x7ffda8b70948, count: 832) = 832
 0.088 lseek(fd: 3, offset: 792, whence: SET)  = 792
 0.090 read(fd: 3, buf: 0x7ffda8b70810, count: 68) = 68
 0.093 fstat(fd: 3, statbuf: 0x7ffda8b707f0)   = 0
 0.095 mmap(addr: NULL, len: 8192, prot: READ|WRITE, flags: 
PRIVATE|ANONYMOUS) = 0x7f3aedfc2000
 0.101 lseek(fd: 3, offset: 792, whence: SET)  = 792
 0.103 read(fd: 3, buf: 0x7ffda8b70450, count: 68) = 68
 0.105 lseek(fd: 3, offset: 864, whence: SET)  = 864
 0.107 read(fd: 3, buf: 0x7ffda8b70470, count: 32) = 32
 0.110 mmap(addr: NULL, len: 1857472, prot: READ, flags: PRIVATE|DENYWRITE, 
fd: 3, off: 0) = 0x7f3aeddfc000
 0.114 mprotect(start: 0x7f3aede1e000, len: 1679360, prot: NONE) = 0
 0.121 mmap(addr: 0x7f3aede1e000, len: 1363968, prot: READ|EXEC, flags: 
PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x22000) = 0x7f3aede1e000
 0.127 mmap(addr: 0x7f3aedf6b000, len: 311296, prot: READ, flags: 
PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x16f000) = 0x7f3aedf6b000
 0.131 mmap(addr: 0x7f3aedfb8000, len: 24576, prot: READ|WRITE, flags: 
PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x1bb000) = 0x7f3aedfb8000
 0.138 mmap(addr: 0x7f3aedfbe000, len: 14272, prot: READ|WRITE, flags: 
PRIVATE|FIXED|ANONYMOUS) = 0x7f3aedfbe000
 0.147 close(fd: 3)= 0
 0.158 arch_prctl(option: SET_FS, arg2: 0x7f3aedfc3580) = 0
 0.210 mprotect(start: 0x7f3aedfb8000, len: 16384, prot: READ) = 0
 0.230 mprotect(start: 0x559f5b27d000, len: 4096, prot: READ) = 0
 0.236 mprotect(start: 0x7f3aee00f000, len: 4096, prot: READ) = 0
 0.240 munmap(addr: 0x7f3aedfc4000, len: 134346) = 0
 0.300 brk(brk: NULL)  = 0x559f5bd96000
 0.302 brk(brk: 0x559f5bdb7000)= 0x559f5bdb7000
 0.305 brk(brk: NULL)  = 0x559f5bdb7000
 0.310 openat(dfd: CWD, filename: "/usr/lib/locale/locale-archive", flags: 
RDONLY|CLOEXEC) = 3
 0.315 fstat(fd: 3, statbuf: 0x7f3aedfbdac0)   = 0
 0.318 mmap(addr: NULL, len: 217750512, prot: READ, flags: PRIVATE, fd: 3, 
off: 0) = 0x7f3ae0e52000
 0.325 close(fd: 3)= 0
 0.358 nanosleep(rqtp: 0x7ffda8b714b0, rmtp: NULL) = 0
  1000.622 close(fd: 1)= 0
  1000.641 close(fd: 2)= 0
  1000.664 exit_group(error_code: 0)   = ?

   Summary of events:

   sleep (722), 80 events, 93.0%

 syscallcalls  errors  total   min   avg   max  
 stddev
   (msec)(msec)(msec)(msec) 
   (%)
 ---   --  - - 

[PATCH 36/57] libbeauty: Introduce syscall_arg__strtoul_strarray()

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

To go from strarrays strings to its indexes.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-wta0qvo207z27huib2c4i...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c   | 6 ++
 tools/perf/trace/beauty/beauty.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 3502417dc7f2..0294b17ed510 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -535,6 +535,11 @@ static size_t syscall_arg__scnprintf_strarray(char *bf, 
size_t size,
 
 #define SCA_STRARRAY syscall_arg__scnprintf_strarray
 
+bool syscall_arg__strtoul_strarray(char *bf, size_t size, struct syscall_arg 
*arg, u64 *ret)
+{
+   return strarray__strtoul(arg->parm, bf, size, ret);
+}
+
 size_t syscall_arg__scnprintf_strarray_flags(char *bf, size_t size, struct 
syscall_arg *arg)
 {
return strarray__scnprintf_flags(arg->parm, bf, size, 
arg->show_string_prefix, arg->val);
@@ -824,6 +829,7 @@ static size_t syscall_arg__scnprintf_getrandom_flags(char 
*bf, size_t size,
 
 #define STRARRAY(name, array) \
  { .scnprintf  = SCA_STRARRAY, \
+   .strtoul= STUL_STRARRAY, \
.parm   = __##array, }
 
 #define STRARRAY_FLAGS(name, array) \
diff --git a/tools/perf/trace/beauty/beauty.h b/tools/perf/trace/beauty/beauty.h
index 232b64d70096..1b8a30e5dcf9 100644
--- a/tools/perf/trace/beauty/beauty.h
+++ b/tools/perf/trace/beauty/beauty.h
@@ -122,6 +122,9 @@ unsigned long syscall_arg__val(struct syscall_arg *arg, u8 
idx);
 size_t syscall_arg__scnprintf_strarray_flags(char *bf, size_t size, struct 
syscall_arg *arg);
 #define SCA_STRARRAY_FLAGS syscall_arg__scnprintf_strarray_flags
 
+bool syscall_arg__strtoul_strarray(char *bf, size_t size, struct syscall_arg 
*arg, u64 *ret);
+#define STUL_STRARRAY syscall_arg__strtoul_strarray
+
 size_t syscall_arg__scnprintf_x86_irq_vectors(char *bf, size_t size, struct 
syscall_arg *arg);
 #define SCA_X86_IRQ_VECTORS syscall_arg__scnprintf_x86_irq_vectors
 
-- 
2.21.0

[PATCH 43/57] libperf: Introduce perf_evlist__for_each_mmap()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add the perf_evlist__for_each_mmap() function and export it in the
perf/evlist.h header, so that the user can iterate through 'struct
perf_mmap' objects.

Add a internal perf_mmap__link() function to do the actual linking.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lore.kernel.org/lkml/20191017105918.20873-2-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/lib/evlist.c  | 26 +++-
 tools/perf/lib/include/internal/evlist.h |  2 ++
 tools/perf/lib/include/internal/mmap.h   |  5 +++--
 tools/perf/lib/include/perf/evlist.h |  9 
 tools/perf/lib/libperf.map   |  1 +
 tools/perf/lib/mmap.c|  6 --
 tools/perf/util/evlist.c |  4 +++-
 7 files changed, 47 insertions(+), 6 deletions(-)

diff --git a/tools/perf/lib/evlist.c b/tools/perf/lib/evlist.c
index 65045614c938..854efff1519d 100644
--- a/tools/perf/lib/evlist.c
+++ b/tools/perf/lib/evlist.c
@@ -347,6 +347,8 @@ static struct perf_mmap* perf_evlist__alloc_mmap(struct 
perf_evlist *evlist, boo
return NULL;
 
for (i = 0; i < evlist->nr_mmaps; i++) {
+   struct perf_mmap *prev = i ? [i - 1] : NULL;
+
/*
 * When the perf_mmap() call is made we grab one refcount, plus
 * one extra to let perf_mmap__consume() get the last
@@ -356,7 +358,7 @@ static struct perf_mmap* perf_evlist__alloc_mmap(struct 
perf_evlist *evlist, boo
 * Each PERF_EVENT_IOC_SET_OUTPUT points to this mmap and
 * thus does perf_mmap__get() on it.
 */
-   perf_mmap__init([i], overwrite, NULL);
+   perf_mmap__init([i], prev, overwrite, NULL);
}
 
return map;
@@ -405,6 +407,15 @@ perf_evlist__mmap_cb_mmap(struct perf_mmap *map, struct 
perf_mmap_param *mp,
return perf_mmap__mmap(map, mp, output, cpu);
 }
 
+static void perf_evlist__set_mmap_first(struct perf_evlist *evlist, struct 
perf_mmap *map,
+   bool overwrite)
+{
+   if (overwrite)
+   evlist->mmap_ovw_first = map;
+   else
+   evlist->mmap_first = map;
+}
+
 static int
 mmap_per_evsel(struct perf_evlist *evlist, struct perf_evlist_mmap_ops *ops,
   int idx, struct perf_mmap_param *mp, int cpu_idx,
@@ -460,6 +471,9 @@ mmap_per_evsel(struct perf_evlist *evlist, struct 
perf_evlist_mmap_ops *ops,
 
if (ops->mmap(map, mp, *output, evlist_cpu) < 0)
return -1;
+
+   if (!idx)
+   perf_evlist__set_mmap_first(evlist, map, 
overwrite);
} else {
if (ioctl(fd, PERF_EVENT_IOC_SET_OUTPUT, *output) != 0)
return -1;
@@ -605,3 +619,13 @@ void perf_evlist__munmap(struct perf_evlist *evlist)
zfree(>mmap);
zfree(>mmap_ovw);
 }
+
+struct perf_mmap*
+perf_evlist__next_mmap(struct perf_evlist *evlist, struct perf_mmap *map,
+  bool overwrite)
+{
+   if (map)
+   return map->next;
+
+   return overwrite ? evlist->mmap_ovw_first : evlist->mmap_first;
+}
diff --git a/tools/perf/lib/include/internal/evlist.h 
b/tools/perf/lib/include/internal/evlist.h
index be0b25a70730..20d90e29fc0e 100644
--- a/tools/perf/lib/include/internal/evlist.h
+++ b/tools/perf/lib/include/internal/evlist.h
@@ -25,6 +25,8 @@ struct perf_evlist {
struct hlist_headheads[PERF_EVLIST__HLIST_SIZE];
struct perf_mmap*mmap;
struct perf_mmap*mmap_ovw;
+   struct perf_mmap*mmap_first;
+   struct perf_mmap*mmap_ovw_first;
 };
 
 typedef void
diff --git a/tools/perf/lib/include/internal/mmap.h 
b/tools/perf/lib/include/internal/mmap.h
index ee536c4441bb..be7556e0a2b2 100644
--- a/tools/perf/lib/include/internal/mmap.h
+++ b/tools/perf/lib/include/internal/mmap.h
@@ -32,6 +32,7 @@ struct perf_mmap {
u64  flush;
libperf_unmap_cb_t   unmap_cb;
char event_copy[PERF_SAMPLE_MAX_SIZE] __aligned(8);
+   struct perf_mmap*next;
 };
 
 struct perf_mmap_param {
@@ -41,8 +42,8 @@ struct perf_mmap_param {
 
 size_t perf_mmap__mmap_len(struct perf_mmap *map);
 
-void perf_mmap__init(struct perf_mmap *map, bool overwrite,
-libperf_unmap_cb_t unmap_cb);
+void perf_mmap__init(struct perf_mmap *map, struct perf_mmap *prev,
+bool overwrite, libperf_unmap_cb_t unmap_cb);
 int perf_mmap__mmap(struct perf_mmap *map, struct perf_mmap_param *mp,
int fd, int cpu);
 void perf_mmap__munmap(struct perf_mmap *map);
diff --git 

[PATCH 37/57] perf trace: Honour --max-events in processing syscalls:sys_enter_*

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

We were doing this only at the sys_exit syscall tracepoint, as for
strace-like we count the pair of sys_enter and sys_exit as one event,
but when asking specifically for a the syscalls:sys_enter_NAME
tracepoint we need to count each of those as an event.

I.e. things like:

  # perf trace --max-events=4 -e syscalls:sys_enter_lseek
 0.000 pool/2242 syscalls:sys_enter_lseek(fd: 14, 
offset: 0, whence: CUR)
 0.034 pool/2242 syscalls:sys_enter_lseek(fd: 15, 
offset: 0, whence: CUR)
 0.051 pool/2242 syscalls:sys_enter_lseek(fd: 16, 
offset: 0, whence: CUR)
  2307.900 sshd/30800 syscalls:sys_enter_lseek(fd: 
3, offset: 9032, whence: SET)
  #

Were going on forever, since we only had sys_enter events.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-0ob1dky1a9ijlfrfhxyl4...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 0294b17ed510..1aaf7b28eec4 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -2727,12 +2727,6 @@ static int trace__event_handler(struct trace *trace, 
struct evsel *evsel,
} else {
trace__fprintf_tp_fields(trace, evsel, sample, 
thread, NULL, 0);
}
-   ++trace->nr_events_printed;
-
-   if (evsel->max_events != ULONG_MAX && 
++evsel->nr_events_printed == evsel->max_events) {
-   evsel__disable(evsel);
-   evsel__close(evsel);
-   }
}
}
 
@@ -2743,6 +2737,13 @@ static int trace__event_handler(struct trace *trace, 
struct evsel *evsel,
trace__fprintf_callchain(trace, sample);
else if (callchain_ret < 0)
pr_err("Problem processing %s callchain, skipping...\n", 
perf_evsel__name(evsel));
+
+   ++trace->nr_events_printed;
+
+   if (evsel->max_events != ULONG_MAX && ++evsel->nr_events_printed == 
evsel->max_events) {
+   evsel__disable(evsel);
+   evsel__close(evsel);
+   }
 out:
thread__put(thread);
return 0;
-- 
2.21.0

[PATCH 51/57] libperf: Add pr_err() macro

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

And missing include for "perf/core.h" header, which provides LIBPERF_*
debug levels and add missing pr_err() support.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lore.kernel.org/lkml/20191017105918.20873-11-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/lib/include/perf/core.h | 1 +
 tools/perf/lib/internal.h  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/tools/perf/lib/include/perf/core.h 
b/tools/perf/lib/include/perf/core.h
index 2a80e4b6f819..a3f6d68edad7 100644
--- a/tools/perf/lib/include/perf/core.h
+++ b/tools/perf/lib/include/perf/core.h
@@ -9,6 +9,7 @@
 #endif
 
 enum libperf_print_level {
+   LIBPERF_ERR,
LIBPERF_WARN,
LIBPERF_INFO,
LIBPERF_DEBUG,
diff --git a/tools/perf/lib/internal.h b/tools/perf/lib/internal.h
index 37db745e1502..2c27e158de6b 100644
--- a/tools/perf/lib/internal.h
+++ b/tools/perf/lib/internal.h
@@ -2,6 +2,8 @@
 #ifndef __LIBPERF_INTERNAL_H
 #define __LIBPERF_INTERNAL_H
 
+#include 
+
 void libperf_print(enum libperf_print_level level,
   const char *format, ...)
__attribute__((format(printf, 2, 3)));
@@ -11,6 +13,7 @@ do {\
libperf_print(level, "libperf: " fmt, ##__VA_ARGS__); \
 } while (0)
 
+#define pr_err(fmt, ...)__pr(LIBPERF_ERR, fmt, ##__VA_ARGS__)
 #define pr_warning(fmt, ...)__pr(LIBPERF_WARN, fmt, ##__VA_ARGS__)
 #define pr_info(fmt, ...)   __pr(LIBPERF_INFO, fmt, ##__VA_ARGS__)
 #define pr_debug(fmt, ...)  __pr(LIBPERF_DEBUG, fmt, ##__VA_ARGS__)
-- 
2.21.0

[PATCH 44/57] libperf: Move mmap allocation to perf_evlist__mmap_ops::get

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Move allocation of the mmap array into perf_evlist__mmap_ops::get, to
centralize the mmap allocation.

Also move nr_mmap setup to perf_evlist__mmap_ops so it's centralized and
shared by both perf and libperf mmap code.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lore.kernel.org/lkml/20191017105918.20873-3-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/lib/evlist.c  | 42 
 tools/perf/util/evlist.c | 24 +--
 2 files changed, 34 insertions(+), 32 deletions(-)

diff --git a/tools/perf/lib/evlist.c b/tools/perf/lib/evlist.c
index 854efff1519d..73aac6bb2ac5 100644
--- a/tools/perf/lib/evlist.c
+++ b/tools/perf/lib/evlist.c
@@ -338,10 +338,6 @@ static struct perf_mmap* perf_evlist__alloc_mmap(struct 
perf_evlist *evlist, boo
int i;
struct perf_mmap *map;
 
-   evlist->nr_mmaps = perf_cpu_map__nr(evlist->cpus);
-   if (perf_cpu_map__empty(evlist->cpus))
-   evlist->nr_mmaps = perf_thread_map__nr(evlist->threads);
-
map = zalloc(evlist->nr_mmaps * sizeof(struct perf_mmap));
if (!map)
return NULL;
@@ -384,18 +380,22 @@ static void perf_evlist__set_sid_idx(struct perf_evlist 
*evlist,
 static struct perf_mmap*
 perf_evlist__mmap_cb_get(struct perf_evlist *evlist, bool overwrite, int idx)
 {
-   struct perf_mmap *map = >mmap[idx];
+   struct perf_mmap *maps;
 
-   if (overwrite) {
-   if (!evlist->mmap_ovw) {
-   evlist->mmap_ovw = perf_evlist__alloc_mmap(evlist, 
true);
-   if (!evlist->mmap_ovw)
-   return NULL;
-   }
-   map = >mmap_ovw[idx];
+   maps = overwrite ? evlist->mmap_ovw : evlist->mmap;
+
+   if (!maps) {
+   maps = perf_evlist__alloc_mmap(evlist, overwrite);
+   if (!maps)
+   return NULL;
+
+   if (overwrite)
+   evlist->mmap_ovw = maps;
+   else
+   evlist->mmap = maps;
}
 
-   return map;
+   return [idx];
 }
 
 #define FD(e, x, y) (*(int *) xyarray__entry(e->fd, x, y))
@@ -556,6 +556,17 @@ mmap_per_cpu(struct perf_evlist *evlist, struct 
perf_evlist_mmap_ops *ops,
return -1;
 }
 
+static int perf_evlist__nr_mmaps(struct perf_evlist *evlist)
+{
+   int nr_mmaps;
+
+   nr_mmaps = perf_cpu_map__nr(evlist->cpus);
+   if (perf_cpu_map__empty(evlist->cpus))
+   nr_mmaps = perf_thread_map__nr(evlist->threads);
+
+   return nr_mmaps;
+}
+
 int perf_evlist__mmap_ops(struct perf_evlist *evlist,
  struct perf_evlist_mmap_ops *ops,
  struct perf_mmap_param *mp)
@@ -567,10 +578,7 @@ int perf_evlist__mmap_ops(struct perf_evlist *evlist,
if (!ops || !ops->get || !ops->mmap)
return -EINVAL;
 
-   if (!evlist->mmap)
-   evlist->mmap = perf_evlist__alloc_mmap(evlist, false);
-   if (!evlist->mmap)
-   return -ENOMEM;
+   evlist->nr_mmaps = perf_evlist__nr_mmaps(evlist);
 
perf_evlist__for_each_entry(evlist, evsel) {
if ((evsel->attr.read_format & PERF_FORMAT_ID) &&
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index 6cda5a311ba5..5cded4ec5806 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -599,9 +599,6 @@ static struct mmap *evlist__alloc_mmap(struct evlist 
*evlist,
int i;
struct mmap *map;
 
-   evlist->core.nr_mmaps = perf_cpu_map__nr(evlist->core.cpus);
-   if (perf_cpu_map__empty(evlist->core.cpus))
-   evlist->core.nr_mmaps = 
perf_thread_map__nr(evlist->core.threads);
map = zalloc(evlist->core.nr_mmaps * sizeof(struct mmap));
if (!map)
return NULL;
@@ -639,19 +636,21 @@ static struct perf_mmap*
 perf_evlist__mmap_cb_get(struct perf_evlist *_evlist, bool overwrite, int idx)
 {
struct evlist *evlist = container_of(_evlist, struct evlist, core);
-   struct mmap *maps = evlist->mmap;
+   struct mmap *maps;
 
-   if (overwrite) {
-   maps = evlist->overwrite_mmap;
+   maps = overwrite ? evlist->overwrite_mmap : evlist->mmap;
 
-   if (!maps) {
-   maps = evlist__alloc_mmap(evlist, true);
-   if (!maps)
-   return NULL;
+   if (!maps) {
+   maps = evlist__alloc_mmap(evlist, overwrite);
+   if (!maps)
+   return NULL;
 
+   if (overwrite) {
evlist->overwrite_mmap = maps;
if (evlist->bkw_mmap_state == BKW_MMAP_NOTREADY)

[PATCH 48/57] libperf: Add tests_mmap_cpus test

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add mmaping tests that generates prctl call on every cpu validates it
gets all the related events in ring buffer.

Committer testing:

  # make -C tools/perf/lib tests
  make: Entering directory '/home/acme/git/perf/tools/perf/lib'
LINK test-cpumap-a
LINK test-threadmap-a
LINK test-evlist-a
LINK test-evsel-a
LINK test-cpumap-so
LINK test-threadmap-so
LINK test-evlist-so
LINK test-evsel-so
  running static:
  - running test-cpumap.c...OK
  - running test-threadmap.c...OK
  - running test-evlist.c...OK
  - running test-evsel.c...OK
  running dynamic:
  - running test-cpumap.c...OK
  - running test-threadmap.c...OK
  - running test-evlist.c...OK
  - running test-evsel.c...OK
  make: Leaving directory '/home/acme/git/perf/tools/perf/lib'
  #

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lore.kernel.org/lkml/20191017105918.20873-8-jo...@kernel.org
[ Added _GNU_SOURCE define for sched.h to get sched_[gs]et_affinity
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/lib/tests/test-evlist.c | 98 ++
 1 file changed, 98 insertions(+)

diff --git a/tools/perf/lib/tests/test-evlist.c 
b/tools/perf/lib/tests/test-evlist.c
index 90a1869ba4b1..741bc1bb4524 100644
--- a/tools/perf/lib/tests/test-evlist.c
+++ b/tools/perf/lib/tests/test-evlist.c
@@ -1,4 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
+#define _GNU_SOURCE // needed for sched.h to get sched_[gs]etaffinity and 
CPU_(ZERO,SET)
+#include 
 #include 
 #include 
 #include 
@@ -299,6 +301,101 @@ static int test_mmap_thread(void)
return 0;
 }
 
+static int test_mmap_cpus(void)
+{
+   struct perf_evlist *evlist;
+   struct perf_evsel *evsel;
+   struct perf_mmap *map;
+   struct perf_cpu_map *cpus;
+   struct perf_event_attr attr = {
+   .type = PERF_TYPE_TRACEPOINT,
+   .sample_period= 1,
+   .wakeup_watermark = 1,
+   .disabled = 1,
+   };
+   cpu_set_t saved_mask;
+   char path[PATH_MAX];
+   int id, err, cpu, tmp;
+   union perf_event *event;
+   int count = 0;
+
+   snprintf(path, PATH_MAX, 
"%s/kernel/debug/tracing/events/syscalls/sys_enter_prctl/id",
+sysfs__mountpoint());
+
+   if (filename__read_int(path, )) {
+   fprintf(stderr, "error: failed to get tracepoint id: %s\n", 
path);
+   return -1;
+   }
+
+   attr.config = id;
+
+   cpus = perf_cpu_map__new(NULL);
+   __T("failed to create cpus", cpus);
+
+   evlist = perf_evlist__new();
+   __T("failed to create evlist", evlist);
+
+   evsel = perf_evsel__new();
+   __T("failed to create evsel1", evsel);
+
+   perf_evlist__add(evlist, evsel);
+
+   perf_evlist__set_maps(evlist, cpus, NULL);
+
+   err = perf_evlist__open(evlist);
+   __T("failed to open evlist", err == 0);
+
+   err = perf_evlist__mmap(evlist, 4);
+   __T("failed to mmap evlist", err == 0);
+
+   perf_evlist__enable(evlist);
+
+   err = sched_getaffinity(0, sizeof(saved_mask), _mask);
+   __T("sched_getaffinity failed", err == 0);
+
+   perf_cpu_map__for_each_cpu(cpu, tmp, cpus) {
+   cpu_set_t mask;
+
+   CPU_ZERO();
+   CPU_SET(cpu, );
+
+   err = sched_setaffinity(0, sizeof(mask), );
+   __T("sched_setaffinity failed", err == 0);
+
+   prctl(0, 0, 0, 0, 0);
+   }
+
+   err = sched_setaffinity(0, sizeof(saved_mask), _mask);
+   __T("sched_setaffinity failed", err == 0);
+
+   perf_evlist__disable(evlist);
+
+   perf_evlist__for_each_mmap(evlist, map, false) {
+   if (perf_mmap__read_init(map) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(map)) != NULL) {
+   count++;
+   perf_mmap__consume(map);
+   }
+
+   perf_mmap__read_done(map);
+   }
+
+   /* calls perf_evlist__munmap/perf_evlist__close */
+   perf_evlist__delete(evlist);
+
+   /*
+* The generated prctl events should match the
+* number of cpus or be bigger (we are system-wide).
+*/
+   __T("failed count", count >= perf_cpu_map__nr(cpus));
+
+   perf_cpu_map__put(cpus);
+
+   return 0;
+}
+
 int main(int argc, char **argv)
 {
__T_START;
@@ -309,6 +406,7 @@ int main(int argc, char **argv)
test_stat_thread();
test_stat_thread_enable();
test_mmap_thread();
+   test_mmap_cpus();
 
__T_OK;
return 0;
-- 
2.21.0

[PATCH 46/57] libperf: Link static tests with libapi.a

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Both static and dynamic tests needs to link with libapi.a, because it's
using its functions. Also include path for libapi includes.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lore.kernel.org/lkml/20191017105918.20873-5-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/lib/Makefile   | 1 +
 tools/perf/lib/tests/Makefile | 6 +++---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/tools/perf/lib/Makefile b/tools/perf/lib/Makefile
index 0889c9c3ec19..0f233638ef1f 100644
--- a/tools/perf/lib/Makefile
+++ b/tools/perf/lib/Makefile
@@ -107,6 +107,7 @@ else
 endif
 
 LIBAPI = $(API_PATH)libapi.a
+export LIBAPI
 
 $(LIBAPI): FORCE
$(Q)$(MAKE) -C $(LIB_DIR) O=$(OUTPUT) $(OUTPUT)libapi.a
diff --git a/tools/perf/lib/tests/Makefile b/tools/perf/lib/tests/Makefile
index 1ee4e9ba848b..a43cd08c5c03 100644
--- a/tools/perf/lib/tests/Makefile
+++ b/tools/perf/lib/tests/Makefile
@@ -16,13 +16,13 @@ all:
 
 include $(srctree)/tools/scripts/Makefile.include
 
-INCLUDE = -I$(srctree)/tools/perf/lib/include -I$(srctree)/tools/include
+INCLUDE = -I$(srctree)/tools/perf/lib/include -I$(srctree)/tools/include 
-I$(srctree)/tools/lib
 
 $(TESTS_A): FORCE
-   $(QUIET_LINK)$(CC) $(INCLUDE) $(CFLAGS) -o $@ $(subst -a,.c,$@) 
../libperf.a
+   $(QUIET_LINK)$(CC) $(INCLUDE) $(CFLAGS) -o $@ $(subst -a,.c,$@) 
../libperf.a $(LIBAPI)
 
 $(TESTS_SO): FORCE
-   $(QUIET_LINK)$(CC) $(INCLUDE) $(CFLAGS) -L.. -o $@ $(subst -so,.c,$@) 
-lperf
+   $(QUIET_LINK)$(CC) $(INCLUDE) $(CFLAGS) -L.. -o $@ $(subst -so,.c,$@) 
$(LIBAPI) -lperf
 
 all: $(TESTS_A) $(TESTS_SO)
 
-- 
2.21.0

Re: [PATCH v6 01/10] KVM: arm64: Document PV-time interface

[Steven Price]

On 18/10/2019 18:10, Mark Rutland wrote:
> On Tue, Oct 15, 2019 at 06:56:51PM +0100, Mark Rutland wrote:
[...]
>>> +PV_TIME_ST
>>> += ==
>>> +Function ID:  (uint32)0xC521
>>> +Return value: (int64) IPA of the stolen time data structure for 
>>> this
>>> +  VCPU. On failure:
>>> +  NOT_SUPPORTED (-1)
>>> += ==
>>> +
>>> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal 
>>> memory
>>> +with inner and outer write back caching attributes, in the inner shareable
>>> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
>>> +meaningfully filled by the hypervisor (see structure below).
>>
>> At what granularity is this allowed to share IPA space with other
>> mappings? The spec doesn't provide any guidance here, and I strongly
>> suspect that it should.
>>
>> To support a 64K guest, we must ensure that this doesn't share a 64K IPA
>> granule with any MMIO, and it probably only makes sense for an instance
>> of this structure to share that granule with another vCPU's structure.
>>
>> We probably _also_ want to ensure that this doesn't share a 64K granule
>> with memory the guest sees as regular system RAM. Otherwise we're liable
>> to force it into having mismatched attributes for any of that RAM it
>> happens to map as part of mapping the PV_TIME_ST structure.
> 
> I guess we can say that it's userspace's responsibiltiy to set this up
> with sufficient alignment, but I do think we want to make a
> recommendataion here.

I can add something like this to the kernel's documentation:

It is advisable that one or more 64k pages are set aside for the
purpose of these structures and not used for other purposes, this
enables the guest to map the region using 64k pages and avoids
conflicting attributes with other memory.

> [...]
> 
>>> +PV_TIME_ST returns the structure for the calling VCPU.
>>> +
>>> +Stolen Time
>>> +---
>>> +
>>> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
>>> +
>>> ++-+-+-++
>>> +| Field   | Byte Length | Byte Offset | Description|
>>> ++=+=+=++
>>> +| Revision|  4  |  0  | Must be 0 for version 1.0  |
>>> ++-+-+-++
>>> +| Attributes  |  4  |  4  | Must be 0  |
>>> ++-+-+-++
>>> +| Stolen time |  8  |  8  | Stolen time in unsigned|
>>> +| | | | nanoseconds indicating how |
>>> +| | | | much time this VCPU thread |
>>> +| | | | was involuntarily not  |
>>> +| | | | running on a physical CPU. |
>>> ++-+-+-++
>>> +
>>> +All values in the structure are stored little-endian.
>>
>> Looking at the published DEN 0057A, endianness is never stated. Is this
>> going to be corrected in the next release?
> 
> I'm assuming that this has been communicated internally, and we can
> assume the next rev of the spec will state so.

Yes I've fed that back, so hopefully it should be in the next rev of the
spec.

> Assuming so, this looks good to me.

Great, thanks for the review.

Steve

[PATCH 57/57] perf trace: Use STUL_STRARRAY_FLAGS with mmap

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

The 'mmap' syscall has special needs so it doesn't use
SCA_STRARRAY_FLAGS, see its implementation in
syscall_arg__scnprintf_mmap_flags(), related to special handling of
MAP_ANONYMOUS, so set ->parm to the strarray__mmap_flags and hook up
with strarray__strtoul_flags manually, now we can filter by those or-ed
string expressions:

  # perf trace -e syscalls:sys_enter_mmap sleep 1
 0.000 syscalls:sys_enter_mmap(addr: NULL, len: 134346, prot: READ, flags: 
PRIVATE, fd: 3, off: 0)
 0.026 syscalls:sys_enter_mmap(addr: NULL, len: 8192, prot: READ|WRITE, 
flags: PRIVATE|ANONYMOUS)
 0.036 syscalls:sys_enter_mmap(addr: NULL, len: 1857472, prot: READ, flags: 
PRIVATE|DENYWRITE, fd: 3, off: 0)
 0.046 syscalls:sys_enter_mmap(addr: 0x7fae003d9000, len: 1363968, prot: 
READ|EXEC, flags: PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x22000)
 0.052 syscalls:sys_enter_mmap(addr: 0x7fae00526000, len: 311296, prot: 
READ, flags: PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x16f000)
 0.055 syscalls:sys_enter_mmap(addr: 0x7fae00573000, len: 24576, prot: 
READ|WRITE, flags: PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x1bb000)
 0.062 syscalls:sys_enter_mmap(addr: 0x7fae00579000, len: 14272, prot: 
READ|WRITE, flags: PRIVATE|FIXED|ANONYMOUS)
 0.253 syscalls:sys_enter_mmap(addr: NULL, len: 217750512, prot: READ, 
flags: PRIVATE, fd: 3, off: 0)
  #

  # perf trace -e syscalls:sys_enter_mmap 
--filter="flags==PRIVATE|FIXED|DENYWRITE" sleep 1
 0.000 syscalls:sys_enter_mmap(addr: 0x7f6ab3dcb000, len: 1363968, prot: 
READ|EXEC, flags: PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x22000)
 0.010 syscalls:sys_enter_mmap(addr: 0x7f6ab3f18000, len: 311296, prot: 
READ, flags: PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x16f000)
 0.014 syscalls:sys_enter_mmap(addr: 0x7f6ab3f65000, len: 24576, prot: 
READ|WRITE, flags: PRIVATE|FIXED|DENYWRITE, fd: 3, off: 0x1bb000)
  # perf trace -e syscalls:sys_enter_mmap --filter="flags==PRIVATE|ANONYMOUS" 
sleep 1
 0.000 syscalls:sys_enter_mmap(addr: NULL, len: 8192, prot: READ|WRITE, 
flags: PRIVATE|ANONYMOUS)
  #

  # perf trace -v -e syscalls:sys_enter_mmap 
--filter="flags==PRIVATE|ANONYMOUS" sleep 1 |& grep "New filter"
  New filter for syscalls:sys_enter_mmap: flags==0x22
  #

Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: Brendan Gregg 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-czw754b7m9rp9ibq2f6be...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 7bb84c4a8f29..43c05eae1768 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -1015,7 +1015,9 @@ static struct syscall_fmt syscall_fmts[] = {
.alias = "old_mmap",
 #endif
  .arg = { [2] = { .scnprintf = SCA_MMAP_PROT,  /* prot */ },
-  [3] = { .scnprintf = SCA_MMAP_FLAGS, /* flags */ },
+  [3] = { .scnprintf = SCA_MMAP_FLAGS, /* flags */
+  .strtoul   = STUL_STRARRAY_FLAGS,
+  .parm  = __mmap_flags, },
   [5] = { .scnprintf = SCA_HEX,/* offset */ }, }, },
{ .name = "mount",
  .arg = { [0] = { .scnprintf = SCA_FILENAME, /* dev_name */ },
-- 
2.21.0

[PATCH 39/57] perf list: Hide deprecated events by default

[Arnaldo Carvalho de Melo]

From: Jin Yao 

There are some deprecated events listed by perf list. But we can't
remove them from perf list with ease because some old scripts may use
them.

Deprecated events are old names of renamed events.  When an event gets
renamed the old name is kept around for some time and marked with
Deprecated. The newer Intel event lists in the tree already have these
headers.

So we need to keep them in the event list, but provide a new option to
show them. The new option is "--deprecated".

With this patch, the deprecated events are hidden by default but they
can be displayed when option "--deprecated" is enabled.

Signed-off-by: Jin Yao 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Kan Liang 
Cc: Peter Zijlstra 
Link: http://lore.kernel.org/lkml/20191015025357.8708-1-yao@linux.intel.com
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Documentation/perf-list.txt |  3 +++
 tools/perf/builtin-list.c  | 14 ++
 tools/perf/pmu-events/jevents.c| 26 --
 tools/perf/pmu-events/jevents.h|  3 ++-
 tools/perf/pmu-events/pmu-events.h |  1 +
 tools/perf/util/parse-events.c |  4 ++--
 tools/perf/util/parse-events.h |  2 +-
 tools/perf/util/pmu.c  | 17 +
 tools/perf/util/pmu.h  |  4 +++-
 9 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index 18ed1b0fceb3..6345db33c533 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -36,6 +36,9 @@ Enable debugging output.
 Print how named events are resolved internally into perf events, and also
 any extra expressions computed by perf stat.
 
+--deprecated::
+Print deprecated events. By default the deprecated events are hidden.
+
 [[EVENT_MODIFIERS]]
 EVENT MODIFIERS
 ---
diff --git a/tools/perf/builtin-list.c b/tools/perf/builtin-list.c
index 08e62ae9d37e..965ef017496f 100644
--- a/tools/perf/builtin-list.c
+++ b/tools/perf/builtin-list.c
@@ -26,6 +26,7 @@ int cmd_list(int argc, const char **argv)
int i;
bool raw_dump = false;
bool long_desc_flag = false;
+   bool deprecated = false;
struct option list_options[] = {
OPT_BOOLEAN(0, "raw-dump", _dump, "Dump raw events"),
OPT_BOOLEAN('d', "desc", _flag,
@@ -34,6 +35,8 @@ int cmd_list(int argc, const char **argv)
"Print longer event descriptions."),
OPT_BOOLEAN(0, "details", _flag,
"Print information on the perf event names and 
expressions used internally by events."),
+   OPT_BOOLEAN(0, "deprecated", ,
+   "Print deprecated events."),
OPT_INCR(0, "debug", ,
 "Enable debugging output"),
OPT_END()
@@ -55,7 +58,7 @@ int cmd_list(int argc, const char **argv)
 
if (argc == 0) {
print_events(NULL, raw_dump, !desc_flag, long_desc_flag,
-   details_flag);
+   details_flag, deprecated);
return 0;
}
 
@@ -78,7 +81,8 @@ int cmd_list(int argc, const char **argv)
print_hwcache_events(NULL, raw_dump);
else if (strcmp(argv[i], "pmu") == 0)
print_pmu_events(NULL, raw_dump, !desc_flag,
-   long_desc_flag, details_flag);
+   long_desc_flag, details_flag,
+   deprecated);
else if (strcmp(argv[i], "sdt") == 0)
print_sdt_events(NULL, NULL, raw_dump);
else if (strcmp(argv[i], "metric") == 0 || strcmp(argv[i], 
"metrics") == 0)
@@ -91,7 +95,8 @@ int cmd_list(int argc, const char **argv)
if (sep == NULL) {
print_events(argv[i], raw_dump, !desc_flag,
long_desc_flag,
-   details_flag);
+   details_flag,
+   deprecated);
continue;
}
sep_idx = sep - argv[i];
@@ -117,7 +122,8 @@ int cmd_list(int argc, const char **argv)
print_hwcache_events(s, raw_dump);
print_pmu_events(s, raw_dump, !desc_flag,
long_desc_flag,
-   details_flag);
+   details_flag,
+   deprecated);

[PATCH 38/57] perf trace: Pass a syscall_arg to syscall_arg_fmt->strtoul()

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

With just what we need for the STUL_STRARRAY, i.e. the 'struct strarray'
pointer to be used, just like with syscall_arg_fmt->scnprintf() for the
other direction (number -> string).

With this all the strarrays that are associated with syscalls can be
used with '-e syscalls:sys_enter_SYSCALLNAME --filter', and soon will be
possible as well to use with the strace-like shorter form, with just the
syscall names, i.e. something like:

   -e lseek/whence==END/

For now we have to use the longer form:

# perf trace -e syscalls:sys_enter_lseek
   0.000 pool/2242 syscalls:sys_enter_lseek(fd: 14, 
offset: 0, whence: CUR)
   0.031 pool/2242 syscalls:sys_enter_lseek(fd: 15, 
offset: 0, whence: CUR)
   0.046 pool/2242 syscalls:sys_enter_lseek(fd: 16, 
offset: 0, whence: CUR)
5003.528 pool/2242 syscalls:sys_enter_lseek(fd: 14, 
offset: 0, whence: CUR)
5003.575 pool/2242 syscalls:sys_enter_lseek(fd: 15, 
offset: 0, whence: CUR)
5003.593 pool/2242 syscalls:sys_enter_lseek(fd: 16, 
offset: 0, whence: CUR)
   10002.017 pool/2242 syscalls:sys_enter_lseek(fd: 14, 
offset: 0, whence: CUR)
   10002.051 pool/2242 syscalls:sys_enter_lseek(fd: 15, 
offset: 0, whence: CUR)
   10002.068 pool/2242 syscalls:sys_enter_lseek(fd: 16, 
offset: 0, whence: CUR)
  ^C# perf trace -e syscalls:sys_enter_lseek --filter="whence!=CUR"
   0.000 sshd/24476 syscalls:sys_enter_lseek(fd: 3, offset: 9032, whence: 
SET)
   0.060 sshd/24476 syscalls:sys_enter_lseek(fd: 
3, offset: 9032, whence: SET)
   0.187 sshd/24476 syscalls:sys_enter_lseek(fd: 
3, offset: 118632, whence: SET)
   0.203 sshd/24476 syscalls:sys_enter_lseek(fd: 
3, offset: 118632, whence: SET)
   0.349 sshd/24476 syscalls:sys_enter_lseek(fd: 
3, offset: 61936, whence: SET)
  ^C#

And for those curious about what are those lseek(DSO, offset, SET), well, its 
the loader:

  # perf trace -e syscalls:sys_enter_lseek/max-stack=16/ --filter="whence!=CUR"
 0.000 sshd/24495 syscalls:sys_enter_lseek(fd: 
3, offset: 9032, whence: SET)
   __libc_lseek64 (/usr/lib64/ld-2.29.so)
   _dl_map_object (/usr/lib64/ld-2.29.so)
 0.067 sshd/24495 syscalls:sys_enter_lseek(fd: 
3, offset: 9032, whence: SET)
   __libc_lseek64 (/usr/lib64/ld-2.29.so)
   _dl_map_object_from_fd 
(/usr/lib64/ld-2.29.so)
   _dl_map_object (/usr/lib64/ld-2.29.so)
 0.198 sshd/24495 syscalls:sys_enter_lseek(fd: 
3, offset: 118632, whence: SET)
   __libc_lseek64 (/usr/lib64/ld-2.29.so)
   _dl_map_object (/usr/lib64/ld-2.29.so)
 0.219 sshd/24495 syscalls:sys_enter_lseek(fd: 
3, offset: 118632, whence: SET)
   __libc_lseek64 (/usr/lib64/ld-2.29.so)
   _dl_map_object_from_fd 
(/usr/lib64/ld-2.29.so)
   _dl_map_object (/usr/lib64/ld-2.29.so)
  ^C#

:-)

With this we can use strings in strarrays in filters, which allows us to
reuse all these that are in place for syscalls:

  $ find tools/perf/trace/beauty/ -name "*.c" | xargs grep -w DEFINE_STRARRAY
  tools/perf/trace/beauty/fcntl.c:  static DEFINE_STRARRAY(fcntl_setlease, 
"F_");
  tools/perf/trace/beauty/mmap.c:   static DEFINE_STRARRAY(mmap_flags, 
"MAP_");
  tools/perf/trace/beauty/mmap.c:   static DEFINE_STRARRAY(madvise_advices, 
"MADV_");
  tools/perf/trace/beauty/sync_file_range.c:   static 
DEFINE_STRARRAY(sync_file_range_flags, "SYNC_FILE_RANGE_");
  tools/perf/trace/beauty/socket.c: static DEFINE_STRARRAY(socket_ipproto, 
"IPPROTO_");
  tools/perf/trace/beauty/mount_flags.c:static 
DEFINE_STRARRAY(mount_flags, "MS_");
  tools/perf/trace/beauty/pkey_alloc.c: static 
DEFINE_STRARRAY(pkey_alloc_access_rights, "PKEY_");
  tools/perf/trace/beauty/sockaddr.c:DEFINE_STRARRAY(socket_families, "PF_");
  tools/perf/trace/beauty/tracepoints/x86_irq_vectors.c:static 
DEFINE_STRARRAY(x86_irq_vectors, "_VECTOR");
  tools/perf/trace/beauty/tracepoints/x86_msr.c:static 
DEFINE_STRARRAY(x86_MSRs, "MSR_");
  tools/perf/trace/beauty/prctl.c:  static DEFINE_STRARRAY(prctl_options, 
"PR_");
  tools/perf/trace/beauty/prctl.c:  static 
DEFINE_STRARRAY(prctl_set_mm_options, "PR_SET_MM_");
  tools/perf/trace/beauty/fspick.c:   static DEFINE_STRARRAY(fspick_flags, 
"FSPICK_");
  tools/perf/trace/beauty/ioctl.c:  static DEFINE_STRARRAY(ioctl_tty_cmd, 
"");
  tools/perf/trace/beauty/ioctl.c:  static DEFINE_STRARRAY(drm_ioctl_cmds, 
"");
  tools/perf/trace/beauty/ioctl.c:  static 
DEFINE_STRARRAY(sndrv_pcm_ioctl_cmds, "");
  tools/perf/trace/beauty/ioctl.c:  static 
DEFINE_STRARRAY(sndrv_ctl_ioctl_cmds, "");
  tools/perf/trace/beauty/ioctl.c:  static DEFINE_STRARRAY(kvm_ioctl_cmds, 
"");
  

[PATCH 53/57] perf trace: Use strtoul for the fcntl 'cmd' argument

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Since its values are in two ranges of values we ended up codifying it
using a 'struct strarrays', so now hook it up with STUL_STRARRAYS so
that we can do:

  # perf trace -e syscalls:*enter_fcntl --filter=cmd==SETLK||cmd==SETLKW
 0.000 sssd_kcm/19021 syscalls:sys_enter_fcntl(fd: 
13, cmd: SETLK, arg: 0x7ffcf0a4dee0)
 1.523 sssd_kcm/19021 syscalls:sys_enter_fcntl(fd: 
13, cmd: SETLK, arg: 0x7ffcf0a4de90)
 1.629 sssd_kcm/19021 syscalls:sys_enter_fcntl(fd: 
13, cmd: SETLK, arg: 0x7ffcf0a4de90)
 2.711 sssd_kcm/19021 syscalls:sys_enter_fcntl(fd: 
13, cmd: SETLK, arg: 0x7ffcf0a4de70)
  ^C#

Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: Brendan Gregg 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-mob96wyzri4r3rvyigqfj...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 265ea876f00b..72ef3b395504 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -894,7 +894,8 @@ static struct syscall_fmt syscall_fmts[] = {
{ .name = "fchownat",
  .arg = { [0] = { .scnprintf = SCA_FDAT, /* fd */ }, }, },
{ .name = "fcntl",
- .arg = { [1] = { .scnprintf = SCA_FCNTL_CMD, /* cmd */
+ .arg = { [1] = { .scnprintf = SCA_FCNTL_CMD,  /* cmd */
+  .strtoul   = STUL_STRARRAYS,
   .parm  = __fcntl_cmds_arrays,
   .show_zero = true, },
   [2] = { .scnprintf =  SCA_FCNTL_ARG, /* arg */ }, }, },
-- 
2.21.0

Re: [PATCH 2/3] watchdog/softlockup: Report the same softlockup regularly

[Petr Mladek]

On Mon 2019-10-21 14:43:39, Peter Zijlstra wrote:
> On Mon, Aug 19, 2019 at 12:47:31PM +0200, Petr Mladek wrote:
> > Softlockup report means that there is no progress on the given CPU. It
> > might be a "short" affair where the system gets recovered. But often
> > the system stops being responsive and need to get rebooted.
> > 
> > The softlockup might be root of the problems or just a symptom. It might
> > be a deadlock, livelock, or often repeated state.
> > 
> > Regular reports help to distinguish different situations. Fortunately,
> > the watchdog is finally able to show correct information how long
> > softlockup_fn() was not scheduled.
> > 
> > Report before this patch:
> > 
> > [  320.248948] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [cat:4916]
> > 
> > And after this patch:
> > 
> > [  480.372418] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [cat:4943]
> > [  508.372359] watchdog: BUG: soft lockup - CPU#2 stuck for 52s! [cat:4943]
> > [  548.372359] watchdog: BUG: soft lockup - CPU#2 stuck for 89s! [cat:4943]
> > [  576.372351] watchdog: BUG: soft lockup - CPU#2 stuck for 115s! [cat:4943]
> > 
> > Note that the horrible code never really worked before the accounting
> > was fixed. The last working timestamp was regularly lost by the many
> > touch*watchdog() calls.
> 
> So what's the point of patch 1? Just confusing people?

I was not sure what was the expected behavior. The code actually
looked like only the first report was wanted. But it probably never
worked that way.

Should I squash the two patches and send it again, please?

Best Regards,
Petr

[PATCH 40/57] perf tests: Remove needless headers for bp_account

[Arnaldo Carvalho de Melo]

From: Leo Yan 

A few headers are not needed and were introduced by copying from other
test file.  This patch removes the needless headers for the breakpoint
accounting testing.

Signed-off-by: Leo Yan 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Brajeswar Ghosh 
Cc: Florian Fainelli 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Song Liu 
Cc: Souptick Joarder 
Cc: Will Deacon 
Link: http://lore.kernel.org/lkml/20191018085531.6348-1-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/bp_account.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/tools/perf/tests/bp_account.c b/tools/perf/tests/bp_account.c
index 016bba2c142d..52ff7a462670 100644
--- a/tools/perf/tests/bp_account.c
+++ b/tools/perf/tests/bp_account.c
@@ -10,11 +10,7 @@
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 
 
 #include "tests.h"
-- 
2.21.0

[PATCH 41/57] perf tests bp_account: Add dedicated checking helper is_supported()

[Arnaldo Carvalho de Melo]

From: Leo Yan 

The arm architecture supports breakpoint accounting but it doesn't
support breakpoint overflow signal handling.  The current code uses the
same checking helper, thus it disables both testings (bp_account and
bp_signal) for arm platform.

For handling two testings separately, this patch adds a dedicated
checking helper is_supported() for breakpoint accounting testing, thus
it allows supporting breakpoint accounting testing on arm platform; the
old helper test__bp_signal_is_supported() is only used to checking for
breakpoint overflow signal testing.

Signed-off-by: Leo Yan 
Cc: Adrian Hunter 
Cc: Alexander Shishkin 
Cc: Brajeswar Ghosh 
Cc: Florian Fainelli 
Cc: Jiri Olsa 
Cc: Mark Rutland 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Song Liu 
Cc: Souptick Joarder 
Cc: Will Deacon 
Link: http://lore.kernel.org/lkml/20191018085531.6348-2-leo@linaro.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/bp_account.c   | 16 
 tools/perf/tests/builtin-test.c |  2 +-
 tools/perf/tests/tests.h|  1 +
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/bp_account.c b/tools/perf/tests/bp_account.c
index 52ff7a462670..d0b935356274 100644
--- a/tools/perf/tests/bp_account.c
+++ b/tools/perf/tests/bp_account.c
@@ -188,3 +188,19 @@ int test__bp_accounting(struct test *test __maybe_unused, 
int subtest __maybe_un
 
return bp_accounting(wp_cnt, share);
 }
+
+bool test__bp_account_is_supported(void)
+{
+   /*
+* PowerPC and S390 do not support creation of instruction
+* breakpoints using the perf_event interface.
+*
+* Just disable the test for these architectures until these
+* issues are resolved.
+*/
+#if defined(__powerpc__) || defined(__s390x__)
+   return false;
+#else
+   return true;
+#endif
+}
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index 55774baffc2a..8b286e9b7549 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -121,7 +121,7 @@ static struct test generic_tests[] = {
{
.desc = "Breakpoint accounting",
.func = test__bp_accounting,
-   .is_supported = test__bp_signal_is_supported,
+   .is_supported = test__bp_account_is_supported,
},
{
.desc = "Watchpoint",
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 72912eb473cb..9837b6e93023 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -111,6 +111,7 @@ int test__map_groups__merge_in(struct test *t, int subtest);
 int test__time_utils(struct test *t, int subtest);
 
 bool test__bp_signal_is_supported(void);
+bool test__bp_account_is_supported(void);
 bool test__wp_is_supported(void);
 
 #if defined(__arm__) || defined(__aarch64__)
-- 
2.21.0

[PATCH 55/57] libbeauty: Introduce strarray__strtoul_flags()

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Counterpart of strarray__scnprintf_flags(), i.e. from a expression like:

   # perf trace -e syscalls:sys_enter_mmap 
--filter="flags==PRIVATE|FIXED|DENYWRITE"

I.e. that "flags==PRIVATE|FIXED|DENYWRITE", turn that into

   # perf trace -e syscalls:sys_enter_mmap --filter=0x812

Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: Brendan Gregg 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-8xst3zrqqogax7fmfzwym...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c   | 45 +++-
 tools/perf/trace/beauty/beauty.h |  1 +
 2 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 72ef3b395504..73c5c14b52eb 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -586,6 +586,49 @@ bool strarray__strtoul(struct strarray *sa, char *bf, 
size_t size, u64 *ret)
return false;
 }
 
+bool strarray__strtoul_flags(struct strarray *sa, char *bf, size_t size, u64 
*ret)
+{
+   u64 val = 0;
+   char *tok = bf, *sep, *end;
+
+   *ret = 0;
+
+   while (size != 0) {
+   int toklen = size;
+
+   sep = memchr(tok, '|', size);
+   if (sep != NULL) {
+   size -= sep - tok + 1;
+
+   end = sep - 1;
+   while (end > tok && isspace(*end))
+   --end;
+
+   toklen = end - tok + 1;
+   }
+
+   while (isspace(*tok))
+   ++tok;
+
+   if (isalpha(*tok) || *tok == '_') {
+   if (!strarray__strtoul(sa, tok, toklen, ))
+   return false;
+   } else {
+   bool is_hexa = tok[0] == 0 && (tok[1] = 'x' || tok[1] 
== 'X');
+
+   val = strtoul(tok, NULL, is_hexa ? 16 : 0);
+   }
+
+   *ret |= (1 << (val - 1));
+
+   if (sep == NULL)
+   break;
+   tok = sep + 1;
+   }
+
+   return true;
+}
+
 bool strarrays__strtoul(struct strarrays *sas, char *bf, size_t size, u64 *ret)
 {
int i;
@@ -3676,7 +3719,7 @@ static int trace__expand_filter(struct trace *trace 
__maybe_unused, struct evsel
}
 
right_end = right + 1;
-   while (isalnum(*right_end) || *right_end == '_')
+   while (isalnum(*right_end) || *right_end == '_' || *right_end 
== '|')
++right_end;
 
if (isalpha(*right)) {
diff --git a/tools/perf/trace/beauty/beauty.h b/tools/perf/trace/beauty/beauty.h
index 10801660a71f..e12b2228b892 100644
--- a/tools/perf/trace/beauty/beauty.h
+++ b/tools/perf/trace/beauty/beauty.h
@@ -32,6 +32,7 @@ size_t strarray__scnprintf_suffix(struct strarray *sa, char 
*bf, size_t size, co
 size_t strarray__scnprintf_flags(struct strarray *sa, char *bf, size_t size, 
bool show_prefix, unsigned long flags);
 
 bool strarray__strtoul(struct strarray *sa, char *bf, size_t size, u64 *ret);
+bool strarray__strtoul_flags(struct strarray *sa, char *bf, size_t size, u64 
*ret);
 
 struct trace;
 struct thread;
-- 
2.21.0

Re: [PATCH v4] perf record: Add support for limit perf output file size

[Jiri Olsa]

On Wed, Sep 25, 2019 at 03:06:37PM +0800, Jiwei Sun wrote:

SNIP

>  SEE ALSO
>  
>  linkperf:perf-stat[1], linkperf:perf-list[1]
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index 48600c90cc7e..30904d2a3407 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -91,6 +91,7 @@ struct record {
>   struct switch_outputswitch_output;
>   unsigned long long  samples;
>   cpu_set_t   affinity_mask;
> + unsigned long   output_max_size;/* = 0: unlimited */
>  };
>  
>  static volatile int auxtrace_record__snapshot_started;
> @@ -120,6 +121,12 @@ static bool switch_output_time(struct record *rec)
>  trigger_is_ready(_output_trigger);
>  }
>  
> +static bool record__output_max_size_exceeded(struct record *rec)
> +{
> + return rec->output_max_size &&
> +(rec->bytes_written >= rec->output_max_size);
> +}
> +
>  static int record__write(struct record *rec, struct mmap *map __maybe_unused,
>void *bf, size_t size)
>  {
> @@ -132,6 +139,12 @@ static int record__write(struct record *rec, struct mmap 
> *map __maybe_unused,
>  
>   rec->bytes_written += size;
>  
> + if (record__output_max_size_exceeded(rec)) {
> + WARN_ONCE(1, "WARNING: The perf data has already reached "
> +  "the limit, stop recording!\n");

I think the message whouldn't be a warning, the user asked for
that, maybe something more like:

  [ perf record: perf size limit reached (XXMB), stopping session ]

> + raise(SIGTERM);

could we just set 'done = 1' what's the benefit in killing perf?

thanks,
jirka

[PATCH 47/57] libperf: Add tests_mmap_thread test

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add mmaping tests that generates 100 prctl calls in monitored child
process and validates it gets 100 events in ring buffer.

Committer tests:

  # make -C tools/perf/lib tests
  make: Entering directory '/home/acme/git/perf/tools/perf/lib'
LINK test-cpumap-a
LINK test-threadmap-a
LINK test-evlist-a
LINK test-evsel-a
LINK test-cpumap-so
LINK test-threadmap-so
LINK test-evlist-so
LINK test-evsel-so
  running static:
  - running test-cpumap.c...OK
  - running test-threadmap.c...OK
  - running test-evlist.c...OK
  - running test-evsel.c...OK
  running dynamic:
  - running test-cpumap.c...OK
  - running test-threadmap.c...OK
  - running test-evlist.c...OK
  - running test-evsel.c...OK
  make: Leaving directory '/home/acme/git/perf/tools/perf/lib'
  #

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexander Shishkin 
Cc: Alexey Budankov 
Cc: Andi Kleen 
Cc: Jin Yao 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Cc: Stephane Eranian 
Link: http://lore.kernel.org/lkml/20191017105918.20873-7-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/lib/tests/test-evlist.c | 119 +
 1 file changed, 119 insertions(+)

diff --git a/tools/perf/lib/tests/test-evlist.c 
b/tools/perf/lib/tests/test-evlist.c
index e6b2ab2e2bde..90a1869ba4b1 100644
--- a/tools/perf/lib/tests/test-evlist.c
+++ b/tools/perf/lib/tests/test-evlist.c
@@ -1,12 +1,21 @@
 // SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
+#include 
 
 static int libperf_print(enum libperf_print_level level,
 const char *fmt, va_list ap)
@@ -181,6 +190,115 @@ static int test_stat_thread_enable(void)
return 0;
 }
 
+static int test_mmap_thread(void)
+{
+   struct perf_evlist *evlist;
+   struct perf_evsel *evsel;
+   struct perf_mmap *map;
+   struct perf_cpu_map *cpus;
+   struct perf_thread_map *threads;
+   struct perf_event_attr attr = {
+   .type = PERF_TYPE_TRACEPOINT,
+   .sample_period= 1,
+   .wakeup_watermark = 1,
+   .disabled = 1,
+   };
+   char path[PATH_MAX];
+   int id, err, pid, go_pipe[2];
+   union perf_event *event;
+   char bf;
+   int count = 0;
+
+   snprintf(path, PATH_MAX, 
"%s/kernel/debug/tracing/events/syscalls/sys_enter_prctl/id",
+sysfs__mountpoint());
+
+   if (filename__read_int(path, )) {
+   fprintf(stderr, "error: failed to get tracepoint id: %s\n", 
path);
+   return -1;
+   }
+
+   attr.config = id;
+
+   err = pipe(go_pipe);
+   __T("failed to create pipe", err == 0);
+
+   fflush(NULL);
+
+   pid = fork();
+   if (!pid) {
+   int i;
+
+   read(go_pipe[0], , 1);
+
+   /* Generate 100 prctl calls. */
+   for (i = 0; i < 100; i++)
+   prctl(0, 0, 0, 0, 0);
+
+   exit(0);
+   }
+
+   threads = perf_thread_map__new_dummy();
+   __T("failed to create threads", threads);
+
+   cpus = perf_cpu_map__dummy_new();
+   __T("failed to create cpus", cpus);
+
+   perf_thread_map__set_pid(threads, 0, pid);
+
+   evlist = perf_evlist__new();
+   __T("failed to create evlist", evlist);
+
+   evsel = perf_evsel__new();
+   __T("failed to create evsel1", evsel);
+
+   perf_evlist__add(evlist, evsel);
+
+   perf_evlist__set_maps(evlist, cpus, threads);
+
+   err = perf_evlist__open(evlist);
+   __T("failed to open evlist", err == 0);
+
+   err = perf_evlist__mmap(evlist, 4);
+   __T("failed to mmap evlist", err == 0);
+
+   perf_evlist__enable(evlist);
+
+   /* kick the child and wait for it to finish */
+   write(go_pipe[1], , 1);
+   waitpid(pid, NULL, 0);
+
+   /*
+* There's no need to call perf_evlist__disable,
+* monitored process is dead now.
+*/
+
+   perf_evlist__for_each_mmap(evlist, map, false) {
+   if (perf_mmap__read_init(map) < 0)
+   continue;
+
+   while ((event = perf_mmap__read_event(map)) != NULL) {
+   count++;
+   perf_mmap__consume(map);
+   }
+
+   perf_mmap__read_done(map);
+   }
+
+   /* calls perf_evlist__munmap/perf_evlist__close */
+   perf_evlist__delete(evlist);
+
+   perf_thread_map__put(threads);
+   perf_cpu_map__put(cpus);
+
+   /*
+* The generated prctl calls should match the
+* number of events in the buffer.
+*/
+   __T("failed count", count == 100);
+
+   return 0;
+}
+
 int main(int argc, char **argv)
 {
__T_START;

[PATCH 56/57] perf trace: Wire up strarray__strtoul_flags()

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

Now anything that uses STRARRAY_FLAGS, like the 'fsmount' syscall will
support mapping or-ed strings back to a value that can be used in a
filter.

In some cases, where STRARRAY_FLAGS isn't used but instead the scnprintf
is a special one because of specific needs, like for mmap, then one has
to set the ->pars to the strarray. See the next cset.

Cc: Adrian Hunter 
Cc: Andi Kleen 
Cc: Brendan Gregg 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-r2lpqo7dfsrhi4ll0npsb...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/builtin-trace.c   | 6 ++
 tools/perf/trace/beauty/beauty.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
index 73c5c14b52eb..7bb84c4a8f29 100644
--- a/tools/perf/builtin-trace.c
+++ b/tools/perf/builtin-trace.c
@@ -540,6 +540,11 @@ bool syscall_arg__strtoul_strarray(char *bf, size_t size, 
struct syscall_arg *ar
return strarray__strtoul(arg->parm, bf, size, ret);
 }
 
+bool syscall_arg__strtoul_strarray_flags(char *bf, size_t size, struct 
syscall_arg *arg, u64 *ret)
+{
+   return strarray__strtoul_flags(arg->parm, bf, size, ret);
+}
+
 bool syscall_arg__strtoul_strarrays(char *bf, size_t size, struct syscall_arg 
*arg, u64 *ret)
 {
return strarrays__strtoul(arg->parm, bf, size, ret);
@@ -882,6 +887,7 @@ static size_t syscall_arg__scnprintf_getrandom_flags(char 
*bf, size_t size,
 
 #define STRARRAY_FLAGS(name, array) \
  { .scnprintf  = SCA_STRARRAY_FLAGS, \
+   .strtoul= STUL_STRARRAY_FLAGS, \
.parm   = __##array, }
 
 #include "trace/beauty/arch_errno_names.c"
diff --git a/tools/perf/trace/beauty/beauty.h b/tools/perf/trace/beauty/beauty.h
index e12b2228b892..5a61043c2ff7 100644
--- a/tools/perf/trace/beauty/beauty.h
+++ b/tools/perf/trace/beauty/beauty.h
@@ -126,6 +126,9 @@ size_t syscall_arg__scnprintf_strarray_flags(char *bf, 
size_t size, struct sysca
 bool syscall_arg__strtoul_strarray(char *bf, size_t size, struct syscall_arg 
*arg, u64 *ret);
 #define STUL_STRARRAY syscall_arg__strtoul_strarray
 
+bool syscall_arg__strtoul_strarray_flags(char *bf, size_t size, struct 
syscall_arg *arg, u64 *ret);
+#define STUL_STRARRAY_FLAGS syscall_arg__strtoul_strarray_flags
+
 bool syscall_arg__strtoul_strarrays(char *bf, size_t size, struct syscall_arg 
*arg, u64 *ret);
 #define STUL_STRARRAYS syscall_arg__strtoul_strarrays
 
-- 
2.21.0

[PATCH 54/57] libbeauty: Make the mmap_flags strarray visible outside of its beautifier

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

So that we can later use it with the strarray__strtoul_flags() routine
that will be soon introduced.

Cc: Adrian Hunter 
Cc: Jiri Olsa 
Cc: Luis Cláudio Gonçalves 
Cc: Namhyung Kim 
Link: https://lkml.kernel.org/n/tip-vldj3ch8su6i20to5eq31...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/trace/beauty/mmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/trace/beauty/mmap.c b/tools/perf/trace/beauty/mmap.c
index 859a8a9db2c6..9fa771a90d79 100644
--- a/tools/perf/trace/beauty/mmap.c
+++ b/tools/perf/trace/beauty/mmap.c
@@ -33,11 +33,11 @@ static size_t syscall_arg__scnprintf_mmap_prot(char *bf, 
size_t size,
 
 #define SCA_MMAP_PROT syscall_arg__scnprintf_mmap_prot
 
-static size_t mmap__scnprintf_flags(unsigned long flags, char *bf, size_t 
size, bool show_prefix)
-{
 #include "trace/beauty/generated/mmap_flags_array.c"
static DEFINE_STRARRAY(mmap_flags, "MAP_");
 
+static size_t mmap__scnprintf_flags(unsigned long flags, char *bf, size_t 
size, bool show_prefix)
+{
return strarray__scnprintf_flags(__mmap_flags, bf, size, 
show_prefix, flags);
 }
 
-- 
2.21.0