linux-toradex.git/drivers/char/ipmi/ipmi_ssif.c, branch v5.10-rc2

ipmi: ssif: Remove finished TODO comment about SMBus alert

2020-06-24T11:41:42+00:00

commit 9162052173d2 ("ipmi: Add alert handling to SSIF") introduces
support of SMBus alert. So, just remove TODO comment in order not to
confuse future readers.

Signed-off-by: Misono Tomohiro 
Message-Id: <20200624065405.17653-2-misono.tomohiro@jp.fujitsu.com>
Signed-off-by: Corey Minyard

ipmi:ssif: Remove dynamic platform device handing

2020-05-27T23:25:56+00:00

Platform devices can only come in through the DMI interface, and that
will get done before initialization is complete.  Therefore there is no
reason to hande getting a device in new_ssif_client after
initialization.

Dynamic entries can still come in through the i2c interfaces, but that's
handled differently.

Signed-off-by: Corey Minyard

Try to load acpi_ipmi when an SSIF ACPI IPMI interface is added

2020-05-18T11:32:02+00:00

This is similar to the recent patch for the SI interface, but for SSIF.

Signed-off-by: Corey Minyard

char: ipmi: convert to use i2c_new_client_device()

2020-05-14T20:37:31+00:00

Move away from the deprecated API.

Signed-off-by: Wolfram Sang 
Message-Id: <20200326210958.13051-2-wsa+renesas@sang-engineering.com>
Signed-off-by: Corey Minyard

ipmi: Add missing annotation for ipmi_ssif_lock_cond() and ipmi_ssif_unlock_cond()

2020-04-03T18:34:57+00:00

Sparse reports a warning at ipmi_ssif_unlock_cond()
	and ipmi_ssif_lock_cond()

warning: context imbalance in ipmi_ssif_lock_cond()
	- wrong count at exit
 warning: context imbalance in ipmi_ssif_unlock_cond()
	- unexpected unlock

The root cause is the missing annotation at ipmi_ssif_unlock_cond()
	and ipmi_ssif_lock_cond()

Add the missing __acquires(&ata_scsi_rbuf_lock)
Add the missing __releases(&ata_scsi_rbuf_lock)

Signed-off-by: Jules Irenge 
Message-Id: <20200403160505.2832-6-jbi.octave@gmail.com>
Signed-off-by: Corey Minyard

ipmi:ssif: Handle a possible NULL pointer reference

2019-12-23T16:42:19+00:00

In error cases a NULL can be passed to memcpy.  The length will always
be zero, so it doesn't really matter, but go ahead and check for NULL,
anyway, to be more precise and avoid static analysis errors.

Reported-by: kbuild test robot 
Signed-off-by: Corey Minyard

ipmi_ssif: avoid registering duplicate ssif interface

2019-08-22T16:06:33+00:00

It is possible that SSIF interface entry is present in both DMI and ACPI
tables. In SMP systems, in such cases it is possible that ssif_probe could
be called simultaneously from i2c interface (from ACPI) and from DMI on
different CPUs at kernel boot. Both try to register same SSIF interface
simultaneously and result in race.

In such cases where ACPI and SMBIOS both IPMI entries are available, we
need to prefer ACPI over SMBIOS so that ACPI functions work properly if
they use IPMI.
So, if we get an ACPI interface and have already registered an SMBIOS
at the same address, we need to remove the SMBIOS one and add the ACPI.

Log:
[   38.774743] ipmi device interface
[   38.805006] ipmi_ssif: IPMI SSIF Interface driver
[   38.861979] ipmi_ssif i2c-IPI0001:06: ssif_probe CPU 99 ***
[   38.863655] ipmi_ssif 0-000e: ssif_probe CPU 14 ***
[   38.863658] ipmi_ssif: Trying SMBIOS-specified SSIF interface at i2c address 0xe, adapter xlp9xx-i2c, slave address 0x0
[   38.869500] ipmi_ssif: Trying ACPI-specified SSIF interface at i2c address 0xe, adapter xlp9xx-i2c, slave address 0x0
[   38.914530] ipmi_ssif: Unable to clear message flags: -22 7 c7
[   38.952429] ipmi_ssif: Unable to clear message flags: -22 7 00
[   38.994734] ipmi_ssif: Error getting global enables: -22 7 00
[   39.015877] ipmi_ssif 0-000e: IPMI message handler: Found new BMC (man_id: 0x00b3d1, prod_id: 0x0001, dev_id: 0x20)
[   39.377645] ipmi_ssif i2c-IPI0001:06: IPMI message handler: Found new BMC (man_id: 0x00b3d1, prod_id: 0x0001, dev_id: 0x20)
[   39.387863] ipmi_ssif 0-000e: IPMI message handler: BMC returned incorrect response, expected netfn 7 cmd 42, got netfn 7 cmd 1
...
[NOTE] : Added custom prints to explain the problem.

In the above log, ssif_probe is executed simultaneously on two different
CPUs.

This patch fixes this issue in following way:
 - Adds ACPI entry also to the 'ssif_infos' list.
 - Checks the list if SMBIOS is already registered, removes it and adds
   ACPI.
 - If ACPI is already registered, it ignores SMBIOS.
 - Adds mutex lock throughout the probe process to avoid race.

Signed-off-by: Kamlakant Patel 
Message-Id: <1566389064-27356-1-git-send-email-kamlakantp@marvell.com>
Signed-off-by: Corey Minyard

ipmi_si: Rework some include files

2019-08-02T12:25:03+00:00

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

ipmi_ssif: fix unexpected driver unregister warning

2019-05-24T15:04:27+00:00

If platform_driver_register() fails from init_ipmi_ssif(),
platform_driver_unregister() called unconditionally will
trigger following warning,

ipmi_ssif: Unable to register driver: -12
------------[ cut here ]------------
Unexpected driver unregister!
WARNING: CPU: 1 PID: 6305 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 
Signed-off-by: Kefeng Wang 
Message-Id: <20190524143724.43218-1-wangkefeng.wang@huawei.com>

Signed-off-by: Corey Minyard

ipmi: Remove warning if no slave address is present

2019-04-24T17:29:24+00:00

It's just noise, really, lots of systems don't have it.

Reported-by: Kamlakant Patel 
Signed-off-by: Corey Minyard