summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-03-21platform/x86: dell-wmi-sysman: Make sysman_init() return -ENODEV of the ↵Hans de Goede
interfaces are not found When either the attributes or the password interface is not found, then unregister the 2 wmi drivers again and return -ENODEV from sysman_init(). Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Reported-by: Alexander Naumann <alexandernaumann@gmx.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-7-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Cleanup sysman_init() error-exit handlingHans de Goede
Cleanup sysman_init() error-exit handling: 1. There is no need for the fail_reset_bios and fail_authentication_kset eror-exit cases, these can be handled by release_attributes_data() 2. Rename all the labels from fail_what_failed, to err_what_to_cleanup this is the usual way to name these and avoids the need to rename them when extra steps are added. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-6-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Fix release_attributes_data() getting called ↵Hans de Goede
twice on init_bios_attributes() failure All calls of init_bios_attributes() will result in a goto fail_create_group if they fail, which calls release_attributes_data(). So there is no need to call release_attributes_data() from init_bios_attributes() on failure itself. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-5-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Make it safe to call exit_foo_attributes() ↵Hans de Goede
multiple times During some of the error-exit paths it is possible that release_attributes_data() will get called multiple times, which results in exit_foo_attributes() getting called multiple times. Make it safe to call exit_foo_attributes() multiple times, avoiding double-free()s in this case. Note that release_attributes_data() really should only be called once during error-exit paths. This will be fixed in a separate patch and it is good to have the exit_foo_attributes() functions modified this way regardless. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-4-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Fix possible NULL pointer deref on exitHans de Goede
It is possible for release_attributes_data() to get called when the main_dir_kset has not been created yet, move the removal of the bios-reset sysfs attr to under a if (main_dir_kset) check to avoid a NULL pointer deref. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Reported-by: Alexander Naumann <alexandernaumann@gmx.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-3-hdegoede@redhat.com
2021-03-21platform/x86: dell-wmi-sysman: Fix crash caused by calling kset_unregister twiceHans de Goede
On some system the WMI GUIDs used by dell-wmi-sysman are present but there are no enum type attributes, this causes init_bios_attributes() to return -ENODEV, after which sysman_init() does a "goto fail_create_group" and then calls release_attributes_data(). release_attributes_data() calls kset_unregister(wmi_priv.main_dir_kset); but before this commit it was missing a "wmi_priv.main_dir_kset = NULL;" statement; and after calling release_attributes_data() the sysman_init() error handling does this: if (wmi_priv.main_dir_kset) { kset_unregister(wmi_priv.main_dir_kset); wmi_priv.main_dir_kset = NULL; } Which causes a second kset_unregister(wmi_priv.main_dir_kset), leading to a double-free, which causes a crash. Add the missing "wmi_priv.main_dir_kset = NULL;" statement to release_attributes_data() to fix this double-free crash. Fixes: e8a60aa7404b ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems") Cc: Divya Bharathi <Divya_Bharathi@dell.com> Cc: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321115901.35072-2-hdegoede@redhat.com
2021-03-21platform/x86: thinkpad_acpi: Disable DYTC CQL mode around switching to ↵Hans de Goede
balanced mode Testing has shown that setting /sys/firmware/acpi/platform_profile to "balanced" when /sys/bus/platform/devices/thinkpad_acpi/dytc_lapmode reports 1, causes dytc_lapmode to get reset to 0 and then it becomes stuck at 0 for aprox. 30 minutes even if the laptop is used on a lap. Disabling CQL (when enabled) before issuing the DYTC_CMD_RESET to get back to balanced mode and re-enabling it afterwards again, like the code already does when switching to low-power / performance mode fixes this. Fixes: c3bfcd4c6762 ("platform/x86: thinkpad_acpi: Add platform profile support") Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210321113108.7069-1-hdegoede@redhat.com
2021-03-21platform/x86: thinkpad_acpi: Allow the FnLock LED to change stateEsteve Varela Colominas
On many recent ThinkPad laptops, there's a new LED next to the ESC key, that indicates the FnLock status. When the Fn+ESC combo is pressed, FnLock is toggled, which causes the Media Key functionality to change, making it so that the media keys either perform their media key function, or function as an F-key by default. The Fn key can be used the access the alternate function at any time. With the current linux kernel, the LED doens't change state if you press the Fn+ESC key combo. However, the media key functionality *does* change. This is annoying, since the LED will stay on if it was on during bootup, and it makes it hard to keep track what the current state of the FnLock is. This patch calls an ACPI function, that gets the current media key state, when the Fn+ESC key combo is pressed. Through testing it was discovered that this function causes the LED to update correctly to reflect the current state when this function is called. The relevant ACPI calls are the following: \_SB_.PCI0.LPC0.EC0_.HKEY.GMKS: Get media key state, returns 0x603 if the FnLock mode is enabled, and 0x602 if it's disabled. \_SB_.PCI0.LPC0.EC0_.HKEY.SMKS: Set media key state, sending a 1 will enable FnLock mode, and a 0 will disable it. Relevant discussion: https://bugzilla.kernel.org/show_bug.cgi?id=207841 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1881015 Signed-off-by: Esteve Varela Colominas <esteve.varela@gmail.com> Link: https://lore.kernel.org/r/20210315195823.23212-1-esteve.varela@gmail.com Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-03-21io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with ↵Stefan Metzmacher
MSG_WAITALL Without that it's not safe to use them in a linked combination with others. Now combinations like IORING_OP_SENDMSG followed by IORING_OP_SPLICE should be possible. We already handle short reads and writes for the following opcodes: - IORING_OP_READV - IORING_OP_READ_FIXED - IORING_OP_READ - IORING_OP_WRITEV - IORING_OP_WRITE_FIXED - IORING_OP_WRITE - IORING_OP_SPLICE - IORING_OP_TEE Now we have it for these as well: - IORING_OP_SENDMSG - IORING_OP_SEND - IORING_OP_RECVMSG - IORING_OP_RECV For IORING_OP_RECVMSG we also check for the MSG_TRUNC and MSG_CTRUNC flags in order to call req_set_fail_links(). There might be applications arround depending on the behavior that even short send[msg]()/recv[msg]() retuns continue an IOSQE_IO_LINK chain. It's very unlikely that such applications pass in MSG_WAITALL, which is only defined in 'man 2 recvmsg', but not in 'man 2 sendmsg'. It's expected that the low level sock_sendmsg() call just ignores MSG_WAITALL, as MSG_ZEROCOPY is also ignored without explicitly set SO_ZEROCOPY. We also expect the caller to know about the implicit truncation to MAX_RW_COUNT, which we don't detect. cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/c4e1a4cc0d905314f4d5dc567e65a7b09621aab3.1615908477.git.metze@samba.org Signed-off-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-21io-wq: ensure task is running before processing task_workJens Axboe
Mark the current task as running if we need to run task_work from the io-wq threads as part of work handling. If that is the case, then return as such so that the caller can appropriately loop back and reset if it was part of a going-to-sleep flush. Fixes: 3bfe6106693b ("io-wq: fork worker threads from original task") Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-21signal: don't allow STOP on PF_IO_WORKER threadsEric W. Biederman
Just like we don't allow normal signals to IO threads, don't deliver a STOP to a task that has PF_IO_WORKER set. The IO threads don't take signals in general, and have no means of flushing out a stop either. Longer term, we may want to look into allowing stop of these threads, as it relates to eg process freezing. For now, this prevents a spin issue if a SIGSTOP is delivered to the parent task. Reported-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
2021-03-21signal: don't allow sending any signals to PF_IO_WORKER threadsJens Axboe
They don't take signals individually, and even if they share signals with the parent task, don't allow them to be delivered through the worker thread. Linux does allow this kind of behavior for regular threads, but it's really a compatability thing that we need not care about for the IO threads. Reported-by: Stefan Metzmacher <metze@samba.org> Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-03-21staging: vchiq: Typo fixesBhaskar Chowdhury
s/sepecific/specific/ s/comonent/component/ Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Link: https://lore.kernel.org/r/20210321043629.585758-1-unixbhaskar@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-21ext4: initialize ret to suppress smatch warningTheodore Ts'o
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: stop inode update before returnPan Bian
The inode update should be stopped before returing the error code. Signed-off-by: Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/20210117085732.93788-1-bianpan2016@163.com Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Cc: stable@kernel.org Reviewed-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: fix rename whiteout with fast commitHarshad Shirwadkar
This patch adds rename whiteout support in fast commits. Note that the whiteout object that gets created is actually char device. Which imples, the function ext4_inode_journal_mode(struct inode *inode) would return "JOURNAL_DATA" for this inode. This has a consequence in fast commit code that it will make creation of the whiteout object a fast-commit ineligible behavior and thus will fall back to full commits. With this patch, this can be observed by running fast commits with rename whiteout and seeing the stats generated by ext4_fc_stats tracepoint as follows: ext4_fc_stats: dev 254:32 fc ineligible reasons: XATTR:0, CROSS_RENAME:0, JOURNAL_FLAG_CHANGE:0, NO_MEM:0, SWAP_BOOT:0, RESIZE:0, RENAME_DIR:0, FALLOC_RANGE:0, INODE_JOURNAL_DATA:16; num_commits:6, ineligible: 6, numblks: 3 So in short, this patch guarantees that in case of rename whiteout, we fall back to full commits. Amir mentioned that instead of creating a new whiteout object for every rename, we can create a static whiteout object with irrelevant nlink. That will make fast commits to not fall back to full commit. But until this happens, this patch will ensure correctness by falling back to full commits. Fixes: 8016e29f4362 ("ext4: fast commit recovery path") Cc: stable@kernel.org Signed-off-by: Harshad Shirwadkar <harshadshirwadkar@gmail.com> Link: https://lore.kernel.org/r/20210316221921.1124955-1-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: fix timer use-after-free on failed mountJan Kara
When filesystem mount fails because of corrupted filesystem we first cancel the s_err_report timer reminding fs errors every day and only then we flush s_error_work. However s_error_work may report another fs error and re-arm timer thus resulting in timer use-after-free. Fix the problem by first flushing the work and only after that canceling the s_err_report timer. Reported-by: syzbot+628472a2aac693ab0fcd@syzkaller.appspotmail.com Fixes: 2d01ddc86606 ("ext4: save error info to sb through journal if available") CC: stable@vger.kernel.org Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20210315165906.2175-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: fix potential error in ext4_do_update_inodeShijie Luo
If set_large_file = 1 and errors occur in ext4_handle_dirty_metadata(), the error code will be overridden, go to out_brelse to avoid this situation. Signed-off-by: Shijie Luo <luoshijie1@huawei.com> Link: https://lore.kernel.org/r/20210312065051.36314-1-luoshijie1@huawei.com Cc: stable@kernel.org Reviewed-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: do not try to set xattr into ea_inode if value is emptyzhangyi (F)
Syzbot report a warning that ext4 may create an empty ea_inode if set an empty extent attribute to a file on the file system which is no free blocks left. WARNING: CPU: 6 PID: 10667 at fs/ext4/xattr.c:1640 ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640 ... Call trace: ext4_xattr_set_entry+0x10f8/0x1114 fs/ext4/xattr.c:1640 ext4_xattr_block_set+0x1d0/0x1b1c fs/ext4/xattr.c:1942 ext4_xattr_set_handle+0x8a0/0xf1c fs/ext4/xattr.c:2390 ext4_xattr_set+0x120/0x1f0 fs/ext4/xattr.c:2491 ext4_xattr_trusted_set+0x48/0x5c fs/ext4/xattr_trusted.c:37 __vfs_setxattr+0x208/0x23c fs/xattr.c:177 ... Now, ext4 try to store extent attribute into an external inode if ext4_xattr_block_set() return -ENOSPC, but for the case of store an empty extent attribute, store the extent entry into the extent attribute block is enough. A simple reproduce below. fallocate test.img -l 1M mkfs.ext4 -F -b 2048 -O ea_inode test.img mount test.img /mnt dd if=/dev/zero of=/mnt/foo bs=2048 count=500 setfattr -n "user.test" /mnt/foo Reported-by: syzbot+98b881fdd8ebf45ab4ae@syzkaller.appspotmail.com Fixes: 9c6e7853c531 ("ext4: reserve space for xattr entries/names") Cc: stable@kernel.org Signed-off-by: zhangyi (F) <yi.zhang@huawei.com> Link: https://lore.kernel.org/r/20210305120508.298465-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: do not iput inode under running transaction in ext4_rename()zhangyi (F)
In ext4_rename(), when RENAME_WHITEOUT failed to add new entry into directory, it ends up dropping new created whiteout inode under the running transaction. After commit <9b88f9fb0d2> ("ext4: Do not iput inode under running transaction"), we follow the assumptions that evict() does not get called from a transaction context but in ext4_rename() it breaks this suggestion. Although it's not a real problem, better to obey it, so this patch add inode to orphan list and stop transaction before final iput(). Signed-off-by: zhangyi (F) <yi.zhang@huawei.com> Link: https://lore.kernel.org/r/20210303131703.330415-2-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-21ext4: find old entry again if failed to rename whiteoutzhangyi (F)
If we failed to add new entry on rename whiteout, we cannot reset the old->de entry directly, because the old->de could have moved from under us during make indexed dir. So find the old entry again before reset is needed, otherwise it may corrupt the filesystem as below. /dev/sda: Entry '00000001' in ??? (12) has deleted/unused inode 15. CLEARED. /dev/sda: Unattached inode 75 /dev/sda: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY. Fixes: 6b4b8e6b4ad ("ext4: fix bug for rename with RENAME_WHITEOUT") Cc: stable@vger.kernel.org Signed-off-by: zhangyi (F) <yi.zhang@huawei.com> Link: https://lore.kernel.org/r/20210303131703.330415-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
2021-03-20docs: networking: Fix a typoBhaskar Chowdhury
s/subsytem/subsystem/ Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20r8169: fix DMA being used after buffer free if WoL is enabledHeiner Kallweit
IOMMU errors have been reported if WoL is enabled and interface is brought down. It turned out that the network chip triggers DMA transfers after the DMA buffers have been freed. For WoL to work we need to leave rx enabled, therefore simply stop the chip from being a DMA busmaster. Fixes: 567ca57faa62 ("r8169: add rtl8169_up") Tested-by: Paul Blazejowski <paulb@blazebox.homeip.net> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20Merge tag 'linux-can-fixes-for-5.12-20210320' of ↵David S. Miller
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-03-20 this is a pull request of 2 patches for net/master. The first patch is by Oliver Hartkopp. He fixes the TX-path in the ISO-TP protocol by properly initializing the outgoing CAN frames. The second patch is by me and reverts a patch from my previous pull request which added MODULE_SUPPORTED_DEVICE to the peak_usb driver. In the mean time in Linus's tree the entirely MODULE_SUPPORTED_DEVICE was removed. So this reverts the adding of the new MODULE_SUPPORTED_DEVICE to avoid the merge conflict. If you prefer to resolve the merge conflict by hand, I'll send a new pull request without that patch. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20Merge branch 'pa-fox-validation'David S. Miller
Alex Elder says: ==================== ipa: fix validation There is sanity checking code in the IPA driver that's meant to be enabled only during development. This allows the driver to make certain assumptions, but not have to verify those assumptions are true at (operational) runtime. This code is built conditional on IPA_VALIDATION, set (if desired) inside the IPA makefile. Unfortunately, this validation code has some errors. First, there are some mismatched arguments supplied to some dev_err() calls in ipa_cmd_table_valid() and ipa_cmd_header_valid(), and these are exposed if validation is enabled. Second, the tag that enables this conditional code isn't used consistently (it's IPA_VALIDATE in some spots and IPA_VALIDATION in others). This series fixes those two problems with the conditional validation code. Version 2 removes the two patches that introduced ipa_assert(). It also modifies the description in the first patch so that it mentions the changes made to ipa_cmd_table_valid(). ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20net: ipa: fix init header command validationAlex Elder
We use ipa_cmd_header_valid() to ensure certain values we will program into hardware are within range, well in advance of when we actually program them. This way we avoid having to check for errors when we actually program the hardware. Unfortunately the dev_err() call for a bad offset value does not supply the arguments to match the format specifiers properly. Fix this. There was also supposed to be a check to ensure the size to be programmed fits in the field that holds it. Add this missing check. Rearrange the way we ensure the header table fits in overall IPA memory range. Finally, update ipa_cmd_table_valid() so the format of messages printed for errors matches what's done in ipa_cmd_header_valid(). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-21genirq: Disable interrupts for force threaded handlersThomas Gleixner
With interrupt force threading all device interrupt handlers are invoked from kernel threads. Contrary to hard interrupt context the invocation only disables bottom halfs, but not interrupts. This was an oversight back then because any code like this will have an issue: thread(irq_A) irq_handler(A) spin_lock(&foo->lock); interrupt(irq_B) irq_handler(B) spin_lock(&foo->lock); This has been triggered with networking (NAPI vs. hrtimers) and console drivers where printk() happens from an interrupt which interrupted the force threaded handler. Now people noticed and started to change the spin_lock() in the handler to spin_lock_irqsave() which affects performance or add IRQF_NOTHREAD to the interrupt request which in turn breaks RT. Fix the root cause and not the symptom and disable interrupts before invoking the force threaded handler which preserves the regular semantics and the usefulness of the interrupt force threading as a general debugging tool. For not RT this is not changing much, except that during the execution of the threaded handler interrupts are delayed until the handler returns. Vs. scheduling and softirq processing there is no difference. For RT kernels there is no issue. Fixes: 8d32a307e4fa ("genirq: Provide forced interrupt threading") Reported-by: Johan Hovold <johan@kernel.org> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Johan Hovold <johan@kernel.org> Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://lore.kernel.org/r/20210317143859.513307808@linutronix.de
2021-03-20Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller
Alexei Starovoitov says: ==================== pull-request: bpf 2021-03-20 The following pull-request contains BPF updates for your *net* tree. We've added 5 non-merge commits during the last 3 day(s) which contain a total of 8 files changed, 155 insertions(+), 12 deletions(-). The main changes are: 1) Use correct nops in fexit trampoline, from Stanislav. 2) Fix BTF dump, from Jean-Philippe. 3) Fix umd memory leak, from Zqiang. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-03-20can: peak_usb: Revert "can: peak_usb: add forgotten supported devices"Marc Kleine-Budde
In commit 6417f03132a6 ("module: remove never implemented MODULE_SUPPORTED_DEVICE") the MODULE_SUPPORTED_DEVICE macro was removed from the kerne entirely. Shortly before this patch was applied mainline the commit 59ec7b89ed3e ("can: peak_usb: add forgotten supported devices") was added to net/master. As this would result in a merge conflict, let's revert this patch. Fixes: 59ec7b89ed3e ("can: peak_usb: add forgotten supported devices") Link: https://lore.kernel.org/r/20210320192649.341832-1-mkl@pengutronix.de Suggested-by: Leon Romanovsky <leon@kernel.org> Cc: Stephane Grosjean <s.grosjean@peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-20can: isotp: tx-path: zero initialize outgoing CAN framesOliver Hartkopp
Commit d4eb538e1f48 ("can: isotp: TX-path: ensure that CAN frame flags are initialized") ensured the TX flags to be properly set for outgoing CAN frames. In fact the root cause of the issue results from a missing initialization of outgoing CAN frames created by isotp. This is no problem on the CAN bus as the CAN driver only picks the correctly defined content from the struct can(fd)_frame. But when the outgoing frames are monitored (e.g. with candump) we potentially leak some bytes in the unused content of struct can(fd)_frame. Fixes: e057dd3fc20f ("can: add ISO 15765-2:2016 transport protocol") Cc: Marc Kleine-Budde <mkl@pengutronix.de> Link: https://lore.kernel.org/r/20210319100619.10858-1-socketcan@hartkopp.net Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-03-20Merge tag 'riscv-for-linus-5.12-rc4' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: "A handful of fixes for 5.12: - fix the SBI remote fence numbers for hypervisor fences, which had been transcribed in the wrong order in Linux. These fences are only used with the KVM patches applied. - fix a whole host of build warnings, these should have no functional change. - fix init_resources() to prevent an off-by-one error from causing an out-of-bounds array reference. This was manifesting during boot on vexriscv. - ensure the KASAN mappings are visible before proceeding to use them" * tag 'riscv-for-linus-5.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Correct SPARSEMEM configuration RISC-V: kasan: Declare kasan_shallow_populate() static riscv: Ensure page table writes are flushed when initializing KASAN vmalloc RISC-V: Fix out-of-bounds accesses in init_resources() riscv: Fix compilation error with Canaan SoC ftrace: Fix spelling mistake "disabed" -> "disabled" riscv: fix bugon.cocci warnings riscv: process: Fix no prototype for arch_dup_task_struct riscv: ftrace: Use ftrace_get_regs helper riscv: process: Fix no prototype for show_regs riscv: syscall_table: Reduce W=1 compilation warnings noise riscv: time: Fix no prototype for time_init riscv: ptrace: Fix no prototype warnings riscv: sbi: Fix comment of __sbi_set_timer_v01 riscv: irq: Fix no prototype warning riscv: traps: Fix no prototype warnings RISC-V: correct enum sbi_ext_rfence_fid
2021-03-20Merge tag '5.12-rc3-smb3' of git://git.samba.org/sfrench/cifs-2.6Linus Torvalds
Pull cifs fixes from Steve French: "Five cifs/smb3 fixes - three for stable, including an important ACL fix and security signature fix" * tag '5.12-rc3-smb3' of git://git.samba.org/sfrench/cifs-2.6: cifs: fix allocation size on newly created files cifs: warn and fail if trying to use rootfs without the config option fs/cifs/: fix misspellings using codespell tool cifs: Fix preauth hash corruption cifs: update new ACE pointer after populate_new_aces.
2021-03-20Merge tag 'scsi-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Eight fixes, all in drivers, all fairly minor either being fixes in error legs, memory leaks on teardown, context errors or semantic problems" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: mpt3sas: Do not use GFP_KERNEL in atomic context scsi: ufs: ufs-mediatek: Correct operator & -> && scsi: sd_zbc: Update write pointer offset cache scsi: lpfc: Fix some error codes in debugfs scsi: qla2xxx: Fix broken #endif placement scsi: st: Fix a use after free in st_open() scsi: myrs: Fix a double free in myrs_cleanup() scsi: ibmvfc: Free channel_setup_buf during device tear down
2021-03-20staging: wimax: delete from the tree.Greg Kroah-Hartman
As stated in f54ec58fee83 ("wimax: move out to staging"), the wimax code is dead with no known users. It has stayed in staging for 5 months, with no one willing to take up the codebase for maintance and support, so let's just remove it entirely for now. If someone comes along and wants to revive it, a simple revert of this patch is a good place to start. Cc: Jakub Kicinski <kuba@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org> Cc: Wang Hai <wanghai38@huawei.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: Colin Ian King <colin.king@canonical.com> Cc: Anirudh Rayabharam <mail@anirudhrb.com> Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com> Cc: Hemansh Agnihotri <hemanshagnihotri27@gmail.com> Cc: Ayush <ayush@disroot.org> Cc: Xin Tan <tanxin.ctf@gmail.com> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn> Cc: Shannon Nelson <snelson@pensando.io> Link: https://lore.kernel.org/r/20210318093315.694404-1-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8188eu: Removed Unnecessary loggingPaul McQuade
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace Signed-off-by: Paul McQuade <paulmcquad@gmail.com> Link: https://lore.kernel.org/r/20210319144206.23439-1-paulmcquad@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8712: Fix a possible NULL pointer dereference in function ↵Lee Gibson
r8712_joinbss_event_callback GCC 10 analyzer reports a warning: dereference of NULL The function r8712_find_network can return NULL and is usually checked but no check is present is this case. Fix by adding the check. Signed-off-by: Lee Gibson <leegib@gmail.com> Link: https://lore.kernel.org/r/20210319085836.8259-1-leegib@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in os_dep/wifi_regd.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 153: FILE: drivers/staging/rtl8723bs/os_dep/wifi_regd.c:153: + DBG_8192C("%s\n", __func__); Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-16-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in os_dep/os_intfs.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 977: FILE: drivers/staging/rtl8723bs/os_dep/os_intfs.c:977: + DBG_871X("===> %s.........\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1030: FILE: drivers/staging/rtl8723bs/os_dep/os_intfs.c:1030: + DBG_871X("====> %s...\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1127: FILE: drivers/staging/rtl8723bs/os_dep/os_intfs.c:1127: + DBG_871X("===> %s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1177: FILE: drivers/staging/rtl8723bs/os_dep/os_intfs.c:1177: + DBG_871X("<=== %s\n", __func__); Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-15-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in os_dep/ioctl_linux.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1207: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:1207: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1507: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:1507: + DBG_871X("=>%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 3390: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:3390: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 3687: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:3687: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 4143: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:4143: + /* DBG_871X("%s\n", __func__); */ Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-14-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in hal/rtl8723b_hal_init.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1685: FILE: drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c:1685: +/* DBG_8192C("%s\n", __func__); */ -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1722: FILE: drivers/staging/rtl8723bs/hal/rtl8723b_hal_init.c:1722: +/* DBG_8192C("%s\n", __func__); */ Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-12-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in hal/odm_debug.hFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 134: FILE: drivers/staging/rtl8723bs/hal/odm_debug.h:134: +#define ODM_dbg_enter() { DbgPrint("==> %s\n", __func__); } -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 135: FILE: drivers/staging/rtl8723bs/hal/odm_debug.h:135: +#define ODM_dbg_exit() { DbgPrint("<== %s\n", __func__); } and removed containing unused macros Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-10-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in hal/odm.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1109: FILE: drivers/staging/rtl8723bs/hal/odm.c:1109: + /* printk("==> %s\n", __func__); */ Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-9-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in hal/hal_com_phycfg.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 201: FILE: drivers/staging/rtl8723bs/hal/hal_com_phycfg.c:201: + /* DBG_871X("===>%s\n", __func__); */ -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 265: FILE: drivers/staging/rtl8723bs/hal/hal_com_phycfg.c:265: + /* DBG_871X("<===%s\n", __func__); */ Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-8-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in hal/HalBtcOutSrc.hFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 126: FILE: drivers/staging/rtl8723bs/hal/HalBtcOutSrc.h:126: + DbgPrint("%s(): ", __func__);\ and remove the whole unused containing macro BTC_PRINT_F Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-7-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in core/rtw_wlan_util.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1140: FILE: drivers/staging/rtl8723bs/core/rtw_wlan_util.c:1140: + DBG_871X("%s\n", __func__); Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-6-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in core/rtw_pwrctrl.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 185: FILE: drivers/staging/rtl8723bs/core/rtw_pwrctrl.c:185: + DBG_871X("==>%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 606: FILE: drivers/staging/rtl8723bs/core/rtw_pwrctrl.c:606: + DBG_871X("%s.....\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 753: FILE: drivers/staging/rtl8723bs/core/rtw_pwrctrl.c:753: + /* DBG_871X("%s\n", __func__); */ Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-5-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in core/rtw_mlme_ext.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 987: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:987: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1115: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:1115: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1547: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:1547: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1760: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:1760: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1813: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:1813: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 2340: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:2340: + /* DBG_871X("%s\n", __func__); */ -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 2499: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:2499: + /* DBG_871X("%s\n", __func__); */ -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 2948: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:2948: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 2969: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:2969: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 3445: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:3445: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 3677: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:3677: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 3915: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:3915: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 4599: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:4599: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 5355: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:5355: + DBG_871X("=>%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 5366: FILE: drivers/staging/rtl8723bs/core/rtw_mlme_ext.c:5366: + DBG_871X("%s\n", __func__); Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-4-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in core/rtw_mlme.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1134: FILE: drivers/staging/rtl8723bs/core/rtw_mlme.c:1134: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1223: FILE: drivers/staging/rtl8723bs/core/rtw_mlme.c:1223: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1528: FILE: drivers/staging/rtl8723bs/core/rtw_mlme.c:1528: + DBG_871X("%s\n", __func__); Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-3-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in core/rtw_ap.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 66: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:66: + /* DBG_871X("%s\n", __func__); */ -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 559: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:559: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 716: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:716: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 770: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:770: + /* DBG_871X("%s\n", __func__); */ -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1476: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1476: + /* DBG_871X("%s\n", __func__); */ -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1531: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1531: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1557: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1557: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1564: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1564: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1609: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1609: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1614: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1614: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1619: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1619: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1624: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1624: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1629: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1629: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1647: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1647: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1716: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1716: + DBG_871X("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1740: FILE: drivers/staging/rtl8723bs/core/rtw_ap.c:1740: + /* DBG_871X("%s\n", __func__); */ Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210318152610.16758-2-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20staging: rtl8723bs: remove unnecessary logging in os_dep/ioctl_cfg80211.cFabio Aiuto
fix the following checkpatch.pl issues: WARNING: Unnecessary ftrace-like logging - prefer using ftrace 239: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:239: + /* DBG_8192C("%s\n", __func__); */ -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 569: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:569: + DBG_8192C("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 854: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:854: + DBG_8192C("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1408: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:1408: + DBG_8192C("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 1645: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:1645: + DBG_8192C("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 2222: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2222: + DBG_8192C("%s\n", __func__); -- WARNING: Unnecessary ftrace-like logging - prefer using ftrace 2230: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:2230: + DBG_8192C("%s\n", __func__); Changes in v2: removed empty #ifdef block Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/20210319100923.4314-1-fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-22 01:53:46 +0000