* RE: About upstreaming ArmChina NPU driver
From: Dejia Shang @ 2024-04-03 9:42 UTC (permalink / raw)
To: Sudeep Holla
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org, Toby Huang, Chengkun Sun
In-Reply-To: <20240328103205.seht2hbog3o4giv5@bogus>
> -----Original Message-----
> From: Sudeep Holla <sudeep.holla@arm.com>
> Sent: 2024年3月28日 18:32
> To: Dejia Shang <Dejia.Shang@armchina.com>
> Cc: ogabbay@kernel.org; Sudeep Holla <sudeep.holla@arm.com>;
> airlied@redhat.com; daniel@ffwll.ch; linux-kernel@vger.kernel.org;
> dri-devel@lists.freedesktop.org; linux-arm-kernel@lists.infradead.org
> Subject: Re: About upstreaming ArmChina NPU driver
>
> On Thu, Mar 28, 2024 at 07:46:01AM +0000, Dejia Shang wrote:
> > IMPORTANT NOTICE: The contents of this email and any attachments may
> > be privileged and confidential. If you are not the intended recipient,
> > please delete the email immediately. It is strictly prohibited to
> > disclose the contents to any other person, use it for any purpose, or
> > store or copy the information in any medium. Thank you. ©Arm
> > Technology (China) Co., Ltd copyright and reserve all rights.
> > 重要提示：本邮件（包括任何附件）可能含有专供明确的个人或目的
> 使用的机密信息，并受法律保护。如果您并非该收件人，请立即删除此
> 邮件。严禁通过任何
> > 渠道，以任何目的，向任何人披露、储存或复制邮件信息或者据此采
> 取任何行动。感谢您的配合。 ©安谋科技（中国）有限公司 版权所有并
> 保留一切权利。
>
> You need to get this fixed, otherwise people will delete this email as you have
> suggested and/or refrain from responding to this email.
>
> Please talk to your local IT and get a setup without this disclaimer for all
> mailing list activities.
Now fixed. I did not realize that because the server auto appended that disclaimer. Thanks for your reminder!
Best Regards,
Dejia
>
> --
> Regards,
> Sudeep
_______________________________________________
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 2/5] tee: optee: Move pool_op helper functions
From: Jens Wiklander @ 2024-04-03 9:43 UTC (permalink / raw)
To: Balint Dobszay
Cc: op-tee, linux-doc, linux-kernel, linux-arm-kernel, sumit.garg,
corbet, sudeep.holla, rdunlap, krzk, gyorgy.szing
In-Reply-To: <20240325151105.135667-3-balint.dobszay@arm.com>
Hi Balint,
On Mon, Mar 25, 2024 at 4:11 PM Balint Dobszay <balint.dobszay@arm.com> wrote:
>
> Move the pool alloc and free helper functions from the OP-TEE driver to
> the TEE subsystem, since these could be reused in other TEE drivers.
> This patch is not supposed to change behavior, it's only reorganizing
> the code.
>
> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
> Suggested-by: Jens Wiklander <jens.wiklander@linaro.org>
> Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>
> ---
> drivers/tee/optee/core.c | 64 -------------------------------
> drivers/tee/optee/ffa_abi.c | 6 +--
> drivers/tee/optee/optee_private.h | 12 ------
> drivers/tee/optee/smc_abi.c | 9 ++---
> drivers/tee/tee_shm.c | 64 +++++++++++++++++++++++++++++++
> include/linux/tee_core.h | 10 +++++
> 6 files changed, 81 insertions(+), 84 deletions(-)
This patch fails to build on x86_64:
CC [M] drivers/tee/tee_shm.o
drivers/tee/tee_shm.c: In function ‘tee_dyn_shm_alloc_helper’:
linux/drivers/tee/tee_shm.c:226:22: error: implicit declaration of
function ‘virt_to_phys’; did you mean ‘virt_to_page’?
[-Werror=implicit-function-declaration]
226 | shm->paddr = virt_to_phys(shm->kaddr);
| ^~~~~~~~~~~~
| virt_to_page
It's fixed by adding
#include <linux/io.h>
I'll fix up the patch if you agree with the fix.
Cheers,
Jens
>
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index f762e3a25119..39e688d4e974 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -9,7 +9,6 @@
> #include <linux/crash_dump.h>
> #include <linux/errno.h>
> #include <linux/io.h>
> -#include <linux/mm.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> #include <linux/string.h>
> @@ -17,69 +16,6 @@
> #include <linux/types.h>
> #include "optee_private.h"
>
> -int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
> - size_t size, size_t align,
> - int (*shm_register)(struct tee_context *ctx,
> - struct tee_shm *shm,
> - struct page **pages,
> - size_t num_pages,
> - unsigned long start))
> -{
> - size_t nr_pages = roundup(size, PAGE_SIZE) / PAGE_SIZE;
> - struct page **pages;
> - unsigned int i;
> - int rc = 0;
> -
> - /*
> - * Ignore alignment since this is already going to be page aligned
> - * and there's no need for any larger alignment.
> - */
> - shm->kaddr = alloc_pages_exact(nr_pages * PAGE_SIZE,
> - GFP_KERNEL | __GFP_ZERO);
> - if (!shm->kaddr)
> - return -ENOMEM;
> -
> - shm->paddr = virt_to_phys(shm->kaddr);
> - shm->size = nr_pages * PAGE_SIZE;
> -
> - pages = kcalloc(nr_pages, sizeof(*pages), GFP_KERNEL);
> - if (!pages) {
> - rc = -ENOMEM;
> - goto err;
> - }
> -
> - for (i = 0; i < nr_pages; i++)
> - pages[i] = virt_to_page((u8 *)shm->kaddr + i * PAGE_SIZE);
> -
> - shm->pages = pages;
> - shm->num_pages = nr_pages;
> -
> - if (shm_register) {
> - rc = shm_register(shm->ctx, shm, pages, nr_pages,
> - (unsigned long)shm->kaddr);
> - if (rc)
> - goto err;
> - }
> -
> - return 0;
> -err:
> - free_pages_exact(shm->kaddr, shm->size);
> - shm->kaddr = NULL;
> - return rc;
> -}
> -
> -void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
> - int (*shm_unregister)(struct tee_context *ctx,
> - struct tee_shm *shm))
> -{
> - if (shm_unregister)
> - shm_unregister(shm->ctx, shm);
> - free_pages_exact(shm->kaddr, shm->size);
> - shm->kaddr = NULL;
> - kfree(shm->pages);
> - shm->pages = NULL;
> -}
> -
> static void optee_bus_scan(struct work_struct *work)
> {
> WARN_ON(optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP));
> diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c
> index cee8ccb84cb8..3235e1c719e8 100644
> --- a/drivers/tee/optee/ffa_abi.c
> +++ b/drivers/tee/optee/ffa_abi.c
> @@ -374,14 +374,14 @@ static int optee_ffa_shm_unregister_supp(struct tee_context *ctx,
> static int pool_ffa_op_alloc(struct tee_shm_pool *pool,
> struct tee_shm *shm, size_t size, size_t align)
> {
> - return optee_pool_op_alloc_helper(pool, shm, size, align,
> - optee_ffa_shm_register);
> + return tee_dyn_shm_alloc_helper(shm, size, align,
> + optee_ffa_shm_register);
> }
>
> static void pool_ffa_op_free(struct tee_shm_pool *pool,
> struct tee_shm *shm)
> {
> - optee_pool_op_free_helper(pool, shm, optee_ffa_shm_unregister);
> + tee_dyn_shm_free_helper(shm, optee_ffa_shm_unregister);
> }
>
> static void pool_ffa_op_destroy_pool(struct tee_shm_pool *pool)
> diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
> index a0698ac18993..429cc20be5cc 100644
> --- a/drivers/tee/optee/optee_private.h
> +++ b/drivers/tee/optee/optee_private.h
> @@ -283,18 +283,6 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session);
> int optee_enumerate_devices(u32 func);
> void optee_unregister_devices(void);
>
> -int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
> - size_t size, size_t align,
> - int (*shm_register)(struct tee_context *ctx,
> - struct tee_shm *shm,
> - struct page **pages,
> - size_t num_pages,
> - unsigned long start));
> -void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
> - int (*shm_unregister)(struct tee_context *ctx,
> - struct tee_shm *shm));
> -
> -
> void optee_remove_common(struct optee *optee);
> int optee_open(struct tee_context *ctx, bool cap_memref_null);
> void optee_release(struct tee_context *ctx);
> diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
> index 9c296b887dc1..734c484ed0f6 100644
> --- a/drivers/tee/optee/smc_abi.c
> +++ b/drivers/tee/optee/smc_abi.c
> @@ -592,19 +592,18 @@ static int pool_op_alloc(struct tee_shm_pool *pool,
> * to be registered with OP-TEE.
> */
> if (shm->flags & TEE_SHM_PRIV)
> - return optee_pool_op_alloc_helper(pool, shm, size, align, NULL);
> + return tee_dyn_shm_alloc_helper(shm, size, align, NULL);
>
> - return optee_pool_op_alloc_helper(pool, shm, size, align,
> - optee_shm_register);
> + return tee_dyn_shm_alloc_helper(shm, size, align, optee_shm_register);
> }
>
> static void pool_op_free(struct tee_shm_pool *pool,
> struct tee_shm *shm)
> {
> if (!(shm->flags & TEE_SHM_PRIV))
> - optee_pool_op_free_helper(pool, shm, optee_shm_unregister);
> + tee_dyn_shm_free_helper(shm, optee_shm_unregister);
> else
> - optee_pool_op_free_helper(pool, shm, NULL);
> + tee_dyn_shm_free_helper(shm, NULL);
> }
>
> static void pool_op_destroy_pool(struct tee_shm_pool *pool)
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 96a45c817427..5bf76c35cd9e 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -202,6 +202,70 @@ struct tee_shm *tee_shm_alloc_priv_buf(struct tee_context *ctx, size_t size)
> }
> EXPORT_SYMBOL_GPL(tee_shm_alloc_priv_buf);
>
> +int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align,
> + int (*shm_register)(struct tee_context *ctx,
> + struct tee_shm *shm,
> + struct page **pages,
> + size_t num_pages,
> + unsigned long start))
> +{
> + size_t nr_pages = roundup(size, PAGE_SIZE) / PAGE_SIZE;
> + struct page **pages;
> + unsigned int i;
> + int rc = 0;
> +
> + /*
> + * Ignore alignment since this is already going to be page aligned
> + * and there's no need for any larger alignment.
> + */
> + shm->kaddr = alloc_pages_exact(nr_pages * PAGE_SIZE,
> + GFP_KERNEL | __GFP_ZERO);
> + if (!shm->kaddr)
> + return -ENOMEM;
> +
> + shm->paddr = virt_to_phys(shm->kaddr);
> + shm->size = nr_pages * PAGE_SIZE;
> +
> + pages = kcalloc(nr_pages, sizeof(*pages), GFP_KERNEL);
> + if (!pages) {
> + rc = -ENOMEM;
> + goto err;
> + }
> +
> + for (i = 0; i < nr_pages; i++)
> + pages[i] = virt_to_page((u8 *)shm->kaddr + i * PAGE_SIZE);
> +
> + shm->pages = pages;
> + shm->num_pages = nr_pages;
> +
> + if (shm_register) {
> + rc = shm_register(shm->ctx, shm, pages, nr_pages,
> + (unsigned long)shm->kaddr);
> + if (rc)
> + goto err;
> + }
> +
> + return 0;
> +err:
> + free_pages_exact(shm->kaddr, shm->size);
> + shm->kaddr = NULL;
> + return rc;
> +}
> +EXPORT_SYMBOL_GPL(tee_dyn_shm_alloc_helper);
> +
> +void tee_dyn_shm_free_helper(struct tee_shm *shm,
> + int (*shm_unregister)(struct tee_context *ctx,
> + struct tee_shm *shm))
> +{
> + if (shm_unregister)
> + shm_unregister(shm->ctx, shm);
> + free_pages_exact(shm->kaddr, shm->size);
> + shm->kaddr = NULL;
> + kfree(shm->pages);
> + shm->pages = NULL;
> +}
> +EXPORT_SYMBOL_GPL(tee_dyn_shm_free_helper);
> +
> static struct tee_shm *
> register_shm_helper(struct tee_context *ctx, struct iov_iter *iter, u32 flags,
> int id)
> diff --git a/include/linux/tee_core.h b/include/linux/tee_core.h
> index d9b3ba8e8fa9..efd16ed52315 100644
> --- a/include/linux/tee_core.h
> +++ b/include/linux/tee_core.h
> @@ -232,6 +232,16 @@ void *tee_get_drvdata(struct tee_device *teedev);
> */
> struct tee_shm *tee_shm_alloc_priv_buf(struct tee_context *ctx, size_t size);
>
> +int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align,
> + int (*shm_register)(struct tee_context *ctx,
> + struct tee_shm *shm,
> + struct page **pages,
> + size_t num_pages,
> + unsigned long start));
> +void tee_dyn_shm_free_helper(struct tee_shm *shm,
> + int (*shm_unregister)(struct tee_context *ctx,
> + struct tee_shm *shm));
> +
> /**
> * tee_shm_is_dynamic() - Check if shared memory object is of the dynamic kind
> * @shm: Shared memory handle
> --
> 2.34.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: [report] WARN_ON_ONCE triggered in for_each_sibling_event()
From: Mark Rutland @ 2024-04-03 9:48 UTC (permalink / raw)
To: Zenghui Yu
Cc: linux-perf-users, linux-kernel, peterz, mingo, acme, namhyung,
will, alexander.shishkin, jolsa, irogers, adrian.hunter,
wanghaibin.wang, linux-arm-kernel
In-Reply-To: <d4491035-9f9c-d3c2-bd26-a5133d8233fe@huawei.com>
On Thu, Mar 28, 2024 at 06:06:21PM +0800, Zenghui Yu wrote:
> Hi folks,
Hi Zenghui,
> The following splat is triggered when I execute `perf stat -e
> smmuv3_pmcg_100020/config_cache_miss/` on mainline kernel (built with
> arm64-defconfig + PROVE_LOCKING).
>
> | ------------[ cut here ]------------
> | WARNING: CPU: 36 PID: 72452 at drivers/perf/arm_smmuv3_pmu.c:434
> smmu_pmu_event_init+0x298/0x2b0 [arm_smmuv3_pmu]
> | Modules linked in: xt_MASQUERADE iptable_nat xt_addrtype xt_conntrack
> nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c overlay
> ip6table_filter ip6_tables xt_tcpudp iptable_filter ip_tables x_tables
> md_mod arm_smmuv3_pmu hibmc_drm drm_vram_helper drm_ttm_helper ttm
> drm_kms_helper spi_dw_mmio spi_dw fuse drm backlight crct10dif_ce
> onboard_usb_hub xhci_pci xhci_pci_renesas hisi_sec2 hisi_qm uacce authenc
> ipmi_si ipmi_devintf ipmi_msghandler dm_mod br_netfilter bridge stp llc nvme
> nvme_core nbd ipv6
> | CPU: 36 PID: 72452 Comm: perf Kdump: loaded Not tainted
> 6.9.0-rc1-00061-g8d025e2092e2-dirty #1700
> | Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.05 09/18/2019
> | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> | pc : smmu_pmu_event_init+0x298/0x2b0 [arm_smmuv3_pmu]
> | lr : smmu_pmu_event_init+0x290/0x2b0 [arm_smmuv3_pmu]
> | sp : ffff8000c8ce3be0
> | x29: ffff8000c8ce3be0 x28: 0000000000000000 x27: ffff8000802a2c1c
> | x26: ffff8000c8ce3d70 x25: ffff8000802a2bc8 x24: 0000000000000000
> | x23: 0000000000000001 x22: ffff0028045d52b0 x21: ffff002807228168
> | x20: 0000000000000002 x19: ffff002807228000 x18: 0000000000000000
> | x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
> | x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000040
> | x11: ffff0020804016d0 x10: ffff0020804016d2 x9 : ffff800083b29b18
> | x8 : ffff0020804016f8 x7 : 0000000000000000 x6 : ffff0020804018c0
> | x5 : ffff0020804016d0 x4 : ffff80007bf07a58 x3 : 0000000000000002
> | x2 : ffff802f5db37000 x1 : 0000000000000000 x0 : 0000000000000000
> | Call trace:
> | smmu_pmu_event_init+0x298/0x2b0 [arm_smmuv3_pmu]
> | perf_try_init_event+0x54/0x140| perf_event_alloc+0x3e4/0x1080
> | __do_sys_perf_event_open+0x178/0xfa8
> | __arm64_sys_perf_event_open+0x28/0x34
> | invoke_syscall+0x48/0x114
> | el0_svc_common.constprop.0+0x40/0xe0
> | do_el0_svc+0x1c/0x28
> | el0_svc+0x4c/0x11c
> | el0t_64_sync_handler+0xc0/0xc4
> | el0t_64_sync+0x190/0x194
> | irq event stamp: 174338
> | hardirqs last enabled at (174337): [<ffff800080357774>]
> ___slab_alloc+0x3bc/0xf38
> | hardirqs last disabled at (174338): [<ffff8000812a7ee0>] el1_dbg+0x24/0x8c
> | softirqs last enabled at (174292): [<ffff8000800185bc>]
> fpsimd_restore_current_state+0x34/0xc4
> | softirqs last disabled at (174290): [<ffff80008001858c>]
> fpsimd_restore_current_state+0x4/0xc4
> | ---[ end trace 0000000000000000 ]---
>
> Note that this is not specific to the arm_smmuv3_pmu driver as I can
> also reproduce it with some HiSilicon uncore PMU events (e.g., executing
> `perf stat -e hisi_sccl1_ddrc0/flux_rd/`).
>
> For your convenience, the assertion was added by commit f3c0eba28704
> ("perf: Add a few assertions").
>
> Post it out for visibility, not sure if there are already similar
> reports on the list though. Please have a look.
Thanks for the report!
This is indeed a regression caused by commit:
f3c0eba28704 ("perf: Add a few assertions")
... and it's concerning that we haven't had a report until now; we're clearly
not testing system/uncore PMUs all that much. :/
I don't want to remove the assertion, since that will catch missed locking that
has been the source of a number of nasty bugs.
I think we have to update all PMU drivers to avoid for_each_sibling_event()
when event == group_leader. That's the established practice in CPU PMU drivers,
and with that done I believe that we can tighten the requirements such that
for_each_sibling_event() can *only* be called for a group leader, which would
catch unintentional misuse in the core code.
Looking around, I see some other (related) problems in group validation in some
PMU drivers, so I'll spin a series to address those in one go. I'll try to get
that out in the next few days.
Mark.
_______________________________________________
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 03/18] PCI: endpoint: Introduce pci_epc_mem_map()/unmap()
From: Manivannan Sadhasivam @ 2024-04-03 9:48 UTC (permalink / raw)
To: Damien Le Moal
Cc: Lorenzo Pieralisi, Kishon Vijay Abraham I, Shawn Lin,
Krzysztof Wilczyński, Bjorn Helgaas, Heiko Stuebner,
linux-pci, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, linux-rockchip, linux-arm-kernel, Rick Wertenbroek,
Wilfred Mallawa, Niklas Cassel
In-Reply-To: <20240330041928.1555578-4-dlemoal@kernel.org>
On Sat, Mar 30, 2024 at 01:19:13PM +0900, Damien Le Moal wrote:
> Introduce the function pci_epc_mem_map() to facilitate controller memory
> address allocation and mapping to a RC PCI address region in endpoint
> function drivers.
>
> This function first uses pci_epc_map_align() to determine the controller
> memory address alignment (offset and size) constraints. The result of
> this function is used to allocate a controller physical memory region
> using pci_epc_mem_alloc_addr() and map it to the RC PCI address
> space with pci_epc_map_addr(). Since pci_epc_map_align() may indicate
> that a mapping can be smaller than the requested size, pci_epc_mem_map()
> may only partially map the RC PCI address region specified and return
> a smaller size for the effective mapping.
>
> The counterpart of pci_epc_mem_map() to unmap and free the controller
> memory address region is pci_epc_mem_unmap().
>
> Both functions operate using struct pci_epc_map data structure which is
> extended to contain the physical and virtual addresses of the allocated
> controller memory. Endpoint function drivers can use struct pci_epc_map
> to implement read/write accesses within the mapped RC PCI address region
> using the ->virt_addr and ->size fields.
>
> This commit contains contributions from Rick Wertenbroek
> <rick.wertenbroek@gmail.com>.
>
Adding 'Co-developed-by && Signed-off-by' tags would give the due credit.
> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
> drivers/pci/endpoint/pci-epc-core.c | 68 +++++++++++++++++++++++++++++
> include/linux/pci-epc.h | 6 +++
> 2 files changed, 74 insertions(+)
>
> diff --git a/drivers/pci/endpoint/pci-epc-core.c b/drivers/pci/endpoint/pci-epc-core.c
> index 37758ca91d7f..0095b54bdf9e 100644
> --- a/drivers/pci/endpoint/pci-epc-core.c
> +++ b/drivers/pci/endpoint/pci-epc-core.c
> @@ -530,6 +530,74 @@ int pci_epc_map_addr(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> }
> EXPORT_SYMBOL_GPL(pci_epc_map_addr);
>
> +/**
> + * pci_epc_mem_map() - allocate and map CPU address to PCI address
How about, 'pci_epc_alloc_map()'? I think the 'mem' prefix was added to the
existing APIs since the function definitions are in pci-epc-mem driver, but
not needed here.
> + * @epc: the EPC device on which the CPU address is to be allocated and mapped
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @pci_addr: PCI address to which the CPU address should be mapped
> + * @size: the number of bytes to map starting from @pci_addr
> + * @map: where to return the mapping information
> + *
> + * Allocate a controller physical address region and map it to a RC PCI address
"Allocate an EPC address space region..."
> + * region, taking into account the controller physical address mapping
> + * constraints (if any). Returns the effective size of the mapping, which may
Return value should be specified separately for Kdoc.
> + * be less than @size, or a negative error code in case of error.
> + */
> +ssize_t pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> + u64 pci_addr, size_t size, struct pci_epc_map *map)
> +{
> + int ret;
> +
> + ret = pci_epc_map_align(epc, func_no, vfunc_no, pci_addr, size, map);
> + if (ret)
> + return ret;
> +
> + map->virt_base = pci_epc_mem_alloc_addr(epc, &map->phys_base,
> + map->map_size);
It'd be nice to move pci_epc_map_align() inside the existing
pci_epc_mem_alloc_addr() API to make sure that the allocated memory follows the
constraints of the EPC.
Would that make sense?
- Mani
> + if (!map->virt_base)
> + return -ENOMEM;
> +
> + map->phys_addr = map->phys_base + map->map_ofst;
> + map->virt_addr = map->virt_base + map->map_ofst;
> +
> + ret = pci_epc_map_addr(epc, func_no, vfunc_no, map->phys_base,
> + map->map_pci_addr, map->map_size);
> + if (ret) {
> + pci_epc_mem_free_addr(epc, map->phys_base, map->virt_base,
> + map->map_size);
> + return ret;
> + }
> +
> + return map->pci_size;
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_map);
> +
> +/**
> + * pci_epc_mem_unmap() - unmap from PCI address and free a CPU address region
> + * @epc: the EPC device on which the CPU address is allocated and mapped
> + * @func_no: the physical endpoint function number in the EPC device
> + * @vfunc_no: the virtual endpoint function number in the physical function
> + * @map: the mapping information
> + *
> + * Allocate and map local CPU address to a PCI address, accounting for the
> + * controller local CPU address alignment constraints.
> + */
> +void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> + struct pci_epc_map *map)
> +{
> + if (!pci_epc_function_is_valid(epc, func_no, vfunc_no))
> + return;
> +
> + if (!map || !map->pci_size)
> + return;
> +
> + pci_epc_unmap_addr(epc, func_no, vfunc_no, map->phys_base);
> + pci_epc_mem_free_addr(epc, map->phys_base, map->virt_base,
> + map->map_size);
> +}
> +EXPORT_SYMBOL_GPL(pci_epc_mem_unmap);
> +
> /**
> * pci_epc_clear_bar() - reset the BAR
> * @epc: the EPC device for which the BAR has to be cleared
> diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
> index 8cfb4aaf2628..86397a500b54 100644
> --- a/include/linux/pci-epc.h
> +++ b/include/linux/pci-epc.h
> @@ -304,4 +304,10 @@ void __iomem *pci_epc_mem_alloc_addr(struct pci_epc *epc,
> phys_addr_t *phys_addr, size_t size);
> void pci_epc_mem_free_addr(struct pci_epc *epc, phys_addr_t phys_addr,
> void __iomem *virt_addr, size_t size);
> +
> +ssize_t pci_epc_mem_map(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> + u64 pci_addr, size_t size, struct pci_epc_map *map);
> +void pci_epc_mem_unmap(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> + struct pci_epc_map *map);
> +
> #endif /* __LINUX_PCI_EPC_H */
> --
> 2.44.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] arm64: dts: ls1028a: sl28: split variant 3/ads2 carrier
From: Michael Walle @ 2024-04-03 8:38 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Michael Walle
The devicetree files can be (re-)used in u-boot now, they are imported
on a regular basis (see OF_UPSTREAM option) there. Up until now, it
didn't matter for linux and there was just a combined devicetree
"-var3-ads2" (with ads2 being the carrier board). But if the devicetree
files are now reused in u-boot, we need to have an individual "-var3"
variant, because the bootloader is just using the bare "varN" devicetree
files. Split the "var3" off of the "-var3-ads2" devicetree.
Signed-off-by: Michael Walle <mwalle@kernel.org>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../fsl-ls1028a-kontron-sl28-var3-ads2.dts | 2 +-
.../fsl-ls1028a-kontron-sl28-var3.dts | 18 ++++++++++++++++++
3 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 045250d0a040..9319791f298c 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -9,6 +9,7 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-kbox-a-230-ls.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var1.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var2.dtb
+dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var3.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var3-ads2.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-kontron-sl28-var4.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-ls1028a-qds.dtb
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
index ed4e69e87e30..195bdbafdf7c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3-ads2.dts
@@ -10,7 +10,7 @@
/dts-v1/;
#include <dt-bindings/clock/fsl,qoriq-clockgen.h>
-#include "fsl-ls1028a-kontron-sl28.dts"
+#include "fsl-ls1028a-kontron-sl28-var3.dts"
/ {
model = "Kontron SMARC-sAL28 (Single PHY) on SMARC Eval 2.0 carrier";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
new file mode 100644
index 000000000000..08851ca407a8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var3.dts
@@ -0,0 +1,18 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Device Tree file for the Kontron SMARC-sAL28 board.
+ *
+ * This is for the network variant 3 which has one ethernet ports.
+ *
+ * Copyright (C) 2024 Michael Walle <michael@walle.cc>
+ *
+ */
+
+/dts-v1/;
+
+#include "fsl-ls1028a-kontron-sl28.dts"
+
+/ {
+ model = "Kontron SMARC-sAL28 (Single PHY)";
+ compatible = "kontron,sl28-var3", "kontron,sl28", "fsl,ls1028a";
+};
--
2.39.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
* Re: [PATCH 07/34] Input: stmpe-ts - mark OF related data as maybe unused
From: Krzysztof Kozlowski @ 2024-04-03 9:52 UTC (permalink / raw)
To: Andy Shevchenko, Arnd Bergmann
Cc: linux-kernel, Dmitry Torokhov, Maxime Coquelin, Alexandre Torgue,
Arnd Bergmann, Uwe Kleine-König, linux-input, linux-stm32,
linux-arm-kernel
In-Reply-To: <Zg0kC6uYFOi-UGXl@smile.fi.intel.com>
On 03/04/2024 11:40, Andy Shevchenko wrote:
> On Wed, Apr 03, 2024 at 10:06:25AM +0200, Arnd Bergmann wrote:
>> From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>
>> When compile tested with W=1 on x86_64 with driver as built-in:
>>
>> stmpe-ts.c:371:34: error: unused variable 'stmpe_ts_ids' [-Werror,-Wunused-const-variable]
>
> ...
>
>> -static const struct of_device_id stmpe_ts_ids[] = {
>> +static const struct of_device_id stmpe_ts_ids[] __maybe_unused = {
>
> __maybe_unused?
>
> Why not adding it into .driver as you have done in another patch in this series?
Because there is no benefit in this. This is instantiated by MFD, so the
only thing you need is entry for module loading.
Best regards,
Krzysztof
_______________________________________________
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 v5 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: ChunHau Tan @ 2024-04-03 9:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Emil Renner Berthing, Krzysztof Kozlowski, Conor Dooley,
Maxime Coquelin, Alexandre Torgue, Simon Horman,
Bartosz Golaszewski, Andrew Halaney, Jisheng Zhang,
Uwe Kleine-König, Russell King, Leyfoon Tan, JeeHeng Sia,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-riscv@lists.infradead.org
In-Reply-To: <20240328204202.GA308290-robh@kernel.org>
> -----Original Message-----
> From: Rob Herring <robh@kernel.org>
> Sent: Friday, 29 March, 2024 4:42 AM
> To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Cc: ChunHau Tan <chunhau.tan@starfivetech.com>; David S . Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>; Emil Renner
> Berthing <kernel@esmil.dk>; Krzysztof Kozlowski
> <krzysztof.kozlowski+dt@linaro.org>; Conor Dooley <conor+dt@kernel.org>;
> Maxime Coquelin <mcoquelin.stm32@gmail.com>; Alexandre Torgue
> <alexandre.torgue@foss.st.com>; Simon Horman <horms@kernel.org>; Bartosz
> Golaszewski <bartosz.golaszewski@linaro.org>; Andrew Halaney
> <ahalaney@redhat.com>; Jisheng Zhang <jszhang@kernel.org>; Uwe
> Kleine-König <u.kleine-koenig@pengutronix.de>; Russell King
> <rmk+kernel@armlinux.org.uk>; Leyfoon Tan <leyfoon.tan@starfivetech.com>;
> JeeHeng Sia <jeeheng.sia@starfivetech.com>; netdev@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-stm32@st-md-mailman.stormreply.com;
> linux-arm-kernel@lists.infradead.org; linux-riscv@lists.infradead.org
> Subject: Re: [PATCH v5 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add
> StarFive JH8100 support
>
> On Wed, Mar 27, 2024 at 08:54:30AM +0100, Krzysztof Kozlowski wrote:
> > On 27/03/2024 02:57, Tan Chun Hau wrote:
> > > Add StarFive JH8100 dwmac support.
> > > The JH8100 dwmac shares the same driver code as the JH7110 dwmac and
> > > has only one reset signal.
> > >
> > > Please refer to below:
> > >
> > > JH8100: reset-names = "stmmaceth";
> > > JH7110: reset-names = "stmmaceth", "ahb";
> > > JH7100: reset-names = "ahb";
> > >
> > > Example usage of JH8100 in the device tree:
> > >
> > > gmac0: ethernet@16030000 {
> > > compatible = "starfive,jh8100-dwmac",
> > > "starfive,jh7110-dwmac",
> > > "snps,dwmac-5.20";
> > > ...
> > > };
> > >
> > > Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
> > > ---
> > > .../devicetree/bindings/net/snps,dwmac.yaml | 1 +
> > > .../bindings/net/starfive,jh7110-dwmac.yaml | 29 +++++++++++++++----
> > > 2 files changed, 25 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > index 6b0341a8e0ea..a6d596b7dcf4 100644
> > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > @@ -97,6 +97,7 @@ properties:
> > > - snps,dwxgmac-2.10
> > > - starfive,jh7100-dwmac
> > > - starfive,jh7110-dwmac
> > > + - starfive,jh8100-dwmac
> >
> > I think that's not needed. You have there already your fallback.
Okay, I will remove it.
> >
> > >
> > > reg:
> > > minItems: 1
> > > diff --git
> > > a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > > b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > > index 0d1962980f57..5805a58c55d1 100644
> > > ---
> > > a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
> > > +++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.ya
> > > +++ ml
> > > @@ -18,6 +18,7 @@ select:
> > > enum:
> > > - starfive,jh7100-dwmac
> > > - starfive,jh7110-dwmac
> > > + - starfive,jh8100-dwmac
> >
> > Same here, even more obvious.
>
> Agreed.
Okay, I will remove it.
>
> >
> > > required:
> > > - compatible
> > >
> > > @@ -30,6 +31,10 @@ properties:
> > > - items:
> > > - const: starfive,jh7110-dwmac
> > > - const: snps,dwmac-5.20
> > > + - items:
> > > + - const: starfive,jh8100-dwmac
> > > + - const: starfive,jh7110-dwmac
> > > + - const: snps,dwmac-5.20
> > >
> > > reg:
> > > maxItems: 1
> > > @@ -116,11 +121,25 @@ allOf:
> > > minItems: 3
> > > maxItems: 3
> > >
> > > - resets:
> > > - minItems: 2
> > > -
> > > - reset-names:
> > > - minItems: 2
> > > + if:
> >
> > I would personally avoid nesting if within if. It gets unreadable.
> > Although Rob did not comment on this one, so I guess it is fine.
>
> I normally agree, but here I suggested it as it looked to be the simplest option.
>
> With the 2 other comments addressed,
>
> 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 31/34] spi: remove incorrect of_match_ptr annotations
From: Mark Brown @ 2024-04-03 9:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Neil Armstrong, Kevin Hilman, Heiko Stuebner,
Andi Shyti, Krzysztof Kozlowski, Arnd Bergmann, Jerome Brunet,
Martin Blumenstingl, Alim Akhtar, Li Zetao, Jonathan Cameron,
Rob Herring, Yang Yingliang, Andy Shevchenko, Luis de Arquer,
Tudor Ambarus, Sam Protsenko, Peter Griffin, Jaewon Kim,
linux-spi, linux-arm-kernel, linux-amlogic, linux-rockchip,
linux-samsung-soc
In-Reply-To: <20240403080702.3509288-32-arnd@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 778 bytes --]
On Wed, Apr 03, 2024 at 10:06:49AM +0200, Arnd Bergmann wrote:
> These appear to all be copied from the same original driver, so fix them at the
> same time by removing the unnecessary of_match_ptr() annotation. As far as I
> can tell, all these drivers are only actually used on configurations that
> have CONFIG_OF enabled.
Why are we not fixing of_match_ptr() here, or at least adding the ifdefs
in case someone does end up wanting to run without OF?
Just as a general thing for something like this where the patches aren't
expected to get merged together it makes life much easier to not send as
a series - pulling individual patches out of a series causes issues with
things like b4, especially if you have to apply them to multiple places,
and there's limited benefit.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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: remove redundant 'extern'
From: Steven Price @ 2024-04-03 9:58 UTC (permalink / raw)
To: Mark Rutland; +Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, linux-kernel
In-Reply-To: <ZgvXljt6vdlVc1sF@FVFF77S0Q05N>
On 02/04/2024 11:01, Mark Rutland wrote:
> On Wed, Mar 27, 2024 at 11:24:39AM +0000, Steven Price wrote:
>> It isn't necessary to mark function definitions extern and goes against
>> the kernel coding style. Remove the redundant extern keyword.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>
> We (unfortunately) have extern misused in a number of places:
>
> | [mark@lakrids:~/src/linux]% git grep 'extern.*(' -- arch/arm64/include | cut -d: -f 1 | uniq -c
> | 11 arch/arm64/include/asm/cacheflush.h
> | 1 arch/arm64/include/asm/checksum.h
> | 1 arch/arm64/include/asm/cpu_ops.h
> | 4 arch/arm64/include/asm/cpufeature.h
> | 2 arch/arm64/include/asm/efi.h
> | 2 arch/arm64/include/asm/elf.h
> | 1 arch/arm64/include/asm/exec.h
> | 1 arch/arm64/include/asm/fixmap.h
> | 48 arch/arm64/include/asm/fpsimd.h
> | 3 arch/arm64/include/asm/ftrace.h
> | 10 arch/arm64/include/asm/hugetlb.h
> | 11 arch/arm64/include/asm/hw_breakpoint.h
> | 6 arch/arm64/include/asm/io.h
> | 4 arch/arm64/include/asm/kexec.h
> | 1 arch/arm64/include/asm/kgdb.h
> | 16 arch/arm64/include/asm/kvm_asm.h
> | 3 arch/arm64/include/asm/kvm_host.h
> | 11 arch/arm64/include/asm/kvm_hyp.h
> | 2 arch/arm64/include/asm/kvm_pkvm.h
> | 2 arch/arm64/include/asm/memory.h
> | 8 arch/arm64/include/asm/mmu.h
> | 2 arch/arm64/include/asm/page.h
> | 1 arch/arm64/include/asm/percpu.h
> | 2 arch/arm64/include/asm/perf_event.h
> | 2 arch/arm64/include/asm/pgalloc.h
> | 18 arch/arm64/include/asm/pgtable.h
> | 3 arch/arm64/include/asm/pointer_auth.h
> | 3 arch/arm64/include/asm/proc-fns.h
> | 2 arch/arm64/include/asm/processor.h
> | 3 arch/arm64/include/asm/ptrace.h
> | 12 arch/arm64/include/asm/smp.h
> | 1 arch/arm64/include/asm/stacktrace.h
> | 14 arch/arm64/include/asm/string.h
> | 2 arch/arm64/include/asm/suspend.h
> | 1 arch/arm64/include/asm/system_misc.h
> | 6 arch/arm64/include/asm/uaccess.h
>
> ... so it'd probably be best to make the commit title more specific to this
> instance, and maybe go clean those up in bulk as a series to avoid a steady
> stream of copycat patches.
Ah, I hadn't gone looking that closely - I'll do a series updating the
arch/arm64/include ones (thanks for the list ;) ), and I'll include an
updated version of this patch, with a clearly commit title, in the series.
Thanks,
Steve
> Mark.
>
>> ---
>> arch/arm64/include/asm/fixmap.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
>> index 87e307804b99..75b22b89db1a 100644
>> --- a/arch/arm64/include/asm/fixmap.h
>> +++ b/arch/arm64/include/asm/fixmap.h
>> @@ -107,7 +107,7 @@ void __init early_fixmap_init(void);
>> #define __late_set_fixmap __set_fixmap
>> #define __late_clear_fixmap(idx) __set_fixmap((idx), 0, FIXMAP_PAGE_CLEAR)
>>
>> -extern void __set_fixmap(enum fixed_addresses idx, phys_addr_t phys, pgprot_t prot);
>> +void __set_fixmap(enum fixed_addresses idx, phys_addr_t phys, pgprot_t prot);
>>
>> #include <asm-generic/fixmap.h>
>>
>> --
>> 2.34.1
>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 0/5] Add Tegra Security Engine driver
From: Akhil R @ 2024-04-03 10:00 UTC (permalink / raw)
To: herbert, davem, robh, krzysztof.kozlowski+dt, conor+dt,
thierry.reding, jonathanh, catalin.marinas, will, mperttunen,
airlied, daniel, linux-crypto, devicetree, linux-tegra,
linux-kernel, linux-arm-kernel, dri-devel
Cc: Akhil R
Add support for Tegra Security Engine which can accelerates various
crypto algorithms. The Engine has two separate instances within for
AES and HASH algorithms respectively.
The driver registers two crypto engines - one for AES and another for
HASH algorithms and these operate independently and both uses the host1x
bus. Additionally, it provides hardware-assisted key protection for up to
15 symmetric keys which it can use for the cipher operations.
v6->v7:
* Move fallback_tfm and fallback_req to end of struct
* Set reqsize and statesize based on fallback_tfm
* Remove ofb(aes)
v5->v6:
* Move copy/pase of intermediate results in export()/import() to
'update()' callback for CMAC as well.
* Check for rctx size when using fallback alg.
* Updated blocksizes to align with generic implementation
* Combined GCM and CCM init into aead_cra_init
* Updates to handle invalid cases better
* Reduce log levels for invalid cases to dev_dbg
v4->v5:
* Move copy/paste of intermediate results in export()/import() to
'update()' callback
v3->v4:
* Remove unused header in bindings doc.
* Update commit message in host1x change.
* Fix test bot warning.
v2->v3:
* Update compatible in driver and device trees.
* Remove extra new lines and symbols in binding doc.
v1->v2:
* Update probe errors with 'dev_err_probe'.
* Clean up function prototypes and redundant prints.
* Remove readl/writel wrappers.
* Fix test bot warnings.
Akhil R (5):
dt-bindings: crypto: Add Tegra Security Engine
gpu: host1x: Add Tegra SE to SID table
crypto: tegra: Add Tegra Security Engine driver
arm64: defconfig: Enable Tegra Security Engine
arm64: tegra: Add Tegra Security Engine DT nodes
.../crypto/nvidia,tegra234-se-aes.yaml | 52 +
.../crypto/nvidia,tegra234-se-hash.yaml | 52 +
MAINTAINERS | 5 +
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 16 +
arch/arm64/configs/defconfig | 1 +
drivers/crypto/Kconfig | 8 +
drivers/crypto/Makefile | 1 +
drivers/crypto/tegra/Makefile | 9 +
drivers/crypto/tegra/tegra-se-aes.c | 1933 +++++++++++++++++
drivers/crypto/tegra/tegra-se-hash.c | 1060 +++++++++
drivers/crypto/tegra/tegra-se-key.c | 156 ++
drivers/crypto/tegra/tegra-se-main.c | 439 ++++
drivers/crypto/tegra/tegra-se.h | 560 +++++
drivers/gpu/host1x/dev.c | 24 +
14 files changed, 4316 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml
create mode 100644 Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml
create mode 100644 drivers/crypto/tegra/Makefile
create mode 100644 drivers/crypto/tegra/tegra-se-aes.c
create mode 100644 drivers/crypto/tegra/tegra-se-hash.c
create mode 100644 drivers/crypto/tegra/tegra-se-key.c
create mode 100644 drivers/crypto/tegra/tegra-se-main.c
create mode 100644 drivers/crypto/tegra/tegra-se.h
--
2.43.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 1/5] dt-bindings: crypto: Add Tegra Security Engine
From: Akhil R @ 2024-04-03 10:00 UTC (permalink / raw)
To: herbert, davem, robh, krzysztof.kozlowski+dt, conor+dt,
thierry.reding, jonathanh, catalin.marinas, will, mperttunen,
airlied, daniel, linux-crypto, devicetree, linux-tegra,
linux-kernel, linux-arm-kernel, dri-devel
Cc: Akhil R, Krzysztof Kozlowski
In-Reply-To: <20240403100039.33146-1-akhilrajeev@nvidia.com>
Add DT binding document for Tegra Security Engine.
The AES and HASH algorithms are handled independently by separate
engines within the Security Engine. These engines are registered
as two separate crypto engine drivers.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
.../crypto/nvidia,tegra234-se-aes.yaml | 52 +++++++++++++++++++
.../crypto/nvidia,tegra234-se-hash.yaml | 52 +++++++++++++++++++
2 files changed, 104 insertions(+)
create mode 100644 Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml
create mode 100644 Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml
diff --git a/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml
new file mode 100644
index 000000000000..cb47ae2889b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-aes.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/nvidia,tegra234-se-aes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Security Engine for AES algorithms
+
+description:
+ The Tegra Security Engine accelerates the following AES encryption/decryption
+ algorithms - AES-ECB, AES-CBC, AES-OFB, AES-XTS, AES-CTR, AES-GCM, AES-CCM,
+ AES-CMAC
+
+maintainers:
+ - Akhil R <akhilrajeev@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra234-se-aes
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - iommus
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/memory/tegra234-mc.h>
+ #include <dt-bindings/clock/tegra234-clock.h>
+
+ crypto@15820000 {
+ compatible = "nvidia,tegra234-se-aes";
+ reg = <0x15820000 0x10000>;
+ clocks = <&bpmp TEGRA234_CLK_SE>;
+ iommus = <&smmu TEGRA234_SID_SES_SE1>;
+ dma-coherent;
+ };
+...
diff --git a/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml
new file mode 100644
index 000000000000..f57ef10645e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/nvidia,tegra234-se-hash.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/crypto/nvidia,tegra234-se-hash.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA Tegra Security Engine for HASH algorithms
+
+description:
+ The Tegra Security HASH Engine accelerates the following HASH functions -
+ SHA1, SHA224, SHA256, SHA384, SHA512, SHA3-224, SHA3-256, SHA3-384, SHA3-512
+ HMAC(SHA224), HMAC(SHA256), HMAC(SHA384), HMAC(SHA512)
+
+maintainers:
+ - Akhil R <akhilrajeev@nvidia.com>
+
+properties:
+ compatible:
+ const: nvidia,tegra234-se-hash
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ iommus:
+ maxItems: 1
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - iommus
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/memory/tegra234-mc.h>
+ #include <dt-bindings/clock/tegra234-clock.h>
+
+ crypto@15840000 {
+ compatible = "nvidia,tegra234-se-hash";
+ reg = <0x15840000 0x10000>;
+ clocks = <&bpmp TEGRA234_CLK_SE>;
+ iommus = <&smmu TEGRA234_SID_SES_SE2>;
+ dma-coherent;
+ };
+...
--
2.43.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
* Re: [PATCH v2] arm64: Fix double TCR_T0SZ_OFFSET shift
From: Mark Rutland @ 2024-04-03 10:01 UTC (permalink / raw)
To: Seongsu Park
Cc: will, catalin.marinas, ardb, linux-arm-kernel, linux-kernel,
Leem ChaeHoon, Gyeonggeon Choi, Soomin Cho, DaeRo Lee, kmasta
In-Reply-To: <20240403024236.193428-1-sgsu.park@samsung.com>
On Wed, Apr 03, 2024 at 11:42:36AM +0900, Seongsu Park wrote:
> We have already shifted the value of t0sz in TCR_T0SZ by TCR_T0SZ_OFFSET.
> So, the TCR_T0SZ_OFFSET shift here should be removed.
Can we please write a better commit message?
This doesn't explain:
* Where we have already shifted the value of t0sz, nor why it makes sense to do
that there.
* That the value of TCR_T0SZ_OFFSET is 0, and hence shifting this repeatedly is
beningn, and this patch is a cleanup rather than a fix.
Mark.
> Co-developed-by: Leem ChaeHoon <infinite.run@gmail.com>
> Signed-off-by: Leem ChaeHoon <infinite.run@gmail.com>
> Co-developed-by: Gyeonggeon Choi <gychoi@student.42seoul.kr>
> Signed-off-by: Gyeonggeon Choi <gychoi@student.42seoul.kr>
> Co-developed-by: Soomin Cho <to.soomin@gmail.com>
> Signed-off-by: Soomin Cho <to.soomin@gmail.com>
> Co-developed-by: DaeRo Lee <skseofh@gmail.com>
> Signed-off-by: DaeRo Lee <skseofh@gmail.com>
> Co-developed-by: kmasta <kmasta.study@gmail.com>
> Signed-off-by: kmasta <kmasta.study@gmail.com>
> Signed-off-by: Seongsu Park <sgsu.park@samsung.com>
> ---
>
> Changes in v2:
> - Condition is updated
>
> ---
> arch/arm64/include/asm/mmu_context.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index c768d16b81a4..bd19f4c758b7 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -72,11 +72,11 @@ static inline void __cpu_set_tcr_t0sz(unsigned long t0sz)
> {
> unsigned long tcr = read_sysreg(tcr_el1);
>
> - if ((tcr & TCR_T0SZ_MASK) >> TCR_T0SZ_OFFSET == t0sz)
> + if ((tcr & TCR_T0SZ_MASK) == t0sz)
> return;
>
> tcr &= ~TCR_T0SZ_MASK;
> - tcr |= t0sz << TCR_T0SZ_OFFSET;
> + tcr |= t0sz;
> write_sysreg(tcr, tcr_el1);
> isb();
> }
> --
> 2.34.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v7 4/5] arm64: defconfig: Enable Tegra Security Engine
From: Akhil R @ 2024-04-03 10:00 UTC (permalink / raw)
To: herbert, davem, robh, krzysztof.kozlowski+dt, conor+dt,
thierry.reding, jonathanh, catalin.marinas, will, mperttunen,
airlied, daniel, linux-crypto, devicetree, linux-tegra,
linux-kernel, linux-arm-kernel, dri-devel
Cc: Akhil R
In-Reply-To: <20240403100039.33146-1-akhilrajeev@nvidia.com>
Enable Tegra Security Engine which can accelerate various
AES and HASH algorithms on supported hardware.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 2c30d617e180..af6f247c497c 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1647,6 +1647,7 @@ CONFIG_CRYPTO_DEV_FSL_CAAM=m
CONFIG_CRYPTO_DEV_FSL_DPAA2_CAAM=m
CONFIG_CRYPTO_DEV_QCE=m
CONFIG_CRYPTO_DEV_QCOM_RNG=m
+CONFIG_CRYPTO_DEV_TEGRA=m
CONFIG_CRYPTO_DEV_CCREE=m
CONFIG_CRYPTO_DEV_HISI_SEC2=m
CONFIG_CRYPTO_DEV_HISI_ZIP=m
--
2.43.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
* [PATCH v7 5/5] arm64: tegra: Add Tegra Security Engine DT nodes
From: Akhil R @ 2024-04-03 10:00 UTC (permalink / raw)
To: herbert, davem, robh, krzysztof.kozlowski+dt, conor+dt,
thierry.reding, jonathanh, catalin.marinas, will, mperttunen,
airlied, daniel, linux-crypto, devicetree, linux-tegra,
linux-kernel, linux-arm-kernel, dri-devel
Cc: Akhil R
In-Reply-To: <20240403100039.33146-1-akhilrajeev@nvidia.com>
Add device tree nodes for Tegra AES and HASH engines.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
arch/arm64/boot/dts/nvidia/tegra234.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index 78cbfdd98dd1..f2e2d8d6845b 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -4406,6 +4406,22 @@ nvdec@15480000 {
*/
status = "disabled";
};
+
+ crypto@15820000 {
+ compatible = "nvidia,tegra234-se-aes";
+ reg = <0x00 0x15820000 0x00 0x10000>;
+ clocks = <&bpmp TEGRA234_CLK_SE>;
+ iommus = <&smmu_niso1 TEGRA234_SID_SES_SE1>;
+ dma-coherent;
+ };
+
+ crypto@15840000 {
+ compatible = "nvidia,tegra234-se-hash";
+ reg = <0x00 0x15840000 0x00 0x10000>;
+ clocks = <&bpmp TEGRA234_CLK_SE>;
+ iommus = <&smmu_niso1 TEGRA234_SID_SES_SE2>;
+ dma-coherent;
+ };
};
pcie@140a0000 {
--
2.43.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
* Re: [PATCH 07/34] Input: stmpe-ts - mark OF related data as maybe unused
From: Andy Shevchenko @ 2024-04-03 10:03 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Arnd Bergmann, linux-kernel, Dmitry Torokhov, Maxime Coquelin,
Alexandre Torgue, Arnd Bergmann, Uwe Kleine-König,
linux-input, linux-stm32, linux-arm-kernel
In-Reply-To: <614fc80a-5d2a-43a1-b8d4-48bdb2cc7dc7@linaro.org>
On Wed, Apr 03, 2024 at 11:52:12AM +0200, Krzysztof Kozlowski wrote:
> On 03/04/2024 11:40, Andy Shevchenko wrote:
> > On Wed, Apr 03, 2024 at 10:06:25AM +0200, Arnd Bergmann wrote:
...
> >> -static const struct of_device_id stmpe_ts_ids[] = {
> >> +static const struct of_device_id stmpe_ts_ids[] __maybe_unused = {
> >
> > __maybe_unused?
> >
> > Why not adding it into .driver as you have done in another patch in this series?
>
> Because there is no benefit in this. This is instantiated by MFD, so the
> only thing you need is entry for module loading.
Hmm... Seems to me rather a good candidate for MODULE_ALIAS in this case. No?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 0/1] Add StarFive JH8100 dwmac support
From: Tan Chun Hau @ 2024-04-03 10:05 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Simon Horman, Bartosz Golaszewski,
Andrew Halaney, Jisheng Zhang, Uwe Kleine-König,
Russell King
Cc: Ley Foon Tan, Jee Heng Sia, netdev, devicetree, linux-kernel,
linux-stm32, linux-arm-kernel, linux-riscv
Add StarFive JH8100 dwmac support.
The JH8100 dwmac shares the same driver code as the JH7110 dwmac
and has only one reset signal.
Please refer to below:
JH8100: reset-names = "stmmaceth";
JH7110: reset-names = "stmmaceth", "ahb";
JH7100: reset-names = "ahb";
Example usage of JH8100 in the device tree:
gmac0: ethernet@16030000 {
compatible = "starfive,jh8100-dwmac",
"starfive,jh7110-dwmac",
"snps,dwmac-5.20";
...
};
Changes in v6:
- Removed unnecessary enum "starfive,jh8100-dwmac".
Tan Chun Hau (1):
dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
.../bindings/net/starfive,jh7110-dwmac.yaml | 28 +++++++++++++++----
1 file changed, 23 insertions(+), 5 deletions(-)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/1] dt-bindings: net: starfive,jh7110-dwmac: Add StarFive JH8100 support
From: Tan Chun Hau @ 2024-04-03 10:05 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Simon Horman, Bartosz Golaszewski,
Andrew Halaney, Jisheng Zhang, Uwe Kleine-König,
Russell King
Cc: Ley Foon Tan, Jee Heng Sia, netdev, devicetree, linux-kernel,
linux-stm32, linux-arm-kernel, linux-riscv
In-Reply-To: <20240403100549.78719-1-chunhau.tan@starfivetech.com>
Add StarFive JH8100 dwmac support.
The JH8100 dwmac shares the same driver code as the JH7110 dwmac
and has only one reset signal.
Please refer to below:
JH8100: reset-names = "stmmaceth";
JH7110: reset-names = "stmmaceth", "ahb";
JH7100: reset-names = "ahb";
Example usage of JH8100 in the device tree:
gmac0: ethernet@16030000 {
compatible = "starfive,jh8100-dwmac",
"starfive,jh7110-dwmac",
"snps,dwmac-5.20";
...
};
Signed-off-by: Tan Chun Hau <chunhau.tan@starfivetech.com>
---
.../bindings/net/starfive,jh7110-dwmac.yaml | 28 +++++++++++++++----
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
index 0d1962980f57..313a15331661 100644
--- a/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/starfive,jh7110-dwmac.yaml
@@ -30,6 +30,10 @@ properties:
- items:
- const: starfive,jh7110-dwmac
- const: snps,dwmac-5.20
+ - items:
+ - const: starfive,jh8100-dwmac
+ - const: starfive,jh7110-dwmac
+ - const: snps,dwmac-5.20
reg:
maxItems: 1
@@ -116,11 +120,25 @@ allOf:
minItems: 3
maxItems: 3
- resets:
- minItems: 2
-
- reset-names:
- minItems: 2
+ if:
+ properties:
+ compatible:
+ contains:
+ const: starfive,jh8100-dwmac
+ then:
+ properties:
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: stmmaceth
+ else:
+ properties:
+ resets:
+ minItems: 2
+
+ reset-names:
+ minItems: 2
unevaluatedProperties: false
--
2.25.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: [RESPIN PATCH] irqchip/gic-v3-its:Fix GICv4.1 needless VSYNC after unmap VPE
From: Marc Zyngier @ 2024-04-03 10:09 UTC (permalink / raw)
To: t00849498; +Cc: tglx, linux-arm-kernel, linux-kernel, guoyang2, wangwudi
In-Reply-To: <20240403083556.3862236-1-tangnianyao@huawei.com>
Thanks for respinning this.
A few remarks:
The subject line could be improved. Something like:
"irqchip/gic-v4: Don't issue a VSYNC after VMAPP with V=0"
On Wed, 03 Apr 2024 09:35:56 +0100,
t00849498 <tangnianyao@huawei.com> wrote:
>
> From: Nianyao Tang <tangnianyao@huawei.com>
>
> Quote from GIC spec 5.3.19, a VMAPP with {V, Alloc}=={0, x}
> is self-synchronizing, This means the ITS command queue does not
> show the command as consumed until all of its effects are completed.
Since this is a direct quote, make it clear that it is so.
>
> We don't need VSYNC to guarantee unmap finish. And VSYNC after unmap VPE
> will reach an invalid vpe table entry, which may trigger exception
> like SError or RAS. Let's fix it.
This should be much stronger. It's not that we don't need VSYNC. It is
that VSYNC is actively wrong. I suggest that you rewrite the commit
message along these lines:
<msg>
As per the GICv4.1 spec (Arm IHI 0069H, 5.3.19):
"A VMAPP with {V, Alloc}=={0, x} is self-synchronizing. This means the
ITS command queue does not show the command as consumed until all of
its effects are completed."
Furthermore, VSYNC is allowed to deliver an SError when referencing a
non existent VPE.
By these definitions, a VMAPP followed by a VSYNC is a bug, as the
later references a VPE that has been unmapped by the former.
Fix it by eliding the VSYNC in this scenario.
</msg>
>
> Signed-off-by: Nianyao Tang <tangnianyao@huawei.com>
Please also add:
Fixes: 64edfaa9a234 ("irqchip/gic-v4.1: Implement the v4.1 flavour of VMAPP")
With the above fixed:
Reviewed-by: Marc Zyngier <maz@kernel.org>
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: About upstreaming ArmChina NPU driver
From: Dejia Shang @ 2024-04-03 10:09 UTC (permalink / raw)
To: Oded Gabbay
Cc: ogabbay@kernel.org, airlied@redhat.com, daniel@ffwll.ch,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-arm-kernel@lists.infradead.org, Toby Huang, Chengkun Sun
In-Reply-To: <CAFCwf12ou8zNgr-_Ru8xT+Q1RWyxywwqJmx9w1spo_MdaEPr1Q@mail.gmail.com>
> -----Original Message-----
> From: Oded Gabbay <oded.gabbay@gmail.com>
> Sent: 2024年4月3日 14:26
> To: Dejia Shang <Dejia.Shang@armchina.com>
> Cc: ogabbay@kernel.org; airlied@redhat.com; daniel@ffwll.ch;
> linux-kernel@vger.kernel.org; dri-devel@lists.freedesktop.org;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: About upstreaming ArmChina NPU driver
>
> On Thu, Mar 28, 2024 at 10:01 AM Dejia Shang <Dejia.Shang@armchina.com>
> wrote:
> >
> > Dear Kernel Maintainers,
> >
> > I am a driver developer and would like to upstream the ArmChina Zhouyi
> NPU driver ("Zhouyi" is the brand) to accel subsystem.
> >
> > The driver is already open sourced (both UMD and KMD) and anyone can
> find the code from https://github.com/Arm-China/Compass_NPU_Driver.git.
> >
> > This driver is responsible for scheduling AI inference tasks to the NPU cores
> (V1/V2/V3). Specifically, a simplified end-to-end flow is:
> >
> > 1. A TFLite/ONNX model is transformed to an executable binary
> file in ELF format by the NN graph compiler (designed by ArmChina)
> > 2. An application loads the executable binary file to UMD and
> provides the input data.
> > 3. UMD parses the binary and sends ioctls to KMD (open device,
> do memory allocation/mmap/free, submit the job descriptor).
> > 4. KMD dispatches the job to NPU h/w, handles interrupts and
> updates the execution status.
> > 5. UMD polls the status of the pre-scheduled job.
> > 6. The application gets the output results.
> >
> > So...for the upstreaming,
> >
> > Q1: do you think our NPU driver is suitable for accel? If the answer is yes,
> which tree & branch should the patches be based on?
> Hi Dejia,
> Yes, it definitely sounds as a good fit to the accel subsystem.
> Please base your patches on "drm-misc-next" branch in drm-misc repo:
> https://anongit.freedesktop.org/git/drm/drm-misc.git
>
Hi Oded,
Got it.
> >
> > Q2: in thread
> https://lore.kernel.org/lkml/ec547d33-214f-4952-aa33-c271e9edad63@kern
> el.org/ showing a similar case, Oded mentioned that:
> >
> > "If we would have upstreamed a new driver, the expectation
> would have been that we would use some drm mechanisms.", and
> > "the minimal requirement is to use GEM/BOs for memory
> management operations".
> >
> > I guess those requirements are also applicable for the Zhouyi NPU KMD?
> Currently, the memory management (MM) in KMD is based on dma-mapping
> APIs, which handles both reserved CMA region(s) and SMMU mapped buffers,
> and supports the dma-buf framework. Maybe I should replace the
> implementations with DRM APIs.
> Yes, those requirements definitely apply here.
> >
> > Q3: if you have looked at the KMD code, do you think I should make any
> other major change before submitting the first patch series? Thank you!
> I took a quick glance. In general, it seems to be ok, but I noticed two things
> related to the integration with drm/accel:
>
> 1. You us a scheduler for the job submission, which provides the ability to
> defer jobs. In that case, I suggest to check if you can use drm_sched instead of
> your own implementation. No point in re-inventing the wheel.
> 2. You provide several memory zones for allocation of memory. I would
> suggest here to look at using ttm as the memory manager instead of
> re-implementing your own.
Thanks for your time! I will try to refactor the code as suggested and then send the first patch series.
>
> And please remove the IMPORTANT NOTICE at the end of your emails. I
> would have to refrain from answering to further emails if that notice remains.
Now fixed. I did not realize that because the server auto appended the notice. Sorry for the inconvenience.
Best Regards,
Dejia
>
> Thanks,
> Oded
>
> >
> > Thanks for your time and look forward to your reply~ 😊
> >
> > Best Regards,
> > Dejia
_______________________________________________
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 07/34] Input: stmpe-ts - mark OF related data as maybe unused
From: Krzysztof Kozlowski @ 2024-04-03 10:10 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Arnd Bergmann, linux-kernel, Dmitry Torokhov, Maxime Coquelin,
Alexandre Torgue, Arnd Bergmann, Uwe Kleine-König,
linux-input, linux-stm32, linux-arm-kernel
In-Reply-To: <Zg0pei7ut5lC9yVC@smile.fi.intel.com>
On 03/04/2024 12:03, Andy Shevchenko wrote:
> On Wed, Apr 03, 2024 at 11:52:12AM +0200, Krzysztof Kozlowski wrote:
>> On 03/04/2024 11:40, Andy Shevchenko wrote:
>>> On Wed, Apr 03, 2024 at 10:06:25AM +0200, Arnd Bergmann wrote:
>
> ...
>
>>>> -static const struct of_device_id stmpe_ts_ids[] = {
>>>> +static const struct of_device_id stmpe_ts_ids[] __maybe_unused = {
>>>
>>> __maybe_unused?
>>>
>>> Why not adding it into .driver as you have done in another patch in this series?
>>
>> Because there is no benefit in this. This is instantiated by MFD, so the
>> only thing you need is entry for module loading.
>
> Hmm... Seems to me rather a good candidate for MODULE_ALIAS in this case. No?
No, I do not think module alias is for that purpose. This is a valid
compatible, documented and provided by DT so it is expected to be in
of_device_id.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] arm64: dts: ti: k3-{am62p,j722s}: Disable ethernet by default
From: Michael Walle @ 2024-04-03 10:15 UTC (permalink / raw)
To: Francesco Dolcini, Nishanth Menon, Vignesh Raghavendra,
Tero Kristo, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, devicetree, linux-kernel, Michael Walle
Device tree best practice is to disable any external interface in the
dtsi and just enable them if needed in the device tree. Thus, disable
the ethernet switch and its ports by default and just enable the ones
used by the EVMs in their device trees.
There is no functional change.
Signed-off-by: Michael Walle <mwalle@kernel.org>
---
v2:
- move the status propert into k3-am62p5-main.dtsi, thus also update
the k3-am62p5-sk.dts
- put "status" last
---
arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 3 +++
arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 3 +++
arch/arm64/boot/dts/ti/k3-j722s-evm.dts | 5 +----
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
index 7337a9e13535..88bc64111234 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
@@ -673,6 +673,7 @@ cpsw3g: ethernet@8000000 {
assigned-clock-parents = <&k3_clks 13 11>;
clock-names = "fck";
power-domains = <&k3_pds 13 TI_SCI_PD_EXCLUSIVE>;
+ status = "disabled";
dmas = <&main_pktdma 0xc600 15>,
<&main_pktdma 0xc601 15>,
@@ -696,6 +697,7 @@ cpsw_port1: port@1 {
label = "port1";
phys = <&phy_gmii_sel 1>;
mac-address = [00 00 00 00 00 00];
+ status = "disabled";
};
cpsw_port2: port@2 {
@@ -704,6 +706,7 @@ cpsw_port2: port@2 {
label = "port2";
phys = <&phy_gmii_sel 2>;
mac-address = [00 00 00 00 00 00];
+ status = "disabled";
};
};
diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
index 6694087b3665..6a9c99c5fb2a 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts
@@ -431,16 +431,19 @@ &cpsw3g {
pinctrl-names = "default";
pinctrl-0 = <&main_rgmii1_pins_default>,
<&main_rgmii2_pins_default>;
+ status = "okay";
};
&cpsw_port1 {
phy-mode = "rgmii-rxid";
phy-handle = <&cpsw3g_phy0>;
+ status = "okay";
};
&cpsw_port2 {
phy-mode = "rgmii-rxid";
phy-handle = <&cpsw3g_phy1>;
+ status = "okay";
};
&cpsw3g_mdio {
diff --git a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
index 6b148da2bcdc..8a38e5ae7d4f 100644
--- a/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j722s-evm.dts
@@ -226,10 +226,7 @@ cpsw3g_phy0: ethernet-phy@0 {
&cpsw_port1 {
phy-mode = "rgmii-rxid";
phy-handle = <&cpsw3g_phy0>;
-};
-
-&cpsw_port2 {
- status = "disabled";
+ status = "okay";
};
&main_gpio1 {
--
2.39.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
* Re: [PATCH v4 2/5] tee: optee: Move pool_op helper functions
From: Balint Dobszay @ 2024-04-03 10:18 UTC (permalink / raw)
To: Jens Wiklander
Cc: op-tee, linux-doc, linux-kernel, linux-arm-kernel, sumit.garg,
corbet, sudeep.holla, rdunlap, krzk, gyorgy.szing
In-Reply-To: <CAHUa44HHikgA2R_nZw9+f6ug1nKBZgwVEYvqPgKo6dx=iijAqA@mail.gmail.com>
Hi Jens,
On 3 Apr 2024, at 11:43, Jens Wiklander wrote:
> Hi Balint,
>
> On Mon, Mar 25, 2024 at 4:11 PM Balint Dobszay <balint.dobszay@arm.com> wrote:
>>
>> Move the pool alloc and free helper functions from the OP-TEE driver to
>> the TEE subsystem, since these could be reused in other TEE drivers.
>> This patch is not supposed to change behavior, it's only reorganizing
>> the code.
>>
>> Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
>> Suggested-by: Jens Wiklander <jens.wiklander@linaro.org>
>> Signed-off-by: Balint Dobszay <balint.dobszay@arm.com>
>> ---
>> drivers/tee/optee/core.c | 64 -------------------------------
>> drivers/tee/optee/ffa_abi.c | 6 +--
>> drivers/tee/optee/optee_private.h | 12 ------
>> drivers/tee/optee/smc_abi.c | 9 ++---
>> drivers/tee/tee_shm.c | 64 +++++++++++++++++++++++++++++++
>> include/linux/tee_core.h | 10 +++++
>> 6 files changed, 81 insertions(+), 84 deletions(-)
>
> This patch fails to build on x86_64:
> CC [M] drivers/tee/tee_shm.o
> drivers/tee/tee_shm.c: In function ‘tee_dyn_shm_alloc_helper’:
> linux/drivers/tee/tee_shm.c:226:22: error: implicit declaration of
> function ‘virt_to_phys’; did you mean ‘virt_to_page’?
> [-Werror=implicit-function-declaration]
> 226 | shm->paddr = virt_to_phys(shm->kaddr);
> | ^~~~~~~~~~~~
> | virt_to_page
>
> It's fixed by adding
> #include <linux/io.h>
>
> I'll fix up the patch if you agree with the fix.
Thanks for catching this. I agree with the fix, please apply it.
Regards,
Balint
>>
>> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
>> index f762e3a25119..39e688d4e974 100644
>> --- a/drivers/tee/optee/core.c
>> +++ b/drivers/tee/optee/core.c
>> @@ -9,7 +9,6 @@
>> #include <linux/crash_dump.h>
>> #include <linux/errno.h>
>> #include <linux/io.h>
>> -#include <linux/mm.h>
>> #include <linux/module.h>
>> #include <linux/slab.h>
>> #include <linux/string.h>
>> @@ -17,69 +16,6 @@
>> #include <linux/types.h>
>> #include "optee_private.h"
>>
>> -int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
>> - size_t size, size_t align,
>> - int (*shm_register)(struct tee_context *ctx,
>> - struct tee_shm *shm,
>> - struct page **pages,
>> - size_t num_pages,
>> - unsigned long start))
>> -{
>> - size_t nr_pages = roundup(size, PAGE_SIZE) / PAGE_SIZE;
>> - struct page **pages;
>> - unsigned int i;
>> - int rc = 0;
>> -
>> - /*
>> - * Ignore alignment since this is already going to be page aligned
>> - * and there's no need for any larger alignment.
>> - */
>> - shm->kaddr = alloc_pages_exact(nr_pages * PAGE_SIZE,
>> - GFP_KERNEL | __GFP_ZERO);
>> - if (!shm->kaddr)
>> - return -ENOMEM;
>> -
>> - shm->paddr = virt_to_phys(shm->kaddr);
>> - shm->size = nr_pages * PAGE_SIZE;
>> -
>> - pages = kcalloc(nr_pages, sizeof(*pages), GFP_KERNEL);
>> - if (!pages) {
>> - rc = -ENOMEM;
>> - goto err;
>> - }
>> -
>> - for (i = 0; i < nr_pages; i++)
>> - pages[i] = virt_to_page((u8 *)shm->kaddr + i * PAGE_SIZE);
>> -
>> - shm->pages = pages;
>> - shm->num_pages = nr_pages;
>> -
>> - if (shm_register) {
>> - rc = shm_register(shm->ctx, shm, pages, nr_pages,
>> - (unsigned long)shm->kaddr);
>> - if (rc)
>> - goto err;
>> - }
>> -
>> - return 0;
>> -err:
>> - free_pages_exact(shm->kaddr, shm->size);
>> - shm->kaddr = NULL;
>> - return rc;
>> -}
>> -
>> -void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
>> - int (*shm_unregister)(struct tee_context *ctx,
>> - struct tee_shm *shm))
>> -{
>> - if (shm_unregister)
>> - shm_unregister(shm->ctx, shm);
>> - free_pages_exact(shm->kaddr, shm->size);
>> - shm->kaddr = NULL;
>> - kfree(shm->pages);
>> - shm->pages = NULL;
>> -}
>> -
>> static void optee_bus_scan(struct work_struct *work)
>> {
>> WARN_ON(optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP));
>> diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c
>> index cee8ccb84cb8..3235e1c719e8 100644
>> --- a/drivers/tee/optee/ffa_abi.c
>> +++ b/drivers/tee/optee/ffa_abi.c
>> @@ -374,14 +374,14 @@ static int optee_ffa_shm_unregister_supp(struct tee_context *ctx,
>> static int pool_ffa_op_alloc(struct tee_shm_pool *pool,
>> struct tee_shm *shm, size_t size, size_t align)
>> {
>> - return optee_pool_op_alloc_helper(pool, shm, size, align,
>> - optee_ffa_shm_register);
>> + return tee_dyn_shm_alloc_helper(shm, size, align,
>> + optee_ffa_shm_register);
>> }
>>
>> static void pool_ffa_op_free(struct tee_shm_pool *pool,
>> struct tee_shm *shm)
>> {
>> - optee_pool_op_free_helper(pool, shm, optee_ffa_shm_unregister);
>> + tee_dyn_shm_free_helper(shm, optee_ffa_shm_unregister);
>> }
>>
>> static void pool_ffa_op_destroy_pool(struct tee_shm_pool *pool)
>> diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
>> index a0698ac18993..429cc20be5cc 100644
>> --- a/drivers/tee/optee/optee_private.h
>> +++ b/drivers/tee/optee/optee_private.h
>> @@ -283,18 +283,6 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session);
>> int optee_enumerate_devices(u32 func);
>> void optee_unregister_devices(void);
>>
>> -int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
>> - size_t size, size_t align,
>> - int (*shm_register)(struct tee_context *ctx,
>> - struct tee_shm *shm,
>> - struct page **pages,
>> - size_t num_pages,
>> - unsigned long start));
>> -void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
>> - int (*shm_unregister)(struct tee_context *ctx,
>> - struct tee_shm *shm));
>> -
>> -
>> void optee_remove_common(struct optee *optee);
>> int optee_open(struct tee_context *ctx, bool cap_memref_null);
>> void optee_release(struct tee_context *ctx);
>> diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
>> index 9c296b887dc1..734c484ed0f6 100644
>> --- a/drivers/tee/optee/smc_abi.c
>> +++ b/drivers/tee/optee/smc_abi.c
>> @@ -592,19 +592,18 @@ static int pool_op_alloc(struct tee_shm_pool *pool,
>> * to be registered with OP-TEE.
>> */
>> if (shm->flags & TEE_SHM_PRIV)
>> - return optee_pool_op_alloc_helper(pool, shm, size, align, NULL);
>> + return tee_dyn_shm_alloc_helper(shm, size, align, NULL);
>>
>> - return optee_pool_op_alloc_helper(pool, shm, size, align,
>> - optee_shm_register);
>> + return tee_dyn_shm_alloc_helper(shm, size, align, optee_shm_register);
>> }
>>
>> static void pool_op_free(struct tee_shm_pool *pool,
>> struct tee_shm *shm)
>> {
>> if (!(shm->flags & TEE_SHM_PRIV))
>> - optee_pool_op_free_helper(pool, shm, optee_shm_unregister);
>> + tee_dyn_shm_free_helper(shm, optee_shm_unregister);
>> else
>> - optee_pool_op_free_helper(pool, shm, NULL);
>> + tee_dyn_shm_free_helper(shm, NULL);
>> }
>>
>> static void pool_op_destroy_pool(struct tee_shm_pool *pool)
>> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
>> index 96a45c817427..5bf76c35cd9e 100644
>> --- a/drivers/tee/tee_shm.c
>> +++ b/drivers/tee/tee_shm.c
>> @@ -202,6 +202,70 @@ struct tee_shm *tee_shm_alloc_priv_buf(struct tee_context *ctx, size_t size)
>> }
>> EXPORT_SYMBOL_GPL(tee_shm_alloc_priv_buf);
>>
>> +int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align,
>> + int (*shm_register)(struct tee_context *ctx,
>> + struct tee_shm *shm,
>> + struct page **pages,
>> + size_t num_pages,
>> + unsigned long start))
>> +{
>> + size_t nr_pages = roundup(size, PAGE_SIZE) / PAGE_SIZE;
>> + struct page **pages;
>> + unsigned int i;
>> + int rc = 0;
>> +
>> + /*
>> + * Ignore alignment since this is already going to be page aligned
>> + * and there's no need for any larger alignment.
>> + */
>> + shm->kaddr = alloc_pages_exact(nr_pages * PAGE_SIZE,
>> + GFP_KERNEL | __GFP_ZERO);
>> + if (!shm->kaddr)
>> + return -ENOMEM;
>> +
>> + shm->paddr = virt_to_phys(shm->kaddr);
>> + shm->size = nr_pages * PAGE_SIZE;
>> +
>> + pages = kcalloc(nr_pages, sizeof(*pages), GFP_KERNEL);
>> + if (!pages) {
>> + rc = -ENOMEM;
>> + goto err;
>> + }
>> +
>> + for (i = 0; i < nr_pages; i++)
>> + pages[i] = virt_to_page((u8 *)shm->kaddr + i * PAGE_SIZE);
>> +
>> + shm->pages = pages;
>> + shm->num_pages = nr_pages;
>> +
>> + if (shm_register) {
>> + rc = shm_register(shm->ctx, shm, pages, nr_pages,
>> + (unsigned long)shm->kaddr);
>> + if (rc)
>> + goto err;
>> + }
>> +
>> + return 0;
>> +err:
>> + free_pages_exact(shm->kaddr, shm->size);
>> + shm->kaddr = NULL;
>> + return rc;
>> +}
>> +EXPORT_SYMBOL_GPL(tee_dyn_shm_alloc_helper);
>> +
>> +void tee_dyn_shm_free_helper(struct tee_shm *shm,
>> + int (*shm_unregister)(struct tee_context *ctx,
>> + struct tee_shm *shm))
>> +{
>> + if (shm_unregister)
>> + shm_unregister(shm->ctx, shm);
>> + free_pages_exact(shm->kaddr, shm->size);
>> + shm->kaddr = NULL;
>> + kfree(shm->pages);
>> + shm->pages = NULL;
>> +}
>> +EXPORT_SYMBOL_GPL(tee_dyn_shm_free_helper);
>> +
>> static struct tee_shm *
>> register_shm_helper(struct tee_context *ctx, struct iov_iter *iter, u32 flags,
>> int id)
>> diff --git a/include/linux/tee_core.h b/include/linux/tee_core.h
>> index d9b3ba8e8fa9..efd16ed52315 100644
>> --- a/include/linux/tee_core.h
>> +++ b/include/linux/tee_core.h
>> @@ -232,6 +232,16 @@ void *tee_get_drvdata(struct tee_device *teedev);
>> */
>> struct tee_shm *tee_shm_alloc_priv_buf(struct tee_context *ctx, size_t size);
>>
>> +int tee_dyn_shm_alloc_helper(struct tee_shm *shm, size_t size, size_t align,
>> + int (*shm_register)(struct tee_context *ctx,
>> + struct tee_shm *shm,
>> + struct page **pages,
>> + size_t num_pages,
>> + unsigned long start));
>> +void tee_dyn_shm_free_helper(struct tee_shm *shm,
>> + int (*shm_unregister)(struct tee_context *ctx,
>> + struct tee_shm *shm));
>> +
>> /**
>> * tee_shm_is_dynamic() - Check if shared memory object is of the dynamic kind
>> * @shm: Shared memory handle
>> --
>> 2.34.1
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v11 7/7] arm64: dts: imx8mm/n remove clock-names property from usb controller node
From: Xu Yang @ 2024-04-03 9:04 UTC (permalink / raw)
To: gregkh, robh+dt, krzysztof.kozlowski+dt, shawnguo, conor+dt
Cc: s.hauer, kernel, festevam, linux-imx, jun.li, linux-usb,
devicetree, linux-arm-kernel, imx, linux-kernel
In-Reply-To: <20240403090438.583326-1-xu.yang_2@nxp.com>
The clock-names property is not needed by usb controller node on imx8mm/n.
This will remove it.
Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
---
Changes in v9:
- new patch
Changes in v10:
- no changes
Changes in v11:
- no changes
---
arch/arm64/boot/dts/freescale/imx8mm.dtsi | 2 --
arch/arm64/boot/dts/freescale/imx8mn.dtsi | 1 -
2 files changed, 3 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
index 8a1b42b94dce..696e96b15585 100644
--- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
@@ -1253,7 +1253,6 @@ usbotg1: usb@32e40000 {
reg = <0x32e40000 0x200>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MM_CLK_USB1_CTRL_ROOT>;
- clock-names = "usb1_ctrl_root_clk";
assigned-clocks = <&clk IMX8MM_CLK_USB_BUS>;
assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_500M>;
phys = <&usbphynop1>;
@@ -1274,7 +1273,6 @@ usbotg2: usb@32e50000 {
reg = <0x32e50000 0x200>;
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MM_CLK_USB1_CTRL_ROOT>;
- clock-names = "usb1_ctrl_root_clk";
assigned-clocks = <&clk IMX8MM_CLK_USB_BUS>;
assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_500M>;
phys = <&usbphynop2>;
diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
index 932c8b05c75f..f017faf87ecd 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
@@ -1213,7 +1213,6 @@ usbotg1: usb@32e40000 {
reg = <0x32e40000 0x200>;
interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clk IMX8MN_CLK_USB1_CTRL_ROOT>;
- clock-names = "usb1_ctrl_root_clk";
assigned-clocks = <&clk IMX8MN_CLK_USB_BUS>;
assigned-clock-parents = <&clk IMX8MN_SYS_PLL2_500M>;
phys = <&usbphynop1>;
--
2.34.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 0/6] Add Synopsys DesignWare HDMI RX Controller
From: Krzysztof Kozlowski @ 2024-04-03 10:21 UTC (permalink / raw)
To: Shreeya Patel, mchehab, hverkuil, hverkuil-cisco
Cc: heiko, robh, krzysztof.kozlowski+dt, conor+dt, mturquette, sboyd,
p.zabel, shawn.wen, kernel, linux-kernel, linux-media, devicetree,
linux-arm-kernel, linux-rockchip, linux-clk, linux-arm
In-Reply-To: <35e566-660d2080-1-7eb9eb00@16488675>
On 03/04/2024 11:24, Shreeya Patel wrote:
> On Thursday, March 28, 2024 04:20 IST, Shreeya Patel <shreeya.patel@collabora.com> wrote:
>
>> This series implements support for the Synopsys DesignWare
>> HDMI RX Controller, being compliant with standard HDMI 1.4b
>> and HDMI 2.0.
>>
>
> Hi Mauro and Hans,
>
> I haven't received any reviews so far. Hence, this is just a gentle reminder to review this patch series.
Why did you put clk changes here? These go via different subsystem. That
might be one of obstacles for your patchset.
Also, you sent it just a week ago and you already ping. Please relax,
and help out by reviewing other patches on the mailing lists in order to
relieve the burden of maintainers and move your patches higher up the list.
Best regards,
Krzysztof
_______________________________________________
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 4/6] arm64: dts: rockchip: Add device tree support for HDMI RX Controller
From: Krzysztof Kozlowski @ 2024-04-03 10:22 UTC (permalink / raw)
To: Shreeya Patel, heiko, mchehab, robh, krzysztof.kozlowski+dt,
conor+dt, mturquette, sboyd, p.zabel, jose.abreu, nelson.costa,
dmitry.osipenko, sebastian.reichel, shawn.wen, nicolas.dufresne,
hverkuil, hverkuil-cisco
Cc: kernel, linux-kernel, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-clk, linux-arm
In-Reply-To: <20240327225057.672304-5-shreeya.patel@collabora.com>
On 27/03/2024 23:50, Shreeya Patel wrote:
> Add device tree support for Synopsys DesignWare HDMI RX
> Controller.
>
> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
> Co-developed-by: Dingxian Wen <shawn.wen@rock-chips.com>
> Signed-off-by: Dingxian Wen <shawn.wen@rock-chips.com>
> Signed-off-by: Shreeya Patel <shreeya.patel@collabora.com>
> ---
> Changes in v3 :-
> - Rename cma node and phandle names
> - Elaborate the comment to explain 160MiB calculation
> - Move &hdmi_receiver_cma to the rock5b dts file
>
> Changes in v2 :-
> - Fix some of the checkpatch errors and warnings
> - Rename resets, vo1-grf and HPD
> - Move hdmirx_cma node to the rk3588.dtsi file
>
> .../boot/dts/rockchip/rk3588-pinctrl.dtsi | 41 ++++++++++++++
> .../boot/dts/rockchip/rk3588-rock-5b.dts | 19 +++++++
> arch/arm64/boot/dts/rockchip/rk3588.dtsi | 56 +++++++++++++++++++
Please do not engage multiple subsystems in one patchset, if not
necessary. Especially do not mix DTS into media or USB subsystems. And
do not put DTS in the middle!
This is not a correct way to upstream DTS. DTS is independent of
drivers, so your drivers cannot be based on this.
Please reach to your experienced colleagues to explain you how
submission of patches should look like.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox