commit c283e41ef3 upstream.
The DMA chip has a fixed number of requestor lines used for flow
control. This number is platform dependent. The pxa_dma dma driver will
use this value to activate or not the flow control.
There won't be any impact on mmp_pdma driver.
Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 237bbd29f7 upstream.
It was possible for an unprivileged user to create the user and user
session keyrings for another user. For example:
sudo -u '#3000' sh -c 'keyctl add keyring _uid.4000 "" @u
keyctl add keyring _uid_ses.4000 "" @u
sleep 15' &
sleep 1
sudo -u '#4000' keyctl describe @u
sudo -u '#4000' keyctl describe @us
This is problematic because these "fake" keyrings won't have the right
permissions. In particular, the user who created them first will own
them and will have full access to them via the possessor permissions,
which can be used to compromise the security of a user's keys:
-4: alswrv-----v------------ 3000 0 keyring: _uid.4000
-5: alswrv-----v------------ 3000 0 keyring: _uid_ses.4000
Fix it by marking user and user session keyrings with a flag
KEY_FLAG_UID_KEYRING. Then, when searching for a user or user session
keyring by name, skip all keyrings that don't have the flag set.
Fixes: 69664cf16a ("keys: don't generate user and user session keyrings unless they're accessed")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The command defines for the ioctl will be installed
into userspace in a header file.
The arguments of the ioctl is the unique at a platform.
Change-Id: Ia86a12c91cc4243fea24fc21cc0a9f77ec9fb2d6
Signed-off-by: Randy Li <randy.li@rock-chips.com>
commit 979990c628 upstream.
kernelci.org reports a crazy stack usage for the VT code when CONFIG_KASAN
is enabled:
drivers/tty/vt/keyboard.c: In function 'kbd_keycode':
drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
The problem is that tty_insert_flip_char() gets inlined many times into
kbd_keycode(), and also into other functions, and each copy requires 128
bytes for stack redzone to check for a possible out-of-bounds access on
the 'ch' and 'flags' arguments that are passed into
tty_insert_flip_string_flags as a variable-length string.
This introduces a new __tty_insert_flip_char() function for the slow
path, which receives the two arguments by value. This completely avoids
the problem and the stack usage goes back down to around 100 bytes.
Without KASAN, this is also slightly better, as we don't have to
spill the arguments to the stack but can simply pass 'ch' and 'flag'
in registers, saving a few bytes in .text for each call site.
This should be backported to linux-4.0 or later, which first introduced
the stack sanitizer in the kernel.
Fixes: c420f167db ("kasan: enable stack instrumentation")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 5a63643e58 ]
This reverts commit 1d6119baf0.
After reverting commit 6d7b857d54 ("net: use lib/percpu_counter API
for fragmentation mem accounting") then here is no need for this
fix-up patch. As percpu_counter is no longer used, it cannot
memory leak it any-longer.
Fixes: 6d7b857d54 ("net: use lib/percpu_counter API for fragmentation mem accounting")
Fixes: 1d6119baf0 ("net: fix percpu memory leaks")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit fb452a1aa3 ]
This reverts commit 6d7b857d54.
There is a bug in fragmentation codes use of the percpu_counter API,
that can cause issues on systems with many CPUs.
The frag_mem_limit() just reads the global counter (fbc->count),
without considering other CPUs can have upto batch size (130K) that
haven't been subtracted yet. Due to the 3MBytes lower thresh limit,
this become dangerous at >=24 CPUs (3*1024*1024/130000=24).
The correct API usage would be to use __percpu_counter_compare() which
does the right thing, and takes into account the number of (online)
CPUs and batch size, to account for this and call __percpu_counter_sum()
when needed.
We choose to revert the use of the lib/percpu_counter API for frag
memory accounting for several reasons:
1) On systems with CPUs > 24, the heavier fully locked
__percpu_counter_sum() is always invoked, which will be more
expensive than the atomic_t that is reverted to.
Given systems with more than 24 CPUs are becoming common this doesn't
seem like a good option. To mitigate this, the batch size could be
decreased and thresh be increased.
2) The add_frag_mem_limit+sub_frag_mem_limit pairs happen on the RX
CPU, before SKBs are pushed into sockets on remote CPUs. Given
NICs can only hash on L2 part of the IP-header, the NIC-RXq's will
likely be limited. Thus, a fair chance that atomic add+dec happen
on the same CPU.
Revert note that commit 1d6119baf0 ("net: fix percpu memory leaks")
removed init_frag_mem_limit() and instead use inet_frags_init_net().
After this revert, inet_frags_uninit_net() becomes empty.
Fixes: 6d7b857d54 ("net: use lib/percpu_counter API for fragmentation mem accounting")
Fixes: 1d6119baf0 ("net: fix percpu memory leaks")
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 4e587ea71b ]
Commit c5cff8561d adds rcu grace period before freeing fib6_node. This
generates a new sparse warning on rt->rt6i_node related code:
net/ipv6/route.c:1394:30: error: incompatible types in comparison
expression (different address spaces)
./include/net/ip6_fib.h:187:14: error: incompatible types in comparison
expression (different address spaces)
This commit adds "__rcu" tag for rt6i_node and makes sure corresponding
rcu API is used for it.
After this fix, sparse no longer generates the above warning.
Fixes: c5cff8561d ("ipv6: add rcu grace period before freeing fib6_node")
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit c5cff8561d ]
We currently keep rt->rt6i_node pointing to the fib6_node for the route.
And some functions make use of this pointer to dereference the fib6_node
from rt structure, e.g. rt6_check(). However, as there is neither
refcount nor rcu taken when dereferencing rt->rt6i_node, it could
potentially cause crashes as rt->rt6i_node could be set to NULL by other
CPUs when doing a route deletion.
This patch introduces an rcu grace period before freeing fib6_node and
makes sure the functions that dereference it takes rcu_read_lock().
Note: there is no "Fixes" tag because this bug was there in a very
early stage.
Signed-off-by: Wei Wang <weiwan@google.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the gpio base is started from 1000, the "gpio = 0" will
be invalid, that can avoid something unforeseen. The real
pin number is "gpio number - 1000".
If you cat the gpio log, you will see the log like this:
rk3399:/ # cat d/gpio
GPIOs 1000-1031, platform/pinctrl, gpio0:
gpio-1004 ( |bt_default_wake_host) in lo
gpio-1005 ( |power ) in hi
gpio-1009 ( |bt_default_reset ) out lo
gpio-1010 ( |reset ) out lo
gpio-1011 ( |? ) out hi
GPIOs 1032-1063, platform/pinctrl, gpio1:
gpio-1034 ( |int-n ) in hi
gpio-1035 ( |vbus-5v ) out lo
gpio-1036 ( |vbus-5v ) out lo
gpio-1045 ( |enable ) out hi
gpio-1046 ( |vsel ) out lo
gpio-1049 ( |vsel ) out lo
gpio-1056 ( |int-n ) in hi
GPIOs 1064-1095, platform/pinctrl, gpio2:
gpio-1083 ( |bt_default_rts ) in hi
gpio-1090 ( |bt_default_wake ) in hi
GPIOs 1096-1127, platform/pinctrl, gpio3:
gpio-1111 ( |mdio-reset ) out hi
GPIOs 1128-1159, platform/pinctrl, gpio4:
gpio-1150 ( |? ) out hi
gpio-1153 ( |vcc5v0_host ) out hi
gpio-1156 ( |hp det ) in hi
Change-Id: I744ddc1df6075b0a044d65c65622e2a59f3a332e
Signed-off-by: David Wu <david.wu@rock-chips.com>
There is a frequency map table between vop bandwidth and dmc, when vop
bandwidth is changed, the dmc frequency will also be changed to specified
frequency.
If new request frequency is greater than old request frequency, update dmc
target frequency immediately. If new request frequency is less than old
request frequency, only update min_freq and max_freq.
Change-Id: Ib5bf098faf5ffa72e60c34aa686431352420e69b
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
rk-isp10: version 0.1.a
1. To optimize the readability of the code, based on v0.1.9
2. Optimize CIF_MI_CTRL_BURST_LEN param.
3. Add check for cam_itf.type(PLTFRM_CAM_ITF_BT656_8I) on
cif_isp10_s_fmt_mp.
4. get field_flag value from cif_isp10_isp_isr.
Change-Id: I334595c01e8b418b47e0a54e6fdfcf624445ff9f
Signed-off-by: zhoupeng <benjo.zhou@rock-chips.com>
Make the schedutil governor take the initial (default) value of the
rate_limit_us sysfs attribute from the (new) transition_delay_us
policy parameter (to be set by the scaling driver).
That will allow scaling drivers to make schedutil use smaller default
values of rate_limit_us and reduce the default average time interval
between consecutive frequency changes.
Make intel_pstate set transition_delay_us to 500.
BACKPORT: Modified to support the separate up_rate_limit_us and
down_rate_limit_us (upstream just has a single rate_limit_us). Also
dropped the changes for intel_pstate as there's a merge conflict.
Change-Id: I62a8543879a4d8582cdcb31ebd55607705d1c8b1
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
(cherry picked from commit 1b72e7fd30)
Signed-off-by: Brendan Jackman <brendan.jackman@arm.com>
Currently block plug holds up to 16 non-mergeable requests. This makes
sense if the request size is small, eg, reduce lock contention. But if
request size is big enough, we don't need to worry about lock
contention. Holding such request makes no sense and it lows the disk
utilization.
In practice, this improves 10% throughput for my raid5 sequential write
workload.
The size (128k) is arbitrary right now, but it makes sure lock
contention is small. This probably could be more intelligent, eg, check
average request size holded. Since this is mainly for sequential IO,
probably not worthy.
V2: check the last request instead of the first request, so as long as
there is one big size request we flush the plug.
Change-Id: I034ee890eb799ea2c2ee2d38f80f880398f39f91
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry pick from 50d24c3440)
commit 591b6bb605 upstream.
Several legacy devices such as Geode-based Cisco ASA appliances
and DB800 development board do possess CS5536 IDE controller
with different PCI id than existing one. Using pata_generic is
not always feasible as at least DB800 requires MSR quirk from
pata_cs5536 to be used with vendor firmware.
Signed-off-by: Andrey Korolyov <andrey@xdel.ru>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fbf1c41fc0 upstream.
Commit 0a94efb5ac ("workqueue: implicit ordered attribute should be
overridable") introduced a __WQ_ORDERED_EXPLICIT flag but gave it the
same value as __WQ_LEGACY. I don't believe these were intended to
mean the same thing, so renumber __WQ_ORDERED_EXPLICIT.
Fixes: 0a94efb5ac ("workqueue: implicit ordered attribute should be ...")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To get input/output bus_format/enc_format dynamically, this patch
introduce following funstion in plat_data:
- get_input_bus_format
- get_output_bus_format
- get_enc_in_encoding
- get_enc_out_encoding
Change-Id: Ic703cba93fad8ceff773e1caca80759f95a9d547
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
This patch adds helper functions for YCBCR 420 handling.
These functions do:
- check if a given video mode is YCBCR 420 only mode.
- check if a given video mode is YCBCR 420 also mode.
V2: Added YCBCR functions as helpers in DRM layer, instead of
keeping it in I915 layer.
V3: Added handling for YCBCR-420 only modes too.
V4: EXPORT_SYMBOL(drm_find_hdmi_output_type)
V5: Addressed review comments from Danvet:
- %s/drm_find_hdmi_output_type/drm_display_info_hdmi_output_type
- %s/drm_can_support_ycbcr_output/drm_display_supports_ycbcr_output
- %s/drm_can_support_this_ycbcr_output/
drm_display_supports_this_ycbcr_output
- pass drm_display_info instead of drm_connector for consistency
- For drm_get_highest_quality_ycbcr_supported doc, move the variable
description above, and then the function description.
V6: Add only YCBCR420 helpers (Ville)
V7: Addressed review comments from Ville
- Remove cea_vic_valid() check.
- Fix indentation.
- Make input parameters to helpers, const.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <Jose.Abreu@synopsys.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-9-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix sparse indentation warn]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Change-Id: Ic2177fc9a7c9a3005fcdc88aa9183b429209d2e0
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 2570fe2586)
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
V2: Addressed
Review comments from Emil:
- Use 1ULL<<i instead of 1<<i to make sure the output is 64bit.
- Use the suggested method for updating dbmap.
- Add documentation for YCBCR420_vcb_map to fix kbuild warning.
Review comments from Ville:
- Do not expose the YCBCR420 flags in uabi layer, keep it internal.
- Save a map of YCBCR420 modes for future reference.
- Check db length before trying to parse extended tag.
- Add a warning if there are > 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
V5: Addressed review comments from Ville:
- Add the patch which cleans up the current EXTENDED_TAG usage
- Make y420_cmdb_map u64
- Do not block ycbcr420 modes while parsing the EDID, rather
add a separate helper function to prune ycbcr420-only modes from
connector's probed modes.
V6: Rebase
V7: Move this patch after the 420_only validation patch (Ville)
V8: Addressed review comments from Ville
- use cea_vic_valid check before adding cmdb/vdb modes
- add check for i < 64 while adding cmdb modes
- use 1ULL while checking bitmap
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1500028426-14883-1-git-send-email-shashank.sharma@intel.com
[vsyrjala: Fix checkpatch complaints and indentation]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Change-Id: Id99fd280375445ff5ec93e19283fa7e3c2e715f7
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 832d4f2f41)
YCBCR420 modes are supported only on HDMI 2.0 capable sources.
This patch adds:
- A drm helper to validate YCBCR420-only mode on a particular
connector. This function will help pruning the YCBCR420-only
modes from the connector's modelist.
- A bool variable (ycbcr_420_allowed) in the drm connector structure.
While handling the EDID from HDMI 2.0 sinks, its important to know
if the source is capable of handling YCBCR420 output, so that no
YCBCR 420 modes will be listed for sources which can't handle it.
A driver should set this variable if it wants to see YCBCR420 modes
in the modedb.
V5: Introduced the patch in series.
V6: Squashed two patches (validate YCBCR420 and add YCBCR420
identifier)
V7: Addressed review comments from Vile:
- Move this patch before we add 420 modes from EDID.
- No need for drm_valid_cea_vic() check, function back to non-static.
- Update MODE_STATUS with NO_420 condition.
- Introduce y420_vdb_modes variable in this patch
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-6-git-send-email-shashank.sharma@intel.com
[vsyrjala: Drop the now bogus EXPORT_SYMBOL(drm_valid_cea_vic)]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Change-Id: Ia5ef115a54ee522d4c44544ee3abe4247a54f9c0
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit d85231530b)
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
As CEA-861-F has already defined VICs for 4K videomodes, this
patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
until the mode is 3D.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
send only one of it.
V4: Rebase
V5: Added r-b from Neil.
Addressed review comments from Ville
- Do not block HDMI vendor IF, instead check for VIC while
handling AVI infoframes
V6: Rebase
V7: Rebase
Change-Id: I4a8e9ed2f292d3db6512e29e43661a21bb0b2a48
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Zheng Yang <zhengyang@rock-chips.com>
(cherry picked from commit 0c1f528cb1)
odd and even field interlace generating a frame image.
fix cif_isp10_img_src_v4l2_subdev_enum_strm_fmts defrect info get error.
fix cif_isp10_rk3399 cif_clk_pll info doesn't match with dts config.
Change-Id: I44159c0dd4e676334221b5d5682e29d3280aa9fd
Signed-off-by: zhoupeng <benjo.zhou@rock-chips.com>
commit b339752d05 upstream.
When !NUMA, cpumask_of_node(@node) equals cpu_online_mask regardless of
@node. The assumption seems that if !NUMA, there shouldn't be more than
one node and thus reporting cpu_online_mask regardless of @node is
correct. However, that assumption was broken years ago to support
DISCONTIGMEM and whether a system has multiple nodes or not is
separately controlled by NEED_MULTIPLE_NODES.
This means that, on a system with !NUMA && NEED_MULTIPLE_NODES,
cpumask_of_node() will report cpu_online_mask for all possible nodes,
indicating that the CPUs are associated with multiple nodes which is an
impossible configuration.
This bug has been around forever but doesn't look like it has caused any
noticeable symptoms. However, it triggers a WARN recently added to
workqueue to verify NUMA affinity configuration.
Fix it by reporting empty cpumask on non-zero nodes if !NUMA.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This adds the necessary data for handling dmcfreq on the rk3128.
Change-Id: I6aeae7103c1eaed0b4515d8d11863c4b190b6918
Signed-off-by: Liang Chen <cl@rock-chips.com>
commit 5389a1dfb3 upstream.
The ->reserved bit is not initialized when allocated on stack.
This may lead targets to misinterpret the PPA as cached.
Signed-off-by: Javier González <javier@cnexlabs.com>
Signed-off-by: Matias Bjørling <m@bjorling.me>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LSK 17.08 v4.4-android
* tag 'lsk-v4.4-17.08-android': (451 commits)
Linux 4.4.83
pinctrl: samsung: Remove bogus irq_[un]mask from resource management
pinctrl: sunxi: add a missing function of A10/A20 pinctrl driver
pnfs/blocklayout: require 64-bit sector_t
iio: adc: vf610_adc: Fix VALT selection value for REFSEL bits
usb:xhci:Add quirk for Certain failing HP keyboard on reset after resume
usb: quirks: Add no-lpm quirk for Moshi USB to Ethernet Adapter
usb: core: unlink urbs from the tail of the endpoint's urb_list
USB: Check for dropped connection before switching to full speed
uag: Add US_FL_IGNORE_RESIDUE for Initio Corporation INIC-3069
iio: light: tsl2563: use correct event code
iio: accel: bmc150: Always restore device to normal mode after suspend-resume
staging:iio:resolver:ad2s1210 fix negative IIO_ANGL_VEL read
USB: hcd: Mark secondary HCD as dead if the primary one died
usb: musb: fix tx fifo flush handling again
USB: serial: pl2303: add new ATEN device id
USB: serial: cp210x: add support for Qivicon USB ZigBee dongle
USB: serial: option: add D-Link DWM-222 device ID
nfs/flexfiles: fix leak of nfs4_ff_ds_version arrays
fuse: initialize the flock flag in fuse_file on allocation
...
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
Conflicts:
drivers/android/binder.c
Keep AOSP changes and discard LTS binder changes, since these LTS changes
have already been merged and further refactored in AOSP tree long ago.
In preparation for moving some of the phy_device structure members,
add macros for printing errors and debug information.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 72ba48be3e)
Signed-off-by: David Wu <david.wu@rock-chips.com>
Change-Id: I75021fb43a0317cab4dba81fe737a23dd3f8431c
Instead of adding hooks inside stmmac_platform it is better to just use
the standard PM callbacks within the specific dwmac-driver. This only
used by the dwmac-rk driver.
This reverts commit cecbc5563a ("stmmac: allow to split suspend/resume
from init/exit callbacks").
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 5a3c7805c4)
Conflicts:
include/linux/stmmac.h
Change-Id: I3864f8bfe4ee201b449ee766aba6810b498d8a74
Signed-off-by: David Wu <david.wu@rock-chips.com>
Let the stmmac platform drivers provide dedicated suspend and resume
callbacks rather than always re-using the init and exits callbacks.
If the driver does not provide the suspend or resume callback, we fall
back to the old behavior trying to use exit or init.
This allows a specific platform to perform only a partial power-down on
suspend if Wake-on-Lan is enabled but always perform the full shutdown
sequence if the module is unloaded.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cecbc5563a)
Conflicts:
include/linux/stmmac.h
Change-Id: I06799616dd75175e186bfdde85814ecbda48a654
Signed-off-by: David Wu <david.wu@rock-chips.com>
tc358649 is similar with tc358643, when VIP in tc358649 is
set to bypassed.
So this driver can also be used for tc358649, we
should rename it to tc35864x.
Below is the function table show differences between tc358643/9:
tc358643 :
- HDMI 1.4a
- MIPI CSI2-TX
- Audio Support
- HDCP Support
- 3D Support
tc358649 :
- HDMI 1.4a
- MIPI CSI2-TX
- Audio Support
- HDCP Support
- 3D Support
- Scalar
- De-interface
Change-Id: I4851f62b58687dfffdc5de686a9d12ece08e6c28
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Switch users of the v4l2_of_ APIs to the more generic v4l2_fwnode_ APIs.
Async OF matching is replaced by fwnode matching and OF matching support
is removed.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Acked-by: Benoit Parrot <bparrot@ti.com> # i2c/ov2569.c, am437x/am437x-vpfe.c and ti-vpe/cal.c
Tested-by: Hans Verkuil <hans.verkuil@cisco.com> # Atmel sama5d3 board + ov2640 sensor
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
(cherry picked from commit 859969b38e)
Signed-off-by: Nathan Ciobanu <nathan.d.ciobanu@intel.com>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Conflicts:
Nathan: context, comment and include deltas, as well as deleting files
that don't apply to ChromeOS-4.4 yet
drivers/media/i2c/Kconfig
drivers/media/i2c/mt9v032.c
drivers/media/i2c/ov5645.c
drivers/media/i2c/ov5647.c
drivers/media/i2c/s5c73m3/s5c73m3-core.c
drivers/media/i2c/smiapp/smiapp-core.c
drivers/media/i2c/tc358743.c
drivers/media/i2c/tvp514x.c
drivers/media/i2c/tvp5150.c
drivers/media/i2c/tvp7002.c
drivers/media/platform/Kconfig
drivers/media/platform/atmel/Kconfig
drivers/media/platform/atmel/atmel-isc.c
drivers/media/platform/atmel/atmel-isi.c
drivers/media/platform/exynos4-is/mipi-csis.c
drivers/media/platform/omap3isp/isp.c
drivers/media/platform/pxa_camera.c
drivers/media/platform/rcar-vin/Kconfig
drivers/media/platform/rcar-vin/rcar-core.c
drivers/media/platform/soc_camera/soc_camera.c
drivers/media/platform/stm32/stm32-dcmi.c
drivers/media/platform/ti-vpe/cal.c
include/media/v4l2-subdev.h
BUG=b:62359918
TEST=No regression in camera functionality
TEST=Kernel builds and boots
Change-Id: If338e2ab0c68c72f242988f34202e0449642734c
Signed-off-by: Nathan Ciobanu <nathan.d.ciobanu@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/528621
Commit-Ready: Nathan D Ciobanu <nathan.d.ciobanu@intel.com>
Tested-by: Yong Zhi <yong.zhi@intel.com>
Reviewed-by: Tomasz Figa <tfiga@chromium.org>
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
