There are several SoCs (e.g. rk3228h and rk3328) that integrated
with Inno USB3 PHY, they can't toggle CP test pattern when do
USB3 compliance test by default.
This patch add a cp_test callback for USB3 controller to enable
the special USB3 PHY to toggle the CP test pattern.
Change-Id: I2d603202723a4c044d4231af10cfe2c60ec0e988
Signed-off-by: William Wu <wulf@rock-chips.com>
Some USB controllers (such as rk3328 SoC DWC3 controller with INNO
USB 3.0 PHY) don't support autosuspend well, when receive remote
wakeup signal from autosuspend, the Port Link State training failed,
the correct PLC is Resume->Recovery->U0, but when the issue happens,
the wrong PLC is Resume->Recovery->Inactive, cause resuming SS port
fail. This issue always occurs when connect with external USB 3.0 HUB.
This patch add a quirk to disable autosuspend function, and add new
'usb3_disable_autosuspend' member in xHCI platform data to support
set the quirk based on platform data.
Change-Id: Ice01d70178206e22658660361dd3a525046cbcf5
Signed-off-by: William Wu <wulf@rock-chips.com>
Some USB host controller seems to have problems with
autosuspend. For example, Rockchip rk3328 SoC USB 3.0
wouldn't handle remote wakeup correctly with external
hub after entered autosuspend, caused to resume SS
port fail.
This patch introduces a new quirk flag for hub that
should remain disabled for autosuspend.
Change-Id: I6d14222b2c5025583fea811a6afd6abd22f41cb9
Signed-off-by: William Wu <wulf@rock-chips.com>
If a PM domain is powered off before system suspend,
we hope do nothing in system runtime suspend noirq phase
and system runtime resume noirq phase.
Change-Id: Id72b1f92e10449c48006aced0d49612637402210
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
If a PM domain is powered off when the first device starts its system PM
prepare phase, genpd prevents any further attempts to power on the PM
domain during the following system PM phases. Not until the system PM
complete phase is finalized for all devices in the PM domain, genpd again
allows it to be powered on.
This behaviour needs to be changed, as a subsystem/driver for a device in
the same PM domain may still need to be able to serve requests in some of
the system PM phases. Accordingly, it may need to runtime resume its
device and thus also request the corresponding PM domain to be powered on.
To deal with these scenarios, let's make the device operational in the
system PM prepare phase by runtime resuming it, no matter if the PM domain
is powered on or off. Changing this also enables us to remove genpd's
suspend_power_off flag, as it's being used to track this condition.
Additionally, we must allow the PM domain to be powered on via runtime PM
during the system PM phases.
This change also requires a fix in the AMD ACP (Audio CoProcessor) drm
driver. It registers a genpd to model the ACP as a PM domain, but
unfortunately it's also abuses genpd's "internal" suspend_power_off flag
to deal with a corner case at system PM resume.
More precisely, the so called SMU block powers on the ACP at system PM
resume, unconditionally if it's being used or not. This may lead to that
genpd's internal status of the power state, may not correctly reflect the
power state of the HW after a system PM resume.
Because of changing the behaviour of genpd, by runtime resuming devices in
the prepare phase, the AMD ACP drm driver no longer have to deal with this
corner case. So let's just drop the related code in this driver.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Acked-by: Maruthi Bayyavarapu <maruthi.bayyavarapu@amd.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 39dd0f234f)
Change-Id: I1c964ebd660c8c7a8547f2206c80c25b936e7196
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
The XHCI controller presents two USB buses to the system - one for USB2
and one for USB3. The hub init code (hub_port_init) is reentrant but
only locks one bus per thread, leading to a race condition failure when
two threads attempt to simultaneously initialise a USB2 and USB3 device:
[ 8.034843] xhci_hcd 0000:00:14.0: Timeout while waiting for setup device command
[ 13.183701] usb 3-3: device descriptor read/all, error -110
On a test system this failure occurred on 6% of all boots.
The call traces at the point of failure are:
Call Trace:
[<ffffffff81b9bab7>] schedule+0x37/0x90
[<ffffffff817da7cd>] usb_kill_urb+0x8d/0xd0
[<ffffffff8111e5e0>] ? wake_up_atomic_t+0x30/0x30
[<ffffffff817dafbe>] usb_start_wait_urb+0xbe/0x150
[<ffffffff817db10c>] usb_control_msg+0xbc/0xf0
[<ffffffff817d07de>] hub_port_init+0x51e/0xb70
[<ffffffff817d4697>] hub_event+0x817/0x1570
[<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
[<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
[<ffffffff810f4684>] worker_thread+0x64/0x4b0
[<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
[<ffffffff810fa7f5>] kthread+0x105/0x120
[<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
[<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
[<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
Call Trace:
[<ffffffff817fd36d>] xhci_setup_device+0x53d/0xa40
[<ffffffff817fd87e>] xhci_address_device+0xe/0x10
[<ffffffff817d047f>] hub_port_init+0x1bf/0xb70
[<ffffffff811247ed>] ? trace_hardirqs_on+0xd/0x10
[<ffffffff817d4697>] hub_event+0x817/0x1570
[<ffffffff810f3e6f>] process_one_work+0x1ff/0x620
[<ffffffff810f3dcf>] ? process_one_work+0x15f/0x620
[<ffffffff810f4684>] worker_thread+0x64/0x4b0
[<ffffffff810f4620>] ? rescuer_thread+0x390/0x390
[<ffffffff810fa7f5>] kthread+0x105/0x120
[<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
[<ffffffff81ba183f>] ret_from_fork+0x3f/0x70
[<ffffffff810fa6f0>] ? kthread_create_on_node+0x200/0x200
Which results from the two call chains:
hub_port_init
usb_get_device_descriptor
usb_get_descriptor
usb_control_msg
usb_internal_control_msg
usb_start_wait_urb
usb_submit_urb / wait_for_completion_timeout / usb_kill_urb
hub_port_init
hub_set_address
xhci_address_device
xhci_setup_device
Mathias Nyman explains the current behaviour violates the XHCI spec:
hub_port_reset() will end up moving the corresponding xhci device slot
to default state.
As hub_port_reset() is called several times in hub_port_init() it
sounds reasonable that we could end up with two threads having their
xhci device slots in default state at the same time, which according to
xhci 4.5.3 specs still is a big no no:
"Note: Software shall not transition more than one Device Slot to the
Default State at a time"
So both threads fail at their next task after this.
One fails to read the descriptor, and the other fails addressing the
device.
Fix this in hub_port_init by locking the USB controller (instead of an
individual bus) to prevent simultaneous initialisation of both buses.
Fixes: 638139eb95 ("usb: hub: allow to process more usb hub events in parallel")
Link: https://lkml.org/lkml/2016/2/8/312
Link: https://lkml.org/lkml/2016/2/4/748
Conflicts:
drivers/usb/core/hcd.c
Change-Id: I5f266198d32793ea3bc009f64ffc8b2a7744461a
Signed-off-by: Chris Bainbridge <chris.bainbridge@gmail.com>
Cc: stable <stable@vger.kernel.org>
Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <wulf@rock-chips.com>
(cherry picked from commit feb26ac31a)
we already have vip_src and sclk_vip_out defined, which are the clocks
we add as cif_out, so let's correct it.
Change-Id: I952b1490a882d290aa36d9629aeb32eee22ce8b3
Signed-off-by: Jacob Chen <jacob2.chen@rock-chips.com>
Some of kernel driver uses the IIO framework to get the sensor
value via ADC or IIO HW driver. The client driver get iio channel
by iio_channel_get() and release it by calling iio_channel_release().
Add resource managed version (devm_*) of these APIs so that if client
calls the devm_iio_channel_get() then it need not to release it explicitly,
it can be done by managed device framework when driver get un-binded.
This reduces the code in error path and also need of .remove callback in
some cases.
Change-Id: Ia00f42dab2f66aefa0b26523db849e75927003af
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
(cherry picked from commit 8bf872d8d2)
I forget to add a dummy function in case the CONFIG_GENERIC_PHY
is disabled.
Change-Id: Ic324387058ef260473fd4ad20ed43eff79044dfe
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
(cherry picked from 98430c7aad)
* linux-linaro-lsk-v4.4-android: (199 commits)
Linux 4.4.41
net: mvpp2: fix dma unmapping of TX buffers for fragments
sg_write()/bsg_write() is not fit to be called under KERNEL_DS
kconfig/nconf: Fix hang when editing symbol with a long prompt
target/user: Fix use-after-free of tcmu_cmds if they are expired
powerpc: Convert cmp to cmpd in idle enter sequence
powerpc/ps3: Fix system hang with GCC 5 builds
nfs_write_end(): fix handling of short copies
libceph: verify authorize reply on connect
PCI: Check for PME in targeted sleep state
Input: drv260x - fix input device's parent assignment
media: solo6x10: fix lockup by avoiding delayed register write
IB/cma: Fix a race condition in iboe_addr_get_sgid()
IB/multicast: Check ib_find_pkey() return value
IPoIB: Avoid reading an uninitialized member variable
IB/mad: Fix an array index check
fgraph: Handle a case where a tracer ignores set_graph_notrace
platform/x86: asus-nb-wmi.c: Add X45U quirk
ftrace/x86_32: Set ftrace_stub to weak to prevent gcc from using short jumps to it
kvm: nVMX: Allow L1 to intercept software exceptions (#BP and #OF)
...
Change-Id: I8c8467700d5563d9a1121c982737ff0ab6d9cdc9
commit e6f462df9a upstream.
When mac80211 abandons an association attempt, it may free
all the data structures, but inform cfg80211 and userspace
about it only by sending the deauth frame it received, in
which case cfg80211 has no link to the BSS struct that was
used and will not cfg80211_unhold_bss() it.
Fix this by providing a way to inform cfg80211 of this with
the BSS entry passed, so that it can clean up properly, and
use this ability in the appropriate places in mac80211.
This isn't ideal: some code is more or less duplicated and
tracing is missing. However, it's a fairly small change and
it's thus easier to backport - cleanups can come later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f84df2a6f2 upstream.
When the user namespace support was merged the need to prevent
ptrace from revealing the contents of an unreadable executable
was overlooked.
Correct this oversight by ensuring that the executed file
or files are in mm->user_ns, by adjusting mm->user_ns.
Use the new function privileged_wrt_inode_uidgid to see if
the executable is a member of the user namespace, and as such
if having CAP_SYS_PTRACE in the user namespace should allow
tracing the executable. If not update mm->user_ns to
the parent user namespace until an appropriate parent is found.
Reported-by: Jann Horn <jann@thejh.net>
Fixes: 9e4a36ece6 ("userns: Fail exec for suid and sgid binaries with ids outside our user namespace.")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 64b875f7ac upstream.
When the flag PT_PTRACE_CAP was added the PTRACE_TRACEME path was
overlooked. This can result in incorrect behavior when an application
like strace traces an exec of a setuid executable.
Further PT_PTRACE_CAP does not have enough information for making good
security decisions as it does not report which user namespace the
capability is in. This has already allowed one mistake through
insufficient granulariy.
I found this issue when I was testing another corner case of exec and
discovered that I could not get strace to set PT_PTRACE_CAP even when
running strace as root with a full set of caps.
This change fixes the above issue with strace allowing stracing as
root a setuid executable without disabling setuid. More fundamentaly
this change allows what is allowable at all times, by using the correct
information in it's decision.
Fixes: 4214e42f96d4 ("v2.4.9.11 -> v2.4.9.12")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bfedb58925 upstream.
During exec dumpable is cleared if the file that is being executed is
not readable by the user executing the file. A bug in
ptrace_may_access allows reading the file if the executable happens to
enter into a subordinate user namespace (aka clone(CLONE_NEWUSER),
unshare(CLONE_NEWUSER), or setns(fd, CLONE_NEWUSER).
This problem is fixed with only necessary userspace breakage by adding
a user namespace owner to mm_struct, captured at the time of exec, so
it is clear in which user namespace CAP_SYS_PTRACE must be present in
to be able to safely give read permission to the executable.
The function ptrace_may_access is modified to verify that the ptracer
has CAP_SYS_ADMIN in task->mm->user_ns instead of task->cred->user_ns.
This ensures that if the task changes it's cred into a subordinate
user namespace it does not become ptraceable.
The function ptrace_attach is modified to only set PT_PTRACE_CAP when
CAP_SYS_PTRACE is held over task->mm->user_ns. The intent of
PT_PTRACE_CAP is to be a flag to note that whatever permission changes
the task might go through the tracer has sufficient permissions for
it not to be an issue. task->cred->user_ns is always the same
as or descendent of mm->user_ns. Which guarantees that having
CAP_SYS_PTRACE over mm->user_ns is the worst case for the tasks
credentials.
To prevent regressions mm->dumpable and mm->user_ns are not considered
when a task has no mm. As simply failing ptrace_may_attach causes
regressions in privileged applications attempting to read things
such as /proc/<pid>/stat
Acked-by: Kees Cook <keescook@chromium.org>
Tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
Fixes: 8409cca705 ("userns: allow ptrace from non-init user namespaces")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch is used for updating the charger operations such
like setting charging current and setting input current.
Change-Id: I7c77624102dd2b43bd1c007c2097ab92a5e3de2a
Signed-off-by: Shengfei xu <xsf@rock-chips.com>
According to Heiko's advice,fix up some code style,
reference the other clock drivers for indentation.
remove grf clk init and use muxgrf to describe.
fix up the pll parent only xin24m.
fix up these *_sample error description.
add mac2io and mac2phy clk id.
moving the clock-ids a bit more together.
Change-Id: I96273a6bf808841d0488dd9db461efdffc82a99f
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
flag of emmc_disk was used to indicate that if the main
disk is for rockchip specific as we need to use rk specific
partition layout. But this name is vague and pointless since
the main disk could be sdmmc as we support sdmmc bootup.
Moreover, we could support more types of storage devices, for
instance, NVMe, UFS etc. Let's rename it to better reflect what
it is here.
Change-Id: Ibdeb4a930b97767d796ddfc050ee9d4d0ddeceb7
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
others clk change it's parent from cpll to dummy_cpll.
the vop's parent just vpll and cpll,
make sure each vop have it's own pll as parent.
Change-Id: Ia61e10918e14a69c053455018ddf0183ff15ea19
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Like what has been done for connectors add callbacks on encoder,
crtc and plane to let driver do actions after drm device registration.
Correspondingly, add callbacks called before unregister drm device.
version 2:
add drm_modeset_register_all() and drm_modeset_unregister_all()
to centralize all calls
version 3:
in error case unwind registers in drm_modeset_register_all
fix uninitialed return value
inverse order of unregistration in drm_modeset_unregister_all
version 4:
move function definitions in drm_crtc_internal.h
remove not needed documentation
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1466519829-4000-1-git-send-email-benjamin.gaignard@linaro.org
(cherry picked from commit 79190ea265)
Change-Id: I836e8ea62b46c0eae89cf8c70bcf3ea4e10068f5
Signed-off-by: Mark Yao <mark.yao@rock-chips.com>
We want to use network trace events in production
builds, to help diagnose Wifi problems. However, we
don't want to expose raw kernel pointers in such
builds.
Change the format specifier for the skbaddr field,
so that, if kptr_restrict is enabled, the pointers
will be reported as 0.
Bug: 30090733
Change-Id: Ic4bd583d37af6637343601feca875ee24479ddff
Signed-off-by: mukesh agrawal <quiche@google.com>
- Use the UID in routing lookups made by protocol connect() and
sendmsg() functions.
- Make sure that routing lookups triggered by incoming packets
(e.g., Path MTU discovery) take the UID of the socket into
account.
- For packets not associated with a userspace socket, (e.g., ping
replies) use UID 0 inside the user namespace corresponding to
the network namespace the socket belongs to. This allows
all namespaces to apply routing and iptables rules to
kernel-originated traffic in that namespaces by matching UID 0.
This is better than using the UID of the kernel socket that is
sending the traffic, because the UID of kernel sockets created
at namespace creation time (e.g., the per-processor ICMP and
TCP sockets) is the UID of the user that created the socket,
which might not be mapped in the namespace.
Bug: 16355602
Change-Id: I910504b508948057912bc188fd1e8aca28294de3
Tested: compiles allnoconfig, allyesconfig, allmodconfig
Tested: https://android-review.googlesource.com/253302
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
[AmitP: A little bit of refactoring because of LTS cherry-pick commit
e5abc10d19 ("tcp: fix NULL deref in tcp_v4_send_ack()")
Signed-off-by: Amit Pundir <amit.pundir@linaro.org>
- Define a new FIB rule attributes, FRA_UID_RANGE, to describe a
range of UIDs.
- Define a RTA_UID attribute for per-UID route lookups and dumps.
- Support passing these attributes to and from userspace via
rtnetlink. The value INVALID_UID indicates no UID was
specified.
- Add a UID field to the flow structures.
Bug: 16355602
Change-Id: Iea98e6fedd0fd4435a1f4efa3deb3629505619ab
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Protocol sockets (struct sock) don't have UIDs, but most of the
time, they map 1:1 to userspace sockets (struct socket) which do.
Various operations such as the iptables xt_owner match need
access to the "UID of a socket", and do so by following the
backpointer to the struct socket. This involves taking
sk_callback_lock and doesn't work when there is no socket
because userspace has already called close().
Simplify this by adding a sk_uid field to struct sock whose value
matches the UID of the corresponding struct socket. The semantics
are as follows:
1. Whenever sk_socket is non-null: sk_uid is the same as the UID
in sk_socket, i.e., matches the return value of sock_i_uid.
Specifically, the UID is set when userspace calls socket(),
fchown(), or accept().
2. When sk_socket is NULL, sk_uid is defined as follows:
- For a socket that no longer has a sk_socket because
userspace has called close(): the previous UID.
- For a cloned socket (e.g., an incoming connection that is
established but on which userspace has not yet called
accept): the UID of the socket it was cloned from.
- For a socket that has never had an sk_socket: UID 0 inside
the user namespace corresponding to the network namespace
the socket belongs to.
Kernel sockets created by sock_create_kern are a special case
of #1 and sk_uid is the user that created them. For kernel
sockets created at network namespace creation time, such as the
per-processor ICMP and TCP sockets, this is the user that created
the network namespace.
Bug: 16355602
Change-Id: Idbc3e9a0cec91c4c6e01916b967b6237645ebe59
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The result of "__entry->walt_avg = (__entry->demand << 10)" will exceed
the range of "unsigned int", which will be truncated and make the trace
looks like as follows:
UnityMain-4588 [004] 6029.645672: walt_update_history: 4588(UnityMain): runtime 9928307 samples 1 event 4
demand 9928307 walt 157 pelt 870 (hist: 9928307 9604307 8440077 87392 34144328) cpu 4
UnityMain-4588 [004] 6029.653658: walt_update_history: 4588(UnityMain): runtime 10000000 samples 1 event 4
demand 10000000 walt 165 pelt 886 (hist: 10000000 9955691 6549308 64000 34144328) cpu 4
Fix this by using a u64 type instead of unsgined int type and make the
trace as below:
UnityMain-4617 [004] 117.613558: walt_update_history: 4617(UnityMain): runtime 5770597 samples 1 event 4
demand 7038739 walt 720 pelt 680 (hist: 5770597 7680001 8904509 65596 156) cpu 4
UnityMain-4617 [004] 117.633560: walt_update_history: 4617(UnityMain): runtime 9911238 samples 1 event 4
demand 9911238 walt 1014 pelt 769 (hist: 9911238 5770597 7680001 0 1664188058) cpu 4
Signed-off-by: Ke Wang <ke.wang@spreadtrum.com>
Make sure drivers work if rk_keys do not selected.
Change-Id: I2882e6c69f0ddbff54089f824be33964ded3cb2e
Signed-off-by: Huang, Tao <huangtao@rock-chips.com>
According to a description from TRM, add all the idle request.
Change-Id: Ia2fdb20d89f7e668a3c86074ebed8c73ab0a9429
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
