Re: initialize variables patch for bn_nist.c

I'm ok with this. On Thu, Jul 14, 2016 at 4:57 AM, Kinichiro Inoguchi < kinichiro.inogu...@gmail.com> wrote: > Hi, > > When I build LibreSSL portable on HP-UX 11.3 with HP C/aC++ compiler, > this warning is detected. > > ... > "bn/bn_nist.c", line 611: warning #2549-D: variable "buf" is used

Re: A patch for allowing IPv6-only or IPv4-only bridges

On 13/07/16(Wed) 18:28, Quentin Rameau wrote: > > Hello there, > Hi, > > > Here is my patch that adds support for creating IPv6-only or > >IPv4-only bridges. This is different from simply blocking one of the > >protocols via PF - it allows you to create a setup where IPv4 is routed > >and

Add hotkey support for Asus Zenbook UX31A

Attached patch adds hotkey support for the Zenbook UX31A. I wasn't sure what to name the magic string, so please rename to whatever you find more suitable. Next step in getting the Zenbook UX31A to work better is finding a neat way to prevent acpivideo from attaching. After the recent refactoring

Re: Add hotkey support for Asus Zenbook UX31A

> Date: Thu, 14 Jul 2016 19:15:46 +0200 > From: Frank Groeneveld > > Attached patch adds hotkey support for the Zenbook UX31A. I wasn't sure > what to name the magic string, so please rename to whatever you find > more suitable. > > Next step in getting

Re: Add hotkey support for Asus Zenbook UX31A

On Thu, Jul 14, 2016 at 07:42:28PM +0200, Mark Kettenis wrote: > Please send the acpidump output for that machine; "pnp0c14" for an > ASUS-specific device looks wrong. Thanks for reviewing. This the only ACPI device that works when attaching (volume buttons start working). I've added the dumps

Re: armv7/imx: imxpcie(4) driver & device tree problem

> Date: Thu, 14 Jul 2016 11:56:47 +0200 (CEST) > From: Mark Kettenis > > > > Time to investigate the > > > > > > sdmmc0: can't enable card > > > > > > message I see on my CuBox-i4Pro once more. > > > > I'd look at the no-1-8v property to start with (ommmc should be

Re: acpiec: handle burst mode failure

On Thu, 14 Jul 2016 at 16:31:32 -0500, joshua stein wrote: > Also, I just checked FreeBSD and they appear to do something similar > to my patch, where they check that the EC burst mode flag is set in > the status after trying to enable it: > >

Re: jot(1) changed behavior

On 16-07-14 12:00:21, Philippe Meunier wrote: > Hello, > > According to jot(1)'s man page: > > "$ jot -w %d -r 10 1 4 | sort -n | uniq -c > 33306 1 > 33473 2 > 33221 3 > > Note that with random sequences, all numbers generated will be smaller > than the upper bound. The largest value

Re: acpiec: handle burst mode failure

> Date: Thu, 14 Jul 2016 16:41:10 -0500 > From: joshua stein > > On Thu, 14 Jul 2016 at 16:31:32 -0500, joshua stein wrote: > > Also, I just checked FreeBSD and they appear to do something similar > > to my patch, where they check that the EC burst mode flag is set in > > the

multiple patches available

Several patches are available to fix kernel errata. Please refer to http://www.openbsd.org/errata59.html and errata58.html for details and patches. Patches for 5.9 include: 013: RELIABILITY FIX: July 14, 2016 All architectures Splicing sockets in a loop could cause a kernel spin. 014:

other usermount bugs

In addition to the patched bugs, several panics were discovered by NCC that can be triggered by root or users with the usermount option set. These bugs are not getting patched because we believe they are only the tip of the iceberg. The mount system call exposes too much code to userland to be

initialize variables patch for bn_nist.c

Hi, When I build LibreSSL portable on HP-UX 11.3 with HP C/aC++ compiler, this warning is detected. ... "bn/bn_nist.c", line 611: warning #2549-D: variable "buf" is used before its value is set nist_set_224(buf.bn, c_d, 14, 13, 12, 11, 10, 9, 8); ^ ... To initialize these variables before

armv7/imx: imxpcie(4) driver & device tree problem

I am working on a MD PCI-E driver for the armv7/imx platform. It attaches via FDT/simplebus, ascertaining its physical memory addresses from the fdt structure originating from the dtb files present on the msdos bootloader partition. The dtb files we're using now have the cubox's 'pcie' nodes

Re: armv7/imx: imxpcie(4) driver & device tree problem

On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote: > I am working on a MD PCI-E driver for the armv7/imx platform. It > attaches via FDT/simplebus, ascertaining its physical memory addresses > from the fdt structure originating from the dtb files present on the > msdos bootloader

Re: armv7/imx: imxpcie(4) driver & device tree problem

> From: Ian Sutton > Date: Thu, 14 Jul 2016 03:20:34 -0400 (EDT) > > I am working on a MD PCI-E driver for the armv7/imx platform. Before you continue you should talk to patrick@. I believe he had some working code already.

Re: armv7/imx: imxpcie(4) driver & device tree problem

On Thu, Jul 14, 2016 at 11:34:05AM +0200, Mark Kettenis wrote: > > Date: Thu, 14 Jul 2016 17:53:22 +1000 > > From: Jonathan Gray > > > > On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote: > > > I am working on a MD PCI-E driver for the armv7/imx platform. It > > >

Re: armv7/imx: imxpcie(4) driver & device tree problem

> Date: Thu, 14 Jul 2016 17:53:22 +1000 > From: Jonathan Gray > > On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote: > > I am working on a MD PCI-E driver for the armv7/imx platform. It > > attaches via FDT/simplebus, ascertaining its physical memory addresses > > from

Re: armv7/imx: imxpcie(4) driver & device tree problem

> Date: Thu, 14 Jul 2016 19:45:32 +1000 > From: Jonathan Gray > > On Thu, Jul 14, 2016 at 11:34:05AM +0200, Mark Kettenis wrote: > > > Date: Thu, 14 Jul 2016 17:53:22 +1000 > > > From: Jonathan Gray > > > > > > On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian

Re: armv7/imx: imxpcie(4) driver & device tree problem

On Thu, Jul 14, 2016 at 11:34:05AM +0200, Mark Kettenis wrote: > > Date: Thu, 14 Jul 2016 17:53:22 +1000 > > From: Jonathan Gray > > > > On Thu, Jul 14, 2016 at 03:20:34AM -0400, Ian Sutton wrote: > > > I am working on a MD PCI-E driver for the armv7/imx platform. It > > >

Re: acpiec: handle burst mode failure

On Sat, 09 Jul 2016 at 16:32:15 -0700, Philip Guenther wrote: > No newer bios for this thing? :-( It is actually the open-source Chrome EC found on the Chromebook Pixel (among others), and according to the source code for the version on this machine, it did not implement burst mode in its ACPI