linux/drivers/char/ipmi, branch v5.11

char: ipmi: convert comma to semicolon

2020-12-16T13:54:54Z

Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun Message-Id: <20201216132615.15529-1-zhengyongjun3@huawei.com> Signed-off-by: Corey Minyard

ipmi: msghandler: Suppress suspicious RCU usage warning

2020-11-19T12:36:28Z

while running ipmi, ipmi_smi_watcher_register() caused a suspicious RCU usage warning. ----- ============================= WARNING: suspicious RCU usage 5.10.0-rc3+ #1 Not tainted ----------------------------- drivers/char/ipmi/ipmi_msghandler.c:750 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by syz-executor.0/4254: stack backtrace: CPU: 0 PID: 4254 Comm: syz-executor.0 Not tainted 5.10.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/ 01/2014 Call Trace: dump_stack+0x19d/0x200 ipmi_smi_watcher_register+0x2d3/0x340 [ipmi_msghandler] acpi_ipmi_init+0xb1/0x1000 [acpi_ipmi] do_one_initcall+0x149/0x7e0 do_init_module+0x1ef/0x700 load_module+0x3467/0x4140 __do_sys_finit_module+0x10d/0x1a0 do_syscall_64+0x34/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x468ded ----- It is safe because smi_watchers_mutex is locked and srcu_read_lock has been used, so simply pass lockdep_is_held() to the list_for_each_entry_rcu() to suppress this warning. Reported-by: Hulk Robot Signed-off-by: Qinglang Miao Message-Id: <20201119070839.381-1-miaoqinglang@huawei.com> Signed-off-by: Corey Minyard

ipmi/watchdog: replace atomic_add() and atomic_sub()

2020-11-17T12:57:45Z

atomic_inc() and atomic_dec() looks better Signed-off-by: Yejune Deng Message-Id: <1605511807-7135-1-git-send-email-yejune.deng@gmail.com> Signed-off-by: Corey Minyard

char: ipmi: remove unneeded break

2020-10-27T21:08:22Z

A break is not needed if it is preceded by a return Signed-off-by: Tom Rix Message-Id: <20201019194805.14996-1-trix@redhat.com> Signed-off-by: Corey Minyard

Merge tag 'for-linus-5.10-1' of git://github.com/cminyard/linux-ipmi

2020-10-14T22:00:20Z

Pull IPMI updates from Corey Minyard: "Some minor bug fixes, return values, cleanups of prints, conversion of tasklets to the new API. The biggest change is retrying the initial information fetch from the management controller. If that fails, the iterface is not operational, and one group was having trouble with the management controller not being ready when the OS started up. So a retry was added" * tag 'for-linus-5.10-1' of git://github.com/cminyard/linux-ipmi: ipmi_si: Fix wrong return value in try_smi_init() ipmi: msghandler: Fix a signedness bug ipmi: add retry in try_get_dev_id() ipmi: Clean up some printks ipmi:msghandler: retry to get device id on an error ipmi:sm: Print current state when the state is invalid ipmi: Reset response handler when failing to send the command ipmi: add a newline when printing parameter 'panic_op' by sysfs char: ipmi: convert tasklets to use new tasklet_setup() API

ipmi_si: Fix wrong return value in try_smi_init()

2020-10-05T18:30:51Z

On an error exit path, a negative error code should be returned instead of a positive return value. Fixes: 90b2d4f15ff7 ("ipmi_si: Remove hacks for adding a dummy platform devices") Cc: Corey Minyard Signed-off-by: Tianjia Zhang Message-Id: <20201005145212.84435-1-tianjia.zhang@linux.alibaba.com> Signed-off-by: Corey Minyard

ipmi: msghandler: Fix a signedness bug

2020-09-18T21:34:52Z

The type for the completion codes should be unsigned char instead of char. If it is declared as a normal char then the conditions in __get_device_id() are impossible because the IPMI_DEVICE_IN_FW_UPDATE_ERR error codes are higher than 127. drivers/char/ipmi/ipmi_msghandler.c:2449 __get_device_id() warn: impossible condition '(bmc->cc == 209) => ((-128)-127 == 209)' Fixes: f8910ffa81b0 ("ipmi:msghandler: retry to get device id on an error") Signed-off-by: Dan Carpenter Message-Id: <20200918142756.GB909725@mwanda> Signed-off-by: Corey Minyard

ipmi: add retry in try_get_dev_id()

2020-09-16T13:54:53Z

Use a retry machanism to give the BMC more opportunities to correctly respond when we receive specific completion codes. This is similar to what is done in __get_device_id(). Signed-off-by: Xianting Tian Message-Id: <20200916062129.26129-1-tian.xianting@h3c.com> [Moved GET_DEVICE_ID_MAX_RETRY to include/linux/ipmi.h, reworded some text.] Signed-off-by: Corey Minyard

ipmi: Clean up some printks

2020-09-15T14:57:45Z

Convert to dev_xxx() and fix some verbage. Signed-off-by: Corey Minyard

ipmi:msghandler: retry to get device id on an error

2020-09-15T14:57:45Z

We fail to get the BMCS's device id with low probability when loading the ipmi driver and it causes BMC device registration failed. When this issue occurs we got below kernel prints: [Wed Sep 9 19:52:03 2020] ipmi_si IPI0001:00: IPMI message handler: device id demangle failed: -22 [Wed Sep 9 19:52:03 2020] IPMI BT: using default values [Wed Sep 9 19:52:03 2020] IPMI BT: req2rsp=5 secs retries=2 [Wed Sep 9 19:52:03 2020] ipmi_si IPI0001:00: Unable to get the device id: -5 [Wed Sep 9 19:52:04 2020] ipmi_si IPI0001:00: Unable to register device: error -5 When this issue happens, we want to manually unload the driver and try to load it again, but it can't be unloaded by 'rmmod' as it is already 'in use'. We add a print in handle_one_recv_msg(), when this issue happens, the msg we received is "Recv: 1c 01 d5", which means the data_len is 1, data[0] is 0xd5 (completion code), which means "bmc cannot execute command. Command, or request parameter(s), not supported in present state". Debug code: static int handle_one_recv_msg(struct ipmi_smi *intf, struct ipmi_smi_msg *msg) { printk("Recv: %*ph\n", msg->rsp_size, msg->rsp); ... ... } Then in ipmi_demangle_device_id(), it returned '-EINVAL' as 'data_len < 7' and 'data[0] != 0'. We created this patch to retry the get device id when this error happens. We reproduced this issue again and the retry succeed on the first retry, we finally got the correct msg and then all is ok: Recv: 1c 01 00 01 81 05 84 02 af db 07 00 01 00 b9 00 10 00 So use a retry machanism in this patch to give bmc more opportunity to correctly response kernel when we received specific completion codes. Signed-off-by: Xianting Tian Message-Id: <20200915071817.4484-1-tian.xianting@h3c.com> [Cleaned up the verbage a bit in the header and prints.] Signed-off-by: Corey Minyard