From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C23354611EE for ; Mon, 20 Jul 2026 18:41:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784572870; cv=none; b=FKquTrDELA8FBKZz4zfMjgz3uQPnpC/oT+VrbDg/K208bTwsxrf3z5pG+/B/KR2BBanmT8oHkAQeueA8VMDP59wY3o3yIg2P3LOwsITMcXfBpTLiOlfRAMEM/eDsLDadrG5rpbZ31Fv2+dtmZXDwMyUqjtcFp3bWYetYko29lMs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784572870; c=relaxed/simple; bh=ww07pT7x2iuDIyjw9QarArYwTDyUVCN0l6Rmvw/2LZM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=jydHpPRx0/pSuzbeOkMBzJZ9dja3/+44D6kNla5bIrnoV3fum44meFj2AH/7R7Y05XCm+hUwqz1BBp/sP1XTTkmLFzxRD5TWQSyi5ee1VAzoIGCgSXG2mFeu/Q+qvA5MvZdg/7wNumsNxSznIaUEqrqYKDNNVRzry29iiInBYQk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KZu01hHh; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KZu01hHh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5A9B1F000E9; Mon, 20 Jul 2026 18:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784572868; bh=ww07pT7x2iuDIyjw9QarArYwTDyUVCN0l6Rmvw/2LZM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=KZu01hHhPiFVT8AYTVFGMBd7JOZ3d1kscOyOXjiCYFYJ2EW61h8ZFzVwKVNaJIzlz DekjDhbRENp0FCA6tSMdC2tLNdKKGQEp6grFEmqqCqJJHXAJuMSfsLjJ+kblSQ6JMI wdVJwmZKlC5Ao80t9JBXY8mISvIkHKwy4ShcAItH7U+EPGyZayfsfmagfTNxQSL2BL Rf69yJ3N0S/TcEIR2h7z9zpgIfWW2H2sD5JyuzZqDmynMZ0lKLuU0d3V/U8bo2yjdx sNIiRxlPHtBkca+gn32dtTB656q89Ikj8eknGfgPdWFIEgZGHJ7z4ygqjhK8xdnABX TA206xkKwX5tg== From: Thomas Gleixner To: Melody Wang , x86@kernel.org Cc: LKML , Melody Wang Subject: Re: [PATCH] x86/apic: Ensure ICR register write value is handled as 32 bits In-Reply-To: <20260708012117.177959-1-huibo.wang@amd.com> References: <20260708012117.177959-1-huibo.wang@amd.com> Date: Mon, 20 Jul 2026 20:41:05 +0200 Message-ID: <877bmpmrlq.ffs@fw13> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Wed, Jul 08 2026 at 01:21, Melody Wang wrote: > The low 32-bit ICR data is prepared by __prepare_ICR(), which returns > a 32-bit value. However, when this value is assigned to a new variable, > it's easy to mistakenly declare that variable with a different width. > > To avoid this class of mistakes, use __prepare_ICR() directly as the > function argument instead of storing its result in an intermediate > variable. This also shaves off a bunch of lines in the code. > > There should be no functionality change resulting from this patch. > > Signed-off-by: Melody Wang Acked-by: Thomas Gleixner