* 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
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 @@
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
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
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
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
> > >
> 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
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
> >
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
>
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
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
> 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
>
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
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
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
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.
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
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)
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
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
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
>
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
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
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
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 -
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
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
27 matches
Mail list logo