linux-stable.git/drivers/base, branch v3.18.26

mm: check if section present during memory block registering

2015-10-28T02:14:54+00:00

[ Upstream commit 04697858d89e4bf2650364f8d6956e2554e8ef88 ]

Tony Luck found on his setup, if memory block size 512M will cause crash
during booting.

  BUG: unable to handle kernel paging request at ffffea0074000020
  IP: get_nid_for_pfn+0x17/0x40
  PGD 128ffcb067 PUD 128ffc9067 PMD 0
  Oops: 0000 [#1] SMP
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc8 #1
  ...
  Call Trace:
     ? register_mem_sect_under_node+0x66/0xe0
     register_one_node+0x17b/0x240
     ? pci_iommu_alloc+0x6e/0x6e
     topology_init+0x3c/0x95
     do_one_initcall+0xcd/0x1f0

The system has non continuous RAM address:
 BIOS-e820: [mem 0x0000001300000000-0x0000001cffffffff] usable
 BIOS-e820: [mem 0x0000001d70000000-0x0000001ec7ffefff] usable
 BIOS-e820: [mem 0x0000001f00000000-0x0000002bffffffff] usable
 BIOS-e820: [mem 0x0000002c18000000-0x0000002d6fffefff] usable
 BIOS-e820: [mem 0x0000002e00000000-0x00000039ffffffff] usable

So there are start sections in memory block not present.  For example:

    memory block : [0x2c18000000, 0x2c20000000) 512M

first three sections are not present.

The current register_mem_sect_under_node() assume first section is
present, but memory block section number range [start_section_nr,
end_section_nr] would include not present section.

For arch that support vmemmap, we don't setup memmap for struct page
area within not present sections area.

So skip the pfn range that belong to absent section.

[akpm@linux-foundation.org: simplification]
[rientjes@google.com: more simplification]
Fixes: bdee237c0343 ("x86: mm: Use 2GB memory block size on large memory x86-64 systems")
Fixes: 982792c782ef ("x86, mm: probe memory block size for generic x86 64bit")
Signed-off-by: Yinghai Lu 
Signed-off-by: David Rientjes 
Reported-by: Tony Luck 
Tested-by: Tony Luck 
Cc: Greg KH 
Cc: Ingo Molnar 
Tested-by: David Rientjes 
Cc: 	[3.15+]
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 

Signed-off-by: Sasha Levin

drivercore: Fix unregistration path of platform devices

2015-10-28T02:14:53+00:00

[ Upstream commit 7f5dcaf1fdf289767a126a0a5cc3ef39b5254b06 ]

The unregister path of platform_device is broken. On registration, it
will register all resources with either a parent already set, or
type==IORESOURCE_{IO,MEM}. However, on unregister it will release
everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There
are also cases where resources don't get registered in the first place,
like with devices created by of_platform_populate()*.

Fix the unregister path to be symmetrical with the register path by
checking the parent pointer instead of the type field to decide which
resources to unregister. This is safe because the upshot of the
registration path algorithm is that registered resources have a parent
pointer, and non-registered resources do not.

* It can be argued that of_platform_populate() should be registering
  it's resources, and they argument has some merit. However, there are
  quite a few platforms that end up broken if we try to do that due to
  overlapping resources in the device tree. Until that is fixed, we need
  to solve the immediate problem.

Cc: Pantelis Antoniou 
Cc: Wolfram Sang 
Cc: Rob Herring 
Cc: Greg Kroah-Hartman 
Cc: Ricardo Ribalda Delgado 
Signed-off-by: Grant Likely 
Tested-by: Ricardo Ribalda Delgado 
Tested-by: Wolfram Sang 
Cc: stable@vger.kernel.org
Signed-off-by: Rob Herring 
Signed-off-by: Sasha Levin

devres: fix devres_get()

2015-10-28T02:14:48+00:00

[ Upstream commit 64526370d11ce8868ca495723d595b61e8697fbf ]

Currently, devres_get() passes devres_free() the pointer to devres,
but devres_free() should be given with the pointer to resource data.

Fixes: 9ac7849e35f7 ("devres: device resource management")
Signed-off-by: Masahiro Yamada 
Acked-by: Tejun Heo 
Cc: stable  # 2.6.21+
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

regmap: debugfs: Don't bother actually printing when calculating max length

2015-10-28T02:14:04+00:00

[ Upstream commit 176fc2d5770a0990eebff903ba680d2edd32e718 ]

The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.

Reported-by: Rasmus Villemoes 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

regmap: debugfs: Ensure we don't underflow when printing access masks

2015-10-28T02:14:03+00:00

[ Upstream commit b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 ]

If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.

Reported-by: Rasmus Villemoes 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

regmap: regcache-rbtree: Clean new present bits on present bitmap resize

2015-09-17T05:29:53+00:00

[ Upstream commit 8ef9724bf9718af81cfc5132253372f79c71b7e2 ]

When inserting a new register into a block, the present bit map size is
increased using krealloc. krealloc does not clear the additionally
allocated memory, leaving it filled with random values. Result is that
some registers are considered cached even though this is not the case.

Fix the problem by clearing the additionally allocated memory. Also, if
the bitmap size does not increase, do not reallocate the bitmap at all
to reduce overhead.

Fixes: 3f4ff561bc88 ("regmap: rbtree: Make cache_present bitmap per node")
Signed-off-by: Guenter Roeck 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

Fix firmware loader uevent buffer NULL pointer dereference

2015-08-04T18:43:38+00:00

[ Upstream commit 6f957724b94cb19f5c1c97efd01dd4df8ced323c ]

The firmware class uevent function accessed the "fw_priv->buf" buffer
without the proper locking and testing for NULL.  This is an old bug
(looks like it goes back to 2012 and commit 1244691c73b2: "firmware
loader: introduce firmware_buf"), but for some reason it's triggering
only now in 4.2-rc1.

Shuah Khan is trying to bisect what it is that causes this to trigger
more easily, but in the meantime let's just fix the bug since others are
hitting it too (at least Ingo reports having seen it as well).

Reported-and-tested-by: Shuah Khan 
Acked-by: Ming Lei 
Cc: Greg Kroah-Hartman 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

regmap: Fix possible shift overflow in regmap_field_init()

2015-07-04T03:02:31+00:00

[ Upstream commit 921cc29473a0d7c109105c1876ddb432f4a4be7d ]

The way the mask is generated in regmap_field_init() is wrong.
Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift
overflow while calculating the mask field.

On some 32 bits architectures, such as x86, the generated mask is 0,
instead of the expected 0xffffffff.

This patch uses GENMASK() to fix the problem, as this macro is already safe
regarding shift overflow.

Signed-off-by: Maxime Coquelin 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin

regmap: Fix regmap_bulk_read in BE mode

2015-07-04T03:02:30+00:00

[ Upstream commit 15b8d2c41fe5839582029f65c5f7004db451cc2b ]

In big endian mode regmap_bulk_read gives incorrect data
for byte reads.

This is because memcpy of a single byte from an address
after full word read gives different results when
endianness differs. ie. we get little-end in LE and big-end in BE.

Signed-off-by: Arun Chandran 
Signed-off-by: Mark Brown 
Cc: stable@vger.kernel.org
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