Credit for this patch goes is shared with Dan Williams [1]. I've
taken things one step further to make the helper function more
useful and clean up calling code.
There's a common pattern in the kernel whereby a struct cdev is placed
in a structure along side a struct device which manages the life-cycle
of both. In the naive approach, the reference counting is broken and
the struct device can free everything before the chardev code
is entirely released.
Many developers have solved this problem by linking the internal kobjs
in this fashion:
cdev.kobj.parent = &parent_dev.kobj;
The cdev code explicitly gets and puts a reference to it's kobj parent.
So this seems like it was intended to be used this way. Dmitrty Torokhov
first put this in place in 2012 with this commit:
2f0157f char_dev: pin parent kobject
and the first instance of the fix was then done in the input subsystem
in the following commit:
4a215aa Input: fix use-after-free introduced with dynamic minor changes
Subsequently over the years, however, this issue seems to have tripped
up multiple developers independently. For example, see these commits:
0d5b7da iio: Prevent race between IIO chardev opening and IIO device
(by Lars-Peter Clausen in 2013)
ba0ef85 tpm: Fix initialization of the cdev
(by Jason Gunthorpe in 2015)
5b28dde [media] media: fix use-after-free in cdev_put() when app exits
after driver unbind
(by Shauh Khan in 2016)
This technique is similarly done in at least 15 places within the kernel
and probably should have been done so in another, at least, 5 places.
The kobj line also looks very suspect in that one would not expect
drivers to have to mess with kobject internals in this way.
Even highly experienced kernel developers can be surprised by this
code, as seen in [2].
To help alleviate this situation, and hopefully prevent future
wasted effort on this problem, this patch introduces a helper function
to register a char device along with its parent struct device.
This creates a more regular API for tying a char device to its parent
without the developer having to set members in the underlying kobject.
This patch introduce cdev_device_add and cdev_device_del which
replaces a common pattern including setting the kobj parent, calling
cdev_add and then calling device_add. It also introduces cdev_set_parent
for the few cases that set the kobject parent without using device_add.
[1] https://lkml.org/lkml/2017/2/13/700
[2] https://lkml.org/lkml/2017/2/10/370
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 233ed09d7f)
Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com>
Like the runtime PM support patch of ohci-platform, we
add the same basic runtime PM for ehci-platform.
Change-Id: I84cbb15dd393e6af69b4cf6887f1628e2cba4999
Signed-off-by: William Wu <william.wu@rock-chips.com>
Use the driver to auto switch the host/peripheral mode for rk1808,
so the dr_mode must be otg.
Change-Id: I9b05e06bacd141d5fbd00a9751f2a12a4e4385c8
Signed-off-by: David.Wu <david.wu@rock-chips.com>
Use the dwc3-rockchip driver to auto switch the host/peripheral dr_mode.
Change-Id: I497570fad4caaffc9da08086f2758653afb729db
Signed-off-by: David.Wu <david.wu@rock-chips.com>
We will use the dwc3-rockchip driver for rk3399pro-npu, this patch
is prepared for it.
Change-Id: I9c97002adbe9bd2fea01d8e209183f5211b3796c
Signed-off-by: David.Wu <david.wu@rock-chips.com>
We will use the dwc3-rockchip driver for rk1808, this patch is prepared
for it.
Change-Id: I7ca8baefd26ea6c67140b757c47e14625cfed609
Signed-off-by: David Wu <david.wu@rock-chips.com>
The driver of dwc3-rockchip depends on CONFIG_USB and
CONFIG_USB_DWC3_GADGE. To use the driver, need to enable
them.
Change-Id: Iddfbf1ac2b413aa33f5803ffcfc165ec3555937f
Signed-off-by: David Wu <david.wu@rock-chips.com>
rk3399-tve1030g*:
isp0/1 for CameraHal1 in Android8.1 or lower version
rkisp1_0/1 & mipi_dphy_rx0/tx1rx1 for CameraHal3 in Android9.0
Change-Id: I9198eccb0d76ad5e51ff6a2a5021e5acefbf0f49
Signed-off-by: Wang Panzhenzhuan <randy.wang@rock-chips.com>
Split DT source files to separate out android fireware specific DT
bindings.
Change-Id: I31361570a630057e50507593c6da693cf1200a12
Signed-off-by: Zhangbin Tong <zebulun.tong@rock-chips.com>
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>
