[PATCH] reset: Add driver for dispmix reset
This is an reset driver to implement a reset controller
device DISPMIX on IMX8MM and IMX8MN platforms. Dispmix
reset is used to reset or enable related buses and clks
for the submodules in DISPMIX.
All the dispmix resets are divided into three subgroups:
sft_rstn, clk_en and mipi_rst, and each of them contains
several reset lines to control several different modules
on and off in DISPMIX which doesn't require the standard
reset flow, but only line assert and deassert operations.
Signed-off-by: Fancy Fang
---
.../bindings/reset/nxp,dispmix-clk-en.txt | 58 +++
.../bindings/reset/nxp,dispmix-mipi-rst.txt | 57 +++
.../bindings/reset/nxp,dispmix-sft-rstn.txt | 58 +++
drivers/reset/Kconfig | 9 +
drivers/reset/Makefile| 1 +
drivers/reset/reset-dispmix.c | 399 ++
include/dt-bindings/reset/imx8mm-dispmix.h| 49 +++
include/dt-bindings/reset/imx8mn-dispmix.h| 47 +++
8 files changed, 678 insertions(+)
create mode 100644
Documentation/devicetree/bindings/reset/nxp,dispmix-clk-en.txt
create mode 100644
Documentation/devicetree/bindings/reset/nxp,dispmix-mipi-rst.txt
create mode 100644
Documentation/devicetree/bindings/reset/nxp,dispmix-sft-rstn.txt
create mode 100644 drivers/reset/reset-dispmix.c
create mode 100644 include/dt-bindings/reset/imx8mm-dispmix.h
create mode 100644 include/dt-bindings/reset/imx8mn-dispmix.h
diff --git a/Documentation/devicetree/bindings/reset/nxp,dispmix-clk-en.txt
b/Documentation/devicetree/bindings/reset/nxp,dispmix-clk-en.txt
new file mode 100644
index ..4375039eb072
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/nxp,dispmix-clk-en.txt
@@ -0,0 +1,58 @@
+NXP Display Mix clk-en Reset Controller
+===
+
+This binding describes a reset controller device that is used to enable
+or disable the internal clocks for all the submodules(such as, LCDIF,
+MIPI DSI, MIPI CSI, ISI and etc) included by the Display Mix subsystem
+on IMX8MM and IMX8MN platforms. Like sft-rstn, only assert and deassert
+functions are required for submodule internal clocks enable or disable,
+that means the clk-en can be treated as a real reset controller.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "fsl,imx8mm-dispmix-clk-en" or
+ "fsl,imx8mn-dispmix-clk-en".
+- reg: should be register base and length as documented in the datasheet.
+- clocks: phandle and clock specifier to disp apb clock for register access.
+- clock-names: should be "disp-apb".
+- power-domains: phandle to dispmix power domain.
+- reset-cells: 1, see below.
+
+example:
+
+ dispmix_clk_en: dispmix-clk-en@32e28004 {
+ compatible = "fsl,imx8mn-dispmix-clk-en";
+ reg = <0x0 0x32e28004 0x0 0x4>;
+ clocks = < IMX8MN_CLK_DISP_APB_ROOT>;
+ clock-names = "disp-apb";
+ power-domains = <_pd>;
+ #reset-cells = <1>;
+ };
+
+Specifying clk-en control of devices
+
+
+Device nodes in Display Mix should specify the reset channel required in
+their "resets" property, containing a phandle to the clk-en device node
+and an index to specify which channel to use, as described in
+Documentation/devicetree/bindings/reset/reset.txt.
+
+example:
+
+ lcdif_resets: lcdif-resets {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #reset-cells = <0>;
+
+ lcdif-clk-enable {
+ compatible = "lcdif,clk-enable";
+ resets = <_clk_en IMX8MN_LCDIF_APB_CLK_EN>,
+<_clk_en IMX8MN_LCDIF_PIXEL_CLK_EN>;
+ };
+ };
+
+Macro definitions for the supported reset channels can be found in:
+include/dt-bindings/reset/imx8mm-dispmix.h and
+include/dt-bindings/reset/imx8mn-dispmix.h.
diff --git a/Documentation/devicetree/bindings/reset/nxp,dispmix-mipi-rst.txt
b/Documentation/devicetree/bindings/reset/nxp,dispmix-mipi-rst.txt
new file mode 100644
index ..c47bfd4842ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/nxp,dispmix-mipi-rst.txt
@@ -0,0 +1,57 @@
+NXP Display Mix mipi-rst Reset Controller
+=
+
+This binding describes a reset controller device that is used to reset
+or de-reset the MIPI DPHY master direction(for MIPI DSI) and slave
+direction(for MIPI CSI) included by the Display Mix subsystem on IMX8MM
+and IMX8MN platforms. Like sft-rstn, only assert and deassert functions
+are required for PHY reset or de-reset.
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "fsl,imx8mm-dispmix-mipi-rst" or
+ "fsl,imx8mn-dispmix-mipi-rst".
+-
Re: [PATCH v7 1/5] mtd: cfi_cmdset_0002: Add support for polling status register
Hi,
On 24/06/19 10:16 PM, Tokunori Ikegami wrote:
>
[...]
>> +/*
>> + * Use status register to poll for Erase/write completion when DQ is not
>> + * supported. This is indicated by Bit[1:0] of SoftwareFeatures field in
>> + * CFI Primary Vendor-Specific Extended Query table 1.5
>> + */
>> +static int cfi_use_status_reg(struct cfi_private *cfi)
>> +{
>> + struct cfi_pri_amdstd *extp = cfi->cmdset_priv;
>> +
>> + return extp->MinorVersion >= '5' &&
>> + (extp->SoftwareFeatures & 0x3) == 0x1;
>
> Seems to be better to use defined values instead of 0x3 and 0x1 hard
> coded values.
>
Ok
>> +}
>> +
>> +static void cfi_check_err_status(struct map_info *map, unsigned long
>> adr)
>> +{
>> + struct cfi_private *cfi = map->fldrv_priv;
>> + map_word status;
>> +
>> + if (!cfi_use_status_reg(cfi))
>> + return;
>> +
>> + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi,
>
> Is it not necessary to set chip->start as the base parameter for
> cfi_send_gen_cmd()?
>
Right now, I am not aware of any flash that supports status registers
and are banked (that's when chip->start can be non zero). Therefore I
did not think of using chip->start.
But anyways, I will fix this up to use chip->start here and elsewhere
for next version, assuming there will be such chips in the future.
>> + cfi->device_type, NULL);
>> + status = map_read(map, adr);
>> +
>> + if (map_word_bitsset(map, status, CMD(0x3a))) {
>> + unsigned long chipstatus = MERGESTATUS(status);
>> +
>> + if (chipstatus & CFI_SR_ESB)
>> + pr_err("%s erase operation failed, status %lx\n",
>> + map->name, chipstatus);
>> + if (chipstatus & CFI_SR_PSB)
>> + pr_err("%s program operation failed, status %lx\n",
>> + map->name, chipstatus);
>> + if (chipstatus & CFI_SR_WBASB)
>> + pr_err("%s buffer program command aborted, status %lx\n",
>> + map->name, chipstatus);
>> + if (chipstatus & CFI_SR_SLSB)
>> + pr_err("%s sector write protected, status %lx\n",
>> + map->name, chipstatus);
>> + }
>> +}
>> /* #define DEBUG_CFI_FEATURES */
>> @@ -744,8 +796,22 @@ static struct mtd_info *cfi_amdstd_setup(struct
>> mtd_info *mtd)
>> */
>> static int __xipram chip_ready(struct map_info *map, unsigned long
>> addr)
>> {
>> + struct cfi_private *cfi = map->fldrv_priv;
>> map_word d, t;
>> + if (cfi_use_status_reg(cfi)) {
>> + map_word ready = CMD(CFI_SR_DRB);
>> + /*
>> + * For chips that support status register, check device
>> + * ready bit
>> + */
>> + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi,
>
> Same comment as cfi_check_err_status() about the base address.
>
>> + cfi->device_type, NULL);
>> + d = map_read(map, addr);
>> +
>> + return map_word_andequal(map, d, ready, ready);
>> + }
>> +
>> d = map_read(map, addr);
>> t = map_read(map, addr);
>> @@ -769,8 +835,27 @@ static int __xipram chip_ready(struct map_info
>> *map, unsigned long addr)
>> */
>> static int __xipram chip_good(struct map_info *map, unsigned long
>> addr, map_word expected)
>> {
>> + struct cfi_private *cfi = map->fldrv_priv;
>> map_word oldd, curd;
>> + if (cfi_use_status_reg(cfi)) {
>> + map_word ready = CMD(CFI_SR_DRB);
>> + map_word err = CMD(CFI_SR_PSB | CFI_SR_ESB);
>
> Is it not necessary to check CFI_SR_WBASB and CFI_SR_SLSB that are
> checked by cfi_check_err_status()?
>
chip_good() is used to verify whether write or erase operation really
succeeded. Looking at Cypress HyperFlash datasheets and app notes on
status register polling, its enough to see if CFI_SR_PSB or CFI_SR_PSB
is set to know if write or erase failed. Now, the reason for program or
erase failure can be known by looking at CFI_SR_WBASB and CFI_SR_SLSB
which is done for cfi_check_err_status().
Therefore, I feel, its enough to look for CFI_SR_PSB or CFI_SR_ESB here.
Thanks for the review!
Regards
Vignesh
>> + /*
>> + * For chips that support status register, check device
>> + * ready bit and Erase/Program status bit to know if
>> + * operation succeeded.
>> + */
>> + cfi_send_gen_cmd(0x70, cfi->addr_unlock1, 0, map, cfi,
>
> Same as cfi_check_err_status() and chip_ready() about the base address.
>
>> + cfi->device_type, NULL);
>> + curd = map_read(map, addr);
>> +
>> + if (map_word_andequal(map, curd, ready, ready))
>> + return !map_word_bitsset(map, curd, err);
>> +
>> + return 0;
>> + }
>> +
>> oldd = map_read(map, addr);
>> curd = map_read(map, addr);
>> @@ -1644,6 +1729,7 @@ static int __xipram do_write_oneword(struct
>> map_info *map, struct flchip *chip,
>> /* Did we succeed? */
>> if (!chip_good(map, adr, datum)) {
>> /*
Reminder: 12 open syzbot bugs in "net/wireless" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 12 of them as possibly being bugs in the "net/wireless" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 12 bugs, 10 were seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/wireless" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: general protection fault in ath6kl_usb_alloc_urb_from_pipe Last occurred: 0 days ago Reported: 73 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=cd8b9cfe50a0bf36ee19eda2d7e2e06843dfbeaf Original thread: https://lkml.kernel.org/lkml/8e82510586561...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. This looks like a bug in a net/wireless USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+ead4037ec793e025e...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/8e82510586561...@google.com Title: INFO: trying to register non-static key in rtl_c2hcmd_launcher Last occurred: 0 days ago Reported: 73 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=9c910719e185e47dad63741d473518b365286eb7 Original thread: https://lkml.kernel.org/lkml/727264058653d...@google.com/T/#u This bug has a C reproducer. The original thread for this bug has received 1 reply, 27 days ago. This looks like a bug in a net/wireless USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+1fcc5ef45175fc774...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/727264058653d...@google.com Title: WARNING: ODEBUG bug in rsi_probe Last occurred: 0 days ago Reported: 71 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=3b35267abf182bd98ba95c0943bc0f957e021101 Original thread: https://lkml.kernel.org/lkml/24bbd7058682e...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. This looks like a bug in a net/wireless USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+1d1597a5aa3679c65...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/24bbd7058682e...@google.com Title: INFO: trying to register non-static key in del_timer_sync (2) Last occurred: 0 days ago Reported: 73 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=26525f643f454dd7be0078423e3cdb0d57744959 Original thread: https://lkml.kernel.org/lkml/927a7b0586561...@google.com/T/#u This bug has a C reproducer. The original thread for this bug has received 5 replies; the last was 12 days ago. This looks like a bug in a net/wireless USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+dc4127f950da51639...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread, which had activity only 12 days ago. For the git send-email command to use, or tips on how to reply if the thread isn't in your
Reminder: 27 open syzbot bugs in "net/xfrm" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 27 of them as possibly being bugs in the "net/xfrm" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 27 bugs, 4 were bisected to commits from the following person: Su Yanjun If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/xfrm" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: general protection fault in get_work_pool Last occurred: 75 days ago Reported: 478 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=849bd5710811bd19cad5b2f32ae863cfd6fe1c58 Original thread: https://lkml.kernel.org/lkml/001a1149c7ba03500d05667a1...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+880087058dbc131a2...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/001a1149c7ba03500d05667a1...@google.com Title: KASAN: use-after-free Read in _decode_session4 Last occurred: 451 days ago Reported: 451 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=341e1a2a55b389e54cc07624ed40eb3ecca577db Original thread: https://lkml.kernel.org/lkml/001a113fe6d081698f0568a5d...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+a7db9083ed4017ba4...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/001a113fe6d081698f0568a5d...@google.com Title: KASAN: use-after-free Read in _decode_session6 Last occurred: 223 days ago Reported: 291 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=ecf3e152769bdad66c297986d83561adea6ae155 Original thread: https://lkml.kernel.org/lkml/8d5a360575368...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+e8c1d30881266e47e...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/8d5a360575368...@google.com Title: WARNING in xfrm_policy_fini Last occurred: 52 days ago Reported: 308 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=c92d61bdd289b3550d8dbd6a970c2f34995a22b4 Original thread: https://lkml.kernel.org/lkml/c5745b0573d62...@google.com/T/#u This bug has a syzkaller reproducer only. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+9bce6db6c82f06b85...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/c5745b0573d62...@google.com Title: KMSAN: uninit-value in xfrm_state_find Last occurred: 169 days ago Reported: 374 days ago Branches: Mainline (with KMSAN patches) Dashboard link:
Reminder: 17 open syzbot bugs in "net/tls" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 17 of them as possibly being bugs in the "net/tls" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 17 bugs, 7 were seen in mainline in the last week. Of these 17 bugs, 6 were bisected to commits from the following people: Dave Watson Vakul Garg Boris Pismenny Daniel Borkmann If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/tls" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KASAN: use-after-free Read in tls_write_space Last occurred: 0 days ago Reported: 353 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=3ff26cb6000860a73428556d7df314541369c939 Original thread: https://lkml.kernel.org/lkml/3dab1605704fb...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+2134b6b74dec9f8c7...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/3dab1605704fb...@google.com Title: KMSAN: uninit-value in gf128mul_4k_lle (3) Last occurred: 0 days ago Reported: 213 days ago Branches: Mainline (with KMSAN patches) Dashboard link: https://syzkaller.appspot.com/bug?id=a01db4c67933e9e4be8e721a8ee15a9530f1ac04 Original thread: https://lkml.kernel.org/lkml/bf2457057b5cc...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 2 replies; the last was 208 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+f8495bff23a879a6d...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/bf2457057b5cc...@google.com Title: INFO: task hung in tls_sw_free_resources_tx Last occurred: 6 days ago Reported: 202 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=44ae4b4fa7e6c6e92aa921d2ec20ce9fbee97939 Original thread: https://lkml.kernel.org/lkml/cab053057c2e5...@google.com/T/#u This bug has a C reproducer. This bug was bisected to: commit 3c4d7559159bfe1e3b94df3a657b2cda3a34e218 Author: Dave Watson Date: Wed Jun 14 18:37:39 2017 + tls: kernel TLS support No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+503339bf3c9053b8a...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/cab053057c2e5...@google.com Title: INFO: task hung in __flush_work Last occurred: 0 days ago Reported: 128 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=9613d8dffb5c6cc39da8ec290cb8f3eb62bdf21f Original thread: https://lkml.kernel.org/lkml/8f9c780581fd7...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+aa0b64a57e300a1c6...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply
Reminder: 14 open syzbot bugs in "net/sctp" subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 14 of them as possibly being bugs in the "net/sctp" subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 14 bugs, 4 were seen in mainline in the last week. Of these 14 bugs, 2 were bisected to commits from the following person: Xin Long If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the "net/sctp" subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: general protection fault in sctp_sched_prio_sched Last occurred: 9 days ago Reported: 9 days ago Branches: net Dashboard link: https://syzkaller.appspot.com/bug?id=c9eebb3d2277a526840c1049ae16762b9b11e50e Original thread: https://lkml.kernel.org/lkml/17a264058b653...@google.com/T/#u This bug has a C reproducer. This bug was bisected to: commit 4ff40b86262b73553ee47cc3784ce8ba0f220bd8 Author: Xin Long Date: Mon Jan 21 18:42:09 2019 + sctp: set chunk transport correctly when it's a new asoc The original thread for this bug has received 4 replies; the last was 6 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+c1a380d42b190ad1e...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread, which had activity only 6 days ago. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/17a264058b653...@google.com Title: KASAN: use-after-free Read in __lock_sock Last occurred: 9 days ago Reported: 219 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=27934d200d11e2fbae5c715bfefad252f41785fb Original thread: https://lkml.kernel.org/lkml/b98a67057ad71...@google.com/T/#u This bug has a syzkaller reproducer only. This bug was bisected to: commit 8f840e47f190cbe61a96945c13e9551048d42cef Author: Xin Long Date: Thu Apr 14 07:35:33 2016 + sctp: add the sctp_diag.c file The original thread for this bug received 6 replies; the last was 200 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+9276d76e83e3bcde6...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/b98a67057ad71...@google.com Title: memory leak in sctp_stream_init_ext Last occurred: 0 days ago Reported: 24 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=bbfa653205516be2a33b51c381ef827c534ba596 Original thread: https://lkml.kernel.org/lkml/f122ab058a303...@google.com/T/#u This bug has a C reproducer. The original thread for this bug has received 2 replies; the last was 20 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+7f3b6b106be8dcdcd...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/f122ab058a303...@google.com Title: memory leak in sctp_get_port_local Last occurred: 3 days ago Reported: 27 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=ff1010c7eb802434fa13f8a03fdf6752d043c77c Original thread: https://lkml.kernel.org/lkml/69c3140589f6d...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+079bf326b38072f84...@syzkaller.appspotmail.com If
[PATCH v4 1/2] mtd: rawnand: Add Macronix Raw NAND controller
Add a driver for Macronix raw NAND controller. Signed-off-by: Mason Yang --- drivers/mtd/nand/raw/Kconfig | 6 + drivers/mtd/nand/raw/Makefile| 1 + drivers/mtd/nand/raw/mxic_nand.c | 551 +++ 3 files changed, 558 insertions(+) create mode 100644 drivers/mtd/nand/raw/mxic_nand.c diff --git a/drivers/mtd/nand/raw/Kconfig b/drivers/mtd/nand/raw/Kconfig index 5a711d8..9cff36a 100644 --- a/drivers/mtd/nand/raw/Kconfig +++ b/drivers/mtd/nand/raw/Kconfig @@ -407,6 +407,12 @@ config MTD_NAND_MTK Enables support for NAND controller on MTK SoCs. This controller is found on mt27xx, mt81xx, mt65xx SoCs. +config MTD_NAND_MXIC + tristate "Macronix raw NAND controller" + depends on HAS_IOMEM || COMPILE_TEST + help + This selects the Macronix raw NAND controller driver. + config MTD_NAND_TEGRA tristate "NVIDIA Tegra NAND controller" depends on ARCH_TEGRA || COMPILE_TEST diff --git a/drivers/mtd/nand/raw/Makefile b/drivers/mtd/nand/raw/Makefile index efaf5cd..9b43fbf 100644 --- a/drivers/mtd/nand/raw/Makefile +++ b/drivers/mtd/nand/raw/Makefile @@ -54,6 +54,7 @@ obj-$(CONFIG_MTD_NAND_HISI504)+= hisi504_nand.o obj-$(CONFIG_MTD_NAND_BRCMNAND)+= brcmnand/ obj-$(CONFIG_MTD_NAND_QCOM)+= qcom_nandc.o obj-$(CONFIG_MTD_NAND_MTK) += mtk_ecc.o mtk_nand.o +obj-$(CONFIG_MTD_NAND_MXIC)+= mxic_nand.o obj-$(CONFIG_MTD_NAND_TEGRA) += tegra_nand.o obj-$(CONFIG_MTD_NAND_STM32_FMC2) += stm32_fmc2_nand.o obj-$(CONFIG_MTD_NAND_MESON) += meson_nand.o diff --git a/drivers/mtd/nand/raw/mxic_nand.c b/drivers/mtd/nand/raw/mxic_nand.c new file mode 100644 index 000..14c0b3b --- /dev/null +++ b/drivers/mtd/nand/raw/mxic_nand.c @@ -0,0 +1,551 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2019 Macronix International Co., Ltd. + * + * Author: + * Mason Yang + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include "internals.h" + +#define HC_CFG 0x0 +#define HC_CFG_IF_CFG(x) ((x) << 27) +#define HC_CFG_DUAL_SLAVE BIT(31) +#define HC_CFG_INDIVIDUAL BIT(30) +#define HC_CFG_NIO(x) (((x) / 4) << 27) +#define HC_CFG_TYPE(s, t) ((t) << (23 + ((s) * 2))) +#define HC_CFG_TYPE_SPI_NOR0 +#define HC_CFG_TYPE_SPI_NAND 1 +#define HC_CFG_TYPE_SPI_RAM2 +#define HC_CFG_TYPE_RAW_NAND 3 +#define HC_CFG_SLV_ACT(x) ((x) << 21) +#define HC_CFG_CLK_PH_EN BIT(20) +#define HC_CFG_CLK_POL_INV BIT(19) +#define HC_CFG_BIG_ENDIAN BIT(18) +#define HC_CFG_DATA_PASS BIT(17) +#define HC_CFG_IDLE_SIO_LVL(x) ((x) << 16) +#define HC_CFG_MAN_START_ENBIT(3) +#define HC_CFG_MAN_START BIT(2) +#define HC_CFG_MAN_CS_EN BIT(1) +#define HC_CFG_MAN_CS_ASSERT BIT(0) + +#define INT_STS0x4 +#define INT_STS_EN 0x8 +#define INT_SIG_EN 0xc +#define INT_STS_ALLGENMASK(31, 0) +#define INT_RDY_PINBIT(26) +#define INT_RDY_SR BIT(25) +#define INT_LNR_SUSP BIT(24) +#define INT_ECC_ERRBIT(17) +#define INT_CRC_ERRBIT(16) +#define INT_LWR_DISBIT(12) +#define INT_LRD_DISBIT(11) +#define INT_SDMA_INT BIT(10) +#define INT_DMA_FINISH BIT(9) +#define INT_RX_NOT_FULLBIT(3) +#define INT_RX_NOT_EMPTY BIT(2) +#define INT_TX_NOT_FULLBIT(1) +#define INT_TX_EMPTY BIT(0) + +#define HC_EN 0x10 +#define HC_EN_BIT BIT(0) + +#define TXD(x) (0x14 + ((x) * 4)) +#define RXD0x24 + +#define SS_CTRL(s) (0x30 + ((s) * 4)) +#define LRD_CFG0x44 +#define LWR_CFG0x80 +#define RWW_CFG0x70 +#define OP_READBIT(23) +#define OP_DUMMY_CYC(x)((x) << 17) +#define OP_ADDR_BYTES(x) ((x) << 14) +#define OP_CMD_BYTES(x)(((x) - 1) << 13) +#define OP_OCTA_CRC_EN BIT(12) +#define OP_DQS_EN BIT(11) +#define OP_ENHC_EN BIT(10) +#define OP_PREAMBLE_EN BIT(9) +#define OP_DATA_DDRBIT(8) +#define OP_DATA_BUSW(x)((x) << 6) +#define OP_ADDR_DDRBIT(5) +#define OP_ADDR_BUSW(x)((x) << 3) +#define OP_CMD_DDR BIT(2) +#define OP_CMD_BUSW(x) (x) +#define OP_BUSW_1 0 +#define OP_BUSW_2 1 +#define OP_BUSW_4 2 +#define OP_BUSW_8 3 + +#define OCTA_CRC 0x38 +#define OCTA_CRC_IN_EN(s) BIT(3 + ((s) * 16)) +#define OCTA_CRC_CHUNK(s, x) ((fls((x) / 32)) << (1 + ((s) * 16))) +#define OCTA_CRC_OUT_EN(s) BIT(0 + ((s) * 16)) + +#define ONFI_DIN_CNT(s)(0x3c + (s)) + +#define
[PATCH v4 2/2] dt-bindings: mtd: Document Macronix raw NAND controller bindings
Document the bindings used by the Macronix raw NAND controller.
Signed-off-by: Mason Yang
---
.../devicetree/bindings/mtd/mxic-nand.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/mxic-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/mxic-nand.txt
b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
new file mode 100644
index 000..3d198e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/mxic-nand.txt
@@ -0,0 +1,26 @@
+Macronix Raw NAND Controller Device Tree Bindings
+-
+
+Required properties:
+- compatible: should be "mxic,raw-nand-ctlr"
+- reg: should contain 1 entrie for the registers
+- reg-names: should contain "regs"
+- interrupts: interrupt line connected to this NAND controller
+- clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk"
+- clocks: should contain 3 entries for the "ps_clk", "send_clk" and
+"send_dly_clk" clocks
+
+Example:
+
+ nand: mxic-nfc@43c3 {
+ compatible = "mxic,raw-nand-ctlr";
+ reg = <0x43c3 0x1>;
+ reg-names = "regs";
+ clocks = < 0>, < 1>, < 15>;
+ clock-names = "send_clk", "send_dly_clk", "ps_clk";
+
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "bch";
+ nand-ecc-step-size = <512>;
+ nand-ecc-strength = <8>;
+ };
--
1.9.1
Reminder: 94 open syzbot bugs in net subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 94 of them as possibly being bugs in the net subsystem. This category only includes the networking bugs that I couldn't assign to a more specific component (bpf, xfrm, bluetooth, tls, tipc, sctp, wireless, etc.). I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 94 bugs, 21 were seen in mainline in the last week. Of these 94 bugs, 3 were bisected to commits from the following people: David Ahern Eric Dumazet Florian Westphal If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the net subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KMSAN: uninit-value in bond_start_xmit (2) Last occurred: 0 days ago Reported: 282 days ago Branches: Mainline (with KMSAN patches) Dashboard link: https://syzkaller.appspot.com/bug?id=a9d5a8daec53b47baf50dd4185ff471c637d9c07 Original thread: https://lkml.kernel.org/lkml/ab5ff60575e86...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+e5be16aa39ad6e755...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/ab5ff60575e86...@google.com Title: unregister_netdevice: waiting for DEV to become free (2) Last occurred: 0 days ago Reported: 313 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=bae9a2236bfede42cf3d219e6bf6740c583568a4 Original thread: https://lkml.kernel.org/lkml/56268e05737dc...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 27 replies; the last was 51 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+30209ea299c09d878...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/56268e05737dc...@google.com Title: kernel BUG at net/core/skbuff.c:LINE! (3) Last occurred: 0 days ago Reported: 508 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=9c55af67ce995cf6c4f11ab6f5d3ee805d67fc00 Original thread: https://groups.google.com/d/msgid/syzkaller-bugs/001a114372a6074e6505642b7f72%40google.com This bug has a C reproducer. For some reason the original report email for this bug is missing from the LKML archive at lore.kernel.org, so my script couldn't check whether anyone has replied to it or not. The Google Groups link above should still work, though. Also try searching for the bug title. Title: KMSAN: uninit-value in ip6_parse_tlv Last occurred: 0 days ago Reported: 277 days ago Branches: Mainline (with KMSAN patches) Dashboard link: https://syzkaller.appspot.com/bug?id=a446d3718ee6322911a0c6d34db57909e1838fe7 Original thread: https://lkml.kernel.org/lkml/30779c057653b...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+f08ac29f2ac8aea19...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/30779c057653b...@google.com Title: KMSAN: uninit-value in do_ip_vs_set_ctl Last occurred:
[PATCH v4 0/2] Add Macronix Raw NAND controller driver
Hi, v4 patch back to only raw NAND controller driver instead of MFD, raw NAND and SPI driver. This is based on MFD maintainer, Lee Jones comments: MFD is for registering child devices of chips which offer genuine cross-subsystem functionality. It is not designed for mode selecting, or as a place to shove shared code just because a better location doesn't appear to exist. v3 patch is to rename the title of SPI controller driver. "Patch Macronix SPI controller driver according to MX25F0A MFD driver" v2s patches is to support Macronix MX25F0A MFD driver for raw nand and spi controller which is separated form previous patchset: https://patchwork.kernel.org/patch/10874679/ thanks for your review. best regards, Mason Mason Yang (2): mtd: rawnand: Add Macronix Raw NAND controller dt-bindings: mtd: Document Macronix raw NAND controller bindings .../devicetree/bindings/mtd/mxic-nand.txt | 26 + drivers/mtd/nand/raw/Kconfig | 6 + drivers/mtd/nand/raw/Makefile | 1 + drivers/mtd/nand/raw/mxic_nand.c | 551 + 4 files changed, 584 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/mxic-nand.txt create mode 100644 drivers/mtd/nand/raw/mxic_nand.c -- 1.9.1
Reminder: 11 open syzbot bugs in RDMA subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 11 of them as possibly being bugs in the RDMA subsystem. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 11 bugs, 1 was seen in mainline in the last week. Of these 11 bugs, 1 was bisected to a commit from the following person: Yishai Hadas If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the RDMA subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: KASAN: use-after-free Read in rdma_listen (2) Last occurred: 0 days ago Reported: 86 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=8dc0bcd9dd6ec915ba10b3354740eb420884acaa Original thread: https://lkml.kernel.org/lkml/12a4cd05854a1...@google.com/T/#u This bug has a syzkaller reproducer only. No one has replied to the original thread for this bug yet. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+adb15cf8c2798e4e0...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/12a4cd05854a1...@google.com Title: WARNING: bad unlock balance in ucma_event_handler Last occurred: 14 days ago Reported: 376 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=d5222b3e1659e0aea19df562c79f216515740daa Original thread: https://lkml.kernel.org/lkml/af6530056e863...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 6 replies; the last was 13 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+e5579222b6a3edd96...@syzkaller.appspotmail.com If you send any email or patch for this bug, please reply to the original thread, which had activity only 13 days ago. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/af6530056e863...@google.com Title: WARNING: bad unlock balance in ucma_destroy_id Last occurred: 93 days ago Reported: 300 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=c600e111223ce0a20e5f2fb4e9a4ebdff54d7fa6 Original thread: https://lkml.kernel.org/lkml/3b9c4b0574806...@google.com/T/#u This bug has a syzkaller reproducer only. This bug was bisected to: commit e1c30298ccab87151a0c4241fc5985c591598361 Author: Yishai Hadas Date: Thu Aug 13 15:32:07 2015 + IB/ucma: HW Device hot-removal support No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+4b628fcc748474003...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/3b9c4b0574806...@google.com Title: KASAN: use-after-free Read in __list_del_entry_valid (4) Last occurred: 449 days ago Reported: 456 days ago Branches: Mainline Dashboard link: https://syzkaller.appspot.com/bug?id=56b60fb3340c5995373fe5b8eae9e8722a012fc4 Original thread: https://lkml.kernel.org/lkml/001a1141551246502d0568457...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 6 replies; the last was 305 days ago. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+29ee8f76017ce6cf0...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread
Re: [PATCH v2] Bluetooth: btrtl: HCI reset on close for Realtek BT chip
Hi Daniel,
>> Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly
>> after on-off several times. Bluetooth daemon sets BT mode failed when
>> this issue happens.
>
> You could also mention that scanning must be active while turning off
> for this bug to be hit.
>
>> bluetoothd[1576]: Failed to set mode: Failed (0x03)
>>
>> If BT is tunred off, then turned on again, it works correctly again.
>
> Typo: turned
>
>> According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set
>> during probing. So, this patch makes Realtek's BT reset on close to fix
>> this issue.
>
> Checked the vendor driver - I see what you are referring to, so the
> change seems correct.
>
> #if HCI_VERSION_CODE >= KERNEL_VERSION(3, 7, 1)
>if (!reset)
>set_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);
>RTKBT_DBG("set_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);");
> #endif
>
> However I'm pretty sure this is not saying that kernel 3.7.0 did not
> need the reset. I think it just means that the flag did not exist
> before Linux-3.7.1, so they added the ifdef to add some level of
> compatibility with older kernel versions. I think you can remove
> "since kernel v3.7.1." from the comment.
>
> After those changes you can add:
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429
> Reviewed-by: Daniel Drake
if someone wants to use HCI_Reset to ensure that all their connections and
radio usage is reset, then they should do that via the hdev->shutdown handler.
Look at btusb.c if you need an example.
This quirk is for hardware that can not use HCI_Reset on init which is
Bluetooth 1.0b hardware.
Regards
Marcel
Re: [PATCH v5 02/25] mm: userfault: return VM_FAULT_RETRY on signals
On Mon, Jun 24, 2019 at 09:31:42PM +0800, Linus Torvalds wrote: > On Mon, Jun 24, 2019 at 3:43 PM Peter Xu wrote: > > > > Should we still be able to react on signal_pending() as part of fault > > handling (because that's what this patch wants to do, at least for an > > user-mode page fault)? Please kindly correct me if I misunderstood... > > I think that with this patch (modulo possible fix-ups) then yes, as > long as we're returning to user mode we can do signal_pending() and > return RETRY. > > But I think we really want to add a new FAULT_FLAG_INTERRUPTIBLE bit > for that (the same way we already have FAULT_FLAG_KILLABLE for things > that can react to fatal signals), and only do it when that is set. > Then the page fault handler can set that flag when it's doing a > user-mode page fault. > > Does that sound reasonable? Yes that sounds reasonable to me, and that matches perfectly with TASK_INTERRUPTIBLE and TASK_KILLABLE. The only thing that I am a bit uncertain is whether we should define FAULT_FLAG_INTERRUPTIBLE as a new bit or make it simply a combination of: FAULT_FLAG_KILLABLE | FAULT_FLAG_USER The problem is that when we do set_current_state() with either TASK_INTERRUPTIBLE or TASK_KILLABLE we'll only choose one of them, but never both. Here since the fault flag is a bitmask then if we introduce a new FAULT_FLAG_INTERRUPTIBLE bit and use it in the fault flags then we should probably be sure that FAULT_FLAG_KILLABLE is also set when with that (since IMHO it won't make much sense to make a page fault "interruptable" but "un-killable"...). Considering that TASK_INTERRUPTIBLE should also always in user-mode page faults so this dependency seems to exist with FAULT_FLAG_USER. Then I'm thinking maybe using the combination to express the meaning that "we would like this page fault to be interruptable, even for general userspace signals" would be nicer? AFAIK currently only handle_userfault() have such code to handle normal signals besides SIGKILL, and it was trying to detect this using this rule already: return_to_userland = (vmf->flags & (FAULT_FLAG_USER|FAULT_FLAG_KILLABLE)) == (FAULT_FLAG_USER|FAULT_FLAG_KILLABLE); Then if we define that globally and officially then we can probably replace this simply with: return_to_userland = vmf->flags & FAULT_FLAG_INTERRUPTIBLE; What do you think? Thanks, -- Peter Xu
Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
On Mon, Jun 24, 2019 at 10:22 PM Viresh Kumar wrote: > > On 24-06-19, 22:00, Saravana Kannan wrote: > > All of the cases above are some real world scenarios I've come across. > > CPU and L2/L3 on ARM systems are a good example of (2) but the passive > > governor doesn't work with CPUs yet. But I plan to work on that later > > as that's not related to this patch series. > > So in case of CPUs, the cache will be the parent device and CPU be the > children ? And CPUs nodes will contain the required-opps property ? No, the CPUs will be the "parent" and the cache will be the "child". CPU is a special case when it comes to the actual software (not DT) as we'll need the devfreq governor to look at all the CPUfreq policies to decide the cache frequency (max of all their requirements). I think "master" and "slave" would have been a better term as the master device determines its frequency using whatever means and the "slave" device just "follows" the master device. -Saravana
Re: [PATCH 1/2 v9] serial: mctrl_gpio: Check if GPIO property exisits before requesting it
Hi Geert,
On 24.06.19 17:35, Geert Uytterhoeven wrote:
On Mon, Jun 24, 2019 at 5:29 PM Stefan Roese wrote:
On 24.06.19 10:42, Geert Uytterhoeven wrote:
On Thu, Jun 20, 2019 at 8:24 AM Stefan Roese wrote:
This patch adds a check for the GPIOs property existence, before the
GPIO is requested. This fixes an issue seen when the 8250 mctrl_gpio
support is added (2nd patch in this patch series) on x86 platforms using
ACPI.
Here Mika's comments from 2016-08-09:
"
I noticed that with v4.8-rc1 serial console of some of our Broxton
systems does not work properly anymore. I'm able to see output but input
does not work.
I bisected it down to commit 4ef03d328769eddbfeca1f1c958fdb181a69c341
("tty/serial/8250: use mctrl_gpio helpers").
The reason why it fails is that in ACPI we do not have names for GPIOs
(except when _DSD is used) so we use the "idx" to index into _CRS GPIO
resources. Now mctrl_gpio_init_noauto() goes through a list of GPIOs
calling devm_gpiod_get_index_optional() passing "idx" of 0 for each. The
UART device in Broxton has following (simplified) ACPI description:
Device (URT4)
{
...
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x003A
}
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
"\\_SB.GPO0", 0x00, ResourceConsumer)
{
0x003D
}
})
In this case it finds the first GPIO (0x003A which happens to be RX pin
for that UART), turns it into GPIO which then breaks input for the UART
device. This also breaks systems with bluetooth connected to UART (those
typically have some GPIOs in their _CRS).
Any ideas how to fix this?
We cannot just drop the _CRS index lookup fallback because that would
break many existing machines out there so maybe we can limit this to
only DT enabled machines. Or alternatively probe if the property first
exists before trying to acquire the GPIOs (using
device_property_present()).
"
This patch implements the fix suggested by Mika in his statement above.
Signed-off-by: Stefan Roese
--- a/drivers/tty/serial/serial_mctrl_gpio.c
+++ b/drivers/tty/serial/serial_mctrl_gpio.c
@@ -116,6 +117,19 @@ struct mctrl_gpios *mctrl_gpio_init_noauto(struct device
*dev, unsigned int idx)
for (i = 0; i < UART_GPIO_MAX; i++) {
enum gpiod_flags flags;
+ char *gpio_str;
+ bool present;
+
+ /* Check if GPIO property exists and continue if not */
+ gpio_str = kasprintf(GFP_KERNEL, "%s-gpios",
+mctrl_gpios_desc[i].name);
This will silently break DTBs using "(cts|dsr|dcd|rng|rts|dtr)-gpio" instead
of "(cts|dsr|dcd|rng|rts|dtr)-gpios".
Should both options be supported ("cts-gpio" vs "cts-gpios")?
Documentation/devicetree/bindings/serial/serial.txt only mentions
the "-gpios" variant.
Well, the "-gpio" variant is deprecated, but still supported by
devm_gpiod_get_index_optional(), and there are active users in upstream
DTS files.
My main objection is (trying to) replicate the matching logic inside
gpiolib.c, causing subtle semantic differences. And keeping it consistent,
of course.
It would be nice if this could be fixed inside acpi_find_gpio(), so
users don't need to be updated. There may be other subsystems where
the difference between DT and ACPI may cause issues, unbeknownst.
Sure, I can fix this. I would prefer to do this in a follow-up patch
though, if nobody objects.
Thanks,
Stefan
Re: [PATCH V6 3/3] arm64/mm: Enable memory hot remove
On 06/24/2019 10:22 PM, Mark Rutland wrote:
> On Fri, Jun 21, 2019 at 03:35:53PM +0100, Steve Capper wrote:
>> Hi Anshuman,
>>
>> On Wed, Jun 19, 2019 at 09:47:40AM +0530, Anshuman Khandual wrote:
>>> The arch code for hot-remove must tear down portions of the linear map and
>>> vmemmap corresponding to memory being removed. In both cases the page
>>> tables mapping these regions must be freed, and when sparse vmemmap is in
>>> use the memory backing the vmemmap must also be freed.
>>>
>>> This patch adds a new remove_pagetable() helper which can be used to tear
>>> down either region, and calls it from vmemmap_free() and
>>> ___remove_pgd_mapping(). The sparse_vmap argument determines whether the
>>> backing memory will be freed.
>>>
>>> remove_pagetable() makes two distinct passes over the kernel page table.
>>> In the first pass it unmaps, invalidates applicable TLB cache and frees
>>> backing memory if required (vmemmap) for each mapped leaf entry. In the
>>> second pass it looks for empty page table sections whose page table page
>>> can be unmapped, TLB invalidated and freed.
>>>
>>> While freeing intermediate level page table pages bail out if any of its
>>> entries are still valid. This can happen for partially filled kernel page
>>> table either from a previously attempted failed memory hot add or while
>>> removing an address range which does not span the entire page table page
>>> range.
>>>
>>> The vmemmap region may share levels of table with the vmalloc region.
>>> There can be conflicts between hot remove freeing page table pages with
>>> a concurrent vmalloc() walking the kernel page table. This conflict can
>>> not just be solved by taking the init_mm ptl because of existing locking
>>> scheme in vmalloc(). Hence unlike linear mapping, skip freeing page table
>>> pages while tearing down vmemmap mapping.
>>>
>>> While here update arch_add_memory() to handle __add_pages() failures by
>>> just unmapping recently added kernel linear mapping. Now enable memory hot
>>> remove on arm64 platforms by default with ARCH_ENABLE_MEMORY_HOTREMOVE.
>>>
>>> This implementation is overall inspired from kernel page table tear down
>>> procedure on X86 architecture.
>>>
>>> Acked-by: David Hildenbrand
>>> Signed-off-by: Anshuman Khandual
>>> ---
>>
>> FWIW:
>> Acked-by: Steve Capper
>>
>> One minor comment below though.
>>
>>> arch/arm64/Kconfig | 3 +
>>> arch/arm64/mm/mmu.c | 290
>>> ++--
>>> 2 files changed, 284 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 6426f48..9375f26 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -270,6 +270,9 @@ config HAVE_GENERIC_GUP
>>> config ARCH_ENABLE_MEMORY_HOTPLUG
>>> def_bool y
>>>
>>> +config ARCH_ENABLE_MEMORY_HOTREMOVE
>>> + def_bool y
>>> +
>>> config SMP
>>> def_bool y
>>>
>>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>>> index 93ed0df..9e80a94 100644
>>> --- a/arch/arm64/mm/mmu.c
>>> +++ b/arch/arm64/mm/mmu.c
>>> @@ -733,6 +733,250 @@ int kern_addr_valid(unsigned long addr)
>>>
>>> return pfn_valid(pte_pfn(pte));
>>> }
>>> +
>>> +#ifdef CONFIG_MEMORY_HOTPLUG
>>> +static void free_hotplug_page_range(struct page *page, size_t size)
>>> +{
>>> + WARN_ON(!page || PageReserved(page));
>>> + free_pages((unsigned long)page_address(page), get_order(size));
>>> +}
>>
>> We are dealing with power of 2 number of pages, it makes a lot more
>> sense (to me) to replace the size parameter with order.
>>
>> Also, all the callers are for known compile-time sizes, so we could just
>> translate the size parameter as follows to remove any usage of get_order?
>> PAGE_SIZE -> 0
>> PMD_SIZE -> PMD_SHIFT - PAGE_SHIFT
>> PUD_SIZE -> PUD_SHIFT - PAGE_SHIFT
>
> Now that I look at this again, the above makes sense to me.
>
> I'd requested the current form (which I now realise is broken), since
> back in v2 the code looked like:
>
> static void free_pagetable(struct page *page, int order)
> {
> ...
> free_pages((unsigned long)page_address(page), order);
> ...
> }
>
> ... with callsites looking like:
>
> free_pagetable(pud_page(*pud), get_order(PUD_SIZE));
>
> ... which I now see is off by PAGE_SHIFT, and we inherited that bug in
> the current code, so the calculated order is vastly larger than it
> should be. It's worrying that doesn't seem to be caught by anything in
> testing. :/
get_order() returns the minimum page allocation order for a given size
which already takes into account PAGE_SHIFT i.e get_order(PAGE_SIZE)
returns 0.
>
> Anshuman, could you please fold in Steve's suggested change? I'll look
> at the rest of the series shortly, so no need to resend that right away,
> but it would be worth sorting out.
get_order() is already optimized for built in constants. But will replace
with absolute constants as Steve mentioned if that is preferred.
Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
On 24-06-19, 22:00, Saravana Kannan wrote: > All of the cases above are some real world scenarios I've come across. > CPU and L2/L3 on ARM systems are a good example of (2) but the passive > governor doesn't work with CPUs yet. But I plan to work on that later > as that's not related to this patch series. So in case of CPUs, the cache will be the parent device and CPU be the children ? And CPUs nodes will contain the required-opps property ? -- viresh
Re: [PATCH v2] phy: meson-g12a-usb3-pcie: disable locking for cr_regmap
On 24/06/19 6:30 PM, Neil Armstrong wrote:
> Hi Kishon,
>
> On 05/06/2019 11:02, Neil Armstrong wrote:
>> Locking is not needed for the phy_g12a_usb3_pcie_cr_bus_read/write() and
>> currently it causes the following BUG because of the usage of the
>> regmap_read_poll_timeout() running in spinlock_irq, configured by regmap
>> fast_io.
>>
>> Simply disable locking in the cr_regmap config since it's only used from the
>> PHY init callback function.
>
> Gentle ping,
> Is the commit log right now ?
merged now, thanks!
-Kishon
>
> Thanks,
> Neil
>
>>
>> BUG: sleeping function called from invalid context at
>> drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c:85
>> in_atomic(): 1, irqs_disabled(): 128, pid: 60, name: kworker/3:1
>> [snip]
>> Workqueue: events deferred_probe_work_func
>> Call trace:
>> dump_backtrace+0x0/0x190
>> show_stack+0x14/0x20
>> dump_stack+0x90/0xb4
>> ___might_sleep+0xec/0x110
>> __might_sleep+0x50/0x88
>> phy_g12a_usb3_pcie_cr_bus_addr.isra.0+0x80/0x1a8
>> phy_g12a_usb3_pcie_cr_bus_read+0x34/0x1d8
>> _regmap_read+0x60/0xe0
>> _regmap_update_bits+0xc4/0x110
>> regmap_update_bits_base+0x60/0x90
>> phy_g12a_usb3_pcie_init+0xdc/0x210
>> phy_init+0x74/0xd0
>> dwc3_meson_g12a_probe+0x2cc/0x4d0
>> platform_drv_probe+0x50/0xa0
>> really_probe+0x20c/0x3b8
>> driver_probe_device+0x68/0x150
>> __device_attach_driver+0xa8/0x170
>> bus_for_each_drv+0x64/0xc8
>> __device_attach+0xd8/0x158
>> device_initial_probe+0x10/0x18
>> bus_probe_device+0x90/0x98
>> deferred_probe_work_func+0x94/0xe8
>> process_one_work+0x1e0/0x338
>> worker_thread+0x230/0x458
>> kthread+0x134/0x138
>> ret_from_fork+0x10/0x1con,
>>
>> Fixes: 36077e16c050 ("phy: amlogic: Add Amlogic G12A USB3 + PCIE Combo PHY
>> Driver")
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
>> b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
>> index 6233a7979a93..ac322d643c7a 100644
>> --- a/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
>> +++ b/drivers/phy/amlogic/phy-meson-g12a-usb3-pcie.c
>> @@ -188,7 +188,7 @@ static const struct regmap_config
>> phy_g12a_usb3_pcie_cr_regmap_conf = {
>> .reg_read = phy_g12a_usb3_pcie_cr_bus_read,
>> .reg_write = phy_g12a_usb3_pcie_cr_bus_write,
>> .max_register = 0x,
>> -.fast_io = true,
>> +.disable_locking = true,
>> };
>>
>> static int phy_g12a_usb3_init(struct phy *phy)
>>
>
Re: [PATCH 1/2] net: macb: Fix compilation on systems without COMMON_CLK
On Tue, Jun 25, 2019 at 4:17 AM wrote: > > On 24/06/2019 at 11:57, Palmer Dabbelt wrote: > > External E-Mail > > > > > > On Mon, 24 Jun 2019 02:40:21 PDT (-0700), nicolas.fe...@microchip.com wrote: > >> On 24/06/2019 at 08:16, Palmer Dabbelt wrote: > >>> External E-Mail > >>> > >>> > >>> The patch to add support for the FU540-C000 added a dependency on > >>> COMMON_CLK, but didn't express that via Kconfig. This fixes the build > >>> failure by adding CONFIG_MACB_FU540, which depends on COMMON_CLK and > >>> conditionally enables the FU540-C000 support. > >> > >> Let's try to limit the use of #ifdef's throughout the code. We are > >> using them in this driver but only for the hot paths and things that > >> have an impact on performance. I don't think it's the case here: so > >> please find another option => NACK. > > > > OK. Would you accept adding a Kconfig dependency of the generic MACB > > driver on > > COMMON_CLK, as suggested in the cover letter? > > Yes: all users of this peripheral have COMMON_CLK set. > You can remove it from the PCI wrapper then. > Yes, +1, both Zynq and ZynqMP have COMMON_CLK set, thanks. Regards, Harini
Re: [PATCH v2] Bluetooth: btrtl: HCI reset on close for Realtek BT chip
On Mon, Jun 24, 2019 at 2:24 PM Jian-Hong Pan wrote:
> Realtek RTL8822BE BT chip on ASUS X420FA cannot be turned on correctly
> after on-off several times. Bluetooth daemon sets BT mode failed when
> this issue happens.
You could also mention that scanning must be active while turning off
for this bug to be hit.
> bluetoothd[1576]: Failed to set mode: Failed (0x03)
>
> If BT is tunred off, then turned on again, it works correctly again.
Typo: turned
> According to the vendor driver, the HCI_QUIRK_RESET_ON_CLOSE flag is set
> during probing. So, this patch makes Realtek's BT reset on close to fix
> this issue.
Checked the vendor driver - I see what you are referring to, so the
change seems correct.
#if HCI_VERSION_CODE >= KERNEL_VERSION(3, 7, 1)
if (!reset)
set_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);
RTKBT_DBG("set_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);");
#endif
However I'm pretty sure this is not saying that kernel 3.7.0 did not
need the reset. I think it just means that the flag did not exist
before Linux-3.7.1, so they added the ifdef to add some level of
compatibility with older kernel versions. I think you can remove
"since kernel v3.7.1." from the comment.
After those changes you can add:
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203429
Reviewed-by: Daniel Drake
> Signed-off-by: Jian-Hong Pan
> ---
> v2:
> - According to the vendor driver, it makes "all" Realtek's BT reset on
>close. So, this version makes it the same.
> - Change to the new subject for all Realtek BT chips.
>
> drivers/bluetooth/btrtl.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/bluetooth/btrtl.c b/drivers/bluetooth/btrtl.c
> index 208feef63de4..be6d5f7e1e44 100644
> --- a/drivers/bluetooth/btrtl.c
> +++ b/drivers/bluetooth/btrtl.c
> @@ -630,6 +630,10 @@ int btrtl_setup_realtek(struct hci_dev *hdev)
> return PTR_ERR(btrtl_dev);
>
> ret = btrtl_download_firmware(hdev, btrtl_dev);
> + /* According to the vendor driver, BT must be reset on close to avoid
> +* firmware crash since kernel v3.7.1.
> +*/
> + set_bit(HCI_QUIRK_RESET_ON_CLOSE, >quirks);
>
> btrtl_free(btrtl_dev);
>
> --
> 2.22.0
>
Re: [PATCH v4 0/7] Hexdump Enhancements
On Tue, 2019-06-25 at 13:17 +1000, Alastair D'Silva wrote: > From: Alastair D'Silva > > Apologies for the large CC list, it's a heads up for those responsible > for subsystems where a prototype change in generic code causes a change > in those subsystems. [] > The default behaviour of hexdump is unchanged, however, the prototype > for hex_dump_to_buffer() has changed, and print_hex_dump() has been > renamed to print_hex_dump_ext(), with a wrapper replacing it for > compatibility with existing code, which would have been too invasive to > change. I believe this cover letter is misleading. The point of the wrapper is to avoid unnecessary changes in existing code.
Re: [PATCH] rtlwifi: rtl8188ee: remove redundant assignment to rtstatus
Colin King wrote:
> From: Colin Ian King
>
> Variable rtstatus is being initialized with a value that is never read
> as rtstatus is being re-assigned a little later on. The assignment is
> redundant and hence can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
25a986e426b0 rtlwifi: rtl8188ee: remove redundant assignment to rtstatus
--
https://patchwork.kernel.org/patch/10983111/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH][next] qtnfmac: Use struct_size() in kzalloc()
"Gustavo A. R. Silva" wrote:
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct ieee80211_regdomain {
> ...
> struct ieee80211_reg_rule reg_rules[];
> };
>
> instance = kzalloc(sizeof(*mac->rd) +
> sizeof(struct ieee80211_reg_rule) *
> count, GFP_KERNEL);
>
> Instead of leaving these open-coded and prone to type mistakes, we can
> now use the new struct_size() helper:
>
> instance = kzalloc(struct_size(instance, reg_rules, count), GFP_KERNEL);
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-by: Gustavo A. R. Silva
> Reviewed-by: Sergey Matyukevich
Patch applied to wireless-drivers-next.git, thanks.
9a1ace64ca3b qtnfmac: Use struct_size() in kzalloc()
--
https://patchwork.kernel.org/patch/10982675/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
On Mon, Jun 24, 2019 at 9:11 PM Viresh Kumar wrote:
>
> On 24-06-19, 15:17, Saravana Kannan wrote:
> > Here's an example. This can't be done today, but can be done with this
> > change.
> >
> > In arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi you have something
> > like this with the following changes:
> >
> > bus_g2d_400: bus0 {
> > compatible = "samsung,exynos-bus";
> > clocks = <_top CLK_ACLK_G2D_400>;
> > clock-names = "bus";
> > operating-points-v2 = <_g2d_400_opp_table>;
> > status = "disabled";
> > };
> >
> > bus_noc2: bus9 {
> > compatible = "samsung,exynos-bus";
> > clocks = <_mif CLK_ACLK_BUS2_400>;
> > clock-names = "bus";
> > operating-points-v2 = <_noc2_opp_table>;
> > status = "disabled";
> > };
>
> And what is the relation between these two busses ?
I can't speak for the Exynos hardware. Maybe Chanwoo knows.
But a couple of common reasons to do this between devices are:
1. These were the combination of frequencies that were
validated/screen during the manufacturing process.
2. These are the sensible performance combinations between two devices
interacting with each other. So that when one runs fast the other
doesn't become the bottleneck.
3. Hardware bugs requiring some kind of frequency ratio between devices.
All of the cases above are some real world scenarios I've come across.
CPU and L2/L3 on ARM systems are a good example of (2) but the passive
governor doesn't work with CPUs yet. But I plan to work on that later
as that's not related to this patch series.
-Saravana
> > bus_g2d_400_opp_table: opp_table2 {
> > compatible = "operating-points-v2";
> > opp-shared;
> >
> > opp-4 {
> > opp-hz = /bits/ 64 <4>;
> > opp-microvolt = <1075000>;
> > + required-opps = <_400>;
> > };
> > opp-26700 {
> > opp-hz = /bits/ 64 <26700>;
> > opp-microvolt = <100>;
> > + required-opps = <_200>;
> > };
> > opp-2 {
> > opp-hz = /bits/ 64 <2>;
> > opp-microvolt = <975000>;
> > + required-opps = <_200>;
> > };
> > opp-16000 {
> > opp-hz = /bits/ 64 <16000>;
> > opp-microvolt = <962500>;
> > + required-opps = <_134>;
> > };
> > opp-13400 {
> > opp-hz = /bits/ 64 <13400>;
> > opp-microvolt = <95>;
> > + required-opps = <_134>;
> > };
> > opp-1 {
> > opp-hz = /bits/ 64 <1>;
> > opp-microvolt = <937500>;
> > + required-opps = <_100>;
> > };
> > };
> >
> > bus_noc2_opp_table: opp_table6 {
> > compatible = "operating-points-v2";
> >
> > - opp-4 {
> > + noc2_400: opp-4 {
> > opp-hz = /bits/ 64 <4>;
> > };
> > - opp-2 {
> > + noc2_200: opp-2 {
> > opp-hz = /bits/ 64 <2>;
> > };
> > - opp-13400 {
> > + noc2_134: opp-13400 {
> > opp-hz = /bits/ 64 <13400>;
> > };
> > - opp-1 {
> > + noc2_100: opp-1 {
> > opp-hz = /bits/ 64 <1>;
> > };
> > };
> >
> > Thanks,
> > Saravana
>
> --
> viresh
Re: [PATCH] rtlwifi: remove redundant assignment to variable k
Colin King wrote:
> From: Colin Ian King
>
> The assignment of 0 to variable k is never read once we break out of
> the loop, so the assignment is redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
Patch applied to wireless-drivers-next.git, thanks.
f0822dfc5887 rtlwifi: remove redundant assignment to variable k
--
https://patchwork.kernel.org/patch/10970261/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rtlwifi: remove redundant assignment to variable badworden
Colin King wrote:
> From: Colin Ian King
>
> The variable badworden is assigned with a value that is never read and
> it is re-assigned a new value immediately afterwards. The assignment is
> redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King
> Acked-by: Larry Finger
Patch applied to wireless-drivers-next.git, thanks.
5315f9d40191 rtlwifi: remove redundant assignment to variable badworden
--
https://patchwork.kernel.org/patch/10969175/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [RFC PATCH 00/11] tracing: of: Boot time tracing using devicetree
Hi Frank, On Mon, 24 Jun 2019 15:31:07 -0700 Frank Rowand wrote: > >>> Currently, kernel support boot-time tracing using kernel command-line > >>> parameters. But that is very limited because of limited expressions > >>> and limited length of command line. Recently, useful features like > >>> histogram, synthetic events, etc. are being added to ftrace, but it is > >>> clear that we can not expand command-line options to support these > >>> features. > >> > >> "it is clear that we can not expand command-line options" needs a fuller > >> explanation. And maybe further exploration. > > > > Indeed. As an example of tracing settings in the first mail, even for simple > > use-case, the trace command is long and complicated. I think it is hard to > > express that as 1-liner kernel command line. But devicetree looks very good > > for expressing structured data. That is great and I like it :) > > But you could extend the command line paradigm to meet your needs. But the kernel command line is a command line. Would you mean encoding the structured setting in binary format with base64 and pass it? :( > >> Devicetree is NOT for configuration information. This has been discussed > >> over and over again in mail lists, at various conferences, and was also an > >> entire session at plumbers a few years ago: > >> > >> > >> https://elinux.org/Device_tree_future#Linux_Plumbers_2016_Device_Tree_Track > > > > Thanks, I'll check that. I found following discussion in etherpad log, https://elinux.org/Device_tree_plumbers_2016_etherpad If you have data that the kernel does not have a good way to get, that's OK to put into DT. Operating points are OK - but should still be structured well. This sounds like if it is structured well, and there are no other way, we will be able to use DT as a channel. > >> > >> There is one part of device tree that does allow non-hardware description, > >> which is the "chosen" node which is provided to allow communication between > >> the bootloader and the kernel. > > > > Ah, "chosen" will be suit for me :) > > No. This is not communicating boot loader information. Hmm, it's a kind of communication with the operator of the boot loader, since there is an admin or developer behind it. I think the comminication is to communicate with that human. Then if they intend to trace boot process, that is a kind of communication. [...] > >>> - Can we use devicetree for configuring kernel dynamically? > >> > >> No. Sorry. > >> > >> My understanding of this proposal is that it is intended to better > >> support boot time kernel and driver debugging. As an alternate > >> implementation, could you compile the ftrace configuration information > >> directly into a kernel data structure? It seems like it would not be > >> very difficult to populate the data structure data via a few macros. > > > > No, that is not what I intended. My intention was to trace boot up > > process "without recompiling kernel", but with a structured data. > > That is debugging. Or if you want to be pedantic, a complex performance > measurement of the boot process (more than holding a stopwatch in your > hand). Yeah, that's right. > Recompiling a single object file (containing the ftrace command data) > and re-linking the kernel is not a big price in that context). No, if I can use DT, I can choose one of them while boot up. That will be a big difference. (Of course for that purpose, I should work on boot loader to support DT overlay) > Or if > you create a new communication channel, you will have the cost of > creating that data object (certainly not much different than compiling > a devicetree) and have the bootloader provide the ftrace data object > to the kernel. Yes, and for me, that sounds like just a reinvention of the wheel. If I can reuse devicetree infrastructure, it is easily done (as I implemented in this series. It's just about 500LOC (and YAML document) I can clone drivers/of/ code only for that new communication channel, but that makes no one happy. :( > > For such purpose, we have to implement a tool to parse and pack the > > data and a channel to load it at earlier stage in bootloader. And > > those are already done by devicetree. Thus I thought I could get a > > piggyback on devicetree. > > Devicetree is not the universal dumping ground for communicating > information to a booting kernel. Please create another communication > channel. Why should we so limit the availability of even a small corner of existing open source software...? Thank you, -- Masami Hiramatsu
Re: [PATCH] perf cs-etm: Improve completeness for kernel address space
Hi Arnaldo,
On Mon, Jun 24, 2019 at 04:00:09PM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> > > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > > > index 0c7776b51045..ae831f836c70 100644
> > > > --- a/tools/perf/util/cs-etm.c
> > > > +++ b/tools/perf/util/cs-etm.c
> > > > @@ -613,10 +613,34 @@ static void cs_etm__free(struct perf_session
> > > > *session)
> > > > static u8 cs_etm__cpu_mode(struct cs_etm_queue *etmq, u64 address)
> > > > {
> > > > struct machine *machine;
> > > > + u64 fixup_kernel_start = 0;
> > > > + const char *arch;
> > > >
> > > > machine = etmq->etm->machine;
> > > > + arch = perf_env__arch(machine->env);
> > > >
> > > > - if (address >= etmq->etm->kernel_start) {
> > > > + /*
> > > > +* Since arm and arm64 specify some memory regions prior to
> > > > +* 'kernel_start', kernel addresses can be less than
> > > > 'kernel_start'.
> > > > +*
> > > > +* For arm architecture, the 16MB virtual memory space prior to
> > > > +* 'kernel_start' is allocated to device modules, a PMD table if
> > > > +* CONFIG_HIGHMEM is enabled and a PGD table.
> > > > +*
> > > > +* For arm64 architecture, the root PGD table, device module
> > > > memory
> > > > +* region and BPF jit region are prior to 'kernel_start'.
> > > > +*
> > > > +* To reflect the complete kernel address space, compensate
> > > > these
> > > > +* pre-defined regions for kernel start address.
> > > > +*/
> > > > + if (!strcmp(arch, "arm64"))
> > > > + fixup_kernel_start = etmq->etm->kernel_start -
> > > > +ARM64_PRE_START_SIZE;
> > > > + else if (!strcmp(arch, "arm"))
> > > > + fixup_kernel_start = etmq->etm->kernel_start -
> > > > +ARM_PRE_START_SIZE;
> > >
> > > I will test your work but from a quick look wouldn't it be better to
> > > have a single define name here? From looking at the modifications you
> > > did to Makefile.config there doesn't seem to be a reason to have two.
> >
> > Thanks for suggestion. I changed to use single define
> > ARM_PRE_START_SIZE and sent patch v2 [1].
> >
> > If possible, please test patch v2.
> >
> > Thanks,
> > Leo Yan
>
> So just for the record, I'm waiting for Mathieu on this one, i.e. for
> him to test/ack v3.
Yes, this makes sense. I'd like to get Mathieu's green light as well,
it needs to take much time to build llvm/clang on SBC, so it's no rush.
Thanks,
Leo Yan
Re: [PATCH 2/2] mwifiex: use 'total_ie_len' in mwifiex_update_bss_desc_with_ie()
Brian Norris wrote: > This is clearer than copy/pasting the magic number '+ 2' around, and it > even saves the need for one existing comment. > > Cc: Takashi Iwai > Signed-off-by: Brian Norris > Reviewed-by: Takashi Iwai This depends on: 63d7ef36103d mwifiex: Don't abort on small, spec-compliant vendor IEs Patch set to Awaiting Upstream. -- https://patchwork.kernel.org/patch/10996893/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[LINUX PATCH v17 2/2] mtd: rawnand: pl353: Add basic driver for arm pl353 smc nand interface
Add driver for arm pl353 static memory controller nand interface. This controller is used in Xilinx Zynq SoC for interfacing the NAND flash memory. Reviewed-by: Helmut Grohne Signed-off-by: Naga Sureshkumar Relli --- xilinx zynq TRM link: https://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf ARM pl353 smc TRM link: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0380g/DDI0380G_smc_pl350_series_r2p1_trm.pdf -> Tested Micron MT29F2G08ABAEAWP (On-die capable) and AMD/Spansion S34ML01G1. -> Tested both x8 and x16 bus-widths. -> Tested ubifs, mtd_debug tools and mtd-tests which exists in kernel as modules. -> Tested jffs2 SMC memory controller driver is at drivers/memory/pl353-smc.c Changes in v17: - This patch fixes the comments given by Helmut Grohne - Removed struct clk *mclk from struct pl353_nand_controller, as it is required only once during probe, so declare it inside the probe - Merged NAND_OP_DATA_IN_INSTR and NAND_OP_DATA_OUT_INSTR as single case in switch - Added updated Makefile and Kconfig file - Added pl353_nand_wait_ready(), in pl353_nand_write_page_raw() to wait for write to complete Changes in v16: - Removed unnecessary comments Changes in v15: All the comments given by Helmut Grohne to v14 are addressed in this series as mentioned below. - Removed below unused macros PL353_NAND_CMD_PHASE, PL353_NAND_DATA_PHASE and PL353_NAND_ECC_CONFIG - Used cond_resched() instead of cpu_relax() to eleminate the CPU spin for a full second - changed the size of cmnds[4] to cmnds[2] - Removed the unused variable end_cmd in struct pl353_nfc_op - Added new variable u16 addrs_56, instead of u32 addr5 and u32 addr6 - Removed the unused variable cle_ale_delay_ns in struct pl353_nfc_op - Completely changed the nand_offset calculation, taken new varibale called dataphase_addrflags and eleminated the casting with __force just used offset + flags - in pl353_ecc_ooblayout64_free(), removed checking of section with ecc.steps, as section is 0 here - simplified the pl353_wait_for_dev_ready() and pl353_wait_for_ecc_done() - Updated the nfc_op->addrs calculation in pl353_nfc_parse_instructions() - Removed cond_delay(), instead used ndelay(), as it is sufficient - in pl353_nand_exec_op(), instead of assigning end_cmd twice, just assign it once by nfc_op.cmnds[1] - changed if (reading) to else in pl353_nand_exec_op() - Removed int err variable in pl353_nand_ecc_init(), instead just used single variable ret - Changed reading clock value by name rather than index in pl353_nand_probe() - Instead of always calling clk_get_rate(), stored it in the probe to a varaible and use it later Changes in v14: - Removed legacy hooks as per Miquel comments Changes in v13: - Rebased the driver to mtd/next Changes in v12: - Rebased the driver on top of v4.19 nand tree - Removed nand_scan_ident() and nand_scan_tail(), and added nand_controller_ops with ->attach_chip() and used nand_scan() instead. - Renamed pl353_nand_info structure to pl353_nand_controller - Renamed nand_base and nandaddr in pl353_nand_controller to 'regs' and 'buf_addr' - Added new API pl353_wait_for_ecc_done() to wait for ecc done and call it from pl353_nand_write_page_hwecc() and pl353_nand_read_page_hwecc() - Defined new macro for max ECC blocks - Added return value check for ecc.calculate() - Renamed pl353_nand_cmd_function() to pl353_nand_exec_op_cmd() - Added x16 bus-width support - The dependent driver pl353-smc is already reviewed and hence dropped the smc driver Changes in v11: - Removed Documentation patch and added the required info in driver as per Boris comments. - Removed unwanted variables from pl353_nand_info as per Miquel comments - Removed IO_ADDR_R/W. - Replaced onhot() with hweight32() - Defined macros for static values in function pl353_nand_correct_data() - Removed all unnecessary delays - Used nand_wait_ready() where ever is required - Modifed the pl353_setup_data_interface() logic as per Miquel comments. - Taken array instead of 7 values in pl353_setup_data_interface() and pass it to smc driver. - Added check to collect the return value of mtd_device_register(). Changes in 10: - Typos correction like nand to NAND and soc to SOC etc.. - Defined macros for the values in pl353_nand_calculate_hwecc() - Modifed ecc_status from int to char in pl353_nand_calculate_hwecc() - Changed the return type form int to bool to the function onehot() - Removed udelay(1000) in pl353_cmd_function, as it is not required - Dropped ecc->hwctl = NULL in pl353_ecc_init() - Added an error message in pl353_ecc_init(), when there is no matching oobsize - Changed the variable from xnand to xnfc - Added logic to get mtd->name from DT, if it is specified in DT Changes in v9: - Addressed the below comments given by Miquel - instead of using pl353_nand_write32, use directly writel_relaxed - Fixed check patch warnings - Renamed
[LINUX PATCH v17 1/2] mtd: rawnand: nand_micron: Do not over write driver's read_page()/write_page()
Add check before assigning chip->ecc.read_page() and chip->ecc.write_page()
Signed-off-by: Naga Sureshkumar Relli
---
drivers/mtd/nand/raw/nand_micron.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/nand_micron.c
b/drivers/mtd/nand/raw/nand_micron.c
index cbd4f09ac178..565f2696c747 100644
--- a/drivers/mtd/nand/raw/nand_micron.c
+++ b/drivers/mtd/nand/raw/nand_micron.c
@@ -500,8 +500,11 @@ static int micron_nand_init(struct nand_chip *chip)
chip->ecc.size = 512;
chip->ecc.strength = chip->base.eccreq.strength;
chip->ecc.algo = NAND_ECC_BCH;
- chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
- chip->ecc.write_page = micron_nand_write_page_on_die_ecc;
+ if (!chip->ecc.read_page)
+ chip->ecc.read_page = micron_nand_read_page_on_die_ecc;
+
+ if (!chip->ecc.write_page)
+ chip->ecc.write_page =
micron_nand_write_page_on_die_ecc;
if (ondie == MICRON_ON_DIE_MANDATORY) {
chip->ecc.read_page_raw = nand_read_page_raw_notsupp;
--
2.17.1
Re: [PATCH] mwifiex: drop 'set_consistent_dma_mask' log message
Brian Norris wrote: > This message is pointless. > > While we're at it, include the error code in the error message, which is > not pointless. > > Signed-off-by: Brian Norris Patch applied to wireless-drivers-next.git, thanks. f7369179ad32 mwifiex: drop 'set_consistent_dma_mask' log message -- https://patchwork.kernel.org/patch/10975823/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] mwifiex: print PCI mmap with %pK
Brian Norris wrote: > Unadorned '%p' has restrictive policies these days, such that it usually > just prints garbage at early boot (see > Documentation/core-api/printk-formats.rst, "kernel will print > ``(ptrval)`` until it gathers enough entropy"). Annotating with %pK > (for "kernel pointer") allows the kptr_restrict sysctl to control > printing policy better. > > We might just as well drop this message entirely, but this fix was easy > enough for now. > > Signed-off-by: Brian Norris Patch applied to wireless-drivers-next.git, thanks. 2fc0aa454473 mwifiex: print PCI mmap with %pK -- https://patchwork.kernel.org/patch/10975827/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/2] mwifiex: dispatch/rotate from reorder table atomically
Brian Norris wrote:
> mwifiex_11n_scan_and_dispatch() and
> mwifiex_11n_dispatch_pkt_until_start_win() share similar patterns, where
> they perform a few different actions on the same table, using the same
> lock, but non-atomically. There have been other attempts to clean up
> this sort of behavior, but they have had problems (incomplete;
> introducing new deadlocks).
>
> We can improve these functions' atomicity by queueing up our RX packets
> in a list, to dispatch at the end of the function. This avoids problems
> of another operation modifying the table in between our dispatch and
> rotation operations.
>
> This was inspired by investigations around this:
>
>
> http://lkml.kernel.org/linux-wireless/20181130175957.167031-1-briannor...@chromium.org
> Subject: [4.20 PATCH] Revert "mwifiex: restructure rx_reorder_tbl_lock
> usage"
>
> While the original (now-reverted) patch had good intentions in
> restructuring some of the locking patterns in this driver, it missed an
> important detail: we cannot defer to softirq contexts while already in
> an atomic context. We can help avoid this sort of problem by separating
> the two steps of:
> (1) iterating / clearing the mwifiex reordering table
> (2) dispatching received packets to upper layers
>
> This makes it much harder to make lock recursion mistakes, as these
> two steps no longer need to hold the same locks.
>
> Testing: I've played with a variety of stress tests, including download
> stress tests on the same APs which caught regressions with commit
> 5188d5453bc9 ("mwifiex: restructure rx_reorder_tbl_lock usage"). I've
> primarily tested on Marvell 8997 / PCIe, although I've given 8897 / SDIO
> a quick spin as well.
>
> Signed-off-by: Brian Norris
> Acked-by: Ganapathi Bhat
New warning:
drivers/net/wireless/marvell/mwifiex/wmm.c: In function
'mwifiex_wmm_process_tx':
drivers/net/wireless/marvell/mwifiex/wmm.c:1438:4: warning: 'flags' may be used
uninitialized in this function [-Wmaybe-uninitialized]
mwifiex_11n_aggregate_pkt(priv, ptr, ptr_index, flags);
^~
drivers/net/wireless/marvell/mwifiex/wmm.c:1406:16: note: 'flags' was declared
here
unsigned long flags;
^
2 patches set to Changes Requested.
10976083 [1/2] mwifiex: dispatch/rotate from reorder table atomically
10976087 [2/2] mwifiex: don't disable hardirqs; just softirqs
--
https://patchwork.kernel.org/patch/10976083/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] net: stmmac: add sanity check to device_property_read_u32_array call
Hi Colin,
On Thu, Jun 20, 2019 at 3:34 AM Martin Blumenstingl
wrote:
>
> Hi Colin,
>
> On Wed, Jun 19, 2019 at 8:55 AM Colin Ian King
> wrote:
> >
> > On 19/06/2019 06:13, Martin Blumenstingl wrote:
> > > Hi Colin,
> > >
> > >> Currently the call to device_property_read_u32_array is not error checked
> > >> leading to potential garbage values in the delays array that are then
> > >> used
> > >> in msleep delays. Add a sanity check to the property fetching.
> > >>
> > >> Addresses-Coverity: ("Uninitialized scalar variable")
> > >> Signed-off-by: Colin Ian King
> > > I have also sent a patch [0] to fix initialize the array.
> > > can you please look at my patch so we can work out which one to use?
> > >
> > > my concern is that the "snps,reset-delays-us" property is optional,
> > > the current dt-bindings documentation states that it's a required
> > > property. in reality it isn't, there are boards (two examples are
> > > mentioned in my patch: [0]) without it.
> > >
> > > so I believe that the resulting behavior has to be:
> > > 1. don't delay if this property is missing (instead of delaying for
> > > ms)
> > > 2. don't error out if this property is missing
> > >
> > > your patch covers #1, can you please check whether #2 is also covered?
> > > I tested case #2 when submitting my patch and it worked fine (even
> > > though I could not reproduce the garbage values which are being read
> > > on some boards)
in the meantime I have tested your patch.
when I don't set the "snps,reset-delays-us" property then I get the
following error:
invalid property snps,reset-delays-us
my patch has landed in the meantime: [0]
how should we proceed with your patch?
Martin
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c?id=84ce4d0f9f55b4f4ca4d4edcbb54a23d9dad1aae
linux-next: manual merge of the block tree with the jc_docs tree
Hi all,
Today's linux-next merge of the block tree got a conflict in:
Documentation/fault-injection/nvme-fault-injection.txt
between commit:
10ffebbed550 ("docs: fault-injection: convert docs to ReST and rename to
*.rst")
from the jc_docs tree and commit:
7e31d8215fd8 ("Documentation: nvme: add an example for nvme fault injection")
from the block tree.
I fixed it up (I removed the file and applied the following patch) and
can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging. You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.
From: Stephen Rothwell
Date: Tue, 25 Jun 2019 14:39:46 +1000
Subject: [PATCH] Documentation: nvme: fix for change to rst
Signed-off-by: Stephen Rothwell
---
.../fault-injection/nvme-fault-injection.rst | 58 +++
1 file changed, 58 insertions(+)
diff --git a/Documentation/fault-injection/nvme-fault-injection.rst
b/Documentation/fault-injection/nvme-fault-injection.rst
index bbb1bf3e8650..cdb2e829228e 100644
--- a/Documentation/fault-injection/nvme-fault-injection.rst
+++ b/Documentation/fault-injection/nvme-fault-injection.rst
@@ -118,3 +118,61 @@ Message from dmesg::
cpu_startup_entry+0x6f/0x80
start_secondary+0x187/0x1e0
secondary_startup_64+0xa5/0xb0
+
+Example 3: Inject an error into the 10th admin command
+--
+
+::
+
+ echo 100 > /sys/kernel/debug/nvme0/fault_inject/probability
+ echo 10 > /sys/kernel/debug/nvme0/fault_inject/space
+ echo 1 > /sys/kernel/debug/nvme0/fault_inject/times
+ nvme reset /dev/nvme0
+
+Expected Result::
+
+ After NVMe controller reset, the reinitialization may or may not succeed.
+ It depends on which admin command is actually forced to fail.
+
+Message from dmesg::
+
+ nvme nvme0: resetting controller
+ FAULT_INJECTION: forcing a failure.
+ name fault_inject, interval 1, probability 100, space 1, times 1
+ CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0-rc2+ #2
+ Hardware name: MSI MS-7A45/B150M MORTAR ARCTIC (MS-7A45), BIOS 1.50
04/25/2017
+ Call Trace:
+
+ dump_stack+0x63/0x85
+ should_fail+0x14a/0x170
+ nvme_should_fail+0x38/0x80 [nvme_core]
+ nvme_irq+0x129/0x280 [nvme]
+ ? blk_mq_end_request+0xb3/0x120
+ __handle_irq_event_percpu+0x84/0x1a0
+ handle_irq_event_percpu+0x32/0x80
+ handle_irq_event+0x3b/0x60
+ handle_edge_irq+0x7f/0x1a0
+ handle_irq+0x20/0x30
+ do_IRQ+0x4e/0xe0
+ common_interrupt+0xf/0xf
+
+ RIP: 0010:cpuidle_enter_state+0xc5/0x460
+ Code: ff e8 8f 5f 86 ff 80 7d c7 00 74 17 9c 58 0f 1f 44 00 00 f6 c4 02 0f
85 69 03 00 00 31 ff e8 62 aa 8c ff fb 66 0f 1f 44 00 00 <45> 85 ed 0f 88 37 03
00 00 4c 8b 45 d0 4c 2b 45 b8 48 ba cf f7 53
+ RSP: 0018:88c03dd0 EFLAGS: 0246 ORIG_RAX: ffdc
+ RAX: 9dac25a2ac80 RBX: 88d53760 RCX: 001f
+ RDX: RSI: 2d958403 RDI:
+ RBP: 88c03e18 R08: fff75e35ffb7 R09: 0a49a56c0b48
+ R10: 88c03da0 R11: 1b0c R12: 9dac25a34d00
+ R13: 0006 R14: 0006 R15: 88d53760
+ cpuidle_enter+0x2e/0x40
+ call_cpuidle+0x23/0x40
+ do_idle+0x201/0x280
+ cpu_startup_entry+0x1d/0x20
+ rest_init+0xaa/0xb0
+ arch_call_rest_init+0xe/0x1b
+ start_kernel+0x51c/0x53b
+ x86_64_start_reservations+0x24/0x26
+ x86_64_start_kernel+0x74/0x77
+ secondary_startup_64+0xa4/0xb0
+ nvme nvme0: Could not set queue count (16385)
+ nvme nvme0: IO queues not created
--
2.20.1
--
Cheers,
Stephen Rothwell
pgpdrm_yWs2Qg.pgp
Description: OpenPGP digital signature
Re: [PATCH] p54usb: Fix race between disconnect and firmware loading
Alan Stern wrote: > The syzbot fuzzer found a bug in the p54 USB wireless driver. The > issue involves a race between disconnect and the firmware-loader > callback routine, and it has several aspects. > > One big problem is that when the firmware can't be loaded, the > callback routine tries to unbind the driver from the USB _device_ (by > calling device_release_driver) instead of from the USB _interface_ to > which it is actually bound (by calling usb_driver_release_interface). > > The race involves access to the private data structure. The driver's > disconnect handler waits for a completion that is signalled by the > firmware-loader callback routine. As soon as the completion is > signalled, you have to assume that the private data structure may have > been deallocated by the disconnect handler -- even if the firmware was > loaded without errors. However, the callback routine does access the > private data several times after that point. > > Another problem is that, in order to ensure that the USB device > structure hasn't been freed when the callback routine runs, the driver > takes a reference to it. This isn't good enough any more, because now > that the callback routine calls usb_driver_release_interface, it has > to ensure that the interface structure hasn't been freed. > > Finally, the driver takes an unnecessary reference to the USB device > structure in the probe function and drops the reference in the > disconnect handler. This extra reference doesn't accomplish anything, > because the USB core already guarantees that a device structure won't > be deallocated while a driver is still bound to any of its interfaces. > > To fix these problems, this patch makes the following changes: > > Call usb_driver_release_interface() rather than > device_release_driver(). > > Don't signal the completion until after the important > information has been copied out of the private data structure, > and don't refer to the private data at all thereafter. > > Lock udev (the interface's parent) before unbinding the driver > instead of locking udev->parent. > > During the firmware loading process, take a reference to the > USB interface instead of the USB device. > > Don't take an unnecessary reference to the device during probe > (and then don't drop it during disconnect). > > Signed-off-by: Alan Stern > Reported-and-tested-by: syzbot+200d4bb11b23d9293...@syzkaller.appspotmail.com > CC: > Acked-by: Christian Lamparter Patch applied to wireless-drivers-next.git, thanks. 6e41e2257f10 p54usb: Fix race between disconnect and firmware loading -- https://patchwork.kernel.org/patch/10951527/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH 1/2] tty: ldisc: Fix misuse of proc_dointvec "ldisc_autoload"
On 2019/06/25 12:32, Greg KH wrote:
> On Tue, Jun 25, 2019 at 12:08:00PM +0900, Eiichi Tsukata wrote:
>> /proc/sys/dev/tty/ldisc_autoload assumes given value to be 0 or 1. Use
>> proc_dointvec_minmax instead of proc_dointvec.
>>
>> Fixes: 7c0cca7c847e "(tty: ldisc: add sysctl to prevent autoloading of
>> ldiscs)"
>> Signed-off-by: Eiichi Tsukata
>> ---
>> drivers/tty/tty_ldisc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
>> index e38f104db174..a8ea7a35c94e 100644
>> --- a/drivers/tty/tty_ldisc.c
>> +++ b/drivers/tty/tty_ldisc.c
>> @@ -863,7 +863,7 @@ static struct ctl_table tty_table[] = {
>> .data = _ldisc_autoload,
>> .maxlen = sizeof(tty_ldisc_autoload),
>> .mode = 0644,
>> -.proc_handler = proc_dointvec,
>> +.proc_handler = proc_dointvec_minmax,
>> .extra1 = ,
>> .extra2 = ,
>
> Ah, nice catch. But this really isn't an issue as if you use a bigger
> value, things will not "break", right?
>
Someone may misuse -1 to disable ldisc autoload, but basically it does not
"break".
Thanks,
Eiichi
[RFCv3 4/8] sched/fair: Define core capacity to limit task packing
This patch defines a method name arch_scale_core_capacity which should
return the capacity of the core. This method will be used in the future
patches to determine if the spare capacity is left in the core to pack
jitter tasks.
For some architectures, core capacity does not increase much with the
number of threads( or CPUs) in the core. For such cases, architecture
specific calculations needs to be done to find core capacity.
This patch provides a default implementation for the scaling core capacity.
ToDo: As per Peter's comments, if we are getting rid of SMT capacity then
we need to find a workaround for limiting task packing. I'm working around
that trying to find a solution for the same but would like to get community
response first to have better view.
Signed-off-by: Parth Shah
---
kernel/sched/fair.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index e8c5eb339e35..ff3f88d788d8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5929,6 +5929,25 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
return cpu;
}
+#ifdef CONFIG_SCHED_SMT
+
+#ifndef arch_scale_core_capacity
+static inline unsigned long arch_scale_core_capacity(int first_thread,
+unsigned long smt_cap)
+{
+ /* Default capacity of core is sum of cap of all the threads */
+ unsigned long ret = 0;
+ int sibling;
+
+ for_each_cpu(sibling, cpu_smt_mask(first_thread))
+ ret += cpu_rq(sibling)->cpu_capacity;
+
+ return ret;
+}
+#endif
+
+#endif
+
/*
* Try and locate an idle core/thread in the LLC cache domain.
*/
--
2.17.1
[RFCv3 2/8] sched: Introduce switch to enable TurboSched mode
This patch creates a static key which allows to enable or disable
TurboSched feature at runtime.
This key is added in order to enable the TurboSched feature. The static key
helps in optimizing the scheduler fast-path when the TurboSched feature is
disabled.
The patch also provides get/put methods to keep track of the tasks using
the TurboSched feature. This allows to enable the feature on setting first
task classified as jitter, similarly disable the feature on unsetting of
such last task.
Signed-off-by: Parth Shah
---
kernel/sched/core.c | 20
kernel/sched/sched.h | 9 +
2 files changed, 29 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 19c7204d6351..ef83725bd4b0 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -61,6 +61,26 @@ __read_mostly int scheduler_running;
*/
int sysctl_sched_rt_runtime = 95;
+DEFINE_STATIC_KEY_FALSE(__turbo_sched_enabled);
+static DEFINE_MUTEX(turbo_sched_lock);
+static int turbo_sched_count;
+
+void turbo_sched_get(void)
+{
+ mutex_lock(_sched_lock);
+ if (!turbo_sched_count++)
+ static_branch_enable(&__turbo_sched_enabled);
+ mutex_unlock(_sched_lock);
+}
+
+void turbo_sched_put(void)
+{
+ mutex_lock(_sched_lock);
+ if (!--turbo_sched_count)
+ static_branch_disable(&__turbo_sched_enabled);
+ mutex_unlock(_sched_lock);
+}
+
/*
* __task_rq_lock - lock the rq @p resides on.
*/
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e5599b33ffb8..1f239a960a6d 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2426,3 +2426,12 @@ static inline bool sched_energy_enabled(void)
static inline bool sched_energy_enabled(void) { return false; }
#endif /* CONFIG_ENERGY_MODEL && CONFIG_CPU_FREQ_GOV_SCHEDUTIL */
+
+void turbo_sched_get(void);
+void turbo_sched_put(void);
+DECLARE_STATIC_KEY_FALSE(__turbo_sched_enabled);
+
+static inline bool is_turbosched_enabled(void)
+{
+ return static_branch_unlikely(&__turbo_sched_enabled);
+}
--
2.17.1
[RFCv3 5/8] powerpc: Define Core Capacity for POWER systems
This patch tunes arch_scale_core_capacity for powerpc arch by scaling
capacity w.r.t to the number of online SMT in the core such that for SMT-4,
core capacity is 1.5x the capacity of sibling thread.
Signed-off-by: Parth Shah
---
arch/powerpc/include/asm/topology.h | 4
arch/powerpc/kernel/smp.c | 33 +
2 files changed, 37 insertions(+)
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index f85e2b01c3df..1c777ee67180 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -132,6 +132,10 @@ static inline void shared_proc_topology_init(void) {}
#define topology_sibling_cpumask(cpu) (per_cpu(cpu_sibling_map, cpu))
#define topology_core_cpumask(cpu) (per_cpu(cpu_core_map, cpu))
#define topology_core_id(cpu) (cpu_to_core_id(cpu))
+#define arch_scale_core_capacity powerpc_scale_core_capacity
+
+unsigned long powerpc_scale_core_capacity(int first_smt,
+ unsigned long smt_cap);
int dlpar_cpu_readd(int cpu);
#endif
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ea6adbf6a221..149a3fbf8ed3 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1169,6 +1169,39 @@ static void remove_cpu_from_masks(int cpu)
}
#endif
+#ifdef CONFIG_SCHED_SMT
+/*
+ * Calculate capacity of a core based on the active threads in the core
+ * Scale the capacity of first SM-thread based on total number of
+ * active threads in the respective smt_mask.
+ *
+ * The scaling is done such that for
+ * SMT-4, core_capacity = 1.5x first_cpu_capacity
+ * and for SMT-8, core_capacity multiplication factor is 2x
+ *
+ * So, core_capacity multiplication factor = (1 + smt_mode*0.125)
+ *
+ * @first_cpu: First/any CPU id in the core
+ * @cap: Capacity of the first_cpu
+ */
+unsigned long powerpc_scale_core_capacity(int first_cpu,
+ unsigned long cap)
+{
+ struct cpumask select_idles;
+ struct cpumask *cpus = _idles;
+ int cpu, smt_mode = 0;
+
+ cpumask_and(cpus, cpu_smt_mask(first_cpu), cpu_online_mask);
+
+ /* Find SMT mode from active SM-threads */
+ for_each_cpu(cpu, cpus)
+ smt_mode++;
+
+ /* Scale core capacity based on smt mode */
+ return smt_mode == 1 ? cap : ((cap * smt_mode) >> 3) + cap;
+}
+#endif
+
static inline void add_cpu_to_smallcore_masks(int cpu)
{
struct cpumask *this_l1_cache_map = per_cpu(cpu_l1_cache_map, cpu);
--
2.17.1
[RFCv3 3/8] sched/core: Update turbo_sched count only when required
Use the get/put methods to add/remove the use of TurboSched support, such
that the feature is turned on only if there is atleast one jitter task.
Signed-off-by: Parth Shah
---
kernel/sched/core.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ef83725bd4b0..c7b628d0be2b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1214,10 +1214,13 @@ static void __setscheduler_uclamp(struct task_struct *p,
* Set task to jitter class if Max util is clamped to the least
* possible value
*/
- if (p->uclamp_req[UCLAMP_MAX].bucket_id == 0 && !p->is_jitter)
+ if (p->uclamp_req[UCLAMP_MAX].bucket_id == 0 && !p->is_jitter) {
p->is_jitter = 1;
- else if (p->is_jitter)
+ turbo_sched_get();
+ } else if (p->is_jitter) {
p->is_jitter = 0;
+ turbo_sched_put();
+ }
}
}
@@ -3215,6 +3218,9 @@ static struct rq *finish_task_switch(struct task_struct
*prev)
mmdrop(mm);
}
if (unlikely(prev_state == TASK_DEAD)) {
+ if (unlikely(prev->is_jitter))
+ turbo_sched_put();
+
if (prev->sched_class->task_dead)
prev->sched_class->task_dead(prev);
--
2.17.1
[RFCv3 7/8] sched/fair: Bound non idle core search within LLC domain
This patch specifies the method which returns sched domain to limit the
search for a non idle core. By default, limit the search in LLC domain
which usually includes all the cores across the system.
The select_non_idle_core searches for the non idle cores across whole
system. But in the systems with multiple NUMA domains, the Turbo frequency
can be sustained within the NUMA domain without being affected from other
NUMA. For such case, arch_turbo_domain can be tuned to change domain for
non idle core search.
Signed-off-by: Parth Shah
---
kernel/sched/fair.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 9d11631ce18c..b049c9d73f1d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5973,6 +5973,13 @@ static inline bool core_underutilized(unsigned long
core_util,
return core_util < (core_capacity >> UNDERUTILIZED_THRESHOLD);
}
+#ifndef arch_turbo_domain
+static __always_inline struct cpumask *arch_turbo_domain(int cpu)
+{
+ return sched_domain_span(rcu_dereference(per_cpu(sd_llc, cpu)));
+}
+#endif
+
/*
* Try to find a non idle core in the system with spare capacity
* available for task packing, thereby keeping minimal cores active.
@@ -5983,7 +5990,8 @@ static int select_non_idle_core(struct task_struct *p,
int prev_cpu, int target)
struct cpumask *cpus = this_cpu_cpumask_var_ptr(turbo_sched_mask);
int iter_cpu, sibling;
- cpumask_and(cpus, cpu_online_mask, p->cpus_ptr);
+ cpumask_and(cpus, cpu_online_mask, arch_turbo_domain(prev_cpu));
+ cpumask_and(cpus, cpus, p->cpus_ptr);
for_each_cpu_wrap(iter_cpu, cpus, prev_cpu) {
unsigned long core_util = 0;
--
2.17.1
[RFCv3 6/8] sched/fair: Tune task wake-up logic to pack jitter tasks
The algorithm finds the first non idle core in the system and tries to
place a task in the least utilized CPU in the chosen core. To maintain
cache hotness, work of finding non idle core starts from the prev_cpu,
which also reduces task ping-pong behaviour inside of the core.
This patch defines a new method named core_underutilized() which will
determine if the core utilization is less than 12.5% of its capacity.
Since core with low utilization should not be selected for packing, the
margin of under-utilization is kept at 12.5% of core capacity.
12.5% is an experimental number which identifies whether the core is
considered to be idle or not. For task packing, the algorithm should
select the best core where the task can be accommodated such that it does
not wake up an idle core. But the jitter tasks should not be placed on the
core which is about to go idle. If the core has aggregated utilization of
<12.5%, it may go idle soon and hence packing on such core should be
ignored. The experiment showed that keeping this threshold to 12.5% gives
better decision capability on not selecting the core which will idle out
soon.
Signed-off-by: Parth Shah
---
kernel/sched/fair.c | 116 +++-
1 file changed, 114 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ff3f88d788d8..9d11631ce18c 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5318,6 +5318,8 @@ static void dequeue_task_fair(struct rq *rq, struct
task_struct *p, int flags)
/* Working cpumask for: load_balance, load_balance_newidle. */
DEFINE_PER_CPU(cpumask_var_t, load_balance_mask);
DEFINE_PER_CPU(cpumask_var_t, select_idle_mask);
+/* A cpumask to find active cores in the system. */
+DEFINE_PER_CPU(cpumask_var_t, turbo_sched_mask);
#ifdef CONFIG_NO_HZ_COMMON
@@ -5929,8 +5931,22 @@ static int select_idle_cpu(struct task_struct *p, struct
sched_domain *sd, int t
return cpu;
}
-#ifdef CONFIG_SCHED_SMT
+#ifdef CONFIG_UCLAMP_TASK
+static inline bool is_task_jitter(struct task_struct *p)
+{
+ if (p->is_jitter == 1)
+ return true;
+ return false;
+}
+#else
+static inline bool is_task_jitter(struct task_struct *p)
+{
+ return false;
+}
+#endif
+
+#ifdef CONFIG_SCHED_SMT
#ifndef arch_scale_core_capacity
static inline unsigned long arch_scale_core_capacity(int first_thread,
unsigned long smt_cap)
@@ -5946,6 +5962,81 @@ static inline unsigned long arch_scale_core_capacity(int
first_thread,
}
#endif
+/*
+ * Core is defined as under-utilized in case if the aggregated utilization of a
+ * all the CPUs in a core is less than 12.5%
+ */
+#define UNDERUTILIZED_THRESHOLD 3
+static inline bool core_underutilized(unsigned long core_util,
+ unsigned long core_capacity)
+{
+ return core_util < (core_capacity >> UNDERUTILIZED_THRESHOLD);
+}
+
+/*
+ * Try to find a non idle core in the system with spare capacity
+ * available for task packing, thereby keeping minimal cores active.
+ * Uses first fit algorithm to pack low util jitter tasks on active cores.
+ */
+static int select_non_idle_core(struct task_struct *p, int prev_cpu, int
target)
+{
+ struct cpumask *cpus = this_cpu_cpumask_var_ptr(turbo_sched_mask);
+ int iter_cpu, sibling;
+
+ cpumask_and(cpus, cpu_online_mask, p->cpus_ptr);
+
+ for_each_cpu_wrap(iter_cpu, cpus, prev_cpu) {
+ unsigned long core_util = 0;
+ unsigned long core_cap = arch_scale_core_capacity(iter_cpu,
+ capacity_of(iter_cpu));
+ unsigned long est_util = 0, est_util_enqueued = 0;
+ unsigned long util_best_cpu = ULONG_MAX;
+ int best_cpu = iter_cpu;
+ struct cfs_rq *cfs_rq;
+
+ for_each_cpu(sibling, cpu_smt_mask(iter_cpu)) {
+ __cpumask_clear_cpu(sibling, cpus);
+ core_util += cpu_util(sibling);
+
+ /*
+* Keep track of least utilized CPU in the core
+*/
+ if (cpu_util(sibling) < util_best_cpu) {
+ util_best_cpu = cpu_util(sibling);
+ best_cpu = sibling;
+ }
+ }
+
+ /*
+* Find if the selected task will fit into this core or not by
+* estimating the utilization of the core.
+*/
+ if (!core_underutilized(core_util, core_cap)) {
+ cfs_rq = _rq(best_cpu)->cfs;
+ est_util =
+ READ_ONCE(cfs_rq->avg.util_avg) + task_util(p);
+ est_util_enqueued =
+ READ_ONCE(cfs_rq->avg.util_est.enqueued);
+ est_util_enqueued +=
[RFCv3 8/8] powerpc: Set turbo domain to NUMA node for task packing
This patch provides an powerpc architecture specific implementation for
defining the turbo domain to make searching of the core to be bound within
the NUMA. This provides a way to decrease the searching time for specific
architectures.
Signed-off-by: Parth Shah
---
arch/powerpc/include/asm/topology.h | 3 +++
arch/powerpc/kernel/smp.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/include/asm/topology.h
b/arch/powerpc/include/asm/topology.h
index 1c777ee67180..410b94c9e1a2 100644
--- a/arch/powerpc/include/asm/topology.h
+++ b/arch/powerpc/include/asm/topology.h
@@ -133,10 +133,13 @@ static inline void shared_proc_topology_init(void) {}
#define topology_core_cpumask(cpu) (per_cpu(cpu_core_map, cpu))
#define topology_core_id(cpu) (cpu_to_core_id(cpu))
#define arch_scale_core_capacity powerpc_scale_core_capacity
+#define arch_turbo_domain powerpc_turbo_domain
unsigned long powerpc_scale_core_capacity(int first_smt,
unsigned long smt_cap);
+struct cpumask *powerpc_turbo_domain(int cpu);
+
int dlpar_cpu_readd(int cpu);
#endif
#endif
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 149a3fbf8ed3..856f7233190e 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -1200,6 +1200,11 @@ unsigned long powerpc_scale_core_capacity(int first_cpu,
/* Scale core capacity based on smt mode */
return smt_mode == 1 ? cap : ((cap * smt_mode) >> 3) + cap;
}
+
+inline struct cpumask *powerpc_turbo_domain(int cpu)
+{
+ return cpumask_of_node(cpu_to_node(cpu));
+}
#endif
static inline void add_cpu_to_smallcore_masks(int cpu)
--
2.17.1
[RFCv3 0/8] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations
This is the 3rd version of the patchset to sustain Turbo frequencies for longer durations. The previous versions can be found here: v2: https://lkml.org/lkml/2019/5/15/1258 v1: https://lwn.net/Articles/783959/ The changes in this versions are: v[2] -> v[3]: - Added a new attribute in task_struct to allow per task jitter classification so that scheduler can use this as request to change wakeup path for task packing - Use syscall for jitter classification, removed cgroup based task classification - Use mutex over spinlock to get rid of task sleeping problem - Changed _Bool->int everywhere - Split few patches to have arch specific code separate from core scheduler code ToDo: - Recompute core capacity only during CPU-Hotplug operation - Remove smt capacity v[1] -> v[2]: - No CPU bound tasks' classification, only jitter tasks are classified from the cpu cgroup controller - Use of Spinlock rather than mutex to count number of jitters in the system classified from cgroup - Architecture specific implementation of Core capacity multiplication factor changes dynamically based on the number of active threads in the core - Selection of non idle core in the system is bounded by DIE domain - Use of UCLAMP mechanism to classify jitter tasks - Removed "highutil_cpu_mask", and rather uses sd for DIE domain to find better fit Abstract The modern servers allows multiple cores to run at range of frequencies higher than rated range of frequencies. But the power budget of the system inhibits sustaining these higher frequencies for longer durations. However when certain cores are put to idle states, the power can be effectively channelled to other busy cores, allowing them to sustain the higher frequency. One way to achieve this is to pack tasks onto fewer cores keeping others idle, but it may lead to performance penalty for such tasks and sustaining higher frequencies proves to be of no benefit. But if one can identify unimportant low utilization tasks which can be packed on the already active cores then waking up of new cores can be avoided. Such tasks are short and/or bursty "jitter tasks" and waking up new core is expensive for such case. Current CFS algorithm in kernel scheduler is performance oriented and hence tries to assign any idle CPU first for the waking up of new tasks. This policy is perfect for major categories of the workload, but for jitter tasks, one can save energy by packing them onto the active cores and allow those cores to run at higher frequencies. These patch-set tunes the task wake up logic in scheduler to pack exclusively classified jitter tasks onto busy cores. The work involves the jitter tasks classifications by using syscall based mechanisms. In brief, if we can pack jitter tasks on busy cores then we can save power by keeping other cores idle and allow busier cores to run at turbo frequencies, patch-set tries to meet this solution in simplest manner. Though, there are some challenges in implementing it(like smt_capacity, un-needed arch hooks, etc) and I'm trying to work around that, it would be great to have a discussion around this patches. Implementation == These patches uses UCLAMP mechanism[2] used to clamp utilization from the userspace, which can be used to classify the jitter tasks. The task wakeup logic uses this information to pack such tasks onto cores which are already running busy with CPU intensive tasks. The task packing is done at `select_task_rq_fair` only so that in case of wrong decision load balancer may pull the classified jitter tasks for maximizing performance. Any tasks clamped with cpu.util.max=1 (with sched_setattr syscall) are classified as jitter tasks. We define a core to be non-idle if it is over 12.5% utilized of its capacity; the jitters are packed over these cores using First-fit approach. To demonstrate/benchmark, one can use a synthetic workload generator `turbo_bench.c`[1] available at https://github.com/parthsl/tools/blob/master/benchmarks/turbo_bench.c Following snippet demonstrates the use of TurboSched feature: ``` i=8; ./turbo_bench -t 30 -h $i -n $((i*2)) -j ``` Current implementation uses only jitter classified tasks to be packed on the first busy cores, but can be further optimized by getting userspace input of important tasks and keeping track of such tasks. This leads to optimized searching of non idle cores and also more accurate as userspace hints are safer than auto classified busy cores/tasks. Result == The patch-set proves to be useful for the system and the workload where frequency boost is found to be useful than packing tasks into cores. IBM POWER 9 system shows the benefit for a workload can be up to 13%. Performance benefit of TurboSched w.r.t. CFS +--+--+--+--+--+--+-+--+--+--+--+--+--+--+--+--+--+--+-+--+--+--+--+--+ | + + + + + + + + + + + + + + + + + + + + + + + | 15 +-+ Performance benefit in
[RFCv3 1/8] sched/core: Add manual jitter classification using sched_setattr syscall
Jitter tasks are short/bursty tasks,typically performing some housekeeping
and are less important in the overall scheme of things. In this patch we
provide a mechanism based on Patrick Bellasi's UCLAMP framework to classify
jitter tasks"
We define jitter tasks as those whose util.max in the UCLAMP framework is
the least (=0). This also provides benefit of giving the least frequency to
those jitter tasks, which is useful if all jitters are packed onto a
separate core."
UCLAMP already provides a way to set util.max for a task by using a syscall
interface. This patch uses the `sched_setattr` syscall to set
sched_util_max attribute of the task which is used to classify the task as
jitter.
Use Case with turbo_bench.c
===
```
i=8;
./turbo_bench -t 30 -h $i -n $((2*i)) -j
```
This spawns 2*i total threads: of which i-CPU bound and i-jitter threads.
Signed-off-by: Parth Shah
---
include/linux/sched.h | 6 ++
kernel/sched/core.c | 9 +
2 files changed, 15 insertions(+)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e2d80e6a187d..2bd9f75a3abb 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -696,6 +696,12 @@ struct task_struct {
struct uclamp_seuclamp_req[UCLAMP_CNT];
/* Effective clamp values used for a scheduling entity */
struct uclamp_seuclamp[UCLAMP_CNT];
+ /*
+* Tag the task as jitter.
+* 0 = regular. Follows regular CFS policy for task placement.
+* 1 = Jitter tasks. Should be packed to reduce active core count.
+*/
+ unsigned intis_jitter;
#endif
#ifdef CONFIG_PREEMPT_NOTIFIERS
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ab0aa319fe60..19c7204d6351 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1189,6 +1189,15 @@ static void __setscheduler_uclamp(struct task_struct *p,
if (attr->sched_flags & SCHED_FLAG_UTIL_CLAMP_MAX) {
uclamp_se_set(>uclamp_req[UCLAMP_MAX],
attr->sched_util_max, true);
+
+ /*
+* Set task to jitter class if Max util is clamped to the least
+* possible value
+*/
+ if (p->uclamp_req[UCLAMP_MAX].bucket_id == 0 && !p->is_jitter)
+ p->is_jitter = 1;
+ else if (p->is_jitter)
+ p->is_jitter = 0;
}
}
--
2.17.1
Re: [selftests/bpf] 69d96519db: kernel_selftests.bpf.test_socket_cookie.fail
On Mon, Jun 24, 2019 at 2:24 PM Stanislav Fomichev wrote:
>
> On 06/24, Andrii Nakryiko wrote:
> > On Sun, Jun 23, 2019 at 5:59 PM Rong Chen wrote:
> > >
> > > On 6/22/19 6:27 AM, Stanislav Fomichev wrote:
> > > > On 06/21, Andrii Nakryiko wrote:
> > > >> )
> > > >>
> > > >> On Fri, Jun 21, 2019 at 9:11 AM Stanislav Fomichev
> > > >> wrote:
> > > >>> On 06/21, kernel test robot wrote:
> > > FYI, we noticed the following commit (built with gcc-7):
> > >
> > > commit: 69d96519dbf0bfa1868dc8597d4b9b2cdeb009d7 ("selftests/bpf:
> > > convert socket_cookie test to sk storage")
> > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
> > > master
> > >
> > > in testcase: kernel_selftests
> > > with following parameters:
> > >
> > > group: kselftests-00
> > >
> > > test-description: The kernel contains a set of "self tests" under
> > > the tools/testing/selftests/ directory. These are intended to be
> > > small unit tests to exercise individual code paths in the kernel.
> > > test-url: https://www.kernel.org/doc/Documentation/kselftest.txt
> > >
> > >
> > > on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge
> > > -smp 2 -m 4G
> > >
> > > caused below changes (please refer to attached dmesg/kmsg for entire
> > > log/backtrace):
> > >
> > >
> > > If you fix the issue, kindly add following tag
> > > Reported-by: kernel test robot
> > >
> > > # selftests: bpf: test_socket_cookie
> > > # libbpf: failed to create map (name: 'socket_cookies'): Invalid
> > > # argument
> > > >>> Another case of old clang trying to create a map that depends on BTF?
> > > >>> Should we maybe switch those BTF checks in the kernel to return
> > > >>> EOPNOTSUPP to make it easy to diagnose?
> > > >> For older compilers that don't generate DATASEC/VAR, you'll see a
> > > >> clear message:
> > > >>
> > > >> libbpf: DATASEC '.maps' not found.
> > > >>
> > > >> So this must be something else. I just confirmed with clang version
> > > >> 7.0.20180201 that for ./test_socket_cookie that's the first line
> > > >> that's emitted on failure.
> > > > Thanks for checking, I also took a look at the attached
> > > > kernel_selftests.xz,
> > > > here is what it has:
> > > > 2019-06-21 11:58:35 ln -sf /usr/bin/clang-6.0 /usr/bin/clang
> > > > 2019-06-21 11:58:35 ln -sf /usr/bin/llc-6.0 /usr/bin/llc
> > > > ...
> > > > # BTF libbpf test[1] (test_btf_haskv.o): SKIP. No ELF .BTF found
> > > > # BTF libbpf test[2] (test_btf_nokv.o): SKIP. No ELF .BTF found
> > > > ...
> > > > # Test case #0 (btf_dump_test_case_syntax): test_btf_dump_case:71:FAIL
> > > > # failed to load test BTF: -2
> > > > # Test case #1 (btf_dump_test_case_ordering): test_btf_dump_case:71:FAIL
> > > > # failed to load test BTF: -2
> > > > ...
> > > >
> > > > And so on. So there is clearly an old clang that doesn't emit any
> > > > BTF. And I also don't see your recent abd29c931459 before 69d96519dbf0
> > > > in
> > > > linux-next, that's why it doesn't complain about missing/corrupt BTF.
> >
> > Ah, ok, that would explain it. But in any case, clang 6&7 is too old.
> > Clang 8 or better yet clang 9 (for global data, datasec/var-dependent
> > stuff) would be great.
> While we are it: I think I have resolved the BTF story internally,
> so if you want to go ahead and convert the rest of the tests to
> BTF format, I would not object anymore ;-)
Glad Clang update went so smooth for you :) I'm going to post an
update to BTF-defined maps (see my updated proposal for updated
approach), so might do the rest of conversion at that time.
>
> (I didn't expect it to be that easy initially, so sorry if I wasted
> everyones time arguing about it).
no worries :)
>
> > > >
> > > > We need to convince lkp people to upgrade clang, otherwise, I suppose,
> > > > we'll get more of these reportings after your recent df0b77925982 :-(
> > >
> > > Thanks for the clarification, we'll upgrade clang asap.
> >
> > Thanks Rong!
> >
> > >
> > > Best Regards,
> > > Rong Chen
> > >
> > >
> > > >
> > > # libbpf: failed to load object './socket_cookie_prog.o'
> > > # (test_socket_cookie.c:149: errno: Invalid argument) Failed to load
> > > # ./socket_cookie_prog.o
> > > # FAILED
> > > not ok 15 selftests: bpf: test_socket_cookie
> > >
> > >
> > >
> > >
> > > To reproduce:
> > >
> > > # build kernel
> > > cd linux
> > > cp config-5.2.0-rc2-00598-g69d9651 .config
> > > make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig
> > > make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 prepare
> > > make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 modules_prepare
> > > make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 SHELL=/bin/bash
> > > make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 bzImage
> > >
> > >
> > >
Re: [PATCH] fsi: sbefifo: Don't fail operations when in SBE IPL state
Hi Greg,
On Mon, 17 Jun 2019 at 05:41, Joel Stanley wrote:
>
> On Mon, 17 Jun 2019 at 02:09, Alistair Popple wrote:
> >
> > On Monday, 21 January 2019 11:15:58 AM AEST Eddie James wrote:
> > > SBE fifo operations should be allowed while the SBE is in any of the
> > > "IPL" states. Operations should succeed in this state.
> > >
> > > Signed-off-by: Eddie James
> >
> > This fixed the problem I was having trying to issue istep operations to the
> > SBE.
> >
> > Tested-by: Alistair Popple
>
> This one slipped through the cracks.
>
> Fixes: 9f4a8a2d7f9d fsi/sbefifo: Add driver for the SBE FIFO
> Reviewed-by: Joel Stanley
>
> Greg, can you please queue this one up for 5.3?
Ping?
>
> Cheers,
>
> Joel
>
> > > ---
> > > drivers/fsi/fsi-sbefifo.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/fsi/fsi-sbefifo.c b/drivers/fsi/fsi-sbefifo.c
> > > index c7d13ac..f7665b3 100644
> > > --- a/drivers/fsi/fsi-sbefifo.c
> > > +++ b/drivers/fsi/fsi-sbefifo.c
> > > @@ -290,11 +290,11 @@ static int sbefifo_check_sbe_state(struct sbefifo
> > > *sbefifo) switch ((sbm & CFAM_SBM_SBE_STATE_MASK) >>
> > > CFAM_SBM_SBE_STATE_SHIFT) { case SBE_STATE_UNKNOWN:
> > > return -ESHUTDOWN;
> > > + case SBE_STATE_DMT:
> > > + return -EBUSY;
> > > case SBE_STATE_IPLING:
> > > case SBE_STATE_ISTEP:
> > > case SBE_STATE_MPIPL:
> > > - case SBE_STATE_DMT:
> > > - return -EBUSY;
> > > case SBE_STATE_RUNTIME:
> > > case SBE_STATE_DUMP: /* Not sure about that one */
> > > break;
> >
> >
Re: [PATCH] dmaengine: fix semicolon.cocci warnings
On 16-06-19, 00:05, kbuild test robot wrote: > From: kbuild test robot > > drivers/dma/dw-edma/dw-edma-core.c:617:2-3: Unneeded semicolon > > > Remove unneeded semicolon. > > Generated by: scripts/coccinelle/misc/semicolon.cocci Applied, thanks -- ~Vinod
linux-next: build failure after merge of the modules tree
Hi Jessica,
After merging the modules tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
kernel/module.c: In function 'module_enable_x':
kernel/module.c:2030:2: error: implicit declaration of function 'frob_text';
did you mean 'rb_next'? [-Werror=implicit-function-declaration]
frob_text(>core_layout, set_memory_x);
^
rb_next
Caused by commit
2eef1399a866 ("modules: fix BUG when load module with rodata=n")
frob_text() only exists when CONFIG_STRICT_MODULE_RWX is defined.
I have used the modules tree from next-20190624 for today.
--
Cheers,
Stephen Rothwell
pgpLqIRUqExAF.pgp
Description: OpenPGP digital signature
Re: [PATCH v2] dmaengine: dmatest: timeout value of -1 should specify infinite wait
On 18-06-19, 22:03, Hook, Gary wrote: > The dmatest module parameter 'timeout' is documented as accepting a > -1 to mean "infinite timeout". Howver, an infinite timeout is not typo Howver > advised, nor possible since the module parameter is an unsigned int, > which won't accept a negative value. Change the parameter > comment to reflect current behavior, which allows values from 0 up to > 4294967295 (0x). Applied after fixing typo, thanks -- ~Vinod
Re: [PATCH v4 1/6] dmaengine: fsl-edma: add drvdata for fsl-edma
On 14-06-19, 16:17, yibin.g...@nxp.com wrote: > From: Robin Gong > > There are some differences between vf610 and next i.mx7ulp. Put such > differences into static driver data for distiguish easily at driver Typo distiguish Though I tried to apply 1-5 it doesnt apply for me, can you rebase and resend Thanks -- ~Vinod
Re: [PATCH v1 0/3] Add required-opps support to devfreq passive gov
On 24-06-19, 15:17, Saravana Kannan wrote:
> Here's an example. This can't be done today, but can be done with this change.
>
> In arch/arm64/boot/dts/exynos/exynos5433-bus.dtsi you have something
> like this with the following changes:
>
> bus_g2d_400: bus0 {
> compatible = "samsung,exynos-bus";
> clocks = <_top CLK_ACLK_G2D_400>;
> clock-names = "bus";
> operating-points-v2 = <_g2d_400_opp_table>;
> status = "disabled";
> };
>
> bus_noc2: bus9 {
> compatible = "samsung,exynos-bus";
> clocks = <_mif CLK_ACLK_BUS2_400>;
> clock-names = "bus";
> operating-points-v2 = <_noc2_opp_table>;
> status = "disabled";
> };
And what is the relation between these two busses ?
> bus_g2d_400_opp_table: opp_table2 {
> compatible = "operating-points-v2";
> opp-shared;
>
> opp-4 {
> opp-hz = /bits/ 64 <4>;
> opp-microvolt = <1075000>;
> + required-opps = <_400>;
> };
> opp-26700 {
> opp-hz = /bits/ 64 <26700>;
> opp-microvolt = <100>;
> + required-opps = <_200>;
> };
> opp-2 {
> opp-hz = /bits/ 64 <2>;
> opp-microvolt = <975000>;
> + required-opps = <_200>;
> };
> opp-16000 {
> opp-hz = /bits/ 64 <16000>;
> opp-microvolt = <962500>;
> + required-opps = <_134>;
> };
> opp-13400 {
> opp-hz = /bits/ 64 <13400>;
> opp-microvolt = <95>;
> + required-opps = <_134>;
> };
> opp-1 {
> opp-hz = /bits/ 64 <1>;
> opp-microvolt = <937500>;
> + required-opps = <_100>;
> };
> };
>
> bus_noc2_opp_table: opp_table6 {
> compatible = "operating-points-v2";
>
> - opp-4 {
> + noc2_400: opp-4 {
> opp-hz = /bits/ 64 <4>;
> };
> - opp-2 {
> + noc2_200: opp-2 {
> opp-hz = /bits/ 64 <2>;
> };
> - opp-13400 {
> + noc2_134: opp-13400 {
> opp-hz = /bits/ 64 <13400>;
> };
> - opp-1 {
> + noc2_100: opp-1 {
> opp-hz = /bits/ 64 <1>;
> };
> };
>
> Thanks,
> Saravana
--
viresh
Re: [PATCH v2] lib/mpi: fix build with clang
On Fri, 21 Jun 2019 at 19:56, Mathieu Malaterre wrote: > > Remove superfluous casts on output operands to avoid warnings on the > following macros: > > * add_ss(sh, sl, ah, al, bh, bl) > * sub_ddmmss(sh, sl, ah, al, bh, bl) > * umul_ppmm(ph, pl, m0, m1) > > Special care has been taken to keep the diff as minimal as possible from > the original header file `longlong.h` from gcc, only importing the > minimal change to make the compilation with clang pass. > Suggested-by: Joel Stanley > Cc: Segher Boessenkool > Signed-off-by: Mathieu Malaterre > --- > v2: Instead of passing compat flag to clang to behave as gcc, remove the > superfluous cast Thanks, I checked your patch against GCC's longlong.h and it looks good. Reviewed-by: Joel Stanley Cheers, Joel
Re: [RESEND PATCH v1 0/5] Solve postboot supplier cleanup and optimize probe ordering
On Mon, Jun 24, 2019 at 03:37:07PM -0700, Sandeep Patil wrote: > We are trying to make sure that all (most) drivers in an Aarch64 system can > be kernel modules for Android, like any other desktop system for > example. There are a number of problems we need to fix before that happens > ofcourse. I will argue that this is NOT an android-specific issue. If the goal of creating an arm64 kernel that will "just work" for a wide range of hardware configurations without rebuilding is going to happen, we need to solve this problem with DT. This goal was one of the original wishes of the arm64 development effort, let's not loose sight of it as obviously, this is not working properly just yet. It just seems that Android is the first one to actually try and implement that goal :) thanks, greg k-h
Re: [PATCH 5.1 000/121] 5.1.15-stable review
On Mon, Jun 24, 2019 at 05:15:41PM -0700, Guenter Roeck wrote: > On 6/24/19 2:55 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.15 release. > > There are 121 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 26 Jun 2019 09:22:03 AM UTC. > > Anything received after that time might be too late. > > > > For v5.1.14-122-g815c105311e8: > > Build results: > total: 159 pass: 159 fail: 0 > Qemu test results: > total: 364 pass: 364 fail: 0 Great! Thanks for testing these and letting me know. greg k-h
Re: [PATCH 5.1 000/121] 5.1.15-stable review
On Tue, Jun 25, 2019 at 06:15:37AM +0530, Naresh Kamboju wrote: > On Mon, 24 Jun 2019 at 15:38, Greg Kroah-Hartman > wrote: > > > > This is the start of the stable review cycle for the 5.1.15 release. > > There are 121 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 26 Jun 2019 09:22:03 AM UTC. > > 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/v5.x/stable-review/patch-5.1.15-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-5.1.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. thanks for testing and letting me know. greg k-h
Re: [PATCH 1/2] tty: ldisc: Fix misuse of proc_dointvec "ldisc_autoload"
On Tue, Jun 25, 2019 at 12:08:00PM +0900, Eiichi Tsukata wrote:
> /proc/sys/dev/tty/ldisc_autoload assumes given value to be 0 or 1. Use
> proc_dointvec_minmax instead of proc_dointvec.
>
> Fixes: 7c0cca7c847e "(tty: ldisc: add sysctl to prevent autoloading of
> ldiscs)"
> Signed-off-by: Eiichi Tsukata
> ---
> drivers/tty/tty_ldisc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
> index e38f104db174..a8ea7a35c94e 100644
> --- a/drivers/tty/tty_ldisc.c
> +++ b/drivers/tty/tty_ldisc.c
> @@ -863,7 +863,7 @@ static struct ctl_table tty_table[] = {
> .data = _ldisc_autoload,
> .maxlen = sizeof(tty_ldisc_autoload),
> .mode = 0644,
> - .proc_handler = proc_dointvec,
> + .proc_handler = proc_dointvec_minmax,
> .extra1 = ,
> .extra2 = ,
Ah, nice catch. But this really isn't an issue as if you use a bigger
value, things will not "break", right?
thanks,
greg k-h
Re: [RESEND PATCH v2] mtd: spinand: read return badly if the last page has bitflips
On Tue, Jun 25, 2019 at 09:02:29AM +0800, liaoweixiong wrote:
> In case of the last page containing bitflips (ret > 0),
> spinand_mtd_read() will return that number of bitflips for the last
> page. But to me it looks like it should instead return max_bitflips like
> it does when the last page read returns with 0.
>
> Signed-off-by: liaoweixiong
> Reviewed-by: Boris Brezillon
> Reviewed-by: Frieder Schrempf
> Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI
> NANDs")
> ---
> drivers/mtd/nand/spi/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [PATCH 5.1 000/121] 5.1.15-stable review
On Mon, Jun 24, 2019 at 12:52:16PM -0500, Jiunn Chang wrote: > On Mon, Jun 24, 2019 at 05:55:32PM +0800, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.15 release. > > There are 121 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 26 Jun 2019 09:22:03 AM UTC. > > 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/v5.x/stable-review/patch-5.1.15-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-5.1.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > - > > Hello, > > Compiled and booted fine. No regressions on x86_64. Great, thanks for letting me know! greg k-h
Re: [PATCH v2 2/5] nvme: rename "pci" operations to "mmio"
On Mon, Jun 24, 2019 at 2:16 PM Christoph Hellwig wrote: > IFF we want to support it it has to be done at the PCIe layer. But > even that will require actual documentation and support from Intel. > > If Intel still believes this scheme is their magic secret to control > the NVMe market and give themselves and unfair advantage over their > competitors there is not much we can do. Since the 2016 discussion, more documentation has been published: https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/300-series-chipset-pch-datasheet-vol-2.pdf Chapter 15 is entirely new, and section 15.2 provides a nice clarity improvement of the magic regs in the AHCI BAR, which I have used in these patches to clean up the code and add documentation in the header (see patch 1 in this series, ahci-remap.h). I believe there's room for further improvement in the docs here, but it would be nice to know what you see as the blocking questions or documentation gaps that would prevent us from continuing to develop the fake PCI bridge approach (https://marc.info/?l=linux-pci=156015271021614=2). We are going to try and push Intel on this via other channels to see if we can get a contact to help us, so it would be useful if I can include a concrete list of what we need. Bearing in mind that we've already been told that the NVMe device config space is inaccessible, and the new docs show exactly how the BIOS enforces such inaccessibility during early boot, the remaining points you mentioned recently were: b) reset handling, including the PCI device removal as the last escalation step c) SR-IOV VFs and their management d) power management Are there other blocking questions you would require answers to? Thanks, Daniel
[PATCH -next] x86/jump_label: Make tp_vec_nr static
Fix sparse warning: arch/x86/kernel/jump_label.c:106:5: warning: symbol 'tp_vec_nr' was not declared. Should it be static? It's only used in jump_label.c, so make it static. Reported-by: Hulk Robot Signed-off-by: YueHaibing --- arch/x86/kernel/jump_label.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c index ea13808..0440532 100644 --- a/arch/x86/kernel/jump_label.c +++ b/arch/x86/kernel/jump_label.c @@ -103,7 +103,7 @@ void arch_jump_label_transform(struct jump_entry *entry, #define TP_VEC_MAX (PAGE_SIZE / sizeof(struct text_poke_loc)) static struct text_poke_loc tp_vec[TP_VEC_MAX]; -int tp_vec_nr = 0; +static int tp_vec_nr; bool arch_jump_label_transform_queue(struct jump_entry *entry, enum jump_label_type type) -- 2.7.4
Reminder: 42 open syzbot bugs in usb subsystem
[This email was generated by a script. Let me know if you have any suggestions to make it better.] Of the currently open syzbot reports against the upstream kernel, I've manually marked 42 of them as possibly being bugs in the usb subsystem. This category mostly includes USB driver bugs, but it might include some core USB bugs too. I've listed these reports below, sorted by an algorithm that tries to list first the reports most likely to be still valid, important, and actionable. Of these 42 bugs, 24 were seen in mainline in the last week. If you believe a bug is no longer valid, please close the syzbot report by sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the original thread, as explained at https://goo.gl/tpsmEJ#status If you believe I misattributed a bug to the usb subsystem, please let me know, and if possible forward the report to the correct people or mailing list. Here are the bugs: Title: possible deadlock in mon_bin_vma_fault Last occurred: 0 days ago Reported: 294 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=2b061d1fabd9760e98f92163543189b637c4af36 Original thread: https://lkml.kernel.org/lkml/6ad6030574fea...@google.com/T/#u This bug has a C reproducer. No one replied to the original thread for this bug. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+56f9673bb4cdcbeb0...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/6ad6030574fea...@google.com Title: WARNING in rollback_registered_many (2) Last occurred: 0 days ago Reported: 229 days ago Branches: Mainline and others Dashboard link: https://syzkaller.appspot.com/bug?id=d39aca7a05a76d146ba96cddbb3242075d9171a7 Original thread: https://lkml.kernel.org/lkml/d9f094057a17b...@google.com/T/#u This bug has a C reproducer. The original thread for this bug received 1 reply, 73 days ago. This looks like a bug in a net USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+40918e4d826fb2ff9...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/d9f094057a17b...@google.com Title: general protection fault in ath6kl_usb_alloc_urb_from_pipe Last occurred: 0 days ago Reported: 73 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=cd8b9cfe50a0bf36ee19eda2d7e2e06843dfbeaf Original thread: https://lkml.kernel.org/lkml/8e82510586561...@google.com/T/#u This bug has a C reproducer. No one has replied to the original thread for this bug yet. This looks like a bug in a net/wireless USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+ead4037ec793e025e...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at https://lkml.kernel.org/r/8e82510586561...@google.com Title: INFO: trying to register non-static key in rtl_c2hcmd_launcher Last occurred: 0 days ago Reported: 73 days ago Branches: Mainline (with usb-fuzzer patches) Dashboard link: https://syzkaller.appspot.com/bug?id=9c910719e185e47dad63741d473518b365286eb7 Original thread: https://lkml.kernel.org/lkml/727264058653d...@google.com/T/#u This bug has a C reproducer. The original thread for this bug has received 1 reply, 27 days ago. This looks like a bug in a net/wireless USB driver. If you fix this bug, please add the following tag to the commit: Reported-by: syzbot+1fcc5ef45175fc774...@syzkaller.appspotmail.com If you send any email or patch for this bug, please consider replying to the original thread. For the git send-email command to use, or tips on how to reply if the thread isn't in your mailbox, see the "Reply instructions" at
Re: [PATCH] clk: imx8mm: Switch to platform driver
Hi Abel, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on shawnguo/for-next] [also build test WARNING on v5.2-rc6 next-20190621] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Abel-Vesa/clk-imx8mm-Switch-to-platform-driver/20190625-095013 base: https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git for-next config: arm64-defconfig (attached as .config) compiler: clang version 9.0.0 (git://gitmirror/llvm_project 868a394bb60dbeb1dc92578c34207265a7b528f6) reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): >> WARNING: vmlinux.o(.text+0x515c60): Section mismatch in reference from the >> function imx8mm_clocks_probe() to the function >> .init.text:imx_register_uart_clocks() The function imx8mm_clocks_probe() references the function __init imx_register_uart_clocks(). This is often because imx8mm_clocks_probe lacks a __init annotation or the annotation of imx_register_uart_clocks is wrong. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] Revert "x86/module: Detect and skip invalid relocations"
On Mon, Jun 24, 2019 at 12:00:33PM +0200, Miroslav Benes wrote: > On Sat, 22 Jun 2019, Thomas Gleixner wrote: > > > Miroslav, > > > > On Thu, 20 Jun 2019, Miroslav Benes wrote: > > > On Thu, 20 Jun 2019, Cheng Jian wrote: > > > > > > > This reverts commit eda9cec4c9a12208a6f69fbe68f72a6311d50032. > > > > > > > > Since commit (eda9cec4c9a1 'x86/module: Detect and skip invalid > > > > relocations') add some sanity check in apply_relocate_add, borke > > > > re-insmod a kernel module which has been patched before, > > > > > > > > The relocation informations of the livepatch module have been > > > > overwritten since first patched, so if we rmmod and insmod the > > > > kernel module, these values are not zero anymore, when > > > > klp_module_coming doing, and that commit marks them as invalid > > > > invalid_relocation. > > > > > > > > Then the following error occurs: > > > > > > > > module: x86/modules: Skipping invalid relocation target, > > > > existing value is nonzero for type 2, loc (ptrval), val > > > > c000236c > > > > livepatch: failed to initialize patch 'livepatch_0001_test' for > > > > module 'test' (-8) > > > > livepatch: patch 'livepatch_0001_test' failed for module > > > > 'test', refusing to load module 'test' > > > > > > Oh yeah. First reported here 20180602161151.apuhs2dygsexmcg2@treble (LP > > > ML > > > only and there is no archive on lore.kernel.org yet. Sorry about that.). > > > I > > > posted v1 here > > > https://lore.kernel.org/lkml/20180607092949.1706-1-mbe...@suse.cz/ and > > > even started to work on v2 in March with arch-specific nullifying, but > > > then I got sidetracked again. I'll move it up my todo list a bit. > > > > so we need to revert it for now, right? > > Not necessarily. > > Quoting Josh from the original bug report: > "Possible ways to fix it: > > 1) Remove the error check in apply_relocate_add(). I don't think we >should do this, because the error is actually useful for detecting >corrupt modules. And also, powerpc has the similar error so this >wouldn't be a universal solution. > > 2) In klp_unpatch_object(), call an arch-specific arch_unpatch_object() >which reverses any arch-specific patching: on x86, clearing all >relocation targets to zero; on powerpc, converting the instructions >after relative link branches to nops. I don't think we should do >this because it's not a global solution and requires fidgety >arch-specific patching code. > > 3) Don't allow patched modules to be removed. I think this makes the >most sense. Nobody needs this functionality anyway (right?). > " > > 1 would be the revert. We decided against it. The scenario (rmmod a > module) is (supposedly) not that common in practice. Even the current bug > report was triggered just in testing if I am not mistaken. Moreover, you > need kpatch-build to properly set up relocation records. Upstream > livepatch does not offer it as of now. That's why (I think) Josh thought > the benefits of the check outweighed the disadvantage. > > Then I tried to implement 3, but there were problems with it too. 2 > remains to be finished and then we can decide what the best approach is. > > That being said... I am not against the reverting the commit per se, but > we lived with it or quite a long time and no one has met it so far in > "real life". I don't think it is the classic "we broke something, we have > to revert" scenario. > > Josh, any comment? I think your opinion matters here much more than mine. Agreed, as far as I know the problem is purely theoretical and we haven't seen any real-world bug reports, because people aren't reloading patched modules in the real world. If we were to revert the error checks in apply_relocate_add() then it could expose us to real-world regressions (which we have actually seen in the past). So I would vote to leave the error checks in place, at least until it becomes a real-world issue. And in the meantime hopefully you can finish implementing #2 or #3 soon :-) -- Josh
Re: [PATCH] riscv: dts: Re-organize SPI DT nodes
On Tue, Jun 25, 2019 at 2:53 AM Paul Walmsley wrote: > > On Mon, 24 Jun 2019, Yash Shah wrote: > > > As per the General convention, define only device DT node in SOC DTSi > > file with status = "disabled" and enable device in Board DTS file with > > status = "okay" > > > > Reported-by: Anup Patel > > Signed-off-by: Yash Shah > > This is a good start, but should also cover the other I/O devices in the > chip DT file. The mandatory internal devices, like the PRCI and PLIC, can > stay the way they are. Yes, this convention only applies to SoC devices with external connections so PRCI, PLIC, and CLINT DT nodes are not required to follow this. Eventually, this convention helps when we have multiple boards of same SOC and each board having different set of peripherals connections. Regards, Anup
[PATCH 2/2] net/ipv6: Fix misuse of proc_dointvec "skip_notify_on_dev_down"
/proc/sys/net/ipv6/route/skip_notify_on_dev_down assumes given value to be
0 or 1. Use proc_dointvec_minmax instead of proc_dointvec.
Fixes: 7c6bb7d2faaf ("net/ipv6: Add knob to skip DELROUTE message ondevice
down")
Signed-off-by: Eiichi Tsukata
---
net/ipv6/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 11ad62effd56..aade636c6be6 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -5281,7 +5281,7 @@ static struct ctl_table ipv6_route_table_template[] = {
.data =
_net.ipv6.sysctl.skip_notify_on_dev_down,
.maxlen = sizeof(int),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_dointvec_minmax,
.extra1 = ,
.extra2 = ,
},
--
2.21.0
[PATCH 1/2] tty: ldisc: Fix misuse of proc_dointvec "ldisc_autoload"
/proc/sys/dev/tty/ldisc_autoload assumes given value to be 0 or 1. Use
proc_dointvec_minmax instead of proc_dointvec.
Fixes: 7c0cca7c847e "(tty: ldisc: add sysctl to prevent autoloading of ldiscs)"
Signed-off-by: Eiichi Tsukata
---
drivers/tty/tty_ldisc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/tty_ldisc.c b/drivers/tty/tty_ldisc.c
index e38f104db174..a8ea7a35c94e 100644
--- a/drivers/tty/tty_ldisc.c
+++ b/drivers/tty/tty_ldisc.c
@@ -863,7 +863,7 @@ static struct ctl_table tty_table[] = {
.data = _ldisc_autoload,
.maxlen = sizeof(tty_ldisc_autoload),
.mode = 0644,
- .proc_handler = proc_dointvec,
+ .proc_handler = proc_dointvec_minmax,
.extra1 = ,
.extra2 = ,
},
--
2.21.0
Re: NMI hardlock stacktrace deadlock [was Re: Linux 5.2-rc5]
On Wed, Jun 19, 2019 at 01:42:53PM -0700, Linus Torvalds wrote: > On Wed, Jun 19, 2019 at 12:19 PM Chris Wilson > wrote: > > > > > Do you have the oops itself at all? > > > > An example at > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/fi-kbl-x1275/dmesg0.log > > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6310/fi-kbl-x1275/boot0.log > > > > The bug causing the oops is clearly a driver problem. The rc5 fallout > > just seems to be because of some shrinker changes affecting some object > > reaping that were unfortunately still active. What perturbed the CI > > team was the machine failed to panic & reboot. > > Hmm. It's hard to guess at the cause of that. The oopses themselves > don't look like they are happening in any particularly bad context, so > all the normal reboot-on-oops etc stuff _should_ work. Looking at the dmesg, panic_on_oops doesn't seem to be enabled: it went through the rewind_stack_do_exit() path instead of the panic() path. So the system is apparently not configured to reboot on oops. So I'd say the hang was presumably caused by a lock held by the oopsing code. So it looks normal to me, other than the original oops. -- Josh
Re: [PATCH] [RFC] dmaengine: add fifo_size member
On 6/24/2019 11:56 AM, Vinod Koul wrote: On 20-06-19, 15:59, Sameer Pujar wrote: So can you explain me what is the difference here that the peripheral cannot configure and use burst size with passing fifo depth? Say for example FIFO_THRESHOLD is programmed as 16 WORDS, BURST_SIZE as 8 WORDS. ADMAIF does not push data to AHUB(operation [2]) till threshold of 16 WORDS is reached in ADMAIF FIFO. Hence 2 burst transfers are needed to reach the threshold. As mentioned earlier, threshold here is to just indicate when data transfer can happen to AHUB modules. So we have ADMA and AHUB and peripheral. You are talking to AHUB and that is _not_ peripheral and if I have guess right the fifo depth is for AHUB right? Yes the communication is between ADMA and AHUB. ADMAIF is the interface between ADMA and AHUB. ADMA channel sending data to AHUB pairs with ADMAIF TX channel. Similary ADMA channel receiving data from AHUB pairs with ADMAIF RX channel. FIFO DEPTH we are talking is about each ADMAIF TX/RX channel and it is configurable. DMA transfers happen to/from ADMAIF FIFOs and whenever data(per WORD) is popped/pushed out of ADMAIF to/from AHUB, asseration is made to ADMA. ADMA keeps counters based on these assertions. By knowing FIFO DEPTH and these counters, ADMA knows when to wait or when to transfer data. Where does ADMAIF driver reside in kernel, who configures it for normal dma txns..? Not yet, we are in the process of upstreaming ADMAIF driver. To describe briefly, audio subsystem is using ALSA SoC(ASoC) layer. ADMAIF is registered as platform driver and exports DMA functionality. It registers PCM devices for each Rx/Tx ADMAIF channel. During PCM playback/capture operations, ALSA callbacks configure DMA channel using API dmaengine_slave_config(). RFC patch proposed, is to help populate FIFO_SIZE value as well during above call, since ADMA requires it. Also it wold have helped the long discussion if that part was made clear rather than talking about peripheral all this time :( Thought it was clear, though should have avoided using 'peripheral' in the discussions. Sorry for the confusion.
Re: [RFC] rcu: Warn that rcu ktheads cannot be spawned
On Mon, Jun 24, 2019 at 12:46:24PM -0400, Joel Fernandes wrote:
> On Mon, Jun 24, 2019 at 05:27:32PM +0900, Byungchul Park wrote:
> > Hello rcu folks,
> >
> > I thought it'd better to announce it if those spawnings fail because of
> > !rcu_scheduler_fully_active.
> >
> > Of course, with the current code, it never happens though.
> >
> > Thoughts?
>
> It seems in the right spirit, but with your patch a warning always fires.
> rcu_prepare_cpu() is called multiple times, once from rcu_init() and then
> from hotplug paths.
I'm sorry bothering you.
I sent the patch to ask how you guys think about the direction coz I'm
not sure if the current code w/o warning on it is intended or not.
However from now on, I think I need to test it first even if it's RFC :)
Thank you very much for the information.
Thanks,
Byungchul
> Warning splat stack looks like:
>
> [0.398767] Call Trace:
>
> [0.398775] rcu_init+0x6aa/0x724
>
> [0.398779] start_kernel+0x220/0x4a2
> [0.398780] ? copy_bootdata+0x12/0xac
>
>
> [0.398782] secondary_startup_64+0xa4/0xb0
>
>
> >
> > Thanks,
> > Byungchul
> >
> > ---8<---
> > From 58a33a85c70f82c406319b4752af95cf6ceb73a3 Mon Sep 17 00:00:00 2001
> > From: Byungchul Park
> > Date: Mon, 24 Jun 2019 17:08:26 +0900
> > Subject: [RFC] rcu: Warn that rcu ktheads cannot be spawned
> >
> > In case that rcu ktheads cannot be spawned due to
> > !rcu_scheduler_fully_active, it'd be better to anounce it.
> >
> > While at it, because the return value of rcu_spawn_one_boost_kthread()
> > is not used any longer, changed the return type from int to void.
> >
> > Signed-off-by: Byungchul Park
> > ---
> > kernel/rcu/tree_plugin.h | 31 +++
> > 1 file changed, 19 insertions(+), 12 deletions(-)
> >
> > diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
> > index 1102765..7d74193 100644
> > --- a/kernel/rcu/tree_plugin.h
> > +++ b/kernel/rcu/tree_plugin.h
> > @@ -1131,7 +1131,7 @@ static void rcu_preempt_boost_start_gp(struct
> > rcu_node *rnp)
> > * already exist. We only create this kthread for preemptible RCU.
> > * Returns zero if all is well, a negated errno otherwise.
> > */
> > -static int rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
> > +static void rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
> > {
> > int rnp_index = rnp - rcu_get_root();
> > unsigned long flags;
> > @@ -1139,25 +1139,24 @@ static int rcu_spawn_one_boost_kthread(struct
> > rcu_node *rnp)
> > struct task_struct *t;
> >
> > if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
> > - return 0;
> > + return;
> >
> > - if (!rcu_scheduler_fully_active || rcu_rnp_online_cpus(rnp) == 0)
> > - return 0;
> > + if (rcu_rnp_online_cpus(rnp) == 0)
> > + return;
> >
> > rcu_state.boost = 1;
> > if (rnp->boost_kthread_task != NULL)
> > - return 0;
> > + return;
> > t = kthread_create(rcu_boost_kthread, (void *)rnp,
> >"rcub/%d", rnp_index);
> > if (IS_ERR(t))
> > - return PTR_ERR(t);
> > + return;
> > raw_spin_lock_irqsave_rcu_node(rnp, flags);
> > rnp->boost_kthread_task = t;
> > raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
> > sp.sched_priority = kthread_prio;
> > sched_setscheduler_nocheck(t, SCHED_FIFO, );
> > wake_up_process(t); /* get to TASK_INTERRUPTIBLE quickly. */
> > - return 0;
> > }
> >
> > static void rcu_cpu_kthread_setup(unsigned int cpu)
> > @@ -1264,8 +1263,12 @@ static void __init rcu_spawn_boost_kthreads(void)
> > per_cpu(rcu_data.rcu_cpu_has_work, cpu) = 0;
> > if (WARN_ONCE(smpboot_register_percpu_thread(_cpu_thread_spec),
> > "%s: Could not start rcub kthread, OOM is now expected behavior\n",
> > __func__))
> > return;
> > +
> > + if (WARN_ON(!rcu_scheduler_fully_active))
> > + return;
> > +
> > rcu_for_each_leaf_node(rnp)
> > - (void)rcu_spawn_one_boost_kthread(rnp);
> > + rcu_spawn_one_boost_kthread(rnp);
> > }
> >
> > static void rcu_prepare_kthreads(int cpu)
> > @@ -1273,9 +1276,11 @@ static void rcu_prepare_kthreads(int cpu)
> > struct rcu_data *rdp = per_cpu_ptr(_data, cpu);
> > struct rcu_node *rnp = rdp->mynode;
> >
> > + if (WARN_ON(!rcu_scheduler_fully_active))
> > + return;
> > +
> > /* Fire up the incoming CPU's kthread and leaf rcu_node kthread. */
> > - if (rcu_scheduler_fully_active)
> > - (void)rcu_spawn_one_boost_kthread(rnp);
> > + rcu_spawn_one_boost_kthread(rnp);
> > }
> >
> > #else /* #ifdef CONFIG_RCU_BOOST */
> > @@
Re: [RFC] rcu: Warn that rcu ktheads cannot be spawned
On Mon, Jun 24, 2019 at 10:25:51AM -0700, Paul E. McKenney wrote:
> On Mon, Jun 24, 2019 at 12:46:24PM -0400, Joel Fernandes wrote:
> > On Mon, Jun 24, 2019 at 05:27:32PM +0900, Byungchul Park wrote:
> > > Hello rcu folks,
> > >
> > > I thought it'd better to announce it if those spawnings fail because of
> > > !rcu_scheduler_fully_active.
> > >
> > > Of course, with the current code, it never happens though.
> > >
> > > Thoughts?
> >
> > It seems in the right spirit, but with your patch a warning always fires.
> > rcu_prepare_cpu() is called multiple times, once from rcu_init() and then
> > from hotplug paths.
> >
> > Warning splat stack looks like:
> >
> > [0.398767] Call Trace:
> > [0.398775] rcu_init+0x6aa/0x724
> > [0.398779] start_kernel+0x220/0x4a2
> > [0.398780] ? copy_bootdata+0x12/0xac
> > [0.398782] secondary_startup_64+0xa4/0xb0
>
> Thank you both, and I will remove this from my testing queue.
>
> As Joel says, this is called at various points in the boot sequence, not
> all of which are far enough along to support spawning kthreads.
>
> The real question here is "What types of bugs are we trying to defend
> against?" But keeping in mind existing diagnostics. For example, are
> there any kthreads for which a persistent failure to spawn would not
> emit any error message. My belief is that any such persistent failure
> would result in either an in-kernel diagnostic or an rcutorture failure,
> but I might well be missing something.
>
> Thoughts? Or, more to the point, tests demonstrating silence in face
> of such a persistent failure?
You are right. There wouldn't be a persistent failure because the path
turning cpus on always tries to spawn them, *even* in case that the
booting sequence is wrong. The current code anyway goes right though.
I thought a hole can be there if the code changes so that those kthreads
cannot be spawned until the cpu being up, which is the case I was
interested in. Again, it's gonna never happen with the current code
because it spawns them after setting rcu_scheduler_fully_active to 1 in
rcu_spawn_gp_kthead().
And I wrongly thought you placed the rcu_scheduler_fully_active check on
spawning just in case. But it seems to be not the case.
So I'd better stop working on the warning patch. :) Instead, please
check the following trivial fix.
Thanks,
Byungchul
---8<---
>From 1293d19bb7abf7553d656c81182118eff54e7dc9 Mon Sep 17 00:00:00 2001
From: Byungchul Park
Date: Mon, 24 Jun 2019 16:22:11 +0900
Subject: [PATCH] rcu: Make rcu_spawn_one_boost_kthread() return void
The return value of rcu_spawn_one_boost_kthread() is not used any
longer. Change the return type from int to void.
Signed-off-by: Byungchul Park
---
kernel/rcu/tree_plugin.h | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/kernel/rcu/tree_plugin.h b/kernel/rcu/tree_plugin.h
index 1102765..4e11aa4 100644
--- a/kernel/rcu/tree_plugin.h
+++ b/kernel/rcu/tree_plugin.h
@@ -1131,7 +1131,7 @@ static void rcu_preempt_boost_start_gp(struct rcu_node
*rnp)
* already exist. We only create this kthread for preemptible RCU.
* Returns zero if all is well, a negated errno otherwise.
*/
-static int rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
+static void rcu_spawn_one_boost_kthread(struct rcu_node *rnp)
{
int rnp_index = rnp - rcu_get_root();
unsigned long flags;
@@ -1139,25 +1139,24 @@ static int rcu_spawn_one_boost_kthread(struct rcu_node
*rnp)
struct task_struct *t;
if (!IS_ENABLED(CONFIG_PREEMPT_RCU))
- return 0;
+ return;
if (!rcu_scheduler_fully_active || rcu_rnp_online_cpus(rnp) == 0)
- return 0;
+ return;
rcu_state.boost = 1;
if (rnp->boost_kthread_task != NULL)
- return 0;
+ return;
t = kthread_create(rcu_boost_kthread, (void *)rnp,
"rcub/%d", rnp_index);
if (IS_ERR(t))
- return PTR_ERR(t);
+ return;
raw_spin_lock_irqsave_rcu_node(rnp, flags);
rnp->boost_kthread_task = t;
raw_spin_unlock_irqrestore_rcu_node(rnp, flags);
sp.sched_priority = kthread_prio;
sched_setscheduler_nocheck(t, SCHED_FIFO, );
wake_up_process(t); /* get to TASK_INTERRUPTIBLE quickly. */
- return 0;
}
static void rcu_cpu_kthread_setup(unsigned int cpu)
@@ -1265,7 +1264,7 @@ static void __init rcu_spawn_boost_kthreads(void)
if (WARN_ONCE(smpboot_register_percpu_thread(_cpu_thread_spec),
"%s: Could not start rcub kthread, OOM is now expected behavior\n", __func__))
return;
rcu_for_each_leaf_node(rnp)
- (void)rcu_spawn_one_boost_kthread(rnp);
+ rcu_spawn_one_boost_kthread(rnp);
}
static void rcu_prepare_kthreads(int cpu)
@@ -1275,7 +1274,7 @@ static void rcu_prepare_kthreads(int cpu)
/* Fire up the incoming CPU's
[PATCH net-next] xdp: Make __mem_id_disconnect static
Fix sparse warning:
net/core/xdp.c:88:6: warning:
symbol '__mem_id_disconnect' was not declared. Should it be static?
Reported-by: Hulk Robot
Signed-off-by: YueHaibing
---
net/core/xdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/xdp.c b/net/core/xdp.c
index b29d7b5..829377c 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -85,7 +85,7 @@ static void __xdp_mem_allocator_rcu_free(struct rcu_head *rcu)
kfree(xa);
}
-bool __mem_id_disconnect(int id, bool force)
+static bool __mem_id_disconnect(int id, bool force)
{
struct xdp_mem_allocator *xa;
bool safe_to_remove = true;
--
2.7.4
Re: [PATCH net-next] net: link_watch: prevent starvation when processing linkwatch wq
On 2019/5/29 16:59, Yunsheng Lin wrote: > On 2019/5/29 14:58, David Miller wrote: >> From: Yunsheng Lin >> Date: Mon, 27 May 2019 09:47:54 +0800 >> >>> When user has configured a large number of virtual netdev, such >>> as 4K vlans, the carrier on/off operation of the real netdev >>> will also cause it's virtual netdev's link state to be processed >>> in linkwatch. Currently, the processing is done in a work queue, >>> which may cause worker starvation problem for other work queue. >>> >>> This patch releases the cpu when link watch worker has processed >>> a fixed number of netdev' link watch event, and schedule the >>> work queue again when there is still link watch event remaining. >>> >>> Signed-off-by: Yunsheng Lin >> >> Why not rtnl_unlock(); yield(); rtnl_lock(); every "100" events >> processed? >> >> That seems better than adding all of this overhead to reschedule the >> workqueue every 100 items. > > One minor concern, the above solution does not seem to solve the cpu > starvation for other normal workqueue which was scheduled on the same > cpu as linkwatch. Maybe I misunderstand the workqueue or there is other > consideration here? :) > > Anyway, I will implemet it as you suggested and test it before posting V2. > Thanks. Hi, David I stress tested the above solution with a lot of vlan dev and qemu-kvm with vf passthrongh mode, the linkwatch wq sometimes block the irqfd_inject wq when they are scheduled on the same cpu, which may cause interrupt delay problem for vm. Rescheduling workqueue every 100 items does give irqfd_inject wq to run sooner, which alleviate the interrupt delay problems for vm. So It is ok for me to fall back to reschedule the link watch wq every 100 items, or is there a better way to fix it properly? > >> >> . >> > > > . >
linux-next: manual merge of the fbdev tree with the v4l-dvb tree
Hi all,
Today's linux-next merge of the fbdev tree got a conflict in:
drivers/media/pci/ivtv/ivtvfb.c
between commit:
2161536516ed ("media: media/pci: set device_caps in struct video_device")
from the v4l-dvb tree and commit:
deb00d2785be ("fbdev: make unregister/unlink functions not fail")
from the fbdev tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/media/pci/ivtv/ivtvfb.c
index 800b3654cac5,299ff032f528..
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@@ -1251,16 -1246,7 +1251,12 @@@ static int ivtvfb_callback_cleanup(stru
struct osd_info *oi = itv->osd_info;
if (itv->v4l2_cap & V4L2_CAP_VIDEO_OUTPUT) {
+ itv->streams[IVTV_DEC_STREAM_TYPE_YUV].vdev.device_caps &=
+ ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
+ itv->streams[IVTV_DEC_STREAM_TYPE_MPG].vdev.device_caps &=
+ ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
+ itv->v4l2_cap &= ~V4L2_CAP_VIDEO_OUTPUT_OVERLAY;
- if (unregister_framebuffer(>osd_info->ivtvfb_info)) {
- IVTVFB_WARN("Framebuffer %d is in use, cannot unload\n",
- itv->instance);
- return 0;
- }
+ unregister_framebuffer(>osd_info->ivtvfb_info);
IVTVFB_INFO("Unregister framebuffer %d\n", itv->instance);
itv->ivtvfb_restore = NULL;
ivtvfb_blank(FB_BLANK_VSYNC_SUSPEND, >ivtvfb_info);
pgpv8PqwfBlXU.pgp
Description: OpenPGP digital signature
Re: [PATCH] time/tick-broadcast: Fix tick_broadcast_offline() lockdep complaint
On Tue, Jun 25, 2019 at 02:43:00AM +0200, Frederic Weisbecker wrote:
> On Mon, Jun 24, 2019 at 04:44:22PM -0700, Paul E. McKenney wrote:
> > On Tue, Jun 25, 2019 at 01:12:23AM +0200, Frederic Weisbecker wrote:
> > > On Fri, Jun 21, 2019 at 04:46:02PM -0700, Paul E. McKenney wrote:
> > > > @@ -3097,13 +3126,21 @@ static void sched_tick_remote(struct
> > > > work_struct *work)
> > > > /*
> > > > * Run the remote tick once per second (1Hz). This arbitrary
> > > > * frequency is large enough to avoid overload but short enough
> > > > -* to keep scheduler internal stats reasonably up to date.
> > > > +* to keep scheduler internal stats reasonably up to date. But
> > > > +* first update state to reflect hotplug activity if required.
> > > > */
> > > > + os = atomic_read(>state);
> > > > + if (os) {
> > > > + WARN_ON_ONCE(os != TICK_SCHED_REMOTE_OFFLINING);
> > > > + if (atomic_inc_not_zero(>state))
> > > > + return;
> > >
> > > Using inc makes me a bit nervous here. If we do so, we should somewhow
> > > make sure that we never exceed a value higher than
> > > TICK_SCHED_REMOTE_OFFLINE
> > > by accident.
> > >
> > > atomic_xchg() is probably a bit costlier but also safer as it allows
> > > us to check both the old and the new value. That path shouldn't be
> > > critically fast
> > > after all.
> >
> > It would need to be cmpxchg() to avoid messing with the state if
> > the state were somehow TICK_SCHED_REMOTE_RUNNING, right?
>
> Ah indeed! Nevermind, let's keep things as they are then.
>
> > > > + }
> > > > queue_delayed_work(system_unbound_wq, dwork, HZ);
> > > > }
> > > >
> > > > static void sched_tick_start(int cpu)
> > > > {
> > > > + int os;
> > > > struct tick_work *twork;
> > > >
> > > > if (housekeeping_cpu(cpu, HK_FLAG_TICK))
> > > > @@ -3112,15 +3149,20 @@ static void sched_tick_start(int cpu)
> > > > WARN_ON_ONCE(!tick_work_cpu);
> > > >
> > > > twork = per_cpu_ptr(tick_work_cpu, cpu);
> > > > - twork->cpu = cpu;
> > > > - INIT_DELAYED_WORK(>work, sched_tick_remote);
> > > > - queue_delayed_work(system_unbound_wq, >work, HZ);
> > > > + os = atomic_xchg(>state, TICK_SCHED_REMOTE_RUNNING);
> > > > + WARN_ON_ONCE(os == TICK_SCHED_REMOTE_RUNNING);
> > >
> > > See if we use atomic_inc(), we would need to also WARN(os >
> > > TICK_SCHED_REMOTE_OFFLINE).
> >
> > How about if I put that WARN() between the atomic_inc_not_zero() and
> > the return, presumably also adding braces?
>
> Yeah, unfortunately there is no atomic_add_not_zero_return().
> I guess we can live with a check using atomic_read(). In the best
> case it returns the fresh increment, otherwise it should be REMOTE_RUNNING.
>
> In any case the (os > TICK_SCHED_REMOTE_OFFLINE) check applies.
True, so with high probability a warning would be emitted. Fair enough?
Thanx, Paul
Re: Kirkwood PCI Express and bridges
On 24/06/19 4:08 PM, Chris Packham wrote:
> Hi Thomas,
>
> On 21/06/19 6:17 PM, Thomas Petazzoni wrote:
>> Hello Chris,
>>
>> On Fri, 21 Jun 2019 04:03:27 +
>> Chris Packham wrote:
>>
>>> I'm in the process of updating the kernel version used on our products
>>> from 4.4 -> 5.1.
>>>
>>> We have one product that uses a Kirkwood CPU, IDT PCI bridge and Marvell
>>> Switch ASIC. The Switch ASIC presents as multiple PCI devices.
>>>
>>> The hardware setup looks like this
>>> __
>>> [ Kirkwood ] --- [ IDT 5T5 ] ---+--- | |
>>> +--- | Switch |
>>> +--- | |
>>> +--- |__|
>>>
>>> On the 4.4 based kernel things are fine
>>>
>>> [root@awplus flash]# lspci -t
>>> -[:00]---01.0-[01-06]00.0-[02-06]--+-02.0-[03]00.0
>>> +-03.0-[04]00.0
>>> +-04.0-[05]00.0
>>> \-05.0-[06]00.0
>>>
>>> But on the 5.1 based kernel things get a little weird
>>>
>>> [root@awplus flash]# lspci -t
>>> -[:00]---01.0-[01-06]--+-00.0-[02-06]--
>>> +-01.0
>>> +-02.0-[02-06]--
>>> +-03.0-[02-06]--
>>> +-04.0-[02-06]--
>>> +-05.0-[02-06]--
>>> +-06.0-[02-06]--
>>> +-07.0-[02-06]--
>>> +-08.0-[02-06]--
>>> +-09.0-[02-06]--
>>> +-0a.0-[02-06]--
>>> +-0b.0-[02-06]--
>>> +-0c.0-[02-06]--
>>> +-0d.0-[02-06]--
>>> +-0e.0-[02-06]--
>>> +-0f.0-[02-06]--
>>> +-10.0-[02-06]--
>>> +-11.0-[02-06]--
>>> +-12.0-[02-06]--
>>> +-13.0-[02-06]--
>>> +-14.0-[02-06]--
>>> +-15.0-[02-06]--
>>> +-16.0-[02-06]--
>>> +-17.0-[02-06]--
>>> +-18.0-[02-06]--
>>> +-19.0-[02-06]--
>>> +-1a.0-[02-06]--
>>> +-1b.0-[02-06]--
>>> +-1c.0-[02-06]--
>>> +-1d.0-[02-06]--
>>> +-1e.0-[02-06]--
>>> \-1f.0-[02-06]--+-02.0-[03]00.0
>>> +-03.0-[04]00.0
>>> +-04.0-[05]00.0
>>> \-05.0-[06]00.0
>>>
>>>
>>> I'll start bisecting to see where things started going wrong. I just
>>> wondered if this rings any bells for anyone.
>>
>> I am almost sure that the culprit is
>> 1f08673eef1236f7d02d93fcf596bb8531ef0d12 ("PCI: mvebu: Convert to PCI
>> emulated bridge config space").
>
> The problem seems to pre-date this commit. I've gone back as far as 4.18
> and the problem still exists (in fact there are more duplicate devices).
> I'll keep going back (unfortunately due to out platform being out of
> tree it's not a simple bisect).
>
>> I still think it makes sense to share the bridge emulation code between
>> the mvebu and aardvark drivers, but this sharing has required making
>> the code very different, with lots of subtle differences in behavior in
>> how registers are emulated.
>
> Agreed. Bugs love to hide in duplicated code.
>
> I will admit to being ignorant about the need for an emulated bridge. I
> know it has something to do with the type of transaction used for the
> downstream devices. I also know that these systems won't work without an
> emulated bridge.
>
>> Unfortunately, I don't have access to one of these complicated PCI
>> setup with a HW switch on the way, so I couldn't test this kind of
>> setups.
>>
>> Do you mind helping with figuring out what the issues are ? That would
>> be really nice.
>
> No problem. As I said I'll keep going to find a point where behaviour
> turns bad for me. I suspect we might find other problems along the way.
>
Some progress. Our defconfig had CONFIG_CMDLINE="pci=pcie_scan_all" in
it. This dated back to before we were using a devicetree with our
kirkwood platforms. At some point this started having an effect on the
emulated bridge.
Re: [PATCH] csky: dts: Add NationalChip GX6605S
Hi Andreas,
On Tue, Jun 25, 2019 at 9:25 AM Andreas Färber wrote:
>
> Am 25.06.19 um 02:45 schrieb Guo Ren:
> > Thx for the patch. No need seperate part into dtsi,
>
> Sorry, I know from many arm contributions that using a .dtsi is the
> right thing here. It logically separates the chip from the board, even
> if there's only one evaluation board currently. Think about set-top
> boxes that someone might author a .dts for - they should be able to
> reuse the .dtsi for the SoC rather than copy it.
gx6605s.dts is simple now, it's unnecessary to seperate it into two
pieces. Other things from you is all OK for me.
>
> > just follow:
> > https://lore.kernel.org/linux-csky/1561376581-19568-1-git-send-email-guo...@kernel.org/T/#u
>
> Thanks for that pointer! I still think my node names are cleaner and
> also the structure of keeping clocks and gpio users outside of /soc. I
> see the value you use is 27 MHz, will try it tomorrow. I see you use
> nice KEY_ constants, whereas I just took the raw values from the dtb.
>
> I notice that your patch doesn't have any Copyright header, how should I
> credit you in the resulting combined patch? I would then also add your
> SoB from the patch you linked to.
Copyright could be the same in arch/csky/kernel/setup.c or add yours
in addition.
>
> More comments inline...
>
> > On Tue, Jun 25, 2019 at 8:28 AM Andreas Färber wrote:
> >>
> >> Add Device Trees for NationalChip GX6605S SoC (based on CK610 CPU) and its
> >> dev board. GxLoader expects as filename gx6605s.dtb, so keep that.
> >> The bootargs are prepared to boot from USB and to output to serial.
> >>
> >> Compatibles for the SoC and board are left out for now.
> >>
> >> Signed-off-by: Andreas Färber
> >> ---
> >> arch/csky/boot/dts/gx6605s.dts | 104
> >>
> >> arch/csky/boot/dts/gx6605s.dtsi | 82 +++
> >> 2 files changed, 186 insertions(+)
> >> create mode 100644 arch/csky/boot/dts/gx6605s.dts
> >> create mode 100644 arch/csky/boot/dts/gx6605s.dtsi
> >>
> >> diff --git a/arch/csky/boot/dts/gx6605s.dts
> >> b/arch/csky/boot/dts/gx6605s.dts
> >> new file mode 100644
> >> index ..f7511024ec6f
> >> --- /dev/null
> >> +++ b/arch/csky/boot/dts/gx6605s.dts
> [...]
> >> + leds {
> >> + compatible = "gpio-leds";
> >> +
> >> + led0 {
> >> + label = "led10";
>
> I forgot to align the numbering here. The label matches the GPIO and
> what is printed on the board.
leds and button is so specific, that's is just a example. You could
keep your own style in the dts.
>
> >> + gpios = < 10 GPIO_ACTIVE_LOW>;
> >> + linux,default-trigger = "heartbeat";
>
> This green one stops blinking and stays on.
Seems there is no driver for it.
>
> >> + };
> >> +
> >> + led1 {
> >> + label = "led11";
> >> + gpios = < 11 GPIO_ACTIVE_LOW>;
> >> + linux,default-trigger = "timer";
>
> This red one keeps blinking after the panic.
>
> >> + };
> >> +
> >> + led2 {
> >> + label = "led12";
> >> + gpios = < 12 GPIO_ACTIVE_LOW>;
> >> + linux,default-trigger = "default-on";
> >> + };
> >> +
> >> + led3 {
> >> + label = "led13";
> >> + gpios = < 13 GPIO_ACTIVE_LOW>;
> >> + linux,default-trigger = "default-on";
>
> These two remain off. So I wonder whether the GPIO polarity is wrong?
> In the example usb.img the gpio-leds module is not loaded by default, so
> maybe it wasn't noticed before?
I try this 1 years ago in linux-4.9 and it need verifying.
>
> Also, many arm boards use more complex LED labels with multiple parts
> separated by colon, like "boardname:name:function" or so.
Name is Ok for me as long as it's correct.
>
> >> + };
> >> + };
> [...]
> >> diff --git a/arch/csky/boot/dts/gx6605s.dtsi
> >> b/arch/csky/boot/dts/gx6605s.dtsi
> >> new file mode 100644
> >> index ..956af5674add
> >> --- /dev/null
> >> +++ b/arch/csky/boot/dts/gx6605s.dtsi
> >> @@ -0,0 +1,82 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause */
> >> +/*
> >> + * NationalChip GX6605S SoC
> >> + *
> >> + * Copyright (c) 2019 Andreas Färber
> >> + */
> >> +
> >> +/ {
> >> + #address-cells = <1>;
> >> + #size-cells = <1>;
> >> +
> >> + cpus {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + cpu0: cpu@0 {
> >> + device_type = "cpu";
> >> + compatible = "csky,ck610";
> >> + reg = <0>;
> >> + };
> >> + };
> >> +
> >> + soc {
> >> + compatible = "simple-bus";
> >> +
Re: [PATCH] rtc: Don't state that the RTC holds UTC in case it doesn't
On Mon, 24 Jun 2019, Alexandre Belloni wrote:
> On 21/06/2019 11:51:26+1000, Finn Thain wrote:
> > Some machines store local time in the Real Time Clock. The hard-coded
> > "UTC" string is wrong on those machines so just omit that string.
> > Update the log parser so it doesn't require the string "UTC".
> >
>
> I don't agree, hctossys will always think the RTC is in UTC.
Well, I wasn't speculating about a theoretical problem. This is a bug that
was reported to me by a user of Debian/powerpc system.
I was able to confirm that the bug also affects dual-boot Windows/Linux on
x86 with CONFIG_RTC_HCTOSYS=y.
> If you store local time in the RTC, then you are probably not using
> hctosys because it definitively doesn't know about the timezone and will
> incorrectly set the system time. That information is usually kept in
> /etc/adjtime.
>
In the Debian/powerpc bug report, the timezone is obtained from the NVRAM:
[0.00] PowerMac motherboard: PowerBook Wallstreet
...
[0.00] GMT Delta read from XPRAM: -360 minutes, DST: on
...
[ 37.605859] rtc-generic rtc-generic: rtc core: registered rtc-generic as rtc0
...
[ 40.346255] rtc-generic rtc-generic: setting system clock to 2019-06-19
15:17:35 UTC (1560957455)
...
Though I don't know whether the sys_tz value is relevant here.
Anyway, here's the bug reproduced on x86 --
# dmesg | grep rtc_cmos
[0.543878] rtc_cmos 00:02: RTC can wake from S4
[0.544090] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0
[0.544090] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram,
hpet irqs
[0.545807] rtc_cmos 00:02: setting system clock to 2019-06-25 11:24:14 UTC
(1561461854)
# grep . /etc/adjtime /etc/timezone
/etc/adjtime:0.000120 1550184138 0.00
/etc/adjtime:1550184138
/etc/adjtime:LOCAL
/etc/timezone:Australia/Melbourne
# hwclock --show
2019-06-25 11:47:49.702660+10:00
# date --iso-8601=s
2019-06-25T11:48:01+10:00
#
Looks wrong to me. What am I missing?
--
> > Signed-off-by: Finn Thain
> > ---
> > drivers/rtc/hctosys.c | 2 +-
> > tools/power/pm-graph/bootgraph.py | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/rtc/hctosys.c b/drivers/rtc/hctosys.c
> > index ff2092a0d38c..2270eca23203 100644
> > --- a/drivers/rtc/hctosys.c
> > +++ b/drivers/rtc/hctosys.c
> > @@ -58,7 +58,7 @@ static int __init rtc_hctosys(void)
> >
> > err = do_settimeofday64();
> >
> > - dev_info(rtc->dev.parent, "setting system clock to %ptR UTC (%lld)\n",
> > + dev_info(rtc->dev.parent, "setting system clock to %ptR (%lld)\n",
> > , (long long)tv64.tv_sec);
> >
> > err_read:
> > diff --git a/tools/power/pm-graph/bootgraph.py
> > b/tools/power/pm-graph/bootgraph.py
> > index 6dae57041537..5a045d1cb879 100755
> > --- a/tools/power/pm-graph/bootgraph.py
> > +++ b/tools/power/pm-graph/bootgraph.py
> > @@ -333,7 +333,7 @@ def parseKernelLog():
> > if(not sysvals.stamp['kernel']):
> > sysvals.stamp['kernel'] =
> > sysvals.kernelVersion(msg)
> > continue
> > - m = re.match('.* setting system clock to (?P.*) UTC.*', msg)
> > + m = re.match('.* setting system clock to (?P.*) (?:UTC
> > )?\(.*', msg)
> > if(m):
> > bt = datetime.strptime(m.group('t'), '%Y-%m-%d
> > %H:%M:%S')
> > bt = bt - timedelta(seconds=int(ktime))
> > --
> > 2.21.0
> >
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
Re: [PATCH] nios2: remove pointless second entry for CONFIG_TRACE_IRQFLAGS_SUPPORT
On Sun, 2019-06-23 at 23:13 +0900, Masahiro Yamada wrote: > On Sun, May 12, 2019 at 10:16 PM Masahiro Yamada > wrote: > > > > > > Strangely enough, NIOS2 defines TRACE_IRQFLAGS_SUPPORT twice > > with different values, which is pointless and confusing. > > > > [1] arch/nios2/Kconfig > > > > config TRACE_IRQFLAGS_SUPPORT > > def_bool n > > > > [2] arch/nios2/Kconfig.debug > > > > config TRACE_IRQFLAGS_SUPPORT > > def_bool y > > > > [1] is included before [2]. In the Kconfig syntax, the first one > > is effective. So, TRACE_IRQFLAGS_SUPPORT is always 'n'. > > > > The second define in arch/nios2/Kconfig.debug is dead code. > > > > Signed-off-by: Masahiro Yamada > > --- > Ping. > > Acked-by: Ley Foon Tan Will integrate to next kernel version. Thanks. > > > > arch/nios2/Kconfig.debug | 3 --- > > 1 file changed, 3 deletions(-) > > > > diff --git a/arch/nios2/Kconfig.debug b/arch/nios2/Kconfig.debug > > index f1da8a7..a8bc06e 100644 > > --- a/arch/nios2/Kconfig.debug > > +++ b/arch/nios2/Kconfig.debug > > @@ -1,8 +1,5 @@ > > # SPDX-License-Identifier: GPL-2.0 > > > > -config TRACE_IRQFLAGS_SUPPORT > > - def_bool y > > - > > config EARLY_PRINTK > > bool "Activate early kernel debugging" > > default y > > -- > > 2.7.4 > > > > -- > Best Regards > Masahiro Yamada > > Regards Ley Foon
Re: [x86/hotplug] e1056a25da: WARNING:at_arch/x86/kernel/apic/apic.c:#setup_local_APIC
On 6/22/19 3:08 AM, Thomas Gleixner wrote:
On Thu, 20 Jun 2019, kernel test robot wrote:
FYI, we noticed the following commit (built with gcc-7):
commit: e1056a25daa6460c95e92d7d6853d05ad62458f7 ("x86/hotplug: Silence APIC and NMI
when CPU is dead")
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git WIP.x86/ipi
in testcase: locktorture
with following parameters:
runtime: 300s
test: cpuhotplug
test-description: This torture test consists of creating a number of kernel
threads which acquire the lock and hold it for specific amount of time, thus
simulating different critical region behaviors.
test-url: https://www.kernel.org/doc/Documentation/locking/locktorture.txt
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 2G
I cannot reproduce that issue. What's the underlying hardware machine?
brand: Genuine Intel(R) CPU 000 @ 2.27GHz
model: Westmere-EX
memory: 256G
nr_node: 4
nr_cpu: 80
Best Regards,
Rong Chen
Thanks,
tglx
RE: Re: [PATCH v4 13/16] PM / devfreq: tegra: Support Tegra30
Sender : Dmitry Osipenko >24.06.2019 14:11, MyungJoo Ham пишет: >>> >>> - Original Message - >>> Sender : Dmitry Osipenko >>> >>> 24.06.2019 10:34, MyungJoo Ham пишет: > > A question: > > Does this driver support Tegra20 as well? > I'm asking this because ARCH_TEGRA includes ARCH_TEGRA_2x_SOC > according to /drivers/soc/tegra/Kconfig. > For this matter, how about updating your 13/16 patch as follows? >> [] >>> >>> Good call! I'll update this patch following yours suggestion, thanks. >> >> Or, you may approve the modified commits here: >> https://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git/log/?h=for-next > >Looks almost good to me! > >I just recalled that there is also a 64bit variant of Tegra124, the Tegra132. >Hence >the Tegra30+ Kconfig entry should look like this (it's also worthy to break >the lines >for readability): > >diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig >index ccb1a68c4b51..bd2efbc27725 100644 >--- a/drivers/devfreq/Kconfig >+++ b/drivers/devfreq/Kconfig >@@ -94,7 +94,10 @@ config ARM_EXYNOS_BUS_DEVFREQ > > config ARM_TEGRA_DEVFREQ >tristate "NVIDIA Tegra30/114/124/210 DEVFREQ Driver" >- depends on ARCH_TEGRA || COMPILE_TEST >+ depends on ARCH_TEGRA_3x_SOC || ARCH_TEGRA_114_SOC || \ >+ ARCH_TEGRA_132_SOC || ARCH_TEGRA_124_SOC || \ >+ ARCH_TEGRA_210_SOC || \ >+ COMPILE_TEST >select PM_OPP >help > This adds the DEVFREQ driver for the Tegra family of SoCs. > >Could you please adjust the patches like I'm suggesting? I'll approve yours >change >then and won't re-spin the first batch of the patches. I've adjusted as you suggested. It's pushed to the git repo as well. Cheers, MyungJoo.
WARNING in mark_lock
Hello, syzbot found the following crash on: HEAD commit:dc636f5d Add linux-next specific files for 20190620 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=162b68b1a0 kernel config: https://syzkaller.appspot.com/x/.config?x=99c104b0092a557b dashboard link: https://syzkaller.appspot.com/bug?extid=a861f52659ae2596492b compiler: gcc (GCC) 9.0.0 20181231 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=110b24f6a0 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+a861f52659ae25964...@syzkaller.appspotmail.com [ cut here ] DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 0 PID: 9968 at kernel/locking/lockdep.c:167 hlock_class kernel/locking/lockdep.c:167 [inline] WARNING: CPU: 0 PID: 9968 at kernel/locking/lockdep.c:167 hlock_class kernel/locking/lockdep.c:156 [inline] WARNING: CPU: 0 PID: 9968 at kernel/locking/lockdep.c:167 mark_lock+0x22b/0x11e0 kernel/locking/lockdep.c:3594 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 9968 Comm: syz-executor.2 Not tainted 5.2.0-rc5-next-20190620 #19 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x172/0x1f0 lib/dump_stack.c:113 panic+0x2dc/0x755 kernel/panic.c:219 __warn.cold+0x20/0x4c kernel/panic.c:576 report_bug+0x263/0x2b0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:179 [inline] fixup_bug arch/x86/kernel/traps.c:174 [inline] do_error_trap+0x11b/0x200 arch/x86/kernel/traps.c:272 do_invalid_op+0x37/0x50 arch/x86/kernel/traps.c:291 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:986 RIP: 0010:hlock_class kernel/locking/lockdep.c:167 [inline] RIP: 0010:hlock_class kernel/locking/lockdep.c:156 [inline] RIP: 0010:mark_lock+0x22b/0x11e0 kernel/locking/lockdep.c:3594 Code: d0 7c 08 84 d2 0f 85 33 0f 00 00 44 8b 15 4d 14 4a 08 45 85 d2 75 b6 48 c7 c6 c0 a6 8b 87 48 c7 c7 00 a7 8b 87 e8 ad e6 eb ff <0f> 0b 31 db e9 a8 fe ff ff 48 c7 c7 80 71 86 8a e8 f0 95 53 00 e9 RSP: 0018:8880ae809ad0 EFLAGS: 00010082 RAX: RBX: 0f1d RCX: RDX: 0001 RSI: 815b37e6 RDI: ed1015d0134c RBP: 8880ae809b20 R08: 88808662e0c0 R09: fbfff11b3285 R10: fbfff11b3284 R11: 88d99423 R12: R13: 88808662e9c8 R14: 004f R15: 000c4f1d mark_usage kernel/locking/lockdep.c:3485 [inline] __lock_acquire+0x1e1a/0x4680 kernel/locking/lockdep.c:3839 lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4418 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x95/0xcd kernel/locking/spinlock.c:159 try_to_wake_up+0x90/0x1430 kernel/sched/core.c:2000 wake_up_process+0x10/0x20 kernel/sched/core.c:2114 hrtimer_wakeup+0x48/0x60 kernel/time/hrtimer.c:1636 __run_hrtimer kernel/time/hrtimer.c:1388 [inline] __hrtimer_run_queues+0x364/0xe40 kernel/time/hrtimer.c:1450 hrtimer_interrupt+0x314/0x770 kernel/time/hrtimer.c:1508 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1041 [inline] smp_apic_timer_interrupt+0x12a/0x5b0 arch/x86/kernel/apic/apic.c:1066 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:806 Kernel Offset: disabled Rebooting in 86400 seconds.. --- This bug is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this bug report. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this bug, for details see: https://goo.gl/tpsmEJ#testing-patches
[PATCH] tracing/snapshot: resize spare buffer if size changed
Current snapshot implementation swaps two ring_buffers even though their
sizes are different from each other, that can cause an inconsistency
between the contents of buffer_size_kb file and the current buffer size.
For example:
# cat buffer_size_kb
7 (expanded: 1408)
# echo 1 > events/enable
# grep bytes per_cpu/cpu0/stats
bytes: 1441020
# echo 1 > snapshot // current:1408, spare:1408
# echo 123 > buffer_size_kb // current:123, spare:1408
# echo 1 > snapshot // current:1408, spare:123
# grep bytes per_cpu/cpu0/stats
bytes: 1443700
# cat buffer_size_kb
123 // != current:1408
And also, a similar per-cpu case hits the following WARNING:
Reproducer:
# echo 1 > per_cpu/cpu0/snapshot
# echo 123 > buffer_size_kb
# echo 1 > per_cpu/cpu0/snapshot
WARNING:
WARNING: CPU: 0 PID: 1946 at kernel/trace/trace.c:1607
update_max_tr_single.part.0+0x2b8/0x380
Modules linked in:
CPU: 0 PID: 1946 Comm: bash Not tainted 5.2.0-rc6 #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-2.fc30
04/01/2014
RIP: 0010:update_max_tr_single.part.0+0x2b8/0x380
Code: ff e8 dc da f9 ff 0f 0b e9 88 fe ff ff e8 d0 da f9 ff 44 89 ee bf f5 ff
ff ff e8 33 dc f9 ff 41 83 fd f5 74 96 e8 b8 da f9 ff <0f> 0b eb 8d e8 af da f9
ff 0f 0b e9 bf fd ff ff e8 a3 da f9 ff 48
RSP: 0018:888063e4fca0 EFLAGS: 00010093
RAX: 888066214380 RBX: 99850fe0 RCX: 964298a8
RDX: RSI: fff5 RDI: 0005
RBP: 11100c7c9f96 R08: 888066214380 R09: ed100c7c9f9b
R10: ed100c7c9f9a R11: 0003 R12:
R13: ffea R14: 888066214380 R15: 99851060
FS: 7f9f8173c700() GS:88806d00() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 00714dc0 CR3: 66fa6000 CR4: 06f0
Call Trace:
? trace_array_printk_buf+0x140/0x140
? __mutex_lock_slowpath+0x10/0x10
tracing_snapshot_write+0x4c8/0x7f0
? trace_printk_init_buffers+0x60/0x60
? selinux_file_permission+0x3b/0x540
? tracer_preempt_off+0x38/0x506
? trace_printk_init_buffers+0x60/0x60
__vfs_write+0x81/0x100
vfs_write+0x1e1/0x560
ksys_write+0x126/0x250
? __ia32_sys_read+0xb0/0xb0
? do_syscall_64+0x1f/0x390
do_syscall_64+0xc1/0x390
entry_SYSCALL_64_after_hwframe+0x49/0xbe
This patch adds resize_buffer_duplicate_size() to check if there is a
difference between current/spare buffer sizes and resize a spare buffer
if necessary.
Signed-off-by: Eiichi Tsukata
---
kernel/trace/trace.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 83e08b78dbee..3edd4c1b96be 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6719,11 +6719,13 @@ tracing_snapshot_write(struct file *filp, const char
__user *ubuf, size_t cnt,
break;
}
#endif
- if (!tr->allocated_snapshot) {
+ if (tr->allocated_snapshot)
+ ret = resize_buffer_duplicate_size(>max_buffer,
+ >trace_buffer, iter->cpu_file);
+ else
ret = tracing_alloc_snapshot_instance(tr);
- if (ret < 0)
- break;
- }
+ if (ret < 0)
+ break;
local_irq_disable();
/* Now, we're going to swap */
if (iter->cpu_file == RING_BUFFER_ALL_CPUS)
--
2.21.0
Re: [PATCH] csky: dts: Add NationalChip GX6605S
Am 25.06.19 um 02:45 schrieb Guo Ren:
> Thx for the patch. No need seperate part into dtsi,
Sorry, I know from many arm contributions that using a .dtsi is the
right thing here. It logically separates the chip from the board, even
if there's only one evaluation board currently. Think about set-top
boxes that someone might author a .dts for - they should be able to
reuse the .dtsi for the SoC rather than copy it.
> just follow:
> https://lore.kernel.org/linux-csky/1561376581-19568-1-git-send-email-guo...@kernel.org/T/#u
Thanks for that pointer! I still think my node names are cleaner and
also the structure of keeping clocks and gpio users outside of /soc. I
see the value you use is 27 MHz, will try it tomorrow. I see you use
nice KEY_ constants, whereas I just took the raw values from the dtb.
I notice that your patch doesn't have any Copyright header, how should I
credit you in the resulting combined patch? I would then also add your
SoB from the patch you linked to.
More comments inline...
> On Tue, Jun 25, 2019 at 8:28 AM Andreas Färber wrote:
>>
>> Add Device Trees for NationalChip GX6605S SoC (based on CK610 CPU) and its
>> dev board. GxLoader expects as filename gx6605s.dtb, so keep that.
>> The bootargs are prepared to boot from USB and to output to serial.
>>
>> Compatibles for the SoC and board are left out for now.
>>
>> Signed-off-by: Andreas Färber
>> ---
>> arch/csky/boot/dts/gx6605s.dts | 104
>>
>> arch/csky/boot/dts/gx6605s.dtsi | 82 +++
>> 2 files changed, 186 insertions(+)
>> create mode 100644 arch/csky/boot/dts/gx6605s.dts
>> create mode 100644 arch/csky/boot/dts/gx6605s.dtsi
>>
>> diff --git a/arch/csky/boot/dts/gx6605s.dts b/arch/csky/boot/dts/gx6605s.dts
>> new file mode 100644
>> index ..f7511024ec6f
>> --- /dev/null
>> +++ b/arch/csky/boot/dts/gx6605s.dts
[...]
>> + leds {
>> + compatible = "gpio-leds";
>> +
>> + led0 {
>> + label = "led10";
I forgot to align the numbering here. The label matches the GPIO and
what is printed on the board.
>> + gpios = < 10 GPIO_ACTIVE_LOW>;
>> + linux,default-trigger = "heartbeat";
This green one stops blinking and stays on.
>> + };
>> +
>> + led1 {
>> + label = "led11";
>> + gpios = < 11 GPIO_ACTIVE_LOW>;
>> + linux,default-trigger = "timer";
This red one keeps blinking after the panic.
>> + };
>> +
>> + led2 {
>> + label = "led12";
>> + gpios = < 12 GPIO_ACTIVE_LOW>;
>> + linux,default-trigger = "default-on";
>> + };
>> +
>> + led3 {
>> + label = "led13";
>> + gpios = < 13 GPIO_ACTIVE_LOW>;
>> + linux,default-trigger = "default-on";
These two remain off. So I wonder whether the GPIO polarity is wrong?
In the example usb.img the gpio-leds module is not loaded by default, so
maybe it wasn't noticed before?
Also, many arm boards use more complex LED labels with multiple parts
separated by colon, like "boardname:name:function" or so.
>> + };
>> + };
[...]
>> diff --git a/arch/csky/boot/dts/gx6605s.dtsi
>> b/arch/csky/boot/dts/gx6605s.dtsi
>> new file mode 100644
>> index ..956af5674add
>> --- /dev/null
>> +++ b/arch/csky/boot/dts/gx6605s.dtsi
>> @@ -0,0 +1,82 @@
>> +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause */
>> +/*
>> + * NationalChip GX6605S SoC
>> + *
>> + * Copyright (c) 2019 Andreas Färber
>> + */
>> +
>> +/ {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu0: cpu@0 {
>> + device_type = "cpu";
>> + compatible = "csky,ck610";
>> + reg = <0>;
>> + };
>> + };
>> +
>> + soc {
>> + compatible = "simple-bus";
>> + interrupt-parent = <>;
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges;
>> +
>> + timer0: timer@20a000 {
>> + compatible = "csky,gx6605s-timer";
The reason I left out the compatible for the SoC/board is that it looks
unclean to me that you're using a "csky," vendor prefix for interrupt
controller and timer instead of a new "nationalchip," prefix for the SoC
vendor. Did I miss some reasoning for that, or did that slip through
patch review?
Being the first board we'd need to create a new YAML file to document
them, I assume. Not sure what the best scope (=name) would be here.
>> + reg = <0x0020a000 0x400>;
>> + clocks
Re: [alsa-devel] [PATCH v2 11/11] ASoC: topology: Consolidate and fix asoc_tplg_dapm_widget_*_create flow
On Mon, 2019-06-17 at 13:36 +0200, Amadeusz Sławiński wrote:
> There are a few soc_tplg_dapm_widget_*_create functions with similar
> content, but slightly different flow, unify their flow and make sure
> that we go to error handler and free memory in case of failure.
>
> Signed-off-by: Amadeusz Sławiński <
> amadeuszx.slawin...@linux.intel.com>
Acked-by: Ranjani Sridharan
I'm good with all the patches in the series.
Thanks,
Ranjani
> ---
> sound/soc/soc-topology.c | 77 ++--
>
> 1 file changed, 35 insertions(+), 42 deletions(-)
>
> diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c
> index a926c2afbe05..fc1f1d6f9e92 100644
> --- a/sound/soc/soc-topology.c
> +++ b/sound/soc/soc-topology.c
> @@ -1310,14 +1310,15 @@ static struct snd_kcontrol_new
> *soc_tplg_dapm_widget_dmixer_create(
>
> for (i = 0; i < num_kcontrols; i++) {
> mc = (struct snd_soc_tplg_mixer_control *)tplg->pos;
> - sm = kzalloc(sizeof(*sm), GFP_KERNEL);
> - if (sm == NULL)
> - goto err;
>
> /* validate kcontrol */
> if (strnlen(mc->hdr.name,
> SNDRV_CTL_ELEM_ID_NAME_MAXLEN) ==
> SNDRV_CTL_ELEM_ID_NAME_MAXLEN)
> - goto err_str;
> + goto err_sm;
> +
> + sm = kzalloc(sizeof(*sm), GFP_KERNEL);
> + if (sm == NULL)
> + goto err_sm;
>
> tplg->pos += (sizeof(struct snd_soc_tplg_mixer_control)
> +
> le32_to_cpu(mc->priv.size));
> @@ -1327,7 +1328,7 @@ static struct snd_kcontrol_new
> *soc_tplg_dapm_widget_dmixer_create(
>
> kc[i].name = kstrdup(mc->hdr.name, GFP_KERNEL);
> if (kc[i].name == NULL)
> - goto err_str;
> + goto err_sm;
> kc[i].private_value = (long)sm;
> kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
> kc[i].access = mc->hdr.access;
> @@ -1353,8 +1354,7 @@ static struct snd_kcontrol_new
> *soc_tplg_dapm_widget_dmixer_create(
> err = soc_tplg_kcontrol_bind_io(>hdr, [i],
> tplg);
> if (err) {
> soc_control_err(tplg, >hdr, mc->hdr.name);
> - kfree(sm);
> - continue;
> + goto err_sm;
> }
>
> /* create any TLV data */
> @@ -1367,20 +1367,19 @@ static struct snd_kcontrol_new
> *soc_tplg_dapm_widget_dmixer_create(
> dev_err(tplg->dev, "ASoC: failed to init %s\n",
> mc->hdr.name);
> soc_tplg_free_tlv(tplg, [i]);
> - kfree(sm);
> - continue;
> + goto err_sm;
> }
> }
> return kc;
>
> -err_str:
> - kfree(sm);
> -err:
> - for (--i; i >= 0; i--) {
> - kfree((void *)kc[i].private_value);
> +err_sm:
> + for (; i >= 0; i--) {
> + sm = (struct soc_mixer_control *)kc[i].private_value;
> + kfree(sm);
> kfree(kc[i].name);
> }
> kfree(kc);
> +
> return NULL;
> }
>
> @@ -1401,11 +1400,11 @@ static struct snd_kcontrol_new
> *soc_tplg_dapm_widget_denum_create(
> /* validate kcontrol */
> if (strnlen(ec->hdr.name,
> SNDRV_CTL_ELEM_ID_NAME_MAXLEN) ==
> SNDRV_CTL_ELEM_ID_NAME_MAXLEN)
> - goto err;
> + goto err_se;
>
> se = kzalloc(sizeof(*se), GFP_KERNEL);
> if (se == NULL)
> - goto err;
> + goto err_se;
>
> tplg->pos += (sizeof(struct snd_soc_tplg_enum_control)
> +
> ec->priv.size);
> @@ -1414,10 +1413,8 @@ static struct snd_kcontrol_new
> *soc_tplg_dapm_widget_denum_create(
> ec->hdr.name);
>
> kc[i].name = kstrdup(ec->hdr.name, GFP_KERNEL);
> - if (kc[i].name == NULL) {
> - kfree(se);
> + if (kc[i].name == NULL)
> goto err_se;
> - }
> kc[i].private_value = (long)se;
> kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
> kc[i].access = ec->hdr.access;
> @@ -1482,44 +1479,43 @@ static struct snd_kcontrol_new
> *soc_tplg_dapm_widget_denum_create(
> for (; i >= 0; i--) {
> /* free values and texts */
> se = (struct soc_enum *)kc[i].private_value;
> - if (!se)
> - continue;
>
> - soc_tplg_denum_remove_values(se);
> - soc_tplg_denum_remove_texts(se);
> + if (se) {
> + soc_tplg_denum_remove_values(se);
> + soc_tplg_denum_remove_texts(se);
> + }
>
> kfree(se);
>
Re: [PATCH v2] kernel/isolation: Assert that a housekeeping CPU comes up at boot time
On Tue, Jun 25, 2019 at 10:17:20AM +1000, Nicholas Piggin wrote:
> +static int __init housekeeping_verify_smp(void)
> +{
> + int cpu;
> +
> + if (!housekeeping_flags)
> + return 0;
> +
> + /*
> + * Early housekeeping setup is done before CPUs come up, and there are
> + * a range of options scattered around that can restrict which CPUs
> + * come up. It is possible to pass in a combination of housekeeping
> + * and SMP arguments that result in housekeeping assigned to an
> + * offline CPU.
> + *
> + * Check that condition here after SMP comes up, and give a useful
> + * error message rather than an obscure non deterministic crash or
> + * hang later.
> + */
> + for_each_online_cpu(cpu) {
> + if (cpumask_test_cpu(cpu, housekeeping_mask))
> + return 0;
> + }
> + panic("Housekeeping: nohz_full= or isolcpus= resulted in no online CPUs
> for housekeeping.\n");
Ok let's keep the panic. But let's simplify and spare long iterations off boot
load:
if (!cpumask_intersects(cpu_online_mask, housekeeping_mask))
panic(...);
Thanks.
[RESEND PATCH v2] mtd: spinand: read return badly if the last page has bitflips
In case of the last page containing bitflips (ret > 0),
spinand_mtd_read() will return that number of bitflips for the last
page. But to me it looks like it should instead return max_bitflips like
it does when the last page read returns with 0.
Signed-off-by: liaoweixiong
Reviewed-by: Boris Brezillon
Reviewed-by: Frieder Schrempf
Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI NANDs")
---
drivers/mtd/nand/spi/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
index 556bfdb..6b9388d 100644
--- a/drivers/mtd/nand/spi/core.c
+++ b/drivers/mtd/nand/spi/core.c
@@ -511,12 +511,12 @@ static int spinand_mtd_read(struct mtd_info *mtd, loff_t
from,
if (ret == -EBADMSG) {
ecc_failed = true;
mtd->ecc_stats.failed++;
- ret = 0;
} else {
mtd->ecc_stats.corrected += ret;
max_bitflips = max_t(unsigned int, max_bitflips, ret);
}
+ ret = 0;
ops->retlen += iter.req.datalen;
ops->oobretlen += iter.req.ooblen;
}
--
1.9.1
Re: [RESEND PATCH v2] mtd: spinand: read return badly if the last page has bitflips
Um.. I am sorry. It is the first time for me to resend patch.
I will send this patch again with correct tags.
On 2019/6/24 PM10:47, Schrempf Frieder wrote:
> On 24.06.19 14:15, liaoweixiong wrote:
>> In case of the last page containing bitflips (ret > 0),
>> spinand_mtd_read() will return that number of bitflips for the last
>> page. But to me it looks like it should instead return max_bitflips like
>> it does when the last page read returns with 0.
>>
>> Signed-off-by: liaoweixiong
>> Acked-by: Boris Brezillon
>> Acked-by: Frieder Schrempf
>
> Why did you change our Reviewed-by tags to Acked-by tags?
>
>> Fixes: 7529df465248 ("mtd: nand: Add core infrastructure to support SPI
>> NANDs")
>> ---
>> drivers/mtd/nand/spi/core.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/spi/core.c b/drivers/mtd/nand/spi/core.c
>> index 556bfdb..6b9388d 100644
>> --- a/drivers/mtd/nand/spi/core.c
>> +++ b/drivers/mtd/nand/spi/core.c
>> @@ -511,12 +511,12 @@ static int spinand_mtd_read(struct mtd_info *mtd,
>> loff_t from,
>> if (ret == -EBADMSG) {
>> ecc_failed = true;
>> mtd->ecc_stats.failed++;
>> -ret = 0;
>> } else {
>> mtd->ecc_stats.corrected += ret;
>> max_bitflips = max_t(unsigned int, max_bitflips, ret);
>> }
>>
>> +ret = 0;
>> ops->retlen += iter.req.datalen;
>> ops->oobretlen += iter.req.ooblen;
>> }
--
liaoweixiong
Re: [PATCH RESEND] ARM: dts: qcom: msm8974-hammerhead: add device tree bindings for vibrator
On Tue, Jun 25, 2019 at 12:29:29AM +0200, Linus Walleij wrote: > On Sun, Jun 23, 2019 at 12:53 PM Brian Masney wrote: > > > 2) Do what Linus suggests above. We can use v1 of this series from last > >September (see below for link) that adds this to the pwm subsystem. > >The locking would need to be added so that it won't conflict with the > >clk subsystem. This can be tied into the input subsystem with the > >existing pwm-vibra driver. > > What I imagined was that the clk driver would double as a pwm driver. > Just register both interfaces. > > There are already plenty of combines clk+reset drivers for example. > > Otherwise I'm all for this approach (but that's just me). I agree that this makes sense. I especially like that it'll allow us to use the existing pwm-vibra driver in the input subsystem with this approach. Brian
Re: [PATCH] csky: dts: Add NationalChip GX6605S
Thx for the patch. No need seperate part into dtsi, just follow:
https://lore.kernel.org/linux-csky/1561376581-19568-1-git-send-email-guo...@kernel.org/T/#u
On Tue, Jun 25, 2019 at 8:28 AM Andreas Färber wrote:
>
> Add Device Trees for NationalChip GX6605S SoC (based on CK610 CPU) and its
> dev board. GxLoader expects as filename gx6605s.dtb, so keep that.
> The bootargs are prepared to boot from USB and to output to serial.
>
> Compatibles for the SoC and board are left out for now.
>
> Signed-off-by: Andreas Färber
> ---
> arch/csky/boot/dts/gx6605s.dts | 104
>
> arch/csky/boot/dts/gx6605s.dtsi | 82 +++
> 2 files changed, 186 insertions(+)
> create mode 100644 arch/csky/boot/dts/gx6605s.dts
> create mode 100644 arch/csky/boot/dts/gx6605s.dtsi
>
> diff --git a/arch/csky/boot/dts/gx6605s.dts b/arch/csky/boot/dts/gx6605s.dts
> new file mode 100644
> index ..f7511024ec6f
> --- /dev/null
> +++ b/arch/csky/boot/dts/gx6605s.dts
> @@ -0,0 +1,104 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause */
> +/*
> + * GX6605S dev board
> + *
> + * Copyright (c) 2019 Andreas Färber
> + */
> +
> +/dts-v1/;
> +
> +#include
> +
> +#include "gx6605s.dtsi"
> +
> +/ {
> + model = "Nationalchip GX6605S";
> +
> + aliases {
> + serial0 =
> + };
> +
> + chosen {
> + bootargs = "console=ttyS0,115200n8 root=/dev/sda2 rw
> rootwait";
> + stdout-path = "serial0:115200n8";
> + };
> +
> + memory@1000 {
> + device_type = "memory";
> + reg = <0x1000 0x0400>;
> + };
> +
> + dummy_apb_clk: dummy-apb-clk {
> + compatible = "fixed-clock";
> + clock-frequency = <2400>; /* guesstimate */
> + #clock-cells = <0>;
> + };
> +
> + buttons {
> + compatible = "gpio-keys-polled";
> + poll-interval = <100>;
> + autorepeat;
> +
> + button5 {
> + label = "button5";
> + linux,code = <103>;
> + gpios = < 5 GPIO_ACTIVE_LOW>;
> + };
> +
> + button6 {
> + label = "button6";
> + linux,code = <106>;
> + gpios = < 6 GPIO_ACTIVE_LOW>;
> + };
> +
> + button7 {
> + label = "button7";
> + linux,code = <28>;
> + gpios = < 7 GPIO_ACTIVE_LOW>;
> + };
> +
> + button8 {
> + label = "button8";
> + linux,code = <105>;
> + gpios = < 8 GPIO_ACTIVE_LOW>;
> + };
> +
> + button9 {
> + label = "button9";
> + linux,code = <108>;
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led0 {
> + label = "led10";
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "heartbeat";
> + };
> +
> + led1 {
> + label = "led11";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "timer";
> + };
> +
> + led2 {
> + label = "led12";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "default-on";
> + };
> +
> + led3 {
> + label = "led13";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "default-on";
> + };
> + };
> +};
> +
> + {
> + clocks = <_apb_clk>;
> +};
> diff --git a/arch/csky/boot/dts/gx6605s.dtsi b/arch/csky/boot/dts/gx6605s.dtsi
> new file mode 100644
> index ..956af5674add
> --- /dev/null
> +++ b/arch/csky/boot/dts/gx6605s.dtsi
> @@ -0,0 +1,82 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause */
> +/*
> + * NationalChip GX6605S SoC
> + *
> + * Copyright (c) 2019 Andreas Färber
> + */
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + device_type = "cpu";
> + compatible = "csky,ck610";
> + reg = <0>;
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + interrupt-parent = <>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
Re: [PATCH 5.1 000/121] 5.1.15-stable review
On Mon, 24 Jun 2019 at 15:38, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 5.1.15 release. > There are 121 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 26 Jun 2019 09:22:03 AM UTC. > 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/v5.x/stable-review/patch-5.1.15-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-5.1.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. Summary kernel: 5.1.15-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-5.1.y git commit: 815c105311e8cdba0f84293235f6f043152808cd git describe: v5.1.14-122-g815c105311e8 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.1-oe/build/v5.1.14-122-g815c105311e8 No regressions (compared to build v5.1.14) No fixes (compared to build v5.1.14) Ran 24427 total tests in the following environments and test suites. Environments -- - dragonboard-410c - hi6220-hikey - i386 - juno-r2 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - x86 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-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-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * ltp-fs-tests * network-basic-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH 4.19 00/90] 4.19.56-stable review
On Mon, 24 Jun 2019 at 15:33, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.19.56 release. > There are 90 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 26 Jun 2019 09:22:03 AM UTC. > 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.56-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. Summary kernel: 4.19.56-rc2 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.19.y git commit: d8e5ade617e917a499d5d59b24e19e71f80886a8 git describe: v4.19.55-92-gd8e5ade617e9 Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.55-92-gd8e5ade617e9 No regressions (compared to build v4.19.55) No fixes (compared to build v4.19.55) Ran 25252 total tests in the following environments and test suites. Environments -- - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - qemu_arm - qemu_arm64 - qemu_i386 - qemu_x86_64 - x15 - arm - x86_64 Test Suites --- * build * install-android-platform-tools-r2600 * kselftest * libgpiod * libhugetlbfs * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-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-syscalls-tests * ltp-timers-tests * perf * spectre-meltdown-checker-test * v4l2-compliance * network-basic-tests * ltp-open-posix-tests * kvm-unit-tests * kselftest-vsyscall-mode-native * kselftest-vsyscall-mode-none -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH] time/tick-broadcast: Fix tick_broadcast_offline() lockdep complaint
On Mon, Jun 24, 2019 at 04:44:22PM -0700, Paul E. McKenney wrote:
> On Tue, Jun 25, 2019 at 01:12:23AM +0200, Frederic Weisbecker wrote:
> > On Fri, Jun 21, 2019 at 04:46:02PM -0700, Paul E. McKenney wrote:
> > > @@ -3097,13 +3126,21 @@ static void sched_tick_remote(struct work_struct
> > > *work)
> > > /*
> > >* Run the remote tick once per second (1Hz). This arbitrary
> > >* frequency is large enough to avoid overload but short enough
> > > - * to keep scheduler internal stats reasonably up to date.
> > > + * to keep scheduler internal stats reasonably up to date. But
> > > + * first update state to reflect hotplug activity if required.
> > >*/
> > > + os = atomic_read(>state);
> > > + if (os) {
> > > + WARN_ON_ONCE(os != TICK_SCHED_REMOTE_OFFLINING);
> > > + if (atomic_inc_not_zero(>state))
> > > + return;
> >
> > Using inc makes me a bit nervous here. If we do so, we should somewhow
> > make sure that we never exceed a value higher than TICK_SCHED_REMOTE_OFFLINE
> > by accident.
> >
> > atomic_xchg() is probably a bit costlier but also safer as it allows
> > us to check both the old and the new value. That path shouldn't be
> > critically fast
> > after all.
>
> It would need to be cmpxchg() to avoid messing with the state if
> the state were somehow TICK_SCHED_REMOTE_RUNNING, right?
Ah indeed! Nevermind, let's keep things as they are then.
> > > + }
> > > queue_delayed_work(system_unbound_wq, dwork, HZ);
> > > }
> > >
> > > static void sched_tick_start(int cpu)
> > > {
> > > + int os;
> > > struct tick_work *twork;
> > >
> > > if (housekeeping_cpu(cpu, HK_FLAG_TICK))
> > > @@ -3112,15 +3149,20 @@ static void sched_tick_start(int cpu)
> > > WARN_ON_ONCE(!tick_work_cpu);
> > >
> > > twork = per_cpu_ptr(tick_work_cpu, cpu);
> > > - twork->cpu = cpu;
> > > - INIT_DELAYED_WORK(>work, sched_tick_remote);
> > > - queue_delayed_work(system_unbound_wq, >work, HZ);
> > > + os = atomic_xchg(>state, TICK_SCHED_REMOTE_RUNNING);
> > > + WARN_ON_ONCE(os == TICK_SCHED_REMOTE_RUNNING);
> >
> > See if we use atomic_inc(), we would need to also WARN(os >
> > TICK_SCHED_REMOTE_OFFLINE).
>
> How about if I put that WARN() between the atomic_inc_not_zero() and
> the return, presumably also adding braces?
Yeah, unfortunately there is no atomic_add_not_zero_return().
I guess we can live with a check using atomic_read(). In the best
case it returns the fresh increment, otherwise it should be REMOTE_RUNNING.
In any case the (os > TICK_SCHED_REMOTE_OFFLINE) check applies.
Thanks.
Re: [PATCH v4 08/11] thermal: sun8i: support ahb clocks
On Mon, Jun 24, 2019 at 08:23:33PM +0200, Maxime Ripard wrote:
> On Sun, Jun 23, 2019 at 12:42:03PM -0400, Yangtao Li wrote:
> > H3 has extra clock, so introduce something in ths_thermal_chip/ths_device
> > and adds the process of the clock.
> >
> > This is pre-work for supprt it.
> >
> > Signed-off-by: Yangtao Li
> > ---
> > drivers/thermal/sun8i_thermal.c | 17 -
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c
> > b/drivers/thermal/sun8i_thermal.c
> > index ed1c19bb27cf..04f53ffb6a14 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -54,6 +54,7 @@ struct tsensor {
> > };
> >
> > struct ths_thermal_chip {
> > + boolhas_ahb_clk;
> > int sensor_num;
> > int offset;
> > int scale;
> > @@ -69,6 +70,7 @@ struct ths_device {
> > struct regmap *regmap;
> > struct reset_control*reset;
> > struct clk *bus_clk;
> > + struct clk *ahb_clk;
>
> Hmm, thinking a bit about this, the name of those two clocks doesn't
> make sense. AHB is the bus being used to access that device, so the
> bus clock is the AHB clock.
>
> What is that clock being used for?
To control the A/D and sample averaging logic, I suppose. It's controlled by the
THS_CLK_REG (THS Clock Register) in H3 user manual.
bus_clk controls THS_GATING in BUS_CLK_GATING_REG2 (THS module is connected to
APB bus).
I'd call it ths_clk and bus_clk.
regards,
o.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH v1] KVM: x86: PMU Whitelist
Thanks for your feedback - I'll send out an updated version
incorporating your comments shortly (assuming you don't have more
after this).
> > +struct kvm_pmu_whitelist {
> > + __u64 event_mask;
>
> Is this "ARCH_PERFMON_EVENTSEL_EVENT | ARCH_PERFMON_EVENTSEL_UMASK"?
In most cases, I envision this being the case, but it's possible users
may want other bits - see response to the next question below.
> > + __u16 num_events;
> > + __u64 events[0];
>
> Can this be __u16?
> The lower 16 bits (umask+eventsel) already determines what the event is.
It looks like newer AMD processors also use bits 32-35 for eventsel
(see AMD64_EVENTSEL_EVENT/AMD64_RAW_EVENT_MASK in
arch/x86/include/asm/perf_event.h or a recent reference guide), though
it doesn't look like this has made it to pmu_amd.c in kvm yet.
Further, including the whole 64 bits could enable whitelisting some
events with particular modifiers (e.g. in_tx=0, but not in_tx=1). I'm
not sure if whitelisting with specific modifiers will be necessary,
but we definitely need more than u16 if we want to support any AMD
events that make use of those bits in the future.
> > + struct kvm_pmu_whitelist *whitelist;
>
> This could be per-VM and under rcu?
I'll try this out in the next version.
> Why not moving this filter to reprogram_gp_counter?
>
> You could directly compare "unit_mask, event_sel" with whitelist->events[i]
The reason is that this approach provides uniform behavior whether an
event is programmed on a fixed purpose counter vs a general purpose
one. Though I admit it's unlikely that instructions retired/cycles
wouldn't be whitelisted (and ref cycles can't be programmed on gp
counters), so it wouldn't be missing too much if I do move this to
reprogram_gp_counter. What do you think?
> I would directly return -EFAULT here.
>
> Same here.
Sounds good - I'll fix that in the next version.
> > + pmu->whitelist = new;
>
> Forgot to copy the whitelist-ed events to new?
Yep, somehow I deleted the lines that did this - thanks for pointing it out.
[PATCH] csky: dts: Add NationalChip GX6605S
Add Device Trees for NationalChip GX6605S SoC (based on CK610 CPU) and its
dev board. GxLoader expects as filename gx6605s.dtb, so keep that.
The bootargs are prepared to boot from USB and to output to serial.
Compatibles for the SoC and board are left out for now.
Signed-off-by: Andreas Färber
---
arch/csky/boot/dts/gx6605s.dts | 104
arch/csky/boot/dts/gx6605s.dtsi | 82 +++
2 files changed, 186 insertions(+)
create mode 100644 arch/csky/boot/dts/gx6605s.dts
create mode 100644 arch/csky/boot/dts/gx6605s.dtsi
diff --git a/arch/csky/boot/dts/gx6605s.dts b/arch/csky/boot/dts/gx6605s.dts
new file mode 100644
index ..f7511024ec6f
--- /dev/null
+++ b/arch/csky/boot/dts/gx6605s.dts
@@ -0,0 +1,104 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause */
+/*
+ * GX6605S dev board
+ *
+ * Copyright (c) 2019 Andreas Färber
+ */
+
+/dts-v1/;
+
+#include
+
+#include "gx6605s.dtsi"
+
+/ {
+ model = "Nationalchip GX6605S";
+
+ aliases {
+ serial0 =
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8 root=/dev/sda2 rw rootwait";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@1000 {
+ device_type = "memory";
+ reg = <0x1000 0x0400>;
+ };
+
+ dummy_apb_clk: dummy-apb-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <2400>; /* guesstimate */
+ #clock-cells = <0>;
+ };
+
+ buttons {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+ autorepeat;
+
+ button5 {
+ label = "button5";
+ linux,code = <103>;
+ gpios = < 5 GPIO_ACTIVE_LOW>;
+ };
+
+ button6 {
+ label = "button6";
+ linux,code = <106>;
+ gpios = < 6 GPIO_ACTIVE_LOW>;
+ };
+
+ button7 {
+ label = "button7";
+ linux,code = <28>;
+ gpios = < 7 GPIO_ACTIVE_LOW>;
+ };
+
+ button8 {
+ label = "button8";
+ linux,code = <105>;
+ gpios = < 8 GPIO_ACTIVE_LOW>;
+ };
+
+ button9 {
+ label = "button9";
+ linux,code = <108>;
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led0 {
+ label = "led10";
+ gpios = < 10 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led1 {
+ label = "led11";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "timer";
+ };
+
+ led2 {
+ label = "led12";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "default-on";
+ };
+
+ led3 {
+ label = "led13";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "default-on";
+ };
+ };
+};
+
+ {
+ clocks = <_apb_clk>;
+};
diff --git a/arch/csky/boot/dts/gx6605s.dtsi b/arch/csky/boot/dts/gx6605s.dtsi
new file mode 100644
index ..956af5674add
--- /dev/null
+++ b/arch/csky/boot/dts/gx6605s.dtsi
@@ -0,0 +1,82 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause */
+/*
+ * NationalChip GX6605S SoC
+ *
+ * Copyright (c) 2019 Andreas Färber
+ */
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "csky,ck610";
+ reg = <0>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ interrupt-parent = <>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ timer0: timer@20a000 {
+ compatible = "csky,gx6605s-timer";
+ reg = <0x0020a000 0x400>;
+ clocks = <_apb_clk>;
+ interrupts = <10>;
+ };
+
+ gpio: gpio@305000 {
+ compatible = "wd,mbl-gpio";
+ reg-names = "dirout", "dat", "set", "clr";
+ reg = <0x00305000 0x4>,
+ <0x00305004 0x4>,
+
Re: [PATCH v5 00/14] epoll: support pollable epoll from userspace
Roman Penyaev wrote: > Hi all, +cc Jason Baron > ** Limitations > 4. No support for EPOLLEXCLUSIVE > If device does not pass pollflags to wake_up() there is no way to > call poll() from the context under spinlock, thus special work is > scheduled to offload polling. In this specific case we can't > support exclusive wakeups, because we do not know actual result > of scheduled work and have to wake up every waiter. Lacking EPOLLEXCLUSIVE support is probably a showstopper for common applications using per-task epoll combined with non-blocking accept4() (e.g. nginx). Fwiw, I'm still a weirdo who prefers a dedicated thread doing blocking accept4 for distribution between tasks (so epoll never sees a listen socket). But, depending on what runtime/language I'm using, I can't always dedicate a blocking thread, so I recently started using EPOLLEXCLUSIVE from Perl5 where I couldn't rely on threads being available. If I could dedicate time to improving epoll; I'd probably add writev() support for batching epoll_ctl modifications to reduce syscall traffic, or pick-up the kevent()-like interface started long ago: https://lore.kernel.org/lkml/1393206162-18151-1-git-send-email-n1ght.4nd@gmail.com/ (but I'm not sure I want to increase the size of the syscall table).
[PATCH] cma: fail if fixed declaration can't be honored
The description of the cma_declare_contiguous() function indicates
that if the 'fixed' argument is true the reserved contiguous area
must be exactly at the address of the 'base' argument.
However, the function currently allows the 'base', 'size', and
'limit' arguments to be silently adjusted to meet alignment
constraints. This commit enforces the documented behavior through
explicit checks that return an error if the region does not fit
within a specified region.
Fixes: 5ea3b1b2f8ad ("cma: add placement specifier for "cma=" kernel parameter")
Signed-off-by: Doug Berger
---
mm/cma.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 3340ef34c154..4973d253dc83 100644
--- a/mm/cma.c
+++ b/mm/cma.c
@@ -278,6 +278,12 @@ int __init cma_declare_contiguous(phys_addr_t base,
*/
alignment = max(alignment, (phys_addr_t)PAGE_SIZE <<
max_t(unsigned long, MAX_ORDER - 1, pageblock_order));
+ if (fixed && base & (alignment - 1)) {
+ ret = -EINVAL;
+ pr_err("Region at %pa must be aligned to %pa bytes\n",
+ , );
+ goto err;
+ }
base = ALIGN(base, alignment);
size = ALIGN(size, alignment);
limit &= ~(alignment - 1);
@@ -308,6 +314,13 @@ int __init cma_declare_contiguous(phys_addr_t base,
if (limit == 0 || limit > memblock_end)
limit = memblock_end;
+ if (base + size > limit) {
+ ret = -EINVAL;
+ pr_err("Size (%pa) of region at %pa exceeds limit (%pa)\n",
+ , , );
+ goto err;
+ }
+
/* Reserve memory */
if (fixed) {
if (memblock_is_region_reserved(base, size) ||
--
2.7.4
