From: Corey Minyard <corey@minyard.net>
To: "Ivan T. Ivanov" <iivanov@suse.de>
Cc: openipmi-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] ipmi:ssif: Improve detecting during probing
Date: Thu, 22 Aug 2024 09:40:50 -0500 [thread overview]
Message-ID: <ZsdN8sBIUYetCUOp@mail.minyard.net> (raw)
In-Reply-To: <20240822072255.fncuy4xdkglnf3bn@localhost.localdomain>
On Thu, Aug 22, 2024 at 10:22:55AM +0300, Ivan T. Ivanov wrote:
> Hi Corey,
>
> On 08-20 20:05, Corey Minyard wrote:
> >
> > If an IPMI SSIF device is probed and there is something there, but
> > probably not an actual BMC, the code would just issue a lot of errors
> > before it failed. We kind of need these errors to help with certain
> > issues, and some of the failure reports are non-fatal.
> >
> > However, a get device id command should alway work. If that fails,
> > nothing else is going to work and it's a pretty good indication that
> > there's no valid BMC there. So issue and check that command and bail
> > if it fails.
> >
> > Reported-by: Ivan T. Ivanov <iivanov@suse.de>
> > Signed-off-by: Corey Minyard <corey@minyard.net>
> > ---
> > drivers/char/ipmi/ipmi_ssif.c | 24 +++++++++++++++++++++++-
> > 1 file changed, 23 insertions(+), 1 deletion(-)
> >
> > Ivan, is it possible for you to test this patch on the broken system?
>
> This exact system is not available to me at the moment. I have few
> other machines on which I could test this.
>
> > It should work based on what you reported, but it's nice to be sure.
> >
> > Also, I discovered that the detect function is kind of bogus, it only
> > works on an address list that isn't present (any more). However, I
> > re-used it for my purposes in the probe function.
> >
> > Thanks.
> >
> > diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
> > index e8e7b832c060..4c403e7a9fc8 100644
> > --- a/drivers/char/ipmi/ipmi_ssif.c
> > +++ b/drivers/char/ipmi/ipmi_ssif.c
> > @@ -1368,8 +1368,20 @@ static int ssif_detect(struct i2c_client *client, struct i2c_board_info *info)
> > rv = do_cmd(client, 2, msg, &len, resp);
> > if (rv)
> > rv = -ENODEV;
>
> What is my worry is that in case of SMBus errors, device is there but
> for some reason it got stuck/crashed or whatever, so will get out of
> detect function from here and with ENODEV return code probe function
> will be called for no reason.
That's not how the i2c code works. See my next comment.
>
> > - else
> > + else {
> > + if (len < 3) {
> > + rv = -ENODEV;
>
> No point to call probe(), right?
Originally (before I add the call from ssif_probe()), this is not involved in
the probe() call. Instead, the detect function is involved in calling a
table of addresses in driver->address_list. So in this case this
function is never called at all from the i2c code, since there is no
address list.
>
> > + } else {
> > + struct ipmi_device_id id;
> > +
> > + rv = ipmi_demangle_device_id(resp[0] >> 2, resp[1],
> > + resp + 2, len - 2, &id);
> > + if (rv)
> > + rv = -ENODEV; /* Error means a BMC probably isn't there. */
>
> Same.
>
> > + }
> > + if (!rv && info)
> > strscpy(info->type, DEVICE_NAME, I2C_NAME_SIZE);
> > + }
> > kfree(resp);
> > return rv;
> > }
> > @@ -1704,6 +1716,16 @@ static int ssif_probe(struct i2c_client *client)
> > ipmi_addr_src_to_str(ssif_info->addr_source),
> > client->addr, client->adapter->name, slave_addr);
> >
> > + /*
> > + * Send a get device id command and validate its response to
> > + * make sure a valid BMC is there.
> > + */
> > + rv = ssif_detect(client, NULL);
> > + if (rv) {
> > + dev_err(&client->dev, "Not present\n");
> > + goto out;
> > + }
> > +
>
> The point is that even after this point IPMI device can start failing
> to properly communicate with the OS, real SMBus errors, like EREMOTEIO
> in my case, but unfortunately code bellow do not handle this very well,
> I think.
It is possible that the BMC gets rebooted or something between the call
to ssif_detect() and the code below, but the probability is really low.
If it answers a detect, the rest of the things should work.
-corey
>
>
> > /* Now check for system interface capabilities */
> > msg[0] = IPMI_NETFN_APP_REQUEST << 2;
> > msg[1] = IPMI_GET_SYSTEM_INTERFACE_CAPABILITIES_CMD;
> > --
> > 2.34.1
> >
>
> Regards,
> Ivan
>
next prev parent reply other threads:[~2024-08-22 14:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-16 6:54 [PATCH] ipmi:ssif: Exit early when there is a SMBus error Ivan T. Ivanov
2024-08-16 18:04 ` Corey Minyard
2024-08-18 9:27 ` Ivan T. Ivanov
2024-08-20 10:20 ` Ivan T. Ivanov
2024-08-20 15:31 ` Corey Minyard
2024-08-20 15:42 ` Ivan T. Ivanov
2024-08-21 1:05 ` [PATCH] ipmi:ssif: Improve detecting during probing Corey Minyard
2024-08-22 7:22 ` Ivan T. Ivanov
2024-08-22 14:40 ` Corey Minyard [this message]
2024-08-26 11:31 ` Ivan T. Ivanov
2024-09-10 10:25 ` Ivan T. Ivanov
2024-09-10 11:30 ` Corey Minyard
2024-09-10 12:05 ` Ivan T. Ivanov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZsdN8sBIUYetCUOp@mail.minyard.net \
--to=corey@minyard.net \
--cc=iivanov@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=openipmi-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.