From: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
To: u-boot@lists.denx.de
Subject: [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros
Date: Wed, 15 Apr 2020 06:48:27 +0200 [thread overview]
Message-ID: <1a84206c-ee30-e540-8636-9b8d239a406c@gmail.com> (raw)
In-Reply-To: <20200414210446.GI27851@bill-the-cat>
Am 14.04.2020 um 23:04 schrieb Tom Rini:
> On Tue, Apr 14, 2020 at 10:38:47PM +0200, Simon Goldschmidt wrote:
>> Masahiro Yamada <masahiroy@kernel.org> schrieb am Di., 14. Apr. 2020, 17:34:
>>
>>> Hi Simon,
>>>
>>> On Tue, Apr 14, 2020 at 11:41 PM Simon Glass <sjg@chromium.org> wrote:
>>>>
>>>> Hi Masahiro,
>>>>
>>>> On Mon, 13 Apr 2020 at 11:10, Masahiro Yamada <masahiroy@kernel.org>
>>> wrote:
>>>>>
>>>>> On Fri, Apr 10, 2020 at 5:18 AM Simon Glass <sjg@chromium.org> wrote:
>>>>>>
>>>>>> Some places use __ASSEMBLER__ instead which does not work since the
>>>>>> Makefile does not define it. Fix them.
>>>>>
>>>>>
>>>>> In my understanding,
>>>>> __ASSEMBLER__ is passed by the compiler
>>>>> while building *.S files.
>>>>>
>>>>> On which compiler didn't this work for you?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Signed-off-by: Simon Glass <sjg@chromium.org>
>>>>>> ---
>>>>>>
>>>>>> Changes in v2:
>>>>>> - Add new patch to fix occurances of __ASSEMBLER__
>>>>>>
>>>>
>>>> I think I hit this with device tree, but I would need to go back and
>>>> check. Anyway I think we should be consistent.
>>>
>>>
>>> DT files are pre-processed with '-x assembler-with-cpp'.
>>>
>>> So, __ASSEMBLER__ is pre-defined by the compiler.
>>>
>>
>> I have just seen this thread now. It touches socfpga headers but we're not
>> in CC (possibly the maintainers file needs updating).
>>
>> Anyway, why do we have 2 defines for assembler? If one is predefined by the
>> compiler, why don't we use that? Can you explain that for someone not too
>> deeply involved?
>
> Generally and broadly speaking, the assembler will set __ASSEMBLER__.
> That said, the Linux kernel has been setting __ASSEMBLY__ for
> practically forever and we've copied that behavior also practically for
> forever. In both trees there are a handful of __ASSEMBLER__ tests and a
> vast majority of __ASSEMBLY__ tests. It doesn't normally matter which
> is used as the only non-compiler in the Linux kernel that might care is
> handled as shown above. Under the assumption that the feature
> Yamada-san pointed out in binman is used, it should also define
> __ASSEMBLER__ I believe, to match other tooling. Thanks!
Ok, thanks for the explanation.
Regards,
Simon
next prev parent reply other threads:[~2020-04-15 4:48 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-09 20:14 [PATCH v2 00/22] common: Further reduce the size of common.h Simon Glass
2020-04-09 20:14 ` [PATCH v2 01/22] common: Drop uuid.h from common header Simon Glass
2020-04-09 20:14 ` [PATCH v2 02/22] flash: Tidy up coding style for flash functions Simon Glass
2020-04-09 20:14 ` [PATCH v2 03/22] common: Drop flash.h from common header Simon Glass
2020-04-09 20:14 ` [PATCH v2 04/22] arm: Don't include common.h in header files Simon Glass
2020-04-09 20:14 ` [PATCH v2 05/22] common: Drop net.h from common header Simon Glass
2020-04-09 20:14 ` [PATCH v2 06/22] part: Drop disk_partition_t typedef Simon Glass
2020-04-09 20:14 ` [PATCH v2 07/22] common: Drop part.h from common header Simon Glass
2020-04-09 20:14 ` [PATCH v2 08/22] bootstage: Use BOOTSTAGE instead of BOOTSTATE Simon Glass
2020-04-09 20:14 ` [PATCH v2 09/22] common: Drop bootstage.h from common header Simon Glass
2020-04-09 20:14 ` [PATCH v2 10/22] common: Drop image.h " Simon Glass
2020-04-09 20:14 ` [PATCH v2 11/22] common: Drop init.h " Simon Glass
2020-04-09 20:14 ` [PATCH v2 12/22] command: Remove the cmd_tbl_t typedef Simon Glass
2020-04-09 20:14 ` [PATCH v2 13/22] Fix some checkpatch warnings in calls to debug() Simon Glass
2020-04-09 20:14 ` [PATCH v2 14/22] common: Drop log.h from common header Simon Glass
2020-04-09 20:14 ` [PATCH v2 15/22] common: Drop asm/ptrace.h " Simon Glass
2020-04-09 20:15 ` [PATCH v2 16/22] common: Drop asm_offsets.h " Simon Glass
2020-04-09 20:15 ` [PATCH v2 17/22] common: Drop linux/bug.h " Simon Glass
2020-04-09 20:15 ` [PATCH v2 18/22] common: Drop linux/stringify.h " Simon Glass
2020-04-09 20:15 ` [PATCH v2 19/22] Fix some checkpatch warnings in calls to udelay() Simon Glass
2020-04-09 20:15 ` [PATCH v2 20/22] common: Drop linux/delay.h from common header Simon Glass
2020-04-09 20:15 ` [PATCH v2 21/22] Use __ASSEMBLY__ as the assembly macros Simon Glass
2020-04-13 17:09 ` Masahiro Yamada
2020-04-14 14:41 ` Simon Glass
2020-04-14 15:33 ` Masahiro Yamada
2020-04-14 20:38 ` Simon Goldschmidt
2020-04-14 21:04 ` Tom Rini
2020-04-15 4:48 ` Simon Goldschmidt [this message]
2020-04-09 20:15 ` [PATCH v2 22/22] common: Drop linux/bitops.h from common header Simon Glass
2020-05-08 18:36 ` [PATCH v2 00/22] common: Further reduce the size of common.h Tom Rini
2020-05-10 15:07 ` Simon Glass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1a84206c-ee30-e540-8636-9b8d239a406c@gmail.com \
--to=simon.k.r.goldschmidt@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox