Re: [PATCH] sparc32: register memory occupied by kernel as memblock.memory

2020-05-26 Thread David Miller
From: Mike Rapoport 
Date: Wed, 27 May 2020 07:52:19 +0300

> Andrew, David,
> 
> Any comments on this?

No objections from me:

Acked-by: David S. Miller 


Re: [PATCH 0/2] Bugy bootloader woraround

2020-05-26 Thread Jiaxun Yang
On Wed, 27 May 2020 13:27:17 +0800
Jiaxun Yang  wrote:

> Jiaxun Yang (2):
>   MIPS: head.S: Always jump to kernel_entry at head of text
>   MIPS: Loongso64: select NO_EXCEPT_FILL

Please ignore the noise.
Something went wrong with my keyboard...

> 
>  arch/mips/Kconfig   | 1 +
>  arch/mips/kernel/head.S | 2 --
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 



Re: [RFC PATCH] gpio: uapi: v2 proposal

2020-05-26 Thread Linus Walleij
On Mon, May 25, 2020 at 4:19 PM Kent Gibson  wrote:

> > > +struct gpioline_config {
> > > +   __u8 default_values[GPIOLINES_MAX];
> >
> > So 32 bytes
> >
>
> Actually that one is 64 bytes, which is the same as v1, i.e. GPIOLINES_MAX
> is the same as GPIOHANDLES_MAX - just renamed.
>
> On the subject of values, is there any reason to use a byte for each line
> rather value than a bit?

Not really, other than making things simple for userspace.

> when adding future fields, the idea was to have a bit
> in the flags that indicates that the corresponding field is now valid.
> If the flag is not set then whatever value is there is irrelevant.

You would need to document that idea, say in the kerneldoc,
else when someone else comes along to do this they will
get it wrong.

> But definitely better to play it safe - will check the padding is
> zeroed as well, as well as any field for which the flag bit is clear.

Yeah better like that. You can write a comment in the code too,
such like "when adding new parameters, update this validation code
to accept it".

> Back on retired ioctls, I notice that 5, 6, and 7 are missing from gpio.
> Have those been retired, or just skipped over by accident?

Just thought it was nice to use jump to 8 for line info.
They should be used when adding generic chip information ioctls().

Yours,
Linus Walleij


Re: [PATCH v1 2/5] clk: Introduce clk_round_rate_unboundly()

2020-05-26 Thread Stephen Boyd
Quoting Dmitry Osipenko (2020-03-30 16:16:14)
> In same cases it may be desired to round clock's rate without taking into
> account current min/max requests made by the clock's users. One example is
> building up OPP table based on a possible clock rates.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/clk/clk.c   | 49 +++--
>  include/linux/clk.h | 18 +

BTW, please run get_maintainers.pl patches. Russell maintains
include/linux/clk.h (the clk API). CCF implements it.


Re: [PATCH V4 6/8] fs/ext4: Make DAX mount option a tri-state

2020-05-26 Thread Xiao Yang
On 2020/5/22 3:13, ira.we...@intel.com wrote:
> From: Ira Weiny
> 
> We add 'always', 'never', and 'inode' (default).  '-o dax' continues to
> operate the same which is equivalent to 'always'.  This new
> functionality is limited to ext4 only.
> 
> Specifically we introduce a 2nd DAX mount flag EXT4_MOUNT2_DAX_NEVER and set
> it and EXT4_MOUNT_DAX_ALWAYS appropriately for the mode.
> 
> We also force EXT4_MOUNT2_DAX_NEVER if !CONFIG_FS_DAX.
> 
> Finally, EXT4_MOUNT2_DAX_INODE is used solely to detect if the user
> specified that option for printing.
Hi Ira,

I have two questions when reviewing this patch:
1) After doing mount with the same dax=inode option, ext4/xfs shows
differnt output(i.e. xfs doesn't print 'dax=inode'):
---
# mount -o dax=inode /dev/pmem0 /mnt/xfstests/test/
# mount | grep pmem0
/dev/pmem0 on /mnt/xfstests/test type ext4 (rw,relatime,seclabel,dax=inode)

# mount -odax=inode /dev/pmem1 /mnt/xfstests/scratch/
# mount | grep pmem1
/dev/pmem1 on /mnt/xfstests/scratch type xfs
(rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,noquota)

Is this expected output? why don't unify the output?

2) Do mount without dax and mount with -odax=inode have the same behavior?
---
# mount /dev/pmem0 /mnt/xfstests/test/
# mount | grep pmem0
/dev/pmem0 on /mnt/xfstests/test type ext4 (rw,relatime,seclabel)
# umount /mnt/xfstests/test
# mount -odax=inode /dev/pmem0 /mnt/xfstests/test/
# mount | grep pmem0
/dev/pmem0 on /mnt/xfstests/test type ext4 (rw,relatime,seclabel,dax=inode
---

BTW: I focus on the support of per-file/directory DAX operations recently.

> 
> Reviewed-by: Jan Kara
> Signed-off-by: Ira Weiny
> 
> ---
> Changes from V1:
>   Fix up mounting options to only show an option if specified
>   Fix remount to prevent dax changes
>   Isolate behavior to ext4 only
> 
> Changes from RFC:
>   Combine remount check for DAX_NEVER with DAX_ALWAYS
>   Update ext4_should_enable_dax()
> ---
>   fs/ext4/ext4.h  |  2 ++
>   fs/ext4/inode.c |  2 ++
>   fs/ext4/super.c | 67 +
>   3 files changed, 61 insertions(+), 10 deletions(-)
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index f5291693ce6e..65ffb831b2b9 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1168,6 +1168,8 @@ struct ext4_inode_info {
> blocks */
>   #define EXT4_MOUNT2_HURD_COMPAT 0x0004 /* Support 
> HURD-castrated
> file systems */
> +#define EXT4_MOUNT2_DAX_NEVER0x0008 /* Do not allow 
> Direct Access */
> +#define EXT4_MOUNT2_DAX_INODE0x0010 /* For printing 
> options only */
> 
>   #define EXT4_MOUNT2_EXPLICIT_JOURNAL_CHECKSUM   0x0008 /* User 
> explicitly
>   specified journal checksum */
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 01636cf5f322..68fac9289109 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -4402,6 +4402,8 @@ static bool ext4_should_enable_dax(struct inode *inode)
>   {
>   struct ext4_sb_info *sbi = EXT4_SB(inode->i_sb);
> 
> + if (test_opt2(inode->i_sb, DAX_NEVER))
> + return false;
>   if (!S_ISREG(inode->i_mode))
>   return false;
>   if (ext4_should_journal_data(inode))
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 80eb814c47eb..5e056aa20ce9 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1512,7 +1512,8 @@ enum {
>   Opt_usrjquota, Opt_grpjquota, Opt_offusrjquota, Opt_offgrpjquota,
>   Opt_jqfmt_vfsold, Opt_jqfmt_vfsv0, Opt_jqfmt_vfsv1, Opt_quota,
>   Opt_noquota, Opt_barrier, Opt_nobarrier, Opt_err,
> - Opt_usrquota, Opt_grpquota, Opt_prjquota, Opt_i_version, Opt_dax,
> + Opt_usrquota, Opt_grpquota, Opt_prjquota, Opt_i_version,
> + Opt_dax, Opt_dax_always, Opt_dax_inode, Opt_dax_never,
>   Opt_stripe, Opt_delalloc, Opt_nodelalloc, Opt_warn_on_error,
>   Opt_nowarn_on_error, Opt_mblk_io_submit,
>   Opt_lazytime, Opt_nolazytime, Opt_debug_want_extra_isize,
> @@ -1579,6 +1580,9 @@ static const match_table_t tokens = {
>   {Opt_nobarrier, "nobarrier"},
>   {Opt_i_version, "i_version"},
>   {Opt_dax, "dax"},
> + {Opt_dax_always, "dax=always"},
> + {Opt_dax_inode, "dax=inode"},
> + {Opt_dax_never, "dax=never"},
>   {Opt_stripe, "stripe=%u"},
>   {Opt_delalloc, "delalloc"},
>   {Opt_warn_on_error, "warn_on_error"},
> @@ -1726,6 +1730,7 @@ static int clear_qf_name(struct super_block *sb, int 
> qtype)
>   #define MOPT_NO_EXT30x0200
>   #define MOPT_EXT4_ONLY  (MOPT_NO_EXT2 | MOPT_NO_EXT3)
>   #define MOPT_STRING 0x0400
> +#define MOPT_SKIP0x0800
> 
>   static 

Re: [PATCH v1 2/5] clk: Introduce clk_round_rate_unboundly()

2020-05-26 Thread Stephen Boyd
Quoting Dmitry Osipenko (2020-03-30 16:16:14)
> In same cases it may be desired to round clock's rate without taking into
> account current min/max requests made by the clock's users. One example is
> building up OPP table based on a possible clock rates.

Shouldn't the OPP table come from firmware/DT? I don't quite understand
why we're generating OPP tables on top of the rate rounding API.
clk_round_rate() is supposed to tell us what rate we'll get if we call
clk_set_rate() with the same arguments. An unboundly version of that
doesn't make sense. 

I wonder if perhaps the clk provider should be populating OPP tables in
this case? Or basically anything besides adding another clk consumer API
to solve this problem. Who is the caller? Something later in this
series?


[PATCH v6 2/5] remoteproc: qcom: Introduce helper to store pil info in IMEM

2020-05-26 Thread Bjorn Andersson
A region in IMEM is used to communicate load addresses of remoteproc to
post mortem debug tools. Implement a helper function that can be used to
store this information in order to enable these tools to process
collected ramdumps.

Reviewed-by: Mathieu Poirier 
Reviewed-by: Vinod Koul 
Signed-off-by: Bjorn Andersson 
---

Changes since v5:
- Picked up reviewed-bys

 drivers/remoteproc/Kconfig |   3 +
 drivers/remoteproc/Makefile|   1 +
 drivers/remoteproc/qcom_pil_info.c | 124 +
 drivers/remoteproc/qcom_pil_info.h |   7 ++
 4 files changed, 135 insertions(+)
 create mode 100644 drivers/remoteproc/qcom_pil_info.c
 create mode 100644 drivers/remoteproc/qcom_pil_info.h

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index c4d1731295eb..f4bd96d1a1a3 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -116,6 +116,9 @@ config KEYSTONE_REMOTEPROC
  It's safe to say N here if you're not interested in the Keystone
  DSPs or just want to use a bare minimum kernel.
 
+config QCOM_PIL_INFO
+   tristate
+
 config QCOM_RPROC_COMMON
tristate
 
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index e8b886e511f0..fe398f82d550 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
 obj-$(CONFIG_KEYSTONE_REMOTEPROC)  += keystone_remoteproc.o
+obj-$(CONFIG_QCOM_PIL_INFO)+= qcom_pil_info.o
 obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
 obj-$(CONFIG_QCOM_Q6V5_COMMON) += qcom_q6v5.o
 obj-$(CONFIG_QCOM_Q6V5_ADSP)   += qcom_q6v5_adsp.o
diff --git a/drivers/remoteproc/qcom_pil_info.c 
b/drivers/remoteproc/qcom_pil_info.c
new file mode 100644
index ..0785c7cde2d3
--- /dev/null
+++ b/drivers/remoteproc/qcom_pil_info.c
@@ -0,0 +1,124 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2019-2020 Linaro Ltd.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define PIL_RELOC_NAME_LEN 8
+
+struct pil_reloc_entry {
+   char name[PIL_RELOC_NAME_LEN];
+   __le64 base;
+   __le32 size;
+} __packed;
+
+struct pil_reloc {
+   struct device *dev;
+   void __iomem *base;
+   size_t num_entries;
+};
+
+static struct pil_reloc _reloc __read_mostly;
+static DEFINE_MUTEX(reloc_mutex);
+
+static int qcom_pil_info_init(void)
+{
+   struct device_node *np;
+   struct resource imem;
+   void __iomem *base;
+   int ret;
+
+   /* Already initialized? */
+   if (_reloc.base)
+   return 0;
+
+   np = of_find_compatible_node(NULL, NULL, "qcom,pil-reloc-info");
+   if (!np)
+   return -ENOENT;
+
+   ret = of_address_to_resource(np, 0, );
+   of_node_put(np);
+   if (ret < 0)
+   return ret;
+
+   base = ioremap(imem.start, resource_size());
+   if (!base) {
+   pr_err("failed to map PIL relocation info region\n");
+   return -ENOMEM;
+   }
+
+   memset_io(base, 0, resource_size());
+
+   _reloc.base = base;
+   _reloc.num_entries = resource_size() / sizeof(struct 
pil_reloc_entry);
+
+   return 0;
+}
+
+/**
+ * qcom_pil_info_store() - store PIL information of image in IMEM
+ * @image: name of the image
+ * @base:  base address of the loaded image
+ * @size:  size of the loaded image
+ *
+ * Return: 0 on success, negative errno on failure
+ */
+int qcom_pil_info_store(const char *image, phys_addr_t base, size_t size)
+{
+   char buf[PIL_RELOC_NAME_LEN];
+   void __iomem *entry;
+   int ret;
+   int i;
+
+   mutex_lock(_mutex);
+   ret = qcom_pil_info_init();
+   if (ret < 0) {
+   mutex_unlock(_mutex);
+   return ret;
+   }
+
+   for (i = 0; i < _reloc.num_entries; i++) {
+   entry = _reloc.base + i * sizeof(struct pil_reloc_entry);
+
+   memcpy_fromio(buf, entry, PIL_RELOC_NAME_LEN);
+
+   /*
+* An empty record means we didn't find it, given that the
+* records are packed.
+*/
+   if (!buf[0])
+   goto found_unused;
+
+   if (!strncmp(buf, image, PIL_RELOC_NAME_LEN))
+   goto found_existing;
+   }
+
+   pr_warn("insufficient PIL info slots\n");
+   mutex_unlock(_mutex);
+   return -ENOMEM;
+
+found_unused:
+   memcpy_toio(entry, image, PIL_RELOC_NAME_LEN);
+found_existing:
+   writel(base, entry + offsetof(struct pil_reloc_entry, base));
+   writel(size, entry + offsetof(struct pil_reloc_entry, size));
+   mutex_unlock(_mutex);
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_pil_info_store);
+
+static void __exit 

[PATCH v6 5/5] arm64: dts: qcom: sdm845: Add IMEM and PIL info region

2020-05-26 Thread Bjorn Andersson
Add a simple-mfd representing IMEM on SDM845 and define the PIL
relocation info region, so that post mortem tools will be able to locate
the loaded remoteprocs.

Reviewed-by: Stephen Boyd 
Reviewed-by: Vinod Koul 
Signed-off-by: Bjorn Andersson 
---

Changes since v5:
- Picked up reviewed-bys

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 8eb5a31346d2..fee50d979dc3 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -3724,6 +3724,21 @@ spmi_bus: spmi@c44 {
cell-index = <0>;
};
 
+   imem@146bf000 {
+   compatible = "simple-mfd";
+   reg = <0 0x146bf000 0 0x1000>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   ranges = <0 0 0x146bf000 0x1000>;
+
+   pil-reloc@94c {
+   compatible = "qcom,pil-reloc-info";
+   reg = <0x94c 0xc8>;
+   };
+   };
+
apps_smmu: iommu@1500 {
compatible = "qcom,sdm845-smmu-500", "arm,mmu-500";
reg = <0 0x1500 0 0x8>;
-- 
2.26.2



[PATCH v6 4/5] arm64: dts: qcom: qcs404: Add IMEM and PIL info region

2020-05-26 Thread Bjorn Andersson
Add a simple-mfd representing IMEM on QCS404 and define the PIL
relocation info region, so that post mortem tools will be able to locate
the loaded remoteprocs.

Reviewed-by: Stephen Boyd 
Reviewed-by: Vinod Koul 
Signed-off-by: Bjorn Andersson 
---

Changes since v5:
- Picked up reviewed-bys

 arch/arm64/boot/dts/qcom/qcs404.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi 
b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index c685a1664810..b654b802e95c 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -1097,6 +1097,21 @@ blsp2_spi0: spi@7af5000 {
status = "disabled";
};
 
+   imem@860 {
+   compatible = "simple-mfd";
+   reg = <0x0860 0x1000>;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   ranges = <0 0x0860 0x1000>;
+
+   pil-reloc@94c {
+   compatible = "qcom,pil-reloc-info";
+   reg = <0x94c 0xc8>;
+   };
+   };
+
intc: interrupt-controller@b00 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
-- 
2.26.2



[PATCH v6 3/5] remoteproc: qcom: Update PIL relocation info on load

2020-05-26 Thread Bjorn Andersson
Update the PIL relocation information in IMEM with information about
where the firmware for various remoteprocs are loaded.

Reviewed-by: Vinod Koul 
Signed-off-by: Bjorn Andersson 
---

Changes since v5:
- Added select QCOM_PIL_INFO to all relevant Kconfig options
- Replaced mem_reloc with mem_phys, to get the start of the memory region,
  rather than the bottom address prior to relocation.
- Include qcom_pil_info.h in qcom_q6v5_wcss.c

 drivers/remoteproc/Kconfig  |  5 +
 drivers/remoteproc/qcom_q6v5_adsp.c | 16 +---
 drivers/remoteproc/qcom_q6v5_mss.c  |  3 +++
 drivers/remoteproc/qcom_q6v5_pas.c  | 15 ---
 drivers/remoteproc/qcom_q6v5_wcss.c | 14 +++---
 drivers/remoteproc/qcom_wcnss.c | 14 +++---
 6 files changed, 55 insertions(+), 12 deletions(-)

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index f4bd96d1a1a3..3e8d5d1a2b9e 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -135,6 +135,7 @@ config QCOM_Q6V5_ADSP
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
select MFD_SYSCON
+   select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
@@ -151,6 +152,7 @@ config QCOM_Q6V5_MSS
depends on QCOM_SYSMON || QCOM_SYSMON=n
select MFD_SYSCON
select QCOM_MDT_LOADER
+   select QCOM_PIL_INFO
select QCOM_Q6V5_COMMON
select QCOM_Q6V5_IPA_NOTIFY
select QCOM_RPROC_COMMON
@@ -167,6 +169,7 @@ config QCOM_Q6V5_PAS
depends on RPMSG_QCOM_GLINK_SMEM || RPMSG_QCOM_GLINK_SMEM=n
depends on QCOM_SYSMON || QCOM_SYSMON=n
select MFD_SYSCON
+   select QCOM_PIL_INFO
select QCOM_MDT_LOADER
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
@@ -185,6 +188,7 @@ config QCOM_Q6V5_WCSS
depends on QCOM_SYSMON || QCOM_SYSMON=n
select MFD_SYSCON
select QCOM_MDT_LOADER
+   select QCOM_PIL_INFO
select QCOM_Q6V5_COMMON
select QCOM_RPROC_COMMON
select QCOM_SCM
@@ -218,6 +222,7 @@ config QCOM_WCNSS_PIL
depends on QCOM_SMEM
depends on QCOM_SYSMON || QCOM_SYSMON=n
select QCOM_MDT_LOADER
+   select QCOM_PIL_INFO
select QCOM_RPROC_COMMON
select QCOM_SCM
help
diff --git a/drivers/remoteproc/qcom_q6v5_adsp.c 
b/drivers/remoteproc/qcom_q6v5_adsp.c
index d2a2574dcf35..efb2c1aa80a3 100644
--- a/drivers/remoteproc/qcom_q6v5_adsp.c
+++ b/drivers/remoteproc/qcom_q6v5_adsp.c
@@ -26,6 +26,7 @@
 #include 
 
 #include "qcom_common.h"
+#include "qcom_pil_info.h"
 #include "qcom_q6v5.h"
 #include "remoteproc_internal.h"
 
@@ -82,6 +83,7 @@ struct qcom_adsp {
unsigned int halt_lpass;
 
int crash_reason_smem;
+   const char *info_name;
 
struct completion start_done;
struct completion stop_done;
@@ -164,10 +166,17 @@ static int qcom_adsp_shutdown(struct qcom_adsp *adsp)
 static int adsp_load(struct rproc *rproc, const struct firmware *fw)
 {
struct qcom_adsp *adsp = (struct qcom_adsp *)rproc->priv;
+   int ret;
+
+   ret = qcom_mdt_load_no_init(adsp->dev, fw, rproc->firmware, 0,
+   adsp->mem_region, adsp->mem_phys,
+   adsp->mem_size, >mem_reloc);
+   if (ret)
+   return ret;
+
+   qcom_pil_info_store(adsp->info_name, adsp->mem_phys, adsp->mem_size);
 
-   return qcom_mdt_load_no_init(adsp->dev, fw, rproc->firmware, 0,
-adsp->mem_region, adsp->mem_phys, adsp->mem_size,
->mem_reloc);
+   return 0;
 }
 
 static int adsp_start(struct rproc *rproc)
@@ -436,6 +445,7 @@ static int adsp_probe(struct platform_device *pdev)
adsp = (struct qcom_adsp *)rproc->priv;
adsp->dev = >dev;
adsp->rproc = rproc;
+   adsp->info_name = desc->sysmon_name;
platform_set_drvdata(pdev, adsp);
 
ret = adsp_alloc_memory_region(adsp);
diff --git a/drivers/remoteproc/qcom_q6v5_mss.c 
b/drivers/remoteproc/qcom_q6v5_mss.c
index feb70283b6a2..dd37e462ed61 100644
--- a/drivers/remoteproc/qcom_q6v5_mss.c
+++ b/drivers/remoteproc/qcom_q6v5_mss.c
@@ -29,6 +29,7 @@
 
 #include "remoteproc_internal.h"
 #include "qcom_common.h"
+#include "qcom_pil_info.h"
 #include "qcom_q6v5.h"
 
 #include 
@@ -1189,6 +1190,8 @@ static int q6v5_mpss_load(struct q6v5 *qproc)
else if (ret < 0)
dev_err(qproc->dev, "MPSS authentication failed: %d\n", ret);
 
+   qcom_pil_info_store("modem", qproc->mpss_phys, qproc->mpss_size);
+
 release_firmware:
release_firmware(fw);
 out:
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c 
b/drivers/remoteproc/qcom_q6v5_pas.c
index 61791a03f648..3837f23995e0 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -25,6 +25,7 @@
 

[PATCH v6 1/5] dt-bindings: remoteproc: Add Qualcomm PIL info binding

2020-05-26 Thread Bjorn Andersson
Add a devicetree binding for the Qualcomm peripheral image loader
relocation information region found in the IMEM.

Reviewed-by: Mathieu Poirier 
Reviewed-by: Rob Herring 
Reviewed-by: Stephen Boyd 
Reviewed-by: Vinod Koul 
Signed-off-by: Bjorn Andersson 
---

Changes since v5:
- Picked up reviewed-bys

 .../bindings/remoteproc/qcom,pil-info.yaml| 44 +++
 1 file changed, 44 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml 
b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
new file mode 100644
index ..87c52316ddbd
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/qcom,pil-info.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm peripheral image loader relocation info binding
+
+maintainers:
+  - Bjorn Andersson 
+
+description:
+  The Qualcomm peripheral image loader relocation memory region, in IMEM, is
+  used for communicating remoteproc relocation information to post mortem
+  debugging tools.
+
+properties:
+  compatible:
+const: qcom,pil-reloc-info
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+examples:
+  - |
+imem@146bf000 {
+  compatible = "syscon", "simple-mfd";
+  reg = <0x146bf000 0x1000>;
+
+  #address-cells = <1>;
+  #size-cells = <1>;
+
+  ranges = <0 0x146bf000 0x1000>;
+
+  pil-reloc@94c {
+compatible = "qcom,pil-reloc-info";
+reg = <0x94c 0xc8>;
+  };
+};
+...
-- 
2.26.2



[PATCH v6 0/5] remoteproc: qcom: PIL info support

2020-05-26 Thread Bjorn Andersson
Introduce support for filling out the relocation information in IMEM, to aid
post mortem debug tools to locate the various remoteprocs.

Bjorn Andersson (5):
  dt-bindings: remoteproc: Add Qualcomm PIL info binding
  remoteproc: qcom: Introduce helper to store pil info in IMEM
  remoteproc: qcom: Update PIL relocation info on load
  arm64: dts: qcom: qcs404: Add IMEM and PIL info region
  arm64: dts: qcom: sdm845: Add IMEM and PIL info region

 .../bindings/remoteproc/qcom,pil-info.yaml|  44 +++
 arch/arm64/boot/dts/qcom/qcs404.dtsi  |  15 +++
 arch/arm64/boot/dts/qcom/sdm845.dtsi  |  15 +++
 drivers/remoteproc/Kconfig|   8 ++
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/qcom_pil_info.c| 124 ++
 drivers/remoteproc/qcom_pil_info.h|   7 +
 drivers/remoteproc/qcom_q6v5_adsp.c   |  16 ++-
 drivers/remoteproc/qcom_q6v5_mss.c|   3 +
 drivers/remoteproc/qcom_q6v5_pas.c|  15 ++-
 drivers/remoteproc/qcom_q6v5_wcss.c   |  14 +-
 drivers/remoteproc/qcom_wcnss.c   |  14 +-
 12 files changed, 264 insertions(+), 12 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/qcom,pil-info.yaml
 create mode 100644 drivers/remoteproc/qcom_pil_info.c
 create mode 100644 drivers/remoteproc/qcom_pil_info.h

-- 
2.26.2



Re: [PATCH] clk: versatile: remove redundant assignment to pointer clk

2020-05-26 Thread Linus Walleij
On Wed, May 27, 2020 at 12:41 AM Colin King  wrote:

> From: Colin Ian King 
>
> The pointer clk is being initialized with a value that is never read
> and is being updated with a new value later on. The initialization
> is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Reviewed-by: Linus Walleij 

Yours,
Linus Walleij


general protection fault in start_creating

2020-05-26 Thread syzbot
Hello,

syzbot found the following crash on:

HEAD commit:c11d28ab Add linux-next specific files for 20200522
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1135d53c10
kernel config:  https://syzkaller.appspot.com/x/.config?x=3f6dbdea4159fb66
dashboard link: https://syzkaller.appspot.com/bug?extid=705f4401d5a93a59b87d
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=110448d210

The bug was bisected to:

commit 63d04348371b7ea4a134bcf47c79763d969e9168
Author: Paolo Bonzini 
Date:   Tue Mar 31 22:42:22 2020 +

KVM: x86: move kvm_create_vcpu_debugfs after last failure point

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1366069a10
final crash:https://syzkaller.appspot.com/x/report.txt?x=10e6069a10
console output: https://syzkaller.appspot.com/x/log.txt?x=1766069a10

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+705f4401d5a93a59b...@syzkaller.appspotmail.com
Fixes: 63d04348371b ("KVM: x86: move kvm_create_vcpu_debugfs after last failure 
point")

general protection fault, probably for non-canonical address 
0xdc2a:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0150-0x0157]
CPU: 0 PID: 8143 Comm: syz-executor.0 Not tainted 
5.7.0-rc6-next-20200522-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:__lock_acquire+0xe1b/0x48a0 kernel/locking/lockdep.c:4250
Code: b6 0a 41 be 01 00 00 00 0f 86 ce 0b 00 00 89 05 ab 87 b6 0a e9 c3 0b 00 
00 48 b8 00 00 00 00 00 fc ff df 4c 89 d2 48 c1 ea 03 <80> 3c 02 00 0f 85 e5 2c 
00 00 49 81 3a 40 75 e5 8b 0f 84 b0 f2 ff
RSP: 0018:c900043cf7b8 EFLAGS: 00010002
RAX: dc00 RBX: 0001 RCX: 
RDX: 002a RSI:  RDI: 0150
RBP: 0001 R08: 0001 R09: 
R10: 0150 R11: 0001 R12: 
R13: 8880966f8240 R14:  R15: 
FS:  7f6300c10700() GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f6300bcbdb8 CR3: 92f4d000 CR4: 001426f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 lock_acquire+0x1f2/0x8f0 kernel/locking/lockdep.c:4959
 down_write+0x8d/0x150 kernel/locking/rwsem.c:1531
 inode_lock include/linux/fs.h:801 [inline]
 start_creating+0xa8/0x250 fs/debugfs/inode.c:334
 __debugfs_create_file+0x62/0x400 fs/debugfs/inode.c:383
 kvm_arch_create_vcpu_debugfs+0x9f/0x200 arch/x86/kvm/debugfs.c:52
 kvm_create_vcpu_debugfs arch/x86/kvm/../../../virt/kvm/kvm_main.c:2998 [inline]
 kvm_vm_ioctl_create_vcpu arch/x86/kvm/../../../virt/kvm/kvm_main.c:3075 
[inline]
 kvm_vm_ioctl+0x1c28/0x2460 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3603
 vfs_ioctl fs/ioctl.c:48 [inline]
 ksys_ioctl+0x11a/0x180 fs/ioctl.c:753
 __do_sys_ioctl fs/ioctl.c:762 [inline]
 __se_sys_ioctl fs/ioctl.c:760 [inline]
 __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:760
 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x45ca29
Code: 0d b7 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
db b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7f6300c0fc78 EFLAGS: 0246 ORIG_RAX: 0010
RAX: ffda RBX: 004e73c0 RCX: 0045ca29
RDX:  RSI: ae41 RDI: 0005
RBP: 0078bf00 R08:  R09: 
R10:  R11: 0246 R12: 
R13: 0396 R14: 004c62c6 R15: 7f6300c106d4
Modules linked in:
---[ end trace b2ea4e12631736e7 ]---
RIP: 0010:__lock_acquire+0xe1b/0x48a0 kernel/locking/lockdep.c:4250
Code: b6 0a 41 be 01 00 00 00 0f 86 ce 0b 00 00 89 05 ab 87 b6 0a e9 c3 0b 00 
00 48 b8 00 00 00 00 00 fc ff df 4c 89 d2 48 c1 ea 03 <80> 3c 02 00 0f 85 e5 2c 
00 00 49 81 3a 40 75 e5 8b 0f 84 b0 f2 ff
RSP: 0018:c900043cf7b8 EFLAGS: 00010002
RAX: dc00 RBX: 0001 RCX: 
RDX: 002a RSI:  RDI: 0150
RBP: 0001 R08: 0001 R09: 
R10: 0150 R11: 0001 R12: 
R13: 8880966f8240 R14:  R15: 
FS:  7f6300c10700() GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7f6300bcbdb8 CR3: 92f4d000 CR4: 001426f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 

Re: [RFC] perf/core: allow ftrace for functions in kernel/event/core.c

2020-05-26 Thread Masami Hiramatsu
On Tue, 26 May 2020 21:46:29 +
Song Liu  wrote:

> 
> 
> > On May 26, 2020, at 2:39 PM, Peter Zijlstra  wrote:
> > 
> > On Tue, May 26, 2020 at 02:28:26PM -0700, Song Liu wrote:
> >> It is useful to trace functions in kernel/event/core.c. Allow ftrace for
> >> them by removing $(CC_FLAGS_FTRACE) from Makefile.
> > 
> > Did you try using the ftrace event with perf with this on?
> 
> I have tried a few things, like 
> 
>   perf stat -e probe:perf_read -I 1000
>   perf record -e probe:__x64_sys_perf_event_open -aR
> 
> They all work fine. 

Did you try using perf with function-tracer or function-graph tracer?
If you just want to trace those functions with kprobes, you can 
build your kernel with CONFIG_KPROBE_EVENTS_ON_NOTRACE=y, which allows
you to probe perf_read etc.

Thank you,


-- 
Masami Hiramatsu 


Re: [PATCH] perf jvmti: remove redundant jitdump line table entries

2020-05-26 Thread Nick Gasson
On 05/27/20 13:03 PM, Ian Rogers wrote:
>
> Great result, thanks! I note there is a lack of symbolization when
> benchmarking a few Java applications. I'll try to see if there's a
> sensible resolution for those.
>

I noticed it loses information when the Hotspot code cache is
resized. I've been working around that by setting
-XX:InitialCodeCacheSize and -XX:ReservedCodeCacheSize to large
values. Does this help in your case?

>
> It'd be better to make this into two patches. Also on acme's perf/core
> branch if possible:
> https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=perf/core

OK sure, I'll do that.

--
Nick


Re: [PATCH V2] PCI: qcom: Improve exception handling in qcom_pcie_probe()

2020-05-26 Thread Markus Elfring
> 1. pm_runtime_put() …
…
> 2. pm_runtime_disable() …

How do you think about to add blank lines for such enumeration items
and to indent the text below the numbers?


> Co-developed-by: Markus Elfring 

Will our collaboration evolve in more ways besides patch review?

Regards,
Markus


[RESEND PATCH v2 1/4] clk: sprd: check its parent status before reading gate clock

2020-05-26 Thread Chunyan Zhang
From: Chunyan Zhang 

Some clocks only can be accessed if their parent is enabled. mipi_csi_xx
clocks on SC9863A are an examples. We have to ensure the parent clock is
enabled when reading those clocks.

Signed-off-by: Chunyan Zhang 
---
 drivers/clk/sprd/gate.c | 7 +++
 drivers/clk/sprd/gate.h | 9 +
 2 files changed, 16 insertions(+)

diff --git a/drivers/clk/sprd/gate.c b/drivers/clk/sprd/gate.c
index 574cfc116bbc..56e1714b541e 100644
--- a/drivers/clk/sprd/gate.c
+++ b/drivers/clk/sprd/gate.c
@@ -94,8 +94,15 @@ static int sprd_gate_is_enabled(struct clk_hw *hw)
 {
struct sprd_gate *sg = hw_to_sprd_gate(hw);
struct sprd_clk_common *common = >common;
+   struct clk_hw *parent;
unsigned int reg;
 
+   if (sg->flags & SPRD_GATE_NON_AON) {
+   parent = clk_hw_get_parent(hw);
+   if (!parent || !clk_hw_is_enabled(parent))
+   return 0;
+   }
+
regmap_read(common->regmap, common->reg, );
 
if (sg->flags & CLK_GATE_SET_TO_DISABLE)
diff --git a/drivers/clk/sprd/gate.h b/drivers/clk/sprd/gate.h
index b55817869367..e738dafa4fe9 100644
--- a/drivers/clk/sprd/gate.h
+++ b/drivers/clk/sprd/gate.h
@@ -19,6 +19,15 @@ struct sprd_gate {
struct sprd_clk_common  common;
 };
 
+/*
+ * sprd_gate->flags is used for:
+ * CLK_GATE_SET_TO_DISABLE BIT(0)
+ * CLK_GATE_HIWORD_MASKBIT(1)
+ * CLK_GATE_BIG_ENDIAN BIT(2)
+ * so we define new flags from BIT(3)
+ */
+#define SPRD_GATE_NON_AON BIT(3) /* not alway powered on, check before read */
+
 #define SPRD_SC_GATE_CLK_HW_INIT_FN(_struct, _name, _parent, _reg, \
_sc_offset, _enable_mask, _flags,   \
_gate_flags, _udelay, _ops, _fn)\
-- 
2.20.1



[RESEND PATCH v2 4/4] clk: sprd: add mipi_csi_xx gate clocks

2020-05-26 Thread Chunyan Zhang
From: Chunyan Zhang 

mipi_csi_xx clocks are used by camera sensors.

Signed-off-by: Chunyan Zhang 
---
 drivers/clk/sprd/sc9863a-clk.c | 32 
 1 file changed, 32 insertions(+)

diff --git a/drivers/clk/sprd/sc9863a-clk.c b/drivers/clk/sprd/sc9863a-clk.c
index a0631f7756cf..f67bd08f225c 100644
--- a/drivers/clk/sprd/sc9863a-clk.c
+++ b/drivers/clk/sprd/sc9863a-clk.c
@@ -1615,6 +1615,36 @@ static const struct sprd_clk_desc sc9863a_mm_gate_desc = 
{
.hw_clks= _mm_gate_hws,
 };
 
+/* camera sensor clocks */
+static SPRD_GATE_CLK_HW(mipi_csi_clk, "mipi-csi-clk", _ckg_eb.common.hw,
+   0x20, BIT(16), 0, SPRD_GATE_NON_AON);
+static SPRD_GATE_CLK_HW(mipi_csi_s_clk, "mipi-csi-s-clk", 
_ckg_eb.common.hw,
+   0x24, BIT(16), 0, SPRD_GATE_NON_AON);
+static SPRD_GATE_CLK_HW(mipi_csi_m_clk, "mipi-csi-m-clk", 
_ckg_eb.common.hw,
+   0x28, BIT(16), 0, SPRD_GATE_NON_AON);
+
+static struct sprd_clk_common *sc9863a_mm_clk_clks[] = {
+   /* address base is 0x6090 */
+   _csi_clk.common,
+   _csi_s_clk.common,
+   _csi_m_clk.common,
+};
+
+static struct clk_hw_onecell_data sc9863a_mm_clk_hws = {
+   .hws= {
+   [CLK_MIPI_CSI]  = _csi_clk.common.hw,
+   [CLK_MIPI_CSI_S]= _csi_s_clk.common.hw,
+   [CLK_MIPI_CSI_M]= _csi_m_clk.common.hw,
+   },
+   .num= CLK_MM_CLK_NUM,
+};
+
+static const struct sprd_clk_desc sc9863a_mm_clk_desc = {
+   .clk_clks   = sc9863a_mm_clk_clks,
+   .num_clk_clks   = ARRAY_SIZE(sc9863a_mm_clk_clks),
+   .hw_clks= _mm_clk_hws,
+};
+
 static SPRD_SC_GATE_CLK_FW_NAME(sim0_eb,   "sim0-eb",  "ext-26m", 0x0,
0x1000, BIT(0), 0, 0);
 static SPRD_SC_GATE_CLK_FW_NAME(iis0_eb,   "iis0-eb",  "ext-26m", 0x0,
@@ -1737,6 +1767,8 @@ static const struct of_device_id sprd_sc9863a_clk_ids[] = 
{
  .data = _aonapb_gate_desc },
{ .compatible = "sprd,sc9863a-mm-gate", /* 0x6080 */
  .data = _mm_gate_desc },
+   { .compatible = "sprd,sc9863a-mm-clk",  /* 0x6090 */
+ .data = _mm_clk_desc },
{ .compatible = "sprd,sc9863a-apapb-gate",  /* 0x7130 */
  .data = _apapb_gate_desc },
{ }
-- 
2.20.1



[RESEND PATCH v2 0/4] add mipi_csi_xx gate clocks for SC9863A

2020-05-26 Thread Chunyan Zhang
From: Chunyan Zhang 

mipi_csi_xx clocks are used by camera sensors. These clocks cannot be
accessed (even read) if their parent gate clock is disabled. So this
patchset also add a check to parent clocks when reading these gate
clocks which marked with the specific flag (SPRD_GATE_NON_AON).

changes from v1:
* added Rob's acked-by;

Chunyan Zhang (4):
  clk: sprd: check its parent status before reading gate clock
  dt-bindings: clk: sprd: add mipi_csi_xx clocks for SC9863A
  clk: sprd: add dt-bindings include for mipi_csi_xx clocks
  clk: sprd: add mipi_csi_xx gate clocks

 .../bindings/clock/sprd,sc9863a-clk.yaml  |  1 +
 drivers/clk/sprd/gate.c   |  7 
 drivers/clk/sprd/gate.h   |  9 ++
 drivers/clk/sprd/sc9863a-clk.c| 32 +++
 include/dt-bindings/clock/sprd,sc9863a-clk.h  |  5 +++
 5 files changed, 54 insertions(+)

-- 
2.20.1



[RESEND PATCH v2 2/4] dt-bindings: clk: sprd: add mipi_csi_xx clocks for SC9863A

2020-05-26 Thread Chunyan Zhang
From: Chunyan Zhang 

mipi_csi_xx clocks are used by camera sensors.

Signed-off-by: Chunyan Zhang 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml 
b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
index bb3a78d8105e..87e8349a539a 100644
--- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
+++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
@@ -28,6 +28,7 @@ properties:
   - sprd,sc9863a-rpll
   - sprd,sc9863a-dpll
   - sprd,sc9863a-mm-gate
+  - sprd,sc9863a-mm-clk
   - sprd,sc9863a-apapb-gate
 
   clocks:
-- 
2.20.1



[RESEND PATCH v2 3/4] clk: sprd: add dt-bindings include for mipi_csi_xx clocks

2020-05-26 Thread Chunyan Zhang
From: Chunyan Zhang 

mipi_csi_xx clocks are used by camera sensors.

Signed-off-by: Chunyan Zhang 
Acked-by: Rob Herring 
---
 include/dt-bindings/clock/sprd,sc9863a-clk.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/dt-bindings/clock/sprd,sc9863a-clk.h 
b/include/dt-bindings/clock/sprd,sc9863a-clk.h
index 901ba59676c2..4e030421641f 100644
--- a/include/dt-bindings/clock/sprd,sc9863a-clk.h
+++ b/include/dt-bindings/clock/sprd,sc9863a-clk.h
@@ -308,6 +308,11 @@
 #define CLK_MCPHY_CFG_EB   14
 #define CLK_MM_GATE_NUM(CLK_MCPHY_CFG_EB + 1)
 
+#define CLK_MIPI_CSI   0
+#define CLK_MIPI_CSI_S 1
+#define CLK_MIPI_CSI_M 2
+#define CLK_MM_CLK_NUM (CLK_MIPI_CSI_M + 1)
+
 #define CLK_SIM0_EB0
 #define CLK_IIS0_EB1
 #define CLK_IIS1_EB2
-- 
2.20.1



Re: [PATCH] gpiolib: add GPIO_SET_DEBOUNCE_IOCTL

2020-05-26 Thread Linus Walleij
On Mon, May 25, 2020 at 5:17 PM Kent Gibson  wrote:

> > I suppose gpiolib would have to steal or intercept the interrupt
> > by using e.g. IRQF_SHARED and then just return IRQ_HANDLED
> > on the first IRQ so the underlying irq handler does not get called.
>
> And how would gpiolib ensure that it was first in the chain?

I don't know.

> Totally agree with the concept - just trying to work out how to
> implement it seemlessly given the existing API and usage, and given my
> limited knowledge of the kernel internals.

The irqchip maintainers certainly know the answer for the question
of shared interrupts at least.

> > Failure is an option! Sorry if I push too complex ideas.
>
> I'm not as concerned about complexity as I am about fragility.
>
> I don't see any problem adding debounce for gpiolib-cdev.
> Adding a more complete solution to gpiolib itself is certainly
> non-trivial, if it is possible at all.

I agree. It's just that I perceive it as more elegant if we can do that.

> The path I'll probably be taking is adding a debouncer to gpiolib-cdev,
> so at least we have a solution for userspace, then take a longer look at
> the more general solution.

That's fine! Thanks for looking into this.

Linus Walleij


Re: [PATCH] perf jvmti: remove redundant jitdump line table entries

2020-05-26 Thread Nick Gasson
On 05/26/20 19:55 PM, Jiri Olsa wrote:
> On Fri, May 22, 2020 at 02:53:30PM +0800, Nick Gasson wrote:
>> For each PC/BCI pair in the JVMTI compiler inlining record table, the
>> jitdump plugin emits debug line table entries for every source line in
>> the method preceding that BCI. Instead only emit one source line per
>> PC/BCI pair. Reported by Ian Rogers. This reduces the .dump size for
>> SPECjbb from ~230MB to ~40MB.
>> 
>> Also fix an error in the DWARF line table state machine where addresses
>> are incorrectly offset by -0x40 (GEN_ELF_TEXT_OFFSET). This can be seen
>> with `objdump -S` on the ELF files after perf inject.
>
> hi,
> I can't apply this on latest Arnaldo's perf/core:
>
> patching file jvmti/libjvmti.c
> Hunk #1 FAILED at 32.
> Hunk #2 succeeded at 67 (offset -4 lines).
> Hunk #3 FAILED at 85.
> Hunk #4 succeeded at 114 (offset -7 lines).
>

Sorry I based this on my earlier patch series below but I didn't realise
that wasn't merged to perf/core yet. Could those patches be applied
first? I believe Ian added a Reviewed-by for all three.

https://lore.kernel.org/lkml/20200427061520.24905-3-nick.gas...@arm.com/T/


>
>> 
>> Signed-off-by: Nick Gasson 
>> ---
>>  tools/perf/jvmti/libjvmti.c| 73 +-
>>  tools/perf/util/genelf_debug.c |  4 +-
>>  2 files changed, 30 insertions(+), 47 deletions(-)
>> 
>> diff --git a/tools/perf/jvmti/libjvmti.c b/tools/perf/jvmti/libjvmti.c
>> index a9a056d68416..398e4ba6498d 100644
>> --- a/tools/perf/jvmti/libjvmti.c
>> +++ b/tools/perf/jvmti/libjvmti.c
>> @@ -32,38 +32,41 @@ static void print_error(jvmtiEnv *jvmti, const char 
>> *msg, jvmtiError ret)
>>  
>>  #ifdef HAVE_JVMTI_CMLR
>>  static jvmtiError
>> -do_get_line_numbers(jvmtiEnv *jvmti, void *pc, jmethodID m, jint bci,
>> -jvmti_line_info_t *tab, jint *nr)
>> +do_get_line_number(jvmtiEnv *jvmti, void *pc, jmethodID m, jint bci,
>> +   jvmti_line_info_t *tab)
>>  {
>> -jint i, lines = 0;
>> -jint nr_lines = 0;
>> +jint i, nr_lines = 0;
>>  jvmtiLineNumberEntry *loc_tab = NULL;
>>  jvmtiError ret;
>> +jint src_line = -1;
>>  
>>  ret = (*jvmti)->GetLineNumberTable(jvmti, m, _lines, _tab);
>>  if (ret == JVMTI_ERROR_ABSENT_INFORMATION || ret == 
>> JVMTI_ERROR_NATIVE_METHOD) {
>>  /* No debug information for this method */
>> -*nr = 0;
>> -return JVMTI_ERROR_NONE;
>> +return ret;
>>  } else if (ret != JVMTI_ERROR_NONE) {
>>  print_error(jvmti, "GetLineNumberTable", ret);
>>  return ret;
>>  }
>>  
>> -for (i = 0; i < nr_lines; i++) {
>> -if (loc_tab[i].start_location < bci) {
>> -tab[lines].pc = (unsigned long)pc;
>> -tab[lines].line_number = loc_tab[i].line_number;
>> -tab[lines].discrim = 0; /* not yet used */
>> -tab[lines].methodID = m;
>> -lines++;
>> -} else {
>> -break;
>> -}
>> +for (i = 0; i < nr_lines && loc_tab[i].start_location <= bci; i++) {
>> +src_line = i;
>> +}
>> +
>> +if (src_line != -1) {
>> +tab->pc = (unsigned long)pc;
>> +tab->line_number = loc_tab[src_line].line_number;
>> +tab->discrim = 0; /* not yet used */
>> +tab->methodID = m;
>> +
>> +ret = JVMTI_ERROR_NONE;
>> +} else {
>> +ret = JVMTI_ERROR_ABSENT_INFORMATION;
>>  }
>> +
>>  (*jvmti)->Deallocate(jvmti, (unsigned char *)loc_tab);
>> -*nr = lines;
>> -return JVMTI_ERROR_NONE;
>> +
>> +return ret;
>>  }
>>  
>>  static jvmtiError
>> @@ -71,9 +74,8 @@ get_line_numbers(jvmtiEnv *jvmti, const void 
>> *compile_info, jvmti_line_info_t **
>>  {
>>  const jvmtiCompiledMethodLoadRecordHeader *hdr;
>>  jvmtiCompiledMethodLoadInlineRecord *rec;
>> -jvmtiLineNumberEntry *lne = NULL;
>>  PCStackInfo *c;
>> -jint nr, ret;
>> +jint ret;
>>  int nr_total = 0;
>>  int i, lines_total = 0;
>>  
>> @@ -86,24 +88,7 @@ get_line_numbers(jvmtiEnv *jvmti, const void 
>> *compile_info, jvmti_line_info_t **
>>  for (hdr = compile_info; hdr != NULL; hdr = hdr->next) {
>>  if (hdr->kind == JVMTI_CMLR_INLINE_INFO) {
>>  rec = (jvmtiCompiledMethodLoadInlineRecord *)hdr;
>> -for (i = 0; i < rec->numpcs; i++) {
>> -c = rec->pcinfo + i;
>> -nr = 0;
>> -/*
>> - * unfortunately, need a tab to get the number 
>> of lines!
>> - */
>> -ret = (*jvmti)->GetLineNumberTable(jvmti, 
>> c->methods[0], , );
>> -if (ret == JVMTI_ERROR_NONE) {
>> -/* free what was allocated for nothing 
>> */
>> -

[PATCH 0/2] Bugy bootloader woraround

2020-05-26 Thread Jiaxun Yang
Jiaxun Yang (2):
  MIPS: head.S: Always jump to kernel_entry at head of text
  MIPS: Loongso64: select NO_EXCEPT_FILL

 arch/mips/Kconfig   | 1 +
 arch/mips/kernel/head.S | 2 --
 2 files changed, 1 insertion(+), 2 deletions(-)

-- 
2.27.0.rc0



[PATCH 1/2] MIPS: head.S: Always jump to kernel_entry at head of text

2020-05-26 Thread Jiaxun Yang
Buggy loaders like early version of PMON2000 sometimes ignore
elf_entry and goto start of text directly.

That would help with dealing with these loaders.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/kernel/head.S | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S
index 3b02ffe46304..c7c2795837e7 100644
--- a/arch/mips/kernel/head.S
+++ b/arch/mips/kernel/head.S
@@ -69,7 +69,6 @@
 
 EXPORT(_stext)
 
-#ifdef CONFIG_BOOT_RAW
/*
 * Give us a fighting chance of running if execution beings at the
 * kernel load address.  This is needed because this platform does
@@ -77,7 +76,6 @@ EXPORT(_stext)
 */
 FEXPORT(__kernel_entry)
j   kernel_entry
-#endif /* CONFIG_BOOT_RAW */
 
__REF
 
-- 
2.27.0.rc0



[PATCH 2/2] MIPS: Loongso64: select NO_EXCEPT_FILL

2020-05-26 Thread Jiaxun Yang
Loongson64 load kernel at 0x8200 and allocate exception vectors
by ebase. So we don't need to reserve space for exception vectors
at head of kernel.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 3ca59b610a67..0e385f7b7691 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -462,6 +462,7 @@ config MACH_LOONGSON64
select IRQ_MIPS_CPU
select NR_CPUS_DEFAULT_64
select USE_GENERIC_EARLY_PRINTK_8250
+   select NO_EXCEPT_FILL
select SYS_HAS_CPU_LOONGSON64
select SYS_HAS_EARLY_PRINTK
select SYS_SUPPORTS_SMP
-- 
2.27.0.rc0



[PATCH 14/16] block: remove rcu_read_lock() from part_stat_lock()

2020-05-26 Thread Christoph Hellwig
From: Konstantin Khlebnikov 

The RCU lock is required only in disk_map_sector_rcu() to lookup the
partition.  After that request holds reference to related hd_struct.

Replace get_cpu() with preempt_disable() - returned cpu index is unused.

Signed-off-by: Konstantin Khlebnikov 
[hch: rebased]
Signed-off-by: Christoph Hellwig 
---
 block/genhd.c | 11 ---
 include/linux/part_stat.h |  4 ++--
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/block/genhd.c b/block/genhd.c
index 3e7df0a3e6bb0..1a76593276644 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -321,11 +321,12 @@ struct hd_struct *disk_map_sector_rcu(struct gendisk 
*disk, sector_t sector)
struct hd_struct *part;
int i;
 
+   rcu_read_lock();
ptbl = rcu_dereference(disk->part_tbl);
 
part = rcu_dereference(ptbl->last_lookup);
if (part && sector_in_part(part, sector) && hd_struct_try_get(part))
-   return part;
+   goto out_unlock;
 
for (i = 1; i < ptbl->len; i++) {
part = rcu_dereference(ptbl->part[i]);
@@ -339,10 +340,14 @@ struct hd_struct *disk_map_sector_rcu(struct gendisk 
*disk, sector_t sector)
if (!hd_struct_try_get(part))
break;
rcu_assign_pointer(ptbl->last_lookup, part);
-   return part;
+   goto out_unlock;
}
}
-   return >part0;
+
+   part = >part0;
+out_unlock:
+   rcu_read_unlock();
+   return part;
 }
 
 /**
diff --git a/include/linux/part_stat.h b/include/linux/part_stat.h
index 6644197980b92..a6b0938ce82e9 100644
--- a/include/linux/part_stat.h
+++ b/include/linux/part_stat.h
@@ -21,8 +21,8 @@ struct disk_stats {
  *
  * part_stat_read() can be called at any time.
  */
-#define part_stat_lock()   ({ rcu_read_lock(); get_cpu(); })
-#define part_stat_unlock() do { put_cpu(); rcu_read_unlock(); } while (0)
+#define part_stat_lock()   preempt_disable()
+#define part_stat_unlock() preempt_enable()
 
 #define part_stat_get_cpu(part, field, cpu)\
(per_cpu_ptr((part)->dkstats, (cpu))->field)
-- 
2.26.2



block I/O accounting improvements v2

2020-05-26 Thread Christoph Hellwig
Hi Jens,

they series contains various improvement for block I/O accounting.  The
first bunch of patches switch the bio based drivers to better accounting
helpers compared to the current mess.  The end contains a fix and various
performanc improvements.  Most of this comes from a series Konstantin
sent a few weeks ago, rebased on changes that landed in your tree since
and my change to always use the percpu version of the disk stats.


Changes since v1:
 - add an ifdef CONFIG_BLOCK to work around the sad state of our headers
 - add reviewed-by tags to all patches


[PATCH 12/16] block: account merge of two requests

2020-05-26 Thread Christoph Hellwig
From: Konstantin Khlebnikov 

Also rename blk_account_io_merge() into blk_account_io_merge_request() to
distinguish it from merging request and bio.

Signed-off-by: Konstantin Khlebnikov 
[hch: rebased]
Signed-off-by: Christoph Hellwig 
---
 block/blk-merge.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 6a4538d39efd2..c3beae5c1be71 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -669,18 +669,16 @@ void blk_rq_set_mixed_merge(struct request *rq)
rq->rq_flags |= RQF_MIXED_MERGE;
 }
 
-static void blk_account_io_merge(struct request *req)
+static void blk_account_io_merge_request(struct request *req)
 {
if (blk_do_io_stat(req)) {
-   struct hd_struct *part;
-
part_stat_lock();
-   part = req->part;
-
-   hd_struct_put(part);
+   part_stat_inc(req->part, merges[op_stat_group(req_op(req))]);
+   hd_struct_put(req->part);
part_stat_unlock();
}
 }
+
 /*
  * Two cases of handling DISCARD merge:
  * If max_discard_segments > 1, the driver takes every bio
@@ -792,7 +790,7 @@ static struct request *attempt_merge(struct request_queue 
*q,
/*
 * 'next' is going away, so update stats accordingly
 */
-   blk_account_io_merge(next);
+   blk_account_io_merge_request(next);
 
/*
 * ownership of bio passed from next to req, return 'next' for
-- 
2.26.2



[PATCH 15/16] block: use __this_cpu_add() instead of access by smp_processor_id()

2020-05-26 Thread Christoph Hellwig
From: Konstantin Khlebnikov 

Most architectures have fast path to access percpu for current cpu.
The required preempt_disable() is provided by part_stat_lock().

Signed-off-by: Konstantin Khlebnikov 
[hch: rebased]
Signed-off-by: Christoph Hellwig 
---
 include/linux/part_stat.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/part_stat.h b/include/linux/part_stat.h
index a6b0938ce82e9..24125778ef3ec 100644
--- a/include/linux/part_stat.h
+++ b/include/linux/part_stat.h
@@ -54,7 +54,7 @@ static inline void part_stat_set_all(struct hd_struct *part, 
int value)
 part_stat_read(part, field[STAT_DISCARD]))
 
 #define __part_stat_add(part, field, addnd)\
-   (part_stat_get(part, field) += (addnd))
+   __this_cpu_add((part)->dkstats->field, addnd)
 
 #define part_stat_add(part, field, addnd)  do {\
__part_stat_add((part), field, addnd);  \
-- 
2.26.2



[PATCH 08/16] zram: nvdimm: use bio_{start,end}_io_acct and disk_{start,end}_io_acct

2020-05-26 Thread Christoph Hellwig
Switch zram to use the nicer bio accounting helpers, and as part of that
ensure each bio is counted as a single I/O request.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 drivers/block/zram/zram_drv.c | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index ebb234f36909c..6e2ad90b17a37 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -1510,13 +1510,8 @@ static void zram_bio_discard(struct zram *zram, u32 
index,
 static int zram_bvec_rw(struct zram *zram, struct bio_vec *bvec, u32 index,
int offset, unsigned int op, struct bio *bio)
 {
-   unsigned long start_time = jiffies;
-   struct request_queue *q = zram->disk->queue;
int ret;
 
-   generic_start_io_acct(q, op, bvec->bv_len >> SECTOR_SHIFT,
-   >disk->part0);
-
if (!op_is_write(op)) {
atomic64_inc(>stats.num_reads);
ret = zram_bvec_read(zram, bvec, index, offset, bio);
@@ -1526,8 +1521,6 @@ static int zram_bvec_rw(struct zram *zram, struct bio_vec 
*bvec, u32 index,
ret = zram_bvec_write(zram, bvec, index, offset, bio);
}
 
-   generic_end_io_acct(q, op, >disk->part0, start_time);
-
zram_slot_lock(zram, index);
zram_accessed(zram, index);
zram_slot_unlock(zram, index);
@@ -1548,6 +1541,7 @@ static void __zram_make_request(struct zram *zram, struct 
bio *bio)
u32 index;
struct bio_vec bvec;
struct bvec_iter iter;
+   unsigned long start_time;
 
index = bio->bi_iter.bi_sector >> SECTORS_PER_PAGE_SHIFT;
offset = (bio->bi_iter.bi_sector &
@@ -1563,6 +1557,7 @@ static void __zram_make_request(struct zram *zram, struct 
bio *bio)
break;
}
 
+   start_time = bio_start_io_acct(bio);
bio_for_each_segment(bvec, bio, iter) {
struct bio_vec bv = bvec;
unsigned int unwritten = bvec.bv_len;
@@ -1571,8 +1566,10 @@ static void __zram_make_request(struct zram *zram, 
struct bio *bio)
bv.bv_len = min_t(unsigned int, PAGE_SIZE - offset,
unwritten);
if (zram_bvec_rw(zram, , index, offset,
-bio_op(bio), bio) < 0)
-   goto out;
+bio_op(bio), bio) < 0) {
+   bio->bi_status = BLK_STS_IOERR;
+   break;
+   }
 
bv.bv_offset += bv.bv_len;
unwritten -= bv.bv_len;
@@ -1580,12 +1577,8 @@ static void __zram_make_request(struct zram *zram, 
struct bio *bio)
update_position(, , );
} while (unwritten);
}
-
+   bio_end_io_acct(bio, start_time);
bio_endio(bio);
-   return;
-
-out:
-   bio_io_error(bio);
 }
 
 /*
@@ -1633,6 +1626,7 @@ static int zram_rw_page(struct block_device *bdev, 
sector_t sector,
u32 index;
struct zram *zram;
struct bio_vec bv;
+   unsigned long start_time;
 
if (PageTransHuge(page))
return -ENOTSUPP;
@@ -1651,7 +1645,9 @@ static int zram_rw_page(struct block_device *bdev, 
sector_t sector,
bv.bv_len = PAGE_SIZE;
bv.bv_offset = 0;
 
+   start_time = disk_start_io_acct(bdev->bd_disk, SECTORS_PER_PAGE, op);
ret = zram_bvec_rw(zram, , index, offset, op, NULL);
+   disk_end_io_acct(bdev->bd_disk, op, start_time);
 out:
/*
 * If I/O fails, just return error(ie, non-zero) without
-- 
2.26.2



[PATCH 07/16] nvdimm: use bio_{start,end}_io_acct

2020-05-26 Thread Christoph Hellwig
Switch dm to use the nicer bio accounting helpers.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 drivers/nvdimm/blk.c  |  6 --
 drivers/nvdimm/btt.c  |  6 --
 drivers/nvdimm/nd.h   | 19 ---
 drivers/nvdimm/pmem.c |  6 --
 4 files changed, 12 insertions(+), 25 deletions(-)

diff --git a/drivers/nvdimm/blk.c b/drivers/nvdimm/blk.c
index 43751fab9d36a..036e23aef9b04 100644
--- a/drivers/nvdimm/blk.c
+++ b/drivers/nvdimm/blk.c
@@ -178,7 +178,9 @@ static blk_qc_t nd_blk_make_request(struct request_queue 
*q, struct bio *bio)
bip = bio_integrity(bio);
nsblk = q->queuedata;
rw = bio_data_dir(bio);
-   do_acct = nd_iostat_start(bio, );
+   do_acct = blk_queue_io_stat(bio->bi_disk->queue);
+   if (do_acct)
+   start = bio_start_io_acct(bio);
bio_for_each_segment(bvec, bio, iter) {
unsigned int len = bvec.bv_len;
 
@@ -195,7 +197,7 @@ static blk_qc_t nd_blk_make_request(struct request_queue 
*q, struct bio *bio)
}
}
if (do_acct)
-   nd_iostat_end(bio, start);
+   bio_end_io_acct(bio, start);
 
bio_endio(bio);
return BLK_QC_T_NONE;
diff --git a/drivers/nvdimm/btt.c b/drivers/nvdimm/btt.c
index 3b09419218d6f..90c0c4bbe77b9 100644
--- a/drivers/nvdimm/btt.c
+++ b/drivers/nvdimm/btt.c
@@ -1452,7 +1452,9 @@ static blk_qc_t btt_make_request(struct request_queue *q, 
struct bio *bio)
if (!bio_integrity_prep(bio))
return BLK_QC_T_NONE;
 
-   do_acct = nd_iostat_start(bio, );
+   do_acct = blk_queue_io_stat(bio->bi_disk->queue);
+   if (do_acct)
+   start = bio_start_io_acct(bio);
bio_for_each_segment(bvec, bio, iter) {
unsigned int len = bvec.bv_len;
 
@@ -1477,7 +1479,7 @@ static blk_qc_t btt_make_request(struct request_queue *q, 
struct bio *bio)
}
}
if (do_acct)
-   nd_iostat_end(bio, start);
+   bio_end_io_acct(bio, start);
 
bio_endio(bio);
return BLK_QC_T_NONE;
diff --git a/drivers/nvdimm/nd.h b/drivers/nvdimm/nd.h
index 85dbb2a322b9b..85c1ae813ea31 100644
--- a/drivers/nvdimm/nd.h
+++ b/drivers/nvdimm/nd.h
@@ -396,25 +396,6 @@ static inline int nvdimm_setup_pfn(struct nd_pfn *nd_pfn,
 #endif
 int nd_blk_region_init(struct nd_region *nd_region);
 int nd_region_activate(struct nd_region *nd_region);
-void __nd_iostat_start(struct bio *bio, unsigned long *start);
-static inline bool nd_iostat_start(struct bio *bio, unsigned long *start)
-{
-   struct gendisk *disk = bio->bi_disk;
-
-   if (!blk_queue_io_stat(disk->queue))
-   return false;
-
-   *start = jiffies;
-   generic_start_io_acct(disk->queue, bio_op(bio), bio_sectors(bio),
- >part0);
-   return true;
-}
-static inline void nd_iostat_end(struct bio *bio, unsigned long start)
-{
-   struct gendisk *disk = bio->bi_disk;
-
-   generic_end_io_acct(disk->queue, bio_op(bio), >part0, start);
-}
 static inline bool is_bad_pmem(struct badblocks *bb, sector_t sector,
unsigned int len)
 {
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 2df6994acf836..97f948f8f4e62 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -202,7 +202,9 @@ static blk_qc_t pmem_make_request(struct request_queue *q, 
struct bio *bio)
if (bio->bi_opf & REQ_PREFLUSH)
ret = nvdimm_flush(nd_region, bio);
 
-   do_acct = nd_iostat_start(bio, );
+   do_acct = blk_queue_io_stat(bio->bi_disk->queue);
+   if (do_acct)
+   start = bio_start_io_acct(bio);
bio_for_each_segment(bvec, bio, iter) {
if (op_is_write(bio_op(bio)))
rc = pmem_do_write(pmem, bvec.bv_page, bvec.bv_offset,
@@ -216,7 +218,7 @@ static blk_qc_t pmem_make_request(struct request_queue *q, 
struct bio *bio)
}
}
if (do_acct)
-   nd_iostat_end(bio, start);
+   bio_end_io_acct(bio, start);
 
if (bio->bi_opf & REQ_FUA)
ret = nvdimm_flush(nd_region, bio);
-- 
2.26.2



[PATCH 09/16] block: remove generic_{start,end}_io_acct

2020-05-26 Thread Christoph Hellwig
Remove these now unused functions.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 block/bio.c | 39 ---
 include/linux/bio.h |  6 --
 2 files changed, 45 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 9c101a0572ca2..3e89c7b37855a 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1392,45 +1392,6 @@ void update_io_ticks(struct hd_struct *part, unsigned 
long now, bool end)
}
 }
 
-void generic_start_io_acct(struct request_queue *q, int op,
-  unsigned long sectors, struct hd_struct *part)
-{
-   const int sgrp = op_stat_group(op);
-   int rw = op_is_write(op);
-
-   part_stat_lock();
-
-   update_io_ticks(part, jiffies, false);
-   part_stat_inc(part, ios[sgrp]);
-   part_stat_add(part, sectors[sgrp], sectors);
-   part_stat_local_inc(part, in_flight[rw]);
-   if (part->partno)
-   part_stat_local_inc(_to_disk(part)->part0, in_flight[rw]);
-
-   part_stat_unlock();
-}
-EXPORT_SYMBOL(generic_start_io_acct);
-
-void generic_end_io_acct(struct request_queue *q, int req_op,
-struct hd_struct *part, unsigned long start_time)
-{
-   unsigned long now = jiffies;
-   unsigned long duration = now - start_time;
-   const int sgrp = op_stat_group(req_op);
-   int rw = op_is_write(req_op);
-
-   part_stat_lock();
-
-   update_io_ticks(part, now, true);
-   part_stat_add(part, nsecs[sgrp], jiffies_to_nsecs(duration));
-   part_stat_local_dec(part, in_flight[rw]);
-   if (part->partno)
-   part_stat_local_dec(_to_disk(part)->part0, in_flight[rw]);
-
-   part_stat_unlock();
-}
-EXPORT_SYMBOL(generic_end_io_acct);
-
 static inline bool bio_remaining_done(struct bio *bio)
 {
/*
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 950c9dc44c4f2..941378ec5b39f 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -444,12 +444,6 @@ void bio_release_pages(struct bio *bio, bool mark_dirty);
 extern void bio_set_pages_dirty(struct bio *bio);
 extern void bio_check_pages_dirty(struct bio *bio);
 
-void generic_start_io_acct(struct request_queue *q, int op,
-   unsigned long sectors, struct hd_struct *part);
-void generic_end_io_acct(struct request_queue *q, int op,
-   struct hd_struct *part,
-   unsigned long start_time);
-
 extern void bio_copy_data_iter(struct bio *dst, struct bvec_iter *dst_iter,
   struct bio *src, struct bvec_iter *src_iter);
 extern void bio_copy_data(struct bio *dst, struct bio *src);
-- 
2.26.2



[PATCH 05/16] bcache: use bio_{start,end}_io_acct

2020-05-26 Thread Christoph Hellwig
Switch bcache to use the nicer bio accounting helpers, and call the
routines where we also sample the start time to give coherent accounting
results.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
Acked-by: Coly Li 
---
 drivers/md/bcache/request.c | 18 --
 1 file changed, 4 insertions(+), 14 deletions(-)

diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
index 77d1a26975174..22b483527176b 100644
--- a/drivers/md/bcache/request.c
+++ b/drivers/md/bcache/request.c
@@ -668,9 +668,7 @@ static void backing_request_endio(struct bio *bio)
 static void bio_complete(struct search *s)
 {
if (s->orig_bio) {
-   generic_end_io_acct(s->d->disk->queue, bio_op(s->orig_bio),
-   >d->disk->part0, s->start_time);
-
+   bio_end_io_acct(s->orig_bio, s->start_time);
trace_bcache_request_end(s->d, s->orig_bio);
s->orig_bio->bi_status = s->iop.status;
bio_endio(s->orig_bio);
@@ -730,7 +728,7 @@ static inline struct search *search_alloc(struct bio *bio,
s->recoverable  = 1;
s->write= op_is_write(bio_op(bio));
s->read_dirty_data  = 0;
-   s->start_time   = jiffies;
+   s->start_time   = bio_start_io_acct(bio);
 
s->iop.c= d->c;
s->iop.bio  = NULL;
@@ -1082,8 +1080,7 @@ static void detached_dev_end_io(struct bio *bio)
bio->bi_end_io = ddip->bi_end_io;
bio->bi_private = ddip->bi_private;
 
-   generic_end_io_acct(ddip->d->disk->queue, bio_op(bio),
-   >d->disk->part0, ddip->start_time);
+   bio_end_io_acct(bio, ddip->start_time);
 
if (bio->bi_status) {
struct cached_dev *dc = container_of(ddip->d,
@@ -1108,7 +1105,7 @@ static void detached_dev_do_request(struct bcache_device 
*d, struct bio *bio)
 */
ddip = kzalloc(sizeof(struct detached_dev_io_private), GFP_NOIO);
ddip->d = d;
-   ddip->start_time = jiffies;
+   ddip->start_time = bio_start_io_acct(bio);
ddip->bi_end_io = bio->bi_end_io;
ddip->bi_private = bio->bi_private;
bio->bi_end_io = detached_dev_end_io;
@@ -1190,11 +1187,6 @@ blk_qc_t cached_dev_make_request(struct request_queue 
*q, struct bio *bio)
}
}
 
-   generic_start_io_acct(q,
- bio_op(bio),
- bio_sectors(bio),
- >disk->part0);
-
bio_set_dev(bio, dc->bdev);
bio->bi_iter.bi_sector += dc->sb.data_offset;
 
@@ -1311,8 +1303,6 @@ blk_qc_t flash_dev_make_request(struct request_queue *q, 
struct bio *bio)
return BLK_QC_T_NONE;
}
 
-   generic_start_io_acct(q, bio_op(bio), bio_sectors(bio), 
>disk->part0);
-
s = search_alloc(bio, d);
cl = >cl;
bio = >bio.bio;
-- 
2.26.2



[PATCH 04/16] lightnvm/pblk: use bio_{start,end}_io_acct

2020-05-26 Thread Christoph Hellwig
Switch rsxx to use the nicer bio accounting helpers.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 drivers/lightnvm/pblk-cache.c |  8 +++-
 drivers/lightnvm/pblk-read.c  | 11 ---
 2 files changed, 7 insertions(+), 12 deletions(-)

diff --git a/drivers/lightnvm/pblk-cache.c b/drivers/lightnvm/pblk-cache.c
index 5c1034c22197c..f185f1a83 100644
--- a/drivers/lightnvm/pblk-cache.c
+++ b/drivers/lightnvm/pblk-cache.c
@@ -21,16 +21,14 @@
 void pblk_write_to_cache(struct pblk *pblk, struct bio *bio,
unsigned long flags)
 {
-   struct request_queue *q = pblk->dev->q;
struct pblk_w_ctx w_ctx;
sector_t lba = pblk_get_lba(bio);
-   unsigned long start_time = jiffies;
+   unsigned long start_time;
unsigned int bpos, pos;
int nr_entries = pblk_get_secs(bio);
int i, ret;
 
-   generic_start_io_acct(q, REQ_OP_WRITE, bio_sectors(bio),
- >disk->part0);
+   start_time = bio_start_io_acct(bio);
 
/* Update the write buffer head (mem) with the entries that we can
 * write. The write in itself cannot fail, so there is no need to
@@ -79,7 +77,7 @@ void pblk_write_to_cache(struct pblk *pblk, struct bio *bio,
pblk_rl_inserted(>rl, nr_entries);
 
 out:
-   generic_end_io_acct(q, REQ_OP_WRITE, >disk->part0, start_time);
+   bio_end_io_acct(bio, start_time);
pblk_write_should_kick(pblk);
 
if (ret == NVM_IO_DONE)
diff --git a/drivers/lightnvm/pblk-read.c b/drivers/lightnvm/pblk-read.c
index 8efd14e683dc4..140927ebf41e9 100644
--- a/drivers/lightnvm/pblk-read.c
+++ b/drivers/lightnvm/pblk-read.c
@@ -187,12 +187,11 @@ static void pblk_end_user_read(struct bio *bio, int error)
 static void __pblk_end_io_read(struct pblk *pblk, struct nvm_rq *rqd,
   bool put_line)
 {
-   struct nvm_tgt_dev *dev = pblk->dev;
struct pblk_g_ctx *r_ctx = nvm_rq_to_pdu(rqd);
struct bio *int_bio = rqd->bio;
unsigned long start_time = r_ctx->start_time;
 
-   generic_end_io_acct(dev->q, REQ_OP_READ, >disk->part0, 
start_time);
+   bio_end_io_acct(int_bio, start_time);
 
if (rqd->error)
pblk_log_read_err(pblk, rqd);
@@ -263,17 +262,15 @@ static void pblk_read_rq(struct pblk *pblk, struct nvm_rq 
*rqd, struct bio *bio,
 
 void pblk_submit_read(struct pblk *pblk, struct bio *bio)
 {
-   struct nvm_tgt_dev *dev = pblk->dev;
-   struct request_queue *q = dev->q;
sector_t blba = pblk_get_lba(bio);
unsigned int nr_secs = pblk_get_secs(bio);
bool from_cache;
struct pblk_g_ctx *r_ctx;
struct nvm_rq *rqd;
struct bio *int_bio, *split_bio;
+   unsigned long start_time;
 
-   generic_start_io_acct(q, REQ_OP_READ, bio_sectors(bio),
- >disk->part0);
+   start_time = bio_start_io_acct(bio);
 
rqd = pblk_alloc_rqd(pblk, PBLK_READ);
 
@@ -283,7 +280,7 @@ void pblk_submit_read(struct pblk *pblk, struct bio *bio)
rqd->end_io = pblk_end_io_read;
 
r_ctx = nvm_rq_to_pdu(rqd);
-   r_ctx->start_time = jiffies;
+   r_ctx->start_time = start_time;
r_ctx->lba = blba;
 
if (pblk_alloc_rqd_meta(pblk, rqd)) {
-- 
2.26.2



[PATCH 10/16] block: move update_io_ticks to blk-core.c

2020-05-26 Thread Christoph Hellwig
All callers are in blk-core.c, so move update_io_ticks over.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 block/bio.c  | 16 
 block/blk-core.c | 15 +++
 block/blk.h  |  1 -
 3 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 3e89c7b37855a..5235da6434aab 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -1376,22 +1376,6 @@ void bio_check_pages_dirty(struct bio *bio)
schedule_work(_dirty_work);
 }
 
-void update_io_ticks(struct hd_struct *part, unsigned long now, bool end)
-{
-   unsigned long stamp;
-again:
-   stamp = READ_ONCE(part->stamp);
-   if (unlikely(stamp != now)) {
-   if (likely(cmpxchg(>stamp, stamp, now) == stamp)) {
-   __part_stat_add(part, io_ticks, end ? now - stamp : 1);
-   }
-   }
-   if (part->partno) {
-   part = _to_disk(part)->part0;
-   goto again;
-   }
-}
-
 static inline bool bio_remaining_done(struct bio *bio)
 {
/*
diff --git a/block/blk-core.c b/block/blk-core.c
index 8973104f88d90..c1675d43c2da0 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1381,6 +1381,21 @@ unsigned int blk_rq_err_bytes(const struct request *rq)
 }
 EXPORT_SYMBOL_GPL(blk_rq_err_bytes);
 
+static void update_io_ticks(struct hd_struct *part, unsigned long now, bool 
end)
+{
+   unsigned long stamp;
+again:
+   stamp = READ_ONCE(part->stamp);
+   if (unlikely(stamp != now)) {
+   if (likely(cmpxchg(>stamp, stamp, now) == stamp))
+   __part_stat_add(part, io_ticks, end ? now - stamp : 1);
+   }
+   if (part->partno) {
+   part = _to_disk(part)->part0;
+   goto again;
+   }
+}
+
 static void blk_account_io_completion(struct request *req, unsigned int bytes)
 {
if (req->part && blk_do_io_stat(req)) {
diff --git a/block/blk.h b/block/blk.h
index 5db4ec1e85f7b..bdf5e94467aa2 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -344,7 +344,6 @@ void blk_queue_free_zone_bitmaps(struct request_queue *q);
 static inline void blk_queue_free_zone_bitmaps(struct request_queue *q) {}
 #endif
 
-void update_io_ticks(struct hd_struct *part, unsigned long now, bool end);
 struct hd_struct *disk_map_sector_rcu(struct gendisk *disk, sector_t sector);
 
 int blk_alloc_devt(struct hd_struct *part, dev_t *devt);
-- 
2.26.2



[PATCH 16/16] block: reduce part_stat_lock() scope

2020-05-26 Thread Christoph Hellwig
We only need the stats lock (aka preempt_disable()) for updating the
states, not for looking up or dropping the hd_struct reference.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 block/blk-core.c  | 5 +++--
 block/blk-merge.c | 3 ++-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index bf2f7d4bc0c1c..a01fb2b508f0e 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1437,9 +1437,9 @@ void blk_account_io_done(struct request *req, u64 now)
update_io_ticks(part, jiffies, true);
part_stat_inc(part, ios[sgrp]);
part_stat_add(part, nsecs[sgrp], now - req->start_time_ns);
+   part_stat_unlock();
 
hd_struct_put(part);
-   part_stat_unlock();
}
 }
 
@@ -1448,8 +1448,9 @@ void blk_account_io_start(struct request *rq)
if (!blk_do_io_stat(rq))
return;
 
-   part_stat_lock();
rq->part = disk_map_sector_rcu(rq->rq_disk, blk_rq_pos(rq));
+
+   part_stat_lock();
update_io_ticks(rq->part, jiffies, false);
part_stat_unlock();
 }
diff --git a/block/blk-merge.c b/block/blk-merge.c
index c3beae5c1be71..f0b0bae075a0c 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -674,8 +674,9 @@ static void blk_account_io_merge_request(struct request 
*req)
if (blk_do_io_stat(req)) {
part_stat_lock();
part_stat_inc(req->part, merges[op_stat_group(req_op(req))]);
-   hd_struct_put(req->part);
part_stat_unlock();
+
+   hd_struct_put(req->part);
}
 }
 
-- 
2.26.2



[PATCH 13/16] block: add a blk_account_io_merge_bio helper

2020-05-26 Thread Christoph Hellwig
From: Konstantin Khlebnikov 

Move the non-"new_io" branch of blk_account_io_start() into separate
function.  Fix merge accounting for discards (they were counted as write
merges).

The new blk_account_io_merge_bio() doesn't call update_io_ticks() unlike
blk_account_io_start(), as there is no reason for that.

Signed-off-by: Konstantin Khlebnikov 
[hch: rebased]
Signed-off-by: Christoph Hellwig 
---
 block/blk-core.c | 25 -
 block/blk-exec.c |  2 +-
 block/blk-mq.c   |  2 +-
 block/blk.h  |  2 +-
 4 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index c1675d43c2da0..bf2f7d4bc0c1c 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -636,6 +636,16 @@ void blk_put_request(struct request *req)
 }
 EXPORT_SYMBOL(blk_put_request);
 
+static void blk_account_io_merge_bio(struct request *req)
+{
+   if (!blk_do_io_stat(req))
+   return;
+
+   part_stat_lock();
+   part_stat_inc(req->part, merges[op_stat_group(req_op(req))]);
+   part_stat_unlock();
+}
+
 bool bio_attempt_back_merge(struct request *req, struct bio *bio,
unsigned int nr_segs)
 {
@@ -656,7 +666,7 @@ bool bio_attempt_back_merge(struct request *req, struct bio 
*bio,
 
bio_crypt_free_ctx(bio);
 
-   blk_account_io_start(req, false);
+   blk_account_io_merge_bio(req);
return true;
 }
 
@@ -682,7 +692,7 @@ bool bio_attempt_front_merge(struct request *req, struct 
bio *bio,
 
bio_crypt_do_front_merge(req, bio);
 
-   blk_account_io_start(req, false);
+   blk_account_io_merge_bio(req);
return true;
 }
 
@@ -704,7 +714,7 @@ bool bio_attempt_discard_merge(struct request_queue *q, 
struct request *req,
req->__data_len += bio->bi_iter.bi_size;
req->nr_phys_segments = segments + 1;
 
-   blk_account_io_start(req, false);
+   blk_account_io_merge_bio(req);
return true;
 no_merge:
req_set_nomerge(q, req);
@@ -1329,7 +1339,7 @@ blk_status_t blk_insert_cloned_request(struct 
request_queue *q, struct request *
return BLK_STS_IOERR;
 
if (blk_queue_io_stat(q))
-   blk_account_io_start(rq, true);
+   blk_account_io_start(rq);
 
/*
 * Since we have a scheduler attached on the top device,
@@ -1433,16 +1443,13 @@ void blk_account_io_done(struct request *req, u64 now)
}
 }
 
-void blk_account_io_start(struct request *rq, bool new_io)
+void blk_account_io_start(struct request *rq)
 {
if (!blk_do_io_stat(rq))
return;
 
part_stat_lock();
-   if (!new_io)
-   part_stat_inc(rq->part, merges[rq_data_dir(rq)]);
-   else
-   rq->part = disk_map_sector_rcu(rq->rq_disk, blk_rq_pos(rq));
+   rq->part = disk_map_sector_rcu(rq->rq_disk, blk_rq_pos(rq));
update_io_ticks(rq->part, jiffies, false);
part_stat_unlock();
 }
diff --git a/block/blk-exec.c b/block/blk-exec.c
index e20a852ae432d..85324d53d072f 100644
--- a/block/blk-exec.c
+++ b/block/blk-exec.c
@@ -55,7 +55,7 @@ void blk_execute_rq_nowait(struct request_queue *q, struct 
gendisk *bd_disk,
rq->rq_disk = bd_disk;
rq->end_io = done;
 
-   blk_account_io_start(rq, true);
+   blk_account_io_start(rq);
 
/*
 * don't check dying flag for MQ because the request won't
diff --git a/block/blk-mq.c b/block/blk-mq.c
index cac11945f6023..c606c74463ccd 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1822,7 +1822,7 @@ static void blk_mq_bio_to_request(struct request *rq, 
struct bio *bio,
blk_rq_bio_prep(rq, bio, nr_segs);
blk_crypto_rq_bio_prep(rq, bio, GFP_NOIO);
 
-   blk_account_io_start(rq, true);
+   blk_account_io_start(rq);
 }
 
 static blk_status_t __blk_mq_issue_directly(struct blk_mq_hw_ctx *hctx,
diff --git a/block/blk.h b/block/blk.h
index 0ecba2ab383d6..428f7e5d70a86 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -185,7 +185,7 @@ bool bio_attempt_discard_merge(struct request_queue *q, 
struct request *req,
 bool blk_attempt_plug_merge(struct request_queue *q, struct bio *bio,
unsigned int nr_segs, struct request **same_queue_rq);
 
-void blk_account_io_start(struct request *req, bool new_io);
+void blk_account_io_start(struct request *req);
 void blk_account_io_done(struct request *req, u64 now);
 
 /*
-- 
2.26.2



[PATCH 01/16] block: add disk/bio-based accounting helpers

2020-05-26 Thread Christoph Hellwig
Add two new helpers to simplify I/O accounting for bio based drivers.
Currently these drivers use the generic_start_io_acct and
generic_end_io_acct helpers which have very cumbersome calling
conventions, don't actually return the time they started accounting,
and try to deal with accounting for partitions, which can't happen
for bio based drivers.  The new helpers will be used to subsequently
replace uses of the old helpers.

The main API is the bio based wrappes in blkdev.h, but for zram
which wants to account rw_page based I/O lower level routines are
provided as well.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 block/blk-core.c   | 34 ++
 include/linux/blkdev.h | 28 
 2 files changed, 62 insertions(+)

diff --git a/block/blk-core.c b/block/blk-core.c
index 77e57c2e8d602..8973104f88d90 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1432,6 +1432,40 @@ void blk_account_io_start(struct request *rq, bool 
new_io)
part_stat_unlock();
 }
 
+unsigned long disk_start_io_acct(struct gendisk *disk, unsigned int sectors,
+   unsigned int op)
+{
+   struct hd_struct *part = >part0;
+   const int sgrp = op_stat_group(op);
+   unsigned long now = READ_ONCE(jiffies);
+
+   part_stat_lock();
+   update_io_ticks(part, now, false);
+   part_stat_inc(part, ios[sgrp]);
+   part_stat_add(part, sectors[sgrp], sectors);
+   part_stat_local_inc(part, in_flight[op_is_write(op)]);
+   part_stat_unlock();
+
+   return now;
+}
+EXPORT_SYMBOL(disk_start_io_acct);
+
+void disk_end_io_acct(struct gendisk *disk, unsigned int op,
+   unsigned long start_time)
+{
+   struct hd_struct *part = >part0;
+   const int sgrp = op_stat_group(op);
+   unsigned long now = READ_ONCE(jiffies);
+   unsigned long duration = now - start_time;
+
+   part_stat_lock();
+   update_io_ticks(part, now, true);
+   part_stat_add(part, nsecs[sgrp], jiffies_to_nsecs(duration));
+   part_stat_local_dec(part, in_flight[op_is_write(op)]);
+   part_stat_unlock();
+}
+EXPORT_SYMBOL(disk_end_io_acct);
+
 /*
  * Steal bios from a request and add them to a bio list.
  * The request must not have been partially completed before.
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 7d10f4e632325..6f7ff0fa8fcf8 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1892,4 +1892,32 @@ static inline void blk_wake_io_task(struct task_struct 
*waiter)
wake_up_process(waiter);
 }
 
+unsigned long disk_start_io_acct(struct gendisk *disk, unsigned int sectors,
+   unsigned int op);
+void disk_end_io_acct(struct gendisk *disk, unsigned int op,
+   unsigned long start_time);
+
+#ifdef CONFIG_BLOCK
+/**
+ * bio_start_io_acct - start I/O accounting for bio based drivers
+ * @bio:   bio to start account for
+ *
+ * Returns the start time that should be passed back to bio_end_io_acct().
+ */
+static inline unsigned long bio_start_io_acct(struct bio *bio)
+{
+   return disk_start_io_acct(bio->bi_disk, bio_sectors(bio), bio_op(bio));
+}
+
+/**
+ * bio_end_io_acct - end I/O accounting for bio based drivers
+ * @bio:   bio to end account for
+ * @start: start time returned by bio_start_io_acct()
+ */
+static inline void bio_end_io_acct(struct bio *bio, unsigned long start_time)
+{
+   return disk_end_io_acct(bio->bi_disk, bio_op(bio), start_time);
+}
+#endif /* CONFIG_BLOCK */
+
 #endif
-- 
2.26.2



[PATCH 11/16] block: always use a percpu variable for disk stats

2020-05-26 Thread Christoph Hellwig
percpu variables have a perfectly fine working stub implementation
for UP kernels, so use that.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 block/blk.h   |  2 +-
 block/genhd.c | 12 +++--
 block/partitions/core.c   |  5 ++--
 include/linux/genhd.h | 13 -
 include/linux/part_stat.h | 55 ---
 5 files changed, 18 insertions(+), 69 deletions(-)

diff --git a/block/blk.h b/block/blk.h
index bdf5e94467aa2..0ecba2ab383d6 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -378,7 +378,7 @@ static inline void hd_struct_put(struct hd_struct *part)
 
 static inline void hd_free_part(struct hd_struct *part)
 {
-   free_part_stats(part);
+   free_percpu(part->dkstats);
kfree(part->info);
percpu_ref_exit(>ref);
 }
diff --git a/block/genhd.c b/block/genhd.c
index 094ed90964964..3e7df0a3e6bb0 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -92,7 +92,6 @@ const char *bdevname(struct block_device *bdev, char *buf)
 }
 EXPORT_SYMBOL(bdevname);
 
-#ifdef CONFIG_SMP
 static void part_stat_read_all(struct hd_struct *part, struct disk_stats *stat)
 {
int cpu;
@@ -112,12 +111,6 @@ static void part_stat_read_all(struct hd_struct *part, 
struct disk_stats *stat)
stat->io_ticks += ptr->io_ticks;
}
 }
-#else /* CONFIG_SMP */
-static void part_stat_read_all(struct hd_struct *part, struct disk_stats *stat)
-{
-   memcpy(stat, >dkstats, sizeof(struct disk_stats));
-}
-#endif /* CONFIG_SMP */
 
 static unsigned int part_in_flight(struct request_queue *q,
struct hd_struct *part)
@@ -1688,14 +1681,15 @@ struct gendisk *__alloc_disk_node(int minors, int 
node_id)
 
disk = kzalloc_node(sizeof(struct gendisk), GFP_KERNEL, node_id);
if (disk) {
-   if (!init_part_stats(>part0)) {
+   disk->part0.dkstats = alloc_percpu(struct disk_stats);
+   if (!disk->part0.dkstats) {
kfree(disk);
return NULL;
}
init_rwsem(>lookup_sem);
disk->node_id = node_id;
if (disk_expand_part_tbl(disk, 0)) {
-   free_part_stats(>part0);
+   free_percpu(disk->part0.dkstats);
kfree(disk);
return NULL;
}
diff --git a/block/partitions/core.c b/block/partitions/core.c
index 297004fd22648..78951e33b2d7c 100644
--- a/block/partitions/core.c
+++ b/block/partitions/core.c
@@ -387,7 +387,8 @@ static struct hd_struct *add_partition(struct gendisk 
*disk, int partno,
if (!p)
return ERR_PTR(-EBUSY);
 
-   if (!init_part_stats(p)) {
+   p->dkstats = alloc_percpu(struct disk_stats);
+   if (!p->dkstats) {
err = -ENOMEM;
goto out_free;
}
@@ -468,7 +469,7 @@ static struct hd_struct *add_partition(struct gendisk 
*disk, int partno,
 out_free_info:
kfree(p->info);
 out_free_stats:
-   free_part_stats(p);
+   free_percpu(p->dkstats);
 out_free:
kfree(p);
return ERR_PTR(err);
diff --git a/include/linux/genhd.h b/include/linux/genhd.h
index a9384449465a3..f0d6d77309a54 100644
--- a/include/linux/genhd.h
+++ b/include/linux/genhd.h
@@ -39,15 +39,6 @@ extern struct class block_class;
 #include 
 #include 
 
-struct disk_stats {
-   u64 nsecs[NR_STAT_GROUPS];
-   unsigned long sectors[NR_STAT_GROUPS];
-   unsigned long ios[NR_STAT_GROUPS];
-   unsigned long merges[NR_STAT_GROUPS];
-   unsigned long io_ticks;
-   local_t in_flight[2];
-};
-
 #define PARTITION_META_INFO_VOLNAMELTH 64
 /*
  * Enough for the string representation of any kind of UUID plus NULL.
@@ -72,11 +63,7 @@ struct hd_struct {
seqcount_t nr_sects_seq;
 #endif
unsigned long stamp;
-#ifdef CONFIG_SMP
struct disk_stats __percpu *dkstats;
-#else
-   struct disk_stats dkstats;
-#endif
struct percpu_ref ref;
 
sector_t alignment_offset;
diff --git a/include/linux/part_stat.h b/include/linux/part_stat.h
index ece607607a864..6644197980b92 100644
--- a/include/linux/part_stat.h
+++ b/include/linux/part_stat.h
@@ -4,19 +4,23 @@
 
 #include 
 
+struct disk_stats {
+   u64 nsecs[NR_STAT_GROUPS];
+   unsigned long sectors[NR_STAT_GROUPS];
+   unsigned long ios[NR_STAT_GROUPS];
+   unsigned long merges[NR_STAT_GROUPS];
+   unsigned long io_ticks;
+   local_t in_flight[2];
+};
+
 /*
  * Macros to operate on percpu disk statistics:
  *
- * {disk|part|all}_stat_{add|sub|inc|dec}() modify the stat counters
- * and should be called between disk_stat_lock() and
- * disk_stat_unlock().
+ * {disk|part|all}_stat_{add|sub|inc|dec}() modify the stat counters and should
+ * be called between disk_stat_lock() and disk_stat_unlock().
  *
  * part_stat_read() can be called at any time.
- *
- * part_stat_{add|set_all}() 

[PATCH 02/16] drbd: use bio_{start,end}_io_acct

2020-05-26 Thread Christoph Hellwig
Switch drbd to use the nicer bio accounting helpers.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 drivers/block/drbd/drbd_req.c | 27 ---
 1 file changed, 4 insertions(+), 23 deletions(-)

diff --git a/drivers/block/drbd/drbd_req.c b/drivers/block/drbd/drbd_req.c
index 840c3aef3c5c9..c80a2f1c3c2a7 100644
--- a/drivers/block/drbd/drbd_req.c
+++ b/drivers/block/drbd/drbd_req.c
@@ -21,24 +21,6 @@
 
 static bool drbd_may_do_local_read(struct drbd_device *device, sector_t 
sector, int size);
 
-/* Update disk stats at start of I/O request */
-static void _drbd_start_io_acct(struct drbd_device *device, struct 
drbd_request *req)
-{
-   struct request_queue *q = device->rq_queue;
-
-   generic_start_io_acct(q, bio_op(req->master_bio),
-   req->i.size >> 9, >vdisk->part0);
-}
-
-/* Update disk stats when completing request upwards */
-static void _drbd_end_io_acct(struct drbd_device *device, struct drbd_request 
*req)
-{
-   struct request_queue *q = device->rq_queue;
-
-   generic_end_io_acct(q, bio_op(req->master_bio),
-   >vdisk->part0, req->start_jif);
-}
-
 static struct drbd_request *drbd_req_new(struct drbd_device *device, struct 
bio *bio_src)
 {
struct drbd_request *req;
@@ -263,7 +245,7 @@ void drbd_req_complete(struct drbd_request *req, struct 
bio_and_error *m)
start_new_tl_epoch(first_peer_device(device)->connection);
 
/* Update disk stats */
-   _drbd_end_io_acct(device, req);
+   bio_end_io_acct(req->master_bio, req->start_jif);
 
/* If READ failed,
 * have it be pushed back to the retry work queue,
@@ -1222,16 +1204,15 @@ drbd_request_prepare(struct drbd_device *device, struct 
bio *bio, unsigned long
bio_endio(bio);
return ERR_PTR(-ENOMEM);
}
-   req->start_jif = start_jif;
+
+   /* Update disk stats */
+   req->start_jif = bio_start_io_acct(req->master_bio);
 
if (!get_ldev(device)) {
bio_put(req->private_bio);
req->private_bio = NULL;
}
 
-   /* Update disk stats */
-   _drbd_start_io_acct(device, req);
-
/* process discards always from our submitter thread */
if (bio_op(bio) == REQ_OP_WRITE_ZEROES ||
bio_op(bio) == REQ_OP_DISCARD)
-- 
2.26.2



[PATCH 06/16] dm: use bio_{start,end}_io_acct

2020-05-26 Thread Christoph Hellwig
Switch dm to use the nicer bio accounting helpers.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 drivers/md/dm.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index f215b86664484..3f39fa1ac756e 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -681,11 +681,7 @@ static void start_io_acct(struct dm_io *io)
struct mapped_device *md = io->md;
struct bio *bio = io->orig_bio;
 
-   io->start_time = jiffies;
-
-   generic_start_io_acct(md->queue, bio_op(bio), bio_sectors(bio),
- _disk(md)->part0);
-
+   io->start_time = bio_start_io_acct(bio);
if (unlikely(dm_stats_used(>stats)))
dm_stats_account_io(>stats, bio_data_dir(bio),
bio->bi_iter.bi_sector, bio_sectors(bio),
@@ -698,8 +694,7 @@ static void end_io_acct(struct dm_io *io)
struct bio *bio = io->orig_bio;
unsigned long duration = jiffies - io->start_time;
 
-   generic_end_io_acct(md->queue, bio_op(bio), _disk(md)->part0,
-   io->start_time);
+   bio_end_io_acct(bio, io->start_time);
 
if (unlikely(dm_stats_used(>stats)))
dm_stats_account_io(>stats, bio_data_dir(bio),
-- 
2.26.2



[PATCH 03/16] rsxx: use bio_{start,end}_io_acct

2020-05-26 Thread Christoph Hellwig
Switch rsxx to use the nicer bio accounting helpers.

Signed-off-by: Christoph Hellwig 
Reviewed-by: Konstantin Khlebnikov 
---
 drivers/block/rsxx/dev.c | 19 ++-
 1 file changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/block/rsxx/dev.c b/drivers/block/rsxx/dev.c
index 8ffa8260dcafe..3ba07ab30c84f 100644
--- a/drivers/block/rsxx/dev.c
+++ b/drivers/block/rsxx/dev.c
@@ -96,20 +96,6 @@ static const struct block_device_operations rsxx_fops = {
.ioctl  = rsxx_blkdev_ioctl,
 };
 
-static void disk_stats_start(struct rsxx_cardinfo *card, struct bio *bio)
-{
-   generic_start_io_acct(card->queue, bio_op(bio), bio_sectors(bio),
->gendisk->part0);
-}
-
-static void disk_stats_complete(struct rsxx_cardinfo *card,
-   struct bio *bio,
-   unsigned long start_time)
-{
-   generic_end_io_acct(card->queue, bio_op(bio),
-   >gendisk->part0, start_time);
-}
-
 static void bio_dma_done_cb(struct rsxx_cardinfo *card,
void *cb_data,
unsigned int error)
@@ -121,7 +107,7 @@ static void bio_dma_done_cb(struct rsxx_cardinfo *card,
 
if (atomic_dec_and_test(>pending_dmas)) {
if (!card->eeh_state && card->gendisk)
-   disk_stats_complete(card, meta->bio, meta->start_time);
+   bio_end_io_acct(meta->bio, meta->start_time);
 
if (atomic_read(>error))
bio_io_error(meta->bio);
@@ -167,10 +153,9 @@ static blk_qc_t rsxx_make_request(struct request_queue *q, 
struct bio *bio)
bio_meta->bio = bio;
atomic_set(_meta->error, 0);
atomic_set(_meta->pending_dmas, 0);
-   bio_meta->start_time = jiffies;
 
if (!unlikely(card->halt))
-   disk_stats_start(card, bio);
+   bio_meta->start_time = bio_start_io_acct(bio);
 
dev_dbg(CARD_TO_DEV(card), "BIO[%c]: meta: %p addr8: x%llx size: %d\n",
 bio_data_dir(bio) ? 'W' : 'R', bio_meta,
-- 
2.26.2



Re: [PATCH 01/16] block: add disk/bio-based accounting helpers

2020-05-26 Thread Christoph Hellwig
On Mon, May 25, 2020 at 03:28:07PM +0300, Konstantin Khlebnikov wrote:
> I think it would be better to leave this jiffies legacy nonsense in
> callers and pass here request duration in nanoseconds.

jiffies is what the existing interfaces uses.  But now that they come
from the start helper fixing this will become easier.  I'll do that
as a follow on, as I'd rather not bloat this series even more.


Re: [PATCH v4 3/7] KVM: PPC: Remove redundant kvm_run from vcpu_arch

2020-05-26 Thread Tianjia Zhang




On 2020/5/27 12:20, Paul Mackerras wrote:

On Mon, Apr 27, 2020 at 12:35:10PM +0800, Tianjia Zhang wrote:

The 'kvm_run' field already exists in the 'vcpu' structure, which
is the same structure as the 'kvm_run' in the 'vcpu_arch' and
should be deleted.

Signed-off-by: Tianjia Zhang 


Thanks, patches 3 and 4 of this series applied to my kvm-ppc-next branch.

Paul.



Thanks for your suggestion, for 5/7, I will submit a new version patch.

Thanks,
Tianjia


Re: [PATCH 1/1] nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()

2020-05-26 Thread Keith Busch
Fixes: fa46c6fb5d61 ("nvme/pci: move cqe check after device shutdown")


Re: KVM broken after suspend in most recent kernels.

2020-05-26 Thread Sean Christopherson
On Mon, May 25, 2020 at 09:15:57PM +0800, Brad Campbell wrote:
> >When you mean that KVM is broken after suspend, you mean that you can't
> >start new VMs after suspend, or do VMs that were running before suspend
> >break?  I see the later on my machine. I have AMD system though, so most
> >likely this is another bug.
> >
> >Looking at the commit, I suspect that we indeed should set the IA32_FEAT_CTL
> >after resume from ram, since suspend to ram might count as a complete CPU
> >reset.
> >
> 
> One of those "I should have clarified that" moments immediately after I
> pressed send.  I've not tried suspending with a VM running. It's "can't start
> new VMs after suspend".

Don't bother testing suspending with a VM, the only thing that will be
different is that your system will hang on resume instead when running a
VM.  If there are active VMs, KVM automatically re-enables VMX via VMXON
after resume, and VMXON is what's faulting.

Odds are good the firmware simply isn't initializing IA32_FEAT_CTL, ever.
The kernel handles the boot-time case, but I (obviously) didn't consider
the suspend case.  I'll work on a patch.


Re: [PATCH] media: omap3isp: Shuffle cacheflush.h and include mm.h

2020-05-26 Thread Christoph Hellwig
On Tue, May 26, 2020 at 09:34:27PM -0700, Nathan Chancellor wrote:
> After mm.h was removed from the asm-generic version of cacheflush.h,
> s390 allyesconfig shows several warnings of the following nature:

Hmm, I'm pretty sure I sent the same fix a few days ago in response to
a build bot report.  But if that didn't get picked up I'm fine with
your version of it as well of course:

Acked-by: Christoph Hellwig 


Re: [PATCH bpf-next] libbpf: Export bpf_object__load_vmlinux_btf

2020-05-26 Thread Andrii Nakryiko
On Tue, May 26, 2020 at 7:09 PM Daniel Xu  wrote:
>
> Right now the libbpf model encourages loading the entire object at once.
> In this model, libbpf handles loading BTF from vmlinux for us. However,
> it can be useful to selectively load certain maps and programs inside an
> object without loading everything else.

There is no way to selectively load or not load a map. All maps are
created, unless they are reusing map FD or pinned instances. See
below, I'd like to understand the use case better.

>
> In the latter model, there was perviously no way to load BTF on-demand.
> This commit exports the bpf_object__load_vmlinux_btf such that we are
> able to load BTF on demand.
>

Let's start with the real problem, not a solution. Do you have
specific use case where you need bpf_object__load_vmlinux_btf()? It
might not do anything if none of BPF programs in the object requires
BTF, because it's very much tightly coupled with loading bpf_object as
a whole model. I'd like to understand what you are after with this,
before exposing internal implementation details as an API.

> Signed-off-by: Daniel Xu 
> ---
>  tools/lib/bpf/libbpf.c   | 2 +-
>  tools/lib/bpf/libbpf.h   | 1 +
>  tools/lib/bpf/libbpf.map | 1 +
>  3 files changed, 3 insertions(+), 1 deletion(-)
>

[...]


Re: [PATCH v5 0/4] Charge loop device i/o to issuing cgroup

2020-05-26 Thread Christoph Hellwig
On Tue, May 26, 2020 at 10:28:03AM -0400, Dan Schatzberg wrote:
> Will do - I'll split out the lock-use refactor into a separate
> patch. Do you have particular concerns about re-using the existing
> spinlock? Its existing use is not contended so I didn't see any harm
> in extending its use. I'll add this justification to the commit
> message as well, but I'm tempted to leave the re-use as is instead of
> creating a new lock.

Please don't share a lock for entirely separate critical sections that
are used from different contexts.


[PATCH v2] net: phy: at803x: add cable diagnostics support for ATH9331 and ATH8032

2020-05-26 Thread Oleksij Rempel
Add support for Atheros 100Base-T PHYs. The only difference seems to be
the ability to test 2 pairs instead of 4 and the lack of 1000Base-T
specific register.

Only the ATH9331 was tested with this patch.

Signed-off-by: Oleksij Rempel 
Reviewed-by: Andrew Lunn 
Reviewed-by: Florian Fainelli 
---
 drivers/net/phy/at803x.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index acd51b29a476..4b9dd43b5b5b 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -920,10 +920,16 @@ static int at803x_cable_test_one_pair(struct phy_device 
*phydev, int pair)
 static int at803x_cable_test_get_status(struct phy_device *phydev,
bool *finished)
 {
-   unsigned long pair_mask = 0xf;
+   unsigned long pair_mask;
int retries = 20;
int pair, ret;
 
+   if (phydev->phy_id == ATH9331_PHY_ID ||
+   phydev->phy_id == ATH8032_PHY_ID)
+   pair_mask = 0x3;
+   else
+   pair_mask = 0xf;
+
*finished = false;
 
/* According to the datasheet the CDT can be performed when
@@ -958,7 +964,9 @@ static int at803x_cable_test_start(struct phy_device 
*phydev)
 */
phy_write(phydev, MII_BMCR, BMCR_ANENABLE);
phy_write(phydev, MII_ADVERTISE, ADVERTISE_CSMA);
-   phy_write(phydev, MII_CTRL1000, 0);
+   if (phydev->phy_id != ATH9331_PHY_ID &&
+   phydev->phy_id != ATH8032_PHY_ID)
+   phy_write(phydev, MII_CTRL1000, 0);
 
/* we do all the (time consuming) work later */
return 0;
@@ -1032,6 +1040,7 @@ static struct phy_driver at803x_driver[] = {
.name   = "Qualcomm Atheros AR8032",
.probe  = at803x_probe,
.remove = at803x_remove,
+   .flags  = PHY_POLL_CABLE_TEST,
.config_init= at803x_config_init,
.link_change_notify = at803x_link_change_notify,
.set_wol= at803x_set_wol,
@@ -1041,15 +1050,20 @@ static struct phy_driver at803x_driver[] = {
/* PHY_BASIC_FEATURES */
.ack_interrupt  = at803x_ack_interrupt,
.config_intr= at803x_config_intr,
+   .cable_test_start   = at803x_cable_test_start,
+   .cable_test_get_status  = at803x_cable_test_get_status,
 }, {
/* ATHEROS AR9331 */
PHY_ID_MATCH_EXACT(ATH9331_PHY_ID),
.name   = "Qualcomm Atheros AR9331 built-in PHY",
.suspend= at803x_suspend,
.resume = at803x_resume,
+   .flags  = PHY_POLL_CABLE_TEST,
/* PHY_BASIC_FEATURES */
.ack_interrupt  = _ack_interrupt,
.config_intr= _config_intr,
+   .cable_test_start   = at803x_cable_test_start,
+   .cable_test_get_status  = at803x_cable_test_get_status,
 } };
 
 module_phy_driver(at803x_driver);
-- 
2.26.2



Re: [PATCH bpf-next 2/4] bpf: Implement bpf_local_storage for inodes

2020-05-26 Thread Christoph Hellwig
On Tue, May 26, 2020 at 06:33:34PM +0200, KP Singh wrote:
> From: KP Singh 
> 
> Similar to bpf_local_storage for sockets, add local storage for inodes.
> The life-cycle of storage is managed with the life-cycle of the inode.
> i.e. the storage is destroyed along with the owning inode.
> 
> Since, the intention is to use this in LSM programs, the destruction is
> done after security_inode_free in __destroy_inode.

NAK onbloating the inode structure.  Please find an out of line way
to store your information.


Re: [PATCH 1/1] nvme-pci: avoid race between nvme_reap_pending_cqes() and nvme_poll()

2020-05-26 Thread Christoph Hellwig
Can you add a Fixes tag so that this gets queued up for -stable properly?



Re: [PATCH] perf jvmti: remove redundant jitdump line table entries

2020-05-26 Thread Ian Rogers
On Thu, May 21, 2020 at 11:54 PM Nick Gasson  wrote:
>
> For each PC/BCI pair in the JVMTI compiler inlining record table, the
> jitdump plugin emits debug line table entries for every source line in
> the method preceding that BCI. Instead only emit one source line per
> PC/BCI pair. Reported by Ian Rogers. This reduces the .dump size for
> SPECjbb from ~230MB to ~40MB.

Great result, thanks! I note there is a lack of symbolization when
benchmarking a few Java applications. I'll try to see if there's a
sensible resolution for those.

> Also fix an error in the DWARF line table state machine where addresses
> are incorrectly offset by -0x40 (GEN_ELF_TEXT_OFFSET). This can be seen
> with `objdump -S` on the ELF files after perf inject.

It'd be better to make this into two patches. Also on acme's perf/core
branch if possible:
https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/log/?h=perf/core

> Signed-off-by: Nick Gasson 
> ---
>  tools/perf/jvmti/libjvmti.c| 73 +-
>  tools/perf/util/genelf_debug.c |  4 +-
>  2 files changed, 30 insertions(+), 47 deletions(-)
>
> diff --git a/tools/perf/jvmti/libjvmti.c b/tools/perf/jvmti/libjvmti.c
> index a9a056d68416..398e4ba6498d 100644
> --- a/tools/perf/jvmti/libjvmti.c
> +++ b/tools/perf/jvmti/libjvmti.c
> @@ -32,38 +32,41 @@ static void print_error(jvmtiEnv *jvmti, const char *msg, 
> jvmtiError ret)
>
>  #ifdef HAVE_JVMTI_CMLR
>  static jvmtiError
> -do_get_line_numbers(jvmtiEnv *jvmti, void *pc, jmethodID m, jint bci,
> -   jvmti_line_info_t *tab, jint *nr)
> +do_get_line_number(jvmtiEnv *jvmti, void *pc, jmethodID m, jint bci,
> +  jvmti_line_info_t *tab)
>  {
> -   jint i, lines = 0;
> -   jint nr_lines = 0;
> +   jint i, nr_lines = 0;
> jvmtiLineNumberEntry *loc_tab = NULL;
> jvmtiError ret;
> +   jint src_line = -1;
>
> ret = (*jvmti)->GetLineNumberTable(jvmti, m, _lines, _tab);
> if (ret == JVMTI_ERROR_ABSENT_INFORMATION || ret == 
> JVMTI_ERROR_NATIVE_METHOD) {
> /* No debug information for this method */
> -   *nr = 0;
> -   return JVMTI_ERROR_NONE;
> +   return ret;
> } else if (ret != JVMTI_ERROR_NONE) {
> print_error(jvmti, "GetLineNumberTable", ret);
> return ret;
> }
>
> -   for (i = 0; i < nr_lines; i++) {
> -   if (loc_tab[i].start_location < bci) {
> -   tab[lines].pc = (unsigned long)pc;
> -   tab[lines].line_number = loc_tab[i].line_number;
> -   tab[lines].discrim = 0; /* not yet used */
> -   tab[lines].methodID = m;
> -   lines++;
> -   } else {
> -   break;
> -   }
> +   for (i = 0; i < nr_lines && loc_tab[i].start_location <= bci; i++) {
> +   src_line = i;
> +   }
> +
> +   if (src_line != -1) {
> +   tab->pc = (unsigned long)pc;
> +   tab->line_number = loc_tab[src_line].line_number;
> +   tab->discrim = 0; /* not yet used */
> +   tab->methodID = m;
> +
> +   ret = JVMTI_ERROR_NONE;
> +   } else {
> +   ret = JVMTI_ERROR_ABSENT_INFORMATION;
> }
> +
> (*jvmti)->Deallocate(jvmti, (unsigned char *)loc_tab);
> -   *nr = lines;
> -   return JVMTI_ERROR_NONE;
> +
> +   return ret;
>  }
>
>  static jvmtiError
> @@ -71,9 +74,8 @@ get_line_numbers(jvmtiEnv *jvmti, const void *compile_info, 
> jvmti_line_info_t **
>  {
> const jvmtiCompiledMethodLoadRecordHeader *hdr;
> jvmtiCompiledMethodLoadInlineRecord *rec;
> -   jvmtiLineNumberEntry *lne = NULL;
> PCStackInfo *c;
> -   jint nr, ret;
> +   jint ret;
> int nr_total = 0;
> int i, lines_total = 0;
>
> @@ -86,24 +88,7 @@ get_line_numbers(jvmtiEnv *jvmti, const void 
> *compile_info, jvmti_line_info_t **
> for (hdr = compile_info; hdr != NULL; hdr = hdr->next) {
> if (hdr->kind == JVMTI_CMLR_INLINE_INFO) {
> rec = (jvmtiCompiledMethodLoadInlineRecord *)hdr;
> -   for (i = 0; i < rec->numpcs; i++) {
> -   c = rec->pcinfo + i;
> -   nr = 0;
> -   /*
> -* unfortunately, need a tab to get the 
> number of lines!
> -*/
> -   ret = (*jvmti)->GetLineNumberTable(jvmti, 
> c->methods[0], , );
> -   if (ret == JVMTI_ERROR_NONE) {
> -   /* free what was allocated for 
> nothing */
> -   (*jvmti)->Deallocate(jvmti, (unsigned 
> char *)lne);
> -   nr_total += (int)nr;
> -   

Re: [PATCH v8 00/13] add ecspi ERR009165 for i.mx6/7 soc family

2020-05-26 Thread Sascha Hauer
On Thu, May 21, 2020 at 04:34:12AM +0800, Robin Gong wrote:
> There is ecspi ERR009165 on i.mx6/7 soc family, which cause FIFO
> transfer to be send twice in DMA mode. Please get more information from:
> https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf. The workaround is adding
> new sdma ram script which works in XCH  mode as PIO inside sdma instead
> of SMC mode, meanwhile, 'TX_THRESHOLD' should be 0. The issue should be
> exist on all legacy i.mx6/7 soc family before i.mx6ul.
> NXP fix this design issue from i.mx6ul, so newer chips including i.mx6ul/
> 6ull/6sll do not need this workaroud anymore. All other i.mx6/7/8 chips
> still need this workaroud. This patch set add new 'fsl,imx6ul-ecspi'
> for ecspi driver and 'ecspi_fixed' in sdma driver to choose if need errata
> or not.
> The first two reverted patches should be the same issue, though, it
> seems 'fixed' by changing to other shp script. Hope Sean or Sascha could
> have the chance to test this patch set if could fix their issues.
> Besides, enable sdma support for i.mx8mm/8mq and fix ecspi1 not work
> on i.mx8mm because the event id is zero.

For the series:

Acked-by: Sascha Hauer 

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


Re: [RFC 02/16] x86/kvm: Introduce KVM memory protection feature

2020-05-26 Thread Sean Christopherson
On Mon, May 25, 2020 at 06:15:25PM +0300, Kirill A. Shutemov wrote:
> On Mon, May 25, 2020 at 04:58:51PM +0200, Vitaly Kuznetsov wrote:
> > > @@ -727,6 +734,15 @@ static void __init kvm_init_platform(void)
> > >  {
> > >   kvmclock_init();
> > >   x86_platform.apic_post_init = kvm_apic_init;
> > > +
> > > + if (kvm_para_has_feature(KVM_FEATURE_MEM_PROTECTED)) {
> > > + if (kvm_hypercall0(KVM_HC_ENABLE_MEM_PROTECTED)) {
> > > + pr_err("Failed to enable KVM memory protection\n");
> > > + return;
> > > + }
> > > +
> > > + mem_protected = true;
> > > + }
> > >  }
> > 
> > Personally, I'd prefer to do this via setting a bit in a KVM-specific
> > MSR instead. The benefit is that the guest doesn't need to remember if
> > it enabled the feature or not, it can always read the config msr. May
> > come handy for e.g. kexec/kdump.
> 
> I think we would need to remember it anyway. Accessing MSR is somewhat
> expensive. But, okay, I can rework it MSR if needed.

I think Vitaly is talking about the case where the kernel can't easily get
at its cached state, e.g. after booting into a new kernel.  The kernel would
still have an X86_FEATURE bit or whatever, providing a virtual MSR would be
purely for rare slow paths.

That being said, a hypercall plus CPUID bit might be better, e.g. that'd
allow the guest to query the state without risking a #GP.

> Note, that we can avoid the enabling algother, if we modify BIOS to deal
> with private/shared memory. Currently BIOS get system crash if we enable
> the feature from time zero.

Which would mesh better with a CPUID feature bit.


Re: [v2,1/1] hwmon:(nct7904) Set default timeout

2020-05-26 Thread Guenter Roeck
On Wed, May 27, 2020 at 03:49:50AM +, yuechao.z...@advantech.com.cn wrote:
> From: Yuechao Zhao 
> 
> The timeout module parameter should not be used for setting the default
> timeout. Because, if you set the timeout = 0, the default timeout will
> be meaningless. And the timeout module parameter of 0 means "no timeout
> module paraameter specified".
> 
> Signed-off-by: Yuechao Zhao 

You should also replace

static int timeout = WATCHDOG_TIMEOUT;

with

static int timeout;

to ensure that the module parameter is only evaluated if it is actually
set. Otherwise your patch has no real impact except if someone explicitly
specifies a timeout parameter of 0 which doesn't really make much sense.

Thanks,
Guenter

> ---
> - modify subject to 'hwmon:(nct7904) Set default timeout'
> ---
>  drivers/hwmon/nct7904.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/nct7904.c b/drivers/hwmon/nct7904.c
> index 18c95be..27eb276 100644
> --- a/drivers/hwmon/nct7904.c
> +++ b/drivers/hwmon/nct7904.c
> @@ -1147,7 +1147,7 @@ static int nct7904_probe(struct i2c_client *client,
>   data->wdt.ops = _wdt_ops;
>   data->wdt.info = _wdt_info;
>  
> - data->wdt.timeout = timeout * 60; /* in seconds */
> + data->wdt.timeout = WATCHDOG_TIMEOUT * 60; /* Set default timeout */
>   data->wdt.min_timeout = MIN_TIMEOUT;
>   data->wdt.max_timeout = MAX_TIMEOUT;
>   data->wdt.parent = >dev;
> -- 
> 1.8.3.1
> 


Re: [PATCH] sparc32: register memory occupied by kernel as memblock.memory

2020-05-26 Thread Mike Rapoport
Andrew, David,

Any comments on this?

On Sun, May 24, 2020 at 07:53:58PM +0300, Mike Rapoport wrote:
> From: Mike Rapoport 
> 
> sparc32 never registered the memory occupied by the kernel image with
> memblock_add() and it only reserved this memory with meblock_reserve().
> 
> With openbios as system firmware, the memory occupied by the kernel is
> reserved in openbios and removed from mem.available. The prom setup code in
> the kernel uses mem.available to set up the memory banks and essentially
> there is a hole for the memory occupied by the kernel image.
> 
> Later in bootmem_init() this memory is memblock_reserve()d.
> 
> Up until recently, memmap initialization would call __init_single_page()
> for the pages in that hole, the free_low_memory_core_early() would mark
> them as reserved and everything would be Ok.
> 
> After the change in memmap initialization introduced by the commit "mm:
> memmap_init: iterate over memblock regions rather that check each PFN", the
> hole is skipped and the page structs for it are not initialized. And when
> they are passed from memblock to page allocator as reserved, the latter
> gets confused.
> 
> Simply registering the memory occupied by the kernel with memblock_add()
> resolves this issue.
> 
> Tested on qemu-system-sparc with Debian Etch [1] userspace.
> 
> [1] 
> https://people.debian.org/~aurel32/qemu/sparc/debian_etch_sparc_small.qcow2
> 
> Signed-off-by: Mike Rapoport 
> Link: https://lkml.kernel.org/r/2020051750.GA87467@roeck-us.nlet/ 
> ---
> 
> David,
> 
> I'd really appreciate your Ack or an explanation where my analysis is wrong :)
> 
>  arch/sparc/mm/init_32.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/sparc/mm/init_32.c b/arch/sparc/mm/init_32.c
> index e45160839f79..eb2946b1df8a 100644
> --- a/arch/sparc/mm/init_32.c
> +++ b/arch/sparc/mm/init_32.c
> @@ -192,6 +192,7 @@ unsigned long __init bootmem_init(unsigned long 
> *pages_avail)
>   /* Reserve the kernel text/data/bss. */
>   size = (start_pfn << PAGE_SHIFT) - phys_base;
>   memblock_reserve(phys_base, size);
> + memblock_add(phys_base, size);
>  
>   size = memblock_phys_mem_size() - memblock_reserved_size();
>   *pages_avail = (size >> PAGE_SHIFT) - high_pages;
> -- 
> 2.26.2
> 

-- 
Sincerely yours,
Mike.


Re: [PATCH 4/6] iio: dac: ad5686: Constify static struct iio_chan_spec

2020-05-26 Thread Ardelean, Alexandru
On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> [External]
> 
> These are never modified and can be made const to allow the compiler to
> put it in read-only memory.
> 
> Before:
>textdata bss dec hex filename
>6642   12608  64   193144b72 drivers/iio/dac/ad5686.o
> 
> After:
>textdata bss dec hex filename
>   169462304  64   193144b72 drivers/iio/dac/ad5686.o
> 

Acked-by: Alexandru Ardelean 

> Signed-off-by: Rikard Falkeborn 
> ---
>  drivers/iio/dac/ad5686.c | 8 
>  drivers/iio/dac/ad5686.h | 2 +-
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iio/dac/ad5686.c b/drivers/iio/dac/ad5686.c
> index 8dd67da0a7da..6de48f618c95 100644
> --- a/drivers/iio/dac/ad5686.c
> +++ b/drivers/iio/dac/ad5686.c
> @@ -206,12 +206,12 @@ static const struct iio_chan_spec_ext_info
> ad5686_ext_info[] = {
>  }
>  
>  #define DECLARE_AD5693_CHANNELS(name, bits, _shift)  \
> -static struct iio_chan_spec name[] = {   \
> +static const struct iio_chan_spec name[] = { \
>   AD5868_CHANNEL(0, 0, bits, _shift), \
>  }
>  
>  #define DECLARE_AD5686_CHANNELS(name, bits, _shift)  \
> -static struct iio_chan_spec name[] = {   \
> +static const struct iio_chan_spec name[] = { \
>   AD5868_CHANNEL(0, 1, bits, _shift), \
>   AD5868_CHANNEL(1, 2, bits, _shift), \
>   AD5868_CHANNEL(2, 4, bits, _shift), \
> @@ -219,7 +219,7 @@ static struct iio_chan_spec name[] = {
>   \
>  }
>  
>  #define DECLARE_AD5676_CHANNELS(name, bits, _shift)  \
> -static struct iio_chan_spec name[] = {   \
> +static const struct iio_chan_spec name[] = { \
>   AD5868_CHANNEL(0, 0, bits, _shift), \
>   AD5868_CHANNEL(1, 1, bits, _shift), \
>   AD5868_CHANNEL(2, 2, bits, _shift), \
> @@ -231,7 +231,7 @@ static struct iio_chan_spec name[] = {
>   \
>  }
>  
>  #define DECLARE_AD5679_CHANNELS(name, bits, _shift)  \
> -static struct iio_chan_spec name[] = {   \
> +static const struct iio_chan_spec name[] = { \
>   AD5868_CHANNEL(0, 0, bits, _shift), \
>   AD5868_CHANNEL(1, 1, bits, _shift), \
>   AD5868_CHANNEL(2, 2, bits, _shift), \
> diff --git a/drivers/iio/dac/ad5686.h b/drivers/iio/dac/ad5686.h
> index 52009b5eef88..a15f2970577e 100644
> --- a/drivers/iio/dac/ad5686.h
> +++ b/drivers/iio/dac/ad5686.h
> @@ -104,7 +104,7 @@ typedef int (*ad5686_read_func)(struct ad5686_state
> *st, u8 addr);
>  struct ad5686_chip_info {
>   u16 int_vref_mv;
>   unsigned intnum_channels;
> - struct iio_chan_spec*channels;
> + const struct iio_chan_spec  *channels;
>   enum ad5686_regmap_type regmap_type;
>  };
>  


[PATCH] xattr: fix EOPNOTSUPP if fs and security xattrs disabled

2020-05-26 Thread Gao Xiang
commit f549d6c18c0e ("[PATCH] Generic VFS fallback for security xattrs")
introduces a behavior change of listxattr path therefore listxattr(2)
won't report EOPNOTSUPP correctly if fs and security xattrs disabled.
However it was clearly recorded in manpage all the time.

Cc: Alexander Viro 
Cc: Stephen Smalley 
Cc: Chengguang Xu 
Cc: Chao Yu 
Signed-off-by: Gao Xiang 
---

Noticed when reviewing Chengguang's patch for erofs [1] (together
with ext2, f2fs). I'm not sure if it's the best approach but it
seems that security_inode_listsecurity() has other users and it
mainly focus on reporting these security xattrs...

[1] https://lore.kernel.org/r/20200526090343.22794-1-cgxu...@mykernel.net

Thanks,
Gao Xiang

 fs/xattr.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/fs/xattr.c b/fs/xattr.c
index 91608d9bfc6a..f339a67db521 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -352,13 +352,15 @@ vfs_listxattr(struct dentry *dentry, char *list, size_t 
size)
error = security_inode_listxattr(dentry);
if (error)
return error;
-   if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR)) {
-   error = inode->i_op->listxattr(dentry, list, size);
-   } else {
-   error = security_inode_listsecurity(inode, list, size);
-   if (size && error > size)
-   error = -ERANGE;
-   }
+
+   if (inode->i_op->listxattr && (inode->i_opflags & IOP_XATTR))
+   return inode->i_op->listxattr(dentry, list, size);
+
+   if (!IS_ENABLED(CONFIG_SECURITY))
+   return -EOPNOTSUPP;
+   error = security_inode_listsecurity(inode, list, size);
+   if (size && error > size)
+   error = -ERANGE;
return error;
 }
 EXPORT_SYMBOL_GPL(vfs_listxattr);
-- 
2.24.0



[PATCH] media: omap3isp: Shuffle cacheflush.h and include mm.h

2020-05-26 Thread Nathan Chancellor
After mm.h was removed from the asm-generic version of cacheflush.h,
s390 allyesconfig shows several warnings of the following nature:

In file included from ./arch/s390/include/generated/asm/cacheflush.h:1,
 from drivers/media/platform/omap3isp/isp.c:42:
./include/asm-generic/cacheflush.h:16:42: warning: 'struct mm_struct'
declared inside parameter list will not be visible outside of this
definition or declaration

cacheflush.h does not include mm.h nor does it include any forward
declaration of these structures hence the warning. To avoid this,
include mm.h explicitly in this file and shuffle cacheflush.h below it.

Fixes: 19c0054597a0 ("asm-generic: don't include  in cacheflush.h")
Signed-off-by: Nathan Chancellor 
---

I am aware the fixes tag is kind of irrelevant because that SHA will
change in the next linux-next revision and this will probably get folded
into the original patch anyways but still.

The other solution would be to add forward declarations of these structs
to the top of cacheflush.h, I just chose to do what Christoph did in the
original patch. I am happy to do that instead if you all feel that is
better.

 drivers/media/platform/omap3isp/isp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/omap3isp/isp.c 
b/drivers/media/platform/omap3isp/isp.c
index a4ee6b86663e..54106a768e54 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -39,8 +39,6 @@
  * Troy Laramy 
  */
 
-#include 
-
 #include 
 #include 
 #include 
@@ -49,6 +47,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,6 +57,8 @@
 #include 
 #include 
 
+#include 
+
 #ifdef CONFIG_ARM_DMA_USE_IOMMU
 #include 
 #endif
-- 
2.27.0.rc0



[PATCH] iio: cros_ec: Reapply range at resume

2020-05-26 Thread Gwendal Grignou
EC does not currently preserve range across sensor reinit.
If sensor is powered down at suspend, it will default to the EC default
range at resume, not the range set by the host.

Save range if modified, and apply at resume.

Signed-off-by: Gwendal Grignou 
---
 .../common/cros_ec_sensors/cros_ec_sensors.c  |  5 +
 .../cros_ec_sensors/cros_ec_sensors_core.c| 21 +++
 drivers/iio/light/cros_ec_light_prox.c|  6 +-
 drivers/iio/pressure/cros_ec_baro.c   |  8 +--
 .../linux/iio/common/cros_ec_sensors_core.h   | 11 +-
 5 files changed, 47 insertions(+), 4 deletions(-)

diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c 
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
index a66941fdb3855..130ab8ce0269b 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors.c
@@ -200,6 +200,10 @@ static int cros_ec_sensors_write(struct iio_dev *indio_dev,
st->core.param.sensor_range.roundup = 1;
 
ret = cros_ec_motion_send_host_cmd(>core, 0);
+   if (ret == 0) {
+   st->core.range_updated = true;
+   st->core.curr_range = val;
+   }
break;
default:
ret = cros_ec_sensors_core_write(
@@ -315,6 +319,7 @@ MODULE_DEVICE_TABLE(platform, cros_ec_sensors_ids);
 static struct platform_driver cros_ec_sensors_platform_driver = {
.driver = {
.name   = "cros-ec-sensors",
+   .pm = _ec_sensors_pm_ops,
},
.probe  = cros_ec_sensors_probe,
.id_table   = cros_ec_sensors_ids,
diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c 
b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
index c831915ca7e56..cda459b612067 100644
--- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
+++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c
@@ -824,5 +824,26 @@ int cros_ec_sensors_core_write(struct 
cros_ec_sensors_core_state *st,
 }
 EXPORT_SYMBOL_GPL(cros_ec_sensors_core_write);
 
+static int __maybe_unused cros_ec_sensors_resume(struct device *dev)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+   struct iio_dev *indio_dev = platform_get_drvdata(pdev);
+   struct cros_ec_sensors_core_state *st = iio_priv(indio_dev);
+   int ret = 0;
+
+   if (st->range_updated) {
+   mutex_lock(>cmd_lock);
+   st->param.cmd = MOTIONSENSE_CMD_SENSOR_RANGE;
+   st->param.sensor_range.data = st->curr_range;
+   st->param.sensor_range.roundup = 1;
+   ret = cros_ec_motion_send_host_cmd(st, 0);
+   mutex_unlock(>cmd_lock);
+   }
+   return ret;
+}
+
+SIMPLE_DEV_PM_OPS(cros_ec_sensors_pm_ops, NULL, cros_ec_sensors_resume);
+EXPORT_SYMBOL_GPL(cros_ec_sensors_pm_ops);
+
 MODULE_DESCRIPTION("ChromeOS EC sensor hub core functions");
 MODULE_LICENSE("GPL v2");
diff --git a/drivers/iio/light/cros_ec_light_prox.c 
b/drivers/iio/light/cros_ec_light_prox.c
index 2198b50909ed0..fed79ba27fda5 100644
--- a/drivers/iio/light/cros_ec_light_prox.c
+++ b/drivers/iio/light/cros_ec_light_prox.c
@@ -145,8 +145,11 @@ static int cros_ec_light_prox_write(struct iio_dev 
*indio_dev,
break;
case IIO_CHAN_INFO_CALIBSCALE:
st->core.param.cmd = MOTIONSENSE_CMD_SENSOR_RANGE;
-   st->core.param.sensor_range.data = (val << 16) | (val2 / 100);
+   st->core.curr_range = (val << 16) | (val2 / 100);
+   st->core.param.sensor_range.data = st->core.curr_range;
ret = cros_ec_motion_send_host_cmd(>core, 0);
+   if (ret == 0)
+   st->core.range_updated = true;
break;
default:
ret = cros_ec_sensors_core_write(>core, chan, val, val2,
@@ -256,6 +259,7 @@ MODULE_DEVICE_TABLE(platform, cros_ec_light_prox_ids);
 static struct platform_driver cros_ec_light_prox_platform_driver = {
.driver = {
.name   = "cros-ec-light-prox",
+   .pm = _ec_sensors_pm_ops,
},
.probe  = cros_ec_light_prox_probe,
.id_table   = cros_ec_light_prox_ids,
diff --git a/drivers/iio/pressure/cros_ec_baro.c 
b/drivers/iio/pressure/cros_ec_baro.c
index c079b89600824..f0938b6fbba07 100644
--- a/drivers/iio/pressure/cros_ec_baro.c
+++ b/drivers/iio/pressure/cros_ec_baro.c
@@ -96,8 +96,11 @@ static int cros_ec_baro_write(struct iio_dev *indio_dev,
/* Always roundup, so caller gets at least what it asks for. */
st->core.param.sensor_range.roundup = 1;
 
-   if (cros_ec_motion_send_host_cmd(>core, 0))
-   ret = -EIO;
+   ret = cros_ec_motion_send_host_cmd(>core, 0);
+   if (ret == 0) {
+   

Re: [PATCH 3/6] iio: dac: ad5592r-base: Constify struct iio_chan_spec_ext_info

2020-05-26 Thread Ardelean, Alexandru
On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> [External]
> 
> ad5592r_ext_info is not modified and can be made const to allow the
> compiler to put it in read-only memory.
> 
> Before:
>textdata bss dec hex filename
>   132932088 256   156373d15 drivers/iio/dac/ad5592r-base.o
> 
> After:
>textdata bss dec hex filename
>   134211960 256   156373d15 drivers/iio/dac/ad5592r-base.o
> 

Acked-by: Alexandru Ardelean 

> Signed-off-by: Rikard Falkeborn 
> ---
>  drivers/iio/dac/ad5592r-base.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/dac/ad5592r-base.c b/drivers/iio/dac/ad5592r-
> base.c
> index 410e90e5f75f..7402f67a551d 100644
> --- a/drivers/iio/dac/ad5592r-base.c
> +++ b/drivers/iio/dac/ad5592r-base.c
> @@ -484,7 +484,7 @@ static ssize_t ad5592r_show_scale_available(struct
> iio_dev *iio_dev,
>   st->scale_avail[1][0], st->scale_avail[1][1]);
>  }
>  
> -static struct iio_chan_spec_ext_info ad5592r_ext_info[] = {
> +static const struct iio_chan_spec_ext_info ad5592r_ext_info[] = {
>   {
>.name = "scale_available",
>.read = ad5592r_show_scale_available,


Re: [PATCH 2/6] iio: dac: ad5380: Constify struct iio_chan_spec_ext_info

2020-05-26 Thread Ardelean, Alexandru
On Tue, 2020-05-26 at 23:02 +0200, Rikard Falkeborn wrote:
> [External]
> 
> ad5380_ext_info is not modified and can be made const to allow the
> compiler to put it in read-only memory.
> 
> Before:
>textdata bss dec hex filename
>   120603280 192   155323cac drivers/iio/dac/ad5380.o
> 
> After:
>textdata bss dec hex filename
>   122523088 192   155323cac drivers/iio/dac/ad5380.o
> 

Acked-by: Alexandru Ardelean 

> Signed-off-by: Rikard Falkeborn 
> ---
>  drivers/iio/dac/ad5380.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/dac/ad5380.c b/drivers/iio/dac/ad5380.c
> index b37e5675f716..04c74cc1a4ec 100644
> --- a/drivers/iio/dac/ad5380.c
> +++ b/drivers/iio/dac/ad5380.c
> @@ -240,7 +240,7 @@ static const struct iio_info ad5380_info = {
>   .write_raw = ad5380_write_raw,
>  };
>  
> -static struct iio_chan_spec_ext_info ad5380_ext_info[] = {
> +static const struct iio_chan_spec_ext_info ad5380_ext_info[] = {
>   {
>   .name = "powerdown",
>   .read = ad5380_read_dac_powerdown,


Re: [PATCH v4 3/7] KVM: PPC: Remove redundant kvm_run from vcpu_arch

2020-05-26 Thread Paul Mackerras
On Mon, Apr 27, 2020 at 12:35:10PM +0800, Tianjia Zhang wrote:
> The 'kvm_run' field already exists in the 'vcpu' structure, which
> is the same structure as the 'kvm_run' in the 'vcpu_arch' and
> should be deleted.
> 
> Signed-off-by: Tianjia Zhang 

Thanks, patches 3 and 4 of this series applied to my kvm-ppc-next branch.

Paul.


Re: [PATCH v30 08/20] x86/sgx: Add functions to allocate and free EPC pages

2020-05-26 Thread Sean Christopherson
On Tue, May 26, 2020 at 02:52:08PM +0200, Borislav Petkov wrote:
> On Fri, May 15, 2020 at 03:43:58AM +0300, Jarkko Sakkinen wrote:
> > diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
> > index 38424c1e8341..60d82e7537c8 100644
> > --- a/arch/x86/kernel/cpu/sgx/main.c
> > +++ b/arch/x86/kernel/cpu/sgx/main.c
> > @@ -13,6 +13,66 @@
> >  struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
> >  int sgx_nr_epc_sections;
> >  
> > +static struct sgx_epc_page *__sgx_try_alloc_page(struct sgx_epc_section 
> > *section)
> > +{
> > +   struct sgx_epc_page *page;
> > +
> > +   if (list_empty(>page_list))
> > +   return NULL;
> > +
> > +   page = list_first_entry(>page_list, struct sgx_epc_page, list);
> > +   list_del_init(>list);
> > +   return page;
> > +}
> > +
> > +/**
> > + * sgx_try_alloc_page() - Allocate an EPC page
> 
> Uuh, this is confusing. Looking forward into the patchset, you guys have
> 
> sgx_alloc_page()
> sgx_alloc_va_page()
>
> and this here
> 
> sgx_try_alloc_page()
> 
> So this one here should be called sgx_alloc_epc_page() if we're going to
> differentiate *what* it is allocating.

No objection to the rename.

> But then looking at sgx_alloc_page():
> 
> + * sgx_alloc_page() - Allocate an EPC page
> ...
> 
> + struct sgx_epc_page *sgx_alloc_page(void *owner, bool reclaim)
> 
> this one returns a struct sgx_epc_page * too.
> 
> The former "allocates" from the EPC cache so I'm thinking former should
> not have "alloc" in its name at all. It should be called something like
> 
> sgx_get_epc_page()
> 
> or so.

> Now, looking at sgx_alloc_page(), it does call this one -
> sgx_try_alloc_page() to get a page from the page list but it
> does not allocate anything. The actual allocation happens in
> sgx_alloc_epc_section() which actually does the k*alloc().

Ah.  The Enclave Page Cache isn't actually a cache, and it's not a kernel
construct.  The EPC is really just Enclave Memory, but Intel really likes
three letter acronyms.  On current CPUs, the EPC is carved out of main
memory via range registers, i.e. it's a statically located and sized chunk
of DRAM with special access rules that are enforced by the CPU.  It's no
more of a cache than regular DRAM. 

In other words, sgx_alloc_epc_section() is poorly named.  It doesn't
actually allocate EPC, it allocates kernel structures to map and track EPC.
sgx_(un)map_epc_section() would be more accurate and would hopefully
alleviate some of the confusion.

> Which sounds to me like those functions should not use "alloc" and
> "free" in their names but "get" and "put" to denote that they're simply
> getting pages from lists and returning them back to those lists.
> 
> IMNSVHO.

A better analogy is k*alloc() == sgx_alloc_epc_page() and
__sgx_alloc_try_alloc_page() == alloc_pages_node().  EPC sections aren't
guaranteed to have a 1:1 relationship with NUMA nodes, but that holds true
for current platforms.

I have no objection to renaming __sgx_alloc_try_alloc_page() to something
like sgx_alloc_epc_page_section or whatever, but IMO using get/put will be
horrendously confusing.


Re: [PATCH -next] KVM: PPC: Book3S HV: remove redundant NULL check

2020-05-26 Thread Paul Mackerras
On Wed, Apr 01, 2020 at 09:09:03PM +0800, Chen Zhou wrote:
> Free function kfree() already does NULL check, so the additional
> check is unnecessary, just remove it.
> 
> Signed-off-by: Chen Zhou 

Thanks, applied to my kvm-ppc-next branch.

Paul.


Re: [PATCH] KVM: PPC: Book3S HV: read ibm,secure-memory nodes

2020-05-26 Thread Paul Mackerras
On Thu, Apr 16, 2020 at 06:27:15PM +0200, Laurent Dufour wrote:
> The newly introduced ibm,secure-memory nodes supersede the
> ibm,uv-firmware's property secure-memory-ranges.
> 
> Firmware will no more expose the secure-memory-ranges property so first
> read the new one and if not found rollback to the older one.
> 
> Signed-off-by: Laurent Dufour 

Thanks, applied to my kvm-ppc-next branch.

Paul.


Re: [PATCH] powerpc/kvm/radix: ignore kmemleak false positives

2020-05-26 Thread Paul Mackerras
On Wed, May 13, 2020 at 09:39:15AM -0400, Qian Cai wrote:
> kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then
> pud_populate() and pmd_populate() will use __pa() to reference the newly
> allocated memory.
> 
> Since kmemleak is unable to track the physical memory resulting in false
> positives, silence those by using kmemleak_ignore().
> 
> unreferenced object 0xc000201c382a1000 (size 4096):
>  comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s)
>  hex dump (first 32 bytes):
>c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87  .. ..` .r...
>c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87  .. ... .
>  backtrace:
>[<4cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv]
>kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366
>(inlined by) kvmppc_create_pte at 
> arch/powerpc/kvm/book3s_64_mmu_radix.c:590
>[] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
>[] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
>[<86dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
>[<5ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
>[] kvmppc_vcpu_run+0x34/0x48 [kvm]
>[] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
>[<2543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
>[<48155cd6>] ksys_ioctl+0xd8/0x130
>[<41ffeaa7>] sys_ioctl+0x28/0x40
>[<4afc4310>] system_call_exception+0x114/0x1e0
>[] system_call_common+0xf0/0x278
> unreferenced object 0xc0002001f0c03900 (size 256):
>  comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s)
>  hex dump (first 32 bytes):
>c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87  .. ... .
>c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87  .. ... .
>  backtrace:
>[<23f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv]
>kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356
>(inlined by) kvmppc_create_pte at 
> arch/powerpc/kvm/book3s_64_mmu_radix.c:593
>[] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv]
>[] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv]
>[<86dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv]
>[<5ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv]
>[] kvmppc_vcpu_run+0x34/0x48 [kvm]
>[] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm]
>[<2543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm]
>[<48155cd6>] ksys_ioctl+0xd8/0x130
>[<41ffeaa7>] sys_ioctl+0x28/0x40
>[<4afc4310>] system_call_exception+0x114/0x1e0
>[] system_call_common+0xf0/0x278
> 
> Signed-off-by: Qian Cai 

Thanks, applied to my kvm-ppc-next branch.

Paul.


Re: [PATCH v2] KVM: PPC: Book3S HV: relax check on H_SVM_INIT_ABORT

2020-05-26 Thread Paul Mackerras
On Wed, May 20, 2020 at 07:43:08PM +0200, Laurent Dufour wrote:
> The commit 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_*
> Hcalls") added checks of secure bit of SRR1 to filter out the Hcall
> reserved to the Ultravisor.
> 
> However, the Hcall H_SVM_INIT_ABORT is made by the Ultravisor passing the
> context of the VM calling UV_ESM. This allows the Hypervisor to return to
> the guest without going through the Ultravisor. Thus the Secure bit of SRR1
> is not set in that particular case.
> 
> In the case a regular VM is calling H_SVM_INIT_ABORT, this hcall will be
> filtered out in kvmppc_h_svm_init_abort() because kvm->arch.secure_guest is
> not set in that case.
> 
> Fixes: 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_* Hcalls")
> Signed-off-by: Laurent Dufour 

Thanks, applied to my kvm-ppc-next branch.  I expanded the comment in
the code a little.

Paul.


Re: [PATCH] powerpc/kvm/book3s64/vio: fix some RCU-list locks

2020-05-26 Thread Paul Mackerras
On Sun, May 10, 2020 at 01:18:34AM -0400, Qian Cai wrote:
> It is unsafe to traverse kvm->arch.spapr_tce_tables and
> stt->iommu_tables without the RCU read lock held. Also, add
> cond_resched_rcu() in places with the RCU read lock held that could take
> a while to finish.
> 
>  arch/powerpc/kvm/book3s_64_vio.c:76 RCU-list traversed in non-reader 
> section!!
> 
>  other info that might help us debug this:
> 
>  rcu_scheduler_active = 2, debug_locks = 1
>  no locks held by qemu-kvm/4265.
> 
>  stack backtrace:
>  CPU: 96 PID: 4265 Comm: qemu-kvm Not tainted 5.7.0-rc4-next-20200508+ #2
>  Call Trace:
>  [c000201a8690f720] [c0715948] dump_stack+0xfc/0x174 (unreliable)
>  [c000201a8690f770] [c01d9470] lockdep_rcu_suspicious+0x140/0x164
>  [c000201a8690f7f0] [c00810b9fb48] 
> kvm_spapr_tce_release_iommu_group+0x1f0/0x220 [kvm]
>  [c000201a8690f870] [c00810b8462c] 
> kvm_spapr_tce_release_vfio_group+0x54/0xb0 [kvm]
>  [c000201a8690f8a0] [c00810b84710] kvm_vfio_destroy+0x88/0x140 [kvm]
>  [c000201a8690f8f0] [c00810b7d488] kvm_put_kvm+0x370/0x600 [kvm]
>  [c000201a8690f990] [c00810b7e3c0] kvm_vm_release+0x38/0x60 [kvm]
>  [c000201a8690f9c0] [c05223f4] __fput+0x124/0x330
>  [c000201a8690fa20] [c0151cd8] task_work_run+0xb8/0x130
>  [c000201a8690fa70] [c01197e8] do_exit+0x4e8/0xfa0
>  [c000201a8690fb70] [c011a374] do_group_exit+0x64/0xd0
>  [c000201a8690fbb0] [c0132c90] get_signal+0x1f0/0x1200
>  [c000201a8690fcc0] [c0020690] do_notify_resume+0x130/0x3c0
>  [c000201a8690fda0] [c0038d64] syscall_exit_prepare+0x1a4/0x280
>  [c000201a8690fe20] [c000c8f8] system_call_common+0xf8/0x278
> 
>  
>  arch/powerpc/kvm/book3s_64_vio.c:368 RCU-list traversed in non-reader 
> section!!
> 
>  other info that might help us debug this:
> 
>  rcu_scheduler_active = 2, debug_locks = 1
>  2 locks held by qemu-kvm/4264:
>   #0: c000201ae2d000d8 (>mutex){+.+.}-{3:3}, at: 
> kvm_vcpu_ioctl+0xdc/0x950 [kvm]
>   #1: c000200c9ed0c468 (>srcu){}-{0:0}, at: 
> kvmppc_h_put_tce+0x88/0x340 [kvm]
> 
>  
>  arch/powerpc/kvm/book3s_64_vio.c:108 RCU-list traversed in non-reader 
> section!!
> 
>  other info that might help us debug this:
> 
>  rcu_scheduler_active = 2, debug_locks = 1
>  1 lock held by qemu-kvm/4257:
>   #0: c000200b1b363a40 (>lock){+.+.}-{3:3}, at: 
> kvm_vfio_set_attr+0x598/0x6c0 [kvm]
> 
>  
>  arch/powerpc/kvm/book3s_64_vio.c:146 RCU-list traversed in non-reader 
> section!!
> 
>  other info that might help us debug this:
> 
>  rcu_scheduler_active = 2, debug_locks = 1
>  1 lock held by qemu-kvm/4257:
>   #0: c000200b1b363a40 (>lock){+.+.}-{3:3}, at: 
> kvm_vfio_set_attr+0x598/0x6c0 [kvm]
> 
> Signed-off-by: Qian Cai 

Thanks, applied to my kvm-ppc-next branch, with the cond_resched_rcu()
in kvmppc_tce_validate removed.

Paul.


Re: inux-next: build failure after merge of the drm-msm tree

2020-05-26 Thread Nathan Chancellor
On Tue, May 26, 2020 at 02:08:41PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Tue, 19 May 2020 15:09:55 +1000 Stephen Rothwell  
> wrote:
> >
> > Hi all,
> > 
> > After merging the drm-msm tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> > 
> > ERROR: modpost: "__aeabi_ldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
> > ERROR: modpost: "__aeabi_uldivmod" [drivers/gpu/drm/msm/msm.ko] undefined!
> > 
> > Caused by commit
> > 
> >   04d9044f6c57 ("drm/msm/dpu: add support for clk and bw scaling for 
> > display")
> > 
> > I applied the following patch for today (this is mechanical, there may
> > be a better way):
> > 
> > From: Stephen Rothwell 
> > Date: Tue, 19 May 2020 14:12:39 +1000
> > Subject: [PATCH] drm/msm/dpu: fix up u64/u32 division for 32 bit 
> > architectures
> > 
> > Signed-off-by: Stephen Rothwell 
> > ---
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 23 ++-
> >  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 15 
> >  2 files changed, 28 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > index 9697abcbec3f..85c2a4190840 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "dpu_kms.h"
> >  #include "dpu_trace.h"
> > @@ -53,8 +54,11 @@ static u64 _dpu_core_perf_calc_bw(struct dpu_kms *kms,
> > }
> >  
> > bw_factor = kms->catalog->perf.bw_inefficiency_factor;
> > -   if (bw_factor)
> > -   crtc_plane_bw = mult_frac(crtc_plane_bw, bw_factor, 100);
> > +   if (bw_factor) {
> > +   u64 quot = crtc_plane_bw;
> > +   u32 rem = do_div(quot, 100);
> > +   crtc_plane_bw = (quot * bw_factor) + ((rem * bw_factor) / 100);
> > +   }
> >  
> > return crtc_plane_bw;
> >  }
> > @@ -89,8 +93,11 @@ static u64 _dpu_core_perf_calc_clk(struct dpu_kms *kms,
> > }
> >  
> > clk_factor = kms->catalog->perf.clk_inefficiency_factor;
> > -   if (clk_factor)
> > -   crtc_clk = mult_frac(crtc_clk, clk_factor, 100);
> > +   if (clk_factor) {
> > +   u64 quot = crtc_clk;
> > +   u32 rem = do_div(quot, 100);
> > +   crtc_clk = (quot * clk_factor) + ((rem * clk_factor) / 100);
> > +   }
> >  
> > return crtc_clk;
> >  }
> > @@ -234,8 +241,12 @@ static int _dpu_core_perf_crtc_update_bus(struct 
> > dpu_kms *kms,
> > }
> > }
> >  
> > -   avg_bw = kms->num_paths ?
> > -   perf.bw_ctl / kms->num_paths : 0;
> > +   if (kms->num_paths) {
> > +   avg_bw = perf.bw_ctl;
> > +   do_div(avg_bw, kms->num_paths);
> > +   } else {
> > +   avg_bw = 0;
> > +   }
> >  
> > for (i = 0; i < kms->num_paths; i++)
> > icc_set_bw(kms->path[i],
> > diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
> > b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > index c2a6e3dacd68..ad95f32eac13 100644
> > --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> > @@ -9,6 +9,7 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -174,7 +175,11 @@ static void _dpu_plane_calc_bw(struct drm_plane *plane,
> > plane_prefill_bw =
> > src_width * hw_latency_lines * fps * fmt->bpp * scale_factor;
> >  
> > -   plane_prefill_bw = mult_frac(plane_prefill_bw, mode->vtotal, (vbp+vpw));
> > +   {
> > +   u64 quot = plane_prefill_bw;
> > +   u32 rem = do_div(plane_prefill_bw, vbp + vpw);
> > +   plane_prefill_bw = quot * mode->vtotal + rem * mode->vtotal / 
> > (vbp + vpw);
> > +   }
> >  
> > pstate->plane_fetch_bw = max(plane_bw, plane_prefill_bw);
> >  }
> > @@ -204,9 +209,11 @@ static void _dpu_plane_calc_clk(struct drm_plane 
> > *plane)
> > pstate->plane_clk =
> > dst_width * mode->vtotal * fps;
> >  
> > -   if (src_height > dst_height)
> > -   pstate->plane_clk = mult_frac(pstate->plane_clk,
> > -   src_height, dst_height);
> > +   if (src_height > dst_height) {
> > +   u64 quot = pstate->plane_clk;
> > +   u32 rem = do_div(quot, dst_height);
> > +   pstate->plane_clk = quot * src_height + rem * src_height / 
> > dst_height;
> > +   }
> >  }
> >  
> >  /**
> > -- 
> > 2.26.2
> 
> I am still applying the above ...
> 
> -- 
> Cheers,
> Stephen Rothwell

Additionally, I see a failure with clang due to the use of Bps_to_icc,
which does a straight division by 1000, which is treated as an integer
literal, with avg_bw as the dividend, which is a u64.

Below is the "hack" in my tree.

Cheers,
Nathan

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c
index 85c2a4190840..5ea725d8da6c 100644
--- 

Re: [PATCH 2/2] clk: Remove CONFIG_ARCH_HISI check for subdir hisilicon

2020-05-26 Thread Tiezhu Yang

On 05/27/2020 02:55 AM, kbuild test robot wrote:

Hi Tiezhu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on clk/clk-next]
[also build test ERROR on v5.7-rc7 next-20200526]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Tiezhu-Yang/clk-hisilicon-Use-correct-return-value-about-hisi_reset_init/20200525-113342
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: i386-tinyconfig (attached as .config)


Hi,

Thanks for your report.

I find that both CONFIG_ARCH_HISI and CONFIG_COMPILE_TEST are not
set in .config, if one of them is set, the build will be success.

But when used with this patch and this .config, I think it is
better to check CONFIG_COMMON_CLK and CONFIG_CLKDEV_LOOKUP or
just check CONFIG_ARCH_HISI before build the following files
"clk.o clkgate-separated.o clkdivider-hi6220.o clk-hisi-phase.o"
in drivers/clk/hisilicon/Makefile to avoid the build failure.

I will verify it and then send v2.

Thanks,
Tiezhu Yang


compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build):
 # save the attached .config to linux build tree
 make W=1 ARCH=i386

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

ld: drivers/clk/hisilicon/clk.o: in function `hisi_clk_register_fixed_rate':

clk.c:(.text+0x9e): undefined reference to `clk_register_fixed_rate'
ld: clk.c:(.text+0xdf): undefined reference to `clk_unregister_fixed_rate'

ld: drivers/clk/hisilicon/clk.o: in function `hisi_clk_register_fixed_factor':

clk.c:(.text+0x117): undefined reference to `clk_register_fixed_factor'
ld: clk.c:(.text+0x158): undefined reference to `clk_unregister_fixed_factor'

ld: drivers/clk/hisilicon/clk.o: in function `hisi_clk_register_mux':

clk.c:(.text+0x1cb): undefined reference to `clk_register_mux_table'
ld: clk.c:(.text+0x1f2): undefined reference to `clk_register_clkdev'
ld: clk.c:(.text+0x21a): undefined reference to `clk_unregister_mux'

ld: drivers/clk/hisilicon/clk.o: in function `hisi_clk_register_divider':

clk.c:(.text+0x2c9): undefined reference to `clk_register_divider_table'

ld: clk.c:(.text+0x2e3): undefined reference to `clk_register_clkdev'

ld: clk.c:(.text+0x311): undefined reference to `clk_unregister_divider'

ld: drivers/clk/hisilicon/clk.o: in function `hisi_clk_register_gate':

clk.c:(.text+0x36c): undefined reference to `clk_register_gate'

ld: clk.c:(.text+0x393): undefined reference to `clk_register_clkdev'

ld: clk.c:(.text+0x3bb): undefined reference to `clk_unregister_gate'

ld: drivers/clk/hisilicon/clk.o: in function `hisi_clk_register_gate_sep':

clk.c:(.text+0x425): undefined reference to `clk_register_clkdev'

ld: drivers/clk/hisilicon/clk.o: in function `hi6220_clk_register_divider':

clk.c:(.init.text+0x5d): undefined reference to `clk_register_clkdev'

ld: drivers/clk/hisilicon/clkgate-separated.o: in function 
`hisi_register_clkgate_sep':

clkgate-separated.c:(.text+0xf0): undefined reference to `clk_register'

ld: drivers/clk/hisilicon/clkdivider-hi6220.o: in function 
`hi6220_clkdiv_set_rate':

clkdivider-hi6220.c:(.text+0x16): undefined reference to `divider_get_val'

ld: drivers/clk/hisilicon/clkdivider-hi6220.o: in function 
`hi6220_clkdiv_recalc_rate':

clkdivider-hi6220.c:(.text+0x8a): undefined reference to `divider_recalc_rate'

ld: drivers/clk/hisilicon/clkdivider-hi6220.o: in function 
`hi6220_clkdiv_round_rate':

clkdivider-hi6220.c:(.text+0xa9): undefined reference to `clk_hw_get_parent'
ld: clkdivider-hi6220.c:(.text+0xbd): undefined reference to 
`divider_round_rate_parent'

ld: drivers/clk/hisilicon/clkdivider-hi6220.o: in function 
`hi6220_register_clkdiv':

clkdivider-hi6220.c:(.text+0x1c5): undefined reference to `clk_register'

ld: drivers/clk/hisilicon/clk-hisi-phase.o: in function 
`clk_register_hisi_phase':

clk-hisi-phase.c:(.text+0x121): undefined reference to `devm_clk_register'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org




Re: [PATCH 2/2] clk: Remove CONFIG_ARCH_HISI check for subdir hisilicon

2020-05-26 Thread kbuild test robot
Hi Tiezhu,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on clk/clk-next]
[also build test ERROR on v5.7-rc7 next-20200526]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Tiezhu-Yang/clk-hisilicon-Use-correct-return-value-about-hisi_reset_init/20200525-113342
base:   https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
config: m68k-allnoconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=m68k 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

m68k-linux-ld: drivers/clk/hisilicon/clk.o: in function 
`hisi_clk_register_fixed_rate':
clk.c:(.text+0xd0): undefined reference to `clk_register_fixed_rate'
>> m68k-linux-ld: clk.c:(.text+0x120): undefined reference to 
>> `clk_unregister_fixed_rate'
m68k-linux-ld: drivers/clk/hisilicon/clk.o: in function 
`hisi_clk_register_fixed_factor':
clk.c:(.text+0x166): undefined reference to `clk_register_fixed_factor'
>> m68k-linux-ld: clk.c:(.text+0x1ba): undefined reference to 
>> `clk_unregister_fixed_factor'
m68k-linux-ld: drivers/clk/hisilicon/clk.o: in function `hisi_clk_register_mux':
clk.c:(.text+0x208): undefined reference to `clk_register_mux_table'
>> m68k-linux-ld: clk.c:(.text+0x210): undefined reference to 
>> `clk_register_clkdev'
>> m68k-linux-ld: clk.c:(.text+0x2a8): undefined reference to 
>> `clk_unregister_mux'
m68k-linux-ld: drivers/clk/hisilicon/clk.o: in function 
`hisi_clk_register_divider':
clk.c:(.text+0x360): undefined reference to `clk_register_divider_table'
m68k-linux-ld: clk.c:(.text+0x366): undefined reference to `clk_register_clkdev'
>> m68k-linux-ld: clk.c:(.text+0x3f0): undefined reference to 
>> `clk_unregister_divider'
m68k-linux-ld: drivers/clk/hisilicon/clk.o: in function 
`hisi_clk_register_gate':
clk.c:(.text+0x43c): undefined reference to `clk_register_gate'
m68k-linux-ld: clk.c:(.text+0x442): undefined reference to `clk_register_clkdev'
>> m68k-linux-ld: clk.c:(.text+0x4c0): undefined reference to 
>> `clk_unregister_gate'
m68k-linux-ld: drivers/clk/hisilicon/clk.o: in function 
`hisi_clk_register_gate_sep':
clk.c:(.text+0x510): undefined reference to `clk_register_clkdev'
m68k-linux-ld: drivers/clk/hisilicon/clk.o: in function 
`hi6220_clk_register_divider':
clk.c:(.init.text+0x16): undefined reference to `clk_register_clkdev'
m68k-linux-ld: drivers/clk/hisilicon/clkgate-separated.o: in function 
`hisi_register_clkgate_sep':
clkgate-separated.c:(.text+0x128): undefined reference to `clk_register'
>> m68k-linux-ld: clkgate-separated.c:(.text+0x176): undefined reference to 
>> `clk_register'
m68k-linux-ld: drivers/clk/hisilicon/clkdivider-hi6220.o: in function 
`hi6220_clkdiv_set_rate':
clkdivider-hi6220.c:(.text+0x26): undefined reference to `divider_get_val'
m68k-linux-ld: drivers/clk/hisilicon/clkdivider-hi6220.o: in function 
`hi6220_clkdiv_round_rate':
clkdivider-hi6220.c:(.text+0xa6): undefined reference to `clk_hw_get_parent'
>> m68k-linux-ld: clkdivider-hi6220.c:(.text+0xc0): undefined reference to 
>> `divider_round_rate_parent'
m68k-linux-ld: drivers/clk/hisilicon/clkdivider-hi6220.o: in function 
`hi6220_clkdiv_recalc_rate':
clkdivider-hi6220.c:(.text+0x10a): undefined reference to `divider_recalc_rate'
m68k-linux-ld: drivers/clk/hisilicon/clkdivider-hi6220.o: in function 
`hi6220_register_clkdiv':
clkdivider-hi6220.c:(.text+0x1f8): undefined reference to `clk_register'
m68k-linux-ld: drivers/clk/hisilicon/clk-hisi-phase.o: in function 
`clk_register_hisi_phase':
clk-hisi-phase.c:(.text+0x172): undefined reference to `devm_clk_register'
>> m68k-linux-ld: clk-hisi-phase.c:(.text+0x1e2): undefined reference to 
>> `devm_clk_register'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip


[PATCH v8 2/5] seq_buf: Export seq_buf_printf

2020-05-26 Thread Vaibhav Jain
'seq_buf' provides a very useful abstraction for writing to a string
buffer without needing to worry about it over-flowing. However even
though the API has been stable for couple of years now its still not
exported to kernel loadable modules limiting its usage.

Hence this patch proposes update to 'seq_buf.c' to mark
seq_buf_printf() which is part of the seq_buf API to be exported to
kernel loadable GPL modules. This symbol will be used in later parts
of this patch-set to simplify content creation for a sysfs attribute.

Cc: Piotr Maziarz 
Cc: Cezary Rojewski 
Cc: Christoph Hellwig 
Cc: Steven Rostedt 
Cc: Borislav Petkov 
Signed-off-by: Vaibhav Jain 
---
Changelog:

v7..v8:
* Updated the patch title [ Christoph Hellwig ]
* Updated patch description to replace confusing term 'external kernel
  modules' to 'kernel lodable modules'.

Resend:
* Added ack from Steven Rostedt

v6..v7:
* New patch in the series
---
 lib/seq_buf.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lib/seq_buf.c b/lib/seq_buf.c
index 4e865d42ab03..707453f5d58e 100644
--- a/lib/seq_buf.c
+++ b/lib/seq_buf.c
@@ -91,6 +91,7 @@ int seq_buf_printf(struct seq_buf *s, const char *fmt, ...)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(seq_buf_printf);
 
 #ifdef CONFIG_BINARY_PRINTF
 /**
-- 
2.26.2



[PATCH v8 4/5] ndctl/papr_scm,uapi: Add support for PAPR nvdimm specific methods

2020-05-26 Thread Vaibhav Jain
Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
module and add the command family to the white list of NVDIMM command
sets. Also advertise support for ND_CMD_CALL for the nvdimm
command mask and implement necessary scaffolding in the module to
handle ND_CMD_CALL ioctl and PDSM requests that we receive.

The layout of the PDSM request as we expect from libnvdimm/libndctl is
described in newly introduced uapi header 'papr_scm_pdsm.h' which
defines a new 'struct nd_pdsm_cmd_pkg' header. This header is used
to communicate the PDSM request via member
'nd_pkg_papr_scm->nd_command' and size of payload that need to be
sent/received for servicing the PDSM.

A new function is_cmd_valid() is implemented that reads the args to
papr_scm_ndctl() and performs sanity tests on them. A new function
papr_scm_service_pdsm() is introduced and is called from
papr_scm_ndctl() in case of a PDSM request is received via ND_CMD_CALL
command from libnvdimm.

Cc: "Aneesh Kumar K . V" 
Cc: Dan Williams 
Cc: Michael Ellerman 
Cc: Ira Weiny 
Signed-off-by: Vaibhav Jain 
---
Changelog:

v7..v8:
* Removed the 'payload_offset' field from 'struct
  nd_pdsm_cmd_pkg'. Instead command payload is always assumed to start
  at 'nd_pdsm_cmd_pkg.payload'. [ Aneesh ]
* To enable introducing new fields to 'struct nd_pdsm_cmd_pkg',
  'reserved' field of 10-bytes is introduced. [ Aneesh ]
* Fixed a typo in "Backward Compatibility" section of papr_scm_pdsm.h
  [ Ira ]

Resend:
* None

v6..v7 :
* Removed the re-definitions of __packed macro from papr_scm_pdsm.h
  [Mpe].
* Removed the usage of __KERNEL__ macros in papr_scm_pdsm.h [Mpe].
* Removed macros that were unused in papr_scm.c from papr_scm_pdsm.h
  [Mpe].
* Made functions defined in papr_scm_pdsm.h as static inline. [Mpe]

v5..v6 :
* Changed the usage of the term DSM to PDSM to distinguish it from the
  ACPI term [ Dan Williams ]
* Renamed papr_scm_dsm.h to papr_scm_pdsm.h and updated various struct
  to reflect the new terminology.
* Updated the patch description and title to reflect the new terminology.
* Squashed patch to introduce new command family in 'ndctl.h' with
  this patch [ Dan Williams ]
* Updated the papr_scm_pdsm method starting index from 0x1 to 0x0
  [ Dan Williams ]
* Removed redundant license text from the papr_scm_psdm.h file.
  [ Dan Williams ]
* s/envelop/envelope/ at various places [ Dan Williams ]
* Added '__packed' attribute to command package header to gaurd
  against different compiler adding paddings between the fields.
  [ Dan Williams]
* Converted various pr_debug to dev_debug [ Dan Williams ]

v4..v5 :
* None

v3..v4 :
* None

v2..v3 :
* Updated the patch prefix to 'ndctl/uapi' [Aneesh]

v1..v2 :
* None
---
 arch/powerpc/include/uapi/asm/papr_scm_pdsm.h | 136 ++
 arch/powerpc/platforms/pseries/papr_scm.c | 101 -
 include/uapi/linux/ndctl.h|   1 +
 3 files changed, 232 insertions(+), 6 deletions(-)
 create mode 100644 arch/powerpc/include/uapi/asm/papr_scm_pdsm.h

diff --git a/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h 
b/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
new file mode 100644
index ..c4bae3208e73
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
@@ -0,0 +1,136 @@
+/* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */
+/*
+ * PAPR-SCM Dimm specific methods (PDSM) and structs for libndctl
+ *
+ * (C) Copyright IBM 2020
+ *
+ * Author: Vaibhav Jain 
+ */
+
+#ifndef _UAPI_ASM_POWERPC_PAPR_SCM_PDSM_H_
+#define _UAPI_ASM_POWERPC_PAPR_SCM_PDSM_H_
+
+#include 
+
+/*
+ * PDSM Envelope:
+ *
+ * The ioctl ND_CMD_CALL transfers data between user-space and kernel via
+ * envelope which consists of a header and user-defined payload sections.
+ * The header is described by 'struct nd_pdsm_cmd_pkg' which expects a
+ * payload following it and accessible via 'nd_pdsm_cmd_pkg.payload' field.
+ * There is reserved field that can used to introduce new fields to the
+ * structure in future. It also tries to ensure that 'nd_pdsm_cmd_pkg.payload'
+ * lies at a 8-byte boundary.
+ *
+ *  +-+-+---+
+ *  |   64-Bytes  |   16-Bytes  |   Max 176-Bytes   |
+ *  +-+-+---+
+ *  |   nd_pdsm_cmd_pkg |   |
+ *  |-+ |   |
+ *  |  nd_cmd_pkg | |   |
+ *  +-+-+---+
+ *  | nd_family   | |   |
+ *  | nd_size_out | cmd_status  |   |
+ *  | nd_size_in  | payload_version | payload   |
+ *  | nd_command  | reserved|   |
+ *  | nd_fw_size  | |   |
+ *  

[PATCH v8 5/5] powerpc/papr_scm: Implement support for PAPR_SCM_PDSM_HEALTH

2020-05-26 Thread Vaibhav Jain
This patch implements support for PDSM request 'PAPR_SCM_PDSM_HEALTH'
that returns a newly introduced 'struct nd_papr_pdsm_health' instance
containing dimm health information back to user space in response to
ND_CMD_CALL. This functionality is implemented in newly introduced
papr_scm_get_health() that queries the scm-dimm health information and
then copies this information to the package payload whose layout is
defined by 'struct nd_papr_pdsm_health'.

The patch also introduces a new member 'struct papr_scm_priv.health'
thats an instance of 'struct nd_papr_pdsm_health' to cache the health
information of a nvdimm. As a result functions drc_pmem_query_health()
and flags_show() are updated to populate and use this new struct
instead of a u64 integer that was earlier used.

Cc: "Aneesh Kumar K . V" 
Cc: Dan Williams 
Cc: Michael Ellerman 
Cc: Ira Weiny 
Signed-off-by: Vaibhav Jain 
---
Changelog:

v7..v8:
* None

Resend:
* None

v6..v7:
* Updated flags_show() to use seq_buf_printf(). [Mpe]
* Updated papr_scm_get_health() to use newly introduced
  __drc_pmem_query_health() bypassing the cache [Mpe].

v5..v6:
* Added attribute '__packed' to 'struct nd_papr_pdsm_health_v1' to
  gaurd against possibility of different compilers adding different
  paddings to the struct [ Dan Williams ]

* Updated 'struct nd_papr_pdsm_health_v1' to use __u8 instead of
  'bool' and also updated drc_pmem_query_health() to take this into
  account. [ Dan Williams ]

v4..v5:
* None

v3..v4:
* Call the DSM_PAPR_SCM_HEALTH service function from
  papr_scm_service_dsm() instead of papr_scm_ndctl(). [Aneesh]

v2..v3:
* Updated struct nd_papr_scm_dimm_health_stat_v1 to use '__xx' types
  as its exported to the userspace [Aneesh]
* Changed the constants DSM_PAPR_SCM_DIMM_XX indicating dimm health
  from enum to #defines [Aneesh]

v1..v2:
* New patch in the series
---
 arch/powerpc/include/uapi/asm/papr_scm_pdsm.h |  39 ++
 arch/powerpc/platforms/pseries/papr_scm.c | 125 +++---
 2 files changed, 147 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h 
b/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
index c4bae3208e73..f81d714279f0 100644
--- a/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
+++ b/arch/powerpc/include/uapi/asm/papr_scm_pdsm.h
@@ -115,6 +115,7 @@ struct nd_pdsm_cmd_pkg {
  */
 enum papr_scm_pdsm {
PAPR_SCM_PDSM_MIN = 0x0,
+   PAPR_SCM_PDSM_HEALTH,
PAPR_SCM_PDSM_MAX,
 };
 
@@ -133,4 +134,42 @@ static inline void *pdsm_cmd_to_payload(struct 
nd_pdsm_cmd_pkg *pcmd)
return (void *)(pcmd->payload);
 }
 
+/* Various scm-dimm health indicators */
+#define PAPR_PDSM_DIMM_HEALTHY   0
+#define PAPR_PDSM_DIMM_UNHEALTHY 1
+#define PAPR_PDSM_DIMM_CRITICAL  2
+#define PAPR_PDSM_DIMM_FATAL 3
+
+/*
+ * Struct exchanged between kernel & ndctl in for PAPR_SCM_PDSM_HEALTH
+ * Various flags indicate the health status of the dimm.
+ *
+ * dimm_unarmed: Dimm not armed. So contents wont persist.
+ * dimm_bad_shutdown   : Previous shutdown did not persist contents.
+ * dimm_bad_restore: Contents from previous shutdown werent restored.
+ * dimm_scrubbed   : Contents of the dimm have been scrubbed.
+ * dimm_locked : Contents of the dimm cant be modified until CEC reboot
+ * dimm_encrypted  : Contents of dimm are encrypted.
+ * dimm_health : Dimm health indicator. One of PAPR_PDSM_DIMM_
+ */
+struct nd_papr_pdsm_health_v1 {
+   __u8 dimm_unarmed;
+   __u8 dimm_bad_shutdown;
+   __u8 dimm_bad_restore;
+   __u8 dimm_scrubbed;
+   __u8 dimm_locked;
+   __u8 dimm_encrypted;
+   __u16 dimm_health;
+} __packed;
+
+/*
+ * Typedef the current struct for dimm_health so that any application
+ * or kernel recompiled after introducing a new version automatically
+ * supports the new version.
+ */
+#define nd_papr_pdsm_health nd_papr_pdsm_health_v1
+
+/* Current version number for the dimm health struct */
+#define ND_PAPR_PDSM_HEALTH_VERSION 1
+
 #endif /* _UAPI_ASM_POWERPC_PAPR_SCM_PDSM_H_ */
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
b/arch/powerpc/platforms/pseries/papr_scm.c
index fcb8afee97dc..adf1fb819c56 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -88,7 +88,7 @@ struct papr_scm_priv {
unsigned long lasthealth_jiffies;
 
/* Health information for the dimm */
-   u64 health_bitmap;
+   struct nd_papr_pdsm_health health;
 };
 
 static int drc_pmem_bind(struct papr_scm_priv *p)
@@ -201,6 +201,7 @@ static int drc_pmem_query_n_bind(struct papr_scm_priv *p)
 static int __drc_pmem_query_health(struct papr_scm_priv *p)
 {
unsigned long ret[PLPAR_HCALL_BUFSIZE];
+   u64 health;
long rc;
 
/* issue the hcall */
@@ -208,18 +209,46 @@ static int __drc_pmem_query_health(struct papr_scm_priv 
*p)
if (rc != H_SUCCESS) {
dev_err(>pdev->dev,
  

[PATCH v8 0/5] powerpc/papr_scm: Add support for reporting nvdimm health

2020-05-26 Thread Vaibhav Jain
Changes since v7 [1]:

* Addressed various review comments from Aneesh, Ira and Mpe.
* Removed the 'payload_offset' field from 'struct nd_pdsm_cmd_pkg' and
  replaced it with some reserved fields [ Aneesh ].
* Updated the doc and description for patch that fetches dimm health
  information from PHYP clarifying bit-ordering [ Mpe and Ira ].
* Updated the patch title & description for patch exporting
  'seq_buf_printf'. [ Christoph Hellwig ]
* Fix types of various newly introduced vars in papr_scm.c [ Ira ].
* Fixed a typo in 'papr_scm_pdsm.h' [ Ira ]

[1] 
https://lore.kernel.org/linux-nvdimm/20200519190058.257981-1-vaib...@linux.ibm.com

---

The PAPR standard[2][4] provides mechanisms to query the health and
performance stats of an NVDIMM via various hcalls as described in
Ref[3].  Until now these stats were never available nor exposed to the
user-space tools like 'ndctl'. This is partly due to PAPR platform not
having support for ACPI and NFIT. Hence 'ndctl' is unable to query and
report the dimm health status and a user had no way to determine the
current health status of a NDVIMM.

To overcome this limitation, this patch-set updates papr_scm kernel
module to query and fetch NVDIMM health stats using hcalls described
in Ref[3].  This health and performance stats are then exposed to
userspace via sysfs and PAPR-NVDIMM-Specific-Methods(PDSM) issued by
libndctl.

These changes coupled with proposed ndtcl changes located at Ref[5]
should provide a way for the user to retrieve NVDIMM health status
using ndtcl.

Below is a sample output using proposed kernel + ndctl for PAPR NVDIMM
in a emulation environment:

 # ndctl list -DH
[
  {
"dev":"nmem0",
"health":{
  "health_state":"fatal",
  "shutdown_state":"dirty"
}
  }
]

Dimm health report output on a pseries guest lpar with vPMEM or HMS
based NVDIMMs that are in perfectly healthy conditions:

 # ndctl list -d nmem0 -H
[
  {
"dev":"nmem0",
"health":{
  "health_state":"ok",
  "shutdown_state":"clean"
}
  }
]

PAPR NVDIMM-Specific-Methods(PDSM)
==

PDSM requests are issued by vendor specific code in libndctl to
execute certain operations or fetch information from NVDIMMS. PDSMs
requests can be sent to papr_scm module via libndctl(userspace) and
libnvdimm (kernel) using the ND_CMD_CALL ioctl command which can be
handled in the dimm control function papr_scm_ndctl(). Current
patchset proposes a single PDSM to retrieve NVDIMM health, defined in
the newly introduced uapi header named 'papr_scm_pdsm.h'. Support for
more PDSMs will be added in future.

Structure of the patch-set
==

The patch-set starts with a doc patch documenting details of hcall
H_SCM_HEALTH. Second patch exports kernel symbol seq_buf_printf()
thats used in subsequent patches to generate sysfs attribute content.

Third patch implements support for fetching NVDIMM health information
from PHYP and partially exposing it to user-space via a NVDIMM sysfs
flag.

Fourth patches deal with implementing support for servicing PDSM
commands in papr_scm module.

Finally the last patch implements support for servicing PDSM
'PAPR_SCM_PDSM_HEALTH' that returns the NVDIMM health information to
libndctl.

References:
[2] "Power Architecture Platform Reference"
  https://en.wikipedia.org/wiki/Power_Architecture_Platform_Reference
[3] commit 58b278f568f0
 ("powerpc: Provide initial documentation for PAPR hcalls")
[4] "Linux on Power Architecture Platform Reference"
 https://members.openpowerfoundation.org/document/dl/469
[5] https://github.com/vaibhav92/ndctl/tree/papr_scm_health_v8

---
Vaibhav Jain (5):
  powerpc: Document details on H_SCM_HEALTH hcall
  seq_buf: Export seq_buf_printf
  powerpc/papr_scm: Fetch nvdimm health information from PHYP
  ndctl/papr_scm,uapi: Add support for PAPR nvdimm specific methods
  powerpc/papr_scm: Implement support for PAPR_SCM_PDSM_HEALTH

 Documentation/ABI/testing/sysfs-bus-papr-scm  |  27 ++
 Documentation/powerpc/papr_hcalls.rst |  45 ++-
 arch/powerpc/include/uapi/asm/papr_scm_pdsm.h | 175 +
 arch/powerpc/platforms/pseries/papr_scm.c | 363 +-
 include/uapi/linux/ndctl.h|   1 +
 lib/seq_buf.c |   1 +
 6 files changed, 599 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-papr-scm
 create mode 100644 arch/powerpc/include/uapi/asm/papr_scm_pdsm.h

-- 
2.26.2



[PATCH v8 3/5] powerpc/papr_scm: Fetch nvdimm health information from PHYP

2020-05-26 Thread Vaibhav Jain
Implement support for fetching nvdimm health information via
H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
of 64-bit bitmap, bitwise-and of which is then stored in
'struct papr_scm_priv' and subsequently partially exposed to
user-space via newly introduced dimm specific attribute
'papr/flags'. Since the hcall is costly, the health information is
cached and only re-queried, 60s after the previous successful hcall.

The patch also adds a  documentation text describing flags reported by
the the new sysfs attribute 'papr/flags' is also introduced at
Documentation/ABI/testing/sysfs-bus-papr-scm.

[1] commit 58b278f568f0 ("powerpc: Provide initial documentation for
PAPR hcalls")

Cc: "Aneesh Kumar K . V" 
Cc: Dan Williams 
Cc: Michael Ellerman 
Cc: Ira Weiny 
Signed-off-by: Vaibhav Jain 
---
Changelog:

v7..v8:
* Update type of variable 'rc' in __drc_pmem_query_health() and
  drc_pmem_query_health() to long and int respectively. [ Ira ]
* Updated the patch description to s/64 bit Big Endian Number/64-bit
  bitmap/ [ Ira, Aneesh ].

Resend:
* None

v6..v7 :
* Used the exported buf_seq_printf() function to generate content for
  'papr/flags'
* Moved the PAPR_SCM_DIMM_* bit-flags macro definitions to papr_scm.c
  and removed the papr_scm.h file [Mpe]
* Some minor consistency issued in sysfs-bus-papr-scm
  documentation. [Mpe]
* s/dimm_mutex/health_mutex/g [Mpe]
* Split drc_pmem_query_health() into two function one of which takes
  care of caching and locking. [Mpe]
* Fixed a local copy creation of dimm health information using
  READ_ONCE(). [Mpe]

v5..v6 :
* Change the flags sysfs attribute from 'papr_flags' to 'papr/flags'
  [Dan Williams]
* Include documentation for 'papr/flags' attr [Dan Williams]
* Change flag 'save_fail' to 'flush_fail' [Dan Williams]
* Caching of health bitmap to reduce expensive hcalls [Dan Williams]
* Removed usage of PPC_BIT from 'papr-scm.h' header [Mpe]
* Replaced two __be64 integers from papr_scm_priv to a single u64
  integer [Mpe]
* Updated patch description to reflect the changes made in this
  version.
* Removed avoidable usage of 'papr_scm_priv.dimm_mutex' from
  flags_show() [Dan Williams]

v4..v5 :
* None

v3..v4 :
* None

v2..v3 :
* Removed PAPR_SCM_DIMM_HEALTH_NON_CRITICAL as a condition for
 NVDIMM unarmed [Aneesh]

v1..v2 :
* New patch in the series.
---
 Documentation/ABI/testing/sysfs-bus-papr-scm |  27 +++
 arch/powerpc/platforms/pseries/papr_scm.c| 169 ++-
 2 files changed, 194 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-papr-scm

diff --git a/Documentation/ABI/testing/sysfs-bus-papr-scm 
b/Documentation/ABI/testing/sysfs-bus-papr-scm
new file mode 100644
index ..6143d06072f1
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-papr-scm
@@ -0,0 +1,27 @@
+What:  /sys/bus/nd/devices/nmemX/papr/flags
+Date:  Apr, 2020
+KernelVersion: v5.8
+Contact:   linuxppc-dev , 
linux-nvd...@lists.01.org,
+Description:
+   (RO) Report flags indicating various states of a
+   papr-scm NVDIMM device. Each flag maps to a one or
+   more bits set in the dimm-health-bitmap retrieved in
+   response to H_SCM_HEALTH hcall. The details of the bit
+   flags returned in response to this hcall is available
+   at 'Documentation/powerpc/papr_hcalls.rst' . Below are
+   the flags reported in this sysfs file:
+
+   * "not_armed"   : Indicates that NVDIMM contents will not
+ survive a power cycle.
+   * "flush_fail"  : Indicates that NVDIMM contents
+ couldn't be flushed during last
+ shut-down event.
+   * "restore_fail": Indicates that NVDIMM contents
+ couldn't be restored during NVDIMM
+ initialization.
+   * "encrypted"   : NVDIMM contents are encrypted.
+   * "smart_notify": There is health event for the NVDIMM.
+   * "scrubbed": Indicating that contents of the
+ NVDIMM have been scrubbed.
+   * "locked"  : Indicating that NVDIMM contents cant
+ be modified until next power cycle.
diff --git a/arch/powerpc/platforms/pseries/papr_scm.c 
b/arch/powerpc/platforms/pseries/papr_scm.c
index f35592423380..010cd9aae488 100644
--- a/arch/powerpc/platforms/pseries/papr_scm.c
+++ b/arch/powerpc/platforms/pseries/papr_scm.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -22,6 +23,44 @@
 (1ul << ND_CMD_GET_CONFIG_DATA) | \
 (1ul << ND_CMD_SET_CONFIG_DATA))
 
+/* DIMM health bitmap bitmap indicators */
+/* SCM device is unable to persist memory contents */
+#define PAPR_SCM_DIMM_UNARMED   (1ULL << (63 - 0))
+/* SCM device 

[PATCH V2] opp: Remove bandwidth votes when target_freq is zero

2020-05-26 Thread Viresh Kumar
We already drop several votes when target_freq is set to zero, drop
bandwidth votes as well.

Reported-by: Sibi Sankar 
Signed-off-by: Viresh Kumar 
---
V2: Some changes left uncommited in my tree by mistake.

 drivers/opp/core.c | 49 ++
 1 file changed, 37 insertions(+), 12 deletions(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 56d3022c1ca2..df12c3804533 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -725,6 +725,34 @@ static int _generic_set_opp_regulator(struct opp_table 
*opp_table,
return ret;
 }
 
+static int _set_opp_bw(const struct opp_table *opp_table,
+  struct dev_pm_opp *opp, struct device *dev, bool remove)
+{
+   u32 avg, peak;
+   int i, ret;
+
+   if (!opp_table->paths)
+   return 0;
+
+   for (i = 0; i < opp_table->path_count; i++) {
+   if (remove) {
+   avg = 0;
+   peak = 0;
+   } else {
+   avg = opp->bandwidth[i].avg;
+   peak = opp->bandwidth[i].peak;
+   }
+   ret = icc_set_bw(opp_table->paths[i], avg, peak);
+   if (ret) {
+   dev_err(dev, "Failed to %s bandwidth[%d]: %d\n",
+   remove ? "remove" : "set", i, ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 static int _set_opp_custom(const struct opp_table *opp_table,
   struct device *dev, unsigned long old_freq,
   unsigned long freq,
@@ -820,7 +848,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
unsigned long freq, old_freq, temp_freq;
struct dev_pm_opp *old_opp, *opp;
struct clk *clk;
-   int ret, i;
+   int ret;
 
opp_table = _find_opp_table(dev);
if (IS_ERR(opp_table)) {
@@ -837,12 +865,17 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
if (!_get_opp_count(opp_table))
return 0;
 
-   if (!opp_table->required_opp_tables && !opp_table->regulators) {
+   if (!opp_table->required_opp_tables && !opp_table->regulators &&
+   !opp_table->paths) {
dev_err(dev, "target frequency can't be 0\n");
ret = -EINVAL;
goto put_opp_table;
}
 
+   ret = _set_opp_bw(opp_table, opp, dev, true);
+   if (ret)
+   return ret;
+
if (opp_table->regulator_enabled) {
regulator_disable(opp_table->regulators[0]);
opp_table->regulator_enabled = false;
@@ -932,16 +965,8 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
dev_err(dev, "Failed to set required opps: %d\n", ret);
}
 
-   if (!ret && opp_table->paths) {
-   for (i = 0; i < opp_table->path_count; i++) {
-   ret = icc_set_bw(opp_table->paths[i],
-opp->bandwidth[i].avg,
-opp->bandwidth[i].peak);
-   if (ret)
-   dev_err(dev, "Failed to set bandwidth[%d]: 
%d\n",
-   i, ret);
-   }
-   }
+   if (!ret)
+   ret = _set_opp_bw(opp_table, opp, dev, false);
 
 put_opp:
dev_pm_opp_put(opp);
-- 
2.25.0.rc1.19.g042ed3e048af



[PATCH v8 1/5] powerpc: Document details on H_SCM_HEALTH hcall

2020-05-26 Thread Vaibhav Jain
Add documentation to 'papr_hcalls.rst' describing the bitmap flags
that are returned from H_SCM_HEALTH hcall as per the PAPR-SCM
specification.

Cc: "Aneesh Kumar K . V" 
Cc: Dan Williams 
Cc: Michael Ellerman 
Cc: Ira Weiny 
Signed-off-by: Vaibhav Jain 
---
Changelog:
v7..v8:
* Added a clarification on bit-ordering of Health Bitmap

Resend:
* None

v6..v7:
* None

v5..v6:
* New patch in the series
---
 Documentation/powerpc/papr_hcalls.rst | 45 ---
 1 file changed, 41 insertions(+), 4 deletions(-)

diff --git a/Documentation/powerpc/papr_hcalls.rst 
b/Documentation/powerpc/papr_hcalls.rst
index 3493631a60f8..45063f305813 100644
--- a/Documentation/powerpc/papr_hcalls.rst
+++ b/Documentation/powerpc/papr_hcalls.rst
@@ -220,13 +220,50 @@ from the LPAR memory.
 **H_SCM_HEALTH**
 
 | Input: drcIndex
-| Out: *health-bitmap, health-bit-valid-bitmap*
+| Out: *health-bitmap (r4), health-bit-valid-bitmap (r5)*
 | Return Value: *H_Success, H_Parameter, H_Hardware*
 
 Given a DRC Index return the info on predictive failure and overall health of
-the NVDIMM. The asserted bits in the health-bitmap indicate a single predictive
-failure and health-bit-valid-bitmap indicate which bits in health-bitmap are
-valid.
+the NVDIMM. The asserted bits in the health-bitmap indicate one or more states
+(described in table below) of the NVDIMM and health-bit-valid-bitmap indicate
+which bits in health-bitmap are valid. The bits are reported in
+reverse bit ordering for example a value of 0xC400
+indicates bits 0, 1, and 5 are valid.
+
+Health Bitmap Flags:
+
++--+---+
+|  Bit |   Definition  
|
++==+===+
+|  00  | SCM device is unable to persist memory contents.  
|
+|  | If the system is powered down, nothing will be saved. 
|
++--+---+
+|  01  | SCM device failed to persist memory contents. Either contents were 
not|
+|  | saved successfully on power down or were not restored properly on 
|
+|  | power up. 
|
++--+---+
+|  02  | SCM device contents are persisted from previous IPL. The data from
|
+|  | the last boot were successfully restored. 
|
++--+---+
+|  03  | SCM device contents are not persisted from previous IPL. There was no 
|
+|  | data to restore from the last boot.   
|
++--+---+
+|  04  | SCM device memory life remaining is critically low
|
++--+---+
+|  05  | SCM device will be garded off next IPL due to failure 
|
++--+---+
+|  06  | SCM contents cannot persist due to current platform health status. A  
|
+|  | hardware failure may prevent data from being saved or restored.   
|
++--+---+
+|  07  | SCM device is unable to persist memory contents in certain conditions 
|
++--+---+
+|  08  | SCM device is encrypted   
|
++--+---+
+|  09  | SCM device has successfully completed a requested erase or secure 
|
+|  | erase procedure.  
|
++--+---+
+|10:63 | Reserved / Unused 
|
++--+---+
 
 **H_SCM_PERFORMANCE_STATS**
 
-- 
2.26.2



Re: [PATCH] kexec: Do not verify the signature without the lockdown or mandatory signature

2020-05-26 Thread lijiang
在 2020年05月27日 11:15, lijiang 写道:
> 在 2020年05月26日 21:59, Jiri Bohac 写道:
>> On Mon, May 25, 2020 at 01:23:51PM +0800, Lianbo Jiang wrote:
>>> So, here, let's simplify the logic to improve code readability. If the
>>> KEXEC_SIG_FORCE enabled or kexec lockdown enabled, signature verification
>>> is mandated. Otherwise, we lift the bar for any kernel image.
>>
>> I agree completely; in fact that was my intention when
>> introducing the code, but I got overruled about the return codes:
>> https://lore.kernel.org/lkml/20180119125425.l72meyyc2qtrr...@dwarf.suse.cz/
>>
>> I like this simplification very much, except this part:
>>
>>> +   if (ret) {
>>> +   pr_debug("kernel signature verification failed (%d).\n", ret);
>>
>> ...
>>
>>> -   pr_notice("kernel signature verification failed (%d).\n", ret);
>>
>> I think the log level should stay at most PR_NOTICE when the
>> verification failure results in rejecting the kernel. Perhaps
>> even lower.
>>
> 
> Thank you for the comment, Jiri Bohac.
> 
> I like the idea of staying at most PR_NOTICE, but the pr_notice() will output
> some messages that kernel could want to ignore, such as the case you mentioned
> below.
> 
>> In case verification is not enforced and the failure is
>> ignored, KERN_DEBUG seems reasonable.
>>
> 
> Yes, good understanding. It seems that the pr_debug() is still a good option 
> here?
> Any other thoughts?
> 

Or the following change looks better? What's your opinion?

static int
kimage_validate_signature(struct kimage *image)
{
int ret;

ret = arch_kexec_kernel_verify_sig(image, image->kernel_buf,
   image->kernel_buf_len);
if (ret) {

if (IS_ENABLED(CONFIG_KEXEC_SIG_FORCE)) {
pr_notice("Enforced kernel signature verification 
failed (%d).\n", ret);
return ret;
}

/*
 * If IMA is guaranteed to appraise a signature on the kexec
 * image, permit it even if the kernel is otherwise locked
 * down.
 */
if (!ima_appraise_signature(READING_KEXEC_IMAGE) &&
security_locked_down(LOCKDOWN_KEXEC))
return -EPERM;

pr_debug("kernel signature verification failed (%d).\n", ret);
}

return 0;
}


Thanks.
Lianbo

> Thanks.
> Lianbo
> 
> 
>> Regards,
>>



[PATCH] opp: Remove bandwidth votes when target_freq is zero

2020-05-26 Thread Viresh Kumar
We already drop several votes when target_freq is set to zero, drop
bandwidth votes as well.

Reported-by: Sibi Sankar 
Signed-off-by: Viresh Kumar 
---
@Georgi/Sibi: Sibi requested this change, please test this out.

 drivers/opp/core.c | 47 +++---
 1 file changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 56d3022c1ca2..0c259d5ed232 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -725,6 +725,34 @@ static int _generic_set_opp_regulator(struct opp_table 
*opp_table,
return ret;
 }
 
+static int _set_opp_bw(const struct opp_table *opp_table,
+  struct dev_pm_opp *opp, bool remove)
+{
+   u32 avg, peak;
+   int i, ret;
+
+   if (!opp_table->paths)
+   return 0;
+
+   for (i = 0; i < opp_table->path_count; i++) {
+   if (remove) {
+   avg = 0;
+   peak = 0;
+   } else {
+   avg = opp->bandwidth[i].avg;
+   peak = opp->bandwidth[i].peak;
+   }
+   ret = icc_set_bw(opp_table->paths[i], avg, peak);
+   if (ret) {
+   dev_err(dev, "Failed to %s bandwidth[%d]: %d\n",
+   remove ? "remove" : "set", i, ret);
+   retrun ret;
+   }
+   }
+
+   return 0;
+}
+
 static int _set_opp_custom(const struct opp_table *opp_table,
   struct device *dev, unsigned long old_freq,
   unsigned long freq,
@@ -837,12 +865,17 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
if (!_get_opp_count(opp_table))
return 0;
 
-   if (!opp_table->required_opp_tables && !opp_table->regulators) {
+   if (!opp_table->required_opp_tables && !opp_table->regulators &&
+   !opp_table->paths) {
dev_err(dev, "target frequency can't be 0\n");
ret = -EINVAL;
goto put_opp_table;
}
 
+   ret = _set_opp_bw(opp_table, opp, true);
+   if (ret)
+   return ret;
+
if (opp_table->regulator_enabled) {
regulator_disable(opp_table->regulators[0]);
opp_table->regulator_enabled = false;
@@ -932,16 +965,8 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
dev_err(dev, "Failed to set required opps: %d\n", ret);
}
 
-   if (!ret && opp_table->paths) {
-   for (i = 0; i < opp_table->path_count; i++) {
-   ret = icc_set_bw(opp_table->paths[i],
-opp->bandwidth[i].avg,
-opp->bandwidth[i].peak);
-   if (ret)
-   dev_err(dev, "Failed to set bandwidth[%d]: 
%d\n",
-   i, ret);
-   }
-   }
+   if (!ret)
+   ret = _set_opp_bw(opp_table, opp, false);
 
 put_opp:
dev_pm_opp_put(opp);
-- 
2.25.0.rc1.19.g042ed3e048af



Re: [PATCH RFCv2 7/9] kvm/arm64: Support async page fault

2020-05-26 Thread Gavin Shan

Hi Mark,

On 5/26/20 10:34 PM, Mark Rutland wrote:

On Fri, May 08, 2020 at 01:29:17PM +1000, Gavin Shan wrote:

There are two stages of fault pages and the stage one page fault is
handled by guest itself. The guest is trapped to host when the page
fault is caused by stage 2 page table, for example missing. The guest
is suspended until the requested page is populated. To populate the
requested page can be related to IO activities if the page was swapped
out previously. In this case, the guest has to suspend for a few of
milliseconds at least, regardless of the overall system load. There
is no useful work done during the suspended period from guest's view.


This is a bit difficult to read. How about:

| When a vCPU triggers a Stage-2 fault (e.g. when accessing a page that
| is not mapped at Stage-2), the vCPU is suspended until the host has
| handled the fault. It can take the host milliseconds or longer to
| handle the fault as this may require IO, and when the system load is
| low neither the host nor guest perform useful work during such
| periods.



Yes, It's much better.



This adds asychornous page fault to improve the situation. A signal


Nit: typo for `asynchronous` here, and there are a few other typos in
the patch itself. It would be nice if you could run a spellcheck over
that.



Sure.


(PAGE_NOT_PRESENT) is sent to guest if the requested page needs some time
to be populated. Guest might reschedule to another running process if
possible. Otherwise, the vCPU is put into power-saving mode, which is
actually to cause vCPU reschedule from host's view. A followup signal
(PAGE_READY) is sent to guest once the requested page is populated.
The suspended task is waken up or scheduled when guest receives the
signal. With this mechanism, the vCPU won't be stuck when the requested
page is being populated by host.


It would probably be best to say 'notification' rather than 'signal'
here, and say 'the guest is notified', etc. As above, it seems that this
is per-vCPU, so it's probably better to say 'vCPU' rather than guest, to
make it clear which context this applies to.



Ok.



There are more details highlighted as below. Note the implementation is
similar to what x86 has to some extent:

* A dedicated SMCCC ID is reserved to enable, disable or configure
  the functionality. The only 64-bits parameter is conveyed by two
  registers (w2/w1). Bits[63:56] is the bitmap used to specify the
  operated functionality like enabling/disabling/configuration. The
  bits[55:6] is the physical address of control block or external
  data abort injection disallowed region. Bit[5:0] are used to pass
  control flags.

* Signal (PAGE_NOT_PRESENT) is sent to guest if the requested page
  isn't ready. In the mean while, a work is started to populate the
  page asynchronously in background. The stage 2 page table entry is
  updated accordingly and another signal (PAGE_READY) is fired after
  the request page is populted. The signals is notified by injected
  data abort fault.

* The signals are fired and consumed in sequential fashion. It means
  no more signals will be fired if there is pending one, awaiting the
  guest to consume. It's because the injected data abort faults have
  to be done in sequential fashion.

Signed-off-by: Gavin Shan 
---
  arch/arm64/include/asm/kvm_host.h  |  43 
  arch/arm64/include/asm/kvm_para.h  |  27 ++
  arch/arm64/include/uapi/asm/Kbuild |   2 -
  arch/arm64/include/uapi/asm/kvm_para.h |  22 ++
  arch/arm64/kvm/Kconfig |   1 +
  arch/arm64/kvm/Makefile|   2 +
  include/linux/arm-smccc.h  |   6 +
  virt/kvm/arm/arm.c |  36 ++-
  virt/kvm/arm/async_pf.c| 335 +
  virt/kvm/arm/hypercalls.c  |   8 +
  virt/kvm/arm/mmu.c |  29 ++-
  11 files changed, 506 insertions(+), 5 deletions(-)
  create mode 100644 arch/arm64/include/asm/kvm_para.h
  create mode 100644 arch/arm64/include/uapi/asm/kvm_para.h
  create mode 100644 virt/kvm/arm/async_pf.c

diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index f77c706777ec..a207728d6f3f 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -250,6 +250,23 @@ struct vcpu_reset_state {
boolreset;
  };
  
+#ifdef CONFIG_KVM_ASYNC_PF

+
+/* Should be a power of two number */
+#define ASYNC_PF_PER_VCPU  64


What exactly is this number?



It's maximal number of async page faults pending on the specific vCPU.


+
+/*
+ * The association of gfn and token. The token will be sent to guest as
+ * page fault address. Also, the guest could be in aarch32 mode. So its
+ * length should be 32-bits.
+ */


The length of what should be 32-bit? The token?

The guest sees the token as the fault address? How exactly is that
exposed to the guest, is that via a 

Re: [PATCH v4 06/12] cpufreq: qcom: Update the bandwidth levels on frequency change

2020-05-26 Thread Viresh Kumar
On 27-05-20, 09:23, Viresh Kumar wrote:
> On 26-05-20, 23:18, Sibi Sankar wrote:
> > https://patchwork.kernel.org/cover/11548479/
> > GPU driver uses Georgi's series
> > for scaling and will need a way to
> > remove the icc votes in the suspend
> > path, (this looks like a pattern
> > that might be used by other clients
> > as well) I could probably update
> > opp_set_bw to support removing bw
> > when NULL opp is specified. Similarly
> > opp_set_rate will need to support
> > set bw to 0 when set_rate is passed
> > 0 as target freq for the same use case.
> 
> Sure, please send a patch for that.

On a second thought, here is the patch. Please test it.

-8<-

Subject: [PATCH] opp: Remove bandwidth votes when target_freq is zero

We already drop several votes when target_freq is set to zero, drop
bandwidth votes as well.

Reported-by: Sibi Sankar 
Signed-off-by: Viresh Kumar 
---
 drivers/opp/core.c | 47 +++---
 1 file changed, 36 insertions(+), 11 deletions(-)

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 56d3022c1ca2..0c259d5ed232 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -725,6 +725,34 @@ static int _generic_set_opp_regulator(struct opp_table 
*opp_table,
return ret;
 }
 
+static int _set_opp_bw(const struct opp_table *opp_table,
+  struct dev_pm_opp *opp, bool remove)
+{
+   u32 avg, peak;
+   int i, ret;
+
+   if (!opp_table->paths)
+   return 0;
+
+   for (i = 0; i < opp_table->path_count; i++) {
+   if (remove) {
+   avg = 0;
+   peak = 0;
+   } else {
+   avg = opp->bandwidth[i].avg;
+   peak = opp->bandwidth[i].peak;
+   }
+   ret = icc_set_bw(opp_table->paths[i], avg, peak);
+   if (ret) {
+   dev_err(dev, "Failed to %s bandwidth[%d]: %d\n",
+   remove ? "remove" : "set", i, ret);
+   retrun ret;
+   }
+   }
+
+   return 0;
+}
+
 static int _set_opp_custom(const struct opp_table *opp_table,
   struct device *dev, unsigned long old_freq,
   unsigned long freq,
@@ -837,12 +865,17 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
if (!_get_opp_count(opp_table))
return 0;
 
-   if (!opp_table->required_opp_tables && !opp_table->regulators) {
+   if (!opp_table->required_opp_tables && !opp_table->regulators &&
+   !opp_table->paths) {
dev_err(dev, "target frequency can't be 0\n");
ret = -EINVAL;
goto put_opp_table;
}
 
+   ret = _set_opp_bw(opp_table, opp, true);
+   if (ret)
+   return ret;
+
if (opp_table->regulator_enabled) {
regulator_disable(opp_table->regulators[0]);
opp_table->regulator_enabled = false;
@@ -932,16 +965,8 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
dev_err(dev, "Failed to set required opps: %d\n", ret);
}
 
-   if (!ret && opp_table->paths) {
-   for (i = 0; i < opp_table->path_count; i++) {
-   ret = icc_set_bw(opp_table->paths[i],
-opp->bandwidth[i].avg,
-opp->bandwidth[i].peak);
-   if (ret)
-   dev_err(dev, "Failed to set bandwidth[%d]: 
%d\n",
-   i, ret);
-   }
-   }
+   if (!ret)
+   ret = _set_opp_bw(opp_table, opp, false);
 
 put_opp:
dev_pm_opp_put(opp);


Re: [PATCH v1 1/1] PCI/ERR: Handle fatal error recovery for non-hotplug capable devices

2020-05-26 Thread Kuppuswamy, Sathyanarayanan




On 5/26/20 8:50 PM, Yicong Yang wrote:

Hi,


On 2020/5/27 9:31, Kuppuswamy, Sathyanarayanan wrote:

Hi,

On 5/21/20 7:56 PM, Yicong Yang wrote:



On 2020/5/22 3:31, Kuppuswamy, Sathyanarayanan wrote:



On 5/21/20 3:58 AM, Yicong Yang wrote:

On 2020/5/21 1:04, Kuppuswamy, Sathyanarayanan wrote:



On 5/20/20 1:28 AM, Yicong Yang wrote:

On 2020/5/7 11:32, sathyanarayanan.kuppusw...@linux.intel.com wrote:

From: Kuppuswamy Sathyanarayanan 

If there are non-hotplug capable devices connected to a given
port, then during the fatal error recovery(triggered by DPC or
AER), after calling reset_link() function, we cannot rely on
hotplug handler to detach and re-enumerate the device drivers
in the affected bus. Instead, we will have to let the error
recovery handler call report_slot_reset() for all devices in
the bus to notify about the reset operation. Although this is
only required for non hot-plug capable devices, doing it for
hotplug capable devices should not affect the functionality.

Along with above issue, this fix also applicable to following
issue.

Commit 6d2c89441571 ("PCI/ERR: Update error status after
reset_link()") added support to store status of reset_link()
call. Although this fixed the error recovery issue observed if
the initial value of error status is PCI_ERS_RESULT_DISCONNECT
or PCI_ERS_RESULT_NO_AER_DRIVER, it also discarded the status
result from report_frozen_detected. This can cause a failure to
recover if _NEED_RESET is returned by report_frozen_detected and
report_slot_reset is not invoked.

Such an event can be induced for testing purposes by reducing the
Max_Payload_Size of a PCIe bridge to less than that of a device
downstream from the bridge, and then initiating I/O through the
device, resulting in oversize transactions.  In the presence of DPC,
this results in a containment event and attempted reset and recovery
via pcie_do_recovery.  After 6d2c89441571 report_slot_reset is not
invoked, and the device does not recover.

[original patch is from jay.vosbu...@canonical.com]
[original patch link https://lore.kernel.org/linux-pci/18609.1588812972@famine/]
Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
Signed-off-by: Jay Vosburgh 
Signed-off-by: Kuppuswamy Sathyanarayanan 

---
 drivers/pci/pcie/err.c | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
index 14bb8f54723e..db80e1ecb2dc 100644
--- a/drivers/pci/pcie/err.c
+++ b/drivers/pci/pcie/err.c
@@ -165,13 +165,24 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev *dev,
 pci_dbg(dev, "broadcast error_detected message\n");
 if (state == pci_channel_io_frozen) {
 pci_walk_bus(bus, report_frozen_detected, );
-status = reset_link(dev);
-if (status != PCI_ERS_RESULT_RECOVERED) {
+status = PCI_ERS_RESULT_NEED_RESET;
+} else {
+pci_walk_bus(bus, report_normal_detected, );
+}
+
+if (status == PCI_ERS_RESULT_NEED_RESET) {
+if (reset_link) {
+if (reset_link(dev) != PCI_ERS_RESULT_RECOVERED)


we'll call reset_link() only if link is frozen. so it may have problem here.

you mean before this change right?
After this change, reset_link() will be called as long as status is
PCI_ERS_RESULT_NEED_RESET.


Yes. I think we should reset the link only if the io is blocked as before. 
There's
no reason to reset a normal link.

Currently, only AER and DPC driver uses pcie_do_recovery() call. So the
possible reset_link options are dpc_reset_link() and aer_root_reset().

In dpc_reset_link() case, the link is already disabled and hence we
don't need to do another reset. In case of aer_root_reset() it
uses pci_bus_error_reset() to reset the slot.


Not exactly. In pci_bus_error_reset(), we call pci_slot_reset() only if it's
hotpluggable. But we always call pci_bus_reset() to perform a secondary bus
reset for the bridge. That's what I think is unnecessary for a normal link,
and that's what reset link indicates us to do. The slot reset is introduced
in the process only to solve side effects. (c4eed62a2143, PCI/ERR: Use slot 
reset if available)


IIUC, pci_bus_reset() will do slot reset if its supported (hot-plug
capable slots). If its not supported then it will attempt secondary
bus reset. So secondary bus reset will be attempted only if slot
reset is not supported.

Since reported_error_detected() requests us to do reset, we will have
to attempt some kind of reset before we call ->slot_reset() right?
What is the side effect in calling secondary bus reset?


I agree we should do a slot reset if driver required. The question is if we 
apply
the patch, think of a situation that the io is normal, the slot is not 
hotpluggable but
driver reports a reset, then:
-->aer_root_reset()
->pci_bus_error_reset()
-> pci_bridge_secondary_bus_reset()  // Is it necessary to reset if the 
link is not blocked?

Before commit (c4eed62a2143, PCI/ERR: Use 

[PATCH] f2fs: protect new segment allocation in expand_inode_data

2020-05-26 Thread Daeho Jeong
From: Daeho Jeong 

Found a new segemnt allocation without f2fs_lock_op() in
expand_inode_data(). So, when we do fallocate() for a pinned file
and trigger checkpoint very frequently and simultaneously. F2FS gets
stuck in the below code of do_checkpoint() forever.

  f2fs_sync_meta_pages(sbi, META, LONG_MAX, FS_CP_META_IO);
  /* Wait for all dirty meta pages to be submitted for IO */
<= if fallocate() here,
  f2fs_wait_on_all_pages(sbi, F2FS_DIRTY_META); <= it'll wait forever.

Signed-off-by: Daeho Jeong 
---
 fs/f2fs/file.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f7de2a1da528..14ace885baa9 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1660,7 +1660,11 @@ static int expand_inode_data(struct inode *inode, loff_t 
offset,
 
down_write(>pin_sem);
map.m_seg_type = CURSEG_COLD_DATA_PINNED;
+
+   f2fs_lock_op(sbi);
f2fs_allocate_new_segments(sbi, CURSEG_COLD_DATA);
+   f2fs_unlock_op(sbi);
+
err = f2fs_map_blocks(inode, , 1, F2FS_GET_BLOCK_PRE_DIO);
up_write(>pin_sem);
 
-- 
2.27.0.rc0.183.gde8f92d652-goog



Re: [PATCH v30 07/20] x86/sgx: Enumerate and track EPC sections

2020-05-26 Thread Sean Christopherson
On Mon, May 25, 2020 at 11:23:04AM +0200, Borislav Petkov wrote:
> On Fri, May 15, 2020 at 03:43:57AM +0300, Jarkko Sakkinen wrote:
> > +struct sgx_epc_section sgx_epc_sections[SGX_MAX_EPC_SECTIONS];
> > +int sgx_nr_epc_sections;
> 
> We have become very averse against global stuff. What is going to use
> those, only sgx code I assume...?

Yes, only SGX code.  The reclaim/swap code needs access to the sections,
and that code is in a different file, reclaim.c.  I don't have a super
strong objection to sucking reclaim.c into main.c, but I'm somewhat
indifferent on code organization as a whole.  Jarkko likely has a stronger
opinion.

> > +static bool __init sgx_page_cache_init(void)
> > +{
> > +   u32 eax, ebx, ecx, edx, type;
> > +   u64 pa, size;
> > +   int i;
> > +
> > +   for (i = 0; i <= ARRAY_SIZE(sgx_epc_sections); i++) {
> > +   cpuid_count(SGX_CPUID, i + SGX_CPUID_FIRST_VARIABLE_SUB_LEAF,
> > +   , , , );
> > +
> > +   type = eax & SGX_CPUID_SUB_LEAF_TYPE_MASK;
> > +   if (type == SGX_CPUID_SUB_LEAF_INVALID)
> > +   break;
> > +
> > +   if (type != SGX_CPUID_SUB_LEAF_EPC_SECTION) {
> > +   pr_err_once("Unknown EPC section type: %u\n", type);
> > +   break;
> > +   }
> > +
> > +   if (i == ARRAY_SIZE(sgx_epc_sections)) {
> > +   pr_warn("No free slot for an EPC section\n");
> > +   break;
> > +   }
> 
> This is also the loop termination: do we really need this warn or can
> the loop simply do "i < ARRAY_SIZE" ?

The warn alerts the user that there will effectively be lost/unused memory,
so IMO it's worth keeping.
 
> If the warn is needed, it can be after the loop too.
> > +
> > +   pa = sgx_calc_section_metric(eax, ebx);
> > +   size = sgx_calc_section_metric(ecx, edx);
> > +
> > +   pr_info("EPC section 0x%llx-0x%llx\n", pa, pa + size - 1);
> 
> I'm assuming that's useful information to issue in dmesg?

Yes, it's effectively the equivalent of dumping the e820 tables.  It might
not be as useful now that the code is stable, but I suspect it will come in
handy for debug/triage down the road.
 
> > diff --git a/arch/x86/kernel/cpu/sgx/reclaim.c 
> > b/arch/x86/kernel/cpu/sgx/reclaim.c
> > new file mode 100644
> > index ..215371588a25
> > --- /dev/null
> > +++ b/arch/x86/kernel/cpu/sgx/reclaim.c
> > @@ -0,0 +1,82 @@
> > +// SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause)
> > +// Copyright(c) 2016-19 Intel Corporation.
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "encls.h"
> > +
> > +struct task_struct *ksgxswapd_tsk;
> 
> Same for this one: also shared only among sgx code?

Yes, that one can definitely be buried behind a helper.

> > +/**
> > + * enum sgx_epc_page_desc - bits and masks for an EPC page's descriptor
> > + * %SGX_EPC_SECTION_MASK:  SGX allows to have multiple EPC sections in the
> > + * physical memory. The existing and near-future
> > + * hardware defines at most eight sections, hence
> > + * three bits to hold a section.
> > + */
> > +enum sgx_epc_page_desc {
> > +   SGX_EPC_SECTION_MASK= GENMASK_ULL(3, 0),
> 
> If that should be three bits, then it should be (2, 0). Because now you
> have 4 bits:

Apparently even pre-school math is hard these days.  I'm pretty sure that's
an ongoing brain fart, I don't think we ever conciously bumped it to 4 bits.

That being said, using 4 bits (or even 5+) isn't necessary a bad thing.  We
aren't tight on bits and the burned memory isn't awful, e.g. <100 bytes per
unused section.  Not having to update the kernel just to handle a system
with more EPC sections would be nice, though we (Intel) should check on our
end to see if nearish-future CPUs are still hard limited to eight sections.

One idea would be to provide a Kconfig a la NR_CPUS or NODES_SHIFT.  I.e.
carve out the bits in sgx_epc_page_desc to allow up to N sections, but let
the user limit the number of sections to recoup the unused memory.

> # arch/x86/kernel/cpu/sgx/sgx.h:56: return _epc_sections[page->desc & 
> SGX_EPC_SECTION_MASK];
> andl$15, %edx   #, _22
>   ^^^
> 
> > +   /* bits 12-63 are reserved for the physical page address of the page */
> > +};


Re: [PATCH v4 06/12] cpufreq: qcom: Update the bandwidth levels on frequency change

2020-05-26 Thread Viresh Kumar
On 26-05-20, 23:18, Sibi Sankar wrote:
> https://patchwork.kernel.org/cover/11548479/
> GPU driver uses Georgi's series
> for scaling and will need a way to
> remove the icc votes in the suspend
> path, (this looks like a pattern
> that might be used by other clients
> as well) I could probably update
> opp_set_bw to support removing bw
> when NULL opp is specified. Similarly
> opp_set_rate will need to support
> set bw to 0 when set_rate is passed
> 0 as target freq for the same use case.

Sure, please send a patch for that.

-- 
viresh


Re: [PATCH v8 2/2] clk: intel: Add CGU clock driver for a new SoC

2020-05-26 Thread Tanwar, Rahul


Hi Stephen,

On 27/5/2020 10:10 am, Stephen Boyd wrote:
> Quoting Rahul Tanwar (2020-04-16 22:54:47)
>> diff --git a/drivers/clk/x86/clk-cgu.c b/drivers/clk/x86/clk-cgu.c
>> new file mode 100644
>> index ..802a7fa88535
>> --- /dev/null
>> +++ b/drivers/clk/x86/clk-cgu.c
>> @@ -0,0 +1,636 @@
> [...]
>> +   ctx->membase = devm_platform_ioremap_resource(pdev, 0);
>> +   if (IS_ERR(ctx->membase))
>> +   return PTR_ERR(ctx->membase);
>> +
>> +   ctx->np = np;
>> +   ctx->dev = dev;
>> +   spin_lock_init(>lock);
>> +
>> +   ret = lgm_clk_register_plls(ctx, lgm_pll_clks,
>> +   ARRAY_SIZE(lgm_pll_clks));
>> +   if (ret)
>> +   return ret;
>> +
>> +   ret = lgm_clk_register_branches(ctx, lgm_branch_clks,
>> +   ARRAY_SIZE(lgm_branch_clks));
>> +   if (ret)
>> +   return ret;
>> +
>> +   ret = lgm_clk_register_ddiv(ctx, lgm_ddiv_clks,
>> +   ARRAY_SIZE(lgm_ddiv_clks));
>> +   if (ret)
>> +   return ret;
>> +
>> +   ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
>> + >clk_data);
>> +   if (ret)
>> +   return ret;
> Are any of the clks unregistered on failure? It looks like devm_ isn't
> used for registration so nothing can be undone? Please fix this in a
> future patch.

Thanks a lot for accepting the patch series. I went through all of your
comments and i agree with all of them. Will fix it & address other
review concerns in a future patch once 5.8 is released.

Regards,
Rahul



Re: [PATCH v1 1/1] PCI/ERR: Handle fatal error recovery for non-hotplug capable devices

2020-05-26 Thread Yicong Yang
Hi,


On 2020/5/27 9:31, Kuppuswamy, Sathyanarayanan wrote:
> Hi,
>
> On 5/21/20 7:56 PM, Yicong Yang wrote:
>>
>>
>> On 2020/5/22 3:31, Kuppuswamy, Sathyanarayanan wrote:
>>>
>>>
>>> On 5/21/20 3:58 AM, Yicong Yang wrote:
 On 2020/5/21 1:04, Kuppuswamy, Sathyanarayanan wrote:
>
>
> On 5/20/20 1:28 AM, Yicong Yang wrote:
>> On 2020/5/7 11:32, sathyanarayanan.kuppusw...@linux.intel.com wrote:
>>> From: Kuppuswamy Sathyanarayanan 
>>> 
>>>
>>> If there are non-hotplug capable devices connected to a given
>>> port, then during the fatal error recovery(triggered by DPC or
>>> AER), after calling reset_link() function, we cannot rely on
>>> hotplug handler to detach and re-enumerate the device drivers
>>> in the affected bus. Instead, we will have to let the error
>>> recovery handler call report_slot_reset() for all devices in
>>> the bus to notify about the reset operation. Although this is
>>> only required for non hot-plug capable devices, doing it for
>>> hotplug capable devices should not affect the functionality.
>>>
>>> Along with above issue, this fix also applicable to following
>>> issue.
>>>
>>> Commit 6d2c89441571 ("PCI/ERR: Update error status after
>>> reset_link()") added support to store status of reset_link()
>>> call. Although this fixed the error recovery issue observed if
>>> the initial value of error status is PCI_ERS_RESULT_DISCONNECT
>>> or PCI_ERS_RESULT_NO_AER_DRIVER, it also discarded the status
>>> result from report_frozen_detected. This can cause a failure to
>>> recover if _NEED_RESET is returned by report_frozen_detected and
>>> report_slot_reset is not invoked.
>>>
>>> Such an event can be induced for testing purposes by reducing the
>>> Max_Payload_Size of a PCIe bridge to less than that of a device
>>> downstream from the bridge, and then initiating I/O through the
>>> device, resulting in oversize transactions.  In the presence of DPC,
>>> this results in a containment event and attempted reset and recovery
>>> via pcie_do_recovery.  After 6d2c89441571 report_slot_reset is not
>>> invoked, and the device does not recover.
>>>
>>> [original patch is from jay.vosbu...@canonical.com]
>>> [original patch link 
>>> https://lore.kernel.org/linux-pci/18609.1588812972@famine/]
>>> Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
>>> Signed-off-by: Jay Vosburgh 
>>> Signed-off-by: Kuppuswamy Sathyanarayanan 
>>> 
>>> ---
>>> drivers/pci/pcie/err.c | 19 +++
>>> 1 file changed, 15 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/pci/pcie/err.c b/drivers/pci/pcie/err.c
>>> index 14bb8f54723e..db80e1ecb2dc 100644
>>> --- a/drivers/pci/pcie/err.c
>>> +++ b/drivers/pci/pcie/err.c
>>> @@ -165,13 +165,24 @@ pci_ers_result_t pcie_do_recovery(struct pci_dev 
>>> *dev,
>>> pci_dbg(dev, "broadcast error_detected message\n");
>>> if (state == pci_channel_io_frozen) {
>>> pci_walk_bus(bus, report_frozen_detected, );
>>> -status = reset_link(dev);
>>> -if (status != PCI_ERS_RESULT_RECOVERED) {
>>> +status = PCI_ERS_RESULT_NEED_RESET;
>>> +} else {
>>> +pci_walk_bus(bus, report_normal_detected, );
>>> +}
>>> +
>>> +if (status == PCI_ERS_RESULT_NEED_RESET) {
>>> +if (reset_link) {
>>> +if (reset_link(dev) != PCI_ERS_RESULT_RECOVERED)
>>
>> we'll call reset_link() only if link is frozen. so it may have problem 
>> here.
> you mean before this change right?
> After this change, reset_link() will be called as long as status is
> PCI_ERS_RESULT_NEED_RESET.

 Yes. I think we should reset the link only if the io is blocked as before. 
 There's
 no reason to reset a normal link.
>>> Currently, only AER and DPC driver uses pcie_do_recovery() call. So the
>>> possible reset_link options are dpc_reset_link() and aer_root_reset().
>>>
>>> In dpc_reset_link() case, the link is already disabled and hence we
>>> don't need to do another reset. In case of aer_root_reset() it
>>> uses pci_bus_error_reset() to reset the slot.
>>
>> Not exactly. In pci_bus_error_reset(), we call pci_slot_reset() only if it's
>> hotpluggable. But we always call pci_bus_reset() to perform a secondary bus
>> reset for the bridge. That's what I think is unnecessary for a normal link,
>> and that's what reset link indicates us to do. The slot reset is introduced
>> in the process only to solve side effects. (c4eed62a2143, PCI/ERR: Use slot 
>> reset if available)
>
> IIUC, pci_bus_reset() will do slot reset if its supported (hot-plug
> capable slots). If its not supported then it will attempt secondary
> bus reset. So secondary bus reset will be attempted only if slot
> reset is not 

[v2,1/1] hwmon:(nct7904) Set default timeout

2020-05-26 Thread yuechao.zhao
From: Yuechao Zhao 

The timeout module parameter should not be used for setting the default
timeout. Because, if you set the timeout = 0, the default timeout will
be meaningless. And the timeout module parameter of 0 means "no timeout
module paraameter specified".

Signed-off-by: Yuechao Zhao 
---
- modify subject to 'hwmon:(nct7904) Set default timeout'
---
 drivers/hwmon/nct7904.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/nct7904.c b/drivers/hwmon/nct7904.c
index 18c95be..27eb276 100644
--- a/drivers/hwmon/nct7904.c
+++ b/drivers/hwmon/nct7904.c
@@ -1147,7 +1147,7 @@ static int nct7904_probe(struct i2c_client *client,
data->wdt.ops = _wdt_ops;
data->wdt.info = _wdt_info;
 
-   data->wdt.timeout = timeout * 60; /* in seconds */
+   data->wdt.timeout = WATCHDOG_TIMEOUT * 60; /* Set default timeout */
data->wdt.min_timeout = MIN_TIMEOUT;
data->wdt.max_timeout = MAX_TIMEOUT;
data->wdt.parent = >dev;
-- 
1.8.3.1



Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin

2020-05-26 Thread Daniel Drake
Hi Maxime,

On Tue, May 26, 2020 at 6:20 PM Maxime Ripard  wrote:
> I gave it a try with U-Boot with my latest work and couldn't reproduce it, so 
> it
> seems that I fixed it along the way

Is your latest work available in a git branch anywhere that we could
test directly?

Thanks
Daniel


[v3 2/2] dts: ppc: t1024rdb: remove interrupts property

2020-05-26 Thread Biwen Li
From: Biwen Li 

Since the interrupt pin for RTC DS1339 is not connected
to the CPU on T1024RDB, remove the interrupt property
from the device tree.

This also fix the following warning for hwclock.util-linux:
$ hwclock.util-linux
hwclock.util-linux: select() to /dev/rtc0
to wait for clock tick timed out

Signed-off-by: Biwen Li 
---
 arch/powerpc/boot/dts/fsl/t1024rdb.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/fsl/t1024rdb.dts 
b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
index 645caff98ed1..605ceec66af3 100644
--- a/arch/powerpc/boot/dts/fsl/t1024rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t1024rdb.dts
@@ -161,7 +161,6 @@
rtc@68 {
compatible = "dallas,ds1339";
reg = <0x68>;
-   interrupts = <0x1 0x1 0 0>;
};
};
 
-- 
2.17.1



[v3 1/2] dts: ppc: t4240rdb: remove interrupts property

2020-05-26 Thread Biwen Li
From: Biwen Li 

Since the interrupt pin for RTC DS1374 is not connected
to the CPU on T4240RDB, remove the interrupt property
from the device tree.

This also fix the following warning for hwclock.util-linux:
$ hwclock.util-linux
hwclock.util-linux: select() to /dev/rtc0
to wait for clock tick timed out

Signed-off-by: Biwen Li 
---
 arch/powerpc/boot/dts/fsl/t4240rdb.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/powerpc/boot/dts/fsl/t4240rdb.dts 
b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
index a56a705d41f7..145896f2eef6 100644
--- a/arch/powerpc/boot/dts/fsl/t4240rdb.dts
+++ b/arch/powerpc/boot/dts/fsl/t4240rdb.dts
@@ -144,7 +144,6 @@
rtc@68 {
compatible = "dallas,ds1374";
reg = <0x68>;
-   interrupts = <0x1 0x1 0 0>;
};
};
 
-- 
2.17.1



[PATCH v2] bluetooth: hci_qca: Fix QCA6390 memdump failure

2020-05-26 Thread Zijun Hu
QCA6390 memdump VSE sometimes come to bluetooth driver
with wrong sequence number as illustrated as follows:
frame # in DEC: frame data in HEX
1396: ff fd 01 08 74 05 00 37 8f 14
1397: ff fd 01 08 75 05 00 ff bf 38
1414: ff fd 01 08 86 05 00 fb 5e 4b
1399: ff fd 01 08 77 05 00 f3 44 0a
1400: ff fd 01 08 78 05 00 ca f7 41
it is mistook for controller missing packets, so results
in page fault after overwriting memdump buffer allocated.

it is fixed by ignoring QCA6390 sequence number error
and checking buffer space before writing.

Signed-off-by: Zijun Hu 
---
 drivers/bluetooth/hci_qca.c | 45 ++---
 1 file changed, 38 insertions(+), 7 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index e4a6823..388fe01b 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -114,6 +114,7 @@ struct qca_memdump_data {
char *memdump_buf_tail;
u32 current_seq_no;
u32 received_dump;
+   u32 ram_dump_size;
 };
 
 struct qca_memdump_event_hdr {
@@ -976,6 +977,8 @@ static void qca_controller_memdump(struct work_struct *work)
char nullBuff[QCA_DUMP_PACKET_SIZE] = { 0 };
u16 seq_no;
u32 dump_size;
+   u32 rx_size;
+   enum qca_btsoc_type soc_type = qca_soc_type(hu);
 
while ((skb = skb_dequeue(>rx_memdump_q))) {
 
@@ -1029,6 +1032,7 @@ static void qca_controller_memdump(struct work_struct 
*work)
 
skb_pull(skb, sizeof(dump_size));
memdump_buf = vmalloc(dump_size);
+   qca_memdump->ram_dump_size = dump_size;
qca_memdump->memdump_buf_head = memdump_buf;
qca_memdump->memdump_buf_tail = memdump_buf;
}
@@ -1052,25 +1056,52 @@ static void qca_controller_memdump(struct work_struct 
*work)
 * packets in the buffer.
 */
while ((seq_no > qca_memdump->current_seq_no + 1) &&
+   (soc_type != QCA_QCA6390) &&
seq_no != QCA_LAST_SEQUENCE_NUM) {
bt_dev_err(hu->hdev, "QCA controller missed packet:%d",
   qca_memdump->current_seq_no);
+   rx_size = qca_memdump->received_dump;
+   rx_size += QCA_DUMP_PACKET_SIZE;
+   if (rx_size > qca_memdump->ram_dump_size) {
+   bt_dev_err(hu->hdev,
+   "QCA memdump received %d, no 
space for missed packet",
+   qca_memdump->received_dump);
+   break;
+   }
memcpy(memdump_buf, nullBuff, QCA_DUMP_PACKET_SIZE);
memdump_buf = memdump_buf + QCA_DUMP_PACKET_SIZE;
qca_memdump->received_dump += QCA_DUMP_PACKET_SIZE;
qca_memdump->current_seq_no++;
}
 
-   memcpy(memdump_buf, (unsigned char *) skb->data, skb->len);
-   memdump_buf = memdump_buf + skb->len;
-   qca_memdump->memdump_buf_tail = memdump_buf;
-   qca_memdump->current_seq_no = seq_no + 1;
-   qca_memdump->received_dump += skb->len;
+   rx_size = qca_memdump->received_dump + skb->len;
+   if (rx_size <= qca_memdump->ram_dump_size) {
+   if ((seq_no != QCA_LAST_SEQUENCE_NUM) &&
+   (seq_no != qca_memdump->current_seq_no))
+   bt_dev_err(hu->hdev,
+   "QCA memdump unexpected packet 
%d",
+   seq_no);
+   bt_dev_dbg(hu->hdev,
+   "QCA memdump packet %d with length %d",
+   seq_no, skb->len);
+   memcpy(memdump_buf, (unsigned char *)skb->data,
+   skb->len);
+   memdump_buf = memdump_buf + skb->len;
+   qca_memdump->memdump_buf_tail = memdump_buf;
+   qca_memdump->current_seq_no = seq_no + 1;
+   qca_memdump->received_dump += skb->len;
+   } else {
+   bt_dev_err(hu->hdev,
+   "QCA memdump received %d, no space for 
packet %d",
+   qca_memdump->received_dump, seq_no);
+   }
qca->qca_memdump = qca_memdump;
kfree_skb(skb);
if (seq_no == QCA_LAST_SEQUENCE_NUM) {
-   bt_dev_info(hu->hdev, "QCA writing crash dump of size 
%d bytes",
-  qca_memdump->received_dump);
+   bt_dev_info(hu->hdev,
+  

Re: [PATCH v1 1/1] PCI/ERR: Handle fatal error recovery for non-hotplug capable devices

2020-05-26 Thread Oliver O'Halloran
On Wed, May 27, 2020 at 1:06 PM Kuppuswamy, Sathyanarayanan
 wrote:
>
> Yes, in case of DPC (Fatal errors) link is already reset. So we
> don't need any special handling. This reset logic is mainly for
> non-fatal errors.

Why? In our experience most fatal errors aren't all that fatal and can
be recovered by resetting the device. The base spec backs that up (see
gen5 base, sec 6.2) too saying the main point of distinction between
fatal and non-fatal errors is whether handling the error requires a
reset or not. For EEH we always try to recover the device and only
mark it as permanently failed once the devices goes over the max error
threshold (5 errors per hour, by default). Doing something similar for
(native) DPC would make sense IMO.


[PATCH] drivers: ipa: remove discription of nonexistent element

2020-05-26 Thread Wang Wenhu
No element named "client" exists within "struct ipa_endpoint".
It might be a heritage forgotten to be removed. Delete it now.

Signed-off-by: Wang Wenhu 
---
 drivers/net/ipa/ipa_endpoint.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/ipa/ipa_endpoint.h b/drivers/net/ipa/ipa_endpoint.h
index 4b336a1f759d..bbee9535d4b2 100644
--- a/drivers/net/ipa/ipa_endpoint.h
+++ b/drivers/net/ipa/ipa_endpoint.h
@@ -41,7 +41,6 @@ enum ipa_endpoint_name {
 
 /**
  * struct ipa_endpoint - IPA endpoint information
- * @client:Client associated with the endpoint
  * @channel_id:EP's GSI channel
  * @evt_ring_id: EP's GSI channel event ring
  */
-- 
2.17.1



Re: [PATCH] net: sctp: Fix spelling in Kconfig help

2020-05-26 Thread David Miller
From: Chris Packham 
Date: Tue, 26 May 2020 10:55:59 +1200

> Change 'handeled' to 'handled' in the Kconfig help for SCTP.
> 
> Signed-off-by: Chris Packham 

Applied.


  1   2   3   4   5   6   7   8   9   10   >