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]

Message-ID: <CADnq5_PUcDVL+RPZPDGiAxHjn=vL7dnNsiQYG2F5e6GWnoX7Kg@mail.gmail.com>
Date:	Thu, 29 Sep 2011 10:36:41 -0400
From:	Alex Deucher <alexdeucher@...il.com>
To:	Brad Campbell <brad@...rfbargle.com>
Cc:	airlied@...hat.com, dri-devel@...ts.freedesktop.org,
	linux-kernel@...r.kernel.org
Subject: Re: Radeon regression fix

On Thu, Sep 29, 2011 at 10:21 AM, Brad Campbell <brad@...rfbargle.com> wrote:
> This patch fixes a regression introduced between 2.6.39 & 3.1-rc1 whereby
> the displayport AUX channel stopped re-trying commands that elicited a DEFER
> response.
>

It should still be retrying, just restructured slightly.  The retry
logic just moved into radeon_dp_i2c_aux_ch(),
radeon_dp_aux_native_write(), and radeon_dp_aux_native_read(), e.g.,

		else if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_DEFER)
			udelay(400);

Perhaps the delay is causing a problem.  Does removing the udelay(400); help?

Alex

> Signed-off-by: Brad Campbell <brad@...rfbargle.com>
>
> diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
> b/drivers/gpu/drm/radeon/atombios_dp.c
> index 7ad43c6..b8450f4 100644
> --- a/drivers/gpu/drm/radeon/atombios_dp.c
> +++ b/drivers/gpu/drm/radeon/atombios_dp.c
> @@ -60,11 +60,13 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan
> *chan,
>        int index = GetIndexIntoMasterTable(COMMAND,
> ProcessAuxChannelTransaction);
>        unsigned char *base;
>        int recv_bytes;
> +       int retry_count = 0;
>
>        memset(&args, 0, sizeof(args));
>
>        base = (unsigned char *)rdev->mode_info.atom_context->scratch;
>
> +retry:
>        memcpy(base, send, send_bytes);
>
>        args.v1.lpAuxRequest = 0;
> @@ -79,6 +81,16 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan
> *chan,
>
>        *ack = args.v1.ucReplyStatus;
>
> +       /* defer */
> +       if (args.v1.ucReplyStatus == 0x20){
> +               DRM_DEBUG_KMS("dp_aux_ch defer\n");
> +                       /* 10 is an arbitrary value from the pre-regression
> patch
> +                       in practice I've never seen more than one */
> +                       if (retry_count++ < 10)
> +                               goto retry;
> +               return -EBUSY;
> +       }
> +
>        /* timeout */
>        if (args.v1.ucReplyStatus == 1) {
>                DRM_DEBUG_KMS("dp_aux_ch timeout\n");
>
--
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/