Re: dwge(4): don't panic on truncated input packet

2023-10-18 Thread Mark Kettenis
> Date: Wed, 18 Oct 2023 16:40:20 + > From: Miod Vallat > > I had the misfortune of hitting a KASSERT in dwge: > > panic: kernel diagnostic assertion "len > 0" failed: file > "/usr/src/sys/dev/fdt > /if_dwge.c", line 1102 > Stopped at panic+0x106:addia0,zero,256TIDPID

Re: bwfm(4): support scan v3

2023-10-13 Thread Mark Kettenis
> Date: Wed, 11 Oct 2023 10:10:58 +0200 > From: Stefan Sperling > > On Tue, Oct 10, 2023 at 11:41:39PM +0200, Mark Kettenis wrote: > > The firmware for the BCM4388 has yet another version of the "escan" > > command. But we can treat it the same as v2 since

Re: initial Intel Elkhart Lake Ethernet support / dwqe(4) at pci

2023-10-11 Thread Mark Kettenis
> Date: Wed, 11 Oct 2023 10:27:24 +0200 > From: Stefan Sperling > > On Tue, Oct 10, 2023 at 09:06:59PM +0200, Mark Kettenis wrote: > > > OK for your diff. Please put it in and I'll rebase on top. > > > > done > > Thanks. Here is a rebased version. Re-tes

bwfm(4): support scan v3

2023-10-10 Thread Mark Kettenis
The firmware for the BCM4388 has yet another version of the "escan" command. But we can treat it the same as v2 since it just added a new parameter in place of some padding. We just set that new parameter to zero, which doesn't change anything. As a bonus this adds some missing htole16() calls.

Re: initial Intel Elkhart Lake Ethernet support / dwqe(4) at pci

2023-10-10 Thread Mark Kettenis
> Date: Tue, 10 Oct 2023 20:49:46 +0200 > From: Stefan Sperling > > On Tue, Oct 10, 2023 at 08:41:37PM +0200, Mark Kettenis wrote: > > So the GMAC_VERSION #define is simply wrong. We should commit the > > diff attached and drop the sc_core stuff you added below.

Re: initial Intel Elkhart Lake Ethernet support / dwqe(4) at pci

2023-10-10 Thread Mark Kettenis
> Date: Tue, 10 Oct 2023 19:40:31 +0200 > From: Stefan Sperling > > This patch adds enough code to get Elkart Lake devices with PCI > Vendor ID 8086 and Product ID 4ba0 to attach and pass traffic. > > dwqe0 at pci0 dev 29 function 1 "Intel Elkhart Lake Ethernet" rev 0x11: rev > 0x52, address

Re: Some bwfm(4) diffs

2023-10-09 Thread Mark Kettenis
> Date: Mon, 09 Oct 2023 20:31:04 +0200 > From: Mark Kettenis > > > Date: Mon, 9 Oct 2023 06:09:57 +0200 > > From: "Peter J. Philipp" > > > > On Sun, Oct 08, 2023 at 07:42:54PM +0200, Mark Kettenis wrote: > > > Hector Martin has added sup

Re: Some bwfm(4) diffs

2023-10-09 Thread Mark Kettenis
> Date: Mon, 9 Oct 2023 06:09:57 +0200 > From: "Peter J. Philipp" > > 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 h

Some bwfm(4) diffs

2023-10-08 Thread Mark Kettenis
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

Re: [patch] [arm64] cpu.c patch based on amd64 idea, provides more debug for multicore kernel

2023-10-05 Thread Mark Kettenis
> From: S V > Date: Thu, 5 Oct 2023 12:58:51 +0300 > > чт, 5 окт. 2023 г., 09:59 Mark Kettenis : > > > > > Date: Thu, 5 Oct 2023 04:10:10 + > > > From: Klemens Nanni > > > > > > On Mon, Sep 25, 2023 at 01:33:31PM +, Klemens Nanni w

Re: [patch] [arm64] cpu.c patch based on amd64 idea, provides more debug for multicore kernel

2023-10-05 Thread Mark Kettenis
> Date: Thu, 5 Oct 2023 04:10:10 + > From: Klemens Nanni > > On Mon, Sep 25, 2023 at 01:33:31PM +, Klemens Nanni wrote: > > On Tue, Jul 25, 2023 at 01:30:43PM +0300, Slava Voronzoff wrote: > > > Hi, pinging and refreshing this patch > > > > > > What it does: > > > allow arm64 cpus to

Re: Inexplicable SIGILL in firefox

2023-10-01 Thread Mark Kettenis
> From: Greg Steuck > Date: Sun, 01 Oct 2023 13:42:21 -0700 > > I had firefox crash on me but the core looks suspect. I don't understand > why `push %r15` is an invalid instruction. > > % egdb /usr/local/lib/firefox/firefox ~/firefox.core > GNU gdb (GDB) 9.2 > ... > [New process 561871] > >

Re: prevent re-upgrade in powerpc64 boot loader

2023-09-23 Thread Mark Kettenis
> Date: Thu, 21 Sep 2023 22:30:01 + > From: Klemens Nanni > > In comparison to MI boot which only cares about /bsd.upgrade's x bit, > powerpc64 rdboot just wants a regular file. > > Require and strip u+x before execution to prevent sysupgrade(8) loop. > I'm new to powerpc64 and can't think

Re: powerpc64 BOOT kernel question

2023-09-23 Thread Mark Kettenis
> Date: Fri, 22 Sep 2023 23:19:30 + > From: Klemens Nanni > > Does the tiny kexec kernel actually need network, bio(4) or HID devices? > octeon/BOOT does not have any of this. Well, we do need the USB keyboard stuff to allow users to type at the bootloader prompt no? The USB mouse is

Re: CVS: cvs.openbsd.org: xenocara

2023-09-07 Thread Mark Kettenis
> Date: Thu, 7 Sep 2023 22:02:12 +0200 > From: Matthieu Herrb > > On Thu, Sep 07, 2023 at 05:24:56PM +0200, Matthieu Herrb wrote: > > On Thu, Sep 07, 2023 at 07:11:40AM +0200, Anton Lindqvist wrote: > > > On Wed, Sep 06, 2023 at 05:42:37AM -0600, Robert Nagy wrote: > > > > CVSROOT:/cvs >

Re: VisionFive 2

2023-09-02 Thread Mark Kettenis
com/ > > Does this mean a new driver for the vf2 like rkdwhdmi would be > "needed" to support hdmi in OpenBSD? In principle support in u-boot would be enough to give OpenBSD a framebuffer console. > Am 3. Aug. 2023, 15:41, um 15:41, Mark Kettenis > schrieb: > >&g

Re: anon & pmap_page_protect

2023-09-01 Thread Mark Kettenis
> Date: Fri, 1 Sep 2023 23:02:59 +0200 > From: Martin Pieuchot > > On 12/08/23(Sat) 10:43, Martin Pieuchot wrote: > > Since UVM has been imported, we zap mappings associated to anon pages > > before deactivating or freeing them. Sadly, with the introduction of > > locking for amaps & anons, I

Re: JH7110 PCIe device tree binding update

2023-08-29 Thread Mark Kettenis
> Date: Tue, 29 Aug 2023 11:58:23 +0200 > From: Mark Kettenis > > Upstreaming of the JH7110 PCIe device tree bindings isn't finished > yet, but it seems some progress has been made and things have been > reviewed by some of the key people involved: > > https://patc

JH7110 PCIe device tree binding update

2023-08-29 Thread Mark Kettenis
Upstreaming of the JH7110 PCIe device tree bindings isn't finished yet, but it seems some progress has been made and things have been reviewed by some of the key people involved: https://patchwork.kernel.org/project/linux-pci/list/?series=779297 Here is a diff that adjusts the driver to the

Re: uvm_pagelookup(): moar sanity checks

2023-08-11 Thread Mark Kettenis
> Date: Fri, 11 Aug 2023 21:34:45 +0200 > From: Martin Pieuchot > > On 11/08/23(Fri) 20:41, Mark Kettenis wrote: > > > Date: Fri, 11 Aug 2023 20:12:19 +0200 > > > From: Martin Pieuchot > > > > > > Here's a simple diff to add some more sanity

Re: uvm_pagelookup(): moar sanity checks

2023-08-11 Thread Mark Kettenis
> Date: Fri, 11 Aug 2023 20:12:19 +0200 > From: Martin Pieuchot > > Here's a simple diff to add some more sanity checks in uvm_pagelookup(). > > Nothing fancy, it helps documenting the flags and reduce the difference > with NetBSD. This is part of my on-going work on UVM. > > ok? NetBSD

Re: installer: disk crypto: crank KDF rounds to hardware based default

2023-08-11 Thread Mark Kettenis
> From: "Theo de Raadt" > Date: Fri, 11 Aug 2023 08:50:32 -0600 > > Mark Kettenis wrote: > > > > Date: Fri, 11 Aug 2023 11:13:23 + > > > From: Klemens Nanni > > > > > > On Mon, May 08, 2023 at 11:00:27AM +, Klemens

Re: installer: disk crypto: crank KDF rounds to hardware based default

2023-08-11 Thread Mark Kettenis
> Date: Fri, 11 Aug 2023 11:13:23 + > From: Klemens Nanni > > On Mon, May 08, 2023 at 11:00:27AM +, Klemens Nanni wrote: > > On Sun, Apr 23, 2023 at 05:07:30PM +, Klemens Nanni wrote: > > > For new installs, it seems adequate to base the number on the actual > > > hardware, > > >

Re: agtimer(4/arm64): simplify agtimer_delay()

2023-08-10 Thread Mark Kettenis
> Date: Thu, 10 Aug 2023 16:01:10 -0500 > From: Scott Cheloha > > On Tue, Aug 08, 2023 at 08:00:47PM +0200, Mark Kettenis wrote: > > > From: Dale Rahn > > > Date: Tue, 8 Aug 2023 12:36:45 -0400 > > > > > > Switching the computation of cycles/

Re: agtimer(4/arm64): simplify agtimer_delay()

2023-08-08 Thread Mark Kettenis
> From: Dale Rahn > Date: Tue, 8 Aug 2023 12:36:45 -0400 > > Switching the computation of cycles/delaycnt to a proper 64 value math > instead of the '32 bit safe' complex math is likely a good idea. > However I am not completely convinced that switching to 'yield' (current > CPU_BUSY_CYCLE

Re: VisionFive 2

2023-08-03 Thread Mark Kettenis
> Date: Tue, 01 Aug 2023 23:11:43 +0200 > From: Robert Palm > > I own a VF 2 version 1.2a and can successfully install / boot the machine. > > The inner network port (dwqe1) works at 100 full duplex and receives > ipv4 via DHCP. > > The outer port currently doesn't seem to get an ip, but

Re: uvm_loadav: don't recompute schedstate_percpu.spc_nrun

2023-08-03 Thread Mark Kettenis
> Date: Thu, 3 Aug 2023 12:56:01 +0200 > From: Claudio Jeker > > On Thu, Aug 03, 2023 at 10:53:24AM +0200, Claudio Jeker wrote: > > On Thu, Aug 03, 2023 at 10:13:57AM +0200, Martin Pieuchot wrote: > > > On 02/08/23(Wed) 14:22, Claudio Jeker wrote: > > > > On Mon, Jul 31, 2023 at 10:21:11AM

Re: axppmic(4): axp313a support

2023-08-01 Thread Mark Kettenis
> Date: Tue, 01 Aug 2023 22:34:05 +0900 > From: SASANO Takayoshi > > hi, > > > maybe add a note that the data sheet is wrong for dcdc3? > > The datasheet issue is written in Linux code at > https://elixir.bootlin.com/linux/v6.5-rc4/source/drivers/regulator/axp20x-regulator.c#L725 > > > /* > >

Re: axppmic(4): axp313a support

2023-07-31 Thread Mark Kettenis
> Date: Mon, 31 Jul 2023 22:12:35 +0900 > From: SASANO Takayoshi > > Hi, > > Mango Pi MQ-Quad and OrangePi Zero3 has X-Power AXP313A PMIC. > > Here is a diff, but AXP313A's dcdc1 is not fully supported. > > dcdc1 has three voltage ranges: > 0.5-1.2V, 10mV/step (71 steps) >

Re: arm64 BTI support for mpg123

2023-07-25 Thread Mark Kettenis
> From: "Theo de Raadt" > Date: Tue, 25 Jul 2023 08:23:14 -0600 > > Christian Weisgerber wrote: > > > Mark Kettenis: > > > > > This port has some infrastructure to use an optimized function that > > > uses a function pointer. Not sure w

Make USB WiFi drivers more robust

2023-07-24 Thread Mark Kettenis
Hi All, I recently committed a change to the xhci(4) driver that fixed an issue with suspending a machine while it has USB devices plugged in. Unfortunately this diff had some unintended side effects. After looking at the way the USB stack works, I've come to the conclusion that it is best to

Re: [Diff] Keyboard backlight support for late powerbooks, plus keybindings

2023-07-23 Thread Mark Kettenis
> Date: Sun, 23 Jul 2023 15:21:38 +0200 > From: Anton Lindqvist > > On Sun, Jul 23, 2023 at 11:37:38AM +, jon@elytron.openbsd.amsterdam wrote: > > Hello all. Thank you very much for your input. I have taken heed of > > your suggestions in the diff below > > > > On Sat, 22 Jul 2023 20:59:04

Re: assign wsdisplay0 to the glass console

2023-07-19 Thread Mark Kettenis
> Date: Wed, 19 Jul 2023 16:12:59 +0900 (JST) > From: YASUOKA Masahiko > > Hi, > > I noticed that the keyboard doesn't work for RAMDISK kernel on HP DL20 > Gen10. The kernel assigns wsdisplay0 for VGA and wsdisplay1 for > efifb. But actually the glass console is efieb but it doesn't have >

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-11 Thread Mark Kettenis
> Date: Tue, 11 Jul 2023 15:28:22 -0500 > From: Scott Cheloha > > On Mon, Jul 10, 2023 at 10:41:15AM -0500, Scott Cheloha wrote: > > On Mon, Jul 10, 2023 at 05:19:35PM +0200, Mark Kettenis wrote: > > > > Date: Mon, 10 Jul 2023 09:57:39 -0500 > > > > Fr

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-10 Thread Mark Kettenis
> Date: Mon, 10 Jul 2023 09:57:39 -0500 > From: Scott Cheloha > > On Mon, Jul 10, 2023 at 07:42:55AM -0600, Theo de Raadt wrote: > > I dare you to write the simplest fix for this, instead of a diff that > > scrolls by. > > This patch seems to work. Will need to bang on it for a few more days.

Re: GPROF: sleep_state: disable _mcount() across suspend/resume

2023-07-10 Thread Mark Kettenis
> Date: Sun, 9 Jul 2023 17:24:41 -0500 > From: Scott Cheloha > > On Sun, Jul 09, 2023 at 08:11:43PM +0200, Claudio Jeker wrote: > > On Sun, Jul 09, 2023 at 12:52:20PM -0500, Scott Cheloha wrote: > > > This patch fixes resume/unhibernate on GPROF kernels where kgmon(8) > > > has activated kernel

Re: m2: add suspend keyboard shortcut

2023-07-08 Thread Mark Kettenis
> Date: Sat, 8 Jul 2023 16:54:25 +0200 > From: Tobias Heider > > Now that we have request_sleep() we can add a new internal KS_Cmd_Sleep > keycode, map it into the macbook keyboard, catch in wskbd and go to sleep. > > ok? Looks good to me, but I'd like to hear what miod@ has to say about this.

Re: request_sleep: new machine independent sleep api

2023-07-08 Thread Mark Kettenis
> Date: Sat, 8 Jul 2023 10:10:51 +0200 > From: Tobias Heider > > This diff adds request_sleep(), a MI way of sending the machine to sleep in a > safe thread. Support is limited to amd64, i386 and arm64 at the moment, macppc > is currently an empty stub since it doesn't implement a sleep task

Re: acpi: move acpiioctl to x86

2023-07-08 Thread Mark Kettenis
> Date: Fri, 7 Jul 2023 11:56:42 +0200 > From: Tobias Heider > > On Wed, Jul 05, 2023 at 04:53:33PM +0200, Tobias Heider wrote: > > I am planning to restructure the APM/sleep APIs to make it easier to suspend > > from more places like as a suspend keyboard shortcut. > > > > The acpiioctl

Re: axppmic(4): revise (fix axppmic_regdata table, axp305 support)

2023-07-06 Thread Mark Kettenis
> Date: Thu, 06 Jul 2023 22:27:59 +0900 > From: SASANO Takayoshi > > Hi, > > changed step -> nsteps, and indent is fixed. Here is new diff. > Can I commit this? Thank you very much! ok kettenis@ > Regards, > -- > SASANO Takayoshi (JG1UAA) > > Index: axppmic.c >

Re: axppmic(4): revise (fix axppmic_regdata table, axp305 support)

2023-07-06 Thread Mark Kettenis
> Date: Thu, 06 Jul 2023 07:31:18 +0900 > From: SASANO Takayoshi > > Hello, > > Adding axp305 support to axppmic(4), I found following bugs: > > - only voltage range defined base and delta working, > base2 and delta2 not working > - even if base2 and delta2 range working,

Re: use if_register in dwge(4)

2023-07-05 Thread Mark Kettenis
> Date: Wed, 5 Jul 2023 22:11:19 +0300 > From: Jonathan Matthew > > Like dwqe(4), dwge(4) should also register its instances for lookup > by ofw node or phandle. > > ok? ok kettenis@ > Index: if_dwge.c > === > RCS file:

Re: dwge(4) fixed-link support

2023-07-05 Thread Mark Kettenis
> Date: Wed, 5 Jul 2023 16:09:14 +0300 > From: Jonathan Matthew > > On Wed, Jul 05, 2023 at 01:13:34PM +0200, Mark Kettenis wrote: > > > Date: Wed, 5 Jul 2023 12:46:36 +0300 > > > From: Jonathan Matthew > > > > > > On the Banana Pi R

Re: dwge(4) fixed-link support

2023-07-05 Thread Mark Kettenis
> Date: Wed, 5 Jul 2023 12:46:36 +0300 > From: Jonathan Matthew > > On the Banana Pi R1 (aka Lamobo R1), the dwge interface on the soc is > connected to a broadcom switch chip. It looks like this in the device > tree: > > { > pinctrl-names = "default"; > pinctrl-0 =

Re: Introduce M_IFGROUP type of memory allocation

2023-06-27 Thread Mark Kettenis
> Date: Tue, 27 Jun 2023 17:52:44 +0200 > From: Alexander Bluhm > > On Tue, Jun 27, 2023 at 01:55:23PM +0200, Mark Kettenis wrote: > > > Date: Tue, 27 Jun 2023 11:09:32 + > > > From: Klemens Nanni > > > > > > On Tue, Jun 27, 2023 at 01:32:37P

Re: Introduce M_IFGROUP type of memory allocation

2023-06-27 Thread Mark Kettenis
> Date: Tue, 27 Jun 2023 11:09:32 + > From: Klemens Nanni > > On Tue, Jun 27, 2023 at 01:32:37PM +0300, Vitaliy Makkoveev wrote: > > M_TEMP seems unreasonable for interface groups data allocations. > > After claudio pointed out the wrong type, I thought of the same name, > no other

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

2023-06-19 Thread Mark Kettenis
> Date: Mon, 19 Jun 2023 10:22:56 +0200 > From: Claudio Jeker > > On Sun, Jun 18, 2023 at 12:43:18PM -0500, Scott Cheloha wrote: > > On Sun, Jun 18, 2023 at 12:36:07PM -0500, Scott Cheloha wrote: > > > On Sun, Jun 18, 2023 at 07:32:56PM +0200, Mark Kettenis wrote:

Re: uvm_meter: improve periodic execution logic for uvm_loadav()

2023-06-18 Thread Mark Kettenis
> Date: Sun, 18 Jun 2023 12:27:17 -0500 > From: Scott Cheloha > > The intent here is to update the load averages every five seconds. > However: > > 1. Measuring elapsed time with the UTC clock is unreliable because of >settimeofday(2). > > 2. "Call uvm_loadav() no more than once every five

Re: all platforms, main(): call clockqueue_init() just before sched_init_cpu()

2023-06-13 Thread Mark Kettenis
> Date: Mon, 12 Jun 2023 19:09:59 -0500 > From: Scott Cheloha > > We need to initialize the per-CPU clockintr_queue struct before we can > call clockintr_establish() from sched_init_cpu(). > > Initialization is done with a call to clockqueue_init(). Currently we > call it during

Re: net_tq_barriers()

2023-05-19 Thread Mark Kettenis
> Date: Fri, 19 May 2023 11:35:35 +0200 > From: Claudio Jeker Hi Claudio, > On Fri, May 19, 2023 at 06:10:19PM +1000, David Gwynne wrote: > > On Fri, May 19, 2023 at 08:11:13AM +0200, Claudio Jeker wrote: > > > On Fri, May 19, 2023 at 01:56:38PM +1000, David Gwynne wrote: > > > > this is a tiny

Re: installer: amd64 EFI: default to GPT

2023-05-16 Thread Mark Kettenis
> Date: Tue, 16 May 2023 20:25:36 + > From: Klemens Nanni > > On Tue, May 16, 2023 at 10:07:20AM -0700, Chris Cappuccio wrote: > > I don't quite understand the case this patch solves, because my installs to > > fresh media always get EFI/GPT. It doesn't default to MBR. However, if > > there

Re: installer: amd64 EFI: default to GPT

2023-05-07 Thread Mark Kettenis
> Date: Sat, 6 May 2023 22:47:55 + > From: Klemens Nanni > > On Sat, Apr 29, 2023 at 06:47:48PM +, Klemens Nanni wrote: > > Installing to a wiped disk on EFI machines suggests MBR not GPT when chosing > > (E)dit because MBR vs. GPT in this manual case is picked based on existing > >

Re: arm64 install.md: fix softraid crypto installation on Mac

2023-04-27 Thread Mark Kettenis
> Op 27-04-2023 13:52 CEST schreef Klemens Nanni : > > > Another approach would be to make installboot(8) -p to retain existing > EFI Sys partitions instead of always recreating them. I don't think it is the job of installboot(8) to device whether the ESP should be retained or not. If you

Re: plt section in kernel due to endbr64

2023-04-22 Thread Mark Kettenis
> Date: Fri, 21 Apr 2023 18:28:38 +0200 > From: Alexander Bluhm > > On Fri, Apr 21, 2023 at 07:35:22AM -0600, Theo de Raadt wrote: > > It may still be better to add it to match the style. On i386, also. > > Here is the diff for arm64. No -fcf-protection for i386 yet. > > Before: > >

Re: efi(4): Support for EFI variables and tables in the kernel

2023-04-19 Thread Mark Kettenis
eantime. Cheers, Mark > On Sun, Jan 08, 2023 at 12:48:05PM +0900, YASUOKA Masahiko wrote: > > Hi, > > > > On Wed, 04 Jan 2023 21:52:35 +0100 > > Mark Kettenis wrote: > > > Dear Sergii and others, > > > > > > I've committed the change

Re: apldc/aplhidev: enable LEDs in xorg

2023-04-09 Thread Mark Kettenis
> Date: Sun, 9 Apr 2023 22:56:01 +0200 > From: Tobias Heider > > This patch enables the capslock LED on apple m1/m2 laptops in xenocara. > Console mode was already working by setting the correct accessop, for > X we are missing an ioctl handler. > > Only tested on apldc but the aplhidev code

Re: OF_getpropstr()

2023-04-08 Thread Mark Kettenis
> Date: Sat, 8 Apr 2023 13:29:25 +1000 > From: David Gwynne > > turns out OF_getprop is like memcpy, but sometimes you want something > like strlcpy. this is what OF_getpropstr aims to provide. > > i know openfirm.h is used on other archs that don't use fdt as their > backend, but i figure we

Re: ahci at fdt where the firmware doesnt help

2023-04-07 Thread Mark Kettenis
> Date: Fri, 7 Apr 2023 07:58:02 +1000 > From: David Gwynne > > the banana pi r2 pro has a usable sata port, but ahci wasnt finding > anything attached to it. > > the fdt glue looked like it assumed the boot loader did a lot of > work to get things going. however, i havent figured out how to >

Re: use labels in the device tree to init interface descriptions

2023-04-07 Thread Mark Kettenis
> From: "Theo de Raadt" > Date: Fri, 07 Apr 2023 05:39:00 -0600 > > Claudio Jeker wrote: > > > On Fri, Apr 07, 2023 at 04:53:52PM +1000, David Gwynne wrote: > > > ethernet interfaces in device trees can have a "label" property which > > > is generally used (when it is used) to identify which

Re: fill out more rk356x dwqe phy-mode handling

2023-04-05 Thread Mark Kettenis
> Date: Wed, 05 Apr 2023 09:09:22 +0200 > From: Mark Kettenis > > > Date: Wed, 5 Apr 2023 16:09:21 +1000 > > From: David Gwynne > > > > On Tue, Apr 04, 2023 at 10:59:56PM +1000, David Gwynne wrote: > > > > > > > > > > On 4 Apr 20

Re: fill out more rk356x dwqe phy-mode handling

2023-04-05 Thread Mark Kettenis
> Date: Wed, 5 Apr 2023 16:09:21 +1000 > From: David Gwynne > > On Tue, Apr 04, 2023 at 10:59:56PM +1000, David Gwynne wrote: > > > > > > > On 4 Apr 2023, at 20:37, Mark Kettenis wrote: > > > > > >> Date: Tue, 4 Apr 2023 09:49:40

Re: fill out more rk356x dwqe phy-mode handling

2023-04-04 Thread Mark Kettenis
> Date: Tue, 4 Apr 2023 09:49:40 +1000 > From: David Gwynne > > i did this when i was trying to figure out why TX wasn't working on the > nanopi r5s before figuring out that problem was because we didn't have > rkiovd. > > at the very least it should future proof dwqe against more phy setups, >

Re: get rid of pmap_copy()

2023-04-03 Thread Mark Kettenis
> Date: Sun, 2 Apr 2023 19:29:02 + > From: Miod Vallat > > pmap_copy() is an optional pmap interface which has never been > implemented. In pure Mary Kondo style, we should thank it for the joy it > brought to CSRG people, and move it to the recycling bin - it's not > going to be implemented

Re: pcidevs: add baikal bm1000 pci bridge

2023-03-31 Thread Mark Kettenis
> Date: Fri, 31 Mar 2023 22:13:44 +0200 > From: Mark Kettenis > > > Date: Fri, 31 Mar 2023 20:07:51 + > > From: Klemens Nanni > > > > On Fri, Mar 31, 2023 at 08:12:20PM +0200, Mark Kettenis wrote: > > > The name BM1000 only s

Re: pcidevs: add baikal bm1000 pci bridge

2023-03-31 Thread Mark Kettenis
> Date: Fri, 31 Mar 2023 20:07:51 + > From: Klemens Nanni > > On Fri, Mar 31, 2023 at 08:12:20PM +0200, Mark Kettenis wrote: > > The name BM1000 only seems to come up in unofficial device trees. > > There is a preliminary data sheet for a BE-M1000 SoC out there? Is

Re: pcidevs: add baikal bm1000 pci bridge

2023-03-31 Thread Mark Kettenis
> Date: Fri, 31 Mar 2023 17:12:42 + > From: Klemens Nanni > > https://pcisig.com/membership/member-companies?combine=baikal > https://linux-hardware.org/?id=pci:1d39-8060 > > Feedback? OK? The name BM1000 only seems to come up in unofficial device trees. There is a preliminary data sheet

Re: installer: pine64: better firmware dd

2023-03-25 Thread Mark Kettenis
> Date: Sat, 25 Mar 2023 16:32:17 + > From: Klemens Nanni > > We must not throw away all errors, dd(1) can be silenced properly. > > OK? > > I don't have the hardware to test, but will need to tweak this MD code soon > for get softraid installs working on those boards. To be honest I

Re: panic: ffs_valloc: dup alloc

2023-03-17 Thread Mark Kettenis
> Date: Fri, 17 Mar 2023 15:23:19 +0100 > From: Moritz Buhl > > Dear tech, > > I have a machine with some kind of hardware defect. > Smartctl shows that one SSD regularly has an unexpected power loss > (Attribute 174): > > 174 Unknown_Attribute 0x0032 100 100 000Old_age >

Re: ACPI diff for testing

2023-03-09 Thread Mark Kettenis
> Date: Thu, 09 Mar 2023 14:48:25 +0100 > From: Mark Kettenis > > The diff below fixes an issue with the way we attach "APCI devices". > As with all ACPI diffs, this may potentially introduce regressions, so > some wider testing would be welcome. > > The fix it

ACPI diff for testing

2023-03-09 Thread Mark Kettenis
The diff below fixes an issue with the way we attach "APCI devices". As with all ACPI diffs, this may potentially introduce regressions, so some wider testing would be welcome. The fix itself involves resolving a "nameref" in the package that describes dependencies between APCI devices. These

Re: installer: handle WEP failure (bwfm)

2023-03-06 Thread Mark Kettenis
> Date: Mon, 6 Mar 2023 13:31:58 + > From: Klemens Nanni > > 01.03.2023 17:47, Klemens Nanni пишет: > > Same diff as nov 2021 "Re: installer: prompt for WEP only if available" > > https://marc.info/?l=openbsd-tech=163680942623448=2 > > > > bwfm(4) still has no WEP support and using it for

Re: acpithinkpad: revert 1.67

2023-02-17 Thread Mark Kettenis
> From: Dave Voutila > Date: Fri, 17 Feb 2023 16:30:46 -0500 > > joshua stein writes: > > > Revision 1.67 made acpithinkpad not take over screen backlight > > control and let inteldrm or some other driver handle it. This was > > done to support fine-grained levels of backlight control rather

Re: pcidevs: add PEX 8311 bridge

2023-02-13 Thread Mark Kettenis
> Date: Mon, 13 Feb 2023 13:08:54 +0300 > From: Vitaliy Makkoveev What makes you think this is a PEX 8311? The data sheet I found has the PCI device ID down as 0x8311, althogh this can be changed by programming the EEPROM. > Index: sys/dev/pci/pcidevs >

Re: ichiic: don't force polling during cold start

2023-02-12 Thread Mark Kettenis
> From: Dave Voutila > Date: Sun, 12 Feb 2023 12:47:56 -0500 > > Noticed on my X1 Carbon gen10 that ichiic(4) complains about a timeout > while doing a bus scan as part of attach. Traced it down to the fact we > force polling if the global cold==1 even if the device reports > supporting

Re: Unlock select(2) and pselect(2)

2023-02-08 Thread Mark Kettenis
> Date: Wed, 8 Feb 2023 14:17:14 +0300 > From: Vitaliy Makkoveev > > On Tue, Feb 07, 2023 at 05:42:40PM +0300, Vitaliy Makkoveev wrote: > > > > > > Otherwise, if you are concerning about serialized `p_sigmask' and > > > > P_SIGSUSPEND, dosigsuspend() should be left under kernel lock: > > > > >

Re: Unlock select(2) and pselect(2)

2023-02-07 Thread Mark Kettenis
> Date: Tue, 7 Feb 2023 14:29:13 +0100 > From: Claudio Jeker > > On Mon, Feb 06, 2023 at 08:28:38PM +0300, Vitaliy Makkoveev wrote: > > On Mon, Feb 06, 2023 at 11:01:00AM +0100, Claudio Jeker wrote: > > > On Sat, Feb 04, 2023 at 01:24:58AM +0300, Vitaliy Makkoveev wrote: > > > > Hi, > > > > > >

Re: libcrypto for powerpc g5 xonly

2023-02-01 Thread Mark Kettenis
> Date: Tue, 31 Jan 2023 20:19:19 -0500 > From: George Koehler > > OpenBSD/macppc can enforce xonly on the PowerPC G5. libcrypto linked > with cc -Wl,--execute-only will SIGSEGV as the PowerPC asm of sha256 > tries to read a table from text. The fix is to move the table to > rodata. To find

Re: hardclock: don't call statclock(), stathz is always non-zero

2023-01-31 Thread Mark Kettenis
> Date: Tue, 31 Jan 2023 04:50:59 -0600 > From: Scott Cheloha > > On Mon, Jan 30, 2023 at 05:08:38PM +0100, Mark Kettenis wrote: > > > Date: Sat, 21 Jan 2023 17:02:48 -0600 > > > From: Scott Cheloha > > > > > > All the platforms have switched to

Re: hardclock: don't call statclock(), stathz is always non-zero

2023-01-30 Thread Mark Kettenis
> Date: Sat, 21 Jan 2023 17:02:48 -0600 > From: Scott Cheloha > > All the platforms have switched to clockintr. > > Let's start by isolating statclock() from hardclock(). stathz is now > always non-zero: statclock() must be called separately. Update > several of the the stathz users to

Re: dmtimer(4), macppc, powerpc64, riscv64: init stathz, profhz like other platforms

2023-01-27 Thread Mark Kettenis
> Date: Thu, 26 Jan 2023 21:29:29 -0600 > From: Scott Cheloha > > Almost every platform initializes stathz and profhz like this: > > stathz = hz; > profhz = stathz * 10; > > This patch brings a few stragglers in line with everyone else. > > This does not change stathz and profhz

Re: gptimer(4): switch to clockintr

2023-01-24 Thread 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

Re: riscv64: enable usb(4) interface, add missing usb devices?

2023-01-23 Thread Mark Kettenis
> From: Jeremie Courreges-Anglas > Date: Mon, 23 Jan 2023 13:43:15 +0100 > > I wanted to cross-connect the serial ports of my armv7 and riscv64 > machines. Problem on riscv64: no uftdi driver. It looks like a lot of > other USB drivers are missing in GENERIC, both generic drivers and >

efi(4): Support for EFI variables and tables in the kernel

2023-01-04 Thread Mark Kettenis
ch/amd64/include/efivar.h === RCS file: sys/arch/amd64/include/efivar.h diff -N sys/arch/amd64/include/efivar.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ sys/arch/amd64/include/efivar.h 4 Jan 2023 19:44:26 - @@ -0,0 +1,42 @

Re: ssh: progress meter: prefer setitimer(2) to alarm(3)

2022-12-31 Thread Mark Kettenis
> Date: Sat, 31 Dec 2022 10:33:26 -0500 > From: Scott Cheloha > > Here's another one. > > The progress meter in scp(1) and sftp(1) updates periodically, once > per second. But using alarm(3) to repeatedly rearm the signal causes > that update period to drift forward: > > $ kdump -ts -R -f

ESRT support for the amd64 bootloader

2022-12-28 Thread Mark Kettenis
Dear Sergii, Sorry for the delay, but I have finally found the time to work on the EFI variable and ESRT support for OpenBSD. As a first step, here is a diff that adds support for copying the ESRT in the bootloader and passing it on to the kernel. I adjusted your diff a bit. It now adds the

Re: sparc64: pull retry logic out of tickcmpr_set(), sys_tickcmr_set()

2022-12-24 Thread Mark Kettenis
> Date: Thu, 22 Dec 2022 17:08:12 -0600 > From: Scott Cheloha > > To keep the %TICK and %SYS_TICK code aligned with the Hummingbird > %STICK code, let's pull the retry logic out of tickcmpr_set() and > sys_tickcmpr_set() into tick_rearm() and sys_tick_rearm(), > respectively. > > As far as I

Re: sxitimer(4): switch to clockintr

2022-12-24 Thread Mark Kettenis
> Date: Wed, 14 Dec 2022 17:57:10 -0600 > From: Scott Cheloha > > On Wed, Dec 14, 2022 at 11:45:31PM +0100, Mark Kettenis wrote: > > > Date: Fri, 9 Dec 2022 11:28:43 -0600 > > > From: Scott Cheloha > > > > > > sxitimer(4) is the fourth and fin

Re: Machine after unhibernate *sometimes* won't suspend/hibernate again or dim screen

2022-12-24 Thread Mark Kettenis
> From: Abel Abraham Camarillo Ojeda > Date: Sat, 24 Dec 2022 04:09:42 -0600 > > Notice it only fails *sometimes*, sometimes after the first unhibernate I > cannot get to hibernate/suspend again. > Sometimes I can get several hibernate/unhibernate cycles where everything > works... > > Will try

Re: futex(2): change FUTEX_WAIT wmesg: "fsleep" -> "ftxwait"

2022-12-23 Thread Mark Kettenis
> Date: Fri, 23 Dec 2022 08:37:43 -0600 > From: Scott Cheloha > > The blocking futex operation is called FUTEX_WAIT. I think "ftxwait" > is literally the perfect wmesg. > > "fsleep" is a lot less obvious. > > ok? Well, I know what "fsleep" is since it has been around for a while. I'd have to

Re: sparc64: pull retry logic out of stickcmpr_set()

2022-12-18 Thread Mark Kettenis
> Date: Fri, 16 Dec 2022 16:28:03 -0600 > From: Scott Cheloha > > miod@'s UltraSPARC IIe machine really, really hates the following > code: > > stickcmpr_set(stick()); > > When we try that code, invariably the clock interrupt does not fire > and the machine hangs. > > I think

Re: clang on riscv64: fix LTO link with PIE/PIC objects

2022-12-16 Thread Mark Kettenis
> From: Jeremie Courreges-Anglas > Date: Fri, 16 Dec 2022 01:43:04 +0100 > > On riscv64 LTO fails for some ports with this error: > > ld: error: linking module flags 'SmallDataLimit': IDs have conflicting > values in '.o' and 'ld-temp.o' > > This is because some objects files are built PIC

Re: sxitimer(4): switch to clockintr

2022-12-14 Thread Mark Kettenis
> Date: Fri, 9 Dec 2022 11:28:43 -0600 > From: Scott Cheloha > > sxitimer(4) is the fourth and final armv7 clock interrupt driver that > needs to switch to clockintr. > > - Remove everything related to STATTIMER. We can multiplex TICKTIMER > to handle all clock interrupt events. > - Remove

Re: sxitimer(4): switch to clockintr

2022-12-12 Thread Mark Kettenis
> Date: Fri, 09 Dec 2022 18:46:13 +0100 > From: Mark Kettenis > > > Date: Fri, 9 Dec 2022 11:28:43 -0600 > > From: Scott Cheloha > > > > sxitimer(4) is the fourth and final armv7 clock interrupt driver that > > needs to switch to clockintr. > >

Re: agtimer(4/armv7): switch to clockintr

2022-12-11 Thread Mark Kettenis
> Date: Sun, 11 Dec 2022 09:13:05 -0600 > From: Scott Cheloha > > On Sun, Dec 11, 2022 at 01:34:39PM +0100, Mark Kettenis wrote: > > > Date: Fri, 9 Dec 2022 09:37:11 -0600 > > > From: Scott Cheloha > > > > > > On Thu, Dec 08, 2022 at

Re: agtimer(4/armv7): switch to clockintr

2022-12-11 Thread Mark Kettenis
> Date: Fri, 9 Dec 2022 09:37:11 -0600 > From: Scott Cheloha > > On Thu, Dec 08, 2022 at 11:35:34AM +0100, Jeremie Courreges-Anglas wrote: > > On Wed, Dec 07 2022, Scott Cheloha wrote: > > > ARMv7 has four interrupt clocks available. I think it'll be easier to > > > review/test if we do the

Re: sparc64: don't install %TICK timecounter on UltraSPARC IIe

2022-12-10 Thread Mark Kettenis
> Date: Sat, 10 Dec 2022 09:43:32 -0600 > From: Scott Cheloha > > On Sat, Dec 10, 2022 at 03:14:37PM +0100, Mark Kettenis wrote: > > > Date: Fri, 9 Dec 2022 16:27:59 -0600 > > > From: Scott Cheloha > > > > > > The UltraSPARC IIe's %TICK register

Re: sparc64: don't install %TICK timecounter on UltraSPARC IIe

2022-12-10 Thread Mark Kettenis
> Date: Fri, 9 Dec 2022 16:27:59 -0600 > From: Scott Cheloha > > The UltraSPARC IIe's %TICK register has a variable frequency. See > section 2.3 in this document here: > >

Re: sxitimer(4): switch to clockintr

2022-12-09 Thread Mark Kettenis
> Date: Fri, 9 Dec 2022 11:28:43 -0600 > From: Scott Cheloha > > sxitimer(4) is the fourth and final armv7 clock interrupt driver that > needs to switch to clockintr. > > - Remove everything related to STATTIMER. We can multiplex TICKTIMER > to handle all clock interrupt events. > - Remove

Re: dmtimer(4): switch to clockintr

2022-12-09 Thread Mark Kettenis
> Date: Fri, 9 Dec 2022 10:32:26 -0600 > From: Scott Cheloha > > dmtimer(4) is a third armv7 clock interrupt driver that needs to > switch to clockintr. > > - Remove dmtimer-specific clock interrupt scheduling bits and > randomized statclock bits. > - Add dmtimer_reset_tisr(). We need to

Re: agtimer(4/armv7): switch to clockintr

2022-12-08 Thread Mark Kettenis
> From: Jeremie Courreges-Anglas > Date: Thu, 08 Dec 2022 11:35:34 +0100 > > On Wed, Dec 07 2022, Scott Cheloha wrote: > > ARMv7 has four interrupt clocks available. I think it'll be easier to > > review/test if we do the clockintr switch driver by driver instead of > > all at once in a

  1   2   3   4   5   6   7   8   9   10   >