Re: [RESEND][PATCH 2/3] dma-buf: heaps: Add a WARN_ON should the vmap_cnt go negative

[Sumit Semwal]

Hi John, Suren,


On Wed, 20 Jan 2021 at 02:15, John Stultz  wrote:
>
> We shouldn't vunmap more then we vmap, but if we do, make
> sure we complain loudly.

I was checking the general usage of vunmap in the kernel, and I
couldn't find many instances where we need to WARN_ON for the vunmap
count more than vmap count. Is there a specific need for this in the heaps?

Best,
Sumit.
>
> Cc: Sumit Semwal 
> Cc: Liam Mark 
> Cc: Laura Abbott 
> Cc: Brian Starkey 
> Cc: Hridya Valsaraju 
> Cc: Suren Baghdasaryan 
> Cc: Sandeep Patil 
> Cc: Daniel Mentz 
> Cc: Chris Goldsworthy 
> Cc: Ørjan Eide 
> Cc: Robin Murphy 
> Cc: Ezequiel Garcia 
> Cc: Simon Ser 
> Cc: James Jones 
> Cc: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesktop.org
> Suggested-by: Suren Baghdasaryan 
> Signed-off-by: John Stultz 
> ---
>  drivers/dma-buf/heaps/cma_heap.c| 1 +
>  drivers/dma-buf/heaps/system_heap.c | 1 +
>  2 files changed, 2 insertions(+)
>
> diff --git a/drivers/dma-buf/heaps/cma_heap.c 
> b/drivers/dma-buf/heaps/cma_heap.c
> index 364fc2f3e499..0c76cbc3fb11 100644
> --- a/drivers/dma-buf/heaps/cma_heap.c
> +++ b/drivers/dma-buf/heaps/cma_heap.c
> @@ -232,6 +232,7 @@ static void cma_heap_vunmap(struct dma_buf *dmabuf, 
> struct dma_buf_map *map)
> struct cma_heap_buffer *buffer = dmabuf->priv;
>
> mutex_lock(>lock);
> +   WARN_ON(buffer->vmap_cnt == 0);
> if (!--buffer->vmap_cnt) {
> vunmap(buffer->vaddr);
> buffer->vaddr = NULL;
> diff --git a/drivers/dma-buf/heaps/system_heap.c 
> b/drivers/dma-buf/heaps/system_heap.c
> index 405351aad2a8..2321c91891f6 100644
> --- a/drivers/dma-buf/heaps/system_heap.c
> +++ b/drivers/dma-buf/heaps/system_heap.c
> @@ -273,6 +273,7 @@ static void system_heap_vunmap(struct dma_buf *dmabuf, 
> struct dma_buf_map *map)
> struct system_heap_buffer *buffer = dmabuf->priv;
>
> mutex_lock(>lock);
> +   WARN_ON(buffer->vmap_cnt == 0);
> if (!--buffer->vmap_cnt) {
> vunmap(buffer->vaddr);
> buffer->vaddr = NULL;
> --
> 2.17.1
>

[PATCH] MIPS: Make definitions of MIPSInst_FMA_{FUNC,FMTM} consistent with MIPS64 manual

[Tiezhu Yang]

The kernel definitions of MIPSInst_FMA_FUNC and MIPSInst_FMA_FFMT are not
consistent with MADD.fmt, NMADD.fmt and NMSUB.fmt in the MIPS64 manual [1],
the field func is bit 5..3 and fmt is bit 2..0, fix them. Otherwise there
exists error when add new instruction simulation.

[1] https://www.mips.com/?do-download=the-mips64-instruction-set-v6-06

Reported-by: Ming Wang 
Signed-off-by: Tiezhu Yang 
---
 arch/mips/include/asm/inst.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/include/asm/inst.h b/arch/mips/include/asm/inst.h
index 22912f7..2f98ced 100644
--- a/arch/mips/include/asm/inst.h
+++ b/arch/mips/include/asm/inst.h
@@ -65,11 +65,11 @@
 #define I_FR_SFT   21
 #define MIPSInst_FR(x) ((MIPSInst(x) & 0x03e0) >> I_FR_SFT)
 
-#define I_FMA_FUNC_SFT 2
-#define MIPSInst_FMA_FUNC(x) ((MIPSInst(x) & 0x003c) >> I_FMA_FUNC_SFT)
+#define I_FMA_FUNC_SFT 3
+#define MIPSInst_FMA_FUNC(x) ((MIPSInst(x) & 0x0038) >> I_FMA_FUNC_SFT)
 
 #define I_FMA_FFMT_SFT 0
-#define MIPSInst_FMA_FFMT(x) (MIPSInst(x) & 0x0003)
+#define MIPSInst_FMA_FFMT(x) (MIPSInst(x) & 0x0007)
 
 typedef unsigned int mips_instruction;
 
-- 
2.1.0

Re: [PATCH] objtool: Don't fail the kernel build on fatal errors

[Greg KH]

On Thu, Jan 21, 2021 at 08:32:35AM +0100, György Andrasek wrote:
> I'm rejecting both these morons as invalid. Please review everything they've
> been doing lately.

As Stephen said, please take this elsewhere, it does not belong on the
Linux kernel mailing lists.

greg k-h

[rcu:dev.2021.01.19a] BUILD SUCCESS 6c1d51e012c5b474cda77d4fa644d76e041c1e05

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2021.01.19a
branch HEAD: 6c1d51e012c5b474cda77d4fa644d76e041c1e05  kvfree_rcu: Make 
krc_this_cpu_unlock() use raw_spin_unlock_irqrestore()

elapsed time: 724m

configs tested: 86
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc  chrp32_defconfig
sh  rsk7203_defconfig
arm   h3600_defconfig
m68km5407c3_defconfig
sh  sdk7786_defconfig
c6x dsk6455_defconfig
arc  axs101_defconfig
arcvdk_hs38_defconfig
x86_64   alldefconfig
mips  ath79_defconfig
sh  lboxre2_defconfig
powerpc redwood_defconfig
powerpc mpc834x_itx_defconfig
armshmobile_defconfig
um   x86_64_defconfig
arcnsimosci_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a001-20210121
i386 randconfig-a002-20210121
i386 randconfig-a004-20210121
i386 randconfig-a006-20210121
i386 randconfig-a005-20210121
i386 randconfig-a003-20210121
i386 randconfig-a013-20210121
i386 randconfig-a011-20210121
i386 randconfig-a012-20210121
i386 randconfig-a014-20210121
i386 randconfig-a015-20210121
i386 randconfig-a016-20210121
x86_64   randconfig-a002-20210121
x86_64   randconfig-a003-20210121
x86_64   randconfig-a001-20210121
x86_64   randconfig-a005-20210121
x86_64   randconfig-a006-20210121
x86_64   randconfig-a004-20210121
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH 3/3] arm64: dts: zynqmp: Wire up the DisplayPort subsystem

[Laurent Pinchart]

Hi Michal,

On Fri, Jan 22, 2021 at 08:19:15AM +0100, Michal Simek wrote:
> On 1/21/21 11:37 PM, Laurent Pinchart wrote:
> > On Thu, Jan 21, 2021 at 01:36:07PM +0100, Michal Simek wrote:
> >> From: Laurent Pinchart 
> >>
> >> Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
> >> the DisplayPort connector.
> >>
> >> Signed-off-by: Laurent Pinchart 
> >> Signed-off-by: Michal Simek 
> >> ---
> >>
> >> Wire all the boards
> >>
> >> ---
> >>  .../boot/dts/xilinx/zynqmp-zcu100-revC.dts| 31 +++
> >>  .../boot/dts/xilinx/zynqmp-zcu102-revA.dts| 10 ++
> >>  .../boot/dts/xilinx/zynqmp-zcu104-revA.dts| 11 +++
> >>  .../boot/dts/xilinx/zynqmp-zcu104-revC.dts| 11 +++
> >>  .../boot/dts/xilinx/zynqmp-zcu106-revA.dts| 11 +++
> >>  .../boot/dts/xilinx/zynqmp-zcu111-revA.dts| 11 +++
> >>  6 files changed, 85 insertions(+)
> >>
> >> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts 
> >> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> >> index 71ebcaadb7c8..a53598c3624b 100644
> >> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> >> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
> >> @@ -15,6 +15,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  
> >>  / {
> >>model = "ZynqMP ZCU100 RevC";
> >> @@ -108,6 +109,18 @@ ina226 {
> >>compatible = "iio-hwmon";
> >>io-channels = < 0>, < 1>, < 2>, < 3>;
> >>};
> >> +
> >> +  si5335a_0: clk26 {
> >> +  compatible = "fixed-clock";
> >> +  #clock-cells = <0>;
> >> +  clock-frequency = <2600>;
> >> +  };
> >> +
> >> +  si5335a_1: clk27 {
> >> +  compatible = "fixed-clock";
> >> +  #clock-cells = <0>;
> >> +  clock-frequency = <2700>;
> >> +  };
> > 
> > This is fine as a workaround for now, but I'm still wondering how we'll
> > solve this properly. We can declare the SI5335A in DT without wiring the
> > output that provides the clock to the PS, otherwise it will be disabled
> > as part of the boot process.
> 
> All these clock chips are preprogrammed to certain rate and enabled by
> default. It means there doesn't need to be any SW handling to enable it.
> When driver for these clock chips comes we can change this that's why I
> used labels which are saying which output it is.

Unless I'm mistaken, on the ZCU106 board, the chip is an SI5341B, which
has a driver already. I tried to declare it in DT, but the PS_REF_CLK
then got disabled at the end of boot, and the system wasn't happy about
it :-)

-- 
Regards,

Laurent Pinchart

Re: [RFC V2 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback

[Viresh Kumar]

On 19-01-21, 19:05, Ionela Voinescu wrote:
> I think it would improve clarity a lot by having a single topology
> function, with clear comments on which path is taken when.
> 
> In regards to them sharing code, there's not much code they could be
> sharing, as one just does some simple math on provided values.
> I attempted to have a single function for frequency invariance at some
> point [1], as the logic for the computation is the same, but I could
> never convince myself the clarity gained was worth the changes. But
> I really like this version of your code for this purpose as well.
> 
> But I'll leave that to your judgement.

Hmm, I don't really agree to merging those two paths into a single
routine unless we share something there. So I would like to skip that
for now :)

All other comments accepted.

Thanks.

-- 
viresh

Re: [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if max_xfer_blocks is available

[Damien Le Moal]

On 2021/01/22 16:24, Changheun Lee wrote:
>> On 2021/01/20 15:45, Manjong Lee wrote:
>>> Add recipients for more reviews.
>>
>> Please resend instead of replying to your own patch. The reply quoting 
>> corrupts
>> the patch.
>>
>> The patch title is very long.
>>
>>>
 SCSI device has max_xfer_size and opt_xfer_size,
 but current kernel uses only opt_xfer_size.

 It causes the limitation on setting IO chunk size,
 although it can support larger one.

 So, I propose this patch to use max_xfer_size in case it has valid value.
 It can support to use the larger chunk IO on SCSI device.

 For example,
 This patch is effective in case of some SCSI device like UFS
 with opt_xfer_size 512KB, queue depth 32 and max_xfer_size over 512KB.

 I expect both the performance improvement
 and the efficiency use of smaller command queue depth.
>>
>> This can be measured, and this commit message should include results to show 
>> how
>> effective this change is.
>>

 Signed-off-by: Manjong Lee 
 ---
 drivers/scsi/sd.c | 56 +++
 1 file changed, 52 insertions(+), 4 deletions(-)

 diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
 index 679c2c025047..de59f01c1304 100644
 --- a/drivers/scsi/sd.c
 +++ b/drivers/scsi/sd.c
 @@ -3108,6 +3108,53 @@ static void sd_read_security(struct scsi_disk 
 *sdkp, unsigned char *buffer)
 sdkp->security = 1;
 }

 +static bool sd_validate_max_xfer_size(struct scsi_disk *sdkp,
 +unsigned int dev_max)
 +{
 +  struct scsi_device *sdp = sdkp->device;
 +  unsigned int max_xfer_bytes =
 +  logical_to_bytes(sdp, sdkp->max_xfer_blocks);
 +
 +  if (sdkp->max_xfer_blocks == 0)
 +  return false;
 +
 +  if (sdkp->max_xfer_blocks > SD_MAX_XFER_BLOCKS) {
 +  sd_first_printk(KERN_WARNING, sdkp,
 +  "Maximal transfer size %u logical blocks " \
 +  "> sd driver limit (%u logical blocks)\n",
 +  sdkp->max_xfer_blocks, SD_DEF_XFER_BLOCKS);
 +  return false;
 +  }
 +
 +  if (sdkp->max_xfer_blocks > dev_max) {
 +  sd_first_printk(KERN_WARNING, sdkp,
 +  "Maximal transfer size %u logical blocks "
 +  "> dev_max (%u logical blocks)\n",
 +  sdkp->max_xfer_blocks, dev_max);
 +  return false;
 +  }
 +
 +  if (max_xfer_bytes < PAGE_SIZE) {
 +  sd_first_printk(KERN_WARNING, sdkp,
 +  "Maximal transfer size %u bytes < " \
 +  "PAGE_SIZE (%u bytes)\n",
 +  max_xfer_bytes, (unsigned int)PAGE_SIZE);
 +  return false;
 +  }
 +
 +  if (max_xfer_bytes & (sdkp->physical_block_size - 1)) {
 +  sd_first_printk(KERN_WARNING, sdkp,
 +  "Maximal transfer size %u bytes not a " \
 +  "multiple of physical block size (%u bytes)\n",
 +  max_xfer_bytes, sdkp->physical_block_size);
 +  return false;
 +  }
 +
 +  sd_first_printk(KERN_INFO, sdkp, "Maximal transfer size %u bytes\n",
 +  max_xfer_bytes);
 +  return true;
 +}
>>
>> Except for the order of the comparisons against SD_MAX_XFER_BLOCKS and 
>> dev_max,
>> this function looks identical to sd_validate_opt_xfer_size(), modulo the use 
>> of
>> max_xfer_blocks instead of opt_xfer_blocks. Can't you turn this into 
>> something like:
>>
>> static bool sd_validate_max_xfer_size(struct scsi_disk *sdkp,
>> const char *name,
>> unsigned int xfer_blocks,
>> unsigned int dev_max)
>>
>> To allow checking both opt_xfer_blocks and max_xfer_blocks ?
>>
 +
 /*
 * Determine the device's preferred I/O size for reads and writes
 * unless the reported value is unreasonably small, large, not a
 @@ -3233,12 +3280,13 @@ static int sd_revalidate_disk(struct gendisk *disk)

 /* Initial block count limit based on CDB TRANSFER LENGTH field size. */
 dev_max = sdp->use_16_for_rw ? SD_MAX_XFER_BLOCKS : SD_DEF_XFER_BLOCKS;
>>
>> This looks weird: no indentation. Care to resend ?
>>
 -
 -  /* Some devices report a maximum block count for READ/WRITE requests. */
 -  dev_max = min_not_zero(dev_max, sdkp->max_xfer_blocks);
 q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max);

 -  if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
 +  if (sd_validate_max_xfer_size(sdkp, dev_max)) {
 +  q->limits.io_opt = 0;
 +  rw_max = logical_to_sectors(sdp, sdkp->max_xfer_blocks);
 +  q->limits.max_dev_sectors = rw_max;
 +  } else if (sd_validate_opt_xfer_size(sdkp, dev_max)) {

Re: [PATCH 1/6] tty: implement write_iter

[Greg Kroah-Hartman]

On Fri, Jan 22, 2021 at 08:33:33AM +0100, Jiri Slaby wrote:
> On 21. 01. 21, 19:42, Linus Torvalds wrote:
> > On Thu, Jan 21, 2021 at 9:57 AM Greg Kroah-Hartman
> >  wrote:
> > > 
> > > Incremental patches please as these are already in my public branches
> > > and I would have to revert them and add new ones but that's messy, so
> > > fixes on top is fine.
> > 
> > Ok. And since I think you put that first tty_write conversion patch in
> > a different branch from the tty_read one, I did the fixup patches for
> > the two as separate patches, even though they really just do the exact
> > same thing.
> > 
> > So here's three patches: the two fixups for the hung_up_tty case, and
> > the EOVERFLOW error case that Jiri also noted. I've also updated the
> > 'tty-splice' branch if you prefer them that way.
> > 
> > And I *should* say that I still haven't tested _any_ of the HDLC
> > changes. I have no idea how to do that, and if somebody can point to a
> > test-case (or better yet, actually has a real life situation where
> > they use it and can test this all) it would be great.
> > 
> > Jiri, any other issues, or any comment of yours I missed? I didn't do
> > the min() thing, I find the explicit conditional more legible myself,
> > but won't complain if somebody else then disagrees and wants to clean
> > it up.
> 
> I cannot find anything else.
> 
> All three:
> Reviewed-by: Jiri Slaby 

Thanks for the review, I'll go apply these in a bit...

greg k-h

[GIT PULL] OP-TEE driver fix for v5.11

[Jens Wiklander]

Hello arm-soc maintainers,

Please pull this small patch taking care of a rcu_sched trace in some
corner cases when OP-TEE is invoked.

Thanks,
Jens

The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62:

  Linux 5.11-rc2 (2021-01-03 15:55:30 -0800)

are available in the Git repository at:

  git://git.linaro.org/people/jens.wiklander/linux-tee.git 
tags/optee-rcu-sched-trace-for-v5.11

for you to fetch changes up to dcb3b06d9c34f33a249f65c08805461fb0c4325b:

  tee: optee: replace might_sleep with cond_resched (2021-01-21 10:36:48 +0100)


Fix rcu_sched trace from OP-TEE invoke

Replaces might_sleep() with a conditional call to cond_resched()
in order to avoid the rcu_sched trace in some corner cases.


Rouven Czerwinski (1):
  tee: optee: replace might_sleep with cond_resched

 drivers/tee/optee/call.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Re: [PATCH v2] tee: optee: replace might_sleep with cond_resched

[Jens Wiklander]

On Tue, Jan 5, 2021 at 11:29 AM Rouven Czerwinski
 wrote:
>
> might_sleep() is a debugging aid and triggers rescheduling only for
> certain kernel configurations. Replace with an explicit check and
> reschedule to work for all kernel configurations. Fixes the following
> trace:
>
>   [  572.945146] rcu: INFO: rcu_sched self-detected stall on CPU
>   [  572.949275] rcu: 0-: (2099 ticks this GP) idle=572/1/0x4002 
> softirq=7412/7412 fqs=974
>   [  572.957964]  (t=2100 jiffies g=10393 q=21)
>   [  572.962054] NMI backtrace for cpu 0
>   [  572.965540] CPU: 0 PID: 165 Comm: xtest Not tainted 5.8.7 #1
>   [  572.971188] Hardware name: STM32 (Device Tree Support)
>   [  572.976354] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
>   [  572.984080] [] (show_stack) from [] 
> (dump_stack+0xc4/0xd8)
>   [  572.991300] [] (dump_stack) from [] 
> (nmi_cpu_backtrace+0x90/0xc4)
>   [  572.999130] [] (nmi_cpu_backtrace) from [] 
> (nmi_trigger_cpumask_backtrace+0xec/0x130)
>   [  573.008706] [] (nmi_trigger_cpumask_backtrace) from 
> [] (rcu_dump_cpu_stacks+0xe8/0x110)
>   [  573.018453] [] (rcu_dump_cpu_stacks) from [] 
> (rcu_sched_clock_irq+0x7fc/0xa88)
>   [  573.027416] [] (rcu_sched_clock_irq) from [] 
> (update_process_times+0x30/0x8c)
>   [  573.036291] [] (update_process_times) from [] 
> (tick_sched_timer+0x4c/0xa8)
>   [  573.044905] [] (tick_sched_timer) from [] 
> (__hrtimer_run_queues+0x174/0x358)
>   [  573.053696] [] (__hrtimer_run_queues) from [] 
> (hrtimer_interrupt+0x118/0x2bc)
>   [  573.062573] [] (hrtimer_interrupt) from [] 
> (arch_timer_handler_virt+0x28/0x30)
>   [  573.071536] [] (arch_timer_handler_virt) from [] 
> (handle_percpu_devid_irq+0x8c/0x240)
>   [  573.081109] [] (handle_percpu_devid_irq) from [] 
> (generic_handle_irq+0x34/0x44)
>   [  573.090156] [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x5c/0xb0)
>   [  573.098857] [] (__handle_domain_irq) from [] 
> (gic_handle_irq+0x4c/0x90)
>   [  573.107209] [] (gic_handle_irq) from [] 
> (__irq_svc+0x6c/0x90)
>   [  573.114682] Exception stack(0xd90dfcf8 to 0xd90dfd40)
>   [  573.119732] fce0:   
> 0004 
>   [  573.127917] fd00:       
> d93493cc 
>   [  573.136098] fd20: d2bc39c0 be926998 d90dfd58 d90dfd48 c09f3384 c01151f0 
> 400d0013 
>   [  573.144281] [] (__irq_svc) from [] 
> (__arm_smccc_smc+0x10/0x20)
>   [  573.151854] [] (__arm_smccc_smc) from [] 
> (optee_smccc_smc+0x3c/0x44)
>   [  573.159948] [] (optee_smccc_smc) from [] 
> (optee_do_call_with_arg+0xb8/0x154)
>   [  573.168735] [] (optee_do_call_with_arg) from [] 
> (optee_invoke_func+0x110/0x190)
>   [  573.177786] [] (optee_invoke_func) from [] 
> (tee_ioctl+0x10b8/0x11c0)
>   [  573.185879] [] (tee_ioctl) from [] 
> (ksys_ioctl+0xe0/0xa4c)
>   [  573.193101] [] (ksys_ioctl) from [] 
> (ret_fast_syscall+0x0/0x54)
>   [  573.200750] Exception stack(0xd90dffa8 to 0xd90dfff0)
>   [  573.205803] ffa0:   be926bf4 be926a78 0003 8010a403 
> be926908 004e3cf8
>   [  573.213987] ffc0: be926bf4 be926a78  0036 be926908 be926918 
> be9269b0 bffdf0f8
>   [  573.222162] ffe0: b6d76fb0 be9268fc b6d66621 b6c7e0d8
>
> seen on STM32 DK2 with CONFIG_PREEMPT_NONE.
>
> Signed-off-by: Rouven Czerwinski 
> Tested-by: Sumit Garg 
> ---
> v2:
> - Add tested-by from Sumit Garg
> - Adjust commit message as agreed upon with Lucas Stach
>
>  drivers/tee/optee/call.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

I'm picking this up.

Thanks,
Jens

Re: [PATCH v1 2/2] isa: Make the remove callback for isa drivers return void

[Marc Kleine-Budde]

On Thu, Jan 21, 2021 at 09:48:12PM +0100, Uwe Kleine-König wrote:
> The driver core ignores the return value of the remove callback, so
> don't give isa drivers the chance to provide a value.
> 
> Adapt all isa_drivers with a remove callbacks accordingly; they all
> return 0 unconditionally anyhow.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/net/can/sja1000/tscan1.c | 4 +---

For the can driver:

Acked-by: Marc Kleine-Budde 

Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |


signature.asc
Description: PGP signature

Re: [PATCH v4 0/4] OPP API fixes and improvements

[Viresh Kumar]

On 21-01-21, 01:26, Dmitry Osipenko wrote:
> Dmitry Osipenko (4):
>   opp: Export devm_pm_opp_attach_genpd()
>   opp: Add dev_pm_opp_sync_regulators()
>   opp: Add dev_pm_opp_set_voltage()
>   opp: Make _set_opp_custom() work without regulators

Patch 1 and 3 aren't required anymore, I have applied 4th already.
Patch 2 can be applied only after the dependency patch for the stub
definition gets merge in Linus's tree. I see that Mark has already
queued that up in his for-5.11 branch, so it might be part of next
-rc. I will apply 2nd patch then.

-- 
viresh

Re: [PATCH 1/6] tty: implement write_iter

[Jiri Slaby]

On 21. 01. 21, 19:42, Linus Torvalds wrote:

On Thu, Jan 21, 2021 at 9:57 AM Greg Kroah-Hartman
 wrote:


Incremental patches please as these are already in my public branches
and I would have to revert them and add new ones but that's messy, so
fixes on top is fine.


Ok. And since I think you put that first tty_write conversion patch in
a different branch from the tty_read one, I did the fixup patches for
the two as separate patches, even though they really just do the exact
same thing.

So here's three patches: the two fixups for the hung_up_tty case, and
the EOVERFLOW error case that Jiri also noted. I've also updated the
'tty-splice' branch if you prefer them that way.

And I *should* say that I still haven't tested _any_ of the HDLC
changes. I have no idea how to do that, and if somebody can point to a
test-case (or better yet, actually has a real life situation where
they use it and can test this all) it would be great.

Jiri, any other issues, or any comment of yours I missed? I didn't do
the min() thing, I find the explicit conditional more legible myself,
but won't complain if somebody else then disagrees and wants to clean
it up.


I cannot find anything else.

All three:
Reviewed-by: Jiri Slaby 

thanks,
--
js

Re: [PATCH v3 0/4] initrd: Use unified initrd reserve function in ARM/RISCV

[Kefeng Wang]

On 2021/1/18 17:17, Russell King - ARM Linux admin wrote:

On Mon, Jan 18, 2021 at 09:01:40AM +0800, Kefeng Wang wrote:

On 2021/1/17 18:09, Russell King - ARM Linux admin wrote:

On Sun, Jan 17, 2021 at 12:57:55PM +0800, Kefeng Wang wrote:

Correct Russell's mail address (from li...@armlinux.org.uk to
rmk+ker...@armlinux.org.uk, should update the MAINTAINERS)

No. MAINTAINERS is correct.

I got following message,  so I check mail of your recent patches, and send a
new one.

Please ignore it, there may be some other problems.

"*Delivery has failed to these recipients or groups:*

li...@armlinux.org.uk 
A communication failure occurred during the delivery of this message. Please
to resend the message later. If the problem continues, contact your
helpdesk."

That is a most unhelpful bounce message - I suppose it's designed for
non-technical people to ensure that the problem can't be resolved.

>From what I can see from my end, every attempt involving your email
address last week (wangkefeng.w...@huawei.com) has been successful, so
I suspect the problem is not at my end.


ok，thank you for letting me know that the email has been received,

any comment about the ARM part in the patchset  ;)



In any case, all @armlinux.org.uk addresses hit the same server, so
if there's a "communication failure" for the domain, it would affect
all local-parts equally.

Re: linux-next: build warning after merge of the drm tree

[Stephen Rothwell]

Hi Daniel,

On Fri, 22 Jan 2021 08:17:58 +0100 Daniel Vetter  wrote:
> 
> Hm that has been in drm-intel-gt-next for a few days, is that tree not
> in linux-next?

It is not.

These are the drm branches currently in linux-next:

drm-fixes   git://git.freedesktop.org/git/drm/drm.git   drm-fixes
amdgpu-fixesgit://people.freedesktop.org/~agd5f/linux   drm-fixes
drm-intel-fixes git://anongit.freedesktop.org/drm-intel 
for-linux-next-fixes
drm-misc-fixes  git://anongit.freedesktop.org/drm/drm-misc  
for-linux-next-fixes
drm git://git.freedesktop.org/git/drm/drm.git   drm-next
amdgpu  https://gitlab.freedesktop.org/agd5f/linux  drm-next
drm-intel   git://anongit.freedesktop.org/drm-intel for-linux-next
drm-tegra   git://anongit.freedesktop.org/tegra/linux.git   
drm/tegra/for-next
drm-miscgit://anongit.freedesktop.org/drm/drm-misc  for-linux-next
drm-msm https://gitlab.freedesktop.org/drm/msm.git  msm-next
imx-drm https://git.pengutronix.de/git/pza/linuximx-drm/next
etnaviv https://git.pengutronix.de/git/lst/linuxetnaviv/next

-- 
Cheers,
Stephen Rothwell


pgpCS8hXsAj8K.pgp
Description: OpenPGP digital signature

Re: [PATCH v3] can: mcp251xfd: replace sizeof(u32) with val_bytes in regmap

[Marc Kleine-Budde]

On 1/22/21 4:01 AM, Su Yanjun wrote:
> The sizeof(u32) is hardcoded. It's better to use the config value in
> regmap.
> 
> It increases the size of target object, but it's flexible when new mcp chip
> need other val_bytes.
> 
> Signed-off-by: Su Yanjun 
> ---
>  drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c 
> b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> index f07e8b737d31..3dde52669343 100644
> --- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> +++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
> @@ -1308,6 +1308,7 @@ mcp251xfd_tef_obj_read(const struct mcp251xfd_priv 
> *priv,
>  const u8 offset, const u8 len)
>  {
>   const struct mcp251xfd_tx_ring *tx_ring = priv->tx;
> + int val_bytes = regmap_get_val_bytes(priv->map_reg);

You're using the wrong regmap here.

>  
>   if (IS_ENABLED(CONFIG_CAN_MCP251XFD_SANITY) &&
>   (offset > tx_ring->obj_num ||
> @@ -1322,7 +1323,7 @@ mcp251xfd_tef_obj_read(const struct mcp251xfd_priv 
> *priv,
>   return regmap_bulk_read(priv->map_rx,
>   mcp251xfd_get_tef_obj_addr(offset),
>   hw_tef_obj,
> - sizeof(*hw_tef_obj) / sizeof(u32) * len);
> + sizeof(*hw_tef_obj) / val_bytes * len);
>  }
>  
>  static int mcp251xfd_handle_tefif(struct mcp251xfd_priv *priv)
> @@ -1511,11 +1512,12 @@ mcp251xfd_rx_obj_read(const struct mcp251xfd_priv 
> *priv,
> const u8 offset, const u8 len)
>  {
>   int err;
> + int val_bytes = regmap_get_val_bytes(priv->map_reg);

You're using the wrong regmap here.

>  
>   err = regmap_bulk_read(priv->map_rx,
>  mcp251xfd_get_rx_obj_addr(ring, offset),
>  hw_rx_obj,
> -len * ring->obj_size / sizeof(u32));
> +len * ring->obj_size / val_bytes);
>  
>   return err;
>  }
> @@ -2139,6 +2141,7 @@ static irqreturn_t mcp251xfd_irq(int irq, void *dev_id)
>   struct mcp251xfd_priv *priv = dev_id;
>   irqreturn_t handled = IRQ_NONE;
>   int err;
> + int val_bytes = regmap_get_val_bytes(priv->map_reg);
>  
>   if (priv->rx_int)
>   do {
> @@ -2162,7 +2165,7 @@ static irqreturn_t mcp251xfd_irq(int irq, void *dev_id)
>   err = regmap_bulk_read(priv->map_reg, MCP251XFD_REG_INT,
>  >regs_status,
>  sizeof(priv->regs_status) /
> -sizeof(u32));
> +val_bytes);
>   if (err)
>   goto out_fail;
>  
> 

Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3] misc: rtsx: init value of aspm_enabled

[Greg KH]

On Fri, Jan 22, 2021 at 11:33:48AM +0800, ricky...@realtek.com wrote:
> From: Ricky Wu 
> 
> v1:
> make sure ASPM state sync with pcr->aspm_enabled
> init value pcr->aspm_enabled
> v2:
> fixes conditions in v1 if-statement
> v3:
> more description for v1 and v2
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ricky Wu 
> ---
>  drivers/misc/cardreader/rtsx_pcr.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Also, you forgot a "Fixes:" tag.

thanks,

greg k-h

Re: [PATCH v3] misc: rtsx: init value of aspm_enabled

[Greg KH]

On Fri, Jan 22, 2021 at 11:33:48AM +0800, ricky...@realtek.com wrote:
> From: Ricky Wu 
> 
> v1:
> make sure ASPM state sync with pcr->aspm_enabled
> init value pcr->aspm_enabled
> v2:
> fixes conditions in v1 if-statement
> v3:
> more description for v1 and v2

This needs to go below the --- line.

And there is no description of what the patch does anymore :(

Please fix up and do a v4.

thanks,

greg k-h

Re: usb: dwc3: gadget: skip pullup and set_speed after suspend

[Jung Daehwan]

On Fri, Jan 22, 2021 03:32, Wesley cheng wrote:
> Hi Daehwan,
> 
> If this is an unexpected event where userspace initiates the UDC bind
> sequence, then after the above sequence occurs, the DWC3 device should
> still be able to re-enter runtime suspend after the autosuspend timer
> expires.  Since the cable is disconnected, the dwc->connected flag would
> still be false.  Is this not happening in your situation?
> 
> I'm just trying to understand what issue you're seeing other than the
> momentary transition from runtime suspend (due to cable disconnect)
> -->runtime resume (due to unexpected UDC bind) --> runtime  suspend (due
> to nothing connected).
> 
> Thanks
> Wesley cheng

Hi Wesley,

I don't know why but DWC3 device is not re-entering runtime-suspend in
my situation. I'm still debugging it.
Even if DWC3 re-enter runtime-suspend but it doesn't mean stopping gadget.
Are you stopping gadget manually in this case?

Best Regards,
Jung Daehwan

Re: [PATCH v1] can: mcp251xfd: use regmap_bulk_write for compatibility

[Marc Kleine-Budde]

On 1/22/21 4:02 AM, Su Yanjun wrote:
> Recently i use mcp2518fd on 4.x kernel which multiple write is not
> backported, regmap_raw_write will cause old kernel crash because the
> tx buffer in driver is smaller then 2K. Use regmap_bulk_write instead
> for compatibility.

Hmmm, this patch will never be backported to any 4.x kernel, as the driver is
not available on these kernels. You have to carry patches for these kernels
anyway, so I think I'll not take that patch. Sorry. Drop me a note if you are
interested in updating your kernel to a recent v5.11 kernel.

regards,
Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 4/4] opp: Make _set_opp_custom() work without regulators

[Viresh Kumar]

On 21-01-21, 01:26, Dmitry Osipenko wrote:
> Check whether OPP table has regulators in _set_opp_custom() and set up
> dev_pm_set_opp_data accordingly. Now _set_opp_custom() works properly,
> i.e. it doesn't crash if OPP table doesn't have assigned regulators.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/opp/core.c | 26 +-
>  1 file changed, 17 insertions(+), 9 deletions(-)

I have applied this instead:

diff --git a/drivers/opp/core.c b/drivers/opp/core.c
index 32d653774adc..805fc2602808 100644
--- a/drivers/opp/core.c
+++ b/drivers/opp/core.c
@@ -828,24 +828,31 @@ static int _set_opp_custom(const struct opp_table 
*opp_table,
   struct dev_pm_opp_supply *old_supply,
   struct dev_pm_opp_supply *new_supply)
 {
-   struct dev_pm_set_opp_data *data;
+   struct dev_pm_set_opp_data *data = opp_table->set_opp_data;
int size;
 
-   data = opp_table->set_opp_data;
+   /*
+* We support this only if dev_pm_opp_set_regulators() was called
+* earlier.
+*/
+   if (opp_table->sod_supplies) {
+   size = sizeof(*old_supply) * opp_table->regulator_count;
+   if (!old_supply)
+   memset(data->old_opp.supplies, 0, size);
+   else
+   memcpy(data->old_opp.supplies, old_supply, size);
+
+   memcpy(data->new_opp.supplies, new_supply, size);
+   data->regulator_count = opp_table->regulator_count;
+   } else {
+   data->regulator_count = 0;
+   }
+
data->regulators = opp_table->regulators;
-   data->regulator_count = opp_table->regulator_count;
data->clk = opp_table->clk;
data->dev = dev;
-
data->old_opp.rate = old_freq;
-   size = sizeof(*old_supply) * opp_table->regulator_count;
-   if (!old_supply)
-   memset(data->old_opp.supplies, 0, size);
-   else
-   memcpy(data->old_opp.supplies, old_supply, size);
-
data->new_opp.rate = freq;
-   memcpy(data->new_opp.supplies, new_supply, size);
 
return opp_table->set_opp(data);
 }


-- 
viresh

Re: [PATCH 1/1] scsi: sd: use max_xfer_blocks for set rw_max if max_xfer_blocks is available

[Changheun Lee]

> On 2021/01/20 15:45, Manjong Lee wrote:
> > Add recipients for more reviews.
> 
> Please resend instead of replying to your own patch. The reply quoting 
> corrupts
> the patch.
> 
> The patch title is very long.
> 
> > 
> >> SCSI device has max_xfer_size and opt_xfer_size,
> >> but current kernel uses only opt_xfer_size.
> >>
> >> It causes the limitation on setting IO chunk size,
> >> although it can support larger one.
> >>
> >> So, I propose this patch to use max_xfer_size in case it has valid value.
> >> It can support to use the larger chunk IO on SCSI device.
> >>
> >> For example,
> >> This patch is effective in case of some SCSI device like UFS
> >> with opt_xfer_size 512KB, queue depth 32 and max_xfer_size over 512KB.
> >>
> >> I expect both the performance improvement
> >> and the efficiency use of smaller command queue depth.
> 
> This can be measured, and this commit message should include results to show 
> how
> effective this change is.
> 
> >>
> >> Signed-off-by: Manjong Lee 
> >> ---
> >> drivers/scsi/sd.c | 56 +++
> >> 1 file changed, 52 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> >> index 679c2c025047..de59f01c1304 100644
> >> --- a/drivers/scsi/sd.c
> >> +++ b/drivers/scsi/sd.c
> >> @@ -3108,6 +3108,53 @@ static void sd_read_security(struct scsi_disk 
> >> *sdkp, unsigned char *buffer)
> >> sdkp->security = 1;
> >> }
> >>
> >> +static bool sd_validate_max_xfer_size(struct scsi_disk *sdkp,
> >> +unsigned int dev_max)
> >> +{
> >> +  struct scsi_device *sdp = sdkp->device;
> >> +  unsigned int max_xfer_bytes =
> >> +  logical_to_bytes(sdp, sdkp->max_xfer_blocks);
> >> +
> >> +  if (sdkp->max_xfer_blocks == 0)
> >> +  return false;
> >> +
> >> +  if (sdkp->max_xfer_blocks > SD_MAX_XFER_BLOCKS) {
> >> +  sd_first_printk(KERN_WARNING, sdkp,
> >> +  "Maximal transfer size %u logical blocks " \
> >> +  "> sd driver limit (%u logical blocks)\n",
> >> +  sdkp->max_xfer_blocks, SD_DEF_XFER_BLOCKS);
> >> +  return false;
> >> +  }
> >> +
> >> +  if (sdkp->max_xfer_blocks > dev_max) {
> >> +  sd_first_printk(KERN_WARNING, sdkp,
> >> +  "Maximal transfer size %u logical blocks "
> >> +  "> dev_max (%u logical blocks)\n",
> >> +  sdkp->max_xfer_blocks, dev_max);
> >> +  return false;
> >> +  }
> >> +
> >> +  if (max_xfer_bytes < PAGE_SIZE) {
> >> +  sd_first_printk(KERN_WARNING, sdkp,
> >> +  "Maximal transfer size %u bytes < " \
> >> +  "PAGE_SIZE (%u bytes)\n",
> >> +  max_xfer_bytes, (unsigned int)PAGE_SIZE);
> >> +  return false;
> >> +  }
> >> +
> >> +  if (max_xfer_bytes & (sdkp->physical_block_size - 1)) {
> >> +  sd_first_printk(KERN_WARNING, sdkp,
> >> +  "Maximal transfer size %u bytes not a " \
> >> +  "multiple of physical block size (%u bytes)\n",
> >> +  max_xfer_bytes, sdkp->physical_block_size);
> >> +  return false;
> >> +  }
> >> +
> >> +  sd_first_printk(KERN_INFO, sdkp, "Maximal transfer size %u bytes\n",
> >> +  max_xfer_bytes);
> >> +  return true;
> >> +}
> 
> Except for the order of the comparisons against SD_MAX_XFER_BLOCKS and 
> dev_max,
> this function looks identical to sd_validate_opt_xfer_size(), modulo the use 
> of
> max_xfer_blocks instead of opt_xfer_blocks. Can't you turn this into 
> something like:
> 
> static bool sd_validate_max_xfer_size(struct scsi_disk *sdkp,
> const char *name,
> unsigned int xfer_blocks,
> unsigned int dev_max)
> 
> To allow checking both opt_xfer_blocks and max_xfer_blocks ?
> 
> >> +
> >> /*
> >> * Determine the device's preferred I/O size for reads and writes
> >> * unless the reported value is unreasonably small, large, not a
> >> @@ -3233,12 +3280,13 @@ static int sd_revalidate_disk(struct gendisk *disk)
> >>
> >> /* Initial block count limit based on CDB TRANSFER LENGTH field size. */
> >> dev_max = sdp->use_16_for_rw ? SD_MAX_XFER_BLOCKS : SD_DEF_XFER_BLOCKS;
> 
> This looks weird: no indentation. Care to resend ?
> 
> >> -
> >> -  /* Some devices report a maximum block count for READ/WRITE requests. */
> >> -  dev_max = min_not_zero(dev_max, sdkp->max_xfer_blocks);
> >> q->limits.max_dev_sectors = logical_to_sectors(sdp, dev_max);
> >>
> >> -  if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
> >> +  if (sd_validate_max_xfer_size(sdkp, dev_max)) {
> >> +  q->limits.io_opt = 0;
> >> +  rw_max = logical_to_sectors(sdp, sdkp->max_xfer_blocks);
> >> +  q->limits.max_dev_sectors = rw_max;
> >> +  } else if (sd_validate_opt_xfer_size(sdkp, dev_max)) {
> 
> This does not look correct to me. This renders the device 

Re: UBSAN: array-index-out-of-bounds in decode_data

[Marco Elver]

On Thu, 21 Jan 2021 at 19:30, syzbot
 wrote:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:9791581c Merge tag 'for-5.11-rc4-tag' of git://git.kernel...
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13cd09a4d0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=39701af622f054a9
> dashboard link: https://syzkaller.appspot.com/bug?extid=70ba6cae2f44c82dcb76
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=133d8030d0
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+70ba6cae2f44c82dc...@syzkaller.appspotmail.com
>
> 
> UBSAN: array-index-out-of-bounds in drivers/net/hamradio/6pack.c:845:16
> index 400 is out of range for type 'unsigned char [400]'
> CPU: 1 PID: 8 Comm: kworker/u4:0 Not tainted 5.11.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Workqueue: events_unbound flush_to_ldisc
> Call Trace:
>  __dump_stack lib/dump_stack.c:79 [inline]
>  dump_stack+0x107/0x163 lib/dump_stack.c:120
>  ubsan_epilogue+0xb/0x5a lib/ubsan.c:148
>  __ubsan_handle_out_of_bounds.cold+0x62/0x6c lib/ubsan.c:356
>  decode_data.part.0+0x2c8/0x2e0 drivers/net/hamradio/6pack.c:845

It looks like this might be due to a race condition; syzbot had
detected a data race in this code a while back, but it seems this was
never fixed: 
https://lore.kernel.org/lkml/bbb17d05a1954...@google.com/

>  decode_data drivers/net/hamradio/6pack.c:965 [inline]
>  sixpack_decode drivers/net/hamradio/6pack.c:968 [inline]
>  sixpack_receive_buf drivers/net/hamradio/6pack.c:458 [inline]
>  sixpack_receive_buf+0xd8c/0x1320 drivers/net/hamradio/6pack.c:435
>  tty_ldisc_receive_buf+0x14a/0x190 drivers/tty/tty_buffer.c:465
>  tty_port_default_receive_buf+0x6e/0xa0 drivers/tty/tty_port.c:38
>  receive_buf drivers/tty/tty_buffer.c:481 [inline]
>  flush_to_ldisc+0x20d/0x380 drivers/tty/tty_buffer.c:533
>  process_one_work+0x98d/0x15f0 kernel/workqueue.c:2275
>  worker_thread+0x64c/0x1120 kernel/workqueue.c:2421
>  kthread+0x3b1/0x4a0 kernel/kthread.c:292
>  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
> 

Thanks,
-- Marco

Re: [PATCH v1] can: mcp251xfd: Add some sysfs debug interfaces for registers r/w

[Marc Kleine-Budde]

On 1/22/21 7:22 AM, Su Yanjun wrote:
> When i debug mcp2518fd, some method to track registers is
> needed. This easy debug interface will be ok.

NACK

As the driver uses regmap, everything should be there already.

To read use:

| cat /sys/kernel/debug/regmap/spi0.0-crc/registers

Register write support for devices that are handles by proper kernel drivers is
a pure debugging tool, thus not enabled by default, not even with a Kconfig
switch. You have to enable it manually, have a look at commit:

09c6ecd39410 regmap: Add support for writing to regmap registers via debugfs

regards,
Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v10 12/16] dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA support

[kernel test robot]

Hi Sia,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on 9791581c049c10929e97098374dd1716a81fefcc]

url:
https://github.com/0day-ci/linux/commits/Sia-Jee-Heng/dmaengine-dw-axi-dmac-support-Intel-KeemBay-AxiDMA/20210121-143156
base:9791581c049c10929e97098374dd1716a81fefcc
config: s390-randconfig-r013-20210121 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
22b68440e1647e16b5ee24b924986207173c02d1)
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
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390x-linux-gnu
# 
https://github.com/0day-ci/linux/commit/62b1af38b9707f0b5ff771080825f5d2deb9aa39
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Sia-Jee-Heng/dmaengine-dw-axi-dmac-support-Intel-KeemBay-AxiDMA/20210121-143156
git checkout 62b1af38b9707f0b5ff771080825f5d2deb9aa39
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   s390x-linux-gnu-ld: kernel/dma/coherent.o: in function 
`dma_declare_coherent_memory':
   coherent.c:(.text+0x76): undefined reference to `memunmap'
   s390x-linux-gnu-ld: kernel/dma/coherent.o: in function 
`dma_init_coherent_memory':
   coherent.c:(.text+0xd0): undefined reference to `memremap'
   s390x-linux-gnu-ld: coherent.c:(.text+0x19e): undefined reference to 
`memunmap'
   s390x-linux-gnu-ld: drivers/phy/ingenic/phy-ingenic-usb.o: in function 
`ingenic_usb_phy_probe':
   phy-ingenic-usb.c:(.text+0x58): undefined reference to 
`devm_platform_ioremap_resource'
   s390x-linux-gnu-ld: drivers/clk/clk-fixed-mmio.o: in function 
`fixed_mmio_clk_setup':
   clk-fixed-mmio.c:(.text+0x24): undefined reference to `of_iomap'
   s390x-linux-gnu-ld: clk-fixed-mmio.c:(.text+0x36): undefined reference to 
`iounmap'
   s390x-linux-gnu-ld: drivers/dma/altera-msgdma.o: in function 
`request_and_map':
   altera-msgdma.c:(.text+0x566): undefined reference to `devm_ioremap'
   s390x-linux-gnu-ld: drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.o: in 
function `dw_probe':
   dw-axi-dmac-platform.c:(.text+0xc4): undefined reference to 
`devm_ioremap_resource'
>> s390x-linux-gnu-ld: dw-axi-dmac-platform.c:(.text+0xfc): undefined reference 
>> to `devm_platform_ioremap_resource'
   s390x-linux-gnu-ld: drivers/dma/dw/platform.o: in function `dw_probe':
   platform.c:(.text+0x92): undefined reference to 
`devm_platform_ioremap_resource'
   s390x-linux-gnu-ld: drivers/dma/fsl-edma.o: in function `fsl_edma_probe':
   fsl-edma.c:(.text+0xce): undefined reference to `devm_ioremap_resource'
   s390x-linux-gnu-ld: fsl-edma.c:(.text+0x1aa): undefined reference to 
`devm_ioremap_resource'
   s390x-linux-gnu-ld: drivers/dma/idma64.o: in function 
`idma64_platform_probe':
   idma64.c:(.text+0x72): undefined reference to `devm_ioremap_resource'
   s390x-linux-gnu-ld: drivers/soc/litex/litex_soc_ctrl.o: in function 
`litex_soc_ctrl_probe':
   litex_soc_ctrl.c:(.text+0xa8): undefined reference to 
`devm_platform_ioremap_resource'
   s390x-linux-gnu-ld: drivers/pcmcia/cistpl.o: in function `release_cis_mem':
   cistpl.c:(.text+0x82): undefined reference to `iounmap'
   s390x-linux-gnu-ld: drivers/pcmcia/cistpl.o: in function `set_cis_map':
   cistpl.c:(.text+0x3e8): undefined reference to `ioremap'
   s390x-linux-gnu-ld: cistpl.c:(.text+0x41e): undefined reference to `iounmap'
   s390x-linux-gnu-ld: cistpl.c:(.text+0x44a): undefined reference to `iounmap'
   s390x-linux-gnu-ld: cistpl.c:(.text+0x45c): undefined reference to `ioremap'
   s390x-linux-gnu-ld: drivers/input/keyboard/omap4-keypad.o: in function 
`omap4_keypad_probe':
   omap4-keypad.c:(.text+0x156): undefined reference to `ioremap'
   s390x-linux-gnu-ld: omap4-keypad.c:(.text+0x196): undefined reference to 
`iounmap'
   s390x-linux-gnu-ld: drivers/input/keyboard/omap4-keypad.o: in function 
`omap4_keypad_remove':
   omap4-keypad.c:(.text+0x204): undefined reference to `iounmap'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[PATCH] x86/fpu/xstate: Use sizeof() instead of a constant

[Yejune Deng]

In fpstate_sanitize_xstate(), use sizeof() instead of a constant,
at the same time, remove & and [0].

Signed-off-by: Yejune Deng 
---
 arch/x86/kernel/fpu/xstate.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
index 5d8047441a0a..683749b80ae2 100644
--- a/arch/x86/kernel/fpu/xstate.c
+++ b/arch/x86/kernel/fpu/xstate.c
@@ -167,14 +167,14 @@ void fpstate_sanitize_xstate(struct fpu *fpu)
fx->fop = 0;
fx->rip = 0;
fx->rdp = 0;
-   memset(>st_space[0], 0, 128);
+   memset(fx->st_space, 0, sizeof(fx->st_space));
}
 
/*
 * SSE is in init state
 */
if (!(xfeatures & XFEATURE_MASK_SSE))
-   memset(>xmm_space[0], 0, 256);
+   memset(fx->xmm_space, 0, sizeof(fx->xmm_space));
 
/*
 * First two features are FPU and SSE, which above we handled
-- 
2.29.0

Re: [PATCH 3/3] arm64: dts: zynqmp: Wire up the DisplayPort subsystem

[Michal Simek]

Hi Laurent,

On 1/21/21 11:37 PM, Laurent Pinchart wrote:
> Hi Michal,
> 
> Thank you for the patch.
> 
> On Thu, Jan 21, 2021 at 01:36:07PM +0100, Michal Simek wrote:
>> From: Laurent Pinchart 
>>
>> Enable the dpsub device and wire it up to the PS-GTR PHY lanes routed to
>> the DisplayPort connector.
>>
>> Signed-off-by: Laurent Pinchart 
>> Signed-off-by: Michal Simek 
>> ---
>>
>> Wire all the boards
>>
>> ---
>>  .../boot/dts/xilinx/zynqmp-zcu100-revC.dts| 31 +++
>>  .../boot/dts/xilinx/zynqmp-zcu102-revA.dts| 10 ++
>>  .../boot/dts/xilinx/zynqmp-zcu104-revA.dts| 11 +++
>>  .../boot/dts/xilinx/zynqmp-zcu104-revC.dts| 11 +++
>>  .../boot/dts/xilinx/zynqmp-zcu106-revA.dts| 11 +++
>>  .../boot/dts/xilinx/zynqmp-zcu111-revA.dts| 11 +++
>>  6 files changed, 85 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts 
>> b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>> index 71ebcaadb7c8..a53598c3624b 100644
>> --- a/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>> +++ b/arch/arm64/boot/dts/xilinx/zynqmp-zcu100-revC.dts
>> @@ -15,6 +15,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  / {
>>  model = "ZynqMP ZCU100 RevC";
>> @@ -108,6 +109,18 @@ ina226 {
>>  compatible = "iio-hwmon";
>>  io-channels = < 0>, < 1>, < 2>, < 3>;
>>  };
>> +
>> +si5335a_0: clk26 {
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <2600>;
>> +};
>> +
>> +si5335a_1: clk27 {
>> +compatible = "fixed-clock";
>> +#clock-cells = <0>;
>> +clock-frequency = <2700>;
>> +};
> 
> This is fine as a workaround for now, but I'm still wondering how we'll
> solve this properly. We can declare the SI5335A in DT without wiring the
> output that provides the clock to the PS, otherwise it will be disabled
> as part of the boot process.

All these clock chips are preprogrammed to certain rate and enabled by
default. It means there doesn't need to be any SW handling to enable it.
When driver for these clock chips comes we can change this that's why I
used labels which are saying which output it is.

Thanks,
Michal

Re: [PATCH] ver_linux: Eliminate duplicate code in ldconfig processing logic

[Alexander Kapshuk]

On Fri, Jan 8, 2021 at 1:26 PM Alexander Kapshuk
 wrote:
>
> The code that acquires the version strings for libc and libcpp is
> identical, as is the printversion call. The only difference being the
> name of the library being printed.
>
> Refactor the code by unifying the bits that are common to both libraries.
>
> Signed-off-by: Alexander Kapshuk 
> ---
>  scripts/ver_linux | 12 +---
>  1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/scripts/ver_linux b/scripts/ver_linux
> index 0968a3070eff..a92acc703f9b 100755
> --- a/scripts/ver_linux
> +++ b/scripts/ver_linux
> @@ -15,7 +15,7 @@ BEGIN {
>
> vernum = "[0-9]+([.]?[0-9]+)+"
> libc = "libc[.]so[.][0-9]+$"
> -   libcpp = "(libg|stdc)[+]+[.]so[.][0-9]+$"
> +   libcpp = "(libg|stdc)[+]+[.]so([.][0-9]+)+$"
>
> printversion("GNU C", version("gcc -dumpversion"))
> printversion("GNU Make", version("make --version"))
> @@ -37,12 +37,10 @@ BEGIN {
> printversion("Bison", version("bison --version"))
> printversion("Flex", version("flex --version"))
>
> -   while ("ldconfig -p 2>/dev/null" | getline > 0) {
> -   if ($NF ~ libc && !seen[ver = version("readlink " $NF)]++)
> -   printversion("Linux C Library", ver)
> -   else if ($NF ~ libcpp && !seen[ver = version("readlink " 
> $NF)]++)
> -   printversion("Linux C++ Library", ver)
> -   }
> +   while ("ldconfig -p 2>/dev/null" | getline > 0)
> +   if ($NF ~ libc || $NF ~ libcpp)
> +   if (!seen[ver = version("readlink " $NF)]++)
> +   printversion("Linux C" ($NF ~ libcpp? "++" : 
> "") " Library", ver)
>
> printversion("Dynamic linker (ldd)", version("ldd --version"))
> printversion("Procps", version("ps --version"))
> --
> 2.30.0
>

I'd appreciate getting some feedback on the patch in question at your
convenience.

Re: linux-next: build warning after merge of the drm tree

[Daniel Vetter]

On Fri, Jan 22, 2021 at 1:59 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
> produced this warning:
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
>   Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && 
> !COMPILE_TEST [=y]
>   Selected by [m]:
>   - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
>   Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && 
> !COMPILE_TEST [=y]
>   Selected by [m]:
>   - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
>
> WARNING: unmet direct dependencies detected for DRM_I915_WERROR
>   Depends on [n]: HAS_IOMEM [=y] && DRM_I915 [=m] && EXPERT [=y] && 
> !COMPILE_TEST [=y]
>   Selected by [m]:
>   - DRM_I915_DEBUG [=y] && HAS_IOMEM [=y] && EXPERT [=y] && DRM_I915 [=m]
>
> Maybe introduced by commit
>
>   4f86975f539d ("drm/i915: Add DEBUG_GEM to the recommended CI config")

Hm that has been in drm-intel-gt-next for a few days, is that tree not
in linux-next?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] powerpc/32: Use r2 in wrtspr() instead of r0

[Christophe Leroy]

wrtspr() is a function to write an arbitrary value in a special
register. It is used on 8xx to write to SPRN_NRI, SPRN_EID and
SPRN_EIE. Writing any value to one of those will play with MSR EE
and MSR RI regardless of that value.

r0 is used many places in the generated code and using r0 for
that creates an unnecessary dependency of this instruction with
preceding ones using r0 in a few places in vmlinux.

r2 is most likely the most stable register as it contains the
pointer to 'current'.

Using r2 instead of r0 avoids that unnecessary dependency.

Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/reg.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
index e40a921d78f9..32a9020e93ab 100644
--- a/arch/powerpc/include/asm/reg.h
+++ b/arch/powerpc/include/asm/reg.h
@@ -1392,8 +1392,7 @@ static inline void mtmsr_isync(unsigned long val)
 : "r" ((unsigned long)(v)) \
 : "memory")
 #endif
-#define wrtspr(rn) asm volatile("mtspr " __stringify(rn) ",0" : \
-: : "memory")
+#define wrtspr(rn) asm volatile("mtspr " __stringify(rn) ",2" : : : 
"memory")
 
 static inline void wrtee(unsigned long val)
 {
-- 
2.25.0

Re: [PATCH v4 1/4] mm: rename memmap_init() and memmap_init_zone()

[Baoquan He]

On 01/20/21 at 11:47pm, kernel test robot wrote:
> Hi Baoquan,
> 
> I love your patch! Perhaps something to improve:
> 
> [auto build test WARNING on linux/master]
> [also build test WARNING on linus/master v5.11-rc4 next-20210120]
> [cannot apply to mmotm/master hnaz-linux-mm/master ia64/next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]
> 
> url:
> https://github.com/0day-ci/linux/commits/Baoquan-He/mm-clean-up-names-and-parameters-of-memmap_init_-functions/20210120-135239
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> 1e2a199f6ccdc15cf111d68d212e2fd4ce65682e
> config: mips-randconfig-r036-20210120 (attached as .config)
> compiler: mips-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://github.com/0day-ci/linux/commit/1bbb0b35dd2fae4a7a38098e63899677c2e53108
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Baoquan-He/mm-clean-up-names-and-parameters-of-memmap_init_-functions/20210120-135239
> git checkout 1bbb0b35dd2fae4a7a38098e63899677c2e53108
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
> ARCH=mips 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All warnings (new ones prefixed by >>):
> 
>mm/page_alloc.c:3597:15: warning: no previous prototype for 
> 'should_fail_alloc_page' [-Wmissing-prototypes]
> 3597 | noinline bool should_fail_alloc_page(gfp_t gfp_mask, unsigned int 
> order)
>  |   ^~
> >> mm/page_alloc.c:6258:23: warning: no previous prototype for 
> >> 'memmap_init_zone' [-Wmissing-prototypes]
> 6258 | void __meminit __weak memmap_init_zone(unsigned long size, int nid,
>  |   ^~~~

Have posted a patch to fix this warning as below. The patch is based on
this patchset.

https://lore.kernel.org/linux-mm/20210122070359.24010-1-...@redhat.com/

Thanks
Baoquan

[PATCH v7 2/7] crypto: hisilicon/hpre - add some updates to adapt to Kunpeng 930

[Meng Yu]

From: Hui Tang 

HPRE of Kunpeng 930 is updated on cluster numbers and configurations
of Kunpeng 920 HPRE, so we try to update this driver to make it running
okay on both chips.

Signed-off-by: Hui Tang 
Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 drivers/crypto/hisilicon/hpre/hpre.h  |  8 ++-
 drivers/crypto/hisilicon/hpre/hpre_main.c | 93 +--
 2 files changed, 68 insertions(+), 33 deletions(-)

diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index e784712..cc50f23 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -14,8 +14,7 @@ enum {
HPRE_CLUSTER0,
HPRE_CLUSTER1,
HPRE_CLUSTER2,
-   HPRE_CLUSTER3,
-   HPRE_CLUSTERS_NUM,
+   HPRE_CLUSTER3
 };
 
 enum hpre_ctrl_dbgfs_file {
@@ -36,7 +35,10 @@ enum hpre_dfx_dbgfs_file {
HPRE_DFX_FILE_NUM
 };
 
-#define HPRE_DEBUGFS_FILE_NUM(HPRE_DEBUG_FILE_NUM + HPRE_CLUSTERS_NUM - 1)
+#define HPRE_CLUSTERS_NUM_V2   (HPRE_CLUSTER3 + 1)
+#define HPRE_CLUSTERS_NUM_V3   1
+#define HPRE_CLUSTERS_NUM_MAX  HPRE_CLUSTERS_NUM_V2
+#define HPRE_DEBUGFS_FILE_NUM (HPRE_DEBUG_FILE_NUM + HPRE_CLUSTERS_NUM_MAX - 1)
 
 struct hpre_debugfs_file {
int index;
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c 
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index ad8b691..52827b0 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -30,6 +30,8 @@
 #define HPRE_BD_ARUSR_CFG  0x301030
 #define HPRE_BD_AWUSR_CFG  0x301034
 #define HPRE_TYPES_ENB 0x301038
+#define HPRE_RSA_ENB   BIT(0)
+#define HPRE_ECC_ENB   BIT(1)
 #define HPRE_DATA_RUSER_CFG0x30103c
 #define HPRE_DATA_WUSER_CFG0x301040
 #define HPRE_INT_MASK  0x301400
@@ -74,7 +76,8 @@
 #define HPRE_QM_AXI_CFG_MASK   0x
 #define HPRE_QM_VFG_AX_MASK0xff
 #define HPRE_BD_USR_MASK   0x3
-#define HPRE_CLUSTER_CORE_MASK 0xf
+#define HPRE_CLUSTER_CORE_MASK_V2  0xf
+#define HPRE_CLUSTER_CORE_MASK_V3  0xff
 
 #define HPRE_AM_OOO_SHUTDOWN_ENB   0x301044
 #define HPRE_AM_OOO_SHUTDOWN_ENABLEBIT(0)
@@ -87,6 +90,11 @@
 #define HPRE_QM_PM_FLR BIT(11)
 #define HPRE_QM_SRIOV_FLR  BIT(12)
 
+#define HPRE_CLUSTERS_NUM(qm)  \
+   (((qm)->ver >= QM_HW_V3) ? HPRE_CLUSTERS_NUM_V3 : HPRE_CLUSTERS_NUM_V2)
+#define HPRE_CLUSTER_CORE_MASK(qm) \
+   (((qm)->ver >= QM_HW_V3) ? HPRE_CLUSTER_CORE_MASK_V3 :\
+   HPRE_CLUSTER_CORE_MASK_V2)
 #define HPRE_VIA_MSI_DSM   1
 #define HPRE_SQE_MASK_OFFSET   8
 #define HPRE_SQE_MASK_LEN  24
@@ -276,8 +284,40 @@ static int hpre_cfg_by_dsm(struct hisi_qm *qm)
return 0;
 }
 
+static int hpre_set_cluster(struct hisi_qm *qm)
+{
+   u32 cluster_core_mask = HPRE_CLUSTER_CORE_MASK(qm);
+   u8 clusters_num = HPRE_CLUSTERS_NUM(qm);
+   struct device *dev = >pdev->dev;
+   unsigned long offset;
+   u32 val = 0;
+   int ret, i;
+
+   for (i = 0; i < clusters_num; i++) {
+   offset = i * HPRE_CLSTR_ADDR_INTRVL;
+
+   /* clusters initiating */
+   writel(cluster_core_mask,
+  HPRE_ADDR(qm, offset + HPRE_CORE_ENB));
+   writel(0x1, HPRE_ADDR(qm, offset + HPRE_CORE_INI_CFG));
+   ret = readl_relaxed_poll_timeout(HPRE_ADDR(qm, offset +
+   HPRE_CORE_INI_STATUS), val,
+   ((val & cluster_core_mask) ==
+   cluster_core_mask),
+   HPRE_REG_RD_INTVRL_US,
+   HPRE_REG_RD_TMOUT_US);
+   if (ret) {
+   dev_err(dev,
+   "cluster %d int st status timeout!\n", i);
+   return -ETIMEDOUT;
+   }
+   }
+
+   return 0;
+}
+
 /*
- * For Hi1620, we shoul disable FLR triggered by hardware (BME/PM/SRIOV).
+ * For Kunpeng 920, we shoul disable FLR triggered by hardware (BME/PM/SRIOV).
  * Or it may stay in D3 state when we bind and unbind hpre quickly,
  * as it does FLR triggered by hardware.
  */
@@ -295,9 +335,8 @@ static void disable_flr_of_bme(struct hisi_qm *qm)
 static int hpre_set_user_domain_and_cache(struct hisi_qm *qm)
 {
struct device *dev = >pdev->dev;
-   unsigned long offset;
-   int ret, i;
u32 val;
+   int ret;
 
writel(HPRE_QM_USR_CFG_MASK, HPRE_ADDR(qm, QM_ARUSER_M_CFG_ENABLE));
writel(HPRE_QM_USR_CFG_MASK, HPRE_ADDR(qm, QM_AWUSER_M_CFG_ENABLE));
@@ -308,7 +347,12 @@ static int hpre_set_user_domain_and_cache(struct hisi_qm 
*qm)
val |= BIT(HPRE_TIMEOUT_ABNML_BIT);
writel_relaxed(val, 

[PATCH v7 6/7] crypto: hisilicon/hpre - add 'ECDH' algorithm

[Meng Yu]

1. Enable 'ECDH' algorithm in Kunpeng 930;
2. HPRE ECDH Support ECC curve: P192, P224, P256, P384, P521.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 drivers/crypto/hisilicon/hpre/hpre.h|   2 +-
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 493 +++-
 drivers/crypto/hisilicon/hpre/hpre_main.c   |   1 +
 3 files changed, 491 insertions(+), 5 deletions(-)

diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index 02193e1..50e6b2e 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -83,6 +83,7 @@ enum hpre_alg_type {
HPRE_ALG_KG_CRT = 0x3,
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
+   HPRE_ALG_ECC_MUL = 0xD,
 };
 
 struct hpre_sqe {
@@ -104,5 +105,4 @@ struct hisi_qp *hpre_create_qp(u8 type);
 int hpre_algs_register(struct hisi_qm *qm);
 void hpre_algs_unregister(struct hisi_qm *qm);
 
-
 #endif
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 712bea9..778a0057 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -2,6 +2,8 @@
 /* Copyright (c) 2019 HiSilicon Limited. */
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -36,6 +38,20 @@ struct hpre_ctx;
 #define HPRE_DFX_SEC_TO_US 100
 #define HPRE_DFX_US_TO_NS  1000
 
+/* size in bytes of the n prime */
+#define HPRE_ECC_NIST_P192_N_SIZE  24
+#define HPRE_ECC_NIST_P224_N_SIZE  28
+#define HPRE_ECC_NIST_P256_N_SIZE  32
+#define HPRE_ECC_NIST_P384_N_SIZE  48
+#define HPRE_ECC_NIST_P521_N_SIZE  66
+
+/* size in bytes */
+#define HPRE_ECC_HW256_KSZ_B   32
+#define HPRE_ECC_HW384_KSZ_B   48
+#define HPRE_ECC_HW576_KSZ_B   72
+
+#define HPRE_ECDH_MAX_SZ   HPRE_ECC_HW576_KSZ_B
+
 typedef void (*hpre_cb)(struct hpre_ctx *ctx, void *sqe);
 
 struct hpre_rsa_ctx {
@@ -61,14 +77,25 @@ struct hpre_dh_ctx {
 * else if base if the counterpart public key we
 * compute the shared secret
 *  ZZ = yb^xa mod p; [RFC2631 sec 2.1.1]
+* low address: d--->n, please refer to Hisilicon HPRE UM
 */
-   char *xa_p; /* low address: d--->n, please refer to Hisilicon HPRE UM */
+   char *xa_p;
dma_addr_t dma_xa_p;
 
char *g; /* m */
dma_addr_t dma_g;
 };
 
+struct hpre_ecdh_ctx {
+   /* low address: p->a->k->b */
+   unsigned char *p;
+   dma_addr_t dma_p;
+
+   /* low address: x->y */
+   unsigned char *g;
+   dma_addr_t dma_g;
+};
+
 struct hpre_ctx {
struct hisi_qp *qp;
struct hpre_asym_request **req_list;
@@ -80,7 +107,10 @@ struct hpre_ctx {
union {
struct hpre_rsa_ctx rsa;
struct hpre_dh_ctx dh;
+   struct hpre_ecdh_ctx ecdh;
};
+   /* for ecc algorithms */
+   unsigned int curve_id;
 };
 
 struct hpre_asym_request {
@@ -91,6 +121,7 @@ struct hpre_asym_request {
union {
struct akcipher_request *rsa;
struct kpp_request *dh;
+   struct kpp_request *ecdh;
} areq;
int err;
int req_id;
@@ -1115,6 +1146,428 @@ static void hpre_rsa_exit_tfm(struct crypto_akcipher 
*tfm)
crypto_free_akcipher(ctx->rsa.soft_tfm);
 }
 
+static void hpre_key_to_big_end(u8 *data, int len)
+{
+   int i, j;
+   u8 tmp;
+
+   for (i = 0; i < len / 2; i++) {
+   j = len - i - 1;
+   tmp = data[j];
+   data[j] = data[i];
+   data[i] = tmp;
+   }
+}
+
+static void hpre_ecc_clear_ctx(struct hpre_ctx *ctx, bool is_clear_all,
+  bool is_ecdh)
+{
+   struct device *dev = HPRE_DEV(ctx);
+   unsigned int sz = ctx->key_sz;
+   unsigned int shift = sz << 1;
+
+   if (is_clear_all)
+   hisi_qm_stop_qp(ctx->qp);
+
+   if (is_ecdh && ctx->ecdh.p) {
+   /* ecdh: p->a->k->b */
+   memzero_explicit(ctx->ecdh.p + shift, sz);
+   dma_free_coherent(dev, sz << 3, ctx->ecdh.p, ctx->ecdh.dma_p);
+   ctx->ecdh.p = NULL;
+   }
+
+   ctx->curve_id = 0;
+   hpre_ctx_clear(ctx, is_clear_all);
+}
+
+/*
+ * The bits of 192/224/256/384/521 are supported by HPRE,
+ * and convert the bits like:
+ * bits<=256, bits=256; 256key_sz << 1;
+   unsigned int shiftb = ctx->key_sz << 2;
+   void *p = ctx->ecdh.p + ctx->key_sz - cur_sz;
+   void *a = ctx->ecdh.p + shifta - cur_sz;
+   void *b = ctx->ecdh.p + shiftb - cur_sz;
+   void *x = ctx->ecdh.g + ctx->key_sz - cur_sz;
+   void *y = ctx->ecdh.g + shifta - cur_sz;
+   const struct ecc_curve *curve;
+   char *n;
+
+   n = kzalloc(ctx->key_sz, GFP_KERNEL);
+   if (unlikely(!n))
+   return -ENOMEM;
+
+   curve = ecc_get_curve_by_id(params->curve_id);
+   if (unlikely(!curve))
+ 

[PATCH v7 4/7] crypto: add ecc curve and expose them

[Meng Yu]

1. Add ecc curves(P224, P384, P521) for ECDH;
2. Reorder ECC 'Curves ID' in 'include/crypto/ecdh.h', and
   modify 'curve_id' used in 'testmgr.h';
3. Add function 'ecc_get_curve_param' in 'include/crypto/ecc_curve.h' for
   users, so everyone in the kernel tree can easily get ecc curve params;

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
Reported-by: kernel test robot 
---
 crypto/ecc.c   |  15 -
 crypto/ecc.h   |  37 +--
 crypto/ecc_curve_defs.h| 152 ++---
 crypto/testmgr.h   |  12 ++--
 include/crypto/ecc_curve.h |  53 
 include/crypto/ecdh.h  |   5 +-
 6 files changed, 207 insertions(+), 67 deletions(-)
 create mode 100644 include/crypto/ecc_curve.h

diff --git a/crypto/ecc.c b/crypto/ecc.c
index c80aa25..cfa1dc3 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -24,6 +24,7 @@
  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -42,14 +43,24 @@ typedef struct {
u64 m_high;
 } uint128_t;
 
+/* Returns CURVE if get curve succssful, NULL otherwise */
+const struct ecc_curve *ecc_get_curve_by_id(unsigned int curve_id)
+{
+   if (curve_id >= ECC_CURVE_NIST_P192 && curve_id <= ECC_CURVE_NIST_P521)
+   return _curve_list[curve_id - 1];
+
+   return NULL;
+}
+EXPORT_SYMBOL(ecc_get_curve_by_id);
+
 static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
 {
switch (curve_id) {
/* In FIPS mode only allow P256 and higher */
case ECC_CURVE_NIST_P192:
-   return fips_enabled ? NULL : _p192;
+   return fips_enabled ? NULL : ecc_get_curve_by_id(curve_id);
case ECC_CURVE_NIST_P256:
-   return _p256;
+   return ecc_get_curve_by_id(curve_id);
default:
return NULL;
}
diff --git a/crypto/ecc.h b/crypto/ecc.h
index d4e546b..38a81d4 100644
--- a/crypto/ecc.h
+++ b/crypto/ecc.h
@@ -26,6 +26,8 @@
 #ifndef _CRYPTO_ECC_H
 #define _CRYPTO_ECC_H
 
+#include 
+
 /* One digit is u64 qword. */
 #define ECC_CURVE_NIST_P192_DIGITS  3
 #define ECC_CURVE_NIST_P256_DIGITS  4
@@ -33,44 +35,9 @@
 
 #define ECC_DIGITS_TO_BYTES_SHIFT 3
 
-/**
- * struct ecc_point - elliptic curve point in affine coordinates
- *
- * @x: X coordinate in vli form.
- * @y: Y coordinate in vli form.
- * @ndigits:   Length of vlis in u64 qwords.
- */
-struct ecc_point {
-   u64 *x;
-   u64 *y;
-   u8 ndigits;
-};
-
 #define ECC_POINT_INIT(x, y, ndigits)  (struct ecc_point) { x, y, ndigits }
 
 /**
- * struct ecc_curve - definition of elliptic curve
- *
- * @name:  Short name of the curve.
- * @g: Generator point of the curve.
- * @p: Prime number, if Barrett's reduction is used for this curve
- * pre-calculated value 'mu' is appended to the @p after ndigits.
- * Use of Barrett's reduction is heuristically determined in
- * vli_mmod_fast().
- * @n: Order of the curve group.
- * @a: Curve parameter a.
- * @b: Curve parameter b.
- */
-struct ecc_curve {
-   char *name;
-   struct ecc_point g;
-   u64 *p;
-   u64 *n;
-   u64 *a;
-   u64 *b;
-};
-
-/**
  * ecc_is_key_valid() - Validate a given ECDH private key
  *
  * @curve_id:  id representing the curve to use
diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h
index 69be6c7..b81e580 100644
--- a/crypto/ecc_curve_defs.h
+++ b/crypto/ecc_curve_defs.h
@@ -15,18 +15,20 @@ static u64 nist_p192_a[] = { 0xFFFCull, 
0xFFFEull,
0xull };
 static u64 nist_p192_b[] = { 0xFEB8DEECC146B9B1ull, 0x0FA7E9AB72243049ull,
0x64210519E59C80E7ull };
-static struct ecc_curve nist_p192 = {
-   .name = "nist_192",
-   .g = {
-   .x = nist_p192_g_x,
-   .y = nist_p192_g_y,
-   .ndigits = 3,
-   },
-   .p = nist_p192_p,
-   .n = nist_p192_n,
-   .a = nist_p192_a,
-   .b = nist_p192_b
-};
+
+/* NIST P-224 */
+static u64 nist_p224_g_x[] = { 0x343280D6115C1D21ull, 0x4A03C1D356C21122ull,
+   0x6BB4BF7F321390B9ull, 0xB70E0CBDull };
+static u64 nist_p224_g_y[] = { 0x44d5819985007e34ull, 0xcd4375a05a074764ull,
+   0xb5f723fb4c22dfe6ull, 0xbd376388ull };
+static u64 nist_p224_p[] = { 0x0001ull, 0xull,
+   0xull, 0xull };
+static u64 nist_p224_n[] = { 0x13DD29455C5C2A3Dull, 0x16A2E0B8F03Eull,
+   0xull, 0xull };
+static u64 nist_p224_a[] = { 0xFFFEull, 0xFFFEull,
+   0xull, 0xull };
+static u64 nist_p224_b[] = { 0x270B39432355FFB4ull, 

[PATCH v7 5/7] crypto: add curve 25519 and expose them

[Meng Yu]

1. Add curve 25519 parameters;
2. Add curve25519 function 'ecc_get_curve25519_param',
   to be exposed to everyone in kernel tree.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 crypto/ecc.c   |  7 +++
 crypto/ecc_curve_defs.h| 17 +
 include/crypto/ecc_curve.h |  7 +++
 3 files changed, 31 insertions(+)

diff --git a/crypto/ecc.c b/crypto/ecc.c
index cfa1dc3..025b5e6e 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -53,6 +53,13 @@ const struct ecc_curve *ecc_get_curve_by_id(unsigned int 
curve_id)
 }
 EXPORT_SYMBOL(ecc_get_curve_by_id);
 
+/* Returns curv25519 curve param */
+const struct ecc_curve *ecc_get_curve25519(void)
+{
+   return _25519;
+}
+EXPORT_SYMBOL(ecc_get_curve25519);
+
 static inline const struct ecc_curve *ecc_get_curve(unsigned int curve_id)
 {
switch (curve_id) {
diff --git a/crypto/ecc_curve_defs.h b/crypto/ecc_curve_defs.h
index b81e580..91b3d4b 100644
--- a/crypto/ecc_curve_defs.h
+++ b/crypto/ecc_curve_defs.h
@@ -160,4 +160,21 @@ static const struct ecc_curve ecc_curve_list[] = {
}
 };
 
+/* curve25519 */
+static u64 curve25519_g_x[] = { 0x0009, 0x,
+   0x, 0x };
+static u64 curve25519_p[] = { 0xffed, 0x,
+   0x, 0x7fff };
+static u64 curve25519_a[] = { 0x0001DB41, 0x,
+0x, 0x };
+static const struct ecc_curve ecc_25519 = {
+   .name = "curve25519",
+   .g = {
+   .x = curve25519_g_x,
+   .ndigits = 4,
+   },
+   .p = curve25519_p,
+   .a = curve25519_a,
+};
+
 #endif
diff --git a/include/crypto/ecc_curve.h b/include/crypto/ecc_curve.h
index a3adf1e..2d22647 100644
--- a/include/crypto/ecc_curve.h
+++ b/include/crypto/ecc_curve.h
@@ -50,4 +50,11 @@ struct ecc_curve {
  */
 const struct ecc_curve *ecc_get_curve_by_id(unsigned int curve_id);
 
+/**
+ * ecc_get_curve25519() - get curve25519 curve;
+ *
+ * Returns curve25519
+ */
+const struct ecc_curve *ecc_get_curve25519(void);
+
 #endif
\ No newline at end of file
-- 
2.8.1

[PATCH v7 0/7] add ECDH and CURVE25519 algorithms support for Kunpeng 930

[Meng Yu]

1. Add some new elliptic curve parameters definitions, and reorder
   ECC 'Curves IDs';
2. Add interface to get elliptic curve by curve_id in
   "include/crypto/ecc_curve.h" by curve_id;
3. Add ECDH and CURVE25519 algorithms support for Kunpeng 930.

v6->v7:
- patch #4: add function interface to expose elliptic curve parameters
- patch #4: eliminate warning by 'kernel test robot'
- patch #5: add function interface to expose curve25519 parameters

v5->v6:
- patch #1: add a new patch (the first patch), which is the "depend on" patch 
before

v4->v5:
- patch #4: delete P-128 and P-320 curve, as the few using case in the kernel

v3 -> v4:
- patch #3: add new, move ecc_curve params to "include/crypto"

v2 -> v3:
- patch #5: fix sparse warnings
- patch #5: add 'CRYPTO_LIB_CURVE25519_GENERIC' in 'Kconfig'

v1 -> v2:
- patch #5: delete `curve25519_null_point'


Hui Tang (1):
  crypto: hisilicon/hpre - add some updates to adapt to Kunpeng 930

Meng Yu (6):
  crypto: hisilicon/hpre - add version adapt to new algorithms
  crypto: hisilicon/hpre - add algorithm type
  crypto: add ecc curve and expose them
  crypto: add curve 25519 and expose them
  crypto: hisilicon/hpre - add 'ECDH' algorithm
  crypto: hisilicon/hpre - add 'CURVE25519' algorithm

 crypto/ecc.c|  22 +-
 crypto/ecc.h|  37 +-
 crypto/ecc_curve_defs.h | 163 +-
 crypto/testmgr.h|  12 +-
 drivers/crypto/hisilicon/Kconfig|   1 +
 drivers/crypto/hisilicon/hpre/hpre.h|  25 +-
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 861 +++-
 drivers/crypto/hisilicon/hpre/hpre_main.c   | 105 ++--
 drivers/crypto/hisilicon/qm.c   |   4 +-
 drivers/crypto/hisilicon/qm.h   |   4 +-
 drivers/crypto/hisilicon/sec2/sec.h |   4 +-
 drivers/crypto/hisilicon/sec2/sec_crypto.c  |   4 +-
 drivers/crypto/hisilicon/sec2/sec_crypto.h  |   4 +-
 drivers/crypto/hisilicon/zip/zip.h  |   4 +-
 drivers/crypto/hisilicon/zip/zip_crypto.c   |   4 +-
 include/crypto/ecc_curve.h  |  60 ++
 include/crypto/ecdh.h   |   5 +-
 17 files changed, 1191 insertions(+), 128 deletions(-)
 create mode 100644 include/crypto/ecc_curve.h

-- 
2.8.1

[PATCH v7 3/7] crypto: hisilicon/hpre - add algorithm type

[Meng Yu]

Algorithm type is brought in to get hardware HPRE queue
to support different algorithms.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 drivers/crypto/hisilicon/hpre/hpre.h| 10 +-
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 12 ++--
 drivers/crypto/hisilicon/hpre/hpre_main.c   | 11 +--
 3 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index cc50f23..02193e1 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -10,6 +10,14 @@
 #define HPRE_PF_DEF_Q_NUM  64
 #define HPRE_PF_DEF_Q_BASE 0
 
+/*
+ * type used in qm sqc DW6.
+ * 0 - Algorithm which has been supported in V2, like RSA, DH and so on;
+ * 1 - ECC algorithm in V3.
+ */
+#define HPRE_V2_ALG_TYPE   0
+#define HPRE_V3_ECC_ALG_TYPE   1
+
 enum {
HPRE_CLUSTER0,
HPRE_CLUSTER1,
@@ -92,7 +100,7 @@ struct hpre_sqe {
__le32 rsvd1[_HPRE_SQE_ALIGN_EXT];
 };
 
-struct hisi_qp *hpre_create_qp(void);
+struct hisi_qp *hpre_create_qp(u8 type);
 int hpre_algs_register(struct hisi_qm *qm);
 void hpre_algs_unregister(struct hisi_qm *qm);
 
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index d89b2f5..712bea9 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -152,12 +152,12 @@ static void hpre_rm_req_from_ctx(struct hpre_asym_request 
*hpre_req)
}
 }
 
-static struct hisi_qp *hpre_get_qp_and_start(void)
+static struct hisi_qp *hpre_get_qp_and_start(u8 type)
 {
struct hisi_qp *qp;
int ret;
 
-   qp = hpre_create_qp();
+   qp = hpre_create_qp(type);
if (!qp) {
pr_err("Can not create hpre qp!\n");
return ERR_PTR(-ENODEV);
@@ -422,11 +422,11 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
req->cb(ctx, resp);
 }
 
-static int hpre_ctx_init(struct hpre_ctx *ctx)
+static int hpre_ctx_init(struct hpre_ctx *ctx, u8 type)
 {
struct hisi_qp *qp;
 
-   qp = hpre_get_qp_and_start();
+   qp = hpre_get_qp_and_start(type);
if (IS_ERR(qp))
return PTR_ERR(qp);
 
@@ -674,7 +674,7 @@ static int hpre_dh_init_tfm(struct crypto_kpp *tfm)
 {
struct hpre_ctx *ctx = kpp_tfm_ctx(tfm);
 
-   return hpre_ctx_init(ctx);
+   return hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
 }
 
 static void hpre_dh_exit_tfm(struct crypto_kpp *tfm)
@@ -1100,7 +1100,7 @@ static int hpre_rsa_init_tfm(struct crypto_akcipher *tfm)
return PTR_ERR(ctx->rsa.soft_tfm);
}
 
-   ret = hpre_ctx_init(ctx);
+   ret = hpre_ctx_init(ctx, HPRE_V2_ALG_TYPE);
if (ret)
crypto_free_akcipher(ctx->rsa.soft_tfm);
 
diff --git a/drivers/crypto/hisilicon/hpre/hpre_main.c 
b/drivers/crypto/hisilicon/hpre/hpre_main.c
index 52827b0..d3ec3b4 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_main.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_main.c
@@ -223,13 +223,20 @@ static u32 vfs_num;
 module_param_cb(vfs_num, _num_ops, _num, 0444);
 MODULE_PARM_DESC(vfs_num, "Number of VFs to enable(1-63), 0(default)");
 
-struct hisi_qp *hpre_create_qp(void)
+struct hisi_qp *hpre_create_qp(u8 type)
 {
int node = cpu_to_node(smp_processor_id());
struct hisi_qp *qp = NULL;
int ret;
 
-   ret = hisi_qm_alloc_qps_node(_devices, 1, 0, node, );
+   if (type != HPRE_V2_ALG_TYPE && type != HPRE_V3_ECC_ALG_TYPE)
+   return NULL;
+
+   /*
+* type: 0 - RSA/DH. algorithm supported in V2,
+*   1 - ECC algorithm in V3.
+*/
+   ret = hisi_qm_alloc_qps_node(_devices, 1, type, node, );
if (!ret)
return qp;
 
-- 
2.8.1

[PATCH v7 7/7] crypto: hisilicon/hpre - add 'CURVE25519' algorithm

[Meng Yu]

Enable 'CURVE25519' algorithm in Kunpeng 930.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
---
 drivers/crypto/hisilicon/Kconfig|   1 +
 drivers/crypto/hisilicon/hpre/hpre.h|   2 +
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 370 +++-
 3 files changed, 364 insertions(+), 9 deletions(-)

diff --git a/drivers/crypto/hisilicon/Kconfig b/drivers/crypto/hisilicon/Kconfig
index 8431926..c45adb1 100644
--- a/drivers/crypto/hisilicon/Kconfig
+++ b/drivers/crypto/hisilicon/Kconfig
@@ -65,6 +65,7 @@ config CRYPTO_DEV_HISI_HPRE
depends on UACCE || UACCE=n
depends on ARM64 || (COMPILE_TEST && 64BIT)
depends on ACPI
+   select CRYPTO_LIB_CURVE25519_GENERIC
select CRYPTO_DEV_HISI_QM
select CRYPTO_DH
select CRYPTO_RSA
diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index 50e6b2e..92892e3 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -84,6 +84,8 @@ enum hpre_alg_type {
HPRE_ALG_DH_G2 = 0x4,
HPRE_ALG_DH = 0x5,
HPRE_ALG_ECC_MUL = 0xD,
+   /* shared by x25519 and x448, but x448 is not supported now */
+   HPRE_ALG_CURVE25519_MUL = 0x10,
 };
 
 struct hpre_sqe {
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index 778a0057..5b67f45 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1,6 +1,7 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (c) 2019 HiSilicon Limited. */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -96,6 +97,16 @@ struct hpre_ecdh_ctx {
dma_addr_t dma_g;
 };
 
+struct hpre_curve25519_ctx {
+   /* low address: p->a->k */
+   unsigned char *p;
+   dma_addr_t dma_p;
+
+   /* gx coordinate */
+   unsigned char *g;
+   dma_addr_t dma_g;
+};
+
 struct hpre_ctx {
struct hisi_qp *qp;
struct hpre_asym_request **req_list;
@@ -108,6 +119,7 @@ struct hpre_ctx {
struct hpre_rsa_ctx rsa;
struct hpre_dh_ctx dh;
struct hpre_ecdh_ctx ecdh;
+   struct hpre_curve25519_ctx curve25519;
};
/* for ecc algorithms */
unsigned int curve_id;
@@ -122,6 +134,7 @@ struct hpre_asym_request {
struct akcipher_request *rsa;
struct kpp_request *dh;
struct kpp_request *ecdh;
+   struct kpp_request *curve25519;
} areq;
int err;
int req_id;
@@ -444,7 +457,6 @@ static void hpre_alg_cb(struct hisi_qp *qp, void *resp)
struct hpre_sqe *sqe = resp;
struct hpre_asym_request *req = ctx->req_list[le16_to_cpu(sqe->tag)];
 
-
if (unlikely(!req)) {
atomic64_inc([HPRE_INVALID_REQ_CNT].value);
return;
@@ -1174,6 +1186,12 @@ static void hpre_ecc_clear_ctx(struct hpre_ctx *ctx, 
bool is_clear_all,
memzero_explicit(ctx->ecdh.p + shift, sz);
dma_free_coherent(dev, sz << 3, ctx->ecdh.p, ctx->ecdh.dma_p);
ctx->ecdh.p = NULL;
+   } else if (!is_ecdh && ctx->curve25519.p) {
+   /* curve25519: p->a->k */
+   memzero_explicit(ctx->curve25519.p + shift, sz);
+   dma_free_coherent(dev, sz << 2, ctx->curve25519.p,
+ ctx->curve25519.dma_p);
+   ctx->curve25519.p = NULL;
}
 
ctx->curve_id = 0;
@@ -1568,6 +1586,313 @@ static void hpre_ecdh_exit_tfm(struct crypto_kpp *tfm)
hpre_ecc_clear_ctx(ctx, true, true);
 }
 
+static void hpre_curve25519_fill_curve(struct hpre_ctx *ctx, const void *buf,
+  unsigned int len)
+{
+   u8 secret[CURVE25519_KEY_SIZE] = { 0 };
+   unsigned int sz = ctx->key_sz;
+   const struct ecc_curve *curve;
+   unsigned int shift = sz << 1;
+   void *p;
+
+   /*
+* The key from 'buf' is in little-endian, we should preprocess it as
+* the description in rfc7748: "k[0] &= 248, k[31] &= 127, k[31] |= 64",
+* then convert it to big endian. Only in this way, the result can be
+* the same as the software curve-25519 that exists in crypto.
+*/
+   memcpy(secret, buf, len);
+   curve25519_clamp_secret(secret);
+   hpre_key_to_big_end(secret, CURVE25519_KEY_SIZE);
+
+   p = ctx->curve25519.p + sz - len;
+
+   curve = ecc_get_curve25519();
+
+   /* fill curve parameters */
+   fill_curve_param(p, curve->p, len, curve->g.ndigits);
+   fill_curve_param(p + sz, curve->a, len, curve->g.ndigits);
+   memcpy(p + shift, secret, len);
+   fill_curve_param(p + shift + sz, curve->g.x, len, curve->g.ndigits);
+   memzero_explicit(secret, CURVE25519_KEY_SIZE);
+}
+
+static int hpre_curve25519_set_param(struct hpre_ctx *ctx, const void *buf,
+

[PATCH v7 1/7] crypto: hisilicon/hpre - add version adapt to new algorithms

[Meng Yu]

A new generation of accelerator Kunpeng930 has appeared, and the
corresponding driver needs to be updated to support some new
algorithms of Kunpeng930. To be compatible with Kunpeng920, we
add parameter 'struct hisi_qm *qm' to sec_algs_(un)register to
identify the chip's version.

Signed-off-by: Meng Yu 
Reviewed-by: Zaibo Xu 
Reviewed-by: Longfang Liu 
---
 drivers/crypto/hisilicon/hpre/hpre.h| 5 +++--
 drivers/crypto/hisilicon/hpre/hpre_crypto.c | 4 ++--
 drivers/crypto/hisilicon/qm.c   | 4 ++--
 drivers/crypto/hisilicon/qm.h   | 4 ++--
 drivers/crypto/hisilicon/sec2/sec.h | 4 ++--
 drivers/crypto/hisilicon/sec2/sec_crypto.c  | 4 ++--
 drivers/crypto/hisilicon/sec2/sec_crypto.h  | 4 ++--
 drivers/crypto/hisilicon/zip/zip.h  | 4 ++--
 drivers/crypto/hisilicon/zip/zip_crypto.c   | 4 ++--
 9 files changed, 19 insertions(+), 18 deletions(-)

diff --git a/drivers/crypto/hisilicon/hpre/hpre.h 
b/drivers/crypto/hisilicon/hpre/hpre.h
index f69252b..e784712 100644
--- a/drivers/crypto/hisilicon/hpre/hpre.h
+++ b/drivers/crypto/hisilicon/hpre/hpre.h
@@ -91,7 +91,8 @@ struct hpre_sqe {
 };
 
 struct hisi_qp *hpre_create_qp(void);
-int hpre_algs_register(void);
-void hpre_algs_unregister(void);
+int hpre_algs_register(struct hisi_qm *qm);
+void hpre_algs_unregister(struct hisi_qm *qm);
+
 
 #endif
diff --git a/drivers/crypto/hisilicon/hpre/hpre_crypto.c 
b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
index a87f990..d89b2f5 100644
--- a/drivers/crypto/hisilicon/hpre/hpre_crypto.c
+++ b/drivers/crypto/hisilicon/hpre/hpre_crypto.c
@@ -1154,7 +1154,7 @@ static struct kpp_alg dh = {
 };
 #endif
 
-int hpre_algs_register(void)
+int hpre_algs_register(struct hisi_qm *qm)
 {
int ret;
 
@@ -1171,7 +1171,7 @@ int hpre_algs_register(void)
return ret;
 }
 
-void hpre_algs_unregister(void)
+void hpre_algs_unregister(struct hisi_qm *qm)
 {
crypto_unregister_akcipher();
 #ifdef CONFIG_CRYPTO_DH
diff --git a/drivers/crypto/hisilicon/qm.c b/drivers/crypto/hisilicon/qm.c
index 904b99a..5e9d8d7 100644
--- a/drivers/crypto/hisilicon/qm.c
+++ b/drivers/crypto/hisilicon/qm.c
@@ -4015,7 +4015,7 @@ int hisi_qm_alg_register(struct hisi_qm *qm, struct 
hisi_qm_list *qm_list)
mutex_unlock(_list->lock);
 
if (flag) {
-   ret = qm_list->register_to_crypto();
+   ret = qm_list->register_to_crypto(qm);
if (ret) {
mutex_lock(_list->lock);
list_del(>list);
@@ -4046,7 +4046,7 @@ void hisi_qm_alg_unregister(struct hisi_qm *qm, struct 
hisi_qm_list *qm_list)
mutex_unlock(_list->lock);
 
if (list_empty(_list->list))
-   qm_list->unregister_from_crypto();
+   qm_list->unregister_from_crypto(qm);
 }
 EXPORT_SYMBOL_GPL(hisi_qm_alg_unregister);
 
diff --git a/drivers/crypto/hisilicon/qm.h b/drivers/crypto/hisilicon/qm.h
index c1dd0fc..7d0d626 100644
--- a/drivers/crypto/hisilicon/qm.h
+++ b/drivers/crypto/hisilicon/qm.h
@@ -198,8 +198,8 @@ struct hisi_qm_err_ini {
 struct hisi_qm_list {
struct mutex lock;
struct list_head list;
-   int (*register_to_crypto)(void);
-   void (*unregister_from_crypto)(void);
+   int (*register_to_crypto)(struct hisi_qm *qm);
+   void (*unregister_from_crypto)(struct hisi_qm *qm);
 };
 
 struct hisi_qm {
diff --git a/drivers/crypto/hisilicon/sec2/sec.h 
b/drivers/crypto/hisilicon/sec2/sec.h
index 0849191..17ddb20 100644
--- a/drivers/crypto/hisilicon/sec2/sec.h
+++ b/drivers/crypto/hisilicon/sec2/sec.h
@@ -183,6 +183,6 @@ struct sec_dev {
 
 void sec_destroy_qps(struct hisi_qp **qps, int qp_num);
 struct hisi_qp **sec_create_qps(void);
-int sec_register_to_crypto(void);
-void sec_unregister_from_crypto(void);
+int sec_register_to_crypto(struct hisi_qm *qm);
+void sec_unregister_from_crypto(struct hisi_qm *qm);
 #endif
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.c 
b/drivers/crypto/hisilicon/sec2/sec_crypto.c
index 2eaa516..f835514 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.c
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.c
@@ -1634,7 +1634,7 @@ static struct aead_alg sec_aeads[] = {
 AES_BLOCK_SIZE, AES_BLOCK_SIZE, SHA512_DIGEST_SIZE),
 };
 
-int sec_register_to_crypto(void)
+int sec_register_to_crypto(struct hisi_qm *qm)
 {
int ret;
 
@@ -1651,7 +1651,7 @@ int sec_register_to_crypto(void)
return ret;
 }
 
-void sec_unregister_from_crypto(void)
+void sec_unregister_from_crypto(struct hisi_qm *qm)
 {
crypto_unregister_skciphers(sec_skciphers,
ARRAY_SIZE(sec_skciphers));
diff --git a/drivers/crypto/hisilicon/sec2/sec_crypto.h 
b/drivers/crypto/hisilicon/sec2/sec_crypto.h
index b2786e1..0e933e7 100644
--- a/drivers/crypto/hisilicon/sec2/sec_crypto.h
+++ b/drivers/crypto/hisilicon/sec2/sec_crypto.h
@@ -211,6 +211,6 @@ struct sec_sqe {
struct sec_sqe_type2 type2;
 };
 
-int 

Re: [PATCH v2] PCI: Re-enable downstream port LTR if it was previously enabled

[Mingchuang Qiao]

On Thu, 2021-01-21 at 16:31 -0600, Bjorn Helgaas wrote:
> [+cc Alex and Mingchuang et al from
> https://lore.kernel.org/r/20210112072739.31624-1-mingchuang.q...@mediatek.com]
> 
> On Tue, Jan 19, 2021 at 04:14:10PM +0300, Mika Westerberg wrote:
> > PCIe r5.0, sec 7.5.3.16 says that the downstream ports must reset the
> > LTR enable bit if the link goes down (port goes DL_Down status). Now, if
> > we had LTR previously enabled and the PCIe endpoint gets hot-removed and
> > then hot-added back the ->ltr_path of the downstream port is still set
> > but the port now does not have the LTR enable bit set anymore.
> > 
> > For this reason check if the bridge upstream had LTR enabled previously
> > and re-enable it before enabling LTR for the endpoint.
> > 
> > Reported-by: Utkarsh H Patel 
> > Signed-off-by: Mika Westerberg 
> 
> I think this and Mingchuang's patch, which is essentially identical,
> are right and solves the problem for hot-remove/hot-add.  In that
> scenario we call pci_configure_ltr() on the hot-added device, and
> with this patch, we'll re-enable LTR on the bridge leading to the new
> device before enabling LTR on the new device itself.
> 
> But don't we have a similar problem if we simply do a Fundamental
> Reset on a device?  I think the reset path will restore the device's
> state, including PCI_EXP_DEVCTL2, but it doesn't do anything with the
> upstream bridge, does it?
> 

Yes. I think the same problem exists under such scenario, and that’s the
issue my patch intends to resolve.
I also prepared a v2 patch for review(update the patch description).
Shall I submit the v2 patch for review?

> So if a bridge and a device below it both have LTR enabled, can't we
> have the following:
> 
>   - bridge LTR enabled
>   - device LTR enabled
>   - reset device, e.g., via Secondary Bus Reset
>   - link goes down, bridge disables LTR
>   - link comes back up, LTR disabled in both bridge and device
>   - restore device state, including LTR enable
>   - device sends LTR message
>   - bridge reports Unsupported Request
> 
> > ---
> > Previous version can be found here:
> > 
> >   
> > https://lore.kernel.org/linux-pci/20210114134724.79511-1-mika.westerb...@linux.intel.com/
> > 
> > Changes from the previous version:
> > 
> >   * Corrected typos in the commit message
> >   * No need to call pcie_downstream_port()
> > 
> >  drivers/pci/probe.c | 17 -
> >  1 file changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 0eb68b47354f..a4a8c0305fb9 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -2153,7 +2153,7 @@ static void pci_configure_ltr(struct pci_dev *dev)
> >  {
> >  #ifdef CONFIG_PCIEASPM
> > struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
> > -   struct pci_dev *bridge;
> > +   struct pci_dev *bridge = NULL;
> > u32 cap, ctl;
> >  
> > if (!pci_is_pcie(dev))
> > @@ -2191,6 +2191,21 @@ static void pci_configure_ltr(struct pci_dev *dev)
> > if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT ||
> > ((bridge = pci_upstream_bridge(dev)) &&
> >   bridge->ltr_path)) {
> > +   /*
> > +* Downstream ports reset the LTR enable bit when the
> > +* link goes down (e.g on hot-remove) so re-enable the
> > +* bit here if not set anymore.
> > +* PCIe r5.0, sec 7.5.3.16.
> > +*/
> > +   if (bridge) {
> > +   pcie_capability_read_dword(bridge, PCI_EXP_DEVCTL2, 
> > );
> > +   if (!(ctl & PCI_EXP_DEVCTL2_LTR_EN)) {
> > +   pci_dbg(bridge, "re-enabling LTR\n");
> > +   pcie_capability_set_word(bridge, 
> > PCI_EXP_DEVCTL2,
> > +
> > PCI_EXP_DEVCTL2_LTR_EN);
> > +   }
> > +   }
> > +   pci_dbg(dev, "enabling LTR\n");
> > pcie_capability_set_word(dev, PCI_EXP_DEVCTL2,
> >  PCI_EXP_DEVCTL2_LTR_EN);
> > dev->ltr_path = 1;
> > -- 
> > 2.29.2
> > 

[RESEND PATCH v2 5/9] regmap: sdw: use _no_pm functions in regmap_read/write

[Bard Liao]

sdw_update_slave_status will be invoked when a codec is attached,
and the codec driver will initialize the codec with regmap functions
while the codec device is pm_runtime suspended.

regmap routines currently rely on regular SoundWire IO functions,
which will call pm_runtime_get_sync()/put_autosuspend.

This causes a deadlock where the resume routine waits for an
initialization complete signal that while the initialization complete
can only be reached when the resume completes.

The only solution if we allow regmap functions to be used in resume
operations as well as during codec initialization is to use _no_pm
routines. The duty of making sure the bus is operational needs to be
handled above the regmap level.

Fixes: 7c22ce6e21840 ('regmap: Add SoundWire bus support')
Signed-off-by: Bard Liao 
---
 drivers/base/regmap/regmap-sdw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap-sdw.c b/drivers/base/regmap/regmap-sdw.c
index c92d614b4943..4b8d2d010cab 100644
--- a/drivers/base/regmap/regmap-sdw.c
+++ b/drivers/base/regmap/regmap-sdw.c
@@ -11,7 +11,7 @@ static int regmap_sdw_write(void *context, unsigned int reg, 
unsigned int val)
struct device *dev = context;
struct sdw_slave *slave = dev_to_sdw_dev(dev);
 
-   return sdw_write(slave, reg, val);
+   return sdw_write_no_pm(slave, reg, val);
 }
 
 static int regmap_sdw_read(void *context, unsigned int reg, unsigned int *val)
@@ -20,7 +20,7 @@ static int regmap_sdw_read(void *context, unsigned int reg, 
unsigned int *val)
struct sdw_slave *slave = dev_to_sdw_dev(dev);
int read;
 
-   read = sdw_read(slave, reg);
+   read = sdw_read_no_pm(slave, reg);
if (read < 0)
return read;
 
-- 
2.17.1

[RESEND PATCH v2 8/9] soundwire: bus: fix confusion on device used by pm_runtime

[Bard Liao]

From: Pierre-Louis Bossart 

Intel stress-tests routinely report IO timeouts and invalid power
management transitions. Upon further analysis, we seem to be using the
wrong devices in pm_runtime calls.

Before reading and writing registers, we first need to make sure the
Slave is fully resumed. The existing code attempts to do such that,
however because of a confusion dating from 2017 and copy/paste, we
end-up resuming the parent only instead of resuming the codec device.

This can lead to accesses to the Slave registers while the bus is
still being configured and the Slave not enumerated, and as a result
IO errors occur.

This is a classic problem, similar confusions happened for HDaudio
between bus and codec device, leading to power management issues.

Fix by using the relevant device for all uses of pm_runtime functions.

Fixes: 60ee9be255712 ('soundwire: bus: add PM/no-PM versions of read/write 
functions')
Fixes: aa79293517b39 ('soundwire: bus: fix io error when processing alert 
event')
Fixes: 9d715fa005ebc ('soundwire: Add IO transfer')
Reported-by: Bard Liao 
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 4eaeeb4090f0..7c4717dd9a34 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -513,16 +513,16 @@ int sdw_nread(struct sdw_slave *slave, u32 addr, size_t 
count, u8 *val)
 {
int ret;
 
-   ret = pm_runtime_get_sync(slave->bus->dev);
+   ret = pm_runtime_get_sync(>dev);
if (ret < 0 && ret != -EACCES) {
-   pm_runtime_put_noidle(slave->bus->dev);
+   pm_runtime_put_noidle(>dev);
return ret;
}
 
ret = sdw_nread_no_pm(slave, addr, count, val);
 
-   pm_runtime_mark_last_busy(slave->bus->dev);
-   pm_runtime_put(slave->bus->dev);
+   pm_runtime_mark_last_busy(>dev);
+   pm_runtime_put(>dev);
 
return ret;
 }
@@ -539,16 +539,16 @@ int sdw_nwrite(struct sdw_slave *slave, u32 addr, size_t 
count, u8 *val)
 {
int ret;
 
-   ret = pm_runtime_get_sync(slave->bus->dev);
+   ret = pm_runtime_get_sync(>dev);
if (ret < 0 && ret != -EACCES) {
-   pm_runtime_put_noidle(slave->bus->dev);
+   pm_runtime_put_noidle(>dev);
return ret;
}
 
ret = sdw_nwrite_no_pm(slave, addr, count, val);
 
-   pm_runtime_mark_last_busy(slave->bus->dev);
-   pm_runtime_put(slave->bus->dev);
+   pm_runtime_mark_last_busy(>dev);
+   pm_runtime_put(>dev);
 
return ret;
 }
@@ -1453,7 +1453,7 @@ static int sdw_handle_slave_alerts(struct sdw_slave 
*slave)
ret = pm_runtime_get_sync(>dev);
if (ret < 0 && ret != -EACCES) {
dev_err(>dev, "Failed to resume device: %d\n", ret);
-   pm_runtime_put_noidle(slave->bus->dev);
+   pm_runtime_put_noidle(>dev);
return ret;
}
 
-- 
2.17.1

[RESEND PATCH v2 9/9] soundwire: bus: clarify dev_err/dbg device references

[Bard Liao]

From: Pierre-Louis Bossart 

The SoundWire bus code confuses bus and Slave device levels for
dev_err/dbg logs. That's not impacting functionality but the accuracy
of kernel logs.

We should only use bus->dev for bus-level operations and handling of
Device0. For all other logs where the device number is not zero, we
should use >dev to provide more precisions to the
user/integrator.

Reported-by: Rander Wang 
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c | 63 +
 1 file changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 7c4717dd9a34..39edf87cf832 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -636,6 +636,7 @@ static int sdw_get_device_num(struct sdw_slave *slave)
 
 static int sdw_assign_device_num(struct sdw_slave *slave)
 {
+   struct sdw_bus *bus = slave->bus;
int ret, dev_num;
bool new_device = false;
 
@@ -646,7 +647,7 @@ static int sdw_assign_device_num(struct sdw_slave *slave)
dev_num = sdw_get_device_num(slave);
mutex_unlock(>bus->bus_lock);
if (dev_num < 0) {
-   dev_err(slave->bus->dev, "Get dev_num failed: 
%d\n",
+   dev_err(bus->dev, "Get dev_num failed: %d\n",
dev_num);
return dev_num;
}
@@ -659,7 +660,7 @@ static int sdw_assign_device_num(struct sdw_slave *slave)
}
 
if (!new_device)
-   dev_dbg(slave->bus->dev,
+   dev_dbg(bus->dev,
"Slave already registered, reusing dev_num:%d\n",
slave->dev_num);
 
@@ -669,7 +670,7 @@ static int sdw_assign_device_num(struct sdw_slave *slave)
 
ret = sdw_write_no_pm(slave, SDW_SCP_DEVNUMBER, dev_num);
if (ret < 0) {
-   dev_err(>dev, "Program device_num %d failed: %d\n",
+   dev_err(bus->dev, "Program device_num %d failed: %d\n",
dev_num, ret);
return ret;
}
@@ -748,7 +749,7 @@ static int sdw_program_device_num(struct sdw_bus *bus)
 */
ret = sdw_assign_device_num(slave);
if (ret) {
-   dev_err(slave->bus->dev,
+   dev_err(bus->dev,
"Assign dev_num failed:%d\n",
ret);
return ret;
@@ -788,9 +789,11 @@ static int sdw_program_device_num(struct sdw_bus *bus)
 static void sdw_modify_slave_status(struct sdw_slave *slave,
enum sdw_slave_status status)
 {
-   mutex_lock(>bus->bus_lock);
+   struct sdw_bus *bus = slave->bus;
 
-   dev_vdbg(>dev,
+   mutex_lock(>bus_lock);
+
+   dev_vdbg(bus->dev,
 "%s: changing status slave %d status %d new status %d\n",
 __func__, slave->dev_num, slave->status, status);
 
@@ -811,7 +814,7 @@ static void sdw_modify_slave_status(struct sdw_slave *slave,
complete(>enumeration_complete);
}
slave->status = status;
-   mutex_unlock(>bus->bus_lock);
+   mutex_unlock(>bus_lock);
 }
 
 static enum sdw_clk_stop_mode sdw_get_clk_stop_mode(struct sdw_slave *slave)
@@ -1140,7 +1143,7 @@ int sdw_configure_dpn_intr(struct sdw_slave *slave,
 
ret = sdw_update(slave, addr, (mask | SDW_DPN_INT_PORT_READY), val);
if (ret < 0)
-   dev_err(slave->bus->dev,
+   dev_err(>dev,
"SDW_DPN_INTMASK write failed:%d\n", val);
 
return ret;
@@ -1271,7 +1274,7 @@ static int sdw_initialize_slave(struct sdw_slave *slave)
/* Enable SCP interrupts */
ret = sdw_update_no_pm(slave, SDW_SCP_INTMASK1, val, val);
if (ret < 0) {
-   dev_err(slave->bus->dev,
+   dev_err(>dev,
"SDW_SCP_INTMASK1 write failed:%d\n", ret);
return ret;
}
@@ -1286,7 +1289,7 @@ static int sdw_initialize_slave(struct sdw_slave *slave)
 
ret = sdw_update_no_pm(slave, SDW_DP0_INTMASK, val, val);
if (ret < 0)
-   dev_err(slave->bus->dev,
+   dev_err(>dev,
"SDW_DP0_INTMASK read failed:%d\n", ret);
return ret;
 }
@@ -1298,7 +1301,7 @@ static int sdw_handle_dp0_interrupt(struct sdw_slave 
*slave, u8 *slave_status)
 
status = sdw_read_no_pm(slave, SDW_DP0_INT);
if (status < 0) {
-   dev_err(slave->bus->dev,
+   dev_err(>dev,
"SDW_DP0_INT read failed:%d\n", status);

[RESEND PATCH v2 7/9] regmap: sdw-mbq: use MODULE_LICENSE("GPL")

[Bard Liao]

"GPL v2" is the same as "GPL". It exists for historic reasons.
See Documentation/process/license-rules.rst

Signed-off-by: Pierre-Louis Bossart 
Signed-off-by: Bard Liao 
---
 drivers/base/regmap/regmap-sdw-mbq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap-sdw-mbq.c 
b/drivers/base/regmap/regmap-sdw-mbq.c
index 6675c3a4b829..fe3ac26b66ad 100644
--- a/drivers/base/regmap/regmap-sdw-mbq.c
+++ b/drivers/base/regmap/regmap-sdw-mbq.c
@@ -98,4 +98,4 @@ struct regmap *__devm_regmap_init_sdw_mbq(struct sdw_slave 
*sdw,
 EXPORT_SYMBOL_GPL(__devm_regmap_init_sdw_mbq);
 
 MODULE_DESCRIPTION("Regmap SoundWire MBQ Module");
-MODULE_LICENSE("GPL v2");
+MODULE_LICENSE("GPL");
-- 
2.17.1

[RESEND PATCH v2 6/9] regmap: sdw: use no_pm routines for SoundWire 1.2 MBQ

[Bard Liao]

Use no_pm versions for write and read.

Signed-off-by: Bard Liao 
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
---
 drivers/base/regmap/regmap-sdw-mbq.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/base/regmap/regmap-sdw-mbq.c 
b/drivers/base/regmap/regmap-sdw-mbq.c
index 8ce30650b97c..6675c3a4b829 100644
--- a/drivers/base/regmap/regmap-sdw-mbq.c
+++ b/drivers/base/regmap/regmap-sdw-mbq.c
@@ -15,11 +15,11 @@ static int regmap_sdw_mbq_write(void *context, unsigned int 
reg, unsigned int va
struct sdw_slave *slave = dev_to_sdw_dev(dev);
int ret;
 
-   ret = sdw_write(slave, SDW_SDCA_MBQ_CTL(reg), (val >> 8) & 0xff);
+   ret = sdw_write_no_pm(slave, SDW_SDCA_MBQ_CTL(reg), (val >> 8) & 0xff);
if (ret < 0)
return ret;
 
-   return sdw_write(slave, reg, val & 0xff);
+   return sdw_write_no_pm(slave, reg, val & 0xff);
 }
 
 static int regmap_sdw_mbq_read(void *context, unsigned int reg, unsigned int 
*val)
@@ -29,11 +29,11 @@ static int regmap_sdw_mbq_read(void *context, unsigned int 
reg, unsigned int *va
int read0;
int read1;
 
-   read0 = sdw_read(slave, reg);
+   read0 = sdw_read_no_pm(slave, reg);
if (read0 < 0)
return read0;
 
-   read1 = sdw_read(slave, SDW_SDCA_MBQ_CTL(reg));
+   read1 = sdw_read_no_pm(slave, SDW_SDCA_MBQ_CTL(reg));
if (read1 < 0)
return read1;
 
-- 
2.17.1

[RESEND PATCH v2 4/9] soundwire: export sdw_write/read_no_pm functions

[Bard Liao]

sdw_write_no_pm and sdw_read_no_pm are useful when we want to do IO
without touching PM.

Fixes: 0231453bc08f ('soundwire: bus: add clock stop helpers')
Fixes: 60ee9be25571 ('soundwire: bus: add PM/no-PM versions of
read/write functions')
Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c   | 7 ---
 include/linux/soundwire/sdw.h | 2 ++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 86c339d77a39..4eaeeb4090f0 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -405,10 +405,11 @@ sdw_nwrite_no_pm(struct sdw_slave *slave, u32 addr, 
size_t count, u8 *val)
return sdw_transfer(slave->bus, );
 }
 
-static int sdw_write_no_pm(struct sdw_slave *slave, u32 addr, u8 value)
+int sdw_write_no_pm(struct sdw_slave *slave, u32 addr, u8 value)
 {
return sdw_nwrite_no_pm(slave, addr, 1, );
 }
+EXPORT_SYMBOL(sdw_write_no_pm);
 
 static int
 sdw_bread_no_pm(struct sdw_bus *bus, u16 dev_num, u32 addr)
@@ -476,8 +477,7 @@ int sdw_bwrite_no_pm_unlocked(struct sdw_bus *bus, u16 
dev_num, u32 addr, u8 val
 }
 EXPORT_SYMBOL(sdw_bwrite_no_pm_unlocked);
 
-static int
-sdw_read_no_pm(struct sdw_slave *slave, u32 addr)
+int sdw_read_no_pm(struct sdw_slave *slave, u32 addr)
 {
u8 buf;
int ret;
@@ -488,6 +488,7 @@ sdw_read_no_pm(struct sdw_slave *slave, u32 addr)
else
return buf;
 }
+EXPORT_SYMBOL(sdw_read_no_pm);
 
 static int sdw_update_no_pm(struct sdw_slave *slave, u32 addr, u8 mask, u8 val)
 {
diff --git a/include/linux/soundwire/sdw.h b/include/linux/soundwire/sdw.h
index f0b01b728640..d08039d65825 100644
--- a/include/linux/soundwire/sdw.h
+++ b/include/linux/soundwire/sdw.h
@@ -1005,6 +1005,8 @@ int sdw_bus_exit_clk_stop(struct sdw_bus *bus);
 
 int sdw_read(struct sdw_slave *slave, u32 addr);
 int sdw_write(struct sdw_slave *slave, u32 addr, u8 value);
+int sdw_write_no_pm(struct sdw_slave *slave, u32 addr, u8 value);
+int sdw_read_no_pm(struct sdw_slave *slave, u32 addr);
 int sdw_nread(struct sdw_slave *slave, u32 addr, size_t count, u8 *val);
 int sdw_nwrite(struct sdw_slave *slave, u32 addr, size_t count, u8 *val);
 
-- 
2.17.1

[RESEND PATCH v2 3/9] soundwire: bus: use no_pm IO routines for all interrupt handling

[Bard Liao]

From: Pierre-Louis Bossart 

There is no need to play with pm_runtime reference counts, if needed
the codec drivers are already explicitly resumed.

Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index b1830032b052..86c339d77a39 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -1295,7 +1295,7 @@ static int sdw_handle_dp0_interrupt(struct sdw_slave 
*slave, u8 *slave_status)
u8 clear, impl_int_mask;
int status, status2, ret, count = 0;
 
-   status = sdw_read(slave, SDW_DP0_INT);
+   status = sdw_read_no_pm(slave, SDW_DP0_INT);
if (status < 0) {
dev_err(slave->bus->dev,
"SDW_DP0_INT read failed:%d\n", status);
@@ -1334,7 +1334,7 @@ static int sdw_handle_dp0_interrupt(struct sdw_slave 
*slave, u8 *slave_status)
}
 
/* clear the interrupts but don't touch reserved and 
SDCA_CASCADE fields */
-   ret = sdw_write(slave, SDW_DP0_INT, clear);
+   ret = sdw_write_no_pm(slave, SDW_DP0_INT, clear);
if (ret < 0) {
dev_err(slave->bus->dev,
"SDW_DP0_INT write failed:%d\n", ret);
@@ -1342,7 +1342,7 @@ static int sdw_handle_dp0_interrupt(struct sdw_slave 
*slave, u8 *slave_status)
}
 
/* Read DP0 interrupt again */
-   status2 = sdw_read(slave, SDW_DP0_INT);
+   status2 = sdw_read_no_pm(slave, SDW_DP0_INT);
if (status2 < 0) {
dev_err(slave->bus->dev,
"SDW_DP0_INT read failed:%d\n", status2);
@@ -1373,7 +1373,7 @@ static int sdw_handle_port_interrupt(struct sdw_slave 
*slave,
return sdw_handle_dp0_interrupt(slave, slave_status);
 
addr = SDW_DPN_INT(port);
-   status = sdw_read(slave, addr);
+   status = sdw_read_no_pm(slave, addr);
if (status < 0) {
dev_err(slave->bus->dev,
"SDW_DPN_INT read failed:%d\n", status);
@@ -1407,7 +1407,7 @@ static int sdw_handle_port_interrupt(struct sdw_slave 
*slave,
}
 
/* clear the interrupt but don't touch reserved fields */
-   ret = sdw_write(slave, addr, clear);
+   ret = sdw_write_no_pm(slave, addr, clear);
if (ret < 0) {
dev_err(slave->bus->dev,
"SDW_DPN_INT write failed:%d\n", ret);
@@ -1415,7 +1415,7 @@ static int sdw_handle_port_interrupt(struct sdw_slave 
*slave,
}
 
/* Read DPN interrupt again */
-   status2 = sdw_read(slave, addr);
+   status2 = sdw_read_no_pm(slave, addr);
if (status2 < 0) {
dev_err(slave->bus->dev,
"SDW_DPN_INT read failed:%d\n", status2);
@@ -1457,7 +1457,7 @@ static int sdw_handle_slave_alerts(struct sdw_slave 
*slave)
}
 
/* Read Intstat 1, Intstat 2 and Intstat 3 registers */
-   ret = sdw_read(slave, SDW_SCP_INT1);
+   ret = sdw_read_no_pm(slave, SDW_SCP_INT1);
if (ret < 0) {
dev_err(slave->bus->dev,
"SDW_SCP_INT1 read failed:%d\n", ret);
@@ -1465,7 +1465,7 @@ static int sdw_handle_slave_alerts(struct sdw_slave 
*slave)
}
buf = ret;
 
-   ret = sdw_nread(slave, SDW_SCP_INTSTAT2, 2, buf2);
+   ret = sdw_nread_no_pm(slave, SDW_SCP_INTSTAT2, 2, buf2);
if (ret < 0) {
dev_err(slave->bus->dev,
"SDW_SCP_INT2/3 read failed:%d\n", ret);
@@ -1473,7 +1473,7 @@ static int sdw_handle_slave_alerts(struct sdw_slave 
*slave)
}
 
if (slave->prop.is_sdca) {
-   ret = sdw_read(slave, SDW_DP0_INT);
+   ret = sdw_read_no_pm(slave, SDW_DP0_INT);
if (ret < 0) {
dev_err(slave->bus->dev,
"SDW_DP0_INT read failed:%d\n", ret);
@@ -1570,7 +1570,7 @@ static int sdw_handle_slave_alerts(struct sdw_slave 
*slave)
}
 
/* Ack interrupt */
-   ret = sdw_write(slave, SDW_SCP_INT1, clear);
+   ret = sdw_write_no_pm(slave, SDW_SCP_INT1, clear);
if (ret < 0) {
dev_err(slave->bus->dev,
"SDW_SCP_INT1 write failed:%d\n", ret);
@@ -1584,7 +1584,7 @@ static int sdw_handle_slave_alerts(struct sdw_slave 
*slave)
 * Read status again to ensure no new interrupts arrived
 * while servicing interrupts.
 */
-   ret = sdw_read(slave, SDW_SCP_INT1);
+   ret = 

Re: [PATCH 1/6] tty: implement write_iter

[Jiri Slaby]

On 21. 01. 21, 22:09, Linus Torvalds wrote:

On Thu, Jan 21, 2021 at 11:43 AM Greg Kroah-Hartman
 wrote:


This works, thanks for these.  I'll wait for Jiri to review them before
applying them to my branches...


Let's hope Jiri sees them, since he had some email issue earlier..

I'll add his suse address here too.


Thanks, I am fixed and nothing was lost :).

--
js
suse labs

[RESEND PATCH v2 1/9] soundwire: bus: use sdw_update_no_pm when initializing a device

[Bard Liao]

From: Pierre-Louis Bossart 

When a Slave device is resumed, it may resume the bus and restart the
enumeration. During that process, we absolutely don't want to call
regular read/write routines which will wait for the resume to
complete, otherwise a deadlock occurs.

Fixes: 60ee9be25571 ('soundwire: bus: add PM/no-PM versions of read/write 
functions')
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index d1e8c3a54976..60c42508c6c6 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -489,6 +489,18 @@ sdw_read_no_pm(struct sdw_slave *slave, u32 addr)
return buf;
 }
 
+static int sdw_update_no_pm(struct sdw_slave *slave, u32 addr, u8 mask, u8 val)
+{
+   int tmp;
+
+   tmp = sdw_read_no_pm(slave, addr);
+   if (tmp < 0)
+   return tmp;
+
+   tmp = (tmp & ~mask) | val;
+   return sdw_write_no_pm(slave, addr, tmp);
+}
+
 /**
  * sdw_nread() - Read "n" contiguous SDW Slave registers
  * @slave: SDW Slave
@@ -1256,7 +1268,7 @@ static int sdw_initialize_slave(struct sdw_slave *slave)
val = slave->prop.scp_int1_mask;
 
/* Enable SCP interrupts */
-   ret = sdw_update(slave, SDW_SCP_INTMASK1, val, val);
+   ret = sdw_update_no_pm(slave, SDW_SCP_INTMASK1, val, val);
if (ret < 0) {
dev_err(slave->bus->dev,
"SDW_SCP_INTMASK1 write failed:%d\n", ret);
@@ -1271,7 +1283,7 @@ static int sdw_initialize_slave(struct sdw_slave *slave)
val = prop->dp0_prop->imp_def_interrupts;
val |= SDW_DP0_INT_PORT_READY | SDW_DP0_INT_BRA_FAILURE;
 
-   ret = sdw_update(slave, SDW_DP0_INTMASK, val, val);
+   ret = sdw_update_no_pm(slave, SDW_DP0_INTMASK, val, val);
if (ret < 0)
dev_err(slave->bus->dev,
"SDW_DP0_INTMASK read failed:%d\n", ret);
-- 
2.17.1

[RESEND PATCH v2 2/9] soundwire: bus: use sdw_write_no_pm when setting the bus scale registers

[Bard Liao]

From: Pierre-Louis Bossart 

When a Slave device is resumed, it may resume the bus and restart the
enumeration. During that process, we absolutely don't want to call
regular read/write routines which will wait for the resume to
complete, otherwise a deadlock occurs.

This patch fixes the same problem as the previous one, but is split to
make the life of linux-stable maintainers less painful.

Fixes: 29d158f90690 ('soundwire: bus: initialize bus clock base and scale 
registers')
Signed-off-by: Pierre-Louis Bossart 
Reviewed-by: Rander Wang 
Signed-off-by: Bard Liao 
---
 drivers/soundwire/bus.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/soundwire/bus.c b/drivers/soundwire/bus.c
index 60c42508c6c6..b1830032b052 100644
--- a/drivers/soundwire/bus.c
+++ b/drivers/soundwire/bus.c
@@ -1222,7 +1222,7 @@ static int sdw_slave_set_frequency(struct sdw_slave 
*slave)
}
scale_index++;
 
-   ret = sdw_write(slave, SDW_SCP_BUS_CLOCK_BASE, base);
+   ret = sdw_write_no_pm(slave, SDW_SCP_BUS_CLOCK_BASE, base);
if (ret < 0) {
dev_err(>dev,
"SDW_SCP_BUS_CLOCK_BASE write failed:%d\n", ret);
@@ -1230,13 +1230,13 @@ static int sdw_slave_set_frequency(struct sdw_slave 
*slave)
}
 
/* initialize scale for both banks */
-   ret = sdw_write(slave, SDW_SCP_BUSCLOCK_SCALE_B0, scale_index);
+   ret = sdw_write_no_pm(slave, SDW_SCP_BUSCLOCK_SCALE_B0, scale_index);
if (ret < 0) {
dev_err(>dev,
"SDW_SCP_BUSCLOCK_SCALE_B0 write failed:%d\n", ret);
return ret;
}
-   ret = sdw_write(slave, SDW_SCP_BUSCLOCK_SCALE_B1, scale_index);
+   ret = sdw_write_no_pm(slave, SDW_SCP_BUSCLOCK_SCALE_B1, scale_index);
if (ret < 0)
dev_err(>dev,
"SDW_SCP_BUSCLOCK_SCALE_B1 write failed:%d\n", ret);
-- 
2.17.1

[RESEND PATCH v2 0/9] soundwire/regmap: use _no_pm routines

[Bard Liao]

When a Slave device is resumed, it may resume the bus and restart the
enumeration. And Slave drivers will wait for initialization_complete
complete in their resume function, however initialization_complete will
complete after sdw_update_slave_status function is finished and codec
driver usually call some IO functions in the update_status callback
function.
It will become a deadlock if we use regular read/write routines during
the resuming process.

This series touches both soundwire and regmap trees.
commit fb5103f9d6ce ("regmap/SoundWire: sdw: add support for SoundWire 1.2 MBQ")
is needed for soundwire tree to complie.
On the other hands,
commit 6e06a85556f9 ("soundwire: bus: add comments to explain interrupt loop 
filter")
to
commit 47b8520997a8 ("soundwire: bus: only clear valid DPN interrupts")
are needed for regmap tree.

v2:
 - Separate commits according to maintainer's comments.

Bard Liao (4):
  soundwire: export sdw_write/read_no_pm functions
  regmap: sdw: use _no_pm functions in regmap_read/write
  regmap: sdw: use no_pm routines for SoundWire 1.2 MBQ
  regmap: sdw-mbq: use MODULE_LICENSE("GPL")

Pierre-Louis Bossart (5):
  soundwire: bus: use sdw_update_no_pm when initializing a device
  soundwire: bus: use sdw_write_no_pm when setting the bus scale
registers
  soundwire: bus: use no_pm IO routines for all interrupt handling
  soundwire: bus: fix confusion on device used by pm_runtime
  soundwire: bus: clarify dev_err/dbg device references

 drivers/base/regmap/regmap-sdw-mbq.c |  10 +-
 drivers/base/regmap/regmap-sdw.c |   4 +-
 drivers/soundwire/bus.c  | 136 +++
 include/linux/soundwire/sdw.h|   2 +
 4 files changed, 85 insertions(+), 67 deletions(-)

-- 
2.17.1

Re: arch/riscv/kernel/vdso/vdso-syms.S:2: Error: junk at end of line, first unrecognized character is `@'

[Nathan Chancellor]

On Fri, Jan 22, 2021 at 09:41:35AM +0800, kernel test robot wrote:
> Hi Palmer,
> 
> First bad commit (maybe != root cause):
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   9f29bd8b2e7132b409178d1367dae1813017bd0e
> commit: c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c RISC-V: Fix the VDSO symbol 
> generaton for binutils-2.35+
> date:   3 months ago
> config: riscv-randconfig-r002-20210122 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
> bd3a387ee76f58caa0d7901f3f84e9bb3d006f27)
> 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
> # install riscv cross compiling tool for clang build
> # apt-get install binutils-riscv64-linux-gnu
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c
> git remote add linus 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout c2c81bb2f69138f902e1a58d3bef6ad97fb8a92c
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
>arch/riscv/kernel/vdso/vdso-syms.S: Assembler messages:
> >> arch/riscv/kernel/vdso/vdso-syms.S:2: Error: junk at end of line, first 
> >> unrecognized character is `@'
>arch/riscv/kernel/vdso/vdso-syms.S:4: Error: junk at end of line, first 
> unrecognized character is `@'
>arch/riscv/kernel/vdso/vdso-syms.S:6: Error: junk at end of line, first 
> unrecognized character is `@'
>arch/riscv/kernel/vdso/vdso-syms.S:8: Error: junk at end of line, first 
> unrecognized character is `@'
>arch/riscv/kernel/vdso/vdso-syms.S:10: Error: junk at end of line, first 
> unrecognized character is `@'
>arch/riscv/kernel/vdso/vdso-syms.S:12: Error: junk at end of line, first 
> unrecognized character is `@'
>clang-12: error: assembler command failed with exit code 1 (use -v to see 
> invocation)
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

I believe this is https://github.com/ClangBuiltLinux/linux/issues/1266.

Cheers,
Nathan

linux-next: Tree for Jan 22

[Stephen Rothwell]

Hi all,

Changes since 20210121:

The drm-intel tree lost its build failure.

The notifications tree gained conflicts against the keys tree.

Non-merge commits (relative to Linus' tree): 4819
 5269 files changed, 192976 insertions(+), 126175 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 333 trees (counting Linus' and 86 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (9f29bd8b2e71 Merge tag 'fs_for_v5.11-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs)
Merging fixes/fixes (e71ba9452f0b Linux 5.11-rc2)
Merging kbuild-current/fixes (19c329f68089 Linux 5.11-rc4)
Merging arc-current/for-curr (7c53f6b671f4 Linux 5.11-rc3)
Merging arm-current/fixes (e64ab473ddda ARM: 9034/1: __div64_32(): straighten 
up inline asm constraints)
Merging arm64-fixes/for-next/fixes (3ed86b9a7140 kasan, arm64: fix pointer tags 
in KASAN reports)
Merging arm-soc-fixes/arm/fixes (8a996b2d8a03 ARM: dts: ux500: Reserve memory 
carveouts)
Merging drivers-memory-fixes/fixes (5c8fe583cce5 Linux 5.11-rc1)
Merging m68k-current/for-linus (2ae92e8b9b7e MAINTAINERS: Update m68k Mac entry)
Merging powerpc-fixes/fixes (08685be7761d powerpc/64s: fix scv entry fallback 
flush vs interrupt)
Merging s390-fixes/fixes (19c329f68089 Linux 5.11-rc4)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (d19d8d345eec fscrypt: fix inline encryption 
not used on new files)
Merging net/master (35c715c30b95 Merge branch 'master' of 
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec)
Merging bpf/master (75439bc439e0 Merge tag 'net-5.11-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net)
Merging ipsec/master (da64ae2d35d3 xfrm: Fix wraparound in 
xfrm_policy_addr_delta())
Merging netfilter/master (c8a8ead01736 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (c8a8ead01736 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging wireless-drivers/master (952de419b617 mt76: mt7663s: fix rx buffer 
refcounting)
Merging mac80211/master (dcf3c8fb32dd mac80211: 160MHz with extended NSS BW in 
CSA)
Merging rdma-fixes/for-rc (f068cb1db2cb RDMA/usnic: Fix misuse of sysfs_emit_at)
Merging sound-current/for-linus (506c203cc3de ALSA: usb-audio: Fix hw 
constraints dependencies)
Merging sound-asoc-fixes/for-linus (6da3017fab4b Merge remote-tracking branch 
'asoc/for-5.11' into asoc-linus)
Merging regmap-fixes/for-linus (19c329f68089 Linux 5.11-rc4)
Merging regulator-fixes/for-linus (82705e71def3 Merge remote-tracking branch 
'regulator/for-5.11' into regulator-linus)
Merging spi-fixes/for-linus (8d874842da43 Merge remote-tracking branch 
'spi/for-5.11' into spi-linus)
Merging pci-current/for-linus (7c53f6b671f4 Linux 5.11-rc3)
Merging driver-core.current/driver-core-linus (e020ff611ba9 driver core: Fix 
device link device name collision)
Merging tty.current/tty-linus (494e63ee9c9f Merge 9bb48c82aced ("tty: implement 
write_iter") into tty-linus)
Merging usb.current/usb-linus (ef02684c4e67 usb: bdc: Make bdc pci driver 
depend on BROKEN)
Merging usb-gadget-fixes/fixes (129aa9734559 usb: raw-gadget: fix memory leak 
in gadget_setup)
Merging usb-serial-fixes/usb-linus (43377df70480 USB

Re: [RFC PATCH 1/2] soundwire: add support for static port mapping

[Srinivas Kandagatla]

On 21/01/2021 21:30, Pierre-Louis Bossart wrote:


Am looking at intel_hw_params(). Isn't sdw_stream_add_master() called 
for every dai in the dai link.


Yes, that's correct, but again a dai may use one or more ports.

if you defined each port as a dai, and want to call 
sdw_stream_add_master() for each port you are doing something the API 
was not designed for. There is a 'num_ports' argument for a reason :-)


per master, and that master_rt deals with one or more ports - your 
choice. >
A 'stream' is an abstract data transport which can be split across 
multiple masters/sales and for each master/slave use multiple ports.
When calling sdw_stream_add_master/slave, you need to provide a 
port_config/num_ports to state which ports will be used on that 
master/slave when using the stream. That's how we e.g. deal with 4ch 
streams that are handled by two ports on each side.


To up-level a bit, the notion of 'stream' is actually very very 
similar to the notion of dailink. And in fact, the 'stream' is 
actually created for Intel in the dailink .startup callback, so I am 
quite in the dark on what you are trying to accomplish.

In qcom case stream is also allocated for in dai startup().

I think we are talking about two different issues,

1>one is the failure I see in sdw_stream_add_master() when I try to 
use dai-link dai-id style approach suggested. I will dig this bit more 
and collect more details!


2>(Main issue) Ability for slave to select different combination of 
ports at runtime based on the mixer setting or active dapm.


All this patch is trying do is the pass this *CURRENT/ACTIVE* static 
port mapping between slave and master while setting up the stream.
With the dailink approach number of ports are pretty much static and 
may not be required for particular use case. As above example if we 
have a headset with button click suppression we would need 2 Ports and 
similarly without we only need one port.


As I said above you cannot enable the button click suppression 
dynamically *after* the headset capture hw_params/prepare.


That is not true, the ports in this case are selected based on mixer 
setting or register state even before stream is setup/started in 
hw_params/prepare.

WSA881x codec has pretty much similar setup.



This is not possible with dai-link approach, unless we create two 
different dai links for the above example usecase!


The current approach is a worst-case one, where you would create a 
single 'headset capture' dailink.




Are you suggesting that we have dailink for each usecase like:

"headset capture"
"Analog MIC1 capture"
"Analog MIC2 Capture"

...

"Analog MIC4 Capture"

...

"DMIC0 capture"
"DMIC1 Capture"
"DMIC2 Capture"

...

"DMIC7 Capture"
..
"Headset Playback"
"Ear Playback"
..
"Aux Playback"
...

this is not really doable!

All am saying is that codec can decide which ports it has to select 
based on mixer setting before the stream is setup/started. This updated 
mapping between slv port and master ports is passed as part of the 
port_config in sdw_stream_add_slave().



--srini

We never envisioned a case where you modify what the definition of 
'headset capture' is based on control events, and I really challenge the 
fact that it is feasible/realistic. This is really about streaming data 
across a bus, and we are limited on what we can do. It's the same 
problem that we never modify the number of channels dynamically on a PCM 
device.

[PATCH] mm: fix prototype warning from kernel test robot

[Baoquan He]

Kernel test robot calling make with 'W=1' triggering warning like below
below for memmap_init_zone() function.

mm/page_alloc.c:6259:23: warning: no previous prototype for 'memmap_init_zone' 
[-Wmissing-prototypes]
 6259 | void __meminit __weak memmap_init_zone(unsigned long size, int nid,
  |   ^~~~

Fix it by adding the function declaration in include/linux/mm.h.
Since memmap_init_zone() has a generic version with '__weak',
the declaratoin in ia64 header file can be simply removed.

Signed-off-by: Baoquan He 
Reported-by: kernel test robot 
---
 arch/ia64/include/asm/pgtable.h | 5 -
 include/linux/mm.h  | 1 +
 2 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 2c81394a2430..9b4efe89e62d 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -517,11 +517,6 @@ extern struct page *zero_page_memmap_ptr;
__changed;  \
 })
 #endif
-
-#  ifdef CONFIG_VIRTUAL_MEM_MAP
-  /* arch mem_map init routine is needed due to holes in a virtual mem_map */
-extern void memmap_init_zone(struct zone *zone);
-#  endif /* CONFIG_VIRTUAL_MEM_MAP */
 # endif /* !__ASSEMBLY__ */
 
 /*
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 56bb239f9150..073049bd0b29 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2401,6 +2401,7 @@ extern void set_dma_reserve(unsigned long 
new_dma_reserve);
 extern void memmap_init_range(unsigned long, int, unsigned long,
unsigned long, unsigned long, enum meminit_context,
struct vmem_altmap *, int migratetype);
+extern void memmap_init_zone(struct zone *zone);
 extern void setup_per_zone_wmarks(void);
 extern int __meminit init_per_zone_wmark_min(void);
 extern void mem_init(void);
-- 
2.17.2

[PATCH] power: supply: bq25980: Fix repetive bq25975 with bq25960

[xinjian]

From: xinjian 

The i2c_device_id bq25975 is repeated, and should be bq25960.

Signed-off-by: xinjian 
---
 drivers/power/supply/bq25980_charger.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/power/supply/bq25980_charger.c 
b/drivers/power/supply/bq25980_charger.c
index c936f311eb4f..530ff4025b31 100644
--- a/drivers/power/supply/bq25980_charger.c
+++ b/drivers/power/supply/bq25980_charger.c
@@ -1285,7 +1285,7 @@ static int bq25980_probe(struct i2c_client *client,
 static const struct i2c_device_id bq25980_i2c_ids[] = {
{ "bq25980", BQ25980 },
{ "bq25975", BQ25975 },
-   { "bq25975", BQ25975 },
+   { "bq25960", BQ25960 },
{},
 };
 MODULE_DEVICE_TABLE(i2c, bq25980_i2c_ids);
-- 
2.25.1

linux-next: build warning after merge of the device-mapper tree

[Stephen Rothwell]

Hi all,

After merging the device-mapper tree, today's linux-next build (htmldocs)
produced this warning:

Documentation/admin-guide/device-mapper/dm-integrity.rst:19
2: WARNING: Unexpected indentation.
Documentation/admin-guide/device-mapper/dm-integrity.rst:193: WARNING: Block 
quote ends without a blank line; unexpected unindent.

Introduced by commit

  61b8b2a834bf ("dm integrity: introduce the "fix_hmac" argument")

-- 
Cheers,
Stephen Rothwell


pgpYJiUJhzOyx.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/2] Enumerate and expose AVX_VNNI feature

[Yang Zhong]

On Thu, Jan 21, 2021 at 04:02:17PM +0100, Paolo Bonzini wrote:
> On 05/01/21 01:49, Yang Zhong wrote:
> >A processor supports AVX_VNNI instructions if CPUID.(EAX=7,ECX=1):EAX[bit 4]
> >is present.
> >
> >This series includes kernel and kvm patches, kernel patch define this
> >new cpu feature bit and kvm expose this bit to guest. When this bit is
> >enabled on cpu or vcpu, the cpu feature flag is shown as "avx_vnni" in
> >/proc/cpuinfo of host and guest.
> >
> >Detailed information on the instruction and CPUID feature flag can be
> >found in the latest "extensions" manual [1].
> >
> >Reference:
> >[1]. 
> >https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html
> >
> >
> >Kyung Min Park (1):
> >   Enumerate AVX Vector Neural Network instructions
> >
> >Yang Zhong (1):
> >   KVM: Expose AVX_VNNI instruction to guset
> >
> >  arch/x86/include/asm/cpufeatures.h | 1 +
> >  arch/x86/kvm/cpuid.c   | 2 +-
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> >
> 
> Queued, thanks.
> 
> Paolo

  Paolo, thanks, i will send the related Qemu patch soon.

  Yang

Re: [PATCH v2 2/5] hugetlb: convert page_huge_active() HPageMigratable flag

[Miaohe Lin]

Hi:
On 2021/1/20 9:30, Mike Kravetz wrote:
> Use the new hugetlb page specific flag HPageMigratable to replace the
> page_huge_active interfaces.  By it's name, page_huge_active implied
> that a huge page was on the active list.  However, that is not really
> what code checking the flag wanted to know.  It really wanted to determine
> if the huge page could be migrated.  This happens when the page is actually
> added the page cache and/or task page table.  This is the reasoning behind

s/added/added to/

> the name change.
> 
> The VM_BUG_ON_PAGE() calls in the *_huge_active() interfaces are not
> really necessary as we KNOW the page is a hugetlb page.  Therefore, they
> are removed.
> 
> The routine page_huge_active checked for PageHeadHuge before testing the
> active bit.  This is unnecessary in the case where we hold a reference or
> lock and know it is a hugetlb head page.  page_huge_active is also called
> without holding a reference or lock (scan_movable_pages), and can race with
> code freeing the page.  The extra check in page_huge_active shortened the
> race window, but did not prevent the race.  Offline code calling
> scan_movable_pages already deals with these races, so removing the check
> is acceptable.  Add comment to racy code.
> 
> Signed-off-by: Mike Kravetz 
> ---
>  fs/hugetlbfs/inode.c   |  2 +-
>  include/linux/hugetlb.h|  5 +
>  include/linux/page-flags.h |  6 -
>  mm/hugetlb.c   | 45 ++
>  mm/memory_hotplug.c|  8 ++-
>  5 files changed, 24 insertions(+), 42 deletions(-)
> 
> diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
> index b8a661780c4a..ec9f03aa2738 100644
> --- a/fs/hugetlbfs/inode.c
> +++ b/fs/hugetlbfs/inode.c
> @@ -735,7 +735,7 @@ static long hugetlbfs_fallocate(struct file *file, int 
> mode, loff_t offset,
>  
>   mutex_unlock(_fault_mutex_table[hash]);
>  
> - set_page_huge_active(page);
> + SetHPageMigratable(page);
>   /*
>* unlock_page because locked by add_to_page_cache()
>* put_page() due to reference from alloc_huge_page()
> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
> index be71a00ee2a0..ce3d03da0133 100644
> --- a/include/linux/hugetlb.h
> +++ b/include/linux/hugetlb.h
> @@ -480,9 +480,13 @@ unsigned long hugetlb_get_unmapped_area(struct file 
> *file, unsigned long addr,
>   * HPG_restore_reserve - Set when a hugetlb page consumes a reservation at
>   *   allocation time.  Cleared when page is fully instantiated.  Free
>   *   routine checks flag to restore a reservation on error paths.
> + * HPG_migratable  - Set after a newly allocated page is added to the page
> + *   cache and/or page tables.  Indicates the page is a candidate for
> + *   migration.
>   */
>  enum hugetlb_page_flags {
>   HPG_restore_reserve = 0,
> + HPG_migratable,
>   __NR_HPAGEFLAGS,
>  };
>  
> @@ -529,6 +533,7 @@ static inline void ClearHPage##uname(struct page *page)   
> \
>   * Create functions associated with hugetlb page flags
>   */
>  HPAGEFLAG(RestoreReserve, restore_reserve)
> +HPAGEFLAG(Migratable, migratable)
>  
>  #ifdef CONFIG_HUGETLB_PAGE
>  
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index bc6fd1ee7dd6..04a34c08e0a6 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -592,15 +592,9 @@ static inline void ClearPageCompound(struct page *page)
>  #ifdef CONFIG_HUGETLB_PAGE
>  int PageHuge(struct page *page);
>  int PageHeadHuge(struct page *page);
> -bool page_huge_active(struct page *page);
>  #else
>  TESTPAGEFLAG_FALSE(Huge)
>  TESTPAGEFLAG_FALSE(HeadHuge)
> -
> -static inline bool page_huge_active(struct page *page)
> -{
> - return 0;
> -}
>  #endif
>  
>  
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 8bed6b5202d2..c24da40626d3 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1353,30 +1353,6 @@ struct hstate *size_to_hstate(unsigned long size)
>   return NULL;
>  }
>  
> -/*
> - * Test to determine whether the hugepage is "active/in-use" (i.e. being 
> linked
> - * to hstate->hugepage_activelist.)
> - *
> - * This function can be called for tail pages, but never returns true for 
> them.
> - */
> -bool page_huge_active(struct page *page)
> -{
> - return PageHeadHuge(page) && PagePrivate([1]);
> -}
> -
> -/* never called for tail page */
> -void set_page_huge_active(struct page *page)
> -{
> - VM_BUG_ON_PAGE(!PageHeadHuge(page), page);
> - SetPagePrivate([1]);
> -}
> -
> -static void clear_page_huge_active(struct page *page)
> -{
> - VM_BUG_ON_PAGE(!PageHeadHuge(page), page);
> - ClearPagePrivate([1]);
> -}
> -
>  /*
>   * Internal hugetlb specific page flag. Do not use outside of the hugetlb
>   * code
> @@ -1438,7 +1414,7 @@ static void __free_huge_page(struct page *page)
>   }
>  
>   spin_lock(_lock);
> - clear_page_huge_active(page);
> + 

arch/riscv/include/asm/pgtable-64.h:70:9: error: use of undeclared identifier 'UL'

[kernel test robot]

Hi Atish,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9f29bd8b2e7132b409178d1367dae1813017bd0e
commit: e557793799c5a8406afb08aa170509619f7eac36 RISC-V: Fix maximum allowed 
phsyical memory for RV32
date:   6 days ago
config: riscv-randconfig-r002-20210122 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
bd3a387ee76f58caa0d7901f3f84e9bb3d006f27)
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
# install riscv cross compiling tool for clang build
# apt-get install binutils-riscv64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e557793799c5a8406afb08aa170509619f7eac36
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout e557793799c5a8406afb08aa170509619f7eac36
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=riscv 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from arch/riscv/kernel/soc.c:7:
   In file included from include/linux/pgtable.h:6:
   In file included from arch/riscv/include/asm/pgtable.h:64:
>> arch/riscv/include/asm/pgtable-64.h:70:9: error: use of undeclared 
>> identifier 'UL'
   return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
  ^
   include/asm-generic/memory_model.h:82:21: note: expanded from macro 
'pfn_to_page'
   #define pfn_to_page __pfn_to_page
   ^
   include/asm-generic/memory_model.h:54:29: note: expanded from macro 
'__pfn_to_page'
   #define __pfn_to_page(pfn)  (vmemmap + (pfn))
^
   arch/riscv/include/asm/pgtable.h:47:34: note: expanded from macro 'vmemmap'
   #define vmemmap ((struct page *)VMEMMAP_START)
   ^
   arch/riscv/include/asm/pgtable.h:41:24: note: expanded from macro 
'VMEMMAP_START'
   #define VMEMMAP_START   (VMALLOC_START - VMEMMAP_SIZE)
^
   arch/riscv/include/asm/pgtable.h:26:27: note: expanded from macro 
'VMALLOC_START'
   #define VMALLOC_START(PAGE_OFFSET - VMALLOC_SIZE)
 ^
   arch/riscv/include/asm/page.h:34:46: note: expanded from macro 'PAGE_OFFSET'
   #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL)
   ^
   In file included from arch/riscv/kernel/soc.c:7:
   In file included from include/linux/pgtable.h:6:
   In file included from arch/riscv/include/asm/pgtable.h:64:
>> arch/riscv/include/asm/pgtable-64.h:70:9: error: use of undeclared 
>> identifier 'UL'
   include/asm-generic/memory_model.h:82:21: note: expanded from macro 
'pfn_to_page'
   #define pfn_to_page __pfn_to_page
   ^
   include/asm-generic/memory_model.h:54:29: note: expanded from macro 
'__pfn_to_page'
   #define __pfn_to_page(pfn)  (vmemmap + (pfn))
^
   arch/riscv/include/asm/pgtable.h:47:34: note: expanded from macro 'vmemmap'
   #define vmemmap ((struct page *)VMEMMAP_START)
   ^
   note: (skipping 2 expansions in backtrace; use -fmacro-backtrace-limit=0 to 
see all)
   arch/riscv/include/asm/pgtable.h:24:27: note: expanded from macro 
'VMALLOC_SIZE'
   #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
 ^
   arch/riscv/include/asm/page.h:36:26: note: expanded from macro 
'KERN_VIRT_SIZE'
   #define KERN_VIRT_SIZE (-PAGE_OFFSET)
^
   arch/riscv/include/asm/page.h:34:46: note: expanded from macro 'PAGE_OFFSET'
   #define PAGE_OFFSET _AC(CONFIG_PAGE_OFFSET, UL)
   ^
   In file included from arch/riscv/kernel/soc.c:7:
   In file included from include/linux/pgtable.h:6:
>> arch/riscv/include/asm/pgtable.h:181:9: error: use of undeclared identifier 
>> 'UL'
   return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
  ^
   include/asm-generic/memory_model.h:82:21: note: expanded from macro 
'pfn_to_page'
   #define pfn_to_page __pfn_to_page
   ^
   include/asm-generic/memory_model.h:54:29: note: expanded from macro 
'__pfn_to_page'
   #define __pfn_to_page(pfn)  (vmemmap + (pfn))
^
   arch/riscv/include/asm/pgtable.h:47:34: note: expanded from macro 'vmemmap'
   #define vmemmap ((struct page *)VMEMMAP_START)
   ^
   arch/riscv/include/asm/pgtable.h:41:24: note: expanded from 

Re: [PATCH V4 0/3] scripts: dtc: Build fdtoverlay

[David Gibson]

On Wed, Jan 20, 2021 at 10:47:40AM +0530, Viresh Kumar wrote:
> +David.
> 
> On 19-01-21, 11:12, Frank Rowand wrote:
> > On 1/12/21 2:28 AM, Viresh Kumar wrote:
> > > We will start building overlays for platforms soon in the kernel and
> > > would need fdtoverlay tool going forward. Lets start fetching and
> > > building it.
> > > 
> > > While at it, also remove fdtdump.c file, which isn't used by the kernel.
> > > 
> > > V4:
> > > - Don't fetch and build fdtdump.c
> > > - Remove fdtdump.c
> > > 
> > > Viresh Kumar (3):
> > >   scripts: dtc: Add fdtoverlay.c to DTC_SOURCE
> > >   scripts: dtc: Build fdtoverlay tool
> > >   scripts: dtc: Remove the unused fdtdump.c file
> > > 
> > >  scripts/dtc/Makefile |   6 +-
> > >  scripts/dtc/fdtdump.c| 163 ---
> > >  scripts/dtc/update-dtc-source.sh |   6 +-
> > >  3 files changed, 8 insertions(+), 167 deletions(-)
> > >  delete mode 100644 scripts/dtc/fdtdump.c
> > > 
> > 
> > My first inclination was to accept fdtoverlay, as is, from the upstream
> > project.
> > 
> > But my experiences debugging use of fdtoverlay against the existing
> > unittest overlay files has me very wary of accepting fdtoverlay in
> > it's current form.
> > 
> > As an exmple, adding an overlay that fails to reply results in the
> > following build messages:
> > 
> >linux--5.11-rc> make zImage
> >make[1]: Entering directory 
> > '/local/frowand_nobackup/src/git_linus/build/dragon_linus_5.11-rc'
> >  GEN Makefile
> >  CALL
> > /local/frowand_nobackup/src/git_linus/linux--5.11-rc/scripts/checksyscalls.sh
> >  CALL
> > /local/frowand_nobackup/src/git_linus/linux--5.11-rc/scripts/atomic/check-atomics.sh
> >  CHK include/generated/compile.h
> >  FDTOVERLAY drivers/of/unittest-data/static_test.dtb
> > 
> >Failed to apply 'drivers/of/unittest-data/overlay.dtb': FDT_ERR_NOTFOUND
> >make[4]: *** 
> > [/local/frowand_nobackup/src/git_linus/linux--5.11-rc/drivers/of/unittest-data/Makefile:96:
> >  drivers/of/unittest-data/static_test.dtb] Error 1
> >make[3]: *** 
> > [/local/frowand_nobackup/src/git_linus/linux--5.11-rc/scripts/Makefile.build:496:
> >  drivers/of/unittest-data] Error 2
> >make[2]: *** 
> > [/local/frowand_nobackup/src/git_linus/linux--5.11-rc/scripts/Makefile.build:496:
> >  drivers/of] Error 2
> >make[1]: *** 
> > [/local/frowand_nobackup/src/git_linus/linux--5.11-rc/Makefile:1805: 
> > drivers] Error 2
> >make[1]: Leaving directory 
> > '/local/frowand_nobackup/src/git_linus/build/dragon_linus_5.11-rc'
> >make: *** [Makefile:185: __sub-make] Error 2
> > 
> > 
> > The specific error message (copied from above) is:
> > 
> >Failed to apply 'drivers/of/unittest-data/overlay.dtb': FDT_ERR_NOTFOUND
> > 
> > which is cryptic and does not even point to the location in the overlay that
> > is problematic.  If you look at the source of fdtoverlay / libfdt, you will
> > find that FDT_ERR_NOTFOUND may be generated in one of many places.
> > 
> > I do _not_ want to do a full review of fdtoverlay, but I think that it is
> > reasonable to request enhancing fdtoverlay in the parent project to generate
> > usable error messages before enabling fdtoverlay in the Linux kernel tree.

That's... actually much harder than it sounds.  fdtoverlay is
basically a trivial wrapper around the fdt_overlay_apply() function in
libfdt.  Matching the conventions of the rest of the library, really
it's only way to report errors is a single error code.

Returning richer errors is not an easy problem in a C library,
especially one designed to be usable in embedded systems, without an
allocator or much else available.

Of course it would be possible to write a friendly command line tool
specifically for applying overlays, which could give better errors.
fdtoverlay as it stands isn't really that - it was pretty much written
just to invoke fdt_overlay_apply() in testcases.

> > fdtoverlay in it's current form adds a potential maintenance burden to me
> > (as the overlay maintainer).  I now have the experience of how difficult it
> > was to debug the use of fdtoverlay in the context of the proposed patch to
> > use it with the devicetree unittest overlay .dtb files.
> > 
> > -Frank
> 

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

[RFC PATCH 1/4] jbd2: make jdb2_debug module parameter per device

[Chunguang Xu]

From: Chunguang Xu 

On a multi-disk machine, because jbd2's debugging switch is global,this
confuses the logs of multiple disks. It is not easy to distinguish the
logs of each disk and the amount of generated logs is very large. Or a
separate debugging switch for each disk would be better, so that you
can easily distinguish the logs of a certain disk.

Signed-off-by: Chunguang Xu 
---
 fs/jbd2/journal.c | 63 +++
 fs/jbd2/transaction.c |  2 +-
 include/linux/jbd2.h  |  7 +
 3 files changed, 60 insertions(+), 12 deletions(-)

diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index 2dc92802..ae147cc713c7 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -48,14 +48,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_JBD2_DEBUG
-ushort jbd2_journal_enable_debug __read_mostly;
-EXPORT_SYMBOL(jbd2_journal_enable_debug);
-
-module_param_named(jbd2_debug, jbd2_journal_enable_debug, ushort, 0644);
-MODULE_PARM_DESC(jbd2_debug, "Debugging level for jbd2");
-#endif
-
 EXPORT_SYMBOL(jbd2_journal_extend);
 EXPORT_SYMBOL(jbd2_journal_stop);
 EXPORT_SYMBOL(jbd2_journal_lock_updates);
@@ -101,13 +93,13 @@ EXPORT_SYMBOL(jbd2_inode_cache);
 static int jbd2_journal_create_slab(size_t slab_size);
 
 #ifdef CONFIG_JBD2_DEBUG
-void __jbd2_debug(int level, const char *file, const char *func,
+void jbd2_log(int level, journal_t *j, const char *file, const char *func,
  unsigned int line, const char *fmt, ...)
 {
struct va_format vaf;
va_list args;
 
-   if (level > jbd2_journal_enable_debug)
+   if (!j || level > j->j_debug_level)
return;
va_start(args, fmt);
vaf.fmt = fmt;
@@ -115,7 +107,7 @@ void __jbd2_debug(int level, const char *file, const char 
*func,
printk(KERN_DEBUG "%s: (%s, %u): %pV", file, func, line, );
va_end(args);
 }
-EXPORT_SYMBOL(__jbd2_debug);
+EXPORT_SYMBOL(jbd2_log);
 #endif
 
 /* Checksumming functions */
@@ -1257,6 +1249,48 @@ static int jbd2_seq_info_release(struct inode *inode, 
struct file *file)
return seq_release(inode, file);
 }
 
+#ifdef CONFIG_JBD2_DEBUG
+static int jbd2_proc_debug_show(struct seq_file *m, void *v)
+{
+   journal_t *j = m->private;
+
+   seq_printf(m, "%d\n", j->j_debug_level);
+   return 0;
+}
+
+static int jbd2_proc_debug_open(struct inode *inode, struct file *file)
+{
+   journal_t *journal = PDE_DATA(inode);
+
+   return single_open(file, jbd2_proc_debug_show, journal);
+}
+
+static ssize_t jbd2_proc_debug_write(struct file *file,
+   const char __user *buffer, size_t count, loff_t *ppos)
+{
+   struct seq_file *seq = file->private_data;
+   journal_t *j = seq->private;
+   char c;
+
+   if (get_user(c, buffer))
+   return -EFAULT;
+
+   if (c < '0' || c > '5')
+   return -EINVAL;
+
+   j->j_debug_level = c - '0';
+   return count;
+}
+
+static const struct proc_ops jbd2_debug_proc_ops = {
+   .proc_open  = jbd2_proc_debug_open,
+   .proc_read  = seq_read,
+   .proc_write = jbd2_proc_debug_write,
+   .proc_release   = single_release,
+   .proc_lseek = seq_lseek,
+};
+#endif
+
 static const struct proc_ops jbd2_info_proc_ops = {
.proc_open  = jbd2_seq_info_open,
.proc_read  = seq_read,
@@ -1272,12 +1306,19 @@ static void jbd2_stats_proc_init(journal_t *journal)
if (journal->j_proc_entry) {
proc_create_data("info", S_IRUGO, journal->j_proc_entry,
 _info_proc_ops, journal);
+#ifdef CONFIG_JBD2_DEBUG
+   proc_create_data("jbd2_debug", S_IRUGO, journal->j_proc_entry,
+_debug_proc_ops, journal);
+#endif
}
 }
 
 static void jbd2_stats_proc_exit(journal_t *journal)
 {
remove_proc_entry("info", journal->j_proc_entry);
+#ifdef CONFIG_JBD2_DEBUG
+   remove_proc_entry("jbd2_debug", journal->j_proc_entry);
+#endif
remove_proc_entry(journal->j_devname, proc_jbd2_stats);
 }
 
diff --git a/fs/jbd2/transaction.c b/fs/jbd2/transaction.c
index 939b7314..f25c6ff16165 100644
--- a/fs/jbd2/transaction.c
+++ b/fs/jbd2/transaction.c
@@ -150,7 +150,7 @@ static inline void update_t_max_wait(transaction_t 
*transaction,
 unsigned long ts)
 {
 #ifdef CONFIG_JBD2_DEBUG
-   if (jbd2_journal_enable_debug &&
+   if (transaction->t_journal->j_debug_level &&
time_after(transaction->t_start, ts)) {
ts = jbd2_time_diff(ts, transaction->t_start);
spin_lock(>t_handle_lock);
diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 99d3cd051ac3..600a2ea8324a 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -1211,6 +1211,13 @@ struct journal_s
 */
struct transaction_stats_s j_stats;
 
+#ifdef CONFIG_JBD2_DEBUG
+   /**
+* @j_debug_level: debugging level for jbd2.
+   

[RFC PATCH 3/4] jbd2: replace jbd_debug with the new log interface

[Chunguang Xu]

From: Chunguang Xu 

In order to support jbd2 per device debugging switch, here we need to
replace jbd_debug with a new log interface. But there is a small
disadvantage here. Because the debugging switch is placed in the journal_t
object, the log before the object is initialized will be lost. However,
usually this will not have much impact on debugging.

Signed-off-by: Chunguang Xu 
---
 fs/jbd2/checkpoint.c  |  6 ++---
 fs/jbd2/commit.c  | 36 +-
 fs/jbd2/journal.c | 59 ---
 fs/jbd2/recovery.c| 59 +++
 fs/jbd2/revoke.c  |  8 +++---
 fs/jbd2/transaction.c | 33 
 6 files changed, 100 insertions(+), 101 deletions(-)

diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index 472932b9e6bc..916f0c495805 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -211,7 +211,7 @@ int jbd2_log_do_checkpoint(journal_t *journal)
tid_t   this_tid;
int result, batch_count = 0;
 
-   jbd_debug(1, "Start checkpoint\n");
+   jbd2_err(journal, "Start checkpoint\n");
 
/*
 * First thing: if there are any transactions in the log which
@@ -220,7 +220,7 @@ int jbd2_log_do_checkpoint(journal_t *journal)
 */
result = jbd2_cleanup_journal_tail(journal);
trace_jbd2_checkpoint(journal, result);
-   jbd_debug(1, "cleanup_journal_tail returned %d\n", result);
+   jbd2_err(journal, "cleanup_journal_tail returned %d\n", result);
if (result <= 0)
return result;
 
@@ -676,5 +676,5 @@ void __jbd2_journal_drop_transaction(journal_t *journal, 
transaction_t *transact
 
trace_jbd2_drop_transaction(journal, transaction);
 
-   jbd_debug(1, "Dropping transaction %d, all done\n", transaction->t_tid);
+   jbd2_err(journal, "Dropping transaction %d, all done\n", 
transaction->t_tid);
 }
diff --git a/fs/jbd2/commit.c b/fs/jbd2/commit.c
index b121d7d434c6..47b7019268ed 100644
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -419,7 +419,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
 
/* Do we need to erase the effects of a prior jbd2_journal_flush? */
if (journal->j_flags & JBD2_FLUSHED) {
-   jbd_debug(3, "super block updated\n");
+   jbd2_notice(journal, "super block updated\n");
mutex_lock_io(>j_checkpoint_mutex);
/*
 * We hold j_checkpoint_mutex so tail cannot change under us.
@@ -433,7 +433,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
REQ_SYNC);
mutex_unlock(>j_checkpoint_mutex);
} else {
-   jbd_debug(3, "superblock not updated\n");
+   jbd2_notice(journal, "superblock not updated\n");
}
 
J_ASSERT(journal->j_running_transaction != NULL);
@@ -465,7 +465,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
commit_transaction = journal->j_running_transaction;
 
trace_jbd2_start_commit(journal, commit_transaction);
-   jbd_debug(1, "JBD2: starting commit of transaction %d\n",
+   jbd2_err(journal, "JBD2: starting commit of transaction %d\n",
commit_transaction->t_tid);
 
write_lock(>j_state_lock);
@@ -549,7 +549,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
__jbd2_journal_clean_checkpoint_list(journal, false);
spin_unlock(>j_list_lock);
 
-   jbd_debug(3, "JBD2: commit phase 1\n");
+   jbd2_notice(journal, "JBD2: commit phase 1\n");
 
/*
 * Clear revoked flag to reflect there is no revoked buffers
@@ -582,7 +582,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
wake_up(>j_wait_transaction_locked);
write_unlock(>j_state_lock);
 
-   jbd_debug(3, "JBD2: commit phase 2a\n");
+   jbd2_notice(journal, "JBD2: commit phase 2a\n");
 
/*
 * Now start flushing things to disk, in the order they appear
@@ -595,7 +595,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
blk_start_plug();
jbd2_journal_write_revoke_records(commit_transaction, _bufs);
 
-   jbd_debug(3, "JBD2: commit phase 2b\n");
+   jbd2_notice(journal, "JBD2: commit phase 2b\n");
 
/*
 * Way to go: we have now written out all of the data for a
@@ -651,7 +651,7 @@ void jbd2_journal_commit_transaction(journal_t *journal)
if (!descriptor) {
J_ASSERT (bufs == 0);
 
-   jbd_debug(4, "JBD2: get descriptor\n");
+   jbd2_info(journal, "JBD2: get descriptor\n");
 
descriptor = jbd2_journal_get_descriptor_buffer(
commit_transaction,
@@ -661,9 +661,9 @@ void jbd2_journal_commit_transaction(journal_t 

[RFC PATCH 4/4] ext4: replace jbd_debug with the new log interface

[Chunguang Xu]

From: Chunguang Xu 

In order to support jbd2 per device debugging switch, here we need to
replace jbd_debug with a new log interface. But there is a small
disadvantage here. Because the debugging switch is placed in the journal_t
object, the log before the object is initialized will be lost. However,
usually this will not have much impact on debugging.

Signed-off-by: Chunguang Xu 
---
 fs/ext4/balloc.c  |  2 +-
 fs/ext4/ext4_jbd2.c   |  3 +-
 fs/ext4/fast_commit.c | 64 +++
 fs/ext4/indirect.c|  4 +--
 fs/ext4/inode.c   |  3 +-
 fs/ext4/namei.c   | 10 +++
 fs/ext4/super.c   | 16 ++-
 7 files changed, 56 insertions(+), 46 deletions(-)

diff --git a/fs/ext4/balloc.c b/fs/ext4/balloc.c
index f45f9feebe59..469aec970b36 100644
--- a/fs/ext4/balloc.c
+++ b/fs/ext4/balloc.c
@@ -645,7 +645,7 @@ int ext4_should_retry_alloc(struct super_block *sb, int 
*retries)
if (EXT4_SB(sb)->s_mb_free_pending == 0)
return 0;
 
-   jbd_debug(1, "%s: retrying operation after ENOSPC\n", sb->s_id);
+   jbd2_err(EXT4_SB(sb)->s_journal, "%s: retrying operation after 
ENOSPC\n", sb->s_id);
jbd2_journal_force_commit_nested(EXT4_SB(sb)->s_journal);
return 1;
 }
diff --git a/fs/ext4/ext4_jbd2.c b/fs/ext4/ext4_jbd2.c
index be799040a415..5c1c06662019 100644
--- a/fs/ext4/ext4_jbd2.c
+++ b/fs/ext4/ext4_jbd2.c
@@ -259,7 +259,8 @@ int __ext4_forget(const char *where, unsigned int line, 
handle_t *handle,
trace_ext4_forget(inode, is_metadata, blocknr);
BUFFER_TRACE(bh, "enter");
 
-   jbd_debug(4, "forgetting bh %p: is_metadata = %d, mode %o, "
+   jbd2_info(EXT4_SB(inode->i_sb)->s_journal,
+ "forgetting bh %p: is_metadata = %d, mode %o, "
  "data mode %x\n",
  bh, is_metadata, inode->i_mode,
  test_opt(inode->i_sb, DATA_FLAGS));
diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
index 0a14a7c87bf8..1356b7063c99 100644
--- a/fs/ext4/fast_commit.c
+++ b/fs/ext4/fast_commit.c
@@ -865,8 +865,9 @@ static int ext4_fc_write_inode_data(struct inode *inode, 
u32 *crc)
mutex_unlock(>i_fc_lock);
 
cur_lblk_off = old_blk_size;
-   jbd_debug(1, "%s: will try writing %d to %d for inode %ld\n",
- __func__, cur_lblk_off, new_blk_size, inode->i_ino);
+   jbd2_err(EXT4_SB(inode->i_sb)->s_journal,
+"%s: will try writing %d to %d for inode %ld\n",
+__func__, cur_lblk_off, new_blk_size, inode->i_ino);
 
while (cur_lblk_off <= new_blk_size) {
map.m_lblk = cur_lblk_off;
@@ -1207,7 +1208,7 @@ int ext4_fc_commit(journal_t *journal, tid_t commit_tid)
sbi->s_fc_avg_commit_time * 3) / 4;
else
sbi->s_fc_avg_commit_time = commit_time;
-   jbd_debug(1,
+   jbd2_err(sbi->s_journal,
"Fast commit ended with blks = %d, reason = %d, subtid - %d",
nblks, reason, subtid);
if (reason == EXT4_FC_REASON_FC_FAILED)
@@ -1319,14 +1320,15 @@ static int ext4_fc_replay_unlink(struct super_block 
*sb, struct ext4_fc_tl *tl)
inode = ext4_iget(sb, darg.ino, EXT4_IGET_NORMAL);
 
if (IS_ERR(inode)) {
-   jbd_debug(1, "Inode %d not found", darg.ino);
+   jbd2_err(EXT4_SB(sb)->s_journal, "Inode %d not found", 
darg.ino);
return 0;
}
 
old_parent = ext4_iget(sb, darg.parent_ino,
EXT4_IGET_NORMAL);
if (IS_ERR(old_parent)) {
-   jbd_debug(1, "Dir with inode  %d not found", darg.parent_ino);
+   jbd2_err(EXT4_SB(sb)->s_journal, "Dir with inode  %d not found",
+darg.parent_ino);
iput(inode);
return 0;
}
@@ -1351,21 +1353,22 @@ static int ext4_fc_replay_link_internal(struct 
super_block *sb,
 
dir = ext4_iget(sb, darg->parent_ino, EXT4_IGET_NORMAL);
if (IS_ERR(dir)) {
-   jbd_debug(1, "Dir with inode %d not found.", darg->parent_ino);
+   jbd2_err(EXT4_SB(sb)->s_journal, "Dir with inode %d not found.",
+darg->parent_ino);
dir = NULL;
goto out;
}
 
dentry_dir = d_obtain_alias(dir);
if (IS_ERR(dentry_dir)) {
-   jbd_debug(1, "Failed to obtain dentry");
+   jbd2_err(EXT4_SB(sb)->s_journal, "Failed to obtain dentry");
dentry_dir = NULL;
goto out;
}
 
dentry_inode = d_alloc(dentry_dir, _dname);
if (!dentry_inode) {
-   jbd_debug(1, "Inode dentry not created.");
+   jbd2_err(EXT4_SB(sb)->s_journal, "Inode dentry not created.");
ret = -ENOMEM;
goto out;
}
@@ -1378,7 +1381,7 @@ static int ext4_fc_replay_link_internal(struct 
super_block *sb,

[RFC PATCH 2/4] jbd2: introduce some new log interfaces

[Chunguang Xu]

From: Chunguang Xu 

Compared to directly using numbers to indicate levels, using abstract
error, warn, notice, info, debug to indicate levels may be more
convenient for code reading and writing. Similar to other kernel
modules, some basic log interfaces are introduced.

Signed-off-by: Chunguang Xu 
---
 include/linux/jbd2.h | 58 +++-
 1 file changed, 41 insertions(+), 17 deletions(-)

diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
index 600a2ea8324a..d3d3ed33be30 100644
--- a/include/linux/jbd2.h
+++ b/include/linux/jbd2.h
@@ -47,23 +47,6 @@
  */
 #define JBD2_DEFAULT_MAX_COMMIT_AGE 5
 
-#ifdef CONFIG_JBD2_DEBUG
-/*
- * Define JBD2_EXPENSIVE_CHECKING to enable more expensive internal
- * consistency checks.  By default we don't do this unless
- * CONFIG_JBD2_DEBUG is on.
- */
-#define JBD2_EXPENSIVE_CHECKING
-extern ushort jbd2_journal_enable_debug;
-void __jbd2_debug(int level, const char *file, const char *func,
- unsigned int line, const char *fmt, ...);
-
-#define jbd_debug(n, fmt, a...) \
-   __jbd2_debug((n), __FILE__, __func__, __LINE__, (fmt), ##a)
-#else
-#define jbd_debug(n, fmt, a...)/**/
-#endif
-
 extern void *jbd2_alloc(size_t size, gfp_t flags);
 extern void jbd2_free(void *ptr, size_t size);
 
@@ -104,6 +87,47 @@ typedef struct jbd2_journal_handle handle_t;/* 
Atomic operation type */
  * This is an opaque datatype.
  **/
 typedef struct journal_s   journal_t;  /* Journal control structure */
+
+#ifdef CONFIG_JBD2_DEBUG
+/*
+ * Define JBD2_EXPENSIVE_CHECKING to enable more expensive internal
+ * consistency checks.  By default we don't do this unless
+ * CONFIG_JBD2_DEBUG is on.
+ */
+#define JBD2_EXPENSIVE_CHECKING
+void jbd2_log(int level, journal_t *j, const char *file, const char *func,
+ unsigned int line, const char *fmt, ...);
+
+#define JBD2_ERR   1   /* error conditions */
+#define JBD2_WARN  2   /* warning conditions */
+#define JBD2_NOTICE3   /* normal but significant condition */
+#define JBD2_INFO  4   /* informational */
+#define JBD2_DEBUG 5   /* debug-level messages */
+
+#define jbd2_err(j, fmt, a...) \
+   jbd2_log(JBD2_ERR, j, __FILE__, __func__, __LINE__, (fmt), ##a)
+
+#define jbd2_warn(j, fmt, a...)
\
+   jbd2_log(JBD2_WARN, j, __FILE__, __func__, __LINE__, (fmt), ##a)
+
+#define jbd2_notice(j, fmt, a...)  \
+   jbd2_log(JBD2_NOTICE, j, __FILE__, __func__, __LINE__, (fmt), ##a)
+
+#define jbd2_info(j, fmt, a...)
\
+   jbd2_log(JBD2_INFO, j, __FILE__, __func__, __LINE__, (fmt), ##a)
+
+#define jbd2_debug(j, fmt, a...)   \
+   jbd2_log(JBD2_DEBUG, j, __FILE__, __func__, __LINE__, (fmt), ##a)
+
+#else
+
+#define jbd2_err(j, fmt, a...)
+#define jbd2_warn(j, fmt, a...)
+#define jbd2_notice(j, fmt, a...)
+#define jbd2_info(j, fmt, a...)
+#define jbd2_debug(j, fmt, a...)
+
+#endif
 #endif
 
 /*
-- 
2.30.0

[RFC PATCH 0/4] make jbd2 debug switch per device

[Chunguang Xu]

On a multi-disk machine, because jbd2 debugging switch is global, this
confuses the logs of multiple disks. It is not easy to distinguish the
logs of each disk and the amount of generated logs is very large. Or a
separate debugging switch for each disk would be better, so that you
can easily distinguish the logs of a certain disk. 

We can enable jbd2 debugging of a device in the following ways:
echo X > /proc/fs/jbd2/sdX/jbd2_debug

But there is a small disadvantage here. Because the debugging switch is
placed in the journal_t object, the log before the object is initialized
will be lost. However, usually this will not have much impact on
debugging.

Chunguang Xu (4):
  jbd2: make jdb2_debug module parameter per device
  jbd2: introduce some new log interfaces
  jbd2: replace jbd_debug with the new log interface
  ext4: replace jbd_debug with the new log interface

 fs/ext4/balloc.c  |   2 +-
 fs/ext4/ext4_jbd2.c   |   3 +-
 fs/ext4/fast_commit.c |  64 --
 fs/ext4/indirect.c|   4 +-
 fs/ext4/inode.c   |   3 +-
 fs/ext4/namei.c   |  10 ++--
 fs/ext4/super.c   |  16 +++---
 fs/jbd2/checkpoint.c  |   6 +--
 fs/jbd2/commit.c  |  36 ++---
 fs/jbd2/journal.c | 122 +++---
 fs/jbd2/recovery.c|  59 ++--
 fs/jbd2/revoke.c  |   8 +--
 fs/jbd2/transaction.c |  35 ++--
 include/linux/jbd2.h  |  65 --
 14 files changed, 257 insertions(+), 176 deletions(-)

-- 
2.30.0

RE: [PATCH 1/3] iommu/vt-d: Add rate limited information when PRQ overflows

[Tian, Kevin]

> From: Lu Baolu 
> Sent: Thursday, January 21, 2021 9:45 AM
> 
> So that the uses could get chances to know what happened.
> 
> Suggested-by: Ashok Raj 
> Signed-off-by: Lu Baolu 
> ---
>  drivers/iommu/intel/svm.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
> index 033b25886e57..f49fe715477b 100644
> --- a/drivers/iommu/intel/svm.c
> +++ b/drivers/iommu/intel/svm.c
> @@ -895,6 +895,7 @@ static irqreturn_t prq_event_thread(int irq, void *d)
>   struct intel_iommu *iommu = d;
>   struct intel_svm *svm = NULL;
>   int head, tail, handled = 0;
> + struct page_req_dsc *req;
> 
>   /* Clear PPR bit before reading head/tail registers, to
>* ensure that we get a new interrupt if needed. */
> @@ -904,7 +905,6 @@ static irqreturn_t prq_event_thread(int irq, void *d)
>   head = dmar_readq(iommu->reg + DMAR_PQH_REG) &
> PRQ_RING_MASK;
>   while (head != tail) {
>   struct vm_area_struct *vma;
> - struct page_req_dsc *req;
>   struct qi_desc resp;
>   int result;
>   vm_fault_t ret;
> @@ -1042,8 +1042,14 @@ static irqreturn_t prq_event_thread(int irq, void
> *d)
>* Clear the page request overflow bit and wake up all threads that
>* are waiting for the completion of this handling.
>*/
> - if (readl(iommu->reg + DMAR_PRS_REG) & DMA_PRS_PRO)
> + if (readl(iommu->reg + DMAR_PRS_REG) & DMA_PRS_PRO) {
> + head = dmar_readq(iommu->reg + DMAR_PQH_REG) &
> PRQ_RING_MASK;
> + req = >prq[head / sizeof(*req)];
> + pr_warn_ratelimited("IOMMU: %s: Page request overflow:
> HEAD: %08llx %08llx",
> + iommu->name, ((unsigned long long
> *)req)[0],
> + ((unsigned long long *)req)[1]);
>   writel(DMA_PRS_PRO, iommu->reg + DMAR_PRS_REG);
> + }
> 

Not about rate limiting but I think we may have a problem in above
logic. It is incorrect to always clear PRO when it's set w/o first checking
whether the overflow condition has been cleared. This code assumes
that if an overflow condition occurs it must have been cleared by earlier
loop when hitting this check. However since this code runs in a threaded 
context, the overflow condition could occur even after you reset the head 
to the tail (under some extreme condition). To be sane I think we'd better
read both head/tail again after seeing a pending PRO here and only clear 
PRO when it becomes a false indicator based on latest head/tail.

Thanks
Kevin

Re: [PATCH v3] soc/tegra: Add devm_tegra_core_dev_init_opp_table()

[Viresh Kumar]

On 21-01-21, 22:01, Dmitry Osipenko wrote:
> Add common helper which initializes OPP table for Tegra SoC core devices.
> 
> Tested-by: Peter Geis  # Ouya T30
> Tested-by: Dmitry Osipenko  # A500 T20 and Nexus7 T30
> Tested-by: Nicolas Chauvet  # PAZ00 T20 and TK1 T124
> Tested-by: Matt Merhar  # Ouya T30
> [tested on some other non-upstreamed-yet T20/30/114 devices as well]
> Signed-off-by: Dmitry Osipenko 
> ---
> 
> Changelog:
> 
> v3: - This patch is factored out from [1] to ease merging of the patches
>   that will use the new helper. The goal is to get this new helper
>   into 5.12, this should remove dependency on this patch for a several
>   patchsets of a different subsystems (DRM, media, memory, etc) that
>   will target 5.13.
> 
>   @Thierry/Jon, please review and apply this patch for 5.12!

This is not how stuff works in kernel Dmitry, every commit in the
kernel tree should build(at least)/boot fine. Your patch can only be
applied once your base tree has all the patches on which your work is
based of, otherwise this will lead to build failure (stuff like git
bisect breaks with that). It would be better if you take this patch in
5.13, or after 5.12-rc2 once all other stuff lands.

-- 
viresh

[rcu:tglx-pc.2021.01.21a] BUILD SUCCESS 1fa4714af1ec25d1f76a1d736cc7987c36ba7c27

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
tglx-pc.2021.01.21a
branch HEAD: 1fa4714af1ec25d1f76a1d736cc7987c36ba7c27  rcu/tree: Allocate a 
page when caller is preemptible

elapsed time: 752m

configs tested: 93
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
powerpc   motionpro_defconfig
c6xevmc6457_defconfig
mips tb0226_defconfig
mips   ip22_defconfig
powerpcicon_defconfig
mipsnlm_xlp_defconfig
h8300   h8s-sim_defconfig
mipsjmr3927_defconfig
mipsmaltaup_xpa_defconfig
sparc64  alldefconfig
armcerfcube_defconfig
m68kstmark2_defconfig
arm cm_x300_defconfig
mips   ip27_defconfig
m68k amcore_defconfig
powerpc sequoia_defconfig
mips  ath25_defconfig
arm orion5x_defconfig
arm  colibri_pxa300_defconfig
powerpc tqm8541_defconfig
ia64generic_defconfig
arm lubbock_defconfig
s390 alldefconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a002-20210121
x86_64   randconfig-a003-20210121
x86_64   randconfig-a001-20210121
x86_64   randconfig-a005-20210121
x86_64   randconfig-a006-20210121
x86_64   randconfig-a004-20210121
i386 randconfig-a001-20210121
i386 randconfig-a002-20210121
i386 randconfig-a004-20210121
i386 randconfig-a006-20210121
i386 randconfig-a005-20210121
i386 randconfig-a003-20210121
i386 randconfig-a013-20210121
i386 randconfig-a011-20210121
i386 randconfig-a012-20210121
i386 randconfig-a014-20210121
i386 randconfig-a015-20210121
i386 randconfig-a016-20210121
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  rhel-8.3-kbuiltin
x86_64  kexec

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org

Re: [PATCH v3] soc/tegra: Add devm_tegra_core_dev_init_opp_table()

[kernel test robot]

Hi Dmitry,

I love your patch! Yet something to improve:

[auto build test ERROR on tegra/for-next]
[also build test ERROR on v5.11-rc4 next-20210121]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Dmitry-Osipenko/soc-tegra-Add-devm_tegra_core_dev_init_opp_table/20210122-032018
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git for-next
config: arm-defconfig (attached as .config)
compiler: arm-linux-gnueabi-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://github.com/0day-ci/linux/commit/d506fc2521a717df9b74b7106dbc8f2912b39e05
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Dmitry-Osipenko/soc-tegra-Add-devm_tegra_core_dev_init_opp_table/20210122-032018
git checkout d506fc2521a717df9b74b7106dbc8f2912b39e05
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arm 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/soc/tegra/common.c: In function 'devm_tegra_core_dev_init_opp_table':
>> drivers/soc/tegra/common.c:122:14: error: implicit declaration of function 
>> 'devm_pm_opp_set_clkname'; did you mean 'dev_pm_opp_set_clkname'? 
>> [-Werror=implicit-function-declaration]
 122 |  opp_table = devm_pm_opp_set_clkname(dev, NULL);
 |  ^~~
 |  dev_pm_opp_set_clkname
   drivers/soc/tegra/common.c:122:12: warning: assignment to 'struct opp_table 
*' from 'int' makes pointer from integer without a cast [-Wint-conversion]
 122 |  opp_table = devm_pm_opp_set_clkname(dev, NULL);
 |^
>> drivers/soc/tegra/common.c:138:14: error: implicit declaration of function 
>> 'devm_pm_opp_set_supported_hw'; did you mean 'dev_pm_opp_set_supported_hw'? 
>> [-Werror=implicit-function-declaration]
 138 |  opp_table = devm_pm_opp_set_supported_hw(dev, _version, 1);
 |  ^~~~
 |  dev_pm_opp_set_supported_hw
   drivers/soc/tegra/common.c:138:12: warning: assignment to 'struct opp_table 
*' from 'int' makes pointer from integer without a cast [-Wint-conversion]
 138 |  opp_table = devm_pm_opp_set_supported_hw(dev, _version, 1);
 |^
>> drivers/soc/tegra/common.c:152:8: error: implicit declaration of function 
>> 'devm_pm_opp_of_add_table'; did you mean 'dev_pm_opp_of_add_table'? 
>> [-Werror=implicit-function-declaration]
 152 |  err = devm_pm_opp_of_add_table(dev);
 |^~~~
 |dev_pm_opp_of_add_table
   cc1: some warnings being treated as errors


vim +122 drivers/soc/tegra/common.c

   105  
   106  /**
   107   * devm_tegra_core_dev_init_opp_table() - initialize OPP table
   108   * @cfg: pointer to the OPP table configuration
   109   *
   110   * This function will initialize OPP table and sync OPP state of a 
Tegra SoC
   111   * core device.
   112   *
   113   * Return: 0 on success or errorno.
   114   */
   115  int devm_tegra_core_dev_init_opp_table(struct device *dev,
   116 struct tegra_core_opp_params 
*params)
   117  {
   118  struct opp_table *opp_table;
   119  u32 hw_version;
   120  int err;
   121  
 > 122  opp_table = devm_pm_opp_set_clkname(dev, NULL);
   123  if (IS_ERR(opp_table)) {
   124  dev_err(dev, "failed to set OPP clk %pe\n", opp_table);
   125  return PTR_ERR(opp_table);
   126  }
   127  
   128  /* Tegra114+ doesn't support OPP yet */
   129  if (!of_machine_is_compatible("nvidia,tegra20") &&
   130  !of_machine_is_compatible("nvidia,tegra30"))
   131  return -ENODEV;
   132  
   133  if (of_machine_is_compatible("nvidia,tegra20"))
   134  hw_version = BIT(tegra_sku_info.soc_process_id);
   135  else
   136  hw_version = BIT(tegra_sku_info.soc_speedo_id);
   137  
 > 138  opp_table = devm_pm_opp_set_supported_hw(dev, _version, 1);
   139  if (IS_ERR(opp_table)) {
   140  dev_err(dev, "failed to set OPP supported HW: %pe\n", 
opp_table);
   141  return PTR_ERR(opp_table);
   142  }
   143  
   144  /*
   145   * Older device-trees have an empty OPP table

Re: [PATCH v3 1/2] dt-bindings: nvmem: mediatek: add support for MediaTek mt8192 SoC

[mtk23264]

On Sun, 2021-01-03 at 09:25 -0700, Rob Herring wrote:
> On Mon, Dec 21, 2020 at 02:10:19PM +0800, yz...@mediatek.com wrote:
> > From: Ryan Wu 
> > 
> > This updates dt-binding documentation for MediaTek mt8192
> > 
> > Signed-off-by: Ryan Wu 
> > ---
> > This patch is based on v5.10-rc7.
> > ---
> >  Documentation/devicetree/bindings/nvmem/mtk-efuse.txt | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt 
> > b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> > index 0668c45a156d..e2f0c0f34d10 100644
> > --- a/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> > +++ b/Documentation/devicetree/bindings/nvmem/mtk-efuse.txt
> > @@ -7,6 +7,7 @@ Required properties:
> >   "mediatek,mt7622-efuse", "mediatek,efuse": for MT7622
> >   "mediatek,mt7623-efuse", "mediatek,efuse": for MT7623
> >   "mediatek,mt8173-efuse" or "mediatek,efuse": for MT8173
> > + "mediatek,mt8192-efuse" or "mediatek,efuse": for MT8192
> 
> No, "mediatek,efuse" by itself is only for MT8173.
Is it should be modify from "mediatek,mt8192-efuse" or "mediatek,efuse"
to "mediatek,mt8192-efuse", "mediatek,efuse" ?

Regards,
Yz
> 
> >  - reg: Should contain registers location and length
> >  
> >  = Data cells =
> > -- 
> > 2.18.0
> > 
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH 11/13] devfreq: tegra30: Migrate to dev_pm_opp_set_opp()

[Viresh Kumar]

On 22-01-21, 00:36, Dmitry Osipenko wrote:
> 21.01.2021 14:17, Viresh Kumar пишет:
> > dev_pm_opp_set_bw() is getting removed and dev_pm_opp_set_opp() should
> > be used instead. Migrate to the new API.
> > 
> > Signed-off-by: Viresh Kumar 
> > ---
> >  drivers/devfreq/tegra30-devfreq.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/devfreq/tegra30-devfreq.c 
> > b/drivers/devfreq/tegra30-devfreq.c
> > index 117cad7968ab..d2477d7d1f66 100644
> > --- a/drivers/devfreq/tegra30-devfreq.c
> > +++ b/drivers/devfreq/tegra30-devfreq.c
> > @@ -647,7 +647,7 @@ static int tegra_devfreq_target(struct device *dev, 
> > unsigned long *freq,
> > return PTR_ERR(opp);
> > }
> >  
> > -   ret = dev_pm_opp_set_bw(dev, opp);
> > +   ret = dev_pm_opp_set_opp(dev, opp);
> > dev_pm_opp_put(opp);
> >  
> > return ret;
> > 
> 
> This patch introduces a very serious change that needs to be fixed.
> 
> Now dev_pm_opp_set_opp() changes both clock rate and bandwidth, this is
> unacceptable for this driver because it shall not touch the clock rate.
> 
> I think dev_pm_opp_set_bw() can't be removed.

I am wondering here on what would be a better solution, do what you
said or introduce another helper like dev_pm_opp_clear_clk(), which
will make sure the OPP core doesn't play with device's clk.

-- 
viresh

Re: [PATCH 4/6] regulator: Initial commit of sy7636a

[Alistair Francis]

On Mon, Jan 18, 2021 at 4:32 AM Mark Brown  wrote:
>
> On Sat, Jan 16, 2021 at 08:25:37PM -0800, Alistair Francis wrote:
>
> > --- /dev/null
> > +++ b/drivers/regulator/sy7636a-regulator.c
> > @@ -0,0 +1,233 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Functions to access SY3686A power management chip voltages
> > + *
>
> Please make the entire comment a C++ one so things look more
> intentional.

Fixed.

>
> > + * Copyright (C) 2019 reMarkable AS - http://www.remarkable.com/
> > + *
> > + * Author: Lars Ivar Miljeteig 
>
> This probably needs an update.
>
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation version 2.
> > + *
> > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > + * kind, whether express or implied; without even the implied warranty
> > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
>
> This boilerplate is redundant and should be removed.

Fixed.

>
> > +static int get_vcom_voltage_op(struct regulator_dev *rdev)
> > +{
> > + int ret = get_vcom_voltage_mv(rdev->regmap);
> > +
>
> Why is this get_vcom_voltage_mv() function not in the regulator driver,
> and why is it not just inline here?  It also needs namespacing.

I'm not sure what you mean, can you please explain?

>
> > +static int disable_regulator(struct regulator_dev *rdev)
> > +{
> > + struct sy7636a *sy7636a = dev_get_drvdata(rdev->dev.parent);
> > + int ret = 0;
> > +
> > + mutex_lock(>reglock);
> > + ret = regulator_disable_regmap(rdev);
> > + usleep_range(3, 35000);
> > + mutex_unlock(>reglock);
>
> Why do you need this delay here, and what purpose is this lock intended

The delay is to allow a power ramp up, I have added a comment.

> to serve?  I can't understand what it's intended to protect.

Apparently the mutex is to protect enable/disable, I don't think it's
required and I will remove it.

>
> > + mutex_lock(>reglock);
> > + ret = regulator_is_enabled_regmap(rdev);
> > + mutex_unlock(>reglock);
>
> This lock usage in particular looks confused.
>
> > + ret = regulator_enable_regmap(rdev);
> > + if (ret)
> > + goto finish;
>
> > + if (!pwr_good) {
> > + dev_err(>dev, "Power good signal timeout after %u ms\n",
> > + jiffies_to_msecs(t1 - t0));
> > + ret = -ETIME;
> > + goto finish;
> > + }
>
> This doesn't undo the underlying enable, leaving the regulator in a
> partially enabled state.

Thanks, fixed.

>
> > +static const struct regulator_ops sy7636a_vcom_volt_ops = {
> > + .get_voltage = get_vcom_voltage_op,
> > + .enable = enable_regulator_pgood,
> > + .disable = disable_regulator,
> > + .is_enabled = sy7636a_regulator_is_enabled,
> > +};
>
> The namespacing for functions is very random and prone to clashes.

Fixed.

> Given the power good signal I'd also expect a get_status() operation.

Added.

>
> > +static int sy7636a_regulator_suspend(struct device *dev)
> > +{
> > + int ret;
> > + struct sy7636a *sy7636a = dev_get_drvdata(dev->parent);
> > +
> > + ret = get_vcom_voltage_mv(sy7636a->regmap);
> > +
> > + if (ret > 0)
> > + sy7636a->vcom = (unsigned int)ret;
> > +
> > + return 0;
> > +}
>
> What's going on here, and if you are going to store this value over
> suspend why not store it in a variable of the correct type?  In general

It is part of the vendor's kernel, they specifically added it to
ensure vcom is set on resume.

I have fixed the variable type.

> it's surprising to need a suspend operation for a regulator.
>
> > + sy7636a->pgood_gpio = gdp;
> > + dev_info(sy7636a->dev,
> > + "Power good GPIO registered (gpio# %d)\n",
> > + desc_to_gpio(sy7636a->pgood_gpio));
>
> This print is just adding noise to the boot process.

Removed.


Alistair

[PATCH v1] can: mcp251xfd: Add some sysfs debug interfaces for registers r/w

[Su Yanjun]

When i debug mcp2518fd, some method to track registers is
needed. This easy debug interface will be ok.

For example,
read a register at 0xe00:
echo 0xe00 > can_get_reg
cat can_get_reg

write a register at 0xe00:
echo 0xe00,0x60 > can_set_reg

Signed-off-by: Su Yanjun 
---
 .../net/can/spi/mcp251xfd/mcp251xfd-core.c| 132 ++
 1 file changed, 132 insertions(+)

diff --git a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c 
b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
index ab8aad0a7594..d65abe5505d5 100644
--- a/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
+++ b/drivers/net/can/spi/mcp251xfd/mcp251xfd-core.c
@@ -27,6 +27,131 @@
 
 #define DEVICE_NAME "mcp251xfd"
 
+/* Add sysfs debug interface for easy to debug
+ *
+ * For example,
+ *
+ * - read a register
+ * echo 0xe00 > can_get_reg
+ * cat can_get_reg
+ *
+ * - write a register
+ * echo 0xe00,0x1 > can_set_reg
+ *
+ */
+static int reg_offset;
+
+static int __get_param(const char *buf, char *off, char *val)
+{
+   int len;
+
+   if (!buf || !off || !val)
+   return -EINVAL;
+
+   len = 0;
+   while (*buf != ',') {
+   *off++ = *buf++;
+   len++;
+
+   if (len >= 16)
+   return -EINVAL;
+   }
+
+   buf++;
+
+   *off = '\0';
+
+   len = 0;
+   while (*buf) {
+   *val++ = *buf++;
+   len++;
+
+   if (len >= 16)
+   return -EINVAL;
+   }
+
+   *val = '\0';
+
+   return 0;
+}
+
+static ssize_t can_get_reg_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   int err;
+   u32 val;
+   struct mcp251xfd_priv *priv;
+
+   priv = dev_get_drvdata(dev);
+
+   err = regmap_read(priv->map_reg, reg_offset, );
+   if (err)
+   return 0;
+
+   return sprintf(buf, "reg = 0x%08x, val = 0x%08x\n", reg_offset, val);
+}
+
+static ssize_t can_get_reg_store(struct device *dev,
+struct device_attribute *attr, const char 
*buf, size_t len)
+{
+   u32 off;
+
+   reg_offset = 0;
+
+   if (kstrtouint(buf, 0, ) || (off % 4))
+   return -EINVAL;
+
+   reg_offset = off;
+
+   return len;
+}
+
+static ssize_t can_set_reg_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   return 0;
+}
+
+static ssize_t can_set_reg_store(struct device *dev,
+struct device_attribute *attr, const char 
*buf, size_t len)
+{
+   struct mcp251xfd_priv *priv;
+   u32 off, val;
+   int err;
+
+   char s1[16];
+   char s2[16];
+
+   if (__get_param(buf, s1, s2))
+   return -EINVAL;
+
+   if (kstrtouint(s1, 0, ) || (off % 4))
+   return -EINVAL;
+
+   if (kstrtouint(s2, 0, ))
+   return -EINVAL;
+
+   err = regmap_write(priv->map_reg, off, val);
+   if (err)
+   return -EINVAL;
+
+   return len;
+}
+
+static DEVICE_ATTR_RW(can_get_reg);
+static DEVICE_ATTR_RW(can_set_reg);
+
+static struct attribute *can_attributes[] = {
+   _attr_can_get_reg.attr,
+   _attr_can_set_reg.attr,
+   NULL
+};
+
+static const struct attribute_group can_group = {
+   .attrs = can_attributes,
+   NULL
+};
+
 static const struct mcp251xfd_devtype_data mcp251xfd_devtype_data_mcp2517fd = {
.quirks = MCP251XFD_QUIRK_MAB_NO_WARN | MCP251XFD_QUIRK_CRC_REG |
MCP251XFD_QUIRK_CRC_RX | MCP251XFD_QUIRK_CRC_TX |
@@ -2944,6 +3069,12 @@ static int mcp251xfd_probe(struct spi_device *spi)
if (err)
goto out_free_candev;
 
+   err = sysfs_create_group(>dev.kobj, _group);
+   if (err) {
+   netdev_err(priv->ndev, "Create can group fail.\n");
+   goto out_free_candev;
+   }
+
err = can_rx_offload_add_manual(ndev, >offload,
MCP251XFD_NAPI_WEIGHT);
if (err)
@@ -2972,6 +3103,7 @@ static int mcp251xfd_remove(struct spi_device *spi)
mcp251xfd_unregister(priv);
spi->max_speed_hz = priv->spi_max_speed_hz_orig;
free_candev(ndev);
+   sysfs_remove_group(>dev.kobj, _group);
 
return 0;
 }
-- 
2.25.1

Re: [PATCH] pinctrl: sunxi: fix use-after-free in sunxi_pmx_free()

[liu xiang]

> Hi,

> On Tue, Jan 19, 2021 at 02:29:08PM +0800, Liu Xiang wrote:
> When CONFIG_REGULATOR is not set, sunxi_pmx_request() always return
> success. Even a group of pins call sunxi_pmx_request(), the refcount
> is only 1. This can cause a use-after-free warning in sunxi_pmx_free().
> To solve this problem, go to err path if regulator_get() return NULL
> or error.
> 
> Signed-off-by: Liu Xiang 

> Is there any drawback to depending on CONFIG_REGULATOR?

> Given that we need those regulators enabled anyway, I guess we could
> just select or depends on it
>
> Maxime


Yes, I think so. But CONFIG_REGULATOR is not enabled by default now.
So I can find this problem during startup.

Re: [PATCH] hugetlbfs: make hugepage size conversion more readable

[Miaohe Lin]

Hi:
On 2021/1/22 13:02, Mike Kravetz wrote:
> On 1/21/21 5:42 PM, Miaohe Lin wrote:
>> Hi:
>> On 2021/1/22 3:00, Mike Kravetz wrote:
>>> On 1/20/21 1:23 AM, Miaohe Lin wrote:
 The calculation 1U << (h->order + PAGE_SHIFT - 10) is actually equal to
 (PAGE_SHIFT << (h->order)) >> 10. So we can make it more readable by
 replace it with huge_page_size(h) / SZ_1K.

 Signed-off-by: Miaohe Lin 
 ---
  fs/hugetlbfs/inode.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c
 index 25c1857ff45d..f94b8f6553fa 100644
 --- a/fs/hugetlbfs/inode.c
 +++ b/fs/hugetlbfs/inode.c
 @@ -1519,8 +1519,8 @@ static struct vfsmount *__init 
 mount_one_hugetlbfs(struct hstate *h)
put_fs_context(fc);
}
if (IS_ERR(mnt))
 -  pr_err("Cannot mount internal hugetlbfs for page size %uK",
 - 1U << (h->order + PAGE_SHIFT - 10));
 +  pr_err("Cannot mount internal hugetlbfs for page size %luK",
 + huge_page_size(h) / SZ_1K);
>>>
>>> I appreciate the effort to make the code more readable.  The existing
>>> calculation does take a minute to understand.  However, it is correct and
>>> anyone modifying the code should be able to understand.
>>>
>>> With my compiler, your proposed change adds an additional instruction to
>>> the routine mount_one_hugetlbfs.  I know this is not significant, but still
>>
>> I thought compiler would generate the same code...
>>
>>> it does increase the kernel size for a change that is of questionable value.
>>>
>>> In the kernel, size in KB is often calculated as (size << (PAGE_SHIFT - 
>>> 10)).
>>> If you change the calculation in the hugetlb code to be:
huge_page_size(h) << (PAGE_SHIFT - 10)
>>
>> I'am sorry but this looks not really correct. I think the calculation shoud 
>> be
>> huge_page_size(h) >> 10. What do you think?
> 
> My bad!  I was looking at code that converts page counts to KB.  Sorry.
> 
> Yes, huge_page_size(h) >> 10 is correct.
> 

So I will send v2 with this change. Many thanks.

Re: [PATCH] powerpc/8xx: export 'cpm_setbrg' for modules

[Randy Dunlap]

On 1/21/21 9:51 PM, Christophe Leroy wrote:
> 
> 
> Le 22/01/2021 à 02:08, Randy Dunlap a écrit :
>> Fix missing export for a loadable module build:
>>
>> ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] 
>> undefined!
>>
>> Fixes: 4128a89ac80d ("powerpc/8xx: move CPM1 related files from sysdev/ to 
>> platforms/8xx")
> 
> I don't understand. Before that commit cpm_setbrg() wasn't exported either.
> 
> For me, it fixes the commit that brought the capability to build the cpm uart 
> driver as a module, that is commit 1da177e4c3f4 ("Linux-2.6.12-rc")

OK, I didn't have a lot of confidence in that tag.

Thanks for commenting.

>> Signed-off-by: Randy Dunlap 
>> Reported-by: kernel test robot 
>> Cc: Nick Desaulniers 
>> Cc: clang-built-li...@googlegroups.com
>> Cc: Andrew Morton 
>> Cc: Christophe Leroy 
>> Cc: Michael Ellerman 
>> Cc: Benjamin Herrenschmidt 
>> Cc: Paul Mackerras 
>> Cc: linuxppc-...@lists.ozlabs.org
>> ---
>>   arch/powerpc/platforms/8xx/cpm1.c |    1 +
>>   1 file changed, 1 insertion(+)
>>
>> --- linux-next-20210121.orig/arch/powerpc/platforms/8xx/cpm1.c
>> +++ linux-next-20210121/arch/powerpc/platforms/8xx/cpm1.c
>> @@ -280,6 +280,7 @@ cpm_setbrg(uint brg, uint rate)
>>   out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
>>     CPM_BRG_EN | CPM_BRG_DIV16);
>>   }
>> +EXPORT_SYMBOL(cpm_setbrg);
>>     struct cpm_ioport16 {
>>   __be16 dir, par, odr_sor, dat, intr;
>>


-- 
~Randy
RFC: Features and documentation: http://lwn.net/Articles/260136/

Re: [PATCH] usemem: Remove the duplicate do_access

[wufengguang]

Applied, thanks!

Sorry the mistake should be caused by manually fixing up mangled outlook patch.

Regards,
Fengguang

Re: [PATCH V3 0/3] mm/memory_hotplug: Pre-validate the address range with platform

[Anshuman Khandual]

On 1/20/21 2:07 PM, Anshuman Khandual wrote:
> 
> 
> On 1/19/21 7:10 PM, Oscar Salvador wrote:
>> On Tue, Jan 19, 2021 at 02:33:03PM +0100, David Hildenbrand wrote:
>>> Minor thing, we should make up our mind if we want to call stuff
>>> internally "memhp_" or "mhp". I prefer the latter, because it is shorter.
>>
>> I would rather use the latter as well. I used that in [1].
> 
> Okay, will change all that is 'memhp' as 'mhp' instead.
> 
>> MEMHP_MERGE_RESOURCE should be renamed if we agree on that.
>>
>> [1] 
>> https://patchwork.kernel.org/project/linux-mm/cover/20201217130758.11565-1-osalva...@suse.de/
>>

While replacing 'memhp' as 'mhp' in this series, noticed there are
some more 'memhp' scattered around the code from earlier. A mix of
both 'memhp' and 'mhp' might not be a good idea. Hence should we
just change these remaining 'memhp' as 'mhp' as well and possibly
also MEMHP_MERGE_RESOURCE as suggested earlier, in a subsequent
clean up patch ? Would there be a problem with memhp_default_state
being a command line parameter ?

>From a tree wide search -

Documentation/admin-guide/kernel-parameters.txt:
memhp_default_state=online/offline
drivers/base/memory.c:int memhp_online_type_from_str(const char *str)
drivers/base/memory.c:  const int online_type = memhp_online_type_from_str(buf);
drivers/base/memory.c:
online_type_to_str[memhp_default_online_type]);
drivers/base/memory.c:  const int online_type = memhp_online_type_from_str(buf);
drivers/base/memory.c:  memhp_default_online_type = online_type;
include/linux/memory_hotplug.h:extern int memhp_online_type_from_str(const char 
*str);
include/linux/memory_hotplug.h:extern int memhp_default_online_type;
mm/memory_hotplug.c:int memhp_default_online_type = MMOP_OFFLINE;
mm/memory_hotplug.c:int memhp_default_online_type = MMOP_ONLINE;
mm/memory_hotplug.c:static int __init setup_memhp_default_state(char *str)
mm/memory_hotplug.c:const int online_type = memhp_online_type_from_str(str);
mm/memory_hotplug.c:memhp_default_online_type = online_type;
mm/memory_hotplug.c:__setup("memhp_default_state=", setup_memhp_default_state);
mm/memory_hotplug.c:mem->online_type = memhp_default_online_type;
mm/memory_hotplug.c:if (memhp_default_online_type != MMOP_OFFLINE)

Re: "possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors

[Lukas Bulwahn]

On Fri, Jan 22, 2021 at 6:47 AM 慕冬亮  wrote:
>
> On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn  wrote:
> >
> > On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮  wrote:
> > >
> > > Dear kernel developers,
> > >
> > > I found that on the syzbot dashboard, “possible deadlock in
> > > console_lock_spinning_enable”[1] and "possible deadlock in
> > > console_unlock"[2] should share the same root cause.
> > >
> > > The reasons for the above statement:
> > > 1) the stack trace is the same, and this title difference is due to
> > > the inline property of "console_lock_spinning_enable";
> > > 2) their PoCs are the same as each other;
> > >
> > > If you can have any issues with this statement or our information is
> > > useful to you, please let us know. Thanks very much.
> > >
> > > [1] “possible deadlock in console_lock_spinning_enable” -
> > > https://syzkaller.appspot.com/bug?id=2820deb61d92a8d7ab17a56ced58e963e65d76d0
> > > [2] “possible deadlock in console_unlock” -
> > > https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a
> > >
> > >
> >
> > Dongliang, what is the purpose of this activity?
>
> Lukas,
>
> We are conducting some research on the crash deduplication (or
> identifying unique bugs) of kernel crash reports. We would like to
> share some results from our research to facilitate the bugfix in the
> syzbot dashboard.
>
> >
> > Why do inform the kernel maintainers that two issues share the root cause?
> >
> > How does this activity contribute to fixing the bugs? Why does it
> > become easier to fix the issue/create a patch with the information you
> > provide?
>
> I do this for three reasons:
>
> (1) I think the reports sharing the same root cause may expedite the
> patching processing and help generate more complete patches. After
> patching bugs in one case, we can close the other cases quicker.
> Without these reports, one developer might be misled to develop an
> incomplete patch due to a lack of understanding of the underlying bug
> [1].
> (2) I think it might help maintainers to better assess the severity of
> the bug and thus could prioritize their effort.
> (3) Multiple reports might better help maintainers diagnose the bug's
> root cause.
>
> [1]  https://groups.google.com/g/syzkaller-bugs/c/9u_hEFvNbLw/m/CO9bfF8zCQAJ
>
> > (Honestly, I do not see how it does. I believe if anyone becomes
> > active and fixes the issue due to either one of the two reports, the
> > one report would be closed by the reported-by tag and the other report
> > would simply disappear after time because it could never be reproduced
> > and hence, syzbot would close it.)
> >
> > Would it not be more reasonable to fix issues rather than identifying
> > duplicates in the automatically filled and managed database?
>
> Yes, fixing issues or bugs is the ultimate goal. However, crash
> deduplication does benefit the bugfix process, and can reduce the
> heavy burden on the kernel developers. To make our analysis more
> useful, we will try our best to add some root cause analysis and how
> to fix the underlying bug.
>

Well, I am not really convinced, but I guess you will convince me when
(thanks to your feature) all bugs reported by syzbot are quickly fixed
and quickly closed.

good luck :)

Lukas

[PATCH] memory: tegra: Remove calls to dev_pm_opp_set_clkname()

[Viresh Kumar]

There is no point calling dev_pm_opp_set_clkname() with the "name"
parameter set to NULL, this is already done by the OPP core at setup
time and should work as it is.

Signed-off-by: Viresh Kumar 
---
Dmitry, am I missing something obvious here ?

 drivers/memory/tegra/tegra20-emc.c | 13 ++---
 drivers/memory/tegra/tegra30-emc.c | 13 ++---
 2 files changed, 4 insertions(+), 22 deletions(-)

diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
index 686aaf477d8a..d653a6be8d7f 100644
--- a/drivers/memory/tegra/tegra20-emc.c
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -911,21 +911,14 @@ static int tegra_emc_interconnect_init(struct tegra_emc 
*emc)
 static int tegra_emc_opp_table_init(struct tegra_emc *emc)
 {
u32 hw_version = BIT(tegra_sku_info.soc_process_id);
-   struct opp_table *clk_opp_table, *hw_opp_table;
+   struct opp_table *hw_opp_table;
int err;
 
-   clk_opp_table = dev_pm_opp_set_clkname(emc->dev, NULL);
-   err = PTR_ERR_OR_ZERO(clk_opp_table);
-   if (err) {
-   dev_err(emc->dev, "failed to set OPP clk: %d\n", err);
-   return err;
-   }
-
hw_opp_table = dev_pm_opp_set_supported_hw(emc->dev, _version, 1);
err = PTR_ERR_OR_ZERO(hw_opp_table);
if (err) {
dev_err(emc->dev, "failed to set OPP supported HW: %d\n", err);
-   goto put_clk_table;
+   return err;
}
 
err = dev_pm_opp_of_add_table(emc->dev);
@@ -954,8 +947,6 @@ static int tegra_emc_opp_table_init(struct tegra_emc *emc)
dev_pm_opp_of_remove_table(emc->dev);
 put_hw_table:
dev_pm_opp_put_supported_hw(hw_opp_table);
-put_clk_table:
-   dev_pm_opp_put_clkname(clk_opp_table);
 
return err;
 }
diff --git a/drivers/memory/tegra/tegra30-emc.c 
b/drivers/memory/tegra/tegra30-emc.c
index 44ac155936aa..6985da0ffb35 100644
--- a/drivers/memory/tegra/tegra30-emc.c
+++ b/drivers/memory/tegra/tegra30-emc.c
@@ -1483,21 +1483,14 @@ static int tegra_emc_interconnect_init(struct tegra_emc 
*emc)
 static int tegra_emc_opp_table_init(struct tegra_emc *emc)
 {
u32 hw_version = BIT(tegra_sku_info.soc_speedo_id);
-   struct opp_table *clk_opp_table, *hw_opp_table;
+   struct opp_table *hw_opp_table;
int err;
 
-   clk_opp_table = dev_pm_opp_set_clkname(emc->dev, NULL);
-   err = PTR_ERR_OR_ZERO(clk_opp_table);
-   if (err) {
-   dev_err(emc->dev, "failed to set OPP clk: %d\n", err);
-   return err;
-   }
-
hw_opp_table = dev_pm_opp_set_supported_hw(emc->dev, _version, 1);
err = PTR_ERR_OR_ZERO(hw_opp_table);
if (err) {
dev_err(emc->dev, "failed to set OPP supported HW: %d\n", err);
-   goto put_clk_table;
+   return err;
}
 
err = dev_pm_opp_of_add_table(emc->dev);
@@ -1526,8 +1519,6 @@ static int tegra_emc_opp_table_init(struct tegra_emc *emc)
dev_pm_opp_of_remove_table(emc->dev);
 put_hw_table:
dev_pm_opp_put_supported_hw(hw_opp_table);
-put_clk_table:
-   dev_pm_opp_put_clkname(clk_opp_table);
 
return err;
 }
-- 
2.25.0.rc1.19.g042ed3e048af

Re: [PATCH v4] ovl: fix dentry leak in ovl_get_redirect

[Joseph Qi]

Hi Miklos,

Any comments on this patch?

Thanks,
Joseph

On 12/22/20 11:26 AM, Al Viro wrote:
> On Tue, Dec 22, 2020 at 11:06:26AM +0800, Liangyan wrote:
> 
>> Cc: 
>> Fixes: a6c606551141 ("ovl: redirect on rename-dir")
>> Signed-off-by: Liangyan 
>> Reviewed-by: Joseph Qi 
>> Suggested-by: Al Viro 
> 
> Fine by me...  I can put it through vfs.git#fixes, but IMO
> that would be better off in overlayfs tree.
> 

RE: [PATCH v7 0/2] PCI: cadence: Retrain Link to work around Gen2

[Athani Nadeem Ladkhan]

Hi Rob / Thomas,

Requesting to provide your reviews.

Thanks & Regards,
Nadeem Athani

> -Original Message-
> From: Kishon Vijay Abraham I 
> Sent: Tuesday, January 12, 2021 12:46 PM
> To: Athani Nadeem Ladkhan ; Tom Joseph
> ; lorenzo.pieral...@arm.com; r...@kernel.org;
> bhelg...@google.com; linux-o...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Cc: Milind Parab ; Swapnil Kashinath Jakhade
> ; Parshuram Raju Thombare
> 
> Subject: Re: [PATCH v7 0/2] PCI: cadence: Retrain Link to work around Gen2
> 
> EXTERNAL MAIL
> 
> 
> 
> 
> On 30/12/20 5:35 pm, Nadeem Athani wrote:
> > Cadence controller will not initiate autonomous speed change if
> > strapped as Gen2. The Retrain Link bit is set as quirk to enable this speed
> change.
> > Adding a quirk flag for defective IP. In future IP revisions this will
> > not be applicable.
> >
> > Version history:
> > Changes in v7:
> > - Changing the commit title of patch 1 in this series.
> > - Added a return value for function cdns_pcie_retrain().
> > Changes in v6:
> > - Move the position of function cdns_pcie_host_wait_for_link to remove
> >   compilation error. No changes in code. Separate patch for this.
> > Changes in v5:
> > - Remove the compatible string based setting of quirk flag.
> > - Removed additional Link Up Check
> > - Removed quirk from pcie-cadence-plat.c and added in pci-j721e.c
> > Changes in v4:
> > - Added a quirk flag based on a new compatible string.
> > - Change of api for link up: cdns_pcie_host_wait_for_link().
> > Changes in v3:
> > - To set retrain link bit,checking device capability & link status.
> > - 32bit read in place of 8bit.
> > - Minor correction in patch comment.
> > - Change in variable & macro name.
> > Changes in v2:
> > - 16bit read in place of 8bit.
> 
> Could get GEN2 card enumerated in GEN2 mode in J7ES EVM.
> 
> Tested-by: Kishon Vijay Abraham I 
> 
> Thanks
> Kishon
> >
> > Nadeem Athani (2):
> >   PCI: cadence: Shifting of a function to support new code.
> >   PCI: cadence: Retrain Link to work around Gen2 training defect.
> >
> >  drivers/pci/controller/cadence/pci-j721e.c |  3 +
> >  drivers/pci/controller/cadence/pcie-cadence-host.c | 70
> --
> >  drivers/pci/controller/cadence/pcie-cadence.h  | 11 +++-
> >  3 files changed, 65 insertions(+), 19 deletions(-)
> >

Re: [PATCH] powerpc/8xx: export 'cpm_setbrg' for modules

[Christophe Leroy]

Le 22/01/2021 à 02:08, Randy Dunlap a écrit :

Fix missing export for a loadable module build:

ERROR: modpost: "cpm_setbrg" [drivers/tty/serial/cpm_uart/cpm_uart.ko] 
undefined!

Fixes: 4128a89ac80d ("powerpc/8xx: move CPM1 related files from sysdev/ to 
platforms/8xx")


I don't understand. Before that commit cpm_setbrg() wasn't exported either.

For me, it fixes the commit that brought the capability to build the cpm uart driver as a module, 
that is commit 1da177e4c3f4 ("Linux-2.6.12-rc")



Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Nick Desaulniers 
Cc: clang-built-li...@googlegroups.com
Cc: Andrew Morton 
Cc: Christophe Leroy 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-...@lists.ozlabs.org
---
  arch/powerpc/platforms/8xx/cpm1.c |1 +
  1 file changed, 1 insertion(+)

--- linux-next-20210121.orig/arch/powerpc/platforms/8xx/cpm1.c
+++ linux-next-20210121/arch/powerpc/platforms/8xx/cpm1.c
@@ -280,6 +280,7 @@ cpm_setbrg(uint brg, uint rate)
out_be32(bp, (((BRG_UART_CLK_DIV16 / rate) - 1) << 1) |
  CPM_BRG_EN | CPM_BRG_DIV16);
  }
+EXPORT_SYMBOL(cpm_setbrg);
  
  struct cpm_ioport16 {

__be16 dir, par, odr_sor, dat, intr;

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

[Xu Yilun]

On Thu, Jan 21, 2021 at 12:03:47PM -0800, Moritz Fischer wrote:
> Hi Tom,
> 
> On Thu, Jan 21, 2021 at 06:30:20AM -0800, Tom Rix wrote:
> > 
> > On 1/17/21 8:22 AM, Moritz Fischer wrote:
> > > Greg,
> > >
> > > On Sun, Jan 17, 2021 at 04:45:04PM +0100, Greg KH wrote:
> > >> On Wed, Jan 13, 2021 at 09:54:07AM +0800, 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.
> > >> Why doesn't the existing uio driver work for this, why do you need a new
> > >> one?
> > >>
> > >>> ---
> > >>>  drivers/fpga/Kconfig| 10 +
> > >>>  drivers/fpga/Makefile   |  1 +
> > >>>  drivers/fpga/dfl-uio-pdev.c | 93 
> > >>> +
> > >> uio drivers traditionally go in drivers/uio/ and start with "uio", so
> > >> shouldn't this be drivers/uio/uio_dfl_pdev.c to match the same naming
> > >> scheme?
> > > I had considered suggesting that, but ultimately this driver only
> > > creates a 'uio_pdrv_genirq' platform device, so it didn't seem like a
> > > good fit.
> > >> But again, you need to explain in detail, why the existing uio driver
> > >> doesn't work properly, or why you can't just add a few lines to an
> > >> existing one.
> > > Ultimately there are three options I see:
> > > 1) Do what Xu does, which is re-use the 'uio_pdrv_genirq' uio driver by
> > >   creating a platform device for it as sub-device of the dfl device that
> > >   we bind to uio_pdrv_genirq
> > > 2) Add a module_dfl_driver part to drivers/uio/uio_pdrv_genirq.c and
> > >   corresponding id table
> > > 3) Create a new uio_dfl_genirq kind of driver that uses the dfl bus and
> > >   that would make sense to then put into drivers/uio. (This would
> > >   duplicate code in uio_pdrv_genirq to some extend)
> > >
> > > Overall I think in terms of code re-use I think Xu's choice might be
> > > less new code as it simply wraps the uio platform device driver, and
> > > allows for defining the resources passed to the UIO driver to be defined
> > > by hardware through a DFL.
> > >
> > > I've seen the pattern that Xu proposed used in other places like the
> > > macb network driver where you'd have macb_main (the platform driver) and
> > > macb_pci that wraps it for a pci usage.
> > >
> > > - Moritz
> > 
> > Thinking of this problem more generally.
> > 
> > Every fpga will have a handful of sub devices.
> > 
> > Do we want to carry them in the fpga subsystem or carry them in the other 
> > subsystems ?
> 
> Yeah no we really don't. I think that was the point of the whole DFL
> bus :)
> > 
> > Consider the short term reviewing and long term maintenance of the sub 
> > devices by the subsystem maintainers.
> > 
> > It easier for them if the sub devices are in the other subsystems.
> 
> Agreed.
> > 
> > 
> > Applying this to specifically for dfl_uio.
> > 
> > No one from the uio subsystem reviewing this change is a problem.
> 
> Greg will.
> > I think this change needs to go to the uio subsystem.
> 
> Yeah I've thought about this some for the last few days, maybe it's
> easier that way.
> 
> Tbh, there's so little code here even if we went with option 3 above
> it's probably fairly short. It would set a better prcedent.
> 
> Xu, how do you feel about giving that a spin? See if option 3 will be
> way more code.

Yes, I'll try to put it to drivers/uio.

I see the implementation in vfio_platform.c/vfio_amba.c/vfio_platform_common.c.
I'm wondering if we could handle it in that way.

Thanks,
yilun

[PATCH] ALSA: hda/realtek: Enable headset of ASUS B1400CEPE with ALC256

[Jian-Hong Pan]

ASUS B1400CEPE laptop's headset audio is not enabled until
ALC256_FIXUP_ASUS_HPE quirk is applied.

Here is the original pin node values:

0x12 0x4000
0x13 0x41f0
0x14 0x90170110
0x18 0x41f0
0x19 0x41f0
0x1a 0x41f0
0x1b 0x41f0
0x1d 0x40461b45
0x1e 0x41f0
0x21 0x04211020

Signed-off-by: Jian-Hong Pan 
---
 sound/pci/hda/patch_realtek.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
index ed5b6b894dc1..290645516313 100644
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -8006,6 +8006,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = {
SND_PCI_QUIRK(0x1043, 0x18b1, "Asus MJ401TA", 
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x18f1, "Asus FX505DT", 
ALC256_FIXUP_ASUS_HEADSET_MIC),
SND_PCI_QUIRK(0x1043, 0x194e, "ASUS UX563FD", ALC294_FIXUP_ASUS_HPE),
+   SND_PCI_QUIRK(0x1043, 0x1982, "ASUS B1400CEPE", ALC256_FIXUP_ASUS_HPE),
SND_PCI_QUIRK(0x1043, 0x19ce, "ASUS B9450FA", ALC294_FIXUP_ASUS_HPE),
SND_PCI_QUIRK(0x1043, 0x19e1, "ASUS UX581LV", 
ALC295_FIXUP_ASUS_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
-- 
2.30.0

[PATCH v2 1/2] platform: cros_ec: Call interrupt bottom half in ISH or RPMSG mode

[Gwendal Grignou]

Call the same bottom half for all EC protocols (threaded code).

Signed-off-by: Gwendal Grignou 
---
Changes since v1:
- Fix merge issues, make changes in cros_ec.h instead of cros_ec_proto.h
- Fix function comments syntax.

 drivers/platform/chrome/cros_ec.c   | 26 +++--
 drivers/platform/chrome/cros_ec.h   |  4 +++-
 drivers/platform/chrome/cros_ec_ishtp.c |  6 +-
 drivers/platform/chrome/cros_ec_rpmsg.c |  6 +-
 4 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/platform/chrome/cros_ec.c 
b/drivers/platform/chrome/cros_ec.c
index 3104680b7485..bf76a6c49c95 100644
--- a/drivers/platform/chrome/cros_ec.c
+++ b/drivers/platform/chrome/cros_ec.c
@@ -32,7 +32,14 @@ static struct cros_ec_platform pd_p = {
.cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_PD_INDEX),
 };
 
-static irqreturn_t ec_irq_handler(int irq, void *data)
+/**
+ * cros_ec_irq_handler() - top half part of the interrupt handler
+ * @irq: IRQ id
+ * @data: (ec_dev) Device with events to process.
+ *
+ * Return: Wakeup the bottom half
+ */
+static irqreturn_t cros_ec_irq_handler(int irq, void *data)
 {
struct cros_ec_device *ec_dev = data;
 
@@ -51,7 +58,7 @@ static irqreturn_t ec_irq_handler(int irq, void *data)
  * Return: true if more events are still pending and this function should be
  * called again.
  */
-bool cros_ec_handle_event(struct cros_ec_device *ec_dev)
+static bool cros_ec_handle_event(struct cros_ec_device *ec_dev)
 {
bool wake_event;
bool ec_has_more_events;
@@ -73,9 +80,15 @@ bool cros_ec_handle_event(struct cros_ec_device *ec_dev)
 
return ec_has_more_events;
 }
-EXPORT_SYMBOL(cros_ec_handle_event);
 
-static irqreturn_t ec_irq_thread(int irq, void *data)
+/**
+ * cros_ec_irq_thread() - bottom half part of the interrupt handler
+ * @irq: IRQ id
+ * @data: (ec_dev) Device with events to process.
+ *
+ * Return: Interrupt handled.
+ */
+irqreturn_t cros_ec_irq_thread(int irq, void *data)
 {
struct cros_ec_device *ec_dev = data;
bool ec_has_more_events;
@@ -86,6 +99,7 @@ static irqreturn_t ec_irq_thread(int irq, void *data)
 
return IRQ_HANDLED;
 }
+EXPORT_SYMBOL(cros_ec_irq_thread);
 
 static int cros_ec_sleep_event(struct cros_ec_device *ec_dev, u8 sleep_event)
 {
@@ -194,8 +208,8 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
 
if (ec_dev->irq > 0) {
err = devm_request_threaded_irq(dev, ec_dev->irq,
-   ec_irq_handler,
-   ec_irq_thread,
+   cros_ec_irq_handler,
+   cros_ec_irq_thread,
IRQF_TRIGGER_LOW | IRQF_ONESHOT,
"chromeos-ec", ec_dev);
if (err) {
diff --git a/drivers/platform/chrome/cros_ec.h 
b/drivers/platform/chrome/cros_ec.h
index e69fc1ff68b4..78363dcfdf23 100644
--- a/drivers/platform/chrome/cros_ec.h
+++ b/drivers/platform/chrome/cros_ec.h
@@ -8,12 +8,14 @@
 #ifndef __CROS_EC_H
 #define __CROS_EC_H
 
+#include 
+
 int cros_ec_register(struct cros_ec_device *ec_dev);
 int cros_ec_unregister(struct cros_ec_device *ec_dev);
 
 int cros_ec_suspend(struct cros_ec_device *ec_dev);
 int cros_ec_resume(struct cros_ec_device *ec_dev);
 
-bool cros_ec_handle_event(struct cros_ec_device *ec_dev);
+irqreturn_t cros_ec_irq_thread(int irq, void *data);
 
 #endif /* __CROS_EC_H */
diff --git a/drivers/platform/chrome/cros_ec_ishtp.c 
b/drivers/platform/chrome/cros_ec_ishtp.c
index 81364029af36..f00107017318 100644
--- a/drivers/platform/chrome/cros_ec_ishtp.c
+++ b/drivers/platform/chrome/cros_ec_ishtp.c
@@ -140,12 +140,8 @@ static void ish_evt_handler(struct work_struct *work)
 {
struct ishtp_cl_data *client_data =
container_of(work, struct ishtp_cl_data, work_ec_evt);
-   struct cros_ec_device *ec_dev = client_data->ec_dev;
-   bool ec_has_more_events;
 
-   do {
-   ec_has_more_events = cros_ec_handle_event(ec_dev);
-   } while (ec_has_more_events);
+   cros_ec_irq_thread(0, client_data->ec_dev);
 }
 
 /**
diff --git a/drivers/platform/chrome/cros_ec_rpmsg.c 
b/drivers/platform/chrome/cros_ec_rpmsg.c
index 30d0ba3b8889..d96d15b8ca94 100644
--- a/drivers/platform/chrome/cros_ec_rpmsg.c
+++ b/drivers/platform/chrome/cros_ec_rpmsg.c
@@ -149,12 +149,8 @@ cros_ec_rpmsg_host_event_function(struct work_struct 
*host_event_work)
struct cros_ec_rpmsg *ec_rpmsg = container_of(host_event_work,
  struct cros_ec_rpmsg,
  host_event_work);
-   struct cros_ec_device *ec_dev = dev_get_drvdata(_rpmsg->rpdev->dev);
-   bool ec_has_more_events;
 
-   do {
-   ec_has_more_events = cros_ec_handle_event(ec_dev);
-   

Re: "possible deadlock in console_lock_spinning_enable" and "possible deadlock in console_unlock" should be duplicate crash behaviors

[慕冬亮]

On Thu, Jan 21, 2021 at 8:49 PM Lukas Bulwahn  wrote:
>
> On Thu, Jan 21, 2021 at 6:37 AM 慕冬亮  wrote:
> >
> > Dear kernel developers,
> >
> > I found that on the syzbot dashboard, “possible deadlock in
> > console_lock_spinning_enable”[1] and "possible deadlock in
> > console_unlock"[2] should share the same root cause.
> >
> > The reasons for the above statement:
> > 1) the stack trace is the same, and this title difference is due to
> > the inline property of "console_lock_spinning_enable";
> > 2) their PoCs are the same as each other;
> >
> > If you can have any issues with this statement or our information is
> > useful to you, please let us know. Thanks very much.
> >
> > [1] “possible deadlock in console_lock_spinning_enable” -
> > https://syzkaller.appspot.com/bug?id=2820deb61d92a8d7ab17a56ced58e963e65d76d0
> > [2] “possible deadlock in console_unlock” -
> > https://syzkaller.appspot.com/bug?id=39ea6caa479af471183997376dc7e90bc7d64a6a
> >
> >
>
> Dongliang, what is the purpose of this activity?

Lukas,

We are conducting some research on the crash deduplication (or
identifying unique bugs) of kernel crash reports. We would like to
share some results from our research to facilitate the bugfix in the
syzbot dashboard.

>
> Why do inform the kernel maintainers that two issues share the root cause?
>
> How does this activity contribute to fixing the bugs? Why does it
> become easier to fix the issue/create a patch with the information you
> provide?

I do this for three reasons:

(1) I think the reports sharing the same root cause may expedite the
patching processing and help generate more complete patches. After
patching bugs in one case, we can close the other cases quicker.
Without these reports, one developer might be misled to develop an
incomplete patch due to a lack of understanding of the underlying bug
[1].
(2) I think it might help maintainers to better assess the severity of
the bug and thus could prioritize their effort.
(3) Multiple reports might better help maintainers diagnose the bug's
root cause.

[1]  https://groups.google.com/g/syzkaller-bugs/c/9u_hEFvNbLw/m/CO9bfF8zCQAJ

> (Honestly, I do not see how it does. I believe if anyone becomes
> active and fixes the issue due to either one of the two reports, the
> one report would be closed by the reported-by tag and the other report
> would simply disappear after time because it could never be reproduced
> and hence, syzbot would close it.)
>
> Would it not be more reasonable to fix issues rather than identifying
> duplicates in the automatically filled and managed database?

Yes, fixing issues or bugs is the ultimate goal. However, crash
deduplication does benefit the bugfix process, and can reduce the
heavy burden on the kernel developers. To make our analysis more
useful, we will try our best to add some root cause analysis and how
to fix the underlying bug.

>
> Best regards,
>
> Lukas

[PATCH v2 0/2] platform: chrome: Simplify interrupt path

[Gwendal Grignou]

rrespective of the transport (i2c, spi, ish, rpmsg), have all cros ec
interrupt stack call the threaded part (bottom half) of the interrupt
handler.
Fix an issue where EC could be stuck if it sends a message while the AP
is not powered on.

Changes since v1:
- fix merging issue and function comments syntax.

Gwendal Grignou (2):
  platform: cros_ec: Call interrupt bottom half in ISH or RPMSG mode
  platform: cros_ec: Call interrupt bottom half at probe time

 drivers/platform/chrome/cros_ec.c   | 33 -
 drivers/platform/chrome/cros_ec.h   |  4 ++-
 drivers/platform/chrome/cros_ec_ishtp.c |  6 +
 drivers/platform/chrome/cros_ec_rpmsg.c |  6 +
 4 files changed, 32 insertions(+), 17 deletions(-)

-- 
2.30.0.280.ga3ce27912f-goog

[PATCH v2 2/2] platform: cros_ec: Call interrupt bottom half at probe time

[Gwendal Grignou]

While the AP was powered off, the EC may have send messages.
If the message is not serviced within 3s, the EC stops sending message.
Unlock the EC by purging stale messages at probe time.

Signed-off-by: Gwendal Grignou 
---
Changes since v1: None.

 drivers/platform/chrome/cros_ec.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/platform/chrome/cros_ec.c 
b/drivers/platform/chrome/cros_ec.c
index bf76a6c49c95..fc5aa1525d13 100644
--- a/drivers/platform/chrome/cros_ec.c
+++ b/drivers/platform/chrome/cros_ec.c
@@ -283,6 +283,13 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
 
dev_info(dev, "Chrome EC device registered\n");
 
+   /*
+* Unlock EC that may be waiting for AP to process MKBP events.
+* If the AP takes to long to answer, the EC would stop sending events.
+*/
+   if (ec_dev->mkbp_event_supported)
+   cros_ec_irq_thread(0, ec_dev);
+
return 0;
 }
 EXPORT_SYMBOL(cros_ec_register);
-- 
2.30.0.280.ga3ce27912f-goog

[PATCH v4] drm/virtio: Track total GPU memory for virtio driver

[Yiwei Zhang]

On the success of virtio_gpu_object_create, add size of newly allocated
bo to the tracked total_mem. In drm_gem_object_funcs.free, after the gem
bo loses its last refcount, subtract the bo size from the tracked
total_mem if the original underlying memory allocation is successful.

It's more accurate to do this in device driver layer to best match when
the underlying resource gets allocated and destroyed during tracing.

Signed-off-by: Yiwei Zhang 
---
 drivers/gpu/drm/virtio/Kconfig  |  1 +
 drivers/gpu/drm/virtio/virtgpu_drv.h|  2 ++
 drivers/gpu/drm/virtio/virtgpu_object.c | 11 +++
 3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index b925b8b1da16..e103b7e883b1 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
select VIRTIO_DMA_SHARED_BUFFER
+   select TRACE_GPU_MEM
help
   This is the virtual GPU driver for virtio.  It can be used with
   QEMU based VMMs (like KVM or Xen).
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 6a232553c99b..c5622f9b591f 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -249,6 +249,8 @@ struct virtio_gpu_device {
spinlock_t resource_export_lock;
/* protects map state and host_visible_mm */
spinlock_t host_visible_lock;
+
+   atomic64_t total_mem;
 };
 
 struct virtio_gpu_fpriv {
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index d69a5b6da553..e2251fc41509 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -25,12 +25,21 @@
 
 #include 
 #include 
+#include 
 
 #include "virtgpu_drv.h"
 
 static int virtio_gpu_virglrenderer_workaround = 1;
 module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int, 0400);
 
+static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device *vgdev,
+ s64 delta)
+{
+   u64 total_mem = atomic64_add_return(delta, >total_mem);
+
+   trace_gpu_mem_total(vgdev->ddev->primary->index, 0, total_mem);
+}
+
 int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t 
*resid)
 {
if (virtio_gpu_virglrenderer_workaround) {
@@ -104,6 +113,7 @@ static void virtio_gpu_free_object(struct drm_gem_object 
*obj)
struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
 
if (bo->created) {
+   virtio_gpu_trace_total_mem(vgdev, -(obj->size));
virtio_gpu_cmd_unref_resource(vgdev, bo);
virtio_gpu_notify(vgdev);
/* completion handler calls virtio_gpu_cleanup_object() */
@@ -265,6 +275,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
virtio_gpu_object_attach(vgdev, bo, ents, nents);
}
 
+   virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
*bo_ptr = bo;
return 0;
 
-- 
2.30.0.280.ga3ce27912f-goog

Re: [ANNOUNCE] v5.11-rc4-rt1

[Ahmed S. Darwish]

On Thu, Jan 21, 2021 at 09:50:08PM +0100, Pavel Machek wrote:
> Hi!
>
> > I'm pleased to announce the v5.11-rc4-rt1 patch set.
> >
> > Changes since v5.10.8-rt24:
> >
> >   - Updated to v5.11-rc4
> >
> > Known issues
> >  - kdb/kgdb can easily deadlock.
> >  - kmsg dumpers expecting not to be called in parallel can clobber
> >their temp buffer.
> >  - netconsole triggers WARN.
>
> I noticed... lot of code using in_interrupt() to decide what to do is
> making it to 5.10-stable at the moment (and I guess that means
> vanilla, too).
>
> I have recollection that that is not okay thing to do. Am I right?
>

Correct. These macros should not be added to new, non-core, kernel code.

There's an on-going effort to clear them already, as in:

  - https://lkml.kernel.org/r/20201019100629.419020...@linutronix.de
(merged)
  - https://lkml.kernel.org/r/20201126132952.2287996-1-bige...@linutronix.de
(merged)
  - https://lkml.kernel.org/r/20210118100955.1761652-1-a.darw...@linutronix.de  
(to be merged)

> Examples: 8abec36d1274bbd5ae8f36f3658b9abb3db56c31,
> d68b29584c25dbacd01ed44a3e45abb35353f1de.
>

That's sad.

Maybe it would be wise to let a bot scan lore regularly, and send an
automatic notification to authors whenever their patches reintroduce
these macros to non-core kernel code.

Thanks,

--
Ahmed S. Darwish

[PATCH v3] drm/virtio: trace total gem bo for virtio

[Yiwei Zhang]

From: Yiwei Zhang 

On the success of virtio_gpu_object_create, add size of newly allocated
bo to the tracked total_mem. In drm_gem_object_funcs.free, after the gem
bo lost its last refcount, subtract the bo size from the tracked
total_mem if the original underlying memory allocation is successful.

It's more accurate to do this in device driver layer to best match when
the underlying resource gets allocated and destroyed during tracing.

Signed-off-by: Yiwei Zhang 
---
 drivers/gpu/drm/virtio/Kconfig  |  1 +
 drivers/gpu/drm/virtio/virtgpu_drv.h|  2 ++
 drivers/gpu/drm/virtio/virtgpu_object.c | 11 +++
 3 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/virtio/Kconfig b/drivers/gpu/drm/virtio/Kconfig
index b925b8b1da16..e103b7e883b1 100644
--- a/drivers/gpu/drm/virtio/Kconfig
+++ b/drivers/gpu/drm/virtio/Kconfig
@@ -5,6 +5,7 @@ config DRM_VIRTIO_GPU
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
select VIRTIO_DMA_SHARED_BUFFER
+   select TRACE_GPU_MEM
help
   This is the virtual GPU driver for virtio.  It can be used with
   QEMU based VMMs (like KVM or Xen).
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h 
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 6a232553c99b..7ab63ce9c6a9 100644
--- a/drivers/gpu/drm/virtio/virtgpu_drv.h
+++ b/drivers/gpu/drm/virtio/virtgpu_drv.h
@@ -249,6 +249,8 @@ struct virtio_gpu_device {
spinlock_t resource_export_lock;
/* protects map state and host_visible_mm */
spinlock_t host_visible_lock;
+   /* total memory backing gem bos */
+   atomic64_t total_mem;
 };
 
 struct virtio_gpu_fpriv {
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c 
b/drivers/gpu/drm/virtio/virtgpu_object.c
index d69a5b6da553..e2251fc41509 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -25,12 +25,21 @@
 
 #include 
 #include 
+#include 
 
 #include "virtgpu_drv.h"
 
 static int virtio_gpu_virglrenderer_workaround = 1;
 module_param_named(virglhack, virtio_gpu_virglrenderer_workaround, int, 0400);
 
+static inline void virtio_gpu_trace_total_mem(struct virtio_gpu_device *vgdev,
+ s64 delta)
+{
+   u64 total_mem = atomic64_add_return(delta, >total_mem);
+
+   trace_gpu_mem_total(vgdev->ddev->primary->index, 0, total_mem);
+}
+
 int virtio_gpu_resource_id_get(struct virtio_gpu_device *vgdev, uint32_t 
*resid)
 {
if (virtio_gpu_virglrenderer_workaround) {
@@ -104,6 +113,7 @@ static void virtio_gpu_free_object(struct drm_gem_object 
*obj)
struct virtio_gpu_device *vgdev = bo->base.base.dev->dev_private;
 
if (bo->created) {
+   virtio_gpu_trace_total_mem(vgdev, -(obj->size));
virtio_gpu_cmd_unref_resource(vgdev, bo);
virtio_gpu_notify(vgdev);
/* completion handler calls virtio_gpu_cleanup_object() */
@@ -265,6 +275,7 @@ int virtio_gpu_object_create(struct virtio_gpu_device 
*vgdev,
virtio_gpu_object_attach(vgdev, bo, ents, nents);
}
 
+   virtio_gpu_trace_total_mem(vgdev, shmem_obj->base.size);
*bo_ptr = bo;
return 0;
 
-- 
2.30.0.280.ga3ce27912f-goog

Re: [PATCH v3 04/17] perf: x86/ds: Handle guest PEBS overflow PMI and inject it to guest

[Like Xu]

On 2021/1/16 1:42, Sean Christopherson wrote:

On Fri, Jan 15, 2021, Xu, Like wrote:

On 2021/1/15 2:55, Sean Christopherson wrote:

On Mon, Jan 04, 2021, Like Xu wrote:

+* Note: KVM disables the co-existence of guest PEBS and host PEBS.

By "KVM", do you mean KVM's loading of the MSRs provided by 
intel_guest_get_msrs()?
Because the PMU should really be the entity that controls guest vs. host.  KVM
should just be a dumb pipe that handles the mechanics of how values are context
switch.


The intel_guest_get_msrs() and atomic_switch_perf_msrs()
will work together to disable the co-existence of guest PEBS and host PEBS:

https://lore.kernel.org/kvm/961e6135-ff6d-86d1-3b7b-a1846ad0e...@intel.com/

+

static void atomic_switch_perf_msrs(struct vcpu_vmx *vmx)
...
     if (nr_msrs > 2 && (msrs[1].guest & msrs[0].guest)) {
         msrs[2].guest = pmu->ds_area;
         if (nr_msrs > 3)
             msrs[3].guest = pmu->pebs_data_cfg;
     }

    for (i = 0; i < nr_msrs; i++)
...


Yeah, that's exactly what I'm complaining about.  Splitting the logic for
determining the guest values is unnecessarily confusing, and as evidenced by the
PEBS_ENABLE bug, potentially fragile.  Perf should have full knowledge and
control of what values are loaded for the guest.  And, the above indexing magic
is nigh impossible to follow and _super_ fragile.


Thanks for pointing this out.



If we change .guest_get_msrs() to take a struct kvm_pmu pointer, then it can
generate the full set of guest values by grabbing ds_area and pebs_data_cfg.
Alternatively, .guest_get_msrs() could take the desired guest MSR values
directly (ds_area and pebs_data_cfg), but kvm_pmu is vendor agnostic, so I don't
see any reason to not just pass the pointer.


Hi Peter,

What do you think of us passing a "struct kvm_pmu" pointer (defined in 
arch/x86/include/asm/kvm_host.h) to guest_get_msrs(int *nr) ?


---
thx,likexu

Re: [PATCH v3] ovl: use a dedicated semaphore for dir upperfile caching

[Icenowy Zheng]

在 2021-01-21星期四的 09:07 +0100，Miklos Szeredi写道：
> On Thu, Jan 21, 2021 at 4:43 AM Icenowy Zheng 
> wrote:
> > 
> > 在 2021-01-20星期三的 11:20 +0100，Miklos Szeredi写道：
> > > On Tue, Jan 05, 2021 at 08:47:41AM +0200, Amir Goldstein wrote:
> > > > On Tue, Jan 5, 2021 at 2:36 AM Icenowy Zheng 
> > > > wrote:
> > > > > 
> > > > > The function ovl_dir_real_file() currently uses the semaphore
> > > > > of
> > > > > the
> > > > > inode to synchronize write to the upperfile cache field.
> > > > 
> > > > Although the inode lock is a rw_sem it is referred to as the
> > > > "inode
> > > > lock"
> > > > and you also left semaphore in the commit subject.
> > > > No need to re-post. This can be fixed on commit.
> > > > 
> > > > > 
> > > > > However, this function will get called by
> > > > > ovl_ioctl_set_flags(),
> > > > > which
> > > > > utilizes the inode semaphore too. In this case
> > > > > ovl_dir_real_file() will
> > > > > try to claim a lock that is owned by a function in its call
> > > > > stack, which
> > > > > won't get released before ovl_dir_real_file() returns.
> > > > > 
> > > > > Define a dedicated semaphore for the upperfile cache, so that
> > > > > the
> > > > > deadlock won't happen.
> > > > > 
> > > > > Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and
> > > > > FS[S|G]ETXATTR ioctls for directories")
> > > > > Cc: sta...@vger.kernel.org # v5.10
> > > > > Signed-off-by: Icenowy Zheng 
> > > > > ---
> > > > > Changes in v2:
> > > > > - Fixed missing replacement in error handling path.
> > > > > Changes in v3:
> > > > > - Use mutex instead of semaphore.
> > > > > 
> > > > >  fs/overlayfs/readdir.c | 10 +-
> > > > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
> > > > > index 01620ebae1bd..3980f9982f34 100644
> > > > > --- a/fs/overlayfs/readdir.c
> > > > > +++ b/fs/overlayfs/readdir.c
> > > > > @@ -56,6 +56,7 @@ struct ovl_dir_file {
> > > > >     struct list_head *cursor;
> > > > >     struct file *realfile;
> > > > >     struct file *upperfile;
> > > > > +   struct mutex upperfile_mutex;
> > > > 
> > > > That's a very specific name.
> > > > This mutex protects members of struct ovl_dir_file, which could
> > > > evolve
> > > > into struct ovl_file one day (because no reason to cache only
> > > > dir
> > > > upper file),
> > > > so I would go with a more generic name, but let's leave it to
> > > > Miklos to decide.
> > > > 
> > > > He could have a different idea altogether for fixing this bug.
> > > 
> > > How about this (untested) patch?
> > > 
> > > It's a cleanup as well as a fix, but maybe we should separate the
> > > cleanup from
> > > the fix...
> > 
> > If you are going to post this, feel free to add
> > 
> > Tested-by: Icenowy Zheng 
> 
> Okay, thanks.
> 
> > (And if you remove the IS_ERR(realfile) part, the tested-by tag
> > still
> > applies.)
> 
> Dropping the IS_ERR(realfile) here would mean having to add the same
> check before relevant fput() calls, which would make it more complex
> not less.
> 
> Or did you mean something else?

I mean "seperate the cleanup from the fix".

This is only for when you do the seperation.

> 
> Thanks,
> Miklos

Re: [PATCH v6 1/4] usb: gadget: udc: core: Introduce check_config to verify USB configuration

[Jack Pham]

Hi Wesley,

On Thu, Jan 21, 2021 at 08:01:37PM -0800, Wesley Cheng wrote:
> Some UDCs may have constraints on how many high bandwidth endpoints it can
> support in a certain configuration.  This API allows for the composite
> driver to pass down the total number of endpoints to the UDC so it can verify
> it has the required resources to support the configuration.
> 
> Signed-off-by: Wesley Cheng 
> ---
>  drivers/usb/gadget/udc/core.c | 9 +
>  include/linux/usb/gadget.h| 2 ++
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
> index 4173acd..469962f 100644
> --- a/drivers/usb/gadget/udc/core.c
> +++ b/drivers/usb/gadget/udc/core.c
> @@ -1003,6 +1003,15 @@ int usb_gadget_ep_match_desc(struct usb_gadget *gadget,
>  }
>  EXPORT_SYMBOL_GPL(usb_gadget_ep_match_desc);
>  
> +int usb_gadget_check_config(struct usb_gadget *gadget, unsigned long ep_map)

You should probably add a kernel-doc for this function.

Jack
-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH V5 5/5] of: unittest: Statically apply overlays using fdtoverlay

[David Gibson]

On Fri, Jan 22, 2021 at 08:40:49AM +0530, Viresh Kumar wrote:
> On 22-01-21, 10:39, David Gibson wrote:
> > No, it definitely will not work in general.  It might kinda work in a
> > few trivial cases, but it absolutely will not do the neccessary
> > handling in some cases.
> > 
> > > I
> > > did inspect the output dtb (made by merging two overlays) using
> > > fdtdump and it looked okay.
> > 
> > Ok.. but if you're using these bizarre messed up "dtbs" that this test
> > code seems to be, I don't really trust that tells you much.
> 
> I only looked if the changes from the second overlay were present in
> the merge and they were. And so I assumed that it must have worked.
> 
> What about checking the base dtb for /plugin/; in fdtoverlay and fail
> the whole thing in case it is present ? I think it is possible for
> people to get confused otherwise, like I did.

/plugin/ doesn't exist in the dtb, only in the dts.  From the dtb
encoding point of view, there's no difference between a dtb and a
dtbo, a dtbo is just a dtb that follows some conventions for its
content.

If we were doing this from scratch, it would be better for dtbos to
have a different magic number from regular dtbs.  I think I actually
suggested that sometime in the past, but by the time that came up,
dtbos were already in pretty widespread use with the existing format.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: PGP signature

Re: [PATCH v2 14/20] x86/xen/pvh: Annotate indirect branch as safe

[Jürgen Groß]

On 21.01.21 22:29, Josh Poimboeuf wrote:

This indirect jump is harmless; annotate it to keep objtool's retpoline
validation happy.

Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Signed-off-by: Josh Poimboeuf 


Reviewed-by: Juergen Gross 


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 1/2] fpga: mgr: Adds secure BitStream loading support

[Moritz Fischer]

On Mon, Jan 18, 2021 at 08:20:57AM +0530, Nava kishore Manne wrote:
> This commit adds secure flags to the framework to support
> secure BitStream Loading.
> 
> Signed-off-by: Nava kishore Manne 
> ---
>  drivers/fpga/of-fpga-region.c | 10 ++
>  include/linux/fpga/fpga-mgr.h | 12 
>  2 files changed, 22 insertions(+)
> 
> diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
> index e405309baadc..3a5eb480 100644
> --- a/drivers/fpga/of-fpga-region.c
> +++ b/drivers/fpga/of-fpga-region.c
> @@ -228,6 +228,16 @@ static struct fpga_image_info *of_fpga_region_parse_ov(
>   if (of_property_read_bool(overlay, "encrypted-fpga-config"))
>   info->flags |= FPGA_MGR_ENCRYPTED_BITSTREAM;
>  
> + if (of_property_read_bool(overlay, "userkey-encrypted-fpga-config"))
> + info->flags |= FPGA_MGR_USERKEY_ENCRYPTED_BITSTREAM;

Can this just be encrypted-fpga-config/FPGA_MGR_ENCRYPTED?
> +
> + if (of_property_read_bool(overlay, "ddrmem-authenticated-fpga-config"))
> + info->flags |= FPGA_MGR_DDR_MEM_AUTH_BITSTREAM;
> +
> + if (of_property_read_bool(overlay,
> +   "securemem-authenticated-fpga-config"))
> + info->flags |= FPGA_MGR_SECURE_MEM_AUTH_BITSTREAM;
> +
>   if (!of_property_read_string(overlay, "firmware-name",
>_name)) {
>   info->firmware_name = devm_kstrdup(dev, firmware_name,
> diff --git a/include/linux/fpga/fpga-mgr.h b/include/linux/fpga/fpga-mgr.h
> index 2bc3030a69e5..2f7455a60666 100644
> --- a/include/linux/fpga/fpga-mgr.h
> +++ b/include/linux/fpga/fpga-mgr.h
> @@ -67,12 +67,24 @@ enum fpga_mgr_states {
>   * %FPGA_MGR_BITSTREAM_LSB_FIRST: SPI bitstream bit order is LSB first
>   *
>   * %FPGA_MGR_COMPRESSED_BITSTREAM: FPGA bitstream is compressed
> + *
> + * %FPGA_MGR_USERKEY_ENCRYPTED_BITSTREAM: indicates bitstream is encrypted 
> with
> + *user key
> + *
> + * %FPGA_MGR_DDR_MEM_AUTH_BITSTREAM: do bitstream authentication using DDR
> + *   memory if supported
> + *
> + * %FPGA_MGR_SECURE_MEM_AUTH_BITSTREAM: do bitstream authentication using 
> secure
> + *  memory if supported
>   */
>  #define FPGA_MGR_PARTIAL_RECONFIGBIT(0)
>  #define FPGA_MGR_EXTERNAL_CONFIG BIT(1)
>  #define FPGA_MGR_ENCRYPTED_BITSTREAM BIT(2)
>  #define FPGA_MGR_BITSTREAM_LSB_FIRST BIT(3)
>  #define FPGA_MGR_COMPRESSED_BITSTREAMBIT(4)
> +#define FPGA_MGR_USERKEY_ENCRYPTED_BITSTREAM BIT(5)
> +#define FPGA_MGR_DDR_MEM_AUTH_BITSTREAM  BIT(6)
> +#define FPGA_MGR_SECURE_MEM_AUTH_BITSTREAM   BIT(7)
>  
>  /**
>   * struct fpga_image_info - information specific to a FPGA image
> -- 
> 2.18.0
> 

Thanks,
Moritz

Re: [PATCH 2/2] fpga: Add support for Xilinx DFX AXI Shutdown manager

[Moritz Fischer]

On Tue, Jan 19, 2021 at 06:34:54AM +, Nava kishore Manne wrote:
> Hi Moritz,
> 
>   Thanks for the review.
> Please find my response inline.
> 
> > -Original Message-
> > From: Moritz Fischer 
> > Sent: Saturday, January 16, 2021 8:28 AM
> > To: Nava kishore Manne 
> > Cc: m...@kernel.org; t...@redhat.com; robh...@kernel.org; Michal Simek
> > ; linux-f...@vger.kernel.org;
> > devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> > ker...@vger.kernel.org; git ; chinnikishore...@gmail.com
> > Subject: Re: [PATCH 2/2] fpga: Add support for Xilinx DFX AXI Shutdown
> > manager
> > 
> > Hi,
> > 
> > On Fri, Jan 15, 2021 at 07:04:31AM +0530, Nava kishore Manne wrote:
> > > This patch adds support for Xilinx Dynamic Function eXchange(DFX) AXI
> > > shutdown manager IP. It can be used to safely handling the AXI traffic
> > > on a Reconfigurable Partition when it is undergoing dynamic
> > > reconfiguration and there by preventing system deadlock that may occur
> > > if AXI transactions are interrupted during reconfiguration.
> > >
> > > PR-Decoupler and AXI shutdown manager are completely different IPs.
> > > But both the IP registers are compatible and also both belong to the
> > > same sub-system (fpga-bridge).So using same driver for both IP's.
> > 
> > I'm a bit confused, the whole goal here is to give the thing a different 
> > name?
> 
> 
> Both the PR Decoupler and AXI Shutdown IP manager IP's are follows same 
> register spec.
> Most of the code is common so we thought of reusing  same driver for AXI 
> shutdown manager as well.

What are the differences, though other than it shows a different name?
> 
> > >
> > > Signed-off-by: Nava kishore Manne 
> > > ---
> > >  drivers/fpga/xilinx-pr-decoupler.c | 35
> > > ++
> > >  1 file changed, 31 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/fpga/xilinx-pr-decoupler.c
> > > b/drivers/fpga/xilinx-pr-decoupler.c
> > > index 7d69af230567..c95f3d065ccb 100644
> > > --- a/drivers/fpga/xilinx-pr-decoupler.c
> > > +++ b/drivers/fpga/xilinx-pr-decoupler.c
> > > @@ -19,10 +19,15 @@
> > >  #define CTRL_OFFSET  0
> > >
> > >  struct xlnx_pr_decoupler_data {
> > > + const struct xlnx_config_data *ipconfig;
> > >   void __iomem *io_base;
> > >   struct clk *clk;
> > >  };
> > >
> > > +struct xlnx_config_data {
> > > + char *name;
> > > +};
> > > +
> > >  static inline void xlnx_pr_decoupler_write(struct xlnx_pr_decoupler_data
> > *d,
> > >  u32 offset, u32 val)
> > >  {
> > > @@ -76,15 +81,28 @@ static const struct fpga_bridge_ops
> > xlnx_pr_decoupler_br_ops = {
> > >   .enable_show = xlnx_pr_decoupler_enable_show,  };
> > >
> > > +static const struct xlnx_config_data decoupler_config = {
> > > + .name = "Xilinx PR Decoupler",
> > > +};
> > > +
> > > +static const struct xlnx_config_data shutdown_config = {
> > > + .name = "Xilinx DFX AXI shutdown mgr", };
> > 
> > If it's just the strings, why not store them as is?
> 
> In order to differentiate the IP's at probe time we are using this name filed.
> 
> > > +
> > >  static const struct of_device_id xlnx_pr_decoupler_of_match[] = {
> > > - { .compatible = "xlnx,pr-decoupler-1.00", },
> > > - { .compatible = "xlnx,pr-decoupler", },
> > > + { .compatible = "xlnx,pr-decoupler-1.00", .data = _config
> > },
> > > + { .compatible = "xlnx,pr-decoupler", .data = _config },
> > > + { .compatible = "xlnx,dfx-axi-shutdown-manager-1.00",
> > > + .data = _config },
> > > + { .compatible = "xlnx,dfx-axi-shutdown-manager",
> > > + .data = _config },
> > >   {},
> > >  };
> > >  MODULE_DEVICE_TABLE(of, xlnx_pr_decoupler_of_match);
> > >
> > >  static int xlnx_pr_decoupler_probe(struct platform_device *pdev)  {
> > > + struct device_node *np = pdev->dev.of_node;
> > >   struct xlnx_pr_decoupler_data *priv;
> > >   struct fpga_bridge *br;
> > >   int err;
> > > @@ -94,6 +112,14 @@ static int xlnx_pr_decoupler_probe(struct
> > platform_device *pdev)
> > >   if (!priv)
> > >   return -ENOMEM;
> > >
> > > + if (np) {
> > > + const struct of_device_id *match;
> > > +
> > > + match = of_match_node(xlnx_pr_decoupler_of_match, np);
> > > + if (match && match->data)
> > > + priv->ipconfig = match->data;
> > > + }
> > > +
> > >   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > >   priv->io_base = devm_ioremap_resource(>dev, res);
> > >   if (IS_ERR(priv->io_base))
> > > @@ -114,7 +140,7 @@ static int xlnx_pr_decoupler_probe(struct
> > > platform_device *pdev)
> > >
> > >   clk_disable(priv->clk);
> > >
> > > - br = devm_fpga_bridge_create(>dev, "Xilinx PR Decoupler",
> > > + br = devm_fpga_bridge_create(>dev, priv->ipconfig->name,
> > >_pr_decoupler_br_ops, priv);
> > >   if (!br) {
> > >   err = -ENOMEM;
> > > @@ -125,7 +151,8 @@ static int