store 0 to disable charger input current supply, otherwise
enable charger input current supply
Change-Id: Iabf61d3c8e6469cb5d6466677e06b73c6af37bcb
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
mark rk8xx_is_enabled_wmsk_regmap as is_enable callback func for siwtch ops.
Change-Id: Ice90f92438a73f77c61aadd1c43441626c24e075
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
If we use usb gadget as uvc and adb composite function,
the adb will be disconnected if the uvc camera apk is
closed. I can reproduce this issue by the following steps
on rk3399/rk3288 platforms.
1. Set usb gadget as uvc and adb composite function,
and open uvc camera apk on rk3399/rk3288 platforms.
2. Connect usb to PC, and use adb shell;
3. Close the uvc camera apk;
And then, the adb will also be disconnected. It's because
that when close the uvc camera apk, the userspace calls
v4l2_release -> uvc_v4l2_release -> uvc_function_disconnect
-> usb_gadget_deactivate -> usb_gadget_disconnect ->
pullup(gadget, 0), this cause usb controller disconnect the
usb connection.
This patch adds a uvc_enabled flag to indicate that usb
is connected, don't call pullup(gadget, 0) to disconnet
usb if we only close uvc camera apk but not plug out usb
cable.
Change-Id: I0cc5ce8a24e8e06e0dc9215dfd1b92ef702e4311
Signed-off-by: William Wu <william.wu@rock-chips.com>
Hub driver will try to disable a USB3 device twice at logical disconnect,
racing with xhci_free_dev() callback from the first port disable.
This can be triggered with "udisksctl power-off --block-device <disk>"
or by writing "1" to the "remove" sysfs file for a USB3 device
in 4.17-rc4.
USB3 devices don't have a similar disabled link state as USB2 devices,
and use a U3 suspended link state instead. In this state the port
is still enabled and connected.
hub_port_connect() first disconnects the device, then later it notices
that device is still enabled (due to U3 states) it will try to disable
the port again (set to U3).
The xhci_free_dev() called during device disable is async, so checking
for existing xhci->devs[i] when setting link state to U3 the second time
was successful, even if device was being freed.
The regression was caused by, and whole thing revealed by,
Commit 44a182b9d1 ("xhci: Fix use-after-free in xhci_free_virt_device")
which sets xhci->devs[i]->udev to NULL before xhci_virt_dev() returned.
and causes a NULL pointer dereference the second time we try to set U3.
Fix this by checking xhci->devs[i]->udev exists before setting link state.
The original patch went to stable so this fix needs to be applied there as
well.
Fixes: 44a182b9d1 ("xhci: Fix use-after-free in xhci_free_virt_device")
Change-Id: I568357fcb3ab320b628f6998ba1e571d40ecaa06
Cc: <stable@vger.kernel.org>
Reported-by: Jordan Glover <Golden_Miller83@protonmail.ch>
Tested-by: Jordan Glover <Golden_Miller83@protonmail.ch>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
(cherry picked from commit 2278446e2b)
Trying to read from debugfs after the system has resumed from
hibernate causes a use-after-free and thus a protection fault.
Steps to reproduce:
Hibernate system, resume from hibernate, then run
$ cat /sys/kernel/debug/usb/xhci/*/command-ring/enqueue
[ 3902.765086] general protection fault: 0000 [#1] PREEMPT SMP
...
[ 3902.765136] RIP: 0010:xhci_trb_virt_to_dma.part.50+0x5/0x30
...
[ 3902.765178] Call Trace:
[ 3902.765188] xhci_ring_enqueue_show+0x1e/0x40
[ 3902.765197] seq_read+0xdb/0x3a0
[ 3902.765204] ? __handle_mm_fault+0x5fb/0x1210
[ 3902.765211] full_proxy_read+0x4a/0x70
[ 3902.765219] __vfs_read+0x23/0x120
[ 3902.765228] vfs_read+0x8e/0x130
[ 3902.765235] SyS_read+0x42/0x90
[ 3902.765242] do_syscall_64+0x6b/0x290
[ 3902.765251] entry_SYSCALL64_slow_path+0x25/0x25
The issue is caused by the xhci ring structures being reallocated
when the system is resumed, but pointers to the old structures
being retained in the debugfs files "private" field:
The proposed patch fixes this issue by storing a pointer to the xhci_ring
field in the xhci device structure in debugfs rather than directly
storing a pointer to the xhci_ring.
Change-Id: Ic60c7b4c7599209b89775e03b5cc4f9d9cdba6ac
Fixes: 02b6fdc2a1 ("usb: xhci: Add debugfs interface for xHCI driver")
Signed-off-by: Alexander Kappner <agk@godking.net>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
Free the virt_device and its debugfs_private member together.
When resuming from hibernate the .free_dev callback unconditionally
freed the debugfs_private member, but could leave virt_device intact.
This triggered a NULL pointer dereference after resume when usbmuxd
sent a USBDEVFS_SETCONFIGURATION ioctl to a device, trying to add a
endpoint debugfs entry to a already freed debugfs_private pointer.
Change-Id: Ib0ed39ee0f82f3f5c3af5c46949a6a5f6dfe190d
Fixes: 02b6fdc2a1 ("usb: xhci: Add debugfs interface for xHCI driver")
Reported-by: Alexander Kappner <agk@godking.net>
Tested-by: Alexander Kappner <agk@godking.net>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: William Wu <william.wu@rock-chips.com>
When system shutdown, shutdown interface will be called.
Hdmi should be disabled when system shutdown.
Change-Id: I09ec1d7d3801bf8a8277c91072fa09bd1b430809
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
When system shutdown, shutdown interface will be called.
TVE should be disabled when system shutdown.
Change-Id: If9dd29605cc0bd67aa8e9c494a98f89e625e4c50
Signed-off-by: Algea Cao <algea.cao@rock-chips.com>
This patch fix the wrong reg value for rk322x/rk322xh,
cuz there is no STORE JUSTIFIED MODE on it.
on rk322x/rk322xh, the same bit means PDM_MODE/RESERVED,
if the bit is set to RESERVED, the controller will not work.
Change-Id: I9bfc055e792d73a66f51c78c7c2ff5c4cba620ae
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch marks RXFIFO_DATA as precious to avoid being read
outside a call from the driver, such as regmap debugfs
Change-Id: Id94a3d6f4ea382fc09547241dabc6ab84ca74139
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch marks SPDIFRX_SMPDR as precious to avoid being read
outside a call from the driver, such as regmap debugfs.
Change-Id: Icc5398e0e192b86e191770b9ebd1251f97e6a048
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch marks SPDIF_SMPDR as volatile to make it resaonable,
which also requires marking it as readable, even though it isn't.
Change-Id: Ia59136a4d7a9a3984d4f4b2518f835ead7419aec
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch adds grf configs to fix the clk paths
when used in tx/rx only slave mode.
Change-Id: I704687d86f1e8c25181d1e87e00107560c9e36fe
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
When restoring registers during runtime resume, we must not write to
I2S_TXDR which is the transmit FIFO as this queues up a sample to be
output and pushes all of the output channels down by one.
This can be demonstrated with the speaker-test utility:
for i in a b c; do speaker-test -c 2 -s 1; done
which should play a test with through the left speaker three times but if
the I2S hardware starts runtime suspended the first sample will be played
through the right speaker.
Fix this by marking I2S_TXDR as volatile (which also requires marking it
as readable, even though it technically isn't). This seems to be the
most robust fix, the alternative of giving I2S_TXDR a default value is
more fragile since it does not prevent regcache writing to the register
in all circumstances.
While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
are not writable so they do not suffer from the same problem as I2S_TXDR
but reading from I2S_RXDR does suffer from a similar problem.
Change-Id: Id91d3f54f3fda0e9140c9da162b0dff2c3df067b
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
When restoring registers during runtime resume, we must not write to
I2S_TXDR which is the transmit FIFO as this queues up a sample to be
output and pushes all of the output channels down by one.
This can be demonstrated with the speaker-test utility:
for i in a b c; do speaker-test -c 2 -s 1; done
which should play a test through the left speaker three times but if the
I2S hardware starts runtime suspended the first sample will be played
through the right speaker.
Fix this by marking I2S_TXDR as volatile (which also requires marking it
as readable, even though it technically isn't). This seems to be the
most robust fix, the alternative of giving I2S_TXDR a default value is
more fragile since it does not prevent regcache writing to the register
in all circumstances.
While here, also fix the configuration of I2S_RXDR and I2S_FIFOLR; these
are not writable so they do not suffer from the same problem as I2S_TXDR
but reading from I2S_RXDR does suffer from a similar problem.
Change-Id: I47e67b51f8251486bb5e937619fdec89fc055f14
Fixes: f0447f6cbb ("ASoC: rockchip: i2s: restore register during runtime_suspend/resume cycle", 2016-09-07)
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
(cherry picked from commit c66234cfed)
This patch adds the reset property for reset mechanism.
Change-Id: Ia60cc1f140860613b35ec42d703094bff8b46893
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch brings i2s back to normal by resetting i2s m/h
logic if i2s' clear operation is failed.
Change-Id: I2fd47039b522ac89499b4a2912d5ffb7a469e75e
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
This patch brings i2s back to normal by resetting i2s tx/rx
relative logic if i2s' clear operation is failed.
Change-Id: I52e4713d26f781962278802bd1f9bbce3fe4b751
Signed-off-by: Sugar Zhang <sugar.zhang@rock-chips.com>
On RK3399/RK3399Pro platforms, We found that when USB 3.0
read/write at the same time in the following test case,
it may easily fail to transfer data with unknown problem.
Host transfer: 24B, 4MB, 4MB, 4MB
Device transfer : 24B, 4MB, 4MB, 4MB
Both Host and Device transfer "24B, 4MB, 4MB, 4M" Repeatedly
until transfer fail.
This patch adds 150us between the 24B and 4MB data to work
around the transfer issue. This patch may affect the USB 3.0
transmission performance, so we mark it as a HACK. We can
revert this patch if we find the root cause and fix this
issue with more reasonable patches.
Change-Id: Iff923ff895396a41a87e6a7df2bfa0072a13e2fc
Signed-off-by: William Wu <william.wu@rock-chips.com>
Some hardware need to translate scaling list table address to u32
address in register. The dma_addr_t on 64bit kernel will cause
overwriting to later register file.
Change-Id: Ib01d8e260b3e83dabafc13b3bfac02595faa6d63
Signed-off-by: Herman Chen <herman.chen@rock-chips.com>
GPIO0_C4 is used for lcd_en,not for backlight_en.
So fix it.
Change-Id: Id38ea83d65c91e2d7772d79caa6bad84a5d4398c
Signed-off-by: Nickey Yang <nickey.yang@rock-chips.com>
commit 5478ad10e7 upstream.
If vesafb attaches to the AST device, it configures the framebuffer memory
for uncached access by default. When ast.ko later tries to attach itself to
the device, it wants to use write-combining on the framebuffer memory, but
vesefb's existing configuration for uncached access takes precedence. This
results in reduced performance.
Removing the framebuffer's configuration before loding the AST driver fixes
the problem. Other DRM drivers already contain equivalent code.
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: <stable@vger.kernel.org>
Tested-by: Y.C. Chen <yc_chen@aspeedtech.com>
Reviewed-by: Jean Delvare <jdelvare@suse.de>
Tested-by: Jean Delvare <jdelvare@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 30aba6656f upstream.
Disallows open of FIFOs or regular files not owned by the user in world
writable sticky directories, unless the owner is the same as that of the
directory or the file is opened without the O_CREAT flag. The purpose
is to make data spoofing attacks harder. This protection can be turned
on and off separately for FIFOs and regular files via sysctl, just like
the symlinks/hardlinks protection. This patch is based on Openwall's
"HARDEN_FIFO" feature by Solar Designer.
This is a brief list of old vulnerabilities that could have been prevented
by this feature, some of them even allow for privilege escalation:
CVE-2000-1134
CVE-2007-3852
CVE-2008-0525
CVE-2009-0416
CVE-2011-4834
CVE-2015-1838
CVE-2015-7442
CVE-2016-7489
This list is not meant to be complete. It's difficult to track down all
vulnerabilities of this kind because they were often reported without any
mention of this particular attack vector. In fact, before
hardlinks/symlinks restrictions, fifos/regular files weren't the favorite
vehicle to exploit them.
[s.mesoraca16@gmail.com: fix bug reported by Dan Carpenter]
Link: https://lkml.kernel.org/r/20180426081456.GA7060@mwanda
Link: http://lkml.kernel.org/r/1524829819-11275-1-git-send-email-s.mesoraca16@gmail.com
[keescook@chromium.org: drop pr_warn_ratelimited() in favor of audit changes in the future]
[keescook@chromium.org: adjust commit subjet]
Link: http://lkml.kernel.org/r/20180416175918.GA13494@beast
Signed-off-by: Salvatore Mesoraca <s.mesoraca16@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Suggested-by: Solar Designer <solar@openwall.com>
Suggested-by: Kees Cook <keescook@chromium.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Loic <hackurx@opensec.fr>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 896bbb2522 upstream.
When priority inheritance was added back in 2.6.18 to sched_setscheduler(), it
added a path to taking an rt-mutex wait_lock, which is not IRQ safe. As PI
is not a common occurrence, lockdep will likely never trigger if
sched_setscheduler was called from interrupt context. A BUG_ON() was added
to trigger if __sched_setscheduler() was ever called from interrupt context
because there was a possibility to take the wait_lock.
Today the wait_lock is irq safe, but the path to taking it in
sched_setscheduler() is the same as the path to taking it from normal
context. The wait_lock is taken with raw_spin_lock_irq() and released with
raw_spin_unlock_irq() which will indiscriminately enable interrupts,
which would be bad in interrupt context.
The problem is that normalize_rt_tasks, which is called by triggering the
sysrq nice-all-RT-tasks was changed to call __sched_setscheduler(), and this
is done from interrupt context!
Now __sched_setscheduler() takes a "pi" parameter that is used to know if
the priority inheritance should be called or not. As the BUG_ON() only cares
about calling the PI code, it should only bug if called from interrupt
context with the "pi" parameter set to true.
Reported-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Tested-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrew Morton <akpm@osdl.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: dbc7f069b9 ("sched: Use replace normalize_task() with __sched_setscheduler()")
Link: http://lkml.kernel.org/r/20170308124654.10e598f2@gandalf.local.home
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6ba9fc8e62 upstream.
[BUG]
fstrim on some btrfs only trims the unallocated space, not trimming any
space in existing block groups.
[CAUSE]
Before fstrim_range passed to btrfs_trim_fs(), it gets truncated to
range [0, super->total_bytes). So later btrfs_trim_fs() will only be
able to trim block groups in range [0, super->total_bytes).
While for btrfs, any bytenr aligned to sectorsize is valid, since btrfs
uses its logical address space, there is nothing limiting the location
where we put block groups.
For filesystem with frequent balance, it's quite easy to relocate all
block groups and bytenr of block groups will start beyond
super->total_bytes.
In that case, btrfs will not trim existing block groups.
[FIX]
Just remove the truncation in btrfs_ioctl_fitrim(), so btrfs_trim_fs()
can get the unmodified range, which is normally set to [0, U64_MAX].
Reported-by: Chris Murphy <lists@colorremedies.com>
Fixes: f4c697e640 ("btrfs: return EINVAL if start > total_bytes in fitrim ioctl")
CC: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
