Re: Some bwfm(4) diffs

[Patrick Wildt]

On Sun, Oct 08, 2023 at 07:42:54PM +0200, Mark Kettenis wrote:
> Hector Martin has added support for the BCM4388 that is found on the
> last generation of Apple Macs.  Based on his commits I've managed to
> get it working on my M2 Pro mini.  I still have to clean up some of
> that stuff, but here is a forst batch of two diffs.
> 
> The changes to dev/ic/bwfm.c correspond to:
> 
> https://github.com/AsahiLinux/linux/commit/81e3cc7bec8b9d9c436f63662d8fcfda4f637807

The changes here look good, ok patrick@ for this part

> The changes to dev/pci/if_bwfm_pci.c corrspond to:
> 
> https://github.com/AsahiLinux/linux/commit/8190add8671fc49c12d04b5ac8fced70f835e69f
> 
> Both changes seem to be a good idea and potentially affect other chips
> as well.  So if you have a machine with bwfm(4), please test.

This scares me a little, I'm gonna find a machine and put a bwfm(4) in
it to test.

> ok?
> 
> 
> Index: dev/ic/bwfm.c
> ===
> RCS file: /cvs/src/sys/dev/ic/bwfm.c,v
> retrieving revision 1.109
> diff -u -p -r1.109 bwfm.c
> --- dev/ic/bwfm.c 28 Mar 2023 14:01:42 -  1.109
> +++ dev/ic/bwfm.c 8 Oct 2023 17:29:35 -
> @@ -1089,15 +1089,9 @@ void
>  bwfm_chip_ai_reset(struct bwfm_softc *sc, struct bwfm_core *core,
>  uint32_t prereset, uint32_t reset, uint32_t postreset)
>  {
> - struct bwfm_core *core2 = NULL;
>   int i;
>  
> - if (core->co_id == BWFM_AGENT_CORE_80211)
> - core2 = bwfm_chip_get_core_idx(sc, BWFM_AGENT_CORE_80211, 1);
> -
>   bwfm_chip_ai_disable(sc, core, prereset, reset);
> - if (core2)
> - bwfm_chip_ai_disable(sc, core2, prereset, reset);
>  
>   for (i = 50; i > 0; i--) {
>   if ((sc->sc_buscore_ops->bc_read(sc,
> @@ -1110,32 +1104,12 @@ bwfm_chip_ai_reset(struct bwfm_softc *sc
>   }
>   if (i == 0)
>   printf("%s: timeout on core reset\n", DEVNAME(sc));
> - if (core2) {
> - for (i = 50; i > 0; i--) {
> - if ((sc->sc_buscore_ops->bc_read(sc,
> - core2->co_wrapbase + BWFM_AGENT_RESET_CTL) &
> - BWFM_AGENT_RESET_CTL_RESET) == 0)
> - break;
> - sc->sc_buscore_ops->bc_write(sc,
> - core2->co_wrapbase + BWFM_AGENT_RESET_CTL, 0);
> - delay(60);
> - }
> - if (i == 0)
> - printf("%s: timeout on core reset\n", DEVNAME(sc));
> - }
>  
>   sc->sc_buscore_ops->bc_write(sc,
>   core->co_wrapbase + BWFM_AGENT_IOCTL,
>   postreset | BWFM_AGENT_IOCTL_CLK);
>   sc->sc_buscore_ops->bc_read(sc,
>   core->co_wrapbase + BWFM_AGENT_IOCTL);
> - if (core2) {
> - sc->sc_buscore_ops->bc_write(sc,
> - core2->co_wrapbase + BWFM_AGENT_IOCTL,
> - postreset | BWFM_AGENT_IOCTL_CLK);
> - sc->sc_buscore_ops->bc_read(sc,
> - core2->co_wrapbase + BWFM_AGENT_IOCTL);
> - }
>  }
>  
>  void
> @@ -1338,6 +1312,7 @@ bwfm_chip_ca7_set_passive(struct bwfm_so
>  {
>   struct bwfm_core *core;
>   uint32_t val;
> + int i = 0;
>  
>   core = bwfm_chip_get_core(sc, BWFM_AGENT_CORE_ARM_CA7);
>   val = sc->sc_buscore_ops->bc_read(sc,
> @@ -1347,10 +1322,11 @@ bwfm_chip_ca7_set_passive(struct bwfm_so
>   BWFM_AGENT_IOCTL_ARMCR4_CPUHALT,
>   BWFM_AGENT_IOCTL_ARMCR4_CPUHALT);
>  
> - core = bwfm_chip_get_core(sc, BWFM_AGENT_CORE_80211);
> - sc->sc_chip.ch_core_reset(sc, core, BWFM_AGENT_D11_IOCTL_PHYRESET |
> - BWFM_AGENT_D11_IOCTL_PHYCLOCKEN, BWFM_AGENT_D11_IOCTL_PHYCLOCKEN,
> - BWFM_AGENT_D11_IOCTL_PHYCLOCKEN);
> + while ((core = bwfm_chip_get_core_idx(sc, BWFM_AGENT_CORE_80211, i++)))
> + sc->sc_chip.ch_core_disable(sc, core,
> + BWFM_AGENT_D11_IOCTL_PHYRESET |
> + BWFM_AGENT_D11_IOCTL_PHYCLOCKEN,
> + BWFM_AGENT_D11_IOCTL_PHYCLOCKEN);
>  }
>  
>  int
> Index: dev/pci/if_bwfm_pci.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_bwfm_pci.c,v
> retrieving revision 1.75
> diff -u -p -r1.75 if_bwfm_pci.c
> --- dev/pci/if_bwfm_pci.c 30 Dec 2022 14:10:17 -  1.75
> +++ dev/pci/if_bwfm_pci.c 8 Oct 2023 17:29:35 -
> @@ -134,6 +134,10 @@ struct bwfm_pci_softc {
>   bus_space_handle_t   sc_reg_ioh;
>   bus_size_t   sc_reg_ios;
>  
> + bus_space_tag_t  sc_pcie_iot;
> + bus_space_handle_t   sc_pcie_ioh;
> + bus_size_t   sc_pcie_ios;
> +
>   bus_space_tag_t  sc_tcm_iot;
>   bus_space_handle_t   sc_tcm_ioh;
>   bus_size_t   sc_tcm_ios;
> @@ -379,6 +383,10 @@ bwfm_pci_attach(struct device *parent, s
>   goto bar1;
>   }
>  
> + sc->sc_pcie_iot = 

xhci(4): map MSI-X

[Patrick Wildt]

Hi,

I noticed that on Qemu with arm64 we're falling back to legacy
interrupts with xhci(4) on PCI.  Turns out that the virtual xHCI
does not support MSI, but it does support MSI-X.  By having xhci(4)
map MSI-X as well I can use that on Qemu.

My x395, which so far used MSI, is still working fine with this:

-xhci0 at pci6 dev 0 function 3 "AMD 17h/1xh xHCI" rev 0x00: msi, xHCI 1.10
+xhci0 at pci6 dev 0 function 3 "AMD 17h/1xh xHCI" rev 0x00: msix, xHCI 1.10
-xhci1 at pci6 dev 0 function 4 "AMD 17h/1xh xHCI" rev 0x00: msi, xHCI 1.10
+xhci1 at pci6 dev 0 function 4 "AMD 17h/1xh xHCI" rev 0x00: msix, xHCI 1.10

ok?

Patrick

diff --git a/sys/dev/pci/xhci_pci.c b/sys/dev/pci/xhci_pci.c
index 88bdf66dbd74..52d0bc1b6761 100644
--- a/sys/dev/pci/xhci_pci.c
+++ b/sys/dev/pci/xhci_pci.c
@@ -158,7 +158,8 @@ xhci_pci_attach(struct device *parent, struct device *self, 
void *aux)
}
 
/* Map and establish the interrupt. */
-   if (pci_intr_map_msi(pa, ) != 0 && pci_intr_map(pa, ) != 0) {
+   if (pci_intr_map_msix(pa, 0, ) != 0 &&
+   pci_intr_map_msi(pa, ) != 0 && pci_intr_map(pa, ) != 0) {
printf(": couldn't map interrupt\n");
goto unmap_ret;
}

Re: wsmouse(4): Apple-like multi-touch buttons

[Patrick Wildt]

On Tue, Feb 07, 2023 at 10:07:56PM +0100, Ulf Brosziewski wrote:
> I wouldn't mind seeing such a feature in the driver, but I think there's more
> to do than counting contacts. The start of a click-and-drag gesture may 
> involve
> two contacts and a button-press event, or people who place a thumb in the 
> lower
> clickpad area and use it for pressing the clickpad button might leave the 
> index
> finger in the main area. In both cases you probably shouldn't generate a 
> middle-
> button event, and I guess it doesn't happen on MacOS, or does it?
> 
> There may be various means to distinguish the gestures. The driver might check
> the positions and the distance of the contacts, or identify their duration,
> their initial position or the current direction and speed of movement, etc.
> 
> I don't know which strategies work well and can be implemented with reasonable
> effort, it might not be easy to figure that out. It seems that libinput uses
> distances (see
>   
> https://wayland.freedesktop.org/libinput/doc/1.22.0/clickpad-softbuttons.html
> ) as well as additional means for identifying "thumbs", but I'm not familiar
> with the details.

Sounds like this good be something one could improve upon in-tree?  The
diff already feels much better than the current default.

Cheers,
Patrick

Re: wsmouse(4): Apple-like multi-touch buttons

[Patrick Wildt]

On Tue, Feb 07, 2023 at 02:12:57PM +0100, Tobias Heider wrote:
> On Mon, Sep 19, 2022 at 11:16:51AM +0200, Ulf Brosziewski wrote:
> > Is there enough interest in this feature among OpenBSD users?  I haven't
> > seen many requests for it, if any.  Moreover, is it a good idea to configure
> > different input methods on this or that hardware just because another OS
> > has different defaults?
> > 
> > Just in case the answer to these questions turns out to be "yes", here are
> > some remarks on the diff.
> 
> I do still believe that there is interest in this feature based on the 
> feedback
> I got from other devs. Having it available as a non-default option as 
> kettenis@
> said would be good enough.
> 
> Below is a revised version of the diff that adds a new mouse.tp.mtbuttons 
> config
> option. It can either be enabled via wsconsctl mouse.tp.mtbuttons=1 or by
> adding mouse.tp.mtbuttons=1 to your /etc/wsconsctl.conf.
> 
> ok?

I am very supportive of this idea/diff.  Not sure if it's my area to ok.

> Index: sys/dev/wscons/wsconsio.h
> ===
> RCS file: /cvs/src/sys/dev/wscons/wsconsio.h,v
> retrieving revision 1.98
> diff -u -p -r1.98 wsconsio.h
> --- sys/dev/wscons/wsconsio.h 15 Jul 2022 17:57:27 -  1.98
> +++ sys/dev/wscons/wsconsio.h 5 Feb 2023 15:35:39 -
> @@ -319,6 +319,7 @@ enum wsmousecfg {
>   WSMOUSECFG_SWAPSIDES,   /* invert soft-button/scroll areas */
>   WSMOUSECFG_DISABLE, /* disable all output except for
>  clicks in the top-button area */
> + WSMOUSECFG_MTBUTTONS,   /* multi-touch buttons */
>  
>   /*
>* Touchpad options
> Index: sys/dev/wscons/wstpad.c
> ===
> RCS file: /cvs/src/sys/dev/wscons/wstpad.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 wstpad.c
> --- sys/dev/wscons/wstpad.c   9 Jun 2022 22:17:18 -   1.31
> +++ sys/dev/wscons/wstpad.c   5 Feb 2023 15:35:39 -
> @@ -72,6 +72,7 @@
>  enum tpad_handlers {
>   SOFTBUTTON_HDLR,
>   TOPBUTTON_HDLR,
> + MTBUTTON_HDLR,
>   TAP_HDLR,
>   F2SCROLL_HDLR,
>   EDGESCROLL_HDLR,
> @@ -149,6 +150,7 @@ struct tpad_touch {
>  #define WSTPAD_HORIZSCROLL   (1 << 5)
>  #define WSTPAD_SWAPSIDES (1 << 6)
>  #define WSTPAD_DISABLE   (1 << 7)
> +#define WSTPAD_MTBUTTONS (1 << 8)
>  
>  #define WSTPAD_MT(1 << 31)
>  
> @@ -646,7 +648,17 @@ wstpad_softbuttons(struct wsmouseinput *
>   }
>  
>   if (tp->softbutton == 0 && PRIMARYBTN_CLICKED(tp)) {
> - tp->softbutton = wstpad_get_sbtn(input, top);
> + if (hdlr == MTBUTTON_HDLR) {
> + switch (tp->contacts) {
> + case 2:
> + tp->softbutton = RIGHTBTN;
> + break;
> + case 3:
> + tp->softbutton = MIDDLEBTN;
> + break;
> + }
> + } else
> + tp->softbutton = wstpad_get_sbtn(input, top);
>   if (tp->softbutton)
>   *cmds |= 1 << SOFTBUTTON_DOWN;
>   }
> @@ -1237,12 +1249,14 @@ wstpad_process_input(struct wsmouseinput
>   cmds = 0;
>   handlers = tp->handlers;
>   if (DISABLE(tp))
> - handlers &= ((1 << TOPBUTTON_HDLR) | (1 << SOFTBUTTON_HDLR));
> + handlers &= ((1 << TOPBUTTON_HDLR) | (1 << SOFTBUTTON_HDLR) |
> + (1 << MTBUTTON_HDLR));
>  
>   FOREACHBIT(handlers, hdlr) {
>   switch (hdlr) {
>   case SOFTBUTTON_HDLR:
>   case TOPBUTTON_HDLR:
> + case MTBUTTON_HDLR:
>   wstpad_softbuttons(input, , hdlr);
>   continue;
>   case TAP_HDLR:
> @@ -1621,6 +1635,8 @@ wstpad_configure(struct wsmouseinput *in
>  
>   tp->handlers = 0;
>  
> + if (tp->features & WSTPAD_MTBUTTONS)
> + tp->handlers |= 1 << MTBUTTON_HDLR;
>   if (tp->features & WSTPAD_SOFTBUTTONS)
>   tp->handlers |= 1 << SOFTBUTTON_HDLR;
>   if (tp->features & WSTPAD_TOPBUTTONS)
> @@ -1691,7 +1707,7 @@ wstpad_set_param(struct wsmouseinput *in
>   return (EINVAL);
>  
>   switch (key) {
> - case WSMOUSECFG_SOFTBUTTONS ... WSMOUSECFG_DISABLE:
> + case WSMOUSECFG_SOFTBUTTONS ... WSMOUSECFG_MTBUTTONS:
>   switch (key) {
>   case WSMOUSECFG_SOFTBUTTONS:
>   flag = WSTPAD_SOFTBUTTONS;
> @@ -1717,6 +1733,9 @@ wstpad_set_param(struct wsmouseinput *in
>   case WSMOUSECFG_DISABLE:
>   flag = WSTPAD_DISABLE;
>   break;
> + case WSMOUSECFG_MTBUTTONS:
> + flag = WSTPAD_MTBUTTONS;
> + break;
>   }
>   if 

Re: gptimer(4): switch to clockintr

[Patrick Wildt]

Am Tue, Jan 24, 2023 at 10:32:49PM +0100 schrieb Mark Kettenis:
> > Date: Tue, 24 Jan 2023 20:57:48 +0100
> > From: Patrick Wildt 
> > 
> > Am Mon, Jan 23, 2023 at 04:34:27PM -0600 schrieb Scott Cheloha:
> > > Whoops, missed one.  This is the fifth and (I think) last armv7 clock
> > > interrupt driver that needs to switch to clockintr.  gptimer(4) is
> > > nearly identical to dmtimer(4).
> > > 
> > > Notable changes:
> > > 
> > > - Switch stathz from 128 to hz.
> > > - Switch profhz from 1024 to (stathz * 10).
> > > 
> > > Everything else in the patch is just normal clockintr switching stuff
> > > or duplicated from the dmtimer(4) patch.
> > > 
> > > jca@ has compile-tested this.
> > > 
> > > I would appreciate a test to confirm that the GENERIC boots.  I don't
> > > think we need to do a full release build.
> > > 
> > > ... if nobody knows where to find a board with gptimer(4), I am
> > > looking for permission to just commit this as-is.  I cannot find any
> > > entries in the dmesg mails of any machines with gptimer(4).  kettenis@
> > > was uncertain whether we actually support any of the machines that have
> > > this clock.
> > > 
> > > Preferences?  ok?
> > 
> > Should we just get rid of it?  It's only used on OMAP3, which was
> > already outdated when I started my ARMv7 endeavour a decade ago.
> > I never had that machine, drahn@ might have one in the attic.
> > 
> > The relevant platforms were the Pandaboard (OMAP4) and the BeagleBone
> > Black (AM335x).  But the OMAP3, did this thing ever work?
> 
> Might as well commit this such that we have it in the attic just in
> case someone wants to revive OMAP3?

Yup, sounds good to me.

> > > Index: gptimer.c
> > > ===
> > > RCS file: /cvs/src/sys/arch/armv7/omap/gptimer.c,v
> > > retrieving revision 1.17
> > > diff -u -p -r1.17 gptimer.c
> > > --- gptimer.c 22 Jan 2023 18:36:38 -  1.17
> > > +++ gptimer.c 22 Jan 2023 23:52:32 -
> > > @@ -23,9 +23,11 @@
> > >  
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > +#include 
> > >  #include 
> > >  #include 
> > >  #include 
> > > @@ -93,14 +95,12 @@
> > >  
> > >  #define TIMER_FREQUENCY  32768   /* 32kHz is used, 
> > > selectable */
> > >  
> > > -static struct evcount clk_count;
> > > -static struct evcount stat_count;
> > > -
> > >  void gptimer_attach(struct device *parent, struct device *self, void 
> > > *args);
> > >  int gptimer_intr(void *frame);
> > >  void gptimer_wait(int reg);
> > >  void gptimer_cpu_initclocks(void);
> > >  void gptimer_delay(u_int);
> > > +void gptimer_reset_tisr(void);
> > >  void gptimer_setstatclockrate(int newhz);
> > >  
> > >  bus_space_tag_t gptimer_iot;
> > > @@ -120,13 +120,16 @@ static struct timecounter gptimer_timeco
> > >   .tc_user = 0,
> > >  };
> > >  
> > > -volatile u_int32_t nexttickevent;
> > > -volatile u_int32_t nextstatevent;
> > > -u_int32_tticks_per_second;
> > > -u_int32_tticks_per_intr;
> > > -u_int32_tticks_err_cnt;
> > > -u_int32_tticks_err_sum;
> > > -u_int32_tstatvar, statmin;
> > > +uint64_t gptimer_nsec_cycle_ratio;
> > > +uint64_t gptimer_nsec_max;
> > > +
> > > +void gptimer_rearm(void *, uint64_t);
> > > +void gptimer_trigger(void *);
> > > +
> > > +const struct intrclock gptimer_intrclock = {
> > > + .ic_rearm = gptimer_rearm,
> > > + .ic_trigger = gptimer_trigger
> > > +};
> > >  
> > >  const struct cfattachgptimer_ca = {
> > >   sizeof (struct device), NULL, gptimer_attach
> > > @@ -177,98 +180,10 @@ gptimer_attach(struct device *parent, st
> > >   gptimer_setstatclockrate, NULL);
> > >  }
> > >  
> > > -/*
> > > - * See comment in arm/xscale/i80321_clock.c
> > > - *
> > > - * counter is count up, but with autoreload timers it is not possible
> > > - * to detect how many  interrupts passed while interrupts were blocked.
> > > - * also it is not possible to atomically add to the register
> > > - * get get it to pre

Re: gptimer(4): switch to clockintr

[Patrick Wildt]

Am Mon, Jan 23, 2023 at 04:34:27PM -0600 schrieb Scott Cheloha:
> Whoops, missed one.  This is the fifth and (I think) last armv7 clock
> interrupt driver that needs to switch to clockintr.  gptimer(4) is
> nearly identical to dmtimer(4).
> 
> Notable changes:
> 
> - Switch stathz from 128 to hz.
> - Switch profhz from 1024 to (stathz * 10).
> 
> Everything else in the patch is just normal clockintr switching stuff
> or duplicated from the dmtimer(4) patch.
> 
> jca@ has compile-tested this.
> 
> I would appreciate a test to confirm that the GENERIC boots.  I don't
> think we need to do a full release build.
> 
> ... if nobody knows where to find a board with gptimer(4), I am
> looking for permission to just commit this as-is.  I cannot find any
> entries in the dmesg mails of any machines with gptimer(4).  kettenis@
> was uncertain whether we actually support any of the machines that have
> this clock.
> 
> Preferences?  ok?

Should we just get rid of it?  It's only used on OMAP3, which was
already outdated when I started my ARMv7 endeavour a decade ago.
I never had that machine, drahn@ might have one in the attic.

The relevant platforms were the Pandaboard (OMAP4) and the BeagleBone
Black (AM335x).  But the OMAP3, did this thing ever work?

> Index: gptimer.c
> ===
> RCS file: /cvs/src/sys/arch/armv7/omap/gptimer.c,v
> retrieving revision 1.17
> diff -u -p -r1.17 gptimer.c
> --- gptimer.c 22 Jan 2023 18:36:38 -  1.17
> +++ gptimer.c 22 Jan 2023 23:52:32 -
> @@ -23,9 +23,11 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -93,14 +95,12 @@
>  
>  #define TIMER_FREQUENCY  32768   /* 32kHz is used, 
> selectable */
>  
> -static struct evcount clk_count;
> -static struct evcount stat_count;
> -
>  void gptimer_attach(struct device *parent, struct device *self, void *args);
>  int gptimer_intr(void *frame);
>  void gptimer_wait(int reg);
>  void gptimer_cpu_initclocks(void);
>  void gptimer_delay(u_int);
> +void gptimer_reset_tisr(void);
>  void gptimer_setstatclockrate(int newhz);
>  
>  bus_space_tag_t gptimer_iot;
> @@ -120,13 +120,16 @@ static struct timecounter gptimer_timeco
>   .tc_user = 0,
>  };
>  
> -volatile u_int32_t nexttickevent;
> -volatile u_int32_t nextstatevent;
> -u_int32_tticks_per_second;
> -u_int32_tticks_per_intr;
> -u_int32_tticks_err_cnt;
> -u_int32_tticks_err_sum;
> -u_int32_tstatvar, statmin;
> +uint64_t gptimer_nsec_cycle_ratio;
> +uint64_t gptimer_nsec_max;
> +
> +void gptimer_rearm(void *, uint64_t);
> +void gptimer_trigger(void *);
> +
> +const struct intrclock gptimer_intrclock = {
> + .ic_rearm = gptimer_rearm,
> + .ic_trigger = gptimer_trigger
> +};
>  
>  const struct cfattachgptimer_ca = {
>   sizeof (struct device), NULL, gptimer_attach
> @@ -177,98 +180,10 @@ gptimer_attach(struct device *parent, st
>   gptimer_setstatclockrate, NULL);
>  }
>  
> -/*
> - * See comment in arm/xscale/i80321_clock.c
> - *
> - * counter is count up, but with autoreload timers it is not possible
> - * to detect how many  interrupts passed while interrupts were blocked.
> - * also it is not possible to atomically add to the register
> - * get get it to precisely fire at a non-fixed interval.
> - *
> - * To work around this two timers are used, GPT1 is used as a reference
> - * clock without reload , however we just ignore the interrupt it
> - * would (may?) generate.
> - *
> - * Internally this keeps track of when the next timer should fire
> - * and based on that time and the current value of the reference
> - * clock a number is written into the timer count register to schedule
> - * the next event.
> - */
> -
>  int
>  gptimer_intr(void *frame)
>  {
> - u_int32_t now, r;
> - u_int32_t nextevent, duration;
> -
> - /* clear interrupt */
> - now = bus_space_read_4(gptimer_iot, gptimer_ioh1, GP_TCRR);
> -
> - while ((int32_t) (nexttickevent - now) < 0) {
> - nexttickevent += ticks_per_intr;
> - ticks_err_sum += ticks_err_cnt;
> -#if 0
> - if (ticks_err_sum  > hz) {
> - u_int32_t match_error;
> - match_error = ticks_err_sum / hz
> - ticks_err_sum -= (match_error * hz);
> - }
> -#else
> - /* looping a few times is faster than divide */
> - while (ticks_err_sum  > hz) {
> - nexttickevent += 1;
> - ticks_err_sum -= hz;
> - }
> -#endif
> - clk_count.ec_count++;
> - hardclock(frame);
> - }
> - while ((int32_t) (nextstatevent - now) < 0) {
> - do {
> - r = random() & (statvar -1);
> - } while (r == 0); /* random == 0 not allowed */
> - nextstatevent += statmin + r;
> - 

Re: LLVM 15: mismatched bound errors

[Patrick Wildt]

On Thu, Dec 22, 2022 at 01:14:57AM +0100, Patrick Wildt wrote:
> On Tue, Dec 20, 2022 at 05:48:41PM -0700, Todd C. Miller wrote:
> > On Tue, 20 Dec 2022 23:44:08 +0100, Patrick Wildt wrote:
> > 
> > > clang complains when the function is declared with a fixed array size in
> > > a parameter while the prototype is unbounded, like this:
> > >
> > > /usr/src/sys/net/pf.c:4353:54: error: argument 'sns' of type 'struct 
> > > pf_src_n
> > > ode *[4]' with mismatched bound [-Werror,-Warray-parameter]
> > > struct pf_rule_actions *act, struct pf_src_node *sns[PF_SN_MAX])
> > >  ^
> > > /usr/src/sys/net/pf.c:203:28: note: previously declared as 'struct 
> > > pf_src_nod
> > > e *[]' here
> > > struct pf_src_node *[]);
> > > ^
> > > 1 error generated.
> > >
> > > We have a few of that, and was wondering what the better solution is.
> > > clang apparently accepts using * instead of [].  The alternative would
> > > be to hardcode the size in the prototype as well.  Here's a diff for
> > > a three files for the first version, as example.
> > 
> > Using * instead of [] is the saner approach.  Hard-coding the sizes
> > into the prototype seems like a bad idea, even if clang is now smart
> > enough to complain about a mismatch.
> > 
> >  - todd
> 
> So, here's the full diff that allows me to compile arm64 GENERIC.MP,
> with radeondrm and amdgpu disabled.

Right, sorry for derailing the thread with a different discussion.
Here's a diff only for the array/ptr changes.

ok?

Patrick

diff --git a/sys/crypto/sha2.c b/sys/crypto/sha2.c
index f789ef3f55b..b2b79f286f3 100644
--- a/sys/crypto/sha2.c
+++ b/sys/crypto/sha2.c
@@ -470,7 +470,7 @@ SHA256Update(SHA2_CTX *context, const void *dataptr, size_t 
len)
 }
 
 void
-SHA256Final(u_int8_t digest[], SHA2_CTX *context)
+SHA256Final(u_int8_t *digest, SHA2_CTX *context)
 {
unsigned intusedspace;
 
@@ -795,7 +795,7 @@ SHA512Last(SHA2_CTX *context)
 }
 
 void
-SHA512Final(u_int8_t digest[], SHA2_CTX *context)
+SHA512Final(u_int8_t *digest, SHA2_CTX *context)
 {
 
SHA512Last(context);
@@ -834,7 +834,7 @@ SHA384Update(SHA2_CTX *context, const void *data, size_t 
len)
 }
 
 void
-SHA384Final(u_int8_t digest[], SHA2_CTX *context)
+SHA384Final(u_int8_t *digest, SHA2_CTX *context)
 {
 
SHA512Last(context);
diff --git a/sys/dev/ic/ar5008.c b/sys/dev/ic/ar5008.c
index cad0f142210..4c0126fd6d6 100644
--- a/sys/dev/ic/ar5008.c
+++ b/sys/dev/ic/ar5008.c
@@ -111,7 +111,7 @@ voidar5008_next_calib(struct athn_softc *);
 void   ar5008_calib_iq(struct athn_softc *);
 void   ar5008_calib_adc_gain(struct athn_softc *);
 void   ar5008_calib_adc_dc_off(struct athn_softc *);
-void   ar5008_write_txpower(struct athn_softc *, int16_t power[]);
+void   ar5008_write_txpower(struct athn_softc *, int16_t *);
 void   ar5008_set_viterbi_mask(struct athn_softc *, int);
 void   ar5008_hw_init(struct athn_softc *, struct ieee80211_channel *,
struct ieee80211_channel *);
@@ -119,9 +119,9 @@ uint8_t ar5008_get_vpd(uint8_t, const uint8_t *, const 
uint8_t *, int);
 void   ar5008_get_pdadcs(struct athn_softc *, uint8_t, struct athn_pier *,
struct athn_pier *, int, int, uint8_t, uint8_t *, uint8_t *);
 void   ar5008_get_lg_tpow(struct athn_softc *, struct ieee80211_channel *,
-   uint8_t, const struct ar_cal_target_power_leg *, int, uint8_t[]);
+   uint8_t, const struct ar_cal_target_power_leg *, int, uint8_t *);
 void   ar5008_get_ht_tpow(struct athn_softc *, struct ieee80211_channel *,
-   uint8_t, const struct ar_cal_target_power_ht *, int, uint8_t[]);
+   uint8_t, const struct ar_cal_target_power_ht *, int, uint8_t *);
 void   ar5008_set_noise_immunity_level(struct athn_softc *, int);
 void   ar5008_enable_ofdm_weak_signal(struct athn_softc *);
 void   ar5008_disable_ofdm_weak_signal(struct athn_softc *);
diff --git a/sys/dev/ic/ar9003.c b/sys/dev/ic/ar9003.c
index 565ea27c701..7ec3131f86b 100644
--- a/sys/dev/ic/ar9003.c
+++ b/sys/dev/ic/ar9003.c
@@ -114,7 +114,7 @@ int ar9003_init_calib(struct athn_softc *);
 void   ar9003_do_calib(struct athn_softc *);
 void   ar9003_next_calib(struct athn_softc *);
 void   ar9003_calib_iq(struct athn_softc *);
-intar9003_get_iq_corr(struct athn_softc *, int32_t[], int32_t[]);
+intar9003_get_iq_corr(struct athn_softc *, int32_t *, int32_t *);
 intar9003_calib_tx_iq(struct athn_softc *);
 void   ar9003_paprd_calib(struct athn_softc *, struct ieee80211_channel *);
 intar9003_get_desired_txgain(struct athn_softc *, int, int);
@@ -126,17 +126,17 @@ int   ar9003_compute_predistortion(struct athn_softc 
*, c

Re: LLVM 15: mismatched bound errors

[Patrick Wildt]

Am Thu, Dec 22, 2022 at 01:57:37AM +0100 schrieb Jeremie Courreges-Anglas:
> On Thu, Dec 22 2022, Theo Buehler  wrote:
> > On Thu, Dec 22, 2022 at 11:39:41AM +1100, Jonathan Gray wrote:
> >> On Thu, Dec 22, 2022 at 01:20:32AM +0100, Theo Buehler wrote:
> >> > > Any concerns regarding the changes in libz?  It introduces diff to
> >> > > upstream, but the recent commits seemed to indicate we have forked
> >> > > anyway?
> >> > 
> >> > I've worked hard to keep the diff to upstream minimal. Why are these
> >> > changes needed?
> >> 
> >> the warnings are from -Wdeprecated-non-prototype
> >> 
> >> https://github.com/madler/zlib/issues/633
> >
> > So, can't we fix this by adding -Wno-deprecated-non-prototype to the
> > kernel build and wait until madler converts upstream?
> 
> That's what I initially proposed on my own wip branch:
> 
>   
> https://github.com/jcourreges/openbsd-src/commit/50d8bd24dadc25aa7e985de898bccf92a60b72ee
> 
> -Wno-deprecated-non-prototype + -Wno-unknown-warning-option (the latter
> option because current clang doesn't understand the former).  libz built
> as part of libsa and the bootloaders also needs a similar tweak in MD
> Makefiles:
> 
>   
> https://github.com/jcourreges/openbsd-src/commit/2107b762420ef6ea863e349e5faea4254d44fdf9
> 
> The build of src/lib/libz doesn't use -Werror and thus doesn't error out.
> 
> The two commits above are obviously incomplete, other archs need similar
> handling.  Apart from the fact that I authored them, I think they're
> the sanest way to handle this libz "oddness".  Not just because I care
> about tb's sanity.  :)

I had hoped that we can resolve that without adding another set of -W
flags everywhere, but I guess the libz churn isn't worth it.

But yeah, maybe we'll just flip the default option in LLVM and then
we'll just not use that warning... at all?

Re: LLVM 15: mismatched bound errors

[Patrick Wildt]

On Tue, Dec 20, 2022 at 05:48:41PM -0700, Todd C. Miller wrote:
> On Tue, 20 Dec 2022 23:44:08 +0100, Patrick Wildt wrote:
> 
> > clang complains when the function is declared with a fixed array size in
> > a parameter while the prototype is unbounded, like this:
> >
> > /usr/src/sys/net/pf.c:4353:54: error: argument 'sns' of type 'struct 
> > pf_src_n
> > ode *[4]' with mismatched bound [-Werror,-Warray-parameter]
> > struct pf_rule_actions *act, struct pf_src_node *sns[PF_SN_MAX])
> >  ^
> > /usr/src/sys/net/pf.c:203:28: note: previously declared as 'struct 
> > pf_src_nod
> > e *[]' here
> > struct pf_src_node *[]);
> > ^
> > 1 error generated.
> >
> > We have a few of that, and was wondering what the better solution is.
> > clang apparently accepts using * instead of [].  The alternative would
> > be to hardcode the size in the prototype as well.  Here's a diff for
> > a three files for the first version, as example.
> 
> Using * instead of [] is the saner approach.  Hard-coding the sizes
> into the prototype seems like a bad idea, even if clang is now smart
> enough to complain about a mismatch.
> 
>  - todd

So, here's the full diff that allows me to compile arm64 GENERIC.MP,
with radeondrm and amdgpu disabled.

Any concerns regarding the changes in libz?  It introduces diff to
upstream, but the recent commits seemed to indicate we have forked
anyway?

There's also an unrelated diff for iwx(4) in here, because of two
incidents of this:

In file included from /usr/src/sys/dev/pci/if_iwx.c:151:
/usr/src/sys/dev/pci/if_iwxreg.h:3626:2: error: field  within 'struct 
iwx_rx_mpdu_desc_v3' is less aligned than 'union 
iwx_rx_mpdu_desc_v3::(anonymous at /usr/src/sys/dev/pci/if_iwxreg.h:3626:2)' 
and is usually due to 'struct iwx_rx_mpdu_desc_v3' being packed, which can lead 
to unaligned accesses [-Werror,-Wunaligned-access]
union {
^

Cheers,
Patrick

diff --git a/sys/crypto/sha2.c b/sys/crypto/sha2.c
index f789ef3f55b..b2b79f286f3 100644
--- a/sys/crypto/sha2.c
+++ b/sys/crypto/sha2.c
@@ -470,7 +470,7 @@ SHA256Update(SHA2_CTX *context, const void *dataptr, size_t 
len)
 }
 
 void
-SHA256Final(u_int8_t digest[], SHA2_CTX *context)
+SHA256Final(u_int8_t *digest, SHA2_CTX *context)
 {
unsigned intusedspace;
 
@@ -795,7 +795,7 @@ SHA512Last(SHA2_CTX *context)
 }
 
 void
-SHA512Final(u_int8_t digest[], SHA2_CTX *context)
+SHA512Final(u_int8_t *digest, SHA2_CTX *context)
 {
 
SHA512Last(context);
@@ -834,7 +834,7 @@ SHA384Update(SHA2_CTX *context, const void *data, size_t 
len)
 }
 
 void
-SHA384Final(u_int8_t digest[], SHA2_CTX *context)
+SHA384Final(u_int8_t *digest, SHA2_CTX *context)
 {
 
SHA512Last(context);
diff --git a/sys/dev/ic/ar5008.c b/sys/dev/ic/ar5008.c
index cad0f142210..4c0126fd6d6 100644
--- a/sys/dev/ic/ar5008.c
+++ b/sys/dev/ic/ar5008.c
@@ -111,7 +111,7 @@ voidar5008_next_calib(struct athn_softc *);
 void   ar5008_calib_iq(struct athn_softc *);
 void   ar5008_calib_adc_gain(struct athn_softc *);
 void   ar5008_calib_adc_dc_off(struct athn_softc *);
-void   ar5008_write_txpower(struct athn_softc *, int16_t power[]);
+void   ar5008_write_txpower(struct athn_softc *, int16_t *);
 void   ar5008_set_viterbi_mask(struct athn_softc *, int);
 void   ar5008_hw_init(struct athn_softc *, struct ieee80211_channel *,
struct ieee80211_channel *);
@@ -119,9 +119,9 @@ uint8_t ar5008_get_vpd(uint8_t, const uint8_t *, const 
uint8_t *, int);
 void   ar5008_get_pdadcs(struct athn_softc *, uint8_t, struct athn_pier *,
struct athn_pier *, int, int, uint8_t, uint8_t *, uint8_t *);
 void   ar5008_get_lg_tpow(struct athn_softc *, struct ieee80211_channel *,
-   uint8_t, const struct ar_cal_target_power_leg *, int, uint8_t[]);
+   uint8_t, const struct ar_cal_target_power_leg *, int, uint8_t *);
 void   ar5008_get_ht_tpow(struct athn_softc *, struct ieee80211_channel *,
-   uint8_t, const struct ar_cal_target_power_ht *, int, uint8_t[]);
+   uint8_t, const struct ar_cal_target_power_ht *, int, uint8_t *);
 void   ar5008_set_noise_immunity_level(struct athn_softc *, int);
 void   ar5008_enable_ofdm_weak_signal(struct athn_softc *);
 void   ar5008_disable_ofdm_weak_signal(struct athn_softc *);
diff --git a/sys/dev/ic/ar9003.c b/sys/dev/ic/ar9003.c
index 565ea27c701..7ec3131f86b 100644
--- a/sys/dev/ic/ar9003.c
+++ b/sys/dev/ic/ar9003.c
@@ -114,7 +114,7 @@ int ar9003_init_calib(struct athn_softc *);
 void   ar9003_do_calib(struct athn_softc *);
 void   ar9003_next_calib(struct athn_softc *);
 void   ar9003_calib_iq(struct athn_softc *);
-intar9003_get_iq_corr(struct athn_softc *, int32_t[], int32_t[]);
+intar9003_get_iq_corr(struct at

LLVM 15: mismatched bound errors

[Patrick Wildt]

Hi,

clang complains when the function is declared with a fixed array size in
a parameter while the prototype is unbounded, like this:

/usr/src/sys/net/pf.c:4353:54: error: argument 'sns' of type 'struct 
pf_src_node *[4]' with mismatched bound [-Werror,-Warray-parameter]
struct pf_rule_actions *act, struct pf_src_node *sns[PF_SN_MAX])
 ^
/usr/src/sys/net/pf.c:203:28: note: previously declared as 'struct pf_src_node 
*[]' here
struct pf_src_node *[]);
^
1 error generated.

We have a few of that, and was wondering what the better solution is.
clang apparently accepts using * instead of [].  The alternative would
be to hardcode the size in the prototype as well.  Here's a diff for
a three files for the first version, as example.

Which version is saner?

Patrick

diff --git a/sys/dev/ic/ar5008.c b/sys/dev/ic/ar5008.c
index cad0f142210..4c0126fd6d6 100644
--- a/sys/dev/ic/ar5008.c
+++ b/sys/dev/ic/ar5008.c
@@ -111,7 +111,7 @@ voidar5008_next_calib(struct athn_softc *);
 void   ar5008_calib_iq(struct athn_softc *);
 void   ar5008_calib_adc_gain(struct athn_softc *);
 void   ar5008_calib_adc_dc_off(struct athn_softc *);
-void   ar5008_write_txpower(struct athn_softc *, int16_t power[]);
+void   ar5008_write_txpower(struct athn_softc *, int16_t *);
 void   ar5008_set_viterbi_mask(struct athn_softc *, int);
 void   ar5008_hw_init(struct athn_softc *, struct ieee80211_channel *,
struct ieee80211_channel *);
@@ -119,9 +119,9 @@ uint8_t ar5008_get_vpd(uint8_t, const uint8_t *, const 
uint8_t *, int);
 void   ar5008_get_pdadcs(struct athn_softc *, uint8_t, struct athn_pier *,
struct athn_pier *, int, int, uint8_t, uint8_t *, uint8_t *);
 void   ar5008_get_lg_tpow(struct athn_softc *, struct ieee80211_channel *,
-   uint8_t, const struct ar_cal_target_power_leg *, int, uint8_t[]);
+   uint8_t, const struct ar_cal_target_power_leg *, int, uint8_t *);
 void   ar5008_get_ht_tpow(struct athn_softc *, struct ieee80211_channel *,
-   uint8_t, const struct ar_cal_target_power_ht *, int, uint8_t[]);
+   uint8_t, const struct ar_cal_target_power_ht *, int, uint8_t *);
 void   ar5008_set_noise_immunity_level(struct athn_softc *, int);
 void   ar5008_enable_ofdm_weak_signal(struct athn_softc *);
 void   ar5008_disable_ofdm_weak_signal(struct athn_softc *);
diff --git a/sys/dev/ic/ar9003.c b/sys/dev/ic/ar9003.c
index 565ea27c701..7ec3131f86b 100644
--- a/sys/dev/ic/ar9003.c
+++ b/sys/dev/ic/ar9003.c
@@ -114,7 +114,7 @@ int ar9003_init_calib(struct athn_softc *);
 void   ar9003_do_calib(struct athn_softc *);
 void   ar9003_next_calib(struct athn_softc *);
 void   ar9003_calib_iq(struct athn_softc *);
-intar9003_get_iq_corr(struct athn_softc *, int32_t[], int32_t[]);
+intar9003_get_iq_corr(struct athn_softc *, int32_t *, int32_t *);
 intar9003_calib_tx_iq(struct athn_softc *);
 void   ar9003_paprd_calib(struct athn_softc *, struct ieee80211_channel *);
 intar9003_get_desired_txgain(struct athn_softc *, int, int);
@@ -126,17 +126,17 @@ int   ar9003_compute_predistortion(struct athn_softc 
*, const uint32_t *,
 void   ar9003_enable_predistorter(struct athn_softc *, int);
 void   ar9003_paprd_enable(struct athn_softc *);
 void   ar9003_paprd_tx_tone_done(struct athn_softc *);
-void   ar9003_write_txpower(struct athn_softc *, int16_t power[]);
+void   ar9003_write_txpower(struct athn_softc *, int16_t *);
 void   ar9003_reset_rx_gain(struct athn_softc *, struct ieee80211_channel *);
 void   ar9003_reset_tx_gain(struct athn_softc *, struct ieee80211_channel *);
 void   ar9003_hw_init(struct athn_softc *, struct ieee80211_channel *,
struct ieee80211_channel *);
 void   ar9003_get_lg_tpow(struct athn_softc *, struct ieee80211_channel *,
uint8_t, const uint8_t *, const struct ar_cal_target_power_leg *,
-   int, uint8_t[]);
+   int, uint8_t *);
 void   ar9003_get_ht_tpow(struct athn_softc *, struct ieee80211_channel *,
uint8_t, const uint8_t *, const struct ar_cal_target_power_ht *,
-   int, uint8_t[]);
+   int, uint8_t *);
 void   ar9003_set_noise_immunity_level(struct athn_softc *, int);
 void   ar9003_enable_ofdm_weak_signal(struct athn_softc *);
 void   ar9003_disable_ofdm_weak_signal(struct athn_softc *);
diff --git a/sys/dev/ic/rtwn.c b/sys/dev/ic/rtwn.c
index 2d7551eaef3..d7f25d59919 100644
--- a/sys/dev/ic/rtwn.c
+++ b/sys/dev/ic/rtwn.c
@@ -151,19 +151,19 @@ void  rtwn_pa_bias_init(struct rtwn_softc *);
 void   rtwn_rxfilter_init(struct rtwn_softc *);
 void   rtwn_edca_init(struct rtwn_softc *);
 void   rtwn_rate_fallback_init(struct rtwn_softc *);
-void   rtwn_write_txpower(struct rtwn_softc *, int, uint16_t[]);
+void   rtwn_write_txpower(struct rtwn_softc *, int, uint16_t *);
 void   

Re: arm64 pwmbl(4): simplify ramp case

[Patrick Wildt]

On Fri, Nov 11, 2022 at 06:48:21AM +, Miod Vallat wrote:
> > This actually breaks my machine.  malloc() is saying allocation too
> > large.  OF_getproplen will return -1 on that.  Is it possible that
> > len is treated as uint64_t as it is an int and sizeof is effectively
> > uint64_t?
> 
> Ah, yes; size_t is unsigned and wider than int on 64-bit platforms,
> therefore int is converted to unsigned for the comparison. Casting
> sizeof to int will do.
> 
> > Might be easier to have a check like:
> > 
> > if (sc->sc_channels == NULL)
> > return level < sc->sc_nlevels ? level : sc->sc_nlevels - 1;
> > 
> > Then you don't need to indent the whole block.  Makes the diff smaller
> > and a bit easier to understand?
> 
> Sure; what about this new version, then?

Works for me, thanks!  ok patrick@

> 
> Index: pwmbl.c
> ===
> RCS file: /OpenBSD/src/sys/dev/fdt/pwmbl.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 pwmbl.c
> --- pwmbl.c   24 Oct 2021 17:52:26 -  1.6
> +++ pwmbl.c   11 Nov 2022 06:46:41 -
> @@ -35,7 +35,7 @@ struct pwmbl_softc {
>   struct device   sc_dev;
>   uint32_t*sc_pwm;
>   int sc_pwm_len;
> - uint32_t*sc_levels;
> + uint32_t*sc_levels; /* NULL if simple ramp */
>   int sc_nlevels;
>   uint32_tsc_max_level;
>   uint32_tsc_def_level;
> @@ -73,7 +73,7 @@ pwmbl_attach(struct device *parent, stru
>   struct pwmbl_softc *sc = (struct pwmbl_softc *)self;
>   struct fdt_attach_args *faa = aux;
>   uint32_t *gpios;
> - int i, len;
> + int len;
>  
>   len = OF_getproplen(faa->fa_node, "pwms");
>   if (len < 0) {
> @@ -95,7 +95,7 @@ pwmbl_attach(struct device *parent, stru
>   }
>  
>   len = OF_getproplen(faa->fa_node, "brightness-levels");
> - if (len > 0) {
> + if (len >= (int)sizeof(uint32_t)) {
>   sc->sc_levels = malloc(len, M_DEVBUF, M_WAITOK);
>   OF_getpropintarray(faa->fa_node, "brightness-levels",
>   sc->sc_levels, len);
> @@ -107,13 +107,9 @@ pwmbl_attach(struct device *parent, stru
>   sc->sc_def_level = sc->sc_nlevels - 1;
>   sc->sc_def_level = sc->sc_levels[sc->sc_def_level];
>   } else {
> + /* No levels, assume a simple 0..255 ramp. */
>   sc->sc_nlevels = 256;
> - sc->sc_levels = mallocarray(sc->sc_nlevels,
> - sizeof(uint32_t), M_DEVBUF, M_WAITOK);
> - for (i = 0; i < sc->sc_nlevels; i++)
> - sc->sc_levels[i] = i;
> - sc->sc_max_level = sc->sc_levels[sc->sc_nlevels - 1];
> - sc->sc_def_level = sc->sc_levels[sc->sc_nlevels - 1];
> + sc->sc_max_level = sc->sc_def_level = sc->sc_nlevels - 1;
>   }
>  
>   printf("\n");
> @@ -143,6 +139,9 @@ pwmbl_find_brightness(struct pwmbl_softc
>  {
>   uint32_t mid;
>   int i;
> +
> + if (sc->sc_levels == NULL)
> + return level < sc->sc_nlevels ? level : sc->sc_nlevels - 1;
>  
>   for (i = 0; i < sc->sc_nlevels - 1; i++) {
>   mid = (sc->sc_levels[i] + sc->sc_levels[i + 1]) / 2;
> 

Re: qcpmic.4, qcpmicgpio.4, etc.: Sort SEE ALSO

[Patrick Wildt]

There are other drivers with intro after others. Are we sorting those 
alphabetically or by relevancy?

Von meinem iPhone gesendet

> Am 10.11.2022 um 16:46 schrieb Josiah Frentsos :
> 
> Index: qcpmic.4
> ===
> RCS file: /cvs/src/share/man/man4/qcpmic.4,v
> retrieving revision 1.2
> diff -u -p -r1.2 qcpmic.4
> --- qcpmic.410 Nov 2022 13:08:57 -1.2
> +++ qcpmic.410 Nov 2022 16:43:07 -
> @@ -34,12 +34,12 @@ Snapdragon SoCs.
> The functionality for the hardware blocks found in each PMIC is
> implemented in the children attaching to this driver.
> .Sh SEE ALSO
> -.Xr qcspmi 4 ,
> +.Xr intro 4 ,
> .Xr qcpmicgpio 4 ,
> .Xr qcpon 4 ,
> .Xr qcpwm 4 ,
> .Xr qcrtc 4 ,
> -.Xr intro 4
> +.Xr qcspmi 4
> .Sh HISTORY
> The
> .Nm
> Index: qcpmicgpio.4
> ===
> RCS file: /cvs/src/share/man/man4/qcpmicgpio.4,v
> retrieving revision 1.1
> diff -u -p -r1.1 qcpmicgpio.4
> --- qcpmicgpio.410 Nov 2022 12:57:08 -1.1
> +++ qcpmicgpio.410 Nov 2022 16:43:07 -
> @@ -30,8 +30,8 @@ SoCs.
> It does not provide direct device driver entry points but makes its
> functions available to other drivers.
> .Sh SEE ALSO
> -.Xr qcpmic 4 ,
> -.Xr intro 4
> +.Xr intro 4 ,
> +.Xr qcpmic 4
> .Sh HISTORY
> The
> .Nm
> Index: qcpon.4
> ===
> RCS file: /cvs/src/share/man/man4/qcpon.4,v
> retrieving revision 1.1
> diff -u -p -r1.1 qcpon.4
> --- qcpon.410 Nov 2022 13:08:57 -1.1
> +++ qcpon.410 Nov 2022 16:43:07 -
> @@ -26,10 +26,11 @@
> The
> .Nm
> driver provides support for the PON controllers integrated on various
> -Qualcomm Snapdragon SoCs.  This controller contains the power button.
> +Qualcomm Snapdragon SoCs.
> +This controller contains the power button.
> .Sh SEE ALSO
> -.Xr qcpmic 4 ,
> -.Xr intro 4
> +.Xr intro 4 ,
> +.Xr qcpmic 4
> .Sh HISTORY
> The
> .Nm
> Index: qcpwm.4
> ===
> RCS file: /cvs/src/share/man/man4/qcpwm.4,v
> retrieving revision 1.1
> diff -u -p -r1.1 qcpwm.4
> --- qcpwm.410 Nov 2022 13:08:57 -1.1
> +++ qcpwm.410 Nov 2022 16:43:07 -
> @@ -28,8 +28,8 @@ The
> driver provides support for the PWM controllers integrated on various
> Qualcomm Snapdragon SoCs.
> .Sh SEE ALSO
> -.Xr qcpmic 4 ,
> -.Xr intro 4
> +.Xr intro 4 ,
> +.Xr qcpmic 4
> .Sh HISTORY
> The
> .Nm
> Index: qcrtc.4
> ===
> RCS file: /cvs/src/share/man/man4/qcrtc.4,v
> retrieving revision 1.1
> diff -u -p -r1.1 qcrtc.4
> --- qcrtc.410 Nov 2022 13:08:57 -1.1
> +++ qcrtc.410 Nov 2022 16:43:07 -
> @@ -28,8 +28,8 @@ The
> driver provides support for the RTC integrated on various Qualcomm
> Snapdragon SoCs.
> .Sh SEE ALSO
> -.Xr qcpmic 4 ,
> -.Xr intro 4
> +.Xr intro 4 ,
> +.Xr qcpmic 4
> .Sh HISTORY
> The
> .Nm
> Index: qcspmi.4
> ===
> RCS file: /cvs/src/share/man/man4/qcspmi.4,v
> retrieving revision 1.1
> diff -u -p -r1.1 qcspmi.4
> --- qcspmi.410 Nov 2022 12:57:08 -1.1
> +++ qcspmi.410 Nov 2022 16:43:07 -
> @@ -29,8 +29,8 @@ The
> driver provides support for the SPMI controller found on various
> Qualcomm Snapdragon SoCs.
> .Sh SEE ALSO
> -.Xr qcpmic 4 ,
> -.Xr intro 4
> +.Xr intro 4 ,
> +.Xr qcpmic 4
> .Sh HISTORY
> The
> .Nm
> 

Re: arm64 pwmbl(4): simplify ramp case

[Patrick Wildt]

On Mon, Jul 04, 2022 at 06:47:33PM +, Miod Vallat wrote:
> When the fdt does not provide a list of brightness states, pwmbl(4)
> builds a 256 state ramp (i.e. state[i] = i with 0 <= i < 256).
> 
> The following diff keeps that behaviour, but gets rid of the malloc
> call for that ramp, since the values are trivially known.
> 
> Compiles but not tested due to the lack of such hardware.
> 
> Index: sys/dev/fdt/pwmbl.c
> ===
> RCS file: /OpenBSD/src/sys/dev/fdt/pwmbl.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 pwmbl.c
> --- sys/dev/fdt/pwmbl.c   24 Oct 2021 17:52:26 -  1.6
> +++ sys/dev/fdt/pwmbl.c   4 Jul 2022 18:45:16 -
> @@ -35,7 +35,7 @@ struct pwmbl_softc {
>   struct device   sc_dev;
>   uint32_t*sc_pwm;
>   int sc_pwm_len;
> - uint32_t*sc_levels;
> + uint32_t*sc_levels; /* NULL if simple ramp */
>   int sc_nlevels;
>   uint32_tsc_max_level;
>   uint32_tsc_def_level;
> @@ -73,7 +73,7 @@ pwmbl_attach(struct device *parent, stru
>   struct pwmbl_softc *sc = (struct pwmbl_softc *)self;
>   struct fdt_attach_args *faa = aux;
>   uint32_t *gpios;
> - int i, len;
> + int len;
>  
>   len = OF_getproplen(faa->fa_node, "pwms");
>   if (len < 0) {
> @@ -95,7 +95,7 @@ pwmbl_attach(struct device *parent, stru
>   }
>  
>   len = OF_getproplen(faa->fa_node, "brightness-levels");
> - if (len > 0) {
> + if (len >= sizeof(uint32_t)) {

This actually breaks my machine.  malloc() is saying allocation too
large.  OF_getproplen will return -1 on that.  Is it possible that
len is treated as uint64_t as it is an int and sizeof is effectively
uint64_t?

Moving len to ssize_t doesn't fix it, but doing

if (len >= (int)sizeof(uint32_t)) {

works.  So I wonder if

if (len > 0 && len >= sizeof(uint32_t)) {

would work as well.  Or maybe let's just keep it as it is?

>   sc->sc_levels = malloc(len, M_DEVBUF, M_WAITOK);
>   OF_getpropintarray(faa->fa_node, "brightness-levels",
>   sc->sc_levels, len);
> @@ -107,13 +107,9 @@ pwmbl_attach(struct device *parent, stru
>   sc->sc_def_level = sc->sc_nlevels - 1;
>   sc->sc_def_level = sc->sc_levels[sc->sc_def_level];
>   } else {
> + /* No levels, assume a simple 0..255 ramp. */
>   sc->sc_nlevels = 256;
> - sc->sc_levels = mallocarray(sc->sc_nlevels,
> - sizeof(uint32_t), M_DEVBUF, M_WAITOK);
> - for (i = 0; i < sc->sc_nlevels; i++)
> - sc->sc_levels[i] = i;
> - sc->sc_max_level = sc->sc_levels[sc->sc_nlevels - 1];
> - sc->sc_def_level = sc->sc_levels[sc->sc_nlevels - 1];
> + sc->sc_max_level = sc->sc_def_level = sc->sc_nlevels - 1;
>   }
>  
>   printf("\n");
> @@ -144,17 +140,22 @@ pwmbl_find_brightness(struct pwmbl_softc
>   uint32_t mid;
>   int i;

Might be easier to have a check like:

if (sc->sc_channels == NULL)
return level < sc->sc_nlevels ? level : sc->sc_nlevels - 1;

Then you don't need to indent the whole block.  Makes the diff smaller
and a bit easier to understand?

Cheers,
Patrick

>  
> - for (i = 0; i < sc->sc_nlevels - 1; i++) {
> - mid = (sc->sc_levels[i] + sc->sc_levels[i + 1]) / 2;
> - if (sc->sc_levels[i] <= level && level <= mid)
> + if (sc->sc_levels) {
> + for (i = 0; i < sc->sc_nlevels - 1; i++) {
> + mid = (sc->sc_levels[i] + sc->sc_levels[i + 1]) / 2;
> + if (sc->sc_levels[i] <= level && level <= mid)
> + return sc->sc_levels[i];
> + if (mid < level && level <= sc->sc_levels[i + 1])
> + return sc->sc_levels[i + 1];
> + }
> + if (level < sc->sc_levels[0])
> + return sc->sc_levels[0];
> + else
>   return sc->sc_levels[i];
> - if (mid < level && level <= sc->sc_levels[i + 1])
> - return sc->sc_levels[i + 1];
> +
> + } else {
> + return level < sc->sc_nlevels ? level : sc->sc_nlevels - 1;
>   }
> - if (level < sc->sc_levels[0])
> - return sc->sc_levels[0];
> - else
> - return sc->sc_levels[i];
>  }
>  
>  int
> 

Re: mvpcie(4): fix panic if "reset-gpios" is not available

[Patrick Wildt]

Am Sun, Feb 13, 2022 at 01:39:22PM + schrieb Klemens Nanni:
> On Sun, Feb 13, 2022 at 02:30:21PM +0100, Tobias Heider wrote:
> > OF_getproplen() will return -1 if "reset-gpios" is not found which
> > currently causes a panic:
> > 
> > panic: malloc: allocation too large, type = 2, size = 4294967295
> > 
> > Below is a fix.
> > 
> > ok?
> 
> OK kn

ok patrick@ as well

> > 
> > Index: mvpcie.c
> > ===
> > RCS file: /mount/openbsd/cvs/src/sys/arch/armv7/marvell/mvpcie.c,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 mvpcie.c
> > --- mvpcie.c24 Oct 2021 17:52:27 -  1.5
> > +++ mvpcie.c13 Feb 2022 13:24:17 -
> > @@ -106,7 +106,7 @@ struct mvpcie_port {
> > int  po_fn;
> >  
> > uint32_t*po_gpio;
> > -   size_t   po_gpiolen;
> > +   int  po_gpiolen;
> >  
> > struct arm32_pci_chipset po_pc;
> > int  po_bus;
> > @@ -353,7 +353,7 @@ mvpcie_port_attach(struct mvpcie_softc *
> > po->po_bridge_iolimit = 1;
> >  
> > po->po_gpiolen = OF_getproplen(po->po_node, "reset-gpios");
> > -   if (po->po_gpiolen) {
> > +   if (po->po_gpiolen > 0) {
> > po->po_gpio = malloc(po->po_gpiolen, M_DEVBUF, M_WAITOK);
> > OF_getpropintarray(po->po_node, "reset-gpios",
> > po->po_gpio, po->po_gpiolen);
> > 
> 

Re: mvdog(4): add support for armada-380-wdg

[Patrick Wildt]

Am Sun, Feb 13, 2022 at 02:22:53PM +0100 schrieb Tobias Heider:
> Hey,
> 
> I'm trying to get the Turris Omnia running and one thing missing
> is a driver for the armada-380-wdg.  We already have a similar driver
> called mvdog(4) that currently only supports the armada-3700 watchdog.
> The diff below adds support for disabling the armada-380-wdg.
> 
> ok?

First of all, it's -wdt. ;)  It's a good start, comments inline.

> 
> Index: mvdog.c
> ===
> RCS file: /mount/openbsd/cvs/src/sys/dev/fdt/mvdog.c,v
> retrieving revision 1.2
> diff -u -p -r1.2 mvdog.c
> --- mvdog.c   24 Oct 2021 17:52:26 -  1.2
> +++ mvdog.c   13 Feb 2022 13:11:06 -
> @@ -33,6 +33,10 @@
>  
>  #define WDT_TIMER_SELECT 0x64

Might be worth renaming those as well.

> +#define ARMADA_380_RSTOUT_MASK_BIT   (1 << 10)
> +#define ARMADA_380_RSTOUT_ENABLE_BIT (1 << 8)
> +#define ARMADA_380_WDT_ENABLE_BIT(1 << 8)

Hm, How about A380 as prefix?  But that's just nitpicking.

>  #define HREAD4(sc, reg)  
> \
>   (bus_space_read_4((sc)->sc_iot, (sc)->sc_ioh, (reg)))
>  #define HWRITE4(sc, reg, val)
> \
> @@ -47,6 +51,8 @@ struct mvdog_softc {
>   bus_space_tag_t  sc_iot;
>   bus_space_handle_t   sc_ioh;
>   struct regmap   *sc_rm;
> + bus_space_handle_t   sc_ioh_rout;
> + bus_space_handle_t   sc_ioh_routmask;
>  };
>  
>  int   mvdog_match(struct device *, void *, void *);
> @@ -65,7 +71,8 @@ mvdog_match(struct device *parent, void 
>  {
>   struct fdt_attach_args *faa = aux;
>  
> - return OF_is_compatible(faa->fa_node, "marvell,armada-3700-wdt");
> + return OF_is_compatible(faa->fa_node, "marvell,armada-3700-wdt") ||
> + OF_is_compatible(faa->fa_node, "marvell,armada-380-wdt");
>  }
>  
>  void
> @@ -86,17 +93,39 @@ mvdog_attach(struct device *parent, stru
>   return;
>   }
>  
> - sc->sc_rm = regmap_byphandle(OF_getpropint(faa->fa_node,
> - "marvell,system-controller", 0));
> - if (sc->sc_rm == NULL) {
> - printf(": can't get regmap\n");
> - return;
> - }
> -
>   printf("\n");

This needs to be moved to the end, otherwise in the error case it will
be:

mvdog0 at simplebus0\n
:can't ...

>  
> - /* Disable watchdog timer. */
> - HCLR4(sc, CNTR_CTRL(CNTR_WDOG), CNTR_CTRL_ENABLE);
> - HCLR4(sc, CNTR_CTRL(CNTR_RETRIGGER), CNTR_CTRL_ENABLE);
> - regmap_write_4(sc->sc_rm, WDT_TIMER_SELECT, 0);
> + if (OF_is_compatible(faa->fa_node, "marvell,armada-3700-wdt")) {
> + sc->sc_rm = regmap_byphandle(OF_getpropint(faa->fa_node,
> + "marvell,system-controller", 0));
> + if (sc->sc_rm == NULL) {
> + printf(": can't get regmap\n");
> + return;
> + }
> +
> + /* Disable watchdog timer. */
> + HCLR4(sc, CNTR_CTRL(CNTR_WDOG), CNTR_CTRL_ENABLE);
> + HCLR4(sc, CNTR_CTRL(CNTR_RETRIGGER), CNTR_CTRL_ENABLE);
> + regmap_write_4(sc->sc_rm, WDT_TIMER_SELECT, 0);
> + } else {

While we tend do to if else quite often with those compatibles, I wonder
if more explicit 'if compatible 380' might be better for readability.

> + if (bus_space_map(sc->sc_iot, faa->fa_reg[1].addr,
> + faa->fa_reg[1].size, 0, >sc_ioh_rout)) {
> + printf(": can't map registers\n");
> + return;
> + }
> + if (bus_space_map(sc->sc_iot, faa->fa_reg[2].addr,
> + faa->fa_reg[2].size, 0, >sc_ioh_routmask)) {
> + printf(": can't map registers\n");
> + return;
> + }
> +
> + /* Disable watchdog timer. */
> + bus_space_write_4(sc->sc_iot, sc->sc_ioh_routmask, 0,
> + bus_space_read_4(sc->sc_iot, sc->sc_ioh_routmask, 0) |
> + ARMADA_380_RSTOUT_MASK_BIT);
> + bus_space_write_4(sc->sc_iot, sc->sc_ioh_rout, 0,
> + bus_space_read_4(sc->sc_iot, sc->sc_ioh_rout, 0) &
> + ~ARMADA_380_RSTOUT_ENABLE_BIT);
> + HCLR4(sc, 0, ARMADA_380_WDT_ENABLE_BIT);

Not sure I like the mix of bus_space_* and H* macros.  Maybe kettenis@
wants to chime in, he always helps me when I'm overthinking stuff.

Cheers,
Patrick

> + }
>  }
> 

Re: Missing UBSan libs

[Patrick Wildt]

Am Sun, Jan 30, 2022 at 11:40:29AM -0800 schrieb Greg Steuck:
> Greg Steuck  writes:
> 
> >> I notice people keep sending fixes to problems reported by UBSan. I
> >> wanted to join the club, but the trivial thing listed at
> >> https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html doesn't
> >> work:
> 
> My confusion is easily resolved. People use UBSan in the kernel where
> anton@ did the integration work whereas userspace work is yet to happen.
> 
> Thanks
> Greg

Hi,

regarding the missing userpace support:  Since a few clang updates ago
we import more than just the builtins of compiler-rt.  This means we
should have at least some related code in our tree, even if it is not
built/complete.  From the recent static analyzer mail thread it looks
like people prefer to have such stuff in ports-clang, so, whatever.

Cheers,
Patrick

sdhc(4): make use of SDHC version 3.0 divisors to increase frequency accuracy

[Patrick Wildt]

Hi,

On SDHC version 3.0 controllers the divisor doesn't have to be a power
of two, but can be a multiple of two.  This means we can get a lot
closer to the target clock.

E.g. to reach 400 kHz on a 200 MHz bus clock, the old mechanism would
take 512 as divisor (== 390.612 kHz) while the new mechanism would use
divisor 500 and reach exactly 400 kHz.

ok?

Patrick

diff --git a/sys/dev/sdmmc/sdhc.c b/sys/dev/sdmmc/sdhc.c
index 28923e22279..a2866b23ce5 100644
--- a/sys/dev/sdmmc/sdhc.c
+++ b/sys/dev/sdmmc/sdhc.c
@@ -635,15 +635,21 @@ sdhc_bus_power(sdmmc_chipset_handle_t sch, u_int32_t ocr)
 static int
 sdhc_clock_divisor(struct sdhc_host *hp, u_int freq)
 {
-   int max_div = SDHC_SDCLK_DIV_MAX;
int div;
 
-   if (SDHC_SPEC_VERSION(hp->version) >= SDHC_SPEC_V3)
-   max_div = SDHC_SDCLK_DIV_MAX_V3;
+   if (SDHC_SPEC_VERSION(hp->version) >= SDHC_SPEC_V3) {
+   if (hp->clkbase <= freq)
+   return 0;
+
+   for (div = 2; div <= SDHC_SDCLK_DIV_MAX_V3; div += 2)
+   if ((hp->clkbase / div) <= freq)
+   return (div / 2);
+   } else {
+   for (div = 1; div <= SDHC_SDCLK_DIV_MAX; div *= 2)
+   if ((hp->clkbase / div) <= freq)
+   return (div / 2);
+   }
 
-   for (div = 1; div <= max_div; div *= 2)
-   if ((hp->clkbase / div) <= freq)
-   return (div / 2);
/* No divisor found. */
return -1;
 }

Re: ohci(4) and ehci(4) at acpi(4)

[Patrick Wildt]

On Wed, Dec 29, 2021 at 06:43:31PM +0100, Patrick Wildt wrote:
> On Wed, Dec 29, 2021 at 06:02:02PM +0100, Mark Kettenis wrote:
> > > Date: Wed, 29 Dec 2021 17:16:36 +0100
> > > From: Patrick Wildt 
> > > 
> > > On Wed, Dec 29, 2021 at 05:03:50PM +0100, Patrick Wildt wrote:
> > > > Hi,
> > > > 
> > > > a device I have still has oHCI and eHCI controllers, which are needed to
> > > > be able to use the second USB port.
> > > > 
> > > > ehci(4) at acpi(4) is plain simple, as it attaches to PNP0D20.  I have
> > > > copied the xhci(4) at acpi(4) file and added the functional changes that
> > > > exist between xhci(4) and ehci(4) at fdt(4).
> > > > 
> > > > ohci(4) is very similar, I have also added the functional changes that
> > > > way.  There's a difference in how they attach:  It uses a PRP0001 ID,
> > > > which basically is a device-tree namespace link.  That means we match
> > > > on that link *and* have to check the 'compatible' property.
> > > > 
> > > > With these changes, my second USB port works just fine.
> > > > 
> > > > Patrick
> > > 
> > > Actually, there's a better way to match ohci(4).  We can match on _CLS,
> > > like we do for ahci(4) at acpi(4).  Updated diff below.
> > 
> > Yes, that is cleaner...

Cleaned up a little, and fixed bogus double ohci_init().

ok?

Patrick

diff --git a/sys/arch/arm64/conf/GENERIC b/sys/arch/arm64/conf/GENERIC
index 19fd6e03c4f..879d024503f 100644
--- a/sys/arch/arm64/conf/GENERIC
+++ b/sys/arch/arm64/conf/GENERIC
@@ -54,7 +54,9 @@ com*  at acpi?
 dwgpio*at acpi?
 dwiic* at acpi?
 iic*   at dwiic?
+ehci*  at acpi?
 ipmi*  at acpi?
+ohci*  at acpi?
 pluart*at acpi?
 sdhc*  at acpi?
 xhci*  at acpi?
diff --git a/sys/arch/arm64/conf/RAMDISK b/sys/arch/arm64/conf/RAMDISK
index b505e37b399..caf2eea44b8 100644
--- a/sys/arch/arm64/conf/RAMDISK
+++ b/sys/arch/arm64/conf/RAMDISK
@@ -44,6 +44,8 @@ pci*  at acpipci?
 ahci*  at acpi?
 ccp*   at acpi?# AMD Cryptographic Co-processor
 com*   at acpi?
+ehci*  at acpi?
+ohci*  at acpi?
 pluart*at acpi?
 sdhc*  at acpi?
 xhci*  at acpi?
diff --git a/sys/dev/acpi/ehci_acpi.c b/sys/dev/acpi/ehci_acpi.c
new file mode 100644
index 000..843a83aeee9
--- /dev/null
+++ b/sys/dev/acpi/ehci_acpi.c
@@ -0,0 +1,124 @@
+/* $OpenBSD: ehci_acpi.c,v 1.4 2021/12/21 20:53:46 kettenis Exp $  */
+/*
+ * Copyright (c) 2018 Mark Kettenis
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct ehci_acpi_softc {
+   struct ehci_softc sc;
+   struct acpi_softc *sc_acpi;
+   struct aml_node *sc_node;
+   void*sc_ih;
+};
+
+intehci_acpi_match(struct device *, void *, void *);
+void   ehci_acpi_attach(struct device *, struct device *, void *);
+
+struct cfattach ehci_acpi_ca = {
+   sizeof(struct ehci_acpi_softc), ehci_acpi_match, ehci_acpi_attach
+};
+
+const char *ehci_hids[] = {
+   "PNP0D20",
+   NULL
+};
+
+int
+ehci_acpi_match(struct device *parent, void *match, void *aux)
+{
+   struct acpi_attach_args *aaa = aux;
+   struct cfdata *cf = match;
+
+   if (aaa->aaa_naddr < 1 || aaa->aaa_nirq < 1)
+   return 0;
+   return acpi_matchhids(aaa, ehci_hids, cf->cf_driver->cd_name);
+}
+
+void
+ehci_acpi_attach(struct device *parent, struct device *self, void *aux)
+{
+   struct ehci_acpi_softc *sc = (struct ehci_acpi_softc *)self;
+   struct acpi_attach_args *aaa = aux;
+   int error;
+
+   sc->sc_acpi = (struct acpi_softc *)parent;
+   sc->sc_node = aaa->aaa_node;
+   printf(" %s", sc->sc_node->name);
+
+   printf(" addr 0x%llx/0x%llx", aaa

Re: ohci(4) and ehci(4) at acpi(4)

[Patrick Wildt]

On Wed, Dec 29, 2021 at 06:02:02PM +0100, Mark Kettenis wrote:
> > Date: Wed, 29 Dec 2021 17:16:36 +0100
> > From: Patrick Wildt 
> > 
> > On Wed, Dec 29, 2021 at 05:03:50PM +0100, Patrick Wildt wrote:
> > > Hi,
> > > 
> > > a device I have still has oHCI and eHCI controllers, which are needed to
> > > be able to use the second USB port.
> > > 
> > > ehci(4) at acpi(4) is plain simple, as it attaches to PNP0D20.  I have
> > > copied the xhci(4) at acpi(4) file and added the functional changes that
> > > exist between xhci(4) and ehci(4) at fdt(4).
> > > 
> > > ohci(4) is very similar, I have also added the functional changes that
> > > way.  There's a difference in how they attach:  It uses a PRP0001 ID,
> > > which basically is a device-tree namespace link.  That means we match
> > > on that link *and* have to check the 'compatible' property.
> > > 
> > > With these changes, my second USB port works just fine.
> > > 
> > > Patrick
> > 
> > Actually, there's a better way to match ohci(4).  We can match on _CLS,
> > like we do for ahci(4) at acpi(4).  Updated diff below.
> 
> Yes, that is cleaner...
> 
> > diff --git a/sys/arch/arm64/conf/GENERIC b/sys/arch/arm64/conf/GENERIC
> > index 19fd6e03c4f..879d024503f 100644
> > --- a/sys/arch/arm64/conf/GENERIC
> > +++ b/sys/arch/arm64/conf/GENERIC
> > @@ -54,7 +54,9 @@ com*  at acpi?
> >  dwgpio*at acpi?
> >  dwiic* at acpi?
> >  iic*   at dwiic?
> > +ehci*  at acpi?
> >  ipmi*  at acpi?
> > +ohci*  at acpi?
> >  pluart*at acpi?
> >  sdhc*  at acpi?
> >  xhci*  at acpi?
> > diff --git a/sys/arch/arm64/conf/RAMDISK b/sys/arch/arm64/conf/RAMDISK
> > index b505e37b399..caf2eea44b8 100644
> > --- a/sys/arch/arm64/conf/RAMDISK
> > +++ b/sys/arch/arm64/conf/RAMDISK
> > @@ -44,6 +44,8 @@ pci*  at acpipci?
> >  ahci*  at acpi?
> >  ccp*   at acpi?# AMD Cryptographic Co-processor
> >  com*   at acpi?
> > +ehci*  at acpi?
> > +ohci*  at acpi?
> >  pluart*at acpi?
> >  sdhc*  at acpi?
> >  xhci*  at acpi?
> > diff --git a/sys/dev/acpi/ehci_acpi.c b/sys/dev/acpi/ehci_acpi.c
> > new file mode 100644
> > index 000..cd1777f26e4
> > --- /dev/null
> > +++ b/sys/dev/acpi/ehci_acpi.c
> > @@ -0,0 +1,125 @@
> > +/* $OpenBSD: ehci_acpi.c,v 1.4 2021/12/21 20:53:46 kettenis Exp $  */
> > +/*
> > + * Copyright (c) 2018 Mark Kettenis
> > + *
> > + * Permission to use, copy, modify, and distribute this software for any
> > + * purpose with or without fee is hereby granted, provided that the above
> > + * copyright notice and this permission notice appear in all copies.
> > + *
> > + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> > + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> > + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> > + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> > + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> > + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> > + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +struct ehci_acpi_softc {
> > +   struct ehci_softc sc;
> > +   struct acpi_softc *sc_acpi;
> > +   struct aml_node *sc_node;
> > +   void*sc_ih;
> > +};
> > +
> > +intehci_acpi_match(struct device *, void *, void *);
> > +void   ehci_acpi_attach(struct device *, struct device *, void *);
> > +
> > +struct cfattach ehci_acpi_ca = {
> > +   sizeof(struct ehci_acpi_softc), ehci_acpi_match, ehci_acpi_attach
> > +};
> > +
> > +const char *ehci_hids[] = {
> > +   "PNP0D20",
> > +   NULL
> > +};
> > +
> > +int
> > +ehci_acpi_match(struct device *parent, void *match, void *a

Re: ohci(4) and ehci(4) at acpi(4)

[Patrick Wildt]

On Wed, Dec 29, 2021 at 06:02:02PM +0100, Mark Kettenis wrote:
> 
> We have acpi_intr_disestablish() on arm64 now...
> 

Actually we also have it on amd64 now, so maybe we should start by
removing all those ifdefs?  Then there'll be less cargo-culting.

ok?

Patrick

diff --git a/sys/dev/acpi/dwgpio.c b/sys/dev/acpi/dwgpio.c
index f216fcfbe4f..1b409caa239 100644
--- a/sys/dev/acpi/dwgpio.c
+++ b/sys/dev/acpi/dwgpio.c
@@ -168,12 +168,10 @@ dwgpio_attach(struct device *parent, struct device *self, 
void *aux)
return;
 
 unmap:
-#ifdef notyet
for (i = 0; i < sc->sc_nirq; i++) {
if (sc->sc_ih[i])
acpi_intr_disestablish(sc->sc_ih[i]);
}
-#endif
free(sc->sc_ih, M_DEVBUF, sc->sc_nirq * sizeof(*sc->sc_ih));
free(sc->sc_pin_ih, M_DEVBUF, sc->sc_npins * sizeof(*sc->sc_pin_ih));
bus_space_unmap(sc->sc_memt, sc->sc_memh, aaa->aaa_size[0]);
diff --git a/sys/dev/acpi/if_bse_acpi.c b/sys/dev/acpi/if_bse_acpi.c
index a76dcb9360e..a9a87c3e7f6 100644
--- a/sys/dev/acpi/if_bse_acpi.c
+++ b/sys/dev/acpi/if_bse_acpi.c
@@ -121,9 +121,7 @@ bse_acpi_attach(struct device *parent, struct device *self, 
void *aux)
return;
 
 disestablish:
-#ifdef notyet
acpi_intr_disestablish(sc->sc.sc_ih);
-#endif
 unmap:
bus_space_unmap(sc->sc.sc_bst, sc->sc.sc_bsh, aaa->aaa_size[0]);
 }
diff --git a/sys/dev/acpi/xhci_acpi.c b/sys/dev/acpi/xhci_acpi.c
index aea9b1f18e7..c382bd3dd19 100644
--- a/sys/dev/acpi/xhci_acpi.c
+++ b/sys/dev/acpi/xhci_acpi.c
@@ -113,9 +113,7 @@ xhci_acpi_attach(struct device *parent, struct device 
*self, void *aux)
return;
 
 disestablish_ret:
-#ifdef notyet
acpi_intr_disestablish(sc->sc_ih);
-#endif
 unmap:
bus_space_unmap(sc->sc.iot, sc->sc.ioh, sc->sc.sc_size);
return;

Re: ohci(4) and ehci(4) at acpi(4)

[Patrick Wildt]

On Wed, Dec 29, 2021 at 05:03:50PM +0100, Patrick Wildt wrote:
> Hi,
> 
> a device I have still has oHCI and eHCI controllers, which are needed to
> be able to use the second USB port.
> 
> ehci(4) at acpi(4) is plain simple, as it attaches to PNP0D20.  I have
> copied the xhci(4) at acpi(4) file and added the functional changes that
> exist between xhci(4) and ehci(4) at fdt(4).
> 
> ohci(4) is very similar, I have also added the functional changes that
> way.  There's a difference in how they attach:  It uses a PRP0001 ID,
> which basically is a device-tree namespace link.  That means we match
> on that link *and* have to check the 'compatible' property.
> 
> With these changes, my second USB port works just fine.
> 
> Patrick

Actually, there's a better way to match ohci(4).  We can match on _CLS,
like we do for ahci(4) at acpi(4).  Updated diff below.

Patrick

diff --git a/sys/arch/arm64/conf/GENERIC b/sys/arch/arm64/conf/GENERIC
index 19fd6e03c4f..879d024503f 100644
--- a/sys/arch/arm64/conf/GENERIC
+++ b/sys/arch/arm64/conf/GENERIC
@@ -54,7 +54,9 @@ com*  at acpi?
 dwgpio*at acpi?
 dwiic* at acpi?
 iic*   at dwiic?
+ehci*  at acpi?
 ipmi*  at acpi?
+ohci*  at acpi?
 pluart*at acpi?
 sdhc*  at acpi?
 xhci*  at acpi?
diff --git a/sys/arch/arm64/conf/RAMDISK b/sys/arch/arm64/conf/RAMDISK
index b505e37b399..caf2eea44b8 100644
--- a/sys/arch/arm64/conf/RAMDISK
+++ b/sys/arch/arm64/conf/RAMDISK
@@ -44,6 +44,8 @@ pci*  at acpipci?
 ahci*  at acpi?
 ccp*   at acpi?# AMD Cryptographic Co-processor
 com*   at acpi?
+ehci*  at acpi?
+ohci*  at acpi?
 pluart*at acpi?
 sdhc*  at acpi?
 xhci*  at acpi?
diff --git a/sys/dev/acpi/ehci_acpi.c b/sys/dev/acpi/ehci_acpi.c
new file mode 100644
index 000..cd1777f26e4
--- /dev/null
+++ b/sys/dev/acpi/ehci_acpi.c
@@ -0,0 +1,125 @@
+/* $OpenBSD: ehci_acpi.c,v 1.4 2021/12/21 20:53:46 kettenis Exp $  */
+/*
+ * Copyright (c) 2018 Mark Kettenis
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct ehci_acpi_softc {
+   struct ehci_softc sc;
+   struct acpi_softc *sc_acpi;
+   struct aml_node *sc_node;
+   void*sc_ih;
+};
+
+intehci_acpi_match(struct device *, void *, void *);
+void   ehci_acpi_attach(struct device *, struct device *, void *);
+
+struct cfattach ehci_acpi_ca = {
+   sizeof(struct ehci_acpi_softc), ehci_acpi_match, ehci_acpi_attach
+};
+
+const char *ehci_hids[] = {
+   "PNP0D20",
+   NULL
+};
+
+int
+ehci_acpi_match(struct device *parent, void *match, void *aux)
+{
+   struct acpi_attach_args *aaa = aux;
+   struct cfdata *cf = match;
+
+   if (aaa->aaa_naddr < 1 || aaa->aaa_nirq < 1)
+   return 0;
+   return acpi_matchhids(aaa, ehci_hids, cf->cf_driver->cd_name);
+}
+
+void
+ehci_acpi_attach(struct device *parent, struct device *self, void *aux)
+{
+   struct ehci_acpi_softc *sc = (struct ehci_acpi_softc *)self;
+   struct acpi_attach_args *aaa = aux;
+   int error;
+
+   sc->sc_acpi = (struct acpi_softc *)parent;
+   sc->sc_node = aaa->aaa_node;
+   printf(" %s", sc->sc_node->name);
+
+   printf(" addr 0x%llx/0x%llx", aaa->aaa_addr[0], aaa->aaa_size[0]);
+   printf(" irq %d", aaa->aaa_irq[0]);
+
+   sc->sc.iot = aaa->aaa_bst[0];
+   sc->sc.sc_size = aaa->aaa_size[0];
+   sc->sc.sc_bus.dmatag = aaa->aaa_dmat;
+
+   if (bus_space_map(sc->sc.iot, aaa->aaa_addr[0], aaa->aaa_size[0],
+   0, >sc.ioh)) {
+   printf(": can't map registers\n");
+   return;
+   }
+
+   /* Disable interrupts, so we don't get any spurious ones. */
+   sc->sc.sc_offs = EREAD1(>sc, EHCI_CAPLENGTH);
+   EOWRITE2(>sc, EHCI_USBINTR, 0);
+
+   sc->sc_ih = acpi_

ohci(4) and ehci(4) at acpi(4)

[Patrick Wildt]

Hi,

a device I have still has oHCI and eHCI controllers, which are needed to
be able to use the second USB port.

ehci(4) at acpi(4) is plain simple, as it attaches to PNP0D20.  I have
copied the xhci(4) at acpi(4) file and added the functional changes that
exist between xhci(4) and ehci(4) at fdt(4).

ohci(4) is very similar, I have also added the functional changes that
way.  There's a difference in how they attach:  It uses a PRP0001 ID,
which basically is a device-tree namespace link.  That means we match
on that link *and* have to check the 'compatible' property.

With these changes, my second USB port works just fine.

Patrick

diff --git a/sys/arch/arm64/conf/GENERIC b/sys/arch/arm64/conf/GENERIC
index 19fd6e03c4f..879d024503f 100644
--- a/sys/arch/arm64/conf/GENERIC
+++ b/sys/arch/arm64/conf/GENERIC
@@ -54,7 +54,9 @@ com*  at acpi?
 dwgpio*at acpi?
 dwiic* at acpi?
 iic*   at dwiic?
+ehci*  at acpi?
 ipmi*  at acpi?
+ohci*  at acpi?
 pluart*at acpi?
 sdhc*  at acpi?
 xhci*  at acpi?
diff --git a/sys/arch/arm64/conf/RAMDISK b/sys/arch/arm64/conf/RAMDISK
index b505e37b399..caf2eea44b8 100644
--- a/sys/arch/arm64/conf/RAMDISK
+++ b/sys/arch/arm64/conf/RAMDISK
@@ -44,6 +44,8 @@ pci*  at acpipci?
 ahci*  at acpi?
 ccp*   at acpi?# AMD Cryptographic Co-processor
 com*   at acpi?
+ehci*  at acpi?
+ohci*  at acpi?
 pluart*at acpi?
 sdhc*  at acpi?
 xhci*  at acpi?
diff --git a/sys/dev/acpi/ehci_acpi.c b/sys/dev/acpi/ehci_acpi.c
new file mode 100644
index 000..cd1777f26e4
--- /dev/null
+++ b/sys/dev/acpi/ehci_acpi.c
@@ -0,0 +1,125 @@
+/* $OpenBSD: ehci_acpi.c,v 1.4 2021/12/21 20:53:46 kettenis Exp $  */
+/*
+ * Copyright (c) 2018 Mark Kettenis
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct ehci_acpi_softc {
+   struct ehci_softc sc;
+   struct acpi_softc *sc_acpi;
+   struct aml_node *sc_node;
+   void*sc_ih;
+};
+
+intehci_acpi_match(struct device *, void *, void *);
+void   ehci_acpi_attach(struct device *, struct device *, void *);
+
+struct cfattach ehci_acpi_ca = {
+   sizeof(struct ehci_acpi_softc), ehci_acpi_match, ehci_acpi_attach
+};
+
+const char *ehci_hids[] = {
+   "PNP0D20",
+   NULL
+};
+
+int
+ehci_acpi_match(struct device *parent, void *match, void *aux)
+{
+   struct acpi_attach_args *aaa = aux;
+   struct cfdata *cf = match;
+
+   if (aaa->aaa_naddr < 1 || aaa->aaa_nirq < 1)
+   return 0;
+   return acpi_matchhids(aaa, ehci_hids, cf->cf_driver->cd_name);
+}
+
+void
+ehci_acpi_attach(struct device *parent, struct device *self, void *aux)
+{
+   struct ehci_acpi_softc *sc = (struct ehci_acpi_softc *)self;
+   struct acpi_attach_args *aaa = aux;
+   int error;
+
+   sc->sc_acpi = (struct acpi_softc *)parent;
+   sc->sc_node = aaa->aaa_node;
+   printf(" %s", sc->sc_node->name);
+
+   printf(" addr 0x%llx/0x%llx", aaa->aaa_addr[0], aaa->aaa_size[0]);
+   printf(" irq %d", aaa->aaa_irq[0]);
+
+   sc->sc.iot = aaa->aaa_bst[0];
+   sc->sc.sc_size = aaa->aaa_size[0];
+   sc->sc.sc_bus.dmatag = aaa->aaa_dmat;
+
+   if (bus_space_map(sc->sc.iot, aaa->aaa_addr[0], aaa->aaa_size[0],
+   0, >sc.ioh)) {
+   printf(": can't map registers\n");
+   return;
+   }
+
+   /* Disable interrupts, so we don't get any spurious ones. */
+   sc->sc.sc_offs = EREAD1(>sc, EHCI_CAPLENGTH);
+   EOWRITE2(>sc, EHCI_USBINTR, 0);
+
+   sc->sc_ih = acpi_intr_establish(aaa->aaa_irq[0], aaa->aaa_irq_flags[0],
+   IPL_USB, ehci_intr, sc, sc->sc.sc_bus.bdev.dv_xname);
+   if (sc->sc_ih == NULL) {
+   printf(": can't establish interrupt\n");
+   goto unmap;
+   }
+
+   printf("\n");
+
+   strlcpy(sc->sc.sc_vendor, "Generic", sizeof(sc->sc.sc_vendor));
+   if ((error = ehci_init(>sc)) != 0) {
+   printf("%s: init 

Re: com(4) at acpi(4) on amd64

[Patrick Wildt]

On Mon, Dec 13, 2021 at 11:15:00PM +0100, Mark Kettenis wrote:
> > Date: Fri, 10 Dec 2021 07:56:44 +0100
> > From: Anton Lindqvist 
> > 
> > On Tue, Dec 07, 2021 at 01:08:45PM +0100, Mark Kettenis wrote:
> > > > Date: Tue, 7 Dec 2021 11:30:48 +0100
> > > > From: Anton Lindqvist 
> > > > 
> > > > On Mon, Dec 06, 2021 at 10:25:34PM +0100, Mark Kettenis wrote:
> > > > > > Date: Mon, 6 Dec 2021 21:45:03 +0100
> > > > > > From: Anton Lindqvist 
> > > > > > 
> > > > > > On Mon, Dec 06, 2021 at 09:23:45PM +0100, Mark Kettenis wrote:
> > > > > > > > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > > > > > > > From: Patrick Wildt 
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On one machine I had the pleasure of having to try and use the
> > > > > > > > Serial-over-LAN feature which shows up as just another com(4)
> > > > > > > > device.  Instead of having to manually add a com(4) at isa(4)
> > > > > > > > I figured it would be nicer to have them attach via ACPI.  At
> > > > > > > > least on that machine, the SOL definitely shows up in the DSDT.
> > > > > > > > 
> > > > > > > > Since I don't want to break any legacy machines, I figured I'd
> > > > > > > > keep ignoring the isa(4) addresses specified in amd64's GENERIC.
> > > > > > > > 
> > > > > > > > Right now this diff is more about putting it out there, not 
> > > > > > > > about
> > > > > > > > asking for OKs, as amd64 isn't really my strong suit.  If people
> > > > > > > > are interested, I can definitely put in all the feedback there 
> > > > > > > > is.
> > > > > > > > 
> > > > > > > > Patrick
> > > > > > > 
> > > > > > > anton@ has a better diff he's working on
> > > > > > 
> > > > > > Here's the diff in its current state. There's one thing I haven't 
> > > > > > had
> > > > > > the time to figure out yet: in order to get interrupts working on my
> > > > > > apu2 I had to explicit pass LR_EXTIRQ_MODE (aaa_irq_flags is zero) 
> > > > > > to
> > > > > > acpi_intr_establish() which causes IST_EDGE to be passed to
> > > > > > intr_establish(). Worth noting is that this matches what com at isa
> > > > > > already does. This was however not necessary on my amd64 build 
> > > > > > machine
> > > > > > where aaa_irq_flags also is zero.
> > > > > 
> > > > > Actually, it seems we're parsing the ACPI interrupt resource
> > > > > descriptor wrong.  The decompiled DSDTs I have here seem to use
> > > > > IRQNoFlags() for the interrupts, which apparently implies the
> > > > > interrupt is edge-triggered.
> > > > > 
> > > > > Let me see if I can cook a diff.
> > > > 
> > > > Updated diff now that kettenis@ fixed parsing of the irq flags.
> > > 
> > > A few comments below.
> > > 
> > > > diff --git share/man/man4/com.4 share/man/man4/com.4
> > > > index 73b421f2ca7..e54255fe0d6 100644
> > > > --- share/man/man4/com.4
> > > > +++ share/man/man4/com.4
> > > > @@ -61,11 +61,13 @@
> > > >  .Cd "com0 at isa? port 0x3f8 irq 4"
> > > >  .Cd "com1 at isa? port 0x2f8 irq 3"
> > > >  .Pp
> > > > +.Cd "# arm64 and amd64"
> > > > +.Cd "com* at acpi?"
> > > > +.Pp
> > > >  .Cd "# armv7"
> > > >  .Cd "com* at fdt?"
> > > >  .Pp
> > > >  .Cd "# arm64"
> > > > -.Cd "com* at acpi?"
> > > >  .Cd "com* at fdt?"
> > > 
> > > The armv7 and arm64 entries can be combined now
> > > 
> > > >  .Pp
> > > >  .Cd "# hppa"
> > > > diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC
> > > > index ecccd1323d9..87fcaced306 100644
> > > > --- sys/arch/amd64/conf/GENERIC
> > > > +++ sys/arch/amd64/conf/GENERIC
> > > > @@ -65,6 +65,11 @@

Re: com(4) at acpi(4) on amd64

[Patrick Wildt]

On Tue, Dec 07, 2021 at 01:08:45PM +0100, Mark Kettenis wrote:
> > Date: Tue, 7 Dec 2021 11:30:48 +0100
> > From: Anton Lindqvist 
> > 
> > On Mon, Dec 06, 2021 at 10:25:34PM +0100, Mark Kettenis wrote:
> > > > Date: Mon, 6 Dec 2021 21:45:03 +0100
> > > > From: Anton Lindqvist 
> > > > 
> > > > On Mon, Dec 06, 2021 at 09:23:45PM +0100, Mark Kettenis wrote:
> > > > > > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > > > > > From: Patrick Wildt 
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > On one machine I had the pleasure of having to try and use the
> > > > > > Serial-over-LAN feature which shows up as just another com(4)
> > > > > > device.  Instead of having to manually add a com(4) at isa(4)
> > > > > > I figured it would be nicer to have them attach via ACPI.  At
> > > > > > least on that machine, the SOL definitely shows up in the DSDT.
> > > > > > 
> > > > > > Since I don't want to break any legacy machines, I figured I'd
> > > > > > keep ignoring the isa(4) addresses specified in amd64's GENERIC.
> > > > > > 
> > > > > > Right now this diff is more about putting it out there, not about
> > > > > > asking for OKs, as amd64 isn't really my strong suit.  If people
> > > > > > are interested, I can definitely put in all the feedback there is.
> > > > > > 
> > > > > > Patrick
> > > > > 
> > > > > anton@ has a better diff he's working on
> > > > 
> > > > Here's the diff in its current state. There's one thing I haven't had
> > > > the time to figure out yet: in order to get interrupts working on my
> > > > apu2 I had to explicit pass LR_EXTIRQ_MODE (aaa_irq_flags is zero) to
> > > > acpi_intr_establish() which causes IST_EDGE to be passed to
> > > > intr_establish(). Worth noting is that this matches what com at isa
> > > > already does. This was however not necessary on my amd64 build machine
> > > > where aaa_irq_flags also is zero.
> > > 
> > > Actually, it seems we're parsing the ACPI interrupt resource
> > > descriptor wrong.  The decompiled DSDTs I have here seem to use
> > > IRQNoFlags() for the interrupts, which apparently implies the
> > > interrupt is edge-triggered.
> > > 
> > > Let me see if I can cook a diff.
> > 
> > Updated diff now that kettenis@ fixed parsing of the irq flags.
> 
> A few comments below.
> 
> > diff --git share/man/man4/com.4 share/man/man4/com.4
> > index 73b421f2ca7..e54255fe0d6 100644
> > --- share/man/man4/com.4
> > +++ share/man/man4/com.4
> > @@ -61,11 +61,13 @@
> >  .Cd "com0 at isa? port 0x3f8 irq 4"
> >  .Cd "com1 at isa? port 0x2f8 irq 3"
> >  .Pp
> > +.Cd "# arm64 and amd64"
> > +.Cd "com* at acpi?"
> > +.Pp
> >  .Cd "# armv7"
> >  .Cd "com* at fdt?"
> >  .Pp
> >  .Cd "# arm64"
> > -.Cd "com* at acpi?"
> >  .Cd "com* at fdt?"
> 
> The armv7 and arm64 entries can be combined now
> 
> >  .Pp
> >  .Cd "# hppa"
> > diff --git sys/arch/amd64/conf/GENERIC sys/arch/amd64/conf/GENERIC
> > index ecccd1323d9..87fcaced306 100644
> > --- sys/arch/amd64/conf/GENERIC
> > +++ sys/arch/amd64/conf/GENERIC
> > @@ -65,6 +65,11 @@ amdgpio* at acpi?
> >  aplgpio*   at acpi?
> >  bytgpio*   at acpi?
> >  chvgpio*   at acpi?
> > +com0   at acpi?
> > +com1   at acpi?
> > +com2   at acpi?
> > +com3   at acpi?
> > +com*   at acpi?
> >  glkgpio*   at acpi?
> >  pchgpio*   at acpi?
> >  sdhc*  at acpi?
> > diff --git sys/arch/amd64/conf/RAMDISK sys/arch/amd64/conf/RAMDISK
> > index 6041293b287..a5f10b357dd 100644
> > --- sys/arch/amd64/conf/RAMDISK
> > +++ sys/arch/amd64/conf/RAMDISK
> > @@ -34,6 +34,9 @@ acpipci*  at acpi?
> >  acpiprt*   at acpi?
> >  acpimadt0  at acpi?
> >  #acpitz*   at acpi?
> > +com0   at acpi?
> > +com1   at acpi?
> > +com*   at acpi?
> >  
> >  mpbios0at bios0
> 
> As Theo pointed out, this may not be entirely fool-proof.  We probe
> acpi(4) before isa(4), which is good.  Since we prevent ISA devices
> from attaching to address

Re: com(4) at acpi(4) on amd64

[Patrick Wildt]

Am Mon, Dec 06, 2021 at 09:23:45PM +0100 schrieb Mark Kettenis:
> > Date: Mon, 6 Dec 2021 21:08:04 +0100
> > From: Patrick Wildt 
> > 
> > Hi,
> > 
> > On one machine I had the pleasure of having to try and use the
> > Serial-over-LAN feature which shows up as just another com(4)
> > device.  Instead of having to manually add a com(4) at isa(4)
> > I figured it would be nicer to have them attach via ACPI.  At
> > least on that machine, the SOL definitely shows up in the DSDT.
> > 
> > Since I don't want to break any legacy machines, I figured I'd
> > keep ignoring the isa(4) addresses specified in amd64's GENERIC.
> > 
> > Right now this diff is more about putting it out there, not about
> > asking for OKs, as amd64 isn't really my strong suit.  If people
> > are interested, I can definitely put in all the feedback there is.
> > 
> > Patrick
> 
> anton@ has a better diff he's working on

Great, please forget I even said anything.

com(4) at acpi(4) on amd64

[Patrick Wildt]

Hi,

On one machine I had the pleasure of having to try and use the
Serial-over-LAN feature which shows up as just another com(4)
device.  Instead of having to manually add a com(4) at isa(4)
I figured it would be nicer to have them attach via ACPI.  At
least on that machine, the SOL definitely shows up in the DSDT.

Since I don't want to break any legacy machines, I figured I'd
keep ignoring the isa(4) addresses specified in amd64's GENERIC.

Right now this diff is more about putting it out there, not about
asking for OKs, as amd64 isn't really my strong suit.  If people
are interested, I can definitely put in all the feedback there is.

Patrick

diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
index ecccd1323d9..edb0131d823 100644
--- a/sys/arch/amd64/conf/GENERIC
+++ b/sys/arch/amd64/conf/GENERIC
@@ -76,6 +76,7 @@ tpm*  at acpi?
 acpihve*   at acpi?
 acpisurface*   at acpi?
 acpihid*   at acpi?
+com*   at acpi?
 ipmi0  at acpi? disable
 ccpmic*at iic?
 tipmic*at iic?
diff --git a/sys/dev/acpi/acpi.c b/sys/dev/acpi/acpi.c
index 7577424e8a2..e89869aedbd 100644
--- a/sys/dev/acpi/acpi.c
+++ b/sys/dev/acpi/acpi.c
@@ -3140,7 +3140,6 @@ const char *acpi_isa_hids[] = {
"PNP0303",  /* IBM Enhanced Keyboard (101/102-key, PS/2 Mouse) */
"PNP0400",  /* Standard LPT Parallel Port */
"PNP0401",  /* ECP Parallel Port */
-   "PNP0501",  /* 16550A-compatible COM Serial Port */
"PNP0700",  /* PC-class Floppy Disk Controller */
"PNP0F03",  /* Microsoft PS/2-style Mouse */
"PNP0F13",  /* PS/2 Mouse */
diff --git a/sys/dev/acpi/com_acpi.c b/sys/dev/acpi/com_acpi.c
index 852be6c71b3..9251b973372 100644
--- a/sys/dev/acpi/com_acpi.c
+++ b/sys/dev/acpi/com_acpi.c
@@ -49,6 +49,7 @@ struct cfattach com_acpi_ca = {
 
 const char *com_hids[] = {
"HISI0031",
+   "PNP0501",
NULL
 };
 
@@ -61,6 +62,13 @@ com_acpi_match(struct device *parent, void *match, void *aux)
struct acpi_attach_args *aaa = aux;
struct cfdata *cf = match;
 
+#ifdef __amd64__
+   /* Ignore com(4) at isa(4) */
+   if (aaa->aaa_addr[0] == 0x3f8 || aaa->aaa_addr[0] == 0x2f8 ||
+   aaa->aaa_addr[0] == 0x3e8 || aaa->aaa_addr[0] == 0x2e8)
+   return 0;
+#endif
+
return acpi_matchhids(aaa, com_hids, cf->cf_driver->cd_name);
 }
 
@@ -95,8 +103,10 @@ com_acpi_attach(struct device *parent, struct device *self, 
void *aux)
sc->sc.sc_uarttype = COM_UART_16550;
sc->sc.sc_frequency = freq ? freq : COM_FREQ;
 
+#ifndef __amd64__
sc->sc.sc_reg_width = acpi_getpropint(sc->sc_node, "reg-io-width", 4);
sc->sc.sc_reg_shift = acpi_getpropint(sc->sc_node, "reg-shift", 2);
+#endif
 
if (com_acpi_is_console(sc)) {
SET(sc->sc.sc_hwflags, COM_HW_CONSOLE);
@@ -105,7 +115,9 @@ com_acpi_attach(struct device *parent, struct device *self, 
void *aux)
comconsrate = B115200;
}
 
-   if (bus_space_map(sc->sc.sc_iot, aaa->aaa_addr[0], aaa->aaa_size[0],
+   if (sc->sc.sc_iobase == comconsaddr)
+   sc->sc.sc_ioh = comconsioh;
+   else if (bus_space_map(sc->sc.sc_iot, aaa->aaa_addr[0], 
aaa->aaa_size[0],
0, >sc.sc_ioh)) {
printf(": can't map registers\n");
return;

Re: lib/Makefile: libfido2 requires libz

[Patrick Wildt]

On Tue, Nov 30, 2021 at 03:24:17PM -0700, Theo de Raadt wrote:
> Todd C. Miller  wrote:
> 
> > On Tue, 30 Nov 2021 23:18:23 +0100, Mark Kettenis wrote:
> > 
> > > Maybe add a comment here that libfido2 depends on libz?
> > >
> > > > +SUBDIR+=libfido2
> > 
> > Yes, please.  With a comment this is OK millert@
> 
> Or just mark these as "phase 2", without saying why.
> 

So, this better?

diff --git a/lib/Makefile b/lib/Makefile
index 7f95cb1e3e7..f96aae01984 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -3,9 +3,12 @@
 
 SUBDIR=csu libagentx libarch libc libcbor libcrypto libcurses \
libedit libelf libevent libexpat \
-   libfido2 libform libfuse libkeynote libkvm libl libm libmenu \
+   libform libfuse libkeynote libkvm libl libm libmenu \
libossaudio libpanel libpcap libradius librthread \
librpcsvc libskey libsndio libssl libtls libusbhid \
libutil liby libz
 
+# Phase 2
+SUBDIR+=libfido2
+
 .include 

Re: lib/Makefile: libfido2 requires libz

[Patrick Wildt]

On Thu, Nov 11, 2021 at 08:27:21PM +0900, SASANO Takayoshi wrote:
> Hi,
> 
> Recently I tried to crossbuild for arm64 on amd64.
> I found "TARGET=arm64 make cross-tools" stops when building libfido2.
> 
> libfido2 requires libz but this is not built yet at that time.
> lib/Makefile needs to tweak like this.
> 
> openbsd-current-vm# diff -uNpr Makefile~ Makefile
> --- Makefile~   Sun Jan  3 05:04:36 2021
> +++ MakefileThu Nov 11 19:47:42 2021
> @@ -2,10 +2,10 @@
>  #  $NetBSD: Makefile,v 1.20.4.1 1996/06/14 17:22:38 cgd Exp $
> 
>  SUBDIR=csu libagentx libarch libc libcbor libcrypto libcurses \
> -   libedit libelf libevent libexpat \
> +   libedit libelf libevent libexpat libz \
> libfido2 libform libfuse libkeynote libkvm libl libm libmenu \
> libossaudio libpanel libpcap libradius librthread \
> librpcsvc libskey libsndio libssl libtls libusbhid \
> -   libutil liby libz
> +   libutil liby
> 
>  .include 
> openbsd-current-vm#
> 
> It works good, but I think there is better build order.
> 
> -- 
> SASANO Takayoshi (JG1UAA) 
> 

Hi,

I just had the same issue and after a short discussion it seems like
it's a better idea to separate libfido2 into a separate line to show
that it should be built at the end due to having libz as dependency.

Comments? ok?

Patrick

diff --git a/lib/Makefile b/lib/Makefile
index 7f95cb1e3e7..1f1586b0518 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -3,9 +3,10 @@
 
 SUBDIR=csu libagentx libarch libc libcbor libcrypto libcurses \
libedit libelf libevent libexpat \
-   libfido2 libform libfuse libkeynote libkvm libl libm libmenu \
+   libform libfuse libkeynote libkvm libl libm libmenu \
libossaudio libpanel libpcap libradius librthread \
librpcsvc libskey libsndio libssl libtls libusbhid \
libutil liby libz
+SUBDIR+=libfido2
 
 .include 

hvkbd(4): Hyper-V Synthetic Keyboard

[Patrick Wildt]

Hi,

this is a port of NetBSD's hvkbd(4).  While Hyper-V Gen1 provides
pckbc(4) as keyboard, Gen2's no-legcay-HW approach needs us to make
use of the Synthetic Keyboard if we want to be able to type in the
framebuffer console.

One thing I'm not so sure about is if we really need another wskbd
type (WSKBD_TYPE_HYPERV).

Comments?  ok?

Patrick

diff --git a/sys/arch/amd64/conf/GENERIC b/sys/arch/amd64/conf/GENERIC
index ecccd1323d9..85a95e11eae 100644
--- a/sys/arch/amd64/conf/GENERIC
+++ b/sys/arch/amd64/conf/GENERIC
@@ -92,6 +92,8 @@ xnf*  at xen? # Xen Netfront
 xbf*   at xen? # Xen Blkfront
 
 hyperv0at pvbus?   # Hyper-V guest
+hvkbd* at hyperv?  # Hyper-V Keyboard
+wskbd* at hvkbd? mux 1
 hvn*   at hyperv?  # Hyper-V NetVSC
 hvs*   at hyperv?  # Hyper-V StorVSC
 
diff --git a/sys/dev/pv/files.pv b/sys/dev/pv/files.pv
index e081897d582..0c0ab1a23e0 100644
--- a/sys/dev/pv/files.pv
+++ b/sys/dev/pv/files.pv
@@ -40,6 +40,11 @@ attach   hyperv at pvbus
 file   dev/pv/hyperv.c hyperv  needs-flag
 file   dev/pv/hypervic.c   hyperv
 
+# Hyper-V Keyboard
+device hvkbd: wskbddev
+attach hvkbd at hyperv
+file   dev/pv/hvkbd.c  hvkbd
+
 # Hyper-V NetVSC
 device hvn: ether, ifnet, ifmedia
 attach hvn at hyperv
diff --git a/sys/dev/pv/hvkbd.c b/sys/dev/pv/hvkbd.c
new file mode 100644
index 000..f8dc1202033
--- /dev/null
+++ b/sys/dev/pv/hvkbd.c
@@ -0,0 +1,593 @@
+/* $OpenBSD$   */
+/* $NetBSD: hvkbd.c,v 1.9 2021/08/07 16:19:11 thorpej Exp $*/
+
+/*-
+ * Copyright (c) 2017 Microsoft Corp.
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice unmodified, this list of conditions, and the following
+ *disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
+ * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ * $FreeBSD: head/sys/dev/hyperv/input/hv_kbd.c 317821 2017-05-05 03:28:30Z 
sephe $
+ * $FreeBSD: head/sys/dev/hyperv/input/hv_kbdc.c 320490 2017-06-30 03:01:22Z 
sephe $
+ * $FreeBSD: head/sys/dev/hyperv/input/hv_kbdc.h 316515 2017-04-05 05:01:23Z 
sephe $
+ */
+
+/* __KERNEL_RCSID(0, "$NetBSD: hvkbd.c,v 1.9 2021/08/07 16:19:11 thorpej Exp 
$"); */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define HVKBD_BUFSIZE  (4 * PAGE_SIZE)
+#define HVKBD_TX_RING_SIZE (10 * PAGE_SIZE)
+#define HVKBD_RX_RING_SIZE (10 * PAGE_SIZE)
+
+#define HVKBD_VER_MAJOR(1)
+#define HVKBD_VER_MINOR(0)
+#define HVKBD_VERSION  ((HVKBD_VER_MAJOR << 16) | HVKBD_VER_MINOR)
+
+enum hvkbd_msg_type {
+   HVKBD_PROTO_REQUEST = 1,
+   HVKBD_PROTO_RESPONSE= 2,
+   HVKBD_PROTO_EVENT   = 3,
+   HVKBD_PROTO_LED_INDICATORS  = 4
+};
+
+struct hvkbd_msg_hdr {
+   uint32_ttype;
+} __packed;
+
+struct hvkbd_proto_req {
+   struct hvkbd_msg_hdrhdr;
+   uint32_tver;
+} __packed;
+
+struct hvkbd_proto_resp {
+   struct hvkbd_msg_hdrhdr;
+   uint32_tstatus;
+#defineRESP_STATUS_ACCEPTED(1 << 0)
+} __packed;
+
+struct keystroke {
+   uint16_tmakecode;
+   uint16_tpad0;
+   uint32_tinfo;
+#define KS_INFO_UNICODE(1 << 0)
+#define KS_INFO_BREAK  (1 << 1)
+#define KS_INFO_E0 (1 << 2)
+#define KS_INFO_E1 (1 << 3)
+} __packed;
+
+struct hvkbd_keystroke {
+   struct hvkbd_msg_hdrhdr;
+   struct keystrokeks;
+} __packed;
+
+struct hvkbd_keystroke_info {
+   LIST_ENTRY(hvkbd_keystroke_info)link;
+   

Re: fix uchcom(4) handling of parity and character size config

[Patrick Wildt]

Am Wed, Oct 27, 2021 at 06:46:38AM +1000 schrieb David Gwynne:
> i bought some random usb to rs485 serial adapters so i can talk
> modbus to a thing, but then discovered i can't talk to the modbus
> thing because uchcom doesn't support configuring parity.
> 
> this ports the functionality to support configuring parity and char size
> masks from netbsd src/sys/dev/usb/uchcom.c r1.26. part of that change
> including tweaks to uchcom_reset_chip, which was then changed in r1.28
> back to what we already have, so i left that chunk out.
> 
> ive tested this talking to a device at 19200 with cs8 and even
> parity. more tests would be appreciated to make sure i haven't
> broken existing use functionality.

ok patrick@

> Index: uchcom.c
> ===
> RCS file: /cvs/src/sys/dev/usb/uchcom.c,v
> retrieving revision 1.28
> diff -u -p -r1.28 uchcom.c
> --- uchcom.c  31 Jul 2020 10:49:33 -  1.28
> +++ uchcom.c  26 Oct 2021 20:33:36 -
> @@ -72,9 +72,8 @@ int uchcomdebug = 0;
>  #define UCHCOM_REG_BPS_DIV   0x13
>  #define UCHCOM_REG_BPS_MOD   0x14
>  #define UCHCOM_REG_BPS_PAD   0x0F
> -#define UCHCOM_REG_BREAK10x05
> -#define UCHCOM_REG_BREAK20x18
> -#define UCHCOM_REG_LCR1  0x18
> +#define UCHCOM_REG_BREAK 0x05
> +#define UCHCOM_REG_LCR   0x18
>  #define UCHCOM_REG_LCR2  0x25
>  
>  #define UCHCOM_VER_200x20
> @@ -83,11 +82,25 @@ int   uchcomdebug = 0;
>  #define UCHCOM_BPS_MOD_BASE  2000
>  #define UCHCOM_BPS_MOD_BASE_OFS  1100
>  
> +#define UCHCOM_BPS_PRE_IMM   0x80/* CH341: immediate RX forwarding */
> +
>  #define UCHCOM_DTR_MASK  0x20
>  #define UCHCOM_RTS_MASK  0x40
>  
> -#define UCHCOM_BRK1_MASK 0x01
> -#define UCHCOM_BRK2_MASK 0x40
> +#define UCHCOM_BREAK_MASK0x01
> +
> +#define UCHCOM_LCR_CS5   0x00
> +#define UCHCOM_LCR_CS6   0x01
> +#define UCHCOM_LCR_CS7   0x02
> +#define UCHCOM_LCR_CS8   0x03
> +#define UCHCOM_LCR_STOPB 0x04
> +#define UCHCOM_LCR_PARENB0x08
> +#define UCHCOM_LCR_PARODD0x00
> +#define UCHCOM_LCR_PAREVEN   0x10
> +#define UCHCOM_LCR_PARMARK   0x20
> +#define UCHCOM_LCR_PARSPACE  0x30
> +#define UCHCOM_LCR_TXE   0x40
> +#define UCHCOM_LCR_RXE   0x80
>  
>  #define UCHCOM_INTR_STAT10x02
>  #define UCHCOM_INTR_STAT20x03
> @@ -577,23 +590,21 @@ int
>  uchcom_set_break(struct uchcom_softc *sc, int onoff)
>  {
>   usbd_status err;
> - uint8_t brk1, brk2;
> + uint8_t brk, lcr;
>  
> - err = uchcom_read_reg(sc, UCHCOM_REG_BREAK1, , UCHCOM_REG_BREAK2,
> - );
> + err = uchcom_read_reg(sc, UCHCOM_REG_BREAK, , UCHCOM_REG_LCR, );
>   if (err)
>   return EIO;
>   if (onoff) {
>   /* on - clear bits */
> - brk1 &= ~UCHCOM_BRK1_MASK;
> - brk2 &= ~UCHCOM_BRK2_MASK;
> + brk &= ~UCHCOM_BREAK_MASK;
> + lcr &= ~UCHCOM_LCR_TXE;
>   } else {
>   /* off - set bits */
> - brk1 |= UCHCOM_BRK1_MASK;
> - brk2 |= UCHCOM_BRK2_MASK;
> + brk |= UCHCOM_BREAK_MASK;
> + lcr |= UCHCOM_LCR_TXE;
>   }
> - err = uchcom_write_reg(sc, UCHCOM_REG_BREAK1, brk1, UCHCOM_REG_BREAK2,
> - brk2);
> + err = uchcom_write_reg(sc, UCHCOM_REG_BREAK, brk, UCHCOM_REG_LCR, lcr);
>   if (err)
>   return EIO;
>  
> @@ -665,23 +676,50 @@ uchcom_set_dte_rate(struct uchcom_softc 
>  int
>  uchcom_set_line_control(struct uchcom_softc *sc, tcflag_t cflag)
>  {
> - /*
> -  * XXX: it is difficult to handle the line control appropriately:
> -  *   work as chip default - CS8, no parity, !CSTOPB
> -  *   other modes are not supported.
> -  */
> + usbd_status err;
> + uint8_t lcr = 0, lcr2 = 0;
> +
> + err = uchcom_read_reg(sc, UCHCOM_REG_LCR, ,
> + UCHCOM_REG_LCR2, );
> + if (err) {
> + printf("%s: cannot get LCR: %s\n",
> + sc->sc_dev.dv_xname, usbd_errstr(err));
> + return EIO;
> + }
> +
> + lcr = UCHCOM_LCR_RXE | UCHCOM_LCR_TXE;
>  
>   switch (ISSET(cflag, CSIZE)) {
>   case CS5:
> + lcr |= UCHCOM_LCR_CS5;
> + break;
>   case CS6:
> + lcr |= UCHCOM_LCR_CS6;
> + break;
>   case CS7:
> - return EINVAL;
> + lcr |= UCHCOM_LCR_CS7;
> + break;
>   case CS8:
> + lcr |= UCHCOM_LCR_CS8;
>   break;
>   }
>  
> - if (ISSET(cflag, PARENB) || ISSET(cflag, CSTOPB))
> - return EINVAL;
> + if (ISSET(cflag, PARENB)) {
> + lcr |= UCHCOM_LCR_PARENB;
> + if (!ISSET(cflag, PARODD))
> + lcr |= UCHCOM_LCR_PAREVEN;
> + }
> +
> + if (ISSET(cflag, CSTOPB)) {
> + lcr |= UCHCOM_LCR_STOPB;
> + }
> 

bootloader: remove unsued variables

[Patrick Wildt]

Hi,

this fixes the build of sys/arch/amd64/stand with LLVM 13.

ok?

Patrick

diff --git a/sys/lib/libsa/netif.c b/sys/lib/libsa/netif.c
index d1a5e180291..79c6496878e 100644
--- a/sys/lib/libsa/netif.c
+++ b/sys/lib/libsa/netif.c
@@ -85,7 +85,7 @@ netif_match(struct netif *nif, void *machdep_hint)
 struct netif *
 netif_select(void *machdep_hint)
 {
-   int d, u, unit_done, s;
+   int d, u, s;
struct netif_driver *drv;
struct netif cur_if;
static struct netif best_if;
@@ -106,7 +106,6 @@ netif_select(void *machdep_hint)
 
for (u = 0; u < drv->netif_nifs; u++) {
cur_if.nif_unit = u;
-   unit_done = 0;
 
 #ifdef NETIF_DEBUG
if (netif_debug)
diff --git a/sys/lib/libsa/tftp.c b/sys/lib/libsa/tftp.c
index 3eea8bbe66e..6bfca23a761 100644
--- a/sys/lib/libsa/tftp.c
+++ b/sys/lib/libsa/tftp.c
@@ -383,9 +383,6 @@ tftp_write(struct open_file *f, void *start, size_t size, 
size_t *resid)
 int
 tftp_stat(struct open_file *f, struct stat *sb)
 {
-   struct tftp_handle *tftpfile;
-   tftpfile = (struct tftp_handle *) f->f_fsdata;
-
sb->st_mode = 0444;
sb->st_nlink = 1;
sb->st_uid = 0;

some warnings in prep for LLVM 13

[Patrick Wildt]

Hi,

mortimer@ has this diff in his tree for LLVM 13.  I actually haven't
tried to see if it works fine with LLVM 11, but I feel it needs to be
sent out and not just be blindly committed.

If someone wants to take care of this, it would be nice, so I can take
care of the remaining parts of sending out the LLVM 13 diff.

Patrick

diff --git a/gnu/usr.bin/binutils-2.17/Makefile.bsd-wrapper 
b/gnu/usr.bin/binutils-2.17/Makefile.bsd-wrapper
index 611a2169862..f4c4e224dc5 100644
--- a/gnu/usr.bin/binutils-2.17/Makefile.bsd-wrapper
+++ b/gnu/usr.bin/binutils-2.17/Makefile.bsd-wrapper
@@ -7,7 +7,7 @@ TARGET_ARCH?=   ${MACHINE_ARCH}
 SUBDIRS=   opcodes bfd
 CONF_SUBDIRS=  opcodes bfd
 
-CFLAGS+=   ${PIE_DEFAULT}
+CFLAGS+=   ${PIE_DEFAULT} -Wno-unused-but-set-variable 
-Wno-null-pointer-subtraction
 XCFLAGS=   CC="${CC}" CFLAGS="${CFLAGS} ${COPTS}" LDFLAGS="${LDSTATIC}"
 # This allows moving the whole binutils installation around for 
 # testing purposes
diff --git a/lib/csu/crtbeginS.c b/lib/csu/crtbeginS.c
index a4a7cd19fce..41500fc1442 100644
--- a/lib/csu/crtbeginS.c
+++ b/lib/csu/crtbeginS.c
@@ -85,6 +85,7 @@ int   _thread_atfork(void (*)(void), void (*)(void), void 
(*)(void), void *)
__attribute__((weak));
 
 int
+__attribute__((weak))
 pthread_atfork(void (*prep)(void), void (*parent)(void), void (*child)(void))
 {
return (_thread_atfork(prep, parent, child, &__dso_handle));
diff --git a/lib/libc/arch/amd64/sys/brk.S b/lib/libc/arch/amd64/sys/brk.S
index ce69679e389..ee1c11f7643 100644
--- a/lib/libc/arch/amd64/sys/brk.S
+++ b/lib/libc/arch/amd64/sys/brk.S
@@ -48,7 +48,6 @@ __minbrk:
END(__minbrk)
.type   __minbrk,@object
 
-   .weak   brk
 ENTRY(brk)
cmpq%rdi,__minbrk(%rip)
jb  1f
diff --git a/lib/libc/arch/amd64/sys/sbrk.S b/lib/libc/arch/amd64/sys/sbrk.S
index 8d7d68909b2..db53a6bb643 100644
--- a/lib/libc/arch/amd64/sys/sbrk.S
+++ b/lib/libc/arch/amd64/sys/sbrk.S
@@ -53,7 +53,6 @@ __curbrk:
END(__curbrk)
.type   __curbrk,@object
 
-   .weak   sbrk
 ENTRY(sbrk)
movq__curbrk(%rip),%rax
movslq  %edi,%rsi
diff --git a/lib/libcrypto/Makefile b/lib/libcrypto/Makefile
index 1a3a3888352..f6063ffb194 100644
--- a/lib/libcrypto/Makefile
+++ b/lib/libcrypto/Makefile
@@ -16,7 +16,7 @@ LCRYPTO_SRC=  ${.CURDIR}
 
 CFLAGS+= -Wall -Wundef
 .if ${COMPILER_VERSION:L} == "clang"
-CFLAGS+= -Werror
+CFLAGS+= -Werror -Wno-unused-but-set-variable
 .endif
 CFLAGS+= -DLIBRESSL_INTERNAL
 
diff --git a/sys/arch/amd64/conf/Makefile.amd64 
b/sys/arch/amd64/conf/Makefile.amd64
index d36bae30417..83bd9a9fed1 100644
--- a/sys/arch/amd64/conf/Makefile.amd64
+++ b/sys/arch/amd64/conf/Makefile.amd64
@@ -70,7 +70,8 @@ CMACHFLAGS+=  -mno-retpoline
 .endif
 .if ${COMPILER_VERSION:Mclang}
 NO_INTEGR_AS=  -no-integrated-as
-CWARNFLAGS+=   -Wno-address-of-packed-member -Wno-constant-conversion
+CWARNFLAGS+=   -Wno-address-of-packed-member -Wno-constant-conversion \
+   -Wno-unused-but-set-variable -Wno-gnu-folding-constant
 .endif
 
 DEBUG?=-g
diff --git a/sys/arch/amd64/stand/pxeboot/Makefile 
b/sys/arch/amd64/stand/pxeboot/Makefile
index 9b028d8f4aa..cc92233463b 100644
--- a/sys/arch/amd64/stand/pxeboot/Makefile
+++ b/sys/arch/amd64/stand/pxeboot/Makefile
@@ -71,7 +71,7 @@ CPPFLAGS+=-DBOOTMAGIC=$(BOOTMAGIC) ${DEBUGFLAGS} 
-DLINKADDR=${LINKADDR}
 CPPFLAGS+=-DSLOW -DSMALL -DNOBYFOUR -DNO_GZIP -DDYNAMIC_CRC_TABLE -DBUILDFIXED
 CPPFLAGS+=-DHEAP_LIMIT=${HEAP_LIMIT} -I${S}/stand/boot #-DCOMPAT_UFS
 CFLAGS+=-m32
-CFLAGS+=$(SACFLAGS) -D__INTERNAL_LIBSA_CREAD -fno-pie
+CFLAGS+=$(SACFLAGS) -D__INTERNAL_LIBSA_CREAD -fno-pie 
-Wno-unused-but-set-variable
 AFLAGS+=${NO_INTEGR_AS}
 # AFLAGS+=-Wa,-a
 AFLAGS+=-m32 # -Wa,-R
diff --git a/usr.bin/openssl/Makefile b/usr.bin/openssl/Makefile
index 664a5200037..e33763e7420 100644
--- a/usr.bin/openssl/Makefile
+++ b/usr.bin/openssl/Makefile
@@ -17,6 +17,7 @@ CFLAGS+= -Wuninitialized
 CFLAGS+= -Wunused
 .if ${COMPILER_VERSION:L} == "clang"
 CFLAGS+= -Werror
+CFLAGS+= -Wno-unused-but-set-variable
 .endif
 CFLAGS+= -DLIBRESSL_INTERNAL
 
diff --git a/sys/arch/amd64/conf/Makefile.amd64 
b/sys/arch/amd64/conf/Makefile.amd64
index d36bae30417..83bd9a9fed1 100644
--- a/sys/arch/amd64/conf/Makefile.amd64
+++ b/sys/arch/amd64/conf/Makefile.amd64
@@ -70,7 +70,8 @@ CMACHFLAGS+=  -mno-retpoline
 .endif
 .if ${COMPILER_VERSION:Mclang}
 NO_INTEGR_AS=  -no-integrated-as
-CWARNFLAGS+=   -Wno-address-of-packed-member -Wno-constant-conversion
+CWARNFLAGS+=   -Wno-address-of-packed-member -Wno-constant-conversion \
+   -Wno-unused-but-set-variable -Wno-gnu-folding-constant
 .endif
 
 DEBUG?=-g
diff --git a/sys/arch/amd64/stand/pxeboot/Makefile 
b/sys/arch/amd64/stand/pxeboot/Makefile
index 9b028d8f4aa..cc92233463b 100644
--- a/sys/arch/amd64/stand/pxeboot/Makefile
+++ b/sys/arch/amd64/stand/pxeboot/Makefile
@@ -71,7 +71,7 @@ CPPFLAGS+=-DBOOTMAGIC=$(BOOTMAGIC) ${DEBUGFLAGS} 

Re: riscv64: ld.lld is too picky on ABI mismatch

[Patrick Wildt]

Am Mon, Oct 25, 2021 at 11:43:55AM +0200 schrieb Mark Kettenis:
> > From: Jeremie Courreges-Anglas 
> > Date: Sun, 24 Oct 2021 17:30:46 +0100
> > 
> > clang(1) defaults to FP ABI but ld(1) -melf64lriscv doesn't.  This is
> > a problem as soon as a port tries to use raw ld(1) -b binary to embed
> > data in a .o file.
> > 
> > Downgrading this hard error to a warning seems more useful as far as the
> > ports tree is concerned.  The diff below fixes
> > databases/postgresql-pllua and should also fix textproc/mupdf and net/utox.
> > 
> > There's another diff here: https://reviews.llvm.org/D106378
> > but it's slightly more complicated and it received seemingly negative
> > feedback.  So I'm just using a minimal change to fit our needs.
> > 
> > ok?
> 
> I think we should try to avoid deviating from upstream as much as
> possible.  And I agree with the folks who argue that the mismatching
> objects are created with the wrong tools.  But if mortimer@ and
> patrick@ can deal with carrying this local modification I won't
> object.

Well, I was about to send an LLVM 13 diff... so can we revisit this diff
when we're updated to LLVM 13?

> > Index: ELF/Arch/RISCV.cpp
> > ===
> > RCS file: /cvs/src/gnu/llvm/lld/ELF/Arch/RISCV.cpp,v
> > retrieving revision 1.1.1.2
> > diff -u -p -r1.1.1.2 RISCV.cpp
> > --- ELF/Arch/RISCV.cpp  28 Apr 2021 12:29:31 -  1.1.1.2
> > +++ ELF/Arch/RISCV.cpp  24 Oct 2021 15:55:49 -
> > @@ -122,8 +122,8 @@ uint32_t RISCV::calcEFlags() const {
> >target |= EF_RISCV_RVC;
> >  
> >  if ((eflags & EF_RISCV_FLOAT_ABI) != (target & EF_RISCV_FLOAT_ABI))
> > -  error(toString(f) +
> > -": cannot link object files with different floating-point 
> > ABI");
> > +  warn(toString(f) +
> > +": linking object files with different floating-point ABI");
> >  
> >  if ((eflags & EF_RISCV_RVE) != (target & EF_RISCV_RVE))
> >error(toString(f) +
> > 
> > 
> > -- 
> > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE
> > 
> > 
> 

Re: crypto: remove crypto queue

[Patrick Wildt]

On Fri, Oct 22, 2021 at 12:03:07AM +0200, Tobias Heider wrote:
> Currently, all crypto users set CRYPTO_F_NOQUEUE to run crypto operations
> without queue and there are no plans to switch back to using the queue.
> The diff below removes the flag together with the queueing code.
> 
> ok?

Looks good to me, ok patrick@.

Next step is removing crypto_taskq, crypto_taskq_mpsafe and the crp_task
member in struct cryptoop?

> Index: dev/softraid_crypto.c
> ===
> RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
> retrieving revision 1.142
> diff -u -p -r1.142 softraid_crypto.c
> --- dev/softraid_crypto.c 13 Oct 2021 22:43:44 -  1.142
> +++ dev/softraid_crypto.c 21 Oct 2021 21:50:31 -
> @@ -325,7 +325,7 @@ sr_crypto_prepare(struct sr_workunit *wu
>   crwu->cr_crp->crp_opaque = crwu;
>   crwu->cr_crp->crp_ilen = xs->datalen;
>   crwu->cr_crp->crp_alloctype = M_DEVBUF;
> - crwu->cr_crp->crp_flags = CRYPTO_F_IOV | CRYPTO_F_NOQUEUE;
> + crwu->cr_crp->crp_flags = CRYPTO_F_IOV;
>   crwu->cr_crp->crp_buf = >cr_uio;
>   for (i = 0; i < crwu->cr_crp->crp_ndesc; i++, blkno++) {
>   crd = >cr_crp->crp_desc[i];
> Index: netinet/ip_ah.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_ah.c,v
> retrieving revision 1.156
> diff -u -p -r1.156 ip_ah.c
> --- netinet/ip_ah.c   13 Oct 2021 22:43:44 -  1.156
> +++ netinet/ip_ah.c   21 Oct 2021 21:50:32 -
> @@ -684,7 +684,7 @@ ah_input(struct mbuf *m, struct tdb *tdb
>  
>   /* Crypto operation descriptor. */
>   crp->crp_ilen = m->m_pkthdr.len; /* Total input length. */
> - crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE | CRYPTO_F_NOQUEUE;
> + crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE;
>   crp->crp_buf = (caddr_t)m;
>   crp->crp_callback = ipsec_input_cb;
>   crp->crp_sid = tdb->tdb_cryptoid;
> @@ -1131,7 +1131,7 @@ ah_output(struct mbuf *m, struct tdb *td
>  
>   /* Crypto operation descriptor. */
>   crp->crp_ilen = m->m_pkthdr.len; /* Total input length. */
> - crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE | CRYPTO_F_NOQUEUE;
> + crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE;
>   crp->crp_buf = (caddr_t)m;
>   crp->crp_callback = ipsec_output_cb;
>   crp->crp_sid = tdb->tdb_cryptoid;
> Index: netinet/ip_esp.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_esp.c,v
> retrieving revision 1.175
> diff -u -p -r1.175 ip_esp.c
> --- netinet/ip_esp.c  21 Oct 2021 08:39:33 -  1.175
> +++ netinet/ip_esp.c  21 Oct 2021 21:50:32 -
> @@ -496,7 +496,7 @@ esp_input(struct mbuf *m, struct tdb *td
>  
>   /* Crypto operation descriptor */
>   crp->crp_ilen = m->m_pkthdr.len; /* Total input length */
> - crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE | CRYPTO_F_NOQUEUE;
> + crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE;
>   crp->crp_buf = (caddr_t)m;
>   crp->crp_callback = ipsec_input_cb;
>   crp->crp_sid = tdb->tdb_cryptoid;
> @@ -978,7 +978,7 @@ esp_output(struct mbuf *m, struct tdb *t
>  
>   /* Crypto operation descriptor. */
>   crp->crp_ilen = m->m_pkthdr.len; /* Total input length. */
> - crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE | CRYPTO_F_NOQUEUE;
> + crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE;
>   crp->crp_buf = (caddr_t)m;
>   crp->crp_callback = ipsec_output_cb;
>   crp->crp_opaque = (caddr_t)tc;
> Index: netinet/ip_ipcomp.c
> ===
> RCS file: /cvs/src/sys/netinet/ip_ipcomp.c,v
> retrieving revision 1.76
> diff -u -p -r1.76 ip_ipcomp.c
> --- netinet/ip_ipcomp.c   13 Oct 2021 22:43:44 -  1.76
> +++ netinet/ip_ipcomp.c   21 Oct 2021 21:50:32 -
> @@ -174,7 +174,7 @@ ipcomp_input(struct mbuf *m, struct tdb 
>  
>   /* Crypto operation descriptor */
>   crp->crp_ilen = m->m_pkthdr.len - (skip + hlen);
> - crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE | CRYPTO_F_NOQUEUE;
> + crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE;
>   crp->crp_buf = (caddr_t)m;
>   crp->crp_callback = ipsec_input_cb;
>   crp->crp_sid = tdb->tdb_cryptoid;
> @@ -476,7 +476,7 @@ ipcomp_output(struct mbuf *m, struct tdb
>  
>   /* Crypto operation descriptor */
>   crp->crp_ilen = m->m_pkthdr.len;/* Total input length */
> - crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE | CRYPTO_F_NOQUEUE;
> + crp->crp_flags = CRYPTO_F_IMBUF | CRYPTO_F_MPSAFE;
>   crp->crp_buf = (caddr_t)m;
>   crp->crp_callback = ipsec_output_cb;
>   crp->crp_opaque = (caddr_t)tc;
> Index: crypto/crypto.c
> ===
> RCS file: /cvs/src/sys/crypto/crypto.c,v
> retrieving revision 1.87
> diff -u -p -r1.87 crypto.c
> --- 

agintc(4): initialize IGROUP (tests required on RK3399 like RockPro64 or Pinebook Pro)

[Patrick Wildt]

Hi,

This diff is one of two steps in getting Parallels on Apple M1s to work.
It initializes two registers to configure the interrupts as GNS1.

It works fine on the Ampere machine that I have access to, but it would
be very nice if someone can give this a try on an RK3399 machine like
the Pinebook Pro or the RockPro64.

Expected outcome: Machines continue to boot up and work like before.

Thanks,
Patrick

diff --git a/sys/arch/arm64/dev/agintc.c b/sys/arch/arm64/dev/agintc.c
index fde4167ce72..4515a867b44 100644
--- a/sys/arch/arm64/dev/agintc.c
+++ b/sys/arch/arm64/dev/agintc.c
@@ -73,6 +73,7 @@
 #define  GICD_TYPER_LPIS   (1 << 17)
 #define  GICD_TYPER_ITLINE_M   0x1f
 #define GICD_IIDR  0x0008
+#define GICD_IGROUPR(i)(0x0080 + (IRQ_TO_REG32(i) * 4))
 #define GICD_ISENABLER(i)  (0x0100 + (IRQ_TO_REG32(i) * 4))
 #define GICD_ICENABLER(i)  (0x0180 + (IRQ_TO_REG32(i) * 4))
 #define GICD_ISPENDR(i)(0x0200 + (IRQ_TO_REG32(i) * 4))
@@ -84,6 +85,7 @@
 #define  GICD_ICFGR_TRIG_LEVEL(i)  (0x0 << (IRQ_TO_REG16BIT(i) * 2))
 #define  GICD_ICFGR_TRIG_EDGE(i)   (0x2 << (IRQ_TO_REG16BIT(i) * 2))
 #define  GICD_ICFGR_TRIG_MASK(i)   (0x2 << (IRQ_TO_REG16BIT(i) * 2))
+#define GICD_IGRPMODR(i)   (0x0d00 + (IRQ_TO_REG32(i) * 4))
 #define GICD_NSACR(i)  (0x0e00 + (IRQ_TO_REG16(i) * 4))
 #define GICD_IROUTER(i)(0x6000 + ((i) * 8))
 
@@ -107,7 +109,7 @@
 #define  GICR_PENDBASER_PTZ(1ULL << 62)
 #define  GICR_PENDBASER_ISH(1ULL << 10)
 #define  GICR_PENDBASER_IC_NORM_NC (1ULL << 7)
-#define GICR_IGROUP0   0x10080
+#define GICR_IGROUPR0  0x10080
 #define GICR_ISENABLE0 0x10100
 #define GICR_ICENABLE0 0x10180
 #define GICR_ISPENDR0  0x10200
@@ -117,6 +119,7 @@
 #define GICR_IPRIORITYR(i) (0x10400 + (i))
 #define GICR_ICFGR00x10c00
 #define GICR_ICFGR10x10c04
+#define GICR_IGRPMODR0 0x10d00
 
 #define GICR_PROP_SIZE (64 * 1024)
 #define  GICR_PROP_GROUP1  (1 << 1)
@@ -492,6 +495,14 @@ agintc_attach(struct device *parent, struct device *self, 
void *aux)
GICD_IPRIORITYR(i), 0x);
}
 
+   /* Set all interrupts to G1NS */
+   for (i = 1; i < nintr / 32; i++) {
+   bus_space_write_4(sc->sc_iot, sc->sc_d_ioh,
+   GICD_IGROUPR(i * 32), ~0);
+   bus_space_write_4(sc->sc_iot, sc->sc_d_ioh,
+   GICD_IGRPMODR(i * 32), 0);
+   }
+
for (i = 2; i < nintr / 16; i++) {
/* irq 32 - N */
bus_space_write_4(sc->sc_iot, sc->sc_d_ioh,
@@ -664,7 +675,11 @@ agintc_cpuinit(void)
bus_space_write_4(sc->sc_iot, sc->sc_r_ioh[hwcpu],
GICR_IPRIORITYR(i), ~0);
}
-   
+   bus_space_write_4(sc->sc_iot, sc->sc_r_ioh[hwcpu],
+   GICR_IGROUPR0, ~0);
+   bus_space_write_4(sc->sc_iot, sc->sc_r_ioh[hwcpu],
+   GICR_IGRPMODR0, 0);
+
if (sc->sc_ipi_irq[0] != NULL)
agintc_route_irq(sc->sc_ipi_irq[0], IRQ_ENABLE, curcpu());
if (sc->sc_ipi_irq[1] != NULL)

Re: Handle openbsd,dma-constraint on armv7

[Patrick Wildt]

Am Mon, Oct 04, 2021 at 01:42:48PM + schrieb Visa Hankala:
> On the Zynq-7000, the lowest 512KiB of physical address space usually
> contains RAM that is usable by the CPUs. However, many other bus
> masters, such as the Ethernet and SDIO controllers, are not able to
> access the 256KiB range that starts at physical address 0x4.
> 
> So far I have used a device tree that says that RAM starts at 0x8,
> to avoid the DMA hole. This is unconventional, though. Typically the
> memory node for Zynq-7000 specifies 0x0 as the starting address for RAM.
> 
> I think armv7 DMA constraint should be adjusted on the Zynq-7000 so that
> less device tree customization would be needed.
> 
> This diff makes armv7 efiboot and kernel handle the
> openbsd,dma-constraint device tree property, with a tweak for the Zynq.
> The code is similar to what is already present on arm64 and riscv64.
> 
> OK?

Heh, I just saw that the dma constraint range is paddr_t, so on ARMv7
it's 32-bit values.  Hence it makes sense that you're not using sizeof(
dma_constraint).

Using the same size in the openbsd,dma-constrant API as arm64 does make
sense to me, so while it might looks less nice than on arm64, I feel it
is the sane way.

Might want to see if kettenis agrees, since he built it, but otherwise
ok patrick@.

> Index: arch/armv7/armv7/armv7_machdep.c
> ===
> RCS file: src/sys/arch/armv7/armv7/armv7_machdep.c,v
> retrieving revision 1.63
> diff -u -p -r1.63 armv7_machdep.c
> --- arch/armv7/armv7/armv7_machdep.c  25 Mar 2021 04:12:01 -  1.63
> +++ arch/armv7/armv7/armv7_machdep.c  4 Oct 2021 13:32:11 -
> @@ -453,6 +453,12 @@ initarm(void *arg0, void *arg1, void *ar
>   len = fdt_node_property(node, "openbsd,uefi-mmap-desc-ver", 
> );
>   if (len == sizeof(mmap_desc_ver))
>   mmap_desc_ver = bemtoh32((uint32_t *)prop);
> +
> + len = fdt_node_property(node, "openbsd,dma-constraint", );
> + if (len == sizeof(uint64_t[2])) {
> + dma_constraint.ucr_low = bemtoh64((uint64_t *)prop);
> + dma_constraint.ucr_high = bemtoh64((uint64_t *)prop + 
> 1);
> + }
>   }
>  
>   process_kernel_args();
> Index: arch/armv7/stand/efiboot/conf.c
> ===
> RCS file: src/sys/arch/armv7/stand/efiboot/conf.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 conf.c
> --- arch/armv7/stand/efiboot/conf.c   10 Jun 2021 22:17:58 -  1.31
> +++ arch/armv7/stand/efiboot/conf.c   4 Oct 2021 13:32:11 -
> @@ -42,7 +42,7 @@
>  #include "efidev.h"
>  #include "efipxe.h"
>  
> -const char version[] = "1.18";
> +const char version[] = "1.19";
>  int  debug = 0;
>  
>  struct fs_ops file_system[] = {
> Index: arch/armv7/stand/efiboot/efiboot.c
> ===
> RCS file: src/sys/arch/armv7/stand/efiboot/efiboot.c,v
> retrieving revision 1.34
> diff -u -p -r1.34 efiboot.c
> --- arch/armv7/stand/efiboot/efiboot.c7 Jun 2021 21:18:31 -   
> 1.34
> +++ arch/armv7/stand/efiboot/efiboot.c4 Oct 2021 13:32:11 -
> @@ -435,6 +435,28 @@ efi_framebuffer(void)
>   sizeof(framebuffer_path));
>  }
>  
> +uint64_t dma_constraint[2] = { 0, -1 };
> +
> +void
> +efi_dma_constraint(void)
> +{
> + void *node;
> +
> + /* Raspberry Pi 4 is "special". */
> + node = fdt_find_node("/");
> + if (fdt_node_is_compatible(node, "brcm,bcm2711"))
> + dma_constraint[1] = htobe64(0x3bff);
> +
> + /* Not all bus masters can access 0x4-0x7 on Zynq-7000. */
> + if (fdt_node_is_compatible(node, "xlnx,zynq-7000"))
> + dma_constraint[0] = htobe64(0x0008);
> +
> + /* Pass DMA constraint. */
> + node = fdt_find_node("/chosen");
> + fdt_node_add_property(node, "openbsd,dma-constraint",
> + dma_constraint, sizeof(dma_constraint));
> +}
> +
>  void
>  efi_console(void)
>  {
> @@ -515,6 +537,7 @@ efi_makebootargs(char *bootargs, int how
>  
>   efi_framebuffer();
>   efi_console();
> + efi_dma_constraint();
>  
>   fdt_finalize();
>  
> 

avoid sched lock recursion in sleep_signal_check()

[Patrick Wildt]

Hi,

one step to (at some point) change the sched lock to a mutex is to start
avoiding recursion on the sched lock.

single_thread_check() always takes the sched lock.  If we want to avoid
recursion, we need to call the locked version and take the sched lock
ourselves if we need to.

Another option might be to just put SCHED_LOCK()/SCHED_UNLOCK() around
call to sleep_signal_check(), but then this might end up in future
confusion if we ever wonder why we are taking the lock there in the
first place.

Opinions?

Patrick

diff --git a/sys/kern/kern_synch.c b/sys/kern/kern_synch.c
index b476a6b4253..030b3a38326 100644
--- a/sys/kern/kern_synch.c
+++ b/sys/kern/kern_synch.c
@@ -66,6 +66,7 @@
 #endif
 
 intsleep_signal_check(void);
+intsleep_signal_check_locked(int s);
 intthrsleep(struct proc *, struct sys___thrsleep_args *);
 intthrsleep_unlock(void *);
 
@@ -410,7 +411,7 @@ sleep_finish(struct sleep_state *sls, int do_sleep)
 * that case we need to unwind immediately.
 */
atomic_setbits_int(>p_flag, P_SINTR);
-   if ((error = sleep_signal_check()) != 0) {
+   if ((error = sleep_signal_check_locked(sls->sls_s)) != 0) {
p->p_stat = SONPROC;
sls->sls_catch = 0;
do_sleep = 0;
@@ -470,14 +471,30 @@ sleep_finish(struct sleep_state *sls, int do_sleep)
 
 /*
  * Check and handle signals and suspensions around a sleep cycle.
+ *
+ * single_thread_check() always takes the sched lock.  To avoid
+ * recursion on the sched lock, call the locked version and take
+ * it ourselves if we need to.
  */
 int
 sleep_signal_check(void)
+{
+   int err, s;
+
+   SCHED_LOCK(s);
+   err = sleep_signal_check_locked(s);
+   SCHED_UNLOCK(s);
+
+   return err;
+}
+
+int
+sleep_signal_check_locked(int s)
 {
struct proc *p = curproc;
int err, sig;
 
-   if ((err = single_thread_check(p, 1)) != 0)
+   if ((err = single_thread_check_locked(p, 1, s)) != 0)
return err;
if ((sig = cursig(p)) != 0) {
if (p->p_p->ps_sigacts->ps_sigintr & sigmask(sig))
diff --git a/sys/sys/proc.h b/sys/sys/proc.h
index 4dbc097f242..978fd5632cd 100644
--- a/sys/sys/proc.h
+++ b/sys/sys/proc.h
@@ -605,6 +605,7 @@ int single_thread_set(struct proc *, enum 
single_thread_mode, int);
 intsingle_thread_wait(struct process *, int);
 void   single_thread_clear(struct proc *, int);
 intsingle_thread_check(struct proc *, int);
+intsingle_thread_check_locked(struct proc *, int, int);
 
 void   child_return(void *);
 

Re: [please test] amd64: schedule clock interrupts against system clock

[Patrick Wildt]

Am Thu, Sep 09, 2021 at 04:10:31PM +0200 schrieb Mark Kettenis:
> > Date: Mon, 6 Sep 2021 21:43:29 +0200
> > From: Patrick Wildt 
> > 
> > Am Fri, Jul 30, 2021 at 07:55:29PM +0200 schrieb Alexander Bluhm:
> > > On Mon, Jul 26, 2021 at 08:12:39AM -0500, Scott Cheloha wrote:
> > > > On Fri, Jun 25, 2021 at 06:09:27PM -0500, Scott Cheloha wrote:
> > > > 1 month bump.  I really appreciate the tests I've gotten so far, thank
> > > > you.
> > > 
> > > On my Xeon machine it works and all regress tests pass.
> > > 
> > > But it fails on my old Opteron machine.  It hangs after attaching
> > > cpu1.
> > 
> > This seems to be caused by contention on the mutex in i8254's gettick().
> > 
> > With Scott's diff, delay_func is i8254_delay() on that old AMD machine.
> > Its gettick() implementation uses a mutex to protect I/O access to the
> > i8254.
> > 
> > When secondary CPUs come up, they will wait for CPU0 to let them boot up
> > further by checking for a flag:
> > 
> > /*
> >  * We need to wait until we can identify, otherwise dmesg
> >  * output will be messy.
> >  */
> > while ((ci->ci_flags & CPUF_IDENTIFY) == 0)
> > delay(10);
> > 
> > Now that machine has 3 secondary cores that are spinning like that.  At
> > the same time CPU0 waits for the core to come up:
> > 
> > /* wait for it to identify */
> > for (i = 200; (ci->ci_flags & CPUF_IDENTIFY) && i > 0; i--)
> > delay(10);
> > 
> > That means we have 3-4 cores spinning just to be able to delay().  Our
> > mutex implementation isn't fair, which means whoever manages to claim
> > the free mutex wins.  Now if CPU2 and CPU3 are spinning all the time,
> > CPU1 identifies and needs delay() and CPU0 waits for CPU1, maybe the
> > one that needs to make progress never gets it.
> > 
> > I changed those delay(10) in cpu_hatch() to CPU_BUSY_CYCLE() and it went
> > ahead a bit better instead of hanging forever.
> > 
> > Then I remembered an idea something from years ago: fair kernel mutexes,
> > so basically mutexes implemented as ticket lock, like our kerne lock.
> > 
> > I did a quick diff, which probably contains a million bugs, but with
> > this bluhm's machine boots up well.
> > 
> > I'm not saying this is the solution, but it might be.
> 
> So the idea really is that the kernel mutexes are cheap and simple
> spin locks.  The assumption has always been that there shouldn't be a
> lot of contention on them.  If you have contention, your locking
> probably isn't fine-grained enough, or you're using the wrong lock
> type.  Note that our mpsafe pmaps use a per-page mutex.  So increasing
> the size of struct mutex is going to have a significant impact.
> 
> Maybe we need another lock type, although we already have one that
> tries to be "fair": struct __mp_lock, which is what we use for the
> kernel lock and the scheduler lock.  A non-recursive version of that
> might make sense.

After further testing I have come to the conclusion that changing
our mutexes to become a ticket lock is a flawed concept.  There are
lock order issues with the kernel lock caused by the spinning path
to be interruptible with code that can take the kernel lock.

CPU0: has the mutex, will soon release it
CPU1: gets the next ticket, spins on the mutex, gets an IRQ that tries
  to take the kernel lock
CPU2: has the kernel lock, tries to get the mutex, gets the ticket after
  CPU1, spins on the mutex

So now CPU2 is waiting for CPU1 to be done with the mutex, but since
CPU1 is waiting for CPU2 to be done with the kernel lock, we're stuck.

As long as a mutex can be interrupted by stuff that takes the kernel
lock, this concept won't work.

Back to the original problem: contention on the i2854_delay lock.

Changing it to an mp lock could work, because then it would be fair.
Does it need to be fair?  If we reduce the contention, there's no need
to change the lock.

So there are two things one could have a look at.  First, make use of
CPU_BUSY_CYCLE() instead of delay(10) when spinning up cores.  Second,
try to not use i8254_delay as delay_func.

Patrick

Re: Turn SCHED_LOCK() into a mutex

[Patrick Wildt]

Am Wed, Nov 04, 2020 at 09:13:22AM -0300 schrieb Martin Pieuchot:
> Diff below removes the recursive attribute of the SCHED_LOCK() by
> turning it into a IPL_NONE mutex.  I'm not intending to commit it
> yet as it raises multiple questions, see below. 
> 
> This work has been started by art@ more than a decade ago and I'm
> willing to finish it as I believe it's the easiest way to reduce
> the scope of this lock.  Having a global mutex is the first step to
> have a per runqueue and per sleepqueue mutex. 
> 
> This is also a way to avoid lock ordering problems exposed by the recent
> races in single_thread_set().
> 
> About the diff:
> 
>  The diff below includes a (hugly) refactoring of rw_exit() to avoid a
>  recursion on the SCHED_LOCK().  In this case the lock is used to protect
>  the global sleepqueue and is grabbed in sleep_setup().
> 
>  The same pattern can be observed in single_thread_check().  However in
>  this case the lock is used to protect different fields so there's no
>  "recursive access" to the same data structure.
> 
>  assertwaitok() has been moved down in mi_switch() which isn't ideal.
> 
>  It becomes obvious that the per-CPU and per-thread accounting fields
>  updated in mi_switch() won't need a separate mutex as proposed last
>  year and that splitting this global mutex will be enough.
> 
> It's unclear to me if/how WITNESS should be modified to handle this lock
> change.
> 
> This has been tested on sparc64 and amd64.  I'm not convinced it exposed
> all the recursions.  So if you want to give it a go and can break it, it
> is more than welcome.
> 
> Comments?  Questions?

I think that's a good direction.  This then allows us to add a few
smaller mutexes and move some users to those.

In the meantime apparently some stuff has changed a little bit.  I had
to fix one reject, which was very easy because only the context around
the diff changed a tiny bit.

I then found one schedlock recursion:

single_thread_check() takes the sched lock, which we call through
sleep_signal_check().  We do the call twice, one time with the sched
lock, and one time without.  My 'quick' fix is to introduce a locked
version that calls single_thread_check_locked().  There might be
a nicer way to do that, which I don't know yet, but this diff seems
to work fine on my arm64 machine with amdgpu.

Build times increase a little, which might be because mutexes are
not 'fair' like mplocks.  If we are looking for 'instant gratification'
we might have to do two steps at once (mplock -> mtx + move contention
to multiple mtxs).  In any case, I believe this is a good step to go
and I'll have a look at reducing the contention.

Patrick

diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c
index 1e51f71301a..4e4e1fc2a27 100644
--- a/sys/kern/kern_fork.c
+++ b/sys/kern/kern_fork.c
@@ -671,7 +671,7 @@ void
 proc_trampoline_mp(void)
 {
SCHED_ASSERT_LOCKED();
-   __mp_unlock(_lock);
+   mtx_leave(_lock);
spl0();
SCHED_ASSERT_UNLOCKED();
KERNEL_ASSERT_UNLOCKED();
diff --git a/sys/kern/kern_lock.c b/sys/kern/kern_lock.c
index 5cc55bb256a..2206ac53321 100644
--- a/sys/kern/kern_lock.c
+++ b/sys/kern/kern_lock.c
@@ -97,9 +97,6 @@ ___mp_lock_init(struct __mp_lock *mpl, const struct lock_type 
*type)
if (mpl == _lock)
mpl->mpl_lock_obj.lo_flags = LO_WITNESS | LO_INITIALIZED |
LO_SLEEPABLE | (LO_CLASS_KERNEL_LOCK << LO_CLASSSHIFT);
-   else if (mpl == _lock)
-   mpl->mpl_lock_obj.lo_flags = LO_WITNESS | LO_INITIALIZED |
-   LO_RECURSABLE | (LO_CLASS_SCHED_LOCK << LO_CLASSSHIFT);
WITNESS_INIT(>mpl_lock_obj, type);
 #endif
 }
diff --git a/sys/kern/kern_rwlock.c b/sys/kern/kern_rwlock.c
index d79b59748e8..2feeff16943 100644
--- a/sys/kern/kern_rwlock.c
+++ b/sys/kern/kern_rwlock.c
@@ -129,36 +129,6 @@ rw_enter_write(struct rwlock *rwl)
}
 }
 
-void
-rw_exit_read(struct rwlock *rwl)
-{
-   unsigned long owner;
-
-   rw_assert_rdlock(rwl);
-   WITNESS_UNLOCK(>rwl_lock_obj, 0);
-
-   membar_exit_before_atomic();
-   owner = rwl->rwl_owner;
-   if (__predict_false((owner & RWLOCK_WAIT) ||
-   rw_cas(>rwl_owner, owner, owner - RWLOCK_READ_INCR)))
-   rw_do_exit(rwl, 0);
-}
-
-void
-rw_exit_write(struct rwlock *rwl)
-{
-   unsigned long owner;
-
-   rw_assert_wrlock(rwl);
-   WITNESS_UNLOCK(>rwl_lock_obj, LOP_EXCLUSIVE);
-
-   membar_exit_before_atomic();
-   owner = rwl->rwl_owner;
-   if (__predict_false((owner & RWLOCK_WAIT) ||
-   rw_cas(>rwl_owner, owner, 0)))
-   rw_do_exit(rwl, RWLOCK_WRLOCK);
-}
-
 #ifdef DIAGNOSTIC
 /*
  * Put the diagnostic functions here to keep the main code free
@@ -313,9 +283,10 @@ retry:
 }
 
 void
-rw_exit(struct rwlock *rwl)
+_rw_exit(struct rwlock *rwl, int locked)
 {
unsigned long wrlock;
+   unsigned long owner, set;
 
/* Avoid deadlocks after panic or in DDB */
  

Re: mutex(9): initialize some more mutexes before use?

[Patrick Wildt]

Am Thu, Sep 09, 2021 at 12:55:13PM +0200 schrieb Mark Kettenis:
> > Date: Wed, 8 Sep 2021 10:45:53 +0200
> > From: Martin Pieuchot 
> > 
> > On 07/09/21(Tue) 14:19, Patrick Wildt wrote:
> > > Hi,
> > > 
> > > I was playing around a little with the mutex code and found that on
> > > arm64 there some uninitialized mutexes out there.
> > > 
> > > I think the arm64 specific one is comparatively easy to solve.  We
> > > either initialize the mtx when we initialize the rest of the pmap, or
> > > we move it into the global definition of those.  I opted for the former
> > > version.
> > 
> > Is the kernel pmap mutex supposed to be used?  On i386 it isn't so the
> > mutex's IPL is set to -1 and we added a KASSERT() in splraise() to spot
> > any mistake.
> 
> Indeed.  The kernel pmap is special:
> 
> * It can never disappear.
> 
> * Page table pages are pre-allocated and are never freed.
> 
> * Mappings are (largely) unmanaged (by uvm).
> 
> Therefore the per-pmap lock isn't used for the kernel map on most
> (all?) architectures.

The one that 'crashed' was pmap_tramp.  I only changed the kernel pmap
because it was like 5 lines above (or below) and seemed to be missing it
as well.

> > > The other one prolly needs more discussion/debugging.  So uvm_init()
> > > calls first pmap_init() and then uvm_km_page_init().  The latter does
> > > initialize the mutex, but arm64's pmap_init() already uses pools, which
> > > uses km_alloc, which then uses that mutex.  Now one easy fix would be
> > > to just initialize the definition right away instead of during runtime.
> > > 
> > > But there might be the question if arm64's pmap is allowed to use pools
> > > and km_alloc during pmap_init.
> > 
> > That's a common question for the family of pmaps calling pool_setlowat()
> > in pmap_init().  That's where pool_prime() is called from.
> > 
> > > #0  0xff800073f984 in mtx_enter (mtx=0xff8000f3b048 
> > > ) at /usr/src/sys/kern/kern_lock.c:281
> > > #1  0xff8000937e6c in km_alloc (sz= > > dwarf expression opcode 0xa3>, kv=0xff8000da6a30 , 
> > > kp=0xff8000da6a48 , kd=0xff8000e934d8)
> > > at /usr/src/sys/uvm/uvm_km.c:899
> > > #2  0xff800084d804 in pool_page_alloc (pp= > > Unhandled dwarf expression opcode 0xa3>, flags= > > Unhandled dwarf expression opcode 0xa3>,
> > > slowdown= > > 0xa3>) at /usr/src/sys/kern/subr_pool.c:1633
> > > #3  0xff800084f8dc in pool_allocator_alloc (pp=0xff8000ea6e40 
> > > , flags=65792, slowdown=0xff80026cd098) at 
> > > /usr/src/sys/kern/subr_pool.c:1602
> > > #4  0xff800084ef08 in pool_p_alloc (pp=0xff8000ea6e40 
> > > , flags=2, slowdown=0xff8000e9359c) at 
> > > /usr/src/sys/kern/subr_pool.c:926
> > > #5  0xff800084f808 in pool_prime (pp=, n= > > reading variable: Unhandled dwarf expression opcode 0xa3>) at 
> > > /usr/src/sys/kern/subr_pool.c:896
> > > #6  0xff800048c20c in pmap_init () at 
> > > /usr/src/sys/arch/arm64/arm64/pmap.c:1682
> > > #7  0xff80009384dc in uvm_init () at /usr/src/sys/uvm/uvm_init.c:118
> > > #8  0xff800048e664 in main (framep= > > dwarf expression opcode 0xa3>) at /usr/src/sys/kern/init_main.c:235
> > > 
> > > diff --git a/sys/arch/arm64/arm64/pmap.c b/sys/arch/arm64/arm64/pmap.c
> > > index 79a344cc84e..f070f4540ec 100644
> > > --- a/sys/arch/arm64/arm64/pmap.c
> > > +++ b/sys/arch/arm64/arm64/pmap.c
> > > @@ -1308,10 +1308,12 @@ pmap_bootstrap(long kvo, paddr_t lpt1, long 
> > > kernelstart, long kernelend,
> > >   pmap_kernel()->pm_vp.l1 = (struct pmapvp1 *)va;
> > >   pmap_kernel()->pm_privileged = 1;
> > >   pmap_kernel()->pm_asid = 0;
> > > + mtx_init(_kernel()->pm_mtx, IPL_VM);
> > >  
> > >   pmap_tramp.pm_vp.l1 = (struct pmapvp1 *)va + 1;
> > >   pmap_tramp.pm_privileged = 1;
> > >   pmap_tramp.pm_asid = 0;
> > > + mtx_init(_tramp.pm_mtx, IPL_VM);
> > >  
> > >   /* Mark ASID 0 as in-use. */
> > >   pmap_asid[0] |= (3U << 0);
> > > diff --git a/sys/uvm/uvm_km.c b/sys/uvm/uvm_km.c
> > > index 4a60377e9d7..e77afeda832 100644
> > > --- a/sys/uvm/uvm_km.c
> > > +++ b/sys/uvm/uvm_km.c
> > > @@ -644,7 +644,7 @@ uvm_km_page_lateinit(void)
> > >   * not zero filled.
> > >   */
> > >  
> > > -struct uvm_km_pages uvm_km_pages;
> > > +struct uvm_km_pages uvm_km_pages = { .mtx = MUTEX_INITIALIZER(IPL_VM) };
> > >  
> > >  void uvm_km_createthread(void *);
> > >  void uvm_km_thread(void *);
> > > @@ -664,7 +664,6 @@ uvm_km_page_init(void)
> > >   int len, bulk;
> > >   vaddr_t addr;
> > >  
> > > - mtx_init(_km_pages.mtx, IPL_VM);
> > >   if (!uvm_km_pages.lowat) {
> > >   /* based on physmem, calculate a good value here */
> > >   uvm_km_pages.lowat = physmem / 256;
> > > 
> > 
> > 
> 

Re: [please test] amd64: schedule clock interrupts against system clock

[Patrick Wildt]

Am Tue, Sep 07, 2021 at 09:52:42PM +0200 schrieb Martin Pieuchot:
> On 07/09/21(Tue) 21:47, Patrick Wildt wrote:
> > Am Tue, Sep 07, 2021 at 02:43:22PM +0200 schrieb Patrick Wildt:
> > > Am Mon, Sep 06, 2021 at 09:43:29PM +0200 schrieb Patrick Wildt:
> > > > Am Fri, Jul 30, 2021 at 07:55:29PM +0200 schrieb Alexander Bluhm:
> > > > > On Mon, Jul 26, 2021 at 08:12:39AM -0500, Scott Cheloha wrote:
> > > > > > On Fri, Jun 25, 2021 at 06:09:27PM -0500, Scott Cheloha wrote:
> > > > > > 1 month bump.  I really appreciate the tests I've gotten so far, 
> > > > > > thank
> > > > > > you.
> > > > > 
> > > > > On my Xeon machine it works and all regress tests pass.
> > > > > 
> > > > > But it fails on my old Opteron machine.  It hangs after attaching
> > > > > cpu1.
> > > > 
> > > > This seems to be caused by contention on the mutex in i8254's gettick().
> > > > 
> > > > With Scott's diff, delay_func is i8254_delay() on that old AMD machine.
> > > > Its gettick() implementation uses a mutex to protect I/O access to the
> > > > i8254.
> > > > 
> > > > When secondary CPUs come up, they will wait for CPU0 to let them boot up
> > > > further by checking for a flag:
> > > > 
> > > > /*
> > > >  * We need to wait until we can identify, otherwise dmesg
> > > >  * output will be messy.
> > > >  */
> > > > while ((ci->ci_flags & CPUF_IDENTIFY) == 0)
> > > > delay(10);
> > > > 
> > > > Now that machine has 3 secondary cores that are spinning like that.  At
> > > > the same time CPU0 waits for the core to come up:
> > > > 
> > > > /* wait for it to identify */
> > > > for (i = 200; (ci->ci_flags & CPUF_IDENTIFY) && i > 0; i--)
> > > > delay(10);
> > > > 
> > > > That means we have 3-4 cores spinning just to be able to delay().  Our
> > > > mutex implementation isn't fair, which means whoever manages to claim
> > > > the free mutex wins.  Now if CPU2 and CPU3 are spinning all the time,
> > > > CPU1 identifies and needs delay() and CPU0 waits for CPU1, maybe the
> > > > one that needs to make progress never gets it.
> > > > 
> > > > I changed those delay(10) in cpu_hatch() to CPU_BUSY_CYCLE() and it went
> > > > ahead a bit better instead of hanging forever.
> > > > 
> > > > Then I remembered an idea something from years ago: fair kernel mutexes,
> > > > so basically mutexes implemented as ticket lock, like our kerne lock.
> > > > 
> > > > I did a quick diff, which probably contains a million bugs, but with
> > > > this bluhm's machine boots up well.
> > > > 
> > > > I'm not saying this is the solution, but it might be.
> > > > 
> > > > Patrick
> > > 
> > > Cleaned the diff up a little, changes since last time:
> > > 
> > > * Rename the struct members to be the same as mplock.
> > > * Change the code to use ticket/user numbers like mplock.  This
> > >   has one obvious downside: If a mutex is not initialized, trying
> > >   to get this mutex will result in a hang.  At least that just let
> > >   me find some uninitialized mutexes.
> > > * More consistent use of the 'ci' variable.
> > > * Definitely compiles with/without DIAGNOSTIC.
> > > * Made sure mtx_enter() still has the membar.
> > > * No need for READ_ONCE() when members are volatile.
> > > 
> > > Apart from being fair, this diff also changes the behaviour while
> > > spinning for a lock.  Previously mtx_enter called mtx_enter_try
> > > in a loop until it got the lock.  mtx_enter_try does splraise,
> > > try lock, splx.  This diff currently spins with the SPL raised,
> > > so that's a change in behaviour.  I'm sure I can change the diff
> > > to splraise/splx while looping, if we prefer that behaviour.
> > > 
> > > Patrick
> 
> This change makes sense on its own as the contention is switching away
> from KERNEL_LOCK() to mutexes.
> 
> Note that hppa has its own mutex implementation in case somebody wants
> to keep in sync.
>  
> > make -j17 seems to have used less system time, so that seemed to have
> > made the machine slightly faster:
> > 
> > old: make -j17  1160.01s user 3244.58s system 1288% cpu 5:41.96 total
> > new: make -j17  1171.80s user 3059.67s system 1295% cpu 5:26.65 total
> 
> Is it with -current or with the UVM unlocking diff that put more
> pressure on mutxes?

It's with the UVM unlocking diff that put more pressure on mutexes.

> > I'll change the diff to do splraise/splx while looping, to make the
> > behaviour more similar to before, and then re-do my testing.
> 
> That'd be nice.  You could also start a new thread to get attention of
> more people, maybe dlg@, visa@ or kettenis@ have an opinion on this.

You can read my mind. :)

Re: [please test] amd64: schedule clock interrupts against system clock

[Patrick Wildt]

Am Tue, Sep 07, 2021 at 02:43:22PM +0200 schrieb Patrick Wildt:
> Am Mon, Sep 06, 2021 at 09:43:29PM +0200 schrieb Patrick Wildt:
> > Am Fri, Jul 30, 2021 at 07:55:29PM +0200 schrieb Alexander Bluhm:
> > > On Mon, Jul 26, 2021 at 08:12:39AM -0500, Scott Cheloha wrote:
> > > > On Fri, Jun 25, 2021 at 06:09:27PM -0500, Scott Cheloha wrote:
> > > > 1 month bump.  I really appreciate the tests I've gotten so far, thank
> > > > you.
> > > 
> > > On my Xeon machine it works and all regress tests pass.
> > > 
> > > But it fails on my old Opteron machine.  It hangs after attaching
> > > cpu1.
> > 
> > This seems to be caused by contention on the mutex in i8254's gettick().
> > 
> > With Scott's diff, delay_func is i8254_delay() on that old AMD machine.
> > Its gettick() implementation uses a mutex to protect I/O access to the
> > i8254.
> > 
> > When secondary CPUs come up, they will wait for CPU0 to let them boot up
> > further by checking for a flag:
> > 
> > /*
> >  * We need to wait until we can identify, otherwise dmesg
> >  * output will be messy.
> >  */
> > while ((ci->ci_flags & CPUF_IDENTIFY) == 0)
> > delay(10);
> > 
> > Now that machine has 3 secondary cores that are spinning like that.  At
> > the same time CPU0 waits for the core to come up:
> > 
> > /* wait for it to identify */
> > for (i = 200; (ci->ci_flags & CPUF_IDENTIFY) && i > 0; i--)
> > delay(10);
> > 
> > That means we have 3-4 cores spinning just to be able to delay().  Our
> > mutex implementation isn't fair, which means whoever manages to claim
> > the free mutex wins.  Now if CPU2 and CPU3 are spinning all the time,
> > CPU1 identifies and needs delay() and CPU0 waits for CPU1, maybe the
> > one that needs to make progress never gets it.
> > 
> > I changed those delay(10) in cpu_hatch() to CPU_BUSY_CYCLE() and it went
> > ahead a bit better instead of hanging forever.
> > 
> > Then I remembered an idea something from years ago: fair kernel mutexes,
> > so basically mutexes implemented as ticket lock, like our kerne lock.
> > 
> > I did a quick diff, which probably contains a million bugs, but with
> > this bluhm's machine boots up well.
> > 
> > I'm not saying this is the solution, but it might be.
> > 
> > Patrick
> 
> Cleaned the diff up a little, changes since last time:
> 
> * Rename the struct members to be the same as mplock.
> * Change the code to use ticket/user numbers like mplock.  This
>   has one obvious downside: If a mutex is not initialized, trying
>   to get this mutex will result in a hang.  At least that just let
>   me find some uninitialized mutexes.
> * More consistent use of the 'ci' variable.
> * Definitely compiles with/without DIAGNOSTIC.
> * Made sure mtx_enter() still has the membar.
> * No need for READ_ONCE() when members are volatile.
> 
> Apart from being fair, this diff also changes the behaviour while
> spinning for a lock.  Previously mtx_enter called mtx_enter_try
> in a loop until it got the lock.  mtx_enter_try does splraise,
> try lock, splx.  This diff currently spins with the SPL raised,
> so that's a change in behaviour.  I'm sure I can change the diff
> to splraise/splx while looping, if we prefer that behaviour.
> 
> Patrick

make -j17 seems to have used less system time, so that seemed to have
made the machine slightly faster:

old: make -j17  1160.01s user 3244.58s system 1288% cpu 5:41.96 total
new: make -j17  1171.80s user 3059.67s system 1295% cpu 5:26.65 total

I'll change the diff to do splraise/splx while looping, to make the
behaviour more similar to before, and then re-do my testing.

Patrick

Re: [please test] amd64: schedule clock interrupts against system clock

[Patrick Wildt]

Am Mon, Sep 06, 2021 at 09:43:29PM +0200 schrieb Patrick Wildt:
> Am Fri, Jul 30, 2021 at 07:55:29PM +0200 schrieb Alexander Bluhm:
> > On Mon, Jul 26, 2021 at 08:12:39AM -0500, Scott Cheloha wrote:
> > > On Fri, Jun 25, 2021 at 06:09:27PM -0500, Scott Cheloha wrote:
> > > 1 month bump.  I really appreciate the tests I've gotten so far, thank
> > > you.
> > 
> > On my Xeon machine it works and all regress tests pass.
> > 
> > But it fails on my old Opteron machine.  It hangs after attaching
> > cpu1.
> 
> This seems to be caused by contention on the mutex in i8254's gettick().
> 
> With Scott's diff, delay_func is i8254_delay() on that old AMD machine.
> Its gettick() implementation uses a mutex to protect I/O access to the
> i8254.
> 
> When secondary CPUs come up, they will wait for CPU0 to let them boot up
> further by checking for a flag:
> 
>   /*
>* We need to wait until we can identify, otherwise dmesg
>* output will be messy.
>*/
>   while ((ci->ci_flags & CPUF_IDENTIFY) == 0)
>   delay(10);
> 
> Now that machine has 3 secondary cores that are spinning like that.  At
> the same time CPU0 waits for the core to come up:
> 
>   /* wait for it to identify */
>   for (i = 200; (ci->ci_flags & CPUF_IDENTIFY) && i > 0; i--)
>   delay(10);
> 
> That means we have 3-4 cores spinning just to be able to delay().  Our
> mutex implementation isn't fair, which means whoever manages to claim
> the free mutex wins.  Now if CPU2 and CPU3 are spinning all the time,
> CPU1 identifies and needs delay() and CPU0 waits for CPU1, maybe the
> one that needs to make progress never gets it.
> 
> I changed those delay(10) in cpu_hatch() to CPU_BUSY_CYCLE() and it went
> ahead a bit better instead of hanging forever.
> 
> Then I remembered an idea something from years ago: fair kernel mutexes,
> so basically mutexes implemented as ticket lock, like our kerne lock.
> 
> I did a quick diff, which probably contains a million bugs, but with
> this bluhm's machine boots up well.
> 
> I'm not saying this is the solution, but it might be.
> 
> Patrick

Cleaned the diff up a little, changes since last time:

* Rename the struct members to be the same as mplock.
* Change the code to use ticket/user numbers like mplock.  This
  has one obvious downside: If a mutex is not initialized, trying
  to get this mutex will result in a hang.  At least that just let
  me find some uninitialized mutexes.
* More consistent use of the 'ci' variable.
* Definitely compiles with/without DIAGNOSTIC.
* Made sure mtx_enter() still has the membar.
* No need for READ_ONCE() when members are volatile.

Apart from being fair, this diff also changes the behaviour while
spinning for a lock.  Previously mtx_enter called mtx_enter_try
in a loop until it got the lock.  mtx_enter_try does splraise,
try lock, splx.  This diff currently spins with the SPL raised,
so that's a change in behaviour.  I'm sure I can change the diff
to splraise/splx while looping, if we prefer that behaviour.

Patrick

diff --git a/sys/kern/kern_lock.c b/sys/kern/kern_lock.c
index 5cc55bb256a..1eeb30e0c40 100644
--- a/sys/kern/kern_lock.c
+++ b/sys/kern/kern_lock.c
@@ -248,6 +248,8 @@ __mtx_init(struct mutex *mtx, int wantipl)
mtx->mtx_owner = NULL;
mtx->mtx_wantipl = wantipl;
mtx->mtx_oldipl = IPL_NONE;
+   mtx->mtx_users = 0;
+   mtx->mtx_ticket = 1;
 }
 
 #ifdef MULTIPROCESSOR
@@ -255,15 +257,26 @@ void
 mtx_enter(struct mutex *mtx)
 {
struct schedstate_percpu *spc = ()->ci_schedstate;
+   struct cpu_info *ci = curcpu();
 #ifdef MP_LOCKDEBUG
int nticks = __mp_lock_spinout;
 #endif
+   u_int t;
+   int s;
+
+   /* Avoid deadlocks after panic or in DDB */
+   if (panicstr || db_active)
+   return;
 
WITNESS_CHECKORDER(MUTEX_LOCK_OBJECT(mtx),
LOP_EXCLUSIVE | LOP_NEWORDER, NULL);
 
+   if (mtx->mtx_wantipl != IPL_NONE)
+   s = splraise(mtx->mtx_wantipl);
+
spc->spc_spinning++;
-   while (mtx_enter_try(mtx) == 0) {
+   t = atomic_inc_int_nv(>mtx_users);
+   while (mtx->mtx_ticket != t) {
CPU_BUSY_CYCLE();
 
 #ifdef MP_LOCKDEBUG
@@ -275,12 +288,22 @@ mtx_enter(struct mutex *mtx)
 #endif
}
spc->spc_spinning--;
+
+   membar_enter_after_atomic();
+   mtx->mtx_owner = ci;
+   if (mtx->mtx_wantipl != IPL_NONE)
+   mtx->mtx_oldipl = s;
+#ifdef DIAGNOSTIC
+   ci->ci_mutex_level++;
+#endif
+   WITNESS_LOCK(MUTEX_LOCK_OBJECT(mtx), LOP_EXCLUSIVE);
 }
 
 int
 mtx_enter_try(struct mutex *mtx)
 {
-   struct cpu_info *owner, *ci = curcpu();
+   struct cpu_in

mutex(9): initialize some more mutexes before use?

[Patrick Wildt]

Hi,

I was playing around a little with the mutex code and found that on
arm64 there some uninitialized mutexes out there.

I think the arm64 specific one is comparatively easy to solve.  We
either initialize the mtx when we initialize the rest of the pmap, or
we move it into the global definition of those.  I opted for the former
version.

The other one prolly needs more discussion/debugging.  So uvm_init()
calls first pmap_init() and then uvm_km_page_init().  The latter does
initialize the mutex, but arm64's pmap_init() already uses pools, which
uses km_alloc, which then uses that mutex.  Now one easy fix would be
to just initialize the definition right away instead of during runtime.

But there might be the question if arm64's pmap is allowed to use pools
and km_alloc during pmap_init.

Patrick

#0  0xff800073f984 in mtx_enter (mtx=0xff8000f3b048 ) at 
/usr/src/sys/kern/kern_lock.c:281
#1  0xff8000937e6c in km_alloc (sz=, kv=0xff8000da6a30 , kp=0xff8000da6a48 
, kd=0xff8000e934d8)
at /usr/src/sys/uvm/uvm_km.c:899
#2  0xff800084d804 in pool_page_alloc (pp=, flags=,
slowdown=) 
at /usr/src/sys/kern/subr_pool.c:1633
#3  0xff800084f8dc in pool_allocator_alloc (pp=0xff8000ea6e40 
, flags=65792, slowdown=0xff80026cd098) at 
/usr/src/sys/kern/subr_pool.c:1602
#4  0xff800084ef08 in pool_p_alloc (pp=0xff8000ea6e40 , 
flags=2, slowdown=0xff8000e9359c) at /usr/src/sys/kern/subr_pool.c:926
#5  0xff800084f808 in pool_prime (pp=, n=) at 
/usr/src/sys/kern/subr_pool.c:896
#6  0xff800048c20c in pmap_init () at 
/usr/src/sys/arch/arm64/arm64/pmap.c:1682
#7  0xff80009384dc in uvm_init () at /usr/src/sys/uvm/uvm_init.c:118
#8  0xff800048e664 in main (framep=) at /usr/src/sys/kern/init_main.c:235

diff --git a/sys/arch/arm64/arm64/pmap.c b/sys/arch/arm64/arm64/pmap.c
index 79a344cc84e..f070f4540ec 100644
--- a/sys/arch/arm64/arm64/pmap.c
+++ b/sys/arch/arm64/arm64/pmap.c
@@ -1308,10 +1308,12 @@ pmap_bootstrap(long kvo, paddr_t lpt1, long 
kernelstart, long kernelend,
pmap_kernel()->pm_vp.l1 = (struct pmapvp1 *)va;
pmap_kernel()->pm_privileged = 1;
pmap_kernel()->pm_asid = 0;
+   mtx_init(_kernel()->pm_mtx, IPL_VM);
 
pmap_tramp.pm_vp.l1 = (struct pmapvp1 *)va + 1;
pmap_tramp.pm_privileged = 1;
pmap_tramp.pm_asid = 0;
+   mtx_init(_tramp.pm_mtx, IPL_VM);
 
/* Mark ASID 0 as in-use. */
pmap_asid[0] |= (3U << 0);
diff --git a/sys/uvm/uvm_km.c b/sys/uvm/uvm_km.c
index 4a60377e9d7..e77afeda832 100644
--- a/sys/uvm/uvm_km.c
+++ b/sys/uvm/uvm_km.c
@@ -644,7 +644,7 @@ uvm_km_page_lateinit(void)
  * not zero filled.
  */
 
-struct uvm_km_pages uvm_km_pages;
+struct uvm_km_pages uvm_km_pages = { .mtx = MUTEX_INITIALIZER(IPL_VM) };
 
 void uvm_km_createthread(void *);
 void uvm_km_thread(void *);
@@ -664,7 +664,6 @@ uvm_km_page_init(void)
int len, bulk;
vaddr_t addr;
 
-   mtx_init(_km_pages.mtx, IPL_VM);
if (!uvm_km_pages.lowat) {
/* based on physmem, calculate a good value here */
uvm_km_pages.lowat = physmem / 256;

Re: [please test] amd64: schedule clock interrupts against system clock

[Patrick Wildt]

Am Fri, Jul 30, 2021 at 07:55:29PM +0200 schrieb Alexander Bluhm:
> On Mon, Jul 26, 2021 at 08:12:39AM -0500, Scott Cheloha wrote:
> > On Fri, Jun 25, 2021 at 06:09:27PM -0500, Scott Cheloha wrote:
> > 1 month bump.  I really appreciate the tests I've gotten so far, thank
> > you.
> 
> On my Xeon machine it works and all regress tests pass.
> 
> But it fails on my old Opteron machine.  It hangs after attaching
> cpu1.

This seems to be caused by contention on the mutex in i8254's gettick().

With Scott's diff, delay_func is i8254_delay() on that old AMD machine.
Its gettick() implementation uses a mutex to protect I/O access to the
i8254.

When secondary CPUs come up, they will wait for CPU0 to let them boot up
further by checking for a flag:

/*
 * We need to wait until we can identify, otherwise dmesg
 * output will be messy.
 */
while ((ci->ci_flags & CPUF_IDENTIFY) == 0)
delay(10);

Now that machine has 3 secondary cores that are spinning like that.  At
the same time CPU0 waits for the core to come up:

/* wait for it to identify */
for (i = 200; (ci->ci_flags & CPUF_IDENTIFY) && i > 0; i--)
delay(10);

That means we have 3-4 cores spinning just to be able to delay().  Our
mutex implementation isn't fair, which means whoever manages to claim
the free mutex wins.  Now if CPU2 and CPU3 are spinning all the time,
CPU1 identifies and needs delay() and CPU0 waits for CPU1, maybe the
one that needs to make progress never gets it.

I changed those delay(10) in cpu_hatch() to CPU_BUSY_CYCLE() and it went
ahead a bit better instead of hanging forever.

Then I remembered an idea something from years ago: fair kernel mutexes,
so basically mutexes implemented as ticket lock, like our kerne lock.

I did a quick diff, which probably contains a million bugs, but with
this bluhm's machine boots up well.

I'm not saying this is the solution, but it might be.

Patrick

diff --git a/sys/kern/kern_lock.c b/sys/kern/kern_lock.c
index 5cc55bb256a..c6a284beb51 100644
--- a/sys/kern/kern_lock.c
+++ b/sys/kern/kern_lock.c
@@ -248,6 +248,8 @@ __mtx_init(struct mutex *mtx, int wantipl)
mtx->mtx_owner = NULL;
mtx->mtx_wantipl = wantipl;
mtx->mtx_oldipl = IPL_NONE;
+   mtx->mtx_ticket = 0;
+   mtx->mtx_cur = 0;
 }
 
 #ifdef MULTIPROCESSOR
@@ -255,15 +257,26 @@ void
 mtx_enter(struct mutex *mtx)
 {
struct schedstate_percpu *spc = ()->ci_schedstate;
+   struct cpu_info *ci = curcpu();
+   unsigned int t;
 #ifdef MP_LOCKDEBUG
int nticks = __mp_lock_spinout;
 #endif
+   int s;
+
+   /* Avoid deadlocks after panic or in DDB */
+   if (panicstr || db_active)
+   return;
 
WITNESS_CHECKORDER(MUTEX_LOCK_OBJECT(mtx),
LOP_EXCLUSIVE | LOP_NEWORDER, NULL);
 
+   if (mtx->mtx_wantipl != IPL_NONE)
+   s = splraise(mtx->mtx_wantipl);
+
spc->spc_spinning++;
-   while (mtx_enter_try(mtx) == 0) {
+   t = atomic_inc_int_nv(>mtx_ticket) - 1;
+   while (READ_ONCE(mtx->mtx_cur) != t) {
CPU_BUSY_CYCLE();
 
 #ifdef MP_LOCKDEBUG
@@ -275,12 +288,21 @@ mtx_enter(struct mutex *mtx)
 #endif
}
spc->spc_spinning--;
+
+   mtx->mtx_owner = curcpu();
+   if (mtx->mtx_wantipl != IPL_NONE)
+   mtx->mtx_oldipl = s;
+#ifdef DIAGNOSTIC
+   ci->ci_mutex_level++;
+#endif
+   WITNESS_LOCK(MUTEX_LOCK_OBJECT(mtx), LOP_EXCLUSIVE);
 }
 
 int
 mtx_enter_try(struct mutex *mtx)
 {
-   struct cpu_info *owner, *ci = curcpu();
+   struct cpu_info *ci = curcpu();
+   unsigned int t;
int s;
 
/* Avoid deadlocks after panic or in DDB */
@@ -290,13 +312,15 @@ mtx_enter_try(struct mutex *mtx)
if (mtx->mtx_wantipl != IPL_NONE)
s = splraise(mtx->mtx_wantipl);
 
-   owner = atomic_cas_ptr(>mtx_owner, NULL, ci);
 #ifdef DIAGNOSTIC
-   if (__predict_false(owner == ci))
+   if (__predict_false(mtx->mtx_owner == ci))
panic("mtx %p: locking against myself", mtx);
 #endif
-   if (owner == NULL) {
+
+   t = READ_ONCE(mtx->mtx_cur);
+   if (atomic_cas_uint(>mtx_ticket, t, t + 1) == t) {
membar_enter_after_atomic();
+   mtx->mtx_owner = curcpu();
if (mtx->mtx_wantipl != IPL_NONE)
mtx->mtx_oldipl = s;
 #ifdef DIAGNOSTIC
@@ -369,6 +393,9 @@ mtx_leave(struct mutex *mtx)
membar_exit();
 #endif
mtx->mtx_owner = NULL;
+#ifdef MULTIPROCESSOR
+   atomic_inc_int_nv(>mtx_cur);
+#endif
if (mtx->mtx_wantipl != IPL_NONE)
splx(s);
 }

virtio(4): don't require legacy mode to have an I/O BAR

[Patrick Wildt]

Hi,

so on the new Parallels version, when using the 'Other' OS setting,
virtio(4) won't attach.  Apparently it's not Virtio 1.0, because even
Fedora 34 falls back to the 'legacy' driver.

While our code expects (and requires) an I/O BAR, it seems to be that
the PCI device only provides two memory BARs.

Linux still works, probably because they don't care about the type.
So I figured, let's just do that as well.  With the following diff,
virtio(4) attach es again, and I can install over vio(4).

I don't know if this violates any official virtio(4) spec, but on
the other hand... it fixes as bug, makes it work, and just loosens
up the requirement a little.

ok?

Patrick

diff --git a/sys/dev/pci/virtio_pci.c b/sys/dev/pci/virtio_pci.c
index c99f50136cd..0a29293e16c 100644
--- a/sys/dev/pci/virtio_pci.c
+++ b/sys/dev/pci/virtio_pci.c
@@ -508,7 +508,10 @@ int
 virtio_pci_attach_09(struct virtio_pci_softc *sc, struct pci_attach_args *pa)
 {
struct virtio_softc *vsc = >sc_sc;
-   if (pci_mapreg_map(pa, PCI_MAPREG_START, PCI_MAPREG_TYPE_IO, 0,
+   pcireg_t type;
+
+   type = pci_mapreg_type(pa->pa_pc, pa->pa_tag, PCI_MAPREG_START);
+   if (pci_mapreg_map(pa, PCI_MAPREG_START, type, 0,
>sc_iot, >sc_ioh, NULL, >sc_iosize, 0)) {
printf("%s: can't map i/o space\n", vsc->sc_dev.dv_xname);
return EIO;

Re: vmx(4): remove useless code

[Patrick Wildt]

On Fri, Aug 06, 2021 at 11:05:53AM +0200, Patrick Wildt wrote:
> Am Thu, Aug 05, 2021 at 02:33:01PM +0200 schrieb Jan Klemkow:
> > Hi,
> > 
> > The following diff removes useless code from the driver.  As discussed
> > here [1] and committed there [2], the hypervisor doesn't do anything
> > with the data structures.  We even just set NULL to the pointer since
> > the initial commit of vmx(4).  So, I guess it better to remove all of
> > these.  The variables are bzero'd in vmxnet3_dma_allocmem() anyway.
> > 
> > OK?
> 
> My main concern was if the structs are getting zeroed correctly, but
> they do, so that's fine.
> 
> That said, it looks like Linux sets the pointer to ~0ULL, not 0.  Should
> we follow Linux' pattern there and do that as well?
> 

Thinking about it a little more, I think we should do that as well.  And
maybe explicitly set driver_data_len to 0 even though it's already zero.
Basically for readability.

> 
> > bye,
> > Jan
> > 
> > [1]: https://www.lkml.org/lkml/2021/1/19/1225
> > [2]: 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/vmxnet3/vmxnet3_drv.c?id=de1da8bcf40564a2adada2d5d5426e05355f66e8
> > 
> > Index: dev/pci/if_vmx.c
> > ===
> > RCS file: /cvs/src/sys/dev/pci/if_vmx.c,v
> > retrieving revision 1.66
> > diff -u -p -r1.66 if_vmx.c
> > --- dev/pci/if_vmx.c23 Jul 2021 00:29:14 -  1.66
> > +++ dev/pci/if_vmx.c5 Aug 2021 11:12:26 -
> > @@ -157,7 +157,6 @@ struct vmxnet3_softc {
> >  #define WRITE_BAR1(sc, reg, val) \
> > bus_space_write_4((sc)->sc_iot1, (sc)->sc_ioh1, reg, val)
> >  #define WRITE_CMD(sc, cmd) WRITE_BAR1(sc, VMXNET3_BAR1_CMD, cmd)
> > -#define vtophys(va) 0  /* XXX ok? */
> >  
> >  int vmxnet3_match(struct device *, void *, void *);
> >  void vmxnet3_attach(struct device *, struct device *, void *);
> > @@ -468,8 +467,6 @@ vmxnet3_dma_init(struct vmxnet3_softc *s
> > ds->vmxnet3_revision = 1;
> > ds->upt_version = 1;
> > ds->upt_features = UPT1_F_CSUM | UPT1_F_VLAN;
> > -   ds->driver_data = vtophys(sc);
> > -   ds->driver_data_len = sizeof(struct vmxnet3_softc);
> > ds->queue_shared = qs_pa;
> > ds->queue_shared_len = qs_len;
> > ds->mtu = VMXNET3_MAX_MTU;
> > @@ -546,8 +543,6 @@ vmxnet3_alloc_txring(struct vmxnet3_soft
> > ts->cmd_ring_len = NTXDESC;
> > ts->comp_ring = comp_pa;
> > ts->comp_ring_len = NTXCOMPDESC;
> > -   ts->driver_data = vtophys(tq);
> > -   ts->driver_data_len = sizeof *tq;
> > ts->intr_idx = intr;
> > ts->stopped = 1;
> > ts->error = 0;
> > @@ -598,8 +593,6 @@ vmxnet3_alloc_rxring(struct vmxnet3_soft
> > rs->cmd_ring_len[1] = NRXDESC;
> > rs->comp_ring = comp_pa;
> > rs->comp_ring_len = NRXCOMPDESC;
> > -   rs->driver_data = vtophys(rq);
> > -   rs->driver_data_len = sizeof *rq;
> > rs->intr_idx = intr;
> > rs->stopped = 1;
> > rs->error = 0;
> > 
> 

Re: vmx(4): remove useless code

[Patrick Wildt]

Am Thu, Aug 05, 2021 at 02:33:01PM +0200 schrieb Jan Klemkow:
> Hi,
> 
> The following diff removes useless code from the driver.  As discussed
> here [1] and committed there [2], the hypervisor doesn't do anything
> with the data structures.  We even just set NULL to the pointer since
> the initial commit of vmx(4).  So, I guess it better to remove all of
> these.  The variables are bzero'd in vmxnet3_dma_allocmem() anyway.
> 
> OK?

My main concern was if the structs are getting zeroed correctly, but
they do, so that's fine.

That said, it looks like Linux sets the pointer to ~0ULL, not 0.  Should
we follow Linux' pattern there and do that as well?

Patrick

> bye,
> Jan
> 
> [1]: https://www.lkml.org/lkml/2021/1/19/1225
> [2]: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/vmxnet3/vmxnet3_drv.c?id=de1da8bcf40564a2adada2d5d5426e05355f66e8
> 
> Index: dev/pci/if_vmx.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_vmx.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 if_vmx.c
> --- dev/pci/if_vmx.c  23 Jul 2021 00:29:14 -  1.66
> +++ dev/pci/if_vmx.c  5 Aug 2021 11:12:26 -
> @@ -157,7 +157,6 @@ struct vmxnet3_softc {
>  #define WRITE_BAR1(sc, reg, val) \
>   bus_space_write_4((sc)->sc_iot1, (sc)->sc_ioh1, reg, val)
>  #define WRITE_CMD(sc, cmd) WRITE_BAR1(sc, VMXNET3_BAR1_CMD, cmd)
> -#define vtophys(va) 0/* XXX ok? */
>  
>  int vmxnet3_match(struct device *, void *, void *);
>  void vmxnet3_attach(struct device *, struct device *, void *);
> @@ -468,8 +467,6 @@ vmxnet3_dma_init(struct vmxnet3_softc *s
>   ds->vmxnet3_revision = 1;
>   ds->upt_version = 1;
>   ds->upt_features = UPT1_F_CSUM | UPT1_F_VLAN;
> - ds->driver_data = vtophys(sc);
> - ds->driver_data_len = sizeof(struct vmxnet3_softc);
>   ds->queue_shared = qs_pa;
>   ds->queue_shared_len = qs_len;
>   ds->mtu = VMXNET3_MAX_MTU;
> @@ -546,8 +543,6 @@ vmxnet3_alloc_txring(struct vmxnet3_soft
>   ts->cmd_ring_len = NTXDESC;
>   ts->comp_ring = comp_pa;
>   ts->comp_ring_len = NTXCOMPDESC;
> - ts->driver_data = vtophys(tq);
> - ts->driver_data_len = sizeof *tq;
>   ts->intr_idx = intr;
>   ts->stopped = 1;
>   ts->error = 0;
> @@ -598,8 +593,6 @@ vmxnet3_alloc_rxring(struct vmxnet3_soft
>   rs->cmd_ring_len[1] = NRXDESC;
>   rs->comp_ring = comp_pa;
>   rs->comp_ring_len = NRXCOMPDESC;
> - rs->driver_data = vtophys(rq);
> - rs->driver_data_len = sizeof *rq;
>   rs->intr_idx = intr;
>   rs->stopped = 1;
>   rs->error = 0;
> 

Re: iked(8): Increase the default Child SA data lifetime limit

[Patrick Wildt]

Am Tue, Aug 03, 2021 at 01:40:51PM +0200 schrieb Tobias Heider:
> On Tue, Aug 03, 2021 at 12:17:38PM +0100, Stuart Henderson wrote:
> > On 2021/08/03 01:12, Vitaliy Makkoveev wrote:
> > > iked(8) uses 3 hours and 512 megabytes of processed data as default
> > > lifetime hard limits for Child SA. Also it sets 85-95% of these values as
> > > soft limit. iked(8) should perform rekeying before we reach hard limit
> > > otherwise this SA will be killed and the tunnel stopped. With default
> > > values the window is only 25-52 megabytes and we easily consume them
> > > before rekeying and the tunnel stops.
> > > 
> > > Hrvoje Popovski complained about such stops when he has tested ipsec(4)
> > > related diffs. I also tried iked(8) with my macos and found that simple
> > > "ping -f ..." makes rekeying impossible.
> > > 
> > > The hard limit could be modified in iked.conf(5) by setting "lifetime
> > > xxx bytes yyy", but the 5% difference between hard and soft limits forces
> > > to set bytes limit big enough, about 4G and more, which could be bad for
> > > security reason.
> > > 
> > > I propose to increase the default hard limit at least up to 1G. Also I
> > > propose to decrease the soft limit down to 50-60% of hard limit. This
> > > keeps the rekeying frequency but increases the update window to 410-512
> > > megabytes. Also this allow to keep bytes in "lifetime" setting small
> > > enough.
> > 
> > I have a couple of comments;
> > 
> > - this isn't a problem I've run into with real-world usage or when
> > running tcpbench over (moderately fast) internet connections - I'm not
> > saying it doesn't happen, but it seems relatively uncommon, with
> > connections at LAN speeds of course it's much more likely
> > 
> > - a 50% lower limit feels too low to me
> > 
> > - your jitter change affects lifetime both in seconds and in bytes,
> > I think changing the jitter for the seconds lifetime is a mistake
> > 
> > - the jitter change could result in some really short rekey intervals
> > if somebody has manually specified lifetimes which are the same as or less
> > than the current default
> > 
> > - looking at other IKEv2 implementations: if bytes lifetime is supported
> > at all (several implementations don't have it, only time-based lifetime),
> > the default settings rarely seem to use it
> > 
> > - 512MB is not really a lot of data
> > 
> > My first though now I know about this problem is just to increase the
> > default byte limit and leave the jitter range as-is. I don't know enough
> > about the security requirements of IKEv2 to know what demands it places
> > on rekeying, but given the above (especially that other implementations
> > mostly don't use byte limits at all), the figure I'd pull out of the air
> > would be more like 4GB.
> > 
> 
> I agree with Stuart here. In my experience raising the limit to 4 GB is enough
> to solve the problem and the current jitter works well enough.
> 
> In a next step we can think about relaxing the limits even further for "safe"
> algorithms like Theo proposed, but this would need a bit more work.
> 
> FWIW here's a diff I sent to bluhm a few weeks ago.  We didn't commit it yet
> because the low limit helped us find and reproduce a PMTU bug (that should
> be gone now).

ok patrick@

> Index: types.h
> ===
> RCS file: /cvs/src/sbin/iked/types.h,v
> retrieving revision 1.43
> diff -u -p -r1.43 types.h
> --- types.h   13 May 2021 15:20:48 -  1.43
> +++ types.h   3 Aug 2021 11:35:26 -
> @@ -67,7 +67,7 @@
>  #define IKED_CYCLE_BUFFERS   8   /* # of static buffers for mapping */
>  #define IKED_PASSWORD_SIZE   256 /* limited by most EAP types */
>  
> -#define IKED_LIFETIME_BYTES  536870912 /* 512 Mb */
> +#define IKED_LIFETIME_BYTES  4294967296 /* 4 GB */
>  #define IKED_LIFETIME_SECONDS10800 /* 3 hours */
>  
>  #define IKED_E   0x1000  /* Decrypted flag */
> 

Re: [please test] amd64: schedule clock interrupts against system clock

[Patrick Wildt]

On Thu, Jun 24, 2021 at 09:50:07PM -0500, Scott Cheloha wrote:
> Hi,
> 
> I'm looking for testers for the attached patch.  You need an amd64
> machine with a lapic.
> 
> This includes:
> 
> - All "real" amd64 machines ever made
> - amd64 VMs running on hypervisors that provide a virtual lapic
> 
> Note that this does *not* include:
> 
> - amd64 VMs running on OpenBSD's vmm(4).
> 
> (I will ask for a separate round of testing for vmm(4) VMs, don't
> worry.)
> 
> The patch adds a new machine-independent clock interrupt scheduling
> layer (hereafter, "clockintr") to the kernel in kern/kern_clockintr.c,
> configures GENERIC amd64 kernels to use clockintr, and changes
> amd64/lapic.c to use clockintr instead of calling hardclock(9)
> directly.
> 
> Please apply the patch and make sure to reconfigure your kernel before
> recompiling/installing it to test.  I am especially interested in
> whether this breaks suspend/resume or hibernate/unhibernate.
> Suspend/resume is unaffected on my Lenovo X1C7, is the same true for
> your machine?  Please include a dmesg with your results.
> 
> Stats for the clockintr subsystem are exposed via sysctl(2).  If
> you're interested in providing them you can compile and run the
> program attached inline in my next mail.  A snippet of the output from
> across a suspend/resume is especially useful.
> 
> This is the end of the mail if you just want to test this.  If you are
> interested in the possible behavior changes or a description of how
> clockintr works, keep reading.
> 
> Thanks,
> 
> -Scott
> 
> --
> 
> There are some behavior changes, but I have found them to be small,
> harmless, and/or useful.  The first one is the most significant:
> 
> - Clockintr schedules events against the system clock, so hardclock(9)
>   ticks are pegged to the system clock, so the length of a tick is now
>   subject to NTP adjustment via adjtime(2) and adjfreq(2).
> 
>   In practice, NTP adjustment is very conservative.  In my testing the
>   delta between the raw frequency and the NTP frequency is small
>   when ntpd(8) is doing coarse correction with adjtime(2) and invisible
>   when ntpd(8) is doing fine correction with adjfreq(2).
> 
>   The upshot of the frequency difference is sometimes you will get
>   some spurious ("early") interrupts while ntpd(8) is correcting the
>   clock.  They go away when the ntpd(8) finishes synchronizing.
> 
>   FWIW: Linux, FreeBSD, and DragonflyBSD have all made this jump.
> 
> - hardclock(9) will run simultaneously on every CPU in the system.
>   This seems to be fine, but there might be some subtle contention
>   that gets worse as you add more CPUs.  Worth investigating.
> 
> - amd64 gets a pseudorandom statclock().  This is desirable, right?
> 
> - "Lost" or delayed ticks are handled by the clockintr layer
>   transparently.  This means that if the clock interrupt is delayed
>   due to e.g. hypervisor delays, we don't "lose" ticks and the
>   timeout schedule does not decay.
> 
>   This is super relevant for vmm(4), but it may also be relevant for
>   other hypervisors.

This sounds pretty good.  I remember someone having horrible time issues
because his VM was missing plenty of ticks, as the HyperVisor was over-
provisioned, or so.

So my X395 still suspends/resumes fine with your change, so that's nice.
Not sure if there's anything other than that which I should test, but so
far I don't notice any regression.

> 
> --
> 
> Last, here are notes for people interested in the design or the actual
> code.  Ask questions if something about my approach seems off, I have
> never added a subsystem to the kernel before.  The code has not
> changed much in the last six months so I think I am nearing a stable
> design.  I will document these interfaces in a real manpage soon.
> 
> - Clockintr prototypes are declared in .
> 
> - Clockintr depends on the timecounter and the system clock to do its
>   scheduling.  If there is no working timecounter the machine will
>   hang, as multitasking preemption will cease.
> 
> - Global clockintr initialization is done via clockintr_init().  You
>   call this from cpu_initclocks() on the primary CPU *after* you install
>   a timecounter.  The function sets a global frequency for the
>   hardclock(9) (required), a global frequency for the statclock()
>   (or zero if you don't want a statclock), and sets global behavior
>   flags.
> 
>   There is only one flag right now, CI_RNDSTAT, which toggles whether
>   the statclock() has a pseudorandom period.  If the platform has a
>   one-shot clock (e.g. amd64, arm64, etc.) it makes sense to set
>   CI_RNDSTAT.  If the platform does not have a one-shot clock (e.g.
>   alpha) there is no point in setting CI_RNDSTAT as the hardware
>   cannot provide the feature.
> 
> - Per-CPU clockintr initialization is done via clockintr_cpu_init().
>   On the primary CPU, call this immediately *after* you call
>   clockintr_init().  Secondary CPUs should call this late in
>   cpu_hatch(), probably right 

Re: pf icmp reflect

[Patrick Wildt]

On Mon, Jul 26, 2021 at 06:41:42PM +0200, Alexander Bluhm wrote:
> Hi,
> 
> The mbuf header cleanup I added in revision 1.173 of ip_icmp.c is
> too strict.  ICMP error packets generated by pf are not passed
> immediately, but may be blocked.  Preserve PF_TAG_GENERATED flag
> in icmp_reflect() and icmp6_reflect().
> 
> ok?

While I do prefer uint8_t, the struct member is defined as u_int8_t, so
I guess for consistency we can use that.

ok patrick@

> bluhm
> 
> Index: netinet/ip_icmp.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet/ip_icmp.c,v
> retrieving revision 1.186
> diff -u -p -r1.186 ip_icmp.c
> --- netinet/ip_icmp.c 30 Mar 2021 08:37:10 -  1.186
> +++ netinet/ip_icmp.c 26 Jul 2021 14:10:37 -
> @@ -691,6 +691,7 @@ icmp_reflect(struct mbuf *m, struct mbuf
>   struct rtentry *rt = NULL;
>   int optlen = (ip->ip_hl << 2) - sizeof(struct ip);
>   u_int rtableid;
> + u_int8_t pfflags;
>  
>   if (!in_canforward(ip->ip_src) &&
>   ((ip->ip_src.s_addr & IN_CLASSA_NET) !=
> @@ -704,8 +705,10 @@ icmp_reflect(struct mbuf *m, struct mbuf
>   return (ELOOP);
>   }
>   rtableid = m->m_pkthdr.ph_rtableid;
> + pfflags = m->m_pkthdr.pf.flags;
>   m_resethdr(m);
>   m->m_pkthdr.ph_rtableid = rtableid;
> + m->m_pkthdr.pf.flags = pfflags & PF_TAG_GENERATED;
>  
>   /*
>* If the incoming packet was addressed directly to us,
> Index: netinet6/icmp6.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/sys/netinet6/icmp6.c,v
> retrieving revision 1.235
> diff -u -p -r1.235 icmp6.c
> --- netinet6/icmp6.c  10 Mar 2021 10:21:49 -  1.235
> +++ netinet6/icmp6.c  26 Jul 2021 15:42:33 -
> @@ -1052,6 +1052,7 @@ icmp6_reflect(struct mbuf **mp, size_t o
>   struct in6_addr t, *src = NULL;
>   struct sockaddr_in6 sa6_src, sa6_dst;
>   u_int rtableid;
> + u_int8_t pfflags;
>  
>   CTASSERT(sizeof(struct ip6_hdr) + sizeof(struct icmp6_hdr) <= MHLEN);
>  
> @@ -1069,8 +1070,10 @@ icmp6_reflect(struct mbuf **mp, size_t o
>   return (ELOOP);
>   }
>   rtableid = m->m_pkthdr.ph_rtableid;
> + pfflags = m->m_pkthdr.pf.flags;
>   m_resethdr(m);
>   m->m_pkthdr.ph_rtableid = rtableid;
> + m->m_pkthdr.pf.flags = pfflags & PF_TAG_GENERATED;
>  
>   /*
>* If there are extra headers between IPv6 and ICMPv6, strip
> 

Re: dwiic(4): wait for tx empty when hitting tx limit

[Patrick Wildt]

Am Mon, Jul 05, 2021 at 07:52:28PM +0200 schrieb Mark Kettenis:
> > Date: Mon, 5 Jul 2021 19:30:28 +0200
> > From: Patrick Wildt 
> > 
> > Am Mon, Jul 05, 2021 at 07:07:24PM +0200 schrieb Mark Kettenis:
> > > > Date: Mon, 5 Jul 2021 19:02:32 +0200
> > > > From: Patrick Wildt 
> > > > 
> > > > Am Mon, Jul 05, 2021 at 06:34:31PM +0200 schrieb Mark Kettenis:
> > > > > > Date: Mon, 5 Jul 2021 00:04:24 +0200
> > > > > > From: Patrick Wildt 
> > > > > > 
> > > > > > Hi,
> > > > > > 
> > > > > > I had trouble interfacing with a machine's IPMI through dwiic(4).  
> > > > > > What
> > > > > > I saw was that when sending 'bigger' commands, it would never 
> > > > > > receive
> > > > > > the STOP bit interrupt.
> > > > > > 
> > > > > > The trouble is, as can be seen in the log, that we want to send (it
> > > > > > says read, but it's a write OP, so it's send) 20 bytes, but the tx
> > > > > > limit says 14.
> > > > > > 
> > > > > > What we should do is send 14 bytes, then wait for it to send us the
> > > > > > tx empty interrupt (like we do when we first enable the controller),
> > > > > > and then re-read the tx limit.  The last line in the log is some
> > > > > > debug print I added for myself, but is not part of the diff.
> > > > > > 
> > > > > > With this, I was finally able to change the IPMI password and regain
> > > > > > access to the web interface after updating the BMC's firmware...
> > > > > > 
> > > > > > dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 3, flags 0x00
> > > > > > dwiic0: dwiic_i2c_exec: need to read 3 bytes, can send 14 read reqs
> > > > > > dwiic0: dwiic_i2c_exec: op 5, addr 0x10, cmdlen 1, len 33, flags 
> > > > > > 0x00
> > > > > > dwiic0: dwiic_i2c_exec: need to read 33 bytes, can send 15 read reqs
> > > > > > dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 20, flags 
> > > > > > 0x00
> > > > > > dwiic0: dwiic_i2c_exec: need to read 20 bytes, can send 14 read reqs
> > > > > > dwiic0: new tx limit 8
> > > > > > 
> > > > > > Opinions? ok?
> > > > > 
> > > > > I think you're on to something.  But this needs to handle I2C_F_POLL.
> > > > 
> > > > True that.  The previous code, which waits for the controller to accept
> > > > commands, just does DELAY(200), but I'm not sure that's good enough for
> > > > inbetween transfers.  One can apparently though poll through the raw
> > > > interrupt status register, where the interrupt mask isn't applied.  So
> > > > maybe like that?  Guess I should try setting ipmi to polling mode...
> > > 
> > > Polling the interrupt status register should work I suppose.  But for
> > > read operations we actually poll the DW_IC_RXFLR register.
> > 
> > Yeah, that would work for TX as well.  Maybe something like this, but
> > then the diff still needs to address what happens when we timeout and
> > there's still no tx_limit > 0.  Maybe timeout like the read stuff:
> > 
> > if (rx_avail == 0) {
> > printf("%s: timed out reading remaining %d\n",
> > sc->sc_dev.dv_xname, (int)(len - readpos));
> > sc->sc_i2c_xfer.error = 1;
> > sc->sc_busy = 0;
> > 
> > return (1);
> > }
> 
> Yes.

This works for me. ok?

Patrick

diff --git a/sys/dev/ic/dwiic.c b/sys/dev/ic/dwiic.c
index 84d97b8645b..8588b0905ea 100644
--- a/sys/dev/ic/dwiic.c
+++ b/sys/dev/ic/dwiic.c
@@ -416,6 +416,42 @@ dwiic_i2c_exec(void *cookie, i2c_op_t op, i2c_addr_t addr, 
const void *cmdbuf,
tx_limit = sc->tx_fifo_depth -
dwiic_read(sc, DW_IC_TXFLR);
}
+
+   if (I2C_OP_WRITE_P(op) && tx_limit == 0 && x < len) {
+   if (flags & I2C_F_POLL) {
+   for (retries = 1000; retries > 0; retries--) {
+   tx_limit = sc->tx_fifo_depth -
+   dwiic_read(sc, DW_IC_TXFLR);
+   if (tx_limit > 0)
+   break;
+   DE

Re: dwiic(4): wait for tx empty when hitting tx limit

[Patrick Wildt]

Am Mon, Jul 05, 2021 at 07:07:24PM +0200 schrieb Mark Kettenis:
> > Date: Mon, 5 Jul 2021 19:02:32 +0200
> > From: Patrick Wildt 
> > 
> > Am Mon, Jul 05, 2021 at 06:34:31PM +0200 schrieb Mark Kettenis:
> > > > Date: Mon, 5 Jul 2021 00:04:24 +0200
> > > > From: Patrick Wildt 
> > > > 
> > > > Hi,
> > > > 
> > > > I had trouble interfacing with a machine's IPMI through dwiic(4).  What
> > > > I saw was that when sending 'bigger' commands, it would never receive
> > > > the STOP bit interrupt.
> > > > 
> > > > The trouble is, as can be seen in the log, that we want to send (it
> > > > says read, but it's a write OP, so it's send) 20 bytes, but the tx
> > > > limit says 14.
> > > > 
> > > > What we should do is send 14 bytes, then wait for it to send us the
> > > > tx empty interrupt (like we do when we first enable the controller),
> > > > and then re-read the tx limit.  The last line in the log is some
> > > > debug print I added for myself, but is not part of the diff.
> > > > 
> > > > With this, I was finally able to change the IPMI password and regain
> > > > access to the web interface after updating the BMC's firmware...
> > > > 
> > > > dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 3, flags 0x00
> > > > dwiic0: dwiic_i2c_exec: need to read 3 bytes, can send 14 read reqs
> > > > dwiic0: dwiic_i2c_exec: op 5, addr 0x10, cmdlen 1, len 33, flags 0x00
> > > > dwiic0: dwiic_i2c_exec: need to read 33 bytes, can send 15 read reqs
> > > > dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 20, flags 0x00
> > > > dwiic0: dwiic_i2c_exec: need to read 20 bytes, can send 14 read reqs
> > > > dwiic0: new tx limit 8
> > > > 
> > > > Opinions? ok?
> > > 
> > > I think you're on to something.  But this needs to handle I2C_F_POLL.
> > 
> > True that.  The previous code, which waits for the controller to accept
> > commands, just does DELAY(200), but I'm not sure that's good enough for
> > inbetween transfers.  One can apparently though poll through the raw
> > interrupt status register, where the interrupt mask isn't applied.  So
> > maybe like that?  Guess I should try setting ipmi to polling mode...
> 
> Polling the interrupt status register should work I suppose.  But for
> read operations we actually poll the DW_IC_RXFLR register.

Yeah, that would work for TX as well.  Maybe something like this, but
then the diff still needs to address what happens when we timeout and
there's still no tx_limit > 0.  Maybe timeout like the read stuff:

if (rx_avail == 0) {
printf("%s: timed out reading remaining %d\n",
sc->sc_dev.dv_xname, (int)(len - readpos));
sc->sc_i2c_xfer.error = 1;
sc->sc_busy = 0;

return (1);
}

diff --git a/sys/dev/ic/dwiic.c b/sys/dev/ic/dwiic.c
index 84d97b8645b..d5d77a52b73 100644
--- a/sys/dev/ic/dwiic.c
+++ b/sys/dev/ic/dwiic.c
@@ -416,6 +416,33 @@ dwiic_i2c_exec(void *cookie, i2c_op_t op, i2c_addr_t addr, 
const void *cmdbuf,
tx_limit = sc->tx_fifo_depth -
dwiic_read(sc, DW_IC_TXFLR);
}
+
+   if (I2C_OP_WRITE_P(op) && tx_limit == 0 && x < len) {
+   if (flags & I2C_F_POLL) {
+   for (retries = 1000; retries > 0; retries--) {
+   tx_limit = sc->tx_fifo_depth -
+   dwiic_read(sc, DW_IC_TXFLR);
+   if (tx_limit > 0)
+   break;
+   DELAY(50);
+   }
+   } else {
+   s = splbio();
+   dwiic_read(sc, DW_IC_CLR_INTR);
+   dwiic_write(sc, DW_IC_INTR_MASK,
+   DW_IC_INTR_TX_EMPTY);
+
+   if (tsleep_nsec(>sc_writewait, PRIBIO,
+   "dwiic", MSEC_TO_NSEC(500)) != 0)
+   printf("%s: timed out waiting for "
+   "tx_empty intr\n",
+   sc->sc_dev.dv_xname);
+   splx(s);
+
+   tx_limit = sc->tx_fifo_depth -
+   dwiic_read(sc, DW_IC_TXFLR);
+   }
+   }
}
 
if (I2C_OP_STOP_P(op) && I2C_OP_WRITE_P(op)) {

Re: dwiic(4): wait for tx empty when hitting tx limit

[Patrick Wildt]

Am Mon, Jul 05, 2021 at 06:34:31PM +0200 schrieb Mark Kettenis:
> > Date: Mon, 5 Jul 2021 00:04:24 +0200
> > From: Patrick Wildt 
> > 
> > Hi,
> > 
> > I had trouble interfacing with a machine's IPMI through dwiic(4).  What
> > I saw was that when sending 'bigger' commands, it would never receive
> > the STOP bit interrupt.
> > 
> > The trouble is, as can be seen in the log, that we want to send (it
> > says read, but it's a write OP, so it's send) 20 bytes, but the tx
> > limit says 14.
> > 
> > What we should do is send 14 bytes, then wait for it to send us the
> > tx empty interrupt (like we do when we first enable the controller),
> > and then re-read the tx limit.  The last line in the log is some
> > debug print I added for myself, but is not part of the diff.
> > 
> > With this, I was finally able to change the IPMI password and regain
> > access to the web interface after updating the BMC's firmware...
> > 
> > dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 3, flags 0x00
> > dwiic0: dwiic_i2c_exec: need to read 3 bytes, can send 14 read reqs
> > dwiic0: dwiic_i2c_exec: op 5, addr 0x10, cmdlen 1, len 33, flags 0x00
> > dwiic0: dwiic_i2c_exec: need to read 33 bytes, can send 15 read reqs
> > dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 20, flags 0x00
> > dwiic0: dwiic_i2c_exec: need to read 20 bytes, can send 14 read reqs
> > dwiic0: new tx limit 8
> > 
> > Opinions? ok?
> 
> I think you're on to something.  But this needs to handle I2C_F_POLL.

True that.  The previous code, which waits for the controller to accept
commands, just does DELAY(200), but I'm not sure that's good enough for
inbetween transfers.  One can apparently though poll through the raw
interrupt status register, where the interrupt mask isn't applied.  So
maybe like that?  Guess I should try setting ipmi to polling mode...

> > diff --git a/sys/dev/ic/dwiic.c b/sys/dev/ic/dwiic.c
> > index 84d97b8645b..d04a7b03979 100644
> > --- a/sys/dev/ic/dwiic.c
> > +++ b/sys/dev/ic/dwiic.c
> > @@ -416,6 +416,21 @@ dwiic_i2c_exec(void *cookie, i2c_op_t op, i2c_addr_t 
> > addr, const void *cmdbuf,
> > tx_limit = sc->tx_fifo_depth -
> > dwiic_read(sc, DW_IC_TXFLR);
> > }
> > +
> > +   if (I2C_OP_WRITE_P(op) && tx_limit == 0 && x < len) {
> > +   s = splbio();
> > +   dwiic_read(sc, DW_IC_CLR_INTR);
> > +   dwiic_write(sc, DW_IC_INTR_MASK, DW_IC_INTR_TX_EMPTY);
> > +
> > +   if (tsleep_nsec(>sc_writewait, PRIBIO, "dwiic",
> > +   MSEC_TO_NSEC(500)) != 0)
> > +   printf("%s: timed out waiting for tx_empty "
> > +   "intr\n", sc->sc_dev.dv_xname);
> > +   splx(s);
> > +
> > +   tx_limit = sc->tx_fifo_depth -
> > +   dwiic_read(sc, DW_IC_TXFLR);
> > +   }
> > }
> >  
> > if (I2C_OP_STOP_P(op) && I2C_OP_WRITE_P(op)) {
> > 
> > 
> 

dwiic(4): wait for tx empty when hitting tx limit

[Patrick Wildt]

Hi,

I had trouble interfacing with a machine's IPMI through dwiic(4).  What
I saw was that when sending 'bigger' commands, it would never receive
the STOP bit interrupt.

The trouble is, as can be seen in the log, that we want to send (it
says read, but it's a write OP, so it's send) 20 bytes, but the tx
limit says 14.

What we should do is send 14 bytes, then wait for it to send us the
tx empty interrupt (like we do when we first enable the controller),
and then re-read the tx limit.  The last line in the log is some
debug print I added for myself, but is not part of the diff.

With this, I was finally able to change the IPMI password and regain
access to the web interface after updating the BMC's firmware...

dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 3, flags 0x00
dwiic0: dwiic_i2c_exec: need to read 3 bytes, can send 14 read reqs
dwiic0: dwiic_i2c_exec: op 5, addr 0x10, cmdlen 1, len 33, flags 0x00
dwiic0: dwiic_i2c_exec: need to read 33 bytes, can send 15 read reqs
dwiic0: dwiic_i2c_exec: op 7, addr 0x10, cmdlen 2, len 20, flags 0x00
dwiic0: dwiic_i2c_exec: need to read 20 bytes, can send 14 read reqs
dwiic0: new tx limit 8

Opinions? ok?

Patrick

diff --git a/sys/dev/ic/dwiic.c b/sys/dev/ic/dwiic.c
index 84d97b8645b..d04a7b03979 100644
--- a/sys/dev/ic/dwiic.c
+++ b/sys/dev/ic/dwiic.c
@@ -416,6 +416,21 @@ dwiic_i2c_exec(void *cookie, i2c_op_t op, i2c_addr_t addr, 
const void *cmdbuf,
tx_limit = sc->tx_fifo_depth -
dwiic_read(sc, DW_IC_TXFLR);
}
+
+   if (I2C_OP_WRITE_P(op) && tx_limit == 0 && x < len) {
+   s = splbio();
+   dwiic_read(sc, DW_IC_CLR_INTR);
+   dwiic_write(sc, DW_IC_INTR_MASK, DW_IC_INTR_TX_EMPTY);
+
+   if (tsleep_nsec(>sc_writewait, PRIBIO, "dwiic",
+   MSEC_TO_NSEC(500)) != 0)
+   printf("%s: timed out waiting for tx_empty "
+   "intr\n", sc->sc_dev.dv_xname);
+   splx(s);
+
+   tx_limit = sc->tx_fifo_depth -
+   dwiic_read(sc, DW_IC_TXFLR);
+   }
}
 
if (I2C_OP_STOP_P(op) && I2C_OP_WRITE_P(op)) {

Re: Patch: Send AUTHENTICATION_FAILED in case of unexpected auth method or auth data not being accessible

[Patrick Wildt]

Am Tue, Jun 29, 2021 at 10:39:06AM + schrieb Claudia Priesterjahn:
> We added two AUTHENTICATION_FAILED notifications for the cases that
> the peer used an unexepected authentication method and for the case
> that the peer's authentication data is not accessible.

Bit of a spacing issue, but that can be fixed prior to commit.  I'd also
drop the comments, since the function call seems self explanatory.  With
that changed, ok patrick@.

> diff --git a/sbin/iked/ikev2.c b/sbin/iked/ikev2.c
> index 9e890979110..1870dc18459 100644
> --- a/sbin/iked/ikev2.c
> +++ b/sbin/iked/ikev2.c
> @@ -805,6 +805,8 @@ ikev2_auth_verify(struct iked *env, struct iked_sa *sa)
> ikev2_auth_map),
> print_map(ikeauth.auth_method,
> ikev2_auth_map));
> +   /* send N(AUTHENTICATION_FAILED) back */
> +   ikev2_send_auth_failed(env, sa);
> return (-1);
> }
> ikeauth.auth_method = sa->sa_peerauth.id_type;
> @@ -813,6 +815,8 @@ ikev2_auth_verify(struct iked *env, struct iked_sa *sa)
> sa->sa_hdr.sh_initiator)) == NULL) {
> log_debug("%s: failed to get auth data",
> __func__);
> +   /* send N(AUTHENTICATION_FAILED) back */
> +   ikev2_send_auth_failed(env, sa);
> return (-1);
> }
> 

Re: 10gbase-r support for mvpp(4)

[Patrick Wildt]

Am Wed, Jun 02, 2021 at 10:37:36PM +0200 schrieb Mark Kettenis:
> Linux folks changed the device tree to use 10gbase-r instead of
> 10gbase-kr since "it is more correct".  Then the UEFI folks synched
> their device trees to Linux and the 10G ports broke.  So accept both
> in the code.
> 
> ok?
> 

Sigh. sure, ok patrick@.

Though you could probably put it into a single if (!strncmp ||
!strncmp), but I don't mind either way.

> 
> Index: dev/fdt/if_mvpp.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/if_mvpp.c,v
> retrieving revision 1.44
> diff -u -p -r1.44 if_mvpp.c
> --- dev/fdt/if_mvpp.c 12 Dec 2020 11:48:52 -  1.44
> +++ dev/fdt/if_mvpp.c 2 Jun 2021 20:34:30 -
> @@ -1354,7 +1354,9 @@ mvpp2_port_attach(struct device *parent,
>  
>   phy_mode = malloc(len, M_TEMP, M_WAITOK);
>   OF_getprop(sc->sc_node, "phy-mode", phy_mode, len);
> - if (!strncmp(phy_mode, "10gbase-kr", strlen("10gbase-kr")))
> + if (!strncmp(phy_mode, "10gbase-r", strlen("10gbase-r")))
> + sc->sc_phy_mode = PHY_MODE_10GBASER;
> + else if (!strncmp(phy_mode, "10gbase-kr", strlen("10gbase-kr")))
>   sc->sc_phy_mode = PHY_MODE_10GBASER;
>   else if (!strncmp(phy_mode, "2500base-x", strlen("2500base-x")))
>   sc->sc_phy_mode = PHY_MODE_2500BASEX;
> 

Re: sdmmc(4): check and retry bus width change

[Patrick Wildt]

Am Mon, Feb 22, 2021 at 08:10:21PM +0100 schrieb Patrick Wildt:
> Hi,
> 
> it seems like some eMMCs are not capable of doing 8-bit operation,
> even if the controller supports it.  I was questioning our drivers
> first, but it looks like it's the same on Linux.  In the case that
> 8-bit doesn't work, they seem to fall back to lower values to make
> that HW work.
> 
> This diff implements a mechanism that tries 8-bit, if available,
> then 4-bit and in the end falls back to 1-bit.  This makes my HW
> work, but I would like to have this tested by a broader audience.
> 
> Apparently there's a "bus test" command, but it isn't implemented
> on all host controllers.  Hence I simply try to read the EXT_CSD
> to make sure the transfer works.
> 
> For testing, a print like
> 
> printf("%s: using %u-bit width\n", DEVNAME(sc), width);
> 
> could be added at line 928.
> 
> What could possible regressions be?  The width could become smaller
> then previously.  This would reduce the read/write transfer speed.
> Also it's possible that eMMCs are not recognized/initialized anymore.
> 
> What could possible improvements be?  eMMCs that previously didn't
> work now work, with at least 1-bit or 4-bit wide transfers.
> 
> Please note that this only works for eMMCs.  SD cards are *not* using
> this code path.  SD cards have a different initialization code path.
> 
> Please report any changes or non-changes.  If nothing changes, that's
> perfect.
> 
> Patrick

Anyone want to give this a try?  It's basically relevant for all
ARM machines with eMMC ('soldered SD cards'), and they should work
as well as before.

> diff --git a/sys/dev/sdmmc/sdmmc_mem.c b/sys/dev/sdmmc/sdmmc_mem.c
> index 59bcb1b4a11..5856b9bb1b3 100644
> --- a/sys/dev/sdmmc/sdmmc_mem.c
> +++ b/sys/dev/sdmmc/sdmmc_mem.c
> @@ -56,6 +56,8 @@ int sdmmc_mem_signal_voltage(struct sdmmc_softc *, int);
>  
>  int  sdmmc_mem_sd_init(struct sdmmc_softc *, struct sdmmc_function *);
>  int  sdmmc_mem_mmc_init(struct sdmmc_softc *, struct sdmmc_function *);
> +int  sdmmc_mem_mmc_select_bus_width(struct sdmmc_softc *,
> + struct sdmmc_function *, int);
>  int  sdmmc_mem_single_read_block(struct sdmmc_function *, int, u_char *,
>   size_t);
>  int  sdmmc_mem_read_block_subr(struct sdmmc_function *, bus_dmamap_t,
> @@ -908,31 +910,20 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *sc, struct 
> sdmmc_function *sf)
>   ext_csd[EXT_CSD_CARD_TYPE]);
>   }
>  
> - if (ISSET(sc->sc_caps, SMC_CAPS_8BIT_MODE)) {
> + if (ISSET(sc->sc_caps, SMC_CAPS_8BIT_MODE) &&
> + sdmmc_mem_mmc_select_bus_width(sc, sf, 8) == 0)
>   width = 8;
> - value = EXT_CSD_BUS_WIDTH_8;
> - } else if (ISSET(sc->sc_caps, SMC_CAPS_4BIT_MODE)) {
> + else if (ISSET(sc->sc_caps, SMC_CAPS_4BIT_MODE) &&
> + sdmmc_mem_mmc_select_bus_width(sc, sf, 4) == 0)
>   width = 4;
> - value = EXT_CSD_BUS_WIDTH_4;
> - } else {
> - width = 1;
> - value = EXT_CSD_BUS_WIDTH_1;
> - }
> -
> - if (width != 1) {
> - error = sdmmc_mem_mmc_switch(sf, EXT_CSD_CMD_SET_NORMAL,
> - EXT_CSD_BUS_WIDTH, value);
> - if (error == 0)
> - error = sdmmc_chip_bus_width(sc->sct,
> - sc->sch, width);
> - else {
> + else {
> + error = sdmmc_mem_mmc_select_bus_width(sc, sf, 1);
> + if (error != 0) {
>   DPRINTF(("%s: can't change bus width"
>   " (%d bit)\n", DEVNAME(sc), width));
>   return error;
>   }
> -
> - /* : need bus test? (using by CMD14 & CMD19) */
> - sdmmc_delay(1);
> + width = 1;
>   }
>  
>   if (timing != SDMMC_TIMING_LEGACY) {
> @@ -1041,6 +1032,59 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *sc, struct 
> sdmmc_function *sf)
>   return error;
>  }
>  
> +int
> +sdmmc_mem_mmc_select_bus_width(struct sdmmc_softc *sc, struct sdmmc_function 
> *sf,
> +int width)
> +{
> + u_int8_t ext_csd[512];
> + int error, value;
> +
> + switch (width) {
> + case 8:
> + value = EXT_CSD_BUS_WIDTH_8;
> + break;
> + case 4:
> + value = EX

nvme(4): fix prpl sync length

[Patrick Wildt]

Hi,

this call to sync the DMA mem wants to sync N - 1 number of prpl
entries, as the first segment is configured regularly, while the
addresses for the following segments (if more than 2), are in a
special DMA memory.

The code currently removes a single byte, instead of an entry.
This just means that it is syncing more than it should.

ok?

Patrick

diff --git a/sys/dev/ic/nvme.c b/sys/dev/ic/nvme.c
index 62b8e40c626..6db25260ef0 100644
--- a/sys/dev/ic/nvme.c
+++ b/sys/dev/ic/nvme.c
@@ -629,7 +629,7 @@ nvme_scsi_io(struct scsi_xfer *xs, int dir)
bus_dmamap_sync(sc->sc_dmat,
NVME_DMA_MAP(sc->sc_ccb_prpls),
ccb->ccb_prpl_off,
-   sizeof(*ccb->ccb_prpl) * dmap->dm_nsegs - 1,
+   sizeof(*ccb->ccb_prpl) * (dmap->dm_nsegs - 1),
BUS_DMASYNC_PREWRITE);
}
 
@@ -691,7 +691,7 @@ nvme_scsi_io_done(struct nvme_softc *sc, struct nvme_ccb 
*ccb,
bus_dmamap_sync(sc->sc_dmat,
NVME_DMA_MAP(sc->sc_ccb_prpls),
ccb->ccb_prpl_off,
-   sizeof(*ccb->ccb_prpl) * dmap->dm_nsegs - 1,
+   sizeof(*ccb->ccb_prpl) * (dmap->dm_nsegs - 1),
BUS_DMASYNC_POSTWRITE);
}
 

mcx(4): sync only received length on RX

[Patrick Wildt]

Hi,

mcx(4) seems to sync the whole mapsize on processing a received packet.
As far as I know, we usually only sync the actual size that we have
received.  Noticed this when doing bounce buffer tests, seeing that
it copied a lot more data than is necessary.

That's because the RX buffer size is maximum supported MTU, which is
about 9500 bytes or so.  For small packets, or regular 1500 bytes,
this adds overhead.

This change should not change anything for ARM machines that have a
cache coherent PCIe bus or x86.

ok?

Patrick

diff --git a/sys/dev/pci/if_mcx.c b/sys/dev/pci/if_mcx.c
index 38437e54897..065855d46d3 100644
--- a/sys/dev/pci/if_mcx.c
+++ b/sys/dev/pci/if_mcx.c
@@ -6800,20 +6800,20 @@ mcx_process_rx(struct mcx_softc *sc, struct mcx_rx *rx,
 {
struct mcx_slot *ms;
struct mbuf *m;
-   uint32_t flags;
+   uint32_t flags, len;
int slot;
 
+   len = bemtoh32(>cq_byte_cnt);
slot = betoh16(cqe->cq_wqe_count) % (1 << MCX_LOG_RQ_SIZE);
 
ms = >rx_slots[slot];
-   bus_dmamap_sync(sc->sc_dmat, ms->ms_map, 0, ms->ms_map->dm_mapsize,
-   BUS_DMASYNC_POSTREAD);
+   bus_dmamap_sync(sc->sc_dmat, ms->ms_map, 0, len, BUS_DMASYNC_POSTREAD);
bus_dmamap_unload(sc->sc_dmat, ms->ms_map);
 
m = ms->ms_m;
ms->ms_m = NULL;
 
-   m->m_pkthdr.len = m->m_len = bemtoh32(>cq_byte_cnt);
+   m->m_pkthdr.len = m->m_len = len;
 
if (cqe->cq_rx_hash_type) {
m->m_pkthdr.ph_flowid = betoh32(cqe->cq_rx_hash);

Re: amd64: softintr_dispatch: remove kernel lock

[Patrick Wildt]

Am Sat, May 22, 2021 at 02:33:47PM +0200 schrieb Mark Kettenis:
> > Date: Sat, 22 May 2021 11:11:38 +
> > From: Visa Hankala 
> > 
> > On Wed, May 19, 2021 at 05:11:09PM -0500, Scott Cheloha wrote:
> > > Hi,
> > > 
> > > visa@ says I need to unlock softintr_dispatch() before I can
> > > unlock softclock(), so let's do that.
> > > 
> > > Additionally, when we call softintr_disestablish() we want to wait for
> > > the underlying softintr handle to finish running if it is running.
> > > 
> > > We can start with amd64.
> > > 
> > > I think this approach will work:
> > > 
> > > - Keep a pointer to the running softintr, if any, in the queue.  NULL
> > >   the pointer when we return from sih_func().
> > > 
> > > - Take/release the kernel lock if the SI_MPSAFE flag is present when
> > >   we enter/leave sih_func().
> > > 
> > > - If the handle is running when you call softintr_disestablish(), spin
> > >   until the handle isn't running anymore and retry.
> > > 
> > > There is no softintr manpage but I think it is understood that
> > > softintr_disestablish() is only safe to call from a process context,
> > > otherwise you may deadlock.  Maybe we should do splassert(IPL_NONE)?
> > > 
> > > We could probably sleep here instead of spinning.  We'd have to change
> > > every softintr_disestablish() implementation to do that, though.
> > > Otherwise you'd have different behavior on different platforms.
> > 
> > I think your diff does not pay enough attention to the fact that soft
> > interrupts are handled by all CPUs. I think the diff that I posted
> > a while ago [1] is better in that respect.
> > 
> > Two biggest things that I do not like in my original diff are
> > synchronization of handler execution, and use of the SMR barrier.
> > 
> > [1] https://marc.info/?l=openbsd-tech=162092714911609
> > 
> > The kernel lock has guaranteed that at most one CPU is able to run
> > a given soft interrupt handler at a time. My diff used a mutex to
> > prevent concurrent execution. However, it is wasteful to spin. It would
> > be more economical to let the current runner of the handler re-execute
> > the code.
> > 
> > The SMR barrier in softintr_disestablish() was a trick to drain any
> > pending activity. However, it made me feel uneasy because I have not
> > checked every caller of softintr_disestablish(). My main worry is not
> > the latency but unexpected side effects.
> > 
> > Below is a revised diff that improves the above two points.
> > 
> > When a soft interrupt handler is scheduled, it is assigned to a CPU.
> > That CPU will keep running the handler as long as there are pending
> > requests. Once all pending requests have been drained, the CPU
> > relinquishes its hold of the handler. This provides natural
> > serialization.
> > 
> > Now softintr_disestablish() uses spinning for draining activity.
> > I still have slight qualms about this, though, because the feature
> > has not been so explicit before. Integration with witness(4) might be
> > in order.
> > 
> > softintr_disestablish() uses READ_ONCE() to enforce reloading of the
> > value in the busy-wait loop. This way the variable does not need to be
> > volatile. (As yet another option, CPU_BUSY_CYCLE() could always
> > imply memory clobbering, which should make an optimizing compiler
> > redo the load.) For consistency with this READ_ONCE(), WRITE_ONCE() is
> > used whenever the variable is written, excluding the initialization.
> > 
> > The patch uses a single mutex for access serialization. The old code
> > has used one mutex per each soft IPL level, but I am not sure how
> > useful that has been. I think it would be better to have a separate
> > mutex for each CPU. However, the increased code complexity might not
> > be worthwhile at the moment. Even having the per-CPU queues has
> > a whiff of being somewhat overkill.
> 
> A few comments:
> 
> * Looking at amd64 in isolation does not make sense.  Like a lot of MD
>   code in OpenBSD the softintr code was copied from whatever
>   Net/FreeBSD had at the time, with no attempt at unification (it
>   works, check it in, don't go back to clean it up).  However, with
>   powerpc64 and riscv64 we try to do things a little bit better in
>   that area.  So arm64, powerpc64 and riscv64 share the same softintr
>   implementation that already implements softintr_establish_flags()
>   with SOFTINTR_ESTABLISH_MPSAFE.  Now we haven't used that flag
>   anywhere in our tree yet, so the code might be completely busted.
>   But it may make a lot of sense to migrate other architectures to the
>   same codebase.
> 
> * The softintr_disestablish() function isn't used a lot in our tree.
>   It may make sense to postpone worrying about safely disestablishing
>   mpsafe soft interrupts for now and simply panic if someone tries to
>   do this.
> 
> * Wouldn't it make sense for an mpsafe soft interrupt to protect
>   itself from running simultaniously on multiple CPUs?  It probably
>   already needs some sort of lock to protect the 

Re: xhci early enumeration

[Patrick Wildt]

Am Fri, May 21, 2021 at 07:24:59PM +0200 schrieb Mark Kettenis:
> > Date: Fri, 21 May 2021 19:01:39 +0200
> > From: Patrick Wildt 
> > 
> > Am Fri, May 21, 2021 at 06:18:40PM +0200 schrieb Martin Pieuchot:
> > > On 21/05/21(Fri) 10:48, Patrick Wildt wrote:
> > > > Am Wed, May 19, 2021 at 07:15:50AM + schrieb Christian Ludwig:
> > > > > The usb(4) driver allows to enumerate the bus early during boot by
> > > > > setting its driver flags to 0x1 in UKC. This mechanism can enable a 
> > > > > USB
> > > > > console keyboard early during autoconf(9), which can come in handy at
> > > > > times. This needs USB polling mode to work, which is a bit broken. 
> > > > > Here
> > > > > is my attempt to fix it for xhci(4) controllers.
> > > > > 
> > > > > According to the xHCI specification section 4.2 "Host Controller
> > > > > Initalization", the host controller must be fully initialized before
> > > > > descending into device enumeration. Then xhci(4) sends command TRBs to
> > > > > open new pipes during enumeration. They wait for completion using
> > > > > tsleep(). This is bad when in polling mode at boot. And finally, the
> > > > > behavior should be the same on resume as it is at boot. Therefore also
> > > > > enumerate USB devices during resume when the flag is set.
> > > > > 
> > > > > I am specifically looking for tests on xhci controllers with usb(4)
> > > > > flags set to 1 in UKC.
> > > > > 
> > > > > So long,
> > > > > 
> > > > > 
> > > > >  - Christian
> > > > > 
> > > > > 
> > > > > diff --git a/sys/arch/armv7/marvell/mvxhci.c 
> > > > > b/sys/arch/armv7/marvell/mvxhci.c
> > > > > index 38a636fd123..2137f68b816 100644
> > > > > --- a/sys/arch/armv7/marvell/mvxhci.c
> > > > > +++ b/sys/arch/armv7/marvell/mvxhci.c
> > > > > @@ -155,12 +155,12 @@ mvxhci_attach(struct device *parent, struct 
> > > > > device *self, void *aux)
> > > > >   goto disestablish_ret;
> > > > >   }
> > > > >  
> > > > > - /* Attach usb device. */
> > > > > - config_found(self, >sc.sc_bus, usbctlprint);
> > > > > -
> > > > >   /* Now that the stack is ready, config' the HC and enable 
> > > > > interrupts. */
> > > > >   xhci_config(>sc);
> > > > >  
> > > > > + /* Attach usb device. */
> > > > > + config_found(self, >sc.sc_bus, usbctlprint);
> > > > > +
> > > > >   return;
> > > > >  
> > > > >  disestablish_ret:
> > > > > diff --git a/sys/dev/acpi/xhci_acpi.c b/sys/dev/acpi/xhci_acpi.c
> > > > > index 95e69cee896..d762f69a00e 100644
> > > > > --- a/sys/dev/acpi/xhci_acpi.c
> > > > > +++ b/sys/dev/acpi/xhci_acpi.c
> > > > > @@ -112,12 +112,12 @@ xhci_acpi_attach(struct device *parent, struct 
> > > > > device *self, void *aux)
> > > > >   goto disestablish_ret;
> > > > >   }
> > > > >  
> > > > > - /* Attach usb device. */
> > > > > - config_found(self, >sc.sc_bus, usbctlprint);
> > > > > -
> > > > >   /* Now that the stack is ready, config' the HC and enable 
> > > > > interrupts. */
> > > > >   xhci_config(>sc);
> > > > >  
> > > > > + /* Attach usb device. */
> > > > > + config_found(self, >sc.sc_bus, usbctlprint);
> > > > > +
> > > > >   return;
> > > > >  
> > > > >  disestablish_ret:
> > > > > diff --git a/sys/dev/fdt/xhci_fdt.c b/sys/dev/fdt/xhci_fdt.c
> > > > > index 38c976a6b24..84e00bdadc5 100644
> > > > > --- a/sys/dev/fdt/xhci_fdt.c
> > > > > +++ b/sys/dev/fdt/xhci_fdt.c
> > > > > @@ -116,12 +116,12 @@ xhci_fdt_attach(struct device *parent, struct 
> > > > > device *self, void *aux)
> > > > >   goto disestablish_ret;
> > > > >   }
> > > > >  
> > > > > - /* Attach usb device. */
> > > > > - config_found(self, >sc.sc_bus, usbctlprint);
> 

Re: xhci early enumeration

[Patrick Wildt]

Am Fri, May 21, 2021 at 06:18:40PM +0200 schrieb Martin Pieuchot:
> On 21/05/21(Fri) 10:48, Patrick Wildt wrote:
> > Am Wed, May 19, 2021 at 07:15:50AM + schrieb Christian Ludwig:
> > > The usb(4) driver allows to enumerate the bus early during boot by
> > > setting its driver flags to 0x1 in UKC. This mechanism can enable a USB
> > > console keyboard early during autoconf(9), which can come in handy at
> > > times. This needs USB polling mode to work, which is a bit broken. Here
> > > is my attempt to fix it for xhci(4) controllers.
> > > 
> > > According to the xHCI specification section 4.2 "Host Controller
> > > Initalization", the host controller must be fully initialized before
> > > descending into device enumeration. Then xhci(4) sends command TRBs to
> > > open new pipes during enumeration. They wait for completion using
> > > tsleep(). This is bad when in polling mode at boot. And finally, the
> > > behavior should be the same on resume as it is at boot. Therefore also
> > > enumerate USB devices during resume when the flag is set.
> > > 
> > > I am specifically looking for tests on xhci controllers with usb(4)
> > > flags set to 1 in UKC.
> > > 
> > > So long,
> > > 
> > > 
> > >  - Christian
> > > 
> > > 
> > > diff --git a/sys/arch/armv7/marvell/mvxhci.c 
> > > b/sys/arch/armv7/marvell/mvxhci.c
> > > index 38a636fd123..2137f68b816 100644
> > > --- a/sys/arch/armv7/marvell/mvxhci.c
> > > +++ b/sys/arch/armv7/marvell/mvxhci.c
> > > @@ -155,12 +155,12 @@ mvxhci_attach(struct device *parent, struct device 
> > > *self, void *aux)
> > >   goto disestablish_ret;
> > >   }
> > >  
> > > - /* Attach usb device. */
> > > - config_found(self, >sc.sc_bus, usbctlprint);
> > > -
> > >   /* Now that the stack is ready, config' the HC and enable interrupts. */
> > >   xhci_config(>sc);
> > >  
> > > + /* Attach usb device. */
> > > + config_found(self, >sc.sc_bus, usbctlprint);
> > > +
> > >   return;
> > >  
> > >  disestablish_ret:
> > > diff --git a/sys/dev/acpi/xhci_acpi.c b/sys/dev/acpi/xhci_acpi.c
> > > index 95e69cee896..d762f69a00e 100644
> > > --- a/sys/dev/acpi/xhci_acpi.c
> > > +++ b/sys/dev/acpi/xhci_acpi.c
> > > @@ -112,12 +112,12 @@ xhci_acpi_attach(struct device *parent, struct 
> > > device *self, void *aux)
> > >   goto disestablish_ret;
> > >   }
> > >  
> > > - /* Attach usb device. */
> > > - config_found(self, >sc.sc_bus, usbctlprint);
> > > -
> > >   /* Now that the stack is ready, config' the HC and enable interrupts. */
> > >   xhci_config(>sc);
> > >  
> > > + /* Attach usb device. */
> > > + config_found(self, >sc.sc_bus, usbctlprint);
> > > +
> > >   return;
> > >  
> > >  disestablish_ret:
> > > diff --git a/sys/dev/fdt/xhci_fdt.c b/sys/dev/fdt/xhci_fdt.c
> > > index 38c976a6b24..84e00bdadc5 100644
> > > --- a/sys/dev/fdt/xhci_fdt.c
> > > +++ b/sys/dev/fdt/xhci_fdt.c
> > > @@ -116,12 +116,12 @@ xhci_fdt_attach(struct device *parent, struct 
> > > device *self, void *aux)
> > >   goto disestablish_ret;
> > >   }
> > >  
> > > - /* Attach usb device. */
> > > - config_found(self, >sc.sc_bus, usbctlprint);
> > > -
> > >   /* Now that the stack is ready, config' the HC and enable interrupts. */
> > >   xhci_config(>sc);
> 
> > >  
> > > + /* Attach usb device. */
> > > + config_found(self, >sc.sc_bus, usbctlprint);
> > > +
> > >   return;
> > >  
> > >  disestablish_ret:
> > > diff --git a/sys/dev/pci/xhci_pci.c b/sys/dev/pci/xhci_pci.c
> > > index fa3271b0d30..0b46083b705 100644
> > > --- a/sys/dev/pci/xhci_pci.c
> > > +++ b/sys/dev/pci/xhci_pci.c
> > > @@ -195,12 +195,12 @@ xhci_pci_attach(struct device *parent, struct 
> > > device *self, void *aux)
> > >   if (PCI_VENDOR(psc->sc_id) == PCI_VENDOR_INTEL)
> > >   xhci_pci_port_route(psc);
> > >  
> > > - /* Attach usb device. */
> > > - config_found(self, >sc.sc_bus, usbctlprint);
> > > -
> > >   /* Now that the stack is ready, config' the HC and enable interrupts. */
> > >   xhci_config(>sc);
> > >  
> > > + /* Attach usb devi

Re: xhci early enumeration

[Patrick Wildt]

Am Wed, May 19, 2021 at 07:15:50AM + schrieb Christian Ludwig:
> The usb(4) driver allows to enumerate the bus early during boot by
> setting its driver flags to 0x1 in UKC. This mechanism can enable a USB
> console keyboard early during autoconf(9), which can come in handy at
> times. This needs USB polling mode to work, which is a bit broken. Here
> is my attempt to fix it for xhci(4) controllers.
> 
> According to the xHCI specification section 4.2 "Host Controller
> Initalization", the host controller must be fully initialized before
> descending into device enumeration. Then xhci(4) sends command TRBs to
> open new pipes during enumeration. They wait for completion using
> tsleep(). This is bad when in polling mode at boot. And finally, the
> behavior should be the same on resume as it is at boot. Therefore also
> enumerate USB devices during resume when the flag is set.
> 
> I am specifically looking for tests on xhci controllers with usb(4)
> flags set to 1 in UKC.
> 
> So long,
> 
> 
>  - Christian
> 
> 
> diff --git a/sys/arch/armv7/marvell/mvxhci.c b/sys/arch/armv7/marvell/mvxhci.c
> index 38a636fd123..2137f68b816 100644
> --- a/sys/arch/armv7/marvell/mvxhci.c
> +++ b/sys/arch/armv7/marvell/mvxhci.c
> @@ -155,12 +155,12 @@ mvxhci_attach(struct device *parent, struct device 
> *self, void *aux)
>   goto disestablish_ret;
>   }
>  
> - /* Attach usb device. */
> - config_found(self, >sc.sc_bus, usbctlprint);
> -
>   /* Now that the stack is ready, config' the HC and enable interrupts. */
>   xhci_config(>sc);
>  
> + /* Attach usb device. */
> + config_found(self, >sc.sc_bus, usbctlprint);
> +
>   return;
>  
>  disestablish_ret:
> diff --git a/sys/dev/acpi/xhci_acpi.c b/sys/dev/acpi/xhci_acpi.c
> index 95e69cee896..d762f69a00e 100644
> --- a/sys/dev/acpi/xhci_acpi.c
> +++ b/sys/dev/acpi/xhci_acpi.c
> @@ -112,12 +112,12 @@ xhci_acpi_attach(struct device *parent, struct device 
> *self, void *aux)
>   goto disestablish_ret;
>   }
>  
> - /* Attach usb device. */
> - config_found(self, >sc.sc_bus, usbctlprint);
> -
>   /* Now that the stack is ready, config' the HC and enable interrupts. */
>   xhci_config(>sc);
>  
> + /* Attach usb device. */
> + config_found(self, >sc.sc_bus, usbctlprint);
> +
>   return;
>  
>  disestablish_ret:
> diff --git a/sys/dev/fdt/xhci_fdt.c b/sys/dev/fdt/xhci_fdt.c
> index 38c976a6b24..84e00bdadc5 100644
> --- a/sys/dev/fdt/xhci_fdt.c
> +++ b/sys/dev/fdt/xhci_fdt.c
> @@ -116,12 +116,12 @@ xhci_fdt_attach(struct device *parent, struct device 
> *self, void *aux)
>   goto disestablish_ret;
>   }
>  
> - /* Attach usb device. */
> - config_found(self, >sc.sc_bus, usbctlprint);
> -
>   /* Now that the stack is ready, config' the HC and enable interrupts. */
>   xhci_config(>sc);
>  
> + /* Attach usb device. */
> + config_found(self, >sc.sc_bus, usbctlprint);
> +
>   return;
>  
>  disestablish_ret:
> diff --git a/sys/dev/pci/xhci_pci.c b/sys/dev/pci/xhci_pci.c
> index fa3271b0d30..0b46083b705 100644
> --- a/sys/dev/pci/xhci_pci.c
> +++ b/sys/dev/pci/xhci_pci.c
> @@ -195,12 +195,12 @@ xhci_pci_attach(struct device *parent, struct device 
> *self, void *aux)
>   if (PCI_VENDOR(psc->sc_id) == PCI_VENDOR_INTEL)
>   xhci_pci_port_route(psc);
>  
> - /* Attach usb device. */
> - config_found(self, >sc.sc_bus, usbctlprint);
> -
>   /* Now that the stack is ready, config' the HC and enable interrupts. */
>   xhci_config(>sc);
>  
> + /* Attach usb device. */
> + config_found(self, >sc.sc_bus, usbctlprint);
> +
>   return;
>  
>  disestablish_ret:

The interesting thing is that xhci_config() used to be part of
xhci_init() and was explicitly taken out from it to fix a panic
that showed up when enumeration happened afterwards.

https://github.com/openbsd/src/commit/48155c88d2b90737b892a715e56d81bc73254308

Is it possible that this works in polling mode, but not without?

While I agree that moving xhci_config() before enumeration creates
consistency with the others, this change was done deliberately and
we should find out why.

mpi, do you still happen to have the logs or the machine for that
particular issue?

Patrick

> diff --git a/sys/dev/usb/usb.c b/sys/dev/usb/usb.c
> index b8943882d0a..f9aff94bfee 100644
> --- a/sys/dev/usb/usb.c
> +++ b/sys/dev/usb/usb.c
> @@ -911,8 +911,19 @@ usb_activate(struct device *self, int act)
>* hub transfers do not need to sleep.
>*/
>   sc->sc_bus->use_polling++;
> - if (!usb_attach_roothub(sc))
> + if (!usb_attach_roothub(sc)) {
> + struct usbd_device *dev = sc->sc_bus->root_hub;
> +#if 1
> + /*
> +  * Turning this code off will delay attachment of USB 
> devices
> +  * until the USB task thread is running, which means 
> 

Re: move copyout() in DIOCGETSTATES outside of NET_LOCK() and state_lcok

[Patrick Wildt]

Am Thu, May 20, 2021 at 11:28:19AM +0200 schrieb Claudio Jeker:
> On Thu, May 20, 2021 at 09:37:38AM +0200, Martin Pieuchot wrote:
> > On 20/05/21(Thu) 03:23, Alexandr Nedvedicky wrote:
> > > Hrvoje gave a try to experimental diff, which trades rw-locks in pf(4)
> > > for mutexes [1]. Hrvoje soon discovered machine panics, when doing 'pfctl 
> > > -ss'
> > > The callstack looks as follows:
> > >
> > > [...]
> > > specific to experimental diff [1]. However this made me thinking, that
> > > it's not a good idea to do copyout() while holding NET_LOCK() and 
> > > state_lock.
> > 
> > malloc(9) and copyout(9) are kind of ok while using the NET_LOCK() but
> > if a deadlock occurs while a global rwlock is held, debugging becomes
> > harder.
> > 
> > As long as the `state_lock' and PF_LOCK() are mutexes all allocations
> > and copyin/copyout(9) must be done without holding them.
> 
> One way to reduce the problems with copyout(9) is to use uvm_vslock() to
> lock the pages. This is what sysctl does but it comes with its own set of
> issues.
> 
> In general exporting large collections from the kernel needs to be
> rethought. The system should not grab a lock for a long time to
> serve a userland process.
>  
> > > Diff below moves copyout() at line 1784 outside of protection of both 
> > > locks.
> > > The approach I took is relatively straightforward:
> > > 
> > > let DIOCGETSTATES to allocate hold_states array, which will keep
> > > references to states.
> > > 
> > > grab locks and take references, keep those references in hold
> > > array.
> > > 
> > > drop locks, export states and do copyout, while walking
> > > array of references.
> > > 
> > > drop references, release hold_states array.
> > > 
> > > does it make sense? If we agree that this approach makes sense
> > 
> > In my opinion it does.  The other approach would be to (ab)use the
> > NET_LOCK() to serialize updates, like bluhm@'s diff does.  Both
> > approaches have pros and cons.
> > 
> 
> I really think adding more to the NET_LOCK() is a step in the wrong
> direction. It will just creap into everything and grow the size of the
> kernel lock. For me the cons outweight the pros.

While what we do at genua probably isn't particularly relevant to the
OpenBSD approach to unlocking the network subsystem, but what we do is
that there is a rwlock that protects the network configuration, and for
ioctls like DIOCGETSTATES we do indeed call uvm_vslock(), then take the
lock either read or write, depending on which ioctl it is, and unlock it
prior to return.

Since this is only the network conf lock, taking it with a 'read' for
something like DIOCGETSTATES does not really influence the network
receive/transmit path, I think.

hvn(4): don't input mbufs if interface is not running

[Patrick Wildt]

Hi,

when hvn(4) attaches it sends commands and waits for replies to come
back in, hence the interrupt function is being polled.  Unfortunately
it seems that the 'receive pipe' has both command completion and data
packets.  As it turns out, while hvn(4) is just setting up the pipes,
it can already receive packets, which I have seen happening on Hyper-V.

This essentially means that if_input() is being called *before* the
card is set up (or UP).  This seems wrong.  Apparently on drivers like
em(4) we only read packets if IFF_RUNNING is set.  I think in the case
of hvn(4), we should drop packets unless IFF_RUNNING is set.

Opinions?

Patrick

diff --git a/sys/dev/pv/if_hvn.c b/sys/dev/pv/if_hvn.c
index f12e2f935ca..4306f717baf 100644
--- a/sys/dev/pv/if_hvn.c
+++ b/sys/dev/pv/if_hvn.c
@@ -1470,7 +1470,10 @@ hvn_rndis_input(struct hvn_softc *sc, uint64_t tid, void 
*arg)
}
hvn_nvs_ack(sc, tid);
 
-   if_input(ifp, );
+   if (ifp->if_flags & IFF_RUNNING)
+   if_input(ifp, );
+   else
+   ml_purge();
 }
 
 static inline struct mbuf *

enable dt(4)

[Patrick Wildt]

Hi,

as proposed by bluhm@ recently, this is the diff to enable dt(4) in
GENERIC.  The overhead should be small, and I have been using it on
arm64 to successfully debug issues for a while now.

I can't vouch that it builds for all architectures... Did anyone do
that?  Number 1 rule: don't break Theo's build.

Patrick

diff --git a/sys/conf/GENERIC b/sys/conf/GENERIC
index 33d0f368968..c47bea90cde 100644
--- a/sys/conf/GENERIC
+++ b/sys/conf/GENERIC
@@ -82,7 +82,7 @@ pseudo-device msts1   # MSTS line discipline
 pseudo-device  endrun  1   # EndRun line discipline
 pseudo-device  vnd 4   # vnode disk devices
 pseudo-device  ksyms   1   # kernel symbols device
-#pseudo-device dt  # Dynamic Tracer
+pseudo-device  dt  # Dynamic Tracer
 
 # clonable devices
 pseudo-device  bpfilter# packet filter

Re: tmpfs & UVM aobj

[Patrick Wildt]

Am Thu, Apr 22, 2021 at 11:19:22AM +0200 schrieb Martin Pieuchot:
> uao_shrink() and uao_grow() are only used by TMPFS, ok to place them
> under an #ifdef?  This save some bytes on RAMDISKs.

sure, ok patrick@

> Index: uvm/uvm_aobj.c
> ===
> RCS file: /cvs/src/sys/uvm/uvm_aobj.c,v
> retrieving revision 1.94
> diff -u -p -r1.94 uvm_aobj.c
> --- uvm/uvm_aobj.c31 Mar 2021 08:53:39 -  1.94
> +++ uvm/uvm_aobj.c22 Apr 2021 09:00:27 -
> @@ -416,6 +416,7 @@ uao_free(struct uvm_aobj *aobj)
>   * pager functions
>   */
>  
> +#ifdef TMPFS
>  /*
>   * Shrink an aobj to a given number of pages. The procedure is always the 
> same:
>   * assess the necessity of data structure conversion (hash to array), secure
> @@ -692,6 +693,7 @@ uao_grow(struct uvm_object *uobj, int pa
>   else
>   return uao_grow_convert(uobj, pages);
>  }
> +#endif /* TMPFS */
>  
>  /*
>   * uao_create: create an aobj of the given size and return its uvm_object.
> 

Re: Change umb(4) devclass from DV_DULL to DV_IFNET

[Patrick Wildt]

Am Mon, Apr 19, 2021 at 10:25:39AM +0200 schrieb Tilo Stritzky:
> On 10/04/21 22:56  Tilo Stritzky wrote:
> > umb interfaces advertise themselves as generic devices.
> > Network makes a lot more sense, I think.
> > tested on amd64.
> 
> Having seen no response on this one, I'ld like to expand a little
> further.
> 
> This value defines how a device is identified in hotplug events,
> eventually showing up in userland as argv to /etc/hotplug/attach.
> It doesn't seem to be used by the kernel itself.
> 
> Currently umb(4) mobile broadband interfaces identify as ``generic''.
> This is not exactly wrong, but there is a ``network interface'' class
> which is a much tighter match. All other USB network interfaces set
> it to DV_IFNET.
> 
> The change lets me group umb related stuff together with other
> hotplugged network devices in /etc/hotplug/attach.
> 
> Alas, this might break some existing hotplugd setups.
> 
> tilo

That does indeed make sense.  umb(4) is some kind of a network device,
and especially in hotplug I think it makes a lot more sense there as
well.  So, I'm in favour.

Objections?  ok?

> Index: if_umb.c
> ===
> RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
> retrieving revision 1.43
> diff -u -p -r1.43 if_umb.c
> --- if_umb.c  1 Apr 2021 08:39:52 -   1.43
> +++ if_umb.c  10 Apr 2021 20:14:59 -
> @@ -212,7 +212,7 @@ uint8_tumb_uuid_qmi_mbim[] = MBIM_UUI
>  uint32_t  umb_session_id = 0;
> 
>  struct cfdriver umb_cd = {
> - NULL, "umb", DV_DULL
> + NULL, "umb", DV_IFNET
>  };
> 
>  const struct cfattach umb_ca = {
> 
> 
> 
> 
> umb0 at uhub0 port 1 configuration 1 interface 0 "MediaTek Inc Product" rev 
> 2.00/3.00 addr 2
> umsm0 at uhub0 port 1 configuration 1 interface 2 "MediaTek Inc Product" rev 
> 2.00/3.00 addr 2
> ucom0 at umsm0
> umsm1 at uhub0 port 1 configuration 1 interface 3 "MediaTek Inc Product" rev 
> 2.00/3.00 addr 2
> ucom1 at umsm1
> umsm2 at uhub0 port 1 configuration 1 interface 4 "MediaTek Inc Product" rev 
> 2.00/3.00 addr 2
> ucom2 at umsm2
> umsm3 at uhub0 port 1 configuration 1 interface 5 "MediaTek Inc Product" rev 
> 2.00/3.00 addr 2
> ucom3 at umsm3
> umass0 at uhub0 port 1 configuration 1 interface 6 "MediaTek Inc Product" rev 
> 2.00/3.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus2 at umass0: 2 targets, initiator 0
> sd1 at scsibus2 targ 1 lun 0:  removable
> 

Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)

[Patrick Wildt]

Am Thu, Apr 15, 2021 at 12:47:44AM +0200 schrieb Patrick Wildt:
> On Wed, Apr 14, 2021 at 11:20:56PM +0200, Patrick Wildt wrote:
> > Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis:
> > > > Date: Wed, 14 Apr 2021 22:25:16 +0200
> > > > From: Patrick Wildt 
> > > > 
> > > > Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt:
> > > > > Hi,
> > > > > 
> > > > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does
> > > > > provide an EFI 'BIOS', our images boot out of the box (once converted
> > > > > to 'hdd' or supplied as USB stick).
> > > > > 
> > > > > Unfortunately virtio doesn't attach, because Parallels seems to 
> > > > > provide
> > > > > a 'new' version 2.  The following diff adds support for version 2 and
> > > > > I used it to install the VM over vio(4) network.  And I was able to
> > > > > install packages over vio(4) network.  Disk is ahci(4), USB 
> > > > > passthrough
> > > > > is xhci(4), so that works nicely out of the box.
> > > > > 
> > > > > Not sure if we want this for 6.9 or not.  I think it wouldn't break 
> > > > > the
> > > > > current version 1, so I think it shouldn't hurt.
> > > > > 
> > > > > If you're wondering why I'm 'so late' with this: jcs@ asked me to have
> > > > > a look at the official Parallels for M1 release, and I just did that.
> > > > > So I couldn't be any faster than this anyway.
> > > > > 
> > > > > Opinions?
> > > > > 
> > > > > Patrick
> > > > 
> > > > Obviously I forgot to pay dmesg tax ;)
> > > > 
> 
> Things change a little when you run 'machine acpi' in efiboot.

And here's the DSDT (thanks to jcs@).  I think audio (HDEF) should be
easy, I believe we only need to attach Azalia to that device, rest
hopefully 'just works'.  PNP0D20 is ehci, that should be easy as
well.  Not sure about video...  There's also an Ethernet device.

Btw, this is just a bit of ACPI info dump, which is unrelated to this
diff.

/*
 * Intel ACPI Component Architecture
 * AML/ASL+ Disassembler version 20200925 (64-bit version)
 * Copyright (c) 2000 - 2020 Intel Corporation
 * 
 * Disassembling to symbolic ASL+ operators
 *
 * Disassembly of DSDT.2, Wed Apr 14 17:46:36 2021
 *
 * Original Table Header:
 * Signature"DSDT"
 * Length   0x0AC6 (2758)
 * Revision 0x02
 * Checksum 0x9D
 * OEM ID   "PRLS  "
 * OEM Table ID "PRLS_OEM"
 * OEM Revision 0x0003 (3)
 * Compiler ID  "INTL"
 * Compiler Version 0x20160527 (538314023)
 */
DefinitionBlock ("", "DSDT", 2, "PRLS  ", "PRLS_OEM", 0x0003)
{
Scope (_SB)
{
OperationRegion (MBOX, SystemMemory, 0x0210, 0x4000)
Field (MBOX, DWordAcc, NoLock, Preserve)
{
MVER,   32, 
RAM,32, 
CPUM,   32, 
MUSB,   32, 
MUFS,   32, 
MAHC,   32, 
VRAM,   32, 
MSER,   32, 
MHDA,   32, 
GPU,32, 
LOON,   32, 
TOOL,   32, 
NET,32
}

Device (CP00)
{
Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
Name (_UID, Zero)  // _UID: Unique ID
}

Device (CP01)
{
Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
Name (_UID, One)  // _UID: Unique ID
}

Device (CP02)
{
Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
Name (_UID, 0x02)  // _UID: Unique ID
}

Device (CP03)
{
Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
Name (_UID, 0x03)  // _UID: Unique ID
}

Device (CP04)
{
Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
Name (_UID, 0x04)  // _UID: Unique ID
}

Device (CP05)
{
Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
Name (_UID, 0x05)  // _UID: Unique ID
}

Device (CP06)
{
Name (_HID, "ACPI0007" /* Processor Device */)  // _HID: Hardware ID
Name (_UID, 0x06)  // _UID: Unique ID
}

Device (CP07)
{
Name (_HID, "ACPI0007

Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)

[Patrick Wildt]

On Wed, Apr 14, 2021 at 11:20:56PM +0200, Patrick Wildt wrote:
> Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis:
> > > Date: Wed, 14 Apr 2021 22:25:16 +0200
> > > From: Patrick Wildt 
> > > 
> > > Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt:
> > > > Hi,
> > > > 
> > > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does
> > > > provide an EFI 'BIOS', our images boot out of the box (once converted
> > > > to 'hdd' or supplied as USB stick).
> > > > 
> > > > Unfortunately virtio doesn't attach, because Parallels seems to provide
> > > > a 'new' version 2.  The following diff adds support for version 2 and
> > > > I used it to install the VM over vio(4) network.  And I was able to
> > > > install packages over vio(4) network.  Disk is ahci(4), USB passthrough
> > > > is xhci(4), so that works nicely out of the box.
> > > > 
> > > > Not sure if we want this for 6.9 or not.  I think it wouldn't break the
> > > > current version 1, so I think it shouldn't hurt.
> > > > 
> > > > If you're wondering why I'm 'so late' with this: jcs@ asked me to have
> > > > a look at the official Parallels for M1 release, and I just did that.
> > > > So I couldn't be any faster than this anyway.
> > > > 
> > > > Opinions?
> > > > 
> > > > Patrick
> > > 
> > > Obviously I forgot to pay dmesg tax ;)
> > > 

Things change a little when you run 'machine acpi' in efiboot.


OpenBSD 6.9 (GENERIC.MP) #295: Wed Apr 14 22:06:35 CEST 2021
patr...@lx2k.blueri.se:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 516284416 (492MB)
avail mem = 468021248 (446MB)
random: good seed from bootblocks
mainbus0 at root: ACPI
psci0 at mainbus0: PSCI 1.0
cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f
cpu0: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache
cpu0: 12288KB 128b/line 12-way L2 cache
cpu0: 
TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2
cpu1 at mainbus0 mpidr 1: Unknown, MIDR 0x410f
cpu1: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache
cpu1: 12288KB 128b/line 12-way L2 cache
cpu1: 
TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2
efi0 at mainbus0: UEFI 2.7
efi0: EDK II rev 0x1
smbios0 at efi0: SMBIOS 3.0.0
smbios0: vendor Parallels Software International Inc. version "16.5.0 (50692)" 
date Mar 25 2021
smbios0: Parallels Parallels ARM Virtual Machine
apm0 at mainbus0
ampintc0 at mainbus0 nirq 128, ncpu 2 ipi: 0, 1: "interrupt-controller"
agtimer0 at mainbus0: 24000 kHz
acpi0 at mainbus0: ACPI 6.1
acpi0: sleep states
acpi0: tables DSDT FACP DBG2 GTDT APIC
acpi0: wakeup devices
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
"ACPI0007" at acpi0 not configured
acpibtn0 at acpi0: PWRB
acpige0 at acpi0 irq 48
"PRL4005" at acpi0 not configured
"PRL4000" at acpi0 not configured
"PRL4006" at acpi0 not configured
"PRL4009" at acpi0 not configured
"PNP0D20" at acpi0 not configured
ahci0 at acpi0 AHC0 addr 0x214/0x2000 irq 34: AHCI 1.1
ahci0: port 0: 1.5Gb/s
ahci0: port 1: 1.5Gb/s
ahci0: port 2: 1.5Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  
t10.ATA_OpenBSD-0_SSD_SM7VVT660WEM5DW1GGN0
sd0: 65536MB, 512 bytes/sector, 134217728 sectors, thin
sd1 at scsibus0 targ 1 lun 0:  
t10.ATA_miniroot69_NQGN5C6P8H5MSAW6W3PG
sd1: 33MB, 512 bytes/sector, 67584 sectors, thin
cd0 at scsibus0 targ 2 lun 0: <, Virtual DVD-ROM, R103> removable
"ACPI000E" at acpi0 not configured
xhci0 at acpi0 XHC0 addr 0x216/0x1000 irq 36, xHCI 1.10
usb0 at xhci0: USB revision 3.0
uhub0 at usb0 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 
addr 1
simplefb0 at mainbus0: 1024x768, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhidev0 at uhub0 port 1 configuration 1 interface 0 "Parallels Virtual Mouse" 
rev 3.00/1.00 addr 2
uhidev0: iclass 3/0, 1 report id
ums0 at uhidev0 reportid 1: 8 buttons, Z and W dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub0 port 1 configuration 1 interface 1 "Parallels Vi

Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)

[Patrick Wildt]

Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis:
> > Date: Wed, 14 Apr 2021 22:25:16 +0200
> > From: Patrick Wildt 
> > 
> > Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt:
> > > Hi,
> > > 
> > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does
> > > provide an EFI 'BIOS', our images boot out of the box (once converted
> > > to 'hdd' or supplied as USB stick).
> > > 
> > > Unfortunately virtio doesn't attach, because Parallels seems to provide
> > > a 'new' version 2.  The following diff adds support for version 2 and
> > > I used it to install the VM over vio(4) network.  And I was able to
> > > install packages over vio(4) network.  Disk is ahci(4), USB passthrough
> > > is xhci(4), so that works nicely out of the box.
> > > 
> > > Not sure if we want this for 6.9 or not.  I think it wouldn't break the
> > > current version 1, so I think it shouldn't hurt.
> > > 
> > > If you're wondering why I'm 'so late' with this: jcs@ asked me to have
> > > a look at the official Parallels for M1 release, and I just did that.
> > > So I couldn't be any faster than this anyway.
> > > 
> > > Opinions?
> > > 
> > > Patrick
> > 
> > Obviously I forgot to pay dmesg tax ;)
> > 
> > OpenBSD 6.9 (GENERIC.MP) #295: Wed Apr 14 22:06:35 CEST 2021
> > patr...@lx2k.blueri.se:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> > real mem  = 516423680 (492MB)
> > avail mem = 468152320 (446MB)
> > random: boothowto does not indicate good seed
> > mainbus0 at root: Parallels ARM Virtual Machine
> > psci0 at mainbus0: PSCI 1.0
> > cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f
> > cpu0: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache
> > cpu0: 12288KB 128b/line 12-way L2 cache
> > cpu0: 
> > TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2
> > cpu1 at mainbus0 mpidr 1: Unknown, MIDR 0x410f
> > cpu1: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache
> > cpu1: 12288KB 128b/line 12-way L2 cache
> > cpu1: 
> > TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2
> > efi0 at mainbus0: UEFI 2.7
> > efi0: EDK II rev 0x1
> > smbios0 at efi0: SMBIOS 3.0.0
> > smbios0: vendor Parallels Software International Inc. version "16.5.0 
> > (50692)" date Mar 25 2021
> > smbios0: Parallels Parallels ARM Virtual Machine
> > apm0 at mainbus0
> > ampintc0 at mainbus0 nirq 128, ncpu 2 ipi: 0, 1: "interrupt-controller"
> > agtimer0 at mainbus0: 24000 kHz
> > "soc" at mainbus0 not configured
> > "clk24mhz" at mainbus0 not configured
> > pluart0 at mainbus0
> > ahci0 at mainbus0: AHCI 1.1
> > ahci0: port 0: 1.5Gb/s
> > ahci0: port 1: 1.5Gb/s
> > scsibus0 at ahci0: 32 targets
> > sd0 at scsibus0 targ 0 lun 0:  
> > t10.ATA_OpenBSD-0_SSD_Y15J1M1AG4B4S7VMR61V
> > sd0: 8192MB, 512 bytes/sector, 16777216 sectors, thin
> > sd1 at scsibus0 targ 1 lun 0:  
> > t10.ATA_miniroot69_NQGN5C6P8H5MSAW6W3PG
> > sd1: 33MB, 512 bytes/sector, 67584 sectors, thin
> > ehci0 at mainbus0
> > usb0 at ehci0: USB revision 2.0
> > uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 
> > 2.00/1.00 addr 1
> > xhci0 at mainbus0, xHCI 1.10
> > usb1 at xhci0: USB revision 3.0
> > uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 
> > 3.00/1.00 addr 1
> > "gpu" at mainbus0 not configured
> > "toolgate" at mainbus0 not configured
> > virtio0 at mainbus0: Virtio Memory Balloon Device
> > viomb0 at virtio0
> > virtio1 at mainbus0: Virtio Network Device
> > vio0 at virtio1: address 00:1c:42:8a:67:34
> > simplefb0 at mainbus0: 1024x768, 32bpp
> > wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
> > wsdisplay0: screen 1-5 added (std, vt100 emulation)
> > uhidev0 at uhub1 port 1 configuration 1 interface 0 "Parallels Virtual 
> > Mouse" rev 3.00/1.00 addr 2
> > uhidev0: iclass 3/0, 1 report id
> > ums0 at uhidev0 reportid 1: 8 buttons, Z and W dir
> > wsmouse0 at ums0 mux 0
> > uhidev1 at uhub1 port 1 configuration 1 interface 1 "Parallels Virtual 
> > Mouse" rev 3.00/1.00 addr 2
> > u

Re: virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)

[Patrick Wildt]

Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt:
> Hi,
> 
> Parallels 16 for Mac supports the Apple M1 SoC now, and since it does
> provide an EFI 'BIOS', our images boot out of the box (once converted
> to 'hdd' or supplied as USB stick).
> 
> Unfortunately virtio doesn't attach, because Parallels seems to provide
> a 'new' version 2.  The following diff adds support for version 2 and
> I used it to install the VM over vio(4) network.  And I was able to
> install packages over vio(4) network.  Disk is ahci(4), USB passthrough
> is xhci(4), so that works nicely out of the box.
> 
> Not sure if we want this for 6.9 or not.  I think it wouldn't break the
> current version 1, so I think it shouldn't hurt.
> 
> If you're wondering why I'm 'so late' with this: jcs@ asked me to have
> a look at the official Parallels for M1 release, and I just did that.
> So I couldn't be any faster than this anyway.
> 
> Opinions?
> 
> Patrick

Obviously I forgot to pay dmesg tax ;)

OpenBSD 6.9 (GENERIC.MP) #295: Wed Apr 14 22:06:35 CEST 2021
patr...@lx2k.blueri.se:/usr/src/sys/arch/arm64/compile/GENERIC.MP
real mem  = 516423680 (492MB)
avail mem = 468152320 (446MB)
random: boothowto does not indicate good seed
mainbus0 at root: Parallels ARM Virtual Machine
psci0 at mainbus0: PSCI 1.0
cpu0 at mainbus0 mpidr 0: Unknown, MIDR 0x410f
cpu0: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache
cpu0: 12288KB 128b/line 12-way L2 cache
cpu0: 
TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2
cpu1 at mainbus0 mpidr 1: Unknown, MIDR 0x410f
cpu1: 192KB 64b/line 6-way L1 PIPT I-cache, 128KB 64b/line 8-way L1 D-cache
cpu1: 12288KB 128b/line 12-way L2 cache
cpu1: 
TLBIOS+IRANGE,TS+AXFLAG,FHM,DP,SHA3,RDM,Atomic,CRC32,SHA2+SHA512,SHA1,AES+PMULL,SPECRES,SB,FRINTTS,GPI,LRCPC+LDAPUR,FCMA,JSCVT,API+PAC,DPB,SpecSEI,PAN+ATS1E1,LO,HPDS,CSV3,CSV2
efi0 at mainbus0: UEFI 2.7
efi0: EDK II rev 0x1
smbios0 at efi0: SMBIOS 3.0.0
smbios0: vendor Parallels Software International Inc. version "16.5.0 (50692)" 
date Mar 25 2021
smbios0: Parallels Parallels ARM Virtual Machine
apm0 at mainbus0
ampintc0 at mainbus0 nirq 128, ncpu 2 ipi: 0, 1: "interrupt-controller"
agtimer0 at mainbus0: 24000 kHz
"soc" at mainbus0 not configured
"clk24mhz" at mainbus0 not configured
pluart0 at mainbus0
ahci0 at mainbus0: AHCI 1.1
ahci0: port 0: 1.5Gb/s
ahci0: port 1: 1.5Gb/s
scsibus0 at ahci0: 32 targets
sd0 at scsibus0 targ 0 lun 0:  
t10.ATA_OpenBSD-0_SSD_Y15J1M1AG4B4S7VMR61V
sd0: 8192MB, 512 bytes/sector, 16777216 sectors, thin
sd1 at scsibus0 targ 1 lun 0:  
t10.ATA_miniroot69_NQGN5C6P8H5MSAW6W3PG
sd1: 33MB, 512 bytes/sector, 67584 sectors, thin
ehci0 at mainbus0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Generic EHCI root hub" rev 2.00/1.00 
addr 1
xhci0 at mainbus0, xHCI 1.10
usb1 at xhci0: USB revision 3.0
uhub1 at usb1 configuration 1 interface 0 "Generic xHCI root hub" rev 3.00/1.00 
addr 1
"gpu" at mainbus0 not configured
"toolgate" at mainbus0 not configured
virtio0 at mainbus0: Virtio Memory Balloon Device
viomb0 at virtio0
virtio1 at mainbus0: Virtio Network Device
vio0 at virtio1: address 00:1c:42:8a:67:34
simplefb0 at mainbus0: 1024x768, 32bpp
wsdisplay0 at simplefb0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
uhidev0 at uhub1 port 1 configuration 1 interface 0 "Parallels Virtual Mouse" 
rev 3.00/1.00 addr 2
uhidev0: iclass 3/0, 1 report id
ums0 at uhidev0 reportid 1: 8 buttons, Z and W dir
wsmouse0 at ums0 mux 0
uhidev1 at uhub1 port 1 configuration 1 interface 1 "Parallels Virtual Mouse" 
rev 3.00/1.00 addr 2
uhidev1: iclass 3/0, 2 report ids
ums1 at uhidev1 reportid 2: 8 buttons, Z and W dir
wsmouse1 at ums1 mux 0
uhidev2 at uhub1 port 2 configuration 1 interface 0 "Parallels Virtual 
Keyboard" rev 3.00/1.00 addr 3
uhidev2: iclass 3/1
ukbd0 at uhidev2: 8 variable keys, 5 key codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uvideo0 at uhub1 port 3 configuration 1 interface 0 "Parallels FaceTime HD 
Camera" rev 3.10/1.00 addr 4
video0 at uvideo0
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
root on sd0a (4a24f1a721df244f.a) swap on sd0b dump on sd0b
Automatic boot in progress: starting file system checks.
/dev/sd0a (4a24f1a721df244f.a): file system is clean; not checking
/dev/sd0e (4a24f1a721df244f.e): file system is clean; not checking
/dev/sd0d (4a24f1a721df244f.d): file system is clean; not checking
pf enabled
starting network
vio0: 10.211.55.4 lease accepted from 10.211.55.1 (00:1c:42:00:00:18)
reordering libraries: done.
starting early daemons: syslogd pflo

virtio(4) at fdt: version 2 for Parallels 16 on Mac (M1)

[Patrick Wildt]

Hi,

Parallels 16 for Mac supports the Apple M1 SoC now, and since it does
provide an EFI 'BIOS', our images boot out of the box (once converted
to 'hdd' or supplied as USB stick).

Unfortunately virtio doesn't attach, because Parallels seems to provide
a 'new' version 2.  The following diff adds support for version 2 and
I used it to install the VM over vio(4) network.  And I was able to
install packages over vio(4) network.  Disk is ahci(4), USB passthrough
is xhci(4), so that works nicely out of the box.

Not sure if we want this for 6.9 or not.  I think it wouldn't break the
current version 1, so I think it shouldn't hurt.

If you're wondering why I'm 'so late' with this: jcs@ asked me to have
a look at the official Parallels for M1 release, and I just did that.
So I couldn't be any faster than this anyway.

Opinions?

Patrick

diff --git a/sys/dev/fdt/virtio_mmio.c b/sys/dev/fdt/virtio_mmio.c
index 88e45436c00..e474bad9e6b 100644
--- a/sys/dev/fdt/virtio_mmio.c
+++ b/sys/dev/fdt/virtio_mmio.c
@@ -58,10 +58,17 @@
 #define VIRTIO_MMIO_QUEUE_NUM  0x038
 #define VIRTIO_MMIO_QUEUE_ALIGN0x03c
 #define VIRTIO_MMIO_QUEUE_PFN  0x040
+#define VIRTIO_MMIO_QUEUE_READY0x044
 #define VIRTIO_MMIO_QUEUE_NOTIFY   0x050
 #define VIRTIO_MMIO_INTERRUPT_STATUS   0x060
 #define VIRTIO_MMIO_INTERRUPT_ACK  0x064
 #define VIRTIO_MMIO_STATUS 0x070
+#define VIRTIO_MMIO_QUEUE_DESC_LOW 0x080
+#define VIRTIO_MMIO_QUEUE_DESC_HIGH0x084
+#define VIRTIO_MMIO_QUEUE_AVAIL_LOW0x090
+#define VIRTIO_MMIO_QUEUE_AVAIL_HIGH   0x094
+#define VIRTIO_MMIO_QUEUE_USED_LOW 0x0a0
+#define VIRTIO_MMIO_QUEUE_USED_HIGH0x0a4
 #define VIRTIO_MMIO_CONFIG 0x100
 
 #define VIRTIO_MMIO_INT_VRING  (1 << 0)
@@ -106,6 +113,7 @@ struct virtio_mmio_softc {
void*sc_ih;
 
int sc_config_offset;
+   uint32_tsc_version;
 };
 
 struct cfattach virtio_mmio_ca = {
@@ -159,10 +167,31 @@ virtio_mmio_setup_queue(struct virtio_softc *vsc, struct 
virtqueue *vq,
vq->vq_index);
bus_space_write_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_QUEUE_NUM,
bus_space_read_4(sc->sc_iot, sc->sc_ioh, 
VIRTIO_MMIO_QUEUE_NUM_MAX));
-   bus_space_write_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_QUEUE_ALIGN,
-   PAGE_SIZE);
-   bus_space_write_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_QUEUE_PFN,
-   addr / VIRTIO_PAGE_SIZE);
+   if (sc->sc_version == 1) {
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_ALIGN, PAGE_SIZE);
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_PFN, addr / VIRTIO_PAGE_SIZE);
+   } else {
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_DESC_LOW, addr);
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_DESC_HIGH, addr >> 32);
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_AVAIL_LOW,
+   addr + vq->vq_availoffset);
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_AVAIL_HIGH,
+   (addr + vq->vq_availoffset) >> 32);
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_USED_LOW,
+   addr + vq->vq_usedoffset);
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_USED_HIGH,
+   (addr + vq->vq_usedoffset) >> 32);
+   bus_space_write_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_QUEUE_READY, 1);
+   }
 }
 
 void
@@ -192,7 +221,7 @@ virtio_mmio_attach(struct device *parent, struct device 
*self, void *aux)
struct fdt_attach_args *faa = aux;
struct virtio_mmio_softc *sc = (struct virtio_mmio_softc *)self;
struct virtio_softc *vsc = >sc_sc;
-   uint32_t id, magic, version;
+   uint32_t id, magic;
 
if (faa->fa_nreg < 1) {
printf(": no register data\n");
@@ -213,17 +242,19 @@ virtio_mmio_attach(struct device *parent, struct device 
*self, void *aux)
return;
}
 
-   version = bus_space_read_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_VERSION);
-   if (version != 1) {
-   printf(": unknown version 0x%02x; giving up\n", version);
+   sc->sc_version = bus_space_read_4(sc->sc_iot, sc->sc_ioh,
+   VIRTIO_MMIO_VERSION);
+   if (sc->sc_version < 1 || sc->sc_version > 2) {
+   printf(": unknown version 0x%02x; giving up\n", sc->sc_version);
return;
}
 
id = bus_space_read_4(sc->sc_iot, sc->sc_ioh, VIRTIO_MMIO_DEVICE_ID);
printf(": Virtio %s Device", virtio_device_string(id));
 
-   bus_space_write_4(sc->sc_iot, sc->sc_ioh, 

Re: uvideo(4) new quirk flag UVIDEO_FLAG_NOATTACH

[Patrick Wildt]

Am Mon, Apr 05, 2021 at 11:19:02PM +0200 schrieb Mark Kettenis:
> > Date: Mon, 5 Apr 2021 23:15:23 +0200
> > From: Marcus Glocker 
> > 
> > On Mon, Apr 05, 2021 at 07:30:43AM -0700, Greg Steuck wrote:
> > 
> > > OK gnezdo with a usability question inline.
> > 
> > Thanks.  See below.
> >  
> > > Marcus Glocker  writes:
> > > 
> > > > martijn@ has recently reported that in his machine he has two cams
> > > > of which one is doing IR, which isn't really supported by uvideo(4).
> > > > This IR device attaches always first as uvideo0, so he needs to swap
> > > > that regularly with his working cam which by default attaches to 
> > > > uvideo1.
> > > >
> > > > I came up with a new quirk flag to *not* attach certain devices.  Tested
> > > > successfully by martijn@, the IR cam attaches to ugen0 and the supported
> > > > cam to uvideo0.
> > > >
> > > > This patch shouldn't affect any supported uvideo(4) devices.
> > > >
> > > > OK?
> > > >
> > > > Index: sys/dev/usb/uvideo.c
> > > > ===
> > > > RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
> > > > retrieving revision 1.211
> > > > diff -u -p -u -p -r1.211 uvideo.c
> > > > --- sys/dev/usb/uvideo.c27 Jan 2021 17:28:19 -  1.211
> > > > +++ sys/dev/usb/uvideo.c8 Mar 2021 22:06:51 -
> > > > @@ -307,6 +307,7 @@ struct video_hw_if uvideo_hw_if = {
> > > >  #define UVIDEO_FLAG_ISIGHT_STREAM_HEADER   0x1
> > > >  #define UVIDEO_FLAG_REATTACH   0x2
> > > >  #define UVIDEO_FLAG_VENDOR_CLASS   0x4
> > > > +#define UVIDEO_FLAG_NOATTACH   0x8
> > > >  struct uvideo_devs {
> > > > struct usb_devno uv_dev;
> > > > char*ucode_name;
> > > > @@ -382,6 +383,12 @@ struct uvideo_devs {
> > > > NULL,
> > > > UVIDEO_FLAG_VENDOR_CLASS
> > > > },
> > > > +   {   /* Infrared camera not supported */
> > > > +   { USB_VENDOR_CHICONY, USB_PRODUCT_CHICONY_IRCAMERA },
> > > > +   NULL,
> > > > +   NULL,
> > > > +   UVIDEO_FLAG_NOATTACH
> > > > +   },
> > > >  };
> > > >  #define uvideo_lookup(v, p) \
> > > > ((struct uvideo_devs *)usb_lookup(uvideo_devs, v, p))
> > > > @@ -480,13 +487,12 @@ uvideo_match(struct device *parent, void
> > > > if (id == NULL)
> > > > return (UMATCH_NONE);
> > > >  
> > > > -   if (id->bInterfaceClass == UICLASS_VIDEO &&
> > > > -   id->bInterfaceSubClass == UISUBCLASS_VIDEOCONTROL)
> > > > -   return (UMATCH_VENDOR_PRODUCT_CONF_IFACE);
> > > > -
> > > > -   /* quirk devices which we want to attach */
> > > > +   /* quirk devices */
> > > > quirk = uvideo_lookup(uaa->vendor, uaa->product);
> > > > if (quirk != NULL) {
> > > > +   if (quirk->flags & UVIDEO_FLAG_NOATTACH)
> > > 
> > > How common is it to explain the system behavior in cases like this?
> > > Would it be less surprising (generate less misc@ traffic) if we printed
> > > a note explaining why the camera was skipped?
> > 
> > I wouldn't print a specific message per unsupported device, but I think
> > a generic message that the video device isn't supported would make
> > sense.  Something like that maybe?  Obviously this can print more than
> > once, but I'm not sure if it's worth to make that a unique print.
> > 
> > E.g.:
> > 
> > vmm0 at mainbus0: VMX/EPT
> > uvideo: device 13d3:56b2 isn't supported
> > uvideo: device 13d3:56b2 isn't supported
> > ugen0 at uhub0 port 8 "SunplusIT Inc Integrated Camera" rev 2.01/17.11 addr 
> > 2
> 
> No; match functions shouldn't print stuff.

Agreed.  If something like that was wanted, I'd rather have uvideo(4)
attach, but print that it's not supported, and then not attach video(4)
to it.

> 
> > Index: sys/dev/usb/uvideo.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/uvideo.c,v
> > retrieving revision 1.212
> > diff -u -p -u -p -r1.212 uvideo.c
> > --- sys/dev/usb/uvideo.c5 Apr 2021 20:45:49 -   1.212
> > +++ sys/dev/usb/uvideo.c5 Apr 2021 21:09:36 -
> > @@ -490,8 +490,11 @@ uvideo_match(struct device *parent, void
> > /* quirk devices */
> > quirk = uvideo_lookup(uaa->vendor, uaa->product);
> > if (quirk != NULL) {
> > -   if (quirk->flags & UVIDEO_FLAG_NOATTACH)
> > +   if (quirk->flags & UVIDEO_FLAG_NOATTACH) {
> > +   printf("uvideo: device %x:%x isn't supported\n",
> > +   uaa->vendor, uaa->product);
> > return (UMATCH_NONE);
> > +   }
> >  
> > if (quirk->flags & UVIDEO_FLAG_REATTACH)
> > return (UMATCH_VENDOR_PRODUCT_CONF_IFACE);
> > 
> > 
> 

Re: simpleaudio: set sysclk before using it

[Patrick Wildt]

Am Sun, Apr 04, 2021 at 11:17:54PM +0200 schrieb Mark Kettenis:
> > Date: Sun, 4 Apr 2021 22:24:57 +0200
> > From: Klemens Nanni 
> > Cc: Mark Kettenis 
> > 
> > On Sun, Apr 04, 2021 at 10:01:50PM +0200, Mark Kettenis wrote:
> > > > Date: Sun, 4 Apr 2021 21:08:09 +0200
> > > > From: Klemens Nanni 
> > > > 
> > > > Feedback? Objections? OK?
> > > 
> > > Explanation?
> > > 
> > > Not sure what happened here, but the reply-to was completely garbled...
> > Sorry, I must've crippled the body before sending.
> > 
> > simpleaudio_set_params() calls set_params() which reads sysclk off the
> > "i2s_clk" property before it sets that very clock's dd_set_sysclk()
> > (in case there's multiplier specified).
> > 
> > Hence reverse the order so set_params() picks up the newly set rate.
> > 
> > The rate is still off on the Pinebook Pro, but I came across this when
> > reading the code and it seemed wrong, so I also checked NetBSD which did
> > the same with
> > 
> > sys/dev/fdt/ausoc.c r1.6
> > "Set sysclk rate at set_format time, so the link set_format callback can 
> > read the new sysclk"
> > https://github.com/NetBSD/src/commit/ac8f47d1e5f46949b081c8e9d95211cdfda1e327
> 
> OK. So NetBSD's _set_format() is the equivalent of our _set_params().
> So changing the order makes us match how NetBSD does things.  That
> makes some sense.
> 
> ok kettenis@, but give Patrick a chance to comment as well.
> 

ok patrick@

> 
> > Index: dev/fdt/simpleaudio.c
> > ===
> > RCS file: /cvs/src/sys/dev/fdt/simpleaudio.c,v
> > retrieving revision 1.1
> > diff -u -p -r1.1 simpleaudio.c
> > --- dev/fdt/simpleaudio.c   10 Jun 2020 23:55:19 -  1.1
> > +++ dev/fdt/simpleaudio.c   4 Apr 2021 20:23:39 -
> > @@ -300,24 +300,6 @@ simpleaudio_set_params(void *cookie, int
> > uint32_t rate;
> > int error;
> >  
> > -   dai = sc->sc_dai_cpu;
> > -   hwif = dai->dd_hw_if;
> > -   if (hwif->set_params) {
> > -   error = hwif->set_params(dai->dd_cookie,
> > -   setmode, usemode, play, rec);
> > -   if (error)
> > -   return error;
> > -   }
> > -
> > -   dai = sc->sc_dai_codec;
> > -   hwif = dai->dd_hw_if;
> > -   if (hwif->set_params) {
> > -   error = hwif->set_params(dai->dd_cookie,
> > -   setmode, usemode, play, rec);
> > -   if (error)
> > -   return error;
> > -   }
> > -
> > if (sc->sc_mclk_fs) {
> > if (setmode & AUMODE_PLAY)
> > rate = play->sample_rate * sc->sc_mclk_fs;
> > @@ -337,6 +319,24 @@ simpleaudio_set_params(void *cookie, int
> > if (error)
> > return error;
> > }
> > +   }
> > +
> > +   dai = sc->sc_dai_cpu;
> > +   hwif = dai->dd_hw_if;
> > +   if (hwif->set_params) {
> > +   error = hwif->set_params(dai->dd_cookie,
> > +   setmode, usemode, play, rec);
> > +   if (error)
> > +   return error;
> > +   }
> > +
> > +   dai = sc->sc_dai_codec;
> > +   hwif = dai->dd_hw_if;
> > +   if (hwif->set_params) {
> > +   error = hwif->set_params(dai->dd_cookie,
> > +   setmode, usemode, play, rec);
> > +   if (error)
> > +   return error;
> > }
> >  
> > return 0;
> > 
> 

Re: cwfg: Use meaningful alert level, track apm's battery state better

[Patrick Wildt]

Am Mon, Mar 29, 2021 at 07:16:18AM +0200 schrieb Klemens Nanni:
> The datasheet says the hardware's default State-Of-Charge threshold is
> three percent, i.e. the gauge pulls down the pin to logic low at 3%
> remaining battery life.
> 
> My Pinebook Pro's fuel gauge actually shows an alert level of zero
> percent however and the latest device tree (both from our dtb package
> and other sources) no longer provide the "cellwise,alert-level"
> property.

If there's no alert-level property, then maybe we should just remove it.
Then you could hard code a value for "below will be critical", like you
now do with the 50%?

> The current code still looks for that property but falls back to the
> define;  crank it such that apm(8) does not always report "high" battery
> state.
> 
> While here, use all three available states in the same way acpibat(4)
> sys/dev/acpi/acpi.c does.
> 
> Feedback? OK?
> 
> Index: cwfg.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/cwfg.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 cwfg.c
> --- cwfg.c26 Mar 2021 22:54:41 -  1.4
> +++ cwfg.c29 Mar 2021 05:03:58 -
> @@ -101,7 +101,7 @@ struct cwfg_softc {
>  
>  #define  CWFG_MONITOR_INTERVAL_DEFAULT   5000
>  #define  CWFG_DESIGN_CAPACITY_DEFAULT2000
> -#define  CWFG_ALERT_LEVEL_DEFAULT0
> +#define  CWFG_ALERT_LEVEL_DEFAULT25
>  
>  int cwfg_match(struct device *, void *, void *);
>  void cwfg_attach(struct device *, struct device *, void *);
> @@ -387,9 +387,13 @@ cwfg_update_sensors(void *arg)
>   sc->sc_sensor[CWFG_SENSOR_SOC].value = val * 1000;
>   sc->sc_sensor[CWFG_SENSOR_SOC].flags &= ~SENSOR_FINVALID;
>  #if NAPM > 0
> - cwfg_power.battery_state = val > sc->sc_alert_level ?
> - APM_BATT_HIGH : APM_BATT_LOW;
>   cwfg_power.battery_life = val;
> + if (val > 50)
> + cwfg_power.battery_state = APM_BATT_HIGH;
> + else if (val > sc->sc_alert_level)
> + cwfg_power.battery_state = APM_BATT_LOW;
> + else
> + cwfg_power.battery_state = APM_BATT_CRITICAL;
>  #endif
>   }
>  
> 

Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)

[Patrick Wildt]

Am Sun, Mar 28, 2021 at 10:53:53AM +0100 schrieb Stuart Henderson:
> On 2021/03/25 00:14, Stuart Henderson wrote:
> > On 2021/03/25 00:30, Patrick Wildt wrote:
> > > Without having looked at anything, it might be worth looking at the most
> > > recent mail in this thread:
> > > 
> > > 'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'
> > > 
> > 
> > oh, usb runs through all drivers looking for a VID/PID match before
> > then running through all looking for a class match? I didn't realise
> > (thought it would try driver-by-driver with first VID/PID then class)
> > but that does make sense.
> > 
> > Updated diff below adding my pid/vid and tweaking some comments. My card
> > attaches to umb with this. I've only added it commented-out to the manual
> > for now until I see it actually pass traffic.
> > 
> > So this fixes Bryan's, at least improves mine (will look for another
> > sim / sim-adapter tomorrow), and seems targetted enough to not risk
> > fallout with existing working devices.
> > 
> > I think this makes sense to commit. OK with me if you'd like to commit
> > it Gerhard (I think it was your diff originally).
> 
> So this isn't enough for the Huawei yet but it doesn't make things
> any worse, and helps for DW5821e.
> 
> If Gerhard isn't around, can I commit this bit so I'm not wrangling
> things which should be separate commits? OK?

Yes, please do.  ok patrick@

> > I added this product to usbdevs as a short string; the other Huawei
> > devices all say "HUAWEI Mobile xyz" rather than just "xyz" in the device
> > string which I think should be trimmed as well, probably worth doing
> > that on top.
> > 
> > 
> > Index: share/man/man4/umb.4
> > ===
> > RCS file: /cvs/src/share/man/man4/umb.4,v
> > retrieving revision 1.11
> > diff -u -p -r1.11 umb.4
> > --- share/man/man4/umb.412 May 2020 13:03:52 -  1.11
> > +++ share/man/man4/umb.425 Mar 2021 00:03:58 -
> > @@ -44,8 +44,10 @@ PIN again even if the system was reboote
> >  The following devices should work:
> >  .Pp
> >  .Bl -tag -width Ds -offset indent -compact
> > +.It Dell DW5821e
> >  .It Ericsson H5321gw and N5321gw
> >  .It Fibocom L831-EAU
> > +.\" .It Huawei ME906s -- attaches but may need more work
> >  .It Medion Mobile S4222 (MediaTek OEM)
> >  .It Sierra Wireless EM7345
> >  .It Sierra Wireless EM7455
> > Index: sys/dev/usb/if_umb.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/if_umb.c,v
> > retrieving revision 1.37
> > diff -u -p -r1.37 if_umb.c
> > --- sys/dev/usb/if_umb.c29 Jan 2021 17:06:19 -  1.37
> > +++ sys/dev/usb/if_umb.c24 Mar 2021 23:52:13 -
> > @@ -225,6 +225,28 @@ const struct cfattach umb_ca = {
> >  int umb_delay = 4000;
> >  
> >  /*
> > + * Normally, MBIM devices are detected by their interface class and 
> > subclass.
> > + * But for some models that have multiple configurations, it is better to
> > + * match by vendor and product id so that we can select the desired
> > + * configuration ourselves, e.g. to override a class-based match to another
> > + * driver.
> > + *
> > + * OTOH, some devices identify themselves as an MBIM device but fail to 
> > speak
> > + * the MBIM protocol.
> > + */
> > +struct umb_products {
> > +   struct usb_devno dev;
> > +   int  confno;
> > +};
> > +const struct umb_products umb_devs[] = {
> > +   { { USB_VENDOR_DELL, USB_PRODUCT_DELL_DW5821E }, 2 },
> > +   { { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_ME906S }, 3 },
> > +};
> > +
> > +#define umb_lookup(vid, pid)   \
> > +   ((const struct umb_products *)usb_lookup(umb_devs, vid, pid))
> > +
> > +/*
> >   * These devices require an "FCC Authentication" command.
> >   */
> >  const struct usb_devno umb_fccauth_devs[] = {
> > @@ -263,6 +285,8 @@ umb_match(struct device *parent, void *m
> > struct usb_attach_arg *uaa = aux;
> > usb_interface_descriptor_t *id;
> >  
> > +   if (umb_lookup(uaa->vendor, uaa->product) != NULL)
> > +   return UMATCH_VENDOR_PRODUCT;
> > if (!uaa->iface)
> > return UMATCH_NONE;
> > if ((id = usbd_get_interface_descriptor(uaa->iface)) == NULL)
> > @@ -315,6 +339,43 @@ umb_attach(struct device *parent, struct
> > sc->s

Re: cwfg: flag sensor as invalid on bogus reads

[Patrick Wildt]

Am Sat, Mar 27, 2021 at 12:00:32AM +0100 schrieb Klemens Nanni:
> On Fri, Mar 26, 2021 at 11:22:32PM +0100, Patrick Wildt wrote:
> > It's pretty normal for voltage to go up once AC is connected.  In the
> > end, afaik batteries are charged by applying voltage.  Additionally
> > if an external supply provides power, there's a smaller voltage drop.
> I thought as much, thanks.
> 
> > The "remaining battery time" to become invalid makes sense as well,
> > I mean, with an AC it's gonna be endless and there's no way to measure
> > the battery change.  Well, the only thing it could maybe try and
> > estimate is time until charged.
> That's stuff for another diff (perhaps;  I've heard guessing estimates
> is hard).
> 
> > What happens to battery percentage?  Does it change while it's charging?
> >
> > As mentioned, connecting the charger will make the voltage go up, but
> > the battery charge will not have changed, hence I expect the percentage
> > to stay the same value, even though the voltage changes.  But with time,
> > percentage should go up.
> the `percent0' values does increase steadily over time while AC is
> plugged in.

Cool, that's what I'd hope it does.  So voltage goes up as expected,
remaining battery is invalid (because it's on AC), and the percentage
goes up.  Sounds good to me. :)

> > > @@ -348,9 +348,12 @@ cwfg_update_sensors(void *arg)
> > >   uint8_t val;
> > >   int error, n;
> > >  
> > > -#if NAPM > 0
> > > - /* reset previous reads so apm(4) never gets stale values
> > > + /* invalidate all previous reads to avoid stale/incoherent values
> > >* in case of transient cwfg_read() failures below */
> > > + sc->sc_sensor[CWFG_SENSOR_VCELL].flags |= SENSOR_FINVALID;
> > > + sc->sc_sensor[CWFG_SENSOR_SOC].flags |= SENSOR_FINVALID;
> > > + sc->sc_sensor[CWFG_SENSOR_RTT].flags |= SENSOR_FINVALID;
> > 
> > I'd probably put a newline here, but that's just personal nitpicking.
> Sure, committed with it.
> 
> > I think it makes sense that outdated information should be marked
> > invalid.  Doing that upfront makes sense.  Doing it for VCELL is
> > not strictly necessary, but makes sense for consistency.
> I did this for consistency, yes.
> 

Re: efiboot/arm64: fix "mach dtb" return code to avoid bogus boot

[Patrick Wildt]

Am Sat, Mar 27, 2021 at 12:09:25AM +0100 schrieb Klemens Nanni:
> On Fri, Mar 26, 2021 at 11:28:37PM +0100, Patrick Wildt wrote:
> > >   fdt = (void *)addr;
> > > - return (0);
> > > + return (1);
> > 
> > Wait, you've been saying that return code 1 makes it boot.  So now you
> > changed it so that "mach dtb" kicks of booting the kernel?  That does
> > not seem tight to me.  This should stay 0, right?
> Absolutely, my bad.
> 
> I've tested all scenarios with and without this fixed diff below to
> double check.
> 
> OK?
> 

Yes.

> 
> Index: efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/stand/efiboot/efiboot.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 efiboot.c
> --- efiboot.c 9 Mar 2021 21:11:24 -   1.31
> +++ efiboot.c 26 Mar 2021 23:05:46 -
> @@ -980,24 +980,26 @@ Xdtb_efi(void)
>  
>  #define O_RDONLY 0
>  
> - if (cmd.argc != 2)
> - return (1);
> + if (cmd.argc != 2) {
> + printf("dtb file\n");
> + return (0);
> + }
>  
>   snprintf(path, sizeof(path), "%s:%s", cmd.bootdev, cmd.argv[1]);
>  
>   fd = open(path, O_RDONLY);
>   if (fd < 0 || fstat(fd, ) == -1) {
>   printf("cannot open %s\n", path);
> - return (1);
> + return (0);
>   }
>   if (efi_memprobe_find(EFI_SIZE_TO_PAGES(sb.st_size),
>   0x1000, ) != EFI_SUCCESS) {
>   printf("cannot allocate memory for %s\n", path);
> - return (1);
> + return (0);
>   }
>   if (read(fd, (void *)addr, sb.st_size) != sb.st_size) {
>   printf("cannot read from %s\n", path);
> - return (1);
> + return (0);
>   }
>  
>   fdt = (void *)addr;

Re: apm/arm64: fix errno, merge ioctl cases

[Patrick Wildt]

Am Sat, Mar 20, 2021 at 08:01:51PM +0100 schrieb Klemens Nanni:
> The EBADF error is always overwritten for the standby, suspend and
> hibernate ioctls, only the mode ioctl has it right.
> 
> Merge the now identical casese while here.
> 
> Tested on a Pinebook Pro.
> 
> OK?

ok patrick@

> Index: apm.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/dev/apm.c,v
> retrieving revision 1.6
> diff -u -p -r1.6 apm.c
> --- apm.c 25 Dec 2020 12:59:51 -  1.6
> +++ apm.c 20 Mar 2021 18:54:23 -
> @@ -213,17 +213,15 @@ apmioctl(dev_t dev, u_long cmd, caddr_t 
>   case APM_IOC_STANDBY_REQ:
>   case APM_IOC_SUSPEND:
>   case APM_IOC_SUSPEND_REQ:
> - if ((flag & FWRITE) == 0)
> - error = EBADF;
> - error = EOPNOTSUPP;
> - break;
>  #ifdef HIBERNATE
>   case APM_IOC_HIBERNATE:
> +#endif
> + case APM_IOC_DEV_CTL:
>   if ((flag & FWRITE) == 0)
>   error = EBADF;
> - error = EOPNOTSUPP;
> + else
> + error = EOPNOTSUPP; /* XXX */
>   break;
> -#endif
>   case APM_IOC_PRN_CTL:
>   if ((flag & FWRITE) == 0)
>   error = EBADF;
> @@ -247,12 +245,6 @@ apmioctl(dev_t dev, u_long cmd, caddr_t 
>   break;
>   }
>   }
> - break;
> - case APM_IOC_DEV_CTL:
> - if ((flag & FWRITE) == 0)
> - error = EBADF;
> - else
> - error = EOPNOTSUPP; /* XXX */
>   break;
>   case APM_IOC_GETPOWER:
>   power = (struct apm_power_info *)data;
> 

Re: efiboot/arm64: fix "mach dtb" return code to avoid bogus boot

[Patrick Wildt]

Am Wed, Mar 24, 2021 at 07:20:29PM +0100 schrieb Klemens Nanni:
> Bootloader command functions must return zero in case of failure,
> returning 1 tells the bootloader to boot the file.
> 
> arm64's `machine dtb' command has it the wrong way so using it triggers
> a boot that doesn't make any sense:
> 
>   >> OpenBSD/arm64 BOOTAA64 1.4
>   boot> mach dtb
>   booting sd0a:/etc/boot.conf: open sd0a:/etc/boot.conf: No such file or 
> directory
>   failed(2). will try /bsd
>   boot> mach dtb /foo
>   cannot open sd0a:/foo
>   NOTE: random seed is being reused.
>   booting sd0a:/etc/boot.conf: open sd0a:/etc/boot.conf: No such file or 
> directory
>   failed(2). will try /bsd
> 
> With this diff:
> 
>   >> OpenBSD/arm64 BOOTAA64 1.4
>   boot> mach dtb
>   dtb file
>   boot> mach dtb /foo
>   cannot open sd0a:/foo
> 
> While here, tell users how to use that command (like other commands
> such as `hexdump' do).
> 
> Feedback? OK?
> 
> Index: arch/arm64/stand/efiboot/efiboot.c
> ===
> RCS file: /cvs/src/sys/arch/arm64/stand/efiboot/efiboot.c,v
> retrieving revision 1.31
> diff -u -p -r1.31 efiboot.c
> --- arch/arm64/stand/efiboot/efiboot.c9 Mar 2021 21:11:24 -   
> 1.31
> +++ arch/arm64/stand/efiboot/efiboot.c24 Mar 2021 17:59:52 -
> @@ -980,28 +980,30 @@ Xdtb_efi(void)
>  
>  #define O_RDONLY 0
>  
> - if (cmd.argc != 2)
> - return (1);
> + if (cmd.argc != 2) {
> + printf("dtb file\n");
> + return (0);
> + }
>  
>   snprintf(path, sizeof(path), "%s:%s", cmd.bootdev, cmd.argv[1]);
>  
>   fd = open(path, O_RDONLY);
>   if (fd < 0 || fstat(fd, ) == -1) {
>   printf("cannot open %s\n", path);
> - return (1);
> + return (0);
>   }
>   if (efi_memprobe_find(EFI_SIZE_TO_PAGES(sb.st_size),
>   0x1000, ) != EFI_SUCCESS) {
>   printf("cannot allocate memory for %s\n", path);
> - return (1);
> + return (0);
>   }
>   if (read(fd, (void *)addr, sb.st_size) != sb.st_size) {
>   printf("cannot read from %s\n", path);
> - return (1);
> + return (0);
>   }
>  
>   fdt = (void *)addr;
> - return (0);
> + return (1);

Wait, you've been saying that return code 1 makes it boot.  So now you
changed it so that "mach dtb" kicks of booting the kernel?  That does
not seem tight to me.  This should stay 0, right?

>  }
>  
>  int
> 

Re: cwfg: flag sensor as invalid on bogus reads

[Patrick Wildt]

Am Fri, Mar 26, 2021 at 12:26:51AM +0100 schrieb Klemens Nanni:
> Follow-up to "arm64: make cwfg(4) report battery information to apm(4)".
> 
> This driver continues to report stale hw.sensors values when reading
> them fails, which can easily be observed on a Pinebook Pro after
> plugging in the AC cable.
> 
> Running on battery looks like this (note sensors and apm are in sync):
> 
>   $ sysctl hw.sensors
>   hw.sensors.cwfg0.volt0=3.68 VDC (battery voltage)
>   hw.sensors.cwfg0.raw0=104 (battery remaining minutes)
>   hw.sensors.cwfg0.percent0=27.00% (battery percent)
>   $ apm
>   Battery state: high, 27% remaining, 104 minutes life estimate
>   A/C adapter state: not known
>   Performance adjustment mode: auto (408 MHz)
> 
> When I plug in the AC cable, `raw0' jumps around considerable one or two
> times before stalling on the last value (note how `percent0' stayed the
> same while `raw0' trippled):
> 
>   $ sysctl hw.sensors
>   hw.sensors.cwfg0.volt0=3.98 VDC (battery voltage)
>   hw.sensors.cwfg0.raw0=359 (battery remaining minutes)
>   hw.sensors.cwfg0.percent0=27.00% (battery percent)
>   $ apm
>   Battery state: high, 27% remaining, unknown life estimate
>   A/C adapter state: not known
>   Performance adjustment mode: auto (408 MHz)
> 
> `raw0' aka. `CWFG_SENSOR_RTT' stops yielding valid values as long as AC
> is plugged in (no idea if by design or a bug).
> 
> Hence hw.sensors.cwf0 values become incoherent and drift away from apm's
> output which --due to the reset logic discussed in the aforementioned
> tech@ thread-- properly picks up the stalled value as "unknown".
> 
> 
> I see two approaches to fix this:
> 
> 1. simple but less user-friendly:  flag sensors invalid upfront in apm's
>fashion and mark them OK iff they yield valid values;   this is what
>other drivers such as rktemp(4) do, but the consequence/intention of
>`SENSOR_FINVALID' is sysctl(8) and systat(8) skipping such sensors,
>i.e. above sysctl output would omit the `raw0' line if AC is plugged
>in (arguably better than printing outdated/misleading values).
> 
> 2. elaborate but informative:  set sensor value/status to 0/unknown like
>acpibat(4) does for example;  the advantage is that sensors no longer
>come and go but could look like this:
>   hw.sensors.cwfg0.raw0=0 (battery remaining minutes), UNKNOWN
>I'd do prefer this but am not yet sure if that's how the sensor
>framework is supposed to be used and/or I'd need to tinker with the
>code (on multiple notebooks/sensors) to see if it works out.
> 
> 
> Either way, diff below implements the first approach such that we avoid
> bogus sysctl/systat lines and hw.sensors gets in sync with apm.
> One could still switch to the second approach afterwards.
> 
> Feedback? Objections? OK?
> 

It's pretty normal for voltage to go up once AC is connected.  In the
end, afaik batteries are charged by applying voltage.  Additionally
if an external supply provides power, there's a smaller voltage drop.

The "remaining battery time" to become invalid makes sense as well,
I mean, with an AC it's gonna be endless and there's no way to measure
the battery change.  Well, the only thing it could maybe try and
estimate is time until charged.

What happens to battery percentage?  Does it change while it's charging?

As mentioned, connecting the charger will make the voltage go up, but
the battery charge will not have changed, hence I expect the percentage
to stay the same value, even though the voltage changes.  But with time,
percentage should go up.

> 
> Index: cwfg.c
> ===
> RCS file: /cvs/src/sys/dev/fdt/cwfg.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 cwfg.c
> --- cwfg.c25 Mar 2021 12:18:27 -  1.3
> +++ cwfg.c25 Mar 2021 12:25:31 -
> @@ -348,9 +348,12 @@ cwfg_update_sensors(void *arg)
>   uint8_t val;
>   int error, n;
>  
> -#if NAPM > 0
> - /* reset previous reads so apm(4) never gets stale values
> + /* invalidate all previous reads to avoid stale/incoherent values
>* in case of transient cwfg_read() failures below */
> + sc->sc_sensor[CWFG_SENSOR_VCELL].flags |= SENSOR_FINVALID;
> + sc->sc_sensor[CWFG_SENSOR_SOC].flags |= SENSOR_FINVALID;
> + sc->sc_sensor[CWFG_SENSOR_RTT].flags |= SENSOR_FINVALID;

I'd probably put a newline here, but that's just personal nitpicking.

I think it makes sense that outdated information should be marked
invalid.  Doing that upfront makes sense.  Doing it for VCELL is
not strictly necessary, but makes sense for consistency.

ok patrick@

> +#if NAPM > 0
>   cwfg_power.battery_state = APM_BATT_UNKNOWN;
>   cwfg_power.ac_state = APM_AC_UNKNOWN;
>   cwfg_power.battery_life = 0;
> 

Re: fyi: get HP EliteBook 830 G7/G8 booting

[Patrick Wildt]

Am Fri, Mar 26, 2021 at 12:12:44PM +0100 schrieb Mark Kettenis:
> > Date: Fri, 26 Mar 2021 19:43:23 +0900 (JST)
> > From: YASUOKA Masahiko 
> > 
> > Hi,
> > 
> > On Fri, 26 Mar 2021 09:30:43 +0100
> > Jan Klemkow  wrote:
> > > If you want to boot OpenBSD on an HP EliteBook 830 G7/G8, the bootloader
> > > will hang while loading the kernel.  Because, the UEFI loads the
> > > bootloader on the same place in memory, where the bootloader will copy
> > > the kernel.  We are unable to load the kernel on arbitrary memory.
> > > Thus, the following diff will help you, to get OpenBSD running on these
> > > machines.  It moves the hardcoded Kernel address to a free place.
> > 
> > The openbsd efiboot copies the kernel to that place after
> > ExitBootServices().
> > 
> > sys/arch/amd64/stand/efiboot/exec_i386.c
> > 152 /*
> > 153  * Move the loaded kernel image to the usual place after 
> > calling
> > 154  * ExitBootServices().
> > 155  */
> > 156 #ifdef __amd64__
> > 157 protect_writeable(marks[MARK_START] + delta,
> > 158 marks[MARK_END] - marks[MARK_START]);
> > 159 #endif
> > 160 memmove((void *)marks[MARK_START] + delta, (void 
> > *)marks[MARK_START],
> > 161 marks[MARK_END] - marks[MARK_START]);
> > 162 for (i = 0; i < MARK_MAX; i++)
> > 163 marks[i] += delta;
> > 164 
> > 165 #ifdef __amd64__
> > 166 (*run_i386)((u_long)run_i386, entry, howto, bootdev, 
> > BOOTARG_APIVER,
> > 167 marks[MARK_END], extmem, cnvmem, ac, (intptr_t)av);
> > 
> > 
> > I think it should work without the ld.script change..
> 
> The (likely) problem is that the memmove() on line 160 is overwriting
> the bootloader code itself.

More than just likely.  We have debugged it, looked at the memory table
etc. and it really is the case that efiboot(8) starts at *the same*
address as where the kernel is supposed to be copied to.  Hence *all*
of efiboot(8) is overwritten, even the code that is currectly doing
the copying.

> There are essentially two ways to fix this:
> 
> 1. Have the bootloader relocate itself to an address that doesn't
>conflict with the kernel to be loaded.
> 
> 2. Make it possible for the kernel to be loaded at a (somewhat)
>arbitrary physical address.
> 
> In my view #2 is the way forward.  There are other reasons why that
> would be beneficial as it would make it less predictable at which
> physical address the kernel code lives which could prevent some
> attacks that use the direct map.
> 
> #2 is also the approach taken by the EFIBOOT on armv7 and arm64.  On
> arm64 for example, EFIBOOT loads the kernel into a 64MB memory block
> that is aligned on a 2MB boundary.  The kernel then figures out its
> load address based on that and and patches things up accordingly.
> 
> mlarkin@ was doing some work to change how we load the amd64 kernel.
> His approach was to let the bootloader build the initial page tables
> and jump into the kernel in 64-bit mode with the MMU enabled.  That
> was more focussed on running the kernel at a randomized virtual
> address.  But it should be fairly easy to make it run at a different
> physical address as well this way.  Unfortunately that effort was
> mostly focussed on the legacy bootloader.

I'm also more in favour of #2, but I'm still working on my thesis (==
no time) and x86 isn't my area of expertise.

Re: Huawei ME906s-158 LTE, cdce(4) vs umb(4)

[Patrick Wildt]

On Wed, Mar 24, 2021 at 11:23:11PM +, Stuart Henderson wrote:
> In my ongoing search to find a umb(4) that will actually work that
> isn't the one in my laptop (since my EM7305 has been a failure),
> I picked up a Huawei ME906s-158 off ebay. It attaches to cdce and ugen
> and fails to work:
> 
> cdce0 at uhub2 port 4 configuration 2 interface 0 "Huawei Technologies Co., 
> Ltd. HUAWEI Mobile" rev 2.10/1.02 addr 3
> cdce0: could not find data bulk in
> ugen0 at uhub2 port 4 configuration 2 "Huawei Technologies Co., Ltd. HUAWEI 
> Mobile" rev 2.10/1.02 addr 3
> 
> Any information I can find for it suggests that it does MBIM, and
> indeed if I disable cdce in the kernel it picks up on a different
> config:
> 
> umb0 at uhub2 port 4 configuration 3 interface 0 "Huawei Technologies Co., 
> Ltd. HUAWEI Mobile" rev 2.10/1.02 addr 3
> ugen0 at uhub2 port 4 configuration 3 "Huawei Technologies Co., Ltd. HUAWEI 
> Mobile" rev 2.10/1.02 addr 3
> 
> and after I figured out which of the APU2's mPCIe slots is routed to
> the SIM slot (the middle one) it actually negotiates with the network
> 
> umb0: flags=8855 mtu 1500
> index 11 priority 6 llprio 3
> roaming disabled registration home network
> state up cell-class LTE rssi -83dBm speed 143Mbps up 143Mbps down
> SIM initialized PIN valid (3 attempts left)
> subscriber-id 234 ICC-id 8944xxx provider 3
> device ML1ME906SM IMEI 867 firmware 11.617.04.00.00
> phone# +44xx APN 3internet
> dns 217.171.132.0 217.171.135.0
> groups: egress
> status: active
> inet 94.197.84.2 --> 94.197.84.1 netmask 0xfffc
> 
> It doesn't seem to be working properly yet (packets transmitted over it
> don't arrive at the destination) but I'm not 100% convinced that it's
> not the network yet, I'll find some more SIMs to try.
> 
> In the meantime, any suggestions how to knock it out from attaching
> to cdce? Is there a way to drop out in the attach routine (e.g. if there's
> no data bulk in) to allow another driver to attempt attaching,
> or is it committed to a specific driver once it has matched?
> 
> If the latter, would it make sense for cdce to look for MBIM on
> another configuration and skip matching in that case? Or do (move
> or replicate) some of cdce_attach()'s checks in cdce_match so it
> can skip attaching if cdce isn't going to work?
> 
> There are loads of these showing up (probably from laptops broken for
> parts) for about 20 $currency_units on ebay/similar now so it would
> be quite nice to get them working. A few similar devices showed up
> on the lists before but I haven't noticed anyone trying to disable
> cdce on them yet.
> https://www.google.com/search?q=huawei+%22cdce0:+could+not+find+data+bulk+in%22+site:openbsd-archive.7691.n7.nabble.com
> 
> If anyone else is thinking of getting one to poke at, to use in an APU
> they also need a M.2 -> mPCIe adapter (aka NGFF -> mPCIe) with 'B' key
> (doesn't need a sim carrier on the adapter), plus whatever u.fl pigtails
> and antennas (the proper multiband LTE antennas usually have SMA
> connectors rather than the RP-SMA common with wifi).
> 
> Descriptors from lsusb below (seach for "HUAWEI Mobile Broadband Module"
> for the 'right' one).

Without having looked at anything, it might be worth looking at the most
recent mail in this thread:

'Re: [PATCH] umb(4) fix for X20 (DW5821e) in Dell Latitude 7300'

Re: ixl(4): add ID for X710 10G SFP+

[Patrick Wildt]

Am Mon, Mar 15, 2021 at 08:59:05AM +0100 schrieb Jan Klemkow:
> On Mon, Mar 15, 2021 at 01:35:28AM -0600, Theo de Raadt wrote:
> > My comments are about the "text name", which goes into every kernel
> > anyone compiles.
> > 
> > It should be as short as possible.
> 
> Sorry, I missed that point.
> 
> > But the reason why 10G is incorrect is because surely the port can
> > accept 1G, or a variety of other SFPs...  It is simply too exact,
> > and wasting kernel bytes.
> 
> OK?
> 
> Thanks,
> Jan
> 
> Index: if_ixl.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_ixl.c,v
> retrieving revision 1.73
> diff -u -p -r1.73 if_ixl.c
> --- if_ixl.c  26 Feb 2021 10:36:45 -  1.73
> +++ if_ixl.c  15 Mar 2021 07:42:48 -
> @@ -1611,6 +1611,7 @@ struct ixl_device {
>  
>  static const struct ixl_device ixl_devices[] = {
>   { _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_10G_SFP },
> + { _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_10G_SFP_2 },

Looks like so far we have ordered this list in the same order as it is
in pcidevs (for X710).  If we want to keep that order, _2 should be
the first entry.  If we don't want to keep that order, then this diff
should be fine.  jsg@, dlg@: any preference or do you not care?

Patrick

>   { _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_XL710_40G_BP },
>   { _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_10G_BP, },
>   { _710, PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_XL710_QSFP_1 },
> Index: pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1960
> diff -u -p -r1.1960 pcidevs
> --- pcidevs   14 Mar 2021 01:09:29 -  1.1960
> +++ pcidevs   15 Mar 2021 07:42:19 -
> @@ -3702,6 +3702,7 @@ product INTEL ICH8_IGP_AMT  0x104a  ICH8 I
>  product INTEL ICH8_IGP_C 0x104b  ICH8 IGP C
>  product INTEL ICH8_IFE   0x104c  ICH8 IFE
>  product INTEL ICH8_IGP_M 0x104d  ICH8 IGP M
> +product INTEL X710_10G_SFP_2 0x104e  X710 SFP+
>  product INTEL PRO_100_VE_4   0x1050  PRO/100 VE
>  product INTEL PRO_100_VE_5   0x1051  PRO/100 VE
>  product INTEL PRO_100_VM_6   0x1052  PRO/100 VM
> Index: pcidevs.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs.h,v
> retrieving revision 1.1954
> diff -u -p -r1.1954 pcidevs.h
> --- pcidevs.h 14 Mar 2021 01:10:35 -  1.1954
> +++ pcidevs.h 15 Mar 2021 07:42:21 -
> @@ -3707,6 +3707,7 @@
>  #define  PCI_PRODUCT_INTEL_ICH8_IGP_C0x104b  /* ICH8 IGP C */
>  #define  PCI_PRODUCT_INTEL_ICH8_IFE  0x104c  /* ICH8 IFE */
>  #define  PCI_PRODUCT_INTEL_ICH8_IGP_M0x104d  /* ICH8 IGP M */
> +#define  PCI_PRODUCT_INTEL_X710_10G_SFP_20x104e  /* X710 
> SFP+ */
>  #define  PCI_PRODUCT_INTEL_PRO_100_VE_4  0x1050  /* PRO/100 VE */
>  #define  PCI_PRODUCT_INTEL_PRO_100_VE_5  0x1051  /* PRO/100 VE */
>  #define  PCI_PRODUCT_INTEL_PRO_100_VM_6  0x1052  /* PRO/100 VM */
> Index: pcidevs_data.h
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs_data.h,v
> retrieving revision 1.1949
> diff -u -p -r1.1949 pcidevs_data.h
> --- pcidevs_data.h14 Mar 2021 01:10:35 -  1.1949
> +++ pcidevs_data.h15 Mar 2021 07:42:21 -
> @@ -12252,6 +12252,10 @@ static const struct pci_known_product pc
>   "ICH8 IGP M",
>   },
>   {
> + PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_X710_10G_SFP_2,
> + "X710 SFP+",
> + },
> + {
>   PCI_VENDOR_INTEL, PCI_PRODUCT_INTEL_PRO_100_VE_4,
>   "PRO/100 VE",
>   },
> 

acpi(4): pass DMA tag to ACPI tables

[Patrick Wildt]

Hi,

to be able to have acpiiort(4) pass a DMA tag to smmu(4), acpiiort(4)
needs to be passed a DMA tag.  So far acpi(4) only seems to pass it on
acpi_foundhid(), but the ACPI table drivers don't get it.  So, let's
just pass the default DMA tag.

ok?

Patrick

diff --git a/sys/dev/acpi/acpi.c b/sys/dev/acpi/acpi.c
index 4c824ee6cbb..67dd7f14435 100644
--- a/sys/dev/acpi/acpi.c
+++ b/sys/dev/acpi/acpi.c
@@ -1202,6 +1202,7 @@ acpi_attach_common(struct acpi_softc *sc, paddr_t base)
memset(, 0, sizeof(aaa));
aaa.aaa_iot = sc->sc_iot;
aaa.aaa_memt = sc->sc_memt;
+   aaa.aaa_dmat = sc->sc_ci_dmat;
aaa.aaa_table = entry->q_table;
config_found_sm(>sc_dev, , acpi_print, acpi_submatch);
}

Re: Read `ps_single' once

[Patrick Wildt]

Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark Kettenis:
> > Date: Thu, 4 Mar 2021 10:34:24 +0100
> > From: Martin Pieuchot 
> > 
> > Running t/rw/msleep(9) w/o KERNEL_LOCK() implies that a thread can
> > change the value of `ps_single' while one of its siblings might be
> > dereferencing it.  
> > 
> > To prevent inconsistencies in the code executed by sibling thread, the
> > diff below makes sure `ps_single' is dereferenced only once in various
> > parts of the kernel.
> > 
> > ok?
> 
> I think that means that ps_single has to be declared "volatile".

Isn't there the READ_ONCE(x) macro, that does exactly that?

> > Index: kern/kern_exit.c
> > ===
> > RCS file: /cvs/src/sys/kern/kern_exit.c,v
> > retrieving revision 1.196
> > diff -u -p -r1.196 kern_exit.c
> > --- kern/kern_exit.c15 Feb 2021 09:35:59 -  1.196
> > +++ kern/kern_exit.c4 Mar 2021 09:29:27 -
> > @@ -274,6 +274,8 @@ exit1(struct proc *p, int xexit, int xsi
> >  */
> > if (qr->ps_flags & PS_TRACED &&
> > !(qr->ps_flags & PS_EXITING)) {
> > +   struct proc *st;
> > +
> > process_untrace(qr);
> >  
> > /*
> > @@ -281,9 +283,9 @@ exit1(struct proc *p, int xexit, int xsi
> >  * direct the signal to the active
> >  * thread to avoid deadlock.
> >  */
> > -   if (qr->ps_single)
> > -   ptsignal(qr->ps_single, SIGKILL,
> > -   STHREAD);
> > +   st = qr->ps_single;
> > +   if (st != NULL)
> > +   ptsignal(st, SIGKILL, STHREAD);
> > else
> > prsignal(qr, SIGKILL);
> > } else {
> > @@ -510,7 +512,7 @@ dowait4(struct proc *q, pid_t pid, int *
> >  {
> > int nfound;
> > struct process *pr;
> > -   struct proc *p;
> > +   struct proc *p, *st;
> > int error;
> >  
> > if (pid == 0)
> > @@ -541,10 +543,11 @@ loop:
> > proc_finish_wait(q, p);
> > return (0);
> > }
> > +
> > +   st = pr->ps_single;
> > if (pr->ps_flags & PS_TRACED &&
> > -   (pr->ps_flags & PS_WAITED) == 0 && pr->ps_single &&
> > -   pr->ps_single->p_stat == SSTOP &&
> > -   (pr->ps_single->p_flag & P_SUSPSINGLE) == 0) {
> > +   (pr->ps_flags & PS_WAITED) == 0 && st != NULL &&
> > +   st->p_stat == SSTOP && (st->p_flag & P_SUSPSINGLE) == 0) {
> > if (single_thread_wait(pr, 0))
> > goto loop;
> >  
> > Index: kern/sys_process.c
> > ===
> > RCS file: /cvs/src/sys/kern/sys_process.c,v
> > retrieving revision 1.86
> > diff -u -p -r1.86 sys_process.c
> > --- kern/sys_process.c  8 Feb 2021 10:51:02 -   1.86
> > +++ kern/sys_process.c  4 Mar 2021 09:29:27 -
> > @@ -273,7 +273,7 @@ sys_ptrace(struct proc *p, void *v, regi
> >  int
> >  ptrace_ctrl(struct proc *p, int req, pid_t pid, caddr_t addr, int data)
> >  {
> > -   struct proc *t; /* target thread */
> > +   struct proc *st, *t;/* target thread */
> > struct process *tr; /* target process */
> > int error = 0;
> > int s;
> > @@ -433,8 +433,9 @@ ptrace_ctrl(struct proc *p, int req, pid
> >  * from where it stopped."
> >  */
> >  
> > -   if (pid < THREAD_PID_OFFSET && tr->ps_single)
> > -   t = tr->ps_single;
> > +   st = tr->ps_single;
> > +   if (pid < THREAD_PID_OFFSET && st != NULL)
> > +   t = st;
> >  
> > /* If the address parameter is not (int *)1, set the pc. */
> > if ((int *)addr != (int *)1)
> > @@ -464,8 +465,9 @@ ptrace_ctrl(struct proc *p, int req, pid
> >  * from where it stopped."
> >  */
> >  
> > -   if (pid < THREAD_PID_OFFSET && tr->ps_single)
> > -   t = tr->ps_single;
> > +   st = tr->ps_single;
> > +   if (pid < THREAD_PID_OFFSET && st != NULL)
> > +   t = st;
> >  
> >  #ifdef PT_STEP
> > /*
> > @@ -495,8 +497,9 @@ ptrace_ctrl(struct proc *p, int req, pid
> > break;
> >  
> > case PT_KILL:
> > -   if (pid < THREAD_PID_OFFSET && tr->ps_single)
> > -   t = tr->ps_single;
> > +   st = tr->ps_single;
> > +   if (pid < THREAD_PID_OFFSET && st != NULL)
> > +   t = st;
> >  
> > /* just send the process a KILL signal. */
> >  

Re: fix nvme(4): NULL deref. and empty device attachments

[Patrick Wildt]

Am Wed, Feb 24, 2021 at 05:34:48PM +0100 schrieb Jan Klemkow:
> Hi,
> 
> While attaching the following disks, the nvme driver runs into a NULL
> dereference in nvme_scsi_capacity16() and nvme_scsi_capacity().
> 
> nvme0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 
> 0x00: msix, NVMe 1.2
> nvme0: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ0413002P4P0DGN
> scsibus1 at nvme0: 129 targets, initiator 0
> sd0 at scsibus1 targ 1 lun 0: 
> sd0: 3815447MB, 512 bytes/sector, 7814037168 sectors
> sd1 at scsibus1 targ 2 lun 0: 
> uvm_fault(0x821d00e8, 0x0, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  nvme_scsi_capacity16+0x39:  movq0(%rax),%rcx
> ddb{0}>
> 
> "ns" in both functions will be NULL, if "identify" is not allocated in
> nvme_scsi_probe().  Thus, its better to just not attach this empty
> disks/LUNs.
> 
> nvme0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 
> 0x00: msix, NVMe 1.2
> nvme0: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ0413002P4P0DGN
> scsibus1 at nvme0: 129 targets, initiator 0
> sd0 at scsibus1 targ 1 lun 0: 
> sd0: 3815447MB, 512 bytes/sector, 7814037168 sectors
> ppb1 at pci0 dev 3 function 2 "AMD 17h PCIE" rev 0x00: msi
> pci2 at ppb1 bus 98
> nvme1 at pci2 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 
> 0x00: msix, NVMe 1.2
> nvme1: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ041500C34P0DGN
> scsibus2 at nvme1: 129 targets, initiator 0
> sd1 at scsibus2 targ 1 lun 0: 
> sd1: 3815447MB, 512 bytes/sector, 7814037168 sectors
> ppb2 at pci0 dev 3 function 3 "AMD 17h PCIE" rev 0x00: msi
> pci3 at ppb2 bus 99
> nvme2 at pci3 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 
> 0x00: msix, NVMe 1.2
> nvme2: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ041402Z64P0DGN
> scsibus3 at nvme2: 129 targets, initiator 0
> sd2 at scsibus3 targ 1 lun 0: 
> sd2: 3815447MB, 512 bytes/sector, 7814037168 sectors
> ppb3 at pci0 dev 3 function 4 "AMD 17h PCIE" rev 0x00: msi
> pci4 at ppb3 bus 100
> nvme3 at pci4 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev 
> 0x00: msix, NVMe 1.2
> nvme3: INTEL SSDPE2KX040T8, firmware VDV10170, serial PHLJ041403134P0DGN
> scsibus4 at nvme3: 129 targets, initiator 0
> sd3 at scsibus4 targ 1 lun 0: 
> sd3: 3815447MB, 512 bytes/sector, 7814037168 sectors
> 
> The following diff signals an error for the upper probing function in
> the SCSI layer to prevents further function calls in nvme(4) which would
> just leads to the upper described error and hundreds of not configured
> devices.
> 
> OK?

I think this is the correct way to fix it.  The issue essentially is
that we still return "ok" even though the size is zero.  And we should
probably fail similarly as if it didn't exist.  FreeBSD has a similar
check here, which explains it a little:

/*
 * If the size of is zero, chances are this isn't a valid
 * namespace (eg one that's not been configured yet). The
 * standard says the entire id will be zeros, so this is a
 * cheap way to test for that.
 */
if (ns->data.nsze == 0)
return (ENXIO);

I wondered if this block of code could be written a bit differently, but
I couldn't make it look any better.

ok patrick@ fwiw

> bye,
> Jan
> 
> Index: dev/ic/nvme.c
> ===
> RCS file: /cvs//src/sys/dev/ic/nvme.c,v
> retrieving revision 1.90
> diff -u -p -r1.90 nvme.c
> --- dev/ic/nvme.c 9 Feb 2021 01:50:10 -   1.90
> +++ dev/ic/nvme.c 24 Feb 2021 16:01:48 -
> @@ -463,11 +463,16 @@ nvme_scsi_probe(struct scsi_link *link)
>   scsi_io_put(>sc_iopool, ccb);
>  
>   identify = NVME_DMA_KVA(mem);
> - if (rv == 0 && lemtoh64(>nsze) > 0) {
> - /* Commit namespace if it has a size greater than zero. */
> - identify = malloc(sizeof(*identify), M_DEVBUF, M_WAITOK);
> - memcpy(identify, NVME_DMA_KVA(mem), sizeof(*identify));
> - sc->sc_namespaces[link->target].ident = identify;
> + if (rv == 0) {
> + if (lemtoh64(>nsze) > 0) {
> + /* Commit namespace if it has a size greater than zero. 
> */
> + identify = malloc(sizeof(*identify), M_DEVBUF, 
> M_WAITOK);
> + memcpy(identify, NVME_DMA_KVA(mem), sizeof(*identify));
> + sc->sc_namespaces[link->target].ident = identify;
> + } else {
> + /* Don't attach a namespace if its size is zero. */
> + rv = ENXIO;
> + }
>   }
>  
>   nvme_dmamem_free(sc, mem);
> 

sdmmc(4): check and retry bus width change

[Patrick Wildt]

Hi,

it seems like some eMMCs are not capable of doing 8-bit operation,
even if the controller supports it.  I was questioning our drivers
first, but it looks like it's the same on Linux.  In the case that
8-bit doesn't work, they seem to fall back to lower values to make
that HW work.

This diff implements a mechanism that tries 8-bit, if available,
then 4-bit and in the end falls back to 1-bit.  This makes my HW
work, but I would like to have this tested by a broader audience.

Apparently there's a "bus test" command, but it isn't implemented
on all host controllers.  Hence I simply try to read the EXT_CSD
to make sure the transfer works.

For testing, a print like

printf("%s: using %u-bit width\n", DEVNAME(sc), width);

could be added at line 928.

What could possible regressions be?  The width could become smaller
then previously.  This would reduce the read/write transfer speed.
Also it's possible that eMMCs are not recognized/initialized anymore.

What could possible improvements be?  eMMCs that previously didn't
work now work, with at least 1-bit or 4-bit wide transfers.

Please note that this only works for eMMCs.  SD cards are *not* using
this code path.  SD cards have a different initialization code path.

Please report any changes or non-changes.  If nothing changes, that's
perfect.

Patrick

diff --git a/sys/dev/sdmmc/sdmmc_mem.c b/sys/dev/sdmmc/sdmmc_mem.c
index 59bcb1b4a11..5856b9bb1b3 100644
--- a/sys/dev/sdmmc/sdmmc_mem.c
+++ b/sys/dev/sdmmc/sdmmc_mem.c
@@ -56,6 +56,8 @@ int   sdmmc_mem_signal_voltage(struct sdmmc_softc *, int);
 
 intsdmmc_mem_sd_init(struct sdmmc_softc *, struct sdmmc_function *);
 intsdmmc_mem_mmc_init(struct sdmmc_softc *, struct sdmmc_function *);
+intsdmmc_mem_mmc_select_bus_width(struct sdmmc_softc *,
+   struct sdmmc_function *, int);
 intsdmmc_mem_single_read_block(struct sdmmc_function *, int, u_char *,
size_t);
 intsdmmc_mem_read_block_subr(struct sdmmc_function *, bus_dmamap_t,
@@ -908,31 +910,20 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *sc, struct 
sdmmc_function *sf)
ext_csd[EXT_CSD_CARD_TYPE]);
}
 
-   if (ISSET(sc->sc_caps, SMC_CAPS_8BIT_MODE)) {
+   if (ISSET(sc->sc_caps, SMC_CAPS_8BIT_MODE) &&
+   sdmmc_mem_mmc_select_bus_width(sc, sf, 8) == 0)
width = 8;
-   value = EXT_CSD_BUS_WIDTH_8;
-   } else if (ISSET(sc->sc_caps, SMC_CAPS_4BIT_MODE)) {
+   else if (ISSET(sc->sc_caps, SMC_CAPS_4BIT_MODE) &&
+   sdmmc_mem_mmc_select_bus_width(sc, sf, 4) == 0)
width = 4;
-   value = EXT_CSD_BUS_WIDTH_4;
-   } else {
-   width = 1;
-   value = EXT_CSD_BUS_WIDTH_1;
-   }
-
-   if (width != 1) {
-   error = sdmmc_mem_mmc_switch(sf, EXT_CSD_CMD_SET_NORMAL,
-   EXT_CSD_BUS_WIDTH, value);
-   if (error == 0)
-   error = sdmmc_chip_bus_width(sc->sct,
-   sc->sch, width);
-   else {
+   else {
+   error = sdmmc_mem_mmc_select_bus_width(sc, sf, 1);
+   if (error != 0) {
DPRINTF(("%s: can't change bus width"
" (%d bit)\n", DEVNAME(sc), width));
return error;
}
-
-   /* : need bus test? (using by CMD14 & CMD19) */
-   sdmmc_delay(1);
+   width = 1;
}
 
if (timing != SDMMC_TIMING_LEGACY) {
@@ -1041,6 +1032,59 @@ sdmmc_mem_mmc_init(struct sdmmc_softc *sc, struct 
sdmmc_function *sf)
return error;
 }
 
+int
+sdmmc_mem_mmc_select_bus_width(struct sdmmc_softc *sc, struct sdmmc_function 
*sf,
+int width)
+{
+   u_int8_t ext_csd[512];
+   int error, value;
+
+   switch (width) {
+   case 8:
+   value = EXT_CSD_BUS_WIDTH_8;
+   break;
+   case 4:
+   value = EXT_CSD_BUS_WIDTH_4;
+   break;
+   case 1:
+   value = EXT_CSD_BUS_WIDTH_1;
+   break;
+   default:
+   printf("%s: invalid bus width\n", DEVNAME(sc));
+   return EINVAL;
+   }
+
+   error = sdmmc_mem_mmc_switch(sf, EXT_CSD_CMD_SET_NORMAL,
+   EXT_CSD_BUS_WIDTH, value);
+   if (error != 0) {
+   DPRINTF(("%s: can't change card bus width"
+   " (%d bit)\n", DEVNAME(sc), width));
+   return error;
+   }
+
+   error = sdmmc_chip_bus_width(sc->sct,
+   sc->sch, width);
+   if (error != 0) {
+   DPRINTF(("%s: can't change host bus width"
+   " (%d bit)\n", 

Re: add simplepmbus(4)

[Patrick Wildt]

Am Wed, Feb 17, 2021 at 11:56:16AM +1100 schrieb Jonathan Gray:
> Add a driver for "simple-pm-bus" a way to enable a clock and/or
> power domain for a group of devices.
> 
> https://www.kernel.org/doc/Documentation/devicetree/bindings/bus/simple-pm-bus.txt
> 
> This is needed to use am335x/omap4 dtbs from linux 5.11.

"A Simple Power-Managed Bus is a transparent bus that doesn't need a real
driver, as it's typically initialized by the boot loader."

That's a bit funny though. :-)  But I think they meant "it doesn't need
a real driver, apart from the generic simple-pm-bus driver".


> Index: sys/dev/fdt/files.fdt
> ===
> RCS file: /cvs/src/sys/dev/fdt/files.fdt,v
> retrieving revision 1.146
> diff -u -p -r1.146 files.fdt
> --- sys/dev/fdt/files.fdt 5 Feb 2021 00:05:20 -   1.146
> +++ sys/dev/fdt/files.fdt 17 Feb 2021 00:49:02 -
> @@ -23,6 +23,10 @@ device simplepanel
>  attach   simplepanel at fdt
>  file dev/fdt/simplepanel.c   simplepanel
>  
> +device   simplepmbus: fdt
> +attach   simplepmbus at fdt
> +file dev/fdt/simplepmbus.c   simplepmbus
> +
>  device   sxiccmu
>  attach   sxiccmu at fdt
>  file dev/fdt/sxiccmu.c   sxiccmu
> Index: share/man/man4/Makefile
> ===
> RCS file: /cvs/src/share/man/man4/Makefile,v
> retrieving revision 1.792
> diff -u -p -r1.792 Makefile
> --- share/man/man4/Makefile   4 Feb 2021 16:25:38 -   1.792
> +++ share/man/man4/Makefile   17 Feb 2021 00:49:02 -
> @@ -72,7 +72,8 @@ MAN=aac.4 abcrtc.4 abl.4 ac97.4 acphy.4
>   rl.4 rlphy.4 route.4 rsu.4 rtsx.4 rum.4 run.4 rtw.4 rtwn.4 \
>   safe.4 safte.4 sbus.4 schsio.4 scsi.4 sd.4 \
>   sdmmc.4 sdhc.4 se.4 ses.4 sf.4 sili.4 \
> - simpleamp.4 simpleaudio.4 simplefb.4 simplepanel.4 siop.4 sis.4 sk.4 \
> + simpleamp.4 simpleaudio.4 simplefb.4 simplepanel.4 simplepmbus.4 \
> + siop.4 sis.4 sk.4 \
>   sm.4 smsc.4 softraid.4 spdmem.4 sdtemp.4 speaker.4 sppp.4 sqphy.4 \
>   ssdfb.4 st.4 ste.4 stge.4 sti.4 stp.4 sv.4 switch.4 sxiccmu.4 \
>   sxidog.4 sximmc.4 sxipio.4 sxipwm.4 sxirsb.4 sxirtc.4 sxisid.4 \
> Index: sys/arch/armv7/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/armv7/conf/GENERIC,v
> retrieving revision 1.134
> diff -u -p -r1.134 GENERIC
> --- sys/arch/armv7/conf/GENERIC   4 Feb 2021 16:25:39 -   1.134
> +++ sys/arch/armv7/conf/GENERIC   17 Feb 2021 00:49:02 -
> @@ -31,6 +31,7 @@ config  bsd swap generic
>  # The main bus device
>  mainbus0 at root
>  simplebus*   at fdt?
> +simplepmbus* at fdt?
>  cpu0 at mainbus?
>  
>  # Cortex-A9
> Index: sys/arch/armv7/conf/RAMDISK
> ===
> RCS file: /cvs/src/sys/arch/armv7/conf/RAMDISK,v
> retrieving revision 1.119
> diff -u -p -r1.119 RAMDISK
> --- sys/arch/armv7/conf/RAMDISK   18 Jun 2020 08:48:04 -  1.119
> +++ sys/arch/armv7/conf/RAMDISK   17 Feb 2021 00:49:02 -
> @@ -30,6 +30,7 @@ config  bsd root on rd0a swap on rd0b
>  mainbus0 at root
>  softraid0at root
>  simplebus*   at fdt?
> +simplepmbus* at fdt?
>  cpu0 at mainbus?
>  
>  # Cortex-A9
> --- /dev/null Wed Feb 17 11:49:05 2021
> +++ sys/dev/fdt/simplepmbus.c Tue Feb 16 17:24:55 2021
> @@ -0,0 +1,62 @@
> +/*   $OpenBSD$   */
> +/*
> + * Copyright (c) 2021 Jonathan Gray 
> + *
> + * Permission to use, copy, modify, and distribute this software for any
> + * purpose with or without fee is hereby granted, provided that the above
> + * copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
> + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
> + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +#include 

Maybe like this, was we have in rkpinctrl?

#ifdef __armv7__
#include 
#else
#include 
#endif

Generally I was wondering if we shouldn't just add this to simplebus.c
itself?  You'd need to add a compatible to the match function, and in
the attach function you'd need to check for the compatible and then
do

power_domain_enable(faa->fa_node);
clock_enable_all(faa->fa_node);

in the if-block.

Haven't made my mind up yet what I like better, maybe kettenis@ has an
opinion.

Patrick

> +
> +int  

Re: Posted vs. non-posted device access

[Patrick Wildt]

Am Mon, Feb 15, 2021 at 09:55:56AM +1000 schrieb David Gwynne:
> 
> 
> > On 15 Feb 2021, at 07:54, Mark Kettenis  wrote:
> > 
> > One of the aspects of device access is whether CPU writes to a device
> > are posted or non-posted.  For non-posted writes, the CPU will wait
> > for the device to acknowledge that the write has performed.  If the
> > device sits on a bus far away, this can take a while and slow things
> > down.  The alternative are so-called posted writes.  The CPU will
> > "post" the write to the bus without waiting for an acknowledgement.
> > The CPU may receive an asynchronous notifaction at a later time that
> > the write didn't succeed or a failing write may be dropped without
> > further botification.  On most architectures whether writes are posted
> > or not is a property of the bus between the CPU and the device.  For
> > example, memory mapped I/O on the PCI bus is always posted and there
> > is nothing the CPU can do about it.
> > 
> > On the ARM architecture though we can indicate to the CPU whether
> > writes to a certain address range should be posted or not.  This is
> > done by specifying certain memory attributes in the mappings used by
> > the MMU.  The OpenBSD kernel always specifies device access as
> > non-posted.  On all ARM implementations we have seen so far this seems
> > to work even for writes to devices connected to a PCIe bus.  There
> > might be a penalty though, so I need to investigate this a bit
> > further.
> > 
> > However, on Apple's M1 SoC, this isn't the case.  Non-posted writes to
> > a bus that uses posted writes fail and vice-versa.  So in order to use
> > the PCIe bus on these SoCs we need to specify the right memory
> > attributes.  The diff below implements this by introducing a new
> > BUS_SPACE_MAP_POSTED flag.  At this point I don't expect generic
> > drivers to use this flag yet.  So there is no need to add it for other
> > architectures.  But I don't rule out we may have to use this flag in
> > sys/dev/fdt sometime in the future.  That is why I posted this to a
> > wider audience.
> 
> You don't want to (ab)use one of the existing flags? If I squint and read 
> kind of quickly I could imagine this is kind of like write combining, like 
> what BUS_SPACE_MAP_PREFETCHABLE can do on pci busses.

BUS_SPACE_MAP_PREFETCHABLE should be "normal uncached" memory on arm64,
which is different to device memory.  That said I have a device where
amdgpu(4) doesn't behave if it's "normal uncached", and I'm not sure if
it's the HW's fault or if there's some barrier missing.  Still, I would
not use BUS_SPACE_MAP_PREFETCHABLE for nGnRnE vs nGnRE.

More info on device vs normal is here:

https://developer.arm.com/documentation/102376/0100/Normal-memory
https://developer.arm.com/documentation/102376/0100/Device-memory

> If this does leak into fdt, would it just be a nop on other archs that use 
> those drivers?
> 
> dlg
> 
> > 
> > ok?
> > 
> > 
> > Index: arch/arm64/arm64/locore.S
> > ===
> > RCS file: /cvs/src/sys/arch/arm64/arm64/locore.S,v
> > retrieving revision 1.32
> > diff -u -p -r1.32 locore.S
> > --- arch/arm64/arm64/locore.S   19 Oct 2020 17:57:40 -  1.32
> > +++ arch/arm64/arm64/locore.S   14 Feb 2021 21:28:26 -
> > @@ -233,9 +233,10 @@ switch_mmu_kernel:
> > mair:
> > /* Device | Normal (no cache, write-back, write-through) */
> > .quad   MAIR_ATTR(0x00, 0) |\
> > -   MAIR_ATTR(0x44, 1) |\
> > -   MAIR_ATTR(0xff, 2) |\
> > -   MAIR_ATTR(0x88, 3)
> > +   MAIR_ATTR(0x04, 1) |\
> > +   MAIR_ATTR(0x44, 2) |\
> > +   MAIR_ATTR(0xff, 3) |\
> > +   MAIR_ATTR(0x88, 4)
> > tcr:
> > .quad (TCR_T1SZ(64 - VIRT_BITS) | TCR_T0SZ(64 - 48) | \
> > TCR_AS | TCR_TG1_4K | TCR_CACHE_ATTRS | TCR_SMP_ATTRS)
> > Index: arch/arm64/arm64/locore0.S
> > ===
> > RCS file: /cvs/src/sys/arch/arm64/arm64/locore0.S,v
> > retrieving revision 1.5
> > diff -u -p -r1.5 locore0.S
> > --- arch/arm64/arm64/locore0.S  28 May 2019 20:32:30 -  1.5
> > +++ arch/arm64/arm64/locore0.S  14 Feb 2021 21:28:26 -
> > @@ -34,8 +34,8 @@
> > #include 
> > 
> > #define DEVICE_MEM  0
> > -#defineNORMAL_UNCACHED 1
> > -#defineNORMAL_MEM  2
> > +#defineNORMAL_UNCACHED 2
> > +#defineNORMAL_MEM  3
> > 
> > /*
> >  * We assume:
> > Index: arch/arm64/arm64/machdep.c
> > ===
> > RCS file: /cvs/src/sys/arch/arm64/arm64/machdep.c,v
> > retrieving revision 1.57
> > diff -u -p -r1.57 machdep.c
> > --- arch/arm64/arm64/machdep.c  11 Feb 2021 23:55:48 -  1.57
> > +++ arch/arm64/arm64/machdep.c  14 Feb 2021 21:28:27 -
> > @@ -1188,7 +1188,7 @@ pmap_bootstrap_bs_map(bus_space_tag_t t,
> > 
> > for (pa = startpa; pa < endpa; pa += PAGE_SIZE, 

Re: Add missing break statement on if_rge.c

[Patrick Wildt]

Am Thu, Feb 11, 2021 at 12:24:37PM + schrieb Ricardo Mestre:
> Hi,
> 
> Add missing break statement. OK?

makes sense to me, ok patrick@

> CID 1501710
> 
> Index: if_rge.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_rge.c,v
> retrieving revision 1.11
> diff -u -p -c -u -r1.11 if_rge.c
> --- if_rge.c  24 Dec 2020 06:34:03 -  1.11
> +++ if_rge.c  11 Feb 2021 12:21:33 -
> @@ -311,6 +311,7 @@ rge_activate(struct device *self, int ac
>  #ifndef SMALL_KERNEL
>   rge_wol_power(sc);
>  #endif
> + break;
>   default:
>   rv = config_activate_children(self, act);
>   break;
> 

Re: isakmpd link dynamically

[Patrick Wildt]

Am Thu, Feb 11, 2021 at 11:29:58AM +0100 schrieb Alexander Bluhm:
> - recommit in /usr/src/usr.sbin -> we loose history

I know no one cares about git, but if the move was committed in a
"single cvs commit", git would understand it's simply a move of files.
So yeah, cvs wouldn't cope, but git would.

Re: Swapped arguments on stoeplitz_ip{4,6}port

[Patrick Wildt]

Already committed as of 7 minutes ago, heh!

Am Thu, Feb 11, 2021 at 10:48:16AM + schrieb Ricardo Mestre:
> Hi,
> 
> It seems this got the args swapped as described in CID 1501717.
> 
> stoeplitz_ip6port being a macro for stoeplitz_hash_ip6port and the arguments
> placed as shown below. Similarly stoeplitz_ip4port also has the same problem
> most likely due to copypasto.
> 
> Comments? OK?
> 
> 173 uint16_t
> 174 stoeplitz_hash_ip6port(const struct stoeplitz_cache *scache,
> 175 const struct in6_addr *faddr6, const struct in6_addr *laddr6,
> 176 in_port_t fport, in_port_t lport)
> 
> Index: netinet/in_pcb.c
> ===
> RCS file: /cvs/src/sys/netinet/in_pcb.c,v
> retrieving revision 1.253
> diff -u -p -u -r1.253 in_pcb.c
> --- netinet/in_pcb.c  25 Jan 2021 03:40:46 -  1.253
> +++ netinet/in_pcb.c  11 Feb 2021 10:34:50 -
> @@ -522,8 +522,8 @@ in_pcbconnect(struct inpcb *inp, struct 
>   inp->inp_fport = sin->sin_port;
>   in_pcbrehash(inp);
>  #if NSTOEPLITZ > 0
> - inp->inp_flowid = stoeplitz_ip4port(inp->inp_laddr.s_addr,
> - inp->inp_faddr.s_addr, inp->inp_lport, inp->inp_fport);
> + inp->inp_flowid = stoeplitz_ip4port(inp->inp_faddr.s_addr,
> + inp->inp_laddr.s_addr, inp->inp_fport, inp->inp_lport);
>  #endif
>  #ifdef IPSEC
>   {
> Index: netinet6/in6_pcb.c
> ===
> RCS file: /cvs/src/sys/netinet6/in6_pcb.c,v
> retrieving revision 1.111
> diff -u -p -u -r1.111 in6_pcb.c
> --- netinet6/in6_pcb.c25 Jan 2021 03:40:47 -  1.111
> +++ netinet6/in6_pcb.c11 Feb 2021 10:34:50 -
> @@ -303,8 +303,8 @@ in6_pcbconnect(struct inpcb *inp, struct
>   inp->inp_flowinfo |=
>   (htonl(ip6_randomflowlabel()) & IPV6_FLOWLABEL_MASK);
>  #if NSTOEPLITZ > 0
> - inp->inp_flowid = stoeplitz_ip6port(>inp_laddr6,
> - >inp_faddr6, inp->inp_lport, inp->inp_fport);
> + inp->inp_flowid = stoeplitz_ip6port(>inp_faddr6,
> + >inp_laddr6, inp->inp_fport, inp->inp_lport);
>  #endif
>   in_pcbrehash(inp);
>   return (0);
> 

Re: rasops1

[Patrick Wildt]

Am Wed, Dec 23, 2020 at 11:32:58PM +0100 schrieb Frederic Cambus:
> Hi Mark,
> 
> On Fri, Dec 18, 2020 at 10:33:52PM +0100, Mark Kettenis wrote:
> 
> > The diff below disables the optimized functions on little-endian
> > architectures such that we always use rasops1_putchar().  This makes
> > ssdfb(4) work with the default 8x16 font on arm64.
> 
> I noticed it was committed already, but it seems the following
> directives:
> 
> #if defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
> 
> Should have been:
> 
> #if !defined(RASOPS_SMALL) && BYTE_ORDER == BIG_ENDIAN
> 
> We want to include the optimized putchar functions only if RASOPS_SMALL
> is not defined.
> 

True that.  In one #endif comment he actually kept the !, but the actual
ifs lost it.

Re: tsleep(9): add global "nowake" channel

[Patrick Wildt]

Am Wed, Dec 23, 2020 at 05:04:23PM -0600 schrieb Scott Cheloha:
> On Wed, Dec 23, 2020 at 02:42:18PM -0700, Theo de Raadt wrote:
> > I agree.  This chunk below is really gross and does not follow the
> > special wakeup channel metaphor.
> > 
> > It is *entirely clear* that a  called "nowake" has no wakeup.
> > Like duh.
> > 
> > > +/*
> > > + * nowake is a global sleep channel for threads that do not want
> > > + * to receive wakeup(9) broadcasts.
> > > + */
> > > +int __nowake;
> > > +void *nowake = &__nowake;
> 
> So we'll go with this?
> 
> Index: kern/kern_synch.c
> ===
> RCS file: /cvs/src/sys/kern/kern_synch.c,v
> retrieving revision 1.172
> diff -u -p -r1.172 kern_synch.c
> --- kern/kern_synch.c 7 Dec 2020 16:55:29 -   1.172
> +++ kern/kern_synch.c 23 Dec 2020 23:03:31 -
> @@ -87,6 +87,11 @@ sleep_queue_init(void)
>   TAILQ_INIT([i]);
>  }
>  
> +/*
> + * Global sleep channel for threads that do not want to
> + * receive wakeup(9) broadcasts.
> + */
> +int nowake;
>  
>  /*
>   * During autoconfiguration or after a panic, a sleep will simply
> @@ -119,6 +124,7 @@ tsleep(const volatile void *ident, int p
>  #endif
>  
>   KASSERT((priority & ~(PRIMASK | PCATCH)) == 0);
> + KASSERT(ident != nowake || ISSET(priority, PCATCH) || timo != 0);

Sure you compiled this? ident is void *, nowake is int.  Should be ident
!= ?  Same for the other code in the diff.

>  
>  #ifdef MULTIPROCESSOR
>   KASSERT(timo || _kernel_lock_held());
> @@ -213,6 +219,7 @@ msleep(const volatile void *ident, struc
>  #endif
>  
>   KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0);
> + KASSERT(ident != nowake || ISSET(priority, PCATCH) || timo != 0);
>   KASSERT(mtx != NULL);
>  
>   if (priority & PCATCH)
> @@ -301,6 +308,7 @@ rwsleep(const volatile void *ident, stru
>   int error, status;
>  
>   KASSERT((priority & ~(PRIMASK | PCATCH | PNORELOCK)) == 0);
> + KASSERT(ident != nowake || ISSET(priority, PCATCH) || timo != 0);
>   rw_assert_anylock(rwl);
>   status = rw_status(rwl);
>  
> Index: sys/systm.h
> ===
> RCS file: /cvs/src/sys/sys/systm.h,v
> retrieving revision 1.148
> diff -u -p -r1.148 systm.h
> --- sys/systm.h   26 Aug 2020 03:29:07 -  1.148
> +++ sys/systm.h   23 Dec 2020 23:03:31 -
> @@ -107,6 +107,8 @@ extern struct vnode *rootvp;  /* vnode eq
>  extern dev_t swapdev;/* swapping device */
>  extern struct vnode *swapdev_vp;/* vnode equivalent to above */
>  
> +extern int nowake;   /* dead wakeup(9) channel */
> +
>  struct proc;
>  struct process;
>  #define curproc curcpu()->ci_curproc
> 

Re: xhci zero length transfers 'leak' one transfer buffer count

[Patrick Wildt]

Am Wed, Dec 23, 2020 at 10:44:21AM +0100 schrieb Marcus Glocker:
> On Wed, 23 Dec 2020 09:47:44 +0100
> Marcus Glocker  wrote:
> 
> > On Tue, 22 Dec 2020 20:55:41 +0100
> > Marcus Glocker  wrote:
> > 
> > > > > Did you consider incrementing xx->ntrb instead?
> > >   
> > > >That doesn't work either, because the status completion code needs
> > > >xx->ntrb to be correct for the data TD to be handled correctly.
> > > >Incrementing xx->ntrb means the number of TRBs for the data TD is
> > > >incorrect, since it includes the (optional) zero TD's TRB.
> > > >
> > > >In this case the zero TD allocates a TRB but doesn't do proper
> > > >accounting, and currently there's no place where this could be
> > > >accounted properly.
> > > >
> > > >In the end it's all software, so I guess the diff will simply have
> > > >to be bigger than just a one-liner.
> > >   
> > > > > With the diff below the produced TRB isn't accounted which might
> > > > > lead
> > > > > to and off-by-one.
> > > 
> > > Sorry, I missed this thread and had to re-grab the last mail from
> > > MARC.
> > > 
> > > Can't we just take account of the zero trb separately?  
> > 
> > We also want to reset the zerotrb.
> 
> Re-thinking this again I think we should only increase the zerotrb to
> avoid again a possible miss match for free_trbs, and leave the
> responsibility to the caller of xhci_xfer_get_trb() to request the
> right amount of zerotrb.
> 
> 
> Index: dev/usb/xhci.c
> ===
> RCS file: /cvs/src/sys/dev/usb/xhci.c,v
> retrieving revision 1.119
> diff -u -p -u -p -r1.119 xhci.c
> --- dev/usb/xhci.c31 Jul 2020 19:27:57 -  1.119
> +++ dev/usb/xhci.c23 Dec 2020 09:38:58 -
> @@ -1135,8 +1135,10 @@ xhci_xfer_done(struct usbd_xfer *xfer)
>   i = (xp->ring.ntrb - 1);
>   }
>   xp->free_trbs += xx->ntrb;
> + xp->free_trbs += xx->zerotrb;
>   xx->index = -1;
>   xx->ntrb = 0;
> + xx->zerotrb = 0;
>  
>   timeout_del(>timeout_handle);
>   usb_rem_task(xfer->device, >abort_task);
> @@ -1842,6 +1844,7 @@ xhci_xfer_get_trb(struct xhci_softc *sc,
>   switch (last) {
>   case -1:/* This will be a zero-length TD. */
>   xp->pending_xfers[xp->ring.index] = NULL;
> + xx->zerotrb += 1;
>   break;
>   case 0: /* This will be in a chain. */
>   xp->pending_xfers[xp->ring.index] = xfer;
> Index: dev/usb/xhcivar.h
> ===
> RCS file: /cvs/src/sys/dev/usb/xhcivar.h,v
> retrieving revision 1.11
> diff -u -p -u -p -r1.11 xhcivar.h
> --- dev/usb/xhcivar.h 6 Oct 2019 17:30:00 -   1.11
> +++ dev/usb/xhcivar.h 23 Dec 2020 09:38:58 -
> @@ -40,6 +40,7 @@ struct xhci_xfer {
>   struct usbd_xfer xfer;
>   int  index; /* Index of the last TRB */
>   size_t   ntrb;  /* Number of associated TRBs */
> + size_t   zerotrb;   /* Is zero len TRB required? */

It's a zero-length TD, not TRB.  I mean, it indeed is a zero-legth TRB,
but the important thing is that it's part of an extra TD.  So at least
update the comment, maybe even the variable name.

The difference is that a TD means that it's a separate transfer.  It
also completes seperately from the TD before.  In theory xfer done will
be called on the initial TD, not on the zero TD, which means that we
could have a race where our accounting "frees" the zero TD, even though
the controller isn't there yet.  In practice I think this is not an
issue, the ring's hopefully long enough that we don't immediately reuse
the TRB that we just freed.

So, I think the approach taken in this diff is fine, the code looks
good, only the naming I think can be improved.  Maybe really just call
it zerotd, then it also fits with the comment.

>  };
>  
>  struct xhci_ring {
> 

Re: uplcom driver update for 23a3 (HXN) chip

[Patrick Wildt]

On Mon, Oct 26, 2020 at 09:12:17AM +0100, Stefan Huber wrote:
> Hey all,
> 
> I recently got hands on an USB-TTY converter that is not (yet) supported by
> OpenBSD:
> 
> > addr 03: 067b:23a3 Prolific Technology Inc., USB-Serial Controller
> 
> Simply adding the device ID to usbdevs and the uplcom driver did not do the
> trick, as apparently it is what the linux driver calls a "HXN" chip, which
> is (as of now) not yet supported by the uplcom driver (also, not in NetBSD
> where the uplcom driver seems to come from). Some hours (days) later, I have
> produced the following diff, butchering both the uplcom and the linux
> driver. I know it looks like shit, but it works (for now and for me). I will
> try to "streamline" the driver, and am happy for any feedback (since you may
> see watching the code I am not a good kernel hacker yet).
> 
> I was also thinking of adding all the other IDs from the linux driver to
> uplcom, but then I can't test them since I only have the two chips 067b:2303
> and 067b:23a3. So I'd rather not merge the other IDs to prevent the kernel
> from doing nasty things to them (or was it the other way around?)
> 
> The diff's below. Works for me. Not looking for okay or a merge, mostly
> feedback and maybe a merge for a future version of this diff.

First of all, we need unified diffs.  Usually you have a CVS checkout
and then run cvs diff -u.  Yours don't look like you used cvs, was that
a diff -r?  Well, even then you should add -u, otherwise diffs become
unreadable.

Second, only OpenBSD account holders can ask for OKs. :)

So, please resend with diff -u, otherwise no one will have a look at it
since the diff is hard to follow.

Thanks,
Patrick

> Happy Hacking,
> Stefan
> 
> 
> Common subdirectories: /home/src_orig/sys/dev/usb/CVS and
> /usr/src/sys/dev/usb/CVS
> Common subdirectories: /home/src_orig/sys/dev/usb/dwc2 and
> /usr/src/sys/dev/usb/dwc2
> diff /home/src_orig/sys/dev/usb/uplcom.c /usr/src/sys/dev/usb/uplcom.c
> 66c66
> < #define DPRINTF(x) DPRINTFN(0, x)
> ---
> > #define DPRINTF(x) printf x;
> 71a72,74
> > #define UPLCOM_SET_NREQUEST 0x80
> > #define UPLCOM_READ_REQUEST 0x01
> > #define UPLCOM_READ_NREQUEST0x81
> 77a81,91
> > #define UPLCOM_READ_HX_STATUS   0x8080
> > #define UPLCOM_HXN_RESET_REG0x07
> > #define UPLCOM_HXN_RESET_UPSTREAM_PIPE  0x02
> > #define UPLCOM_HXN_RESET_DOWNSTREAM_PIPE0x01
> > 
> > #define UPLCOM_HXN_FLOWCTRL_REG 0x0a
> > #define UPLCOM_HXN_FLOWCTRL_MASK0x1c
> > #define UPLCOM_HXN_FLOWCTRL_NONE0x1c
> > #define UPLCOM_HXN_FLOWCTRL_RTS_CTS 0x18
> > #define UPLCOM_HXN_FLOWCTRL_XON_XOFF0x0c
> > 
> 98a113
> > int  sc_type_hxn;   /* HXN variant */
> 108a124,127
> > usbd_status uplcom_update_reg(struct uplcom_softc *sc, char reg, char
> > mask, char val);
> > usbd_status uplcom_vendor_read(struct uplcom_softc *sc, char val, char
> > buf[1]);
> > usbd_status uplcom_vendor_write(struct uplcom_softc *sc, char val, char
> > index);
> > int uplcom_test_hxn(struct uplcom_softc *);
> 153a173
> > { USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL23a3 },
> 250c270,272
> < if (ddesc->bDeviceClass == 0x02)
> ---
> > printf("[DEBUG] DeviceClass: %x\n", ddesc->bDeviceClass);
> > printf("[DEBUG] MaxPacketSize: %x\n", ddesc->bMaxPacketSize);
> > if (ddesc->bDeviceClass == 0x02) { /* type 0 */
> 252c274,276
> < else if (ddesc->bMaxPacketSize == 0x40)
> ---
> > sc->sc_type_hxn = 0;
> > }
> > else if (ddesc->bMaxPacketSize == 0x40) { /* type hx */
> 254c278,280
> < else
> ---
> > sc->sc_type_hxn = 0;
> > }
> > else { /* probably type 1 */
> 255a282,283
> > sc->sc_type_hxn = 0;
> > }
> 256a285,298
> > /*
> >  * The Linux driver also distinguishes HXN variant...
> >  * Let's see if that is needed for the 23a3 variant.
> >  */
> > if (sc->sc_type_hx == 1) {
> > printf("[DEBUG] seems to be HX type. Checking for HXN type.\n");
> > if (uplcom_test_hxn(sc)) {
> > printf("[DEBUG] Probably HXN.\n");
> > sc->sc_type_hxn = 1;
> > } else {
> > printf("[DEBUG] Probably not HXN.\n");
> > }
> > }
> > 
> 259c301,303
> < if (sc->sc_type_hx) {
> ---
> > if (sc->sc_type_hxn) {
> > DPRINTF(("uplcom_attach: chiptype 2303XN\n"));
> > } else if (sc->sc_type_hx) {
> 419a464,471
> > 
> > if (sc->sc_type_hxn) {
> > DPRINTF(("[DEBUG] trying to reset hxn\n"));
> > req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
> > req.bRequest = UPLCOM_SET_NREQUEST;
> > USETW(req.wValue, 0x07);
> > USETW(req.wIndex, UPLCOM_HXN_RESET_UPSTREAM_PIPE |
> > UPLCOM_HXN_RESET_DOWNSTREAM_PIPE);
> > USETW(req.wLength, 0);
> 421,425c473,484
> < 

Re: xhci zero length transfers 'leak' one transfer buffer count

[Patrick Wildt]

On Sun, Oct 11, 2020 at 08:12:29AM +0200, Martin Pieuchot wrote:
> On 09/10/20(Fri) 12:37, Jonathon Fletcher wrote:
> > In xhci_xfer_get_trb, the count of transfer buffers in the pipe 
> > (xp->free_trbs) is always decremented but the count of transfer buffers 
> > used in the transfer (xx->ntrb) is not incremented for zero-length 
> > transfers. The result of this is that, at the end of a zero length 
> > transfer, xp->free_trbs has 'lost' one.
> > 
> > Over time, this mismatch of unconditional decrement (xp->free_trbs) vs 
> > conditional increment (xx->ntrb) results in xhci_device_*_start returning 
> > USBD_NOMEM.
> > 
> > The patch below works around this by only decrementing xp->free_trbs in the 
> > cases when xx->ntrb is incremented.
> 
> Did you consider incrementing xx->ntrb instead?

That doesn't work either, because the status completion code needs
xx->ntrb to be correct for the data TD to be handled correctly.
Incrementing xx->ntrb means the number of TRBs for the data TD is
incorrect, since it includes the (optional) zero TD's TRB.

In this case the zero TD allocates a TRB but doesn't do proper
accounting, and currently there's no place where this could be
accounted properly.

In the end it's all software, so I guess the diff will simply have
to be bigger than just a one-liner.

> With the diff below the produced TRB isn't accounted which might lead to
> and off-by-one.
> 
> > Index: xhci.c
> > ===
> > RCS file: /cvs/src/sys/dev/usb/xhci.c,v
> > retrieving revision 1.119
> > diff -u -p -u -r1.119 xhci.c
> > --- xhci.c  31 Jul 2020 19:27:57 -  1.119
> > +++ xhci.c  9 Oct 2020 19:11:45 -
> > @@ -1836,7 +1836,6 @@ xhci_xfer_get_trb(struct xhci_softc *sc,
> > struct xhci_xfer *xx = (struct xhci_xfer *)xfer;
> >  
> > KASSERT(xp->free_trbs >= 1);
> > -   xp->free_trbs--;
> > *togglep = xp->ring.toggle;
> >  
> > switch (last) {
> > @@ -1847,11 +1846,13 @@ xhci_xfer_get_trb(struct xhci_softc *sc,
> > xp->pending_xfers[xp->ring.index] = xfer;
> > xx->index = -2;
> > xx->ntrb += 1;
> > +   xp->free_trbs--;
> > break;
> > case 1: /* This will terminate a chain. */
> > xp->pending_xfers[xp->ring.index] = xfer;
> > xx->index = xp->ring.index;
> > xx->ntrb += 1;
> > +   xp->free_trbs--;
> > break;
> > }
> >  
> > 
>