linux-stable.git/include/linux, branch v3.18.17

kernel: make READ_ONCE() valid on const arguments

2015-06-28T17:39:28+00:00

[ Upstream commit dd36929720f40f17685e841ae0d4c581c165ea60 ]

The use of READ_ONCE() causes lots of warnings witht he pending paravirt
spinlock fixes, because those ends up having passing a member to a
'const' structure to READ_ONCE().

There should certainly be nothing wrong with using READ_ONCE() with a
const source, but the helper function __read_once_size() would cause
warnings because it would drop the 'const' qualifier, but also because
the destination would be marked 'const' too due to the use of 'typeof'.

Use a union of types in READ_ONCE() to avoid this issue.

Also make sure to use parenthesis around the macro arguments to avoid
possible operator precedence issues.

Tested-by: Ingo Molnar 
Cc: Christian Borntraeger 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

[media] Add and use IS_REACHABLE macro

2015-06-28T17:39:23+00:00

[ Upstream commit 9b174527e7b756cda9f5d9e541f87b7fec9cfdf0 ]

In the media drivers, the v4l2 core knows about all submodules
and calls into them from a common function. However this cannot
work if the modules that get called are loadable and the
core is built-in. In that case we get

drivers/built-in.o: In function `set_type':
drivers/media/v4l2-core/tuner-core.c:301: undefined reference to `tea5767_attach'
drivers/media/v4l2-core/tuner-core.c:307: undefined reference to `tea5761_attach'
drivers/media/v4l2-core/tuner-core.c:349: undefined reference to `tda9887_attach'
drivers/media/v4l2-core/tuner-core.c:405: undefined reference to `xc4000_attach'

This was working previously, until the IS_ENABLED() macro was used
to replace the construct like

 #if defined(CONFIG_DVB_CX24110) || (defined(CONFIG_DVB_CX24110_MODULE) && defined(MODULE))

with the difference that the new code no longer checks whether it is being
built as a loadable module itself.

To fix this, this new patch adds an 'IS_REACHABLE' macro, which evaluates
true in exactly the condition that was used previously. The downside
of this is that this trades an obvious link error for a more subtle
runtime failure, but it is clear that the change that introduced the
link error was unintentional and it seems better to revert it for
now. Also, a similar change was originally created by Trent Piepho
and then reverted by teh change to the IS_ENABLED macro.

Ideally Kconfig would be used to avoid the case of a broken dependency,
or the code restructured in a way to turn around the dependency, but either
way would require much larger changes here.

Fixes: 7b34be71db53 ("[media] use IS_ENABLED() macro")
See-also: c5dec9fb248e ("V4L/DVB (4751): Fix DBV_FE_CUSTOMISE for card drivers compiled into kernel")

Signed-off-by: Arnd Bergmann 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin

jhash: Update jhash_[321]words functions to use correct initval

2015-06-28T17:39:22+00:00

[ Upstream commit 2e7056c433216f406b90a003aa0ba42e19d3bdcf ]

Looking over the implementation for jhash2 and comparing it to jhash_3words
I realized that the two hashes were in fact very different.  Doing a bit of
digging led me to "The new jhash implementation" in which lookup2 was
supposed to have been replaced with lookup3.

In reviewing the patch I noticed that jhash2 had originally initialized a
and b to JHASH_GOLDENRATIO and c to initval, but after the patch a, b, and
c were initialized to initval + (length << 2) + JHASH_INITVAL.  However the
changes in jhash_3words simply replaced the initialization of a and b with
JHASH_INITVAL.

This change corrects what I believe was an oversight so that a, b, and c in
jhash_3words all have the same value added consisting of initval + (length
<< 2) + JHASH_INITVAL so that jhash2 and jhash_3words will now produce the
same hash result given the same inputs.

Fixes: 60d509c823cca ("The new jhash implementation")
Signed-off-by: Alexander Duyck 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin

Driver core: Unified device properties interface for platform firmware

2015-06-28T17:39:20+00:00

[ Upstream commit b31384fa5de37a100507751dfb5c0a49d06cee67 ]

Add a uniform interface by which device drivers can request device
properties from the platform firmware by providing a property name
and the corresponding data type.  The purpose of it is to help to
write portable code that won't depend on any particular platform
firmware interface.

The following general helper functions are added:

device_property_present()
device_property_read_u8()
device_property_read_u16()
device_property_read_u32()
device_property_read_u64()
device_property_read_string()
device_property_read_u8_array()
device_property_read_u16_array()
device_property_read_u32_array()
device_property_read_u64_array()
device_property_read_string_array()

The first one allows the caller to check if the given property is
present.  The next 5 of them allow single-valued properties of
various types to be retrieved in a uniform way.  The remaining 5 are
for reading properties with multiple values (arrays of either numbers
or strings).

The interface covers both ACPI and Device Trees.

This change set includes material from Mika Westerberg and Aaron Lu.

Signed-off-by: Aaron Lu 
Signed-off-by: Mika Westerberg 
Acked-by: Greg Kroah-Hartman 
Acked-by: Grant Likely 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

ACPI: Add support for device specific properties

2015-06-28T17:39:20+00:00

[ Upstream commit ffdcd955c3078af3ce117edcfce80fde1a512bed ]

Device Tree is used in many embedded systems to describe the system
configuration to the OS. It supports attaching properties or name-value
pairs to the devices it describe. With these properties one can pass
additional information to the drivers that would not be available
otherwise.

ACPI is another configuration mechanism (among other things) typically
seen, but not limited to, x86 machines. ACPI allows passing arbitrary
data from methods but there has not been mechanism equivalent to Device
Tree until the introduction of _DSD in the recent publication of the
ACPI 5.1 specification.

In order to facilitate ACPI usage in systems where Device Tree is
typically used, it would be beneficial to standardize a way to retrieve
Device Tree style properties from ACPI devices, which is what we do in
this patch.

If a given device described in ACPI namespace wants to export properties it
must implement _DSD method (Device Specific Data, introduced with ACPI 5.1)
that returns the properties in a package of packages. For example:

	Name (_DSD, Package () {
		ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
		Package () {
			Package () {"name1", },
			Package () {"name2", },
			...
		}
	})

The UUID reserved for properties is daffd814-6eba-4d8c-8a91-bc9bbf4aa301
and is documented in the ACPI 5.1 companion document called "_DSD
Implementation Guide" [1], [2].

We add several helper functions that can be used to extract these
properties and convert them to different Linux data types.

The ultimate goal is that we only have one device property API that
retrieves the requested properties from Device Tree or from ACPI
transparent to the caller.

[1] http://www.uefi.org/sites/default/files/resources/_DSD-implementation-guide-toplevel.htm
[2] http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf

Reviewed-by: Hanjun Guo 
Reviewed-by: Josh Triplett 
Reviewed-by: Grant Likely 
Signed-off-by: Darren Hart 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

sched: Handle priority boosted tasks proper in setscheduler()

2015-06-10T17:42:31+00:00

[ Upstream commit 0782e63bc6fe7e2d3408d250df11d388b7799c6b ]

Ronny reported that the following scenario is not handled correctly:

	T1 (prio = 10)
	   lock(rtmutex);

	T2 (prio = 20)
	   lock(rtmutex)
	      boost T1

	T1 (prio = 20)
	   sys_set_scheduler(prio = 30)
	   T1 prio = 30
	   ....
	   sys_set_scheduler(prio = 10)
	   T1 prio = 30

The last step is wrong as T1 should now be back at prio 20.

Commit c365c292d059 ("sched: Consider pi boosting in setscheduler()")
only handles the case where a boosted tasks tries to lower its
priority.

Fix it by taking the new effective priority into account for the
decision whether a change of the priority is required.

Reported-by: Ronny Meeus 
Tested-by: Steven Rostedt 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Reviewed-by: Steven Rostedt 
Cc: 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Mike Galbraith 
Fixes: c365c292d059 ("sched: Consider pi boosting in setscheduler()")
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1505051806060.4225@nanos
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

libata: Ignore spurious PHY event on LPM policy change

2015-06-10T17:42:26+00:00

[ Upstream commit 09c5b4803a80a5451d950d6a539d2eb311dc0fb1 ]

When the LPM policy is set to ATA_LPM_MAX_POWER, the device might
generate a spurious PHY event that cuases errors on the link.
Ignore this event if it occured within 10s after the policy change.

The timeout was chosen observing that on a Dell XPS13 9333 these
spurious events can occur up to roughly 6s after the policy change.

Link: http://lkml.kernel.org/g/3352987.ugV1Ipy7Z5@xps13
Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

libata: Add helper to determine when PHY events should be ignored

2015-06-10T17:42:26+00:00

[ Upstream commit 8393b811f38acdf7fd8da2028708edad3e68ce1f ]

This is a preparation commit that will allow to add other criteria
according to which PHY events should be dropped.

Signed-off-by: Gabriele Mazzotta 
Signed-off-by: Tejun Heo 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

ktime: Fix ktime_divns to do signed division

2015-06-09T17:43:50+00:00

[ Upstream commit f7bcb70ebae0dcdb5a2d859b09e4465784d99029 ]

It was noted that the 32bit implementation of ktime_divns()
was doing unsigned division and didn't properly handle
negative values.

And when a ktime helper was changed to utilize
ktime_divns, it caused a regression on some IR blasters.
See the following bugzilla for details:
  https://bugzilla.redhat.com/show_bug.cgi?id=1200353

This patch fixes the problem in ktime_divns by checking
and preserving the sign bit, and then reapplying it if
appropriate after the division, it also changes the return
type to a s64 to make it more obvious this is expected.

Nicolas also pointed out that negative dividers would
cause infinite loops on 32bit systems, negative dividers
is unlikely for users of this function, but out of caution
this patch adds checks for negative dividers for both
32-bit (BUG_ON) and 64-bit(WARN_ON) versions to make sure
no such use cases creep in.

[ tglx: Hand an u64 to do_div() to avoid the compiler warning ]

Fixes: 166afb64511e 'ktime: Sanitize ktime_to_us/ms conversion'
Reported-and-tested-by: Trevor Cordes 
Signed-off-by: John Stultz 
Acked-by: Nicolas Pitre 
Cc: Ingo Molnar 
Cc: Josh Boyer 
Cc: One Thousand Gnomes 
Cc: 
Link: http://lkml.kernel.org/r/1431118043-23452-1-git-send-email-john.stultz@linaro.org
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sasha Levin

ktime: Optimize ktime_divns for constant divisors

2015-06-09T17:43:49+00:00

[ Upstream commit 8b618628b2bf83512fc8df5e8672619d65adfdfb ]

At least on ARM, do_div() is optimized to turn constant divisors into
an inline multiplication by the reciprocal value at compile time.
However this optimization is missed entirely whenever ktime_divns() is
used and the slow out-of-line division code is used all the time.

Let ktime_divns() use do_div() inline whenever the divisor is constant
and small enough.  This will make things like ktime_to_us() and
ktime_to_ms() much faster.

Cc: Arnd Bergmann 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Nicolas Pitre 
Acked-by: Arnd Bergmann 
Signed-off-by: Nicolas Pitre 
Signed-off-by: John Stultz 
Signed-off-by: Sasha Levin