| Age | Commit message (Collapse) | Author |
|---|
|
Various avr32 builds fail:
arch/avr32/oprofile/backtrace.c:58: error: dereferencing pointer to incomplete type
arch/avr32/oprofile/backtrace.c:60: error: implicit declaration of function 'user_mode'
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Richter <rric@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: oprofile-list@lists.sf.net
Fixes: f780d89a0e82 ("sched/headers: Remove <asm/ptrace.h> from ...")
Link: http://lkml.kernel.org/r/1488762357-4500-1-git-send-email-linux@roeck-us.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
Current Audio-DMAC is assigned "rx" as Audio-DMAC0, "tx" as Audio-DMAC1.
Thus, DVC "tx" should be assigned as Audio-DMAC1, instead of Audio-DMAC0.
Because of this, current platform board (using SRC/DVC/SSI)
Playback/Capture both will use same Audio-DMAC0
(but it depends on data path).
First note is that this "rx" and "tx" are from each IP point,
it doesn't mean Playback/Capture.
Second note is that Audio DMAC assigned on DT is only for
Audio-DMAC, Audio-DMAC-peri-peri has no entry.
=> Audio-DMAC
-> Audio-DMAC-peri-peri
-- HW connection
Playback case
[Mem] => [SRC]--[DVC] -> [SSI]--[Codec]
rx ~~~~~~~~~~~~
Capture
[Mem] <= [DVC]--[SRC] <- [SSI]--[Codec]
tx ~~~~~~~~~~~~
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The Cortex-A7 cache controller is an integrated controller, and thus the
device node representing it should not have a unit-addresses or reg
property.
Fixes: 34ea4b4a827b4ee7 ("ARM: dts: r8a7794: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: ad53f5f00b095a0d ("ARM: dts: r8a7793: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 7c4163aae3d8e5b9 ("ARM: dts: r8a7792: initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 6f9314ce258c8504 ("ARM: dts: r8a7791: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The Cortex-A15/A7 cache controllers are integrated controllers, and thus
the device nodes representing them should not have unit-addresses or reg
properties.
Fixes: 2c3de36700d4f3a5 ("ARM: dts: r8a7790: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The Cortex-A7 cache controller is an integrated controller, and thus the
device node representing it should not have a unit-addresses or reg
property.
Fixes: c95360247bdd67d3 ("ARM: dts: r8a7745: initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 34e8d993a68ae459 ("ARM: dts: r8a7743: initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The Cortex-A15/A7 cache controllers are integrated controllers, and thus
the device nodes representing them should not have unit-addresses or reg
properties.
Fixes: b0da45c60d2f7b08 ("ARM: dts: r8a73a4: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The dual Cortex-A9 MPCore inside socfpga has a standard PMU unit for
each core mapped in the DAP memory space. Add support for it!
Tested with perf on a Cyclone 5 SoC DK.
Reported-by: Alberto Dassatti <alberto.dassatti@heig-vd.ch>
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Tested-by: Alberto Dassatti <alberto.dassatti@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
This makes it easier to reference the CPU nodes afterwards.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
The skeleton.dtsi file is now deprecated as noted in commit 9c0da3cc61f1
("ARM: dts: explicitly mark skeleton.dtsi as deprecated"). The SoCFPGA
device trees already contain the nodes that are defined in skeleton.dtsi
(#address-cells, #size-cells, chosen, aliases, memory).
Including skeleton.dtsi is useless and will produce the following
warning when compiled with W=1:
Node /memory has a reg or ranges property, but no unit name
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
GPIO LEDs in the Cyclone5 EBV SOCrates board have a unit name but no reg
property. Indeed, GPIO LEDs do not need such a property. They do not
need a unit name neither. This will trigger the following warnings when
compiled with W=1:
Node /gpio-leds/led@0 has a unit name, but no reg property
Node /gpio-leds/led@1 has a unit name, but no reg property
Node /gpio-leds/led@2 has a unit name, but no reg property
The solution is to remove the unit name. In order to have unique node
names, a rename is necessary. This should be harmless as all the LEDs
have a 'label' property, hence their name do not derive from the node
name and will stay the same after this patch.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
The stmpe_touchscreen node in Cyclone5 MCV EVK has a reg property, but
this is not used by the driver. Moreover the binding documentation do
not define this property. Having a reg property without a unit name will
trigger the following warning when compiled with W=1:
Node /soc/i2c@ffc04000/stmpe811@41/stmpe_touchscreen has a reg or ranges
property, but no unit name
Remove the superfluous reg property.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Node eccmgr has a unit name, but do not have a reg property as only the
child nodes do have this property. Likewise the usbphy node do not have
a reg property. This will trigger the following warnings when compiled
with W=1:
Node /soc/eccmgr@ffd08140 has a unit name, but no reg property
Node /soc/usbphy@0 has a unit name, but no reg property
Remove the superfluous unit names.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Memory nodes in Arria5, Cyclone5 and Arria10 do not have a unit name.
This will trigger several warnings like this one (when compiled with
W=1):
Node /memory has a reg or ranges property, but no unit name
Add the corresponding unit name to each node.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Most clock nodes in Arria5, Cyclone5 and Arria10 have a reg property but
does not have a unit name. This will trigger several warnings like this
one (when compiled with W=1):
Node /soc/clkmgr@ffd04000/clocks/periph_pll has a reg or ranges
property, but no unit name
Add the corresponding unit name to each node.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
|
|
Always increment/decrement ucount->count under the ucounts_lock. The
increments are there already and moving the decrements there means the
locking logic of the code is simpler. This simplification in the
locking logic fixes a race between put_ucounts and get_ucounts that
could result in a use-after-free because the count could go zero then
be found by get_ucounts and then be freed by put_ucounts.
A bug presumably this one was found by a combination of syzkaller and
KASAN. JongWhan Kim reported the syzkaller failure and Dmitry Vyukov
spotted the race in the code.
Cc: stable@vger.kernel.org
Fixes: f6b2db1a3e8d ("userns: Make the count of user namespaces per user")
Reported-by: JongHwan Kim <zzoru007@gmail.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Reviewed-by: Andrei Vagin <avagin@gmail.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
|
|
Fix warnings reported when built with W=1:
Node /memory has a reg or ranges property, but no unit name
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Commit 9c0da3cc61f1 ("ARM: dts: explicitly mark skeleton.dtsi as
deprecated") declared that skeleton.dtsi was deprecated.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
|
Added two WAN status LEDs and a GPIO key for brightness which were
missing.
Signed-off-by: Aditya Xavier <adityaxavier@gmail.com>
Acked-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
It's preferred to have DT source files licensed under BSD compatible
license. All new BCM5301X DTS files use ISC so let's also relicense old
ones to it.
Except for me only Hauke was ever touched these files in his commit
9faa5960eef3 ("ARM: BCM5301X: add NAND flash chip description") and
commit bb1d8fba1965 ("ARM: BCM5301X: add NAND flash chip description for
Asus RT-AC87U").
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
|
|
write
After XFS switching to iomap based DIO (commit acdda3aae146 ("xfs:
use iomap_dio_rw")), I started to notice dio29/dio30 tests failures
from LTP run on ppc64 hosts, and they can be reproduced on x86_64
hosts with 512B/1k block size XFS too.
dio29 diotest3 -b 65536 -n 100 -i 1000 -o 1024000
dio30 diotest6 -b 65536 -n 100 -i 1000 -o 1024000
The failure message is like:
bufcmp: offset 0: Expected: 0x62, got 0x0
diotest03 1 TPASS : Read with Direct IO, Write without
diotest03 2 TFAIL : diotest3.c:142: comparsion failed; child=98 offset=1425408
diotest03 3 TFAIL : diotest3.c:194: Write Direct-child 98 failed
Direct write wrote 0x62 but buffer read got zero. This is because,
when doing direct write to a hole or preallocated file, we
invalidate the page caches before converting the extent from
unwritten state to normal state, which is done by
iomap_dio_complete(), thus leave a window for other buffer reader to
cache the unwritten state extent.
Consider this case, with sub-page blocksize XFS, two processes are
direct writing to different blocksize-aligned regions (say 512B) of
the same preallocated file, and reading the region back via buffered
I/O to compare contents.
process A, region [0,512] process B, region [512,1024]
xfs_file_write_iter
xfs_file_aio_dio_write
iomap_dio_rw
iomap_apply
invalidate_inode_pages2_range
xfs_file_write_iter
xfs_file_aio_dio_write
iomap_dio_rw
iomap_apply
invalidate_inode_pages2_range
iomap_dio_complete
xfs_file_read_iter
xfs_file_buffered_aio_read
generic_file_read_iter
do_generic_file_read
<readahead fills pagecache with 0>
iomap_dio_complete
xfs_file_read_iter
<read gets 0 from pagecache>
Process A first invalidates page caches, at this point the
underlying extent is still in unwritten state (iomap_dio_complete
not called yet), and process B finishs direct write and populates
page caches via readahead, which caches zeros in page for region A,
then process A reads zeros from page cache, instead of the actual
data.
Fix it by invalidating page caches after converting unwritten extent
to make sure we read content from disk after extent state changed,
as what we did before switching to iomap based dio.
Also introduce a new 'start' variable to save the original write
offset (iomap_dio_complete() updates iocb->ki_pos), and a 'err'
variable for invalidating caches result, cause we can't reuse 'ret'
anymore.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
|
|
The modules stay disabled by default, and if you want to enable DSI
you'll need an overlay that connects a panel to it.
Signed-off-by: Eric Anholt <eric@anholt.net>
|
|
VMCLEAR should silently ignore a failure to clear the launch state of
the VMCS referenced by the operand.
Signed-off-by: Jim Mattson <jmattson@google.com>
[Changed "kvm_write_guest(vcpu->kvm" to "kvm_vcpu_write_guest(vcpu".]
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
|
|
Droid4's touchscreen can be used with mainline's maxtouch driver. The
touchscreen's lower area is used for four soft buttons (KEY_MENU,
KEY_HOME, KEY_BACK, KEY_SEARCH), but that does not seem to be currently
supported by the mainline kernel.
The mxt224 configuration can be saved with "mxt-app" for the kernel
to load. It can be saved after the first boot with:
# mxt-app -d i2c-dev:1-004a --save /lib/firmware/maxtouch.cfg
Where the mxt-app can be found at:
https://github.com/atmel-maxtouch/mxt-app
The firmware for the droid 4 mxt224 comes with GPLv2 license in the
Motorola Linux kernel sources. This firmware can be dumped out with
"droid4-touchscreen-firmware" program at:
https://github.com/tmlind/droid4-touchscreen-firmware
The related LCD patches are still pending, but when merged,
the touchscreen can be rotated in X with something like:
# xrandr --output DSI-1 --rotate right
# xinput set-prop 6 'Coordinate Transformation Matrix' \
0 1 0 -1 0 1 0 0 1
For now, we rely on a gpio-hog but later on we can add the reset
gpio handling to the driver and have it load the maxtouch.cfg and
maxtouch.fw on boot.
This patch is based on combined similar patches done by me and
Sebastian.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add accelerometer.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add compass.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add power button.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
Add rtc.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
On Droid 4 "Volume Down" and "Keypad Slide" keys are
connected via SoC GPIOs, "Power Key" via CPCAP and
all other keys via SoC keypad Matrix. This adds the
GPIO keys.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
[tony@atomide.com: updated to apply on omap4-keypad patch]
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
With drivers/mfd/motorola-cpcap.c and drivers/regulator/cpcap-regulator.c
we can now configure proper regulators for droid 4.
Let's add regulator voltages and switch over MMC, eMMC and WLAN to use
the CPCAP regulators.
Cc: devicetree@vger.kernel.org
Cc: Marcel Partap <mpartap@gmx.net>
Cc: Michael Scott <michael.scott@linaro.org>
Tested-By: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
|
|
In the function scan_dma_completions() there is a reusage of tmp
variable. That coused a wrong value being used in some case when
reading a short packet terminated transaction from an endpoint,
in 2 concecutive reads.
This was my logic for the patch:
The req->td->dmadesc equals to 0 iff:
-- There was a transaction ending with a short packet, and
-- The read() to read it was shorter than the transaction length, and
-- The read() to complete it is longer than the residue.
I believe this is true from the printouts of various cases,
but I can't be positive it is correct.
Entering this if, there should be no more data in the endpoint
(a short packet terminated the transaction).
If there is, the transaction wasn't really done and we should exit and
wait for it to finish entirely. That is the inner if.
That inner if should never happen, but it is there to be on the safe
side. That is why it is marked with the comment /* paranoia */.
The size of the data available in the endpoint is ep->dma->dmacount
and it is read to tmp.
This entire clause is based on my own educated guesses.
If we passed that inner if without breaking in the original code,
than tmp & DMA_BYTE_MASK_COUNT== 0.
That means we will always pass dma bytes count of 0 to dma_done(),
meaning all the requested bytes were read.
dma_done() reports back to the upper layer that the request (read())
was done and how many bytes were read.
In the original code that would always be the request size,
regardless of the actual size of the data.
That did not make sense to me at all.
However, the original value of tmp is req->td->dmacount,
which is the dmacount value when the request's dma transaction was
finished. And that is a much more reasonable value to report back to
the caller.
To recreate the problem:
Read from a bulk out endpoint in a loop, 1024 * n bytes in each
iteration.
Connect the PLX to a host you can control.
Send to that endpoint 1024 * n + x bytes,
such that 0 < x < 1024 * n and (x % 1024) != 0
You would expect the first read() to return 1024 * n
and the second read() to return x.
But you will get the first read to return 1024 * n
and the second one to return 1024 * n.
That is true for every positive integer n.
Cc: Felipe Balbi <balbi@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Signed-off-by: Raz Manor <Raz.Manor@valens.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
A call usb_put_phy(udc->transceiver) must be tested for a valid pointer.
Use an already existing test for usb_unregister_notifier call.
Acked-by: Robert Jarzmik <robert.jarzmik@free.fr>
Reported-by: Robert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: Petr Cvek <petr.cvek@tul.cz>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
We need to break from all cases if we want to treat
each one of them separately.
Reported-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Fixes: d2728fb3e01f ("usb: dwc3: omap: Pass VBUS and ID events transparently")
Cc: <stable@vger.kernel.org> #v4.8+
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
On TI platforms (dra7, am437x), the DWC3_DSTS_DEVCTRLHLT bit is not set
after the device controller is stopped via DWC3_DCTL_RUN_STOP.
If we don't disconnect and stop the gadget, it stops working after a
system resume with the trace below.
There is no point in preventing gadget disconnect and gadget stop during
system suspend/resume as we're going to suspend in any case, whether
DEVCTRLHLT timed out or not.
[ 141.727480] ------------[ cut here ]------------
[ 141.732349] WARNING: CPU: 1 PID: 2135 at drivers/usb/dwc3/gadget.c:2384 dwc3_stop_active_transfer.constprop.4+0xc4/0xe4 [dwc3]
[ 141.744299] Modules linked in: usb_f_ss_lb g_zero libcomposite xhci_plat_hcd xhci_hcd usbcore dwc3 evdev udc_core m25p80 usb_common spi_nor snd_soc_davinci_mcasp snd_soc_simple_card snd_soc_edma snd_soc_tlv3e
[ 141.792163] CPU: 1 PID: 2135 Comm: irq/456-dwc3 Not tainted 4.10.0-rc8 #1138
[ 141.799547] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 141.805940] [<c01101b4>] (unwind_backtrace) from [<c010c31c>] (show_stack+0x10/0x14)
[ 141.814066] [<c010c31c>] (show_stack) from [<c04a0918>] (dump_stack+0xac/0xe0)
[ 141.821648] [<c04a0918>] (dump_stack) from [<c013708c>] (__warn+0xd8/0x104)
[ 141.828955] [<c013708c>] (__warn) from [<c0137164>] (warn_slowpath_null+0x20/0x28)
[ 141.836902] [<c0137164>] (warn_slowpath_null) from [<bf27784c>] (dwc3_stop_active_transfer.constprop.4+0xc4/0xe4 [dwc3])
[ 141.848329] [<bf27784c>] (dwc3_stop_active_transfer.constprop.4 [dwc3]) from [<bf27ab14>] (__dwc3_gadget_ep_disable+0x64/0x528 [dwc3])
[ 141.861034] [<bf27ab14>] (__dwc3_gadget_ep_disable [dwc3]) from [<bf27c27c>] (dwc3_gadget_ep_disable+0x3c/0xc8 [dwc3])
[ 141.872280] [<bf27c27c>] (dwc3_gadget_ep_disable [dwc3]) from [<bf23b428>] (usb_ep_disable+0x11c/0x18c [udc_core])
[ 141.883160] [<bf23b428>] (usb_ep_disable [udc_core]) from [<bf342774>] (disable_ep+0x18/0x54 [usb_f_ss_lb])
[ 141.893408] [<bf342774>] (disable_ep [usb_f_ss_lb]) from [<bf3437b0>] (disable_endpoints+0x18/0x50 [usb_f_ss_lb])
[ 141.904168] [<bf3437b0>] (disable_endpoints [usb_f_ss_lb]) from [<bf343814>] (disable_source_sink+0x2c/0x34 [usb_f_ss_lb])
[ 141.915771] [<bf343814>] (disable_source_sink [usb_f_ss_lb]) from [<bf329a9c>] (reset_config+0x48/0x7c [libcomposite])
[ 141.927012] [<bf329a9c>] (reset_config [libcomposite]) from [<bf329afc>] (composite_disconnect+0x2c/0x54 [libcomposite])
[ 141.938444] [<bf329afc>] (composite_disconnect [libcomposite]) from [<bf23d7dc>] (usb_gadget_udc_reset+0x10/0x34 [udc_core])
[ 141.950237] [<bf23d7dc>] (usb_gadget_udc_reset [udc_core]) from [<bf276d70>] (dwc3_gadget_reset_interrupt+0x64/0x698 [dwc3])
[ 141.962022] [<bf276d70>] (dwc3_gadget_reset_interrupt [dwc3]) from [<bf27952c>] (dwc3_thread_interrupt+0x618/0x1a3c [dwc3])
[ 141.973723] [<bf27952c>] (dwc3_thread_interrupt [dwc3]) from [<c01a7ce8>] (irq_thread_fn+0x1c/0x54)
[ 141.983215] [<c01a7ce8>] (irq_thread_fn) from [<c01a7fbc>] (irq_thread+0x120/0x1f0)
[ 141.991247] [<c01a7fbc>] (irq_thread) from [<c015ba14>] (kthread+0xf8/0x138)
[ 141.998641] [<c015ba14>] (kthread) from [<c01078f0>] (ret_from_fork+0x14/0x24)
[ 142.006213] ---[ end trace b4ecfe9f175b9a9c ]---
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
This reverts commit ac670a3a650b899fc020b81f63e810d06015b865.
This introduce bug we already fixed in
commit 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 wof OS_DESC_EXT_COMPAT")
Next FFS (adb) SS enumeration fail with Windows OS.
Signed-off-by: Janusz Dziedzic <januszx.dziedzic@linux.intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
'kbuf' is allocated just a few lines above using 'memdup_user()'.
If the 'if (dev->buf)' test fails, this memory is never released.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
The debug output now contains the wrong variable, as seen from the compiler
warning:
drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable':
drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used uninitialized in this function [-Werror=maybe-uninitialized]
DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
This changes the debug output the same way as the other code.
Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation scheme")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
The utmi mode is unsigned according the dt-bindings.
Fix sparse issue (-Wtypesign):
drivers/usb/dwc3/dwc3-omap.c:391:50: warning: incorrect type in argument 3 (different signedness)
drivers/usb/dwc3/dwc3-omap.c:391:50: expected unsigned int [usertype] *out_value
drivers/usb/dwc3/dwc3-omap.c:391:50: got int *<noident>
Signed-off-by: Franck Demathieu <fdemathieu@gmail.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
When binding a gadget to a device, "name" is stored in gi->udc_name, but
this does not happen when unregistering and the string is leaked.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
Fix following build error for s390:
drivers/vfio/vfio_iommu_type1.c: In function 'vfio_iommu_type1_attach_group':
drivers/vfio/vfio_iommu_type1.c:1290:25: error: implicit declaration of function 'irq_domain_check_msi_remap'
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Mian Yousaf Kaukab <yousaf.kaukab@suse.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
The max and entry variables are unsigned according to the dt-bindings.
Fix following 3 sparse issues (-Wtypesign):
drivers/irqchip/irq-crossbar.c:222:52: warning: incorrect type in argument 3 (different signedness)
drivers/irqchip/irq-crossbar.c:222:52: expected unsigned int [usertype] *out_value
drivers/irqchip/irq-crossbar.c:222:52: got int *<noident>
drivers/irqchip/irq-crossbar.c:245:56: warning: incorrect type in argument 4 (different signedness)
drivers/irqchip/irq-crossbar.c:245:56: expected unsigned int [usertype] *out_value
drivers/irqchip/irq-crossbar.c:245:56: got int *<noident>
drivers/irqchip/irq-crossbar.c:263:56: warning: incorrect type in argument 4 (different signedness)
drivers/irqchip/irq-crossbar.c:263:56: expected unsigned int [usertype] *out_value
drivers/irqchip/irq-crossbar.c:263:56: got int *<noident>
Signed-off-by: Franck Demathieu <fdemathieu@gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
When the user does device unbind and rebind test, the kernel will
show below dump due to usb_gadget memory region is dirty after unbind.
Clear usb_gadget region for every new probe.
root@imx6qdlsolo:/sys/bus/platform/drivers/dummy_udc# echo dummy_udc.0 > bind
[ 102.523312] kobject (eddd78b0): tried to init an initialized object, something is seriously wrong.
[ 102.532447] CPU: 0 PID: 734 Comm: sh Not tainted 4.10.0-rc7-00872-g1b2b8e9 #1298
[ 102.539866] Hardware name: Freescale i.MX6 SoloX (Device Tree)
[ 102.545717] Backtrace:
[ 102.548225] [<c010d090>] (dump_backtrace) from [<c010d338>] (show_stack+0x18/0x1c)
[ 102.555822] r7:ede34000 r6:60010013 r5:00000000 r4:c0f29418
[ 102.561512] [<c010d320>] (show_stack) from [<c040c2a4>] (dump_stack+0xb4/0xe8)
[ 102.568764] [<c040c1f0>] (dump_stack) from [<c040e6d4>] (kobject_init+0x80/0x9c)
[ 102.576187] r10:0000001f r9:eddd7000 r8:eeaf8c10 r7:eddd78a8 r6:c177891c r5:c0f3b060
[ 102.584036] r4:eddd78b0 r3:00000000
[ 102.587641] [<c040e654>] (kobject_init) from [<c05359a4>] (device_initialize+0x28/0xf8)
[ 102.595665] r5:eebc4800 r4:eddd78a8
[ 102.599268] [<c053597c>] (device_initialize) from [<c05382ac>] (device_register+0x14/0x20)
[ 102.607556] r7:eddd78a8 r6:00000000 r5:eebc4800 r4:eddd78a8
[ 102.613256] [<c0538298>] (device_register) from [<c0668ef4>] (usb_add_gadget_udc_release+0x8c/0x1ec)
[ 102.622410] r5:eebc4800 r4:eddd7860
[ 102.626015] [<c0668e68>] (usb_add_gadget_udc_release) from [<c0669068>] (usb_add_gadget_udc+0x14/0x18)
[ 102.635351] r10:0000001f r9:eddd7000 r8:eddd788c r7:bf003770 r6:eddd77f8 r5:eddd7818
[ 102.643198] r4:eddd785c r3:eddd7b24
[ 102.646834] [<c0669054>] (usb_add_gadget_udc) from [<bf003428>] (dummy_udc_probe+0x170/0x1c4 [dummy_hcd])
[ 102.656458] [<bf0032b8>] (dummy_udc_probe [dummy_hcd]) from [<c053d114>] (platform_drv_probe+0x54/0xb8)
[ 102.665881] r10:00000008 r9:c1778960 r8:bf004128 r7:fffffdfb r6:bf004128 r5:eeaf8c10
[ 102.673727] r4:eeaf8c10
[ 102.676293] [<c053d0c0>] (platform_drv_probe) from [<c053b160>] (driver_probe_device+0x264/0x474)
[ 102.685186] r7:00000000 r6:00000000 r5:c1778960 r4:eeaf8c10
[ 102.690876] [<c053aefc>] (driver_probe_device) from [<c05397c4>] (bind_store+0xb8/0x14c)
[ 102.698994] r10:eeb3bb4c r9:ede34000 r8:0000000c r7:eeaf8c44 r6:bf004128 r5:c0f3b668
[ 102.706840] r4:eeaf8c10
[ 102.709402] [<c053970c>] (bind_store) from [<c0538ca8>] (drv_attr_store+0x28/0x34)
[ 102.716998] r9:ede34000 r8:00000000 r7:ee3863c0 r6:ee3863c0 r5:c0538c80 r4:c053970c
[ 102.724776] [<c0538c80>] (drv_attr_store) from [<c029c930>] (sysfs_kf_write+0x50/0x54)
[ 102.732711] r5:c0538c80 r4:0000000c
[ 102.736313] [<c029c8e0>] (sysfs_kf_write) from [<c029be84>] (kernfs_fop_write+0x100/0x214)
[ 102.744599] r7:ee3863c0 r6:eeb3bb40 r5:00000000 r4:00000000
[ 102.750287] [<c029bd84>] (kernfs_fop_write) from [<c0222dd8>] (__vfs_write+0x34/0x120)
[ 102.758231] r10:00000000 r9:ede34000 r8:c0108bc4 r7:0000000c r6:ede35f80 r5:c029bd84
[ 102.766077] r4:ee223780
[ 102.768638] [<c0222da4>] (__vfs_write) from [<c0224678>] (vfs_write+0xa8/0x170)
[ 102.775974] r9:ede34000 r8:c0108bc4 r7:ede35f80 r6:01861cb0 r5:ee223780 r4:0000000c
[ 102.783743] [<c02245d0>] (vfs_write) from [<c0225498>] (SyS_write+0x4c/0xa8)
[ 102.790818] r9:ede34000 r8:c0108bc4 r7:0000000c r6:01861cb0 r5:ee223780 r4:ee223780
[ 102.798595] [<c022544c>] (SyS_write) from [<c0108a20>] (ret_fast_syscall+0x0/0x1c)
[ 102.806188] r7:00000004 r6:b6e83d58 r5:01861cb0 r4:0000000c
Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers")
Cc: stable <stable@vger.kernel.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Peter Chen <peter.chen@nxp.com>
Tested-by: Xiaolong Ye <xiaolong.ye@intel.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
This reverts commit 4fbac5206afd01b717d4bdc58793d471f3391b4b.
This commit breaks g_webcam when used with uvc-gadget [1].
The user space application (e.g. uvc-gadget) is responsible for
sending response to UVC class specific requests on control endpoint
in uvc_send_response() in uvc_v4l2.c.
The bad commit was causing a duplicate response to be sent with
incorrect response data thus causing UVC probe to fail at the host
and broken control transfer endpoint at the gadget.
[1] - git://git.ideasonboard.org/uvc-gadget.git
Cc: <stable@vger.kernel.org> # v4.9+
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
|
|
After several hours of debugging this obviously bogus but elaborate
gcc-7.0.1 warning,
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c: In function 'vchiq_complete_bulk':
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c:603:4: error: argument 2 null where non-null expected [-Werror=nonnull]
memcpy((char *)page_address(pages[0]) +
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pagelist->offset,
~~~~~~~~~~~~~~~~~
fragments,
~~~~~~~~~~
head_bytes);
~~~~~~~~~~~
In file included from include/linux/string.h:18:0,
from include/linux/bitmap.h:8,
from include/linux/cpumask.h:11,
from include/linux/interrupt.h:9,
from drivers/staging/vc04_services/interface/vchiq_arm/vchiq_2835_arm.c:37:
arch/arm/include/asm/string.h:16:15: note: in a call to function 'memcpy' declared here
extern void * memcpy(void *, const void *, __kernel_size_t) __nocapture(2);
^~~~~~
I have concluded that gcc was technically right in the first place:
vchiq_complete_bulk is an externally visible function that calls
free_pagelist(), which in turn derives a pointer from the global
g_fragments_base variable.
g_fragments_base is initialized in vchiq_platform_init(), but
we only get there if of_property_read_u32() successfully reads the
cache line size. When CONFIG_OF is disabled, this always fails, and
g_fragments_base is guaranteed to be NULL when vchiq_complete_bulk()
gets called.
This adds a CONFIG_OF Kconfig dependency, which is also technically correct
but nonobvious, and thus seems like a good fit for the warning.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This patch changes pin names of AIO and XIRQ according to updated
specification.
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The get_direction callback function allows gpiolib to know the current
direction (input vs output) for a given GPIO.
This is particularly useful on ACPI systems, where the GPIOs are
configured only by firmware (typically UEFI), so the only way to
know the initial values to query the hardware directly. Without
this function, gpiolib thinks that all GPIOs are configured for
input.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
On Kernel 4.9, WARNINGs about doing DMA on stack are hit at
the dw2102 driver: one in su3000_power_ctrl() and the other in tt_s2_4600_frontend_attach().
Both were due to the use of buffers on the stack as parameters to
dvb_usb_generic_rw() and the resulting attempt to do DMA with them.
The device was non-functional as a result.
So, switch this driver over to use a buffer within the device state
structure, as has been done with other DVB-USB drivers.
Tested with TechnoTrend TT-connect S2-4600.
[mchehab@osg.samsung.com: fixed a warning at su3000_i2c_transfer() that
state var were dereferenced before check 'd']
Signed-off-by: Jonathan McDowell <noodles@earth.li>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
|
