* [PATCH v2 8/8] KVM: arm/arm64: Enable selective trapping of TLB instructions
From: Punit Agrawal @ 2016-10-26 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026174148.17172-1-punit.agrawal@arm.com>
The TTLB bit of Hypervisor Control Register controls the trapping of
guest TLB maintenance instructions. Taking the trap requires a switch to
the hypervisor and is an expensive operation.
Enable selective trapping of guest TLB instructions when the associated
perf trace event is enabled for a specific virtual machine.
Signed-off-by: Punit Agrawal <punit.agrawal@arm.com>
Cc: Christoffer Dall <christoffer.dall@linaro.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
virt/kvm/arm/perf_trace.c | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/virt/kvm/arm/perf_trace.c b/virt/kvm/arm/perf_trace.c
index 1cafbc9..649ca55 100644
--- a/virt/kvm/arm/perf_trace.c
+++ b/virt/kvm/arm/perf_trace.c
@@ -17,6 +17,8 @@
#include <linux/kvm_host.h>
#include <linux/trace_events.h>
+#include <asm/kvm_emulate.h>
+
typedef int (*perf_trace_callback_fn)(struct kvm *kvm, bool enable);
struct kvm_trace_hook {
@@ -24,7 +26,37 @@ struct kvm_trace_hook {
perf_trace_callback_fn setup_fn;
};
+static int tlb_invalidate_trap(struct kvm *kvm, bool enable)
+{
+ int i;
+ struct kvm_vcpu *vcpu;
+
+ /*
+ * Halt the VM to ensure atomic update across all vcpus (this
+ * avoids racy behaviour against other modifications of
+ * HCR_EL2 such as kvm_toggle_cache/kvm_set_way_flush).
+ */
+ kvm_arm_halt_guest(kvm);
+ kvm_for_each_vcpu(i, vcpu, kvm) {
+ unsigned long hcr = vcpu_get_hcr(vcpu);
+
+ if (enable)
+ hcr |= HCR_TTLB;
+ else
+ hcr &= ~HCR_TTLB;
+
+ vcpu_set_hcr(vcpu, hcr);
+ }
+ kvm_arm_resume_guest(kvm);
+
+ return 0;
+}
+
static struct kvm_trace_hook trace_hook[] = {
+ {
+ .key = "kvm_tlb_invalidate",
+ .setup_fn = tlb_invalidate_trap,
+ },
{ },
};
--
2.9.3
^ permalink raw reply related
* [PATCH] at91sam9g20.dtsi: set correct USB clock divisors
From: Andrey Yurovsky @ 2016-10-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
The AT91SAM9G20 has different clock divisors from the otherwise similar
AT91SAM9260. Set them in at91sam9g20.dtsi so that all AT91SAM9G20 users set up
the USB host controller clocks correctly.
Signed-off-by: Andrey Yurovsky <yurovsky@gmail.com>
---
arch/arm/boot/dts/at91sam9g20.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9g20.dtsi b/arch/arm/boot/dts/at91sam9g20.dtsi
index f593016..6c4488c 100644
--- a/arch/arm/boot/dts/at91sam9g20.dtsi
+++ b/arch/arm/boot/dts/at91sam9g20.dtsi
@@ -62,6 +62,10 @@
atmel,clk-output-range = <0 133000000>;
atmel,clk-divisors = <1 2 4 6>;
};
+
+ usb: usbck {
+ atmel,clk-divisors = <4 2 0 0>;
+ };
};
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Robin Murphy @ 2016-10-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
With the new dma_{map,unmap}_resource() functions added to the DMA API
for the benefit of cases like slave DMA, add suitable implementations to
the arsenal of our generic layer. Since cache maintenance should not be
a concern, these can both be standalone callback implementations without
the need for arch code wrappers.
CC: Joerg Roedel <joro@8bytes.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
v2: Use iommu_dma_unmap_page for symmetry, instead of being sneaky.
drivers/iommu/dma-iommu.c | 13 +++++++++++++
include/linux/dma-iommu.h | 4 ++++
2 files changed, 17 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index c5ab8667e6f2..a2fd90a6a782 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -624,6 +624,19 @@ void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
__iommu_dma_unmap(iommu_get_domain_for_dev(dev), sg_dma_address(sg));
}
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ return iommu_dma_map_page(dev, phys_to_page(phys), offset_in_page(phys),
+ size, dma_direction_to_prot(dir, false) | IOMMU_MMIO);
+}
+
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs)
+{
+ iommu_dma_unmap_page(dev, handle, size, dir, attrs);
+}
+
int iommu_dma_supported(struct device *dev, u64 mask)
{
/*
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 32c589062bd9..7f7e9a7e3839 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -61,6 +61,10 @@ void iommu_dma_unmap_page(struct device *dev, dma_addr_t handle, size_t size,
enum dma_data_direction dir, unsigned long attrs);
void iommu_dma_unmap_sg(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction dir, unsigned long attrs);
+dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
+void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
+ size_t size, enum dma_data_direction dir, unsigned long attrs);
int iommu_dma_supported(struct device *dev, u64 mask);
int iommu_dma_mapping_error(struct device *dev, dma_addr_t dma_addr);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] arm64: Wire up iommu_dma_{map, unmap}_resource()
From: Robin Murphy @ 2016-10-26 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4e84146ae49a4edd5f1226d76617be9aa92a58ee.1477503578.git.robin.murphy@arm.com>
With no coherency to worry about, just plug'em straight in.
CC: Catalin Marinas <catalin.marinas@arm.com>
CC: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm64/mm/dma-mapping.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3f74d0d98de6..5cd0a383b14b 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -796,6 +796,8 @@ static void __iommu_unmap_sg_attrs(struct device *dev,
.sync_single_for_device = __iommu_sync_single_for_device,
.sync_sg_for_cpu = __iommu_sync_sg_for_cpu,
.sync_sg_for_device = __iommu_sync_sg_for_device,
+ .map_resource = iommu_dma_map_resource,
+ .unmap_resource = iommu_dma_unmap_resource,
.dma_supported = iommu_dma_supported,
.mapping_error = iommu_dma_mapping_error,
};
--
1.9.1
^ permalink raw reply related
* [PATCH] PCI: mvebu: Take control of mbus windows setup by the firmware
From: Jason Gunthorpe @ 2016-10-26 17:44 UTC (permalink / raw)
To: linux-arm-kernel
The firmware may setup the mbus to access PCI-E and indicate this
has happened with a ranges mapping for the PCI-E ID. If this happens
then the mbus setup and the pci dynamic setup conflict, creating
problems.
Have PCI-E assume control of the firmware specified default mapping by
setting the value of the bridge window to match the firmware mapping.
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
---
drivers/bus/mvebu-mbus.c | 36 ++++++++++++++++++++++++++++++++++++
drivers/pci/host/pci-mvebu.c | 22 ++++++++++++++++++++++
include/linux/mbus.h | 3 +++
3 files changed, 61 insertions(+)
In the DT this could look like:
mbus {
ranges = <MBUS_ID(0x04, 0xe8) 0 0xe0000000 0x8000000 /* PEX 0 MEM */
pex@e0000000 {
compatible = "marvell,kirkwood-pcie";
ranges = <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000 /* Controller regs */
0x82000000 1 0 MBUS_ID(0x04, 0xe8) 0 1 0 /* Port 0.0 MEM */
>;
pcie at 1,0 {
ranges = <0x82000000 0 0 0x82000000 0x1 0 1 0>;
reg = <0x0800 0 0 0 0>; // 0000:00:01.0
device at 0 {
reg = <0x0 0 0 0 0>; // 0000:01:00.0
ranges = <0x00000000 0x82000000 0x00000000 0x00000000 0x8000000>;
Which is basically the OF way to describe PCI devices downstream of
the interface and give information about what their BARs should be.
This is useful if there is even more DT stuff below the explicitly
declared device as it allows standard DT address translation to work
properly.
diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c7f396903184..ce0ac5049c1f 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -922,6 +922,42 @@ int mvebu_mbus_add_window_by_id(unsigned int target, unsigned int attribute,
size, MVEBU_MBUS_NO_REMAP);
}
+/**
+ * mvebu_mbus_get_single_window_by_id() - return the location of the window if
+ * the target/attribute has a single enabled mapping.
+ *
+ * RETURNS:
+ * -ENODEV if no mapping and -E2BIG if there is more than one mapping
+ */
+int mvebu_mbus_get_single_window_by_id(unsigned int target,
+ unsigned int attribute,
+ phys_addr_t *base, phys_addr_t *size)
+{
+ unsigned int win;
+ unsigned int count = 0;
+
+ for (win = 0; win < mbus_state.soc->num_wins; win++) {
+ u64 wbase;
+ u32 wsize;
+ u8 wtarget, wattr;
+ int enabled;
+
+ mvebu_mbus_read_window(&mbus_state, win, &enabled, &wbase,
+ &wsize, &wtarget, &wattr, NULL);
+ if (enabled && wtarget == target && wattr == attribute) {
+ *base = wbase;
+ *size = wsize;
+ count++;
+ }
+ }
+
+ if (count == 1)
+ return 0;
+ if (count == 0)
+ return -ENODEV;
+ return -E2BIG;
+}
+
int mvebu_mbus_del_window(phys_addr_t base, size_t size)
{
int win;
diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
index 307f81d6b479..5d5a2687b73e 100644
--- a/drivers/pci/host/pci-mvebu.c
+++ b/drivers/pci/host/pci-mvebu.c
@@ -464,6 +464,8 @@ static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port)
static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
{
struct mvebu_sw_pci_bridge *bridge = &port->bridge;
+ int rc;
+ phys_addr_t base, size;
memset(bridge, 0, sizeof(struct mvebu_sw_pci_bridge));
@@ -480,6 +482,26 @@ static void mvebu_sw_pci_bridge_init(struct mvebu_pcie_port *port)
/* Add capabilities */
bridge->status = PCI_STATUS_CAP_LIST;
+
+ /*
+ * If the firmware has already setup a window for PCIe then assume
+ * control of it by defaulting the BAR to the window setting.
+ */
+ rc = mvebu_mbus_get_single_window_by_id(port->mem_target,
+ port->mem_attr, &base, &size);
+ if (rc == -E2BIG)
+ pr_err(FW_BUG "%s: Too many pre-existing mbus mappings\n",
+ port->dn->name);
+ if (!rc) {
+ if ((base & 0xFFFFF) != 0 || ((size + base) & 0xFFFFF) != 0)
+ pr_err(FW_BUG "%s: Invalid pre-existing mbus mapping\n",
+ port->dn->name);
+ port->memwin_base = base;
+ port->memwin_size = size;
+ port->bridge.membase = (base >> 16) & 0xFFF0;
+ port->bridge.memlimit = ((size - 1 + base) >> 16) & 0xFFF0;
+ port->bridge.command |= PCI_COMMAND_MEMORY;
+ }
}
/*
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index d610232762e3..dfafc27b41b5 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -83,5 +83,8 @@ int mvebu_mbus_init(const char *soc, phys_addr_t mbus_phys_base,
size_t mbus_size, phys_addr_t sdram_phys_base,
size_t sdram_size);
int mvebu_mbus_dt_init(bool is_coherent);
+int mvebu_mbus_get_single_window_by_id(unsigned int target,
+ unsigned int attribute,
+ phys_addr_t *base, phys_addr_t *size);
#endif /* __LINUX_MBUS_H */
--
2.1.4
^ permalink raw reply related
* Pinctrl nodes missing for USB
From: Anand Moon @ 2016-10-26 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026165348.GA5600@kozik-lap>
Hi Krzysztof
On 26 October 2016 at 22:23, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Wed, Oct 26, 2016 at 05:56:54PM +0530, Anand Moon wrote:
>> Hi All,
>>
>> I have tried to enable CONFIG_DEBUG_PINCTRL=y on Odroid XU4.
>> Just to try to understand the feature.
>> Is this feature suppoted for USB nodes.
>>
>> Below is the output of failed to pase pinctrl for USB nodes via dts.
>
> I do not see any question here...
>
> Anyway the devices not instantiated from DT will have such warning and
> USB devices are not present in DT, from obvious reasons... However what
> surprises me is why pinctrl_dt_to_map() was called for USB devices?
>
> Best regards,
> Krzysztof
>
[snip]
Sorry. I was just referring HK odroidxu3 dts for reference for dwc3 controller.
https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/boot/dts/exynos5422-odroidxu3.dts#L525
I am just trying to understand if such a configuration possible for
dwc3 controllers.
Best Regards
Anand Moon
^ permalink raw reply
* [PATCH v2] modversions: treat symbol CRCs as 32 bit quantities on 64 bit archs
From: Ard Biesheuvel @ 2016-10-26 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-MEG5ayvBcbOwEFzaWPUvOwzTHVH9JKF_tKVN683Eh7A@mail.gmail.com>
On 26 October 2016 at 14:04, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 26 October 2016 at 11:07, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> Hi Ard,
>>
>> I like the concept, but ...
>>
>> Ard Biesheuvel <ard.biesheuvel@linaro.org> writes:
>>> The symbol CRCs are emitted as ELF symbols, which allows us to easily
>>> populate the kcrctab sections by relying on the linker to associate
>>> each kcrctab slot with the correct value.
>>>
>>> This has two downsides:
>>> - given that the CRCs are treated as pointers, we waste 4 bytes for
>>> each CRC on 64 bit architectures,
>>> - on architectures that support runtime relocation, a relocation entry is
>>> emitted for each CRC value, which may take up 24 bytes of __init space
>>> (on ELF64 systems)
>>>
>>> This comes down to a x8 overhead in [uncompressed] kernel size. In addition,
>>> each relocation has to be reverted before the CRC value can be used.
>>>
>>> Switching to explicit 32 bit values on 64 bit architectures fixes both
>>> issues, since 32 bit values are not treated as relocatable quantities on
>>> ELF64 systems, even if the value ultimately resolves to a linker supplied
>>> value.
>>
>> Are we sure that part is true? ("not treated as relocatable")
>>
>
> Thanks for testing this.
>
>> A quick test build on powerpc gives me:
>>
>> WARNING: 6829 bad relocations
>> c000000000ca3748 R_PPC64_ADDR16 *ABS*+0x0000000013f53da6
>> c000000000ca374a R_PPC64_ADDR16 *ABS*+0x00000000f7272059
>> c000000000ca374c R_PPC64_ADDR16 *ABS*+0x0000000002013d36
>> c000000000ca374e R_PPC64_ADDR16 *ABS*+0x00000000a59dffc8
>> ...
>>
>> Which is coming from our relocs_check.sh script, which checks that the
>> generated relocations are ones we know how to handle.
>>
>
> OK, first of all, it appears the ppc64 assembler interprets .word
> differently than the arm64 one, so I will need to fold this in
>
> """
> diff --git a/include/linux/export.h b/include/linux/export.h
> index fa51ab2ad190..a000d421526d 100644
> --- a/include/linux/export.h
> +++ b/include/linux/export.h
> @@ -54,7 +54,7 @@ extern struct module __this_module;
> #define __CRC_SYMBOL(sym, sec) \
> asm(" .section \"___kcrctab" sec "+" #sym "\", \"a\" \n" \
> " .weak " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
> - " .word " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
> + " .long " VMLINUX_SYMBOL_STR(__crc_##sym) " \n" \
> " .previous \n");
> #endif
> #else
> """
>
> With that change, the CRCs are actually emitted as
>
> WARNING: 7525 bad relocations
> c000000000ce7f50 R_PPC64_ADDR32 *ABS*+0x0000000013f53da6
> c000000000ce7f54 R_PPC64_ADDR32 *ABS*+0x0000000004f7c64e
> c000000000ce7f58 R_PPC64_ADDR32 *ABS*+0x0000000092be8a3e
>
> which is still a bit disappointing, given that we still have 7525 RELA
> entries to process.
> I tried several thing, i.e., adding -Bsymbolic to the linker command
> line, emitting the reference above as .hidden or emit the definition
> from the linker script as HIDDEN(), but nothing seems to make any
> difference. (On arm64, -Bsymbolic eliminates *all* runtime relocations
> except R_<arch>_RELATIVE ones)
>
>> And when I try to boot it I get:
>>
>> virtio: disagrees about version of symbol module_layout
>> virtio: disagrees about version of symbol module_layout
>> scsi_mod: disagrees about version of symbol module_layout
>>
>> And it can't find my root file system (unsurprisingly as it's on scsi).
>>
>
> Something like the below should fix it, I hope.
>
> """
> diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
> index d88736fbece6..99cdf2311ab5 100644
> --- a/arch/powerpc/kernel/reloc_64.S
> +++ b/arch/powerpc/kernel/reloc_64.S
> @@ -14,6 +14,7 @@
> RELA = 7
> RELACOUNT = 0x6ffffff9
> R_PPC64_RELATIVE = 22
> +R_PPC64_ADDR32 = 1
>
> /*
> * r3 = desired final address of kernel
> @@ -77,9 +78,22 @@ _GLOBAL(relocate)
> add r0,r0,r3
> stdx r0,r7,r6
> addi r9,r9,24
> - bdnz 5b
> + b 7f
> +
> + /*
> + * CRCs of exported symbols are emitted as 32-bit relocations against
> + * the *ABS* section with the CRC value recorded in the addend.
> + */
> +6: cmpdi r0,R_PPC64_ADDR32
> + bne 7f
> + ld r6,0(r9) /* reloc->r_offset */
> + ld r0,16(r9) /* reloc->r_addend */
> + stwx r0,r7,r6
> + addi r9,r9,24
> +
> +7: bdnz 5b
> + blr
>
> -6: blr
>
> .balign 8
> p_dyn: .llong __dynamic_start - 0b
> """
>
> Note that the loop no longer terminates at the first
> non-R_PPC64_RELATIVE relocation, but that seems safer to me in any
> case. It simply stores the value of r_addend at r_offset, which is the
> correct thing to do for R_PPC64_ADDR32 relocations against the *ABS*
> section, regardless of whether we are dealing with CRCs or something
> else. Note that the comparison above will fail for R_PPC64_ADDR32
> relocations against named symbols, since we compare the entire r_info
> field and not just the type (as the comment a few lines higher up
> suggests)
>
> Also a fix for relocs_check.sh:
>
> """
> diff --git a/arch/powerpc/relocs_check.sh b/arch/powerpc/relocs_check.sh
> index ec2d5c835170..2f510fbc87da 100755
> --- a/arch/powerpc/relocs_check.sh
> +++ b/arch/powerpc/relocs_check.sh
> @@ -43,7 +43,8 @@ R_PPC_ADDR16_HA
> R_PPC_RELATIVE
> R_PPC_NONE' |
> grep -E -v '\<R_PPC64_ADDR64[[:space:]]+mach_' |
> - grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_'
> + grep -E -v '\<R_PPC64_ADDR64[[:space:]]+__crc_' |
> + grep -E -v '\<R_PPC64_ADDR32[[:space:]]+\*ABS\*'
> )
>
> if [ -z "$bad_relocs" ]; then
> """
>
> If these changes work for PPC, I think we should fold them in.
> Hopefully, GNU ld for PPC will gain that ability to resolve absolute
> relocations at build time (like other architectures), and then the
> R_PPC64_ADDR32 handling will simply become dead code. In any case, it
> is an improvement over the mangling of CRC values to undo the runtime
> relocation, imo.
>
I have spent some more time looking into this, and it seems impossible
to coerce the powerpc linker into resolving relocations against build
time absolute constants at build time.
Interestingly, the CONFIG_MODVERSIONS + CONFIG_RELOCATABLE issue
exists on PPC32 as well, i.e., commit 0e0ed6406e61 ("powerpc/modules:
Module CRC relocation fix causes perf issues") reintroduced it on
PPC32 by making the fix PPC64 specific.
I think the fact that relocations against *ABS* symbols are converted
into R_PPC[64]_RELATIVE relocations is a linker bug. I spotted
something similar on arm64 a while ago
https://lists.gnu.org/archive/html/bug-binutils/2016-07/msg00087.html
but this has not been fixed yet either.
Having to deal with toolchain bugs when working on issues like these
is always a bit annoying, so I wonder what your take is on the PPC32
issue. If nobody cares about CONFIG_RELOCATABLE on PPC32, perhaps it
could be made mutually exclusive with CONFIG_MODVERSIONS on 32-bit
PPC.
^ permalink raw reply
* [PATCH 02/12] ASoC: dapm: Implement stereo mixer control support
From: Mark Brown @ 2016-10-26 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161003110804.28235-3-wens@csie.org>
On Mon, Oct 03, 2016 at 07:07:54PM +0800, Chen-Yu Tsai wrote:
> /* find dapm widget path assoc with kcontrol */
> dapm_kcontrol_for_each_path(path, kcontrol) {
> + /*
> + * If status for the second channel was given ( >= 0 ),
> + * consider the second and later paths as the second
> + * channel.
> + */
> + if (found && rconnect >= 0)
> + soc_dapm_connect_path(path, rconnect, "mixer update");
> + else
> + soc_dapm_connect_path(path, connect, "mixer update");
> found = 1;
> - soc_dapm_connect_path(path, connect, "mixer update");
This really only works for two channels with the current inteface - the
comment makes it sound like it'll work for more but we can only pass in
two (and there's only support for specifying two everywhere).
> - change = dapm_kcontrol_set_value(kcontrol, val);
> + /* This assumes field width < (bits in unsigned int / 2) */
> + change = dapm_kcontrol_set_value(kcontrol, val | (rval << width));
That seems like a bit of an assumption in cases where we've got a single
control for both power and volume? They're very rare though, I'm not
even sure any exist. It'd be good to have a check in the code just in
case it does come up, it'll likely be a nightmare to debug if someone
does run into it.
Otherwise I think this makes sense.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161026/6a7d0d11/attachment.sig>
^ permalink raw reply
* [PATCH] arm64: dts: msm8996: Correct slpi region reg definition
From: Bjorn Andersson @ 2016-10-26 17:54 UTC (permalink / raw)
To: linux-arm-kernel
I missed the missing cell in the reg property of the slpi region in my review,
so let's add it.
Fixes: 2b7f0de19648 ("arm64: dts: msm8996: Add reserve-memory nodes")
Cc: Sarangdhar Joshi <spjoshi@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
---
arch/arm64/boot/dts/qcom/msm8996.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index b97647d29842..215de91e802d 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -42,7 +42,7 @@
};
slpi_region: slpi at 90b00000 {
- reg = <0x0 0x90b00000 0xa00000>;
+ reg = <0x0 0x90b00000 0x0 0xa00000>;
no-map;
};
--
2.5.0
^ permalink raw reply related
* Pinctrl nodes missing for USB
From: Krzysztof Kozlowski @ 2016-10-26 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgSfRVDA_MXN9S+G0-u-mQNhPuPJ65FT_Y-ZH5nFpX4ptg@mail.gmail.com>
On Wed, Oct 26, 2016 at 11:15:51PM +0530, Anand Moon wrote:
> Hi Krzysztof
>
> On 26 October 2016 at 22:23, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Wed, Oct 26, 2016 at 05:56:54PM +0530, Anand Moon wrote:
> >> Hi All,
> >>
> >> I have tried to enable CONFIG_DEBUG_PINCTRL=y on Odroid XU4.
> >> Just to try to understand the feature.
> >> Is this feature suppoted for USB nodes.
> >>
> >> Below is the output of failed to pase pinctrl for USB nodes via dts.
> >
> > I do not see any question here...
> >
> > Anyway the devices not instantiated from DT will have such warning and
> > USB devices are not present in DT, from obvious reasons... However what
> > surprises me is why pinctrl_dt_to_map() was called for USB devices?
> >
> > Best regards,
> > Krzysztof
> >
> [snip]
>
> Sorry. I was just referring HK odroidxu3 dts for reference for dwc3 controller.
>
> https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/arch/arm/boot/dts/exynos5422-odroidxu3.dts#L525
>
> I am just trying to understand if such a configuration possible for
> dwc3 controllers.
What do you mean by "configuration"? Which configuration?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: davinci: da850: Fix pwm name matching
From: Sekhar Nori @ 2016-10-26 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7heg33rtdl.fsf@baylibre.com>
On Wednesday 26 October 2016 09:32 PM, Kevin Hilman wrote:
> Hi Sekhar,
>
> Sekhar Nori <nsekhar@ti.com> writes:
>
>> On Tuesday 25 October 2016 11:24 PM, David Lechner wrote:
>>> This fixes pwm name matching for DA850 familiy devices. When using device
>>> tree, the da850_auxdata_lookup[] table caused pwm devices to have the exact
>>> same name, which caused errors when trying to register the devices.
>>>
>>> The names for clock matching in da850_clks[] also have to be updated to
>>> to exactly match in order for the clock lookup to work correctly.
>>>
>>> Signed-off-by: David Lechner <david@lechnology.com>
>>
>> Applied to "fixes" branch. Will send upstream after testing a bit and
>> also waiting to see if anyone else has any comments.
>
> I'm not seeing a fixes branch in your tree. Did you push this out?
> Similarily, I didn't see the updates in v4.10/defconfig either.
Pushed now. Will push a merged master branch tomorrow after some testing.
Thanks,
Sekhar
^ permalink raw reply
* [PATCHv2] ARM: dts: socfpga: Enable QSPI on the Cyclone5 sockit
From: dinguyen at opensource.altera.com @ 2016-10-26 18:05 UTC (permalink / raw)
To: linux-arm-kernel
From: Dinh Nguyen <dinguyen@opensource.altera.com>
Enable the QSPI node and add the flash chip.
Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
---
v2: Remove partition entries for the SoCKIT
---
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
index 02e22f5..2ce6736 100644
--- a/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
+++ b/arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
@@ -175,6 +175,27 @@
status = "okay";
};
+&qspi {
+ status = "okay";
+
+ flash: flash at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "n25q256a";
+ reg = <0>;
+ spi-max-frequency = <100000000>;
+
+ m25p,fast-read;
+ cdns,page-size = <256>;
+ cdns,block-size = <16>;
+ cdns,read-delay = <4>;
+ cdns,tshsl-ns = <50>;
+ cdns,tsd2d-ns = <50>;
+ cdns,tchsh-ns = <4>;
+ cdns,tslch-ns = <4>;
+ };
+};
+
&usb1 {
status = "okay";
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] drivers: psci: PSCI checker module
From: Paul E. McKenney @ 2016-10-26 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161026173534.GC16248@red-moon>
On Wed, Oct 26, 2016 at 06:35:34PM +0100, Lorenzo Pieralisi wrote:
> On Wed, Oct 26, 2016 at 10:22:52AM -0700, Paul E. McKenney wrote:
> > On Wed, Oct 26, 2016 at 06:10:06PM +0100, Lorenzo Pieralisi wrote:
[ . . . ]
> > > Thanks a lot for your feedback, thoughts appreciated.
> >
> > Let me ask the question more directly.
> >
> > Why on earth are we trying to run these tests concurrently?
>
> We must prevent that, no question about that, that's why I started
> this discussion. It is not fine to enable this checker and the
> RCU/LOCK torture hotplug tests at the same time.
>
> > After all, if we just run one at a time in isolation, there is no
> > problem.
>
> Fine by me, it was to understand if the current assumptions we made
> are correct and they are definitely not. If we enable the PSCI checker
> we must disable the torture rcu/lock hotplug tests either statically or
> dynamically.
What rcutorture, locktorture, and rcuperf do is to invoke
torture_init_begin(), which returns false if one of these tests
is already running.
Perhaps we should extract this torture-test-exclusion and require
than conflicting torture tests invoke it?
Thanx, Paul
^ permalink raw reply
* [PATCH 1/2] DT: binding: bcm2835-mbox: fix address typo in example
From: Stefan Wahren @ 2016-10-26 18:13 UTC (permalink / raw)
To: linux-arm-kernel
The address of the mailbox node in the example has a typo.
So fix it accordingly.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes: d4b5c782b9f4 ("dt/bindings: Add binding for the BCM2835 mailbox driver")
---
.../bindings/mailbox/brcm,bcm2835-mbox.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
index e893615..b48d7d3 100644
--- a/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
+++ b/Documentation/devicetree/bindings/mailbox/brcm,bcm2835-mbox.txt
@@ -12,7 +12,7 @@ Required properties:
Example:
-mailbox: mailbox at 7e00b800 {
+mailbox: mailbox at 7e00b880 {
compatible = "brcm,bcm2835-mbox";
reg = <0x7e00b880 0x40>;
interrupts = <0 1>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: bcm283x: fix typo in mailbox address
From: Stefan Wahren @ 2016-10-26 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477505640-26658-1-git-send-email-stefan.wahren@i2se.com>
The address of the mailbox node in the bcm283x.dts has also a typo.
So fix it accordingly.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes: 05b682b7a3b2 ("ARM: bcm2835: dt: Add the mailbox to the device tree")
---
arch/arm/boot/dts/bcm283x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 46d46d8..74dd21b 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -104,7 +104,7 @@
reg = <0x7e104000 0x10>;
};
- mailbox: mailbox at 7e00b800 {
+ mailbox: mailbox at 7e00b880 {
compatible = "brcm,bcm2835-mbox";
reg = <0x7e00b880 0x40>;
interrupts = <0 1>;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] arm64: Remove pointless WARN_ON in DMA teardown
From: Robin Murphy @ 2016-10-26 18:19 UTC (permalink / raw)
To: linux-arm-kernel
We expect arch_teardown_dma_ops() to be called very late in a device's
life, after it has been removed from its bus, and thus after the IOMMU
bus notifier has run. As such, even if this funny little check did make
sense, it's unlikely to achieve what it thinks it's trying to do anyway.
It's a residual trace of an earlier implementation which didn't belong
here from the start; belatedly snuff it out.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
arch/arm64/mm/dma-mapping.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 5cd0a383b14b..290a84f3351f 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -940,11 +940,6 @@ static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
void arch_teardown_dma_ops(struct device *dev)
{
- struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
-
- if (WARN_ON(domain))
- iommu_detach_device(domain, dev);
-
dev->archdata.dma_ops = NULL;
}
--
1.9.1
^ permalink raw reply related
* [PATCH] arm64: Remove pointless WARN_ON in DMA teardown
From: Will Deacon @ 2016-10-26 18:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <74f5ae2ead8bb8fa9fabcf88b5962885b29eb2d5.1477505971.git.robin.murphy@arm.com>
On Wed, Oct 26, 2016 at 07:19:31PM +0100, Robin Murphy wrote:
> We expect arch_teardown_dma_ops() to be called very late in a device's
> life, after it has been removed from its bus, and thus after the IOMMU
> bus notifier has run. As such, even if this funny little check did make
> sense, it's unlikely to achieve what it thinks it's trying to do anyway.
> It's a residual trace of an earlier implementation which didn't belong
> here from the start; belatedly snuff it out.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
> arch/arm64/mm/dma-mapping.c | 5 -----
> 1 file changed, 5 deletions(-)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index 5cd0a383b14b..290a84f3351f 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -940,11 +940,6 @@ static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
>
> void arch_teardown_dma_ops(struct device *dev)
> {
> - struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
> -
> - if (WARN_ON(domain))
> - iommu_detach_device(domain, dev);
> -
> dev->archdata.dma_ops = NULL;
> }
Acked-by: Will Deacon <will.deacon@arm.com>
I guess Catalin will pick this up when he starts queueing things for
4.10.
Will
^ permalink raw reply
* [PATCH V5 3/3] ACPI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs
From: Sinan Kaya @ 2016-10-26 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB2KywvUKAv84kvoyAV2YkqtOL9LbFOqSTLgZ=dCk-Z5xA@mail.gmail.com>
Thanks Jonathan,
On 10/24/2016 12:46 AM, Jonathan Liu wrote:
>> 1.9.1
>> >
> This series fixes one or more network adapters not working in Linux
> 32-bit x86 guest running inside VirtualBox if I have 4 network
> adapters enabled.
> The following message no longer appears in the kernel log:
> ACPI: No IRQ available for PCI Interrupt Link [LNKD]. Try pci=noacpi or acpi=off
>
> Tested-by: Jonathan Liu <net147@gmail.com>
Can we also get some more testing coverage from the people in TO?
We want to make sure that we fixed all outstanding ACPI PCI IRQ issues.
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES
From: Will Deacon @ 2016-10-26 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477364358-10620-3-git-send-email-thunder.leizhen@huawei.com>
On Tue, Oct 25, 2016 at 10:59:18AM +0800, Zhen Lei wrote:
> Some numa nodes may have no memory. For example:
> 1) a node has no memory bank plugged.
> 2) a node has no memory bank slots.
>
> To ensure percpu variable areas and numa control blocks of the
> memoryless numa nodes to be allocated from the nearest available node to
> improve performance, defined node_distance_ready. And make its value to be
> true immediately after node distances have been initialized.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> arch/arm64/Kconfig | 4 ++++
> arch/arm64/include/asm/numa.h | 3 +++
> arch/arm64/mm/numa.c | 6 +++++-
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 30398db..648dd13 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -609,6 +609,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
> def_bool y
> depends on NUMA
>
> +config HAVE_MEMORYLESS_NODES
> + def_bool y
> + depends on NUMA
Given that patch 1 and the associated node_distance_ready stuff is all
an unqualified performance optimisation, is there any merit in just
enabling HAVE_MEMORYLESS_NODES in Kconfig and then optimising things as
a separate series when you have numbers to back it up?
Will
^ permalink raw reply
* [RFC PATCH 1/5] of: introduce the overlay manager
From: Thomas Petazzoni @ 2016-10-26 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyszsn2TLYhUjHMt2ZnEUmE9eSc71W2KWBL0fWhh3PPBw@mail.gmail.com>
Hello,
On Wed, 26 Oct 2016 10:29:59 -0600, Mathieu Poirier wrote:
> > + overlay = devm_kzalloc(dev, sizeof(*overlay), GFP_KERNEL);
>
> Function devm_kzalloc() can sleep but you're holding a spinlock - I'm
> surprised the kernel didn't complain here. Allocate the memory before
> holding the lock. If the overly is already loaded simply free it on
> the error path.
Actually, I'm not sure using a spinlock here is appropriate. Using a
mutex would probably be better.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* MAINTAINERS entry for ARM/CLKDEV SUPPORT
From: Dan Carpenter @ 2016-10-26 19:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010141819.GA1041@n2100.armlinux.org.uk>
On Mon, Oct 10, 2016 at 03:18:19PM +0100, Russell King - ARM Linux wrote:
> On Mon, Oct 10, 2016 at 05:08:10PM +0300, Dan Carpenter wrote:
> > Hello Stephen Boyd,
>
> Okay, that's really not nice.
>
> This is _not_ a question for Stephen. Stephen does _not_ co-maintain
> clkdev or the clk API, but co-maintains CCF. I've no idea why you are
> addressing this to Stephen when this is clearly a question for me to
> answer.
>
Sorry, I didn't mean to offend. He's the one who deleted the clkdev.h
file though so I thought he might know if it should still be listed or
if it was gone for good.
The clkdev.c question was a throw away thing that occured to me before I
hit send.
regards,
dan carpenter
^ permalink raw reply
* [PATCH 0/5] add NS2 support to bgmac
From: Jon Mason @ 2016-10-26 19:35 UTC (permalink / raw)
To: linux-arm-kernel
Add support for the amac found in the Broadcom Northstar2 SoC to the
bgmac driver. This necessitates adding support to connect to an
externally defined phy (as described in the device tree) in the driver.
These phy changes are in addition to the changes necessary to get NS2
working.
This series (based on the net-next git tree) has been tested on NSP and
NS2 HW.
Jon Mason (4):
Documentation: devicetree: net: add NS2 bindings to amac
net: ethernet: bgmac: device tree phy enablement
net: ethernet: bgmac: add NS2 support
arm64: dts: NS2: add AMAC ethernet support
Vikas Soni (1):
net: phy: broadcom: Add BCM54810 phy entry
.../devicetree/bindings/net/brcm,amac.txt | 7 +-
arch/arm64/boot/dts/broadcom/ns2-svk.dts | 5 +
arch/arm64/boot/dts/broadcom/ns2.dtsi | 12 +++
drivers/net/ethernet/broadcom/bgmac-bcma.c | 48 +++++++++
drivers/net/ethernet/broadcom/bgmac-platform.c | 108 ++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 56 +----------
drivers/net/ethernet/broadcom/bgmac.h | 9 ++
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/broadcom.c | 65 +++++++++++++
include/linux/brcmphy.h | 7 ++
10 files changed, 264 insertions(+), 55 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/5] net: phy: broadcom: Add BCM54810 phy entry
From: Jon Mason @ 2016-10-26 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-1-git-send-email-jon.mason@broadcom.com>
From: Vikas Soni <vsoni@broadcom.com>
Add BCM54810 phy entry
Signed-off-by: Vikas Soni <vsoni@broadcom.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/net/phy/Kconfig | 2 +-
drivers/net/phy/broadcom.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/brcmphy.h | 7 +++++
3 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 45f68ea..31967ca 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -217,7 +217,7 @@ config BROADCOM_PHY
select BCM_NET_PHYLIB
---help---
Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
- BCM5481 and BCM5482 PHYs.
+ BCM5481, BCM54810 and BCM5482 PHYs.
config CICADA_PHY
tristate "Cicada PHYs"
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 870327e..cdce761 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -35,6 +35,35 @@ static int bcm54xx_auxctl_write(struct phy_device *phydev, u16 regnum, u16 val)
return phy_write(phydev, MII_BCM54XX_AUX_CTL, regnum | val);
}
+static int bcm54810_config(struct phy_device *phydev)
+{
+ int rc;
+
+ /* Disable BroadR-Reach */
+ rc = bcm_phy_write_exp(phydev, BCM54810_EXP_BROADREACH_LRE_MISC_CTL, 0);
+ if (rc < 0)
+ return rc;
+
+ /* SKEW DISABLE */
+ rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ 0xF0E0);
+ if (rc < 0)
+ return rc;
+
+ /* DELAY DISABLE */
+ rc = bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ 0x7000);
+ if (rc < 0)
+ return rc;
+
+ /* DELAY DISABLE */
+ rc = bcm_phy_write_shadow(phydev, BCM54810_SHD_CLK_CTL, 0);
+ if (rc < 0)
+ return rc;
+
+ return 0;
+}
+
/* Needs SMDSP clock enabled via bcm54xx_phydsp_config() */
static int bcm50610_a0_workaround(struct phy_device *phydev)
{
@@ -207,6 +236,20 @@ static int bcm54xx_config_init(struct phy_device *phydev)
(phydev->dev_flags & PHY_BRCM_AUTO_PWRDWN_ENABLE))
bcm54xx_adjust_rxrefclk(phydev);
+ if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810) {
+ err = bcm54810_config(phydev);
+ if (err)
+ return err;
+
+ reg = phy_read(phydev, MII_BMCR);
+ if (reg < 0)
+ return reg;
+
+ err = phy_write(phydev, MII_BMCR, reg & ~BMCR_PDOWN);
+ if (err)
+ return err;
+ }
+
bcm54xx_phydsp_config(phydev);
return 0;
@@ -334,6 +377,15 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
phy_write(phydev, 0x18, reg);
}
+ if (BRCM_PHY_MODEL(phydev) == PHY_ID_BCM54810 &&
+ phydev->dev_flags & PHY_BRCM_EXP_LANE_SWAP) {
+ /* LANE SWAP */
+ ret = bcm_phy_write_exp(phydev, MII_BCM54XX_EXP_SEL_ER + 0x9,
+ 0x11B);
+ if (ret < 0)
+ return ret;
+ }
+
return ret;
}
@@ -521,6 +573,18 @@ static struct phy_driver broadcom_drivers[] = {
.ack_interrupt = bcm_phy_ack_intr,
.config_intr = bcm_phy_config_intr,
}, {
+ .phy_id = PHY_ID_BCM54810,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM54810",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = bcm5481_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm_phy_ack_intr,
+ .config_intr = bcm_phy_config_intr,
+}, {
.phy_id = PHY_ID_BCM5482,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5482",
@@ -603,6 +667,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
{ PHY_ID_BCM54616S, 0xfffffff0 },
{ PHY_ID_BCM5464, 0xfffffff0 },
{ PHY_ID_BCM5481, 0xfffffff0 },
+ { PHY_ID_BCM54810, 0xfffffff0 },
{ PHY_ID_BCM5482, 0xfffffff0 },
{ PHY_ID_BCM50610, 0xfffffff0 },
{ PHY_ID_BCM50610M, 0xfffffff0 },
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index e7a3d9d..40e6ead 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -13,6 +13,7 @@
#define PHY_ID_BCM5241 0x0143bc30
#define PHY_ID_BCMAC131 0x0143bc70
#define PHY_ID_BCM5481 0x0143bca0
+#define PHY_ID_BCM54810 0x03625d00
#define PHY_ID_BCM5482 0x0143bcb0
#define PHY_ID_BCM5411 0x00206070
#define PHY_ID_BCM5421 0x002060e0
@@ -55,6 +56,8 @@
#define PHY_BRCM_EXT_IBND_TX_ENABLE 0x00002000
#define PHY_BRCM_CLEAR_RGMII_MODE 0x00004000
#define PHY_BRCM_DIS_TXCRXC_NOENRGY 0x00008000
+#define PHY_BRCM_EXP_LANE_SWAP 0x00010000
+
/* Broadcom BCM7xxx specific workarounds */
#define PHY_BRCM_7XXX_REV(x) (((x) >> 8) & 0xff)
#define PHY_BRCM_7XXX_PATCH(x) ((x) & 0xff)
@@ -187,6 +190,10 @@
#define BCM5482_SSD_SGMII_SLAVE_EN 0x0002 /* Slave mode enable */
#define BCM5482_SSD_SGMII_SLAVE_AD 0x0001 /* Slave auto-detection */
+/* BCM54810 Registers */
+#define BCM54810_EXP_BROADREACH_LRE_MISC_CTL (MII_BCM54XX_EXP_SEL_ER + 0x90)
+#define BCM54810_SHD_CLK_CTL 0x3
+
/*****************************************************************************/
/* Fast Ethernet Transceiver definitions. */
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] Documentation: devicetree: net: add NS2 bindings to amac
From: Jon Mason @ 2016-10-26 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-1-git-send-email-jon.mason@broadcom.com>
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
Documentation/devicetree/bindings/net/brcm,amac.txt | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/brcm,amac.txt b/Documentation/devicetree/bindings/net/brcm,amac.txt
index ba5ecc1..f92caee 100644
--- a/Documentation/devicetree/bindings/net/brcm,amac.txt
+++ b/Documentation/devicetree/bindings/net/brcm,amac.txt
@@ -2,15 +2,18 @@ Broadcom AMAC Ethernet Controller Device Tree Bindings
-------------------------------------------------------------
Required properties:
- - compatible: "brcm,amac" or "brcm,nsp-amac"
+ - compatible: "brcm,amac", "brcm,nsp-amac", or "brcm,ns2-amac"
- reg: Address and length of the GMAC registers,
Address and length of the GMAC IDM registers
+ Address and length of the NIC Port Manager registers (optional)
- reg-names: Names of the registers. Must have both "amac_base" and
- "idm_base"
+ "idm_base". "nicpm_base" is optional (required for NS2)
- interrupts: Interrupt number
Optional properties:
- mac-address: See ethernet.txt file in the same directory
+- brcm,enet-phy-lane-swap:
+ boolean; Swap the PHY lanes (needed on some SKUs of NS2)
Examples:
--
2.7.4
^ permalink raw reply related
* [PATCH 3/5] net: ethernet: bgmac: device tree phy enablement
From: Jon Mason @ 2016-10-26 19:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477510561-17035-1-git-send-email-jon.mason@broadcom.com>
Change the bgmac driver to allow for phy's defined by the device tree
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
drivers/net/ethernet/broadcom/bgmac-bcma.c | 48 ++++++++++++++++++++++++
drivers/net/ethernet/broadcom/bgmac-platform.c | 48 +++++++++++++++++++++++-
drivers/net/ethernet/broadcom/bgmac.c | 51 +-------------------------
drivers/net/ethernet/broadcom/bgmac.h | 7 ++++
4 files changed, 104 insertions(+), 50 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c b/drivers/net/ethernet/broadcom/bgmac-bcma.c
index c16ec3a..3e3efde 100644
--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
+++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
@@ -80,6 +80,50 @@ static void bcma_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset, u32 mask,
bcma_maskset32(bgmac->bcma.cmn, offset, mask, set);
}
+static int bcma_phy_connect(struct bgmac *bgmac)
+{
+ struct phy_device *phy_dev;
+ char bus_id[MII_BUS_ID_SIZE + 3];
+
+ /* Connect to the PHY */
+ snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
+ bgmac->phyaddr);
+ phy_dev = phy_connect(bgmac->net_dev, bus_id, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "PHY connecton failed\n");
+ return PTR_ERR(phy_dev);
+ }
+
+ return 0;
+}
+
+static int bcma_phy_direct_connect(struct bgmac *bgmac)
+{
+ struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ };
+ struct phy_device *phy_dev;
+ int err;
+
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ if (!phy_dev || IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+ return -ENODEV;
+ }
+
+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (err) {
+ dev_err(bgmac->dev, "Connecting PHY failed\n");
+ return err;
+ }
+
+ return err;
+}
+
static const struct bcma_device_id bgmac_bcma_tbl[] = {
BCMA_CORE(BCMA_MANUF_BCM, BCMA_CORE_4706_MAC_GBIT,
BCMA_ANY_REV, BCMA_ANY_CLASS),
@@ -275,6 +319,10 @@ static int bgmac_probe(struct bcma_device *core)
bgmac->cco_ctl_maskset = bcma_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = bcma_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = bcma_bgmac_cmn_maskset32;
+ if (bgmac->mii_bus)
+ bgmac->phy_connect = bcma_phy_connect;
+ else
+ bgmac->phy_connect = bcma_phy_direct_connect;
err = bgmac_enet_probe(bgmac);
if (err)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c b/drivers/net/ethernet/broadcom/bgmac-platform.c
index be52f27..aed5dc5 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -16,6 +16,7 @@
#include <linux/bcma/bcma.h>
#include <linux/etherdevice.h>
#include <linux/of_address.h>
+#include <linux/of_mdio.h>
#include <linux/of_net.h>
#include "bgmac.h"
@@ -86,6 +87,46 @@ static void platform_bgmac_cmn_maskset32(struct bgmac *bgmac, u16 offset,
WARN_ON(1);
}
+static int platform_phy_connect(struct bgmac *bgmac)
+{
+ struct phy_device *phy_dev;
+
+ phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
+ bgmac_adjust_link);
+ if (!phy_dev) {
+ dev_err(bgmac->dev, "Phy connect failed\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static int platform_phy_direct_connect(struct bgmac *bgmac)
+{
+ struct fixed_phy_status fphy_status = {
+ .link = 1,
+ .speed = SPEED_1000,
+ .duplex = DUPLEX_FULL,
+ };
+ struct phy_device *phy_dev;
+ int err;
+
+ phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
+ if (!phy_dev || IS_ERR(phy_dev)) {
+ dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
+ return -ENODEV;
+ }
+
+ err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
+ PHY_INTERFACE_MODE_MII);
+ if (err) {
+ dev_err(bgmac->dev, "Connecting PHY failed\n");
+ return err;
+ }
+
+ return err;
+}
+
static int bgmac_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -102,7 +143,6 @@ static int bgmac_probe(struct platform_device *pdev)
/* Set the features of the 4707 family */
bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
- bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
bgmac->feature_flags |= BGMAC_FEAT_CMDCFG_SR_REV4;
bgmac->feature_flags |= BGMAC_FEAT_TX_MASK_SETUP;
bgmac->feature_flags |= BGMAC_FEAT_RX_MASK_SETUP;
@@ -151,6 +191,12 @@ static int bgmac_probe(struct platform_device *pdev)
bgmac->cco_ctl_maskset = platform_bgmac_cco_ctl_maskset;
bgmac->get_bus_clock = platform_bgmac_get_bus_clock;
bgmac->cmn_maskset32 = platform_bgmac_cmn_maskset32;
+ if (of_parse_phandle(np, "phy-handle", 0)) {
+ bgmac->phy_connect = platform_phy_connect;
+ } else {
+ bgmac->phy_connect = platform_phy_direct_connect;
+ bgmac->feature_flags |= BGMAC_FEAT_FORCE_SPEED_2500;
+ }
return bgmac_enet_probe(bgmac);
}
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 856379c..38876ec 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1388,7 +1388,7 @@ static const struct ethtool_ops bgmac_ethtool_ops = {
* MII
**************************************************/
-static void bgmac_adjust_link(struct net_device *net_dev)
+void bgmac_adjust_link(struct net_device *net_dev)
{
struct bgmac *bgmac = netdev_priv(net_dev);
struct phy_device *phy_dev = net_dev->phydev;
@@ -1412,50 +1412,6 @@ static void bgmac_adjust_link(struct net_device *net_dev)
}
}
-static int bgmac_phy_connect_direct(struct bgmac *bgmac)
-{
- struct fixed_phy_status fphy_status = {
- .link = 1,
- .speed = SPEED_1000,
- .duplex = DUPLEX_FULL,
- };
- struct phy_device *phy_dev;
- int err;
-
- phy_dev = fixed_phy_register(PHY_POLL, &fphy_status, -1, NULL);
- if (!phy_dev || IS_ERR(phy_dev)) {
- dev_err(bgmac->dev, "Failed to register fixed PHY device\n");
- return -ENODEV;
- }
-
- err = phy_connect_direct(bgmac->net_dev, phy_dev, bgmac_adjust_link,
- PHY_INTERFACE_MODE_MII);
- if (err) {
- dev_err(bgmac->dev, "Connecting PHY failed\n");
- return err;
- }
-
- return err;
-}
-
-static int bgmac_phy_connect(struct bgmac *bgmac)
-{
- struct phy_device *phy_dev;
- char bus_id[MII_BUS_ID_SIZE + 3];
-
- /* Connect to the PHY */
- snprintf(bus_id, sizeof(bus_id), PHY_ID_FMT, bgmac->mii_bus->id,
- bgmac->phyaddr);
- phy_dev = phy_connect(bgmac->net_dev, bus_id, &bgmac_adjust_link,
- PHY_INTERFACE_MODE_MII);
- if (IS_ERR(phy_dev)) {
- dev_err(bgmac->dev, "PHY connecton failed\n");
- return PTR_ERR(phy_dev);
- }
-
- return 0;
-}
-
int bgmac_enet_probe(struct bgmac *info)
{
struct net_device *net_dev;
@@ -1507,10 +1463,7 @@ int bgmac_enet_probe(struct bgmac *info)
netif_napi_add(net_dev, &bgmac->napi, bgmac_poll, BGMAC_WEIGHT);
- if (!bgmac->mii_bus)
- err = bgmac_phy_connect_direct(bgmac);
- else
- err = bgmac_phy_connect(bgmac);
+ err = bgmac_phy_connect(bgmac);
if (err) {
dev_err(bgmac->dev, "Cannot connect to phy\n");
goto err_dma_free;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index 80836b4..ea52ac3 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -513,10 +513,12 @@ struct bgmac {
u32 (*get_bus_clock)(struct bgmac *bgmac);
void (*cmn_maskset32)(struct bgmac *bgmac, u16 offset, u32 mask,
u32 set);
+ int (*phy_connect)(struct bgmac *bgmac);
};
int bgmac_enet_probe(struct bgmac *info);
void bgmac_enet_remove(struct bgmac *bgmac);
+void bgmac_adjust_link(struct net_device *net_dev);
struct mii_bus *bcma_mdio_mii_register(struct bcma_device *core, u8 phyaddr);
void bcma_mdio_mii_unregister(struct mii_bus *mii_bus);
@@ -583,4 +585,9 @@ static inline void bgmac_set(struct bgmac *bgmac, u16 offset, u32 set)
{
bgmac_maskset(bgmac, offset, ~0, set);
}
+
+static inline int bgmac_phy_connect(struct bgmac *bgmac)
+{
+ return bgmac->phy_connect(bgmac);
+}
#endif /* _BGMAC_H */
--
2.7.4
^ 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