Andy reported:
Debian clang version 19.1.7 is not happy when compiled with
`make W=1` (note, CONFIG_WERROR=y is the default):
ipmi_si_platform.c:268:15: error: cast to smaller integer type 'enum si_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
268 | io.si_type = (enum si_type)device_get_match_data(&pdev->dev);
The IPMI SI type is an enum that was cast into a pointer that was
then cast into an enum again. That's not the greatest style, so
instead create an info structure to hold the data and use that.
Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Closes: https://lore.kernel.org/lkml/20250415085156.446430-1-andriy.shevchenko@linux.intel.com/
Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Corey Minyard <corey@minyard.net>
The continual trickle of small conversion patches is grating on me, and
is really not helping. Just get rid of the 'remove_new' member
function, which is just an alias for the plain 'remove', and had a
comment to that effect:
/*
* .remove_new() is a relic from a prototype conversion of .remove().
* New drivers are supposed to implement .remove(). Once all drivers are
* converted to not use .remove_new any more, it will be dropped.
*/
This was just a tree-wide 'sed' script that replaced '.remove_new' with
'.remove', with some care taken to turn a subsequent tab into two tabs
to make things line up.
I did do some minimal manual whitespace adjustment for places that used
spaces to line things up.
Then I just removed the old (sic) .remove_new member function, and this
is the end result. No more unnecessary conversion noise.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Message-Id: <789cd7876780241430dd5604bc4322453fe4e581.1709655755.git.u.kleine-koenig@pengutronix.de>
Signed-off-by: Corey Minyard <minyard@acm.org>
Use preferred device_get_match_data() instead of of_match_device() to
get the driver match data. With this, adjust the includes to explicitly
include the correct headers.
Signed-off-by: Rob Herring <robh@kernel.org>
Message-Id: <20231115210230.3744198-1-robh@kernel.org>
Signed-off-by: Corey Minyard <minyard@acm.org>
With W=1 we see the following warning:
| drivers/char/ipmi/ipmi_si_platform.c:272:15: error: \
| cast to smaller integer type 'enum si_type' from \
| 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
| 272 | io.si_type = (enum si_type) match->data;
| | ^~~~~~~~~~~~~~~~~~~~~~~~~~
This is due to the fact that the `si_type` enum members are int-width
and a cast from pointer-width down to int will cause truncation and
possible data loss. Although in this case `si_type` has only a few
enumerated fields and thus there is likely no data loss occurring.
Nonetheless, this patch is necessary to the goal of promoting this
warning out of W=1.
Link: https://github.com/ClangBuiltLinux/linux/issues/1902
Link: https://lore.kernel.org/llvm/202308081000.tTL1ElTr-lkp@intel.com/
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Justin Stitt <justinstitt@google.com>
Message-Id: <20230809-cbl-1902-v1-1-92def12d1dea@google.com>
Signed-off-by: Corey Minyard <minyard@acm.org>
When probing for an ACPI-specified IPMI device, the code would request
that the acpi_ipmi module be loaded ACPI operations through IPMI can be
performed. This could happen through module load context, for instance,
if an I2C module is loaded that caused the IPMI interface to be probed.
This is not allowed because a synchronous module load in this context
can result in an deadlock, and I was getting a warning:
[ 23.967853] WARNING: CPU: 0 PID: 21 at kernel/module/kmod.c:144 __request_module+0x1de/0x2d0
[ 23.968852] Modules linked in: i2c_i801 ipmi_ssif
The IPMI driver is not dependent on acpi_ipmi, so just change the called
to request_module_nowait to make the load asynchronous.
Signed-off-by: Corey Minyard <minyard@acm.org>
The caller of this function (parisc_driver_remove() in
arch/parisc/kernel/drivers.c) ignores the return value, so better don't
return any value at all to not wake wrong expectations in driver authors.
The only function that could return a non-zero value before was
ipmi_parisc_remove() which returns the return value of
ipmi_si_remove_by_dev(). Make this function return void, too, as for all
other callers the value is ignored, too.
Also fold in a small checkpatch fix for:
WARNING: Unnecessary space before function pointer arguments
+ void (*remove) (struct parisc_device *dev);
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> (for drivers/input)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Acked-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Helge Deller <deller@gmx.de>
Although the IRQ assignment in ipmi_si driver is optional,
platform_get_irq() spews error messages unnecessarily:
ipmi_si dmi-ipmi-si.0: IRQ index 0 not found
Fix this by switching to platform_get_irq_optional().
Cc: stable@vger.kernel.org # 5.4.x
Cc: John Donnelly <john.p.donnelly@oracle.com>
Fixes: 7723f4c5ec ("driver core: platform: Add an error message to platform_get_irq*()")
Reported-and-tested-by: Patrick Vo <patrick.vo@hpe.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Message-Id: <20200205093146.1352-1-tiwai@suse.de>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
ipmi_si_sm.h was getting included in lots of places it didn't
belong. Rework things a bit to remove all the dependencies,
mostly just moving things between include files that were in
the wrong place and removing bogus includes.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Pull IPMI updates from Corey Minyard:
"Some small fixes for various things, nothing huge, mostly found by
automated tools.
Plus add a driver that allows Linux to act as an IPMB slave device, so
it can be a satellite MC in an IPMI network"
* tag 'for-linus-5.3' of git://github.com/cminyard/linux-ipmi:
docs: ipmb: place it at driver-api and convert to ReST
fix platform_no_drv_owner.cocci warnings
ipmi: ipmb: don't allocate i2c_client on stack
ipmi: ipmb: Fix build error while CONFIG_I2C is set to m
Add support for IPMB driver
drivers: ipmi: Drop device reference
ipmi_ssif: fix unexpected driver unregister warning
ipmi_si: use bool type for initialized variable
ipmi_si: fix unexpected driver unregister warning
If ipmi_si_platform_init()->platform_driver_register() fails,
platform_driver_unregister() called unconditionally will trigger
following warning,
ipmi_platform: Unable to register driver: -12
------------[ cut here ]------------
Unexpected driver unregister!
WARNING: CPU: 1 PID: 7210 at drivers/base/driver.c:193 driver_unregister+0x60/0x70 drivers/base/driver.c:193
Fix it by adding platform_registered variable, only unregister platform
driver when it is already successfully registered.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Message-Id: <20190517101245.4341-1-wangkefeng.wang@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
It was being done in two different places now that hard-coded devices
use platform devices, and it's about to be three with hotmod switching
to platform devices. So put the code in one place.
This required some rework on some interfaces to make the type space
clean.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
When excuting a command like:
modprobe ipmi_si ports=0xffc0e3 type=bt
The system would get an oops.
The trouble here is that ipmi_si_hardcode_find_bmc() is called before
ipmi_si_platform_init(), but initialization of the hard-coded device
creates an IPMI platform device, which won't be initialized yet.
The real trouble is that hard-coded devices aren't created with
any device, and the fixup is done later. So do it right, create the
hard-coded devices as normal platform devices.
This required adding some new resource types to the IPMI platform
code for passing information required by the hard-coded device
and adding some code to remove the hard-coded platform devices
on module removal.
To enforce the "hard-coded devices passed by the user take priority
over firmware devices" rule, some special code was added to check
and see if a hard-coded device already exists.
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Tested-by: Yang Yingliang <yangyingliang@huawei.com>
The IPMI DMI code was adding platform overrides, which is not
really an ideal solution. Switch to using the id_table in
the drivers to identify the devices.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Add and use #define pr_fmt/dev_fmt, and remove #define PFX
This also prefixes some messages that were not previously prefixed.
Miscellanea:
o Convert printk(KERN_<level> to pr_<level>(
o Use %s, __func__ where appropriate
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
The IPMI spec states:
The purpose of the SPMI Table is to provide a mechanism that can
be used by the OSPM (an ACPI term for “OS Operating System-directed
configuration and Power Management” essentially meaning an ACPI-aware
OS or OS loader) very early in the boot process, e.g., before the
ability to execute ACPI control methods in the OS is available.
When we are probing IPMI in Linux, ACPI control methods are available,
so we shouldn't be probing using SPMI. It could cause some confusion
during the probing process.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Fix typo in parameter description.
Fixes: 95e300c052 ("ipmi: Make the DMI probe into a generic platform probe")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Rework the DMI probe function to be a generic platform probe, and
then rework the DMI code (and a few other things) to use the more
generic information. This is so other things can declare platform
IPMI devices.
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Corey Minyard