drivers: flash: Add information in build assert on how to get sfdp-bfp

[markus-becker-tridonic-com]

Made the build assert more verbose and explain how to get the value of sfdp-bfp using the jesd216 sample.

[de-nordic]

No.
This should go into documentation and I do not think this is good idea to hardcode sample paths into asserts of drivers.

[markus-becker-tridonic-com]

I recently stumbled over this build assert and had no hint what to do next. I thought of helping others. Would a documentation URL in the build assert be better?

…

________________________________ From: Dominik Ermel ***@***.***> Sent: Tuesday, April 22, 2025 4:30 PM To: zephyrproject-rtos/zephyr ***@***.***> Cc: Becker Markus ***@***.***>; Author ***@***.***> Subject: Re: [zephyrproject-rtos/zephyr] drivers: flash: Add information in build assert on how to get sfdp-bfp (PR #88904) @de-nordic requested changes on this pull request. No. This should go into documentation and I do not think this is good idea to hardcode sample paths into asserts of drivers. — Reply to this email directly, view it on GitHub<#88904 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADMS2VTN6NBWR76Q73SF3U322ZHBFAVCNFSM6AAAAAB3T3PQ3GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDOOBUGMZTGMZUGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

________________________________ The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

[de-nordic]

I recently stumbled over this build assert and had no hint what to do next. I thought of helping others. Would a documentation URL in the build assert be better?

---

From: Dominik Ermel @.***>

Sent: Tuesday, April 22, 2025 4:30 PM

To: zephyrproject-rtos/zephyr @.***>

Cc: Becker Markus @.>; Author @.>

Subject: Re: [zephyrproject-rtos/zephyr] drivers: flash: Add information in build assert on how to get sfdp-bfp (PR #88904)

@de-nordic requested changes on this pull request.

No.

This should go into documentation and I do not think this is good idea to hardcode sample paths into asserts of drivers.

—

Reply to this email directly, view it on GitHub#88904 (review), or unsubscribehttps://github.com/notifications/unsubscribe-auth/ADMS2VTN6NBWR76Q73SF3U322ZHBFAVCNFSM6AAAAAB3T3PQ3GVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDOOBUGMZTGMZUGE.

You are receiving this because you authored the thread.Message ID: @.***>

---

The contents of this e-mail and any attachments are confidential to the intended recipient. They may not be disclosed to or used by or copied in any way by anyone other than the intended recipient. If this e-mail is received in error, please immediately notify the sender and delete the e-mail and attached documents. Please note that neither the sender nor the sender's company accept any responsibility for viruses and it is your responsibility to scan or otherwise check this e-mail and any attachments.

We should have a paragraph in documentation, maybe in dts binding description, on how to generate the table. Not in assertions.

The other question is whether we should not consider giving the sample a new category, a run time info dump tool, because it is weird to resolve to sample to generate crucial build information.