-
Notifications
You must be signed in to change notification settings - Fork 1.6k
drivers/mtd: Remove bad block management in FTL when it is not needed #19018
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
jerpelea
merged 1 commit into
apache:master
from
tiiuae:remove_bad_block_management_when_not_using_nand
Jun 8, 2026
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@xiaoxiang781216 I don’t agree with enabling this by default for non‑DEFAULT_SMALL configurations. I have several chips that use FTL without bad block management, so it’s unclear why this should be applied universally to those devices. Bad block management is typically only required for NAND-based technologies.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think DEFAULT_SMALL is the correct one here. All of the boards which I am working on are !DEFAULT_SMALL and bad block management is not needed. Only reasonable default that I can think of is really MTD_NAND, because BBM on the host controller side is commonly needed only for raw nand devices. If the motivation behind the suggestion is that there are other than MTD_NAND devices, where default y is wanted, please give an example of that... perhaps we can add some additiona "default y if ..."?
In addition, we could have a DEFAULT_SMALL board using raw nand, in which case the BBM would be needed.
So I'd rather find a reasonable default based on whether the functionality is required or not, and not couple it to DEFAULT_SMALL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if so, please add assert if mtd support isbad or markbad, but FTL_BBM is false.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds reasonable but where? In ftl_open perhaps? DEBUGASSERT?
What if user wants to intentionally disable the bad block management? Perhaps there is no reason to do so...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I agree most of the drivers don't need it. But after this merge request you have to enable
CONFIG_FTL_BBMif you usemtd_partitionto create multiple partitions on your flash device. And that's not a theoretical bug, it's fairly common use case. If you don't enableCONFIG_FTL_BBM, you program runs into the debug assertion, even if your driver doesn't need bad block management. This should be solved by the diff above and we won't have to enableCONFIG_FTL_BBMfor most of the NOR flash devices (perhaps for all of them...). I can create a merge request for the change if you want.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah sorry. Now I understand. The debugassert is definitely wrong! @xiaoxiang781216 I think we should remove that debugassert, and solve the potential misconfiguration you were worried about by other means.
Thanks @michallenc for you patience, sorry for me being so slow to understand what you were saying :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simplest fix would be to just remove the DEBUGASSERT. I can also check if something could be done to make proper compile time check for original purpose why it was suggested to be added.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps something in this direction: #19145 , do you think this would solve the issue @michallenc, @xiaoxiang781216 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or then we can just pick the original patch that @michallenc provided and keep the debugassert?