Searched hist:4198 (Results 1 - 16 of 16) sorted by relevance
/linux-master/drivers/net/ethernet/stmicro/stmmac/ | ||
H A D | dwmac-sunxi.c | diff 4198b7db Wed May 13 16:11:05 MDT 2015 Joachim Eastwood <manabian@gmail.com> stmmac: convert dwmac-sunxi to platform driver Convert platform glue layer into a proper platform driver and add it to the build system. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | stmmac_platform.h | diff 4198b7db Wed May 13 16:11:05 MDT 2015 Joachim Eastwood <manabian@gmail.com> stmmac: convert dwmac-sunxi to platform driver Convert platform glue layer into a proper platform driver and add it to the build system. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | Makefile | diff 4198b7db Wed May 13 16:11:05 MDT 2015 Joachim Eastwood <manabian@gmail.com> stmmac: convert dwmac-sunxi to platform driver Convert platform glue layer into a proper platform driver and add it to the build system. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | Kconfig | diff 4198b7db Wed May 13 16:11:05 MDT 2015 Joachim Eastwood <manabian@gmail.com> stmmac: convert dwmac-sunxi to platform driver Convert platform glue layer into a proper platform driver and add it to the build system. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
H A D | stmmac_platform.c | diff 4198b7db Wed May 13 16:11:05 MDT 2015 Joachim Eastwood <manabian@gmail.com> stmmac: convert dwmac-sunxi to platform driver Convert platform glue layer into a proper platform driver and add it to the build system. Signed-off-by: Joachim Eastwood <manabian@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
/linux-master/drivers/char/hw_random/ | ||
H A D | mxc-rnga.c | diff a9ccb7bd Tue Sep 04 15:35:21 MDT 2012 Fabio Estevam <fabio.estevam@freescale.com> hwrng: mxc-rnga - Adapt clocks to new i.mx clock framework Adapt clocks to the new i.mx clock framework and fix the following warning: ------------[ cut here ]------------ WARNING: at drivers/clk/clk.c:511 __clk_enable+0x9c/0xac() Modules linked in: Backtrace: [<800124c8>] (dump_backtrace+0x0/0x10c) from [<804172dc>] (dump_stack+0x18/0x1c) r7:00000009 r6:000001ff r5:8032cb50 r4:00000000 [<804172c4>] (dump_stack+0x0/0x1c) from [<80021834>] (warn_slowpath_common+0x54) [<800217e0>] (warn_slowpath_common+0x0/0x6c) from [<80021870>] (warn_slowpath_n) r9:80581cac r8:8700a9c0 r7:805ab070 r6:80000013 r5:806133d4 r4:8700a9c0 [<8002184c>] (warn_slowpath_null+0x0/0x2c) from [<8032cb50>] (__clk_enable+0x9c) [<8032cab4>] (__clk_enable+0x0/0xac) from [<8032cb88>] (clk_enable+0x28/0x44) r5:806133d4 r4:8700a9c0 [<8032cb60>] (clk_enable+0x0/0x44) from [<80560f14>] (mxc_rnga_probe+0x68/0x164) r7:805ab070 r6:8706ec00 r5:80611314 r4:00000000 [<80560eac>] (mxc_rnga_probe+0x0/0x164) from [<8025914c>] (platform_drv_probe+0) [<8025912c>] (platform_drv_probe+0x0/0x24) from [<80257c7c>] (driver_probe_devi) [<80257bfc>] (driver_probe_device+0x0/0x204) from [<80257e94>] (__driver_attach) r9:80581cac r8:0000008e r7:00000000 r6:8706ec3c r5:805ab070 r4:8706ec08 [<80257e00>] (__driver_attach+0x0/0x98) from [<8025642c>] (bus_for_each_dev+0x6) r7:00000000 r6:80257e00 r5:87035e98 r4:805ab070 [<802563c4>] (bus_for_each_dev+0x0/0x94) from [<80257adc>] (driver_attach+0x20/) r7:00000000 r6:873f2380 r5:805ab338 r4:805ab070 [<80257abc>] (driver_attach+0x0/0x28) from [<80256d50>] (bus_add_driver+0x18c/0) [<80256bc4>] (bus_add_driver+0x0/0x268) from [<802584c4>] (driver_register+0x80) [<80258444>] (driver_register+0x0/0x134) from [<802594f4>] (platform_driver_reg) r7:00000000 r6:805c2e00 r5:00000007 r4:805ab05c [<802594a8>] (platform_driver_register+0x0/0x60) from [<80259528>] (platform_dr) [<80259508>] (platform_driver_probe+0x0/0xa4) from [<80560ea0>] (mod_init+0x18/) r7:00000000 r6:805c2e00 r5:00000007 r4:87034000 [<80560e88>] (mod_init+0x0/0x24) from [<800086b4>] (do_one_initcall+0x40/0x194) [<80008674>] (do_one_initcall+0x0/0x194) from [<8053d3f4>] (kernel_init+0xfc/0x) [<8053d2f8>] (kernel_init+0x0/0x1cc) from [<80027190>] (do_exit+0x0/0x7ec) ---[ end trace 4198eed02050f461 ]--- Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> |
/linux-master/drivers/char/tpm/ | ||
H A D | tpm_crb.c | diff e1ec650f Thu Jul 06 11:48:39 MDT 2017 Arvind Yadav <arvind.yadav.cs@gmail.com> tpm: tpm_crb: constify acpi_device_id. acpi_device_id are not supposed to change at runtime. All functions working with acpi_device_id provided by <acpi/acpi_bus.h> work with const acpi_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 4198 608 0 4806 12c6 drivers/char/tpm/tpm_crb.o File size After adding 'const': text data bss dec hex filename 4262 520 0 4782 12ae drivers/char/tpm/tpm_crb.o Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: James Morris <james.l.morris@oracle.com> |
/linux-master/fs/bcachefs/ | ||
H A D | fs-io.c | diff 4198bf03 Thu Aug 03 01:39:49 MDT 2023 Kent Overstreet <kent.overstreet@linux.dev> bcachefs: Fix lock thrashing in __bchfs_fallocate() We've observed significant lock thrashing on fstests generic/083 in fallocate, due to dropping and retaking btree locks when checking the pagecache for data. This adds a nonblocking mode to bch2_clamp_data_hole(), where we only use folio_trylock(), and can thus be used safely while btree locks are held - thus we only have to drop btree locks as a fallback, on actual lock contention. Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev> |
/linux-master/include/linux/ | ||
H A D | videodev2.h | diff f81cf753 Sun Jun 18 13:54:20 MDT 2006 Hans Verkuil <hverkuil@xs4all.nl> V4L/DVB (4198): Avoid newer usages of obsoleted experimental MPEGCOMP API Put old MPEGCOMP API under #if __KERNEL__ and issue warnings when used. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> |
/linux-master/drivers/net/wireless/ath/ath5k/ | ||
H A D | base.c | diff 4198a8d0 Mon Oct 04 22:27:17 MDT 2010 Bruno Randolf <br1@einfach.org> ath5k: Don't wake internal queues We should only wake up queues which mac80211 knows about (queues 0-3). We have another internal queue ("CAB", queue number 6) which we use for power-saved frames. When transmitted frames are processed from this queue, we have to make sure we don't bother mac80211 with waking a queue it doesn't know about. this fixes: WARNING: at /home/br1/ath/wireless-testing/net/mac80211/util.c:275 __ieee80211_wake_queue+0xd6/0xe0 [mac80211]() Signed-off-by: Bruno Randolf <br1@einfach.org> Signed-off-by: John W. Linville <linville@tuxdriver.com> |
/linux-master/drivers/pinctrl/ | ||
H A D | core.c | diff 4198a9b5 Wed Nov 15 03:28:24 MST 2023 Maria Yu <quic_aiquny@quicinc.com> pinctrl: avoid reload of p state in list iteration When in the list_for_each_entry iteration, reload of p->state->settings with a local setting from old_state will turn the list iteration into an infinite loop. The typical symptom when the issue happens, will be a printk message like: "not freeing pin xx (xxx) as part of deactivating group xxx - it is already used for some other setting". This is a compiler-dependent problem, one instance occurred using Clang version 10.0 on the arm64 architecture with linux version 4.19. Fixes: 6e5e959dde0d ("pinctrl: API changes to support multiple states per device") Signed-off-by: Maria Yu <quic_aiquny@quicinc.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20231115102824.23727-1-quic_aiquny@quicinc.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> |
/linux-master/arch/arm/ | ||
H A D | Makefile | diff e4d06e39 Thu Feb 15 16:12:31 MST 2007 Ben Dooks <ben-linux@fluff.org> [ARM] 4198/2: S3C2443: arch/arm/mach-s3c2443 and related support Add arch/arm/mach-s3c2443 for support of the Samsung S3C2443 SoC This patch adds the core CPU support, clock framework, times and initial IRQ support, as well as adding the directory into the build tree. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> |
H A D | Kconfig | diff e4d06e39 Thu Feb 15 16:12:31 MST 2007 Ben Dooks <ben-linux@fluff.org> [ARM] 4198/2: S3C2443: arch/arm/mach-s3c2443 and related support Add arch/arm/mach-s3c2443 for support of the Samsung S3C2443 SoC This patch adds the core CPU support, clock framework, times and initial IRQ support, as well as adding the directory into the build tree. Signed-off-by: Ben Dooks <ben-linux@fluff.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> |
/linux-master/drivers/scsi/ | ||
H A D | scsi_lib.c | diff 8fe8ffb1 Fri Oct 20 12:46:45 MDT 2017 Bart Van Assche <bvanassche@acm.org> scsi: Suppress a kernel warning in case the prep function returns BLKPREP_DEFER The legacy block layer handles requests as follows: - If the prep function returns BLKPREP_OK, let blk_peek_request() return the pointer to that request. - If the prep function returns BLKPREP_DEFER, keep the RQF_STARTED flag and retry calling the prep function later. - If the prep function returns BLKPREP_KILL or BLKPREP_INVALID, end the request. In none of these cases it is correct to clear the SCMD_INITIALIZED flag from inside scsi_prep_fn(). Since scsi_prep_fn() already guarantees that scsi_init_command() will be called once even if scsi_prep_fn() is called multiple times, remove the code that clears SCMD_INITIALIZED from scsi_prep_fn(). The scsi-mq code handles requests as follows: - If scsi_mq_prep_fn() returns BLKPREP_OK, set the RQF_DONTPREP flag and submit the request to the SCSI LLD. - If scsi_mq_prep_fn() returns BLKPREP_DEFER, call blk_mq_delay_run_hw_queue() and return BLK_STS_RESOURCE. - If the prep function returns BLKPREP_KILL or BLKPREP_INVALID, call scsi_mq_uninit_cmd() and let the blk-mq core end the request. In none of these cases scsi_mq_prep_fn() should clear the SCMD_INITIALIZED flag. Hence remove the code from scsi_mq_prep_fn() function that clears that flag. This patch avoids that the following warning is triggered when using the legacy block layer: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4198 at drivers/scsi/scsi_lib.c:654 scsi_end_request+0x1de/0x220 CPU: 1 PID: 4198 Comm: mkfs.f2fs Not tainted 4.14.0-rc5+ #1 task: ffff91c147a4b800 task.stack: ffffb282c37b8000 RIP: 0010:scsi_end_request+0x1de/0x220 Call Trace: <IRQ> scsi_io_completion+0x204/0x5e0 scsi_finish_command+0xce/0xe0 scsi_softirq_done+0x126/0x130 blk_done_softirq+0x6e/0x80 __do_softirq+0xcf/0x2a8 irq_exit+0xab/0xb0 do_IRQ+0x7b/0xc0 common_interrupt+0x90/0x90 </IRQ> RIP: 0010:_raw_spin_unlock_irqrestore+0x9/0x10 __test_set_page_writeback+0xc7/0x2c0 __block_write_full_page+0x158/0x3b0 block_write_full_page+0xc4/0xd0 blkdev_writepage+0x13/0x20 __writepage+0x12/0x40 write_cache_pages+0x204/0x500 generic_writepages+0x48/0x70 blkdev_writepages+0x9/0x10 do_writepages+0x34/0xc0 __filemap_fdatawrite_range+0x6c/0x90 file_write_and_wait_range+0x31/0x90 blkdev_fsync+0x16/0x40 vfs_fsync_range+0x44/0xa0 do_fsync+0x38/0x60 SyS_fsync+0xb/0x10 entry_SYSCALL_64_fastpath+0x13/0x94 ---[ end trace 86e8ef85a4a6c1d1 ]--- Fixes: commit 64104f703212 ("scsi: Call scsi_initialize_rq() for filesystem requests") Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com> Cc: Damien Le Moal <damien.lemoal@wdc.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> diff 8fe8ffb1 Fri Oct 20 12:46:45 MDT 2017 Bart Van Assche <bvanassche@acm.org> scsi: Suppress a kernel warning in case the prep function returns BLKPREP_DEFER The legacy block layer handles requests as follows: - If the prep function returns BLKPREP_OK, let blk_peek_request() return the pointer to that request. - If the prep function returns BLKPREP_DEFER, keep the RQF_STARTED flag and retry calling the prep function later. - If the prep function returns BLKPREP_KILL or BLKPREP_INVALID, end the request. In none of these cases it is correct to clear the SCMD_INITIALIZED flag from inside scsi_prep_fn(). Since scsi_prep_fn() already guarantees that scsi_init_command() will be called once even if scsi_prep_fn() is called multiple times, remove the code that clears SCMD_INITIALIZED from scsi_prep_fn(). The scsi-mq code handles requests as follows: - If scsi_mq_prep_fn() returns BLKPREP_OK, set the RQF_DONTPREP flag and submit the request to the SCSI LLD. - If scsi_mq_prep_fn() returns BLKPREP_DEFER, call blk_mq_delay_run_hw_queue() and return BLK_STS_RESOURCE. - If the prep function returns BLKPREP_KILL or BLKPREP_INVALID, call scsi_mq_uninit_cmd() and let the blk-mq core end the request. In none of these cases scsi_mq_prep_fn() should clear the SCMD_INITIALIZED flag. Hence remove the code from scsi_mq_prep_fn() function that clears that flag. This patch avoids that the following warning is triggered when using the legacy block layer: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 4198 at drivers/scsi/scsi_lib.c:654 scsi_end_request+0x1de/0x220 CPU: 1 PID: 4198 Comm: mkfs.f2fs Not tainted 4.14.0-rc5+ #1 task: ffff91c147a4b800 task.stack: ffffb282c37b8000 RIP: 0010:scsi_end_request+0x1de/0x220 Call Trace: <IRQ> scsi_io_completion+0x204/0x5e0 scsi_finish_command+0xce/0xe0 scsi_softirq_done+0x126/0x130 blk_done_softirq+0x6e/0x80 __do_softirq+0xcf/0x2a8 irq_exit+0xab/0xb0 do_IRQ+0x7b/0xc0 common_interrupt+0x90/0x90 </IRQ> RIP: 0010:_raw_spin_unlock_irqrestore+0x9/0x10 __test_set_page_writeback+0xc7/0x2c0 __block_write_full_page+0x158/0x3b0 block_write_full_page+0xc4/0xd0 blkdev_writepage+0x13/0x20 __writepage+0x12/0x40 write_cache_pages+0x204/0x500 generic_writepages+0x48/0x70 blkdev_writepages+0x9/0x10 do_writepages+0x34/0xc0 __filemap_fdatawrite_range+0x6c/0x90 file_write_and_wait_range+0x31/0x90 blkdev_fsync+0x16/0x40 vfs_fsync_range+0x44/0xa0 do_fsync+0x38/0x60 SyS_fsync+0xb/0x10 entry_SYSCALL_64_fastpath+0x13/0x94 ---[ end trace 86e8ef85a4a6c1d1 ]--- Fixes: commit 64104f703212 ("scsi: Call scsi_initialize_rq() for filesystem requests") Signed-off-by: Bart Van Assche <bart.vanassche@wdc.com> Cc: Damien Le Moal <damien.lemoal@wdc.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> |
/linux-master/fs/ceph/ | ||
H A D | mds_client.c | diff 4198aba4 Thu May 02 06:06:50 MDT 2019 Jeff Layton <jlayton@kernel.org> ceph: fix unaligned access in ceph_send_cap_releases Signed-off-by: Jeff Layton <jlayton@kernel.org> Reviewed-by: "Yan, Zheng" <zyan@redhat.com> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> |
/linux-master/kernel/bpf/ | ||
H A D | btf.c | diff d7e7b42f Thu Feb 03 12:17:27 MST 2022 Yonghong Song <yhs@fb.com> bpf: Fix a btf decl_tag bug when tagging a function syzbot reported a btf decl_tag bug with stack trace below: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 0 PID: 3592 Comm: syz-executor914 Not tainted 5.16.0-syzkaller-11424-gb7892f7d5cb2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:btf_type_vlen include/linux/btf.h:231 [inline] RIP: 0010:btf_decl_tag_resolve+0x83e/0xaa0 kernel/bpf/btf.c:3910 ... Call Trace: <TASK> btf_resolve+0x251/0x1020 kernel/bpf/btf.c:4198 btf_check_all_types kernel/bpf/btf.c:4239 [inline] btf_parse_type_sec kernel/bpf/btf.c:4280 [inline] btf_parse kernel/bpf/btf.c:4513 [inline] btf_new_fd+0x19fe/0x2370 kernel/bpf/btf.c:6047 bpf_btf_load kernel/bpf/syscall.c:4039 [inline] __sys_bpf+0x1cbb/0x5970 kernel/bpf/syscall.c:4679 __do_sys_bpf kernel/bpf/syscall.c:4738 [inline] __se_sys_bpf kernel/bpf/syscall.c:4736 [inline] __x64_sys_bpf+0x75/0xb0 kernel/bpf/syscall.c:4736 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae The kasan error is triggered with an illegal BTF like below: type 0: void type 1: int type 2: decl_tag to func type 3 type 3: func to func_proto type 8 The total number of types is 4 and the type 3 is illegal since its func_proto type is out of range. Currently, the target type of decl_tag can be struct/union, var or func. Both struct/union and var implemented their own 'resolve' callback functions and hence handled properly in kernel. But func type doesn't have 'resolve' callback function. When btf_decl_tag_resolve() tries to check func type, it tries to get vlen of its func_proto type, which triggered the above kasan error. To fix the issue, btf_decl_tag_resolve() needs to do btf_func_check() before trying to accessing func_proto type. In the current implementation, func type is checked with btf_func_check() in the main checking function btf_check_all_types(). To fix the above kasan issue, let us implement 'resolve' callback func type properly. The 'resolve' callback will be also called in btf_check_all_types() for func types. Fixes: b5ea834dde6b ("bpf: Support for new btf kind BTF_KIND_TAG") Reported-by: syzbot+53619be9444215e785ed@syzkaller.appspotmail.com Signed-off-by: Yonghong Song <yhs@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20220203191727.741862-1-yhs@fb.com |
Completed in 2125 milliseconds