* Re: [PATCH tip/core/rcu 0/2] Torture-test changes for 4.10
From: Josh Triplett @ 2016-11-14 18:14 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
mathieu.desnoyers, tglx, peterz, rostedt, dhowells, edumazet,
dvhart, fweisbec, oleg, bobby.prani
In-Reply-To: <20161114175924.GA23488@linux.vnet.ibm.com>
On Mon, Nov 14, 2016 at 09:59:24AM -0800, Paul E. McKenney wrote:
> Hello!
>
> This series contains a couple of torture-test changes:
>
> 1. Remove obsolete files from the rcutorture .gitignore file.
>
> 2. Prevent the --jitter flag from delaying --build-only runs.
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
^ permalink raw reply
* Re: Long delays creating a netns after deleting one (possibly RCU related)
From: Paul E. McKenney @ 2016-11-14 18:14 UTC (permalink / raw)
To: Cong Wang
Cc: Rolf Neugebauer, LKML, Linux Kernel Network Developers,
Justin Cormack, Ian Campbell
In-Reply-To: <CAM_iQpXL+JaVG86+h2ucYs4Dm0zJKHq+4Nm+gk75wESGOzTmJQ@mail.gmail.com>
On Mon, Nov 14, 2016 at 09:44:35AM -0800, Cong Wang wrote:
> On Mon, Nov 14, 2016 at 8:24 AM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > On Sun, Nov 13, 2016 at 10:47:01PM -0800, Cong Wang wrote:
> >> On Fri, Nov 11, 2016 at 4:55 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >> > On Fri, Nov 11, 2016 at 4:23 PM, Paul E. McKenney
> >> > <paulmck@linux.vnet.ibm.com> wrote:
> >> >>
> >> >> Ah! This net_mutex is different than RTNL. Should synchronize_net() be
> >> >> modified to check for net_mutex being held in addition to the current
> >> >> checks for RTNL being held?
> >> >>
> >> >
> >> > Good point!
> >> >
> >> > Like commit be3fc413da9eb17cce0991f214ab0, checking
> >> > for net_mutex for this case seems to be an optimization, I assume
> >> > synchronize_rcu_expedited() and synchronize_rcu() have the same
> >> > behavior...
> >>
> >> Thinking a bit more, I think commit be3fc413da9eb17cce0991f
> >> gets wrong on rtnl_is_locked(), the lock could be locked by other
> >> process not by the current one, therefore it should be
> >> lockdep_rtnl_is_held() which, however, is defined only when LOCKDEP
> >> is enabled... Sigh.
> >>
> >> I don't see any better way than letting callers decide if they want the
> >> expedited version or not, but this requires changes of all callers of
> >> synchronize_net(). Hm.
> >
> > I must confess that I don't understand how it would help to use an
> > expedited grace period when some other process is holding RTNL.
> > In contrast, I do well understand how it helps when the current process
> > is holding RTNL.
>
> Yeah, this is exactly my point. And same for ASSERT_RTNL() which checks
> rtnl_is_locked(), clearly we need to assert "it is held by the current process"
> rather than "it is locked by whatever process".
>
> But given *_is_held() is always defined by LOCKDEP, so we probably need
> mutex to provide such a helper directly, mutex->owner is not always defined
> either. :-/
There is always the option of making acquisition and release set a per-task
variable that can be tested. (Where did I put that asbestos suit, anyway?)
Thanx, Paul
^ permalink raw reply
* Re: [PATCH] dt-bindings: Add Keith&Koep vendor prefix
From: Marek Vasut @ 2016-11-14 18:14 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA; +Cc: Rob Herring, Fabio Estevam, Shawn Guo
In-Reply-To: <20161114101217.3580-1-marex-ynQEQJNshbs@public.gmane.org>
On 11/14/2016 11:12 AM, Marek Vasut wrote:
> Add vendor prefix for Keith&Koep GmbH , http://keith-koep.com/en/
>
> Signed-off-by: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
> Cc: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Fabio Estevam <fabio.estevam-3arQi8VN3Tc@public.gmane.org>
> Cc: Shawn Guo <shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Please ignore, I see the patch was applied and the rebase didn't drop
it. Sorry for the noise.
--
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [GIT PULL] Samsung SoC driver updates for 4.10
From: Sylwester Nawrocki @ 2016-11-14 18:14 UTC (permalink / raw)
To: LMML
In-Reply-To: <CGME20161114181500eucas1p2f4bc902fe54c96803440410b6325d237@eucas1p2.samsung.com>
Hi Mauro,
This includes mostly clean up and fixes of the s5p-mfc and exynos-gsc
drivers. Support for the Exynos5433 (64-bit ARM) SoC is added to the
exynos-gsc driver.
The following changes since commit 669c6141ea78dff885b5bf025456c7dffb669a61:
[media] mtk-mdp: fix double mutex_unlock (2016-10-21 12:09:53 -0200)
are available in the git repository at:
git://linuxtv.org/snawrocki/samsung.git for-v4.10/media/next
for you to fetch changes up to 37269235bfaab6ad0b801190dc8a8c7397476b5b:
s5p-mfc: Fix clock management in s5p_mfc_release() function (2016-11-14 16:04:15 +0100)
----------------------------------------------------------------
Andrzej Hajda (1):
s5p-mfc: Correct scratch buffer size of H.263 decoder
Donghwa Lee (1):
s5p-mfc: Skip incomplete frame
Ingi Kim (1):
s5p-mfc: Fix MFC context buffer size
Javier Martinez Canillas (7):
exynos-gsc: change spamming try_fmt log message to debug
exynos-gsc: don't clear format when freeing buffers with REQBUFS(0)
exynos-gsc: fix supported RGB pixel format
exynos-gsc: do proper bytesperline and sizeimage calculation
exynos-gsc: don't release a non-dynamically allocated video_device
exynos-gsc: unregister video device node on driver removal
exynos-gsc: cleanup m2m src and dst vb2 queues on STREAMOFF
Marek Szyprowski (8):
exynos-gsc: Simplify system PM even more
exynos-gsc: Remove unused lclk_freqency entry
exynos-gsc: Add missing newline char in debug messages
exynos-gsc: Use of_device_get_match_data() helper
exynos-gsc: Enable driver on ARCH_EXYNOS
exynos-gsc: Add support for Exynos5433 specific version
s5p-mfc: Use clock gating only on MFC v5 hardware
s5p-mfc: Fix clock management in s5p_mfc_release() function
Nicolas Dufresne (1):
exynos4-is: fimc: Roundup imagesize to row size for tiled formats
Shuah Khan (2):
s5p-mfc: Collapse two error message into one
s5p-mfc: include buffer size in error message
Ulf Hansson (7):
exynos-gsc: Simplify clock management
exynos-gsc: Convert gsc_m2m_resume() from int to void
exynos-gsc: Make driver functional when CONFIG_PM is unset
exynos-gsc: Make PM callbacks available conditionally
exynos-gsc: Fixup clock management at ->remove()
exynos-gsc: Do full clock gating at runtime PM suspend
exynos-gsc: Simplify system PM
.../bindings/media/exynos5-gsc.txt | 3 +-
drivers/media/platform/Kconfig | 2 +-
.../media/platform/exynos-gsc/gsc-core.c | 279 +++++++--------
.../media/platform/exynos-gsc/gsc-core.h | 11 +-
.../media/platform/exynos-gsc/gsc-m2m.c | 38 +-
.../platform/exynos4-is/fimc-core.c | 13 +-
.../media/platform/s5p-mfc/regs-mfc-v6.h | 3 +-
.../media/platform/s5p-mfc/regs-mfc-v8.h | 2 +-
.../media/platform/s5p-mfc/regs-mfc.h | 3 +
drivers/media/platform/s5p-mfc/s5p_mfc.c | 15 +-
.../platform/s5p-mfc/s5p_mfc_common.h | 2 +
.../media/platform/s5p-mfc/s5p_mfc_opr.c | 6 +-
.../media/platform/s5p-mfc/s5p_mfc_pm.c | 17 +-
13 files changed, 209 insertions(+), 185 deletions(-)
--
Thanks,
Sylwester
^ permalink raw reply
* Re: [PATCH v2] i2c: mux: fix up dependencies
From: Peter Rosin @ 2016-11-14 14:39 UTC (permalink / raw)
To: Linus Walleij, Wolfram Sang, linux-i2c; +Cc: stable, Jonathan Cameron
In-Reply-To: <1479134057-30653-1-git-send-email-linus.walleij@linaro.org>
On 2016-11-14 15:34, Linus Walleij wrote:
> We get the following build error from UM Linux after adding
> an entry to drivers/iio/gyro/Kconfig that issues "select I2C_MUX":
>
> ERROR: "devm_ioremap_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
> ERROR: "of_address_to_resource"
> [drivers/i2c/muxes/i2c-mux-reg.ko] undefined!
>
> It appears that the I2C mux core code depends on HAS_IOMEM
> for historical reasons, while CONFIG_I2C_MUX_REG does *not*
> have a direct dependency on HAS_IOMEM.
>
> This creates a situation where a allyesconfig or allmodconfig
> for UM Linux will select I2C_MUX, and will implicitly enable
> I2C_MUX_REG as well, and the compilation will fail for the
> register driver.
>
> Fix this up by making I2C_MUX_REG depend on HAS_IOMEM and
> removing the dependency from I2C_MUX.
>
> Cc: stable@vger.kernel.org
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Reported-by: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
> Cc: Peter Rosin <peda@axentia.se>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Peter Rosin <peda@axentia.se>
Thanks!
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback
From: Doug Anderson @ 2016-11-14 18:15 UTC (permalink / raw)
To: William Wu
Cc: Kishon Vijay Abraham I, Heiko Stübner,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
open list:ARM/Rockchip SoC...,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Frank Wang, 黄涛, Brian Norris, Guenter Roeck
In-Reply-To: <1479106911-16049-2-git-send-email-wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
William
On Sun, Nov 13, 2016 at 11:01 PM, William Wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org> wrote:
> Since we needs to delay ~1ms to wait for 480MHz output clock
> of USB2 PHY to become stable after turn on it, the delay time
> is pretty long for something that's supposed to be "atomic"
> like a clk_enable(). Consider that clk_enable() will disable
> interrupt and that a 1ms interrupt latency is not sensible.
>
> The 480MHz output clock should be handled in prepare callbacks
> which support gate a clk if the operation may sleep.
>
> Signed-off-by: William Wu <wulf-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
> ---
> drivers/phy/phy-rockchip-inno-usb2.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Douglas Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback
From: Doug Anderson @ 2016-11-14 18:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479106911-16049-2-git-send-email-wulf@rock-chips.com>
William
On Sun, Nov 13, 2016 at 11:01 PM, William Wu <wulf@rock-chips.com> wrote:
> Since we needs to delay ~1ms to wait for 480MHz output clock
> of USB2 PHY to become stable after turn on it, the delay time
> is pretty long for something that's supposed to be "atomic"
> like a clk_enable(). Consider that clk_enable() will disable
> interrupt and that a 1ms interrupt latency is not sensible.
>
> The 480MHz output clock should be handled in prepare callbacks
> which support gate a clk if the operation may sleep.
>
> Signed-off-by: William Wu <wulf@rock-chips.com>
> ---
> drivers/phy/phy-rockchip-inno-usb2.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [PATCH v2 1/2] phy: rockchip-inno-usb2: correct clk_ops callback
From: Doug Anderson @ 2016-11-14 18:15 UTC (permalink / raw)
To: William Wu
Cc: Kishon Vijay Abraham I, Heiko Stübner,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
open list:ARM/Rockchip SoC..., devicetree@vger.kernel.org,
Rob Herring, Frank Wang, 黄涛, Brian Norris,
Guenter Roeck
In-Reply-To: <1479106911-16049-2-git-send-email-wulf@rock-chips.com>
William
On Sun, Nov 13, 2016 at 11:01 PM, William Wu <wulf@rock-chips.com> wrote:
> Since we needs to delay ~1ms to wait for 480MHz output clock
> of USB2 PHY to become stable after turn on it, the delay time
> is pretty long for something that's supposed to be "atomic"
> like a clk_enable(). Consider that clk_enable() will disable
> interrupt and that a 1ms interrupt latency is not sensible.
>
> The 480MHz output clock should be handled in prepare callbacks
> which support gate a clk if the operation may sleep.
>
> Signed-off-by: William Wu <wulf@rock-chips.com>
> ---
> drivers/phy/phy-rockchip-inno-usb2.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 18:15 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <14044cda-054d-94eb-8d91-7ad3a1e0869e@redhat.com>
On Mon, Nov 14, 2016 at 06:20:29PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 18:13, Marcelo Tosatti wrote:
> > On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/11/2016 16:40, Marcelo Tosatti wrote:
> >>> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> >>> {
> >>> KVMClockState *s = opaque;
> >>>
> >>> /*
> >>> * On machine types that support reliable KVM_GET_CLOCK,
> >>> * if host kernel does provide reliable KVM_GET_CLOCK,
> >>> * set src_use_reliable_get_clock=true so that destination
> >>> * avoids reading kvmclock from memory.
> >>> */
> >>> if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
> >>> {
> >>> s->src_use_reliable_get_clock = true;
> >>> }
> >>>
> >>> return s->mach_use_reliable_get_clock;
> >>> }
> >>>
> >>>
> >>> Ah, OK, done.
> >>
> >> s->src_use_reliable_get_clock should not be set with
> >> KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.
> >
> > Well, thats not right: What matters is the presence of get_kvmclock_ns
> > which returns a value that the guest sees.
> >
> > get_kernel_monotonic_clock() + kvmclock_offset +
> > (rdtsc() - tsc_timestamp)
> >
> > IOW what the guest sees. And you changed that in
> >
> > commit 108b249c453dd7132599ab6dc7e435a7036c193f
> > Author: Paolo Bonzini <pbonzini@redhat.com>
> > Date: Thu Sep 1 14:21:03 2016 +0200
> >
> > KVM: x86: introduce get_kvmclock_ns
> >
> > And the correct behaviour (once KVM_GET_CLOCK is fixed per
> > previous message to return rdtsc - tsc_timestamp for the
> > non masterclock case) depends on this commit above,
> > not on masterclock.
>
> This commit in turn only gets the correct behavior if
> "vcpu->arch.hv_clock.flags & PVCLOCK_TSC_STABLE_BIT" (and it will be
> changed soon to ka->use_masterclock). KVM_CHECK_EXTENSION can still
> return KVM_CLOCK_TSC_STABLE even if the masterclock is disabled,
> because KVM_CHECK_EXTENSION only tells you which flags are known for
> this version of the KVM module.
What QEMU wants is to use KVM_GET_CLOCK at pre_save independently
of whether masterclock is enabled or not... it just depends
on KVM_GET_CLOCK being correct for the masterclock case
(108b249c453dd7132599ab6dc7e435a7036c193f).
So a "reliable KVM_GET_CLOCK" (that does not timebackward
when masterclock is enabled) is much simpler to userspace
than "whether masterclock is enabled or not".
If you have a reason why that should not be the case,
let me know.
> To see if the masterclock is enabled _now_, you need to check what
> KVM_GET_CLOCK sets in the flags. From the KVM_CLOCK_TSC_STABLE patch:
>
> user_ns.flags = kvm->arch.use_master_clock ? KVM_CLOCK_TSC_STABLE : 0;
Again, whether masterclock is enable is independent of
being able to use KVM_GET_CLOCK at pre_save.
^ permalink raw reply
* Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Marcelo Tosatti @ 2016-11-14 18:15 UTC (permalink / raw)
To: Paolo Bonzini
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Juan Quintela,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <14044cda-054d-94eb-8d91-7ad3a1e0869e@redhat.com>
On Mon, Nov 14, 2016 at 06:20:29PM +0100, Paolo Bonzini wrote:
>
>
> On 14/11/2016 18:13, Marcelo Tosatti wrote:
> > On Mon, Nov 14, 2016 at 05:43:33PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/11/2016 16:40, Marcelo Tosatti wrote:
> >>> static bool kvmclock_src_use_reliable_get_clock(void *opaque)
> >>> {
> >>> KVMClockState *s = opaque;
> >>>
> >>> /*
> >>> * On machine types that support reliable KVM_GET_CLOCK,
> >>> * if host kernel does provide reliable KVM_GET_CLOCK,
> >>> * set src_use_reliable_get_clock=true so that destination
> >>> * avoids reading kvmclock from memory.
> >>> */
> >>> if (s->mach_use_reliable_get_clock && kvm_has_adjust_clock_stable())
> >>> {
> >>> s->src_use_reliable_get_clock = true;
> >>> }
> >>>
> >>> return s->mach_use_reliable_get_clock;
> >>> }
> >>>
> >>>
> >>> Ah, OK, done.
> >>
> >> s->src_use_reliable_get_clock should not be set with
> >> KVM_CHECK_EXTENSION, but rather from the flags returned by KVM_GET_CLOCK.
> >
> > Well, thats not right: What matters is the presence of get_kvmclock_ns
> > which returns a value that the guest sees.
> >
> > get_kernel_monotonic_clock() + kvmclock_offset +
> > (rdtsc() - tsc_timestamp)
> >
> > IOW what the guest sees. And you changed that in
> >
> > commit 108b249c453dd7132599ab6dc7e435a7036c193f
> > Author: Paolo Bonzini <pbonzini@redhat.com>
> > Date: Thu Sep 1 14:21:03 2016 +0200
> >
> > KVM: x86: introduce get_kvmclock_ns
> >
> > And the correct behaviour (once KVM_GET_CLOCK is fixed per
> > previous message to return rdtsc - tsc_timestamp for the
> > non masterclock case) depends on this commit above,
> > not on masterclock.
>
> This commit in turn only gets the correct behavior if
> "vcpu->arch.hv_clock.flags & PVCLOCK_TSC_STABLE_BIT" (and it will be
> changed soon to ka->use_masterclock). KVM_CHECK_EXTENSION can still
> return KVM_CLOCK_TSC_STABLE even if the masterclock is disabled,
> because KVM_CHECK_EXTENSION only tells you which flags are known for
> this version of the KVM module.
What QEMU wants is to use KVM_GET_CLOCK at pre_save independently
of whether masterclock is enabled or not... it just depends
on KVM_GET_CLOCK being correct for the masterclock case
(108b249c453dd7132599ab6dc7e435a7036c193f).
So a "reliable KVM_GET_CLOCK" (that does not timebackward
when masterclock is enabled) is much simpler to userspace
than "whether masterclock is enabled or not".
If you have a reason why that should not be the case,
let me know.
> To see if the masterclock is enabled _now_, you need to check what
> KVM_GET_CLOCK sets in the flags. From the KVM_CLOCK_TSC_STABLE patch:
>
> user_ns.flags = kvm->arch.use_master_clock ? KVM_CLOCK_TSC_STABLE : 0;
Again, whether masterclock is enable is independent of
being able to use KVM_GET_CLOCK at pre_save.
^ permalink raw reply
* [refpolicy] su_exec
From: Dominick Grift @ 2016-11-14 18:15 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <67130EC7AFA3FE4E9290B03665B351F40669E4@SE-EX022.groupinfra.com>
On 11/14/2016 05:11 PM, Fakim, Walid wrote:
> Hi Guys,
>
> So for this process am trying to confine, the startup script is using su -c rather than runuser and even though I've got su_exec(mydomain_t) in my te file, it's prompting for a password at startup.
>
> Any thoughts or experience of seeing this before?
>
> Thanks.
>
> Best Regards,
>
> Walid Fakim
>
>
Add pam_rootok.so to /etc/pam.d/su maybe?
Also you may need to allow ":passwd rootok;" permission
If it hit that then the event should show up as a "USER_AVC" in
audit.log (ausearch -m USER_AVC -ts today)
In the past there was a problem with PAMs' SELinux awareness and it was
not logging USER_AVC denials. That should now be fixed.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161114/b6331b12/attachment.bin
^ permalink raw reply
* Re: [PATCH 1/1] libsemanage: semanage_seuser_key_create: copy name
From: Stephen Smalley @ 2016-11-14 18:16 UTC (permalink / raw)
To: Nicolas Iooss, selinux
In-Reply-To: <20161112120503.2162-1-nicolas.iooss@m4x.org>
On 11/12/2016 07:05 AM, Nicolas Iooss wrote:
> When removing a login using semanage with Python 3 the following error
> occurs:
>
> # semanage login -l | grep my_user
> my_user user_u
>
> # semanage login --delete my_user
> ValueError: Login mapping for my_user is not defined
>
> This is due to a use-after-free in the swig-generated code for python3
> bindings.
>
> Copy the user name in semanage_seuser_key_create() and free it in
> semanage_seuser_key_free(), like commit eac6f1f1b512 ("libsepol:
> sepol_{bool|iface|user}_key_create: copy name") did.
Thanks, applied.
>
> Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org>
> ---
> libsemanage/src/seuser_record.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/libsemanage/src/seuser_record.c b/libsemanage/src/seuser_record.c
> index 8823b1ed1c7b..1ed459486228 100644
> --- a/libsemanage/src/seuser_record.c
> +++ b/libsemanage/src/seuser_record.c
> @@ -33,7 +33,7 @@ struct semanage_seuser {
>
> struct semanage_seuser_key {
> /* This user's name */
> - const char *name;
> + char *name;
> };
>
> int semanage_seuser_key_create(semanage_handle_t * handle,
> @@ -48,7 +48,12 @@ int semanage_seuser_key_create(semanage_handle_t * handle,
> ERR(handle, "out of memory, could not create seuser key");
> return STATUS_ERR;
> }
> - tmp_key->name = name;
> + tmp_key->name = strdup(name);
> + if (!tmp_key->name) {
> + ERR(handle, "out of memory, could not create seuser key");
> + free(tmp_key);
> + return STATUS_ERR;
> + }
>
> *key_ptr = tmp_key;
> return STATUS_SUCCESS;
> @@ -75,7 +80,7 @@ hidden_def(semanage_seuser_key_extract)
>
> void semanage_seuser_key_free(semanage_seuser_key_t * key)
> {
> -
> + free(key->name);
> free(key);
> }
>
>
^ permalink raw reply
* ✗ Fi.CI.BAT: warning for drm/i915: A few DP stragglers
From: Patchwork @ 2016-11-14 18:16 UTC (permalink / raw)
To: ville.syrjala; +Cc: intel-gfx
In-Reply-To: <1479145447-12907-1-git-send-email-ville.syrjala@linux.intel.com>
== Series Details ==
Series: drm/i915: A few DP stragglers
URL : https://patchwork.freedesktop.org/series/15299/
State : warning
== Summary ==
Series 15299v1 drm/i915: A few DP stragglers
https://patchwork.freedesktop.org/api/1.0/series/15299/revisions/1/mbox/
Test kms_pipe_crc_basic:
Subgroup nonblocking-crc-pipe-b:
pass -> DMESG-WARN (fi-snb-2520m)
fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40
fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53
fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hq total:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21
fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21
fi-snb-2520m total:244 pass:211 dwarn:1 dfail:0 fail:0 skip:32
fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33
8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 2016y-11m-14d-16h-10m-52s UTC integration manifest
1c9d66a drm/i915: Simplify DP port limited color range bit platform checks
73f4bd0 drm/i915: Kill dp_encoder_is_mst
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2987/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: ✓ Fi.CI.BAT: success for drm/i915: Per-plane rotation leftovers
From: Ville Syrjälä @ 2016-11-14 18:16 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20161114174719.16476.13804@emeril.freedesktop.org>
On Mon, Nov 14, 2016 at 05:47:19PM -0000, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Per-plane rotation leftovers
> URL : https://patchwork.freedesktop.org/series/15290/
> State : success
And series pushed to dinq. Thanks for the reviews.
>
> == Summary ==
>
> Series 15290v1 drm/i915: Per-plane rotation leftovers
> https://patchwork.freedesktop.org/api/1.0/series/15290/revisions/1/mbox/
>
>
> fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
> fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40
> fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
> fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
> fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
> fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
> fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
> fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53
> fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
> fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
> fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
> fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
> fi-skl-6700hq total:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21
> fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21
> fi-skl-6770hq total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
> fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
> fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33
>
> 8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 2016y-11m-14d-16h-10m-52s UTC integration manifest
> 86c7280 drm/i915: Add horizontal mirroring support for CHV pipe B planes
> c2f2b21 drm/i915: Clean up rotation DSPCNTR/DVSCNTR/etc. setup
> 00f1032 drm/i915: Use & instead if == to check for rotations
>
> == Logs ==
>
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2986/
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH v3 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: Doug Anderson @ 2016-11-14 18:17 UTC (permalink / raw)
To: William Wu
Cc: Kishon Vijay Abraham I, Heiko Stübner,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
open list:ARM/Rockchip SoC..., devicetree@vger.kernel.org,
Rob Herring, Frank Wang, 黄涛, Brian Norris,
Guenter Roeck
In-Reply-To: <1479115631-20137-3-git-send-email-wulf@rock-chips.com>
William,
On Mon, Nov 14, 2016 at 1:27 AM, William Wu <wulf@rock-chips.com> wrote:
> We found that the system crashed due to 480MHz output clock of
> USB2 PHY was unstable after clock had been enabled by gpu module.
>
> Theoretically, 1 millisecond is a critical value for 480MHz
> output clock stable time, so we try to change the delay time
> to 1.2 millisecond to avoid this issue.
>
> And the commit ed907fb1d7c3 ("phy: rockchip-inno-usb2: correct
> clk_ops callback") used prepare callbacks instead of enable
> callbacks to support gate a clk if the operation may sleep. So
> we can switch from delay to sleep functions.
>
> Signed-off-by: William Wu <wulf@rock-chips.com>
> ---
> Changes in v3:
> - fix kbuild test error: too few arguments to function 'usleep_range'
>
> Changes in v2:
> - use usleep_range() function instead of mdelay()
>
> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
> index 365e077..0e52b25 100644
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -166,7 +166,7 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
> return ret;
>
> /* waitting for the clk become stable */
> - mdelay(1);
> + usleep_range(1200, 1300);
Sight nit that you could also fix the spelling from "waitting" to "waiting".
...but that's pre-existing, so:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* [PATCH v3 2/2] phy: rockchip-inno-usb2: correct 480MHz output clock stable time
From: Doug Anderson @ 2016-11-14 18:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479115631-20137-3-git-send-email-wulf@rock-chips.com>
William,
On Mon, Nov 14, 2016 at 1:27 AM, William Wu <wulf@rock-chips.com> wrote:
> We found that the system crashed due to 480MHz output clock of
> USB2 PHY was unstable after clock had been enabled by gpu module.
>
> Theoretically, 1 millisecond is a critical value for 480MHz
> output clock stable time, so we try to change the delay time
> to 1.2 millisecond to avoid this issue.
>
> And the commit ed907fb1d7c3 ("phy: rockchip-inno-usb2: correct
> clk_ops callback") used prepare callbacks instead of enable
> callbacks to support gate a clk if the operation may sleep. So
> we can switch from delay to sleep functions.
>
> Signed-off-by: William Wu <wulf@rock-chips.com>
> ---
> Changes in v3:
> - fix kbuild test error: too few arguments to function 'usleep_range'
>
> Changes in v2:
> - use usleep_range() function instead of mdelay()
>
> drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
> index 365e077..0e52b25 100644
> --- a/drivers/phy/phy-rockchip-inno-usb2.c
> +++ b/drivers/phy/phy-rockchip-inno-usb2.c
> @@ -166,7 +166,7 @@ static int rockchip_usb2phy_clk480m_prepare(struct clk_hw *hw)
> return ret;
>
> /* waitting for the clk become stable */
> - mdelay(1);
> + usleep_range(1200, 1300);
Sight nit that you could also fix the spelling from "waitting" to "waiting".
...but that's pre-existing, so:
Reviewed-by: Douglas Anderson <dianders@chromium.org>
^ permalink raw reply
* Re: Tracing sched_switch events for client application when process is switched back in
From: Milian Wolff @ 2016-11-14 18:17 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: linux-perf-users
In-Reply-To: <20161114153611.GA26543@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3357 bytes --]
On Monday, November 14, 2016 12:36:11 PM CET Arnaldo Carvalho de Melo wrote:
> Em Mon, Nov 14, 2016 at 03:10:26PM +0100, Milian Wolff escreveu:
> > On Monday, October 10, 2016 9:36:55 PM CET Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Oct 06, 2016 at 06:38:28PM +0200, Milian Wolff escreveu:
> > > > only find 7, whereas tracing sched_switch finds all 100 that actually
> > > > take
> > > > place?
> >
> > Hey there,
> >
> > long delay but I looked at this again today.
> >
> > > This is looking only for the sched switches for the monitored workload,
> > > which in this case is 'sleep 1', this wasn't a system wide session.
> > >
> > > add -a and you'll get those other switches, if I got what you described.
> >
> > I've used the sources of the simple C application I showed in the first
> > email of this thread (still quoted above). Then I try:
> >
> > perf record --switch-events -a ./a.out
> >
> > And indeed, I get all switch events. But I now also profile all
> > applications on the machine, which is not what I want. I want to combine
> > the following
>
> So you remove that '-a' from that command line and gets just the context
> switches for that ./a.out app, no?
>
> Lets see:
<snip>
> 5 out, 5 in, in a lightly loaded machine, plenty of CPUs, looks about right,
> no?
Hm this is odd. Before writing the last mail, and the one from one month ago,
I tried this and it did not work. But now it does seem to work as intended,
even with my simple application code...
perf record --switch-events ./a.out
perf script --show-switch-events | grep -c SWITCH
200
So this clearly works as intended - sorry for the noise.
> But...
>
> > features:
> >
> > - sample CPU events for a given application with backtraces
> >
> > perf record --call-graph dwarf ./foo
> >
> > - record switch-out events with backtraces (`-e
> > sched:sched_switch/fp=dwarf/`) - somehow record the switch-in events,
> > which are associated with a different process and thus currently
> > discarded
>
> You want the backtraces with that, and since this is a meta-event... Humm,
> for the switch in would the above be sufficient? What value would be in
> knowing the backtrace in that case?
Knowing the backtrace would ensure I get the real location that triggered a
switch, i.e. often times that comes from a syscall like futex or the like. Or
would I always get a CPU event (e.g. cycles) with a backtrace before the
switch happens, pointing to the same location?
> So something like would do? Try not looking at the "PERF_RECORD_SWITCH OUT"
> lines, they are generated by the kernel _after_ the corresponding
> sched:sched_switch is registered:
>
> [root@jouet ~]# perf record --call-graph=dwarf --switch-events -e
<snip>
Yes, that seems to work just fine:
perf record -e cycles -e sched:sched_switch \
--call-graph dwarf --switch-events \
./a.out
That gives me all information. With some post-processing one could then turn
this into a really useful profiling tool, as one will only need a single perf
record step to allow both, on-CPU as well as off-CPU profiling for application
developers.
Many thanks for the help, Arnaldo, and sorry again for the confusion on my
side.
Cheers
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply
* Re: [PATCHSET] Add support for simplified async direct-io
From: Jens Axboe @ 2016-11-14 18:17 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: axboe, linux-block
In-Reply-To: <20161114181119.GA9396@infradead.org>
On 11/14/2016 11:11 AM, Christoph Hellwig wrote:
> On Mon, Nov 14, 2016 at 11:08:46AM -0700, Jens Axboe wrote:
>> It'd be cleaner to loop one level out, and avoid all that 'dio' stuff
>> instead. And then still retain the separate parts of the sync and async.
>> There's nothing to share there imho, and it just makes the code harder
>> to read.
>
> How do you avoid it for the async case? We can only call ki_complete
> once all bios have finished, which means we need a tracking structure
> for it. For the synchronous case we could in theory wait for the
> previous bio before sending the next, but there are plenty of RAID
> arrays that would prefer > 1MB I/O. And we can pretty much reuse the
> async case for this anyway.
Just make the limit reasonable - with a order 1 alloc, we have 256
pages, or 1MB of IO. Loop around that. We could play tricks with bio
reuse and using the ref count for knowing when it'd be done.
--
Jens Axboe
^ permalink raw reply
* Re: [RFC][PATCH 2/7] kref: Add kref_read()
From: Christoph Hellwig @ 2016-11-14 18:16 UTC (permalink / raw)
To: Peter Zijlstra
Cc: gregkh, keescook, will.deacon, elena.reshetova, arnd, tglx, mingo,
hpa, dave, linux-kernel
In-Reply-To: <20161114174446.486581399@infradead.org>
On Mon, Nov 14, 2016 at 06:39:48PM +0100, Peter Zijlstra wrote:
> Since we need to change the implementation, stop exposing internals.
>
> Provide kref_read() to read the current reference count; typically
> used for debug messages.
Can we just provide a printk specifier for a kref value instead as
that is the only valid use case for reading the value?
^ permalink raw reply
* [PATCH v2 0/4] Support PowerISA v3.0 PMU Raw event format
From: Madhavan Srinivasan @ 2016-11-14 18:17 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, Madhavan Srinivasan
Patchset to factor out the PowerISA v2.07 PMU raw event
format encoding and add support to the PowerISA v3.0 PMU
raw event format encoding.
Changelog v1:
1) Initialized "mmcra" variable to avoid compile time errors
2) Made changes to commit message
Madhavan Srinivasan (4):
powerpc/perf: factor out the event format field
powerpc/perf: update attribute_group data structure
powerpc/perf: PowerISA v3.0 raw event format encoding
powerpc/perf: macros for PowerISA v3.0 format encoding
arch/powerpc/perf/isa207-common.c | 124 +++++++++++++++++++++++++++++++++++---
arch/powerpc/perf/isa207-common.h | 27 ++++++++-
arch/powerpc/perf/power8-pmu.c | 39 ++----------
arch/powerpc/perf/power9-pmu.c | 112 +++++++++++++++++++++++++++++++++-
4 files changed, 256 insertions(+), 46 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v2 1/4] powerpc/perf: factor out the event format field
From: Madhavan Srinivasan @ 2016-11-14 18:17 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, Madhavan Srinivasan
In-Reply-To: <1479147435-18665-1-git-send-email-maddy@linux.vnet.ibm.com>
Factor out the format field structure for PowerISA v2.07.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
arch/powerpc/perf/isa207-common.c | 34 ++++++++++++++++++++++++++++++++++
arch/powerpc/perf/power8-pmu.c | 39 ++++-----------------------------------
arch/powerpc/perf/power9-pmu.c | 39 ++++-----------------------------------
3 files changed, 42 insertions(+), 70 deletions(-)
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 6143c99f3ec5..2a2040ea5f99 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -12,6 +12,40 @@
*/
#include "isa207-common.h"
+PMU_FORMAT_ATTR(event, "config:0-49");
+PMU_FORMAT_ATTR(pmcxsel, "config:0-7");
+PMU_FORMAT_ATTR(mark, "config:8");
+PMU_FORMAT_ATTR(combine, "config:11");
+PMU_FORMAT_ATTR(unit, "config:12-15");
+PMU_FORMAT_ATTR(pmc, "config:16-19");
+PMU_FORMAT_ATTR(cache_sel, "config:20-23");
+PMU_FORMAT_ATTR(sample_mode, "config:24-28");
+PMU_FORMAT_ATTR(thresh_sel, "config:29-31");
+PMU_FORMAT_ATTR(thresh_stop, "config:32-35");
+PMU_FORMAT_ATTR(thresh_start, "config:36-39");
+PMU_FORMAT_ATTR(thresh_cmp, "config:40-49");
+
+struct attribute *isa207_pmu_format_attr[] = {
+ &format_attr_event.attr,
+ &format_attr_pmcxsel.attr,
+ &format_attr_mark.attr,
+ &format_attr_combine.attr,
+ &format_attr_unit.attr,
+ &format_attr_pmc.attr,
+ &format_attr_cache_sel.attr,
+ &format_attr_sample_mode.attr,
+ &format_attr_thresh_sel.attr,
+ &format_attr_thresh_stop.attr,
+ &format_attr_thresh_start.attr,
+ &format_attr_thresh_cmp.attr,
+ NULL,
+};
+
+struct attribute_group isa207_pmu_format_group = {
+ .name = "format",
+ .attrs = isa207_pmu_format_attr,
+};
+
static inline bool event_is_fab_match(u64 event)
{
/* Only check pmc, unit and pmcxsel, ignore the edge bit (0) */
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index ab830d106ec5..d07186382f3a 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -30,6 +30,9 @@ enum {
#define POWER8_MMCRA_IFM2 0x0000000080000000UL
#define POWER8_MMCRA_IFM3 0x00000000C0000000UL
+/* PowerISA v2.07 format attribute structure*/
+extern struct attribute_group isa207_pmu_format_group;
+
/* Table of alternatives, sorted by column 0 */
static const unsigned int event_alternatives[][MAX_ALT] = {
{ PM_MRK_ST_CMPL, PM_MRK_ST_CMPL_ALT },
@@ -175,42 +178,8 @@ static struct attribute_group power8_pmu_events_group = {
.attrs = power8_events_attr,
};
-PMU_FORMAT_ATTR(event, "config:0-49");
-PMU_FORMAT_ATTR(pmcxsel, "config:0-7");
-PMU_FORMAT_ATTR(mark, "config:8");
-PMU_FORMAT_ATTR(combine, "config:11");
-PMU_FORMAT_ATTR(unit, "config:12-15");
-PMU_FORMAT_ATTR(pmc, "config:16-19");
-PMU_FORMAT_ATTR(cache_sel, "config:20-23");
-PMU_FORMAT_ATTR(sample_mode, "config:24-28");
-PMU_FORMAT_ATTR(thresh_sel, "config:29-31");
-PMU_FORMAT_ATTR(thresh_stop, "config:32-35");
-PMU_FORMAT_ATTR(thresh_start, "config:36-39");
-PMU_FORMAT_ATTR(thresh_cmp, "config:40-49");
-
-static struct attribute *power8_pmu_format_attr[] = {
- &format_attr_event.attr,
- &format_attr_pmcxsel.attr,
- &format_attr_mark.attr,
- &format_attr_combine.attr,
- &format_attr_unit.attr,
- &format_attr_pmc.attr,
- &format_attr_cache_sel.attr,
- &format_attr_sample_mode.attr,
- &format_attr_thresh_sel.attr,
- &format_attr_thresh_stop.attr,
- &format_attr_thresh_start.attr,
- &format_attr_thresh_cmp.attr,
- NULL,
-};
-
-static struct attribute_group power8_pmu_format_group = {
- .name = "format",
- .attrs = power8_pmu_format_attr,
-};
-
static const struct attribute_group *power8_pmu_attr_groups[] = {
- &power8_pmu_format_group,
+ &isa207_pmu_format_group,
&power8_pmu_events_group,
NULL,
};
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 8e9a81967ff8..443511b18bc5 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -31,6 +31,9 @@ enum {
#define POWER9_MMCRA_IFM2 0x0000000080000000UL
#define POWER9_MMCRA_IFM3 0x00000000C0000000UL
+/* PowerISA v2.07 format attribute structure*/
+extern struct attribute_group isa207_pmu_format_group;
+
GENERIC_EVENT_ATTR(cpu-cycles, PM_CYC);
GENERIC_EVENT_ATTR(stalled-cycles-frontend, PM_ICT_NOSLOT_CYC);
GENERIC_EVENT_ATTR(stalled-cycles-backend, PM_CMPLU_STALL);
@@ -90,42 +93,8 @@ static struct attribute_group power9_pmu_events_group = {
.attrs = power9_events_attr,
};
-PMU_FORMAT_ATTR(event, "config:0-49");
-PMU_FORMAT_ATTR(pmcxsel, "config:0-7");
-PMU_FORMAT_ATTR(mark, "config:8");
-PMU_FORMAT_ATTR(combine, "config:11");
-PMU_FORMAT_ATTR(unit, "config:12-15");
-PMU_FORMAT_ATTR(pmc, "config:16-19");
-PMU_FORMAT_ATTR(cache_sel, "config:20-23");
-PMU_FORMAT_ATTR(sample_mode, "config:24-28");
-PMU_FORMAT_ATTR(thresh_sel, "config:29-31");
-PMU_FORMAT_ATTR(thresh_stop, "config:32-35");
-PMU_FORMAT_ATTR(thresh_start, "config:36-39");
-PMU_FORMAT_ATTR(thresh_cmp, "config:40-49");
-
-static struct attribute *power9_pmu_format_attr[] = {
- &format_attr_event.attr,
- &format_attr_pmcxsel.attr,
- &format_attr_mark.attr,
- &format_attr_combine.attr,
- &format_attr_unit.attr,
- &format_attr_pmc.attr,
- &format_attr_cache_sel.attr,
- &format_attr_sample_mode.attr,
- &format_attr_thresh_sel.attr,
- &format_attr_thresh_stop.attr,
- &format_attr_thresh_start.attr,
- &format_attr_thresh_cmp.attr,
- NULL,
-};
-
-static struct attribute_group power9_pmu_format_group = {
- .name = "format",
- .attrs = power9_pmu_format_attr,
-};
-
static const struct attribute_group *power9_pmu_attr_groups[] = {
- &power9_pmu_format_group,
+ &isa207_pmu_format_group,
&power9_pmu_events_group,
NULL,
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/4] powerpc/perf: PowerISA v3.0 raw event format encoding
From: Madhavan Srinivasan @ 2016-11-14 18:17 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, Madhavan Srinivasan
In-Reply-To: <1479147435-18665-1-git-send-email-maddy@linux.vnet.ibm.com>
Patch to update the PowerISA v3.0 raw event encoding format
information and add support for the same in Power9-pmu.c.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
arch/powerpc/perf/power9-pmu.c | 134 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 134 insertions(+)
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index d1782fd644e9..928d0e739ed4 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -16,6 +16,78 @@
#include "isa207-common.h"
/*
+ * Raw event encoding for PowerISA v3.0:
+ *
+ * 60 56 52 48 44 40 36 32
+ * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - |
+ * | | [ ] [ ] [ thresh_cmp ] [ thresh_ctl ]
+ * | | | | |
+ * | | *- IFM (Linux) | thresh start/stop OR FAB match -*
+ * | *- BHRB (Linux) *sm
+ * *- EBB (Linux)
+ *
+ * 28 24 20 16 12 8 4 0
+ * | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - | - - - - |
+ * [ ] [ sample ] [cache] [ pmc ] [unit ] [] m [ pmcxsel ]
+ * | | | | |
+ * | | | | *- mark
+ * | | *- L1/L2/L3 cache_sel |
+ * | | |
+ * | *- sampling mode for marked events *- combine
+ * |
+ * *- thresh_sel
+ *
+ * Below uses IBM bit numbering.
+ *
+ * MMCR1[x:y] = unit (PMCxUNIT)
+ * MMCR1[24] = pmc1combine[0]
+ * MMCR1[25] = pmc1combine[1]
+ * MMCR1[26] = pmc2combine[0]
+ * MMCR1[27] = pmc2combine[1]
+ * MMCR1[28] = pmc3combine[0]
+ * MMCR1[29] = pmc3combine[1]
+ * MMCR1[30] = pmc4combine[0]
+ * MMCR1[31] = pmc4combine[1]
+ *
+ * if pmc == 3 and unit == 0 and pmcxsel[0:6] == 0b0101011
+ * # PM_MRK_FAB_RSP_MATCH
+ * MMCR1[20:27] = thresh_ctl (FAB_CRESP_MATCH / FAB_TYPE_MATCH)
+ * else if pmc == 4 and unit == 0xf and pmcxsel[0:6] == 0b0101001
+ * # PM_MRK_FAB_RSP_MATCH_CYC
+ * MMCR1[20:27] = thresh_ctl (FAB_CRESP_MATCH / FAB_TYPE_MATCH)
+ * else
+ * MMCRA[48:55] = thresh_ctl (THRESH START/END)
+ *
+ * if thresh_sel:
+ * MMCRA[45:47] = thresh_sel
+ *
+ * if thresh_cmp:
+ * MMCRA[9:11] = thresh_cmp[0:2]
+ * MMCRA[12:18] = thresh_cmp[3:9]
+ *
+ * if unit == 6 or unit == 7
+ * MMCRC[53:55] = cache_sel[1:3] (L2EVENT_SEL)
+ * else if unit == 8 or unit == 9:
+ * if cache_sel[0] == 0: # L3 bank
+ * MMCRC[47:49] = cache_sel[1:3] (L3EVENT_SEL0)
+ * else if cache_sel[0] == 1:
+ * MMCRC[50:51] = cache_sel[2:3] (L3EVENT_SEL1)
+ * else if cache_sel[1]: # L1 event
+ * MMCR1[16] = cache_sel[2]
+ * MMCR1[17] = cache_sel[3]
+ *
+ * if mark:
+ * MMCRA[63] = 1 (SAMPLE_ENABLE)
+ * MMCRA[57:59] = sample[0:2] (RAND_SAMP_ELIG)
+ * MMCRA[61:62] = sample[3:4] (RAND_SAMP_MODE)
+ *
+ * if EBB and BHRB:
+ * MMCRA[32:33] = IFM
+ *
+ * MMCRA[SDAR_MODE] = sm
+ */
+
+/*
* Some power9 event codes.
*/
#define EVENT(_name, _code) _name = _code,
@@ -99,6 +171,48 @@ static const struct attribute_group *power9_isa207_pmu_attr_groups[] = {
NULL,
};
+PMU_FORMAT_ATTR(event, "config:0-51");
+PMU_FORMAT_ATTR(pmcxsel, "config:0-7");
+PMU_FORMAT_ATTR(mark, "config:8");
+PMU_FORMAT_ATTR(combine, "config:10-11");
+PMU_FORMAT_ATTR(unit, "config:12-15");
+PMU_FORMAT_ATTR(pmc, "config:16-19");
+PMU_FORMAT_ATTR(cache_sel, "config:20-23");
+PMU_FORMAT_ATTR(sample_mode, "config:24-28");
+PMU_FORMAT_ATTR(thresh_sel, "config:29-31");
+PMU_FORMAT_ATTR(thresh_stop, "config:32-35");
+PMU_FORMAT_ATTR(thresh_start, "config:36-39");
+PMU_FORMAT_ATTR(thresh_cmp, "config:40-49");
+PMU_FORMAT_ATTR(sdar_mode, "config:50-51");
+
+static struct attribute *power9_pmu_format_attr[] = {
+ &format_attr_event.attr,
+ &format_attr_pmcxsel.attr,
+ &format_attr_mark.attr,
+ &format_attr_combine.attr,
+ &format_attr_unit.attr,
+ &format_attr_pmc.attr,
+ &format_attr_cache_sel.attr,
+ &format_attr_sample_mode.attr,
+ &format_attr_thresh_sel.attr,
+ &format_attr_thresh_stop.attr,
+ &format_attr_thresh_start.attr,
+ &format_attr_thresh_cmp.attr,
+ &format_attr_sdar_mode.attr,
+ NULL,
+};
+
+static struct attribute_group power9_pmu_format_group = {
+ .name = "format",
+ .attrs = power9_pmu_format_attr,
+};
+
+static const struct attribute_group *power9_pmu_attr_groups[] = {
+ &power9_pmu_format_group,
+ &power9_pmu_events_group,
+ NULL,
+};
+
static int power9_generic_events[] = {
[PERF_COUNT_HW_CPU_CYCLES] = PM_CYC,
[PERF_COUNT_HW_STALLED_CYCLES_FRONTEND] = PM_ICT_NOSLOT_CYC,
@@ -278,6 +392,24 @@ static struct power_pmu power9_isa207_pmu = {
.bhrb_nr = 32,
};
+static struct power_pmu power9_pmu = {
+ .name = "POWER9",
+ .n_counter = MAX_PMU_COUNTERS,
+ .add_fields = ISA207_ADD_FIELDS,
+ .test_adder = ISA207_TEST_ADDER,
+ .compute_mmcr = isa207_compute_mmcr,
+ .config_bhrb = power9_config_bhrb,
+ .bhrb_filter_map = power9_bhrb_filter_map,
+ .get_constraint = isa207_get_constraint,
+ .disable_pmc = isa207_disable_pmc,
+ .flags = PPMU_HAS_SIER | PPMU_ARCH_207S,
+ .n_generic = ARRAY_SIZE(power9_generic_events),
+ .generic_events = power9_generic_events,
+ .cache_events = &power9_cache_events,
+ .attr_groups = power9_pmu_attr_groups,
+ .bhrb_nr = 32,
+};
+
static int __init init_power9_pmu(void)
{
int rc;
@@ -289,6 +421,8 @@ static int __init init_power9_pmu(void)
if (cpu_has_feature(CPU_FTR_POWER9_DD1)) {
rc = register_power_pmu(&power9_isa207_pmu);
+ } else {
+ rc = register_power_pmu(&power9_pmu);
}
if (rc)
--
2.7.4
^ permalink raw reply related
* [PATCH v2 2/4] powerpc/perf: update attribute_group data structure
From: Madhavan Srinivasan @ 2016-11-14 18:17 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, Madhavan Srinivasan
In-Reply-To: <1479147435-18665-1-git-send-email-maddy@linux.vnet.ibm.com>
Rename the power_pmu and attribute_group variables that
support PowerISA v2.07. Add a cpu feature flag check to pick
the PowerISA v2.07 format structures to support.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
arch/powerpc/perf/power9-pmu.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/perf/power9-pmu.c b/arch/powerpc/perf/power9-pmu.c
index 443511b18bc5..d1782fd644e9 100644
--- a/arch/powerpc/perf/power9-pmu.c
+++ b/arch/powerpc/perf/power9-pmu.c
@@ -93,7 +93,7 @@ static struct attribute_group power9_pmu_events_group = {
.attrs = power9_events_attr,
};
-static const struct attribute_group *power9_pmu_attr_groups[] = {
+static const struct attribute_group *power9_isa207_pmu_attr_groups[] = {
&isa207_pmu_format_group,
&power9_pmu_events_group,
NULL,
@@ -260,7 +260,7 @@ static int power9_cache_events[C(MAX)][C(OP_MAX)][C(RESULT_MAX)] = {
#undef C
-static struct power_pmu power9_pmu = {
+static struct power_pmu power9_isa207_pmu = {
.name = "POWER9",
.n_counter = MAX_PMU_COUNTERS,
.add_fields = ISA207_ADD_FIELDS,
@@ -274,7 +274,7 @@ static struct power_pmu power9_pmu = {
.n_generic = ARRAY_SIZE(power9_generic_events),
.generic_events = power9_generic_events,
.cache_events = &power9_cache_events,
- .attr_groups = power9_pmu_attr_groups,
+ .attr_groups = power9_isa207_pmu_attr_groups,
.bhrb_nr = 32,
};
@@ -287,7 +287,10 @@ static int __init init_power9_pmu(void)
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power9"))
return -ENODEV;
- rc = register_power_pmu(&power9_pmu);
+ if (cpu_has_feature(CPU_FTR_POWER9_DD1)) {
+ rc = register_power_pmu(&power9_isa207_pmu);
+ }
+
if (rc)
return rc;
--
2.7.4
^ permalink raw reply related
* [PATCH v2 4/4] powerpc/perf: macros for PowerISA v3.0 format encoding
From: Madhavan Srinivasan @ 2016-11-14 18:17 UTC (permalink / raw)
To: mpe; +Cc: linuxppc-dev, Madhavan Srinivasan
In-Reply-To: <1479147435-18665-1-git-send-email-maddy@linux.vnet.ibm.com>
Patch to add macros and contants to support the PowerISA v3.0 raw
event encoding format. Couple of functions added since some of the
bits fields like PMCxCOMB and THRESH_CMP has different width and location
within MMCR* in PowerISA v3.0.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
---
arch/powerpc/perf/isa207-common.c | 90 ++++++++++++++++++++++++++++++++++++---
arch/powerpc/perf/isa207-common.h | 27 +++++++++++-
2 files changed, 109 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/perf/isa207-common.c b/arch/powerpc/perf/isa207-common.c
index 2a2040ea5f99..e747bbf06661 100644
--- a/arch/powerpc/perf/isa207-common.c
+++ b/arch/powerpc/perf/isa207-common.c
@@ -55,6 +55,81 @@ static inline bool event_is_fab_match(u64 event)
return (event == 0x30056 || event == 0x4f052);
}
+static bool is_event_valid(u64 event)
+{
+ if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ (cpu_has_feature(CPU_FTR_POWER9_DD1)) &&
+ (event & ~EVENT_VALID_MASK))
+ return false;
+ else if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ (event & ~ISA300_EVENT_VALID_MASK))
+ return false;
+ else if (event & ~EVENT_VALID_MASK)
+ return false;
+
+ return true;
+}
+
+static u64 mmcra_sdar_mode(u64 event)
+{
+ u64 sm;
+
+ if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ (cpu_has_feature(CPU_FTR_POWER9_DD1))) {
+ goto sm_tlb;
+ } else if (cpu_has_feature(CPU_FTR_ARCH_300)) {
+ sm = (event >> ISA300_SDAR_MODE_SHIFT) & ISA300_SDAR_MODE_MASK;
+ if (sm)
+ return sm<<MMCRA_SDAR_MODE_SHIFT;
+ } else
+ goto sm_tlb;
+
+sm_tlb:
+ return MMCRA_SDAR_MODE_TLB;
+}
+
+static u64 thresh_cmp_val(u64 value)
+{
+ if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ (cpu_has_feature(CPU_FTR_POWER9_DD1)))
+ goto thr_cmp;
+ else if (cpu_has_feature(CPU_FTR_ARCH_300))
+ return value<<ISA300_MMCRA_THR_CMP_SHIFT;
+ else
+ goto thr_cmp;
+thr_cmp:
+ return value<<MMCRA_THR_CMP_SHIFT;
+}
+
+static unsigned long combine_from_event(u64 event)
+{
+ unsigned long combine;
+
+ if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ (cpu_has_feature(CPU_FTR_POWER9_DD1)))
+ combine = (event >> EVENT_COMBINE_SHIFT) & EVENT_COMBINE_MASK;
+ else if (cpu_has_feature(CPU_FTR_ARCH_300))
+ combine = (event >> ISA300_EVENT_COMBINE_SHIFT) & ISA300_EVENT_COMBINE_MASK;
+ else
+ combine = (event >> EVENT_COMBINE_SHIFT) & EVENT_COMBINE_MASK;
+
+ return combine;
+}
+
+static unsigned long combine_shift(unsigned long pmc)
+{
+ if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ (cpu_has_feature(CPU_FTR_POWER9_DD1)))
+ goto comb_shift;
+ else if (cpu_has_feature(CPU_FTR_ARCH_300))
+ return ISA300_MMCR1_COMBINE_SHIFT(pmc);
+ else
+ goto comb_shift;
+
+comb_shift:
+ return MMCR1_COMBINE_SHIFT(pmc);
+}
+
int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)
{
unsigned int unit, pmc, cache, ebb;
@@ -62,7 +137,7 @@ int isa207_get_constraint(u64 event, unsigned long *maskp, unsigned long *valp)
mask = value = 0;
- if (event & ~EVENT_VALID_MASK)
+ if (!is_event_valid(event))
return -1;
pmc = (event >> EVENT_PMC_SHIFT) & EVENT_PMC_MASK;
@@ -189,15 +264,13 @@ int isa207_compute_mmcr(u64 event[], int n_ev,
pmc_inuse |= 1 << pmc;
}
- /* In continuous sampling mode, update SDAR on TLB miss */
- mmcra = MMCRA_SDAR_MODE_TLB;
- mmcr1 = mmcr2 = 0;
+ mmcra = mmcr1 = mmcr2 = 0;
/* Second pass: assign PMCs, set all MMCR1 fields */
for (i = 0; i < n_ev; ++i) {
pmc = (event[i] >> EVENT_PMC_SHIFT) & EVENT_PMC_MASK;
unit = (event[i] >> EVENT_UNIT_SHIFT) & EVENT_UNIT_MASK;
- combine = (event[i] >> EVENT_COMBINE_SHIFT) & EVENT_COMBINE_MASK;
+ combine = combine_from_event(event[i]);
psel = event[i] & EVENT_PSEL_MASK;
if (!pmc) {
@@ -211,10 +284,13 @@ int isa207_compute_mmcr(u64 event[], int n_ev,
if (pmc <= 4) {
mmcr1 |= unit << MMCR1_UNIT_SHIFT(pmc);
- mmcr1 |= combine << MMCR1_COMBINE_SHIFT(pmc);
+ mmcr1 |= combine << combine_shift(pmc);
mmcr1 |= psel << MMCR1_PMCSEL_SHIFT(pmc);
}
+ /* In continuous sampling mode, update SDAR on TLB miss */
+ mmcra |= mmcra_sdar_mode(event[i]);
+
if (event[i] & EVENT_IS_L1) {
cache = event[i] >> EVENT_CACHE_SEL_SHIFT;
mmcr1 |= (cache & 1) << MMCR1_IC_QUAL_SHIFT;
@@ -245,7 +321,7 @@ int isa207_compute_mmcr(u64 event[], int n_ev,
val = (event[i] >> EVENT_THR_SEL_SHIFT) & EVENT_THR_SEL_MASK;
mmcra |= val << MMCRA_THR_SEL_SHIFT;
val = (event[i] >> EVENT_THR_CMP_SHIFT) & EVENT_THR_CMP_MASK;
- mmcra |= val << MMCRA_THR_CMP_SHIFT;
+ mmcra |= thresh_cmp_val(val);
}
if (event[i] & EVENT_WANTS_BHRB) {
diff --git a/arch/powerpc/perf/isa207-common.h b/arch/powerpc/perf/isa207-common.h
index 4d0a4e5017c2..0a240635cf48 100644
--- a/arch/powerpc/perf/isa207-common.h
+++ b/arch/powerpc/perf/isa207-common.h
@@ -134,6 +134,24 @@
PERF_SAMPLE_BRANCH_KERNEL |\
PERF_SAMPLE_BRANCH_HV)
+/* Contants to support PowerISA v3.0 encoding format */
+#define ISA300_EVENT_COMBINE_SHIFT 10 /* Combine bit */
+#define ISA300_EVENT_COMBINE_MASK 0x3ull
+#define ISA300_SDAR_MODE_SHIFT 50
+#define ISA300_SDAR_MODE_MASK 0x3ull
+
+#define ISA300_EVENT_VALID_MASK \
+ ((ISA300_SDAR_MODE_MASK<< ISA300_SDAR_MODE_SHIFT | \
+ (EVENT_THRESH_MASK << EVENT_THRESH_SHIFT) | \
+ (EVENT_SAMPLE_MASK << EVENT_SAMPLE_SHIFT) | \
+ (EVENT_CACHE_SEL_MASK << EVENT_CACHE_SEL_SHIFT) | \
+ (EVENT_PMC_MASK << EVENT_PMC_SHIFT) | \
+ (EVENT_UNIT_MASK << EVENT_UNIT_SHIFT) | \
+ (ISA300_EVENT_COMBINE_MASK << ISA300_EVENT_COMBINE_SHIFT) | \
+ (EVENT_MARKED_MASK << EVENT_MARKED_SHIFT) | \
+ EVENT_LINUX_MASK | \
+ EVENT_PSEL_MASK))
+
/*
* Layout of constraint bits:
*
@@ -210,15 +228,22 @@
#define MMCR1_DC_QUAL_SHIFT 47
#define MMCR1_IC_QUAL_SHIFT 46
+/* MMCR1 Combine bits macro for PowerISA v3.0 */
+#define ISA300_MMCR1_COMBINE_SHIFT(pmc) (38 - ((pmc - 1) * 2))
+
/* Bits in MMCRA for PowerISA v2.07 */
#define MMCRA_SAMP_MODE_SHIFT 1
#define MMCRA_SAMP_ELIG_SHIFT 4
#define MMCRA_THR_CTL_SHIFT 8
#define MMCRA_THR_SEL_SHIFT 16
#define MMCRA_THR_CMP_SHIFT 32
-#define MMCRA_SDAR_MODE_TLB (1ull << 42)
+#define MMCRA_SDAR_MODE_SHIFT 42
+#define MMCRA_SDAR_MODE_TLB (1ull << MMCRA_SDAR_MODE_SHIFT)
#define MMCRA_IFM_SHIFT 30
+/* MMCR1 Threshold Compare bit constant for PowerISA v3.0 */
+#define ISA300_MMCRA_THR_CMP_SHIFT 45
+
/* Bits in MMCR2 for PowerISA v2.07 */
#define MMCR2_FCS(pmc) (1ull << (63 - (((pmc) - 1) * 9)))
#define MMCR2_FCP(pmc) (1ull << (62 - (((pmc) - 1) * 9)))
--
2.7.4
^ permalink raw reply related
* Re: linux-next: Tree for Nov 14 (drivers/cpufreq/intel_pstate.c)
From: Srinivas Pandruvada @ 2016-11-14 18:17 UTC (permalink / raw)
To: Randy Dunlap, Stephen Rothwell, linux-next
Cc: linux-kernel, Len Brown, Linux PM list, Viresh Kumar,
Rafael J. Wysocki, Arnd Bergmann
In-Reply-To: <e7f4138c-709a-b60f-e6b8-9ef4dc418d7f@infradead.org>
On Mon, 2016-11-14 at 09:48 -0800, Randy Dunlap wrote:
> On 11/13/16 23:23, Stephen Rothwell wrote:
> >
> > Hi all,
> >
> > Changes since 20161111:
> >
>
> on i386, when CONFIG_ACPI is not enabled:
>
> ../drivers/cpufreq/intel_pstate.c: In function 'copy_cpu_funcs':
> ../drivers/cpufreq/intel_pstate.c:1798:2: error: too few arguments to
> function 'intel_pstate_use_acpi_profile'
> intel_pstate_use_acpi_profile();
> ^
> ../drivers/cpufreq/intel_pstate.c:1782:20: note: declared here
> static inline void intel_pstate_use_acpi_profile(struct pstate_funcs
> *funcs)
>
^
[PATCH] cpufreq: intel_pstate: fix intel_pstate_use_acpi_profile helper
from Arnd Bergmann <arnd@arndb.de>
fixes this.
But I am resubmitting the original patch as this is a compile issue.
Thanks,
Srinivas
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.