From: Jeremy Kerr <jk@ozlabs.org>
To: OpenBMC Patches <openbmc-patches@stwcx.xyz>, openbmc@lists.ozlabs.org
Cc: Nan Li <bjlinan@cn.ibm.com>
Subject: Re: [PATCH openpower-host-ipmi-oem v3] Fix issue5 for endian safe
Date: Mon, 30 May 2016 14:06:59 +0800 [thread overview]
Message-ID: <574BD883.7030004@ozlabs.org> (raw)
In-Reply-To: <20160527120039.11133-2-openbmc-patches@stwcx.xyz>
Hi Nan,
> @@ -29,9 +30,8 @@ ipmi_ret_t ipmi_ibm_oem_partial_esel(ipmi_netfn_t netfn, ipmi_cmd_t cmd,
> esel_request_t *reqptr = (esel_request_t*) request;
> FILE *fp;
> int r = 0;
> - // TODO: Issue 5: This is not endian-safe.
> - short *recid = (short*) &reqptr->selrecordls;
> - short *offset = (short*) &reqptr->offsetls;
> + short recid = le16toh((((unsigned short) reqptr->selrecordms) << 8) + reqptr->selrecordls);
> + short offset = le16toh((((unsigned short) reqptr->offsetms) << 8) + reqptr->offsetls);
I think that this is less correct than the first attempt, and that's
probably due to an incorrect suggestion from me. Sorry for that.
I've only just noticed that you're using different members of the reqptr
struct to construct that 16-bit value; so your first patch probably did
the right thing.
However: we should fix the actual source of the problem - that the
fields in struct esel_request_t are unnecessarily split into uint8_t
fields.
I think it'd be much better if we changed esel_request_t to this:
struct esel_request_t {
uint16_t resid;
uint16_t selrecord;
uint16_t offset;
uint8_t progress;
} __attribute__ ((packed)) ;
- and did the proper conversion with le16toh().
[Also, the typo in the commit title is still present]
Regards,
Jeremy
next prev parent reply other threads:[~2016-05-30 6:07 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-27 12:00 [PATCH openpower-host-ipmi-oem v3] Fix endianness issue5 OpenBMC Patches
2016-05-27 12:00 ` [PATCH openpower-host-ipmi-oem v3] Fix issue5 for endian safe OpenBMC Patches
2016-05-30 6:06 ` Jeremy Kerr [this message]
2016-06-03 3:41 ` Nan KX Li
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=574BD883.7030004@ozlabs.org \
--to=jk@ozlabs.org \
--cc=bjlinan@cn.ibm.com \
--cc=openbmc-patches@stwcx.xyz \
--cc=openbmc@lists.ozlabs.org \
/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.