linux-kernel - Re: [PATCH 1/2] SOUND: kill gameport bits

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140828211110.GA24519@suse.cz>
Date:	Thu, 28 Aug 2014 23:11:10 +0200
From:	Vojtech Pavlik <vojtech@...e.cz>
To:	Clemens Ladisch <clemens@...isch.de>
Cc:	Takashi Iwai <tiwai@...e.de>, Andreas Mohr <andi@...as.de>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 1/2] SOUND: kill gameport bits

On Thu, Aug 28, 2014 at 10:03:55PM +0200, Clemens Ladisch wrote:
> Takashi Iwai wrote:
> > did anyone test the patch at all...?
> 
> Appears to work.  The ymfpci gameport seems to be somewhat unreliable:
> 
>  analog.c: 100 out of 17347 reads (0%) on pci0000:06:06.1/gameport0 failed
>  analog.c: 122 out of 1111 reads (10%) on pci0000:06:07.0/gameport0 failed

The analog.c gameport read routine is unreliable by design. 

The 558 chip is not an ADC, it's an one-shot timer from 1971. The analog
position of the joystick is measured by timing bit changes on the
gameport.

analog.c does that without disabling interrupts, as the read can take
several milliseconds. analog.c instead detects when an interrupt influenced
the measurement too much and retries.

The retries are counted and reported.

10% is a largeish number, but still something the analog.c driver can
cope with and give reliable results. 

> There is still some dependence of the CPU speed on the loop counts
> calculated by gameport_time(), but it's not very high; the following are
> for 3200 and 800 MHz, 5 times each:
> 
>  gameport gameport7: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 651kHz
>  gameport gameport8: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 651kHz
>  gameport gameport9: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 651kHz
>  gameport gameport10: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 651kHz
>  gameport gameport11: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 651kHz
>  gameport gameport12: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 612kHz
>  gameport gameport13: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 612kHz
>  gameport gameport14: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 612kHz
>  gameport gameport15: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 611kHz
>  gameport gameport16: EMU10K1 is pci0000:06:06.1/gameport0, io 0xe480, speed 612kHz

The gameport speed is speed of the i/o to the port. It may change as
frequencies in the system change. It's used for timeouts on digital
gameport protocols only and thus a variation of less than 20% shouldn't cause
trouble.

The analog.c driver uses its own timing calibration to make the
analog_cooked_read() reliable even when the speed of the i/o operations
changes.

What is important is that the GET_TIME() macro is fast (0.1 usec or
less), precise (sub-microsecond resolution) and reliable. Digital
protocols also rely on udelay() and mdelay() waiting precisely for the
amount of time specified.

-- 
Vojtech Pavlik
Director SuSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/