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  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 24 Aug 2014 07:07:16 +0200
From:	Andreas Mohr <andi@...as.de>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Andreas Mohr <andi@...as.de>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org, Vojtech Pavlik <vojtech@...e.cz>,
	Jiri Kosina <jkosina@...e.cz>
Subject: Re: [PATCH 1/2] SOUND: kill gameport bits

On Thu, Aug 21, 2014 at 01:29:03PM +0200, Takashi Iwai wrote:
> I did a quick hack and it seems working on my box.
> The patch is below.

Thanks!!

Further comments below.

I will be testing this ASAP.
> +static bool use_ktime = true;
> +module_param(use_ktime, bool, 0400);

Towards final commit, should probably add param docs on what may be switched here and why.

> +
>  /*
>   * gameport_mutex protects entire gameport subsystem and is taken
>   * every time gameport port or driver registrered or unregistered.
> @@ -76,6 +80,36 @@ static unsigned int get_time_pit(void)
>  
>  static int gameport_measure_speed(struct gameport *gameport)
>  {
> +	unsigned int i, t, tx;
> +	u64 t1, t2;
> +	unsigned long flags;
> +
> +	if (gameport_open(gameport, NULL, GAMEPORT_MODE_RAW))
> +		return 0;
> +
> +	tx = ~0;
> +
> +	for (i = 0; i < 50; i++) {
> +		local_irq_save(flags);
> +		t1 = ktime_get_ns();
> +		for (t = 0; t < 50; t++)
> +			gameport_read(gameport);
> +		t2 = ktime_get_ns();
> +		local_irq_restore(flags);
> +		udelay(i * 10);
> +		if (t2 - t1 < tx)
> +			tx = t2 - t1;

This impl is not doing the more complex t3, t2, t1 calculation
that the PIT impl is doing (likely for the uncommented purpose
of eliminating timer I/O delay from timing consideration).
Do/don't ktime/TSC impls better need such an I/O timing correction,
or are they so fast relative to gameport I/O delays
that it does not matter? (probably the case for TSC at least).


Oh, and any reason that such a speed calculation remains painfully duplicated
in both source files? That's possibly done for layering reasons,
but I'd have to analyze it further.

> +static inline u64 get_time(void)
> +{
> +	if (use_ktime) {
> +		return ktime_get_ns();
> +	} else {
> +		unsigned int x;
> +		GET_TIME(x);
> +		return x;
> +	}
> +}

It might be useful to have a first commit to introduce these helpers,
and a second commit to then add ktime support (to keep review code size
down).

Thanks,

Andreas Mohr

-- 
GNU/Linux. It's not the software that's free, it's you.
--
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/

Powered by blists - more mailing lists