Re: [PATCH] scsi: sd: add runtime pm to open / release

[Martin Kepplinger]

On 07.08.20 16:30, Alan Stern wrote:
> On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote:
>> it's really strange: below is the change I'm trying. Of course that's
>> only for testing the functionality, nothing how a patch could look like.
>>
>> While I remember it had worked, now (weirdly since I tried that mounting
>> via fstab) it doesn't anymore!
>>
>> What I understand (not much): I handle the error with "retry" via the
>> new flag, but scsi_decide_disposition() returns SUCCESS because of "no
>> more retries"; but it's the first and only time it's called.
> 
> Are you saying that scmd->allowed is set to 0?  Or is scsi_notry_cmd() 
> returning a nonzero value?  Whichever is true, why does it happen that 
> way?

scsi_notry_cmd() is returning 1. (it's retry 1 of 5 allowed).

why is it returning 1? REQ_FAILFAST_DEV is set. It's DID_OK, then "if
(status_byte(scmd->result) != CHECK_CONDITION)" appearently is not true,
then at the end it returns 1 because of REQ_FAILFAST_DEV.

that seems to come from the block layer. why and when? could I change
that so that the scsi error handling stays in control?

> 
> What is the failing command?  Is it a READ(10)?

Not sure how I'd answer that, but here's the test to trigger the error:

mount /dev/sda1 /mnt
cd /mnt
ls
cp file ~/ (if ls "works" and doesn't yet trigger the error)

and that's the (familiar looking) logs when doing so. again: despite the
mentioned workaround in scsi_error and the new expected_media_change
flag *is* set and gets cleared, as it should be. REQ_FAILFAST_DEV seems
to override what I want to do is scsi_error:

[   55.557629] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result:
hostbyte=0x00 driverbyte=0x08 cmd_age=0s
[   55.557639] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current]
[   55.557646] sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0
[   55.557657] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 08 fc
e0 00 00 01 00
[   55.557666] blk_update_request: I/O error, dev sda, sector 589024 op
0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   55.568899] sd 0:0:0:0: [sda] tag#0 device offline or changed
[   55.574691] blk_update_request: I/O error, dev sda, sector 589025 op
0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   55.585756] sd 0:0:0:0: [sda] tag#0 device offline or changed
[   55.591562] blk_update_request: I/O error, dev sda, sector 589026 op
0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   55.602274] sd 0:0:0:0: [sda] tag#0 device offline or changed
(... goes on with the same)


> 
>> How can this be? What am I missing?
> 
> It's kind of hard to tell without seeing the error messages or system 
> log or any debugging information.

thanks a lot for getting back to me,

   martin


> 
> Alan Stern
> 
>> --- a/drivers/scsi/scsi_error.c
>> +++ b/drivers/scsi/scsi_error.c
>> @@ -565,6 +565,13 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
>>  return NEEDS_RETRY;
>>  }
>>  }
>> +if (scmd->device->expecting_media_change) {
>> +if (sshdr.asc == 0x28 && sshdr.ascq == 0x00) {
>> +scmd->device->expecting_media_change = 0;
>> +return NEEDS_RETRY;
>> +}
>> +}
>> +
>>  /*
>>   * we might also expect a cc/ua if another LUN on the target
>>   * reported a UA with an ASC/ASCQ of 3F 0E -
>> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
>> index d90fefffe31b..bb583e403b81 100644
>> --- a/drivers/scsi/sd.c
>> +++ b/drivers/scsi/sd.c
>> @@ -3642,6 +3642,8 @@ static int sd_resume(struct device *dev)
>>  if (!sdkp)  /* E.g.: runtime resume at the start of sd_probe() */
>>  return 0;
>>
>> +sdkp->device->expecting_media_change = 1;
>> +
>>  if (!sdkp->device->manage_start_stop)
>>  return 0;
>>
>> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
>> index bc5909033d13..f5fc1af68e00 100644
>> --- a/include/scsi/scsi_device.h
>> +++ b/include/scsi/scsi_device.h
>> @@ -169,6 +169,7 @@ struct scsi_device {
>>   * this device */
>>  unsigned expecting_cc_ua:1; /* Expecting a CHECK_CONDITION/UNIT_ATTN
>>   * because we did a bus reset. */
>> +unsigned expecting_media_change:1;
>>  unsigned use_10_for_rw:1; /* first try 10-byte read / write */
>>  unsigned use_10_for_ms:1; /* first try 10-byte mode sense/select */
>>  unsigned set_dbd_for_ms:1; /* Set "DBD" field in mode sense */

drivers/soc/qcom/socinfo.c:277 qcom_show_pmic_model() error: buffer overflow 'pmic_models' 26 <= 26

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   049eb096da48db0421dd5e358b9b082a1a8a2025
commit: e9247e2ce5778678c8d631e26ef79dbccedbe6d0 soc: qcom: socinfo: fix 
printing of pmic_model
date:   6 weeks ago
config: x86_64-randconfig-m001-20200808 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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

New smatch warnings:
drivers/soc/qcom/socinfo.c:277 qcom_show_pmic_model() error: buffer overflow 
'pmic_models' 26 <= 26

Old smatch warnings:
drivers/soc/qcom/socinfo.c:278 qcom_show_pmic_model() error: buffer overflow 
'pmic_models' 26 <= 26

vim +/pmic_models +277 drivers/soc/qcom/socinfo.c

   268  
   269  static int qcom_show_pmic_model(struct seq_file *seq, void *p)
   270  {
   271  struct socinfo *socinfo = seq->private;
   272  int model = SOCINFO_MINOR(le32_to_cpu(socinfo->pmic_model));
   273  
   274  if (model < 0)
   275  return -EINVAL;
   276  
 > 277  if (model <= ARRAY_SIZE(pmic_models) && pmic_models[model])
   278  seq_printf(seq, "%s\n", pmic_models[model]);
   279  else
   280  seq_printf(seq, "unknown (%d)\n", model);
   281  
   282  return 0;
   283  }
   284  

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


.config.gz
Description: application/gzip

Re: [PATCH] tty: synclink_gt: switch from 'pci_' to 'dma_' API

[Jiri Slaby]

On 06. 08. 20, 7:44, Christophe JAILLET wrote:
> The wrappers in include/linux/pci-dma-compat.h should go away.
> 
> The patch has been generated with the coccinelle script below and has been
> hand modified to replace GFP_ with a correct flag.
> It has been compile tested.
> 
> When memory is allocated in 'alloc_desc()' and 'alloc_bufs()', GFP_KERNEL
> can be used because it is only called from a probe function and no lock is
> acquired.
> The call chain is:
>init_one(the probe function)
>   --> device_init
>  --> alloc_dma_bufs
> --> alloc_desc
> --> alloc_bufs

Right.

...
> Signed-off-by: Christophe JAILLET 

Reviewed-by: Jiri Slaby 

> ---
> If needed, see post from Christoph Hellwig on the kernel-janitors ML:
>https://marc.info/?l=kernel-janitors&m=158745678307186&w=4
> ---
>  drivers/tty/synclink_gt.c | 14 +-
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/tty/synclink_gt.c b/drivers/tty/synclink_gt.c
> index b794177ccfb9..1edf06653148 100644
> --- a/drivers/tty/synclink_gt.c
> +++ b/drivers/tty/synclink_gt.c
> @@ -3341,8 +3341,8 @@ static int alloc_desc(struct slgt_info *info)
>   unsigned int pbufs;
>  
>   /* allocate memory to hold descriptor lists */
> - info->bufs = pci_zalloc_consistent(info->pdev, DESC_LIST_SIZE,
> -&info->bufs_dma_addr);
> + info->bufs = dma_alloc_coherent(&info->pdev->dev, DESC_LIST_SIZE,
> + &info->bufs_dma_addr, GFP_KERNEL);
>   if (info->bufs == NULL)
>   return -ENOMEM;
>  
> @@ -3384,7 +3384,8 @@ static int alloc_desc(struct slgt_info *info)
>  static void free_desc(struct slgt_info *info)
>  {
>   if (info->bufs != NULL) {
> - pci_free_consistent(info->pdev, DESC_LIST_SIZE, info->bufs, 
> info->bufs_dma_addr);
> + dma_free_coherent(&info->pdev->dev, DESC_LIST_SIZE,
> +   info->bufs, info->bufs_dma_addr);
>   info->bufs  = NULL;
>   info->rbufs = NULL;
>   info->tbufs = NULL;
> @@ -3395,7 +3396,9 @@ static int alloc_bufs(struct slgt_info *info, struct 
> slgt_desc *bufs, int count)
>  {
>   int i;
>   for (i=0; i < count; i++) {
> - if ((bufs[i].buf = pci_alloc_consistent(info->pdev, DMABUFSIZE, 
> &bufs[i].buf_dma_addr)) == NULL)
> + bufs[i].buf = dma_alloc_coherent(&info->pdev->dev, DMABUFSIZE,
> +  &bufs[i].buf_dma_addr, 
> GFP_KERNEL);
> + if (!bufs[i].buf)
>   return -ENOMEM;
>   bufs[i].pbuf  = cpu_to_le32((unsigned int)bufs[i].buf_dma_addr);
>   }
> @@ -3408,7 +3411,8 @@ static void free_bufs(struct slgt_info *info, struct 
> slgt_desc *bufs, int count)
>   for (i=0; i < count; i++) {
>   if (bufs[i].buf == NULL)
>   continue;
> - pci_free_consistent(info->pdev, DMABUFSIZE, bufs[i].buf, 
> bufs[i].buf_dma_addr);
> + dma_free_coherent(&info->pdev->dev, DMABUFSIZE, bufs[i].buf,
> +   bufs[i].buf_dma_addr);
>   bufs[i].buf = NULL;
>   }
>  }
> 

thanks,
-- 
js

INVESTMENT

[campbellclark016]

Good day,

 You were recommended by a mutual associate. I write you regarding an 
investment of bearer bonds I made on behalf of a client. The investment was 
made in 2009 and has been under my management. The said investor is deceased. 
The window is now available to assign these bonds to any name or company of my 
choice. I have all the necessary information to achieve this within 10 banking 
days. The total value of the bond is 100 million pounds sterling, in a million 
pound denominations. If you can handle this, do contact me at your earliest 
convenience via my email campbell.clar...@yahoo.com So we can discuss the finer 
details


Thank you


Mr Campbell Clark

[PATCH] mailmap: Update comments for with format and more detalis

[Kees Cook]

Without having first read the git-shortlog man-page first, the format
of .mailmap may not be immediately obvious. Add comments with pointers
to the man-page, along with other details.

Signed-off-by: Kees Cook 
---
I'm adding this to my earlier .mailmap update series:
https://lore.kernel.org/lkml/20200730183702.702552-1-keesc...@chromium.org/
---
 .mailmap | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/.mailmap b/.mailmap
index 6c1c04a63b18..3a991e19928c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -2,11 +2,16 @@
 # This list is used by git-shortlog to fix a few botched name translations
 # in the git archive, either because the author's full name was messed up
 # and/or not always written the same way, making contributions from the
-# same person appearing not to be so or badly displayed.
+# same person appearing not to be so or badly displayed. Also allows for
+# old email addresses to map to new email addresses.
 #
+# For format details, see "MAPPING AUTHORS" in "man git-shortlog".
+#
+# Please keep this list dictionary sorted.
+#
+# This comment is parsed by git-shortlog:
 # repo-abbrev: /pub/scm/linux/kernel/git/
 #
-
 Aaron Durbin 
 Adam Oldham 
 Adam Radford 
-- 
2.25.1


-- 
Kees Cook

答复: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI device in RMRR

[FelixCui-oc]

Hi baolu,
The attachment is the new patch.
If you have any questions, you can contact me at any time.
Thanks.

Best regards
Felix cui-oc




-邮件原件-
发件人: Lu Baolu  
发送时间: 2020年8月7日 16:08
收件人: FelixCui-oc ; Joerg Roedel ; 
io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org; David Woodhouse 

抄送: baolu...@linux.intel.com; RaymondPang-oc ; 
CobeChen-oc 
主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI 
device in RMRR

Hi,

On 2020/8/7 11:29, FelixCui-oc wrote:
> Hi baolu,
>   I understand what you mean is that you want to put the 
> following processing code in the acpi_device_create_direct_mappings() into 
> the probe_acpi_namespace_devices() ,right?
>   If you mean it , I think it's OK.

Yes. If the acpi device has companion physical devices, then probe the 
companion devices; otherwise, probe the acpi device instead. Also, let's put 
detecting and probing acpi devices in different patches so that they could be 
easier for reviewing.

Best regards,
baolu

> 
>   if (pn_dev == NULL) {
>   acpi_device->bus->iommu_ops = &intel_iommu_ops;
>   ret = iommu_probe_device(acpi_device);
>   if (ret) {
>   pr_err("acpi_device probe fail! ret:%d\n", ret);
>   return ret;
>   }
>   return 0;
>   }
> 
> Best regards
> Felix cui-oc
> 
> 
> 
>   
> 
> -邮件原件-
> 发件人: Lu Baolu 
> 发送时间: 2020年8月7日 9:08
> 收件人: FelixCui-oc ; Joerg Roedel 
> ; io...@lists.linux-foundation.org; 
> linux-kernel@vger.kernel.org; David Woodhouse 
> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
> ; CobeChen-oc 
> 主题: Re: 答复: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for 
> ACPI device in RMRR
> 
> Hi Felix,
> 
> On 2020/8/6 14:51, FelixCui-oc wrote:
>> Hi  baolu,
>>  >Sure. Before that, let me sync my understanding with you. You 
>> have an acpi namespace device in ANDD table, it also shows up in the device 
>> scope of a RMRR.
>>  >Current code doesn't enumerate that device for the RMRR, hence 
>> iommu_create_device_direct_mappings() doesn't work for this device.
>>
>>  >At the same time, probe_acpi_namespace_devices() doesn't work 
>> for this device, hence you want to add a home-made
>>  >acpi_device_create_direct_mappings() helper.
>>
>>  Your understanding is right.
>>  But there is a problem that even if the namespace device in 
>> rmrr is enumerated in the code, probe_acpi_namespace_devices() also doesn't 
>> work for this device.
>>  This is because the dev parameter of the 
>> iommu_create_device_direct_mappings() is not the namespace device in RMRR.
>>  The actual parameter passed in is the namespace device's 
>> physical node device.
>>  In iommu_create_device_direct_mappings(), the physical node 
>> device passed in cannot match the namespace device in rmrr->device[],right?
>>  We need acpi_device_create_direct_mappings() helper ?
>>
>>  In addition, adev->physical_node_list is related to the __HID 
>> of namespace device reported by the bios.
>>  For example, if the __HID reported by the bios belongs to 
>> acpi_pnp_device_ids[], adev->physical_node_list has no devices.
>>  So in acpi_device_create_direct_mappings(), I added the case 
>> that adev->physical_node_list is empty.
> 
> Got you. Thanks!
> 
> Have you ever tried to have probe_acpi_namespace_devices() handle the case of 
> empty adev->physical_node_list at the same time?
> 
> Best regards,
> baolu
> 
>>
>>
>> Best regards
>> Felix cui
>>
>>
>>
>>
>> -邮件原件-
>> 发件人: Lu Baolu 
>> 发送时间: 2020年8月6日 10:36
>> 收件人: FelixCui-oc ; Joerg Roedel 
>> ; io...@lists.linux-foundation.org; 
>> linux-kernel@vger.kernel.org; David Woodhouse 
>> 抄送: baolu...@linux.intel.com; RaymondPang-oc 
>> ; CobeChen-oc 
>> 主题: Re: 答复: 答复: 答复: 答复: 答复: [PATCH] iommu/vt-d:Add support for ACPI 
>> device in RMRR
>>
>> Hi Felix,
>>
>> On 8/5/20 3:37 PM, FelixCui-oc wrote:
>>> Hi baolu,
>>> Let me talk about why acpi_device_create_direct_mappings() is 
>>> needed and please tell me if there is an error.
>>
>> Sure. Before that, let me sync my understanding with you. You have an acpi 
>> namespace device in ANDD table, it also shows up in the device scope of a 
>> RMRR. Current code doesn't enumerate that device for the RMRR, hence 
>> iommu_create_device_direct_mappings() doesn't work for this device.
>>
>> At the same time, probe_acpi_namespace_devices() doesn't work for 
>> this device, hence you want to add a home-made
>> acpi_device_create_direct_mappings() helper.
>>
>> Did I get it right?
>>
>>> In the probe_acpi_namespace_devices() function, only the device 
>>> in the addev->physical_node_list is probed,
>>> but we need to establish identity mapping for the namespace

Re: [PATCH v7 3/9] net/scm: Regularize compat handling of scm_detach_fds()

[Kees Cook]

On Fri, Aug 07, 2020 at 05:02:15PM -0700, John Stultz wrote:
> On Fri, Aug 7, 2020 at 3:18 PM Kees Cook  wrote:
> >
> > On Fri, Aug 07, 2020 at 01:29:24PM -0700, John Stultz wrote:
> > > On Thu, Jul 9, 2020 at 11:28 AM Kees Cook  wrote:
> > > >
> > > > Duplicate the cleanups from commit 2618d530dd8b ("net/scm: cleanup
> > > > scm_detach_fds") into the compat code.
> > > >
> > > > Replace open-coded __receive_sock() with a call to the helper.
> > > >
> > > > Move the check added in commit 1f466e1f15cf ("net: cleanly handle kernel
> > > > vs user buffers for ->msg_control") to before the compat call, even
> > > > though it should be impossible for an in-kernel call to also be compat.
> > > >
> > > > Correct the int "flags" argument to unsigned int to match fd_install()
> > > > and similar APIs.
> > > >
> > > > Regularize any remaining differences, including a whitespace issue,
> > > > a checkpatch warning, and add the check from commit 6900317f5eff ("net,
> > > > scm: fix PaX detected msg_controllen overflow in scm_detach_fds") which
> > > > fixed an overflow unique to 64-bit. To avoid confusion when comparing
> > > > the compat handler to the native handler, just include the same check
> > > > in the compat handler.
> > > >
> > > > Acked-by: Christian Brauner 
> > > > Signed-off-by: Kees Cook 
> > > > ---
> > >
> > > Hey Kees,
> > >   So during the merge window (while chasing a few other regressions),
> > > I noticed occasionally my Dragonboard 845c running AOSP having trouble
> > > with the web browser crashing or other apps hanging, and I've bisected
> > > the issue down to this change.
> > >
> > > Unfortunately it doesn't revert cleanly so I can't validate reverting
> > > it sorts things against linus/HEAD.  Anyway, I wanted to check and see
> > > if you had any other reports of similar or any ideas what might be
> > > going wrong?
> >
> > Hi; Yes, sorry for the trouble. I had a typo in a refactor of
> > SCM_RIGHTS. I suspect it'll be fixed by this:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1fa2c0a0c814fbae0eb3e79a510765225570d043
> >
> > Can you verify Linus's latest tree works for you? If not, there might be
> > something else hiding in the corners...
> 
> Thanks so much! Yes, I just updated to Linus' latest and the issue has
> disappeared!
> 
> thanks again!

Whew; sorry again and thanks for testing! :)

-- 
Kees Cook

[PATCH] gpu/drm: Remove TTM_PL_FLAG_WC of VRAM to fix writecombine issue for Loongson64

[Tiezhu Yang]

Loongson processors have a writecombine issue that maybe failed to
write back framebuffer used with ATI Radeon or AMD GPU at times,
after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine
mapping for MIPS"), there exists some errors such as blurred screen
and lockup, and so on.

Remove the flag TTM_PL_FLAG_WC of VRAM to fix writecombine issue for
Loongson64 to work well with ATI Radeon or AMD GPU, and it has no any
influence on the other platforms.

[   60.958721] radeon :03:00.0: ring 0 stalled for more than 10079msec
[   60.965315] radeon :03:00.0: GPU lockup (current fence id 
0x0112 last fence id 0x011d on ring 0)
[   60.976525] radeon :03:00.0: ring 3 stalled for more than 10086msec
[   60.983156] radeon :03:00.0: GPU lockup (current fence id 
0x0374 last fence id 0x03a8 on ring 3)

Signed-off-by: Tiezhu Yang 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  7 +--
 drivers/gpu/drm/radeon/radeon_object.c | 20 ++--
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 5ac7b55..9f785f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -136,8 +136,11 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo 
*abo, u32 domain)
 
places[c].fpfn = 0;
places[c].lpfn = 0;
-   places[c].flags = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED |
-   TTM_PL_FLAG_VRAM;
+   if (IS_ENABLED(CONFIG_MACH_LOONGSON64))
+   places[c].flags = TTM_PL_FLAG_UNCACHED | 
TTM_PL_FLAG_VRAM;
+   else
+   places[c].flags = TTM_PL_FLAG_WC | TTM_PL_FLAG_UNCACHED 
|
+ TTM_PL_FLAG_VRAM;
 
if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)
places[c].lpfn = visible_pfn;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
b/drivers/gpu/drm/radeon/radeon_object.c
index f3dee01..c6cede6 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -112,15 +112,23 @@ void radeon_ttm_placement_from_domain(struct radeon_bo 
*rbo, u32 domain)
rbo->rdev->mc.visible_vram_size < 
rbo->rdev->mc.real_vram_size) {
rbo->placements[c].fpfn =
rbo->rdev->mc.visible_vram_size >> PAGE_SHIFT;
-   rbo->placements[c++].flags = TTM_PL_FLAG_WC |
-TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_VRAM;
+   if (IS_ENABLED(CONFIG_MACH_LOONGSON64))
+   rbo->placements[c++].flags = 
TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_VRAM;
+   else
+   rbo->placements[c++].flags = TTM_PL_FLAG_WC |
+
TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_VRAM;
}
 
rbo->placements[c].fpfn = 0;
-   rbo->placements[c++].flags = TTM_PL_FLAG_WC |
-TTM_PL_FLAG_UNCACHED |
-TTM_PL_FLAG_VRAM;
+   if (IS_ENABLED(CONFIG_MACH_LOONGSON64))
+   rbo->placements[c++].flags = TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_VRAM;
+   else
+   rbo->placements[c++].flags = TTM_PL_FLAG_WC |
+TTM_PL_FLAG_UNCACHED |
+TTM_PL_FLAG_VRAM;
}
 
if (domain & RADEON_GEM_DOMAIN_GTT) {
-- 
2.1.0

drivers/vhost/net.c:1010 vhost_net_rx_peek_head_len() error: double unlocked 'sk->sk_receive_queue.lock' (orig line 1002)

[kernel test robot]

Hi Jason,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 20c384f1ea1a0bc7320bc445c72dd02d2970d594 vhost: refine vhost and vringh 
kconfig
date:   4 months ago
config: arm-randconfig-m031-20200808 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0

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

New smatch warnings:
drivers/vhost/net.c:1010 vhost_net_rx_peek_head_len() error: double unlocked 
'sk->sk_receive_queue.lock' (orig line 1002)
drivers/vhost/net.c:1010 vhost_net_rx_peek_head_len() error: double unlocked 
'sk->sk_receive_queue.lock' (orig line 1002)

Old smatch warnings:
drivers/vhost/net.c:1528 vhost_net_set_backend() warn: passing a valid pointer 
to 'PTR_ERR'

vim +1010 drivers/vhost/net.c

8dd014adfea6f17 David Stevens   2010-07-27   994  
be294a51adfc1e1 Toshiaki Makita 2018-07-03   995  static int 
vhost_net_rx_peek_head_len(struct vhost_net *net, struct sock *sk,
be294a51adfc1e1 Toshiaki Makita 2018-07-03   996
  bool *busyloop_intr)
030881372460654 Jason Wang  2016-03-04   997  {
28b9b33b983f4de Toshiaki Makita 2018-07-03   998struct 
vhost_net_virtqueue *rnvq = &net->vqs[VHOST_NET_VQ_RX];
28b9b33b983f4de Toshiaki Makita 2018-07-03   999struct 
vhost_net_virtqueue *tnvq = &net->vqs[VHOST_NET_VQ_TX];
6369fec5be0aad4 Toshiaki Makita 2018-07-03  1000struct vhost_virtqueue 
*rvq = &rnvq->vq;
28b9b33b983f4de Toshiaki Makita 2018-07-03  1001struct vhost_virtqueue 
*tvq = &tnvq->vq;
28b9b33b983f4de Toshiaki Makita 2018-07-03 @1002int len = 
peek_head_len(rnvq, sk);
030881372460654 Jason Wang  2016-03-04  1003  
dc151282bbdaed0 Tonghao Zhang   2018-09-25  1004if (!len && 
rvq->busyloop_timeout) {
f5a4941aa6d190e Jason Wang  2018-05-29  1005/* Flush 
batched heads first */
09c3248938c3e3b Jason Wang  2018-07-20  1006
vhost_net_signal_used(rnvq);
030881372460654 Jason Wang  2016-03-04  1007/* Both tx vq 
and rx socket were polled here */
dc151282bbdaed0 Tonghao Zhang   2018-09-25  1008
vhost_net_busy_poll(net, rvq, tvq, busyloop_intr, true);
030881372460654 Jason Wang  2016-03-04  1009  
28b9b33b983f4de Toshiaki Makita 2018-07-03 @1010len = 
peek_head_len(rnvq, sk);
030881372460654 Jason Wang  2016-03-04  1011}
030881372460654 Jason Wang  2016-03-04  1012  
030881372460654 Jason Wang  2016-03-04  1013return len;
030881372460654 Jason Wang  2016-03-04  1014  }
030881372460654 Jason Wang  2016-03-04  1015  

:: The code at line 1010 was first introduced by commit
:: 28b9b33b983f4de3ce9e660e3efe1e08adabf779 vhost_net: Rename local 
variables in vhost_net_rx_peek_head_len

:: TO: Toshiaki Makita 
:: CC: David S. Miller 

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


.config.gz
Description: application/gzip

Re: [PATCH 20/20] arm64: dts: renesas: r8a774e1: Add VIN and CSI-2 nodes

[Niklas Söderlund]

Hi Geert and Lad,

On 2020-08-07 13:36:46 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
> 
> On Fri, Aug 7, 2020 at 1:27 PM Niklas Söderlund
>  wrote:
> > On 2020-08-06 13:47:58 +0200, Geert Uytterhoeven wrote:
> > > On Thu, Aug 6, 2020 at 1:17 PM Lad, Prabhakar
> > >  wrote:
> > > > On Wed, Aug 5, 2020 at 12:19 PM Geert Uytterhoeven 
> > > >  wrote:
> > > > > On Thu, Jul 16, 2020 at 7:20 PM Lad Prabhakar
> > > > >  wrote:
> > > > > > Add VIN and CSI-2 nodes to RZ/G2H (R8A774E1) SoC dtsi.
> > > > > >
> > > > > > Signed-off-by: Lad Prabhakar 
> > > > > > 
> > > > > > Reviewed-by: Marian-Cristian Rotariu 
> > > > > > 
> > > > >
> > > > > Reviewed-by: Geert Uytterhoeven 
> > > > >
> > > > > However, before I queue this in renesas-devel for v5.10, I'd like to
> > > > > have some clarification about the issue below.
> > > > >
> > > > > > --- a/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/renesas/r8a774e1.dtsi
> > > > >
> > > > > > +   vin4: video@e6ef4000 {
> > > > > > +   compatible = "renesas,vin-r8a774e1";
> > > > > > +   reg = <0 0xe6ef4000 0 0x1000>;
> > > > > > +   interrupts =  > > > > > IRQ_TYPE_LEVEL_HIGH>;
> > > > > > +   clocks = <&cpg CPG_MOD 807>;
> > > > > > +   power-domains = <&sysc 
> > > > > > R8A774E1_PD_ALWAYS_ON>;
> > > > > > +   resets = <&cpg 807>;
> > > > > > +   renesas,id = <4>;
> > > > > > +   status = "disabled";
> > > > > > +
> > > > > > +   ports {
> > > > > > +   #address-cells = <1>;
> > > > > > +   #size-cells = <0>;
> > > > > > +
> > > > > > +   port@1 {
> > > > > > +   #address-cells = <1>;
> > > > > > +   #size-cells = <0>;
> > > > >
> > > > > "make dtbs W=1" says:
> > > > >
> > > > > arch/arm64/boot/dts/renesas/r8a774e1.dtsi:1562.12-1572.7: Warning
> > > > > (graph_child_address): /soc/video@e6ef4000/ports/port@1: graph node
> > > > > has single child node 'endpoint@0', #address-cells/#size-cells are not
> > > > > necessary
> > > > >
> > > > > (same for vin5-7 below)
> > > > >
> > > > Referring to commit 5e53dbf4edb4d ("arm64: dts: renesas: r8a77990: Fix
> > > > VIN endpoint numbering") we definitely need endpoint numbering.
> > > > Probably the driver needs to be fixed to handle such cases.
> > >
> > > > > > +
> > > > > > +   reg = <1>;
> > > > > > +
> > > > > > +   vin4csi20: endpoint@0 {
> > > > > > +   reg = <0>;
> > > > > > +   remote-endpoint = 
> > > > > > <&csi20vin4>;
> > >
> > > On R-Car E3, the single endpoint is at address 2, so "make dtbs 
> > > W=1"doesn't
> > > complain. Here it is at address 0.
> > >
> > > Niklas?
> >
> > First the R-Car VIN driver makes decisions based on which endpoint is
> > described, each endpoint 0-3 represents a different CSI-2 block on the
> > other end (0: CSI20, 1: CSI21, 2: CSI40 and 3: CSI41).
> 
> That's my understanding, too.
> 
> > Then how to handle the warning I'm not sure. I can only really see 2
> > options.
> >
> > 1. Ignore the warning.
> > 2. Remove #address-cells, #size-cells and reg properties from port@ if
> >the only endpoint described is endpoint@0.
> >
> > I would prefers option 2. that is what we do in other cases (for example
> > on Gen2 boards that only have a single parallel sensor in some early DTS
> > files we don't have the ports node and just describe a single port with
> > the same reasoning.
> >
> > We are not at risk at someone describing a second CSI-2 bock as an
> > overlay so I see no real harm in option 2.
> 
> Yeah, no overlay possible for on-SoC wiring ;-)
> 
> > What are your thoughts Geert?
> > You know more about DT then me.
> 
> You have too much faith in me ;-)
> 
> AFAIK we don't get this warning for e.g. SPI buses, which can have a
> single device at address 0, and #{address,size}-cells is mandatory
> there. So endpoints (or SPI?) are treated special?

That is a good question, I don't know if either of those are treated 
special. Lad could you look into this?

> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> -- 
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

-- 
Regards,
Niklas Söderlund

samsung_tty.c:undefined reference to `dma_release_channel'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: d76271d22694e874ed70791702db9252ffe96a4c drm: xlnx: DRM/KMS driver for 
Xilinx ZynqMP DisplayPort Subsystem
date:   3 weeks ago
config: nios2-randconfig-r033-20200808 (attached as .config)
compiler: nios2-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
git checkout d76271d22694e874ed70791702db9252ffe96a4c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=nios2 

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

All errors (new ones prefixed by >>):

   nios2-linux-ld: crypto/async_tx/async_tx.o: in function `async_tx_submit':
>> async_tx.c:(.text+0xc0): undefined reference to `dma_wait_for_async_tx'
   async_tx.c:(.text+0xc0): relocation truncated to fit: R_NIOS2_CALL26 against 
`dma_wait_for_async_tx'
   nios2-linux-ld: crypto/async_tx/async_tx.o: in function `async_tx_quiesce':
   async_tx.c:(.text+0x1c4): undefined reference to `dma_wait_for_async_tx'
   async_tx.c:(.text+0x1c4): relocation truncated to fit: R_NIOS2_CALL26 
against `dma_wait_for_async_tx'
   nios2-linux-ld: crypto/async_tx/async_memcpy.o: in function `async_memcpy':
>> async_memcpy.c:(.text+0x64): undefined reference to 
>> `dmaengine_get_unmap_data'
   async_memcpy.c:(.text+0x64): relocation truncated to fit: R_NIOS2_CALL26 
against `dmaengine_get_unmap_data'
>> nios2-linux-ld: async_memcpy.c:(.text+0x200): undefined reference to 
>> `dmaengine_unmap_put'
   async_memcpy.c:(.text+0x200): relocation truncated to fit: R_NIOS2_CALL26 
against `dmaengine_unmap_put'
   nios2-linux-ld: crypto/async_tx/async_xor.o: in function `async_xor':
>> async_xor.c:(.text+0x74): undefined reference to `dmaengine_get_unmap_data'
   async_xor.c:(.text+0x74): relocation truncated to fit: R_NIOS2_CALL26 
against `dmaengine_get_unmap_data'
>> nios2-linux-ld: async_xor.c:(.text+0x334): undefined reference to 
>> `dmaengine_unmap_put'
   async_xor.c:(.text+0x334): relocation truncated to fit: R_NIOS2_CALL26 
against `dmaengine_unmap_put'
   nios2-linux-ld: async_xor.c:(.text+0x40c): undefined reference to 
`dmaengine_unmap_put'
   async_xor.c:(.text+0x40c): relocation truncated to fit: R_NIOS2_CALL26 
against `dmaengine_unmap_put'
   nios2-linux-ld: async_xor.c:(.text+0x548): undefined reference to 
`dmaengine_unmap_put'
   async_xor.c:(.text+0x548): relocation truncated to fit: R_NIOS2_CALL26 
against `dmaengine_unmap_put'
   nios2-linux-ld: crypto/async_tx/async_xor.o: in function `async_xor_val':
   async_xor.c:(.text+0x6f0): undefined reference to `dmaengine_get_unmap_data'
   async_xor.c:(.text+0x6f0): relocation truncated to fit: R_NIOS2_CALL26 
against `dmaengine_get_unmap_data'
   nios2-linux-ld: async_xor.c:(.text+0x89c): undefined reference to 
`dmaengine_unmap_put'
   async_xor.c:(.text+0x89c): relocation truncated to fit: R_NIOS2_CALL26 
against `dmaengine_unmap_put'
   nios2-linux-ld: crypto/async_tx/async_pq.o: in function `async_gen_syndrome':
>> async_pq.c:(.text+0x88): undefined reference to `dmaengine_get_unmap_data'
   async_pq.c:(.text+0x88): additional relocation overflows omitted from the 
output
>> nios2-linux-ld: async_pq.c:(.text+0x1b8): undefined reference to 
>> `dmaengine_unmap_put'
   nios2-linux-ld: async_pq.c:(.text+0x730): undefined reference to 
`dmaengine_unmap_put'
   nios2-linux-ld: crypto/async_tx/async_pq.o: in function `async_syndrome_val':
   async_pq.c:(.text+0x8a0): undefined reference to `dmaengine_get_unmap_data'
   nios2-linux-ld: async_pq.c:(.text+0xad0): undefined reference to 
`dmaengine_unmap_put'
   nios2-linux-ld: drivers/tty/serial/samsung_tty.o: in function 
`s3c24xx_serial_shutdown':
>> samsung_tty.c:(.text+0x26e8): undefined reference to `dma_release_channel'
>> nios2-linux-ld: samsung_tty.c:(.text+0x2734): undefined reference to 
>> `dma_release_channel'
   nios2-linux-ld: samsung_tty.c:(.text+0x27a0): undefined reference to 
`dma_release_channel'
   nios2-linux-ld: drivers/tty/serial/samsung_tty.o: in function 
`s3c64xx_serial_startup':
>> samsung_tty.c:(.text+0x296c): undefined reference to `dma_request_chan'
>> nios2-linux-ld: samsung_tty.c:(.text+0x2984): undefined reference to 
>> `dma_get_slave_caps'
>> nios2-linux-ld: samsung_tty.c:(.text+0x29bc): undefined reference to 
>> `dma_request_chan'
   nios2-linux-ld: samsung_tty.c:(.text+0x29d4): undefined reference to 

Re: [GIT PULL] sound updates for 5.9

[Takashi Iwai]

On Sat, 08 Aug 2020 08:46:18 +0200,
Takashi Iwai wrote:
> 
> On Sat, 08 Aug 2020 02:23:24 +0200,
> John Stultz wrote:
> > 
> > On Thu, Aug 6, 2020 at 3:33 AM Takashi Iwai  wrote:
> > >
> > > Linus,
> > >
> > > please pull sound updates for v5.9 from:
> > >
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
> > > tags/sound-5.9-rc1
> > >
> > > The topmost commit is c7fabbc51352f50cc58242a6dc3b9c1a3599849b
> > >
> > > 
> > >
> > > sound updates for 5.9
> > >
> > > This became wide and scattered updates all over the sound tree as
> > > diffstat shows: lots of (still ongoing) refactoring works in ASoC,
> > > fixes and cleanups caught by static analysis, inclusive term
> > > conversions as well as lots of new drivers.  Below are highlights:
> > >
> > > ASoC core:
> > > * API cleanups and conversions to the unified mute_stream() call
> > > * Simplify I/O helper functions
> > > * Use helper macros to retrieve RTD from substreams
> > ...
> > > Kuninori Morimoto (90):
> > >   ASoC: soc-component: add soc_component_pin() and share code
> > >   ASoC: soc-component: move snd_soc_component_xxx_regmap() to 
> > > soc-component
> > >   ASoC: soc-component: move snd_soc_component_initialize() to 
> > > soc-component.c
> > >   ASoC: soc-component: add soc_component_err()
> > >   ASoC: soc-component: add snd_soc_pcm_component_prepare()
> > >   ASoC: soc-component: add snd_soc_pcm_component_hw_params()
> > >   ASoC: soc-component: add snd_soc_pcm_component_hw_free()
> > >   ASoC: soc-component: add snd_soc_pcm_component_trigger()
> > >   ASoC: soc-component: add snd_soc_component_init()
> > >   ASoC: soc-component: merge soc-io.c into soc-component.c
> > 
> > So oddly, today I bisected down the change "ASoC: soc-component: merge
> > soc-io.c into soc-component.c":
> >   
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=460b42d162e3cf634586999e6a84e74ca52e626d
> > 
> > as causing audio regressions on Dragonboard 845c running AOSP.
> > 
> > On boot I was seeing tons of:
> > q6routing remoteproc-adsp:glink-edge:apr:apr-service@8:routing: ASoC:
> > error at soc_component_read_no_lock on
> > remoteproc-adsp:glink-edge:apr:: -5
> > 
> > And when audio was supposed to play I'd see:
> > [  227.462986] qcom-q6afe aprsvc:apr-service:4:4: cmd = 0x100e5
> > returned error = 0x9
> > [  227.470720] qcom-q6afe aprsvc:apr-service:4:4: DSP returned error[9]
> > [  227.477168] qcom-q6afe aprsvc:apr-service:4:4: AFE enable for port
> > 0x4000 failed -22
> > [  227.485038] q6afe-dai
> > remoteproc-adsp:glink-edge:apr:apr-service@4:dais: fail to start AFE
> > port 2
> > [  227.494013] q6afe-dai
> > remoteproc-adsp:glink-edge:apr:apr-service@4:dais: ASoC: error at
> > snd_soc_pcm_dai_prepare on SLIMBUS_0_RX: -22
> > [  227.506034]  SLIM Playback: ASoC: DAI prepare error: -22
> > [  227.511415]  SLIM Playback: ASoC: backend prepare failed -22
> > 
> > Its strange, as the bisected patch is really just moving code around
> > and there's very little in the way of logic changes. After minimizing
> > the code movement and just focusing on what changed I forward ported a
> > revert to mainline and minimized it until things were working.
> > 
> > The resulting patch is a twoliner here:
> > https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/db845c-mainline-WIP&id=a3527193f39b1224d59bf1519fce3ef8c57d0f5e
> > 
> > I'm a bit baffled as to why this patch works. Logically we are
> > returning the same value. I suspect when we hit the error, all the
> > extra error print messages on the console slow things down and end up
> > causing some timing related initialization failure?
> 
> Does the patch below fix the bug?  If so, it's rather a bug in the
> commit cf6e26c71bfd ("ASoC: soc-component: merge
> snd_soc_component_read() and snd_soc_component_read32()").

That said, the commit cf6e26c71bfd dropped the capability of returning
an error code from snd_soc_component_read() completely, while many
code still expect an error gets returned.  The assumption mentioned in
the patch (the error can be ignored) looks too naive.

Morimoto-san, Mark, could you address it?  IMO, we may still need two
variants in the end again: the former snd_soc_component_read32() that
returns the value directly and snd_soc_component_read() that returns 0
or an error.  Only once after we deal with the error handling in each
caller side, we can unify the read functions.


Takashi

> 
> thanks,
> 
> Takashi
> 
> --- a/sound/soc/soc-component.c
> +++ b/sound/soc/soc-component.c
> @@ -406,7 +406,7 @@ static unsigned int soc_component_read_no_lock(
>   ret = -EIO;
>  
>   if (ret < 0)
> - soc_component_ret(component, ret);
> + return soc_component_ret(component, ret);
>  
>   return val;
>  }

Re: [PATCH V2] drm: Remove unnecessary drm_panel_attach and drm_panel_detach

[Sam Ravnborg]

Hi Joe.

On Sun, Aug 02, 2020 at 07:34:13PM +0200, Sam Ravnborg wrote:
> Hi Joe.
> 
> On Sun, Aug 02, 2020 at 09:43:59AM -0700, Joe Perches wrote:
> > These functions are now empty and no longer
> > useful so remove the functions and their uses.
> > 
> > Signed-off-by: Joe Perches 
> > ---
> > 
> > > > It's too tedious to break apart into multiple patches.
> > > > Done with coccinelle and typing.
> > > > 
> > > > Compiled allyesconfig x86-64 only.
> > 
> > V2: Removed 3 additional lines
> > 
> > drivers/gpu/drm/omapdrm/omap_drv.c:390:27: warning: unused variable ‘priv’ 
> > [-Wunused-variable]
> > drivers/gpu/drm/exynos/exynos_drm_dpi.c:45:21: warning: unused variable 
> > ‘ctx’ [-Wunused-variable]
> > drivers/gpu/drm/sun4i/sun4i_lvds.c:57:21: warning: unused variable ‘lvds’ 
> > [-Wunused-variable]
> 
> Thanks, better now.
> 
> I had to fix a few warnings and a build error to get it going on
> drm-misc-next. I will keep it locally just to let anyone speak up.
> I you do not see any mail from me until friday that it is applied please
> ping me.
Thanks, Now applied to drm-misc-next. Will show up in -next sometimes after the
current merge window closes.

Sam

[PATCH] net: Convert to use the fallthrough macro

[linmiaohe]

From: Miaohe Lin 

Convert the uses of fallthrough comments to fallthrough macro.

Signed-off-by: Miaohe Lin 
---
 net/socket.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/socket.c b/net/socket.c
index c61f036d24f5..f4d5998bdcba 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1325,7 +1325,7 @@ int sock_wake_async(struct socket_wq *wq, int how, int 
band)
case SOCK_WAKE_SPACE:
if (!test_and_clear_bit(SOCKWQ_ASYNC_NOSPACE, &wq->flags))
break;
-   /* fall through */
+   fallthrough;
case SOCK_WAKE_IO:
 call_kill:
kill_fasync(&wq->fasync_list, SIGIO, band);
@@ -3158,13 +3158,13 @@ static int ethtool_ioctl(struct net *net, struct 
compat_ifreq __user *ifr32)
if (rule_cnt > KMALLOC_MAX_SIZE / sizeof(u32))
return -ENOMEM;
buf_size += rule_cnt * sizeof(u32);
-   /* fall through */
+   fallthrough;
case ETHTOOL_GRXRINGS:
case ETHTOOL_GRXCLSRLCNT:
case ETHTOOL_GRXCLSRULE:
case ETHTOOL_SRXCLSRLINS:
convert_out = true;
-   /* fall through */
+   fallthrough;
case ETHTOOL_SRXCLSRLDEL:
buf_size += sizeof(struct ethtool_rxnfc);
convert_in = true;
-- 
2.19.1

I NEED YOUR URGENT RESPONSE PLEASE

[Ibrahim]

Hello Dear Friend,

My name is Mr.ibrahim idewu. I have decided to seek a confidential co-operation 
 with you in the execution of the deal described here-under for our both  
mutual benefit and I hope you will keep it a top secret because of the nature  
of the transaction, During the course of our bank year auditing, I discovered  
an unclaimed/abandoned fund, sum total of {US$19.3 Million United State  
Dollars} in the bank account that belongs to a Saudi Arabia businessman Who 
unfortunately lost his life and entire family in a Motor Accident.

Now our bank has been waiting for any of the relatives to come-up for the claim 
but nobody has done that. I personally has been unsuccessful in locating any of 
the relatives, now, I sincerely seek your consent to present you as the next of 
kin / Will Beneficiary to the deceased so that the proceeds of this account 
valued at {US$19.3 Million United State Dollars} can be paid to you, which we 
will share in these percentages ratio, 60% to me and 40% to you. All I request 
is your utmost sincere co-operation; trust and maximum confidentiality to 
achieve this project successfully. I have carefully mapped out the moralities 
for execution of this transaction under a legitimate arrangement to protect you 
from any breach of the law both in your country and here in Burkina Faso when 
the fund is being transferred to your bank account.

I will have to provide all the relevant document that will be requested to 
indicate that you are the rightful beneficiary of this legacy and our bank will 
release the fund to you without any further delay, upon your consideration and 
acceptance of this offer, please send me the following information as stated 
below so we can proceed and get this fund transferred to your designated bank 
account immediately.

-Your Full Name:
-Your Contact Address:
-Your direct Mobile telephone Number:
-Your Date of Birth:
-Your occupation:

I await your swift response and re-assurance.

Best regards,
Mr.ibrahim idewu.

[PATCH] cifs: Convert to use the fallthrough macro

[linmiaohe]

From: Miaohe Lin 

Convert the uses of fallthrough comments to fallthrough macro.

Signed-off-by: Hongxiang Lou 
Signed-off-by: Miaohe Lin 
---
 fs/cifs/smb2pdu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c
index 24c2ac360591..667d70aa335f 100644
--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -3913,7 +3913,7 @@ smb2_readv_callback(struct mid_q_entry *mid)
case MID_RESPONSE_MALFORMED:
credits.value = le16_to_cpu(shdr->CreditRequest);
credits.instance = server->reconnect_instance;
-   /* fall through */
+   fallthrough;
default:
rdata->result = -EIO;
}
@@ -4146,7 +4146,7 @@ smb2_writev_callback(struct mid_q_entry *mid)
case MID_RESPONSE_MALFORMED:
credits.value = le16_to_cpu(rsp->sync_hdr.CreditRequest);
credits.instance = server->reconnect_instance;
-   /* fall through */
+   fallthrough;
default:
wdata->result = -EIO;
break;
-- 
2.19.1

Re: KASAN: use-after-free Read in rc_dev_uevent

[Sean Young]

On Fri, Aug 07, 2020 at 09:55:40PM +0800, Hillf Danton wrote:
> 
> On Fri, 7 Aug 2020 10:15:04 +0100 Sean Young wrote:
> > On Fri, Aug 07, 2020 at 12:26:29AM -0700, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:7b4ea945 Revert "x86/mm/64: Do not sync vmalloc/ioremap 
> > > ma..
> > > git tree:   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=11a7813a90
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=72a84c46d0c668c
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=ceef16277388d6f24898
> > > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > > 
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > > 
> > > IMPORTANT: if you fix the issue, please add the following tag to the 
> > > commit:
> > > Reported-by: syzbot+ceef16277388d6f24...@syzkaller.appspotmail.com
> > > 
> > > ==
> > > BUG: KASAN: use-after-free in string_nocheck lib/vsprintf.c:611 [inline]
> > > BUG: KASAN: use-after-free in string+0x39c/0x3d0 lib/vsprintf.c:693
> > > Read of size 1 at addr 8881ca21cd20 by task systemd-udevd/5147
> > > 
> > > CPU: 1 PID: 5147 Comm: systemd-udevd Not tainted 5.8.0-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> > > Google 01/01/2011
> > > Call Trace:
> > >  __dump_stack lib/dump_stack.c:77 [inline]
> > >  dump_stack+0xf6/0x16e lib/dump_stack.c:118
> > >  print_address_description.constprop.0+0x1a/0x210 mm/kasan/report.c:383
> > >  __kasan_report mm/kasan/report.c:513 [inline]
> > >  kasan_report.cold+0x37/0x7c mm/kasan/report.c:530
> > >  string_nocheck lib/vsprintf.c:611 [inline]
> > >  string+0x39c/0x3d0 lib/vsprintf.c:693
> > >  vsnprintf+0x71b/0x14f0 lib/vsprintf.c:2617
> > >  add_uevent_var+0x14d/0x310 lib/kobject_uevent.c:664
> > >  rc_dev_uevent+0x54/0x140 drivers/media/rc/rc-main.c:1616
> > >  dev_uevent+0x30e/0x780 drivers/base/core.c:1916
> > >  uevent_show+0x1bb/0x360 drivers/base/core.c:1963
> > >  dev_attr_show+0x4b/0x90 drivers/base/core.c:1667
> > >  sysfs_kf_seq_show+0x1f8/0x400 fs/sysfs/file.c:60
> > >  seq_read+0x432/0x1070 fs/seq_file.c:208
> > >  kernfs_fop_read+0xe9/0x590 fs/kernfs/file.c:251
> > >  vfs_read+0x1df/0x520 fs/read_write.c:479
> > >  ksys_read+0x12d/0x250 fs/read_write.c:607
> > >  do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46
> > >  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7f6e6c02f910
> > > Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f 
> > > 1f 44 00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 
> > > ff ff 73 31 c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24
> > > RSP: 002b:7fff3cddeae8 EFLAGS: 0246 ORIG_RAX: 
> > > RAX: ffda RBX: 558492caaae0 RCX: 7f6e6c02f910
> > > RDX: 1000 RSI: 558492cc7530 RDI: 0007
> > > RBP: 7f6e6c2ea440 R08: 7f6e6c2ee298 R09: 1010
> > > R10: 558492caaae0 R11: 0246 R12: 1000
> > > R13: 0d68 R14: 558492cc7530 R15: 7f6e6c2e9900
> > 
> > This thread is reading the uevent sysfs file, which reads
> > rc_dev->map.name, and also rc_dev->device_name, but that is not causing
> > problems is this case.
> > 
> > > 
> > > Allocated by task 5:
> > >  save_stack+0x1b/0x40 mm/kasan/common.c:48
> > >  set_track mm/kasan/common.c:56 [inline]
> > >  __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494
> > >  slab_post_alloc_hook mm/slab.h:586 [inline]
> > >  slab_alloc_node mm/slub.c:2824 [inline]
> > >  slab_alloc mm/slub.c:2832 [inline]
> > >  __kmalloc_track_caller+0xec/0x280 mm/slub.c:4430
> > >  kstrdup+0x36/0x70 mm/util.c:60
> > >  ir_create_table drivers/media/rc/rc-main.c:217 [inline]
> > >  ir_setkeytable drivers/media/rc/rc-main.c:477 [inline]
> > >  rc_prepare_rx_device drivers/media/rc/rc-main.c:1786 [inline]
> > >  rc_register_device+0x464/0x1600 drivers/media/rc/rc-main.c:1914
> > >  igorplugusb_probe+0x7e6/0xc98 drivers/media/rc/igorplugusb.c:209
> > >  usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:374
> > >  really_probe+0x291/0xde0 drivers/base/dd.c:553
> > >  driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:738
> > >  __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:844
> > >  bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
> > >  __device_attach+0x228/0x4a0 drivers/base/dd.c:912
> > >  bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
> > >  device_add+0xb51/0x1c70 drivers/base/core.c:2930
> > >  usb_set_configuration+0xf05/0x18a0 drivers/usb/core/message.c:2032
> > >  usb_generic_driver_probe+0xba/0xf2 drivers/usb/core/generic.c:239
> > >  usb_probe_device+0xd9/0x250 drivers/usb/core/driver.c:272
> > >  really_probe+0x291/0xde0 drivers/base/dd.c:553
> > >  driver_probe_device+0x26b/0x3d0 dri

[PATCH] io_uring: Convert to use the fallthrough macro

[linmiaohe]

From: Miaohe Lin 

Convert the uses of fallthrough comments to fallthrough macro.

Signed-off-by: Hongxiang Lou 
Signed-off-by: Miaohe Lin 
---
 fs/io_uring.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/io_uring.c b/fs/io_uring.c
index 2a3af95be4ca..77e932c25312 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -2516,7 +2516,7 @@ static inline void io_rw_done(struct kiocb *kiocb, 
ssize_t ret)
 * IO with EINTR.
 */
ret = -EINTR;
-   /* fall through */
+   fallthrough;
default:
kiocb->ki_complete(kiocb, ret, 0);
}
-- 
2.19.1

drivers/tty/serial/mvebu-uart.c:605 mvebu_uart_putc() warn: this loop depends on readl() succeeding

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 05933aac7b11911955de307a329dc2a7a14b7bd0 ia64: remove now unused 
machvec indirections
date:   12 months ago
config: ia64-randconfig-m031-20200808 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0

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

New smatch warnings:
drivers/tty/serial/mvebu-uart.c:605 mvebu_uart_putc() warn: this loop depends 
on readl() succeeding

Old smatch warnings:
drivers/tty/serial/mvebu-uart.c:293 mvebu_uart_rx_chars() warn: this loop 
depends on readl() succeeding

vim +605 drivers/tty/serial/mvebu-uart.c

30530791a7a032 Wilson Ding   2016-02-16  595  
30530791a7a032 Wilson Ding   2016-02-16  596  #ifdef CONFIG_SERIAL_MVEBU_CONSOLE
30530791a7a032 Wilson Ding   2016-02-16  597  /* Early Console */
30530791a7a032 Wilson Ding   2016-02-16  598  static void 
mvebu_uart_putc(struct uart_port *port, int c)
30530791a7a032 Wilson Ding   2016-02-16  599  {
30530791a7a032 Wilson Ding   2016-02-16  600unsigned int st;
30530791a7a032 Wilson Ding   2016-02-16  601  
30530791a7a032 Wilson Ding   2016-02-16  602for (;;) {
30530791a7a032 Wilson Ding   2016-02-16  603st = 
readl(port->membase + UART_STAT);
30530791a7a032 Wilson Ding   2016-02-16  604if (!(st & 
STAT_TX_FIFO_FUL))
30530791a7a032 Wilson Ding   2016-02-16 @605break;
30530791a7a032 Wilson Ding   2016-02-16  606}
30530791a7a032 Wilson Ding   2016-02-16  607  
5218d76958644a Miquel Raynal 2017-10-13  608/* At early stage, DT is not 
parsed yet, only use UART0 */
5218d76958644a Miquel Raynal 2017-10-13  609writel(c, port->membase + 
UART_STD_TSH);
30530791a7a032 Wilson Ding   2016-02-16  610  
30530791a7a032 Wilson Ding   2016-02-16  611for (;;) {
30530791a7a032 Wilson Ding   2016-02-16  612st = 
readl(port->membase + UART_STAT);
30530791a7a032 Wilson Ding   2016-02-16  613if (st & 
STAT_TX_FIFO_EMP)
30530791a7a032 Wilson Ding   2016-02-16  614break;
30530791a7a032 Wilson Ding   2016-02-16  615}
30530791a7a032 Wilson Ding   2016-02-16  616  }
30530791a7a032 Wilson Ding   2016-02-16  617  

:: The code at line 605 was first introduced by commit
:: 30530791a7a032dc27dbbab56b8afabd5138074c serial: mvebu-uart: initial 
support for Armada-3700 serial port

:: TO: Wilson Ding 
:: CC: Greg Kroah-Hartman 

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


.config.gz
Description: application/gzip

Re: [PATCH v1 1/2] kunit: tool: fix running kunit_tool from outside kernel tree

[Brendan Higgins]

On Fri, Aug 7, 2020 at 10:45 PM David Gow  wrote:
>
> On Sat, Aug 8, 2020 at 9:17 AM Brendan Higgins
>  wrote:
> >
> > Currently kunit_tool does not work correctly when executed from a path
> > outside of the kernel tree, so make sure that the current working
> > directory is correct and the kunit_dir is properly initialized before
> > running.
> >
> > Signed-off-by: Brendan Higgins 
> > ---
> >  tools/testing/kunit/kunit.py | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
> > index 425ef40067e7..96344a11ff1f 100755
> > --- a/tools/testing/kunit/kunit.py
> > +++ b/tools/testing/kunit/kunit.py
> > @@ -237,9 +237,14 @@ def main(argv, linux=None):
> >
> > cli_args = parser.parse_args(argv)
> >
> > +   if get_kernel_root_path():
> > +   print('cd ' + get_kernel_root_path())
> Do we want to print this, or is it a leftover debug statement?

Whoops, I was supposed to delete that. That's embarrassing... ^_^;

> > +   os.chdir(get_kernel_root_path())
> > +
> > if cli_args.subcommand == 'run':
> > if not os.path.exists(cli_args.build_dir):
> > os.mkdir(cli_args.build_dir)
> > +   create_default_kunitconfig()
> Why are we adding this everywhere when it's already in config_tests,
> which should already be called in all of the places where a
> kunitconfig is required?

Ah yes, .kunitconfig needs to be created before config_tests() can be
called because the LinuxSourceTree constructor needs .kunitconfig to
exist.

> Is the goal to always copy the default kunitconfig when creating a new
> build_dir? While I can sort-of see why we might want to do that, if
> the build dir doesn't exist, most of the subcommands will fail anyway
> (maybe we should only create the build-dir for 'config' and 'run'?)

I just did it because we were getting a failure in a constructor so we
couldn't do much. Ideally we would check that the current state allows
for the command that the user intended to run, but I think that's
beyond the scope of this change.

So I guess the real question is: Is it okay for it to crash in the
constructor with a cryptic error message for now, or do we want to let
it fail with a slightly less cryptic message later?

> > if not linux:
> > linux = kunit_kernel.LinuxSourceTree()
> > @@ -257,6 +262,7 @@ def main(argv, linux=None):
> > if cli_args.build_dir:
> > if not os.path.exists(cli_args.build_dir):
> > os.mkdir(cli_args.build_dir)
> > +   create_default_kunitconfig()
> >
> > if not linux:
> > linux = kunit_kernel.LinuxSourceTree()
> > @@ -273,6 +279,7 @@ def main(argv, linux=None):
> > if cli_args.build_dir:
> > if not os.path.exists(cli_args.build_dir):
> > os.mkdir(cli_args.build_dir)
> > +   create_default_kunitconfig()
> >
> > if not linux:
> > linux = kunit_kernel.LinuxSourceTree()
> > @@ -291,6 +298,7 @@ def main(argv, linux=None):
> > if cli_args.build_dir:
> > if not os.path.exists(cli_args.build_dir):
> > os.mkdir(cli_args.build_dir)
> > +   create_default_kunitconfig()
> >
> > if not linux:
> > linux = kunit_kernel.LinuxSourceTree()
> >
> > base-commit: 30185b69a2d533c4ba6ca926b8390ce7de495e29
> > --
> > 2.28.0.236.gb10cc79966-goog
> >

[PATCH] badblocks: Convert to use the fallthrough macro

[linmiaohe]

From: Miaohe Lin 

Convert the uses of fallthrough comments to fallthrough macro.

Signed-off-by: Hongxiang Lou 
Signed-off-by: Miaohe Lin 
---
 block/badblocks.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/badblocks.c b/block/badblocks.c
index 2e5f5697db35..d39056630d9c 100644
--- a/block/badblocks.c
+++ b/block/badblocks.c
@@ -525,7 +525,7 @@ ssize_t badblocks_store(struct badblocks *bb, const char 
*page, size_t len,
case 3:
if (newline != '\n')
return -EINVAL;
-   /* fall through */
+   fallthrough;
case 2:
if (length <= 0)
return -EINVAL;
-- 
2.19.1

drivers/scsi/ufs/ufshcd.c:6495 ufshcd_host_reset_and_restore() error: double unlocked (orig line 6489)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 5cac1095cf289f7623f835a9212b9ec0ad3b85b3 scsi: ufs: Make 
ufshcd_wait_for_register() sleep instead of busy-waiting
date:   3 months ago
config: arm-randconfig-m031-20200808 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0

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

New smatch warnings:
drivers/scsi/ufs/ufshcd.c:6495 ufshcd_host_reset_and_restore() error: double 
unlocked '*hba->host->host_lock' (orig line 6489)

Old smatch warnings:
drivers/scsi/ufs/ufshcd.c:1430 ufshcd_suspend_clkscaling() error: double 
unlocked '*hba->host->host_lock' (orig line 1427)
drivers/scsi/ufs/ufshcd.c:1704 ufshcd_gate_work() error: double unlocked 
'*hba->host->host_lock' (orig line 1667)
drivers/scsi/ufs/ufshcd.c:2132 ufshcd_send_uic_cmd() error: double unlocked 
'*hba->host->host_lock' (orig line 2130)
drivers/scsi/ufs/ufshcd.c:2132 ufshcd_send_uic_cmd() error: double unlocked 
'*hba->host->host_lock' (orig line 2130)
drivers/scsi/ufs/ufshcd.c:2539 ufshcd_queuecommand() error: double unlocked 
'*hba->host->host_lock' (orig line 2501)
drivers/scsi/ufs/ufshcd.c:2661 ufshcd_wait_for_dev_cmd() error: double unlocked 
'*hba->host->host_lock' (orig line 2655)
drivers/scsi/ufs/ufshcd.c:2661 ufshcd_wait_for_dev_cmd() error: double unlocked 
'*hba->host->host_lock' (orig line 2655)
drivers/scsi/ufs/ufshcd.c:3772 ufshcd_uic_pwr_ctrl() error: double unlocked 
'*hba->host->host_lock' (orig line 3736)
drivers/scsi/ufs/ufshcd.c:3831 ufshcd_link_recovery() error: double unlocked 
'*hba->host->host_lock' (orig line 3820)
drivers/scsi/ufs/ufshcd.c:5450 ufshcd_quirk_dl_nac_errors() error: double 
unlocked '*hba->host->host_lock' (orig line 5430)
drivers/scsi/ufs/ufshcd.c:5468 ufshcd_quirk_dl_nac_errors() error: double 
unlocked '*hba->host->host_lock' (orig line 5450)
drivers/scsi/ufs/ufshcd.c:5528 ufshcd_err_handler() error: double unlocked 
'*hba->host->host_lock' (orig line 5504)
drivers/scsi/ufs/ufshcd.c:5531 ufshcd_err_handler() error: double unlocked 
'*hba->host->host_lock' (orig line 5528)
drivers/scsi/ufs/ufshcd.c:5531 ufshcd_err_handler() error: double unlocked 
'*hba->host->host_lock' (orig line 5528)
drivers/scsi/ufs/ufshcd.c:5570 ufshcd_err_handler() error: double unlocked 
'*hba->host->host_lock' (orig line 5504)
drivers/scsi/ufs/ufshcd.c:5598 ufshcd_err_handler() error: double unlocked 
'*hba->host->host_lock' (orig line 5570)
drivers/scsi/ufs/ufshcd.c:6587 ufshcd_eh_host_reset_handler() error: double 
unlocked '*hba->host->host_lock' (orig line 6574)
drivers/scsi/ufs/ufshcd.c:7910 ufshcd_hba_exit() error: double unlocked 
'*hba->host->host_lock' (orig line 7907)
drivers/scsi/ufs/ufshcd.c:8286 ufshcd_suspend() error: double unlocked 
'*hba->host->host_lock' (orig line 8193)
drivers/scsi/ufs/ufshcd.c:8297 ufshcd_suspend() error: double unlocked 
'*hba->host->host_lock' (orig line 8193)
drivers/scsi/ufs/ufshcd.c:8388 ufshcd_resume() error: double unlocked 
'*hba->host->host_lock' (orig line 8385)

vim +6495 drivers/scsi/ufs/ufshcd.c

7a3e97b0dc4bbac Santosh Yaraganavi 2012-02-29  6469  
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6470  /**
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6471   * 
ufshcd_host_reset_and_restore - reset and restore host controller
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6472   * @hba: per-adapter 
instance
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6473   *
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6474   * Note that host 
controller reset may issue DME_RESET to
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6475   * local and remote 
(device) Uni-Pro stack and the attributes
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6476   * are reset to default 
state.
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6477   *
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6478   * Returns zero on 
success, non-zero on failure
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6479   */
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6480  static int 
ufshcd_host_reset_and_restore(struct ufs_hba *hba)
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6481  {
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6482 int err;
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6483 unsigned long flags;
3441da7ddbdedf9 Sujit Reddy Thumma 2014-05-26  6484  
2df74b6985b51e7 Can Guo2019-11-25  6485 /*
2df74b6985b51e7 Can Guo2019-11-25  6486  * Stop the host 
controller and complete the requests
2df74b6985b51e7 Can Guo   

[PATCH] erofs: Convert to use the fallthrough macro

[linmiaohe]

From: Miaohe Lin 

Convert the uses of fallthrough comments to fallthrough macro.

Signed-off-by: Hongxiang Lou 
Signed-off-by: Miaohe Lin 
---
 fs/erofs/zmap.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/erofs/zmap.c b/fs/erofs/zmap.c
index 7d40d78ea864..ae325541884e 100644
--- a/fs/erofs/zmap.c
+++ b/fs/erofs/zmap.c
@@ -359,7 +359,7 @@ static int z_erofs_extent_lookback(struct 
z_erofs_maprecorder *m,
return z_erofs_extent_lookback(m, m->delta[0]);
case Z_EROFS_VLE_CLUSTER_TYPE_PLAIN:
map->m_flags &= ~EROFS_MAP_ZIPPED;
-   /* fallthrough */
+   fallthrough;
case Z_EROFS_VLE_CLUSTER_TYPE_HEAD:
map->m_la = (lcn << lclusterbits) | m->clusterofs;
break;
@@ -416,7 +416,7 @@ int z_erofs_map_blocks_iter(struct inode *inode,
case Z_EROFS_VLE_CLUSTER_TYPE_PLAIN:
if (endoff >= m.clusterofs)
map->m_flags &= ~EROFS_MAP_ZIPPED;
-   /* fallthrough */
+   fallthrough;
case Z_EROFS_VLE_CLUSTER_TYPE_HEAD:
if (endoff >= m.clusterofs) {
map->m_la = (m.lcn << lclusterbits) | m.clusterofs;
@@ -433,7 +433,7 @@ int z_erofs_map_blocks_iter(struct inode *inode,
end = (m.lcn << lclusterbits) | m.clusterofs;
map->m_flags |= EROFS_MAP_FULL_MAPPED;
m.delta[0] = 1;
-   /* fallthrough */
+   fallthrough;
case Z_EROFS_VLE_CLUSTER_TYPE_NONHEAD:
/* get the correspoinding first chunk */
err = z_erofs_extent_lookback(&m, m.delta[0]);
-- 
2.19.1

Re: KASAN: use-after-free Read in rc_dev_uevent

[Sean Young]

Hi Eze,

On Fri, Aug 07, 2020 at 08:45:12PM -0300, Ezequiel Garcia wrote:
> On Fri, 7 Aug 2020 at 06:15, Sean Young  wrote:
> >
> > On Fri, Aug 07, 2020 at 12:26:29AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:7b4ea945 Revert "x86/mm/64: Do not sync vmalloc/ioremap 
> > > ma..
> > > git tree:   
> > > https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=11a7813a90
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=72a84c46d0c668c
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=ceef16277388d6f24898
> > > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the 
> > > commit:
> > > Reported-by: syzbot+ceef16277388d6f24...@syzkaller.appspotmail.com
> > >
> > > ==
> > > BUG: KASAN: use-after-free in string_nocheck lib/vsprintf.c:611 [inline]
> > > BUG: KASAN: use-after-free in string+0x39c/0x3d0 lib/vsprintf.c:693
> > > Read of size 1 at addr 8881ca21cd20 by task systemd-udevd/5147
> > >
> > > CPU: 1 PID: 5147 Comm: systemd-udevd Not tainted 5.8.0-syzkaller #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> > > Google 01/01/2011
> > > Call Trace:
> > >  __dump_stack lib/dump_stack.c:77 [inline]
> > >  dump_stack+0xf6/0x16e lib/dump_stack.c:118
> > >  print_address_description.constprop.0+0x1a/0x210 mm/kasan/report.c:383
> > >  __kasan_report mm/kasan/report.c:513 [inline]
> > >  kasan_report.cold+0x37/0x7c mm/kasan/report.c:530
> > >  string_nocheck lib/vsprintf.c:611 [inline]
> > >  string+0x39c/0x3d0 lib/vsprintf.c:693
> > >  vsnprintf+0x71b/0x14f0 lib/vsprintf.c:2617
> > >  add_uevent_var+0x14d/0x310 lib/kobject_uevent.c:664
> > >  rc_dev_uevent+0x54/0x140 drivers/media/rc/rc-main.c:1616
> > >  dev_uevent+0x30e/0x780 drivers/base/core.c:1916
> > >  uevent_show+0x1bb/0x360 drivers/base/core.c:1963
> > >  dev_attr_show+0x4b/0x90 drivers/base/core.c:1667
> > >  sysfs_kf_seq_show+0x1f8/0x400 fs/sysfs/file.c:60
> > >  seq_read+0x432/0x1070 fs/seq_file.c:208
> > >  kernfs_fop_read+0xe9/0x590 fs/kernfs/file.c:251
> > >  vfs_read+0x1df/0x520 fs/read_write.c:479
> > >  ksys_read+0x12d/0x250 fs/read_write.c:607
> > >  do_syscall_64+0x2d/0x40 arch/x86/entry/common.c:46
> > >  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > RIP: 0033:0x7f6e6c02f910
> > > Code: b6 fe ff ff 48 8d 3d 0f be 08 00 48 83 ec 08 e8 06 db 01 00 66 0f 
> > > 1f 44 00 00 83 3d f9 2d 2c 00 00 75 10 b8 00 00 00 00 0f 05 <48> 3d 01 f0 
> > > ff ff 73 31 c3 48 83 ec 08 e8 de 9b 01 00 48 89 04 24
> > > RSP: 002b:7fff3cddeae8 EFLAGS: 0246 ORIG_RAX: 
> > > RAX: ffda RBX: 558492caaae0 RCX: 7f6e6c02f910
> > > RDX: 1000 RSI: 558492cc7530 RDI: 0007
> > > RBP: 7f6e6c2ea440 R08: 7f6e6c2ee298 R09: 1010
> > > R10: 558492caaae0 R11: 0246 R12: 1000
> > > R13: 0d68 R14: 558492cc7530 R15: 7f6e6c2e9900
> >
> > This thread is reading the uevent sysfs file, which reads
> > rc_dev->map.name, and also rc_dev->device_name, but that is not causing
> > problems is this case.
> >
> > >
> > > Allocated by task 5:
> > >  save_stack+0x1b/0x40 mm/kasan/common.c:48
> > >  set_track mm/kasan/common.c:56 [inline]
> > >  __kasan_kmalloc.constprop.0+0xc2/0xd0 mm/kasan/common.c:494
> > >  slab_post_alloc_hook mm/slab.h:586 [inline]
> > >  slab_alloc_node mm/slub.c:2824 [inline]
> > >  slab_alloc mm/slub.c:2832 [inline]
> > >  __kmalloc_track_caller+0xec/0x280 mm/slub.c:4430
> > >  kstrdup+0x36/0x70 mm/util.c:60
> > >  ir_create_table drivers/media/rc/rc-main.c:217 [inline]
> > >  ir_setkeytable drivers/media/rc/rc-main.c:477 [inline]
> > >  rc_prepare_rx_device drivers/media/rc/rc-main.c:1786 [inline]
> > >  rc_register_device+0x464/0x1600 drivers/media/rc/rc-main.c:1914
> > >  igorplugusb_probe+0x7e6/0xc98 drivers/media/rc/igorplugusb.c:209
> > >  usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:374
> > >  really_probe+0x291/0xde0 drivers/base/dd.c:553
> > >  driver_probe_device+0x26b/0x3d0 drivers/base/dd.c:738
> > >  __device_attach_driver+0x1d1/0x290 drivers/base/dd.c:844
> > >  bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:431
> > >  __device_attach+0x228/0x4a0 drivers/base/dd.c:912
> > >  bus_probe_device+0x1e4/0x290 drivers/base/bus.c:491
> > >  device_add+0xb51/0x1c70 drivers/base/core.c:2930
> > >  usb_set_configuration+0xf05/0x18a0 drivers/usb/core/message.c:2032
> > >  usb_generic_driver_probe+0xba/0xf2 drivers/usb/core/generic.c:239
> > >  usb_probe_device+0xd9/0x250 drivers/usb/core/driver.c:272
> > >  really_probe+0x291/0xde0 drivers/base/dd.c:553
> > >  driver_probe_device+0x26b/0x3d0 dri

[PATCH] vdpa/mlx5: Missing error code on allocation failure

[Dan Carpenter]

This should return -ENOMEM if the allocation fails.  Currently it
either returns success or an uninitialized value.

Fixes: 94abbccdf291 ("vdpa/mlx5: Add shared memory registration code")
Signed-off-by: Dan Carpenter 
---
 drivers/vdpa/mlx5/core/mr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/vdpa/mlx5/core/mr.c b/drivers/vdpa/mlx5/core/mr.c
index f5dec0274133..ef1c550f8266 100644
--- a/drivers/vdpa/mlx5/core/mr.c
+++ b/drivers/vdpa/mlx5/core/mr.c
@@ -319,8 +319,10 @@ static int add_direct_chain(struct mlx5_vdpa_dev *mvdev, 
u64 start, u64 size, u8
while (size) {
sz = (u32)min_t(u64, MAX_KLM_SIZE, size);
dmr = kzalloc(sizeof(*dmr), GFP_KERNEL);
-   if (!dmr)
+   if (!dmr) {
+   err = -ENOMEM;
goto err_alloc;
+   }
 
dmr->start = st;
dmr->end = st + sz;
-- 
2.27.0

[PATCH] vdpa/mlx5: Fix pointer math in mlx5_vdpa_get_config()

[Dan Carpenter]

There is a pointer math bug here so if "offset" is non-zero then this
will copy memory from beyond the end of the array.

Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Dan Carpenter 
---
 drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 3ec44a4f0e45..9d1637cf772e 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1758,7 +1758,7 @@ static void mlx5_vdpa_get_config(struct vdpa_device 
*vdev, unsigned int offset,
struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
 
if (offset + len < sizeof(struct virtio_net_config))
-   memcpy(buf, &ndev->config + offset, len);
+   memcpy(buf, (u8 *)&ndev->config + offset, len);
 }
 
 static void mlx5_vdpa_set_config(struct vdpa_device *vdev, unsigned int 
offset, const void *buf,
-- 
2.27.0

KASAN: null-ptr-deref Write in l2cap_chan_put

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:5631c5e0 Merge tag 'xfs-5.9-merge-7' of git://git.kernel.o..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15c2193490
kernel config:  https://syzkaller.appspot.com/x/.config?x=afba7c06f91e56eb
dashboard link: https://syzkaller.appspot.com/bug?extid=452e9465a3b2817fa4c2
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=131e96aa90

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

==
BUG: KASAN: null-ptr-deref in instrument_atomic_write 
include/linux/instrumented.h:71 [inline]
BUG: KASAN: null-ptr-deref in atomic_fetch_sub_release 
include/asm-generic/atomic-instrumented.h:220 [inline]
BUG: KASAN: null-ptr-deref in refcount_sub_and_test 
include/linux/refcount.h:266 [inline]
BUG: KASAN: null-ptr-deref in refcount_dec_and_test 
include/linux/refcount.h:294 [inline]
BUG: KASAN: null-ptr-deref in kref_put include/linux/kref.h:64 [inline]
BUG: KASAN: null-ptr-deref in l2cap_chan_put+0x28/0x230 
net/bluetooth/l2cap_core.c:502
Write of size 4 at addr 0018 by task kworker/0:1/7077

CPU: 0 PID: 7077 Comm: kworker/0:1 Not tainted 5.8.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: events l2cap_chan_timeout
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 __kasan_report mm/kasan/report.c:517 [inline]
 kasan_report.cold+0x5/0x37 mm/kasan/report.c:530
 check_memory_region_inline mm/kasan/generic.c:186 [inline]
 check_memory_region+0x13d/0x180 mm/kasan/generic.c:192
 instrument_atomic_write include/linux/instrumented.h:71 [inline]
 atomic_fetch_sub_release include/asm-generic/atomic-instrumented.h:220 [inline]
 refcount_sub_and_test include/linux/refcount.h:266 [inline]
 refcount_dec_and_test include/linux/refcount.h:294 [inline]
 kref_put include/linux/kref.h:64 [inline]
 l2cap_chan_put+0x28/0x230 net/bluetooth/l2cap_core.c:502
 l2cap_sock_kill+0xbd/0x180 net/bluetooth/l2cap_sock.c:1217
 l2cap_chan_timeout+0x1c1/0x450 net/bluetooth/l2cap_core.c:438
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
==
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 7077 Comm: kworker/0:1 Tainted: GB 5.8.0-syzkaller 
#0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: events l2cap_chan_timeout
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 panic+0x2e3/0x75c kernel/panic.c:231
 end_report+0x4d/0x53 mm/kasan/report.c:104
 __kasan_report mm/kasan/report.c:520 [inline]
 kasan_report.cold+0xd/0x37 mm/kasan/report.c:530
 check_memory_region_inline mm/kasan/generic.c:186 [inline]
 check_memory_region+0x13d/0x180 mm/kasan/generic.c:192
 instrument_atomic_write include/linux/instrumented.h:71 [inline]
 atomic_fetch_sub_release include/asm-generic/atomic-instrumented.h:220 [inline]
 refcount_sub_and_test include/linux/refcount.h:266 [inline]
 refcount_dec_and_test include/linux/refcount.h:294 [inline]
 kref_put include/linux/kref.h:64 [inline]
 l2cap_chan_put+0x28/0x230 net/bluetooth/l2cap_core.c:502
 l2cap_sock_kill+0xbd/0x180 net/bluetooth/l2cap_sock.c:1217
 l2cap_chan_timeout+0x1c1/0x450 net/bluetooth/l2cap_core.c:438
 process_one_work+0x94c/0x1670 kernel/workqueue.c:2269
 worker_thread+0x64c/0x1120 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches

[PATCH] mm: slub: re-initialize randomized freelist sequence in calculate_sizes

[kpark3469]

From: Sahara 

Slab cache flags are exported to sysfs and are allowed to get modified
from userspace. Some of those may call calculate_sizes function because
the changed flag can take an effect on slab object size and layout,
which means kmem_cache may have different order and objects.
The freelist pointer corruption occurs if some slab flags are modified
while CONFIG_SLAB_FREELIST_RANDOM is turned on.

 $ echo 0 > /sys/kernel/slab/zs_handle/store_user
 $ echo 0 > /sys/kernel/slab/zspage/store_user
 $ mkswap /dev/block/zram0
 $ swapon /dev/block/zram0 -p 32758

 =
 BUG zs_handle (Not tainted): Freepointer corrupt
 -

 Disabling lock debugging due to kernel taint
 INFO: Slab 0xffbf29603600 objects=102 used=102 fp=0x 
flags=0x0200
 INFO: Object 0xffca580d8d78 @offset=3448 fp=0xffca580d8ed0

 Redzone f3cddd6c: bb bb bb bb bb bb bb bb  

 Object 82d5d74e: 6b 6b 6b 6b 6b 6b 6b a5  
kkk.
 Redzone 8fd80359: bb bb bb bb bb bb bb bb  

 Padding c7f56047: 5a 5a 5a 5a 5a 5a 5a 5a  


In this example, an Android device tries to use zram as a swap and to
turn off store_user in order to reduce the slub object size.
When calculate_sizes is called in kmem_cache_open, size, order and
objects for zs_handle is:
 size:360, order:0, objects:22
However, if the SLAB_STORE_USER bit is cleared in store_user_store:
 size: 56, order:1, objects:73

All the size, order, and objects is changed by calculate_sizes(), but
the size of the random_seq array is still old value(22). As a result,
out-of-bound array access can occur at shuffle_freelist() when slab
allocation is requested.

This patch fixes the problem by re-allocating the random_seq array
with re-calculated correct objects value.

Fixes: 210e7a43fa905 ("mm: SLUB freelist randomization")
Reported-by: Ari-Pekka Verta 
Reported-by: Timo Simola 
Signed-off-by: Sahara 
---
 mm/slub.c | 23 ---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index f226d66408ee..be1e4d6682b8 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3704,7 +3704,22 @@ static int calculate_sizes(struct kmem_cache *s, int 
forced_order)
if (oo_objects(s->oo) > oo_objects(s->max))
s->max = s->oo;
 
-   return !!oo_objects(s->oo);
+   if (!oo_objects(s->oo))
+   return 0;
+
+   /*
+* Initialize the pre-computed randomized freelist if slab is up.
+* If the randomized freelist random_seq is already initialized,
+* free and re-initialize it with re-calculated value.
+*/
+   if (slab_state >= UP) {
+   if (s->random_seq)
+   cache_random_seq_destroy(s);
+   if (init_cache_random_seq(s))
+   return 0;
+   }
+
+   return 1;
 }
 
 static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
@@ -3748,12 +3763,6 @@ static int kmem_cache_open(struct kmem_cache *s, 
slab_flags_t flags)
s->remote_node_defrag_ratio = 1000;
 #endif
 
-   /* Initialize the pre-computed randomized freelist if slab is up */
-   if (slab_state >= UP) {
-   if (init_cache_random_seq(s))
-   goto error;
-   }
-
if (!init_kmem_cache_nodes(s))
goto error;
 
-- 
2.17.1

Re: [PATCH v11 2/5] x86: kdump: move reserve_crashkernel_low() into crash_core.c

[Dave Young]

On 08/01/20 at 09:08pm, Chen Zhou wrote:
> In preparation for supporting reserve_crashkernel_low in arm64 as
> x86_64 does, move reserve_crashkernel_low() into kernel/crash_core.c.
> 
> BTW, move x86_64 CRASH_ALIGN to 2M suggested by Dave. CONFIG_PHYSICAL_ALIGN
> can be selected from 2M to 16M, move to the same as arm64.
> 
> Signed-off-by: Chen Zhou 
> ---
>  arch/x86/include/asm/kexec.h | 24 ++
>  arch/x86/kernel/setup.c  | 86 +++-
>  include/linux/crash_core.h   |  3 ++
>  include/linux/kexec.h|  2 -
>  kernel/crash_core.c  | 74 +++
>  kernel/kexec_core.c  | 17 ---
>  6 files changed, 107 insertions(+), 99 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kexec.h b/arch/x86/include/asm/kexec.h
> index 6802c59e8252..f8f9d952e09f 100644
> --- a/arch/x86/include/asm/kexec.h
> +++ b/arch/x86/include/asm/kexec.h
> @@ -18,6 +18,30 @@
>  
>  # define KEXEC_CONTROL_CODE_MAX_SIZE 2048
>  
> +/* 2M alignment for crash kernel regions */
> +#define CRASH_ALIGN  SZ_2M
> +
> +/*
> + * Keep the crash kernel below this limit.
> + *
> + * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
> + * due to mapping restrictions.
> + *
> + * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
> + * the upper limit of system RAM in 4-level paging mode. Since the kdump
> + * jump could be from 5-level paging to 4-level paging, the jump will fail if
> + * the kernel is put above 64 TB, and during the 1st kernel bootup there's
> + * no good way to detect the paging mode of the target kernel which will be
> + * loaded for dumping.
> + */
> +#ifdef CONFIG_X86_32
> +# define CRASH_ADDR_LOW_MAX  SZ_512M
> +# define CRASH_ADDR_HIGH_MAX SZ_512M
> +#else
> +# define CRASH_ADDR_LOW_MAX  SZ_4G
> +# define CRASH_ADDR_HIGH_MAX SZ_64T
> +#endif
> +
>  #ifndef __ASSEMBLY__
>  
>  #include 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index a3767e74c758..46763c1e5d9f 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -401,83 +401,6 @@ static void __init 
> memblock_x86_reserve_range_setup_data(void)
>  
>  #ifdef CONFIG_KEXEC_CORE
>  
> -/* 16M alignment for crash kernel regions */
> -#define CRASH_ALIGN  SZ_16M
> -
> -/*
> - * Keep the crash kernel below this limit.
> - *
> - * Earlier 32-bits kernels would limit the kernel to the low 512 MB range
> - * due to mapping restrictions.
> - *
> - * 64-bit kdump kernels need to be restricted to be under 64 TB, which is
> - * the upper limit of system RAM in 4-level paging mode. Since the kdump
> - * jump could be from 5-level paging to 4-level paging, the jump will fail if
> - * the kernel is put above 64 TB, and during the 1st kernel bootup there's
> - * no good way to detect the paging mode of the target kernel which will be
> - * loaded for dumping.
> - */
> -#ifdef CONFIG_X86_32
> -# define CRASH_ADDR_LOW_MAX  SZ_512M
> -# define CRASH_ADDR_HIGH_MAX SZ_512M
> -#else
> -# define CRASH_ADDR_LOW_MAX  SZ_4G
> -# define CRASH_ADDR_HIGH_MAX SZ_64T
> -#endif
> -
> -static int __init reserve_crashkernel_low(void)
> -{
> -#ifdef CONFIG_X86_64
> - unsigned long long base, low_base = 0, low_size = 0;
> - unsigned long total_low_mem;
> - int ret;
> -
> - total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
> -
> - /* crashkernel=Y,low */
> - ret = parse_crashkernel_low(boot_command_line, total_low_mem, 
> &low_size, &base);
> - if (ret) {
> - /*
> -  * two parts from kernel/dma/swiotlb.c:
> -  * -swiotlb size: user-specified with swiotlb= or default.
> -  *
> -  * -swiotlb overflow buffer: now hardcoded to 32k. We round it
> -  * to 8M for other buffers that may need to stay low too. Also
> -  * make sure we allocate enough extra low memory so that we
> -  * don't run out of DMA buffers for 32-bit devices.
> -  */
> - low_size = max(swiotlb_size_or_default() + (8UL << 20), 256UL 
> << 20);
> - } else {
> - /* passed with crashkernel=0,low ? */
> - if (!low_size)
> - return 0;
> - }
> -
> - low_base = memblock_find_in_range(0, 1ULL << 32, low_size, CRASH_ALIGN);
> - if (!low_base) {
> - pr_err("Cannot reserve %ldMB crashkernel low memory, please try 
> smaller size.\n",
> -(unsigned long)(low_size >> 20));
> - return -ENOMEM;
> - }
> -
> - ret = memblock_reserve(low_base, low_size);
> - if (ret) {
> - pr_err("%s: Error reserving crashkernel low memblock.\n", 
> __func__);
> - return ret;
> - }
> -
> - pr_info("Reserving %ldMB of low memory at %ldMB for crashkernel (System 
> low RAM: %ldMB)\n",
> - (unsigned long)(low_size >> 20),
> - (unsigned long)(low_base >> 20),
> - (unsigned l

Re: [PATCH v11 5/5] kdump: update Documentation about crashkernel

[Dave Young]

On 08/01/20 at 09:08pm, Chen Zhou wrote:
> Now the behavior of crashkernel=X has been changed, which tries low
> allocation in ZONE_DMA, and fall back to high allocation if it fails.
> 
> If requized size X is too large and leads to very little free memory
> in ZONE_DMA after low allocation, the system may not work well.
> So add a threshold and go for high allocation directly if the required
> size is too large. The threshold is set as the half of low memory.
> 
> If crash_base is outside ZONE_DMA, try to allocate at least 256M in
> ZONE_DMA automatically. "crashkernel=Y,low" can be used to allocate
> specified size low memory. For non-RPi4 platforms, change ZONE_DMA
> memtioned above to ZONE_DMA32.
> 
> So update the Documentation.
> 
> Signed-off-by: Chen Zhou 
> ---
>  Documentation/admin-guide/kdump/kdump.rst | 21 ---
>  .../admin-guide/kernel-parameters.txt | 11 --
>  2 files changed, 27 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/admin-guide/kdump/kdump.rst 
> b/Documentation/admin-guide/kdump/kdump.rst
> index 2da65fef2a1c..4b58f97351d5 100644
> --- a/Documentation/admin-guide/kdump/kdump.rst
> +++ b/Documentation/admin-guide/kdump/kdump.rst
> @@ -299,7 +299,15 @@ Boot into System Kernel
> "crashkernel=64M@16M" tells the system kernel to reserve 64 MB of memory
> starting at physical address 0x0100 (16MB) for the dump-capture 
> kernel.
>  
> -   On x86 and x86_64, use "crashkernel=64M@16M".
> +   On x86 use "crashkernel=64M@16M".
> +
> +   On x86_64, use "crashkernel=X" to select a region under 4G first, and
> +   fall back to reserve region above 4G.
> +   We can also use "crashkernel=X,high" to select a region above 4G, which
> +   also tries to allocate at least 256M below 4G automatically and
> +   "crashkernel=Y,low" can be used to allocate specified size low memory.
> +   Use "crashkernel=Y@X" if you really have to reserve memory from specified
> +   start address X.
>  
> On ppc64, use "crashkernel=128M@32M".
>  
> @@ -316,8 +324,15 @@ Boot into System Kernel
> kernel will automatically locate the crash kernel image within the
> first 512MB of RAM if X is not given.
>  
> -   On arm64, use "crashkernel=Y[@X]".  Note that the start address of
> -   the kernel, X if explicitly specified, must be aligned to 2MiB (0x20).
> +   On arm64, use "crashkernel=X" to try low allocation in ZONE_DMA, and
> +   fall back to high allocation if it fails. And go for high allocation
> +   directly if the required size is too large. If crash_base is outside
> +   ZONE_DMA, try to allocate at least 256M in ZONE_DMA automatically.
> +   "crashkernel=Y,low" can be used to allocate specified size low memory.
> +   For non-RPi4 platforms, change ZONE_DMA memtioned above to ZONE_DMA32.
> +   Use "crashkernel=Y@X" if you really have to reserve memory from
> +   specified start address X. Note that the start address of the kernel,
> +   X if explicitly specified, must be aligned to 2MiB (0x20).
>  
>  Load the Dump-capture Kernel
>  
> diff --git a/Documentation/admin-guide/kernel-parameters.txt 
> b/Documentation/admin-guide/kernel-parameters.txt
> index fb95fad81c79..d1b6016850d6 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -722,6 +722,10 @@
>   [KNL, x86_64] select a region under 4G first, and
>   fall back to reserve region above 4G when '@offset'
>   hasn't been specified.
> + [KNL, arm64] Try low allocation in ZONE_DMA, fall back
> + to high allocation if it fails when '@offset' hasn't 
> been
> + specified. For non-RPi4 platforms, change ZONE_DMA to
> + ZONE_DMA32.
>   See Documentation/admin-guide/kdump/kdump.rst for 
> further details.
>  
>   crashkernel=range1:size1[,range2:size2,...][@offset]
> @@ -746,13 +750,16 @@
>   requires at least 64M+32K low memory, also enough extra
>   low memory is needed to make sure DMA buffers for 32-bit
>   devices won't run out. Kernel would try to allocate at
> - at least 256M below 4G automatically.
> + least 256M below 4G automatically.
>   This one let user to specify own low range under 4G
>   for second kernel instead.
>   0: to disable low allocation.
>   It will be ignored when crashkernel=X,high is not used
>   or memory reserved is below 4G.
> -
> + [KNL, arm64] range under 4G.
> + This one let user to specify a low range in ZONE_DMA for
> + crash dump kernel. For non-RPi4 platforms, change 
> ZONE_DMA
> + to ZONE_DMA32.
>   cryptomgr.

drivers/md/dm-mpath.c:432 choose_pgpath() error: double unlocked 'm->lock' (orig line 402)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 69cea0d45a618ad4ae74f36386ef1af5128b2b19 dm mpath: changes from initial 
m->flags locking audit
date:   4 weeks ago
config: arm-randconfig-m031-20200808 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0

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

New smatch warnings:
drivers/md/dm-mpath.c:432 choose_pgpath() error: double unlocked 'm->lock' 
(orig line 402)

Old smatch warnings:
drivers/md/dm-mpath.c:443 choose_pgpath() error: double unlocked 'm->lock' 
(orig line 389)
drivers/md/dm-mpath.c:593 __map_bio() error: double unlocked 'm->lock' (orig 
line 589)
drivers/md/dm-mpath.c:1574 pg_init_done() error: double unlocked 'm->lock' 
(orig line 1527)

vim +432 drivers/md/dm-mpath.c

   378  
   379  static struct pgpath *choose_pgpath(struct multipath *m, size_t 
nr_bytes)
   380  {
   381  unsigned long flags;
   382  struct priority_group *pg;
   383  struct pgpath *pgpath;
   384  unsigned bypassed = 1;
   385  
   386  if (!atomic_read(&m->nr_valid_paths)) {
   387  spin_lock_irqsave(&m->lock, flags);
   388  clear_bit(MPATHF_QUEUE_IO, &m->flags);
   389  spin_unlock_irqrestore(&m->lock, flags);
   390  goto failed;
   391  }
   392  
   393  /* Were we instructed to switch PG? */
   394  if (READ_ONCE(m->next_pg)) {
   395  spin_lock_irqsave(&m->lock, flags);
   396  pg = m->next_pg;
   397  if (!pg) {
   398  spin_unlock_irqrestore(&m->lock, flags);
   399  goto check_current_pg;
   400  }
   401  m->next_pg = NULL;
 > 402  spin_unlock_irqrestore(&m->lock, flags);
   403  pgpath = choose_path_in_pg(m, pg, nr_bytes);
   404  if (!IS_ERR_OR_NULL(pgpath))
   405  return pgpath;
   406  }
   407  
   408  /* Don't change PG until it has no remaining paths */
   409  check_current_pg:
   410  pg = READ_ONCE(m->current_pg);
   411  if (pg) {
   412  pgpath = choose_path_in_pg(m, pg, nr_bytes);
   413  if (!IS_ERR_OR_NULL(pgpath))
   414  return pgpath;
   415  }
   416  
   417  /*
   418   * Loop through priority groups until we find a valid path.
   419   * First time we skip PGs marked 'bypassed'.
   420   * Second time we only try the ones we skipped, but set
   421   * pg_init_delay_retry so we do not hammer controllers.
   422   */
   423  do {
   424  list_for_each_entry(pg, &m->priority_groups, list) {
   425  if (pg->bypassed == !!bypassed)
   426  continue;
   427  pgpath = choose_path_in_pg(m, pg, nr_bytes);
   428  if (!IS_ERR_OR_NULL(pgpath)) {
   429  if (!bypassed) {
   430  spin_lock_irqsave(&m->lock, 
flags);
   431  
set_bit(MPATHF_PG_INIT_DELAY_RETRY, &m->flags);
 > 432  
 > spin_unlock_irqrestore(&m->lock, flags);
   433  }
   434  return pgpath;
   435  }
   436  }
   437  } while (bypassed--);
   438  
   439  failed:
   440  spin_lock_irqsave(&m->lock, flags);
   441  m->current_pgpath = NULL;
   442  m->current_pg = NULL;
   443  spin_unlock_irqrestore(&m->lock, flags);
   444  
   445  return NULL;
   446  }
   447  

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


.config.gz
Description: application/gzip

Re: [RFC] libperf: Add support for user space counter access

[Jiri Olsa]

On Fri, Aug 07, 2020 at 05:05:17PM -0600, Rob Herring wrote:
> x86 and arm64 can both support direct access of event counters in
> userspace. The access sequence is less than trivial and currently exists
> in perf test code (tools/perf/arch/x86/tests/rdpmc.c) with copies in
> projects such as PAPI and libpfm4.
> 
> Patches to add arm64 userspace support are pending[1].
> 
> For this RFC, looking for a yes, seems like a good idea, or no, go away we
> don't want this in libperf.

hi,
looks great!

I wanted to add this for very long time.. so yes, we want this ;-)

> 
> TODO:
> - Handle userspace access not enabled.
> - Handle pmc_width and cap_user_time_short in read loop.
> - Move existing rdpmc test to libperf based test?
> - Abstract out rdtsc/rdpmc (currently only builds on x86 and need to add
>   Arm versions)

all of them seem good, also please add test for perf_mmap__read_self
itself and update the doc/man

SNIP

> +{
> + struct perf_event_mmap_page *pc = map->base;
> + u32 seq, idx, time_mult = 0, time_shift = 0;
> + u64 count, cyc = 0, time_offset = 0, enabled, running, delta;
> +
> + /*
> +  * Check if event was unmapped due to a POLLHUP/POLLERR.
> +  */
> + if (!refcount_read(&map->refcnt))
> + return ~0;
> +
> + do {
> + seq = pc->lock;
> + barrier();
> +
> + enabled = pc->time_enabled;
> + running = pc->time_running;
> +
> + if (enabled != running) {

should you check pc->cap_usr_time in here?

> + cyc = rdtsc();
> + time_mult = pc->time_mult;
> + time_shift = pc->time_shift;
> + time_offset = pc->time_offset;
> + }
> +
> + idx = pc->index;
> + count = pc->offset;
> + if (idx)

and pc->cap_user_rdpmc in here?

ok, it's probably in the TODO

thanks,
jirka

Re: [PATCH v3 0/2] iio: temperature: mlx90632: Add extended calibration calculations

[Andy Shevchenko]

On Sat, Aug 8, 2020 at 2:22 AM Crt Mori  wrote:
>
> Since the second patch is dependent on the first and was still not
> merged, I have decided to send them together. First patch just makes
> second one more readable as it splits out the repeated calculation and
> that enables the second patch to tweak the variable to the new
> condition.

Neither here nor in the individual patches I haven't found a changelog.

> Crt Mori (2):
>   iio:temperature:mlx90632: Reduce number of equal calulcations
>   iio:temperature:mlx90632: Adding extended calibration option
>
>  drivers/iio/temperature/mlx90632.c | 233 +++--
>  1 file changed, 223 insertions(+), 10 deletions(-)
>
> --
> 2.25.1
>


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3] hwmon/pmbus: use simple i2c probe function

[Stephen Kitt]

On Fri, 7 Aug 2020 21:07:07 +0200, Stephen Kitt  wrote:

> On Fri, 7 Aug 2020 10:32:31 -0700, Guenter Roeck  wrote:
> > On Fri, Aug 07, 2020 at 06:28:01PM +0200, Stephen Kitt wrote:  
> > >  
> > > -static int ltc2978_probe(struct i2c_client *client,
> > > -  const struct i2c_device_id *id)
> > > +static int ltc2978_probe(struct i2c_client *client)
> > >  {
> > >   int i, chip_id;
> > >   struct ltc2978_data *data;
> > > @@ -670,10 +669,10 @@ static int ltc2978_probe(struct i2c_client
> > > *client, return chip_id;
> > >  
> > >   data->id = chip_id;
> > > - if (data->id != id->driver_data)
> > > + if (strcmp(client->name, ltc2978_id[data->id].name) != 0)
> > 
> > I was about to apply this patch, but this is problematic: It assumes that
> > __stringify(id) == ltc2978_id[id].name and that ltc2978_id[id].driver_data
> > == id. While that is curently the case (as far as I can see), it is still
> > unsafe. I think it would be much safer to use i2c_match_id() here.  
> 
> I’m not following the __stringify assumption
[...]

I get it, the code assumes there’s a bijection between the set of names and
the set of driver_data values. So effectively we can’t log the detected name
based on the chip_id...

Regards,

Stephen


pgpm_wvfSlRNV.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 1/2] iio:temperature:mlx90632: Reduce number of equal calulcations

[Andy Shevchenko]

On Sat, Aug 8, 2020 at 2:22 AM Crt Mori  wrote:
>
> TAdut4 was calculated each iteration although it did not change. In light
> of near future additions of the Extended range DSP calculations, this
> function refactoring will help reduce unrelated changes in that series as
> well as reduce the number of new functions needed.

I see you provided a helper for this calculus, but I think we may
reduce a lot of churn if you do the following:
- introduce helper and convert one/current user (no functional change!)
- do what you did in this patch, but it will move less LOCs
- do what you have done in the next one using the helper

-- 
With Best Regards,
Andy Shevchenko

drivers/pci/endpoint/functions/pci-epf-test.c:288:24: sparse: sparse: incorrect type in argument 1 (different address spaces)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to 
define address spaces
date:   7 weeks ago
config: parisc-randconfig-s032-20200808 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=parisc 

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


sparse warnings: (new ones prefixed by >>)

>> drivers/pci/endpoint/functions/pci-epf-test.c:288:24: sparse: sparse: 
>> incorrect type in argument 1 (different address spaces) @@ expected void 
>> *dest @@ got void [noderef] __iomem *[assigned] dst_addr @@
   drivers/pci/endpoint/functions/pci-epf-test.c:288:24: sparse: expected 
void *dest
   drivers/pci/endpoint/functions/pci-epf-test.c:288:24: sparse: got void 
[noderef] __iomem *[assigned] dst_addr
   drivers/pci/endpoint/functions/pci-epf-test.c:288:34: sparse: sparse: 
incorrect type in argument 2 (different address spaces) @@ expected void 
const *src @@ got void [noderef] __iomem *[assigned] src_addr @@
   drivers/pci/endpoint/functions/pci-epf-test.c:288:34: sparse: expected 
void const *src
   drivers/pci/endpoint/functions/pci-epf-test.c:288:34: sparse: got void 
[noderef] __iomem *[assigned] src_addr

vim +288 drivers/pci/endpoint/functions/pci-epf-test.c

5893c2e5353bb9 Kishon Vijay Abraham I 2020-03-16  226  
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  227  static int 
pci_epf_test_copy(struct pci_epf_test *epf_test)
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  228  {
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  229   int ret;
5ebf3fc59bd20d Kishon Vijay Abraham I 2020-03-16  230   bool use_dma;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  231   void __iomem *src_addr;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  232   void __iomem *dst_addr;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  233   phys_addr_t 
src_phys_addr;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  234   phys_addr_t 
dst_phys_addr;
5893c2e5353bb9 Kishon Vijay Abraham I 2020-03-16  235   struct timespec64 
start, end;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  236   struct pci_epf *epf = 
epf_test->epf;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  237   struct device *dev = 
&epf->dev;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  238   struct pci_epc *epc = 
epf->epc;
3235b994950d84 Kishon Vijay Abraham I 2017-08-18  239   enum pci_barno 
test_reg_bar = epf_test->test_reg_bar;
3235b994950d84 Kishon Vijay Abraham I 2017-08-18  240   struct pci_epf_test_reg 
*reg = epf_test->reg[test_reg_bar];
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  241  
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  242   src_addr = 
pci_epc_mem_alloc_addr(epc, &src_phys_addr, reg->size);
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  243   if (!src_addr) {
798c0441bec8c4 Gustavo Pimentel   2018-05-14  244   dev_err(dev, 
"Failed to allocate source address\n");
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  245   reg->status = 
STATUS_SRC_ADDR_INVALID;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  246   ret = -ENOMEM;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  247   goto err;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  248   }
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  249  
4494738de0d9dc Cyrille Pitchen2018-01-30  250   ret = 
pci_epc_map_addr(epc, epf->func_no, src_phys_addr, reg->src_addr,
4494738de0d9dc Cyrille Pitchen2018-01-30  251  
reg->size);
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  252   if (ret) {
798c0441bec8c4 Gustavo Pimentel   2018-05-14  253   dev_err(dev, 
"Failed to map source address\n");
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  254   reg->status = 
STATUS_SRC_ADDR_INVALID;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  255   goto 
err_src_addr;
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  256   }
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  257  
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  258   dst_addr = 
pci_epc_mem_alloc_addr(epc, &dst_phys_addr, reg->size);
349e7a85b25fa6 Kishon Vijay Abraham I 2017-03-27  259   if (!dst_addr) {
798c0441bec8c4 Gustavo Pimentel   2018-05-14  260   dev_e

Re: [PATCH v3 2/2] iio:temperature:mlx90632: Adding extended calibration option

[Andy Shevchenko]

On Sat, Aug 8, 2020 at 2:24 AM Crt Mori  wrote:
>
> For some time the market wants medical grade accuracy in medical range,
> while still retaining the declared accuracy outside of the medical range
> within the same sensor. That is why we created extended calibration
> which is automatically switched to when object temperature is too high.
>
> This patch also introduces the object_ambient_temperature variable which
> is needed for more accurate calculation of the object infra-red
> footprint as sensor's ambient temperature might be totally different
> than what the ambient temperature is at object and that is why we can
> have some more errors which can be eliminated. Currently this temperature
> is fixed at 25, but the interface to adjust it by user (with external
> sensor or just IR measurement of the other object which acts as ambient),
> will be introduced in another commit.

Thank you for an update!
My comments below.

...

>  struct mlx90632_data {
> struct i2c_client *client;
> struct mutex lock; /* Multiple reads for single measurement */
> struct regmap *regmap;
> u16 emissivity;
> +   u8 mtyp; /* measurement type - to enable extended range calculations 
> */
> +   u32 object_ambient_temperature;
>  };

As a separate patch to have a kernel doc for this, there are plenty of
examples in the kernel, but I will show below an example

/**
 * struct foo - private data for the MLX90632 device
 * @client: I2C client of the device
 * @bar: ...
 ...
 */
struct foo {
  struct i2c_client *client;
  ... bar;
  ...
};

...

> +   if ((type != MLX90632_MTYP_MEDICAL) && (type != 
> MLX90632_MTYP_EXTENDED))
> +   return -EINVAL;

So, just to point out what the difference between & and &&  (even for
boolean): the former one forces both sides of operand to be executed,
while && checks for only first in case of false.

...

> +static int mlx90632_read_ambient_raw_extended(struct regmap *regmap,
> + s16 *ambient_new_raw, s16 
> *ambient_old_raw)
> +{
> +   unsigned int read_tmp;
> +   int ret;
> +
> +   ret = regmap_read(regmap, MLX90632_RAM_3(17), &read_tmp);
> +   if (ret < 0)
> +   return ret;
> +   *ambient_new_raw = (s16)read_tmp;

Again the same question, do you need all these castings?

> +   ret = regmap_read(regmap, MLX90632_RAM_3(18), &read_tmp);

These 17, 18 and 19 should be defined with descriptive names.

> +   if (ret < 0)
> +   return ret;
> +   *ambient_old_raw = (s16)read_tmp;
> +
> +   return 0;
> +}

...

> +   int tries = 4;

> +   while (tries-- > 0) {
> +   ret = mlx90632_perform_measurement(data);
> +   if (ret < 0)
> +   goto read_unlock;
> +
> +   if (ret == 19)
> +   break;
> +   }
> +   if (tries < 0) {
> +   ret = -ETIMEDOUT;
> +   goto read_unlock;
> +   }

Again, please use

unsigned int tries = 4; // or should be 5?

do {
  ...
} while (ret != ..._ LAST_CHANNEL && --tries);
if (!tries)
  ...

It will really make the code easier to read.

...

> +static s64 mlx90632_preprocess_temp_obj_extended(s16 object_new_raw, s16 
> ambient_new_raw,
> +s16 ambient_old_raw, s16 Ka)
> +{
> +   s64 VR_IR, kKa, tmp;
> +
> +   kKa = ((s64)Ka * 1000LL) >> 10ULL;
> +   VR_IR = (s64)ambient_old_raw * 100LL +
> +   kKa * div64_s64((s64)ambient_new_raw * 1000LL,
> +   MLX90632_REF_3);
> +   tmp = div64_s64(
> +   div64_s64((s64) object_new_raw * 1LL, 
> MLX90632_REF_12),
> +   VR_IR);
> +   return div64_s64(tmp << 19ULL, 1000LL);
> +}

It would be nice to have a comment on this voodoo arithmetics.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3 2/2] iio:temperature:mlx90632: Adding extended calibration option

[Crt Mori]

On Sat, 8 Aug 2020 at 12:44, Andy Shevchenko  wrote:
>
> On Sat, Aug 8, 2020 at 2:24 AM Crt Mori  wrote:
> >
> > For some time the market wants medical grade accuracy in medical range,
> > while still retaining the declared accuracy outside of the medical range
> > within the same sensor. That is why we created extended calibration
> > which is automatically switched to when object temperature is too high.
> >
> > This patch also introduces the object_ambient_temperature variable which
> > is needed for more accurate calculation of the object infra-red
> > footprint as sensor's ambient temperature might be totally different
> > than what the ambient temperature is at object and that is why we can
> > have some more errors which can be eliminated. Currently this temperature
> > is fixed at 25, but the interface to adjust it by user (with external
> > sensor or just IR measurement of the other object which acts as ambient),
> > will be introduced in another commit.
>
> Thank you for an update!
> My comments below.
>

Will provide next version with changelog as well.

> ...
>
> >  struct mlx90632_data {
> > struct i2c_client *client;
> > struct mutex lock; /* Multiple reads for single measurement */
> > struct regmap *regmap;
> > u16 emissivity;
> > +   u8 mtyp; /* measurement type - to enable extended range 
> > calculations */
> > +   u32 object_ambient_temperature;
> >  };
>
> As a separate patch to have a kernel doc for this, there are plenty of
> examples in the kernel, but I will show below an example
>
> /**
>  * struct foo - private data for the MLX90632 device
>  * @client: I2C client of the device
>  * @bar: ...
>  ...
>  */
> struct foo {
>   struct i2c_client *client;
>   ... bar;
>   ...
> };
>
> ...
>
> > +   if ((type != MLX90632_MTYP_MEDICAL) && (type != 
> > MLX90632_MTYP_EXTENDED))
> > +   return -EINVAL;
>
> So, just to point out what the difference between & and &&  (even for
> boolean): the former one forces both sides of operand to be executed,
> while && checks for only first in case of false.
>

OK, I am OK with evaluating first only. I mostly thought it is boolean
vs bitwise, but I keep on learning.

> ...
>
> > +static int mlx90632_read_ambient_raw_extended(struct regmap *regmap,
> > + s16 *ambient_new_raw, s16 
> > *ambient_old_raw)
> > +{
> > +   unsigned int read_tmp;
> > +   int ret;
> > +
> > +   ret = regmap_read(regmap, MLX90632_RAM_3(17), &read_tmp);
> > +   if (ret < 0)
> > +   return ret;
> > +   *ambient_new_raw = (s16)read_tmp;
>
> Again the same question, do you need all these castings?
>

These castings are in fact needed. You read unsigned integer, but the
return value is signed integer. Without the cast it did not extend the
signed bit, but just wrote the value to signed. Also I find it more
obvious with casts, that I did not "accidentally" convert to signed.

> > +   ret = regmap_read(regmap, MLX90632_RAM_3(18), &read_tmp);
>
> These 17, 18 and 19 should be defined with descriptive names.
>

When we started 0 to 19 were all open for access, from userspace, then
only 1 and 2 were used with calculations, and now we use 17, 18 and
19. Matter of fact is, I can't provide a descriptive name as it
depends on DSP version and as you can see now within the same DSP
version, also on the ID part. While RAM3 vs RAM1 and RAM2 could be
named RAM_OBJECT1, RAM_OBJECT2, RAM_AMBIENT, knowing our development
that might not be true in the next configuration, so I rather keep the
naming as in the datasheet.

> > +   if (ret < 0)
> > +   return ret;
> > +   *ambient_old_raw = (s16)read_tmp;
> > +
> > +   return 0;
> > +}
>
> ...
>
> > +   int tries = 4;
>
> > +   while (tries-- > 0) {
> > +   ret = mlx90632_perform_measurement(data);
> > +   if (ret < 0)
> > +   goto read_unlock;
> > +
> > +   if (ret == 19)
> > +   break;
> > +   }
> > +   if (tries < 0) {
> > +   ret = -ETIMEDOUT;
> > +   goto read_unlock;
> > +   }
>
> Again, please use
>
> unsigned int tries = 4; // or should be 5?
>
> do {
>   ...
> } while (ret != ..._ LAST_CHANNEL && --tries);
> if (!tries)
>   ...
>
> It will really make the code easier to read.
>

I thought of keeping it consistent with the existing implementation in
the perform_measurement function. If you still insist in the loop
change, then I think it is better if I provide a followup patch that
changes both these loops.

> ...
>
> > +static s64 mlx90632_preprocess_temp_obj_extended(s16 object_new_raw, s16 
> > ambient_new_raw,
> > +s16 ambient_old_raw, s16 
> > Ka)
> > +{
> > +   s64 VR_IR, kKa, tmp;
> > +
> > +   kKa = ((s64)Ka * 1000LL) >> 10ULL;
> > +   VR_IR = (s64)ambient_old_raw * 100LL +
> > +   kKa * d

drivers/md/dm-mpath.c:1682 multipath_end_io_bio() error: double unlocked 'm->lock' (orig line 1675)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: a271a89c6e4773478b1c4f8213dfe8351ea66723 dm mpath: take m->lock 
spinlock when testing QUEUE_IF_NO_PATH
date:   4 weeks ago
config: arm-randconfig-m031-20200808 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0

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

New smatch warnings:
drivers/md/dm-mpath.c:1682 multipath_end_io_bio() error: double unlocked 
'm->lock' (orig line 1675)
drivers/md/dm-mpath.c:1988 multipath_prepare_ioctl() error: double unlocked 
'm->lock' (orig line 1977)

Old smatch warnings:
drivers/md/dm-mpath.c:432 choose_pgpath() error: double unlocked 'm->lock' 
(orig line 402)
drivers/md/dm-mpath.c:443 choose_pgpath() error: double unlocked 'm->lock' 
(orig line 389)
drivers/md/dm-mpath.c:593 __map_bio() error: double unlocked 'm->lock' (orig 
line 589)
drivers/md/dm-mpath.c:1574 pg_init_done() error: double unlocked 'm->lock' 
(orig line 1527)

vim +1682 drivers/md/dm-mpath.c

^1da177e4c3f41 Linus Torvalds  2005-04-16  1647  
4e4cbee93d5613 Christoph Hellwig   2017-06-03  1648  static int 
multipath_end_io_bio(struct dm_target *ti, struct bio *clone,
4e4cbee93d5613 Christoph Hellwig   2017-06-03  1649 
blk_status_t *error)
76e33fe4e2c436 Mike Snitzer2016-05-19  1650  {
14ef1e48269dde Christoph Hellwig   2017-06-03  1651 struct 
multipath *m = ti->private;
14ef1e48269dde Christoph Hellwig   2017-06-03  1652 struct 
dm_mpath_io *mpio = get_mpio_from_bio(clone);
14ef1e48269dde Christoph Hellwig   2017-06-03  1653 struct pgpath 
*pgpath = mpio->pgpath;
76e33fe4e2c436 Mike Snitzer2016-05-19  1654 unsigned long 
flags;
1be56909845889 Christoph Hellwig   2017-06-03  1655 int r = 
DM_ENDIO_DONE;
76e33fe4e2c436 Mike Snitzer2016-05-19  1656  
a1275677f8cd06 Keith Busch 2018-01-09  1657 if (!*error || 
!blk_path_error(*error))
14ef1e48269dde Christoph Hellwig   2017-06-03  1658 goto 
done;
76e33fe4e2c436 Mike Snitzer2016-05-19  1659  
14ef1e48269dde Christoph Hellwig   2017-06-03  1660 if (pgpath)
14ef1e48269dde Christoph Hellwig   2017-06-03  1661 
fail_path(pgpath);
76e33fe4e2c436 Mike Snitzer2016-05-19  1662  
a271a89c6e4773 Mike Snitzer2020-06-10  1663 if 
(!atomic_read(&m->nr_valid_paths)) {
a271a89c6e4773 Mike Snitzer2020-06-10  1664 
spin_lock_irqsave(&m->lock, flags);
a271a89c6e4773 Mike Snitzer2020-06-10  1665 if 
(!test_bit(MPATHF_QUEUE_IF_NO_PATH, &m->flags)) {
a862e4e2154289 Mike Snitzer2020-05-26  1666 
if (__must_push_back(m)) {
c1fd0abee0d52e Mike Snitzer2017-12-07  1667 
r = DM_ENDIO_REQUEUE;
c1fd0abee0d52e Mike Snitzer2017-12-07  1668 
} else {
18a482f5245cc8 Christoph Hellwig   2017-05-15  1669 
dm_report_EIO(m);
4e4cbee93d5613 Christoph Hellwig   2017-06-03  1670 
*error = BLK_STS_IOERR;
c1fd0abee0d52e Mike Snitzer2017-12-07  1671 
}
a271a89c6e4773 Mike Snitzer2020-06-10  1672 
spin_unlock_irqrestore(&m->lock, flags);
14ef1e48269dde Christoph Hellwig   2017-06-03  1673 
goto done;
18a482f5245cc8 Christoph Hellwig   2017-05-15  1674 }
a271a89c6e4773 Mike Snitzer2020-06-10 @1675 
spin_unlock_irqrestore(&m->lock, flags);
a271a89c6e4773 Mike Snitzer2020-06-10  1676 }
76e33fe4e2c436 Mike Snitzer2016-05-19  1677  
76e33fe4e2c436 Mike Snitzer2016-05-19  1678 
spin_lock_irqsave(&m->lock, flags);
76e33fe4e2c436 Mike Snitzer2016-05-19  1679 
bio_list_add(&m->queued_bios, clone);
76e33fe4e2c436 Mike Snitzer2016-05-19  1680 if 
(!test_bit(MPATHF_QUEUE_IO, &m->flags))
76e33fe4e2c436 Mike Snitzer2016-05-19  1681 
queue_work(kmultipathd, &m->process_queued_bios);
69cea0d45a618a Mike Snitzer2020-06-10 @1682 
spin_unlock_irqrestore(&m->lock, flags);
76e33fe4e2c436 Mike Snitzer2016-05-19  1683  
1be56909845889 Christoph Hellwig   2017-06-03  1684 r = 
DM_ENDIO_INCOMPLETE;
14ef1e48269dde Christoph Hellwig   2017-06-03  1685  done:
76e33fe4e2c436 Mike Snitzer2016-05-19  1686 if (pgpath) {
14ef1e48269dde Christoph Hellwig 

Re: [PATCH v1 01/12] fbdev: gxfb: use generic power management

[Sam Ravnborg]

Hi Vaibhav

On Wed, Aug 05, 2020 at 11:37:11PM +0530, Vaibhav Gupta wrote:
> Drivers using legacy power management .suspen()/.resume() callbacks
> have to manage PCI states and device's PM states themselves. They also
> need to take care of standard configuration registers.
> 
> Switch to generic power management framework using a single
> "struct dev_pm_ops" variable

"to take the unnecessary load from the driver."
- I do not parse the above - I cannot see what load is removed.
But the code is simpler which is fine. The drawback is that we now
always link in the suspend_gx functions but hopefultl the linker drops
them later.

> This also avoids the need for the driver to directly call most of the PCI
> helper functions and device power state control functions, as through
> the generic framework PCI Core takes care of the necessary operations,
> and drivers are required to do only device-specific jobs.
Again, I do not see what calles are removed.
A single check for the state is dropped - anything else?

> 
> Signed-off-by: Vaibhav Gupta 
> ---
>  drivers/video/fbdev/geode/gxfb.h   |  5 
>  drivers/video/fbdev/geode/gxfb_core.c  | 36 ++
>  drivers/video/fbdev/geode/suspend_gx.c |  4 ---
>  3 files changed, 20 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/video/fbdev/geode/gxfb.h 
> b/drivers/video/fbdev/geode/gxfb.h
> index d2e9c5c8e294..792c111c21e4 100644
> --- a/drivers/video/fbdev/geode/gxfb.h
> +++ b/drivers/video/fbdev/geode/gxfb.h
> @@ -21,7 +21,6 @@ struct gxfb_par {
>   void __iomem *dc_regs;
>   void __iomem *vid_regs;
>   void __iomem *gp_regs;
> -#ifdef CONFIG_PM
>   int powered_down;
>  
>   /* register state, for power management functionality */
> @@ -36,7 +35,6 @@ struct gxfb_par {
>   uint64_t fp[FP_REG_COUNT];
>  
>   uint32_t pal[DC_PAL_COUNT];
> -#endif
>  };
>  
>  unsigned int gx_frame_buffer_size(void);
> @@ -49,11 +47,8 @@ void gx_set_dclk_frequency(struct fb_info *info);
>  void gx_configure_display(struct fb_info *info);
>  int gx_blank_display(struct fb_info *info, int blank_mode);
>  
> -#ifdef CONFIG_PM
>  int gx_powerdown(struct fb_info *info);
>  int gx_powerup(struct fb_info *info);
> -#endif
> -
>  
>  /* Graphics Processor registers (table 6-23 from the data book) */
>  enum gp_registers {
> diff --git a/drivers/video/fbdev/geode/gxfb_core.c 
> b/drivers/video/fbdev/geode/gxfb_core.c
> index d38a148d4746..44089b331f91 100644
> --- a/drivers/video/fbdev/geode/gxfb_core.c
> +++ b/drivers/video/fbdev/geode/gxfb_core.c
> @@ -322,17 +322,14 @@ static struct fb_info *gxfb_init_fbinfo(struct device 
> *dev)
>   return info;
>  }
>  
> -#ifdef CONFIG_PM
> -static int gxfb_suspend(struct pci_dev *pdev, pm_message_t state)
> +static int __maybe_unused gxfb_suspend(struct device *dev)
>  {
> - struct fb_info *info = pci_get_drvdata(pdev);
> + struct fb_info *info = dev_get_drvdata(dev);
I do not see any dev_set_drvdata() so I guess we get a NULL pointer
here which is not intended.
Adding a dev_set_data() to gxfb_probe() would do the trick.

>  
> - if (state.event == PM_EVENT_SUSPEND) {
> - console_lock();
> - gx_powerdown(info);
> - fb_set_suspend(info, 1);
> - console_unlock();
> - }
> + console_lock();
> + gx_powerdown(info);
> + fb_set_suspend(info, 1);
> + console_unlock();
>  
>   /* there's no point in setting PCI states; we emulate PCI, so
>* we don't end up getting power savings anyways */
> @@ -340,9 +337,9 @@ static int gxfb_suspend(struct pci_dev *pdev, 
> pm_message_t state)
>   return 0;
>  }
>  
> -static int gxfb_resume(struct pci_dev *pdev)
> +static int __maybe_unused gxfb_resume(struct device *dev)
>  {
> - struct fb_info *info = pci_get_drvdata(pdev);
> + struct fb_info *info = dev_get_drvdata(dev);
>   int ret;
>  
>   console_lock();
> @@ -356,7 +353,6 @@ static int gxfb_resume(struct pci_dev *pdev)
>   console_unlock();
>   return 0;
>  }
> -#endif
>  
>  static int gxfb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
> @@ -467,15 +463,23 @@ static const struct pci_device_id gxfb_id_table[] = {
>  
>  MODULE_DEVICE_TABLE(pci, gxfb_id_table);
>  
> +static const struct dev_pm_ops gxfb_pm_ops = {
> +#ifdef CONFIG_PM_SLEEP
> + .suspend= gxfb_suspend,
> + .resume = gxfb_resume,
> + .freeze = NULL,
> + .thaw   = gxfb_resume,
> + .poweroff   = NULL,
> + .restore= gxfb_resume,
> +#endif
> +};
Can we use SET_SYSTEM_SLEEP_PM_OPS here?
.freeze will be assigned gxfb_suspend, but gxfb_suspend will anyway be
called as far as I read the code.
Likewise for poweroff.

Sam

> +
>  static struct pci_driver gxfb_driver = {
>   .name   = "gxfb",
>   .id_table   = gxfb_id_table,
>   .probe  = gxfb_probe,
>   .remove = gxfb_remove,
> -#ifdef CONFIG_PM
> -   

Re: [PATCH v1 02/12] fbdev: lxfb: use generic power management

[Sam Ravnborg]

Hi Vaibhav

On Wed, Aug 05, 2020 at 11:37:12PM +0530, Vaibhav Gupta wrote:
> Drivers using legacy power management .suspen()/.resume() callbacks
> have to manage PCI states and device's PM states themselves. They also
> need to take care of standard configuration registers.
> 
> Switch to generic power management framework using a single
> "struct dev_pm_ops" variable to take the unnecessary load from the driver.
> This also avoids the need for the driver to directly call most of the PCI
> helper functions and device power state control functions, as through
> the generic framework PCI Core takes care of the necessary operations,
> and drivers are required to do only device-specific jobs.
> 
> Signed-off-by: Vaibhav Gupta 

Some of the same comments from fxfb applies to lxfb.
Please address these and re-submit.

Sam

> ---
>  drivers/video/fbdev/geode/lxfb.h  |  5 
>  drivers/video/fbdev/geode/lxfb_core.c | 37 +++
>  drivers/video/fbdev/geode/lxfb_ops.c  |  4 ---
>  3 files changed, 20 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/video/fbdev/geode/lxfb.h 
> b/drivers/video/fbdev/geode/lxfb.h
> index ef24bf6d49dc..d37b32dbcd68 100644
> --- a/drivers/video/fbdev/geode/lxfb.h
> +++ b/drivers/video/fbdev/geode/lxfb.h
> @@ -29,7 +29,6 @@ struct lxfb_par {
>   void __iomem *gp_regs;
>   void __iomem *dc_regs;
>   void __iomem *vp_regs;
> -#ifdef CONFIG_PM
>   int powered_down;
>  
>   /* register state, for power mgmt functionality */
> @@ -50,7 +49,6 @@ struct lxfb_par {
>   uint32_t hcoeff[DC_HFILT_COUNT * 2];
>   uint32_t vcoeff[DC_VFILT_COUNT];
>   uint32_t vp_coeff[VP_COEFF_SIZE / 4];
> -#endif
>  };
>  
>  static inline unsigned int lx_get_pitch(unsigned int xres, int bpp)
> @@ -64,11 +62,8 @@ int lx_blank_display(struct fb_info *, int);
>  void lx_set_palette_reg(struct fb_info *, unsigned int, unsigned int,
>   unsigned int, unsigned int);
>  
> -#ifdef CONFIG_PM
>  int lx_powerdown(struct fb_info *info);
>  int lx_powerup(struct fb_info *info);
> -#endif
> -
>  
>  /* Graphics Processor registers (table 6-29 from the data book) */
>  enum gp_registers {
> diff --git a/drivers/video/fbdev/geode/lxfb_core.c 
> b/drivers/video/fbdev/geode/lxfb_core.c
> index adc2d9c2395e..66c81262d18f 100644
> --- a/drivers/video/fbdev/geode/lxfb_core.c
> +++ b/drivers/video/fbdev/geode/lxfb_core.c
> @@ -443,17 +443,14 @@ static struct fb_info *lxfb_init_fbinfo(struct device 
> *dev)
>   return info;
>  }
>  
> -#ifdef CONFIG_PM
> -static int lxfb_suspend(struct pci_dev *pdev, pm_message_t state)
> +static int __maybe_unused lxfb_suspend(struct device *dev)
>  {
> - struct fb_info *info = pci_get_drvdata(pdev);
> + struct fb_info *info = dev_get_drvdata(dev);
>  
> - if (state.event == PM_EVENT_SUSPEND) {
> - console_lock();
> - lx_powerdown(info);
> - fb_set_suspend(info, 1);
> - console_unlock();
> - }
> + console_lock();
> + lx_powerdown(info);
> + fb_set_suspend(info, 1);
> + console_unlock();
>  
>   /* there's no point in setting PCI states; we emulate PCI, so
>* we don't end up getting power savings anyways */
> @@ -461,9 +458,9 @@ static int lxfb_suspend(struct pci_dev *pdev, 
> pm_message_t state)
>   return 0;
>  }
>  
> -static int lxfb_resume(struct pci_dev *pdev)
> +static int __maybe_unused lxfb_resume(struct device *dev)
>  {
> - struct fb_info *info = pci_get_drvdata(pdev);
> + struct fb_info *info = dev_get_drvdata(dev);
>   int ret;
>  
>   console_lock();
> @@ -477,10 +474,6 @@ static int lxfb_resume(struct pci_dev *pdev)
>   console_unlock();
>   return 0;
>  }
> -#else
> -#define lxfb_suspend NULL
> -#define lxfb_resume NULL
> -#endif
>  
>  static int lxfb_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>  {
> @@ -600,13 +593,23 @@ static struct pci_device_id lxfb_id_table[] = {
>  
>  MODULE_DEVICE_TABLE(pci, lxfb_id_table);
>  
> +static const struct dev_pm_ops lxfb_pm_ops = {
> +#ifdef CONFIG_PM_SLEEP
> + .suspend= lxfb_suspend,
> + .resume = lxfb_resume,
> + .freeze = NULL,
> + .thaw   = lxfb_resume,
> + .poweroff   = NULL,
> + .restore= lxfb_resume,
> +#endif
> +};
> +
>  static struct pci_driver lxfb_driver = {
>   .name   = "lxfb",
>   .id_table   = lxfb_id_table,
>   .probe  = lxfb_probe,
>   .remove = lxfb_remove,
> - .suspend= lxfb_suspend,
> - .resume = lxfb_resume,
> + .driver.pm  = &lxfb_pm_ops,
>  };
>  
>  #ifndef MODULE
> diff --git a/drivers/video/fbdev/geode/lxfb_ops.c 
> b/drivers/video/fbdev/geode/lxfb_ops.c
> index 5be8bc62844c..b3a041fce570 100644
> --- a/drivers/video/fbdev/geode/lxfb_ops.c
> +++ b/drivers/video/fbdev/geode/lxfb_ops.c
> @@ -580,8 +580,6 @@ int lx_blank_display(struct fb_info *info, int

arch/mips/kvm/vz.c:32:10: fatal error: loongson_regs.h: No such file or directory

[kernel test robot]

Hi Huacai,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 7f2a83f1c2a941ebfee53f504ed5fdbc61cfb333 KVM: MIPS: Add CPUCFG 
emulation for Loongson-3
date:   9 weeks ago
config: mips-randconfig-r024-20200808 (attached as .config)
compiler: mips64el-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
git checkout 7f2a83f1c2a941ebfee53f504ed5fdbc61cfb333
# 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 errors (new ones prefixed by >>):

>> arch/mips/kvm/vz.c:32:10: fatal error: loongson_regs.h: No such file or 
>> directory
  32 | #include "loongson_regs.h"
 |  ^
   compilation terminated.

vim +32 arch/mips/kvm/vz.c

30  
31  #include "interrupt.h"
  > 32  #include "loongson_regs.h"
33  

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


.config.gz
Description: application/gzip

arch/powerpc/platforms/powernv/opal-fadump.c:42:33: sparse: sparse: incorrect type in assignment (different base types)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 742a265accd3e3afcc8e7b17f409c93c1de8be85 powerpc/fadump: register 
kernel metadata address with opal
date:   11 months ago
config: powerpc64-randconfig-s032-20200808 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout 742a265accd3e3afcc8e7b17f409c93c1de8be85
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 

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


sparse warnings: (new ones prefixed by >>)

>> arch/powerpc/platforms/powernv/opal-fadump.c:42:33: sparse: sparse: 
>> incorrect type in assignment (different base types) @@ expected 
>> restricted __be64 [usertype] dest @@ got unsigned long long [usertype] 
>> addr @@
>> arch/powerpc/platforms/powernv/opal-fadump.c:42:33: sparse: expected 
>> restricted __be64 [usertype] dest
>> arch/powerpc/platforms/powernv/opal-fadump.c:42:33: sparse: got unsigned 
>> long long [usertype] addr
   arch/powerpc/platforms/powernv/opal-fadump.c:43:33: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] size @@ got unsigned long boot_memory_size @@
>> arch/powerpc/platforms/powernv/opal-fadump.c:43:33: sparse: expected 
>> restricted __be64 [usertype] size
   arch/powerpc/platforms/powernv/opal-fadump.c:43:33: sparse: got unsigned 
long boot_memory_size
>> arch/powerpc/platforms/powernv/opal-fadump.c:50:53: sparse: sparse: 
>> restricted __be64 degrades to integer

vim +42 arch/powerpc/platforms/powernv/opal-fadump.c

32  
33  static u64 opal_fadump_init_mem_struct(struct fw_dump *fadump_conf)
34  {
35  u64 addr = fadump_conf->reserve_dump_area_start;
36  
37  opal_fdm = __va(fadump_conf->kernel_metadata);
38  opal_fadump_init_metadata(opal_fdm);
39  
40  opal_fdm->region_cnt = 1;
41  opal_fdm->rgn[0].src= 0;
  > 42  opal_fdm->rgn[0].dest   = addr;
  > 43  opal_fdm->rgn[0].size   = fadump_conf->boot_memory_size;
44  addr += fadump_conf->boot_memory_size;
45  
46  /*
47   * Kernel metadata is passed to f/w and retrieved in capture 
kerenl.
48   * So, use it to save fadump header address instead of 
calculating it.
49   */
  > 50  opal_fdm->fadumphdr_addr = (opal_fdm->rgn[0].dest +
51  fadump_conf->boot_memory_size);
52  
53  return addr;
54  }
55  

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


.config.gz
Description: application/gzip

drivers/virtio/virtio_mem.c:1031 virtio_mem_mb_plug_any_sb() error: uninitialized symbol 'rc'.

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 5f1f79bbc9e26fa9412fa9522f957bb8f030c442 virtio-mem: Paravirtualized 
memory hotplug
date:   9 weeks ago
config: x86_64-randconfig-m001-20200808 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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

New smatch warnings:
drivers/virtio/virtio_mem.c:1031 virtio_mem_mb_plug_any_sb() error: 
uninitialized symbol 'rc'.
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:1607 
calculate_bandwidth() warn: Function too hairy.  No more merges.

Old smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3387 bw_calcs() 
warn: inconsistent indenting

vim +/rc +1031 drivers/virtio/virtio_mem.c

   978  
   979  /*
   980   * Try to plug the desired number of subblocks of a memory block that
   981   * is already added to Linux.
   982   *
   983   * Will modify the state of the memory block.
   984   *
   985   * Note: Can fail after some subblocks were successfully plugged.
   986   */
   987  static int virtio_mem_mb_plug_any_sb(struct virtio_mem *vm, unsigned 
long mb_id,
   988   uint64_t *nb_sb, bool online)
   989  {
   990  unsigned long pfn, nr_pages;
   991  int sb_id, count;
   992  int rc;
   993  
   994  if (WARN_ON_ONCE(!*nb_sb))
   995  return -EINVAL;
   996  
   997  while (*nb_sb) {
   998  sb_id = virtio_mem_mb_first_unplugged_sb(vm, mb_id);
   999  if (sb_id >= vm->nb_sb_per_mb)
  1000  break;
  1001  count = 1;
  1002  while (count < *nb_sb &&
  1003 sb_id + count < vm->nb_sb_per_mb &&
  1004 !virtio_mem_mb_test_sb_plugged(vm, mb_id, sb_id 
+ count,
  10051))
  1006  count++;
  1007  
  1008  rc = virtio_mem_mb_plug_sb(vm, mb_id, sb_id, count);
  1009  if (rc)
  1010  return rc;
  1011  *nb_sb -= count;
  1012  if (!online)
  1013  continue;
  1014  
  1015  /* fake-online the pages if the memory block is online 
*/
  1016  pfn = PFN_DOWN(virtio_mem_mb_id_to_phys(mb_id) +
  1017 sb_id * vm->subblock_size);
  1018  nr_pages = PFN_DOWN(count * vm->subblock_size);
  1019  virtio_mem_fake_online(pfn, nr_pages);
  1020  }
  1021  
  1022  if (virtio_mem_mb_test_sb_plugged(vm, mb_id, 0, 
vm->nb_sb_per_mb)) {
  1023  if (online)
  1024  virtio_mem_mb_set_state(vm, mb_id,
  1025  
VIRTIO_MEM_MB_STATE_ONLINE);
  1026  else
  1027  virtio_mem_mb_set_state(vm, mb_id,
  1028  
VIRTIO_MEM_MB_STATE_OFFLINE);
  1029  }
  1030  
> 1031  return rc;
  1032  }
  1033  

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


.config.gz
Description: application/gzip

[PATCH] mmc: Kconfig: Add RISCV and CSKY for MMC_DW

[guoren]

From: Guo Ren 

Synopsys DesignWare MMC controller could be used in RISC-V and
C-SKY architectures.

Signed-off-by: Guo Ren 
Cc: Ulf Hansson 
---
 drivers/mmc/host/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 3b706af..119adab 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -777,7 +777,7 @@ config MMC_CAVIUM_THUNDERX
 
 config MMC_DW
tristate "Synopsys DesignWare Memory Card Interface"
-   depends on ARC || ARM || ARM64 || MIPS || COMPILE_TEST
+   depends on ARC || ARM || ARM64 || MIPS || RISCV || CSKY || COMPILE_TEST
help
  This selects support for the Synopsys DesignWare Mobile Storage IP
  block, this provides host support for SD and MMC interfaces, in both
-- 
2.7.4

[PATCH v3] drm/vkms: guarantee vblank when capturing crc

[Melissa Wen]

VKMS needs vblank interrupts enabled to capture CRC. When vblank is
disabled, tests like kms_cursor_crc and kms_pipe_crc_basic getting stuck
waiting for a capture that will not occur until vkms wakes up. This patch
adds a helper to set composer and ensure that vblank remains enabled as
long as the CRC capture is needed.

It clears the execution of the following kms_cursor_crc subtests:
1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, off-screen, sliding,
random, fast-moving])] - successful when running individually.
2. pipe-A-cursor-dpms passes again
3. pipe-A-cursor-suspend also passes

The issue was initially tracked in the sequential execution of IGT
kms_cursor_crc subtests: when running the test sequence or one of its
subtests twice, the odd execs complete and the pairs get stuck in an
endless wait. In the IGT code, calling a wait_for_vblank on preparing for
CRC capture prevented the busy-wait. But the problem persisted in the
pipe-A-cursor-dpms and -suspend subtests.

Checking the history, the pipe-A-cursor-dpms subtest was successful when,
in vkms_atomic_commit_tail, instead of using the flip_done op, it used
wait_for_vblanks. Another way to prevent blocking was wait_one_vblank when
enabling crtc. However, in both cases, pipe-A-cursor-suspend persisted
blocking in the 2nd start of CRC capture, which may indicate that
something got stuck in the step of CRC setup. Indeed, wait_one_vblank in
the crc setup was able to sync things and free all kms_cursor_crc
subtests. Besides, other alternatives to force enabling vblanks or prevent
disabling them such as calling drm_crtc_put_vblank or modeset_enables
before commit_planes + offdelay = 0, also unlock all subtests executions.

Finally, due to vkms's dependence on vblank interruptions to perform
tasks, this patch uses refcount to ensure that vblanks happen when
enabling composer and while crc capture is needed.

Cc: Rodrigo Siqueira 
Cc: Haneen Mohammed 

Co-debugged-by: Sidong Yang 
Signed-off-by: Sidong Yang 
Signed-off-by: Melissa Wen 
Reviewed-by: Daniel Vetter 

---

v2:
- extract a vkms_set_composer helper
- fix vblank refcounting for the disabling case

v3:
- make the vkms_set_composer helper static
- review the credit tags

---
 drivers/gpu/drm/vkms/vkms_composer.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vkms/vkms_composer.c 
b/drivers/gpu/drm/vkms/vkms_composer.c
index b8b060354667..4f3b07a32b60 100644
--- a/drivers/gpu/drm/vkms/vkms_composer.c
+++ b/drivers/gpu/drm/vkms/vkms_composer.c
@@ -233,6 +233,22 @@ int vkms_verify_crc_source(struct drm_crtc *crtc, const 
char *src_name,
return 0;
 }
 
+static void vkms_set_composer(struct vkms_output *out, bool enabled)
+{
+   bool old_enabled;
+
+   if (enabled)
+   drm_crtc_vblank_get(&out->crtc);
+
+   spin_lock_irq(&out->lock);
+   old_enabled = out->composer_enabled;
+   out->composer_enabled = enabled;
+   spin_unlock_irq(&out->lock);
+
+   if (old_enabled)
+   drm_crtc_vblank_put(&out->crtc);
+}
+
 int vkms_set_crc_source(struct drm_crtc *crtc, const char *src_name)
 {
struct vkms_output *out = drm_crtc_to_vkms_output(crtc);
@@ -241,9 +257,7 @@ int vkms_set_crc_source(struct drm_crtc *crtc, const char 
*src_name)
 
ret = vkms_crc_parse_source(src_name, &enabled);
 
-   spin_lock_irq(&out->lock);
-   out->composer_enabled = enabled;
-   spin_unlock_irq(&out->lock);
+   vkms_set_composer(out, enabled);
 
return ret;
 }
-- 
2.27.0

Re: [PATCH 16/22] crypto: ccree - add check for xts input length equal to zero

[Gilad Ben-Yossef]

On Fri, Aug 7, 2020 at 7:22 PM Andrei Botila  wrote:
>
> From: Andrei Botila 
>
> Standardize the way input lengths equal to 0 are handled in all skcipher
> algorithms. All the algorithms return 0 for input lengths equal to zero.
> This change has implications not only for xts(aes) but also for cts(cbc(aes))
> and cts(cbc(paes)).
>
> Cc: Gilad Ben-Yossef 
> Signed-off-by: Andrei Botila 
> ---
>  drivers/crypto/ccree/cc_cipher.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/crypto/ccree/cc_cipher.c 
> b/drivers/crypto/ccree/cc_cipher.c
> index 076669dc1035..112bb8b4dce6 100644
> --- a/drivers/crypto/ccree/cc_cipher.c
> +++ b/drivers/crypto/ccree/cc_cipher.c
> @@ -912,17 +912,18 @@ static int cc_cipher_process(struct skcipher_request 
> *req,
>
> /* STAT_PHASE_0: Init and sanity checks */
>
> -   if (validate_data_size(ctx_p, nbytes)) {
> -   dev_dbg(dev, "Unsupported data size %d.\n", nbytes);
> -   rc = -EINVAL;
> -   goto exit_process;
> -   }
> if (nbytes == 0) {
> /* No data to process is valid */
> rc = 0;
> goto exit_process;
> }
>
> +   if (validate_data_size(ctx_p, nbytes)) {
> +   dev_dbg(dev, "Unsupported data size %d.\n", nbytes);
> +   rc = -EINVAL;
> +   goto exit_process;
> +   }
> +
> if (ctx_p->fallback_on) {
> struct skcipher_request *subreq = skcipher_request_ctx(req);
>
> --
> 2.17.1
>

Acked-by: Gilad Ben-Yossef 

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!

[PATCH v4 0/4] iio: temperature: mlx90632: Add extended calibration calculations

[Crt Mori]

Since the second patch is dependent on the first and was still not
merged, I have decided to send them together. First patch just makes
second one more readable as it splits out the repeated calculation and
that enables the second patch to tweak the variable to the new
condition.

V4 review comments from Andy Shevchenko :
 - Move the function creation for Ta4 to first patch
 - Add kernel doc patch for documenting internal struct
 - Add patch to convert while loops to do-while loops for
   polling

V3 review comments from Andy Shevchenko :
 - Change commit message text to more proper English as per suggestions
 - Drop unneeded brackets and parentheses
 - Use defines from limits.h
 - Remove userspace typedefs as leftovers from porting
 - Testing of timeout loops with iopoll.h was no successful,
   because delay between measurements is 10ms, but we need to
   fill at least 3 channels, so final timeout should be 40ms
   which is out of scope of usleep function
 - Fixing some typos in comments

V2 review comments from Andy Shevchenko :
 - Convert divison back to shifts to make it more readable

Crt Mori (4):
  iio:temperature:mlx90632: Reduce number of equal calulcations
  iio:temperature:mlx90632: Adding extended calibration option
  iio:temperature:mlx90632: Add kerneldoc to the internal struct
  iio:temperature:mlx90632: Convert polling while loops to do-while

 drivers/iio/temperature/mlx90632.c | 251 +++--
 1 file changed, 236 insertions(+), 15 deletions(-)

-- 
2.25.1

[PATCH v4 1/4] iio:temperature:mlx90632: Reduce number of equal calulcations

[Crt Mori]

TAdut4 was calculated each iteration although it did not change. In light
of near future additions of the Extended range DSP calculations, this
function refactoring will help reduce unrelated changes in that series as
well as reduce the number of new functions needed.

Signed-off-by: Crt Mori 
---
 drivers/iio/temperature/mlx90632.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/iio/temperature/mlx90632.c 
b/drivers/iio/temperature/mlx90632.c
index 51b812bcff2e..c3de10ba5b1e 100644
--- a/drivers/iio/temperature/mlx90632.c
+++ b/drivers/iio/temperature/mlx90632.c
@@ -374,11 +374,11 @@ static s32 mlx90632_calc_temp_ambient(s16 
ambient_new_raw, s16 ambient_old_raw,
 }
 
 static s32 mlx90632_calc_temp_object_iteration(s32 prev_object_temp, s64 
object,
-  s64 TAdut, s32 Fa, s32 Fb,
+  s64 TAdut, s64 TAdut4, s32 Fa, 
s32 Fb,
   s32 Ga, s16 Ha, s16 Hb,
   u16 emissivity)
 {
-   s64 calcedKsTO, calcedKsTA, ir_Alpha, TAdut4, Alpha_corr;
+   s64 calcedKsTO, calcedKsTA, ir_Alpha, Alpha_corr;
s64 Ha_customer, Hb_customer;
 
Ha_customer = ((s64)Ha * 100LL) >> 14ULL;
@@ -393,30 +393,35 @@ static s32 mlx90632_calc_temp_object_iteration(s32 
prev_object_temp, s64 object,
Alpha_corr = emissivity * div64_s64(Alpha_corr, 10LL);
Alpha_corr = div64_s64(Alpha_corr, 1000LL);
ir_Alpha = div64_s64((s64)object * 1000LL, Alpha_corr);
-   TAdut4 = (div64_s64(TAdut, 1LL) + 27315) *
-   (div64_s64(TAdut, 1LL) + 27315) *
-   (div64_s64(TAdut, 1LL)  + 27315) *
-   (div64_s64(TAdut, 1LL) + 27315);
 
return (int_sqrt64(int_sqrt64(ir_Alpha * 1LL + TAdut4))
- 27315 - Hb_customer) * 10;
 }
 
+static s64 mlx90632_calc_ta4(s64 TAdut, s64 scale)
+{
+   return (div64_s64(TAdut, scale) + 27315) *
+   (div64_s64(TAdut, scale) + 27315) *
+   (div64_s64(TAdut, scale) + 27315) *
+   (div64_s64(TAdut, scale) + 27315);
+}
+
 static s32 mlx90632_calc_temp_object(s64 object, s64 ambient, s32 Ea, s32 Eb,
 s32 Fa, s32 Fb, s32 Ga, s16 Ha, s16 Hb,
 u16 tmp_emi)
 {
-   s64 kTA, kTA0, TAdut;
+   s64 kTA, kTA0, TAdut, TAdut4;
s64 temp = 25000;
s8 i;
 
kTA = (Ea * 1000LL) >> 16LL;
kTA0 = (Eb * 1000LL) >> 8LL;
TAdut = div64_s64(((ambient - kTA0) * 100LL), kTA) + 25 * 100LL;
+   TAdut4 = mlx90632_calc_ta4(TAdut, 1LL);
 
/* Iterations of calculation as described in datasheet */
for (i = 0; i < 5; ++i) {
-   temp = mlx90632_calc_temp_object_iteration(temp, object, TAdut,
+   temp = mlx90632_calc_temp_object_iteration(temp, object, TAdut, 
TAdut4,
   Fa, Fb, Ga, Ha, Hb,
   tmp_emi);
}
-- 
2.25.1

drivers/md/dm-mpath.c:524 multipath_clone_and_map() error: double unlocked 'm->lock' (orig line 516)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 374117ad4736c5a4f8012cfe59fc07d9d58191d5 dm mpath: use double checked 
locking in fast path
date:   4 weeks ago
config: arm-randconfig-m031-20200808 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0

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

New smatch warnings:
drivers/md/dm-mpath.c:524 multipath_clone_and_map() error: double unlocked 
'm->lock' (orig line 516)

Old smatch warnings:
drivers/md/dm-mpath.c:446 choose_pgpath() error: double unlocked 'm->lock' 
(orig line 416)
drivers/md/dm-mpath.c:457 choose_pgpath() error: double unlocked 'm->lock' 
(orig line 403)
drivers/md/dm-mpath.c:525 multipath_clone_and_map() error: double unlocked 
'm->lock' (orig line 516)
drivers/md/dm-mpath.c:526 multipath_clone_and_map() error: double unlocked 
'm->lock' (orig line 524)
drivers/md/dm-mpath.c:626 __map_bio() error: double unlocked 'm->lock' (orig 
line 615)
drivers/md/dm-mpath.c:627 __map_bio() error: double unlocked 'm->lock' (orig 
line 615)
drivers/md/dm-mpath.c:628 __map_bio() error: double unlocked 'm->lock' (orig 
line 626)
drivers/md/dm-mpath.c:629 __map_bio() error: double unlocked 'm->lock' (orig 
line 628)
drivers/md/dm-mpath.c:1607 pg_init_done() error: double unlocked 'm->lock' 
(orig line 1560)
drivers/md/dm-mpath.c:1707 multipath_end_io_bio() error: double unlocked 
'm->lock' (orig line 1704)
drivers/md/dm-mpath.c:1988 multipath_prepare_ioctl() error: double unlocked 
'm->lock' (orig line 1984)
drivers/md/dm-mpath.c:2012 multipath_prepare_ioctl() error: double unlocked 
'm->lock' (orig line 2001)

vim +524 drivers/md/dm-mpath.c

   498  
   499  /*
   500   * Map cloned requests (request-based multipath)
   501   */
   502  static int multipath_clone_and_map(struct dm_target *ti, struct request 
*rq,
   503 union map_info *map_context,
   504 struct request **__clone)
   505  {
   506  struct multipath *m = ti->private;
   507  size_t nr_bytes = blk_rq_bytes(rq);
   508  struct pgpath *pgpath;
   509  struct block_device *bdev;
   510  struct dm_mpath_io *mpio = get_mpio(map_context);
   511  struct request_queue *q;
   512  struct request *clone;
   513  
   514  /* Do we need to select a new pgpath? */
   515  pgpath = READ_ONCE(m->current_pgpath);
 > 516  if (!pgpath || !mpath_double_check_test_bit(MPATHF_QUEUE_IO, m))
   517  pgpath = choose_pgpath(m, nr_bytes);
   518  
   519  if (!pgpath) {
   520  if (must_push_back_rq(m))
   521  return DM_MAPIO_DELAY_REQUEUE;
   522  dm_report_EIO(m);   /* Failed */
   523  return DM_MAPIO_KILL;
 > 524  } else if (mpath_double_check_test_bit(MPATHF_QUEUE_IO, m) ||
   525 mpath_double_check_test_bit(MPATHF_PG_INIT_REQUIRED, 
m)) {
   526  pg_init_all_paths(m);
   527  return DM_MAPIO_DELAY_REQUEUE;
   528  }
   529  
   530  mpio->pgpath = pgpath;
   531  mpio->nr_bytes = nr_bytes;
   532  
   533  bdev = pgpath->path.dev->bdev;
   534  q = bdev_get_queue(bdev);
   535  clone = blk_get_request(q, rq->cmd_flags | REQ_NOMERGE,
   536  BLK_MQ_REQ_NOWAIT);
   537  if (IS_ERR(clone)) {
   538  /* EBUSY, ENODEV or EWOULDBLOCK: requeue */
   539  if (blk_queue_dying(q)) {
   540  atomic_inc(&m->pg_init_in_progress);
   541  activate_or_offline_path(pgpath);
   542  return DM_MAPIO_DELAY_REQUEUE;
   543  }
   544  
   545  /*
   546   * blk-mq's SCHED_RESTART can cover this requeue, so we
   547   * needn't deal with it by DELAY_REQUEUE. More 
importantly,
   548   * we have to return DM_MAPIO_REQUEUE so that blk-mq can
   549   * get the queue busy feedback (via BLK_STS_RESOURCE),
   550   * otherwise I/O merging can suffer.
   551   */
   552  return DM_MAPIO_REQUEUE;
   553  }
   554  clone->bio = clone->biotail = NULL;
   555  clone->rq_disk = bdev->bd_disk;
   556  clone->cmd_flags |= REQ_FAILFAST_TRANSPORT;
   557  *__clone = clone;
   558  
   559  if (pgpath->pg->ps.type->start_io)
   560  pgpath->pg->ps.type->start_io

[PATCH v4 3/4] iio:temperature:mlx90632: Add kerneldoc to the internal struct

[Crt Mori]

Document internal/private struct for mlx90632 device.

Signed-off-by: Crt Mori 
---
 drivers/iio/temperature/mlx90632.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/temperature/mlx90632.c 
b/drivers/iio/temperature/mlx90632.c
index 049c1217a166..4e0131705c11 100644
--- a/drivers/iio/temperature/mlx90632.c
+++ b/drivers/iio/temperature/mlx90632.c
@@ -107,12 +107,23 @@
 #define MLX90632_SLEEP_DELAY_MS 3000 /**< Autosleep delay */
 #define MLX90632_EXTENDED_LIMIT 27000 /* Extended mode raw value limit */
 
+/**
+ * struct mlx90632_data - private data for the MLX90632 device
+ * @client: I2C client of the device
+ * @lock: Internal mutex for multiple reads for single measurement
+ * @regmap: Regmap of the device
+ * @emissivity: Object emissivity from 0 to 1000 where 1000 = 1.
+ * @mtyp: Measurement type physical sensor configuration for extended range
+ *calculations
+ * @object_ambient_temperature: Ambient temperature at object (might differ of
+ *  the ambient temperature of sensor.
+ */
 struct mlx90632_data {
struct i2c_client *client;
-   struct mutex lock; /* Multiple reads for single measurement */
+   struct mutex lock;
struct regmap *regmap;
u16 emissivity;
-   u8 mtyp; /* measurement type - to enable extended range calculations */
+   u8 mtyp;
u32 object_ambient_temperature;
 };
 
-- 
2.25.1

[PATCH v4 2/4] iio:temperature:mlx90632: Adding extended calibration option

[Crt Mori]

For some time the market wants medical grade accuracy in medical range,
while still retaining the declared accuracy outside of the medical range
within the same sensor. That is why we created extended calibration
which is automatically switched to when object temperature is too high.

This patch also introduces the object_ambient_temperature variable which
is needed for more accurate calculation of the object infra-red
footprint as sensor's ambient temperature might be totally different
than what the ambient temperature is at object and that is why we can
have some more errors which can be eliminated. Currently this temperature
is fixed at 25, but the interface to adjust it by user (with external
sensor or just IR measurement of the other object which acts as ambient),
will be introduced in another commit.

Signed-off-by: Crt Mori 
---
 drivers/iio/temperature/mlx90632.c | 212 -
 1 file changed, 210 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/temperature/mlx90632.c 
b/drivers/iio/temperature/mlx90632.c
index c3de10ba5b1e..049c1217a166 100644
--- a/drivers/iio/temperature/mlx90632.c
+++ b/drivers/iio/temperature/mlx90632.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -58,6 +59,8 @@
 /* Control register address - volatile */
 #define MLX90632_REG_CONTROL   0x3001 /* Control Register address */
 #define   MLX90632_CFG_PWR_MASKGENMASK(2, 1) /* PowerMode Mask 
*/
+#define   MLX90632_CFG_MTYP_MASK   GENMASK(8, 4) /* Meas select 
Mask */
+
 /* PowerModes statuses */
 #define MLX90632_PWR_STATUS(ctrl_val) (ctrl_val << 1)
 #define MLX90632_PWR_STATUS_HALT MLX90632_PWR_STATUS(0) /* hold */
@@ -65,6 +68,18 @@
 #define MLX90632_PWR_STATUS_STEP MLX90632_PWR_STATUS(2) /* step */
 #define MLX90632_PWR_STATUS_CONTINUOUS MLX90632_PWR_STATUS(3) /* continuous*/
 
+/* Measurement types */
+#define MLX90632_MTYP_MEDICAL 0
+#define MLX90632_MTYP_EXTENDED 17
+
+/* Measurement type select*/
+#define MLX90632_MTYP_STATUS(ctrl_val) (ctrl_val << 4)
+#define MLX90632_MTYP_STATUS_MEDICAL 
MLX90632_MTYP_STATUS(MLX90632_MTYP_MEDICAL)
+#define MLX90632_MTYP_STATUS_EXTENDED 
MLX90632_MTYP_STATUS(MLX90632_MTYP_EXTENDED)
+
+/* I2C command register - volatile */
+#define MLX90632_REG_I2C_CMD0x3005 /* I2C command Register address */
+
 /* Device status register - volatile */
 #define MLX90632_REG_STATUS0x3fff /* Device status register */
 #define   MLX90632_STAT_BUSY   BIT(10) /* Device busy indicator */
@@ -81,6 +96,8 @@
 /* Magic constants */
 #define MLX90632_ID_MEDICAL0x0105 /* EEPROM DSPv5 Medical device id */
 #define MLX90632_ID_CONSUMER   0x0205 /* EEPROM DSPv5 Consumer device id */
+#define MLX90632_ID_EXTENDED   0x0505 /* EEPROM DSPv5 Extended range device id 
*/
+#define MLX90632_ID_MASK   GENMASK(14, 0) /* DSP version and device ID in 
EE_VERSION */
 #define MLX90632_DSP_VERSION   5 /* DSP version */
 #define MLX90632_DSP_MASK  GENMASK(7, 0) /* DSP version in EE_VERSION */
 #define MLX90632_RESET_CMD 0x0006 /* Reset sensor (address or global) */
@@ -88,16 +105,20 @@
 #define MLX90632_REF_3 12LL /**< ResCtrlRef value of Channel 3 */
 #define MLX90632_MAX_MEAS_NUM  31 /**< Maximum measurements in list */
 #define MLX90632_SLEEP_DELAY_MS 3000 /**< Autosleep delay */
+#define MLX90632_EXTENDED_LIMIT 27000 /* Extended mode raw value limit */
 
 struct mlx90632_data {
struct i2c_client *client;
struct mutex lock; /* Multiple reads for single measurement */
struct regmap *regmap;
u16 emissivity;
+   u8 mtyp; /* measurement type - to enable extended range calculations */
+   u32 object_ambient_temperature;
 };
 
 static const struct regmap_range mlx90632_volatile_reg_range[] = {
regmap_reg_range(MLX90632_REG_I2C_ADDR, MLX90632_REG_CONTROL),
+   regmap_reg_range(MLX90632_REG_I2C_CMD, MLX90632_REG_I2C_CMD),
regmap_reg_range(MLX90632_REG_STATUS, MLX90632_REG_STATUS),
regmap_reg_range(MLX90632_RAM_1(0),
 MLX90632_RAM_3(MLX90632_MAX_MEAS_NUM)),
@@ -113,6 +134,7 @@ static const struct regmap_range mlx90632_read_reg_range[] 
= {
regmap_reg_range(MLX90632_EE_CTRL, MLX90632_EE_I2C_ADDR),
regmap_reg_range(MLX90632_EE_Ha, MLX90632_EE_Hb),
regmap_reg_range(MLX90632_REG_I2C_ADDR, MLX90632_REG_CONTROL),
+   regmap_reg_range(MLX90632_REG_I2C_CMD, MLX90632_REG_I2C_CMD),
regmap_reg_range(MLX90632_REG_STATUS, MLX90632_REG_STATUS),
regmap_reg_range(MLX90632_RAM_1(0),
 MLX90632_RAM_3(MLX90632_MAX_MEAS_NUM)),
@@ -199,6 +221,26 @@ static int mlx90632_perform_measurement(struct 
mlx90632_data *data)
return (reg_status & MLX90632_STAT_CYCLE_POS) >> 2;
 }
 
+static int mlx90632_set_meas_type(struct regmap *regmap, u8 type)
+{
+   int ret;
+
+   if ((type != MLX90632_MTYP_MEDICAL) && (type != MLX90632_MTYP_EXTENDED))
+   

[PATCH v4 4/4] iio:temperature:mlx90632: Convert polling while loops to do-while

[Crt Mori]

Reduce number of lines and improve readability to convert polling while
loops to do-while. The iopoll.h interface was not used, because we
require more than 20ms timeout, because time for sensor to perform a
measurement is around 10ms and it needs to perform measurements for each
channel (which currently is 3).

Signed-off-by: Crt Mori 
---
 drivers/iio/temperature/mlx90632.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/temperature/mlx90632.c 
b/drivers/iio/temperature/mlx90632.c
index 4e0131705c11..24ffcce9ad74 100644
--- a/drivers/iio/temperature/mlx90632.c
+++ b/drivers/iio/temperature/mlx90632.c
@@ -214,15 +214,13 @@ static int mlx90632_perform_measurement(struct 
mlx90632_data *data)
if (ret < 0)
return ret;
 
-   while (tries-- > 0) {
+   do {
ret = regmap_read(data->regmap, MLX90632_REG_STATUS,
  ®_status);
if (ret < 0)
return ret;
-   if (reg_status & MLX90632_STAT_DATA_RDY)
-   break;
usleep_range(1, 11000);
-   }
+   } while (!(reg_status & MLX90632_STAT_DATA_RDY) && tries--);
 
if (tries < 0) {
dev_err(&data->client->dev, "data not ready");
@@ -419,7 +417,7 @@ static int mlx90632_read_object_raw_extended(struct regmap 
*regmap, s16 *object_
 static int mlx90632_read_all_channel_extended(struct mlx90632_data *data, s16 
*object_new_raw,
  s16 *ambient_new_raw, s16 
*ambient_old_raw)
 {
-   int tries = 4;
+   int tries = 5;
int ret;
 
mutex_lock(&data->lock);
@@ -427,14 +425,13 @@ static int mlx90632_read_all_channel_extended(struct 
mlx90632_data *data, s16 *o
if (ret < 0)
goto read_unlock;
 
-   while (tries-- > 0) {
+   do {
ret = mlx90632_perform_measurement(data);
if (ret < 0)
goto read_unlock;
 
-   if (ret == 19)
-   break;
-   }
+   } while ((ret != 19) && tries--);
+
if (tries < 0) {
ret = -ETIMEDOUT;
goto read_unlock;
-- 
2.25.1

Aw: [PATCH 1/2] arm: dts: mt7623: move more display-related nodes to mt7623n.dtsi

[Frank Wunderlich]

Hi,

as i made a mistake in cover-letter, it is not assigned to the series.

to show its content, i send it here as comment (instead of resending the whole 
series):

based on series from David Woodhouse [1]
i moved more display-nodes out of mt7623.dtsi to new mt7623n.dtsi
and changed last part from my series [2] to add these nodes to this new dtsi

the depency of dtsi-dtsi-dts is already done for mt7623a, so i guess it's a good
way to use it for mt7623n too.

this first set is an RFC if all nodes are in right order and if it is wanted to 
move
them out as i have no technical document about mt7623a/n which describes which 
parts
are available on both or only on one of them

added MTK DRM Maintainer CK Hu, Ryder Lee and Sean Wang, maybe they can give me 
some advice
how to proceed further here

[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=329209
[2] https://patchwork.kernel.org/patch/11700699/

[PATCH for-fixes] MIPS: Loongson64: Do not override watch and ejtag feature

[Jiaxun Yang]

Do not override ejtag feature to 0 as Loongson 3A1000+ do have ejtag.
For watch, as KVM emulated CPU doesn't have watch feature, we should
not enable it unconditionally.

Signed-off-by: Jiaxun Yang 
---
This patch should go into mips-fixes tree as watch feature is blocking
KVM guest boot in some cases.
---
 arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h 
b/arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
index b6e9c99b85a5..eb181224eb4c 100644
--- a/arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
+++ b/arch/mips/include/asm/mach-loongson64/cpu-feature-overrides.h
@@ -26,7 +26,6 @@
 #define cpu_has_counter1
 #define cpu_has_dc_aliases (PAGE_SIZE < 0x4000)
 #define cpu_has_divec  0
-#define cpu_has_ejtag  0
 #define cpu_has_inclusive_pcaches  1
 #define cpu_has_llsc   1
 #define cpu_has_mcheck 0
@@ -42,7 +41,6 @@
 #define cpu_has_veic   0
 #define cpu_has_vint   0
 #define cpu_has_vtag_icache0
-#define cpu_has_watch  1
 #define cpu_has_wsbh   1
 #define cpu_has_ic_fills_f_dc  1
 #define cpu_hwrena_impl_bits   0xc000
-- 
2.28.0.rc1

[GIT PULL] IPMI bug fixes for 5.9

[Corey Minyard]

The following changes since commit a5dc8300df75e8b8384b4c82225f1e4a0b4d9b55:

  scripts/decode_stacktrace: warn when modpath is needed but is unset 
(2020-06-15 15:37:24 -0700)

are available in the Git repository at:

  https://github.com/cminyard/linux-ipmi.git tags/for-linus-5.9-1

for you to fetch changes up to 634b06def11cf7ecf6282c79735f08004e323983:

  ipmi/watchdog: add missing newlines when printing parameters by sysfs 
(2020-07-21 06:29:15 -0500)


Minor cleanups to the IPMI driver for 5.9

Nothing of any major consequence.  Duplicate code, some missing \n's in
sysfs files, some documentation and comment changes.

-corey


Jing Xiangfeng (1):
  ipmi: remve duplicate code in __ipmi_bmc_register()

Misono Tomohiro (2):
  Doc: driver-api: ipmi: Add description of alerts_broken module param
  ipmi: ssif: Remove finished TODO comment about SMBus alert

Xiongfeng Wang (1):
  ipmi/watchdog: add missing newlines when printing parameters by sysfs

 Documentation/driver-api/ipmi.rst   | 4 
 drivers/char/ipmi/ipmi_msghandler.c | 2 --
 drivers/char/ipmi/ipmi_ssif.c   | 5 -
 drivers/char/ipmi/ipmi_watchdog.c   | 9 +++--
 4 files changed, 11 insertions(+), 9 deletions(-)

[PATCH] fix arm64 build with lack of __cpu_logical_map exported

[Greg Kroah-Hartman]

Currently Linus's tree fails with the following build error on arm64
makeallmodconfig:
ERROR: modpost: "__cpu_logical_map" 
[drivers/cpufreq/tegra194-cpufreq.ko] undefined!

Seems that kernel.ci also notices this for the past 2 days:
https://lore.kernel.org/r/5f2c97ab.1c69fb81.160f4.0...@mx.google.com
https://lore.kernel.org/r/5f2ab734.1c69fb81.24b16.8...@mx.google.com

Fix this up by just exporting the symbol.  Don't know if it's the
"right" fix, but it solves the build error for my machines.

Reported-by: "kernelci.org bot" 
Signed-off-by: Greg Kroah-Hartman 


diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 87e81d29e6fb..b421a4756793 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -275,6 +275,7 @@ static int __init reserve_memblock_reserved_regions(void)
 arch_initcall(reserve_memblock_reserved_regions);
 
 u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
+EXPORT_SYMBOL_GPL(__cpu_logical_map);
 
 void __init __no_sanitize_address setup_arch(char **cmdline_p)
 {

arch/powerpc/platforms/powernv/opal-fadump.c:33:41: sparse: sparse: incorrect type in assignment (different base types)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: a20a8fa42def548f46c7e0401a94f62b8e595883 powerpc/fadump: define OPAL 
register/un-register callback functions
date:   11 months ago
config: powerpc64-randconfig-s032-20200808 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout a20a8fa42def548f46c7e0401a94f62b8e595883
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 

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


sparse warnings: (new ones prefixed by >>)

>> arch/powerpc/platforms/powernv/opal-fadump.c:33:41: sparse: sparse: 
>> incorrect type in assignment (different base types) @@ expected unsigned 
>> long long [usertype] boot_mem_dest_addr @@ got restricted __be64 const 
>> [usertype] dest @@
>> arch/powerpc/platforms/powernv/opal-fadump.c:33:41: sparse: expected 
>> unsigned long long [usertype] boot_mem_dest_addr
>> arch/powerpc/platforms/powernv/opal-fadump.c:33:41: sparse: got 
>> restricted __be64 const [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:58:33: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] dest @@ got unsigned long long [usertype] addr @@
   arch/powerpc/platforms/powernv/opal-fadump.c:58:33: sparse: expected 
restricted __be64 [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:58:33: sparse: got unsigned 
long long [usertype] addr
   arch/powerpc/platforms/powernv/opal-fadump.c:59:33: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] size @@ got unsigned long boot_memory_size @@
   arch/powerpc/platforms/powernv/opal-fadump.c:59:33: sparse: expected 
restricted __be64 [usertype] size
   arch/powerpc/platforms/powernv/opal-fadump.c:59:33: sparse: got unsigned 
long boot_memory_size
   arch/powerpc/platforms/powernv/opal-fadump.c:66:53: sparse: sparse: 
restricted __be64 degrades to integer
>> arch/powerpc/platforms/powernv/opal-fadump.c:118:56: sparse: sparse: 
>> incorrect type in argument 2 (different base types) @@ expected unsigned 
>> long long [usertype] src @@ got restricted __be64 [usertype] src @@
>> arch/powerpc/platforms/powernv/opal-fadump.c:118:56: sparse: expected 
>> unsigned long long [usertype] src
>> arch/powerpc/platforms/powernv/opal-fadump.c:118:56: sparse: got 
>> restricted __be64 [usertype] src
>> arch/powerpc/platforms/powernv/opal-fadump.c:119:56: sparse: sparse: 
>> incorrect type in argument 3 (different base types) @@ expected unsigned 
>> long long [usertype] dest @@ got restricted __be64 [usertype] dest @@
>> arch/powerpc/platforms/powernv/opal-fadump.c:119:56: sparse: expected 
>> unsigned long long [usertype] dest
>> arch/powerpc/platforms/powernv/opal-fadump.c:119:56: sparse: got 
>> restricted __be64 [usertype] dest
>> arch/powerpc/platforms/powernv/opal-fadump.c:120:56: sparse: sparse: 
>> incorrect type in argument 4 (different base types) @@ expected unsigned 
>> long long [usertype] size @@ got restricted __be64 [usertype] size @@
>> arch/powerpc/platforms/powernv/opal-fadump.c:120:56: sparse: expected 
>> unsigned long long [usertype] size
>> arch/powerpc/platforms/powernv/opal-fadump.c:120:56: sparse: got 
>> restricted __be64 [usertype] size

vim +33 arch/powerpc/platforms/powernv/opal-fadump.c

25  
26  static void opal_fadump_update_config(struct fw_dump *fadump_conf,
27const struct 
opal_fadump_mem_struct *fdm)
28  {
29  /*
30   * The destination address of the first boot memory region is 
the
31   * destination address of boot memory regions.
32   */
  > 33  fadump_conf->boot_mem_dest_addr = fdm->rgn[0].dest;
34  pr_debug("Destination address of boot memory regions: 
%#016llx\n",
35   fadump_conf->boot_mem_dest_addr);
36  
37  fadump_conf->fadumphdr_addr = fdm->fadumphdr_addr;
38  }
39  
40  /* Initialize kernel metadata */
41  static void opal_fadump_init_metadata(struct opal_fadump_mem_struct 
*fdm)
42  {
43  fdm->version = OPAL_FADUMP_VERS

Re: drivers/virtio/virtio_mem.c:1031 virtio_mem_mb_plug_any_sb() error: uninitialized symbol 'rc'.

[David Hildenbrand]

> Am 08.08.2020 um 13:39 schrieb kernel test robot :
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
> commit: 5f1f79bbc9e26fa9412fa9522f957bb8f030c442 virtio-mem: Paravirtualized 
> memory hotplug
> date:   9 weeks ago
> config: x86_64-randconfig-m001-20200808 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 

Was there a delay in sending these out? The fix by Dan is long upstream: 
1c3d69ab5348

> New smatch warnings:
> drivers/virtio/virtio_mem.c:1031 virtio_mem_mb_plug_any_sb() error: 
> uninitialized symbol 'rc'.
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:1607 
> calculate_bandwidth() warn: Function too hairy.  No more merges.
> 
> Old smatch warnings:
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3387 bw_calcs() 
> warn: inconsistent indenting
> 
> vim +/rc +1031 drivers/virtio/virtio_mem.c
> 
>   978
>   979/*
>   980 * Try to plug the desired number of subblocks of a memory block that
>   981 * is already added to Linux.
>   982 *
>   983 * Will modify the state of the memory block.
>   984 *
>   985 * Note: Can fail after some subblocks were successfully plugged.
>   986 */
>   987static int virtio_mem_mb_plug_any_sb(struct virtio_mem *vm, unsigned 
> long mb_id,
>   988 uint64_t *nb_sb, bool online)
>   989{
>   990unsigned long pfn, nr_pages;
>   991int sb_id, count;
>   992int rc;
>   993
>   994if (WARN_ON_ONCE(!*nb_sb))
>   995return -EINVAL;
>   996
>   997while (*nb_sb) {
>   998sb_id = virtio_mem_mb_first_unplugged_sb(vm, mb_id);
>   999if (sb_id >= vm->nb_sb_per_mb)
>  1000break;
>  1001count = 1;
>  1002while (count < *nb_sb &&
>  1003   sb_id + count < vm->nb_sb_per_mb &&
>  1004   !virtio_mem_mb_test_sb_plugged(vm, mb_id, sb_id + 
> count,
>  1005  1))
>  1006count++;
>  1007
>  1008rc = virtio_mem_mb_plug_sb(vm, mb_id, sb_id, count);
>  1009if (rc)
>  1010return rc;
>  1011*nb_sb -= count;
>  1012if (!online)
>  1013continue;
>  1014
>  1015/* fake-online the pages if the memory block is online */
>  1016pfn = PFN_DOWN(virtio_mem_mb_id_to_phys(mb_id) +
>  1017   sb_id * vm->subblock_size);
>  1018nr_pages = PFN_DOWN(count * vm->subblock_size);
>  1019virtio_mem_fake_online(pfn, nr_pages);
>  1020}
>  1021
>  1022if (virtio_mem_mb_test_sb_plugged(vm, mb_id, 0, 
> vm->nb_sb_per_mb)) {
>  1023if (online)
>  1024virtio_mem_mb_set_state(vm, mb_id,
>  1025VIRTIO_MEM_MB_STATE_ONLINE);
>  1026else
>  1027virtio_mem_mb_set_state(vm, mb_id,
>  1028VIRTIO_MEM_MB_STATE_OFFLINE);
>  1029}
>  1030
>> 1031return rc;
>  1032}
>  1033
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
> <.config.gz>

RE: [PATCH net-next v1] hinic: fix strncpy output truncated compile warnings

[David Laight]

From: luobin (L)
> Sent: 08 August 2020 04:37
> 
> On 2020/8/7 17:32, David Laight wrote:
> > From: Luo bin
> >> Sent: 07 August 2020 03:09
> >>
> >> fix the compile warnings of 'strncpy' output truncated before
> >> terminating nul copying N bytes from a string of the same length
> >>
> >> Signed-off-by: Luo bin 
> >> Reported-by: kernel test robot 
> >> ---
> >> V0~V1:
> >> - use the strlen()+1 pattern consistently
> >>
> >>  drivers/net/ethernet/huawei/hinic/hinic_devlink.c | 8 
> >>  1 file changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> >> b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> >> index c6adc776f3c8..1ec88ebf81d6 100644
> >> --- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> >> +++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c
> >> @@ -342,9 +342,9 @@ static int chip_fault_show(struct devlink_fmsg *fmsg,
> >>
> >>level = event->event.chip.err_level;
> >>if (level < FAULT_LEVEL_MAX)
> >> -  strncpy(level_str, fault_level[level], 
> >> strlen(fault_level[level]));
> >> +  strncpy(level_str, fault_level[level], 
> >> strlen(fault_level[level]) + 1);
> >
> > Have you even considered what that code is actually doing?
> >
> > David
>
> I'm sorry that I haven't got what you mean and I haven't found any defects in 
> that code. Can you
> explain more to me?

If you can't see it you probably shouldn't be submitting patches

Consider what happens when the string is long.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

[PATCH] usb: xhci-mtk: Fix typo

[Frank Wunderlich]

From: Frank Wunderlich 

fix this small typo u3_ports_disabed => u3_ports_disabled

Fixes: 55ba6e9e25a6 (usb: xhci-mtk: support option to disable usb3 ports)
Signed-off-by: Frank Wunderlich 
---
 drivers/usb/host/xhci-mtk.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 4311d4c9b68d..8f321f39ab96 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -77,7 +77,7 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
 {
struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
u32 value, check_val;
-   int u3_ports_disabed = 0;
+   int u3_ports_disabled = 0;
int ret;
int i;
 
@@ -92,7 +92,7 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
/* power on and enable u3 ports except skipped ones */
for (i = 0; i < mtk->num_u3_ports; i++) {
if ((0x1 << i) & mtk->u3p_dis_msk) {
-   u3_ports_disabed++;
+   u3_ports_disabled++;
continue;
}
 
@@ -117,7 +117,7 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
check_val = STS1_SYSPLL_STABLE | STS1_REF_RST |
STS1_SYS125_RST | STS1_XHCI_RST;
 
-   if (mtk->num_u3_ports > u3_ports_disabed)
+   if (mtk->num_u3_ports > u3_ports_disabled)
check_val |= STS1_U3_MAC_RST;
 
ret = readl_poll_timeout(&ippc->ip_pw_sts1, value,
-- 
2.25.1

Re: drivers/dma/pl330.c:2981:9: warning: Identical condition 'ret', second condition is always false

[Vinod Koul]

On 08-08-20, 10:53, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   30185b69a2d533c4ba6ca926b8390ce7de495e29
> commit: a39cddc9e3775100100a4272feed64faac831be9 dmaengine: pl330: Drop 
> boilerplate code for suspend/resume
> date:   8 months ago
> compiler: aarch64-linux-gcc (GCC) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> 
> cppcheck warnings: (new ones prefixed by >>)
> 
> >> drivers/dma/pl330.c:2981:9: warning: Identical condition 'ret', second 
> >> condition is always false [identicalConditionAfterEarlyExit]
> return ret;
>^
>drivers/dma/pl330.c:2976:6: note: first condition
> if (ret)
> ^
>drivers/dma/pl330.c:2981:9: note: second condition
> return ret;

This one could be fixed by making this as return 0, but is harmless


>^
> >> drivers/dma/pl330.c:2798:23: warning: Variable 'desc->rqcfg.brst_len' is 
> >> reassigned a value before the old one has been used. [redundantAssignment]
> desc->rqcfg.brst_len = get_burst_len(desc, len);
>  ^
>drivers/dma/pl330.c:2796:24: note: Variable 'desc->rqcfg.brst_len' is 
> reassigned a value before the old one has been used.
>  desc->rqcfg.brst_len = 1;
>   ^
>drivers/dma/pl330.c:2798:23: note: Variable 'desc->rqcfg.brst_len' is 
> reassigned a value before the old one has been used.
> desc->rqcfg.brst_len = get_burst_len(desc, len);

This one actually seems like a bug. Reading the code I think
get_burst_len() should be called first before checking if burst size is
smaller and setting to 1 in that case

Sugar Zhang, Marek Szyprowski can you folks check this?

>  ^
> 
> vim +/ret +2981 drivers/dma/pl330.c
> 
> 42bc9cf45939c2 Boojin Kim  2011-09-02  2753  
> b3040e40675ec2 Jassi Brar  2010-05-23  2754  static struct 
> dma_async_tx_descriptor *
> b3040e40675ec2 Jassi Brar  2010-05-23  2755  
> pl330_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dst,
> b3040e40675ec2 Jassi Brar  2010-05-23  2756   dma_addr_t src, 
> size_t len, unsigned long flags)
> b3040e40675ec2 Jassi Brar  2010-05-23  2757  {
> b3040e40675ec2 Jassi Brar  2010-05-23  2758   struct dma_pl330_desc 
> *desc;
> b3040e40675ec2 Jassi Brar  2010-05-23  2759   struct dma_pl330_chan 
> *pch = to_pchan(chan);
> f5636854f3fcee Maninder Singh  2015-05-26  2760   struct pl330_dmac 
> *pl330;
> b3040e40675ec2 Jassi Brar  2010-05-23  2761   int burst;
> b3040e40675ec2 Jassi Brar  2010-05-23  2762  
> 4e0e6109a1cc18 Rob Herring 2011-07-25  2763   if (unlikely(!pch || 
> !len))
> b3040e40675ec2 Jassi Brar  2010-05-23  2764   return NULL;
> b3040e40675ec2 Jassi Brar  2010-05-23  2765  
> f5636854f3fcee Maninder Singh  2015-05-26  2766   pl330 = pch->dmac;
> f5636854f3fcee Maninder Singh  2015-05-26  2767  
> b3040e40675ec2 Jassi Brar  2010-05-23  2768   desc = 
> __pl330_prep_dma_memcpy(pch, dst, src, len);
> b3040e40675ec2 Jassi Brar  2010-05-23  2769   if (!desc)
> b3040e40675ec2 Jassi Brar  2010-05-23  2770   return NULL;
> b3040e40675ec2 Jassi Brar  2010-05-23  2771  
> b3040e40675ec2 Jassi Brar  2010-05-23  2772   desc->rqcfg.src_inc = 1;
> b3040e40675ec2 Jassi Brar  2010-05-23  2773   desc->rqcfg.dst_inc = 1;
> 9dc5a315fe515e Lars-Peter Clausen  2014-07-06  2774   desc->rqtype = 
> DMA_MEM_TO_MEM;
> b3040e40675ec2 Jassi Brar  2010-05-23  2775  
> b3040e40675ec2 Jassi Brar  2010-05-23  2776   /* Select max possible 
> burst size */
> f6f2421c0a1cb6 Lars-Peter Clausen  2014-07-06  2777   burst = 
> pl330->pcfg.data_bus_width / 8;
> b3040e40675ec2 Jassi Brar  2010-05-23  2778  
> 137bd11090d89b Jon Medhurst2014-11-07  2779   /*
> 137bd11090d89b Jon Medhurst2014-11-07  2780* Make sure we use a 
> burst size that aligns with all the memcpy
> 137bd11090d89b Jon Medhurst2014-11-07  2781* parameters because 
> our DMA programming algorithm doesn't cope with
> 137bd11090d89b Jon Medhurst2014-11-07  2782* transfers which 
> straddle an entry in the DMA device's MFIFO.
> 137bd11090d89b Jon Medhurst2014-11-07  2783*/
> 137bd11090d89b Jon Medhurst2014-11-07  2784   while ((src | dst | 
> len) & (burst - 1))
> b3040e40675ec2 Jassi Brar  2010-05-23  2785   burst /= 2;
> b3040e40675ec2 Jassi Brar  2010-05-23  2786  
> b3040e40675ec2 Jassi Brar  2010-05-23  2787   desc->rqcfg.brst_size = 
> 0;
> b3040e40675ec2 Jassi Brar  2010-05-23  2788   while (burst != (1 << 
> desc->rqcfg.brst_size))
> b3040e40675ec2 Jassi Brar  2010-05-23  2789   
> desc->rqcfg.brst_size++;
> b3040e40675ec2 Jassi Brar  2010-05-23  2790  
> 137

Re: linux plumbers + clang + s390 virtualized testing

[Vasily Gorbik]

On Thu, Aug 06, 2020 at 12:02:52PM -0700, Nick Desaulniers wrote:
> On Wed, Jul 29, 2020 at 6:51 AM Vasily Gorbik  wrote:
> >
> > > > We were very excited to see your patches going by for enabling Clang
> > > > support for s390.  Since then, we've added s390 builds to our
> > > > continuous integration setup.
> > > >
> > > > We've been running into a few issues with doing virtualized boot tests
> > > > of our kernels on s390.
> > > >
> > > > I was curious if you'll both be attending Linux plumbers conf?  If we
> > > > carve out time for an s390+clang talk, would this be of interest to
> > > > you to attend?
> > I will attend and it would surely be interesting to me and other
> > s390 folks. Your efforts are greatly appreciated!
> 
> Cool, so our MC has been approved:
> https://www.linuxplumbersconf.org/event/7/page/80-accepted-microconferences#llvm-cr
> 
> But we're super tight on time and probably won't be able to do a
> session on s390 at the MC.  That said, I have just submitted a BoF
> proposal since we have more topics internal to our group we'd like to
> have more time to discuss.  I've added s390 testing to the list of
> potential topics, too.  I'll re-ping this thread once I hear back
> about whether it gets approved or not.
> 
> That said, we do meet once every other week virtually online, see
> links: https://clangbuiltlinux.github.io/.
> 
> >
> > BTW I believe basic Clang support for s390 came earlier in 5.2 with
> > a lot of efforts from Arnd Bergmann.
> >
> > My part was fixing recent breakages and bugging our s390 clang team
> > (which did all the great work) to get kernel specific features support
> > in clang 10 and 11 to reach features parity with gcc. And eventually
> > doing few adjustments so that features which came with clang 10 and
> > 11 are working smoothly. That is s390 "asm goto" support and specific
> > compiler flags for ftrace support and stack packing.
> 
> That's awesome; I'd love to get the chance to meet your s390 LLVM
> team; in general it can take a while to get bugs routed to folks most
> empowered to fix them until you know who they are.
> 
> Would you, any fellow s390 kernel and LLVM folks be interested in
> attending one of our virtual meetings, even if it's just to say "hi"
> quickly? Next one is next Wednesday.
> 
> Usually we go over whatever firedrills we've been running the past two
> weeks, but sometimes have presentations of folks projects and
> research.  I think it would be cool to get more background on s390 and
> work out the issues we're running into with testing.

I've added few more people in To. We'll try to make it next Wednesday,
but no promises since we are based in Germany and this is quite late
for us.

Re: [PATCH] mm/memcg: remove useless check on page->mem_cgroup

[Alex Shi]

在 2020/8/5 下午9:02, Alex Shi 写道:
> 
> 
> 在 2020/8/5 下午8:28, Alex Shi 写道:
>> The last patch has a problem on define. this version could fix it.
>>
>> BTW, I see some !memcg happens when MEMCG compilered but disabled by 
>> cgroup_disable
>>
>>
>> [   94.657666] ---[ end trace f1f34bfc3b32ed2f ]---
>> [   95.138995] anon flags: 0x5005b48008000d(locked|uptodate|dirty|swapbacked)
>> [   95.146220] raw: 005005b48008000d dead0100 dead0122 
>> 8897c7c76ad1
>> [   95.154549] raw: 0022  0002 
>> 
>> [   95.162876] page dumped because: VM_WARN_ON_ONCE_PAGE(!memcg)
>>
>>
> 
> The following patch may helpful.

Any comments for the 2 patches?

Thanks
Alex

> 
> From 8bfb26a2e37e08dc61d20212bcfa5812a367ba94 Mon Sep 17 00:00:00 2001
> From: Alex Shi 
> Date: Wed, 5 Aug 2020 20:32:12 +0800
> Subject: [PATCH] mm/memcg: don't try charge swap if memcg disabled
> 
> If we disabled memcg by cgroup_disable=memory, the swap charges are
> still called. Let's return from the funcs earlier and keep WARN_ON
> monitor.
> 
> Signed-off-by: Alex Shi 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Vladimir Davydov 
> Cc: Andrew Morton 
> Cc: cgro...@vger.kernel.org
> Cc: linux...@kvack.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  mm/memcontrol.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index cb07a48d53aa..65f2b42d25af 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -7163,6 +7163,9 @@ void mem_cgroup_swapout(struct page *page, swp_entry_t 
> entry)
>   VM_BUG_ON_PAGE(PageLRU(page), page);
>   VM_BUG_ON_PAGE(page_count(page), page);
>  
> + if (mem_cgroup_disabled())
> + return;
> +
>   if (cgroup_subsys_on_dfl(memory_cgrp_subsys))
>   return;
>  
> @@ -7228,6 +7231,9 @@ int mem_cgroup_try_charge_swap(struct page *page, 
> swp_entry_t entry)
>   struct mem_cgroup *memcg;
>   unsigned short oldid;
>  
> + if (mem_cgroup_disabled())
> + return 0;
> +
>   if (!cgroup_subsys_on_dfl(memory_cgrp_subsys))
>   return 0;
>  
> 

Re: Removal of HCI commands? (Was: Re: OCF_READ_LOCAL_CODECS is permitted only for root user)

[Pali Rohár]

On Wednesday 15 April 2020 00:56:18 Pali Rohár wrote:
> On Sunday 09 February 2020 14:21:37 Pali Rohár wrote:
> > On Saturday 04 January 2020 11:24:36 Pali Rohár wrote:
> > > On Saturday 04 January 2020 10:44:52 Marcel Holtmann wrote:
> > > > Hi Pali,
> > > > 
> > > > > I wrote a simple script "sco_features.pl" which show all supported
> > > > > codecs by local HCI bluetooth adapter. Script is available at:
> > > > > 
> > > > > https://github.com/pali/hsphfpd-prototype/blob/prototype/sco_features.pl
> > > > > 
> > > > > And I found out that OCF_READ_LOCAL_CODECS HCI command cannot be send 
> > > > > by
> > > > > non-root user. Kernel returns "Operation not permitted" error.
> > > > > 
> > > > > What is reason that kernel blocks OCF_READ_LOCAL_CODECS command for
> > > > > non-root users? Without it (audio) application does not know which
> > > > > codecs local bluetooth adapter supports.
> > > > > 
> > > > > E.g. OCF_READ_LOCAL_EXT_FEATURES or OCF_READ_VOICE_SETTING commands 
> > > > > can
> > > > > be send also by non-root user and kernel does not block them.
> > > > 
> > > > actually the direct access to HCI commands is being removed. So we have 
> > > > no plans to add new commands into the list since that it what the 
> > > > kernel is suppose to handle. If we wanted to expose this, then it has 
> > > > to be via mgmt.
> > > 
> > > Hi Marcel! Thank you for information. I have not know that this API is
> > > "deprecated" and is going to be removed. But userspace audio
> > > applications need to know what bluetooth adapter supports, so can you
> > > export result of these commands to userspace? My script linked above
> > > calls: OCF_READ_VOICE_SETTING, OCF_READ_LOCAL_COMMANDS,
> > > OCF_READ_LOCAL_EXT_FEATURES, OCF_READ_LOCAL_CODECS
> > 
> > Hello! Just a gently reminder for this question. How to retrieve
> > information about supported codecs from userspace by non-root user?
> > Because running all bluetooth audio applications by root is not really a
> > solution. Plus if above API for root user is going to be removed, what
> > is a replacement?
> 
> Hello!
> 
> I have not got any answer to my email from Marcel for months, so I'm
> adding other developers to loop. Could somebody tell me that is the
> replacement API if above one is going to be removed?
> 
> I was not able to find any documentation where could be described this
> API nor information about deprecation / removal.
> 
> And are you aware of the fact that removing of API could potentially
> break existing applications?
> 
> I really need to know which API should I use, because when I use API
> which is going to be removed, then my application stops working. And I
> really want to avoid it.
> 
> Also I have not got any response yet, how can I read list of supported
> codecs by bluetooth adapter by ordinary non-root user? Audio application
> needs to know list of supported codecs and it is really insane to run it
> as root.

Hello! This is just another reminder that I have not got any reply to
this email.

Does silence mean that audio applications are expected to work only
under root account and ordinary users are not able to use audio and list
supported codecs?

Re: [PATCH] gpu/drm: Remove TTM_PL_FLAG_WC of VRAM to fix writecombine issue for Loongson64

[Thomas Bogendoerfer]

On Sat, Aug 08, 2020 at 03:25:02PM +0800, Tiezhu Yang wrote:
> Loongson processors have a writecombine issue that maybe failed to
> write back framebuffer used with ATI Radeon or AMD GPU at times,
> after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine
> mapping for MIPS"), there exists some errors such as blurred screen
> and lockup, and so on.
> 
> Remove the flag TTM_PL_FLAG_WC of VRAM to fix writecombine issue for
> Loongson64 to work well with ATI Radeon or AMD GPU, and it has no any
> influence on the other platforms.

well it's not my call to take or reject this patch, but I already
indicated it might be better to disable writecombine on the CPU
detection side (or do you have other devices where writecombining
works ?). Something like below will disbale it for all loongson64 CPUs.
If you now find out where it works and where it doesn't, you can even
reduce it to the required minium of affected CPUs.

Thomas.


diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index def1659fe262..cdd87009e931 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -2043,7 +2043,6 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips 
*c, unsigned int cpu)
set_isa(c, MIPS_CPU_ISA_M64R2);
break;
}
-   c->writecombine = _CACHE_UNCACHED_ACCELERATED;
c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_EXT |
MIPS_ASE_LOONGSON_EXT2);
break;
@@ -2073,7 +2072,6 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips 
*c, unsigned int cpu)
 * register, we correct it here.
 */
c->options |= MIPS_CPU_FTLB | MIPS_CPU_TLBINV | MIPS_CPU_LDPTE;
-   c->writecombine = _CACHE_UNCACHED_ACCELERATED;
c->ases |= (MIPS_ASE_LOONGSON_MMI | MIPS_ASE_LOONGSON_CAM |
MIPS_ASE_LOONGSON_EXT | MIPS_ASE_LOONGSON_EXT2);
c->ases &= ~MIPS_ASE_VZ; /* VZ of Loongson-3A2000/3000 is 
incomplete */
@@ -2084,7 +2082,6 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips 
*c, unsigned int cpu)
set_elf_platform(cpu, "loongson3a");
set_isa(c, MIPS_CPU_ISA_M64R2);
decode_cpucfg(c);
-   c->writecombine = _CACHE_UNCACHED_ACCELERATED;
break;
default:
panic("Unknown Loongson Processor ID!");

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]

[PATCH] ext4: use kmemdup_nul() instead of kstrndup()

[Xianting Tian]

kmemdup_nul() is more efficient than kmemdup_nul() if
the size is known exactly.

The description of kstrndup() already suggested:
Note: Use kmemdup_nul() instead if the size is known exactly.

Signed-off-by: Xianting Tian 
---
 fs/ext4/super.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 330957e..be37556 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4016,7 +4016,7 @@ static int ext4_fill_super(struct super_block *sb, void 
*data, int silent)
}
 
if (sbi->s_es->s_mount_opts[0]) {
-   char *s_mount_opts = kstrndup(sbi->s_es->s_mount_opts,
+   char *s_mount_opts = kmemdup_nul(sbi->s_es->s_mount_opts,
  sizeof(sbi->s_es->s_mount_opts),
  GFP_KERNEL);
if (!s_mount_opts)
-- 
1.8.3.1

Re: [PATCH v3] hwmon/pmbus: use simple i2c probe function

[Guenter Roeck]

On 8/7/20 11:53 PM, Stephen Kitt wrote:
> On Fri, 7 Aug 2020 21:07:07 +0200, Stephen Kitt  wrote:
> 
>> On Fri, 7 Aug 2020 10:32:31 -0700, Guenter Roeck  wrote:
>>> On Fri, Aug 07, 2020 at 06:28:01PM +0200, Stephen Kitt wrote:  
  
 -static int ltc2978_probe(struct i2c_client *client,
 -   const struct i2c_device_id *id)
 +static int ltc2978_probe(struct i2c_client *client)
  {
int i, chip_id;
struct ltc2978_data *data;
 @@ -670,10 +669,10 @@ static int ltc2978_probe(struct i2c_client
 *client, return chip_id;
  
data->id = chip_id;
 -  if (data->id != id->driver_data)
 +  if (strcmp(client->name, ltc2978_id[data->id].name) != 0)
>>>
>>> I was about to apply this patch, but this is problematic: It assumes that
>>> __stringify(id) == ltc2978_id[id].name and that ltc2978_id[id].driver_data
>>> == id. While that is curently the case (as far as I can see), it is still
>>> unsafe. I think it would be much safer to use i2c_match_id() here.  
>>
>> I’m not following the __stringify assumption
> [...]
> 
> I get it, the code assumes there’s a bijection between the set of names and
> the set of driver_data values. So effectively we can’t log the detected name
> based on the chip_id...

Exactly.

Thanks,
Guenter



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] gpu/drm: Remove TTM_PL_FLAG_WC of VRAM to fix writecombine issue for Loongson64

[Jiaxun Yang]

在 2020/8/8 下午9:41, Thomas Bogendoerfer 写道:

On Sat, Aug 08, 2020 at 03:25:02PM +0800, Tiezhu Yang wrote:

Loongson processors have a writecombine issue that maybe failed to
write back framebuffer used with ATI Radeon or AMD GPU at times,
after commit 8a08e50cee66 ("drm: Permit video-buffers writecombine
mapping for MIPS"), there exists some errors such as blurred screen
and lockup, and so on.

Remove the flag TTM_PL_FLAG_WC of VRAM to fix writecombine issue for
Loongson64 to work well with ATI Radeon or AMD GPU, and it has no any
influence on the other platforms.

well it's not my call to take or reject this patch, but I already
indicated it might be better to disable writecombine on the CPU
detection side (or do you have other devices where writecombining
works ?). Something like below will disbale it for all loongson64 CPUs.
If you now find out where it works and where it doesn't, you can even
reduce it to the required minium of affected CPUs.

Hi Tiezhu, Thomas,

Yes, writecombine works well on LS7A's internal GPU
And even works well with some AMD GPUs (in my case, RX550).

Tiezhu, is it possible to investigate the issue deeper in Loongson?
Probably we just need to add some barrier to maintain the data coherency,
or disable writecombine for AMD GPU's command buffer and leave texture/frame
buffer wc accelerated.

Thanks.

- Jiaxun

RE: [PATCH 25/26] net: pass a sockptr_t into ->setsockopt

[David Laight]

From: Eric Dumazet
> Sent: 07 August 2020 19:29
> 
> On 8/7/20 2:18 AM, David Laight wrote:
> > From: Eric Dumazet
> >> Sent: 06 August 2020 23:21
> >>
> >> On 7/22/20 11:09 PM, Christoph Hellwig wrote:
> >>> Rework the remaining setsockopt code to pass a sockptr_t instead of a
> >>> plain user pointer.  This removes the last remaining set_fs(KERNEL_DS)
> >>> outside of architecture specific code.
> >>>
> >>> Signed-off-by: Christoph Hellwig 
> >>> Acked-by: Stefan Schmidt  [ieee802154]
> >>> ---
> >>
> >>
> >> ...
> >>
> >>> diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
> >>> index 594e01ad670aa6..874f01cd7aec42 100644
> >>> --- a/net/ipv6/raw.c
> >>> +++ b/net/ipv6/raw.c
> >>> @@ -972,13 +972,13 @@ static int rawv6_sendmsg(struct sock *sk, struct 
> >>> msghdr *msg, size_t len)
> >>>  }
> >>>
> >>
> >> ...
> >>
> >>>  static int do_rawv6_setsockopt(struct sock *sk, int level, int optname,
> >>> - char __user *optval, unsigned int optlen)
> >>> +sockptr_t optval, unsigned int optlen)
> >>>  {
> >>>   struct raw6_sock *rp = raw6_sk(sk);
> >>>   int val;
> >>>
> >>> - if (get_user(val, (int __user *)optval))
> >>> + if (copy_from_sockptr(&val, optval, sizeof(val)))
> >>>   return -EFAULT;
> >>>
> >>
> >> converting get_user(...)   to  copy_from_sockptr(...) really assumed the 
> >> optlen
> >> has been validated to be >= sizeof(int) earlier.
> >>
> >> Which is not always the case, for example here.
> >>
> >> User application can fool us passing optlen=0, and a user pointer of 
> >> exactly TASK_SIZE-1
> >
> > Won't the user pointer force copy_from_sockptr() to call
> > copy_from_user() which will then do access_ok() on the entire
> > range and so return -EFAULT.
> >
> > The only problems arise if the kernel code adds an offset to the
> > user address.
> > And the later patch added an offset to the copy functions.
> 
> I dunno, I definitely got the following syzbot crash
> 
> No repro found by syzbot yet, but I suspect a 32bit binary program
> did :
> 
> setsockopt(fd, 0x29, 0x24, 0x, 0x0)

A few too many ffs...

> BUG: KASAN: wild-memory-access in memcpy include/linux/string.h:406 [inline]
> BUG: KASAN: wild-memory-access in copy_from_sockptr_offset 
> include/linux/sockptr.h:71 [inline]
> BUG: KASAN: wild-memory-access in copy_from_sockptr 
> include/linux/sockptr.h:77 [inline]
> BUG: KASAN: wild-memory-access in do_rawv6_setsockopt net/ipv6/raw.c:1023 
> [inline]
> BUG: KASAN: wild-memory-access in rawv6_setsockopt+0x1a1/0x6f0 
> net/ipv6/raw.c:1084
> Read of size 4 at addr  by task syz-executor.0/28251

Yep, the code is nearly, but not quite right.
The problem is almost certainly that access_ok(x, 0) always returns success.

In any case the check for a valid user address ought to be exactly
the same one that later selects between copy_to/from_user() and memcpy().

The latter compares the address against 'TASK_SIZE'.
However that isn't the right value either - I think it reads
the value from 'current' that set_fs() sets.
What this code needs is any address that is above the highest
user address and below (or equal to) to lowest kernel one.

On i386 (and probably most 32bit linux) this is 0xc000.
On x86-64 this could be any address in the address 'black hole'.
Picking 1ull<<63 may be best.
Quite what the correct #define is requires further research.

There is actually scope for making init_user_sockptr(kern_address)
save a value that will cause copy_to/from_sockptr() go into
the user-copy path with an address that access_ok() will reject.
Then the -EFAULT will get generated in the 'expected' place
and there is no scope for failing to test it's return value.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

Re: [ANNOUNCE] v4.4.231-rt202

[Joe Korty]

Ping?

On Mon, Jul 27, 2020 at 03:10:33PM -0400, Steven Rostedt wrote:
> On Sun, 26 Jul 2020 13:55:12 +0200
> Daniel Wagner  wrote:
> 
> > Hi,
> > 
> > On 24.07.20 15:41, Daniel Wagner wrote:
> > > Known issues:
> > > 
> > > sigwaittest with hackbench as workload is able to trigger a crash on 
> > > x86_64,
> > > the same as reported for the v4.4.220-rt196 release. As it turns
> > > out it was not triggered by BPF.
> > > https://paste.opensuse.org/view/raw/58939248  
> > 
> > Joe pointed out [1] that v4.4-rt is missing 9567db2ebe56 ("signal: 
> > Prevent double-free of user struct") from devel-rt. With this
> > patch all my tests pass.
> > 
> > @stable-rt team: Can you please add it to the missing trees?
> 
> Good catch,
> 
> I'll pull this in on Friday.
> 
> -- Steve
> 
> > 
> > Thanks,
> > Daniel
> > 
> > [1] 
> > https://lore.kernel.org/linux-rt-users/20200626130544.ga37...@zipoli.concurrent-rt.com/

Re: [PATCH] Replace HTTP links with HTTPS ones: AUXILIARY DISPLAY DRIVERS

[Miguel Ojeda]

Hi Alexander,

On Wed, Jul 8, 2020 at 2:56 PM Alexander A. Klimov
 wrote:
>
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
>   If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
>
> Signed-off-by: Alexander A. Klimov 

Thanks! Queuing it up.

Cheers,
Miguel

[rcu:dev.2020.08.05a] BUILD SUCCESS 3893c86425fd2f1480d8740aa6b9f55e72497c4d

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
dev.2020.08.05a
branch HEAD: 3893c86425fd2f1480d8740aa6b9f55e72497c4d  rcu: Provide optional 
RCU-reader exit delay for strict GPs

elapsed time: 723m

configs tested: 75
configs skipped: 3

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

arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
s390   zfcpdump_defconfig
mipsworkpad_defconfig
sh  defconfig
powerpc powernv_defconfig
h8300alldefconfig
x86_64   allyesconfig
powerpc  mgcoge_defconfig
arm palmz72_defconfig
powerpc mpc83xx_defconfig
xtensa   common_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
powerpc defconfig
i386 randconfig-a004-20200808
i386 randconfig-a005-20200808
i386 randconfig-a001-20200808
i386 randconfig-a003-20200808
i386 randconfig-a002-20200808
i386 randconfig-a006-20200808
x86_64   randconfig-a013-20200807
x86_64   randconfig-a011-20200807
x86_64   randconfig-a012-20200807
x86_64   randconfig-a016-20200807
x86_64   randconfig-a015-20200807
x86_64   randconfig-a014-20200807
i386 randconfig-a011-20200808
i386 randconfig-a014-20200808
i386 randconfig-a015-20200808
i386 randconfig-a013-20200808
i386 randconfig-a012-20200808
i386 randconfig-a016-20200808
riscvallyesconfig
riscv allnoconfig
riscv   defconfig
riscvallmodconfig
x86_64   rhel
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

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

Lieber Freund (Assalamu Alaikum),?

[Aisha Gaddafi]

-- 
Lieber Freund (Assalamu Alaikum),

Ich bin vor einer privaten Suche auf Ihren E-Mail-Kontakt gestoßen
Ihre Hilfe. Mein Name ist Aisha Al-Qaddafi, eine alleinerziehende
Mutter und eine Witwe
mit drei Kindern. Ich bin die einzige leibliche Tochter des Spätlibyschen
Präsident (verstorbener Oberst Muammar Gaddafi).

Ich habe Investmentfonds im Wert von siebenundzwanzig Millionen
fünfhunderttausend
United State Dollar ($ 27.500.000.00) und ich brauche eine
vertrauenswürdige Investition
Manager / Partner aufgrund meines aktuellen Flüchtlingsstatus bin ich jedoch
Möglicherweise interessieren Sie sich für die Unterstützung von
Investitionsprojekten in Ihrem Land
Von dort aus können wir in naher Zukunft Geschäftsbeziehungen aufbauen.

Ich bin bereit, mit Ihnen über das Verhältnis zwischen Investition und
Unternehmensgewinn zu verhandeln
Basis für die zukünftige Investition Gewinne zu erzielen.

Wenn Sie bereit sind, dieses Projekt in meinem Namen zu bearbeiten,
antworten Sie bitte dringend
Damit ich Ihnen mehr Informationen über die Investmentfonds geben kann.

Ihre dringende Antwort wird geschätzt. schreibe mir an diese email adresse (
ayishagdda...@mail.ru ) zur weiteren Diskussion.

Freundliche Grüße
Frau Aisha Al-Qaddafi

Re: drivers/md/dm-mpath.c:524 multipath_clone_and_map() error: double unlocked 'm->lock' (orig line 516)

[Mike Snitzer]

On Sat, Aug 08 2020 at  8:10am -0400,
kernel test robot  wrote:

> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
> commit: 374117ad4736c5a4f8012cfe59fc07d9d58191d5 dm mpath: use double checked 
> locking in fast path
> date:   4 weeks ago
> config: arm-randconfig-m031-20200808 (attached as .config)
> compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 

All 3 recent reports about smatch showing "double unlocked 'm->lock'"
appear to be bogus.  Think smatch is generating false positives (and
given "Old smatch warnings" it seems it has been doing so for some
time).

In addition, does l...@intel.com no longer test linux-next?  The dm-mpath
locking changes that were just merged into mainline have been in
linux-next since July 13.  Why were these tests only done against
mainline?

Mike



> New smatch warnings:
> drivers/md/dm-mpath.c:524 multipath_clone_and_map() error: double unlocked 
> 'm->lock' (orig line 516)
> 
> Old smatch warnings:
> drivers/md/dm-mpath.c:446 choose_pgpath() error: double unlocked 'm->lock' 
> (orig line 416)
> drivers/md/dm-mpath.c:457 choose_pgpath() error: double unlocked 'm->lock' 
> (orig line 403)
> drivers/md/dm-mpath.c:525 multipath_clone_and_map() error: double unlocked 
> 'm->lock' (orig line 516)
> drivers/md/dm-mpath.c:526 multipath_clone_and_map() error: double unlocked 
> 'm->lock' (orig line 524)
> drivers/md/dm-mpath.c:626 __map_bio() error: double unlocked 'm->lock' (orig 
> line 615)
> drivers/md/dm-mpath.c:627 __map_bio() error: double unlocked 'm->lock' (orig 
> line 615)
> drivers/md/dm-mpath.c:628 __map_bio() error: double unlocked 'm->lock' (orig 
> line 626)
> drivers/md/dm-mpath.c:629 __map_bio() error: double unlocked 'm->lock' (orig 
> line 628)
> drivers/md/dm-mpath.c:1607 pg_init_done() error: double unlocked 'm->lock' 
> (orig line 1560)
> drivers/md/dm-mpath.c:1707 multipath_end_io_bio() error: double unlocked 
> 'm->lock' (orig line 1704)
> drivers/md/dm-mpath.c:1988 multipath_prepare_ioctl() error: double unlocked 
> 'm->lock' (orig line 1984)
> drivers/md/dm-mpath.c:2012 multipath_prepare_ioctl() error: double unlocked 
> 'm->lock' (orig line 2001)
> 
> vim +524 drivers/md/dm-mpath.c
> 
>498
>499/*
>500 * Map cloned requests (request-based multipath)
>501 */
>502static int multipath_clone_and_map(struct dm_target *ti, struct 
> request *rq,
>503   union map_info *map_context,
>504   struct request **__clone)
>505{
>506struct multipath *m = ti->private;
>507size_t nr_bytes = blk_rq_bytes(rq);
>508struct pgpath *pgpath;
>509struct block_device *bdev;
>510struct dm_mpath_io *mpio = get_mpio(map_context);
>511struct request_queue *q;
>512struct request *clone;
>513
>514/* Do we need to select a new pgpath? */
>515pgpath = READ_ONCE(m->current_pgpath);
>  > 516if (!pgpath || 
> !mpath_double_check_test_bit(MPATHF_QUEUE_IO, m))
>517pgpath = choose_pgpath(m, nr_bytes);
>518
>519if (!pgpath) {
>520if (must_push_back_rq(m))
>521return DM_MAPIO_DELAY_REQUEUE;
>522dm_report_EIO(m);   /* Failed */
>523return DM_MAPIO_KILL;
>  > 524} else if (mpath_double_check_test_bit(MPATHF_QUEUE_IO, 
> m) ||
>525   
> mpath_double_check_test_bit(MPATHF_PG_INIT_REQUIRED, m)) {
>526pg_init_all_paths(m);
>527return DM_MAPIO_DELAY_REQUEUE;
>528}
>529
>530mpio->pgpath = pgpath;
>531mpio->nr_bytes = nr_bytes;
>532
>533bdev = pgpath->path.dev->bdev;
>534q = bdev_get_queue(bdev);
>535clone = blk_get_request(q, rq->cmd_flags | REQ_NOMERGE,
>536BLK_MQ_REQ_NOWAIT);
>537if (IS_ERR(clone

Re: [PATCH v2] i2c: iproc: fix race between client unreg and isr

[Florian Fainelli]

On 8/7/2020 8:55 PM, Dhananjay Phadke wrote:
> On 8/7/2020, Florian Fainelli wrote:
>>> When i2c client unregisters, synchronize irq before setting
>>> iproc_i2c->slave to NULL.
>>>
>>> (1) disable_irq()
>>> (2) Mask event enable bits in control reg
>>> (3) Erase slave address (avoid further writes to rx fifo)
>>> (4) Flush tx and rx FIFOs
>>> (5) Clear pending event (interrupt) bits in status reg
>>> (6) enable_irq()
>>> (7) Set client pointer to NULL
>>>
>>
>>> @@ -1091,6 +1091,17 @@ static int bcm_iproc_i2c_unreg_slave(struct 
>>> i2c_client *slave)
>>> tmp &= ~BIT(S_CFG_EN_NIC_SMB_ADDR3_SHIFT);
>>> iproc_i2c_wr_reg(iproc_i2c, S_CFG_SMBUS_ADDR_OFFSET, tmp);
>>>  
>>> +   /* flush TX/RX FIFOs */
>>> +   tmp = (BIT(S_FIFO_RX_FLUSH_SHIFT) | BIT(S_FIFO_TX_FLUSH_SHIFT));
>>> +   iproc_i2c_wr_reg(iproc_i2c, S_FIFO_CTRL_OFFSET, tmp);
>>> +
>>> +   /* clear all pending slave interrupts */
>>> +   iproc_i2c_wr_reg(iproc_i2c, IS_OFFSET, ISR_MASK_SLAVE);
>>> +
>>> +   enable_irq(iproc_i2c->irq);
>>> +
>>> +   iproc_i2c->slave = NULL;
>>
>> There is nothing that checks on iproc_i2c->slave being valid within the
>> interrupt handler, we assume that the pointer is valid which is fin,
>> however non functional it may be, it may feel more natural to move the
>> assignment before the enable_irq()?
> 
> As far as the teardown sequence ensures no more interrupts arrive after
> enable_irq() and they are enabled only after setting pointer during
> client register(); checking for NULL in ISR isn't necessary. 

Agreed.

> 
> If The teardown sequence doesn't guarantee quiescing of interrupts,
> setting NULL before or after enable_irq() is equally vulnerable.

The teardown sequence is sort of a critical section if we may say, so
ensuring that everything happens within it and that enable_irq() is the
last operation would seem more natural to me at least. Thanks
-- 
Florian

arch/powerpc/platforms/powernv/opal-fadump.c:72:58: sparse: expected restricted __be64 src

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 51bba8edef90cf579dba16de912d3ef809fe1d77 powerpc/fadump: support 
copying multiple kernel boot memory regions
date:   11 months ago
config: powerpc64-randconfig-s032-20200808 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout 51bba8edef90cf579dba16de912d3ef809fe1d77
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 

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


sparse warnings: (new ones prefixed by >>)

   arch/powerpc/platforms/powernv/opal-fadump.c:35:41: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned 
long long [usertype] boot_mem_dest_addr @@ got restricted __be64 const 
[usertype] dest @@
   arch/powerpc/platforms/powernv/opal-fadump.c:35:41: sparse: expected 
unsigned long long [usertype] boot_mem_dest_addr
   arch/powerpc/platforms/powernv/opal-fadump.c:35:41: sparse: got 
restricted __be64 const [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:72:58: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] src @@ got unsigned long long [assigned] [usertype] 
src_addr @@
>> arch/powerpc/platforms/powernv/opal-fadump.c:72:58: sparse: expected 
>> restricted __be64 [usertype] src
   arch/powerpc/platforms/powernv/opal-fadump.c:72:58: sparse: got unsigned 
long long [assigned] [usertype] src_addr
   arch/powerpc/platforms/powernv/opal-fadump.c:73:58: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] dest @@ got unsigned long long [assigned] [usertype] 
dest_addr @@
   arch/powerpc/platforms/powernv/opal-fadump.c:73:58: sparse: expected 
restricted __be64 [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:73:58: sparse: got unsigned 
long long [assigned] [usertype] dest_addr
   arch/powerpc/platforms/powernv/opal-fadump.c:74:58: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] size @@ got int [assigned] cur_size @@
   arch/powerpc/platforms/powernv/opal-fadump.c:74:58: sparse: expected 
restricted __be64 [usertype] size
   arch/powerpc/platforms/powernv/opal-fadump.c:74:58: sparse: got int 
[assigned] cur_size
   arch/powerpc/platforms/powernv/opal-fadump.c:86:53: sparse: sparse: 
restricted __be64 degrades to integer
   arch/powerpc/platforms/powernv/opal-fadump.c:138:56: sparse: sparse: 
incorrect type in argument 2 (different base types) @@ expected unsigned 
long long [usertype] src @@ got restricted __be64 [usertype] src @@
   arch/powerpc/platforms/powernv/opal-fadump.c:138:56: sparse: expected 
unsigned long long [usertype] src
   arch/powerpc/platforms/powernv/opal-fadump.c:138:56: sparse: got 
restricted __be64 [usertype] src
   arch/powerpc/platforms/powernv/opal-fadump.c:139:56: sparse: sparse: 
incorrect type in argument 3 (different base types) @@ expected unsigned 
long long [usertype] dest @@ got restricted __be64 [usertype] dest @@
   arch/powerpc/platforms/powernv/opal-fadump.c:139:56: sparse: expected 
unsigned long long [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:139:56: sparse: got 
restricted __be64 [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:140:56: sparse: sparse: 
incorrect type in argument 4 (different base types) @@ expected unsigned 
long long [usertype] size @@ got restricted __be64 [usertype] size @@
   arch/powerpc/platforms/powernv/opal-fadump.c:140:56: sparse: expected 
unsigned long long [usertype] size
   arch/powerpc/platforms/powernv/opal-fadump.c:140:56: sparse: got 
restricted __be64 [usertype] size

vim +72 arch/powerpc/platforms/powernv/opal-fadump.c

50  
51  static u64 opal_fadump_init_mem_struct(struct fw_dump *fadump_conf)
52  {
53  int max_copy_size, cur_size, size;
54  u64 src_addr, dest_addr;
55  
56  opal_fdm = __va(fadump_conf->kernel_metadata);
57  opal_fadump_init_metadata(opal_fdm);
58  
59  /*
60   * Firmware supports 32-bit field for size. Align it to 
PAGE_SIZE
61   * and request firmware to copy multiple kernel boot memory 
regions.
62   */
63  max_copy_size = _ALIGN_DOWN(U32_MAX, PAGE_SIZE);
64  

Re: [PATCH] fix arm64 build with lack of __cpu_logical_map exported

[Catalin Marinas]

Hi Greg,

On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote:
> diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> index 87e81d29e6fb..b421a4756793 100644
> --- a/arch/arm64/kernel/setup.c
> +++ b/arch/arm64/kernel/setup.c
> @@ -275,6 +275,7 @@ static int __init reserve_memblock_reserved_regions(void)
>  arch_initcall(reserve_memblock_reserved_regions);
>  
>  u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> +EXPORT_SYMBOL_GPL(__cpu_logical_map);

This was still under discussion, Sudeep preferring an alternative in the
driver:

http://lkml.kernel.org/r/20200727172744.GD8003@bogus
http://lkml.kernel.org/r/20200724131059.GB6521@bogus

Sumit came with a new diff inline that fixes the driver instead of
exporting the __cpu_logical_map.

https://lore.kernel.org/linux-arm-kernel/e3a4bc21-c334-4d48-90b5-aab8d1879...@nvidia.com/

Sumit, Sudeep, is the above diff sufficient and can it go upstream?

Thanks.

-- 
Catalin

Re: [PATCH] scsi: sd: add runtime pm to open / release

[Alan Stern]

On Sat, Aug 08, 2020 at 08:59:09AM +0200, Martin Kepplinger wrote:
> On 07.08.20 16:30, Alan Stern wrote:
> > On Fri, Aug 07, 2020 at 11:51:21AM +0200, Martin Kepplinger wrote:
> >> it's really strange: below is the change I'm trying. Of course that's
> >> only for testing the functionality, nothing how a patch could look like.
> >>
> >> While I remember it had worked, now (weirdly since I tried that mounting
> >> via fstab) it doesn't anymore!
> >>
> >> What I understand (not much): I handle the error with "retry" via the
> >> new flag, but scsi_decide_disposition() returns SUCCESS because of "no
> >> more retries"; but it's the first and only time it's called.
> > 
> > Are you saying that scmd->allowed is set to 0?  Or is scsi_notry_cmd() 
> > returning a nonzero value?  Whichever is true, why does it happen that 
> > way?
> 
> scsi_notry_cmd() is returning 1. (it's retry 1 of 5 allowed).
> 
> why is it returning 1? REQ_FAILFAST_DEV is set. It's DID_OK, then "if
> (status_byte(scmd->result) != CHECK_CONDITION)" appearently is not true,
> then at the end it returns 1 because of REQ_FAILFAST_DEV.
> 
> that seems to come from the block layer. why and when? could I change
> that so that the scsi error handling stays in control?

The only place I see where that flag might get set is in 
blk_mq_bio_to_request() in block/blk-mq.c, which does:

if (bio->bi_opf & REQ_RAHEAD)
rq->cmd_flags |= REQ_FAILFAST_MASK;

So apparently read-ahead reads are supposed to fail fast (i.e., without 
retries), presumably because they are optional after all.

> > What is the failing command?  Is it a READ(10)?
> 
> Not sure how I'd answer that, but here's the test to trigger the error:
> 
> mount /dev/sda1 /mnt
> cd /mnt
> ls
> cp file ~/ (if ls "works" and doesn't yet trigger the error)
> 
> and that's the (familiar looking) logs when doing so. again: despite the
> mentioned workaround in scsi_error and the new expected_media_change
> flag *is* set and gets cleared, as it should be. REQ_FAILFAST_DEV seems
> to override what I want to do is scsi_error:
> 
> [   55.557629] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result:
> hostbyte=0x00 driverbyte=0x08 cmd_age=0s
> [   55.557639] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current]
> [   55.557646] sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0
> [   55.557657] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 08 fc
> e0 00 00 01 00

Yes, 0x28 is READ(10).  Likely this is a read-ahead request, although I 
don't know how we can tell for sure.

> [   55.557666] blk_update_request: I/O error, dev sda, sector 589024 op
> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
> [   55.568899] sd 0:0:0:0: [sda] tag#0 device offline or changed
> [   55.574691] blk_update_request: I/O error, dev sda, sector 589025 op
> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
> [   55.585756] sd 0:0:0:0: [sda] tag#0 device offline or changed
> [   55.591562] blk_update_request: I/O error, dev sda, sector 589026 op
> 0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
> [   55.602274] sd 0:0:0:0: [sda] tag#0 device offline or changed
> (... goes on with the same)

Is such a drastic response really appropriate for the failure of a 
read-ahead request?  It seems like a more logical response would be to 
let the request fail but keep the device online.

Of course, that would only solve part of your problem -- your log would 
still get filled with those "I/O error" messages even though they 
wouldn't be fatal.  Probably a better approach would be to make the new 
expecting_media_change flag override scsi_no_retry_cmd().

But this is not my area of expertise.  Maybe someone else will have more 
to say.

Alan Stern

Re: [PATCH] docs: Fix function name trailing double-()s

[Paul E. McKenney]

On Fri, Aug 07, 2020 at 11:49:59PM -0700, Kees Cook wrote:
> I noticed a double-() after a function name in deprecated.rst today. Fix
> that one and two others in the Documentation/ tree.
> 
> Signed-off-by: Kees Cook 

For the RCU hunk:

Acked-by: Paul E. McKenney 

Or I could take the Documentation/RCU/lockdep.rst portion, if you
would prefer.

> ---
>  Documentation/RCU/lockdep.rst   | 2 +-
>  Documentation/process/deprecated.rst| 2 +-
>  Documentation/translations/it_IT/process/deprecated.rst | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/RCU/lockdep.rst b/Documentation/RCU/lockdep.rst
> index f1fc8ae3846a..cc860a0c296b 100644
> --- a/Documentation/RCU/lockdep.rst
> +++ b/Documentation/RCU/lockdep.rst
> @@ -49,7 +49,7 @@ checking of rcu_dereference() primitives:
>   is invoked by both RCU-sched readers and updaters.
>   srcu_dereference_check(p, c):
>   Use explicit check expression "c" along with
> - srcu_read_lock_held()().  This is useful in code that
> + srcu_read_lock_held().  This is useful in code that
>   is invoked by both SRCU readers and updaters.
>   rcu_dereference_raw(p):
>   Don't check.  (Use sparingly, if at all.)
> diff --git a/Documentation/process/deprecated.rst 
> b/Documentation/process/deprecated.rst
> index 4a9aa4f0681e..918e32d76fc4 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -142,7 +142,7 @@ only NUL-terminated strings. The safe replacement is 
> strscpy().
>  (Users of strscpy() still needing NUL-padding should instead
>  use strscpy_pad().)
>  
> -If a caller is using non-NUL-terminated strings, strncpy()() can
> +If a caller is using non-NUL-terminated strings, strncpy() can
>  still be used, but destinations should be marked with the `__nonstring
>  `_
>  attribute to avoid future compiler warnings.
> diff --git a/Documentation/translations/it_IT/process/deprecated.rst 
> b/Documentation/translations/it_IT/process/deprecated.rst
> index e108eaf82cf6..a642ff3fdc8b 100644
> --- a/Documentation/translations/it_IT/process/deprecated.rst
> +++ b/Documentation/translations/it_IT/process/deprecated.rst
> @@ -130,7 +130,7 @@ chi usa solo stringe terminate. La versione sicura da 
> usare è
>  strscpy(). (chi usa strscpy() e necessita di estendere la
>  terminazione con NUL deve aggiungere una chiamata a memset())
>  
> -Se il chiamate no usa stringhe terminate con NUL, allore strncpy()()
> +Se il chiamate no usa stringhe terminate con NUL, allore strncpy()
>  può continuare ad essere usata, ma i buffer di destinazione devono essere
>  marchiati con l'attributo `__nonstring 
> `_
>  per evitare avvisi durante la compilazione.
> -- 
> 2.25.1
> 
> 
> -- 
> Kees Cook

Re: [PATCH] fix arm64 build with lack of __cpu_logical_map exported

[Greg Kroah-Hartman]

On Sat, Aug 08, 2020 at 04:05:00PM +0100, Catalin Marinas wrote:
> Hi Greg,
> 
> On Sat, Aug 08, 2020 at 02:42:42PM +0200, Greg Kroah-Hartman wrote:
> > diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
> > index 87e81d29e6fb..b421a4756793 100644
> > --- a/arch/arm64/kernel/setup.c
> > +++ b/arch/arm64/kernel/setup.c
> > @@ -275,6 +275,7 @@ static int __init 
> > reserve_memblock_reserved_regions(void)
> >  arch_initcall(reserve_memblock_reserved_regions);
> >  
> >  u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
> > +EXPORT_SYMBOL_GPL(__cpu_logical_map);
> 
> This was still under discussion, Sudeep preferring an alternative in the
> driver:
> 
> http://lkml.kernel.org/r/20200727172744.GD8003@bogus
> http://lkml.kernel.org/r/20200724131059.GB6521@bogus
> 
> Sumit came with a new diff inline that fixes the driver instead of
> exporting the __cpu_logical_map.
> 
> https://lore.kernel.org/linux-arm-kernel/e3a4bc21-c334-4d48-90b5-aab8d1879...@nvidia.com/

Ok, but having a broken tree is not nice, how did this survive
linux-next testing?

> Sumit, Sudeep, is the above diff sufficient and can it go upstream?

Note that MIPS already export this symbol, so perhaps the drivers that
need it on that platform should also be fixed the same way?

thanks,

greg k-h

Re: [RFC PATCH 0/7] metricfs metric file system and examples

[David Ahern]

On 8/7/20 8:06 PM, Andrew Lunn wrote:
> So i personally don't think netdev statistics is a good idea, i doubt
> it scales.

+1

[PATCH v3 0/3] rk3318 A95X Z2 board

[Johan Jonker]

Add rk3318 A95X Z2 board.

What works:
 adc key
 emmc
 ethernet
 hdmi
 gpu
 ir
 mmc
 sd card
 vop
 usb2
 uart2

Not tested:
 av
 uart0 / bt
 spdif
 wifi

No support in mainline:
 usb3 (works with manufacturer driver)
 front display (works with custom gpio driver AD1628/HT1628)

Problems:
 U-boot only starts on emmc, then loads kernel from sd card or emmc.

 Hdmi hotplug detects DVI modes, but marks them all BAD.
 The dw-hdmi driver needs more pre_pll_cfg_table entries.
 Slow boot behavior. Screen available way after boot. (no penguins)

 GPU support for Debian is not up to date. (old version)
 Use Github version instead.
 Test with glmark2-es2-drm gives glmark2 Score: 29
 Kernel log:
  lima ff30.gpu: pp pp0 reset time out
  lima ff30.gpu: pp pp1 reset time out
 No mainline support for GPU thermal and voltage to frequency.
 PWM1 supply connected to DMC, GPU and vcodec.

 The box only has a model name. Vendor prefix not verified.

 Etc.

Changed V3:
  add acked by
  change adc-keys
  change regulator
  change SPDIF
  rebase
  remove disable-wp
  remove pinctrl-names
  remove vcc_phy
  use label u2phy

Changed V2:
  add vendor prefix
  changed compatible string
  changed led active high to active low
  removed usb3 regulator node
  restyle

Johan Jonker (3):
  dt-bindings: Add vendor prefix for Shenzhen Zkmagic Technology Co.,
Ltd.
  dt-bindings: arm: rockchip: add Zkmagic A95X Z2 description
  arm64: dts: rockchip: add rk3318 A95X Z2 board

Johan Jonker (3):
  dt-bindings: Add vendor prefix for Shenzhen Zkmagic Technology Co.,
Ltd.
  dt-bindings: arm: rockchip: add Zkmagic A95X Z2 description
  arm64: dts: rockchip: add rk3318 A95X Z2 board

 .../devicetree/bindings/arm/rockchip.yaml  |   5 +
 .../devicetree/bindings/vendor-prefixes.yaml   |   2 +
 arch/arm64/boot/dts/rockchip/Makefile  |   1 +
 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts| 374 +
 4 files changed, 382 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts

--
2.11.0

[PATCH v3 3/3] arm64: dts: rockchip: add rk3318 A95X Z2 board

[Johan Jonker]

The rk3318 A95X Z2 boards are sold as TV box.
No further documentation is given, but from the dts files
extracted it seems that the rk3318 processor is simulair
to the rk3328. This dts file contains only the basic nodes
that have support in the mainline kernel.

Features:

CPU: RK3318 Quad-Core Cortex-A53
GPU: Mali-450
RAM: 2/4GB DDR3
ROM: EMMC 16/32/64GB
HDMI: HDMI 2.0a for 4k@60Hz
Ethernet: 10/100M standard RJ-45
WiFi: 2.4G+5G WIFI, 802.11 b/g/n
Bluetooth: 4.0
1 x USB 3.0
1 x USB 2.0
1 x Micro SD card slot
1 x SPDIF
1 x AV
1 x DC IN

Signed-off-by: Johan Jonker 
---
 arch/arm64/boot/dts/rockchip/Makefile   |   1 +
 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts | 374 
 2 files changed, 375 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile 
b/arch/arm64/boot/dts/rockchip/Makefile
index b87b1f773..aa508bc4a 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -2,6 +2,7 @@
 dtb-$(CONFIG_ARCH_ROCKCHIP) += px30-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3308-evb.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3308-roc-cc.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3318-a95x-z2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3326-odroid-go2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-a1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-evb.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts 
b/arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts
new file mode 100644
index 0..30c73ef25
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3318-a95x-z2.dts
@@ -0,0 +1,374 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include 
+#include "rk3328.dtsi"
+
+/ {
+   model = "A95X Z2";
+   compatible = "zkmagic,a95x-z2", "rockchip,rk3318";
+
+   chosen {
+   stdout-path = "serial2:150n8";
+   };
+
+   adc-keys {
+   compatible = "adc-keys";
+   io-channels = <&saradc 0>;
+   io-channel-names = "buttons";
+   keyup-threshold-microvolt = <180>;
+   poll-interval = <100>;
+
+   recovery {
+   label = "recovery";
+   linux,code = ;
+   press-threshold-microvolt = <17000>;
+   };
+   };
+
+   ir-receiver {
+   compatible = "gpio-ir-receiver";
+   gpios = <&gpio2 RK_PA2 GPIO_ACTIVE_LOW>;
+   pinctrl-0 = <&ir_int>;
+   pinctrl-names = "default";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-0 = <&cyx_led_pin>;
+   pinctrl-names = "default";
+
+   cyx_led: led-0 {
+   default-state = "on";
+   gpios = <&gpio2 RK_PC7 GPIO_ACTIVE_LOW>;
+   label = "CYX_LED";
+   };
+   };
+
+   sdio_pwrseq: sdio-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+   pinctrl-0 = <&wifi_enable_h>;
+   pinctrl-names = "default";
+   reset-gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
+   };
+
+   spdif-sound {
+   compatible = "simple-audio-card";
+   simple-audio-card,name = "SPDIF";
+
+   simple-audio-card,cpu {
+   sound-dai = <&spdif>;
+   };
+
+   simple-audio-card,codec {
+   sound-dai = <&spdif_out>;
+   };
+   };
+
+   spdif_out: spdif-out {
+   compatible = "linux,spdif-dit";
+   #sound-dai-cells = <0>;
+   };
+
+   /* Power tree */
+   vccio_1v8: vccio-1v8-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_1v8";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   vccio_3v3: vccio-3v3-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vccio_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
+
+   vcc_otg_vbus: otg-vbus-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 RK_PA2 GPIO_ACTIVE_HIGH>;
+   pinctrl-0 = <&otg_vbus_drv>;
+   pinctrl-names = "default";
+   regulator-name = "vcc_otg_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   enable-active-high;
+   };
+
+   vcc_sd: sdmmc-regulator {
+   compatible = "regulator-fixed";
+   gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
+   pinctrl-0 = <&sdmmc0m1_pin>;
+   pinctrl-names = "default";
+   regulator-name = "vcc_sd";
+ 

[PATCH v3 1/3] dt-bindings: Add vendor prefix for Shenzhen Zkmagic Technology Co., Ltd.

[Johan Jonker]

Add vendor prefix for Shenzhen Zkmagic Technology Co., Ltd.

Signed-off-by: Johan Jonker 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml 
b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index f3d847832..f4bd9b9a1 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1197,6 +1197,8 @@ patternProperties:
 description: Shenzhen Zidoo Technology Co., Ltd.
   "^zii,.*":
 description: Zodiac Inflight Innovations
+  "^zkmagic,.*":
+description: Shenzhen Zkmagic Technology Co., Ltd.
   "^zte,.*":
 description: ZTE Corp.
   "^zyxel,.*":
-- 
2.11.0

[PATCH v3 2/3] dt-bindings: arm: rockchip: add Zkmagic A95X Z2 description

[Johan Jonker]

Add Zkmagic A95X Z2 description for a board with rk3318 processor.

Signed-off-by: Johan Jonker 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml 
b/Documentation/devicetree/bindings/arm/rockchip.yaml
index db2e35796..7d1961bbd 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -555,4 +555,9 @@ properties:
 items:
   - const: tronsmart,orion-r68-meta
   - const: rockchip,rk3368
+
+  - description: Zkmagic A95X Z2
+items:
+  - const: zkmagic,a95x-z2
+  - const: rockchip,rk3318
 ...
-- 
2.11.0

Re: [PATCH v6 2/2] iio: light: as73211: New driver

[Jonathan Cameron]

On Fri, 7 Aug 2020 17:46:36 +0200
Christian Eggers  wrote:

> Hi Jonathan,
> 
> On Thursday, 6 August 2020, 19:44:51 CEST, Jonathan Cameron wrote:
> > Hi Christian,
> > 
> > I'll take this, but please send a follow up patch to add documentation
> > for in_intensity_x_raw and all the other new ABI this adds in
> > Documentation/ABI/testing/sysfs-bus-iio
> > I should have mentioned that earlier, but kind of assumed we already
> > had these documented for some reason!  
> where to add these entries in Documentation/ABI/testing/sysfs-bus-iio?
> Shall all missing entries be added together at the bottom (as AS73211
> is the first device using it) , or inserted in different existing paragraphs
> (when the enums where introduced)?

Insert them into the relevant groups that already exist.  In some cases
it will just be adding an entry with no specific explanation.
For the _raw attribute add a bit more info about what x, y and z are
(basically just say they are from cie1931 (I think?)

> 
> Which kernel version shall I use (5.10)?
This file doesn't change that quickly so that should be fine. I'll deal
with any merge conflicts that do occur.

Thanks,

Jonathan

> 
> regards
> Christian
> 
> 
> 
> 

[PATCH] docs: cdrom: Fix a typo and rst markup

[Remi Andruccioli]

"The capability fags" should be "The capability flags".

In rst markup, a incorrect markup expression is causing bad rendering in
Sphinx output. Replace the erroneous single quote by a backquote.

Signed-off-by: Remi Andruccioli 
---
 Documentation/cdrom/cdrom-standard.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/cdrom/cdrom-standard.rst 
b/Documentation/cdrom/cdrom-standard.rst
index 2de905810590..70500b189cc8 100644
--- a/Documentation/cdrom/cdrom-standard.rst
+++ b/Documentation/cdrom/cdrom-standard.rst
@@ -557,7 +557,7 @@ phase. Currently, the capabilities are any of::
CDC_DRIVE_STATUS/* driver implements drive status */
 
 The capability flag is declared *const*, to prevent drivers from
-accidentally tampering with the contents. The capability fags actually
+accidentally tampering with the contents. The capability flags actually
 inform `cdrom.c` of what the driver can do. If the drive found
 by the driver does not have the capability, is can be masked out by
 the *cdrom_device_info* variable *mask*. For instance, the SCSI CD-ROM
@@ -736,7 +736,7 @@ Description of routines in `cdrom.c`
 
 Only a few routines in `cdrom.c` are exported to the drivers. In this
 new section we will discuss these, as well as the functions that `take
-over' the CD-ROM interface to the kernel. The header file belonging
+over` the CD-ROM interface to the kernel. The header file belonging
 to `cdrom.c` is called `cdrom.h`. Formerly, some of the contents of this
 file were placed in the file `ucdrom.h`, but this file has now been
 merged back into `cdrom.h`.
-- 
2.26.2

RE: [PATCH v3] exfat: integrates dir-entry getting and validation

[Sungjong Seo]

> Add validation for num, bh and type on getting dir-entry.
> Renamed exfat_get_dentry_cached() to exfat_get_validated_dentry() due to a
> change in functionality.
> 
> Integrate type-validation with simplified.
> This will also recognize a dir-entry set that contains 'benign secondary'
> dir-entries.
> 
> Pre-Validated 'file' and 'stream-ext' dir-entries are provided as member
> variables of exfat_entry_set_cache.
> 
> And, rename TYPE_EXTEND to TYPE_NAME.
> 
> Suggested-by: Sungjong Seo 
> Suggested-by: Namjae Jeon 
> Signed-off-by: Tetsuhiro Kohada 

Reviewed-by: Sungjong Seo 

Looks good to me. Thanks.

> ---
> Changes in v2
>  - Change verification order
>  - Verification loop start with index 2
> Changes in v3
>  - Fix indent
>  - Fix comment of exfat_get_dentry_set()
>  - Add de_file/de_stream in exfat_entry_set_cache
>  - Add srtuct tag name for each dir-entry type in exfat_dentry
>  - Add description about de_file/de_stream to commit-log
> 
>  fs/exfat/dir.c   | 147 +--
>  fs/exfat/exfat_fs.h  |  17 +++--
>  fs/exfat/exfat_raw.h |  10 +--
>  fs/exfat/file.c  |  25 
>  fs/exfat/inode.c |  49 ++-
>  fs/exfat/namei.c |  36 +--
>  6 files changed, 122 insertions(+), 162 deletions(-)

arch/arm/include/asm/arch_gicv3.h:44:2: error: implicit declaration of function 'write_sysreg'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: d82bcef5157de1368c08244a846ab968b3e5cb7e soc: imx: select ARM_GIC_V3 
for i.MX8M
date:   4 weeks ago
config: arm-randconfig-p002-20200808 (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
git checkout d82bcef5157de1368c08244a846ab968b3e5cb7e
# 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 >>):

   In file included from include/linux/irqchip/arm-gic-v3.h:662,
from drivers/irqchip/irq-gic-v3.c:24:
   arch/arm/include/asm/arch_gicv3.h: In function 'write_ICC_PMR_EL1':
>> arch/arm/include/asm/arch_gicv3.h:44:2: error: implicit declaration of 
>> function 'write_sysreg' [-Werror=implicit-function-declaration]
  44 |  write_sysreg(val, a32);   \
 |  ^~~~
   arch/arm/include/asm/arch_gicv3.h:51:1: note: in expansion of macro 
'CPUIF_MAP'
  51 | CPUIF_MAP(ICC_PMR, ICC_PMR_EL1)
 | ^
>> arch/arm/include/asm/arch_gicv3.h:22:20: error: implicit declaration of 
>> function '__ACCESS_CP15' [-Werror=implicit-function-declaration]
  22 | #define ICC_PMR__ACCESS_CP15(c4, 0, c6, 0)
 |^
   arch/arm/include/asm/arch_gicv3.h:44:20: note: in definition of macro 
'CPUIF_MAP'
  44 |  write_sysreg(val, a32);   \
 |^~~
   arch/arm/include/asm/arch_gicv3.h:51:11: note: in expansion of macro 
'ICC_PMR'
  51 | CPUIF_MAP(ICC_PMR, ICC_PMR_EL1)
 |   ^~~
>> arch/arm/include/asm/arch_gicv3.h:22:34: error: 'c4' undeclared (first use 
>> in this function)
  22 | #define ICC_PMR__ACCESS_CP15(c4, 0, c6, 0)
 |  ^~
   arch/arm/include/asm/arch_gicv3.h:44:20: note: in definition of macro 
'CPUIF_MAP'
  44 |  write_sysreg(val, a32);   \
 |^~~
   arch/arm/include/asm/arch_gicv3.h:51:11: note: in expansion of macro 
'ICC_PMR'
  51 | CPUIF_MAP(ICC_PMR, ICC_PMR_EL1)
 |   ^~~
   arch/arm/include/asm/arch_gicv3.h:22:34: note: each undeclared identifier is 
reported only once for each function it appears in
  22 | #define ICC_PMR__ACCESS_CP15(c4, 0, c6, 0)
 |  ^~
   arch/arm/include/asm/arch_gicv3.h:44:20: note: in definition of macro 
'CPUIF_MAP'
  44 |  write_sysreg(val, a32);   \
 |^~~
   arch/arm/include/asm/arch_gicv3.h:51:11: note: in expansion of macro 
'ICC_PMR'
  51 | CPUIF_MAP(ICC_PMR, ICC_PMR_EL1)
 |   ^~~
>> arch/arm/include/asm/arch_gicv3.h:22:41: error: 'c6' undeclared (first use 
>> in this function)
  22 | #define ICC_PMR__ACCESS_CP15(c4, 0, c6, 0)
 | ^~
   arch/arm/include/asm/arch_gicv3.h:44:20: note: in definition of macro 
'CPUIF_MAP'
  44 |  write_sysreg(val, a32);   \
 |^~~
   arch/arm/include/asm/arch_gicv3.h:51:11: note: in expansion of macro 
'ICC_PMR'
  51 | CPUIF_MAP(ICC_PMR, ICC_PMR_EL1)
 |   ^~~
   arch/arm/include/asm/arch_gicv3.h: In function 'read_ICC_PMR_EL1':
>> arch/arm/include/asm/arch_gicv3.h:48:9: error: implicit declaration of 
>> function 'read_sysreg' [-Werror=implicit-function-declaration]
  48 |  return read_sysreg(a32);   \
 | ^~~
   arch/arm/include/asm/arch_gicv3.h:51:1: note: in expansion of macro 
'CPUIF_MAP'
  51 | CPUIF_MAP(ICC_PMR, ICC_PMR_EL1)
 | ^
>> arch/arm/include/asm/arch_gicv3.h:22:34: error: 'c4' undeclared (first use 
>> in this function)
  22 | #define ICC_PMR__ACCESS_CP15(c4, 0, c6, 0)
 |  ^~
   arch/arm/include/asm/arch_gicv3.h:48:21: note: in definition of macro 
'CPUIF_MAP'
  48 |  return read_sysreg(a32);   \
 | ^~~
   arch/arm/include/asm/arch_gicv3.h:51:11: note: in expansion of macro 
'ICC_PMR'
  51 | CPUIF_MAP(ICC_PMR, ICC_PMR_EL1)
 |   ^~~
>> arch/arm/include/asm/arch_gicv3.h:22:41: error: 'c6' undeclared (first use 
>> in this function)
  22 | #define ICC_PMR__ACCESS_CP15(c4, 0, c6, 0)
 | 

RE: [PATCH 1/2] exfat: add NameLength check when extracting name

[Sungjong Seo]

> The current implementation doesn't care NameLength when extracting the
> name from Name dir-entries, so the name may be incorrect.
> (Without null-termination, Insufficient Name dir-entry, etc) Add a
> NameLength check when extracting the name from Name dir-entries to extract
> correct name.
> And, change to get the information of file/stream-ext dir-entries via the
> member variable of exfat_entry_set_cache.
> 
> ** This patch depends on:
>   '[PATCH v3] exfat: integrates dir-entry getting and validation'.
> 
> Signed-off-by: Tetsuhiro Kohada 
> ---
>  fs/exfat/dir.c | 81 --
>  1 file changed, 39 insertions(+), 42 deletions(-)
> 
> diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index
> 91cdbede0fd1..545bb73b95e9 100644
> --- a/fs/exfat/dir.c
> +++ b/fs/exfat/dir.c
> @@ -28,16 +28,15 @@ static int exfat_extract_uni_name(struct exfat_dentry
> *ep,
> 
>  }
> 
> -static void exfat_get_uniname_from_ext_entry(struct super_block *sb,
> - struct exfat_chain *p_dir, int entry, unsigned short
> *uniname)
> +static int exfat_get_uniname_from_name_entries(struct
> exfat_entry_set_cache *es,
> + struct exfat_uni_name *uniname)
>  {
> - int i;
> - struct exfat_entry_set_cache *es;
> + int n, l, i;
>   struct exfat_dentry *ep;
> 
> - es = exfat_get_dentry_set(sb, p_dir, entry, ES_ALL_ENTRIES);
> - if (!es)
> - return;
> + uniname->name_len = es->de_stream->name_len;
> + if (uniname->name_len == 0)
> + return -EIO;

-EINVAL looks better.

> 
>   /*
>* First entry  : file entry
> @@ -45,14 +44,15 @@ static void exfat_get_uniname_from_ext_entry(struct
> super_block *sb,
>* Third entry  : first file-name entry
>* So, the index of first file-name dentry should start from 2.
>*/
> -
> - i = 2;
> - while ((ep = exfat_get_validated_dentry(es, i++, TYPE_NAME))) {
> - exfat_extract_uni_name(ep, uniname);
> - uniname += EXFAT_FILE_NAME_LEN;
> + for (l = 0, n = 2; l < uniname->name_len; n++) {
> + ep = exfat_get_validated_dentry(es, n, TYPE_NAME);
> + if (!ep)
> + return -EIO;
> + for (i = 0; l < uniname->name_len && i <
EXFAT_FILE_NAME_LEN;
> i++, l++)
> + uniname->name[l] = le16_to_cpu(ep-
> >dentry.name.unicode_0_14[i]);

Looks good.

>   }
> -
> - exfat_free_dentry_set(es, false);
> + uniname->name[l] = 0;
> + return 0;
>  }
> 
>  /* read a directory entry from the opened directory */ @@ -63,6 +63,7 @@
> static int exfat_readdir(struct inode *inode, struct exfat_dir_entry
> *dir_entry)
[snip]
> - *uni_name.name = 0x0;
> - exfat_get_uniname_from_ext_entry(sb, &dir, dentry,
> - uni_name.name);
> + dir_entry->size = le64_to_cpu(es->de_stream-
> >valid_size);
> +
> + exfat_get_uniname_from_name_entries(es, &uni_name);

Modified function has a return value.
It would be better to check the return value.

>   exfat_utf16_to_nls(sb, &uni_name,
>   dir_entry->namebuf.lfn,
>   dir_entry->namebuf.lfnbuf_len);
> - brelse(bh);
> 
> - ep = exfat_get_dentry(sb, &clu, i + 1, &bh, NULL);
> - if (!ep)
> - return -EIO;
> - dir_entry->size =
> - le64_to_cpu(ep->dentry.stream.valid_size);
> - brelse(bh);
> + exfat_free_dentry_set(es, false);
> 
>   ei->hint_bmap.off = dentry >> dentries_per_clu_bits;
>   ei->hint_bmap.clu = clu.dir;
> --
> 2.25.1

Re: [GIT PULL] IPMI bug fixes for 5.9

[pr-tracker-bot]

The pull request you sent on Sat, 8 Aug 2020 07:34:07 -0500:

> https://github.com/cminyard/linux-ipmi.git tags/for-linus-5.9-1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/11030fe96b57ad843518b0e9430f3cd4b3610ce2

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

drivers/char/agp/amd-k7-agp.c:46:28: sparse: sparse: incorrect type in assignment (different address spaces)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 670d0a4b10704667765f7d18f7592993d02783aa sparse: use identifiers to 
define address spaces
date:   7 weeks ago
config: i386-randconfig-s002-20200809 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout 670d0a4b10704667765f7d18f7592993d02783aa
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 

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


sparse warnings: (new ones prefixed by >>)

>> drivers/char/agp/amd-k7-agp.c:46:28: sparse: sparse: incorrect type in 
>> assignment (different address spaces) @@ expected unsigned long 
>> [noderef] __iomem *remapped @@ got unsigned long *real @@
>> drivers/char/agp/amd-k7-agp.c:46:28: sparse: expected unsigned long 
>> [noderef] __iomem *remapped
   drivers/char/agp/amd-k7-agp.c:46:28: sparse: got unsigned long *real
--
>> drivers/scsi/pcmcia/nsp_cs.c:1669:34: sparse: sparse: incorrect type in 
>> argument 1 (different address spaces) @@ expected void volatile 
>> [noderef] __iomem *addr @@ got void * @@
>> drivers/scsi/pcmcia/nsp_cs.c:1669:34: sparse: expected void volatile 
>> [noderef] __iomem *addr
   drivers/scsi/pcmcia/nsp_cs.c:1669:34: sparse: got void *
   drivers/scsi/pcmcia/nsp_cs.c: note: in included file:
   drivers/scsi/pcmcia/nsp_io.h:231:30: sparse: sparse: incorrect type in 
argument 1 (different address spaces) @@ expected void const volatile 
[noderef] __iomem *addr @@ got unsigned long *ptr @@
   drivers/scsi/pcmcia/nsp_io.h:231:30: sparse: expected void const 
volatile [noderef] __iomem *addr
   drivers/scsi/pcmcia/nsp_io.h:231:30: sparse: got unsigned long *ptr
   drivers/scsi/pcmcia/nsp_io.h:257:30: sparse: sparse: incorrect type in 
argument 2 (different address spaces) @@ expected void volatile [noderef] 
__iomem *addr @@ got unsigned long *ptr @@
   drivers/scsi/pcmcia/nsp_io.h:257:30: sparse: expected void volatile 
[noderef] __iomem *addr
   drivers/scsi/pcmcia/nsp_io.h:257:30: sparse: got unsigned long *ptr

vim +46 drivers/char/agp/amd-k7-agp.c

^1da177e4c3f41 Linus Torvalds2005-04-16  36  
^1da177e4c3f41 Linus Torvalds2005-04-16  37  static int 
amd_create_page_map(struct amd_page_map *page_map)
^1da177e4c3f41 Linus Torvalds2005-04-16  38  {
^1da177e4c3f41 Linus Torvalds2005-04-16  39 int i;
^1da177e4c3f41 Linus Torvalds2005-04-16  40  
^1da177e4c3f41 Linus Torvalds2005-04-16  41 page_map->real = 
(unsigned long *) __get_free_page(GFP_KERNEL);
^1da177e4c3f41 Linus Torvalds2005-04-16  42 if (page_map->real == 
NULL)
^1da177e4c3f41 Linus Torvalds2005-04-16  43 return -ENOMEM;
^1da177e4c3f41 Linus Torvalds2005-04-16  44  
44a207fc66c13c Dave Airlie   2008-02-20  45 set_memory_uc((unsigned 
long)page_map->real, 1);
fcea424d31868a Arjan van dev Ven 2008-02-06 @46 page_map->remapped = 
page_map->real;
^1da177e4c3f41 Linus Torvalds2005-04-16  47  
^1da177e4c3f41 Linus Torvalds2005-04-16  48 for (i = 0; i < 
PAGE_SIZE / sizeof(unsigned long); i++) {
^1da177e4c3f41 Linus Torvalds2005-04-16  49 
writel(agp_bridge->scratch_page, page_map->remapped+i);
^1da177e4c3f41 Linus Torvalds2005-04-16  50 
readl(page_map->remapped+i);/* PCI Posting. */
^1da177e4c3f41 Linus Torvalds2005-04-16  51 }
^1da177e4c3f41 Linus Torvalds2005-04-16  52  
^1da177e4c3f41 Linus Torvalds2005-04-16  53 return 0;
^1da177e4c3f41 Linus Torvalds2005-04-16  54  }
^1da177e4c3f41 Linus Torvalds2005-04-16  55  

:: The code at line 46 was first introduced by commit
:: fcea424d31868a78366ad5ee0cb3cc2a4cbe689b fix historic ioremap() abuse in 
AGP

:: TO: Arjan van dev Ven 
:: CC: Dave Airlie 

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


.config.gz
Description: application/gzip

[PATCH] [net/ipv6] ip6_output: Add ipv6_pinfo null check

[Gaurav Singh]

This PR fixes a possible segmentation violation.

In function: ip6_xmit(), we have
const struct ipv6_pinfo *np = inet6_sk(sk); which returns NULL
unconditionally (regardless sk being  NULL or not).

In include/linux/ipv6.h:

static inline struct ipv6_pinfo * inet6_sk(const struct sock *__sk)
{
return NULL;
}

Further down the function, there's a check:
if (np) hlimit = hp->htop_limit

Thereafter, we have a call
ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb, fl6->flowlabel,
ip6_autoflowlabel(net, np), fl6));

Hence np = NULL gets passed in
the function ip6_autoflowlabel() that accesses np without check which
may cause a segment violation.

Fixes: 513674b5a2c9c ("net: reevalulate autoflowlabel setting after sysctl 
setting")

Signed-off-by: Gaurav Singh 
---
 net/ipv6/ip6_output.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 8a8c2d0cfcc8..94a07c9bd925 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -181,10 +181,10 @@ int ip6_output(struct net *net, struct sock *sk, struct 
sk_buff *skb)
 
 bool ip6_autoflowlabel(struct net *net, const struct ipv6_pinfo *np)
 {
-   if (!np->autoflowlabel_set)
-   return ip6_default_np_autolabel(net);
-   else
+   if (np && np->autoflowlabel_set)
return np->autoflowlabel;
+   else
+   return ip6_default_np_autolabel(net);
 }
 
 /*
-- 
2.17.1

Re: [PATCH] clk: samsung: Prevent potential endless loop in the PLL set_rate ops

[Tomasz Figa]

2020年8月7日(金) 19:06 Sylwester Nawrocki :
>
> Hi Tomasz,
>
> On 8/6/20 18:11, Tomasz Figa wrote:
> >> --- a/drivers/clk/samsung/clk-pll.c
> >> +++ b/drivers/clk/samsung/clk-pll.c
> >> @@ -63,6 +63,27 @@ static long samsung_pll_round_rate(struct clk_hw *hw,
> >> return rate_table[i - 1].rate;
> >>  }
> >>
> >> +static int samsung_pll_lock_wait(struct samsung_clk_pll *pll,
> >> +unsigned int reg_mask)
> >> +{
> >> +   ktime_t timeout;
> >> +
> >> +   /* Wait until the PLL is in steady locked state */
> >> +   timeout = ktime_add_ms(ktime_get(), PLL_TIMEOUT_MS);
> >> +
> >> +   while (!(readl_relaxed(pll->con_reg) & reg_mask)) {
> >> +   if (ktime_after(ktime_get(), timeout)) {
> >> +   pr_err("%s: Could not lock PLL %s\n",
> >> +   __func__, clk_hw_get_name(&pll->hw));
> >> +   return -EFAULT;
> >> +   }
> >> +
> >> +   cpu_relax();
> >> +   }
>
> > Thanks for the patch! Good to have this consolidated. How about going
> > one step further and using the generic
> > readl_relaxed_poll_timeout_atomic() helper?
>
> Might be a good suggestion, I was considering those helpers but ended
> up not using them in the patch. The cpu_relax() call might also not be
> really needed now, when there is the ktime code within the loop.
> Having multiple occurrences of readl_relaxed_poll_timeout_atomic() could
> increase the code size due to inlining. How about keeping the
> samsung_pll_lock_wait() function and just changing its implementation?

Sounds good to me, thanks!

Best regards,
Tomasz

RE: [PATCH 2/2] exfat: unify name extraction

[Sungjong Seo]

> Name extraction in exfat_find_dir_entry() also doesn't care NameLength, so
> the name may be incorrect.
> Replace the name extraction in exfat_find_dir_entry() with using
> exfat_entry_set_cache and exfat_get_uniname_from_name_entries(),
> like exfat_readdir().
> Replace the name extraction with using exfat_entry_set_cache and
> exfat_get_uniname_from_name_entries(), like exfat_readdir().
> And, remove unused functions/parameters.
> 
> ** This patch depends on:
>   '[PATCH v3] exfat: integrates dir-entry getting and validation'.
> 
> Signed-off-by: Tetsuhiro Kohada 
> ---
>  fs/exfat/dir.c  | 161 ++--
>  fs/exfat/exfat_fs.h |   2 +-
>  fs/exfat/namei.c|   4 +-
>  3 files changed, 38 insertions(+), 129 deletions(-)
> 
> diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index
> 545bb73b95e9..c9715c7a55a1 100644
> --- a/fs/exfat/dir.c
> +++ b/fs/exfat/dir.c
> @@ -10,24 +10,6 @@
>  #include "exfat_raw.h"
>  #include "exfat_fs.h"
[snip]
> @@ -963,80 +942,38 @@ int exfat_find_dir_entry(struct super_block *sb,
> struct exfat_inode_info *ei,
>   num_empty = 0;
>   candi_empty.eidx = EXFAT_HINT_NONE;
> 
[snip]
> 
> - if (entry_type &
> - (TYPE_CRITICAL_SEC |
TYPE_BENIGN_SEC)) {
> - if (step == DIRENT_STEP_SECD) {
> - if (++order == num_ext)
> - goto found;
> - continue;
> - }
> + exfat_get_uniname_from_name_entries(es, &uni_name);

It is needed to check a return value.

> + exfat_free_dentry_set(es, false);
> +
> + if (!exfat_uniname_ncmp(sb,
> + p_uniname->name,
> + uni_name.name,
> + name_len)) {
> + /* set the last used position as hint */
> + hint_stat->clu = clu.dir;
> + hint_stat->eidx = dentry;

eidx and clu of hint_stat should have one for the next entry we'll start
looking for.
Did you intentionally change the concept?

> + return dentry;
>   }
> - step = DIRENT_STEP_FILE;
>   }
> 
>   if (clu.flags == ALLOC_NO_FAT_CHAIN) { @@ -1069,32 +1006,6
> @@ int exfat_find_dir_entry(struct super_block *sb, struct
> exfat_inode_info *ei,
>   hint_stat->clu = p_dir->dir;
>   hint_stat->eidx = 0;
>   return -ENOENT;
> -
> -found:
> - /* next dentry we'll find is out of this cluster */
> - if (!((dentry + 1) & (dentries_per_clu - 1))) {
> - int ret = 0;
> -
> - if (clu.flags == ALLOC_NO_FAT_CHAIN) {
> - if (--clu.size > 0)
> - clu.dir++;
> - else
> - clu.dir = EXFAT_EOF_CLUSTER;
> - } else {
> - ret = exfat_get_next_cluster(sb, &clu.dir);
> - }
> -
> - if (ret || clu.dir == EXFAT_EOF_CLUSTER) {
> - /* just initialized hint_stat */
> - hint_stat->clu = p_dir->dir;
> - hint_stat->eidx = 0;
> - return (dentry - num_ext);
> - }
> - }
> -
> - hint_stat->clu = clu.dir;
> - hint_stat->eidx = dentry + 1;
> - return dentry - num_ext;
>  }
> 
>  int exfat_count_ext_entries(struct super_block *sb, struct exfat_chain
> *p_dir, diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h index
> b88b7abc25bd..62a4768a4f6e 100644
> --- a/fs/exfat/exfat_fs.h
> +++ b/fs/exfat/exfat_fs.h
> @@ -456,7 +456,7 @@ void exfat_update_dir_chksum_with_entry_set(struct
> exfat_entry_set_cache *es);  int exfat_calc_num_entries(struct
> exfat_uni_name *p_uniname);  int exfat_find_dir_entry(struct super_block
> *sb, struct exfat_inode_info *ei,
>   struct exfat_chain *p_dir, struct exfat_uni_name *p_uniname,
> - int num_entries, unsigned int type);
> + int num_entries);
>  int exfat_alloc_new_dir(struct inode *inode, struct exfat_chain *clu);
> int exfat_find_location(struct super_block *sb, struct exfat_chain *p_dir,
>   int entry, sector_t *sector, int *offset); diff --git
> a/fs/exfat/namei.c b/fs/exfat/namei.c index a65d60ef93f4..c59d523547ca
> 100644
> --- a/fs/exfat/namei.c
> +++ b/fs/exfat/namei.c
> @@ -625,9 +625,7 @@ static int exfat_find(struct inode *dir, struct qstr
> *qname,
>   }
> 
>   /* search the file name for directories */
> - dentry = exfat_find_dir_entry(sb, ei, &cdir, &uni_name,
> - num_entries, TYPE_ALL);
> -
> + dentry = exfat_find_dir_entry(sb, ei, &cdir, &uni_name,
> num_entries);

[PATCH] drm/msm/a6xx: fix crashdec section name typo

[Rob Clark]

From: Rob Clark 

Backport note: maybe wait some time for the crashdec MR[1] to look for
both the old typo'd name and the corrected name to land in mesa 20.2

[1] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6242

Fixes: 1707add81551 ("drm/msm/a6xx: Add a6xx gpu state")
Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h 
b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
index 846fd5b54c23..2fb58b7098e4 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
@@ -372,7 +372,7 @@ static const struct a6xx_indexed_registers {
u32 data;
u32 count;
 } a6xx_indexed_reglist[] = {
-   { "CP_SEQ_STAT", REG_A6XX_CP_SQE_STAT_ADDR,
+   { "CP_SQE_STAT", REG_A6XX_CP_SQE_STAT_ADDR,
REG_A6XX_CP_SQE_STAT_DATA, 0x33 },
{ "CP_DRAW_STATE", REG_A6XX_CP_DRAW_STATE_ADDR,
REG_A6XX_CP_DRAW_STATE_DATA, 0x100 },
-- 
2.26.2

Re: [PATCH] mailmap: Update comments for with format and more detalis

[Joe Perches]

On Sat, 2020-08-08 at 00:14 -0700, Kees Cook wrote:
> Without having first read the git-shortlog man-page first, the format
> of .mailmap may not be immediately obvious. Add comments with pointers
> to the man-page, along with other details.
> 
> Signed-off-by: Kees Cook 
> ---
> I'm adding this to my earlier .mailmap update series:
> https://lore.kernel.org/lkml/20200730183702.702552-1-keesc...@chromium.org/
> ---
>  .mailmap | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/.mailmap b/.mailmap
> index 6c1c04a63b18..3a991e19928c 100644
> --- a/.mailmap
> +++ b/.mailmap
> @@ -2,11 +2,16 @@
>  # This list is used by git-shortlog

and scripts/get_maintainer.pl

Today, this list is primarily used not for
messed up email addresses.  It's mostly used
to map no longer in-use email addresses to
current email address.

>  to fix a few botched name translations
>  # in the git archive, either because the author's full name was messed up
>  # and/or not always written the same way, making contributions from the
> -# same person appearing not to be so or badly displayed.
> +# same person appearing not to be so or badly displayed. Also allows for
> +# old email addresses to map to new email addresses.
>  #
> +# For format details, see "MAPPING AUTHORS" in "man git-shortlog".
> +#
> +# Please keep this list dictionary sorted.
> +#
> +# This comment is parsed by git-shortlog:
>  # repo-abbrev: /pub/scm/linux/kernel/git/
>  #
> -
>  Aaron Durbin 
>  Adam Oldham 
>  Adam Radford 
> -- 
> 2.25.1
> 
> 

Re: [PATCH] [net/ipv6] ip6_output: Add ipv6_pinfo null check

[Cong Wang]

On Sat, Aug 8, 2020 at 10:07 AM Gaurav Singh  wrote:
>
> This PR fixes a possible segmentation violation.
>
> In function: ip6_xmit(), we have
> const struct ipv6_pinfo *np = inet6_sk(sk); which returns NULL
> unconditionally (regardless sk being  NULL or not).
>
> In include/linux/ipv6.h:
>
> static inline struct ipv6_pinfo * inet6_sk(const struct sock *__sk)
> {
> return NULL;
> }
>

Tell us who will use ip6_autoflowlabel() when CONFIG_IPV6
is disabled. :)

arch/powerpc/platforms/powernv/opal-fadump.c:70:46: sparse: sparse: incorrect type in assignment (different base types)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   449dc8c97089a6e09fb2dac4d92b1b7ac0eb7c1e
commit: 2a1b06dd3a17ac278494da3c15cac84684346d22 powerpc/fadump: process the 
crashdump by exporting it as /proc/vmcore
date:   11 months ago
config: powerpc64-randconfig-s032-20200808 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.2-118-ge1578773-dirty
git checkout 2a1b06dd3a17ac278494da3c15cac84684346d22
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc64 

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


sparse warnings: (new ones prefixed by >>)

   arch/powerpc/platforms/powernv/opal-fadump.c:37:41: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected unsigned 
long long [usertype] boot_mem_dest_addr @@ got restricted __be64 const 
[usertype] dest @@
   arch/powerpc/platforms/powernv/opal-fadump.c:37:41: sparse: expected 
unsigned long long [usertype] boot_mem_dest_addr
   arch/powerpc/platforms/powernv/opal-fadump.c:37:41: sparse: got 
restricted __be64 const [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:63:47: sparse: sparse: invalid 
assignment: +=
   arch/powerpc/platforms/powernv/opal-fadump.c:63:47: sparse:left side has 
type unsigned long
   arch/powerpc/platforms/powernv/opal-fadump.c:63:47: sparse:right side 
has type restricted __be64
>> arch/powerpc/platforms/powernv/opal-fadump.c:70:46: sparse: sparse: 
>> incorrect type in assignment (different base types) @@ expected unsigned 
>> long reserve_dump_area_start @@ got restricted __be64 const [usertype] 
>> dest @@
>> arch/powerpc/platforms/powernv/opal-fadump.c:70:46: sparse: expected 
>> unsigned long reserve_dump_area_start
   arch/powerpc/platforms/powernv/opal-fadump.c:70:46: sparse: got 
restricted __be64 const [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:105:58: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] src @@ got unsigned long long [assigned] [usertype] 
src_addr @@
   arch/powerpc/platforms/powernv/opal-fadump.c:105:58: sparse: expected 
restricted __be64 [usertype] src
   arch/powerpc/platforms/powernv/opal-fadump.c:105:58: sparse: got 
unsigned long long [assigned] [usertype] src_addr
   arch/powerpc/platforms/powernv/opal-fadump.c:106:58: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] dest @@ got unsigned long long [assigned] [usertype] 
dest_addr @@
   arch/powerpc/platforms/powernv/opal-fadump.c:106:58: sparse: expected 
restricted __be64 [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:106:58: sparse: got 
unsigned long long [assigned] [usertype] dest_addr
   arch/powerpc/platforms/powernv/opal-fadump.c:107:58: sparse: sparse: 
incorrect type in assignment (different base types) @@ expected restricted 
__be64 [usertype] size @@ got int [assigned] cur_size @@
   arch/powerpc/platforms/powernv/opal-fadump.c:107:58: sparse: expected 
restricted __be64 [usertype] size
   arch/powerpc/platforms/powernv/opal-fadump.c:107:58: sparse: got int 
[assigned] cur_size
   arch/powerpc/platforms/powernv/opal-fadump.c:119:53: sparse: sparse: 
restricted __be64 degrades to integer
   arch/powerpc/platforms/powernv/opal-fadump.c:171:56: sparse: sparse: 
incorrect type in argument 2 (different base types) @@ expected unsigned 
long long [usertype] src @@ got restricted __be64 [usertype] src @@
   arch/powerpc/platforms/powernv/opal-fadump.c:171:56: sparse: expected 
unsigned long long [usertype] src
   arch/powerpc/platforms/powernv/opal-fadump.c:171:56: sparse: got 
restricted __be64 [usertype] src
   arch/powerpc/platforms/powernv/opal-fadump.c:172:56: sparse: sparse: 
incorrect type in argument 3 (different base types) @@ expected unsigned 
long long [usertype] dest @@ got restricted __be64 [usertype] dest @@
   arch/powerpc/platforms/powernv/opal-fadump.c:172:56: sparse: expected 
unsigned long long [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:172:56: sparse: got 
restricted __be64 [usertype] dest
   arch/powerpc/platforms/powernv/opal-fadump.c:173:56: sparse: sparse: 
incorrect type in argument 4 (different base types) @@ expected unsigned 
long long [usertype] size @@ got restricted __be64 [usertype] size @@
   arch/powerpc/platforms/powernv/opal-fadump.c:173:56: sparse: expected