Re: [PATCH] f2fs: fix to avoid out-of-bounds memory access
Hi, I have tested the patch on 5.12.0-rc4+, it seems to fix the problem. Regards, butt3rflyh4ck. On Mon, Mar 22, 2021 at 7:47 PM Chao Yu wrote: > > butt3rflyh4ck reported a bug found by > syzkaller fuzzer with custom modifications in 5.12.0-rc3+ [1]: > > dump_stack+0xfa/0x151 lib/dump_stack.c:120 > print_address_description.constprop.0.cold+0x82/0x32c mm/kasan/report.c:232 > __kasan_report mm/kasan/report.c:399 [inline] > kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416 > f2fs_test_bit fs/f2fs/f2fs.h:2572 [inline] > current_nat_addr fs/f2fs/node.h:213 [inline] > get_next_nat_page fs/f2fs/node.c:123 [inline] > __flush_nat_entry_set fs/f2fs/node.c:2888 [inline] > f2fs_flush_nat_entries+0x258e/0x2960 fs/f2fs/node.c:2991 > f2fs_write_checkpoint+0x1372/0x6a70 fs/f2fs/checkpoint.c:1640 > f2fs_issue_checkpoint+0x149/0x410 fs/f2fs/checkpoint.c:1807 > f2fs_sync_fs+0x20f/0x420 fs/f2fs/super.c:1454 > __sync_filesystem fs/sync.c:39 [inline] > sync_filesystem fs/sync.c:67 [inline] > sync_filesystem+0x1b5/0x260 fs/sync.c:48 > generic_shutdown_super+0x70/0x370 fs/super.c:448 > kill_block_super+0x97/0xf0 fs/super.c:1394 > > The root cause is, if nat entry in checkpoint journal area is corrupted, > e.g. nid of journalled nat entry exceeds max nid value, during checkpoint, > once it tries to flush nat journal to NAT area, get_next_nat_page() may > access out-of-bounds memory on nat_bitmap due to it uses wrong nid value > as bitmap offset. > > [1] > https://lore.kernel.org/lkml/cafco6xomwdr8pobek6en6-fs58kg9dorfadgjj-fnf-1x43...@mail.gmail.com/T/#u > > Reported-by: butt3rflyh4ck > Signed-off-by: Chao Yu > --- > fs/f2fs/node.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c > index caf43970510e..8311b2367c7c 100644 > --- a/fs/f2fs/node.c > +++ b/fs/f2fs/node.c > @@ -2790,6 +2790,9 @@ static void remove_nats_in_journal(struct f2fs_sb_info > *sbi) > struct f2fs_nat_entry raw_ne; > nid_t nid = le32_to_cpu(nid_in_journal(journal, i)); > > + if (f2fs_check_nid_range(sbi, nid)) > + continue; > + > raw_ne = nat_in_journal(journal, i); > > ne = __lookup_nat_cache(nm_i, nid); > -- > 2.29.2 >
Re: [PATCH 1/3] w1: ds2438: fixed a coding style issues
On Mon, Mar 22, 2021 at 11:42:09PM -0300, Luiz Sampaio wrote: > Fixed coding style issues. > > Signed-off-by: Luiz Sampaio > --- > drivers/w1/slaves/w1_ds2438.c | 26 -- > 1 file changed, 12 insertions(+), 14 deletions(-) Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - Your patch did many different things all at once, making it difficult to review. All Linux kernel patches need to only do one thing at a time. If you need to do multiple things (such as clean up all coding style issues in a file/driver), do it in a sequence of patches, each one doing only one thing. This will make it easier to review the patches to ensure that they are correct, and to help alleviate any merge issues that larger patches can cause. - You did not specify a description of why the patch is needed, or possibly, any description at all, in the email body. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what is needed in order to properly describe the change. - You did not write a descriptive Subject: for the patch, allowing Greg, and everyone else, to know what this patch is all about. Please read the section entitled "The canonical patch format" in the kernel file, Documentation/SubmittingPatches for what a proper Subject: line should look like. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
[PATCH v8 3/3] mtd: rawnand: Add support for secure regions in NAND memory
On a typical end product, a vendor may choose to secure some regions in
the NAND memory which are supposed to stay intact between FW upgrades.
The access to those regions will be blocked by a secure element like
Trustzone. So the normal world software like Linux kernel should not
touch these regions (including reading).
The regions are declared using a NAND chip DT property,
"secure-regions". So let's make use of this property in the raw NAND
core and skip access to the secure regions present in a system.
Signed-off-by: Manivannan Sadhasivam
---
drivers/mtd/nand/raw/nand_base.c | 105 +++
include/linux/mtd/rawnand.h | 14 +
2 files changed, 119 insertions(+)
diff --git a/drivers/mtd/nand/raw/nand_base.c b/drivers/mtd/nand/raw/nand_base.c
index c33fa1b1847f..2a990219f498 100644
--- a/drivers/mtd/nand/raw/nand_base.c
+++ b/drivers/mtd/nand/raw/nand_base.c
@@ -278,11 +278,46 @@ static int nand_block_bad(struct nand_chip *chip, loff_t
ofs)
return 0;
}
+/**
+ * nand_check_secure_region() - Check if the region is secured
+ * @chip: NAND chip object
+ * @offset: Offset of the region to check
+ * @size: Size of the region to check
+ *
+ * Checks if the region is secured by comparing the offset and size with the
+ * list of secure regions obtained from DT. Returns -EIO if the region is
+ * secured else 0.
+ */
+static int nand_check_secure_region(struct nand_chip *chip, loff_t offset, u64
size)
+{
+ int i;
+
+ /* Skip touching the secure regions if present */
+ for (i = 0; i < chip->nr_secure_regions; i++) {
+ const struct nand_secure_region *region =
>secure_regions[i];
+
+ if (offset + size < region->offset ||
+ offset >= region->offset + region->size)
+ continue;
+
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int nand_isbad_bbm(struct nand_chip *chip, loff_t ofs)
{
+ int ret;
+
if (chip->options & NAND_NO_BBM_QUIRK)
return 0;
+ /* Check if the region is secured */
+ ret = nand_check_secure_region(chip, ofs, 0);
+ if (ret)
+ return ret;
+
if (chip->legacy.block_bad)
return chip->legacy.block_bad(chip, ofs);
@@ -397,6 +432,11 @@ static int nand_do_write_oob(struct nand_chip *chip,
loff_t to,
return -EINVAL;
}
+ /* Check if the region is secured */
+ ret = nand_check_secure_region(chip, to, ops->ooblen);
+ if (ret)
+ return ret;
+
chipnr = (int)(to >> chip->chip_shift);
/*
@@ -565,6 +605,11 @@ static int nand_block_isreserved(struct mtd_info *mtd,
loff_t ofs)
if (!chip->bbt)
return 0;
+
+ /* Check if the region is secured */
+ if (nand_check_secure_region(chip, ofs, 0))
+ return -EIO;
+
/* Return info from the table */
return nand_isreserved_bbt(chip, ofs);
}
@@ -3127,6 +3172,11 @@ static int nand_do_read_ops(struct nand_chip *chip,
loff_t from,
int retry_mode = 0;
bool ecc_fail = false;
+ /* Check if the region is secured */
+ ret = nand_check_secure_region(chip, from, readlen);
+ if (ret)
+ return ret;
+
chipnr = (int)(from >> chip->chip_shift);
nand_select_target(chip, chipnr);
@@ -3458,6 +3508,11 @@ static int nand_do_read_oob(struct nand_chip *chip,
loff_t from,
pr_debug("%s: from = 0x%08Lx, len = %i\n",
__func__, (unsigned long long)from, readlen);
+ /* Check if the region is secured */
+ ret = nand_check_secure_region(chip, from, readlen);
+ if (ret)
+ return ret;
+
stats = mtd->ecc_stats;
len = mtd_oobavail(mtd, ops);
@@ -3979,6 +4034,11 @@ static int nand_do_write_ops(struct nand_chip *chip,
loff_t to,
return -EINVAL;
}
+ /* Check if the region is secured */
+ ret = nand_check_secure_region(chip, to, writelen);
+ if (ret)
+ return ret;
+
column = to & (mtd->writesize - 1);
chipnr = (int)(to >> chip->chip_shift);
@@ -4180,6 +4240,11 @@ int nand_erase_nand(struct nand_chip *chip, struct
erase_info *instr,
if (check_offs_len(chip, instr->addr, instr->len))
return -EINVAL;
+ /* Check if the region is secured */
+ ret = nand_check_secure_region(chip, instr->addr, instr->len);
+ if (ret)
+ return ret;
+
/* Grab the lock and see if the device is available */
ret = nand_get_device(chip);
if (ret)
@@ -4995,10 +5060,37 @@ static bool of_get_nand_on_flash_bbt(struct device_node
*np)
return of_property_read_bool(np, "nand-on-flash-bbt");
}
+static int of_get_nand_secure_regions(struct nand_chip *chip)
+{
+ struct device_node *dn = nand_get_flash_node(chip);
+ struct property *prop;
+
[PATCH v8 1/3] dt-bindings: mtd: Convert Qcom NANDc binding to YAML
Convert Qcom NANDc devicetree binding to YAML.
Signed-off-by: Manivannan Sadhasivam
Reviewed-by: Rob Herring
---
.../devicetree/bindings/mtd/qcom,nandc.yaml | 196 ++
.../devicetree/bindings/mtd/qcom_nandc.txt| 142 -
2 files changed, 196 insertions(+), 142 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
delete mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt
diff --git a/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
new file mode 100644
index ..84ad7ff30121
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/qcom,nandc.yaml
@@ -0,0 +1,196 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mtd/qcom,nandc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm NAND controller
+
+maintainers:
+ - Manivannan Sadhasivam
+
+properties:
+ compatible:
+enum:
+ - qcom,ipq806x-nand
+ - qcom,ipq4019-nand
+ - qcom,ipq6018-nand
+ - qcom,ipq8074-nand
+ - qcom,sdx55-nand
+
+ reg:
+maxItems: 1
+
+ clocks:
+items:
+ - description: Core Clock
+ - description: Always ON Clock
+
+ clock-names:
+items:
+ - const: core
+ - const: aon
+
+ "#address-cells": true
+ "#size-cells": true
+
+patternProperties:
+ "^nand@[a-f0-9]$":
+type: object
+properties:
+ nand-bus-width:
+const: 8
+
+ nand-ecc-strength:
+enum: [1, 4, 8]
+
+ nand-ecc-step-size:
+enum:
+ - 512
+
+allOf:
+ - $ref: "nand-controller.yaml#"
+
+ - if:
+ properties:
+compatible:
+ contains:
+const: qcom,ipq806x-nand
+then:
+ properties:
+dmas:
+ items:
+- description: rxtx DMA channel
+
+dma-names:
+ items:
+- const: rxtx
+
+qcom,cmd-crci:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+Must contain the ADM command type CRCI block instance number
+specified for the NAND controller on the given platform
+
+qcom,data-crci:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+Must contain the ADM data type CRCI block instance number
+specified for the NAND controller on the given platform
+
+ - if:
+ properties:
+compatible:
+ contains:
+enum:
+ - qcom,ipq4019-nand
+ - qcom,ipq6018-nand
+ - qcom,ipq8074-nand
+ - qcom,sdx55-nand
+
+then:
+ properties:
+dmas:
+ items:
+- description: tx DMA channel
+- description: rx DMA channel
+- description: cmd DMA channel
+
+dma-names:
+ items:
+- const: tx
+- const: rx
+- const: cmd
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+nand-controller@1ac0 {
+ compatible = "qcom,ipq806x-nand";
+ reg = <0x1ac0 0x800>;
+
+ clocks = < EBI2_CLK>,
+ < EBI2_AON_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = <_dma 3>;
+ dma-names = "rxtx";
+ qcom,cmd-crci = <15>;
+ qcom,data-crci = <3>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+reg = <0>;
+
+nand-ecc-strength = <4>;
+nand-bus-width = <8>;
+
+partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+label = "boot-nand";
+reg = <0 0x58a>;
+ };
+
+ partition@58a {
+label = "fs-nand";
+reg = <0x58a 0x400>;
+ };
+};
+ };
+};
+
+#include
+nand-controller@79b {
+ compatible = "qcom,ipq4019-nand";
+ reg = <0x79b 0x1000>;
+
+ clocks = < GCC_QPIC_CLK>,
+ < GCC_QPIC_AHB_CLK>;
+ clock-names = "core", "aon";
+
+ dmas = < 0>,
+ < 1>,
+ < 2>;
+ dma-names = "tx", "rx", "cmd";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ nand@0 {
+reg = <0>;
+nand-ecc-strength = <4>;
+nand-bus-width = <8>;
+
+partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+label = "boot-nand";
+reg = <0 0x58a>;
+ };
+
+ partition@58a {
+label = "fs-nand";
+reg = <0x58a 0x400>;
+ };
+};
+ };
+};
+
+...
diff --git a/Documentation/devicetree/bindings/mtd/qcom_nandc.txt
[PATCH v8 0/3] Add support for secure regions in NAND
On a typical end product, a vendor may choose to secure some regions in the NAND memory which are supposed to stay intact between FW upgrades. The access to those regions will be blocked by a secure element like Trustzone. So the normal world software like Linux kernel should not touch these regions (including reading). So this series adds a property for declaring such secure regions in DT so that the driver can skip touching them. While at it, the Qcom NANDc DT binding is also converted to YAML format. Thanks, Mani Changes in v8: * Reworked the secure region check logic based on input from Boris * Removed the check where unnecessary in rawnand core. Changes in v7: * Made "size" u64 and fixed a warning reported by Kernel test bot Changes in v6: * Made use of "size" of the regions for comparision * Used "secure" instead of "sec" * Fixed the sizeof parameter in of_get_nand_secure_regions() Changes in v5: * Switched to "uint64-matrix" as suggested by Rob * Moved the whole logic from qcom driver to nand core as suggested by Boris Changes in v4: * Used "uint32-matrix" instead of "uint32-array" as per Rob's review. * Collected Rob's review tag for binding conversion patch Changes in v3: * Removed the nand prefix from DT property and moved the property parsing logic before nand_scan() in driver. Changes in v2: * Moved the secure-regions property to generic NAND binding as a NAND chip property and renamed it as "nand-secure-regions". Manivannan Sadhasivam (3): dt-bindings: mtd: Convert Qcom NANDc binding to YAML dt-bindings: mtd: Add a property to declare secure regions in NAND chips mtd: rawnand: Add support for secure regions in NAND memory .../bindings/mtd/nand-controller.yaml | 7 + .../devicetree/bindings/mtd/qcom,nandc.yaml | 196 ++ .../devicetree/bindings/mtd/qcom_nandc.txt| 142 - drivers/mtd/nand/raw/nand_base.c | 105 ++ include/linux/mtd/rawnand.h | 14 ++ 5 files changed, 322 insertions(+), 142 deletions(-) create mode 100644 Documentation/devicetree/bindings/mtd/qcom,nandc.yaml delete mode 100644 Documentation/devicetree/bindings/mtd/qcom_nandc.txt -- 2.25.1
[PATCH v8 2/3] dt-bindings: mtd: Add a property to declare secure regions in NAND chips
On a typical end product, a vendor may choose to secure some regions in the NAND memory which are supposed to stay intact between FW upgrades. The access to those regions will be blocked by a secure element like Trustzone. So the normal world software like Linux kernel should not touch these regions (including reading). So let's add a property for declaring such secure regions so that the drivers can skip touching them. Signed-off-by: Manivannan Sadhasivam --- Documentation/devicetree/bindings/mtd/nand-controller.yaml | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index d0e422f4b3e0..678b39952502 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -143,6 +143,13 @@ patternProperties: Ready/Busy pins. Active state refers to the NAND ready state and should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. + secure-regions: +$ref: /schemas/types.yaml#/definitions/uint64-matrix +description: + Regions in the NAND chip which are protected using a secure element + like Trustzone. This property contains the start address and size of + the secure regions present. + required: - reg -- 2.25.1
Re: [PATCH] ftrace: shut up -Wcast-function-type warning for ftrace_ops_no_ops
On Mon, Mar 22, 2021 at 10:49:58PM +0100, Arnd Bergmann wrote: > From: Arnd Bergmann > > With 'make W=1', gcc warns about casts between incompatible function > types: > > kernel/trace/ftrace.c:128:31: error: cast between incompatible function types > from 'void (*)(long unsigned int, long unsigned int)' to 'void (*)(long > unsigned int, long unsigned int, struct ftrace_ops *, struct ftrace_regs > *)' [-Werror=cast-function-type] > 128 | #define ftrace_ops_list_func ((ftrace_func_t)ftrace_ops_no_ops) > | ^ > > As the commet here explains, this one was intentional, so shut up the > warning harder by using a double cast. > > Signed-off-by: Arnd Bergmann > --- > kernel/trace/ftrace.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c > index 4d8e35575549..d8fc87a17421 100644 > --- a/kernel/trace/ftrace.c > +++ b/kernel/trace/ftrace.c > @@ -125,7 +125,7 @@ static void ftrace_ops_list_func(unsigned long ip, > unsigned long parent_ip, > #else > /* See comment below, where ftrace_ops_list_func is defined */ > static void ftrace_ops_no_ops(unsigned long ip, unsigned long parent_ip); > -#define ftrace_ops_list_func ((ftrace_func_t)ftrace_ops_no_ops) > +#define ftrace_ops_list_func ((ftrace_func_t)(void *)ftrace_ops_no_ops) So now we're making perfectly fine code worse, because GCC is stupid? Please just kill the warning, like we do with so many other warnings. It's broken!
arch/mips/kernel/setup.c:47:39: error: redefinition of '__appended_dtb' with a different type: 'const char vs 'char
Hi Thomas,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 84196390620ac0e5070ae36af84c137c6216a7dc
commit: b83ba0b9df56f8404ccc6ebcc7050fb8294f0f20 MIPS: of: Introduce helper
function to get DTB
date: 7 weeks ago
config: mips-randconfig-r022-20210322 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
14696baaf4c43fe53f738bc292bbe169eed93d5d)
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
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b83ba0b9df56f8404ccc6ebcc7050fb8294f0f20
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout b83ba0b9df56f8404ccc6ebcc7050fb8294f0f20
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> arch/mips/kernel/setup.c:47:39: error: redefinition of '__appended_dtb' with
>> a different type: 'const char [1048576]' vs 'char []'
const char __section(".appended_dtb") __appended_dtb[0x10];
^
arch/mips/include/asm/bootinfo.h:118:13: note: previous declaration is here
extern char __appended_dtb[];
^
1 error generated.
vim +47 arch/mips/kernel/setup.c
^1da177e4c3f41 Linus Torvalds 2005-04-16 45
87db537da4cd1b Aaro Koskinen 2015-09-11 46 #ifdef
CONFIG_MIPS_ELF_APPENDED_DTB
33def8498fdde1 Joe Perches2020-10-21 @47 const char
__section(".appended_dtb") __appended_dtb[0x10];
87db537da4cd1b Aaro Koskinen 2015-09-11 48 #endif /*
CONFIG_MIPS_ELF_APPENDED_DTB */
87db537da4cd1b Aaro Koskinen 2015-09-11 49
:: The code at line 47 was first introduced by commit
:: 33def8498fdde180023444b08e12b72a9efed41d treewide: Convert macro and
uses of __section(foo) to __section("foo")
:: TO: Joe Perches
:: CC: Linus Torvalds
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] kernel/signal: Modify the comment of function check_kill_permission
Maybe it's easier for us to understand the function of check_kill_permission. Signed-off-by: zhouchuangao --- kernel/signal.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/signal.c b/kernel/signal.c index f2a1b89..2fbf68a 100644 --- a/kernel/signal.c +++ b/kernel/signal.c @@ -823,8 +823,10 @@ static bool kill_ok_by_cred(struct task_struct *t) } /* - * Bad permissions for sending the signal - * - the caller must hold the RCU read lock + * Check if the signal has permission to kill the process. + * - The caller must hold the RCU read lock; + * - Return 0 means permission is allowed, otherwise returns the + * corresponding error number. */ static int check_kill_permission(int sig, struct kernel_siginfo *info, struct task_struct *t) -- 2.7.4
Re: [PATCH net-next] iwlwifi: fix old-style-declaration warning
On Mon, 2021-03-22 at 22:51 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The correct order is 'static const', not 'const static', as seen from
> make W=1:
>
> drivers/net/wireless/intel/iwlwifi/mvm/rfi.c:14:1: error: 'static' is not at
> beginning of declaration [-Werror=old-style-declaration]
>
> Fixes: 21254908cbe9 ("iwlwifi: mvm: add RFI-M support")
> Signed-off-by: Arnd Bergmann
> ---
Thanks, Arnd! But I just applied the patch Wei Yongjun submitted, so
we'll go with that one.
--
Cheers,
Luca.
RE: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
Hi Andy Shevchenko,
> -Original Message-
> From: Andy Shevchenko
> Sent: Monday, March 22, 2021 10:47 PM
> To: Sai Krishna Potthuri
> Cc: Linus Walleij ; Rob Herring
> ; Michal Simek ; Greg Kroah-
> Hartman ; linux-arm Mailing List ker...@lists.infradead.org>; Linux Kernel Mailing List ker...@vger.kernel.org>; devicetree ; open
> list:GPIO SUBSYSTEM ; git ;
> saikrishna12...@gmail.com
> Subject: Re: [PATCH v4 3/3] pinctrl: Add Xilinx ZynqMP pinctrl driver support
>
> On Mon, Mar 22, 2021 at 5:25 PM Sai Krishna Potthuri
> wrote:
> > > From: Andy Shevchenko
> > > Sent: Friday, March 19, 2021 3:53 PM On Thu, Mar 18, 2021 at 4:42 PM
> > > Sai Krishna Potthuri
> > > wrote:
> > > > > From: Andy Shevchenko
> > > > > Sent: Wednesday, March 17, 2021 6:26 PM On Wed, Mar 17, 2021 at
> > > > > 10:27 AM Sai Krishna Potthuri
> > > > > wrote:
>
> ...
>
> > > > #include
> > >
> > > Looking into other drivers with similar includes, shouldn't it go
> > > first in the file before any other linux/* asm/* etc?
> > I see some drivers are including this header before linux/* and some
> > are using after linux/*.
>
> The rule of thumb is that: more generic headers are going first.
>
> I consider dt/* ones are more generic than linux/* ones because they are
> covering more than just the Linux kernel.
Ok, I will reorder accordingly.
>
> ...
>
> > > > > I'm lost here. What is IO standard exactly? Why it can't be in
> > > > > generic headers?
> > > > It represents LVCMOS 3.3 volts/ LVCMOS 1.8 volts.
> > > > Since this is specific to Xilinx ZynqMP platform, considered to be
> > > > added in the driver file.
> > >
> > > So, why can't we create a couple of bits to represent this voltages
> > > in the generic header and gain usability for others as well?
> > I see some drivers are maintaining the configuration list in the
> > driver file, if the configuration is specific to the driver.
>
> Yes, my point is that this case doesn't sound too specific to the driver. Many
> pin control buffers (in hardware way of speaking) have properties to be
> different voltage tolerant / produce.
Ok, you want me to proceed with this change or shall we wait for
Linus to comment?
>
> > We can move this to generic header if it is used by others as well.
> > Ok, will wait for Linus to comment.
> > >
> > > Linus?
>
> ...
>
> > > > > > + ret = zynqmp_pm_pinctrl_request(pin);
> > > > > > + if (ret) {
> > > > > > + dev_err(pctldev->dev, "request failed for pin
> > > > > > + %u\n", pin);
> > > > >
> > > > > > + return -EIO;
> > > > >
> > > > > Why shadowing error code?
> > >
> > > So, any comments on the initial Q?
> > Xilinx low level secure firmware error codes are different from Linux error
> codes.
> > Secure firmware maintains list of error codes (positive values other than
> zero).
> > Hence we return -EIO, if the return value from firmware is non-zero.
>
> Why the zynqmp_pm_pinctrl_request() can't return codes in Linux error
> code space?
I cross checked with the Xilinx firmware team, firmware driver is now returning
Linux error codes in the latest kernel but while developing the driver it was a
different approach. I will update the driver to simply return the values from
firmware calls.
>
> > > >> Since it's the only possible error, why is it not
> > > > > reflected in the kernel doc?
> > > > I will update the kernel doc with the error value for such cases.
> > > > >
> > > > > > + }
>
> --
> With Best Regards,
> Andy Shevchenko
Re: [PATCH v7 3/3] arm64: dts: ti: k3-j7200: Add support for higher speed modes and update delay select values for MMCSD subsystems
Hi Kishon,
On 23/03/21 11:59 am, Kishon Vijay Abraham I wrote:
> Hi Aswath,
>
> On 23/03/21 10:54 am, Aswath Govindraju wrote:
>> Hi Nishanth,
>>
>> On 22/03/21 9:05 pm, Nishanth Menon wrote:
>>> On 18:42-20210322, Aswath Govindraju wrote:
The following speed modes are now supported in J7200 SoC,
- HS200 and HS400 modes at 1.8 V card voltage, in MMCSD0 subsystem [1].
- UHS-I speed modes in MMCSD1 subsystem [1].
Add support for UHS-I modes by adding voltage regulator device tree nodes
and corresponding pinmux details, to power cycle and voltage switch cards.
Set respective tags in sdhci0 and remove no-1-8-v tag from sdhci1
device tree nodes.
Also update the delay values for various speed modes supported, based on
the revised january 2021 J7200 datasheet[2].
[1] - section 12.3.6.1.1 MMCSD Features, in
https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf,
(SPRUIU1A – JULY 2020 – REVISED JANUARY 2021)
[2] - https://www.ti.com/lit/ds/symlink/dra821u.pdf,
(SPRSP57B – APRIL 2020 – REVISED JANUARY 2021)
Signed-off-by: Aswath Govindraju
---
.../dts/ti/k3-j7200-common-proc-board.dts | 42 +++
arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 14 ++-
2 files changed, 54 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
index b493f939b09a..de8c06bdc825 100644
--- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts
@@ -16,6 +16,29 @@
stdout-path = "serial2:115200n8";
bootargs = "console=ttyS2,115200n8
earlycon=ns16550a,mmio32,0x0280";
};
+
+ vdd_mmc1: fixedregulator-sd {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_mmc1";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ enable-active-high;
+ gpios = < 2 GPIO_ACTIVE_HIGH>;
>>>
>>> is that gpio ?
>>
>> Yes, that is correct. I'll correct it in the respin
>>
>>> I'd encourage to use vin-supply as well.
>>
>> Will add this in respin.
>>
>>>
+ };
+
+ vdd_sd_dv: gpio-regulator-vdd-sd-dv {
>>> What does this drive? TLV71033 ?
>>
>> Yes, this node models the TLV71033 voltage regulator that switches the
>> MMC IO signal voltage level between 3.3V and 1.8V.
>
> Nope. Unlike J721e SOM which uses TLV71033 for switching voltage, J7200
> SOM directly uses GPIO input to PMIC to control the output voltage. So
> this should model the gpio input to PMIC.
>
This was the case with older SoMs and on newer ones load switches are
being used[1].
[1] - https://www.ti.com/lit/zip/sprr424, PROC105E6(001)_SCH.pdf, page 24
Thanks,
Aswath
[tip: locking/core] locking/mutex: Fix non debug version of mutex_lock_io_nested()
The following commit has been merged into the locking/core branch of tip:
Commit-ID: ebdbd41bf2536ac57bf315ce9690245e08c5e506
Gitweb:
https://git.kernel.org/tip/ebdbd41bf2536ac57bf315ce9690245e08c5e506
Author:Thomas Gleixner
AuthorDate:Mon, 22 Mar 2021 09:46:13 +01:00
Committer: Peter Zijlstra
CommitterDate: Mon, 22 Mar 2021 21:43:57 +01:00
locking/mutex: Fix non debug version of mutex_lock_io_nested()
If CONFIG_DEBUG_LOCK_ALLOC=n then mutex_lock_io_nested() maps to
mutex_lock() which is clearly wrong because mutex_lock() lacks the
io_schedule_prepare()/finish() invocations.
Map it to mutex_lock_io().
Fixes: f21860bac05b ("locking/mutex, sched/wait: Fix the mutex_lock_io_nested()
define")
Signed-off-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/878s6fshii@nanos.tec.linutronix.de
---
include/linux/mutex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 0cd631a..515cff7 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -185,7 +185,7 @@ extern void mutex_lock_io(struct mutex *lock);
# define mutex_lock_interruptible_nested(lock, subclass)
mutex_lock_interruptible(lock)
# define mutex_lock_killable_nested(lock, subclass) mutex_lock_killable(lock)
# define mutex_lock_nest_lock(lock, nest_lock) mutex_lock(lock)
-# define mutex_lock_io_nested(lock, subclass) mutex_lock(lock)
+# define mutex_lock_io_nested(lock, subclass) mutex_lock_io(lock)
#endif
/*
[PATCH] USB: gadget: legacy: remove left-over __ref annotations
These were added in commit 780cc0f370 ("usb: gadget: add '__ref' for
rndis_config_register() and cdc_config_register()") to silence
modpost, but they didn't fix the real problem - that was fixed later
by removing wrong __init annotations in commit c94e289f195e ("usb:
gadget: remove incorrect __init/__exit annotations").
It really never makes sense for a function to be marked __ref unless
it (1) has some conditional that chooses whether to call an __init
function (or access __initdata) or not and (2) has a comment
explaining why the __ref is there and why it is safe.
Signed-off-by: Rasmus Villemoes
---
drivers/usb/gadget/legacy/multi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/gadget/legacy/multi.c
b/drivers/usb/gadget/legacy/multi.c
index ec9749845660..f6d0782e6fc3 100644
--- a/drivers/usb/gadget/legacy/multi.c
+++ b/drivers/usb/gadget/legacy/multi.c
@@ -182,7 +182,7 @@ static int rndis_do_config(struct usb_configuration *c)
return ret;
}
-static __ref int rndis_config_register(struct usb_composite_dev *cdev)
+static int rndis_config_register(struct usb_composite_dev *cdev)
{
static struct usb_configuration config = {
.bConfigurationValue= MULTI_RNDIS_CONFIG_NUM,
@@ -197,7 +197,7 @@ static __ref int rndis_config_register(struct
usb_composite_dev *cdev)
#else
-static __ref int rndis_config_register(struct usb_composite_dev *cdev)
+static int rndis_config_register(struct usb_composite_dev *cdev)
{
return 0;
}
@@ -265,7 +265,7 @@ static int cdc_do_config(struct usb_configuration *c)
return ret;
}
-static __ref int cdc_config_register(struct usb_composite_dev *cdev)
+static int cdc_config_register(struct usb_composite_dev *cdev)
{
static struct usb_configuration config = {
.bConfigurationValue= MULTI_CDC_CONFIG_NUM,
@@ -280,7 +280,7 @@ static __ref int cdc_config_register(struct
usb_composite_dev *cdev)
#else
-static __ref int cdc_config_register(struct usb_composite_dev *cdev)
+static int cdc_config_register(struct usb_composite_dev *cdev)
{
return 0;
}
@@ -291,7 +291,7 @@ static __ref int cdc_config_register(struct
usb_composite_dev *cdev)
/** Gadget Bind **/
-static int __ref multi_bind(struct usb_composite_dev *cdev)
+static int multi_bind(struct usb_composite_dev *cdev)
{
struct usb_gadget *gadget = cdev->gadget;
#ifdef CONFIG_USB_G_MULTI_CDC
--
2.29.2
[PATCH v2 3/3] soc: rockchip: power-domain: add rk3568 powerdomains
Add power-domains found on rk3568 socs.
Signed-off-by: Elaine Zhang
---
drivers/soc/rockchip/pm_domains.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/soc/rockchip/pm_domains.c
b/drivers/soc/rockchip/pm_domains.c
index 54eb6cfc5d5b..a2c19c845cf2 100644
--- a/drivers/soc/rockchip/pm_domains.c
+++ b/drivers/soc/rockchip/pm_domains.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
struct rockchip_domain_info {
int pwr_mask;
@@ -131,6 +132,9 @@ struct rockchip_pmu {
#define DOMAIN_RK3399(pwr, status, req, wakeup)\
DOMAIN(pwr, status, req, req, req, wakeup)
+#define DOMAIN_RK3568(pwr, req, wakeup)\
+ DOMAIN_M(pwr, pwr, req, req, req, wakeup)
+
static bool rockchip_pmu_domain_is_idle(struct rockchip_pm_domain *pd)
{
struct rockchip_pmu *pmu = pd->pmu;
@@ -841,6 +845,18 @@ static const struct rockchip_domain_info
rk3399_pm_domains[] = {
[RK3399_PD_SDIOAUDIO] = DOMAIN_RK3399(BIT(31), BIT(31), BIT(29),
true),
};
+static const struct rockchip_domain_info rk3568_pm_domains[] = {
+ [RK3568_PD_NPU] = DOMAIN_RK3568(BIT(1), BIT(2), false),
+ [RK3568_PD_GPU] = DOMAIN_RK3568(BIT(0), BIT(1), false),
+ [RK3568_PD_VI] = DOMAIN_RK3568(BIT(6), BIT(3), false),
+ [RK3568_PD_VO] = DOMAIN_RK3568(BIT(7), BIT(4), false),
+ [RK3568_PD_RGA] = DOMAIN_RK3568(BIT(5), BIT(5), false),
+ [RK3568_PD_VPU] = DOMAIN_RK3568(BIT(2), BIT(6), false),
+ [RK3568_PD_RKVDEC] = DOMAIN_RK3568(BIT(4), BIT(8), false),
+ [RK3568_PD_RKVENC] = DOMAIN_RK3568(BIT(3), BIT(7), false),
+ [RK3568_PD_PIPE]= DOMAIN_RK3568(BIT(8), BIT(11), false),
+};
+
static const struct rockchip_pmu_info px30_pmu = {
.pwr_offset = 0x18,
.status_offset = 0x20,
@@ -976,6 +992,17 @@ static const struct rockchip_pmu_info rk3399_pmu = {
.domain_info = rk3399_pm_domains,
};
+static const struct rockchip_pmu_info rk3568_pmu = {
+ .pwr_offset = 0xa0,
+ .status_offset = 0x98,
+ .req_offset = 0x50,
+ .idle_offset = 0x68,
+ .ack_offset = 0x60,
+
+ .num_domains = ARRAY_SIZE(rk3568_pm_domains),
+ .domain_info = rk3568_pm_domains,
+};
+
static const struct of_device_id rockchip_pm_domain_dt_match[] = {
{
.compatible = "rockchip,px30-power-controller",
@@ -1021,6 +1048,10 @@ static const struct of_device_id
rockchip_pm_domain_dt_match[] = {
.compatible = "rockchip,rk3399-power-controller",
.data = (void *)_pmu,
},
+ {
+ .compatible = "rockchip,rk3568-power-controller",
+ .data = (void *)_pmu,
+ },
{ /* sentinel */ },
};
--
2.17.1
[PATCH v2 1/3] dt-bindings: add power-domain header for RK3568 SoCs
According to a description from TRM, add all the power domains Signed-off-by: Elaine Zhang --- include/dt-bindings/power/rk3568-power.h | 32 1 file changed, 32 insertions(+) create mode 100644 include/dt-bindings/power/rk3568-power.h diff --git a/include/dt-bindings/power/rk3568-power.h b/include/dt-bindings/power/rk3568-power.h new file mode 100644 index ..6cc1af1a9d26 --- /dev/null +++ b/include/dt-bindings/power/rk3568-power.h @@ -0,0 +1,32 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __DT_BINDINGS_POWER_RK3568_POWER_H__ +#define __DT_BINDINGS_POWER_RK3568_POWER_H__ + +/* VD_CORE */ +#define RK3568_PD_CPU_00 +#define RK3568_PD_CPU_11 +#define RK3568_PD_CPU_22 +#define RK3568_PD_CPU_33 +#define RK3568_PD_CORE_ALIVE 4 + +/* VD_PMU */ +#define RK3568_PD_PMU 5 + +/* VD_NPU */ +#define RK3568_PD_NPU 6 + +/* VD_GPU */ +#define RK3568_PD_GPU 7 + +/* VD_LOGIC */ +#define RK3568_PD_VI 8 +#define RK3568_PD_VO 9 +#define RK3568_PD_RGA 10 +#define RK3568_PD_VPU 11 +#define RK3568_PD_CENTER 12 +#define RK3568_PD_RKVDEC 13 +#define RK3568_PD_RKVENC 14 +#define RK3568_PD_PIPE 15 +#define RK3568_PD_LOGIC_ALIVE 16 + +#endif -- 2.17.1
[PATCH v2 0/3] soc: rockchip: power-domain: add rk3568 powerdomains
Support power domain function for RK3568 Soc. Change in V2: [PATCH v2 1/3]: No change. [PATCH v2 2/3]: Fix up yaml code styles. [PATCH v2 3/3]: No change. Elaine Zhang (3): dt-bindings: add power-domain header for RK3568 SoCs dt-bindings: Convert the rockchip power_domain to YAML and extend soc: rockchip: power-domain: add rk3568 powerdomains .../bindings/soc/rockchip/power_domain.txt| 136 - .../rockchip/rockchip,power-controller.yaml | 259 ++ drivers/soc/rockchip/pm_domains.c | 31 +++ include/dt-bindings/power/rk3568-power.h | 32 +++ 4 files changed, 322 insertions(+), 136 deletions(-) delete mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt create mode 100644 Documentation/devicetree/bindings/soc/rockchip/rockchip,power-controller.yaml create mode 100644 include/dt-bindings/power/rk3568-power.h -- 2.17.1
[PATCH v2 2/3] dt-bindings: Convert the rockchip power_domain to YAML and extend
This converts the rockchip power domain family bindings to YAML schema,
and add binding documentation for the power domains found on Rockchip
RK3568 SoCs.
Signed-off-by: Elaine Zhang
---
.../bindings/soc/rockchip/power_domain.txt| 136 -
.../rockchip/rockchip,power-controller.yaml | 259 ++
2 files changed, 259 insertions(+), 136 deletions(-)
delete mode 100644
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
create mode 100644
Documentation/devicetree/bindings/soc/rockchip/rockchip,power-controller.yaml
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
deleted file mode 100644
index 8304eceb62e4..
--- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
+++ /dev/null
@@ -1,136 +0,0 @@
-* Rockchip Power Domains
-
-Rockchip processors include support for multiple power domains which can be
-powered up/down by software based on different application scenes to save
power.
-
-Required properties for power domain controller:
-- compatible: Should be one of the following.
- "rockchip,px30-power-controller" - for PX30 SoCs.
- "rockchip,rk3036-power-controller" - for RK3036 SoCs.
- "rockchip,rk3066-power-controller" - for RK3066 SoCs.
- "rockchip,rk3128-power-controller" - for RK3128 SoCs.
- "rockchip,rk3188-power-controller" - for RK3188 SoCs.
- "rockchip,rk3228-power-controller" - for RK3228 SoCs.
- "rockchip,rk3288-power-controller" - for RK3288 SoCs.
- "rockchip,rk3328-power-controller" - for RK3328 SoCs.
- "rockchip,rk3366-power-controller" - for RK3366 SoCs.
- "rockchip,rk3368-power-controller" - for RK3368 SoCs.
- "rockchip,rk3399-power-controller" - for RK3399 SoCs.
-- #power-domain-cells: Number of cells in a power-domain specifier.
- Should be 1 for multiple PM domains.
-- #address-cells: Should be 1.
-- #size-cells: Should be 0.
-
-Required properties for power domain sub nodes:
-- reg: index of the power domain, should use macros in:
- "include/dt-bindings/power/px30-power.h" - for PX30 type power domain.
- "include/dt-bindings/power/rk3036-power.h" - for RK3036 type power
domain.
- "include/dt-bindings/power/rk3066-power.h" - for RK3066 type power
domain.
- "include/dt-bindings/power/rk3128-power.h" - for RK3128 type power
domain.
- "include/dt-bindings/power/rk3188-power.h" - for RK3188 type power
domain.
- "include/dt-bindings/power/rk3228-power.h" - for RK3228 type power
domain.
- "include/dt-bindings/power/rk3288-power.h" - for RK3288 type power
domain.
- "include/dt-bindings/power/rk3328-power.h" - for RK3328 type power
domain.
- "include/dt-bindings/power/rk3366-power.h" - for RK3366 type power
domain.
- "include/dt-bindings/power/rk3368-power.h" - for RK3368 type power
domain.
- "include/dt-bindings/power/rk3399-power.h" - for RK3399 type power
domain.
-- clocks (optional): phandles to clocks which need to be enabled while power
domain
- switches state.
-- pm_qos (optional): phandles to qos blocks which need to be saved and restored
- while power domain switches state.
-
-Qos Example:
-
- qos_gpu: qos_gpu@ffaf {
- compatible ="syscon";
- reg = <0x0 0xffaf 0x0 0x20>;
- };
-
-Example:
-
- power: power-controller {
- compatible = "rockchip,rk3288-power-controller";
- #power-domain-cells = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- pd_gpu {
- reg = ;
- clocks = < ACLK_GPU>;
- pm_qos = <_gpu>;
- };
- };
-
-power: power-controller {
-compatible = "rockchip,rk3368-power-controller";
-#power-domain-cells = <1>;
-#address-cells = <1>;
-#size-cells = <0>;
-
-pd_gpu_1 {
-reg = ;
-clocks = < ACLK_GPU_CFG>;
-};
-};
-
-Example 2:
- power: power-controller {
- compatible = "rockchip,rk3399-power-controller";
- #power-domain-cells = <1>;
- #address-cells = <1>;
- #size-cells = <0>;
-
- pd_vio {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = ;
-
- pd_vo {
- #address-cells = <1>;
- #size-cells = <0>;
- reg = ;
-
- pd_vopb {
- reg = ;
-
Re: [PATCH v10] i2c: virtio: add a virtio i2c frontend driver
On 23-03-21, 16:33, Jie Deng wrote:
> On 2021/3/23 15:27, Viresh Kumar wrote:
>
> > On 23-03-21, 22:19, Jie Deng wrote:
> > > +static int __maybe_unused virtio_i2c_freeze(struct virtio_device *vdev)
> > > +{
> > > + virtio_i2c_del_vqs(vdev);
> > > + return 0;
> > > +}
> > > +
> > > +static int __maybe_unused virtio_i2c_restore(struct virtio_device *vdev)
> > > +{
> > > + return virtio_i2c_setup_vqs(vdev->priv);
> > > +}
> > Sorry for not looking at this earlier, but shouldn't we enclose the above
> > two
> > within #ifdef CONFIG_PM_SLEEP instead and drop the __maybe_unused ?
>
>
> I remembered I was suggested to use "__maybe_unused" instead of "#ifdef".
>
> You may check this https://lore.kernel.org/patchwork/patch/732981/
>
> The reason may be something like that.
Ahh, thanks for the link Jie. Okay you can leave it as is.
--
viresh
Re: [PATCH v2 2/2] arm64: dts: qcom: sm8350: Add thermal zones and throttling support
Hey Konrad,
Thanks for the review!
On Mon, 22 Mar 2021 at 18:27, Konrad Dybcio
wrote:
>
> Hi!
>
>
> > + tsens0: thermal-sensor@c222000 {
> > + compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
> > + reg = <0 0x0C263000 0 0x1ff>, /* TM */
> > + <0 0x0C222000 0 0x8>; /* SROT */
>
> Please use lowercase hex
Ack
>
>
> > + tsens1: thermal-sensor@c223000 {
> > + compatible = "qcom,sm8350-tsens", "qcom,tsens-v2";
> > + reg = <0 0x0C265000 0 0x1ff>, /* TM */
> > + <0 0x0c223000 0 0x8>; /* SROT */
>
> Ditto
Ack
>
>
> > + trips {
> > + cpu0_alert0: trip-point0 {
> > + temperature = <9>;
> > + hysteresis = <2000>;
> > + type = "passive";
> > + };
> > +
> > + cpu0_alert1: trip-point1 {
> > + temperature = <95000>;
> > + hysteresis = <2000>;
> > + type = "passive";
>
> Shouldn't this be "hot"? Possibly ditto for all cpu*alert1-labeled nodes.
I based this patch on the upstream DTS for sm8250 & sdm845, and this
is what they use. However, if you think it is incorrect I'm happy to
do a little digging.
>
>
> > + };
> > +
> > + cpu0_crit: cpu_crit {
> > + temperature = <11>;
> > + hysteresis = <1000>;
> > + type = "critical";
> > + };
> > + };
>
> These values seem, err.. scorching hot.. Are they alright?
I agree :) This is what the vendor ships in their downstream DTS.
>
>
>
> > + // TODO: What is the NSP subsystem?
> Please use C-style comments (/* foo */)
Removing comment.
ERROR: modpost: "ioremap" undefined!
Hi Nick, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 84196390620ac0e5070ae36af84c137c6216a7dc commit: 1e1b6d63d6340764e00356873e5794225a2a03ea lib/string.c: implement stpcpy date: 6 months ago config: s390-randconfig-r031-20210322 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 14696baaf4c43fe53f738bc292bbe169eed93d5d) 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 # install s390 cross compiling tool for clang build # apt-get install binutils-s390x-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e1b6d63d6340764e00356873e5794225a2a03ea git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 1e1b6d63d6340764e00356873e5794225a2a03ea # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "ioremap" [drivers/pcmcia/pcmcia.ko] undefined! >> ERROR: modpost: "iounmap" [drivers/pcmcia/pcmcia.ko] undefined! ERROR: modpost: "devm_ioremap_resource" [drivers/dma/idma64.ko] undefined! ERROR: modpost: "devm_ioremap" [drivers/dma/altera-msgdma.ko] undefined! ERROR: modpost: "devm_ioremap_resource" [drivers/dma/qcom/hdma.ko] undefined! >> ERROR: modpost: "devm_ioremap_resource" [drivers/dma/qcom/hdma_mgmt.ko] >> undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
Re: [PATCH] Bluetooth: check for zapped sk before connecting
Hi Marcel,
Thanks for your suggestion. I implemented it in v2, please take another look.
On Mon, 22 Mar 2021 at 23:53, Marcel Holtmann wrote:
>
> Hi Archie,
>
> > There is a possibility of receiving a zapped sock on
> > l2cap_sock_connect(). This could lead to interesting crashes, one
> > such case is tearing down an already tore l2cap_sock as is happened
> > with this call trace:
> >
> > __dump_stack lib/dump_stack.c:15 [inline]
> > dump_stack+0xc4/0x118 lib/dump_stack.c:56
> > register_lock_class kernel/locking/lockdep.c:792 [inline]
> > register_lock_class+0x239/0x6f6 kernel/locking/lockdep.c:742
> > __lock_acquire+0x209/0x1e27 kernel/locking/lockdep.c:3105
> > lock_acquire+0x29c/0x2fb kernel/locking/lockdep.c:3599
> > __raw_spin_lock_bh include/linux/spinlock_api_smp.h:137 [inline]
> > _raw_spin_lock_bh+0x38/0x47 kernel/locking/spinlock.c:175
> > spin_lock_bh include/linux/spinlock.h:307 [inline]
> > lock_sock_nested+0x44/0xfa net/core/sock.c:2518
> > l2cap_sock_teardown_cb+0x88/0x2fb net/bluetooth/l2cap_sock.c:1345
> > l2cap_chan_del+0xa3/0x383 net/bluetooth/l2cap_core.c:598
> > l2cap_chan_close+0x537/0x5dd net/bluetooth/l2cap_core.c:756
> > l2cap_chan_timeout+0x104/0x17e net/bluetooth/l2cap_core.c:429
> > process_one_work+0x7e3/0xcb0 kernel/workqueue.c:2064
> > worker_thread+0x5a5/0x773 kernel/workqueue.c:2196
> > kthread+0x291/0x2a6 kernel/kthread.c:211
> > ret_from_fork+0x4e/0x80 arch/x86/entry/entry_64.S:604
> >
> > Signed-off-by: Archie Pusaka
> > Reported-by: syzbot+abfc0f5e668d4099a...@syzkaller.appspotmail.com
> > Reviewed-by: Alain Michaud
> > Reviewed-by: Abhishek Pandit-Subedi
> > Reviewed-by: Guenter Roeck
> > ---
> >
> > net/bluetooth/l2cap_sock.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
> > index f1b1edd0b697..b86fd8cc4dc1 100644
> > --- a/net/bluetooth/l2cap_sock.c
> > +++ b/net/bluetooth/l2cap_sock.c
> > @@ -182,6 +182,13 @@ static int l2cap_sock_connect(struct socket *sock,
> > struct sockaddr *addr,
> >
> > BT_DBG("sk %p", sk);
> >
> > + lock_sock(sk);
> > + if (sock_flag(sk, SOCK_ZAPPED)) {
> > + release_sock(sk);
> > + return -EINVAL;
> > + }
> > + release_sock(sk);
> > +
>
> hmmm. I wonder if this would look better and easy to see that the locking is
> done correctly.
>
> lock_sock(sk);
> zapped = sock_flag(sk, SOCK_ZAPPED);
> release_sock(sk);
>
> if (zapped)
> return -EINVAL;
>
> Regards
>
> Marcel
>
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
On 23.03.2021 09:32:10, Oliver Hartkopp wrote: > I wonder if the compiler configurations (gcc -v) or the options used at > kernel build time are identical. I tested several compilers and with my .config never triggered a problem, but with Rong Chen it does. I'm trying to figure out which option it is, stay tuned. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: PGP signature
Re: [PATCH] drm/i915: A typo fix
On Tue, 23 Mar 2021, Bhaskar Chowdhury wrote: > s/nothign/nothing/ > > Signed-off-by: Bhaskar Chowdhury You've sent the same patch before? I've already pushed it. BR, Jani. > --- > drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > index f6ad257a260e..14d784a6fae5 100644 > --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c > @@ -4185,7 +4185,7 @@ static void icl_pll_disable(struct drm_i915_private > *dev_priv, > /* >* DVFS pre sequence would be here, but in our driver the cdclk code >* paths should already be setting the appropriate voltage, hence we do > - * nothign here. > + * nothing here. >*/ > > val = intel_de_read(dev_priv, enable_reg); > -- > 2.31.0 > -- Jani Nikula, Intel Open Source Graphics Center
[GIT PULL] Immutable branch between MFD and Power due for the v5.13 merge window
Enjoy!
The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-power-v5.13
for you to fetch changes up to ee0975c3089e1c3357ccc3ada7a94a95b61e708c:
mfd/power: ab8500: Push data to power supply code (2021-03-22 14:56:02 +)
Immutable branch between MFD and Power due for the v5.13 merge window
Linus Walleij (4):
power: ab8500: Require device tree
mfd/power: ab8500: Push data to power supply code
mfd/power: ab8500: Push algorithm to power supply code
mfd/power: ab8500: Push data to power supply code
drivers/mfd/ab8500-core.c | 17 +-
drivers/power/supply/Kconfig | 2 +-
.../abx500 => drivers/power/supply}/ab8500-bm.h| 297 +++--
.../power/supply/ab8500-chargalg.h | 6 +-
drivers/power/supply/ab8500_bmdata.c | 3 +-
drivers/power/supply/ab8500_btemp.c| 45 +---
drivers/power/supply/ab8500_charger.c | 27 +-
drivers/power/supply/ab8500_fg.c | 20 +-
drivers/power/supply/abx500_chargalg.c | 22 +-
drivers/power/supply/pm2301_charger.c | 4 +-
include/linux/mfd/abx500.h | 276 ---
11 files changed, 326 insertions(+), 393 deletions(-)
rename {include/linux/mfd/abx500 => drivers/power/supply}/ab8500-bm.h (58%)
rename include/linux/mfd/abx500/ux500_chargalg.h =>
drivers/power/supply/ab8500-chargalg.h (93%)
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 12/17] auxdisplay: ht16k33: Add helper variable dev
On 2021-03-22 15:48, Geert Uytterhoeven wrote:
This driver has many users of "client->dev". Add shorthands to
simplify
the code.
Signed-off-by: Geert Uytterhoeven
---
drivers/auxdisplay/ht16k33.c | 43 ++--
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/auxdisplay/ht16k33.c
b/drivers/auxdisplay/ht16k33.c
index 1b67f38109bddba8..37fca1d44c3e73e1 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -316,7 +316,8 @@ static void ht16k33_keypad_stop(struct input_dev
*dev)
static int ht16k33_keypad_probe(struct i2c_client *client,
struct ht16k33_keypad *keypad)
{
- struct device_node *node = client->dev.of_node;
+ struct device *dev = >dev;
+ struct device_node *node = dev->of_node;
u32 rows = HT16K33_MATRIX_KEYPAD_MAX_ROWS;
u32 cols = HT16K33_MATRIX_KEYPAD_MAX_COLS;
int err;
@@ -324,7 +325,7 @@ static int ht16k33_keypad_probe(struct i2c_client
*client,
keypad->client = client;
init_waitqueue_head(>wait);
- keypad->dev = devm_input_allocate_device(>dev);
+ keypad->dev = devm_input_allocate_device(dev);
if (!keypad->dev)
return -ENOMEM;
@@ -341,17 +342,17 @@ static int ht16k33_keypad_probe(struct i2c_client
*client,
err = of_property_read_u32(node, "debounce-delay-ms",
>debounce_ms);
if (err) {
- dev_err(>dev, "key debounce delay not specified\n");
+ dev_err(dev, "key debounce delay not specified\n");
return err;
}
- err = matrix_keypad_parse_of_params(>dev, , );
+ err = matrix_keypad_parse_of_params(dev, , );
if (err)
return err;
if (rows > HT16K33_MATRIX_KEYPAD_MAX_ROWS ||
cols > HT16K33_MATRIX_KEYPAD_MAX_COLS) {
- dev_err(>dev, "%u rows or %u cols out of range in DT\n",
- rows, cols);
+ dev_err(dev, "%u rows or %u cols out of range in DT\n", rows,
+ cols);
return -ERANGE;
}
@@ -362,17 +363,17 @@ static int ht16k33_keypad_probe(struct i2c_client
*client,
err = matrix_keypad_build_keymap(NULL, NULL, rows, cols, NULL,
keypad->dev);
if (err) {
- dev_err(>dev, "failed to build keymap\n");
+ dev_err(dev, "failed to build keymap\n");
return err;
}
- err = devm_request_threaded_irq(>dev, client->irq,
- NULL, ht16k33_keypad_irq_thread,
+ err = devm_request_threaded_irq(dev, client->irq, NULL,
+ ht16k33_keypad_irq_thread,
IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
DRIVER_NAME, keypad);
if (err) {
- dev_err(>dev, "irq request failed %d, error %d\n",
- client->irq, err);
+ dev_err(dev, "irq request failed %d, error %d\n", client->irq,
+ err);
return err;
}
@@ -389,14 +390,15 @@ static int ht16k33_probe(struct i2c_client
*client)
struct backlight_properties bl_props;
struct ht16k33_priv *priv;
struct ht16k33_fbdev *fbdev;
- struct device_node *node = client->dev.of_node;
+ struct device *dev = >dev;
+ struct device_node *node = dev->of_node;
if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C)) {
- dev_err(>dev, "i2c_check_functionality error\n");
+ dev_err(dev, "i2c_check_functionality error\n");
return -EIO;
}
- priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
if (!priv)
return -ENOMEM;
@@ -414,13 +416,13 @@ static int ht16k33_probe(struct i2c_client
*client)
if (!fbdev->buffer)
return -ENOMEM;
- fbdev->cache = devm_kmalloc(>dev, HT16K33_FB_SIZE,
GFP_KERNEL);
+ fbdev->cache = devm_kmalloc(dev, HT16K33_FB_SIZE, GFP_KERNEL);
if (!fbdev->cache) {
err = -ENOMEM;
goto err_fbdev_buffer;
}
- fbdev->info = framebuffer_alloc(0, >dev);
+ fbdev->info = framebuffer_alloc(0, dev);
if (!fbdev->info) {
err = -ENOMEM;
goto err_fbdev_buffer;
@@ -429,7 +431,7 @@ static int ht16k33_probe(struct i2c_client *client)
err = of_property_read_u32(node, "refresh-rate-hz",
>refresh_rate);
if (err) {
- dev_err(>dev, "refresh rate not specified\n");
+ dev_err(dev, "refresh rate not specified\n");
goto err_fbdev_info;
}
fb_bl_default_curve(fbdev->info, 0, MIN_BRIGHTNESS,
Re: [Ksummit-discuss] RFC: create mailing list "linux-issues" focussed on issues/bugs and regressions
On 22.03.21 22:56, Theodore Ts'o wrote: > On Mon, Mar 22, 2021 at 08:25:15PM +0100, Thorsten Leemhuis wrote: >> I agree to the last point and yeah, maybe regressions are the more >> important problem we should work on – at least from the perspective of >> kernel development. But from the users perspective (and >> reporting-issues.rst is written for that perspective) it feel a bit >> unsatisfying to not have a solution to query for existing report, >> regressions or not. H... > First of all, thanks for working on reporting-issues.rst. Thx, very glad to hear that. I didn't get much feedback on it, which made me wonder if anybody besides docs folks actually looked at it... > If we can > actually get users to *read* it, I think it's going to save kernel > developers a huge amount of time and frustration. And users hopefully as well. But yes, making them read it is the problem. :-/ > I wonder if it might be useful to have a form which users could be > encouraged to fill out so that (a) the information is available in a > structured format so it's easier for developers to find the relevant > information, (b) so it is easier for programs to parse, for easier > reporting or indexing, and (c) as a nudge so that users remember to > report critical bits of information such as the hardware > configuration, the exact kernel version, which distribution userspace > was in use, etc. > > There could also be something in the text form which would make it > easier for lore.kernel.org searches to identify bug reports. (e.g., > "LINUX KERNEL BUG REPORTER TEMPLATE") Hmmm, yeah, I like that idea. I'll keep it in mind for later: I would prefer to get reporting-issues.rst officially blessed and reporting-bugs.rst gone before working on further enhancements. Maybe the best idea would be to have a script and/or webpage that helps people creating the proper text form (which they then could simply copy-and-paste into their mailer). I had such a script/webpage in mind already to help with one of the IMHO biggest pain points when it comes to reporting issues: finding where the report needs to go, as decoding MAINTAINERS requires that you have a at least a vague idea which component might be causing the issue – which afaics is hard even for people that known a thing or two about the kernel. :-/ Ciao, Thorsten
Re: [PATCH] serial: imx: drop workaround for forced irq threading
On 2021-03-23 08:34:47 [+0100], Uwe Kleine-König wrote:
> Hello Sebastian,
Hi Uwe,
> On Mon, Mar 22, 2021 at 09:48:36PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2021-03-22 14:40:32 [+0100], Uwe Kleine-König wrote:
> > > From a strictly logically point of view you indeed cannot. But if you go
> > > to the street and say to people there that they can park their car in
> > > this street free of charge between Monday and Friday, I expect that most
> > > of them will assume that they have to pay for parking on weekends.
> >
> > If I hear that parking is free on weekdays and on paid on weekends, I
> > expect it to be a scam.
>
> I don't feel taken seriously with this reply.
I'm sorry.
> > Uwe, the patch reverts a change which was needed for !RT + threadirqs.
>
> This would be a useful information for the commit log.
>
> > The commit message claims that since the referenced commit "… interrupt
> > handlers always run with interrupts disabled on non-RT… ". This has
> > nothing to do with _this_ change. It argues why the workaround is not
> > needed.
>
> It argues why the work around is not needed on non-RT. It might be
> obvious for someone who is firm in the RT concepts, but IMHO commit logs
> should be understandable by and make sense for a wider audience than the
> deep experts. From what I know about RT "Force-threaded interrupt
> handlers used to run with interrupts enabled" still applies there.
Yes. The commit Johan referenced explains it in more detail.
> > If the referenced commit breaks RT then this is another story.
>
> I'm surprised to hear that from you. With the goal to get RT into
> mainline I would expect you to be happy if people consider the effects
> on RT in their reviews.
Correct, I do and I am glad if people consider other aspects of the
kernel in their review including RT.
> > > So when you said that on on-RT the reason why it used to need a
> > > workaround is gone made me wonder what that implies for RT.
> >
> > There was never reason (or a lockdep splat) for it on RT. If so you
> > should have seen it, right?
>
> No, I don't consider myself to be an RT expert who is aware of all the
> problems. So I admit that for me the effect on RT of the patch under
> discussion isn't obvious. I just wonder that the change is justified
> with being OK on non-RT. So it's either bad that it breaks RT *or*
> improving the commit log would be great.
>
> And even if I had reason to believe that there is no problem with the
> commit on RT, I'd still wish that the commit log wouldn't suggest to the
> casual reader that there might be a problem.
Okay. I added a sentence. What about this rewording:
Force-threaded interrupt handlers used to run with interrupts enabled,
something which could lead to deadlocks in case a threaded handler
shared a lock with code running in hard interrupt context (e.g. timer
callbacks) and did not explicitly disable interrupts.
This was specifically the case for serial drivers that take the port
lock in their console write path as printk can be called from hard
interrupt context also with forced threading ("threadirqs").
Since commit 81e2073c175b ("genirq: Disable interrupts for force
threaded handlers") interrupt handlers always run with interrupts
disabled on non-RT so that drivers no longer need to do handle this.
RT is not affected by the referenced commit and the workaround, that is
reverted, was not required because spinlock_t must not be acquired on
RT in hardirq context.
Drop the now obsolete workaround added by commit 33f16855dcb9 ("tty:
serial: imx: fix potential deadlock").
> Best regards
> Uwe
>
Sebastian
Re: GTE - The hardware timestamping engine
On Mon, Mar 22, 2021 at 01:33:38PM -0700, Dipen Patel wrote: > Hi Richard, > > Thanks for your input and time. Please see below follow up. > > On 3/20/21 8:38 AM, Richard Cochran wrote: > > On Sat, Mar 20, 2021 at 01:44:20PM +0100, Arnd Bergmann wrote: > >> Adding Richard Cochran as well, for drivers/ptp/, he may be able to > >> identify whether this should be integrated into that framework in some > >> form. > > > > I'm not familiar with the GTE, but it sounds like it is a (free > > running?) clock with time stamping inputs. If so, then it could > > expose a PHC. That gets you functionality: > > > > - clock_gettime() and friends > > - comparison ioctl between GTE clock and CLOCK_REALTIME > > - time stamping channels with programmable input selection > > > GTE gets or rather records the timestamps from the TSC > (timestamp system coutner) so its not attached to GTE as any > one can access TSC, so not sure if we really need to implement PHC > and/or clock_* and friends for the GTE. I believe burden to find correlation > between various clock domains should be on the clients, consider below > example. I agree. My understanding is the the TSC is basically an SoC-wide clock that can be (and is) used by several hardware blocks. There's an interface for software to read out the value, but it's part of a block called TKE (time-keeping engine, if I recall correctly) that implements various clock sources and watchdog functionality. As a matter of fact, I recall typing up a driver for that at some point but I don't recall if I ever sent it out or what became of it. I can't find it upstream at least. Anyway, I think given that the GTE doesn't provide that clock itself but rather just a means of taking a snapshot of that clock and stamping certain events with that, it makes more sense to provide that clock from the TKE driver. Thierry signature.asc Description: PGP signature
[rcu:rcu/next] BUILD SUCCESS f4d010298f01aac657191629d6e9e11d978cc64d
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next branch HEAD: f4d010298f01aac657191629d6e9e11d978cc64d doc: Fix statement of RCU's memory-ordering requirements elapsed time: 726m configs tested: 122 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig riscvallmodconfig x86_64 allyesconfig i386 allyesconfig riscvallyesconfig m68k m5208evb_defconfig arc haps_hs_defconfig powerpc katmai_defconfig sh rts7751r2dplus_defconfig mips ip27_defconfig riscvnommu_virt_defconfig arc alldefconfig arc axs103_defconfig powerpc powernv_defconfig sh se7712_defconfig arm lubbock_defconfig sparc64 alldefconfig powerpc ppc44x_defconfig mips maltaaprp_defconfig mips cu1830-neo_defconfig sh ap325rxa_defconfig mipsjmr3927_defconfig mips ip28_defconfig arm mxs_defconfig riscvalldefconfig shedosk7705_defconfig sh defconfig mips decstation_64_defconfig openrisc simple_smp_defconfig riscvnommu_k210_defconfig powerpc bluestone_defconfig m68k m5275evb_defconfig nios2alldefconfig powerpc linkstation_defconfig powerpcgamecube_defconfig arm tegra_defconfig xtensa cadence_csp_defconfig powerpc mpc836x_rdk_defconfig openrisc alldefconfig m68k m5249evb_defconfig mipsmaltaup_defconfig arm omap1_defconfig i386defconfig arm imx_v4_v5_defconfig arm at91_dt_defconfig powerpc ep8248e_defconfig powerpc wii_defconfig riscv defconfig powerpcsam440ep_defconfig m68k hp300_defconfig sh se7724_defconfig arm ezx_defconfig armqcom_defconfig m68km5307c3_defconfig ia64defconfig mips pic32mzda_defconfig shsh7785lcr_defconfig ia64 allmodconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig s390 allmodconfig parisc allyesconfig s390defconfig sparcallyesconfig sparc defconfig i386 tinyconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig i386 randconfig-a004-20210322 i386 randconfig-a003-20210322 i386 randconfig-a001-20210322 i386 randconfig-a002-20210322 i386 randconfig-a006-20210322 i386 randconfig-a005-20210322 x86_64 randconfig-a012-20210322 x86_64 randconfig-a015-20210322 x86_64 randconfig-a013-20210322 x86_64
Re: [PATCH 10/13] usb: mtu3: support ip-sleep wakeup for MT8183
Hi Chunfeng,
I love your patch! Perhaps something to improve:
[auto build test WARNING on usb/usb-testing]
[also build test WARNING on robh/for-next linus/master v5.12-rc4 next-20210323]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Chunfeng-Yun/dt-bindings-usb-mtk-xhci-support-property-usb2-lpm-disable/20210322-111651
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: arm64-randconfig-r031-20210322 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
14696baaf4c43fe53f738bc292bbe169eed93d5d)
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
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
#
https://github.com/0day-ci/linux/commit/6c0e65b02daf53e661d1804f081cb75fda28b916
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Chunfeng-Yun/dt-bindings-usb-mtk-xhci-support-property-usb2-lpm-disable/20210322-111651
git checkout 6c0e65b02daf53e661d1804f081cb75fda28b916
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/usb/mtu3/mtu3_host.c:60:35: warning: implicit conversion from
>> 'unsigned long' to 'u32' (aka 'unsigned int') changes value from
>> 18446744073441120320 to 4026536000 [-Wconstant-conversion]
msk = WC0_IS_EN | WC0_IS_C(0xf) | WC0_IS_P;
~ ~~^~
drivers/usb/mtu3/mtu3_host.c:61:29: warning: implicit conversion from
'unsigned long' to 'u32' (aka 'unsigned int') changes value from
18446744071562068032 to 2147483712 [-Wconstant-conversion]
val = enable ? (WC0_IS_EN | WC0_IS_C(0x8)) : 0;
~ ~~^~~
2 warnings generated.
vim +60 drivers/usb/mtu3/mtu3_host.c
43
44 /*
45 * ip-sleep wakeup mode:
46 * all clocks can be turn off, but power domain should be kept on
47 */
48 static void ssusb_wakeup_ip_sleep_set(struct ssusb_mtk *ssusb, bool
enable)
49 {
50 u32 reg, msk, val;
51
52 switch (ssusb->uwk_vers) {
53 case SSUSB_UWK_V1:
54 reg = ssusb->uwk_reg_base + PERI_WK_CTRL1;
55 msk = WC1_IS_EN | WC1_IS_C(0xf) | WC1_IS_P;
56 val = enable ? (WC1_IS_EN | WC1_IS_C(0x8)) : 0;
57 break;
58 case SSUSB_UWK_V11:
59 reg = ssusb->uwk_reg_base + PERI_WK_CTRL0;
> 60 msk = WC0_IS_EN | WC0_IS_C(0xf) | WC0_IS_P;
61 val = enable ? (WC0_IS_EN | WC0_IS_C(0x8)) : 0;
62 break;
63 case SSUSB_UWK_V2:
64 reg = ssusb->uwk_reg_base + PERI_SSUSB_SPM_CTRL;
65 msk = SSC_IP_SLEEP_EN | SSC_SPM_INT_EN;
66 val = enable ? msk : 0;
67 break;
68 default:
69 return;
70 }
71 regmap_update_bits(ssusb->uwk, reg, msk, val);
72 }
73
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH -next] x86: Fix intel cpu unsed variable ‘l2’ warning
On Tue, Mar 23, 2021 at 10:59:01AM +0800, Xu Yihang wrote: > Fixes the following W=1 kernel build warning(s): > ../arch/x86/kernel/cpu/intel.c: In function ‘init_intel’: > ../arch/x86/kernel/cpu/intel.c:644:20: warning: variable ‘l2’ set but not > used [-Wunused-but-set-variable] >unsigned int l1, l2; > ^~ > > Compilation command(s): > make allmodconfig ARCH=x86_64 CROSS_COMPILE=x86_64-linux-gnu- > make W=1 arch/x86/kernel/cpu/intel.o ARCH=x86_64 > CROSS_COMPILE=x86_64-linux-gnu- > > According to Intel Software Developer's Manual Table 2-2 through Table 2-24 > about MSRs: > X86_FEATURE_BTS which represents Branch Trace Storage Unavailable and > X86_FEATURE_PEBS > represens Processor Event Based Sampling (PEBS) Unavailable, but on some > platform these fields > maybe reserved or not available. For the function init_intel it self, only > bit 11 and bit 12 > are used for checking BTS and PEBS, and higher 32 bits are not used. So cast > to void to > avoid warning. > > Reported-by: Hulk Robot > Signed-off-by: Xu Yihang > --- > arch/x86/kernel/cpu/intel.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c > index 63e381a46153..547ba6668eb3 100644 > --- a/arch/x86/kernel/cpu/intel.c > +++ b/arch/x86/kernel/cpu/intel.c > @@ -644,6 +644,7 @@ static void init_intel(struct cpuinfo_x86 *c) > unsigned int l1, l2; > > rdmsr(MSR_IA32_MISC_ENABLE, l1, l2); > + (void) l2; > if (!(l1 & (1<<11))) > set_cpu_cap(c, X86_FEATURE_BTS); > if (!(l1 & (1<<12))) > -- Are you kidding me? In what universe is this good idea?! Where have you seen other code like that in the kernel and thought this makes sense? I would strongly suggest you apply some brain matter and common sense before sending patches like that and think real hard whether some warnings need to be fixed at all cost and at all. Because there's a reason these warnings are behind the W= switch. Otherwise all your mail will land in /dev/null and you'll be purely wasting your time. Good luck! -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
[PATCH][next] media: imx-jpeg: Fix spelling mistake "Canot" -> "Cannot"
From: Colin Ian King
There is a spelling mistake in a dev_err message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/media/platform/imx-jpeg/mxc-jpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/imx-jpeg/mxc-jpeg.c
b/drivers/media/platform/imx-jpeg/mxc-jpeg.c
index 2d29558f1864..adb1715c75d7 100644
--- a/drivers/media/platform/imx-jpeg/mxc-jpeg.c
+++ b/drivers/media/platform/imx-jpeg/mxc-jpeg.c
@@ -947,7 +947,7 @@ static void mxc_jpeg_device_run(void *priv)
goto end;
}
if (!mxc_jpeg_alloc_slot_data(jpeg, ctx->slot)) {
- dev_err(dev, "Canot allocate slot data\n");
+ dev_err(dev, "Cannot allocate slot data\n");
goto end;
}
--
2.30.2
Re: [PATCH v1 2/5] mfd: intel_quark_i2c_gpio: Unregister resources in reversed order
On Tue, 02 Mar 2021, Andy Shevchenko wrote: > In ->remove() unregister resources in reversed order, i.e. MFD devices first > followed by I²C clock. > > Signed-off-by: Andy Shevchenko > --- > drivers/mfd/intel_quark_i2c_gpio.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v8 0/3] CPUFreq: Add support for opp-sharing cpus
On Thu, 18 Feb 2021 22:23:23 +, Nicola Mazzucato wrote: > In this V8 I have addressed your comments: > - correct the goto in patch 1/3 > - improve comment in patch 2/3 for dev_pm_opp_get_opp_count() > > Many thanks, > Nicola > > [...] (New commit info after rebase to v5.12-rc2 for obvious reasons) Applied to sudeep.holla/linux (for-next/scmi), thanks! [1/3] scmi-cpufreq: Remove deferred probe https://git.kernel.org/sudeep.holla/c/71a37cd6a5 [2/3] scmi-cpufreq: Get opp_shared_cpus from opp-v2 for EM https://git.kernel.org/sudeep.holla/c/80a064dbd5 -- Regards, Sudeep
Re: [PATCH 1/2] arm64: dts: juno: Describe PCI dma-ranges
On Fri, 5 Mar 2021 17:33:17 +, Robin Murphy wrote: > The PLDA root complex on Juno relies on an address-based lookup table to > generate AXI attributes for inbound PCI transactions, and as such will > not pass any transaction not matching any programmed address range. The > standard firmware configuration programs 3 entries covering the GICv2m > MSI doorbell and the 2 DRAM regions, so add a "dma-ranges" property to > describe those usable inbound windows. (New commit info after rebase to v5.12-rc2 for obvious reasons) Applied to sudeep.holla/linux (for-next/juno), thanks! [1/2] arm64: dts: juno: Describe PCI dma-ranges https://git.kernel.org/sudeep.holla/c/4ac4d146cb [2/2] arm64: dts: juno: Enable more SMMUs https://git.kernel.org/sudeep.holla/c/d9df28ba58 -- Regards, Sudeep
Re: [PATCH V3 1/2] soc: qcom-geni-se: Cleanup the code to remove proxy votes
On Mon, Mar 22, 2021 at 04:34:28PM +0530, Roja Rani Yarubandi wrote:
> This reverts commit 048eb908a1f2 ("soc: qcom-geni-se: Add interconnect
> support to fix earlycon crash")
>
> ICC core and platforms drivers supports sync_state feature with
> commit 7d3b0b0d8184 ("interconnect: qcom: Use icc_sync_state") which
> ensures that the default ICC BW votes from the bootloader is not
> removed until all it's consumers are probes.
>
> The proxy votes were needed in case other QUP child drivers
> I2C, SPI probes before UART, they can turn off the QUP-CORE clock
> which is shared resources for all QUP driver, this causes unclocked
> access to HW from earlycon.
>
> Given above support from ICC there is no longer need to maintain
> proxy votes on QUP-CORE ICC node from QUP wrapper driver for early
> console usecase, the default votes won't be removed until real
> console is probed.
>
> Signed-off-by: Roja Rani Yarubandi
> Signed-off-by: Akash Asthana
> Reviewed-by: Matthias Kaehlcke
Should this have a "Fixes:" tag, and also be cc: sta...@vger.kernel.org
so that it will be properly backported?
If so, please add and resend.
thanks,
greg k-h
Re: [PATCH v7 25/38] iio/scmi: port driver to the new scmi_sensor_proto_ops interface
Hi Jonathan, On Thu, Mar 18, 2021 at 12:12:02PM +, Sudeep Holla wrote: > On Tue, Mar 16, 2021 at 10:38:43PM -0700, Jyoti Bhayana wrote: > > Hi Christian, > > > > Thanks for the detailed explanation. Sounds good to me. > > > > Can I get official Reviewed-by or Acked-by please if you are fine with the > change ? > I need your ack to this via arm-soc. -- Regards, Sudeep
Re: [PATCH] selftests: kvm: make hardware_disable_test less verbose
On Tue, Mar 23, 2021 at 09:53:03AM +0100, Vitaly Kuznetsov wrote:
> hardware_disable_test produces 512 snippets like
> ...
> main: [511] waiting semaphore
> run_test: [511] start vcpus
> run_test: [511] all threads launched
> main: [511] waiting 368us
> main: [511] killing child
>
> and this doesn't have much value, let's just drop these fprintf().
> Restoring them for debugging purposes shouldn't be too hard.
Changing them to pr_debug() allows you to keep them and restore
with -DDEBUG
Thanks,
drew
>
> Signed-off-by: Vitaly Kuznetsov
> ---
> tools/testing/selftests/kvm/hardware_disable_test.c | 5 -
> 1 file changed, 5 deletions(-)
>
> diff --git a/tools/testing/selftests/kvm/hardware_disable_test.c
> b/tools/testing/selftests/kvm/hardware_disable_test.c
> index 2f2eeb8a1d86..d6d4517c4a8a 100644
> --- a/tools/testing/selftests/kvm/hardware_disable_test.c
> +++ b/tools/testing/selftests/kvm/hardware_disable_test.c
> @@ -108,7 +108,6 @@ static void run_test(uint32_t run)
> kvm_vm_elf_load(vm, program_invocation_name, 0, 0);
> vm_create_irqchip(vm);
>
> - fprintf(stderr, "%s: [%d] start vcpus\n", __func__, run);
> for (i = 0; i < VCPU_NUM; ++i) {
> vm_vcpu_add_default(vm, i, guest_code);
> payloads[i].vm = vm;
> @@ -124,7 +123,6 @@ static void run_test(uint32_t run)
> check_set_affinity(throw_away, _set);
> }
> }
> - fprintf(stderr, "%s: [%d] all threads launched\n", __func__, run);
> sem_post(sem);
> for (i = 0; i < VCPU_NUM; ++i)
> check_join(threads[i], );
> @@ -147,16 +145,13 @@ int main(int argc, char **argv)
> if (pid == 0)
> run_test(i); /* This function always exits */
>
> - fprintf(stderr, "%s: [%d] waiting semaphore\n", __func__, i);
> sem_wait(sem);
> r = (rand() % DELAY_US_MAX) + 1;
> - fprintf(stderr, "%s: [%d] waiting %dus\n", __func__, i, r);
> usleep(r);
> r = waitpid(pid, , WNOHANG);
> TEST_ASSERT(r != pid,
> "%s: [%d] child exited unexpectedly status: [%d]",
> __func__, i, s);
> - fprintf(stderr, "%s: [%d] killing child\n", __func__, i);
> kill(pid, SIGKILL);
> }
>
> --
> 2.30.2
>
Re: [PATCH 00/11] pragma once: treewide conversion
Hi! > > > (a) the traditional include guard optimization HAS NO HIDDEN SEMANTIC > > > MEANING. It's a pure optimization that doesn't actually change > > > anything else. If you don't do the optimization, absolutely nothing > > > changes. > > > > And if the parser is well written the optimisation is probably > > irrelevant compared to the compile time. > > That's actually surprisingly not even remotely true. > > People always think that the optimization phases of a compiler are the > expensive ones. And yes, there are certain optimizations that can be > *really* expensive, and people just don't even do them because they > are _so_ expensive and are exponential in time. Well, linux kernel can be compiled in two _seconds_ if you take compiler optimized for fast parsing... and quick code generation. See "SUSE Labs Conference 2018 - Compiling the Linux kernel in a second (give or take)" on youtube. So yes, gcc's frontend may be slow, but that does not mean job can not be done quickly by suitable compiler. Best regards, Pavel -- http://www.livejournal.com/~pavelmachek signature.asc Description: Digital signature
Re: [PATCH 3/5] mm/migrate.c: fix potential indeterminate pte entry in migrate_vma_insert_page()
On 20.03.21 10:36, Miaohe Lin wrote:
If the zone device page does not belong to un-addressable device memory,
the variable entry will be uninitialized and lead to indeterminate pte
entry ultimately. Fix this unexpectant case and warn about it.
s/unexpectant/unexpected/
Fixes: df6ad69838fc ("mm/device-public-memory: device memory cache coherent with
CPU")
Signed-off-by: Miaohe Lin
---
mm/migrate.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/mm/migrate.c b/mm/migrate.c
index 20a3bf75270a..271081b014cb 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -2972,6 +2972,13 @@ static void migrate_vma_insert_page(struct migrate_vma
*migrate,
swp_entry = make_device_private_entry(page, vma->vm_flags & VM_WRITE);
entry = swp_entry_to_pte(swp_entry);
+ } else {
+ /*
+* For now we only support migrating to un-addressable
+* device memory.
+*/
+ WARN_ON(1);
+ goto abort;
Fix it by crashing the kernel with panic_on_warn? :)
If this case can actual happen, than no WARN_ON() - rather a
pr_warn_once(). If this case cannot happen, why do we even care (it's
not a fix then)?
--
Thanks,
David / dhildenb
[PATCH resend] tty:serial: fix spelling typo of values
From: zhichao Cai vaules -> values Signed-off-by: zhichao Cai --- drivers/tty/serial/8250/8250_mtk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c index f7d3023..c6633dc 100644 --- a/drivers/tty/serial/8250/8250_mtk.c +++ b/drivers/tty/serial/8250/8250_mtk.c @@ -325,7 +325,7 @@ static void mtk8250_set_flow_ctrl(struct uart_8250_port *up, int mode) * Mediatek UARTs use an extra highspeed register (MTK_UART_HIGHS) * * We need to recalcualte the quot register, as the claculation depends -* on the vaule in the highspeed register. +* on the value in the highspeed register. * * Some baudrates are not supported by the chip, so we use the next * lower rate supported and update termios c_flag. -- 1.9.1
Re: [PATCH RFC v2 8/8] selftests/perf: Add kselftest for remove_on_exec
On Tue, 23 Mar 2021 at 11:32, Peter Zijlstra wrote:
>
> On Tue, Mar 23, 2021 at 10:52:41AM +0100, Marco Elver wrote:
>
> > with efs->func==__perf_event_enable. I believe it's sufficient to add
> >
> > mutex_lock(_event->child_mutex);
> > list_del_init(>child_list);
> > mutex_unlock(_event->child_mutex);
> >
> > right before removing from context. With the version I have now (below
> > for completeness), extended torture with the above test results in no
> > more warnings and the test also passes.
> >
>
> > + list_for_each_entry_safe(event, next, >event_list, event_entry) {
> > + struct perf_event *parent_event = event->parent;
> > +
> > + if (!event->attr.remove_on_exec)
> > continue;
> >
> > + if (!is_kernel_event(event))
> > + perf_remove_from_owner(event);
> >
> > + modified = true;
> > +
> > + if (parent_event) {
> > /*
> > + * Remove event from parent, to avoid race where the
> > + * parent concurrently iterates through its children
> > to
> > + * enable, disable, or otherwise modify an event.
> >*/
> > + mutex_lock(_event->child_mutex);
> > + list_del_init(>child_list);
> > + mutex_unlock(_event->child_mutex);
> > }
>
> ^^^ this, right?
>
> But that's something perf_event_exit_event() alread does. So then you're
> worried about the order of things.
Correct. We somehow need to prohibit the parent from doing an
event_function_call() while we potentially deactivate the context with
perf_remove_from_context().
> > +
> > + perf_remove_from_context(event, !!event->parent *
> > DETACH_GROUP);
> > + perf_event_exit_event(event, ctx, current, true);
> > }
>
> perf_event_release_kernel() first does perf_remove_from_context() and
> then clears the child_list, and that makes sense because if we're there,
> there's no external access anymore, the filedesc is gone and nobody will
> be iterating child_list anymore.
>
> perf_event_exit_task_context() and perf_event_exit_event() OTOH seem to
> rely on ctx->task == TOMBSTONE to sabotage event_function_call() such
> that if anybody is iterating the child_list, it'll NOP out.
>
> But here we don't have neither, and thus need to worry about the order
> vs child_list iteration.
>
> I suppose we should stick sync_child_event() in there as well.
>
> And at that point there's very little value in still using
> perf_event_exit_event()... let me see if there's something to be done
> about that.
I don't mind dropping use of perf_event_exit_event() and open coding
all of this. That would also avoid modifying perf_event_exit_event().
But I leave it to you what you think is nicest.
Thanks,
-- Marco
Re: [PATCH v5 2/5] acpi,memhotplug: Enable MHP_MEMMAP_ON_MEMORY when supported
On Fri 19-03-21 10:26:32, Oscar Salvador wrote: > Let the caller check whether it can pass MHP_MEMMAP_ON_MEMORY by > checking mhp_supports_memmap_on_memory(). > MHP_MEMMAP_ON_MEMORY can only be set in case > ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE is enabled, the architecture supports > altmap, and the range to be added spans a single memory block. > > Signed-off-by: Oscar Salvador > Reviewed-by: David Hildenbrand Acked-by: Michal Hocko > --- > drivers/acpi/acpi_memhotplug.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c > index b02fd51e5589..8cc195c4c861 100644 > --- a/drivers/acpi/acpi_memhotplug.c > +++ b/drivers/acpi/acpi_memhotplug.c > @@ -171,6 +171,7 @@ static int acpi_memory_enable_device(struct > acpi_memory_device *mem_device) > acpi_handle handle = mem_device->device->handle; > int result, num_enabled = 0; > struct acpi_memory_info *info; > + mhp_t mhp_flags = MHP_NONE; > int node; > > node = acpi_get_node(handle); > @@ -194,8 +195,10 @@ static int acpi_memory_enable_device(struct > acpi_memory_device *mem_device) > if (node < 0) > node = memory_add_physaddr_to_nid(info->start_addr); > > + if (mhp_supports_memmap_on_memory(info->length)) > + mhp_flags |= MHP_MEMMAP_ON_MEMORY; > result = __add_memory(node, info->start_addr, info->length, > - MHP_NONE); > + mhp_flags); > > /* >* If the memory block has been used by the kernel, add_memory() > -- > 2.16.3 -- Michal Hocko SUSE Labs
Re: [PATCH v2 2/2] s390/kvm: VSIE: fix MVPG handling for prefixing and MSO
On 22.03.21 15:05, Claudio Imbrenda wrote:
Prefixing needs to be applied to the guest real address to translate it
into a guest absolute address.
The value of MSO needs to be added to a guest-absolute address in order to
obtain the host-virtual.
Fixes: 223ea46de9e79 ("s390/kvm: VSIE: correctly handle MVPG when in VSIE")
Cc: sta...@vger.kernel.org
Signed-off-by: Claudio Imbrenda
Reported-by: Janosch Frank
---
arch/s390/kvm/vsie.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c
index 48aab6290a77..ac86f11e46dc 100644
--- a/arch/s390/kvm/vsie.c
+++ b/arch/s390/kvm/vsie.c
@@ -1002,7 +1002,7 @@ static u64 vsie_get_register(struct kvm_vcpu *vcpu,
struct vsie_page *vsie_page,
static int vsie_handle_mvpg(struct kvm_vcpu *vcpu, struct vsie_page
*vsie_page)
{
struct kvm_s390_sie_block *scb_s = _page->scb_s;
- unsigned long pei_dest, pei_src, src, dest, mask;
+ unsigned long pei_dest, pei_src, dest, src, mask, mso, prefix;
u64 *pei_block = _page->scb_o->mcic;
int edat, rc_dest, rc_src;
union ctlreg0 cr0;
@@ -1010,9 +1010,13 @@ static int vsie_handle_mvpg(struct kvm_vcpu *vcpu,
struct vsie_page *vsie_page)
cr0.val = vcpu->arch.sie_block->gcr[0];
edat = cr0.edat && test_kvm_facility(vcpu->kvm, 8);
mask = _kvm_s390_logical_to_effective(_s->gpsw, PAGE_MASK);
+ mso = scb_s->mso & ~(1UL << 20);
+ prefix = scb_s->prefix << GUEST_PREFIX_SHIFT;
dest = vsie_get_register(vcpu, vsie_page, scb_s->ipb >> 16) & mask;
+ dest = _kvm_s390_real_to_abs(prefix, dest) + mso;
src = vsie_get_register(vcpu, vsie_page, scb_s->ipb >> 20) & mask;
+ src = _kvm_s390_real_to_abs(prefix, src) + mso;
rc_dest = kvm_s390_shadow_fault(vcpu, vsie_page->gmap, dest, _dest);
rc_src = kvm_s390_shadow_fault(vcpu, vsie_page->gmap, src, _src);
mso is always confusing, but I think this should be correct.
Reviewed-by: David Hildenbrand
--
Thanks,
David / dhildenb
Re: [PATCH] mmc: core: Mark mmc_host device with pm_runtime_no_callbacks
We encounter a resume issue in our device sometimes. The mmc device's
parent list is
mmc0:0001->mmc_host mmc0->fa63.mmc->soc in our soc. We found in the blow
case with mmc0->power.disable_depth=0 the mmc_runtime_resume will be skipped,
which cause subsequent mmc command fail.
mmc_get_card(mmc0:0001)->pm_runtime_get_sync->rpm_resume(mmc0:0001)->rpm_resume(mmc0)
The rpm_resume(mmc0) return -ENOSYS due to no callback and
mmc0->power.runtime_status
keep RPM_SUSPENDED. This lead to rpm_resume(mmc0:0001) return -EBUSY and skip
rpm_callback which call mmc_runtime_resume, the mmc is still in
suspended and the
subsequent mmc command fail.
[ 198.856157] Call trace:
[ 198.858917] [] dump_backtrace+0x0/0x1cc
[ 198.864966] [] show_stack+0x14/0x1c
[ 198.870627] [] dump_stack+0xa8/0xe0
[ 198.876288] [] rpm_resume+0x850/0x938
[ 198.882141] [] rpm_resume+0x250/0x938
[ 198.887994] [] __pm_runtime_resume+0x50/0x74
[ 198.894530] [] mmc_get_card+0x3c/0xb8
[ 198.900388] [] mmc_blk_issue_rq+0x2b0/0x4d8
[ 198.906824] [] mmc_queue_thread+0xdc/0x198
[ 198.913165] [] kthread+0xec/0x100
[ 198.918632] [] ret_from_fork+0x10/0x40
[ 198.924582] mmc0 callback (null)
[ 198.935837] mmcblk mmc0:0001: __pm_runtime_resume ret -16
Mark mmc_host device with pm_runtime_no_callbacks will solve the issue.
Thanks.
Huanlin Ke
Ulf Hansson 于2021年3月22日周一 下午6:26写道：
>
> On Sat, 20 Mar 2021 at 05:57, kehuanlin wrote:
> >
> > The rpm_resume() will call parent's resume callback recursively.
> > Since mmc_host has no its own pm_runtime callbacks, the mmc devices
> > may fail to resume (-ENOSYS in rpm_callback) sometimes. Mark mmc_host
> > device with pm_runtime_no_callbacks can fix the issue.
>
> Can you please elaborate more on this? What do you mean by "sometimes"?
>
> More precisely, how do you trigger the rpm_callback() for mmc class
> device to return -ENOSYS?
>
> Don't get me wrong, the patch is fine, but I want to understand if it
> actually solves a problem for you - or that it's better considered as
> an optimization?
>
> Kind regards
> Uffe
>
> >
> > Signed-off-by: kehuanlin
> > ---
> > drivers/mmc/core/host.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
> > index 9b89a91b6b47..177bebd9a6c4 100644
> > --- a/drivers/mmc/core/host.c
> > +++ b/drivers/mmc/core/host.c
> > @@ -15,6 +15,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -480,6 +481,7 @@ struct mmc_host *mmc_alloc_host(int extra, struct
> > device *dev)
> > host->class_dev.class = _host_class;
> > device_initialize(>class_dev);
> > device_enable_async_suspend(>class_dev);
> > + pm_runtime_no_callbacks(>class_dev);
> >
> > if (mmc_gpio_alloc(host)) {
> > put_device(>class_dev);
> > --
> > 2.30.0
> >
Re: [PATCH v1 2/3] kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources
On Mon, Mar 22, 2021 at 05:01:59PM +0100, David Hildenbrand wrote:
> It used to be true that we can have system RAM only on the first level
> in the resourc tree. However, this is no longer holds for driver-managed
> system RAM (i.e., dax/kmem and virtio-mem).
>
> The function walk_mem_res() only consideres the first level and is
> used in arch/x86/mm/ioremap.c:__ioremap_check_mem() only. We currently
> fail to identify System RAM added by dax/kmem and virtio-mem as
> "IORES_MAP_SYSTEM_RAM", for example, allowing for remapping of such
> "normal RAM" in __ioremap_caller().
Here I dunno, but consider to add Fixes tag if it fixes known bad behaviour.
> Let's find all busy IORESOURCE_MEM resources, making the function
> behave similar to walk_system_ram_res().
>
> Cc: Andrew Morton
> Cc: Greg Kroah-Hartman
> Cc: Dan Williams
> Cc: Daniel Vetter
> Cc: Andy Shevchenko
> Cc: Mauro Carvalho Chehab
> Cc: Signed-off-by: David Hildenbrand
> Cc: Dave Young
> Cc: Baoquan He
> Cc: Vivek Goyal
> Cc: Dave Hansen
> Cc: Keith Busch
> Cc: Michal Hocko
> Cc: Qian Cai
> Cc: Oscar Salvador
> Cc: Eric Biederman
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Tom Lendacky
> Cc: Brijesh Singh
> Cc: x...@kernel.org
> Cc: ke...@lists.infradead.org
> Signed-off-by: David Hildenbrand
> ---
> kernel/resource.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/resource.c b/kernel/resource.c
> index 4efd6e912279..16e0c7e8ed24 100644
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -470,7 +470,7 @@ int walk_mem_res(u64 start, u64 end, void *arg,
> {
> unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
>
> - return __walk_iomem_res_desc(start, end, flags, IORES_DESC_NONE, true,
> + return __walk_iomem_res_desc(start, end, flags, IORES_DESC_NONE, false,
>arg, func);
> }
>
> --
> 2.29.2
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH] ARM: dts: at91-sama5d27_som1: fix phy address to 7
Alexander, Ahmad,
On 23/03/2021 at 11:55, Ahmad Fatoum wrote:
Hello Alexander,
On 23.03.21 11:45, Alexander Dahl wrote:
Hei hei,
I could not get ethernet to work on SAMA5D27-SOM1-EK1 with kernels v5.10 and
v5.11 built by a recent ptxdist based DistroKit BSP, while it used to work with
an older v4.19 kernel. Just applying this patch to the tree made ethernet
working again, thus:
Tested-by: Alexander Dahl
Not sure why it worked with that older kernel, though.
Thanks for investigating! Seems that somehow PHY broadcast worked on this
board with older kernels (and current barebox), but no longer does with
newer kernels.
A bisection could shed some light onto what broke this.
As the KSZ8081 driver disables broadcast in the phy config init, this change
looks appropriate regardless. The fixes tag doesn't refer to an upstream
commit though. This should probably read:
Fixes: af690fa37e39 ("ARM: dts: at91: at91-sama5d27_som1: add sama5d27 SoM1
support")
I didn't noticed that on my side.
With this addressed:
Reviewed-by: Ahmad Fatoum
Thanks a lot for your feedback.
You could send a proper patch and stick your S-o-b under it.
Actually this patch is already in arm-soc tree here:
https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/commit/?h=arm/fixes=221c3a09ddf70a0a51715e6c2878d8305e95c558
So I cannot add tags anymore to it, sorry.
Best regards,
Nicolas
I added Ahmad to Cc, he added board support to DistroKit for that board, and
might want to know. And I added the devicetree list to Cc, I wondered why the
patch was not there and get_maintainers.pl proposed it.
Thanks for fixing this and greetings
Alex
nicolas.fe...@microchip.com hat am 17.02.2021 12:38 geschrieben:
From: Claudiu Beznea
Fix the phy address to 7 for Ethernet PHY on SAMA5D27 SOM1. No
connection established if phy address 0 is used.
The board uses the 24 pins version of the KSZ8081RNA part, KSZ8081RNA
pin 16 REFCLK as PHYAD bit [2] has weak internal pull-down. But at
reset, connected to PD09 of the MPU it's connected with an internal
pull-up forming PHYAD[2:0] = 7.
Signed-off-by: Claudiu Beznea
Fixes: 2f61929eb10a ("ARM: dts: at91: at91-sama5d27_som1: fix PHY ID")
Cc: Ludovic Desroches
Signed-off-by: Nicolas Ferre
Cc: # 4.14+
---
arch/arm/boot/dts/at91-sama5d27_som1.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
b/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
index 1b1163858b1d..e3251f3e3eaa 100644
--- a/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
+++ b/arch/arm/boot/dts/at91-sama5d27_som1.dtsi
@@ -84,8 +84,8 @@ macb0: ethernet@f8008000 {
pinctrl-0 = <_macb0_default>;
phy-mode = "rmii";
-ethernet-phy@0 {
-reg = <0x0>;
+ethernet-phy@7 {
+reg = <0x7>;
interrupt-parent = <>;
interrupts = ;
pinctrl-names = "default";
--
2.30.0
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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- |
--
Nicolas Ferre
RE: [PATCH v3 1/2] PCI: xilinx-nwl: Enable coherent PCIe DMA traffic using CCI
Ping. > -Original Message- > From: Bharat Kumar Gogada > Sent: Monday, March 15, 2021 11:43 AM > To: Bharat Kumar Gogada ; linux- > p...@vger.kernel.org; linux-kernel@vger.kernel.org > Cc: bhelg...@google.com > Subject: RE: [PATCH v3 1/2] PCI: xilinx-nwl: Enable coherent PCIe DMA traffic > using CCI > > Ping. > > > -Original Message- > > From: Bharat Kumar Gogada > > Sent: Monday, February 22, 2021 2:18 PM > > To: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org > > Cc: bhelg...@google.com; Bharat Kumar Gogada > > Subject: [PATCH v3 1/2] PCI: xilinx-nwl: Enable coherent PCIe DMA > > traffic using CCI > > > > Add support for routing PCIe DMA traffic coherently when Cache > > Coherent Interconnect (CCI) is enabled in the system. > > The "dma-coherent" property is used to determine if CCI is enabled or not. > > Refer to https://developer.arm.com/documentation/ddi0470/k/preface > > for the CCI specification. > > > > Signed-off-by: Bharat Kumar Gogada > > --- > > drivers/pci/controller/pcie-xilinx-nwl.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c > > b/drivers/pci/controller/pcie-xilinx-nwl.c > > index 07e36661bbc2..8689311c5ef6 100644 > > --- a/drivers/pci/controller/pcie-xilinx-nwl.c > > +++ b/drivers/pci/controller/pcie-xilinx-nwl.c > > @@ -26,6 +26,7 @@ > > > > /* Bridge core config registers */ > > #define BRCFG_PCIE_RX0 0x > > +#define BRCFG_PCIE_RX1 0x0004 > > #define BRCFG_INTERRUPT0x0010 > > #define BRCFG_PCIE_RX_MSG_FILTER 0x0020 > > > > @@ -128,6 +129,7 @@ > > #define NWL_ECAM_VALUE_DEFAULT 12 > > > > #define CFG_DMA_REG_BARGENMASK(2, 0) > > +#define CFG_PCIE_CACHE GENMASK(7, 0) > > > > #define INT_PCI_MSI_NR (2 * 32) > > > > @@ -675,6 +677,11 @@ static int nwl_pcie_bridge_init(struct nwl_pcie > > *pcie) > > nwl_bridge_writel(pcie, CFG_ENABLE_MSG_FILTER_MASK, > > BRCFG_PCIE_RX_MSG_FILTER); > > > > + /* This routes the PCIe DMA traffic to go through CCI path */ > > + if (of_dma_is_coherent(dev->of_node)) > > + nwl_bridge_writel(pcie, nwl_bridge_readl(pcie, > > BRCFG_PCIE_RX1) | > > + CFG_PCIE_CACHE, BRCFG_PCIE_RX1); > > + > > err = nwl_wait_for_link(pcie); > > if (err) > > return err; > > -- > > 2.17.1
Re: [PATCH] rcu: Fix various typos in comments
* Paul E. McKenney wrote: > > > * there are no read-side primitives analogous to rcu_read_lock() and > > > * rcu_read_unlock() because this primitive is intended to determine > > > * that all tasks have passed through a safe state, not so much for > > > - * data-strcuture synchronization. > > > + * data-structure synchronization. > > > * > > > > The "hyphen" in the middle of the word "data structure" is required or > > keeping by > > convention or has some significance? > > Yes, this is one of many peculiarities of English, and an optional one > at that. English is not a block-structured language, so grouping can > be ambiguous. Is is "(data structure) synchronization" or is it instead > "data (structure synchronization)"? The default is the latter, and > the hyphen indicates the former. In this case, the former is intended, > hence the hyphen. The other point is that there are a *lot* of hyphen variations in the kernel, and unless the primary author or maintainer is iterating the text would be insane to categorize them as 'typos' and create churn to 'fix' them... 'data-structure' or 'datastructure' are both perfectly readable, just like 'fast-path' or 'fastpath', 'cache-miss' or 'cachemiss' and a million other examples. Thanks, Ingo
[tip: locking/urgent] locking/mutex: Fix non debug version of mutex_lock_io_nested()
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 291da9d4a9eb3a1cb0610b7f4480f5b52b1825e7
Gitweb:
https://git.kernel.org/tip/291da9d4a9eb3a1cb0610b7f4480f5b52b1825e7
Author:Thomas Gleixner
AuthorDate:Mon, 22 Mar 2021 09:46:13 +01:00
Committer: Ingo Molnar
CommitterDate: Tue, 23 Mar 2021 12:20:23 +01:00
locking/mutex: Fix non debug version of mutex_lock_io_nested()
If CONFIG_DEBUG_LOCK_ALLOC=n then mutex_lock_io_nested() maps to
mutex_lock() which is clearly wrong because mutex_lock() lacks the
io_schedule_prepare()/finish() invocations.
Map it to mutex_lock_io().
Fixes: f21860bac05b ("locking/mutex, sched/wait: Fix the mutex_lock_io_nested()
define")
Signed-off-by: Thomas Gleixner
Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Ingo Molnar
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/878s6fshii@nanos.tec.linutronix.de
---
include/linux/mutex.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/mutex.h b/include/linux/mutex.h
index 0cd631a..515cff7 100644
--- a/include/linux/mutex.h
+++ b/include/linux/mutex.h
@@ -185,7 +185,7 @@ extern void mutex_lock_io(struct mutex *lock);
# define mutex_lock_interruptible_nested(lock, subclass)
mutex_lock_interruptible(lock)
# define mutex_lock_killable_nested(lock, subclass) mutex_lock_killable(lock)
# define mutex_lock_nest_lock(lock, nest_lock) mutex_lock(lock)
-# define mutex_lock_io_nested(lock, subclass) mutex_lock(lock)
+# define mutex_lock_io_nested(lock, subclass) mutex_lock_io(lock)
#endif
/*
Re: [PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources
On 23.03.21 12:06, Andy Shevchenko wrote:
On Mon, Mar 22, 2021 at 05:01:58PM +0100, David Hildenbrand wrote:
It used to be true that we can have busy system RAM only on the first level
in the resourc tree. However, this is no longer holds for driver-managed
system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on
lower levels.
We have two users of walk_system_ram_res(), which currently only
consideres the first level:
a) kernel/kexec_file.c:kexec_walk_resources() -- We properly skip
IORESOURCE_SYSRAM_DRIVER_MANAGED resources via
locate_mem_hole_callback(), so even after this change, we won't be
placing kexec images onto dax/kmem and virtio-mem added memory. No
change.
b) arch/x86/kernel/crash.c:fill_up_crash_elf_data() -- we're currently
not adding relevant ranges to the crash elf info, resulting in them
not getting dumped via kdump.
This change fixes loading a crashkernel via kexec_file_load() and including
"...fixes..." effectively means to me that Fixes tag should be provided.
We can certainly add, although it doesn't really affect the running
kernel, but only crashdumps taken in the kdump kernel:
Fixes: ebf71552bb0e ("virtio-mem: Add parent resource for all added
"System RAM"")
Fixes: c221c0b0308f ("device-dax: "Hotplug" persistent memory for use
like normal RAM")
Thanks
--
Thanks,
David / dhildenb
Re: [PATCH] video/fbdev: Fix a double free in hvfb_probe
Thanks for your patch.
I would like to change the prefix to "video: hyperv_fb:" to be more
specific.
On Tue, Mar 23, 2021 at 12:33:50AM -0700, Lv Yunlong wrote:
> In function hvfb_probe in hyperv_fb.c, it calls hvfb_getmem(hdev, info)
> and return err when info->apertures is freed.
>
> In the error1 label of hvfb_probe, info->apertures will be freed twice
> by framebuffer_release(info).
>
I would say "freed for the second time" here. What you wrote reads to me
fraembuffer_release frees the buffer twice all by itself.
> My patch sets info->apertures to NULL after it was freed to avoid
> double free.
>
I think this approach works. I would like to give other people a chance
to comment though.
Fixes: 3a6fb6c4255c ("video: hyperv: hyperv_fb: Use physical memory for fb on
HyperV Gen 1 VMs.")
> Signed-off-by: Lv Yunlong
> ---
> drivers/video/fbdev/hyperv_fb.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
> index c8b0ae676809..2fc9b507e73a 100644
> --- a/drivers/video/fbdev/hyperv_fb.c
> +++ b/drivers/video/fbdev/hyperv_fb.c
> @@ -1032,6 +1032,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct
> fb_info *info)
> if (!pdev) {
> pr_err("Unable to find PCI Hyper-V video\n");
> kfree(info->apertures);
> + info->apertures = NULL;
> return -ENODEV;
> }
>
> @@ -1130,6 +1131,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct
> fb_info *info)
> pci_dev_put(pdev);
> }
> kfree(info->apertures);
> + info->apertures = NULL;
>
> return 0;
>
> @@ -1142,6 +1144,7 @@ static int hvfb_getmem(struct hv_device *hdev, struct
> fb_info *info)
> if (!gen2vm)
> pci_dev_put(pdev);
> kfree(info->apertures);
> + info->apertures = NULL;
>
> return -ENOMEM;
> }
> --
> 2.25.1
>
>
Re: [PATCH v7 1/3] usb: dwc3: qcom: Add missing DWC3 OF node refcount decrement
On Thu, Feb 18, 2021 at 06:40:51PM +0300, Serge Semin wrote: > On Thu, Feb 18, 2021 at 04:32:29PM +0100, Greg Kroah-Hartman wrote: > > On Thu, Feb 18, 2021 at 06:29:04PM +0300, Serge Semin wrote: > > > Bjorn, Greg, Felippe, Andy, > > > Any comments on this series? Bjorn, Greg you asked me to resend the > > > patches related with the DW USB3 node name change. I did as you said, > > > but no news since then. I'd be glad to have this patch accepted in > > > some -next repo and forget about it. > > > > > Sorry, but it's the merge window right now and I can't add anything new > > until 5.12-rc1 is out. So can you wait until then? > > Well, I don't think there is another choice but to wait now.) > Hopefully the patchset won't be forgotten when the merge window closes > as that happened with the original series... Can you resend this if still needed? I don't see them in my queue... thanks, greg k-h
Re: [PATCH v3 1/2] usbip: tools: add options and examples in man page related to device mode
On Tue, Mar 16, 2021 at 04:36:57AM +0800, Hongren Zheng (Zenithal) wrote:
> The commit e0546fd8b748b19d8edd1550530da8ebad6e4b31 implemented device
> mode for user space tools, however the corresponding options are not
> documented in man page.
When referring to commits in the kernel, they should be listed as:
e0546fd8b748 ("usbip: tools: Start using VUDC backend in usbip tools")
as the kernel documentation asks for.
Please fix up and resend.
thanks,
greg k-h
Re: [PATCH v2] mtd: spinand: add support for Foresee FS35ND01G-S1Y2
Hi Miquel, On Tue, 23 Mar 2021 at 19:32, Miquel Raynal wrote: > You can run nandbiterrs -i /dev/mtdX > > You'll see if there is ECC correction or not (and its level). These are results I get for both of the nandbiterrs tests. # nandbiterrs -i /dev/mtd1 incremental biterrors test Successfully corrected 0 bit errors per subpage Inserted biterror @ 0/5 Read reported 4 corrected bit errors ECC failure, invalid data despite read success # nandbiterrs -o /dev/mtd1 overwrite biterrors test Read reported 4 corrected bit errors Failed to recover 1 bitflips Bit error histogram (883 operations total): Page reads with 0 corrected bit errors: 845 Page reads with 1 corrected bit errors: 0 Page reads with 2 corrected bit errors: 0 Page reads with 3 corrected bit errors: 0 I guess this means ECC is there and it's working. Thanks, Daniel
Re: [PATCH 09/17] auxdisplay: ht16k33: Use HT16K33_FB_SIZE in ht16k33_initialize()
On 2021-03-22 15:48, Geert Uytterhoeven wrote:
Use the existing HT16K33_FB_SIZE definition instead of open-coding the
same calculation using an hardcoded value.
While at it, restore reverse Christmas tree variable declaration order.
Signed-off-by: Geert Uytterhoeven
---
drivers/auxdisplay/ht16k33.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/auxdisplay/ht16k33.c
b/drivers/auxdisplay/ht16k33.c
index 1e69cc6d21a0dca2..6d39f12054618fa5 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -168,9 +168,9 @@ static void ht16k33_fb_update(struct work_struct
*work)
static int ht16k33_initialize(struct ht16k33_priv *priv)
{
+ uint8_t data[HT16K33_FB_SIZE];
uint8_t byte;
int err;
- uint8_t data[HT16K33_MATRIX_LED_MAX_COLS * 2];
/* Clear RAM (8 * 16 bits) */
memset(data, 0, sizeof(data));
Acked-by: Robin van der Gracht
Re: [PATCH 10/17] auxdisplay: ht16k33: Remove unneeded error check in keypad probe()
On 2021-03-22 15:48, Geert Uytterhoeven wrote: There is no need to check the return code of input_register_device(), just propagate it to the caller. Signed-off-by: Geert Uytterhoeven --- drivers/auxdisplay/ht16k33.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/auxdisplay/ht16k33.c b/drivers/auxdisplay/ht16k33.c index 6d39f12054618fa5..13d18f218b4d196e 100644 --- a/drivers/auxdisplay/ht16k33.c +++ b/drivers/auxdisplay/ht16k33.c @@ -378,11 +378,7 @@ static int ht16k33_keypad_probe(struct i2c_client *client, ht16k33_keypad_stop(keypad->dev); - err = input_register_device(keypad->dev); - if (err) - return err; - - return 0; + return input_register_device(keypad->dev); } static int ht16k33_probe(struct i2c_client *client, Acked-by: Robin van der Gracht
Re: [PATCH 11/17] auxdisplay: ht16k33: Convert to simple i2c probe function
On 2021-03-22 15:48, Geert Uytterhoeven wrote:
ht16k33_probe() does not use the passed i2c_device_id, so the driver
can
be converted trivially to the new-style of i2c probing.
Signed-off-by: Geert Uytterhoeven
---
drivers/auxdisplay/ht16k33.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/auxdisplay/ht16k33.c
b/drivers/auxdisplay/ht16k33.c
index 13d18f218b4d196e..1b67f38109bddba8 100644
--- a/drivers/auxdisplay/ht16k33.c
+++ b/drivers/auxdisplay/ht16k33.c
@@ -381,8 +381,7 @@ static int ht16k33_keypad_probe(struct i2c_client
*client,
return input_register_device(keypad->dev);
}
-static int ht16k33_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
+static int ht16k33_probe(struct i2c_client *client)
{
int err;
uint32_t dft_brightness;
@@ -523,7 +522,7 @@ static const struct of_device_id ht16k33_of_match[]
= {
MODULE_DEVICE_TABLE(of, ht16k33_of_match);
static struct i2c_driver ht16k33_driver = {
- .probe = ht16k33_probe,
+ .probe_new = ht16k33_probe,
.remove = ht16k33_remove,
.driver = {
.name = DRIVER_NAME,
Acked-by: Robin van der Gracht
Re: [PATCH v4 0/4] man2: udpate mm/userfaultfd manpages to latest
On Mon, Mar 22, 2021 at 06:08:44PM -0400, Peter Xu wrote: > v4: > - Fixed a few "subordinate clauses" (SC) cases [Alex] > - Reword in ioctl_userfaultfd.2 to use bold font for the two modes referenced, > so as to be clear on what is "both" referring to [Alex] > > v3: > - Don't use "Currently", instead add "(since x.y)" mark where proper [Alex] > - Always use semantic newlines across the whole patchset [Alex] > - Use quote when possible, rather than escapes [Alex] > - Fix one missing replacement of ".BR" -> ".B" [Alex] > - Some other trivial rephrases here and there when fixing up above > > v2 changes: > - Fix wordings as suggested [MikeR] > - convert ".BR" to ".B" where proper for the patchset [Alex] > - rearrange a few lines in the last two patches where they got messed up > - document more things, e.g. UFFDIO_COPY_MODE_WP; and also on how to resolve a > wr-protect page fault. > > There're two features missing in current manpage, namely: > > (1) Userfaultfd Thread-ID feature > (2) Userfaultfd write protect mode > > There's also a 3rd one which was just contributed from Axel - Axel, I think it > would be great if you can add that part too, probably after the whole > hugetlbfs/shmem minor mode reaches the linux master branch. > > Please review, thanks. > > Peter Xu (4): > userfaultfd.2: Add UFFD_FEATURE_THREAD_ID docs > userfaultfd.2: Add write-protect mode > ioctl_userfaultfd.2: Add UFFD_FEATURE_THREAD_ID docs > ioctl_userfaultfd.2: Add write-protect mode docs > > man2/ioctl_userfaultfd.2 | 89 - > man2/userfaultfd.2 | 117 ++- > 2 files changed, 201 insertions(+), 5 deletions(-) Acked-by: Mike Rapoport > -- > 2.26.2 > > -- Sincerely yours, Mike.
[PATCH net-next 1/1] net: phy: marvell10g: Add PHY loopback support for 88E2110 PHY
From: Tan Tee Min
Add support for PHY loopback for the Marvell 88E2110 PHY.
This allow user to perform selftest using ethtool.
Signed-off-by: Tan Tee Min
Signed-off-by: Wong Vee Khee
---
drivers/net/phy/marvell10g.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/net/phy/marvell10g.c b/drivers/net/phy/marvell10g.c
index b1bb9b8e1e4e..c45a8f11bdcf 100644
--- a/drivers/net/phy/marvell10g.c
+++ b/drivers/net/phy/marvell10g.c
@@ -89,6 +89,8 @@ enum {
MV_V2_TEMP_CTRL_DISABLE = 0xc000,
MV_V2_TEMP = 0xf08c,
MV_V2_TEMP_UNKNOWN = 0x9600, /* unknown function */
+
+ MV_LOOPBACK = BIT(14), /* Loopback (88E2110 only) */
};
struct mv3310_priv {
@@ -765,6 +767,15 @@ static int mv3310_set_tunable(struct phy_device *phydev,
}
}
+static int mv3310_loopback(struct phy_device *phydev, bool enable)
+{
+ if (phydev->drv->phy_id != MARVELL_PHY_ID_88E2110)
+ return -EOPNOTSUPP;
+
+ return phy_modify_mmd(phydev, MDIO_MMD_PCS, MV_PCS_BASE_T,
+ MV_LOOPBACK, enable ? MV_LOOPBACK : 0);
+}
+
static struct phy_driver mv3310_drivers[] = {
{
.phy_id = MARVELL_PHY_ID_88X3310,
@@ -796,6 +807,7 @@ static struct phy_driver mv3310_drivers[] = {
.get_tunable= mv3310_get_tunable,
.set_tunable= mv3310_set_tunable,
.remove = mv3310_remove,
+ .set_loopback = mv3310_loopback,
},
};
--
2.25.1
Re: [RFC PATCH] autofs: find_autofs_mount overmounted parent support
On Tue, 2021-03-09 at 13:43 +0300, Alexander Mikhalitsyn wrote:
> On Sat, 06 Mar 2021 17:13:32 +0800
> Ian Kent wrote:
>
> > On Fri, 2021-03-05 at 14:55 +0300, Alexander Mikhalitsyn wrote:
> > > On Fri, 05 Mar 2021 18:10:02 +0800
> > > Ian Kent wrote:
> > >
> > > > On Thu, 2021-03-04 at 13:11 +0300, Alexander Mikhalitsyn wrote:
> > > > > On Thu, 04 Mar 2021 14:54:11 +0800
> > > > > Ian Kent wrote:
> > > > >
> > > > > > On Wed, 2021-03-03 at 18:28 +0300, Alexander Mikhalitsyn
> > > > > > wrote:
> > > > > > > It was discovered that find_autofs_mount() function
> > > > > > > in autofs not support cases when autofs mount
> > > > > > > parent is overmounted. In this case this function will
> > > > > > > always return -ENOENT.
> > > > > >
> > > > > > Ok, I get this shouldn't happen.
> > > > > >
> > > > > > > Real-life reproducer is fairly simple.
> > > > > > > Consider the following mounts on root mntns:
> > > > > > > --
> > > > > > > 35 24 0:36 / /proc/sys/fs/binfmt_misc ... shared:16 -
> > > > > > > autofs
> > > > > > > systemd-
> > > > > > > 1 ...
> > > > > > > 654 35 0:57 / /proc/sys/fs/binfmt_misc ... shared:322 -
> > > > > > > binfmt_misc
> > > > > > > ...
> > > > > > > --
> > > > > > > and some process which calls
> > > > > > > ioctl(AUTOFS_DEV_IOCTL_OPENMOUNT)
> > > > > > > $ unshare -m -p --fork --mount-proc ./process-bin
> > > > > > >
> > > > > > > Due to "mount-proc" /proc will be overmounted and
> > > > > > > ioctl() will fail with -ENOENT
> > > > > >
> > > > > > I think I need a better explanation ...
> > > > >
> > > > > Thank you for the quick reply, Ian.
> > > > > I'm sorry If my patch description was not sufficiently clear
> > > > > and
> > > > > detailed.
> > > > >
> > > > > That problem connected with CRIU (Checkpoint-Restore in
> > > > > Userspace)
> > > > > project.
> > > > > In CRIU we have support of autofs mounts C/R. To acheive that
> > > > > we
> > > > > need
> > > > > to use
> > > > > ioctl's from /dev/autofs to get data about mounts, restore
> > > > > mount
> > > > > as
> > > > > catatonic
> > > > > (if needed), change pipe fd and so on. But the problem is
> > > > > that
> > > > > during
> > > > > CRIU
> > > > > dump we may meet situation when VFS subtree where autofs
> > > > > mount
> > > > > present was
> > > > > overmounted as whole.
> > > > >
> > > > > Simpliest example is /proc/sys/fs/binfmt_misc. This mount
> > > > > present
> > > > > on
> > > > > most
> > > > > GNU/Linux distributions by default. For instance on my Fedora
> > > > > 33:
> > > >
> > > > Yes, I don't know why systemd uses this direct mount, there
> > > > must
> > > > have been a reason for it.
> > > >
> > > > > trigger automount of binfmt_misc
> > > > > $ ls /proc/sys/fs/binfmt_misc
> > > > >
> > > > > $ cat /proc/1/mountinfo | grep binfmt
> > > > > 35 24 0:36 / /proc/sys/fs/binfmt_misc rw,relatime shared:16 -
> > > > > autofs
> > > > > systemd-1 rw,...,direct,pipe_ino=223
> > > > > 632 35 0:56 / /proc/sys/fs/binfmt_misc rw,...,relatime
> > > > > shared:315
> > > > > -
> > > > > binfmt_misc binfmt_misc rw
> > > >
> > > > Yes, I think this looks normal.
> > > >
> > > > > $ sudo unshare -m -p --fork --mount-proc sh
> > > > > # cat /proc/self/mountinfo | grep "/proc"
> > > > > 828 809 0:23 / /proc rw,nosuid,nodev,noexec,relatime - proc
> > > > > proc
> > > > > rw
> > > > > 829 828 0:36 / /proc/sys/fs/binfmt_misc rw,relatime - autofs
> > > > > systemd-
> > > > > 1 rw,...,direct,pipe_ino=223
> > > > > 943 829 0:56 / /proc/sys/fs/binfmt_misc rw,...,relatime -
> > > > > binfmt_misc
> > > > > binfmt_misc rw
> > > > > 949 828 0:57 / /proc rw...,relatime - proc proc rw
> > > >
> > > > Isn't this screwed up, /proc is on top of the binfmt_misc mount
> > > > ...
> > > >
> > > > Is this what's seen from the root namespace?
> > >
> > > No-no, after issuing
> > > $ sudo unshare -m -p --fork --mount-proc sh
> > >
> > > we enter to the pid+mount namespace and:
> > >
> > > # cat /proc/self/mountinfo | grep "/proc"
> > >
> > > So, it's picture from inside namespaces.
> >
> > Ok, so potentially some of those have been propagated from the
> > original mount namespace.
> >
> > It seems to me the sensible thing would be those mounts would
> > not propagate when a new proc has been requested. It doesn't
> > make sense to me to carry around mounts that are not accessible
> > because of something requested by the mount namespace creator.
> >
> > But that's nothing new and isn't likely to change any time soon.
> >
> > > > > As we can see now autofs mount /proc/sys/fs/binfmt_misc is
> > > > > inaccessible.
> > > > > If we do something like:
> > > > >
> > > > > struct autofs_dev_ioctl *param;
> > > > > param = malloc(...);
> > > > > devfd = open("/dev/autofs", O_RDONLY);
> > > > > init_autofs_dev_ioctl(param);
> > > > > param->size = size;
> > > > > strcpy(param->path, "/proc/sys/fs/binfmt_misc");
> > > > > param->openmount.devid = 36;
> > > > > err = ioctl(devfd, AUTOFS_DEV_IOCTL_OPENMOUNT, param)
> > > > >
> > >
Re: [PATCH mfd v1] mfd: Add Renesas Synchronization Management Unit (SMU) support
On Mon, 22 Mar 2021, Min Li wrote: > > > > I'm pretty confused. This has been sent ~6 times already. What is the v1 > > of? > > Is this a different driver? If so, why does it have the same $SUBJECT line? > > > > If this is not actually v1. Please provide a change-log. > > > > > Hi Lee > > Sorry for confusion. This is no version before v1. The reason you saw it > multiple times is because > I was basing the change in the wrong tree and I now I switched it to > > https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/ > > I am wondering if this is the correct tree to submit the patch for MFD? > > So to sum it up, the latest patch is my first version to this tree. Either MFD or -next is fine for MFD-only patches. Has the code changed at all in any of the patches? If so, please provide a change-log, so we can keep up. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH 3/7] mfd: mt6397: Drop of_compatible for regulator
On Fri, 12 Mar 2021, matthias@kernel.org wrote: > From: Matthias Brugger > > For regulators a compatible string is superfluous. Drop the string. > > Signed-off-by: Matthias Brugger > --- > drivers/mfd/mt6397-core.c | 3 --- > 1 file changed, 3 deletions(-) Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [LTP] [f2fs] 02eb84b96b: ltp.swapon03.fail
On 2021/3/11 4:49, Jaegeuk Kim wrote: On 03/10, Huang Jianan wrote: Hi Richard, On 2021/3/9 12:01, Matthew Wilcox wrote: On Tue, Mar 09, 2021 at 10:23:35AM +0800, Weichao Guo wrote: Hi Richard, On 2021/3/8 19:53, Richard Palethorpe wrote: Hello, kern :err : [ 187.461914] F2FS-fs (sda1): Swapfile does not align to section commit 02eb84b96bc1b382dd138bf60724edbefe77b025 Author: huangjia...@oppo.com Date: Mon Mar 1 12:58:44 2021 +0800 f2fs: check if swapfile is section-alligned If the swapfile isn't created by pin and fallocate, it can't be guaranteed section-aligned, so it may be selected by f2fs gc. When gc_pin_file_threshold is reached, the address of swapfile may change, but won't be synchronized to swap_extent, so swap will write to wrong address, which will cause data corruption. Signed-off-by: Huang Jianan Signed-off-by: Guo Weichao Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim The test uses fallocate to preallocate the swap file and writes zeros to it. I'm not sure what pin refers to? 'pin' refers to pinned file feature in F2FS, the LBA(Logical Block Address) of a file is fixed after pinned. Without this operation before fallocate, the LBA may not align with section(F2FS GC unit), some LBA of the file may be changed by F2FS GC in some extreme cases. For this test case, how about pin the swap file before fallocate for F2FS as following: ioctl(fd, F2FS_IOC_SET_PIN_FILE, true); No special ioctl should be needed. f2fs_swap_activate() should pin the file, just like it converts inline inodes and disables compression. Now f2fs_swap_activate() will pin the file. The problem is that when f2fs_swap_activate() is executed, the file has been created and may not be section-aligned. So I think it would be better to consider aligning the swapfile during f2fs_swap_activate()? Does it make sense to reallocate blocks like in f2fs_swap_activate(), set_inode_flag(inode, FI_PIN_FILE); truncate_pagecache(inode, 0); f2fs_truncate_blocks(inode, 0, true); It will corrupt swap header info while relocating whole swapfile... expand_inode_data(); .
Re: GTE - The hardware timestamping engine
On Mon, Mar 22, 2021 at 9:17 PM Dipen Patel wrote: > My follow-up concerns on both Linus's and Kent's feedback: > > 1. Please correct me if I am wrong, lineevent in the gpiolib* is only > serves the userspace clients. > 1.a What about kernel drivers wanting to use this feature for monitoring its > GPIO lines, see gyroscope example somewhere below. In that regards, > lineevent implementation is not sufficient. > 1.b Are you also implying to extend lineevent implementation to kernel > drivers? I was talking about lineevent because you mentioned things like motors and robotics, and those things are traditionally not run in kernelspace because they are not generic hardware that fit in the kernel subsystems. Normally industrial automatic control tasks are run in a userspace thread with some realtime priority. As Kent says, in-kernel events are exclusively using IRQ as mechanism, and should be modeled as IRQs. Then the question is how you join the timestamp with the IRQ. GPIO chips are just some kind of irqchip in this regard, we reuse the irqchip infrastructure in the kernel for all GPIO drivers that generate "events" in response to state transitions on digital lines. > >> And certainly you will also want to use this timestamp for > >> IIO devices? If it is just GPIOs and IRQs today, it will be > >> gyroscopes and accelerometers tomorrow, am I right? > >> > > Gyroscope, accelerometers or any IIO are built on top of i2c/spi and/or GPIOs. > So they are covered as long as they serve as client to GTE framework, For > example, if gyroscope uses GPIO as an interrupt to indicate frame > ready, GTE could timestamp that GPIO as well any IRQs like i2c transaction > complete IRQ. To this to happen, gycroscope then register itself with > GTE framework and enable required signals that it interfaces/interested with. I think there are IIO devices that provide their own hardware timestamp and as such they might want to use that, so the mechanism need to be generic enough that a certain hardware timestamp can be selected sooner or later. But let's not overcomplicate things for now. Yours, Linus Walleij
Re: [PATCH 06/13] usb: xhci-mtk: support ip-sleep wakeup for MT8183
Hi Chunfeng,
I love your patch! Perhaps something to improve:
[auto build test WARNING on usb/usb-testing]
[also build test WARNING on robh/for-next linus/master v5.12-rc4 next-20210323]
[cannot apply to mediatek/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Chunfeng-Yun/dt-bindings-usb-mtk-xhci-support-property-usb2-lpm-disable/20210322-111651
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
usb-testing
config: alpha-allyesconfig (attached as .config)
compiler: alpha-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
#
https://github.com/0day-ci/linux/commit/519248a4690ce1617790e13220fb52badd09b0c9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Chunfeng-Yun/dt-bindings-usb-mtk-xhci-support-property-usb2-lpm-disable/20210322-111651
git checkout 519248a4690ce1617790e13220fb52badd09b0c9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross
ARCH=alpha
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/bits.h:6,
from include/linux/bitops.h:6,
from include/linux/kernel.h:11,
from include/linux/clk.h:13,
from drivers/usb/host/xhci-mtk.c:10:
drivers/usb/host/xhci-mtk.c: In function 'usb_wakeup_ip_sleep_set':
>> include/vdso/bits.h:7:19: warning: conversion from 'long unsigned int' to
>> 'u32' {aka 'unsigned int'} changes value from '18446744073441120320' to
>> '4026536000' [-Woverflow]
7 | #define BIT(nr) (UL(1) << (nr))
| ^
drivers/usb/host/xhci-mtk.c:71:19: note: in expansion of macro 'BIT'
71 | #define WC0_IS_EN BIT(6)
| ^~~
drivers/usb/host/xhci-mtk.c:313:9: note: in expansion of macro 'WC0_IS_EN'
313 | msk = WC0_IS_EN | WC0_IS_C(0xf) | WC0_IS_P;
| ^
vim +7 include/vdso/bits.h
3945ff37d2f48d Vincenzo Frascino 2020-03-20 6
3945ff37d2f48d Vincenzo Frascino 2020-03-20 @7 #define BIT(nr)
(UL(1) << (nr))
3945ff37d2f48d Vincenzo Frascino 2020-03-20 8
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [Linux-stm32] [PATCH v10 22/33] counter: Internalize sysfs interface code
On Mon, Mar 22, 2021 at 05:44:01PM +0100, Fabrice Gasnier wrote:
> On 3/19/21 12:00 PM, William Breathitt Gray wrote:
> > static const struct atmel_tcb_config tcb_rm9200_config = {
> > diff --git a/drivers/counter/stm32-lptimer-cnt.c
> > b/drivers/counter/stm32-lptimer-cnt.c
> > index 13656957c45f..aef78a4217b5 100644
> > --- a/drivers/counter/stm32-lptimer-cnt.c
> > +++ b/drivers/counter/stm32-lptimer-cnt.c
> > @@ -17,6 +17,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > struct stm32_lptim_cnt {
> > struct counter_device counter;
> > @@ -130,32 +131,46 @@ static int stm32_lptim_setup(struct stm32_lptim_cnt
> > *priv, int enable)
> > * +-+--+--+-+--+-+
> > */
> > enum stm32_lptim_cnt_function {
> > - STM32_LPTIM_COUNTER_INCREASE,
> > - STM32_LPTIM_ENCODER_BOTH_EDGE,
> > + STM32_LPTIM_COUNTER_INCREASE = COUNTER_FUNCTION_INCREASE,
> > + STM32_LPTIM_ENCODER_BOTH_EDGE = COUNTER_FUNCTION_QUADRATURE_X4,
>
> Hi William,
>
> I'm wondering if this enum is still necessary. I noticed the enum is
> removed from the 104-quad-8 driver.
Hi Fabrice,
This enum is no longer necessary. I wanted to leave it up to the
maintainers to decide whether to remove any particular enum (or to do
any other sort of code cleanup), so that is why I didn't remove it here.
> > };
> >
> > static const enum counter_function stm32_lptim_cnt_functions[] = {
> > - [STM32_LPTIM_COUNTER_INCREASE] = COUNTER_FUNCTION_INCREASE,
> > - [STM32_LPTIM_ENCODER_BOTH_EDGE] = COUNTER_FUNCTION_QUADRATURE_X4,
> > + STM32_LPTIM_COUNTER_INCREASE,
> > + STM32_LPTIM_ENCODER_BOTH_EDGE,
> > };
> >
> > enum stm32_lptim_synapse_action {
> > + /* Index must match with stm32_lptim_cnt_polarity[] (priv->polarity) */
>
> Arf... I forgot to update this comment in earlier commit:
> d8ac6b4 counter: stm32-lptimer-cnt: remove iio counter abi
>
> "stm32_lptim_cnt_polarity" doesn't exist anymore. So, this comment can
> be updated. This should match the priv->polarity, as it's used to write
> the "CKPOL" bits (e.g. 0x0 for rising, 0x1 falling, 0x2 both).
>
> Or do you wish I send a separate patch ?
This is just a simple comment fix so I think it's best to send it as its
own patch to the mailing list.
> > STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE,
> > STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE,
> > STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES,
> > STM32_LPTIM_SYNAPSE_ACTION_NONE,
> > };
> >
> > -static const enum counter_synapse_action stm32_lptim_cnt_synapse_actions[]
> > = {
> > - /* Index must match with stm32_lptim_cnt_polarity[] (priv->polarity) */
> > +static const enum stm32_lptim_synapse_action stm32_lptim_c2l_actions_map[]
> > = {
> > + [COUNTER_SYNAPSE_ACTION_RISING_EDGE] =
> > STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE,
> > + [COUNTER_SYNAPSE_ACTION_FALLING_EDGE] =
> > STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE,
> > + [COUNTER_SYNAPSE_ACTION_BOTH_EDGES] =
> > STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES,
> > + [COUNTER_SYNAPSE_ACTION_NONE] = STM32_LPTIM_SYNAPSE_ACTION_NONE,
> > +};
> > +
> > +static const enum counter_synapse_action stm32_lptim_l2c_actions_map[] = {
> > [STM32_LPTIM_SYNAPSE_ACTION_RISING_EDGE] =
> > COUNTER_SYNAPSE_ACTION_RISING_EDGE,
> > [STM32_LPTIM_SYNAPSE_ACTION_FALLING_EDGE] =
> > COUNTER_SYNAPSE_ACTION_FALLING_EDGE,
> > [STM32_LPTIM_SYNAPSE_ACTION_BOTH_EDGES] =
> > COUNTER_SYNAPSE_ACTION_BOTH_EDGES,
> > [STM32_LPTIM_SYNAPSE_ACTION_NONE] = COUNTER_SYNAPSE_ACTION_NONE,
> > };
> >
> > +static const enum counter_synapse_action stm32_lptim_cnt_synapse_actions[]
> > = {
> > + COUNTER_SYNAPSE_ACTION_RISING_EDGE,
> > + COUNTER_SYNAPSE_ACTION_FALLING_EDGE,
> > + COUNTER_SYNAPSE_ACTION_BOTH_EDGES,
> > + COUNTER_SYNAPSE_ACTION_NONE,
> > +};
> > +
>
> I'm getting confused with the two table entries, and the two enums that
> are very similar. Could it be simplified ?
>
> I'm thinking of something more straight-forward... in fact only one
> array should be enough, to convert from synapse action to CKPOL value
> before it's written to register in stm32_lptim_setup() routine.
> This should be easier now that the iio part has been removed.
Yes, this might just be a hold over from when we had to handle the
legacy IIO Counter code. But now that it is gone, this could probably be
simplified down to a single array then. If you have any idea of how to
achieve that, please do.
> > @@ -333,43 +333,39 @@ static int stm32_lptim_cnt_action_get(struct
> > counter_device *counter,
> > }
> > }
> >
> > -static int stm32_lptim_cnt_action_set(struct counter_device *counter,
> > - struct counter_count *count,
> > - struct counter_synapse *synapse,
> > - size_t action)
> > +static int stm32_lptim_cnt_action_write(struct counter_device *counter,
> > + struct counter_count *count,
> >
Re: [PATCH] docs/kokr: make sections on bug reporting match practice
Hello Jon, could I ask you a review for this patch? Thanks, SeongJae Park
Re: [External] Re: [PATCH v5 1/7] mm: memcontrol: slab: fix obtain a reference to a freeing memcg
On Mon, Mar 22, 2021 at 10:46 PM Johannes Weiner wrote:
>
> On Sat, Mar 20, 2021 at 12:38:14AM +0800, Muchun Song wrote:
> > The rcu_read_lock/unlock only can guarantee that the memcg will not be
> > freed, but it cannot guarantee the success of css_get (which is in the
> > refill_stock when cached memcg changed) to memcg.
> >
> > rcu_read_lock()
> > memcg = obj_cgroup_memcg(old)
> > __memcg_kmem_uncharge(memcg)
> > refill_stock(memcg)
> > if (stock->cached != memcg)
> > // css_get can change the ref counter from 0 back to 1.
> > css_get(>css)
> > rcu_read_unlock()
> >
> > This fix is very like the commit:
> >
> > eefbfa7fd678 ("mm: memcg/slab: fix use after free in obj_cgroup_charge")
> >
> > Fix this by holding a reference to the memcg which is passed to the
> > __memcg_kmem_uncharge() before calling __memcg_kmem_uncharge().
> >
> > Fixes: 3de7d4f25a74 ("mm: memcg/slab: optimize objcg stock draining")
> > Signed-off-by: Muchun Song
>
> Acked-by: Johannes Weiner
>
> Good catch! Did you trigger the WARN_ON() in
> percpu_ref_kill_and_confirm() during testing?
No. The race window is very small, it should be difficult to trigger.
When I reviewed the code here, I suddenly realized that there
might be a problem here. Very coincidental.
Thanks.
Re: [PATCH V5 2/2] backlight: qcom-wled: Correct the sync_toggle sequence
On Thu, 18 Mar 2021, Kiran Gunda wrote: > As per the current implementation, after FSC (Full Scale Current) > and brightness update the sync bits are set-then-cleared. > But, the FSC and brightness sync takes place when the sync bits are > set (e.g. on a rising edge). So the hardware team recommends a > clear-then-set approach in order to guarantee such a transition > regardless of the previous register state. > > Signed-off-by: Kiran Gunda > Reviewed-by: Daniel Thompson > --- > drivers/video/backlight/qcom-wled.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) Applied, thanks. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v1 1/3] kernel/resource: make walk_system_ram_res() find all busy IORESOURCE_SYSTEM_RAM resources
On 22.03.21 17:01, David Hildenbrand wrote: It used to be true that we can have busy system RAM only on the first level in the resourc tree. However, this is no longer holds for driver-managed system RAM (i.e., added via dax/kmem and virtio-mem), which gets added on lower levels. We have two users of walk_system_ram_res(), which currently only consideres the first level: a) kernel/kexec_file.c:kexec_walk_resources() -- We properly skip IORESOURCE_SYSRAM_DRIVER_MANAGED resources via locate_mem_hole_callback(), so even after this change, we won't be placing kexec images onto dax/kmem and virtio-mem added memory. No change. b) arch/x86/kernel/crash.c:fill_up_crash_elf_data() -- we're currently not adding relevant ranges to the crash elf info, resulting in them not getting dumped via kdump. This change fixes loading a crashkernel via kexec_file_load() and including dax/kmem and virtio-mem added System RAM in the crashdump on x86-64. Note that e.g,, arm64 relies on memblock data and, therefore, always considers all added System RAM already. Let's find all busy IORESOURCE_SYSTEM_RAM resources, making the function behave like walk_system_ram_range(). Cc: Andrew Morton Cc: Greg Kroah-Hartman Cc: Dan Williams Cc: Daniel Vetter Cc: Andy Shevchenko Cc: Mauro Carvalho Chehab Cc: Signed-off-by: David Hildenbrand ^ My copy-paste action when creating the cc list slipped in a duplicate SO in all 3 patches. I can resend if desired. -- Thanks, David / dhildenb
Re: drivers/opp/of.c:959:12: warning: stack frame size of 1056 bytes in function '_of_add_table_indexed'
On 3/23/21 3:25 PM, Viresh Kumar wrote: On 23-03-21, 15:23, kernel test robot wrote: Hi Viresh, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 84196390620ac0e5070ae36af84c137c6216a7dc commit: 406e47652161d4f0d9bc4cd6237b36c51497ec75 opp: Create _of_add_table_indexed() to reduce code duplication date: 7 weeks ago config: powerpc64-randconfig-r023-20210323 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 14696baaf4c43fe53f738bc292bbe169eed93d5d) 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 # install powerpc64 cross compiling tool for clang build # apt-get install binutils-powerpc64-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=406e47652161d4f0d9bc4cd6237b36c51497ec75 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 406e47652161d4f0d9bc4cd6237b36c51497ec75 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): drivers/opp/of.c:959:12: warning: stack frame size of 1056 bytes in function '_of_add_table_indexed' [-Wframe-larger-than=] static int _of_add_table_indexed(struct device *dev, int index) ^ 1 warning generated. I have reported this on 1st march as well. Looks to be false positive. Hi Viresh, Thanks for the feedback, we'll stop the bot sending such report again. Best Regards, Rong Chen
Re: [PATCH] mfd: stm32-timers: avoid clearing auto reload register
On Wed, 03 Mar 2021, Fabrice Gasnier wrote:
> The ARR register is cleared unconditionally upon probing, after the maximum
> value has been read. This initial condition is rather not intuitive, when
> considering the counter child driver. It rather expects the maximum value
> by default:
> - The counter interface shows a zero value by default for 'ceiling'
> attribute.
> - Enabling the counter without any prior configuration makes it doesn't
> count.
>
> The reset value of ARR register is the maximum. So Choice here
> is to backup it, and restore it then, instead of clearing its value.
> It also fixes the initial condition seen by the counter driver.
>
> Fixes: d0f949e220fd ("mfd: Add STM32 Timers driver")
>
> Signed-off-by: Fabrice Gasnier
> ---
> drivers/mfd/stm32-timers.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Applied, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
[PATCH V2] octeontx2-af: Few mundane typos fixed
s/preceeds/precedes/ .two different places
s/rsponse/response/
s/cetain/certain/
s/precison/precision/
Fix a sentence construction as per suggestion.
Signed-off-by: Bhaskar Chowdhury
---
Changes from V1:
Bad sentence construction missed my eyes , correced by following
Randy's suggestion.
drivers/net/ethernet/marvell/octeontx2/af/mbox.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
index ea456099b33c..8a6227287e34 100644
--- a/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
+++ b/drivers/net/ethernet/marvell/octeontx2/af/mbox.h
@@ -74,13 +74,13 @@ struct otx2_mbox {
struct otx2_mbox_dev *dev;
};
-/* Header which preceeds all mbox messages */
+/* Header which precedes all mbox messages */
struct mbox_hdr {
u64 msg_size; /* Total msgs size embedded */
u16 num_msgs; /* No of msgs embedded */
};
-/* Header which preceeds every msg and is also part of it */
+/* Header which precedes every msg and is also part of it */
struct mbox_msghdr {
u16 pcifunc; /* Who's sending this msg */
u16 id; /* Mbox message ID */
@@ -277,8 +277,8 @@ struct msg_req {
struct mbox_msghdr hdr;
};
-/* Generic rsponse msg used a ack or response for those mbox
- * messages which doesn't have a specific rsp msg format.
+/* Generic response msg used an ack or response for those mbox
+ * messages which don't have a specific rsp msg format.
*/
struct msg_rsp {
struct mbox_msghdr hdr;
@@ -299,7 +299,7 @@ struct ready_msg_rsp {
/* Structure for requesting resource provisioning.
* 'modify' flag to be used when either requesting more
- * or to detach partial of a cetain resource type.
+ * or to detach partial of a certain resource type.
* Rest of the fields specify how many of what type to
* be attached.
* To request LFs from two blocks of same type this mailbox
@@ -489,7 +489,7 @@ struct cgx_set_link_mode_rsp {
};
#define RVU_LMAC_FEAT_FC BIT_ULL(0) /* pause frames */
-#define RVU_LMAC_FEAT_PTP BIT_ULL(1) /* precison time protocol */
+#define RVU_LMAC_FEAT_PTP BIT_ULL(1) /* precision time protocol */
#define RVU_MAC_VERSIONBIT_ULL(2)
#define RVU_MAC_CGXBIT_ULL(3)
#define RVU_MAC_RPMBIT_ULL(4)
--
2.31.0
Re: [PATCH v2] usb: Add a lock when freeing data in usbtmc_disconnect
On Tue, Mar 23, 2021 at 02:28:54AM -0700, Lv Yunlong wrote: > In usbtmc_disconnect, data is got from intf with the initial reference. > There is no refcount inc operation before usbmc_free_int(data). In > usbmc_free_int(data), the data may be freed. > > But later in usbtmc_disconnect, there is another put function of data. > It could cause errors in race. > > My patch adds a lock to protect kref from changing in race. > > Signed-off-by: Lv Yunlong > --- > drivers/usb/class/usbtmc.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c > index 74d5a9c5238a..44f1fcabbb1e 100644 > --- a/drivers/usb/class/usbtmc.c > +++ b/drivers/usb/class/usbtmc.c > @@ -2493,8 +2493,13 @@ static void usbtmc_disconnect(struct usb_interface > *intf) > usb_scuttle_anchored_urbs(_data->in_anchor); > } > mutex_unlock(>io_mutex); > + > + spinlock_t *dev_lock = >dev_lock; > + > + spin_lock_irq(dev_lock); > usbtmc_free_int(data); > kref_put(>kref, usbtmc_delete); > + spin_unlock_irq(dev_lock); > } > > static void usbtmc_draw_down(struct usbtmc_file_data *file_data) > -- > 2.25.1 You obviously did not even build this patch, let alone test it :( Please do not waste maintainer's time by not doing the proper steps when submitting patches. thanks, greg k-h
Re: [PATCH v6 20/24] iio: buffer: add ioctl() to support opening extra buffers for IIO device
On Sun, Mar 21, 2021 at 7:37 PM Jonathan Cameron
wrote:
>
> On Sat, 20 Mar 2021 17:41:00 +
> Jonathan Cameron wrote:
>
> > On Mon, 15 Mar 2021 09:58:08 +
> > "Sa, Nuno" wrote:
> >
> > > > -Original Message-
> > > > From: Alexandru Ardelean
> > > > Sent: Saturday, March 6, 2021 6:01 PM
> > > > To: Jonathan Cameron
> > > > Cc: Lars-Peter Clausen ; Ardelean,
> > > > Alexandru ; LKML > > > ker...@vger.kernel.org>; linux-iio ;
> > > > Hennerich, Michael ; Jonathan
> > > > Cameron ; Sa, Nuno ;
> > > > Bogdan, Dragos
> > > > Subject: Re: [PATCH v6 20/24] iio: buffer: add ioctl() to support
> > > > opening
> > > > extra buffers for IIO device
> > > >
> > > > [External]
> > > >
> > > > On Sun, Feb 28, 2021 at 9:00 PM Jonathan Cameron
> > > > wrote:
> > > > >
> > > > > On Sun, 28 Feb 2021 16:51:51 +0100
> > > > > Lars-Peter Clausen wrote:
> > > > >
> > > > > > On 2/28/21 3:34 PM, Jonathan Cameron wrote:
> > > > > > > On Sun, 28 Feb 2021 09:51:38 +0100
> > > > > > > Lars-Peter Clausen wrote:
> > > > > > >
> > > > > > >> On 2/15/21 11:40 AM, Alexandru Ardelean wrote:
> > > > > > >>> With this change, an ioctl() call is added to open a character
> > > > device for a
> > > > > > >>> buffer. The ioctl() number is 'i' 0x91, which follows the
> > > > > > >>> IIO_GET_EVENT_FD_IOCTL ioctl.
> > > > > > >>>
> > > > > > >>> The ioctl() will return an FD for the requested buffer index.
> > > > The indexes
> > > > > > >>> are the same from the /sys/iio/devices/iio:deviceX/bufferY
> > > > (i.e. the Y
> > > > > > >>> variable).
> > > > > > >>>
> > > > > > >>> Since there doesn't seem to be a sane way to return the FD for
> > > > buffer0 to
> > > > > > >>> be the same FD for the /dev/iio:deviceX, this ioctl() will
> > > > > > >>> return
> > > > another
> > > > > > >>> FD for buffer0 (or the first buffer). This duplicate FD will be
> > > > able to
> > > > > > >>> access the same buffer object (for buffer0) as accessing
> > > > directly the
> > > > > > >>> /dev/iio:deviceX chardev.
> > > > > > >>>
> > > > > > >>> Also, there is no IIO_BUFFER_GET_BUFFER_COUNT ioctl()
> > > > implemented, as the
> > > > > > >>> index for each buffer (and the count) can be deduced from
> > > > the
> > > > > > >>> '/sys/bus/iio/devices/iio:deviceX/bufferY' folders (i.e the
> > > > number of
> > > > > > >>> bufferY folders).
> > > > > > >>>
> > > > > > >>> Used following C code to test this:
> > > > > > >>> ---
> > > > > > >>>
> > > > > > >>>#include
> > > > > > >>>#include
> > > > > > >>>#include
> > > > > > >>>#include
> > > > > > >>>#include > > > > > >>>#include
> > > > > > >>>
> > > > > > >>>#define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int)
> > > > > > >>>
> > > > > > >>> int main(int argc, char *argv[])
> > > > > > >>> {
> > > > > > >>> int fd;
> > > > > > >>> int fd1;
> > > > > > >>> int ret;
> > > > > > >>>
> > > > > > >>> if ((fd = open("/dev/iio:device0", O_RDWR))<0) {
> > > > > > >>> fprintf(stderr, "Error open() %d errno
> > > > > > >>> %d\n",fd,
> > > > errno);
> > > > > > >>> return -1;
> > > > > > >>> }
> > > > > > >>>
> > > > > > >>> fprintf(stderr, "Using FD %d\n", fd);
> > > > > > >>>
> > > > > > >>> fd1 = atoi(argv[1]);
> > > > > > >>>
> > > > > > >>> ret = ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, );
> > > > > > >>> if (ret < 0) {
> > > > > > >>> fprintf(stderr, "Error for buffer %d ioctl()
> > > > > > >>> %d errno
> > > > %d\n", fd1, ret, errno);
> > > > > > >>> close(fd);
> > > > > > >>> return -1;
> > > > > > >>> }
> > > > > > >>>
> > > > > > >>> fprintf(stderr, "Got FD %d\n", fd1);
> > > > > > >>>
> > > > > > >>> close(fd1);
> > > > > > >>> close(fd);
> > > > > > >>>
> > > > > > >>> return 0;
> > > > > > >>> }
> > > > > > >>> ---
> > > > > > >>>
> > > > > > >>> Results are:
> > > > > > >>> ---
> > > > > > >>># ./test 0
> > > > > > >>>Using FD 3
> > > > > > >>>Got FD 4
> > > > > > >>>
> > > > > > >>># ./test 1
> > > > > > >>>Using FD 3
> > > > > > >>>Got FD 4
> > > > > > >>>
> > > > > > >>># ./test 2
> > > > > > >>>Using FD 3
> > > > > > >>>Got FD 4
> > > > > > >>>
> > > > > > >>># ./test 3
> > > > > > >>>Using FD 3
> > > > > > >>>Got FD 4
> > > > > > >>>
> > > > > > >>># ls /sys/bus/iio/devices/iio\:device0
> > > > > > >>>buffer buffer0 buffer1 buffer2 buffer3 dev
> > > > > > >>>in_voltage_sampling_frequency in_voltage_scale
> > > > > > >>>in_voltage_scale_available
> > > > > > >>>name of_node power scan_elements subsystem uevent
> > > > > > >>>
Re: [PATCH v2 10/17] gpio: support ROHM BD71815 GPOs
On Tue, 2021-01-19 at 12:07 +0100, Bartosz Golaszewski wrote: > On Tue, Jan 19, 2021 at 8:23 AM Matti Vaittinen > wrote: > > Support GPO(s) found from ROHM BD71815 power management IC. The IC > > has two > > GPO pins but only one is properly documented in data-sheet. The > > driver > > exposes by default only the documented GPO. The second GPO is > > connected to > > E5 pin and is marked as GND in data-sheet. Control for this > > undocumented > > pin can be enabled using a special DT property. > > > > This driver is derived from work by Peter Yang < > > yang...@embest-tech.com> > > although not so much of original is left. > > > > Signed-off-by: Matti Vaittinen > > Hi Matti, > > looks great, just a couple nits. Hello Bartosz, I think fixed all the nits to v3. Can I translate this to an ack? (I will respin the series as I guess the regulator part may have fallen through the cracks so I'd like to add the relevant acks :] ) Best Regards Matti Vaittinen
Re: GTE - The hardware timestamping engine
On Tue, Mar 23, 2021 at 10:08:00AM +0100, Linus Walleij wrote: > On Mon, Mar 22, 2021 at 9:17 PM Dipen Patel wrote: > > > My follow-up concerns on both Linus's and Kent's feedback: > > > > 1. Please correct me if I am wrong, lineevent in the gpiolib* is only > > serves the userspace clients. > > 1.a What about kernel drivers wanting to use this feature for monitoring its > > GPIO lines, see gyroscope example somewhere below. In that regards, > > lineevent implementation is not sufficient. > > 1.b Are you also implying to extend lineevent implementation to kernel > > drivers? > > I was talking about lineevent because you mentioned things like > motors and robotics, and those things are traditionally not run in > kernelspace because they are not generic hardware that fit in the > kernel subsystems. > > Normally industrial automatic control tasks are run in a userspace > thread with some realtime priority. > > As Kent says, in-kernel events are exclusively using IRQ as > mechanism, and should be modeled as IRQs. Then the question > is how you join the timestamp with the IRQ. GPIO chips are > just some kind of irqchip in this regard, we reuse the irqchip > infrastructure in the kernel for all GPIO drivers that generate > "events" in response to state transitions on digital lines. One potential problem I see with this is that Kent's proposal, if I understand correctly, would supplant the original IRQ of a device with the GTE IRQ for the corresponding event. I'm not sure that's desirable because that would require modifying the device tree and would no longer accurately represent the hardware. Timestamping also sounds like something that drivers would want to opt into, and requiring people to update the device tree to achieve this just doesn't seem reasonable. This proposal would also only work if there's a 1:1 correspondence between hardware IRQ and GTE IRQ. However, as Dipen mentioned, the GTE events can be configured with a threshold, so a GTE IRQ might only trigger every, say, 5th hardware IRQ. I'm not sure if those are common use-cases, though. Obviously if we don't integrate this with IRQs directly, it becomes a bit more difficult to relate the captured timestamps to the events across subsystem boundaries. I'm not sure how this would be solved properly. If the events are sufficiently rare, and it's certain that none will be missed, then it should be possible to just pull a timestamp from the timestamp FIFO for each event. All of that said, I wonder if perhaps hierarchical IRQ domains can somehow be used for this. We did something similar on Tegra not too long ago for wake events, which are basically IRQs exposed by a parent IRQ chip that allows waking up from system sleep. There are some similarities between that and GTE in that the wake events also map to a subset of GPIOs and IRQs and provide additional functionalities on top. I managed to mess up the implementation and Marc stepped in to clean things up, so Cc'ing him since he's clearly more familiar with the topic than I am. Thierry signature.asc Description: PGP signature
Re: [PATCH 4.19 00/43] 4.19.183-rc1 review
On Mon, 22 Mar 2021 at 18:20, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.183 release. > There are 43 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed, 24 Mar 2021 12:19:09 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.183-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h > Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.19.183-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: 155590e98805144ae9800805ca98d3edcd2228de git describe: v4.19.182-44-g155590e98805 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.182-44-g155590e98805 No regressions (compared to build v4.19.182) No fixes (compared to build v4.19.182) Ran 55402 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - juno-r2-compat - juno-r2-kasan - mips - nxp-ls2088 - nxp-ls2088-64k_page_size - powerpc - qemu-arm-debug - qemu-arm64-clang - qemu-arm64-debug - qemu-arm64-kasan - qemu-i386-debug - qemu-x86_64-clang - qemu-x86_64-debug - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - s390 - sparc - x15 - arm - x86_64 - x86-kasan - x86_64 Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * kselftest- * kselftest-android * kselftest-bpf * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-intel_pstate * kselftest-kvm * kselftest-livepatch * kselftest-lkdtm * kselftest-net * kselftest-netfilter * kselftest-nsfs * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-zram * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-tracing-tests * v4l2-compliance * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-lib * kselftest-membarrier * kselftest-memfd * kselftest-memory-hotplug * kselftest-mincore * kselftest-mount * kselftest-mqueue * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kvm-unit-tests * ltp-fs-tests * network-basic-tests * perf * kselftest-kexec * kselftest-vm * kselftest-x86 * ltp-open-posix-tests * ltp-syscalls-tests * fwts * rcutorture * igt-gpu-tools * ssuite * kselftest-vsyscall-mode-native- * kselftest-vsyscall-mode-none- -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH RFC v2 8/8] selftests/perf: Add kselftest for remove_on_exec
On Tue, Mar 23, 2021 at 10:52:41AM +0100, Marco Elver wrote:
> with efs->func==__perf_event_enable. I believe it's sufficient to add
>
> mutex_lock(_event->child_mutex);
> list_del_init(>child_list);
> mutex_unlock(_event->child_mutex);
>
> right before removing from context. With the version I have now (below
> for completeness), extended torture with the above test results in no
> more warnings and the test also passes.
>
> + list_for_each_entry_safe(event, next, >event_list, event_entry) {
> + struct perf_event *parent_event = event->parent;
> +
> + if (!event->attr.remove_on_exec)
> continue;
>
> + if (!is_kernel_event(event))
> + perf_remove_from_owner(event);
>
> + modified = true;
> +
> + if (parent_event) {
> /*
> + * Remove event from parent, to avoid race where the
> + * parent concurrently iterates through its children to
> + * enable, disable, or otherwise modify an event.
>*/
> + mutex_lock(_event->child_mutex);
> + list_del_init(>child_list);
> + mutex_unlock(_event->child_mutex);
> }
^^^ this, right?
But that's something perf_event_exit_event() alread does. So then you're
worried about the order of things.
> +
> + perf_remove_from_context(event, !!event->parent * DETACH_GROUP);
> + perf_event_exit_event(event, ctx, current, true);
> }
perf_event_release_kernel() first does perf_remove_from_context() and
then clears the child_list, and that makes sense because if we're there,
there's no external access anymore, the filedesc is gone and nobody will
be iterating child_list anymore.
perf_event_exit_task_context() and perf_event_exit_event() OTOH seem to
rely on ctx->task == TOMBSTONE to sabotage event_function_call() such
that if anybody is iterating the child_list, it'll NOP out.
But here we don't have neither, and thus need to worry about the order
vs child_list iteration.
I suppose we should stick sync_child_event() in there as well.
And at that point there's very little value in still using
perf_event_exit_event()... let me see if there's something to be done
about that.
Re: [PATCH v1 1/5] mfd: intel_quark_i2c_gpio: revert "Constify static struct resources"
On Tue, Mar 23, 2021 at 09:14:53AM +, Lee Jones wrote:
> On Tue, 02 Mar 2021, Andy Shevchenko wrote:
>
> > The structures are used as place holders, so they are modified at run-time.
> > Obviously they may not be constants.
> >
> > BUG: unable to handle page fault for address: d0643220
> > ...
> > CPU: 0 PID: 110 Comm: modprobe Not tainted 5.11.0+ #1
> > Hardware name: Intel Corp. QUARK/GalileoGen2, BIOS 0x01000200 01/01/2014
> > EIP: intel_quark_mfd_probe+0x93/0x1c0 [intel_quark_i2c_gpio]
> >
> > This partially reverts the commit c4a164f41554d2899bed94bdcc499263f41787b4.
> >
> > While at it, add a comment to avoid similar changes in the future.
> >
> > Fixes: c4a164f41554 ("mfd: Constify static struct resources")
> > Cc: Rikard Falkeborn
> > Signed-off-by: Andy Shevchenko
> > ---
> > drivers/mfd/intel_quark_i2c_gpio.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
>
> Applied to -fixes for testing, thanks.
Thanks!
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v1 5/5] mfd: intel_quark_i2c_gpio: Reuse BAR definitions for MFD cell indexing
On Tue, Mar 23, 2021 at 09:20:57AM +, Lee Jones wrote:
> On Tue, 02 Mar 2021, Andy Shevchenko wrote:
>
> > It's convenient and less error prone to use definitions to address
> > different cells in an array. For this purpose we may reuse existing
> > BAR definitions.
...
> > + {
> > + .id = MFD_GPIO_BAR,
> > + .name = "gpio-dwapb",
> > + .acpi_match = _quark_acpi_match_gpio,
> > + .num_resources = ARRAY_SIZE(intel_quark_gpio_res),
> > + .resources = intel_quark_gpio_res,
> > + .ignore_resource_conflicts = true,
> > + },
> > };
>
> I would make this more explicit.
>
> [MFD_I2C_BAR] = { }
>
> If someone comes along and re-reorders these, it will break.
Agree.
Will do for v2.
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v4 net-next 02/11] net: bridge: add helper to retrieve the current ageing time
On 23/03/2021 01:51, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The SWITCHDEV_ATTR_ID_BRIDGE_AGEING_TIME attribute is only emitted from:
>
> sysfs/ioctl/netlink
> -> br_set_ageing_time
>-> __set_ageing_time
>
> therefore not at bridge port creation time, so:
> (a) switchdev drivers have to hardcode the initial value for the address
> ageing time, because they didn't get any notification
> (b) that hardcoded value can be out of sync, if the user changes the
> ageing time before enslaving the port to the bridge
>
> We need a helper in the bridge, such that switchdev drivers can query
> the current value of the bridge ageing time when they start offloading
> it.
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Florian Fainelli
> Reviewed-by: Tobias Waldekranz
> ---
> include/linux/if_bridge.h | 6 ++
> net/bridge/br_stp.c | 13 +
> 2 files changed, 19 insertions(+)
>
The patch is mostly fine, there are a few minor nits (const qualifiers). If
there
is another version of the patch-set please add them, either way:
Acked-by: Nikolay Aleksandrov
> diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
> index 920d3a02cc68..ebd16495459c 100644
> --- a/include/linux/if_bridge.h
> +++ b/include/linux/if_bridge.h
> @@ -137,6 +137,7 @@ struct net_device *br_fdb_find_port(const struct
> net_device *br_dev,
> void br_fdb_clear_offload(const struct net_device *dev, u16 vid);
> bool br_port_flag_is_set(const struct net_device *dev, unsigned long flag);
> u8 br_port_get_stp_state(const struct net_device *dev);
> +clock_t br_get_ageing_time(struct net_device *br_dev);
> #else
> static inline struct net_device *
> br_fdb_find_port(const struct net_device *br_dev,
> @@ -160,6 +161,11 @@ static inline u8 br_port_get_stp_state(const struct
> net_device *dev)
> {
> return BR_STATE_DISABLED;
> }
> +
> +static inline clock_t br_get_ageing_time(struct net_device *br_dev)
const
> +{
> + return 0;
> +}
> #endif
>
> #endif
> diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
> index 86b5e05d3f21..3dafb6143cff 100644
> --- a/net/bridge/br_stp.c
> +++ b/net/bridge/br_stp.c
> @@ -639,6 +639,19 @@ int br_set_ageing_time(struct net_bridge *br, clock_t
> ageing_time)
> return 0;
> }
>
> +clock_t br_get_ageing_time(struct net_device *br_dev)
const
> +{
> + struct net_bridge *br;
const
> +
> + if (!netif_is_bridge_master(br_dev))
> + return 0;
> +
> + br = netdev_priv(br_dev);
> +
> + return jiffies_to_clock_t(br->ageing_time);
> +}
> +EXPORT_SYMBOL_GPL(br_get_ageing_time);
> +
> /* called under bridge lock */
> void __br_set_topology_change(struct net_bridge *br, unsigned char val)
> {
>
Re: [RFC PATCH v2 3/8] arm64: Terminate the stack trace at TASK_FRAME and EL0_FRAME
On Thu, Mar 18, 2021 at 03:29:19PM -0500, Madhavan T. Venkataraman wrote:
>
>
> On 3/18/21 1:26 PM, Mark Brown wrote:
> > On Mon, Mar 15, 2021 at 11:57:55AM -0500, madve...@linux.microsoft.com
> > wrote:
> >
> >> + /* Terminal record, nothing to unwind */
> >> + if (fp == (unsigned long) regs->stackframe) {
> >> + if (regs->frame_type == TASK_FRAME ||
> >> + regs->frame_type == EL0_FRAME)
> >> + return -ENOENT;
> >>return -EINVAL;
> >> + }
> >
> > This is conflating the reliable stacktrace checks (which your series
> > will later flag up with frame->reliable) with verifying that we found
> > the bottom of the stack by looking for this terminal stack frame record.
> > For the purposes of determining if the unwinder got to the bottom of the
> > stack we don't care what stack type we're looking at, we just care if it
> > managed to walk to this defined final record.
> >
> > At the minute nothing except reliable stack trace has any intention of
> > checking the specific return code but it's clearer to be consistent.
> >
>
> So, you are saying that the type check is redundant. OK. I will remove it
> and just return -ENOENT on reaching the final record.
Yes please; and please fold that into the same patch that adds the final
records.
Thanks,
Mark.
Re: [PATCH v7 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
On Tue, 23 Mar 2021 at 11:01, Adrien Grassein wrote:
>
> Hey Robert,
>
> Thanks for the update.
>
> Le mar. 23 mars 2021 à 10:10, Robert Foss a écrit :
> >
> > Hey Adrien,
> >
> > Sorry about the slow reply, but I just received the documentation from
> > the vendor. So let's dig in to the HPD issue.
>
> No problem :)
> >
> > > +static enum drm_connector_status lt8912_check_cable_status(struct lt8912
> > > *lt)
> > > +{
> > > + int ret;
> > > + unsigned int reg_val;
> > > +
> > > + ret = regmap_read(lt->regmap[I2C_MAIN], 0xC1, _val);
> > > + if (ret)
> > > + return connector_status_unknown;
> > > +
> > > + if (reg_val & BIT(7))
> > > + return connector_status_connected;
> >
> > Register 0xc0 & BIT(7) - HPD signal after debounce
> > Register 0xc0 & BIT(6) - HPD signal for TX HPD pad
>
> So, if I understand well, I need to write 0xc0 & BIT(6) with 1 to
> enable the HPD pin.
Ah, sorry about being a bit terse.
Both bit 6 & 7 are read only, and are probably best read after an IRQ.
> >
> > > +
> > > +static int lt8912_probe(struct i2c_client *client,
> > > +const struct i2c_device_id *id)
> > > +{
> > > + static struct lt8912 *lt;
> > > + int ret = 0;
> > > + struct device *dev = >dev;
> > > +
> > > + lt = devm_kzalloc(dev, sizeof(struct lt8912), GFP_KERNEL);
> > > + if (!lt)
> > > + return -ENOMEM;
> > > +
> > > + lt->dev = dev;
> > > + lt->i2c_client[0] = client;
> > > + lt->cable_status = connector_status_unknown;
> > > + lt->workq = create_workqueue("lt8912_workq");
> >
> > Looking at [1] and maybe even better [2], I think this polling
> > approach is the wrong way to go. And with access to documentation, I
> > think we should be able to sort this out.
>
> I neither like the polling approach too. I did it to go on this issue.
> I will totally remove it once the HPD issue will be resolved.
> >
> > Using the irq driver approach requires the interrupt pin to be
> > configured. Pin 63 of the lt8912b is the IRQ output pin.
> >
> > In order to trigger interrupts based on it, the dt-binding would need
> > to be updated[3][4] as well as whichever DTS you're using.
> >
>
> The IRQ part is working well in my DTB. It test it by adding some
> electronics to emulate the HPD pin on the GPIO expander where the HPD
> pin is linked.
Looking at the dt-binding patch, it does not seem to list any
interrupts. So that should be added. I think the irq support from [3]
& [4] can be pretty much copied.
Then we can come back and replace the polling code with the IRQ driven
code from [2].
>
> >
> > [1]
> > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/analogix/anx7625.c#L1751
> >
> > [2]
> > https://github.com/torvalds/linux/blob/v5.11/drivers/gpu/drm/bridge/lontium-lt9611.c#L1160
> >
> > [3]
> > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L27
> >
> > [4]
> > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L144
Re: [PATCH] selftests: kvm: make hardware_disable_test less verbose
Andrew Jones writes: > On Tue, Mar 23, 2021 at 09:53:03AM +0100, Vitaly Kuznetsov wrote: >> hardware_disable_test produces 512 snippets like >> ... >> main: [511] waiting semaphore >> run_test: [511] start vcpus >> run_test: [511] all threads launched >> main: [511] waiting 368us >> main: [511] killing child >> >> and this doesn't have much value, let's just drop these fprintf(). >> Restoring them for debugging purposes shouldn't be too hard. > > Changing them to pr_debug() allows you to keep them and restore > with -DDEBUG Ah, missed that we have this for selftests! v2 is coming. -- Vitaly
Re: [PATCH v5 3/5] mm,memory_hotplug: Add kernel boot option to enable memmap_on_memory
On Fri 19-03-21 10:26:33, Oscar Salvador wrote:
> Self stored memmap leads to a sparse memory situation which is unsuitable
> for workloads that requires large contiguous memory chunks, so make this
> an opt-in which needs to be explicitly enabled.
>
> To control this, let memory_hotplug have its own memory space, as suggested
> by David, so we can add memory_hotplug.memmap_on_memory parameter.
>
> Signed-off-by: Oscar Salvador
> Reviewed-by: David Hildenbrand
Acked-by: Michal Hocko
I would just rephrased the help text to be less low level
> ---
> Documentation/admin-guide/kernel-parameters.txt | 16
> mm/Makefile | 5 -
> mm/memory_hotplug.c | 10 +-
> 3 files changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt
> b/Documentation/admin-guide/kernel-parameters.txt
> index 04545725f187..d29b96e50c5c 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2794,6 +2794,22 @@
> seconds. Use this parameter to check at some
> other rate. 0 disables periodic checking.
>
> + memory_hotplug.memmap_on_memory
> + [KNL,X86,ARM] Boolean flag to enable this feature.
> + Format: {on | off (default)}
> + When enabled, memory to build the pages tables for the
> + memmap array describing the hot-added range will be
> taken
> + from the range itself, so the memmap page tables will be
> + self-hosted.
> + Since only single memory device ranges are supported at
> + the moment, this option is disabled by default because
> + it might have an impact on workloads that needs large
> + contiguous memory chunks.
> + The state of the flag can be read in
> + /sys/module/memory_hotplug/parameters/memmap_on_memory.
> + Note that even when enabled, there are a few cases where
> + the feature is not effective.
> +
When enabled, runtime hotplugged memory will
allocate its internal metadata (struct pages)
from the hotadded memory which will allow to
hotadd a lot of memory without requiring
additional memory to do so.
This feature is disabled by default because it
has some implication on large (e.g. GB)
allocations in some configurations (e.g. small
memory blocks).
> memtest=[KNL,X86,ARM,PPC] Enable memtest
> Format:
> default : 0
> diff --git a/mm/Makefile b/mm/Makefile
> index 72227b24a616..82ae9482f5e3 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -58,9 +58,13 @@ obj-y := filemap.o mempool.o
> oom_kill.o fadvise.o \
> page-alloc-y := page_alloc.o
> page-alloc-$(CONFIG_SHUFFLE_PAGE_ALLOCATOR) += shuffle.o
>
> +# Give 'memory_hotplug' its own module-parameter namespace
> +memory-hotplug-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
> +
> obj-y += page-alloc.o
> obj-y += init-mm.o
> obj-y += memblock.o
> +obj-y += $(memory-hotplug-y)
>
> ifdef CONFIG_MMU
> obj-$(CONFIG_ADVISE_SYSCALLS) += madvise.o
> @@ -83,7 +87,6 @@ obj-$(CONFIG_SLUB) += slub.o
> obj-$(CONFIG_KASAN) += kasan/
> obj-$(CONFIG_KFENCE) += kfence/
> obj-$(CONFIG_FAILSLAB) += failslab.o
> -obj-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
> obj-$(CONFIG_MEMTEST)+= memtest.o
> obj-$(CONFIG_MIGRATION) += migrate.o
> obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o khugepaged.o
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 350cde69a97d..c525e5dab859 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -42,7 +42,15 @@
> #include "internal.h"
> #include "shuffle.h"
>
> -static bool memmap_on_memory;
The memmap_on_memory can be dropped from the 1st patch IIUC and only
introduce it now.
> +
> +/*
> + * memory_hotplug.memmap_on_memory parameter
> + */
> +static bool memmap_on_memory __ro_after_init;
> +#ifdef CONFIG_MHP_MEMMAP_ON_MEMORY
> +module_param(memmap_on_memory, bool, 0444);
> +MODULE_PARM_DESC(memmap_on_memory, "Enable memmap on memory for memory
> hotplug");
> +#endif
I am not very much familiar with the machinery. Does this expose the
state to the userspace?
--
Michal Hocko
SUSE Labs
[PATCH net-next 1/1] net: stmmac: Add hardware supported cross-timestamp
From: Tan Tee Min
Cross timestamping is supported on Integrated Ethernet Controller in
Intel SoC such as EHL and TGL with Always Running Timer.
The hardware cross-timestamp result is made available to
applications through the PTP_SYS_OFFSET_PRECISE ioctl which calls
stmmac_getcrosststamp().
Device time is stored in the MAC Auxiliary register. The 64-bit System
time (ART timestamp) is stored in registers that are only addressable
by using MDIO space.
Signed-off-by: Tan Tee Min
Co-developed-by: Wong Vee Khee
Signed-off-by: Wong Vee Khee
---
drivers/net/ethernet/stmicro/stmmac/common.h | 2 +
.../net/ethernet/stmicro/stmmac/dwmac-intel.c | 108 ++
drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 8 ++
.../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 2 +
drivers/net/ethernet/stmicro/stmmac/hwif.h| 3 +
.../ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 11 ++
.../net/ethernet/stmicro/stmmac/stmmac_ptp.c | 32 ++
.../net/ethernet/stmicro/stmmac/stmmac_ptp.h | 23
include/linux/stmmac.h| 4 +
9 files changed, 193 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 1c0c60bdf854..95469059dca1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -388,6 +388,8 @@ struct dma_features {
unsigned int estsel;
unsigned int fpesel;
unsigned int tbssel;
+ /* Numbers of Auxiliary Snapshot Inputs */
+ unsigned int aux_snapshot_n;
};
/* RX Buffer size must be multiple of 4/8/16 bytes */
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 763b549e3c2d..992294d25706 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -8,6 +8,7 @@
#include "dwmac-intel.h"
#include "dwmac4.h"
#include "stmmac.h"
+#include "stmmac_ptp.h"
#define INTEL_MGBE_ADHOC_ADDR 0x15
#define INTEL_MGBE_XPCS_ADDR 0x16
@@ -240,6 +241,108 @@ static void intel_mgbe_ptp_clk_freq_config(void *npriv)
writel(gpio_value, priv->ioaddr + GMAC_GPIO_STATUS);
}
+static void get_arttime(struct mii_bus *mii, int intel_adhoc_addr,
+ u64 *art_time)
+{
+ u64 ns;
+
+ ns = mdiobus_read(mii, intel_adhoc_addr, PMC_ART_VALUE3);
+ ns <<= GMAC4_ART_TIME_SHIFT;
+ ns |= mdiobus_read(mii, intel_adhoc_addr, PMC_ART_VALUE2);
+ ns <<= GMAC4_ART_TIME_SHIFT;
+ ns |= mdiobus_read(mii, intel_adhoc_addr, PMC_ART_VALUE1);
+ ns <<= GMAC4_ART_TIME_SHIFT;
+ ns |= mdiobus_read(mii, intel_adhoc_addr, PMC_ART_VALUE0);
+
+ *art_time = ns;
+}
+
+static int intel_crosststamp(ktime_t *device,
+struct system_counterval_t *system,
+void *ctx)
+{
+ struct intel_priv_data *intel_priv;
+
+ struct stmmac_priv *priv = (struct stmmac_priv *)ctx;
+ void __iomem *ptpaddr = priv->ptpaddr;
+ void __iomem *ioaddr = priv->hw->pcsr;
+ unsigned long flags;
+ u64 art_time = 0;
+ u64 ptp_time = 0;
+ u32 num_snapshot;
+ u32 gpio_value;
+ u32 acr_value;
+ int ret;
+ u32 v;
+ int i;
+
+ if (!boot_cpu_has(X86_FEATURE_ART))
+ return -EOPNOTSUPP;
+
+ intel_priv = priv->plat->bsp_priv;
+
+ /* Enable Internal snapshot trigger */
+ acr_value = readl(ptpaddr + PTP_ACR);
+ acr_value &= ~PTP_ACR_MASK;
+ switch (priv->plat->int_snapshot_num) {
+ case AUX_SNAPSHOT0:
+ acr_value |= PTP_ACR_ATSEN0;
+ break;
+ case AUX_SNAPSHOT1:
+ acr_value |= PTP_ACR_ATSEN1;
+ break;
+ case AUX_SNAPSHOT2:
+ acr_value |= PTP_ACR_ATSEN2;
+ break;
+ case AUX_SNAPSHOT3:
+ acr_value |= PTP_ACR_ATSEN3;
+ break;
+ default:
+ return -EINVAL;
+ }
+ writel(acr_value, ptpaddr + PTP_ACR);
+
+ /* Clear FIFO */
+ acr_value = readl(ptpaddr + PTP_ACR);
+ acr_value |= PTP_ACR_ATSFC;
+ writel(acr_value, ptpaddr + PTP_ACR);
+
+ /* Trigger Internal snapshot signal
+* Create a rising edge by just toggle the GPO1 to low
+* and back to high.
+*/
+ gpio_value = readl(ioaddr + GMAC_GPIO_STATUS);
+ gpio_value &= ~GMAC_GPO1;
+ writel(gpio_value, ioaddr + GMAC_GPIO_STATUS);
+ gpio_value |= GMAC_GPO1;
+ writel(gpio_value, ioaddr + GMAC_GPIO_STATUS);
+
+ /* Poll for time sync operation done */
+ ret = readl_poll_timeout(priv->ioaddr + GMAC_INT_STATUS, v,
+(v & GMAC_INT_TSIE), 100, 1);
+
+ if (ret == -ETIMEDOUT) {
+ pr_err("%s: Wait for time sync operation timeout\n", __func__);
+ return ret;
+
Re: [PATCH 0/3 v5] Introduce a bulk order-0 page allocator
On Mon, 22 Mar 2021 20:58:27 +
Mel Gorman wrote:
> On Mon, Mar 22, 2021 at 08:32:54PM +, Chuck Lever III wrote:
> > >> It is returning some confusing (to me) results. I'd like
> > >> to get these resolved before posting any benchmark
> > >> results.
> > >>
> > >> 1. When it has visited every array element, it returns the
> > >> same value as was passed in @nr_pages. That's the N + 1th
> > >> array element, which shouldn't be touched. Should the
> > >> allocator return nr_pages - 1 in the fully successful case?
> > >> Or should the documentation describe the return value as
> > >> "the number of elements visited" ?
> > >>
> > >
> > > I phrased it as "the known number of populated elements in the
> > > page_array".
> >
> > The comment you added states:
> >
> > + * For lists, nr_pages is the number of pages that should be allocated.
> > + *
> > + * For arrays, only NULL elements are populated with pages and nr_pages
> > + * is the maximum number of pages that will be stored in the array.
> > + *
> > + * Returns the number of pages added to the page_list or the index of the
> > + * last known populated element of page_array.
> >
> >
> > > I did not want to write it as "the number of valid elements
> > > in the array" because that is not necessarily the case if an array is
> > > passed in with holes in the middle. I'm open to any suggestions on how
> > > the __alloc_pages_bulk description can be improved.
> >
> > The comments states that, for the array case, a /count/ of
> > pages is passed in, and an /index/ is returned. If you want
> > to return the same type for lists and arrays, it should be
> > documented as a count in both cases, to match @nr_pages.
> > Consumers will want to compare @nr_pages with the return
> > value to see if they need to call again.
> >
>
> Then I'll just say it's the known count of pages in the array. That
> might still be less than the number of requested pages if holes are
> encountered.
>
> > > The definition of the return value as-is makes sense for either a list
> > > or an array. Returning "nr_pages - 1" suits an array because it's the
> > > last valid index but it makes less sense when returning a list.
> > >
> > >> 2. Frequently the allocator returns a number smaller than
> > >> the total number of elements. As you may recall, sunrpc
> > >> will delay a bit (via a call to schedule_timeout) then call
> > >> again. This is supposed to be a rare event, and the delay
> > >> is substantial. But with the array-based API, a not-fully-
> > >> successful allocator call seems to happen more than half
> > >> the time. Is that expected? I'm calling with GFP_KERNEL,
> > >> seems like the allocator should be trying harder.
> > >>
> > >
> > > It's not expected that the array implementation would be worse *unless*
> > > you are passing in arrays with holes in the middle. Otherwise, the success
> > > rate should be similar.
> >
> > Essentially, sunrpc will always pass an array with a hole.
> > Each RPC consumes the first N elements in the rq_pages array.
> > Sometimes N == ARRAY_SIZE(rq_pages). AFAIK sunrpc will not
> > pass in an array with more than one hole. Typically:
> >
> > .
> >
> > My results show that, because svc_alloc_arg() ends up calling
> > __alloc_pages_bulk() twice in this case, it ends up being
> > twice as expensive as the list case, on average, for the same
> > workload.
> >
>
> Ok, so in this case the caller knows that holes are always at the
> start. If the API returns an index that is a valid index and populated,
> it can check the next index and if it is valid then the whole array
> must be populated.
>
> Right now, the implementation checks for populated elements at the *start*
> because it is required for calling prep_new_page starting at the correct
> index and the API cannot make assumptions about the location of the hole.
>
> The patch below would check the rest of the array but note that it's
> slower for the API to do this check because it has to check every element
> while the sunrpc user could check one element. Let me know if a) this
> hunk helps and b) is desired behaviour.
>
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c83d38dfe936..4bf20650e5f5 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -5107,6 +5107,9 @@ int __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
> } else {
> while (prep_index < nr_populated)
> prep_new_page(page_array[prep_index++], 0, gfp, 0);
> +
> + while (nr_populated < nr_pages && page_array[nr_populated])
> + nr_populated++;
> }
>
> return nr_populated;
I do know that I suggested moving prep_new_page() out of the
IRQ-disabled loop, but maybe was a bad idea, for several reasons.
All prep_new_page does is to write into struct page, unless some
debugging stuff (like kasan) is enabled. This cache-line is hot as
LRU-list update just wrote into this cache-line. As the
Re: [PATCH v7 2/2] drm/bridge: Introduce LT8912B DSI to HDMI bridge
Le mar. 23 mars 2021 à 11:42, Robert Foss a écrit :
>
> On Tue, 23 Mar 2021 at 11:01, Adrien Grassein
> wrote:
> >
> > Hey Robert,
> >
> > Thanks for the update.
> >
> > Le mar. 23 mars 2021 à 10:10, Robert Foss a écrit :
> > >
> > > Hey Adrien,
> > >
> > > Sorry about the slow reply, but I just received the documentation from
> > > the vendor. So let's dig in to the HPD issue.
> >
> > No problem :)
> > >
> > > > +static enum drm_connector_status lt8912_check_cable_status(struct
> > > > lt8912 *lt)
> > > > +{
> > > > + int ret;
> > > > + unsigned int reg_val;
> > > > +
> > > > + ret = regmap_read(lt->regmap[I2C_MAIN], 0xC1, _val);
> > > > + if (ret)
> > > > + return connector_status_unknown;
> > > > +
> > > > + if (reg_val & BIT(7))
> > > > + return connector_status_connected;
> > >
> > > Register 0xc0 & BIT(7) - HPD signal after debounce
> > > Register 0xc0 & BIT(6) - HPD signal for TX HPD pad
> >
> > So, if I understand well, I need to write 0xc0 & BIT(6) with 1 to
> > enable the HPD pin.
>
> Ah, sorry about being a bit terse.
>
> Both bit 6 & 7 are read only, and are probably best read after an IRQ.
In my case, IRQ is not triggered at all.
When reading the value of the HPD pin, I always get 1 (and no
transition occurs when plugging / unplugging a cable).
The HPD IRQ is done on the HDMI connector driver [5].
I think a register configuration should be done to enable the IRQ pin
or maybe there is a nug in electronics.
The HPD pin is linked to a 2.2k pullup resistor (maybe it's wrong)
>
> > >
> > > > +
> > > > +static int lt8912_probe(struct i2c_client *client,
> > > > +const struct i2c_device_id *id)
> > > > +{
> > > > + static struct lt8912 *lt;
> > > > + int ret = 0;
> > > > + struct device *dev = >dev;
> > > > +
> > > > + lt = devm_kzalloc(dev, sizeof(struct lt8912), GFP_KERNEL);
> > > > + if (!lt)
> > > > + return -ENOMEM;
> > > > +
> > > > + lt->dev = dev;
> > > > + lt->i2c_client[0] = client;
> > > > + lt->cable_status = connector_status_unknown;
> > > > + lt->workq = create_workqueue("lt8912_workq");
> > >
> > > Looking at [1] and maybe even better [2], I think this polling
> > > approach is the wrong way to go. And with access to documentation, I
> > > think we should be able to sort this out.
> >
> > I neither like the polling approach too. I did it to go on this issue.
> > I will totally remove it once the HPD issue will be resolved.
> > >
> > > Using the irq driver approach requires the interrupt pin to be
> > > configured. Pin 63 of the lt8912b is the IRQ output pin.
> > >
> > > In order to trigger interrupts based on it, the dt-binding would need
> > > to be updated[3][4] as well as whichever DTS you're using.
> > >
> >
> > The IRQ part is working well in my DTB. It test it by adding some
> > electronics to emulate the HPD pin on the GPIO expander where the HPD
> > pin is linked.
>
> Looking at the dt-binding patch, it does not seem to list any
> interrupts. So that should be added. I think the irq support from [3]
> & [4] can be pretty much copied.
>
> Then we can come back and replace the polling code with the IRQ driven
> code from [2].
My board uses a "max7323" GPIO expander and the HPD pin is linked to it.
I test this GPIO expander by soldering a pull up resistor and an
interrupt on it and an interrupt was correctly triggered in both
max7323 driver and hdmi-connector;
So I guess that my DTB configuration is correct.
I made my DBT configuration available:
- hdmi-connector node: [6]
- lt8912b node: |7]
- max7323 node: [8].
>
> >
> > >
> > > [1]
> > > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/analogix/anx7625.c#L1751
> > >
> > > [2]
> > > https://github.com/torvalds/linux/blob/v5.11/drivers/gpu/drm/bridge/lontium-lt9611.c#L1160
> > >
> > > [3]
> > > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L27
> > >
> > > [4]
> > > https://github.com/torvalds/linux/blob/v5.11/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml#L144
[5]
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/display-connector.c#L199
[6]
https://github.com/grassead/linux-next/blob/master/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts#L37
[7]
https://github.com/grassead/linux-next/blob/master/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts#L249
[8]
https://github.com/grassead/linux-next/blob/master/arch/arm64/boot/dts/freescale/imx8mq-nitrogen.dts#L291
Thanks,
Re: [PATCH v1 3/3] kernel/resource: remove first_lvl / siblings_only logic
On 23.03.21 12:11, Andy Shevchenko wrote:
On Mon, Mar 22, 2021 at 05:02:00PM +0100, David Hildenbrand wrote:
All IORESOURCE_SYSTEM_RAM and IORESOURCE_MEM now properly consider the
whole resource tree, not just the first level. Let's drop the unused
first_lvl / siblings_only logic.
All functions properly search the whole tree, so remove documentation
that indicates that some functions behave differently.
Like this clean up!
Reviewed-by: Andy Shevchenko
Although a few nit-picks below.
Cc: Andrew Morton
Cc: Greg Kroah-Hartman
Cc: Dan Williams
Cc: Daniel Vetter
Cc: Andy Shevchenko
Cc: Mauro Carvalho Chehab
Cc: Signed-off-by: David Hildenbrand
Cc: Dave Young
Cc: Baoquan He
Cc: Vivek Goyal
Cc: Dave Hansen
Cc: Keith Busch
Cc: Michal Hocko
Cc: Qian Cai
Cc: Oscar Salvador
Cc: Eric Biederman
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Borislav Petkov
Cc: "H. Peter Anvin"
Cc: Tom Lendacky
Cc: Brijesh Singh
Cc: x...@kernel.org
Cc: ke...@lists.infradead.org
Signed-off-by: David Hildenbrand
---
kernel/resource.c | 45 -
1 file changed, 12 insertions(+), 33 deletions(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 16e0c7e8ed24..7e00239a023a 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -64,12 +64,8 @@ static DEFINE_RWLOCK(resource_lock);
static struct resource *bootmem_resource_free;
static DEFINE_SPINLOCK(bootmem_resource_lock);
-static struct resource *next_resource(struct resource *p, bool sibling_only)
+static struct resource *next_resource(struct resource *p)
{
- /* Caller wants to traverse through siblings only */
- if (sibling_only)
- return p->sibling;
-
if (p->child)
return p->child;
while (!p->sibling && p->parent)
@@ -81,7 +77,7 @@ static void *r_next(struct seq_file *m, void *v, loff_t *pos)
{
struct resource *p = v;
(*pos)++;
- return (void *)next_resource(p, false);
+ return (void *)next_resource(p);
}
#ifdef CONFIG_PROC_FS
@@ -330,14 +326,10 @@ EXPORT_SYMBOL(release_resource);
* of the resource that's within [@start..@end]; if none is found, returns
* -ENODEV. Returns -EINVAL for invalid parameters.
*
- * This function walks the whole tree and not just first level children
- * unless @first_lvl is true.
- *
* @start:start address of the resource searched for
* @end: end address of same resource
* @flags:flags which the resource must have
* @desc: descriptor the resource must have
- * @first_lvl: walk only the first level children, if set
* @res: return ptr, if resource found
*
* The caller must specify @start, @end, @flags, and @desc
@@ -345,9 +337,8 @@ EXPORT_SYMBOL(release_resource);
*/
static int find_next_iomem_res(resource_size_t start, resource_size_t end,
unsigned long flags, unsigned long desc,
- bool first_lvl, struct resource *res)
+ struct resource *res)
{
- bool siblings_only = true;
struct resource *p;
if (!res)
@@ -358,7 +349,7 @@ static int find_next_iomem_res(resource_size_t start,
resource_size_t end,
read_lock(_lock);
- for (p = iomem_resource.child; p; p = next_resource(p, siblings_only)) {
+ for (p = iomem_resource.child; p; p = next_resource(p)) {
/* If we passed the resource we are looking for, stop */
if (p->start > end) {
p = NULL;
@@ -369,13 +360,6 @@ static int find_next_iomem_res(resource_size_t start,
resource_size_t end,
if (p->end < start)
continue;
- /*
-* Now that we found a range that matches what we look for,
-* check the flags and the descriptor. If we were not asked to
-* use only the first level, start looking at children as well.
-*/
- siblings_only = first_lvl;
-
if ((p->flags & flags) != flags)
continue;
if ((desc != IORES_DESC_NONE) && (desc != p->desc))
@@ -402,14 +386,14 @@ static int find_next_iomem_res(resource_size_t start,
resource_size_t end,
static int __walk_iomem_res_desc(resource_size_t start, resource_size_t end,
unsigned long flags, unsigned long desc,
-bool first_lvl, void *arg,
+void *arg,
int (*func)(struct resource *, void *))
Can it be one line?
{
struct resource res;
int ret = -EINVAL;
while (start < end &&
- !find_next_iomem_res(start, end, flags, desc, first_lvl, )) {
+ !find_next_iomem_res(start, end, flags, desc, )) {
ret = (*func)(, arg);
if (ret)
break;
@@ -431,7 +415,6 @@
Re: [PATCH v1 2/3] kernel/resource: make walk_mem_res() find all busy IORESOURCE_MEM resources
On 23.03.21 12:08, Andy Shevchenko wrote: On Mon, Mar 22, 2021 at 05:01:59PM +0100, David Hildenbrand wrote: It used to be true that we can have system RAM only on the first level in the resourc tree. However, this is no longer holds for driver-managed system RAM (i.e., dax/kmem and virtio-mem). The function walk_mem_res() only consideres the first level and is used in arch/x86/mm/ioremap.c:__ioremap_check_mem() only. We currently fail to identify System RAM added by dax/kmem and virtio-mem as "IORES_MAP_SYSTEM_RAM", for example, allowing for remapping of such "normal RAM" in __ioremap_caller(). Here I dunno, but consider to add Fixes tag if it fixes known bad behaviour. Haven't observed it in the wild. We can add the same fixes tags as to patch #1. -- Thanks, David / dhildenb
Re: [PATCH resend] usb: gadget: legacy: fix error return code of msg_bind()
On Sun, Mar 07, 2021 at 12:52:19AM -0800, Jia-Ju Bai wrote: > When usb_otg_descriptor_alloc() returns NULL to usb_desc, no error > return code of msg_bind() is assigned. > To fix this bug, status is assigned with -ENOMEM in this case. > > Reported-by: TOTE Robot > You have 2 '>' on the end of this line :(
[PATCH v2 2/2] staging: rtl8192e: Change state information from u16 to u8
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4
bytes in total while the operations performed on this array through-out
the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 bytes of data using memcpy():
(In rtllib_rx.c:1972)
memcpy(network->CcxRmState, _element->data[4], 2)
With "info_element->data[]" being a u8 array, if 2 bytes are written
into "CcxRmState" (whose one element is u16 size), then the 2 u8
elements from "data[]" gets squashed and written into the first element
("CcxRmState[0]") while the second element ("CcxRmState[1]") is never
fed with any data.
Same in file rtllib_rx.c:2522:
memcpy(dst->CcxRmState, src->CcxRmState, 2);
The above line duplicates "src" data to "dst" but only writes 2 bytes
(and not 4, which is the actual size). Again, only 1st element gets the
value while the 2nd element remains uninitialized.
This later makes operations done with CcxRmState unpredictable in the
following lines as the 1st element is having a squashed number while the
2nd element is having an uninitialized random number.
rtllib_rx.c:1973:if (network->CcxRmState[0] != 0)
rtllib_rx.c:1977:network->MBssidMask = network->CcxRmState[1] & 0x07;
network->MBssidMask is also of type u8 and not u16.
Fix this by changing the type of "CcxRmState" from u16 to u8 so that the
data written into this array and read from it make sense and are not
random values.
NOTE: The wrong initialization of "CcxRmState" can be seen in the
following commit:
commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver")
The above commit created a file `rtl8192e/ieee80211.h` which used to
have the faulty line. The file has been deleted (or possibly renamed)
with the contents copied in to a new file `rtl8192e/rtllib.h` along with
additional code in the commit 94a799425eee (tagged in Fixes).
Fixes: 94a799425eee ("[PATCH 1/8] rtl8192e: Import new version of driver from
realtek")
Cc: sta...@vger.kernel.org
Signed-off-by: Atul Gopinathan
---
drivers/staging/rtl8192e/rtllib.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtllib.h
b/drivers/staging/rtl8192e/rtllib.h
index b84f00b8d18b..4cabaf21c1ca 100644
--- a/drivers/staging/rtl8192e/rtllib.h
+++ b/drivers/staging/rtl8192e/rtllib.h
@@ -1101,15 +1101,15 @@ struct rtllib_network {
u8 hidden_ssid[IW_ESSID_MAX_SIZE + 1];
u8 hidden_ssid_len;
struct rtllib_qos_data qos_data;
boolbWithAironetIE;
boolbCkipSupported;
boolbCcxRmEnable;
- u16 CcxRmState[2];
+ u8 CcxRmState[2];
boolbMBssidValid;
u8 MBssidMask;
u8 MBssid[ETH_ALEN];
boolbWithCcxVerNum;
u8 BssCcxVerNumber;
/* These are network statistics */
struct rtllib_rx_stats stats;
--
2.25.1
Re: [PATCH v6 20/24] iio: buffer: add ioctl() to support opening extra buffers for IIO device
On Tue, 23 Mar 2021 11:51:04 +0200
Alexandru Ardelean wrote:
> On Sun, Mar 21, 2021 at 7:37 PM Jonathan Cameron
> wrote:
> >
> > On Sat, 20 Mar 2021 17:41:00 +
> > Jonathan Cameron wrote:
> >
> > > On Mon, 15 Mar 2021 09:58:08 +
> > > "Sa, Nuno" wrote:
> > >
> > > > > -Original Message-
> > > > > From: Alexandru Ardelean
> > > > > Sent: Saturday, March 6, 2021 6:01 PM
> > > > > To: Jonathan Cameron
> > > > > Cc: Lars-Peter Clausen ; Ardelean,
> > > > > Alexandru ; LKML > > > > ker...@vger.kernel.org>; linux-iio ;
> > > > > Hennerich, Michael ; Jonathan
> > > > > Cameron ; Sa, Nuno ;
> > > > > Bogdan, Dragos
> > > > > Subject: Re: [PATCH v6 20/24] iio: buffer: add ioctl() to support
> > > > > opening
> > > > > extra buffers for IIO device
> > > > >
> > > > > [External]
> > > > >
> > > > > On Sun, Feb 28, 2021 at 9:00 PM Jonathan Cameron
> > > > > wrote:
> > > > > >
> > > > > > On Sun, 28 Feb 2021 16:51:51 +0100
> > > > > > Lars-Peter Clausen wrote:
> > > > > >
> > > > > > > On 2/28/21 3:34 PM, Jonathan Cameron wrote:
> > > > > > > > On Sun, 28 Feb 2021 09:51:38 +0100
> > > > > > > > Lars-Peter Clausen wrote:
> > > > > > > >
> > > > > > > >> On 2/15/21 11:40 AM, Alexandru Ardelean wrote:
> > > > > > > >>> With this change, an ioctl() call is added to open a
> > > > > > > >>> character
> > > > > device for a
> > > > > > > >>> buffer. The ioctl() number is 'i' 0x91, which follows the
> > > > > > > >>> IIO_GET_EVENT_FD_IOCTL ioctl.
> > > > > > > >>>
> > > > > > > >>> The ioctl() will return an FD for the requested buffer index.
> > > > > > > >>>
> > > > > The indexes
> > > > > > > >>> are the same from the /sys/iio/devices/iio:deviceX/bufferY
> > > > > (i.e. the Y
> > > > > > > >>> variable).
> > > > > > > >>>
> > > > > > > >>> Since there doesn't seem to be a sane way to return the FD
> > > > > > > >>> for
> > > > > buffer0 to
> > > > > > > >>> be the same FD for the /dev/iio:deviceX, this ioctl() will
> > > > > > > >>> return
> > > > > another
> > > > > > > >>> FD for buffer0 (or the first buffer). This duplicate FD will
> > > > > > > >>> be
> > > > > able to
> > > > > > > >>> access the same buffer object (for buffer0) as accessing
> > > > > directly the
> > > > > > > >>> /dev/iio:deviceX chardev.
> > > > > > > >>>
> > > > > > > >>> Also, there is no IIO_BUFFER_GET_BUFFER_COUNT ioctl()
> > > > > implemented, as the
> > > > > > > >>> index for each buffer (and the count) can be deduced from
> > > > > the
> > > > > > > >>> '/sys/bus/iio/devices/iio:deviceX/bufferY' folders (i.e the
> > > > > number of
> > > > > > > >>> bufferY folders).
> > > > > > > >>>
> > > > > > > >>> Used following C code to test this:
> > > > > > > >>> ---
> > > > > > > >>>
> > > > > > > >>>#include
> > > > > > > >>>#include
> > > > > > > >>>#include
> > > > > > > >>>#include
> > > > > > > >>>#include > > > > > > >>>#include
> > > > > > > >>>
> > > > > > > >>>#define IIO_BUFFER_GET_FD_IOCTL _IOWR('i', 0x91, int)
> > > > > > > >>>
> > > > > > > >>> int main(int argc, char *argv[])
> > > > > > > >>> {
> > > > > > > >>> int fd;
> > > > > > > >>> int fd1;
> > > > > > > >>> int ret;
> > > > > > > >>>
> > > > > > > >>> if ((fd = open("/dev/iio:device0", O_RDWR))<0) {
> > > > > > > >>> fprintf(stderr, "Error open() %d errno
> > > > > > > >>> %d\n",fd,
> > > > > errno);
> > > > > > > >>> return -1;
> > > > > > > >>> }
> > > > > > > >>>
> > > > > > > >>> fprintf(stderr, "Using FD %d\n", fd);
> > > > > > > >>>
> > > > > > > >>> fd1 = atoi(argv[1]);
> > > > > > > >>>
> > > > > > > >>> ret = ioctl(fd, IIO_BUFFER_GET_FD_IOCTL, );
> > > > > > > >>> if (ret < 0) {
> > > > > > > >>> fprintf(stderr, "Error for buffer %d
> > > > > > > >>> ioctl() %d errno
> > > > > %d\n", fd1, ret, errno);
> > > > > > > >>> close(fd);
> > > > > > > >>> return -1;
> > > > > > > >>> }
> > > > > > > >>>
> > > > > > > >>> fprintf(stderr, "Got FD %d\n", fd1);
> > > > > > > >>>
> > > > > > > >>> close(fd1);
> > > > > > > >>> close(fd);
> > > > > > > >>>
> > > > > > > >>> return 0;
> > > > > > > >>> }
> > > > > > > >>> ---
> > > > > > > >>>
> > > > > > > >>> Results are:
> > > > > > > >>> ---
> > > > > > > >>># ./test 0
> > > > > > > >>>Using FD 3
> > > > > > > >>>Got FD 4
> > > > > > > >>>
> > > > > > > >>># ./test 1
> > > > > > > >>>Using FD 3
> > > > > > > >>>Got FD 4
> > > > > > > >>>
> > > > > > > >>># ./test 2
> > > > > > > >>>Using FD 3
> > > > > > > >>>Got FD 4
> > > > > > >
Re: [PATCH] PCI: dwc/intel-gw: Fix enabling the legacy PCI interrupt lines
On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
> bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however
> was taking (for example) "13" as raw value instead of taking BIT(13).
> Define the legacy PCI interrupt bits using the BIT() macro and then use
> these in PCIE_APP_IRN_INT.
>
> Fixes: ed22aaaede44 ("PCI: dwc: intel: PCIe RC controller driver")
> Signed-off-by: Martin Blumenstingl
> ---
> drivers/pci/controller/dwc/pcie-intel-gw.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c
> b/drivers/pci/controller/dwc/pcie-intel-gw.c
> index 0cedd1f95f37..ae96bfbb6c83 100644
> --- a/drivers/pci/controller/dwc/pcie-intel-gw.c
> +++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
> @@ -39,6 +39,10 @@
> #define PCIE_APP_IRN_PM_TO_ACK BIT(9)
> #define PCIE_APP_IRN_LINK_AUTO_BW_STAT BIT(11)
> #define PCIE_APP_IRN_BW_MGT BIT(12)
> +#define PCIE_APP_IRN_INTABIT(13)
> +#define PCIE_APP_IRN_INTBBIT(14)
> +#define PCIE_APP_IRN_INTCBIT(15)
> +#define PCIE_APP_IRN_INTDBIT(16)
> #define PCIE_APP_IRN_MSG_LTR BIT(18)
> #define PCIE_APP_IRN_SYS_ERR_RC BIT(29)
> #define PCIE_APP_INTX_OFST 12
> @@ -48,10 +52,8 @@
> PCIE_APP_IRN_RX_VDM_MSG | PCIE_APP_IRN_SYS_ERR_RC | \
> PCIE_APP_IRN_PM_TO_ACK | PCIE_APP_IRN_MSG_LTR | \
> PCIE_APP_IRN_BW_MGT | PCIE_APP_IRN_LINK_AUTO_BW_STAT | \
> - (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTA) | \
> - (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTB) | \
> - (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTC) | \
> - (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTD))
> + PCIE_APP_IRN_INTA | PCIE_APP_IRN_INTB | \
> + PCIE_APP_IRN_INTC | PCIE_APP_IRN_INTD)
>
> #define BUS_IATU_OFFSET SZ_256M
> #define RESET_INTERVAL_MS100
This looks like a significant bug - which in turn raises the question
on how well this driver has been tested.
Dilip, can you review and ACK asap please ?
Thanks,
Lorenzo
Re: [PATCH v2 12/15] PCI/MSI: Let PCI host bridges declare their reliance on MSI domains
On 2021-03-22 18:46, Marc Zyngier wrote:
The new 'no_msi' attribute solves the problem of advertising the lack
of MSI capability for host bridges that know for sure that there will
be no MSI for their end-points.
However, there is a whole class of host bridges that cannot know
whether MSIs will be provided or not, as they rely on other blocks
to provide the MSI functionnality, using MSI domains. This is
the case for example on systems that use the ARM GIC architecture.
Introduce a new attribute ('msi_domain') indicating that implicit
dependency, and use this property to set the NO_MSI flag when
no MSI domain is found at probe time.
Acked-by: Bjorn Helgaas
Signed-off-by: Marc Zyngier
---
drivers/pci/probe.c | 2 +-
include/linux/pci.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 146bd85c037e..bac9f69a06a8 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -925,7 +925,7 @@ static int pci_register_host_bridge(struct pci_host_bridge
*bridge)
device_enable_async_suspend(bus->bridge);
pci_set_bus_of_node(bus);
pci_set_bus_msi_domain(bus);
- if (bridge->no_msi)
+ if (bridge->no_msi || (bridge->msi_domain && !bus->dev.msi_domain))
bus->bus_flags |= PCI_BUS_FLAGS_NO_MSI;
if (!parent)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 48605cca82ae..d322d00db432 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -551,6 +551,7 @@ struct pci_host_bridge {
unsigned intpreserve_config:1; /* Preserve FW resource setup */
unsigned intsize_windows:1; /* Enable root bus sizing */
unsigned intno_msi:1; /* Bridge has no MSI support */
+ unsigned intmsi_domain:1; /* Bridge wants MSI domain */
Aren't these really the same thing? Either way we're saying the bridge
itself doesn't handle MSIs, it's just in one case we're effectively
encoding a platform-specific assumption that an external domain won't be
provided. I can't help wondering whether that distinction is really
necessary...
Robin.
/* Resource alignment requirements */
resource_size_t (*align_resource)(struct pci_dev *dev,
[PATCH 3/3] arm64: lib: improve copy performance when size is less than 128 and ge 64 bytes
When copy less than 128 and ge than 64 bytes, add src/dst after load and store 64 bytes to improve performance. Copy 127 bytes cost on Kunpeng920 (ms): Without this patch: memcpy: 14.62 copy_from_user: 14.23 copy_to_user: 14.42 With this patch: memcpy: 13.85 copy_from_user: 13.26 copy_to_user: 13.84 It's about 5.27% improvement in memcpy(). Signed-off-by: Yang Yingliang --- arch/arm64/lib/copy_template.S | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/arch/arm64/lib/copy_template.S b/arch/arm64/lib/copy_template.S index c3cd6f84c9c0..a9cbd47473f0 100644 --- a/arch/arm64/lib/copy_template.S +++ b/arch/arm64/lib/copy_template.S @@ -132,14 +132,16 @@ D_h .reqx14 * Less than 128 bytes to copy, so handle 64 here and then jump * to the tail. */ - ldp1A_l, A_h, src, #16 - stp1A_l, A_h, dst, #16 - ldp1B_l, B_h, src, #16 - ldp1C_l, C_h, src, #16 - stp1B_l, B_h, dst, #16 - stp1C_l, C_h, dst, #16 - ldp1D_l, D_h, src, #16 - stp1D_l, D_h, dst, #16 + ldp2A_l, A_h, src, #0, #8 + stp2A_l, A_h, dst, #0, #8 + ldp2B_l, B_h, src, #16, #24 + ldp2C_l, C_h, src, #32, #40 + stp2B_l, B_h, dst, #16, #24 + stp2C_l, C_h, dst, #32, #40 + ldp2D_l, D_h, src, #48, #56 + stp2D_l, D_h, dst, #48, #56 + add src, src, #64 + add dst, dst, #64 tst count, #0x3f b.ne.Ltail63 -- 2.25.1
Re: [kbuild-all] Re: include/linux/compiler_types.h:315:38: error: call to '__compiletime_assert_536' declared with attribute error: BUILD_BUG_ON failed: offsetof(struct can_frame, len) != offsetof(st
On 23.03.2021 10:54:40, Rong Chen wrote: > I tried arm-linux-gnueabi (gcc version 10.2.0) and the problem still > exists, btw we prefer to not use the latest gcc compiler to avoid > false positives. FWIW: I'm using latest debian arm compiler and the BUILD_BUG never triggered. gcc version 10.2.1 20210110 (Debian 10.2.1-6) regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | signature.asc Description: PGP signature
