Ath6kl Baytrail SDIO support #322

guylamar2006 · 2016-09-14T16:28:50Z

Added baytrail ID to sdio.c

Add baytrail wifi SDIO ID.

Added Baytrail SDIO ID.

use host_task_stub() for host task

…ch-fixes WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per line) torvalds#21: A) page backing address is free before mmu_notifier_invalidate_range_end() ERROR: code indent should use tabs where possible torvalds#322: FILE: mm/hugetlb.c:3263: +^I ^I^I^I *$ WARNING: please, no space before tabs torvalds#322: FILE: mm/hugetlb.c:3263: +^I ^I^I^I *$ total: 1 errors, 2 warnings, 283 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/mm-mmu_notifier-avoid-double-notification-when-it-is-useless.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Jérôme Glisse <jglisse@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

WARNING: please, no spaces at the start of a line torvalds#250: FILE: kernel/cgroup/cgroup.c:4554: + {$ ERROR: code indent should use tabs where possible torvalds#251: FILE: kernel/cgroup/cgroup.c:4555: + .name = "cpu.pressure",$ WARNING: please, no spaces at the start of a line torvalds#251: FILE: kernel/cgroup/cgroup.c:4555: + .name = "cpu.pressure",$ ERROR: code indent should use tabs where possible torvalds#252: FILE: kernel/cgroup/cgroup.c:4556: + .flags = CFTYPE_NOT_ON_ROOT,$ WARNING: please, no spaces at the start of a line torvalds#252: FILE: kernel/cgroup/cgroup.c:4556: + .flags = CFTYPE_NOT_ON_ROOT,$ ERROR: code indent should use tabs where possible torvalds#253: FILE: kernel/cgroup/cgroup.c:4557: + .seq_show = cgroup_cpu_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#253: FILE: kernel/cgroup/cgroup.c:4557: + .seq_show = cgroup_cpu_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#254: FILE: kernel/cgroup/cgroup.c:4558: + },$ WARNING: please, no spaces at the start of a line torvalds#255: FILE: kernel/cgroup/cgroup.c:4559: + {$ ERROR: code indent should use tabs where possible torvalds#256: FILE: kernel/cgroup/cgroup.c:4560: + .name = "memory.pressure",$ WARNING: please, no spaces at the start of a line torvalds#256: FILE: kernel/cgroup/cgroup.c:4560: + .name = "memory.pressure",$ ERROR: code indent should use tabs where possible torvalds#257: FILE: kernel/cgroup/cgroup.c:4561: + .flags = CFTYPE_NOT_ON_ROOT,$ WARNING: please, no spaces at the start of a line torvalds#257: FILE: kernel/cgroup/cgroup.c:4561: + .flags = CFTYPE_NOT_ON_ROOT,$ ERROR: code indent should use tabs where possible torvalds#258: FILE: kernel/cgroup/cgroup.c:4562: + .seq_show = cgroup_memory_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#258: FILE: kernel/cgroup/cgroup.c:4562: + .seq_show = cgroup_memory_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#259: FILE: kernel/cgroup/cgroup.c:4563: + },$ WARNING: please, no spaces at the start of a line torvalds#260: FILE: kernel/cgroup/cgroup.c:4564: + {$ ERROR: code indent should use tabs where possible torvalds#261: FILE: kernel/cgroup/cgroup.c:4565: + .name = "io.pressure",$ WARNING: please, no spaces at the start of a line torvalds#261: FILE: kernel/cgroup/cgroup.c:4565: + .name = "io.pressure",$ ERROR: code indent should use tabs where possible torvalds#262: FILE: kernel/cgroup/cgroup.c:4566: + .flags = CFTYPE_NOT_ON_ROOT,$ WARNING: please, no spaces at the start of a line torvalds#262: FILE: kernel/cgroup/cgroup.c:4566: + .flags = CFTYPE_NOT_ON_ROOT,$ ERROR: code indent should use tabs where possible torvalds#263: FILE: kernel/cgroup/cgroup.c:4567: + .seq_show = cgroup_io_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#263: FILE: kernel/cgroup/cgroup.c:4567: + .seq_show = cgroup_io_pressure_show,$ WARNING: please, no spaces at the start of a line torvalds#264: FILE: kernel/cgroup/cgroup.c:4568: + },$ WARNING: please, no spaces at the start of a line torvalds#322: FILE: kernel/sched/psi.c:424: + cgroup = task->cgroups->dfl_cgrp;$ WARNING: please, no spaces at the start of a line torvalds#323: FILE: kernel/sched/psi.c:425: + while (cgroup && (parent = cgroup_parent(cgroup))) {$ WARNING: suspect code indent for conditional statements (7, 15) torvalds#323: FILE: kernel/sched/psi.c:425: + while (cgroup && (parent = cgroup_parent(cgroup))) { + struct psi_group *group; ERROR: code indent should use tabs where possible torvalds#324: FILE: kernel/sched/psi.c:426: + struct psi_group *group;$ WARNING: please, no spaces at the start of a line torvalds#324: FILE: kernel/sched/psi.c:426: + struct psi_group *group;$ ERROR: code indent should use tabs where possible torvalds#326: FILE: kernel/sched/psi.c:428: + group = cgroup_psi(cgroup);$ WARNING: please, no spaces at the start of a line torvalds#326: FILE: kernel/sched/psi.c:428: + group = cgroup_psi(cgroup);$ ERROR: code indent should use tabs where possible torvalds#327: FILE: kernel/sched/psi.c:429: + psi_group_change(group, cpu, now, clear, set);$ WARNING: please, no spaces at the start of a line torvalds#327: FILE: kernel/sched/psi.c:429: + psi_group_change(group, cpu, now, clear, set);$ ERROR: code indent should use tabs where possible torvalds#329: FILE: kernel/sched/psi.c:431: + cgroup = parent;$ WARNING: please, no spaces at the start of a line torvalds#329: FILE: kernel/sched/psi.c:431: + cgroup = parent;$ WARNING: please, no spaces at the start of a line torvalds#330: FILE: kernel/sched/psi.c:432: + }$ WARNING: braces {} are not necessary for any arm of this statement torvalds#378: FILE: kernel/sched/psi.c:537: + if (task_on_rq_queued(task)) { [...] + } else if (task->in_iowait) { [...] total: 13 errors, 24 warnings, 334 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. NOTE: Whitespace errors detected. You may wish to use scripts/cleanpatch or scripts/cleanfile ./patches/psi-cgroup-support.patch has style problems, please review. NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. Please run checkpatch prior to sending patches Cc: Johannes Weiner <jweiner@fb.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>

…inter In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c torvalds#322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b8 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: John Garry <john.garry@huawei.com>

…inter In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c torvalds#322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b8 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: John Garry <john.garry@huawei.com> Reviewed-by: Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by: Xinliang Liu <z.liuxinliang@hisilicon.com>

…inter [ Upstream commit 331d880 ] In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c #322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b8 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: John Garry <john.garry@huawei.com> Reviewed-by: Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by: Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…inter BugLink: http://bugs.launchpad.net/bugs/1810821 [ Upstream commit 331d880 ] In hibmc_drm_fb_create(), when the call to hibmc_framebuffer_init() fails with error, do not store the error code in the HiBMC device frame-buffer pointer, as this will be later checked for non-zero value in hibmc_fbdev_destroy() when our intention is to check for a valid function pointer. This fixes the following crash: [ 9.699791] Unable to handle kernel NULL pointer dereference at virtual address 000000000000001a [ 9.708672] Mem abort info: [ 9.711489] ESR = 0x96000004 [ 9.714570] Exception class = DABT (current EL), IL = 32 bits [ 9.720551] SET = 0, FnV = 0 [ 9.723631] EA = 0, S1PTW = 0 [ 9.726799] Data abort info: [ 9.729702] ISV = 0, ISS = 0x00000004 [ 9.733573] CM = 0, WnR = 0 [ 9.736566] [000000000000001a] user address but active_mm is swapper [ 9.742987] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 9.748614] Modules linked in: [ 9.751694] CPU: 16 PID: 293 Comm: kworker/16:1 Tainted: G W 4.19.0-rc4-next-20180920-00001-g9b0012c torvalds#322 [ 9.762681] Hardware name: Huawei Taishan 2280 /D05, BIOS Hisilicon D05 IT21 Nemo 2.0 RC0 04/18/2018 [ 9.771915] Workqueue: events work_for_cpu_fn [ 9.776312] pstate: 60000005 (nZCv daif -PAN -UAO) [ 9.781150] pc : drm_mode_object_put+0x0/0x20 [ 9.785547] lr : hibmc_fbdev_fini+0x40/0x58 [ 9.789767] sp : ffff00000af1bcf0 [ 9.793108] x29: ffff00000af1bcf0 x28: 0000000000000000 [ 9.798473] x27: 0000000000000000 x26: ffff000008f66630 [ 9.803838] x25: 0000000000000000 x24: ffff0000095abb98 [ 9.809203] x23: ffff8017db92fe00 x22: ffff8017d2b13000 [ 9.814568] x21: ffffffffffffffea x20: ffff8017d2f80018 [ 9.819933] x19: ffff8017d28a0018 x18: ffffffffffffffff [ 9.825297] x17: 0000000000000000 x16: 0000000000000000 [ 9.830662] x15: ffff0000092296c8 x14: ffff00008939970f [ 9.836026] x13: ffff00000939971d x12: ffff000009229940 [ 9.841391] x11: ffff0000085f8fc0 x10: ffff00000af1b9a0 [ 9.846756] x9 : 000000000000000d x8 : 6620657a696c6169 [ 9.852121] x7 : ffff8017d3340580 x6 : ffff8017d4168000 [ 9.857486] x5 : 0000000000000000 x4 : ffff8017db92fb20 [ 9.862850] x3 : 0000000000002690 x2 : ffff8017d3340480 [ 9.868214] x1 : 0000000000000028 x0 : 0000000000000002 [ 9.873580] Process kworker/16:1 (pid: 293, stack limit = 0x(____ptrval____)) [ 9.880788] Call trace: [ 9.883252] drm_mode_object_put+0x0/0x20 [ 9.887297] hibmc_unload+0x1c/0x80 [ 9.890815] hibmc_pci_probe+0x170/0x3c8 [ 9.894773] local_pci_probe+0x3c/0xb0 [ 9.898555] work_for_cpu_fn+0x18/0x28 [ 9.902337] process_one_work+0x1e0/0x318 [ 9.906382] worker_thread+0x228/0x450 [ 9.910164] kthread+0x128/0x130 [ 9.913418] ret_from_fork+0x10/0x18 [ 9.917024] Code: a94153f3 a8c27bfd d65f03c0 d503201f (f9400c01) [ 9.923180] ---[ end trace 2695ffa0af5be375 ]--- Fixes: d1667b8 ("drm/hisilicon/hibmc: Add support for frame buffer") Signed-off-by: John Garry <john.garry@huawei.com> Reviewed-by: Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by: Xinliang Liu <z.liuxinliang@hisilicon.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>

Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <daniel@gaisler.com>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <kristoffer@gaisler.com>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <info@metux.net>

Current code doesn't limit the number of nested devices. Nested devices would be handled recursively and this needs huge stack memory. So, unlimited nested devices could make stack overflow. This patch adds upper_level and lower_leve, they are common variables and represent maximum lower/upper depth. When upper/lower device is attached or dettached, {lower/upper}_level are updated. and if maximum depth is bigger than 8, attach routine fails and returns -EMLINK. Test commands: ip link add dummy0 type dummy ip link add link dummy0 name vlan1 type vlan id 1 ip link set vlan1 up for i in {2..100} do let A=$i-1 ip link add name vlan$i link vlan$A type vlan id $i done Splat looks like: [ 140.483124] BUG: looking up invalid subclass: 8 [ 140.483505] turning off the locking correctness validator. [ 140.483505] CPU: 0 PID: 1324 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 140.483505] Hardware name: To be filled by O.E.M. To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/08/2015 [ 140.483505] Call Trace: [ 140.483505] dump_stack+0x7c/0xbb [ 140.483505] register_lock_class+0x64d/0x14d0 [ 140.483505] ? is_dynamic_key+0x230/0x230 [ 140.483505] ? module_assert_mutex_or_preempt+0x41/0x70 [ 140.483505] ? __module_address+0x3f/0x3c0 [ 140.483505] lockdep_init_map+0x24e/0x630 [ 140.483505] vlan_dev_init+0x828/0xce0 [8021q] [ 140.483505] register_netdevice+0x24f/0xd70 [ 140.483505] ? netdev_change_features+0xa0/0xa0 [ 140.483505] ? dev_get_nest_level+0xe1/0x170 [ 140.483505] register_vlan_dev+0x29b/0x710 [8021q] [ 140.483505] __rtnl_newlink+0xb75/0x1180 [ ... ] [ 168.446539] WARNING: can't dereference registers at 00000000bef3d701 for ip apic_timer_interrupt+0xf/0x20 [ 168.466843] ================================================================== [ 168.469452] BUG: KASAN: slab-out-of-bounds in __unwind_start+0x71/0x850 [ 168.480707] Write of size 88 at addr ffff8880b8856d38 by task ip/1758 [ 168.480707] [ 168.480707] CPU: 1 PID: 1758 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ ... ] [ 168.794493] Rebooting in 5 seconds.. Signed-off-by: Taehee Yoo <ap420073@gmail.com>

All VLAN device has same lockdep key and subclass is initialized with nest_level. But actual nest_level value can be changed when a lower device is attached. And at this moment, the subclass should be updated but it seems to be unsafe. So this patch makes VLAN use dynamic lockdep key instead of the subclass. Test commands: ip link add dummy0 type dummy ip link set dummy0 up ip link add bond0 type bond ip link add vlan_dummy1 link dummy0 type vlan id 1 ip link add vlan_bond1 link bond0 type vlan id 2 ip link set vlan_dummy1 master bond0 ip link set bond0 up ip link set vlan_dummy1 up ip link set vlan_bond1 up Both vlan_dummy1 and vlan_bond1 have the same subclass and it makes unnecessary deadlock warning message. Splat looks like: [ 149.244978] ============================================ [ 149.244978] WARNING: possible recursive locking detected [ 149.244978] 5.3.0-rc7+ torvalds#322 Not tainted [ 149.244978] -------------------------------------------- [ 149.244978] ip/1340 is trying to acquire lock: [ 149.244978] 000000001399b1a7 (&vlan_netdev_addr_lock_key/1){+...}, at: dev_uc_sync_multiple+0xfa/0x1a0 [ 149.279600] [ 149.279600] but task is already holding lock: [ 149.279600] 00000000b963d9b4 (&vlan_netdev_addr_lock_key/1){+...}, at: dev_set_rx_mode+0x19/0x30 [ 149.279600] [ 149.279600] other info that might help us debug this: [ 149.305981] Possible unsafe locking scenario: [ 149.305981] [ 149.305981] CPU0 [ 149.305981] ---- [ 149.305981] lock(&vlan_netdev_addr_lock_key/1); [ 149.305981] lock(&vlan_netdev_addr_lock_key/1); [ 149.326258] [ 149.326258] *** DEADLOCK *** [ 149.326258] [ 149.326258] May be due to missing lock nesting notation [ 149.326258] [ 149.326258] 4 locks held by ip/1340: [ 149.326258] #0: 00000000927f0698 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0 [ 149.326258] #1: 00000000b963d9b4 (&vlan_netdev_addr_lock_key/1){+...}, at: dev_set_rx_mode+0x19/0x30 [ 149.326258] #2: 0000000027395445 (&dev_addr_list_lock_key/3){+...}, at: dev_mc_sync+0xfa/0x1a0 [ 149.369961] #3: 00000000ce334932 (rcu_read_lock){....}, at: bond_set_rx_mode+0x5/0x3c0 [bonding] [ 149.369961] [ 149.369961] stack backtrace: [ 149.369961] CPU: 1 PID: 1340 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 149.369961] Call Trace: [ 149.369961] dump_stack+0x7c/0xbb [ 149.369961] __lock_acquire+0x26a9/0x3de0 [ 149.369961] ? register_lock_class+0x14d0/0x14d0 [ 149.369961] ? register_lock_class+0x14d0/0x14d0 [ 149.369961] lock_acquire+0x164/0x3b0 [ 149.433970] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 149.433970] _raw_spin_lock_nested+0x2e/0x60 [ 149.433970] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 149.433970] dev_uc_sync_multiple+0xfa/0x1a0 [ 149.433970] bond_set_rx_mode+0x269/0x3c0 [bonding] [ 149.433970] ? bond_init+0x6f0/0x6f0 [bonding] [ 149.433970] dev_mc_sync+0x15a/0x1a0 [ 149.433970] vlan_dev_set_rx_mode+0x37/0x80 [8021q] [ 149.433970] dev_set_rx_mode+0x21/0x30 [ 149.433970] __dev_open+0x202/0x310 [ 149.433970] ? dev_set_rx_mode+0x30/0x30 [ 149.433970] ? mark_held_locks+0xa5/0xe0 [ 149.433970] ? __local_bh_enable_ip+0xe9/0x1b0 [ 149.433970] __dev_change_flags+0x3c3/0x500 [ ... ] Fixes: 0fe1e56 ("[VLAN]: nested VLAN: fix lockdep's recursive locking warning") Signed-off-by: Taehee Yoo <ap420073@gmail.com>

The IFF_BONDING means bonding master or bonding slave device. ->ndo_add_slave() sets IFF_BONDING flag and ->ndo_del_slave() removes IFF_BONDING flag. This routine makes a problem in the nesting bonding structure. bond1<--bond2 Both bond0 and bond1 are bonding device and these should keep having IFF_BONDING flag until they are removed. But bond1 would lose IFF_BONDING at ->ndo_del_slave because that routine can not check whether the slave device is the bonding type or not. So that this patch splits the IFF_BONDING into theIFF_BONDING and the IFF_BONDING_SLAVE. The IFF_BONDING is bonding master flag and IFF_BONDING_SLAVE is bonding slave flag. Test commands: ip link add bond0 type bond ip link add bond1 type bond ip link set bond1 master bond0 ip link set bond1 nomaster ip link del bond1 type bond ip link add bond1 type bond Splat looks like: [ 149.201107] proc_dir_entry 'bonding/bond1' already registered [ 149.208013] WARNING: CPU: 1 PID: 1308 at fs/proc/generic.c:361 proc_register+0x2a9/0x3e0 [ 149.208866] Modules linked in: bonding veth openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv4 ip_tables6 [ 149.208866] CPU: 1 PID: 1308 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 149.208866] RIP: 0010:proc_register+0x2a9/0x3e0 [ 149.208866] Code: 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 39 01 00 00 48 8b 04 24 48 89 ea 48 c7 c7 a0 a0 13 89 48 8b b0 0 [ 149.208866] RSP: 0018:ffff88810df9f098 EFLAGS: 00010286 [ 149.208866] RAX: dffffc0000000008 RBX: ffff8880b5d3aa50 RCX: ffffffff87cdec92 [ 149.208866] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff888116bf6a8c [ 149.208866] RBP: ffff8880b5d3acd3 R08: ffffed1022d7ff71 R09: ffffed1022d7ff71 [ 149.208866] R10: 0000000000000001 R11: ffffed1022d7ff70 R12: ffff8880b5d3abe8 [ 149.208866] R13: ffff8880b5d3acd2 R14: dffffc0000000000 R15: ffffed1016ba759a [ 149.208866] FS: 00007f4bd1f650c0(0000) GS:ffff888116a00000(0000) knlGS:0000000000000000 [ 149.208866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 149.208866] CR2: 000055e7ca686118 CR3: 0000000106fd4000 CR4: 00000000001006e0 [ 149.208866] Call Trace: [ 149.208866] proc_create_seq_private+0xb3/0xf0 [ 149.208866] bond_create_proc_entry+0x1b3/0x3f0 [bonding] [ 149.208866] bond_netdev_event+0x433/0x970 [bonding] [ 149.208866] ? __module_text_address+0x13/0x140 [ 149.208866] notifier_call_chain+0x90/0x160 [ 149.208866] register_netdevice+0x9b3/0xd70 [ 149.208866] ? alloc_netdev_mqs+0x854/0xc10 [ 149.208866] ? netdev_change_features+0xa0/0xa0 [ 149.208866] ? rtnl_create_link+0x2ed/0xad0 [ 149.208866] bond_newlink+0x2a/0x60 [bonding] [ 149.208866] __rtnl_newlink+0xb75/0x1180 [ ... ] Fixes: 0b680e7 ("[PATCH] bonding: Add priv_flag to avoid event mishandling") Signed-off-by: Taehee Yoo <ap420073@gmail.com>

All bonding device has same lockdep key and subclass is initialized with nest_level. But actual nest_level value can be changed when a lower device is attached. And at this moment, the subclass should be updated but it seems to be unsafe. So this patch makes bonding use dynamic lockdep key instead of the subclass. Test commands: ip link add bond0 type bond for i in {1..5} do let A=$i-1 ip link add bond$i type bond ip link set bond$i master bond$A done ip link set bond5 master bond0 Splat looks like: [ 327.477830] ============================================ [ 327.477830] WARNING: possible recursive locking detected [ 327.477830] 5.3.0-rc7+ torvalds#322 Not tainted [ 327.477830] -------------------------------------------- [ 327.477830] ip/1399 is trying to acquire lock: [ 327.477830] 00000000f604be63 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding] [ 327.477830] [ 327.477830] but task is already holding lock: [ 327.477830] 00000000e9d31238 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding] [ 327.477830] [ 327.477830] other info that might help us debug this: [ 327.477830] Possible unsafe locking scenario: [ 327.477830] [ 327.477830] CPU0 [ 327.477830] ---- [ 327.477830] lock(&(&bond->stats_lock)->rlock#2/2); [ 327.477830] lock(&(&bond->stats_lock)->rlock#2/2); [ 327.477830] [ 327.477830] *** DEADLOCK *** [ 327.477830] [ 327.477830] May be due to missing lock nesting notation [ 327.477830] [ 327.477830] 3 locks held by ip/1399: [ 327.477830] #0: 00000000a762c4e3 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0 [ 327.477830] #1: 00000000e9d31238 (&(&bond->stats_lock)->rlock#2/2){+.+.}, at: bond_get_stats+0xb8/0x500 [bonding] [ 327.477830] #2: 000000008f7ebff4 (rcu_read_lock){....}, at: bond_get_stats+0x9f/0x500 [bonding] [ 327.477830] [ 327.477830] stack backtrace: [ 327.477830] CPU: 0 PID: 1399 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 327.477830] Call Trace: [ 327.477830] dump_stack+0x7c/0xbb [ 327.477830] __lock_acquire+0x26a9/0x3de0 [ 327.477830] ? __change_page_attr_set_clr+0x133b/0x1d20 [ 327.477830] ? register_lock_class+0x14d0/0x14d0 [ 327.477830] lock_acquire+0x164/0x3b0 [ 327.477830] ? bond_get_stats+0xb8/0x500 [bonding] [ 327.666914] _raw_spin_lock_nested+0x2e/0x60 [ 327.666914] ? bond_get_stats+0xb8/0x500 [bonding] [ 327.678302] bond_get_stats+0xb8/0x500 [bonding] [ 327.678302] ? bond_arp_rcv+0xf10/0xf10 [bonding] [ 327.678302] ? register_lock_class+0x14d0/0x14d0 [ 327.678302] ? bond_get_stats+0xb8/0x500 [bonding] [ 327.678302] dev_get_stats+0x1ec/0x270 [ 327.678302] bond_get_stats+0x1d1/0x500 [bonding] [ 327.678302] ? lock_acquire+0x164/0x3b0 [ 327.678302] ? bond_arp_rcv+0xf10/0xf10 [bonding] [ 327.678302] ? rtnl_is_locked+0x16/0x30 [ 327.678302] ? devlink_compat_switch_id_get+0x18/0x140 [ 327.678302] ? dev_get_alias+0xe2/0x190 [ 327.731145] ? dev_get_port_parent_id+0x12a/0x340 [ 327.731145] ? rtnl_phys_switch_id_fill+0x88/0xe0 [ 327.731145] dev_get_stats+0x1ec/0x270 [ 327.731145] rtnl_fill_stats+0x44/0xbe0 [ 327.731145] ? nla_put+0xc2/0x140 [ ... ] Fixes: d3fff6c ("net: add netdev_lockdep_set_classes() helper") Signed-off-by: Taehee Yoo <ap420073@gmail.com>

In the current code, all team devices have same static lockdep key and team devices could be nested so that it makes unnecessary lockdep warning. Test commands: ip link add team0 type team for i in {1..7} do let A=$i-1 ip link add team$i type team ip link set team$i master team$A done ip link del team0 Splat looks like: [ 137.406730] ============================================ [ 137.412685] WARNING: possible recursive locking detected [ 137.418642] 5.3.0-rc7+ torvalds#322 Not tainted [ 137.422941] -------------------------------------------- [ 137.428886] ip/1383 is trying to acquire lock: [ 137.433869] 0000000089571080 (&dev_addr_list_lock_key/1){+...}, at: dev_uc_sync_multiple+0xfa/0x1a0 [ 137.444034] [ 137.444034] but task is already holding lock: [ 137.450572] 00000000d9597252 (&dev_addr_list_lock_key/1){+...}, at: dev_uc_unsync+0x10c/0x1b0 [ 137.460142] [ 137.460142] other info that might help us debug this: [ 137.467458] Possible unsafe locking scenario: [ 137.467458] [ 137.474096] CPU0 [ 137.476828] ---- [ 137.479569] lock(&dev_addr_list_lock_key/1); [ 137.484554] lock(&dev_addr_list_lock_key/1); [ 137.489539] [ 137.489539] *** DEADLOCK *** [ 137.489539] [ 137.496178] May be due to missing lock nesting notation [ 137.496178] [ 137.503789] 5 locks held by ip/1383: [ 137.507797] #0: 00000000d497f415 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0 [ 137.516786] #1: 000000008e4b4656 (&team->lock){+.+.}, at: team_uninit+0x3a/0x1a0 [team] [ 137.525882] #2: 000000005cf248d1 (&dev_addr_list_lock_key){+...}, at: dev_uc_unsync+0x98/0x1b0 [ 137.535649] #3: 00000000d9597252 (&dev_addr_list_lock_key/1){+...}, at: dev_uc_unsync+0x10c/0x1b0 [ 137.545709] #4: 00000000bec134c3 (rcu_read_lock){....}, at: team_set_rx_mode+0x5/0x1d0 [team] [ 137.555384] [ 137.555384] stack backtrace: [ 137.560277] CPU: 0 PID: 1383 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 137.577826] Call Trace: [ 137.580586] dump_stack+0x7c/0xbb [ 137.584307] __lock_acquire+0x26a9/0x3de0 [ 137.588820] ? register_lock_class+0x14d0/0x14d0 [ 137.594008] ? register_lock_class+0x14d0/0x14d0 [ 137.599194] lock_acquire+0x164/0x3b0 [ 137.603310] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 137.608307] _raw_spin_lock_nested+0x2e/0x60 [ 137.613105] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 137.618095] dev_uc_sync_multiple+0xfa/0x1a0 [ 137.622900] team_set_rx_mode+0xa9/0x1d0 [team] [ 137.627993] dev_uc_unsync+0x151/0x1b0 [ 137.632205] team_port_del+0x304/0x790 [team] [ 137.637110] team_uninit+0xb0/0x1a0 [team] [ 137.641717] rollback_registered_many+0x728/0xda0 [ 137.647005] ? generic_xdp_install+0x310/0x310 [ 137.651994] ? __set_pages_p+0xf4/0x150 [ 137.656306] ? check_chain_key+0x236/0x5d0 [ 137.660914] ? __nla_validate_parse+0x98/0x1ad0 [ 137.666006] unregister_netdevice_many.part.120+0x13/0x1b0 [ 137.672167] rtnl_delete_link+0xbc/0x100 [ 137.676575] ? rtnl_af_register+0xc0/0xc0 [ 137.681084] rtnl_dellink+0x2e7/0x870 [ 137.685204] ? find_held_lock+0x39/0x1d0 [ ... ] Fixes: 3d249d4 ("net: introduce ethernet teaming device") Signed-off-by: Taehee Yoo <ap420073@gmail.com>

All macsec device has same lockdep key and subclass is initialized with nest_level. But actual nest_level value can be changed when a lower device is attached. And at this moment, the subclass should be updated but it seems to be unsafe. So this patch makes macsec use dynamic lockdep key instead of the subclass. Test commands: ip link add bond0 type bond ip link add dummy0 type dummy ip link add macsec0 link bond0 type macsec ip link add macsec1 link dummy0 type macsec ip link set bond0 mtu 1000 ip link set macsec1 master bond0 ip link set bond0 up ip link set macsec0 up ip link set dummy0 up ip link set macsec1 up Splat looks like: [ 146.540123] ============================================ [ 146.540123] WARNING: possible recursive locking detected [ 146.540123] 5.3.0-rc7+ torvalds#322 Not tainted [ 146.540123] -------------------------------------------- [ 146.540123] ip/1340 is trying to acquire lock: [ 146.540123] 00000000446fd8bd (&macsec_netdev_addr_lock_key/1){+...}, at: dev_uc_sync_multiple+0xfa/0x1a0 [ 146.540123] [ 146.540123] but task is already holding lock: [ 146.540123] 00000000a9ab6378 (&macsec_netdev_addr_lock_key/1){+...}, at: dev_set_rx_mode+0x19/0x30 [ 146.540123] [ 146.540123] other info that might help us debug this: [ 146.540123] Possible unsafe locking scenario: [ 146.540123] [ 146.540123] CPU0 [ 146.540123] ---- [ 146.540123] lock(&macsec_netdev_addr_lock_key/1); [ 146.540123] lock(&macsec_netdev_addr_lock_key/1); [ 146.623155] [ 146.623155] *** DEADLOCK *** [ 146.623155] [ 146.623155] May be due to missing lock nesting notation [ 146.623155] [ 146.623155] 4 locks held by ip/1340: [ 146.623155] #0: 0000000026436ef0 (rtnl_mutex){+.+.}, at: rtnetlink_rcv_msg+0x466/0x8a0 [ 146.623155] #1: 00000000a9ab6378 (&macsec_netdev_addr_lock_key/1){+...}, at: dev_set_rx_mode+0x19/0x30 [ 146.623155] #2: 00000000a8947dd0 (&dev_addr_list_lock_key/3){+...}, at: dev_mc_sync+0xfa/0x1a0 [ 146.623155] #3: 00000000b62011e9 (rcu_read_lock){....}, at: bond_set_rx_mode+0x5/0x3c0 [bonding] [ 146.674970] [ 146.674970] stack backtrace: [ 146.687145] CPU: 0 PID: 1340 Comm: ip Not tainted 5.3.0-rc7+ torvalds#322 [ 146.693024] Call Trace: [ 146.693024] dump_stack+0x7c/0xbb [ 146.693024] __lock_acquire+0x26a9/0x3de0 [ 146.693024] ? register_lock_class+0x14d0/0x14d0 [ 146.693024] ? register_lock_class+0x14d0/0x14d0 [ 146.693024] lock_acquire+0x164/0x3b0 [ 146.693024] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 146.693024] _raw_spin_lock_nested+0x2e/0x60 [ 146.693024] ? dev_uc_sync_multiple+0xfa/0x1a0 [ 146.693024] dev_uc_sync_multiple+0xfa/0x1a0 [ 146.693024] bond_set_rx_mode+0x269/0x3c0 [bonding] [ 146.751163] ? bond_init+0x6f0/0x6f0 [bonding] [ 146.757006] ? do_raw_spin_trylock+0xa9/0x170 [ 146.757006] dev_mc_sync+0x15a/0x1a0 [ 146.757006] macsec_dev_set_rx_mode+0x3a/0x50 [macsec] [ 146.757006] dev_set_rx_mode+0x21/0x30 [ 146.757006] __dev_open+0x202/0x310 [ 146.757006] ? dev_set_rx_mode+0x30/0x30 [ 146.757006] ? mark_held_locks+0xa5/0xe0 [ 146.757006] ? __local_bh_enable_ip+0xe9/0x1b0 [ 146.757006] __dev_change_flags+0x3c3/0x500 [ 146.757006] ? dev_set_allmulti+0x10/0x10 [ 146.757006] ? sched_clock_local+0xd4/0x140 [ 146.757006] ? check_chain_key+0x236/0x5d0 [ 146.757006] dev_change_flags+0x7a/0x160 [ 146.757006] do_setlink+0xa26/0x2f20 [ 146.757006] ? sched_clock_local+0xd4/0x140 [ ... ] Fixes: e200387 ("macsec: fix lockdep splats when nesting devices") Signed-off-by: Taehee Yoo <ap420073@gmail.com>

Fix checkpatch warnings: WARNING: line over 80 characters torvalds#9: FILE: drivers/tty/serial/apbuart.c:9: + * Copyright (C) 2006 Daniel Hellstrom <daniel@gaisler.com>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#11: FILE: drivers/tty/serial/apbuart.c:11: + * Copyright (C) 2009 Kristoffer Glembo <kristoffer@gaisler.com>, Aeroflex Gaisler AB WARNING: line over 80 characters torvalds#16: FILE: drivers/tty/serial/apbuart.c:16: +#if defined(CONFIG_SERIAL_GRLIB_GAISLER_APBUART_CONSOLE) && defined(CONFIG_MAGIC_SYSRQ) WARNING: labels should not be indented torvalds#122: FILE: drivers/tty/serial/apbuart.c:122: + ignore_char: WARNING: Missing a blank line after declarations torvalds#186: FILE: drivers/tty/serial/apbuart.c:186: + unsigned int status = UART_GET_STATUS(port); + return status & UART_STATUS_THE ? TIOCSER_TEMT : 0; WARNING: Missing a blank line after declarations torvalds#322: FILE: drivers/tty/serial/apbuart.c:322: + int ret = 0; + if (ser->type != PORT_UNKNOWN && ser->type != PORT_APBUART) WARNING: Missing a blank line after declarations torvalds#427: FILE: drivers/tty/serial/apbuart.c:427: + unsigned int status; + do { WARNING: Missing a blank line after declarations torvalds#463: FILE: drivers/tty/serial/apbuart.c:463: + unsigned int quot, status; + status = UART_GET_STATUS(port); WARNING: line over 80 characters torvalds#627: FILE: drivers/tty/serial/apbuart.c:627: + port->membase = ioremap(addr, sizeof(struct grlib_apbuart_regs_map)); WARNING: line over 80 characters torvalds#634: FILE: drivers/tty/serial/apbuart.c:634: + port->fifosize = apbuart_scan_fifo_size((struct uart_port *) port, line); Signed-off-by: Enrico Weigelt <info@metux.net>

…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Lokendra Singh <lokendra.singh@intel.com>

…format For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Lokendra Singh <lokendra.singh@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

…format [ Upstream commit 06d213d ] For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 torvalds#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Lokendra Singh <lokendra.singh@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

…format [ Upstream commit 06d213d ] For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 #309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 #311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 #312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 #314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 #325 [hci0] 49.500311 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Lokendra Singh <lokendra.singh@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

…format [ Upstream commit 06d213d ] For incoming SCO connection with transparent coding format, alt setting of CVSD is getting applied instead of Transparent. Before fix: < HCI Command: Accept Synchron.. (0x01|0x0029) plen 21 #2196 [hci0] 321.342548 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 #2197 [hci0] 321.343585 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Comp.. (0x2c) plen 17 #2198 [hci0] 321.351666 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) ........ > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2336 [hci0] 321.383655 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2337 [hci0] 321.389558 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2338 [hci0] 321.393615 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2339 [hci0] 321.393618 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2340 [hci0] 321.393618 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2341 [hci0] 321.397070 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2342 [hci0] 321.403622 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2343 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2344 [hci0] 321.403625 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2345 [hci0] 321.403625 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2346 [hci0] 321.404569 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2347 [hci0] 321.412091 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2348 [hci0] 321.413626 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2349 [hci0] 321.413630 > SCO Data RX: Handle 257 flags 0x00 dlen 48 #2350 [hci0] 321.413630 < SCO Data TX: Handle 257 flags 0x00 dlen 60 #2351 [hci0] 321.419674 After fix: < HCI Command: Accept Synchronou.. (0x01|0x0029) plen 21 linux-sunxi#309 [hci0] 49.439693 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Transmit bandwidth: 8000 Receive bandwidth: 8000 Max latency: 13 Setting: 0x0003 Input Coding: Linear Input Data Format: 1's complement Input Sample Size: 8-bit # of bits padding at MSB: 0 Air Coding Format: Transparent Data Retransmission effort: Optimize for link quality (0x02) Packet type: 0x003f HV1 may be used HV2 may be used HV3 may be used EV3 may be used EV4 may be used EV5 may be used > HCI Event: Command Status (0x0f) plen 4 torvalds#310 [hci0] 49.440308 Accept Synchronous Connection Request (0x01|0x0029) ncmd 1 Status: Success (0x00) > HCI Event: Synchronous Connect Complete (0x2c) plen 17 torvalds#311 [hci0] 49.449308 Status: Success (0x00) Handle: 257 Address: 1C:CC:D6:E2:EA:80 (Xiaomi Communications Co Ltd) Link type: eSCO (0x02) Transmission interval: 0x0c Retransmission window: 0x04 RX packet length: 60 TX packet length: 60 Air mode: Transparent (0x03) < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#312 [hci0] 49.450421 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#313 [hci0] 49.457927 > HCI Event: Max Slots Change (0x1b) plen 3 torvalds#314 [hci0] 49.460345 Handle: 256 Max slots: 5 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#315 [hci0] 49.465453 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#316 [hci0] 49.470502 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#317 [hci0] 49.470519 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#318 [hci0] 49.472996 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#319 [hci0] 49.480412 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#320 [hci0] 49.480492 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#321 [hci0] 49.487989 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#322 [hci0] 49.490303 < SCO Data TX: Handle 257 flags 0x00 dlen 60 torvalds#323 [hci0] 49.495496 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#324 [hci0] 49.500304 > SCO Data RX: Handle 257 flags 0x00 dlen 60 torvalds#325 [hci0] 49.500311 Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Lokendra Singh <lokendra.singh@intel.com> Signed-off-by: Marcel Holtmann <marcel@holtmann.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

Implement a `#[vtable]` macro

The gadget may change over bind/unbind cycles, so set it each time during bind, not only the first time. Without it we get a use-after-free with the following example: cd /sys/kernel/config/usb_gadget/; mkdir -p mygadget; cd mygadget mkdir -p configs/c.1/strings/0x409 echo "C1:Composite Device" > configs/c.1/strings/0x409/configuration mkdir -p functions/ecm.usb0 ln -s functions/ecm.usb0 configs/c.1/ rmmod dummy_hcd modprobe dummy_hcd KASAN will complain shortly after the 'modprobe': usb 2-1: New USB device found, idVendor=0000, idProduct=0000, bcdDevice= 6.01 usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 ================================================================== BUG: KASAN: use-after-free in gether_connect+0xb8/0x30c Read of size 4 at addr cbef170c by task swapper/3/0 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.0-rc3-00014-g41ff012f50cb-dirty torvalds#322 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from print_report+0x134/0x4d4 print_report from kasan_report+0x78/0x10c kasan_report from gether_connect+0xb8/0x30c gether_connect from ecm_set_alt+0x124/0x254 ecm_set_alt from composite_setup+0xb98/0x2b18 composite_setup from configfs_composite_setup+0x80/0x98 configfs_composite_setup from dummy_timer+0x8f0/0x14a0 [dummy_hcd] ... Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

The gadget may change over bind/unbind cycles, so set it each time during bind, not only the first time. Without it we get a use-after-free with the following example: cd /sys/kernel/config/usb_gadget/; mkdir -p mygadget; cd mygadget mkdir -p configs/c.1/strings/0x409 echo "C1:Composite Device" > configs/c.1/strings/0x409/configuration mkdir -p functions/ecm.usb0 ln -s functions/ecm.usb0 configs/c.1/ rmmod dummy_hcd modprobe dummy_hcd KASAN will complain shortly after the 'modprobe': usb 2-1: New USB device found, idVendor=0000, idProduct=0000, bcdDevice= 6.01 usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 ================================================================== BUG: KASAN: use-after-free in gether_connect+0xb8/0x30c Read of size 4 at addr cbef170c by task swapper/3/0 CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.1.0-rc3-00014-g41ff012f50cb-dirty torvalds#322 Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from print_report+0x134/0x4d4 print_report from kasan_report+0x78/0x10c kasan_report from gether_connect+0xb8/0x30c gether_connect from ecm_set_alt+0x124/0x254 ecm_set_alt from composite_setup+0xb98/0x2b18 composite_setup from configfs_composite_setup+0x80/0x98 configfs_composite_setup from dummy_timer+0x8f0/0x14a0 [dummy_hcd] ... Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://lore.kernel.org/r/20221104131031.850850-3-s.hauer@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <chao@kernel.org>

With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>

[ Upstream commit c5d3f9b ] With below mount option and testcase, it hangs kernel. 1. mount -t f2fs -o compress_log_size=5 /dev/vdb /mnt/f2fs 2. touch /mnt/f2fs/file 3. chattr +c /mnt/f2fs/file 4. dd if=/dev/zero of=/mnt/f2fs/file bs=1MB count=1 5. sync 6. dd if=/dev/zero of=/mnt/f2fs/file bs=111 count=11 conv=notrunc 7. sync INFO: task sync:4788 blocked for more than 120 seconds. Not tainted 6.5.0-rc1+ torvalds#322 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sync state:D stack:0 pid:4788 ppid:509 flags:0x00000002 Call Trace: <TASK> __schedule+0x335/0xf80 schedule+0x6f/0xf0 wb_wait_for_completion+0x5e/0x90 sync_inodes_sb+0xd8/0x2a0 sync_inodes_one_sb+0x1d/0x30 iterate_supers+0x99/0xf0 ksys_sync+0x46/0xb0 __do_sys_sync+0x12/0x20 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The reason is f2fs_all_cluster_page_ready() assumes that pages array should cover at least one cluster, otherwise, it will always return false, result in deadloop. By default, pages array size is 16, and it can cover the case cluster_size is equal or less than 16, for the case cluster_size is larger than 16, let's allocate memory of pages array dynamically. Fixes: 4c8ff70 ("f2fs: support data compression") Signed-off-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>

On Raspberry Pis without onboard USB hub frequent device reconnects can trigger a interrupt storm after DWC2 entered host clock gating. This is caused by a race between _dwc2_hcd_suspend() and the port interrupt, which sets port_connect_status. The issue occurs if port_connect_status is still 1, but there is no connection anymore: usb 1-1: USB disconnect, device number 25 dwc2 3f980000.usb: _dwc2_hcd_suspend: port_connect_status: 1 dwc2 3f980000.usb: Entering host clock gating. Disabling IRQ torvalds#66 irq 66: nobody cared (try booting with the "irqpoll" option) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-gc1bb81b13202-dirty torvalds#322 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x50/0x64 dump_stack_lvl from __report_bad_irq+0x38/0xc0 __report_bad_irq from note_interrupt+0x2ac/0x2f4 note_interrupt from handle_irq_event+0x88/0x8c handle_irq_event from handle_level_irq+0xb4/0x1ac handle_level_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28 bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44 generic_handle_arch_irq from __irq_svc+0x88/0xb0 Exception stack(0xc1d01f20 to 0xc1d01f68) 1f20: 0004ef3c 00000001 00000000 00000000 c1d09780 c1f6bb5c c1d04e54 c1c60ca8 1f40: c1d04e94 00000000 00000000 c1d092a8 c1f6af20 c1d01f70 c1211b98 c1212f40 1f60: 60000013 ffffffff __irq_svc from default_idle_call+0x1c/0xb0 default_idle_call from do_idle+0x21c/0x284 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from kernel_init+0x0/0x12c handlers: [<e3a25c00>] dwc2_handle_common_intr [<58bf98a3>] usb_hcd_irq Disabling IRQ torvalds#66 So avoid this by reading the connection status directly. Fixes: 113f86d ("usb: dwc2: Update partial power down entering by system suspend") Signed-off-by: Stefan Wahren <wahrenst@gmx.net>

On Raspberry Pis without onboard USB hub frequent device reconnects can trigger a interrupt storm after DWC2 entered host clock gating. This is caused by a race between _dwc2_hcd_suspend() and the port interrupt, which sets port_connect_status. The issue occurs if port_connect_status is still 1, but there is no connection anymore: usb 1-1: USB disconnect, device number 25 dwc2 3f980000.usb: _dwc2_hcd_suspend: port_connect_status: 1 dwc2 3f980000.usb: Entering host clock gating. Disabling IRQ torvalds#66 irq 66: nobody cared (try booting with the "irqpoll" option) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-gc1bb81b13202-dirty torvalds#322 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x50/0x64 dump_stack_lvl from __report_bad_irq+0x38/0xc0 __report_bad_irq from note_interrupt+0x2ac/0x2f4 note_interrupt from handle_irq_event+0x88/0x8c handle_irq_event from handle_level_irq+0xb4/0x1ac handle_level_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28 bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44 generic_handle_arch_irq from __irq_svc+0x88/0xb0 Exception stack(0xc1d01f20 to 0xc1d01f68) 1f20: 0004ef3c 00000001 00000000 00000000 c1d09780 c1f6bb5c c1d04e54 c1c60ca8 1f40: c1d04e94 00000000 00000000 c1d092a8 c1f6af20 c1d01f70 c1211b98 c1212f40 1f60: 60000013 ffffffff __irq_svc from default_idle_call+0x1c/0xb0 default_idle_call from do_idle+0x21c/0x284 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from kernel_init+0x0/0x12c handlers: [<e3a25c00>] dwc2_handle_common_intr [<58bf98a3>] usb_hcd_irq Disabling IRQ torvalds#66 So avoid this by reading the connection status directly. Fixes: 113f86d ("usb: dwc2: Update partial power down entering by system suspend") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20241202001631.75473-4-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 1cf1bd8 upstream. On Raspberry Pis without onboard USB hub frequent device reconnects can trigger a interrupt storm after DWC2 entered host clock gating. This is caused by a race between _dwc2_hcd_suspend() and the port interrupt, which sets port_connect_status. The issue occurs if port_connect_status is still 1, but there is no connection anymore: usb 1-1: USB disconnect, device number 25 dwc2 3f980000.usb: _dwc2_hcd_suspend: port_connect_status: 1 dwc2 3f980000.usb: Entering host clock gating. Disabling IRQ torvalds#66 irq 66: nobody cared (try booting with the "irqpoll" option) CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-gc1bb81b13202-dirty torvalds#322 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x50/0x64 dump_stack_lvl from __report_bad_irq+0x38/0xc0 __report_bad_irq from note_interrupt+0x2ac/0x2f4 note_interrupt from handle_irq_event+0x88/0x8c handle_irq_event from handle_level_irq+0xb4/0x1ac handle_level_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from bcm2836_chained_handle_irq+0x24/0x28 bcm2836_chained_handle_irq from generic_handle_domain_irq+0x24/0x34 generic_handle_domain_irq from generic_handle_arch_irq+0x34/0x44 generic_handle_arch_irq from __irq_svc+0x88/0xb0 Exception stack(0xc1d01f20 to 0xc1d01f68) 1f20: 0004ef3c 00000001 00000000 00000000 c1d09780 c1f6bb5c c1d04e54 c1c60ca8 1f40: c1d04e94 00000000 00000000 c1d092a8 c1f6af20 c1d01f70 c1211b98 c1212f40 1f60: 60000013 ffffffff __irq_svc from default_idle_call+0x1c/0xb0 default_idle_call from do_idle+0x21c/0x284 do_idle from cpu_startup_entry+0x28/0x2c cpu_startup_entry from kernel_init+0x0/0x12c handlers: [<e3a25c00>] dwc2_handle_common_intr [<58bf98a3>] usb_hcd_irq Disabling IRQ torvalds#66 So avoid this by reading the connection status directly. Fixes: 113f86d ("usb: dwc2: Update partial power down entering by system suspend") Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Link: https://lore.kernel.org/r/20241202001631.75473-4-wahrenst@gmx.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

guylamar2006 added 2 commits August 15, 2016 14:04

Add files via upload

8d28b75

Add baytrail wifi SDIO ID.

Add files via upload

b5aaac9

Added Baytrail SDIO ID.

laijs pushed a commit to laijs/linux that referenced this pull request Feb 22, 2017

Merge pull request torvalds#322 from laijs/host_task_stub

5b3fcd5

use host_task_stub() for host task

yestyle pushed a commit to yestyle/linux that referenced this pull request Jul 10, 2022

Merge pull request torvalds#322 from nbdd0121/macros

ec966c7

Implement a `#[vtable]` macro

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ath6kl Baytrail SDIO support #322

Ath6kl Baytrail SDIO support #322

guylamar2006 commented Sep 14, 2016

Ath6kl Baytrail SDIO support #322

Are you sure you want to change the base?

Ath6kl Baytrail SDIO support #322

Conversation

guylamar2006 commented Sep 14, 2016