[PATCH 6/9] dma-mapping: remove
Just provide a weak default definition of dma_contiguous_early_fixup and
let arm override it.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/dma-contiguous.h | 15 ---
arch/arm/mm/dma-mapping.c | 1 -
include/asm-generic/Kbuild| 1 -
include/asm-generic/dma-contiguous.h | 10 --
include/linux/dma-map-ops.h | 2 ++
kernel/dma/contiguous.c | 6 +-
6 files changed, 7 insertions(+), 28 deletions(-)
delete mode 100644 arch/arm/include/asm/dma-contiguous.h
delete mode 100644 include/asm-generic/dma-contiguous.h
diff --git a/arch/arm/include/asm/dma-contiguous.h
b/arch/arm/include/asm/dma-contiguous.h
deleted file mode 100644
index d785187a6f8ac1..00
--- a/arch/arm/include/asm/dma-contiguous.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef ASMARM_DMA_CONTIGUOUS_H
-#define ASMARM_DMA_CONTIGUOUS_H
-
-#ifdef __KERNEL__
-#ifdef CONFIG_DMA_CMA
-
-#include
-
-void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size);
-
-#endif
-#endif
-
-#endif
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 154c24cec94c74..911fc6ea26071e 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -34,7 +34,6 @@
#include
#include
#include
-#include
#include
#include "dma.h"
diff --git a/include/asm-generic/Kbuild b/include/asm-generic/Kbuild
index 74b0612601dd1b..62ebdc731ee239 100644
--- a/include/asm-generic/Kbuild
+++ b/include/asm-generic/Kbuild
@@ -16,7 +16,6 @@ mandatory-y += current.h
mandatory-y += delay.h
mandatory-y += device.h
mandatory-y += div64.h
-mandatory-y += dma-contiguous.h
mandatory-y += dma-mapping.h
mandatory-y += dma.h
mandatory-y += emergency-restart.h
diff --git a/include/asm-generic/dma-contiguous.h
b/include/asm-generic/dma-contiguous.h
deleted file mode 100644
index f24b0f9a4f05b6..00
--- a/include/asm-generic/dma-contiguous.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_GENERIC_DMA_CONTIGUOUS_H
-#define _ASM_GENERIC_DMA_CONTIGUOUS_H
-
-#include
-
-static inline void
-dma_contiguous_early_fixup(phys_addr_t base, unsigned long size) { }
-
-#endif
diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h
index 474fc81bd4921c..7912f5d00ed950 100644
--- a/include/linux/dma-map-ops.h
+++ b/include/linux/dma-map-ops.h
@@ -116,6 +116,8 @@ bool dma_release_from_contiguous(struct device *dev, struct
page *pages,
int count);
struct page *dma_alloc_contiguous(struct device *dev, size_t size, gfp_t gfp);
void dma_free_contiguous(struct device *dev, struct page *page, size_t size);
+
+void dma_contiguous_early_fixup(phys_addr_t base, unsigned long size);
#else /* CONFIG_DMA_CMA */
static inline struct cma *dev_get_cma_area(struct device *dev)
{
diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c
index 6bfb763fff6fca..a2ee330a3749ec 100644
--- a/kernel/dma/contiguous.c
+++ b/kernel/dma/contiguous.c
@@ -44,7 +44,6 @@
#endif
#include
-#include
#include
#include
@@ -212,6 +211,11 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
}
}
+void __weak
+dma_contiguous_early_fixup(phys_addr_t base, unsigned long size)
+{
+}
+
/**
* dma_contiguous_reserve_area() - reserve custom contiguous area
* @size: Size of the reserved area (in bytes),
--
2.28.0
[PATCH 8/9] dma-mapping: move large parts of to kernel/dma
Most of the dma_direct symbols should only be used by direct.c and
mapping.c, so move them to kernel/dma. In fact more of dma-direct.h
should eventually move, but that will require more coordination with
other subsystems.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 106 -
kernel/dma/direct.c| 2 +-
kernel/dma/direct.h| 119 +
kernel/dma/mapping.c | 2 +-
4 files changed, 121 insertions(+), 108 deletions(-)
create mode 100644 kernel/dma/direct.h
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 38ed3b55034d50..a2d6640c42c04e 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -120,114 +120,8 @@ struct page *dma_direct_alloc_pages(struct device *dev,
size_t size,
void dma_direct_free_pages(struct device *dev, size_t size,
struct page *page, dma_addr_t dma_addr,
enum dma_data_direction dir);
-int dma_direct_get_sgtable(struct device *dev, struct sg_table *sgt,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs);
-bool dma_direct_can_mmap(struct device *dev);
-int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
- void *cpu_addr, dma_addr_t dma_addr, size_t size,
- unsigned long attrs);
int dma_direct_supported(struct device *dev, u64 mask);
-bool dma_direct_need_sync(struct device *dev, dma_addr_t dma_addr);
-int dma_direct_map_sg(struct device *dev, struct scatterlist *sgl, int nents,
- enum dma_data_direction dir, unsigned long attrs);
dma_addr_t dma_direct_map_resource(struct device *dev, phys_addr_t paddr,
size_t size, enum dma_data_direction dir, unsigned long attrs);
-size_t dma_direct_max_mapping_size(struct device *dev);
-#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE) || \
-defined(CONFIG_SWIOTLB)
-void dma_direct_sync_sg_for_device(struct device *dev, struct scatterlist *sgl,
- int nents, enum dma_data_direction dir);
-#else
-static inline void dma_direct_sync_sg_for_device(struct device *dev,
- struct scatterlist *sgl, int nents, enum dma_data_direction dir)
-{
-}
-#endif
-
-#if defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU) || \
-defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL) || \
-defined(CONFIG_SWIOTLB)
-void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sgl,
- int nents, enum dma_data_direction dir, unsigned long attrs);
-void dma_direct_sync_sg_for_cpu(struct device *dev,
- struct scatterlist *sgl, int nents, enum dma_data_direction
dir);
-#else
-static inline void dma_direct_unmap_sg(struct device *dev,
- struct scatterlist *sgl, int nents, enum dma_data_direction dir,
- unsigned long attrs)
-{
-}
-static inline void dma_direct_sync_sg_for_cpu(struct device *dev,
- struct scatterlist *sgl, int nents, enum dma_data_direction dir)
-{
-}
-#endif
-
-static inline void dma_direct_sync_single_for_device(struct device *dev,
- dma_addr_t addr, size_t size, enum dma_data_direction dir)
-{
- phys_addr_t paddr = dma_to_phys(dev, addr);
-
- if (unlikely(is_swiotlb_buffer(paddr)))
- swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_DEVICE);
-
- if (!dev_is_dma_coherent(dev))
- arch_sync_dma_for_device(paddr, size, dir);
-}
-
-static inline void dma_direct_sync_single_for_cpu(struct device *dev,
- dma_addr_t addr, size_t size, enum dma_data_direction dir)
-{
- phys_addr_t paddr = dma_to_phys(dev, addr);
-
- if (!dev_is_dma_coherent(dev)) {
- arch_sync_dma_for_cpu(paddr, size, dir);
- arch_sync_dma_for_cpu_all();
- }
-
- if (unlikely(is_swiotlb_buffer(paddr)))
- swiotlb_tbl_sync_single(dev, paddr, size, dir, SYNC_FOR_CPU);
-
- if (dir == DMA_FROM_DEVICE)
- arch_dma_mark_clean(paddr, size);
-}
-
-static inline dma_addr_t dma_direct_map_page(struct device *dev,
- struct page *page, unsigned long offset, size_t size,
- enum dma_data_direction dir, unsigned long attrs)
-{
- phys_addr_t phys = page_to_phys(page) + offset;
- dma_addr_t dma_addr = phys_to_dma(dev, phys);
-
- if (unlikely(swiotlb_force == SWIOTLB_FORCE))
- return swiotlb_map(dev, phys, size, dir, attrs);
-
- if (unlikely(!dma_capable(dev, dma_addr, size, true))) {
- if (swiotlb_force != SWIOTLB_NO_FORCE)
- return swiotlb_map(dev, phys, size, dir, attrs);
-
- dev_WARN_ONCE(dev, 1,
-"DMA addr %pad+%zu overflow (mask %llx, bus limit
%llx).\n",
-&dma_addr, size, *dev->dma_mask,
dev->bus_dma_limit);
- return DMA_MAPPING_ERROR;
- }
-
- if (!dev_is_dma
[PATCH 2/9] dma-contiguous: remove dma_declare_contiguous
dma_declare_contiguous is a trivial wrapper around
dma_contiguous_reserve_area and just has a single caller.
Signed-off-by: Christoph Hellwig
---
arch/arm/mach-davinci/devices-da8xx.c | 16 +-
include/linux/dma-contiguous.h| 32 ---
2 files changed, 10 insertions(+), 38 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index feb206bdf6e172..2e2853582b459e 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -884,6 +884,7 @@ early_param("rproc_mem", early_rproc_mem);
void __init da8xx_rproc_reserve_cma(void)
{
+ struct cma *cma;
int ret;
if (!rproc_base || !rproc_size) {
@@ -897,13 +898,16 @@ void __init da8xx_rproc_reserve_cma(void)
pr_info("%s: reserving 0x%lx @ 0x%lx...\n",
__func__, rproc_size, (unsigned long)rproc_base);
- ret = dma_declare_contiguous(&da8xx_dsp.dev, rproc_size, rproc_base, 0);
- if (ret)
- pr_err("%s: dma_declare_contiguous failed %d\n", __func__, ret);
- else
- rproc_mem_inited = true;
+ ret = dma_contiguous_reserve_area(rproc_size, rproc_base, 0, &cma,
+ true);
+ if (ret) {
+ pr_err("%s: dma_contiguous_reserve_area failed %d\n",
+ __func__, ret);
+ return;
+ }
+ dev_set_cma_area(&da8xx_dsp.dev, cma);
+ rproc_mem_inited = true;
}
-
#else
void __init da8xx_rproc_reserve_cma(void)
diff --git a/include/linux/dma-contiguous.h b/include/linux/dma-contiguous.h
index fe55e004f1f433..62fd55d0723546 100644
--- a/include/linux/dma-contiguous.h
+++ b/include/linux/dma-contiguous.h
@@ -83,31 +83,6 @@ int __init dma_contiguous_reserve_area(phys_addr_t size,
phys_addr_t base,
phys_addr_t limit, struct cma **res_cma,
bool fixed);
-/**
- * dma_declare_contiguous() - reserve area for contiguous memory handling
- * for particular device
- * @dev: Pointer to device structure.
- * @size: Size of the reserved memory.
- * @base: Start address of the reserved memory (optional, 0 for any).
- * @limit: End address of the reserved memory (optional, 0 for any).
- *
- * This function reserves memory for specified device. It should be
- * called by board specific code when early allocator (memblock or bootmem)
- * is still activate.
- */
-
-static inline int dma_declare_contiguous(struct device *dev, phys_addr_t size,
-phys_addr_t base, phys_addr_t limit)
-{
- struct cma *cma;
- int ret;
- ret = dma_contiguous_reserve_area(size, base, limit, &cma, true);
- if (ret == 0)
- dev_set_cma_area(dev, cma);
-
- return ret;
-}
-
struct page *dma_alloc_from_contiguous(struct device *dev, size_t count,
unsigned int order, bool no_warn);
bool dma_release_from_contiguous(struct device *dev, struct page *pages,
@@ -135,13 +110,6 @@ static inline int dma_contiguous_reserve_area(phys_addr_t
size, phys_addr_t base
return -ENOSYS;
}
-static inline
-int dma_declare_contiguous(struct device *dev, phys_addr_t size,
- phys_addr_t base, phys_addr_t limit)
-{
- return -ENOSYS;
-}
-
static inline
struct page *dma_alloc_from_contiguous(struct device *dev, size_t count,
unsigned int order, bool no_warn)
--
2.28.0
Re: [PATCH printk 3/5] printk: use buffer pool for sprint buffers
On 2020-09-30, Petr Mladek wrote: >> Doubling the cost of every single printk by unconditionally doing >> vsnprintf() twice is a bad idea. > > I would prefer to solve this when there are real life problems. > printk() should not get called in performance sensitive paths in > the first place. > > We could always make the code more complicated when it can be > justified. Extra buffers is yet another layer (code and memory) > in the processing. And the current arguments sounds theoretical. I am preparing a v2 that avoids the memory pool. John Ogness
Re: [PATCH v6 2/3] remoteproc: Move recovery configuration to sysfs
On 9/30/20 10:11 AM, Arnaud POULIQUEN wrote:
>
>
> On 9/29/20 12:17 AM, Rishabh Bhatnagar wrote:
>> Move recovery configuration from debugfs to sysfs.This will
>> allow usage of this configuration feature in production
>> devices where access to debugfs might be limited.
>>
>> Signed-off-by: Rishabh Bhatnagar
>> ---
>> Documentation/ABI/testing/sysfs-class-remoteproc | 20 ++
>> drivers/remoteproc/remoteproc_debugfs.c | 78
>>
>> drivers/remoteproc/remoteproc_sysfs.c| 56 +
>> 3 files changed, 76 insertions(+), 78 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-remoteproc
>> b/Documentation/ABI/testing/sysfs-class-remoteproc
>> index f6c44fa..7368b50 100644
>> --- a/Documentation/ABI/testing/sysfs-class-remoteproc
>> +++ b/Documentation/ABI/testing/sysfs-class-remoteproc
>> @@ -82,3 +82,23 @@ Description: Remote processor coredump configuration
>> all data is read by usersapce.
>>
>> "disabled" means no dump will be collected.
>> +
>> +What: /sys/class/remoteproc/.../recovery
>> +Date: July 2020
>> +Contact:Bjorn Andersson , Ohad Ben-Cohen
>>
>> +Description:Remote processor recovery mechanism
>> +
>> +Reports the recovery mechanism of the remote processor,
>> +which will be one of:
>> +
>> +"enabled"
>> +"disabled"
>> +
>> +"enabled" means, the remote processor will be automatically
>> +recovered whenever it crashes. Moreover, if the remote
>> +processor crashes while recovery is disabled, it will
>> +be automatically recovered too as soon as recovery is enabled.
>> +
>> +"disabled" means, a remote processor will remain in a crashed
>> +state if it crashes. This is useful for debugging purposes;
>> +without it, debugging a crash is substantially harder.
>> diff --git a/drivers/remoteproc/remoteproc_debugfs.c
>> b/drivers/remoteproc/remoteproc_debugfs.c
>> index 732770e..c505f0e 100644
>> --- a/drivers/remoteproc/remoteproc_debugfs.c
>> +++ b/drivers/remoteproc/remoteproc_debugfs.c
>> @@ -84,82 +84,6 @@ static const struct file_operations rproc_name_ops = {
>> .llseek = generic_file_llseek,
>> };
>>
>> -/* expose recovery flag via debugfs */
>> -static ssize_t rproc_recovery_read(struct file *filp, char __user *userbuf,
>> - size_t count, loff_t *ppos)
>> -{
>> -struct rproc *rproc = filp->private_data;
>> -char *buf = rproc->recovery_disabled ? "disabled\n" : "enabled\n";
>> -
>> -return simple_read_from_buffer(userbuf, count, ppos, buf, strlen(buf));
>> -}
>> -
>> -/*
>> - * By writing to the 'recovery' debugfs entry, we control the behavior of
>> the
>> - * recovery mechanism dynamically. The default value of this entry is
>> "enabled".
>> - *
>> - * The 'recovery' debugfs entry supports these commands:
>> - *
>> - * enabled: When enabled, the remote processor will be automatically
>> - * recovered whenever it crashes. Moreover, if the remote
>> - * processor crashes while recovery is disabled, it will
>> - * be automatically recovered too as soon as recovery is enabled.
>> - *
>> - * disabled:When disabled, a remote processor will remain in a
>> crashed
>> - * state if it crashes. This is useful for debugging purposes;
>> - * without it, debugging a crash is substantially harder.
>> - *
>> - * recover: This function will trigger an immediate recovery if the
>> - * remote processor is in a crashed state, without changing
>> - * or checking the recovery state (enabled/disabled).
>> - * This is useful during debugging sessions, when one expects
>> - * additional crashes to happen after enabling recovery. In this
>> - * case, enabling recovery will make it hard to debug subsequent
>> - * crashes, so it's recommended to keep recovery disabled, and
>> - * instead use the "recover" command as needed.
>> - */
>> -static ssize_t
>> -rproc_recovery_write(struct file *filp, const char __user *user_buf,
>> - size_t count, loff_t *ppos)
>> -{
>> -struct rproc *rproc = filp->private_data;
>> -char buf[10];
>> -int ret;
>> -
>> -if (count < 1 || count > sizeof(buf))
>> -return -EINVAL;
>> -
>> -ret = copy_from_user(buf, user_buf, count);
>> -if (ret)
>> -return -EFAULT;
>> -
>> -/* remove end of line */
>> -if (buf[count - 1] == '\n')
>> -buf[count - 1] = '\0';
>> -
>> -if (!strncmp(buf, "enabled", count)) {
>> -/* change the flag and begin the recovery process if needed */
>> -rproc->recovery_disabled = false;
>> -rproc_trigger_recovery(rproc);
>> -} else if (!strncmp(buf, "disabled", count)) {
>> -rproc->recovery
[PATCH next v2 2/2] printk: reduce setup_text_buf size to LOG_LINE_MAX
@setup_text_buf only copies the original text messages (without any
prefix or extended text). It only needs to be LOG_LINE_MAX in size.
Signed-off-by: John Ogness
Reviewed-by: Petr Mladek
---
kernel/printk/printk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 04cf1e00478f..1538df175aae 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1103,7 +1103,7 @@ static unsigned int __init add_to_rb(struct
printk_ringbuffer *rb,
return prb_record_text_space(&e);
}
-static char setup_text_buf[CONSOLE_EXT_LOG_MAX] __initdata;
+static char setup_text_buf[LOG_LINE_MAX] __initdata;
void __init setup_log_buf(int early)
{
--
2.20.1
[PATCH next v2 0/2] printk: fix reading beyond buffer
Hello, Marek Szyprowski reported [0] a problem with a particular printk usage. This particular usage performs thousands of LOG_CONT calls. The printk.c implementation was only limiting the growing record by the maximum size available in the ringbuffer, thus creating a record that was several kilobytes in size. This in and of itself is not a problem. However, the various readers used buffers that were about 1KB in size. The ringbuffer would only fill the reader's 1KB buffer, but the meta data stated that the message was actually much larger. The reader code was not checking this and assumed its buffer contained the full message. I have solved this problem by adding the necessary check to the functions where the situation can occur and also adding an argument when extending records so that a maximum size is specified. This will prevent the records from growing beyond the size that we know our readers are using. I did not add the check where it is certain that the reader's buffer is large enough to contain the largest possible message. The 2nd patch in this series reduces the size of the initial setup buffer. I noticed it was too big while verifying all the sizes for this series. John Ogness [0] https://lkml.kernel.org/r/f1651593-3579-5820-6863-5f4973d2b...@samsung.com John Ogness (2): printk: avoid and/or handle record truncation printk: reduce setup_text_buf size to LOG_LINE_MAX kernel/printk/printk.c| 11 +-- kernel/printk/printk_ringbuffer.c | 12 ++-- kernel/printk/printk_ringbuffer.h | 2 +- 3 files changed, 20 insertions(+), 5 deletions(-) -- 2.20.1
Re: [PATCH 4.4 50/62] XEN uses irqdesc::irq_data_common::handler_data to store a per interrupt XEN data pointer which contains XEN specific information.
On 30.09.20 10:52, Stefan Bader wrote: On 29.09.20 16:05, Jürgen Groß wrote: On 29.09.20 15:13, Stefan Bader wrote: On 01.09.20 17:10, Greg Kroah-Hartman wrote: From: Thomas Gleixner commit c330fb1ddc0a922f044989492b7fcca77ee1db46 upstream. handler data is meant for interrupt handlers and not for storing irq chip specific information as some devices require handler data to store internal per interrupt information, e.g. pinctrl/GPIO chained interrupt handlers. This obviously creates a conflict of interests and crashes the machine because the XEN pointer is overwritten by the driver pointer. I cannot say whether this applies the same for the vanilla 4.4 stable kernels but once this had been applied to our 4.4 based kernels, we observed Xen HVM guests crashing on boot with: [ 0.927538] ACPI: bus type PCI registered [ 0.936008] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 0.948739] PCI: Using configuration type 1 for base access [ 0.960007] PCI: Using configuration type 1 for extended access [ 0.984340] ACPI: Added _OSI(Module Device) [ 0.988010] ACPI: Added _OSI(Processor Device) [ 0.992007] ACPI: Added _OSI(3.0 _SCP Extensions) [ 0.996013] ACPI: Added _OSI(Processor Aggregator Device) [ 1.002103] BUG: unable to handle kernel paging request at ff5f3000 [ 1.004000] IP: [] mp_irqdomain_activate+0x5f/0xa0 [ 1.004000] PGD 1e0f067 PUD 1e11067 PMD 1e12067 PTE 0 [ 1.004000] Oops: 0002 [#1] SMP [ 1.004000] Modules linked in: [ 1.004000] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.4.0-191-generic #221-Ubuntu [ 1.004000] Hardware name: Xen HVM domU, BIOS 4.6.5 04/18/2018 [ 1.004000] task: 880107db ti: 880107dac000 task.ti: 880107dac000 [ 1.004000] RIP: 0010:[] [] mp_irqdomain_activate+0x5f/0xa0 [ 1.004000] RSP: 0018:880107dafc48 EFLAGS: 00010086 [ 1.004000] RAX: 0086 RBX: 8800eb852140 RCX: [ 1.004000] RDX: ff5f3000 RSI: 0001 RDI: 0020c000 [ 1.004000] RBP: 880107dafc50 R08: 81ebdfd0 R09: [ 1.004000] R10: 0011 R11: 0009 R12: 88010880d400 [ 1.004000] R13: 0001 R14: 0009 R15: 8800eb880080 [ 1.004000] FS: () GS:880108ec() knlGS: [ 1.004000] CS: 0010 DS: ES: CR0: 80050033 [ 1.004000] CR2: ff5f3000 CR3: 01e0a000 CR4: 06f0 [ 1.004000] Stack: [ 1.004000] 88010880bc58 880107dafc70 810ea644 88010880bc00 [ 1.004000] 88010880bc58 880107dafca0 810e6d88 810e1009 [ 1.004000] 88010880bc00 88010880bca0 8800eb880080 880107dafd38 [ 1.004000] Call Trace: [ 1.004000] [] irq_domain_activate_irq+0x44/0x50 [ 1.004000] [] irq_startup+0x38/0x90 [ 1.004000] [] ? vprintk_default+0x29/0x40 [ 1.004000] [] __setup_irq+0x5a2/0x650 [ 1.004000] [] ? kmem_cache_alloc_trace+0x1d4/0x1f0 [ 1.004000] [] ? acpi_osi_handler+0xb0/0xb0 [ 1.004000] [] request_threaded_irq+0xfb/0x1a0 [ 1.004000] [] ? acpi_osi_handler+0xb0/0xb0 [ 1.004000] [] ? acpi_ev_sci_dispatch+0x64/0x64 [ 1.004000] [] acpi_os_install_interrupt_handler+0xaa/0x100 [ 1.004000] [] ? acpi_sleep_proc_init+0x28/0x28 [ 1.004000] [] acpi_ev_install_sci_handler+0x23/0x25 [ 1.004000] [] acpi_ev_install_xrupt_handlers+0x1c/0x6c [ 1.004000] [] acpi_enable_subsystem+0x8f/0x93 [ 1.004000] [] acpi_init+0x8b/0x2c4 [ 1.004000] [] ? kasprintf+0x4e/0x70 [ 1.004000] [] ? acpi_sleep_proc_init+0x28/0x28 [ 1.004000] [] do_one_initcall+0xb5/0x200 [ 1.004000] [] ? parse_args+0x29a/0x4a0 [ 1.004000] [] kernel_init_freeable+0x177/0x218 [ 1.004000] [] ? rest_init+0x80/0x80 [ 1.004000] [] kernel_init+0xe/0xe0 [ 1.004000] [] ret_from_fork+0x42/0x80 [ 1.004000] [] ? rest_init+0x80/0x80 [ 1.004000] Code: 8d 1c d2 8d ba 0b 02 00 00 44 8d 51 11 42 8b 14 dd 74 ec 10 82 c1 e7 0c 48 63 ff 81 e2 ff 0f 00 00 48 81 ea 00 10 80 00 48 29 fa <44> 89 12 89 72 10 42 8b 14 dd 74 ec 10 82 83 c1 10 81 e2 ff 0f [ 1.004000] RIP [] mp_irqdomain_activate+0x5f/0xa0 [ 1.004000] RSP [ 1.004000] CR2: ff5f3000 [ 1.004000] ---[ end trace 3201cae5b6bd7be1 ]--- [ 1.592027] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009 [ 1.592027] This is from a local server but same stack-trace happens on AWS instances while initializing ACPI SCI. mp_irqdomain_activate is accessing chip_data expecting ioapic data there. Oddly enough more recent kernels seem to do the same but not crashing as HVM guest (neither seen for our 4.15 nor the 5.4). Hmm, could it be that calling irq_set_chip_data() for a legacy irq is a rather bad idea? Could you please try the attached patch (might need some backport, but should be rather easy)? Ok, I can confirm that adding your patch (mi
[PATCH next v2 1/2] printk: avoid and/or handle record truncation
If a reader provides a buffer that is smaller than the message text,
the @text_len field of @info will have a value larger than the buffer
size. If readers blindly read @text_len bytes of data without
checking the size, they will read beyond their buffer.
Add this check to record_print_text() to properly recognize when such
truncation has occurred.
Add a maximum size argument to the ringbuffer function to extend
records so that records can not be created that are larger than the
buffer size of readers.
When extending records (LOG_CONT), do not extend records beyond
LOG_LINE_MAX since that is the maximum size available in the buffers
used by consoles and syslog.
Fixes: f5f022e53b87 ("printk: reimplement log_cont using record extension")
Signed-off-by: John Ogness
Reported-by: Marek Szyprowski
---
kernel/printk/printk.c| 9 -
kernel/printk/printk_ringbuffer.c | 12 ++--
kernel/printk/printk_ringbuffer.h | 2 +-
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index 78f68b4830dc..04cf1e00478f 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -1357,6 +1357,13 @@ static size_t record_print_text(struct printk_record *r,
bool syslog,
size_t len = 0;
char *next;
+ /*
+* If the message was truncated because the buffer was not large
+* enough, treat the available text as if it were the full text.
+*/
+ if (text_len > buf_size)
+ text_len = buf_size;
+
prefix_len = info_print_prefix(r->info, syslog, time, prefix);
/*
@@ -1911,7 +1918,7 @@ static size_t log_output(int facility, int level, enum
log_flags lflags,
struct printk_record r;
prb_rec_init_wr(&r, text_len);
- if (prb_reserve_in_last(&e, prb, &r, caller_id)) {
+ if (prb_reserve_in_last(&e, prb, &r, caller_id, LOG_LINE_MAX)) {
memcpy(&r.text_buf[r.info->text_len], text, text_len);
r.info->text_len += text_len;
if (lflags & LOG_NEWLINE) {
diff --git a/kernel/printk/printk_ringbuffer.c
b/kernel/printk/printk_ringbuffer.c
index 13b94b92342e..2493348a1631 100644
--- a/kernel/printk/printk_ringbuffer.c
+++ b/kernel/printk/printk_ringbuffer.c
@@ -202,7 +202,8 @@
* // specify additional 5 bytes text space to extend
* prb_rec_init_wr(&r, 5);
*
- * if (prb_reserve_in_last(&e, &test_rb, &r, printk_caller_id())) {
+ * // try to extend, but only if it does not exceed 32 bytes
+ * if (prb_reserve_in_last(&e, &test_rb, &r, printk_caller_id()), 32) {
* snprintf(&r.text_buf[r.info->text_len],
* r.text_buf_size - r.info->text_len, "hello");
*
@@ -1309,6 +1310,7 @@ static struct prb_desc *desc_reopen_last(struct
prb_desc_ring *desc_ring,
* @rb:The ringbuffer to re-reserve and extend data in.
* @r: The record structure to allocate buffers for.
* @caller_id: The caller ID of the caller (reserving writer).
+ * @max_size: Fail if the extended size would be greater than this.
*
* This is the public function available to writers to re-reserve and extend
* data.
@@ -1343,7 +1345,7 @@ static struct prb_desc *desc_reopen_last(struct
prb_desc_ring *desc_ring,
*@r->info->text_len after concatenating.
*/
bool prb_reserve_in_last(struct prb_reserved_entry *e, struct
printk_ringbuffer *rb,
-struct printk_record *r, u32 caller_id)
+struct printk_record *r, u32 caller_id, unsigned int
max_size)
{
struct prb_desc_ring *desc_ring = &rb->desc_ring;
struct printk_info *info;
@@ -1389,6 +1391,9 @@ bool prb_reserve_in_last(struct prb_reserved_entry *e,
struct printk_ringbuffer
if (!data_check_size(&rb->text_data_ring, r->text_buf_size))
goto fail;
+ if (r->text_buf_size > max_size)
+ goto fail;
+
r->text_buf = data_alloc(rb, &rb->text_data_ring,
r->text_buf_size,
&d->text_blk_lpos, id);
} else {
@@ -1410,6 +1415,9 @@ bool prb_reserve_in_last(struct prb_reserved_entry *e,
struct printk_ringbuffer
if (!data_check_size(&rb->text_data_ring, r->text_buf_size))
goto fail;
+ if (r->text_buf_size > max_size)
+ goto fail;
+
r->text_buf = data_realloc(rb, &rb->text_data_ring,
r->text_buf_size,
&d->text_blk_lpos, id);
}
diff --git a/kernel/printk/printk_ringbuffer.h
b/kernel/printk/printk_ringbuffer.h
index 0adaa685d1ca..5dc9d022db07 100644
--- a/kernel/printk/printk_ringbuffer.h
+++ b/kernel/printk/printk_ringbuffer.h
@@ -303,7 +303,7 @@ static inline void prb_rec_init_wr(struct printk_record *r,
bool prb_reserv
Re: linux-next: build failure after merge of the drm tree
On Mon, Sep 28, 2020 at 03:31:28PM +0200, Paul Cercueil wrote: > It's allocated with dma_alloc_wc, but then it's only accessed as > non-coherent. > > Anyway, for the time being I guess you could revert 37054fc81443. But I > have patches on top of it in drm-misc-next so it's going to be a mess. > > If we have time I can come up with a custom dumb_create() fonction, to make > sure that the GEM buffers are allocated with dma_alloc_noncoherent(). Is > there a dma_mmap_noncoherent() too? Please use the lower-level dma_alloc_pages and then just insert the pages directly using remap_pfn_range. Although it might make sense to eventually create a wrapper around remap_pfn_range for all the vma sizing sanity checks. > > -Paul > ---end quoted text---
[RESEND PATCH] ARM: dts: aspeed-g6: Fix gpio memory region
Signed-off-by: Billy Tsai --- arch/arm/boot/dts/aspeed-g6.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi index 97ca743363d7..b9ec8b579f73 100644 --- a/arch/arm/boot/dts/aspeed-g6.dtsi +++ b/arch/arm/boot/dts/aspeed-g6.dtsi @@ -357,7 +357,7 @@ #gpio-cells = <2>; gpio-controller; compatible = "aspeed,ast2600-gpio"; - reg = <0x1e78 0x800>; + reg = <0x1e78 0x500>; interrupts = ; gpio-ranges = <&pinctrl 0 0 208>; ngpios = <208>; -- 2.17.1
Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()
"On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
>
> From: Dmitry Osipenko
>
> Multiple Tegra drivers need to retrieve Memory Controller and hence there
> is quite some duplication of the retrieval code among the drivers. Let's
> add a new common helper for the retrieval of the MC.
>
> Signed-off-by: Dmitry Osipenko
> Signed-off-by: Nicolin Chen
> ---
>
> Changelog
> v2->v3:
> * Replaced with Dimtry's devm_tegra_get_memory_controller()
> v1->v2:
> * N/A
>
> drivers/memory/tegra/mc.c | 39 +++
> include/soc/tegra/mc.h| 17 +
> 2 files changed, 56 insertions(+)
>
> diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> index ec8403557ed4..dd691dc3738e 100644
> --- a/drivers/memory/tegra/mc.c
> +++ b/drivers/memory/tegra/mc.c
> @@ -42,6 +42,45 @@ static const struct of_device_id tegra_mc_of_match[] = {
> };
> MODULE_DEVICE_TABLE(of, tegra_mc_of_match);
>
> +static void tegra_mc_devm_action_put_device(void *data)
devm_tegra_memory_controller_put()
> +{
> + struct tegra_mc *mc = data;
> +
> + put_device(mc->dev);
> +}
> +
> +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
Usually 'get' is a suffix (e.g. clk, gpiod, iio, led), so:
devm_tegra_memory_controller_get()
> +{
> + struct platform_device *pdev;
> + struct device_node *np;
> + struct tegra_mc *mc;
> + int err;
> +
> + np = of_find_matching_node_and_match(NULL, tegra_mc_of_match, NULL);
> + if (!np)
> + return ERR_PTR(-ENOENT);
> +
> + pdev = of_find_device_by_node(np);
> + of_node_put(np);
> + if (!pdev)
> + return ERR_PTR(-ENODEV);
> +
> + mc = platform_get_drvdata(pdev);
> + if (!mc) {
> + put_device(mc->dev);
> + return ERR_PTR(-EPROBE_DEFER);
> + }
> +
> + err = devm_add_action(dev, tegra_mc_devm_action_put_device, mc);
> + if (err) {
> + put_device(mc->dev);
> + return ERR_PTR(err);
> + }
> +
> + return mc;
> +}
> +EXPORT_SYMBOL_GPL(devm_tegra_get_memory_controller);
> +
> static int tegra_mc_block_dma_common(struct tegra_mc *mc,
> const struct tegra_mc_reset *rst)
> {
> diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
> index 1238e35653d1..c05142e3e244 100644
> --- a/include/soc/tegra/mc.h
> +++ b/include/soc/tegra/mc.h
> @@ -184,4 +184,21 @@ struct tegra_mc {
> int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long
> rate);
> unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
>
> +#ifdef CONFIG_TEGRA_MC
> +/**
> + * devm_tegra_get_memory_controller() - Get the tegra_mc pointer.
> + * @dev: Device that will be interacted with
This is not precise enough and there is no interaction with 'dev' in
devm_tegra_get_memory_controller(). Something like: "Device that owns
the pointer to tegra memory controller"
> + *
> + * Return: ERR_PTR() on error or a valid pointer to a struct tegra_mc.
> + *
> + * The mc->dev counter will be automatically put by the device management
> code.
1. s/mc/tegra_mc/ (it's the first occurence of word mc here)
2. "kerneldoc goes to the C file". Not to the header.
Best regards,
Krzysztof
Re: [PATCH 2/3] exfat: remove useless check in exfat_move_file()
Are you busy now? I'm sorry, I'm so busy for my full time work :( Anyway, I'm trying to review serious bug patches or bug reports first. Other patches, such as clean-up or code refactoring, may take some time to review. I'll try to reduce your burden as much as possible. I am waiting for your reply about "integrates dir-entry getting and validation" patch. As I know, your patch is being under review by Namjae. OK. I'll discuss it with him. If possible, please let me know your opinion. BR --- Tetsuhiro Kohada
Re: [PATCH] ACPI / NUMA: Add stub function for pxm_to_node
On 2020/9/29 3:45, Nathan Chancellor wrote:
After commit 01feba590cd6 ("ACPI: Do not create new NUMA domains from
ACPI static tables that are not SRAT"):
$ scripts/config --file arch/x86/configs/x86_64_defconfig -d NUMA -e ACPI_NFIT
$ make -skj"$(nproc)" distclean defconfig drivers/acpi/nfit/
drivers/acpi/nfit/core.c: In function ‘acpi_nfit_register_region’:
drivers/acpi/nfit/core.c:3010:27: error: implicit declaration of
function ‘pxm_to_node’; did you mean ‘xa_to_node’?
[-Werror=implicit-function-declaration]
3010 | ndr_desc->target_node = pxm_to_node(spa->proximity_domain);
| ^~~
| xa_to_node
cc1: some warnings being treated as errors
...
Add a stub function like acpi_map_pxm_to_node had so that the build
continues to work.
Fixes: 01feba590cd6 ("ACPI: Do not create new NUMA domains from ACPI static tables
that are not SRAT")
Signed-off-by: Nathan Chancellor
---
I am not sure if this is the right place or value for this. It looks
like there is going to be another stub function added here, which is
going through -mm:
https://lkml.kernel.org/r/159643094925.4062302.14979872973043772305.st...@dwillia2-desk3.amr.corp.intel.com
include/acpi/acpi_numa.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/acpi/acpi_numa.h b/include/acpi/acpi_numa.h
index fdebcfc6c8df..09eb3bc20ff5 100644
--- a/include/acpi/acpi_numa.h
+++ b/include/acpi/acpi_numa.h
@@ -22,5 +22,10 @@ extern int acpi_numa __initdata;
extern void bad_srat(void);
extern int srat_disabled(void);
+#else/* CONFIG_ACPI_NUMA */
+static inline int pxm_to_node(int pxm)
+{
+ return 0;
+}
#endif/* CONFIG_ACPI_NUMA */
#endif/* __ACP_NUMA_H */
Looks good to me,
Reviewed-by: Hanjun Guo
Re: [PATCH v13 15/15] mtd: spi-nor: micron-st: allow using MT35XU512ABA in Octal DTR mode
On 9/16/20 3:44 PM, Pratyush Yadav wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the > content is safe > > Since this flash doesn't have a Profile 1.0 table, the Octal DTR > capabilities are enabled in the post SFDP fixup, along with the 8D-8D-8D > fast read settings. > > Enable Octal DTR mode with 20 dummy cycles to allow running at the > maximum supported frequency of 200Mhz. > > The flash supports the soft reset sequence. So, add the flag in the > flash's info. > > Signed-off-by: Pratyush Yadav > --- > drivers/mtd/spi-nor/micron-st.c | 102 +++- > 1 file changed, 101 insertions(+), 1 deletion(-) > > diff --git a/drivers/mtd/spi-nor/micron-st.c b/drivers/mtd/spi-nor/micron-st.c > index ef3695080710..cc02c1418d1d 100644 > --- a/drivers/mtd/spi-nor/micron-st.c > +++ b/drivers/mtd/spi-nor/micron-st.c > @@ -8,10 +8,110 @@ similar comments to those in 14/15 apply here as well. Looks good. I couldn't find datasheets for neither of flashes though. Cheers, ta
[PATCH 04/18] dmaengine: dmatest: Use dmaengine_get_dma_device
By using the dmaengine_get_dma_device() to get the device for
dma_api use, the dmatest can support per channel coherency if it is
supported by the DMA controller.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/dmatest.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index a3a172173e34..f696246f57fd 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -573,6 +573,7 @@ static int dmatest_func(void *data)
struct dmatest_params *params;
struct dma_chan *chan;
struct dma_device *dev;
+ struct device *dma_dev;
unsigned interror_count;
unsigned intfailed_tests = 0;
unsigned inttotal_tests = 0;
@@ -606,6 +607,8 @@ static int dmatest_func(void *data)
params = &info->params;
chan = thread->chan;
dev = chan->device;
+ dma_dev = dmaengine_get_dma_device(chan);
+
src = &thread->src;
dst = &thread->dst;
if (thread->type == DMA_MEMCPY) {
@@ -730,7 +733,7 @@ static int dmatest_func(void *data)
filltime = ktime_add(filltime, diff);
}
- um = dmaengine_get_unmap_data(dev->dev, src->cnt + dst->cnt,
+ um = dmaengine_get_unmap_data(dma_dev, src->cnt + dst->cnt,
GFP_KERNEL);
if (!um) {
failed_tests++;
@@ -745,10 +748,10 @@ static int dmatest_func(void *data)
struct page *pg = virt_to_page(buf);
unsigned long pg_off = offset_in_page(buf);
- um->addr[i] = dma_map_page(dev->dev, pg, pg_off,
+ um->addr[i] = dma_map_page(dma_dev, pg, pg_off,
um->len, DMA_TO_DEVICE);
srcs[i] = um->addr[i] + src->off;
- ret = dma_mapping_error(dev->dev, um->addr[i]);
+ ret = dma_mapping_error(dma_dev, um->addr[i]);
if (ret) {
result("src mapping error", total_tests,
src->off, dst->off, len, ret);
@@ -763,9 +766,9 @@ static int dmatest_func(void *data)
struct page *pg = virt_to_page(buf);
unsigned long pg_off = offset_in_page(buf);
- dsts[i] = dma_map_page(dev->dev, pg, pg_off, um->len,
+ dsts[i] = dma_map_page(dma_dev, pg, pg_off, um->len,
DMA_BIDIRECTIONAL);
- ret = dma_mapping_error(dev->dev, dsts[i]);
+ ret = dma_mapping_error(dma_dev, dsts[i]);
if (ret) {
result("dst mapping error", total_tests,
src->off, dst->off, len, ret);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 00/18] dmaengine/soc: k3-udma: Add support for BCDMA and PKTDMA
Hi, The series have build dependency on ti_sci/soc series (v1): https://lore.kernel.org/lkml/20200928083429.17390-1-peter.ujfal...@ti.com/ The unmapped event handling in INTA is also needed, but it is not a build dependency (v2): https://lore.kernel.org/lkml/20200930074559.18028-1-peter.ujfal...@ti.com/ The DMSS introduced within AM64 as a simplified Data movement engine is built on similar grounds as the K3 NAVSS and UDMAP, but with significant architectural changes. - Rings are built into the DMAs The DMAs no longer use the general purpose ringacc, all rings has been moved inside of the DMAs. The new rings within the DMAs are simplified to be dual directional compared to the uni-directional rings in ringacc. There is no more of a concept of generic purpose rings, all rings are assigned to specific channels or flows. - Per channel coherency support The DMAs use the 'ASEL' bits to select data and configuration fetch path. The ASEL bits are placed at the unused parts of any address field used by the DMAs (pointers to descriptors, addresses in descriptors, ring base addresses). The ASEL is not part of the address (the DMAs can address 48bits). Individual channels can be configured to be coherent (via ACP port) or non coherent individually by configuring the ASEL to appropriate value. - Two different DMAs (well, three actually) PKTDMA Similar to UDMAP channels configured in packet mode. The flow configuration of the channels has changed significantly in a way that each channel have at least one flow assigned at design time and each flow is directly mapped to corresponding ring. When multiple flows are set, the channel can only use the flows within it's assigned range. PKTDMA also introduced multiple tflows which did not existed in UDMAP. BCDMA It has two types of channels: - split channels (tchan/rchan): Similar to UDMAP channels configured in TR mode. - Block copy channels (bchan): Similar to EDMA or traditional DMA channels, they can be used for mem2mem type of transfers or to service peripherals not accessible via PSI-L by using external triggers for the TR. BCDMA channels do not have support for multiple flows With the introduction of the new DMAs (especially the BCDMA) we also need to update the resource manager code to support the second range from sysfw for UDMA channels. The two outstanding change in the series in my view is the handling of the DMAs sideband signal of ASEL to select path to provide coherency or non coherency. the smaller one is the device_router_config callback to allow the configuration of the triggers when BCDMA is servicing a triggering peripheral to solve a chicken-egg situation: The router needs to know the event number to send which in turn depends on the channel we got for servicing the peripheral. I'm sending this series as early as possible to have time for review and changes. When all things resolved, it would be nice if Santosh could create an immutable branch with the ti_sci/soc patches for Vinod to use for this series. Regards, Peter --- Grygorii Strashko (1): soc: ti: k3-ringacc: add AM64 DMA rings support. Peter Ujfalusi (16): dmaengine: of-dma: Add support for optional router configuration callback dmaengine: Add support for per channel coherency handling dmaengine: doc: client: Update for dmaengine_get_dma_device() usage dmaengine: dmatest: Use dmaengine_get_dma_device dmaengine: ti: k3-udma: Wait for peer teardown completion if supported dmaengine: ti: k3-udma: Add support for second resource range from sysfw dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings dt-bindings: dma: ti: Add document for K3 BCDMA dt-bindings: dma: ti: Add document for K3 PKTDMA dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMA dmaengine: ti: k3-psil: Add initial map for AM64 dmaengine: ti: Add support for k3 event routers dmaengine: ti: k3-udma: Initial support for K3 BCDMA dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling dmaengine: ti: k3-udma: Initial support for K3 PKTDMA Vignesh Raghavendra (1): dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA .../devicetree/bindings/dma/ti/k3-bcdma.yaml | 183 ++ .../devicetree/bindings/dma/ti/k3-pktdma.yaml | 189 ++ Documentation/driver-api/dmaengine/client.rst |4 +- drivers/dma/dmatest.c | 13 +- drivers/dma/of-dma.c | 10 + drivers/dma/ti/Makefile |3 +- drivers/dma/ti/k3-psil-am64.c | 75 + drivers/dma/ti/k3-psil-priv.h |1 + drivers/dma/ti/k3-psil.c |1 + drivers/dma/ti/k3-udma-glue.c | 294 ++- drivers/dma/ti/k3-udma-private.c | 39 + drivers/dma/ti/k3-udma.c | 1975 +++-- drivers/dma/ti/k3-udma.h | 27 +- drivers/soc/ti
[PATCH 02/18] dmaengine: Add support for per channel coherency handling
If the DMA device supports per channel coherency configuration (a channel
can be configured to have coherent or not coherent view) then a single
device (the DMA controller's device) can not be used for dma_api for all
channels as channels can have different coherency.
Introduce custom_dma_mapping flag for the dma_chan and a new helper to get
the device pointer to be used for dma_api for the given channel.
Client drivers should be updated to be able to support per channel
coherency by:
- dma_map_single(chan->device->dev, ptr, size, DMA_TO_DEVICE);
+ struct device *dma_dev = dmaengine_get_dma_device(chan);
+
+ dma_map_single(dma_dev, ptr, size, DMA_TO_DEVICE);
Signed-off-by: Peter Ujfalusi
---
include/linux/dmaengine.h | 12
1 file changed, 12 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index d6197fe875af..182a1a2e7793 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -357,11 +357,14 @@ struct dma_chan {
* @chan: driver channel device
* @device: sysfs device
* @dev_id: parent dma_device dev_id
+ * @chan_dma_dev: The channel is using custom/different dma-mapping
+ * compared to the parent dma_device
*/
struct dma_chan_dev {
struct dma_chan *chan;
struct device device;
int dev_id;
+ bool chan_dma_dev;
};
/**
@@ -1613,4 +1616,13 @@ dmaengine_get_direction_text(enum dma_transfer_direction
dir)
return "invalid";
}
}
+
+static inline struct device *dmaengine_get_dma_device(struct dma_chan *chan)
+{
+ if (chan->dev->chan_dma_dev)
+ return &chan->dev->device;
+
+ return chan->device->dev;
+}
+
#endif /* DMAENGINE_H */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 03/18] dmaengine: doc: client: Update for dmaengine_get_dma_device() usage
Client drivers should use the dmaengine_get_dma_device(chan) to get the device pointer which should be used for DMA API for allocations and mapping. Signed-off-by: Peter Ujfalusi --- Documentation/driver-api/dmaengine/client.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/driver-api/dmaengine/client.rst b/Documentation/driver-api/dmaengine/client.rst index 09a3f66dcd26..bfd057b21a00 100644 --- a/Documentation/driver-api/dmaengine/client.rst +++ b/Documentation/driver-api/dmaengine/client.rst @@ -120,7 +120,9 @@ The details of these operations are: .. code-block:: c - nr_sg = dma_map_sg(chan->device->dev, sgl, sg_len); + struct device *dma_dev = dmaengine_get_dma_device(chan); + + nr_sg = dma_map_sg(dma_dev, sgl, sg_len); if (nr_sg == 0) /* error */ -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Re: [PATCH v2 4/4] iio: adc: at91_adc: remove of_match_ptr() usage
On 30/09/2020 11:46:06+0300, Alexandru Ardelean wrote:
> On Wed, Sep 30, 2020 at 10:48 AM Alexandre Belloni
> wrote:
> >
> > Hi,
> >
> > On 30/09/2020 09:00:08+0300, Alexandru Ardelean wrote:
> > > Since the driver should be allowed to build without OF support, the
> > > of_match_ptr() is redundant.
> > >
> >
> > This can probably be squashed with the previous commit.
> >
> > Also, I think that you should really make the driver DT only else, the
> > driver will carry dead code and there will be no reminder that a cleanup
> > is needed.
> >
> > I can take care of that if you feel that this is more work than what you
> > wanted to spend on this driver.
>
> Ah, you're saying remove the old pdata?
Yes, since you are making the driver DT only, the pdata has to be
removed, don't forget to also remove the header file.
> I can do that while waiting for other of my patches to go in.
>
> >
> > > Signed-off-by: Alexandru Ardelean
> > > ---
> > > drivers/iio/adc/at91_adc.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_adc.c
> > > index 7d846a2852a5..473bffe84fbd 100644
> > > --- a/drivers/iio/adc/at91_adc.c
> > > +++ b/drivers/iio/adc/at91_adc.c
> > > @@ -1466,7 +1466,7 @@ static struct platform_driver at91_adc_driver = {
> > > .id_table = at91_adc_ids,
> > > .driver = {
> > > .name = DRIVER_NAME,
> > > -.of_match_table = of_match_ptr(at91_adc_dt_ids),
> > > +.of_match_table = at91_adc_dt_ids,
> > > .pm = &at91_adc_pm_ops,
> > > },
> > > };
> > > --
> > > 2.17.1
> > >
> >
> > --
> > Alexandre Belloni, Bootlin
> > Embedded Linux and Kernel engineering
> > https://bootlin.com
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[PATCH 05/18] dmaengine: ti: k3-udma: Wait for peer teardown completion if supported
Set the TDTYPE if it is supported on the platform (j721e) which will cause
UDMAP to wait for the remote peer to finish the teardown before returning
the teardown completed message.
Signed-off-by: Peter Ujfalusi
Tested-by: Keerthy
Reviewed-by: Grygorii Strashko
---
drivers/dma/ti/k3-udma.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index de7bfc02a2de..3f798993a8b1 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -86,6 +86,7 @@ struct udma_rchan {
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
+#define UDMA_FLAG_TDTYPE BIT(2)
struct udma_match_data {
u32 psil_base;
@@ -1591,6 +1592,13 @@ static int udma_tisci_tx_channel_config(struct udma_chan
*uc)
req_tx.tx_fetch_size = fetch_size >> 2;
req_tx.txcq_qnum = tc_ring;
req_tx.tx_atype = uc->config.atype;
+ if (uc->config.ep_type == PSIL_EP_PDMA_XY &&
+ ud->match_data->flags & UDMA_FLAG_TDTYPE) {
+ /* wait for peer to complete the teardown for PDMAs */
+ req_tx.valid_params |=
+ TI_SCI_MSG_VALUE_RM_UDMAP_CH_TX_TDTYPE_VALID;
+ req_tx.tx_tdtype = 1;
+ }
ret = tisci_ops->tx_ch_cfg(tisci_rm->tisci, &req_tx);
if (ret)
@@ -3107,14 +3115,14 @@ static struct udma_match_data am654_mcu_data = {
static struct udma_match_data j721e_main_data = {
.psil_base = 0x1000,
.enable_memcpy_support = true,
- .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST,
+ .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST | UDMA_FLAG_TDTYPE,
.statictr_z_mask = GENMASK(23, 0),
};
static struct udma_match_data j721e_mcu_data = {
.psil_base = 0x6000,
.enable_memcpy_support = false, /* MEM_TO_MEM is slow via MCU UDMA */
- .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST,
+ .flags = UDMA_FLAG_PDMA_ACC32 | UDMA_FLAG_PDMA_BURST | UDMA_FLAG_TDTYPE,
.statictr_z_mask = GENMASK(23, 0),
};
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 11/18] dmaengine: ti: k3-psil: Extend psil_endpoint_config for K3 PKTDMA
Additional fields needed for K3 PKTDMA to be able to handle the mapped
channels (channels are locked to handle specific threads) and flow ranges
for these mapped threads.
PKTDMA also introduces tflow for tx channels which can not be found in
K3 UDMA architecture.
Signed-off-by: Peter Ujfalusi
---
include/linux/dma/k3-psil.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/dma/k3-psil.h b/include/linux/dma/k3-psil.h
index 1962f75fa2d3..36e22c5a0f29 100644
--- a/include/linux/dma/k3-psil.h
+++ b/include/linux/dma/k3-psil.h
@@ -50,6 +50,15 @@ enum psil_endpoint_type {
* @channel_tpl: Desired throughput level for the channel
* @pdma_acc32:ACC32 must be enabled on the PDMA side
* @pdma_burst:BURST must be enabled on the PDMA side
+ * @mapped_channel_id: PKTDMA thread to channel mapping for mapped channels.
+ * The thread must be serviced by the specified channel if
+ * mapped_channel_id is >= 0 in case of PKTDMA
+ * @flow_start:PKDMA flow range start of mapped channel.
Unmapped
+ * channels use flow_id == chan_id
+ * @flow_num: PKDMA flow count of mapped channel. Unmapped channels
+ * use flow_id == chan_id
+ * @default_flow_id: PKDMA default (r)flow index of mapped channel.
+ * Must be within the flow range of the mapped channel.
*/
struct psil_endpoint_config {
enum psil_endpoint_type ep_type;
@@ -63,6 +72,13 @@ struct psil_endpoint_config {
/* PDMA properties, valid for PSIL_EP_PDMA_* */
unsigned pdma_acc32:1;
unsigned pdma_burst:1;
+
+ /* PKDMA mapped channel */
+ int mapped_channel_id;
+ /* PKTDMA tflow and rflow ranges for mapped channel */
+ u16 flow_start;
+ u16 flow_num;
+ u16 default_flow_id;
};
int psil_set_new_ep_config(struct device *dev, const char *name,
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 01/18] dmaengine: of-dma: Add support for optional router configuration callback
Additional configuration for the DMA event router might be needed for a
channel which can not be done during device_alloc_chan_resources callback
since the router information is not yet present for the drivers.
If there is a need for additional configuration for the channel if DMA
router is in use, then the driver can implement the device_router_config
callback.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/of-dma.c | 10 ++
include/linux/dmaengine.h | 2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 8a4f608904b9..ec00b20ae8e4 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -75,8 +75,18 @@ static struct dma_chan *of_dma_router_xlate(struct
of_phandle_args *dma_spec,
ofdma->dma_router->route_free(ofdma->dma_router->dev,
route_data);
} else {
+ int ret = 0;
+
chan->router = ofdma->dma_router;
chan->route_data = route_data;
+
+ if (chan->device->device_router_config)
+ ret = chan->device->device_router_config(chan);
+
+ if (ret) {
+ dma_release_channel(chan);
+ chan = ERR_PTR(ret);
+ }
}
/*
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index dd357a747780..d6197fe875af 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -800,6 +800,7 @@ struct dma_filter {
* by tx_status
* @device_alloc_chan_resources: allocate resources and return the
* number of allocated descriptors
+ * @device_router_config: optional callback for DMA router configuration
* @device_free_chan_resources: release DMA channel's resources
* @device_prep_dma_memcpy: prepares a memcpy operation
* @device_prep_dma_xor: prepares a xor operation
@@ -874,6 +875,7 @@ struct dma_device {
enum dma_residue_granularity residue_granularity;
int (*device_alloc_chan_resources)(struct dma_chan *chan);
+ int (*device_router_config)(struct dma_chan *chan);
void (*device_free_chan_resources)(struct dma_chan *chan);
struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 08/18] dmaengine: ti: k3-udma-glue: Configure the dma_dev for rings
Rings in RING mode should be using the DMA device for DMA API as in this
mode the ringacc will not access the ring memory in any ways, but the DMA
is.
Fix up the ring configuration and set the dma_dev unconditionally and let
the ringacc driver to select the correct device to use for DMA API.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index a53bc4707ae8..f39825ce288a 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -280,6 +280,10 @@ struct k3_udma_glue_tx_channel
*k3_udma_glue_request_tx_chn(struct device *dev,
goto err;
}
+ /* Set the dma_dev for the rings to be configured */
+ cfg->tx_cfg.dma_dev = k3_udma_glue_tx_get_dma_device(tx_chn);
+ cfg->txcq_cfg.dma_dev = cfg->tx_cfg.dma_dev;
+
ret = k3_ringacc_ring_cfg(tx_chn->ringtx, &cfg->tx_cfg);
if (ret) {
dev_err(dev, "Failed to cfg ringtx %d\n", ret);
@@ -589,6 +593,10 @@ static int k3_udma_glue_cfg_rx_flow(struct
k3_udma_glue_rx_channel *rx_chn,
goto err_rflow_put;
}
+ /* Set the dma_dev for the rings to be configured */
+ flow_cfg->rx_cfg.dma_dev = k3_udma_glue_rx_get_dma_device(rx_chn);
+ flow_cfg->rxfdq_cfg.dma_dev = flow_cfg->rx_cfg.dma_dev;
+
ret = k3_ringacc_ring_cfg(flow->ringrx, &flow_cfg->rx_cfg);
if (ret) {
dev_err(dev, "Failed to cfg ringrx %d\n", ret);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 14/18] soc: ti: k3-ringacc: add AM64 DMA rings support.
From: Grygorii Strashko
The DMAs in AM64 have built in rings compared to AM654/J721e/J7200 where a
separate and generic ringacc is used.
The ring SW interface is similar to ringacc with some major architectural
differences, like
They are part of the DMA (BCDMA or PKTDMA).
They are dual mode rings are modeled as pair of Rings objects which has
common configuration and memory buffer, but separate real-time control
register sets for each direction mem2dev (forward) and dev2mem (reverse).
The ringacc driver must be initialized for DMA rings use with
k3_ringacc_dmarings_init() as it is not an independent device as ringacc
is.
AM64 rings must be requested only using k3_ringacc_request_rings_pair(),
and forward ring must always be initialized/configured. After this any
other Ringacc APIs can be used without any callers changes.
Signed-off-by: Grygorii Strashko
Signed-off-by: Peter Ujfalusi
---
drivers/soc/ti/k3-ringacc.c | 325 +-
include/linux/soc/ti/k3-ringacc.h | 17 ++
2 files changed, 335 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
index 7d0b4092fce8..25eca75b859a 100644
--- a/drivers/soc/ti/k3-ringacc.c
+++ b/drivers/soc/ti/k3-ringacc.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -21,6 +22,7 @@ static LIST_HEAD(k3_ringacc_list);
static DEFINE_MUTEX(k3_ringacc_list_lock);
#define K3_RINGACC_CFG_RING_SIZE_ELCNT_MASKGENMASK(19, 0)
+#define K3_DMARING_CFG_RING_SIZE_ELCNT_MASKGENMASK(15, 0)
/**
* struct k3_ring_rt_regs - The RA realtime Control/Status Registers region
@@ -43,7 +45,13 @@ struct k3_ring_rt_regs {
u32 hwindx;
};
-#define K3_RINGACC_RT_REGS_STEP0x1000
+#define K3_RINGACC_RT_REGS_STEP0x1000
+#define K3_DMARING_RT_REGS_STEP0x2000
+#define K3_DMARING_RT_REGS_REVERSE_OFS 0x1000
+#define K3_RINGACC_RT_OCC_MASK GENMASK(20, 0)
+#define K3_DMARING_RT_OCC_TDOWN_COMPLETE BIT(31)
+#define K3_DMARING_RT_DB_ENTRY_MASKGENMASK(7, 0)
+#define K3_DMARING_RT_DB_TDOWN_ACK BIT(31)
/**
* struct k3_ring_fifo_regs - The Ring Accelerator Queues Registers region
@@ -122,6 +130,7 @@ struct k3_ring_state {
u32 occ;
u32 windex;
u32 rindex;
+ u32 tdown_complete:1;
};
/**
@@ -142,6 +151,7 @@ struct k3_ring_state {
* @use_count: Use count for shared rings
* @proxy_id: RA Ring Proxy Id (only if @K3_RINGACC_RING_USE_PROXY)
* @dma_dev: device to be used for DMA API (allocation, mapping)
+ * @asel: Address Space Select value for physical addresses
*/
struct k3_ring {
struct k3_ring_rt_regs __iomem *rt;
@@ -156,12 +166,15 @@ struct k3_ring {
u32 flags;
#define K3_RING_FLAG_BUSY BIT(1)
#define K3_RING_FLAG_SHAREDBIT(2)
+#define K3_RING_FLAG_REVERSE BIT(3)
struct k3_ring_state state;
u32 ring_id;
struct k3_ringacc *parent;
u32 use_count;
int proxy_id;
struct device *dma_dev;
+ u32 asel;
+#define K3_ADDRESS_ASEL_SHIFT 48
};
struct k3_ringacc_ops {
@@ -187,6 +200,7 @@ struct k3_ringacc_ops {
* @tisci_ring_ops: ti-sci rings ops
* @tisci_dev_id: ti-sci device id
* @ops: SoC specific ringacc operation
+ * @dma_rings: indicate DMA ring (dual ring within BCDMA/PKTDMA)
*/
struct k3_ringacc {
struct device *dev;
@@ -209,6 +223,7 @@ struct k3_ringacc {
u32 tisci_dev_id;
const struct k3_ringacc_ops *ops;
+ bool dma_rings;
};
/**
@@ -220,6 +235,21 @@ struct k3_ringacc_soc_data {
unsigned dma_ring_reset_quirk:1;
};
+static int k3_ringacc_ring_read_occ(struct k3_ring *ring)
+{
+ return readl(&ring->rt->occ) & K3_RINGACC_RT_OCC_MASK;
+}
+
+static void k3_ringacc_ring_update_occ(struct k3_ring *ring)
+{
+ u32 val;
+
+ val = readl(&ring->rt->occ);
+
+ ring->state.occ = val & K3_RINGACC_RT_OCC_MASK;
+ ring->state.tdown_complete = !!(val & K3_DMARING_RT_OCC_TDOWN_COMPLETE);
+}
+
static long k3_ringacc_ring_get_fifo_pos(struct k3_ring *ring)
{
return K3_RINGACC_FIFO_WINDOW_SIZE_BYTES -
@@ -233,12 +263,24 @@ static void *k3_ringacc_get_elm_addr(struct k3_ring
*ring, u32 idx)
static int k3_ringacc_ring_push_mem(struct k3_ring *ring, void *elem);
static int k3_ringacc_ring_pop_mem(struct k3_ring *ring, void *elem);
+static int k3_dmaring_fwd_pop(struct k3_ring *ring, void *elem);
+static int k3_dmaring_reverse_pop(struct k3_ring *ring, void *elem);
static struct k3_ring_ops k3_ring_mode_ring_ops = {
.push_tail = k3_ringacc_ring_push_mem,
.pop_head = k3_ringacc_ring_pop_mem,
};
+static struct k3_ring_ops k3_dmaring_fwd_ops = {
+ .push_tail = k3_ringacc_ring_push_mem,
+ .pop_head = k3_dm
[PATCH 13/18] dmaengine: ti: Add support for k3 event routers
In k3 architecture a DMA channel (in TR momde) can be triggered by global
events, origination from different modules.
The events for triggers can be sent from any module which is connected to
PSI-L fabric, but the event number to be sent is DMA channel specific, it
is only known after the channel itself is requested.
The router operation needs to be split up:
- route_allocate: configure the dma_spec for the DMA and store the
configuration which is needed for the router's input
- set_event: callback used by the DMA driver to set the event number for
the channel and enable the routing
Signed-off-by: Peter Ujfalusi
---
include/linux/dma/k3-event-router.h | 16
1 file changed, 16 insertions(+)
create mode 100644 include/linux/dma/k3-event-router.h
diff --git a/include/linux/dma/k3-event-router.h
b/include/linux/dma/k3-event-router.h
new file mode 100644
index ..e3f88b2f87be
--- /dev/null
+++ b/include/linux/dma/k3-event-router.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com
+ */
+
+#ifndef K3_EVENT_ROUTER_
+#define K3_EVENT_ROUTER_
+
+#include
+
+struct k3_event_route_data {
+ void *priv;
+ int (*set_event)(void *priv, u32 event);
+};
+
+#endif /* K3_EVENT_ROUTER_ */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 10/18] dt-bindings: dma: ti: Add document for K3 PKTDMA
New binding document for
Texas Instruments K3 Packet DMA (PKTDMA).
PKTDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-pktdma.yaml | 189 ++
1 file changed, 189 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
new file mode 100644
index ..75b35bd85830
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml
@@ -0,0 +1,189 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/ti/k3-pktdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 DMSS PKTDMA Device Tree Bindings
+
+maintainers:
+ - Peter Ujfalusi
+
+description: |
+ The Packet DMA (PKTDMA) is intended to perform similar functions as the
packet
+ mode channels of K3 UDMA-P.
+ PKTDMA only includes Split channels to service PSI-L based peripherals.
+
+ The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
+ with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and
the
+ legacy peripheral.
+
+ PDMAs can be configured via PKTDMA split channel's peer registers to match
+ with the configuration of the legacy peripheral.
+
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+
+properties:
+ "#dma-cells":
+const: 2
+description: |
+ The first cell is the PSI-L thread ID of the remote (to PKTDMA) end.
+ Valid ranges for thread ID depends on the data movement direction:
+ for source thread IDs (rx): 0 - 0x7fff
+ for destination thread IDs (tx): 0x8000 - 0x
+
+ Please refer to the device documentation for the PSI-L thread map and
also
+ the PSI-L peripheral chapter for the correct thread ID.
+
+ The second cell is the ASEL value for the channel
+
+ compatible:
+enum:
+ - ti,am64-dmss-pktdma
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+maxItems: 4
+
+ reg-names:
+ items:
+ - const: gcfg
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ msi-parent: true
+
+ ti,sci:
+description: phandle to TI-SCI compatible System controller node
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+
+ ti,sci-dev-id:
+description: TI-SCI device id of PKTDMA
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,sci-rm-range-tchan:
+description: |
+ Array of PKTDMA split tx channel resource subtypes for resource
allocation
+ for this host
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+# Should be enough
+maxItems: 255
+
+ ti,sci-rm-range-tflow:
+description: |
+ Array of PKTDMA split tx flow resource subtypes for resource allocation
+ for this host
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+# Should be enough
+maxItems: 255
+
+ ti,sci-rm-range-rchan:
+description: |
+ Array of PKTDMA split rx channel resource subtypes for resource
allocation
+ for this host
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+# Should be enough
+maxItems: 255
+
+ ti,sci-rm-range-rflow:
+description: |
+ Array of PKTDMA split rx flow resource subtypes for resource allocation
+ for this host
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+# Should be enough
+maxItems: 255
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - "#dma-cells"
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-rm-range-tchan
+ - ti,sci-rm-range-tflow
+ - ti,sci-rm-range-rchan
+ - ti,sci-rm-range-rflow
+
+additionalProperties: false
+
+examples:
+ - |+
+cbass_main {
+#address-cells = <2>;
+#size-cells = <2>;
+
+main_dmss {
+compatible = "simple-mfd";
+#address-cells = <2>;
+#size-cells = <2>;
+dma-ranges;
+ranges;
+
+ti,sci-dev-id = <25>;
+
+main_pktdma: dma-controller@485c {
+compatible = "ti,am64-dmss-pktdma";
+#address-cells = <2>;
+#size-cells = <2>;
+
+reg = <0x0 0x485c 0x0 0x100>,
+ <0x0 0x4a80 0x0 0x2>,
+ <0x0 0x4aa0 0x0 0x4>,
+ <0x0 0x4b80 0x0 0x40>;
+reg-names = "gcfg", "rchanrt", "tchanrt", "ringrt";
+msi-parent = <&inta_main_dmss>;
+#dma-cells = <2>;
+
+ti,sci = <&dmsc>;
+ti,sci-dev-id = <30>;
+
+ti,sci-rm-range-tchan = <0x23>, /* UNMAPP
[PATCH 09/18] dt-bindings: dma: ti: Add document for K3 BCDMA
New binding document for
Texas Instruments K3 Block Copy DMA (BCDMA).
BCDMA is introduced as part of AM64.
Signed-off-by: Peter Ujfalusi
---
.../devicetree/bindings/dma/ti/k3-bcdma.yaml | 183 ++
1 file changed, 183 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
diff --git a/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
new file mode 100644
index ..c84fb641738f
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml
@@ -0,0 +1,183 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/ti/k3-bcdma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 DMSS BCDMA Device Tree Bindings
+
+maintainers:
+ - Peter Ujfalusi
+
+description: |
+ The Block Copy DMA (BCDMA) is intended to perform similar functions as the TR
+ mode channels of K3 UDMA-P.
+ BCDMA includes block copy channels and Split channels.
+
+ Block copy channels mainly used for memory to memory transfers, but with
+ optional triggers a block copy channel can service peripherals by accessing
+ directly to memory mapped registers or area.
+
+ Split channels can be used to service PSI-L based peripherals.
+ The peripherals can be PSI-L native or legacy, non PSI-L native peripherals
+ with PDMAs. PDMA is tasked to act as a bridge between the PSI-L fabric and
the
+ legacy peripheral.
+
+ PDMAs can be configured via BCDMA split channel's peer registers to match
with
+ the configuration of the legacy peripheral.
+
+allOf:
+ - $ref: /schemas/dma/dma-controller.yaml#
+
+properties:
+ "#dma-cells":
+const: 3
+description: |
+ cell 1: type of the BCDMA channel to be used to service the peripheral:
+0 - split channel
+1 - block copy channel using global trigger 1
+2 - block copy channel using global trigger 2
+3 - block copy channel using local trigger
+
+ cell 2: parameter for the channel:
+if cell 1 is 0 (split channel):
+ PSI-L thread ID of the remote (to BCDMA) end.
+ Valid ranges for thread ID depends on the data movement direction:
+ for source thread IDs (rx): 0 - 0x7fff
+ for destination thread IDs (tx): 0x8000 - 0x
+
+ Please refer to the device documentation for the PSI-L thread map and
+ also the PSI-L peripheral chapter for the correct thread ID.
+if cell 1 is 1 or 2 (block copy channel using global trigger):
+ Unused, ignored
+
+ The trigger must be configured for the channel externally to BCDMA,
+ channels using global triggers should not be requested directly, but
+ via DMA event router.
+if cell 1 is 3 (block copy channel using local trigger):
+ bchan number of the locally triggered channel
+
+ cell 3: ASEL value for the channel
+
+ compatible:
+enum:
+ - ti,am64-dmss-bcdma
+
+ "#address-cells":
+const: 2
+
+ "#size-cells":
+const: 2
+
+ reg:
+maxItems: 5
+
+ reg-names:
+ items:
+ - const: gcfg
+ - const: bchanrt
+ - const: rchanrt
+ - const: tchanrt
+ - const: ringrt
+
+ msi-parent: true
+
+ ti,sci:
+description: phandle to TI-SCI compatible System controller node
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+
+ ti,sci-dev-id:
+description: TI-SCI device id of BCDMA
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,asel:
+description: ASEL value for non slave channels
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,sci-rm-range-bchan:
+description: |
+ Array of BCDMA block-copy channel resource subtypes for resource
+ allocation for this host
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+# Should be enough
+maxItems: 255
+
+ ti,sci-rm-range-tchan:
+description: |
+ Array of BCDMA split tx channel resource subtypes for resource allocation
+ for this host
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+# Should be enough
+maxItems: 255
+
+ ti,sci-rm-range-rchan:
+description: |
+ Array of BCDMA split rx channel resource subtypes for resource allocation
+ for this host
+allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-array
+minItems: 1
+# Should be enough
+maxItems: 255
+
+required:
+ - compatible
+ - "#address-cells"
+ - "#size-cells"
+ - "#dma-cells"
+ - reg
+ - reg-names
+ - msi-parent
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,sci-rm-range-bchan
+ - ti,sci-rm-range-tchan
+ - ti,sci-rm-range-rchan
+
+additionalProperties: false
+
+examples:
+ - |+
+cbass_main {
+#address-cells = <2>;
+#size-cells = <2>;
+
+main_dmss {
+compatible = "
[PATCH 17/18] dmaengine: ti: k3-udma: Initial support for K3 PKTDMA
One of the DMAs introduced with AM64 is the Packet DMA (PKTDMA).
It serves similar purpose as K3 UDMAP channels in packet mode, but with
notable differences, like tflow support and channels being allocated to
service specific peripherals.
The rings for the PKTDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
PKTDMA can be used to service PSI-L peripherals, similarly to
K3 UDMA channels.
Most of the driver code can be reused for PKTDMA tchan/rchan support but
new setup and allocation functions are needed to handle the differences
between the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-private.c | 9 +
drivers/dma/ti/k3-udma.c | 546 +--
drivers/dma/ti/k3-udma.h | 4 +
3 files changed, 534 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c
index 8ff7a264be03..f0cecd29cff1 100644
--- a/drivers/dma/ti/k3-udma-private.c
+++ b/drivers/dma/ti/k3-udma-private.c
@@ -82,6 +82,9 @@ EXPORT_SYMBOL(xudma_free_gp_rflow_range);
bool xudma_rflow_is_gp(struct udma_dev *ud, int id)
{
+ if (!ud->rflow_gp_map)
+ return false;
+
return !test_bit(id, ud->rflow_gp_map);
}
EXPORT_SYMBOL(xudma_rflow_is_gp);
@@ -113,6 +116,12 @@ void xudma_rflow_put(struct udma_dev *ud, struct
udma_rflow *p)
}
EXPORT_SYMBOL(xudma_rflow_put);
+int xudma_get_rflow_ring_offset(struct udma_dev *ud)
+{
+ return ud->tflow_cnt;
+}
+EXPORT_SYMBOL(xudma_get_rflow_ring_offset);
+
#define XUDMA_GET_RESOURCE_ID(res) \
int xudma_##res##_get_id(struct udma_##res *p) \
{ \
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 69f2c43354d4..bcec3d5c7be1 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -59,6 +59,7 @@ struct udma_chan;
enum k3_dma_type {
DMA_TYPE_UDMA = 0,
DMA_TYPE_BCDMA,
+ DMA_TYPE_PKTDMA,
};
enum udma_mmr {
@@ -82,6 +83,8 @@ struct udma_tchan {
int id;
struct k3_ring *t_ring; /* Transmit ring */
struct k3_ring *tc_ring; /* Transmit Completion ring */
+ int tflow_id; /* applicable only for PKTDMA */
+
};
#define udma_bchan udma_tchan
@@ -109,6 +112,10 @@ struct udma_oes_offsets {
u32 bcdma_tchan_ring;
u32 bcdma_rchan_data;
u32 bcdma_rchan_ring;
+
+ /* PKTDMA Output Event Offsets */
+ u32 pktdma_tchan_flow;
+ u32 pktdma_rchan_flow;
};
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
@@ -179,12 +186,14 @@ struct udma_dev {
int echan_cnt;
int rchan_cnt;
int rflow_cnt;
+ int tflow_cnt;
unsigned long *bchan_map;
unsigned long *tchan_map;
unsigned long *rchan_map;
unsigned long *rflow_gp_map;
unsigned long *rflow_gp_map_allocated;
unsigned long *rflow_in_use;
+ unsigned long *tflow_map;
struct udma_bchan *bchans;
struct udma_tchan *tchans;
@@ -249,6 +258,11 @@ struct udma_chan_config {
u32 tr_trigger_type;
+ /* PKDMA mapped channel */
+ int mapped_channel_id;
+ /* PKTDMA default tflow or rflow for mapped channel */
+ int default_flow_id;
+
enum dma_transfer_direction dir;
};
@@ -426,6 +440,8 @@ static void udma_reset_uchan(struct udma_chan *uc)
{
memset(&uc->config, 0, sizeof(uc->config));
uc->config.remote_thread_id = -1;
+ uc->config.mapped_channel_id = -1;
+ uc->config.default_flow_id = -1;
uc->state = UDMA_CHAN_IS_IDLE;
}
@@ -815,10 +831,16 @@ static void udma_start_desc(struct udma_chan *uc)
{
struct udma_chan_config *ucc = &uc->config;
- if (ucc->pkt_mode && (uc->cyclic || ucc->dir == DMA_DEV_TO_MEM)) {
+ if (uc->ud->match_data->type == DMA_TYPE_UDMA && ucc->pkt_mode &&
+ (uc->cyclic || ucc->dir == DMA_DEV_TO_MEM)) {
int i;
- /* Push all descriptors to ring for packet mode cyclic or RX */
+ /*
+* UDMA only: Push all descriptors to ring for packet mode
+* cyclic or RX
+* PKTDMA supports pre-linked descriptor and cyclic is not
+* supported
+*/
for (i = 0; i < uc->desc->sglen; i++)
udma_push_to_ring(uc, i);
} else {
@@ -1250,10 +1272,12 @@ static struct udma_rflow *__udma_get_rflow(struct
udma_dev *ud, int id)
if (test_bit(id, ud->rflow_in_use))
return ERR_PTR(-ENOENT);
- /* GP rflow has to be allocated first */
- if (!test_bit(id, ud->rflow_gp_map) &&
- !test_bit(id, ud->rflow_gp_map_allocated))
- return ERR_PTR(-EINVAL);
+ if (ud->rflow_gp_map) {
+ /* GP rflow has to be allocated first */
[PATCH 12/18] dmaengine: ti: k3-psil: Add initial map for AM64
Add initial PSI-L map file for AM64.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/Makefile | 3 +-
drivers/dma/ti/k3-psil-am64.c | 75 +++
drivers/dma/ti/k3-psil-priv.h | 1 +
drivers/dma/ti/k3-psil.c | 1 +
4 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma/ti/k3-psil-am64.c
diff --git a/drivers/dma/ti/Makefile b/drivers/dma/ti/Makefile
index 0c67254caee6..bd496efadff7 100644
--- a/drivers/dma/ti/Makefile
+++ b/drivers/dma/ti/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_TI_K3_UDMA_GLUE_LAYER) += k3-udma-glue.o
obj-$(CONFIG_TI_K3_PSIL) += k3-psil.o \
k3-psil-am654.o \
k3-psil-j721e.o \
- k3-psil-j7200.o
+ k3-psil-j7200.o \
+ k3-psil-am64.o
obj-$(CONFIG_TI_DMA_CROSSBAR) += dma-crossbar.o
diff --git a/drivers/dma/ti/k3-psil-am64.c b/drivers/dma/ti/k3-psil-am64.c
new file mode 100644
index ..e88f57a36ac1
--- /dev/null
+++ b/drivers/dma/ti/k3-psil-am64.c
@@ -0,0 +1,75 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Texas Instruments Incorporated - https://www.ti.com
+ * Author: Peter Ujfalusi
+ */
+
+#include
+
+#include "k3-psil-priv.h"
+
+#define PSIL_ETHERNET(x, ch, flow_base, flow_cnt) \
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 16, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = flow_base, \
+ }, \
+ }
+
+#define PSIL_SAUL(x, ch, flow_base, flow_cnt, default_flow, tx)\
+ { \
+ .thread_id = x, \
+ .ep_config = { \
+ .ep_type = PSIL_EP_NATIVE, \
+ .pkt_mode = 1, \
+ .needs_epib = 1,\
+ .psd_size = 64, \
+ .mapped_channel_id = ch,\
+ .flow_start = flow_base,\
+ .flow_num = flow_cnt, \
+ .default_flow_id = default_flow,\
+ .notdpkt = tx, \
+ }, \
+ }
+
+/* PSI-L source thread IDs, used for RX (DMA_DEV_TO_MEM) */
+static struct psil_ep am64_src_ep_map[] = {
+ /* SA2UL */
+ PSIL_SAUL(0x4000, 17, 32, 8, 32, 0),
+ PSIL_SAUL(0x4001, 18, 32, 8, 33, 0),
+ PSIL_SAUL(0x4002, 19, 40, 8, 40, 0),
+ PSIL_SAUL(0x4003, 20, 40, 8, 41, 0),
+ /* CPSW3G */
+ PSIL_ETHERNET(0x4500, 16, 16, 16),
+};
+
+/* PSI-L destination thread IDs, used for TX (DMA_MEM_TO_DEV) */
+static struct psil_ep am64_dst_ep_map[] = {
+ /* SA2UL */
+ PSIL_SAUL(0xc000, 24, 80, 8, 80, 1),
+ PSIL_SAUL(0xc001, 25, 88, 8, 88, 1),
+ /* CPSW3G */
+ PSIL_ETHERNET(0xc500, 16, 16, 8),
+ PSIL_ETHERNET(0xc501, 17, 24, 8),
+ PSIL_ETHERNET(0xc502, 18, 32, 8),
+ PSIL_ETHERNET(0xc503, 19, 40, 8),
+ PSIL_ETHERNET(0xc504, 20, 48, 8),
+ PSIL_ETHERNET(0xc505, 21, 56, 8),
+ PSIL_ETHERNET(0xc506, 22, 64, 8),
+ PSIL_ETHERNET(0xc507, 23, 72, 8),
+};
+
+struct psil_ep_map am64_ep_map = {
+ .name = "am64",
+ .src = am64_src_ep_map,
+ .src_count = ARRAY_SIZE(am64_src_ep_map),
+ .dst = am64_dst_ep_map,
+ .dst_count = ARRAY_SIZE(am64_dst_ep_map),
+};
diff --git a/drivers/dma/ti/k3-psil-priv.h b/drivers/dma/ti/k3-psil-priv.h
index b4b0fb359eff..b74e192e3c2d 100644
--- a/drivers/dma/ti/k3-psil-priv.h
+++ b/drivers/dma/ti/k3-psil-priv.h
@@ -40,5 +40,6 @@ struct psil_endpoint_config *psil_get_ep_config(u32
thread_id);
extern struct psil_ep_map am654_ep_map;
extern struct psil_ep_map j721e_ep_map;
extern struct psil_ep_map j7200_ep_map;
+extern struct psil_ep_map am64_ep_map;
#endif /* K3_PSIL_PRIV_H_ */
diff --git a/drivers/dma/ti/k3-psil.c b/drivers/dma/ti/k3-psil.c
index 837853aab95a..9da3027a6fbb 100644
--- a/drivers/dma/ti/k3-psil.c
+++ b/drivers/dma/ti/k3-psil.c
@@ -20,6 +20,7 @@ static const struct soc_device_attribute k3_soc
[PATCH 16/18] dmaengine: ti: k3-udma: Add support for BCDMA channel TPL handling
Unlike UDMAP the BCDMA defines the channel TPL levels per channel type.
In UDMAP the number of high and ultra-high channels applies to both tchan
and rchan.
BCDMA defines the TPL per channel types: bchan, tchan and rchan can have
different number of high and ultra-high channels.
In order to support BCDMA channel TPL we need to move the tpl information
as per channel type property for the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 122 ++-
drivers/dma/ti/k3-udma.h | 6 ++
2 files changed, 89 insertions(+), 39 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index a342e89a4bae..69f2c43354d4 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -146,6 +146,11 @@ struct udma_rx_flush {
dma_addr_t buffer_paddr;
};
+struct udma_tpl {
+ u8 levels;
+ u32 start_idx[3];
+};
+
struct udma_dev {
struct dma_device ddev;
struct device *dev;
@@ -153,8 +158,9 @@ struct udma_dev {
const struct udma_match_data *match_data;
const struct udma_soc_data *soc_data;
- u8 tpl_levels;
- u32 tpl_start_idx[3];
+ struct udma_tpl bchan_tpl;
+ struct udma_tpl tchan_tpl;
+ struct udma_tpl rchan_tpl;
size_t desc_align; /* alignment to use for descriptors */
@@ -1278,10 +1284,10 @@ static struct udma_##res *__udma_reserve_##res(struct
udma_dev *ud, \
} else {\
int start; \
\
- if (tpl >= ud->tpl_levels) \
- tpl = ud->tpl_levels - 1; \
+ if (tpl >= ud->res##_tpl.levels)\
+ tpl = ud->res##_tpl.levels - 1; \
\
- start = ud->tpl_start_idx[tpl]; \
+ start = ud->res##_tpl.start_idx[tpl]; \
\
id = find_next_zero_bit(ud->res##_map, ud->res##_cnt, \
start); \
@@ -1294,29 +1300,14 @@ static struct udma_##res *__udma_reserve_##res(struct
udma_dev *ud, \
return &ud->res##s[id]; \
}
+UDMA_RESERVE_RESOURCE(bchan);
UDMA_RESERVE_RESOURCE(tchan);
UDMA_RESERVE_RESOURCE(rchan);
-static struct udma_bchan *__bcdma_reserve_bchan(struct udma_dev *ud, int id)
-{
- if (id >= 0) {
- if (test_bit(id, ud->bchan_map)) {
- dev_err(ud->dev, "bchan%d is in use\n", id);
- return ERR_PTR(-ENOENT);
- }
- } else {
- id = find_next_zero_bit(ud->bchan_map, ud->bchan_cnt, 0);
- if (id == ud->bchan_cnt)
- return ERR_PTR(-ENOENT);
- }
-
- set_bit(id, ud->bchan_map);
- return &ud->bchans[id];
-}
-
static int bcdma_get_bchan(struct udma_chan *uc)
{
struct udma_dev *ud = uc->ud;
+ enum udma_tp_level tpl;
if (uc->bchan) {
dev_dbg(ud->dev, "chan%d: already have bchan%d allocated\n",
@@ -1324,7 +1315,16 @@ static int bcdma_get_bchan(struct udma_chan *uc)
return 0;
}
- uc->bchan = __bcdma_reserve_bchan(ud, -1);
+ /*
+* Use normal channels for peripherals, and highest TPL channel for
+* mem2mem
+*/
+ if (uc->config.tr_trigger_type)
+ tpl = 0;
+ else
+ tpl = ud->bchan_tpl.levels - 1;
+
+ uc->bchan = __udma_reserve_bchan(ud, tpl, -1);
if (IS_ERR(uc->bchan))
return PTR_ERR(uc->bchan);
@@ -1386,8 +1386,11 @@ static int udma_get_chan_pair(struct udma_chan *uc)
/* Can be optimized, but let's have it like this for now */
end = min(ud->tchan_cnt, ud->rchan_cnt);
- /* Try to use the highest TPL channel pair for MEM_TO_MEM channels */
- chan_id = ud->tpl_start_idx[ud->tpl_levels - 1];
+ /*
+* Try to use the highest TPL channel pair for MEM_TO_MEM channels
+* Note: in UDMAP the channel TPL is symmetric between tchan and rchan
+*/
+ chan_id = ud->tchan_tpl.start_idx[ud->tchan_tpl.levels - 1];
for (; chan_id < end; chan_id++) {
if (!test_bit(chan_id, ud->tchan_map) &&
!test_bit(chan_id, ud->rchan_map))
@@ -4043,24 +4046,28 @@ static int udma_setup_resources(struct udma_dev *ud)
cap3 = udma_read(ud->mmrs[MMR_GCFG], 0x2c);
if (of_device_is_compatible(dev->of_node,
"ti,am654-navss-main-udmap")) {
-
[PATCH 07/18] dmaengine: ti: k3-udma-glue: Add function to get device pointer for DMA API
Glue layer users should use the device of the DMA for DMA mapping and
allocations as it is the DMA which accesses to descriptors and buffers,
not the clients
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 14 ++
drivers/dma/ti/k3-udma-private.c | 6 ++
drivers/dma/ti/k3-udma.h | 1 +
include/linux/dma/k3-udma-glue.h | 4
4 files changed, 25 insertions(+)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index a367584f0d7b..a53bc4707ae8 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -487,6 +487,13 @@ int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel
*tx_chn)
}
EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_irq);
+struct device *
+ k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn)
+{
+ return xudma_get_device(tx_chn->common.udmax);
+}
+EXPORT_SYMBOL_GPL(k3_udma_glue_tx_get_dma_device);
+
static int k3_udma_glue_cfg_rx_chn(struct k3_udma_glue_rx_channel *rx_chn)
{
const struct udma_tisci_rm *tisci_rm = rx_chn->common.tisci_rm;
@@ -1189,3 +1196,10 @@ int k3_udma_glue_rx_get_irq(struct
k3_udma_glue_rx_channel *rx_chn,
return flow->virq;
}
EXPORT_SYMBOL_GPL(k3_udma_glue_rx_get_irq);
+
+struct device *
+ k3_udma_glue_rx_get_dma_device(struct k3_udma_glue_rx_channel *rx_chn)
+{
+ return xudma_get_device(rx_chn->common.udmax);
+}
+EXPORT_SYMBOL_GPL(k3_udma_glue_rx_get_dma_device);
diff --git a/drivers/dma/ti/k3-udma-private.c b/drivers/dma/ti/k3-udma-private.c
index aa24e554f7b4..8ff7a264be03 100644
--- a/drivers/dma/ti/k3-udma-private.c
+++ b/drivers/dma/ti/k3-udma-private.c
@@ -50,6 +50,12 @@ struct udma_dev *of_xudma_dev_get(struct device_node *np,
const char *property)
}
EXPORT_SYMBOL(of_xudma_dev_get);
+struct device *xudma_get_device(struct udma_dev *ud)
+{
+ return ud->dev;
+}
+EXPORT_SYMBOL(xudma_get_device);
+
u32 xudma_dev_get_psil_base(struct udma_dev *ud)
{
return ud->psil_base;
diff --git a/drivers/dma/ti/k3-udma.h b/drivers/dma/ti/k3-udma.h
index 09c4529e013d..d1cace0cb43b 100644
--- a/drivers/dma/ti/k3-udma.h
+++ b/drivers/dma/ti/k3-udma.h
@@ -112,6 +112,7 @@ int xudma_navss_psil_unpair(struct udma_dev *ud, u32
src_thread,
u32 dst_thread);
struct udma_dev *of_xudma_dev_get(struct device_node *np, const char
*property);
+struct device *xudma_get_device(struct udma_dev *ud);
void xudma_dev_put(struct udma_dev *ud);
u32 xudma_dev_get_psil_base(struct udma_dev *ud);
struct udma_tisci_rm *xudma_dev_get_tisci_rm(struct udma_dev *ud);
diff --git a/include/linux/dma/k3-udma-glue.h b/include/linux/dma/k3-udma-glue.h
index 5eb34ad973a7..d7c12f31377c 100644
--- a/include/linux/dma/k3-udma-glue.h
+++ b/include/linux/dma/k3-udma-glue.h
@@ -41,6 +41,8 @@ void k3_udma_glue_reset_tx_chn(struct k3_udma_glue_tx_channel
*tx_chn,
u32 k3_udma_glue_tx_get_hdesc_size(struct k3_udma_glue_tx_channel *tx_chn);
u32 k3_udma_glue_tx_get_txcq_id(struct k3_udma_glue_tx_channel *tx_chn);
int k3_udma_glue_tx_get_irq(struct k3_udma_glue_tx_channel *tx_chn);
+struct device *
+ k3_udma_glue_tx_get_dma_device(struct k3_udma_glue_tx_channel *tx_chn);
enum {
K3_UDMA_GLUE_SRC_TAG_LO_KEEP = 0,
@@ -130,5 +132,7 @@ int k3_udma_glue_rx_flow_enable(struct
k3_udma_glue_rx_channel *rx_chn,
u32 flow_idx);
int k3_udma_glue_rx_flow_disable(struct k3_udma_glue_rx_channel *rx_chn,
u32 flow_idx);
+struct device *
+ k3_udma_glue_rx_get_dma_device(struct k3_udma_glue_rx_channel *rx_chn);
#endif /* K3_UDMA_GLUE_H_ */
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
[PATCH 15/18] dmaengine: ti: k3-udma: Initial support for K3 BCDMA
One of the DMAs introduced with AM64 is the Block Copy DMA (BCDMA).
It serves similar purpose as K3 UDMAP channels in TR mode.
The rings for the BCDMA is integrated within the DMA itself instead of
using rings from the general purpose ringacc.
A BCDMA have two different type of channels:
- Block Copy Channels (bchan)
- Split Channels (tchan and rchan)
tchan and rchan can be used to service PSI-L peripherals, similarly to
K3 UDMA channels.
bchan can be only used for block copy operation (TR type15) like the
paired K3 UDMA tchan/rchan configured in block copy mode.
bchans can be also used to service peripherals directly if an external
trigger is selected for the channel.
Most of the driver code can be reused for BCDMA bchan/tchan/rchan support
but new setup and allocation functions are needed to handle the
differences between the DMAs.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 1386 ++
drivers/dma/ti/k3-udma.h | 12 +-
2 files changed, 1247 insertions(+), 151 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 1ae5d09e2059..a342e89a4bae 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include "../virt-dma.h"
@@ -55,14 +56,25 @@ struct udma_static_tr {
struct udma_chan;
+enum k3_dma_type {
+ DMA_TYPE_UDMA = 0,
+ DMA_TYPE_BCDMA,
+};
+
enum udma_mmr {
MMR_GCFG = 0,
+ MMR_BCHANRT,
MMR_RCHANRT,
MMR_TCHANRT,
MMR_LAST,
};
-static const char * const mmr_names[] = { "gcfg", "rchanrt", "tchanrt" };
+static const char * const mmr_names[] = {
+ [MMR_GCFG] = "gcfg",
+ [MMR_BCHANRT] = "bchanrt",
+ [MMR_RCHANRT] = "rchanrt",
+ [MMR_TCHANRT] = "tchanrt",
+};
struct udma_tchan {
void __iomem *reg_rt;
@@ -72,6 +84,8 @@ struct udma_tchan {
struct k3_ring *tc_ring; /* Transmit Completion ring */
};
+#define udma_bchan udma_tchan
+
struct udma_rflow {
int id;
struct k3_ring *fd_ring; /* Free Descriptor ring */
@@ -84,11 +98,25 @@ struct udma_rchan {
int id;
};
+struct udma_oes_offsets {
+ /* K3 UDMA Output Event Offset */
+ u32 udma_rchan;
+
+ /* BCDMA Output Event Offsets */
+ u32 bcdma_bchan_data;
+ u32 bcdma_bchan_ring;
+ u32 bcdma_tchan_data;
+ u32 bcdma_tchan_ring;
+ u32 bcdma_rchan_data;
+ u32 bcdma_rchan_ring;
+};
+
#define UDMA_FLAG_PDMA_ACC32 BIT(0)
#define UDMA_FLAG_PDMA_BURST BIT(1)
#define UDMA_FLAG_TDTYPE BIT(2)
struct udma_match_data {
+ enum k3_dma_type type;
u32 psil_base;
bool enable_memcpy_support;
u32 flags;
@@ -96,7 +124,8 @@ struct udma_match_data {
};
struct udma_soc_data {
- u32 rchan_oes_offset;
+ struct udma_oes_offsets oes;
+ u32 bcdma_trigger_event_offset;
};
struct udma_hwdesc {
@@ -139,16 +168,19 @@ struct udma_dev {
struct udma_rx_flush rx_flush;
+ int bchan_cnt;
int tchan_cnt;
int echan_cnt;
int rchan_cnt;
int rflow_cnt;
+ unsigned long *bchan_map;
unsigned long *tchan_map;
unsigned long *rchan_map;
unsigned long *rflow_gp_map;
unsigned long *rflow_gp_map_allocated;
unsigned long *rflow_in_use;
+ struct udma_bchan *bchans;
struct udma_tchan *tchans;
struct udma_rchan *rchans;
struct udma_rflow *rflows;
@@ -156,6 +188,7 @@ struct udma_dev {
struct udma_chan *channels;
u32 psil_base;
u32 atype;
+ u32 asel;
};
struct udma_desc {
@@ -200,6 +233,7 @@ struct udma_chan_config {
bool notdpkt; /* Suppress sending TDC packet */
int remote_thread_id;
u32 atype;
+ u32 asel;
u32 src_thread;
u32 dst_thread;
enum psil_endpoint_type ep_type;
@@ -207,6 +241,8 @@ struct udma_chan_config {
bool enable_burst;
enum udma_tp_level channel_tpl; /* Channel Throughput Level */
+ u32 tr_trigger_type;
+
enum dma_transfer_direction dir;
};
@@ -214,11 +250,13 @@ struct udma_chan {
struct virt_dma_chan vc;
struct dma_slave_config cfg;
struct udma_dev *ud;
+ struct device *dma_dev;
struct udma_desc *desc;
struct udma_desc *terminated_desc;
struct udma_static_tr static_tr;
char *name;
+ struct udma_bchan *bchan;
struct udma_tchan *tchan;
struct udma_rchan *rchan;
struct udma_rflow *rflow;
@@ -354,6 +392,30 @@ static int navss_psil_unpair(struct udma_dev *ud, u32
src_thread,
src_thread, dst_thread);
}
+static void k3_configure_chan_coherency(struct dma_chan *chan, u32 asel)
+{
+ struct device *chan_dev = &chan->dev->device;
+
+ if (asel == 0) {
+ /
[PATCH 06/18] dmaengine: ti: k3-udma: Add support for second resource range from sysfw
Resource allocation via sysfw can use up to two ranges per resource subtype
to support more complex resource assignment, mainly for DMA channels.
Take the second range also into consideration when setting up the maps for
available resources.
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma.c | 55 ++--
1 file changed, 31 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/ti/k3-udma.c b/drivers/dma/ti/k3-udma.c
index 3f798993a8b1..1ae5d09e2059 100644
--- a/drivers/dma/ti/k3-udma.c
+++ b/drivers/dma/ti/k3-udma.c
@@ -3179,12 +3179,22 @@ static int udma_get_mmrs(struct platform_device *pdev,
struct udma_dev *ud)
return 0;
}
+static void udma_mark_resource_ranges(struct udma_dev *ud, unsigned long *map,
+ struct ti_sci_resource_desc *rm_desc,
+ char *name)
+{
+ bitmap_clear(map, rm_desc->start, rm_desc->num);
+ bitmap_clear(map, rm_desc->start_sec, rm_desc->num_sec);
+ dev_dbg(ud->dev, "ti_sci resource range for %s: %d:%d | %d:%d\n", name,
+ rm_desc->start, rm_desc->num, rm_desc->start_sec,
+ rm_desc->num_sec);
+}
+
static int udma_setup_resources(struct udma_dev *ud)
{
struct device *dev = ud->dev;
int ch_count, ret, i, j;
u32 cap2, cap3;
- struct ti_sci_resource_desc *rm_desc;
struct ti_sci_resource *rm_res, irq_res;
struct udma_tisci_rm *tisci_rm = &ud->tisci_rm;
static const char * const range_names[] = { "ti,sci-rm-range-tchan",
@@ -3270,13 +3280,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_zero(ud->tchan_map, ud->tchan_cnt);
} else {
bitmap_fill(ud->tchan_map, ud->tchan_cnt);
- for (i = 0; i < rm_res->sets; i++) {
- rm_desc = &rm_res->desc[i];
- bitmap_clear(ud->tchan_map, rm_desc->start,
-rm_desc->num);
- dev_dbg(dev, "ti-sci-res: tchan: %d:%d\n",
- rm_desc->start, rm_desc->num);
- }
+ for (i = 0; i < rm_res->sets; i++)
+ udma_mark_resource_ranges(ud, ud->tchan_map,
+ &rm_res->desc[i], "tchan");
}
irq_res.sets = rm_res->sets;
@@ -3286,13 +3292,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_zero(ud->rchan_map, ud->rchan_cnt);
} else {
bitmap_fill(ud->rchan_map, ud->rchan_cnt);
- for (i = 0; i < rm_res->sets; i++) {
- rm_desc = &rm_res->desc[i];
- bitmap_clear(ud->rchan_map, rm_desc->start,
-rm_desc->num);
- dev_dbg(dev, "ti-sci-res: rchan: %d:%d\n",
- rm_desc->start, rm_desc->num);
- }
+ for (i = 0; i < rm_res->sets; i++)
+ udma_mark_resource_ranges(ud, ud->rchan_map,
+ &rm_res->desc[i], "rchan");
}
irq_res.sets += rm_res->sets;
@@ -3301,12 +3303,21 @@ static int udma_setup_resources(struct udma_dev *ud)
for (i = 0; i < rm_res->sets; i++) {
irq_res.desc[i].start = rm_res->desc[i].start;
irq_res.desc[i].num = rm_res->desc[i].num;
+ irq_res.desc[i].start_sec = rm_res->desc[i].start_sec;
+ irq_res.desc[i].num_sec = rm_res->desc[i].num_sec;
}
rm_res = tisci_rm->rm_ranges[RM_RANGE_RCHAN];
for (j = 0; j < rm_res->sets; j++, i++) {
- irq_res.desc[i].start = rm_res->desc[j].start +
+ if (rm_res->desc[j].num) {
+ irq_res.desc[i].start = rm_res->desc[j].start +
ud->soc_data->rchan_oes_offset;
- irq_res.desc[i].num = rm_res->desc[j].num;
+ irq_res.desc[i].num = rm_res->desc[j].num;
+ }
+ if (rm_res->desc[j].num_sec) {
+ irq_res.desc[i].start_sec = rm_res->desc[j].start_sec +
+ ud->soc_data->rchan_oes_offset;
+ irq_res.desc[i].num_sec = rm_res->desc[j].num_sec;
+ }
}
ret = ti_sci_inta_msi_domain_alloc_irqs(ud->dev, &irq_res);
kfree(irq_res.desc);
@@ -3322,13 +,9 @@ static int udma_setup_resources(struct udma_dev *ud)
bitmap_clear(ud->rflow_gp_map, ud->rchan_cnt,
ud->rflow_cnt - ud->rchan_cnt);
} else {
- for (i = 0; i < rm_res->sets; i++) {
- rm_desc = &rm_res->desc[i];
- bitmap_clear(ud->rflow_gp_map, rm_desc->start,
-rm_desc->num);
-
[PATCH 18/18] dmaengine: ti: k3-udma-glue: Add support for K3 PKTDMA
From: Vignesh Raghavendra
This commit adds support for PKTDMA in k3-udma glue driver. Use new
psil_endpoint_config struct to get static data for a given channel or a
flow during setup. Make sure that the RX flows being mapped to a RX
channel is within the range of flows that is been allocated to that RX
channel.
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti/k3-udma-glue.c| 272 ++-
drivers/dma/ti/k3-udma-private.c | 24 +++
drivers/dma/ti/k3-udma.h | 4 +
include/linux/dma/k3-udma-glue.h | 8 +
4 files changed, 270 insertions(+), 38 deletions(-)
diff --git a/drivers/dma/ti/k3-udma-glue.c b/drivers/dma/ti/k3-udma-glue.c
index f39825ce288a..6730bc296043 100644
--- a/drivers/dma/ti/k3-udma-glue.c
+++ b/drivers/dma/ti/k3-udma-glue.c
@@ -22,6 +22,7 @@
struct k3_udma_glue_common {
struct device *dev;
+ struct device chan_dev;
struct udma_dev *udmax;
const struct udma_tisci_rm *tisci_rm;
struct k3_ringacc *ringacc;
@@ -32,7 +33,8 @@ struct k3_udma_glue_common {
bool epib;
u32 psdata_size;
u32 swdata_size;
- u32 atype;
+ u32 atype_asel;
+ struct psil_endpoint_config *ep_config;
};
struct k3_udma_glue_tx_channel {
@@ -53,6 +55,8 @@ struct k3_udma_glue_tx_channel {
bool tx_filt_einfo;
bool tx_filt_pswords;
bool tx_supr_tdpkt;
+
+ int udma_tflow_id;
};
struct k3_udma_glue_rx_flow {
@@ -104,7 +108,6 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
const char *name, struct k3_udma_glue_common *common,
bool tx_chn)
{
- struct psil_endpoint_config *ep_config;
struct of_phandle_args dma_spec;
u32 thread_id;
int ret = 0;
@@ -121,15 +124,26 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
&dma_spec))
return -ENOENT;
+ ret = of_k3_udma_glue_parse(dma_spec.np, common);
+ if (ret)
+ goto out_put_spec;
+
thread_id = dma_spec.args[0];
if (dma_spec.args_count == 2) {
- if (dma_spec.args[1] > 2) {
+ if (dma_spec.args[1] > 2 && !xudma_is_pktdma(common->udmax)) {
dev_err(common->dev, "Invalid channel atype: %u\n",
dma_spec.args[1]);
ret = -EINVAL;
goto out_put_spec;
}
- common->atype = dma_spec.args[1];
+ if (dma_spec.args[1] > 15 && xudma_is_pktdma(common->udmax)) {
+ dev_err(common->dev, "Invalid channel asel: %u\n",
+ dma_spec.args[1]);
+ ret = -EINVAL;
+ goto out_put_spec;
+ }
+
+ common->atype_asel = dma_spec.args[1];
}
if (tx_chn && !(thread_id & K3_PSIL_DST_THREAD_ID_OFFSET)) {
@@ -143,25 +157,23 @@ static int of_k3_udma_glue_parse_chn(struct device_node
*chn_np,
}
/* get psil endpoint config */
- ep_config = psil_get_ep_config(thread_id);
- if (IS_ERR(ep_config)) {
+ common->ep_config = psil_get_ep_config(thread_id);
+ if (IS_ERR(common->ep_config)) {
dev_err(common->dev,
"No configuration for psi-l thread 0x%04x\n",
thread_id);
- ret = PTR_ERR(ep_config);
+ ret = PTR_ERR(common->ep_config);
goto out_put_spec;
}
- common->epib = ep_config->needs_epib;
- common->psdata_size = ep_config->psd_size;
+ common->epib = common->ep_config->needs_epib;
+ common->psdata_size = common->ep_config->psd_size;
if (tx_chn)
common->dst_thread = thread_id;
else
common->src_thread = thread_id;
- ret = of_k3_udma_glue_parse(dma_spec.np, common);
-
out_put_spec:
of_node_put(dma_spec.np);
return ret;
@@ -227,7 +239,7 @@ static int k3_udma_glue_cfg_tx_chn(struct
k3_udma_glue_tx_channel *tx_chn)
req.tx_supr_tdpkt = 1;
req.tx_fetch_size = tx_chn->common.hdesc_size >> 2;
req.txcq_qnum = k3_ringacc_get_ring_id(tx_chn->ringtxcq);
- req.tx_atype = tx_chn->common.atype;
+ req.tx_atype = tx_chn->common.atype_asel;
return tisci_rm->tisci_udmap_ops->tx_ch_cfg(tisci_rm->tisci, &req);
}
@@ -259,8 +271,14 @@ struct k3_udma_glue_tx_channel
*k3_udma_glue_request_tx_chn(struct device *dev,
tx_chn->common.psdata_size,
tx_chn->common.swdata_size);
+ if (xudma_is_pktdma(tx_chn->common.udmax))
+ tx_chn->udma_tchan_id =
tx_chn->common.ep_config->mapped_channel_id;
+ else
+ tx_chn->udma_tchan_id = -1;
Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2
* Trent Piepho [200930 08:35]:
> The closest thing would be the generic pin config type bindings, which
> go in the pinctrl driver's nodes, and look like this:
> &am335x_pinmux {
> pinctrl_yoyo_reset: yoyogrp {
> pins = "foo";
> function = "gpio";
> bias-pull-up;
> };
> };
There's a bit of a dtb size and boot time issue for adding properties
for each pin where that needs to be done for several hundred pins :)
> Is "some additional property for specifying generic conf flags"
> different from the existing pinctrl-single,bias-pullup, etc.
> properties? Because splitting the data cell into two parts doesn't
> make any difference to those.
So with an interrupt style binding with generic pinconf flags we can
leave out the parsing of multiple properties for each pin. Sure the
pin is only referenced by the controller like you pointed out but the
pinconf flags could be generic.
Regards,
Tony
Re: lockdep null-ptr-deref
On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote:
> I think there are two problems here:
>
> 1) the "(null)" means we don't have the "usage_str" for a usage bit,
> which I think is the LOCK_USED_READ bit introduced by Peter at
> 23870f122768 ('locking/lockdep: Fix "USED" <- "IN-NMI" inversions').
>
> 2) the next null-ptr-deref, and I think this is also caused by
> LOCK_USED_READ bit, because in the loop inside
> print_lock_class_header(), we iterate from 0 to LOCK_USAGE_STATES (which
> is 4*2 + 3), however the class->usage_traces[] only has
> XXX_LOCK_USAGE_STATES (which is 4*2 + 1) elements, so if we have
> LOCK_USED_READ bit set in ->usage_mask, we will try to access an element
> out of the ->usage_traces[] array.
>
> Probably the following helps? And another possible fix is to enlarge the
> ->usage_trace[] array and record the call trace of LOCK_READ_USED.
Urgh.. yeah, I wanted to avoid saving that trace; it's pretty useless :/
The existing USED trace is already mostly pointless, the consistent
thing would be to remove both but that might be too radical.
But you're right in that I made a right mess of it. Not sure what's
best here.
Let me have a play.
[PATCH] xen/events: don't use chip_data for legacy IRQs
Since commit c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to
store a per interrupt XEN data pointer which contains XEN specific
information.")
Xen is using the chip_data pointer for storing IRQ specific data. When
running as a HVM domain this can result in problems for legacy IRQs, as
those might use chip_data for their own purposes.
Use a local array for this purpose in case of legacy IRQs, avoiding the
double use.
Cc: sta...@vger.kernel.org
Fixes: c330fb1ddc0a ("XEN uses irqdesc::irq_data_common::handler_data to store
a per interrupt XEN data pointer which contains XEN specific information.")
Signed-off-by: Juergen Gross
---
drivers/xen/events/events_base.c | 29 +
1 file changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/xen/events/events_base.c b/drivers/xen/events/events_base.c
index 90b8f56fbadb..6f02c18fa65c 100644
--- a/drivers/xen/events/events_base.c
+++ b/drivers/xen/events/events_base.c
@@ -92,6 +92,8 @@ static bool (*pirq_needs_eoi)(unsigned irq);
/* Xen will never allocate port zero for any purpose. */
#define VALID_EVTCHN(chn) ((chn) != 0)
+static struct irq_info *legacy_info_ptrs[NR_IRQS_LEGACY];
+
static struct irq_chip xen_dynamic_chip;
static struct irq_chip xen_percpu_chip;
static struct irq_chip xen_pirq_chip;
@@ -156,7 +158,18 @@ int get_evtchn_to_irq(evtchn_port_t evtchn)
/* Get info for IRQ */
struct irq_info *info_for_irq(unsigned irq)
{
- return irq_get_chip_data(irq);
+ if (irq < nr_legacy_irqs())
+ return legacy_info_ptrs[irq];
+ else
+ return irq_get_chip_data(irq);
+}
+
+static void set_info_for_irq(unsigned int irq, struct irq_info *info)
+{
+ if (irq < nr_legacy_irqs())
+ legacy_info_ptrs[irq] = info;
+ else
+ irq_set_chip_data(irq, info);
}
/* Constructors for packed IRQ information. */
@@ -377,7 +390,7 @@ static void xen_irq_init(unsigned irq)
info->type = IRQT_UNBOUND;
info->refcnt = -1;
- irq_set_chip_data(irq, info);
+ set_info_for_irq(irq, info);
list_add_tail(&info->list, &xen_irq_list_head);
}
@@ -426,14 +439,14 @@ static int __must_check xen_allocate_irq_gsi(unsigned gsi)
static void xen_free_irq(unsigned irq)
{
- struct irq_info *info = irq_get_chip_data(irq);
+ struct irq_info *info = info_for_irq(irq);
if (WARN_ON(!info))
return;
list_del(&info->list);
- irq_set_chip_data(irq, NULL);
+ set_info_for_irq(irq, NULL);
WARN_ON(info->refcnt > 0);
@@ -603,7 +616,7 @@ EXPORT_SYMBOL_GPL(xen_irq_from_gsi);
static void __unbind_from_irq(unsigned int irq)
{
evtchn_port_t evtchn = evtchn_from_irq(irq);
- struct irq_info *info = irq_get_chip_data(irq);
+ struct irq_info *info = info_for_irq(irq);
if (info->refcnt > 0) {
info->refcnt--;
@@ -1108,7 +1121,7 @@ int bind_ipi_to_irqhandler(enum ipi_vector ipi,
void unbind_from_irqhandler(unsigned int irq, void *dev_id)
{
- struct irq_info *info = irq_get_chip_data(irq);
+ struct irq_info *info = info_for_irq(irq);
if (WARN_ON(!info))
return;
@@ -1142,7 +1155,7 @@ int evtchn_make_refcounted(evtchn_port_t evtchn)
if (irq == -1)
return -ENOENT;
- info = irq_get_chip_data(irq);
+ info = info_for_irq(irq);
if (!info)
return -ENOENT;
@@ -1170,7 +1183,7 @@ int evtchn_get(evtchn_port_t evtchn)
if (irq == -1)
goto done;
- info = irq_get_chip_data(irq);
+ info = info_for_irq(irq);
if (!info)
goto done;
--
2.26.2
Re: [PATCH 1/1] sched/fair: Fix the wrong sched_stat_wait time
Peter Zijlstra 于2020年9月30日周三 下午4:20写道：
>
> On Wed, Sep 30, 2020 at 10:47:12AM +0800, qianjun.ker...@gmail.com wrote:
> > From: jun qian
> >
> > When the sched_schedstat changes from 0 to 1, some sched se maybe
> > already in the runqueue, the se->statistics.wait_start will be 0.
> > So it will let the (rq_of(cfs_rq)) - se->statistics.wait_start)
> > wrong. We need to avoid this scenario.
>
> Is this really the only problem there? Did you do a full audit of that
> schedstat nonsense?
>
Did you mean that the sched_stat_xxx's xxx_start(sched_stat_sleep
sched_stat_iowait sched_stat_blocked
sched_stat_runtime) may be also depend the schedstat_enabled?
I have searched the codes, and found that these sched_stat_xxx's
xxx_start don't depend the schedstat_enabled
except the wait_start.
This patch is going to slove the problem that when the
schedstat_enabled is enabled, the sched_stat_wait of
the probed process will become unbelievable big probability in the fist time.
> > Signed-off-by: jun qian
> > Signed-off-by: Yafang Shao
> > ---
> > kernel/sched/fair.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 658aa7a..dd7c3bb 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -908,6 +908,14 @@ static void update_curr_fair(struct rq *rq)
>
> your git-diff is 'funny', it got the function ^ wrong.
>
sorry :)
> > if (!schedstat_enabled())
> > return;
> >
> > + /*
> > + * When the sched_schedstat changes from 0 to 1, some sched se maybe
> > + * already in the runqueue, the se->statistics.wait_start will be 0.
> > + * So it will let the delta wrong. We need to avoid this scenario.
> > + */
> > + if (unlikely(!schedstat_val(se->statistics.wait_start)))
> > + return;
> > +
> > delta = rq_clock(rq_of(cfs_rq)) -
> > schedstat_val(se->statistics.wait_start);
> >
> > if (entity_is_task(se)) {
> > --
> > 1.8.3.1
> >
Re: [PATCH v2] page_alloc: Fix freeing non-compound pages
On Tue, Sep 29, 2020 at 03:06:22PM +0100, Matthew Wilcox wrote: > On Tue, Sep 29, 2020 at 10:26:22AM +0300, Mike Rapoport wrote: > > This sentence presumes existing description/prior knowledge about > > put_page(). > > > > Maybe > > > > This function can free multi-page allocations that were not allocated > > with %__GFP_COMP, unlike put_page() that would free only the first page > > in such case. __free_pages() does not ... > > Thanks. After waking up this morning I did a more extensive rewrite: I like this one Acked-by: Mike Rapoport > /** > * __free_pages - Free pages allocated with alloc_pages(). > * @page: The page pointer returned from alloc_pages(). > * @order: The order of the allocation. > * > * This function can free multi-page allocations that are not compound > * pages. It does not check that the @order passed in matches that of > * the allocation, so it is easy to leak memory. Freeing more memory > * than was allocated will probably emit a warning. > * > * If the last reference to this page is speculative, it will be released > * by put_page() which only frees the first page of a non-compound > * allocation. To prevent the remaining pages from being leaked, we free > * the subsequent pages here. If you want to use the page's reference > * count to decide when to free the allocation, you should allocate a > * compound page, and use put_page() instead of __free_pages(). > * > * Context: May be called in interrupt context or holding a normal > * spinlock, but not in NMI context or while holding a raw spinlock. > */ > -- Sincerely yours, Mike.
Re: [PATCH 3/9] media: docs: ipu3.rst: rely at automarkup extension
On Wed, Sep 30, 2020 at 08:35:56AM +0200, Mauro Carvalho Chehab wrote: > There are several :c:type: definitions there, in order to > do cross-references with the driver's documentation. > > Those are broken when docs are built with Sphinx 3.x, as > it would require :c:struct: instead. > > For Sphinx < 3.x, the automarkup.py extension is able to do the > replacement already, and a future improvement on it should make > it also work with Sphinx 3.x. > > So, get rid of the usage of the :c:type: macro there. > > Signed-off-by: Mauro Carvalho Chehab Thanks! Acked-by: Sakari Ailus -- Sakari Ailus
Re: Removal of HCI commands, userspace bluetooth regression?
On Wed, Sep 30, 2020 at 10:16:40AM +0200, Marcel Holtmann wrote: > Hi Greg, > > I wrote a simple script "sco_features.pl" which show all supported > codecs by local HCI bluetooth adapter. Script is available at: > > https://github.com/pali/hsphfpd-prototype/blob/prototype/sco_features.pl > > And I found out that OCF_READ_LOCAL_CODECS HCI command cannot be > send by > non-root user. Kernel returns "Operation not permitted" error. > > What is reason that kernel blocks OCF_READ_LOCAL_CODECS command for > non-root users? Without it (audio) application does not know which > codecs local bluetooth adapter supports. > > E.g. OCF_READ_LOCAL_EXT_FEATURES or OCF_READ_VOICE_SETTING commands > can > be send also by non-root user and kernel does not block them. > >>> > >>> actually the direct access to HCI commands is being removed. So we > >>> have no plans to add new commands into the list since that it what > >>> the kernel is suppose to handle. If we wanted to expose this, then it > >>> has to be via mgmt. > >> > >> Hi Marcel! Thank you for information. I have not know that this API is > >> "deprecated" and is going to be removed. But userspace audio > >> applications need to know what bluetooth adapter supports, so can you > >> export result of these commands to userspace? My script linked above > >> calls: OCF_READ_VOICE_SETTING, OCF_READ_LOCAL_COMMANDS, > >> OCF_READ_LOCAL_EXT_FEATURES, OCF_READ_LOCAL_CODECS > > > > Hello! Just a gently reminder for this question. How to retrieve > > information about supported codecs from userspace by non-root user? > > Because running all bluetooth audio applications by root is not really a > > solution. Plus if above API for root user is going to be removed, what > > is a replacement? > > Hello! > > I have not got any answer to my email from Marcel for months, so I'm > adding other developers to loop. Could somebody tell me that is the > replacement API if above one is going to be removed? > > I was not able to find any documentation where could be described this > API nor information about deprecation / removal. > > And are you aware of the fact that removing of API could potentially > break existing applications? > > I really need to know which API should I use, because when I use API > which is going to be removed, then my application stops working. And I > really want to avoid it. > > Also I have not got any response yet, how can I read list of supported > codecs by bluetooth adapter by ordinary non-root user? Audio application > needs to know list of supported codecs and it is really insane to run it > as root. > >>> > >>> Hello! This is just another reminder that I have not got any reply to > >>> this email. > >>> > >>> Does silence mean that audio applications are expected to work only > >>> under root account and ordinary users are not able to use audio and list > >>> supported codecs? > >> > >> Hello! I have not got any reply for this issue for 10 months and if you > >> are going to remove (or after these 10 months you already did it?) > >> existing HCI API from kernel it would break existing and working > >> userspace application. How do you want to handle such regressions? > > > > What git commit caused this regression? > > there is no regression! > > New Bluetooth standards added new HCI commands that are just not > exposed to unprivileged users. Ok, that makes sense. What tool takes advantage of these new HCI commands? thanks, greg k-h
Re: Removal of HCI commands, userspace bluetooth regression?
On Wed, Sep 30, 2020 at 10:25:34AM +0200, Pali Rohár wrote: > On Wednesday 30 September 2020 10:02:05 Greg Kroah-Hartman wrote: > > On Tue, Sep 29, 2020 at 11:32:54PM +0200, Pali Rohár wrote: > > > CCing other lists and maintainers, hopefully, somebody would have a time > > > to look at it... > > > > > > On Saturday 08 August 2020 15:27:47 Pali Rohár wrote: > > > > On Wednesday 15 April 2020 00:56:18 Pali Rohár wrote: > > > > > On Sunday 09 February 2020 14:21:37 Pali Rohár wrote: > > > > > > On Saturday 04 January 2020 11:24:36 Pali Rohár wrote: > > > > > > > On Saturday 04 January 2020 10:44:52 Marcel Holtmann wrote: > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > I wrote a simple script "sco_features.pl" which show all > > > > > > > > > supported > > > > > > > > > codecs by local HCI bluetooth adapter. Script is available at: > > > > > > > > > > > > > > > > > > https://github.com/pali/hsphfpd-prototype/blob/prototype/sco_features.pl > > > > > > > > > > > > > > > > > > And I found out that OCF_READ_LOCAL_CODECS HCI command cannot > > > > > > > > > be send by > > > > > > > > > non-root user. Kernel returns "Operation not permitted" error. > > > > > > > > > > > > > > > > > > What is reason that kernel blocks OCF_READ_LOCAL_CODECS > > > > > > > > > command for > > > > > > > > > non-root users? Without it (audio) application does not know > > > > > > > > > which > > > > > > > > > codecs local bluetooth adapter supports. > > > > > > > > > > > > > > > > > > E.g. OCF_READ_LOCAL_EXT_FEATURES or OCF_READ_VOICE_SETTING > > > > > > > > > commands can > > > > > > > > > be send also by non-root user and kernel does not block them. > > > > > > > > > > > > > > > > actually the direct access to HCI commands is being removed. So > > > > > > > > we have no plans to add new commands into the list since that > > > > > > > > it what the kernel is suppose to handle. If we wanted to expose > > > > > > > > this, then it has to be via mgmt. > > > > > > > > > > > > > > Hi Marcel! Thank you for information. I have not know that this > > > > > > > API is > > > > > > > "deprecated" and is going to be removed. But userspace audio > > > > > > > applications need to know what bluetooth adapter supports, so can > > > > > > > you > > > > > > > export result of these commands to userspace? My script linked > > > > > > > above > > > > > > > calls: OCF_READ_VOICE_SETTING, OCF_READ_LOCAL_COMMANDS, > > > > > > > OCF_READ_LOCAL_EXT_FEATURES, OCF_READ_LOCAL_CODECS > > > > > > > > > > > > Hello! Just a gently reminder for this question. How to retrieve > > > > > > information about supported codecs from userspace by non-root user? > > > > > > Because running all bluetooth audio applications by root is not > > > > > > really a > > > > > > solution. Plus if above API for root user is going to be removed, > > > > > > what > > > > > > is a replacement? > > > > > > > > > > Hello! > > > > > > > > > > I have not got any answer to my email from Marcel for months, so I'm > > > > > adding other developers to loop. Could somebody tell me that is the > > > > > replacement API if above one is going to be removed? > > > > > > > > > > I was not able to find any documentation where could be described this > > > > > API nor information about deprecation / removal. > > > > > > > > > > And are you aware of the fact that removing of API could potentially > > > > > break existing applications? > > > > > > > > > > I really need to know which API should I use, because when I use API > > > > > which is going to be removed, then my application stops working. And I > > > > > really want to avoid it. > > > > > > > > > > Also I have not got any response yet, how can I read list of supported > > > > > codecs by bluetooth adapter by ordinary non-root user? Audio > > > > > application > > > > > needs to know list of supported codecs and it is really insane to run > > > > > it > > > > > as root. > > > > > > > > Hello! This is just another reminder that I have not got any reply to > > > > this email. > > > > > > > > Does silence mean that audio applications are expected to work only > > > > under root account and ordinary users are not able to use audio and list > > > > supported codecs? > > > > > > Hello! I have not got any reply for this issue for 10 months and if you > > > are going to remove (or after these 10 months you already did it?) > > > existing HCI API from kernel it would break existing and working > > > userspace application. How do you want to handle such regressions? > > > > What git commit caused this regression? > > Hello! Marcel in January wrote that access for HCI commands is being > removed from kernel. I do not know if he managed to do it in since > January, but I'm going to check it... So you don't see a regression/problem, but are saying there is one? odd...
Re: [PATCH] pwm: sysfs: Set class on pwm devices
Hi Uwe,
thank you for your review!
On Wed, Sep 30, 2020 at 08:57:26AM +0200, Uwe Kleine-König wrote:
> Hello Lars,
>
> On Tue, Sep 29, 2020 at 02:19:53PM +0200, poesc...@lemonage.de wrote:
> > From: Lars Poeschel
> >
> > This adds a class to exported pwm devices.
> > Exporting a pwm through sysfs did not yield udev events. The
>
> I wonder what is your use-case here. This for sure also has a place to
> be mentioned in the commit log. I suspect there is a better way to
> accomplish you way.
Use-case is to be able to use a pwm from a non-root userspace process.
I use udev rules to adjust permissions.
> > dev_uevent_filter function does filter-out devices without a bus or
> > class.
> > This was already addressed in commit
> > commit 7e5d1fd75c3d ("pwm: Set class for exported channels in sysfs")
> > but this did cause problems and the commit got reverted with
> > commit c289d6625237 ("Revert "pwm: Set class for exported channels in
> > sysfs"")
> >
> > pwm's have to be local to its pwmchip, so we create an individual class
> > for each pwmchip
>
> This sounds conceptually wrong.
I suspect you mean the second part is wrong and we agree on the first
part, that pwm's have to be local to its pwmchip.
There seems to be a need for this as 7e5d1fd75c3d tried this already.
Problem with this approach was, that the pwms where not local to their
pwmchip and if you then have the same pwm number exported from different
pwmchips this did collide.
Ok, now the uevent_ops filter function blocks the uevent I want to see
based on if device has a bus or a class set.
Can you recommend a better solution ?
Write a different filter function for this case ?
> > and assign this class to the pwm belonging to the
> > pwmchip. This does better map to structure that is also visible in
> > sysfs.
> >
> > Signed-off-by: Lars Poeschel
> > ---
> > drivers/pwm/sysfs.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pwm/sysfs.c b/drivers/pwm/sysfs.c
> > index 449dbc0f49ed..e2dfbc335366 100644
> > --- a/drivers/pwm/sysfs.c
> > +++ b/drivers/pwm/sysfs.c
> > @@ -259,7 +259,7 @@ static int pwm_export_child(struct device *parent,
> > struct pwm_device *pwm)
> > export->child.release = pwm_export_release;
> > export->child.parent = parent;
> > export->child.devt = MKDEV(0, 0);
> > - export->child.groups = pwm_groups;
> > + export->child.class = parent->class;
> > dev_set_name(&export->child, "pwm%u", pwm->hwpwm);
> >
> > ret = device_register(&export->child);
> > @@ -499,6 +499,9 @@ void pwmchip_sysfs_export(struct pwm_chip *chip)
> > dev_warn(chip->dev,
> > "device_create failed for pwm_chip sysfs export\n");
> > }
> > +
> > + parent->class = class_create(THIS_MODULE, parent->kobj.name);
>
> This needs error handling.
If this concept has a chance after discussion, I will change this.
Thanks again,
Lars
Re: [PATCH] tty: serial: mvebu-uart: Remove unused variable 'ret'
On Wed, Sep 30, 2020 at 04:14:59PM +0800, Pujin Shi wrote: > 'ret' variable is now defined but not used in mvebu_uart_probe(), > causing this warning: > > drivers/tty/serial/mvebu-uart.c: In function ‘mvebu_uart_probe’: > drivers/tty/serial/mvebu-uart.c:806:6: warning: unused variable ‘ret’ > [-Wunused-variable] > > Signed-off-by: Pujin Shi What commit caused this problem? And are you sure it's not already fixed by: https://lore.kernel.org/r/20200929085651.158283-1-miaoqingl...@huawei.com thanks, greg k-h
Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev
On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
>
> Previously the driver relies on bus_set_iommu() in .probe() to call
> in .probe_device() function so each client can poll iommus property
> in DTB to configure fwspec via tegra_smmu_configure(). According to
> the comments in .probe(), this is a bit of a hack. And this doesn't
> work for a client that doesn't exist in DTB, PCI device for example.
>
> Actually when a device/client gets probed, the of_iommu_configure()
> will call in .probe_device() function again, with a prepared fwspec
> from of_iommu_configure() that reads the SWGROUP id in DTB as we do
> in tegra-smmu driver.
>
> Additionally, as a new helper devm_tegra_get_memory_controller() is
> introduced, there's no need to poll the iommus property in order to
> get mc->smmu pointers or SWGROUP id.
>
> This patch reworks .probe_device() and .attach_dev() by doing:
> 1) Using fwspec to get swgroup id in .attach_dev/.dettach_dev()
> 2) Removing DT polling code, tegra_smmu_find/tegra_smmu_configure()
> 3) Calling devm_tegra_get_memory_controller() in .probe_device()
> 4) Also dropping the hack in .probe() that's no longer needed.
>
> Signed-off-by: Nicolin Chen
> ---
>
> Changelog
> v2->v3
> * Used devm_tegra_get_memory_controller() to get mc pointer
> * Replaced IS_ERR_OR_NULL with IS_ERR in .probe_device()
> v1->v2
> * Replaced in .probe_device() tegra_smmu_find/tegra_smmu_configure()
>with tegra_get_memory_controller call.
> * Dropped the hack in tegra_smmu_probe().
>
> drivers/iommu/tegra-smmu.c | 144 ++---
> 1 file changed, 36 insertions(+), 108 deletions(-)
>
> diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> index 6a3ecc334481..636dc3b89545 100644
> --- a/drivers/iommu/tegra-smmu.c
> +++ b/drivers/iommu/tegra-smmu.c
> @@ -61,6 +61,8 @@ struct tegra_smmu_as {
> u32 attr;
> };
>
> +static const struct iommu_ops tegra_smmu_ops;
I cannot find in this patch where this is assigned.
Best regards,
Krzysztof
Re: [PATCH v2 1/3] dt-bindings: pinctrl: Add bindings for pinctrl-mchp-sgpio driver
Hi Lars,
thanks for working on this!
On Sun, Sep 13, 2020 at 9:11 PM Lars Povlsen wrote:
> > What I do not understand is why this GPIO controller is placed in the
> > bindings of the pin controllers? Do you plan to add pin control
> > properties to the bindings in the future?
>
> I have made provisions for some of the generic pinconf parameters, and
> since the controller also has support for some alternate modes like
> (syncronized) blink at various rates, I thought I better add it as
> pinctrl straight away.
OK fair enough let's keep the bindings here.
BTW the latter function sounds like some kind of PWM?
> >> + gpio-controller: true
> >> +
> >> + '#gpio-cells':
> >> +description: GPIO consumers must specify four arguments, first the
> >> + port number, then the bit number, then a input/output flag and
> >> + finally the GPIO flags (from include/dt-bindings/gpio/gpio.h).
> >> + The dt-bindings/gpio/mchp-sgpio.h file define manifest constants
> >> + PIN_INPUT and PIN_OUTPUT.
> >> +const: 4
> >
> > I do not follow this new third input/output flag at all.
>
> Its actually a sort of bank address, since the individual "pins" are
> unidirectional.
I'm a bit confused here...
The standard advice for any "banked" GPIOs is to represent
each "bank" as a separate node (with a corresponding gpio_chip
in the Linux kernel). Then you can just use the standard
bindings to pick a line from one of these nodes.
> The PIN_INPUT/PIN_OUTPUT is defined in similar fashion in other pinctrl
> binding header files... I can drop the define and use, but as it will be
> used to address individual pins, I think it adds to readability.
Hmmm. What makes these names expecially confusing is the
Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml defines:
input-enable
input-disable
output-enable
output-high
output-low
In the Linux kernel further there is:
include/linux/pinctrl/pinconf-generic.h that defines:
PIN_CONFIG_INPUT_ENABLE
PIN_CONFIG_OUTPUT_ENABLE
PIN_CONFIG_OUTPUT
Since you are using the pin control framework this gets really
hard to hash out.
I don't really understand why it is needed.
> Like this (excerpts from a DT with a switchdev driver using SFP's and
> LED's on sgpio):
>
> /{
> leds {
> compatible = "gpio-leds";
> led@0 {
> label = "eth60:yellow";
> gpios = <&sgpio1 28 0 PIN_OUTPUT GPIO_ACTIVE_LOW>;
> default-state = "off";
> };
> ...
> };
> };
If what you intend to achieve is to make the GPIO come up in output mode,
you can either just have the driver do that as needed by the consumer.
If you absolutely have to do it in the device tree, then implement
pin control (pin config) and have it something like this:
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
pinctrl-0 = <&my_led_pinctrl>;
led@0 {
label = "eth60:yellow";
gpios = <&sgpio1 28 GPIO_ACTIVE_LOW>;
default-state = "off";
};
...
my_led_pinctrl: pinctrl-led {
pins = "gpio95"; // Just an example way of referring to the pin
bias-disable;
output-enable;
};
};
> >> + microchip,sgpio-port-ranges:
> >> +description: This is a sequence of tuples, defining intervals of
> >> + enabled ports in the serial input stream. The enabled ports must
> >> + match the hardware configuration in order for signals to be
> >> + properly written/read to/from the controller holding
> >> + registers. Being tuples, then number of arguments must be
> >> + even. The tuples mast be ordered (low, high) and are
> >> + inclusive. Arguments must be between 0 and 31.
> >> +$ref: /schemas/types.yaml#/definitions/uint32-array
> >> +minItems: 2
> >> +maxItems: 64
> >
> > And you are *absolutely sure* that you can't just figure this out
> > from the compatible string? Or add a few compatible strings for
> > the existing variants?
>
> Yes, this really needs to be configured for each board individually -
> and cant be probed. It defines how the bitstream to/from the shift
> registers is constructed/demuxed.
And you have considered the option of simply letting the driver
check which board we are then? The property at the very
top of the device tree.
if (of_machine_is_compatible("my_board")) {
} else if (of_machine_is_compatible("my_other_board")) {
}
So that you simply use the board compatible string to determine
this?
> >> +/* mchp-sgpio specific pin type defines */
> >> +#undef PIN_OUTPUT
> >> +#undef PIN_INPUT
> >> +#define PIN_OUTPUT 0
> >> +#define PIN_INPUT 1
> >
> > I'm not a fan of this. It seems like something that should be set in
> > response to the gpiochip callbacks .direction_input and
> > .direction_output callbacks.
> >
>
> As I tried to explain a
[PATCH v2 1/2] dt-bindings: gpio: pca953x: Add support for the NXP PCAL9554B/C
The NXP PCAL9554B is a variant of the PCA953x GPIO expander, with 8 GPIOs, latched interrupts and some advanced configuration options. The "C" version only differs in I2C address. This adds the entry to the devicetree bindings. Signed-off-by: Mike Looijmans --- v2: Split devicetree and code into separate patches Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt index 3126c3817e2a..99dc1936f633 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt @@ -20,6 +20,7 @@ Required properties: nxp,pcal6416 nxp,pcal6524 nxp,pcal9535 + nxp,pcal9554b nxp,pcal9555a maxim,max7310 maxim,max7312 -- 2.17.1
[PATCH v2 2/2] gpio: pca953x: Add support for the NXP PCAL9554B/C
The NXP PCAL9554B is a variant of the PCA953x GPIO expander,
with 8 GPIOs, latched interrupts and some advanced configuration
options. The "C" version only differs in I2C address.
Signed-off-by: Mike Looijmans
---
v2: Split devicetree and code into separate patches
drivers/gpio/gpio-pca953x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index bd2e96c34f82..fb946b01512d 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -90,6 +90,7 @@ static const struct i2c_device_id pca953x_id[] = {
{ "pcal6416", 16 | PCA953X_TYPE | PCA_LATCH_INT, },
{ "pcal6524", 24 | PCA953X_TYPE | PCA_LATCH_INT, },
{ "pcal9535", 16 | PCA953X_TYPE | PCA_LATCH_INT, },
+ { "pcal9554b", 8 | PCA953X_TYPE | PCA_LATCH_INT, },
{ "pcal9555a", 16 | PCA953X_TYPE | PCA_LATCH_INT, },
{ "max7310", 8 | PCA953X_TYPE, },
@@ -1237,6 +1238,7 @@ static const struct of_device_id pca953x_dt_ids[] = {
{ .compatible = "nxp,pcal6416", .data = OF_953X(16, PCA_LATCH_INT), },
{ .compatible = "nxp,pcal6524", .data = OF_953X(24, PCA_LATCH_INT), },
{ .compatible = "nxp,pcal9535", .data = OF_953X(16, PCA_LATCH_INT), },
+ { .compatible = "nxp,pcal9554b", .data = OF_953X( 8, PCA_LATCH_INT), },
{ .compatible = "nxp,pcal9555a", .data = OF_953X(16, PCA_LATCH_INT), },
{ .compatible = "maxim,max7310", .data = OF_953X( 8, 0), },
--
2.17.1
RE: [PATCH 6/8] usb: cdnsp: Device side header file for CDNSP driver
>
>
>On 20-09-28 14:27:39, Pawel Laszczak wrote:
>> Patch defines macros, registers and structures used by
>> Device side driver.
>>
>> Because the size of main patch is very big, I’ve decided to create
>> separate patch for gadget.h. It should simplify reviewing the code.
>>
>> Signed-off-by: Pawel Laszczak
>> ---
>> drivers/usb/cdnsp/gadget.h | 1459
>
>I have no seen there are folder cdnsp from previous patches.
Yes, it's true, but cdnsp folder is creating during applying this patch.
Pawel
>> 1 file changed, 1459 insertions(+)
>> create mode 100644 drivers/usb/cdnsp/gadget.h
>>
>> diff --git a/drivers/usb/cdnsp/gadget.h b/drivers/usb/cdnsp/gadget.h
>> new file mode 100644
>> index ..bfc4196c3b10
>> --- /dev/null
>> +++ b/drivers/usb/cdnsp/gadget.h
>> @@ -0,0 +1,1459 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Cadence CDNSP DRD Driver.
>> + *
>> + * Copyright (C) 2020 Cadence.
>> + *
>> + * Author: Pawel Laszczak
>> + *
>> + * Code based on Linux XHCI driver.
>> + * Origin: Copyright (C) 2008 Intel Corp.
>> + */
>> +#ifndef __LINUX_CDNSP_GADGET_H
>> +#define __LINUX_CDNSP_GADGET_H
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +/* Max number slots - only 1 is allowed. */
>> +#define CDNSP_DEV_MAX_SLOTS 1
>> +
>> +#define CDNSP_EP0_SETUP_SIZE512
>> +
>> +/*16 for in and 16 for out. */
>> +#define CDNSP_ENDPOINTS_NUM 32
>> +
>> +/* Best Effort Service Latency. */
>> +#define CDNSP_DEFAULT_BESL 0
>> +
>> +/* Device Controller command default timeout value in us */
>> +#define CDNSP_CMD_TIMEOUT (15 * 1000)
>> +
>> +/* Up to 16 ms to halt an device controller */
>> +#define CDNSP_MAX_HALT_USEC (16 * 1000)
>> +
>> +#define CDNSP_CTX_SIZE 2112
>> +
>> +/*
>> + * Controller register interface.
>> + */
>> +
>> +/**
>> + * struct cdnsp_cap_regs - CDNSP Registers.
>> + * @hc_capbase: Length of the capabilities register and controller
>> + * version number
>> + * @hcs_params1: HCSPARAMS1 - Structural Parameters 1
>> + * @hcs_params2: HCSPARAMS2 - Structural Parameters 2
>> + * @hcs_params3: HCSPARAMS3 - Structural Parameters 3
>> + * @hcc_params: HCCPARAMS - Capability Parameters
>> + * @db_off: DBOFF - Doorbell array offset
>> + * @run_regs_off: RTSOFF - Runtime register space offset
>> + * @hcc_params2: HCCPARAMS2 Capability Parameters 2,
>> + */
>> +struct cdnsp_cap_regs {
>> +__le32 hc_capbase;
>> +__le32 hcs_params1;
>> +__le32 hcs_params2;
>> +__le32 hcs_params3;
>> +__le32 hcc_params;
>> +__le32 db_off;
>> +__le32 run_regs_off;
>> +__le32 hcc_params2;
>> +/* Reserved up to (CAPLENGTH - 0x1C) */
>> +};
>> +
>> +/* hc_capbase bitmasks. */
>> +/* bits 7:0 - how long is the Capabilities register. */
>> +#define HC_LENGTH(p)(((p) >> 00) & GENMASK(7, 0))
>> +/* bits 31:16 */
>> +#define HC_VERSION(p) (((p) >> 16) & GENMASK(15, 1))
>> +
>> +/* HCSPARAMS1 - hcs_params1 - bitmasks */
>> +/* bits 0:7, Max Device Endpoints */
>> +#define HCS_ENDPOINTS_MASK GENMASK(7, 0)
>> +#define HCS_ENDPOINTS(p)(((p) & HCS_ENDPOINTS_MASK) >> 0)
>> +
>> +/* HCCPARAMS offset from PCI base address */
>> +#define HCC_PARAMS_OFFSET 0x10
>> +
>> +/* HCCPARAMS - hcc_params - bitmasks */
>> +/* true: device controller can use 64-bit address pointers. */
>> +#define HCC_64BIT_ADDR(p) ((p) & BIT(0))
>> +/* true: device controller uses 64-byte Device Context structures. */
>> +#define HCC_64BYTE_CONTEXT(p) ((p) & BIT(2))
>> +/* Max size for Primary Stream Arrays - 2^(n+1), where n is bits 12:15. */
>> +#define HCC_MAX_PSA(p) p) >> 12) & 0xf) + 1)
>> +/* Extended Capabilities pointer from PCI base. */
>> +#define HCC_EXT_CAPS(p) (((p) & GENMASK(31, 16)) >> 16)
>> +
>> +#define CTX_SIZE(_hcc) (HCC_64BYTE_CONTEXT(_hcc) ? 64 : 32)
>> +
>> +/* db_off bitmask - bits 0:1 reserved. */
>> +#define DBOFF_MASK GENMASK(31, 2)
>> +
>> +/* run_regs_off bitmask - bits 0:4 reserved. */
>> +#define RTSOFF_MASK GENMASK(31, 5)
>> +
>> +/**
>> + * struct cdnsp_op_regs - Device Controller Operational Registers.
>> + * @command: USBCMD - Controller command register.
>> + * @status: USBSTS - Controller status register.
>> + * @page_size: This indicates the page size that the device controller
>> supports.
>> + * If bit n is set, the controller supports a page size of
>> 2^(n+12),
>> + * up to a 128MB page size. 4K is the minimum page size.
>> + * @dnctrl: DNCTRL - Device notification control register.
>> + * @cmd_ring: CRP - 64-bit Command Ring Pointer.
>> + * @dcbaa_ptr: DCBAAP - 64-bit Device Context Base Address Array Pointer.
>> + * @config_reg: CONFIG - Configure Register
>> + * @port_reg_base: PORTSCn - base address for Port Status and Control
>> + * Each port has a Port Status and Control register,
>> + * followed by a Port Power Management Status and Control
Re: [PATCH v2 1/1] kdump: append uts_namespace.name offset to VMCOREINFO
Hi, Alexander 在 2020年09月24日 20:46, Alexander Egorenkov 写道: > The offset of the field 'init_uts_ns.name' has changed > since > > commit 9a56493f6942c0e2df1579986128721da96e00d8 > Author: Kirill Tkhai > Date: Mon Aug 3 13:16:21 2020 +0300 > > uts: Use generic ns_common::count > > Link: > https://lore.kernel.org/r/159644978167.604812.1773586504374412107.stgit@localhost.localdomain > > Make the offset of the field 'uts_namespace.name' available > in VMCOREINFO because tools like 'crash-utility' and > 'makedumpfile' must be able to read it from crash dumps. > > Signed-off-by: Alexander Egorenkov > --- > kernel/crash_core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/kernel/crash_core.c b/kernel/crash_core.c > index 106e4500fd53..173fdc261882 100644 > --- a/kernel/crash_core.c > +++ b/kernel/crash_core.c > @@ -447,6 +447,7 @@ static int __init crash_save_vmcoreinfo_init(void) > VMCOREINFO_PAGESIZE(PAGE_SIZE); > > VMCOREINFO_SYMBOL(init_uts_ns); > + VMCOREINFO_OFFSET(uts_namespace, name); Since the new symbol is exported, would you mind adding it to Documentation/kdump/vmcoreinfo.txt ? Thanks. Lianbo > VMCOREINFO_SYMBOL(node_online_map); > #ifdef CONFIG_MMU > VMCOREINFO_SYMBOL_ARRAY(swapper_pg_dir); >
Re: [RFC-PATCH 2/4] mm: Add __rcu_alloc_page_lockless() func.
On Tue 29-09-20 18:25:14, Uladzislau Rezki wrote: > > > I look at it in scope of GFP_ATOMIC/GFP_NOWAIT issues, i.e. inability > > > to provide a memory service for contexts which are not allowed to > > > sleep, RCU is part of them. Both flags used to provide such ability > > > before but not anymore. > > > > > > Do you agree with it? > > > > Yes this sucks. But this is something that we likely really want to live > > with. We have to explicitly _document_ that really atomic contexts in RT > > cannot use the allocator. From the past discussions we've had this is > > likely the most reasonable way forward because we do not really want to > > encourage anybody to do something like that and there should be ways > > around that. The same is btw. true also for !RT. The allocator is not > > NMI safe and while we should be able to make it compatible I am not > > convinced we really want to. > > > > Would something like this be helpful wrt documentation? > > > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > > index 67a0774e080b..9fcd47606493 100644 > > --- a/include/linux/gfp.h > > +++ b/include/linux/gfp.h > > @@ -238,7 +238,9 @@ struct vm_area_struct; > > * %__GFP_FOO flags as necessary. > > * > > * %GFP_ATOMIC users can not sleep and need the allocation to succeed. A > > lower > > - * watermark is applied to allow access to "atomic reserves" > > + * watermark is applied to allow access to "atomic reserves". > > + * The current implementation doesn't support NMI and other non-preemptive > > context > > + * (e.g. raw_spin_lock). > > * > > * %GFP_KERNEL is typical for kernel-internal allocations. The caller > > requires > > * %ZONE_NORMAL or a lower zone for direct access but can direct reclaim. > > > To me it is clear. But also above conflicting statement: > > > %GFP_ATOMIC users can not sleep and need the allocation to succeed. A %lower > > > should be rephrased, IMHO. Any suggestions? Or more specifics about which part is conflicting? It tries to say that there is a higher demand to succeed even though the context cannot sleep to take active measures to achieve that. So the only way to achieve that is to break the watermakrs to a certain degree which is making them more "higher class" than other allocations. -- Michal Hocko SUSE Labs
Re: [PATCH bpf-next v2 2/4] selftests: bpf: Add helper to compare socket cookies
On Tue, 29 Sep 2020 at 16:48, Alexei Starovoitov
wrote:
...
> There was a warning. I noticed it while applying and fixed it up.
> Lorenz, please upgrade your compiler. This is not the first time such
> warning has been missed.
I tried reproducing this on latest bpf-next (b0efc216f577997) with gcc
9.3.0 by removing the initialization of duration:
make: Entering directory '/home/lorenz/dev/bpf-next/tools/testing/selftests/bpf'
TEST-OBJ [test_progs] sockmap_basic.test.o
TEST-HDR [test_progs] tests.h
EXT-OBJ [test_progs] test_progs.o
EXT-OBJ [test_progs] cgroup_helpers.o
EXT-OBJ [test_progs] trace_helpers.o
EXT-OBJ [test_progs] network_helpers.o
EXT-OBJ [test_progs] testing_helpers.o
BINARY test_progs
make: Leaving directory '/home/lorenz/dev/bpf-next/tools/testing/selftests/bpf'
So, gcc doesn't issue a warning. Jakub did the following little experiment:
jkbs@toad ~/tmp $ cat warning.c
#include
int main(void)
{
int duration;
fprintf(stdout, "%d", duration);
return 0;
}
jkbs@toad ~/tmp $ gcc -Wall -o /dev/null warning.c
warning.c: In function ‘main’:
warning.c:7:2: warning: ‘duration’ is used uninitialized in this
function [-Wuninitialized]
7 | fprintf(stdout, "%d", duration);
| ^~~
The simple case seems to work. However, adding the macro breaks things:
jkbs@toad ~/tmp $ cat warning.c
#include
#define _CHECK(duration) \
({ \
fprintf(stdout, "%d", duration);\
})
#define CHECK() _CHECK(duration)
int main(void)
{
int duration;
CHECK();
return 0;
}
jkbs@toad ~/tmp $ gcc -Wall -o /dev/null warning.c
jkbs@toad ~/tmp $
Maybe this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 ? The
problem is still there on gcc 10. Compiling test_progs with clang does
issue a warning FWIW, but it seems like other things break when doing
that.
--
Lorenz Bauer | Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK
www.cloudflare.com
Re: [PATCH v9 0/4] Introduce the for_each_set_clump macro
On Tue, Sep 29, 2020 at 3:14 PM Andy Shevchenko wrote: > Linus, are you referencing to [3]? It was fixed in GENMASK() > implementation some time ago. > [3]: https://lore.kernel.org/lkml/202006171559.jsbgjxnw%25...@intel.com/ Yup. I tried to apply the patches again now to test it but now patch 2 needs to be rebased. Sorry for all the trouble! Syed can you rebase the patch set on v5.9-rc1 and resend as v10? Yours, Linus Walleij
Re: [PATCH v1] i2c: npcm7xx: Support changing bus speed using debugfs.
On Wed, Sep 30, 2020 at 10:13:42AM +0300, Tali Perry wrote:
> Systems that can dinamically add and remove slave devices
dynamically
> often need to change the bus speed in runtime.
> This patch exposes the bus frequency to the user.
Expose the bus frequency to the user.
> This feature can also be used for test automation.
In general I think that DT overlays or so should be user rather than this.
If we allow to change bus speed settings for debugging purposes it might make
sense to do this on framework level for all drivers which support that (via
additional callback or so).
> Fixes: 56a1485b102e (i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver)
> Signed-off-by: Tali Perry
> ---
> drivers/i2c/busses/i2c-npcm7xx.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-npcm7xx.c
> b/drivers/i2c/busses/i2c-npcm7xx.c
> index 2ad166355ec9..44e2340c1893 100644
> --- a/drivers/i2c/busses/i2c-npcm7xx.c
> +++ b/drivers/i2c/busses/i2c-npcm7xx.c
> @@ -2208,6 +2208,41 @@ static const struct i2c_algorithm npcm_i2c_algo = {
> /* i2c debugfs directory: used to keep health monitor of i2c devices */
> static struct dentry *npcm_i2c_debugfs_dir;
>
> +static int i2c_speed_get(void *data, u64 *val)
> +{
> + struct npcm_i2c *bus = data;
> +
> + *val = (u64)bus->bus_freq;
> + return 0;
> +}
> +
> +static int i2c_speed_set(void *data, u64 val)
> +{
> + struct npcm_i2c *bus = data;
> + int ret;
> +
> + if (val < (u64)I2C_FREQ_MIN_HZ || val > (u64)I2C_FREQ_MAX_HZ)
> + return -EINVAL;
> +
> + if (val == (u64)bus->bus_freq)
> + return 0;
> +
> + i2c_lock_bus(&bus->adap, I2C_LOCK_ROOT_ADAPTER);
> +
> + npcm_i2c_int_enable(bus, false);
> +
> + ret = npcm_i2c_init_module(bus, I2C_MASTER, (u32)val);
> +
> + i2c_unlock_bus(&bus->adap, I2C_LOCK_ROOT_ADAPTER);
While all these explicit castings?
> +
> + if (ret)
> + return -EAGAIN;
> +
> + return 0;
> +}
> +
No need to have this blank line
> +DEFINE_DEBUGFS_ATTRIBUTE(i2c_clock_ops, i2c_speed_get, i2c_speed_set,
> "%lld\n");
> +
> static void npcm_i2c_init_debugfs(struct platform_device *pdev,
> struct npcm_i2c *bus)
> {
> @@ -2223,6 +2258,7 @@ static void npcm_i2c_init_debugfs(struct
> platform_device *pdev,
> debugfs_create_u64("rec_succ_cnt", 0444, d, &bus->rec_succ_cnt);
> debugfs_create_u64("rec_fail_cnt", 0444, d, &bus->rec_fail_cnt);
> debugfs_create_u64("timeout_cnt", 0444, d, &bus->timeout_cnt);
> + debugfs_create_file("i2c_speed", 0644, d, bus, &i2c_clock_ops);
>
> bus->debugfs = d;
> }
--
With Best Regards,
Andy Shevchenko
Re: [PATCH v2 1/2] devfreq: qcom: Add L2 Krait Cache devfreq scaling driver
On Tue, Sep 29, 2020 at 06:29:24PM +0200, Ansuel Smith wrote: > Qcom L2 Krait CPUs use the generic cpufreq-dt driver and doesn't actually > scale the Cache frequency when the CPU frequency is changed. This > devfreq driver register with the cpu notifier and scale the Cache > based on the max Freq across all core as the CPU cache is shared across > all of them. If provided this also scale the voltage of the regulator > attached to the CPU cache. The scaling logic is based on the CPU freq > and the 3 scaling interval are set by the device dts. > I have raised this concern before. I am worried this kind of independent CPU and cache frequency controls make way for clkscrew kind of attacks. Why can't the clocks be made parent/child or secondary and automatically updated when CPU clocks are changed. -- Regards, Sudeep
[PATCH v2] drivers/perf: Add support for ARMv8.3-SPE
Armv8.3 extends the SPE by adding:
- Alignment field in the Events packet, and filtering on this event
using PMSEVFR_EL1.
- Support for the Scalable Vector Extension (SVE).
The main additions for SVE are:
- Recording the vector length for SVE operations in the Operation Type
packet. It is not possible to filter on vector length.
- Incomplete predicate and empty predicate fields in the Events packet,
and filtering on these events using PMSEVFR_EL1.
Update the check of pmsevfr for empty/partial predicated SVE and
alignment event in SPE driver. For adaption by the version of SPE,
expose 'pmsver' as cap attribute to userspace.
Signed-off-by: Wei Li
---
v1 -> v2:
- Rename 'pmuver' to 'pmsver', change it's type to 'u16' from 'int'.
(Suggested by Will and Leo.)
- Expose 'pmsver' as cap attribute through sysfs, instead of printing.
(Suggested by Will.)
---
arch/arm64/include/asm/sysreg.h | 4 +++-
drivers/perf/arm_spe_pmu.c | 18 --
2 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index 554a7e8ecb07..f4f9c1fc6398 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -281,7 +281,6 @@
#define SYS_PMSFCR_EL1_ST_SHIFT18
#define SYS_PMSEVFR_EL1sys_reg(3, 0, 9, 9, 5)
-#define SYS_PMSEVFR_EL1_RES0 0x00ff0f55UL
#define SYS_PMSLATFR_EL1 sys_reg(3, 0, 9, 9, 6)
#define SYS_PMSLATFR_EL1_MINLAT_SHIFT 0
@@ -787,6 +786,9 @@
#define ID_AA64DFR0_PMUVER_8_5 0x6
#define ID_AA64DFR0_PMUVER_IMP_DEF 0xf
+#define ID_AA64DFR0_PMSVER_8_2 0x1
+#define ID_AA64DFR0_PMSVER_8_3 0x2
+
#define ID_DFR0_PERFMON_SHIFT 24
#define ID_DFR0_PERFMON_8_10x4
diff --git a/drivers/perf/arm_spe_pmu.c b/drivers/perf/arm_spe_pmu.c
index cc00915ad6d1..52e7869f5621 100644
--- a/drivers/perf/arm_spe_pmu.c
+++ b/drivers/perf/arm_spe_pmu.c
@@ -54,7 +54,7 @@ struct arm_spe_pmu {
struct hlist_node hotplug_node;
int irq; /* PPI */
-
+ u16 pmsver;
u16 min_period;
u16 counter_sz;
@@ -80,6 +80,15 @@ struct arm_spe_pmu {
/* Keep track of our dynamic hotplug state */
static enum cpuhp_state arm_spe_pmu_online;
+static u64 sys_pmsevfr_el1_mask[] = {
+ [ID_AA64DFR0_PMSVER_8_2] = GENMASK_ULL(63, 48) | GENMASK_ULL(31, 24) |
+ GENMASK_ULL(15, 12) | BIT_ULL(7) | BIT_ULL(5) | BIT_ULL(3) |
+ BIT_ULL(1),
+ [ID_AA64DFR0_PMSVER_8_3] = GENMASK_ULL(63, 48) | GENMASK_ULL(31, 24) |
+ GENMASK_ULL(18, 17) | GENMASK_ULL(15, 11) | BIT_ULL(7) |
+ BIT_ULL(5) | BIT_ULL(3) | BIT_ULL(1),
+};
+
enum arm_spe_pmu_buf_fault_action {
SPE_PMU_BUF_FAULT_ACT_SPURIOUS,
SPE_PMU_BUF_FAULT_ACT_FATAL,
@@ -93,6 +102,7 @@ enum arm_spe_pmu_capabilities {
SPE_PMU_CAP_FEAT_MAX,
SPE_PMU_CAP_CNT_SZ = SPE_PMU_CAP_FEAT_MAX,
SPE_PMU_CAP_MIN_IVAL,
+ SPE_PMU_CAP_PMSVER,
};
static int arm_spe_pmu_feat_caps[SPE_PMU_CAP_FEAT_MAX] = {
@@ -110,6 +120,8 @@ static u32 arm_spe_pmu_cap_get(struct arm_spe_pmu *spe_pmu,
int cap)
return spe_pmu->counter_sz;
case SPE_PMU_CAP_MIN_IVAL:
return spe_pmu->min_period;
+ case SPE_PMU_CAP_PMSVER:
+ return spe_pmu->pmsver;
default:
WARN(1, "unknown cap %d\n", cap);
}
@@ -143,6 +155,7 @@ static struct attribute *arm_spe_pmu_cap_attr[] = {
SPE_CAP_EXT_ATTR_ENTRY(ernd, SPE_PMU_CAP_ERND),
SPE_CAP_EXT_ATTR_ENTRY(count_size, SPE_PMU_CAP_CNT_SZ),
SPE_CAP_EXT_ATTR_ENTRY(min_interval, SPE_PMU_CAP_MIN_IVAL),
+ SPE_CAP_EXT_ATTR_ENTRY(pmsver, SPE_PMU_CAP_PMSVER),
NULL,
};
@@ -670,7 +683,7 @@ static int arm_spe_pmu_event_init(struct perf_event *event)
!cpumask_test_cpu(event->cpu, &spe_pmu->supported_cpus))
return -ENOENT;
- if (arm_spe_event_to_pmsevfr(event) & SYS_PMSEVFR_EL1_RES0)
+ if (arm_spe_event_to_pmsevfr(event) &
~sys_pmsevfr_el1_mask[spe_pmu->pmsver])
return -EOPNOTSUPP;
if (attr->exclude_idle)
@@ -937,6 +950,7 @@ static void __arm_spe_pmu_dev_probe(void *info)
fld, smp_processor_id());
return;
}
+ spe_pmu->pmsver = (u16)fld;
/* Read PMBIDR first to determine whether or not we have access */
reg = read_sysreg_s(SYS_PMBIDR_EL1);
--
2.17.1
Re: [PATCH v14 0/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC
Hi Miquel, On 28/9/2020 10:25 pm, Miquel Raynal wrote: Hello, "Ramuthevar,Vadivel MuruganX" wrote on Thu, 24 Sep 2020 16:48:40 +0800: This patch adds the new IP of Nand Flash Controller(NFC) support on Intel's Lightning Mountain(LGM) SoC. DMA is used for burst data transfer operation, also DMA HW supports aligned 32bit memory address and aligned data access by default. DMA burst of 8 supported. Data register used to support the read/write operation from/to device. NAND controller also supports in-built HW ECC engine. NAND controller driver implements ->exec_op() to replace legacy hooks, these specific call-back method to execute NAND operations. Thanks Miquel, Boris, Andy, Arnd and Rob for the review comments and suggestions. --- v14: - Address Andy's review comments - align the headers and revome Duplicates - replcace numerical const values by HZ_PER_MHZ and USEC_PER_SEC defined macros - add dev_err_probe() api instead of legacy err check - add get_unaligned_le32() api instead of manual endiness - remove redudent check - split the lines logically in between and add require spaces v13: - Address Miquel Raynal review comments - update the return type with variable 'ret' - handle err check statement properly - change the naming convention aligned with recently changed the naming around the data interface data structure and function names - replace by div 8 instead of <<4 in ecc calculation better code readability - handle check_only properly like existing drivers I am sorry but there are two to three comments which you did not address or addressed partially while not so impacting on the logic, can you please review and address them all? (please note that I checked the patch adding the driver before telling you that). Thank you for your comments...! Sure, I will review once again all your comments in the previous patch sent if anything is missed then will add it and send the updated patch. Regards Vadivel Thanks, Miquèl
Re: [PATCH v3 4/4] dt-bindings: gpio: gpio-vf610: fix iMX 7ULP compatible matching
On Tue, Sep 29, 2020 at 4:02 PM Rob Herring wrote:
> On Tue, Sep 29, 2020 at 01:54:44PM +0200, Linus Walleij wrote:
> > On Sun, Sep 20, 2020 at 9:59 PM Krzysztof Kozlowski wrote:
> >
> > > The i.MX 7ULP DTSes use two compatibles so update the binding to fix
> > > dtbs_check warnings like:
> > >
> > > arch/arm/boot/dts/imx7ulp-com.dt.yaml: gpio@40ae:
> > > compatible: ['fsl,imx7ulp-gpio', 'fsl,vf610-gpio'] is too long
> > >
> > > arch/arm/boot/dts/imx7ulp-com.dt.yaml: gpio@40ae:
> > > compatible: Additional items are not allowed ('fsl,vf610-gpio' was
> > > unexpected)
> > >
> > > Signed-off-by: Krzysztof Kozlowski
> >
> > This patch doesn't apply to my tree linux-gpio "devel":
> >
> > $ git am --signoff
> > ./v3_20200920_krzk_dt_bindings_gpio_pl061_add_gpio_line_names.mbx
> > Applying: dt-bindings: gpio: gpio-vf610: fix iMX 7ULP compatible matching
> > error: Documentation/devicetree/bindings/gpio/gpio-vf610.yaml: does
> > not exist in index
> > Patch failed at 0001 dt-bindings: gpio: gpio-vf610: fix iMX 7ULP
> > compatible matching
>
> It's in my tree, so I've applied it.
Excellent, thanks Rob.
Yours,
Linus Walleij
Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2
On Wed, Sep 30, 2020 at 2:15 AM Tony Lindgren wrote:
>
> * Trent Piepho [200930 08:35]:
> > The closest thing would be the generic pin config type bindings, which
> > go in the pinctrl driver's nodes, and look like this:
> > &am335x_pinmux {
> > pinctrl_yoyo_reset: yoyogrp {
> > pins = "foo";
> > function = "gpio";
> > bias-pull-up;
> > };
> > };
>
> There's a bit of a dtb size and boot time issue for adding properties
> for each pin where that needs to be done for several hundred pins :)
pins is list, multiple pins can be specified at once. Otherwise the
property name would be "pin" and not "pins" There's also a groups
property to refer to multiple pins at once, e.g.
arch/mips/boot/dts/ingenic/ci20.dts-pins_mmc1: mmc1 {
arch/mips/boot/dts/ingenic/ci20.dts-function = "mmc1";
arch/mips/boot/dts/ingenic/ci20.dts:groups =
"mmc1-1bit-d", "mmc1-4bit-d";
arch/mips/boot/dts/ingenic/ci20.dts-bias-disable;
arch/mips/boot/dts/ingenic/ci20.dts-};
arch/mips/boot/dts/pic32/pic32mzda_sk.dts- user_leds_s0: user_leds_s0 {
arch/mips/boot/dts/pic32/pic32mzda_sk.dts: pins = "H0", "H1", "H2";
arch/mips/boot/dts/pic32/pic32mzda_sk.dts- output-low;
arch/mips/boot/dts/pic32/pic32mzda_sk.dts- microchip,digital;
arch/mips/boot/dts/pic32/pic32mzda_sk.dts- };
> > Is "some additional property for specifying generic conf flags"
> > different from the existing pinctrl-single,bias-pullup, etc.
> > properties? Because splitting the data cell into two parts doesn't
> > make any difference to those.
>
> So with an interrupt style binding with generic pinconf flags we can
> leave out the parsing of multiple properties for each pin. Sure the
> pin is only referenced by the controller like you pointed out but the
> pinconf flags could be generic.
Where do these flags go? In pinctrl-single,pins? Like:
pinctrl-single,pins = ;
But PIN_INPUT_PULLUP is a generic flag? Which is translated into the
proper value by??
Or are you talking about replacing the existing pinctrl-0,
pinctrl-names properties with a totally different system that looks
more like gpio and interrupt handles?
Re: [RESEND PATCH 1/2] mtd: spi-nor: do not touch TB bit without SPI_NOR_HAS_TB
On 9/21/20 4:54 PM, Ivan Mikhaylov wrote: > Some chips like macronix don't have TB(Top/Bottom protection) > bit in the status register. Do not write tb_mask inside status > register, unless SPI_NOR_HAS_TB is present for the chip. > Not entirely accurate.. Macronix chips have TB bit in config register and is OTP and hence should not be touched ideally... You still need to "read" that bit to determine actual scheme (Top vs Bottom). This is needs to be done before 2/2 enables SPI_NOR_HAS_LOCK flag for macronix flashes. > Signed-off-by: Ivan Mikhaylov > --- > drivers/mtd/spi-nor/core.c | 22 -- > 1 file changed, 16 insertions(+), 6 deletions(-) > > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c > index 0369d98b2d12..f9853dd566dc 100644 > --- a/drivers/mtd/spi-nor/core.c > +++ b/drivers/mtd/spi-nor/core.c > @@ -1735,13 +1735,18 @@ static int spi_nor_sr_lock(struct spi_nor *nor, > loff_t ofs, uint64_t len) > return -EINVAL; > } > > - status_new = (status_old & ~mask & ~tb_mask) | val; > + if (nor->flags & SNOR_F_HAS_SR_TB) > + status_new = (status_old & ~mask & ~tb_mask) | val; > + else > + status_new = (status_old & ~mask) | val; > > /* Disallow further writes if WP pin is asserted */ > status_new |= SR_SRWD; > I guess macronix does not support SR_SRWD right? This needs special treatment as well. So either, macronix.c should implements its own locking ops or convert this function in to more generic library so that its suitable to be called from macronix.c file while hiding vendor specific stuff in that driver, Regards Vignesh
RE: [PATCH 2/8] usb: cdns3: Split core.c into cdns3-plat and core.c file
>
>
>On 20-09-28 14:27:35, Pawel Laszczak wrote:
>> Patch splits file core.c into core.c containing the common reusable code
>> and cnd3-plat.c containing device platform specific code. These changes
>
>cdns3-plat.c
>
>Pawel, at 5.10-rc1, there are some cdns3 driver updates at Felipe's
>next tree, you may create patches based on that to avoid rebase effects in
>future.
>
Yes, I know. The cdnsp is put in drivers/usb directory and I was not sure
on which repository I should based on.
This series can be successfully applied on Linux-Next and Greg (usb)
repository.
As I remember we also have some patch not added to Felipe repository.
I hope that next version will contain all latest changes in drd.c and core.c.
Thanks
Pawel
>
>> are required to make possible reuse DRD part of CDNS3 driver in CDNSP
>> driver.
>>
>> Signed-off-by: Pawel Laszczak
>> ---
>> drivers/usb/cdns3/Makefile | 2 +-
>> drivers/usb/cdns3/cdns3-plat.c | 209 +
>> drivers/usb/cdns3/core.c | 181 +++-
>> drivers/usb/cdns3/core.h | 8 +-
>> 4 files changed, 234 insertions(+), 166 deletions(-)
>> create mode 100644 drivers/usb/cdns3/cdns3-plat.c
>>
>> diff --git a/drivers/usb/cdns3/Makefile b/drivers/usb/cdns3/Makefile
>> index d47e341a6f39..a1fe9612053a 100644
>> --- a/drivers/usb/cdns3/Makefile
>> +++ b/drivers/usb/cdns3/Makefile
>> @@ -2,7 +2,7 @@
>> # define_trace.h needs to know how to find our header
>> CFLAGS_trace.o := -I$(src)
>>
>> -cdns3-y := core.o drd.o
>> +cdns3-y := cdns3-plat.o core.o drd.o
>>
>> obj-$(CONFIG_USB_CDNS3) += cdns3.o
>> cdns3-$(CONFIG_USB_CDNS3_GADGET)+= gadget.o ep0.o
>> diff --git a/drivers/usb/cdns3/cdns3-plat.c b/drivers/usb/cdns3/cdns3-plat.c
>> new file mode 100644
>> index ..f35e9dca30fe
>> --- /dev/null
>> +++ b/drivers/usb/cdns3/cdns3-plat.c
>> @@ -0,0 +1,209 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Cadence USBSS DRD Driver.
>> + *
>> + * Copyright (C) 2018-2020 Cadence.
>> + * Copyright (C) 2017-2018 NXP
>> + * Copyright (C) 2019 Texas Instrumentsq
>> + *
>> + *
>> + * Author: Peter Chen
>> + * Pawel Laszczak
>> + * Roger Quadros
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include "core.h"
>> +
>> +/**
>> + * cdns3_plat_probe - probe for cdns3 core device
>> + * @pdev: Pointer to cdns3 core platform device
>> + *
>> + * Returns 0 on success otherwise negative errno
>> + */
>> +static int cdns3_plat_probe(struct platform_device *pdev)
>> +{
>> +struct device *dev = &pdev->dev;
>> +struct resource *res;
>> +struct cdns3 *cdns;
>> +void __iomem *regs;
>> +int ret;
>> +
>> +cdns = devm_kzalloc(dev, sizeof(*cdns), GFP_KERNEL);
>> +if (!cdns)
>> +return -ENOMEM;
>> +
>> +cdns->dev = dev;
>> +
>> +platform_set_drvdata(pdev, cdns);
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_IRQ, "host");
>> +if (!res) {
>> +dev_err(dev, "missing host IRQ\n");
>> +return -ENODEV;
>> +}
>> +
>> +cdns->xhci_res[0] = *res;
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "xhci");
>> +if (!res) {
>> +dev_err(dev, "couldn't get xhci resource\n");
>> +return -ENXIO;
>> +}
>> +
>> +cdns->xhci_res[1] = *res;
>> +
>> +cdns->dev_irq = platform_get_irq_byname(pdev, "peripheral");
>> +if (cdns->dev_irq == -EPROBE_DEFER)
>> +return cdns->dev_irq;
>> +
>> +if (cdns->dev_irq < 0)
>> +dev_err(dev, "couldn't get peripheral irq\n");
>> +
>> +regs = devm_platform_ioremap_resource_byname(pdev, "dev");
>> +if (IS_ERR(regs))
>> +return PTR_ERR(regs);
>> +cdns->dev_regs = regs;
>> +
>> +cdns->otg_irq = platform_get_irq_byname(pdev, "otg");
>> +if (cdns->otg_irq == -EPROBE_DEFER)
>> +return cdns->otg_irq;
>> +
>> +if (cdns->otg_irq < 0) {
>> +dev_err(dev, "couldn't get otg irq\n");
>> +return cdns->otg_irq;
>> +}
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otg");
>> +if (!res) {
>> +dev_err(dev, "couldn't get otg resource\n");
>> +return -ENXIO;
>> +}
>> +
>> +cdns->otg_res = *res;
>> +
>> +cdns->usb2_phy = devm_phy_optional_get(dev, "cdns3,usb2-phy");
>> +if (IS_ERR(cdns->usb2_phy))
>> +return PTR_ERR(cdns->usb2_phy);
>> +
>> +ret = phy_init(cdns->usb2_phy);
>> +if (ret)
>> +return ret;
>> +
>> +cdns->usb3_phy = devm_phy_optional_get(dev, "cdns3,usb3-phy");
>> +if (IS_ERR(cdns->usb3_phy))
>> +return PTR_ERR(cdns->usb3_phy);
>> +
>> +ret = phy_init(cdns->usb3_phy);
>> +if (ret)
>> +goto err_phy3_init;
>> +
>> +ret = phy_power_on(cdns->usb2_p
Re: [PATCH bpf-next v2 4/4] selftest: bpf: Test copying a sockmap and sockhash
On Tue, 29 Sep 2020 at 18:23, Martin KaFai Lau wrote: ... > > Yeah, I think so. We'd need to do something similar to your > > sock_common work for PTR_TO_RDONLY_BUF_OR_NULL. The fact that the > > pointer is read only makes it a bit more difficult I think. After > I thought the key arg should be used as read-only in the map's helper. > or there is map type's helper that modifies the key? I don't know, that's what I meant by more difficult. If map keys are always read-only like you say this would be straight forward to do (famous last words). -- Lorenz Bauer | Systems Engineer 6th Floor, County Hall/The Riverside Building, SE1 7PB, UK www.cloudflare.com
Re: [PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v5)
On 2020-03-17 10:21 p.m., Jason Ekstrand wrote: Explicit synchronization is the future. At least, that seems to be what most userspace APIs are agreeing on at this point. However, most of our Linux APIs (both userspace and kernel UAPI) are currently built around implicit synchronization with dma-buf. While work is ongoing to change many of the userspace APIs and protocols to an explicit synchronization model, switching over piecemeal is difficult due to the number of potential components involved. On the kernel side, many drivers use dma-buf including GPU (3D/compute), display, v4l, and others. In userspace, we have X11, several Wayland compositors, 3D drivers, compute drivers (OpenCL etc.), media encode/decode, and the list goes on. This patch provides a path forward by allowing userspace to manually manage the fences attached to a dma-buf. Alternatively, one can think of this as making dma-buf's implicit synchronization simply a carrier for an explicit fence. This is accomplished by adding two IOCTLs to dma-buf for importing and exporting a sync file to/from the dma-buf. This way a userspace component which is uses explicit synchronization, such as a Vulkan driver, can manually set the write fence on a buffer before handing it off to an implicitly synchronized component such as a Wayland compositor or video encoder. In this way, each of the different components can be upgraded to an explicit synchronization model one at a time as long as the userspace pieces connecting them are aware of it and import/export fences at the right times. There is a potential race condition with this API if userspace is not careful. A typical use case for implicit synchronization is to wait for the dma-buf to be ready, use it, and then signal it for some other component. Because a sync_file cannot be created until it is guaranteed to complete in finite time, userspace can only signal the dma-buf after it has already submitted the work which uses it to the kernel and has received a sync_file back. There is no way to atomically submit a wait-use-signal operation. This is not, however, really a problem with this API so much as it is a problem with explicit synchronization itself. The way this is typically handled is to have very explicit ownership transfer points in the API or protocol which ensure that only one component is using it at any given time. Both X11 (via the PRESENT extension) and Wayland provide such ownership transfer points via explicit present and idle messages. The decision was intentionally made in this patch to make the import and export operations IOCTLs on the dma-buf itself rather than as a DRM IOCTL. This makes it the import/export operation universal across all components which use dma-buf including GPU, display, v4l, and others. It also means that a userspace component can do the import/export without access to the DRM fd which may be tricky to get in cases where the client communicates with DRM via a userspace API such as OpenGL or Vulkan. At a future date we may choose to add direct import/export APIs to components such as drm_syncobj to avoid allocating a file descriptor and going through two ioctls. However, that seems to be something of a micro-optimization as import/export operations are likely to happen at a rate of a few per frame of rendered or decoded video. v2 (Jason Ekstrand): - Use a wrapper dma_fence_array of all fences including the new one when importing an exclusive fence. v3 (Jason Ekstrand): - Lock around setting shared fences as well as exclusive - Mark SIGNAL_SYNC_FILE as a read-write ioctl. - Initialize ret to 0 in dma_buf_wait_sync_file v4 (Jason Ekstrand): - Use the new dma_resv_get_singleton helper v5 (Jason Ekstrand): - Rename the IOCTLs to import/export rather than wait/signal - Drop the WRITE flag and always get/set the exclusive fence Signed-off-by: Jason Ekstrand What's the status of this? DMA_BUF_IOCTL_EXPORT_SYNC_FILE would be useful for Wayland compositors to wait for client buffers to become ready without being prone to getting delayed by later HW access to them, so it would be nice to merge that at least (if DMA_BUF_IOCTL_IMPORT_SYNC_FILE is still controversial). -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer
Re: [PATCH] phy: qcom-qusb2: Add support for SDM630/660
Tested on Xiaomi Redmi Note 7 (lavender), SDM660 Tested-by: Alexey Minnekhanov On 9/26/20 4:11 PM, khol...@gmail.com wrote: > From: Konrad Dybcio > > QUSB on these SoCs actually uses *almost* the same > configuration that msm8996 does, so we can reuse > the phy_cfg from there with just a single change > (se clock scheme). > > Signed-off-by: Konrad Dybcio > Signed-off-by: AngeloGioacchino Del Regno > --- > Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml | 1 + > drivers/phy/qualcomm/phy-qcom-qusb2.c | 7 ++- > 2 files changed, 7 insertions(+), 1 deletion(-)
Re: [PATCH -next] pinctrl: mediatek: simplify the return expression of mtk_pinconf_bias_disable_set_rev1()
在 2020/9/30 16:53, Linus Walleij 写道: On Mon, Sep 21, 2020 at 3:10 PM Qinglang Miao wrote: Simplify the return expression. Signed-off-by: Qinglang Miao This patch does not apply to the pinctrl "devel" branch, please rebase and resend, include Sean's ACK. https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=devel Yours, Linus Walleij . Hi Linus, I tried to rebase this patch to the pinctrl "devel" branch but there's no conflict. Could you please try again or show me some details? Thanks.
Re: [RESEND PATCH 2/2] mtd: spi-nor: enable lock interface for macronix chips
Hi,
On 9/21/20 4:54 PM, Ivan Mikhaylov wrote:
> Add locks for whole macronix chip series with BP0-2 and BP0-3 bits.
>
> Tested with mx25l51245g(BP0-3).
Since you have only tested on flash that have 4bit BP, please don't
modify flashes that have 3bit BP. Lets be conservative and enable only
things that have been tested else we may end up with broken feature from
day 1.
Regards
Vignesh
>
> Signed-off-by: Ivan Mikhaylov
> ---
> drivers/mtd/spi-nor/macronix.c | 75 ++
> 1 file changed, 50 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
> index 96735d83c77c..80de43eb05d6 100644
> --- a/drivers/mtd/spi-nor/macronix.c
> +++ b/drivers/mtd/spi-nor/macronix.c
> @@ -37,53 +37,78 @@ static const struct flash_info macronix_parts[] = {
> /* Macronix */
> { "mx25l512e", INFO(0xc22010, 0, 64 * 1024, 1, SECT_4K) },
> { "mx25l2005a", INFO(0xc22012, 0, 64 * 1024, 4, SECT_4K) },
> - { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8, SECT_4K) },
> - { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16, 0) },
> - { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32, SECT_4K) },
> - { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64, SECT_4K) },
> - { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64, SECT_4K) },
> - { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128, SECT_4K) },
> - { "mx25u2033e", INFO(0xc22532, 0, 64 * 1024, 4, SECT_4K) },
> + { "mx25l4005a", INFO(0xc22013, 0, 64 * 1024, 8,
> + SECT_4K | SPI_NOR_HAS_LOCK) },
> + { "mx25l8005", INFO(0xc22014, 0, 64 * 1024, 16,
> + SPI_NOR_HAS_LOCK) },
> + { "mx25l1606e", INFO(0xc22015, 0, 64 * 1024, 32,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l3205d", INFO(0xc22016, 0, 64 * 1024, 64,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l3255e", INFO(0xc29e16, 0, 64 * 1024, 64,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l6405d", INFO(0xc22017, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25u2033e", INFO(0xc22532, 0, 64 * 1024, 4,
> + SECT_4K | SPI_NOR_HAS_LOCK) },
> { "mx25u3235f", INFO(0xc22536, 0, 64 * 1024, 64,
> SECT_4K | SPI_NOR_DUAL_READ |
> - SPI_NOR_QUAD_READ) },
> - { "mx25u4035", INFO(0xc22533, 0, 64 * 1024, 8, SECT_4K) },
> - { "mx25u8035", INFO(0xc22534, 0, 64 * 1024, 16, SECT_4K) },
> - { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128, SECT_4K) },
> - { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256, 0) },
> - { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256, 0) },
> + SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
> + { "mx25u4035", INFO(0xc22533, 0, 64 * 1024, 8,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25u8035", INFO(0xc22534, 0, 64 * 1024, 16,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25u6435f", INFO(0xc22537, 0, 64 * 1024, 128,
> + SECT_4K | SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l12805d", INFO(0xc22018, 0, 64 * 1024, 256,
> + SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> + { "mx25l12855e", INFO(0xc22618, 0, 64 * 1024, 256,
> + SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP) },
> { "mx25r3235f", INFO(0xc22816, 0, 64 * 1024, 64,
> SECT_4K | SPI_NOR_DUAL_READ |
> - SPI_NOR_QUAD_READ) },
> + SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
> { "mx25u12835f", INFO(0xc22538, 0, 64 * 1024, 256,
> SECT_4K | SPI_NOR_DUAL_READ |
> - SPI_NOR_QUAD_READ) },
> + SPI_NOR_QUAD_READ | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
> { "mx25l25635e", INFO(0xc22019, 0, 64 * 1024, 512,
> - SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ)
> + SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
> + SPI_NOR_HAS_LOCK | SPI_NOR_4BIT_BP)
> .fixups = &mx25l25635_fixups },
> { "mx25u25635f", INFO(0xc22539, 0, 64 * 1024, 512,
> - SECT_4K | SPI_NOR_4B_OPCODES) },
> + SECT_4K | SPI_NOR_4B_OPCODES | SPI_NOR_HAS_LOCK |
> + SPI_NOR_4BIT_BP) },
> { "mx25u51245g", INFO(0xc2253a, 0, 64 * 1024, 1024,
> SECT_4K | SPI_NOR_DUAL_READ |
> - SPI_NOR
Re: [PATCH v2 1/2] dt-bindings: gpio: pca953x: Add support for the NXP PCAL9554B/C
On Wed, Sep 30, 2020 at 11:21 AM Mike Looijmans wrote: > > The NXP PCAL9554B is a variant of the PCA953x GPIO expander, > with 8 GPIOs, latched interrupts and some advanced configuration > options. The "C" version only differs in I2C address. > > This adds the entry to the devicetree bindings. > > Signed-off-by: Mike Looijmans > --- > v2: Split devicetree and code into separate patches > > Documentation/devicetree/bindings/gpio/gpio-pca953x.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > index 3126c3817e2a..99dc1936f633 100644 > --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt > @@ -20,6 +20,7 @@ Required properties: > nxp,pcal6416 > nxp,pcal6524 > nxp,pcal9535 > + nxp,pcal9554b > nxp,pcal9555a > maxim,max7310 > maxim,max7312 > -- > 2.17.1 > Reviewed-by: Bartosz Golaszewski
Re: [PATCH v2 2/2] gpio: pca953x: Add support for the NXP PCAL9554B/C
On Wed, Sep 30, 2020 at 11:21 AM Mike Looijmans wrote: > > The NXP PCAL9554B is a variant of the PCA953x GPIO expander, > with 8 GPIOs, latched interrupts and some advanced configuration > options. The "C" version only differs in I2C address. > > Signed-off-by: Mike Looijmans > --- Reviewed-by: Bartosz Golaszewski I'll let Linus pick it up, I already sent my final PR for v5.10. Bartosz
Re: [PATCH v2] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2
On Sat, Sep 19, 2020 at 10:10 PM Drew Fustini wrote:
> Document the values in pinctrl-single,pins when #pinctrl-cells = <2>
>
> Fixes: 27c90e5e48d0 ("ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2")
> Reported-by: Trent Piepho
> Link: https://lore.kernel.org/linux-omap/3139716.CMS8C0sQ7x@zen.local/
> Signed-off-by: Drew Fustini
> ---
> v2 change:
> - rephrase to make it clear that the pin conf value and pin mux value
> are OR'd together with #pinctrl-cells = <2>
Patch applied with the ACKs.
Thanks for fixing this!
Yours,
Linus Walleij
Re: [PATCH] pwm: sysfs: Set class on pwm devices
Hello, I added Greg Kroah-Hartman who I discussed this with via irc a bit to Cc:. On Wed, Sep 30, 2020 at 11:20:56AM +0200, Lars Poeschel wrote: > thank you for your review! > > On Wed, Sep 30, 2020 at 08:57:26AM +0200, Uwe Kleine-König wrote: > > On Tue, Sep 29, 2020 at 02:19:53PM +0200, poesc...@lemonage.de wrote: > > > From: Lars Poeschel > > > > > > This adds a class to exported pwm devices. > > > Exporting a pwm through sysfs did not yield udev events. The > > > > I wonder what is your use-case here. This for sure also has a place to > > be mentioned in the commit log. I suspect there is a better way to > > accomplish you way. > > Use-case is to be able to use a pwm from a non-root userspace process. > I use udev rules to adjust permissions. Hmm, how do you trigger the export? Without being aware of all the details in the sysfs code I would expect that the exported stuff is available instantly once the write used to export the PWM is completed. So changing the permissions can be done directly after triggering the export in the same process. Out of interest: What do you use the pwm for? Isn't there a suitable kernel driver that can do the required stuff? Compared to the kernel-API the sysfs interface isn't atomic. Is this an annoyance? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
[PATCH v3 0/2] Add support for F3A
RMI4 F3A supports the touchpad GPIO function, it's designed to support more GPIOs and used on newer touchpads. The patches add support of touchpad buttons and rename f30_data to avoid confusion. Changes in v2: - Combined patch 1 and 2 of v1 to fix bisectability. Changes in v3: - Fix indentations pointed out by Lyude Paul. Vincent Huang (2): Input: synaptics-rmi4 - rename f30_data to gpio_data Input: synaptics-rmi4 - add support for F3A drivers/hid/hid-rmi.c | 2 +- drivers/input/mouse/synaptics.c | 2 +- drivers/input/rmi4/Kconfig | 8 ++ drivers/input/rmi4/Makefile | 1 + drivers/input/rmi4/rmi_bus.c| 3 + drivers/input/rmi4/rmi_driver.h | 1 + drivers/input/rmi4/rmi_f30.c| 14 +- drivers/input/rmi4/rmi_f3a.c| 240 include/linux/rmi.h | 11 +- 9 files changed, 268 insertions(+), 14 deletions(-) create mode 100644 drivers/input/rmi4/rmi_f3a.c -- 2.25.1
[PATCH v3 2/2] Input: synaptics-rmi4 - add support for F3A
RMI4 F3A supports the touchpad GPIO function, it's designed to
support more GPIOs and used on newer touchpads. This patch adds
support of the touchpad buttons.
Signed-off-by: Vincent Huang
Reviewed-by: Hans de Goede
Tested-by: Hans de Goede
---
drivers/input/rmi4/Kconfig | 8 ++
drivers/input/rmi4/Makefile | 1 +
drivers/input/rmi4/rmi_bus.c| 3 +
drivers/input/rmi4/rmi_driver.h | 1 +
drivers/input/rmi4/rmi_f3a.c| 240
5 files changed, 253 insertions(+)
create mode 100644 drivers/input/rmi4/rmi_f3a.c
diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index a212ff706f74..16119f760d11 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -100,6 +100,14 @@ config RMI4_F34
device via the firmware loader interface. This is triggered using a
sysfs attribute.
+config RMI4_F3A
+ bool "RMI4 Function 3A (GPIO)"
+ help
+ Say Y here if you want to add support for RMI4 function 3A.
+
+ Function 3A provides GPIO support for RMI4 devices. This includes
+ support for buttons on TouchPads and ClickPads.
+
config RMI4_F54
bool "RMI4 Function 54 (Analog diagnostics)"
depends on VIDEO_V4L2=y || (RMI4_CORE=m && VIDEO_V4L2=m)
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index f17631656987..02f14c846861 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -10,6 +10,7 @@ rmi_core-$(CONFIG_RMI4_F11) += rmi_f11.o
rmi_core-$(CONFIG_RMI4_F12) += rmi_f12.o
rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
rmi_core-$(CONFIG_RMI4_F34) += rmi_f34.o rmi_f34v7.o
+rmi_core-$(CONFIG_RMI4_F3A) += rmi_f3a.o
rmi_core-$(CONFIG_RMI4_F54) += rmi_f54.o
rmi_core-$(CONFIG_RMI4_F55) += rmi_f55.o
diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
index af706a583656..47d1b97ed6cf 100644
--- a/drivers/input/rmi4/rmi_bus.c
+++ b/drivers/input/rmi4/rmi_bus.c
@@ -365,6 +365,9 @@ static struct rmi_function_handler *fn_handlers[] = {
#ifdef CONFIG_RMI4_F34
&rmi_f34_handler,
#endif
+#ifdef CONFIG_RMI4_F3A
+ &rmi_f3a_handler,
+#endif
#ifdef CONFIG_RMI4_F54
&rmi_f54_handler,
#endif
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index 65bfaa95e193..1c6c6086c0e5 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -135,6 +135,7 @@ extern struct rmi_function_handler rmi_f11_handler;
extern struct rmi_function_handler rmi_f12_handler;
extern struct rmi_function_handler rmi_f30_handler;
extern struct rmi_function_handler rmi_f34_handler;
+extern struct rmi_function_handler rmi_f3a_handler;
extern struct rmi_function_handler rmi_f54_handler;
extern struct rmi_function_handler rmi_f55_handler;
#endif
diff --git a/drivers/input/rmi4/rmi_f3a.c b/drivers/input/rmi4/rmi_f3a.c
new file mode 100644
index ..11ff35f811b0
--- /dev/null
+++ b/drivers/input/rmi4/rmi_f3a.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2012-2020 Synaptics Incorporated
+ */
+
+#include
+#include
+#include
+#include
+#include "rmi_driver.h"
+
+#define RMI_F3A_MAX_GPIO_COUNT 128
+#define RMI_F3A_MAX_REG_SIZE DIV_ROUND_UP(RMI_F3A_MAX_GPIO_COUNT, 8)
+
+/* Defs for Query 0 */
+#define RMI_F3A_GPIO_COUNT 0x7F
+
+#define RMI_F3A_DATA_REGS_MAX_SIZE RMI_F3A_MAX_REG_SIZE
+
+#define TRACKSTICK_RANGE_START 3
+#define TRACKSTICK_RANGE_END 6
+
+struct f3a_data {
+ /* Query Data */
+ u8 gpio_count;
+
+ u8 register_count;
+
+ u8 data_regs[RMI_F3A_DATA_REGS_MAX_SIZE];
+ u16 *gpio_key_map;
+
+ struct input_dev *input;
+
+ struct rmi_function *f03;
+ bool trackstick_buttons;
+};
+
+static void rmi_f3a_report_button(struct rmi_function *fn,
+ struct f3a_data *f3a, unsigned int button)
+{
+ u16 key_code = f3a->gpio_key_map[button];
+ bool key_down = !(f3a->data_regs[0] & BIT(button));
+
+ if (f3a->trackstick_buttons &&
+ button >= TRACKSTICK_RANGE_START &&
+ button <= TRACKSTICK_RANGE_END) {
+ rmi_f03_overwrite_button(f3a->f03, key_code, key_down);
+ } else {
+ rmi_dbg(RMI_DEBUG_FN, &fn->dev,
+ "%s: call input report key (0x%04x) value (0x%02x)",
+ __func__, key_code, key_down);
+ input_report_key(f3a->input, key_code, key_down);
+ }
+}
+
+static irqreturn_t rmi_f3a_attention(int irq, void *ctx)
+{
+ struct rmi_function *fn = ctx;
+ struct f3a_data *f3a = dev_get_drvdata(&fn->dev);
+ struct rmi_driver_data *drvdata = dev_get_drvdata(&fn->rmi_dev->dev);
+ int error;
+ int i;
+
+ if (drvdata->attn_data.data) {
+ if (drvdata->attn_data.size < f3a->register_count) {
+ dev_warn(&fn->dev,
+
Re: [PATCH v2 2/2] regulator: rtmv20: Add DT-binding document for Richtek RTMV20
On Wed, Sep 30, 2020 at 10:23:49AM +0800, ChiYuan Huang wrote: >Due to that already merged into your regulator for-next git, may I > send the patch to fix Rob's comment? Of course, yes please. > And I also found one line need to be added into rtmv20 probe phase. > Please check below. > /* > * keep in shutdown mode to minimize the current consumption > * and also mark regcache as dirty > */ > + regcache_cache_only(priv->regmap, true); > regcache_mark_dirty(priv->regmap); > gpiod_set_value(priv->enable_gpio, 0); > > Can I directly merge into one that includes Rob's comment and the > above line to be added? Please make it a separate patch. signature.asc Description: PGP signature
[PATCH v3 1/2] Input: synaptics-rmi4 - rename f30_data to gpio_data
f30_data in rmi_device_platform_data could be also referenced by RMI
function 3A, so rename it and the structure name to avoid confusion.
Signed-off-by: Vincent Huang
Reviewed-by: Hans de Goede
Tested-by: Hans de Goede
---
drivers/hid/hid-rmi.c | 2 +-
drivers/input/mouse/synaptics.c | 2 +-
drivers/input/rmi4/rmi_f30.c| 14 +++---
include/linux/rmi.h | 11 ++-
4 files changed, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c
index 9ce22acdfaca..62315e31d520 100644
--- a/drivers/hid/hid-rmi.c
+++ b/drivers/hid/hid-rmi.c
@@ -722,7 +722,7 @@ static int rmi_probe(struct hid_device *hdev, const struct
hid_device_id *id)
}
if (data->device_flags & RMI_DEVICE_HAS_PHYS_BUTTONS)
- rmi_hid_pdata.f30_data.disable = true;
+ rmi_hid_pdata.gpio_data.disable = true;
data->xport.dev = hdev->dev.parent;
data->xport.pdata = rmi_hid_pdata;
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index 4b81b2d0fe06..8a54efd6eb95 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1752,7 +1752,7 @@ static int synaptics_create_intertouch(struct psmouse
*psmouse,
.kernel_tracking = false,
.topbuttonpad = topbuttonpad,
},
- .f30_data = {
+ .gpio_data = {
.buttonpad = SYN_CAP_CLICKPAD(info->ext_cap_0c),
.trackstick_buttons =
!!SYN_CAP_EXT_BUTTONS_STICK(info->ext_cap_10),
diff --git a/drivers/input/rmi4/rmi_f30.c b/drivers/input/rmi4/rmi_f30.c
index a90dad1d9ac7..35045f161dc2 100644
--- a/drivers/input/rmi4/rmi_f30.c
+++ b/drivers/input/rmi4/rmi_f30.c
@@ -168,17 +168,17 @@ static int rmi_f30_config(struct rmi_function *fn)
rmi_get_platform_data(fn->rmi_dev);
int error;
- /* can happen if f30_data.disable is set */
+ /* can happen if gpio_data.disable is set */
if (!f30)
return 0;
- if (pdata->f30_data.trackstick_buttons) {
+ if (pdata->gpio_data.trackstick_buttons) {
/* Try [re-]establish link to F03. */
f30->f03 = rmi_find_function(fn->rmi_dev, 0x03);
f30->trackstick_buttons = f30->f03 != NULL;
}
- if (pdata->f30_data.disable) {
+ if (pdata->gpio_data.disable) {
drv->clear_irq_bits(fn->rmi_dev, fn->irq_mask);
} else {
/* Write Control Register values back to device */
@@ -245,10 +245,10 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
if (!rmi_f30_is_valid_button(i, f30->ctrl))
continue;
- if (pdata->f30_data.trackstick_buttons &&
+ if (pdata->gpio_data.trackstick_buttons &&
i >= TRACKSTICK_RANGE_START && i < TRACKSTICK_RANGE_END) {
f30->gpioled_key_map[i] = trackstick_button++;
- } else if (!pdata->f30_data.buttonpad || !button_mapped) {
+ } else if (!pdata->gpio_data.buttonpad || !button_mapped) {
f30->gpioled_key_map[i] = button;
input_set_capability(input, EV_KEY, button++);
button_mapped = true;
@@ -264,7 +264,7 @@ static int rmi_f30_map_gpios(struct rmi_function *fn,
* but I am not sure, so use only the pdata info and the number of
* mapped buttons.
*/
- if (pdata->f30_data.buttonpad || (button - BTN_LEFT == 1))
+ if (pdata->gpio_data.buttonpad || (button - BTN_LEFT == 1))
__set_bit(INPUT_PROP_BUTTONPAD, input->propbit);
return 0;
@@ -372,7 +372,7 @@ static int rmi_f30_probe(struct rmi_function *fn)
struct f30_data *f30;
int error;
- if (pdata->f30_data.disable)
+ if (pdata->gpio_data.disable)
return 0;
if (!drv_data->input) {
diff --git a/include/linux/rmi.h b/include/linux/rmi.h
index 7b22366d0065..00dda5381bf8 100644
--- a/include/linux/rmi.h
+++ b/include/linux/rmi.h
@@ -102,15 +102,16 @@ struct rmi_2d_sensor_platform_data {
};
/**
- * struct rmi_f30_data - overrides defaults for a single F30 GPIOs/LED chip.
+ * struct rmi_gpio_data - overrides defaults for a single F30/F3A GPIOs/LED
+ * chip.
* @buttonpad - the touchpad is a buttonpad, so enable only the first actual
* button that is found.
- * @trackstick_buttons - Set when the function 30 is handling the physical
+ * @trackstick_buttons - Set when the function 30 or 3a is handling the
physical
* buttons of the trackstick (as a PS/2 passthrough device).
- * @disable - the touchpad incorrectly reports F30 and it should be ignored.
+ * @disable - the touchpad incorrectly reports F30/F3A and it should be
ignored.
* This is a special case whi
Re: [PATCH next v2 1/2] printk: avoid and/or handle record truncation
On (20/09/30 11:07), John Ogness wrote:
[..]
> @@ -1389,6 +1391,9 @@ bool prb_reserve_in_last(struct prb_reserved_entry *e,
> struct printk_ringbuffer
> if (!data_check_size(&rb->text_data_ring, r->text_buf_size))
> goto fail;
>
> + if (r->text_buf_size > max_size)
> + goto fail;
> +
> r->text_buf = data_alloc(rb, &rb->text_data_ring,
> r->text_buf_size,
>&d->text_blk_lpos, id);
> } else {
> @@ -1410,6 +1415,9 @@ bool prb_reserve_in_last(struct prb_reserved_entry *e,
> struct printk_ringbuffer
> if (!data_check_size(&rb->text_data_ring, r->text_buf_size))
> goto fail;
>
> + if (r->text_buf_size > max_size)
> + goto fail;
> +
> r->text_buf = data_realloc(rb, &rb->text_data_ring,
> r->text_buf_size,
> &d->text_blk_lpos, id);
> }
[..]
> bool prb_reserve_in_last(struct prb_reserved_entry *e, struct
> printk_ringbuffer *rb,
> - struct printk_record *r, u32 caller_id);
> + struct printk_record *r, u32 caller_id, unsigned int
> max_size);
Isn't `max_size' always LOG_LINE_MAX?
-ss
Re: Removal of HCI commands, userspace bluetooth regression?
On Wednesday 30 September 2020 11:20:43 Greg Kroah-Hartman wrote: > On Wed, Sep 30, 2020 at 10:25:34AM +0200, Pali Rohár wrote: > > On Wednesday 30 September 2020 10:02:05 Greg Kroah-Hartman wrote: > > > On Tue, Sep 29, 2020 at 11:32:54PM +0200, Pali Rohár wrote: > > > > CCing other lists and maintainers, hopefully, somebody would have a > > > > time to look at it... > > > > > > > > On Saturday 08 August 2020 15:27:47 Pali Rohár wrote: > > > > > On Wednesday 15 April 2020 00:56:18 Pali Rohár wrote: > > > > > > On Sunday 09 February 2020 14:21:37 Pali Rohár wrote: > > > > > > > On Saturday 04 January 2020 11:24:36 Pali Rohár wrote: > > > > > > > > On Saturday 04 January 2020 10:44:52 Marcel Holtmann wrote: > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > > I wrote a simple script "sco_features.pl" which show all > > > > > > > > > > supported > > > > > > > > > > codecs by local HCI bluetooth adapter. Script is available > > > > > > > > > > at: > > > > > > > > > > > > > > > > > > > > https://github.com/pali/hsphfpd-prototype/blob/prototype/sco_features.pl > > > > > > > > > > > > > > > > > > > > And I found out that OCF_READ_LOCAL_CODECS HCI command > > > > > > > > > > cannot be send by > > > > > > > > > > non-root user. Kernel returns "Operation not permitted" > > > > > > > > > > error. > > > > > > > > > > > > > > > > > > > > What is reason that kernel blocks OCF_READ_LOCAL_CODECS > > > > > > > > > > command for > > > > > > > > > > non-root users? Without it (audio) application does not > > > > > > > > > > know which > > > > > > > > > > codecs local bluetooth adapter supports. > > > > > > > > > > > > > > > > > > > > E.g. OCF_READ_LOCAL_EXT_FEATURES or OCF_READ_VOICE_SETTING > > > > > > > > > > commands can > > > > > > > > > > be send also by non-root user and kernel does not block > > > > > > > > > > them. > > > > > > > > > > > > > > > > > > actually the direct access to HCI commands is being removed. > > > > > > > > > So we have no plans to add new commands into the list since > > > > > > > > > that it what the kernel is suppose to handle. If we wanted to > > > > > > > > > expose this, then it has to be via mgmt. > > > > > > > > > > > > > > > > Hi Marcel! Thank you for information. I have not know that this > > > > > > > > API is > > > > > > > > "deprecated" and is going to be removed. But userspace audio > > > > > > > > applications need to know what bluetooth adapter supports, so > > > > > > > > can you > > > > > > > > export result of these commands to userspace? My script linked > > > > > > > > above > > > > > > > > calls: OCF_READ_VOICE_SETTING, OCF_READ_LOCAL_COMMANDS, > > > > > > > > OCF_READ_LOCAL_EXT_FEATURES, OCF_READ_LOCAL_CODECS > > > > > > > > > > > > > > Hello! Just a gently reminder for this question. How to retrieve > > > > > > > information about supported codecs from userspace by non-root > > > > > > > user? > > > > > > > Because running all bluetooth audio applications by root is not > > > > > > > really a > > > > > > > solution. Plus if above API for root user is going to be removed, > > > > > > > what > > > > > > > is a replacement? > > > > > > > > > > > > Hello! > > > > > > > > > > > > I have not got any answer to my email from Marcel for months, so I'm > > > > > > adding other developers to loop. Could somebody tell me that is the > > > > > > replacement API if above one is going to be removed? > > > > > > > > > > > > I was not able to find any documentation where could be described > > > > > > this > > > > > > API nor information about deprecation / removal. > > > > > > > > > > > > And are you aware of the fact that removing of API could potentially > > > > > > break existing applications? > > > > > > > > > > > > I really need to know which API should I use, because when I use API > > > > > > which is going to be removed, then my application stops working. > > > > > > And I > > > > > > really want to avoid it. > > > > > > > > > > > > Also I have not got any response yet, how can I read list of > > > > > > supported > > > > > > codecs by bluetooth adapter by ordinary non-root user? Audio > > > > > > application > > > > > > needs to know list of supported codecs and it is really insane to > > > > > > run it > > > > > > as root. > > > > > > > > > > Hello! This is just another reminder that I have not got any reply to > > > > > this email. > > > > > > > > > > Does silence mean that audio applications are expected to work only > > > > > under root account and ordinary users are not able to use audio and > > > > > list > > > > > supported codecs? > > > > > > > > Hello! I have not got any reply for this issue for 10 months and if you > > > > are going to remove (or after these 10 months you already did it?) > > > > existing HCI API from kernel it would break existing and working > > > > userspace application. How do you want to handle such regressions? > > > > > > What git commit caused this regression? > > > > Hello! Marcel in Januar
Re: [PATCH v3 2/3] iommu/tegra-smmu: Rework .probe_device and .attach_dev
On Wed, Sep 30, 2020 at 11:21:14AM +0200, Krzysztof Kozlowski wrote:
> On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
> >
> > Previously the driver relies on bus_set_iommu() in .probe() to call
> > in .probe_device() function so each client can poll iommus property
> > in DTB to configure fwspec via tegra_smmu_configure(). According to
> > the comments in .probe(), this is a bit of a hack. And this doesn't
> > work for a client that doesn't exist in DTB, PCI device for example.
> >
> > Actually when a device/client gets probed, the of_iommu_configure()
> > will call in .probe_device() function again, with a prepared fwspec
> > from of_iommu_configure() that reads the SWGROUP id in DTB as we do
> > in tegra-smmu driver.
> >
> > Additionally, as a new helper devm_tegra_get_memory_controller() is
> > introduced, there's no need to poll the iommus property in order to
> > get mc->smmu pointers or SWGROUP id.
> >
> > This patch reworks .probe_device() and .attach_dev() by doing:
> > 1) Using fwspec to get swgroup id in .attach_dev/.dettach_dev()
> > 2) Removing DT polling code, tegra_smmu_find/tegra_smmu_configure()
> > 3) Calling devm_tegra_get_memory_controller() in .probe_device()
> > 4) Also dropping the hack in .probe() that's no longer needed.
> >
> > Signed-off-by: Nicolin Chen
> > ---
> >
> > Changelog
> > v2->v3
> > * Used devm_tegra_get_memory_controller() to get mc pointer
> > * Replaced IS_ERR_OR_NULL with IS_ERR in .probe_device()
> > v1->v2
> > * Replaced in .probe_device() tegra_smmu_find/tegra_smmu_configure()
> >with tegra_get_memory_controller call.
> > * Dropped the hack in tegra_smmu_probe().
> >
> > drivers/iommu/tegra-smmu.c | 144 ++---
> > 1 file changed, 36 insertions(+), 108 deletions(-)
> >
> > diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
> > index 6a3ecc334481..636dc3b89545 100644
> > --- a/drivers/iommu/tegra-smmu.c
> > +++ b/drivers/iommu/tegra-smmu.c
> > @@ -61,6 +61,8 @@ struct tegra_smmu_as {
> > u32 attr;
> > };
> >
> > +static const struct iommu_ops tegra_smmu_ops;
>
> I cannot find in this patch where this is assigned.
Because it's already set in probe():
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/iommu/tegra-smmu.c#n1162
And my PATCH-3 sets it for PCI bus also.
Thanks
Re: [PATCH] ARM: dts: document pinctrl-single,pins when #pinctrl-cells = 2
* Trent Piepho [200930 09:34]:
> On Wed, Sep 30, 2020 at 2:15 AM Tony Lindgren wrote:
> >
> > * Trent Piepho [200930 08:35]:
> > > The closest thing would be the generic pin config type bindings, which
> > > go in the pinctrl driver's nodes, and look like this:
> > > &am335x_pinmux {
> > > pinctrl_yoyo_reset: yoyogrp {
> > > pins = "foo";
> > > function = "gpio";
> > > bias-pull-up;
> > > };
> > > };
> >
> > There's a bit of a dtb size and boot time issue for adding properties
> > for each pin where that needs to be done for several hundred pins :)
>
> pins is list, multiple pins can be specified at once. Otherwise the
> property name would be "pin" and not "pins" There's also a groups
> property to refer to multiple pins at once, e.g.
>
> arch/mips/boot/dts/ingenic/ci20.dts-pins_mmc1: mmc1 {
> arch/mips/boot/dts/ingenic/ci20.dts-function = "mmc1";
> arch/mips/boot/dts/ingenic/ci20.dts:groups =
> "mmc1-1bit-d", "mmc1-4bit-d";
> arch/mips/boot/dts/ingenic/ci20.dts-bias-disable;
> arch/mips/boot/dts/ingenic/ci20.dts-};
>
> arch/mips/boot/dts/pic32/pic32mzda_sk.dts- user_leds_s0: user_leds_s0 {
> arch/mips/boot/dts/pic32/pic32mzda_sk.dts: pins = "H0", "H1",
> "H2";
> arch/mips/boot/dts/pic32/pic32mzda_sk.dts- output-low;
> arch/mips/boot/dts/pic32/pic32mzda_sk.dts- microchip,digital;
> arch/mips/boot/dts/pic32/pic32mzda_sk.dts- };
Right.
> > > Is "some additional property for specifying generic conf flags"
> > > different from the existing pinctrl-single,bias-pullup, etc.
> > > properties? Because splitting the data cell into two parts doesn't
> > > make any difference to those.
> >
> > So with an interrupt style binding with generic pinconf flags we can
> > leave out the parsing of multiple properties for each pin. Sure the
> > pin is only referenced by the controller like you pointed out but the
> > pinconf flags could be generic.
>
> Where do these flags go? In pinctrl-single,pins? Like:
>
> pinctrl-single,pins = ;
>
> But PIN_INPUT_PULLUP is a generic flag? Which is translated into the
> proper value by??
Yes that's what I was thinking, something like this with generic flags:
pinctrl-single,pins = ;
> Or are you talking about replacing the existing pinctrl-0,
> pinctrl-names properties with a totally different system that looks
> more like gpio and interrupt handles?
That would be even better :) Might be just too much to deal with..
In any case the parser code could already be generic if we had generic
flags based on #pinctrl-cells.
Regards,
Tony
Re: [PATCH v3 1/3] memory: tegra: Add devm_tegra_get_memory_controller()
On Wed, Sep 30, 2020 at 11:07:32AM +0200, Krzysztof Kozlowski wrote:
> "On Wed, 30 Sep 2020 at 10:48, Nicolin Chen wrote:
> >
> > From: Dmitry Osipenko
> >
> > Multiple Tegra drivers need to retrieve Memory Controller and hence there
> > is quite some duplication of the retrieval code among the drivers. Let's
> > add a new common helper for the retrieval of the MC.
> >
> > Signed-off-by: Dmitry Osipenko
> > Signed-off-by: Nicolin Chen
> > ---
> >
> > Changelog
> > v2->v3:
> > * Replaced with Dimtry's devm_tegra_get_memory_controller()
> > v1->v2:
> > * N/A
> >
> > drivers/memory/tegra/mc.c | 39 +++
> > include/soc/tegra/mc.h| 17 +
> > 2 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
> > index ec8403557ed4..dd691dc3738e 100644
> > --- a/drivers/memory/tegra/mc.c
> > +++ b/drivers/memory/tegra/mc.c
> > @@ -42,6 +42,45 @@ static const struct of_device_id tegra_mc_of_match[] = {
> > };
> > MODULE_DEVICE_TABLE(of, tegra_mc_of_match);
> >
> > +static void tegra_mc_devm_action_put_device(void *data)
>
> devm_tegra_memory_controller_put()
>
> > +{
> > + struct tegra_mc *mc = data;
> > +
> > + put_device(mc->dev);
> > +}
> > +
> > +struct tegra_mc *devm_tegra_get_memory_controller(struct device *dev)
>
> Usually 'get' is a suffix (e.g. clk, gpiod, iio, led), so:
> devm_tegra_memory_controller_get()
>
> > +{
> > + struct platform_device *pdev;
> > + struct device_node *np;
> > + struct tegra_mc *mc;
> > + int err;
> > +
> > + np = of_find_matching_node_and_match(NULL, tegra_mc_of_match, NULL);
> > + if (!np)
> > + return ERR_PTR(-ENOENT);
> > +
> > + pdev = of_find_device_by_node(np);
> > + of_node_put(np);
> > + if (!pdev)
> > + return ERR_PTR(-ENODEV);
> > +
> > + mc = platform_get_drvdata(pdev);
> > + if (!mc) {
> > + put_device(mc->dev);
> > + return ERR_PTR(-EPROBE_DEFER);
> > + }
> > +
> > + err = devm_add_action(dev, tegra_mc_devm_action_put_device, mc);
> > + if (err) {
> > + put_device(mc->dev);
> > + return ERR_PTR(err);
> > + }
> > +
> > + return mc;
> > +}
> > +EXPORT_SYMBOL_GPL(devm_tegra_get_memory_controller);
> > +
> > static int tegra_mc_block_dma_common(struct tegra_mc *mc,
> > const struct tegra_mc_reset *rst)
> > {
> > diff --git a/include/soc/tegra/mc.h b/include/soc/tegra/mc.h
> > index 1238e35653d1..c05142e3e244 100644
> > --- a/include/soc/tegra/mc.h
> > +++ b/include/soc/tegra/mc.h
> > @@ -184,4 +184,21 @@ struct tegra_mc {
> > int tegra_mc_write_emem_configuration(struct tegra_mc *mc, unsigned long
> > rate);
> > unsigned int tegra_mc_get_emem_device_count(struct tegra_mc *mc);
> >
> > +#ifdef CONFIG_TEGRA_MC
> > +/**
> > + * devm_tegra_get_memory_controller() - Get the tegra_mc pointer.
> > + * @dev: Device that will be interacted with
>
> This is not precise enough and there is no interaction with 'dev' in
> devm_tegra_get_memory_controller(). Something like: "Device that owns
> the pointer to tegra memory controller"
>
> > + *
> > + * Return: ERR_PTR() on error or a valid pointer to a struct tegra_mc.
> > + *
> > + * The mc->dev counter will be automatically put by the device management
> > code.
>
> 1. s/mc/tegra_mc/ (it's the first occurence of word mc here)
> 2. "kerneldoc goes to the C file". Not to the header.
I will send v4 after changing all of the places.
Thanks for the comments!
Re: [PATCH -next] pinctrl: mediatek: simplify the return expression of mtk_pinconf_bias_disable_set_rev1()
On Wed, Sep 30, 2020 at 11:39 AM miaoqinglang wrote: > I tried to rebase this patch to the pinctrl "devel" branch but there's > no conflict. Could you please try again or show me some details? If you used "git rebase" this might work for you because the git tree can do a more intelligent rebase than me. I only have the patches and they do not contain context. However I actually want to apply it on a clean v5.9-rc1 (that's what I actually tried, sorry for the confusion) but maybe it has some dependencies so that does not work? Yours, Linus Walleij
[RFC] net: phy: add shutdown hook to struct phy_driver
Hi, A GE phy supports pad isolation which can save power in WOL mode. But once the isolation is enabled, the MAC can't send/receive pkts to/from the phy because the phy is "isolated". To make the PHY work normally, I need to move the enabling isolation to suspend hook, so far so good. But the isolation isn't enabled in system shutdown case, to support this, I want to add shutdown hook to net phy_driver, then also enable the isolation in the shutdown hook. Is there any elegant solution? Or we can break the assumption: ethernet can still send/receive pkts after enabling WoL, no? Thanks in advance, Jisheng
Re: Removal of HCI commands, userspace bluetooth regression?
On Wednesday 30 September 2020 11:20:20 Greg Kroah-Hartman wrote: > On Wed, Sep 30, 2020 at 10:16:40AM +0200, Marcel Holtmann wrote: > > Hi Greg, > > > > I wrote a simple script "sco_features.pl" which show all supported > > codecs by local HCI bluetooth adapter. Script is available at: > > > > https://github.com/pali/hsphfpd-prototype/blob/prototype/sco_features.pl > > > > And I found out that OCF_READ_LOCAL_CODECS HCI command cannot be > > send by > > non-root user. Kernel returns "Operation not permitted" error. > > > > What is reason that kernel blocks OCF_READ_LOCAL_CODECS command for > > non-root users? Without it (audio) application does not know which > > codecs local bluetooth adapter supports. > > > > E.g. OCF_READ_LOCAL_EXT_FEATURES or OCF_READ_VOICE_SETTING > > commands can > > be send also by non-root user and kernel does not block them. > > >>> > > >>> actually the direct access to HCI commands is being removed. So we > > >>> have no plans to add new commands into the list since that it what > > >>> the kernel is suppose to handle. If we wanted to expose this, then > > >>> it has to be via mgmt. > > >> > > >> Hi Marcel! Thank you for information. I have not know that this API > > >> is > > >> "deprecated" and is going to be removed. But userspace audio > > >> applications need to know what bluetooth adapter supports, so can you > > >> export result of these commands to userspace? My script linked above > > >> calls: OCF_READ_VOICE_SETTING, OCF_READ_LOCAL_COMMANDS, > > >> OCF_READ_LOCAL_EXT_FEATURES, OCF_READ_LOCAL_CODECS > > > > > > Hello! Just a gently reminder for this question. How to retrieve > > > information about supported codecs from userspace by non-root user? > > > Because running all bluetooth audio applications by root is not > > > really a > > > solution. Plus if above API for root user is going to be removed, what > > > is a replacement? > > > > Hello! > > > > I have not got any answer to my email from Marcel for months, so I'm > > adding other developers to loop. Could somebody tell me that is the > > replacement API if above one is going to be removed? > > > > I was not able to find any documentation where could be described this > > API nor information about deprecation / removal. > > > > And are you aware of the fact that removing of API could potentially > > break existing applications? > > > > I really need to know which API should I use, because when I use API > > which is going to be removed, then my application stops working. And I > > really want to avoid it. > > > > Also I have not got any response yet, how can I read list of supported > > codecs by bluetooth adapter by ordinary non-root user? Audio > > application > > needs to know list of supported codecs and it is really insane to run > > it > > as root. > > >>> > > >>> Hello! This is just another reminder that I have not got any reply to > > >>> this email. > > >>> > > >>> Does silence mean that audio applications are expected to work only > > >>> under root account and ordinary users are not able to use audio and list > > >>> supported codecs? > > >> > > >> Hello! I have not got any reply for this issue for 10 months and if you > > >> are going to remove (or after these 10 months you already did it?) > > >> existing HCI API from kernel it would break existing and working > > >> userspace application. How do you want to handle such regressions? > > > > > > What git commit caused this regression? > > > > there is no regression! > > > > New Bluetooth standards added new HCI commands that are just not > > exposed to unprivileged users. > > Ok, that makes sense. What tool takes advantage of these new HCI > commands? sco_features as written above (in quoted part). And today also main daemon in that repository. > thanks, > > greg k-h
Re: lockdep null-ptr-deref
On Wed, Sep 30, 2020 at 11:16:11AM +0200, Peter Zijlstra wrote:
> On Wed, Sep 30, 2020 at 07:08:23AM +0800, Boqun Feng wrote:
> > I think there are two problems here:
> >
> > 1) the "(null)" means we don't have the "usage_str" for a usage bit,
> > which I think is the LOCK_USED_READ bit introduced by Peter at
> > 23870f122768 ('locking/lockdep: Fix "USED" <- "IN-NMI" inversions').
> >
> > 2) the next null-ptr-deref, and I think this is also caused by
> > LOCK_USED_READ bit, because in the loop inside
> > print_lock_class_header(), we iterate from 0 to LOCK_USAGE_STATES (which
> > is 4*2 + 3), however the class->usage_traces[] only has
> > XXX_LOCK_USAGE_STATES (which is 4*2 + 1) elements, so if we have
> > LOCK_USED_READ bit set in ->usage_mask, we will try to access an element
> > out of the ->usage_traces[] array.
> >
> > Probably the following helps? And another possible fix is to enlarge the
> > ->usage_trace[] array and record the call trace of LOCK_READ_USED.
>
> Urgh.. yeah, I wanted to avoid saving that trace; it's pretty useless :/
> The existing USED trace is already mostly pointless, the consistent
> thing would be to remove both but that might be too radical.
>
> But you're right in that I made a right mess of it. Not sure what's
> best here.
>
> Let me have a play.
How's something like this? It's bigger than I'd like, but I feel the
result is more consistent/readable.
---
diff --git a/include/linux/lockdep_types.h b/include/linux/lockdep_types.h
index bb35b449f533..a55b1d314ae8 100644
--- a/include/linux/lockdep_types.h
+++ b/include/linux/lockdep_types.h
@@ -35,8 +35,12 @@ enum lockdep_wait_type {
/*
* We'd rather not expose kernel/lockdep_states.h this wide, but we do need
* the total number of states... :-(
+ *
+ * XXX_LOCK_USAGE_STATES is the number of lines in lockdep_states.h, for each
+ * of those we generates 4 states, Additionally we (for now) report on USED.
*/
-#define XXX_LOCK_USAGE_STATES (1+2*4)
+#define XXX_LOCK_USAGE_STATES 2
+#define LOCK_TRACE_STATES (XXX_LOCK_USAGE_STATES*4 + 1)
/*
* NR_LOCKDEP_CACHING_CLASSES ... Number of classes
@@ -106,7 +110,7 @@ struct lock_class {
* IRQ/softirq usage tracking bits:
*/
unsigned long usage_mask;
- const struct lock_trace *usage_traces[XXX_LOCK_USAGE_STATES];
+ const struct lock_trace *usage_traces[LOCK_TRACE_STATES];
/*
* Generation counter, when doing certain classes of graph walking,
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 454355c033d2..4f98ac8b4575 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -600,6 +600,8 @@ static const char *usage_str[] =
#include "lockdep_states.h"
#undef LOCKDEP_STATE
[LOCK_USED] = "INITIAL USE",
+ [LOCK_USED_READ] = "INITIAL READ USE",
+ /* abused as string storage for verify_lock_unused() */
[LOCK_USAGE_STATES] = "IN-NMI",
};
#endif
@@ -2231,7 +2233,7 @@ static void print_lock_class_header(struct lock_class
*class, int depth)
#endif
printk(KERN_CONT " {\n");
- for (bit = 0; bit < LOCK_USAGE_STATES; bit++) {
+ for (bit = 0; bit < LOCK_TRACE_STATES; bit++) {
if (class->usage_mask & (1 << bit)) {
int len = depth;
@@ -4354,27 +4356,24 @@ static int mark_lock(struct task_struct *curr, struct
held_lock *this,
old_mask = hlock_class(this)->usage_mask;
hlock_class(this)->usage_mask |= new_mask;
- /*
-* Save one usage_traces[] entry and map both LOCK_USED and
-* LOCK_USED_READ onto the same entry.
-*/
- if (new_bit == LOCK_USED || new_bit == LOCK_USED_READ) {
- if (old_mask & (LOCKF_USED | LOCKF_USED_READ))
- goto unlock;
- new_bit = LOCK_USED;
+ if (new_bit < LOCK_TRACE_STATES) {
+ if (!(hlock_class(this)->usage_traces[new_bit] = save_trace()))
+ return 0;
}
- if (!(hlock_class(this)->usage_traces[new_bit] = save_trace()))
- return 0;
-
switch (new_bit) {
+ case 0 ... LOCK_USED-1:
+ ret = mark_lock_irq(curr, this, new_bit);
+ if (!ret)
+ return 0;
+ break;
+
case LOCK_USED:
debug_atomic_dec(nr_unused_locks);
break;
+
default:
- ret = mark_lock_irq(curr, this, new_bit);
- if (!ret)
- return 0;
+ break;
}
unlock:
diff --git a/kernel/locking/lockdep_internals.h
b/kernel/locking/lockdep_internals.h
index b0be1560ed17..67dc46e46552 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -20,9 +20,12 @@ enum lock_usage_bit {
#undef LOCKDEP_STATE
LOCK_USED,
LOCK_USED_READ,
- LOCK_USAGE_STATES
+ LO
Re: [PATCH v2 1/2] dt-bindings: gpio: pca953x: Add support for the NXP PCAL9554B/C
On Wed, Sep 30, 2020 at 11:21 AM Mike Looijmans wrote: > The NXP PCAL9554B is a variant of the PCA953x GPIO expander, > with 8 GPIOs, latched interrupts and some advanced configuration > options. The "C" version only differs in I2C address. > > This adds the entry to the devicetree bindings. > > Signed-off-by: Mike Looijmans > --- > v2: Split devicetree and code into separate patches Reviewed-by: Linus Walleij This patch 1/2 does not apply to my tree, I suppose Rob has to apply it? I will try to apply 2/2. Yours, Linus Walleij
Re: [PATCH v2 2/2] gpio: pca953x: Add support for the NXP PCAL9554B/C
On Wed, Sep 30, 2020 at 11:21 AM Mike Looijmans wrote: > The NXP PCAL9554B is a variant of the PCA953x GPIO expander, > with 8 GPIOs, latched interrupts and some advanced configuration > options. The "C" version only differs in I2C address. > > Signed-off-by: Mike Looijmans > --- > v2: Split devicetree and code into separate patches Patch applied. Yours, Linus Walleij
Re: [PATCH] pwm: sysfs: Set class on pwm devices
On Wed, Sep 30, 2020 at 11:41:46AM +0200, Uwe Kleine-König wrote: > Hello, > > I added Greg Kroah-Hartman who I discussed this with via irc a bit to > Cc:. > > On Wed, Sep 30, 2020 at 11:20:56AM +0200, Lars Poeschel wrote: > > thank you for your review! > > > > On Wed, Sep 30, 2020 at 08:57:26AM +0200, Uwe Kleine-König wrote: > > > On Tue, Sep 29, 2020 at 02:19:53PM +0200, poesc...@lemonage.de wrote: > > > > From: Lars Poeschel > > > > > > > > This adds a class to exported pwm devices. > > > > Exporting a pwm through sysfs did not yield udev events. The > > > > > > I wonder what is your use-case here. This for sure also has a place to > > > be mentioned in the commit log. I suspect there is a better way to > > > accomplish you way. > > > > Use-case is to be able to use a pwm from a non-root userspace process. > > I use udev rules to adjust permissions. > > Hmm, how do you trigger the export? Without being aware of all the > details in the sysfs code I would expect that the exported stuff is > available instantly once the write used to export the PWM is completed. > So changing the permissions can be done directly after triggering the > export in the same process. It looks like userspace wants to see when a pwmX device shows up, right? And it's not because those devices do not belong to any class or bus, so they are just "floating" out there (they might show up under /sys/bus/virtual, if you set things up right, which I don't think is happening here...) So yes, you need to create a class, or assign this to a bus, which is fine, but it looks like no one is doing that. Don't create new classes dynamically, but rather, just assign this to the existing pwm class. What's wrong with that? I saw an older patch that did that, what did that break? thanks, greg k-h
Re: [PATCH rdma-next v4 4/4] RDMA/umem: Move to allocate SG table from pages
On Tue, Sep 29, 2020 at 04:59:29PM -0300, Jason Gunthorpe wrote:
> On Sun, Sep 27, 2020 at 09:46:47AM +0300, Leon Romanovsky wrote:
> > @@ -296,11 +223,17 @@ static struct ib_umem *__ib_umem_get(struct ib_device
> > *device,
> > goto umem_release;
> >
> > cur_base += ret * PAGE_SIZE;
> > - npages -= ret;
> > -
> > - sg = ib_umem_add_sg_table(sg, page_list, ret,
> > - dma_get_max_seg_size(device->dma_device),
> > - &umem->sg_nents);
> > + npages -= ret;
> > + sg = __sg_alloc_table_from_pages(
> > + &umem->sg_head, page_list, ret, 0, ret << PAGE_SHIFT,
> > + dma_get_max_seg_size(device->dma_device), sg, npages,
> > + GFP_KERNEL);
> > + umem->sg_nents = umem->sg_head.nents;
> > + if (IS_ERR(sg)) {
> > + unpin_user_pages_dirty_lock(page_list, ret, 0);
> > + ret = PTR_ERR(sg);
> > + goto umem_release;
> > + }
> > }
> >
> > sg_mark_end(sg);
>
> Does it still need the sg_mark_end?
It is preserved here for correctness, the release logic doesn't rely on
this marker, but it is better to leave it.
Thanks
>
> Jason
Re: [PATCH 0/3] Prevent out-of-bounds access for built-in font data buffers
On Wed, Sep 30, 2020 at 03:11:51AM -0400, Peilin Ye wrote:
> On Tue, Sep 29, 2020 at 04:38:49PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 29, 2020 at 2:34 PM Peilin Ye wrote:
> > > It seems that users don't use `console_font` directly, they use
> > > `console_font_op`. Then, in TTY:
> >
> > Wow, this is a maze :-/
> >
> > > (drivers/tty/vt/vt.c)
> > > int con_font_op(struct vc_data *vc, struct console_font_op *op)
> > > {
> > > switch (op->op) {
> > > case KD_FONT_OP_SET:
> > > return con_font_set(vc, op);
> > > case KD_FONT_OP_GET:
> > > return con_font_get(vc, op);
> > > case KD_FONT_OP_SET_DEFAULT:
> > > return con_font_default(vc, op);
> > > case KD_FONT_OP_COPY:
> > > return con_font_copy(vc, op);
> > > }
> > > return -ENOSYS;
> > > }
> >
> > So my gut feeling is that this is just a bit of overenthusiastic
> > common code sharing, and all it results is confuse everyone. I think
> > if we change the conf_font_get/set/default/copy functions to not take
> > the *op struct (which is take pretty arbitrarily from one of the
> > ioctl), but the parameters each needs directly, that would clean up
> > the code a _lot_. Since most callers would then directly call the
> > right operation, instead of this detour through console_font_op.
> > struct console_font_op is an uapi struct, so really shouldn't be used
> > for internal abstractions - we can't change uapi, hence this makes it
> > impossible to refactor anything from the get-go.
> >
> > I also think that trying to get rid of con_font_op callers as much as
> > possible (everywhere where the op struct is constructed in the kernel
> > and doesn't come from userspace essentially) should be doable as a
> > stand-alone patch series.
>
> I see, I'll do some code searching and try to clean them up.
>
> > > These 4 functions allocate `console_font`. We can replace them with our
> > > `kernel_console_font`. So, ...
> > >
> > > $ vgrep "\.con_font_set"
> >
> > An aside: git grep is awesome, and really fast.
>
> Ah, yes, by default vgrep uses git-grep. I use vgrep when I need to see
> something colorful :)
>
> > > $ vgrep "\.con_font_get"
> > > Index FileLine Content
> > > 0 drivers/usb/misc/sisusbvga/sisusb_con.c 1295 .con_font_get =
> > > sisusbcon_font_get,
> > > 1 drivers/video/console/vgacon.c 1227 .con_font_get =
> > > vgacon_font_get,
> > > 2 drivers/video/fbdev/core/fbcon.c3121 .con_font_get
> > > = fbcon_get_font,
> > > $
> > > $ vgrep "\.con_font_default"
> > > Index FileLine Content
> > > 0 drivers/usb/misc/sisusbvga/sisusb_con.c 1379 .con_font_default =
> > > sisusbdummycon_font_default,
> > > 1 drivers/video/console/dummycon.c 163 .con_font_default =
> > > dummycon_font_default,
> >
> > The above two return 0 but do nothing, which means width/height are
> > now bogus (or well the same as what userspace set). I don't think that
> > works correctly ...
> >
> > > 2 drivers/video/console/newport_con.c 694 .con_font_default =
> > > newport_font_default,
> >
> > This just seems to release the userspace font. This is already done in
> > other places where it makes a lot more sense to clean up.
> >
> > > 3 drivers/video/fbdev/core/fbcon.c3122 .con_font_default=
> > > fbcon_set_def_font,
> >
> > This actually does something. tbh I would not be surprises if the
> > fb_set utility is the only thing that uses this - with a bit of code
> > search we could perhaps confirm this, and delete all the other
> > implementations.
> >
> > > $ vgrep "\.con_font_copy"
> > > Index FileLine Content
> > > 0 drivers/usb/misc/sisusbvga/sisusb_con.c 1380 .con_font_copy =
> > > sisusbdummycon_font_copy,
> > > 1 drivers/video/console/dummycon.c 164 .con_font_copy =
> > > dummycon_font_copy,
> >
> > Above two do nothing, but return 0. Again this wont work I think.
> >
> > > 2 drivers/video/fbdev/core/fbcon.c3123 .con_font_copy
> > > = fbcon_copy_font,
> >
> > Smells again like something that's only used by fb_set, and we could
> > probably delete the other dummy implementations. Also I'm not even
> > really clear on what this does ...
> >
> > Removing these dummy functions means that for a dummy console these
> > ioctls would start failing, but then I don't think anyone boots up
> > into a dummy console and expects font changes to work. So again I
> > think we could split this cleanup as prep work.
>
> Sure, for step two, I'll read, confirm and try to remove these dummy
> functions.
>
> > > ... are these all the callbacks we need to take care of? What about
> > > other console drivers that don't register these callbacks? ...
> > >
> > > ... for example, mdacon.c? What font does mdacon.
Re: [PATCH 3/3] RFC: dma-buf: Add an API for importing and exporting sync files (v5)
On Wed, Sep 30, 2020 at 11:39:06AM +0200, Michel Dänzer wrote: > On 2020-03-17 10:21 p.m., Jason Ekstrand wrote: > > Explicit synchronization is the future. At least, that seems to be what > > most userspace APIs are agreeing on at this point. However, most of our > > Linux APIs (both userspace and kernel UAPI) are currently built around > > implicit synchronization with dma-buf. While work is ongoing to change > > many of the userspace APIs and protocols to an explicit synchronization > > model, switching over piecemeal is difficult due to the number of > > potential components involved. On the kernel side, many drivers use > > dma-buf including GPU (3D/compute), display, v4l, and others. In > > userspace, we have X11, several Wayland compositors, 3D drivers, compute > > drivers (OpenCL etc.), media encode/decode, and the list goes on. > > > > This patch provides a path forward by allowing userspace to manually > > manage the fences attached to a dma-buf. Alternatively, one can think > > of this as making dma-buf's implicit synchronization simply a carrier > > for an explicit fence. This is accomplished by adding two IOCTLs to > > dma-buf for importing and exporting a sync file to/from the dma-buf. > > This way a userspace component which is uses explicit synchronization, > > such as a Vulkan driver, can manually set the write fence on a buffer > > before handing it off to an implicitly synchronized component such as a > > Wayland compositor or video encoder. In this way, each of the different > > components can be upgraded to an explicit synchronization model one at a > > time as long as the userspace pieces connecting them are aware of it and > > import/export fences at the right times. > > > > There is a potential race condition with this API if userspace is not > > careful. A typical use case for implicit synchronization is to wait for > > the dma-buf to be ready, use it, and then signal it for some other > > component. Because a sync_file cannot be created until it is guaranteed > > to complete in finite time, userspace can only signal the dma-buf after > > it has already submitted the work which uses it to the kernel and has > > received a sync_file back. There is no way to atomically submit a > > wait-use-signal operation. This is not, however, really a problem with > > this API so much as it is a problem with explicit synchronization > > itself. The way this is typically handled is to have very explicit > > ownership transfer points in the API or protocol which ensure that only > > one component is using it at any given time. Both X11 (via the PRESENT > > extension) and Wayland provide such ownership transfer points via > > explicit present and idle messages. > > > > The decision was intentionally made in this patch to make the import and > > export operations IOCTLs on the dma-buf itself rather than as a DRM > > IOCTL. This makes it the import/export operation universal across all > > components which use dma-buf including GPU, display, v4l, and others. > > It also means that a userspace component can do the import/export > > without access to the DRM fd which may be tricky to get in cases where > > the client communicates with DRM via a userspace API such as OpenGL or > > Vulkan. At a future date we may choose to add direct import/export APIs > > to components such as drm_syncobj to avoid allocating a file descriptor > > and going through two ioctls. However, that seems to be something of a > > micro-optimization as import/export operations are likely to happen at a > > rate of a few per frame of rendered or decoded video. > > > > v2 (Jason Ekstrand): > > - Use a wrapper dma_fence_array of all fences including the new one > > when importing an exclusive fence. > > > > v3 (Jason Ekstrand): > > - Lock around setting shared fences as well as exclusive > > - Mark SIGNAL_SYNC_FILE as a read-write ioctl. > > - Initialize ret to 0 in dma_buf_wait_sync_file > > > > v4 (Jason Ekstrand): > > - Use the new dma_resv_get_singleton helper > > > > v5 (Jason Ekstrand): > > - Rename the IOCTLs to import/export rather than wait/signal > > - Drop the WRITE flag and always get/set the exclusive fence > > > > Signed-off-by: Jason Ekstrand > > What's the status of this? DMA_BUF_IOCTL_EXPORT_SYNC_FILE would be useful > for Wayland compositors to wait for client buffers to become ready without > being prone to getting delayed by later HW access to them, so it would be > nice to merge that at least (if DMA_BUF_IOCTL_IMPORT_SYNC_FILE is still > controversial). I think the missing bits are just the usual stuff - igt testcases - userspace using the new ioctls - review of the entire pile I don't think there's any fundamental objections aside from "no one ever pushed this over the finish line". Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [PATCH] [v2] wireless: Initial driver submission for pureLiFi devices
On Wed, Sep 30, 2020 at 11:01:27AM +0300, Kalle Valo wrote: > Leon Romanovsky writes: > > >> diff --git a/drivers/net/wireless/purelifi/Kconfig > > b/drivers/net/wireless/purelifi/Kconfig > >> new file mode 100644 > >> index ..ff05eaf0a8d4 > >> --- /dev/null > >> +++ b/drivers/net/wireless/purelifi/Kconfig > >> @@ -0,0 +1,38 @@ > >> +# SPDX-License-Identifier: GPL-2.0 > >> +config WLAN_VENDOR_PURELIFI > >> + bool "pureLiFi devices" > >> + default y > > > > "N" is preferred default. > > In most cases that's true, but for WLAN_VENDOR_ configs 'default y' > should be used. It's the same as with NET_VENDOR_. I would like to challenge it, why is that? Why do I need to set "N", every time new vendor upstreams its code? Thanks > > > -- > https://patchwork.kernel.org/project/linux-wireless/list/ > > https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH v3] mm: memcontrol: reword obsolete comment of mem_cgroup_unmark_under_oom()
Since commit 79dfdaccd1d5 ("memcg: make oom_lock 0 and 1 based rather than
counter"), the mem_cgroup_unmark_under_oom() is added and the comment of
the mem_cgroup_oom_unlock() is moved here. But this comment make no sense
here because mem_cgroup_oom_lock() does not operate on under_oom field. So
we reword the comment as this would be helpful.
[Thanks Michal Hocko for rewording this comment.]
Signed-off-by: Miaohe Lin
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Vladimir Davydov
---
mm/memcontrol.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 6877c765b8d0..4f0c14cb8690 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1817,8 +1817,8 @@ static void mem_cgroup_unmark_under_oom(struct mem_cgroup
*memcg)
struct mem_cgroup *iter;
/*
-* When a new child is created while the hierarchy is under oom,
-* mem_cgroup_oom_lock() may not be called. Watch for underflow.
+* Be careful about under_oom underflows becase a child memcg
+* could have been added after mem_cgroup_mark_under_oom.
*/
spin_lock(&memcg_oom_lock);
for_each_mem_cgroup_tree(iter, memcg)
--
2.19.1
Re: [PATCH v2] block: Fix potential page reference leak in __bio_iov_append_get_pages()
Friendly ping :)
> When bio_add_hw_page() failed, we left page reference still held in pages
> from iov_iter_get_pages(). Release these references and also advance the
> iov_iter according to what we have done successfully yet.
>
> Fixes: 0512a75b98f8 ("block: Introduce REQ_OP_ZONE_APPEND")
> Reviewed-by: Johannes Thumshirn
> Signed-off-by: Miaohe Lin
> ---
> block/bio.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/block/bio.c b/block/bio.c
> index e113073958cb..a323a5446221 100644
> --- a/block/bio.c
Re: [PATCH 1/1] sched/fair: Fix the wrong sched_stat_wait time
On Wed, Sep 30, 2020 at 05:16:29PM +0800, jun qian wrote: > Peter Zijlstra 于2020年9月30日周三 下午4:20写道： > > > > On Wed, Sep 30, 2020 at 10:47:12AM +0800, qianjun.ker...@gmail.com wrote: > > > From: jun qian > > > > > > When the sched_schedstat changes from 0 to 1, some sched se maybe > > > already in the runqueue, the se->statistics.wait_start will be 0. > > > So it will let the (rq_of(cfs_rq)) - se->statistics.wait_start) > > > wrong. We need to avoid this scenario. > > > > Is this really the only problem there? Did you do a full audit of that > > schedstat nonsense? > > > > Did you mean that the sched_stat_xxx's xxx_start(sched_stat_sleep > sched_stat_iowait sched_stat_blocked > sched_stat_runtime) may be also depend the schedstat_enabled? Yeah, this runtime schedstat_enabled thing is fairly recent, it used to be an always on/off kinda thing. At the time we figured inconsistencies from dynamically enabling/disabling it were okay, it's just stats after all. But if you now want to 'fix' that, then a full audit might be nice. > I have searched the codes, and found that these sched_stat_xxx's > xxx_start don't depend the schedstat_enabled > except the wait_start. OK, so you did the audit and only found this one issue? That's good Changelog material :-) Thanks!
Re: [PATCH] locking/atomic/bitops: Fix some wrong param names in comments
Friendly ping :) > Correct the wrong param name @addr to @p. > > Signed-off-by: Miaohe Lin > --- > include/asm-generic/bitops/lock.h | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/include/asm-generic/bitops/lock.h > b/include/asm-generic/bitops/lock.h
Re: [PATCH v13 00/15] mtd: spi-nor: add xSPI Octal DTR support
On 9/16/20 3:44 PM, Pratyush Yadav wrote: > Hi, Hello, > > This series adds support for Octal DTR flashes in the SPI NOR framework, > and then adds hooks for the Cypress Semper and Micron Xcella flashes to > allow running them in Octal DTR mode. This series assumes that the flash > is handed to the kernel in Legacy SPI mode. > I like this series. There are some comments that can be addressed, no big deal though. I think that we shouldn't let the door open for users with flashes that enter in a X-X-X mode in a non-volatile way. Think of two flashes that have the same X-X-X mode enable sequence, but in which only the EN bit differs: for one the EN bit is volatile and for the other it is non-volatile. Users of the later flash that try to enable the X-X-X mode (using our code) will end up with the flash in a mode from which they can't recover. Thus my advice is to consider by default all the flashes, as X-X-X mode non-volatile flashes, and to not let them use the X-X-X mode enable methods. Flashes that can enter X-X-X modes in a volatile way, should discover this capability by parsing the optional SFDP SCCR Map. Those that don't define this table, should pass this capability as a flash_info flag when declaring the flash. With these, users should be conscious about the V or NV modes, and the risk to end up with flashes for which there is no software to recover is diminished. This is what I tried in RFC 1/3 and RFC 3/3. I think those 2 patches should be part of this series. 14/15 and 15/15 should be updated accordingly. RFC 2/3 has room for discussions because it provides access system-wise, while ideally would be to do it at flash granularity. I'll wait for your feedback on those. > Tested on TI J721E EVM with 1-bit ECC on the Cypress flash. As a tip, when introducing some big changes to the core, would be nice to be assured that things that worked previously are still working now. An erase-write-read-back test in Quad SPI would suffice. Probably you have already did that, but I haven't seen it mentioned. Cheers, ta
[RFC PATCH 0/2] objtool and cross compilation
This is based on v5.9-rc7, before "other architectures support" patches starting pouring in. Currently objtool seems to be the only tool from build tools needed which breaks x86 cross compilation on big endian systems. But besides x86 cross compilation, endianness awareness is also needed for big endian architectures objtool support in general. We have working prototype of objtool support and orc unwinder for s390 made originally by Martin Schwidefsky. I'm trying to bring it in shape again and refactor to share more code with "generic" part. But first things first. These 2 patches point to endianness problems which should be addressed. And I'd be glad to get any ideas how to make them less ugly. New "other architectures support" patches currently move only some problematic parts into x86 arch specific folder. But the main problem is that arch/x86/lib/insn.c and arch/x86/include/asm/insn.h are shared across the kernel source and the tools, and there is no common way to address endianness problems. Since big endian stuff is only needed for the objtool and not for the kernel I can try to hide alternative big endian definitions in tools only header which is included only if __KERNEL__ is not defined. But that kind of defeats the idea of sharing those files 1 to 1 with tools. Thoughts? Any suggestions are welcome. Martin Schwidefsky (1): objtool: x86 instruction decoder and big endian cross compiles Vasily Gorbik (1): objtool: fix x86 orc generation on big endian cross compiles arch/x86/include/asm/insn.h| 43 arch/x86/include/asm/orc_types.h | 24 +++ arch/x86/lib/insn.c| 95 +++--- tools/arch/x86/include/asm/insn.h | 43 tools/arch/x86/include/asm/orc_types.h | 24 +++ tools/arch/x86/lib/insn.c | 95 +++--- tools/objtool/check.c | 4 +- tools/objtool/elf.c| 34 + tools/objtool/orc_dump.c | 4 +- tools/objtool/orc_gen.c| 2 + tools/objtool/special.c| 4 +- 11 files changed, 243 insertions(+), 129 deletions(-) -- ⢋⡀⣀⠹ ⠠⣶⡦⠀ ⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿ ⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿ ⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿ ⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
[RFC PATCH 1/2] objtool: x86 instruction decoder and big endian cross compiles
From: Martin Schwidefsky
Make the x86 instruction decoder of the objtool usable on big endian
machines. This is useful for compile tests on non x86, big endian
hardware.
Co-developed-by: Vasily Gorbik
[ gor: more endianness problems findings fixes / rebasing ]
Signed-off-by: Martin Schwidefsky
Signed-off-by: Vasily Gorbik
---
arch/x86/include/asm/insn.h | 43 ++
arch/x86/lib/insn.c | 95 +--
tools/arch/x86/include/asm/insn.h | 43 ++
tools/arch/x86/lib/insn.c | 95 +--
tools/objtool/check.c | 4 +-
tools/objtool/elf.c | 34 ++-
tools/objtool/special.c | 4 +-
7 files changed, 191 insertions(+), 127 deletions(-)
diff --git a/arch/x86/include/asm/insn.h b/arch/x86/include/asm/insn.h
index 5c1ae3eff9d4..8d9864b09552 100644
--- a/arch/x86/include/asm/insn.h
+++ b/arch/x86/include/asm/insn.h
@@ -8,8 +8,17 @@
*/
/* insn_attr_t is defined in inat.h */
+#ifdef __KERNEL__
+#include
+#include
+#else
+#include
+#endif
#include
+#if defined(__BYTE_ORDER) ? \
+ __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
+
struct insn_field {
union {
insn_value_t value;
@@ -20,6 +29,40 @@ struct insn_field {
unsigned char nbytes;
};
+static inline void insn_field_set(struct insn_field *p, insn_value_t v,
+ unsigned char n)
+{
+ p->value = v;
+ p->nbytes = n;
+}
+
+#else
+
+struct insn_field {
+ insn_value_t value;
+ union {
+ insn_value_t little;
+ insn_byte_t bytes[4];
+ };
+ /* !0 if we've run insn_get_xxx() for this field */
+ unsigned char got;
+ unsigned char nbytes;
+};
+
+static inline void insn_field_set(struct insn_field *p, insn_value_t v,
+ unsigned char n)
+{
+ p->value = v;
+#ifdef __KERNEL__
+ p->little = __swap32(v);
+#else
+ p->little = __bswap_32(v);
+#endif
+ p->nbytes = n;
+}
+
+#endif
+
struct insn {
struct insn_field prefixes; /*
* Prefixes
diff --git a/arch/x86/lib/insn.c b/arch/x86/lib/insn.c
index 404279563891..9150bdc8a6d6 100644
--- a/arch/x86/lib/insn.c
+++ b/arch/x86/lib/insn.c
@@ -15,15 +15,23 @@
#include
+#ifdef __KERNEL__
+#define letoh(t, r) \
+ ((sizeof(t) == 4) ? le32_to_cpu(r) : (sizeof(t) == 2) ? le16_to_cpu(r)
: r)
+#else
+#define letoh(t, r) \
+ ((sizeof(t) == 4) ? le32toh(r) : (sizeof(t) == 2) ? le16toh(r) : r)
+#endif
+
/* Verify next sizeof(t) bytes can be on the same instruction */
#define validate_next(t, insn, n) \
((insn)->next_byte + sizeof(t) + n <= (insn)->end_kaddr)
#define __get_next(t, insn)\
- ({ t r = *(t*)insn->next_byte; insn->next_byte += sizeof(t); r; })
+ ({ t r = *(t*)insn->next_byte; insn->next_byte += sizeof(t); letoh(t,
r); })
#define __peek_nbyte_next(t, insn, n) \
- ({ t r = *(t*)((insn)->next_byte + n); r; })
+ ({ t r = *(t*)((insn)->next_byte + n); letoh(t, r); })
#define get_next(t, insn) \
({ if (unlikely(!validate_next(t, insn, 0))) goto err_out;
__get_next(t, insn); })
@@ -157,8 +165,7 @@ void insn_get_prefixes(struct insn *insn)
b = peek_next(insn_byte_t, insn);
attr = inat_get_opcode_attribute(b);
if (inat_is_rex_prefix(attr)) {
- insn->rex_prefix.value = b;
- insn->rex_prefix.nbytes = 1;
+ insn_field_set(&insn->rex_prefix, b, 1);
insn->next_byte++;
if (X86_REX_W(b))
/* REX.W overrides opnd_size */
@@ -295,8 +302,7 @@ void insn_get_modrm(struct insn *insn)
if (inat_has_modrm(insn->attr)) {
mod = get_next(insn_byte_t, insn);
- modrm->value = mod;
- modrm->nbytes = 1;
+ insn_field_set(modrm, mod, 1);
if (inat_is_group(insn->attr)) {
pfx_id = insn_last_prefix_id(insn);
insn->attr = inat_get_group_attribute(mod, pfx_id,
@@ -334,7 +340,7 @@ int insn_rip_relative(struct insn *insn)
* For rip-relative instructions, the mod field (top 2 bits)
* is zero and the r/m field (bottom 3 bits) is 0x5.
*/
- return (modrm->nbytes && (modrm->value & 0xc7) == 0x5);
+ return (modrm->nbytes && (modrm->bytes[0] & 0xc7) == 0x5);
}
/**
@@ -353,11 +359,11 @@ void insn_get_sib(struct insn *insn)
if (!insn->modrm.got)
insn_get_modrm(insn);
if (insn->modrm.nbytes) {
- modrm = (insn_byte_t)insn->modrm.value;
+ modrm = insn->modrm.bytes[0];
if (insn->addr_bytes != 2 &&
X86_MODRM_MOD(modrm) != 3 && X86_MODRM_RM(mod
Re: [PATCH v4 09/29] arm64: disable recordmcount with DYNAMIC_FTRACE_WITH_REGS
Hi Sami, On Tue, Sep 29, 2020 at 02:46:11PM -0700, Sami Tolvanen wrote: > Select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY to disable > recordmcount when DYNAMIC_FTRACE_WITH_REGS is selected. Could you please add an explanation as to /why/ this is necessary in the commit message? I couldn't figure this out form the commit message alone, and reading the cover letter also didn't help. If the minimum required GCC version supports patchable-function-entry I'd be happy to make that a requirement for dynamic ftrace on arm64, as then we'd only need to support one mechanism, and can get rid of some redundant code. We already default to it when present anyhow. > > Signed-off-by: Sami Tolvanen > --- > arch/arm64/Kconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 6d232837cbee..ad522b021f35 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -155,6 +155,8 @@ config ARM64 > select HAVE_DYNAMIC_FTRACE > select HAVE_DYNAMIC_FTRACE_WITH_REGS \ > if $(cc-option,-fpatchable-function-entry=2) > + select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \ > + if DYNAMIC_FTRACE_WITH_REGS This doesn't look quite right to me. Presumably we shouldn't allow DYNAMIC_FTRACE_WITH_REGS to be selected if HAVE_DYNAMIC_FTRACE_WITH_REGS isn't. Thanks, Mark.
[RFC PATCH 2/2] objtool: fix x86 orc generation on big endian cross compiles
Correct objtool orc generation endianness problems to enable fully
functional x86 cross compiles on big endian hardware.
Signed-off-by: Vasily Gorbik
---
arch/x86/include/asm/orc_types.h | 24
tools/arch/x86/include/asm/orc_types.h | 24
tools/objtool/orc_dump.c | 4 ++--
tools/objtool/orc_gen.c| 2 ++
4 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/orc_types.h b/arch/x86/include/asm/orc_types.h
index d25534940bde..931f99b70af3 100644
--- a/arch/x86/include/asm/orc_types.h
+++ b/arch/x86/include/asm/orc_types.h
@@ -61,6 +61,13 @@
#define UNWIND_HINT_TYPE_RET_OFFSET3
#ifndef __ASSEMBLY__
+#ifdef __KERNEL__
+#include
+#include
+#else
+#include
+#endif
+
/*
* This struct is more or less a vastly simplified version of the DWARF Call
* Frame Information standard. It contains only the necessary parts of DWARF
@@ -69,6 +76,9 @@
* the stack for a given code address. Each instance of the struct corresponds
* to one or more code locations.
*/
+#if defined(__BYTE_ORDER) ? \
+ __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
+
struct orc_entry {
s16 sp_offset;
s16 bp_offset;
@@ -78,6 +88,20 @@ struct orc_entry {
unsignedend:1;
} __packed;
+#else
+
+struct orc_entry {
+ s16 sp_offset;
+ s16 bp_offset;
+ unsignedbp_reg:4;
+ unsignedsp_reg:4;
+ unsignedunused:5;
+ unsignedend:1;
+ unsignedtype:2;
+} __packed;
+
+#endif
+
/*
* This struct is used by asm and inline asm code to manually annotate the
* location of registers on the stack for the ORC unwinder.
diff --git a/tools/arch/x86/include/asm/orc_types.h
b/tools/arch/x86/include/asm/orc_types.h
index d25534940bde..931f99b70af3 100644
--- a/tools/arch/x86/include/asm/orc_types.h
+++ b/tools/arch/x86/include/asm/orc_types.h
@@ -61,6 +61,13 @@
#define UNWIND_HINT_TYPE_RET_OFFSET3
#ifndef __ASSEMBLY__
+#ifdef __KERNEL__
+#include
+#include
+#else
+#include
+#endif
+
/*
* This struct is more or less a vastly simplified version of the DWARF Call
* Frame Information standard. It contains only the necessary parts of DWARF
@@ -69,6 +76,9 @@
* the stack for a given code address. Each instance of the struct corresponds
* to one or more code locations.
*/
+#if defined(__BYTE_ORDER) ? \
+ __BYTE_ORDER == __LITTLE_ENDIAN : defined(__LITTLE_ENDIAN)
+
struct orc_entry {
s16 sp_offset;
s16 bp_offset;
@@ -78,6 +88,20 @@ struct orc_entry {
unsignedend:1;
} __packed;
+#else
+
+struct orc_entry {
+ s16 sp_offset;
+ s16 bp_offset;
+ unsignedbp_reg:4;
+ unsignedsp_reg:4;
+ unsignedunused:5;
+ unsignedend:1;
+ unsignedtype:2;
+} __packed;
+
+#endif
+
/*
* This struct is used by asm and inline asm code to manually annotate the
* location of registers on the stack for the ORC unwinder.
diff --git a/tools/objtool/orc_dump.c b/tools/objtool/orc_dump.c
index fca46e006fc2..0fbf8521c891 100644
--- a/tools/objtool/orc_dump.c
+++ b/tools/objtool/orc_dump.c
@@ -196,11 +196,11 @@ int orc_dump(const char *_objname)
printf(" sp:");
- print_reg(orc[i].sp_reg, orc[i].sp_offset);
+ print_reg(orc[i].sp_reg, (s16)le16toh(orc[i].sp_offset));
printf(" bp:");
- print_reg(orc[i].bp_reg, orc[i].bp_offset);
+ print_reg(orc[i].bp_reg, (s16)le16toh(orc[i].bp_offset));
printf(" type:%s end:%d\n",
orc_type_name(orc[i].type), orc[i].end);
diff --git a/tools/objtool/orc_gen.c b/tools/objtool/orc_gen.c
index 968f55e6dd94..b3978fad93e6 100644
--- a/tools/objtool/orc_gen.c
+++ b/tools/objtool/orc_gen.c
@@ -90,6 +90,8 @@ static int create_orc_entry(struct elf *elf, struct section
*u_sec, struct secti
/* populate ORC data */
orc = (struct orc_entry *)u_sec->data->d_buf + idx;
memcpy(orc, o, sizeof(*orc));
+ orc->sp_offset = htole16(orc->sp_offset);
+ orc->bp_offset = htole16(orc->bp_offset);
/* populate reloc for ip */
reloc = malloc(sizeof(*reloc));
--
⢋⡀⣀⠹
⠠⣶⡦⠀
⣿⣿⣿⠏⣴⣮⣴⣧⠈⢿⣿⣿
⣿⣿⡏⢰⣿⠖⣠⣿⡆⠈⣿⣿
⣿⢛⣵⣄⠙⣶⣶⡟⣅⣠⠹⣿
⣿⣜⣛⠻⢎⣉⣉⣀⠿⣫⣵⣿
