linux-kernel - Re: Radeon regression fix

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]

Date:	Fri, 30 Sep 2011 13:14:56 +0800
From:	Brad Campbell <lists2009@...rfbargle.com>
To:	Alex Deucher <alexdeucher@...il.com>
CC:	airlied@...hat.com, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: Radeon regression fix

On 30/09/11 12:59, Alex Deucher wrote:
> On Thu, Sep 29, 2011 at 8:23 PM, Brad Campbell

>> Looking at it with a nights sleep, it's obvious the code path in
>> aux_native_write is ok. Is this a bit cleaner than the last patch?
>
> Looks pretty good.  I was thinking of something more like this (sorry
> for the lack of a patch, I'm away from my source trees at the moment):
>
> 	while (1) {
> 		ret = radeon_process_aux_ch(dig_connector->dp_i2c_bus,
> 					    msg, msg_bytes, recv, recv_bytes, delay,&ack);
>
> 		if (ret<  0)
> 			return ret;
> 		if ((ack&  AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_ACK)
> 			return ret;
> 		else if ((ack&  AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_DEFER)
> 			udelay(400);
> 		else if (ret == 0)
> 			return -EPROTO;
> 		else
> 			return -EIO;
> 	}

Yep, that looks cleaner.

My only thought was the pre-3.0 code had a limit to the number of 
retries. Was that for a specific reason or is it ok to attempt to retry 
indefinitely if we receive a DEFER ?

>
> Thanks for tracking this down.

No worries. I learned quite a bit about some kernel internals and more 
than a few quirks about apple hardware while muddling around.
--
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/