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.
MSC exclusive access support. #8814
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
MSC exclusive access support. #8814
Changes from all commits
fd327d2
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
At which state will tud_msc_remount be called? Only when the device is ejected? Or is it possible that the PC may remount the drive? I cannot do that with my Linux box. If the board has always go through a power cycle, then it's fine.
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.
Assuming that a board with MSC support will start in locally write protected mode. What happens if the board is running stand-alone? Can it tell that there is no MSC mounted? Then the drive must be mounted write enabled.
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.
It gets called when the device is ejected. It may be possible to remount a safely-removed/ejected drive, but I think that disconnects power from the port anyway, I will have to test to confirm. However, I think that's a very unlikely case that shouldn't be handled, not sure if it should remount as read-only after giving write access to the device.
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'm chewing on the timing issue. At the moment, the board starts with write enabled, to be able to create a file system, if it does not exist. Then it mounts the flash drive, which must be write protected if MSC is used. It could decide based on the status of the IOCTL_STATUS call. But how long does that status change take?
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.
OK. So the tud_msc_start_stop_cb() is only called on eject. The ud_msc_inquiry_cb() is called on start, as well as the tud_msc_capacity_cb(). So we could use these as indicator, that a PC is attempting to connect.
The tud_msc_test_unit_ready_cb() is called regularly.
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.
With the softreboot the file is gone. test without the soft reboot.
But I found a possible reason at my set-up: In tud_msc_remount_task() you have a check for
len == 1
. That is the length of the mount point name. On my set-up, the length is 6. So the remount never happens.Changing the it to len == 6, the code is executed, and I can single-step it in the debugger. Then I see a strange phenomenon: while single stepping though unmount, remount, .., the PC still shows: "Unmount in progress, please do not remove the drive". Only after the remount function is finished, this message disappears. So it looks like in addition to the non-matching length check, the remount at the board was too early.
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.
maybe a false alarm: The PC/USB simple code waits for tud_msc_start_stop_cb() to finish.
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.
Yes maybe because you're single stepping the function. The remount is scheduled, so this function returns immediately. Anyway, the mount point of the MSC filesystem should be defined somewhere, or even better if it's detected dynamically somehow, but I'm not sure how to do that.
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 single stepped in the tud_msc_remount_task() function. So I know it is called.
At the moment, the internal flash is the first mounted file system. I do not know if we can reliably assume that this is always the case.
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 we do not find a good solution, we could at least defer opening the file system for write until the next soft boot. That's at least safe.