Re: [PATCH net-next 1/4] net: use indirect call helpers for dst_input
Hi Brian, Thank you for the patch! Yet something to improve: [auto build test ERROR on net-next/master] url: https://github.com/0day-ci/linux/commits/Brian-Vazquez/net-avoid-indirect-calls-in-dst-functions/20201211-100941 base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 51e13685bd93654e0e9b2559c8e103d6545ddf95 config: x86_64-randconfig-a011-20201209 (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/f63e8ffacedd4f9e322d6deaf20adacf4c9e3c87 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Brian-Vazquez/net-avoid-indirect-calls-in-dst-functions/20201211-100941 git checkout f63e8ffacedd4f9e322d6deaf20adacf4c9e3c87 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "ip_local_deliver" [net/decnet/decnet.ko] undefined! --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[RFC PATCH] KVM: arm64: Add prejudgement for relaxing permissions only case in stage2 translation fault handler
In dirty-logging, or dirty-logging-stopped time, even normal running
time of a guest configed with huge mappings and numbers of vCPUs,
translation faults by different vCPUs on the same GPA could occur
successively almost at the same time. There are two reasons for it.
(1) If there are some vCPUs accessing the same GPA at the same time
and the leaf PTE is not set yet, then they will all cause translation
faults and the first vCPU holding mmu_lock will set valid leaf PTE,
and the others will later choose to update the leaf PTE or not.
(2) When changing a leaf entry or a table entry with break-before-make,
if there are some vCPUs accessing the same GPA just catch the moment
when the target PTE is set invalid in a BBM procedure coincidentally,
they will all cause translation faults and will later choose to update
the leaf PTE or not.
The worst case can be like this: some vCPUs cause translation faults
on the same GPA with different prots, they will fight each other by
changing back access permissions of the PTE with break-before-make.
And the BBM-invalid moment might trigger more unnecessary translation
faults. As a result, some useless small loops will occur, which could
lead to vCPU stuck.
To avoid unnecessary update and small loops, add prejudgement in the
translation fault handler: Skip updating the valid leaf PTE if we are
trying to recreate exactly the same mapping or to reduce access
permissions only(such as RW-->RO). And update the valid leaf PTE without
break-before-make if we are trying to add more permissions only.
Signed-off-by: Yanan Wang
---
arch/arm64/kvm/hyp/pgtable.c | 73 +---
1 file changed, 52 insertions(+), 21 deletions(-)
diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
index 23a01dfcb27a..f8b3248cef1c 100644
--- a/arch/arm64/kvm/hyp/pgtable.c
+++ b/arch/arm64/kvm/hyp/pgtable.c
@@ -45,6 +45,8 @@
#define KVM_PTE_LEAF_ATTR_HI_S2_XN BIT(54)
+#define KVM_PTE_LEAF_ATTR_PERMS(GENMASK(7, 6) | BIT(54))
+
struct kvm_pgtable_walk_data {
struct kvm_pgtable *pgt;
struct kvm_pgtable_walker *walker;
@@ -170,10 +172,9 @@ static void kvm_set_table_pte(kvm_pte_t *ptep, kvm_pte_t
*childp)
smp_store_release(ptep, pte);
}
-static bool kvm_set_valid_leaf_pte(kvm_pte_t *ptep, u64 pa, kvm_pte_t attr,
- u32 level)
+static kvm_pte_t kvm_init_valid_leaf_pte(u64 pa, kvm_pte_t attr, u32 level)
{
- kvm_pte_t old = *ptep, pte = kvm_phys_to_pte(pa);
+ kvm_pte_t pte = kvm_phys_to_pte(pa);
u64 type = (level == KVM_PGTABLE_MAX_LEVELS - 1) ? KVM_PTE_TYPE_PAGE :
KVM_PTE_TYPE_BLOCK;
@@ -181,12 +182,7 @@ static bool kvm_set_valid_leaf_pte(kvm_pte_t *ptep, u64
pa, kvm_pte_t attr,
pte |= FIELD_PREP(KVM_PTE_TYPE, type);
pte |= KVM_PTE_VALID;
- /* Tolerate KVM recreating the exact same mapping. */
- if (kvm_pte_valid(old))
- return old == pte;
-
- smp_store_release(ptep, pte);
- return true;
+ return pte;
}
static int kvm_pgtable_visitor_cb(struct kvm_pgtable_walk_data *data, u64 addr,
@@ -341,12 +337,17 @@ static int hyp_map_set_prot_attr(enum kvm_pgtable_prot
prot,
static bool hyp_map_walker_try_leaf(u64 addr, u64 end, u32 level,
kvm_pte_t *ptep, struct hyp_map_data *data)
{
+ kvm_pte_t new, old = *ptep;
u64 granule = kvm_granule_size(level), phys = data->phys;
if (!kvm_block_mapping_supported(addr, end, phys, level))
return false;
- WARN_ON(!kvm_set_valid_leaf_pte(ptep, phys, data->attr, level));
+ /* Tolerate KVM recreating the exact same mapping. */
+ new = kvm_init_valid_leaf_pte(phys, data->attr, level);
+ if (old != new && !WARN_ON(kvm_pte_valid(old)))
+ smp_store_release(ptep, new);
+
data->phys += granule;
return true;
}
@@ -461,25 +462,56 @@ static int stage2_map_set_prot_attr(enum kvm_pgtable_prot
prot,
return 0;
}
+static bool stage2_set_valid_leaf_pte_pre(u64 addr, u32 level,
+ kvm_pte_t *ptep, kvm_pte_t new,
+ struct stage2_map_data *data)
+{
+ kvm_pte_t old = *ptep, old_attr, new_attr;
+
+ if ((old ^ new) & (~KVM_PTE_LEAF_ATTR_PERMS))
+ return false;
+
+ /*
+* Skip updating if we are trying to recreate exactly the same mapping
+* or to reduce the access permissions only. And update the valid leaf
+* PTE without break-before-make if we are trying to add more access
+* permissions only.
+*/
+ old_attr = (old & KVM_PTE_LEAF_ATTR_PERMS) ^ KVM_PTE_LEAF_ATTR_HI_S2_XN;
+ new_attr = (new & KVM_PTE_LEAF_ATTR_PERMS) ^ KVM_PTE_LEAF_ATTR_HI_S2_XN;
+ if (new_attr <= old_attr)
+ return true;
+
+
[RFC PATCH 0/1] Add prejudgement for relaxing permissions only case
Hi folks, Found that in dirty-logging, or dirty-logging-stopped time, even normal running time of a guest configed with huge mappings and numbers of vCPUs, translation faults by different vCPUs on the same GPA could occur successively almost at the same time. See below for the trace log, and there are two reasons to explain. (1) If there are some vCPUs accessing the same GPA at the same time and the leaf PTE is not set yet, then they will all cause translation faults and the first vCPU holding mmu_lock will set valid leaf PTE, and the others will later choose to update the leaf PTE or not. (2) When changing a leaf entry or a table entry with break-before-make, if there are some vCPUs accessing the same GPA just catch the moment when the target PTE is set invalid in a BBM procedure coincidentally, they will all cause translation faults and will later choose to update the leaf PTE or not. The worst case can be like this: some vCPUs cause translation faults on the same GPA with different prots, they will fight each other by changing back access permissions of the PTE with break-before-make. And the BBM-invalid moment might trigger more unnecessary translation faults. As a result, some useless small loops will occur, which could lead to vCPU stuck. We have met the stuck occasionally in guest migration and migration-stop time. To avoid unnecessary update and small loops, add prejudgement in the translation fault handler: Skip updating the valid leaf PTE if we are trying to recreate exactly the same mapping or to reduce access permissions only(such as RW-->RO). And update the valid leaf PTE without break-before-make if we are trying to add more permissions only. Yanan Wang (1): KVM: arm64: Add prejudgement for relaxing permissions only case in stage2 translation fault handler arch/arm64/kvm/hyp/pgtable.c | 73 +--- 1 file changed, 52 insertions(+), 21 deletions(-) -- 2.19.1 Trace log for a guest with 96 vCPUs and huge mappings by 1G. * Recreating the same mappings and small loops in dirty-logging period. * Recreating the same mappings: CPU 94/KVM-8590[094] ...2 82538.821614: user_mem_abort: logging_active 1, vcpu_id 94, f_ipa 0x83fffc000 , fault_status 0x4, prot 0x6, vma_pagesize 4096 , write_fault 1, exec_fault 0 CPU 94/KVM-8590[094] ...2 82538.821615: stage2_map_walker_try_leaf_equal: addr 0x83fffc000 , level 3, old_pte 0x40002a7fffc7ff, new_pte 0x40002a7fffc7ff CPU 55/KVM-8547[055] ...2 82538.821618: user_mem_abort: logging_active 1, vcpu_id 55, f_ipa 0x83fffc000 , fault_status 0x4, prot 0x6, vma_pagesize 4096 , write_fault 1, exec_fault 0 CPU 55/KVM-8547[055] ...2 82538.821619: stage2_map_walker_try_leaf_equal: addr 0x83fffc000 , level 3, old_pte 0x40002a7fffc7ff, new_pte 0x40002a7fffc7ff CPU 78/KVM-8572[078] ...2 82538.821620: user_mem_abort: logging_active 1, vcpu_id 78, f_ipa 0x83fffc000 , fault_status 0x4, prot 0x6, vma_pagesize 4096 , write_fault 1, exec_fault 0 CPU 78/KVM-8572[078] ...2 82538.821622: stage2_map_walker_try_leaf_equal: addr 0x83fffc000 , level 3, old_pte 0x40002a7fffc7ff, new_pte 0x40002a7fffc7ff CPU 59/KVM-8552[059] ...2 82538.821624: user_mem_abort: logging_active 1, vcpu_id 59, f_ipa 0x83fffc000 , fault_status 0x4, prot 0x6, vma_pagesize 4096 , write_fault 1, exec_fault 0 CPU 59/KVM-8552[059] ...2 82538.821625: stage2_map_walker_try_leaf_equal: addr 0x83fffc000 , level 3, old_pte 0x40002a7fffc7ff, new_pte 0x40002a7fffc7ff CPU 57/KVM-8549[057] ...2 82538.821626: user_mem_abort: logging_active 1, vcpu_id 57, f_ipa 0x83fffc000 , fault_status 0x4, prot 0x6, vma_pagesize 4096 , write_fault 1, exec_fault 0 CPU 57/KVM-8549[057] ...2 82538.821626: stage2_map_walker_try_leaf_equal: addr 0x83fffc000 , level 3, old_pte 0x40002a7fffc7ff, new_pte 0x40002a7fffc
Re: mmc: atmel-mci: Reduce scope for the variable “slot” in atmci_request_end()
On 11/12/2020 07:34:41+0100, Markus Elfring wrote:
> >> How do you think about a patch like “staging: speakup: remove redundant
> >> initialization
> >> of pointer p_key” for comparison?
> >> https://lore.kernel.org/patchwork/patch/1199128/
> >> https://lore.kernel.org/driverdev-devel/20200223153954.420731-1-colin.k...@canonical.com/
> >>
> >> Would you tolerate to omit the initialisation for the variable “slot”?
> >
> > If you were able to provide one good technical reason.
>
> I find that the positions of variable definitions (and similar assignments)
> influence
> the generation of executable code.
>
And you are wrong, it doesn't. Before:
c044a0f0 :
{
c044a0f0: e92d4070push{r4, r5, r6, lr}
c044a0f4: e1a04000mov r4, r0
WARN_ON(host->cmd || host->data);
c044a0f8: e5902024ldr r2, [r0, #36] ; 0x24
{
c044a0fc: e1a06001mov r6, r1
struct mmc_host *prev_mmc = host->cur_slot->mmc;
c044a100: e590301cldr r3, [r0, #28]
WARN_ON(host->cmd || host->data);
c044a104: e352cmp r2, #0
struct mmc_host *prev_mmc = host->cur_slot->mmc;
c044a108: e5935000ldr r5, [r3]
WARN_ON(host->cmd || host->data);
c044a10c: 0a2dbeq c044a1c8
c044a110: e300movwr0, #0
c044a110: R_ARM_MOVW_ABS_NC .LC0
c044a114: e3a03000mov r3, #0
c044a118: e340movtr0, #0
c044a118: R_ARM_MOVT_ABS.LC0
c044a11c: e3a02009mov r2, #9
c044a120: e300161cmovwr1, #1564 ; 0x61c
c044a124: ebfebl 0
c044a124: R_ARM_CALLwarn_slowpath_fmt
del_timer(&host->timer);
c044a128: e28400a4add r0, r4, #164; 0xa4
c044a12c: ebfebl 0
c044a12c: R_ARM_CALLdel_timer
if (host->need_clock_update) {
c044a130: e5d430a0ldrbr3, [r4, #160] ; 0xa0
c044a134: e353cmp r3, #0
c044a138: 0a05beq c044a154
atmci_writel(host, ATMCI_MR, host->mode_reg);
c044a13c: e59420b8ldr r2, [r4, #184] ; 0xb8
c044a140: e5943000ldr r3, [r4]
asm volatile("str %1, %0"
c044a144: e5832004str r2, [r3, #4]
if (host->caps.has_cfg_reg)
c044a148: e5d420daldrbr2, [r4, #218] ; 0xda
c044a14c: e352cmp r2, #0
c044a150: 1a19bne c044a1bc
host->cur_slot->mrq = NULL;
c044a154: e594101cldr r1, [r4, #28]
return READ_ONCE(head->next) == head;
c044a158: e1a03004mov r3, r4
c044a15c: e3a02000mov r2, #0
c044a160: e5812010str r2, [r1, #16]
host->mrq = NULL;
c044a164: e5842020str r2, [r4, #32]
c044a168: e5b31098ldr r1, [r3, #152]! ; 0x98
if (!list_empty(&host->queue)) {
c044a16c: e1510003cmp r1, r3
host->state = STATE_IDLE;
c044a170: 05842094streq r2, [r4, #148] ; 0x94
if (!list_empty(&host->queue)) {
c044a174: 0a0cbeq c044a1ac
slot = list_entry(host->queue.next,
c044a178: e5943098ldr r3, [r4, #152] ; 0x98
After:
c044a0f0 :
{
c044a0f0: e92d4070push{r4, r5, r6, lr}
c044a0f4: e1a04000mov r4, r0
WARN_ON(host->cmd || host->data);
c044a0f8: e5902024ldr r2, [r0, #36] ; 0x24
{
c044a0fc: e1a06001mov r6, r1
struct mmc_host *prev_mmc = host->cur_slot->mmc;
c044a100: e590301cldr r3, [r0, #28]
WARN_ON(host->cmd || host->data);
c044a104: e352cmp r2, #0
struct mmc_host *prev_mmc = host->cur_slot->mmc;
c044a108: e5935000ldr r5, [r3]
WARN_ON(host->cmd || host->data);
c044a10c: 0a2dbeq c044a1c8
c044a110: e300movwr0, #0
c044a110: R_ARM_MOVW_ABS_NC .LC0
c044a114: e3a03000mov r3, #0
c044a118: e340movtr0, #0
c044a118: R_ARM_MOVT_ABS.LC0
c044a11c: e3a02009mov r2, #9
c044a120: e300161bmovwr1, #1563 ; 0x61b
c044a124: ebfebl 0
c044a124: R_ARM_CALLwarn_slowpath_fmt
del_timer(&host->timer);
c044a128: e28400a4add r0, r4, #164; 0xa4
c044a12c: ebfebl 0
c044a12c: R_ARM_CALLdel_timer
if (host->need_clock_update) {
c044a130: e5d430a0ldrbr3, [r4, #160] ; 0xa0
c044a134:
Re: [PATCH] dmabuf: Add the capability to expose DMA-BUF stats in sysfs
Am 10.12.20 um 23:41 schrieb Hridya Valsaraju:
Thanks again for the reviews!
On Thu, Dec 10, 2020 at 3:03 AM Christian König
wrote:
Am 10.12.20 um 11:56 schrieb Greg KH:
On Thu, Dec 10, 2020 at 11:27:27AM +0100, Daniel Vetter wrote:
On Thu, Dec 10, 2020 at 11:10:45AM +0100, Greg KH wrote:
On Thu, Dec 10, 2020 at 10:58:50AM +0100, Christian König wrote:
In general a good idea, but I have a few concern/comments here.
Am 10.12.20 um 05:43 schrieb Hridya Valsaraju:
This patch allows statistics to be enabled for each DMA-BUF in
sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS.
The following stats will be exposed by the interface:
/sys/kernel/dmabuf//exporter_name
/sys/kernel/dmabuf//size
/sys/kernel/dmabuf//dev_map_info
The inode_number is unique for each DMA-BUF and was added earlier [1]
in order to allow userspace to track DMA-BUF usage across different
processes.
Currently, this information is exposed in
/sys/kernel/debug/dma_buf/bufinfo.
However, since debugfs is considered unsafe to be mounted in production,
it is being duplicated in sysfs.
Mhm, this makes it part of the UAPI. What is the justification for this?
In other words do we really need those debug information in a production
environment?
Production environments seem to want to know who is using up memory :)
This only shows shared memory, so it does smell a lot like $specific_issue
and we're designing a narrow solution for that and then have to carry it
forever.
I think the "issue" is that this was a feature from ion that people
"missed" in the dmabuf move. Taking away the ability to see what kind
of allocations were being made didn't make a lot of debugging tools
happy :(
Yeah, that is certainly a very valid concern.
But Hridya knows more, she's been dealing with the transition for a long
time now.
Currently, telemetry tools capture this information(along with other
memory metrics) periodically as well as on important events like a
foreground app kill (which might have been triggered by an LMK). We
would also like to get a snapshot of the system memory usage on other
events such as OOM kills and ANRs.
That userspace tools are going to use those files directly is the
justification you need for the stable UAPI provided by sysfs.
Otherwise debugfs would be the way to go even when that is often disabled.
Please change the commit message to reflect that.
E.g. why is the list of attachments not a sysfs link? That's how we
usually expose struct device * pointers in sysfs to userspace, not as a
list of things.
These aren't struct devices, so I don't understand the objection here.
Where else could these go in sysfs?
Sure they are! Just take a look at an attachment:
struct dma_buf_attachment {
struct dma_buf *dmabuf;
struct device *dev;
This is the struct device which is importing the buffer and the patch in
discussion is just printing the name of this device into sysfs.
I actually did not know that this is not ok to do. I will change it in
the next version of the patch to be sysfs links instead.
Thanks, you need to restructure this patch a bit. But I agree with
Daniel that links to the devices which are attached are more appropriate.
I'm just not sure how we want to represent the map count for each
attachment then, probably best to have that as separate file as well.
Regards,
Christian.
答复: [PATCH] [v2] tty: Protect disc_data in n_tty_close and n_tty_flush_buffer
Hi Greg KH： I try to reproduce this problem in testing, but it is difficult to happen again. It is hard to grasp the timing that n_tty_flush_buffer accesses the disc_data which was just set to NULL by n_tty_close. Thanks Gao Yan -邮件原件- 发件人: Greg KH [mailto:gre...@linuxfoundation.org] 发送时间: 2020年12月10日 14:22 收件人: gaoyan (RD) 抄送: jirisl...@kernel.org; linux-kernel@vger.kernel.org; tianxianting (RD) 主题: Re: [PATCH] [v2] tty: Protect disc_data in n_tty_close and n_tty_flush_buffer On Thu, Dec 10, 2020 at 10:25:07AM +0800, Yan.Gao wrote: > n_tty_flush_buffer can happen in parallel with n_tty_close that the > tty->disc_data will be set to NULL. n_tty_flush_buffer accesses > tty->disc_data, so we must prevent n_tty_close clear tty->disc_data > while n_tty_flush_buffer has a non-NULL view of tty->disc_data. > > So we need to make sure that accesses to disc_data are atomic using > tty->termios_rwsem. > > There is an example I meet: > When n_tty_flush_buffer accesses tty struct, the disc_data is right. > However, then reset_buffer_flags accesses tty->disc_data, disc_data > become NULL, So kernel crash when accesses tty->disc_data->real_tail. > I guess there could be another thread change tty->disc_data to NULL, > and during N_TTY line discipline, n_tty_close will set tty->disc_data > to be NULL. So use tty->termios_rwsem to protect disc_data between > close and flush_buffer. > > IP: reset_buffer_flags+0x9/0xf0 > PGD 0 P4D 0 > Oops: 0002 [#1] SMP > CPU: 23 PID: 2087626 Comm: (agetty) Kdump: loaded Tainted: G Hardware > name: UNISINSIGHT X3036P-G3/ST01M2C7S, BIOS 2.00.13 01/11/2019 > task: 9c4e9da71e80 task.stack: b30cfe898000 > RIP: 0010:reset_buffer_flags+0x9/0xf0 > RSP: 0018:b30cfe89bca8 EFLAGS: 00010246 > RAX: 9c4e9da71e80 RBX: 9c368d1bac00 RCX: > RDX: RSI: 9c4ea17b50f0 RDI: > RBP: b30cfe89bcc8 R08: 0100 R09: 0001 > R10: 0001 R11: R12: 9c368d1bacc0 > R13: 9c20cfd18428 R14: 9c4ea17b50f0 R15: 9c368d1bac00 > FS: 7f9fbbe97940() GS:9c375c74() > knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 2260 CR3: 002f72233003 CR4: 007606e0 > DR0: DR1: DR2: > DR3: DR6: fffe0ff0 DR7: 0400 > PKRU: 5554 > Call Trace: > ? n_tty_flush_buffer+0x2a/0x60 > tty_buffer_flush+0x76/0x90 > tty_ldisc_flush+0x22/0x40 > vt_ioctl+0x5a7/0x10b0 > ? n_tty_ioctl_helper+0x27/0x110 > tty_ioctl+0xef/0x8c0 > do_vfs_ioctl+0xa7/0x5e0 > ? __audit_syscall_entry+0xaf/0x100 > ? syscall_trace_enter+0x1d0/0x2b0 > SyS_ioctl+0x79/0x90 > do_syscall_64+0x6c/0x1b0 > entry_SYSCALL64_slow_path+0x25/0x25 > > n_tty_flush_buffer--->tty->disc_data is OK > ->reset_buffer_flags -->tty->disc_data is NULL > > Signed-off-by: Yan.Gao > Reviewed-by: Xianting Tian > --- > drivers/tty/n_tty.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c index > 7e5e36315..e78124ce1 100644 > --- a/drivers/tty/n_tty.c > +++ b/drivers/tty/n_tty.c > @@ -1892,8 +1892,10 @@ static void n_tty_close(struct tty_struct *tty) > if (tty->link) > n_tty_packet_mode_flush(tty); > > + down_write(&tty->termios_rwsem); > vfree(ldata); > tty->disc_data = NULL; > + up_write(&tty->termios_rwsem); > } > > /** So does this solve your problem in testing? Do you have a reproducer for this problem? thanks, greg k-h
Re: [PATCH 6/6] iio:pressure:ms5637: add ms5803 support
On 10/12/2020 21:34:13-0600, Rob Herring wrote: > On Thu, Dec 10, 2020 at 12:48:57AM +0100, Alexandre Belloni wrote: > > The ms5803 is very similar to the ms5805 but has less resolution options > > and has the 128bit PROM layout. > > > > Cc: Rob Herring > > Signed-off-by: Alexandre Belloni > > --- > > Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++ > > drivers/iio/pressure/ms5637.c | 8 > > 2 files changed, 10 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml > > b/Documentation/devicetree/bindings/trivial-devices.yaml > > index ab623ba930d5..84b0e44235c1 100644 > > --- a/Documentation/devicetree/bindings/trivial-devices.yaml > > +++ b/Documentation/devicetree/bindings/trivial-devices.yaml > > @@ -132,6 +132,8 @@ properties: > >- mcube,mc3230 > > # MEMSIC 2-axis 8-bit digital accelerometer > >- memsic,mxc6225 > > +# Measurement Specialities I2C pressure and temperature sensor > > + - meas,ms5803 > > Alphabetical order please. Ah, this was my intention, it will conflict with the togreg branch of iio.git anyway. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
[GIT PULL] extcon next for v5.11
Dear Greg, This is extcon-next pull request for v5.11. I add detailed description of this pull request on below. Please pull extcon with following updates. Best Regards, Chanwoo Choi The following changes since commit 0477e92881850d44910a7e94fc2c46f96faa131f: Linux 5.10-rc7 (2020-12-06 14:25:12 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git tags/extcon-next-for-5.11 for you to fetch changes up to e1efdb604f5c9903a5d92ef42244009d3c04880f: extcon: max77693: Fix modalias string (2020-12-11 17:18:10 +0900) Update for extcon-next v5.11 1. Add new TI TUSB320 USB-C extcon driver - The extcon-usbc-tusb320.c driver for the TI TUSB320 USB Type-C device support the USB Type C connector detection. 2. Rewrite binding document in yaml for extcon-fsa9480.c and add new compatible name of TI TSU6111 device. 3. Fix moalias string of extcon-max77693.c to fix the automated module loading when this driver is compiled as a module. Linus Walleij (2): extcon: fsa9480: Rewrite bindings in YAML and extend extcon: fsa9480: Support TI TSU6111 variant Marek Szyprowski (1): extcon: max77693: Fix modalias string Michael Auchter (2): extcon: Add driver for TI TUSB320 dt-bindings: extcon: add binding for TUSB320 .../devicetree/bindings/extcon/extcon-fsa9480.txt | 21 --- .../bindings/extcon/extcon-usbc-tusb320.yaml | 41 + .../devicetree/bindings/extcon/fcs,fsa880.yaml | 52 ++ drivers/extcon/Kconfig | 8 + drivers/extcon/Makefile| 1 + drivers/extcon/extcon-fsa9480.c| 1 + drivers/extcon/extcon-max77693.c | 2 +- drivers/extcon/extcon-usbc-tusb320.c | 184 + 8 files changed, 288 insertions(+), 22 deletions(-) delete mode 100644 Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-usbc-tusb320.yaml create mode 100644 Documentation/devicetree/bindings/extcon/fcs,fsa880.yaml create mode 100644 drivers/extcon/extcon-usbc-tusb320.c
Re: [PATCH] spi: dt-bindings: clarify CS behavior for spi-cs-high and gpio descriptors
On Wed, Dec 9, 2020 at 11:01 AM H. Nikolaus Schaller wrote: > Behavior of CS signal in combination of spi-cs-high and gpio descriptors > is not clearly defined and documented. So clarify the documentation > > Cc: linus.wall...@linaro.org > Cc: linux-g...@vger.kernel.org > Signed-off-by: H. Nikolaus Schaller This is good because it is helpful to users. Reviewed-by: Linus Walleij In cases like this I would actually consider to write a bit in the bindings saying "this is inconsistent because we screwed up so be careful", standard bodies usually try to avoid that kind of statements because they have all kind of prestige involved with their work, but we don't so we can just as well admit it. Yours, Linus Walleij
Re: [PATCH] regulator: max14577: Add proper module aliases strings
On 12/10/20 8:21 PM, Marek Szyprowski wrote:
> Add proper modalias structures to let this driver load automatically if
> compiled as module, because max14577 MFD driver creates MFD cells with
> such compatible strings.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/regulator/max14577-regulator.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/regulator/max14577-regulator.c
> b/drivers/regulator/max14577-regulator.c
> index e34face736f4..1d78b455cc48 100644
> --- a/drivers/regulator/max14577-regulator.c
> +++ b/drivers/regulator/max14577-regulator.c
> @@ -269,3 +269,5 @@ module_exit(max14577_regulator_exit);
> MODULE_AUTHOR("Krzysztof Kozlowski ");
> MODULE_DESCRIPTION("Maxim 14577/77836 regulator driver");
> MODULE_LICENSE("GPL");
> +MODULE_ALIAS("platform:max14577-regulator");
> +MODULE_ALIAS("platform:max77836-regulator");
>
Reviewed-by: Chanwoo Choi
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 2/3] rwsem: Implement down_read_interruptible
On Thu, Dec 10, 2020 at 01:33:25PM -0600, Eric W. Biederman wrote:
> Peter Zijlstra writes:
>
> > On Tue, Dec 08, 2020 at 12:27:39PM -0600, Eric W. Biederman wrote:
> >> Peter Zijlstra writes:
> >>
> >> > On Mon, Dec 07, 2020 at 09:56:34AM -0600, Eric W. Biederman wrote:
> >> >
> >> >> Do you want to pull these two into a topic branch in the tip tree
> >> >> based on v10-rc1?
> >> >
> >> > I'll go do that. I'll let the robots chew on it before pushing it out
> >> > though, I'll reply once it's in tip.git.
> >>
> >> Thanks,
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/rwsem
>
> Is that branch supposed to be against 34816d20f173
> ("Merge tag 'gfs2-v5.10-rc5-fixes' of
> git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2")
That's what it looks like indeed. IIRC my script was supposed to pick
the most recent -rc when creating new branches, but then I've no idea
how I ended up on this. I'll go dig..
> If so I can live with that, but it is a little awkward to work with a
> base that recent. As all of my other branches have an older base.
I missed you explicitly requested -rc1, sorry about that :/
Re: [PATCH v2] Serial: silabs si4455 serial driver
On Fri, Dec 11, 2020 at 08:33:17AM +0100, 'Greg Kroah-Hartman' wrote:
> On Fri, Dec 11, 2020 at 06:37:52AM +, József Horváth wrote:
> > On Fri, Dec 11, 2020 at 07:20:41AM +0100, 'Greg Kroah-Hartman' wrote:
> > > On Fri, Dec 11, 2020 at 06:09:43AM +, József Horváth wrote:
> > > > On Fri, Dec 11, 2020 at 06:50:58AM +0100, 'Greg Kroah-Hartman' wrote:
> > > > > On Thu, Dec 10, 2020 at 07:46:25PM +, József Horváth wrote:
> > > > > > On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman'
> > > > > > wrote:
> > > > > > > On Thu, Dec 10, 2020 at 05:04:46PM +, József Horváth wrote:
> > > > > > > > This is a serial port driver for
> > > > > > > > Silicon Labs Si4455 Sub-GHz transciver.
> > > > > > > > +
> > > > > > > > +#define BASE_TTYIOC_PRIVATE0xA0
> > > > > > > > +/* Set EZConfig.
> > > > > > > > + * After this ioctl call, the driver restarts the si4455,
> > > > > > > > + * then apply the new configuration and patch.
> > > > > > > > + */
> > > > > > > > +#define SI4455_IOC_SEZC_IOW('T', \
> > > > > > > > +BASE_TTYIOC_PRIVATE +
> > > > > > > > 0x01, \
> > > > > > > > +struct si4455_iocbuff)
> > > > > > >
> > > > > > > Why does a serial driver have private ioctls? Please no, don't
> > > > > > > do that.
> > > > > >
> > > > > > I checked the ioctl.h and serial_core.h, but I not found any
> > > > > > similar definition, like BASE_VIDIOC_PRIVATE in videodev2.h.
> > > > > > In this case the name of macro BASE_TTYIOC_PRIVATE means the base
> > > > > > value of special ioctl commands owned by this driver.
> > > > >
> > > > > My point is, a serial driver should NOT have any custom ioctls.
> > > > >
> > > > > > I can change it to BASE_TTYIOC or SI4455_IOC_BASE
> > > > > >
> > > > > > > Implement the basic serial driver first, and then we can talk
> > > > > > > about
> > > > > > > "custom" configurations and the like, using the correct apis.
> > > > > >
> > > > > > Without the SI4455_IOC_SEZC call, the driver can't configure the
> > > > > > Si4455 and not working at all.
> > > > > > The cofiguration for interface is provided by user for application.
> > > > >
> > > > > That is what a device tree is for, to configure the device to have the
> > > > > correct system configuration, why can't that be the same here?
> > > > >
> > > > > > It contains the base frequency, channel spacing, modulation, and a
> > > > > > lot
> > > > > > of more stuff, and generated by Silicon Labs Wireless Development
> > > > > > Suite.
> > > > > > The generated configuration is in a non public(compressed,
> > > > > > encrypted...who knows) format, so without this the driver can't
> > > > > > provide configuration parameters to Si4455.
> > > > >
> > > > > So we have to take a "custom" userspace blob and send it to the device
> > > > > to configure it properly? Like Jiri said, sounds like firmware, so
> > > > > just
> > > > > use that interface instead.
> > > >
> > > > I checked Jiri's suggestion, and it is a good solution to replace
> > > > SI4455_IOC_SEZC(configuration) and SI4455_IOC_SEZP(firmware patch).
> > > > I can move SI4455_IOC_SSIZ(package size) to device tree property.
> > > >
> > > > Maybe you have good suggestion for the following:
> > > > SI4455_IOC_STXC -> Radio transmit channel index. It is a real use case
> > > > to control this parameter by user at runtime.
> > > > SI4455_IOC_SRXC -> Radio receive channel index. It is a real use case
> > > > to control this parameter by user at runtime.
> > >
> > > These are not serial port things, why would a serial port care about
> > > these?
> >
> > You are right, these are not regular serial port things, but this device is
> > not a regular uart, it is a sub-GHz transciever, digital radio.
> > This driver tries to represent it as a serial port to user.
>
> Is that the correct representation to be using here? Why not act like a
> proper radio device instead? That way you get to use the normal kernel
> apis for radio devices.
In my mind it is absolute a serial device by the application.
>
> > > > SI4455_IOC_GRSSI -> Last measured RSSI, when packet received. This is a
> > > > useful information.
> > > > (Currently I'm the only one user, and I need this :) )
> > >
> > > What is "RSSI"?
> > >
> > > And why not debugfs if it's only debugging stuff?
> >
> > Received signal strength indication, and not only debugging. It is an
> > information for the end user.
>
> How do other radio devices (like wifi controllers) export this
> information to userspace? Don't create custom apis for only a single
> device when the goal of a kernel is to make hardware interfaces all work
> the same as far as userspace is concerned.
I move the package size, tx/rx channel properties to dt as device parameter,
and the user could control these properties in sysfs and get rssi too. Finally
I can remove all custom ioctl commands.
What do you think?
>
> thanks,
Re: [PATCH 00/18] keys: Miscellaneous fixes
On Wed, Dec 09, 2020 at 12:14:24PM +, David Howells wrote:
>
> Hi Jarkko,
>
> I've extended my collection of minor keyrings fixes for the next merge
> window. Anything else I should add (or anything I should drop)?
Looks good to me. I dropped the keys fixes that I had previously in
my tree that I saw in yours.
/Jarkko
>
> The patches can be found on the following branch:
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-fixes
>
> David
> ---
> Alex Shi (2):
> PKCS#7: drop function from kernel-doc pkcs7_validate_trust_one
> certs/blacklist: fix kernel doc interface issue
>
> Alexander A. Klimov (1):
> encrypted-keys: Replace HTTP links with HTTPS ones
>
> David Howells (1):
> certs: Fix blacklist flag type confusion
>
> Denis Efremov (1):
> security/keys: use kvfree_sensitive()
>
> Gabriel Krisman Bertazi (1):
> watch_queue: Drop references to /dev/watch_queue
>
> Gustavo A. R. Silva (1):
> security: keys: Fix fall-through warnings for Clang
>
> Jann Horn (1):
> keys: Remove outdated __user annotations
>
> Krzysztof Kozlowski (1):
> KEYS: asymmetric: Fix kerneldoc
>
> Mickaël Salaün (3):
> certs: Fix blacklisted hexadecimal hash string check
> PKCS#7: Fix missing include
> certs: Replace K{U,G}IDT_INIT() with GLOBAL_ROOT_{U,G}ID
>
> Randy Dunlap (2):
> security: keys: delete repeated words in comments
> crypto: asymmetric_keys: fix some comments in pkcs7_parser.h
>
> Tianjia Zhang (1):
> crypto: public_key: Remove redundant header file from public_key.h
>
> Tom Rix (2):
> KEYS: remove redundant memset
> keys: remove trailing semicolon in macro definition
>
> YueHaibing (1):
> crypto: pkcs7: Use match_string() helper to simplify the code
>
>
> Documentation/security/keys/core.rst | 4 ++--
> certs/blacklist.c| 10 +-
> certs/system_keyring.c | 5 +++--
> crypto/asymmetric_keys/asymmetric_type.c | 6 --
> crypto/asymmetric_keys/pkcs7_parser.h| 5 ++---
> crypto/asymmetric_keys/pkcs7_trust.c | 2 +-
> crypto/asymmetric_keys/pkcs7_verify.c| 9 -
> include/crypto/public_key.h | 1 -
> include/keys/encrypted-type.h| 2 +-
> include/linux/key.h | 5 +++--
> include/linux/verification.h | 2 ++
> samples/Kconfig | 2 +-
> samples/watch_queue/watch_test.c | 2 +-
> security/integrity/ima/ima_mok.c | 3 +--
> security/keys/Kconfig| 8
> security/keys/big_key.c | 9 +++--
> security/keys/key.c | 2 ++
> security/keys/keyctl.c | 2 +-
> security/keys/keyctl_pkey.c | 2 --
> security/keys/keyring.c | 10 +-
> 20 files changed, 45 insertions(+), 46 deletions(-)
>
>
>
[PATCH v3 1/1] net/ipv4/inet_fragment: Batch fqdir destroy works
From: SeongJae Park
For each 'fqdir_exit()' call, a work for destroy of the 'fqdir' is
enqueued. The work function, 'fqdir_work_fn()', internally calls
'rcu_barrier()'. In case of intensive 'fqdir_exit()' (e.g., frequent
'unshare()' systemcalls), this increased contention could result in
unacceptably high latency of 'rcu_barrier()'. This commit avoids such
contention by doing the 'rcu_barrier()' and subsequent lightweight works
in a batched manner using a dedicated singlethread worker, as similar to
that of 'cleanup_net()'.
Signed-off-by: SeongJae Park
---
include/net/inet_frag.h | 1 +
net/ipv4/inet_fragment.c | 45 +---
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index bac79e817776..48cc5795ceda 100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -21,6 +21,7 @@ struct fqdir {
/* Keep atomic mem on separate cachelines in structs that include it */
atomic_long_t mem cacheline_aligned_in_smp;
struct work_struct destroy_work;
+ struct llist_node free_list;
};
/**
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index 10d31733297d..a6fc4afcc323 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -145,12 +145,17 @@ static void inet_frags_free_cb(void *ptr, void *arg)
inet_frag_destroy(fq);
}
-static void fqdir_work_fn(struct work_struct *work)
+static struct workqueue_struct *fqdir_wq;
+static LLIST_HEAD(free_list);
+
+static void fqdir_free_fn(struct work_struct *work)
{
- struct fqdir *fqdir = container_of(work, struct fqdir, destroy_work);
- struct inet_frags *f = fqdir->f;
+ struct llist_node *kill_list;
+ struct fqdir *fqdir, *tmp;
+ struct inet_frags *f;
- rhashtable_free_and_destroy(&fqdir->rhashtable, inet_frags_free_cb,
NULL);
+ /* Atomically snapshot the list of fqdirs to free */
+ kill_list = llist_del_all(&free_list);
/* We need to make sure all ongoing call_rcu(..., inet_frag_destroy_rcu)
* have completed, since they need to dereference fqdir.
@@ -158,12 +163,38 @@ static void fqdir_work_fn(struct work_struct *work)
*/
rcu_barrier();
- if (refcount_dec_and_test(&f->refcnt))
- complete(&f->completion);
+ llist_for_each_entry_safe(fqdir, tmp, kill_list, free_list) {
+ f = fqdir->f;
+ if (refcount_dec_and_test(&f->refcnt))
+ complete(&f->completion);
- kfree(fqdir);
+ kfree(fqdir);
+ }
}
+static DECLARE_WORK(fqdir_free_work, fqdir_free_fn);
+
+static void fqdir_work_fn(struct work_struct *work)
+{
+ struct fqdir *fqdir = container_of(work, struct fqdir, destroy_work);
+
+ rhashtable_free_and_destroy(&fqdir->rhashtable, inet_frags_free_cb,
NULL);
+
+ if (llist_add(&fqdir->free_list, &free_list))
+ queue_work(fqdir_wq, &fqdir_free_work);
+}
+
+static int __init fqdir_wq_init(void)
+{
+ fqdir_wq = create_singlethread_workqueue("fqdir");
+ if (!fqdir_wq)
+ panic("Could not create fqdir workq");
+ return 0;
+}
+
+pure_initcall(fqdir_wq_init);
+
+
int fqdir_init(struct fqdir **fqdirp, struct inet_frags *f, struct net *net)
{
struct fqdir *fqdir = kzalloc(sizeof(*fqdir), GFP_KERNEL);
--
2.17.1
Re: [patch 16/30] mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc
On Thu, Dec 10, 2020 at 8:42 PM Thomas Gleixner wrote: > First of all drivers have absolutely no business to dig into the internals > of an irq descriptor. That's core code and subject to change. All of this > information is readily available to /proc/interrupts in a safe and race > free way. > > Remove the inspection code which is a blatant violation of subsystem > boundaries and racy against concurrent modifications of the interrupt > descriptor. > > Print the irq line instead so the information can be looked up in a sane > way in /proc/interrupts. > > Signed-off-by: Thomas Gleixner > Cc: Linus Walleij > Cc: Lee Jones > Cc: linux-arm-ker...@lists.infradead.org Reviewed-by: Linus Walleij Yours, Linus Walleij
Re: [RESEND PATCH V20 1/3] MAINTAINERS: da7280 updates to the Dialog Semiconductor search terms
On Thu, Nov 26, 2020 at 01:07:39AM +0900, Roy Im wrote: > This patch adds the da7280 bindings doc and driver to the Dialog > Semiconductor support list. > > Signed-off-by: Roy Im > Applied, thank you. -- Dmitry
[PATCH v3 0/1] net: Reduce rcu_barrier() contentions from 'unshare(CLONE_NEWNET)'
From: SeongJae Park On a few of our systems, I found frequent 'unshare(CLONE_NEWNET)' calls make the number of active slab objects including 'sock_inode_cache' type rapidly and continuously increase. As a result, memory pressure occurs. In more detail, I made an artificial reproducer that resembles the workload that we found the problem and reproduce the problem faster. It merely repeats 'unshare(CLONE_NEWNET)' 50,000 times in a loop. It takes about 2 minutes. On 40 CPU cores, 70GB DRAM machine, the available memory continuously reduced in a fast speed (about 120MB per second, 15GB in total within the 2 minutes). Note that the issue don't reproduce on every machine. On my 6 CPU cores machine, the problem didn't reproduce. 'cleanup_net()' and 'fqdir_work_fn()' are functions that deallocate the relevant memory objects. They are asynchronously invoked by the work queues and internally use 'rcu_barrier()' to ensure safe destructions. 'cleanup_net()' works in a batched maneer in a single thread worker, while 'fqdir_work_fn()' works for each 'fqdir_exit()' call in the 'system_wq'. Therefore, 'fqdir_work_fn()' called frequently under the workload and made the contention for 'rcu_barrier()' high. In more detail, the global mutex, 'rcu_state.barrier_mutex' became the bottleneck. I tried making 'rcu_barrier()' and subsequent lightweight works in 'fqdir_work_fn()' to be processed by a dedicated singlethread worker in batch and confirmed it works. After the change, No continuous memory reduction but some fluctuation observed. Nevertheless, the available memory reduction was only up to about 400MB. The following patch is for the change. I think this is the right solution for point fix of this issue, but someone might blame different parts. 1. User: Frequent 'unshare()' calls >From some point of view, such frequent 'unshare()' calls might seem only insane. 2. Global mutex in 'rcu_barrier()' Because of the global mutex, 'rcu_barrier()' callers could wait long even after the callbacks started before the call finished. Therefore, similar issues could happen in another 'rcu_barrier()' usages. Maybe we can use some wait queue like mechanism to notify the waiters when the desired time came. I personally believe applying the point fix for now and making 'rcu_barrier()' improvement in longterm make sense. If I'm missing something or you have different opinion, please feel free to let me know. Patch History - Changes from v2 (https://lore.kernel.org/lkml/20201210080844.23741-1-sjp...@amazon.com/) - Add numbers after the patch (Eric Dumazet) - Make only 'rcu_barrier()' and subsequent lightweight works serialized (Eric Dumazet) Changes from v1 (https://lore.kernel.org/netdev/20201208094529.23266-1-sjp...@amazon.com/) - Keep xmas tree variable ordering (Jakub Kicinski) - Add more numbers (Eric Dumazet) - Use 'llist_for_each_entry_safe()' (Eric Dumazet) SeongJae Park (1): net/ipv4/inet_fragment: Batch fqdir destroy works include/net/inet_frag.h | 1 + net/ipv4/inet_fragment.c | 45 +--- 2 files changed, 39 insertions(+), 7 deletions(-) -- 2.17.1
Re: [RESEND PATCH V20 3/3] Input: new da7280 haptic driver
On Thu, Nov 26, 2020 at 01:07:39AM +0900, Roy Im wrote: > Adds support for the Dialog DA7280 LRA/ERM Haptic Driver with > multiple mode and integrated waveform memory and wideband support. > It communicates via an I2C bus to the device. > > Reviewed-by: Jes Sorensen . > > Signed-off-by: Roy Im Applied with some cosmetic edits, thank you. -- Dmitry
[PATCH v4 0/2] hwspinlock: add sun8i hardware spinlock support
Most of the Allwinner sun8i compatible devices contain a spinlock unit which can be used to sync access to devices shared between the ARM cores and the embedded OpenRisc AR100 core. According to the datasheets at least 32 spinlocks are supported. The implementation supports 32, 64, 128 and 256 spinlock setups, but there is no known SoC yet, which implements more than 32 spinlocks. This driver adds support for this hardware spinlock unit to Linux including all 4 possible setups. The driver reports the found setup via debugfs. It can be build as a builtin and normal module by using the HWSPINLOCK_SUN8I symbol. This driver is the first step to enable hwspinlock support in Linux, but also requires support in the firmware of the OpenRisc core. This patch provides the driver and binding documentation but is not yet included into the sun8i and sun50i dtsi files. Also not every sun8i or sun50i SoC seem to have support for this hardware. For example the H616 is missing the whole spinlock section in the datasheets. The spinlock hardware has two ways to figure out if a lock is taken. The lock can simply be read or bits of a 32bit wide status register can be checked. The status register only supports the first 32 locks and may not cover bigger spinlock setups. Therefore reading/writing a specific spinlock for checking is used in the driver. The status register is now free for debugging/testing purposes and can completely bypass the Linux hwspinlock ABI. This status register will be used in some additional kernel modules to test the hwspinlock driver. Testing the driver. To run all tests it is necessary to take locks on the OpenRisc core and show on the Linux side that the locks were taken by an external event. This can be achived by using the crust firmware. For this the crust firmware needs to be changed to take and release spinlocks (a simple MMIO operation on the hwlock registers), which is currently not supported by the current crust firmware. The necessary crust fork can be found here https://github.com/wgottwalt/crust (hwspinlock branch). It is also necessary to build u-boot with support for this crust/SCP firmware. This u-boot fork can be found here https://github.com/crust-firmware/u-boot (crust branch). For testing this driver it is also necessary to pick a device that is fully supported by the crust firmware. For this the H5 based Friendlyarm NanoPi NEO2 was used, which is fully supported by u-boot (and the fork), the curst firmware (via H5 target) and current Linux kernels. In the crust fork it is necessary to go into debug menu of "make nconfig" and select the hwspinlock test loop. This debug option enables a loop that goes through the first 32 spinlocks. It takes/releases a lock one after another using the timeout functions (and hw timers) of the crust firmware. A timeout can be set in the debug menu. Test 1: This test was done using a mainline u-boot and a crust enabled u-boot. For this a simple second kernel module was used, which can be found here https://github.com/wgottwalt/sunxi_hwspinlock/tree/main/test. Using mainline u-boot it shows that the Linux side correctly takes a lock, tries to recursively take a lock again (which does not happen) and releases a lock. This is done for all 32 locks several times. [ 50.332836] [init]--- SUN8I HWSPINLOCK DRIVER TEST --- [ 50.338155] [run ]--- testing locks 0 to 31 --- [ 50.342725] [test] testing lock 0 [ 50.346075] [test]+++ attempt #0 succeded [ 50.350103] [test]+++ attempt #1 succeded [ 50.354127] [test]+++ attempt #2 succeded [ 50.358154] [test] testing lock 1 [ 50.361474] [test]+++ attempt #0 succeded [ 50.365496] [test]+++ attempt #1 succeded [ 50.369509] [test]+++ attempt #2 succeded ... [ 50.819369] [test] testing lock 31 [ 50.822777] [test]+++ attempt #0 succeded [ 50.826796] [test]+++ attempt #1 succeded [ 50.830816] [test]+++ attempt #2 succeded If the same test is done with the hwspinlock loop enabled crust firmware and the crust enabled u-boot fork, the Linux test kernel module hits the one lock taken by the crust firmware. [ 198.232316] [init]--- SUN8I HWSPINLOCK DRIVER TEST --- [ 198.237616] [run ]--- testing locks 0 to 31 --- [ 198.242170] [test] testing lock 0 [ 198.245493] [test]+++ attempt #0 succeded [ 198.249514] [test]+++ attempt #1 succeded [ 198.253528] [test]+++ attempt #2 succeded ... [ 198.550564] [test] testing lock 20 [ 198.553972] [test]+++ attempt #0 succeded [ 198.557983] [test]+++ attempt #1 succeded [ 198.561998] [test]+++ attempt #2 succeded [ 198.566018] [test] testing lock 21 [ 198.569432] [test] taking lock attempt #0 failed (-16) [ 198.574580] [run ]--- testing specific lock 21 failed (-14) --- [ 198.580505] [test] testing lock 22 [ 198.583918] [test]+++ attempt #0 succeded [ 198.587935] [test]+++ attempt #1 succeded [ 198.591954] [test]+++ attempt #2 succeded ... [ 198.719650] [test] testing lock 31 [ 198.723065] [test]+++ attempt #0 succeded [ 198.727088] [t
[PATCH v2] drm/ast: Fixed CVE for DP501
[Bug][DP501]
If ASPEED P2A (PCI to AHB) bridge is disabled and disallowed for
CVE_2019_6260 item3, and then the monitor's EDID is unable read through
Parade DP501.
The reason is the DP501's FW is mapped to BMC addressing space rather
than Host addressing space.
The resolution is that using "pci_iomap_range()" maps to DP501's FW that
stored on the end of FB (Frame Buffer).
In this case, FrameBuffer reserves the last 2MB used for the image of
DP501.
Signed-off-by: KuoHsiang Chou
---
drivers/gpu/drm/ast/ast_dp501.c | 136 +++-
drivers/gpu/drm/ast/ast_drv.h | 12 +++
drivers/gpu/drm/ast/ast_main.c | 8 ++
3 files changed, 120 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_dp501.c b/drivers/gpu/drm/ast/ast_dp501.c
index 88121c0e0d05..aef9bbace99f 100644
--- a/drivers/gpu/drm/ast/ast_dp501.c
+++ b/drivers/gpu/drm/ast/ast_dp501.c
@@ -189,6 +189,9 @@ bool ast_backup_fw(struct drm_device *dev, u8 *addr, u32
size)
u32 i, data;
u32 boot_address;
+ if (ast->config_mode != ast_use_p2a)
+ return false;
+
data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (data) {
boot_address = get_fw_base(ast);
@@ -207,6 +210,9 @@ static bool ast_launch_m68k(struct drm_device *dev)
u8 *fw_addr = NULL;
u8 jreg;
+ if (ast->config_mode != ast_use_p2a)
+ return false;
+
data = ast_mindwm(ast, 0x1e6e2100) & 0x01;
if (!data) {
@@ -271,25 +277,55 @@ u8 ast_get_dp501_max_clk(struct drm_device *dev)
struct ast_private *ast = to_ast_private(dev);
u32 boot_address, offset, data;
u8 linkcap[4], linkrate, linklanes, maxclk = 0xff;
+ u32 *plinkcap;
- boot_address = get_fw_base(ast);
-
- /* validate FW version */
- offset = 0xf000;
- data = ast_mindwm(ast, boot_address + offset);
- if ((data & 0xf0) != 0x10) /* version: 1x */
- return maxclk;
-
- /* Read Link Capability */
- offset = 0xf014;
- *(u32 *)linkcap = ast_mindwm(ast, boot_address + offset);
- if (linkcap[2] == 0) {
- linkrate = linkcap[0];
- linklanes = linkcap[1];
- data = (linkrate == 0x0a) ? (90 * linklanes) : (54 * linklanes);
- if (data > 0xff)
- data = 0xff;
- maxclk = (u8)data;
+ if (ast->config_mode == ast_use_p2a) {
+ boot_address = get_fw_base(ast);
+
+ /* validate FW version */
+ offset = AST_DP501_GBL_VERSION;
+ data = ast_mindwm(ast, boot_address + offset);
+ if ((data & AST_DP501_FW_VERSION_MASK) !=
AST_DP501_FW_VERSION_1) /* version: 1x */
+ return maxclk;
+
+ /* Read Link Capability */
+ offset = AST_DP501_LINKRATE;
+ plinkcap = (u32 *)linkcap;
+ *plinkcap = ast_mindwm(ast, boot_address + offset);
+ if (linkcap[2] == 0) {
+ linkrate = linkcap[0];
+ linklanes = linkcap[1];
+ data = (linkrate == 0x0a) ? (90 * linklanes) : (54 *
linklanes);
+ if (data > 0xff)
+ data = 0xff;
+ maxclk = (u8)data;
+ }
+ } else {
+ if (!ast->dp501_fw_buf)
+ return AST_DP501_DEFAULT_DCLK; /* 1024x768 as default
*/
+
+ /* dummy read */
+ offset = 0x;
+ data = readl(ast->dp501_fw_buf + offset);
+
+ /* validate FW version */
+ offset = AST_DP501_GBL_VERSION;
+ data = readl(ast->dp501_fw_buf + offset);
+ if ((data & AST_DP501_FW_VERSION_MASK) !=
AST_DP501_FW_VERSION_1) /* version: 1x */
+ return maxclk;
+
+ /* Read Link Capability */
+ offset = AST_DP501_LINKRATE;
+ plinkcap = (u32 *)linkcap;
+ *plinkcap = readl(ast->dp501_fw_buf + offset);
+ if (linkcap[2] == 0) {
+ linkrate = linkcap[0];
+ linklanes = linkcap[1];
+ data = (linkrate == 0x0a) ? (90 * linklanes) : (54 *
linklanes);
+ if (data > 0xff)
+ data = 0xff;
+ maxclk = (u8)data;
+ }
}
return maxclk;
}
@@ -299,25 +335,53 @@ bool ast_dp501_read_edid(struct drm_device *dev, u8
*ediddata)
struct ast_private *ast = to_ast_private(dev);
u32 i, boot_address, offset, data;
- boot_address = get_fw_base(ast);
-
- /* validate FW version */
- offset = 0xf000;
- data = ast_mindwm(ast, boot_address + offset);
- if ((data & 0xf0) != 0x10)
- return false;
-
- /* validate PnP Monitor */
- offset = 0xf010;
[PATCH v4 2/2] hwspinlock: add sun8i hardware spinlock support
Adds the sun8i_hwspinlock driver for the hardware spinlock unit found in
most of the sun8i compatible SoCs.
This unit provides at least 32 spinlocks in hardware. The implementation
supports 32, 64, 128 or 256 32bit registers. A lock can be taken by
reading a register and released by writing a 0 to it. This driver
supports all 4 spinlock setups, but for now only the first setup (32
locks) seem to exist in available devices. This spinlock unit is shared
between all ARM cores and the embedded OpenRisc AR100 core. All of them
can take/release a lock with a single cycle operation. It can be used to
sync access to devices shared by the ARM cores and the OpenRisc core.
There are two ways to check if a lock is taken. The first way is to read
a lock. If a 0 is returned, the lock was free and is taken now. If an 1
is returned, the caller has to try again. Which means the lock is taken.
The second way is to read a 32bit wide status register where every bit
represents one of the 32 first locks. According to the datasheets this
status register supports only the 32 first locks. This is the reason the
first way (lock read/write) approach is used to be able to cover all 256
locks in future devices. The driver also reports the amount of supported
locks via debugfs.
Signed-off-by: Wilken Gottwalt
---
Changes in v4:
- further simplified driver
- fixed an add_action_and_reset_ function issue
- changed bindings from sun8i-hwspinlock to sun8i-a33-hwspinlock
Changes in v3:
- moved test description to cover letter
- changed name and symbols from sunxi to sun8i
- improved driver description
- further simplified driver
- fully switched to devm_* and devm_add_action_* functions
Changes in v2:
- added suggestions from Bjorn Andersson and Maxime Ripard
- provided better driver and test description
---
MAINTAINERS | 6 +
drivers/hwspinlock/Kconfig| 9 ++
drivers/hwspinlock/Makefile | 1 +
drivers/hwspinlock/sun8i_hwspinlock.c | 197 ++
4 files changed, 213 insertions(+)
create mode 100644 drivers/hwspinlock/sun8i_hwspinlock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index ebe4829cdd4d..46846113f1eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -722,6 +722,12 @@ L: linux-cry...@vger.kernel.org
S: Maintained
F: drivers/crypto/allwinner/
+ALLWINNER HARDWARE SPINLOCK SUPPORT
+M: Wilken Gottwalt
+S: Maintained
+F: Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
+F: drivers/hwspinlock/sun8i_hwspinlock.c
+
ALLWINNER THERMAL DRIVER
M: Vasily Khoruzhick
M: Yangtao Li
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 32cd26352f38..b03fd99aab32 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -55,6 +55,15 @@ config HWSPINLOCK_STM32
If unsure, say N.
+config HWSPINLOCK_SUN8I
+ tristate "SUN8I Hardware Spinlock device"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ help
+ Say y here to support the SUN8I Hardware Spinlock device which can be
+ found in most of the sun8i compatible Allwinner SoCs.
+
+ If unsure, say N.
+
config HSEM_U8500
tristate "STE Hardware Semaphore functionality"
depends on ARCH_U8500 || COMPILE_TEST
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index ed053e3f02be..3496648d9257 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_HWSPINLOCK_QCOM) += qcom_hwspinlock.o
obj-$(CONFIG_HWSPINLOCK_SIRF) += sirf_hwspinlock.o
obj-$(CONFIG_HWSPINLOCK_SPRD) += sprd_hwspinlock.o
obj-$(CONFIG_HWSPINLOCK_STM32) += stm32_hwspinlock.o
+obj-$(CONFIG_HWSPINLOCK_SUN8I) += sun8i_hwspinlock.o
obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o
diff --git a/drivers/hwspinlock/sun8i_hwspinlock.c
b/drivers/hwspinlock/sun8i_hwspinlock.c
new file mode 100644
index ..878dae6f1763
--- /dev/null
+++ b/drivers/hwspinlock/sun8i_hwspinlock.c
@@ -0,0 +1,197 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * sun8i_hwspinlock.c - hardware spinlock driver for sun8i compatible
Allwinner SoCs
+ * Copyright (C) 2020 Wilken Gottwalt
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "hwspinlock_internal.h"
+
+#define DRIVER_NAME"sun8i_hwspinlock"
+
+#define SPINLOCK_BASE_ID 0 /* there is only one hwspinlock device per
SoC */
+#define SPINLOCK_SYSSTATUS_REG 0x
+#define SPINLOCK_LOCK_REGN 0x0100
+#define SPINLOCK_NOTTAKEN 0
+
+struct sun8i_hwspinlock_data {
+ struct hwspinlock_device *bank;
+ struct reset_control *reset;
+ struct clk *ahb_clk;
+ struct dentry *debugfs;
+ int nlocks;
+};
+
+#ifdef CONFIG_DEBUG_FS
+
+static int hwlocks_supported_show(struct seq_file *seqf, void *unused)
+{
Re: [RESEND PATCH V20 2/3] dt-bindings: input: Add document bindings for DA7280
On Thu, Nov 26, 2020 at 01:07:39AM +0900, Roy Im wrote: > Add device tree binding information for DA7280 haptic driver. > Example bindings for DA7280 are added. > > Reviewed-by: Rob Herring . > > Signed-off-by: Roy Im > Applied, thank you. -- Dmitry
Re: [PATCH 03/22] keembay-ipc: Add Keem Bay IPC module
On Thu, Dec 10, 2020 at 06:38:24PM +, Daniele Alessandrelli wrote:
> On Tue, 2020-12-08 at 20:48 +0100, Greg KH wrote:
> > On Tue, Dec 08, 2020 at 06:59:09PM +, Daniele Alessandrelli wrote:
> > > Hi Greg,
> > >
> > > Thanks for your feedback.
> > >
> > > On Wed, 2020-12-02 at 07:19 +0100, Greg KH wrote:
> > > > On Tue, Dec 01, 2020 at 02:34:52PM -0800, mgr...@linux.intel.com wrote:
> > > > > From: Daniele Alessandrelli
> > > > >
> > > > > On the Intel Movidius SoC code named Keem Bay, communication between
> > > > > the
> > > > > Computing Sub-System (CSS), i.e., the CPU, and the Multimedia
> > > > > Sub-System
> > > > > (MSS), i.e., the VPU is enabled by the Keem Bay Inter-Processor
> > > > > Communication (IPC) mechanism.
> > > > >
> > > > > Add the driver for using Keem Bay IPC from within the Linux Kernel.
> > > > >
> > > > > Keem Bay IPC uses the following terminology:
> > > > >
> > > > > - Node:A processing entity that can use the IPC to communicate;
> > > > > currently, we just have two nodes, CPU (CSS) and VPU (MSS).
> > > > >
> > > > > - Link:Two nodes that can communicate over IPC form an IPC link
> > > > > (currently, we just have one link, the one between the CPU
> > > > > and VPU).
> > > > >
> > > > > - Channel: An IPC link can provide multiple IPC channels. IPC channels
> > > > > allow communication multiplexing, i.e., the same IPC link can
> > > > > be used by different applications for different
> > > > > communications. Each channel is identified by a channel ID,
> > > > > which must be unique within a single IPC link. Channels are
> > > > > divided in two categories, High-Speed (HS) channels and
> > > > > General-Purpose (GP) channels. HS channels have higher
> > > > > priority over GP channels.
> > > > >
> > > > > Keem Bay IPC mechanism is based on shared memory and hardware FIFOs.
> > > > > Both the CPU and the VPU have their own hardware FIFO. When the CPU
> > > > > wants to send an IPC message to the VPU, it writes to the VPU FIFO
> > > > > (MSS
> > > > > FIFO); similarly, when MSS wants to send an IPC message to the CPU, it
> > > > > writes to the CPU FIFO (CSS FIFO).
> > > > >
> > > > > A FIFO entry is simply a pointer to an IPC buffer (aka IPC header)
> > > > > stored in a portion of memory shared between the CPU and the VPU.
> > > > > Specifically, the FIFO entry contains the (VPU) physical address of
> > > > > the
> > > > > IPC buffer being transferred.
> > > > >
> > > > > In turn, the IPC buffer contains the (VPU) physical address of the
> > > > > payload (which must be located in shared memory too) as well as other
> > > > > information (payload size, IPC channel ID, etc.).
> > > > >
> > > > > Each IPC node instantiates a pool of IPC buffers from its own IPC
> > > > > buffer
> > > > > memory region. When instantiated, IPC buffers are marked as free. When
> > > > > the node needs to send an IPC message, it gets the first free buffer
> > > > > it
> > > > > finds (from its own pool), marks it as allocated (used), and puts its
> > > > > physical address into the IPC FIFO of the destination node. The
> > > > > destination node (which is notified by an interrupt when there are
> > > > > entries pending in its FIFO) extract the physical address from the
> > > > > FIFO
> > > > > and process the IPC buffer, marking it as free once done (so that the
> > > > > sender can reuse the buffer).
> > > >
> > > > Any reason you can't use the dmabuf interface for these memory buffers
> > > > you are creating and having to manage "by hand"? I thought that was
> > > > what the kernel was wanting to unify on such that individual
> > > > drivers/subsystems didn't have to do this on their own.
> > >
> > > My understanding is that the dmabuf interface is used to share DMA
> > > buffers across different drivers, while these buffers are used only
> > > internally to the IPC driver (and exchanged only with the VPU
> > > firmware). They basically are packet headers that are sent to the VPU.
> >
> > There's no reason you couldn't use these to share your buffers
> > "internally" as well, because you have the same lifetime rules and
> > accounting and all other sorts of things you have to handle, right? Why
> > rewrite something like this when you should take advantage of common
> > code instead?
>
> I looked at dma-buf again, but I'm still failing to see how we can use
> it in this driver :/
>
> The problem I'm not able to solve is exactly how to match the lifetime
> of this IPC packets (IPC buffers is probably a misleading name, my bad
> for using it in the code) with the dma-buf lifetime rules.
>
> Basically, these IPC packets are cache-aligned (64 bytes) and have the
> following fixed structure:
>
>struct kmb_ipc_buf {
> u32 data_addr;
> u32 data_size;
> u16 channel;
> u8 src_node;
> u8 dst_node;
> u8 statu
Re: [PATCH] Input: cyapa - do not call input_device_enabled from power mode handler
On 11.12.2020 08:09, Dmitry Torokhov wrote:
> Input device's user counter is supposed to be accessed only while holding
> input->mutex. Commit d69f0a43c677 ("Input: use input_device_enabled()")
> recently switched cyapa to using the dedicated API and it uncovered the
> fact that cyapa driver violated this constraint.
>
> This patch removes checks whether the input device is open when clearing
> device queues when changing device's power mode as there is no harm in
> sending input events through closed input device - the events will simply
> be dropped by the input core.
>
> Note that there are more places in cyapa driver that call
> input_device_enabled() without holding input->mutex, those are left
> unfixed for now.
>
> Reported-by: Marek Szyprowski
> Signed-off-by: Dmitry Torokhov
> ---
>
> Marek, could you please try this one?
The warning is still there:
[ cut here ]
WARNING: CPU: 1 PID: 1787 at drivers/input/input.c:2230
input_device_enabled+0x68/0x6c
Modules linked in: cmac bnep mwifiex_sdio mwifiex sha256_generic
libsha256 sha256_arm btmrvl_sdio btmrvl cfg80211 bluetooth s5p_mfc
exynos_gsc v4l2_mem2mem videob
CPU: 1 PID: 1787 Comm: rtcwake Not tainted
5.10.0-rc7-next-20201210-1-g70a81f43fddf #2204
Hardware name: Samsung Exynos (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xb4/0xd4)
[] (dump_stack) from [] (__warn+0xd8/0x11c)
[] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8)
[] (warn_slowpath_fmt) from []
(input_device_enabled+0x68/0x6c)
[] (input_device_enabled) from []
(cyapa_reinitialize+0x4c/0x154)
[] (cyapa_reinitialize) from [] (cyapa_resume+0x48/0x98)
[] (cyapa_resume) from [] (dpm_run_callback+0xb0/0x3c8)
[] (dpm_run_callback) from [] (device_resume+0xbc/0x260)
[] (device_resume) from [] (dpm_resume+0x14c/0x51c)
[] (dpm_resume) from [] (dpm_resume_end+0xc/0x18)
[] (dpm_resume_end) from []
(suspend_devices_and_enter+0x1b4/0xbd4)
[] (suspend_devices_and_enter) from []
(pm_suspend+0x314/0x42c)
[] (pm_suspend) from [] (state_store+0x6c/0xc8)
[] (state_store) from [] (kernfs_fop_write+0x10c/0x228)
[] (kernfs_fop_write) from [] (vfs_write+0xc8/0x530)
[] (vfs_write) from [] (ksys_write+0x60/0xd8)
[] (ksys_write) from [] (ret_fast_syscall+0x0/0x2c)
Exception stack(0xc3923fa8 to 0xc3923ff0)
irq event stamp: 54139
hardirqs last enabled at (54147): [] vprintk_emit+0x2b8/0x308
hardirqs last disabled at (54154): [] vprintk_emit+0x27c/0x308
softirqs last enabled at (50722): [] __do_softirq+0x528/0x684
softirqs last disabled at (50671): [] irq_exit+0x1ec/0x1f8
---[ end trace 1fbefe3f239ae597 ]---
> drivers/input/mouse/cyapa_gen3.c |5 +
> drivers/input/mouse/cyapa_gen5.c |3 +--
> 2 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/input/mouse/cyapa_gen3.c
> b/drivers/input/mouse/cyapa_gen3.c
> index a97f4acb6452..4a9022faf945 100644
> --- a/drivers/input/mouse/cyapa_gen3.c
> +++ b/drivers/input/mouse/cyapa_gen3.c
> @@ -907,7 +907,6 @@ static u16 cyapa_get_wait_time_for_pwr_cmd(u8 pwr_mode)
> static int cyapa_gen3_set_power_mode(struct cyapa *cyapa, u8 power_mode,
> u16 always_unused, enum cyapa_pm_stage pm_stage)
> {
> - struct input_dev *input = cyapa->input;
> u8 power;
> int tries;
> int sleep_time;
> @@ -953,7 +952,6 @@ static int cyapa_gen3_set_power_mode(struct cyapa *cyapa,
> u8 power_mode,
>* depending on the command's content.
>*/
> if (cyapa->operational &&
> - input && input_device_enabled(input) &&
> (pm_stage == CYAPA_PM_RUNTIME_SUSPEND ||
>pm_stage == CYAPA_PM_RUNTIME_RESUME)) {
> /* Try to polling in 120Hz, read may fail, just ignore it. */
> @@ -1223,8 +1221,7 @@ static int cyapa_gen3_try_poll_handler(struct cyapa
> *cyapa)
> (data.finger_btn & OP_DATA_VALID) != OP_DATA_VALID)
> return -EINVAL;
>
> - return cyapa_gen3_event_process(cyapa, &data);
> -
> + return cyapa->input ? cyapa_gen3_event_process(cyapa, &data) : 0;
> }
>
> static int cyapa_gen3_initialize(struct cyapa *cyapa) { return 0; }
> diff --git a/drivers/input/mouse/cyapa_gen5.c
> b/drivers/input/mouse/cyapa_gen5.c
> index abf42f77b4c5..afc5aa4dcf47 100644
> --- a/drivers/input/mouse/cyapa_gen5.c
> +++ b/drivers/input/mouse/cyapa_gen5.c
> @@ -518,8 +518,7 @@ int cyapa_empty_pip_output_data(struct cyapa *cyapa,
> *len = length;
> /* Response found, success. */
> return 0;
> - } else if (cyapa->operational &&
> -input && input_device_enabled(input) &&
> + } else if (cyapa->operational && input &&
> (pm_stage == CYAPA_PM_RUNTIME_RESUME ||
> pm_stage == CYAPA_PM_RUNTIME_SUSPEND)) {
> /* Parse the data and report it if it's valid. */
>
Best regards
--
[PATCH v4 1/2] dt-bindings: hwlock: add sun8i_hwspinlock
Adds documentation on how to use the sun8i_hwspinlock driver for sun8i
compatible SoCs.
Signed-off-by: Wilken Gottwalt
---
Changes in v4:
- changed binding to sun8i-a33-hwpinlock
- added changes suggested by Maxime Ripard
Changes in v3:
- changed symbols from sunxi to sun8i
Changes in v2:
- fixed memory ranges
---
.../bindings/hwlock/sun8i-hwspinlock.yaml | 56 +++
1 file changed, 56 insertions(+)
create mode 100644
Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
diff --git a/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
b/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
new file mode 100644
index ..76963d8abd5f
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwlock/sun8i-hwspinlock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SUN8I hardware spinlock driver for Allwinner sun8i compatible SoCs
+
+maintainers:
+ - Wilken Gottwalt
+
+description:
+ The hardware unit provides sempahores between the ARM cores and the embedded
+ OpenRisc core on the SoC.
+
+properties:
+ compatible:
+const: allwinner,sun8i-a33-hwspinlock
+
+reg:
+ maxItems: 1
+
+clocks:
+ maxItems: 1
+
+clock-names:
+ items:
+- const: ahb
+
+resets:
+ maxItems: 1
+
+reset-names:
+ items:
+- const: ahb
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - resets
+ - reset-names
+
+additionalProperties: false
+
+examples:
+ - |
+hwspinlock@1c18000 {
+ compatible = "allwinner,sun8i-a33-hwspinlock";
+ reg = <0x01c18000 0x1000>;
+ clocks = <&ccu CLK_BUS_SPINLOCK>;
+ clock-names = "ahb";
+ resets = <&ccu RST_BUS_SPINLOCK>;
+ reset-names = "ahb";
+};
--
2.29.2
Re: [PATCH 0/5] USB: typec: various patches
On Thu, Dec 10, 2020 at 05:05:16PM +0100, Greg Kroah-Hartman wrote: > In digging through a large set of proposed typec patches for the Android > common kernel, I've picked out 5 "easy" patches that should all go > upstream (they all should go upstream, just will take a while to clean > them up it seems...) Cool. Is there already support for the new Enter_USB message? Badhri, maybe you know more about this, if somebody is working on that or not? FWIW, for all except the first patch 1/5: Acked-by: Heikki Krogerus > Badhri Jagan Sridharan (2): > USB: typec: tcpm: Prevent log overflow by removing old entries > USB: typec: tcpci: Add Bleed discharge to POWER_CONTROL definition > > Kyle Tso (2): > USB: typec: tcpm: Fix PR_SWAP error handling > USB: typec: tcpm: Add a 30ms room for tPSSourceOn in PR_SWAP > > pumahsu (1): > USB: typec: tcpm: Hard Reset after not receiving a Request > > drivers/usb/typec/tcpm/tcpci.h | 1 + > drivers/usb/typec/tcpm/tcpm.c | 30 +++--- > include/linux/usb/pd.h | 1 + > 3 files changed, 17 insertions(+), 15 deletions(-) > > -- > 2.29.2 thanks, -- heikki
Re: [PATCH] Input: cyapa - do not call input_device_enabled from power mode handler
On Fri, Dec 11, 2020 at 09:22:44AM +0100, Marek Szyprowski wrote:
>
> On 11.12.2020 08:09, Dmitry Torokhov wrote:
> > Input device's user counter is supposed to be accessed only while holding
> > input->mutex. Commit d69f0a43c677 ("Input: use input_device_enabled()")
> > recently switched cyapa to using the dedicated API and it uncovered the
> > fact that cyapa driver violated this constraint.
> >
> > This patch removes checks whether the input device is open when clearing
> > device queues when changing device's power mode as there is no harm in
> > sending input events through closed input device - the events will simply
> > be dropped by the input core.
> >
> > Note that there are more places in cyapa driver that call
> > input_device_enabled() without holding input->mutex, those are left
> > unfixed for now.
> >
> > Reported-by: Marek Szyprowski
> > Signed-off-by: Dmitry Torokhov
> > ---
> >
> > Marek, could you please try this one?
>
> The warning is still there:
Ah, yes, we are hitting another instance right after setting power mode.
I need to think more how to handle that one.
Thanks.
--
Dmitry
[PATCH] media: dvbdev: Fix memory leak in dvb_media_device_free()
dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn`
before setting it to NULL, as documented in include/media/media-device.h:
"The media_entity instance itself must be freed explicitly by the driver
if required."
Cc: sta...@vger.kernel.org
Fixes: 0230d60e4661 ("[media] dvbdev: Add RF connector if needed")
Reported-by: syzbot+7f09440acc069a0d3...@syzkaller.appspotmail.com
Link:
https://syzkaller.appspot.com/bug?id=9bbe4b842c98f0ed05c5eed77a226e9de33bf298
Signed-off-by: Peilin Ye
---
drivers/media/dvb-core/dvbdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
index 959fa2820259..ec9ebff28552 100644
--- a/drivers/media/dvb-core/dvbdev.c
+++ b/drivers/media/dvb-core/dvbdev.c
@@ -241,6 +241,7 @@ static void dvb_media_device_free(struct dvb_device *dvbdev)
if (dvbdev->adapter->conn) {
media_device_unregister_entity(dvbdev->adapter->conn);
+ kfree(dvbdev->adapter->conn);
dvbdev->adapter->conn = NULL;
kfree(dvbdev->adapter->conn_pads);
dvbdev->adapter->conn_pads = NULL;
--
2.25.1
Re: [RFC PATCH 10/11] mm/filemap: Add folio_add_to_page_cache
On 8.12.20 г. 21:46 ч., Matthew Wilcox (Oracle) wrote:
> Pages being added to the page cache should already be folios, so
> turn add_to_page_cache_lru() into a wrapper. Saves hundreds of
> bytes of text.
>
> Signed-off-by: Matthew Wilcox (Oracle)
> ---
> include/linux/pagemap.h | 13 +++--
> mm/filemap.c| 62 -
> 2 files changed, 41 insertions(+), 34 deletions(-)
>
> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> index 060faeb8d701..3bc56b3aa384 100644
> --- a/include/linux/pagemap.h
> +++ b/include/linux/pagemap.h
> @@ -778,9 +778,9 @@ static inline int fault_in_pages_readable(const char
> __user *uaddr, int size)
> }
>
> int add_to_page_cache_locked(struct page *page, struct address_space
> *mapping,
> - pgoff_t index, gfp_t gfp_mask);
> -int add_to_page_cache_lru(struct page *page, struct address_space *mapping,
> - pgoff_t index, gfp_t gfp_mask);
> + pgoff_t index, gfp_t gfp);
> +int folio_add_to_page_cache(struct folio *folio, struct address_space
> *mapping,
> + pgoff_t index, gfp_t gfp);
> extern void delete_from_page_cache(struct page *page);
> extern void __delete_from_page_cache(struct page *page, void *shadow);
> int replace_page_cache_page(struct page *old, struct page *new, gfp_t
> gfp_mask);
> @@ -805,6 +805,13 @@ static inline int add_to_page_cache(struct page *page,
> return error;
> }
>
> +static inline int add_to_page_cache_lru(struct page *page,
> + struct address_space *mapping, pgoff_t index, gfp_t gfp)
> +{
> + return folio_add_to_page_cache((struct folio *)page, mapping,
> + index, gfp);
> +}
> +
> /**
> * struct readahead_control - Describes a readahead request.
> *
> diff --git a/mm/filemap.c b/mm/filemap.c
> index 56ff6aa24265..297144524f58 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -828,25 +828,25 @@ int replace_page_cache_page(struct page *old, struct
> page *new, gfp_t gfp_mask)
> }
> EXPORT_SYMBOL_GPL(replace_page_cache_page);
>
> -static noinline int __add_to_page_cache_locked(struct page *page,
> +static noinline int __add_to_page_cache_locked(struct folio *folio,
> struct address_space *mapping,
> - pgoff_t offset, gfp_t gfp,
> + pgoff_t index, gfp_t gfp,
> void **shadowp)
> {
> - XA_STATE(xas, &mapping->i_pages, offset);
> - int huge = PageHuge(page);
> + XA_STATE(xas, &mapping->i_pages, index);
> + int huge = PageHuge(&folio->page);
PageHuge also does page_compound, since you know this is either the head
page or not you could use PageHeadHuge which simply checks if it's a
head page and then goes directly to perform the hugepage check via the
dtor.
[PATCH RFC v2] docs: experimental: build PDF with rst2pdf
Add an experimental PDF builder using rst2pdf
Signed-off-by: Mauro Carvalho Chehab
---
Please notice that 18 documents (of a total of 71) won't build with
rst2pdf. There's an opened issue about that at:
https://github.com/rst2pdf/rst2pdf/issues/958
v2: usage of SPHINXDIRS was fixed.
Documentation/Makefile | 5 +
Documentation/conf.py | 21 +++--
Documentation/sphinx/load_config.py| 12
Documentation/userspace-api/media/Makefile | 1 +
Makefile | 4 ++--
5 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 61a7310b49e0..c3c8fb10f94e 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -115,6 +115,10 @@ pdfdocs: latexdocs
endif # HAVE_PDFLATEX
+rst2pdf:
+ @$(srctree)/scripts/sphinx-pre-install --version-check
+ @+$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,pdf,$(var),pdf,$(var)))
+
epubdocs:
@$(srctree)/scripts/sphinx-pre-install --version-check
@+$(foreach var,$(SPHINXDIRS),$(call
loop_cmd,sphinx,epub,$(var),epub,$(var)))
@@ -140,6 +144,7 @@ dochelp:
@echo ' htmldocs- HTML'
@echo ' latexdocs - LaTeX'
@echo ' pdfdocs - PDF'
+ @echo ' rst2pdf - PDF, using experimental rst2pdf support'
@echo ' epubdocs- EPUB'
@echo ' xmldocs - XML'
@echo ' linkcheckdocs - check for broken external links'
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 66e121df59cd..6f2788aac81e 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -123,6 +123,12 @@ if (major == 1 and minor > 3) or (major > 1):
else:
extensions.append("sphinx.ext.pngmath")
+# Enable experimental rst2pdf, if available
+try:
+extensions.append("rst2pdf.pdfbuilder")
+except:
+sys.stderr.write('rst2pdf extension not available.\n')
+
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
@@ -614,12 +620,15 @@ epub_exclude_files = ['search.html']
#
# See the Sphinx chapter of https://ralsina.me/static/manual.pdf
#
-# FIXME: Do not add the index file here; the result will be too big. Adding
-# multiple PDF files here actually tries to get the cross-referencing right
-# *between* PDF files.
-pdf_documents = [
-('kernel-documentation', u'Kernel', u'Kernel', u'J. Random Bozo'),
-]
+
+# Add all LaTeX files to PDF documents as well
+pdf_documents = []
+for l in latex_documents:
+doc = l[0]
+fn = l[1].replace(".tex", "")
+name = l[2]
+authors = l[3]
+pdf_documents.append((doc, fn, name, authors))
# kernel-doc extension configuration for running Sphinx directly (e.g. by Read
# the Docs). In a normal build, these are supplied from the Makefile via
command
diff --git a/Documentation/sphinx/load_config.py
b/Documentation/sphinx/load_config.py
index eeb394b39e2c..8266afd438aa 100644
--- a/Documentation/sphinx/load_config.py
+++ b/Documentation/sphinx/load_config.py
@@ -43,6 +43,18 @@ def loadConfig(namespace):
namespace['latex_documents'] = new_latex_docs
+new_pdf_docs = []
+pdf_documents = namespace['pdf_documents']
+
+for l in pdf_documents:
+if l[0].find(dir + '/') == 0:
+has = True
+fn = l[0][len(dir) + 1:]
+new_pdf_docs.append((fn, l[1], l[2], l[3]))
+break
+
+namespace['pdf_documents'] = new_pdf_docs
+
# If there is an extra conf.py file, load it
if os.path.isfile(config_file):
sys.stdout.write("load additional sphinx-config: %s\n" %
config_file)
diff --git a/Documentation/userspace-api/media/Makefile
b/Documentation/userspace-api/media/Makefile
index 81a4a1a53bce..8c6b3ac4ecb0 100644
--- a/Documentation/userspace-api/media/Makefile
+++ b/Documentation/userspace-api/media/Makefile
@@ -59,6 +59,7 @@ all: $(IMGDOT) $(BUILDDIR) ${TARGETS}
html: all
epub: all
xml: all
+pdf: all
latex: $(IMGPDF) all
linkcheck:
diff --git a/Makefile b/Makefile
index 43ecedeb3f02..db4043578eec 100644
--- a/Makefile
+++ b/Makefile
@@ -264,7 +264,7 @@ no-dot-config-targets := $(clean-targets) \
cscope gtags TAGS tags help% %docs check% coccicheck \
$(version_h) headers headers_% archheaders archscripts
\
%asm-generic kernelversion %src-pkg dt_binding_check \
-outputmakefile
+outputmakefile rst2pdf
no-sync-config-targets := $(no-dot-config-targets) %install kernelrelease
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
@@ -1654,7 +1654,7 @@ $(help-board-dirs): help-%:
# Documentation targets
#
Re: [PATCH v4 1/4] pwm: pca9685: Switch to atomic API
On Thu, Dec 10, 2020 at 09:39:26PM +0100, Uwe Kleine-König wrote: > Hello Thierry, > > On Thu, Dec 10, 2020 at 06:10:45PM +0100, Thierry Reding wrote: > > Like I said, that's not what I was saying. I was merely saying that if > > there aren't any use-cases that current users rely on that would be > > broken by using this simpler implementation, then I'm okay with it, even > > if it's less flexible than a more complicated implementation. It should > > be possible to determine what the current users are by inspecting device > > trees present in the kernel. Anything outside the kernel isn't something > > we need to consider, as usual. > > If "users in mainline" is the criteria that's a word. I didn't say "users in mainline", I said "use-cases". What I don't want to happen is for this change under discussion to break any existing use- cases of any existing users in the kernel. I said that we can determine what the existing users are by looking at which device trees use the compatible strings that the driver matches on. > So you agree we remove the following drivers?: > > - pwm-hibvt.c >Last driver specific change in Feb 2019, no mainline user > - pwm-sprd.c >Last driver specific change in Aug 2019, no mainline user No, that's an extrapolation of what I was saying above. Drivers with no apparent users are a separate topic, so don't conflate it with the issue at hand. While it's certainly unfortunate that these don't seem to be used, I see no reason why we should remove them. They don't create much of a maintenance burden, so I'm fine with keeping them in the hopes that users may still show up at some point. > Most PWMs are added to cpu.dtsi files with status = "disabled", I wonder > if it makes sense to check the machine.dts files if some of the PMWs are > completely unused. Do you consider status = "okay" a use that we have to > retain even if the node has no phandle? A PWM controller may be in use via sysfs even if it has no phandle. Thierry signature.asc Description: PGP signature
Re: [PATCH v2] usb: typec: Add class for plug alt mode device
On Thu, Dec 10, 2020 at 01:16:54PM -0800, Prashant Malani wrote:
> Add the Type C class for plug alternate mode devices which are being
> registered by the Type C connector class. This ensures that udev events
> get generated when the plug alt modes are registered.
>
> Signed-off-by: Prashant Malani
> Cc: Heikki Krogerus
Reviewed-by: Heikki Krogerus
> ---
>
> Changes in v2:
> - Changed code to set the class member instead of bus.
> - Removed the alteration to typec_bus.rst since it's not longer
> required.
> - Updated the commit message and subject to reflect the change in code.
>
> v1:
> https://lore.kernel.org/linux-usb/20201203030846.51669-1-pmal...@chromium.org/
>
> drivers/usb/typec/class.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
> index 35eec707cb51..29d05b45cc9d 100644
> --- a/drivers/usb/typec/class.c
> +++ b/drivers/usb/typec/class.c
> @@ -482,6 +482,10 @@ typec_register_altmode(struct device *parent,
> if (is_typec_partner(parent))
> alt->adev.dev.bus = &typec_bus;
>
> + /* Plug alt modes need a class to generate udev events. */
> + if (is_typec_plug(parent))
> + alt->adev.dev.class = typec_class;
> +
> ret = device_register(&alt->adev.dev);
> if (ret) {
> dev_err(parent, "failed to register alternate mode (%d)\n",
> --
> 2.29.2.576.ga3fc446d84-goog
thanks,
--
heikki
Re: [PATCH] usb: typec: tcpci: Enable bleed discharge when auto discharge is enabled
On Thu, Dec 10, 2020 at 11:11:45PM -0800, Badhri Jagan Sridharan wrote: > Auto discharge circuits kick in only when vbus decays and reaches > VBUS_SINK_DISCONNECT_THRESHOLD threshold. Enable bleed discharge to > discharge vbus to VBUS_SINK_DISCONNECT_THRESHOLD upon disconnect. > > Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Heikki Krogerus > --- > drivers/usb/typec/tcpm/tcpci.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/typec/tcpm/tcpci.c b/drivers/usb/typec/tcpm/tcpci.c > index af5524338a63..f676abab044b 100644 > --- a/drivers/usb/typec/tcpm/tcpci.c > +++ b/drivers/usb/typec/tcpm/tcpci.c > @@ -725,6 +725,8 @@ struct tcpci *tcpci_register_port(struct device *dev, > struct tcpci_data *data) > tcpci->tcpc.enable_auto_vbus_discharge = > tcpci_enable_auto_vbus_discharge; > tcpci->tcpc.set_auto_vbus_discharge_threshold = > tcpci_set_auto_vbus_discharge_threshold; > + regmap_update_bits(tcpci->regmap, TCPC_POWER_CTRL, > TCPC_POWER_CTRL_BLEED_DISCHARGE, > +TCPC_POWER_CTRL_BLEED_DISCHARGE); > } > > if (tcpci->data->vbus_vsafe0v) > -- > 2.29.2.576.ga3fc446d84-goog -- heikki
Re: [PATCH v3] lib: stackdepot: Add support to configure STACK_HASH_SIZE
On Thu, Dec 10, 2020 at 6:01 AM wrote:
>
> From: Yogesh Lal
>
> Add a kernel parameter stack_hash_order to configure STACK_HASH_SIZE.
>
> Aim is to have configurable value for STACK_HASH_SIZE, so that one
> can configure it depending on usecase there by reducing the static
> memory overhead.
>
> One example is of Page Owner, default value of STACK_HASH_SIZE lead
> stack depot to consume 8MB of static memory. Making it configurable
> and use lower value helps to enable features like CONFIG_PAGE_OWNER
> without any significant overhead.
Can we go with a static CONFIG_ parameter instead?
Guess most users won't bother changing the default anyway, and for
CONFIG_PAGE_OWNER users changing the size at boot time is not strictly
needed.
> -static struct stack_record *stack_table[STACK_HASH_SIZE] = {
> - [0 ... STACK_HASH_SIZE - 1] = NULL
> +static unsigned int stack_hash_order = 20;
Please initialize with MAX_STACK_HASH_ORDER instead.
> +static struct stack_record *stack_table_def[MAX_STACK_HASH_SIZE] __initdata
> = {
> + [0 ... MAX_STACK_HASH_SIZE - 1] = NULL
> };
> +static struct stack_record **stack_table __refdata = stack_table_def;
> +
> +static int __init setup_stack_hash_order(char *str)
> +{
> + kstrtouint(str, 0, &stack_hash_order);
> + if (stack_hash_order > MAX_STACK_HASH_ORDER)
> + stack_hash_order = MAX_STACK_HASH_ORDER;
> + return 0;
> +}
> +early_param("stack_hash_order", setup_stack_hash_order);
> +
> +static int __init init_stackdepot(void)
> +{
> + size_t size = (STACK_HASH_SIZE * sizeof(struct stack_record *));
> +
> + stack_table = vmalloc(size);
> + memcpy(stack_table, stack_table_def, size);
Looks like you are assuming stack_table_def already contains some data
by this point.
But if STACK_HASH_SIZE shrinks this memcpy() above will just copy some
part of the table, whereas the rest will be lost.
We'll need to:
- either explicitly decide we can afford losing this data (no idea how
bad this can potentially be),
- or disallow storing anything prior to full stackdepot initialization
(then we don't need stack_table_def),
- or carefully move all entries to the first part of the table.
Alex
[PATCH net-next] gve: simplify the gve code return expression
Simplify the return expression at diffrent gve_adminq.c file, simplify this all.
Signed-off-by: Zheng Yongjun
---
drivers/net/ethernet/google/gve/gve_adminq.c | 21 +++-
1 file changed, 3 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c
b/drivers/net/ethernet/google/gve/gve_adminq.c
index 24ae6a28a806..6719181afdfd 100644
--- a/drivers/net/ethernet/google/gve/gve_adminq.c
+++ b/drivers/net/ethernet/google/gve/gve_adminq.c
@@ -318,7 +318,6 @@ static int gve_adminq_create_tx_queue(struct gve_priv
*priv, u32 queue_index)
{
struct gve_tx_ring *tx = &priv->tx[queue_index];
union gve_adminq_command cmd;
- int err;
memset(&cmd, 0, sizeof(cmd));
cmd.opcode = cpu_to_be32(GVE_ADMINQ_CREATE_TX_QUEUE);
@@ -332,11 +331,7 @@ static int gve_adminq_create_tx_queue(struct gve_priv
*priv, u32 queue_index)
.ntfy_id = cpu_to_be32(tx->ntfy_id),
};
- err = gve_adminq_issue_cmd(priv, &cmd);
- if (err)
- return err;
-
- return 0;
+ return gve_adminq_issue_cmd(priv, &cmd);
}
int gve_adminq_create_tx_queues(struct gve_priv *priv, u32 num_queues)
@@ -357,7 +352,6 @@ static int gve_adminq_create_rx_queue(struct gve_priv
*priv, u32 queue_index)
{
struct gve_rx_ring *rx = &priv->rx[queue_index];
union gve_adminq_command cmd;
- int err;
memset(&cmd, 0, sizeof(cmd));
cmd.opcode = cpu_to_be32(GVE_ADMINQ_CREATE_RX_QUEUE);
@@ -372,11 +366,7 @@ static int gve_adminq_create_rx_queue(struct gve_priv
*priv, u32 queue_index)
.queue_page_list_id = cpu_to_be32(rx->data.qpl->id),
};
- err = gve_adminq_issue_cmd(priv, &cmd);
- if (err)
- return err;
-
- return 0;
+ return gve_adminq_issue_cmd(priv, &cmd);
}
int gve_adminq_create_rx_queues(struct gve_priv *priv, u32 num_queues)
@@ -396,7 +386,6 @@ int gve_adminq_create_rx_queues(struct gve_priv *priv, u32
num_queues)
static int gve_adminq_destroy_tx_queue(struct gve_priv *priv, u32 queue_index)
{
union gve_adminq_command cmd;
- int err;
memset(&cmd, 0, sizeof(cmd));
cmd.opcode = cpu_to_be32(GVE_ADMINQ_DESTROY_TX_QUEUE);
@@ -404,11 +393,7 @@ static int gve_adminq_destroy_tx_queue(struct gve_priv
*priv, u32 queue_index)
.queue_id = cpu_to_be32(queue_index),
};
- err = gve_adminq_issue_cmd(priv, &cmd);
- if (err)
- return err;
-
- return 0;
+ return gve_adminq_issue_cmd(priv, &cmd);
}
int gve_adminq_destroy_tx_queues(struct gve_priv *priv, u32 num_queues)
--
2.22.0
Re: [RFC PATCH] workqueue: handle CPU hotplug without updating worker pool's attrs
On Fri, Dec 11, 2020 at 3:21 PM Hillf Danton wrote:
>
> On Fri, 11 Dec 2020 10:29:55 +0800 Lai Jiangshan wrote:
> >On Wed, Dec 9, 2020 at 4:34 PM Hillf Danton wrote:
> >>
> >> This makes the cpumask intact for worker pools of unbound workqueues
> >> when CPUs go offline because we need to rebind workers to the original
> >> cpumask(of the original pool) when they come back, as represented by
> >> the cpu check in restore_unbound_workers_cpumask().
> >>
> >> Note this is now only for comments.
> >>
> >> Signed-off-by: Hillf Danton
> >> ---
> >>
> >> --- a/kernel/workqueue.c
> >> +++ b/kernel/workqueue.c
> >> @@ -4117,6 +4117,32 @@ static void wq_update_unbound_numa(struc
> >> copy_workqueue_attrs(target_attrs, wq->unbound_attrs);
> >> pwq = unbound_pwq_by_node(wq, node);
> >>
> >> + cpumask = pwq->pool->attrs->cpumask;
> >> + if (!online || !cpumask_test_cpu(cpu, cpumask))
> >> + return;
> >> + do {
> >> + struct worker *worker;
> >> + int i;
> >> +
> >> + for_each_cpu_and(i, cpu_online_mask, cpumask) {
> >> + if (i != cpu)
> >> + return;
> >> + }
> >> +
> >> + /*
> >> +* rebind workers only when the first CPU in
> >> +* pool's attrs cpumask comes back because scheduler
> >> +* may have unbound them when the last CPU went offline
> >> +*/
> >> + mutex_lock(&wq_pool_attach_mutex);
> >> +
> >> + for_each_pool_worker(worker, pwq->pool)
> >> + set_cpus_allowed_ptr(worker->task, cpumask);
> >> +
> >
> >There might be multiple pwqs that share the same pool, this line of
> >code might update the same pool multiple times.
>
> Thanks for taking a look at it.
>
> It is the pool (shared between multiple pwqs or not) attrs cpumask, in
> combination with the above i != cpu check, that ensures single update.
When the pool is shared by multiple pwqs, it will be visited
multiple times when each pwq is visited, and your code touches
the pool multiple times.
wq_update_unbound_numa() updates the pwq table.
restore_unbound_workers_cpumask() updates the scheduler cpumasks.
>
> >
> >Please keep the logic in restore_unbound_workers_cpumask().
> >
> >> + mutex_unlock(&wq_pool_attach_mutex);
> >> + return;
> >> + } while (0);
> >> +
> >> /*
> >> * Let's determine what needs to be done. If the target cpumask is
> >> * different from the default pwq's, we need to compare it to
> >> @pwq's
> >> @@ -5004,34 +5030,6 @@ static void rebind_workers(struct worker
> >> raw_spin_unlock_irq(&pool->lock);
> >> }
> >>
> >> -/**
> >> - * restore_unbound_workers_cpumask - restore cpumask of unbound workers
> >> - * @pool: unbound pool of interest
> >> - * @cpu: the CPU which is coming up
> >> - *
> >> - * An unbound pool may end up with a cpumask which doesn't have any online
> >> - * CPUs. When a worker of such pool get scheduled, the scheduler resets
> >> - * its cpus_allowed. If @cpu is in @pool's cpumask which didn't have any
> >> - * online CPU before, cpus_allowed of all its workers should be restored.
> >> - */
> >> -static void restore_unbound_workers_cpumask(struct worker_pool *pool, int
> >> cpu)
> >> -{
> >> - static cpumask_t cpumask;
> >> - struct worker *worker;
> >> -
> >> - lockdep_assert_held(&wq_pool_attach_mutex);
> >> -
> >> - /* is @cpu allowed for @pool? */
> >> - if (!cpumask_test_cpu(cpu, pool->attrs->cpumask))
> >> - return;
> >> -
> >> - cpumask_and(&cpumask, pool->attrs->cpumask, cpu_online_mask);
> >
> >Good catch of the problem.
> >But please fix it where the problem is found (here!)
>
> The cause of the issue is the update of pool->attrs->cpumask in
> wq_update_unbound_numa() for offline CPUs, and it is too late to
> add changes only when they come back online.
>
pool->attrs->cpumask is read only, it is not updated.
This function just updates the pwq table, using(allocating when needed)
the pwq for the node or using the default pwq. It does not change the
attrs->cpumask.
And
+ if (!online || !cpumask_test_cpu(cpu, cpumask))
+ return;
is totally incorrect for !online. In both cases (online&offline)
we may need to update the pwq table.
> >Like this:
> >
> >+/* only restore the cpumask of the pool's workers when @cpu is
> >+ the first online cpu in @pool's cpumask */
> >+if (cpumask_weight(cpumask) > 1)
> >+return;
> >
> >/* as we're called from CPU_ONLINE, the following shouldn't fail */
> >for_each_pool_worker(worker, pool)
> >-WARN_ON_ONCE(set_cpus_allowed_ptr(worker->task, &cpumask) <
> >0);
> >+WARN_ON_ONCE(set_cpus_allowed_ptr(worker->task,
> >pool->attrs->cpumask) < 0);
>
> Got it. And we hav
Re: [PATCH 4.19 15/39] ALSA: hda/generic: Add option to enforce preferred_dacs pairs
Hi! > From: Takashi Iwai > > commit 242d990c158d5b1dabd166516e21992baef5f26a upstream. > > The generic parser accepts the preferred_dacs[] pairs as a hint for > assigning a DAC to each pin, but this hint doesn't work always > effectively. Currently it's merely a secondary choice after the trial > with the path index failed. This made sometimes it difficult to > assign DACs without mimicking the connection list and/or the badness > table. > > This patch adds a new flag, obey_preferred_dacs, that changes the > behavior of the parser. As its name stands, the parser obeys the Option added is never used as variable is never set. We don't need this in 4.19. Best regards, Pavel -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany signature.asc Description: PGP signature
[PATCH net-next] net/mediatek: simplify the mediatek code return expression
Simplify the return expression at mtk_eth_path.c file, simplify this all.
Signed-off-by: Zheng Yongjun
---
drivers/net/ethernet/mediatek/mtk_eth_path.c | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_path.c
b/drivers/net/ethernet/mediatek/mtk_eth_path.c
index 6bc9f2487384..72648535a14d 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_path.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_path.c
@@ -252,7 +252,7 @@ int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int
mac_id)
int mtk_gmac_gephy_path_setup(struct mtk_eth *eth, int mac_id)
{
- int err, path = 0;
+ int path = 0;
if (mac_id == 1)
path = MTK_ETH_PATH_GMAC2_GEPHY;
@@ -261,25 +261,17 @@ int mtk_gmac_gephy_path_setup(struct mtk_eth *eth, int
mac_id)
return -EINVAL;
/* Setup proper MUXes along the path */
- err = mtk_eth_mux_setup(eth, path);
- if (err)
- return err;
-
- return 0;
+ return mtk_eth_mux_setup(eth, path);
}
int mtk_gmac_rgmii_path_setup(struct mtk_eth *eth, int mac_id)
{
- int err, path;
+ int path;
path = (mac_id == 0) ? MTK_ETH_PATH_GMAC1_RGMII :
MTK_ETH_PATH_GMAC2_RGMII;
/* Setup proper MUXes along the path */
- err = mtk_eth_mux_setup(eth, path);
- if (err)
- return err;
-
- return 0;
+ return mtk_eth_mux_setup(eth, path);
}
--
2.22.0
[GIT PULL] Late GPIO fixes for v5.10
Hi Linus, these are hopefully the last GPIO fixes for this cycle. All are driver fixes except a small resource leak for pin ranges in the gpiolib. Two are PM related, which is nice because when developers start to find PM bugs it is usually because they have smoked out the bugs of more severe nature. Please pull it in! Yours, Linus Walleij The following changes since commit b65054597872ce3aefbc6a666385eabdf9e288da: Linux 5.10-rc6 (2020-11-29 15:50:50 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git tags/v5.10-3 for you to fetch changes up to 263ade7166a2e589c5b605272690c155c0637dcb: gpio: eic-sprd: break loop when getting NULL device resource (2020-12-09 09:41:49 +0100) GPIO fixes for the v5.10 kernel series: - Fix runtime PM balancing on the errorpath of the Arizona driver. - Fix a suspend NULL pointer reference in the dwapb driver. - Balance free:ing in gpiochip_generic_free() - Fix runtime PM balancing on the errorpath of the zynq driver. - Fix irqdomain use-after-free in the mvebu driver. - Break an eternal loop in the spreadtrum EIC driver. Baruch Siach (1): gpio: mvebu: fix potential user-after-free on probe Chunyan Zhang (1): gpio: eic-sprd: break loop when getting NULL device resource Edmond Chung (1): gpiolib: Don't free if pin ranges are not defined Linus Walleij (1): Merge tag 'gpio-fixes-for-v5.10-rc7' of git://git.kernel.org/.../brgl/linux into fixes Luo Jiaxing (1): gpio: dwapb: fix NULL pointer dereference at dwapb_gpio_suspend() Qinglang Miao (1): gpio: zynq: fix reference leak in zynq_gpio functions Zheng Liang (1): gpio: arizona: disable pm_runtime in case of failure drivers/gpio/gpio-arizona.c | 1 + drivers/gpio/gpio-dwapb.c| 2 ++ drivers/gpio/gpio-eic-sprd.c | 2 +- drivers/gpio/gpio-mvebu.c| 16 +++- drivers/gpio/gpio-zynq.c | 4 ++-- drivers/gpio/gpiolib.c | 5 + 6 files changed, 22 insertions(+), 8 deletions(-)
Re: [PATCH] mmc: atmel-mci: Reduce scope for the variable “slot” in atmci_request_end()
Markus was banned from vger at the end of July after ignoring repeated warnings. This makes it hard to review any patches or follow discussion... regards, dan carpenter
[PATCH -next] fs/omfs: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- fs/omfs/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/omfs/file.c b/fs/omfs/file.c index 2c7b70ee1388..fc6828f30f60 100644 --- a/fs/omfs/file.c +++ b/fs/omfs/file.c @@ -22,8 +22,8 @@ void omfs_make_empty_table(struct buffer_head *bh, int offset) struct omfs_extent *oe = (struct omfs_extent *) &bh->b_data[offset]; oe->e_next = ~cpu_to_be64(0ULL); - oe->e_extent_count = cpu_to_be32(1), - oe->e_fill = cpu_to_be32(0x22), + oe->e_extent_count = cpu_to_be32(1); + oe->e_fill = cpu_to_be32(0x22); oe->e_entry.e_cluster = ~cpu_to_be64(0ULL); oe->e_entry.e_blocks = ~cpu_to_be64(0ULL); } -- 2.22.0
[PATCH -next] fs/omfs: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- fs/omfs/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/omfs/file.c b/fs/omfs/file.c index 2c7b70ee1388..fc6828f30f60 100644 --- a/fs/omfs/file.c +++ b/fs/omfs/file.c @@ -22,8 +22,8 @@ void omfs_make_empty_table(struct buffer_head *bh, int offset) struct omfs_extent *oe = (struct omfs_extent *) &bh->b_data[offset]; oe->e_next = ~cpu_to_be64(0ULL); - oe->e_extent_count = cpu_to_be32(1), - oe->e_fill = cpu_to_be32(0x22), + oe->e_extent_count = cpu_to_be32(1); + oe->e_fill = cpu_to_be32(0x22); oe->e_entry.e_cluster = ~cpu_to_be64(0ULL); oe->e_entry.e_blocks = ~cpu_to_be64(0ULL); } -- 2.22.0
[PATCH -next] fs/afs: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- fs/afs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/afs/inode.c b/fs/afs/inode.c index b0d7b892090d..da728210cdb8 100644 --- a/fs/afs/inode.c +++ b/fs/afs/inode.c @@ -502,7 +502,7 @@ static int afs_iget5_set_root(struct inode *inode, void *opaque) struct afs_vnode *vnode = AFS_FS_I(inode); vnode->volume = as->volume; - vnode->fid.vid = as->volume->vid, + vnode->fid.vid = as->volume->vid; vnode->fid.vnode= 1; vnode->fid.unique = 1; inode->i_ino= 1; -- 2.22.0
[PATCH -next] fs/xfs: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- fs/xfs/libxfs/xfs_btree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/libxfs/xfs_btree.c b/fs/xfs/libxfs/xfs_btree.c index 2d25bab68764..51dbff9b0908 100644 --- a/fs/xfs/libxfs/xfs_btree.c +++ b/fs/xfs/libxfs/xfs_btree.c @@ -4070,7 +4070,7 @@ xfs_btree_delrec( * surviving block, and log it. */ xfs_btree_set_numrecs(left, lrecs + rrecs); - xfs_btree_get_sibling(cur, right, &cptr, XFS_BB_RIGHTSIB), + xfs_btree_get_sibling(cur, right, &cptr, XFS_BB_RIGHTSIB); xfs_btree_set_sibling(cur, left, &cptr, XFS_BB_RIGHTSIB); xfs_btree_log_block(cur, lbp, XFS_BB_NUMRECS | XFS_BB_RIGHTSIB); -- 2.22.0
Re: [PATCH v2] Serial: silabs si4455 serial driver
On Fri, Dec 11, 2020 at 08:16:34AM +, József Horváth wrote:
> On Fri, Dec 11, 2020 at 08:33:17AM +0100, 'Greg Kroah-Hartman' wrote:
> > On Fri, Dec 11, 2020 at 06:37:52AM +, József Horváth wrote:
> > > On Fri, Dec 11, 2020 at 07:20:41AM +0100, 'Greg Kroah-Hartman' wrote:
> > > > On Fri, Dec 11, 2020 at 06:09:43AM +, József Horváth wrote:
> > > > > On Fri, Dec 11, 2020 at 06:50:58AM +0100, 'Greg Kroah-Hartman' wrote:
> > > > > > On Thu, Dec 10, 2020 at 07:46:25PM +, József Horváth wrote:
> > > > > > > On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman'
> > > > > > > wrote:
> > > > > > > > On Thu, Dec 10, 2020 at 05:04:46PM +, József Horváth wrote:
> > > > > > > > > This is a serial port driver for
> > > > > > > > > Silicon Labs Si4455 Sub-GHz transciver.
> > > > > > > > > +
> > > > > > > > > +#define BASE_TTYIOC_PRIVATE 0xA0
> > > > > > > > > +/* Set EZConfig.
> > > > > > > > > + * After this ioctl call, the driver restarts the si4455,
> > > > > > > > > + * then apply the new configuration and patch.
> > > > > > > > > + */
> > > > > > > > > +#define SI4455_IOC_SEZC _IOW('T', \
> > > > > > > > > + BASE_TTYIOC_PRIVATE +
> > > > > > > > > 0x01, \
> > > > > > > > > + struct si4455_iocbuff)
> > > > > > > >
> > > > > > > > Why does a serial driver have private ioctls? Please no, don't
> > > > > > > > do that.
> > > > > > >
> > > > > > > I checked the ioctl.h and serial_core.h, but I not found any
> > > > > > > similar definition, like BASE_VIDIOC_PRIVATE in videodev2.h.
> > > > > > > In this case the name of macro BASE_TTYIOC_PRIVATE means the base
> > > > > > > value of special ioctl commands owned by this driver.
> > > > > >
> > > > > > My point is, a serial driver should NOT have any custom ioctls.
> > > > > >
> > > > > > > I can change it to BASE_TTYIOC or SI4455_IOC_BASE
> > > > > > >
> > > > > > > > Implement the basic serial driver first, and then we can talk
> > > > > > > > about
> > > > > > > > "custom" configurations and the like, using the correct apis.
> > > > > > >
> > > > > > > Without the SI4455_IOC_SEZC call, the driver can't configure the
> > > > > > > Si4455 and not working at all.
> > > > > > > The cofiguration for interface is provided by user for
> > > > > > > application.
> > > > > >
> > > > > > That is what a device tree is for, to configure the device to have
> > > > > > the
> > > > > > correct system configuration, why can't that be the same here?
> > > > > >
> > > > > > > It contains the base frequency, channel spacing, modulation, and
> > > > > > > a lot
> > > > > > > of more stuff, and generated by Silicon Labs Wireless Development
> > > > > > > Suite.
> > > > > > > The generated configuration is in a non public(compressed,
> > > > > > > encrypted...who knows) format, so without this the driver can't
> > > > > > > provide configuration parameters to Si4455.
> > > > > >
> > > > > > So we have to take a "custom" userspace blob and send it to the
> > > > > > device
> > > > > > to configure it properly? Like Jiri said, sounds like firmware, so
> > > > > > just
> > > > > > use that interface instead.
> > > > >
> > > > > I checked Jiri's suggestion, and it is a good solution to replace
> > > > > SI4455_IOC_SEZC(configuration) and SI4455_IOC_SEZP(firmware patch).
> > > > > I can move SI4455_IOC_SSIZ(package size) to device tree property.
> > > > >
> > > > > Maybe you have good suggestion for the following:
> > > > > SI4455_IOC_STXC -> Radio transmit channel index. It is a real use
> > > > > case to control this parameter by user at runtime.
> > > > > SI4455_IOC_SRXC -> Radio receive channel index. It is a real use case
> > > > > to control this parameter by user at runtime.
> > > >
> > > > These are not serial port things, why would a serial port care about
> > > > these?
> > >
> > > You are right, these are not regular serial port things, but this device
> > > is not a regular uart, it is a sub-GHz transciever, digital radio.
> > > This driver tries to represent it as a serial port to user.
> >
> > Is that the correct representation to be using here? Why not act like a
> > proper radio device instead? That way you get to use the normal kernel
> > apis for radio devices.
>
> In my mind it is absolute a serial device by the application.
What is the application? Traditionally serial ports don't need radio signals :)
> > > > > SI4455_IOC_GRSSI -> Last measured RSSI, when packet received. This is
> > > > > a useful information.
> > > > > (Currently I'm the only one user, and I need this :) )
> > > >
> > > > What is "RSSI"?
> > > >
> > > > And why not debugfs if it's only debugging stuff?
> > >
> > > Received signal strength indication, and not only debugging. It is an
> > > information for the end user.
> >
> > How do other radio devices (like wifi controllers) export this
> > information to userspace? Don't create custom apis for only
Re: [RFC v2 1/1] vfio/platform: add support for msi
Hi Vikas,
On 12/10/20 8:34 AM, Vikas Gupta wrote:
> HI Eric,
>
> On Tue, Dec 8, 2020 at 2:13 AM Auger Eric wrote:
>>
>> Hi Vikas,
>>
>> On 12/3/20 3:50 PM, Vikas Gupta wrote:
>>> Hi Eric,
>>>
>>> On Wed, Dec 2, 2020 at 8:14 PM Auger Eric wrote:
Hi Vikas,
On 11/24/20 5:16 PM, Vikas Gupta wrote:
> MSI support for platform devices.
>
> Signed-off-by: Vikas Gupta
> ---
> drivers/vfio/platform/vfio_platform_common.c | 99 ++-
> drivers/vfio/platform/vfio_platform_irq.c | 260 +-
> drivers/vfio/platform/vfio_platform_private.h | 16 ++
> include/uapi/linux/vfio.h | 43 +++
> 4 files changed, 401 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/vfio/platform/vfio_platform_common.c
> b/drivers/vfio/platform/vfio_platform_common.c
> index c0771a9567fb..b0bfc0f4ee1f 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "vfio_platform_private.h"
>
> @@ -344,9 +345,16 @@ static long vfio_platform_ioctl(void *device_data,
>
> } else if (cmd == VFIO_DEVICE_GET_IRQ_INFO) {
> struct vfio_irq_info info;
> + struct vfio_info_cap caps = { .buf = NULL, .size = 0 };
> + struct vfio_irq_info_cap_msi *msi_info = NULL;
> + unsigned long capsz;
> + int ext_irq_index = vdev->num_irqs - vdev->num_ext_irqs;
>
> minsz = offsetofend(struct vfio_irq_info, count);
>
> + /* For backward compatibility, cannot require this */
> + capsz = offsetofend(struct vfio_irq_info, cap_offset);
> +
> if (copy_from_user(&info, (void __user *)arg, minsz))
> return -EFAULT;
>
> @@ -356,9 +364,89 @@ static long vfio_platform_ioctl(void *device_data,
> if (info.index >= vdev->num_irqs)
> return -EINVAL;
>
> + if (info.argsz >= capsz)
> + minsz = capsz;
> +
> + if (info.index == ext_irq_index) {
nit: n case we add new ext indices afterwards, I would check info.index
- ext_irq_index against an VFIO_EXT_IRQ_MSI define.
> + struct vfio_irq_info_cap_type cap_type = {
> + .header.id = VFIO_IRQ_INFO_CAP_TYPE,
> + .header.version = 1 };
> + int i;
> + int ret;
> + int num_msgs;
> + size_t msi_info_size;
> + struct vfio_platform_irq *irq;
nit: I think generally the opposite order (length) is chosen. This also
would better match the existing style in this file
>>> Ok will fix it
> +
> + info.index = array_index_nospec(info.index,
> + vdev->num_irqs);
> +
> + irq = &vdev->irqs[info.index];
> +
> + info.flags = irq->flags;
I think this can be removed given [*]
>>> Sure.
> + cap_type.type = irq->type;
> + cap_type.subtype = irq->subtype;
> +
> + ret = vfio_info_add_capability(&caps,
> +&cap_type.header,
> +sizeof(cap_type));
> + if (ret)
> + return ret;
> +
> + num_msgs = irq->num_ctx;
do would want to return the cap even if !num_ctx?
>>> If num_ctx = 0 then VFIO_IRQ_INFO_CAP_MSI_DESCS should not be written.
>>> I`ll take care of same.
> +
> + msi_info_size = struct_size(msi_info, msgs,
> num_msgs);
> +
> + msi_info = kzalloc(msi_info_size, GFP_KERNEL);
> + if (!msi_info) {
> + kfree(caps.buf);
> + return -ENOMEM;
> + }
> +
> + msi_info->header.id = VFIO_IRQ_INFO_CAP_MSI_DESCS;
> + msi_info->header.version = 1;
> + msi_info->nr_msgs = num_msgs;
> +
> + for (i = 0; i < num_msgs; i++) {
> + struct vfio_irq_ctx *ctx = &irq->ctx[i];
> +
> + msi_info->msgs[i].addr_lo =
> ctx->msg.address_lo;
> + msi_info->msgs[i].addr_hi =
> ctx->msg.address_hi;
> + msi_info->msgs[i].data = ctx->msg.data;
> +
[PATCH -next] fs/lockd: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- fs/lockd/host.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/lockd/host.c b/fs/lockd/host.c index 0afb6d59bad0..497520bc00a7 100644 --- a/fs/lockd/host.c +++ b/fs/lockd/host.c @@ -163,7 +163,7 @@ static struct nlm_host *nlm_alloc_host(struct nlm_lookup_host_info *ni, host->h_nsmhandle = nsm; host->h_addrbuf= nsm->sm_addrbuf; host->net = ni->net; - host->h_cred = get_cred(ni->cred), + host->h_cred = get_cred(ni->cred); strlcpy(host->nodename, utsname()->nodename, sizeof(host->nodename)); out: -- 2.22.0
[PATCH -next] kernel/audit: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- kernel/audit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/audit.c b/kernel/audit.c index 68cee3bc8cfe..c8497115be35 100644 --- a/kernel/audit.c +++ b/kernel/audit.c @@ -2282,7 +2282,7 @@ static void audit_log_set_loginuid(kuid_t koldloginuid, kuid_t kloginuid, uid = from_kuid(&init_user_ns, task_uid(current)); oldloginuid = from_kuid(&init_user_ns, koldloginuid); - loginuid = from_kuid(&init_user_ns, kloginuid), + loginuid = from_kuid(&init_user_ns, kloginuid); tty = audit_get_tty(); audit_log_format(ab, "pid=%d uid=%u", task_tgid_nr(current), uid); -- 2.22.0
[PATCH -next] sof/intel: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- sound/soc/sof/intel/hda-dsp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sof/intel/hda-dsp.c b/sound/soc/sof/intel/hda-dsp.c index 18ff1c2f5376..2b001151fe37 100644 --- a/sound/soc/sof/intel/hda-dsp.c +++ b/sound/soc/sof/intel/hda-dsp.c @@ -44,7 +44,7 @@ int hda_dsp_core_reset_enter(struct snd_sof_dev *sdev, unsigned int core_mask) reset = HDA_DSP_ADSPCS_CRST_MASK(core_mask); snd_sof_dsp_update_bits_unlocked(sdev, HDA_DSP_BAR, HDA_DSP_REG_ADSPCS, -reset, reset), +reset, reset); /* poll with timeout to check if operation successful */ ret = snd_sof_dsp_read_poll_timeout(sdev, HDA_DSP_BAR, -- 2.22.0
Re: linux-next fsnotify mod breaks tail -f
On Fri, Dec 11, 2020 at 1:45 AM Hugh Dickins wrote:
>
> Hi Jan, Amir,
>
> There's something wrong with linux-next commit ca7fbf0d29ab
> ("fsnotify: fix events reported to watching parent and child").
>
> If I revert that commit, no problem;
> but here's a one-line script "tailed":
>
> for i in 1 2 3 4 5; do date; sleep 1; done &
>
> Then if I run that (same result doing ./tailed after chmod a+x):
>
> sh tailed >log; tail -f log
>
> the "tail -f log" behaves in one of three ways:
>
> 1) On a console, before graphical screen, no problem,
>it shows the five lines coming from "date" as you would expect.
> 2) From xterm or another tty, shows just the first line from date,
>but after I wait and Ctrl-C out, "cat log" shows all five lines.
> 3) From xterm or another tty, doesn't even show that first line.
>
> The before/after graphical screen thing seems particularly weird:
> I expect you'll end up with a simpler explanation for what's
> causing that difference.
>
> tailed and log are on ext4, if that's relevant;
> ah, I just tried on tmpfs, and saw no problem there.
Nice riddle Hugh :)
Thanks for this early testing!
I was able to reproduce this.
The outcome does not depend on the type of terminal or filesystem
it depends on the existence of a watch on the parent dir of the log file.
Running ' inotifywait -m . &' will stop tail from getting notifications:
echo > log
tail -f log &
sleep 1
echo "can you see this?" >> log
inotifywait -m . &
sleep 1
echo "how about this?" >> log
kill $(jobs -p)
I suppose with a graphical screen you have systemd or other services
in the system watching the logs/home dir in your test env.
Attached fix patch. I suppose Jan will want to sqhash it.
We missed a subtle logic change in the switch from inode/child marks
to parent/inode marks terminology.
Before the change (!inode_mark && child_mark) meant that name
was not NULL and should be discarded (which the old code did).
After the change (!parent_mark && inode_mark) is not enough to
determine if name should be discarded (it should be discarded only
for "events on child"), so another check is needed.
Thanks,
Amir.
From c7ea57c66c8c9f9607928bf7c55fc409eecc3e57 Mon Sep 17 00:00:00 2001
From: Amir Goldstein
Date: Fri, 11 Dec 2020 10:19:36 +0200
Subject: [PATCH] fsnotify: fix for fix events reported to watching parent and
child
The child watch is expecting an event without file name and without
the ON_CHILD flag.
Reported-by: Hugh Dickins
Signed-off-by: Amir Goldstein
---
fs/notify/fsnotify.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
index a0da9e766992..30d422b8c0fc 100644
--- a/fs/notify/fsnotify.c
+++ b/fs/notify/fsnotify.c
@@ -291,13 +291,18 @@ static int fsnotify_handle_event(struct fsnotify_group
*group, __u32 mask,
}
if (!inode_mark)
return 0;
+ }
+ if (mask & FS_EVENT_ON_CHILD) {
/*
* Some events can be sent on both parent dir and child marks
* (e.g. FS_ATTRIB). If both parent dir and child are
* watching, report the event once to parent dir with name (if
* interested) and once to child without name (if interested).
+* The child watcher is expecting an event without a file name
+* and without the FS_EVENT_ON_CHILD flag.
*/
+ mask &= ~FS_EVENT_ON_CHILD;
dir = NULL;
name = NULL;
}
--
2.25.1
Re: [PATCH v3 1/1] net/ipv4/inet_fragment: Batch fqdir destroy works
On Fri, Dec 11, 2020 at 9:21 AM SeongJae Park wrote:
>
> From: SeongJae Park
>
> For each 'fqdir_exit()' call, a work for destroy of the 'fqdir' is
> enqueued. The work function, 'fqdir_work_fn()', internally calls
> 'rcu_barrier()'. In case of intensive 'fqdir_exit()' (e.g., frequent
> 'unshare()' systemcalls), this increased contention could result in
> unacceptably high latency of 'rcu_barrier()'. This commit avoids such
> contention by doing the 'rcu_barrier()' and subsequent lightweight works
> in a batched manner using a dedicated singlethread worker, as similar to
> that of 'cleanup_net()'.
Not sure why you submit a patch series with a single patch.
Your cover letter contains interesting info that would better be
captured in this changelog IMO
>
> Signed-off-by: SeongJae Park
> ---
> include/net/inet_frag.h | 1 +
> net/ipv4/inet_fragment.c | 45 +---
> 2 files changed, 39 insertions(+), 7 deletions(-)
>
> diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
> index bac79e817776..48cc5795ceda 100644
> --- a/include/net/inet_frag.h
> +++ b/include/net/inet_frag.h
> @@ -21,6 +21,7 @@ struct fqdir {
> /* Keep atomic mem on separate cachelines in structs that include it
> */
> atomic_long_t mem cacheline_aligned_in_smp;
> struct work_struct destroy_work;
> + struct llist_node free_list;
> };
>
> /**
> diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
> index 10d31733297d..a6fc4afcc323 100644
> --- a/net/ipv4/inet_fragment.c
> +++ b/net/ipv4/inet_fragment.c
> @@ -145,12 +145,17 @@ static void inet_frags_free_cb(void *ptr, void *arg)
> inet_frag_destroy(fq);
> }
>
> -static void fqdir_work_fn(struct work_struct *work)
> +static struct workqueue_struct *fqdir_wq;
> +static LLIST_HEAD(free_list);
> +
> +static void fqdir_free_fn(struct work_struct *work)
> {
> - struct fqdir *fqdir = container_of(work, struct fqdir, destroy_work);
> - struct inet_frags *f = fqdir->f;
> + struct llist_node *kill_list;
> + struct fqdir *fqdir, *tmp;
> + struct inet_frags *f;
>
> - rhashtable_free_and_destroy(&fqdir->rhashtable, inet_frags_free_cb,
> NULL);
> + /* Atomically snapshot the list of fqdirs to free */
> + kill_list = llist_del_all(&free_list);
>
> /* We need to make sure all ongoing call_rcu(...,
> inet_frag_destroy_rcu)
> * have completed, since they need to dereference fqdir.
> @@ -158,12 +163,38 @@ static void fqdir_work_fn(struct work_struct *work)
> */
> rcu_barrier();
>
> - if (refcount_dec_and_test(&f->refcnt))
> - complete(&f->completion);
> + llist_for_each_entry_safe(fqdir, tmp, kill_list, free_list) {
> + f = fqdir->f;
> + if (refcount_dec_and_test(&f->refcnt))
> + complete(&f->completion);
>
> - kfree(fqdir);
> + kfree(fqdir);
> + }
> }
>
> +static DECLARE_WORK(fqdir_free_work, fqdir_free_fn);
> +
> +static void fqdir_work_fn(struct work_struct *work)
> +{
> + struct fqdir *fqdir = container_of(work, struct fqdir, destroy_work);
> +
> + rhashtable_free_and_destroy(&fqdir->rhashtable, inet_frags_free_cb,
> NULL);
> +
> + if (llist_add(&fqdir->free_list, &free_list))
> + queue_work(fqdir_wq, &fqdir_free_work);
I think you misunderstood me.
Since this fqdir_free_work will have at most one instance, you can use
system_wq here, there is no risk of abuse.
My suggestion was to not use system_wq for fqdir_exit(), to better
control the number
of threads in rhashtable cleanups.
void fqdir_exit(struct fqdir *fqdir)
{
INIT_WORK(&fqdir->destroy_work, fqdir_work_fn);
- queue_work(system_wq, &fqdir->destroy_work);
+ queue_work(fqdir_wq, &fqdir->destroy_work);
}
> +}
> +
> +static int __init fqdir_wq_init(void)
> +{
> + fqdir_wq = create_singlethread_workqueue("fqdir");
And here, I suggest to use a non ordered work queue, allowing one
thread per cpu, to allow concurrent rhashtable cleanups
Also "fqdir" name is rather vague, this is an implementation detail ?
fqdir_wq =create_workqueue("inet_frag_wq");
> + if (!fqdir_wq)
> + panic("Could not create fqdir workq");
> + return 0;
> +}
> +
> +pure_initcall(fqdir_wq_init);
> +
> +
> int fqdir_init(struct fqdir **fqdirp, struct inet_frags *f, struct net *net)
> {
> struct fqdir *fqdir = kzalloc(sizeof(*fqdir), GFP_KERNEL);
> --
> 2.17.1
>
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
Hi Greg, On Fri, Dec 11, 2020 at 08:44:29AM +0100, Greg KH wrote: > On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > > raw data between MHI device and host using standard file operations. > > Driver instantiates UCI device object which is associated to device > > file node. UCI device object instantiates UCI channel object when device > > file node is opened. UCI channel object is used to manage MHI channels > > by calling MHI core APIs for read and write operations. MHI channels > > are started as part of device open(). MHI channels remain in start > > state until last release() is called on UCI device file node. Device > > file node is created with format > > > > /dev/ > > > > Currently it supports QMI channel. libqmi is userspace MHI client which > > communicates to a QMI service using QMI channel. libqmi is a glib-based > > library for talking to WWAN modems and devices which speaks QMI protocol. > > For more information about libqmi please refer > > https://www.freedesktop.org/wiki/Software/libqmi/ > > This says _what_ this is doing, but not _why_. > > Why do you want to circumvent the normal user/kernel apis for this type > of device and move the normal network handling logic out to userspace? > What does that help with? What does the current in-kernel api lack that > this userspace interface is going to solve, and why can't the in-kernel > api solve it instead? > Well, this driver is not moving the network handling logic out. Instead this driver just exposes a channel which can be used to configure the modem using the existing userspace library like libqmi. Then the networking logic is handled by a separate in kernel driver called mhi-net which is queued for v5.11. This is same for most of the Qualcomm USB modems as well. They expose a chardev node like /dev/cdc_wdm0 for configuration and once configured the networking logic is handled by usual network interface wwan0. The difference here is that the underlying physical layer is PCIe and there is this MHI bus which sits on top of it. > You are pushing a common user/kernel api out of the kernel here, to > become very device-specific, with no apparent justification as to why > this is happening. > > Also, because you are going around the existing network api, I will need > the networking maintainers to ack this type of patch. > No, this driver is not at all touching the networking part. As said, the networking logic is all handled by mhi-net driver. Thanks, Mani > thanks, > > greg k-h
[PATCH -next] regulator: wm831x-isink: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/regulator/wm831x-isink.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/wm831x-isink.c b/drivers/regulator/wm831x-isink.c index eade3ae3e333..76d9b0434c70 100644 --- a/drivers/regulator/wm831x-isink.c +++ b/drivers/regulator/wm831x-isink.c @@ -146,10 +146,10 @@ static int wm831x_isink_probe(struct platform_device *pdev) isink->desc.ops = &wm831x_isink_ops; isink->desc.type = REGULATOR_CURRENT; isink->desc.owner = THIS_MODULE; - isink->desc.curr_table = wm831x_isinkv_values, - isink->desc.n_current_limits = ARRAY_SIZE(wm831x_isinkv_values), - isink->desc.csel_reg = isink->reg, - isink->desc.csel_mask = WM831X_CS1_ISEL_MASK, + isink->desc.curr_table = wm831x_isinkv_values; + isink->desc.n_current_limits = ARRAY_SIZE(wm831x_isinkv_values); + isink->desc.csel_reg = isink->reg; + isink->desc.csel_mask = WM831X_CS1_ISEL_MASK; config.dev = pdev->dev.parent; config.init_data = pdata->isink[id]; -- 2.22.0
[PATCH -next] regulator: mc13892-regulator: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/regulator/mc13892-regulator.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/regulator/mc13892-regulator.c b/drivers/regulator/mc13892-regulator.c index a731e826a037..5221f7a9df91 100644 --- a/drivers/regulator/mc13892-regulator.c +++ b/drivers/regulator/mc13892-regulator.c @@ -582,8 +582,8 @@ static int mc13892_regulator_probe(struct platform_device *pdev) /* update mc13892_vcam ops */ memcpy(&mc13892_vcam_ops, mc13892_regulators[MC13892_VCAM].desc.ops, sizeof(struct regulator_ops)); - mc13892_vcam_ops.set_mode = mc13892_vcam_set_mode, - mc13892_vcam_ops.get_mode = mc13892_vcam_get_mode, + mc13892_vcam_ops.set_mode = mc13892_vcam_set_mode; + mc13892_vcam_ops.get_mode = mc13892_vcam_get_mode; mc13892_regulators[MC13892_VCAM].desc.ops = &mc13892_vcam_ops; mc13xxx_data = mc13xxx_parse_regulators_dt(pdev, mc13892_regulators, -- 2.22.0
Re: [PATCH v1] usb: typec: tcpm: Update vbus_vsafe0v on init
On Thu, Dec 10, 2020 at 11:19:11PM -0800, Badhri Jagan Sridharan wrote: > During init, vbus_vsafe0v does not get updated till the first > connect as a sink. This causes TCPM to be stuck in SRC_ATTACH_WAIT > state while booting with a sink (For instance: a headset) connected. > > [1.429168] Start toggling > [1.439907] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, > disconnected] > [1.445242] CC1: 0 -> 0, CC2: 0 -> 0 [state TOGGLING, polarity 0, > disconnected] > [ 53.358528] CC1: 0 -> 0, CC2: 0 -> 2 [state TOGGLING, polarity 0, > connected] > [ 53.358564] state change TOGGLING -> SRC_ATTACH_WAIT [rev1 NONE_AMS] > > Fix this by updating vbus_vsafe0v based on vbus_present status > on boot. > > Signed-off-by: Badhri Jagan Sridharan One nitpick bellow, but it's so minor that you can ignore it if you like. FWIW: Reviewed-by: Heikki Krogerus > --- > drivers/usb/typec/tcpm/tcpm.c | 18 ++ > 1 file changed, 18 insertions(+) > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > index cedc6cf82d61..58a6302c549f 100644 > --- a/drivers/usb/typec/tcpm/tcpm.c > +++ b/drivers/usb/typec/tcpm/tcpm.c > @@ -4794,6 +4794,24 @@ static void tcpm_init(struct tcpm_port *port) > if (port->vbus_present) > port->vbus_never_low = true; > > + /* > + * 1. When vbus_present is true, voltage on VBUS is already at VSAFE5V. > + * So implicitly vbus_vsafe0v = false. > + * > + * 2. When vbus_present is false and TCPC does NOT support querying > + * vsafe0v status, then, it's best to assume vbus is at VSAFE0V i.e. > + * vbus_vsafe0v is true. > + * > + * 3. When vbus_present is false and TCPC does support querying vsafe0v, > + * then, query tcpc for vsafe0v status. > + */ > + if (port->vbus_present) > + port->vbus_vsafe0v = false; > + else if (!port->tcpc->is_vbus_vsafe0v) > + port->vbus_vsafe0v = true; > + else > + port->vbus_vsafe0v = port->tcpc->is_vbus_vsafe0v(port->tcpc); Couldn't that be the other way around? ... else if (port->tcpc->is_vbus_vsafe0v) port->vbus_vsafe0v = port->tcpc->is_vbus_vsafe0v(port->tcpc); else port->vbus_vsafe0v = true; ... > tcpm_set_state(port, tcpm_default_state(port), 0); > > if (port->tcpc->get_cc(port->tcpc, &cc1, &cc2) == 0) > -- > 2.29.2.576.ga3fc446d84-goog thanks, -- heikki
[PATCH -next] mfd: rave-sp: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/mfd/rave-sp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mfd/rave-sp.c b/drivers/mfd/rave-sp.c index 545196c85b5c..abb9cbdabaa9 100644 --- a/drivers/mfd/rave-sp.c +++ b/drivers/mfd/rave-sp.c @@ -358,7 +358,7 @@ int rave_sp_exec(struct rave_sp *sp, ackid = atomic_inc_return(&sp->ackid); reply.ackid = ackid; - reply.code = rave_sp_reply_code((u8)command), + reply.code = rave_sp_reply_code((u8)command); mutex_lock(&sp->bus_lock); -- 2.22.0
[PATCH -next] pinctrl/pinctrl-at91: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/pinctrl/pinctrl-at91.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c index 72edc675431c..47b19d3a48cf 100644 --- a/drivers/pinctrl/pinctrl-at91.c +++ b/drivers/pinctrl/pinctrl-at91.c @@ -1742,7 +1742,7 @@ static int at91_gpio_of_irq_setup(struct platform_device *pdev, gpio_irqchip->irq_disable = gpio_irq_mask; gpio_irqchip->irq_mask = gpio_irq_mask; gpio_irqchip->irq_unmask = gpio_irq_unmask; - gpio_irqchip->irq_set_wake = gpio_irq_set_wake, + gpio_irqchip->irq_set_wake = gpio_irq_set_wake; gpio_irqchip->irq_set_type = at91_gpio->ops->irq_type; /* Disable irqs of this PIO controller */ -- 2.22.0
Re: [PATCH 4.19 15/39] ALSA: hda/generic: Add option to enforce preferred_dacs pairs
On Fri, 11 Dec 2020 09:36:21 +0100, Pavel Machek wrote: > > Hi! > > > From: Takashi Iwai > > > > commit 242d990c158d5b1dabd166516e21992baef5f26a upstream. > > > > The generic parser accepts the preferred_dacs[] pairs as a hint for > > assigning a DAC to each pin, but this hint doesn't work always > > effectively. Currently it's merely a secondary choice after the trial > > with the path index failed. This made sometimes it difficult to > > assign DACs without mimicking the connection list and/or the badness > > table. > > > > This patch adds a new flag, obey_preferred_dacs, that changes the > > behavior of the parser. As its name stands, the parser obeys the > > Option added is never used as variable is never set. We don't need > this in 4.19. Right, it seems that the succeeding fix is queued only for 5.4 and 5.9. OTOH, this change will help if another quirk is added in near future, and it's pretty safe to apply, so I think it's worth to keep it. thanks, Takashi
Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open
On 10. 12. 20, 19:59, Mychaela Falconia wrote: O_DIRECT is an interesting hack, has anyone seen if it violates the posix rules for us to use it on a character device like this? According to open(2) Linux man page, O_DIRECT does not come from POSIX at all, instead it is specific to Linux, FreeBSD and SGI IRIX. Thus it seems like there aren't any POSIX rules to be violated here. If we go with O_DIRECT, what semantics are we going to implement? There are 3 possibilities that come to mind most readily: 1) O_DIRECT applies only to the open call in which this flag is set, and suppresses DTR/RTS assertion on that open. If someone needs to do multiple opens with DTR/RTS suppression being required every time, then they need to include O_DIRECT every time. 2) O_DIRECT applies not only immediately, but also sets a latched flag whereby all subsequent opens continue to suppress auto-assertion without requiring O_DIRECT every time. This approach by itself runs counter to the generic Unix way of doing things, but it may be OK if there is also some ioctl to explicitly set or clear the latched flag. 3) O_DIRECT applies only to the open call in which it is set, no built-in latching, but there is also some ioctl to control a flag enabling or disabling DTR/RTS auto-assertion on subsequent opens. 3) -- to allow standard tools to work on the device after the quirk is set up once. thanks, -- js
[PATCH -next] mediatek/pinctrl-paris: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/pinctrl/mediatek/pinctrl-paris.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/mediatek/pinctrl-paris.c b/drivers/pinctrl/mediatek/pinctrl-paris.c index 623af4410b07..d27b9278ecb3 100644 --- a/drivers/pinctrl/mediatek/pinctrl-paris.c +++ b/drivers/pinctrl/mediatek/pinctrl-paris.c @@ -891,8 +891,8 @@ static int mtk_build_gpiochip(struct mtk_pinctrl *hw, struct device_node *np) chip->direction_output = mtk_gpio_direction_output; chip->get = mtk_gpio_get; chip->set = mtk_gpio_set; - chip->to_irq= mtk_gpio_to_irq, - chip->set_config= mtk_gpio_set_config, + chip->to_irq= mtk_gpio_to_irq; + chip->set_config= mtk_gpio_set_config; chip->base = -1; chip->ngpio = hw->soc->npins; chip->of_node = np; -- 2.22.0
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
On Fri, 11 Dec 2020 at 08:44, Greg KH wrote: > > On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer > > raw data between MHI device and host using standard file operations. > > Driver instantiates UCI device object which is associated to device > > file node. UCI device object instantiates UCI channel object when device > > file node is opened. UCI channel object is used to manage MHI channels > > by calling MHI core APIs for read and write operations. MHI channels > > are started as part of device open(). MHI channels remain in start > > state until last release() is called on UCI device file node. Device > > file node is created with format > > > > /dev/ > > > > Currently it supports QMI channel. libqmi is userspace MHI client which > > communicates to a QMI service using QMI channel. libqmi is a glib-based > > library for talking to WWAN modems and devices which speaks QMI protocol. > > For more information about libqmi please refer > > https://www.freedesktop.org/wiki/Software/libqmi/ > > This says _what_ this is doing, but not _why_. > > Why do you want to circumvent the normal user/kernel apis for this type > of device and move the normal network handling logic out to userspace? > What does that help with? What does the current in-kernel api lack that > this userspace interface is going to solve, and why can't the in-kernel > api solve it instead? > > You are pushing a common user/kernel api out of the kernel here, to > become very device-specific, with no apparent justification as to why > this is happening. That would probably deserve re-wording indeed. This interface offers access to the modem control channel(s), which can be QMI (added in this patch), MBIM, or the old known AT protocol. Because there is no WWAN subsystem, these control pipes are directly exposed to userspace and accessed by tools like libqmi, ModemManager, minicom (for AT) etc... However, the data path, transporting the network payload (IP) is well routed to the Linux network via the mhi-net driver. > > Also, because you are going around the existing network api, I will need > the networking maintainers to ack this type of patch.
[PATCH -next] mediatek/pinctrl-moore: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/pinctrl/mediatek/pinctrl-moore.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/pinctrl/mediatek/pinctrl-moore.c b/drivers/pinctrl/mediatek/pinctrl-moore.c index 5e00f93ac998..0fa7de43bc4c 100644 --- a/drivers/pinctrl/mediatek/pinctrl-moore.c +++ b/drivers/pinctrl/mediatek/pinctrl-moore.c @@ -514,8 +514,8 @@ static int mtk_build_gpiochip(struct mtk_pinctrl *hw, struct device_node *np) chip->direction_output = mtk_gpio_direction_output; chip->get = mtk_gpio_get; chip->set = mtk_gpio_set; - chip->to_irq= mtk_gpio_to_irq, - chip->set_config= mtk_gpio_set_config, + chip->to_irq= mtk_gpio_to_irq; + chip->set_config= mtk_gpio_set_config; chip->base = -1; chip->ngpio = hw->soc->npins; chip->of_node = np; -- 2.22.0
Re: [GIT PULL] extcon next for v5.11
On Fri, Dec 11, 2020 at 05:27:24PM +0900, Chanwoo Choi wrote: > Dear Greg, > > This is extcon-next pull request for v5.11. I add detailed description of > this pull request on below. Please pull extcon with following updates. > > Best Regards, > Chanwoo Choi > > > The following changes since commit 0477e92881850d44910a7e94fc2c46f96faa131f: > > Linux 5.10-rc7 (2020-12-06 14:25:12 -0800) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git > tags/extcon-next-for-5.11 Pulled and pushed out, thanks. greg k-h
[PATCH] net: fs_enet: remove casting dma_alloc_coherent
Remove casting the values returned by dma_alloc_coherent. Signed-off-by: Xu Wang --- drivers/net/ethernet/freescale/fs_enet/mac-fcc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c b/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c index b47490be872c..17f757c0bb85 100644 --- a/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c +++ b/drivers/net/ethernet/freescale/fs_enet/mac-fcc.c @@ -147,7 +147,7 @@ static int allocate_bd(struct net_device *dev) struct fs_enet_private *fep = netdev_priv(dev); const struct fs_platform_info *fpi = fep->fpi; - fep->ring_base = (void __iomem __force *)dma_alloc_coherent(fep->dev, + fep->ring_base = dma_alloc_coherent(fep->dev, (fpi->tx_ring + fpi->rx_ring) * sizeof(cbd_t), &fep->ring_mem_addr, GFP_KERNEL); -- 2.17.1
[PATCH -next] ti/pinctrl-ti-iodelay: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/pinctrl/ti/pinctrl-ti-iodelay.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/ti/pinctrl-ti-iodelay.c b/drivers/pinctrl/ti/pinctrl-ti-iodelay.c index cfb924228d87..ae91559bd4a1 100644 --- a/drivers/pinctrl/ti/pinctrl-ti-iodelay.c +++ b/drivers/pinctrl/ti/pinctrl-ti-iodelay.c @@ -704,7 +704,7 @@ static void ti_iodelay_pinconf_group_dbg_show(struct pinctrl_dev *pctldev, u32 reg = 0; cfg = &group->cfg[i]; - regmap_read(iod->regmap, cfg->offset, ®), + regmap_read(iod->regmap, cfg->offset, ®); seq_printf(s, "\n\t0x%08x = 0x%08x (%3d, %3d)", cfg->offset, reg, cfg->a_delay, cfg->g_delay); -- 2.22.0
[PATCH -next] input: serio: convert comma to semicolon
Replace a comma between expression statements by a semicolon.
Signed-off-by: Zheng Yongjun
---
drivers/input/serio/parkbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/serio/parkbd.c b/drivers/input/serio/parkbd.c
index ddbbd4afb4a2..3ac57a91ede4 100644
--- a/drivers/input/serio/parkbd.c
+++ b/drivers/input/serio/parkbd.c
@@ -168,7 +168,7 @@ static struct serio *parkbd_allocate_serio(void)
serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
if (serio) {
serio->id.type = parkbd_mode;
- serio->write = parkbd_write,
+ serio->write = parkbd_write;
strlcpy(serio->name, "PARKBD AT/XT keyboard adapter",
sizeof(serio->name));
snprintf(serio->phys, sizeof(serio->phys), "%s/serio0",
parkbd_dev->port->name);
}
--
2.22.0
Re: objtool crashes with some clang produced .o files
On Thu, Dec 10, 2020 at 03:35:45PM -0800, Nick Desaulniers wrote:
> On Thu, Dec 3, 2020 at 5:56 AM Arnd Bergmann wrote:
> >
> > I see occasional randconfig builds failing on x86 with clang-11
> > and clang-12 when objtool crashes with a segmentation fault.
> >
> > The simplest test case I managed to create is
> >
> > $ echo "__SCK__tp_func_cdev_update() { __SCT__tp_func_cdev_update(); }" >
> > file.c
> So some instruction in .text that contained a relocation for, we could
> not determine a symbol for? I'm curious why we're even in this loop
> though, since we didn't do anything related to static calls...
No you did, you called a __SCT*() function, which is a
static-call-trampoline. objtool does indeed assume it then has a symbol
for the matching key, which should be guaranteed by the __ADDRESSABLE()
in __static_call().
>From linux/static_call.h:
/*
* __ADDRESSABLE() is used to ensure the key symbol doesn't get stripped from
* the symbol table so that objtool can reference it when it generates the
* .static_call_sites section.
*/
#define __static_call(name) \
({ \
__ADDRESSABLE(STATIC_CALL_KEY(name)); \
&STATIC_CALL_TRAMP(name); \
})
Let me go find a copy of clang-11..
[PATCH -next] input: misc: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/input/misc/ixp4xx-beeper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/input/misc/ixp4xx-beeper.c b/drivers/input/misc/ixp4xx-beeper.c index 794ecc9a552d..05018d0c97c7 100644 --- a/drivers/input/misc/ixp4xx-beeper.c +++ b/drivers/input/misc/ixp4xx-beeper.c @@ -97,7 +97,7 @@ static int ixp4xx_spkr_probe(struct platform_device *dev) input_set_drvdata(input_dev, (void *) dev->id); - input_dev->name = "ixp4xx beeper", + input_dev->name = "ixp4xx beeper"; input_dev->phys = "ixp4xx/gpio"; input_dev->id.bustype = BUS_HOST; input_dev->id.vendor = 0x001f; -- 2.22.0
[PATCH -next] ti/phy-j721e-wiz: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/phy/ti/phy-j721e-wiz.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c index c9cfafe89cbf..73eb92b5817b 100644 --- a/drivers/phy/ti/phy-j721e-wiz.c +++ b/drivers/phy/ti/phy-j721e-wiz.c @@ -922,8 +922,8 @@ static int wiz_probe(struct platform_device *pdev) phy_reset_dev = &wiz->wiz_phy_reset_dev; phy_reset_dev->dev = dev; - phy_reset_dev->ops = &wiz_phy_reset_ops, - phy_reset_dev->owner = THIS_MODULE, + phy_reset_dev->ops = &wiz_phy_reset_ops; + phy_reset_dev->owner = THIS_MODULE; phy_reset_dev->of_node = node; /* Reset for each of the lane and one for the entire SERDES */ phy_reset_dev->nr_resets = num_lanes + 1; -- 2.22.0
[PATCH -next] md/raid10: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/md/raid10.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c index b7bca6703df8..acf4df3d971f 100644 --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -2459,7 +2459,7 @@ static void fix_recovery_read_error(struct r10bio *r10_bio) s = PAGE_SIZE >> 9; rdev = conf->mirrors[dr].rdev; - addr = r10_bio->devs[0].addr + sect, + addr = r10_bio->devs[0].addr + sect; ok = sync_page_io(rdev, addr, s << 9, -- 2.22.0
[PATCH] lib/find_bit_bench: fix the unmatched iterations cnt
We should have same iteration count when we walk the same bitmap
regardless of using find_next_bit or find_last_bit.
When we run the find_bit_benchmark.ko, we sometime get
unmatched iterations count below:
Start testing find_bit() with random-filled bitmap
[+...] find_next_bit: 875085 ns, 163755 iterations <
[+...] find_next_zero_bit: 865319 ns, 163926 iterations
[+...] find_last_bit: 611807 ns, 163756 iterations <
[+...] find_first_bit:1601016 ns, 16335 iterations
[+...] find_next_and_bit: 400645 ns, 74040 iterations
[+...]
Start testing find_bit() with sparse bitmap
[+...] find_next_bit:9942 ns,654 iterations
[+...] find_next_zero_bit:1678445 ns, 327027 iterations
[+...] find_last_bit:7131 ns,654 iterations
[+...] find_first_bit: 551383 ns,654 iterations
[+...] find_next_and_bit:3027 ns, 1 iterations
Normally, this is happen when the last bit of bitmap was set.
This patch fix the unmatched iterations count between
test_find_next_bit and test_find_last_bit.
Signed-off-by: Levi Yun
---
lib/find_bit_benchmark.c | 30 --
1 file changed, 16 insertions(+), 14 deletions(-)
diff --git a/lib/find_bit_benchmark.c b/lib/find_bit_benchmark.c
index 5637c5711db9..766e0487852b 100644
--- a/lib/find_bit_benchmark.c
+++ b/lib/find_bit_benchmark.c
@@ -35,14 +35,14 @@ static DECLARE_BITMAP(bitmap2, BITMAP_LEN) __initdata;
*/
static int __init test_find_first_bit(void *bitmap, unsigned long len)
{
- unsigned long i, cnt;
+ unsigned long i = 0, cnt = 0;
ktime_t time;
time = ktime_get();
- for (cnt = i = 0; i < len; cnt++) {
+ do {
i = find_first_bit(bitmap, len);
__clear_bit(i, bitmap);
- }
+ } while (i++ < len && ++cnt);
time = ktime_get() - time;
pr_err("find_first_bit: %18llu ns, %6ld iterations\n", time, cnt);
@@ -51,12 +51,13 @@ static int __init test_find_first_bit(void *bitmap,
unsigned long len)
static int __init test_find_next_bit(const void *bitmap, unsigned long len)
{
- unsigned long i, cnt;
+ unsigned long i = 0, cnt = 0;
ktime_t time;
time = ktime_get();
- for (cnt = i = 0; i < BITMAP_LEN; cnt++)
- i = find_next_bit(bitmap, BITMAP_LEN, i) + 1;
+ do {
+ i = find_next_bit(bitmap, BITMAP_LEN, i);
+ } while (i++ < BITMAP_LEN && ++cnt);
time = ktime_get() - time;
pr_err("find_next_bit: %18llu ns, %6ld iterations\n", time, cnt);
@@ -65,12 +66,13 @@ static int __init test_find_next_bit(const void *bitmap,
unsigned long len)
static int __init test_find_next_zero_bit(const void *bitmap, unsigned long
len)
{
- unsigned long i, cnt;
+ unsigned long i = 0, cnt = 0;
ktime_t time;
time = ktime_get();
- for (cnt = i = 0; i < BITMAP_LEN; cnt++)
- i = find_next_zero_bit(bitmap, len, i) + 1;
+ do {
+ i = find_next_zero_bit(bitmap, len, i);
+ } while (i++ < BITMAP_LEN && ++cnt);
time = ktime_get() - time;
pr_err("find_next_zero_bit: %18llu ns, %6ld iterations\n", time, cnt);
@@ -84,12 +86,11 @@ static int __init test_find_last_bit(const void *bitmap,
unsigned long len)
time = ktime_get();
do {
- cnt++;
l = find_last_bit(bitmap, len);
if (l >= len)
break;
len = l;
- } while (len);
+ } while (len >= 0 && ++cnt);
time = ktime_get() - time;
pr_err("find_last_bit: %18llu ns, %6ld iterations\n", time, cnt);
@@ -99,12 +100,13 @@ static int __init test_find_last_bit(const void *bitmap,
unsigned long len)
static int __init test_find_next_and_bit(const void *bitmap,
const void *bitmap2, unsigned long len)
{
- unsigned long i, cnt;
+ unsigned long i = 0, cnt = 0;
ktime_t time;
time = ktime_get();
- for (cnt = i = 0; i < BITMAP_LEN; cnt++)
- i = find_next_and_bit(bitmap, bitmap2, BITMAP_LEN, i + 1);
+ do {
+ i = find_next_and_bit(bitmap, bitmap2, BITMAP_LEN, i);
+ } while (i++ < BITMAP_LEN && ++cnt);
time = ktime_get() - time;
pr_err("find_next_and_bit: %18llu ns, %6ld iterations\n", time, cnt);
--
2.27.0
[PATCH -next] md/bcache: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/md/bcache/sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/bcache/sysfs.c b/drivers/md/bcache/sysfs.c index 554e3afc9b68..00a520c03f41 100644 --- a/drivers/md/bcache/sysfs.c +++ b/drivers/md/bcache/sysfs.c @@ -404,7 +404,7 @@ STORE(__cached_dev) if (!env) return -ENOMEM; add_uevent_var(env, "DRIVER=bcache"); - add_uevent_var(env, "CACHED_UUID=%pU", dc->sb.uuid), + add_uevent_var(env, "CACHED_UUID=%pU", dc->sb.uuid); add_uevent_var(env, "CACHED_LABEL=%s", buf); kobject_uevent_env(&disk_to_dev(dc->disk.disk)->kobj, KOBJ_CHANGE, -- 2.22.0
[PATCH wireless -next] wireless: mt76: mt7915: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c index 0fd3a16f736a..a2c655c4021f 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c @@ -1676,7 +1676,7 @@ mt7915_mcu_wtbl_ht_tlv(struct sk_buff *skb, struct ieee80211_sta *sta, tlv = mt7915_mcu_add_nested_tlv(skb, WTBL_VHT, sizeof(*vht), wtbl_tlv, sta_wtbl); vht = (struct wtbl_vht *)tlv; - vht->ldpc = sta->vht_cap.cap & IEEE80211_VHT_CAP_RXLDPC, + vht->ldpc = sta->vht_cap.cap & IEEE80211_VHT_CAP_RXLDPC; vht->vht = true; af = FIELD_GET(IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK, -- 2.22.0
[GIT PULL] xen: branch for v5.10-rc8
Linus, Please git pull the following tag: git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git for-linus-5.10c-rc8-tag xen: branch for v5.10-rc8 It contains a short series fixing a regression introduced in 5.9 for running as Xen dom0 on a system with NVMe backed storage. Thanks. Juergen drivers/block/xen-blkback/blkback.c | 89 +- drivers/block/xen-blkback/common.h | 4 +- drivers/block/xen-blkback/xenbus.c | 6 +- drivers/xen/grant-table.c | 123 drivers/xen/unpopulated-alloc.c | 20 +++--- drivers/xen/xen-scsiback.c | 60 -- include/xen/grant_table.h | 17 + 7 files changed, 182 insertions(+), 137 deletions(-) Juergen Gross (2): xen: add helpers for caching grant mapping pages xen: don't use page->lru for ZONE_DEVICE memory
[PATCH] net: ethernet: fs-enet: remove casting dma_alloc_coherent
Remove casting the values returned by dma_alloc_coherent. Signed-off-by: Xu Wang --- drivers/net/ethernet/freescale/fs_enet/mac-fec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/freescale/fs_enet/mac-fec.c b/drivers/net/ethernet/freescale/fs_enet/mac-fec.c index 99fe2c210d0f..3ae345676e50 100644 --- a/drivers/net/ethernet/freescale/fs_enet/mac-fec.c +++ b/drivers/net/ethernet/freescale/fs_enet/mac-fec.c @@ -131,7 +131,7 @@ static int allocate_bd(struct net_device *dev) struct fs_enet_private *fep = netdev_priv(dev); const struct fs_platform_info *fpi = fep->fpi; - fep->ring_base = (void __force __iomem *)dma_alloc_coherent(fep->dev, + fep->ring_base = dma_alloc_coherent(fep->dev, (fpi->tx_ring + fpi->rx_ring) * sizeof(cbd_t), &fep->ring_mem_addr, GFP_KERNEL); -- 2.17.1
[PATCH -next] usb: phy: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/usb/phy/phy-isp1301-omap.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/usb/phy/phy-isp1301-omap.c b/drivers/usb/phy/phy-isp1301-omap.c index 4a6462c92ef2..6f4f74e6ba51 100644 --- a/drivers/usb/phy/phy-isp1301-omap.c +++ b/drivers/usb/phy/phy-isp1301-omap.c @@ -1566,13 +1566,13 @@ isp1301_probe(struct i2c_client *i2c, const struct i2c_device_id *id) isp->phy.dev = &i2c->dev; isp->phy.label = DRIVER_NAME; - isp->phy.set_power = isp1301_set_power, + isp->phy.set_power = isp1301_set_power; isp->phy.otg->usb_phy = &isp->phy; - isp->phy.otg->set_host = isp1301_set_host, - isp->phy.otg->set_peripheral = isp1301_set_peripheral, - isp->phy.otg->start_srp = isp1301_start_srp, - isp->phy.otg->start_hnp = isp1301_start_hnp, + isp->phy.otg->set_host = isp1301_set_host; + isp->phy.otg->set_peripheral = isp1301_set_peripheral; + isp->phy.otg->start_srp = isp1301_start_srp; + isp->phy.otg->start_hnp = isp1301_start_hnp; enable_vbus_draw(isp, 0); power_down(isp); -- 2.22.0
[PATCH -next] usb: ucsi: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/usb/typec/ucsi/psy.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/typec/ucsi/psy.c b/drivers/usb/typec/ucsi/psy.c index 571a51e16234..56bf56517f75 100644 --- a/drivers/usb/typec/ucsi/psy.c +++ b/drivers/usb/typec/ucsi/psy.c @@ -220,11 +220,11 @@ int ucsi_register_port_psy(struct ucsi_connector *con) return -ENOMEM; con->psy_desc.name = psy_name; - con->psy_desc.type = POWER_SUPPLY_TYPE_USB, + con->psy_desc.type = POWER_SUPPLY_TYPE_USB; con->psy_desc.usb_types = ucsi_psy_usb_types; con->psy_desc.num_usb_types = ARRAY_SIZE(ucsi_psy_usb_types); - con->psy_desc.properties = ucsi_psy_props, - con->psy_desc.num_properties = ARRAY_SIZE(ucsi_psy_props), + con->psy_desc.properties = ucsi_psy_props; + con->psy_desc.num_properties = ARRAY_SIZE(ucsi_psy_props); con->psy_desc.get_property = ucsi_psy_get_prop; con->psy = power_supply_register(dev, &con->psy_desc, &psy_cfg); -- 2.22.0
[PATCH -next] usb: typec: tcpm: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/usb/typec/tcpm/tcpm.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index a6fae1f86505..4451507d600c 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -5024,14 +5024,14 @@ static int devm_tcpm_psy_register(struct tcpm_port *port) snprintf(psy_name, psy_name_len, "%s%s", tcpm_psy_name_prefix, port_dev_name); port->psy_desc.name = psy_name; - port->psy_desc.type = POWER_SUPPLY_TYPE_USB, + port->psy_desc.type = POWER_SUPPLY_TYPE_USB; port->psy_desc.usb_types = tcpm_psy_usb_types; port->psy_desc.num_usb_types = ARRAY_SIZE(tcpm_psy_usb_types); - port->psy_desc.properties = tcpm_psy_props, - port->psy_desc.num_properties = ARRAY_SIZE(tcpm_psy_props), - port->psy_desc.get_property = tcpm_psy_get_prop, - port->psy_desc.set_property = tcpm_psy_set_prop, - port->psy_desc.property_is_writeable = tcpm_psy_prop_writeable, + port->psy_desc.properties = tcpm_psy_props; + port->psy_desc.num_properties = ARRAY_SIZE(tcpm_psy_props); + port->psy_desc.get_property = tcpm_psy_get_prop; + port->psy_desc.set_property = tcpm_psy_set_prop; + port->psy_desc.property_is_writeable = tcpm_psy_prop_writeable; port->usb_type = POWER_SUPPLY_USB_TYPE_C; -- 2.22.0
[GIT PULL] MMC fixes for v5.10-rc8
Hi Linus, Here's a PR with a couple of MMC fixes intended for v5.10-rc8. Details about the highlights are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit d06d60d52ec0b0eef702dd3e7b4699f0b589ad0f: mmc: sdhci-of-arasan: Issue DLL reset explicitly (2020-11-17 12:44:44 +0100) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.10-rc4-2 for you to fetch changes up to c0d638a03bc5dfdb08fb95d0a79ecada25f40da8: mmc: mediatek: mark PM functions as __maybe_unused (2020-12-04 15:35:54 +0100) MMC core: - Fixup condition for CMD13 polling for RPMB requests MMC host: - mtk-sd: Fix system suspend/resume support for CQHCI - mtd-sd: Extend SDIO IRQ fix to more variants - sdhci-of-arasan: Fix clock registration error for Keem Bay SOC - tmio: Bring HW to a sane state after a power off Arnd Bergmann (1): mmc: mediatek: mark PM functions as __maybe_unused Bean Huo (1): mmc: block: Fixup condition for CMD13 polling for RPMB requests Muhammad Husaini Zulkifli (1): mmc: sdhci-of-arasan: Fix clock registration error for Keem Bay SOC Wenbin Mei (1): mmc: mediatek: Fix system suspend/resume support for CQHCI Wolfram Sang (1): mmc: tmio: improve bringing HW to a sane state with MMC_POWER_OFF yong mao (1): mmc: mediatek: Extend recheck_sdio_irq fix to more variants drivers/mmc/core/block.c | 2 +- drivers/mmc/host/mtk-sd.c | 39 +++--- drivers/mmc/host/sdhci-of-arasan.c | 3 +++ drivers/mmc/host/tmio_mmc_core.c | 6 +++--- 4 files changed, 35 insertions(+), 15 deletions(-)
[PATCH -next] iio: chemical: pms7003: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/iio/chemical/pms7003.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/chemical/pms7003.c b/drivers/iio/chemical/pms7003.c index e9d4405654bc..e9857d93b307 100644 --- a/drivers/iio/chemical/pms7003.c +++ b/drivers/iio/chemical/pms7003.c @@ -282,7 +282,7 @@ static int pms7003_probe(struct serdev_device *serdev) state->serdev = serdev; indio_dev->info = &pms7003_info; indio_dev->name = PMS7003_DRIVER_NAME; - indio_dev->channels = pms7003_channels, + indio_dev->channels = pms7003_channels; indio_dev->num_channels = ARRAY_SIZE(pms7003_channels); indio_dev->modes = INDIO_DIRECT_MODE; indio_dev->available_scan_masks = pms7003_scan_masks; -- 2.22.0
Re: [PATCH v17 3/3] bus: mhi: Add userspace client interface driver
Hi, Maybe it is a good idea to take QMI as example. QMI is QUALCOMM private protocol, maybe lots of people do not know what is QMI? MHI device can be WIFI device or WWAN device, if it is WIFI device, it is a pure network device, and maybe do not need this driver. But for WWAN devices, it support AT/NMEA/QMI/MBIM etc. protocol. And this driver is work for these functions. There are similar drivers in the kernel for WWAN devices base on USB interface. Like drivers/usb/class/cdc-wdm.c (for QMI & MBIM), and drivers/usb/serial/usb_wwan.c (for AT/NMEA) For USB WWAN devices, open source softwares libqmi/libmbim/ModemManager/LVFS want to commutate with WWAN devices via above 2 drivers. For MHI WWAN devices, these open source software also need such driver. On 11 Dec 2020 08:44:29, Greg KH wrote: > On Thu, Dec 10, 2020 at 11:04:11PM -0800, Hemant Kumar wrote: > > This MHI client driver allows userspace clients to transfer raw data > > between MHI device and host using standard file operations. > > Driver instantiates UCI device object which is associated to device > > file node. UCI device object instantiates UCI channel object when > > device file node is opened. UCI channel object is used to manage MHI > > channels by calling MHI core APIs for read and write operations. MHI > > channels are started as part of device open(). MHI channels remain in > > start state until last release() is called on UCI device file node. > > Device file node is created with format > > > > /dev/ > > > > Currently it supports QMI channel. libqmi is userspace MHI client > > which communicates to a QMI service using QMI channel. libqmi is a > > glib-based library for talking to WWAN modems and devices which speaks QMI > protocol. > > For more information about libqmi please refer > > https://www.freedesktop.org/wiki/Software/libqmi/ > > This says _what_ this is doing, but not _why_. > > Why do you want to circumvent the normal user/kernel apis for this type of > device and move the normal network handling logic out to userspace? > What does that help with? What does the current in-kernel api lack that this > userspace interface is going to solve, and why can't the in-kernel api solve > it > instead? > > You are pushing a common user/kernel api out of the kernel here, to become > very device-specific, with no apparent justification as to why this is > happening. > > Also, because you are going around the existing network api, I will need the > networking maintainers to ack this type of patch. > > thanks, > > greg k-h > > >
linux-next: manual merge of the akpm-current tree with the tip tree
Hi all,
Today's linux-next merge of the akpm-current tree got a conflict in:
mm/gup.c
between commit:
2a4a06da8a4b ("mm/gup: Provide gup_get_pte() more generic")
from the tip tree and commit:
1eb2fe862a51 ("mm/gup: combine put_compound_head() and unpin_user_page()")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc mm/gup.c
index 44b0c6b89602,b3d852b4a60c..
--- a/mm/gup.c
+++ b/mm/gup.c
@@@ -2062,29 -1977,62 +1977,6 @@@ EXPORT_SYMBOL(get_user_pages_unlocked)
* This code is based heavily on the PowerPC implementation by Nick Piggin.
*/
#ifdef CONFIG_HAVE_FAST_GUP
-#ifdef CONFIG_GUP_GET_PTE_LOW_HIGH
--
- static void put_compound_head(struct page *page, int refs, unsigned int flags)
-/*
- * WARNING: only to be used in the get_user_pages_fast() implementation.
- *
- * With get_user_pages_fast(), we walk down the pagetables without taking any
- * locks. For this we would like to load the pointers atomically, but
sometimes
- * that is not possible (e.g. without expensive cmpxchg8b on x86_32 PAE).
What
- * we do have is the guarantee that a PTE will only either go from not present
- * to present, or present to not present or both -- it will not switch to a
- * completely different present page without a TLB flush in between; something
- * that we are blocking by holding interrupts off.
- *
- * Setting ptes from not present to present goes:
- *
- * ptep->pte_high = h;
- * smp_wmb();
- * ptep->pte_low = l;
- *
- * And present to not present goes:
- *
- * ptep->pte_low = 0;
- * smp_wmb();
- * ptep->pte_high = 0;
- *
- * We must ensure here that the load of pte_low sees 'l' IFF pte_high sees
'h'.
- * We load pte_high *after* loading pte_low, which ensures we don't see an
older
- * value of pte_high. *Then* we recheck pte_low, which ensures that we
haven't
- * picked up a changed pte high. We might have gotten rubbish values from
- * pte_low and pte_high, but we are guaranteed that pte_low will not have the
- * present bit set *unless* it is 'l'. Because get_user_pages_fast() only
- * operates on present ptes we're safe.
- */
-static inline pte_t gup_get_pte(pte_t *ptep)
--{
- if (flags & FOLL_PIN) {
- mod_node_page_state(page_pgdat(page), NR_FOLL_PIN_RELEASED,
- refs);
- pte_t pte;
--
- if (hpage_pincount_available(page))
- hpage_pincount_sub(page, refs);
- else
- refs *= GUP_PIN_COUNTING_BIAS;
- }
- do {
- pte.pte_low = ptep->pte_low;
- smp_rmb();
- pte.pte_high = ptep->pte_high;
- smp_rmb();
- } while (unlikely(pte.pte_low != ptep->pte_low));
--
- VM_BUG_ON_PAGE(page_ref_count(page) < refs, page);
- /*
-* Calling put_page() for each ref is unnecessarily slow. Only the last
-* ref needs a put_page().
-*/
- if (refs > 1)
- page_ref_sub(page, refs - 1);
- put_page(page);
- return pte;
-}
-#else /* CONFIG_GUP_GET_PTE_LOW_HIGH */
-/*
- * We require that the PTE can be read atomically.
- */
-static inline pte_t gup_get_pte(pte_t *ptep)
-{
- return ptep_get(ptep);
--}
-#endif /* CONFIG_GUP_GET_PTE_LOW_HIGH */
--
static void __maybe_unused undo_dev_pagemap(int *nr, int nr_start,
unsigned int flags,
struct page **pages)
pgpIyk7IqzE7w.pgp
Description: OpenPGP digital signature
Re: [PATCH v4 1/2] dt-bindings: hwlock: add sun8i_hwspinlock
Hi, On Fri, Dec 11, 2020 at 09:23:48AM +0100, Wilken Gottwalt wrote: > Adds documentation on how to use the sun8i_hwspinlock driver for sun8i > compatible SoCs. > > Signed-off-by: Wilken Gottwalt > --- > Changes in v4: > - changed binding to sun8i-a33-hwpinlock > - added changes suggested by Maxime Ripard > > Changes in v3: > - changed symbols from sunxi to sun8i > > Changes in v2: > - fixed memory ranges > --- > .../bindings/hwlock/sun8i-hwspinlock.yaml | 56 +++ > 1 file changed, 56 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml > > diff --git a/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml > b/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml > new file mode 100644 > index ..76963d8abd5f > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml We usually have the schemas with the same name than the compatible > @@ -0,0 +1,56 @@ > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/hwlock/sun8i-hwspinlock.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: SUN8I hardware spinlock driver for Allwinner sun8i compatible SoCs > + > +maintainers: > + - Wilken Gottwalt > + > +description: > + The hardware unit provides sempahores between the ARM cores and the > embedded ^ typo > + OpenRisc core on the SoC. It's not just OpenRisc: there's some SoC that will have an xtensa core. Maybe we can replace openrisc by secondary? > + > +properties: > + compatible: > +const: allwinner,sun8i-a33-hwspinlock > + > +reg: > + maxItems: 1 > + > +clocks: > + maxItems: 1 > + > +clock-names: > + items: > +- const: ahb clock-names is useless when you have a single clock > + > +resets: > + maxItems: 1 > + > +reset-names: > + items: > +- const: ahb and reset-names is useless as well when there's a single reset line Maxime signature.asc Description: PGP signature
[PATCH -next] gpu: drm: imx: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/gpu/drm/imx/parallel-display.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/imx/parallel-display.c b/drivers/gpu/drm/imx/parallel-display.c index 2eb8df4697df..c4dab79a9385 100644 --- a/drivers/gpu/drm/imx/parallel-display.c +++ b/drivers/gpu/drm/imx/parallel-display.c @@ -74,7 +74,7 @@ static int imx_pd_connector_get_modes(struct drm_connector *connector) return ret; drm_mode_copy(mode, &imxpd->mode); - mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED, + mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED; drm_mode_probed_add(connector, mode); num_modes++; } -- 2.22.0
[PATCH -next] gpu: drm: vmwgfx: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c index e67e2e8f6e6f..537c48eff197 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c @@ -2509,7 +2509,7 @@ static int vmw_cmd_dx_set_so_targets(struct vmw_private *dev_priv, binding.bi.ctx = ctx_node->ctx; binding.bi.res = res; - binding.bi.bt = vmw_ctx_binding_so_target, + binding.bi.bt = vmw_ctx_binding_so_target; binding.offset = cmd->targets[i].offset; binding.size = cmd->targets[i].sizeInBytes; binding.slot = i; -- 2.22.0
[PATCH] net: qlcnic: remove casting dma_alloc_coherent
Remove casting the values returned by dma_alloc_coherent.
Signed-off-by: Xu Wang
---
drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
index 87f76bac2e46..c263c7769444 100644
--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
@@ -569,7 +569,7 @@ int qlcnic_alloc_hw_resources(struct qlcnic_adapter
*adapter)
for (ring = 0; ring < adapter->drv_tx_rings; ring++) {
tx_ring = &adapter->tx_ring[ring];
- ptr = (__le32 *)dma_alloc_coherent(&pdev->dev, sizeof(u32),
+ ptr = dma_alloc_coherent(&pdev->dev, sizeof(u32),
&tx_ring->hw_cons_phys_addr,
GFP_KERNEL);
if (ptr == NULL) {
--
2.17.1
[PATCH -next] mtd: nand: raw: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/mtd/nand/raw/mxc_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/mxc_nand.c b/drivers/mtd/nand/raw/mxc_nand.c index 684c51e5e60d..aa61b64a8abd 100644 --- a/drivers/mtd/nand/raw/mxc_nand.c +++ b/drivers/mtd/nand/raw/mxc_nand.c @@ -1787,7 +1787,7 @@ static int mxcnd_probe(struct platform_device *pdev) this->legacy.chip_delay = 5; nand_set_controller_data(this, host); - nand_set_flash_node(this, pdev->dev.of_node), + nand_set_flash_node(this, pdev->dev.of_node); this->legacy.dev_ready = mxc_nand_dev_ready; this->legacy.cmdfunc = mxc_nand_command; this->legacy.read_byte = mxc_nand_read_byte; -- 2.22.0
[PATCH -next] gpu: drm: i915: convert comma to semicolon
Replace a comma between expression statements by a semicolon. Signed-off-by: Zheng Yongjun --- drivers/gpu/drm/i915/display/intel_hdmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c b/drivers/gpu/drm/i915/display/intel_hdmi.c index 3f2008d845c2..9737a8604fc7 100644 --- a/drivers/gpu/drm/i915/display/intel_hdmi.c +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c @@ -1323,8 +1323,8 @@ static int intel_hdmi_hdcp_write(struct intel_digital_port *dig_port, memcpy(&write_buf[1], buffer, size); msg.addr = DRM_HDCP_DDC_ADDR; - msg.flags = 0, - msg.len = size + 1, + msg.flags = 0; + msg.len = size + 1; msg.buf = write_buf; ret = i2c_transfer(adapter, &msg, 1); -- 2.22.0
Re: [PATCH 3/4] sched/fair: Do not replace recent_used_cpu with the new target
On Fri, Dec 11, 2020 at 02:25:42PM +0800, Hillf Danton wrote:
> On Tue, 8 Dec 2020 15:35:00 + Mel Gorman wrote:
> > @@ -6277,17 +6277,13 @@ static int select_idle_sibling(struct task_struct
> > *p, int prev, int target)
> >
> > /* Check a recently used CPU as a potential idle candidate: */
> > recent_used_cpu = p->recent_used_cpu;
> > + p->recent_used_cpu = prev;
> > if (recent_used_cpu != prev &&
> > recent_used_cpu != target &&
> > cpus_share_cache(recent_used_cpu, target) &&
> > (available_idle_cpu(recent_used_cpu) ||
> > sched_idle_cpu(recent_used_cpu)) &&
> > cpumask_test_cpu(p->recent_used_cpu, p->cpus_ptr) &&
>
> Typo? Fix it in spin if so.
>
What typo?
> > asym_fits_capacity(task_util, recent_used_cpu)) {
> > - /*
> > -* Replace recent_used_cpu with prev as it is a potential
> > -* candidate for the next wake:
> > -*/
> > - p->recent_used_cpu = prev;
> > return recent_used_cpu;
>
> I prefer to update the recent CPU after llc check.
>
That would prevent recent_used_cpu leaving the LLC the task first
started on.
--
Mel Gorman
SUSE Labs
Re: [PATCH 4.14 00/31] 4.14.212-rc1 review
On Thu, 10 Dec 2020 at 20:01, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.212 release. > There are 31 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat, 12 Dec 2020 14:25:47 +. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.212-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.14.y > and the diffstat can be found below. > > thanks, > > greg k-h Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386. Tested-by: Linux Kernel Functional Testing Summary kernel: 4.14.212-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: ad2d75a4fc6e81e11297320a54abb176b5de8dca git describe: v4.14.211-31-gad2d75a4fc6e Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.211-31-gad2d75a4fc6e No regressions (compared to build v4.14.211) No fixes (compared to build v4.14.211) Ran 36132 total tests in the following environments and test suites. Environments -- - arm - arm64 - dragonboard-410c - arm64 - hi6220-hikey - arm64 - i386 - juno-r2 - arm64 - mips - qemu-arm64-kasan - qemu-x86_64-kasan - qemu_arm - qemu_arm64 - qemu_arm64-compat - qemu_i386 - qemu_x86_64 - qemu_x86_64-compat - sparc - x15 - arm - x86_64 - x86-kasan Test Suites --- * build * linux-log-parser * install-android-platform-tools-r2600 * ltp-cap_bounds-tests * ltp-containers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-mm-tests * ltp-nptl-tests * ltp-pty-tests * ltp-securebits-tests * perf * ltp-commands-tests * ltp-controllers-tests * ltp-cve-tests * ltp-dio-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-sched-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * libhugetlbfs * ltp-fs-tests * ltp-open-posix-tests * v4l2-compliance * rcutorture * fwts * kvm-unit-tests -- Linaro LKFT https://lkft.linaro.org
Re: [PATCH v4 2/2] hwspinlock: add sun8i hardware spinlock support
Hi, On Fri, Dec 11, 2020 at 09:24:15AM +0100, Wilken Gottwalt wrote: > Adds the sun8i_hwspinlock driver for the hardware spinlock unit found in > most of the sun8i compatible SoCs. > > This unit provides at least 32 spinlocks in hardware. The implementation > supports 32, 64, 128 or 256 32bit registers. A lock can be taken by > reading a register and released by writing a 0 to it. This driver > supports all 4 spinlock setups, but for now only the first setup (32 > locks) seem to exist in available devices. This spinlock unit is shared > between all ARM cores and the embedded OpenRisc AR100 core. All of them > can take/release a lock with a single cycle operation. It can be used to > sync access to devices shared by the ARM cores and the OpenRisc core. > > There are two ways to check if a lock is taken. The first way is to read > a lock. If a 0 is returned, the lock was free and is taken now. If an 1 > is returned, the caller has to try again. Which means the lock is taken. > The second way is to read a 32bit wide status register where every bit > represents one of the 32 first locks. According to the datasheets this > status register supports only the 32 first locks. This is the reason the > first way (lock read/write) approach is used to be able to cover all 256 > locks in future devices. The driver also reports the amount of supported > locks via debugfs. > > Signed-off-by: Wilken Gottwalt > --- > Changes in v4: > - further simplified driver > - fixed an add_action_and_reset_ function issue > - changed bindings from sun8i-hwspinlock to sun8i-a33-hwspinlock > > Changes in v3: > - moved test description to cover letter > - changed name and symbols from sunxi to sun8i > - improved driver description > - further simplified driver > - fully switched to devm_* and devm_add_action_* functions > > Changes in v2: > - added suggestions from Bjorn Andersson and Maxime Ripard > - provided better driver and test description > --- > MAINTAINERS | 6 + > drivers/hwspinlock/Kconfig| 9 ++ > drivers/hwspinlock/Makefile | 1 + > drivers/hwspinlock/sun8i_hwspinlock.c | 197 ++ > 4 files changed, 213 insertions(+) > create mode 100644 drivers/hwspinlock/sun8i_hwspinlock.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index ebe4829cdd4d..46846113f1eb 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -722,6 +722,12 @@ L: linux-cry...@vger.kernel.org > S: Maintained > F: drivers/crypto/allwinner/ > > +ALLWINNER HARDWARE SPINLOCK SUPPORT > +M: Wilken Gottwalt > +S: Maintained > +F: Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml > +F: drivers/hwspinlock/sun8i_hwspinlock.c > + > ALLWINNER THERMAL DRIVER > M: Vasily Khoruzhick > M: Yangtao Li > diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig > index 32cd26352f38..b03fd99aab32 100644 > --- a/drivers/hwspinlock/Kconfig > +++ b/drivers/hwspinlock/Kconfig > @@ -55,6 +55,15 @@ config HWSPINLOCK_STM32 > > If unsure, say N. > > +config HWSPINLOCK_SUN8I > + tristate "SUN8I Hardware Spinlock device" > + depends on ARCH_SUNXI || COMPILE_TEST > + help > + Say y here to support the SUN8I Hardware Spinlock device which can be > + found in most of the sun8i compatible Allwinner SoCs. > + > + If unsure, say N. > + > config HSEM_U8500 > tristate "STE Hardware Semaphore functionality" > depends on ARCH_U8500 || COMPILE_TEST > diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile > index ed053e3f02be..3496648d9257 100644 > --- a/drivers/hwspinlock/Makefile > +++ b/drivers/hwspinlock/Makefile > @@ -9,4 +9,5 @@ obj-$(CONFIG_HWSPINLOCK_QCOM) += qcom_hwspinlock.o > obj-$(CONFIG_HWSPINLOCK_SIRF)+= sirf_hwspinlock.o > obj-$(CONFIG_HWSPINLOCK_SPRD)+= sprd_hwspinlock.o > obj-$(CONFIG_HWSPINLOCK_STM32) += stm32_hwspinlock.o > +obj-$(CONFIG_HWSPINLOCK_SUN8I) += sun8i_hwspinlock.o > obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o > diff --git a/drivers/hwspinlock/sun8i_hwspinlock.c > b/drivers/hwspinlock/sun8i_hwspinlock.c > new file mode 100644 > index ..878dae6f1763 > --- /dev/null > +++ b/drivers/hwspinlock/sun8i_hwspinlock.c > @@ -0,0 +1,197 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * sun8i_hwspinlock.c - hardware spinlock driver for sun8i compatible > Allwinner SoCs > + * Copyright (C) 2020 Wilken Gottwalt > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include "hwspinlock_internal.h" > + > +#define DRIVER_NAME "sun8i_hwspinlock" > + > +#define SPINLOCK_BASE_ID 0 /* there is only one hwspinlock device per > SoC */ > +#define SPINLOCK_SYSSTATUS_REG 0x > +#define SPINLOCK_LOCK_REGN 0x0100 > +#define SP
[PATCH v10 0/4] Adding the Sparx5 Serdes driver
Adding the Sparx5 Serdes driver This series of patches provides the serdes driver for the Microchip Sparx5 ethernet switch. The serdes driver supports the 10G and 25G serdes instances available in the Sparx5. The Sparx5 serdes support several interface modes with several speeds and also allows the client to change the mode and the speed according to changing in the environment such as changing cables from DAC to fiber. The serdes driver is to be used by the Sparx5 switchdev driver that will follow in subsequent series. Sparx5 Arhitecture: === Below is a diagram of the Ethernet transport part of the Sparx5 chip. The diagram shows the switch core that sends/receives traffic via the Frame Bus and passes to the Port Modules. The Port Modules are able to talk to a SerDes via a Port Muxing configuration. The SerDes instances (33 in all) then passes the traffic on its lanes to the attached cuPHY or SFP module. +-+ | | | Switch Core | | | +++ | ---+--+--+---+--+-+ Frame Bus | | | | +--+-+ +--+-+ +--+-+ +--+-+ |1G/2.G Port | |5G Port | |10G Port| |25GG Port | |Modules | |Modules | |Modules | |Modules | |MAC, PCS| |MAC, PCS| |MAC, PCS| |MAC, PCS| +--+-+ +--+-+ +--+-+ +--+-+ | | | | ---+-++---+--+--+---+-+ Port Muxing || | +-++ +-++ +--+---+ |SerDes 5G | |SerDes 10G| |SerDes 25G|SerDes Driver |Lane (13) | |Lane (12) | |Lane (8) |Controls these +-++ +-++ +-++ ||| to cuPHY to cuPHY to cuPHY or SFP or SFP or SFP The 33 SerDes instances are handled internally by 2 SerDes macros types: - A 10G SerDes macro that supports the following rates and modes: - 100 Mbps: - 100BASE-FX - 1.25 Gbps: - SGMII - 1000BASE-X - 1000BASE-KX - 3.125 Gbps: - 2.5GBASE-X - 2.5GBASE-KX - 5 Gbps: - QSGMII - USGMII - 5.15625 Gbps: - 5GBASE-KR - 5G-USXGMII - 10 Gbps: - 10G-USGMII - 10.3125 Gbps: - 10GBASE-R - 10GBASE-KR - USXGMII - A 25G SerDes macro that supports the following rates and modes: - 1.25 Gbps: - SGMII - 1000BASE-X - 1000BASE-KX - 3.125 Gbps: - 2.5GBASE-X - 2.5GBASE-KX - 5 Gbps: - QSGMII - USGMII - 5.15625 Gbps: - 5GBASE-KR - 5G-USXGMII - 10 Gbps: - 10G-USGMII - 10.3125 Gbps: - 10GBASE-R - 10GBASE-KR - USXGMII - 10.3125 Gbps: - 10GBASE-R - 10GBASE-KR - USXGMII - 25.78125 Gbps: - 25GBASE-KR - 25GBASE-CR - 25GBASE-SR - 25GBASE-LR - 25GBASE-ER The SerDes driver handles these SerDes instances and configures them based on the selected mode, speed and media type. In the current version of the SerDes driver only a subset of the above modes are supported: the modes that can be tested on our current evaluation boards (PCB134 and PCB35). The first 13 10G SerDes macros are limited to 6G, and this gives the SerDes instance architecture shown on the diagram above. The Port Muxing allows a Port Module to use a specific SerDes instance, but not all combinations are allowed. This is functionality as well as the configuration of the Port Modules is handled by the SwitchDev Driver. History: v9 -> v10: Only add the new folder to the phy Kconfig (no sort fix) Corrected the serdes mode conversion for 2.5G mode. Clarified the SGMII and 1000BASEX conversion. Improved some of the more cryptic error messages. Expanded the validate function a bit, and removed the link status from the return value. v8 -> v9: Replace pr_err with dev_err Expanded the description here in the cover letter (should probably og into the driver, at least part of it). v7 -> v8: Provide the IO targets as offsets from the start of the IO range Initialise resource index v6 -> v7: This series changes the way the IO targets are provided to the driver. Now only one IO range is available in the DT, and the driver has a table to map its targets (as their order is still not sequential), thus reducing the DT needed information and binding requirements.
[PATCH v10 1/4] dt-bindings: phy: Add sparx5-serdes bindings
Document the Sparx5 ethernet serdes phy driver bindings.
Signed-off-by: Lars Povlsen
Signed-off-by: Steen Hegelund
Reviewed-by: Rob Herring
---
.../bindings/phy/microchip,sparx5-serdes.yaml | 100 ++
1 file changed, 100 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
diff --git a/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
b/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
new file mode 100644
index ..bdbdb3bbddbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/microchip,sparx5-serdes.yaml
@@ -0,0 +1,100 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/microchip,sparx5-serdes.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip Sparx5 Serdes controller
+
+maintainers:
+ - Steen Hegelund
+
+description: |
+ The Sparx5 SERDES interfaces share the same basic functionality, but
+ support different operating modes and line rates.
+
+ The following list lists the SERDES features:
+
+ * RX Adaptive Decision Feedback Equalizer (DFE)
+ * Programmable continuous time linear equalizer (CTLE)
+ * Rx variable gain control
+ * Rx built-in fault detector (loss-of-lock/loss-of-signal)
+ * Adjustable tx de-emphasis (FFE)
+ * Tx output amplitude control
+ * Supports rx eye monitor
+ * Multiple loopback modes
+ * Prbs generator and checker
+ * Polarity inversion control
+
+ SERDES6G:
+
+ The SERDES6G is a high-speed SERDES interface, which can operate at
+ the following data rates:
+
+ * 100 Mbps (100BASE-FX)
+ * 1.25 Gbps (SGMII/1000BASE-X/1000BASE-KX)
+ * 3.125 Gbps (2.5GBASE-X/2.5GBASE-KX)
+ * 5.15625 Gbps (5GBASE-KR/5G-USXGMII)
+
+ SERDES10G
+
+ The SERDES10G is a high-speed SERDES interface, which can operate at
+ the following data rates:
+
+ * 100 Mbps (100BASE-FX)
+ * 1.25 Gbps (SGMII/1000BASE-X/1000BASE-KX)
+ * 3.125 Gbps (2.5GBASE-X/2.5GBASE-KX)
+ * 5 Gbps (QSGMII/USGMII)
+ * 5.15625 Gbps (5GBASE-KR/5G-USXGMII)
+ * 10 Gbps (10G-USGMII)
+ * 10.3125 Gbps (10GBASE-R/10GBASE-KR/USXGMII)
+
+ SERDES25G
+
+ The SERDES25G is a high-speed SERDES interface, which can operate at
+ the following data rates:
+
+ * 1.25 Gbps (SGMII/1000BASE-X/1000BASE-KX)
+ * 3.125 Gbps (2.5GBASE-X/2.5GBASE-KX)
+ * 5 Gbps (QSGMII/USGMII)
+ * 5.15625 Gbps (5GBASE-KR/5G-USXGMII)
+ * 10 Gbps (10G-USGMII)
+ * 10.3125 Gbps (10GBASE-R/10GBASE-KR/USXGMII)
+ * 25.78125 Gbps (25GBASE-KR/25GBASE-CR/25GBASE-SR/25GBASE-LR/25GBASE-ER)
+
+properties:
+ $nodename:
+pattern: "^serdes@[0-9a-f]+$"
+
+ compatible:
+const: microchip,sparx5-serdes
+
+ reg:
+minItems: 1
+
+ '#phy-cells':
+const: 1
+description: |
+ - The main serdes input port
+
+ clocks:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - '#phy-cells'
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+serdes: serdes@10808000 {
+ compatible = "microchip,sparx5-serdes";
+ #phy-cells = <1>;
+ clocks = <&sys_clk>;
+ reg = <0x10808000 0x5d>;
+};
+
+...
--
2.29.2
[PATCH v10 4/4] arm64: dts: sparx5: Add Sparx5 serdes driver node
Add Sparx5 serdes driver node, and enable it generally for all
reference boards.
Signed-off-by: Lars Povlsen
Signed-off-by: Steen Hegelund
---
arch/arm64/boot/dts/microchip/sparx5.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/microchip/sparx5.dtsi
b/arch/arm64/boot/dts/microchip/sparx5.dtsi
index 8e7724d413fb..797601a9d542 100644
--- a/arch/arm64/boot/dts/microchip/sparx5.dtsi
+++ b/arch/arm64/boot/dts/microchip/sparx5.dtsi
@@ -287,5 +287,13 @@ tmon0: tmon@610508110 {
#thermal-sensor-cells = <0>;
clocks = <&ahb_clk>;
};
+
+ serdes: serdes@10808000 {
+ compatible = "microchip,sparx5-serdes";
+ #phy-cells = <1>;
+ clocks = <&sys_clk>;
+ reg = <0x6 0x10808000 0x5d>;
+ };
+
};
};
--
2.29.2
Re: [PATCH -next] usb: typec: tcpm: convert comma to semicolon
On Fri, Dec 11, 2020 at 04:55:53PM +0800, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. > > Signed-off-by: Zheng Yongjun Reviewed-by: Heikki Krogerus > --- > drivers/usb/typec/tcpm/tcpm.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c > index a6fae1f86505..4451507d600c 100644 > --- a/drivers/usb/typec/tcpm/tcpm.c > +++ b/drivers/usb/typec/tcpm/tcpm.c > @@ -5024,14 +5024,14 @@ static int devm_tcpm_psy_register(struct tcpm_port > *port) > snprintf(psy_name, psy_name_len, "%s%s", tcpm_psy_name_prefix, >port_dev_name); > port->psy_desc.name = psy_name; > - port->psy_desc.type = POWER_SUPPLY_TYPE_USB, > + port->psy_desc.type = POWER_SUPPLY_TYPE_USB; > port->psy_desc.usb_types = tcpm_psy_usb_types; > port->psy_desc.num_usb_types = ARRAY_SIZE(tcpm_psy_usb_types); > - port->psy_desc.properties = tcpm_psy_props, > - port->psy_desc.num_properties = ARRAY_SIZE(tcpm_psy_props), > - port->psy_desc.get_property = tcpm_psy_get_prop, > - port->psy_desc.set_property = tcpm_psy_set_prop, > - port->psy_desc.property_is_writeable = tcpm_psy_prop_writeable, > + port->psy_desc.properties = tcpm_psy_props; > + port->psy_desc.num_properties = ARRAY_SIZE(tcpm_psy_props); > + port->psy_desc.get_property = tcpm_psy_get_prop; > + port->psy_desc.set_property = tcpm_psy_set_prop; > + port->psy_desc.property_is_writeable = tcpm_psy_prop_writeable; > > port->usb_type = POWER_SUPPLY_USB_TYPE_C; > > -- > 2.22.0 thanks, -- heikki
[PATCH v10 2/4] phy: Add ethernet serdes configuration option
Provide a new ethernet phy configuration structure, that
allow PHYs used for ethernet to be configured with
speed, media type and clock information.
Signed-off-by: Lars Povlsen
Signed-off-by: Steen Hegelund
---
include/linux/phy/phy-ethernet-serdes.h | 30 +
include/linux/phy/phy.h | 4
2 files changed, 34 insertions(+)
create mode 100644 include/linux/phy/phy-ethernet-serdes.h
diff --git a/include/linux/phy/phy-ethernet-serdes.h
b/include/linux/phy/phy-ethernet-serdes.h
new file mode 100644
index ..d2462fadf179
--- /dev/null
+++ b/include/linux/phy/phy-ethernet-serdes.h
@@ -0,0 +1,30 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
+/*
+ * Microchip Sparx5 Ethernet SerDes driver
+ *
+ * Copyright (c) 2020 Microschip Inc
+ */
+#ifndef __PHY_ETHERNET_SERDES_H_
+#define __PHY_ETHERNET_SERDES_H_
+
+#include
+
+enum ethernet_media_type {
+ ETH_MEDIA_DEFAULT,
+ ETH_MEDIA_SR,
+ ETH_MEDIA_DAC,
+};
+
+/**
+ * struct phy_configure_opts_eth_serdes - Ethernet SerDes This structure is
used
+ * to represent the configuration state of a Ethernet Serdes PHY.
+ * @speed: Speed of the serdes interface in Mbps
+ * @media_type: Specifies which media the serdes will be using
+ */
+struct phy_configure_opts_eth_serdes {
+ u32speed;
+ enum ethernet_media_type media_type;
+};
+
+#endif
+
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index e435bdb0bab3..78ecb375cede 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -18,6 +18,7 @@
#include
#include
+#include
struct phy;
@@ -49,11 +50,14 @@ enum phy_mode {
*
* @mipi_dphy: Configuration set applicable for phys supporting
* the MIPI_DPHY phy mode.
+ * @eth_serdes: Configuration set applicable for phys supporting
+ * the ethernet serdes.
* @dp:Configuration set applicable for phys supporting
* the DisplayPort protocol.
*/
union phy_configure_opts {
struct phy_configure_opts_mipi_dphy mipi_dphy;
+ struct phy_configure_opts_eth_serdeseth_serdes;
struct phy_configure_opts_dpdp;
};
--
2.29.2
Re: [PATCH -next] usb: ucsi: convert comma to semicolon
On Fri, Dec 11, 2020 at 04:55:10PM +0800, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. > > Signed-off-by: Zheng Yongjun Reviewed-by: Heikki Krogerus > --- > drivers/usb/typec/ucsi/psy.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/typec/ucsi/psy.c b/drivers/usb/typec/ucsi/psy.c > index 571a51e16234..56bf56517f75 100644 > --- a/drivers/usb/typec/ucsi/psy.c > +++ b/drivers/usb/typec/ucsi/psy.c > @@ -220,11 +220,11 @@ int ucsi_register_port_psy(struct ucsi_connector *con) > return -ENOMEM; > > con->psy_desc.name = psy_name; > - con->psy_desc.type = POWER_SUPPLY_TYPE_USB, > + con->psy_desc.type = POWER_SUPPLY_TYPE_USB; > con->psy_desc.usb_types = ucsi_psy_usb_types; > con->psy_desc.num_usb_types = ARRAY_SIZE(ucsi_psy_usb_types); > - con->psy_desc.properties = ucsi_psy_props, > - con->psy_desc.num_properties = ARRAY_SIZE(ucsi_psy_props), > + con->psy_desc.properties = ucsi_psy_props; > + con->psy_desc.num_properties = ARRAY_SIZE(ucsi_psy_props); > con->psy_desc.get_property = ucsi_psy_get_prop; > > con->psy = power_supply_register(dev, &con->psy_desc, &psy_cfg); > -- > 2.22.0 thanks, -- heikki
Re: [PATCH -next] fs/afs: convert comma to semicolon
On Fri, 2020-12-11 at 16:38 +0800, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. If you are using a tool to find and fix these, you should mention the tool. btw: using Julia Lawall's cocci script to update these is probably best. https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/
Re: [PATCH v4 1/2] dt-bindings: hwlock: add sun8i_hwspinlock
On Fri, 11 Dec 2020 09:57:57 +0100 Maxime Ripard wrote: > Hi, > > On Fri, Dec 11, 2020 at 09:23:48AM +0100, Wilken Gottwalt wrote: > > Adds documentation on how to use the sun8i_hwspinlock driver for sun8i > > compatible SoCs. > > > > Signed-off-by: Wilken Gottwalt > > --- > > Changes in v4: > > - changed binding to sun8i-a33-hwpinlock > > - added changes suggested by Maxime Ripard > > > > Changes in v3: > > - changed symbols from sunxi to sun8i > > > > Changes in v2: > > - fixed memory ranges > > --- > > .../bindings/hwlock/sun8i-hwspinlock.yaml | 56 +++ > > 1 file changed, 56 insertions(+) > > create mode 100644 > > Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml > > > > diff --git a/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml > > b/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml new file > > mode 100644 > > index ..76963d8abd5f > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/hwlock/sun8i-hwspinlock.yaml > > We usually have the schemas with the same name than the compatible > > > @@ -0,0 +1,56 @@ > > +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) > > +%YAML 1.2 > > +--- > > +$id: http://devicetree.org/schemas/hwlock/sun8i-hwspinlock.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: SUN8I hardware spinlock driver for Allwinner sun8i compatible SoCs > > + > > +maintainers: > > + - Wilken Gottwalt > > + > > +description: > > + The hardware unit provides sempahores between the ARM cores and the > > embedded > > ^ typo Hmm, you are right. This is odd, the patch checking script didn't catch that one. > > + OpenRisc core on the SoC. > > It's not just OpenRisc: there's some SoC that will have an xtensa core. Maybe > we can replace > openrisc by secondary? So there are actually different embedded cores? What about embedded companion core? > > + > > +properties: > > + compatible: > > +const: allwinner,sun8i-a33-hwspinlock > > + > > +reg: > > + maxItems: 1 > > + > > +clocks: > > + maxItems: 1 > > + > > +clock-names: > > + items: > > +- const: ahb > > clock-names is useless when you have a single clock > > > + > > +resets: > > + maxItems: 1 > > + > > +reset-names: > > + items: > > +- const: ahb > > and reset-names is useless as well when there's a single reset line So just drop the reset-names lines? I'm still a bit unsure about this dt yaml documentation format. I try to learn from the existing bindings, but the quality seems a bit mixed. So thank you for your patience. greetings, Wilken > Maxime
Re: [PATCH v2] Serial: silabs si4455 serial driver
On Fri, Dec 11, 2020 at 09:43:31AM +0100, 'Greg Kroah-Hartman' wrote:
> On Fri, Dec 11, 2020 at 08:16:34AM +, József Horváth wrote:
> > On Fri, Dec 11, 2020 at 08:33:17AM +0100, 'Greg Kroah-Hartman' wrote:
> > > On Fri, Dec 11, 2020 at 06:37:52AM +, József Horváth wrote:
> > > > On Fri, Dec 11, 2020 at 07:20:41AM +0100, 'Greg Kroah-Hartman' wrote:
> > > > > On Fri, Dec 11, 2020 at 06:09:43AM +, József Horváth wrote:
> > > > > > On Fri, Dec 11, 2020 at 06:50:58AM +0100, 'Greg Kroah-Hartman'
> > > > > > wrote:
> > > > > > > On Thu, Dec 10, 2020 at 07:46:25PM +, József Horváth wrote:
> > > > > > > > On Thu, Dec 10, 2020 at 08:03:22PM +0100, 'Greg Kroah-Hartman'
> > > > > > > > wrote:
> > > > > > > > > On Thu, Dec 10, 2020 at 05:04:46PM +, József Horváth
> > > > > > > > > wrote:
> > > > > > > > > > This is a serial port driver for
> > > > > > > > > > Silicon Labs Si4455 Sub-GHz transciver.
> > > > > > > > > > +
> > > > > > > > > > +#define BASE_TTYIOC_PRIVATE0xA0
> > > > > > > > > > +/* Set EZConfig.
> > > > > > > > > > + * After this ioctl call, the driver restarts the si4455,
> > > > > > > > > > + * then apply the new configuration and patch.
> > > > > > > > > > + */
> > > > > > > > > > +#define SI4455_IOC_SEZC_IOW('T', \
> > > > > > > > > > +BASE_TTYIOC_PRIVATE +
> > > > > > > > > > 0x01, \
> > > > > > > > > > +struct si4455_iocbuff)
> > > > > > > > >
> > > > > > > > > Why does a serial driver have private ioctls? Please no,
> > > > > > > > > don't do that.
> > > > > > > >
> > > > > > > > I checked the ioctl.h and serial_core.h, but I not found any
> > > > > > > > similar definition, like BASE_VIDIOC_PRIVATE in videodev2.h.
> > > > > > > > In this case the name of macro BASE_TTYIOC_PRIVATE means the
> > > > > > > > base value of special ioctl commands owned by this driver.
> > > > > > >
> > > > > > > My point is, a serial driver should NOT have any custom ioctls.
> > > > > > >
> > > > > > > > I can change it to BASE_TTYIOC or SI4455_IOC_BASE
> > > > > > > >
> > > > > > > > > Implement the basic serial driver first, and then we can talk
> > > > > > > > > about
> > > > > > > > > "custom" configurations and the like, using the correct apis.
> > > > > > > >
> > > > > > > > Without the SI4455_IOC_SEZC call, the driver can't configure
> > > > > > > > the Si4455 and not working at all.
> > > > > > > > The cofiguration for interface is provided by user for
> > > > > > > > application.
> > > > > > >
> > > > > > > That is what a device tree is for, to configure the device to
> > > > > > > have the
> > > > > > > correct system configuration, why can't that be the same here?
> > > > > > >
> > > > > > > > It contains the base frequency, channel spacing, modulation,
> > > > > > > > and a lot
> > > > > > > > of more stuff, and generated by Silicon Labs Wireless
> > > > > > > > Development
> > > > > > > > Suite.
> > > > > > > > The generated configuration is in a non public(compressed,
> > > > > > > > encrypted...who knows) format, so without this the driver can't
> > > > > > > > provide configuration parameters to Si4455.
> > > > > > >
> > > > > > > So we have to take a "custom" userspace blob and send it to the
> > > > > > > device
> > > > > > > to configure it properly? Like Jiri said, sounds like firmware,
> > > > > > > so just
> > > > > > > use that interface instead.
> > > > > >
> > > > > > I checked Jiri's suggestion, and it is a good solution to replace
> > > > > > SI4455_IOC_SEZC(configuration) and SI4455_IOC_SEZP(firmware patch).
> > > > > > I can move SI4455_IOC_SSIZ(package size) to device tree property.
> > > > > >
> > > > > > Maybe you have good suggestion for the following:
> > > > > > SI4455_IOC_STXC -> Radio transmit channel index. It is a real use
> > > > > > case to control this parameter by user at runtime.
> > > > > > SI4455_IOC_SRXC -> Radio receive channel index. It is a real use
> > > > > > case to control this parameter by user at runtime.
> > > > >
> > > > > These are not serial port things, why would a serial port care about
> > > > > these?
> > > >
> > > > You are right, these are not regular serial port things, but this
> > > > device is not a regular uart, it is a sub-GHz transciever, digital
> > > > radio.
> > > > This driver tries to represent it as a serial port to user.
> > >
> > > Is that the correct representation to be using here? Why not act like a
> > > proper radio device instead? That way you get to use the normal kernel
> > > apis for radio devices.
> >
> > In my mind it is absolute a serial device by the application.
>
> What is the application? Traditionally serial ports don't need radio signals
> :)
The application is connecting newly developed sensors(with only rf interface)
and legacy sensors(with regular serial communication over rs-485 with modbus)
keeping the legacy user software.
User sw [Java]
<-> /dev/ttyXXX
