[nvmewin] ***UNCHECKED*** Aug 9 - Patch (mainly IOCTL stuff, some general cleanup as well)

[Chang, Alex]

Hi Paul,

Some questions after browsing the difference between current source and your changes:
1. Why you removed "CC.SHN  = 1;" in NVMeNormalShutdown routine?
2. In nvme.h, why you changed the opcode of NVM_DATASET_MANAGEMENT from 0x06 to 0x09?
3. Is there any specific reason(s), you added the following in NVMeInitialize, and then immediately clear EN without checking RDY = 1?
    /* Set EN to 1 (all others zero) */
    CC.EN = 1;
    StorPortWriteRegisterUlong(pAE,
                               (PULONG)(&pAE->pCtrlRegister->CC),
                               CC.AsUlong);

Thanks,
Alex


________________________________
From: nvmewin-bounces at lists.openfabrics.org [mailto:nvmewin-bounces at lists.openfabrics.org] On Behalf Of Luse, Paul E
Sent: Thursday, August 09, 2012 7:58 AM
To: nvmewin at lists.openfabrics.org
Subject: [nvmewin] ***UNCHECKED*** Aug 9 - Patch (mainly IOCTL stuff, some general cleanup as well)

All-

Here's the next patch (pw is intel123), main focus is really IOCTL handling with some other small fixes as well.  I'll be looking for feedback/approval by the end of next week (Aug 17); please let me know if you need more time.   Tested as per our guidelines, no issues.

Alex, you mentioned having some power transition changes almost ready - following acceptance of this patch can you being to prepare that one?

Thx
Paul

PS:  note that the SVN repo changed recently.  Make sure you are setup according to the updated website as shown below:
NVM Express for Windows subversion repository (SVN) can be accessed using an SVN client at the following:

  *   svn://beany.openfabrics.org/nvmewin (note that the directory is case-sensitive)
  *   http://beany.openfabrics.org/svn/nvmewin (note that the directory is case sensitive)
- minor cleanup (some prints, extra chatham1 stuff, etc).  There were a few "odd" issues in the trunk and I think we may have had some merge issues with the recent SVN change so once this is pushed be sure to update!
- bug fix for reset handling:  q ptrs were being reset to 0 in the wrong locations
- bug fix:  we weren't honoring the supports VWC bit in some SNTI routines
- updates to format (NVM) handling based on new lunExt changes
- slight change to how we handle initial touch of HW.  Before we forced a reset by setting EN to 1 then reading it back then writing 1.  We had a report of IHV HW where this was causing an issue because their interpretation of the spec, and thus their implementation, expected nothing to happen after setting EN to 1 until RDY is set, including setting EN back to 0.  Rather than add an additional wait it seems reasonable to check if EN is already set and if so then set it to 0 to force an initial reset.  If its 0 to begin with the n its either just been powered on (thus reset) or it made a transition from  1?0 thus was just reset.  No change to where we enable the card for the first time, that's still in the init state machine
- lots of structural rework in the IOCTL handlers.  See code for details, let me know if there are questions, either as to what or why things were shuffled around.  The initial implementation didn't take into account the need for IHVs to define their own private IOCTLs so decode need to be added/changed accordingly.  Also, some IOCTLs need processing in startIO only (some private ones) and we didn't have a framework setup very well for that either.
- removed a few no-op IOCTL placeholders.  Note that NVMe does not define specific private IOCTLs other than the NVME PT IOCTL.  We need (eventually, Intel will propose one soon if someone else doesn't) a standard struct to define a private IOCTL if we want one, or if IHVs want to define their own and keep both it and their private IOCTLs our of OFA that's fine.  I left 2 privates in there (hot add, hot remove) because they don't have a corresponding structure, they're basically just op codes.
- added a few IOCTLs for Msft public SMART commands (caused rework of the IOCTL generic callback)




____________________________________
Paul Luse
Sr. Staff Engineer
PCG Server Software Engineering
Desk: 480.554.3688, Mobile: 480.334.4630

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openfabrics.org/pipermail/nvmewin/attachments/20120810/4d6ed7b8/attachment.html>