Re: Enable arm64 PAN feature

2020-08-15 Thread Dale Rahn
Enabling PAN is a great idea. I have only skimmed this diff at this point, but it looks reasonable, with the additional check to catch the PAN violation in the data abort handler. Dale On Sat, Aug 15, 2020 at 6:56 AM Mark Kettenis wrote: > > Date: Sat, 15 Aug 2020 20:21:09 +1000 > > From: Jonat

Re: cosmetic sdmmc(4) diff

2020-08-15 Thread Stefan Sperling
On Sat, Aug 15, 2020 at 02:56:25PM +0200, Mark Kettenis wrote: > This diff makes sdmmc(4) print ddr52 and hs200 capabilities, making it > possible to see whether a controller supports these high-speed eMMC > modes. > > ok? ok stsp@ > Index: dev/sdmmc/sdmmc.c > ===

cosmetic sdmmc(4) diff

2020-08-15 Thread Mark Kettenis
This diff makes sdmmc(4) print ddr52 and hs200 capabilities, making it possible to see whether a controller supports these high-speed eMMC modes. ok? Index: dev/sdmmc/sdmmc.c === RCS file: /cvs/src/sys/dev/sdmmc/sdmmc.c,v retrieving

Re: Enable arm64 PAN feature

2020-08-15 Thread Mark Kettenis
> Date: Sat, 15 Aug 2020 20:21:09 +1000 > From: Jonathan Gray > > On Fri, Aug 14, 2020 at 11:06:59PM +0200, Mark Kettenis wrote: > > > Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST) > > > From: Mark Kettenis > > > > > > I suppose a way to test this properly is to pick a system call and > > > repl

Re: Enable arm64 PAN feature

2020-08-15 Thread Jonathan Gray
On Fri, Aug 14, 2020 at 11:06:59PM +0200, Mark Kettenis wrote: > > Date: Fri, 14 Aug 2020 14:40:23 +0200 (CEST) > > From: Mark Kettenis > > > > I suppose a way to test this properly is to pick a system call and > > replace a copyin() with a direct access? That will succeed without > > PAN but sh

Re: kqueue_scan_setup/finish

2020-08-15 Thread Visa Hankala
On Fri, Aug 14, 2020 at 12:31:33PM +0200, Martin Pieuchot wrote: > The previous change introducing the kqueue_scan_setup()/finish() API > required to switch poll(2) internals to use the kqueue mechanism has > been backed out. The reason for the regression is still unknown, so > let's take a baby s

Re: Make pipex more common for pppac and pppx

2020-08-15 Thread YASUOKA Masahiko
Let me update the diff. A bug found by the test. diff --git a/sys/net/if_pppx.c b/sys/net/if_pppx.c index 62b85bc34af..6d3de6973bd 100644 --- a/sys/net/if_pppx.c +++ b/sys/net/if_pppx.c @@ -163,7 +163,6 @@ struct pppx_if { struct ifnetpxi_if; struct pppx_dev *p

Make pipex more common for pppac and pppx

2020-08-15 Thread YASUOKA Masahiko
This diff makes pipex become more common for pppac and pppx. - Delete "pipex_iface_context". It had been created when pppx doesn't exist. This creates some confusions. For example session->pipex_iface is the device context when pppac(4) but it's not when pppx(4). 623 Static int

Typo fix in comment sys/dev/usb/ugold.c

2020-08-15 Thread Paul de Weerd
While looking at ugold.c I noticed a typo in a comment. Diff below. Cheers, Paul Index: ugold.c === RCS file: /home/OpenBSD/cvs/src/sys/dev/usb/ugold.c,v retrieving revision 1.14 diff -u -p -r1.14 ugold.c --- ugold.c 5 Oct 201

Re: sensor value last change time not updated?

2020-08-15 Thread Paul de Weerd
Thanks Hiltjo, that made me look at ugold.c. With the below diff, my simple test program shows a value for the tv struct member. [weerd@pom] $ ./sensor_last_change 1597477798.557355: 28.72 However, given what Hiltjo showed, the tv member seems to only be used for time-sensors, so it may be compl