26 Aug, 2016
1 commit
17 Aug, 2016
1 commit
02 Jun, 2016
21 commits
-
TI-Feature: ti_linux_base_lsk
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.4.y* 'ti-linux-4.4.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
ARM: dts: keystone: increase number of descriptors in region-12
ti_config_fragments/connectivity.cfg: Enable IPSec configSigned-off-by: LCPD Auto Merger
-
New interfaces were added recently but number of descriptors
were not adjusted accordingly. This patch updates the
number of descriptors in descriptor pool region-12 so that
it is enough for 2 gbe+pa and 2 10gbe interfaces.Signed-off-by: WingMan Kwok
Acked-by: Kishon Vijay Abraham I -
TI-Feature: ti_linux_base_lsk
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.4.y* 'ti-linux-4.4.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
ti_config_fragments/connectivity.cfg: build matrix-keypad as module
ARM: dts: keystone: remove bogus PCI IO resources in DT bindingsSigned-off-by: LCPD Auto Merger
-
…gration-tree/connectivity-ti-linux-kernel into ti-linux-4.4.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.4.y* 'connectivity-ti-linux-4.4.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
ti_config_fragments/connectivity.cfg: build matrix-keypad as module
ARM: dts: keystone: remove bogus PCI IO resources in DT bindingsSigned-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
-
In the past, the PCI controller required a IO resource to be specified
without which it fails in PCI core when creating the RC device. So
to overcome this, a bogus entry was added. In recent kernel, this
requirement is removed and we could initialize without specifying an IO
resource. Keystone PCI controller hardware doesn't support IO window.
So it is not required.The flip side of this is that during boot, following error log is thrown
in, but doesn't cause any issues with SATA hard drive access. So remove
the bogus entry as having it can causes the device to fail for access to
the IO window (only snapshot of first few lines of dump shown)[ 37.182381] Unable to handle kernel paging request at virtual address fee01020
[ 37.189598] pgd = d9d5fec0
[ 37.192297] [fee01020] *pgd=80000800007003, *pmd=00000000
[ 37.197700] Internal error: Oops: 206 [#1] PREEMPT SMP ARM
[ 37.203176] Modules linked in: xhci_plat_hcd ahci libahci dwc3 libata udc_core extcon dwc3_keystone
[ 37.212258] CPU: 0 PID: 1797 Comm: udevadm Not tainted 4.4.11-00323-ge3a9adb #1
[ 37.219557] Hardware name: Keystone
[ 37.223038] task: daaec600 ti: d9eba000 task.ti: d9eba000
[ 37.228433] PC is at pci_read_resource_io+0xe4/0xf4
[ 37.233302] LR is at 0x0
[ 37.235830] pc : [] lr : [] psr: 60010013
[ 37.235830] sp : d9ebbe50 ip : da11a240 fp : d9ebbe6c
[ 37.247295] r10: d9fe4000 r9 : da31e9cc r8 : d9ebbf80
[ 37.252511] r7 : 00000000 r6 : 00001023 r5 : 00000000 r4 : 00001023
[ 37.259029] r3 : d9fe4000 r2 : fee01020 r1 : 00001020 r0 : 00000004
[ 37.265548] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 37.272673] Control: 30c5387d Table: 19d5fec0 DAC: fffffffd
[ 37.278410] Process udevadm (pid: 1797, stack limit = 0xd9eba210)Signed-off-by: Murali Karicheri
Signed-off-by: Sekhar Nori -
TI-Feature: ti_linux_base_lsk
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.4.y* 'ti-linux-4.4.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel: (87 commits)
Linux 4.4.12
kbuild: move -Wunused-const-variable to W=1 warning level
Revert "scsi: fix soft lockup in scsi_remove_target() on module removal"
scsi: Add intermediate STARGET_REMOVE state to scsi_target_state
hpfs: implement the show_options method
hpfs: fix remount failure when there are no options changed
UBI: Fix static volume checks when Fastmap is used
SIGNAL: Move generic copy_siginfo() to signal.h
thunderbolt: Fix double free of drom buffer
IB/srp: Fix a debug kernel crash
ALSA: hda - Fix headset mic detection problem for one Dell machine
ALSA: hda/realtek - Add support for ALC295/ALC3254
ALSA: hda - Fix headphone noise on Dell XPS 13 9360
ALSA: hda/realtek - New codecs support for ALC234/ALC274/ALC294
mcb: Fixed bar number assignment for the gdd
clk: bcm2835: add locking to pll*_on/off methods
locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()
serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios()
serial: 8250_mid: recognize interrupt source in handler
serial: 8250_mid: use proper bar for DNV platform
...Signed-off-by: LCPD Auto Merger
-
…ux-stable into ti-linux-4.4.y
This is the 4.4.12 stable release
* tag 'v4.4.12' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (87 commits)
Linux 4.4.12
kbuild: move -Wunused-const-variable to W=1 warning level
Revert "scsi: fix soft lockup in scsi_remove_target() on module removal"
scsi: Add intermediate STARGET_REMOVE state to scsi_target_state
hpfs: implement the show_options method
hpfs: fix remount failure when there are no options changed
UBI: Fix static volume checks when Fastmap is used
SIGNAL: Move generic copy_siginfo() to signal.h
thunderbolt: Fix double free of drom buffer
IB/srp: Fix a debug kernel crash
ALSA: hda - Fix headset mic detection problem for one Dell machine
ALSA: hda/realtek - Add support for ALC295/ALC3254
ALSA: hda - Fix headphone noise on Dell XPS 13 9360
ALSA: hda/realtek - New codecs support for ALC234/ALC274/ALC294
mcb: Fixed bar number assignment for the gdd
clk: bcm2835: add locking to pll*_on/off methods
locking,qspinlock: Fix spin_is_locked() and spin_unlock_wait()
serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios()
serial: 8250_mid: recognize interrupt source in handler
serial: 8250_mid: use proper bar for DNV platform
...Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
-
commit 702f926067d2a4b28c10a3c41a1172dd62d9e735 upstream.
b4ff8389ed14 is incomplete: relies on nr_legacy_irqs() to get the number
of legacy interrupts when actually nr_legacy_irqs() returns 0 after
probe_8259A(). Use NR_IRQS_LEGACY instead.Signed-off-by: Stefano Stabellini
Signed-off-by: Greg Kroah-Hartman -
commit 316314cae15fb0e3869b76b468f59a0c83ac3d4e upstream.
This ensures that the guest doesn't see XSAVE extensions
(e.g. xgetbv1 or xsavec) that the host lacks.Cc: stable@vger.kernel.org
Reviewed-by: Radim Krčmář
[4.5 does have CPUID_D_1_EAX, but earlier kernels don't, so use
the numeric value. This is consistent with other occurrences
of cpuid_mask in arch/x86/kvm/cpuid.c - Paolo]
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit b45bacd2d048f405c7760e5cc9b60dd67708734f upstream.
Writing CP0_Compare clears the timer interrupt pending bit
(CP0_Cause.TI), but this wasn't being done atomically. If a timer
interrupt raced with the write of the guest CP0_Compare, the timer
interrupt could end up being pending even though the new CP0_Compare is
nowhere near CP0_Count.We were already updating the hrtimer expiry with
kvm_mips_update_hrtimer(), which used both kvm_mips_freeze_hrtimer() and
kvm_mips_resume_hrtimer(). Close the race window by expanding out
kvm_mips_update_hrtimer(), and clearing CP0_Cause.TI and setting
CP0_Compare between the freeze and resume. Since the pending timer
interrupt should not be cleared when CP0_Compare is written via the KVM
user API, an ack argument is added to distinguish the source of the
write.Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: "Radim KrÄmář"
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit 4355c44f063d3de4f072d796604c7f4ba4085cc3 upstream.
There's a particularly narrow and subtle race condition when the
software emulated guest timer is frozen which can allow a guest timer
interrupt to be missed.This happens due to the hrtimer expiry being inexact, so very
occasionally the freeze time will be after the moment when the emulated
CP0_Count transitions to the same value as CP0_Compare (so an IRQ should
be generated), but before the moment when the hrtimer is due to expire
(so no IRQ is generated). The IRQ won't be generated when the timer is
resumed either, since the resume CP0_Count will already match CP0_Compare.With VZ guests in particular this is far more likely to happen, since
the soft timer may be frozen frequently in order to restore the timer
state to the hardware guest timer. This happens after 5-10 hours of
guest soak testing, resulting in an overflow in guest kernel timekeeping
calculations, hanging the guest. A more focussed test case to
intentionally hit the race (with the help of a new hypcall to cause the
timer state to migrated between hardware & software) hits the condition
fairly reliably within around 30 seconds.Instead of relying purely on the inexact hrtimer expiry to determine
whether an IRQ should be generated, read the guest CP0_Compare and
directly check whether the freeze time is before or after it. Only if
CP0_Count is on or after CP0_Compare do we check the hrtimer expiry to
determine whether the last IRQ has already been generated (which will
have pushed back the expiry by one timer period).Fixes: e30492bbe95a ("MIPS: KVM: Rewrite count/compare timer emulation")
Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: "Radim KrÄmář"
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f24632475d4ffed5626abbfab7ef30a128dd1474 upstream.
Commit d28bc9dd25ce reversed the order of two lines which initialize cr0,
allowing the current (old) cr0 value to mess up vcpu initialization.
This was observed in the checks for cr0 X86_CR0_WP bit in the context of
kvm_mmu_reset_context(). Besides, setting vcpu->arch.cr0 after vmx_set_cr0()
is completely redundant. Change the order back to ensure proper vcpu
initialization.The combination of booting with ovmf firmware when guest vcpus > 1 and kvm's
ept=N option being set results in a VM-entry failure. This patch fixes that.Fixes: d28bc9dd25ce ("KVM: x86: INIT and reset sequences are different")
Signed-off-by: Bruce Rogers
Signed-off-by: Radim Krčmář
Signed-off-by: Greg Kroah-Hartman -
commit 9842df62004f366b9fed2423e24df10542ee0dc5 upstream.
MSR 0x2f8 accessed the 124th Variable Range MTRR ever since MTRR support
was introduced by 9ba075a664df ("KVM: MTRR support").0x2f8 became harmful when 910a6aae4e2e ("KVM: MTRR: exactly define the
size of variable MTRRs") shrinked the array of VR MTRRs from 256 to 8,
which made access to index 124 out of bounds. The surrounding code only
WARNs in this situation, thus the guest gained a limited read/write
access to struct kvm_arch_vcpu.0x2f8 is not a valid VR MTRR MSR, because KVM has/advertises only 16 VR
MTRR MSRs, 0x200-0x20f. Every VR MTRR is set up using two MSRs, 0x2f8
was treated as a PHYSBASE and 0x2f9 would be its PHYSMASK, but 0x2f9 was
not implemented in KVM, therefore 0x2f8 could never do anything useful
and getting rid of it is safe.This fixes CVE-2016-3713.
Fixes: 910a6aae4e2e ("KVM: MTRR: exactly define the size of variable MTRRs")
Reported-by: David Matlack
Signed-off-by: Andy Honig
Signed-off-by: Radim Krčmář
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit e4fe9e7dc3828bf6a5714eb3c55aef6260d823a2 upstream.
The EC field of the constructed ESR is conditionally modified by ORing in
ESR_ELx_EC_DABT_LOW for a data abort. However, ESR_ELx_EC_SHIFT is missing
from this condition.Signed-off-by: Matt Evans
Acked-by: Marc Zyngier
Signed-off-by: Christoffer Dall
Signed-off-by: Greg Kroah-Hartman -
commit d4b9e0790aa764c0b01e18d4e8d33e93ba36d51f upstream.
The ARM architecture mandates that when changing a page table entry
from a valid entry to another valid entry, an invalid entry is first
written, TLB invalidated, and only then the new entry being written.The current code doesn't respect this, directly writing the new
entry and only then invalidating TLBs. Let's fix it up.Reported-by: Christoffer Dall
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
Signed-off-by: Greg Kroah-Hartman -
commit f228b494e56d949be8d8ea09d4f973d1979201bf upstream.
The loop that browses the array compat_hwcap_str will stop when a NULL
is encountered, however NULL is missing at the end of array. This will
lead to overrun until a NULL is found somewhere in the following memory.
In reality, this works out because the compat_hwcap2_str array tends to
follow immediately in memory, and that *is* terminated correctly.
Furthermore, the unsigned int compat_elf_hwcap is checked before
printing each capability, so we end up doing the right thing because
the size of the two arrays is less than 32. Still, this is an obvious
mistake and should be fixed.Note for backporting: commit 12d11817eaafa414 ("arm64: Move
/proc/cpuinfo handling code") moved this code in v4.4. Prior to that
commit, the same change should be made in arch/arm64/kernel/setup.c.Fixes: 44b82b7700d0 "arm64: Fix up /proc/cpuinfo"
Signed-off-by: Julien Grall
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 282aa7051b0169991b34716f0f22d9c2f59c46c4 upstream.
The update to the accessed or dirty states for block mappings must be
done atomically on hardware with support for automatic AF/DBM. The
ptep_set_access_flags() function has been fixed as part of commit
66dbd6e61a52 ("arm64: Implement ptep_set_access_flags() for hardware
AF/DBM"). This patch brings pmdp_set_access_flags() in line with the pte
counterpart.Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits")
Reviewed-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 66dbd6e61a526ae7d11a208238ae2c17e5cacb6b upstream.
When hardware updates of the access and dirty states are enabled, the
default ptep_set_access_flags() implementation based on calling
set_pte_at() directly is potentially racy. This triggers the "racy dirty
state clearing" warning in set_pte_at() because an existing writable PTE
is overridden with a clean entry.There are two main scenarios for this situation:
1. The CPU getting an access fault does not support hardware updates of
the access/dirty flags. However, a different agent in the system
(e.g. SMMU) can do this, therefore overriding a writable entry with a
clean one could potentially lose the automatically updated dirty
status2. A more complex situation is possible when all CPUs support hardware
AF/DBM:a) Initial state: shareable + writable vma and pte_none(pte)
b) Read fault taken by two threads of the same process on different
CPUs
c) CPU0 takes the mmap_sem and proceeds to handling the fault. It
eventually reaches do_set_pte() which sets a writable + clean pte.
CPU0 releases the mmap_sem
d) CPU1 acquires the mmap_sem and proceeds to handle_pte_fault(). The
pte entry it reads is present, writable and clean and it continues
to pte_mkyoung()
e) CPU1 calls ptep_set_access_flags()If between (d) and (e) the hardware (another CPU) updates the dirty
state (clears PTE_RDONLY), CPU1 will override the PTR_RDONLY bit
marking the entry clean again.This patch implements an arm64-specific ptep_set_access_flags() function
to perform an atomic update of the PTE flags.Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits")
Signed-off-by: Catalin Marinas
Reported-by: Ming Lei
Tested-by: Julien Grall
Cc: Will Deacon
[will: reworded comment]
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 5bb1cc0ff9a6b68871970737e6c4c16919928d8b upstream.
Currently, pmd_present() only checks for a non-zero value, returning
true even after pmd_mknotpresent() (which only clears the type bits).
This patch converts pmd_present() to using pte_present(), similar to the
other pmd_*() checks. As a side effect, it will return true for
PROT_NONE mappings, though they are not yet used by the kernel with
transparent huge pages.For consistency, also change pmd_mknotpresent() to only clear the
PMD_SECT_VALID bit, even though the PMD_TABLE_BIT is already 0 for block
mappings (no functional change). The unused PMD_SECT_PROT_NONE
definition is removed as transparent huge pages use the pte page prot
values.Fixes: 9c7e535fcc17 ("arm64: mm: Route pmd thp functions through pte equivalents")
Reviewed-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit 911f56eeb87ee378f5e215469268a7a2f68a5a8a upstream.
With hardware AF/DBM support, pmd modifications (transparent huge pages)
should be performed atomically using load/store exclusive. The initial
patches defined the get-and-clear function and __HAVE_ARCH_* macro
without the "huge" word, leaving the pmdp_huge_get_and_clear() to the
default, non-atomic implementation.Fixes: 2f4b829c625e ("arm64: Add support for hardware updates of the access and dirty pte bits")
Reviewed-by: Will Deacon
Signed-off-by: Catalin Marinas
Signed-off-by: Will Deacon
Signed-off-by: Greg Kroah-Hartman -
commit ab92b232ae05c382c3df0e3d6a5c6d16b639ac8c upstream.
Currently, the PT driver always sets the PMI bit one region (page) before
the STOP region so that we can wake up the consumer before we run out of
room in the buffer and have to disable the event. However, we also need
an interrupt in the last output region, so that we actually get to disable
the event (if no more room from new data is available at that point),
otherwise hardware just quietly refuses to start, but the event is
scheduled in and we end up losing trace data till the event gets removed.For a cpu-wide event it is even worse since there may not be any
re-scheduling at all and no chance for the ring buffer code to notice
that its buffer is filled up and the event needs to be disabled (so that
the consumer can re-enable it when it finishes reading the data out). In
other words, all the trace data will be lost after the buffer gets filled
up.This patch makes PT also generate a PMI when the last output region is
full.Reported-by: Markus Metzger
Signed-off-by: Alexander Shishkin
Signed-off-by: Peter Zijlstra (Intel)
Cc: Arnaldo Carvalho de Melo
Cc: Arnaldo Carvalho de Melo
Cc: Borislav Petkov
Cc: Jiri Olsa
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Stephane Eranian
Cc: Thomas Gleixner
Cc: Vince Weaver
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/1462886313-13660-2-git-send-email-alexander.shishkin@linux.intel.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
28 May, 2016
2 commits
-
TI-Feature: ti_linux_base_lsk
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.4.y* 'ti-linux-4.4.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
HACK: net: prueth: Fix net transmit queue stall
ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-BootSigned-off-by: LCPD Auto Merger
-
…gration-tree/connectivity-ti-linux-kernel into ti-linux-4.4.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.4.y* 'connectivity-ti-linux-4.4.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
HACK: net: prueth: Fix net transmit queue stall
ARM: dts: keystone-k2*: Increase SPI Flash partition size for U-BootSigned-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
27 May, 2016
1 commit
-
U-Boot SPI Boot image is now more than 512KB for Keystone2 devices and
cannot fit into existing partition. So, increase the SPI Flash partition
for U-Boot to 1MB for all Keystone2 devices.Signed-off-by: Vignesh R
26 May, 2016
4 commits
-
TI-Feature: ti_linux_base_lsk
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.4.y* 'ti-linux-4.4.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
ARM: omap2: am437x: rollback to use omap3_gptimer_timer_init()
ARM: dts: dra72-evm: Rename 3.3V regulator tagSigned-off-by: LCPD Auto Merger
-
…nel/platform-linux-feature-tree into ti-linux-4.4.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.4.y* 'platform-ti-linux-4.4.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
ARM: omap2: am437x: rollback to use omap3_gptimer_timer_init()
ARM: dts: dra72-evm: Rename 3.3V regulator tagSigned-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
-
TI-Feature: ti_linux_base_lsk
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.4.y* 'ti-linux-4.4.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
soc: ti: opp-domain: Make ti,absolute-max-voltage-uv mandatory
ARM: dts: OMAP5: Switch to opp-v2 definitions
ARM: dts: OMAP5: Move the cpu-opp-domain to SoC dtsi
ARM: dts: omap5-cm-t54: Switch to opp-domain
ARM: dts: omap5-board-common: Move the opp-domain definition to board-common dts
ARM: dts: omap5-uevm: Remove voltage tolerance
ARM: dts: DRA7/AM57x: Move cpu-opp-domain mapping to SoC map
ARM: dts: dra72-evm-common: Get rid of voltage toleranceSigned-off-by: LCPD Auto Merger
-
…nel/platform-linux-feature-tree into ti-linux-4.4.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.4.y* 'platform-ti-linux-4.4.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
soc: ti: opp-domain: Make ti,absolute-max-voltage-uv mandatory
ARM: dts: OMAP5: Switch to opp-v2 definitions
ARM: dts: OMAP5: Move the cpu-opp-domain to SoC dtsi
ARM: dts: omap5-cm-t54: Switch to opp-domain
ARM: dts: omap5-board-common: Move the opp-domain definition to board-common dts
ARM: dts: omap5-uevm: Remove voltage tolerance
ARM: dts: DRA7/AM57x: Move cpu-opp-domain mapping to SoC map
ARM: dts: dra72-evm-common: Get rid of voltage toleranceSigned-off-by: Dan Murphy <DMurphy@ti.com>
Conflicts:
arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
arch/arm/boot/dts/dra72-evm-common.dtsi
25 May, 2016
2 commits
-
The commit 55ee7017ee31 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x") unintentionally changes the
clocksource devices for AM437x from OMAP GP Timer to SyncTimer32K.Unfortunately, the SyncTimer32K is starving from frequency deviation
as mentioned in commit 5b5c01359152 ("ARM: OMAP2+: AM43x: Use gptimer
as clocksource") and, as reported by Franklin [1], even its monotonic
nature is under question (most probably there is a HW issue, but it's
still under investigation).Taking into account above facts It's reasonable to rollback to the use
of omap3_gptimer_timer_init().[1] http://www.spinics.net/lists/linux-omap/msg127425.html
Reported-by: Cooper Jr., Franklin
Signed-off-by: Grygorii Strashko
Signed-off-by: Lokesh Vutla -
Rename the tag of the 3.3 V regulator used in the DRA72 EVM in
order to have a consistent tag name with the DRA7 EVM. That's
useful when the regulator needs to be referenced in common dtsi
files.Signed-off-by: Misael Lopez Cruz
Acked-by: Nishanth Menon
24 May, 2016
7 commits
-
Switch OMAP5 over to OPP-v2 definitions, This is based on data from
Data sheet SWPS051k (Updated October 2015)[1].[1] http://www.ti.com/lit/gpn/omap5432 (sign in required)
Signed-off-by: Nishanth Menon
-
No reason for the board files to replicate the definition of
cpu-opp-domain definitions for each platform. Centralize the same in
omap5.dtsi since that is the requirement of the SoC.Signed-off-by: Nishanth Menon
-
Switch to opp-domains based on the SMPS mapping in existence.
Signed-off-by: Nishanth Menon
-
This allows for common definitions reused for IGEP and uEVM platforms.
While at it, delete the redundant cpu0-supply property.
Signed-off-by: Nishanth Menon
-
With OPP-v2 bindings, there is no need for voltage-tolerance definition,
remove the same.Signed-off-by: Nishanth Menon
-
SoC dts should define cpu-opp-domain since it is a mandatory feature of
the SoC, the actual mapping of the domain will depend on the board.Remove cpu-opp-domain mapping to mpu_opp_domain from the board dts and
move it to SoC dtsi.Signed-off-by: Nishanth Menon
Acked-by: Suman Anna -
We dont need voltage tolerance with opp-v2 domains since the ranges
are already defined in place.Fixes: aa1c4e02270c ("ARM: dts: dra72-evm: Add mapping of OPP domains to regulators")
Signed-off-by: Nishanth Menon
Acked-by: Suman Anna
20 May, 2016
1 commit
-
TI-Feature: ti_linux_base_lsk
TI-Tree: git@git.ti.com:ti-linux-kernel/ti-linux-kernel.git
TI-Branch: ti-linux-4.4.y* 'ti-linux-4.4.y' of git.ti.com:ti-linux-kernel/ti-linux-kernel:
ARM: dts: dra72: Support QSPI MODE-0 operation at 64MHz
ti_config_fragments/connectivity.cfg: enable IP multicast capability
ti_config_fragments/connectivity.cfg: enable marvell phy driver
ti_config_fragments/connectivity.cfg: enable TI ethernet drivers
ti_config_fragments/connectivity.cfg: add CONFIG_NETFILTER
ti_config_fragments/connectivity.cfg: enable extcon drivers
ti_config_fragments/connectivity.cfg: enable USB DWC3
Input: ti_am335x_tsc - Ack pending IRQs at probe and before suspend
Input: ti_am335x_tsc - Prevent system suspend when TSC is in use
Input: ti_am335x_tsc - Mark IRQ as wakeup capable
ti_config_fragments/connectivity.cfg: Enable SPI and HDQ support
mmc: host: omap_hsmmc: Fix card_busy ops to be used outside of voltage switching
ti_config_fragments/connectivity.cfg: enable MUSB
usb: musb: host: don't start next rx urb if current one failed
usb: musb: host: clear rxcsr error bit if set
drivers: net: cpsw-phy-sel: add support to configure rgmii internal delay
ti_config_fragments/connectivity.cfg: enable some common touchscreen/adc driversSigned-off-by: LCPD Auto Merger