> 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.
>
> 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
> 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
> any
> 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 -
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 try
> 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
> 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)
> 1.22-1.5
> 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
>
> > /*
> >
> 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 -0500,
> 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 gets
> 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 implem
> 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/del
> 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,
> > > ass
> 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
> 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 reall
> 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 sa
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 cur
> 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:/
> 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 ad
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
> 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
>
> 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 clearl
> 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 o
> 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]
>
>
> 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 br
> 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
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
> 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 his
> 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
> 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 xx
> 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.
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.
> 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. R
> 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 it
> 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
> Date: Mon, 2 Mar 2020 13:56:11 +0100
> From: Patrick Wildt
>
> Hi,
>
> as it turns out, puc(4) has trouble with 64-bit BARs. The issue is that
> puc(4) tries to map every BAR before doing anything else. While iter-
> ating over the BARs it assumes the next BAR is always 4 bytes after the
> o
> Date: Sat, 8 Feb 2020 13:15:47 -0600
> From: Scott Cheloha
>
> On Sun, Dec 22, 2019 at 01:17:56PM -0600, Scott Cheloha wrote:
> > lcd_softc.sc_delay's unit appears to be microseconds.
> >
> > ok?
>
> 1 month bump.
Finaly verified that it works.
ok kettenis@
> Index: dev/lcd.c
> ===
> Date: Wed, 11 Mar 2020 13:38:12 +0100
> From: Jasper Lievisse Adriaanse
>
> Hi,
>
> Remove dead code which is actually duplicated a few lines above
> right after err is set. Coverity ID 975917
>
> OK?
ok kettenis@
> Index: dev/usb/uplcom.c
> =
> Date: Thu, 12 Mar 2020 12:21:53 +0100
> From: Martin Pieuchot
>
> Those two statements are redundant, so keep only one of them, ok?
ok kettenis@
> Index: kern/subr_disk.c
> ===
> RCS file: /cvs/src/sys/kern/subr_disk.c,v
> retrie
> Date: Sat, 14 Mar 2020 23:33:37 -0400
> From: George Koehler
>
> Hello tech@ list!
>
> With this diff, it becomes possible to build macppc kernel with
> base-clang. The default compiler for macppc is base-gcc.
>
> rgc mailed the ppc@ list to report problems with
> clang kernel, and got a wo
> Date: Mon, 16 Mar 2020 20:51:54 +0100
> From: Martin Pieuchot
>
> If the given `rate' is bigger than the last element of the array there's
> an out-of-bound read and `divisor' will contain garbage.
>
> Diff below fix this issue reported by coverity, CID 1453258.
>
> Ok?
ok kettenis@
> Index
tested the bootloader. Doesn't hurt to try
again though.
> And userland?
base was in pretty good shape already and I'm rebuilding now that the
ABI fix is in. Haven't tried xenocara yet.
> George Koehler wrote:
>
> > On Mon, 16 Mar 2020 12:54:52 +0100 (CET)
>
> Date: Tue, 17 Mar 2020 14:12:14 +0100
> From: Klemens Nanni
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Sat, Mar 07, 2020 at 05:44:12PM +0100, Klemens Nanni wrote:
> > Next to the IO device path to be used in ldom.conf we can also print the
> > name which a
> Date: Tue, 17 Mar 2020 17:27:21 +0100
> From: Klemens Nanni
>
> On Tue, Mar 17, 2020 at 03:26:56PM +0100, Mark Kettenis wrote:
> > > @@ -2889,7 +2896,8 @@ list_components(void)
> > >
> > > pri_init(pri);
> > >
> > > + printf(&quo
While playing with dt(4) on arm64, I noticed that there were some
unrecognized functions. Diff below fixes that.
ok?
Index: arch/arm64/arm64/exception.S
===
RCS file: /cvs/src/sys/arch/arm64/arm64/exception.S,v
retrieving revision
While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64
machine, I noticed that the kernel was spending a lot of time (6.84%)
in uvm_map_inentry(). This is caused by kernel lock contention.
Pushing baack the kernel lock further into the slow path reduces the
time to 0.05%.
Now mpi@ trie
> Date: Wed, 18 Mar 2020 11:34:59 +0100
> From: Martin Pieuchot
>
> On 17/03/20(Tue) 20:08, Mark Kettenis wrote:
> > While playing with dt(4)/btrace(4) flamegraphs on a 32-core arm64
> > machine, I noticed that the kernel was spending a lot of time (6.84%)
> >
> Date: Fri, 20 Mar 2020 11:54:59 +0100
> From: Martin Pieuchot
>
> As explained in my recent ix(4) diff, using a define when an arch
> doesn't support a given function makes the compiler complain that
> the arguments are unused:
>
> /sys/dev/pci/if_ix.c:1789:21: error: unused variable 'dummy'
> Date: Fri, 20 Mar 2020 12:50:58 +0100
> From: Martin Pieuchot
>
> On 20/03/20(Fri) 12:01, Mark Kettenis wrote:
> > > Date: Fri, 20 Mar 2020 11:54:59 +0100
> > > From: Martin Pieuchot
> > >
> > > As explained in my recent ix(4) diff, using a d
Some versions of U-Boot do not include a "media device path" node in
the boot device path, even though the OpenBSD bootloader has been
loaded from an MS-DOS partition.
The UEFI specification isn't very clear whether such a media device
path node is required or not. Unfortunately our current EFI
b
> Date: Mon, 23 Mar 2020 21:57:46 -0500
> From: Scott Cheloha
>
> On Sun, Mar 15, 2020 at 09:55:53PM -0500, Scott Cheloha wrote:
> >
> > [...]
> >
> > This is a straightforward ticks-to-milliseconds conversion, but IIRC
> > pirofti@ wanted me to get some tests before committing it.
> >
> > The
> Date: Tue, 24 Mar 2020 15:18:13 +0100
> From: Martin Pieuchot
>
> As soon as an entry is found on `pmr_control.allocs' the boolean
> `work_done' will be set to true. So it is impossible to reach the
> case below that sets UVM_PMA_FAIL.
>
> CID 1453061 Logically dead code
>
> Ok?
Almost cert
> Date: Tue, 24 Mar 2020 16:08:56 +0100
> From: Martin Pieuchot
>
> Variable `me' is never NULL before reaching RBT_POISON(). Diff has a
> lot of context to ease the review.
>
> CID 1453116 Dereference before null check
>
> ok?
ok kettenis@
> Index: uvm/uvm_map.c
> ==
> Date: Tue, 24 Mar 2020 16:11:48 +0100
> From: Martin Pieuchot
>
> On 24/03/20(Tue) 15:55, Mark Kettenis wrote:
> > > Date: Tue, 24 Mar 2020 15:18:13 +0100
> > > From: Martin Pieuchot
> > >
> > > As soon as an entry is found on `pmr_control.allo
> Date: Tue, 24 Mar 2020 12:52:55 -0500
> From: Scott Cheloha
>
> On Tue, Mar 24, 2020 at 09:17:34AM +0100, Mark Kettenis wrote:
> > > Date: Mon, 23 Mar 2020 21:57:46 -0500
> > > From: Scott Cheloha
> > >
> > > On Sun, Mar 1
> Date: Thu, 26 Mar 2020 01:03:26 +0100
> From: Tobias Heider
>
> sr_block_get() returns dma_alloc(length, PR_NOWAIT | PR_ZERO) which may be
> NULL if the memory pool is depleted.
> The result is used as 'dst' argument to memcpy() in the following call to
> sr_raid5_regenerate(), resulting in a p
+
device ssdfb: wsemuldisplaydev, rasops1
attach ssdfb at spi with ssdfb_spi
attach ssdfb at i2c with ssdfb_i2c
Index: dev/fdt/ipmi_fdt.c
===
RCS file: dev/fdt/ipmi_fdt.c
diff -N dev/fdt/ipmi_fdt.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/fdt/ipmi_fdt.c 27 Mar 2020 20:2
> Date: Sun, 29 Mar 2020 19:59:02 -0400
> From: George Koehler
>
> Here is a new diff for macppc's ofw_stack() problem, without using
> __attribute__((noinline)). I use this diff to build and run a macppc
> kernel with clang. It also works with gcc.
>
> The kernel did 3 steps to prepare an Ope
> Date: Wed, 1 Apr 2020 09:40:05 +0200
> From: Patrick Wildt
>
> On Wed, Apr 01, 2020 at 09:22:07AM +0200, Patrick Wildt wrote:
> > On Wed, Apr 01, 2020 at 04:47:10PM +1100, Jonathan Gray wrote:
> > > On Wed, Apr 01, 2020 at 12:58:23PM +1100, Jonathan Gray wrote:
> > > > On Wed, Mar 18, 2020 at 0
> Date: Wed, 1 Apr 2020 10:28:33 +0200
> From: Martin Pieuchot
>
> I've started to refactor some of the kqueue() subsystem to make progress
> on moving selwakeup() out of the KERNEL_LOCK(). Diff below is a small
> part of this work. It extracts the sleeping logic outside of the main
> loop.
>
> Date: Thu, 2 Apr 2020 20:12:08 +0200
> From: Martin Pieuchot
> Content-Type: text/plain; charset=utf-8
>
> While reviewing the all current .d_poll() functions I found those two
> which are incoherent with the rest.
>
> - Most of the devices return POLLERR when the device is no longer valid,
>
> Date: Thu, 2 Apr 2020 16:05:09 -0400
> From: George Koehler
>
> Hello tech,
>
> powerpc libunwind is broken on machines without altivec. It crashes
> SIGILL when code (built with base-clang++) throws a C++ exception,
> because libunwind always saves the altivec registers. You don't have
> al
So regress/lib/libm/msun/run-conj_test fails because clang emits
fmovqne instructions. Those instructions aren't actually implemented
and since we don't emulate them in our kernel the test gets killed
with SIGILL.
The compiler isn't suppose to emit the instructions unless they are
explicitly enab
> Date: Sat, 4 Apr 2020 23:46:05 +0200 (CEST)
> From: Mark Kettenis
>
> So regress/lib/libm/msun/run-conj_test fails because clang emits
> fmovqne instructions. Those instructions aren't actually implemented
> and since we don't emulate them in our kernel the te
> Date: Mon, 6 Apr 2020 15:32:09 -0500
> From: Scott Cheloha
>
> On Tue, Mar 24, 2020 at 09:02:38PM +0100, Mark Kettenis wrote:
> > > Date: Tue, 24 Mar 2020 12:52:55 -0500
> > > From: Scott Cheloha
> > >
> > > On Tue, Mar 24, 2020 at 09:17:34AM
> Date: Thu, 9 Apr 2020 10:01:09 +0200
> From: Martin Pieuchot
> Cc: c...@openbsd.org
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
>
> cwen@ reported that GENERIC.MP on powerpc exposes a bug under high load
> which seems to always involve unlocking a rwlock and UVM swap
The Rapsberry Pi4 UEFI firmware (in ACPI mode) uses a QWord() resource
descriptor for the address.
ok?
P.S. I still plan to move this parsing code into something a bit more
generic at some point instead of replicating slightly different
versions in each driver.
Index: dev/acpi/xhci_ac
Some semi-recent ACPI revision introduced the _CCA method. This
method indicates whether DMA is cache-coherent for a device. This
isn't really relevant on i386/amd64 since its busses are pretty much
always fully cache-coherent. But on amr64 things are different.
Server machines typically have co
Apparently when hooking up an Ethernet PHY using an RGMII interface
some signals need a to have a small clock delay applied to them. The
delays can be applied at various points: by the PHY, by the lengt of
the traces on the board or by the MAC. Linux has an explanation her:
https://github.com
> Date: Sun, 12 Apr 2020 14:38:55 +
> From: Visa Hankala
>
> On Sun, Apr 12, 2020 at 03:26:14PM +0200, Martin Pieuchot wrote:
> > The existing variations of the NET_LOCK() macros are confusing. We're
> > now all aware of this fact. So let's keep them simple to prevent future
> > mistakes :)
Implement the equivalent of OF_getprop() for device-tree-like
properties in ACPI land. Needed for the upcomong Raspberry Pi4
network interface driver.
ok?
Index: dev/acpi/acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrievi
_bse_acpi.c
diff -N dev/acpi/if_bse_acpi.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/acpi/if_bse_acpi.c 12 Apr 2020 15:38:43 -
@@ -0,0 +1,172 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2020 Mark Kettenis
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+
> From: "Theo de Raadt"
> Date: Sun, 12 Apr 2020 10:28:59 -0600
>
> > + if ((p->p_flag & P_SYSTEM) &&
> > + (strncmp(p->p_p->ps_comm, "softnet", 7) == 0))
>
> Wow that is ugly.
A better approach might be to store a pointer to the softnet task's
struct proc in a global variable and
patrick@ pointed out that the arm64 bus_space implementation was
(partly) copied from mips64. Therefore th fixes should probably be
applied there as well.
Untested so far.
Index: arch/loongson/include/bus.h
===
RCS file: /cvs/src/s
> Date: Fri, 10 Apr 2020 09:31:24 +0200
> From: Martin Pieuchot
>
> In order to reduce the differences with other architecture and to be able
> to use WITNESS on powerpc I'm proposing the diff below that makes use of
> the MI mp (ticket) lock implementation for powerpc.
>
> This has been tested
enBSD: bcm2835_rng.c,v 1.2 2018/04/28 15:44:59 jasper Exp $ */
+/*
+ * Copyright (c) 2020 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 appe
> Date: Sun, 19 Apr 2020 12:56:04 +0200 (CEST)
> From: Mark Kettenis
>
> So the random number generator on the Raspberry Pi 4 is a different
> design than what was present on earlier models. Here is a driver.
>
> The ACPI tables don't list this device, so only FD
The Raspberry Pi 4 has an additional SD/MMC controller. This
controller is almost completely standard and just needs one tiny
quirk. So the diff is really simple.
By default, if you use the EDK2-base UEFI firmware this controller
isn't actually connected to anything. So you'll see
sdmmc0: ca
> Date: Sun, 19 Apr 2020 22:24:31 +0200
> From: Stefan Sperling
>
> We really should be documenting supported wifi chipsets to help users
> find devices that will work with OpenBSD.
> The bwfm(4) man page leaves such questions entirely open at present.
>
> The diff below intends to fill that gap
> Date: Thu, 16 Apr 2020 21:31:51 +0100
> From: Stuart Henderson
>
> any comments? ok?
ok kettenis@
> Index: prep
> ===
> RCS file: /cvs/src/distrib/notes/arm64/prep,v
> retrieving revision 1.9
> diff -u -p -r1.9 prep
> --- prep
> Date: Mon, 20 Apr 2020 22:18:06 +0100
> From: Stuart Henderson
>
> On 2020/04/19 21:44, Mark Kettenis wrote:
> > The Raspberry Pi 4 has an additional SD/MMC controller. This
> > controller is almost completely standard and just needs one tiny
> > quirk.
ox* at fdt? early 1
Index: dev/fdt/bcm2835_gpio.c
===
RCS file: dev/fdt/bcm2835_gpio.c
diff -N dev/fdt/bcm2835_gpio.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/fdt/bcm2835_gpio.c 23 Apr 2020 10:48:42 -
@@ -0,0 +1,199 @@
+/* $Ope
I put this in at some point since I couldn't get the eMMC on my
firefly-rk3399 working otherwise. But its eMMC died and on my
rockpro64 and rk3399-q7 boards things work very well without it. On
the latter board it even makes things a bit speedier: the raw read
performance goes up from 35 MB/s to
> Date: Fri, 24 Apr 2020 12:19:32 +0200
> From: Martin Pieuchot
>
> On 15/04/20(Wed) 17:04, Martin Pieuchot wrote:
> > On 15/04/20(Wed) 09:26, Martin Pieuchot wrote:
> > > jca@ is currently building kernels with "-Wno-error=uninitialized" and
> > > reported a warning in ART in SP builds:
> > >
>
The chip will set the OSF flag whenever the internal oscillator stops
running. That happens for example wen the battry runs out of juice.
The idea as that we can check this flag to decide whether we should
trust the time in the chip. The driver tries to implement that but
fails because it always
$ */
+/*
+ * Copyright (c) 2020 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&quo
The cvs log tells me this driver was written to privide an alternative
clock for the Sun Fire V210. That is probably why it prints a message
about overwriting the rtc handler. But the driver was never enabled
on sparc64 (or anywhere else for that matter) and overwriting the rtc
is normal behaviou
Diff below adds GPIO support to bcmgpio(4). It also adds the bits to
attach gpio(4) such that GPIO pins can be controlled from userland.
This makes sense on boards like the Raspberry Pi and the
implementation makes sure that pins used by kernel drivers can't be
touched.
ok?
Index: arch/arm64/co
> Date: Sun, 26 Apr 2020 18:03:20 +0200
> From: Patrick Wildt
>
> Hi,
>
> I have a HummingBoard Pulse, which is an NXP i.MX8MQ based board
> featuring two ethernets, with the second ethernet being an em(4) on
> a PCIe controller.
>
> I had trouble getting it to work, but realized that the issue
> Date: Sat, 25 Apr 2020 00:41:38 +0200 (CEST)
> From: Mark Kettenis
>
> The chip will set the OSF flag whenever the internal oscillator stops
> running. That happens for example wen the battry runs out of juice.
> The idea as that we can check this flag to decide whether we
> Date: Sat, 25 Apr 2020 20:20:37 +0200 (CEST)
> From: Mark Kettenis
>
> The cvs log tells me this driver was written to privide an alternative
> clock for the Sun Fire V210. That is probably why it prints a message
> about overwriting the rtc handler. But the driver was
> Date: Mon, 27 Apr 2020 12:33:24 +0100
> From: Stuart Henderson
>
> On 2020/04/26 12:56, Mark Kettenis wrote:
> > Diff below adds GPIO support to bcmgpio(4). It also adds the bits to
> > attach gpio(4) such that GPIO pins can be controlled from userland.
> > This
> Date: Tue, 28 Apr 2020 11:40:17 +0200
> From: Martin Pieuchot
>
> On 27/04/20(Mon) 19:34, Martin Pieuchot wrote:
> > On 28/04/20(Tue) 01:54, Jonathan Gray wrote:
> > > On Mon, Apr 27, 2020 at 04:52:33PM +0200, Martin Pieuchot wrote:
> > > > Diff below extends the existing drmkqfilter() to suppo
> Date: Tue, 28 Apr 2020 23:27:00 +0200
> From: Patrick Wildt
>
> On Tue, Apr 28, 2020 at 11:16:43PM +0200, Patrick Wildt wrote:
> > Hi,
> >
> > on my i.MX8MM EVK there's a ath10k-based WiFi chip which we
> > unfortunately do not support (yet?). But the SD/MMC CIS parser
> > complains:
> >
> >
> Date: Tue, 28 Apr 2020 01:31:12 -0400
> From: George Koehler
>
> Moving from bugs@ to tech@,
> because some people might miss a clang diff on bugs@.
>
> This diff modifies LLVM's DAGCombiner to skip an optimization if it
> would make an illegal ISD::ADDE node. This fixes fatal errors from
> p
> Date: Thu, 30 Apr 2020 12:58:32 -0400
> From: George Koehler
>
> On Wed, 29 Apr 2020 21:08:52 +0200 (CEST)
> Mark Kettenis wrote:
>
> > Upstream fixed this issue as well. Apparently only ADDE can't be
> > legalized (because it is "special") but
> Date: Fri, 1 May 2020 14:17:56 +0200
> From: Alexandre Ratchov
>
> On Fri, May 01, 2020 at 01:11:16PM +0200, Damien Couderc wrote:
> >
> > Speaking of the hdmi-only devices that were disabled in 2009: does the
> > project still stand on this position in 2020? I made a quick search and it
> > s
> From: Damien Couderc
> Date: Fri, 1 May 2020 18:24:12 +0200
>
> Le 01/05/2020 à 17:30, Stuart Henderson a écrit :
> > On 2020/05/01 17:16, Damien Couderc wrote:
> >> Le 01/05/2020 à 15:01, Mark Kettenis a écrit :
> >>>> Date: Fri, 1 May 2020 14:
I've always interpreted the bit of code that takes the bus number from
_CRS instead of _BBN, ut allegedly this is not how it works and _BBN
is supposedly only there to make sure we can access PCI config space
of the host bridge from AML code.
Fortunately having _CRS provide the bus number is just
> Date: Fri, 8 May 2020 15:39:26 +0200
> From: Jan Klemkow
>
> On Mon, Apr 27, 2020 at 10:42:52AM +0200, Martin Pieuchot wrote:
> >
> > So the current logic assumes that as long as the ring contains descriptors
> > em_rxrefill() failures aren't fatal and it is not necessary to schedule a
> > ref
201 - 300 of 3190 matches
Mail list logo
