According to pinctrl assignment for Pro4, each definition of USB#2 and
USB#3 are as follows.
184: USB2VBUS
185: USB2OD
186: USB2ID
187: USB3VBUS
188: USB3OD
USB#2 has an additional pin "USB2ID", but the chip doesn't use this pin
while in host-mode. Considering this pin, the pin definitions for USB#3
should be {187, 188}.
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>
Fixes the following warnings when building docs:
../include/drm/drm_drv.h:553: warning: No description found for parameter 'debugfs_init'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_open_object'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_close_object'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'prime_handle_to_fd'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'prime_fd_to_handle'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_prime_export'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_prime_import'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'gem_vm_ops'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'major'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'minor'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'patchlevel'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'name'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'desc'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'date'
../include/drm/drm_drv.h:553: warning: No description found for parameter 'driver_features'
There are still a couple more warnings for prime helpers that are
documented elsewhere.
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170720174746.29100-5-seanpaul@chromium.org
Without a quirk or the X Window System, this device disconnects every
60 seconds. This patch also renames the define associated with the
Logitech 0xc007 product ID, which appeared to have a conflicting typo.
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Kyle Roarty <kroarty@xes-inc.com>
Signed-off-by: Aaron Sierra <asierra@xes-inc.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Add support for the Bananapi R2 (BPI-R2) development board from
BIPAI KEJI. Detailed hardware information for BPI-R2 which could be
found on http://www.banana-pi.org/r2.html
The patch added nodes into the SoC-level file mt7623.dtsi such as CPU OPP
table and thermal zone treating CPU as one of cooling devices and also
added nodes into board-level file mt7623n-bananapi-bpi-r2.dts such as
MediaTek GMAC, MT7530 Switch, the crypto engine, USB, IR, I2S, I2C, UART,
SPI, PWM, GPIO keys, GPIO LEDs and PMIC LEDs. As to the other missing
hardware and peripherals, they would be added and integrated continuously.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
All versions of the mt7623n RFB have an USB port so enable the device.
There is a gpio that gets used to power up the port supply. Add support
for this gpio using the fixed-regulator driver.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
This patch does a cleanup of the uart nodes in the dts file of the RFB. It
adds aliases, enables 2 more uarts and explicitly sets the uart mode of the
console.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
There are 2 versions of the MT7623 SoC, the one is MT7623N and the other
is MT7623A. MT7623N is almost identical to MT7623A but has some
additional multimedia features. The reference boards are available as
NAND or MMC and might have a different ethernet setup. In order to reduce
the duplication of devicetree code we add an intermediate dtsi file for
these reference boards. Additionally MediaTek pointed out, that the EVB
is yet another board and the board in question is infact the RFB. Take
this into account while renaming the files.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
MediaTek produces various PMICs. Which one is used depends on the actual
circuit design. Instead of adding the correct PMIC node to every dts file
we instead add a new intermediate dtsi file which adds the PMIC node. For
those boards with the same PMIC, the intermediate mt6323.dtsi could be
reused to save more redundant nodes created on each board device-tree
files.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Because there are two versions of MT7623 SoC that is MT7623a and MT7623n
respectively. So update the part of MT7623n bindings to allow that people
tend to differentiate which MT7623 SoC the boards applies.
And "mediatek,mt7623-evb" can be safely changed to
"mediatek,mt7623n-rfb-nand" because mt7623-evb is a kind of debug board
internally in Mediatek which real users can't get. So instead we should
indicate which variants it belongs to with more specific postfix as the
adding here to let people easily know what board they use.
Signed-off-by: John Crispin <john@phrozen.org>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
On one of my test machines nhi_mailbox_cmd() called from icm_suspend()
times out and returnes an error which then is propagated to the
caller and causes the entire system suspend to be aborted which isn't
very useful.
Instead of aborting system suspend, print the error into the log
and continue.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Michael Jamet <michael.jamet@intel.com>
This patch replaces an rwlock and raw notifier by an atomic notifier
protected by a spin_lock and RCU.
The main reason for this change is due to a 'scheduling while atomic'
bug with RT kernels on ARM/ARM64. On ARM/ARM64, the rwlock
cpu_pm_notifier_lock in cpu_pm_enter/exit() causes a potential
schedule after IRQ disable in the idle call chain:
cpu_startup_entry
cpu_idle_loop
local_irq_disable()
cpuidle_idle_call
call_cpuidle
cpuidle_enter
cpuidle_enter_state
->enter :arm_enter_idle_state
cpu_pm_enter/exit
CPU_PM_CPU_IDLE_ENTER
read_lock(&cpu_pm_notifier_lock); <-- sleep in idle
__rt_spin_lock();
schedule();
The kernel panic is here:
[ 4.609601] BUG: scheduling while atomic: swapper/1/0/0x00000002
[ 4.609608] [<ffff0000086fae70>] arm_enter_idle_state+0x18/0x70
[ 4.609614] Modules linked in:
[ 4.609615] [<ffff0000086f9298>] cpuidle_enter_state+0xf0/0x218
[ 4.609620] [<ffff0000086f93f8>] cpuidle_enter+0x18/0x20
[ 4.609626] Preemption disabled at:
[ 4.609627] [<ffff0000080fa234>] call_cpuidle+0x24/0x40
[ 4.609635] [<ffff000008882fa4>] schedule_preempt_disabled+0x1c/0x28
[ 4.609639] [<ffff0000080fa49c>] cpu_startup_entry+0x154/0x1f8
[ 4.609645] [<ffff00000808e004>] secondary_start_kernel+0x15c/0x1a0
Daniel Lezcano said this notification is needed on arm/arm64 platforms.
Sebastian suggested using atomic_notifier instead of rwlock, which is not
only removing the sleeping in idle, but also improving latency.
Tony Lindgren found a miss use that rcu_read_lock used after rcu_idle_enter
Paul McKenney suggested trying RCU_NONIDLE.
Signed-off-by: Alex Shi <alex.shi@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
[ rjw: Subject & changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
X-Gene platforms describe multiple GHES error sources with the same
hardware error notification type (external interrupt) and interrupt
number.
Change the GHES interrupt request to support sharing the same IRQ.
This change includs contributions from Tuan Phan <tphan@apm.com>.
Signed-off-by: Loc Ho <lho@apm.com>
Acked-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Force alignment value to the default one (1 byte) if uninitialized.
This fixes hci_ll serdev driver (alignment = 0) and avoid any further
issues with upcoming drivers.
Signed-off-by: Loic Poulain <loic.poulain@gmail.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The watchdog soft-NMI exception stack setup loads a stack pointer
twice, which is an obvious error. It ends up using the system reset
interrupt (true-NMI) stack, which is also a bug because the watchdog
could be preempted by a system reset interrupt that overwrites the
NMI stack.
Change the soft-NMI to use the "emergency stack". The current kernel
stack is not used, because of the longer-term goal to prevent
asynchronous stack access using soft-disable.
Fixes: 2104180a53 ("powerpc/64s: implement arch-specific hardlockup watchdog")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
The fixes branch is based off a random pre-rc1 commit, because we had
some fixes that needed to go in before rc1 was released.
However we now need to fix some code that went in after that point, but
before rc1, so merge rc1 to get that code into fixes so we can fix it!
The for_each_child_of_node macro itself maintains the correct reference
count of the nodes so the explicit of_node_put() call causes a warning:
[ 0.098960] OF: ERROR: Bad of_node_put() on /pmc@7000e400/powergates/xusba
[ 0.098981] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.3 #1-NixOS
[ 0.098996] Hardware name: NVIDIA Jetson TX1 Developer Kit (DT)
[ 0.099011] Call trace:
[ 0.099034] [<ffff00000808a048>] dump_backtrace+0x0/0x2a0
[ 0.099051] [<ffff00000808a30c>] show_stack+0x24/0x30
[ 0.099069] [<ffff0000084a6494>] dump_stack+0x9c/0xc0
[ 0.099090] [<ffff000008992214>] of_node_release+0xa4/0xa8
[ 0.099107] [<ffff0000084a9270>] kobject_put+0x90/0x1f8
[ 0.099124] [<ffff0000089914ac>] of_node_put+0x24/0x30
[ 0.099140] [<ffff00000898cec4>] __of_get_next_child+0x4c/0x70
[ 0.099155] [<ffff00000898cf28>] of_get_next_child+0x40/0x68
[ 0.099173] [<ffff0000090a099c>] tegra_pmc_early_init+0x4e8/0x5ac
[ 0.099189] [<ffff00000808399c>] do_one_initcall+0x5c/0x168
[ 0.099206] [<ffff000009050c98>] kernel_init_freeable+0xd4/0x240
[ 0.099224] [<ffff000008b2d658>] kernel_init+0x18/0x108
[ 0.099238] [<ffff0000080836c0>] ret_from_fork+0x10/0x50
(It's not very apparent from the OF documentation that of_node_put() is
not needed; the macro itself has no docstring and of_get_next_child()
used in the implementation begins with "Returns a node pointer with
refcount incremented" but then only at the very end of the docstring
the crucial part "Decrements the refcount of prev" is mentioned.)
Fixes: a38045121b ("soc/tegra: pmc: Add generic PM domain support")
Signed-off-by: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This patch fixes an issue in the translation table code potentially
leading to a TT Request + Response storm. The issue may occur for nodes
involving BLA and an inconsistent configuration of the batman-adv AP
isolation feature. However, since the new multicast optimizations, a
single, malformed packet may lead to a mesh-wide, persistent
Denial-of-Service, too.
The issue occurs because nodes are currently OR-ing the TT sync flags of
all originators announcing a specific MAC address via the
translation table. When an intermediate node now receives a TT Request
and wants to answer this on behalf of the destination node, then this
intermediate node now responds with an altered flag field and broken
CRC. The next OGM of the real destination will lead to a CRC mismatch
and triggering a TT Request and Response again.
Furthermore, the OR-ing is currently never undone as long as at least
one originator announcing the according MAC address remains, leading to
the potential persistency of this issue.
This patch fixes this issue by storing the flags used in the CRC
calculation on a a per TT orig entry basis to be able to respond with
the correct, original flags in an intermediate TT Response for one
thing. And to be able to correctly unset sync flags once all nodes
announcing a sync flag vanish for another.
Fixes: e9c00136a4 ("batman-adv: fix tt_global_entries flags update")
Signed-off-by: Linus Lüssing <linus.luessing@c0d3.blue>
Acked-by: Antonio Quartulli <a@unstable.cc>
[sw: typo in commit message]
Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
The Amlogic Meson8/Meson8b/Meson8m2 clock controller provides some reset
lines. These are used for example to boot the secondary CPU cores.
This patch describes the reset controller which is embedded into the
clock controller on these SoCs.
A header file is provided which provides preprocessor macros for each
reset line (to make the .dts files easier to read).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
The offset of hugepage block will not be 16G, if the expected
page is more than one. Calculate the totol size instead of the
hardcode value.
Fixes: 4792adbac9 ("powerpc: Don't use a 16G page if beyond mem= limits")
Signed-off-by: Rui Teng <rui.teng@linux.vnet.ibm.com>
Tested-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
For debugging very early boot problems we have CONFIG_PPC_EARLY_DEBUG,
which allows configuring the kernel such that it unconditionally writes
to a particular type of console, regardless of whether that console
exists or not. This is useful sometimes when the kernel crashes before
it can even determine what platform it's on, and therefore what consoles
exist.
However if you boot a kernel built this way on a different platform, it
will generally crash because it writes to a console that doesn't exist.
A particularly nasty instance of this is if you enable the hypervisor
console early debug, and then boot that kernel on bare metal. The result
is that the kernel calls "the hypervisor" very early in boot, but the
kernel *is* the hypervisor, so we jump to the system call handler and
start executing all sorts of code that isn't ready to be run. This may
lead to a machine check or check stop depending on how lucky you are.
Luckily there is an easy way to avoid this particular case. We simply
read the MSR before installing the hooks, and if we see MSR_HV is set
then we are the hypervisor and we definitely should not use the
hypervisor console.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Although pretty much everyone using powernv is running little endian,
we should still test we can build for big endian. So add a
powernv_be_defconfig, which is autogenerated by flipping the endian
symbol in powernv_defconfig.
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Cyril Bur <cyrilbur@gmail.com>
Since kernel 4.11 the thread and irq stacks on parisc randomly overflow
the default size of 16k. The reason why stack usage suddenly grew is yet
unknown.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: stable@vger.kernel.org # 4.11+
Signed-off-by: Helge Deller <deller@gmx.de>
In testing James' patch to drivers/parisc/pdc_stable.c, I hit the BUG
statement in flush_cache_range() during a system shutdown:
kernel BUG at arch/parisc/kernel/cache.c:595!
CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1
Workqueue: events free_ioctx
IAOQ[0]: flush_cache_range+0x144/0x148
IAOQ[1]: flush_cache_page+0x0/0x1a8
RP(r2): flush_cache_range+0xec/0x148
Backtrace:
[<00000000402910ac>] unmap_page_range+0x84/0x880
[<00000000402918f4>] unmap_single_vma+0x4c/0x60
[<0000000040291a18>] zap_page_range_single+0x110/0x160
[<0000000040291c34>] unmap_mapping_range+0x174/0x1a8
[<000000004026ccd8>] truncate_pagecache+0x50/0xa8
[<000000004026cd84>] truncate_setsize+0x54/0x70
[<000000004033d534>] put_aio_ring_file+0x44/0xb0
[<000000004033d5d8>] aio_free_ring+0x38/0x140
[<000000004033d714>] free_ioctx+0x34/0xa8
[<00000000401b0028>] process_one_work+0x1b8/0x4d0
[<00000000401b04f4>] worker_thread+0x1b4/0x648
[<00000000401b9128>] kthread+0x1b0/0x208
[<0000000040150020>] end_fault_vector+0x20/0x28
[<0000000040639518>] nf_ip_reroute+0x50/0xa8
[<0000000040638ed0>] nf_ip_route+0x10/0x78
[<0000000040638c90>] xfrm4_mode_tunnel_input+0x180/0x1f8
CPU: 2 PID: 6532 Comm: kworker/2:0 Not tainted 4.13.0-rc2+ #1
Workqueue: events free_ioctx
Backtrace:
[<0000000040163bf0>] show_stack+0x20/0x38
[<0000000040688480>] dump_stack+0xa8/0x120
[<0000000040163dc4>] die_if_kernel+0x19c/0x2b0
[<0000000040164d0c>] handle_interruption+0xa24/0xa48
This patch modifies flush_cache_range() to handle non current contexts.
In as much as this occurs infrequently, the simplest approach is to
flush the entire cache when this happens.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Cc: stable@vger.kernel.org # 4.9+
Signed-off-by: Helge Deller <deller@gmx.de>
For some odd reason, it forces a byte-by-byte copy of each field. A
plain old swap() on most of these fields would be more efficient. We
do need to retain the memswap of i_data however as that field is an array.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
A CMA memory pool reserved memory node is added, and is attached to
the DSP node through the 'memory-region' property on the K2E EVM board.
This area will be used for allocating virtio rings and buffers. This
node allows the DSP Memory Protection and Address Extension (MPAX)
module to be configured properly for the DSP processor, and matches
the values used on the other Keystone 2 boards for software
compatibility.
The reserved memory node and the user DSP node are also marked okay
to enable the DSP on the 66AK2E EVM board.
Signed-off-by: Sam Nelson <sam.nelson@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
A common CMA memory pool reserved memory node is added, and is attached
to all the DSP nodes through the 'memory-region' property on the 66AK2L
EVM board. This area will be used for allocating virtio rings and buffers.
The common node allows the DSP Memory Protection and Address Extension
(MPAX) module to be configured uniformly across all the DSP processors.
The reserved memory node and all the user DSP nodes are also marked okay
to enable the DSPs on the 66AK2L EVM board.
Signed-off-by: Sam Nelson <sam.nelson@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
A common CMA memory pool reserved memory node is added, and is attached
to all the DSP nodes through the 'memory-region' property on the 66AK2H
EVM board. This area will be used for allocating virtio rings and buffers.
The common node allows the DSP Memory Protection and Address Extension
(MPAX) module to be configured uniformly across all the DSP processors.
The reserved memory node and all the user DSP nodes are also marked okay
to enable the DSPs on the 66AK2K EVM board.
Signed-off-by: Sam Nelson <sam.nelson@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
The Keystone 2 66AK2E SoC has one TMS320C66x DSP Core Subsystem
(C66x CorePac), with a 1.4 GHz C66x Fixed or Floating-Point DSP
Core, and 32 KB of L1P & L1D SRAMs and a 1 MB L2 SRAM. Add the
DT node for this DSP processor sub-system. The processor does
not have a MMU, and uses various IPC Generation registers and
shared memory for inter-processor communication. The alias with
a stem 'rproc' has also been added for the DSP, it provides a
fixed remoteproc id for the DSP processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <sam.nelson@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
The Keystone 2 66AK2L SoCs have 4 TMS320C66x DSP Core Subsystems
(C66x CorePacs), each with a 1.0 GHz or 1.2 GHz C66x Fixed /
Floating-Point DSP Core, and 32 KB of L1P & L1D SRAMs and a 1 MB
L2 SRAM. Add the DT nodes for these DSP processor sub-systems.
The processors do not have an MMU, and use various IPC Generation
registers and shared memory for inter-processor communication.
The aliases with a stem 'rproc' have also been added for all the
DSPs, they provide a fixed remoteproc id to each DSP processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <sam.nelson@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
The Keystone 2 66AK2H/66AK2K SoCs have upto 8 TMS320C66x DSP Core
Subsystems (C66x CorePacs), each with a 1.0 GHz or 1.2 GHz C66x
Fixed/Floating-Point DSP Core, and 32 KB of L1P & L1D SRAMs and a
1 MB L2 SRAM. Add the DT nodes for these DSP processor sub-systems.
The processors do not have an MMU, and use various IPC Generation
registers and shared memory for inter-processor communication.
The aliases with a stem 'rproc' have also been added for all the
DSPs, they provide a fixed remoteproc id to each DSP processor.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sam Nelson <sam.nelson@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
When new directory 'DIR1' is created in a directory 'DIR0' with SGID bit
set, DIR1 is expected to have SGID bit set (and owning group equal to
the owning group of 'DIR0'). However when 'DIR0' also has some default
ACLs that 'DIR1' inherits, setting these ACLs will result in SGID bit on
'DIR1' to get cleared if user is not member of the owning group.
Fix the problem by moving posix_acl_update_mode() out of
__ext4_set_acl() into ext4_set_acl(). That way the function will not be
called when inheriting ACLs which is what we want as it prevents SGID
bit clearing and the mode has been properly set by posix_acl_create()
anyway.
Fixes: 073931017b
CC: stable@vger.kernel.org
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
