Re: tmpfs & UVM aobj

2021-04-22 Thread Patrick Wildt
Am Thu, Apr 22, 2021 at 11:19:22AM +0200 schrieb Martin Pieuchot: > uao_shrink() and uao_grow() are only used by TMPFS, ok to place them > under an #ifdef? This save some bytes on RAMDISKs. sure, ok patrick@ > Index: uvm/uvm_aobj.c >

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

2021-04-20 Thread Patrick Wildt
Am Mon, Apr 19, 2021 at 10:25:39AM +0200 schrieb Tilo Stritzky: > On 10/04/21 22:56 Tilo Stritzky wrote: > > umb interfaces advertise themselves as generic devices. > > Network makes a lot more sense, I think. > > tested on amd64. > > Having seen no response on this one, I'ld like to expand a

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

2021-04-14 Thread Patrick Wildt
Am Thu, Apr 15, 2021 at 12:47:44AM +0200 schrieb Patrick Wildt: > On Wed, Apr 14, 2021 at 11:20:56PM +0200, Patrick Wildt wrote: > > Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis: > > > > Date: Wed, 14 Apr 2021 22:25:16 +0200 > > > > From: Patri

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

2021-04-14 Thread Patrick Wildt
On Wed, Apr 14, 2021 at 11:20:56PM +0200, Patrick Wildt wrote: > Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis: > > > Date: Wed, 14 Apr 2021 22:25:16 +0200 > > > From: Patrick Wildt > > > > > > Am Wed, Apr 14, 2021 at 10:17:58PM

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

2021-04-14 Thread Patrick Wildt
Am Wed, Apr 14, 2021 at 10:55:14PM +0200 schrieb Mark Kettenis: > > Date: Wed, 14 Apr 2021 22:25:16 +0200 > > From: Patrick Wildt > > > > Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt: > > > Hi, > > > > > > Parallels 16 for M

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

2021-04-14 Thread Patrick Wildt
Am Wed, Apr 14, 2021 at 10:17:58PM +0200 schrieb Patrick Wildt: > Hi, > > Parallels 16 for Mac supports the Apple M1 SoC now, and since it does > provide an EFI 'BIOS', our images boot out of the box (once converted > to 'hdd' or supplied as USB stick). > > Unfortunately

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

2021-04-14 Thread Patrick Wildt
Hi, Parallels 16 for Mac supports the Apple M1 SoC now, and since it does provide an EFI 'BIOS', our images boot out of the box (once converted to 'hdd' or supplied as USB stick). Unfortunately virtio doesn't attach, because Parallels seems to provide a 'new' version 2. The following diff adds

Re: uvideo(4) new quirk flag UVIDEO_FLAG_NOATTACH

2021-04-05 Thread Patrick Wildt
Am Mon, Apr 05, 2021 at 11:19:02PM +0200 schrieb Mark Kettenis: > > Date: Mon, 5 Apr 2021 23:15:23 +0200 > > From: Marcus Glocker > > > > On Mon, Apr 05, 2021 at 07:30:43AM -0700, Greg Steuck wrote: > > > > > OK gnezdo with a usability question inline. > > > > Thanks. See below. > > > > >

Re: simpleaudio: set sysclk before using it

2021-04-05 Thread Patrick Wildt
Am Sun, Apr 04, 2021 at 11:17:54PM +0200 schrieb Mark Kettenis: > > Date: Sun, 4 Apr 2021 22:24:57 +0200 > > From: Klemens Nanni > > Cc: Mark Kettenis > > > > On Sun, Apr 04, 2021 at 10:01:50PM +0200, Mark Kettenis wrote: > > > > Date: Sun, 4 Apr 2021 21:08:09 +0200 > > > > From: Klemens Nanni

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

2021-03-31 Thread Patrick Wildt
Am Mon, Mar 29, 2021 at 07:16:18AM +0200 schrieb Klemens Nanni: > The datasheet says the hardware's default State-Of-Charge threshold is > three percent, i.e. the gauge pulls down the pin to logic low at 3% > remaining battery life. > > My Pinebook Pro's fuel gauge actually shows an alert level

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

2021-03-28 Thread Patrick Wildt
Am Sun, Mar 28, 2021 at 10:53:53AM +0100 schrieb Stuart Henderson: > On 2021/03/25 00:14, Stuart Henderson wrote: > > On 2021/03/25 00:30, Patrick Wildt wrote: > > > Without having looked at anything, it might be worth looking at the most > > > recent mail in this threa

Re: cwfg: flag sensor as invalid on bogus reads

2021-03-26 Thread Patrick Wildt
Am Sat, Mar 27, 2021 at 12:00:32AM +0100 schrieb Klemens Nanni: > On Fri, Mar 26, 2021 at 11:22:32PM +0100, Patrick Wildt wrote: > > It's pretty normal for voltage to go up once AC is connected. In the > > end, afaik batteries are charged by applying voltage. Additionally >

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

2021-03-26 Thread Patrick Wildt
Am Sat, Mar 27, 2021 at 12:09:25AM +0100 schrieb Klemens Nanni: > On Fri, Mar 26, 2021 at 11:28:37PM +0100, Patrick Wildt wrote: > > > fdt = (void *)addr; > > > - return (0); > > > + return (1); > > > > Wait, you've been saying that return code 1 ma

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

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

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

2021-03-26 Thread Patrick Wildt
Am Wed, Mar 24, 2021 at 07:20:29PM +0100 schrieb Klemens Nanni: > Bootloader command functions must return zero in case of failure, > returning 1 tells the bootloader to boot the file. > > arm64's `machine dtb' command has it the wrong way so using it triggers > a boot that doesn't make any

Re: cwfg: flag sensor as invalid on bogus reads

2021-03-26 Thread Patrick Wildt
Am Fri, Mar 26, 2021 at 12:26:51AM +0100 schrieb Klemens Nanni: > Follow-up to "arm64: make cwfg(4) report battery information to apm(4)". > > This driver continues to report stale hw.sensors values when reading > them fails, which can easily be observed on a Pinebook Pro after > plugging in the

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

2021-03-26 Thread Patrick Wildt
Am Fri, Mar 26, 2021 at 12:12:44PM +0100 schrieb Mark Kettenis: > > Date: Fri, 26 Mar 2021 19:43:23 +0900 (JST) > > From: YASUOKA Masahiko > > > > Hi, > > > > On Fri, 26 Mar 2021 09:30:43 +0100 > > Jan Klemkow wrote: > > > If you want to boot OpenBSD on an HP EliteBook 830 G7/G8, the

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

2021-03-24 Thread Patrick Wildt
On Wed, Mar 24, 2021 at 11:23:11PM +, Stuart Henderson wrote: > In my ongoing search to find a umb(4) that will actually work that > isn't the one in my laptop (since my EM7305 has been a failure), > I picked up a Huawei ME906s-158 off ebay. It attaches to cdce and ugen > and fails to work: >

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

2021-03-15 Thread Patrick Wildt
Am Mon, Mar 15, 2021 at 08:59:05AM +0100 schrieb Jan Klemkow: > On Mon, Mar 15, 2021 at 01:35:28AM -0600, Theo de Raadt wrote: > > My comments are about the "text name", which goes into every kernel > > anyone compiles. > > > > It should be as short as possible. > > Sorry, I missed that point. >

acpi(4): pass DMA tag to ACPI tables

2021-03-06 Thread Patrick Wildt
Hi, to be able to have acpiiort(4) pass a DMA tag to smmu(4), acpiiort(4) needs to be passed a DMA tag. So far acpi(4) only seems to pass it on acpi_foundhid(), but the ACPI table drivers don't get it. So, let's just pass the default DMA tag. ok? Patrick diff --git a/sys/dev/acpi/acpi.c

Re: Read `ps_single' once

2021-03-04 Thread Patrick Wildt
Am Thu, Mar 04, 2021 at 10:42:24AM +0100 schrieb Mark Kettenis: > > Date: Thu, 4 Mar 2021 10:34:24 +0100 > > From: Martin Pieuchot > > > > Running t/rw/msleep(9) w/o KERNEL_LOCK() implies that a thread can > > change the value of `ps_single' while one of its siblings might be > > dereferencing

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

2021-02-24 Thread Patrick Wildt
Am Wed, Feb 24, 2021 at 05:34:48PM +0100 schrieb Jan Klemkow: > Hi, > > While attaching the following disks, the nvme driver runs into a NULL > dereference in nvme_scsi_capacity16() and nvme_scsi_capacity(). > > nvme0 at pci1 dev 0 function 0 vendor "Intel", unknown product 0x0a54 rev > 0x00:

sdmmc(4): check and retry bus width change

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

Re: add simplepmbus(4)

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

Re: Posted vs. non-posted device access

2021-02-14 Thread Patrick Wildt
Am Mon, Feb 15, 2021 at 09:55:56AM +1000 schrieb David Gwynne: > > > > On 15 Feb 2021, at 07:54, Mark Kettenis wrote: > > > > One of the aspects of device access is whether CPU writes to a device > > are posted or non-posted. For non-posted writes, the CPU will wait > > for the device to

Re: Add missing break statement on if_rge.c

2021-02-11 Thread Patrick Wildt
Am Thu, Feb 11, 2021 at 12:24:37PM + schrieb Ricardo Mestre: > Hi, > > Add missing break statement. OK? makes sense to me, ok patrick@ > CID 1501710 > > Index: if_rge.c > === > RCS file: /cvs/src/sys/dev/pci/if_rge.c,v >

Re: isakmpd link dynamically

2021-02-11 Thread Patrick Wildt
Am Thu, Feb 11, 2021 at 11:29:58AM +0100 schrieb Alexander Bluhm: > - recommit in /usr/src/usr.sbin -> we loose history I know no one cares about git, but if the move was committed in a "single cvs commit", git would understand it's simply a move of files. So yeah, cvs wouldn't cope, but git

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

2021-02-11 Thread Patrick Wildt
Already committed as of 7 minutes ago, heh! Am Thu, Feb 11, 2021 at 10:48:16AM + schrieb Ricardo Mestre: > Hi, > > It seems this got the args swapped as described in CID 1501717. > > stoeplitz_ip6port being a macro for stoeplitz_hash_ip6port and the arguments > placed as shown below.

Re: rasops1

2020-12-23 Thread Patrick Wildt
Am Wed, Dec 23, 2020 at 11:32:58PM +0100 schrieb Frederic Cambus: > Hi Mark, > > On Fri, Dec 18, 2020 at 10:33:52PM +0100, Mark Kettenis wrote: > > > The diff below disables the optimized functions on little-endian > > architectures such that we always use rasops1_putchar(). This makes > >

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

2020-12-23 Thread Patrick Wildt
Am Wed, Dec 23, 2020 at 05:04:23PM -0600 schrieb Scott Cheloha: > On Wed, Dec 23, 2020 at 02:42:18PM -0700, Theo de Raadt wrote: > > I agree. This chunk below is really gross and does not follow the > > special wakeup channel metaphor. > > > > It is *entirely clear* that a called "nowake" has

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

2020-12-23 Thread Patrick Wildt
Am Wed, Dec 23, 2020 at 10:44:21AM +0100 schrieb Marcus Glocker: > On Wed, 23 Dec 2020 09:47:44 +0100 > Marcus Glocker wrote: > > > On Tue, 22 Dec 2020 20:55:41 +0100 > > Marcus Glocker wrote: > > > > > > > Did you consider incrementing xx->ntrb instead? > > > > > > >That doesn't work

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

2020-10-26 Thread Patrick Wildt
On Mon, Oct 26, 2020 at 09:12:17AM +0100, Stefan Huber wrote: > Hey all, > > I recently got hands on an USB-TTY converter that is not (yet) supported by > OpenBSD: > > > addr 03: 067b:23a3 Prolific Technology Inc., USB-Serial Controller > > Simply adding the device ID to usbdevs and the uplcom

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

2020-10-11 Thread Patrick Wildt
On Sun, Oct 11, 2020 at 08:12:29AM +0200, Martin Pieuchot wrote: > On 09/10/20(Fri) 12:37, Jonathon Fletcher wrote: > > In xhci_xfer_get_trb, the count of transfer buffers in the pipe > > (xp->free_trbs) is always decremented but the count of transfer buffers > > used in the transfer (xx->ntrb)

Re: mfokclock(4) -> mfokrtc(4): loongson's hugging arm

2020-09-29 Thread Patrick Wildt
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

mfokclock(4) -> mfokrtc(4): loongson's hugging arm

2020-09-29 Thread Patrick Wildt
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

Re: utpms(4): fix geyser 2 y_sensors

2020-09-11 Thread Patrick Wildt
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

Re: softintr.h comment tweak

2020-08-14 Thread Patrick Wildt
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:

Re: Enable arm64 PAN feature

2020-08-13 Thread Patrick Wildt
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

Re: xhci(4) isoc: fix bogus handling of chained TRBs

2020-07-10 Thread Patrick Wildt
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

replace IFQ_SET_MAXLEN and IFQ_IS_EMPTY

2020-07-10 Thread Patrick Wildt
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

Re: remove compat macros IFQ_ENQUEUE, IFQ_DEQUEUE and IFQ_LEN

2020-07-10 Thread Patrick Wildt
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 re

replace IFQ_PURGE with ifq_purge

2020-07-10 Thread Patrick Wildt
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 {

remove compat macros IFQ_ENQUEUE, IFQ_DEQUEUE and IFQ_LEN

2020-07-10 Thread Patrick Wildt
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

Re: Add "Spleen 6x12" font to wsfont

2020-07-08 Thread Patrick Wildt
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

Re: xhci: zero length multi-TRB inbound xfer does not work

2020-06-24 Thread Patrick Wildt
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

xhci(4): acknowledge interrupts before calling usb_schedsoftintr()

2020-06-23 Thread Patrick Wildt
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

umass(4): consistently use sc_xfer_flags for polling mode

2020-06-23 Thread Patrick Wildt
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

Re: SSE in kernel?

2020-06-23 Thread Patrick Wildt
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

Re: WireGuard patchset for OpenBSD, rev. 3

2020-06-21 Thread Patrick Wildt
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

Re: sparc64 boot issue on qemu

2020-05-30 Thread Patrick Wildt
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

powerpc64: Target Info in clang for __OpenBSD__

2020-05-19 Thread Patrick Wildt
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.

Re: libsa's in_cksum() cannot handle payload of odd-length?

2020-05-18 Thread Patrick Wildt
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

Re: libsa's in_cksum() cannot handle payload of odd-length?

2020-05-18 Thread Patrick Wildt
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 called

libsa's in_cksum() cannot handle payload of odd-length?

2020-05-18 Thread Patrick Wildt
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

Re: sdmmc: CIS tuple can have empty body

2020-04-28 Thread 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: > > sdmmc0: CIS parse error at 4136, tuple code 0x14, length 0

sdmmc: CIS tuple can have empty body

2020-04-28 Thread Patrick Wildt
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

Re: [patch] Check for -1 explicitly in getpeereid.c

2020-04-26 Thread Patrick Wildt
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:

coherent em(4) descriptor rings (to be able to run on my arm64 machine)

2020-04-26 Thread 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 is the descriptor ring coherency. I looked into the code, tried to find if

Re: usb(4): use cacheable buffers for data transfers (massive speedup)

2020-04-02 Thread Patrick Wildt
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: > > > &

Re: usb(4): use cacheable buffers for data transfers (massive speedup)

2020-04-01 Thread Patrick Wildt
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: > > > &

Re: usb(4): use cacheable buffers for data transfers (massive speedup)

2020-04-01 Thread Patrick Wildt
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: > > > &

Re: usb(4): use cacheable buffers for data transfers (massive speedup)

2020-04-01 Thread 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 01:41:06PM +0100, Patrick Wildt wrote: > > > &

Re: usb(4): use cacheable buffers for data transfers (massive speedup)

2020-04-01 Thread Patrick Wildt
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: > > >

Re: usb(4): use cacheable buffers for data transfers (massive speedup)

2020-03-18 Thread Patrick Wildt
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, all USB

usb(4): use cacheable buffers for data transfers (massive speedup)

2020-03-18 Thread Patrick Wildt
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

Re: Fix brightness control on ASUS 1005PXD

2020-03-16 Thread Patrick Wildt
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

Re: New bwfm device (bcm43341)

2020-03-13 Thread Patrick Wildt
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

Re: New bwfm device (bcm43341)

2020-03-13 Thread Patrick Wildt
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

com(4) at pci

2020-03-03 Thread Patrick Wildt
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

puc(4): 64-bit BARs

2020-03-02 Thread 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 other. For 64-bit BARs that's wrong. On a device with a 64-bit BAR, it will

Re: [PATCH] Gemini Lake SoC pcidevs and eMMC

2020-02-04 Thread Patrick Wildt
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 >

hidmt(4): only allow hid_input kind

2020-01-25 Thread Patrick Wildt
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

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-24 Thread Patrick Wildt
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

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
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

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
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 method. But w

Re: acpivout(4): directly call ws_[gs]et_param

2020-01-23 Thread Patrick Wildt
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

acpivout(4): directly call ws_[gs]et_param

2020-01-22 Thread Patrick Wildt
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

Re: acpivout: try to consistently adjust brightness by 5%

2020-01-13 Thread Patrick Wildt
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

Re: ublink(4), led(4) and ledctl(1)

2019-12-19 Thread Patrick Wildt
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

Re: ublink(4), led(4) and ledctl(1)

2019-12-16 Thread Patrick Wildt
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 > > u

Re: ublink(4), led(4) and ledctl(1)

2019-12-13 Thread Patrick Wildt
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

ublink(4), led(4) and ledctl(1)

2019-12-13 Thread Patrick Wildt
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/sys/dev/ic/led.c @

xhci(4): correct short actlen for >64k transfers

2019-11-26 Thread Patrick Wildt
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

Re: XHCI support for bulk xfers >64k

2019-11-21 Thread Patrick Wildt
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

Re: acpivout(4): fix brightness not going up

2019-11-20 Thread Patrick Wildt
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

Re: pci_sdhc: Intel eMMC controller fix

2019-11-20 Thread Patrick Wildt
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

Re: iwm: support 9260 devices

2019-11-20 Thread Patrick Wildt
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

iwm(4): support for MSI-X

2019-11-20 Thread Patrick Wildt
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

sdhc(4): no 0V one some Intel

2019-11-19 Thread Patrick Wildt
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.

Re: Remove NetChip from cdce

2019-11-13 Thread Patrick Wildt
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

Re: fix xhci 'actlen' calculation

2019-11-12 Thread Patrick Wildt
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 'xfer->

Re: fix xhci 'actlen' calculation

2019-11-12 Thread Patrick Wildt
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's because the co

Re: fix xhci 'actlen' calculation

2019-11-12 Thread Patrick Wildt
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

acpivout(4): backlights without method to query current level

2019-10-31 Thread Patrick Wildt
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

Re: HID devices without numbered reports

2019-10-29 Thread Patrick Wildt
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

Re: HID devices without numbered reports

2019-10-29 Thread Patrick Wildt
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: > > > > > > > &g

Re: HID devices without numbered reports

2019-10-29 Thread Patrick Wildt
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

Re: HID devices without numbered reports

2019-10-28 Thread Patrick Wildt
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

Re: HID devices without numbered reports

2019-10-25 Thread Patrick Wildt
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

Re: HID devices without numbered reports

2019-10-25 Thread Patrick Wildt
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

  1   2   3   4   5   >