* Re: [PATCH] drivers/perf: hisi: Permit modular builds of HiSilicon uncore drivers
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: Shaokun Zhang, Zhou Wang, Mark Rutland
Cc: catalin.marinas, Will Deacon, linuxarm, linux-arm-kernel
In-Reply-To: <1588820305-174479-1-git-send-email-wangzhou1@hisilicon.com>
On Thu, 7 May 2020 10:58:25 +0800, Zhou Wang wrote:
> This patch lets HiSilicon uncore PMU driver can be built as modules.
> A common module and three specific uncore PMU driver modules will be built.
>
> Export necessary functions in hisi_uncore_pmu module, and change
> irq_set_affinity to irq_set_affinity_hint to pass compile.
Applied to will (for-next/perf), thanks!
[1/1] drivers/perf: hisi: Permit modular builds of HiSilicon uncore drivers
https://git.kernel.org/will/c/97807325a02b
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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 v6] iommu/arm-smmu-qcom: Request direct mapping for modem device
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: robin.murphy, swboyd, joro, Sibi Sankar
Cc: linux-kernel, catalin.marinas, dianders, evgreen, bjorn.andersson,
iommu, mka, linux-arm-msm, Will Deacon, linux-arm-kernel
In-Reply-To: <20200511175532.25874-1-sibis@codeaurora.org>
On Mon, 11 May 2020 23:25:32 +0530, Sibi Sankar wrote:
> The modem remote processor has two access paths to DDR. One path is
> directly connected to DDR and another path goes through an SMMU. The
> SMMU path is configured to be a direct mapping because it's used by
> various peripherals in the modem subsystem. Typically this direct
> mapping is configured statically at EL2 by QHEE (Qualcomm's Hypervisor
> Execution Environment) before the kernel is entered.
>
> [...]
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] iommu/arm-smmu-qcom: Request direct mapping for modem device
https://git.kernel.org/will/c/d100ff3843b7
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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] iommu/arm-smmu-v3: Don't reserve implementation defined register space
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: linux-arm-kernel, Jean-Philippe Brucker, iommu
Cc: lorenzo.pieralisi, catalin.marinas, joro, robin.murphy, tuanphan,
Will Deacon
In-Reply-To: <20200513110255.597203-1-jean-philippe@linaro.org>
On Wed, 13 May 2020 13:02:57 +0200, Jean-Philippe Brucker wrote:
> Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG)
> inside the first 64kB region of the SMMU. Since PMCG are managed by a
> separate driver, this layout causes resource reservation conflicts
> during boot.
>
> To avoid this conflict, don't reserve the MMIO regions that are
> implementation defined. Although devm_ioremap_resource() still works on
> full pages under the hood, this way we benefit from resource conflict
> checks.
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] iommu/arm-smmu-v3: Don't reserve implementation defined register space
https://git.kernel.org/will/c/52f3fab0067d
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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] pmu/smmuv3: Clear IRQ affinity hint on device removal
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: mark.rutland, Jean-Philippe Brucker
Cc: catalin.marinas, Will Deacon, linux-arm-kernel
In-Reply-To: <20200422084805.237738-1-jean-philippe@linaro.org>
On Wed, 22 Apr 2020 10:48:06 +0200, Jean-Philippe Brucker wrote:
> Currently when trying to remove the SMMUv3 PMU module we get a
> WARN_ON_ONCE from free_irq(), because the affinity hint set during probe
> hasn't been properly cleared.
>
> [ 238.878383] WARNING: CPU: 0 PID: 175 at kernel/irq/manage.c:1744 free_irq+0x324/0x358
> ...
> [ 238.897263] Call trace:
> [ 238.897998] free_irq+0x324/0x358
> [ 238.898792] devm_irq_release+0x18/0x28
> [ 238.899189] release_nodes+0x1b0/0x228
> [ 238.899984] devres_release_all+0x38/0x60
> [ 238.900779] device_release_driver_internal+0x10c/0x1d0
> [ 238.901574] driver_detach+0x50/0xe0
> [ 238.902368] bus_remove_driver+0x5c/0xd8
> [ 238.903448] driver_unregister+0x30/0x60
> [ 238.903958] platform_driver_unregister+0x14/0x20
> [ 238.905075] arm_smmu_pmu_exit+0x1c/0xecc [arm_smmuv3_pmu]
> [ 238.905547] __arm64_sys_delete_module+0x14c/0x260
> [ 238.906342] el0_svc_common.constprop.0+0x74/0x178
> [ 238.907355] do_el0_svc+0x24/0x90
> [ 238.907932] el0_sync_handler+0x11c/0x198
> [ 238.908979] el0_sync+0x158/0x180
>
> [...]
Applied to will (for-next/perf), thanks!
[1/1] pmu/smmuv3: Clear IRQ affinity hint on device removal
https://git.kernel.org/will/c/10f6cd2af21b
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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] ACPI: GTDT: Put GTDT table after parsing
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: Sudeep Holla, Rafael J. Wysocki, Lorenzo Pieralisi, Hanjun Guo
Cc: catalin.marinas, Will Deacon, linux-arm-kernel, linux-acpi
In-Reply-To: <1588910753-18543-1-git-send-email-guohanjun@huawei.com>
On Fri, 8 May 2020 12:05:52 +0800, Hanjun Guo wrote:
> The mapped GTDT table needs to be released after
> the driver init.
Applied to arm64 (for-next/acpi), thanks!
[1/2] ACPI: GTDT: Put GTDT table after parsing
https://git.kernel.org/arm64/c/5ec605108ff4
[2/2] ACPI: IORT: Add comments for not calling acpi_put_table()
https://git.kernel.org/arm64/c/701dafe0670c
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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: Call debug_traps_init() from trap_init() to help early kgdb
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: Daniel Thompson, Douglas Anderson, Jason Wessel
Cc: Mark Rutland, sumit.garg, liwei391, Eric W. Biederman,
Paul E. McKenney, Alexios Zavras, Enrico Weigelt, catalin.marinas,
linux-kernel, jinho lim, Greg Kroah-Hartman, James Morse,
Masami Hiramatsu, kgdb-bugreport, Zenghui Yu, Thomas Gleixner,
Will Deacon, Dave Martin, Allison Randal, linux-arm-kernel
In-Reply-To: <20200513160501.1.I0b5edf030cc6ebef6ab4829f8867cdaea42485d8@changeid>
On Wed, 13 May 2020 16:06:37 -0700, Douglas Anderson wrote:
> A new kgdb feature will soon land (kgdb_earlycon) that lets us run
> kgdb much earlier. In order for everything to work properly it's
> important that the break hook is setup by the time we process
> "kgdbwait".
>
> Right now the break hook is setup in debug_traps_init() and that's
> called from arch_initcall(). That's a bit too late since
> kgdb_earlycon really needs things to be setup by the time the system
> calls dbg_late_init().
>
> [...]
Applied to arm64 (for-next/misc), thanks!
[1/1] arm64: Call debug_traps_init() from trap_init() to help early kgdb
https://git.kernel.org/arm64/c/b322c65f8ca3
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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 -next] iommu/arm-smmu-v3: remove set but not used variable 'smmu'
From: Will Deacon @ 2020-05-18 23:04 UTC (permalink / raw)
To: joro, robin.murphy, Chen Zhou
Cc: catalin.marinas, iommu, Will Deacon, linux-kernel,
linux-arm-kernel
In-Reply-To: <20200508014955.87630-1-chenzhou10@huawei.com>
On Fri, 8 May 2020 09:49:55 +0800, Chen Zhou wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/iommu/arm-smmu-v3.c:2989:26:
> warning: variable ‘smmu’ set but not used [-Wunused-but-set-variable]
> struct arm_smmu_device *smmu;
Applied to will (for-joerg/arm-smmu/updates), thanks!
[1/1] iommu/arm-smmu-v3: remove set but not used variable 'smmu'
https://git.kernel.org/will/c/06020196c82e
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
_______________________________________________
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] soc: fsl: qe: Replace one-element array and use struct_size() helper
From: Kees Cook @ 2020-05-18 22:56 UTC (permalink / raw)
To: Gustavo A. R. Silva
Cc: Gustavo A. R. Silva, linux-kernel, Li Yang, linuxppc-dev,
linux-arm-kernel, Qiang Zhao
In-Reply-To: <20200518221904.GA22274@embeddedor>
On Mon, May 18, 2020 at 05:19:04PM -0500, Gustavo A. R. Silva wrote:
> The current codebase makes use of one-element arrays in the following
> form:
>
> struct something {
> int length;
> u8 data[1];
> };
>
> struct something *instance;
>
> instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
> instance->length = size;
> memcpy(instance->data, source, size);
>
> but the preferred mechanism to declare variable-length types such as
> these ones is a flexible array member[1][2], introduced in C99:
>
> struct foo {
> int stuff;
> struct boo array[];
> };
>
> By making use of the mechanism above, we will get a compiler warning
> in case the flexible array does not occur last in the structure, which
> will help us prevent some kind of undefined behavior bugs from being
> inadvertently introduced[3] to the codebase from now on. So, replace
> the one-element array with a flexible-array member.
>
> Also, make use of the new struct_size() helper to properly calculate the
> size of struct qe_firmware.
>
> This issue was found with the help of Coccinelle and, audited and fixed
> _manually_.
>
> [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
> [2] https://github.com/KSPP/linux/issues/21
> [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
> ---
> drivers/soc/fsl/qe/qe.c | 4 ++--
> include/soc/fsl/qe/qe.h | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
> index 447146861c2c1..2df20d6f85fa4 100644
> --- a/drivers/soc/fsl/qe/qe.c
> +++ b/drivers/soc/fsl/qe/qe.c
> @@ -448,7 +448,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
> unsigned int i;
> unsigned int j;
> u32 crc;
> - size_t calc_size = sizeof(struct qe_firmware);
> + size_t calc_size;
> size_t length;
> const struct qe_header *hdr;
>
> @@ -480,7 +480,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
> }
>
> /* Validate the length and check if there's a CRC */
> - calc_size += (firmware->count - 1) * sizeof(struct qe_microcode);
> + calc_size = struct_size(firmware, microcode, firmware->count);
>
> for (i = 0; i < firmware->count; i++)
> /*
> diff --git a/include/soc/fsl/qe/qe.h b/include/soc/fsl/qe/qe.h
> index e282ac01ec081..3feddfec9f87d 100644
> --- a/include/soc/fsl/qe/qe.h
> +++ b/include/soc/fsl/qe/qe.h
> @@ -307,7 +307,7 @@ struct qe_firmware {
> u8 revision; /* The microcode version revision */
> u8 padding; /* Reserved, for alignment */
> u8 reserved[4]; /* Reserved, for future expansion */
> - } __attribute__ ((packed)) microcode[1];
> + } __packed microcode[];
> /* All microcode binaries should be located here */
> /* CRC32 should be located here, after the microcode binaries */
> } __attribute__ ((packed));
> --
> 2.26.2
>
Hm, looking at this code, I see a few other things that need to be
fixed:
1) drivers/tty/serial/ucc_uart.c does not do a be32_to_cpu() conversion
on the length test (understandably, a little-endian system has never run
this code since it's ppc specific), but it's still wrong:
if (firmware->header.length != fw->size) {
compare to the firmware loader:
length = be32_to_cpu(hdr->length);
2) drivers/soc/fsl/qe/qe.c does not perform bounds checking on the
per-microcode offsets, so the uploader might send data outside the
firmware buffer. Perhaps:
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 447146861c2c..c4e0bc452f03 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -451,6 +451,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
size_t calc_size = sizeof(struct qe_firmware);
size_t length;
const struct qe_header *hdr;
+ void *firmware_end;
if (!firmware) {
printk(KERN_ERR "qe-firmware: invalid pointer\n");
@@ -491,19 +492,39 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
calc_size += sizeof(__be32) *
be32_to_cpu(firmware->microcode[i].count);
- /* Validate the length */
+ /* Validate total length */
if (length != calc_size + sizeof(__be32)) {
printk(KERN_ERR "qe-firmware: invalid length\n");
return -EPERM;
}
/* Validate the CRC */
- crc = be32_to_cpu(*(__be32 *)((void *)firmware + calc_size));
+ firmware_end = (void *)firmware + calc_size;
+ crc = be32_to_cpu(*(__be32 *)firmware_end);
if (crc != crc32(0, firmware, calc_size)) {
printk(KERN_ERR "qe-firmware: firmware CRC is invalid\n");
return -EIO;
}
+ /* Validate ucode lengths and offsets */
+ for (i = 0; i < firmware->count; i++) {
+ const struct qe_microcode *ucode = &firmware->microcode[i];
+ __be32 *code;
+ size_t count;
+
+ if (!ucode->code_offset)
+ continue;
+
+ code = (void *)firmware + be32_to_cpu(ucode->code_offset);
+ count = be32_to_cpu(ucode->count) * sizeof(*code);
+
+ if (code < firmware || code >= firmware_end ||
+ code + count < firmware || code + count >= firmware_end) {
+ printk(KERN_ERR "qe-firmware: invalid ucode offset\n");
+ return -EIO;
+ }
+ }
+
/*
* If the microcode calls for it, split the I-RAM.
*/
I haven't tested this.
--
Kees Cook
_______________________________________________
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 v5 0/1] Add rga to rk322x device tree
From: Heiko Stuebner @ 2020-05-18 22:52 UTC (permalink / raw)
To: Mark Rutland, Justin Swartz, Rob Herring
Cc: devicetree, linux-rockchip, Heiko Stuebner, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200419125134.29923-1-justin.swartz@risingedge.co.za>
On Sun, 19 Apr 2020 12:51:32 +0000, Justin Swartz wrote:
> This patchset aims to enable use of Rockchip's RGA, a 2D raster
> graphic acceleration unit, on rk322x based devices.
>
> Changes in v5:
> - Remove the patch to rockchip-rga device tree binding documentation
> as Johan Jonker has already included mention of "rockchip,rk3228-rga"
> since the conversion to YAML.
>
> [...]
Applied, thanks!
[1/1] ARM: dts: rockchip: add rga node for rk322x
commit: 54b1a4e070330c3fba5becfb0b619bf360bc2657
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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: dts: rockchip: add bus-width properties to mmc nodes for px30.dtsi
From: Heiko Stuebner @ 2020-05-18 22:42 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
In-Reply-To: <20200416183053.6045-1-jbx6244@gmail.com>
On Thu, 16 Apr 2020 20:30:53 +0200, Johan Jonker wrote:
> 'bus-width' and pinctrl containing the bus-pins
> should be in the same file, so add them to
> all mmc nodes in 'px30.dtsi'.
Applied, thanks!
[1/1] arm64: dts: rockchip: add bus-width properties to mmc nodes for px30
commit: fb0ab17f1ab750d9662ec6b9fb3aa541a8ac1f5c
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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] ARM: dts: enable WLAN for Mecer Xtreme Mini S6
From: Heiko Stuebner @ 2020-05-18 22:42 UTC (permalink / raw)
To: Rob Herring, Justin Swartz, Mark Rutland
Cc: devicetree, linux-rockchip, Heiko Stuebner, linux-arm-kernel,
linux-kernel
In-Reply-To: <20200406135006.23759-1-justin.swartz@risingedge.co.za>
On Mon, 6 Apr 2020 13:50:04 +0000, Justin Swartz wrote:
> The Mecer Xtreme Mini S6 features a wireless module, based on a
> Realtek 8723BS, which provides WLAN and Bluetooth connectivity via
> SDIO and UART interfaces respectively.
>
> Define a simple MMC power sequence that declares the GPIO pins
> connected to the module's WLAN Disable and Bluetooth Disable pins
> as active low reset signals, because both signals must be deasserted
> for WLAN radio operation.
>
> [...]
Applied, thanks!
[1/1] ARM: dts: enable WLAN for Mecer Xtreme Mini S6
commit: 6067ec2c7ffacab4689ddfed3df74a467d112efe
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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] ARM: dts: remove disable-wp from rk3229-xms6 emmc
From: Heiko Stübner @ 2020-05-18 22:42 UTC (permalink / raw)
To: Justin Swartz
Cc: Mark Rutland, devicetree, linux-kernel, linux-rockchip,
Rob Herring, linux-arm-kernel
In-Reply-To: <20200406135006.23759-2-justin.swartz@risingedge.co.za>
Am Montag, 6. April 2020, 15:50:05 CEST schrieb Justin Swartz:
> Remove the disable-wp attribute from &emmc as it is, according to
> Documentation/devicetree/bindings/mmc/mmc-controller.yaml:
>
> "Not used in combination with eMMC or SDIO."
>
> Suggested-by: Johan Jonker <jbx6244@gmail.com>
> Signed-off-by: Justin Swartz <justin.swartz@risingedge.co.za>
applied for 5.8
_______________________________________________
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] dt-bindings: reset: Convert i.MX7 reset to json-schema
From: Rob Herring @ 2020-05-18 22:42 UTC (permalink / raw)
To: Anson Huang
Cc: devicetree, Philipp Zabel, Andrey Smirnov, Shawn Guo,
Sascha Hauer, linux-kernel@vger.kernel.org, NXP Linux Team,
Sascha Hauer, Fabio Estevam,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <1589198262-21372-1-git-send-email-Anson.Huang@nxp.com>
On Mon, May 11, 2020 at 6:07 AM Anson Huang <Anson.Huang@nxp.com> wrote:
>
> Convert the i.MX7 reset binding to DT schema format using json-schema.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - Improve description;
> - Remove i.MX8MM and i.MX8MN compatible, they use i.MX8MQ's compatible;
> - Keep original author as maintainer;
> - Remove unnecessary "..." at the end of file.
> ---
> .../devicetree/bindings/reset/fsl,imx7-src.txt | 56 ---------------------
> .../devicetree/bindings/reset/fsl,imx7-src.yaml | 58 ++++++++++++++++++++++
> 2 files changed, 58 insertions(+), 56 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/reset/fsl,imx7-src.txt
> create mode 100644 Documentation/devicetree/bindings/reset/fsl,imx7-src.yaml
I'd apply but doesn't apply cleanly to my tree, so:
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
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] arm64: dts: qcom: sc7180: Support ETMv4 power management
From: Bjorn Andersson @ 2020-05-18 22:35 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: devicetree, Mathieu Poirier, Suzuki K Poulose, linux-arm-msm,
coresight, linux-kernel, Rob Herring, Stephen Boyd, Andy Gross,
linux-arm-kernel, Mike Leach
In-Reply-To: <badc88ecd5932033235ed9bcd173ea16@codeaurora.org>
On Mon 18 May 12:08 PDT 2020, Sai Prakash Ranjan wrote:
> Hi Bjorn,
>
> On 2020-05-19 00:21, Bjorn Andersson wrote:
> > On Fri 15 May 03:55 PDT 2020, Sai Prakash Ranjan wrote:
>
> [...]
>
> > >
> > >
> > > The previous version of this patch in QCOM tree seems to have added
> > > the
> > > property to replicator node instead of etm7 node, can you please drop
> > > that from the tree and apply this one?
> > >
> >
> > I'm not able to replace the old commit without rewriting the history of
> > the branch. So I've applied a patch ontop of the branch to fix this up
> > instead.
> >
> > Please review the branch and let me know if there's any issues.
> >
>
> Thanks for the patch, I checked the branch and its good.
> Sorry, I should have sent a patch on top of the old one
> instead of repost.
>
No worries, now you know for next time. Thanks confirming my fix.
Thanks,
Bjorn
_______________________________________________
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/cpuinfo: Move HWCAP name arrays alongside their bit definitions
From: Will Deacon @ 2020-05-18 22:35 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, Suzuki K Poulose, Catalin Marinas, linux-kernel,
Ard Biesheuvel, Mark Brown, Dave Martin, linux-arm-kernel
In-Reply-To: <8ddd0ca5-07c9-3a99-2ec6-4a201725ebe8@arm.com>
On Fri, May 15, 2020 at 08:58:05AM +0530, Anshuman Khandual wrote:
> On 05/14/2020 01:06 PM, Will Deacon wrote:
> > Why is it a change? We've never reported e.g. "java" on an arm64 kernel, so
>
> We already have "java" defined in existing compat_hwcap_str[] array even
> though it might never get set in compat_elf_hwcap. AFAICS, compat_elf_hwcap
> will have the following capabilities set (at the most).
>
> Via COMPAT_ELF_HWCAP_DEFAULT
>
> 01. COMPAT_HWCAP_HALF
> 02. COMPAT_HWCAP_THUMB
> 03. COMPAT_HWCAP_FAST_MULT
> 04. COMPAT_HWCAP_EDSP
> 05. COMPAT_HWCAP_TLS
> 06. COMPAT_HWCAP_IDIV
> 07. COMPAT_HWCAP_LPAE
>
> Via setup_elf_hwcaps(compat_elf_hwcaps) <-- setup_cpu_features()
>
> 8. COMPAT_HWCAP_NEON
> 9. COMPAT_HWCAP_VFPv4
> 10. COMPAT_HWCAP_VFP
> 11. COMPAT_HWCAP_VFPv3
>
> Via arch_timer_set_evtstrm_feature()
>
> 12. COMPAT_HWCAP_EVTSTRM
>
> The code exists for "java" string to be displayed with /proc/cpuinfo but it
> may never get triggered as compat_elf_hwcap will never have JAVA capability
> unless there is a bug as you had rightly mentioned.
Fair enough, but applying this patch causes a *tonne* of warnings from
aiaiai:
+In file included from arch/arm64/include/asm/cpufeature.h:11,
+ from arch/arm64/include/asm/ptrace.h:11,
+ from arch/arm64/include/asm/irqflags.h:10,
+ from include/linux/irqflags.h:16,
+ from include/linux/spinlock.h:54,
+ from include/linux/seqlock.h:36,
+ from include/linux/time.h:6,
+ from arch/arm64/include/asm/stat.h:12,
+ from include/linux/stat.h:6,
+ from include/linux/module.h:13,
+ from drivers/media/rc/keymaps/rc-imon-mce.mod.c:1:
+arch/arm64/include/asm/hwcap.h:189:26: warning: ‘compat_hwcap2_str’ defined but not used [-Wunused-const-variable=]
+ 189 | static const char *const compat_hwcap2_str[] = {
+ | ^~~~~~~~~~~~~~~~~
so I'm dropping this for now.
Will
_______________________________________________
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 3/4] arm64: dts: rockchip: remove include for irq.h
From: Heiko Stübner @ 2020-05-18 22:29 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, robh+dt, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <20200403180159.13387-3-jbx6244@gmail.com>
Hi Johan,
Am Freitag, 3. April 2020, 20:01:58 CEST schrieb Johan Jonker:
> The 'irq.h' file is already included through 'arm-gic.h',
> so remove them from all Rockchip dtsi files.
I disagree here ... we do use properties from both arm-gic.h and
the main irq.h an therefore should not rely on the arm-gic.h
"accidentially" including irq.h
Heiko
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
> arch/arm64/boot/dts/rockchip/px30.dtsi | 1 -
> arch/arm64/boot/dts/rockchip/rk3308.dtsi | 1 -
> arch/arm64/boot/dts/rockchip/rk3328.dtsi | 1 -
> arch/arm64/boot/dts/rockchip/rk3368.dtsi | 1 -
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 1 -
> 5 files changed, 5 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
> index 6f7171290..4820edc7f 100644
> --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
> @@ -6,7 +6,6 @@
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> -#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/power/px30-power.h>
> #include <dt-bindings/soc/rockchip,boot-mode.h>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3308.dtsi b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> index ac43bc3f7..a9b98555d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3308.dtsi
> @@ -7,7 +7,6 @@
> #include <dt-bindings/clock/rk3308-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> -#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/soc/rockchip,boot-mode.h>
> #include <dt-bindings/thermal/thermal.h>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> index 470783a48..175060695 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
> @@ -6,7 +6,6 @@
> #include <dt-bindings/clock/rk3328-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> -#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/power/rk3328-power.h>
> #include <dt-bindings/soc/rockchip,boot-mode.h>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> index 1ebb0eef4..f22475016 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> @@ -5,7 +5,6 @@
>
> #include <dt-bindings/clock/rk3368-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> -#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/soc/rockchip,boot-mode.h>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 0d895cff5..123b7402a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -6,7 +6,6 @@
> #include <dt-bindings/clock/rk3399-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> -#include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/power/rk3399-power.h>
> #include <dt-bindings/thermal/thermal.h>
>
_______________________________________________
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 2/2] arm64: dts: rockchip: rk3399: fix pd_tcpc0 and pd_tcpc1 node position
From: Heiko Stübner @ 2020-05-18 22:29 UTC (permalink / raw)
To: Johan Jonker, kever.yang, Caesar Wang
Cc: devicetree, robh+dt, linux-kernel, linux-arm-kernel,
linux-rockchip
In-Reply-To: <20200428203003.3318-2-jbx6244@gmail.com>
Hi Kever, Caesar,
could you double check where the type-c power-domains are located
in the power-tree, as Caesar did add them under pd_vio back in 2016.
Thanks
Heiko
Am Dienstag, 28. April 2020, 22:30:03 CEST schrieb Johan Jonker:
> The pd_tcpc0 and pd_tcpc1 nodes are currently a sub node of pd_vio.
> In the rk3399 TRM figure of the 'Power Domain Partition' and in the
> table of 'Power Domain and Voltage Domain Summary' these power domains
> are positioned directly under VD_LOGIC, so fix that in 'rk3399.dtsi'.
>
> Signed-off-by: Johan Jonker <jbx6244@gmail.com>
> ---
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> index 37279db53..a4dc1bf2e 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
> @@ -1056,6 +1056,16 @@
> clocks = <&cru HCLK_SDIO>;
> pm_qos = <&qos_sdioaudio>;
> };
> + pd_tcpc0@RK3399_PD_TCPD0 {
> + reg = <RK3399_PD_TCPD0>;
> + clocks = <&cru SCLK_UPHY0_TCPDCORE>,
> + <&cru SCLK_UPHY0_TCPDPHY_REF>;
> + };
> + pd_tcpc1@RK3399_PD_TCPD1 {
> + reg = <RK3399_PD_TCPD1>;
> + clocks = <&cru SCLK_UPHY1_TCPDCORE>,
> + <&cru SCLK_UPHY1_TCPDPHY_REF>;
> + };
> pd_usb3@RK3399_PD_USB3 {
> reg = <RK3399_PD_USB3>;
> clocks = <&cru ACLK_USB3>;
> @@ -1088,16 +1098,6 @@
> pm_qos = <&qos_isp1_m0>,
> <&qos_isp1_m1>;
> };
> - pd_tcpc0@RK3399_PD_TCPD0 {
> - reg = <RK3399_PD_TCPD0>;
> - clocks = <&cru SCLK_UPHY0_TCPDCORE>,
> - <&cru SCLK_UPHY0_TCPDPHY_REF>;
> - };
> - pd_tcpc1@RK3399_PD_TCPD1 {
> - reg = <RK3399_PD_TCPD1>;
> - clocks = <&cru SCLK_UPHY1_TCPDCORE>,
> - <&cru SCLK_UPHY1_TCPDPHY_REF>;
> - };
> pd_vo@RK3399_PD_VO {
> reg = <RK3399_PD_VO>;
> #address-cells = <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 1/6] arm64: dts: rockchip: fix phy nodename for rk3328
From: Heiko Stuebner @ 2020-05-18 22:27 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-kernel, linux-rockchip, robh+dt,
robin.murphy, linux-arm-kernel, aballier
In-Reply-To: <20200321215423.12176-1-jbx6244@gmail.com>
On Sat, 21 Mar 2020 22:54:18 +0100, Johan Jonker wrote:
> A test with the command below gives for example this error:
>
> arch/arm64/boot/dts/rockchip/rk3328-evb.dt.yaml: phy@0:
> '#phy-cells' is a required property
>
> The phy nodename is used by a phy-handle.
> The parent node is compatible with "snps,dwmac-mdio",
> so change nodename to 'ethernet-phy', for which '#phy-cells'
> is not a required property
>
> [...]
Applied, thanks!
[1/6] arm64: dts: rockchip: fix phy nodename for rk3328
commit: 8370cc5533b3baa5e0f18075ae638b050458aabd
[2/6] arm64: dts: rockchip: fix rtl8211f nodename for rk3328 Beelink A1
commit: 63834d1edb96e2016191e53444934299bbc06bb1
[3/6] arm64: dts: rockchip: fix rtl8211e nodename for rk3399-nanopi4
commit: b450d1c566bd726f93bc72a3cf3155cecebc1b75
[4/6] arm64: dts: rockchip: fix &pinctrl phy sub nodename for rk3399-nanopi4
commit: 737157f9618b40c7147cf697aec431ce9dd178a0
[5/6] arm64: dts: rockchip: fix rtl8211e nodename for rk3399-orangepi
commit: b2bb769100d49c6acbfb2756cc4748aac09209c9
[6/6] arm64: dts: rockchip: fix &pinctrl phy sub nodename for rk3399-orangepi
commit: 302a729c84b59c835f7857ec378efecbda58b9b3
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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 1/4] ARM: dts: rockchip: remove identical #include from rk3288.dtsi
From: Heiko Stuebner @ 2020-05-18 22:28 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
In-Reply-To: <20200403180159.13387-1-jbx6244@gmail.com>
On Fri, 3 Apr 2020 20:01:56 +0200, Johan Jonker wrote:
> There are 2 identical '#include' for 'rk3288-power.h',
> so remove one of them.
Applied, thanks!
[1/1] ARM: dts: rockchip: remove identical #include from rk3288.dtsi
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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 1/2] arm64: dts: rockchip: fix defines in pd_vio node for rk3399
From: Heiko Stuebner @ 2020-05-18 22:28 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
In-Reply-To: <20200428203003.3318-1-jbx6244@gmail.com>
On Tue, 28 Apr 2020 22:30:02 +0200, Johan Jonker wrote:
> A test with the command below gives for example this error:
>
> arch/arm64/boot/dts/rockchip/rk3399-evb.dt.yaml: pd_vio@15:
> 'pd_tcpc0@RK3399_PD_TCPC0', 'pd_tcpc1@RK3399_PD_TCPC1'
> do not match any of the regexes:
> '.*-names$', '.*-supply$', '^#.*-cells$',
> '^#[a-zA-Z0-9,+\\-._]{0,63}$',
> '^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}$',
> '^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-fA-F]+(,[0-9a-fA-F]+)*$',
> '^__.*__$', 'pinctrl-[0-9]+'
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: fix defines in pd_vio node for rk3399
commit: 84836ded76ec9a6f25d1d0acebaad44977e0ec6f
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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: dts: rockchip: remove disable-wp from rk3308-roc-cc emmc node
From: Heiko Stuebner @ 2020-05-18 22:27 UTC (permalink / raw)
To: Johan Jonker
Cc: mark.rutland, devicetree, Heiko Stuebner, linux-kernel,
linux-rockchip, robh+dt, linux-arm-kernel
In-Reply-To: <20191219121954.2450-1-jbx6244@gmail.com>
On Thu, 19 Dec 2019 13:19:54 +0100, Johan Jonker wrote:
> The mmc-controller.yaml didn't explicitly say disable-wp is
> for SD card slot only, but that is what it was designed for
> in the first place.
> Remove all disable-wp from emmc or sdio controllers.
Applied, thanks!
[1/1] arm64: dts: rockchip: remove disable-wp from rk3308-roc-cc emmc node
commit: 1fab4cf51e48e9525cf70a9604e90dd3dd666a2f
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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/3] arm64: dts: rockchip: replace RK_FUNC defines in rk3326-odroid-go2.dts
From: Heiko Stuebner @ 2020-05-18 22:27 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-rockchip, linus.walleij,
linux-kernel, linux-gpio, robh+dt, linux-arm-kernel
In-Reply-To: <20200512203524.7317-1-jbx6244@gmail.com>
On Tue, 12 May 2020 22:35:22 +0200, Johan Jonker wrote:
> The defines RK_FUNC_1 and RK_FUNC_2 are deprecated,
> so replace them with the preferred form.
> Restyle properties in the same line.
Applied, thanks!
[1/2] arm64: dts: rockchip: replace RK_FUNC defines in rk3326-odroid-go2
commit: 213f272b754f4e27aeab9d1265c775610e612bb7
[2/2] include: dt-bindings: rockchip: remove unused defines
commit: d09855bdd8c4d4eb6e58b8546318ebb5859a513c
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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: rockchip: fix phy nodename for rk3328
From: Heiko Stuebner @ 2020-05-18 22:28 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
In-Reply-To: <20200505170227.6503-1-jbx6244@gmail.com>
On Tue, 5 May 2020 19:02:27 +0200, Johan Jonker wrote:
> A test with the command below gives for example this error:
>
> arch/arm64/boot/dts/rockchip/rk3328-evb.dt.yaml: phy@0:
> '#phy-cells' is a required property
>
> The phy nodename is normally used by a phy-handle.
> This node is however compatible with
> "ethernet-phy-id1234.d400", "ethernet-phy-ieee802.3-c22"
> which is just been added to 'ethernet-phy.yaml'.
> So change nodename to 'ethernet-phy' for which '#phy-cells'
> is not a required property
>
> [...]
Applied, thanks!
[1/1] arm64: dts: rockchip: fix phy nodename for rk3328
commit: 8370cc5533b3baa5e0f18075ae638b050458aabd
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
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 v1 1/2] ARM: dts: rockchip: rename and label gpio-led subnodes
From: Heiko Stuebner @ 2020-05-18 22:27 UTC (permalink / raw)
To: Johan Jonker
Cc: devicetree, Heiko Stuebner, linux-kernel, linux-rockchip, robh+dt,
linux-arm-kernel
In-Reply-To: <20200428144933.10953-1-jbx6244@gmail.com>
On Tue, 28 Apr 2020 16:49:32 +0200, Johan Jonker wrote:
> Current dts files with 'gpio-led' nodes were manually verified.
> In order to automate this process leds-gpio.txt
> has been converted to yaml. With this conversion a check
> for pattern properties was added. A test with the command
> below gives a screen full of warnings like:
>
> arch/arm/boot/dts/rk3188-radxarock.dt.yaml: gpio-leds:
> 'blue', 'green', 'sleep'
> do not match any of the regexes:
> '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+'
>
> [...]
Applied, thanks!
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] soc: fsl: qe: Replace one-element array and use struct_size() helper
From: Gustavo A. R. Silva @ 2020-05-18 22:19 UTC (permalink / raw)
To: Qiang Zhao, Li Yang
Cc: Kees Cook, linuxppc-dev, linux-kernel, linux-arm-kernel,
Gustavo A. R. Silva
The current codebase makes use of one-element arrays in the following
form:
struct something {
int length;
u8 data[1];
};
struct something *instance;
instance = kmalloc(sizeof(*instance) + size, GFP_KERNEL);
instance->length = size;
memcpy(instance->data, source, size);
but the preferred mechanism to declare variable-length types such as
these ones is a flexible array member[1][2], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on. So, replace
the one-element array with a flexible-array member.
Also, make use of the new struct_size() helper to properly calculate the
size of struct qe_firmware.
This issue was found with the help of Coccinelle and, audited and fixed
_manually_.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
---
drivers/soc/fsl/qe/qe.c | 4 ++--
include/soc/fsl/qe/qe.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/soc/fsl/qe/qe.c b/drivers/soc/fsl/qe/qe.c
index 447146861c2c1..2df20d6f85fa4 100644
--- a/drivers/soc/fsl/qe/qe.c
+++ b/drivers/soc/fsl/qe/qe.c
@@ -448,7 +448,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
unsigned int i;
unsigned int j;
u32 crc;
- size_t calc_size = sizeof(struct qe_firmware);
+ size_t calc_size;
size_t length;
const struct qe_header *hdr;
@@ -480,7 +480,7 @@ int qe_upload_firmware(const struct qe_firmware *firmware)
}
/* Validate the length and check if there's a CRC */
- calc_size += (firmware->count - 1) * sizeof(struct qe_microcode);
+ calc_size = struct_size(firmware, microcode, firmware->count);
for (i = 0; i < firmware->count; i++)
/*
diff --git a/include/soc/fsl/qe/qe.h b/include/soc/fsl/qe/qe.h
index e282ac01ec081..3feddfec9f87d 100644
--- a/include/soc/fsl/qe/qe.h
+++ b/include/soc/fsl/qe/qe.h
@@ -307,7 +307,7 @@ struct qe_firmware {
u8 revision; /* The microcode version revision */
u8 padding; /* Reserved, for alignment */
u8 reserved[4]; /* Reserved, for future expansion */
- } __attribute__ ((packed)) microcode[1];
+ } __packed microcode[];
/* All microcode binaries should be located here */
/* CRC32 should be located here, after the microcode binaries */
} __attribute__ ((packed));
--
2.26.2
_______________________________________________
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