i2c driver for Elan Touchpad

A long while ago, Ben Pye did an i2c driver for the Elan Touchpad. I believe it had been reviewed at the time, but it was never committed. Attached is that patch against -current. OK? Index: arch/amd64/conf/GENERIC === RCS file:

Re: [PATCH] Add elan(4) touchpad driver

On Fri, Nov 09, 2018 at 04:25:13PM +, Ben Pye wrote: > On Thu, Nov 08, 2018 at 11:25:37PM -0600, joshua stein wrote: > > On Fri, 09 Nov 2018 at 03:30:07 +, b...@curlybracket.co.uk wrote: > > > Hi all, > > > > > > This patch adds a new touchpad driver, elan(4), which supports older non > >

Re: [PATCH] Fix broken bus voltage setting in sdhc

On Sat, Nov 10, 2018 at 03:45:41PM +, Ben Pye wrote: > On Sat, Nov 10, 2018 at 06:30:37AM +, Ben Pye wrote: > > On Wed, Nov 07, 2018 at 05:33:13PM +0100, Mark Kettenis wrote: > > > > From: Ben Pye > > > > Content-Type: text/plain; charset="utf-8" > > > > > > > > I have been attempting to

Re: 11n support for athn(4)

On Tue, Jan 10, 2017 at 11:08:40PM +0100, Vincent Gross wrote: > On Tue, 10 Jan 2017 00:27:47 +0100 > Stefan Sperling wrote: > > > On Mon, Jan 09, 2017 at 01:54:55PM +0100, Stefan Sperling wrote: > > > This diff adds 11n support to the athn(4) driver. > > > Requires -current

Re: acpicbkbd

On Fri, Jul 01, 2016 at 09:18:41AM -0500, joshua stein wrote: > Small ACPI driver for controlling the keyboard backlight on some > Chromebooks with wsconsctl. > This has been working for me for several days now. OK bmercer@ FWIW. > Index: sys/arch/amd64/conf/GENERIC >

Re: arm: purge arm9e, too

On Mon, Mar 21, 2016 at 11:15:48AM +0100, Patrick Wildt wrote: > Hi, > > I would like to get rid of even more unused CPUs, so we end up with only > armish, zaurus (armv5) and armv7. This diff removes ARM9E, but I also > have diffs prepared to get rid of ARM10 and ARM11. Tested here, and OK

Re: more armreg.h cleanup

On Mon, Mar 21, 2016 at 12:52:17AM +1100, Jonathan Gray wrote: > Remove defines for unsupported chips, add V5TEJ and remove incorrect > ARCH_V7 define. The number ARM Ltd armv7 chips set here is 0xf, > documented as 'Defined by CPUID scheme'. Looks OK to me. Compile tested only.

axen improvements

I've recently acquired a usb3.0->gigabit ethernet adapter. It did not attach reliably, pass traffic reliably, and it made my machine panic when I unplugged it. Takahiro HAYASHI suggested that the reset code doesn't do anything and that it should initialize the chip. Indeed that does seem to help.

Re: arm/fdt: map fdt and use given memory/bootargs

On Fri, Mar 04, 2016 at 08:08:36PM +0100, Patrick Wildt wrote: > On Fri, Mar 04, 2016 at 09:38:18AM -0500, Brandon Mercer wrote: > > On Fri, Mar 04, 2016 at 03:15:23PM +0100, Patrick Wildt wrote: > > > Hi, > > > > > > this diff makes armv7 map the FD

Re: arm/fdt: map fdt and use given memory/bootargs

On Fri, Mar 04, 2016 at 03:15:23PM +0100, Patrick Wildt wrote: > Hi, > > this diff makes armv7 map the FDT, if available, and uses it to read > information about the machine's available memory and bootargs. > > I'd like to get some opinions about the way I have implemented some > stuff. For

Re: ksh another home/end pair

On Tue, Dec 29, 2015 at 12:16 PM Ted Unangst wrote: > In tmux, home and end send different bytes. I don't know why, but I want > things to just work. We already have two different keys here, so what's one > more? (how many can there be...?) > > > Index: emacs.c >

Re: [PATCH] doas authentication type

On Thu, Aug 27, 2015 at 1:09 PM Theo de Raadt dera...@cvs.openbsd.org wrote: Sorry, I think adding an option is too much. I just committed halex's o= riginal diff to only change the type. I thought he was going to do that by now.= Hi Ted, The thing is, my patch doesn't do

Re: cpsw updates

fine on my BBB. I have no problems with this patch but then i had no known problems before. - Ben On 04/12/14 17:00, Brandon Mercer wrote: This diff will properly initialize cpsw if uboot hasn't done so already. It also adds support for 1000BaseT (RGMII) PHY found on some boards. Based

Re: ffs2 boot

It will take me about that long to newfs the 10 kvm's I plan on using ;) On Thu, Apr 17, 2014 at 5:09 AM, Otto Moerbeek o...@drijf.net wrote: On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote: On Thursday, April 17, 2014, Otto Moerbeek o...@drijf.net wrote: ... But bear in

Re: ffs2 boot

:31 AM, Brandon Mercer yourcomputer...@gmail.com wrote: It will take me about that long to newfs the 10 kvm's I plan on using ;) On Thu, Apr 17, 2014 at 5:09 AM, Otto Moerbeek o...@drijf.net wrote: On Wed, Apr 16, 2014 at 11:16:00PM -0700, Philip Guenther wrote: On Thursday, April

Re: ffs2 boot

On Wed, Apr 16, 2014 at 08:05:57PM +, Miod Vallat wrote: The other day I was doing an install in qemu-kvm and newfs was taking forever, to the tune of hours. This is similar to formatting on arm boards. In my quest to track down why, I discovered that ffs2 takes far less time to format

Re: ffs2 boot

PM, Brandon Mercer yourcomputer...@gmail.com wrote: The other day I was doing an install in qemu-kvm and newfs was taking forever, to the tune of hours. This is similar to formatting on arm boards. In my quest to track down why, I discovered that ffs2 takes far less time to format than ffs1

cpsw device timeouts

I've been trying to track down what's causing the cpsw device timeouts on the beaglebone and beaglebone black. As best I can tell disabling hardware flow control does the trick. If you're able to recreate that issue please test this diff and report your findings. Thanks. cvs diff: Diffing

Re: cpsw device timeouts

whoops, small typo in the previous diff: cvs diff: Diffing sys/arch/armv7/omap/ Index: sys/arch/armv7/omap//if_cpsw.c === RCS file: /cvs/src/sys/arch/armv7/omap/if_cpsw.c,v retrieving revision 1.21 diff -u -p -u -r1.21 if_cpsw.c ---

cpsw updates

This diff will properly initialize cpsw if uboot hasn't done so already. It also adds support for 1000BaseT (RGMII) PHY found on some boards. Based heavily on a netbsd diff. My BBB is out of comission so please test this and provide feedback. Thanks. diff -r 4d62a2f27093 -r 961793eb2b24

Re: Iso image integrity verification

We've all expressed reasonable doubt. In the US you can be assured that the USPS will open, scan, read, and deliver your mail. So it's reasonable to believe that they may also tamper with your openbsd CD's. Just buy the disks, let this thread die along with the stupidity of PCI-DSS (which I've

Re: Iso image integrity verification

There's literally the same thing on the mirror? http://ftp.openbsd.org/pub/OpenBSD/snapshots/amd64/SHA256 On Wed, Sep 11, 2013 at 1:53 PM, Valentin Zagura put...@gmail.com wrote: I don't think I'm more paranoid than the average considering that Debian has a way to do this

Re: Allegations regarding OpenBSD IPSEC

I about talked myself out of believing that this happened after explaining this to a cow-orker today. They were quite surprised i'd buy into something this speculative and far fetched at all. After listening to him generalize it back to me it seems even sillier. Brandon On Dec 16, 2010 6:34 PM,

Re: Allegations regarding OpenBSD IPSEC

, 2010 at 10:26:44PM -0500, Brandon Mercer wrote: If this type of thing really did happen and this actually is going on something as simple as systrace or dtrace would have found it correct? Surely folks have monitored and audited the actual function and traffic that goes across the wire

Re: Allegations regarding OpenBSD IPSEC

If this type of thing really did happen and this actually is going on something as simple as systrace or dtrace would have found it correct? Surely folks have monitored and audited the actual function and traffic that goes across the wire... conversely amd has a debugger that'll get you access to