SCSI Eject events are obscured by the STMicro USB drivers. Is there a bug in the driver?

[Rstua.1]

I have a STM32 based device which switches on command from a USB/CDC device to a USB/MSC device. What I need now is a way to switch the STM32 based device back to USB/CDC.  I see where the SCSI Eject command is processed and reported by the STMicro drivers to my code.  This in fact works.  However, I find I need to send the Eject command twice.  This is unexpected.

Using a debugging tool, I break on my code and see not until the 2nd SCSI Eject command does the STMicro flag change state to EJECT (possible STMicro driver states: EJECT, LOCKED & UN-LOCKED). But, when debugging the STMicro driver its self, I see where the STMicro flag is being set to EJECT upon the 1st SCSI Eject command!  However, this gets obscured because the STMicro driver also sets this flag to either LOCKED or UN-LOCKED depending on if the USB/MSD is mounted or not mounted during the time of the SCSI Ejection.

Why is this?  Why can not the STMicro driver use an independent flag for each state?  Or, is it possible I am using the driver incorrectly? 

-thanks

[Rstua.1]

Added later . . .

The STMicro code that reports all SCSI Eject events but likely is also over-writing the 1st SCSI Eject event and only allowing the 2nd SCSI Eject event to be seen by the application is inside file usbd_msc_scsi.c.  I set a break point on the line where hmsc->scsi_medium_state is set to SCSI_MEDIUM_EJECTED and broke for all SCSI Eject events.

if ((params[4] & 0x3U) == 0x1U) /* START=1 */
{
hmsc->scsi_medium_state = SCSI_MEDIUM_UNLOCKED;
}
else if ((params[4] & 0x3U) == 0x2U) /* START=0 and LOEJ Load Eject=1 */
{
hmsc->scsi_medium_state = SCSI_MEDIUM_EJECTED;
}
else if ((params[4] & 0x3U) == 0x3U) /* START=1 and LOEJ Load Eject=1 */
{
hmsc->scsi_medium_state = SCSI_MEDIUM_UNLOCKED;
}
else
{
/* .. */
}

However, a similar break point was set in the Application which tests for SCSI_MEDIUM_EJECTED.  This only broke upon the 2nd SCSI Eject.  Upon closer inspection, the tested variable was set to either SCSI_MEDIUM_UNLOCKED or SCSI_MEDIUM_LOCKED after the 1st SCSI Eject was issued.  It was expected the variable to be set to SCSI_MEDIUM_EJECTED after the 1st SCSI Eject attempt.

[Rstua.1]

Added later ...

I should also point out that while connected to a Win10 box the Win10 eject (from an instance of File Explorer) works with my STMicro software to revert my STMicro processor based device from USB/MSC to USB/CDC mode every time.  It is only when connected to a Linux / Ubuntu box when I start to have problems.  With Linux, I can see where the STMicro HAL code will detect a SCSI Eject every time the Linux box send an eject.  However, since the STMicro HAL also test for LOCKED and UNLOCKED and uses the same variable to report those states, the EJECT usually is over written.  I found that my only solution was to send many Linux SCSI eject commands to the STMicro HAL code in hopes that 1 would get to my STMicro code and revert my STMicro processor based device from USB/MSC to USB/CDC mode.

[Rstua.1]

What is the best way ...

What is the best way to suggest a change to the STMicro USB driver code?  Is it to find the code on GITHUB.COM, clone the project and make a pull-request?

I would like to explore changing the above STMicro USB driver code to allow exposure of each of these state to the clients code.  I believe the EJECT state is being overwritten before the client code is able to "see" it and respond to an EJECT event.

[Pavel A.]

Yes, a normal github pull request would be good. Even if they won't accept it "as is" it will be easy to review and comment.