Xu Panda <xu.panda@zte.com.cn>
The implementation of strscpy() is more robust and safer.
That's now the recommended way to copy NUL terminated strings.
Signed-off-by: Xu Panda <xu.panda@zte.com.cn>
Signed-off-by: Yang Yang <yang.yang29@zte.com>
Message-Id: <202212051936400309332@zte.com.cn>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The probe function doesn't make use of the i2c_device_id * parameter so it
can be trivially converted.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Message-Id: <20221118224540.619276-606-uwe@kleine-koenig.org>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The intf_free() function frees the "intf" pointer so we cannot
dereference it again on the next line.
Fixes: cbb79863fc ("ipmi: Don't allow device module unload when in use")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Message-Id: <Y3M8xa1drZv4CToE@kili>
Cc: <stable@vger.kernel.org> # 5.5+
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The kstrto<something>() functions have been moved from kernel.h to
kstrtox.h.
So, in order to eventually remove <linux/kernel.h> from <linux/watchdog.h>,
include the latter directly in the appropriate files.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Message-Id: <37daa028845d90ee77f1e547121a051a983fec2e.1667647002.git.christophe.jaillet@wanadoo.fr>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The spec states that the minimum message retry time is 60ms, but it was
set to 20ms. Correct it.
Reported by: Tony Camuso <tcamuso@redhat.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The current code provokes some kernel-doc warnings:
drivers/char/ipmi/ipmi_msghandler.c:618: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
Signed-off-by: Bo Liu <liubo03@inspur.com>
Message-Id: <20221025060436.4372-1-liubo03@inspur.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
This fixes the following sparse warning:
sparse warnings: (new ones prefixed by >>)
>> drivers/char/ipmi/ssif_bmc.c:254:22: sparse: sparse: invalid assignment: |=
>> drivers/char/ipmi/ssif_bmc.c:254:22: sparse: left side has type restricted __poll_t
>> drivers/char/ipmi/ssif_bmc.c:254:22: sparse: right side has type int
Fixes: dd2bc5cc9e ("ipmi: ssif_bmc: Add SSIF BMC driver")
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/all/202210181103.ontD9tRT-lkp@intel.com/
Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com>
Message-Id: <20221024075956.3312552-1-quan@os.amperecomputing.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
If you continue to access and send messages at a high frequency (once
every 55s) when the IPMI is disconnected, messages will accumulate in
intf->[hp_]xmit_msg. If it lasts long enough, it takes up a lot of
memory.
The reason is that if IPMI is disconnected, each message will be set to
IDLE after it returns to HOSED through IDLE->ERROR0->HOSED. The next
message goes through the same process when it comes in. This process
needs to wait for IBF_TIMEOUT * (MAX_ERROR_RETRIES + 1) = 55s.
Each message takes 55S to destroy. This results in a continuous increase
in memory.
I find that if I wait 5 seconds after the first message fails, the
status changes to ERROR0 in smi_timeout(). The next message will return
the error code IPMI_NOT_IN_MY_STATE_ERR directly without wait.
This is more in line with our needs.
So instead of setting each message state to IDLE after it reaches the
state HOSED, set state to ERROR0.
After testing, the problem has been solved, no matter how many
consecutive sends, will not cause continuous memory growth. It also
returns to normal immediately after the IPMI is restored.
In addition, the HOSED state should also count as invalid. So the HOSED
is removed from the invalid judgment in start_kcs_transaction().
The verification operations are as follows:
1. Use BPF to record the ipmi_alloc/free_smi_msg().
$ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc
%p\n",retval);} kprobe:free_recv_msg {printf("free %p\n",arg0)}'
2. Exec `date; time for x in $(seq 1 2); do ipmitool mc info; done`.
3. Record the output of `time` and when free all msgs.
Before:
`time` takes 120s, This is because `ipmitool mc info` send 4 msgs and
waits only 15 seconds for each message. Last msg is free after 440s.
$ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc
%p\n",retval);} kprobe:free_recv_msg {printf("free %p\n",arg0)}'
Oct 05 11:40:55 Attaching 2 probes...
Oct 05 11:41:12 alloc 0xffff9558a05f0c00
Oct 05 11:41:27 alloc 0xffff9558a05f1a00
Oct 05 11:41:42 alloc 0xffff9558a05f0000
Oct 05 11:41:57 alloc 0xffff9558a05f1400
Oct 05 11:42:07 free 0xffff9558a05f0c00
Oct 05 11:42:07 alloc 0xffff9558a05f7000
Oct 05 11:42:22 alloc 0xffff9558a05f2a00
Oct 05 11:42:37 alloc 0xffff9558a05f5a00
Oct 05 11:42:52 alloc 0xffff9558a05f3a00
Oct 05 11:43:02 free 0xffff9558a05f1a00
Oct 05 11:43:57 free 0xffff9558a05f0000
Oct 05 11:44:52 free 0xffff9558a05f1400
Oct 05 11:45:47 free 0xffff9558a05f7000
Oct 05 11:46:42 free 0xffff9558a05f2a00
Oct 05 11:47:37 free 0xffff9558a05f5a00
Oct 05 11:48:32 free 0xffff9558a05f3a00
$ root@dc00-pb003-t106-n078:~# date;time for x in $(seq 1 2); do
ipmitool mc info; done
Wed Oct 5 11:41:12 CST 2022
No data available
Get Device ID command failed
No data available
No data available
No valid response received
Get Device ID command failed: Unspecified error
No data available
Get Device ID command failed
No data available
No data available
No valid response received
No data available
Get Device ID command failed
real 1m55.052s
user 0m0.001s
sys 0m0.001s
After:
`time` takes 55s, all msgs is returned and free after 55s.
$ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc
%p\n",retval);} kprobe:free_recv_msg {printf("free %p\n",arg0)}'
Oct 07 16:30:35 Attaching 2 probes...
Oct 07 16:30:45 alloc 0xffff955943aa9800
Oct 07 16:31:00 alloc 0xffff955943aacc00
Oct 07 16:31:15 alloc 0xffff955943aa8c00
Oct 07 16:31:30 alloc 0xffff955943aaf600
Oct 07 16:31:40 free 0xffff955943aa9800
Oct 07 16:31:40 free 0xffff955943aacc00
Oct 07 16:31:40 free 0xffff955943aa8c00
Oct 07 16:31:40 free 0xffff955943aaf600
Oct 07 16:31:40 alloc 0xffff9558ec8f7e00
Oct 07 16:31:40 free 0xffff9558ec8f7e00
Oct 07 16:31:40 alloc 0xffff9558ec8f7800
Oct 07 16:31:40 free 0xffff9558ec8f7800
Oct 07 16:31:40 alloc 0xffff9558ec8f7e00
Oct 07 16:31:40 free 0xffff9558ec8f7e00
Oct 07 16:31:40 alloc 0xffff9558ec8f7800
Oct 07 16:31:40 free 0xffff9558ec8f7800
root@dc00-pb003-t106-n078:~# date;time for x in $(seq 1 2); do
ipmitool mc info; done
Fri Oct 7 16:30:45 CST 2022
No data available
Get Device ID command failed
No data available
No data available
No valid response received
Get Device ID command failed: Unspecified error
Get Device ID command failed: 0xd5 Command not supported in present state
Get Device ID command failed: Command not supported in present state
real 0m55.038s
user 0m0.001s
sys 0m0.001s
Signed-off-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
Message-Id: <20221009091811.40240-2-zhangyuchen.lcr@bytedance.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
After the IPMI disconnect problem, the memory kept rising and we tried
to unload the driver to free the memory. However, only part of the
free memory is recovered after the driver is uninstalled. Using
ebpf to hook free functions, we find that neither ipmi_user nor
ipmi_smi_msg is free, only ipmi_recv_msg is free.
We find that the deliver_smi_err_response call in clean_smi_msgs does
the destroy processing on each message from the xmit_msg queue without
checking the return value and free ipmi_smi_msg.
deliver_smi_err_response is called only at this location. Adding the
free handling has no effect.
To verify, try using ebpf to trace the free function.
$ bpftrace -e 'kretprobe:ipmi_alloc_recv_msg {printf("alloc rcv
%p\n",retval);} kprobe:free_recv_msg {printf("free recv %p\n",
arg0)} kretprobe:ipmi_alloc_smi_msg {printf("alloc smi %p\n",
retval);} kprobe:free_smi_msg {printf("free smi %p\n",arg0)}'
Signed-off-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
Message-Id: <20221007092617.87597-4-zhangyuchen.lcr@bytedance.com>
[Fixed the comment above handle_one_recv_msg().]
Signed-off-by: Corey Minyard <cminyard@mvista.com>
When fixing the problem mentioned in PATCH1, we also found
the following problem:
If the IPMI is disconnected and in the sending process, the
uninstallation driver will be stuck for a long time.
The main problem is that uninstalling the driver waits for curr_msg to
be sent or HOSED. After stopping tasklet, the only place to trigger the
timeout mechanism is the circular poll in shutdown_smi.
The poll function delays 10us and calls smi_event_handler(smi_info,10).
Smi_event_handler deducts 10us from kcs->ibf_timeout.
But the poll func is followed by schedule_timeout_uninterruptible(1).
The time consumed here is not counted in kcs->ibf_timeout.
So when 10us is deducted from kcs->ibf_timeout, at least 1 jiffies has
actually passed. The waiting time has increased by more than a
hundredfold.
Now instead of calling poll(). call smi_event_handler() directly and
calculate the elapsed time.
For verification, you can directly use ebpf to check the kcs->
ibf_timeout for each call to kcs_event() when IPMI is disconnected.
Decrement at normal rate before unloading. The decrement rate becomes
very slow after unloading.
$ bpftrace -e 'kprobe:kcs_event {printf("kcs->ibftimeout : %d\n",
*(arg0+584));}'
Signed-off-by: Zhang Yuchen <zhangyuchen.lcr@bytedance.com>
Message-Id: <20221007092617.87597-3-zhangyuchen.lcr@bytedance.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Cc: stable@vger.kernel.org
The ASPEED KCS devices don't provide a BMC-side interrupt for the host
reading the output data register (ODR). The act of the host reading ODR
clears the output buffer full (OBF) flag in the status register (STR),
informing the BMC it can transmit a subsequent byte.
On the BMC side the KCS client must enable the OBE event *and* perform a
subsequent read of STR anyway to avoid races - the polling provides a
window for the host to read ODR if data was freshly written while
minimising BMC-side latency.
Fixes: 28651e6c42 ("ipmi: kcs_bmc: Allow clients to control KCS IRQ state")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20220812144741.240315-1-andrew@aj.id.au>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The SMBus system interface (SSIF) IPMI BMC driver can be used to perform
in-band IPMI communication with their host in management (BMC) side.
Thanks Dan for the copy_from_user() fix in the link below.
Link: https://lore.kernel.org/linux-arm-kernel/20220310114119.13736-4-quan@os.amperecomputing.com/
Signed-off-by: Quan Nguyen <quan@os.amperecomputing.com>
Message-Id: <20221004093106.1653317-2-quan@os.amperecomputing.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
This is mostly just doc, config, and little tweaks. Nothing big, which
is why there was nothing for 6.0. There is one crash fix, but it's not
something that I think anyone is using yet.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE/Q1c5nzg9ZpmiCaGYfOMkJGb/4EFAmM8sVMACgkQYfOMkJGb
/4HBow//ZhkVpFqURCDNjO+GjVL9tzxuvnUQPeKPYlnUkpY53mPg7PucEZu4DXWD
GgOz/wGxoCZL0n+Na8LKD+4NNo9gXMZH8k+o7GwIPdAu970MC80XSnr3KrbkSv6J
ID29kZE+jOzd3orM8J662Hqv9BK8FKLCFFBUMuzeMQYH1oOJvFjSK4OXLxIo+h0M
3LhNcj8yPa9pW/Uam8sIBj9JLsUZEr7wqG8VESnekxZ6Pqtpaq+Ik0pJtPP/Vxw+
Ri06UeVSO+614Ywo+aVxVxezFhnxx77/Y5Uvo4UMw2ssaslku/Glmp4XzWjgAOj5
l8unB1PFll5s7jkzrcL5HVsyZt81+OBTItbO6HaaejKHc99Is+g7IlO9o0bg9pUS
OyBeQHc7k5PfI40nwve2LUPz6FwO3NEaaz3oMrQuy1pnpEwdE7GdPiYdJe3kVHem
0hIHby99jFkTlvvNbLj0JrejEd5As45UNDlfBjJuYh7L/2A3gpbNX3MHxD4cwZRg
9LuM/BTOR274QvSb49xlQuxMOf8lagXOTajkvLUYBSkenQi8PAmcjk74Zgk/FYRW
qpDuA8LC7XVTk7JtS9ZHECkLjk1Qe1CUVNcrCQmB8Lyapx3SI8pDB2SQOzf5zG5Z
/Ty4Qgw8eUJWepJ4BVymalHFhCgdsz1vlFwMT3KJc+giUFTlNwY=
=wVwj
-----END PGP SIGNATURE-----
Merge tag 'for-linus-6.1-1' of https://github.com/cminyard/linux-ipmi
Pull IPMI updates from Corey Minyard:
"Fix a bunch of little problems in IPMI
This is mostly just doc, config, and little tweaks. Nothing big, which
is why there was nothing for 6.0. There is one crash fix, but it's not
something that I think anyone is using yet"
* tag 'for-linus-6.1-1' of https://github.com/cminyard/linux-ipmi:
ipmi: Remove unused struct watcher_entry
ipmi: kcs: aspeed: Update port address comments
ipmi: Add __init/__exit annotations to module init/exit funcs
ipmi:ipmb: Don't call ipmi_unregister_smi() on a register failure
ipmi:ipmb: Fix a vague comment and a typo
dt-binding: ipmi: add fallback to npcm845 compatible
ipmi: Fix comment typo
char: ipmi: modify NPCM KCS configuration
dt-bindings: ipmi: Add npcm845 compatible
After commit e86ee2d44b44("ipmi: Rework locking and shutdown for hot remove"),
no one use struct watcher_entry, so remove it.
Signed-off-by: Yuan Can <yuancan@huawei.com>
Message-Id: <20220927133814.98929-1-yuancan@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Remove AST_usrGuide_KCS.pdf as it is no longer maintained.
Add more descriptions as the driver now supports the I/O
address configurations for both the KCS Data and Cmd/Status
interface registers.
Signed-off-by: Chia-Wei Wang <chiawei_wang@aspeedtech.com>
Message-Id: <20220920020333.601-1-chiawei_wang@aspeedtech.com>
[I don't like removing documentation, but the document in question
was a personal note by an employee and nothing official and not
necessarily guaranteed to be accurate in the future. So go
ahead and remove it.]
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The data structure won't be set up to be unregistered, and it can result in
crashes if the register fails.
Signed-off-by: Corey Minyard <minyard@acm.org>
Sending an IPMI response message gets a reponse to the response, but the
comment saying that just said "response response", which is hard to
understand. Also fix an obvious typo.
Reported-by: Shaomin Deng <dengshaomin@cdjrlc.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The value returned by an i2c driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)
So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.
Reviewed-by: Peter Senna Tschudin <peter.senna@gmail.com>
Reviewed-by: Jeremy Kerr <jk@codeconstruct.com.au>
Reviewed-by: Benjamin Mugnier <benjamin.mugnier@foss.st.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Marek Behún <kabel@kernel.org> # for leds-turris-omnia
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Petr Machata <petrm@nvidia.com> # for mlxsw
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com> # for surface3_power
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> # for bmc150-accel-i2c + kxcjk-1013
Reviewed-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> # for media/* + staging/media/*
Acked-by: Miguel Ojeda <ojeda@kernel.org> # for auxdisplay/ht16k33 + auxdisplay/lcd2s
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # for versaclock5
Reviewed-by: Ajay Gupta <ajayg@nvidia.com> # for ucsi_ccg
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for iio
Acked-by: Peter Rosin <peda@axentia.se> # for i2c-mux-*, max9860
Acked-by: Adrien Grassein <adrien.grassein@gmail.com> # for lontium-lt8912b
Reviewed-by: Jean Delvare <jdelvare@suse.de> # for hwmon, i2c-core and i2c/muxes
Acked-by: Corey Minyard <cminyard@mvista.com> # for IPMI
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> # for drivers/power
Acked-by: Krzysztof Hałasa <khalasa@piap.pl>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
The double `the' is duplicated in line 4360, remove one.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Message-Id: <20220715054156.6342-1-wangborong@cdjrlc.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
of_parse_phandle() returns a node pointer with refcount
incremented, we should use of_node_put() on it when done.
Add missing of_node_put() to avoid refcount leak.
Fixes: 00d93611f0 ("ipmi:ipmb: Add the ability to have a separate slave and master device")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
Message-Id: <20220512044445.3102-1-linmq006@gmail.com>
Cc: stable@vger.kernel.org # v5.17+
Signed-off-by: Corey Minyard <cminyard@mvista.com>
There were two identical logs in two different places, so you couldn't
tell which one was being logged. Make them unique.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The was it was wouldn't work in some situations, simplify it. What was
there was unnecessary complexity.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Don't hand-initialize the struct here, create a macro to initialize it
so new fields added don't get forgotten in places.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
There was a "type" element added to this structure, but some static
values were missed. The default value will be zero, which is correct,
but create an initializer for the type and initialize the type properly
in the initializer to avoid future issues.
Reported-by: Joe Wiese <jwiese@rackspace.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Even though it's not possible to get into the SSIF_GETTING_MESSAGES and
SSIF_GETTING_EVENTS states without a valid message in the msg field,
it's probably best to be defensive here and check and print a log, since
that means something else went wrong.
Also add a default clause to that switch statement to release the lock
and print a log, in case the state variable gets messed up somehow.
Reported-by: Haowen Bai <baihaowen@meizu.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The i2c probe functions here don't use the id information provided in
their second argument, so the single-parameter i2c probe function
("probe_new") can be used instead.
This avoids scanning the identifier tables during probes.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Message-Id: <20220324171159.544565-1-steve@sk2.org>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Go through each user and add its message count to a total and print the
total.
It would be nice to have a per-user file, but there's no user sysfs
entity at this point to hang it off of. Probably not worth the effort.
Based on work by Chen Guanqiao <chen.chenchacha@foxmail.com>
Cc: Chen Guanqiao <chen.chenchacha@foxmail.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
A count of users is kept for each interface, allow it to be viewed.
Based on work by Chen Guanqiao <chen.chenchacha@foxmail.com>
Cc: Chen Guanqiao <chen.chenchacha@foxmail.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
This way a rogue application can't use up a bunch of memory.
Based on work by Chen Guanqiao <chen.chenchacha@foxmail.com>
Cc: Chen Guanqiao <chen.chenchacha@foxmail.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Each user uses memory, we need limits to avoid a rogue program from
running the system out of memory.
Based on work by Chen Guanqiao <chen.chenchacha@foxmail.com>
Cc: Chen Guanqiao <chen.chenchacha@foxmail.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
KASAN report null-ptr-deref as follows:
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
RIP: 0010:ipmi_unregister_smi+0x7d/0xd50 drivers/char/ipmi/ipmi_msghandler.c:3680
Call Trace:
ipmi_ipmb_remove+0x138/0x1a0 drivers/char/ipmi/ipmi_ipmb.c:443
ipmi_ipmb_probe+0x409/0xda1 drivers/char/ipmi/ipmi_ipmb.c:548
i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563
really_probe+0x3f3/0xa70 drivers/base/dd.c:541
In ipmi_ipmb_probe(), 'iidev->intf' is not set before
ipmi_register_smi() success. And in the error handling case,
ipmi_ipmb_remove() is called to release resources, ipmi_unregister_smi()
is called without check 'iidev->intf', this will cause KASAN
null-ptr-deref issue.
General kernel style is to allow NULL to be passed into unregister
calls, so fix it that way. This allows a NULL check to be removed in
other code.
Fixes: 57c9e3c9a3 ("ipmi:ipmi_ipmb: Unregister the SMI on remove")
Reported-by: Hulk Robot <hulkci@huawei.com>
Cc: stable@vger.kernel.org # v5.17+
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
A chunk was dropped when the code handling send messages was rewritten.
Those messages shouldn't be processed normally, they are just an
indication that the message was successfully sent and the timers should
be started for the real response that should be coming later.
Add back in the missing chunk to just discard the message and go on.
Fixes: 059747c245 ("ipmi: Add support for IPMB direct messages")
Reported-by: Joe Wiese <jwiese@rackspace.com>
Cc: stable@vger.kernel.org # v5.16+
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Joe Wiese <jwiese@rackspace.com>
Clang static analysis reports this issue
ipmi_ssif.c:1731:3: warning: 4th function call
argument is an uninitialized value
dev_info(&ssif_info->client->dev,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The 4th parameter is the 'len' variable.
len is only set by a successful call to do_cmd().
Initialize to len 0.
Signed-off-by: Tom Rix <trix@redhat.com>
Message-Id: <20220320135954.2258545-1-trix@redhat.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
It's been a few releases since we depreciated the "v1" bindings. Remove
support from the driver as all known device trees have been updated to
use the new bindings.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20220228062840.449215-1-joel@jms.id.au>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
A situation has come up where there is a slave-only device for the slave
and a separate master device on the same bug. Allow a separate slave
device to be registered.
Signed-off-by: Corey Minyard <minyard@acm.org>
The AST2600 is already described in the bindings, but the driver never
gained a compatible string.
Signed-off-by: Joel Stanley <joel@jms.id.au>
Message-Id: <20220221070351.121905-1-joel@jms.id.au>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The strlcpy should not be used because it doesn't limit the source
length. So that it will lead some potential bugs.
But the strscpy doesn't require reading memory from the src string
beyond the specified "count" bytes, and since the return value is
easier to error-check than strlcpy()'s. In addition, the implementation
is robust to the string changing out from underneath it, unlike the
current strlcpy() implementation.
Thus, replace strlcpy with strscpy.
Signed-off-by: Jason Wang <wangborong@cdjrlc.com>
Message-Id: <20211222032707.1912186-1-wangborong@cdjrlc.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ident is not modified and can be made const to allow the compiler to put
it in read-only memory.
Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com>
Message-Id: <20211128220154.32927-1-rikard.falkeborn@gmail.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
If the workqueue allocation fails, the driver is marked as not initialized,
and timer and panic_notifier will be left registered.
Instead of removing those when workqueue allocation fails, do the workqueue
initialization before doing it, and cleanup srcu_struct if it fails.
Fixes: 1d49eb91e8 ("ipmi: Move remove_work to dedicated workqueue")
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Cc: Corey Minyard <cminyard@mvista.com>
Cc: Ioanna Alifieraki <ioanna-maria.alifieraki@canonical.com>
Cc: stable@vger.kernel.org
Message-Id: <20211217154410.1228673-2-cascardo@canonical.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
In case, init_srcu_struct fails (because of memory allocation failure), we
might proceed with the driver initialization despite srcu_struct not being
entirely initialized.
Fixes: 913a89f009 ("ipmi: Don't initialize anything in the core until something uses it")
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Cc: Corey Minyard <cminyard@mvista.com>
Cc: stable@vger.kernel.org
Message-Id: <20211217154410.1228673-1-cascardo@canonical.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
During probe ssif_info->client is dereferenced in error path. However,
it is set when some of the error checking has already been done. This
causes following kernel crash if an error path is taken:
[ 30.645593][ T674] ipmi_ssif 0-000e: ipmi_ssif: Not probing, Interface already present
[ 30.657616][ T674] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000088
...
[ 30.657723][ T674] pc : __dev_printk+0x28/0xa0
[ 30.657732][ T674] lr : _dev_err+0x7c/0xa0
...
[ 30.657772][ T674] Call trace:
[ 30.657775][ T674] __dev_printk+0x28/0xa0
[ 30.657778][ T674] _dev_err+0x7c/0xa0
[ 30.657781][ T674] ssif_probe+0x548/0x900 [ipmi_ssif 62ce4b08badc1458fd896206d9ef69a3c31f3d3e]
[ 30.657791][ T674] i2c_device_probe+0x37c/0x3c0
...
Initialize ssif_info->client before any error path can be taken. Clear
i2c_client data in the error path to prevent the dangling pointer from
leaking.
Fixes: c4436c9149 ("ipmi_ssif: avoid registering duplicate ssif interface")
Cc: stable@vger.kernel.org # 5.4.x
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Message-Id: <20211208093239.4432-1-ykaukab@suse.de>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
More missed changes, the response back to another system sending a
command that had no user to handle it wasn't formatted properly.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
A couple of issues:
The tested data sizes are wrong; during the design that changed and this
got missed.
The formatting of the reponse couldn't use the normal one, it has to be
an IPMB formatted response.
Reported-by: Jakub Kicinski <kuba@kernel.org>
Fixes: 059747c245 ("ipmi: Add support for IPMB direct messages")
Signed-off-by: Corey Minyard <cminyard@mvista.com>
