* [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks
From: Gabriele Paoloni @ 2016-09-16 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915105849.GA10345@red-moon>
Hi Lorenzo and Tomasz
Many Thanks for looking at this
> -----Original Message-----
> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi at arm.com]
> Sent: 15 September 2016 11:59
> To: liudongdong (C)
> Cc: Tomasz Nowicki; helgaas at kernel.org; will.deacon at arm.com;
> catalin.marinas at arm.com; rafael at kernel.org; arnd at arndb.de;
> hanjun.guo at linaro.org; okaya at codeaurora.org; jchandra at broadcom.com;
> cov at codeaurora.org; dhdang at apm.com; ard.biesheuvel at linaro.org;
> robert.richter at caviumnetworks.com; mw at semihalf.com;
> Liviu.Dudau at arm.com; ddaney at caviumnetworks.com; Wangyijing;
> msalter at redhat.com; linux-pci at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linaro-acpi at lists.linaro.org;
> jcm at redhat.com; andrea.gallo at linaro.org; jeremy.linton at arm.com;
> Gabriele Paoloni; jhugo at codeaurora.org; linux-acpi at vger.kernel.org;
> linux-kernel at vger.kernel.org
> Subject: Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM
> quirks
>
> On Tue, Sep 13, 2016 at 07:38:39PM +0800, Dongdong Liu wrote:
>
> [...]
>
> > Our host bridge is non ECAM only for the RC bus config space;
> > for any other bus underneath the root bus we support ECAM access.
> >
> > RC config resource with hardcode as DEFINE_RES_MEM(0xb0070000,
> SZ_4K),
> > EP config resource we get it from MCFG table.
> > So we need to override ops, but config resource we only need to
> hardcode with RC config resource.
> >
> > Our host controller ACPI support patch can be found:
> > https://lkml.org/lkml/2016/8/31/340
>
> Sorry I misread your code. IIUC you create an array of resources that
> represent non-ECAM config space (and incidentally contain debug
> registers to check the link status - that you need to check for every
> given config access (?)), but you still need to have an MCFG entry that
The link status check is inherited from the designware framework (see
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L678)
However I think that in this case we can just check the link status
in our init function and return an error if the link is down
> covers the bus number subject to quirk to make sure this mechanism
> works. Correct ?
Well we need the quirks for the root bus numbers but if read this v6
quirk mechanism correctly even if we do not specify an mcfg entry for
bus 0 oci_mcfg_match_quirks() is called anyway and we can set our
special configuration space addresses for the root buses (i.e. I think
we can have a clean MCFG table with entries only for those bus ranges
that are really ECAM)
>
> This also means that, with the MCFG tables you have and current
> mainline kernel you are able to probe a root bridge (because the MCFG
> table covers the bus number that is not ECAM), with enumeration
> going haywire because it is trying to carry out ECAM accesses on
> non-ECAM space.
Yes correct, we cannot access the host controller configuration space
with our current MCFG table and current Linux mainline
>
> Is my reading correct ?
>
> Anyway, that's not stricly related to this discussion, it is time we
> converge on this patchset, we can add a domain range if that
> simplifies things.
IMO it would be better to have the domain range to avoid
a very large and repetitive static quirk array
Thanks
Gab
>
> Thanks,
> Lorenzo
>
> > This patch is based on RFC V5 quirk mechanism.
> >
> > Based on V6 quirk mechanism, we have to change it as below:
> >
> > #ifdef CONFIG_PCI_HISI_ACPI
> > { "HISI ", "HIP05 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP05 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> > ....
> >
> > { "HISI ", "HIP07 ", 0, 15, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > MCFG_RES_EMPTY},
> >
> > #endif
> >
> > struct pci_ecam_ops hisi_pci_hip05_ops = {
> > .bus_shift = 20,
> > .init = hisi_pci_hip05_init,
> > .pci_ops = {
> > .map_bus = pci_ecam_map_bus,
> > .read = hisi_pcie_acpi_rd_conf,
> > .write = hisi_pcie_acpi_wr_conf,
> > }
> > };
> >
> > struct pci_ecam_ops hisi_pci_hip06_ops = {
> > .bus_shift = 20,
> > .init = hisi_pci_hip06_init,
> > .pci_ops = {
> > .map_bus = pci_ecam_map_bus,
> > .read = hisi_pcie_acpi_rd_conf,
> > .write = hisi_pcie_acpi_wr_conf,
> > }
> > };
> >
> > hisi_pci_hipxx_init function is used to get RC config resource with
> hardcode.
> > .....
> >
> > So I hope we can use MCFG_DOM_RANGE, Then I can change it as below.
> >
> > #ifdef CONFIG_PCI_HISI_ACPI
> > { "HISI ", "HIP05 ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> > &hisi_pcie_hip05_ops, MCFG_RES_EMPTY},
> > { "HISI ", "HIP06 ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> > &hisi_pcie_hip06_ops, MCFG_RES_EMPTY},
> > { "HISI ", "HIP07 ", 0, MCFG_DOM_RANGE(0, 15), MCFG_BUS_ANY,
> > &hisi_pcie_hip07_ops, MCFG_RES_EMPTY},
> > #endif
> >
> > Thanks
> > Dongdong
> > >
> > >Thanks,
> > >Tomasz
> > >
> > >.
> > >
> >
^ permalink raw reply
* [PATCH] arm64: hw_breakpoint: Handle inexact watchpoint addresses
From: Will Deacon @ 2016-09-16 8:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473689244-147136-1-git-send-email-labath@google.com>
Hi Pavel,
On Mon, Sep 12, 2016 at 03:07:24PM +0100, Pavel Labath wrote:
> Arm64 hardware does not always report a watchpoint hit address that
> matches one of the watchpoints set. It can also report an address
> "near" the watchpoint if a single instruction access both watched and
> unwatched addresses. There is no straight-forward way, short of
> disassembling the offending instruction, to map that address back to
> the watchpoint.
>
> Previously, when the hardware reported a watchpoint hit on an address
> that did not match our watchpoint (this happens in case of instructions
> which access large chunks of memory such as "stp") the process would
> enter a loop where we would be continually resuming it (because we did
> not recognise that watchpoint hit) and it would keep hitting the
> watchpoint again and again. The tracing process would never get
> notified of the watchpoint hit.
>
> This commit fixes the problem by looking at the watchpoints near the
> address reported by the hardware. If the address does not exactly match
> one of the watchpoints we have set, it attributes the hit to the
> nearest watchpoint we have. This heuristic is a bit dodgy, but I don't
> think we can do much more, given the hardware limitations.
> I include a kernel selftest which triggers this code.
Thanks for the patch. Comments inline.
> Signed-off-by: Pavel Labath <labath@google.com>
> ---
> arch/arm64/kernel/hw_breakpoint.c | 104 +++++++---
> tools/testing/selftests/breakpoints/Makefile | 5 +-
> .../selftests/breakpoints/breakpoint_test-arm.c | 217 +++++++++++++++++++++
> 3 files changed, 298 insertions(+), 28 deletions(-)
> create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test-arm.c
Could you split the test out into a separate patch please?
> diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> index 26a6bf7..d0ebfe6 100644
> --- a/arch/arm64/kernel/hw_breakpoint.c
> +++ b/arch/arm64/kernel/hw_breakpoint.c
> @@ -661,50 +661,80 @@ unlock:
> }
> NOKPROBE_SYMBOL(breakpoint_handler);
>
> +/*
> + * Arm64 hardware does not always report a watchpoint hit address that matches
> + * one of the watchpoints set. It can also report an address "near" the
> + * watchpoint if a single instruction access both watched and unwatched
> + * addresses. There is no straight-forward way, short of disassembling the
> + * offending instruction, to map that address back to the watchpoint. This
> + * function computes the distance of the memory access from the watchpoint as a
> + * heuristic for the likelyhood that a given access triggered the watchpoint.
> + *
> + * See Section D2.10.5 "Determining the memory location that caused a Watchpoint
> + * exception" of ARMv8 Architecture Reference Manual for details.
> + *
> + * The function returns the distance of the address from the bytes watched by
> + * the watchpoint. In case of an exact match, it returns 0.
> + */
> +static u64 get_distance_from_watchpoint(unsigned long addr, int i,
> + struct arch_hw_breakpoint *info)
> +{
> + u64 val, alignment_mask, wp_low, wp_high;
> + u32 ctrl_reg;
> + int first_bit;
> + struct arch_hw_breakpoint_ctrl ctrl;
> +
> + /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
> + if (is_compat_task()) {
> + if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
> + alignment_mask = 0x7;
> + else
> + alignment_mask = 0x3;
> + } else {
> + alignment_mask = 0x7;
> + }
We have identical logic elsewhere in this file, so please stick this into
a get_watchpoint_alignment_mask function.
> +
> + val = read_wb_reg(AARCH64_DBG_REG_WVR, i) & ~alignment_mask;
> +
> + ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
> + decode_ctrl_reg(ctrl_reg, &ctrl);
> + first_bit = ffs(ctrl.len);
> + if (first_bit == 0)
> + return -1;
> + wp_low = val + first_bit - 1;
> + wp_high = val + fls(ctrl.len) - 1;
> + if (addr < wp_low)
> + return wp_low - addr;
> + else if (addr > wp_high)
> + return addr - wp_high;
Why do you need to read the control register? We already have the length
in the arch_hw_breakpoint, and that should be sufficient for the check, no?
> static int watchpoint_handler(unsigned long addr, unsigned int esr,
> struct pt_regs *regs)
> {
> - int i, step = 0, *kernel_step, access;
> - u32 ctrl_reg;
> - u64 val, alignment_mask;
> + int i, step = 0, *kernel_step, access, closest_match;
> + u64 min_dist = -1, dist;
> struct perf_event *wp, **slots;
> struct debug_info *debug_info;
> struct arch_hw_breakpoint *info;
> - struct arch_hw_breakpoint_ctrl ctrl;
>
> slots = this_cpu_ptr(wp_on_reg);
> debug_info = ¤t->thread.debug;
>
> + /*
> + * Find all watchpoints that match the reported address. If no exact
> + * match is found. Attribute the hit to the closest watchpoint.
> + */
> for (i = 0; i < core_num_wrps; ++i) {
> rcu_read_lock();
>
> wp = slots[i];
> -
> if (wp == NULL)
> goto unlock;
>
> - info = counter_arch_bp(wp);
> - /* AArch32 watchpoints are either 4 or 8 bytes aligned. */
> - if (is_compat_task()) {
> - if (info->ctrl.len == ARM_BREAKPOINT_LEN_8)
> - alignment_mask = 0x7;
> - else
> - alignment_mask = 0x3;
> - } else {
> - alignment_mask = 0x7;
> - }
> -
> - /* Check if the watchpoint value matches. */
> - val = read_wb_reg(AARCH64_DBG_REG_WVR, i);
> - if (val != (addr & ~alignment_mask))
> - goto unlock;
> -
> - /* Possible match, check the byte address select to confirm. */
> - ctrl_reg = read_wb_reg(AARCH64_DBG_REG_WCR, i);
> - decode_ctrl_reg(ctrl_reg, &ctrl);
> - if (!((1 << (addr & alignment_mask)) & ctrl.len))
> - goto unlock;
> -
> /*
> * Check that the access type matches.
> * 0 => load, otherwise => store
> @@ -714,6 +744,17 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
> if (!(access & hw_breakpoint_type(wp)))
> goto unlock;
>
> + info = counter_arch_bp(wp);
> +
> + dist = get_distance_from_watchpoint(addr, i, info);
> + if (dist < min_dist) {
> + min_dist = dist;
> + closest_match = i;
> + }
> + /* Is this an exact match? */
> + if (dist != 0)
> + goto unlock;
> +
> info->trigger = addr;
> perf_bp_event(wp, regs);
>
> @@ -724,6 +765,15 @@ static int watchpoint_handler(unsigned long addr, unsigned int esr,
> unlock:
> rcu_read_unlock();
> }
> + if (min_dist > 0 && min_dist != -1) {
> + /* No exact match found. */
> + rcu_read_lock();
> + wp = slots[closest_match];
> + info = counter_arch_bp(wp);
> + info->trigger = addr;
> + perf_bp_event(wp, regs);
> + rcu_read_unlock();
Hmm, are you sure it's safe to drop and retake the RCU lock here? If the
event is destroyed before we retake the RCU lock, won't htis go horribly
wrong? It's probably best to hold the lock outside the loop :(
Will
^ permalink raw reply
* linux-next: manual merge of the samsung-krzk tree with the arm-soc tree
From: Krzysztof Kozlowski @ 2016-09-16 8:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160905111948.553487be@canb.auug.org.au>
On 09/05/2016 03:19 AM, Stephen Rothwell wrote:
> Hi Krzysztof,
>
> Today's linux-next merge of the samsung-krzk tree got a conflict in:
>
> arch/arm64/boot/dts/exynos/exynos7.dtsi
>
> between commit:
>
> 585dcacac6bb ("arm64: dts: Fix broken architected timer interrupt trigger")
>
> from the arm-soc tree and commit:
>
> 36d1c9cd07cd ("arm64: dts: exynos: Use human-friendly symbols for timer interrupt flags")
>
> from the samsung-krzk tree.
>
> I fixed it up (I *think* - see below) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
The fix is correct, for the record:
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Merge conflict was (unfortunately) expected. In general, the
multiple-platform-at-once patches are conflict prone. Especially in this
case, Marc's patch ("arm64: dts: Fix broken architected...") could be
split per architecture.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] KVM: arm/arm64: Route vtimer events to user space
From: kbuild test robot @ 2016-09-16 8:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473981320-25387-1-git-send-email-agraf@suse.de>
Hi Alexander,
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on v4.8-rc6 next-20160916]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
[Suggest to use git(>=2.9.0) format-patch --base=<commit> (or --base=auto for convenience) to record what (public, well-known) commit your patch series was built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url: https://github.com/0day-ci/linux/commits/Alexander-Graf/KVM-arm-arm64-Route-vtimer-events-to-user-space/20160916-073838
base: https://git.kernel.org/pub/scm/virt/kvm/kvm.git linux-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm64
All error/warnings (new ones prefixed by >>):
arch/arm64/kvm/../../../arch/arm/kvm/arm.c: In function 'kvm_arch_vcpu_ioctl':
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1000:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement]
int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1016:12: error: invalid storage class for function 'kvm_vm_ioctl_set_device_addr'
static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1077:13: error: invalid storage class for function 'cpu_init_hyp_mode'
static void cpu_init_hyp_mode(void *dummy)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1098:13: error: invalid storage class for function 'cpu_hyp_reinit'
static void cpu_hyp_reinit(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1112:13: error: invalid storage class for function 'cpu_hyp_reset'
static void cpu_hyp_reset(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1119:13: error: invalid storage class for function '_kvm_arch_hardware_enable'
static void _kvm_arch_hardware_enable(void *discard)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1133:13: error: invalid storage class for function '_kvm_arch_hardware_disable'
static void _kvm_arch_hardware_disable(void *discard)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1147:12: error: invalid storage class for function 'hyp_init_cpu_pm_notifier'
static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1180:19: error: initializer element is not constant
.notifier_call = hyp_init_cpu_pm_notifier,
^
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1180:19: note: (near initialization for 'hyp_init_cpu_pm_nb.notifier_call')
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1183:20: error: invalid storage class for function 'hyp_cpu_pm_init'
static void __init hyp_cpu_pm_init(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1187:20: error: invalid storage class for function 'hyp_cpu_pm_exit'
static void __init hyp_cpu_pm_exit(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1200:13: error: invalid storage class for function 'teardown_common_resources'
static void teardown_common_resources(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1205:12: error: invalid storage class for function 'init_common_resources'
static int init_common_resources(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1216:12: error: invalid storage class for function 'init_subsystems'
static int init_subsystems(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1263:13: error: invalid storage class for function 'teardown_hyp_mode'
static void teardown_hyp_mode(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1276:12: error: invalid storage class for function 'init_vhe_mode'
static int init_vhe_mode(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1289:12: error: invalid storage class for function 'init_hyp_mode'
static int init_hyp_mode(void)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1379:13: error: invalid storage class for function 'check_kvm_target_cpu'
static void check_kvm_target_cpu(void *ret)
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1448:12: error: invalid storage class for function 'arm_init'
static int arm_init(void)
^
In file included from include/linux/printk.h:5:0,
from include/linux/kernel.h:13,
from include/linux/cpu_pm.h:21,
from arch/arm64/kvm/../../../arch/arm/kvm/arm.c:19:
arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1454:13: error: initializer element is not constant
module_init(arm_init);
^
include/linux/init.h:182:58: note: in definition of macro '__define_initcall'
__attribute__((__section__(".initcall" #id ".init"))) = fn; \
^
include/linux/init.h:217:24: note: in expansion of macro 'device_initcall'
#define __initcall(fn) device_initcall(fn)
^
include/linux/module.h:86:24: note: in expansion of macro '__initcall'
#define module_init(x) __initcall(x);
^
>> arch/arm64/kvm/../../../arch/arm/kvm/arm.c:1454:1: note: in expansion of macro 'module_init'
module_init(arm_init);
^
vim +/kvm_vm_ioctl_set_device_addr +1016 arch/arm64/kvm/../../../arch/arm/kvm/arm.c
53c810c36 Mario Smarduch 2015-01-15 994 *
53c810c36 Mario Smarduch 2015-01-15 995 * 1. Take a snapshot of the bit and clear it if needed.
53c810c36 Mario Smarduch 2015-01-15 996 * 2. Write protect the corresponding page.
53c810c36 Mario Smarduch 2015-01-15 997 * 3. Copy the snapshot to the userspace.
53c810c36 Mario Smarduch 2015-01-15 998 * 4. Flush TLB's if needed.
53c810c36 Mario Smarduch 2015-01-15 999 */
749cf76c5 Christoffer Dall 2013-01-20 @1000 int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log)
749cf76c5 Christoffer Dall 2013-01-20 1001 {
53c810c36 Mario Smarduch 2015-01-15 1002 bool is_dirty = false;
53c810c36 Mario Smarduch 2015-01-15 1003 int r;
53c810c36 Mario Smarduch 2015-01-15 1004
53c810c36 Mario Smarduch 2015-01-15 1005 mutex_lock(&kvm->slots_lock);
53c810c36 Mario Smarduch 2015-01-15 1006
53c810c36 Mario Smarduch 2015-01-15 1007 r = kvm_get_dirty_log_protect(kvm, log, &is_dirty);
53c810c36 Mario Smarduch 2015-01-15 1008
53c810c36 Mario Smarduch 2015-01-15 1009 if (is_dirty)
53c810c36 Mario Smarduch 2015-01-15 1010 kvm_flush_remote_tlbs(kvm);
53c810c36 Mario Smarduch 2015-01-15 1011
53c810c36 Mario Smarduch 2015-01-15 1012 mutex_unlock(&kvm->slots_lock);
53c810c36 Mario Smarduch 2015-01-15 1013 return r;
749cf76c5 Christoffer Dall 2013-01-20 1014 }
749cf76c5 Christoffer Dall 2013-01-20 1015
3401d5469 Christoffer Dall 2013-01-23 @1016 static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
3401d5469 Christoffer Dall 2013-01-23 1017 struct kvm_arm_device_addr *dev_addr)
3401d5469 Christoffer Dall 2013-01-23 1018 {
330690cdc Christoffer Dall 2013-01-21 1019 unsigned long dev_id, type;
330690cdc Christoffer Dall 2013-01-21 1020
330690cdc Christoffer Dall 2013-01-21 1021 dev_id = (dev_addr->id & KVM_ARM_DEVICE_ID_MASK) >>
330690cdc Christoffer Dall 2013-01-21 1022 KVM_ARM_DEVICE_ID_SHIFT;
330690cdc Christoffer Dall 2013-01-21 1023 type = (dev_addr->id & KVM_ARM_DEVICE_TYPE_MASK) >>
330690cdc Christoffer Dall 2013-01-21 1024 KVM_ARM_DEVICE_TYPE_SHIFT;
330690cdc Christoffer Dall 2013-01-21 1025
330690cdc Christoffer Dall 2013-01-21 1026 switch (dev_id) {
330690cdc Christoffer Dall 2013-01-21 1027 case KVM_ARM_DEVICE_VGIC_V2:
c7da6fa43 Pavel Fedin 2015-12-18 1028 if (!vgic_present)
c7da6fa43 Pavel Fedin 2015-12-18 1029 return -ENXIO;
ce01e4e88 Christoffer Dall 2013-09-23 1030 return kvm_vgic_addr(kvm, type, &dev_addr->addr, true);
330690cdc Christoffer Dall 2013-01-21 1031 default:
3401d5469 Christoffer Dall 2013-01-23 1032 return -ENODEV;
3401d5469 Christoffer Dall 2013-01-23 1033 }
330690cdc Christoffer Dall 2013-01-21 1034 }
3401d5469 Christoffer Dall 2013-01-23 1035
749cf76c5 Christoffer Dall 2013-01-20 1036 long kvm_arch_vm_ioctl(struct file *filp,
749cf76c5 Christoffer Dall 2013-01-20 1037 unsigned int ioctl, unsigned long arg)
749cf76c5 Christoffer Dall 2013-01-20 1038 {
3401d5469 Christoffer Dall 2013-01-23 1039 struct kvm *kvm = filp->private_data;
3401d5469 Christoffer Dall 2013-01-23 1040 void __user *argp = (void __user *)arg;
3401d5469 Christoffer Dall 2013-01-23 1041
3401d5469 Christoffer Dall 2013-01-23 1042 switch (ioctl) {
5863c2ce7 Marc Zyngier 2013-01-21 1043 case KVM_CREATE_IRQCHIP: {
a28ebea2a Christoffer Dall 2016-08-09 1044 int ret;
c7da6fa43 Pavel Fedin 2015-12-18 1045 if (!vgic_present)
c7da6fa43 Pavel Fedin 2015-12-18 1046 return -ENXIO;
a28ebea2a Christoffer Dall 2016-08-09 1047 mutex_lock(&kvm->lock);
a28ebea2a Christoffer Dall 2016-08-09 1048 ret = kvm_vgic_create(kvm, KVM_DEV_TYPE_ARM_VGIC_V2);
a28ebea2a Christoffer Dall 2016-08-09 1049 mutex_unlock(&kvm->lock);
a28ebea2a Christoffer Dall 2016-08-09 1050 return ret;
5863c2ce7 Marc Zyngier 2013-01-21 1051 }
3401d5469 Christoffer Dall 2013-01-23 1052 case KVM_ARM_SET_DEVICE_ADDR: {
3401d5469 Christoffer Dall 2013-01-23 1053 struct kvm_arm_device_addr dev_addr;
3401d5469 Christoffer Dall 2013-01-23 1054
3401d5469 Christoffer Dall 2013-01-23 1055 if (copy_from_user(&dev_addr, argp, sizeof(dev_addr)))
3401d5469 Christoffer Dall 2013-01-23 1056 return -EFAULT;
3401d5469 Christoffer Dall 2013-01-23 1057 return kvm_vm_ioctl_set_device_addr(kvm, &dev_addr);
3401d5469 Christoffer Dall 2013-01-23 1058 }
42c4e0c77 Anup Patel 2013-09-30 1059 case KVM_ARM_PREFERRED_TARGET: {
42c4e0c77 Anup Patel 2013-09-30 1060 int err;
42c4e0c77 Anup Patel 2013-09-30 1061 struct kvm_vcpu_init init;
42c4e0c77 Anup Patel 2013-09-30 1062
42c4e0c77 Anup Patel 2013-09-30 1063 err = kvm_vcpu_preferred_target(&init);
42c4e0c77 Anup Patel 2013-09-30 1064 if (err)
42c4e0c77 Anup Patel 2013-09-30 1065 return err;
42c4e0c77 Anup Patel 2013-09-30 1066
42c4e0c77 Anup Patel 2013-09-30 1067 if (copy_to_user(argp, &init, sizeof(init)))
42c4e0c77 Anup Patel 2013-09-30 1068 return -EFAULT;
42c4e0c77 Anup Patel 2013-09-30 1069
42c4e0c77 Anup Patel 2013-09-30 1070 return 0;
42c4e0c77 Anup Patel 2013-09-30 1071 }
3401d5469 Christoffer Dall 2013-01-23 1072 default:
749cf76c5 Christoffer Dall 2013-01-20 1073 return -EINVAL;
749cf76c5 Christoffer Dall 2013-01-20 1074 }
3401d5469 Christoffer Dall 2013-01-23 1075 }
749cf76c5 Christoffer Dall 2013-01-20 1076
d157f4a51 Marc Zyngier 2013-04-12 @1077 static void cpu_init_hyp_mode(void *dummy)
342cd0ab0 Christoffer Dall 2013-01-20 1078 {
dac288f7b Marc Zyngier 2013-05-14 1079 phys_addr_t pgd_ptr;
342cd0ab0 Christoffer Dall 2013-01-20 1080 unsigned long hyp_stack_ptr;
342cd0ab0 Christoffer Dall 2013-01-20 1081 unsigned long stack_page;
342cd0ab0 Christoffer Dall 2013-01-20 1082 unsigned long vector_ptr;
342cd0ab0 Christoffer Dall 2013-01-20 1083
342cd0ab0 Christoffer Dall 2013-01-20 1084 /* Switch from the HYP stub to our own HYP init vector */
5a677ce04 Marc Zyngier 2013-04-12 1085 __hyp_set_vectors(kvm_get_idmap_vector());
342cd0ab0 Christoffer Dall 2013-01-20 1086
dac288f7b Marc Zyngier 2013-05-14 1087 pgd_ptr = kvm_mmu_get_httbr();
1436c1aa6 Christoph Lameter 2013-10-21 1088 stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
342cd0ab0 Christoffer Dall 2013-01-20 1089 hyp_stack_ptr = stack_page + PAGE_SIZE;
a0bf9776c Ard Biesheuvel 2016-02-16 1090 vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
342cd0ab0 Christoffer Dall 2013-01-20 1091
12fda8123 Marc Zyngier 2016-06-30 1092 __cpu_init_hyp_mode(pgd_ptr, hyp_stack_ptr, vector_ptr);
35a2491a6 Marc Zyngier 2016-02-01 1093 __cpu_init_stage2();
56c7f5e77 Alex Benn?e 2015-07-07 1094
56c7f5e77 Alex Benn?e 2015-07-07 1095 kvm_arm_init_debug();
342cd0ab0 Christoffer Dall 2013-01-20 1096 }
342cd0ab0 Christoffer Dall 2013-01-20 1097
5f5560b1c James Morse 2016-03-30 @1098 static void cpu_hyp_reinit(void)
5f5560b1c James Morse 2016-03-30 1099 {
5f5560b1c James Morse 2016-03-30 1100 if (is_kernel_in_hyp_mode()) {
5f5560b1c James Morse 2016-03-30 1101 /*
67f691976 AKASHI Takahiro 2016-04-27 1102 * __cpu_init_stage2() is safe to call even if the PM
5f5560b1c James Morse 2016-03-30 1103 * event was cancelled before the CPU was reset.
5f5560b1c James Morse 2016-03-30 1104 */
67f691976 AKASHI Takahiro 2016-04-27 1105 __cpu_init_stage2();
5f5560b1c James Morse 2016-03-30 1106 } else {
5f5560b1c James Morse 2016-03-30 1107 if (__hyp_get_vectors() == hyp_default_vectors)
5f5560b1c James Morse 2016-03-30 1108 cpu_init_hyp_mode(NULL);
5f5560b1c James Morse 2016-03-30 1109 }
5f5560b1c James Morse 2016-03-30 1110 }
5f5560b1c James Morse 2016-03-30 1111
67f691976 AKASHI Takahiro 2016-04-27 @1112 static void cpu_hyp_reset(void)
67f691976 AKASHI Takahiro 2016-04-27 1113 {
12fda8123 Marc Zyngier 2016-06-30 1114 if (!is_kernel_in_hyp_mode())
e537ecd7e Marc Zyngier 2016-06-30 1115 __cpu_reset_hyp_mode(hyp_default_vectors,
e537ecd7e Marc Zyngier 2016-06-30 1116 kvm_get_idmap_start());
67f691976 AKASHI Takahiro 2016-04-27 1117 }
67f691976 AKASHI Takahiro 2016-04-27 1118
67f691976 AKASHI Takahiro 2016-04-27 @1119 static void _kvm_arch_hardware_enable(void *discard)
d157f4a51 Marc Zyngier 2013-04-12 1120 {
67f691976 AKASHI Takahiro 2016-04-27 1121 if (!__this_cpu_read(kvm_arm_hardware_enabled)) {
5f5560b1c James Morse 2016-03-30 1122 cpu_hyp_reinit();
67f691976 AKASHI Takahiro 2016-04-27 1123 __this_cpu_write(kvm_arm_hardware_enabled, 1);
67f691976 AKASHI Takahiro 2016-04-27 1124 }
d157f4a51 Marc Zyngier 2013-04-12 1125 }
d157f4a51 Marc Zyngier 2013-04-12 1126
67f691976 AKASHI Takahiro 2016-04-27 1127 int kvm_arch_hardware_enable(void)
67f691976 AKASHI Takahiro 2016-04-27 1128 {
67f691976 AKASHI Takahiro 2016-04-27 1129 _kvm_arch_hardware_enable(NULL);
67f691976 AKASHI Takahiro 2016-04-27 1130 return 0;
342cd0ab0 Christoffer Dall 2013-01-20 1131 }
342cd0ab0 Christoffer Dall 2013-01-20 1132
67f691976 AKASHI Takahiro 2016-04-27 @1133 static void _kvm_arch_hardware_disable(void *discard)
67f691976 AKASHI Takahiro 2016-04-27 1134 {
67f691976 AKASHI Takahiro 2016-04-27 1135 if (__this_cpu_read(kvm_arm_hardware_enabled)) {
67f691976 AKASHI Takahiro 2016-04-27 1136 cpu_hyp_reset();
67f691976 AKASHI Takahiro 2016-04-27 1137 __this_cpu_write(kvm_arm_hardware_enabled, 0);
67f691976 AKASHI Takahiro 2016-04-27 1138 }
67f691976 AKASHI Takahiro 2016-04-27 1139 }
67f691976 AKASHI Takahiro 2016-04-27 1140
67f691976 AKASHI Takahiro 2016-04-27 1141 void kvm_arch_hardware_disable(void)
67f691976 AKASHI Takahiro 2016-04-27 1142 {
67f691976 AKASHI Takahiro 2016-04-27 1143 _kvm_arch_hardware_disable(NULL);
67f691976 AKASHI Takahiro 2016-04-27 1144 }
d157f4a51 Marc Zyngier 2013-04-12 1145
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1146 #ifdef CONFIG_CPU_PM
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 @1147 static int hyp_init_cpu_pm_notifier(struct notifier_block *self,
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1148 unsigned long cmd,
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1149 void *v)
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1150 {
67f691976 AKASHI Takahiro 2016-04-27 1151 /*
67f691976 AKASHI Takahiro 2016-04-27 1152 * kvm_arm_hardware_enabled is left with its old value over
67f691976 AKASHI Takahiro 2016-04-27 1153 * PM_ENTER->PM_EXIT. It is used to indicate PM_EXIT should
67f691976 AKASHI Takahiro 2016-04-27 1154 * re-enable hyp.
67f691976 AKASHI Takahiro 2016-04-27 1155 */
67f691976 AKASHI Takahiro 2016-04-27 1156 switch (cmd) {
67f691976 AKASHI Takahiro 2016-04-27 1157 case CPU_PM_ENTER:
67f691976 AKASHI Takahiro 2016-04-27 1158 if (__this_cpu_read(kvm_arm_hardware_enabled))
67f691976 AKASHI Takahiro 2016-04-27 1159 /*
67f691976 AKASHI Takahiro 2016-04-27 1160 * don't update kvm_arm_hardware_enabled here
67f691976 AKASHI Takahiro 2016-04-27 1161 * so that the hardware will be re-enabled
67f691976 AKASHI Takahiro 2016-04-27 1162 * when we resume. See below.
67f691976 AKASHI Takahiro 2016-04-27 1163 */
67f691976 AKASHI Takahiro 2016-04-27 1164 cpu_hyp_reset();
67f691976 AKASHI Takahiro 2016-04-27 1165
67f691976 AKASHI Takahiro 2016-04-27 1166 return NOTIFY_OK;
67f691976 AKASHI Takahiro 2016-04-27 1167 case CPU_PM_EXIT:
67f691976 AKASHI Takahiro 2016-04-27 1168 if (__this_cpu_read(kvm_arm_hardware_enabled))
67f691976 AKASHI Takahiro 2016-04-27 1169 /* The hardware was enabled before suspend. */
5f5560b1c James Morse 2016-03-30 1170 cpu_hyp_reinit();
67f691976 AKASHI Takahiro 2016-04-27 1171
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1172 return NOTIFY_OK;
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1173
67f691976 AKASHI Takahiro 2016-04-27 1174 default:
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1175 return NOTIFY_DONE;
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1176 }
67f691976 AKASHI Takahiro 2016-04-27 1177 }
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1178
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1179 static struct notifier_block hyp_init_cpu_pm_nb = {
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 @1180 .notifier_call = hyp_init_cpu_pm_notifier,
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1181 };
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1182
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 @1183 static void __init hyp_cpu_pm_init(void)
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1184 {
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1185 cpu_pm_register_notifier(&hyp_init_cpu_pm_nb);
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1186 }
06a71a24b Sudeep Holla 2016-04-04 @1187 static void __init hyp_cpu_pm_exit(void)
06a71a24b Sudeep Holla 2016-04-04 1188 {
06a71a24b Sudeep Holla 2016-04-04 1189 cpu_pm_unregister_notifier(&hyp_init_cpu_pm_nb);
06a71a24b Sudeep Holla 2016-04-04 1190 }
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1191 #else
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1192 static inline void hyp_cpu_pm_init(void)
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1193 {
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1194 }
06a71a24b Sudeep Holla 2016-04-04 1195 static inline void hyp_cpu_pm_exit(void)
06a71a24b Sudeep Holla 2016-04-04 1196 {
06a71a24b Sudeep Holla 2016-04-04 1197 }
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1198 #endif
1fcf7ce0c Lorenzo Pieralisi 2013-08-05 1199
1e947bad0 Marc Zyngier 2015-01-29 @1200 static void teardown_common_resources(void)
1e947bad0 Marc Zyngier 2015-01-29 1201 {
1e947bad0 Marc Zyngier 2015-01-29 1202 free_percpu(kvm_host_cpu_state);
1e947bad0 Marc Zyngier 2015-01-29 1203 }
1e947bad0 Marc Zyngier 2015-01-29 1204
1e947bad0 Marc Zyngier 2015-01-29 @1205 static int init_common_resources(void)
1e947bad0 Marc Zyngier 2015-01-29 1206 {
1e947bad0 Marc Zyngier 2015-01-29 1207 kvm_host_cpu_state = alloc_percpu(kvm_cpu_context_t);
1e947bad0 Marc Zyngier 2015-01-29 1208 if (!kvm_host_cpu_state) {
:::::: The code at line 1016 was first introduced by commit
:::::: 3401d54696f992edf036f00f46c8c399d1b75c2a KVM: ARM: Introduce KVM_ARM_SET_DEVICE_ADDR ioctl
:::::: TO: Christoffer Dall <c.dall@virtualopensystems.com>
:::::: CC: Marc Zyngier <marc.zyngier@arm.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/octet-stream
Size: 51309 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160916/1dd442e8/attachment-0001.obj>
^ permalink raw reply
* [PATCH v2 0/5] Cavium ThunderX uncore PMU support
From: Jan Glauber @ 2016-09-16 8:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916075523.GJ3380@arm.com>
On Fri, Sep 16, 2016 at 08:55:24AM +0100, Will Deacon wrote:
> Hi Jan,
>
> On Mon, Jul 04, 2016 at 11:11:32AM +0100, Will Deacon wrote:
> > On Tue, Jun 28, 2016 at 04:04:59PM +0200, Jan Glauber wrote:
> > > On Tue, Jun 28, 2016 at 11:24:20AM +0100, Will Deacon wrote:
> > > > On Wed, Mar 09, 2016 at 05:21:02PM +0100, Jan Glauber wrote:
> > > > > This patch series provides access to various counters on the ThunderX SOC.
> > > > >
> > > > > For details of the uncore implementation see patch #1.
> > > > >
> > > > > Patches #2-5 add the various ThunderX specific PMUs.
> > > > >
> > > > > As suggested I've put the files under drivers/perf/uncore. I would
> > > > > prefer this location over drivers/bus because not all of the uncore
> > > > > drivers are bus related.
> > > >
> > > > What's the status of these patches? Were you planning to send a new
> > > > version?
> > >
> > > I was half-way through with addressing Mark's review comments when
> > > got side-tracked.
> > >
> > > The principle question these patches raised remains open though in my
> > > opinion, how to determine the socket a device belongs to.
> > >
> > > There is no first-class interface to ask a device or the firmware
> > > which socket the device lives on.
> > >
> > > The options I see are:
> > > A) Using NUMA node information, depends on CONFIG_NUMA
> > > B) Decoding the socket bits of the PCI BAR address
> > > C) Using PCI topology information
> > >
> > > A is what I tried, but I agree that depending on CONFIG_NUMA is not a good
> > > solution. B would be easy but looks not very future-proof. So option C
> > > is what is left...
> >
> > Sorry to go full circle on this, but "depends on NUMA" sounds better
> > than deriving NUMA topology from PCI to me. The only worry I have is if
> > the NUMA information ends up being insufficient in the long-term, and we
> > end up with a mixture of the three options above in order to figure out
> > the PMU topology.
> >
> > As long as you're happy that the PMU:NUMA topology remains 1:1, then I
> > have no objections. The moment you need extra hacks on the side, we should
> > probably drop the NUMA dependency altogether and figure it out some other
> > way.
>
> Any news on this series, or did I miss a v3? I was hoping to have this in
> for 4.9, but it seems to have stalled :(
>
> Will
No news, I'm afraid it is stalled on my side :( I'll try to get back to
it, but not for 4.9.
Jan
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Nicolas Ferre @ 2016-09-16 8:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915150722.13103-1-alexandre.belloni@free-electrons.com>
Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
> atmel_usba_udc fails with:
>
> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
> ecm_do_notify+0x188/0x1a0
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
> Hardware name: Atmel SAMA5
> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
> ---[ end trace e7cf9dcebf4815a6 ]---
>
> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
> Reported-by: Richard Genoud <richard.genoud@gmail.com>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Felipe, Greg,
It is clearly a regression and material for 4.8-fixes. But I do know
that we are very late in the process :-(
Please do what you can to make it progress before 4.8-final but I'm
truly aware of the challenge.
Thanks to Richard for finding this and Alexandre for the quick correction.
Bye,
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index bb1f6c8f0f01..45bc997d0711 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1978,7 +1978,7 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
> dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
> goto err;
> }
> - ep->ep.name = name;
> + ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
>
> ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
> ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] ARM: dts: exynos: Remove "simple-bus" compatible from fimc-is node
From: Sylwester Nawrocki @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
The "simple-bus" compatible was originally added for fimc-is only
to ensure the child devices instantiation. The child devices are
now being created by the parent device driver so remove the
"simple-bus" compatible.
Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
---
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi b/arch/arm/boot/dts/exynos4x12.dtsi
index c452499..e8d0678 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -147,7 +147,7 @@
};
fimc_is: fimc-is at 12000000 {
- compatible = "samsung,exynos4212-fimc-is", "simple-bus";
+ compatible = "samsung,exynos4212-fimc-is";
reg = <0x12000000 0x260000>;
interrupts = <0 90 0>, <0 95 0>;
power-domains = <&pd_isp>;
--
1.9.1
^ permalink raw reply related
* [PATCH 9/9] dmaengine: ti-dma-crossbar: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
When compile testing eDMA or omap-dma, select also the ti-dma-crossbar so
it is also covered by the compile testing.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 84647d6cb2f4..1c11628062ad 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -133,7 +133,7 @@ config DMA_OMAP
depends on ARCH_OMAP || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
- select TI_DMA_CROSSBAR if SOC_DRA7XX
+ select TI_DMA_CROSSBAR if (SOC_DRA7XX || COMPILE_TEST)
config DMA_SA11X0
tristate "SA-11x0 DMA support"
@@ -518,7 +518,7 @@ config TI_EDMA
depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
- select TI_DMA_CROSSBAR if ARCH_OMAP
+ select TI_DMA_CROSSBAR if (ARCH_OMAP || COMPILE_TEST)
default n
help
Enable support for the TI EDMA controller. This DMA
--
2.10.0
^ permalink raw reply related
* [PATCH 8/9] dmaengine: ti-dma-crossbar: Use enum for crossbar type
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
Fixes compiler warning on 64bit architectures.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index e4f3bd1ae264..876e4ccaf033 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -16,8 +16,10 @@
#include <linux/of_device.h>
#include <linux/of_dma.h>
-#define TI_XBAR_DRA7 0
-#define TI_XBAR_AM335X 1
+enum ti_xbar_type {
+ TI_XBAR_DRA7 = 0,
+ TI_XBAR_AM335X,
+};
static const struct of_device_id ti_dma_xbar_match[] = {
{
@@ -395,7 +397,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
xbar->dmarouter.dev = &pdev->dev;
xbar->dmarouter.route_free = ti_dra7_xbar_free;
- xbar->dma_offset = (u32)match->data;
+ xbar->dma_offset = (enum ti_xbar_type)match->data;
mutex_init(&xbar->mutex);
platform_set_drvdata(pdev, xbar);
@@ -428,7 +430,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
if (unlikely(!match))
return -EINVAL;
- switch ((u32)match->data) {
+ switch ((enum ti_xbar_type)match->data) {
case TI_XBAR_DRA7:
ret = ti_dra7_xbar_probe(pdev);
break;
--
2.10.0
^ permalink raw reply related
* [PATCH 7/9] dmaengine: ti-dma-crossbar: Correct type for of_find_property() third parameter
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The correct type is int and not for the third parameter of
of_find_property().
Fixes compilation for 64bit architectures (x86_64, aarch64).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/ti-dma-crossbar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 5ae294b256a7..e4f3bd1ae264 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -311,7 +311,7 @@ static int ti_dra7_xbar_probe(struct platform_device *pdev)
struct property *prop;
struct resource *res;
u32 safe_val;
- size_t sz;
+ int sz;
void __iomem *iomem;
int i, ret;
--
2.10.0
^ permalink raw reply related
* [PATCH 6/9] dmaengine: omap-dma: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 4348249b943a..84647d6cb2f4 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -130,7 +130,7 @@ config DMA_JZ4780
config DMA_OMAP
tristate "OMAP DMA support"
- depends on ARCH_OMAP
+ depends on ARCH_OMAP || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
select TI_DMA_CROSSBAR if SOC_DRA7XX
--
2.10.0
^ permalink raw reply related
* [PATCH 5/9] dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP configs
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The DMAengine driver for omap-dma use three function calls from the
plat-omap legacy driver. When the DMAengine driver is built when ARCH_OMAP
is not set, the compilation will fail due to missing symbols.
Add empty inline functions to allow the DMAengine driver to be compiled
with COMPILE_TEST.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
include/linux/omap-dma.h | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/include/linux/omap-dma.h b/include/linux/omap-dma.h
index 1d99b61adc65..290081620b3e 100644
--- a/include/linux/omap-dma.h
+++ b/include/linux/omap-dma.h
@@ -297,6 +297,7 @@ struct omap_system_dma_plat_info {
#define dma_omap15xx() __dma_omap15xx(d)
#define dma_omap16xx() __dma_omap16xx(d)
+#if defined(CONFIG_ARCH_OMAP)
extern struct omap_system_dma_plat_info *omap_get_plat_info(void);
extern void omap_set_dma_priority(int lch, int dst_port, int priority);
@@ -355,4 +356,22 @@ static inline int omap_lcd_dma_running(void)
}
#endif
+#else /* CONFIG_ARCH_OMAP */
+
+static inline struct omap_system_dma_plat_info *omap_get_plat_info(void)
+{
+ return NULL;
+}
+
+static inline int omap_request_dma(int dev_id, const char *dev_name,
+ void (*callback)(int lch, u16 ch_status, void *data),
+ void *data, int *dma_ch)
+{
+ return -ENODEV;
+}
+
+static inline void omap_free_dma(int ch) { }
+
+#endif /* CONFIG_ARCH_OMAP */
+
#endif /* __LINUX_OMAP_DMA_H */
--
2.10.0
^ permalink raw reply related
* [PATCH 4/9] dmaengine: edma: enable COMPILE_TEST
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
To get more coverage, enable COMPILE_TEST for this driver.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index fe2dbb811e19..4348249b943a 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -515,7 +515,7 @@ config TI_DMA_CROSSBAR
config TI_EDMA
bool "TI EDMA support"
- depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE
+ depends on ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE || COMPILE_TEST
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
select TI_DMA_CROSSBAR if ARCH_OMAP
--
2.10.0
^ permalink raw reply related
* [PATCH 3/9] dmaengine: edma: Use correct type for of_find_property() third parameter
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The correct type is int and not for the third parameter of
of_find_property().
Fixes compilation for 64bit architectures (x86_64, aarch64).
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 4c8818278fcc..16c0bb92fa4d 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -2024,8 +2024,7 @@ static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev,
{
struct edma_soc_info *info;
struct property *prop;
- size_t sz;
- int ret;
+ int sz, ret;
info = devm_kzalloc(dev, sizeof(struct edma_soc_info), GFP_KERNEL);
if (!info)
--
2.10.0
^ permalink raw reply related
* [PATCH 2/9] dmaengine: edma: Use enum for eDMA binding type (legacy vs TPCC)
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
Fixes the following warning when compiling the driver for 64bit
architectures (x86_64 for example):
drivers/dma/edma.c:2185:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
if (match && (u32)match->data == EDMA_BINDING_TPCC)
^
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index c2098a4b4dcf..4c8818278fcc 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -261,8 +261,11 @@ static const struct edmacc_param dummy_paramset = {
.ccnt = 1,
};
-#define EDMA_BINDING_LEGACY 0
-#define EDMA_BINDING_TPCC 1
+enum edma_binding_type {
+ EDMA_BINDING_LEGACY = 0,
+ EDMA_BINDING_TPCC,
+};
+
static const struct of_device_id edma_of_ids[] = {
{
.compatible = "ti,edma3",
@@ -2184,7 +2187,8 @@ static int edma_probe(struct platform_device *pdev)
const struct of_device_id *match;
match = of_match_node(edma_of_ids, node);
- if (match && (u32)match->data == EDMA_BINDING_TPCC)
+ if (match &&
+ (enum edma_binding_type)match->data == EDMA_BINDING_TPCC)
legacy_mode = false;
info = edma_setup_info_from_dt(dev, legacy_mode);
--
2.10.0
^ permalink raw reply related
* [PATCH 1/9] dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id structs
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916083324.29133-1-peter.ujfalusi@ti.com>
The MODULE_DEVICE_TABLE() were missing from the driver for the of_device_id
structures.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
---
drivers/dma/edma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 3d277fa76c1a..c2098a4b4dcf 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -274,11 +274,13 @@ static const struct of_device_id edma_of_ids[] = {
},
{}
};
+MODULE_DEVICE_TABLE(of, edma_of_ids);
static const struct of_device_id edma_tptc_of_ids[] = {
{ .compatible = "ti,edma3-tptc", },
{}
};
+MODULE_DEVICE_TABLE(of, edma_tptc_of_ids);
static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
{
--
2.10.0
^ permalink raw reply related
* [PATCH 0/9] dmaengine: ti drivers: enable COMPILE_TESTing
From: Peter Ujfalusi @ 2016-09-16 8:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The following series will enable unconditional COMPILE_TEST coverage for the
following drivers: omap-dma, edma and ti-dma-crossbar
The series includes fixes noticed when compiling the drivers for x86_64 and
aarch64.
Replaces the patch Vinod sent to enable partial compile testing for omap-dma:
http://www.spinics.net/lists/dmaengine/msg11025.html
Regards,
Peter
---
Peter Ujfalusi (9):
dmaengine: edma: Add missing MODULE_DEVICE_TABLE() for of_device_id
structs
dmaengine: edma: Use enum for eDMA binding type (legacy vs TPCC)
dmaengine: edma: Use correct type for of_find_property() third
parameter
dmaengine: edma: enable COMPILE_TEST
dmaengine/ARM: omap-dma: Fix the DMAengine compile test on non OMAP
configs
dmaengine: omap-dma: enable COMPILE_TEST
dmaengine: ti-dma-crossbar: Correct type for of_find_property() third
parameter
dmaengine: ti-dma-crossbar: Use enum for crossbar type
dmaengine: ti-dma-crossbar: enable COMPILE_TEST
drivers/dma/Kconfig | 8 ++++----
drivers/dma/edma.c | 15 ++++++++++-----
drivers/dma/ti-dma-crossbar.c | 12 +++++++-----
include/linux/omap-dma.h | 19 +++++++++++++++++++
4 files changed, 40 insertions(+), 14 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v3 2/2] ARM: exynos_defconfig: Remove old non-working MIPI driver
From: Krzysztof Kozlowski @ 2016-09-16 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474014760-23173-1-git-send-email-k.kozlowski@samsung.com>
The Exynos MIPI driver does not work anymore (it is board file only) so
it is removed. Remove also config options.
Cc: Inki Dae <inki.dae@samsung.com>
Cc: Donghwa Lee <dh09.lee@samsung.com>
Cc: Kyungmin Park <kyungmin.park@samsung.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
This does not really depend on patch #1. The driver is dysfunctional and
it does not work so defconfig change can be applied separately.
Changes since v2:
1. Remove also EXYNOS_MIPI_DSI, pointed out by Tomi Valkeinen.
Changes since v1:
1. New patch.
---
arch/arm/configs/exynos_defconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
index 4e484f406419..c58f6841f8aa 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -168,8 +168,6 @@ CONFIG_DRM_PANEL_SAMSUNG_LD9040=y
CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
CONFIG_DRM_NXP_PTN3460=y
CONFIG_DRM_PARADE_PS8622=y
-CONFIG_EXYNOS_VIDEO=y
-CONFIG_EXYNOS_MIPI_DSI=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_PLATFORM=y
CONFIG_BACKLIGHT_PWM=y
--
1.9.1
^ permalink raw reply related
* v4.8-rc: GSM audio causes trouble
From: Pavel Machek @ 2016-09-16 8:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915205142.GA6747@amd>
On Thu 2016-09-15 22:51:42, Pavel Machek wrote:
> Hi!
>
> > I was trying to improve GSM call quality, and hit problems in
> > v4.8-rc. Sound only worked for a while, then I tried to kill
> > cmtspeech_ofono_test, and could not, not even with -9 and could not
> > even reboot.
> >
> > I went back to v4.1 (ok, quite far, I see), and problems are gone.
> >
> > Does it work for you? Any ideas what to try... besides bisect?
>
> v4.7 is okay.
>
> v4.8 with
>
> git diff ..mini-v4.7 drivers/hsi/ | git apply
I believe I tried just reverting
9c99e5e51988798af2a687ef9b1716dd79388550 before, but that did not
help.
I guess I'll try with these reverted, next:
pavel at amd:/data/l/linux-n900$ git show
9c99e5e51988798af2a687ef9b1716dd79388550 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
ad60db2f9fe3367e60a21fc0afe19999516f8b27 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
4e552310cdf0c81210b5fc9173f7cf497eeb9feb | git apply -R
pavel at amd:/data/l/linux-n900$ git show
604fdfa45886f04ad6070c1b8266c7f4154bc497 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
d2b8d695c61c4d2864eee900bebc2ced4f425645 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
fa1572d956ee072e965da01d2c46f10d2b67d017 | git apply -R
pavel at amd:/data/l/linux-n900$ git show
62aa292b3eae920a80c2fd0ed0601a70328627f6 | git apply -R
pavel at amd:/data/l/linux-n900$
...seems to be broken already. I guess its time to
bisect... hmm. Tried bisecting, but soundcard does not work
there. Will do it manually...
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* [PATCH v2 2/2] ARM: exynos_defconfig: Remove old non-working MIPI driver
From: Krzysztof Kozlowski @ 2016-09-16 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b3688bb-8dcb-24d4-8112-a0cc56573e48@ti.com>
On 09/07/2016 10:14 AM, Tomi Valkeinen wrote:
> On 01/09/16 14:49, Krzysztof Kozlowski wrote:
>> The Exynos MIPI driver does not work anymore (it is board file only) so
>> it is removed. Remove also config option.
>>
>> Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>>
>> ---
>>
>> Changes since v1:
>> 1. New patch.
>> ---
>> arch/arm/configs/exynos_defconfig | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
>> index 4e484f406419..fea8edef1534 100644
>> --- a/arch/arm/configs/exynos_defconfig
>> +++ b/arch/arm/configs/exynos_defconfig
>> @@ -168,7 +168,6 @@ CONFIG_DRM_PANEL_SAMSUNG_LD9040=y
>> CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=y
>> CONFIG_DRM_NXP_PTN3460=y
>> CONFIG_DRM_PARADE_PS8622=y
>> -CONFIG_EXYNOS_VIDEO=y
>> CONFIG_EXYNOS_MIPI_DSI=y
>
> EXYNOS_MIPI_DSI too?
Yes, this one too. I'll send a v2. I think these patches can safely go
through different trees (removal of driver through your tree and
defconfig through arm-soc).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Kishon Vijay Abraham I @ 2016-09-16 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAFBinCCDDwydB+RP0CZKoAW5Suxotn224ZFVWvt2OGW3gNJR1g@mail.gmail.com>
Hi,
On Friday 09 September 2016 09:44 PM, Martin Blumenstingl wrote:
> On Fri, Sep 9, 2016 at 5:33 PM, Kevin Hilman <khilman@baylibre.com> wrote:
>> However, the problem with all of the solutions proposed (runtime PM ones
>> included) is that we're forcing a board-specific design issue (2 devices
>> sharing a reset line) into a driver that should not have any
>> board-specific assumptions in it.
>>
>> For example, if this driver is used on another platform where different
>> PHYs have different reset lines, then one of them (the unlucky one who
>> is not probed first) will never get reset. So any form of per-device
>> ref-counting is not a portable solution.
> maybe we should also consider Ben's solution: he played with the USB
> PHY on his Meson8b board. His approach was to have only one USB PHY
> driver instance which exposes two PHYs.
> The downside of this: the driver would have to know the offset of the
> PHYs (0x0 for the first PHY, 0x20 for the second), but we could handle
> the reset using runtime PM without any hacks.
I think the offset information can come from the devicetree too. The phy can be
modeled something like below.
usb-phys at c0000000 {
compatible = "amlogic,meson-gxbb-usb2-phy";
reg = <0x0 0xc0000000 0x0 0x40>;
#address-cells = <2>;
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc0000000 0x0 0x40>;
resets = <&reset 34>;
usb0_phy: usb_phy at 0 {
#phy-cells = <0>;
reg = <0x0 0x0 0x0 0x20>;
clocks = <&clkc CLKID_USB &clkc CLKID_USB0>;
clock-names = "usb_general", "usb";
status = "disabled";
};
usb1_phy: usb_phy at 20 {
#phy-cells = <0>;
reg = <0x0 0x20 0x0 0x20>;
clocks = <&clkc CLKID_USB &clkc CLKID_USB1>;
clock-names = "usb_general", "usb";
status = "disabled";
};
};
This way the driver will be probed only once (the reset can be done during
probe). The phy driver should scan the dt node and for every sub-node it
invokes phy_create?
Thanks
Kishon
^ permalink raw reply
* [PATCH] arm64: tegra: Add missing Smaug revision
From: Alexandre Courbot @ 2016-09-16 8:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL1qeaF+Zck_p_1d-cNMvoJ8oMn7c65wL21E6LjGVVMA3BY2yA@mail.gmail.com>
Not seeing this patch in -next, can someone pick it?
On Fri, Jul 1, 2016 at 1:15 AM, Andrew Bresticker <abrestic@chromium.org> wrote:
> On Wed, Jun 29, 2016 at 1:52 AM, Alexandre Courbot <acourbot@nvidia.com> wrote:
>> The "google,smaug-rev2" string is missing from the compatible list of
>> Smaug's DT. The differences of rev2 are not relevant at our current
>> level of support and it boots just fine, so add it.
>>
>> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
>
> Acked-by: Andrew Bresticker <abrestic@chromium.org>
>
>> ---
>> arch/arm64/boot/dts/nvidia/tegra210-smaug.dts | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> index 431266a48e9c..82a96bd27bc8 100644
>> --- a/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> +++ b/arch/arm64/boot/dts/nvidia/tegra210-smaug.dts
>> @@ -11,7 +11,8 @@
>> compatible = "google,smaug-rev8", "google,smaug-rev7",
>> "google,smaug-rev6", "google,smaug-rev5",
>> "google,smaug-rev4", "google,smaug-rev3",
>> - "google,smaug-rev1", "google,smaug", "nvidia,tegra210";
>> + "google,smaug-rev2", "google,smaug-rev1",
>> + "google,smaug", "nvidia,tegra210";
>>
>> aliases {
>> serial0 = &uarta;
>> --
>> 2.9.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] clocksource: arm_arch_timer: Don't assume clock runs in suspend
From: Daniel Lezcano @ 2016-09-16 8:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DBA81F.2060404@arm.com>
On 16/09/2016 10:06, Marc Zyngier wrote:
> Hi Brian,
>
> On 16/09/16 06:49, Brian Norris wrote:
>> Since commit 4fbcdc813fb9 ("clocksource: arm_arch_timer: Use clocksource
>> for suspend timekeeping"), this driver assumes that the ARM architected
>> timer keeps running in suspend. This is not the case for some ARM SoCs,
>> depending on the HW state used for system suspend. Let's not assume that
>> all SoCs support this, and instead only support this if the device tree
>> explicitly tells us it's "always on". In all other cases, just fall back
>> to the RTC. This should be relatively harmless.
>
> I'm afraid you're confusing two things:
> - the counter, which *must* carry on counting no matter what, as
> (quoting the ARM ARM) "The system counter must be implemented in an
> always-on power domain"
> - the timer, which is allowed to be powered off, and can be tagged with
> the "always-on" property to indicate that it is guaranteed to stay up
> (which in practice only exists in virtual machines and never on real HW).
>
> If your counter does stop counting when suspended, then this is starting
> to either feel like a HW bug, or someone is killing the clock that feeds
> this counter when entering suspend.
>
> If this is the former, then we need a separate quirk to indicate the
> non-standard behaviour. If it is the latter, don't do it! ;-)
+1
-- Daniel
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [PATCH BUGFIX] mtd: nand: mxc: fix obiwan error in mxc_nand_v[12]_ooblayout_free() functions
From: Lothar Waßmann @ 2016-09-16 8:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160915180605.4aed48d3@bbrezillon>
Hi,
On Thu, 15 Sep 2016 18:06:05 +0200 Boris Brezillon wrote:
> Hi Lothar,
>
> On Fri, 9 Sep 2016 16:44:11 +0200
> Lothar Wa?mann <LW@KARO-electronics.de> wrote:
>
> > commit a894cf6c5a82 ("mtd: nand: mxc: switch to mtd_ooblayout_ops")
> > introduced a regression accessing the OOB area from the mxc_nand
> > driver due to an Obiwan error in the mxc_nand_v[12]_ooblayout_free()
> > functions. They report a bogus oobregion { 64, 7 } which leads to
> > errors accessing bogus data when reading the oob area.
> >
> > Prior to the commit the mtd-oobtest module could be run without any
> > errors. With the offending commit, this test fails with results like:
> > |Running mtd-oobtest
> > |
> > |=================================================
> > |mtd_oobtest: MTD device: 5
> > |mtd_oobtest: MTD device size 524288, eraseblock size 131072, page size 2048, count of eraseblocks 4, pages per eraseblock 64, OOB size 64
> > |mtd_test: scanning for bad eraseblocks
> > |mtd_test: scanned 4 eraseblocks, 0 are bad
> > |mtd_oobtest: test 1 of 5
> > |mtd_oobtest: writing OOBs of whole device
> > |mtd_oobtest: written up to eraseblock 0
> > |mtd_oobtest: written 4 eraseblocks
> > |mtd_oobtest: verifying all eraseblocks
> > |mtd_oobtest: error @addr[0x0:0x19] 0x9a -> 0x78 diff 0xe2
> > |mtd_oobtest: error @addr[0x0:0x1a] 0xcc -> 0x0 diff 0xcc
> > |mtd_oobtest: error @addr[0x0:0x1b] 0xe0 -> 0x85 diff 0x65
> > |mtd_oobtest: error @addr[0x0:0x1c] 0x60 -> 0x62 diff 0x2
> > |mtd_oobtest: error @addr[0x0:0x1d] 0x69 -> 0x45 diff 0x2c
> > |mtd_oobtest: error @addr[0x0:0x1e] 0xcd -> 0xa0 diff 0x6d
> > |mtd_oobtest: error @addr[0x0:0x1f] 0xf2 -> 0x60 diff 0x92
> > |mtd_oobtest: error: verify failed at 0x0
> > [...]
> >
> > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> > ---
> > drivers/mtd/nand/mxc_nand.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/mxc_nand.c b/drivers/mtd/nand/mxc_nand.c
> > index 5173fad..fdee907 100644
> > --- a/drivers/mtd/nand/mxc_nand.c
> > +++ b/drivers/mtd/nand/mxc_nand.c
> > @@ -893,7 +893,7 @@ static int mxc_v1_ooblayout_free(struct mtd_info *mtd, int section,
> > {
> > struct nand_chip *nand_chip = mtd_to_nand(mtd);
> >
> > - if (section > nand_chip->ecc.steps)
> > + if (section >= nand_chip->ecc.steps)
> > return -ERANGE;
>
> Hm, looking at the commit you're pointing to, it seems that this test
> is correct (we have X + 1 free sections, where X is the number of ECC
> steps).
>
You are right. I didn't verify the v1 case (for which I have no HW here
any more).
I'll send a corrected patch.
Lothar Wa?mann
^ permalink raw reply
* [PATCH] MAINTAINERS: update list of Oxnas maintainers
From: Neil Armstrong @ 2016-09-16 8:09 UTC (permalink / raw)
To: linux-arm-kernel
Add a new list address in the MAINTAINERS file for the Oxnas platform.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 71aa5da..5470e42 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1442,6 +1442,7 @@ F: arch/arm/mach-orion5x/ts78xx-*
ARM/OXNAS platform support
M: Neil Armstrong <narmstrong@baylibre.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+L: linux-oxnas at lists.tuxfamily.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/mach-oxnas/
F: arch/arm/boot/dts/oxnas*
--
2.7.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox