On Tue, Sep 29, 2020 at 11:23:03AM -0600, Theo de Raadt wrote:
> + if (strcmp(ia->ia_name, "st,m41t83") == 0)
>
> fine with me. But in that case, why not call the driver i2c/m41t83.c
Because it's a series of chips, like m41t80, m41t81, m41t82. Machines
and their device trees encode the sp
Hi,
some arm64 that I'd like to use as replacement server for the one that's
crashing all the time (probably HW-related) has a Microcrystal RV4162
RTC. As it turns out, this is about the same as the ST M41T8x series.
For that one we already have mfokclock(4), but only for loongson. After
talkin
On Thu, Sep 10, 2020 at 10:13:30AM +0200, Tobias Heider wrote:
> Hi,
>
> the newer Geyser 2 touchpad has only 9 sensors in the Y-direction instead
> of 16 like the other Apple touch pads.
> The driver sets sc_y_sensors correctly and then immediately overwrites
> it with the wrong default.
> I thin
On Fri, Aug 14, 2020 at 02:33:10PM +0200, Mark Kettenis wrote:
> Miod noticed that the powerpc64 version talked about AArch64. I don't
> think the "for all XXX platforms" makes sense so simply drop it from
> all three versions of this header.
>
> ok?
>
ok patrick@
>
> Index: arch/arm/include/
On Thu, Aug 13, 2020 at 09:17:41PM +0200, Mark Kettenis wrote:
> ARMv8.1 introduced PAN (Priviliged Access Never) which prevents the
> kernel from accessing userland data. This can be bypassed by using
> special instructions which we already use in copyin(9) and friends.
> So we can simply turn th
On Fri, Jul 10, 2020 at 01:00:31PM +0200, Marcus Glocker wrote:
> Hi All,
>
> Laurence Tratt was reporting about corrupted video images when using
> uvideo(4) on xhci(4) with MJPEG and higher resolutions, e.g. when using
> ffplay:
>
> $ ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -f /
Hi,
based on the previous diffs, this removes the last remaining users
of the compat API. IFQ_SET_MAXLEN is simply now lowercase, and
IFQ_IS_EMPTY is lowercase and got its _IS removed. Pretty mechanical
diff.
ok?
Patrick
diff --git a/sys/arch/armv7/omap/if_cpsw.c b/sys/arch/armv7/omap/if_cpsw
On Fri, Jul 10, 2020 at 12:20:53PM +0300, Vitaliy Makkoveev wrote:
>
>
> > On 10 Jul 2020, at 12:13, Patrick Wildt wrote:
> >
> > Hi,
> >
> > this is a rather mechanical diff, done using vim and some regex,
> > to remove and replace IFQ_ENQUEUE, I
Hi,
based on the previous diff, this rids the compat API from IFQ_PURGE.
ok?
Patrick
diff --git a/sys/dev/ic/ath.c b/sys/dev/ic/ath.c
index c469269eb4e..47505b6b733 100644
--- a/sys/dev/ic/ath.c
+++ b/sys/dev/ic/ath.c
@@ -737,7 +737,7 @@ ath_stop(struct ifnet *ifp)
} else {
Hi,
this is a rather mechanical diff, done using vim and some regex,
to remove and replace IFQ_ENQUEUE, IFQ_DEQUEUE and IFQ_LEN.
There are more, but I didn't want the diff to get too big. I'll
do that after this one is committed.
ok?
Patrick
diff --git a/sys/arch/armv7/omap/if_cpsw.c b/sys/ar
On Wed, Jul 08, 2020 at 12:19:35PM +0200, Frederic Cambus wrote:
> Hi tech@,
>
> I created a new size for Spleen, to bridge the gap between the 5x8 and
> the 8x16 versions. The idea is to have something more readable than the
> 5x8 version while still being small enough to be usable on OLED displa
On Tue, Jun 16, 2020 at 06:55:27AM +, sc.dy...@gmail.com wrote:
> hi,
>
> The function xhci_event_xfer_isoc() of sys/dev/usb/xhci.c at line 954
> does not work with zero length multi-TRB inbound transfer.
>
>949/*
>950 * If we queued two TRBs for a fram
Hi,
I had issues with a machine hanging on powerdown. The issue is caused
by sd(4)'s suspend method trying to "power down" my umass(4) USB stick.
The symptom was that during powerdown, when running in "polling mode",
the first transaction (send command to power down to USB stick) works:
We enque
Hi,
when powering down, sd(4) will trigger a powerdown on it's umass(4)
USB stick. If the device fails to respond, for whatever reason, the
umass(4) code will do multiple reset mechanism, and one of those uses
a control transfer. Unfortunately the control transfer is not passed
the sc_xfer_flags
On Tue, Jun 23, 2020 at 06:51:20AM -0400, Bryan Steele wrote:
> On Mon, Jun 22, 2020 at 11:10:10PM -0700, jo...@armadilloaerospace.com wrote:
> > Are SSE instructions allowed in the AMD64 kernel? Is #ifdef __SSE__
> > a sufficient guard?
> >
> > I have a rasops32 putchar with SSE that is 2x faste
On Sun, Jun 21, 2020 at 10:06:52AM -0400, Sonic wrote:
> Along that line, does wireguard have any problems using alias
> addresses? It's not a problem with IKEv1 but it is with IKEv2.
>
> Thanks!
>
> Chris
I still don't see how this is a problem with IKEv2, so don't spread any
rumours and instea
On Sat, May 30, 2020 at 07:21:15PM +, Miod Vallat wrote:
> Yet another case where the emulator does not match the real hardware.
>
> Why bother with them?
>
> Get qemu to fix their shit so that the frame buffer metrics variable are
> aligned on 64-bit boundaries. There might not be a written
Hi,
drahn@ was complaining to me that his cross-compiler wasn't defining
__OpenBSD__ or __ELF__, and I think the fix is pretty simple. We're
just missing a case in a switch-case.
The .cpp file itself still compiles, but I haven't built a full clang
with it. Please give it a go and report back.
On Mon, May 18, 2020 at 10:16:27AM -0600, Theo de Raadt wrote:
> I suspect there are other inconsistancies in all these versions.
>
> ./sys/arch/arm/arm/in_cksum_arm.S
> ./sys/arch/i386/i386/in_cksum.s
> ./sys/arch/sparc64/sparc64/in_cksum.S
> ./sys/arch/sh/sh/in_cksum.S
These are assembly and fo
On Mon, May 18, 2020 at 05:50:28PM +0200, Claudio Jeker wrote:
> On Mon, May 18, 2020 at 03:50:05PM +0200, Patrick Wildt wrote:
> > Hi,
> >
> > I was trying to tftpboot and had an issue with files of odd-length.
> > As it turns out, I think the in_cksum() that's c
Hi,
I was trying to tftpboot and had an issue with files of odd-length.
As it turns out, I think the in_cksum() that's called for UDP payload
cannot handle a payload length that's not aligned to 16 bytes.
I don't know how in_cksum() is supposed to work exactly, but it looks
like the first step is
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:
>
> sdmmc0: CIS parse error at 4136, tuple code 0x14, leng
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:
sdmmc0: CIS parse error at 4136, tuple code 0x14, length 0
manufacturer 0x0271, product 0x0701 at sdmmc0 function 1 not configured
It's not a transmission bu
Hi,
I don't know userland very well, so I have a question. In the middle of
2019 there have been plenty of changes in regards to changing checks of
syscalls from < 0 to a more strict == -1, like this one in isakmpd:
revision 1.26
date: 2019/06/28 13:32:44; author: d
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 is the
descriptor ring coherency. I looked into the code, tried to find if
the
On Wed, Apr 01, 2020 at 12:23:53PM +0200, Patrick Wildt wrote:
> On Wed, Apr 01, 2020 at 12:04:25PM +0200, Patrick Wildt wrote:
> > On Wed, Apr 01, 2020 at 09:40:06AM +0200, Patrick Wildt wrote:
> > > On Wed, Apr 01, 2020 at 09:22:07AM +0200, Patrick Wildt wrote:
> > > &
On Wed, Apr 01, 2020 at 12:04:25PM +0200, Patrick Wildt wrote:
> On Wed, Apr 01, 2020 at 09:40:06AM +0200, Patrick Wildt wrote:
> > 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 09:40:06AM +0200, Patrick Wildt wrote:
> 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, 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 01:41:06PM +0100, 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 01:41:06PM +0100, Patrick Wildt wrote:
> > > On Wed, Mar 18, 2020 at 11:22:40AM +0100, Patrick Wildt wrote:
> > >
On Wed, Mar 18, 2020 at 11:22:40AM +0100, Patrick Wildt wrote:
> Hi,
>
> I've spent a few days investigating why USB ethernet adapters are so
> horribly slow on my ARMs. Using dt(4) I realized that it was spending
> most of its time in memcpy. But, why? As it turns out, al
Hi,
I've spent a few days investigating why USB ethernet adapters are so
horribly slow on my ARMs. Using dt(4) I realized that it was spending
most of its time in memcpy. But, why? As it turns out, all USB data
buffers are mapped COHERENT, which on some/most ARMs means uncached.
Using cached da
On Sat, Mar 14, 2020 at 04:28:26AM +0100, Alexandre Ratchov wrote:
> On ASUS 1001PXD, _BQC returns an out of range value which makes
> acpivout_get_brightness() return -1, in turn breaking the
> display.brightness control (wsconsctl displays a mangled value).
>
> This diff ignores the out of range
On Fri, Mar 13, 2020 at 05:54:01PM +0100, Rob Schmersel wrote:
> On Fri, 13 Mar 2020 16:31:18 +0100
> Patrick Wildt wrote:
> > Thanks for the diff! Since Linux uses the same firmware (43340) for
> > both 43340 and 43341, I commited the diff slightly differently to
> > fo
On Fri, Mar 13, 2020 at 02:49:33PM +0100, Rob Schmersel wrote:
> Hi,
>
> I got a new toy to play with recently which uses a bcm43341 wireless
> chipset. This chipset is the same as the bcm43340 apart from an
> additional nfc mode and can re-use the brcmfmac43340-sdio.bin firmware.
> (I simply adde
c* at sdhc?# SD/MMC bus
diff --git a/sys/dev/pci/com_pci.c b/sys/dev/pci/com_pci.c
new file mode 100644
index 000..cfb6e238bea
--- /dev/null
+++ b/sys/dev/pci/com_pci.c
@@ -0,0 +1,242 @@
+/* $OpenBSD$ */
+/*
+ * Copyright (c) 2020 Patrick Wildt
+ *
+ * Permission to use, co
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
other. For 64-bit BARs that's wrong. On a device with a 64-bit BAR, it
will
On Wed, Jan 02, 2019 at 08:11:25PM -0500, James Hastings wrote:
> Hello tech@
>
> I would like to add PCI devices for latest Intel SoC (Gemini Lake).
>
> Included a patch for sdhc(4) too that depends on this to enable eMMC.
> The Intel eMMC controller does not like bus power going to 0V. There
>
Hi,
on the Pinebook Pro the trackpad isn't working. The reason is that the
Y-coordinate is extracted twice. The first location has thevalue
correctly, the second location has it zeroed or garbage. This is
because when we iterate over the report, the Y-coordinate usage
appears twice. This shoul
On Fri, Jan 24, 2020 at 01:04:41AM +0100, Patrick Wildt wrote:
> On Thu, Jan 23, 2020 at 11:25:51PM +0100, Mark Kettenis wrote:
> > Since acpi_set_brightness() can be called from anywhere, it should really
> > use the acpi task queue to do its thing instead of calling AML directly
On Thu, Jan 23, 2020 at 11:25:51PM +0100, Mark Kettenis wrote:
> Since acpi_set_brightness() can be called from anywhere, it should really
> use the acpi task queue to do its thing instead of calling AML directly.
I didn't know there's an acpi task queue, so that's awesome! I just saw
that acpith
On Thu, Jan 23, 2020 at 05:03:01PM -0500, Ted Unangst wrote:
> Patrick Wildt wrote:
> > acpivout_[gs]et_param don't know if they are being called by itself
> > or by someone else. I don't need to grab it again, I just need to
> > have it before calling an ACPI meth
On Thu, Jan 23, 2020 at 09:51:11AM +0100, Martin Pieuchot wrote:
> On 23/01/20(Thu) 08:26, Patrick Wildt wrote:
> > Hi,
> >
> > this is the second attempt of a diff that prepares acpivout(4) to work
> > with the X395. The previous one broke due to recursive ACPI lock
Hi,
this is the second attempt of a diff that prepares acpivout(4) to work
with the X395. The previous one broke due to recursive ACPI locking.
So apparently we cannot change the brightness using the acpivout(4) ACPI
methods. Instead we need to call amdgpu(4) to change the brightness.
But the b
On Mon, Jan 13, 2020 at 11:58:11AM +0100, Klemens Nanni wrote:
> On Sun, Oct 13, 2019 at 09:28:26PM -0500, joshua stein wrote:
> > When responding to hardware keys to increment or decrement screen
> > brightness, don't just adjust by 1 BCL level as there may be 100
> > levels. Find the next brig
On Fri, Dec 13, 2019 at 10:34:59PM +0100, Patrick Wildt wrote:
> Hi,
>
> I have a ThingM blink(1) USB RGB device that shows up as uhid(4).
> The tooling is "interesting", especially with all those libusb and
> HID libraries doing the abstraction. This introduces ublink
On Mon, Dec 16, 2019 at 01:57:41PM +, Stuart Henderson wrote:
> On 2019/12/13 22:34, Patrick Wildt wrote:
> > uhidev1 at uhub0 port 3 configuration 1 interface 0 "ThingM blink(1) mk2"
> > rev 2.00/0.02 addr 2
> > uhidev1: iclass 3/0, 1 report id
> > ubli
On Fri, Dec 13, 2019 at 02:43:25PM -0700, Theo de Raadt wrote:
> +__devitem(led, led*, Generic LED devices)dnl
> +_mcdev({-led-}, led*, {-led-}, {-major_led_c-}, 660)dnl
>
> Mode 660 leads me to ask -- what is the group?
I don't know, I figured you could help me there. I guess the
default can be
led {}
+device led
+file dev/ic/led.cled needs-flag
+attach led at led
+
# net device attributes - we have generic code for ether(net)
define crypto
define ether
diff --git a/sys/dev/ic/led.c b/sys/dev/ic/led.c
new file mode 100644
index 000..3bc8c214394
--- /dev/null
+++ b/s
Hi,
I found another issue with the calculation of the actual length on short
xfers. On e.g. bulk transfers with multiple TRBs the first short TRB
will give us a short event. We will then calculate the actual length
and return. So far this is good.
The last TRB in the TD is marked as IOC (Inter
On Thu, Nov 21, 2019 at 06:52:36AM +, sc.dy...@gmail.com wrote:
> Hi,
>
> On 2019/11/18 20:34, Marcus Glocker wrote:
> > On Sun, Nov 17, 2019 at 12:36:49PM +0100, Marcus Glocker wrote:
> >
> >> While recently testing UDL on XHCI I faced a lot of USB timeouts, and
> >> therefore screen renderi
On Sat, Nov 02, 2019 at 10:09:43PM -0400, James Hastings wrote:
> Hi,
>
> Backlight on multiple laptops will go down but not up when using brightness
> keys.
> Compare new brightness level to min/max values in sc_bcl[] instead.
> Diff below restores backlight up function.
Since (n)level is based
On Fri, Mar 29, 2019 at 05:22:13AM -0400, James Hastings wrote:
> Index: dev/pci/pcidevs
> ===
> RCS file: /cvs/src/sys/dev/pci/pcidevs,v
> retrieving revision 1.1881
> diff -u -p -r1.1881 pcidevs
> --- dev/pci/pcidevs 20 Mar 2019 10
On Wed, Nov 20, 2019 at 08:06:25AM -0800, Bryan Vyhmeister wrote:
> On Sat, Nov 16, 2019 at 10:01:44PM -0800, Philip Guenther wrote:
> > Looking good so far on my X1 extreme once I
> > added PCI_PRODUCT_INTEL_WL_9560_2 next to the _1 lines in if_iwm.c.
> > Awesome!
>
> Could this change be committ
Hi,
on my Intel NUC 8i5BEHs that has a 9560 chip the current in-tree
support for the 9000 series does not work. The issue seems to be
the interrupt delivery. The first interrupt we wait for, which is
loading the firmware chunks, never appears. Even disabling MSI
and relying on legacy interrupts
Hi,
on some GPD Pocket mlarkin@ has the eMMC doesn't come up. One issue
is that we shouldn't go to 0V on some/most(?) Intel controllers. This
only adds it for his machine, but I know that the Appollo Lake versions
might also work if added to this check. But unless verified I'll not
add it. Thi
On Wed, Nov 13, 2019 at 06:40:00PM -0700, Aaron Bieber wrote:
> Hi,
>
> I have a raspberry pi 0 that attaches as:
> cdce0 at uhub0 port 3 configuration 2 interface 0 "Linux 4.19.75+ with \
> 2098.usb RNDIS/Ethernet Gadget" rev 2.00/4.19 addr 10
>
> Unfortunately the cdce interface does
On Tue, Nov 12, 2019 at 07:00:00PM +0100, Patrick Wildt wrote:
> On Tue, Nov 12, 2019 at 01:43:28PM +0100, Patrick Wildt wrote:
> > On Tue, Nov 12, 2019 at 10:45:39AM +0100, Gerhard Roth wrote:
> > > Hi,
> > >
> > > xhci's calculation of 'xfe
On Tue, Nov 12, 2019 at 01:43:28PM +0100, Patrick Wildt wrote:
> On Tue, Nov 12, 2019 at 10:45:39AM +0100, Gerhard Roth wrote:
> > Hi,
> >
> > xhci's calculation of 'xfer->actlen' is wrong if the xfer was split into
> > multiple TRBs. That&#
On Tue, Nov 12, 2019 at 10:45:39AM +0100, Gerhard Roth wrote:
> Hi,
>
> xhci's calculation of 'xfer->actlen' is wrong if the xfer was split into
> multiple TRBs. That's because the code just looks at the remainder
> reported by the status TRB. However, this remainder only refers to the
> total siz
Hi,
some machines have no _BQC method, which is used to query the
current display backlight level. We can still work on those by
starting with the highest level (when there's no _BQC method)
and keeping track of the current level.
Patrick
diff --git a/sys/dev/acpi/acpivideo.c b/sys/dev/acpi/acp
On Wed, Oct 30, 2019 at 08:07:06AM +1100, Damien Miller wrote:
> On Tue, 29 Oct 2019, Patrick Wildt wrote:
>
> > Ok, so it turns out that this is related with opening/closing
> > the uhid(4) device. Because every open(2) and close(2) also
> > opens and closes the pi
On Tue, Oct 29, 2019 at 05:41:55PM +0100, Patrick Wildt wrote:
> On Mon, Oct 28, 2019 at 12:07:20PM +1100, Damien Miller wrote:
> > On Mon, 28 Oct 2019, Damien Miller wrote:
> >
> > > On Fri, 25 Oct 2019, Patrick Wildt wrote:
> > >
> > > > > S
On Mon, Oct 28, 2019 at 12:07:20PM +1100, Damien Miller wrote:
> On Mon, 28 Oct 2019, Damien Miller wrote:
>
> > On Fri, 25 Oct 2019, Patrick Wildt wrote:
> >
> > > > So from what I understood the Yubikey expects the transfer to happen
> > > > on the Int
On Mon, Oct 28, 2019 at 03:14:22PM +1100, Damien Miller wrote:
> On Mon, 28 Oct 2019, Damien Miller wrote:
>
> > BTW, the token still becomes unresponsive after the first transaction,
> > but looking at a sniff (using an OpenViszla), it seems we're getting the
> > DATA0/DATA1 flipping incorrect on
On Fri, Oct 25, 2019 at 03:59:25PM +0200, Patrick Wildt wrote:
> On Fri, Oct 25, 2019 at 03:10:48PM +1100, Damien Miller wrote:
> > Hi,
> >
> > Some HID devices do not list any report IDs for communication, e.g. my
> > Yubikey5:
> >
> > > uhidev0: i
On Fri, Oct 25, 2019 at 03:10:48PM +1100, Damien Miller wrote:
> Hi,
>
> Some HID devices do not list any report IDs for communication, e.g. my
> Yubikey5:
>
> > uhidev0: iclass 3/0
> > uhid0 at uhidev0: input=64, output=64, feature=0
> > ugen0 at uhub0 port 2 configuration 1 "Yubico YubiKey FIDO
Committed, thanks!
On Wed, Sep 25, 2019 at 09:45:41AM -0700, Josh Elsasser wrote:
> I came across some code which uses __clear_cache() from
> libgcc/libcompiler_rt on 32-bit arm. Currently that just falls through
> to abort(), but enabling the existing sysarch() code works for me.
>
> diff --git
On Sun, Aug 18, 2019 at 08:36:28PM +0200, Ulf Brosziewski wrote:
> With the introduction of precision scrolling, it is no longer possible to
> reverse scroll directions for touchpads by means of button mappings in X.
> This patch adds a configuration option to wsmouse and a boolean field
> named
>
boot 172.16.65.1:/bsd.rd
> boot> boot tftp:/bsd.rd
> cannot open tftp:/etc/random.seed: bad drive number
> booting tftp:/bsd.rd: open tftp:/bsd.rd: bad drive number
> failed(98). will try /bsd
> boot> boot tftp0a:/bsd.rd
> booting tftp0a:/bsd.rd: open tftp0a:/bsd.rd: Operat
Hi,
the second camrea on my Lenovo X395 is an "IR" camera that produces some
greyscale picture. video(1) doesn't support that format, but with this
patch I can use
$ ffmpeg -f v4l2 -i /dev/video1 test.mp4
$ mplayer test.mp4
to record and show the video correctly.
Patrick
diff --git a/sys/de
Hi,
on my Lenovo X395 the uvideo(4) follows the current UVC 1.5 spec. The
message length was increased with each specification, so now the buffer
for probe messages is up to 48 bytes. On that particular device the
camera sends a USB stall if we only supply the 26 bytes from the
original UVC 1.0
Hi,
since we already dump most of the descriptors, also dump the interface
association descriptor, which helped me debug the previous issue.
Patrick
diff --git a/sys/dev/usb/uvideo.c b/sys/dev/usb/uvideo.c
index c990c899c45..1a9dfc733fa 100644
--- a/sys/dev/usb/uvideo.c
+++ b/sys/dev/usb/uvideo.
Hi,
newer laptops can have more than one camera. For instance the Lenovo
X395 ships with a normal camera and an infrared camera. These cameras
are behind a single USB device and their "functions" are separated
using interface association descriptors. This means that there are
USB descriptors th
Hi,
on some hardware I see a "failed to start command DMA on port N,
disabling" during attach. Apparently AHCI spec. rev 1.3 only
requires that a HBA clears AHCI_PREG_CMD_CR when AHCI_PREG_CMD_ST
gets cleared by software/driver, but not the inverse. Actually
neither the FreeBSD, Linux nor NetBSD
On Thu, Jun 20, 2019 at 11:21:20AM +0200, Remco wrote:
> On 19-06-19 07:13, Patrick Wildt wrote:
> > Hi,
> >
> > this diff adds the necessary helpers to arm64 so that libcrypto knows
> > which of the hardware crypto features are available on the machine.
> > Those
On Wed, Jun 19, 2019 at 09:25:27AM +0200, Mark Kettenis wrote:
> > Date: Wed, 19 Jun 2019 07:13:19 +0200
> > From: Patrick Wildt
> >
> > Hi,
> >
> > this diff adds the necessary helpers to arm64 so that libcrypto knows
> > which of the hardware cr
Hi,
this diff adds the necessary helpers to arm64 so that libcrypto knows
which of the hardware crypto features are available on the machine.
Those helpers are used by the existing and matching armv7 code.
ok?
Patrick
diff --git a/lib/libcrypto/arch/aarch64/Makefile.inc
b/lib/libcrypto/arch/aa
Committed, thanks!
On Mon, Jun 17, 2019 at 07:53:50PM +0200, Mark Kettenis wrote:
> > From: James Hastings
> > Date: Mon, 17 Jun 2019 13:24:36 -0400 (EDT)
>
> This diff is ok kettenis@
>
> It might take a few days for me to commit this. If anybody else wants
> to do it based on my ok, go ahead
Hi,
in a recent discussion I was told we can throw out all the !ARMv7
architecture code and !OpenBSD and if portable needs it they can
add it back.
With this in mind we can throw out quite a bit of ifdefs.
ok?
Patrick
diff --git a/lib/libcrypto/armv4cpuid.S b/lib/libcrypto/armv4cpuid.S
index b
On Wed, May 22, 2019 at 02:38:04AM +0200, Krystian Lewandowski wrote:
> I tried to rebuild cross tools recently and it seems there is a typo
> in Makefile.cross.
Thanks, committed!
Hi,
claudio@ has a Kaby Lake that exceeds the 128 kB limit, being as big as
190 kB. So, for him the ucode isn't being loaded.
On EFI systems we can simply ask EFI to allocate some memory for us.
I'm not sure why this file is duplicated 4 times, but it looks like
for efiboot this one is currently
On Tue, Apr 16, 2019 at 03:23:37PM +0200, Mark Kettenis wrote:
> > Date: Mon, 15 Apr 2019 08:50:04 +0200
> > From: Patrick Wildt
> > Content-Type: text/plain; charset="utf-8"
> > Content-Disposition: inline
> >
> > Hi,
> >
> > with kette
Hi,
with kettenis' change from 2015(?) we can configure a ppb(4)'s bus
information. Unfortunately the hotplug fixup code runs before that
change has a chance, and it will program a single bus (with no amount
of children) below it. I think that part of the hotplug fixup can go
away.
The hotplug
Hi,
with kettenis' change from 2015(?) we are able to configure ppb(4)'s
that are hotplugged. I think on detach we should make sure to free the
bus range that was allocated for that device dynamically. Otherwise
plug and pull can starve the extent.
Feedback?
Patrick
diff --git a/sys/dev/pci/p
On Wed, Feb 27, 2019 at 01:01:37PM +, Stuart Henderson wrote:
> On 2019/02/26 16:34, Tobias Heider wrote:
> > Hi,
> >
> > this diff adds support for IKEv2 Message Fragmentation as defined in
> > RFC 7383 (https://tools.ietf.org/html/rfc7383) to iked(8).
>
> Thank you, I know there are quite a
On Tue, Feb 26, 2019 at 06:45:38PM +0100, Patrick Wildt wrote:
> On Thu, Feb 21, 2019 at 06:29:15PM +0100, Aram Hăvărneanu wrote:
> > This change fixes the sending of INTERNAL_IP6_DNS, INTERNAL_IP6_DHCP
> > (RFC5996); INTERNAL_IP6_NBNS (RFC4306); and INTERNAL_IP6_SERV
On Thu, Feb 21, 2019 at 06:29:15PM +0100, Aram Hăvărneanu wrote:
> This change fixes the sending of INTERNAL_IP6_DNS, INTERNAL_IP6_DHCP
> (RFC5996); INTERNAL_IP6_NBNS (RFC4306); and INTERNAL_IP6_SERVER
> (MS-IKEE).
>
> Prior to this fix the data sent to clients was garbled.
Oh, good catch! That
On Fri, Feb 22, 2019 at 08:49:58PM +0100, Jan Klemkow wrote:
> Hi,
>
> The diff below adds support for the Dynastream "ANT USBStick2" to
> uscom(4). The device attached with the following message:
>
> uscom0 at uhub0 port 2 configuration 1 interface 0 "Dynastream Innovations
> ANT USBStick2" re
On Thu, Feb 21, 2019 at 03:56:57PM +0100, Stefan Sperling wrote:
> On Thu, Feb 21, 2019 at 10:50:40AM +0100, Patrick Wildt wrote:
> > Hi,
> >
> > on my i.MX8M machine which features a DWC3 xHCI 1.10 controller I have
> > seen this error while installing base64.tgz or ru
Hi,
on my i.MX8M machine which features a DWC3 xHCI 1.10 controller I have
seen this error while installing base64.tgz or running fsck:
umass0: Invalid CSW: sig 0x43425355 should be 0x53425355
As it turns out using a USB protocol analyzer, the transfers actually
seem fine, the USB mass storage i
On Thu, Jan 31, 2019 at 12:55:44AM +0100, Mark Kettenis wrote:
> Still need to review this properly. But why is one of the properties
> called openbsd,bootsr-maskkey? openbsd,bootsr-key would make more
> sense. Or maybe openbsd,sr-bootuuid and openbsd,sr-bootkey?
I agree, I don't like them eith
Hi,
to boot a pinebook with softraid crypto there are three parts that need
to be implemented, which this diff hopefully does well enough.
First, our EFI bootloader so far only supports one disk, so we need to
extend this so we can see all connected block devices. The second part
is adding the s
Hi,
I know some people might be wondering why I want crypto on the ramdisk
for those slow 64-bit ARMs, but,... I'd like to setup softraid crypto
on the pinebook. GENERIC allows it, but RAMDISK doesn't have it by
default. I'd like for arm64 to have sofraid crypto, so I need CRYPTO
in the RAMDISK
On Tue, Jan 15, 2019 at 10:01:42PM +0100, Stefan Sperling wrote:
> This diff makes 'ifconfig bwfm0' display whether 11n is active or not,
> what the current Tx rate is, and show up-to-date RSSI measurements.
> I'm leaving display of 11ac Tx rates for future work because that will
> require a change
On Wed, Oct 31, 2018 at 10:03:57AM +0100, Mark Kettenis wrote:
> > Date: Wed, 31 Oct 2018 09:54:35 +0100
> > From: Patrick Wildt
> >
> > Hi,
> >
> > during the libunwind update to 6.0 we lost a particular patchset that
> > fixes register numbering
Hi,
during the libunwind update to 6.0 we lost a particular patchset that
fixes register numbering for OpenBSD/i386, thus breaking exception
handling on that platform. Looks like no one noticed until now.
ok?
Patrick
diff --git a/lib/libunwind/include/libunwind.h
b/lib/libunwind/include/libun
On Tue, Oct 30, 2018 at 05:30:55PM +0800, Kevin Lo wrote:
> On Tue, Oct 30, 2018 at 09:43:08AM +0100, Patrick Wildt wrote:
> > + if (sc->ure_flags & URE_FLAG_8152)
> > + ifp->ifp_hardmtu = URE_MAX_FRAMELEN_8152;
> > + else
> > + ifp
Hi,
I recently wanted to use VLANs on ure(4) but failed. As it turns out,
hardmtu is set to 1500 which apparently does not leave enough space
for the VLAN tag. It looks like the Gigabit Version does even support
Jumbo frames. Thus we can set the maximum framelen on the RX path
to something bigg
On Tue, Oct 02, 2018 at 06:07:22PM +0200, Mark Kettenis wrote:
> > Date: Tue, 2 Oct 2018 17:24:42 +0200
> > From: Patrick Wildt
> >
> > Hi,
> >
> > we already do have the sources for LLDB, the only thing left to do is
> > add the build infrastr
101 - 200 of 502 matches
Mail list logo
