As the last user of the pm_genpd_poweroff_unused() API has moved into
relying on genpd to deal with this internally from a late_initcall, let's
remove the API.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit ba2bbfbf ("PM / Domains: Remove intermediate states..") changed
the power off sequence (pm_genpd_poweroff()), which from locking point of
view means the genpd mutex is held throughout the sequence.

The above change means the in_progress counter can't be updated while
pm_genpd_poweroff() is executing, which allows us to remove the counter.

Instead we inform pm_genpd_poweroff() via a bool parameter, to indicate
whether we call it from the scheduled work or from the ->runtime_suspend()
callback, since that all that matters.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NLina Iyer <lina.iyer@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Drop the "out" label in __pm_genpd_poweron() that's not used any more.
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The power domains code allows to tie a cpuidle state with a power domain.

Preventing the cpuidle framework to enter a specific idle state by disabling
from the power domain framework is a good idea. Unfortunately, the current
implementation has some gaps with a SMP system and a complex cpuidle
implementation. Enabling a power domain wakes up all the cpus even if a cpu
does not belong to the power domain.

There is some work to do a logical representation with the power domains of
the hardware dependencies (eg. a cpu belongs to a power domains, these power
domains belong to a higher power domain for a cluster, etc ...). A new code
relying on the genpd hierarchy to disable the idle states would make more
sense.

As the unique user of this code has been removed, let's wipe out this code
to prevent new user and to have a clean place to put a new implementation.
Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

As all users of the named based APIs now have converted to the non-named
based APIs, the time has come to remove them.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The current implementation of platform MSI caches the msi_desc
pointer in irq_data::handler_data. This is a bit silly, as
we also have irq_data::msi_desc, which is perfectly valid.

Remove the useless assignment and simplify the whole flow.
Reported-by: NMa Jun <majun258@huawei.com>
Signed-off-by: NMarc Zyngier <marc.zyngier@arm.com>
Reviewed-by: NJiang Liu <jiang.liu@linux.intel.com>
Link: http://lkml.kernel.org/r/1442147824-20971-1-git-send-email-marc.zyngier@arm.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>

There is no point returning suspend_opp, if it is disabled by the core.
As we can't use it at all. Fix it.

Fixes: 4eafbd15 ("PM / OPP: add dev_pm_opp_get_suspend_opp() helper")
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Add dev_pm_opp_get_suspend_opp() helper to obtain suspend opp.
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The function device_get_mac_address is trying different property names
in order to get the mac address. To check the return value, the variable
addr (which contain the buffer pass by the caller) will be re-used. This
means that if the previous property is not found, the next property will
be read using a NULL buffer.

Therefore it's only possible to retrieve the mac if node contains a
property "mac-address". Fix it by using a temporary buffer for the
return value.

This has been introduced by commit 4c96b7dc
"Add a matching set of device_ functions for determining mac/phy"
Signed-off-by: NJulien Grall <julien.grall@citrix.com>
Cc: Jeremy Linton <jeremy.linton@arm.com>
Cc: David S. Miller <davem@davemloft.net>
Reviewed-by: NJeremy Linton <jeremy.linton@arm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The function pm_genpd_remove_subdomain() removes a subdomain from a
generic PM domain, however, it does not check if the subdomain has any
slave domains or device attached before doing so. Therefore, add a test
to verify that the subdomain does not have any slave domains associated
or any device attached before removing.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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: bdee237c ("x86: mm: Use 2GB memory block size on large memory x86-64 systems")
Fixes: 982792c7 ("x86, mm: probe memory block size for generic x86 64bit")
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NDavid Rientjes <rientjes@google.com>
Reported-by: NTony Luck <tony.luck@intel.com>
Tested-by: NTony Luck <tony.luck@intel.com>
Cc: Greg KH <greg@kroah.com>
Cc: Ingo Molnar <mingo@elte.hu>
Tested-by: NDavid Rientjes <rientjes@google.com>
Cc: <stable@vger.kernel.org>	[3.15+]
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

While powering up a genpd, its domain masters are first being powered up.
In the error path of __pm_genpd_poweron(), we didn't care to try power off
these domain masters. Let's deal with that to avoid leaving unused PM
domains powered.
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Reviewed-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

__regmap_init() may receive a NULL `struct regmap_bus *bus' pointer,
for example, from snd_hdac_regmap_init(), and it make sure that it
does not NULL deference `bus`, except around ->max_raw_read and
->max_raw_write initialisation. Add missing check.
Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

When doing a bulk read from a device which lacks raw I/O support we fall
back to doing register at a time reads but we still use the raw
formatters in order to render the data into the word size used by the
device (since bulk reads still operate on the device word size rather
than unsigned ints).  This means that devices without raw formatting
such as those that provide reg_read() are not supported.  Provide
handling for them by copying the values read into native endian values
of the appropriate size.
Signed-off-by: NMark Brown <broonie@kernel.org>

This allows to read/write up to 32 bytes of data and is to be prefered
if supported before the register read/write smbus support.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Check in regmap_raw_read() and regmap_raw_write() for correct maximum
sizes of the operations. Return -E2BIG if this size is not supported
because it is too big.

Also this patch causes an uninitialized variable warning so it
initializes ret (although not necessary).
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add functions to access the maximum size we can read/write using
regmap_raw_read/write().

This helps drivers that need to know how much they can write with the
raw functions without problems. There are some devices (e.g. bmc150)
that have fifos as registers which need to be read in specific chunks
otherwise samples are dropped.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

There are some buses which have a limit on the maximum number of bytes
that can be send/received. An example for this is
I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of more
than 32 bytes. The regmap_bulk operations should still be able to
utilize the full 32 bytes in this case.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The function genpd_dev_pm_detach() detaches a device from a PM domain,
however, in the description, the "dev" argument for the function is
described as the device to "attach" instead of "detach". Correct this.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Export symbol pm_genpd_init so it can be used in loadable
kernel modules
Signed-off-by: NRajendra Nayak <rnayak@codeaurora.org>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

"domain": header is indented by 4, data by 0 spaces => 0 spaces
"/device": header is indented by 11, data by 4 spaces => 4 spaces
"slaves": header is indented by 47, data by 49 spaces => 48 spaces

Ruler:
    1234567890123456789012345678901234567890123456789012345678901234567890

Before:

	domain                      status         slaves
	       /device                                      runtime status
    ----------------------------------------------------------------------
    a3sp                            on               a2us
	/devices/platform/e60b0000.i2c                      suspended

After:

    domain                          status          slaves
	/device                                             runtime status
    ----------------------------------------------------------------------
    a3sp                            on              a2us
	/devices/platform/e60b0000.i2c                      suspended
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NKevin Hilman <khilman@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

IS_ERR(_OR_NULL) already contain an 'unlikely' compiler flag and there
is no need to do that again from its callers. Drop it.
Acked-by: NPavel Machek <pavel@ucw.cz>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Dan Carpenter reported (generated with static checker):

drivers/base/power/opp.c:949 _opp_add_static_v2()
warn: passing casted pointer '&new_opp->clock_latency_ns' to
'of_property_read_u32()' 64 vs 32.

This code will break on 64 bit, big endian machines.

Fix this by reading the value in a u32 type variable first and then
assigning it to the unsigned long variable.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Suggested-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

_of_init_opp_table_v2() isn't freeing up resources on some errors and
the error values returned are also not correct always.

This fixes following problems:
- Return -ENOENT, if no entries are found in the table.
- Use IS_ERR() to properly check return value of _find_device_opp().
- Return error value with PTR_ERR() in above case.
- Free table if _find_device_opp() fails.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Return -ENXIO if device property array access functions don't find
a suitable firmware interface.

This lets drivers decide if they should use available platform data
instead.

Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Tested-by: NJeremy Linton <jeremy.linton@arm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The one string as an equivalent to an array of one element. Allow user to read
one string as a plain string.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

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 <pantelis.antoniou@konsulko.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGrant Likely <grant.likely@linaro.org>
Tested-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
Cc: stable@vger.kernel.org
Signed-off-by: NRob Herring <robh@kernel.org>

There is no multi_write support available if we cannot use raw_write.
This is the case if bus->write is not implemented.

This patch adds a condition that we need bus and bus->write so that
can_multi_write is true.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

use_single_rw currently reflects the capabilities of the connected
device. The capabilities of the bus are currently missing for this
variable.

As there are read only and write only buses we need seperate values for
use_single_rw to also reflect tha capabilities of the bus.

This patch splits use_single_rw into use_single_read and
use_single_write. The initialization is changed to check the
configuration for use_single_rw and to check the capabilities of the
used bus.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

The regmap config does not prohibit val_bytes that are not powers of
two. But the current code of regmap_bulk_write for use_single_rw does
limit the possible val_bytes to 1, 2 and 4.

This patch fixes the behaviour to allow bus writes with non-standard
val_bytes sizes.

Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch adds MAC address length check back into
the device_get_mac_addr() function before calling
is_valid_ether_addr() similar to the way the OF
routine does it.

Update the comments for the two new functions.
Signed-off-by: NJeremy Linton <jeremy.linton@arm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Return -ENOTSUPP if map->bus->read is not implemented and we do not use
the cache. This code path would directly use bus->read would run into an
NULL pointer for the read function.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

This function is missing a check if map->bus->write is implemented. If
it is not implemented arbitrary raw writes are not possible.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

OF has some helper functions for parsing MAC and PHY settings.
In cases where the platform is providing this information rather
than the device itself, there needs to be similar functions for ACPI.

These functions are slightly modified versions of the ones in
of_net which can use information provided via DT or ACPI.
Signed-off-by: NJeremy Linton <jeremy.linton@arm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There are two typos in drivers/base/regmap/regmap.c, and they may
introduce some noise when checking new patches.
Signed-off-by: NXiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

These values are defined as unsigned int in the struct and are assigned
to int values.

This patch fixes the type to be unsigned int instead.
Signed-off-by: NMarkus Pargmann <mpa@pengutronix.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

Init functions defined in regmap*.c files are now prefixed with
__, take lockdep key and class parameters, and should not be
called directly: move the documentation to regmap.h, where the
macros are defined.
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Lockdep validator complains about recursive locking and deadlock
when two different regmap instances are called in a nested order.
That happens anytime a regmap read/write call needs to access
another regmap.

This is because, for performance reason, lockdep groups all locks
initialized by the same mutex_init() in the same lock class.
Therefore all regmap mutexes are in the same lock class, leading
to lockdep "nested locking" warnings if a regmap accesses another
regmap.

In general, it is impossible to establish in advance the hierarchy
of regmaps, so we make sure that each regmap init call initializes
its own static lock_class_key. This is done by wrapping all
regmap_init calls into macros.

This also allows us to give meaningful names to the lock_class_key.
For example, in rt5677 case, we have in /proc/lockdep_chains:
irq_context: 0
[ffffffc0018d2198] &dev->mutex
[ffffffc0018d2198] &dev->mutex
[ffffffc001bd7f60] rt5677:5104:(&rt5677_regmap)->_lock
[ffffffc001bd7f58] rt5677:5096:(&rt5677_regmap_physical)->_lock
[ffffffc001b95448] &(&base->lock)->rlock

The above would have resulted in a lockdep recursive warning
previously. This is not the case anymore as the lockdep validator
now clearly identifies the 2 regmaps as separate.
Signed-off-by: NNicolas Boichat <drinkcat@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

IS_ENABLED should only be used for CONFIG_* symbols.

I have done a small test:
  #define REGMAP_ALLOW_WRITE_DEBUGFS
  IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.

  #define REGMAP_ALLOW_WRITE_DEBUGFS 0
  IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.

  #define REGMAP_ALLOW_WRITE_DEBUGFS 1
  IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 1.

  #define REGMAP_ALLOW_WRITE_DEBUGFS 2
  IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.

So fix the misuse of IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) and switch to
use #if defined(REGMAP_ALLOW_WRITE_DEBUGFS) instead.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

Add dev_pm_opp_is_turbo() helper to verify if an opp is to be used only
for turbo mode or not.
Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NBartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>