* [PATCH v3] arm64/prefetch: fix a -Wtype-limits warning
From: Qian Cai @ 2019-08-06 3:05 UTC (permalink / raw)
To: will, catalin.marinas
Cc: rrichter, Qian Cai, robin.murphy, linux-kernel, linux-arm-kernel
The commit d5370f754875 ("arm64: prefetch: add alternative pattern for
CPUs without a prefetcher") introduced MIDR_IS_CPU_MODEL_RANGE() to be
used in has_no_hw_prefetch() with rv_min=0 which generates a compilation
warning from GCC,
In file included from ./arch/arm64/include/asm/cache.h:8,
from ./include/linux/cache.h:6,
from ./include/linux/printk.h:9,
from ./include/linux/kernel.h:15,
from ./include/linux/cpumask.h:10,
from arch/arm64/kernel/cpufeature.c:11:
arch/arm64/kernel/cpufeature.c: In function 'has_no_hw_prefetch':
./arch/arm64/include/asm/cputype.h:59:26: warning: comparison of
unsigned expression >= 0 is always true [-Wtype-limits]
_model == (model) && rv >= (rv_min) && rv <= (rv_max); \
^~
arch/arm64/kernel/cpufeature.c:889:9: note: in expansion of macro
'MIDR_IS_CPU_MODEL_RANGE'
return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
^~~~~~~~~~~~~~~~~~~~~~~
Fix it by converting MIDR_IS_CPU_MODEL_RANGE to a static inline
function.
Signed-off-by: Qian Cai <cai@lca.pw>
---
v3: Convert MIDR_IS_CPU_MODEL_RANGE to a static inline function.
v2: Use "s32" for "rv", so "variant 0/revision 0" can be covered.
arch/arm64/include/asm/cputype.h | 21 +++++++++++----------
arch/arm64/kernel/cpufeature.c | 2 +-
2 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index e7d46631cc42..b1454d117cd2 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -51,14 +51,6 @@
#define MIDR_CPU_MODEL_MASK (MIDR_IMPLEMENTOR_MASK | MIDR_PARTNUM_MASK | \
MIDR_ARCHITECTURE_MASK)
-#define MIDR_IS_CPU_MODEL_RANGE(midr, model, rv_min, rv_max) \
-({ \
- u32 _model = (midr) & MIDR_CPU_MODEL_MASK; \
- u32 rv = (midr) & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK); \
- \
- _model == (model) && rv >= (rv_min) && rv <= (rv_max); \
- })
-
#define ARM_CPU_IMP_ARM 0x41
#define ARM_CPU_IMP_APM 0x50
#define ARM_CPU_IMP_CAVIUM 0x43
@@ -159,10 +151,19 @@ struct midr_range {
#define MIDR_REV(m, v, r) MIDR_RANGE(m, v, r, v, r)
#define MIDR_ALL_VERSIONS(m) MIDR_RANGE(m, 0, 0, 0xf, 0xf)
+static inline bool midr_is_cpu_model_range(u32 midr, u32 model, u32 rv_min,
+ u32 rv_max)
+{
+ u32 _model = midr & MIDR_CPU_MODEL_MASK;
+ u32 rv = midr & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK);
+
+ return _model == model && rv >= rv_min && rv <= rv_max;
+}
+
static inline bool is_midr_in_range(u32 midr, struct midr_range const *range)
{
- return MIDR_IS_CPU_MODEL_RANGE(midr, range->model,
- range->rv_min, range->rv_max);
+ return midr_is_cpu_model_range(midr, range->model,
+ range->rv_min, range->rv_max);
}
static inline bool
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index d19d14ba9ae4..95201e5ff5e1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -886,7 +886,7 @@ static bool has_no_hw_prefetch(const struct arm64_cpu_capabilities *entry, int _
u32 midr = read_cpuid_id();
/* Cavium ThunderX pass 1.x and 2.x */
- return MIDR_IS_CPU_MODEL_RANGE(midr, MIDR_THUNDERX,
+ return midr_is_cpu_model_range(midr, MIDR_THUNDERX,
MIDR_CPU_VAR_REV(0, 0),
MIDR_CPU_VAR_REV(1, MIDR_REVISION_MASK));
}
--
2.20.1 (Apple Git-117)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/2] ARM: zynq: smp improvements
From: Luis Araneda @ 2019-08-06 3:07 UTC (permalink / raw)
To: linux, michal.simek; +Cc: Luis Araneda, linux-arm-kernel, stable, linux-kernel
This series adds support for kernel compiled in Thumb mode
and fixes a kernel panic on smp bring-up when FORTIFY_SOURCE
is enabled.
The series started with the second patch as an RFC, and
the first patch were suggested on the review to complement
the fix.
The changes were run-tested on a Digilent Zybo Z7 board
Luis Araneda (2):
ARM: zynq: support smp in thumb mode
ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
arch/arm/mach-zynq/headsmp.S | 2 ++
arch/arm/mach-zynq/platsmp.c | 4 ++--
2 files changed, 4 insertions(+), 2 deletions(-)
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] ARM: zynq: support smp in thumb mode
From: Luis Araneda @ 2019-08-06 3:07 UTC (permalink / raw)
To: linux, michal.simek; +Cc: Luis Araneda, linux-arm-kernel, stable, linux-kernel
In-Reply-To: <20190806030718.29048-1-luaraneda@gmail.com>
Add .arm directive to headsmp.S to ensure that the
CPU starts in 32-bit ARM mode and the correct code
size is copied on smp bring-up
Additionally, start secondary CPUs on secondary_startup_arm
to automatically switch from ARM to thumb on a thumb kernel
Suggested-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
---
arch/arm/mach-zynq/headsmp.S | 2 ++
arch/arm/mach-zynq/platsmp.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynq/headsmp.S b/arch/arm/mach-zynq/headsmp.S
index ab85003cf9ad..3449e0d1f990 100644
--- a/arch/arm/mach-zynq/headsmp.S
+++ b/arch/arm/mach-zynq/headsmp.S
@@ -7,6 +7,8 @@
#include <linux/init.h>
#include <asm/assembler.h>
+ .arm
+
ENTRY(zynq_secondary_trampoline)
ARM_BE8(setend be) @ ensure we are in BE8 mode
ldr r0, zynq_secondary_trampoline_jump
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index a7cfe07156f4..38728badabd4 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -81,7 +81,7 @@ EXPORT_SYMBOL(zynq_cpun_start);
static int zynq_boot_secondary(unsigned int cpu, struct task_struct *idle)
{
- return zynq_cpun_start(__pa_symbol(secondary_startup), cpu);
+ return zynq_cpun_start(__pa_symbol(secondary_startup_arm), cpu);
}
/*
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
From: Luis Araneda @ 2019-08-06 3:07 UTC (permalink / raw)
To: linux, michal.simek; +Cc: Luis Araneda, linux-arm-kernel, stable, linux-kernel
In-Reply-To: <20190806030718.29048-1-luaraneda@gmail.com>
This fixes a kernel panic (read overflow) on memcpy when
FORTIFY_SOURCE is enabled.
The computed size of memcpy args are:
- p_size (dst): 4294967295 = (size_t) -1
- q_size (src): 1
- size (len): 8
Additionally, the memory is marked as __iomem, so one of
the memcpy_* functions should be used for read/write
Signed-off-by: Luis Araneda <luaraneda@gmail.com>
---
arch/arm/mach-zynq/platsmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-zynq/platsmp.c b/arch/arm/mach-zynq/platsmp.c
index 38728badabd4..a10085be9073 100644
--- a/arch/arm/mach-zynq/platsmp.c
+++ b/arch/arm/mach-zynq/platsmp.c
@@ -57,7 +57,7 @@ int zynq_cpun_start(u32 address, int cpu)
* 0x4: Jump by mov instruction
* 0x8: Jumping address
*/
- memcpy((__force void *)zero, &zynq_secondary_trampoline,
+ memcpy_toio(zero, &zynq_secondary_trampoline,
trampoline_size);
writel(address, zero + trampoline_size);
--
2.22.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] pinctrl: spear: spear: Add of_node_put() before return
From: Viresh Kumar @ 2019-08-06 3:42 UTC (permalink / raw)
To: Nishka Dasgupta; +Cc: vireshk, linus.walleij, linux-arm-kernel, linux-gpio
In-Reply-To: <20190804154948.4584-1-nishkadg.linux@gmail.com>
On 04-08-19, 21:19, Nishka Dasgupta wrote:
> Each iteration of for_each_child_of_node puts the previous node, but in
> the case of a return from the middle of the loop, there is no put, thus
> causing a memory leak. Hence add an of_node_put before the return in
> two places.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> ---
> drivers/pinctrl/spear/pinctrl-spear.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/spear/pinctrl-spear.c b/drivers/pinctrl/spear/pinctrl-spear.c
> index c4f850345dc4..7ec19c73f870 100644
> --- a/drivers/pinctrl/spear/pinctrl-spear.c
> +++ b/drivers/pinctrl/spear/pinctrl-spear.c
> @@ -157,12 +157,16 @@ static int spear_pinctrl_dt_node_to_map(struct pinctrl_dev *pctldev,
> /* calculate number of maps required */
> for_each_child_of_node(np_config, np) {
> ret = of_property_read_string(np, "st,function", &function);
> - if (ret < 0)
> + if (ret < 0) {
> + of_node_put(np);
> return ret;
> + }
>
> ret = of_property_count_strings(np, "st,pins");
> - if (ret < 0)
> + if (ret < 0) {
> + of_node_put(np);
> return ret;
> + }
>
> count += ret;
> }
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64/cache: fix -Woverride-init compiler warnings
From: Qian Cai @ 2019-08-06 3:50 UTC (permalink / raw)
To: Will Deacon; +Cc: Mark Rutland, Catalin Marinas, linux-kernel, linux-arm-kernel
In-Reply-To: <20190805140118.fys437oor2b2rnq5@willie-the-truck>
> On Aug 5, 2019, at 10:01 AM, Will Deacon <will@kernel.org> wrote:
>
> On Mon, Aug 05, 2019 at 07:47:37AM -0400, Qian Cai wrote:
>>
>>
>>> On Aug 5, 2019, at 5:52 AM, Will Deacon <will@kernel.org> wrote:
>>>
>>> On Fri, Aug 02, 2019 at 11:32:24AM -0400, Qian Cai wrote:
>>>> The commit 155433cb365e ("arm64: cache: Remove support for ASID-tagged
>>>> VIVT I-caches") introduced some compiation warnings from GCC,
>>>>
>>>> arch/arm64/kernel/cpuinfo.c:38:26: warning: initialized field
>>>> overwritten [-Woverride-init]
>>>> [ICACHE_POLICY_VIPT] = "VIPT",
>>>> ^~~~~~
>>>> arch/arm64/kernel/cpuinfo.c:38:26: note: (near initialization for
>>>> 'icache_policy_str[2]')
>>>> arch/arm64/kernel/cpuinfo.c:39:26: warning: initialized field
>>>> overwritten [-Woverride-init]
>>>> [ICACHE_POLICY_PIPT] = "PIPT",
>>>> ^~~~~~
>>>> arch/arm64/kernel/cpuinfo.c:39:26: note: (near initialization for
>>>> 'icache_policy_str[3]')
>>>> arch/arm64/kernel/cpuinfo.c:40:27: warning: initialized field
>>>> overwritten [-Woverride-init]
>>>> [ICACHE_POLICY_VPIPT] = "VPIPT",
>>>> ^~~~~~~
>>>> arch/arm64/kernel/cpuinfo.c:40:27: note: (near initialization for
>>>> 'icache_policy_str[0]')
>>>>
>>>> because it initializes icache_policy_str[0 ... 3] twice.
>>>>
>>>> Fixes: 155433cb365e ("arm64: cache: Remove support for ASID-tagged VIVT I-caches")
>>>> Signed-off-by: Qian Cai <cai@lca.pw>
>>>> ---
>>>> arch/arm64/kernel/cpuinfo.c | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
>>>> index 876055e37352..193b38da8d96 100644
>>>> --- a/arch/arm64/kernel/cpuinfo.c
>>>> +++ b/arch/arm64/kernel/cpuinfo.c
>>>> @@ -34,10 +34,10 @@
>>>> static struct cpuinfo_arm64 boot_cpu_data;
>>>>
>>>> static char *icache_policy_str[] = {
>>>> - [0 ... ICACHE_POLICY_PIPT] = "RESERVED/UNKNOWN",
>>>> + [ICACHE_POLICY_VPIPT] = "VPIPT",
>>>> + [ICACHE_POLICY_VPIPT + 1] = "RESERVED/UNKNOWN",
>>>> [ICACHE_POLICY_VIPT] = "VIPT",
>>>> [ICACHE_POLICY_PIPT] = "PIPT",
>>>> - [ICACHE_POLICY_VPIPT] = "VPIPT",
>>>
>>> I really don't like this patch. Using "[0 ... MAXIDX] = <default>" is a
>>> useful idiom and I think the code is more error-prone the way you have
>>> restructured it.
>>>
>>> Why are you passing -Woverride-init to the compiler anyway? There's only
>>> one Makefile that references that option, and it's specific to a pinctrl
>>> driver.
>>
>> Those extra warnings can be enabled by “make W=1”. “-Woverride-init “ seems to be useful
>> to catch potential developer mistakes with unintented double-initializations. It is normal to
>> start to fix the most of false-positives first before globally enabling the flag by default just like
>> “-Wimplicit-fallthrough” mentioned in,
>>
>> https://lwn.net/Articles/794944/
>
> I think this case is completely different to the implicit fallthrough stuff.
> The solution there was simply to add a comment without restructuring the
> surrounding code. What your patch does here is actively make the code harder
> to understand.
>
> Initialising a static array with a non-zero pattern is a useful idiom and I
> don't think we should throw that away just to appease a silly compiler
> warning that appears only with non-default build options. Have a look at
> the way we use PERF_MAP_ALL_UNSUPPORTED in the Arm PMU code, for example.
Well, both GCC and Clang would generate warnings for those. Clang even enable this by
default,
https://releases.llvm.org/8.0.0/tools/clang/docs/DiagnosticsReference.html#winitializer-overrides
Assume compiler people are sane, I probably not call those are “silly”.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next 03/10] net: stmmac: Fix issues when number of Queues >= 4
From: Jakub Kicinski @ 2019-08-06 4:34 UTC (permalink / raw)
To: Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev, linux-kernel, linux-stm32,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <5e95bb1761f9438361f198d744640685a34790ea.1565027782.git.joabreu@synopsys.com>
On Mon, 5 Aug 2019 20:01:16 +0200, Jose Abreu wrote:
> When queues >= 4 we use different registers but we were not subtracting
> the offset of 4. Fix this.
>
> Found out by Coverity.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Should this be a bug fix for the net tree?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCHv2 3/3] PCI: layerscape: Add LS1028a support
From: Z.q. Hou @ 2019-08-06 4:39 UTC (permalink / raw)
To: Xiaowei Bao, bhelgaas@google.com, robh+dt@kernel.org,
mark.rutland@arm.com, shawnguo@kernel.org, Leo Li, kishon@ti.com,
lorenzo.pieralisi@arm.com, arnd@arndb.de,
gregkh@linuxfoundation.org, M.h. Lian, Mingkai Hu, Roy Zang,
kstewart@linuxfoundation.org, pombredanne@nexb.com,
shawn.lin@rock-chips.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linuxppc-dev@lists.ozlabs.org
Cc: Xiaowei Bao
In-Reply-To: <20190805040453.48009-3-xiaowei.bao@nxp.com>
Hi Xiaowei,
> -----Original Message-----
> From: Xiaowei Bao [mailto:xiaowei.bao@nxp.com]
> Sent: 2019年8月5日 12:05
> To: bhelgaas@google.com; robh+dt@kernel.org; mark.rutland@arm.com;
> shawnguo@kernel.org; Leo Li <leoyang.li@nxp.com>; kishon@ti.com;
> lorenzo.pieralisi@arm.com; arnd@arndb.de; gregkh@linuxfoundation.org;
> M.h. Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>;
> Z.q. Hou <zhiqiang.hou@nxp.com>; Roy Zang <roy.zang@nxp.com>;
> kstewart@linuxfoundation.org; pombredanne@nexb.com;
> shawn.lin@rock-chips.com; linux-pci@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org
> Cc: Xiaowei Bao <xiaowei.bao@nxp.com>
> Subject: [PATCHv2 3/3] PCI: layerscape: Add LS1028a support
>
> Add support for the LS1028a PCIe controller.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> v2:
> - no change.
>
> drivers/pci/controller/dwc/pci-layerscape.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c
> b/drivers/pci/controller/dwc/pci-layerscape.c
> index 3a5fa26..8c556e1 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -236,6 +236,14 @@ static const struct ls_pcie_drvdata ls1043_drvdata =
> {
> .dw_pcie_ops = &dw_ls_pcie_ops,
> };
>
> +static const struct ls_pcie_drvdata ls1028a_drvdata = {
> + .lut_offset = 0x80000,
> + .ltssm_shift = 0,
> + .lut_dbg = 0x407fc,
> + .ops = &ls_pcie_host_ops,
> + .dw_pcie_ops = &dw_ls_pcie_ops,
> +};
> +
Reuse the driver data structure of LS2088 instead add a new one.
- Zhiqiang
> static const struct ls_pcie_drvdata ls1046_drvdata = {
> .lut_offset = 0x80000,
> .ltssm_shift = 24,
> @@ -263,6 +271,7 @@ static const struct ls_pcie_drvdata ls2088_drvdata =
> { static const struct of_device_id ls_pcie_of_match[] = {
> { .compatible = "fsl,ls1012a-pcie", .data = &ls1046_drvdata },
> { .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
> + { .compatible = "fsl,ls1028a-pcie", .data = &ls1028a_drvdata },
> { .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
> { .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
> { .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
> --
> 2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next 06/10] net: stmmac: Implement RSS and enable it in XGMAC core
From: Jakub Kicinski @ 2019-08-06 4:46 UTC (permalink / raw)
To: Jose Abreu
Cc: Joao Pinto, Alexandre Torgue, netdev, linux-kernel, linux-stm32,
Maxime Coquelin, Giuseppe Cavallaro, David S. Miller,
linux-arm-kernel
In-Reply-To: <e70981c111ac857a0bac77750bd69a3383d99ee0.1565027782.git.joabreu@synopsys.com>
On Mon, 5 Aug 2019 20:01:19 +0200, Jose Abreu wrote:
> Implement the RSS functionality and add the corresponding callbacks in
> XGMAC core.
>
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> ---
> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> Cc: Alexandre Torgue <alexandre.torgue@st.com>
> Cc: Jose Abreu <joabreu@synopsys.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> index c4c45402b8f8..9ff9d9ac1a50 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_descs.c
> @@ -254,6 +254,34 @@ static void dwxgmac2_clear(struct dma_desc *p)
> p->des3 = 0;
> }
>
> +static int dwxgmac2_get_rx_hash(struct dma_desc *p, u32 *hash,
> + enum pkt_hash_types *type)
> +{
> + unsigned int rdes3 = le32_to_cpu(p->des3);
> + u32 ptype;
> +
> + if (rdes3 & XGMAC_RDES3_RSV) {
> + ptype = (rdes3 & XGMAC_RDES3_L34T) >> XGMAC_RDES3_L34T_SHIFT;
> +
> + switch (ptype) {
> + case 0x1:
> + case 0x2:
> + case 0x9:
> + case 0xA:
nit: it'd be nice to have defines for these constants
> + *type = PKT_HASH_TYPE_L4;
> + break;
> + default:
> + *type = PKT_HASH_TYPE_L3;
> + break;
> + }
> +
> + *hash = le32_to_cpu(p->des1);
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> const struct stmmac_desc_ops dwxgmac210_desc_ops = {
> .tx_status = dwxgmac2_get_tx_status,
> .rx_status = dwxgmac2_get_rx_status,
> @@ -4182,7 +4208,7 @@ int stmmac_dvr_probe(struct device *device,
> struct net_device *ndev = NULL;
> struct stmmac_priv *priv;
> u32 queue, maxq;
> - int ret = 0;
> + int i, ret = 0;
>
> ndev = devm_alloc_etherdev_mqs(device, sizeof(struct stmmac_priv),
> MTL_MAX_TX_QUEUES, MTL_MAX_RX_QUEUES);
> @@ -4290,6 +4316,14 @@ int stmmac_dvr_probe(struct device *device,
> #endif
> priv->msg_enable = netif_msg_init(debug, default_msg_level);
>
> + /* Initialize RSS */
> + netdev_rss_key_fill(priv->rss.key, sizeof(priv->rss.key));
> + for (i = 0; i < ARRAY_SIZE(priv->rss.table); i++)
> + priv->rss.table[i] = i % priv->plat->rx_queues_to_use;
ethtool_rxfh_indir_default() ?
> + if (priv->dma_cap.rssen && priv->plat->rss_en)
> + ndev->features |= NETIF_F_RXHASH;
> +
> /* MTU range: 46 - hw-specific max */
> ndev->min_mtu = ETH_ZLEN - ETH_HLEN;
> if ((priv->plat->enh_desc) || (priv->synopsys_id >= DWMAC_CORE_4_00))
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dma-mapping: fix page attributes for dma_mmap_*
From: Christoph Hellwig @ 2019-08-06 5:12 UTC (permalink / raw)
To: Gavin Li
Cc: Gavin Li, Shawn Anastasio, Michael Ellerman, linuxppc-dev,
linux-kernel, Russell King, linux-mips, Paul Burton,
Catalin Marinas, James Hogan, Will Deacon, Christoph Hellwig,
linux-arm-kernel, Robin Murphy
In-Reply-To: <CA+GxvY5C_rrukCzC5K-h72bePyW8PS_Rfj3uxh-K6UrcAextUQ@mail.gmail.com>
On Mon, Aug 05, 2019 at 07:55:44PM -0700, Gavin Li wrote:
> > /* create a coherent mapping */
> > ret = dma_common_contiguous_remap(page, size, VM_USERMAP,
> > - arch_dma_mmap_pgprot(dev, PAGE_KERNEL, attrs),
> > + dma_pgprot(dev, PAGE_KERNEL, attrs),
> > __builtin_return_address(0));
> > if (!ret) {
> > __dma_direct_free_pages(dev, size, page);
>
> Is dma_common_contiguous_remap() still necessary in the
> DMA_ATTR_NON_CONSISTENT case? I would presume it would be fine to just
> return a linearly mapped address in that case.
It would not be required for a real DMA_ATTR_NON_CONSISTENT
implementation. But only parisc and mips actually properly implement
DMA_ATTR_NON_CONSISTENT, everyone ignores it. Given that the API is
a little ill defined and I have a better replacement in the pipeline
I don't want to start implementing it for other architectures now.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 0/2] ARM: zynq: smp improvements
From: Greg KH @ 2019-08-06 5:17 UTC (permalink / raw)
To: Luis Araneda; +Cc: linux-arm-kernel, linux-kernel, linux, stable, michal.simek
In-Reply-To: <20190806030718.29048-1-luaraneda@gmail.com>
On Mon, Aug 05, 2019 at 11:07:16PM -0400, Luis Araneda wrote:
> This series adds support for kernel compiled in Thumb mode
> and fixes a kernel panic on smp bring-up when FORTIFY_SOURCE
> is enabled.
>
> The series started with the second patch as an RFC, and
> the first patch were suggested on the review to complement
> the fix.
>
> The changes were run-tested on a Digilent Zybo Z7 board
>
> Luis Araneda (2):
> ARM: zynq: support smp in thumb mode
> ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
>
> arch/arm/mach-zynq/headsmp.S | 2 ++
> arch/arm/mach-zynq/platsmp.c | 4 ++--
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> --
> 2.22.0
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
From: Greg KH @ 2019-08-06 5:17 UTC (permalink / raw)
To: Luis Araneda; +Cc: linux-arm-kernel, linux-kernel, linux, stable, michal.simek
In-Reply-To: <20190806030718.29048-3-luaraneda@gmail.com>
On Mon, Aug 05, 2019 at 11:07:18PM -0400, Luis Araneda wrote:
> This fixes a kernel panic (read overflow) on memcpy when
> FORTIFY_SOURCE is enabled.
>
> The computed size of memcpy args are:
> - p_size (dst): 4294967295 = (size_t) -1
> - q_size (src): 1
> - size (len): 8
>
> Additionally, the memory is marked as __iomem, so one of
> the memcpy_* functions should be used for read/write
>
> Signed-off-by: Luis Araneda <luaraneda@gmail.com>
> ---
> arch/arm/mach-zynq/platsmp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] ARM: zynq: support smp in thumb mode
From: Greg KH @ 2019-08-06 5:17 UTC (permalink / raw)
To: Luis Araneda; +Cc: linux-arm-kernel, linux-kernel, linux, stable, michal.simek
In-Reply-To: <20190806030718.29048-2-luaraneda@gmail.com>
On Mon, Aug 05, 2019 at 11:07:17PM -0400, Luis Araneda wrote:
> Add .arm directive to headsmp.S to ensure that the
> CPU starts in 32-bit ARM mode and the correct code
> size is copied on smp bring-up
>
> Additionally, start secondary CPUs on secondary_startup_arm
> to automatically switch from ARM to thumb on a thumb kernel
>
> Suggested-by: Michal Simek <michal.simek@xilinx.com>
> Signed-off-by: Luis Araneda <luaraneda@gmail.com>
> ---
> arch/arm/mach-zynq/headsmp.S | 2 ++
> arch/arm/mach-zynq/platsmp.c | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/7] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*
From: Christoph Hellwig @ 2019-08-06 5:29 UTC (permalink / raw)
To: Takashi Iwai
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, linuxppc-dev,
x86, linux-m68k, linux-kernel, iommu, Robin Murphy,
Christoph Hellwig, linux-arm-kernel, Marek Szyprowski
In-Reply-To: <s5hzhkonf0k.wl-tiwai@suse.de>
On Mon, Aug 05, 2019 at 11:22:03AM +0200, Takashi Iwai wrote:
> This won't work as expected, unfortunately. It's a bit tricky check,
> since the driver may have its own mmap implementation via
> substream->ops->mmap, and the dma_buffer.dev.dev might point to
> another object depending on the dma_buffer.dev.type.
>
> So please replace with something like below:
From my gut feeling I'd reorder it a bit to make it more clear like
this:
http://git.infradead.org/users/hch/misc.git/commitdiff/958fccf54d00c16740522f818d23f9350498e911
if this is fine it'll be in the next version, waiting for a little more
feedback on the other patches.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] arm64: dts: ls1028a: Add temperature sensor node
From: Yuantian Tang @ 2019-08-06 5:30 UTC (permalink / raw)
To: shawnguo
Cc: mark.rutland, devicetree, Yuantian Tang, linux-kernel, leoyang.li,
robh+dt, linux-arm-kernel
Add nxp sa56004 chip node for temperature monitor.
Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
---
v3:
- sort the node in i2c address
v2:
- change the node name and add vcc-supply
arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 15 +++++++++++++++
arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 15 +++++++++++++++
2 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
index b359068..960daf2 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
@@ -47,6 +47,15 @@
regulator-always-on;
};
+ sb_3v3: regulator-sb3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_vbus";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,format = "i2s";
@@ -117,6 +126,12 @@
#size-cells = <0>;
reg = <0x3>;
+ temperature-sensor@4c {
+ compatible = "nxp,sa56004";
+ reg = <0x4c>;
+ vcc-supply = <&sb_3v3>;
+ };
+
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
index f9c272f..6a22423 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
@@ -43,6 +43,15 @@
regulator-always-on;
};
+ sb_3v3: regulator-sb3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_vbus";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
sound {
compatible = "simple-audio-card";
simple-audio-card,format = "i2s";
@@ -115,6 +124,12 @@
#size-cells = <0>;
reg = <0x3>;
+ temperature-sensor@4c {
+ compatible = "nxp,sa56004";
+ reg = <0x4c>;
+ vcc-supply = <&sb_3v3>;
+ };
+
rtc@51 {
compatible = "nxp,pcf2129";
reg = <0x51>;
--
1.7.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH v3] arm64: dts: ls1028a: Add temperature sensor node
From: Andy Tang @ 2019-08-06 5:41 UTC (permalink / raw)
To: Andy Tang, shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Leo Li, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190806053004.36956-1-andy.tang@nxp.com>
Please ignore this email. Sorry for sending the wrong patch.
BR,
Andy
> -----Original Message-----
> From: Yuantian Tang <andy.tang@nxp.com>
> Sent: 2019年8月6日 13:30
> To: shawnguo@kernel.org
> Cc: Leo Li <leoyang.li@nxp.com>; robh+dt@kernel.org;
> mark.rutland@arm.com; linux-arm-kernel@lists.infradead.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; Andy Tang
> <andy.tang@nxp.com>
> Subject: [PATCH v3] arm64: dts: ls1028a: Add temperature sensor node
>
> Add nxp sa56004 chip node for temperature monitor.
>
> Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
> ---
> v3:
> - sort the node in i2c address
> v2:
> - change the node name and add vcc-supply
> arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts | 15
> +++++++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts | 15
> +++++++++++++++
> 2 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> index b359068..960daf2 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-qds.dts
> @@ -47,6 +47,15 @@
> regulator-always-on;
> };
>
> + sb_3v3: regulator-sb3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3v3_vbus";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,format = "i2s";
> @@ -117,6 +126,12 @@
> #size-cells = <0>;
> reg = <0x3>;
>
> + temperature-sensor@4c {
> + compatible = "nxp,sa56004";
> + reg = <0x4c>;
> + vcc-supply = <&sb_3v3>;
> + };
> +
> rtc@51 {
> compatible = "nxp,pcf2129";
> reg = <0x51>;
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> index f9c272f..6a22423 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-rdb.dts
> @@ -43,6 +43,15 @@
> regulator-always-on;
> };
>
> + sb_3v3: regulator-sb3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3v3_vbus";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,format = "i2s";
> @@ -115,6 +124,12 @@
> #size-cells = <0>;
> reg = <0x3>;
>
> + temperature-sensor@4c {
> + compatible = "nxp,sa56004";
> + reg = <0x4c>;
> + vcc-supply = <&sb_3v3>;
> + };
> +
> rtc@51 {
> compatible = "nxp,pcf2129";
> reg = <0x51>;
> --
> 1.7.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V4 1/4] dt-bindings: arm: imx: Add the soc binding for i.MX8MN
From: Anson Huang @ 2019-08-06 5:42 UTC (permalink / raw)
To: robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
andrew.smirnov@gmail.com, manivannan.sadhasivam@linaro.org,
j.neuschaefer@gmx.net, u.kleine-koenig@pengutronix.de, Leo Li,
Aisheng Dong, l.stach@pengutronix.de, Vabhav Sharma,
Bhaskar Upadhaya, Jacky Bai, Pramod Kumar, Leonard Crestez,
Daniel Baluta, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: dl-linux-imx
In-Reply-To: <20190619022145.42398-1-Anson.Huang@nxp.com>
Ping for this patch series...
> From: Anson Huang <Anson.Huang@nxp.com>
>
> This patch adds the soc & board binding for i.MX8MN.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> No change.
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml
> b/Documentation/devicetree/bindings/arm/fsl.yaml
> index 407138e..b35abb1 100644
> --- a/Documentation/devicetree/bindings/arm/fsl.yaml
> +++ b/Documentation/devicetree/bindings/arm/fsl.yaml
> @@ -177,6 +177,12 @@ properties:
> - fsl,imx8mm-evk # i.MX8MM EVK Board
> - const: fsl,imx8mm
>
> + - description: i.MX8MN based Boards
> + items:
> + - enum:
> + - fsl,imx8mn-ddr4-evk # i.MX8MN DDR4 EVK Board
> + - const: fsl,imx8mn
> +
> - description: i.MX8QXP based Boards
> items:
> - enum:
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4] kasan: add memory corruption identification for software tag-based mode
From: Walter Wu @ 2019-08-06 5:43 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger, Andrew Morton, Martin Schwidefsky,
Arnd Bergmann, Thomas Gleixner, Vasily Gorbik, Andrey Konovalov,
Miles Chen, Walter Wu
Cc: wsd_upstream, linux-kernel, kasan-dev, linux-mm, linux-mediatek,
linux-arm-kernel
This patch adds memory corruption identification at bug report for
software tag-based mode, the report show whether it is "use-after-free"
or "out-of-bound" error instead of "invalid-access" error. This will make
it easier for programmers to see the memory corruption problem.
We extend the slab to store five old free pointer tag and free backtrace,
we can check if the tagged address is in the slab record and make a
good guess if the object is more like "use-after-free" or "out-of-bound".
therefore every slab memory corruption can be identified whether it's
"use-after-free" or "out-of-bound".
====== Changes
Change since v1:
- add feature option CONFIG_KASAN_SW_TAGS_IDENTIFY.
- change QUARANTINE_FRACTION to reduce quarantine size.
- change the qlist order in order to find the newest object in quarantine
- reduce the number of calling kmalloc() from 2 to 1 time.
- remove global variable to use argument to pass it.
- correct the amount of qobject cache->size into the byes of qlist_head.
- only use kasan_cache_shrink() to shink memory.
Change since v2:
- remove the shinking memory function kasan_cache_shrink()
- modify the description of the CONFIG_KASAN_SW_TAGS_IDENTIFY
- optimize the quarantine_find_object() and qobject_free()
- fix the duplicating function name 3 times in the header.
- modify the function name set_track() to kasan_set_track()
Change since v3:
- change tag-based quarantine to extend slab to identify memory corruption
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
---
lib/Kconfig.kasan | 8 ++++
mm/kasan/common.c | 14 +++++--
mm/kasan/kasan.h | 37 ++++++++++++++++++
mm/kasan/report.c | 53 +++++++++++++++-----------
mm/kasan/tags.c | 86 ++++++++++++++++++++++++++++++++++++++++++
mm/kasan/tags_report.c | 5 ++-
6 files changed, 177 insertions(+), 26 deletions(-)
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
index 4fafba1a923b..70b55e1c4834 100644
--- a/lib/Kconfig.kasan
+++ b/lib/Kconfig.kasan
@@ -135,6 +135,14 @@ config KASAN_S390_4_LEVEL_PAGING
to 3TB of RAM with KASan enabled). This options allows to force
4-level paging instead.
+config KASAN_SW_TAGS_IDENTIFY
+ bool "Enable memory corruption identification"
+ depends on KASAN_SW_TAGS
+ help
+ This option enables best-effort identification of bug type
+ (use-after-free or out-of-bounds) at the cost of increased
+ memory consumption for slab extending.
+
config TEST_KASAN
tristate "Module for testing KASAN for bug detection"
depends on m && KASAN
diff --git a/mm/kasan/common.c b/mm/kasan/common.c
index 2277b82902d8..6bbb044708e6 100644
--- a/mm/kasan/common.c
+++ b/mm/kasan/common.c
@@ -71,7 +71,7 @@ static inline depot_stack_handle_t save_stack(gfp_t flags)
return stack_depot_save(entries, nr_entries, flags);
}
-static inline void set_track(struct kasan_track *track, gfp_t flags)
+void kasan_set_track(struct kasan_track *track, gfp_t flags)
{
track->pid = current->pid;
track->stack = save_stack(flags);
@@ -304,7 +304,8 @@ size_t kasan_metadata_size(struct kmem_cache *cache)
struct kasan_alloc_meta *get_alloc_info(struct kmem_cache *cache,
const void *object)
{
- BUILD_BUG_ON(sizeof(struct kasan_alloc_meta) > 32);
+ if (!IS_ENABLED(CONFIG_KASAN_SW_TAGS_IDENTIFY))
+ BUILD_BUG_ON(sizeof(struct kasan_alloc_meta) > 32);
return (void *)object + cache->kasan_info.alloc_meta_offset;
}
@@ -446,7 +447,11 @@ static bool __kasan_slab_free(struct kmem_cache *cache, void *object,
unlikely(!(cache->flags & SLAB_KASAN)))
return false;
- set_track(&get_alloc_info(cache, object)->free_track, GFP_NOWAIT);
+ if (IS_ENABLED(CONFIG_KASAN_SW_TAGS_IDENTIFY))
+ kasan_set_free_info(cache, object, tag);
+ else
+ kasan_set_track(&get_alloc_info(cache, object)->free_track,
+ GFP_NOWAIT);
quarantine_put(get_free_info(cache, object), cache);
return IS_ENABLED(CONFIG_KASAN_GENERIC);
@@ -484,7 +489,8 @@ static void *__kasan_kmalloc(struct kmem_cache *cache, const void *object,
KASAN_KMALLOC_REDZONE);
if (cache->flags & SLAB_KASAN)
- set_track(&get_alloc_info(cache, object)->alloc_track, flags);
+ kasan_set_track(&get_alloc_info(cache, object)->alloc_track,
+ flags);
return set_tag(object, tag);
}
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 014f19e76247..531a5823e8c6 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -95,9 +95,23 @@ struct kasan_track {
depot_stack_handle_t stack;
};
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+#define KASAN_EXTRA_FREE_INFO_COUNT 4
+#define KASAN_TOTAL_FREE_INFO_COUNT (KASAN_EXTRA_FREE_INFO_COUNT + 1)
+struct extra_free_info {
+ /* Round-robin FIFO array. */
+ struct kasan_track free_track[KASAN_EXTRA_FREE_INFO_COUNT];
+ u8 free_pointer_tag[KASAN_TOTAL_FREE_INFO_COUNT];
+ u8 free_track_tail;
+};
+#endif
+
struct kasan_alloc_meta {
struct kasan_track alloc_track;
struct kasan_track free_track;
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+ struct extra_free_info free_info;
+#endif
};
struct qlist_node {
@@ -146,6 +160,29 @@ void kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip);
void kasan_report_invalid_free(void *object, unsigned long ip);
+struct page *addr_to_page(const void *addr);
+
+void kasan_set_track(struct kasan_track *track, gfp_t flags);
+
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+void kasan_set_free_info(struct kmem_cache *cache, void *object, u8 tag);
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag);
+char *kasan_get_corruption_type(void *addr);
+#else
+static inline void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag) { }
+static inline struct kasan_track *kasan_get_free_track(
+ struct kmem_cache *cache, void *object, u8 tag)
+{
+ return NULL;
+}
+static inline char *kasan_get_corruption_type(void *addr)
+{
+ return NULL;
+}
+#endif
+
#if defined(CONFIG_KASAN_GENERIC) && \
(defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
void quarantine_put(struct kasan_free_meta *info, struct kmem_cache *cache);
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 0e5f965f1882..9ea7a4265b42 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -111,14 +111,6 @@ static void print_track(struct kasan_track *track, const char *prefix)
}
}
-static struct page *addr_to_page(const void *addr)
-{
- if ((addr >= (void *)PAGE_OFFSET) &&
- (addr < high_memory))
- return virt_to_head_page(addr);
- return NULL;
-}
-
static void describe_object_addr(struct kmem_cache *cache, void *object,
const void *addr)
{
@@ -152,18 +144,27 @@ static void describe_object_addr(struct kmem_cache *cache, void *object,
}
static void describe_object(struct kmem_cache *cache, void *object,
- const void *addr)
+ const void *tagged_addr)
{
+ void *untagged_addr = reset_tag(tagged_addr);
struct kasan_alloc_meta *alloc_info = get_alloc_info(cache, object);
if (cache->flags & SLAB_KASAN) {
print_track(&alloc_info->alloc_track, "Allocated");
pr_err("\n");
- print_track(&alloc_info->free_track, "Freed");
- pr_err("\n");
+ if (IS_ENABLED(CONFIG_KASAN_SW_TAGS_IDENTIFY)) {
+ struct kasan_track *free_track;
+ u8 tag = get_tag(tagged_addr);
+
+ free_track = kasan_get_free_track(cache, object, tag);
+ print_track(free_track, "Freed");
+ } else {
+ print_track(&alloc_info->free_track, "Freed");
+ pr_err("\n");
+ }
}
- describe_object_addr(cache, object, addr);
+ describe_object_addr(cache, object, untagged_addr);
}
static inline bool kernel_or_module_addr(const void *addr)
@@ -344,23 +345,25 @@ static void print_address_stack_frame(const void *addr)
print_decoded_frame_descr(frame_descr);
}
-static void print_address_description(void *addr)
+static void print_address_description(void *tagged_addr)
{
- struct page *page = addr_to_page(addr);
+ void *untagged_addr = reset_tag(tagged_addr);
+ struct page *page = addr_to_page(untagged_addr);
dump_stack();
pr_err("\n");
if (page && PageSlab(page)) {
struct kmem_cache *cache = page->slab_cache;
- void *object = nearest_obj(cache, page, addr);
+ void *object = nearest_obj(cache, page, untagged_addr);
- describe_object(cache, object, addr);
+ describe_object(cache, object, tagged_addr);
}
- if (kernel_or_module_addr(addr) && !init_task_stack_addr(addr)) {
+ if (kernel_or_module_addr(untagged_addr) &&
+ !init_task_stack_addr(untagged_addr)) {
pr_err("The buggy address belongs to the variable:\n");
- pr_err(" %pS\n", addr);
+ pr_err(" %pS\n", tagged_addr);
}
if (page) {
@@ -368,7 +371,7 @@ static void print_address_description(void *addr)
dump_page(page, "kasan: bad access detected");
}
- print_address_stack_frame(addr);
+ print_address_stack_frame(untagged_addr);
}
static bool row_is_guilty(const void *row, const void *guilty)
@@ -432,6 +435,14 @@ static bool report_enabled(void)
return !test_and_set_bit(KASAN_BIT_REPORTED, &kasan_flags);
}
+struct page *addr_to_page(const void *addr)
+{
+ if ((addr >= (void *)PAGE_OFFSET) &&
+ (addr < high_memory))
+ return virt_to_head_page(addr);
+ return NULL;
+}
+
void kasan_report_invalid_free(void *object, unsigned long ip)
{
unsigned long flags;
@@ -439,10 +450,10 @@ void kasan_report_invalid_free(void *object, unsigned long ip)
start_report(&flags);
pr_err("BUG: KASAN: double-free or invalid-free in %pS\n", (void *)ip);
print_tags(get_tag(object), reset_tag(object));
- object = reset_tag(object);
pr_err("\n");
print_address_description(object);
pr_err("\n");
+ object = reset_tag(object);
print_shadow_for_address(object);
end_report(&flags);
}
@@ -479,7 +490,7 @@ void __kasan_report(unsigned long addr, size_t size, bool is_write, unsigned lon
pr_err("\n");
if (addr_has_shadow(untagged_addr)) {
- print_address_description(untagged_addr);
+ print_address_description(tagged_addr);
pr_err("\n");
print_shadow_for_address(info.first_bad_addr);
} else {
diff --git a/mm/kasan/tags.c b/mm/kasan/tags.c
index 0e987c9ca052..05a11f1cfff7 100644
--- a/mm/kasan/tags.c
+++ b/mm/kasan/tags.c
@@ -161,3 +161,89 @@ void __hwasan_tag_memory(unsigned long addr, u8 tag, unsigned long size)
kasan_poison_shadow((void *)addr, size, tag);
}
EXPORT_SYMBOL(__hwasan_tag_memory);
+
+#ifdef CONFIG_KASAN_SW_TAGS_IDENTIFY
+void kasan_set_free_info(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ struct extra_free_info *free_info;
+ u8 idx;
+
+ alloc_meta = get_alloc_info(cache, object);
+ free_info = &alloc_meta->free_info;
+
+ if (free_info->free_track_tail == 0)
+ free_info->free_track_tail = KASAN_EXTRA_FREE_INFO_COUNT;
+ else
+ free_info->free_track_tail -= 1;
+
+ idx = free_info->free_track_tail;
+ free_info->free_pointer_tag[idx] = tag;
+
+ if (idx == KASAN_EXTRA_FREE_INFO_COUNT)
+ kasan_set_track(&alloc_meta->free_track, GFP_NOWAIT);
+ else
+ kasan_set_track(&free_info->free_track[idx], GFP_NOWAIT);
+}
+
+struct kasan_track *kasan_get_free_track(struct kmem_cache *cache,
+ void *object, u8 tag)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ struct extra_free_info *free_info;
+ int idx, i;
+
+ alloc_meta = get_alloc_info(cache, object);
+ free_info = &alloc_meta->free_info;
+
+ for (i = 0; i < KASAN_TOTAL_FREE_INFO_COUNT; i++) {
+ idx = free_info->free_track_tail + i;
+ if (idx >= KASAN_TOTAL_FREE_INFO_COUNT)
+ idx -= KASAN_TOTAL_FREE_INFO_COUNT;
+
+ if (free_info->free_pointer_tag[idx] == tag) {
+ if (idx == KASAN_EXTRA_FREE_INFO_COUNT)
+ return &alloc_meta->free_track;
+ else
+ return &free_info->free_track[idx];
+ }
+ }
+ if (free_info->free_track_tail == KASAN_EXTRA_FREE_INFO_COUNT)
+ return &alloc_meta->free_track;
+ else
+ return &free_info->free_track[free_info->free_track_tail];
+}
+
+char *kasan_get_corruption_type(void *addr)
+{
+ struct kasan_alloc_meta *alloc_meta;
+ struct extra_free_info *free_info;
+ struct page *page;
+ struct kmem_cache *cache;
+ void *object;
+ u8 tag;
+ int idx, i;
+
+ tag = get_tag(addr);
+ addr = reset_tag(addr);
+ page = addr_to_page(addr);
+ if (page && PageSlab(page)) {
+ cache = page->slab_cache;
+ object = nearest_obj(cache, page, addr);
+ alloc_meta = get_alloc_info(cache, object);
+ free_info = &alloc_meta->free_info;
+
+ for (i = 0; i < KASAN_TOTAL_FREE_INFO_COUNT; i++) {
+ idx = free_info->free_track_tail + i;
+ if (idx >= KASAN_TOTAL_FREE_INFO_COUNT)
+ idx -= KASAN_TOTAL_FREE_INFO_COUNT;
+
+ if (free_info->free_pointer_tag[idx] == tag)
+ return "use-after-free";
+ }
+ return "out-of-bounds";
+ }
+ return "invalid-access";
+}
+#endif
diff --git a/mm/kasan/tags_report.c b/mm/kasan/tags_report.c
index 8eaf5f722271..6d8cdb91c4b6 100644
--- a/mm/kasan/tags_report.c
+++ b/mm/kasan/tags_report.c
@@ -36,7 +36,10 @@
const char *get_bug_type(struct kasan_access_info *info)
{
- return "invalid-access";
+ if (IS_ENABLED(CONFIG_KASAN_SW_TAGS_IDENTIFY))
+ return(kasan_get_corruption_type((void *)info->access_addr));
+ else
+ return "invalid-access";
}
void *find_first_bad_addr(void *addr, size_t size)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2] arm64: dts: ls1028a: Add Thermal Monitor Unit node
From: Yuantian Tang @ 2019-08-06 5:35 UTC (permalink / raw)
To: shawnguo
Cc: mark.rutland, devicetree, Yuantian Tang, linux-kernel, leoyang.li,
robh+dt, linux-arm-kernel
The Thermal Monitoring Unit (TMU) monitors and reports the
temperature from 2 remote temperature measurement sites
located on ls1028a chip.
Add TMU dts node to enable this feature.
Signed-off-by: Yuantian Tang <andy.tang@nxp.com>
Acked-by: Eduardo Valentin <edubezval@gmail.com>
---
v2:
- remove multiple sensors support
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 85 +++++++++++++++++++
1 file changed, 85 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index aef5b06a98d5..20d7e7db5dcb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -29,6 +29,7 @@
clocks = <&clockgen 1 0>;
next-level-cache = <&l2>;
cpu-idle-states = <&CPU_PW20>;
+ #cooling-cells = <2>;
};
cpu1: cpu@1 {
@@ -39,6 +40,7 @@
clocks = <&clockgen 1 0>;
next-level-cache = <&l2>;
cpu-idle-states = <&CPU_PW20>;
+ #cooling-cells = <2>;
};
l2: l2-cache {
@@ -503,6 +505,89 @@
status = "disabled";
};
+ tmu: tmu@1f00000 {
+ compatible = "fsl,qoriq-tmu";
+ reg = <0x0 0x1f80000 0x0 0x10000>;
+ interrupts = <0 23 0x4>;
+ fsl,tmu-range = <0xb0000 0xa0026 0x80048 0x70061>;
+ fsl,tmu-calibration = <0x00000000 0x00000024
+ 0x00000001 0x0000002b
+ 0x00000002 0x00000031
+ 0x00000003 0x00000038
+ 0x00000004 0x0000003f
+ 0x00000005 0x00000045
+ 0x00000006 0x0000004c
+ 0x00000007 0x00000053
+ 0x00000008 0x00000059
+ 0x00000009 0x00000060
+ 0x0000000a 0x00000066
+ 0x0000000b 0x0000006d
+
+ 0x00010000 0x0000001c
+ 0x00010001 0x00000024
+ 0x00010002 0x0000002c
+ 0x00010003 0x00000035
+ 0x00010004 0x0000003d
+ 0x00010005 0x00000045
+ 0x00010006 0x0000004d
+ 0x00010007 0x00000045
+ 0x00010008 0x0000005e
+ 0x00010009 0x00000066
+ 0x0001000a 0x0000006e
+
+ 0x00020000 0x00000018
+ 0x00020001 0x00000022
+ 0x00020002 0x0000002d
+ 0x00020003 0x00000038
+ 0x00020004 0x00000043
+ 0x00020005 0x0000004d
+ 0x00020006 0x00000058
+ 0x00020007 0x00000063
+ 0x00020008 0x0000006e
+
+ 0x00030000 0x00000010
+ 0x00030001 0x0000001c
+ 0x00030002 0x00000029
+ 0x00030003 0x00000036
+ 0x00030004 0x00000042
+ 0x00030005 0x0000004f
+ 0x00030006 0x0000005b
+ 0x00030007 0x00000068>;
+ little-endian;
+ #thermal-sensor-cells = <1>;
+ };
+
+ thermal-zones {
+ core-cluster {
+ polling-delay-passive = <1000>;
+ polling-delay = <5000>;
+ thermal-sensors = <&tmu 0>;
+
+ trips {
+ core_cluster_alert: core-cluster-alert {
+ temperature = <85000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
+
+ core_cluster_crit: core-cluster-crit {
+ temperature = <95000>;
+ hysteresis = <2000>;
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&core_cluster_alert>;
+ cooling-device =
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+ <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+ };
+
pcie@1f0000000 { /* Integrated Endpoint Root Complex */
compatible = "pci-host-ecam-generic";
reg = <0x01 0xf0000000 0x0 0x100000>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* RE: [PATCH 1/2] dt-bindings: imx-ocotp: Add i.MX8MN compatible
From: Anson Huang @ 2019-08-06 5:59 UTC (permalink / raw)
To: srinivas.kandagatla@linaro.org, robh+dt@kernel.org,
mark.rutland@arm.com, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: dl-linux-imx
In-Reply-To: <20190711023714.16000-1-Anson.Huang@nxp.com>
Gentle Ping...
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add compatible for i.MX8MN and add i.MX8MM/i.MX8MN to the description.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> index 96ffd06..904dadf 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt
> @@ -2,7 +2,7 @@ Freescale i.MX6 On-Chip OTP Controller (OCOTP) device
> tree bindings
>
> This binding represents the on-chip eFuse OTP controller found on
> i.MX6Q/D, i.MX6DL/S, i.MX6SL, i.MX6SX, i.MX6UL, i.MX6ULL/ULZ, i.MX6SLL, -
> i.MX7D/S, i.MX7ULP and i.MX8MQ SoCs.
> +i.MX7D/S, i.MX7ULP, i.MX8MQ, i.MX8MM and i.MX8MN SoCs.
>
> Required properties:
> - compatible: should be one of
> @@ -16,6 +16,7 @@ Required properties:
> "fsl,imx7ulp-ocotp" (i.MX7ULP),
> "fsl,imx8mq-ocotp" (i.MX8MQ),
> "fsl,imx8mm-ocotp" (i.MX8MM),
> + "fsl,imx8mn-ocotp" (i.MX8MN),
> followed by "syscon".
> - #address-cells : Should be 1
> - #size-cells : Should be 1
> --
> 2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 4/7] ALSA: pcm: use dma_can_mmap() to check if a device supports dma_mmap_*
From: Takashi Iwai @ 2019-08-06 6:00 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-xtensa, Michal Simek, linux-parisc, linux-sh, Takashi Iwai,
linuxppc-dev, x86, linux-m68k, linux-kernel, iommu, Robin Murphy,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190806052949.GC13409@lst.de>
On Tue, 06 Aug 2019 07:29:49 +0200,
Christoph Hellwig wrote:
>
> On Mon, Aug 05, 2019 at 11:22:03AM +0200, Takashi Iwai wrote:
> > This won't work as expected, unfortunately. It's a bit tricky check,
> > since the driver may have its own mmap implementation via
> > substream->ops->mmap, and the dma_buffer.dev.dev might point to
> > another object depending on the dma_buffer.dev.type.
> >
> > So please replace with something like below:
>
> >From my gut feeling I'd reorder it a bit to make it more clear like
> this:
>
> http://git.infradead.org/users/hch/misc.git/commitdiff/958fccf54d00c16740522f818d23f9350498e911
>
> if this is fine it'll be in the next version, waiting for a little more
> feedback on the other patches.
Yes, the new one looks good.
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Thanks!
Takashi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH V3] soc: imx-scu: Add SoC UID(unique identifier) support
From: Anson Huang @ 2019-08-06 6:04 UTC (permalink / raw)
To: Shawn Guo, Marco Felsch
Cc: Aisheng Dong, Abel Vesa, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190718082216.GO3738@dragon>
Hi, Marco
Are you OK with this patch?
Thanks,
Anson.
> On Tue, Jul 02, 2019 at 03:45:45PM +0800, Anson.Huang@nxp.com wrote:
> > From: Anson Huang <Anson.Huang@nxp.com>
> >
> > Add i.MX SCU SoC's UID(unique identifier) support, user can read it
> > from sysfs:
> >
> > root@imx8qxpmek:~# cat /sys/devices/soc0/soc_uid
> > 7B64280B57AC1898
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
>
> @Marco, are you happy with it?
>
> Shawn
>
> > ---
> > Change since V2:
> > - The SCU FW API for getting UID does NOT have response, so we
> should set
> > imx_scu_call_rpc()'s 3rd parameter as false and still can check the
> returned
> > value, and comment is no needed any more.
> > ---
> > drivers/soc/imx/soc-imx-scu.c | 39
> > +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 39 insertions(+)
> >
> > diff --git a/drivers/soc/imx/soc-imx-scu.c
> > b/drivers/soc/imx/soc-imx-scu.c index 676f612..50831eb 100644
> > --- a/drivers/soc/imx/soc-imx-scu.c
> > +++ b/drivers/soc/imx/soc-imx-scu.c
> > @@ -27,6 +27,40 @@ struct imx_sc_msg_misc_get_soc_id {
> > } data;
> > } __packed;
> >
> > +struct imx_sc_msg_misc_get_soc_uid {
> > + struct imx_sc_rpc_msg hdr;
> > + u32 uid_low;
> > + u32 uid_high;
> > +} __packed;
> > +
> > +static ssize_t soc_uid_show(struct device *dev,
> > + struct device_attribute *attr, char *buf) {
> > + struct imx_sc_msg_misc_get_soc_uid msg;
> > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > + u64 soc_uid;
> > + int ret;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_MISC;
> > + hdr->func = IMX_SC_MISC_FUNC_UNIQUE_ID;
> > + hdr->size = 1;
> > +
> > + ret = imx_scu_call_rpc(soc_ipc_handle, &msg, false);
> > + if (ret) {
> > + pr_err("%s: get soc uid failed, ret %d\n", __func__, ret);
> > + return ret;
> > + }
> > +
> > + soc_uid = msg.uid_high;
> > + soc_uid <<= 32;
> > + soc_uid |= msg.uid_low;
> > +
> > + return sprintf(buf, "%016llX\n", soc_uid); }
> > +
> > +static DEVICE_ATTR_RO(soc_uid);
> > +
> > static int imx_scu_soc_id(void)
> > {
> > struct imx_sc_msg_misc_get_soc_id msg; @@ -102,6 +136,11 @@
> static
> > int imx_scu_soc_probe(struct platform_device *pdev)
> > goto free_revision;
> > }
> >
> > + ret = device_create_file(soc_device_to_device(soc_dev),
> > + &dev_attr_soc_uid);
> > + if (ret)
> > + goto free_revision;
> > +
> > return 0;
> >
> > free_revision:
> > --
> > 2.7.4
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [linux-sunxi] Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality
From: Chen-Yu Tsai @ 2019-08-06 6:22 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Linux-ALSA, Andrea Venturi (pers), Maxime Ripard,
Christopher Obbard, Liam Girdwood, linux-kernel, Code Kipper,
linux-sunxi, Mark Brown, linux-arm-kernel
In-Reply-To: <1589203.0AjJVEASy3@jernej-laptop>
On Thu, Aug 1, 2019 at 1:32 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Dne sreda, 31. julij 2019 ob 14:29:53 CEST je Maxime Ripard napisal(a):
> > On Tue, Jul 30, 2019 at 07:57:10PM +0200, Jernej Škrabec wrote:
> > > Dne torek, 04. junij 2019 ob 11:38:44 CEST je Code Kipper napisal(a):
> > > > On Tue, 4 Jun 2019 at 11:02, Christopher Obbard <chris@64studio.com>
> wrote:
> > > > > On Tue, 4 Jun 2019 at 09:43, Code Kipper <codekipper@gmail.com> wrote:
> > > > > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard
> > > > > > <maxime.ripard@bootlin.com>
> > >
> > > wrote:
> > > > > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekipper@gmail.com
> wrote:
> > > > > > > > From: Marcus Cooper <codekipper@gmail.com>
> > > > > > > >
> > > > > > > > The i2s block supports multi-lane i2s output however this
> > > > > > > > functionality
> > > > > > > > is only possible in earlier SoCs where the pins are exposed and
> > > > > > > > for
> > > > > > > > the i2s block used for HDMI audio on the later SoCs.
> > > > > > > >
> > > > > > > > To enable this functionality, an optional property has been
> > > > > > > > added to
> > > > > > > > the bindings.
> > > > > > > >
> > > > > > > > Signed-off-by: Marcus Cooper <codekipper@gmail.com>
> > > > > > >
> > > > > > > I'd like to have Mark's input on this, but I'm really worried
> > > > > > > about
> > > > > > > the interaction with the proper TDM support.
> > > > > > >
> > > > > > > Our fundamental issue is that the controller can have up to 8
> > > > > > > channels, but either on 4 lines (instead of 1), or 8 channels on 1
> > > > > > > (like proper TDM) (or any combination between the two, but that
> > > > > > > should
> > > > > > > be pretty rare).
> > > > > >
> > > > > > I understand...maybe the TDM needs to be extended to support this to
> > > > > > consider channel mapping and multiple transfer lines. I was thinking
> > > > > > about the later when someone was requesting support on IIRC a while
> > > > > > ago, I thought masking might of been a solution. These can wait as
> > > > > > the
> > > > > > only consumer at the moment is LibreELEC and we can patch it there.
> > > > >
> > > > > Hi Marcus,
> > > > >
> > > > > FWIW, the TI McASP driver has support for TDM & (i think?) multiple
> > > > > transfer lines which are called serializers.
> > > > > Maybe this can help with inspiration?
> > > > > see
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tre
> > > > > e/s
> > > > > ound/soc/ti/davinci-mcasp.c sample DTS:
> > > > >
> > > > > &mcasp0 {
> > > > >
> > > > > #sound-dai-cells = <0>;
> > > > > status = "okay";
> > > > > pinctrl-names = "default";
> > > > > pinctrl-0 = <&mcasp0_pins>;
> > > > >
> > > > > op-mode = <0>;
> > > > > tdm-slots = <8>;
> > > > > serial-dir = <
> > > > >
> > > > > 2 0 1 0
> > > > > 0 0 0 0
> > > > > 0 0 0 0
> > > > > 0 0 0 0
> > > > > >
> > > > > >;
> > > > >
> > > > > tx-num-evt = <1>;
> > > > > rx-num-evt = <1>;
> > > > >
> > > > > };
> > > > >
> > > > > Cheers!
> > > >
> > > > Thanks, this looks good.
> > >
> > > I would really like to see this issue resolved, because HDMI audio support
> > > in mainline Linux for those SoCs is long overdue.
> > >
> > > However, there is a possibility to still add HDMI audio suport (stereo
> > > only) even if this issue is not completely solved. If we agree that
> > > configuration of channels would be solved with additional property as
> > > Christopher suggested, support for >2 channels can be left for a later
> > > time when support for that property would be implemented. Currently,
> > > stereo HDMI audio support can be added with a few patches.
> > >
> > > I think all I2S cores are really the same, no matter if internally
> > > connected to HDMI controller or routed to pins, so it would make sense to
> > > use same compatible for all of them. It's just that those I2S cores which
> > > are routed to pins can use only one lane and >2 channels can be used only
> > > in TDM mode of operation, if I understand this correctly.
> > >
> > > New property would have to be optional, so it's omission would result in
> > > same channel configuration as it is already present, to preserve
> > > compatibility with old device trees. And this mode is already sufficient
> > > for stereo HDMI audio support.
> >
> > Yeah, it looks like a good plan.
> >
> > > Side note: HDMI audio with current sun4i-i2s driver has a delay (about a
> > > second), supposedly because DW HDMI controller automatically generates CTS
> > > value based on I2S clock (auto CTS value generation is enabled per
> > > DesignWare recomendation for DW HDMI I2S interface).
> >
> > Is that a constant delay during the audio playback, or only at startup?
>
> I think it's just at startup, e.g. if you're watching movie, audio is in sync,
> it's just that first second or so is silent.
>
> >
> > > I2S driver from BSP Linux solves that by having I2S clock output
> > > enabled all the time. Should this be flagged with some additional
> > > property in DT?
> >
> > I'd say that if the codec has that requirement, then it should be
> > between the codec and the DAI, the DT doesn't really have anything to
> > do with this.
>
> Ok, but how to communicate that fact to I2S driver then? BSP driver solves
> that by using different compatible, but as I said before, I2S cores are not
> really different, so this seems wrong.
Maybe we could make the DW-HDMI I2S driver require the I2S clock be on all
the time? You wouldn't need any changes to the DT.
ChenYu
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on A64-OLinuXino
From: Chen-Yu Tsai @ 2019-08-06 6:25 UTC (permalink / raw)
To: Martin Ayotte; +Cc: Maxime Ripard, Sunil Mohan Adapa, linux-arm-kernel
In-Reply-To: <1955D9AD572C4F57A2D66B15EB8CF79C@GirolesWin7>
On Mon, Aug 5, 2019 at 8:58 PM Martin Ayotte <martinayotte@gmail.com> wrote:
>
> Fine for me too.
>
> Thanks .
>
> -----Message d'origine-----
> De : Sunil Mohan Adapa [mailto:sunil@medhas.org]
> Envoyé : Monday, August 05, 2019 1:25 AM
> À : Chen-Yu Tsai
> Cc : Maxime Ripard; Martin Ayotte; linux-arm-kernel
> Objet : Re: [PATCH v2] arm64: dts: allwinner: a64: Enable eMMC on
> A64-OLinuXino
>
> On 04/08/19 8:33 pm, Chen-Yu Tsai wrote:
> > On Fri, Aug 2, 2019 at 2:47 AM Sunil Mohan Adapa <sunil@medhas.org> wrote:
> >>
> >> On 01/08/19 6:49 am, Martin Ayotte wrote:
> >>> If my SOB could help here, I don't mind since I've done the commit
> >>> more than a year ago for Armbian ...
> >>>
> >>> Signed-off-by: Martin Ayotte <martinayotte@gmai.com>
> >>> Tested-by: Martin Ayotte <martinayotte@gmai.com>
> >> gmai.com is likely a typo.
> >>
> >>> On Wed, Jul 31, 2019 at 10:42 PM Chen-Yu Tsai <wens@csie.org
> >>>
> >>>> Thanks. The patch looks good overall. The authorship is a little
> >>>> confusing though. If it was initially done by Martin (CC-ed), then
> >>>> he should be the author, and we should get his Signed-off-by if
> >>>> possible.
> >>
> >> Martin is indeed the original author of the patch. Thank you for
> reviewing.
> >
> > I'd like to apply this patch with Martin as the author, if that's OK with
> you
> > both?
>
> That is completely okay with me.
Applied for 5.4.
I reordered the tags so they make more sense:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/commit/?h=sunxi/dt-for-5.4&id=0834887732df5af41b59b2e4d530fc1f5478965f
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv3 1/3] dt-bindings: pci: layerscape-pci: add compatible strings "fsl, ls1028a-pcie"
From: Xiaowei Bao @ 2019-08-06 6:15 UTC (permalink / raw)
To: bhelgaas, robh+dt, mark.rutland, shawnguo, leoyang.li, kishon,
lorenzo.pieralisi, arnd, gregkh, minghuan.Lian, mingkai.hu,
zhiqiang.hou, roy.zang, kstewart, pombredanne, shawn.lin,
linux-pci, devicetree, linux-kernel, linux-arm-kernel,
linuxppc-dev
Cc: Hou Zhiqiang, Xiaowei Bao
Add the PCIe compatible string for LS1028A
Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
---
v2:
- no change.
v3:
- no change.
Documentation/devicetree/bindings/pci/layerscape-pci.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
index e20ceaa..99a386e 100644
--- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
+++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
@@ -21,6 +21,7 @@ Required properties:
"fsl,ls1046a-pcie"
"fsl,ls1043a-pcie"
"fsl,ls1012a-pcie"
+ "fsl,ls1028a-pcie"
EP mode:
"fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
- reg: base addresses and lengths of the PCIe controller register blocks.
--
2.9.5
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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