Received: by 2002:ab2:69cc:0:b0:1fd:c486:4f03 with SMTP id n12csp379046lqp; Tue, 11 Jun 2024 07:15:42 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVl2HyirzXg8p2esr+2MXPB5vf5VTvM2d/n/13r77B7Ajb4m1WFLP5rMhezS+68ZsrJlrNQKIB9mcqjm98ehxQYGFJmiiNVDOn72T00gw== X-Google-Smtp-Source: AGHT+IGjYp5n5perR9VPZsXGW+Alwgk8uGE1nWfUluJVH+glZDwKHfkldu05MZ+2tZNuwDN6PurK X-Received: by 2002:a17:902:ce91:b0:1f4:b9d3:adce with SMTP id d9443c01a7336-1f6d02dd8cbmr176145535ad.27.1718115341791; Tue, 11 Jun 2024 07:15:41 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1718115341; cv=pass; d=google.com; s=arc-20160816; b=MEnj0TPNEqtnS/PN1dSjauGHUdSNCu5rpXY5tbFfPF02Q603k6xPJH7ttxCcBnkqVq lgWhblRf2yapIr6ih2Q2s7OPVMbcXYvaR+T+5AWfCMThXv3SfffsBNiu0r0M9L5GUO5M sa0rIJbBRMlZZVFyMcWcE9c1+PICe1QeheK51d5U3krbjXH78GvPmxEpO0FJAMKWGRwT /66suDAl07EpLf10fKNV3XB3jjbZYpAWU0x8LomsFeURWDIfeLQtKjxwNrvcXXiZAaom MRdFNE/oqDisrlZ2ZWYrkfp8Vymz2ML1WJBwQj34cT096rW0RcafMphXuVHT9GU25+I9 jh2Q== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date; bh=cay/DBQ6wGdUVHeI2q0vcMVeZ4NGQFiHDc4yVtEBTjo=; fh=8UW5faKTjmGrMxJWe3bOjmvoFU4rm9aYNVHJ1l/BBGk=; b=PQPwNmYZbgdaxXzIspm2PRHy4osQPMUp2aGloI2ehNtO+bVG/6f/sUTgK2tAn17Pag 7OO1vSx4594xEUewS1d3J2ySLFv1borSLOExDl/zZDWH5WO1uG78DyEXo6YrYLVnwy30 rqItVQAF4NFbjvGmFwFRkeOQGxZEHNK1wKvG6T80PIABNhdvymW2l22h1SQU1d6GIigZ BDJxsMdvbYp5vmAWT+8SfIfUgXzfb3b33bq/KSWfJVBkmap/uOwZpJHEVVRmVnbRaGab KvRuWU7Zzgf2C6yZbi+DKO+wQkKM6IeS5vGAnVovp0TuGkM/4KtQwk8/QDLytZKF7peS vV6A==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=alpha.franken.de); spf=pass (google.com: domain of linux-kernel+bounces-210049-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-210049-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id d9443c01a7336-1f70b24c51csi41130835ad.264.2024.06.11.07.15.41 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Jun 2024 07:15:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-210049-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=alpha.franken.de); spf=pass (google.com: domain of linux-kernel+bounces-210049-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-210049-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 1864628B2BD for ; Tue, 11 Jun 2024 14:15:41 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5857517D8BF; Tue, 11 Jun 2024 14:15:14 +0000 (UTC) Received: from elvis.franken.de (elvis.franken.de [193.175.24.41]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0A95017D36F; Tue, 11 Jun 2024 14:15:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.175.24.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718115313; cv=none; b=ciDBoDep2vmGImz1DlCVQExSakv2Pwb1eoW5jvr8m/qeR9fCYHzV5aaw9ss4I0MMqoiOIu3dmT90WJES1OLLcy4yDJCk3u+xNh93nOQz8ieu7rLPOQsxibNSguSzz90rP1P5+0OeskH6c5jxXKa5MSu2Olv9cp3DXHotzovUBbY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718115313; c=relaxed/simple; bh=HAOmF6rdj6a4UzhcOHHBQoRqQ0wQFaxoA/VjGAh8ocU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rX3NbwSEiXuDQjNgx0Kkd69yH0m64qdaXUxuK1gQDceXsT1t+a6vzfiOAvbKZllCVrJKWB/oY5hp+IiFVa/tA0pPGv2XGzUT8FpdHAo0jepGLKSGKCN7rcBUVHQrXPFb+nCXvPV1gki60WfttuMJNX0Jv0FyjbtFo5Ef8Su+PzI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=alpha.franken.de; spf=pass smtp.mailfrom=alpha.franken.de; arc=none smtp.client-ip=193.175.24.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=alpha.franken.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alpha.franken.de Received: from uucp by elvis.franken.de with local-rmail (Exim 3.36 #1) id 1sH2Gu-00034K-00; Tue, 11 Jun 2024 16:14:48 +0200 Received: by alpha.franken.de (Postfix, from userid 1000) id BE0F4C0688; Tue, 11 Jun 2024 16:14:35 +0200 (CEST) Date: Tue, 11 Jun 2024 16:14:35 +0200 From: Thomas Bogendoerfer To: Ilpo =?iso-8859-1?Q?J=E4rvinen?= Cc: Florian Fainelli , Ralf Baechle , Phil Sutter , linux-mips@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] MIPS: Routerboard 532: Fix vendor retry check code Message-ID: References: <20240508120700.51374-1-ilpo.jarvinen@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240508120700.51374-1-ilpo.jarvinen@linux.intel.com> On Wed, May 08, 2024 at 03:07:00PM +0300, Ilpo J?rvinen wrote: > read_config_dword() contains strange condition checking ret for a > number of values. The ret variable, however, is always zero because > config_access() never returns anything else. Thus, the retry is always > taken until number of tries is exceeded. > > The code looks like it wants to check *val instead of ret to see if the > read gave an error response. > > Fixes: 73b4390fb234 ("[MIPS] Routerboard 532: Support for base system") > Signed-off-by: Ilpo J?rvinen > -- > > IMPORTANT NOTE TO MAINTAINER: > > This change has potential of breaking something and I don't have HW to > test this with. I only came across it while going through all PCIBIOS_* > call chains. Clearly the current code non-sensical so something is not > right but whether this is the right way to solve the problem, I'm not > entirely sure because it will make small change into the behavior. I have rework of this code sitting in one of my development branches and I didn't spot the bug in the old code, but the new code does what your fix is doing. So I'm pretty sure this change is correct. > --- > arch/mips/pci/ops-rc32434.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied to mips-fixes. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]