Re: Merge branch 'floppy'

> Actual working physical floppy hardware is getting hard to find, and > while Willy was able to test this, I think the driver can be considered > pretty much dead from an actual hardware standpoint. Just for the record: I have an Ubuntu machine, still in daily use, that has a floppy disk

Re: I'd like to donate a MacBook Pro

2017-05-11 5:16 GMT-06:00 Mathias Nyman : > Looks like there are a few people suffering from macbook xhci related issues > > From the bugs linked it looks like there are both some UEFI issues and a > non-responsive > usb device at boot. at least one USB device does

Re: I'd like to donate a MacBook Pro

2017-05-11 5:16 GMT-06:00 Mathias Nyman : > Looks like there are a few people suffering from macbook xhci related issues > > From the bugs linked it looks like there are both some UEFI issues and a > non-responsive > usb device at boot. at least one USB device does not respond to a address >

Re: I'd like to donate a MacBook Pro

2017-05-03 8:58 GMT-06:00 Joerg Roedel <jroe...@suse.de>: > On Wed, May 03, 2017 at 08:35:47AM -0600, Alex Henrie wrote: >> 2017-05-03 5:58 GMT-06:00 Greg KH <gre...@linuxfoundation.org>: >> > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: >&

Re: I'd like to donate a MacBook Pro

2017-05-03 8:58 GMT-06:00 Joerg Roedel : > On Wed, May 03, 2017 at 08:35:47AM -0600, Alex Henrie wrote: >> 2017-05-03 5:58 GMT-06:00 Greg KH : >> > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: >> >> Today I ran a regression test to determine which

Re: I'd like to donate a MacBook Pro

2017-05-03 5:58 GMT-06:00 Greg KH <gre...@linuxfoundation.org>: > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: >> Today I ran a regression test to determine which commit made the >> keyboard stop working entirely. The last comm

Re: I'd like to donate a MacBook Pro

2017-05-03 5:58 GMT-06:00 Greg KH : > On Tue, May 02, 2017 at 10:55:09PM -0600, Alex Henrie wrote: >> Today I ran a regression test to determine which commit made the >> keyboard stop working entirely. The last commit that worked for me was >> c09e22d5370739e16463c11352

Re: I'd like to donate a MacBook Pro

2017-05-01 3:03 GMT-06:00 Lukas Wunner <lu...@wunner.de>: > On Mon, 1 May 2017 00:27:41 -0600, Alex Henrie wrote: >> I am confident that this is a common problem because I have found >> various other users complaining about it: >> >> https://bbs.archlinux.org/v

Re: I'd like to donate a MacBook Pro

2017-05-01 3:03 GMT-06:00 Lukas Wunner : > On Mon, 1 May 2017 00:27:41 -0600, Alex Henrie wrote: >> I am confident that this is a common problem because I have found >> various other users complaining about it: >> >> https://bbs.archlinux.org/viewtopic.php?pi

I'd like to donate a MacBook Pro

Dear kernel developers, I have a MacBookPro12,1 A1502 with a very annoying problem. Every time it boots, the screen stays black for about 90 seconds, and the keyboard is unresponsive for an additional 40 seconds. Both the internal keyboard and (if present) external USB keyboard are unresponsive.

I'd like to donate a MacBook Pro

Dear kernel developers, I have a MacBookPro12,1 A1502 with a very annoying problem. Every time it boots, the screen stays black for about 90 seconds, and the keyboard is unresponsive for an additional 40 seconds. Both the internal keyboard and (if present) external USB keyboard are unresponsive.

Re: [PATCH] SubmittingPatches: make Subject examples match the de facto standard

2015-09-24 23:57 GMT+02:00 Jonathan Corbet : > On Sun, 20 Sep 2015 14:11:19 +0200 > Alex Henrie wrote: > >> The examples should better match what kernel developers actually expect, >> so that they set a good example both for this project and for other >> projec

Re: [PATCH] SubmittingPatches: make Subject examples match the de facto standard

2015-09-24 23:57 GMT+02:00 Jonathan Corbet <cor...@lwn.net>: > On Sun, 20 Sep 2015 14:11:19 +0200 > Alex Henrie <alexhenri...@gmail.com> wrote: > >> The examples should better match what kernel developers actually expect, >> so that they set a good example bo

[PATCH] SubmittingPatches: make Subject examples match the de facto standard

The examples should better match what kernel developers actually expect, so that they set a good example both for this project and for other projects with similar development processes. Signed-off-by: Alex Henrie --- Documentation/SubmittingPatches | 8 1 file changed, 4 insertions

[PATCH] SubmittingPatches: make Subject examples match the de facto standard

The examples should better match what kernel developers actually expect, so that they set a good example both for this project and for other projects with similar development processes. Signed-off-by: Alex Henrie <alexhenri...@gmail.com> --- Documentation/SubmittingPatches | 8

ioperm is kept on fork

Hi, Could one of you knowledgeable kernel developers comment on https://bugzilla.kernel.org/show_bug.cgi?id=99911 ? The man pages maintainer wants to know when this behavior changed. -Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

ioperm is kept on fork

Hi, Could one of you knowledgeable kernel developers comment on https://bugzilla.kernel.org/show_bug.cgi?id=99911 ? The man pages maintainer wants to know when this behavior changed. -Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to

Re: [PATCH v2] x86: Preserve iopl on fork and execve

2015-05-12 9:47 GMT-06:00 Austin S Hemmelgarn : > On 2015-05-12 11:25, Arjan van de Ven wrote: >> If you look at a modern linux distro, nothing should need/use iopl and >> co anymore, so maybe an interesting >> question is if we can stick these behind a CONFIG_ option (default on >> of course for

Re: [PATCH v2] x86: Preserve iopl on fork and execve

2015-05-12 9:47 GMT-06:00 Austin S Hemmelgarn ahferro...@gmail.com: On 2015-05-12 11:25, Arjan van de Ven wrote: If you look at a modern linux distro, nothing should need/use iopl and co anymore, so maybe an interesting question is if we can stick these behind a CONFIG_ option (default on of

[PATCH v2] x86: Preserve iopl on fork and execve

Signed-off-by: Alex Henrie Suggested-by: Doug Johnson --- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c index 8ed2106..0ef7078 100644 --- a/arch

Re: ioperm is preserved across fork and execve, but iopl is not

2015-05-11 15:11 GMT-06:00 One Thousand Gnomes : > Is there a real world use case ? Back in 2012 I needed to make a legacy program run that accessed the parallel port directly. Rewriting the program was not an option. So I wrote a helper program that used iopl and execve to grant the necessary

[PATCH] x86: Preserve iopl on fork and execve

Signed-off-by: Alex Henrie Suggested-by: Doug Johnson --- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c index 8ed2106..86bfe7c 100644 --- a/arch

Fwd: ioperm is preserved across fork and execve, but iopl is not

Dear kernel developers, The ioperm and iopl calls are both used to grant a process permission to access I/O devices directly. iopl(3) is equivalent to ioperm(0, 0x, 1). However, permissions granted through ioperm are preserved across fork and execve, and permissions granted through iopl are

Re: ioperm is preserved across fork and execve, but iopl is not

2015-05-11 15:11 GMT-06:00 One Thousand Gnomes gno...@lxorguk.ukuu.org.uk: Is there a real world use case ? Back in 2012 I needed to make a legacy program run that accessed the parallel port directly. Rewriting the program was not an option. So I wrote a helper program that used iopl and execve

[PATCH] x86: Preserve iopl on fork and execve

Signed-off-by: Alex Henrie alexhenri...@gmail.com Suggested-by: Doug Johnson dou...@dougvj.net --- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c

Fwd: ioperm is preserved across fork and execve, but iopl is not

Dear kernel developers, The ioperm and iopl calls are both used to grant a process permission to access I/O devices directly. iopl(3) is equivalent to ioperm(0, 0x, 1). However, permissions granted through ioperm are preserved across fork and execve, and permissions granted through iopl are

[PATCH v2] x86: Preserve iopl on fork and execve

Signed-off-by: Alex Henrie alexhenri...@gmail.com Suggested-by: Doug Johnson dou...@dougvj.net --- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c