Re: de-hole some structs on amd64

On Sat, May 19, 2018 at 4:30 PM, Amit Kulkarni wrote: > > I tested removing some slop (i.e. structure packing/de-holing) on amd64, > this went through a full kernel + userland build. > Parts of this are probably okay, but there's some stuff which needs better placement vs

Re: sdhc(4) ACPI improvements

On Mon, May 21, 2018 at 01:22:50AM +0200, Mark Kettenis wrote: > Diff below does two things: > > 1. Put controllers and child devices into _PS0. It seems the BIOS is >supposed to deliver them to us in that state, but apparently some >BIOSen don't do that. > > 2. Override the card detect

sdhc(4) ACPI improvements

Diff below does two things: 1. Put controllers and child devices into _PS0. It seems the BIOS is supposed to deliver them to us in that state, but apparently some BIOSen don't do that. 2. Override the card detect if ACPI says that the child devices are non-removable. Apparently SDHC

Re: dwiic acpi improvement

On Sun, May 20, 2018 at 08:51:03PM +0200, Mark Kettenis wrote: > > Date: Sat, 19 May 2018 18:48:15 -0700 > > From: Mike Larkin > > > > On Sat, May 19, 2018 at 09:44:22PM +0200, Mark Kettenis wrote: > > > I'm working on some i2c drivers that are closely tied to acpi. These

Should whois(1) and IPv6 default to ANICHOST?

Hi, This is very naive patch for whois(1) which makes it work by default for IPv6 addresses. I went with very minimal approach here. If string contains colon, it's asumed to be IPv6 address. Comments welcome. Please CC me, as I'm not subscribed to the list. Index: whois.c

Re: dwiic acpi improvement

> Date: Sat, 19 May 2018 18:48:15 -0700 > From: Mike Larkin > > On Sat, May 19, 2018 at 09:44:22PM +0200, Mark Kettenis wrote: > > I'm working on some i2c drivers that are closely tied to acpi. These > > drivers need to call into acpi and need to know their acpi node. The

Re: Wake the acpi thread up for gpio events

On Sun, May 20, 2018 at 11:28:14AM +0200, Mark Kettenis wrote: > > Date: Sun, 20 May 2018 10:44:49 +0200 > > From: Martin Pieuchot > > > > On 19/05/18(Sat) 21:39, Mark Kettenis wrote: > > > Without the wakeup, the event doesn't get scheduled until some other > > > event wakes

Re: [UPDATE] FreeType 2.9.1

On Thu, Apr 26, 2018 at 01:01:33PM +0200, David Coppa wrote: > > Hi all, > > Attached you will find an update to the latest freetype (2.9.1). > > I've rebuilt all my stuff (i3, chromium, urxvt, mpv, etc.) with it, > but a real bulk build by the usual suspects would be useful. > > Noteworthy

Re: patch: add --localize-hidden option to objcopy

On Sun, May 20, 2018 at 11:09:48AM +0200, Mark Kettenis wrote: > > Date: Sun, 20 May 2018 10:26:44 +0200 > > From: Sebastien Marie > > > > Hi, > > > > While trying to build git HEAD of radare2, I found us objcopy(1) doesn't > > have the --localize-hidden option. > > > > As

Re: Wake the acpi thread up for gpio events

> Date: Sun, 20 May 2018 10:44:49 +0200 > From: Martin Pieuchot > > On 19/05/18(Sat) 21:39, Mark Kettenis wrote: > > Without the wakeup, the event doesn't get scheduled until some other > > event wakes up the acpi thread. On one of my machines the gpio event > > reads a status

Re: patch: add --localize-hidden option to objcopy

> Date: Sun, 20 May 2018 10:26:44 +0200 > From: Sebastien Marie > > Hi, > > While trying to build git HEAD of radare2, I found us objcopy(1) doesn't > have the --localize-hidden option. > > As the option was proposed in >

Re: Wake the acpi thread up for gpio events

On 19/05/18(Sat) 21:39, Mark Kettenis wrote: > Without the wakeup, the event doesn't get scheduled until some other > event wakes up the acpi thread. On one of my machines the gpio event > reads a status byte over i2c in repsonse of a gpio event. Without the > wakeup that status byte has often

patch: add --localize-hidden option to objcopy

Hi, While trying to build git HEAD of radare2, I found us objcopy(1) doesn't have the --localize-hidden option. As the option was proposed in https://sourceware.org/ml/binutils/2006-06/msg00204.html (in 2006), and commited in GPLv2 tree of binutils, I think the patch is suitable for us too.