All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] arm64: add helper functions to read I-cache attributes
Date: Wed, 6 Aug 2014 15:34:30 +0100	[thread overview]
Message-ID: <20140806143430.GU25953@arm.com> (raw)
In-Reply-To: <CAKv+Gu-iGZMLgWHEPoc1w8HW3gUyuJXb6uerXg_kGQOhbqySSg@mail.gmail.com>

On Wed, Aug 06, 2014 at 02:27:55PM +0100, Ard Biesheuvel wrote:
> On 6 August 2014 15:17, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > On 6 August 2014 15:00, Will Deacon <will.deacon@arm.com> wrote:
> >> On Tue, Aug 05, 2014 at 10:25:56AM +0100, Ard Biesheuvel wrote:
> >>> This adds helper functions and #defines to <asm/cachetype.h> to read the
> >>> line size and the number of sets from the level 1 instruction cache.
> >>>
> >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> >>> ---

[...]

> >>> +static inline __attribute_const__ u64 icache_get_ccsidr(void)
> >>> +{
> >>> +     u64 ccsidr;
> >>> +
> >>> +     /* Select L1 I-cache and read its size ID register */
> >>> +     asm("msr csselr_el1, %1; isb; mrs %0, ccsidr_el1"
> >>> +         : "=r"(ccsidr) : "r"(1L));
> >>> +     return ccsidr;
> >>
> >> Is it worth having a WARN_ON(preemptible()) here?
> >>
> >
> > Sure, why not.
> 
> ... if it weren't for the fact that this triggers recursive header
> inclusion hell
> 
>   CC      kernel/bounds.s
> In file included from /home/ard/linux-2.6/include/asm-generic/preempt.h:4:0,
>                  from arch/arm64/include/generated/asm/preempt.h:1,
>                  from /home/ard/linux-2.6/include/linux/preempt.h:18,
>                  from /home/ard/linux-2.6/arch/arm64/include/asm/cachetype.h:21,

[...]

> i.e., linux/bug,h and linux/preempt.h already implicitly #include
> cachetype.h, so including the former from the latter to import the
> declaration of WARN_ON() and/or preemptible respectively produces this
> error.

Damn, that's a real shame. I'm always dubious about adding code like this
which isn't obviously broken from preemptible context when you're just
looking at the function name.

Ho-hum.

Will

  reply	other threads:[~2014-08-06 14:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-05  9:25 [PATCH v2 1/3] arm64: fix typo in I-cache policy detection Ard Biesheuvel
2014-08-05  9:25 ` [PATCH v2 2/3] arm64: add helper functions to read I-cache attributes Ard Biesheuvel
2014-08-06 13:00   ` Will Deacon
2014-08-06 13:17     ` Ard Biesheuvel
2014-08-06 13:27       ` Ard Biesheuvel
2014-08-06 14:34         ` Will Deacon [this message]
2014-08-06 14:38           ` Ard Biesheuvel
2014-08-05  9:25 ` [PATCH v2 3/3] arm64: don't flag non-aliasing VIPT I-caches as aliasing Ard Biesheuvel
2014-08-06 12:43 ` [PATCH v2 1/3] arm64: fix typo in I-cache policy detection Will Deacon

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=20140806143430.GU25953@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.