ASoC: SOF: ext_manifest: Initial submission #1903
Conversation
|
@ktrzcinx We need to squash these changes to the merged series, so can you update this to edit every commit to have summary of: "squash! ASoC: SOF: ext_manifest: parse compiler version" .. with the summary matching the merged commit this patch should be squashed into (before sending upstream). This syntax is used by "git commit --squash " and you can also use it with amending "git commit --amend --squash . |
|
Agree with @kv2019i without clear indications it's likely maintainers will make a mistake when squashing. please provide guidance on what needs to be squashed where, thank you |
ktrzcinx
force-pushed
the
ext-mnf-pr-fix
branch
from
0a74307 to
26d3965
Compare
|
@kv2019i how does the !fixup work? Will be autosquash the patches when we click on rebase and merge the PR? |
ktrzcinx
force-pushed
the
ext-mnf-pr-fix
branch
from
26d3965 to
09a2f2c
Compare
|
@ranj063 wrote:
No, it's not done by GitHub. But when we do a rebase of sof-dev-rebase, then the fixup/squash commits are automatically ordered such that we can easily combine them. You need to have "autoSquash = true" in your .git/config, or pass "--autosquash" to git-rebase. We never rebase sof-dev, so in sof-dev these patches will always stay as they are. This may cause some complications to our scripts for picking reviewed-by tags, though, so something to watch out for. FYI @plbossart |
There was a problem hiding this comment.
To avoid further fixups, I want confirmation that the FW side is merged.
There was a problem hiding this comment.
@ktrzcinx Why are you removing this field? Without it getting to the data would become more difficult. Now you can just do hdr->blob, after this patch this won't be any longer possible. Above you did keep a variable-length .elements[] array, why are you removing .blob[] here?
There was a problem hiding this comment.
@lyakh thesofproject/sof#2427 (comment). Moreover hdr->blob shouldn't be used at all, hdr should be every time casted to type specific struct. Field .elements[] should be deleted in a same way as .blob[], my mistake.
ktrzcinx
force-pushed
the
ext-mnf-pr-fix
branch
2 times, most recently
from
3fb1427 to
ed50f53
Compare
|
All good, now just waiting for thesofproject/sof#2427 to be approved. UPDATE: still waiting for thesofproject/sof#2427 to be merged (some extra steps needed to keep QEMU in CI going on) |
ktrzcinx
force-pushed
the
ext-mnf-pr-fix
branch
from
e85a0a9 to
bed6720
Compare
ktrzcinx
force-pushed
the
ext-mnf-pr-fix
branch
from
bed6720 to
d0b2382
Compare
Extended manifest is a place to store build time known firmware metadata, for example firmware version or used compiler description. Given information is read on host side before firmware startup. This part of output binary is located as a first structure in binary file. Extended manifest should be skipped in firmware loading routine. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
The firmware version can be extracted from the extended manifest content. This information known at build time does not need to be provided in a mailbox. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
ktrzcinx
force-pushed
the
ext-mnf-pr-fix
branch
2 times, most recently
from
713cd69 to
91ffbbf
Compare
sound/soc/sof/loader.c
Outdated
There was a problem hiding this comment.
you compare w_size of memory here, and w_size is calculated from w->num_windows, and w->num_windows is only verified below to be valid. So, for example if w->num_windows == 0 the below check would return -EINVAL, but in case of sdev->info_window != NULL you now return 0 in this case? Which one is correct?
There was a problem hiding this comment.
Such an issue would be properly handled, because for w->num_windows == 0 w->num_windows will differ from sdev->info_window->num_windows for sure (condition in line 24/33). Event that I changed order of those checks, to make it more obvious.
The window description can be extracted from the extended manifest content. This information known at build time does not need to be provided in a mailbox. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
The compiler version and description can be extracted from the extended manifest content. This information known at build time does not need to be provided in a mailbox. Signed-off-by: Karol Trzcinski <karolx.trzcinski@linux.intel.com>
|
@ranj063 This is ready to go, but you still have pending changes-requested, so can you check that? |
|
Please review the 2-lines long, PR #2091 fixup! for the crash below |
6 participants
Some minor fixes proposed by @lyakh in #1818