Re: is anyone maintaining hifn(4)?

> Can you be more specific about the issues?  Can you say more about
> your use case?

i'll go into one of the issues in more detail below.

as far as my use case goes, i have quite a lot of old and slow hardware, =
which is one of the reasons i use and like netbsd, since it works on all =
of it. i like to test modern software with this hardware under netbsd, =
and fix issues when they crop up. much of my hardware is usable for many =
things, but consistently are slowed to a crawl by cryptographic =
operations.=20

as an example, one of my 486 machines is currently running a rust-based =
server for the matrix chat protocol, called conduit (i have some other =
patches related to this that i'm going to be sending as well, in other =
parts of the kernel, which may serve to reduce userland maintenance =
burden related to 486 systems). it runs surprisingly well, but my =
experience with this and other servers on this machine is that tls is =
the slowest and most resource intensive part of the server. since these =
cards are already able to accelerate tls 1.2 via accelerating aes in =
cbc-mode, i'm interested in ensuring they work with the entire software =
stack, and installing them in several of my machines. if possible, i =
would also like this card to be able to accelerate aes in ccm-mode and =
gcm-mode. the chip offers acceleration for aes-ctr, which people who =
know more about aes than i do tell me should be usable for this purpose, =
so down the line i want to investigate that.

also, since soekris was the primary source of these cards that i am =
aware of, and they are no longer manufacturing them (and the remainder =
of their stock is presumably dwindling), i have been considering =
sourcing some hifn chips and producing new cards of my own. with an open =
source board design, for people with similar needs.

> What do you mean by `currently disabled'?  It looks like hifn(4) is
> included in amd64/GENERIC and i386/GENERIC, at least.

i saw a commit from 2020 that mentioned disabling hifn. i haven't tested =
this or tried to build hifn on current, so if this is wrong then just =
ignore me.

> If you have any patches, I'd be happy to take a look.  (Can't test on
> my device right now but I'll eventually have access to it again.)

sure. a small patch follows, which fixes three things:

first, the original code programmed a value that set a bit which is =
supposed to be disabled. since the reserved registers are not all zero, =
i assume them to be meaningful, and so this could cause undefined =
behavior in the chip's operation.=20

second, the PLL register is hard-configured to rely on the host bus =
clock, and sets a fixed multiplier value based on that. the host bus =
clock is not necessarily stable or known, so this is not the best =
approach - since the device is pci 2.1 compatible and can support a =
66mhz bus (and will report this), it's possible for it to be overclocked =
to twice what it is rated for. on other systems with slower bus clocks, =
it is possible that it could be underclocked. i looked at the hardware =
that i have (soekris vpn1401) as well as photos of all =
hifn7954/7955/7956 hardware i could find, and they appear all to have =
33mhz reference clocks. since netbsd does not seem to have a way to =
query bus speed, i rewrote the register to instead rely on the onboard =
reference clock.

finally, the datasheet emphasizes a specific set of operations for =
correctly programming the PLL register, and says that doing otherwise =
may result in incorrect operation. i updated the code to do this, which =
requires three separate values to be programmed in order to reach the =
final setting, with a delay between.

i've tested this on several machines - on all the machines i have that =
already work with this card, it behaves identically in speed and =
correctness of operation. on a 486 machine with PCI that is my intended =
target for this card, the original driver would cause the machine to =
hang with no output during boot. with the new code, this no longer =
happens. i noticed that there's a similar reported issue with the =
soekris net4501 router hardware. i will soon own that hardware and will =
be testing with that as well.  there is still error on the 486 while =
enabling the card's cryptographic engine that i have not yet tracked =
down, but it does at least boot reliably now. expect a future patch once =
i find the issue.

if it's possible, at some point in the future i'd like to rewrite the =
driver so that the clock source and multiplier are configurable, rather =
than using a hard-coded value.

diff -r a/sys/dev/pci/hifn7751reg.h b/sys/dev/pci/hifn7751reg.h
364c364,373
< #define       HIFN_PLL_7956           0x00001d18      /* 7956 PLL =
config value */
---
>=20
> /* 7956 PLL config values=20
>  *
>  * set PLL to use onboard reference, rather than a potentially
>  * unknown and unstable bus clock. setting PLL correctly requires
>  * three steps.=20
>  */
> #define HIFN_PLL_7956_INIT    0x00001c03 /* initial state, setting pll =
clock source */
> #define HIFN_PLL_7956_INIT2   0x00001c01 /* after PLL stabilizes, =
clear PLL bypass bit */
> #define       HIFN_PLL_7956           0x00001c19 /* set packet and key =
engines to use PLL */
hakase$ diff -u -p1 -r a/sys/dev/pci b/sys/dev/pci
diff: `-1' option is obsolete; use `-U 1'
diff: Try `diff --help' for more information.
hakase$ diff -u -r a/sys/dev/pci b/sys/dev/pci    =20
diff -u -r a/sys/dev/pci/hifn7751.c b/sys/dev/pci/hifn7751.c
--- a/sys/dev/pci/hifn7751.c    2018-12-27 06:03:54.000000000 -0800
+++ b/sys/dev/pci/hifn7751.c    2021-07-17 23:42:13.371790047 -0700
@@ -1073,6 +1073,17 @@
                WRITE_REG_0(sc, HIFN_0_PUCNFG, HIFN_PUCNFG_COMPSING |
                    HIFN_PUCNFG_TCALLPHASES |
                    HIFN_PUCNFG_TCDRVTOTEM | HIFN_PUCNFG_BUS32);
+               /* per datasheet: set PLL speed and charge current,
+                * and turn on the PLL bypass */
+               WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956_INIT);
+               /* then, wait at least 10ms for the PLL to lock */
+               kpause("hifnpll", false, mstohz(10), NULL);
+               /* then, disable PLL bypass */
+               WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956_INIT2);
+               /* pause again for good measure */
+               kpause("hifnpll", false, mstohz(10), NULL);
+               /* write the final PLL config value, with packet engine =
and
+                * key engine set to use the PLL output */
                WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956);
        } else {
                WRITE_REG_0(sc, HIFN_0_PUCNFG, HIFN_PUCNFG_COMPSING |
diff -u -r a/sys/dev/pci/hifn7751reg.h b/sys/dev/pci/hifn7751reg.h
--- a/sys/dev/pci/hifn7751reg.h 2005-12-11 04:22:49.000000000 -0800
+++ b/sys/dev/pci/hifn7751reg.h 2021-07-17 23:42:13.372045735 -0700
@@ -361,7 +361,16 @@
 /*
  * PLL config register
  */
-#define        HIFN_PLL_7956           0x00001d18      /* 7956 PLL =
config value */
+
+/* 7956 PLL config values=20
+ *
+ * set PLL to use onboard reference, rather than a potentially
+ * unknown and unstable bus clock. setting PLL correctly requires
+ * three steps.=20
+ */
+#define HIFN_PLL_7956_INIT     0x00001c03 /* initial state, setting pll =
clock source */
+#define HIFN_PLL_7956_INIT2    0x00001c01 /* after PLL stabilizes, =
clear PLL bypass bit */
+#define        HIFN_PLL_7956           0x00001c19 /* set packet and key =
engines to use PLL */
=20
 /*********************************************************************
  * Structs for board commands
hakase$ diff -u -r a/sys/dev/pci b/sys/dev/pci=20
diff -u -r a/sys/dev/pci/hifn7751.c b/sys/dev/pci/hifn7751.c
--- a/sys/dev/pci/hifn7751.c    2018-12-27 06:03:54.000000000 -0800
+++ b/sys/dev/pci/hifn7751.c    2021-07-17 23:42:13.371790047 -0700
@@ -1073,6 +1073,17 @@
                WRITE_REG_0(sc, HIFN_0_PUCNFG, HIFN_PUCNFG_COMPSING |
                    HIFN_PUCNFG_TCALLPHASES |
                    HIFN_PUCNFG_TCDRVTOTEM | HIFN_PUCNFG_BUS32);
+               /* per datasheet: set PLL speed and charge current,
+                * and turn on the PLL bypass */
+               WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956_INIT);
+               /* then, wait at least 10ms for the PLL to lock */
+               kpause("hifnpll", false, mstohz(10), NULL);
+               /* then, disable PLL bypass */
+               WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956_INIT2);
+               /* pause again for good measure */
+               kpause("hifnpll", false, mstohz(10), NULL);
+               /* write the final PLL config value, with packet engine =
and
+                * key engine set to use the PLL output */
                WRITE_REG_1(sc, HIFN_1_PLL, HIFN_PLL_7956);
        } else {
                WRITE_REG_0(sc, HIFN_0_PUCNFG, HIFN_PUCNFG_COMPSING |
diff -u -r a/sys/dev/pci/hifn7751reg.h b/sys/dev/pci/hifn7751reg.h
--- a/sys/dev/pci/hifn7751reg.h 2005-12-11 04:22:49.000000000 -0800
+++ b/sys/dev/pci/hifn7751reg.h 2021-07-17 23:42:13.372045735 -0700
@@ -361,7 +361,16 @@
 /*
  * PLL config register
  */
-#define        HIFN_PLL_7956           0x00001d18      /* 7956 PLL =
config value */
+
+/* 7956 PLL config values=20
+ *
+ * set PLL to use onboard reference, rather than a potentially
+ * unknown and unstable bus clock. setting PLL correctly requires
+ * three steps.=20
+ */
+#define HIFN_PLL_7956_INIT     0x00001c03 /* initial state, setting pll =
clock source */
+#define HIFN_PLL_7956_INIT2    0x00001c01 /* after PLL stabilizes, =
clear PLL bypass bit */
+#define        HIFN_PLL_7956           0x00001c19 /* set packet and key =
engines to use PLL */
=20
 /*********************************************************************
  * Structs for board commands