This allows the OPP core to request/free the regulator resource,
attached to a device OPP. The regulator device is fetched using the name
provided by the driver, while calling: dev_pm_opp_set_regulator().
This will work for both OPP-v1 and v2 bindings.
This is a preliminary step for moving the OPP switching logic into the
OPP core.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 9f8ea969d5)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
gcc warns quite a bit about values returned from allocate_resources()
in cpufreq-dt.c:
cpufreq-dt.c: In function 'cpufreq_init':
cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this function [-Werror=maybe-uninitialized]
cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here
cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here
cpufreq-dt.c: In function 'dt_cpufreq_probe':
cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here
The problem is that it's slightly hard for gcc to follow return
codes across PTR_ERR() calls.
This patch uses explicit assignments to the "ret" variable to make
it easier for gcc to verify that the code is actually correct,
without the need to add a bogus initialization.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit b331bc20d9)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
sprintf() can access memory outside of the range of the character array,
and is risky in some situations. The driver specified prop_name string
can be longer than NAME_MAX here (only an attacker will do that though)
and so blindly copying it into the character array of size NAME_MAX
isn't safe. Instead we must use snprintf() here.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 5ff24d6010)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
Set cpu_dev->id in cpumask first when setting up cpumask for CPUs that
share the same OPP table. This might be helpful when handling cpumask
without the original CPU bitfield set.
Signed-off-by: Pi-Cheng Chen <pi-cheng.chen@linaro.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit d9de19b1cc)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
Commit 01fb4d3c39 ("PM / OPP: Parse 'opp-<prop>-<name>'
bindings") broke support for parsing standard opp-microvolt and
opp-microamp properties. Fix it by setting 'name' string to
proper value for !prop cases.
Fixes: 01fb4d3c39 ("PM / OPP: Parse 'opp-<prop>-<name> 'bindings")
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit fd8d8e6346)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
OPP bindings (for few properties) allow a platform to choose a
value/range among a set of available options. The options are present as
opp-<prop>-<name>, where the platform needs to supply the <name> string.
The OPP properties which allow such an option are: opp-microvolt and
opp-microamp.
Add support to the OPP-core to parse these bindings, by introducing
dev_pm_opp_{set|put}_prop_name() APIs.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 01fb4d3c39)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
OPP bindings allow a platform to enable OPPs based on the version of the
hardware they are used for.
Add support to the OPP-core to parse these bindings, by introducing
dev_pm_opp_{set|put}_supported_hw() APIs.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 7de36b0aa5)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
It would be better to name OPP nodes as opp@<opp-hz> as that will ensure
that multiple DT nodes don't contain the same frequency. Of course we
expect the writer to name the node with its opp-hz frequency and not any
other frequency.
And that will let the compile error out if multiple nodes are using the
same opp-hz frequency.
Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 754dcf35f3)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
These aren't used until now by any DT files and wouldn't be used now as
we have a better scheme in place now, i.e. opp-property-<name>
properties.
Remove the (useless) binding without breaking ABI.
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit af87a39a5f)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
Depending on the version of hardware or its properties, which are only
known at runtime, various properties of the OPP can change. For example,
an OPP with frequency 1.2 GHz, may have different voltage/current
requirements based on the version of the hardware it is running on.
In order to not replicate the same OPP tables for varying values of all
such fields, this commit introduces the concept of opp-property-<name>.
The <name> can be chosen by the platform at runtime, and OPPs will be
initialized depending on that name string. Currently support is extended
for the following properties:
- opp-microvolt-<name>
- opp-microamp-<name>
If the name string isn't provided by the platform, or if it is provided
but doesn't match the properties present in the OPP node, we will fall
back to the original properties without the -<name> string, if they are
available.
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit ffdb8cc7a2)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
We may want to enable only a subset of OPPs, from the bigger list of
OPPs, based on what version of the hardware we are running on. This
would enable us to not duplicate OPP tables for every version of the
hardware we support.
To enable that, this patch defines a new property 'opp-supported-hw'. It
can support any number of hierarchy levels of the versions the hardware
follows. And based on the selected hardware versions, we can pick only
the relevant OPPs at runtime.
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 1c4d12de27)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
This patch adds debugfs support to OPP layer to export OPPs and their
properties for all the devices.
This creates a top level directory: /sys/kernel/debug/opp and then
device specific directories (based on device names) inside it. For
example: 'cpu0', 'cpu1', etc..
If multiple devices share the OPP table, then the real directory is
created only for the first device. For all others, links are created to
the real directory.
Inside the device specific directory, a separate directory is created
for each OPP. And within that files per opp property.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit deaa514651)
Signed-off-by: Alex Shi <alex.shi@linaro.org>
When CONFIG_MMC_SIMULATE_MAX_SPEED is enabled, Expose max_read_speed,
max_write_speed and cache_size default module parameters and sysfs
controls to simulate a slow eMMC device. Default values are 0 (off),
0 (off) and 4 MB respectively.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 26976972
Change-Id: I342bfbd8b85f9b790e3f0e1e4e51a900ae07e05d
cpufreq_interactive_speedchange_task() is running as a separate kernel
thread and is calling __cpufreq_driver_target(), which requires callers
to hold policy->rwsem for writing to prevent racing with other parts of
the kernel trying to adjust the frequency, for example kernel thermal
throttling. Let's change the code to take policy->rwsem and while at it
refactor the code a bit.
This was originally 2 changes reviewed at:
https://chromium-review.googlesource.com/246273https://chromium-review.googlesource.com/256120
Change-Id: Icc2d97c6c1b929acd2ee32e8c81d81fd2af778ab
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Reviewed-by: Dylan Reid <dgreid@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Dmitry Torokhov <dtor@google.com>
Add a sysfs entry that allows user space to determine whether dm-verity
has come across correctable errors on the underlying block device.
Bug: 22655252
Bug: 27928374
Change-Id: I80547a2aa944af2fb9ffde002650482877ade31b
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
(cherry picked from commit 7911fad5f0a2cf5afc2215657219a21e6630e001)
If ignore_zero_blocks is enabled dm-verity will return zeroes for blocks
matching a zero hash without validating the content.
Change-Id: I728fa4b2586b29f2793ea5cb014289892819d249
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit 0cc37c2df4)
Add support for correcting corrupted blocks using Reed-Solomon.
This code uses RS(255, N) interleaved across data and hash
blocks. Each error-correcting block covers N bytes evenly
distributed across the combined total data, so that each byte is a
maximum distance away from the others. This makes it possible to
recover from several consecutive corrupted blocks with relatively
small space overhead.
In addition, using verity hashes to locate erasures nearly doubles
the effectiveness of error correction. Being able to detect
corrupted blocks also improves performance, because only corrupted
blocks need to corrected.
For a 2 GiB partition, RS(255, 253) (two parity bytes for each
253-byte block) can correct up to 16 MiB of consecutive corrupted
blocks if erasures can be located, and 8 MiB if they cannot, with
16 MiB space overhead.
Change-Id: Ife4f8889f7fbf0974bf3ed4be6d3322ae9b4cb0e
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit a739ff3f54)
verity_for_bv_block() will be re-used by optional dm-verity object.
Change-Id: I80e0f8e7c9f234fce3fbdf21cb05aba3041d7f98
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit bb4d73ac5e)
Prepare for an optional verity object to make use of existing dm-verity
structures and functions.
Change-Id: Ib14c3834bfed222b33e068908fb5f71a53e1187b
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit ffa393807c)
Prepare for extending dm-verity with an optional object. Follows the
naming convention used by other DM targets (e.g. dm-cache and dm-era).
Change-Id: If6d2f27b290adf14fa77f3745fdc13aaa417c8dc
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit 03045cbafa)
Move optional argument parsing into a separate function to make it
easier to add more of them without making verity_ctr even longer.
Change-Id: I9cd9df41c3326824f8cca5764075501987e78a52
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit 753c1fd028)
Handle dm-verity salting in one place to simplify the code.
Change-Id: If923a01dc63ae5123af13ba1b0863b73e33ddf46
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit 6dbeda3469)
Device mapper used the field bi_private to point to dm_target_io. However,
since kernel 3.15, the bi_private field is unused, and so the targets do
not need to save and restore this field.
This patch removes code that saves and restores bi_private from dm-cache,
dm-snapshot and dm-verity.
Change-Id: Ic72905ccb6d58ff94eafaa47ba54b2688d92d3d1
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
(cherry picked from commit fe3265b180)
The 0-day build bot reports the following build error, seen if SDCARD_FS
is built as module.
ERROR: "do_munmap" undefined!
Fixes: 84a1b7d3d3 ("Included sdcardfs source code for kernel 3.0")
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
The 0-day build bot reports the following build error, seen if SDCARD_FS
is built as module.
ERROR: "d_absolute_path" undefined!
Fixes: 84a1b7d3d3 ("Included sdcardfs source code for kernel 3.0")
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
CONFIG_SDCARD_FS_CI_SEARCH only guards a define for
LOOKUP_CASE_INSENSITIVE, which is never used in the
kernel. Remove both, along with the option matching
that supports it.
Change-Id: I363a8f31de8ee7a7a934d75300cc9ba8176e2edf
Signed-off-by: Daniel Rosenberg <drosen@google.com>
Patch "vfs: add d_canonical_path for stacked filesystem support"
erroneously updated the ALL_INOTIFY_BITS count. This changes it back
Change-Id: Idb04edc736da276159d30f04c40cff9d6b1e070f
Attempts to build sdcardfs as module fail with
fs/sdcardfs/lookup.c: In function '__sdcardfs_lookup':
fs/sdcardfs/lookup.c:243:5: error: 'LOOKUP_CASE_INSENSITIVE' undeclared
This occurs because the define is enclosed with #ifdef
CONFIG_SDCARD_FS_CI_SEARCH. If SDCARD_FS_CI_SEARCH is configured to be
built as module, this does not work. Alternatives would be to use #if
IS_ENABLED(CONFIG_SDCARD_FS_CI_SEARCH), or to declare SDCARD_FS_CI_SEARCH
as bool, but that does not work because the define is used unconditionally
in the source.
Note that LOOKUP_CASE_INSENSITIVE is only set but not evaluated in the
current source code, so setting the flag has no real effect.
Fixes: 84a1b7d3d3 ("Included sdcardfs source code for kernel 3.0")
Cc: Daniel Rosenberg <drosen@google.com>
Signed-off-by: Guenter Roeck <groeck@chromium.org>
Inotify does not currently know when a filesystem
is acting as a wrapper around another fs. This means
that inotify watchers will miss any modifications to
the base file, as well as any made in a separate
stacked fs that points to the same file.
d_canonical_path solves this problem by allowing the fs
to map a dentry to a path in the lower fs. Inotify
can use it to find the appropriate place to watch to
be informed of all changes to a file.
Change-Id: I09563baffad1711a045e45c1bd0bd8713c2cc0b6
Signed-off-by: Daniel Rosenberg <drosen@google.com>
In M, the workings of sdcardfs were changed significantly.
This brings sdcardfs into line with the changes.
Change-Id: I10e91a84a884c838feef7aa26c0a2b21f02e052e
Fixed existing type-casting in packagelist management code. All
warnings at compile time were taken care of.
Change-Id: I1ea97786d1d1325f31b9f09ae966af1f896a2af5
Signed-off-by: Daniel Campello <campello@google.com>
Only included the source code as is for kernel 3.0. Following patches
take care of porting this file system to version 3.10.
Change-Id: I09e76db77cd98a059053ba5b6fd88572a4b75b5b
Signed-off-by: Daniel Campello <campello@google.com>
When userspace unbinds gadget functions through configfs, the
.free_func() callback is always invoked. (in config_usb_cfg_unlink())
Implement it as a no-op to avoid the following crash:
[ 68.125679] configfs-gadget gadget: unbind function 'accessory'/ffffffc0720bf000
[ 68.133202] configfs-gadget gadget: unbind function 'audio_source'/ffffffc0012ca3c0
[ 68.142668] tegra-xudc 700d0000.usb-device: ep 0 disabled
[ 68.148186] Bad mode in Synchronous Abort handler detected, code 0x86000006
[ 68.155144] CPU: 2 PID: 1 Comm: init Tainted: G U W 3.18.0-09419-g87296c3-dirty #561
[ 68.163743] Hardware name: Google Tegra210 Smaug Rev 1,3+ (DT)
[ 68.169566] task: ffffffc0bc8d0000 ti: ffffffc0bc8bc000 task.ti: ffffffc0bc8bc000
[ 68.177039] PC is at 0x0
[ 68.179577] LR is at usb_put_function+0x14/0x1c
....
BUG=chrome-os-partner:49140
TEST="setprop sys.usb.config accessory,audio_source" on A44 and then
switch back to default: "setprop sys.usb.config mtp,adb", no crash will
be seen.
Change-Id: I5b6141964aab861e86e3afb139ded02d4d122dab
Signed-off-by: Mark Kuo <mkuo@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/321013
Commit-Ready: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
wBytesPerInterval in SuperSpeed Endpoint Companion Descriptor needs
to be set large enough to reserve enough bus time for associated
periodic endpoint.
Originally, wBytesPerInterval for mtp's interrupt IN endpoint is set
to 2 and its single interrupt transfer will be split into many 2 bytes
interrupt transfers. So, we change wBytesPerInterval to INTR_BUFFER_SIZE
to ensure interrupt transfer will not be split.
BUG=none
TEST=Smaug works as a MTP device
Change-Id: I49c0df892b2d9e0193a684eef23f73664ced9f91
Signed-off-by: Henry Lin <henryl@nvidia.com>
Signed-off-by: Mark Kuo <mkuo@nvidia.com>
Reviewed-on: https://chromium-review.googlesource.com/299091
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
If mmc_blk_ioctl returns -EINVAL, blkdev_ioctl continues to
work without returning err to user-space. But now we check
CAP_SYS_RAWIO firstly, so we return -EPERM to blkdev_ioctl,
which make blkdev_ioctl return -EPERM to user-space directly.
So this will break all the ioctl with BLKROSET. Now we find
Android-adb suffer it for the following log:
remount of /system failed;
couldn't make block device writable: Operation not permitted
openat(AT_FDCWD, "/dev/block/platform/ff420000.dwmmc/by-name/system", O_RDONLY) = 3
ioctl(3, BLKROSET, 0) = -1 EPERM (Operation not permitted)
Fixes: a5f5774c55 ("mmc: block: Add new ioctl to send multi commands")
Change-Id: Ie9ba728e366abf4ab73fd6102d2a2aa0d4ee5c66
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: John Stultz <john.stultz@linaro.org>
(cherry picked from commit https://lkml.org/lkml/2016/2/4/833)
Replace calls to get_random_int() followed by a cast to (unsigned long)
with calls to get_random_long(). Also address shifting bug which, in case
of x86 removed entropy mask for mmap_rnd_bits values > 31 bits.
Bug: 26963541
Signed-off-by: Daniel Cashman <dcashman@android.com>
Signed-off-by: Daniel Cashman <dcashman@google.com>
Change-Id: I36c156c9b8d7d157134895fddd4cd6efddcbee86
(cherry picked from commit https://lkml.org/lkml/2016/2/4/831)
d07e22597d ("mm: mmap: add new /proc tunable for mmap_base ASLR")
added the ability to choose from a range of values to use for entropy
count in generating the random offset to the mmap_base address. The
maximum value on this range was set to 32 bits for 64-bit x86 systems, but
this value could be increased further, requiring more than the 32 bits of
randomness provided by get_random_int(), as is already possible for arm64.
Add a new function: get_random_long() which more naturally fits with the
mmap usage of get_random_int() but operates exactly the same as
get_random_int().
Also, fix the shifting constant in mmap_rnd() to be an unsigned long so
that values greater than 31 bits generate an appropriate mask without
overflow. This is especially important on x86, as its shift instruction
uses a 5-bit mask for the shift operand, which meant that any value for
mmap_rnd_bits over 31 acts as a no-op and effectively disables mmap_base
randomization.
Finally, replace calls to get_random_int() with get_random_long() where
appropriate.
Bug: 26963541
Signed-off-by: Daniel Cashman <dcashman@android.com>
Signed-off-by: Daniel Cashman <dcashman@google.com>
Change-Id: I5b45621088666d5d1dfbf43952f25ea0798b10ba
