linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: gregkh@linuxfoundation.org
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com
Subject: [GIT PULL] Couple more arm64 fixes for 4.19
Date: Fri, 12 Oct 2018 16:46:29 +0100	[thread overview]
Message-ID: <20181012154629.GB11387@arm.com> (raw)

Hi Greg,

Please pull these two arm64 fixes for 4.19. One of them fixes a nasty
WARN() that has started triggering because we assumed that memory
reservations from firmware would always correspond to regions of the
physical address space that we have mapped as memory. Unfortunately,
some existing device-tree files break this assumption and we need to
continue supporting them. The other fix addresses an issue where a
CHAIN PMU event can be requested as a 32-bit counter via perf, which
makes no sense in isolation since these events are intended to be used
in conjunction with another event when creating a 64-bit counter.

This is summarised in the tag.

Cheers,

Will

--->8

The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21:

  Linux 4.19-rc7 (2018-10-07 17:26:02 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes

for you to fetch changes up to ca2b497253ad01c80061a1f3ee9eb91b5d54a849:

  arm64: perf: Reject stand-alone CHAIN events for PMUv3 (2018-10-12 15:25:17 +0100)

----------------------------------------------------------------
More arm64 fixes

- Reject CHAIN PMU events when they are not part of a 64-bit counter

- Fix WARN_ON_ONCE() that triggers for reserved regions that don't
  correspond to mapped memory

----------------------------------------------------------------
Will Deacon (2):
      arm64: Fix /proc/iomem for reserved but not memory regions
      arm64: perf: Reject stand-alone CHAIN events for PMUv3

 arch/arm64/kernel/perf_event.c |  7 ++++++
 arch/arm64/kernel/setup.c      | 56 ++++++++++++++++++++----------------------
 drivers/perf/arm_pmu.c         |  8 +++++-
 include/linux/perf/arm_pmu.h   |  1 +
 4 files changed, 42 insertions(+), 30 deletions(-)

             reply	other threads:[~2018-10-12 15:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-12 15:46 Will Deacon [this message]
2018-10-13  7:28 ` [GIT PULL] Couple more arm64 fixes for 4.19 Greg KH

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=20181012154629.GB11387@arm.com \
    --to=will.deacon@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).