[PATCH v2] f2fs: fix to keep isolation of atomic write

2020-12-29 Thread Chao Yu
ThreadA ThreadB
- f2fs_ioc_start_atomic_write
- write
- f2fs_ioc_commit_atomic_write
 - f2fs_commit_inmem_pages
 - f2fs_drop_inmem_pages
 - f2fs_drop_inmem_pages
  - __revoke_inmem_pages
- f2fs_vm_page_mkwrite
 - set_page_dirty
  - tag ATOMIC_WRITTEN_PAGE and add page
to inmem_pages list
  - clear_inode_flag(FI_ATOMIC_FILE)
- f2fs_vm_page_mkwrite
  - set_page_dirty
   - f2fs_update_dirty_page
- f2fs_trace_pid
 - tag inmem page private to pid
- truncate
 - f2fs_invalidate_page
 - set page->mapping to NULL
  then it will cause panic once we
  access page->mapping

The root cause is we missed to keep isolation of atomic write in the case
of commit_atomic_write vs mkwrite, let commit_atomic_write helds i_mmap_sem
lock to avoid this issue.

Signed-off-by: Chao Yu 
---
v2:
- use i_mmap_sem to avoid mkwrite racing with below flows:
 * f2fs_ioc_start_atomic_write
 * f2fs_drop_inmem_pages
 * f2fs_commit_inmem_pages

 fs/f2fs/file.c| 3 +++
 fs/f2fs/segment.c | 7 +++
 2 files changed, 10 insertions(+)

diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 4e6d4b9120a8..a48ec650d691 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -2050,6 +2050,7 @@ static int f2fs_ioc_start_atomic_write(struct file *filp)
goto out;
 
down_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
+   down_write(&F2FS_I(inode)->i_mmap_sem);
 
/*
 * Should wait end_io to count F2FS_WB_CP_DATA correctly by
@@ -2060,6 +2061,7 @@ static int f2fs_ioc_start_atomic_write(struct file *filp)
  inode->i_ino, get_dirty_pages(inode));
ret = filemap_write_and_wait_range(inode->i_mapping, 0, LLONG_MAX);
if (ret) {
+   up_write(&F2FS_I(inode)->i_mmap_sem);
up_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
goto out;
}
@@ -2073,6 +2075,7 @@ static int f2fs_ioc_start_atomic_write(struct file *filp)
/* add inode in inmem_list first and set atomic_file */
set_inode_flag(inode, FI_ATOMIC_FILE);
clear_inode_flag(inode, FI_ATOMIC_REVOKE_REQUEST);
+   up_write(&F2FS_I(inode)->i_mmap_sem);
up_write(&F2FS_I(inode)->i_gc_rwsem[WRITE]);
 
f2fs_update_time(F2FS_I_SB(inode), REQ_TIME);
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index d8570b0359f5..dab870d9faf6 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -327,6 +327,8 @@ void f2fs_drop_inmem_pages(struct inode *inode)
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
struct f2fs_inode_info *fi = F2FS_I(inode);
 
+   down_write(&F2FS_I(inode)->i_mmap_sem);
+
while (!list_empty(&fi->inmem_pages)) {
mutex_lock(&fi->inmem_lock);
__revoke_inmem_pages(inode, &fi->inmem_pages,
@@ -344,6 +346,8 @@ void f2fs_drop_inmem_pages(struct inode *inode)
sbi->atomic_files--;
}
spin_unlock(&sbi->inode_lock[ATOMIC_FILE]);
+
+   up_write(&F2FS_I(inode)->i_mmap_sem);
 }
 
 void f2fs_drop_inmem_page(struct inode *inode, struct page *page)
@@ -467,6 +471,7 @@ int f2fs_commit_inmem_pages(struct inode *inode)
f2fs_balance_fs(sbi, true);
 
down_write(&fi->i_gc_rwsem[WRITE]);
+   down_write(&F2FS_I(inode)->i_mmap_sem);
 
f2fs_lock_op(sbi);
set_inode_flag(inode, FI_ATOMIC_COMMIT);
@@ -478,6 +483,8 @@ int f2fs_commit_inmem_pages(struct inode *inode)
clear_inode_flag(inode, FI_ATOMIC_COMMIT);
 
f2fs_unlock_op(sbi);
+
+   up_write(&F2FS_I(inode)->i_mmap_sem);
up_write(&fi->i_gc_rwsem[WRITE]);
 
return err;
-- 
2.29.2



Re: [PATCH] scsi: ufs: Correct the lun used in eh_device_reset_handler() callback

2020-12-29 Thread Can Guo

On 2020-12-30 15:20, Avri Altman wrote:

Users can initiate resets to specific SCSI device/target/host through
IOCTL. When this happens, the SCSI cmd passed to eh_device/target/host
_reset_handler() callbacks is initialized with a request whose tag is 
-1.
So, in this case, it is not right for eh_device_reset_handler() 
callback
to count on the lun get from hba->lrb[-1]. Fix it by getting lun from 
the

SCSI device associated with the SCSI cmd.

Signed-off-by: Can Guo 

Reviewed-by: Avri Altman 

Btw, am surprised to see that you guys are still using sg_reset
instead of ufs-utils?


Hi Avri,

We are not using any user layer tools at all. But I am confronted
with many customers and tons of test teams inside and outside.
I see all kinds of corner cases everyday, so not surprised at all.

Thanks,
Can Guo



Thanks,
Avri


Re: Registering IRQ for MT7530 internal PHYs

2020-12-29 Thread Heiner Kallweit
On 30.12.2020 05:22, DENG Qingfang wrote:
> Hi,
> 
> I added MT7530 IRQ support and registered its internal PHYs to IRQ.
> It works but my patch used two hacks.
> 
> 1. Removed phy_drv_supports_irq check, because config_intr and
> handle_interrupt are not set for Generic PHY.
> 
I don't think that's the best option. First, did you check which
consequences this has? The check is there for a reason.
You may want to add a PHY driver for your chip. Supposedly it
supports at least PHY suspend/resume. You can use the RTL8366RB
PHY driver as template.

> 2. Allocated ds->slave_mii_bus before calling ds->ops->setup, because
> we cannot call dsa_slave_mii_bus_init which is private.
> 
> Any better ideas?
> 
> Regards,
> Qingfang
> 
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index a67cac15a724..d59a8c50ede3 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1639,6 +1640,125 @@ mtk_get_tag_protocol(struct dsa_switch *ds, int port,
>   }
>  }
>  
> +static irqreturn_t
> +mt7530_irq(int irq, void *data)
> +{
> + struct mt7530_priv *priv = data;
> + bool handled = false;
> + int phy;
> + u32 val;
> +
> + val = mt7530_read(priv, MT7530_SYS_INT_STS);
> + mt7530_write(priv, MT7530_SYS_INT_STS, val);
> +
> + dev_info_ratelimited(priv->dev, "interrupt status: 0x%08x\n", val);
> + dev_info_ratelimited(priv->dev, "interrupt enable: 0x%08x\n", 
> mt7530_read(priv, MT7530_SYS_INT_EN));
> +
This is debug code to be removed in the final version?

> + for (phy = 0; phy < MT7530_NUM_PHYS; phy++) {
> + if (val & BIT(phy)) {
> + unsigned int child_irq;
> +
> + child_irq = irq_find_mapping(priv->irq_domain, phy);
> + handle_nested_irq(child_irq);
> + handled = true;
> + }
> + }
> +
> + return handled ? IRQ_HANDLED : IRQ_NONE;

IRQ_RETVAL() could be used here.

> +}
> +
> +static void mt7530_irq_mask(struct irq_data *d)
> +{
> + struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
> +
> + priv->irq_enable &= ~BIT(d->hwirq);

Here you don't actually do something. HW doesn't support masking
interrupt generation for a port?

> +}
> +
> +static void mt7530_irq_unmask(struct irq_data *d)
> +{
> + struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
> +
> + priv->irq_enable |= BIT(d->hwirq);
> +}
> +
> +static void mt7530_irq_bus_lock(struct irq_data *d)
> +{
> + struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
> +
> + mutex_lock(&priv->reg_mutex);
> +}
> +
> +static void mt7530_irq_bus_sync_unlock(struct irq_data *d)
> +{
> + struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
> +
> + mt7530_write(priv, MT7530_SYS_INT_EN, priv->irq_enable);
> + mutex_unlock(&priv->reg_mutex);
> +}
> +
> +static struct irq_chip mt7530_irq_chip = {
> + .name = MT7530_NAME,
> + .irq_mask = mt7530_irq_mask,
> + .irq_unmask = mt7530_irq_unmask,
> + .irq_bus_lock = mt7530_irq_bus_lock,
> + .irq_bus_sync_unlock = mt7530_irq_bus_sync_unlock,
> +};
> +
> +static int
> +mt7530_irq_map(struct irq_domain *domain, unsigned int irq,
> +irq_hw_number_t hwirq)
> +{
> + irq_set_chip_data(irq, domain->host_data);
> + irq_set_chip_and_handler(irq, &mt7530_irq_chip, handle_simple_irq);
> + irq_set_noprobe(irq);
> +
> + return 0;
> +}
> +
> +static const struct irq_domain_ops mt7530_irq_domain_ops = {
> + .map = mt7530_irq_map,
> + .xlate = irq_domain_xlate_onecell,
> +};
> +
> +static void
> +mt7530_irq_init(struct mt7530_priv *priv)
> +{
> + struct mii_bus *bus = priv->ds->slave_mii_bus;
> + struct device *dev = priv->dev;
> + struct device_node *np = dev->of_node;
> + int parent_irq;
> + int phy, ret;
> +
> + parent_irq = of_irq_get(np, 0);
> + if (parent_irq <= 0) {
> + dev_err(dev, "failed to get parent IRQ: %d\n", parent_irq);
> + return;
> + }
> +
> + mt7530_set(priv, MT7530_TOP_SIG_CTRL, TOP_SIG_CTRL_NORMAL);
> + ret = devm_request_threaded_irq(dev, parent_irq, NULL, mt7530_irq,
> + IRQF_ONESHOT, MT7530_NAME, priv);
> + if (ret) {
> + dev_err(dev, "failed to request IRQ: %d\n", ret);
> + return;
> + }
> +
> + priv->irq_domain = irq_domain_add_linear(np, MT7530_NUM_PHYS,
> + &mt7530_irq_domain_ops, priv);
> + if (!priv->irq_domain) {
> + dev_err(dev, "failed to create IRQ domain\n");
> + return;
> + }
> +
> + /* IRQ for internal PHYs */
> + for (phy = 0; phy < MT7530_NUM_PHYS; phy++) {
> + unsigned int irq = irq_create_mapping(priv->irq_domain, phy);
> +
> + irq_set_parent(irq, parent_irq);
> + 

[PATCH] ibmvnic: fix: NULL pointer dereference.

2020-12-29 Thread YANG LI
The error is due to dereference a null pointer in function
reset_one_sub_crq_queue():

if (!scrq) {
netdev_dbg(adapter->netdev,
   "Invalid scrq reset. irq (%d) or msgs(%p).\n",
scrq->irq, scrq->msgs);
return -EINVAL;
}

If the expression is true, scrq must be a null pointer and cannot
dereference.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 drivers/net/ethernet/ibm/ibmvnic.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/ibm/ibmvnic.c 
b/drivers/net/ethernet/ibm/ibmvnic.c
index f302504..d7472be 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -2981,9 +2981,7 @@ static int reset_one_sub_crq_queue(struct ibmvnic_adapter 
*adapter,
int rc;
 
if (!scrq) {
-   netdev_dbg(adapter->netdev,
-  "Invalid scrq reset. irq (%d) or msgs (%p).\n",
-  scrq->irq, scrq->msgs);
+   netdev_dbg(adapter->netdev, "Invalid scrq reset.\n");
return -EINVAL;
}
 
-- 
1.8.3.1



RE: [PATCH] scsi: ufs: Correct the lun used in eh_device_reset_handler() callback

2020-12-29 Thread Avri Altman
 
> Users can initiate resets to specific SCSI device/target/host through
> IOCTL. When this happens, the SCSI cmd passed to eh_device/target/host
> _reset_handler() callbacks is initialized with a request whose tag is -1.
> So, in this case, it is not right for eh_device_reset_handler() callback
> to count on the lun get from hba->lrb[-1]. Fix it by getting lun from the
> SCSI device associated with the SCSI cmd.
> 
> Signed-off-by: Can Guo 
Reviewed-by: Avri Altman 

Btw, am surprised to see that you guys are still using sg_reset instead of 
ufs-utils?

Thanks,
Avri


Re: [PATCH] 9p: fix: Uninitialized variable p.

2020-12-29 Thread Dominique Martinet
YANG LI wrote on Wed, Dec 30, 2020:
> The pointer p is being used but it isn't being initialized,
> need to assign a NULL to it.

My understanding is p has to be initialized: the only way out of the
while(1) loop below sets it.


I don't mind fixing false positive warnings as it makes maintenance
easier for everyone, but:

 1/ the commit message needs to reflect that and at least name which
tool had a problem with it. I'm tempted to think this case is common
enough that the tool ought to be fixed instead...

 2/ the code needs to work in the p=NULL case if you set it that way
(right now, it doesn't, so in the event the code changes in the future
and there really comes a way to skip initialization this change would
actually hinder bug detection -- it'd need to add a p == NULL check
below, which is going to be useless code, but hopefully compilers will
optimize it away)


Thanks,
-- 
Dominique


Re: [PATCH v2 1/2] x86/cpufeatures: Add the Virtual SPEC_CTRL feature

2020-12-29 Thread Borislav Petkov
On Tue, Dec 22, 2020 at 04:31:32PM -0600, Babu Moger wrote:
> Newer AMD processors have a feature to virtualize the use of the
> SPEC_CTRL MSR. Presence of this feature is indicated via CPUID
> function 0x800A_EDX[20]: GuestSpecCtrl. When preset, the SPEC_CTRL
> MSR is automatically virtualized.
> 
> Signed-off-by: Babu Moger 
> ---
>  arch/x86/include/asm/cpufeatures.h |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/x86/include/asm/cpufeatures.h 
> b/arch/x86/include/asm/cpufeatures.h
> index dad350d42ecf..aee4a924ecd7 100644
> --- a/arch/x86/include/asm/cpufeatures.h
> +++ b/arch/x86/include/asm/cpufeatures.h
> @@ -335,6 +335,7 @@
>  #define X86_FEATURE_AVIC (15*32+13) /* Virtual Interrupt 
> Controller */
>  #define X86_FEATURE_V_VMSAVE_VMLOAD  (15*32+15) /* Virtual VMSAVE VMLOAD */
>  #define X86_FEATURE_VGIF (15*32+16) /* Virtual GIF */
> +#define X86_FEATURE_V_SPEC_CTRL  (15*32+20) /* Virtual SPEC_CTRL */
>  
>  /* Intel-defined CPU features, CPUID level 0x0007:0 (ECX), word 16 */
>  #define X86_FEATURE_AVX512VBMI   (16*32+ 1) /* AVX512 Vector Bit 
> Manipulation instructions*/


I'm guessing this will go through the kvm tree so:

Acked-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


Re: [PATCH v2 2/2] KVM: SVM: Add support for Virtual SPEC_CTRL

2020-12-29 Thread Borislav Petkov
On Tue, Dec 22, 2020 at 04:31:55PM -0600, Babu Moger wrote:
> @@ -2549,7 +2559,10 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct 
> msr_data *msr_info)
>   !guest_cpuid_has(vcpu, X86_FEATURE_AMD_SSBD))
>   return 1;
>  
> - msr_info->data = svm->spec_ctrl;
> + if (static_cpu_has(X86_FEATURE_V_SPEC_CTRL))
> + msr_info->data = svm->vmcb->save.spec_ctrl;
> + else
> + msr_info->data = svm->spec_ctrl;
>   break;
>   case MSR_AMD64_VIRT_SPEC_CTRL:
>   if (!msr_info->host_initiated &&
> @@ -2640,6 +2653,8 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct 
> msr_data *msr)
>   return 1;
>  
>   svm->spec_ctrl = data;
> + if (static_cpu_has(X86_FEATURE_V_SPEC_CTRL))
> + svm->vmcb->save.spec_ctrl = data;
>   if (!data)
>   break;
>  

Are the get/set_msr() accessors such a fast path that they need
static_cpu_has() ?

svm_get_msr() already uses boot_cpu_has() for MSR_TSC_AUX...

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


[PATCH v2] checkpatch: ignore warning designated initializers using NR_CPUS

2020-12-29 Thread Peng Wang
Some max_length wants to hold as large room as possible to
ensure enough size to tackle with the biggest NR_CPUS.
An example below:

kernel/cgroup/cpuset.c:
static struct cftype legacy_files[] = {
{
.name = "cpus",
.seq_show = cpuset_common_seq_show,
.write = cpuset_write_resmask,
.max_write_len = (100U + 6 * NR_CPUS),
.private = FILE_CPULIST,
},
...
}

Signed-off-by: Peng Wang 
---
 scripts/checkpatch.pl | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0008530..fdbbab3 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7022,12 +7022,15 @@ sub process {
 
 # use of NR_CPUS is usually wrong
 # ignore definitions of NR_CPUS and usage to define arrays as likely right
+# ignore designated initializers using NR_CPUS
+
if ($line =~ /\bNR_CPUS\b/ &&
$line !~ /^.\s*\s*#\s*if\b.*\bNR_CPUS\b/ &&
$line !~ /^.\s*\s*#\s*define\b.*\bNR_CPUS\b/ &&
$line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/ &&
$line !~ /\[[^\]]*\.\.\.[^\]]*NR_CPUS[^\]]*\]/ &&
-   $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/)
+   $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/ &&
+   $line !~ /^.\s*\.\w+\s*=\s*.*\bNR_CPUS\b/)
{
WARN("NR_CPUS",
 "usage of NR_CPUS is often wrong - consider using 
cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . 
$herecurr);
-- 
2.9.5



Re: [PATCH] checkpatch: ignore warning designated initializers using NR_CPUS

2020-12-29 Thread Peng Wang

Hi, Joe

On 12/30/20 1:35 PM, , Joe Perches wrote:

On Wed, 2020-12-30 at 12:13 +0800, Peng Wang wrote:

Some max_length wants to hold as large room as possible to
ensure enough size to tackle with the biggest NR_CPUS. As
an example below:

kernel/cgroup/cpuset.c:
static struct cftype legacy_files[] = {
 {
 .name = "cpus",
 .seq_show = cpuset_common_seq_show,
 .write = cpuset_write_resmask,
 .max_write_len = (100U + 6 * NR_CPUS),
 .private = FILE_CPULIST,
 },
...
}

[]

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl

[]

@@ -7022,12 +7022,15 @@ sub process {
  


  # use of NR_CPUS is usually wrong
  # ignore definitions of NR_CPUS and usage to define arrays as likely right
+# ignore designated initializers using NR_CPUS
+
    if ($line =~ /\bNR_CPUS\b/ &&
    $line !~ /^.\s*\s*#\s*if\b.*\bNR_CPUS\b/ &&
    $line !~ /^.\s*\s*#\s*define\b.*\bNR_CPUS\b/ &&
    $line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/ &&
    $line !~ /\[[^\]]*\.\.\.[^\]]*NR_CPUS[^\]]*\]/ &&
-   $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/)
+   $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/ &&
+   $line !~ /\s*\..*=.*\bNR_CPUS\b.*,$/)
    {
    WARN("NR_CPUS",
     "usage of NR_CPUS is often wrong - consider using 
cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . $herecurr);


I wonder if it's worth it as there just aren't many of these: (6 total)


It does not look that much, but checkpatch.pl makes warning on this 
especially when "0 errors, 0 warnings" is needed.




$ git grep -P '\..*=.*\bNR_CPUS\b.*,\s*$'
drivers/firmware/efi/efi.c: .cpu_bitmap = { 
[BITS_TO_LONGS(NR__CPUS)] = 0},
drivers/infiniband/hw/hfi1/sdma.c:  .max_size = NR_CPUS,
init/init_task.c:   .nr_cpus_allowed= NR_CPUS,
kernel/cgroup/cpuset.c: .max_write_len = (100U + 6 * NR_CPUS),
kernel/cgroup/cpuset.c: .max_write_len = (100U + 6 * NR_CPUS),
kernel/sysctl.c:.maxlen = NR_CPUS,

It also seems it might be more sensible as:

$line !~ /^.\s*\.\w+\s*=\s*.*\bNR_CPUS\b/


Aha, this is better!
Will send a v2 patch including this if you don't mind, Thanks.



Which finds a couple more:

$ git grep -P '^\s*\.\w+\s*=\s*.*\bNR_CPUS\b'
arch/arm64/include/asm/processor.h: .fpsimd_cpu = NR_CPUS,  
\
arch/powerpc/kernel/prom_init.c:.max_cpus = 
cpu_to_be32(NR_CPUS),   /* number of cores supported */
drivers/firmware/efi/efi.c: .cpu_bitmap = { 
[BITS_TO_LONGS(NR_CPUS)] = 0},
drivers/infiniband/hw/hfi1/sdma.c:  .max_size = NR_CPUS,
init/init_task.c:   .nr_cpus_allowed= NR_CPUS,
kernel/cgroup/cpuset.c: .max_write_len = (100U + 6 * NR_CPUS),
kernel/cgroup/cpuset.c: .max_write_len = (100U + 6 * NR_CPUS),
kernel/sysctl.c:.maxlen = NR_CPUS,



Re: [PATCH] mm: fix: Uninitialized variable ret.

2020-12-29 Thread Muchun Song
YANG LI  于2020年12月30日周三 下午3:02写道:
>
> The ret is being used but it isn't being initialized,
> need to assign a value to it, like 0.

Hi Yang,

I didn't see where it was used without initialized.
Can you point that out to me?

Thanks.


>
> Signed-off-by: YANG LI 
> Reported-by: Abaci 
> ---
>  mm/memcontrol.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 605f671..15ba17d 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3366,7 +3366,7 @@ static int mem_cgroup_resize_max(struct mem_cgroup 
> *memcg,
>  {
> bool enlarge = false;
> bool drained = false;
> -   int ret;
> +   int ret = 0;
> bool limits_invariant;
> struct page_counter *counter = memsw ? &memcg->memsw : &memcg->memory;
>
> --
> 1.8.3.1
>


[PATCH] isci: style: remove the unneeded variable: "status".

2020-12-29 Thread YANG LI
The variable 'status' is being initialized with SCI_SUCCESS and never 
update later with a new value. The initialization is redundant and can 
be removed.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 drivers/scsi/isci/request.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/scsi/isci/request.c b/drivers/scsi/isci/request.c
index 6e08179..bee1685 100644
--- a/drivers/scsi/isci/request.c
+++ b/drivers/scsi/isci/request.c
@@ -2103,8 +2103,6 @@ enum sci_status
 static enum sci_status stp_request_udma_await_tc_event(struct isci_request 
*ireq,
   u32 completion_code)
 {
-   enum sci_status status = SCI_SUCCESS;
-
switch (SCU_GET_COMPLETION_TL_STATUS(completion_code)) {
case SCU_MAKE_COMPLETION_STATUS(SCU_TASK_DONE_GOOD):
ireq->scu_status = SCU_TASK_DONE_GOOD;
@@ -2148,7 +2146,7 @@ static enum sci_status 
stp_request_udma_await_tc_event(struct isci_request *ireq
break;
}
 
-   return status;
+   return SCI_SUCCESS;
 }
 
 static enum sci_status atapi_raw_completion(struct isci_request *ireq, u32 
completion_code,
-- 
1.8.3.1



[PATCH] fs: fix: second lock in function d_prune_aliases().

2020-12-29 Thread YANG LI
Goto statement jumping will cause lock to be executed again without
executing unlock, placing the lock statement in front of goto
label to fix this problem.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 fs/dcache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index 97e81a8..bf38446 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1050,6 +1050,6 @@ void d_prune_aliases(struct inode *inode)
 {
struct dentry *dentry;
-restart:
spin_lock(&inode->i_lock);
+restart:
hlist_for_each_entry(dentry, &inode->i_dentry, d_u.d_alias) {
spin_lock(&dentry->d_lock);
-- 
1.8.3.1



Re: [PATCH] x86/iommu: Fix two minimal issues in check_iommu_entries()

2020-12-29 Thread Borislav Petkov
On Wed, Dec 23, 2020 at 02:24:12PM +0800, Zhenzhong Duan wrote:
> check_iommu_entries() checks for cyclic dependency in iommu entries
> and fixes the cyclic dependency by setting x->depend to NULL. But
> this repairing isn't correct if q is in front of p, there will be
> "EXECUTION ORDER INVALID!" report following. Fix it by NULLing
> whichever in the front.

When does "q is in front of p" happen? How does it happen?

> The second issue is about the report of exectuion order reverse,
> the order is reversed incorrectly in the report, fix it.

I have no clue what that means.

Plese structure your commit message something like this:

Problem is A.

It happens because of B.

Fix it by doing C.

(Potentially do D).

For more detailed info, see
Documentation/process/submitting-patches.rst, Section "2) Describe your
changes".

Thx.

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette


[PATCH] mm: fix: Uninitialized variable ret.

2020-12-29 Thread YANG LI
The ret is being used but it isn't being initialized,
need to assign a value to it, like 0.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 mm/memcontrol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 605f671..15ba17d 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -3366,7 +3366,7 @@ static int mem_cgroup_resize_max(struct mem_cgroup *memcg,
 {
bool enlarge = false;
bool drained = false;
-   int ret;
+   int ret = 0;
bool limits_invariant;
struct page_counter *counter = memsw ? &memcg->memsw : &memcg->memory;
 
-- 
1.8.3.1



[PATCH] Bluetooth: btusb: Add a Kconfig option to disable USB wakeup by default

2020-12-29 Thread max.chou
From: Max Chou 

For the original commit of 9e45524a011107a73bc2cdde8370c61e82e93a4d,
wakeup is always disabled for Realtek Bluetooth devices.
However, there's the capability for Realtek Bluetooth devices to
apply USB wakeup. Otherwise, there's the better power consumption
without USB wakeup during suspending.
In this commit, divide the original commit into two parts.
1. Redefine the feature that Realtek devices should be enabled wakeup on
auto-suspend as BTUSB_WAKEUP_AUTOSUSPEND.
2. Add a Kconfig option to switch disable_wakeup for Bluetooth
USB devices by default as CONFIG_BT_HCIBTUSB_DISABLEWAKEUP.

Signed-off-by: Max Chou 
---
 drivers/bluetooth/Kconfig | 11 +++
 drivers/bluetooth/btusb.c | 41 ++-
 2 files changed, 38 insertions(+), 14 deletions(-)

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 4e73a531b377..7af10897a248 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -41,6 +41,17 @@ config BT_HCIBTUSB_AUTOSUSPEND
  This can be overridden by passing btusb.enable_autosuspend=[y|n]
  on the kernel commandline.
 
+config BT_HCIBTUSB_DISABLEWAKEUP
+   bool "Disable USB wakeup for Bluetooth USB devices by default"
+   depends on BT_HCIBTUSB
+   default n
+   help
+ Say Y here to disable USB wakeup for Bluetooth USB devices by
+ default.
+
+ This can be overridden by passing btusb.disable_wakeup=[y|n]
+ on the kernel commandline.
+
 config BT_HCIBTUSB_BCM
bool "Broadcom protocol support"
depends on BT_HCIBTUSB
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index b630a1d54c02..5f55111849b5 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -30,6 +30,7 @@
 static bool disable_scofix;
 static bool force_scofix;
 static bool enable_autosuspend = IS_ENABLED(CONFIG_BT_HCIBTUSB_AUTOSUSPEND);
+static bool disable_wakeup = IS_ENABLED(CONFIG_BT_HCIBTUSB_DISABLEWAKEUP);
 
 static bool reset = true;
 
@@ -505,7 +506,7 @@ static const struct dmi_system_id 
btusb_needs_reset_resume_table[] = {
 #define BTUSB_OOB_WAKE_ENABLED 11
 #define BTUSB_HW_RESET_ACTIVE  12
 #define BTUSB_TX_WAIT_VND_EVT  13
-#define BTUSB_WAKEUP_DISABLE   14
+#define BTUSB_WAKEUP_AUTOSUSPEND   14
 
 struct btusb_data {
struct hci_dev   *hdev;
@@ -1330,7 +1331,7 @@ static int btusb_open(struct hci_dev *hdev)
 * For Realtek chips, global suspend without
 * SET_FEATURE (DEVICE_REMOTE_WAKEUP) can save more power in device.
 */
-   if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags))
+   if (disable_wakeup)
device_wakeup_disable(&data->udev->dev);
 
if (test_and_set_bit(BTUSB_INTR_RUNNING, &data->flags))
@@ -1399,7 +1400,7 @@ static int btusb_close(struct hci_dev *hdev)
data->intf->needs_remote_wakeup = 0;
 
/* Enable remote wake up for auto-suspend */
-   if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags))
+   if (test_bit(BTUSB_WAKEUP_AUTOSUSPEND, &data->flags))
data->intf->needs_remote_wakeup = 1;
 
usb_autopm_put_interface(data->intf);
@@ -4257,7 +4258,7 @@ static bool btusb_prevent_wake(struct hci_dev *hdev)
 {
struct btusb_data *data = hci_get_drvdata(hdev);
 
-   if (test_bit(BTUSB_WAKEUP_DISABLE, &data->flags))
+   if (disable_wakeup)
return true;
 
return !device_may_wakeup(&data->udev->dev);
@@ -4557,11 +4558,8 @@ static int btusb_probe(struct usb_interface *intf,
hdev->shutdown = btrtl_shutdown_realtek;
hdev->cmd_timeout = btusb_rtl_cmd_timeout;
 
-   /* Realtek devices lose their updated firmware over global
-* suspend that means host doesn't send SET_FEATURE
-* (DEVICE_REMOTE_WAKEUP)
-*/
-   set_bit(BTUSB_WAKEUP_DISABLE, &data->flags);
+   /* Realtek devices need to set USB remote wakeup on 
auto-suspend */
+   set_bit(BTUSB_WAKEUP_AUTOSUSPEND, &data->flags);
}
 
if (!reset)
@@ -4731,17 +4729,29 @@ static int btusb_suspend(struct usb_interface *intf, 
pm_message_t message)
enable_irq(data->oob_wake_irq);
}
 
-   /* For global suspend, Realtek devices lose the loaded fw
-* in them. But for autosuspend, firmware should remain.
+   /* For suspend(S3), Realtek devices lose the loaded fw
+* if USB wakeup is disabled.
+* It can meet better power consumption.
+* Otherwise, the fw is alive if USB wakeup is enabled.
+* It's able to wake Host up by the paired devices.
+* Note that disable_wakeup should be false,
+* and device_may_wakeup() should return true.
+*
+* For autosuspend, firmware should remain.
 * Actually, it depends on whether the usb host sends
 * set feature (enable wakeup) or not.
 */
-   if (test_

Re: Commit 4257f7e0 ("PCI/ASPM: Save/restore L1SS Capability for suspend/resume") causing hibernate resume failures

2020-12-29 Thread Vidya Sagar

Ideally Bjorn's patch should have worked.
Could you please collect 'sudo lspci -vv' (please don't forget to give 
sudo) with Bjorn's patch before and after hibernate?
Also, is it right to say that with policy set to "performance" there is 
no issue during hibernate/resume?


- Vidya Sagar

On 12/28/2020 12:00 PM, Kenneth R. Crudup wrote:

External email: Use caution opening links or attachments


On Sun, 27 Dec 2020, Kenneth R. Crudup wrote:


I'll try your patch after the revert and see if anything changes.


I just realized today's patch makes no sense if it's reverted, so nevermind.

 -Kenny

--
Kenneth R. Crudup  Sr. SW Engineer, Scott County Consulting, Orange County CA



Re: [PATCH v1 1/2] dt-bindings: drm/bridge: anx7625: add DPI flag and swing setting

2020-12-29 Thread Xin Ji
On Tue, Dec 29, 2020 at 04:34:20PM +0200, Laurent Pinchart wrote:
> Hi Xin Ji,
> 
> On Tue, Dec 29, 2020 at 02:50:48PM +0800, Xin Ji wrote:
> > On Mon, Dec 28, 2020 at 05:08:56PM +0200, Laurent Pinchart wrote:
> > > On Fri, Dec 25, 2020 at 07:01:09PM +0800, Xin Ji wrote:
> > > > Add DPI flag for distinguish MIPI input signal type, DSI or DPI. Add
> > > > swing setting for adjusting DP tx PHY swing
> > > > 
> > > > Signed-off-by: Xin Ji 
> > > > ---
> > > >  .../bindings/display/bridge/analogix,anx7625.yaml | 19 
> > > > +++
> > > >  1 file changed, 19 insertions(+)
> > > > 
> > > > diff --git 
> > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > >  
> > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > index 60585a4..34a7faf 100644
> > > > --- 
> > > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > +++ 
> > > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > > @@ -34,6 +34,14 @@ properties:
> > > >  description: used for reset chip control, RESET_N pin B7.
> > > >  maxItems: 1
> > > >  
> > > > +  anx,swing-setting:
> > > > +$ref: /schemas/types.yaml#/definitions/uint32-array
> > > > +description: an array of swing register setting for DP tx PHY
> > > 
> > > Register values in DT are frowned upon.
> >
> > Hi Laurent Pinchart, as the different vendor has the different PCB layout,
> > it effects DP CTS test result, so they may need config DP tx Swing register
> > to adjust signal swing(the default swing setting is not satisfy for
> > every platform). If we move the config code to driver file, it must define
> > swing register setting for each vendor, so the DT is the best way. Do you
> > have any idea for it if you don't agree to add in DT.
> 
> If it depends on the PCB layout then it should indeed be in DT. What I
> wonder is if there would be a better way to specify the data than
> register values. The ANX7625 datasheet isn't public, so there's
> effectively no way for someone to write a device tree compliant with
> this binding only with the information contained here. Reviewing the
> bindings is equally difficult. It would be best if this property instead
> contained information that could be documented clearly.
Hi Laurent Pinchart, the swing register setting is optional. Basically, no need
to care about it if customer PCB layout match our chip requirement. The
property define just in case. So far, we just found one customer encountered
DP tx swing issue. As the datasheet swing register adjusting algorithm
has a little complex, we will help customer to adjust the DP tx swing
case by case.
> 
> > > > +  anx,mipi-dpi-in:
> > > > +$ref: /schemas/types.yaml#/definitions/uint32
> > > > +description: indicate the MIPI rx signal type is DPI or DSI
> > > 
> > > This sounds similar to the bus-type property defined in
> > > Documentation/devicetree/bindings/media/video-interfaces.txt (which is
> > > getting converted to YAML, Rob has posted a patch series, I expect it to
> > > land in v5.13). I think it would make sense to extend bus-type to
> > > support DSI, and use that property.
> >
> > Sorry, I didn't found any define for DPI or DSI flag in Rob's patches.
> > Do you mean I just remove this flag define and call a special function
> > to read the port's type(DSI or DPI)?
> 
> video-interfaces.yaml has initially been written for cameras, so it
> doesn't support DSI. I think it would make sense to extend the bus-type
> property with a DSI type, and use it here instead of a vendor-specific
> property.
> 
> Alternatively, I'm wondering if this isn't information we could query at
> runtime. DRM bridges and panels have a type, so we could look at the
> next bridge or panel to find the type of the connected device instead of
> specifying it in DT.

At anx7625 driver probe stage, for the DSI, driver needs call some special
interface to attach to DSI interface. For the DPI port, there is no such
limitation, so we need to know what kind of MIPI signal type at driver initial
stage.
Maybe we can keep this flag, if the future has defined DSI, I'll submit new
patch to remove this flag.

Thanks,
Xin

> 
> > > > +
> > > >ports:
> > > >  type: object
> > > >  
> > > > @@ -72,6 +80,17 @@ examples:
> > > >  reg = <0x58>;
> > > >  enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> > > >  reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> > > > +anx,swing-setting = <0x00 0x14>, <0x01 0x54>,
> > > > +<0x02 0x64>, <0x03 0x74>, <0x04 0x29>,
> > > > +<0x05 0x7b>, <0x06 0x77>, <0x07 0x5b>,
> > > > +<0x08 0x7f>, <0x0c 0x20>, <0x0d 0x60>,
> > > > +<0x10 0x60>, <0x12 0x40>, <0x13 0x60>,
> > > > +<0x14 0x14>, <0x15 0x54>, <0x16 0x64>,
> > > > +<0x17 0x74>, <0x18 0x29>, <0x19 0x7b>,
> > > > +<0x1a 0x77>, <0x1b 0x5b

Re: [PATCH 12/21] vhost-vdpa: introduce uAPI to get the number of virtqueue groups

2020-12-29 Thread Jason Wang



On 2020/12/29 下午8:24, Eli Cohen wrote:

On Wed, Dec 16, 2020 at 02:48:09PM +0800, Jason Wang wrote:

Follows the vDPA support for multiple address spaces, this patch
introduce uAPI for the userspace to know the number of virtqueue
groups supported by the vDPA device.

Can you explain what exactly you mean be userspace?



It's the userspace that uses the uAPI introduced in this patch.



Is it just qemu or
is it destined to the virtio_net driver run by the qemu process?



It could be Qemu, DPDK or other userspace program.

The guest virtio-net driver will not use this but talks to the virtio 
device emulated by Qemu.




Also can you say for what purpose?



This can be used for facilitate the checking of whether the control vq 
could be supported.


E.g if the device support less than 2 groups, qemu won't advertise 
control vq.


Yes, #groups could be inferred from GET_VRING_GROUP. But it's not 
straightforward as this.


Thanks





Signed-off-by: Jason Wang 
---
  drivers/vhost/vdpa.c   | 4 
  include/uapi/linux/vhost.h | 3 +++
  2 files changed, 7 insertions(+)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 060d5b5b7e64..1ba5901b28e7 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -536,6 +536,10 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
case VHOST_VDPA_GET_VRING_NUM:
r = vhost_vdpa_get_vring_num(v, argp);
break;
+   case VHOST_VDPA_GET_GROUP_NUM:
+   r = copy_to_user(argp, &v->vdpa->ngroups,
+sizeof(v->vdpa->ngroups));
+   break;
case VHOST_SET_LOG_BASE:
case VHOST_SET_LOG_FD:
r = -ENOIOCTLCMD;
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 59c6c0fbaba1..8a4e6e426bbf 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -145,4 +145,7 @@
  /* Get the valid iova range */
  #define VHOST_VDPA_GET_IOVA_RANGE _IOR(VHOST_VIRTIO, 0x78, \
 struct vhost_vdpa_iova_range)
+/* Get the number of virtqueue groups. */
+#define VHOST_VDPA_GET_GROUP_NUM   _IOR(VHOST_VIRTIO, 0x79, unsigned int)
+
  #endif
--
2.25.1





Re: [PATCH] liquidio: fix: warning: %u in format string (no. 3) requires 'unsigned int' but the argument type is 'signed int'.

2020-12-29 Thread Joe Perches
On Wed, 2020-12-30 at 14:41 +0800, YANG LI wrote:
> For safety, modify '%u' to '%d' to keep the type consistent.

There is no additional safety here.

The for loop ensures that i is positive as num_ioq_vector is also
int and so i can not be negative as it's incremented from 0.

> diff --git a/drivers/net/ethernet/cavium/liquidio/lio_core.c 
> b/drivers/net/ethernet/cavium/liquidio/lio_core.c
[]
> @@ -1109,12 +1109,12 @@ int octeon_setup_interrupt(struct octeon_device *oct, 
> u32 num_ioqs)
>   for (i = 0 ; i < num_ioq_vectors ; i++) {
>   if (OCTEON_CN23XX_PF(oct))
>   snprintf(&queue_irq_names[IRQ_NAME_OFF(i)],
> -  INTRNAMSIZ, "LiquidIO%u-pf%u-rxtx-%u",
> +  INTRNAMSIZ, "LiquidIO%u-pf%u-rxtx-%d",
>    oct->octeon_id, oct->pf_num, i);
>  
> 
>   if (OCTEON_CN23XX_VF(oct))
>   snprintf(&queue_irq_names[IRQ_NAME_OFF(i)],
> -  INTRNAMSIZ, "LiquidIO%u-vf%u-rxtx-%u",
> +  INTRNAMSIZ, "LiquidIO%u-vf%u-rxtx-%d",
>    oct->octeon_id, oct->vf_num, i);
>  
> 
>   irqret = request_irq(msix_entries[i].vector,




[PATCH] 9p: fix: Uninitialized variable p.

2020-12-29 Thread YANG LI
The pointer p is being used but it isn't being initialized,
need to assign a NULL to it.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 net/9p/trans_virtio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/9p/trans_virtio.c b/net/9p/trans_virtio.c
index 93f2f86..d4d635f 100644
--- a/net/9p/trans_virtio.c
+++ b/net/9p/trans_virtio.c
@@ -342,7 +342,7 @@ static int p9_get_mapped_pages(struct virtio_chan *chan,
/* kernel buffer, no need to pin pages */
int index;
size_t len;
-   void *p;
+   void *p = NULL;
 
/* we'd already checked that it's non-empty */
while (1) {
-- 
1.8.3.1



[PATCH] liquidio: fix: warning: %u in format string (no. 3) requires 'unsigned int' but the argument type is 'signed int'.

2020-12-29 Thread YANG LI
For safety, modify '%u' to '%d' to keep the type consistent.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 drivers/net/ethernet/cavium/liquidio/lio_core.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_core.c 
b/drivers/net/ethernet/cavium/liquidio/lio_core.c
index 37d0641..07846f9 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_core.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_core.c
@@ -1109,12 +1109,12 @@ int octeon_setup_interrupt(struct octeon_device *oct, 
u32 num_ioqs)
for (i = 0 ; i < num_ioq_vectors ; i++) {
if (OCTEON_CN23XX_PF(oct))
snprintf(&queue_irq_names[IRQ_NAME_OFF(i)],
-INTRNAMSIZ, "LiquidIO%u-pf%u-rxtx-%u",
+INTRNAMSIZ, "LiquidIO%u-pf%u-rxtx-%d",
 oct->octeon_id, oct->pf_num, i);
 
if (OCTEON_CN23XX_VF(oct))
snprintf(&queue_irq_names[IRQ_NAME_OFF(i)],
-INTRNAMSIZ, "LiquidIO%u-vf%u-rxtx-%u",
+INTRNAMSIZ, "LiquidIO%u-vf%u-rxtx-%d",
 oct->octeon_id, oct->vf_num, i);
 
irqret = request_irq(msix_entries[i].vector,
-- 
1.8.3.1



[PATCH] misc: rtsx: remove unused function

2020-12-29 Thread ricky_wu
From: Ricky Wu 

removed unused function 'rtsx_pci_disable_aspm'

Signed-off-by: Ricky Wu 
---
 drivers/misc/cardreader/rtsx_pcr.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/misc/cardreader/rtsx_pcr.c 
b/drivers/misc/cardreader/rtsx_pcr.c
index 2aa6648fa41f..d782754fa346 100644
--- a/drivers/misc/cardreader/rtsx_pcr.c
+++ b/drivers/misc/cardreader/rtsx_pcr.c
@@ -59,12 +59,6 @@ static const struct pci_device_id rtsx_pci_ids[] = {
 
 MODULE_DEVICE_TABLE(pci, rtsx_pci_ids);
 
-static inline void rtsx_pci_disable_aspm(struct rtsx_pcr *pcr)
-{
-   pcie_capability_clear_and_set_word(pcr->pci, PCI_EXP_LNKCTL,
-  PCI_EXP_LNKCTL_ASPMC, 0);
-}
-
 static int rtsx_comm_set_ltr_latency(struct rtsx_pcr *pcr, u32 latency)
 {
rtsx_pci_write_register(pcr, MSGTXDATA0,
-- 
2.17.1



[PATCH] xen: fix: use WARN_ON instead of if condition followed by BUG.

2020-12-29 Thread YANG LI
Use WARN_ON instead of if condition followed by BUG in
gnttab_batch_map() and gnttab_batch_copy().

This issue was detected with the help of coccicheck.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 drivers/xen/grant-table.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/grant-table.c b/drivers/xen/grant-table.c
index 3729bea..db1770c 100644
--- a/drivers/xen/grant-table.c
+++ b/drivers/xen/grant-table.c
@@ -1080,8 +1080,8 @@ void gnttab_batch_map(struct gnttab_map_grant_ref *batch, 
unsigned count)
 {
struct gnttab_map_grant_ref *op;
 
-   if (HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, batch, count))
-   BUG();
+   WARN_ON(HYPERVISOR_grant_table_op(GNTTABOP_map_grant_ref, batch, 
count));
+
for (op = batch; op < batch + count; op++)
if (op->status == GNTST_eagain)
gnttab_retry_eagain_gop(GNTTABOP_map_grant_ref, op,
@@ -1093,8 +1093,8 @@ void gnttab_batch_copy(struct gnttab_copy *batch, 
unsigned count)
 {
struct gnttab_copy *op;
 
-   if (HYPERVISOR_grant_table_op(GNTTABOP_copy, batch, count))
-   BUG();
+   WARN_ON(HYPERVISOR_grant_table_op(GNTTABOP_copy, batch, count));
+
for (op = batch; op < batch + count; op++)
if (op->status == GNTST_eagain)
gnttab_retry_eagain_gop(GNTTABOP_copy, op,
-- 
1.8.3.1



[PATCH] cifs: style: replace one-element array with flexible-array

2020-12-29 Thread YANG LI
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use "flexible array members"[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9/process/
deprecated.html#zero-length-and-one-element-arrays

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 fs/cifs/smb2pdu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/cifs/smb2pdu.h b/fs/cifs/smb2pdu.h
index 204a622..d85edf5 100644
--- a/fs/cifs/smb2pdu.h
+++ b/fs/cifs/smb2pdu.h
@@ -424,7 +424,7 @@ struct smb2_rdma_transform_capabilities_context {
__le16  TransformCount;
__u16   Reserved1;
__u32   Reserved2;
-   __le16  RDMATransformIds[1];
+   __le16  RDMATransformIds[];
 } __packed;
 
 /* Signing algorithms */
-- 
1.8.3.1



Re: [PATCH 11/21] vhost-vdpa: introduce asid based IOTLB

2020-12-29 Thread Jason Wang



On 2020/12/29 下午7:53, Eli Cohen wrote:

+
+static struct vhost_vdpa_as *vhost_vdpa_alloc_as(struct vhost_vdpa *v, u32 
asid)
+{
+   struct hlist_head *head = &v->as[asid % VHOST_VDPA_IOTLB_BUCKETS];
+   struct vhost_vdpa_as *as;
+
+   if (asid_to_as(v, asid))
+   return NULL;
+
+   as = kmalloc(sizeof(*as), GFP_KERNEL);

kzalloc()? See comment below.


+   if (!as)
+   return NULL;
+
+   vhost_iotlb_init(&as->iotlb, 0, 0);
+   as->id = asid;
+   hlist_add_head(&as->hash_link, head);
+   ++v->used_as;

Although you eventually ended up removing used_as, this is a bug since
you're incrementing a random value. Maybe it's better to be on the safe
side and use kzalloc() for as above.



Yes and used_as needs to be removed.

Thanks









Re: [PATCH 11/21] vhost-vdpa: introduce asid based IOTLB

2020-12-29 Thread Jason Wang



On 2020/12/29 下午8:05, Eli Cohen wrote:

+
+static int vhost_vdpa_remove_as(struct vhost_vdpa *v, u32 asid)

The return value is never interpreted. I think it should either be made
void or return values checked.



Right, will make it void.





+{
+   struct vhost_vdpa_as *as = asid_to_as(v, asid);
+
+   /* Remove default address space is not allowed */
+   if (asid == 0)
+   return -EINVAL;

Can you explain why? I think you have a memory leak due to this as no
one will ever free as with id 0.



Looks like a bug. Will remove this.

Thanks




Re: [PATCH] io_uring: style: redundant NULL check.

2020-12-29 Thread Randy Dunlap
On 12/29/20 10:22 PM, YANG LI wrote:
> If the pointer in kfree is empty, the function does nothing,
> so remove the redundant NULL check.
> 
> Signed-off-by: YANG LI 
> Reported-by: Abaci 
> ---

Looks like you should do something with these 2 comments:

/* it's reportedly faster than delegating the null check to kfree() */

>  fs/io_uring.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 7e35283..105e188 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -1934,8 +1934,8 @@ static void io_dismantle_req(struct io_kiocb *req)
>  {
>   io_clean_op(req);
>  
> - if (req->async_data)
> - kfree(req->async_data);
> + kfree(req->async_data);
> +
>   if (req->file)
>   io_put_file(req, req->file, (req->flags & REQ_F_FIXED_FILE));
>   if (req->fixed_file_refs)
> @@ -3537,8 +3537,7 @@ static int io_read(struct io_kiocb *req, bool 
> force_nonblock,
>   ret = 0;
>  out_free:
>   /* it's reportedly faster than delegating the null check to kfree() */
> - if (iovec)
> - kfree(iovec);
> + kfree(iovec);
>   return ret;
>  }
>  
> @@ -3644,8 +3643,7 @@ static int io_write(struct io_kiocb *req, bool 
> force_nonblock,
>   }
>  out_free:
>   /* it's reportedly faster than delegating the null check to kfree() */
> - if (iovec)
> - kfree(iovec);
> + kfree(iovec);
>   return ret;
>  }
>  
> @@ -6133,8 +6131,7 @@ static void __io_clean_op(struct io_kiocb *req)
>   case IORING_OP_WRITE_FIXED:
>   case IORING_OP_WRITE: {
>   struct io_async_rw *io = req->async_data;
> - if (io->free_iovec)
> - kfree(io->free_iovec);
> + kfree(io->free_iovec);
>   break;
>   }
>   case IORING_OP_RECVMSG:
> 


-- 
~Randy



[PATCH v2 2/2] clocksource: Add Intel Keem Bay Timer Support

2020-12-29 Thread vijayakannan . ayyathurai
From: Vijayakannan Ayyathurai 

Add generic clocksource and clockevent driver for the timer IP used
in Intel Keem Bay SoC.

One free running Counter used as a clocksource device and one Timer
used as a clockevent device. Both are enabled through TIM_GEN_CONFIG
register. This register is in the DT resource index 2.

Timer and Counter base register is in the DT resource index 0 and 1
respectively. This register map/unmap handled by TIMER OF api.

Acked-by: Mark Gross 
Acked-by: Andy Shevchenko 
Signed-off-by: Vijayakannan Ayyathurai 
---
 arch/arm64/Kconfig.platforms|   1 +
 drivers/clocksource/Kconfig |  10 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-keembay.c | 225 
 4 files changed, 237 insertions(+)
 create mode 100644 drivers/clocksource/timer-keembay.c

diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index 6eecdef538bd..12c0c39a27ff 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -146,6 +146,7 @@ config ARCH_HISI
 
 config ARCH_KEEMBAY
bool "Keem Bay SoC"
+   select KEEMBAY_TIMER
help
  This enables support for Intel Movidius SoC code-named Keem Bay.
 
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 14c7c4712478..cebe774fe104 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -728,4 +728,14 @@ config MICROCHIP_PIT64B
  modes and high resolution. It is used as a clocksource
  and a clockevent.
 
+config KEEMBAY_TIMER
+   bool "Intel Keembay timer driver"
+   depends on ARCH_KEEMBAY || (ARM64 && COMPILE_TEST)
+   select TIMER_OF
+   help
+ This option enables the support for the Intel Keembay general
+ purpose timer and free running counter driver. Each timer can
+ generate an individual interrupt and the 64 bit counter can also
+ be used as one of the clock source.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 3c75cbbf8533..584628a56c76 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -93,3 +93,4 @@ obj-$(CONFIG_CSKY_MP_TIMER)   += timer-mp-csky.o
 obj-$(CONFIG_GX6605S_TIMER)+= timer-gx6605s.o
 obj-$(CONFIG_HYPERV_TIMER) += hyperv_timer.o
 obj-$(CONFIG_MICROCHIP_PIT64B) += timer-microchip-pit64b.o
+obj-$(CONFIG_KEEMBAY_TIMER)+= timer-keembay.o
diff --git a/drivers/clocksource/timer-keembay.c 
b/drivers/clocksource/timer-keembay.c
new file mode 100644
index ..f5465b907ba4
--- /dev/null
+++ b/drivers/clocksource/timer-keembay.c
@@ -0,0 +1,225 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Intel Keembay Timer driver
+ *
+ * Copyright (C) 2020 Intel Corporation
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "timer-of.h"
+
+/* Registers offset */
+#define TIM_CNT_VAL_OFFSET 0
+#define TIM_RELOAD_VAL_OFFSET  SZ_4
+#define TIM_CONFIG_OFFSET  SZ_8
+
+/* Bit fields of TIM_GEN_CONFIG register */
+#define TIM_CONFIG_PRESCALER_ENABLEBIT(2)
+
+/* Bit fields of TIM_CONFIG registers */
+#define TIM_CONFIG_INTERRUPT_PENDING   BIT(4)
+#define TIM_CONFIG_INTERRUPT_ENABLEBIT(2)
+#define TIM_CONFIG_RESTART BIT(1)
+#define TIM_CONFIG_ENABLE  BIT(0)
+
+#define TIM_RATING 200
+#define TIM_CLKSRC_BITSSZ_64
+
+struct keembay_init_data {
+   struct timer_of *cfg;
+   void __iomem*base;
+   u32 mask;
+};
+
+static inline void keembay_timer_disable(void __iomem *base)
+{
+   writel(0, base + TIM_CONFIG_OFFSET);
+}
+
+static inline void keembay_timer_enable(void __iomem *base, u32 flags)
+{
+   writel(TIM_CONFIG_ENABLE | flags, base + TIM_CONFIG_OFFSET);
+}
+
+static inline void keembay_timer_update_counter(void __iomem *base, u32 val)
+{
+   writel(val, base + TIM_CNT_VAL_OFFSET);
+   writel(val, base + TIM_RELOAD_VAL_OFFSET);
+}
+
+static int keembay_timer_set_next_event(unsigned long evt, struct 
clock_event_device *ce)
+{
+   u32 flags = TIM_CONFIG_INTERRUPT_ENABLE;
+   struct timer_of *to = to_timer_of(ce);
+
+   keembay_timer_disable(timer_of_base(to));
+   keembay_timer_update_counter(timer_of_base(to), evt);
+   keembay_timer_enable(timer_of_base(to), flags);
+
+   return 0;
+}
+
+static int keembay_timer_periodic(struct clock_event_device *ce)
+{
+   u32 flags = TIM_CONFIG_INTERRUPT_ENABLE | TIM_CONFIG_RESTART;
+   struct timer_of *to = to_timer_of(ce);
+
+   keembay_timer_disable(timer_of_base(to));
+   keembay_timer_update_counter(timer_of_base(to), timer_of_period(to));
+   keembay_timer_enable(timer_of_base(to), flags);
+
+   return 0;
+}
+
+static int keembay_timer_shutdown(struct clock_event_device *ce)
+{
+   struct timer_of *to = to_timer_of(ce);
+
+   keem

[PATCH v2 1/2] dt-bindings: timer: Add bindings for Intel Keem Bay SoC timer

2020-12-29 Thread vijayakannan . ayyathurai
From: Vijayakannan Ayyathurai 

Add Device Tree bindings for the Timer IP, which used as clocksource and
clockevent device in the Intel Keem Bay SoC.

Acked-by: Mark Gross 
Acked-by: Andy Shevchenko 
Signed-off-by: Vijayakannan Ayyathurai 
---
 .../bindings/timer/intel,keembay-timer.yaml   | 52 +++
 1 file changed, 52 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml

diff --git a/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml 
b/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml
new file mode 100644
index ..197493336ac2
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/timer/intel,keembay-timer.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Keem Bay SoC Timers
+
+maintainers:
+  - Wan Ahmad Zainie 
+  - Vijayakannan Ayyathurai 
+
+description:
+  Intel Keem Bay SoC Timers block contains 8 32-bit general purpose timers,
+  a free running 64-bit counter, a random number generator and a watchdog
+  timer. Each gpt can generate an individual interrupt.
+
+properties:
+  compatible:
+enum:
+  - intel,keembay-timer
+
+  reg:
+maxItems: 3
+
+  clocks:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#define KEEM_BAY_A53_TIM
+
+timer@20330010 {
+compatible = "intel,keembay-timer";
+reg = <0x20330010 0xc>,
+  <0x203300e8 0xc>,
+  <0x20331000 0xc>;
+clocks = <&scmi_clk KEEM_BAY_A53_TIM>;
+interrupts = ;
+};
-- 
2.17.1



[PATCH v2 0/2] Add drivers for Intel Keem Bay SoC timer block

2020-12-29 Thread vijayakannan . ayyathurai
From: Vijayakannan Ayyathurai 

Hi,

This patch set adds the driver for Intel Keem Bay SoC timer block, which
contains 32-bit general purpose timers, a 64 bit free running counter.

Patch 1 holds the Device Tree binding documentation and
Patch 2 holds the Device Driver for clocksource and clockevent.

It was tested on the Keem Bay evaluation module board.

Thanks,
Vijay

Changes since v1:
 - Add support for KEEMBAY_TIMER to get selected through Kconfig.platforms.
 - Add CLOCK_EVT_FEAT_DYNIRQ as part of clockevent feature.
 - Avoid overlapping reg regions across 2 device nodes.
 - Simplify 2 device nodes as 1 because both are from same IP block.
 - Adapt the driver code according to the new simplified devicetree.

Vijayakannan Ayyathurai (2):
  dt-bindings: timer: Add bindings for Intel Keem Bay SoC timer
  clocksource: Add Intel Keem Bay Timer Support

 .../bindings/timer/intel,keembay-timer.yaml   |  52 
 arch/arm64/Kconfig.platforms  |   1 +
 drivers/clocksource/Kconfig   |  10 +
 drivers/clocksource/Makefile  |   1 +
 drivers/clocksource/timer-keembay.c   | 225 ++
 5 files changed, 289 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/intel,keembay-timer.yaml
 create mode 100644 drivers/clocksource/timer-keembay.c


base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
prerequisite-patch-id: bbb340c3a34059ea6960e8b96f5ad3bf0b4ae7b0
prerequisite-patch-id: b71b548284a57a38ce96d9bb523eadfccabd6e02
-- 
2.17.1



[PATCH] mlx4: style: replace zero-length array with flexible-array member.

2020-12-29 Thread YANG LI
There is a regular need in the kernel to provide a way to declare
having a dynamically sized set of trailing elements in a structure.
Kernel code should always use "flexible array members"[1] for these
cases. The older style of one-element or zero-length arrays should
no longer be used[2].

[1] https://en.wikipedia.org/wiki/Flexible_array_member
[2] https://www.kernel.org/doc/html/v5.9/process/
deprecated.html#zero-length-and-one-element-arrays

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h 
b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
index e8ed2319..4029a8b 100644
--- a/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
+++ b/drivers/net/ethernet/mellanox/mlx4/mlx4_en.h
@@ -314,7 +314,7 @@ struct mlx4_en_tx_ring {
 
 struct mlx4_en_rx_desc {
/* actual number of entries depends on rx ring stride */
-   struct mlx4_wqe_data_seg data[0];
+   struct mlx4_wqe_data_seg data[];
 };
 
 struct mlx4_en_rx_ring {
-- 
1.8.3.1



Re: [PATCH] liquidio: style: Identical condition and return expression 'retval', return value is always 0.

2020-12-29 Thread Joe Perches
On Wed, 2020-12-30 at 14:07 +0800, YANG LI wrote:
> The warning was because of the following line in function
> liquidio_set_fec():
> 
> retval = wait_for_sc_completion_timeout(oct, sc, 0);
> if (retval)
>   return (-EIO);

I presume abaci is a robot

Perhaps also the robot could look for code immediately above this like:

oct->props[lio->ifidx].fec = var;
if (resp->fec_setting == SEAPI_CMD_FEC_SET_RS)
oct->props[lio->ifidx].fec = 1;
else
oct->props[lio->ifidx].fec = 0;

where a location is immediately overwritten.

so the line
oct->props[lio->ifidx].fec = var;
could be highlighted and perhaps removed
and also perhaps the second test and set block could be written

oct->props[lio->ifidx].fec = resp->fec_setting == 
SEAPI_CMD_FEC_SET_RS;





Re: [PATCH 11/21] vhost-vdpa: introduce asid based IOTLB

2020-12-29 Thread Jason Wang



On 2020/12/29 下午7:41, Eli Cohen wrote:

On Wed, Dec 16, 2020 at 02:48:08PM +0800, Jason Wang wrote:

This patch converts the vhost-vDPA device to support multiple IOTLBs
tagged via ASID via hlist. This will be used for supporting multiple
address spaces in the following patches.

Signed-off-by: Jason Wang 
---
  drivers/vhost/vdpa.c | 106 ---
  1 file changed, 80 insertions(+), 26 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index feb6a58df22d..060d5b5b7e64 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -33,13 +33,21 @@ enum {
  
  #define VHOST_VDPA_DEV_MAX (1U << MINORBITS)
  
+#define VHOST_VDPA_IOTLB_BUCKETS 16

+
+struct vhost_vdpa_as {
+   struct hlist_node hash_link;
+   struct vhost_iotlb iotlb;
+   u32 id;
+};
+
  struct vhost_vdpa {
struct vhost_dev vdev;
struct iommu_domain *domain;
struct vhost_virtqueue *vqs;
struct completion completion;
struct vdpa_device *vdpa;
-   struct vhost_iotlb *iotlb;
+   struct hlist_head as[VHOST_VDPA_IOTLB_BUCKETS];
struct device dev;
struct cdev cdev;
atomic_t opened;
@@ -49,12 +57,64 @@ struct vhost_vdpa {
struct eventfd_ctx *config_ctx;
int in_batch;
struct vdpa_iova_range range;
+   int used_as;

This is not really used. Not in this patch and later removed.



Right, will remove this.

Thanks




[PATCH] io_uring: style: redundant NULL check.

2020-12-29 Thread YANG LI
If the pointer in kfree is empty, the function does nothing,
so remove the redundant NULL check.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 fs/io_uring.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 7e35283..105e188 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -1934,8 +1934,8 @@ static void io_dismantle_req(struct io_kiocb *req)
 {
io_clean_op(req);
 
-   if (req->async_data)
-   kfree(req->async_data);
+   kfree(req->async_data);
+
if (req->file)
io_put_file(req, req->file, (req->flags & REQ_F_FIXED_FILE));
if (req->fixed_file_refs)
@@ -3537,8 +3537,7 @@ static int io_read(struct io_kiocb *req, bool 
force_nonblock,
ret = 0;
 out_free:
/* it's reportedly faster than delegating the null check to kfree() */
-   if (iovec)
-   kfree(iovec);
+   kfree(iovec);
return ret;
 }
 
@@ -3644,8 +3643,7 @@ static int io_write(struct io_kiocb *req, bool 
force_nonblock,
}
 out_free:
/* it's reportedly faster than delegating the null check to kfree() */
-   if (iovec)
-   kfree(iovec);
+   kfree(iovec);
return ret;
 }
 
@@ -6133,8 +6131,7 @@ static void __io_clean_op(struct io_kiocb *req)
case IORING_OP_WRITE_FIXED:
case IORING_OP_WRITE: {
struct io_async_rw *io = req->async_data;
-   if (io->free_iovec)
-   kfree(io->free_iovec);
+   kfree(io->free_iovec);
break;
}
case IORING_OP_RECVMSG:
-- 
1.8.3.1



Review request 0/2: init/main.c: sink the kernel_init to the bottom

2020-12-29 Thread Liu Peibao
It looks better that sinking the kernel_init() to bottom. And such the
statement of kernel_init_freeable() is redundant. Also there is a
warning found by the checkpatch.pl.



[PATCH 2/2] init/main.c: sink the kernel_init to the bottom

2020-12-29 Thread Liu Peibao
Remove the redundant kernel_init_freeable statement.

Signed-off-by: Liu Peibao 
---
 init/main.c | 132 ++--
 1 file changed, 65 insertions(+), 67 deletions(-)

diff --git a/init/main.c b/init/main.c
index 1e492de770c8..d5c2fa85ee54 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1364,8 +1364,6 @@ static int try_to_run_init_process(const char 
*init_filename)
return ret;
 }
 
-static noinline void __init kernel_init_freeable(void);
-
 #if defined(CONFIG_STRICT_KERNEL_RWX) || defined(CONFIG_STRICT_MODULE_RWX)
 bool rodata_enabled __ro_after_init = true;
 static int __init set_debug_rodata(char *str)
@@ -1408,71 +1406,6 @@ void __weak free_initmem(void)
free_initmem_default(POISON_FREE_INITMEM);
 }
 
-static int __ref kernel_init(void *unused)
-{
-   int ret;
-
-   kernel_init_freeable();
-   /* need to finish all async __init code before freeing the memory */
-   async_synchronize_full();
-   kprobe_free_init_mem();
-   ftrace_free_init_mem();
-   free_initmem();
-   mark_readonly();
-
-   /*
-* Kernel mappings are now finalized - update the userspace page-table
-* to finalize PTI.
-*/
-   pti_finalize();
-
-   system_state = SYSTEM_RUNNING;
-   numa_default_policy();
-
-   rcu_end_inkernel_boot();
-
-   do_sysctl_args();
-
-   if (ramdisk_execute_command) {
-   ret = run_init_process(ramdisk_execute_command);
-   if (!ret)
-   return 0;
-   pr_err("Failed to execute %s (error %d)\n",
-  ramdisk_execute_command, ret);
-   }
-
-   /*
-* We try each of these until one succeeds.
-*
-* The Bourne shell can be used instead of init if we are
-* trying to recover a really broken machine.
-*/
-   if (execute_command) {
-   ret = run_init_process(execute_command);
-   if (!ret)
-   return 0;
-   panic("Requested init %s failed (error %d).",
- execute_command, ret);
-   }
-
-   if (CONFIG_DEFAULT_INIT[0] != '\0') {
-   ret = run_init_process(CONFIG_DEFAULT_INIT);
-   if (ret)
-   pr_err("Default init %s failed (error %d)\n",
-  CONFIG_DEFAULT_INIT, ret);
-   else
-   return 0;
-   }
-
-   if (!try_to_run_init_process("/sbin/init") ||
-   !try_to_run_init_process("/etc/init") ||
-   !try_to_run_init_process("/bin/init") ||
-   !try_to_run_init_process("/bin/sh"))
-   return 0;
-
-   panic("No working init found. Try passing init= option to kernel. See 
Linux Documentation/admin-guide/init.rst for guidance.");
-}
-
 /* Open /dev/console, for stdin/stdout/stderr, this should never fail */
 void __init console_on_rootfs(void)
 {
@@ -1554,3 +1487,68 @@ static noinline void __init kernel_init_freeable(void)
 
integrity_load_keys();
 }
+
+static int __ref kernel_init(void *unused)
+{
+   int ret;
+
+   kernel_init_freeable();
+   /* need to finish all async __init code before freeing the memory */
+   async_synchronize_full();
+   kprobe_free_init_mem();
+   ftrace_free_init_mem();
+   free_initmem();
+   mark_readonly();
+
+   /*
+* Kernel mappings are now finalized - update the userspace page-table
+* to finalize PTI.
+*/
+   pti_finalize();
+
+   system_state = SYSTEM_RUNNING;
+   numa_default_policy();
+
+   rcu_end_inkernel_boot();
+
+   do_sysctl_args();
+
+   if (ramdisk_execute_command) {
+   ret = run_init_process(ramdisk_execute_command);
+   if (!ret)
+   return 0;
+   pr_err("Failed to execute %s (error %d)\n",
+  ramdisk_execute_command, ret);
+   }
+
+   /*
+* We try each of these until one succeeds.
+*
+* The Bourne shell can be used instead of init if we are
+* trying to recover a really broken machine.
+*/
+   if (execute_command) {
+   ret = run_init_process(execute_command);
+   if (!ret)
+   return 0;
+   panic("Requested init %s failed (error %d).",
+ execute_command, ret);
+   }
+
+   if (CONFIG_DEFAULT_INIT[0] != '\0') {
+   ret = run_init_process(CONFIG_DEFAULT_INIT);
+   if (ret)
+   pr_err("Default init %s failed (error %d)\n",
+  CONFIG_DEFAULT_INIT, ret);
+   else
+   return 0;
+   }
+
+   if (!try_to_run_init_process("/sbin/init") ||
+   !try_to_run_init_process("/etc/init") ||
+   !try_to_run_init_process("/bin/init") ||
+   !try_to_run_init_process("/bin/sh"))

[PATCH] liquidio: style: Identical condition and return expression 'retval', return value is always 0.

2020-12-29 Thread YANG LI
The warning was because of the following line in function
liquidio_get_fec():

retval = wait_for_sc_completion_timeout(oct, sc, 0);
if (retval)
return retval;

If this statement is not true, retval must be 0 and not updated
later. So, It is better to return 0 directly.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 drivers/net/ethernet/cavium/liquidio/lio_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_core.c 
b/drivers/net/ethernet/cavium/liquidio/lio_core.c
index 37d0641..cff18a0 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_core.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_core.c
@@ -1811,5 +1811,5 @@ int liquidio_get_fec(struct lio *lio)
oct->props[lio->ifidx].fec ? "on" : "off");
}
 
-   return retval;
+   return 0;
 }
-- 
1.8.3.1



ERROR: modpost: ".__warn_printk" undefined!

2020-12-29 Thread kernel test robot
Hi Christoph,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   139711f033f636cc78b6aaf7363252241b9698ef
commit: a7b75c5a8c41445f33efb663887ff5f5c3b4454b net: pass a sockptr_t into 
->setsockopt
date:   5 months ago
config: powerpc-randconfig-r034-20201225 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a7b75c5a8c41445f33efb663887ff5f5c3b4454b
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout a7b75c5a8c41445f33efb663887ff5f5c3b4454b
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

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: ".ktime_get_with_offset" [net/nfc/nfc.ko] undefined!
ERROR: modpost: ".sock_alloc_send_skb" [net/nfc/nfc.ko] undefined!
ERROR: modpost: ".skb_recv_datagram" [net/nfc/nfc.ko] undefined!
ERROR: modpost: ".skb_queue_head" [net/nfc/nfc.ko] undefined!
ERROR: modpost: "._copy_from_user" [net/nfc/nfc.ko] undefined!
ERROR: modpost: "._raw_read_lock" [net/nfc/nfc.ko] undefined!
ERROR: modpost: ".request_key_tag" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".strlen" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".key_put" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".user_read" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".up_read" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".revert_creds" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".kstrtoull" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".key_revoke" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".__kmalloc" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".down_read" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".key_invalidate" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".seq_puts" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".prepare_kernel_cred" [net/dns_resolver/dns_resolver.ko] 
undefined!
ERROR: modpost: ".strcasecmp" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".seq_printf" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".register_key_type" [net/dns_resolver/dns_resolver.ko] 
undefined!
ERROR: modpost: ".key_validate" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".memcpy" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".strncasecmp" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".__put_cred" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".memchr" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".__invalid_creds" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".unregister_key_type" [net/dns_resolver/dns_resolver.ko] 
undefined!
ERROR: modpost: ".kmemdup_nul" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".keyring_alloc" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".override_creds" [net/dns_resolver/dns_resolver.ko] undefined!
ERROR: modpost: ".creds_are_invalid" [net/dns_resolver/dns_resolver.ko] 
undefined!
ERROR: modpost: ".dev_remove_pack" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".unregister_netdevice_notifier" [net/caif/caif_usb.ko] 
undefined!
ERROR: modpost: ".register_netdevice_notifier" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".strlcpy" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".dev_add_pack" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".caif_enroll_dev" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".snprintf" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".kmem_cache_alloc" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".__module_get" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".module_put" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".strcmp" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".cfpkt_extr_head" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".cfpkt_add_head" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".memset" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".kfree_skb" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".cfpkt_info" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".cfpkt_tonative" [net/caif/caif_usb.ko] undefined!
ERROR: modpost: ".sock_unregister" [net/caif/caif_socket.ko] undefined!
ERROR: modpost: ".sock_register" [net/caif/caif_socket.ko] undefined!
ERROR: modpost: ".skb_p

[PATCH] liquidio: style: Identical condition and return expression 'retval', return value is always 0.

2020-12-29 Thread YANG LI
The warning was because of the following line in function
liquidio_set_fec():

retval = wait_for_sc_completion_timeout(oct, sc, 0);
if (retval)
return (-EIO);

If this statement is not true, retval must be 0 and not updated
later. So, It is better to return 0 directly.

Signed-off-by: YANG LI 
Reported-by: Abaci 
---
 drivers/net/ethernet/cavium/liquidio/lio_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/cavium/liquidio/lio_core.c 
b/drivers/net/ethernet/cavium/liquidio/lio_core.c
index 37d0641..6e2426f 100644
--- a/drivers/net/ethernet/cavium/liquidio/lio_core.c
+++ b/drivers/net/ethernet/cavium/liquidio/lio_core.c
@@ -1747,7 +1747,7 @@ int liquidio_set_fec(struct lio *lio, int on_off)
oct->props[lio->ifidx].fec ? "on" : "off");
}
 
-   return retval;
+   return 0;
 }
 
 int liquidio_get_fec(struct lio *lio)
-- 
1.8.3.1



[PATCH 1/2] init/main.c: fix strings split across lines

2020-12-29 Thread Liu Peibao
Fix warning found by checkpatch.pl.

Signed-off-by: Liu Peibao 
---
 init/main.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/init/main.c b/init/main.c
index 6feee7f11eaf..1e492de770c8 100644
--- a/init/main.c
+++ b/init/main.c
@@ -1470,8 +1470,7 @@ static int __ref kernel_init(void *unused)
!try_to_run_init_process("/bin/sh"))
return 0;
 
-   panic("No working init found.  Try passing init= option to kernel. "
- "See Linux Documentation/admin-guide/init.rst for guidance.");
+   panic("No working init found. Try passing init= option to kernel. See 
Linux Documentation/admin-guide/init.rst for guidance.");
 }
 
 /* Open /dev/console, for stdin/stdout/stderr, this should never fail */
-- 
2.17.1



[PATCH] initramfs: fix "Decoding failed"

2020-12-29 Thread Hongfei Shang
From: Hongfei Shang 

when initrd image file load in memory, it is align to 4 bytes,
so there are may be some padding bytes(<4),
should ignore these padding bytes and handle as normal end

before: (when size of initrd.img is: size%4 = 1, 2 or 3)
"Initramfs unpacking failed: Decoding failed"

after:
no error message

Signed-off-by: Hongfei Shang 
---
 lib/decompress_unlz4.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/lib/decompress_unlz4.c b/lib/decompress_unlz4.c
index c0cfcfd486be..7527f1541dfd 100644
--- a/lib/decompress_unlz4.c
+++ b/lib/decompress_unlz4.c
@@ -181,6 +181,14 @@ STATIC inline int INIT unlz4(u8 *input, long in_len,
goto exit_2;
}
inp += chunksize;
+
+   if (size < 4) {
+   unsigned int padding = 0;
+
+   memcpy(&padding, inp, size);
+   if (padding == 0)
+   break;
+   }
}
}
 
-- 
2.25.1



Re: [PATCH] checkpatch: ignore warning designated initializers using NR_CPUS

2020-12-29 Thread Joe Perches
On Wed, 2020-12-30 at 12:13 +0800, Peng Wang wrote:
> Some max_length wants to hold as large room as possible to
> ensure enough size to tackle with the biggest NR_CPUS. As
> an example below:
> 
> kernel/cgroup/cpuset.c:
> static struct cftype legacy_files[] = {
> {
> .name = "cpus",
> .seq_show = cpuset_common_seq_show,
> .write = cpuset_write_resmask,
> .max_write_len = (100U + 6 * NR_CPUS),
> .private = FILE_CPULIST,
> },
>   ...
> }
[]
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -7022,12 +7022,15 @@ sub process {
>  
> 
>  # use of NR_CPUS is usually wrong
>  # ignore definitions of NR_CPUS and usage to define arrays as likely right
> +# ignore designated initializers using NR_CPUS
> +
>   if ($line =~ /\bNR_CPUS\b/ &&
>   $line !~ /^.\s*\s*#\s*if\b.*\bNR_CPUS\b/ &&
>   $line !~ /^.\s*\s*#\s*define\b.*\bNR_CPUS\b/ &&
>   $line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/ &&
>   $line !~ /\[[^\]]*\.\.\.[^\]]*NR_CPUS[^\]]*\]/ &&
> - $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/)
> + $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/ &&
> + $line !~ /\s*\..*=.*\bNR_CPUS\b.*,$/)
>   {
>   WARN("NR_CPUS",
>    "usage of NR_CPUS is often wrong - consider using 
> cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . 
> $herecurr);

I wonder if it's worth it as there just aren't many of these: (6 total)

$ git grep -P '\..*=.*\bNR_CPUS\b.*,\s*$'
drivers/firmware/efi/efi.c: .cpu_bitmap = { 
[BITS_TO_LONGS(NR__CPUS)] = 0},
drivers/infiniband/hw/hfi1/sdma.c:  .max_size = NR_CPUS,
init/init_task.c:   .nr_cpus_allowed= NR_CPUS,
kernel/cgroup/cpuset.c: .max_write_len = (100U + 6 * NR_CPUS),
kernel/cgroup/cpuset.c: .max_write_len = (100U + 6 * NR_CPUS),
kernel/sysctl.c:.maxlen = NR_CPUS,

It also seems it might be more sensible as:

$line !~ /^.\s*\.\w+\s*=\s*.*\bNR_CPUS\b/

Which finds a couple more:

$ git grep -P '^\s*\.\w+\s*=\s*.*\bNR_CPUS\b'
arch/arm64/include/asm/processor.h: .fpsimd_cpu = NR_CPUS,  
\
arch/powerpc/kernel/prom_init.c:.max_cpus = 
cpu_to_be32(NR_CPUS),   /* number of cores supported */
drivers/firmware/efi/efi.c: .cpu_bitmap = { 
[BITS_TO_LONGS(NR_CPUS)] = 0},
drivers/infiniband/hw/hfi1/sdma.c:  .max_size = NR_CPUS,
init/init_task.c:   .nr_cpus_allowed= NR_CPUS,
kernel/cgroup/cpuset.c: .max_write_len = (100U + 6 * NR_CPUS),
kernel/cgroup/cpuset.c: .max_write_len = (100U + 6 * NR_CPUS),
kernel/sysctl.c:.maxlen = NR_CPUS,




Re: [PATCH] RDMA/ocrdma: fix use after free in ocrdma_dealloc_ucontext_pd()

2020-12-29 Thread Leon Romanovsky
On Tue, Dec 29, 2020 at 06:46:53PM -0800, t...@redhat.com wrote:
> From: Tom Rix 
>
> In ocrdma_dealloc_ucontext_pd() uctx->cntxt_pd is assigned to
> the variable pd and then after uctx->cntxt_pd is freed, the
> variable pd is passed to function _ocrdma_dealloc_pd() which
> dereferences pd directly or through its call to
> ocrdma_mbx_dealloc_pd().
>
> Reorder the free using the variable pd.
>
> Fixes: 21a428a019c9 ("RDMA: Handle PD allocations by IB/core")
> Signed-off-by: Tom Rix 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Thanks,
Reviewed-by: Leon Romanovsky 


Re: [PATCH v2 11/48] opp: Add dev_pm_opp_find_level_ceil()

2020-12-29 Thread Viresh Kumar
On 28-12-20, 17:03, Dmitry Osipenko wrote:
> 28.12.2020 09:22, Viresh Kumar пишет:
> > On 24-12-20, 16:00, Dmitry Osipenko wrote:
> >> In a device driver I want to set PD to the lowest performance state by
> >> removing the performance vote when dev_pm_opp_set_rate(dev, 0) is
> >> invoked by the driver.
> >>
> >> The OPP core already does this, but if OPP levels don't start from 0 in
> >> a device-tree for PD, then it currently doesn't work since there is a
> >> need to get a rounded-up performance state because
> >> dev_pm_opp_set_voltage() takes OPP entry for the argument (patches 9 and
> >> 28).
> >>
> >> The PD powering off and performance-changes are separate from each other
> >> in the GENPD core. The GENPD core automatically turns off domain when
> >> all devices within the domain are suspended by system-suspend or RPM.
> >>
> >> The performance state of a power domain is controlled solely by a device
> >> driver. GENPD core only aggregates the performance requests, it doesn't
> >> change the performance state of a domain by itself when device is
> >> suspended or resumed, IIUC this is intentional. And I want to put domain
> >> into lowest performance state when device is suspended.
> > 
> > Right, so if you really want to just drop the performance vote, then with a
> > value of 0 for the performance state the call will reach to your genpd's
> > callback ->set_performance_state(). Just as dev_pm_opp_set_rate() accepts 
> > the
> > frequency to be 0, I would expect dev_pm_opp_set_rate() to accept opp 
> > argument
> > as NULL and in that case set voltage to 0 and do regulator_disable() as 
> > well.
> > Won't that work better than going for the lowest voltage ?
> > 
> 
> We can make dev_pm_opp_set_voltage() to accept OPP=NULL in order to
> disable the regulator, like it's done for dev_pm_opp_set_rate(dev, 0).
> Although, I don't need this kind of behaviour for the Tegra PD driver,
> and thus, would prefer to leave this for somebody else to implement in
> the future, once it will be really needed.
> 
> Still we need the dev_pm_opp_find_level_ceil() because level=0 means
> that we want to set PD to the lowest (minimal) performance state, i.e.
> it doesn't necessarily mean that we want to set the voltage to 0 and
> disable the PD entirely. GENPD has a separate controls for on/off.

Ok.

-- 
viresh


[PATCH] mailbox: arm_mhuv2: Fix sparse warnings

2020-12-29 Thread Viresh Kumar
This patch fixes a bunch of sparse warnings in the newly added arm_mhuv2
driver.

drivers/mailbox/arm_mhuv2.c:506:24: warning: incorrect type in argument 1 
(different address spaces)
drivers/mailbox/arm_mhuv2.c:506:24:expected void const volatile [noderef] 
__iomem *addr
drivers/mailbox/arm_mhuv2.c:506:24:got unsigned int [usertype] *
drivers/mailbox/arm_mhuv2.c:547:42: warning: incorrect type in argument 2 
(different address spaces)
drivers/mailbox/arm_mhuv2.c:547:42:expected unsigned int [usertype] *reg
drivers/mailbox/arm_mhuv2.c:547:42:got unsigned int [noderef] __iomem *
drivers/mailbox/arm_mhuv2.c:625:42: warning: incorrect type in argument 2 
(different address spaces)
drivers/mailbox/arm_mhuv2.c:625:42:expected unsigned int [usertype] *reg
drivers/mailbox/arm_mhuv2.c:625:42:got unsigned int [noderef] __iomem *
drivers/mailbox/arm_mhuv2.c:972:24: warning: dereference of noderef expression
drivers/mailbox/arm_mhuv2.c:973:22: warning: dereference of noderef expression
drivers/mailbox/arm_mhuv2.c:993:25: warning: dereference of noderef expression
drivers/mailbox/arm_mhuv2.c:1026:24: warning: dereference of noderef expression
drivers/mailbox/arm_mhuv2.c:1027:22: warning: dereference of noderef expression
drivers/mailbox/arm_mhuv2.c:1048:17: warning: dereference of noderef expression

Reported-by: kernel test robot 
Signed-off-by: Viresh Kumar 
---
 drivers/mailbox/arm_mhuv2.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/mailbox/arm_mhuv2.c b/drivers/mailbox/arm_mhuv2.c
index 67fb10885bb4..8223c1005254 100644
--- a/drivers/mailbox/arm_mhuv2.c
+++ b/drivers/mailbox/arm_mhuv2.c
@@ -238,19 +238,19 @@ struct mhuv2_mbox_chan_priv {
 };
 
 /* Macro for reading a bitfield within a physically mapped packed struct */
-#define readl_relaxed_bitfield(_regptr, _field)
\
+#define readl_relaxed_bitfield(_regptr, _type, _field) \
({  \
u32 _regval;\
_regval = readl_relaxed((_regptr)); \
-   (*(typeof((_regptr)))(&_regval))._field;\
+   (*(_type *)(&_regval))._field;  \
})
 
 /* Macro for writing a bitfield within a physically mapped packed struct */
-#define writel_relaxed_bitfield(_value, _regptr, _field)   \
+#define writel_relaxed_bitfield(_value, _regptr, _type, _field)
\
({  \
u32 _regval;\
_regval = readl_relaxed(_regptr);   \
-   (*(typeof(_regptr))(&_regval))._field = _value; \
+   (*(_type *)(&_regval))._field = _value; \
writel_relaxed(_regval, _regptr);   \
})
 
@@ -496,7 +496,7 @@ static const struct mhuv2_protocol_ops 
mhuv2_data_transfer_ops = {
 
 /* Interrupt handlers */
 
-static struct mbox_chan *get_irq_chan_comb(struct mhuv2 *mhu, u32 *reg)
+static struct mbox_chan *get_irq_chan_comb(struct mhuv2 *mhu, u32 __iomem *reg)
 {
struct mbox_chan *chans = mhu->mbox.chans;
int channel = 0, i, offset = 0, windows, protocol, ch_wn;
@@ -969,8 +969,8 @@ static int mhuv2_tx_init(struct amba_device *adev, struct 
mhuv2 *mhu,
mhu->mbox.ops = &mhuv2_sender_ops;
mhu->send = reg;
 
-   mhu->windows = readl_relaxed_bitfield(&mhu->send->mhu_cfg, num_ch);
-   mhu->minor = readl_relaxed_bitfield(&mhu->send->aidr, arch_minor_rev);
+   mhu->windows = readl_relaxed_bitfield(&mhu->send->mhu_cfg, struct 
mhu_cfg_t, num_ch);
+   mhu->minor = readl_relaxed_bitfield(&mhu->send->aidr, struct aidr_t, 
arch_minor_rev);
 
spin_lock_init(&mhu->doorbell_pending_lock);
 
@@ -990,7 +990,7 @@ static int mhuv2_tx_init(struct amba_device *adev, struct 
mhuv2 *mhu,
mhu->mbox.txdone_poll = false;
mhu->irq = adev->irq[0];
 
-   writel_relaxed_bitfield(1, &mhu->send->int_en, chcomb);
+   writel_relaxed_bitfield(1, &mhu->send->int_en, struct 
int_en_t, chcomb);
 
/* Disable all channel interrupts */
for (i = 0; i < mhu->windows; i++)
@@ -1023,8 +1023,8 @@ static int mhuv2_rx_init(struct amba_device *adev, struct 
mhuv2 *mhu,
mhu->mbox.ops = &mhuv2_receiver_ops;
mhu->recv = reg;
 
-   mhu->windows = readl_relaxed_bitfield(&mhu->recv->mhu_cfg, num_ch);
-   mhu->minor = readl_relaxed_bitfield(&mhu->recv->aidr, arch_minor_rev);
+   mhu->windows = readl_relaxed_bitfield(&mhu->recv->mhu_cfg, struct 
mhu_cfg_t, num_ch);
+   mhu->minor = readl_relaxed_bitfield(&mhu->recv->aidr, struct aidr_t, 
a

Re: [PATCH 10/21] vhost: support ASID in IOTLB API

2020-12-29 Thread Jason Wang



On 2020/12/29 下午6:20, Eli Cohen wrote:

-static int vhost_process_iotlb_msg(struct vhost_dev *dev,
+static int vhost_process_iotlb_msg(struct vhost_dev *dev, u16 asid,
   struct vhost_iotlb_msg *msg)
  {
int ret = 0;
  
+	if (asid != 0)

+   return -EINVAL;
+
mutex_lock(&dev->mutex);
vhost_dev_lock_vqs(dev);
switch (msg->type) {
@@ -1135,6 +1138,7 @@ ssize_t vhost_chr_write_iter(struct vhost_dev *dev,
struct vhost_iotlb_msg msg;
size_t offset;
int type, ret;
+   u16 asid = 0;

You assume asid occupies just 16 bits. So maybe you should reserve the
other 16 bits for future extension:

struct vhost_msg_v2 {
 __u32 type;
-   __u32 reserved;
+   __u16 asid;
+   __u16 reserved;
 union {

Moreover, maybe this should be reflected in previous patches that use
the asid:

-static int mlx5_vdpa_set_map(struct vdpa_device *vdev, struct vhost_iotlb 
*iotlb)
+static int mlx5_vdpa_set_map(struct vdpa_device *vdev, u16 asid,
+struct vhost_iotlb *iotlb)

-static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev,
+static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev, u16 asid,
 struct vhost_iotlb_msg *msg)

etc.



Good catch.

This is a bug of the code actually. Since I want to stick to 32bit to be 
large enough for e.g PASID.


Will fix.

Thanks








Registering IRQ for MT7530 internal PHYs

2020-12-29 Thread DENG Qingfang
Hi,

I added MT7530 IRQ support and registered its internal PHYs to IRQ.
It works but my patch used two hacks.

1. Removed phy_drv_supports_irq check, because config_intr and
handle_interrupt are not set for Generic PHY.

2. Allocated ds->slave_mii_bus before calling ds->ops->setup, because
we cannot call dsa_slave_mii_bus_init which is private.

Any better ideas?

Regards,
Qingfang

diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index a67cac15a724..d59a8c50ede3 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1639,6 +1640,125 @@ mtk_get_tag_protocol(struct dsa_switch *ds, int port,
}
 }
 
+static irqreturn_t
+mt7530_irq(int irq, void *data)
+{
+   struct mt7530_priv *priv = data;
+   bool handled = false;
+   int phy;
+   u32 val;
+
+   val = mt7530_read(priv, MT7530_SYS_INT_STS);
+   mt7530_write(priv, MT7530_SYS_INT_STS, val);
+
+   dev_info_ratelimited(priv->dev, "interrupt status: 0x%08x\n", val);
+   dev_info_ratelimited(priv->dev, "interrupt enable: 0x%08x\n", 
mt7530_read(priv, MT7530_SYS_INT_EN));
+
+   for (phy = 0; phy < MT7530_NUM_PHYS; phy++) {
+   if (val & BIT(phy)) {
+   unsigned int child_irq;
+
+   child_irq = irq_find_mapping(priv->irq_domain, phy);
+   handle_nested_irq(child_irq);
+   handled = true;
+   }
+   }
+
+   return handled ? IRQ_HANDLED : IRQ_NONE;
+}
+
+static void mt7530_irq_mask(struct irq_data *d)
+{
+   struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
+
+   priv->irq_enable &= ~BIT(d->hwirq);
+}
+
+static void mt7530_irq_unmask(struct irq_data *d)
+{
+   struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
+
+   priv->irq_enable |= BIT(d->hwirq);
+}
+
+static void mt7530_irq_bus_lock(struct irq_data *d)
+{
+   struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
+
+   mutex_lock(&priv->reg_mutex);
+}
+
+static void mt7530_irq_bus_sync_unlock(struct irq_data *d)
+{
+   struct mt7530_priv *priv = irq_data_get_irq_chip_data(d);
+
+   mt7530_write(priv, MT7530_SYS_INT_EN, priv->irq_enable);
+   mutex_unlock(&priv->reg_mutex);
+}
+
+static struct irq_chip mt7530_irq_chip = {
+   .name = MT7530_NAME,
+   .irq_mask = mt7530_irq_mask,
+   .irq_unmask = mt7530_irq_unmask,
+   .irq_bus_lock = mt7530_irq_bus_lock,
+   .irq_bus_sync_unlock = mt7530_irq_bus_sync_unlock,
+};
+
+static int
+mt7530_irq_map(struct irq_domain *domain, unsigned int irq,
+  irq_hw_number_t hwirq)
+{
+   irq_set_chip_data(irq, domain->host_data);
+   irq_set_chip_and_handler(irq, &mt7530_irq_chip, handle_simple_irq);
+   irq_set_noprobe(irq);
+
+   return 0;
+}
+
+static const struct irq_domain_ops mt7530_irq_domain_ops = {
+   .map = mt7530_irq_map,
+   .xlate = irq_domain_xlate_onecell,
+};
+
+static void
+mt7530_irq_init(struct mt7530_priv *priv)
+{
+   struct mii_bus *bus = priv->ds->slave_mii_bus;
+   struct device *dev = priv->dev;
+   struct device_node *np = dev->of_node;
+   int parent_irq;
+   int phy, ret;
+
+   parent_irq = of_irq_get(np, 0);
+   if (parent_irq <= 0) {
+   dev_err(dev, "failed to get parent IRQ: %d\n", parent_irq);
+   return;
+   }
+
+   mt7530_set(priv, MT7530_TOP_SIG_CTRL, TOP_SIG_CTRL_NORMAL);
+   ret = devm_request_threaded_irq(dev, parent_irq, NULL, mt7530_irq,
+   IRQF_ONESHOT, MT7530_NAME, priv);
+   if (ret) {
+   dev_err(dev, "failed to request IRQ: %d\n", ret);
+   return;
+   }
+
+   priv->irq_domain = irq_domain_add_linear(np, MT7530_NUM_PHYS,
+   &mt7530_irq_domain_ops, priv);
+   if (!priv->irq_domain) {
+   dev_err(dev, "failed to create IRQ domain\n");
+   return;
+   }
+
+   /* IRQ for internal PHYs */
+   for (phy = 0; phy < MT7530_NUM_PHYS; phy++) {
+   unsigned int irq = irq_create_mapping(priv->irq_domain, phy);
+
+   irq_set_parent(irq, parent_irq);
+   bus->irq[phy] = irq;
+   }
+}
+
 static int
 mt7530_setup(struct dsa_switch *ds)
 {
@@ -2578,8 +2698,13 @@ static int
 mt753x_setup(struct dsa_switch *ds)
 {
struct mt7530_priv *priv = ds->priv;
+   int ret =  priv->info->sw_setup(ds);
 
-   return priv->info->sw_setup(ds);
+   /* Setup interrupt */
+   if (!ret)
+   mt7530_irq_init(priv);
+
+   return ret;
 }
 
 static int
@@ -2780,6 +2905,9 @@ mt7530_remove(struct mdio_device *mdiodev)
dev_err(priv->dev, "Failed to disable io pwr: %d\n",
ret);
 
+   if (priv->irq_domain)
+   irq_domain_remove(priv->irq_domain);

[PATCH] checkpatch: ignore warning designated initializers using NR_CPUS

2020-12-29 Thread Peng Wang
Some max_length wants to hold as large room as possible to
ensure enough size to tackle with the biggest NR_CPUS. As
an example below:

kernel/cgroup/cpuset.c:
static struct cftype legacy_files[] = {
{
.name = "cpus",
.seq_show = cpuset_common_seq_show,
.write = cpuset_write_resmask,
.max_write_len = (100U + 6 * NR_CPUS),
.private = FILE_CPULIST,
},
...
}

Signed-off-by: Peng Wang 
---
 scripts/checkpatch.pl | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0008530..da8fc48 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7022,12 +7022,15 @@ sub process {
 
 # use of NR_CPUS is usually wrong
 # ignore definitions of NR_CPUS and usage to define arrays as likely right
+# ignore designated initializers using NR_CPUS
+
if ($line =~ /\bNR_CPUS\b/ &&
$line !~ /^.\s*\s*#\s*if\b.*\bNR_CPUS\b/ &&
$line !~ /^.\s*\s*#\s*define\b.*\bNR_CPUS\b/ &&
$line !~ /^.\s*$Declare\s.*\[[^\]]*NR_CPUS[^\]]*\]/ &&
$line !~ /\[[^\]]*\.\.\.[^\]]*NR_CPUS[^\]]*\]/ &&
-   $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/)
+   $line !~ /\[[^\]]*NR_CPUS[^\]]*\.\.\.[^\]]*\]/ &&
+   $line !~ /\s*\..*=.*\bNR_CPUS\b.*,$/)
{
WARN("NR_CPUS",
 "usage of NR_CPUS is often wrong - consider using 
cpu_possible(), num_possible_cpus(), for_each_possible_cpu(), etc\n" . 
$herecurr);
-- 
2.9.5



Re: [PATCH 07/21] vdpa: multiple address spaces support

2020-12-29 Thread Jason Wang



On 2020/12/29 下午3:28, Eli Cohen wrote:

@@ -43,6 +43,8 @@ struct vdpa_vq_state {
   * @index: device index
   * @features_valid: were features initialized? for legacy guests
   * @nvqs: the number of virtqueues
+ * @ngroups: the number of virtqueue groups
+ * @nas: the number of address spaces

I am not sure these can be categorised as part of the state of the VQ.
It's more of a property so maybe we can have a callback to get the
properties of the VQ?



Or maybe there's a misunderstanding of the patch.

Those two attributes belongs to vdpa_device instead of vdpa_vq_state 
actually.


Thanks



Re: [PATCH 07/21] vdpa: multiple address spaces support

2020-12-29 Thread Jason Wang



On 2020/12/29 下午3:28, Eli Cohen wrote:

@@ -43,6 +43,8 @@ struct vdpa_vq_state {
   * @index: device index
   * @features_valid: were features initialized? for legacy guests
   * @nvqs: the number of virtqueues
+ * @ngroups: the number of virtqueue groups
+ * @nas: the number of address spaces

I am not sure these can be categorised as part of the state of the VQ.
It's more of a property so maybe we can have a callback to get the
properties of the VQ?

Moreover, I think they should be handled in the hardware drivers to
return 1 for both ngroups and nas.



We can, but those are static attributes that is not expected to be 
changed by the driver.


Introduce callbacks for those static stuffs does not give us any advantage.

For group id and notification area, since we don't have a abstract of 
vdpa_virtqueue. The only choice is to introduce callbacks for them.


Maybe it's time to introduce vdpa_virtqueue.

Thanks



WARNING in cm109_urb_irq_callback/usb_submit_urb

2020-12-29 Thread syzbot
Hello,

syzbot found the following issue on:

HEAD commit:5814bc2d Merge tag 'perf-tools-2020-12-24' of git://git.ke..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12f074db50
kernel config:  https://syzkaller.appspot.com/x/.config?x=bf519e1e96191576
dashboard link: https://syzkaller.appspot.com/bug?extid=2d6d691af5ab4b7e66df
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2d6d691af5ab4b7e6...@syzkaller.appspotmail.com

cm109 2-1:0.0: cm109_urb_irq_callback: urb status -71
[ cut here ]
URB 96f203b6 submitted while active
WARNING: CPU: 0 PID: 18262 at drivers/usb/core/urb.c:378 
usb_submit_urb+0x128e/0x1560 drivers/usb/core/urb.c:378
Modules linked in:
CPU: 0 PID: 18262 Comm: syz-executor.5 Not tainted 5.10.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:usb_submit_urb+0x128e/0x1560 drivers/usb/core/urb.c:378
Code: 89 de e8 55 99 31 fc 84 db 0f 85 74 f4 ff ff e8 68 91 31 fc 4c 89 fe 48 
c7 c7 a0 c6 02 8a c6 05 4b 89 28 08 01 e8 f6 1c 89 03 <0f> 0b e9 52 f4 ff ff c7 
44 24 14 01 00 00 00 e9 09 f5 ff ff 41 be
RSP: 0018:c90079e8 EFLAGS: 00010082
RAX:  RBX:  RCX: 
RDX: 0004 RSI: 815b94d5 RDI: f5200f2f
RBP: 88802517c4c0 R08:  R09: 
R10: 815b792b R11:  R12: 0012
R13: 88801e060058 R14: fff0 R15: 88801f2b6500
FS:  () GS:8880b9c0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 001b2f62d000 CR3: 2aba6000 CR4: 001526f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 
 cm109_urb_irq_callback+0x44f/0xaa0 drivers/input/misc/cm109.c:422
 __usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1657
 usb_hcd_giveback_urb+0x38c/0x430 drivers/usb/core/hcd.c:1728
 dummy_timer+0x11f4/0x32a0 drivers/usb/gadget/udc/dummy_hcd.c:1971
 call_timer_fn+0x1a5/0x710 kernel/time/timer.c:1417
 expire_timers kernel/time/timer.c:1462 [inline]
 __run_timers.part.0+0x692/0xa80 kernel/time/timer.c:1731
 __run_timers kernel/time/timer.c:1712 [inline]
 run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1744
 __do_softirq+0x2bc/0xa77 kernel/softirq.c:343
 asm_call_irq_on_stack+0xf/0x20
 
 __run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
 run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
 do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77
 invoke_softirq kernel/softirq.c:226 [inline]
 __irq_exit_rcu+0x17f/0x200 kernel/softirq.c:420
 irq_exit_rcu+0x5/0x20 kernel/softirq.c:432
 sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1096
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:628
RIP: 0010:check_kcov_mode+0x2c/0x40 kernel/kcov.c:174
Code: 05 09 a8 8e 7e 89 c2 81 e2 00 01 00 00 a9 00 01 ff 00 74 10 31 c0 85 d2 
74 15 8b 96 cc 14 00 00 85 d2 74 0b 8b 86 a8 14 00 00 <39> f8 0f 94 c0 c3 0f 1f 
40 00 66 2e 0f 1f 84 00 00 00 00 00 31 c0
RSP: 0018:c90014ebf628 EFLAGS: 0246
RAX:  RBX: 01fe RCX: 00aa
RDX:  RSI: 888066450280 RDI: 0003
RBP: ea4ca500 R08: 01fe R09: 004ca500
R10: 819a63e0 R11:  R12: 
R13: 88802d906560 R14: 00aa R15: dc00
 write_comp_data kernel/kcov.c:218 [inline]
 __sanitizer_cov_trace_cmp4+0x1c/0x70 kernel/kcov.c:258
 release_pages+0x6f0/0x1d60 mm/swap.c:864
 tlb_batch_pages_flush mm/mmu_gather.c:49 [inline]
 tlb_flush_mmu_free mm/mmu_gather.c:242 [inline]
 tlb_flush_mmu+0xe9/0x6b0 mm/mmu_gather.c:249
 zap_pte_range mm/memory.c:1330 [inline]
 zap_pmd_range mm/memory.c:1368 [inline]
 zap_pud_range mm/memory.c:1397 [inline]
 zap_p4d_range mm/memory.c:1418 [inline]
 unmap_page_range+0x1a75/0x2640 mm/memory.c:1439
 unmap_single_vma+0x198/0x300 mm/memory.c:1484
 unmap_vmas+0x168/0x2e0 mm/memory.c:1516
 exit_mmap+0x2b1/0x5a0 mm/mmap.c:3220
 __mmput+0x122/0x470 kernel/fork.c:1083
 mmput+0x53/0x60 kernel/fork.c:1104
 exit_mm kernel/exit.c:500 [inline]
 do_exit+0xa97/0x2a00 kernel/exit.c:810
 do_group_exit+0x125/0x310 kernel/exit.c:920
 get_signal+0x3e9/0x2160 kernel/signal.c:2770
 arch_do_signal_or_restart+0x2a8/0x1eb0 arch/x86/kernel/signal.c:811
 handle_signal_work kernel/entry/common.c:147 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:171 [inline]
 exit_to_user_mode_prepare+0x124/0x200 kernel/entry/common.c:201
 __syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
 syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.

[PATCH v3] MIPS: zboot: head.S clean up

2020-12-29 Thread Jiaxun Yang
.cprestore is removed as we don't expect Position Independent
zboot ELF.

.noreorder is also removed and rest instructions are massaged
to improve readability.

t9 register is used for indirect jump as MIPS ABI requirement.

start label is removed as it already defined in LEAF.

Reported-by: Paul Cercueil 
Signed-off-by: Jiaxun Yang 

--
v2: Remove start label (paul)
---
 arch/mips/boot/compressed/head.S | 18 +++---
 1 file changed, 7 insertions(+), 11 deletions(-)

diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S
index 409cb483a9ff..070b2fbabae4 100644
--- a/arch/mips/boot/compressed/head.S
+++ b/arch/mips/boot/compressed/head.S
@@ -15,10 +15,7 @@
 #include 
 #include 
 
-   .set noreorder
-   .cprestore
LEAF(start)
-start:
/* Save boot rom start args */
moves0, a0
moves1, a1
@@ -35,21 +32,20 @@ start:
PTR_LA  a0, (.heap)  /* heap address */
PTR_LA  sp, (.stack + 8192)  /* stack address */
 
-   PTR_LA  ra, 2f
-   PTR_LA  k0, decompress_kernel
-   jr  k0
-nop
+   PTR_LA  t9, decompress_kernel
+   jalrt9
+
 2:
movea0, s0
movea1, s1
movea2, s2
movea3, s3
-   PTR_LI  k0, KERNEL_ENTRY
-   jr  k0
-nop
+   PTR_LI  t9, KERNEL_ENTRY
+   jalrt9
+
 3:
b   3b
-nop
+
END(start)
 
.comm .heap,BOOT_HEAP_SIZE,4
-- 
2.30.0



Re: [PATCH v2] MIPS: zboot: head.S clean up

2020-12-29 Thread Jiaxun Yang

在 2020/12/30 上午11:08, Jiaxun Yang 写道:

.cprestore is removed as we don't expect Position Independent
zboot ELF.

.noreorder is also removed and rest instructions are massaged
to improve readability.

t9 register is used for indirect jump as MIPS ABI requirement.

start label is removed as it already defined in LEAF.

Reported-by: Paul Cercueil 
Signed-off-by: Jiaxun Yang 

--
v2: Remove start label (paul)
---
  arch/mips/boot/compressed/head.S | 17 +++--
  1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S
index 409cb483a9ff..977218c90bc8 100644
--- a/arch/mips/boot/compressed/head.S
+++ b/arch/mips/boot/compressed/head.S
@@ -15,8 +15,6 @@
  #include 
  #include 
  
-	.set noreorder

-   .cprestore
LEAF(start)
  start:


Oops, it's still here, sorry for the noise.

Thanks

- Jiaxun


/* Save boot rom start args */
@@ -35,21 +33,20 @@ start:
PTR_LA  a0, (.heap)  /* heap address */
PTR_LA  sp, (.stack + 8192)  /* stack address */
  
-	PTR_LA	ra, 2f

-   PTR_LA  k0, decompress_kernel
-   jr  k0
-nop
+   PTR_LA  t9, decompress_kernel
+   jalrt9
+
  2:
movea0, s0
movea1, s1
movea2, s2
movea3, s3
-   PTR_LI  k0, KERNEL_ENTRY
-   jr  k0
-nop
+   PTR_LI  t9, KERNEL_ENTRY
+   jalrt9
+
  3:
b   3b
-nop
+
END(start)
  
  	.comm .heap,BOOT_HEAP_SIZE,4




[PATCH] Use IS_ERR instead of IS_ERR_OR_NULL and set inode null when IS_ERR.

2020-12-29 Thread Yi Li
1: ext4_iget/ext4_find_extent never returns NULL, use IS_ERR
instead of IS_ERR_OR_NULL to fix this.

2: ext4_fc_replay_inode should set the inode to NULL when IS_ERR.
and go to call iput properly.

Signed-off-by: Yi Li 
---
 fs/ext4/fast_commit.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
index 4fcc21c25e79..6b5489273c85 100644
--- a/fs/ext4/fast_commit.c
+++ b/fs/ext4/fast_commit.c
@@ -1318,14 +1318,14 @@ static int ext4_fc_replay_unlink(struct super_block 
*sb, struct ext4_fc_tl *tl)
entry.len = darg.dname_len;
inode = ext4_iget(sb, darg.ino, EXT4_IGET_NORMAL);
 
-   if (IS_ERR_OR_NULL(inode)) {
+   if (IS_ERR(inode)) {
jbd_debug(1, "Inode %d not found", darg.ino);
return 0;
}
 
old_parent = ext4_iget(sb, darg.parent_ino,
EXT4_IGET_NORMAL);
-   if (IS_ERR_OR_NULL(old_parent)) {
+   if (IS_ERR(old_parent)) {
jbd_debug(1, "Dir with inode  %d not found", darg.parent_ino);
iput(inode);
return 0;
@@ -1410,7 +1410,7 @@ static int ext4_fc_replay_link(struct super_block *sb, 
struct ext4_fc_tl *tl)
darg.parent_ino, darg.dname_len);
 
inode = ext4_iget(sb, darg.ino, EXT4_IGET_NORMAL);
-   if (IS_ERR_OR_NULL(inode)) {
+   if (IS_ERR(inode)) {
jbd_debug(1, "Inode not found.");
return 0;
}
@@ -1466,10 +1466,11 @@ static int ext4_fc_replay_inode(struct super_block *sb, 
struct ext4_fc_tl *tl)
trace_ext4_fc_replay(sb, tag, ino, 0, 0);
 
inode = ext4_iget(sb, ino, EXT4_IGET_NORMAL);
-   if (!IS_ERR_OR_NULL(inode)) {
+   if (!IS_ERR(inode)) {
ext4_ext_clear_bb(inode);
iput(inode);
}
+   inode = NULL;
 
ext4_fc_record_modified_inode(sb, ino);
 
@@ -1512,7 +1513,7 @@ static int ext4_fc_replay_inode(struct super_block *sb, 
struct ext4_fc_tl *tl)
 
/* Given that we just wrote the inode on disk, this SHOULD succeed. */
inode = ext4_iget(sb, ino, EXT4_IGET_NORMAL);
-   if (IS_ERR_OR_NULL(inode)) {
+   if (IS_ERR(inode)) {
jbd_debug(1, "Inode not found.");
return -EFSCORRUPTED;
}
@@ -1564,7 +1565,7 @@ static int ext4_fc_replay_create(struct super_block *sb, 
struct ext4_fc_tl *tl)
goto out;
 
inode = ext4_iget(sb, darg.ino, EXT4_IGET_NORMAL);
-   if (IS_ERR_OR_NULL(inode)) {
+   if (IS_ERR(inode)) {
jbd_debug(1, "inode %d not found.", darg.ino);
inode = NULL;
ret = -EINVAL;
@@ -1577,7 +1578,7 @@ static int ext4_fc_replay_create(struct super_block *sb, 
struct ext4_fc_tl *tl)
 * dot and dot dot dirents are setup properly.
 */
dir = ext4_iget(sb, darg.parent_ino, EXT4_IGET_NORMAL);
-   if (IS_ERR_OR_NULL(dir)) {
+   if (IS_ERR(dir)) {
jbd_debug(1, "Dir %d not found.", darg.ino);
goto out;
}
@@ -1653,7 +1654,7 @@ static int ext4_fc_replay_add_range(struct super_block 
*sb,
 
inode = ext4_iget(sb, le32_to_cpu(fc_add_ex->fc_ino),
EXT4_IGET_NORMAL);
-   if (IS_ERR_OR_NULL(inode)) {
+   if (IS_ERR(inode)) {
jbd_debug(1, "Inode not found.");
return 0;
}
@@ -1777,7 +1778,7 @@ ext4_fc_replay_del_range(struct super_block *sb, struct 
ext4_fc_tl *tl)
le32_to_cpu(lrange->fc_ino), cur, remaining);
 
inode = ext4_iget(sb, le32_to_cpu(lrange->fc_ino), EXT4_IGET_NORMAL);
-   if (IS_ERR_OR_NULL(inode)) {
+   if (IS_ERR(inode)) {
jbd_debug(1, "Inode %d not found", le32_to_cpu(lrange->fc_ino));
return 0;
}
@@ -1832,7 +1833,7 @@ static void ext4_fc_set_bitmaps_and_counters(struct 
super_block *sb)
for (i = 0; i < state->fc_modified_inodes_used; i++) {
inode = ext4_iget(sb, state->fc_modified_inodes[i],
EXT4_IGET_NORMAL);
-   if (IS_ERR_OR_NULL(inode)) {
+   if (IS_ERR(inode)) {
jbd_debug(1, "Inode %d not found.",
state->fc_modified_inodes[i]);
continue;
@@ -1849,7 +1850,7 @@ static void ext4_fc_set_bitmaps_and_counters(struct 
super_block *sb)
 
if (ret > 0) {
path = ext4_find_extent(inode, map.m_lblk, 
NULL, 0);
-   if (!IS_ERR_OR_NULL(path)) {
+   if (!IS_ERR(path)) {
for (j = 0; j < path->p_depth; j++)
ext4_mb_mark_bb(inode->i_sb,
   

[PATCH 2/2] MIPS: Loongson64: Set cluster for cores

2020-12-29 Thread Jiaxun Yang
cluster is required for cacheinfo to set shared_cpu_map correctly.

Signed-off-by: Jiaxun Yang 
Reviewed-by: Tiezhu Yang 
Tested-by: Tiezhu Yang 
---
 arch/mips/loongson64/smp.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c
index e744e1bee49e..fae3a97d853c 100644
--- a/arch/mips/loongson64/smp.c
+++ b/arch/mips/loongson64/smp.c
@@ -403,6 +403,8 @@ static void __init loongson3_smp_setup(void)
__cpu_number_map[i] = num;
__cpu_logical_map[num] = i;
set_cpu_possible(num, true);
+   /* Loongson processors are always grouped by 4 */
+   cpu_set_cluster(&cpu_data[num], i / 4);
num++;
}
i++;
-- 
2.30.0



[PATCH RESEND 1/2] MIPS: cacheinfo: Add missing VCache

2020-12-29 Thread Jiaxun Yang
Victim Cache is defined by Loongson as per-core unified
private Cache.
Add this into cacheinfo and make cache levels selfincrement
instead of hardcode levels.

Signed-off-by: Jiaxun Yang 
Reviewed-by: Tiezhu Yang 
Tested-by: Tiezhu Yang 
---
 arch/mips/kernel/cacheinfo.c | 34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)

diff --git a/arch/mips/kernel/cacheinfo.c b/arch/mips/kernel/cacheinfo.c
index 47312c529410..83548331ee94 100644
--- a/arch/mips/kernel/cacheinfo.c
+++ b/arch/mips/kernel/cacheinfo.c
@@ -35,6 +35,11 @@ static int __init_cache_level(unsigned int cpu)
 
leaves += (c->icache.waysize) ? 2 : 1;
 
+   if (c->vcache.waysize) {
+   levels++;
+   leaves++;
+   }
+
if (c->scache.waysize) {
levels++;
leaves++;
@@ -74,25 +79,38 @@ static int __populate_cache_leaves(unsigned int cpu)
struct cpuinfo_mips *c = ¤t_cpu_data;
struct cpu_cacheinfo *this_cpu_ci = get_cpu_cacheinfo(cpu);
struct cacheinfo *this_leaf = this_cpu_ci->info_list;
+   int level = 1;
 
if (c->icache.waysize) {
-   /* L1 caches are per core */
+   /* D/I caches are per core */
fill_cpumask_siblings(cpu, &this_leaf->shared_cpu_map);
-   populate_cache(dcache, this_leaf, 1, CACHE_TYPE_DATA);
+   populate_cache(dcache, this_leaf, level, CACHE_TYPE_DATA);
fill_cpumask_siblings(cpu, &this_leaf->shared_cpu_map);
-   populate_cache(icache, this_leaf, 1, CACHE_TYPE_INST);
+   populate_cache(icache, this_leaf, level, CACHE_TYPE_INST);
+   level++;
} else {
-   populate_cache(dcache, this_leaf, 1, CACHE_TYPE_UNIFIED);
+   populate_cache(dcache, this_leaf, level, CACHE_TYPE_UNIFIED);
+   level++;
+   }
+
+   if (c->vcache.waysize) {
+   /* Vcache is per core as well */
+   fill_cpumask_siblings(cpu, &this_leaf->shared_cpu_map);
+   populate_cache(vcache, this_leaf, level, CACHE_TYPE_UNIFIED);
+   level++;
}
 
if (c->scache.waysize) {
-   /* L2 cache is per cluster */
+   /* Scache is per cluster */
fill_cpumask_cluster(cpu, &this_leaf->shared_cpu_map);
-   populate_cache(scache, this_leaf, 2, CACHE_TYPE_UNIFIED);
+   populate_cache(scache, this_leaf, level, CACHE_TYPE_UNIFIED);
+   level++;
}
 
-   if (c->tcache.waysize)
-   populate_cache(tcache, this_leaf, 3, CACHE_TYPE_UNIFIED);
+   if (c->tcache.waysize) {
+   populate_cache(tcache, this_leaf, level, CACHE_TYPE_UNIFIED);
+   level++;
+   }
 
this_cpu_ci->cpu_map_populated = true;
 
-- 
2.30.0



Re: [PATCH v2 -next] staging: greybus: light: Use kzalloc for allocating only one thing

2020-12-29 Thread Alex Elder

On 12/29/20 7:37 PM, Zheng Yongjun wrote:

Use kzalloc rather than kcalloc(1,...)

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
@@

- kcalloc(1,
+ kzalloc(
   ...)
// 

Signed-off-by: Zheng Yongjun 


Looks good.

Reviewed-by: Alex Elder 


---
  drivers/staging/greybus/light.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
index d2672b65c3f4..87d36948c610 100644
--- a/drivers/staging/greybus/light.c
+++ b/drivers/staging/greybus/light.c
@@ -290,8 +290,7 @@ static int channel_attr_groups_set(struct gb_channel 
*channel,
channel->attrs = kcalloc(size + 1, sizeof(*channel->attrs), GFP_KERNEL);
if (!channel->attrs)
return -ENOMEM;
-   channel->attr_group = kcalloc(1, sizeof(*channel->attr_group),
- GFP_KERNEL);
+   channel->attr_group = kzalloc(sizeof(*channel->attr_group), GFP_KERNEL);
if (!channel->attr_group)
return -ENOMEM;
channel->attr_groups = kcalloc(2, sizeof(*channel->attr_groups),





Re: [PATCH] ARM: dts: sun8i-v3s: Add CSI0 MCLK pin definition

2020-12-29 Thread Chen-Yu Tsai
On Tue, Dec 22, 2020 at 4:17 PM Jernej Škrabec  wrote:
>
> Hi!
>
> Dne petek, 18. december 2020 ob 20:50:33 CET je Paul Kocialkowski napisal(a):
> > This adds a device-tree definition for the CSI0 MCLK pin,
> > which can be used for feeding MIPI CSI-2 sensors.
> >
> > Signed-off-by: Paul Kocialkowski 
>
> Is this used anywhere? Current policy is to add pin definitions only if any
> user exists.

IIRC we sort of loosened that requirement with the use of /omit-if-no-ref/.
The A20 dtsi file has a whole bunch of pins defined that are not directly
used but are available for users to reference, especially in overlays.
The "-@" parameter for the device tree compiler, used to build overlay
compatible DTBs, makes the compiler ignore /omit-if-no-ref/ and include
all the nodes.

ChenYu

> Best regards,
> Jernej
>
> > ---
> >  arch/arm/boot/dts/sun8i-v3s.dtsi | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > b/arch/arm/boot/dts/sun8i-v3s.dtsi index a9f5795d4e57..bff822b9fa01 100644
> > --- a/arch/arm/boot/dts/sun8i-v3s.dtsi
> > +++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
> > @@ -337,6 +337,12 @@ pio: pinctrl@1c20800 {
> >   interrupt-controller;
> >   #interrupt-cells = <3>;
> >
> > + /omit-if-no-ref/
> > + csi0_mclk_pin: csi0-mclk-pin {
> > + pins = "PE20";
> > + function = "csi_mipi";
> > + };
> > +
> >   /omit-if-no-ref/
> >   csi1_8bit_pins: csi1-8bit-pins {
> >   pins = "PE0", "PE2", "PE3",
> "PE8", "PE9",
>
>
>
>


[PATCH 1/3] MIPS: Add vulnerabilities infrastructure

2020-12-29 Thread Jiaxun Yang
Add infrastructure to display CPU vulnerabilities.
As most MIPS CPU vendors are dead today and we can't confirm
vulnerabilities states with them, we'll display vulnerabilities
as "Unknown" by default and override them in cpu-probe.c

Signed-off-by: Jiaxun Yang 
---
 arch/mips/Kconfig|  1 +
 arch/mips/include/asm/cpu-info.h |  5 
 arch/mips/include/asm/cpu.h  |  7 +
 arch/mips/kernel/Makefile|  2 +-
 arch/mips/kernel/vulnbl.c| 46 
 5 files changed, 60 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/kernel/vulnbl.c

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index ef5b2a177b1b..524053b8f769 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -24,6 +24,7 @@ config MIPS
select GENERIC_CLOCKEVENTS
select GENERIC_CMOS_UPDATE
select GENERIC_CPU_AUTOPROBE
+   select GENERIC_CPU_VULNERABILITIES
select GENERIC_GETTIMEOFDAY
select GENERIC_IOMAP
select GENERIC_IRQ_PROBE
diff --git a/arch/mips/include/asm/cpu-info.h b/arch/mips/include/asm/cpu-info.h
index a600670d00e9..1a964dbfc0a8 100644
--- a/arch/mips/include/asm/cpu-info.h
+++ b/arch/mips/include/asm/cpu-info.h
@@ -106,6 +106,11 @@ struct cpuinfo_mips {
unsigned intguestid_mask;
unsigned intguestid_cache;
 
+   /* Vulnerabilities */
+   unsigned intvulnerabilities; /* Vulnerabilities states that 
we known */
+   unsigned intvulnerable; /* Vulnerabilities affated */
+   unsigned intmitigations; /* Mitigations */
+
 #ifdef CONFIG_CPU_LOONGSON3_CPUCFG_EMULATION
/* CPUCFG data for this CPU, synthesized at probe time.
 *
diff --git a/arch/mips/include/asm/cpu.h b/arch/mips/include/asm/cpu.h
index f5b04e8f6061..3414c9f5464e 100644
--- a/arch/mips/include/asm/cpu.h
+++ b/arch/mips/include/asm/cpu.h
@@ -447,4 +447,11 @@ enum cpu_type_enum {
 #define MIPS_ASE_LOONGSON_EXT  0x2000 /* Loongson EXTensions */
 #define MIPS_ASE_LOONGSON_EXT2 0x4000 /* Loongson EXTensions R2 */
 
+/*
+ * CPU security vulnerabilities
+ */
+#define MIPS_VULNBL_MELTDOWN   BIT(0)
+#define MIPS_VULNBL_SPECTRE_V1 BIT(1)
+#define MIPS_VULNBL_SPECTRE_V2 BIT(2)
+
 #endif /* _ASM_CPU_H */
diff --git a/arch/mips/kernel/Makefile b/arch/mips/kernel/Makefile
index 13a26d254829..39abc8ead5e0 100644
--- a/arch/mips/kernel/Makefile
+++ b/arch/mips/kernel/Makefile
@@ -8,7 +8,7 @@ extra-y := head.o vmlinux.lds
 obj-y  += cmpxchg.o cpu-probe.o branch.o elf.o entry.o genex.o idle.o 
irq.o \
   process.o prom.o ptrace.o reset.o setup.o signal.o \
   syscall.o time.o topology.o traps.o unaligned.o watch.o \
-  vdso.o cacheinfo.o
+  vdso.o cacheinfo.o vulnbl.o
 
 ifdef CONFIG_FUNCTION_TRACER
 CFLAGS_REMOVE_ftrace.o = -pg
diff --git a/arch/mips/kernel/vulnbl.c b/arch/mips/kernel/vulnbl.c
new file mode 100644
index ..fc73da6214fe
--- /dev/null
+++ b/arch/mips/kernel/vulnbl.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *  Copyright (C) 2020, Jiaxun Yang 
+ *  MIPS CPU vulnerabilities
+ */
+
+#include 
+
+#include 
+#include 
+
+ssize_t cpu_show_meltdown(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+   if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_MELTDOWN))
+   return sprintf(buf, "Unknown\n");
+
+   if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_MELTDOWN))
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Affected\n");
+}
+
+ssize_t cpu_show_spectre_v1(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V1))
+   return sprintf(buf, "Unknown\n");
+
+   if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V1))
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Affected\n");
+}
+
+ssize_t cpu_show_spectre_v2(struct device *dev,
+  struct device_attribute *attr, char *buf)
+{
+   if (!(boot_cpu_data.vulnerabilities & MIPS_VULNBL_SPECTRE_V2))
+   return sprintf(buf, "Unknown\n");
+
+   if (!(boot_cpu_data.vulnerable & MIPS_VULNBL_SPECTRE_V2))
+   return sprintf(buf, "Not affected\n");
+
+   return sprintf(buf, "Affected\n");
+}
-- 
2.30.0



[PATCH 3/3] MIPS: cpu-probe: Vulnerabilities for Loongson cores

2020-12-29 Thread Jiaxun Yang
Loongson64C is known to be vulnerable to meltdown according to
PoC from Rui Wang .

Loongson64G defended these side-channel attack by silicon.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/kernel/cpu-probe.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 2460783dbdb1..24b21f51353c 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -2092,6 +2092,8 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips 
*c, unsigned int cpu)
c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_CAM |
MIPS_ASE_LOONGSON_EXT | MIPS_ASE_LOONGSON_EXT2);
c->ases &= ~MIPS_ASE_VZ; /* VZ of Loongson-3A2000/3000 is 
incomplete */
+   c->vulnerabilities |= MIPS_VULNBL_MELTDOWN;
+   c->vulnerable |= MIPS_VULNBL_MELTDOWN;
break;
case PRID_IMP_LOONGSON_64G:
c->cputype = CPU_LOONGSON64;
@@ -2100,6 +2102,8 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips 
*c, unsigned int cpu)
set_isa(c, MIPS_CPU_ISA_M64R2);
decode_cpucfg(c);
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
+   c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
+ MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;
break;
default:
panic("Unknown Loongson Processor ID!");
-- 
2.30.0



[PATCH 2/3] MIPS: cpu-probe: Vulnerabilities for MIPS cores

2020-12-29 Thread Jiaxun Yang
Accorading to MIPS's announcement[1], only P5600 and P6600 is
affected by spectre v1 and v2, other cores are not affected.

So we mark vulnerabilities states for MIPS cores as known and
set P5600 and P6600 as vulnerable.

[1]: 
https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/

Signed-off-by: Jiaxun Yang 
---
 arch/mips/kernel/cpu-probe.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index 03adeed58efb..2460783dbdb1 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1688,6 +1688,9 @@ static inline void cpu_probe_legacy(struct cpuinfo_mips 
*c, unsigned int cpu)
 static inline void cpu_probe_mips(struct cpuinfo_mips *c, unsigned int cpu)
 {
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
+   c->vulnerabilities |= MIPS_VULNBL_MELTDOWN |
+ MIPS_VULNBL_SPECTRE_V1 | MIPS_VULNBL_SPECTRE_V2;
+
switch (c->processor_id & PRID_IMP_MASK) {
case PRID_IMP_QEMU_GENERIC:
c->writecombine = _CACHE_UNCACHED;
@@ -1794,10 +1797,12 @@ static inline void cpu_probe_mips(struct cpuinfo_mips 
*c, unsigned int cpu)
case PRID_IMP_P5600:
c->cputype = CPU_P5600;
__cpu_name[cpu] = "MIPS P5600";
+   c->vulnerable |= MIPS_VULNBL_SPECTRE_V1 | 
MIPS_VULNBL_SPECTRE_V2;
break;
case PRID_IMP_P6600:
c->cputype = CPU_P6600;
__cpu_name[cpu] = "MIPS P6600";
+   c->vulnerable |= MIPS_VULNBL_SPECTRE_V1 | 
MIPS_VULNBL_SPECTRE_V2;
break;
case PRID_IMP_I6400:
c->cputype = CPU_I6400;
-- 
2.30.0



[PATCH] tty: serial: amba-pl011: added RS485 support [v3]

2020-12-29 Thread Ivan Sistik
AMBA PL011 do not have hardware support for RS485. This implementation is
for drive enable signal (DE), which switch direction of RS485 driver chip.
This signal si drived by RTS pin. Correct multiplexor settings have to be
provided to Device Tree. Usually it is 'ctsrts', which is used for enabling
of HW flow control, too.

DE signal is switched by starting transmition from serial core and data
transfer is initiated by first hrtimer if there is delay before send
enabled.

There is missing FIFO empty interrupt in PL011. It is replaced by second
hrtimer which is started if there are no more data in port transmit buffer.
Notice that port transmit buffer is not the same as HW TX FIFO. Time of
this timmer is set to char send time and it is running until fifo is empty.
This kind of implementation cause that there can be unwanted delay of one
timer tick before DE signal is switched. This is used to prevent data loss
during transmit. Second timer can start first if there is delay after send
enabled.

Signed-off-by: Ivan Sistik 
---

Notes:
This patch is ported and corrected version of my previous patches which
can be reviewed here:
https://lore.kernel.org/lkml/20200106235203.27256-1-sis...@3ksolutions.sk/
and here:
https://lore.kernel.org/lkml/20201228164108.16508-1-sis...@3ksolutions.sk/

I have been waiting for some time to see if Lukas Wunner 
will create patch with his own solution.

Now I am successfully running my imeplementation for almost one year in
production environment. It is running 24/7 on Raspberry PI 4B which is
used as modbus master. There are no problems with it. I have made
corrections to patch according to notes from Greg Kroah-Hartman
 and Stefan Wahren .

 drivers/tty/serial/Kconfig  |  11 +
 drivers/tty/serial/amba-pl011.c | 463 +++-
 2 files changed, 471 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index a9751a83d..26dddab0c 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -75,6 +75,17 @@ config SERIAL_AMBA_PL011_CONSOLE
  your boot loader (lilo or loadlin) about how to pass options to the
  kernel at boot time.)
 
+config SERIAL_AMBA_PL011_SOFT_RS485
+   bool "RS485 software direction switching for ARM AMBA PL011 serial"
+   depends on SERIAL_AMBA_PL011=y
+   help
+ Enable RS485 software direction switching of driver enable (RTS pin)
+ for ARM AMBA PL011 serial. AMBA PL011 does not have HW support for
+ RS485. This driver use 2 hrtimers. One is used for rs485 delays.
+ Second one is used for polling of TX FIFO. There is not TX FIFO
+ empty interrupt in PL011. Secondary timer is started by empty
+ transmit buffer.
+
 config SERIAL_EARLYCON_ARM_SEMIHOST
bool "Early console using ARM semihosting"
depends on ARM64 || ARM
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 16720c97a..6a40e5bc5 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -46,6 +46,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "amba-pl011.h"
 
@@ -60,6 +61,18 @@
 #define UART_DR_ERROR  
(UART011_DR_OE|UART011_DR_BE|UART011_DR_PE|UART011_DR_FE)
 #define UART_DUMMY_DR_RX   (1 << 16)
 
+#ifdef CONFIG_SERIAL_AMBA_PL011_SOFT_RS485
+/*
+ * Enum with current status
+ */
+enum rs485_status {
+   rs485_receiving,
+   rs485_delay_before_send,
+   rs485_sending,
+   rs485_delay_after_send
+};
+#endif
+
 static u16 pl011_std_offsets[REG_ARRAY_SIZE] = {
[REG_DR] = UART01x_DR,
[REG_FR] = UART01x_FR,
@@ -270,6 +283,16 @@ struct uart_amba_port {
unsigned intold_cr; /* state during shutdown */
unsigned intfixed_baud; /* vendor-set fixed baud rate */
chartype[12];
+
+#ifdef CONFIG_SERIAL_AMBA_PL011_SOFT_RS485
+   enum rs485_status   rs485_current_status; /* status used for RTS */
+   enum rs485_status   rs485_next_status; /* this status after tick */
+   struct hrtimer  rs485_delay_timer;
+   struct hrtimer  rs485_tx_empty_poll_timer;
+   unsigned long   send_char_time; /* send char (nanoseconds) */
+   boolrs485_last_char_sending;
+#endif
+
 #ifdef CONFIG_DMA_ENGINE
/* DMA stuff */
boolusing_tx_dma;
@@ -306,6 +329,36 @@ static void pl011_write(unsigned int val, const struct 
uart_amba_port *uap,
writew_relaxed(val, addr);
 }
 
+#ifdef CONFIG_SERIAL_AMBA_PL011_SOFT_RS485
+
+static void pl011_rs485_start_rts_delay(struct uart_amba_port *uap);
+
+static void rs485_set_rts_signal(struct uart_amba_port *uap, bool value)
+{
+   unsigned int rts_temp_cr;
+
+   rts_temp_cr = pl011_read(uap, REG_CR);
+
+   if (!value)
+   rts_temp_cr |= UAR

[PATCH v2] MIPS: zboot: head.S clean up

2020-12-29 Thread Jiaxun Yang
.cprestore is removed as we don't expect Position Independent
zboot ELF.

.noreorder is also removed and rest instructions are massaged
to improve readability.

t9 register is used for indirect jump as MIPS ABI requirement.

start label is removed as it already defined in LEAF.

Reported-by: Paul Cercueil 
Signed-off-by: Jiaxun Yang 

--
v2: Remove start label (paul)
---
 arch/mips/boot/compressed/head.S | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/arch/mips/boot/compressed/head.S b/arch/mips/boot/compressed/head.S
index 409cb483a9ff..977218c90bc8 100644
--- a/arch/mips/boot/compressed/head.S
+++ b/arch/mips/boot/compressed/head.S
@@ -15,8 +15,6 @@
 #include 
 #include 
 
-   .set noreorder
-   .cprestore
LEAF(start)
 start:
/* Save boot rom start args */
@@ -35,21 +33,20 @@ start:
PTR_LA  a0, (.heap)  /* heap address */
PTR_LA  sp, (.stack + 8192)  /* stack address */
 
-   PTR_LA  ra, 2f
-   PTR_LA  k0, decompress_kernel
-   jr  k0
-nop
+   PTR_LA  t9, decompress_kernel
+   jalrt9
+
 2:
movea0, s0
movea1, s1
movea2, s2
movea3, s3
-   PTR_LI  k0, KERNEL_ENTRY
-   jr  k0
-nop
+   PTR_LI  t9, KERNEL_ENTRY
+   jalrt9
+
 3:
b   3b
-nop
+
END(start)
 
.comm .heap,BOOT_HEAP_SIZE,4
-- 
2.30.0



Re: [PATCH v4 1/2] fpga: dfl: add the userspace I/O device support for DFL devices

2020-12-29 Thread Xu Yilun
On Tue, Dec 29, 2020 at 06:37:37AM -0800, Tom Rix wrote:
> 
> On 12/28/20 6:42 PM, Xu Yilun wrote:
> > This patch supports the DFL drivers be written in userspace. This is
> > realized by exposing the userspace I/O device interfaces.
> >
> > The driver leverages the uio_pdrv_genirq, it adds the uio_pdrv_genirq
> > platform device with the DFL device's resources, and let the generic UIO
> > platform device driver provide support to userspace access to kernel
> > interrupts and memory locations.
> >
> > The driver now supports the ether group feature. To support a new DFL
> > feature been directly accessed via UIO, its feature id should be added to
> > the driver's id_table.
> >
> > Signed-off-by: Xu Yilun 
> > ---
> > v2: switch to the new matching algorithem. It matches DFL devices which
> >  could not be handled by other DFL drivers.
> > refacor the code about device resources filling.
> > fix some comments.
> > v3: split the dfl.c changes out of this patch.
> > some minor fixes
> > v4: drop the idea of a generic matching algorithem, instead we specify
> >  each matching device in id_table.
> > to make clear that only one irq is supported, the irq handling code
> >  is refactored.
> > ---
> >  drivers/fpga/Kconfig|  10 +
> >  drivers/fpga/Makefile   |   1 +
> >  drivers/fpga/dfl-uio-pdev.c | 101 
> > 
> >  3 files changed, 112 insertions(+)
> >  create mode 100644 drivers/fpga/dfl-uio-pdev.c
> >
> > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > index 5ff9438..61445be 100644
> > --- a/drivers/fpga/Kconfig
> > +++ b/drivers/fpga/Kconfig
> > @@ -203,6 +203,16 @@ config FPGA_DFL_NIOS_INTEL_PAC_N3000
> >   the card. It also instantiates the SPI master (spi-altera) for
> >   the card's BMC (Board Management Controller).
> >  
> > +config FPGA_DFL_UIO_PDEV
> > +   tristate "FPGA DFL Driver for Userspace I/O platform devices"
> > +   depends on FPGA_DFL && UIO_PDRV_GENIRQ
> > +   help
> > + Enable this to allow some DFL drivers be written in userspace. It
> > + adds the uio_pdrv_genirq platform device with the DFL feature's
> > + resources, and lets the generic UIO platform device driver provide
> > + support for userspace access to kernel interrupts and memory
> > + locations.
> > +
> >  config FPGA_DFL_PCI
> > tristate "FPGA DFL PCIe Device Driver"
> > depends on PCI && FPGA_DFL
> > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > index 18dc9885..8847fe0 100644
> > --- a/drivers/fpga/Makefile
> > +++ b/drivers/fpga/Makefile
> > @@ -45,6 +45,7 @@ dfl-afu-objs := dfl-afu-main.o dfl-afu-region.o 
> > dfl-afu-dma-region.o
> >  dfl-afu-objs += dfl-afu-error.o
> >  
> >  obj-$(CONFIG_FPGA_DFL_NIOS_INTEL_PAC_N3000)+= dfl-n3000-nios.o
> > +obj-$(CONFIG_FPGA_DFL_UIO_PDEV)+= dfl-uio-pdev.o
> >  
> >  # Drivers for FPGAs which implement DFL
> >  obj-$(CONFIG_FPGA_DFL_PCI) += dfl-pci.o
> > diff --git a/drivers/fpga/dfl-uio-pdev.c b/drivers/fpga/dfl-uio-pdev.c
> > new file mode 100644
> > index 000..1100434
> > --- /dev/null
> > +++ b/drivers/fpga/dfl-uio-pdev.c
> > @@ -0,0 +1,101 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * DFL driver for Userspace I/O platform devices
> > + *
> > + * Copyright (C) 2020 Intel Corporation, Inc.
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME "dfl-uio-pdev"
> > +
> > +static int dfl_uio_pdev_probe(struct dfl_device *ddev)
> > +{
> > +   struct device *dev = &ddev->dev;
> > +   struct platform_device_info pdevinfo = { 0 };
> > +   struct uio_info uio_pdata = { 0 };
> > +   struct platform_device *uio_pdev;
> > +   unsigned int num_res = 1;
> > +   struct resource *res;
> > +
> > +   if (ddev->num_irqs > 1)
> This num_irq check could be combined with the one below.

Yes, I'll change it.

> > +   dev_warn(&ddev->dev,
> > +"%d irqs for %s, but UIO only supports the first 
> > one\n",
> > +ddev->num_irqs, dev_name(&ddev->dev));
> > +
> > +   pdevinfo.name = "uio_pdrv_genirq";
> > +
> > +   if (ddev->num_irqs)
> > +   num_res++;
> > +
> > +   res = kcalloc(num_res, sizeof(*res), GFP_KERNEL);
> 
> Since num_res is at most 2, could res be converted to a stack array ?

Yes, I could refactor the code.

Thanks,
Yilun

> 
> Reviewed-by: Tom Rix  


[PATCH] RDMA/ocrdma: fix use after free in ocrdma_dealloc_ucontext_pd()

2020-12-29 Thread trix
From: Tom Rix 

In ocrdma_dealloc_ucontext_pd() uctx->cntxt_pd is assigned to
the variable pd and then after uctx->cntxt_pd is freed, the
variable pd is passed to function _ocrdma_dealloc_pd() which
dereferences pd directly or through its call to
ocrdma_mbx_dealloc_pd().

Reorder the free using the variable pd.

Fixes: 21a428a019c9 ("RDMA: Handle PD allocations by IB/core")
Signed-off-by: Tom Rix 
---
 drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
index bc98bd950d99..3acb5c10b155 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
@@ -434,9 +434,9 @@ static void ocrdma_dealloc_ucontext_pd(struct 
ocrdma_ucontext *uctx)
pr_err("%s(%d) Freeing in use pdid=0x%x.\n",
   __func__, dev->id, pd->id);
}
-   kfree(uctx->cntxt_pd);
uctx->cntxt_pd = NULL;
_ocrdma_dealloc_pd(dev, pd);
+   kfree(pd);
 }
 
 static struct ocrdma_pd *ocrdma_get_ucontext_pd(struct ocrdma_ucontext *uctx)
-- 
2.27.0



RE: [PATCH 2/4] arm64: dts: imx8mn: add spba bus node

2020-12-29 Thread Peng Fan
> Subject: Re: [PATCH 2/4] arm64: dts: imx8mn: add spba bus node
> 
> On Tue, Dec 29, 2020 at 06:26:41AM -0600, Adam Ford wrote:
> > On Tue, Dec 29, 2020 at 6:15 AM  wrote:
> > >
> > > From: Peng Fan 
> > >
> > > According to RM, there is a spba bus inside aips3 and aips1, add it.
> > >
> > > Signed-off-by: Peng Fan 
> > > ---
> > >  arch/arm64/boot/dts/freescale/imx8mm.dtsi | 362
> > > +++---
> > >  1 file changed, 189 insertions(+), 173 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > index c824f2615fe8..91f85b8cee9a 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mm.dtsi
> > > @@ -269,117 +269,125 @@ aips1: bus@3000 {
> > > #size-cells = <1>;
> > > ranges = <0x3000 0x3000
> 0x40>;
> > >
> > > -   sai1: sai@3001 {
> > > -   #sound-dai-cells = <0>;
> > > -   compatible = "fsl,imx8mm-sai",
> "fsl,imx8mq-sai";
> > > -   reg = <0x3001 0x1>;
> > > -   interrupts =  IRQ_TYPE_LEVEL_HIGH>;
> > > -   clocks = <&clk
> IMX8MM_CLK_SAI1_IPG>,
> > > -<&clk
> IMX8MM_CLK_SAI1_ROOT>,
> > > -<&clk
> IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>;
> > > -   clock-names = "bus", "mclk1",
> "mclk2", "mclk3";
> > > -   dmas = <&sdma2 0 2 0>, <&sdma2
> 1 2 0>;
> > > -   dma-names = "rx", "tx";
> > > -   status = "disabled";
> > > -   };
> > > +   bus@3000 {
> >
> > There is already a bus@3000 (aips1), and I think the system
> > doesn't like it when there are multiple busses with the same name.
> >
> > There was some discussion on fixing the 8mn [1], but it doesn't look
> > like it went anywhere.
> >
> > I am guessing the Mini will need something similar to the nano.
> >
> > [1] -
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> >
> hwork.kernel.org%2Fproject%2Flinux-arm-kernel%2Fpatch%2F1607324004-1
> 29
> >
> 60-1-git-send-email-shengjiu.wang%40nxp.com%2F&data=04%7C01%7
> Cpeng
> > .fan%40nxp.com%7C970d320f3ef7413296ed08d8ac1486f9%7C686ea1d3bc
> 2b4c6fa9
> >
> 2cd99c5c301635%7C0%7C0%7C637448551481206715%7CUnknown%7CTW
> FpbGZsb3d8ey
> >
> JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7C200
> >
> 0&sdata=xKgYHCDyitbUyTPKVuwQV%2FCoJvepCbdBJ1MD9vP%2B6MY
> %3D&res
> > erved=0
> 
> Several replies from S.j. Wang are missing from LKML (and maybe
> patchwork?) but we reached a conclusion:

Thanks for the pointing, I'll give a look. If S.J take it, I'll leave it to S.J.

Thanks,
Peng. 

> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.ke
> rnel.org%2Flinux-arm-kernel%2F20201208090601.GA8347%40kozik-lap%2F&
> amp;data=04%7C01%7Cpeng.fan%40nxp.com%7C970d320f3ef7413296ed08
> d8ac1486f9%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63744
> 8551481206715%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
> CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=nk
> t0J5RtzA%2B29nK4aPnd434FNQV8MUZ%2F8Aq64o6hl6I%3D&reserved
> =0
> 
> Either you do some remapping of address space or just rename the "bus"
> nodes (e.g. generic bus-1 or a specific spba-bus).
> 
> Best regards,
> Krzysztof


Re: [RFC please help] membarrier: Rewrite sync_core_before_usermode()

2020-12-29 Thread Nicholas Piggin
Excerpts from Russell King - ARM Linux admin's message of December 29, 2020 
8:44 pm:
> On Tue, Dec 29, 2020 at 01:09:12PM +1000, Nicholas Piggin wrote:
>> I think it should certainly be documented in terms of what guarantees
>> it provides to application, _not_ the kinds of instructions it may or
>> may not induce the core to execute. And if existing API can't be
>> re-documented sanely, then deprecatd and new ones added that DTRT.
>> Possibly under a new system call, if arch's like ARM want a range
>> flush and we don't want to expand the multiplexing behaviour of
>> membarrier even more (sigh).
> 
> The 32-bit ARM sys_cacheflush() is there only to support self-modifying
> code, and takes whatever actions are necessary to support that.
> Exactly what actions it takes are cache implementation specific, and
> should be of no concern to the caller, but the underlying thing is...
> it's to support self-modifying code.

   Caveat
   cacheflush()  should  not  be used in programs intended to be portable.
   On Linux, this call first appeared on the MIPS architecture, but  nowa‐
   days, Linux provides a cacheflush() system call on some other architec‐
   tures, but with different arguments.

What a disaster. Another badly designed interface, although it didn't 
originate in Linux it sounds like we weren't to be outdone so
we messed it up even worse.

flushing caches is neither necessary nor sufficient for code modification
on many processors. Maybe some old MIPS specific private thing was fine,
but certainly before it grew to other architectures, somebody should 
have thought for more than 2 minutes about it. Sigh.

> 
> Sadly, because it's existed for 20+ years, and it has historically been
> sufficient for other purposes too, it has seen quite a bit of abuse
> despite its design purpose not changing - it's been used by graphics
> drivers for example. They quickly learnt the error of their ways with
> ARMv6+, since it does not do sufficient for their purposes given the
> cache architectures found there.
> 
> Let's not go around redesigning this after twenty odd years, requiring
> a hell of a lot of pain to users. This interface is called by code
> generated by GCC, so to change it you're looking at patching GCC as
> well as the kernel, and you basically will make new programs
> incompatible with older kernels - very bad news for users.

For something to be redesigned it had to have been designed in the first 
place, so there is no danger of that don't worry... But no I never 
suggested making incompatible changes to any existing system call, I 
said "re-documented". And yes I said deprecated but in Linux that really 
means kept indefinitely.

If ARM, MIPS, 68k etc programs and toolchains keep using what they are 
using it'll keep working no problem.

The point is we're growing new interfaces, and making the same mistakes. 
It's not portable (ARCH_HAS_MEMBARRIER_SYNC_CORE), it's also specified 
in terms of low level processor operations rather than higher level 
intent, and also is not sufficient for self-modifying code (without 
additional cache flush on some processors).

The application wants a call that says something like "memory modified 
before the call will be visible as instructions (including illegal 
instructions) by all threads in the program after the system call 
returns, and no threads will be subject to any effects of executing the 
previous contents of that memory.

So I think the basics are simple (although should confirm with some JIT 
and debugger etc developers, and not just Android mind you). There are 
some complications in details, address ranges, virtual/physical, thread 
local vs process vs different process or system-wide, memory ordering 
and propagation of i and d sides, etc. But that can be worked through, 
erring on the side of sanity rather than pointless micro-optmisations.

Thanks,
Nick


RE: [PATCH 3/4] arm64: dts: imx8mn: add spba bus node

2020-12-29 Thread Peng Fan
> Subject: Re: [PATCH 3/4] arm64: dts: imx8mn: add spba bus node
> 
> On Tue, Dec 29, 2020 at 08:00:44PM +0800, peng@nxp.com wrote:
> > From: Peng Fan 
> >
> > According to RM, there is a spba bus inside aips3 and aips1, add it.
> 
> This does not look like matching contents of commit.

Posted in a rush. Forgot to squash commits.

Thanks,
Peng.

> 
> Best regards,
> Krzysztof
> 
> 
> >
> > Signed-off-by: Peng Fan 
> > ---
> >  arch/arm64/boot/dts/freescale/imx8mn.dtsi | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > index 73602832ccaa..033fa90570ff 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8mn.dtsi
> > @@ -749,7 +749,7 @@ uart2: serial@3089 {
> > clock-names = "ipg", "per";
> > status = "disabled";
> > };
> > -   }
> > +   };
> >
> > crypto: crypto@3090 {
> > compatible = "fsl,sec-v4.0";
> > --
> > 2.28.0
> >


[PATCH] irqchip/gic: remove a if in gic_of_setup()

2020-12-29 Thread Yejune Deng
There is two function gic_of_init() and gic_of_init_child() called
gic_of_setup(),both gic and node never fail,so remove
if (!gic || !node) is safe.

Signed-off-by: Yejune Deng 
---
 drivers/irqchip/irq-gic.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index b1d9c22..a65678f0 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -1380,9 +1380,6 @@ static bool gic_check_eoimode(struct device_node *node, 
void __iomem **base)
 
 static int gic_of_setup(struct gic_chip_data *gic, struct device_node *node)
 {
-   if (!gic || !node)
-   return -EINVAL;
-
gic->raw_dist_base = of_iomap(node, 0);
if (WARN(!gic->raw_dist_base, "unable to map gic dist registers\n"))
goto error;
-- 
1.9.1



Re: [PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time

2020-12-29 Thread Xu Yilun
On Tue, Dec 29, 2020 at 01:13:08PM +, Mark Brown wrote:
> On Tue, Dec 29, 2020 at 01:27:42PM +0800, Xu Yilun wrote:
> > The xfer waiting time is the result of xfer->len / xfer->speed_hz, but
> > when the following patch is merged,
> > 
> > commit 9326e4f1e5dd ("spi: Limit the spi device max speed to controller's 
> > max speed")
> > 
> > the xfer->speed_hz may always be clamped to 0 if the controller doesn't
> > provide its max_speed_hz. There may be no hardware indication of the
> > max_speed_hz so the controller driver leaves it, but exception happens
> > when it tries to do irq mode transfer.
> 
> Does this still apply with current code?  There have been some fixes in
> this area which I think should ensure that we don't turn the speed down
> to 0 if the controller doesn't supply a limit IIRC.

Yes, there is chance the speed is set to 0, some related code from 5.11-rc1

  int spi_setup(struct spi_device *spi)
  {
...

if (!spi->max_speed_hz ||
spi->max_speed_hz > spi->controller->max_speed_hz)
spi->max_speed_hz = spi->controller->max_speed_hz;

If the controller doesn't supply a limit, spi->max_speed_hz will always
be clamped to 0 here, no matter what the client inputs.

BTW, Could we keep the spi->max_speed_hz if no controller->max_speed_hz?
Always clamp the spi->max_speed_hz to 0 makes no sense.

...
  }

  static int __spi_validate(struct spi_device *spi, struct spi_message
*message)
  {
...

if (!xfer->speed_hz)
xfer->speed_hz = spi->max_speed_hz;

if (ctlr->max_speed_hz && xfer->speed_hz > ctlr->max_speed_hz)
xfer->speed_hz = ctlr->max_speed_hz;

If spi->max_speed_hz & controller->max_speed_hz are 0, xfer->speed_hz is
always 0.

...
  }


I tested it on 5.11-rc1 with spi-altera.

> 
> > This patch makes the assumption of 1khz xfer speed if the xfer->speed_hz
> > is not assigned. This avoids the divide by 0 issue and ensures a
> > reasonable tolerant waiting time.
> 
> It will cause absurdly slow transfers if the controller does actually
> implement speed setting though, if we're going to pick a default value

Maybe I didn't describe clearly, if the controller has a valid limit setting,
the xfer->speed_hz will be set to max_speed_hz and will not fall through to
a default value. The fix code takes function when all the checks in spi_setup &
spi_validate fails to assign the xfer->speed_hz. 

This fix only affects the waiting timeout, it will not slow down the normal
xfer anyway.

> I'd go for at least 100kHz. 

If some controller is actually working at a speed lower than the default
value, xfer will always be unexpectly early terminated.

I'm not sure how slow the controllers in the world could be. If 100kHz
is slow enough to everyone it's OK.
 
> 
> > } else {
> > +   speed_hz = xfer->speed_hz ? : 1000;
> 
> Please don't abuse the ternery operator, write normal conditional
> statements to make things more legible.

OK, I'll change it.

Thanks,
Yilun


Re: inconsistent lock state in ila_xlat_nl_cmd_add_mapping

2020-12-29 Thread Jakub Kicinski
On Tue, 29 Dec 2020 17:52:56 -0800 Cong Wang wrote:
> On Tue, Dec 29, 2020 at 5:39 PM Jakub Kicinski  wrote:
> >
> > On Mon, 13 Aug 2018 21:40:03 -0700 syzbot wrote:  
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:78cbac647e61 Merge branch 
> > > 'ip-faster-in-order-IP-fragments'
> > > git tree:   net-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14df482840
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=9100338df26ab75
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=eaaf6c4a6a8cb1869d86
> > > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13069ad240
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+eaaf6c4a6a8cb1869...@syzkaller.appspotmail.com  
> >
> > #syz invalid
> >
> > Hard to track down what fixed this, but the lockdep splat is mixing up
> > locks from two different hashtables, so there was never a real issue
> > here.  
> 
> This one is probably fixed by:
> 
> commit ff93bca769925a2d8fd7f910cdf543d992e17f07
> Author: Cong Wang 
> Date:   Tue Aug 14 15:21:31 2018 -0700
> 
> ila: make lockdep happy again
> 
> given the time of last reproducing...

Ah, yes, matches perfectly! I didn't look for fixes in spinlock.h.

Thanks!


Re: [PATCH] irqchip/gic: add WARN_ON() to facilitate backtracking

2020-12-29 Thread Yejune Deng
OK,I will adopt it and resubmit.

On Tue, Dec 29, 2020 at 5:27 PM Marc Zyngier  wrote:
>
> Yejune,
>
> On 2020-12-29 07:15, Yejune Deng wrote:
> > There is two function gic_of_init() and gic_of_init_child() called
> > gic_of_setup(),so add WARN_ON() to facilitate backtracking.
> >
> > Signed-off-by: Yejune Deng 
> > ---
> >  drivers/irqchip/irq-gic.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
> > index b1d9c22..7c11705 100644
> > --- a/drivers/irqchip/irq-gic.c
> > +++ b/drivers/irqchip/irq-gic.c
> > @@ -1380,7 +1380,7 @@ static bool gic_check_eoimode(struct device_node
> > *node, void __iomem **base)
> >
> >  static int gic_of_setup(struct gic_chip_data *gic, struct device_node
> > *node)
> >  {
> > - if (!gic || !node)
> > + if (WARN_ON(!gic || !node))
> >   return -EINVAL;
> >
> >   gic->raw_dist_base = of_iomap(node, 0);
>
> I don't immediately see what you gain with this. If you end-up here
> with NULL pointers, that either because:
>
> - you have failed to allocate the GIC private data structure:
>but as it turns out, these allocations either cannot fail (gic_data[]
>is static), or the dynamic allocation in gic_of_init_child() is
> already
>checked.
>
> - node is NULL: both paths already check for a NULL node, so that cannot
>fail either.
>
> My conclusion is that these checks can never trigger, and we should be
> able to *remove* them altogether.
>
> Am I missing something?
>
>  M.
> --
> Jazz is not dead. It just smells funny...


linux-next: stats (Was: Linux 5.11-rc1)

2020-12-29 Thread Stephen Rothwell
Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20201214 was the first linux-next after
the merge window opened.)

Commits in v5.11-rc1 (relative to v5.10):  12498
Commits in next-20201214:  12038
Commits with the same SHA1:10988
Commits with the same patch_id:  500 (1)
Commits with the same subject line:   47 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20201214: 11535 92%

Some breakdown of the list of extra commits (relative to next-20201214)
in -rc1:

Top ten first word of commit summary:

135 perf
 76 drm
 49 kvm
 35 libceph
 31 clk
 27 net
 27 cifs
 26 dt-bindings
 24 tools
 23 ceph

Top ten authors:

 56 a...@redhat.com
 34 thomas.lenda...@amd.com
 34 idryo...@gmail.com
 32 t...@linutronix.de
 31 leo@linaro.org
 19 trond.mykleb...@hammerspace.com
 19 peter.ujfal...@ti.com
 16 sgarz...@redhat.com
 15 jo...@kernel.org
 15 jlay...@kernel.org

Top ten commiters:

158 a...@redhat.com
 88 k...@kernel.org
 59 idryo...@gmail.com
 57 alexander.deuc...@amd.com
 50 pbonz...@redhat.com
 37 ax...@kernel.dk
 36 sb...@kernel.org
 33 t...@linutronix.de
 30 stfre...@microsoft.com
 30 m...@redhat.com

There are also 503 commits in next-20201214 that didn't make it into
v5.11-rc1.

Top ten first word of commit summary:

 65 drm
 42 arm
 38 mm
 30 usb
 23 scsi
 23 btrfs
 14 fpga
 12 dt-bindings
 11 sparc32
 11 soc

Top ten authors:

 22 mchehab+hua...@kernel.org
 20 wi...@infradead.org
 19 jo...@toxicpanda.com
 16 jani.nik...@intel.com
 15 uma.shan...@intel.com
 15 a...@linux-foundation.org
 14 r...@kernel.org
 14 m...@kernel.org
 13 paw...@cadence.com
 12 a...@arndb.de

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

121 s...@canb.auug.org.au
 32 peter.c...@nxp.com
 28 alexandre.tor...@st.com
 23 dste...@suse.com
 23 dhowe...@redhat.com
 22 martin.peter...@oracle.com
 21 mchehab+hua...@kernel.org
 19 geert+rene...@glider.be
 18 m...@kernel.org
 18 a...@arndb.de

Those commits by me are from Andrew's mmotm tree.

-- 
Cheers,
Stephen Rothwell


pgpQ71gOtcnmF.pgp
Description: OpenPGP digital signature


Re: inconsistent lock state in ila_xlat_nl_cmd_add_mapping

2020-12-29 Thread Cong Wang
On Tue, Dec 29, 2020 at 5:39 PM Jakub Kicinski  wrote:
>
> On Mon, 13 Aug 2018 21:40:03 -0700 syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:78cbac647e61 Merge branch 'ip-faster-in-order-IP-fragments'
> > git tree:   net-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14df482840
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=9100338df26ab75
> > dashboard link: https://syzkaller.appspot.com/bug?extid=eaaf6c4a6a8cb1869d86
> > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13069ad240
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+eaaf6c4a6a8cb1869...@syzkaller.appspotmail.com
>
> #syz invalid
>
> Hard to track down what fixed this, but the lockdep splat is mixing up
> locks from two different hashtables, so there was never a real issue
> here.

This one is probably fixed by:

commit ff93bca769925a2d8fd7f910cdf543d992e17f07
Author: Cong Wang 
Date:   Tue Aug 14 15:21:31 2018 -0700

ila: make lockdep happy again

given the time of last reproducing...

Thanks.


[PATCH v2 net-next] net: kcm: Replace fput with sockfd_put

2020-12-29 Thread Zheng Yongjun
The function sockfd_lookup uses fget on the value that is stored in
the file field of the returned structure, so fput should ultimately be
applied to this value.  This can be done directly, but it seems better
to use the specific macro sockfd_put, which does the same thing.

The refactoring proposed was found using the following semantic patch.

// 
@@
expression s;
@@

   s = sockfd_lookup(...)
   ...
+  sockfd_put(s);
- fput(s->file);
// 

Signed-off-by: Zheng Yongjun 
---
 net/kcm/kcmsock.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
index 56dad9565bc9..a9eb616f5521 100644
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -1496,7 +1496,7 @@ static int kcm_attach_ioctl(struct socket *sock, struct 
kcm_attach *info)
 
return 0;
 out:
-   fput(csock->file);
+   sockfd_put(csock);
return err;
 }
 
@@ -1644,7 +1644,7 @@ static int kcm_unattach_ioctl(struct socket *sock, struct 
kcm_unattach *info)
spin_unlock_bh(&mux->lock);
 
 out:
-   fput(csock->file);
+   sockfd_put(csock);
return err;
 }
 
-- 
2.22.0



Re: inconsistent lock state in ila_xlat_nl_cmd_add_mapping

2020-12-29 Thread Jakub Kicinski
On Mon, 13 Aug 2018 21:40:03 -0700 syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:78cbac647e61 Merge branch 'ip-faster-in-order-IP-fragments'
> git tree:   net-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=14df482840
> kernel config:  https://syzkaller.appspot.com/x/.config?x=9100338df26ab75
> dashboard link: https://syzkaller.appspot.com/bug?extid=eaaf6c4a6a8cb1869d86
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13069ad240
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+eaaf6c4a6a8cb1869...@syzkaller.appspotmail.com

#syz invalid

Hard to track down what fixed this, but the lockdep splat is mixing up
locks from two different hashtables, so there was never a real issue
here.


[PATCH v2 -next] staging: greybus: light: Use kzalloc for allocating only one thing

2020-12-29 Thread Zheng Yongjun
Use kzalloc rather than kcalloc(1,...)

The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)

// 
@@
@@

- kcalloc(1,
+ kzalloc(
  ...)
// 

Signed-off-by: Zheng Yongjun 
---
 drivers/staging/greybus/light.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c
index d2672b65c3f4..87d36948c610 100644
--- a/drivers/staging/greybus/light.c
+++ b/drivers/staging/greybus/light.c
@@ -290,8 +290,7 @@ static int channel_attr_groups_set(struct gb_channel 
*channel,
channel->attrs = kcalloc(size + 1, sizeof(*channel->attrs), GFP_KERNEL);
if (!channel->attrs)
return -ENOMEM;
-   channel->attr_group = kcalloc(1, sizeof(*channel->attr_group),
- GFP_KERNEL);
+   channel->attr_group = kzalloc(sizeof(*channel->attr_group), GFP_KERNEL);
if (!channel->attr_group)
return -ENOMEM;
channel->attr_groups = kcalloc(2, sizeof(*channel->attr_groups),
-- 
2.22.0



[PATCH 5/5] ARM: dts: meson: add the AO ARC remote processor

2020-12-29 Thread Martin Blumenstingl
The 32-bit Amlogic Meson SoCs embed an ARC processor in the Always-On
power domain which is typically used for managing system suspend. The
memory for this ARC core is taken from the AHB SRAM area. Depending on
the actual SoC a different ARC core is used:
- Meson6 and earlier: some ARCv1 ISA based core (probably an ARC625)
- Meson8 and later: an ARC EM4 (ARCv2 ISA) based core

Add the device-tree node for this remote-processor along with the
required SRAM sections, clocks and reset-lines. Also use the
SoC-specific compatible string to manage any differences (should
they exist).

On Meson8, Meson8b and Meson8m2 the "secbus2" IO region is needed as
some bits need to be programmed there. Add this IO region for those
SoCs as well.

Signed-off-by: Martin Blumenstingl 
---
 arch/arm/boot/dts/meson.dtsi   |  7 +++
 arch/arm/boot/dts/meson8.dtsi  | 21 +
 arch/arm/boot/dts/meson8b.dtsi | 21 +
 3 files changed, 49 insertions(+)

diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index e0ca5f08d07d..8bae6ed0abb2 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -200,6 +200,13 @@ aobus: aobus@c810 {
#size-cells = <1>;
ranges = <0x0 0xc810 0x10>;
 
+   ao_arc_rproc: remoteproc@1c {
+   compatible= "amlogic,meson-mx-ao-arc";
+   reg = <0x1c 0x8>, <0x38 0x8>;
+   reg-names = "remap", "cpu";
+   status = "disabled";
+   };
+
ir_receiver: ir-receiver@480 {
compatible= "amlogic,meson6-ir";
reg = <0x480 0x20>;
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 420324ea2ad7..157a950a55d3 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -369,6 +369,14 @@ mux {
};
 };
 
+&ao_arc_rproc {
+   compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
+   amlogic,secbus2 = <&secbus2>;
+   sram = <&ao_arc_sram>;
+   resets = <&reset RESET_MEDIA_CPU>;
+   clocks = <&clkc CLKID_AO_MEDIA_CPU>;
+};
+
 &cbus {
reset: reset-controller@4404 {
compatible = "amlogic,meson8b-reset";
@@ -496,6 +504,12 @@ mux {
 };
 
 &ahb_sram {
+   ao_arc_sram: ao-arc-sram@0 {
+   compatible = "amlogic,meson8-ao-arc-sram";
+   reg = <0x0 0x8000>;
+   pool;
+   };
+
smp-sram@1ff80 {
compatible = "amlogic,meson8-smp-sram";
reg = <0x1ff80 0x8>;
@@ -631,6 +645,13 @@ &sdhc {
clock-names = "clkin0", "clkin1", "clkin2", "clkin3", "pclk";
 };
 
+&secbus {
+   secbus2: system-controller@4000 {
+   compatible = "amlogic,meson8-secbus2", "syscon";
+   reg = <0x4000 0x2000>;
+   };
+};
+
 &sdio {
compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio";
clocks = <&clkc CLKID_SDIO>, <&clkc CLKID_CLK81>;
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index dbf7963b6c87..c02b03cbcdf4 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -320,6 +320,14 @@ mux {
};
 };
 
+&ao_arc_rproc {
+   compatible= "amlogic,meson8b-ao-arc", "amlogic,meson-mx-ao-arc";
+   amlogic,secbus2 = <&secbus2>;
+   sram = <&ao_arc_sram>;
+   resets = <&reset RESET_MEDIA_CPU>;
+   clocks = <&clkc CLKID_AO_MEDIA_CPU>;
+};
+
 &cbus {
reset: reset-controller@4404 {
compatible = "amlogic,meson8b-reset";
@@ -464,6 +472,12 @@ mux {
 };
 
 &ahb_sram {
+   ao_arc_sram: ao-arc-sram@0 {
+   compatible = "amlogic,meson8b-ao-arc-sram";
+   reg = <0x0 0x8000>;
+   pool;
+   };
+
smp-sram@1ff80 {
compatible = "amlogic,meson8b-smp-sram";
reg = <0x1ff80 0x8>;
@@ -628,6 +642,13 @@ &sdhc {
clock-names = "clkin0", "clkin1", "clkin2", "clkin3", "pclk";
 };
 
+&secbus {
+   secbus2: system-controller@4000 {
+   compatible = "amlogic,meson8b-secbus2", "syscon";
+   reg = <0x4000 0x2000>;
+   };
+};
+
 &sdio {
compatible = "amlogic,meson8b-sdio", "amlogic,meson-mx-sdio";
clocks = <&clkc CLKID_SDIO>, <&clkc CLKID_CLK81>;
-- 
2.30.0



[PATCH 0/5] Amlogic Meson Always-On ARC remote-processor support

2020-12-29 Thread Martin Blumenstingl
Amlogic Meson6/8/8b/8m2 come with an ARC core in the Always-On (AO)
power-domain. This is typically used for waking up the ARM CPU after
powering it down for system suspend.

The exact ARC core used on Meson6 and earlier is not known. I believe
it is an ARC625, but I am not sure about this. Meson8/8b/8m2 uses an
ARC EM4 core.
They all have in common that they use a section of the SoCs SRAM for
running code on the ARC core.

Unfortunately there's no information about the remote-processor control
registers in the public Meson8b (S805) datasheet. All information is
either taken from Amlogic's 3.10 kernel and 2011-03 u-boot or found by
testing (for example the clock input is not mentioned anywhere in the
reference code, but disabling it stops the AO ARC core from working).

This series consists of five patches:
 1: dt-bindings for the SRAM section
 2: dt-bindings for the SECBUS2 syscon region which contains a few
bits for controlling this remote processor
 3: dt-bindings for the AO ARC remote processor
 4: the driver for booting code on the AO ARC remote processor
 5: (only included for documentation purposes) dts changes (these will
be re-sent separately)

Patches #3 and #4 should go through the remoteproc tree. Patches #1
and #2 may go through Rob's (devicetree) tree, Kevin's linux-amlogic
tree or through the remoteproc tree. Personally I have no preference
here.

To test this series I ported the Amlogic serial driver and added the
board files for the Amlogic AO ARC EM4 to the Zephyr RTOS. The code can
be found here: [0] (the resulting zephyr.elf can then be loaded as
remote-processor firmware from Linux).


[0] https://github.com/xdarklight/zephyr-rtos/commits/amlogic_ao_em4-20201229


Martin Blumenstingl (5):
  dt-bindings: sram: Add compatible strings for the Meson AO ARC SRAM
  dt-bindings: Amlogic: add the documentation for the SECBUS2 registers
  dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc
  remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote
procesor
  ARM: dts: meson: add the AO ARC remote processor

 .../arm/amlogic/amlogic,meson-mx-secbus2.yaml |  53 
 .../remoteproc/amlogic,meson-mx-ao-arc.yaml   |  87 +++
 .../devicetree/bindings/sram/sram.yaml|   2 +
 arch/arm/boot/dts/meson.dtsi  |   7 +
 arch/arm/boot/dts/meson8.dtsi |  21 ++
 arch/arm/boot/dts/meson8b.dtsi|  21 ++
 drivers/remoteproc/Kconfig|  11 +
 drivers/remoteproc/Makefile   |   1 +
 drivers/remoteproc/meson_mx_ao_arc.c  | 240 ++
 9 files changed, 443 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
 create mode 100644 drivers/remoteproc/meson_mx_ao_arc.c

-- 
2.30.0



[PATCH 2/5] dt-bindings: Amlogic: add the documentation for the SECBUS2 registers

2020-12-29 Thread Martin Blumenstingl
The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
contains registers for various IP blocks such as pin-controller bits for
the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
The registers can be accessed directly when not running in "secure mode".
When "secure mode" is enabled then these registers have to be accessed
through secure monitor calls.

So far these SoCs are always known to boot in "non-secure mode".
Add a binding documentation using syscon (as these registers are shared
across different IPs) for the SECBUS2 registers.

Signed-off-by: Martin Blumenstingl 
---
 .../arm/amlogic/amlogic,meson-mx-secbus2.yaml | 53 +++
 1 file changed, 53 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml

diff --git 
a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml 
b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
new file mode 100644
index ..cfa8e9de6c28
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Amlogic Meson8/Meson8b/Meson8m2 SECBUS2 register interface
+
+maintainers:
+  - Martin Blumenstingl 
+
+description: |
+  The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
+  contains registers for various IP blocks such as pin-controller bits for
+  the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
+  The registers can be accessed directly when not running in "secure mode".
+  When "secure mode" is enabled then these registers have to be accessed
+  through secure monitor calls.
+
+# We need a select here so we don't match all nodes with 'syscon'
+select:
+  properties:
+compatible:
+  contains:
+enum:
+  - amlogic,meson8-secbus2
+  - amlogic,meson8b-secbus2
+  required:
+- compatible
+
+properties:
+  compatible:
+items:
+  - enum:
+- amlogic,meson8-secbus2
+- amlogic,meson8b-secbus2
+  - const: syscon
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+secbus2: system-controller@4000 {
+  compatible = "amlogic,meson8-secbus2", "syscon";
+  reg = <0x4000 0x2000>;
+};
-- 
2.30.0



[PATCH 1/5] dt-bindings: sram: Add compatible strings for the Meson AO ARC SRAM

2020-12-29 Thread Martin Blumenstingl
Amlogic Meson8, Meson8b and Meson8m2 SoCs embed an ARC EM4 core
typically used for managing system suspend. A section of the SoCs SRAM
is mapped as memory for this ARC core. Add new compatible strings for
the SRAM section for the ARC core memory.

Signed-off-by: Martin Blumenstingl 
---
 Documentation/devicetree/bindings/sram/sram.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/sram/sram.yaml 
b/Documentation/devicetree/bindings/sram/sram.yaml
index 19d116ff9ddc..6d65771e979c 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -72,6 +72,8 @@ patternProperties:
 - allwinner,sun4i-a10-sram-d
 - allwinner,sun9i-a80-smp-sram
 - allwinner,sun50i-a64-sram-c
+- amlogic,meson8-ao-arc-sram
+- amlogic,meson8b-ao-arc-sram
 - amlogic,meson8-smp-sram
 - amlogic,meson8b-smp-sram
 - amlogic,meson-gxbb-scp-shmem
-- 
2.30.0



[PATCH 4/5] remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor

2020-12-29 Thread Martin Blumenstingl
Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the
Always-On (AO) power-domain. This is typically used for waking up the
ARM cores after system suspend.

The configuration is spread across three different registers:
- AO_REMAP_REG0 which must be programmed to zero, it's actual purpose
  is unknown. There is a second remap register which is not used in the
  vendor kernel (which served as reference for this driver).
- AO_CPU_CNTL is used to start and stop the ARC core.
- AO_SECURE_REG0 in the SECBUS2 register area with unknown purpose.

To boot the ARC core we also need to enable it's gate clock and trigger
a reset.

The actual code for this ARC core can come from an ELF binary, for
example by building the Zephyr RTOS for an ARC EM4 core and then taking
"zephyr.elf" as firmware. This executable does not have any "rsc table"
so we are skipping rproc_elf_load_rsc_table (rproc_ops.parse_fw) and
rproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table).

Signed-off-by: Martin Blumenstingl 
---
 drivers/remoteproc/Kconfig   |  11 ++
 drivers/remoteproc/Makefile  |   1 +
 drivers/remoteproc/meson_mx_ao_arc.c | 240 +++
 3 files changed, 252 insertions(+)
 create mode 100644 drivers/remoteproc/meson_mx_ao_arc.c

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 9e7efe542f69..0e7fb91635fe 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -125,6 +125,17 @@ config KEYSTONE_REMOTEPROC
  It's safe to say N here if you're not interested in the Keystone
  DSPs or just want to use a bare minimum kernel.
 
+config MESON_MX_AO_ARC_REMOTEPROC
+   tristate "Amlogic Meson6/8/8b/8m2 AO ARC remote processor support"
+   depends on HAS_IOMEM
+   depends on (ARM && ARCH_MESON) || COMPILE_TEST
+   select GENERIC_ALLOCATOR
+   help
+ Say m or y here to have support for the AO ARC remote processor
+ on Amlogic Meson6/Meson8/Meson8b/Meson8m2 SoCs. This is
+ typically used for system suspend.
+ If unusre say N.
+
 config PRU_REMOTEPROC
tristate "TI PRU remoteproc support"
depends on TI_PRUSS
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index bb26c9e4ef9c..ce1abeb30907 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
 obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
 obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
 obj-$(CONFIG_KEYSTONE_REMOTEPROC)  += keystone_remoteproc.o
+obj-$(CONFIG_MESON_MX_AO_ARC_REMOTEPROC)+= meson_mx_ao_arc.o
 obj-$(CONFIG_PRU_REMOTEPROC)   += pru_rproc.o
 obj-$(CONFIG_QCOM_PIL_INFO)+= qcom_pil_info.o
 obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
diff --git a/drivers/remoteproc/meson_mx_ao_arc.c 
b/drivers/remoteproc/meson_mx_ao_arc.c
new file mode 100644
index ..1deb03ca30f4
--- /dev/null
+++ b/drivers/remoteproc/meson_mx_ao_arc.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Martin Blumenstingl 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define AO_REMAP_REG0  0x0
+#define AO_REMAP_REG1  0x4
+
+#define AO_CPU_CNTL0x0
+   #define AO_CPU_CNTL_MEM_ADDR_UPPER  GENMASK(28, 16)
+   #define AO_CPU_CNTL_HALTBIT(9)
+   #define AO_CPU_CNTL_UNKNONWNBIT(8)
+   #define AO_CPU_CNTL_RUN BIT(0)
+
+#define AO_CPU_STAT0x4
+
+#define AO_SECURE_REG0 0x0
+   #define AO_SECURE_REG0_UNKNOWN  GENMASK(23, 8)
+
+#define MESON_AO_RPROC_SRAM_USABLE_BITSGENMASK(31, 20)
+#define MESON_AO_RPROC_MEMORY_OFFSET   0x1000
+
+struct meson_mx_ao_arc_rproc_priv {
+   void __iomem*remap_base;
+   void __iomem*cpu_base;
+   unsigned long   sram_va;
+   phys_addr_t sram_pa;
+   size_t  sram_size;
+   struct gen_pool *sram_pool;
+   struct reset_control*arc_reset;
+   struct clk  *arc_pclk;
+   struct regmap   *secbus2_regmap;
+};
+
+static int meson_mx_ao_arc_rproc_start(struct rproc *rproc)
+{
+   struct meson_mx_ao_arc_rproc_priv *priv = rproc->priv;
+   phys_addr_t phys_addr;
+   int ret;
+
+   ret = clk_prepare_enable(priv->arc_pclk);
+   if (ret)
+   return ret;
+
+   writel(0, priv->remap_base + AO_REMAP_REG0);
+   usleep_range(10, 100);
+
+   re

[PATCH 3/5] dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc

2020-12-29 Thread Martin Blumenstingl
Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC EM4
controller for always-on operations, typically used for managing system
suspend.

Signed-off-by: Martin Blumenstingl 
---
 .../remoteproc/amlogic,meson-mx-ao-arc.yaml   | 87 +++
 1 file changed, 87 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml

diff --git 
a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml 
b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
new file mode 100644
index ..ba5deebaf7dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml#";
+$schema: "http://devicetree.org/meta-schemas/core.yaml#";
+
+title: Amlogic Meson AO ARC Remote Processor bindings
+
+description:
+  Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC core
+  controller for always-on operations, typically used for managing
+  system suspend. Meson6 and older use a ARC core based on the ARCv1
+  ISA, while Meson8, Meson8b and Meson8m2 use an ARC EM4 (ARCv2 ISA)
+  core.
+
+maintainers:
+  - Martin Blumenstingl 
+
+properties:
+  compatible:
+items:
+  - enum:
+- amlogic,meson8-ao-arc
+- amlogic,meson8b-ao-arc
+  - const: amlogic,meson-mx-ao-arc
+
+  firmware-name:
+$ref: /schemas/types.yaml#/definitions/string
+description:
+  The name of the firmware which should be loaded for this remote
+  processor.
+
+  reg:
+description:
+  Address ranges of the remap and CPU control addresses for the
+  remote processor.
+minItems: 2
+
+  reg-names:
+items:
+  - const: remap
+  - const: cpu
+
+  resets:
+ minItems: 1
+
+  clocks:
+minItems: 1
+
+  sram:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  phandles to a reserved SRAM region which is used as the memory of
+  the ARC core. The region should be defined as child nodes of the
+  AHB SRAM node as per the generic bindings in
+  Documentation/devicetree/bindings/sram/sram.yaml
+
+  amlogic,secbus2:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+  A phandle to the SECBUS2 region which contains some configuration
+  bits of this remote processor
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - resets
+  - clocks
+  - sram
+  - amlogic,secbus2
+
+additionalProperties: false
+
+examples:
+  - |
+remoteproc@1c {
+  compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
+  reg = <0x1c 0x8>, <0x38 0x8>;
+  reg-names = "remap", "cpu";
+  resets = <&media_cpu_reset>;
+  clocks = <&media_cpu_clock>;
+  sram = <&ahb_sram_ao_arc>;
+  amlogic,secbus2 = <&secbus2>;
+};
+
+...
-- 
2.30.0



[ANNOUNCE] 4.9.249-rt164

2020-12-29 Thread Luis Claudio R. Goncalves
Hello RT-list!

I'm pleased to announce the 4.9.249-rt164 stable release.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v4.9-rt
  Head SHA1: cd8267a1050e4380c4325a5384de42f4412bfc2b

Or to build 4.9.249-rt164 directly, the following patches should be applied:

  https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.9.tar.xz

  https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.9.249.xz

  
https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.249-rt164.patch.xz


Enjoy!
Luis



signature.asc
Description: PGP signature


Re: [PATCH] MIPS: Loongson64: Give chance to build under !CONFIG_NUMA and !CONFIG_SMP

2020-12-29 Thread Tiezhu Yang

On 12/30/2020 12:39 AM, Thomas Bogendoerfer wrote:

On Wed, Dec 16, 2020 at 10:44:23AM +0800, Tiezhu Yang wrote:

I have tested the following three configs on the Loongson platform:
(1) !NUMA and !SMP,
(2) !NUMA and SMP,
(3) NUMA and SMP,
everything is all right.

But there exists the following build error under NUMA and !SMP:

   CC  arch/mips/kernel/asm-offsets.s
In file included from ./include/linux/gfp.h:9:0,
  from ./include/linux/xarray.h:14,
  from ./include/linux/radix-tree.h:19,
  from ./include/linux/fs.h:15,
  from ./include/linux/compat.h:17,
  from arch/mips/kernel/asm-offsets.c:12:
./include/linux/topology.h: In function ‘numa_node_id’:
./include/linux/topology.h:119:2: error: implicit declaration of function
‘cpu_logical_map’ [-Werror=implicit-function-declaration]
   return cpu_to_node(raw_smp_processor_id());
   ^
cc1: some warnings being treated as errors
scripts/Makefile.build:117: recipe for target
'arch/mips/kernel/asm-offsets.s' failed
make[1]: *** [arch/mips/kernel/asm-offsets.s] Error 1
arch/mips/Makefile:396: recipe for target 'archprepare' failed
make: *** [archprepare] Error 2

I find a patch to fix this kind of build errors [1], but it seems
meaningless.

According to the NUMA and SMP description in arch/mips/Kconfig,
we will use only one CPU of a multiprocessor machine if !SMP,
on single node systems leave NUMA disabled.

So I think there is no need to use NUMA if !SMP, and also we should
make NUMA depend on SMP to avoid build errors.

ok, but compiling IP27 with your patch gives

WARNING: unmet direct dependencies detected for NUMA
   Depends on [n]: SYS_SUPPORTS_NUMA [=y] && SMP [=n]
   Selected by [y]:
   - SGI_IP27 [=y] && 

WARNING: unmet direct dependencies detected for NUMA
   Depends on [n]: SYS_SUPPORTS_NUMA [=y] && SMP [=n]
   Selected by [y]:
   - SGI_IP27 [=y] && 

WARNING: unmet direct dependencies detected for NUMA
   Depends on [n]: SYS_SUPPORTS_NUMA [=y] && SMP [=n]
   Selected by [y]:
   - SGI_IP27 [=y] && 

If I use "select SMP" instead both ip27 and loongson64 compile.

If you are ok with this change, I'll change it while appling your
patch.


No problem, looks good to me, thank you very much.

Thanks,
Tiezhu


Thomas.





[PATCH 1/6] block: manage bio slab cache by xarray

2020-12-29 Thread Ming Lei
Managing bio slab cache via xarray by using slab cache size as xarray index, and
storing 'struct bio_slab' instance into xarray.

So code is simplified a lot, meantime is is more readable than before.

Signed-off-by: Ming Lei 
---
 block/bio.c | 104 +---
 1 file changed, 42 insertions(+), 62 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index 1f2cc1fbe283..aa657cdd7c8c 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include "blk.h"
@@ -58,61 +59,49 @@ struct bio_slab {
char name[8];
 };
 static DEFINE_MUTEX(bio_slab_lock);
-static struct bio_slab *bio_slabs;
-static unsigned int bio_slab_nr, bio_slab_max;
+static DEFINE_XARRAY(bio_slabs);
+
+static struct bio_slab *create_bio_slab(unsigned int size)
+{
+   struct bio_slab *bslab = kzalloc(sizeof(*bslab), GFP_KERNEL);
+   if (!bslab)
+   return NULL;
+
+   snprintf(bslab->name, sizeof(bslab->name), "bio-%d", size);
+   bslab->slab = kmem_cache_create(bslab->name, size,
+   ARCH_KMALLOC_MINALIGN, SLAB_HWCACHE_ALIGN, NULL);
+   if (bslab->slab) {
+   bslab->slab_ref = 1;
+   bslab->slab_size = size;
+   } else {
+   kfree(bslab);
+   bslab = NULL;
+   }
+   return bslab;
+}
 
 static struct kmem_cache *bio_find_or_create_slab(unsigned int extra_size)
 {
unsigned int sz = sizeof(struct bio) + extra_size;
struct kmem_cache *slab = NULL;
-   struct bio_slab *bslab, *new_bio_slabs;
-   unsigned int new_bio_slab_max;
-   unsigned int i, entry = -1;
+   struct bio_slab *bslab;
 
mutex_lock(&bio_slab_lock);
-
-   i = 0;
-   while (i < bio_slab_nr) {
-   bslab = &bio_slabs[i];
-
-   if (!bslab->slab && entry == -1)
-   entry = i;
-   else if (bslab->slab_size == sz) {
+   bslab = xa_load(&bio_slabs, sz);
+   if (bslab) {
+   slab = bslab->slab;
+   bslab->slab_ref++;
+   } else {
+   bslab = create_bio_slab(sz);
+   if(bslab && !xa_err(xa_store(&bio_slabs, sz, bslab,
+   GFP_KERNEL)))
slab = bslab->slab;
-   bslab->slab_ref++;
-   break;
+   else {
+   if (bslab)
+   kmem_cache_destroy(bslab->slab);
+   kfree(bslab);
}
-   i++;
-   }
-
-   if (slab)
-   goto out_unlock;
-
-   if (bio_slab_nr == bio_slab_max && entry == -1) {
-   new_bio_slab_max = bio_slab_max << 1;
-   new_bio_slabs = krealloc(bio_slabs,
-new_bio_slab_max * sizeof(struct 
bio_slab),
-GFP_KERNEL);
-   if (!new_bio_slabs)
-   goto out_unlock;
-   bio_slab_max = new_bio_slab_max;
-   bio_slabs = new_bio_slabs;
}
-   if (entry == -1)
-   entry = bio_slab_nr++;
-
-   bslab = &bio_slabs[entry];
-
-   snprintf(bslab->name, sizeof(bslab->name), "bio-%d", entry);
-   slab = kmem_cache_create(bslab->name, sz, ARCH_KMALLOC_MINALIGN,
-SLAB_HWCACHE_ALIGN, NULL);
-   if (!slab)
-   goto out_unlock;
-
-   bslab->slab = slab;
-   bslab->slab_ref = 1;
-   bslab->slab_size = sz;
-out_unlock:
mutex_unlock(&bio_slab_lock);
return slab;
 }
@@ -120,27 +109,26 @@ static struct kmem_cache 
*bio_find_or_create_slab(unsigned int extra_size)
 static void bio_put_slab(struct bio_set *bs)
 {
struct bio_slab *bslab = NULL;
-   unsigned int i;
+   unsigned int slab_size = bs->front_pad + sizeof(struct bio) +
+   BIO_INLINE_VECS * sizeof(struct bio_vec);
 
mutex_lock(&bio_slab_lock);
 
-   for (i = 0; i < bio_slab_nr; i++) {
-   if (bs->bio_slab == bio_slabs[i].slab) {
-   bslab = &bio_slabs[i];
-   break;
-   }
-   }
-
+   bslab = xa_load(&bio_slabs, slab_size);
if (WARN(!bslab, KERN_ERR "bio: unable to find slab!\n"))
goto out;
 
+   WARN_ON_ONCE(bslab->slab != bs->bio_slab);
+
WARN_ON(!bslab->slab_ref);
 
if (--bslab->slab_ref)
goto out;
 
+   xa_erase(&bio_slabs, slab_size);
+
kmem_cache_destroy(bslab->slab);
-   bslab->slab = NULL;
+   kfree(bslab);
 
 out:
mutex_unlock(&bio_slab_lock);
@@ -1651,16 +1639,8 @@ static void __init biovec_init_slabs(void)
 
 static int __init init_bio(void)
 {
-   bio_slab_max = 2;
-   bio_slab_nr = 0;
-   bio_slabs = kcalloc(bio_slab_max, sizeof(struct bio_slab),
-  

[PATCH 5/6] block: move three bvec helpers declaration into private helper

2020-12-29 Thread Ming Lei
bvec_alloc(), bvec_free() and bvec_nr_vecs() are only used inside block
layer core functions, no need to declare them in public header.

Signed-off-by: Ming Lei 
---
 block/blk.h | 4 
 include/linux/bio.h | 3 ---
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/block/blk.h b/block/blk.h
index 7550364c326c..ac60f5024d6f 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -55,6 +55,10 @@ void blk_free_flush_queue(struct blk_flush_queue *q);
 
 void blk_freeze_queue(struct request_queue *q);
 
+extern struct bio_vec *bvec_alloc(gfp_t, int, unsigned long *, mempool_t *);
+extern void bvec_free(mempool_t *, struct bio_vec *, unsigned int);
+extern unsigned int bvec_nr_vecs(unsigned short idx);
+
 static inline bool biovec_phys_mergeable(struct request_queue *q,
struct bio_vec *vec1, struct bio_vec *vec2)
 {
diff --git a/include/linux/bio.h b/include/linux/bio.h
index f606eb1e556f..70914dd6a70d 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -478,9 +478,6 @@ static inline void zero_fill_bio(struct bio *bio)
zero_fill_bio_iter(bio, bio->bi_iter);
 }
 
-extern struct bio_vec *bvec_alloc(gfp_t, int, unsigned long *, mempool_t *);
-extern void bvec_free(mempool_t *, struct bio_vec *, unsigned int);
-extern unsigned int bvec_nr_vecs(unsigned short idx);
 extern const char *bio_devname(struct bio *bio, char *buffer);
 
 #define bio_set_dev(bio, bdev) \
-- 
2.28.0



[PATCH 6/6] bcache: don't pass BIOSET_NEED_BVECS for the 'bio_set' embedded in 'cache_set'

2020-12-29 Thread Ming Lei
This bioset is just for allocating bio only from bio_next_split, and it needn't
bvecs, so remove the flag.

Cc: linux-bca...@vger.kernel.org
Cc: Coly Li 
Signed-off-by: Ming Lei 
---
 drivers/md/bcache/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/md/bcache/super.c b/drivers/md/bcache/super.c
index 0e06d721cd8e..61c8aafc0a32 100644
--- a/drivers/md/bcache/super.c
+++ b/drivers/md/bcache/super.c
@@ -1897,7 +1897,7 @@ struct cache_set *bch_cache_set_alloc(struct cache_sb *sb)
goto err;
 
if (bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio),
-   BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER))
+   BIOSET_NEED_RESCUER))
goto err;
 
c->uuids = alloc_meta_bucket_pages(GFP_KERNEL, sb);
-- 
2.28.0



[PATCH 4/6] block: set .bi_max_vecs as actual allocated vector number

2020-12-29 Thread Ming Lei
bvec_alloc() may allocate more bio vectors than requested, so set .bi_max_vecs 
as
actual allocated vector number, instead of the requested number. This way can 
help
fs build bigger bio because new bio often won't be allocated until the current 
one
becomes full.

Signed-off-by: Ming Lei 
---
 block/bio.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/block/bio.c b/block/bio.c
index 3991a5aab1bc..e567feb380b6 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -502,12 +502,13 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, unsigned int 
nr_iovecs,
goto err_free;
 
bio->bi_flags |= idx << BVEC_POOL_OFFSET;
+   bio->bi_max_vecs = bvec_nr_vecs(idx);
} else if (nr_iovecs) {
bvl = bio->bi_inline_vecs;
+   bio->bi_max_vecs = inline_vecs;
}
 
bio->bi_pool = bs;
-   bio->bi_max_vecs = nr_iovecs;
bio->bi_io_vec = bvl;
return bio;
 
-- 
2.28.0



[PATCH 2/6] block: don't pass BIOSET_NEED_BVECS for q->bio_split

2020-12-29 Thread Ming Lei
q->bio_split is only used by bio_split() for fast cloning bio, and no
need to allocate bvecs, so remove this flag.

Signed-off-by: Ming Lei 
---
 block/blk-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-core.c b/block/blk-core.c
index 96e5fcd7f071..3480ca037d3f 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -530,7 +530,7 @@ struct request_queue *blk_alloc_queue(int node_id)
if (q->id < 0)
goto fail_q;
 
-   ret = bioset_init(&q->bio_split, BIO_POOL_SIZE, 0, BIOSET_NEED_BVECS);
+   ret = bioset_init(&q->bio_split, BIO_POOL_SIZE, 0, 0);
if (ret)
goto fail_id;
 
-- 
2.28.0



[PATCH 0/6] block: improvement on bioset & bvec allocation

2020-12-29 Thread Ming Lei
Hello,

All are bioset / bvec improvement, and most of them are quite
straightforward.


Ming Lei (6):
  block: manage bio slab cache by xarray
  block: don't pass BIOSET_NEED_BVECS for q->bio_split
  block: don't allocate inline bvecs if this bioset needn't bvecs
  block: set .bi_max_vecs as actual allocated vector number
  block: move three bvec helpers declaration into private helper
  bcache: don't pass BIOSET_NEED_BVECS for the 'bio_set' embedded in
'cache_set'

 block/bio.c   | 116 --
 block/blk-core.c  |   2 +-
 block/blk.h   |   4 ++
 drivers/md/bcache/super.c |   2 +-
 include/linux/bio.h   |   4 +-
 5 files changed, 57 insertions(+), 71 deletions(-)

-- 
2.28.0



[PATCH 3/6] block: don't allocate inline bvecs if this bioset needn't bvecs

2020-12-29 Thread Ming Lei
The inline bvecs won't be used if user needn't bvecs by not passing
BIOSET_NEED_BVECS, so don't allocate bvecs in this situation.

Signed-off-by: Ming Lei 
---
 block/bio.c | 11 +++
 include/linux/bio.h |  1 +
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/block/bio.c b/block/bio.c
index aa657cdd7c8c..3991a5aab1bc 100644
--- a/block/bio.c
+++ b/block/bio.c
@@ -110,7 +110,7 @@ static void bio_put_slab(struct bio_set *bs)
 {
struct bio_slab *bslab = NULL;
unsigned int slab_size = bs->front_pad + sizeof(struct bio) +
-   BIO_INLINE_VECS * sizeof(struct bio_vec);
+   bs->back_pad;
 
mutex_lock(&bio_slab_lock);
 
@@ -1567,15 +1567,18 @@ int bioset_init(struct bio_set *bs,
unsigned int front_pad,
int flags)
 {
-   unsigned int back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec);
-
bs->front_pad = front_pad;
 
+   if (flags & BIOSET_NEED_BVECS)
+   bs->back_pad = BIO_INLINE_VECS * sizeof(struct bio_vec);
+   else
+   bs->back_pad = 0;
+
spin_lock_init(&bs->rescue_lock);
bio_list_init(&bs->rescue_list);
INIT_WORK(&bs->rescue_work, bio_alloc_rescue);
 
-   bs->bio_slab = bio_find_or_create_slab(front_pad + back_pad);
+   bs->bio_slab = bio_find_or_create_slab(bs->front_pad + bs->back_pad);
if (!bs->bio_slab)
return -ENOMEM;
 
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 1edda614f7ce..f606eb1e556f 100644
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -703,6 +703,7 @@ struct bio_set {
mempool_t bvec_integrity_pool;
 #endif
 
+   unsigned int back_pad;
/*
 * Deadlock avoidance for stacking block drivers: see comments in
 * bio_alloc_bioset() for details
-- 
2.28.0



Re: [PATCH v3 0/5] dwmac-meson8b: picosecond precision RX delay support

2020-12-29 Thread Martin Blumenstingl
Hi Jakub,

On Mon, Dec 28, 2020 at 9:37 PM Jakub Kicinski  wrote:
>
> On Thu, 24 Dec 2020 00:29:00 +0100 Martin Blumenstingl wrote:
> > Hello,
> >
> > with the help of Jianxin Pan (many thanks!) the meaning of the "new"
> > PRG_ETH1[19:16] register bits on Amlogic Meson G12A, G12B and SM1 SoCs
> > are finally known. These SoCs allow fine-tuning the RGMII RX delay in
> > 200ps steps (contrary to what I have thought in the past [0] these are
> > not some "calibration" values).
>
> Could you repost in a few days? Net-next is still closed:
sure
I also received a Reviewed-by from Florian on patch #1 so I'll also include that


Best regards,
Martin


[PATCH] fs/buffer: try to submit writeback bio in unit of page

2020-12-29 Thread Ming Lei
It is observed that __block_write_full_page() always submit bio with size of 
block size,
which is often 512 bytes.

In case of sequential IO, or >=4k BS random/seq writeback IO, most of times IO
represented by all buffer_head in each page can be done in single bio. It is 
actually
done in single request IO by block layer's plug merge too.

So check if IO represented by buffer_head can be merged to single page
IO, if yes, just submit single bio instead of submitting one bio for each 
buffer_head.

Cc: Alexander Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: linux-bl...@vger.kernel.org
Cc: Christoph Hellwig 
Cc: Jens Axboe 
Signed-off-by: Ming Lei 
---
 fs/buffer.c | 112 +---
 1 file changed, 90 insertions(+), 22 deletions(-)

diff --git a/fs/buffer.c b/fs/buffer.c
index 32647d2011df..6bcf9ce5d7f8 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -54,6 +54,8 @@
 static int fsync_buffers_list(spinlock_t *lock, struct list_head *list);
 static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
 enum rw_hint hint, struct writeback_control *wbc);
+static int submit_page_wbc(int op, int op_flags, struct buffer_head *bh,
+enum rw_hint hint, struct writeback_control *wbc);
 
 #define BH_ENTRY(list) list_entry((list), struct buffer_head, b_assoc_buffers)
 
@@ -1716,10 +1718,12 @@ int __block_write_full_page(struct inode *inode, struct 
page *page,
int err;
sector_t block;
sector_t last_block;
-   struct buffer_head *bh, *head;
+   struct buffer_head *bh, *head, *prev_bh;
unsigned int blocksize, bbits;
int nr_underway = 0;
int write_flags = wbc_to_write_flags(wbc);
+   unsigned int total_size = 0;
+   bool continuous = true;
 
head = create_page_buffers(page, inode,
(1 << BH_Dirty)|(1 << BH_Uptodate));
@@ -1774,6 +1778,7 @@ int __block_write_full_page(struct inode *inode, struct 
page *page,
block++;
} while (bh != head);
 
+   prev_bh = NULL;
do {
if (!buffer_mapped(bh))
continue;
@@ -1792,9 +1797,17 @@ int __block_write_full_page(struct inode *inode, struct 
page *page,
}
if (test_clear_buffer_dirty(bh)) {
mark_buffer_async_write_endio(bh, handler);
+   total_size += bh->b_size;
} else {
unlock_buffer(bh);
}
+
+   if (continuous && prev_bh && !(
+   prev_bh->b_blocknr + 1 == bh->b_blocknr &&
+   prev_bh->b_bdev == bh->b_bdev &&
+   buffer_meta(prev_bh) == buffer_meta(bh)))
+   continuous = false;
+   prev_bh = bh;
} while ((bh = bh->b_this_page) != head);
 
/*
@@ -1804,15 +1817,21 @@ int __block_write_full_page(struct inode *inode, struct 
page *page,
BUG_ON(PageWriteback(page));
set_page_writeback(page);
 
-   do {
-   struct buffer_head *next = bh->b_this_page;
-   if (buffer_async_write(bh)) {
-   submit_bh_wbc(REQ_OP_WRITE, write_flags, bh,
-   inode->i_write_hint, wbc);
-   nr_underway++;
-   }
-   bh = next;
-   } while (bh != head);
+   if (total_size == PAGE_SIZE && continuous) {
+   submit_page_wbc(REQ_OP_WRITE, write_flags, bh,
+   inode->i_write_hint, wbc);
+   nr_underway = MAX_BUF_PER_PAGE;
+   } else {
+   do {
+   struct buffer_head *next = bh->b_this_page;
+   if (buffer_async_write(bh)) {
+   submit_bh_wbc(REQ_OP_WRITE, write_flags, bh,
+   inode->i_write_hint, wbc);
+   nr_underway++;
+   }
+   bh = next;
+   } while (bh != head);
+   }
unlock_page(page);
 
err = 0;
@@ -3006,8 +3025,28 @@ static void end_bio_bh_io_sync(struct bio *bio)
bio_put(bio);
 }
 
-static int submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,
-enum rw_hint write_hint, struct writeback_control *wbc)
+static void end_bio_page_io_sync(struct bio *bio)
+{
+   struct buffer_head *head = bio->bi_private;
+   struct buffer_head *bh = head;
+
+   do {
+   struct buffer_head *next = bh->b_this_page;
+
+   if (unlikely(bio_flagged(bio, BIO_QUIET)))
+   set_bit(BH_Quiet, &bh->b_state);
+
+   bh->b_end_io(bh, !bio->bi_status);
+   bh = next;
+   } while (bh != head);
+
+   bio_put(bio);
+}
+
+static int __submit_bh_wbc(int op, int op_flags, struct buffer_head *bh,

[PATCH] xfs: Wake CIL push waiters more reliably

2020-12-29 Thread Donald Buczek
Threads, which committed items to the CIL, wait in the xc_push_wait
waitqueue when used_space in the push context goes over a limit. These
threads need to be woken when the CIL is pushed.

The CIL push worker tries to avoid the overhead of calling wake_all()
when there are no waiters waiting. It does so by checking the same
condition which caused the waits to happen. This, however, is
unreliable, because ctx->space_used can actually decrease when items are
recommitted. If the value goes below the limit while some threads are
already waiting but before the push worker gets to it, these threads are
not woken.

Always wake all CIL push waiters. Test with waitqueue_active() as an
optimization. This is possible, because we hold the xc_push_lock
spinlock, which prevents additions to the waitqueue.

Signed-off-by: Donald Buczek 
---
 fs/xfs/xfs_log_cil.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_log_cil.c b/fs/xfs/xfs_log_cil.c
index b0ef071b3cb5..d620de8e217c 100644
--- a/fs/xfs/xfs_log_cil.c
+++ b/fs/xfs/xfs_log_cil.c
@@ -670,7 +670,7 @@ xlog_cil_push_work(
/*
 * Wake up any background push waiters now this context is being pushed.
 */
-   if (ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log))
+   if (waitqueue_active(&cil->xc_push_wait))
wake_up_all(&cil->xc_push_wait);
 
/*
-- 
2.26.2



Re: [PATCH] block: add debugfs stanza for QUEUE_FLAG_NOWAIT.

2020-12-29 Thread Jens Axboe
On 12/28/20 12:27 PM, Andres Freund wrote:
> This was missed in 021a24460dc2. Leads to the numeric value of
> QUEUE_FLAG_NOWAIT (i.e. 29) showing up in
> /sys/kernel/debug/block/*/state.

Applied, thanks.

-- 
Jens Axboe



Re: [PATCH] fs: block_dev.c: fix kernel-doc warnings from struct block_device changes

2020-12-29 Thread Jens Axboe
On 12/28/20 8:47 PM, Randy Dunlap wrote:
> Fix new kernel-doc warnings in fs/block_dev.c:
> 
> ../fs/block_dev.c:1066: warning: Excess function parameter 'whole' 
> description in 'bd_abort_claiming'
> ../fs/block_dev.c:1837: warning: Function parameter or member 'dev' not 
> described in 'lookup_bdev'

Applied, thanks.

-- 
Jens Axboe



Re: [PATCH -next] aoe: Use kzalloc for allocating only one thing

2020-12-29 Thread Jens Axboe
On 12/29/20 6:51 AM, Zheng Yongjun wrote:
> Use kzalloc rather than kcalloc(1,...)
> 
> The semantic patch that makes this change is as follows:
> (http://coccinelle.lip6.fr/)
> 
> // 
> @@
> @@
> 
> - kcalloc(1,
> + kzalloc(
>   ...)
> // 

Should probably fix up that missing set of () while at it.

-- 
Jens Axboe



Re: BTFIDS: FAILED unresolved symbol udp6_sock

2020-12-29 Thread Qais Yousef
Hi Jiri

On 12/29/20 18:34, Jiri Olsa wrote:
> On Tue, Dec 29, 2020 at 03:13:52PM +, Qais Yousef wrote:
> > Hi
> > 
> > When I enable CONFIG_DEBUG_INFO_BTF I get the following error in the BTFIDS
> > stage
> > 
> > FAILED unresolved symbol udp6_sock
> > 
> > I cross compile for arm64. My .config is attached.
> > 
> > I managed to reproduce the problem on v5.9 and v5.10. Plus 5.11-rc1.
> > 
> > Have you seen this before? I couldn't find a specific report about this
> > problem.
> > 
> > Let me know if you need more info.
> 
> hi,
> this looks like symptom of the gcc DWARF bug we were
> dealing with recently:
> 
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97060
>   
> https://lore.kernel.org/lkml/CAE1WUT75gu9G62Q9uAALGN6vLX=o7vz9uhqtvwnbuv81dgm...@mail.gmail.com/#r
> 
> what pahole/gcc version are you using?

I'm on gcc 9.3.0

aarch64-linux-gnu-gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

I was on pahole v1.17. I moved to v1.19 but I still see the same problem.

Thanks

--
Qais Yousef

> 
> we fixed pahole (v1.19) to workaround the issue and AFAIK
> there's already gcc fix as well


  1   2   3   4   5   >