From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 CD3F843A7E9 for ; Fri, 21 Aug 2026 08:21:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787300494; cv=none; b=Loa7vl3bGY7v0UKKQTlwxJuse4eAG3iCc+Pgaylv125fphGDrsc7LFmToABRHjSXJkyXMCVxEeWbAJrZr87DT9iLEaL/OXj9nEo9sGqR+Jutiu469SCjt+W6ckAgIk9JX8fCwWSPdFMxGOKK0bP74AEjf0T8JhLnyIqDZeAKZJ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787300494; c=relaxed/simple; bh=s66SPfIYFVXwMi95c5OUG+VHhmfqc+3Zo1ljLfB4nd4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=JqNYfJnynr4BeWwgaen4QsafKGXHSH34sFscTvuA9reFZVN+Zas22+EpjpMaCw0V+3TdrCRkbTi8E6P+eZdVFw5TsQlgYSj409Y2Vc2J3tSpjjFPYmGc4A2KAZAuQ7HE7e209C2Y+tIia9wT6PnU8HuwaONspD20jNDqdbZnpt0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=Y8t2FmBD; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Y8t2FmBD" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1787300488; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=71PdG2FF3occukMcYZtZGT4uA/SoouYhxW+ICbWmfmM=; b=Y8t2FmBDVKR/8V+mV0MI3GH7pRElikvCERlgLZyrh+bsMDkREZ4tLHjpyWz3oq4Dfv8GKU jcBOd8kiZZxs+3JUTIpXn0pFge0FNHR88U7qQpfPEnLeY+Iywum26zL5TjBjPV0r3AWUj3 iJLfkG9SrSIFNxdQ4LZKJstOOL9Loy8= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-655-oRPSpw4GNai4TIoTYnx_Sg-1; Fri, 21 Aug 2026 04:21:24 -0400 X-MC-Unique: oRPSpw4GNai4TIoTYnx_Sg-1 X-Mimecast-MFC-AGG-ID: oRPSpw4GNai4TIoTYnx_Sg_1787300483 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1E7741800148; Fri, 21 Aug 2026 08:21:23 +0000 (UTC) Received: from thuth-p1g4.redhat.com (unknown [10.44.32.129]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E321F7D7; Fri, 21 Aug 2026 08:21:20 +0000 (UTC) From: Thomas Huth To: Daniel Mack , Haojian Zhuang , Robert Jarzmik Cc: linux-kernel@vger.kernel.org Subject: [PATCH] ARM: PXA: Replace __ASSEMBLY__ with __ASSEMBLER__ Date: Fri, 21 Aug 2026 10:21:18 +0200 Message-ID: <20260821082118.177326-1-thuth@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.6 on 10.30.177.95 While the GCC and Clang compilers already define __ASSEMBLER__ auto- matically when compiling assembly code, __ASSEMBLY__ is a macro that only gets defined by the Makefiles in the kernel. This can be very confusing when switching between userspace and kernelspace coding, or when dealing with uapi headers that rather should use __ASSEMBLER__ instead. Let's standardize now on the __ASSEMBLER__ macro to avoid this confusion. Signed-off-by: Thomas Huth --- Note: This has been split from an earlier bigger patch of mine into a separate patch to ease reviewing arch/arm/mach-pxa/irqs.h | 2 +- arch/arm/mach-pxa/pxa-regs.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-pxa/irqs.h b/arch/arm/mach-pxa/irqs.h index 22bf536a462d0..07d7aa3a65065 100644 --- a/arch/arm/mach-pxa/irqs.h +++ b/arch/arm/mach-pxa/irqs.h @@ -94,7 +94,7 @@ #define PXA_NR_IRQS (IRQ_BOARD_START) -#ifndef __ASSEMBLY__ +#ifndef __ASSEMBLER__ struct irq_data; struct pt_regs; diff --git a/arch/arm/mach-pxa/pxa-regs.h b/arch/arm/mach-pxa/pxa-regs.h index ba5120c06b8a5..b56c8899042c4 100644 --- a/arch/arm/mach-pxa/pxa-regs.h +++ b/arch/arm/mach-pxa/pxa-regs.h @@ -31,7 +31,7 @@ #define io_v2p(x) (0x3c000000 + ((x) & 0x01ffffff) + (((x) & 0x0e000000) << 1)) #define io_p2v(x) IOMEM(0xf2000000 + ((x) & 0x01ffffff) + (((x) & 0x1c000000) >> 1)) -#ifndef __ASSEMBLY__ +#ifndef __ASSEMBLER__ # define __REG(x) (*((volatile u32 __iomem *)io_p2v(x))) /* With indexed regs we don't want to feed the index through io_p2v() -- 2.55.0