It's been observed that even if firmware returns an error
for a configuration command, we go ahead and start AP.
This patch changes the command type from async to sync
so that threads waits for command response and return
failure start AP.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Even if ADHOC start or join attempt is failed, these commands
are returned with success status by firmware. Actual connection
result is provided inside command response.
This patch parses the adhoc connection result and resets
connection state variables if connection is not successful.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Cathy Luo <cluo@marvell.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This code was supposed to trigger a BUG() if we truncate the output but
it's off by one so it allows one character to be truncated. Really
drivers shouldn't call BUG_ON() and especially for something minor like
this so I've changed it to a WARN_ON().
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The current code returns success if prism2_init_local_data() fails, but
we want to return an error code. Also we can remove the bogus
ret initializer because it is wrong and never used.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
We already know that "wep_key->key_length" is set so there is no need to
check again. Also the last curly brace was indented too far.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This code causes a static checker warning because we check for
"if (ret == 0)" but we have already had verified that was true. Clean
it up a little.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
If the mode is NL80211_IFTYPE_UNSPECIFIED then we return success at the
start of the function so this condition is never true.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
There is a null ptr check for fws to set bcmc_credit_check, however,
there a lock and unlock on fws should only performed if fwts is
also not null to also avoid a potential null pointer deference.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The condition for checking for XDAT being cleared was not correct.
Fixes: 36bcecd0a7 ("ASoC: davinci-mcasp: Correct TX start sequence")
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Align to new wl18xx sg parameters.
This requires to split both wl12xx/wl18xx enumerators.
Signed-off-by: Guy Mishol <guym@ti.com>
Acked-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This driver has been sitting in the linux-zigbee[2] repository for a long
time. We updated it from time to time and made it available via our
github kernel repository. The Linux MAC802.15.4 support has improved a lot
since then. Thanks to all! So it’s finally time to upstream this driver.
The ADF7242 requires an add-on firmware for the automatic IEEE 802.15.4
operating modes. The firmware file is currently made available on the
ADF7242 wiki page here [1]
[1] http://wiki.analog.com/resources/tools-software/linux-drivers/networking-mac802154/adf7242
[2] http://sourceforge.net/p/linux-zigbee/kernel/ci/devel/tree/drivers/ieee802154/adf7242.c
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Reviewed-by: Stefan Schmidt <stefan@osg.samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This patch removes redundant condition.
(length && length > 5) can be reduced to a single evaluation.
Tested by compilation only.
Caught by cppcheck.
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
This patch removes redundant conditions.
(!A || (A && B)) is the same as (!A || B).
Tested by compilation only.
Caught by cppcheck.
Signed-off-by: Geyslan G. Bem <geyslan@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
A Linux PC is connected with another device over Bluetooth PAN using a
BNEP interface.
Whenever a packet is tried to be sent over the BNEP interface, the
function "bnep_net_xmit()" in "net/bluetooth/bnep/netdev.c" is called.
This function calls "bnep_net_mc_filter()", which checks (if the
destination address is multicast) if the address is set in a certain
multicast filter (&s->mc_filter). If it is not, then it is not sent out.
This filter is only changed in two other functions, found in
net/bluetooth/bnep/core.c": in "bnep_ctrl_set_mc_filter()", which is
only called if a message of type "BNEP_FILTER_MULTI_ADDR_SET" is
received. Otherwise, it is set in "bnep_add_connection()", where it is
set to a default value which only adds the broadcast address to the
filter:
set_bit(bnep_mc_hash(dev->broadcast), (ulong *) &s->mc_filter);
To sum up, if the BNEP interface does not receive any message of type
"BNEP_FILTER_MULTI_ADDR_SET", it will not send out any messages with
multicast destination addresses except for broadcast.
However, in the BNEP specification (page 27 in
http://grouper.ieee.org/groups/802/15/Bluetooth/BNEP.pdf), it is said
that per default, all multicast addresses should not be filtered, i.e.
the BNEP interface should be able to send packets with any multicast
destination address.
It seems that the default case is wrong: the multicast filter should not
block almost all multicast addresses, but should not filter out any.
This leads to the problem that e.g. Neighbor Solicitation messages sent
with Bluetooth PAN over the BNEP interface to a multicast destination
address other than broadcast are blocked and not sent out.
Therefore, in the default case, we set the mc_filter to ~0LL to not
filter out any multicast addresses.
Signed-off-by: Danny Schweizer <danny.schweizer@proofnet.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The H3 uses the same pin controller as previous SoC's from Allwinner.
Add support for the pins controlled by the main PIO controller.
Signed-off-by: Jens Kuske <jenskuske@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If the Renesas R-Car GPIO driver cannot find a functional clock, it
prints a warning, .e.g.
gpio_rcar ffc40000.gpio: unable to get clock
and continues, as the clock is optional, depending on the SoC type.
This warning may confuse users.
To fix this, add a flag to indicate that the clock is mandatory or
optional:
- If the clock is mandatory (on R-Car Gen2 and Gen3), a missing clock
is now treated as a fatal error,
- If the clock is optional (on R-Car Gen1), the warning is no longer
printed.
Suggested-by: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit 4baadb9e05 ("ARM: shmobile: r8a7778: remove obsolete
setup code"), Renesas R-Car SoCs are only supported in generic DT-only
ARM multi-platform builds. The driver doesn't need to use platform data
anymore, hence remove platform data configuration.
Make gpio_rcar_priv.has_both_edge_trigger a boolean for consistency with
gpio_rcar_info.has_both_edge_trigger.
Move gpio_rcar_priv.irq_parent down while we're at it, to prevent gaps
on 64-bit.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Describe the procedure that drm_helper_probe_single_connector_modes()
uses to do it's work in the kernel-doc comment.
Caveat: Looks like crap and trying to reverse engineer the documentation
tools is not something I want to do.
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449782037-19722-3-git-send-email-ville.syrjala@linux.intel.com
IMO the override_edid should override any default EDID for the
connector, whether that came in via the connector helper ->get_modes()
vfunc or via the firmware EDID mechanism.
Cc: Thomas Wood <thomas.wood@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449782037-19722-2-git-send-email-ville.syrjala@linux.intel.com
sti seems confused about which mode list is used in its .get_modes()
hook. It adds the modes to the probed_modes list (as is appropriate)
but then for some reason it tries to sort the old mode list.
Just drop the sorting since it does nothing, and let the probe helper
do its thing. It will sort the final mode list after merging in the
modes from the probed_modes list and validating them.
Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Cc: Vincent Abriou <vincent.abriou@st.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-8-git-send-email-ville.syrjala@linux.intel.com
Now that the mode type bit merge logic is fixed to only merge
between new probed modes, hopefully we can eliminat the special
case for qxl and virtio. That is make the merge the mode type
bits from all matching new probed modes, just like every other
driver.
qxl and virtio got excluded from the merging in
commit 3fbd6439e4 ("drm: copy mode type in drm_mode_connector_list_update()")
commit abce1ec9b0 ("Revert "drm: copy mode type in drm_mode_connector_list_update()"")
commit b87577b7c7 ("drm: try harder to avoid regression when merging mode bits")
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Resolve conflicts with doc updates.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently most drivers request that any mode appearing on both the
old mode list and the new probed_modes list get their type bits ORed
together if the modes are deemed to otherwise match each other.
I don't know why anyone would want to merge in the mode type bits
from any mode left over from a previous probe. For instance, you
could never get rid of ther preferred bit if a matching non-preferred
mode is returned by the new probe. So let's not merge anything from
the stale old modes, and just replace them outright with matching new
modes.
If multiple matching modes are produced by the same probe, merging
the type bits between them would seem like a sensible thing to do.
For a bit of extra finesse if two modes are considered equal we can
pick the actual timings from the one marked as preferrred. And if
multiple preferred modes are produced by the same probe somehow, we
can just favor the first one added to the probed_modes list.
You may be asking yourself why we bother with the merging at all if
nothing from the old list survives in practice. The only answer I have
is "debug output". That is we want to print out a list of pruned modes,
which is why we still want to look for duplicates with the old modes.
There was a previous attempt to get rid of the mode type merging
entirely, but it caused some kind of regression on Daniels's G33
machine. Apparently the sdvo transcoder on said machine started to
die at around the same time and has since rotted away totally, so
it may have been a red herring. So we don't have to worry about
it anymore. The relevant commits are:
commit 3fbd6439e4 ("drm: copy mode type in drm_mode_connector_list_update()")
commit abce1ec9b0 ("Revert "drm: copy mode type in drm_mode_connector_list_update()"")
It was then decided in
commit b87577b7c7 ("drm: try harder to avoid regression when merging mode bits")
that just qxl virtio are excluded from the merging, while everyone
else does it. That is not changed, although now even qxl and virtio
will be subject to the previously mentioned logic to choose which
actual timings are picked for the new mode.
v2: Fix typos in commit message, and clarify the details on
the G33 regression from the previous attempt (Daniel)
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449234781-22332-1-git-send-email-ville.syrjala@linux.intel.com
MODE_UNVERIFIED actually means that the mode came from a previous probe,
and if the new probe doesn't produce a matching mode it will get pruned
from the list. Rename the flag to MODE_STALE to better convey the
meaning.
v2: Rebased due to conflicts with Daniel's doc stuff
Cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449779948-10906-1-git-send-email-ville.syrjala@linux.intel.com
The Olimex A20-SOM-EVB is an evaluation board for the Olimex
A20-SOM system-on-module. The baseboard provides a full-size SD
socket (connected to mmc3) in addition to the micro-SD socket on
the SOM itself (which is connected to mmc0).
Enable the mmc3 controller in the dts.
Signed-off-by: Karsten Merker <merker@debian.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The Olimex A20-SOM-EVB is an evaluation board for the Olimex
A20-SOM system-on-module. It provides a set of android-style
buttons (labeled "VOL+", "VOL-", "MENU", "SEARCH", "HOME", "ESC"
and "ENTER") which are connected to a low-resolution ADC via a
resistor network.
This patch adds appropriate button definitions to the board
dts. The voltages assigned to the keys are specified in the
board schematics published by the manufacturer.
Signed-off-by: Karsten Merker <merker@debian.org>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
The way the mode probing works is this:
1. All modes currently on the mode list are marked as UNVERIFIED
2. New modes are on the probed_modes list (they start with
status OK)
3. Modes are moved from the probed_modes list to the actual
mode list. If a mode already on the mode list is deemed
to match one of the probed modes, the duplicate is dropped
and the mode status updated to OK. After this the
probed_modes list will be empty.
4. All modes on the mode list are verified to not violate any
constraints. Any that do are marked as such.
5. Any mode left with a non-OK status is pruned from the list,
with an appropriate debug message.
What all this means is that any mode on the original list that
didn't have a duplicate on the probed_modes list, should be left
with status UNVERFIED (or previously could have been left with
some other status, but never OK).
I broke that in
commit 05acaec334 ("drm: Reorganize probed mode validation")
by always assigning something to the mode->status during the validation
step. So any mode from the old list that still passed the validation
would be left on the list with status OK in the end.
Fix this by not doing the basic mode validation unless the mode
already has status OK (meaning it came from the probed_modes list,
or at least a duplicate of it was on that list). This way we will
correctly prune away any mode from the old mode list that didn't
appear on the probed_modes list.
Cc: stable@vger.kernel.org
Cc: Adam Jackson <ajax@redhat.com>
Fixes: 05acaec334 ("drm: Reorganize probed mode validation")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1449177255-9515-2-git-send-email-ville.syrjala@linux.intel.com
Testcase: igt/kms_force_connector_basic/prune-stale-modes
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93332
[danvet: Also applying to drm-misc to avoid too much conflict hell -
there's a big pile of patches from Ville on top of this one.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Show a sensible name for the plane in debug mesages. The driver
may supply its own name, otherwise the core genrates the name
("plane-0", "plane-1" etc.).
v2: kstrdup() the name passed by the caller (Jani)
v3: Generate a default name if the driver doesn't supply one
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449592922-5545-7-git-send-email-ville.syrjala@linux.intel.com
Show a sensible name for the crtc in debug mesages. The driver may
supply its own name, otherwise the core genrates the name
("crtc-0", "crtc-1" etc.).
v2: kstrdup() the name passed by the caller (Jani)
v3: Generate a default name if the driver doesn't supply one
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449592922-5545-6-git-send-email-ville.syrjala@linux.intel.com
Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.
@@
identifier dev, encoder, funcs;
@@
int drm_encoder_init(struct drm_device *dev,
struct drm_encoder *encoder,
const struct drm_encoder_funcs *funcs,
int encoder_type
+ ,const char *name, int DOTDOTDOT
)
{ ... }
@@
identifier dev, encoder, funcs;
@@
int drm_encoder_init(struct drm_device *dev,
struct drm_encoder *encoder,
const struct drm_encoder_funcs *funcs,
int encoder_type
+ ,const char *name, int DOTDOTDOT
);
@@
expression E1, E2, E3, E4;
@@
drm_encoder_init(E1, E2, E3, E4
+ ,NULL
)
v2: Add ', or NULL...' to @name kernel doc (Jani)
Annotate the function with __printf() attribute (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670818-2966-1-git-send-email-ville.syrjala@linux.intel.com
Done with coccinelle for the most part. It choked on
msm/mdp/mdp5/mdp5_plane.c like so:
"BAD:!!!!! enum drm_plane_type type;"
No idea how to deal with that, so I just fixed that up
by hand.
Also it thinks '...' is part of the semantic patch, so I put an
'int DOTDOTDOT' placeholder in its place and got rid of it with
sed afterwards.
I didn't convert drm_plane_init() since passing the varargs through
would mean either cpp macros or va_list, and I figured we don't
care about these legacy functions enough to warrant the extra pain.
@@
typedef uint32_t;
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
const uint32_t *formats,
unsigned int format_count,
enum drm_plane_type type
+ ,const char *name, int DOTDOTDOT
)
{ ... }
@@
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
int drm_universal_plane_init(struct drm_device *dev,
struct drm_plane *plane,
unsigned long possible_crtcs,
const struct drm_plane_funcs *funcs,
const uint32_t *formats,
unsigned int format_count,
enum drm_plane_type type
+ ,const char *name, int DOTDOTDOT
);
@@
expression E1, E2, E3, E4, E5, E6, E7;
@@
drm_universal_plane_init(E1, E2, E3, E4, E5, E6, E7
+ ,NULL
)
v2: Split crtc and plane changes apart
Pass NUL for no-name instead of ""
Leave drm_plane_init() alone
v3: Add ', or NULL...' to @name kernel doc (Jani)
Annotate the function with __printf() attribute (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670795-2853-1-git-send-email-ville.syrjala@linux.intel.com
Done with coccinelle for the most part. However, it thinks '...' is
part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder
in its place and got rid of it with sed afterwards.
I didn't convert drm_crtc_init() since passing the varargs through
would mean either cpp macros or va_list, and I figured we don't
care about these legacy functions enough to warrant the extra pain.
@@
identifier dev, crtc, primary, cursor, funcs;
@@
int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor,
const struct drm_crtc_funcs *funcs
+ ,const char *name, int DOTDOTDOT
)
{ ... }
@@
identifier dev, crtc, primary, cursor, funcs;
@@
int drm_crtc_init_with_planes(struct drm_device *dev,
struct drm_crtc *crtc,
struct drm_plane *primary, struct drm_plane *cursor,
const struct drm_crtc_funcs *funcs
+ ,const char *name, int DOTDOTDOT
);
@@
expression E1, E2, E3, E4, E5;
@@
drm_crtc_init_with_planes(E1, E2, E3, E4, E5
+ ,NULL
)
v2: Split crtc and plane changes apart
Pass NULL for no-name instead of ""
Leave drm_crtc_init() alone
v3: Add ', or NULL...' to @name kernel doc (Jani)
Annotate the function with __printf() attribute (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670771-2751-1-git-send-email-ville.syrjala@linux.intel.com
This build failure triggers on 64-bit allmodconfig:
arch/x86/platform/uv/uv_nmi.c:493:2: error: implicit declaration of function ‘clocksource_touch_watchdog’ [-Werror=implicit-function-declaration]
which is caused by recent changes exposing a missing clocksource.h include
in uv_nmi.c:
cc1e24fdb0 x86/vdso: Remove pvclock fixmap machinery
this file got clocksource.h indirectly via fixmap.h - that stealth route
of header inclusion is now gone.
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Now that pvclock doesn't require access to the fixmap, all vdso
variants can use it.
The kernel side isn't wired up for 32-bit kernels yet, but this
covers 32-bit and x32 userspace on 64-bit kernels.
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/a7ef693b7a4c88dd2173dc1d4bf6bc27023626eb.1449702533.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The pvclock vdso code was too abstracted to understand easily
and excessively paranoid. Simplify it for a huge speedup.
This opens the door for additional simplifications, as the vdso
no longer accesses the pvti for any vcpu other than vcpu 0.
Before, vclock_gettime using kvm-clock took about 45ns on my
machine. With this change, it takes 29ns, which is almost as
fast as the pure TSC implementation.
Signed-off-by: Andy Lutomirski <luto@amacapital.net>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/6b51dcc41f1b101f963945c5ec7093d72bdac429.1449702533.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This gets rid of the "did TSC go backwards" logic and just
updates all clocks. It should work better (no more disabling of
fast timing) and more reliably (all of the clocks are actually
updated).
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-mm@kvack.org
Link: http://lkml.kernel.org/r/861716d768a1da6d1fd257b7972f8df13baf7f85.1449702533.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Infrastructure:
- Revert "perf tools: Improve setting of gcc debug option", -Og is broken,
GCC PR created (Jiri Olsa)
- More reference count fixes (Masami Hiramatsu)
- Untangle browser setup (--stdio, --tui, etc) from argument checking,
prep work to move the usage() code out of tools/perf for use by
other tools/ living utilities (Namhyung Kim)
- Delete half-processed hist entries when exiting 'perf top' (Namhyung Kim)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWadUsAAoJENZQFvNTUqpAPkUP/A1JdGbSzgXAUhVO9uGxR8tP
fnJlvun8J/qjCzLNfzFBH/UkbHyBjNoXj+dt846HH9chJuzO9zI3Nn5bshcHIpHj
30Qu+K9eMtYchDRZc4wfLgT/ciatfn4bp6RTPZZzVJGKQyY7cxYydeEQnMqCYdJ5
LPkA76qAvESMOj47RrJEFO/L3VJb2cUcaG7WrDiKVLjSw6yWOCTX+ESVHnQX6QPx
LeUYNvmUht6ZtVMVG3xVnIMBYmNJDVjPimPtmqNCbn4J+gaAeSInYdVWRGn6BMCY
qm9OEZAOcDqRA2uKRQF/ytHalHQngJgoIfo6vI2KkyPcRptqS1LHy03qckYac3FV
Rsk+tHWa+tZmDlmnxILl7QSp2rDfc9npD+c9bYRfuScyGwdIaTfWhHCOIoqx6IdO
UB8Tlfmhx0m+2ffItKfx+U9UlMBDdkJfN7HMfqNObkSZ/oIRFcktyTOQAwxNkyoG
4iDBGJi4sUb2pKNnSZLytqB/75oQ5b5UiXyBuyaARO9eVIzZcZiK/E9nmZ5K6Evu
b2sc1XYZkthaAVxUu7yzI1y12rARQqefZJQJwJrzKRnBrAEYHLQ4H1bO4feh1BgM
7T3+4UZYAFBjio1WLgAlwc3SOYfqjNqAqQjct2RyLSamWJuRS2n9JY8y60Uns68h
OqTqhyO9XEMVMGed06Iv
=nr7K
-----END PGP SIGNATURE-----
Merge tag 'perf-core-for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core
Pull perf/core refactorings and fixes from Arnaldo Carvalho de Melo:
Infrastructure changes:
- Revert "perf tools: Improve setting of gcc debug option", -Og is broken,
GCC PR created (Jiri Olsa)
- More reference count fixes (Masami Hiramatsu)
- Untangle browser setup (--stdio, --tui, etc) from argument checking,
prep work to move the usage() code out of tools/perf for use by
other tools/ living utilities (Namhyung Kim)
- Delete half-processed hist entries when exiting 'perf top' (Namhyung Kim)
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
For adjtimex()'s ADJ_SETOFFSET, make sure the tv_usec value is
sane. We might multiply them later which can cause an overflow
and undefined behavior.
This patch introduces new helper functions to simplify the
checking code and adds comments to clarify
Orginally this patch was by Sasha Levin, but I've basically
rewritten it, so he should get credit for finding the issue
and I should get the blame for any mistakes made since.
Also, credit to Richard Cochran for the phrasing used in the
comment for what is considered valid here.
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
We need to make sure that the offset is valid before manipulating it,
otherwise it might overflow on the multiplication.
Cc: Sasha Levin <sasha.levin@oracle.com>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
[jstultz: Reworked one of the checks so it makes more sense]
Signed-off-by: John Stultz <john.stultz@linaro.org>
The function can return negative value.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
There are few defects in vga_get() related to signal hadning:
- we shouldn't check for pending signals for TASK_UNINTERRUPTIBLE
case;
- if we found pending signal we must remove ourself from wait queue
and change task state back to running;
- -ERESTARTSYS is more appropriate, I guess.
Signed-off-by: Kirill A. Shutemov <kirill@shutemov.name>
Cc: stable@vger.kernel.org
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
some big endian fixes and one regression fix.
* 'drm-fixes-4.4' of git://people.freedesktop.org/~agd5f/linux:
radeon: Fix VCE IB test on Big-Endian systems
radeon: Fix VCE ring test for Big-Endian systems
radeon/cik: Fix GFX IB test on Big-Endian
drm/amdgpu: fix the lost duplicates checking
Fix all the problems with the header files and userspace builds
off them. I really care so little about this, but hey who am
I to stop progress.
* 'drm-header-fixes' of https://github.com/GabrielL/linux: (30 commits)
drm: fix inclusion of drm.h in via_drm.h
drm: fix inclusion of drm.h in vmwgfx_drm.h
drm: fix inclusion of drm.h in virtgpu_drm.h
drm: fix inclusion of drm.h in tegra_drm.h
drm: fix inclusion of drm.h in savage_drm.h
drm: fix inclusion of drm.h in r128_drm.h
drm: fix inclusion of drm.h in qxl_drm.h
drm: fix inclusion of drm.h in omap_drm.h
drm: fix inclusion of drm.h in msm_drm.h
drm: fix inclusion of drm.h in mga_drm.h
drm: fix inclusion of drm.h in exynos_sarea.h
drm: fix inclusion of drm.h in i810_drm.h
drm: fix inclusion of drm.h in exynos_sarea.h
drm: fix inclusion of drm.h in drm_sarea.h
drm: drm_mode.h fix includes
drm: drm_fourcc.h fix includes
drm: include drm.h in armada_drm.h
include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from <linux/types.h>
drm: Kbuild: add admgpu_drm.h to the installed headers
drm: use __u{32,64} instead of uint{32,64}_t in virtgpu_drm.h
...
* pci/aspm:
PCI/ASPM: Make sysfs link_state_store() consistent with link_state_show()
* pci/hotplug:
PCI: pciehp: Always protect pciehp_disable_slot() with hotplug mutex
* pci/misc:
x86/PCI: Simplify pci_bios_{read,write}
PCI: Simplify config space size computation
PCI: Limit config space size for Netronome NFP6000 family
PCI: Add Netronome vendor and device IDs
PCI: Support PCIe devices with short cfg_size
x86/PCI: Clarify AMD Fam10h config access restrictions comment
PCI: Print warnings for all invalid expansion ROM headers
PCI: Check for PCI_HEADER_TYPE_BRIDGE equality, not bitmask
* pci/msi:
PCI/MSI: Remove empty pci_msi_init_pci_dev()
PCI/MSI: Initialize MSI capability for all architectures
There is some repetitive code in the switch/case statements in
pci_bios_read() and pci_bios_write(). Factor out the BIOS function
IDs and the result widths to simplify the code.
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Restructure the logic so we return the config space size as soon as we know
it. This reduces indentation, removes negations, and removes gotos.
No functional change.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
The NFP6000 has an erratum where reading/writing to PCI config space
addresses above 0x600 can cause the NFP to generate PCIe completion
timeouts.
Limit the NFP6000's config space size to 0x600 bytes.
Signed-off-by: Jason S. McMullan <jason.mcmullan@netronome.com>
[simon: edited changelog]
Signed-off-by: Simon Horman <simon.horman@netronome.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
