* [PATCH 1/3] ARM: dts: at91: add dma1 definition to sama5d2
From: Nicolas Ferre @ 2016-12-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
The sama5d2 SoC has a second DMA controller and can be used just like DMA0.
By default both DMA controllers are configured as "Secure" in
MATRIX_SPSELR so we can use whichever we want in a "single Secure World"
configuration.
Surprisingly the DMA1 has a lower address than DMA0. To avoid confusion
place it after DMA0 node anyway.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d2.dtsi | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index ceb9783ff7e1..c791ce9c750c 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -395,6 +395,16 @@
clock-names = "dma_clk";
};
+ /* Place dma1 here despite its address */
+ dma1: dma-controller at f0004000 {
+ compatible = "atmel,sama5d4-dma";
+ reg = <0xf0004000 0x1000>;
+ interrupts = <7 IRQ_TYPE_LEVEL_HIGH 0>;
+ #dma-cells = <1>;
+ clocks = <&dma1_clk>;
+ clock-names = "dma_clk";
+ };
+
pmc: pmc at f0014000 {
compatible = "atmel,sama5d2-pmc", "syscon";
reg = <0xf0014000 0x160>;
--
2.9.0
^ permalink raw reply related
* [PATCH 2/3] ARM: dts: at91: sama5d2: move UART3 to DMA1
From: Nicolas Ferre @ 2016-12-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104949.23985-1-nicolas.ferre@atmel.com>
Now that DMA1 is defined, use it to distribute channel usage among the two
controllers.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/sama5d2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index c791ce9c750c..5b69eff523d9 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -1151,10 +1151,10 @@
compatible = "atmel,at91sam9260-usart";
reg = <0xfc008000 0x100>;
interrupts = <27 IRQ_TYPE_LEVEL_HIGH 7>;
- dmas = <&dma0
+ dmas = <&dma1
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
AT91_XDMAC_DT_PERID(41))>,
- <&dma0
+ <&dma1
(AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) |
AT91_XDMAC_DT_PERID(42))>;
dma-names = "tx", "rx";
--
2.9.0
^ permalink raw reply related
* [PATCH 3/3] ARM: dts: at91: sama5d2 Xplained: use DMA for UART3
From: Nicolas Ferre @ 2016-12-01 10:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104949.23985-1-nicolas.ferre@atmel.com>
Use DMA for UART3 as we have enough channels and to show how to
specify DMA use with serial nodes.
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/at91-sama5d2_xplained.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/at91-sama5d2_xplained.dts b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
index 0b9a59d5fdac..e2d5cb3fecb1 100644
--- a/arch/arm/boot/dts/at91-sama5d2_xplained.dts
+++ b/arch/arm/boot/dts/at91-sama5d2_xplained.dts
@@ -256,6 +256,8 @@
};
uart3: serial at fc008000 {
+ atmel,use-dma-rx;
+ atmel,use-dma-tx;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3_default>;
status = "okay";
--
2.9.0
^ permalink raw reply related
* [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
From: Marc Zyngier @ 2016-12-01 10:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA817475F7E@lhreml504-mbs>
On 01/12/16 10:28, Shameerali Kolothum Thodi wrote:
> Hi Marc,
>
>> -----Original Message-----
>> From: kvmarm-bounces at lists.cs.columbia.edu [mailto:kvmarm-
>> bounces at lists.cs.columbia.edu] On Behalf Of Marc Zyngier
>> Sent: Thursday, December 01, 2016 9:26 AM
>> To: Paolo Bonzini; Radim Kr?m??
>> Cc: Catalin Marinas; kvmarm at lists.cs.columbia.edu; linux-arm-
>> kernel at lists.infradead.org; kvm at vger.kernel.org
>> Subject: [PATCH] KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs
>>
>> When we inject a level triggerered interrupt (and unless it is backed
>> by the physical distributor - timer style), we request a maintenance
>> interrupt. Part of the processing for that interrupt is to feed to the
>> rest of KVM (and to the eventfd subsystem) the information that the
>> interrupt has been EOIed.
>>
>> But that notification only makes sense for SPIs, and not PPIs (such as
>> the PMU interrupt). Skip over the notification if the interrupt is not
>> an SPI.
>
> Just to clarify my understanding, the maintenance interrupt is generated
> for cases where there is no mapping of virt to phys interrupts
> (ie, ICH_LR HW bit is not set). And I was under the impression that
> kvm_notify_acked_irq will eventually deactivate the interrupt on distributor
> for such cases. Its not clear to me how the deactivation is done
> otherwise.
>
> Could you please help me to understand this better.
kvm_notify_acked_irq() doesn't do *anything* at the distributor level,
ever (it has no idea of anything GIC-specific anyway). It's sole job is
to signal the rest of the stack that an interrupt has been EOIed in the
guest.
For these interrupts, which are purely virtual, there is absolutely
nothing to do at the physical distributor level anyway. Furthermore,
kvm_notify_acked_irq doesn't know about per-cpu interrupt, which is why
we cannot notify them.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] mach-omap2: fixing wrong strcat for Non-NULL terminated string
From: Maninder Singh @ 2016-12-01 10:58 UTC (permalink / raw)
To: linux-arm-kernel
variable name can have Non NULL terminated string after cropping
which may result strcat to fail, and cropping is not
required if (strlen(oh->name) + 8 < MOD_CLK_MAX_NAME_LEN).
Issue caught with static analysis tool:
"Dangerous usage of 'name' (strncpy doesn't always 0-terminate it)"
Signed-off-by: Vaneet Narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
---
v1 -> v2: changed strncpy to strlcpy
arch/arm/mach-omap2/omap_hwmod.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 759e1d4..582b95a 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -742,12 +742,14 @@ static int _init_main_clk(struct omap_hwmod *oh)
char name[MOD_CLK_MAX_NAME_LEN];
struct clk *clk;
- /* +7 magic comes from '_mod_ck' suffix */
- if (strlen(oh->name) + 7 > MOD_CLK_MAX_NAME_LEN)
+ /* +8 magic comes from strlen("_mod_ck") added as suffix */
+ if (strlen(oh->name) + 8 > MOD_CLK_MAX_NAME_LEN) {
pr_warn("%s: warning: cropping name for %s\n", __func__,
oh->name);
+ strlcpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
+ } else
+ strcpy(name, oh->name);
- strncpy(name, oh->name, MOD_CLK_MAX_NAME_LEN - 7);
strcat(name, "_mod_ck");
clk = clk_get(NULL, name);
--
1.9.1
^ permalink raw reply related
* [PATCH v7 0/4] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (4):
i2c: pxa: Add definition of fast and high speed modes via the regs
layout
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 26 +++++++++++++++++++++--
5 files changed, 48 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v7 1/4] i2c: pxa: Add definition of fast and high speed modes via the regs layout
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
So far, the bit masks for the fast and high speed mode were statically
defined. Some IP blocks might use different bits for these modes.
This commit introduces new fields in order to enable the definition of
different bit masks for these features. If these fields are undefined,
ICR_FM and ICR_HS are selected to preserve backward compatibility with
other IPs.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v7:
- Fixed line over 80 characters for fm_mask and hs_mask in the probe
function.
drivers/i2c/busses/i2c-pxa.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..b4ac235 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -48,6 +48,8 @@ struct pxa_reg_layout {
u32 isar;
u32 ilcr;
u32 iwcr;
+ u32 fm;
+ u32 hs;
};
enum pxa_i2c_types {
@@ -193,6 +195,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ u32 fm_mask;
+ u32 hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +507,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1234,6 +1238,9 @@ static int i2c_pxa_probe(struct platform_device *dev)
i2c->reg_idbr = i2c->reg_base + pxa_reg_layout[i2c_type].idbr;
i2c->reg_icr = i2c->reg_base + pxa_reg_layout[i2c_type].icr;
i2c->reg_isr = i2c->reg_base + pxa_reg_layout[i2c_type].isr;
+ i2c->fm_mask = pxa_reg_layout[i2c_type].fm ? : ICR_FM;
+ i2c->hs_mask = pxa_reg_layout[i2c_type].hs ? : ICR_HS;
+
if (i2c_type != REGS_CE4100)
i2c->reg_isar = i2c->reg_base + pxa_reg_layout[i2c_type].isar;
--
2.9.3
^ permalink raw reply related
* [PATCH v7 2/4] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
Changes in v6:
- Revert back A3700_REGS, as asked by Wolfram and define fm_mask
and hs_mask in the register layout. I moved the generic code
for fm_mask and hs_mask to a seperated commit (1/4)
Changes in v5:
- Don't define registers for armada-3700, we can re-use the ones
for PXA3XX.
- Define registers mask when OF is not used, in probe_pdata.
Changes in v4:
- Replaced the type of hs_mask and fm_mask by u32, instead of
unsigned int, As writel() take an u32 as first argument...
Changes in v3:
- Replaced the type of hs_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 15 +++++++++++++++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index b4ac235..6cf333e 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -57,8 +57,12 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
+
/*
* I2C registers definitions
*/
@@ -93,6 +97,15 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ .fm = ICR_BUSMODE_FM,
+ .hs = ICR_BUSMODE_HS,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -100,6 +113,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -1141,6 +1155,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
--
2.9.3
^ permalink raw reply related
* [PATCH v7 3/4] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e9bd587..1b0fd21 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c at 11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_periph_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c at 11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_periph_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial at 12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* [PATCH v7 4/4] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-12-01 11:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201110440.27530-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Rob Herring <robh@kernel.org>
---
Changes in v5:
- Added the tag 'Acked-by', by Rob Herring
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v3 11/14] ACPI: irq: introduce interrupt producer
From: Aleksey Makarov @ 2016-12-01 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477408169-22217-12-git-send-email-guohanjun@huawei.com>
Hi Hanjun,
On 10/25/2016 09:09 PM, Hanjun Guo wrote:
> From: Hanjun Guo <hanjun.guo@linaro.org>
>
> In ACPI 6.1 spec, section 19.6.62, Interrupt Resource Descriptor Macro,
[ ... ]
> ---
> drivers/acpi/gsi.c | 10 ++++--
> drivers/acpi/resource.c | 85 ++++++++++++++++++++++++++++++++++---------------
> include/acpi/acpi_bus.h | 1 +
> 3 files changed, 68 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/acpi/gsi.c b/drivers/acpi/gsi.c
> index ee9e0f2..29ee547 100644
> --- a/drivers/acpi/gsi.c
> +++ b/drivers/acpi/gsi.c
> @@ -55,13 +55,19 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
> int polarity)
> {
> struct irq_fwspec fwspec;
> + struct acpi_device *adev = dev ? to_acpi_device(dev) : NULL;
Why are you sure dev is always an acpi device?
Look for example at drivers/acpi/pci_irq.c:377 where this function
is called for a PCI device
>
> - if (WARN_ON(!acpi_gsi_domain_id)) {
> + if (adev && &adev->fwnode && adev->interrupt_producer)
&adev->fwnode is always true
> + /* devices in DSDT connecting to spefic interrupt producer */
> + fwspec.fwnode = adev->interrupt_producer;
> + else if (acpi_gsi_domain_id)
> + /* devices connecting to gicd in default */
> + fwspec.fwnode = acpi_gsi_domain_id;
> + else {
> pr_warn("GSI: No registered irqchip, giving up\n");
> return -EINVAL;
> }
[ ... ]
All the best
Aleksey Makarov
^ permalink raw reply
* [GIT PULL 1/6] Broadcom soc changes for 4.10
From: Rafał Miłecki @ 2016-12-01 11:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <23121827.vnVDrZQAeV@wuerfel>
On 2016-11-30 17:52, Arnd Bergmann wrote:
> On Monday, November 21, 2016 9:48:19 PM CET Florian Fainelli wrote:
>> This pull request contains Broadcom ARM-based SoC changes for 4.10,
>> please pull
>> the following:
>>
>> - Rafal adds back the abort handler hook on BCM5301x which is required
>> to silence
>> errors forwared from the PCIe controller that cannot be silenced at
>> the PCIe RC level
>>
>
> Pulled into next/soc.
>
> It's unclear to me whether we want this to be backported to stable
> kernels,
> can you clarify?
It took me/us so much time to get an agreement on this patch I totally
forgot
about backporting it to stable.
To be clear it indeed fixes a regression. Commit 937b12306ea79 ("ARM:
BCM5301X:
remove workaround imprecise abort fault handler") went into 4.5, so this
one
could be backported to 4.5+.
As this has been already pulled, I think I'll wait for it to appear in
Linus's
tree and just e-mail stable guys manually (unless someone objects).
Thanks for
bringing my attention to this.
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: used managed kasprintf
From: Nicolas Ferre @ 2016-12-01 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201102656.29041-1-alexandre.belloni@free-electrons.com>
Le 01/12/2016 ? 11:26, Alexandre Belloni a ?crit :
> Use devm_kasprintf instead of simple kasprintf to free the allocated memory
> when needed.
>
> Suggested-by: Peter Rosin <peda@axentia.se>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/usb/gadget/udc/atmel_usba_udc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
> index 45bc997d0711..aec72fe8273c 100644
> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
> @@ -1978,7 +1978,8 @@ 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 = kasprintf(GFP_KERNEL, "ep%d", ep->index);
> + ep->ep.name = devm_kasprintf(&pdev->dev, 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] dmaengine: at_xdmac: don't restore unsaved status
From: Nicolas Ferre @ 2016-12-01 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201104903.30019-1-alexandre.belloni@free-electrons.com>
Le 01/12/2016 ? 11:49, Alexandre Belloni a ?crit :
> save_gs is supposed to save the channel status in order to be restored at
> resume time but it is never updated and is always 0. Anyway, the channel
> status is updated in the per channel loop later in the resume function.
>
> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Indeed, seems superfluous...
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/dma/at_xdmac.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
> index b7d7f2d443a1..8c1abb794340 100644
> --- a/drivers/dma/at_xdmac.c
> +++ b/drivers/dma/at_xdmac.c
> @@ -221,7 +221,6 @@ struct at_xdmac {
> int irq;
> struct clk *clk;
> u32 save_gim;
> - u32 save_gs;
> struct dma_pool *at_xdmac_desc_pool;
> struct at_xdmac_chan chan[0];
> };
> @@ -1896,7 +1895,6 @@ static int atmel_xdmac_resume(struct device *dev)
> }
>
> at_xdmac_write(atxdmac, AT_XDMAC_GIE, atxdmac->save_gim);
> - at_xdmac_write(atxdmac, AT_XDMAC_GE, atxdmac->save_gs);
> list_for_each_entry_safe(chan, _chan, &atxdmac->dma.channels, device_node) {
> atchan = to_at_xdmac_chan(chan);
> at_xdmac_chan_write(atchan, AT_XDMAC_CC, atchan->save_cc);
>
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-12-01 11:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6b4d20a85b05e93d254e265eb07569dd1285d303.1480542157.git-series.gregory.clement@free-electrons.com>
Hi Gregory, Marcin,
On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
> From: Marcin Wojtas <mw@semihalf.com>
>
> Prepare the mvneta driver in order to be usable on the 64 bits platform
> such as the Armada 3700.
>
> [gregory.clement at free-electrons.com]: this patch was extract from a larger
> one to ease review and maintenance.
>
> Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 92b9af14c352..8ef03fb69bcd 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -296,6 +296,12 @@
> /* descriptor aligned size */
> #define MVNETA_DESC_ALIGNED_SIZE 32
>
> +/* Number of bytes to be taken into account by HW when putting incoming data
> + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
> + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
We also brought up this driver on 64bit platforms, we doesn't have this
patch. Maybe I'm wrong, I'm trying to understand why we need this
modification. Let's assume the NET_SKB_PAD is 64B, we call
mvneta_rxq_offset_set(pp, rxq, 64),
{
u32 val;
val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
/* Offset is in */
val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
// then this will be "val |= 8;" it doesn't exceeds the max offset of
MVNETA_RXQ_CONFIG_REG(q) register.
Could you please kindly point out where I am wrong?
> + */
> +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
> +
> #define MVNETA_RX_PKT_SIZE(mtu) \
> ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
> ETH_HLEN + ETH_FCS_LEN, \
> @@ -416,6 +422,7 @@ struct mvneta_port {
> u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
>
> u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
> + u16 rx_offset_correction;
> };
>
> /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
> return -ENOMEM;
> }
>
> + phys_addr += pp->rx_offset_correction;
> mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
> return 0;
> }
> @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
> mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
>
> /* Set Offset */
> - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
> + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
>
> /* Set coalescing pkts and time */
> mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
> @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
>
> pp->rxq_def = rxq_def;
>
> + /* Set RX packet offset correction for platforms, whose
> + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
> + * platforms and 0B for 32-bit ones.
Even we need this patch, I'm not sure this last comment is correct or not.
NET_SKB_PAD is defined as:
#define NET_SKB_PAD max(32, L1_CACHE_BYTES)
we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
should be 64B as well.
Thanks,
Jisheng
^ permalink raw reply
* [PATCH 02/10] iommu/of: Prepare for deferred IOMMU configuration
From: Lorenzo Pieralisi @ 2016-12-01 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c89825aa-c75f-8493-fe92-7cc97f525bc7@arm.com>
On Wed, Nov 30, 2016 at 04:42:27PM +0000, Robin Murphy wrote:
> On 30/11/16 16:17, Lorenzo Pieralisi wrote:
> > Sricharan, Robin,
> >
> > I gave this series a go on ACPI and apart from an SMMU v3 fix-up
> > it seems to work, more thorough testing required though.
> >
> > A key question below.
> >
> > On Wed, Nov 30, 2016 at 05:52:16AM +0530, Sricharan R wrote:
> >> From: Robin Murphy <robin.murphy@arm.com>
> >>
> >> IOMMU configuration represents unchanging properties of the hardware,
> >> and as such should only need happen once in a device's lifetime, but
> >> the necessary interaction with the IOMMU device and driver complicates
> >> exactly when that point should be.
> >>
> >> Since the only reasonable tool available for handling the inter-device
> >> dependency is probe deferral, we need to prepare of_iommu_configure()
> >> to run later than it is currently called (i.e. at driver probe rather
> >> than device creation), to handle being retried, and to tell whether a
> >> not-yet present IOMMU should be waited for or skipped (by virtue of
> >> having declared a built-in driver or not).
> >>
> >> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> >> ---
> >> drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
> >> 1 file changed, 29 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> >> index ee49081..349bd1d 100644
> >> --- a/drivers/iommu/of_iommu.c
> >> +++ b/drivers/iommu/of_iommu.c
> >> @@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
> >> int err;
> >>
> >> ops = iommu_get_instance(fwnode);
> >> - if (!ops || !ops->of_xlate)
> >> + if ((ops && !ops->of_xlate) ||
> >> + (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
> >
> > IIUC of_match_node() here is there to check there is a driver compiled
> > in for this device_node (aka compatible string in OF world), correct ?
>
> Yes - specifically, it's checking the magic table for a matching
> IOMMU_OF_DECLARE entry.
>
> > If that's the case (and I think that's what Sricharan was referring to
> > in his ACPI query) I need to cook-up something on the ACPI side to
> > emulate the OF linker table behaviour (or anyway to detect a driver is
> > actually in the kernel), it is not that difficult but it is key to know,
> > I will give it some thought to make it as clean as possible.
>
> I didn't think this would be a concern for ACPI, since IORT works much
> the same way the current of_iommu_init_fn/of_platform_device_create()
> bodges in drivers so for DT. If you can only discover SMMUs from IORT,
> then iort_init_platform_devices() will have already created every SMMU
> that's going to exist before discovering other devices from wherever
> they come from, thus you could never get into the situation of probing a
> device without its SMMU being ready (if it's ever going to be). Is that
> not right?
It is right, my point and question is: we are probing a device and we
have to know whether it is worth deferring its IOMMU DMA setup. On DT,
through of_match_node(&__iommu_of_table, iommu_device_node) we check at
once that:
1 - A device for the IOMMU exists
AND
2 - A driver for the IOMMU is compiled in the kernel
Is this correct ? As you said (1) is not a concern on ACPI IORT (because
we create the IOMMU device before _any_ other device so either the IOMMU
device is there or it will never be by the time master devices are
probed), but for (2) I need to slightly change how the IORT linker entry
work to make sure we can detect a driver is actually compiled in the
kernel, it is easy, I was just asking if my understanding was correct
and I think that was what Sricharan was referring to in his query.
I will put together a patch, again, it is a simple tweak.
Thanks !
Lorenzo
> Robin.
>
> >
> > Thanks,
> > Lorenzo
> >
> >> return NULL;
> >>
> >> err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> >> if (err)
> >> return ERR_PTR(err);
> >> + /*
> >> + * The otherwise-empty fwspec handily serves to indicate the specific
> >> + * IOMMU device we're waiting for, which will be useful if we ever get
> >> + * a proper probe-ordering dependency mechanism in future.
> >> + */
> >> + if (!ops)
> >> + return ERR_PTR(-EPROBE_DEFER);
> >>
> >> err = ops->of_xlate(dev, iommu_spec);
> >> if (err)
> >> @@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
> >> struct device_node *master_np)
> >> {
> >> const struct iommu_ops *ops;
> >> + struct iommu_fwspec *fwspec = dev->iommu_fwspec;
> >>
> >> if (!master_np)
> >> return NULL;
> >>
> >> + if (fwspec) {
> >> + if (fwspec->ops)
> >> + return fwspec->ops;
> >> +
> >> + /* In the deferred case, start again from scratch */
> >> + iommu_fwspec_free(dev);
> >> + }
> >> +
> >> if (dev_is_pci(dev))
> >> ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
> >> else
> >> ops = of_platform_iommu_init(dev, master_np);
> >> + /*
> >> + * If we have reason to believe the IOMMU driver missed the initial
> >> + * add_device callback for dev, replay it to get things in order.
> >> + */
> >> + if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
> >> + dev->bus && !dev->iommu_group) {
> >> + int err = ops->add_device(dev);
> >> +
> >> + if (err)
> >> + ops = ERR_PTR(err);
> >> + }
> >>
> >> return IS_ERR(ops) ? NULL : ops;
> >> }
> >> --
> >> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> >>
>
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Jean-Francois Moine @ 2016-12-01 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5021537.YAZCMeDTSh@avalon>
On Thu, 01 Dec 2016 12:41:20 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> > > If a DVI connector instead of a HDMI connector is soldered, how
> > > should such a device tree be written?
> >
> > Use a dvi-connector instead :)
>
> The HDMI encoder DT node doesn't (and certainly shouldn't) report what type of
> connector is mounted on the board. Having a connector node in DT makes the
> connector type available to the system, allowing the DRM driver to expose the
> right connector type to userspace (it would be confusing for the user to
> report DRM_MODE_CONNECTOR_HDMIA for a DVI connector).
The connector type, HDMI or DVI, is known by the EDID.
The user is not interested by the software indication of the connector
type: (s)he knows it because (s)he connected him/herself the display
device.
And the DRM driver does not do anything from the knowledge of the
connector type in the DT. Only the EDID may tell if the display device
may do audio streaming (direct HDMI with audio capability) or not
(direct HDMI without audio, HDMI to DVI cable, DVI physical connector).
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
From: Will Deacon @ 2016-12-01 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACVXFVPsHjh3CWjdUrKB_r6=hkXK=qS3wpykbacdKe1rzz1H8Q@mail.gmail.com>
On Mon, Nov 28, 2016 at 11:10:14AM +0800, Ming Lei wrote:
> When I run stress-ng via the following steps on one ARM64 dual
> socket system(Cavium Thunder), the kernel oops[1] can often be
> triggered after running the stress test for several hours(sometimes
> it may take longer):
>
> - git clone git://kernel.ubuntu.com/cking/stress-ng.git
> - apply the attachment patch which just makes the posix file
> lock stress test more aggressive
> - run the test via '~/git/stress-ng$./stress-ng --lockf 128 --aggressive'
>
>
> From the oops log, looks one garbage file_lock node is got
> from the linked list of 'ctx->flc_posix' when the issue happens.
>
> BTW, the issue isn't observed on single socket Cavium Thunder yet,
> and the same issue can be seen on Ubuntu Xenial(v4.4 based kernel)
> too.
FWIW, I've been running this on Seattle for 24 hours with your patch applied
and not seen any problems yet. That said, Thomas did just fix an rt_mutex
race which only seemed to pop up on Thunder, so you could give those
patches a try.
https://lkml.kernel.org/r/20161130205431.629977871 at linutronix.de
Will
^ permalink raw reply
* [GIT PULL 1/6] Broadcom soc changes for 4.10
From: Arnd Bergmann @ 2016-12-01 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fa48be7a336e97c850b226d0c54c9b96@milecki.pl>
On Thursday, December 1, 2016 12:18:26 PM CET Rafa? Mi?ecki wrote:
> On 2016-11-30 17:52, Arnd Bergmann wrote:
> > On Monday, November 21, 2016 9:48:19 PM CET Florian Fainelli wrote:
> >> This pull request contains Broadcom ARM-based SoC changes for 4.10,
> >> please pull
> >> the following:
> >>
> >> - Rafal adds back the abort handler hook on BCM5301x which is required
> >> to silence
> >> errors forwared from the PCIe controller that cannot be silenced at
> >> the PCIe RC level
> >>
> >
> > Pulled into next/soc.
> >
> > It's unclear to me whether we want this to be backported to stable
> > kernels,
> > can you clarify?
>
> It took me/us so much time to get an agreement on this patch I totally
> forgot
> about backporting it to stable.
>
> To be clear it indeed fixes a regression. Commit 937b12306ea79 ("ARM:
> BCM5301X:
> remove workaround imprecise abort fault handler") went into 4.5, so this
> one
> could be backported to 4.5+.
>
> As this has been already pulled, I think I'll wait for it to appear in
> Linus's
> tree and just e-mail stable guys manually (unless someone objects).
> Thanks for
> bringing my attention to this.
Ok, sounds good. Thanks!
Arnd
^ permalink raw reply
* [PATCHv4 08/10] mm/kasan: Switch to using __pa_symbol and lm_alias
From: Andrey Ryabinin @ 2016-12-01 11:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-9-git-send-email-labbott@redhat.com>
On 11/29/2016 09:55 PM, Laura Abbott wrote:
> __pa_symbol is the correct API to find the physical address of symbols.
> Switch to it to allow for debugging APIs to work correctly.
But __pa() is correct for symbols. I see how __pa_symbol() might be a little
faster than __pa(), but there is nothing wrong in using __pa() on symbols.
> Other
> functions such as p*d_populate may call __pa internally. Ensure that the
> address passed is in the linear region by calling lm_alias.
Why it should be linear mapping address? __pa() translates kernel image address just fine.
This lm_alias() only obfuscates source code. Generated code is probably worse too.
^ permalink raw reply
* [PATCH v5 net-next 3/7] net: mvneta: Use cacheable memory to store the rx buffer virtual address
From: Jisheng Zhang @ 2016-12-01 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2e54b7711de0b971a7a9ee3662dad02d12bec385.1480542157.git-series.gregory.clement@free-electrons.com>
On Wed, 30 Nov 2016 22:42:48 +0100 Gregory CLEMENT wrote:
> Until now the virtual address of the received buffer were stored in the
> cookie field of the rx descriptor. However, this field is 32-bits only
> which prevents to use the driver on a 64-bits architecture.
>
> With this patch the virtual address is stored in an array not shared with
> the hardware (no more need to use the DMA API). Thanks to this, it is
> possible to use cache contrary to the access of the rx descriptor member.
>
> The change is done in the swbm path only because the hwbm uses the cookie
> field, this also means that currently the hwbm is not usable in 64-bits.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Reviewed-by: Jisheng Zhang <jszhang@marvell.com>
Thanks,
Jisheng
> ---
> drivers/net/ethernet/marvell/mvneta.c | 34 +++++++++++++++++++---------
> 1 file changed, 24 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index f5319c50f8d9..92b9af14c352 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -561,6 +561,9 @@ struct mvneta_rx_queue {
> u32 pkts_coal;
> u32 time_coal;
>
> + /* Virtual address of the RX buffer */
> + void **buf_virt_addr;
> +
> /* Virtual address of the RX DMA descriptors array */
> struct mvneta_rx_desc *descs;
>
> @@ -1573,10 +1576,14 @@ static void mvneta_tx_done_pkts_coal_set(struct mvneta_port *pp,
>
> /* Handle rx descriptor fill by setting buf_cookie and buf_phys_addr */
> static void mvneta_rx_desc_fill(struct mvneta_rx_desc *rx_desc,
> - u32 phys_addr, u32 cookie)
> + u32 phys_addr, void *virt_addr,
> + struct mvneta_rx_queue *rxq)
> {
> - rx_desc->buf_cookie = cookie;
> + int i;
> +
> rx_desc->buf_phys_addr = phys_addr;
> + i = rx_desc - rxq->descs;
> + rxq->buf_virt_addr[i] = virt_addr;
> }
>
> /* Decrement sent descriptors counter */
> @@ -1781,7 +1788,8 @@ EXPORT_SYMBOL_GPL(mvneta_frag_free);
>
> /* Refill processing for SW buffer management */
> static int mvneta_rx_refill(struct mvneta_port *pp,
> - struct mvneta_rx_desc *rx_desc)
> + struct mvneta_rx_desc *rx_desc,
> + struct mvneta_rx_queue *rxq)
>
> {
> dma_addr_t phys_addr;
> @@ -1799,7 +1807,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
> return -ENOMEM;
> }
>
> - mvneta_rx_desc_fill(rx_desc, phys_addr, (u32)data);
> + mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
> return 0;
> }
>
> @@ -1861,7 +1869,7 @@ static void mvneta_rxq_drop_pkts(struct mvneta_port *pp,
>
> for (i = 0; i < rxq->size; i++) {
> struct mvneta_rx_desc *rx_desc = rxq->descs + i;
> - void *data = (void *)rx_desc->buf_cookie;
> + void *data = rxq->buf_virt_addr[i];
>
> dma_unmap_single(pp->dev->dev.parent, rx_desc->buf_phys_addr,
> MVNETA_RX_BUF_SIZE(pp->pkt_size), DMA_FROM_DEVICE);
> @@ -1894,12 +1902,13 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
> unsigned char *data;
> dma_addr_t phys_addr;
> u32 rx_status, frag_size;
> - int rx_bytes, err;
> + int rx_bytes, err, index;
>
> rx_done++;
> rx_status = rx_desc->status;
> rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
> - data = (unsigned char *)rx_desc->buf_cookie;
> + index = rx_desc - rxq->descs;
> + data = rxq->buf_virt_addr[index];
> phys_addr = rx_desc->buf_phys_addr;
>
> if (!mvneta_rxq_desc_is_first_last(rx_status) ||
> @@ -1938,7 +1947,7 @@ static int mvneta_rx_swbm(struct mvneta_port *pp, int rx_todo,
> }
>
> /* Refill processing */
> - err = mvneta_rx_refill(pp, rx_desc);
> + err = mvneta_rx_refill(pp, rx_desc, rxq);
> if (err) {
> netdev_err(dev, "Linux processing - Can't refill\n");
> rxq->missed++;
> @@ -2020,7 +2029,7 @@ static int mvneta_rx_hwbm(struct mvneta_port *pp, int rx_todo,
> rx_done++;
> rx_status = rx_desc->status;
> rx_bytes = rx_desc->data_size - (ETH_FCS_LEN + MVNETA_MH_SIZE);
> - data = (unsigned char *)rx_desc->buf_cookie;
> + data = (u8 *)(uintptr_t)rx_desc->buf_cookie;
> phys_addr = rx_desc->buf_phys_addr;
> pool_id = MVNETA_RX_GET_BM_POOL_ID(rx_desc);
> bm_pool = &pp->bm_priv->bm_pools[pool_id];
> @@ -2716,7 +2725,7 @@ static int mvneta_rxq_fill(struct mvneta_port *pp, struct mvneta_rx_queue *rxq,
>
> for (i = 0; i < num; i++) {
> memset(rxq->descs + i, 0, sizeof(struct mvneta_rx_desc));
> - if (mvneta_rx_refill(pp, rxq->descs + i) != 0) {
> + if (mvneta_rx_refill(pp, rxq->descs + i, rxq) != 0) {
> netdev_err(pp->dev, "%s:rxq %d, %d of %d buffs filled\n",
> __func__, rxq->id, i, num);
> break;
> @@ -3865,6 +3874,11 @@ static int mvneta_init(struct device *dev, struct mvneta_port *pp)
> rxq->size = pp->rx_ring_size;
> rxq->pkts_coal = MVNETA_RX_COAL_PKTS;
> rxq->time_coal = MVNETA_RX_COAL_USEC;
> + rxq->buf_virt_addr = devm_kmalloc(pp->dev->dev.parent,
> + rxq->size * sizeof(void *),
> + GFP_KERNEL);
> + if (!rxq->buf_virt_addr)
> + return -ENOMEM;
> }
>
> return 0;
^ permalink raw reply
* [PATCH v2] KVM: arm/arm64: Access CNTHCTL_EL2 bit fields correctly
From: Jintack Lim @ 2016-12-01 11:38 UTC (permalink / raw)
To: linux-arm-kernel
Current KVM world switch code is unintentionally setting wrong bits to
CNTHCTL_EL2 when E2H == 1, which may allow guest OS to access physical
timer. Bit positions of CNTHCTL_EL2 are changing depending on
HCR_EL2.E2H bit. EL1PCEN and EL1PCTEN are 1st and 0th bits when E2H is
not set, but they are 11th and 10th bits respectively when E2H is set.
In fact, on VHE we only need to set those bits once, not for every world
switch. This is because the host kernel runs in EL2 with HCR_EL2.TGE ==
1, which makes those bits have no effect for the host kernel execution.
So we just set those bits once for guests, and that's it.
Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
---
v2: Skip configuring cnthctl_el2 in world switch path on VHE system.
This patch is based on linux-next.
---
arch/arm/kvm/arm.c | 1 +
include/kvm/arm_arch_timer.h | 1 +
virt/kvm/arm/arch_timer.c | 23 ++++++++++++++++++++++
virt/kvm/arm/hyp/timer-sr.c | 45 ++++++++++++++++++++++++++++++++------------
4 files changed, 58 insertions(+), 12 deletions(-)
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 8f92efa..38c0645 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -1286,6 +1286,7 @@ static void teardown_hyp_mode(void)
static int init_vhe_mode(void)
{
+ on_each_cpu(kvm_timer_init_vhe, NULL, 1);
kvm_info("VHE mode initialized successfully\n");
return 0;
}
diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
index dda39d8..5853399 100644
--- a/include/kvm/arm_arch_timer.h
+++ b/include/kvm/arm_arch_timer.h
@@ -76,4 +76,5 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
void kvm_timer_vcpu_put(struct kvm_vcpu *vcpu);
+void kvm_timer_init_vhe(void *dummy);
#endif
diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
index 17b8fa5..7a0d85d7 100644
--- a/virt/kvm/arm/arch_timer.c
+++ b/virt/kvm/arm/arch_timer.c
@@ -24,6 +24,7 @@
#include <clocksource/arm_arch_timer.h>
#include <asm/arch_timer.h>
+#include <asm/kvm_hyp.h>
#include <kvm/arm_vgic.h>
#include <kvm/arm_arch_timer.h>
@@ -507,3 +508,25 @@ void kvm_timer_init(struct kvm *kvm)
{
kvm->arch.timer.cntvoff = kvm_phys_timer_read();
}
+
+/*
+ * On VHE system, we only need to configure trap on physical timer and counter
+ * accesses in EL0 and EL1 once, not for every world switch.
+ * The host kernel runs at EL2 with HCR_EL2.TGE == 1,
+ * and this makes those bits have no effect for the host kernel execution.
+ */
+void kvm_timer_init_vhe(void *dummy)
+{
+ /* When HCR_EL2.E2H ==1, EL1PCEN and EL1PCTEN are shifted by 10 */
+ u32 cnthctl_shift = 10;
+ u64 val;
+
+ /*
+ * Disallow physical timer access for the guest.
+ * Physical counter access is allowed.
+ */
+ val = read_sysreg(cnthctl_el2);
+ val &= ~(CNTHCTL_EL1PCEN << cnthctl_shift);
+ val |= (CNTHCTL_EL1PCTEN << cnthctl_shift);
+ write_sysreg(val, cnthctl_el2);
+}
diff --git a/virt/kvm/arm/hyp/timer-sr.c b/virt/kvm/arm/hyp/timer-sr.c
index 798866a..f7fc957 100644
--- a/virt/kvm/arm/hyp/timer-sr.c
+++ b/virt/kvm/arm/hyp/timer-sr.c
@@ -21,6 +21,18 @@
#include <asm/kvm_hyp.h>
+#ifdef CONFIG_ARM64
+static inline bool has_vhe(void)
+{
+ if (cpus_have_const_cap(ARM64_HAS_VIRT_HOST_EXTN))
+ return true;
+
+ return false;
+}
+#else
+#define has_vhe() false
+#endif
+
/* vcpu is already in the HYP VA space */
void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
{
@@ -35,10 +47,16 @@ void __hyp_text __timer_save_state(struct kvm_vcpu *vcpu)
/* Disable the virtual timer */
write_sysreg_el0(0, cntv_ctl);
- /* Allow physical timer/counter access for the host */
- val = read_sysreg(cnthctl_el2);
- val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
- write_sysreg(val, cnthctl_el2);
+ /*
+ * We don't need to do this for VHE since the host kernel runs in EL2
+ * with HCR_EL2.TGE ==1, which makes those bits have no impact.
+ */
+ if (!has_vhe()) {
+ /* Allow physical timer/counter access for the host */
+ val = read_sysreg(cnthctl_el2);
+ val |= CNTHCTL_EL1PCTEN | CNTHCTL_EL1PCEN;
+ write_sysreg(val, cnthctl_el2);
+ }
/* Clear cntvoff for the host */
write_sysreg(0, cntvoff_el2);
@@ -50,14 +68,17 @@ void __hyp_text __timer_restore_state(struct kvm_vcpu *vcpu)
struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu;
u64 val;
- /*
- * Disallow physical timer access for the guest
- * Physical counter access is allowed
- */
- val = read_sysreg(cnthctl_el2);
- val &= ~CNTHCTL_EL1PCEN;
- val |= CNTHCTL_EL1PCTEN;
- write_sysreg(val, cnthctl_el2);
+ /* Those bits are already configured at boot on VHE-system */
+ if (!has_vhe()) {
+ /*
+ * Disallow physical timer access for the guest
+ * Physical counter access is allowed
+ */
+ val = read_sysreg(cnthctl_el2);
+ val &= ~CNTHCTL_EL1PCEN;
+ val |= CNTHCTL_EL1PCTEN;
+ write_sysreg(val, cnthctl_el2);
+ }
if (timer->enabled) {
write_sysreg(kvm->arch.timer.cntvoff, cntvoff_el2);
--
1.9.1
^ permalink raw reply related
* [PATCH v14] acpi, apei, arm64: APEI initial support for aarch64.
From: Borislav Petkov @ 2016-12-01 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1470834168-1780-1-git-send-email-fu.wei@linaro.org>
On Wed, Aug 10, 2016 at 09:02:48PM +0800, fu.wei at linaro.org wrote:
> From: Tomasz Nowicki <tomasz.nowicki@linaro.org>
>
> This patch provides APEI arch-specific bits for aarch64
>
> Meanwhile,
> (1)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
> a generic place.
> (2)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
> because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
...
> @@ -110,8 +111,27 @@ static inline const char *acpi_get_enable_method(int cpu)
> }
>
> #ifdef CONFIG_ACPI_APEI
> +/*
> + * acpi_disable_cmcff is used in drivers/acpi/apei/hest.c for disabling
> + * IA-32 Architecture Corrected Machine Check (CMC) Firmware-First mode by
> + * boot parameter(acpi=nocmcff). But we don't have this IA-32 specific
Make that
"... with a kernel command line parameter "acpi=nocmcoff"."
Please fix that up when applying.
With that:
Reviewed-by: Borislav Petkov <bp@suse.de>
Thanks!
--
Regards/Gruss,
Boris.
SUSE Linux GmbH, GF: Felix Imend?rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N?rnberg)
--
^ permalink raw reply
* [PATCH v5 net-next 4/7] net: mvneta: Convert to be 64 bits compatible
From: Jisheng Zhang @ 2016-12-01 11:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201192604.07ed9516@xhacker>
On Thu, 1 Dec 2016 19:26:04 +0800
Jisheng Zhang <jszhang@marvell.com> wrote:
> Hi Gregory, Marcin,
>
> On Wed, 30 Nov 2016 22:42:49 +0100 Gregory CLEMENT wrote:
>
> > From: Marcin Wojtas <mw@semihalf.com>
> >
> > Prepare the mvneta driver in order to be usable on the 64 bits platform
> > such as the Armada 3700.
> >
> > [gregory.clement at free-electrons.com]: this patch was extract from a larger
> > one to ease review and maintenance.
> >
> > Signed-off-by: Marcin Wojtas <mw@semihalf.com>
> > Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> > ---
> > drivers/net/ethernet/marvell/mvneta.c | 17 ++++++++++++++++-
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> > index 92b9af14c352..8ef03fb69bcd 100644
> > --- a/drivers/net/ethernet/marvell/mvneta.c
> > +++ b/drivers/net/ethernet/marvell/mvneta.c
> > @@ -296,6 +296,12 @@
> > /* descriptor aligned size */
> > #define MVNETA_DESC_ALIGNED_SIZE 32
> >
> > +/* Number of bytes to be taken into account by HW when putting incoming data
> > + * to the buffers. It is needed in case NET_SKB_PAD exceeds maximum packet
> > + * offset supported in MVNETA_RXQ_CONFIG_REG(q) registers.
>
> We also brought up this driver on 64bit platforms, we doesn't have this
> patch. Maybe I'm wrong, I'm trying to understand why we need this
> modification. Let's assume the NET_SKB_PAD is 64B, we call
> mvneta_rxq_offset_set(pp, rxq, 64),
>
> {
> u32 val;
>
> val = mvreg_read(pp, MVNETA_RXQ_CONFIG_REG(rxq->id));
> val &= ~MVNETA_RXQ_PKT_OFFSET_ALL_MASK;
>
> /* Offset is in */
> val |= MVNETA_RXQ_PKT_OFFSET_MASK(offset >> 3);
> // then this will be "val |= 8;" it doesn't exceeds the max offset of
sorry, this will be "val |= MVNETA_RXQ_PKT_OFFSET_MASK(8);"
> MVNETA_RXQ_CONFIG_REG(q) register.
>
> Could you please kindly point out where I am wrong?
>
> > + */
> > +#define MVNETA_RX_PKT_OFFSET_CORRECTION 64
> > +
> > #define MVNETA_RX_PKT_SIZE(mtu) \
> > ALIGN((mtu) + MVNETA_MH_SIZE + MVNETA_VLAN_TAG_LEN + \
> > ETH_HLEN + ETH_FCS_LEN, \
> > @@ -416,6 +422,7 @@ struct mvneta_port {
> > u64 ethtool_stats[ARRAY_SIZE(mvneta_statistics)];
> >
> > u32 indir[MVNETA_RSS_LU_TABLE_SIZE];
> > + u16 rx_offset_correction;
> > };
> >
> > /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> > @@ -1807,6 +1814,7 @@ static int mvneta_rx_refill(struct mvneta_port *pp,
> > return -ENOMEM;
> > }
> >
> > + phys_addr += pp->rx_offset_correction;
> > mvneta_rx_desc_fill(rx_desc, phys_addr, data, rxq);
> > return 0;
> > }
> > @@ -2782,7 +2790,7 @@ static int mvneta_rxq_init(struct mvneta_port *pp,
> > mvreg_write(pp, MVNETA_RXQ_SIZE_REG(rxq->id), rxq->size);
> >
> > /* Set Offset */
> > - mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD);
> > + mvneta_rxq_offset_set(pp, rxq, NET_SKB_PAD - pp->rx_offset_correction);
> >
> > /* Set coalescing pkts and time */
> > mvneta_rx_pkts_coal_set(pp, rxq, rxq->pkts_coal);
> > @@ -4033,6 +4041,13 @@ static int mvneta_probe(struct platform_device *pdev)
> >
> > pp->rxq_def = rxq_def;
> >
> > + /* Set RX packet offset correction for platforms, whose
> > + * NET_SKB_PAD, exceeds 64B. It should be 64B for 64-bit
> > + * platforms and 0B for 32-bit ones.
>
> Even we need this patch, I'm not sure this last comment is correct or not.
> NET_SKB_PAD is defined as:
>
> #define NET_SKB_PAD max(32, L1_CACHE_BYTES)
>
> we have 64B cacheline 32bit platforms, on this platforms, the NET_SKB_PAD
> should be 64B as well.
>
> Thanks,
> Jisheng
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Laurent Pinchart @ 2016-12-01 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201123009.d2b4d9d389070200c54138ee@free.fr>
On Thursday 01 Dec 2016 12:30:09 Jean-Francois Moine wrote:
> On Thu, 01 Dec 2016 12:41:20 +0200 Laurent Pinchart wrote:
> >>> If a DVI connector instead of a HDMI connector is soldered, how
> >>> should such a device tree be written?
> >>
> >> Use a dvi-connector instead :)
> >
> > The HDMI encoder DT node doesn't (and certainly shouldn't) report what
> > type of connector is mounted on the board. Having a connector node in DT
> > makes the connector type available to the system, allowing the DRM driver
> > to expose the right connector type to userspace (it would be confusing
> > for the user to report DRM_MODE_CONNECTOR_HDMIA for a DVI connector).
>
> The connector type, HDMI or DVI, is known by the EDID.
> The user is not interested by the software indication of the connector
> type: (s)he knows it because (s)he connected him/herself the display
> device.
That's not correct. The connector type reported by DRM to userspace can be
used as a hint to information the user about connectors. Displaying a "Please
connect a monitor to the HDMI connector" is confusing when the system has a
DVI connector.
> And the DRM driver does not do anything from the knowledge of the
> connector type in the DT. Only the EDID may tell if the display device
> may do audio streaming (direct HDMI with audio capability) or not
> (direct HDMI without audio, HDMI to DVI cable, DVI physical connector).
--
Regards,
Laurent Pinchart
^ permalink raw reply
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