Re: vmctl: parse_size(): Use local variable instead of function parameter

2019-12-16 Thread Pratik Vyas
* Klemens Nanni [2019-12-16 23:42:04 +0100]: On Fri, Dec 06, 2019 at 06:49:52PM +0100, Klemens Nanni wrote: The parse_size() wrapper around scan_scaled(3) writes its intermediate result to the function argument which is always passed as literal zero. This seems odd, the function parameter

audio(4): *sleep(9) -> *sleep_nsec(9)

2019-12-16 Thread Scott Cheloha
ok? Index: audio.c === RCS file: /cvs/src/sys/dev/audio.c,v retrieving revision 1.183 diff -u -p -r1.183 audio.c --- audio.c 7 Oct 2019 10:47:08 - 1.183 +++ audio.c 17 Dec 2019 00:52:48 - @@ -1492,8 +1492,8 @@

Re: [PATCH] add support for more Nuvoton chips to lm(4)

2019-12-16 Thread Todd Mortimer
Hi Joe, On Mon, Dec 16, 2019 at 12:04:57PM -0500, Joe Gidi wrote: > Hi Todd, > > Thanks for taking the time to review and offer improvements. I'm attaching > a new diff that incorporates your suggestion for simplifying the matching > and eliminating the unneeded struct and function. It is

Re: vmctl: parse_size(): Use local variable instead of function parameter

2019-12-16 Thread Klemens Nanni
On Fri, Dec 06, 2019 at 06:49:52PM +0100, Klemens Nanni wrote: > The parse_size() wrapper around scan_scaled(3) writes its intermediate > result to the function argument which is always passed as literal zero. > > This seems odd, the function parameter has no meaning but merely serves > as

openssl.1: note default -md value for openssl enc and how to get list of available hashes

2019-12-16 Thread Fabio Scotoni
This diff changes the documentation of openssl(1) enc to note the default value (sha256) and replace the "hardcoded" list of md5, sha1 with instructions to use list-message-digest-algorithms instead. Inspired by a conversation on misc@ a few weeks ago ("LibreSSL vs. OpenSSL enc command"). Perhaps

Re: piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Bryan Steele
On Mon, Dec 16, 2019 at 09:05:47PM +0100, Claudio Jeker wrote: > On Mon, Dec 16, 2019 at 08:02:55PM +0100, Mark Kettenis wrote: > > > Date: Mon, 16 Dec 2019 12:37:51 +0100 > > > From: Claudio Jeker > > > > > > This diff should add support for newer smbus controllers used on newer AMD > > >

Re: piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Mark Kettenis
> Date: Mon, 16 Dec 2019 21:05:47 +0100 > From: Claudio Jeker > Cc: tech@openbsd.org > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Mon, Dec 16, 2019 at 08:02:55PM +0100, Mark Kettenis wrote: > > > Date: Mon, 16 Dec 2019 12:37:51 +0100 > > > From: Claudio Jeker

Re: piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Claudio Jeker
On Mon, Dec 16, 2019 at 08:02:55PM +0100, Mark Kettenis wrote: > > Date: Mon, 16 Dec 2019 12:37:51 +0100 > > From: Claudio Jeker > > > > This diff should add support for newer smbus controllers used on newer AMD > > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the > >

Re: piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Jasper Lievisse Adriaanse
On Mon, Dec 16, 2019 at 12:37:51PM +0100, Claudio Jeker wrote: > This diff should add support for newer smbus controllers used on newer AMD > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the > iic(4) busses attach but there is nothing detected on them (well possible >

Re: [PATCH] add support for more Nuvoton chips to lm(4)

2019-12-16 Thread Theo de Raadt
Joe Gidi wrote: > Hi Todd, > > Thanks for taking the time to review and offer improvements. I'm attaching > a new diff that incorporates your suggestion for simplifying the matching > and eliminating the unneeded struct and function. It is definitely a > cleaner, simpler approach. I also

Re: [PATCH] add support for more Nuvoton chips to lm(4)

2019-12-16 Thread Joe Gidi
Hi Todd, Thanks for taking the time to review and offer improvements. I'm attaching a new diff that incorporates your suggestion for simplifying the matching and eliminating the unneeded struct and function. It is definitely a cleaner, simpler approach. I also corrected the whitespace issue you

Re: piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Mark Kettenis
> Date: Mon, 16 Dec 2019 12:37:51 +0100 > From: Claudio Jeker > > This diff should add support for newer smbus controllers used on newer AMD > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the > iic(4) busses attach but there is nothing detected on them (well possible >

fix HW_IF_CONFIG register write in iwm(4)

2019-12-16 Thread Stefan Sperling
I noticed that iwm(4) is overwriting the entire HW_IF_CONFIG register with a hardcoded value, while Linux does a "read + clear some bits + set some bits + write" operation instead (see iwl_mvm_nic_config() in the Linux source file drivers/net/wireless/intel/iwlwifi/mvm/ops.c). Our old code wrote

Re: attention please: host's IP stack behavior got changed slightly

2019-12-16 Thread Alexandr Nedvedicky
Hello, On Mon, Dec 16, 2019 at 03:21:43PM +0100, Claudio Jeker wrote: > On Mon, Dec 16, 2019 at 02:13:50PM +0100, Alexander Bluhm wrote: > > On Sun, Dec 15, 2019 at 03:17:26PM +0100, Alexandr Nedvedicky wrote: > > > Hello Daniel, > > > > > > thanks for reporting back. > > > > > > > > > > Should

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 > > ublink0 at uhidev1 reportid 1 > > led0 at

Re: piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Bryan Steele
On Mon, Dec 16, 2019 at 03:19:30PM +0100, Claudio Jeker wrote: > On Mon, Dec 16, 2019 at 08:46:21AM -0500, Bryan Steele wrote: > > On Mon, Dec 16, 2019 at 12:37:51PM +0100, Claudio Jeker wrote: > > > This diff should add support for newer smbus controllers used on newer AMD > > > chipsets.

Re: attention please: host's IP stack behavior got changed slightly

2019-12-16 Thread Claudio Jeker
On Mon, Dec 16, 2019 at 02:13:50PM +0100, Alexander Bluhm wrote: > On Sun, Dec 15, 2019 at 03:17:26PM +0100, Alexandr Nedvedicky wrote: > > Hello Daniel, > > > > thanks for reporting back. > > > > > > > Should the rdr-to rule still work? I fixed it with using the "Port foo" > > > directive in my

Re: piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Claudio Jeker
On Mon, Dec 16, 2019 at 08:46:21AM -0500, Bryan Steele wrote: > On Mon, Dec 16, 2019 at 12:37:51PM +0100, Claudio Jeker wrote: > > This diff should add support for newer smbus controllers used on newer AMD > > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the > > iic(4)

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

2019-12-16 Thread Stuart Henderson
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 > ublink0 at uhidev1 reportid 1 > led0 at ublink0: 2 LEDs Does this attachment break the normal software used with

Re: attention please: host's IP stack behavior got changed slightly

2019-12-16 Thread Stuart Henderson
On 2019/12/16 13:44, Alexander Bluhm wrote: > On Sat, Dec 14, 2019 at 09:26:06PM -0500, Daniel Jakots wrote: > > My sshd doesn't listen on port 22 but I was too lazy to change it in my > > sshd config so I have a rule > > > > pass in [...] rdr-to 127.0.0.1 port ssh [...] > > A pf divert-to rule

Re: piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Bryan Steele
On Mon, Dec 16, 2019 at 12:37:51PM +0100, Claudio Jeker wrote: > This diff should add support for newer smbus controllers used on newer AMD > chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the > iic(4) busses attach but there is nothing detected on them (well possible >

Re: attention please: host's IP stack behavior got changed slightly

2019-12-16 Thread Alexander Bluhm
On Sun, Dec 15, 2019 at 03:17:26PM +0100, Alexandr Nedvedicky wrote: > Hello Daniel, > > thanks for reporting back. > > > > Should the rdr-to rule still work? I fixed it with using the "Port foo" > > directive in my sshd config (and a simple "pass in to port foo") in the > > meantime. > > My

Re: attention please: host's IP stack behavior got changed slightly

2019-12-16 Thread Alexander Bluhm
On Sat, Dec 14, 2019 at 09:26:06PM -0500, Daniel Jakots wrote: > My sshd doesn't listen on port 22 but I was too lazy to change it in my > sshd config so I have a rule > > pass in [...] rdr-to 127.0.0.1 port ssh [...] A pf divert-to rule is better for this use case. bluhm

piixpm(4) add support for newer AMD chipsets

2019-12-16 Thread Claudio Jeker
This diff should add support for newer smbus controllers used on newer AMD chipsets. Especially Hudson-2 and Kerncz based chipsets. On my Ryzen 5 the iic(4) busses attach but there is nothing detected on them (well possible that I missed something). I also implemented the up to 4 busses available

Infinite sleeps in sys/kern

2019-12-16 Thread Martin Pieuchot
Convert the remaining ones to {m,t}sleep_nsec(9), ok? Index: kern/kern_bufq.c === RCS file: /cvs/src/sys/kern/kern_bufq.c,v retrieving revision 1.32 diff -u -p -r1.32 kern_bufq.c --- kern/kern_bufq.c16 Aug 2017 17:52:17 -

Re: ospf6d: rework priority handling

2019-12-16 Thread Denis Fondras
On Sun, Dec 15, 2019 at 04:07:11PM +0100, Sebastian Benoit wrote: > unrelated to this diff: I wonder if the manpage (of both ospfd and pspf6d) > should mention that changing fib-priority with a reload is equivalent toa > uncouple/couple? > If I understand correctly what you mean, I don't think

Re: bktr(4): tsleep(9) -> tsleep_nsec(9)

2019-12-16 Thread Alexandre Ratchov
On Sun, Dec 15, 2019 at 10:28:32PM -0600, Scott Cheloha wrote: > I don't have any of these cards, but these are straightforward conversions. > > ok? > ok