Support for linux kernel 5.8 and greater

[vetlewi]

The drivers had issues compiling on kernels newer than 5.8 since there was a change in the mmap locking API. I've made changes such that the driver now compiles on newer kernels. I've been able to compile it on 6.20. Note that I've not yet been able to test it with actual hardware, so it may or may not work. I've marked the PR as draft until I get to test the fix.

NOTE: Not yet tested

[rmathar]

i) The patch of replacing the #include <linux/vermagic.h> should not only
modify Driver/Source.Plx9000/Driver.c but also Driver/Sourc.Plx6000_NT/Driver.c,
Driver/Source.Plx8000_DMA/Driver.c, Driver/Source.Plx8000_NT/Driver.c and
Driver/Source.PlxSvc/Driver.c

ii) It is desirable to remove the compiler warnings by replacing
the obsolete use of ftime() calls as follows

--- PlxApi.orig/SpiFlash.c      2020-11-17 20:37:55.000000000 +0100
+++ PlxApi/SpiFlash.c   2023-11-23 16:09:10.126467155 +0100
@@ -49,7 +49,7 @@


 #include <string.h>     // For memset()/memcpy()
-#include <sys/timeb.h>  // For ftime()
+#include <sys/time.h>  // For getttimeofday()
 #include "SpiFlash.h"
 #include "PlxApiDebug.h"

@@ -764,12 +764,13 @@
     U32          regVal;
     U32          elapsedTimeMs;
     PLX_STATUS   status;
-    struct timeb endTime;
-    struct timeb startTime;
+    struct timeval endTime;
+    struct timeval startTime;
+    struct timeval deltaTime;


     // Note start time
-    ftime( &startTime );
+    gettimeofday( &startTime, NULL );

     // Wait until command valid is clear
     do
@@ -790,8 +791,9 @@
         }

         // Verify we don't exceed poll time
-        ftime( &endTime );
-        elapsedTimeMs = (U32)(PLX_DIFF_TIMEB( endTime, startTime ) * 1000);
+        gettimeofday( &endTime, NULL );
+        timersub(& startTime, & endTime, &deltaTime) ;
+        elapsedTimeMs = (U32)( deltaTime.tv_sec*1000+deltaTime.tv_usec/1000 );
         if (elapsedTimeMs >= SPI_MAX_WAIT_CTRL_READY_MS)
         {
             ErrorPrintf((

iii) On Alma Linux 9.1 and 9.2 (but not on Alma Linux 8.8, CentOS, openSUSE 15.5, Ubuntu)
I had to replace the GFP_KERNEL | __GFP_NOWARN in the function dma_alloc_coherent
in the file SuppFunc.c by GFP_ATOMIC to avoid kernel panic during the Plx_load phase.

--- Driver.orig/Source.Plx9000/SuppFunc.c       2023-11-27 22:33:46.367380271 +0100
+++ Driver/Source.Plx9000/SuppFunc.c    2023-12-06 16:08:23.857310300 +0100
@@ -615,7 +615,12 @@
             &(pdx->pPciDevice->dev),
             pMemObject->Size,
             &BusAddress,
+#if 0
             GFP_KERNEL | __GFP_NOWARN         
+#else       
+            // this to avoid failure on Alma 9.x 
+            GFP_ATOMIC
+#endif      
             );
             
     if (pMemObject->pKernelVa == NULL)
@@ -626,6 +631,25 @@
     // Store the bus address
     pMemObject->BusPhysical = (U64)BusAddress;
             
+#if 1       
+    // Check that the pages in the correct range (avoid kernel panic on Alma 9.x)
+    for (virt_addr = (PLX_UINT_PTR)pMemObject->pKernelVa;
+         virt_addr < ((PLX_UINT_PTR)pMemObject->pKernelVa + pMemObject->Size);
+         virt_addr += PAGE_SIZE)
+    {
+        if ( ! virt_addr_valid( PLX_INT_TO_PTR(virt_addr) ) )
+        {
+            dma_free_coherent(
+                &(pdx->pPciDevice->dev),
+                pMemObject->Size,
+                pMemObject->pKernelVa,
+                (dma_addr_t)pMemObject->BusPhysical
+                );
+           return NULL ;
+        }
+    }
+#endif
+
     // Tag all pages as reserved
     for (virt_addr = (PLX_UINT_PTR)pMemObject->pKernelVa;
          virt_addr < ((PLX_UINT_PTR)pMemObject->pKernelVa + pMemObject->Size);

[The kernel panic occurs when the loop in ApiFunc.c with decremented sizes
of the pMemObject->Size reaches the phase where it tries to allocate negative sizes...]
I did not check whether that patch is also needed on equivalent Rocky Linux 9.x
Red Hat 9.x OSs, or whether such a patch would corrupt the loading on the other operating systems.

This is from experience with the 8311 and 9656 broadcomm chips.