Test push #195

fireshots · 2015-07-20T09:43:06Z

No description provided.

ecnepsnai · 2015-07-21T00:58:07Z

-1 Spam

fireshots · 2015-07-21T02:37:21Z

Hi
I'm sorry about spam message

Happy day

나의 iPhone에서 보냄

1. 1. 오전 10:01 Ian Spence notifications@github.com 작성:

-1 Spam

—
Reply to this email directly or view it on GitHub.

WARNING: line over 80 characters torvalds#103: FILE: include/linux/mm.h:132: +#define VM_LOCKONFAULT 0x00001000 /* Lock the pages covered when they are faulted in */ WARNING: line over 80 characters torvalds#195: FILE: mm/hugetlb.c:3768: + unsigned long svm_flags = svma->vm_flags & ~(VM_LOCKED | VM_LOCKONFAULT); WARNING: line over 80 characters torvalds#231: FILE: mm/rmap.c:747: + pra->vm_flags |= (vma->vm_flags & (VM_LOCKED | VM_LOCKONFAULT)); WARNING: line over 80 characters torvalds#240: FILE: mm/rmap.c:768: + pra->vm_flags |= (vma->vm_flags & (VM_LOCKED | VM_LOCKONFAULT)); total: 0 errors, 4 warnings, 138 lines checked ./patches/mm-introduce-vm_lockonfault.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: Eric B Munson <emunson@akamai.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

Here is a bug with mlx5_ib. commit d603c80 Author: Eli Cohen <eli@mellanox.com> Date: Fri Mar 11 22:58:35 2016 +0200 IB/mlx5: Fix decision on using MAD_IFC This commit causes below WARN. The "ix" returns -1 658 void ib_cache_gid_set_default_gid(struct ib_device *ib_dev, u8 port, ... 693 /* Coudn't find default GID location */ 694 WARN_ON(ix < 0); 695 WARNING: CPU: 1 PID: 2651 at /home/mlin/linux/drivers/infiniband/core/cache.c:717 ib_cache_gid_set_default_gid+0x2f8/0x340 [ib_core] [ 394.725187] CPU: 1 PID: 2651 Comm: modprobe Tainted: G OE 4.6.0-rc3+ torvalds#195 [ 394.734464] Hardware name: Dell Inc. OptiPlex 7010/0YXT71, BIOS A15 08/12/2013 [ 394.743131] 0000000000000000 ffff88006791b848 ffffffff8132996a 0000000000000000 [ 394.752045] 0000000000000000 ffff88006791b888 ffffffff8106a7c7 000002cd00000008 [ 394.761426] 0000000000000000 0000000000000001 ffff880063028780 ffff880060d7c000 [ 394.770370] Call Trace: [ 394.774749] [<ffffffff8132996a>] dump_stack+0x63/0x89 [ 394.781582] [<ffffffff8106a7c7>] __warn+0xc7/0xf0 [ 394.788325] [<ffffffff8106a8a8>] warn_slowpath_null+0x18/0x20 [ 394.795732] [<ffffffffc0860c48>] ib_cache_gid_set_default_gid+0x2f8/0x340 [ib_core] [ 394.804556] [<ffffffff8109ef07>] ? pick_next_task_fair+0x367/0x490 [ 394.811923] [<ffffffff816db9e0>] ? __schedule+0x660/0x770 [ 394.818487] [<ffffffffc08624ef>] add_netdev_ips+0xaf/0xc0 [ib_core] [ 394.825935] [<ffffffffc0862685>] enum_all_gids_of_dev_cb+0x85/0xc0 [ib_core] [ 394.834155] [<ffffffffc0861760>] ? rdma_protocol_roce_eth_encap+0x20/0x20 [ib_core] [ 394.842993] [<ffffffffc085e642>] ib_enum_roce_netdev+0xe2/0x100 [ib_core] [ 394.850959] [<ffffffffc0862600>] ? is_eth_port_of_netdev+0x90/0x90 [ib_core] [ 394.859193] [<ffffffffc086281c>] roce_rescan_device+0x1c/0x20 [ib_core] [ 394.866981] [<ffffffffc0860d7b>] ib_cache_setup_one+0xeb/0x400 [ib_core] [ 394.874851] [<ffffffffc085e299>] ib_register_device+0x2d9/0x500 [ib_core] [ 394.882807] [<ffffffffc0979961>] mlx5_ib_add+0xad1/0x1370 [mlx5_ib] [ 394.890211] [<ffffffff8108dad8>] ? ttwu_do_activate.constprop.81+0x58/0x60 [ 394.898212] [<ffffffff81084224>] ? __alloc_workqueue_key+0x1f4/0x540 [ 394.905696] [<ffffffffc08840ec>] mlx5_add_device+0x3c/0xa0 [mlx5_core] [ 394.913340] [<ffffffffc09e3000>] ? 0xffffffffc09e3000 [ 394.919516] [<ffffffffc08841bc>] mlx5_register_interface+0x6c/0xa0 [mlx5_core] [ 394.927858] [<ffffffffc09e3035>] mlx5_ib_init+0x35/0x4b [mlx5_ib] [ 394.935059] [<ffffffff81002138>] do_one_initcall+0xc8/0x1f0 [ 394.941734] [<ffffffff81159690>] ? __vunmap+0x80/0xd0 [ 394.947875] [<ffffffff8111d04f>] do_init_module+0x56/0x1c8 [ 394.954450] [<ffffffff810dd2be>] load_module+0x1dae/0x2670 [ 394.961034] [<ffffffff810da7b0>] ? __symbol_put+0x50/0x50 [ 394.967543] [<ffffffff810ddd89>] SYSC_finit_module+0xa9/0xd0 [ 394.974302] [<ffffffff810dddc9>] SyS_finit_module+0x9/0x10 [ 394.980878] [<ffffffff816df1b6>] entry_SYSCALL_64_fastpath+0x1e/0xa8 [ 394.988336] ---[ end trace df64015bed03617a ]--- [ 395.007774] BUG: unable to handle kernel paging request at ffffffffffffffe0 [ 395.302076] Call Trace: [ 395.305549] [<ffffffff8106a7a0>] ? __warn+0xa0/0xf0 [ 395.311550] [<ffffffffc0860bd4>] ib_cache_gid_set_default_gid+0x284/0x340 [ib_core] [ 395.320335] [<ffffffff816db9e0>] ? __schedule+0x660/0x770 [ 395.326868] [<ffffffffc08624ef>] add_netdev_ips+0xaf/0xc0 [ib_core] [ 395.334268] [<ffffffffc0862685>] enum_all_gids_of_dev_cb+0x85/0xc0 [ib_core] [ 395.342452] [<ffffffffc0861760>] ? rdma_protocol_roce_eth_encap+0x20/0x20 [ib_core] [ 395.351239] [<ffffffffc085e642>] ib_enum_roce_netdev+0xe2/0x100 [ib_core] [ 395.359167] [<ffffffffc0862600>] ? is_eth_port_of_netdev+0x90/0x90 [ib_core] [ 395.367353] [<ffffffffc086281c>] roce_rescan_device+0x1c/0x20 [ib_core] [ 395.375115] [<ffffffffc0860d7b>] ib_cache_setup_one+0xeb/0x400 [ib_core] [ 395.382949] [<ffffffffc085e299>] ib_register_device+0x2d9/0x500 [ib_core] [ 395.390869] [<ffffffffc0979961>] mlx5_ib_add+0xad1/0x1370 [mlx5_ib] [ 395.398289] [<ffffffff8108dad8>] ? ttwu_do_activate.constprop.81+0x58/0x60 [ 395.406318] [<ffffffff81084224>] ? __alloc_workqueue_key+0x1f4/0x540 [ 395.413806] [<ffffffffc08840ec>] mlx5_add_device+0x3c/0xa0 [mlx5_core] [ 395.421467] [<ffffffffc09e3000>] ? 0xffffffffc09e3000 [ 395.427644] [<ffffffffc08841bc>] mlx5_register_interface+0x6c/0xa0 [mlx5_core] [ 395.436002] [<ffffffffc09e3035>] mlx5_ib_init+0x35/0x4b [mlx5_ib] [ 395.443222] [<ffffffff81002138>] do_one_initcall+0xc8/0x1f0 [ 395.449938] [<ffffffff81159690>] ? __vunmap+0x80/0xd0 [ 395.456114] [<ffffffff8111d04f>] do_init_module+0x56/0x1c8 [ 395.462722] [<ffffffff810dd2be>] load_module+0x1dae/0x2670 [ 395.469324] [<ffffffff810da7b0>] ? __symbol_put+0x50/0x50 [ 395.475872] [<ffffffff810ddd89>] SYSC_finit_module+0xa9/0xd0 [ 395.482656] [<ffffffff810dddc9>] SyS_finit_module+0x9/0x10 [ 395.489252] [<ffffffff816df1b6>] entry_SYSCALL_64_fastpath+0x1e/0xa8 Instead of reverting the commit, I tried to find out the cause. ib_cache_gid_set_default_gid() calls find_gid() 249 static int find_gid(struct ib_gid_table *table, const union ib_gid *gid, 250 const struct ib_gid_attr *val, bool default_gid, 251 unsigned long mask, int *pempty) 252 { 253 int i = 0; 254 int found = -1; 255 int empty = pempty ? -1 : 0; 256 257 while (i < table->sz && (found < 0 || empty < 0)) { find_gid() returns -1 because table->sz is 0. 757 static int _gid_table_setup_one(struct ib_device *ib_dev) 758 { 759 u8 port; 760 struct ib_gid_table **table; 761 int err = 0; 762 763 table = kcalloc(ib_dev->phys_port_cnt, sizeof(*table), GFP_KERNEL); 764 765 if (!table) { 766 pr_warn("failed to allocate ib gid cache for %s\n", 767 ib_dev->name); 768 return -ENOMEM; 769 } 770 771 for (port = 0; port < ib_dev->phys_port_cnt; port++) { 772 u8 rdma_port = port + rdma_start_port(ib_dev); 773 774 table[port] = 775 alloc_gid_table( 776 ib_dev->port_immutable[rdma_port].gid_tbl_len); "table" is allocated in alloc_gid_table(). And debug shows ib_dev->port_immutable[rdma_port].gid_tbl_len is 0. "gid_tbl_len" is set in mlx5_query_mad_ifc_port() 498 int mlx5_query_mad_ifc_port(struct ib_device *ibdev, u8 port, 499 struct ib_port_attr *props) 500 { ... 537 props->gid_tbl_len = out_mad->data[50]; Debug shows out_mad->data[50] is 0. So here is the "temporary" patch. I just copied it from mlx5_query_hca_port()

In the driver ptp_tx_skb variable stores the skb address This variable is of type u32. On 64-bit platform it is causing a kernel crash when trying to access this variable. Crash log: [ 58.675430] Unable to handle kernel paging request at virtual address 6e882cc8 [ 58.682583] pgd = ffffffc0018d7000 [ 58.685956] [6e882cc8] *pgd=0000000000000000, *pud=0000000000000000 [ 58.692206] Internal error: Oops: 96000005 [#1] SMP [ 58.697067] Modules linked in: [ 58.700106] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.0 torvalds#195 [ 58.706095] Hardware name: ZynqMP ZCU102 (DT) [ 58.710435] task: ffffffc00180a8c0 ti: ffffffc0017fc000 task.ti: ffffffc0017fc000 [ 58.717912] PC is at axienet_tx_irq+0x1f4/0x3fc [ 58.722416] LR is at handle_irq_event_percpu+0x94/0x13c [ 58.727622] pc : [<ffffffc00051d54c>] lr : [<ffffffc0000d1194>] pstate: 000001c5 [ 58.735005] sp : ffffffc0017ffc30 [ 58.738296] x29: ffffffc0017ffc30 x28: ffffff8000279a00 [ 58.743589] x27: ffffffc071bed700 x26: ffffffc000913b70 [ 58.748884] x25: ffffffc0007e7130 x24: ffffffc071afbe00 [ 58.754179] x23: ffffffc071bed000 x22: 0000000000000000 [ 58.759473] x21: 0000000000000000 x20: ffffffc071bed000 [ 58.764768] x19: 0000000080000056 x18: 0000007fef55a510 [ 58.770063] x17: 0000007f8f15d0c0 x16: ffffffc00017d4ec [ 58.775358] x15: ffffffffffffffff x14: ffffffffffffff00 [ 58.780653] x13: ffffffffffffffff x12: 0000000000000008 [ 58.785948] x11: 0101010101010101 x10: 00000000000006e0 [ 58.791242] x9 : ffffffc0017ffe70 x8 : ffffffc071400768 [ 58.796537] x7 : ffffffc0714006c8 x6 : 0000000000000000 [ 58.801832] x5 : 00000000fffffffa x4 : 00000000767af000 [ 58.807126] x3 : 0000000000000000 x2 : ffffff80001c0000 [ 58.812421] x1 : ffffffc071bed000 x0 : 000000006e882c00 [ 58.817715] [ 58.819194] Process swapper/0 (pid: 0, stack limit = 0xffffffc0017fc020) [ 58.825880] Stack: (0xffffffc0017ffc30 to 0xffffffc001800000) [ 58.831609] fc20: ffffffc0017ffca0 ffffffc0000d1194 [ 58.839428] fc40: ffffffc06e881280 ffffffc001835580 0000000000000000 0000000000000000 [ 58.847240] fc60: 00000000000000cf ffffffc071afbe00 ffffffc00187c3cb ffffffc000913b70 [ 58.855052] fc80: ffffffc000913b98 0000000000000000 ffffffc00187c3cb ffffffc0009799f0 [ 58.862864] fca0: ffffffc0017ffd00 ffffffc0000d1280 ffffffc071afbe00 ffffffc001835580 [ 58.870676] fcc0: ffffffc071afbe9c ffffffc001805040 ffffff8000014010 ffffff8000015000 [ 58.878488] fce0: ffffffc000766cd0 ffffffc00187c000 0000000000000000 ffffffc0000eeb4c [ 58.886300] fd00: ffffffc0017ffd30 ffffffc0000d461c ffffffc071afbe00 ffffffc001835580 [ 58.894112] fd20: 0000000000000000 ffffffc00009b18c ffffffc0017ffd50 ffffffc0000d07a0 [ 58.901924] fd40: ffffffc0017e5000 0000000000000000 ffffffc0017ffd60 ffffffc0000d0ab8 [ 58.909736] fd60: ffffffc0017ffda0 ffffffc000080cec ffffff800001400c ffffffc001835000 [ 58.917548] fd80: ffffffc0017ffde0 ffffffc07132c1e0 ffffffc071808000 0000007900757990 [ 58.925360] fda0: ffffffc0017fff00 ffffffc000083da8 ffffffc0017fc000 ffffffc001802000 [ 58.933172] fdc0: ffffffc0017fff00 ffffffc000084e70 0000000060000145 ffffffc0017e6c78 [ 58.940983] fde0: 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 58.948796] fe00: 0000000000000000 00000000767af000 ffffffc001802ad0 00000000ffff1452 [ 58.956608] fe20: ffffffc00180b000 ffffffc0017ffe70 00000000000006e0 0101010101010101 [ 58.964420] fe40: 0000000000000008 ffffffffffffffff ffffffffffffff00 ffffffffffffffff [ 58.972232] fe60: ffffffc00017d4ec 0000007f8f15d0c0 0000007fef55a510 ffffffc0017fc000 [ 58.980044] fe80: ffffffc001802000 ffffffc001802ad0 ffffffc0017e39c0 ffffffc0017fff20 [ 58.987856] fea0: ffffffc0017e6c78 ffffffc000766cd0 ffffffc00187c000 0000000000000000 [ 58.995668] fec0: 0000000000000000 ffffffc0017fff00 ffffffc000084e6c ffffffc0017fff00 [ 59.003480] fee0: ffffffc000084e70 0000000060000145 ffffffc000766cd0 ffffffc000757ca8 [ 59.011292] ff00: ffffffc0017fff10 ffffffc0000c99f8 ffffffc0017fff20 ffffffc0000c9b30 [ 59.019104] ff20: ffffffc0017fff90 ffffffc000754f08 ffffffc00187f000 ffffffc00187f000 [ 59.026916] ff40: ffffffc00187f000 ffffffc001802000 ffffffc077fd0000 ffffffc000a462c8 [ 59.034728] ff60: 00000000018d4000 00000000018d7000 ffffffc0000801d8 000000007df4ae40 [ 59.042540] ff80: ffffffc0017fff90 ffffffc000754f00 ffffffc0017fffa0 ffffffc000a1594c [ 59.050352] ffa0: 0000000000000000 000000000075c000 0000000000000400 0000000000000e12 [ 59.058163] ffc0: 0000000007ff5000 0000000000000003 000000007df47c88 0000000000000000 [ 59.065975] ffe0: 0000000000000000 ffffffc000a462c8 0000000000000000 0000000000000000 [ 59.073785] Call trace: [ 59.076211] [<ffffffc00051d54c>] axienet_tx_irq+0x1f4/0x3fc [ 59.081767] [<ffffffc0000d1194>] handle_irq_event_percpu+0x94/0x13c [ 59.088017] [<ffffffc0000d1280>] handle_irq_event+0x44/0x74 [ 59.093573] [<ffffffc0000d461c>] handle_fasteoi_irq+0xac/0x19c [ 59.099387] [<ffffffc0000d07a0>] generic_handle_irq+0x24/0x38 [ 59.105116] [<ffffffc0000d0ab8>] __handle_domain_irq+0x60/0xac [ 59.110932] [<ffffffc000080cec>] gic_handle_irq+0x60/0xb4 [ 59.116312] Exception stack(0xffffffc0017ffdb0 to 0xffffffc0017ffed0) [ 59.122736] fda0: ffffffc0017fc000 ffffffc001802000 [ 59.130555] fdc0: ffffffc0017fff00 ffffffc000084e70 0000000060000145 ffffffc0017e6c78 [ 59.138366] fde0: 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 59.146179] fe00: 0000000000000000 00000000767af000 ffffffc001802ad0 00000000ffff1452 [ 59.153991] fe20: ffffffc00180b000 ffffffc0017ffe70 00000000000006e0 0101010101010101 [ 59.161803] fe40: 0000000000000008 ffffffffffffffff ffffffffffffff00 ffffffffffffffff [ 59.169615] fe60: ffffffc00017d4ec 0000007f8f15d0c0 0000007fef55a510 ffffffc0017fc000 [ 59.177427] fe80: ffffffc001802000 ffffffc001802ad0 ffffffc0017e39c0 ffffffc0017fff20 [ 59.185239] fea0: ffffffc0017e6c78 ffffffc000766cd0 ffffffc00187c000 0000000000000000 [ 59.193050] fec0: 0000000000000000 ffffffc0017fff00 [ 59.197905] [<ffffffc000083da8>] el1_irq+0x68/0xc0 [ 59.202680] [<ffffffc0000c99f8>] default_idle_call+0x1c/0x30 [ 59.208322] [<ffffffc0000c9b30>] cpu_startup_entry+0x124/0x1dc [ 59.214138] [<ffffffc000754f08>] rest_init+0x74/0x7c [ 59.219086] [<ffffffc000a1594c>] start_kernel+0x394/0x3a8 [ 59.224465] [<000000000075c000>] 0x75c000 [ 59.228459] Code: b9404380 34fffb60 2a0003e0 f944a2e2 (b940c818) This patch fixes this issue. Signed-off-by: Kedareswara rao Appana <appanad@xilinx.com> Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#173: FILE: include/rtl8723b_hal.h:173: +typedef enum _C2H_EVT { WARNING: do not add new typedefs torvalds#189: FILE: include/rtl8723b_hal.h:189: +typedef struct _C2H_EVT_HDR { WARNING: do not add new typedefs torvalds#195: FILE: include/rtl8723b_hal.h:195: +typedef enum tag_Package_Definition { Signed-off-by: Marco Cesati <marco.cesati@gmail.com>

This commit fixes the following checkpatch.pl warnings: WARNING: do not add new typedefs torvalds#173: FILE: include/rtl8723b_hal.h:173: +typedef enum _C2H_EVT { WARNING: do not add new typedefs torvalds#189: FILE: include/rtl8723b_hal.h:189: +typedef struct _C2H_EVT_HDR { WARNING: do not add new typedefs torvalds#195: FILE: include/rtl8723b_hal.h:195: +typedef enum tag_Package_Definition { Signed-off-by: Marco Cesati <marco.cesati@gmail.com> Link: https://lore.kernel.org/r/20210312082638.25512-23-marco.cesati@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…nslate the same key and the ones that depend on other translations The hid-apple driver does not support chaining translations or dependencies on other translations. This creates two problems: 1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this problem. The quirk is not set for the Macs where these bugs happen yet (see the 2nd patch for that), but this can be forced by setting the iso_layout parameter. Unfortunately, this only partially works. KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get translated to KEY_102ND, so both of them end up functioning as KEY_GRAVE. This is because the driver translates the keys as if Fn was pressed and the original is sent if it is not pressed, without any further translations happening on the key[torvalds#463]. KEY_GRAVE is present at macbookpro_no_esc_fn_keys[torvalds#195], so this is what happens: - KEY_GRAVE -> KEY_ESC (as if Fn is pressed) - KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded) - KEY_GRAVE -> KEY_102ND (this part is not reached!) ... 2 - In case the touchbar does not work, the driver supports sending Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND is actually KEY_GRAVE and needs to be translated before this happens. Normally, these are the steps that should happen: - KEY_102ND -> KEY_GRAVE - KEY_GRAVE -> KEY_ESC (Fn is pressed) - KEY_ESC is returned Though this is what happens instead, as dependencies on other translations are not supported: - KEY_102ND -> KEY_ESC (Fn is pressed) - KEY_ESC is returned This patch fixes both bugs by ordering the translations correctly and by making the translations continue and not return immediately after translating a key so that chained translations work and translations can depend on other ones. This patch also simplifies the implementation of the swap_fn_leftctrl option a little bit, as it makes it simply use a normal translation instead adding extra code to translate a key to KEY_FN[torvalds#381]. This change wasn't put in another patch as the code that translates the Fn key needs to be changed because of the changes in the patch, and those changes would be discarded with the next patch anyway (the part that originally translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of the part that transltes KEY_LEFTCTRL to KEY_FN). Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit 20afcc4 ("HID: apple: Add "GANSS" to the non-Apple list"). Note: These bugs are only present on Macs with a keyboard with no dedicated escape key and a non-English layout. Signed-off-by: Kerem Karabay <kekrby@gmail.com>

…nslate the same key The hid-apple driver does not support chaining translations or dependencies on other translations. This creates two problems: 1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this problem. The quirk is not set for the Macs where these bugs happen yet (see the 2nd patch for that), but this can be forced by setting the iso_layout parameter. Unfortunately, this only partially works. KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get translated to KEY_102ND, so both of them end up functioning as KEY_GRAVE. This is because the driver translates the keys as if Fn was pressed and the original is sent if it is not pressed, without any further translations happening on the key[torvalds#463]. KEY_GRAVE is present at macbookpro_no_esc_fn_keys[torvalds#195], so this is what happens: - KEY_GRAVE -> KEY_ESC (as if Fn is pressed) - KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded) - KEY_GRAVE -> KEY_102ND (this part is not reached!) ... 2 - In case the touchbar does not work, the driver supports sending Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND is actually KEY_GRAVE and needs to be translated before this happens. Normally, these are the steps that should happen: - KEY_102ND -> KEY_GRAVE - KEY_GRAVE -> KEY_ESC (Fn is pressed) - KEY_ESC is returned Though this is what happens instead, as dependencies on other translations are not supported: - KEY_102ND -> KEY_ESC (Fn is pressed) - KEY_ESC is returned This patch fixes both bugs by ordering the translations correctly and by making the translations continue and not return immediately after translating a key so that chained translations work and translations can depend on other ones. This patch also simplifies the implementation of the swap_fn_leftctrl option a little bit, as it makes it simply use a normal translation instead adding extra code to translate a key to KEY_FN[torvalds#381]. This change wasn't put in another patch as the code that translates the Fn key needs to be changed because of the changes in the patch, and those changes would be discarded with the next patch anyway (the part that originally translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of the part that transltes KEY_LEFTCTRL to KEY_FN). Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit 20afcc4 ("HID: apple: Add "GANSS" to the non-Apple list"). Note: These bugs are only present on Macs with a keyboard with no dedicated escape key and a non-English layout. Signed-off-by: Kerem Karabay <kekrby@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>

…nslate the same key and the ones that depend on other translations The hid-apple driver does not support chaining translations or dependencies on other translations. This creates two problems: 1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this problem. The quirk is not set for the Macs where these bugs happen yet (see the 2nd patch for that), but this can be forced by setting the iso_layout parameter. Unfortunately, this only partially works. KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get translated to KEY_102ND, so both of them end up functioning as KEY_GRAVE. This is because the driver translates the keys as if Fn was pressed and the original is sent if it is not pressed, without any further translations happening on the key[torvalds#463]. KEY_GRAVE is present at macbookpro_no_esc_fn_keys[torvalds#195], so this is what happens: - KEY_GRAVE -> KEY_ESC (as if Fn is pressed) - KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded) - KEY_GRAVE -> KEY_102ND (this part is not reached!) ... 2 - In case the touchbar does not work, the driver supports sending Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND is actually KEY_GRAVE and needs to be translated before this happens. Normally, these are the steps that should happen: - KEY_102ND -> KEY_GRAVE - KEY_GRAVE -> KEY_ESC (Fn is pressed) - KEY_ESC is returned Though this is what happens instead, as dependencies on other translations are not supported: - KEY_102ND -> KEY_ESC (Fn is pressed) - KEY_ESC is returned This patch fixes both bugs by ordering the translations correctly and by making the translations continue and not return immediately after translating a key so that chained translations work and translations can depend on other ones. This patch also simplifies the implementation of the swap_fn_leftctrl option a little bit, as it makes it simply use a normal translation instead adding extra code to translate a key to KEY_FN[torvalds#381]. This change wasn't put in another patch as the code that translates the Fn key needs to be changed because of the changes in the patch, and those changes would be discarded with the next patch anyway (the part that originally translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of the part that transltes KEY_LEFTCTRL to KEY_FN). Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit 20afcc4 ("HID: apple: Add "GANSS" to the non-Apple list"). Note: These bugs are only present on Macs with a keyboard with no dedicated escape key and a non-English layout. Signed-off-by: Kerem Karabay <kekrby@gmail.com>

Advance the line numbers so messages don't repeat previously processed lines. Before: WARNING: please write 4 lines of help text that fully describes the config symbol (detected 3 lines) torvalds#195: FILE: crypto/Kconfig:837: +config CRYPTO_GHASH_CLMUL_NI_INTEL + tristate "GHASH (x86_64 with CLMUL-NI)" depends on X86 && 64BIT + select CRYPTO_CRYPTD + select CRYPTO_CRYPTD + select CRYPTO_CRYPTD help + GCM GHASH hash function (NIST SP800-38D) + GCM GHASH hash function (NIST SP800-38D) Architecture: x86_64 using: + * CLMUL-NI (carry-less multiplication new instructions) + * CLMUL-NI (carry-less multiplication new instructions) + * CLMUL-NI (carry-less multiplication new instructions) +config CRYPTO_GHASH_S390 +config CRYPTO_GHASH_S390 +config CRYPTO_GHASH_S390 +config CRYPTO_GHASH_S390 After: WARNING: please write 4 lines of help text that fully describes the config symbol (detected 3 lines) torvalds#195: FILE: crypto/Kconfig:837: +config CRYPTO_GHASH_CLMUL_NI_INTEL + tristate "GHASH (x86_64 with CLMUL-NI)" depends on X86 && 64BIT + select CRYPTO_CRYPTD help + GCM GHASH hash function (NIST SP800-38D) Architecture: x86_64 using: + * CLMUL-NI (carry-less multiplication new instructions) +config CRYPTO_GHASH_S390 Signed-off-by: Robert Elliott <elliott@hpe.com>

test_bpf tail call tests end up as: test_bpf: #0 Tail call leaf jited:1 85 PASS test_bpf: #1 Tail call 2 jited:1 111 PASS test_bpf: #2 Tail call 3 jited:1 145 PASS test_bpf: #3 Tail call 4 jited:1 170 PASS test_bpf: #4 Tail call load/store leaf jited:1 190 PASS test_bpf: #5 Tail call load/store jited:1 BUG: Unable to handle kernel data access on write at 0xf1b4e000 Faulting instruction address: 0xbe86b710 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash PowerMac Modules linked in: test_bpf(+) CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ torvalds#195 Hardware name: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] __run_one+0xec/0x264 [test_bpf] Call Trace: [f1b4dfe] [00000002] 0x2 (unreliable) Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]--- This is a tentative to write above the stack. The problem is encoutered with tests added by commit 38608ee ("bpf, tests: Add load store test case for tail call") This happens because tail call is done to a BPF prog with a different stack_depth. At the time being, the stack is kept as is when the caller tail calls its callee. But at exit, the callee restores the stack based on its own properties. Therefore here, at each run, r1 is erroneously increased by 32 - 16 = 16 bytes. This was done that way in order to pass the tail call count from caller to callee through the stack. As powerpc32 doesn't have a red zone in the stack, it was necessary the maintain the stack as is for the tail call. But it was not anticipated that the BPF frame size could be different. Let's take a new approach. Use register r4 to carry the tail call count during the tail call, and save it into the stack at function entry if required. This means the input parameter must be in r3, which is more correct as it is a 32 bits parameter, then tail call better match with normal BPF function entry, the down side being that we move that input parameter back and forth between r3 and r4. That can be optimised later. Doing that also has the advantage of maximising the common parts between tail calls and a normal function exit. With the fix, tail call tests are now successfull: test_bpf: #0 Tail call leaf jited:1 53 PASS test_bpf: #1 Tail call 2 jited:1 115 PASS test_bpf: #2 Tail call 3 jited:1 154 PASS test_bpf: #3 Tail call 4 jited:1 165 PASS test_bpf: #4 Tail call load/store leaf jited:1 101 PASS test_bpf: #5 Tail call load/store jited:1 141 PASS test_bpf: torvalds#6 Tail call error path, max count reached jited:1 994 PASS test_bpf: torvalds#7 Tail call count preserved across function calls jited:1 140975 PASS test_bpf: torvalds#8 Tail call error path, NULL target jited:1 110 PASS test_bpf: torvalds#9 Tail call error path, index out of range jited:1 69 PASS test_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed] Suggested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Fixes: 51c66ad ("powerpc/bpf: Implement extended BPF on PPC32") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>

test_bpf tail call tests end up as: test_bpf: #0 Tail call leaf jited:1 85 PASS test_bpf: #1 Tail call 2 jited:1 111 PASS test_bpf: #2 Tail call 3 jited:1 145 PASS test_bpf: #3 Tail call 4 jited:1 170 PASS test_bpf: #4 Tail call load/store leaf jited:1 190 PASS test_bpf: #5 Tail call load/store jited:1 BUG: Unable to handle kernel data access on write at 0xf1b4e000 Faulting instruction address: 0xbe86b710 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash PowerMac Modules linked in: test_bpf(+) CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ torvalds#195 Hardware name: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] __run_one+0xec/0x264 [test_bpf] Call Trace: [f1b4dfe] [00000002] 0x2 (unreliable) Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]--- This is a tentative to write above the stack. The problem is encoutered with tests added by commit 38608ee ("bpf, tests: Add load store test case for tail call") This happens because tail call is done to a BPF prog with a different stack_depth. At the time being, the stack is kept as is when the caller tail calls its callee. But at exit, the callee restores the stack based on its own properties. Therefore here, at each run, r1 is erroneously increased by 32 - 16 = 16 bytes. This was done that way in order to pass the tail call count from caller to callee through the stack. As powerpc32 doesn't have a red zone in the stack, it was necessary the maintain the stack as is for the tail call. But it was not anticipated that the BPF frame size could be different. Let's take a new approach. Use register r4 to carry the tail call count during the tail call, and save it into the stack at function entry if required. This means the input parameter must be in r3, which is more correct as it is a 32 bits parameter, then tail call better match with normal BPF function entry, the down side being that we move that input parameter back and forth between r3 and r4. That can be optimised later. Doing that also has the advantage of maximising the common parts between tail calls and a normal function exit. With the fix, tail call tests are now successfull: test_bpf: #0 Tail call leaf jited:1 53 PASS test_bpf: #1 Tail call 2 jited:1 115 PASS test_bpf: #2 Tail call 3 jited:1 154 PASS test_bpf: #3 Tail call 4 jited:1 165 PASS test_bpf: #4 Tail call load/store leaf jited:1 101 PASS test_bpf: #5 Tail call load/store jited:1 141 PASS test_bpf: torvalds#6 Tail call error path, max count reached jited:1 994 PASS test_bpf: torvalds#7 Tail call count preserved across function calls jited:1 140975 PASS test_bpf: torvalds#8 Tail call error path, NULL target jited:1 110 PASS test_bpf: torvalds#9 Tail call error path, index out of range jited:1 69 PASS test_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed] Suggested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Fixes: 51c66ad ("powerpc/bpf: Implement extended BPF on PPC32") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/757acccb7fbfc78efa42dcf3c974b46678198905.1669278887.git.christophe.leroy@csgroup.eu

commit 89d21e2 upstream. test_bpf tail call tests end up as: test_bpf: #0 Tail call leaf jited:1 85 PASS test_bpf: #1 Tail call 2 jited:1 111 PASS test_bpf: #2 Tail call 3 jited:1 145 PASS test_bpf: #3 Tail call 4 jited:1 170 PASS test_bpf: #4 Tail call load/store leaf jited:1 190 PASS test_bpf: #5 Tail call load/store jited:1 BUG: Unable to handle kernel data access on write at 0xf1b4e000 Faulting instruction address: 0xbe86b710 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K MMU=Hash PowerMac Modules linked in: test_bpf(+) CPU: 0 PID: 97 Comm: insmod Not tainted 6.1.0-rc4+ torvalds#195 Hardware name: PowerMac3,1 750CL 0x87210 PowerMac NIP: be86b710 LR: be857e88 CTR: be86b704 REGS: f1b4df20 TRAP: 0300 Not tainted (6.1.0-rc4+) MSR: 00009032 <EE,ME,IR,DR,RI> CR: 28008242 XER: 00000000 DAR: f1b4e000 DSISR: 42000000 GPR00: 00000001 f1b4dfe c11d2280 00000000 00000000 00000000 00000002 00000000 GPR08: f1b4e000 be86b704 f1b4e000 00000000 00000000 100d816a f2440000 fe73baa8 GPR16: f2458000 00000000 c1941ae4 f1fe2248 00000045 c0de0000 f2458030 00000000 GPR24: 000003e8 0000000f f2458000 f1b4dc90 3e584b46 00000000 f24466a0 c1941a00 NIP [be86b710] 0xbe86b710 LR [be857e88] __run_one+0xec/0x264 [test_bpf] Call Trace: [f1b4dfe] [00000002] 0x2 (unreliable) Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX ---[ end trace 0000000000000000 ]--- This is a tentative to write above the stack. The problem is encoutered with tests added by commit 38608ee ("bpf, tests: Add load store test case for tail call") This happens because tail call is done to a BPF prog with a different stack_depth. At the time being, the stack is kept as is when the caller tail calls its callee. But at exit, the callee restores the stack based on its own properties. Therefore here, at each run, r1 is erroneously increased by 32 - 16 = 16 bytes. This was done that way in order to pass the tail call count from caller to callee through the stack. As powerpc32 doesn't have a red zone in the stack, it was necessary the maintain the stack as is for the tail call. But it was not anticipated that the BPF frame size could be different. Let's take a new approach. Use register r4 to carry the tail call count during the tail call, and save it into the stack at function entry if required. This means the input parameter must be in r3, which is more correct as it is a 32 bits parameter, then tail call better match with normal BPF function entry, the down side being that we move that input parameter back and forth between r3 and r4. That can be optimised later. Doing that also has the advantage of maximising the common parts between tail calls and a normal function exit. With the fix, tail call tests are now successfull: test_bpf: #0 Tail call leaf jited:1 53 PASS test_bpf: #1 Tail call 2 jited:1 115 PASS test_bpf: #2 Tail call 3 jited:1 154 PASS test_bpf: #3 Tail call 4 jited:1 165 PASS test_bpf: #4 Tail call load/store leaf jited:1 101 PASS test_bpf: #5 Tail call load/store jited:1 141 PASS test_bpf: torvalds#6 Tail call error path, max count reached jited:1 994 PASS test_bpf: torvalds#7 Tail call count preserved across function calls jited:1 140975 PASS test_bpf: torvalds#8 Tail call error path, NULL target jited:1 110 PASS test_bpf: torvalds#9 Tail call error path, index out of range jited:1 69 PASS test_bpf: test_tail_calls: Summary: 10 PASSED, 0 FAILED, [10/10 JIT'ed] Suggested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Fixes: 51c66ad ("powerpc/bpf: Implement extended BPF on PPC32") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/757acccb7fbfc78efa42dcf3c974b46678198905.1669278887.git.christophe.leroy@csgroup.eu Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

…nslate the same key [ Upstream commit 5476fcf ] The hid-apple driver does not support chaining translations or dependencies on other translations. This creates two problems: 1 - In Non-English keyboards of Macs, KEY_102ND and KEY_GRAVE are swapped and the APPLE_ISO_TILDE_QUIRK is used to work around this problem. The quirk is not set for the Macs where these bugs happen yet (see the 2nd patch for that), but this can be forced by setting the iso_layout parameter. Unfortunately, this only partially works. KEY_102ND gets translated to KEY_GRAVE, but KEY_GRAVE does not get translated to KEY_102ND, so both of them end up functioning as KEY_GRAVE. This is because the driver translates the keys as if Fn was pressed and the original is sent if it is not pressed, without any further translations happening on the key[torvalds#463]. KEY_GRAVE is present at macbookpro_no_esc_fn_keys[torvalds#195], so this is what happens: - KEY_GRAVE -> KEY_ESC (as if Fn is pressed) - KEY_GRAVE is returned (Fn isn't pressed, so translation is discarded) - KEY_GRAVE -> KEY_102ND (this part is not reached!) ... 2 - In case the touchbar does not work, the driver supports sending Escape when Fn+KEY_GRAVE is pressed. As mentioned previously, KEY_102ND is actually KEY_GRAVE and needs to be translated before this happens. Normally, these are the steps that should happen: - KEY_102ND -> KEY_GRAVE - KEY_GRAVE -> KEY_ESC (Fn is pressed) - KEY_ESC is returned Though this is what happens instead, as dependencies on other translations are not supported: - KEY_102ND -> KEY_ESC (Fn is pressed) - KEY_ESC is returned This patch fixes both bugs by ordering the translations correctly and by making the translations continue and not return immediately after translating a key so that chained translations work and translations can depend on other ones. This patch also simplifies the implementation of the swap_fn_leftctrl option a little bit, as it makes it simply use a normal translation instead adding extra code to translate a key to KEY_FN[torvalds#381]. This change wasn't put in another patch as the code that translates the Fn key needs to be changed because of the changes in the patch, and those changes would be discarded with the next patch anyway (the part that originally translates KEY_FN to KEY_LEFTCTRL needs to be made an else-if branch of the part that transltes KEY_LEFTCTRL to KEY_FN). Note: Line numbers (#XYZ) are for drivers/hid/hid-apple.c at commit 20afcc4 ("HID: apple: Add "GANSS" to the non-Apple list"). Note: These bugs are only present on Macs with a keyboard with no dedicated escape key and a non-English layout. Signed-off-by: Kerem Karabay <kekrby@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>

Changes: * Fix the issue that cannot boot properly when RPI LCD is not connected. Signed-off-by: Stephen Chen <stephen@radxa.com>

Test push

cd00fd0

checkpatch compatible wanning

e32495d

fireshots closed this Jul 21, 2015

fireshots deleted the hotfixes/patched branch July 21, 2015 04:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Test push #195

Test push #195

fireshots commented Jul 20, 2015

ecnepsnai commented Jul 21, 2015

fireshots commented Jul 21, 2015

Test push #195

Test push #195

Conversation

fireshots commented Jul 20, 2015

ecnepsnai commented Jul 21, 2015

fireshots commented Jul 21, 2015