From: Olliver Schinagl <oliver@schinagl.nl>
This patch adds a bit-banging gpio PWM driver. It makes use of hrtimers,
to allow nano-second resolution, though it obviously strongly depends on
the switching speed of the gpio pins, hrtimer and system load.
Each pwm node can have 1 or more "pwm-gpio" entries, which will be
treated as pwm's as part of a pwm chip.
Change-Id: Idd42bf6d79f8ce52275a15965b02af470f28da7c
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
It has two main use cases:
1) Allow drivers to reset their hardware via a GPIO line in a standard fashion
as supplied by the reset framework.
This allows adhoc driver code requesting GPIOs etc to be replaced with a
single call to device_reset().
2) Allow hardware on discoverable busses to be rest via a GPIO line
without driver modifications.
Examples of the second use case include:
* SDIO wifi modules
* USB hub chips with a reset line
In this second use case the reset has to be done externally to the driver
managing the hardware since resetting the device from the driver's probe()
method will either do nothing (if the device needs to be reset before
ennumeration will work) or cause racy beahviour (when the device disappears
from the bus during probe()).
So, in addition to providing a gpio based reset controller implementation
it is also possible to reset devices at boot via a DT property or from
userspace on request via sysfs attributes.
Change-Id: I316f9e622d99cff7167b57e8fd5ff73a34dc2a81
Signed-off-by: Martin Fuzzey <mfuzzey@parkeon.com>
Signed-off-by: Kevin Kim <ckkim@hardkernel.com>
PD#SWPL-8013
Problem:
separate dts config from driver
Solution:
separate dts config from driver
Verify:
verify by u202
Change-Id: I4de45ec213b86d12cdd9296f80de62f4f2dc6713
Signed-off-by: GongWei Chen <gongwei.chen@amlogic.com>
PD#SWPL-5636
Problem:
the clock measurement in SoC is changed
Solution:
add clock measurement
Verify:
test passed on ptm
Change-Id: I2325e9c76e27498c258449624b01f0deff9f7684
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
PD#SWPL-5636
Problem:
pcie and several clk81 clocks are newly added in tm2 SoC
Solution:
add pcie and several clk81 clocks
Verify:
test passed on ptm
Change-Id: I8456d7fa8ffb6438e99d3f1cddee4a3ba846b933
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
PD#SWPL-5651
Problem:
tm2 has 2 extra pins than tl1, should use new param data
Solution:
add tm2 param data
Verify:
T962e2_ab319
Change-Id: I77aaaead7b10024cd5f12354ba6b47db74ba96f5
Signed-off-by: Qianggui Song <qianggui.song@amlogic.com>
PD#SWPL-5656
Problem:
tm2 need a static data pinctrl file to depict pins
Solution:
add relative codes to support tm2
Verify:
T962E2_ab319
Change-Id: I55206f9b3df6390e8821fd777d329ddf05dd8386
Signed-off-by: Qianggui Song <qianggui.song@amlogic.com>
PD#SWPL-5395
Problem:
sm1 support double-edge trigger, current code do not support.
Solution:
add relatvie bitmask to support this function.
Verify:
ptm & sm1_skt
Change-Id: I48ebc9b38db868f946c49b6fd5f98d427b2669df
Signed-off-by: Qianggui Song <qianggui.song@amlogic.com>
PD# SWPL-4823
Problem:
1. After stack optimization, stack memory cannot be
mapped as dma buffers and thus causing crypto dma failed to
generate correct result.
2. crypto dma was not enabled on G12B
Solution:
1. Move key_iv buffer from stack to memory provided by kzalloc
2. Enable crypto dma on G12B
3. Replace module_param with debugfs
4. Replace pr_err with dev_err
Verify:
verified on G12B
Change-Id: I6de682e3d1fc141f8c6179c7d91f9b4bff165eae
Signed-off-by: Matthew Shyu <matthew.shyu@amlogic.com>
Signed-off-by: Mingyen Hung <mingyen.hung@amlogic.com>
PD#SWPL-3437
Problem:
the arm64 does not support tl1
Solution:
add arm64 support for tl1
Verify:
test pass on x301
Change-Id: I9531731650c7e8e962f681e357580d3dd0eb0137
Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
PD#SWPL-1513
Problem:
ab update can not work on P
Solution:
add dtsi for ab update for P
Verify:
test pass in ampere
Change-Id: I6ff219170a16c0081fba7297110e8dfaadcff401
Signed-off-by: Xindong Xu <xindong.xu@amlogic.com>
PD#172587: watchdog: meson: add watchdog support for tl1
TL1's watchdog is same with G12A.
Change-Id: Iaa8c502e6a8889a33ed2875e7a16cca07873738a
Signed-off-by: Bo Yang <bo.yang@amlogic.com>
PD#172587: pwm: meson: add support for tl1
Add support for tl1.
Change-Id: I5db1be16765a8e2f2a07815e6d7d139eec4dcf16
Signed-off-by: bichao.zheng <bichao.zheng@amlogic.com>
PD#172286: this commit changes mainly for GVA
1) keypad: add pca9557 keypad driver for new mic board D607.
Change-Id: I0d9ec9626362b3d87d6c55e5c967bfa4486b1472
Signed-off-by: jinrong.liao <jinrong.liao@amlogic.com>
commit 5b76a3cff0 upstream
When nested virtualization is in use, VMENTER operations from the nested
hypervisor into the nested guest will always be processed by the bare metal
hypervisor, and KVM's "conditional cache flushes" mode in particular does a
flush on nested vmentry. Therefore, include the "skip L1D flush on
vmentry" bit in KVM's suggested ARCH_CAPABILITIES setting.
Add the relevant Documentation.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 801e459a6f upstream
Provide a new KVM capability that allows bits within MSRs to be recognized
as features. Two new ioctls are added to the /dev/kvm ioctl routine to
retrieve the list of these MSRs and then retrieve their values. A kvm_x86_ops
callback is used to determine support for the listed MSR-based features.
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
[Tweaked documentation. - Radim]
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d90a7a0ec8 upstream
Introduce the 'l1tf=' kernel command line option to allow for boot-time
switching of mitigation that is used on processors affected by L1TF.
The possible values are:
full
Provides all available mitigations for the L1TF vulnerability. Disables
SMT and enables all mitigations in the hypervisors. SMT control via
/sys/devices/system/cpu/smt/control is still possible after boot.
Hypervisors will issue a warning when the first VM is started in
a potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
full,force
Same as 'full', but disables SMT control. Implies the 'nosmt=force'
command line option. sysfs control of SMT and the hypervisor flush
control is disabled.
flush
Leaves SMT enabled and enables the conditional hypervisor mitigation.
Hypervisors will issue a warning when the first VM is started in a
potentially insecure configuration, i.e. SMT enabled or L1D flush
disabled.
flush,nosmt
Disables SMT and enables the conditional hypervisor mitigation. SMT
control via /sys/devices/system/cpu/smt/control is still possible
after boot. If SMT is reenabled or flushing disabled at runtime
hypervisors will issue a warning.
flush,nowarn
Same as 'flush', but hypervisors will not warn when
a VM is started in a potentially insecure configuration.
off
Disables hypervisor mitigations and doesn't emit any warnings.
Default is 'flush'.
Let KVM adhere to these semantics, which means:
- 'lt1f=full,force' : Performe L1D flushes. No runtime control
possible.
- 'l1tf=full'
- 'l1tf-flush'
- 'l1tf=flush,nosmt' : Perform L1D flushes and warn on VM start if
SMT has been runtime enabled or L1D flushing
has been run-time enabled
- 'l1tf=flush,nowarn' : Perform L1D flushes and no warnings are emitted.
- 'l1tf=off' : L1D flushes are not performed and no warnings
are emitted.
KVM can always override the L1D flushing behavior using its 'vmentry_l1d_flush'
module parameter except when lt1f=full,force is set.
This makes KVM's private 'nosmt' option redundant, and as it is a bit
non-systematic anyway (this is something to control globally, not on
hypervisor level), remove that option.
Add the missing Documentation entry for the l1tf vulnerability sysfs file
while at it.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Jiri Kosina <jkosina@suse.cz>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Link: https://lkml.kernel.org/r/20180713142323.202758176@linutronix.de
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a399477e52 upstream
Add a mitigation mode parameter "vmentry_l1d_flush" for CVE-2018-3620, aka
L1 terminal fault. The valid arguments are:
- "always" L1D cache flush on every VMENTER.
- "cond" Conditional L1D cache flush, explained below
- "never" Disable the L1D cache flush mitigation
"cond" is trying to avoid L1D cache flushes on VMENTER if the code executed
between VMEXIT and VMENTER is considered safe, i.e. is not bringing any
interesting information into L1D which might exploited.
[ tglx: Split out from a larger patch ]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 26acfb666a upstream
If the L1TF CPU bug is present we allow the KVM module to be loaded as the
major of users that use Linux and KVM have trusted guests and do not want a
broken setup.
Cloud vendors are the ones that are uncomfortable with CVE 2018-3620 and as
such they are the ones that should set nosmt to one.
Setting 'nosmt' means that the system administrator also needs to disable
SMT (Hyper-threading) in the BIOS, or via the 'nosmt' command line
parameter, or via the /sys/devices/system/cpu/smt/control. See commit
05736e4ac1 ("cpu/hotplug: Provide knobs to control SMT").
Other mitigations are to use task affinity, cpu sets, interrupt binding,
etc - anything to make sure that _only_ the same guests vCPUs are running
on sibling threads.
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 506a66f374 upstream
Dave Hansen reported, that it's outright dangerous to keep SMT siblings
disabled completely so they are stuck in the BIOS and wait for SIPI.
The reason is that Machine Check Exceptions are broadcasted to siblings and
the soft disabled sibling has CR4.MCE = 0. If a MCE is delivered to a
logical core with CR4.MCE = 0, it asserts IERR#, which shuts down or
reboots the machine. The MCE chapter in the SDM contains the following
blurb:
Because the logical processors within a physical package are tightly
coupled with respect to shared hardware resources, both logical
processors are notified of machine check errors that occur within a
given physical processor. If machine-check exceptions are enabled when
a fatal error is reported, all the logical processors within a physical
package are dispatched to the machine-check exception handler. If
machine-check exceptions are disabled, the logical processors enter the
shutdown state and assert the IERR# signal. When enabling machine-check
exceptions, the MCE flag in control register CR4 should be set for each
logical processor.
Reverting the commit which ignores siblings at enumeration time solves only
half of the problem. The core cpuhotplug logic needs to be adjusted as
well.
This thoughtful engineered mechanism also turns the boot process on all
Intel HT enabled systems into a MCE lottery. MCE is enabled on the boot CPU
before the secondary CPUs are brought up. Depending on the number of
physical cores the window in which this situation can happen is smaller or
larger. On a HSW-EX it's about 750ms:
MCE is enabled on the boot CPU:
[ 0.244017] mce: CPU supports 22 MCE banks
The corresponding sibling #72 boots:
[ 1.008005] .... node #0, CPUs: #72
That means if an MCE hits on physical core 0 (logical CPUs 0 and 72)
between these two points the machine is going to shutdown. At least it's a
known safe state.
It's obvious that the early boot can be hit by an MCE as well and then runs
into the same situation because MCEs are not yet enabled on the boot CPU.
But after enabling them on the boot CPU, it does not make any sense to
prevent the kernel from recovering.
Adjust the nosmt kernel parameter documentation as well.
Reverts: 2207def700 ("x86/apic: Ignore secondary threads if nosmt=force")
Reported-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 05736e4ac1 upstream
Provide a command line and a sysfs knob to control SMT.
The command line options are:
'nosmt': Enumerate secondary threads, but do not online them
'nosmt=force': Ignore secondary threads completely during enumeration
via MP table and ACPI/MADT.
The sysfs control file has the following states (read/write):
'on': SMT is enabled. Secondary threads can be freely onlined
'off': SMT is disabled. Secondary threads, even if enumerated
cannot be onlined
'forceoff': SMT is permanentely disabled. Writes to the control
file are rejected.
'notsupported': SMT is not supported by the CPU
The command line option 'nosmt' sets the sysfs control to 'off'. This
can be changed to 'on' to reenable SMT during runtime.
The command line option 'nosmt=force' sets the sysfs control to
'forceoff'. This cannot be changed during runtime.
When SMT is 'on' and the control file is changed to 'off' then all online
secondary threads are offlined and attempts to online a secondary thread
later on are rejected.
When SMT is 'off' and the control file is changed to 'on' then secondary
threads can be onlined again. The 'off' -> 'on' transition does not
automatically online the secondary threads.
When the control file is set to 'forceoff', the behaviour is the same as
setting it to 'off', but the operation is irreversible and later writes to
the control file are rejected.
When the control status is 'notsupported' then writes to the control file
are rejected.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
PD#170175: drm: Centralize format information
Various pieces of information about DRM formats (number of planes, color
depth, chroma subsampling, ...) are scattered across different helper
functions in the DRM core. Callers of those functions often need to
access more than a single parameter of the format, leading to
inefficiencies due to multiple lookups.
Centralize all format information in a data structure and create a
function to look up information based on the format 4CC.
Change-Id: I25dc415450c89e5eb69726b3dda521c5800c4d68
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: http://patchwork.freedesktop.org/patch/msgid/1476744081-24485-2-git-send-email-laurent.pinchart@ideasonboard.com
Signed-off-by: Victor Wan <victor.wan@amlogic.com>
Conflicts:
drivers/md/dm-bufio.c
drivers/media/dvb-core/dvb_frontend.c
drivers/usb/dwc3/core.c
drivers/usb/gadget/function/f_fs.c
[ Upstream commit 7e5d05e18b ]
We need to introduce a new compatible name for the Meson-AXG SoC
in order to support the RMII 100M ethernet PHY, since the PRG_ETH0
register of the dwmac glue layer is changed from previous old SoC.
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 03d9fbc397 ]
The Meson8m2 SoC is a variant of Meson8 with some updates from Meson8b
(such as the Gigabit capable DesignWare MAC).
It is mostly pin compatible with Meson8, only 10 (existing) CBUS pins
get an additional function (four of these are Ethernet RXD2, RXD3, TXD2
and TXD3 which are required when the board uses an RGMII PHY).
The AOBUS pins seem to be identical on Meson8 and Meson8m2.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
