common.h: Guard definition of IS_ALIGNED for Zephyr builds #8708
Conversation
yonsch
requested review from
lgirdwood,
plbossart,
mmaka1,
lbetlej,
dbaluta and
kv2019i
as code owners
|
Can one of the admins verify this patch?
|
There was a problem hiding this comment.
There is another place in Zephyr also defined this in zephyr code, could you change zephyr code as well?
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/crypto/crypto_intel_sha_priv.h#L33
| #define IS_ALIGNED(size, alignment) ((size) % (alignment) == 0) | ||
| #else | ||
| #include <zephyr/sys/util.h> | ||
| #endif |
There was a problem hiding this comment.
this is referring to zephyrproject-rtos/zephyr#67243 which isn't merged yet, right? So if we merge this first this will break Zephyr builds? This cannot be merged like this. A simple solution would be to use #ifnder IS_ALIGNED as a guard.
There was a problem hiding this comment.
Long term we move this and other common Zephyr re-definitions to the xtos header directory for remaining xtos users and pull this directly from Zephyr.
common.h defines the IS_ALIGNED macro, which conflicts with a Zephyr macro of the same name. Add guards to define it only if it is not already defined by Zephyr. Signed-off-by: Yonatan Schachter <[email protected]>
yonsch
force-pushed
the
zephyr_is_aligned
branch
from
1d46d59 to
514020f
Compare
|
Looks like some CI has timed out - restart CI. |
|
SOFCI TEST |
|
@wszypelt This PR seems to have got stuck in quickbuild, can you check. |
| /* Align the number to the nearest alignment value */ | ||
| #ifndef IS_ALIGNED |
There was a problem hiding this comment.
Except for "extreme" cases, #ifndef is always best avoided because it makes the usual, horrible macro experience even worse. Zephyr forbids it: https://docs.zephyrproject.org/latest/contribute/coding_guidelines/index.html#rule-a-3-macro-name-collisions
As requested in zephyrproject-rtos/zephyr#67243 (comment), please rename this SOF_ALIGN() and make everything simpler: backwards and forwards compatibility and trannsitions
There was a problem hiding this comment.
@marc-hb Can you do a follow-up on SOF side. This is sufficient for now to unblock the integration of Zephyr side IS_ALIGNED. SOF can move to other naming on its own pace.
There was a problem hiding this comment.
Can you do a follow-up on SOF side.
Submitted in #8755
common.h defines the IS_ALIGNED macro, which conflicts with a Zephyr macro of the same name. Add guards to define it only if it is not already defined by Zephyr.