Current main branch does no longer compile on Arch, kernel 6.6.1

[nursoda]

Build the kernel module:
make -C /lib/modules/6.6.1-arch1-1/build M=…/xmm7360-pci modules
make[1]: Verzeichnis „/usr/lib/modules/6.6.1-arch1-1/build“ wird betreten
  CC [M]  …/xmm7360-pci/xmm7360.o
…/xmm7360-pci/xmm7360.c: In Funktion »xmm7360_irq0«:
…/xmm7360-pci/xmm7360.c:1195:13: Warnung: der Vergleich wird immer als »true« ausgewertet, da die Adresse von »td_ring« niemals NULL sein wird [-Waddress]
 1195 |         if (xmm->td_ring) {
      |             ^~~
…/xmm7360-pci/xmm7360.c:209:24: Anmerkung: »td_ring« ist hier deklariert
  209 |         struct td_ring td_ring[16];
      |                        ^~~~~~~
…/xmm7360-pci/xmm7360.c: Auf höchster Ebene:
…/xmm7360-pci/xmm7360.c:1346:18: Fehler: Initialisierung von »ssize_t (*)(struct tty_struct *, const u8 *, size_t)« {alias »long int (*)(struct tty_struct *, const unsigned char *, long unsigned int)«} von inkompatiblem Zeigertyp »int (*)(struct tty_struct *, const unsigned char *, int)« [-Werror=incompatible-pointer-types]
 1346 |         .write = xmm7360_tty_write,
      |                  ^~~~~~~~~~~~~~~~~
…/xmm7360-pci/xmm7360.c:1346:18: Anmerkung: (nahe der Initialisierung für »xmm7360_tty_ops.write«)
cc1: Einige Warnungen werden als Fehler behandelt
make[3]: *** [scripts/Makefile.build:243: …/xmm7360-pci/xmm7360.o] Fehler 1
make[2]: *** [/usr/lib/modules/6.6.1-arch1-1/build/Makefile:1913: …/xmm7360-pci] Fehler 2
make[1]: *** [Makefile:234: __sub-make] Fehler 2
make[1]: Verzeichnis „/usr/lib/modules/6.6.1-arch1-1/build“ wird verlassen
make: *** [Makefile:9: default] Fehler 2

[vebodev]

I met the save error from GCC. This is what I did to change.

diff --git a/xmm7360.c b/xmm7360.c
index f571d9c..7ac1157 100644
--- a/xmm7360.c
+++ b/xmm7360.c
@@ -1262,8 +1262,8 @@ static void xmm7360_tty_close(struct tty_struct *tty, struct file *filp)
                tty_port_close(&qp->port, tty, filp);
 }

-static int xmm7360_tty_write(struct tty_struct *tty,
-                            const unsigned char *buffer, int count)
+static long int xmm7360_tty_write(struct tty_struct *tty,
+                            const unsigned char *buffer, long unsigned int count)
 {
        struct queue_pair *qp = tty->driver_data;
        int written;

[nursoda]

@vebodev 👍🏻 wfm. Would you please explain how you found what to change?

Would you care to provide a PR or shall I create one from your patch?

Do you know whether one would need to distinguish kernel versions and have different code depending on the kernel version?

[pswiatki]

Well.... Perhaps switching to iosm is a good idea at this point?

211 describes the steps and I verified it worked nicely.

[vebodev]

@vebodev 👍🏻 wfm. Would you please explain how you found what to change?

Would you care to provide a PR or shall I create one from your patch?

Do you know whether one would need to distinguish kernel versions and have different code depending on the kernel version?

Although the compiling is passed, I haven't make the driver work properly yet. I will submit a PR after all is done.

[vebodev]

Well.... Perhaps switching to iosm is a good idea at this point? #211 describes the steps and I verified it worked nicely.

@pswiatki Thanks for your advice, I finally made it work.

I will make a PR for what I have done

[nursoda]

Although compiling passed, I haven't make the driver work properly yet

I did not try with iosm. What I did: compile as usual (yields warnings), load the kernel module, wait for ~10 sec., start once (hangs), abort, start again. That does work for me. That btw is what I always have to do. I never managed to load and start in one go.

[pswiatki]

The problem with iosm is that it fails after the system is brought up from hibernation. I don't know enough about inner workings of iosm to track it down further, but have just double checkded it. Restarted Arch Linux from scratch and, sure enough, got connected easily:

RPC executing UtaRPCPSConnectSetupReq
b'4601000002040000014602040000007d11000100020100020400000000020400000000020400000000020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020100020400000000551402040000001702040000000300000000000000000000000000000000000000000000000204ffffffff0204000000320204000000010204000000030204000000050201000201fa0201000201fa0201000201000201ff0201ff0201010201120201060201070201fe0201fe02019602010302010202010302010102011f02010902010102010302010102010502040000000155140204000000160204000000020acbd535000000000000000000000000000000000000020400000000020400000000020400020017020400000000'
response: 0x0
name:lo uuid:XXX type:loopback
setup NNN
setup connection
Traceback (most recent call last):
  File "/home/pswiatki/devel/HW/LTE_modem_m.2/xmm7360-pci/scripts/../rpc/open_xdatachannel.py", line 240, in <module>
    manager.ActivateConnection(connection_path, devpath, "/")
                                                ^^^^^^^
NameError: name 'devpath' is not defined

[pswiatki]

OK, after reading this discussion and testing on my DELL Precision 3561 I confirm the following steps bring the modem back to a proper state after wakeup from suspend/hibernation:

To establish the PCI device number:

# ls -al /sys/bus/pci/drivers/iosm/
total 0
drwxr-xr-x  2 root root    0 Apr 28 02:01 .
drwxr-xr-x 33 root root    0 Apr 28 02:01 ..
lrwxrwxrwx  1 root root    0 Apr 28 02:01 0000:73:00.0 -> ../../../../devices/pci0000:00/0000:00:1c.0/0000:73:00.0
[...]
#

Then PCI device reset, remove and bus rescan, as follows:

# echo 1 >  /sys/bus/pci/devices/<PCI_address_from_previous_step>/reset
# echo 1 >  /sys/bus/pci/devices/<PCI_address_from_previous_step>/remove 
# echo 1 >  /sys/bus/pci/rescan 
#

Then lte.sh up works perfectly again.