From: "Rojewski, Cezary" <cezary.rojewski@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: "pierre-louis.bossart@linux.intel.com"
<pierre-louis.bossart@linux.intel.com>,
"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"Kaczmarski, Filip" <filip.kaczmarski@intel.com>,
"N, Harshapriya" <harshapriya.n@intel.com>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"Barlik, Marcin" <marcin.barlik@intel.com>,
"zwisler@google.com" <zwisler@google.com>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"tiwai@suse.com" <tiwai@suse.com>,
"Proborszcz, Filip" <filip.proborszcz@intel.com>,
"broonie@kernel.org" <broonie@kernel.org>,
"amadeuszx.slawinski@linux.intel.com"
<amadeuszx.slawinski@linux.intel.com>,
"Wasko, Michal" <michal.wasko@intel.com>,
"cujomalainey@chromium.org" <cujomalainey@chromium.org>,
"Hejmowski, Krzysztof" <krzysztof.hejmowski@intel.com>,
"Papierkowski, Piotr \(Habana\)" <ppapierkowski@habana.ai>,
"Gopal, Vamshi Krishna" <vamshi.krishna.gopal@intel.com>
Subject: RE: [PATCH v7 03/14] ASoC: Intel: catpt: Add IPC message handlers
Date: Mon, 21 Sep 2020 20:48:12 +0000 [thread overview]
Message-ID: <191afe965b1e46799bf776be3254d28f@intel.com> (raw)
In-Reply-To: <20200921184129.GH3956970@smile.fi.intel.com>
On 2020-09-21 8:41 PM, Andy Shevchenko wrote:> On Mon, Sep 21, 2020 at 06:13:59PM +0000, Rojewski, Cezary wrote:
>> On 2020-09-21 2:59 PM, Andy Shevchenko wrote:
>>> On Mon, Sep 21, 2020 at 01:54:13PM +0200, Cezary Rojewski wrote:
...
>>>> + for (i = j = 0; i < FW_INFO_SIZE_MAX; i++)
>>>> + if (cdev->ipc.config.fw_info[i] == ' ')
>>>> + if (++j == 4)
>>>> + break;
>>>
>>>> + for (j = ++i; j < FW_INFO_SIZE_MAX && j - i < 20; j++) {
>>>
>>> This should have static_assert() at the place where you define both constants
>>> (2nd is mentioned above 20).
>>>
>>>> + if (cdev->ipc.config.fw_info[j] == ' ')
>>>> + break;
>>>> + *(pos + j - i) = cdev->ipc.config.fw_info[j];
>>>> + }
>>>> + pos += 20;
>>>
>>> These two for-loops should have some comment to explain what's going on.
>>>
>>
>> Actually, after poking my FW friends again I realized that it's just
>> dumping 20chars from "hash" segment of fw_info (struct catpt_fw_ready,
>> field: fw_info[]).
>>
>> So, this could be replaced by:
>>
>
>> /* navigate to fifth info segment (fw hash) */
>> for (i = j = 0; i < FW_INFO_SIZE_MAX; i++)
>> /* info segments are separated by space each */
>> if (cdev->ipc.config.fw_info[i] == ' ')
>> if (++j == 4)
>> break;
>
> ...and this is repeating strnchr() / strnchrnul().
>
Indeed, will incorporate into above.
> With the questions "what if...":
> - nul in the middle of this?
> - less than 4 spaces found?
>
While this should never happen (means user is somehow not making use of
officially released firmware binary), coredumps are useful only if you
have access to debug tools. In cases you'd mentioned, invalid hash would
have been dumped to coredump and crash reader simply wouldn't have been
able to navigate to actual build for it. The rest of the coredump is still
vital though.
memcpy() could be gated behind an 'if' for safety if needed:
info = cdev->ipc.config.fw_info;
eof = info + FW_INFO_SIZE_MAX;
/* navigate to fifth info segment (fw hash) */
for (i = 0; i < 4 && info < eof; i++, info++)
/* info segments are separated by space each */
if ((info = strnchr(info, eof - info, ' ')) == NULL)
break;
if (i == 4 && info < eof)
memcpy(pos, info, min(eof - info, CATPT_DUMP_HASH_SIZE));
Didn't compile this, some typecheck fixes might be in order and so on.
>> memcpy(pos, &cdev->ipc.config.fw_info[++i], CATPT_DUMP_HASH_SIZE);
>> pos += CATPT_DUMP_HASH_SIZE;
>>
>>
>> Existing for-loops were based on internal solution. Half of the code
>> isn't needed afterall..
>
next prev parent reply other threads:[~2020-09-21 20:49 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-21 11:54 [PATCH v7 00/14] ASoC: Intel: Catpt - Lynx and Wildcat point Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 01/14] ASoC: Intel: Add catpt base members Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 02/14] ASoC: Intel: catpt: Implement IPC protocol Cezary Rojewski
2020-09-21 13:00 ` Andy Shevchenko
2020-09-21 17:57 ` Rojewski, Cezary
2020-09-21 11:54 ` [PATCH v7 03/14] ASoC: Intel: catpt: Add IPC message handlers Cezary Rojewski
2020-09-21 12:59 ` Andy Shevchenko
2020-09-21 13:58 ` Amadeusz Sławiński
2020-09-21 14:20 ` Andy Shevchenko
2020-09-21 14:23 ` Andy Shevchenko
2020-09-21 18:14 ` Rojewski, Cezary
2020-09-21 18:13 ` Rojewski, Cezary
2020-09-21 18:41 ` Andy Shevchenko
2020-09-21 20:48 ` Rojewski, Cezary [this message]
2020-09-22 9:04 ` Andy Shevchenko
2020-09-22 11:04 ` Rojewski, Cezary
2020-09-22 11:29 ` Andy Shevchenko
2020-09-22 11:30 ` Andy Shevchenko
2020-09-22 11:56 ` Rojewski, Cezary
2020-09-21 11:54 ` [PATCH v7 04/14] ASoC: Intel: catpt: Define DSP operations Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 05/14] ASoC: Intel: catpt: Firmware loading and context restore Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 06/14] ASoC: Intel: catpt: PCM operations Cezary Rojewski
2020-09-21 14:08 ` Andy Shevchenko
2020-09-21 18:50 ` Rojewski, Cezary
2020-09-21 11:54 ` [PATCH v7 07/14] ASoC: Intel: catpt: Device driver lifecycle Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 08/14] ASoC: Intel: catpt: Event tracing Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 09/14] ASoC: Intel: catpt: Simple sysfs attributes Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 10/14] ASoC: Intel: haswell: Remove haswell-solution specific code Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 11/14] ASoC: Intel: broadwell: " Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 12/14] ASoC: Intel: bdw-5650: " Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 13/14] ASoC: Intel: bdw-5677: " Cezary Rojewski
2020-09-21 11:54 ` [PATCH v7 14/14] ASoC: Intel: Select catpt and deprecate haswell Cezary Rojewski
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=191afe965b1e46799bf776be3254d28f@intel.com \
--to=cezary.rojewski@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=cujomalainey@chromium.org \
--cc=filip.kaczmarski@intel.com \
--cc=filip.proborszcz@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=harshapriya.n@intel.com \
--cc=krzysztof.hejmowski@intel.com \
--cc=lgirdwood@gmail.com \
--cc=marcin.barlik@intel.com \
--cc=michal.wasko@intel.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ppapierkowski@habana.ai \
--cc=tiwai@suse.com \
--cc=vamshi.krishna.gopal@intel.com \
--cc=zwisler@google.com \
/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.