Re: [PATCH] net/mlx5: Add a missing macro undefinition

[Hu Haowen]

On 2020/6/7 2:36 PM, Leon Romanovsky wrote:

On Sun, Jun 07, 2020 at 01:12:40PM +0800, Hu Haowen wrote:

The macro ODP_CAP_SET_MAX is only used in function handle_hca_cap_odp()
in file main.c, so it should be undefined when there are no more uses
of it.

Signed-off-by: Hu Haowen 
---
  drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 ++
  1 file changed, 2 insertions(+)

"should be undefined" is s little bit over statement, but overall
the patch is good.



Sorry for my strong tone, but my idea is that every macro which is
defined and used just in a single function, is supposed to be undefined
at the end of its final use, so that you won't get into trouble next
time if you define a macro with the same name as this one.




Fixes: fca22e7e595f ("net/mlx5: ODP support for XRC transport is not enabled by 
default in FW")

Thanks,
Reviewed-by: Leon Romanovsky 

Re: Coccinelle: Improving software components around usage of SmPL disjunctions

[Markus Elfring]

>> But hiding information that could be apparent to the SmPL compiler
>> and could be used to improve the performance of the matching
>> process is not one of them.
>
> Will any software extensions become possible also in this area?

You pointed out that SmPL disjunctions can trigger specific consequences
according to functionality which is different from SmPL constraints.
Both application areas support data processing for function name lists
to some degree.
Each element of a SmPL disjunction refers to a fragment of a detailed
source code search pattern. We are discussing use cases where a search
pattern is occasionally restricted in the way that only identifiers
should be found at a specific place.

* Does this detail provide the opportunity to improve the corresponding
  software any more?

* Can a feature request like “Working with variables for case match
  identification by SmPL disjunctions” become more interesting?
  https://github.com/coccinelle/coccinelle/issues/159

Regards,
Markus

Re: [PATCH][next] RDMA/mlx5: remove duplicated assignment to resp.response_length

[Leon Romanovsky]

On Thu, Jun 04, 2020 at 03:39:02PM +0100, Colin King wrote:
> From: Colin Ian King 
>
> The assignment to resp.response_length is never read since it is being
> updated again on the next statement. The assignment is redundant so
> removed it.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/infiniband/hw/mlx5/qp.c | 2 --
>  1 file changed, 2 deletions(-)
>

Thanks,
Acked-by: Leon Romanovsky 

Re: [PATCH] net/mlx5: Add a missing macro undefinition

[Leon Romanovsky]

On Sun, Jun 07, 2020 at 01:12:40PM +0800, Hu Haowen wrote:
> The macro ODP_CAP_SET_MAX is only used in function handle_hca_cap_odp()
> in file main.c, so it should be undefined when there are no more uses
> of it.
>
> Signed-off-by: Hu Haowen 
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 ++
>  1 file changed, 2 insertions(+)

"should be undefined" is s little bit over statement, but overall
the patch is good.

Fixes: fca22e7e595f ("net/mlx5: ODP support for XRC transport is not enabled by 
default in FW")

Thanks,
Reviewed-by: Leon Romanovsky 

Re: Re: [PATCH] PCI: rcar: fix runtime pm imbalance on error

[dinghao . liu]

> >  
> >  err_pm_put:
> 
> You might want to remove this label too.

Thank you for pointing out this! I will fix this in the 
next version of patch.

Re: [PATCH 4.19 00/28] 4.19.127-rc1 review

[Naresh Kamboju]

On Fri, 5 Jun 2020 at 19:50, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.19.127 release.
> There are 28 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 07 Jun 2020 13:54:56 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.127-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.19.127-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.19.y
git commit: 65151bf9f715983d62613a4d9196525eb64dda53
git describe: v4.19.126-29-g65151bf9f715
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.19-oe/build/v4.19.126-29-g65151bf9f715


No regressions (compared to build v4.19.126)

No fixes (compared to build v4.19.126)


Ran 32146 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64
- x86-kasan

Test Suites
---
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-ipc-tests
* ltp-sched-tests
* perf
* v4l2-compliance
* ltp-commands-tests
* ltp-containers-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* network-basic-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net

-- 
Linaro LKFT
https://lkft.linaro.org

RE: [PATCH 1/2] habanalabs: block scalar load_and_exe on external queue

[Tomer Tayar]

On Sat, Jun 6, 2020 at 0:29, Oded Gabbay  wrote:
> In Gaudi, the user can't execute scalar load_and_exe on external queue
> because it can be a security hole. The driver doesn't parse the commands
> being loaded and it can be msg_prot, which the user isn't allowed to use.
> 
> Signed-off-by: Oded Gabbay 

Reviewed-by: Tomer Tayar 

Re: [PATCH v5 1/3] counter: 104-quad-8: Add lock guards - generic interface

[Syed Nayyar Waris]

On Sun, Jun 7, 2020 at 9:39 AM William Breathitt Gray
 wrote:
>
> On Sun, Jun 07, 2020 at 09:28:40AM +0530, Syed Nayyar Waris wrote:
> > On Sat, Apr 4, 2020 at 7:36 PM Jonathan Cameron  wrote:
> > >
> > > On Mon, 30 Mar 2020 23:54:32 +0530
> > > Syed Nayyar Waris  wrote:
> > >
> > > > Hi Jonathan
> > > >
> > > > >Looks good.  I'm not sure right now which tree I'll take this through
> > > > >(depends on whether it looks like we'll get an rc8 and hence I can 
> > > > >sneak
> > > > >it in for the coming merge window or not).
> > > > >
> > > > >So poke me if I seem to have forgotten to apply this in a week or so.
> > > >
> > > > Gentle Reminder.
> > > > Thanks !
> > > > Syed Nayyar Waris
> > >
> > > Thanks.  I've applied it to the fixes-togreg branch of iio.git which will 
> > > go
> > > upstream after the merge window closes.
> > >
> > > Thanks,
> > >
> > > Jonathan
> > >
> >
> > HI Jonathan,
> >
> > I think only the patch [1/3] has been applied. Patches [2/3] and [3/3] have 
> > not.
> >
> > The three patches were:
> > https://lore.kernel.org/patchwork/patch/1210135/
> > https://lore.kernel.org/patchwork/patch/1210136/
> > https://lore.kernel.org/patchwork/patch/1210137/
> >
> > The last 2 patches need to be applied, I think.
> >
> > Regards
> > Syed Nayyar Waris
>
> Just a heads-up: the relevant bugs are present in the 5.7 release so it
> would be prudent to tag those two patches with respective Fixes lines.
>
> William Breathitt Gray

Mentioning below, the 'Fixes' tags just for reference:
For patch [2/3]: counter: 104-quad-8: Add lock guards - differential encoder.
Fixes: bbef69e088c3 ("counter: 104-quad-8: Support Differential
Encoder Cable Status")

For patch [3/3]: counter: 104-quad-8: Add lock guards - filter clock prescaler.
Fixes: 9b74dddf79be ("counter: 104-quad-8: Support Filter Clock Prescaler")

I have replied on the v5 patches [2/3] and [3/3] with the (above)
'Fixes' tags. I have added the tags in the message.

I think that was what you meant.

Regards
Syed Nayyar Waris

[PATCH] habanalabs: rename mmu_write() to mmu_asid_va_write()

[Oded Gabbay]

The function name conflicts with a static inline function in
arch/m68k/include/asm/mcfmmu.h

Reported-by: kernel test robot 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/debugfs.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/habanalabs/debugfs.c 
b/drivers/misc/habanalabs/debugfs.c
index 3c8dcdfba20c..fc4372c18ce2 100644
--- a/drivers/misc/habanalabs/debugfs.c
+++ b/drivers/misc/habanalabs/debugfs.c
@@ -480,7 +480,7 @@ static int mmu_show(struct seq_file *s, void *data)
return 0;
 }
 
-static ssize_t mmu_write(struct file *file, const char __user *buf,
+static ssize_t mmu_asid_va_write(struct file *file, const char __user *buf,
size_t count, loff_t *f_pos)
 {
struct seq_file *s = file->private_data;
@@ -1125,7 +1125,7 @@ static const struct hl_info_list hl_debugfs_list[] = {
{"command_submission_jobs", command_submission_jobs_show, NULL},
{"userptr", userptr_show, NULL},
{"vm", vm_show, NULL},
-   {"mmu", mmu_show, mmu_write},
+   {"mmu", mmu_show, mmu_asid_va_write},
{"engines", engines_show, NULL}
 };
 
-- 
2.17.1

Re: [PATCH v5 3/3] counter: 104-quad-8: Add lock guards - filter clock prescaler

[Syed Nayyar Waris]

On Wed, Mar 18, 2020 at 7:48 AM William Breathitt Gray
 wrote:
>
> On Mon, Mar 16, 2020 at 06:20:46PM +0530, Syed Nayyar Waris wrote:
> > Add lock protection from race conditions to the 104-quad-8 counter
> > driver for filter clock prescaler code changes. Mutex calls used for
> > protection.
> >
> > Signed-off-by: Syed Nayyar Waris 
> > ---
> > Changes in v5:
> >  - Change spin lock calls to mutex lock calls.
> >  - Modify the title description.
>
> Signed-off-by: William Breathitt Gray 

Adding the 'Fixes' tag:

Fixes: 9b74dddf79be ("counter: 104-quad-8: Support Filter Clock Prescaler")

Regards
Syed Nayyar Waris

Re: [PATCH v5 2/3] counter: 104-quad-8: Add lock guards - differential encoder

[Syed Nayyar Waris]

On Wed, Mar 18, 2020 at 7:48 AM William Breathitt Gray
 wrote:
>
> On Mon, Mar 16, 2020 at 06:20:06PM +0530, Syed Nayyar Waris wrote:
> > Add lock protection from race conditions to 104-quad-8 counter driver
> > for differential encoder status code changes. Mutex lock calls used for
> > protection.
> >
> > Signed-off-by: Syed Nayyar Waris 
> > ---
> > Changes in v5:
> >  - Change spin lock calls to mutex lock calls.
> >  - Modify the title description.
>
> Looks like the Fixes tags were dropped in these last two patches. I
> suppose they aren't really necessary though since these features haven't
> yet made it out of the IIO tree, so no need to backport these fixes.
>
> Signed-off-by: William Breathitt Gray 

Adding the 'Fixes' tag:

Fixes: bbef69e088c3 ("counter: 104-quad-8: Support Differential
Encoder Cable Status")

Regards
Syed Nayyar Waris

[PATCH] net/mlx5: Add a missing macro undefinition

[Hu Haowen]

The macro ODP_CAP_SET_MAX is only used in function handle_hca_cap_odp()
in file main.c, so it should be undefined when there are no more uses
of it.

Signed-off-by: Hu Haowen 
---
 drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c 
b/drivers/net/ethernet/mellanox/mlx5/core/main.c
index df46b1fce3a7..1143297eccaa 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
@@ -489,6 +489,8 @@ static int handle_hca_cap_odp(struct mlx5_core_dev *dev, 
void *set_ctx)
ODP_CAP_SET_MAX(dev, dc_odp_caps.read);
ODP_CAP_SET_MAX(dev, dc_odp_caps.atomic);
 
+#undef ODP_CAP_SET_MAX
+
if (!do_set)
return 0;
 
-- 
2.25.1

Re: [PATCH 2/2][RFC] PM-runtime: add tracepoints to cover all usage_count changes

[Michal Miroslaw]

On Sat, Jun 06, 2020 at 03:14:59PM +0800, Chen Yu wrote:
> Hi,
> On Fri, Jun 05, 2020 at 09:33:11PM +0200, Michal Miroslaw wrote:
> > On Sat, Jun 06, 2020 at 03:05:52AM +0800, Chen Yu wrote:
> > > Commit d229290689ae ("PM-runtime: add tracepoints for usage_count 
> > > changes")
> > > has added some tracepoints to monitor the change of runtime usage, and
> > > there is something to improve:
> > > 1. There are some places that adjust the usage count have not
> > >been traced yet. For example, pm_runtime_get_noresume() and
> > >pm_runtime_put_noidle()
> > > 2. The change of the usage count will not be tracked if decreased
> > >from 1 to 0.
> > [...]
> > > @@ -1448,16 +1453,17 @@ EXPORT_SYMBOL_GPL(pm_runtime_forbid);
> > >   */
> > >  void pm_runtime_allow(struct device *dev)
> > >  {
> > > + bool is_zero;
> > > +
> > >   spin_lock_irq(&dev->power.lock);
> > >   if (dev->power.runtime_auto)
> > >   goto out;
> > >  
> > >   dev->power.runtime_auto = true;
> > > - if (atomic_dec_and_test(&dev->power.usage_count))
> > > + is_zero = atomic_dec_and_test(&dev->power.usage_count);
> > > + trace_rpm_usage_rcuidle(dev, RPM_AUTO | RPM_ASYNC);
> > > + if (is_zero)
> > >   rpm_idle(dev, RPM_AUTO | RPM_ASYNC);
> > > - else
> > > - trace_rpm_usage_rcuidle(dev, RPM_AUTO | RPM_ASYNC);
> > > -
> > [...]
> > 
> > IIRC, rpm_idle() has a tracepoint already.
> > 
> Yes, this is what I concerned previously. If someone
> want to track the change of usage_count, then he might
> have to enable both trace rpm_usage and rpm_idle so
> as to track the moment when the counter drops from 1 to
> 0. It might be more consistent if we only enable
> trace rpm_usage to track the whole process.
> > > @@ -1523,9 +1529,8 @@ static void update_autosuspend(struct device *dev, 
> > > int old_delay, int old_use)
> > >   /* If it used to be allowed then prevent it. */
> > >   if (!old_use || old_delay >= 0) {
> > >   atomic_inc(&dev->power.usage_count);
> > > - rpm_resume(dev, 0);
> > > - } else {
> > >   trace_rpm_usage_rcuidle(dev, 0);
> > > + rpm_resume(dev, 0);
> > >   }
> > >   }
> > [...]
> > 
> > This actually changes logic, so it doesn't match the patch description.
> > 
> This patch intends to adjust the logic to be consistent with
> the change of usage_counter, that is to say, only after the
> counter has been possibly modified, we record it. In current
> logic above, it tracks the usage count where the latter does
> not change.

I see now what you intended. I think it would be nice to put the idea
(that all usage changes be shown using rpm_usage even if included in
other trace points) into the commit message. Otherwise, looks ok.

Best Regards
Michał Mirosław

[PATCH 1/2] x86/amd_nb: Add Family 17h, Model 60h PCI IDs

[Jacky Hu]

Add the new Family 17h, Model 60h PCI IDs for AMD Zen2 APU systems.

Signed-off-by: Jacky Hu 
---
 arch/x86/kernel/amd_nb.c | 5 +
 drivers/hwmon/k10temp.c  | 2 ++
 include/linux/pci_ids.h  | 1 +
 3 files changed, 8 insertions(+)

diff --git a/arch/x86/kernel/amd_nb.c b/arch/x86/kernel/amd_nb.c
index b6b3297851f3..b57e7bd68885 100644
--- a/arch/x86/kernel/amd_nb.c
+++ b/arch/x86/kernel/amd_nb.c
@@ -18,9 +18,11 @@
 #define PCI_DEVICE_ID_AMD_17H_ROOT 0x1450
 #define PCI_DEVICE_ID_AMD_17H_M10H_ROOT0x15d0
 #define PCI_DEVICE_ID_AMD_17H_M30H_ROOT0x1480
+#define PCI_DEVICE_ID_AMD_17H_M60H_ROOT0x1630
 #define PCI_DEVICE_ID_AMD_17H_DF_F40x1464
 #define PCI_DEVICE_ID_AMD_17H_M10H_DF_F4 0x15ec
 #define PCI_DEVICE_ID_AMD_17H_M30H_DF_F4 0x1494
+#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F4 0x144c
 #define PCI_DEVICE_ID_AMD_17H_M70H_DF_F4 0x1444
 #define PCI_DEVICE_ID_AMD_19H_DF_F40x1654
 
@@ -33,6 +35,7 @@ static const struct pci_device_id amd_root_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_ROOT) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_ROOT) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M30H_ROOT) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M60H_ROOT) },
{}
 };
 
@@ -51,6 +54,7 @@ static const struct pci_device_id amd_nb_misc_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M30H_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F3) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M60H_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M70H_DF_F3) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_DF_F3) },
{}
@@ -65,6 +69,7 @@ static const struct pci_device_id amd_nb_link_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M30H_DF_F4) },
+   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M60H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_17H_M70H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_19H_DF_F4) },
{ PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_CNB17H_F4) },
diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index 9915578533bb..287e9cf2aab9 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -583,6 +583,7 @@ static int k10temp_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
k10temp_get_ccd_support(pdev, data, 4);
break;
case 0x31:  /* Zen2 Threadripper */
+   case 0x60:  /* Zen2 APU */
case 0x71:  /* Zen2 */
data->show_current = !is_threadripper() && !is_epyc();
data->cfactor[0] = CFACTOR_ICORE;
@@ -632,6 +633,7 @@ static const struct pci_device_id k10temp_id_table[] = {
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_DF_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M10H_DF_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M30H_DF_F3) },
+   { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M60H_DF_F3) },
{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_17H_M70H_DF_F3) },
{ PCI_VDEVICE(HYGON, PCI_DEVICE_ID_AMD_17H_DF_F3) },
{}
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 9a57e6717e5c..0ad57693f392 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -550,6 +550,7 @@
 #define PCI_DEVICE_ID_AMD_17H_DF_F30x1463
 #define PCI_DEVICE_ID_AMD_17H_M10H_DF_F3 0x15eb
 #define PCI_DEVICE_ID_AMD_17H_M30H_DF_F3 0x1493
+#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F3 0x144b
 #define PCI_DEVICE_ID_AMD_17H_M70H_DF_F3 0x1443
 #define PCI_DEVICE_ID_AMD_19H_DF_F30x1653
 #define PCI_DEVICE_ID_AMD_CNB17H_F30x1703
-- 
2.27.0

[PATCH 2/2] EDAC/amd64: Add family ops for Family 17h Models 60h-6Fh

[Jacky Hu]

Add family ops to support AMD Family 17h, Models 60h-6Fh systems.

Signed-off-by: Jacky Hu 
---
 drivers/edac/amd64_edac.c | 14 ++
 drivers/edac/amd64_edac.h |  3 +++
 2 files changed, 17 insertions(+)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 9cf7cc1f3f72..0e74027d3660 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2319,6 +2319,16 @@ static struct amd64_family_type family_types[] = {
.dbam_to_cs = f17_addr_mask_to_cs_size,
}
},
+   [F17_M60H_CPUS] = {
+   .ctl_name = "F17h_M60h",
+   .f0_id = PCI_DEVICE_ID_AMD_17H_M60H_DF_F0,
+   .f6_id = PCI_DEVICE_ID_AMD_17H_M60H_DF_F6,
+   .max_mcs = 2,
+   .ops = {
+   .early_channel_count= f17_early_channel_count,
+   .dbam_to_cs = f17_addr_mask_to_cs_size,
+   }
+   },
[F17_M70H_CPUS] = {
.ctl_name = "F17h_M70h",
.f0_id = PCI_DEVICE_ID_AMD_17H_M70H_DF_F0,
@@ -3357,6 +3367,10 @@ static struct amd64_family_type *per_family_init(struct 
amd64_pvt *pvt)
fam_type = &family_types[F17_M30H_CPUS];
pvt->ops = &family_types[F17_M30H_CPUS].ops;
break;
+   } else if (pvt->model >= 0x60 && pvt->model <= 0x6f) {
+   fam_type = &family_types[F17_M60H_CPUS];
+   pvt->ops = &family_types[F17_M60H_CPUS].ops;
+   break;
} else if (pvt->model >= 0x70 && pvt->model <= 0x7f) {
fam_type = &family_types[F17_M70H_CPUS];
pvt->ops = &family_types[F17_M70H_CPUS].ops;
diff --git a/drivers/edac/amd64_edac.h b/drivers/edac/amd64_edac.h
index abbf3c274d74..52b5d03eeba0 100644
--- a/drivers/edac/amd64_edac.h
+++ b/drivers/edac/amd64_edac.h
@@ -120,6 +120,8 @@
 #define PCI_DEVICE_ID_AMD_17H_M10H_DF_F6 0x15ee
 #define PCI_DEVICE_ID_AMD_17H_M30H_DF_F0 0x1490
 #define PCI_DEVICE_ID_AMD_17H_M30H_DF_F6 0x1496
+#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F0 0x1448
+#define PCI_DEVICE_ID_AMD_17H_M60H_DF_F6 0x144e
 #define PCI_DEVICE_ID_AMD_17H_M70H_DF_F0 0x1440
 #define PCI_DEVICE_ID_AMD_17H_M70H_DF_F6 0x1446
 #define PCI_DEVICE_ID_AMD_19H_DF_F00x1650
@@ -293,6 +295,7 @@ enum amd_families {
F17_CPUS,
F17_M10H_CPUS,
F17_M30H_CPUS,
+   F17_M60H_CPUS,
F17_M70H_CPUS,
F19_CPUS,
NUM_FAMILIES,
-- 
2.27.0

[PATCH 0/2] MCA and EDAC updates for AMD Family 17h, Model 60h

[Jacky Hu]

This patchset adds MCA and EDAC support for AMD Family 17h, Model 60h.

Also k10temp works with 4800h

k10temp-pci-00c3
Adapter: PCI adapter
Vcore: 1.55 V
Vsoc:  1.55 V
Tctl: +49.6°C
Tdie: +49.6°C
Icore: 0.00 A
Isoc:  0.00 A

Jacky Hu (2):
  x86/amd_nb: Add Family 17h, Model 60h PCI IDs
  EDAC/amd64: Add family ops for Family 17h Models 60h-6Fh

 arch/x86/kernel/amd_nb.c  |  5 +
 drivers/edac/amd64_edac.c | 14 ++
 drivers/edac/amd64_edac.h |  3 +++
 drivers/hwmon/k10temp.c   |  2 ++
 include/linux/pci_ids.h   |  1 +
 5 files changed, 25 insertions(+)

-- 
2.27.0

Re: [PATCH 1/5] RISC-V: Add mechanism to provide custom IPI operations

[Anup Patel]

On Fri, Jun 5, 2020 at 2:10 AM Palmer Dabbelt  wrote:
>
> On Thu, 21 May 2020 06:45:40 PDT (-0700), Anup Patel wrote:
> > We add mechanism to set custom IPI operations so that CLINT driver
> > from drivers directory can provide custom IPI operations.
> >
> > Signed-off-by: Anup Patel 
> > ---
> >  arch/riscv/include/asm/smp.h | 11 
> >  arch/riscv/kernel/smp.c  | 52 
> >  arch/riscv/kernel/smpboot.c  |  3 +--
> >  3 files changed, 47 insertions(+), 19 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> > index 40bb1c15a731..ad0601260cb1 100644
> > --- a/arch/riscv/include/asm/smp.h
> > +++ b/arch/riscv/include/asm/smp.h
> > @@ -40,6 +40,17 @@ void arch_send_call_function_single_ipi(int cpu);
> >  int riscv_hartid_to_cpuid(int hartid);
> >  void riscv_cpuid_to_hartid_mask(const struct cpumask *in, struct cpumask 
> > *out);
> >
> > +struct riscv_ipi_ops {
> > + void (*ipi_inject)(const unsigned long *hart_mask);
> > + void (*ipi_clear)(void);
> > +};
> > +
> > +/* Set custom IPI operations */
> > +void riscv_set_ipi_ops(struct riscv_ipi_ops *ops);
> > +
> > +/* Clear IPI for current CPU */
> > +void riscv_clear_ipi(void);
> > +
> >  /*
> >   * Obtains the hart ID of the currently executing task.  This relies on
> >   * THREAD_INFO_IN_TASK, but we define that unconditionally.
> > diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
> > index b1d4f452f843..8375cc5970f6 100644
> > --- a/arch/riscv/kernel/smp.c
> > +++ b/arch/riscv/kernel/smp.c
> > @@ -84,6 +84,35 @@ static void ipi_stop(void)
> >   wait_for_interrupt();
> >  }
> >
> > +#if IS_ENABLED(CONFIG_RISCV_SBI)
> > +static void clear_ipi(void)
> > +{
> > + csr_clear(CSR_IP, IE_SIE);
> > +}
> > +
> > +static struct riscv_ipi_ops sbi_ipi_ops = {
> > + .ipi_inject = sbi_send_ipi,
> > + .ipi_clear = clear_ipi,
> > +};
> > +
> > +static struct riscv_ipi_ops *ipi_ops = &sbi_ipi_ops;
> > +#else
> > +static struct riscv_ipi_ops *ipi_ops;
> > +#endif
> > +
> > +void riscv_set_ipi_ops(struct riscv_ipi_ops *ops)
> > +{
> > + ipi_ops = ops;
> > +}
> > +EXPORT_SYMBOL_GPL(riscv_set_ipi_ops);
> > +
> > +void riscv_clear_ipi(void)
> > +{
> > + if (ipi_ops)
> > + ipi_ops->ipi_clear();
> > +}
> > +EXPORT_SYMBOL_GPL(riscv_clear_ipi);
>
> There should at least be a warning on SMP systems when an ipi_ops hasn't been
> set, as otherwise the system will just hang.

Sure, I will add pr_warn() here.

>
> > +
> >  static void send_ipi_mask(const struct cpumask *mask, enum 
> > ipi_message_type op)
> >  {
> >   struct cpumask hartid_mask;
> > @@ -95,10 +124,9 @@ static void send_ipi_mask(const struct cpumask *mask, 
> > enum ipi_message_type op)
> >   smp_mb__after_atomic();
> >
> >   riscv_cpuid_to_hartid_mask(mask, &hartid_mask);
> > - if (IS_ENABLED(CONFIG_RISCV_SBI))
> > - sbi_send_ipi(cpumask_bits(&hartid_mask));
> > - else
> > - clint_send_ipi_mask(mask);
> > +
> > + if (ipi_ops)
> > + ipi_ops->ipi_inject(cpumask_bits(&hartid_mask));
> >  }
> >
> >  static void send_ipi_single(int cpu, enum ipi_message_type op)
> > @@ -109,18 +137,8 @@ static void send_ipi_single(int cpu, enum 
> > ipi_message_type op)
> >   set_bit(op, &ipi_data[cpu].bits);
> >   smp_mb__after_atomic();
> >
> > - if (IS_ENABLED(CONFIG_RISCV_SBI))
> > - sbi_send_ipi(cpumask_bits(cpumask_of(hartid)));
> > - else
> > - clint_send_ipi_single(hartid);
> > -}
> > -
> > -static inline void clear_ipi(void)
> > -{
> > - if (IS_ENABLED(CONFIG_RISCV_SBI))
> > - csr_clear(CSR_IP, IE_SIE);
> > - else
> > - clint_clear_ipi(cpuid_to_hartid_map(smp_processor_id()));
> > + if (ipi_ops)
> > + ipi_ops->ipi_inject(cpumask_bits(cpumask_of(hartid)));
> >  }
> >
> >  void handle_IPI(struct pt_regs *regs)
> > @@ -131,7 +149,7 @@ void handle_IPI(struct pt_regs *regs)
> >
> >   irq_enter();
> >
> > - clear_ipi();
> > + riscv_clear_ipi();
> >
> >   while (true) {
> >   unsigned long ops;
> > diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> > index 4e9922790f6e..5fe849791bf0 100644
> > --- a/arch/riscv/kernel/smpboot.c
> > +++ b/arch/riscv/kernel/smpboot.c
> > @@ -147,8 +147,7 @@ asmlinkage __visible void smp_callin(void)
> >  {
> >   struct mm_struct *mm = &init_mm;
> >
> > - if (!IS_ENABLED(CONFIG_RISCV_SBI))
> > - clint_clear_ipi(cpuid_to_hartid_map(smp_processor_id()));
> > + riscv_clear_ipi();
> >
> >   /* All kernel threads share the same mm context.  */
> >   mmgrab(mm);

Regards,
Anup

Re: [PATCH 4/5] clocksource/drivers: Add CLINT timer driver

[Anup Patel]

On Fri, Jun 5, 2020 at 2:10 AM Palmer Dabbelt  wrote:
>
> On Thu, 21 May 2020 06:45:43 PDT (-0700), Anup Patel wrote:
> > The TIME CSR and SBI calls are not available in RISC-V M-mode so we
> > add CLINT driver for Linux RISC-V M-mode (i.e. RISC-V NoMMU kernel).
> >
> > Signed-off-by: Anup Patel 
> > ---
> >  drivers/clocksource/Kconfig   |  10 ++
> >  drivers/clocksource/Makefile  |   1 +
> >  drivers/clocksource/timer-clint.c | 226 ++
> >  include/linux/cpuhotplug.h|   1 +
> >  4 files changed, 238 insertions(+)
> >  create mode 100644 drivers/clocksource/timer-clint.c
> >
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index 21950d9e3e9d..ea97bf0eb09f 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -659,6 +659,16 @@ config RISCV_TIMER
> > is accessed via both the SBI and the rdcycle instruction.  This is
> > required for all RISC-V systems.
> >
> > +config CLINT_TIMER
> > + bool "Timer for the RISC-V platform"
> > + depends on GENERIC_SCHED_CLOCK && RISCV
>
> Presumably this also depends on RISCV_M_MODE?

Ahh, good catch. I will update in v2.

>
> > + default y
> > + select TIMER_PROBE
> > + select TIMER_OF
> > + help
> > +   This option enables the CLINT timer for RISC-V systems. The CLINT
> > +   driver is usually used for NoMMU RISC-V systems.
> > +
> >  config CSKY_MP_TIMER
> >   bool "SMP Timer for the C-SKY platform" if COMPILE_TEST
> >   depends on CSKY
> > diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
> > index 641ba5383ab5..dca308b5ff98 100644
> > --- a/drivers/clocksource/Makefile
> > +++ b/drivers/clocksource/Makefile
> > @@ -86,6 +86,7 @@ obj-$(CONFIG_CLKSRC_ST_LPC) += clksrc_st_lpc.o
> >  obj-$(CONFIG_X86_NUMACHIP)   += numachip.o
> >  obj-$(CONFIG_ATCPIT100_TIMER)+= timer-atcpit100.o
> >  obj-$(CONFIG_RISCV_TIMER)+= timer-riscv.o
> > +obj-$(CONFIG_CLINT_TIMER)+= timer-clint.o
> >  obj-$(CONFIG_CSKY_MP_TIMER)  += timer-mp-csky.o
> >  obj-$(CONFIG_GX6605S_TIMER)  += timer-gx6605s.o
> >  obj-$(CONFIG_HYPERV_TIMER)   += hyperv_timer.o
> > diff --git a/drivers/clocksource/timer-clint.c 
> > b/drivers/clocksource/timer-clint.c
> > new file mode 100644
> > index ..7fc4f145da65
> > --- /dev/null
> > +++ b/drivers/clocksource/timer-clint.c
> > @@ -0,0 +1,226 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Western Digital Corporation or its affiliates.
> > + *
> > + * Most of the M-mode (i.e. NoMMU) RISC-V systems usually have a
> > + * CLINT MMIO timer device.
> > + */
> > +
> > +#define pr_fmt(fmt) "clint: " fmt
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define CLINT_IPI_OFF0
> > +#define CLINT_TIME_CMP_OFF   0x4000
> > +#define CLINT_TIME_VAL_OFF   0xbff8
> > +
> > +/* CLINT manages IPI and Timer for RISC-V M-mode  */
> > +static u32 __iomem *clint_ipi_base;
>
> It seems odd to have IPIs in the timer driver.  I know the CLINT handles both
> of them, but these really feel like two separate drivers.

AFAIK, there are no dedicated APIs in the kernel/irq subsystem for
IPI injections. Every architecture have their own way of registering
IPI injection mechanism. In ARM/ARM64, the arch code provides
set_smp_cross_call() API which drivers use to register IPI injections
mechanism. The PATCH1 of this series adds riscv_set_ipi_ops()
for this purpose.

Generally for most architectures (e.g. ARM, ARM64, MIPS, etc),
the IPI injections mechanism is registered from the irqchip driver
but for Linux RISC-V NoMMU the  IPI injection mechanism is
part of CLINT hence part of this CLINT driver.

Regards,
Anup

>
> > +static u64 __iomem *clint_time_cmp;
> > +static u64 __iomem *clint_time_val;
> > +static unsigned long clint_freq;
> > +static unsigned int clint_irq;
> > +
> > +static void clint_send_ipi(const unsigned long *hart_mask)
> > +{
> > + u32 hartid;
> > +
> > + for_each_set_bit(hartid, hart_mask, NR_CPUS)
> > + writel(1, clint_ipi_base + hartid);
> > +}
> > +
> > +static void clint_clear_ipi(void)
> > +{
> > + writel(0, clint_ipi_base + cpuid_to_hartid_map(smp_processor_id()));
> > +}
> > +
> > +static struct riscv_ipi_ops clint_ipi_ops = {
> > + .ipi_inject = clint_send_ipi,
> > + .ipi_clear = clint_clear_ipi,
> > +};
> > +
> > +#ifdef CONFIG_64BIT
> > +#define clint_get_cycles()   readq_relaxed(clint_time_val)
> > +#else
> > +#define clint_get_cycles()   readl_relaxed(clint_time_val)
> > +#define clint_get_cycles_hi()readl_relaxed(((u32 *)clint_time_val) 
> > + 1)
> > +#endif
> > +
> > +#ifdef CONFIG_64BIT
> > +static u64 clint_get_cycles64(void)
> > +{
> > + return clint

Re: [PATCH 3/5] clocksource/drivers/timer-riscv: Remove MMIO related stuff

[Anup Patel]

On Fri, Jun 5, 2020 at 2:10 AM Palmer Dabbelt  wrote:
>
> On Thu, 21 May 2020 06:45:42 PDT (-0700), Anup Patel wrote:
> > Right now the RISC-V timer is convoluted to support:
> > 1. Linux RISC-V S-mode (with MMU) where it will use TIME CSR
> >for clocksource and SBI timer calls for clockevent device.
> > 2. Linux RISC-V M-mode (without MMU) where it will use CLINT
> >MMIO counter register for clocksource and CLINT MMIO compare
> >register for clockevent device.
> >
> > This patch removes MMIO related stuff from RISC-V timer driver
> > so that we can have a separate CLINT timer driver.
>
> This one will also break bisecting for the K210.

Same comments as PATCH2. This only affects the NoMMU kernel
which is still not 100 % complete due to on-going userspace work.

Regards,
Anup

>
> >
> > Signed-off-by: Anup Patel 
> > ---
> >  arch/riscv/Kconfig|  2 +-
> >  arch/riscv/include/asm/timex.h| 28 +++-
> >  drivers/clocksource/Kconfig   |  2 +-
> >  drivers/clocksource/timer-riscv.c | 17 ++---
> >  4 files changed, 11 insertions(+), 38 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 2cf0c83c1a47..bbdc37a78f7b 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -52,7 +52,7 @@ config RISCV
> >   select PCI_DOMAINS_GENERIC if PCI
> >   select PCI_MSI if PCI
> >   select RISCV_INTC
> > - select RISCV_TIMER
> > + select RISCV_TIMER if RISCV_SBI
> >   select GENERIC_IRQ_MULTI_HANDLER
> >   select GENERIC_ARCH_TOPOLOGY if SMP
> >   select ARCH_HAS_PTE_SPECIAL
> > diff --git a/arch/riscv/include/asm/timex.h b/arch/riscv/include/asm/timex.h
> > index bad2a7c2cda5..a3fb85d505d4 100644
> > --- a/arch/riscv/include/asm/timex.h
> > +++ b/arch/riscv/include/asm/timex.h
> > @@ -7,41 +7,27 @@
> >  #define _ASM_RISCV_TIMEX_H
> >
> >  #include 
> > -#include 
> >
> >  typedef unsigned long cycles_t;
> >
> > -extern u64 __iomem *riscv_time_val;
> > -extern u64 __iomem *riscv_time_cmp;
> > -
> > -#ifdef CONFIG_64BIT
> > -#define mmio_get_cycles()readq_relaxed(riscv_time_val)
> > -#else
> > -#define mmio_get_cycles()readl_relaxed(riscv_time_val)
> > -#define mmio_get_cycles_hi() readl_relaxed(((u32 *)riscv_time_val) + 1)
> > -#endif
> > -
> >  static inline cycles_t get_cycles(void)
> >  {
> > - if (IS_ENABLED(CONFIG_RISCV_SBI))
> > - return csr_read(CSR_TIME);
> > - return mmio_get_cycles();
> > + return csr_read(CSR_TIME);
> >  }
> >  #define get_cycles get_cycles
> >
> > +static inline u32 get_cycles_hi(void)
> > +{
> > + return csr_read(CSR_TIMEH);
> > +}
> > +#define get_cycles_hi get_cycles_hi
> > +
> >  #ifdef CONFIG_64BIT
> >  static inline u64 get_cycles64(void)
> >  {
> >   return get_cycles();
> >  }
> >  #else /* CONFIG_64BIT */
> > -static inline u32 get_cycles_hi(void)
> > -{
> > - if (IS_ENABLED(CONFIG_RISCV_SBI))
> > - return csr_read(CSR_TIMEH);
> > - return mmio_get_cycles_hi();
> > -}
> > -
> >  static inline u64 get_cycles64(void)
> >  {
> >   u32 hi, lo;
> > diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
> > index f2142e6bbea3..21950d9e3e9d 100644
> > --- a/drivers/clocksource/Kconfig
> > +++ b/drivers/clocksource/Kconfig
> > @@ -650,7 +650,7 @@ config ATCPIT100_TIMER
> >
> >  config RISCV_TIMER
> >   bool "Timer for the RISC-V platform"
> > - depends on GENERIC_SCHED_CLOCK && RISCV
> > + depends on GENERIC_SCHED_CLOCK && RISCV_SBI
> >   default y
> >   select TIMER_PROBE
> >   select TIMER_OF
> > diff --git a/drivers/clocksource/timer-riscv.c 
> > b/drivers/clocksource/timer-riscv.c
> > index 5fb7c5ba5c91..3e7e0cf5b899 100644
> > --- a/drivers/clocksource/timer-riscv.c
> > +++ b/drivers/clocksource/timer-riscv.c
> > @@ -19,26 +19,13 @@
> >  #include 
> >  #include 
> >  #include 
> > -
> > -u64 __iomem *riscv_time_cmp;
> > -u64 __iomem *riscv_time_val;
> > -
> > -static inline void mmio_set_timer(u64 val)
> > -{
> > - void __iomem *r;
> > -
> > - r = riscv_time_cmp + cpuid_to_hartid_map(smp_processor_id());
> > - writeq_relaxed(val, r);
> > -}
> > +#include 
> >
> >  static int riscv_clock_next_event(unsigned long delta,
> >   struct clock_event_device *ce)
> >  {
> >   csr_set(CSR_IE, IE_TIE);
> > - if (IS_ENABLED(CONFIG_RISCV_SBI))
> > - sbi_set_timer(get_cycles64() + delta);
> > - else
> > - mmio_set_timer(get_cycles64() + delta);
> > + sbi_set_timer(get_cycles64() + delta);
> >   return 0;
> >  }

KASAN: null-ptr-deref Read in tty_wakeup

[Kyungtae Kim]

We report a bug (in linux-5.6.11) found by FuzzUSB (a modified version
of syzkaller)

This bug happened during enumeration (i.e., set_config) for an acm gadget.

Although tty (instance of tty_struct) held by port->port in
gs_start_io() is null,
this tries to access its field (tty->flags) in tty_wakeup(), thereby
triggering this error.

kernel config: https://kt0755.github.io/etc/config_v5.6.11

==
BUG: KASAN: null-ptr-deref in test_bit
include/asm-generic/bitops/instrumented-non-atomic.h:110 [inline]
BUG: KASAN: null-ptr-deref in tty_wakeup+0x25/0x110 drivers/tty/tty_io.c:532
Read of size 8 at addr 0460 by task systemd-udevd/2719

CPU: 2 PID: 2719 Comm: systemd-udevd Not tainted 5.6.11 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xce/0x128 lib/dump_stack.c:118
 __kasan_report+0x161/0x1b0 mm/kasan/report.c:510
 kasan_report+0x12/0x20 mm/kasan/common.c:641
 check_memory_region_inline mm/kasan/generic.c:185 [inline]
 check_memory_region+0x152/0x1b0 mm/kasan/generic.c:192
 __kasan_check_read+0x11/0x20 mm/kasan/common.c:95
 test_bit include/asm-generic/bitops/instrumented-non-atomic.h:110 [inline]
 tty_wakeup+0x25/0x110 drivers/tty/tty_io.c:532
 gs_start_io+0x1b7/0x2a0 drivers/usb/gadget/function/u_serial.c:568
 gserial_connect+0x41c/0x590 drivers/usb/gadget/function/u_serial.c:1333
 acm_set_alt+0x251/0x5c0 drivers/usb/gadget/function/f_acm.c:456
 set_config drivers/usb/gadget/composite.c:838 [inline]
 composite_setup+0x4231/0x6f10 drivers/usb/gadget/composite.c:1717
 configfs_composite_setup+0x11a/0x170 drivers/usb/gadget/configfs.c:1466
 dummy_timer+0xda5/0x33f0 drivers/usb/gadget/udc/dummy_hcd.c:1898
 call_timer_fn+0x20e/0x770 kernel/time/timer.c:1404
 expire_timers kernel/time/timer.c:1449 [inline]
 __run_timers kernel/time/timer.c:1773 [inline]
 run_timer_softirq+0x63f/0x13c0 kernel/time/timer.c:1786
 __do_softirq+0x262/0xb46 kernel/softirq.c:292
 invoke_softirq kernel/softirq.c:373 [inline]
 irq_exit+0x161/0x1b0 kernel/softirq.c:413
 exiting_irq arch/x86/include/asm/apic.h:546 [inline]
 smp_apic_timer_interrupt+0x137/0x500 arch/x86/kernel/apic/apic.c:1146
 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
 
RIP: 0010:create_object+0x74c/0xba0 mm/kmemleak.c:607
Code: e9 44 fc ff ff 65 48 8b 04 25 00 0f 02 00 48 8d b8 90 04 00 00
48 ba 00 00 00 00 00 fc ff df 48 89 fe 48 c1 ee 03 0f b6 14 16 <84> d2
74 09 80 fa 03 0f 8e be 01 00 00 49 8d bf 50 01 00 00 8b 90
RSP: 0018:88805ad17560 EFLAGS: 0a02 ORIG_RAX: ff13
RAX: 88803b448000 RBX: 0120 RCX: 816e25c4
RDX:  RSI: 111007689092 RDI: 88803b448490
RBP: 88805ad175b0 R08: ed100c9a128e R09: ed100c9a128e
R10: 0001 R11: ed100c9a128d R12: 888057bb8160
R13: 888064d09420 R14: 888064d09534 R15: 888064d093e0
 kmemleak_alloc+0x21/0x30 mm/kmemleak.c:893
 kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]
 slab_post_alloc_hook mm/slab.h:586 [inline]
 slab_alloc_node mm/slub.c:2786 [inline]
 slab_alloc mm/slub.c:2794 [inline]
 kmem_cache_alloc+0x157/0x2d0 mm/slub.c:2799
 __d_alloc+0x2e/0x8b0 fs/dcache.c:1690
 d_alloc+0x4d/0x250 fs/dcache.c:1769
 d_alloc_parallel+0xfe/0x1910 fs/dcache.c:2521
 __lookup_slow+0x195/0x440 fs/namei.c:1742
 lookup_slow fs/namei.c:1774 [inline]
 walk_component+0x779/0xe30 fs/namei.c:1915
 lookup_last fs/namei.c:2391 [inline]
 path_lookupat+0x151/0x3e0 fs/namei.c:2436
 filename_lookup+0x191/0x3a0 fs/namei.c:2466
 user_path_at_empty+0x40/0x50 fs/namei.c:2746
 user_path_at include/linux/namei.h:58 [inline]
 vfs_statx+0xe9/0x190 fs/stat.c:197
 vfs_lstat include/linux/fs.h:3277 [inline]
 __do_sys_newlstat+0x87/0xf0 fs/stat.c:364
 __se_sys_newlstat fs/stat.c:358 [inline]
 __x64_sys_newlstat+0x54/0x80 fs/stat.c:358
 do_syscall_64+0x9e/0x510 arch/x86/entry/common.c:294
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x7f473bb9f335
Code: 69 db 2b 00 64 c7 00 16 00 00 00 b8 ff ff ff ff c3 0f 1f 40 00
83 ff 01 48 89 f0 77 30 48 89 c7 48 89 d6 b8 06 00 00 00 0f 05 <48> 3d
00 f0 ff ff 77 03 f3 c3 90 48 8b 15 31 db 2b 00 f7 d8 64 89
RSP: 002b:7ffc79ada6f8 EFLAGS: 0246 ORIG_RAX: 0006
RAX: ffda RBX: 55d54f102c1a RCX: 7f473bb9f335
RDX: 7ffc79ada7b0 RSI: 7ffc79ada7b0 RDI: 7ffc79ada700
RBP: 7ffc79ada880 R08: fc00 R09: 
R10: 0007 R11: 0246 R12: 7ffc79ada890
R13: 7ffc79ada788 R14: 0018 R15: 55d54f846470
==

Re: [PATCH 2/5] RISC-V: Remove CLINT related code

[Anup Patel]

On Fri, Jun 5, 2020 at 2:10 AM Palmer Dabbelt  wrote:
>
> On Thu, 21 May 2020 06:45:41 PDT (-0700), Anup Patel wrote:
> > We will be having separate CLINT timer driver which will also
> > provide CLINT based IPI operations so let's remove CLINT related
> > code from arch/riscv directory.
>
> This will leave the system unbootable, which breaks bisecting.

This only affects the NoMMU kernel where userspace FPDPIC work
is still in-progress so NoMMU kernel is anyway not 100% complete
without upstreamed userspace support.

Are you suggesting to squash PATCH2, PATCH3, and PATCH4 for
preserving bistability ?

Regards,
Anup


>
> >
> > Signed-off-by: Anup Patel 
> > ---
> >  arch/riscv/include/asm/clint.h | 39 --
> >  arch/riscv/kernel/Makefile |  2 +-
> >  arch/riscv/kernel/clint.c  | 44 --
> >  arch/riscv/kernel/setup.c  |  2 --
> >  arch/riscv/kernel/smp.c|  1 -
> >  arch/riscv/kernel/smpboot.c|  1 -
> >  6 files changed, 1 insertion(+), 88 deletions(-)
> >  delete mode 100644 arch/riscv/include/asm/clint.h
> >  delete mode 100644 arch/riscv/kernel/clint.c
> >
> > diff --git a/arch/riscv/include/asm/clint.h b/arch/riscv/include/asm/clint.h
> > deleted file mode 100644
> > index a279b17a6aad..
> > --- a/arch/riscv/include/asm/clint.h
> > +++ /dev/null
> > @@ -1,39 +0,0 @@
> > -/* SPDX-License-Identifier: GPL-2.0 */
> > -#ifndef _ASM_RISCV_CLINT_H
> > -#define _ASM_RISCV_CLINT_H 1
> > -
> > -#include 
> > -#include 
> > -
> > -#ifdef CONFIG_RISCV_M_MODE
> > -extern u32 __iomem *clint_ipi_base;
> > -
> > -void clint_init_boot_cpu(void);
> > -
> > -static inline void clint_send_ipi_single(unsigned long hartid)
> > -{
> > - writel(1, clint_ipi_base + hartid);
> > -}
> > -
> > -static inline void clint_send_ipi_mask(const struct cpumask *mask)
> > -{
> > - int cpu;
> > -
> > - for_each_cpu(cpu, mask)
> > - clint_send_ipi_single(cpuid_to_hartid_map(cpu));
> > -}
> > -
> > -static inline void clint_clear_ipi(unsigned long hartid)
> > -{
> > - writel(0, clint_ipi_base + hartid);
> > -}
> > -#else /* CONFIG_RISCV_M_MODE */
> > -#define clint_init_boot_cpu()do { } while (0)
> > -
> > -/* stubs to for code is only reachable under 
> > IS_ENABLED(CONFIG_RISCV_M_MODE): */
> > -void clint_send_ipi_single(unsigned long hartid);
> > -void clint_send_ipi_mask(const struct cpumask *hartid_mask);
> > -void clint_clear_ipi(unsigned long hartid);
> > -#endif /* CONFIG_RISCV_M_MODE */
> > -
> > -#endif /* _ASM_RISCV_CLINT_H */
> > diff --git a/arch/riscv/kernel/Makefile b/arch/riscv/kernel/Makefile
> > index d8bbd3207100..529cda705cfe 100644
> > --- a/arch/riscv/kernel/Makefile
> > +++ b/arch/riscv/kernel/Makefile
> > @@ -31,7 +31,7 @@ obj-y   += cacheinfo.o
> >  obj-y+= patch.o
> >  obj-$(CONFIG_MMU) += vdso.o vdso/
> >
> > -obj-$(CONFIG_RISCV_M_MODE)   += clint.o traps_misaligned.o
> > +obj-$(CONFIG_RISCV_M_MODE)   += traps_misaligned.o
> >  obj-$(CONFIG_FPU)+= fpu.o
> >  obj-$(CONFIG_SMP)+= smpboot.o
> >  obj-$(CONFIG_SMP)+= smp.o
> > diff --git a/arch/riscv/kernel/clint.c b/arch/riscv/kernel/clint.c
> > deleted file mode 100644
> > index 3647980d14c3..
> > --- a/arch/riscv/kernel/clint.c
> > +++ /dev/null
> > @@ -1,44 +0,0 @@
> > -// SPDX-License-Identifier: GPL-2.0
> > -/*
> > - * Copyright (c) 2019 Christoph Hellwig.
> > - */
> > -
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -#include 
> > -
> > -/*
> > - * This is the layout used by the SiFive clint, which is also shared by 
> > the qemu
> > - * virt platform, and the Kendryte KD210 at least.
> > - */
> > -#define CLINT_IPI_OFF0
> > -#define CLINT_TIME_CMP_OFF   0x4000
> > -#define CLINT_TIME_VAL_OFF   0xbff8
> > -
> > -u32 __iomem *clint_ipi_base;
> > -
> > -void clint_init_boot_cpu(void)
> > -{
> > - struct device_node *np;
> > - void __iomem *base;
> > -
> > - np = of_find_compatible_node(NULL, NULL, "riscv,clint0");
> > - if (!np) {
> > - panic("clint not found");
> > - return;
> > - }
> > -
> > - base = of_iomap(np, 0);
> > - if (!base)
> > - panic("could not map CLINT");
> > -
> > - clint_ipi_base = base + CLINT_IPI_OFF;
> > - riscv_time_cmp = base + CLINT_TIME_CMP_OFF;
> > - riscv_time_val = base + CLINT_TIME_VAL_OFF;
> > -
> > - clint_clear_ipi(boot_cpu_hartid);
> > -}
> > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > index 145128a7e560..b07a583bf53b 100644
> > --- a/arch/riscv/kernel/setup.c
> > +++ b/arch/riscv/kernel/setup.c
> > @@ -18,7 +18,6 @@
> >  #include 
> >  #include 
> >
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -76,7 +75,6 @@ void __init setup_arch(char **cmdline_p)
> >   setup_bootmem();
> >   paging_init();
> >   unflatten_device_tree();
> > - clint_init_boo

Re: [PATCH v5 1/3] counter: 104-quad-8: Add lock guards - generic interface

[William Breathitt Gray]

On Sun, Jun 07, 2020 at 09:28:40AM +0530, Syed Nayyar Waris wrote:
> On Sat, Apr 4, 2020 at 7:36 PM Jonathan Cameron  wrote:
> >
> > On Mon, 30 Mar 2020 23:54:32 +0530
> > Syed Nayyar Waris  wrote:
> >
> > > Hi Jonathan
> > >
> > > >Looks good.  I'm not sure right now which tree I'll take this through
> > > >(depends on whether it looks like we'll get an rc8 and hence I can sneak
> > > >it in for the coming merge window or not).
> > > >
> > > >So poke me if I seem to have forgotten to apply this in a week or so.
> > >
> > > Gentle Reminder.
> > > Thanks !
> > > Syed Nayyar Waris
> >
> > Thanks.  I've applied it to the fixes-togreg branch of iio.git which will go
> > upstream after the merge window closes.
> >
> > Thanks,
> >
> > Jonathan
> >
> 
> HI Jonathan,
> 
> I think only the patch [1/3] has been applied. Patches [2/3] and [3/3] have 
> not.
> 
> The three patches were:
> https://lore.kernel.org/patchwork/patch/1210135/
> https://lore.kernel.org/patchwork/patch/1210136/
> https://lore.kernel.org/patchwork/patch/1210137/
> 
> The last 2 patches need to be applied, I think.
> 
> Regards
> Syed Nayyar Waris

Just a heads-up: the relevant bugs are present in the 5.7 release so it
would be prudent to tag those two patches with respective Fixes lines.

William Breathitt Gray


signature.asc
Description: PGP signature

Re: [PATCH v5 1/3] counter: 104-quad-8: Add lock guards - generic interface

[Syed Nayyar Waris]

On Sat, Apr 4, 2020 at 7:36 PM Jonathan Cameron  wrote:
>
> On Mon, 30 Mar 2020 23:54:32 +0530
> Syed Nayyar Waris  wrote:
>
> > Hi Jonathan
> >
> > >Looks good.  I'm not sure right now which tree I'll take this through
> > >(depends on whether it looks like we'll get an rc8 and hence I can sneak
> > >it in for the coming merge window or not).
> > >
> > >So poke me if I seem to have forgotten to apply this in a week or so.
> >
> > Gentle Reminder.
> > Thanks !
> > Syed Nayyar Waris
>
> Thanks.  I've applied it to the fixes-togreg branch of iio.git which will go
> upstream after the merge window closes.
>
> Thanks,
>
> Jonathan
>

HI Jonathan,

I think only the patch [1/3] has been applied. Patches [2/3] and [3/3] have not.

The three patches were:
https://lore.kernel.org/patchwork/patch/1210135/
https://lore.kernel.org/patchwork/patch/1210136/
https://lore.kernel.org/patchwork/patch/1210137/

The last 2 patches need to be applied, I think.

Regards
Syed Nayyar Waris

[PATCH] samples: binderfs: really compile this sample and fix build issues

[Masahiro Yamada]

Even after commit c624adc9cb6e ("samples: fix binderfs sample"), this
sample is never compiled.

'hostprogs' teaches Kbuild that this is a host program, but not enough
to order to compile it. You must add it to 'always-y' to really compile
it.

Since this sample has never been compiled in upstream, various issues
are left unnoticed.

[1] compilers without  are still widely used

 is only available since commit c13295ad219d
("binderfs: rename header to binderfs.h"), i.e., Linux 5.0

If your compiler is based on UAPI headers older than Linux 5.0, you
will see the following error:

  samples/binderfs/binderfs_example.c:16:10: fatal error: 
linux/android/binderfs.h: No such file or directory
   #include 
^~
  compilation terminated.

You cannot rely on compilers to have such a new header.

The common approach is to install UAPI headers of this kernel into
usr/include, and then add it to the header include path.

I added 'depends on HEADERS_INSTALL' in Kconfig, and '-I usr/include'
compiler flag in Makefile.

[2] compile the sample for target architecture

Since headers_install works for the target architecture, only the native
build was able to build sample code that requires '-I usr/include'.

Commit 7f3a59db274c ("kbuild: add infrastructure to build userspace
programs") added the new syntax 'userprogs' to compile user-space
programs for the target architecture.

Use it, and 'ifndef CROSS_COMPILE' will go away.

I added 'depends on CC_CAN_LINK' because $(CC) is not necessarily capable
of linking user-space programs.

[3] use subdir-y to descend into samples/binderfs/

Since this directory does not contain any kernel-space code, it has no
point to generate built-in.a or modules.order.

Replace obj-$(CONFIG_...) with subdir-$(CONFIG_...).

[4] -Wunused-variable warning

If I compile this, I see the following warning.

  samples/binderfs/binderfs_example.c: In function 'main':
  samples/binderfs/binderfs_example.c:21:9: warning: unused variable 'len' 
[-Wunused-variable]
 21 |  size_t len;
| ^~~

I removed the unused 'len'.

[5] CONFIG_ANDROID_BINDERFS is not required

Since this is a user-space standalone program, it is independent of
the kernel configuration.

Remove 'depends on ANDROID_BINDERFS'.

Fixes: 9762dc1432e1 ("samples: add binderfs sample program")
Fixes: c624adc9cb6e ("samples: fix binderfs sample")
Signed-off-by: Masahiro Yamada 
---

 samples/Kconfig | 2 +-
 samples/Makefile| 2 +-
 samples/binderfs/Makefile   | 9 -
 samples/binderfs/binderfs_example.c | 1 -
 4 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/samples/Kconfig b/samples/Kconfig
index 0cbb6146f3cf..953abbdebf7b 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -185,7 +185,7 @@ config SAMPLE_VFIO_MDEV_MBOCHS
 
 config SAMPLE_ANDROID_BINDERFS
bool "Build Android binderfs example"
-   depends on ANDROID_BINDERFS
+   depends on CC_CAN_LINK && HEADERS_INSTALL
help
  Builds a sample program to illustrate the use of the Android binderfs
  filesystem.
diff --git a/samples/Makefile b/samples/Makefile
index 29c66aadd954..4029d207cebb 100644
--- a/samples/Makefile
+++ b/samples/Makefile
@@ -2,7 +2,7 @@
 # Makefile for Linux samples code
 
 subdir-$(CONFIG_SAMPLE_AUXDISPLAY) += auxdisplay
-obj-$(CONFIG_SAMPLE_ANDROID_BINDERFS)  += binderfs/
+subdir-$(CONFIG_SAMPLE_ANDROID_BINDERFS) += binderfs
 obj-$(CONFIG_SAMPLE_CONFIGFS)  += configfs/
 obj-$(CONFIG_SAMPLE_CONNECTOR) += connector/
 subdir-$(CONFIG_SAMPLE_HIDRAW) += hidraw
diff --git a/samples/binderfs/Makefile b/samples/binderfs/Makefile
index a3ac5476338a..989e4badaee2 100644
--- a/samples/binderfs/Makefile
+++ b/samples/binderfs/Makefile
@@ -1,6 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0-only
-ifndef CROSS_COMPILE
-ifdef CONFIG_SAMPLE_ANDROID_BINDERFS
-hostprogs := binderfs_example
-endif
-endif
+userprogs := binderfs_example
+always-y := $(userprogs)
+
+userccflags += -I usr/include
diff --git a/samples/binderfs/binderfs_example.c 
b/samples/binderfs/binderfs_example.c
index 5bbd2ebc0aea..0fd92cdda460 100644
--- a/samples/binderfs/binderfs_example.c
+++ b/samples/binderfs/binderfs_example.c
@@ -18,7 +18,6 @@
 int main(int argc, char *argv[])
 {
int fd, ret, saved_errno;
-   size_t len;
struct binderfs_device device = { 0 };
 
ret = unshare(CLONE_NEWNS);
-- 
2.25.1

Re: [PATCH v3 17/25] mm: Add __page_cache_alloc_order

[Matthew Wilcox]

On Wed, May 06, 2020 at 11:03:06AM -0700, Yang Shi wrote:
> > diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h
> > index 55199cb5bd66..1169e2428dd7 100644
> > --- a/include/linux/pagemap.h
> > +++ b/include/linux/pagemap.h
> > @@ -205,15 +205,33 @@ static inline int page_cache_add_speculative(struct 
> > page *page, int count)
> > return __page_cache_add_speculative(page, count);
> >  }
> >
> > +static inline gfp_t thp_gfpmask(gfp_t gfp)
> > +{
> > +#ifdef CONFIG_TRANSPARENT_HUGEPAGE
> > +   /* We'd rather allocate smaller pages than stall a page fault */
> > +   gfp |= GFP_TRANSHUGE_LIGHT;
> 
> This looks not correct. GFP_TRANSHUGE_LIGHT may set GFP_FS, but some
> filesystem may expect GFP_NOFS, i.e. in readahead path.

Apologies, I overlooked this mail.

In one of the prerequisite patches for this patch set (which is now merged
as f2c817bed58d9be2051fad1d18e167e173c0c227), we call memalloc_nofs_save()
in the readahead path.  That ensures all allocations will have GFP_NOFS
set by the time the page allocator sees them.

Thanks for checking on this.

Re: [PATCH v3 18/25] mm: Allow large pages to be added to the page cache

[Matthew Wilcox]

On Sun, May 03, 2020 at 08:10:36PM -0700, Matthew Wilcox wrote:
> On Wed, Apr 29, 2020 at 06:36:50AM -0700, Matthew Wilcox wrote:
> > @@ -886,7 +906,7 @@ static int __add_to_page_cache_locked(struct page *page,
> > /* Leave page->index set: truncation relies upon it */
> > if (!huge)
> > mem_cgroup_cancel_charge(page, memcg, false);
> > -   put_page(page);
> > +   page_ref_sub(page, nr);
> > return xas_error(&xas);
> >  }
> >  ALLOW_ERROR_INJECTION(__add_to_page_cache_locked, ERRNO);
> 
> This is wrong.  page_ref_sub() will not call __put_page() if the refcount
> gets to zero.  What do people prefer?

*sigh*.  It's not wrong.  The caller holds a reference on the page
already, so calling page_ref_sub() will never reduce the refcount to 0.
The latest version looks like this:

+   page_ref_sub(page, nr);
+   VM_BUG_ON_PAGE(page_count(page) <= 0, page);

Re: [PATCH v5 0/8] drm: rcar-du: Add Color Management Module (CMM)

[Laurent Pinchart]

Hello,

On Fri, Jun 05, 2020 at 03:53:15PM +0200, Jacopo Mondi wrote:
> On Fri, Jun 05, 2020 at 03:41:24PM +0200, Eugeniu Rosca wrote:
> > On Fri, Jun 05, 2020 at 03:29:00PM +0200, Jacopo Mondi wrote:
> >> On Wed, May 27, 2020 at 09:15:55AM +0200, Eugeniu Rosca wrote:
> >>> Could you kindly share the cross compilation steps for your kmsxx fork?
> >>
> >> I usually build it on the target :)
> >
> > Interesting approach. With ARM getting more and more potent, why not? :)
> 
> For 'small' utilities like kmsxx it's doable
> 
> >>> Just out of curiosity, have you ever tried to pull the display's HDMI
> >>> cable while reading from CM2_LUT_TBL?
> >>
> >> Ahem, not really :) Did I get you right, you mean disconnecting the
> >> HDMI cable from the board ?
> >
> > Right.
> 
> So, no, I have not tried. Do you see any intersting failure with the
> mainline version ?

Jacopo, would you be able to give this a try ?

> >>> At least with the out-of-tree CMM implementation [*], this sends the
> >>> R-Car3 reference targets into an unrecoverable freeze, with no lockup
> >>> reported by the kernel (i.e. looks like an serious HW issue).
> >>>
>  CMM functionalities are retained between suspend/resume cycles (tested 
>  with
>  suspend-to-idle) without requiring a re-programming of the LUT tables.
> >>>
> >>> Hmm. Is this backed up by any statement in the HW User's manual?
> >>> This comes in contrast with the original Renesas CMM implementation [**]
> >>> which does make use of suspend (where the freeze actually happens).
> >>>
> >>> Can we infer, based on your statement, that we could also get rid of
> >>> the suspend callback in [**]?
> >>
> >> As Geert (thanks) explained what I've tested with is suspend-to-idle,
> >> which retains the state of the LUT tables (and I assume other
> >> not-yet-implemented CMM features, like CLU). I recall the out-of-tree
> >> driver has suspend/resume routines but I never really tested that.
> >
> > I see. JFYI, there is a flaw in the suspend handling in the out-of-tree
> > CMM patch [*], which renders the SoC unresponsive on HDMI hotplug. The
> > fix is currently under review. Hopefully it will make its way to [*]
> > in the nearest future. Just to keep in mind for the moment when CMM
> > s2ram will become a mainline feature.
> 
> Thanks, let's keep this in mind. Next week I'll run a few tests again
> with s2ram and will get back to you.

Note that the CMM driver is controlled by the DU driver. As the DU
driver will reenable the display during resume, it will call
rcar_du_cmm_setup() at resume time, which will reprogram the CMM. There
should thus be no need for manual suspend/resume handling in the CMM as
far as I can tell, but we need to ensure that the CMM is suspended
before and resumed after the DU. I believe this could be implemented
using device links.

> >>> [*] https://github.com/renesas-rcar/du_cmm
> >>> [**] 
> >>> https://github.com/renesas-rcar/du_cmm/blob/c393ed49834bdbc/meta-rcar-gen3/recipes-kernel/linux/linux-renesas/0001-drm-rcar-du-Add-DU-CMM-support.patch#L1912

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2] media: vsp1: dl: Fix NULL pointer dereference on unbind

[Laurent Pinchart]

Hi Eugeniu,

Thank you for the patch.

Mauro, there's a question for you below.

On Tue, Jun 02, 2020 at 09:50:16PM +0200, Eugeniu Rosca wrote:
> In commit f3b98e3c4d2e16 ("media: vsp1: Provide support for extended
> command pools"), the vsp pointer used for referencing the VSP1 device
> structure from a command pool during vsp1_dl_ext_cmd_pool_destroy() was
> not populated.
> 
> Correctly assign the pointer to prevent the following
> null-pointer-dereference when removing the device:
> 
> [*] h3ulcb-kf #>
> echo fea28000.vsp > /sys/bus/platform/devices/fea28000.vsp/driver/unbind
>  Unable to handle kernel NULL pointer dereference at virtual address 
> 0028
>  Mem abort info:
>ESR = 0x9606
>EC = 0x25: DABT (current EL), IL = 32 bits
>SET = 0, FnV = 0
>EA = 0, S1PTW = 0
>  Data abort info:
>ISV = 0, ISS = 0x0006
>CM = 0, WnR = 0
>  user pgtable: 4k pages, 48-bit VAs, pgdp=0007318be000
>  [0028] pgd=0007333a1003, pud=0007333a6003, 
> pmd=
>  Internal error: Oops: 9606 [#1] PREEMPT SMP
>  Modules linked in:
>  CPU: 1 PID: 486 Comm: sh Not tainted 
> 5.7.0-rc6-arm64-renesas-00118-ge644645abf47 #185
>  Hardware name: Renesas H3ULCB Kingfisher board based on r8a77951 (DT)
>  pstate: 4005 (nZcv daif -PAN -UAO)
>  pc : vsp1_dlm_destroy+0xe4/0x11c
>  lr : vsp1_dlm_destroy+0xc8/0x11c
>  sp : 800012963b60
>  x29: 800012963b60 x28: 0006f83fc440
>  x27:  x26: 0006f5e13e80
>  x25: 0006f5e13ed0 x24: 0006f5e13ed0
>  x23: 0006f5e13ed0 x22: dead0122
>  x21: 0006f5e3a080 x20: 0006f5df2938
>  x19: 0006f5df2980 x18: 0003
>  x17:  x16: 0016
>  x15: 0003 x14: 000393c0
>  x13: 800011a5ec18 x12: 800011d8d000
>  x11: 0006f83fcc68 x10: 800011a53d70
>  x9 : 8000111f3000 x8 : 
>  x7 : 00210d00 x6 : 
>  x5 : 800010872e60 x4 : 0004
>  x3 : 78068000 x2 : 800012781000
>  x1 : 2c00 x0 : 
>  Call trace:
>   vsp1_dlm_destroy+0xe4/0x11c
>   vsp1_wpf_destroy+0x10/0x20
>   vsp1_entity_destroy+0x24/0x4c
>   vsp1_destroy_entities+0x54/0x130
>   vsp1_remove+0x1c/0x40
>   platform_drv_remove+0x28/0x50
>   __device_release_driver+0x178/0x220
>   device_driver_detach+0x44/0xc0
>   unbind_store+0xe0/0x104
>   drv_attr_store+0x20/0x30
>   sysfs_kf_write+0x48/0x70
>   kernfs_fop_write+0x148/0x230
>   __vfs_write+0x18/0x40
>   vfs_write+0xdc/0x1c4
>   ksys_write+0x68/0xf0
>   __arm64_sys_write+0x18/0x20
>   el0_svc_common.constprop.0+0x70/0x170
>   do_el0_svc+0x20/0x80
>   el0_sync_handler+0x134/0x1b0
>   el0_sync+0x140/0x180
>  Code: b4c2 f9403a60 d2800084 a9400663 (f9401400)
>  ---[ end trace 3875369841fb288a ]---
> 
> Fixes: f3b98e3c4d2e16 ("media: vsp1: Provide support for extended command 
> pools")
> Cc: sta...@vger.kernel.org # v4.19+
> Signed-off-by: Eugeniu Rosca 
> Reviewed-by: Kieran Bingham 
> Tested-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

Mauro, can this be applied as a v5.8 fix, or should I include it in a
pull request for v5.9 ?

> ---
> 
> Changes in v2:
>  - Rephrased the description based on Kieran's proposal
>  - Added the Reviewed-by/Tested-by signatures
>  - No change in the contents
> 
> ---
>  drivers/media/platform/vsp1/vsp1_dl.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c 
> b/drivers/media/platform/vsp1/vsp1_dl.c
> index d7b43037e500..e07b135613eb 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -431,6 +431,8 @@ vsp1_dl_cmd_pool_create(struct vsp1_device *vsp1, enum 
> vsp1_extcmd_type type,
>   if (!pool)
>   return NULL;
>  
> + pool->vsp1 = vsp1;
> +
>   spin_lock_init(&pool->lock);
>   INIT_LIST_HEAD(&pool->free);
>  

-- 
Regards,

Laurent Pinchart

Re: [GIT PULL] arch/sh updates for 5.8

[pr-tracker-bot]

The pull request you sent on Sat, 6 Jun 2020 12:56:22 -0400:

> git://git.libc.org/linux-sh tags/sh-for-5.8

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3b69e8b4571125bec1f77f886174fe6cab6b9d75

Thank you!

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

Re: [RFC PATCH 2/2] drm: xlnx: driver for Xilinx DSI TX Subsystem

[Laurent Pinchart]

Hi GVRao,

On Sun, May 31, 2020 at 05:41:50PM +, Venkateshwar Rao Gannavarapu wrote:
> On Sunday, May 24, 2020 8:38 AM, Laurent Pinchart wrote:
> > On Mon, May 04, 2020 at 11:43:48AM -0700, Hyun Kwon wrote:
> >> On Mon, 2020-04-20 at 14:20:56 -0700, Venkateshwar Rao Gannavarapu wrote:
> >>> The Xilinx MIPI DSI Tx Subsystem soft IP is used to display video
> >>> data from AXI-4 stream interface.
> >>>
> >>> It supports upto 4 lanes, optional register interface for the DPHY,
> >>
> >> I don't see the register interface for dphy support.
> >
> > I think the D-PHY should be supported through a PHY driver, as it seems to 
> > be
> > shared between different subsystems.
>
> IP has the provision to read DPHY register for debug purpose only.
> No programming of DPHY is required in subsystem.

Do you know if this is the same D-PHY as used in the CSI2-RX subsystem ?

> >>> multiple RGB color formats, command mode and video mode.
> >>> This is a MIPI-DSI host driver and provides DSI bus for panels.
> >>> This driver also helps to communicate with its panel using panel
> >>> framework.
> >>>
> >>> Signed-off-by: Venkateshwar Rao Gannavarapu 
> >>> 
> >>> ---
> >>>  drivers/gpu/drm/xlnx/Kconfig|  11 +
> >>>  drivers/gpu/drm/xlnx/Makefile   |   2 +
> >>>  drivers/gpu/drm/xlnx/xlnx_dsi.c | 755 
> >>> 
> >
> > Daniel Vetter has recently expressed his opiion that bridge drivers should 
> > go to
> > drivers/gpu/drm/bridge/. It would then be drivers/gpu/drm/bridge/xlnx/. I 
> > don't
> > have a strong opinion myself.
> >
> >>>  3 files changed, 768 insertions(+)
> >>>  create mode 100644 drivers/gpu/drm/xlnx/xlnx_dsi.c

[snip]

-- 
Regards,

Laurent Pinchart

Re: [PATCH v14 1/2] media: dt-bindings: media: xilinx: Add Xilinx MIPI CSI-2 Rx Subsystem

[Laurent Pinchart]

Hi Vishal,

On Thu, May 28, 2020 at 07:25:12AM +, Vishal Sagar wrote:
> On Wednesday, May 27, 2020 9:42 PM, Laurent Pinchart wrote:
> > On Wed, May 27, 2020 at 07:27:18PM +0530, Vishal Sagar wrote:
> > > Add bindings documentation for Xilinx MIPI CSI-2 Rx Subsystem.
> > >
> > > The Xilinx MIPI CSI-2 Rx Subsystem consists of a CSI-2 Rx controller,
> > > a D-PHY in Rx mode and a Video Format Bridge.
> > >
> > > Signed-off-by: Vishal Sagar 
> > > Reviewed-by: Hyun Kwon 
> > > Reviewed-by: Rob Herring 
> > > Reviewed-by: Luca Ceresoli 
> > > Reviewed-by: Laurent Pinchart 
> > > ---
> > > v14
> > > - Removed xlnx,csi-pxl-format from required properties
> > > - Added dependency of xlnx,csi-pxl-format on xlnx,vfb
> > > - End the yaml file with ...
> > > - Added Reviewed by Laurent
> > >
> > > v13
> > > - Based on Laurent's suggestions
> > > - Fixed the datatypes values as minimum and maximum
> > > - condition added for en-vcx property
> > >
> > > v12
> > > - Moved to yaml format
> > > - Update CSI-2 and D-PHY
> > > - Mention that bindings for D-PHY not here
> > > - reset -> video-reset
> > >
> > > v11
> > > - Modify compatible string from 4.0 to 5.0
> > >
> > > v10
> > > - No changes
> > >
> > > v9
> > > - Fix xlnx,vfb description.
> > > - s/Optional/Required endpoint property.
> > > - Move data-lanes description from Ports to endpoint property section.
> > >
> > > v8
> > > - Added reset-gpios optional property to assert video_aresetn
> > >
> > > v7
> > > - Removed the control name from dt bindings
> > > - Updated the example dt node name to csi2rx
> > >
> > > v6
> > > - Added "control" after V4L2_CID_XILINX_MIPICSISS_ACT_LANES as
> > > suggested by Luca
> > > - Added reviewed by Rob Herring
> > >
> > > v5
> > > - Incorporated comments by Luca Cersoli
> > > - Removed DPHY clock from description and example
> > > - Removed bayer pattern from device tree MIPI CSI IP
> > >   doesn't deal with bayer pattern.
> > >
> > > v4
> > > - Added reviewed by Hyun Kwon
> > >
> > > v3
> > > - removed interrupt parent as suggested by Rob
> > > - removed dphy clock
> > > - moved vfb to optional properties
> > > - Added required and optional port properties section
> > > - Added endpoint property section
> > >
> > > v2
> > > - updated the compatible string to latest version supported
> > > - removed DPHY related parameters
> > > - added CSI v2.0 related property (including VCX for supporting upto 16
> > >   virtual channels).
> > > - modified csi-pxl-format from string to unsigned int type where the value
> > >   is as per the CSI specification
> > > - Defined port 0 and port 1 as sink and source ports.
> > > - Removed max-lanes property as suggested by Rob and Sakari
> > >
> > >  .../bindings/media/xilinx/xlnx,csi2rxss.yaml   | 237
> > +
> > >  1 file changed, 237 insertions(+)
> > >  create mode 100644
> > > Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
> > > b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yaml
> > > new file mode 100644
> > > index 000..2282231
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/media/xilinx/xlnx,csi2rxss.yam
> > > +++ l
> > > @@ -0,0 +1,237 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/media/xilinx/xlnx,csi2rxss.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Xilinx MIPI CSI-2 Receiver Subsystem
> > > +
> > > +maintainers:
> > > +  - Vishal Sagar 
> > > +
> > > +description: |
> > > +  The Xilinx MIPI CSI-2 Receiver Subsystem is used to capture MIPI
> > > +CSI-2
> > > +  traffic from compliant camera sensors and send the output as AXI4
> > > +Stream
> > > +  video data for image processing.
> > > +  The subsystem consists of a MIPI D-PHY in slave mode which captures
> > > +the
> > > +  data packets. This is passed along the MIPI CSI-2 Rx IP which
> > > +extracts the
> > > +  packet data. The optional Video Format Bridge (VFB) converts this
> > > +data to
> > > +  AXI4 Stream video data.
> > > +  For more details, please refer to PG232 Xilinx MIPI CSI-2 Receiver
> > Subsystem.
> > > +  Please note that this bindings includes only the MIPI CSI-2 Rx
> > > +controller
> > > +  and Video Format Bridge and not D-PHY.
> > > +
> > > +properties:
> > > +  compatible:
> > > +items:
> > > +  - enum:
> > > +- xlnx,mipi-csi2-rx-subsystem-5.0
> > > +
> > > +  reg:
> > > +maxItems: 1
> > > +
> > > +  interrupts:
> > > +maxItems: 1
> > > +
> > > +  clocks:
> > > +description: List of clock specifiers
> > > +items:
> > > +  - description: AXI Lite clock
> > > +  - description: Video clock
> > > +
> > > +  clock-names:
> > > +items:
> > > +  - const: lite_aclk
> > > +  - const: video_aclk
> > > +
> > > +  xlnx,csi-pxl-format:
> > > +description: |
> > > +   

Re: A panic and a hang in the i915 drm driver

[David Howells]

Here's the dmesg from a successful boot (commit
f84e1ba336a4f47ae251e4d2d8a694902571b0df).

David
---
[0.007455]   Normal   [mem 0x0001-0x00041fdf]
[0.007456] Movable zone start for each node
[0.007456] Early memory node ranges
[0.007457]   node   0: [mem 0x1000-0x00057fff]
[0.007458]   node   0: [mem 0x00059000-0x0009efff]
[0.007459]   node   0: [mem 0x0010-0xaf304fff]
[0.007460]   node   0: [mem 0xaf30c000-0xaf774fff]
[0.007460]   node   0: [mem 0xafbbd000-0xd8b7bfff]
[0.007461]   node   0: [mem 0xd9fff000-0xd9ff]
[0.007461]   node   0: [mem 0x0001-0x00041fdf]
[0.007845] Zeroed struct page in unavailable ranges: 31541 pages
[0.007846] Initmem setup node 0 [mem 0x1000-0x00041fdf]
[0.007848] On node 0 totalpages: 4162763
[0.007849]   DMA zone: 64 pages used for memmap
[0.007849]   DMA zone: 24 pages reserved
[0.007850]   DMA zone: 3997 pages, LIFO batch:0
[0.007901]   DMA32 zone: 13789 pages used for memmap
[0.007901]   DMA32 zone: 882478 pages, LIFO batch:63
[0.020153]   Normal zone: 51192 pages used for memmap
[0.020155]   Normal zone: 3276288 pages, LIFO batch:63
[0.064070] Reserving Intel graphics memory at [mem 0xdb20-0xdf1f]
[0.064144] ACPI: PM-Timer IO Port: 0x1808
[0.064146] ACPI: Local APIC address 0xfee0
[0.064150] ACPI: LAPIC_NMI (acpi_id[0xff] high edge lint[0x1])
[0.064159] IOAPIC[0]: apic_id 8, version 32, address 0xfec0, GSI 0-23
[0.064161] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[0.064162] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[0.064163] ACPI: IRQ0 used by override.
[0.064164] ACPI: IRQ9 used by override.
[0.064166] Using ACPI (MADT) for SMP configuration information
[0.064167] ACPI: HPET id: 0x8086a701 base: 0xfed0
[0.064171] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please 
update microcode to version: 0x22 (or later)
[0.064172] smpboot: Allowing 4 CPUs, 0 hotplug CPUs
[0.064198] [mem 0xdf20-0xf7ff] available for PCI devices
[0.064204] clocksource: refined-jiffies: mask: 0x max_cycles: 
0x, max_idle_ns: 7645519600211568 ns
[0.077227] setup_percpu: NR_CPUS:4 nr_cpumask_bits:4 nr_cpu_ids:4 
nr_node_ids:1
[0.077563] percpu: Embedded 54 pages/cpu s181200 r8192 d31792 u524288
[0.077569] pcpu-alloc: s181200 r8192 d31792 u524288 alloc=1*2097152
[0.077570] pcpu-alloc: [0] 0 1 2 3 
[0.077588] Built 1 zonelists, mobility grouping on.  Total pages: 4097694
[0.077588] Policy zone: Normal
[0.077590] Kernel command line: BOOT_IMAGE=/data/tftp/andromeda-vmlinuz 
ip=enp3s0:dhcp console=tty0 console=ttyS0,115200 ro root=/dev/sdb2
[0.079327] Dentry cache hash table entries: 2097152 (order: 12, 16777216 
bytes, linear)
[0.080136] Inode-cache hash table entries: 1048576 (order: 11, 8388608 
bytes, linear)
[0.080167] mem auto-init: stack:off, heap alloc:off, heap free:off
[0.159182] Memory: 16016000K/16651052K available (12290K kernel code, 1927K 
rwdata, 5372K rodata, 1608K init, 1296K bss, 635052K reserved, 0K cma-reserved)
[0.159242] Kernel/User page tables isolation: enabled
[0.159256] ftrace: allocating 47297 entries in 185 pages
[0.172236] ftrace: allocated 185 pages with 5 groups
[0.172293] rcu: Hierarchical RCU implementation.
[0.172294] rcu: RCU calculated value of scheduler-enlistment delay is 25 
jiffies.
[0.175046] NR_IRQS: 4352, nr_irqs: 456, preallocated irqs: 16
[0.175193] rcu: Offload RCU callbacks from CPUs: (none).
[0.175244] random: get_random_bytes called from start_kernel+0x3f5/0x5c0 
with crng_init=0
[0.175342] Console: colour dummy device 80x25
[0.175458] printk: console [tty0] enabled
[0.957870] printk: console [ttyS0] enabled
[0.960753] ACPI: Core revision 20200326
[0.963468] clocksource: hpet: mask: 0x max_cycles: 0x, 
max_idle_ns: 133484882848 ns
[0.971296] APIC: Switch to symmetric I/O mode setup
[0.975260] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=0 pin2=0
[0.999294] clocksource: tsc-early: mask: 0x max_cycles: 
0x6a6cab8f549, max_idle_ns: 881590883366 ns
[1.008503] Calibrating delay loop (skipped), value calculated using timer 
frequency.. 7383.19 BogoMIPS (lpj=14766392)
[1.012503] pid_max: default: 32768 minimum: 301
[1.024069] LSM: Security Framework initializing
[1.024510] Yama: becoming mindful.
[1.028507] SELinux:  Initializing.
[1.030772] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes, 
linear)
[1.032558] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 
bytes, linear)
[1.036710] mce: CPU0: Thermal monitoring enabled (TM1)
[1.040511] process: using mwait in idle threads
[1

Re: [kernfs] ea7c5fc39a: stress-ng.stream.ops_per_sec 11827.2% improvement

[Ian Kent]

On Sat, 2020-06-06 at 20:18 +0200, Greg Kroah-Hartman wrote:
> On Sat, Jun 06, 2020 at 11:52:16PM +0800, kernel test robot wrote:
> > Greeting,
> > 
> > FYI, we noticed a 11827.2% improvement of stress-
> > ng.stream.ops_per_sec due to commit:
> > 
> > 
> > commit: ea7c5fc39ab005b501e0c7666c29db36321e4f74 ("[PATCH 1/4]
> > kernfs: switch kernfs to use an rwsem")
> > url: 
> > https://github.com/0day-ci/linux/commits/Ian-Kent/kernfs-proposed-locking-and-concurrency-improvement/20200525-134849
> > 
> 
> Seriously?  That's a huge performance increase, and one that feels
> really odd.  Why would a stress-ng test be touching sysfs?

That is unusually high even if there's a lot of sysfs or kernfs
activity and that patch shouldn't improve VFS path walk contention
very much even if it is present.

Maybe I've missed something, and the information provided doesn't
seem to be quite enough to even make a start on it.

That's going to need some analysis which, for my part, will need to
wait probably until around rc1 time frame to allow me to get through
the push down stack (reactive, postponed due to other priorities) of
jobs I have in order to get back to the fifo queue (longer term tasks,
of which this is one) list of jobs I need to do as well, ;)

Please, kernel test robot, more information about this test and what
it's doing.

Ian

Re: [RFC PATCH] uvcvideo: Add mapping for HEVC payloads

[Laurent Pinchart]

Hi Dmitry,

Thank you for the patch.

On Fri, May 29, 2020 at 11:05:47AM +1000, Dmitry Buzdyk wrote:
> Add HEVC GUID and assotiate with HEVC pixel format so that frame
> based format descriptors recognized by the UVC video driver.

The patch itself looks OK to me, but could you share a bit more
information about which device(s) implement this ? Are they UVC 1.1
devices ? Could you share their full USB descriptors (retrieved with
'lsusb -v', running as root if possible) ?

Is there anything else needed to get HEVC capture working, such as
extension unit controls, or is this patch enough ? What userspace
software do you use to capture and decode HEVC (or capture it to disk) ?

> Signed-off-by: Dmitry Buzdyk 
> ---
>  drivers/media/usb/uvc/uvc_driver.c | 5 +
>  drivers/media/usb/uvc/uvcvideo.h   | 4 
>  2 files changed, 9 insertions(+)
> 
> diff --git a/drivers/media/usb/uvc/uvc_driver.c 
> b/drivers/media/usb/uvc/uvc_driver.c
> index 431d86e1c94b..825ee3601661 100644
> --- a/drivers/media/usb/uvc/uvc_driver.c
> +++ b/drivers/media/usb/uvc/uvc_driver.c
> @@ -214,6 +214,11 @@ static struct uvc_format_desc uvc_fmts[] = {
>   .guid   = UVC_GUID_FORMAT_CNF4,
>   .fcc= V4L2_PIX_FMT_CNF4,
>   },
> + {
> + .name   = "HEVC",
> + .guid   = UVC_GUID_FORMAT_HEVC,
> + .fcc= V4L2_PIX_FMT_HEVC,
> + },
>  };
>  
>  /* 
> diff --git a/drivers/media/usb/uvc/uvcvideo.h 
> b/drivers/media/usb/uvc/uvcvideo.h
> index 6ab972c643e3..c7f043121b41 100644
> --- a/drivers/media/usb/uvc/uvcvideo.h
> +++ b/drivers/media/usb/uvc/uvcvideo.h
> @@ -165,6 +165,10 @@
>   {0x32, 0x00, 0x00, 0x00, 0x02, 0x00, 0x10, 0x00, \
>0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
>  
> +#define UVC_GUID_FORMAT_HEVC \
> + { 'H',  'E',  'V',  'C', 0x00, 0x00, 0x10, 0x00, \
> +  0x80, 0x00, 0x00, 0xaa, 0x00, 0x38, 0x9b, 0x71}
> +
>  
>  /* 
>   * Driver specific constants.

-- 
Regards,

Laurent Pinchart

A panic and a hang in the i915 drm driver

[David Howells]

Hi,

I'm seeing the attached oops and panic from the i915 drm driver.  I've tried
bisecting it, but there's a problem in that one of the merged branches causes
the machine to hang without output.

The oops for commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 looks like:

BUG: kernel NULL pointer dereference, address: 
#PF: supervisor read access in kernel mode
#PF: error_code(0x) - not-present page
PGD 0 P4D 0 
Oops:  [#1] SMP PTI
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc2-fscache+ #883
Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014
RIP: 0010:intel_psr_enabled+0xb/0x6e
Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 10 
5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6 
83 5e 08 00 00 20 75 05 45 31 e4 eb 44 80
RSP: :88840dedfa18 EFLAGS: 00010246
RAX:  RBX: 8884086f9000 RCX: 
RDX: 0001 RSI: 8884086f9000 RDI: 0128
RBP: 8884086fb000 R08:  R09: 0001
R10: 0001 R11: 00ff R12: 88840868
R13:  R14:  R15: 8884086fb200
FS:  () GS:88840fb0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 0440c001 CR4: 001606e0
Call Trace:
 intel_read_dp_sdp+0x71/0x2c5
 hsw_crt_get_config+0x18/0x41
 intel_modeset_readout_hw_state+0x24d/0x662
 ? do_raw_spin_lock+0x8b/0xcd
 ? _raw_spin_lock_irqsave+0x10/0x16
 intel_modeset_setup_hw_state+0xa8/0xb59
 ? __next_node_in+0x39/0x42
 ? ww_mutex_lock+0x3d/0x1da
 ? modeset_lock+0xd4/0x114
 ? drm_modeset_lock_all_ctx+0x86/0xcc
 intel_modeset_init+0x285/0x5bf
 ? intel_irq_postinstall+0x485/0x4d1
 i915_driver_probe+0x1b4/0x49c
 ? __kernfs_new_node+0x161/0x1b2
 ? rpm_resume+0x45e/0x485
 i915_pci_probe+0xfd/0x11d
 ? __pm_runtime_resume+0x51/0x5e
 local_pci_probe+0x39/0x7a
 pci_device_probe+0xf5/0x14f
 ? sysfs_do_create_link_sd.isra.0+0x77/0xa3
 really_probe+0x140/0x2a9
 driver_probe_device+0x9c/0xd1
 device_driver_attach+0x3c/0x55
 __driver_attach+0x97/0x9f
 ? device_driver_attach+0x55/0x55
 bus_for_each_dev+0x72/0xa8
 bus_add_driver+0x108/0x1b9
 driver_register+0x9e/0xd7
 ? mipi_dsi_bus_init+0x11/0x11
 i915_init+0x58/0x6b
 do_one_initcall+0x83/0x18a
 kernel_init_freeable+0x19b/0x1fd
 ? rest_init+0x9f/0x9f
 kernel_init+0xa/0xfa
 ret_from_fork+0x1f/0x30
Modules linked in:
CR2: 
---[ end trace d0c4f561618aeb37 ]---
RIP: 0010:intel_psr_enabled+0xb/0x6e
Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 10 
5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6 
83 5e 08 00 00 20 75 05 45 31 e4 eb 44 80
RSP: :88840dedfa18 EFLAGS: 00010246
RAX:  RBX: 8884086f9000 RCX: 
RDX: 0001 RSI: 8884086f9000 RDI: 0128
RBP: 8884086fb000 R08:  R09: 0001
R10: 0001 R11: 00ff R12: 88840868
R13:  R14:  R15: 8884086fb200
FS:  () GS:88840fb0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 0440c001 CR4: 001606e0
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x0009 ]---


Decoding the RIP gives:

RIP: 0010:intel_psr_enabled 
(/data/fs/linux-fs/build3/../drivers/gpu/drm/i915/display/intel_display_types.h:1595
 /data/fs/linux-fs/build3/../drivers/gpu/drm/i915/display/intel_psr.c:1598) 



Commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 ("Merge tag
'drm-intel-next-fixes-2020-05-20' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next") is definitely bad
and logs an oops to the console and panics, but it's a merge.

On one side is e20bb857dea2f620ff37ae541ed8aee70e3c89f1 ("Merge tag
'exynos-drm-next-for-v5.8' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-next"), which hangs.  This is also a merge.

One side of e20bb is f84e1ba336a4f47ae251e4d2d8a694902571b0df
("drm/exynos-vidi: convert platform driver to use dev_groups") which is good.

The other side of c4121 and e20bb derive from the same line of commits, with
three patches between.  All of these, down to at least
230982d8d8df7f9d9aa216840ea2db1df6ad5d37 ("drm/i915: Update DRIVER_DATE to
20200430") cause the machine to hang without any sort of console output.

Commit bfbe1744e4417986419236719922a9a7fda224d1 ("Merge tag
'amd-drm-next-5.8-2020-05-19' of git://people.freedesktop.org/~agd5f/linux
into drm-next") is good.

Commit 47e51832ae93534d872511ba557115722582d94c
("drm/i915/gvt: use context lrc_reg_state for shadow ppgtt override") is good.

I've attached the git log and the config file.

David

git bisect start

Greetings!

[Peter Flavel]

I have a legal business proposition for you worth $ 45,275,000.00. Reply back 
if you are interested
Kind regards,
Peter Flavel

Re: [PATCH 1/3] exfat: add error check when updating dir-entries

[Namjae Jeon]

2020-06-04 17:44 GMT+09:00, Tetsuhiro Kohada :
Hi Tetsuhiro,
> Add error check when synchronously updating dir-entries.
> Furthermore, add exfat_update_bhs(). It wait for write completion once
> instead of sector by sector.
This patch can be split into two also ?
>
> Suggested-by: Sungjong Seo 
> Signed-off-by: Tetsuhiro Kohada 
> ---
>  fs/exfat/dir.c  | 15 +--
>  fs/exfat/exfat_fs.h |  3 ++-
>  fs/exfat/file.c |  5 -
>  fs/exfat/inode.c|  8 +---
>  fs/exfat/misc.c | 19 +++
>  5 files changed, 39 insertions(+), 11 deletions(-)
>
> diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c
> index de43534aa299..3eb8386fb5f2 100644
> --- a/fs/exfat/dir.c
> +++ b/fs/exfat/dir.c
> @@ -602,16 +602,19 @@ void exfat_update_dir_chksum_with_entry_set(struct
> exfat_entry_set_cache *es)
>   es->modified = true;
>  }
>
> -void exfat_free_dentry_set(struct exfat_entry_set_cache *es, int sync)
> +int exfat_free_dentry_set(struct exfat_entry_set_cache *es, int sync)
>  {
> - int i;
> + int i, err = 0;
>
> - for (i = 0; i < es->num_bh; i++) {
> - if (es->modified)
> - exfat_update_bh(es->sb, es->bh[i], sync);
> - brelse(es->bh[i]);
> + if (es->modified) {
> + set_bit(EXFAT_SB_DIRTY, &EXFAT_SB(es->sb)->s_state);
EXFAT_SB_DIRTY set can be merged into exfat_update_bhs() ?
> + err = exfat_update_bhs(es->bh, es->num_bh, sync);
>   }
> +
> + for (i = 0; i < es->num_bh; i++)
> + err ? bforget(es->bh[i]):brelse(es->bh[i]);
>   kfree(es);
> + return err;
>  }
>
>  static int exfat_walk_fat_chain(struct super_block *sb,
> diff --git a/fs/exfat/exfat_fs.h b/fs/exfat/exfat_fs.h
> index 595f3117f492..f4fa0e833486 100644
> --- a/fs/exfat/exfat_fs.h
> +++ b/fs/exfat/exfat_fs.h
> @@ -462,7 +462,7 @@ struct exfat_dentry *exfat_get_dentry_cached(struct
> exfat_entry_set_cache *es,
>   int num);
>  struct exfat_entry_set_cache *exfat_get_dentry_set(struct super_block *sb,
>   struct exfat_chain *p_dir, int entry, unsigned int type);
> -void exfat_free_dentry_set(struct exfat_entry_set_cache *es, int sync);
> +int exfat_free_dentry_set(struct exfat_entry_set_cache *es, int sync);
>  int exfat_count_dir_entries(struct super_block *sb, struct exfat_chain
> *p_dir);
>
>  /* inode.c */
> @@ -515,6 +515,7 @@ void exfat_set_entry_time(struct exfat_sb_info *sbi,
> struct timespec64 *ts,
>  u16 exfat_calc_chksum16(void *data, int len, u16 chksum, int type);
>  u32 exfat_calc_chksum32(void *data, int len, u32 chksum, int type);
>  void exfat_update_bh(struct super_block *sb, struct buffer_head *bh, int
> sync);
> +int exfat_update_bhs(struct buffer_head **bhs, int nr_bhs, int sync);
>  void exfat_chain_set(struct exfat_chain *ec, unsigned int dir,
>   unsigned int size, unsigned char flags);
>  void exfat_chain_dup(struct exfat_chain *dup, struct exfat_chain *ec);
> diff --git a/fs/exfat/file.c b/fs/exfat/file.c
> index fce03f318787..37c8f04c1f8a 100644
> --- a/fs/exfat/file.c
> +++ b/fs/exfat/file.c
> @@ -153,6 +153,7 @@ int __exfat_truncate(struct inode *inode, loff_t
> new_size)
>   struct timespec64 ts;
>   struct exfat_dentry *ep, *ep2;
>   struct exfat_entry_set_cache *es;
> + int err;
>
>   es = exfat_get_dentry_set(sb, &(ei->dir), ei->entry,
>   ES_ALL_ENTRIES);
> @@ -187,7 +188,9 @@ int __exfat_truncate(struct inode *inode, loff_t
> new_size)
>   }
>
>   exfat_update_dir_chksum_with_entry_set(es);
> - exfat_free_dentry_set(es, inode_needs_sync(inode));
> + err = exfat_free_dentry_set(es, inode_needs_sync(inode));
> + if (err)
> + return err;
>   }
>
>   /* cut off from the FAT chain */
> diff --git a/fs/exfat/inode.c b/fs/exfat/inode.c
> index ef7cf7a6d187..c0bfd1a586aa 100644
> --- a/fs/exfat/inode.c
> +++ b/fs/exfat/inode.c
> @@ -77,8 +77,7 @@ static int __exfat_write_inode(struct inode *inode, int
> sync)
>   ep2->dentry.stream.size = ep2->dentry.stream.valid_size;
>
>   exfat_update_dir_chksum_with_entry_set(es);
> - exfat_free_dentry_set(es, sync);
> - return 0;
> + return exfat_free_dentry_set(es, sync);
>  }
>
>  int exfat_write_inode(struct inode *inode, struct writeback_control *wbc)
> @@ -222,6 +221,7 @@ static int exfat_map_cluster(struct inode *inode,
> unsigned int clu_offset,
>   if (ei->dir.dir != DIR_DELETED && modified) {
>   struct exfat_dentry *ep;
>   struct exfat_entry_set_cache *es;
> + int err;
>
>   es = exfat_get_dentry_set(sb, &(ei->dir), ei->entry,
>   ES_ALL_ENTRIES);
> @@ -240,7 +240,9 @@ static int exfat_map_cluster(struct inode *inode,
> unsigned int clu_offset,
>   ep->dentry.stream.v

Re: [PATCH 3/3] exfat: set EXFAT_SB_DIRTY and VOL_DIRTY at the same timing

[Namjae Jeon]

2020-06-06 18:22 GMT+09:00, Tetsuhiro Kohada :
> On 2020/06/05 16:32, Namjae Jeon wrote:
>>> Set EXFAT_SB_DIRTY flag in exfat_put_super().
>>>
>>> In some cases, can't clear VOL_DIRTY with 'sync'.
>>> ex:
>>>
>>> VOL_DIRTY is set when rmdir starts, but when non-empty-dir is detected,
>>> return error without setting
>>> EXFAT_SB_DIRTY.
>>> If performe 'sync' in this state, VOL_DIRTY will not be cleared.
>> Good catch.
>>
>> Can you split this patch into two? (Don't set VOL_DIRTY on -ENOTEMPTY and
>> Setting EXFAT_SB_DIRTY is
>> merged into exfat_set_vol_flag). I need to check the second one more.
>
> Can't do that.
>
> exfat_set_vol_flag() is called when rmdir processing begins. When Not-empty
> is detected,
> VOL_DIRTY has already been written and synced to the media.
You can move it before calling exfat_remove_entries().
>
> This sequence is same as other write functions.
> 
>  set VOL_DIRTY (write to the media)
>  preparation/state analysis
>  update bh & set SB_DIRTY
>  clear VOL_DIRTY (cached)
> 
>
> SB_DIRTY is set when updating bh.
> However, in some cases SB_DIRTY is not set.
> If SB_DIRTY is not set, exfat_sync_fs() does nothing.
>
> I thought there was a problem with separating VOL_DIRTY and SB_DIRTY.
> So I investigated the timing when these are set. Attach the caller graph.
> The green box is a function that sets SB_DIRTY directly.
> The red box is a function that calls exfat_set_vol_flag() and sets
> VOL_DIRTY.
> VOL_DIRTY is set on all paths before setting SB_DIRTY.
>
> I think VOL_DIRTY and SB_DIRTY should be set at the same time.
> That way, It is not necessary to set SB_DIRTY when updating bh.
>
> 
>  set VOL_DIRTY (actually write on media), and set SB_DIRTY
>  preparation/state analysis
>  update data
>  clear VOL_DIRTY (cached)
> 
>
> By doing this, sync is guaranteed if VOL_DIRTY is set by calling
> exfat_set_vol_flag.
>
> This change may still have problems, but it's little better than before, I
> think.
I need to check more if it is the best or there is more better way.

Thanks!
>
> BR
> ---
> Tetsuhiro Kohada 
>
>
>>
>> Thanks!
>>>
>>> Signed-off-by: Tetsuhiro Kohada 
>>> ---
>>>   fs/exfat/balloc.c   |  4 ++--
>>>   fs/exfat/dir.c  | 18 --
>>>   fs/exfat/exfat_fs.h |  2 +-
>>>   fs/exfat/fatent.c   |  6 +-
>>>   fs/exfat/misc.c |  3 +--
>>>   fs/exfat/namei.c| 12 ++--
>>>   fs/exfat/super.c|  3 +++
>>>   7 files changed, 22 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/fs/exfat/balloc.c b/fs/exfat/balloc.c index
>>> 4055eb00ea9b..a987919686c0 100644
>>> --- a/fs/exfat/balloc.c
>>> +++ b/fs/exfat/balloc.c
>>> @@ -158,7 +158,7 @@ int exfat_set_bitmap(struct inode *inode, unsigned
>>> int clu)
>>> b = BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx);
>>>
>>> set_bit_le(b, sbi->vol_amap[i]->b_data);
>>> -   exfat_update_bh(sb, sbi->vol_amap[i], IS_DIRSYNC(inode));
>>> +   exfat_update_bh(sbi->vol_amap[i], IS_DIRSYNC(inode));
>>> return 0;
>>>   }
>>>
>>> @@ -180,7 +180,7 @@ void exfat_clear_bitmap(struct inode *inode, unsigned
>>> int clu)
>>> b = BITMAP_OFFSET_BIT_IN_SECTOR(sb, ent_idx);
>>>
>>> clear_bit_le(b, sbi->vol_amap[i]->b_data);
>>> -   exfat_update_bh(sb, sbi->vol_amap[i], IS_DIRSYNC(inode));
>>> +   exfat_update_bh(sbi->vol_amap[i], IS_DIRSYNC(inode));
>>>
>>> if (opts->discard) {
>>> int ret_discard;
>>> diff --git a/fs/exfat/dir.c b/fs/exfat/dir.c index
>>> 3eb8386fb5f2..96c9a817d928 100644
>>> --- a/fs/exfat/dir.c
>>> +++ b/fs/exfat/dir.c
>>> @@ -468,7 +468,7 @@ int exfat_init_dir_entry(struct inode *inode, struct
>>> exfat_chain *p_dir,
>>> &ep->dentry.file.access_date,
>>> NULL);
>>>
>>> -   exfat_update_bh(sb, bh, IS_DIRSYNC(inode));
>>> +   exfat_update_bh(bh, IS_DIRSYNC(inode));
>>> brelse(bh);
>>>
>>> ep = exfat_get_dentry(sb, p_dir, entry + 1, &bh, §or); @@ -478,7
>>> +478,7 @@ int
>>> exfat_init_dir_entry(struct inode *inode, struct exfat_chain *p_dir,
>>> exfat_init_stream_entry(ep,
>>> (type == TYPE_FILE) ? ALLOC_FAT_CHAIN : ALLOC_NO_FAT_CHAIN,
>>> start_clu, size);
>>> -   exfat_update_bh(sb, bh, IS_DIRSYNC(inode));
>>> +   exfat_update_bh(bh, IS_DIRSYNC(inode));
>>> brelse(bh);
>>>
>>> return 0;
>>> @@ -514,7 +514,7 @@ int exfat_update_dir_chksum(struct inode *inode,
>>> struct exfat_chain *p_dir,
>>> }
>>>
>>> fep->dentry.file.checksum = cpu_to_le16(chksum);
>>> -   exfat_update_bh(sb, fbh, IS_DIRSYNC(inode));
>>> +   exfat_update_bh(fbh, IS_DIRSYNC(inode));
>>>   release_fbh:
>>> brelse(fbh);
>>> return ret;
>>> @@ -536,7 +536,7 @@ int exfat_init_ext_entry(struct inode *inode, struct
>>> exfat_chain *p_dir,
>>> return -EIO;
>>>
>>> ep->dentry.file.num_ext = (unsigned char)(num_entries - 1);
>>> -   exfat_update_bh(sb, bh, sync);
>>> +   exfat_update_bh(bh, sync);
>>> brelse(bh);
>>>
>>> ep = exfat_get_dentry(sb, 

linux-next test error: BUG: using smp_processor_id() in preemptible [ADDR] code: systemd-rfkill/6910

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:0e21d462 Add linux-next specific files for 20200602
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1461fcf210
kernel config:  https://syzkaller.appspot.com/x/.config?x=ecc1aef35f550ee3
dashboard link: https://syzkaller.appspot.com/bug?extid=c2a0ce95f0c47bcd4b37
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

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

BUG: using smp_processor_id() in preemptible [] code: 
systemd-rfkill/6910
caller is ext4_mb_new_blocks+0xa4d/0x3b70 fs/ext4/mballoc.c:4711
CPU: 0 PID: 6910 Comm: systemd-rfkill Not tainted 5.7.0-next-20200602-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+0x18f/0x20d lib/dump_stack.c:118
 check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
 ext4_mb_new_blocks+0xa4d/0x3b70 fs/ext4/mballoc.c:4711
 ext4_ext_map_blocks+0x201b/0x33e0 fs/ext4/extents.c:4244
 ext4_map_blocks+0x4cb/0x1640 fs/ext4/inode.c:626
 ext4_getblk+0xad/0x520 fs/ext4/inode.c:833
 ext4_bread+0x7c/0x380 fs/ext4/inode.c:883
 ext4_append+0x153/0x360 fs/ext4/namei.c:67
 ext4_init_new_dir fs/ext4/namei.c:2757 [inline]
 ext4_mkdir+0x5e0/0xdf0 fs/ext4/namei.c:2802
 vfs_mkdir+0x419/0x690 fs/namei.c:3632
 do_mkdirat+0x21e/0x280 fs/namei.c:3655
 do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:359
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7ff18513b687
Code: Bad RIP value.
RSP: 002b:7ffcc5bd1218 EFLAGS: 0246 ORIG_RAX: 0053
RAX: ffda RBX: 560bebc67985 RCX: 7ff18513b687
RDX: 7ffcc5bd10e0 RSI: 01ed RDI: 560bebc67985
RBP: 7ff18513b680 R08: 0100 R09: 
R10: 560bebc67980 R11: 0246 R12: 01ed
R13: 7ffcc5bd13a0 R14:  R15: 


---
This bug 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 bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

linux-next test error: BUG: using smp_processor_id() in preemptible [ADDR] code: kworker/u4:LINE/198

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:0e21d462 Add linux-next specific files for 20200602
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=107072f210
kernel config:  https://syzkaller.appspot.com/x/.config?x=ecc1aef35f550ee3
dashboard link: https://syzkaller.appspot.com/bug?extid=ca020d38a27ddc8e3cae
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)

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

BUG: using smp_processor_id() in preemptible [] code: kworker/u4:4/198
caller is ext4_mb_new_blocks+0xa4d/0x3b70 fs/ext4/mballoc.c:4711
CPU: 0 PID: 198 Comm: kworker/u4:4 Not tainted 5.7.0-next-20200602-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Workqueue: writeback wb_workfn (flush-8:0)
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 check_preemption_disabled+0x20d/0x220 lib/smp_processor_id.c:48
 ext4_mb_new_blocks+0xa4d/0x3b70 fs/ext4/mballoc.c:4711
 ext4_ext_map_blocks+0x201b/0x33e0 fs/ext4/extents.c:4244
 ext4_map_blocks+0x4cb/0x1640 fs/ext4/inode.c:626
 mpage_map_one_extent fs/ext4/inode.c:2377 [inline]
 mpage_map_and_submit_extent fs/ext4/inode.c:2430 [inline]
 ext4_writepages+0x1ab5/0x3400 fs/ext4/inode.c:2782
 do_writepages+0xfa/0x2a0 mm/page-writeback.c:2338
 __writeback_single_inode+0x12a/0x13d0 fs/fs-writeback.c:1453
 writeback_sb_inodes+0x515/0xdc0 fs/fs-writeback.c:1717
 __writeback_inodes_wb+0xc3/0x250 fs/fs-writeback.c:1786
 wb_writeback+0x8db/0xd50 fs/fs-writeback.c:1895
 wb_check_old_data_flush fs/fs-writeback.c:1997 [inline]
 wb_do_writeback fs/fs-writeback.c:2050 [inline]
 wb_workfn+0xab3/0x1090 fs/fs-writeback.c:2079
 process_one_work+0x965/0x1690 kernel/workqueue.c:2269
 worker_thread+0x96/0xe10 kernel/workqueue.c:2415
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
tipc: TX() has been purged, node left!


---
This bug 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 bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

RE: [PATCH v3 2/2] scsi: ufs: remove wrapper function ufshcd_setup_clocks()

[Winkler, Tomas]

> 
> From: Bean Huo 
> 
> The static function ufshcd_setup_clocks() is just a wrapper around
> __ufshcd_setup_clocks(), remove it. Rename original function wrapped
> __ufshcd_setup_clocks() to new ufshcd_setup_clocks().

Not sure about this change, we have only one call with skip_ref_clock set to 
true, the original code actually make sense from readability stand point. 

> 
> Signed-off-by: Bean Huo 
> ---
>  drivers/scsi/ufs/ufshcd.c | 32 
>  1 file changed, 12 insertions(+), 20 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
> ec4f55211648..531d0b7878db 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -215,9 +215,7 @@ static int ufshcd_eh_host_reset_handler(struct
> scsi_cmnd *cmd);  static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int
> tag);  static void ufshcd_hba_exit(struct ufs_hba *hba);  static int
> ufshcd_probe_hba(struct ufs_hba *hba, bool async); -static int
> __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
> -  bool skip_ref_clk);
> -static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
> +static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on, bool
> +skip_ref_clk);
>  static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);  static inline void
> ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);  static int
> ufshcd_host_reset_and_restore(struct ufs_hba *hba); @@ -1497,7 +1495,7
> @@ static void ufshcd_ungate_work(struct work_struct *work)
>   }
> 
>   spin_unlock_irqrestore(hba->host->host_lock, flags);
> - ufshcd_setup_clocks(hba, true);
> + ufshcd_setup_clocks(hba, true, false);
> 
>   ufshcd_enable_irq(hba);
> 
> @@ -1655,10 +1653,10 @@ static void ufshcd_gate_work(struct work_struct
> *work)
>   ufshcd_disable_irq(hba);
> 
>   if (!ufshcd_is_link_active(hba))
> - ufshcd_setup_clocks(hba, false);
> + ufshcd_setup_clocks(hba, false, false);
>   else
>   /* If link is active, device ref_clk can't be switched off */
> - __ufshcd_setup_clocks(hba, false, true);
> + ufshcd_setup_clocks(hba, false, true);
> 
>   /*
>* In case you are here to cancel this work the gating state @@ -
> 7683,8 +7681,7 @@ static int ufshcd_init_hba_vreg(struct ufs_hba *hba)
>   return 0;
>  }
> 
> -static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
> - bool skip_ref_clk)
> +static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on, bool
> +skip_ref_clk)
>  {
>   int ret = 0;
>   struct ufs_clk_info *clki;
> @@ -7747,11 +7744,6 @@ static int __ufshcd_setup_clocks(struct ufs_hba
> *hba, bool on,
>   return ret;
>  }
> 
> -static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on) -{
> - return  __ufshcd_setup_clocks(hba, on, false);
> -}
> -
>  static int ufshcd_init_clocks(struct ufs_hba *hba)  {
>   int ret = 0;
> @@ -7858,7 +7850,7 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
>   if (err)
>   goto out_disable_hba_vreg;
> 
> - err = ufshcd_setup_clocks(hba, true);
> + err = ufshcd_setup_clocks(hba, true, false);
>   if (err)
>   goto out_disable_hba_vreg;
> 
> @@ -7880,7 +7872,7 @@ static int ufshcd_hba_init(struct ufs_hba *hba)
>  out_disable_vreg:
>   ufshcd_setup_vreg(hba, false);
>  out_disable_clks:
> - ufshcd_setup_clocks(hba, false);
> + ufshcd_setup_clocks(hba, false, false);
>  out_disable_hba_vreg:
>   ufshcd_setup_hba_vreg(hba, false);
>  out:
> @@ -7896,7 +7888,7 @@ static void ufshcd_hba_exit(struct ufs_hba *hba)
>   if (ufshcd_is_clkscaling_supported(hba))
>   if (hba->devfreq)
>   ufshcd_suspend_clkscaling(hba);
> - ufshcd_setup_clocks(hba, false);
> + ufshcd_setup_clocks(hba, false, false);
>   ufshcd_setup_hba_vreg(hba, false);
>   hba->is_powered = false;
>   ufs_put_device_desc(hba);
> @@ -8259,10 +8251,10 @@ static int ufshcd_suspend(struct ufs_hba *hba,
> enum ufs_pm_op pm_op)
>   ufshcd_disable_irq(hba);
> 
>   if (!ufshcd_is_link_active(hba))
> - ufshcd_setup_clocks(hba, false);
> + ufshcd_setup_clocks(hba, false, false);
>   else
>   /* If link is active, device ref_clk can't be switched off */
> - __ufshcd_setup_clocks(hba, false, true);
> + ufshcd_setup_clocks(hba, false, true);
> 
>   hba->clk_gating.state = CLKS_OFF;
>   trace_ufshcd_clk_gating(dev_name(hba->dev), hba-
> >clk_gating.state); @@ -8321,7 +8313,7 @@ static int ufshcd_resume(struct
> ufs_hba *hba, enum ufs_pm_op pm_op)
> 
>   ufshcd_hba_vreg_set_hpm(hba);
>   /* Make sure clocks are enabled before accessing controller */
> - ret = ufshcd_setup_clocks(hba, true);
> + ret = ufshcd_setup_clocks(hba, true, false);
>   

RE: [PATCH v3 1/2] scsi: ufs: Add SPDX GPL-2.0 to replace GPL v2 boilerplate

[Winkler, Tomas]

> 
> From: Bean Huo 
> 
> Add SPDX GPL-2.0 to UFS driver files that specified the GPL version 2 license,
> remove the full boilerplate text.
> 
> Signed-off-by: Bean Huo 
LGTM.
Thanks
Tomas

> ---
>  drivers/scsi/ufs/ufs.h   | 27 +--
>  drivers/scsi/ufs/ufshcd-pci.c| 25 +
>  drivers/scsi/ufs/ufshcd-pltfrm.c | 27 +--
>  drivers/scsi/ufs/ufshcd.c| 30 +-
>  drivers/scsi/ufs/ufshcd.h| 27 +--
>  drivers/scsi/ufs/ufshci.h| 27 +--
>  6 files changed, 6 insertions(+), 157 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h index
> c70845d41449..7df4bdc813d6 100644
> --- a/drivers/scsi/ufs/ufs.h
> +++ b/drivers/scsi/ufs/ufs.h
> @@ -1,36 +1,11 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
>  /*
>   * Universal Flash Storage Host controller driver
> - *
> - * This code is based on drivers/scsi/ufs/ufs.h
>   * Copyright (C) 2011-2013 Samsung India Software Operations
>   *
>   * Authors:
>   *   Santosh Yaraganavi 
>   *   Vinayak Holikatti 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version 2
> - * of the License, or (at your option) any later version.
> - * See the COPYING file in the top-level directory or visit
> - * 
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * This program is provided "AS IS" and "WITH ALL FAULTS" and
> - * without warranty of any kind. You are solely responsible for
> - * determining the appropriateness of using and distributing
> - * the program and assume all risks associated with your exercise
> - * of rights with respect to the program, including but not limited
> - * to infringement of third party rights, the risks and costs of
> - * program errors, damage to or loss of data, programs or equipment,
> - * and unavailability or interruption of operations. Under no
> - * circumstances will the contributor of this Program be liable for
> - * any damages of any kind arising from your use or distribution of
> - * this program.
>   */
> 
>  #ifndef _UFS_H
> diff --git a/drivers/scsi/ufs/ufshcd-pci.c b/drivers/scsi/ufs/ufshcd-pci.c 
> index
> 8f78a8151499..f407b13883ac 100644
> --- a/drivers/scsi/ufs/ufshcd-pci.c
> +++ b/drivers/scsi/ufs/ufshcd-pci.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
>  /*
>   * Universal Flash Storage Host controller PCI glue driver
>   *
> @@ -7,30 +8,6 @@
>   * Authors:
>   *   Santosh Yaraganavi 
>   *   Vinayak Holikatti 
> - *
> - * This program is free software; you can redistribute it and/or
> - * modify it under the terms of the GNU General Public License
> - * as published by the Free Software Foundation; either version 2
> - * of the License, or (at your option) any later version.
> - * See the COPYING file in the top-level directory or visit
> - * 
> - *
> - * This program is distributed in the hope that it will be useful,
> - * but WITHOUT ANY WARRANTY; without even the implied warranty of
> - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> - * GNU General Public License for more details.
> - *
> - * This program is provided "AS IS" and "WITH ALL FAULTS" and
> - * without warranty of any kind. You are solely responsible for
> - * determining the appropriateness of using and distributing
> - * the program and assume all risks associated with your exercise
> - * of rights with respect to the program, including but not limited
> - * to infringement of third party rights, the risks and costs of
> - * program errors, damage to or loss of data, programs or equipment,
> - * and unavailability or interruption of operations. Under no
> - * circumstances will the contributor of this Program be liable for
> - * any damages of any kind arising from your use or distribution of
> - * this program.
>   */
> 
>  #include "ufshcd.h"
> diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c 
> b/drivers/scsi/ufs/ufshcd-pltfrm.c
> index 76f9be71c31b..3db0af66c71c 100644
> --- a/drivers/scsi/ufs/ufshcd-pltfrm.c
> +++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
> @@ -1,36 +1,11 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
>  /*
>   * Universal Flash Storage Host controller Platform bus based glue driver
> - *
> - * This code is based on drivers/scsi/ufs/ufshcd-pltfrm.c
>   * Copyright (C) 2011-2013 Samsung India Software Operations
>   *
>   * Authors:
>   *   Santosh Yaraganavi 
>   *   Vinayak Holikatti 
> - *
> - * This program is free software; you can redistribute it and

Re: [PATCH v7 2/4] lib/test_bitmap.c: Add for_each_set_clump test cases

[Syed Nayyar Waris]

On Fri, Jun 5, 2020 at 5:54 PM Andy Shevchenko
 wrote:
>
> On Fri, Jun 05, 2020 at 02:12:54AM +0530, Syed Nayyar Waris wrote:
> > On Sun, May 31, 2020 at 12:50 AM kbuild test robot  wrote:
>
> > > >> WARNING: modpost: lib/test_bitmap.o(.data+0xe80): Section mismatch in 
> > > >> reference from the variable clump_test_data to the variable 
> > > >> .init.rodata:clump_exp1
> > > The variable clump_test_data references
> > > the variable __initconst clump_exp1
> > > If the reference is valid then annotate the
> > > variable with or __refdata (see linux/init.h) or name the variable:
> > >
> > > --
> > > >> WARNING: modpost: lib/test_bitmap.o(.data+0xec8): Section mismatch in 
> > > >> reference from the variable clump_test_data to the variable 
> > > >> .init.rodata:clump_exp2
> > > The variable clump_test_data references
> > > the variable __initconst clump_exp2
> > > If the reference is valid then annotate the
> > > variable with or __refdata (see linux/init.h) or name the variable:
> > >
> > > --
> > > >> WARNING: modpost: lib/test_bitmap.o(.data+0xf10): Section mismatch in 
> > > >> reference from the variable clump_test_data to the variable 
> > > >> .init.rodata:clump_exp3
> > > The variable clump_test_data references
> > > the variable __initconst clump_exp3
> > > If the reference is valid then annotate the
> > > variable with or __refdata (see linux/init.h) or name the variable:
> > >
> > > --
> > > >> WARNING: modpost: lib/test_bitmap.o(.data+0xf58): Section mismatch in 
> > > >> reference from the variable clump_test_data to the variable 
> > > >> .init.rodata:clump_exp4
> > > The variable clump_test_data references
> > > the variable __initconst clump_exp4
> > > If the reference is valid then annotate the
> > > variable with or __refdata (see linux/init.h) or name the variable:
>
> > I am unable to reproduce the compilation warning.
>
> You have to enable section mismatch checker.
>
> > I ran the command:
> > make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'  lib/
> >
> > But the compilation warning didn't show up. Can anyone please point to me
> > what I am doing wrong here? How shall I reproduce the warning? Thanks !
>
> You put some data into init section of the object, while you are trying to
> access it from non-init one. It's easy-to-fix issue.
>
> --
> With Best Regards,
> Andy Shevchenko

Thanks! I have made code changes for the above warning. Actually I am
still unable to reproduce the compilation warning. But I believe the
following code fix will fix the compilation warning:

In file lib/test_bitmap.c

@@ -692,7 +692,7 @@ struct clump_test_data_params {
unsigned long const *exp;
 };

-struct clump_test_data_params clump_test_data[] =
+static struct clump_test_data_params clump_test_data[] __initdata =
{ {{0}, 2, 0, 64, 8, clump_exp1},
{{0}, 8, 2, 240, 24, clump_exp2},
{{0}, 8, 10, 240, 30, clump_exp3},



Let me know if I should submit a new patchset (v8) for
'for_each_set_clump' including above code fix.

Just to share how I attempted to reproduce the warning (but unsuccessful):

Step 1: Use the config file in attachment. Download, extract, rename
file to .config at the root of the tree.
Step 2: '$ make lib/'
No warning reproduced after above step 2.
Step 3: '$ make W=1 C=1 ARCH=x86_64 CF='-fdiagnostic-prefix
-D__CHECK_ENDIAN__' lib/'
After step 3 I got error in build:
scripts/kconfig/conf  --syncconfig Kconfig
  CHECK   scripts/mod/empty.c
No such file: asan-globals=1
scripts/Makefile.build:266: recipe for target 'scripts/mod/empty.o' failed
make[1]: *** [scripts/mod/empty.o] Error 1
Makefile:1147: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2

The command in above step 3 was mentioned in the bot mail.

Regards
Syed Nayyar Waris

Re: [RFC][PATCH 7/7] sched: Replace rq::wake_list

[Guenter Roeck]

On 6/5/20 9:15 AM, Eric Biggers wrote:
> On Fri, Jun 05, 2020 at 09:41:54AM +0200, Peter Zijlstra wrote:
>> On Thu, Jun 04, 2020 at 05:24:33PM -0700, Eric Biggers wrote:
>>> On Thu, Jun 04, 2020 at 07:18:37AM -0700, Guenter Roeck wrote:
 On Tue, May 26, 2020 at 06:11:04PM +0200, Peter Zijlstra wrote:
> The recent commit: 90b5363acd47 ("sched: Clean up scheduler_ipi()")
> got smp_call_function_single_async() subtly wrong. Even though it will
> return -EBUSY when trying to re-use a csd, that condition is not
> atomic and still requires external serialization.
>
> The change in ttwu_queue_remote() got this wrong.
>
> While on first reading ttwu_queue_remote() has an atomic test-and-set
> that appears to serialize the use, the matching 'release' is not in
> the right place to actually guarantee this serialization.
>
> The actual race is vs the sched_ttwu_pending() call in the idle loop;
> that can run the wakeup-list without consuming the CSD.
>
> Instead of trying to chain the lists, merge them.
>
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
 ...
> + /*
> +  * Assert the CSD_TYPE_TTWU layout is similar enough
> +  * for task_struct to be on the @call_single_queue.
> +  */
> + BUILD_BUG_ON(offsetof(struct task_struct, wake_entry_type) - 
> offsetof(struct task_struct, wake_entry) !=
> +  offsetof(struct __call_single_data, flags) - 
> offsetof(struct __call_single_data, llist));
> +

 There is no guarantee in C that

type1 a;
type2 b;

 in two different data structures means that offsetof(b) - offsetof(a)
 is the same in both data structures unless attributes such as
 __attribute__((__packed__)) are used.

 As result, this does and will cause a variety of build errors depending
 on the compiler version and compile flags.

 Guenter
>>>
>>> Yep, this breaks the build for me.
>>
>> -ENOCONFIG
> 
> For me, the problem seems to be randstruct.  To reproduce, you can use
> (on x86_64):
> 
>   make defconfig
>   echo CONFIG_GCC_PLUGIN_RANDSTRUCT=y >> .config
>   make olddefconfig
>   make kernel/smp.o
> 

I confirmed that disabling CONFIG_GCC_PLUGIN_RANDSTRUCT "fixes" the problem
in my test builds. Maybe it would make sense to mark that configuration option
for the time being as BROKEN.

Guenter

Re: [PATCH net] net: dp83869: Reset return variable if PHY strap is read

[David Miller]

From: Dan Murphy 
Date: Fri, 5 Jun 2020 15:51:03 -0500

> When the PHY's strap register is read to determine if lane swapping is
> needed the phy_read_mmd returns the value back into the ret variable.
> 
> If the call to read the strap fails the failed value is returned.  If
> the call to read the strap is successful then ret is possibly set to a
> non-zero positive number. Without reseting the ret value to 0 this will
> cause the parse DT function to return a failure.
> 
> Fixes: c4566aec6e808 ("net: phy: dp83869: Update port-mirroring to read 
> straps")
> Signed-off-by: Dan Murphy 

Applied, thank you.

Re: [PATCH] docs: it_IT: address invalid reference warnings

[Federico Vaga]

I re-read the documents with the full context.

Moving to the directive :doc: for only those two references (like I was 
arguing in the previous email) will make the document inconsistent.
So, the patch is fine for me as it is.

I will finish and push the translation for ../core-api/symbol-namespace.rst
and move the link again

On Tuesday, June 2, 2020 10:37:21 AM CEST Federico Vaga wrote:
> On Sunday, May 31, 2020 8:56:18 PM CEST Lukas Bulwahn wrote:
> > Documentation generation warns:
> >   it_IT/kernel-hacking/hacking.rst:
> > WARNING: unknown document: ../core-api/symbol/namespaces
> >   
> >   it_IT/process/5.Posting.rst:
> > WARNING: undefined label: it_email_clients
> >   
> >   it_IT/process/submitting-patches.rst:
> > WARNING: undefined label: it_email_clients
> >   
> >   it_IT/process/howto.rst:
> >  WARNING: undefined label: it_managementstyle
> > 
> > Refer to English documentation, as Italian translation does not exist,
> > and
> 
> The file exists! On my disk :D
> My mistake, I have an almost done translation for that and of course I do
> not see the warning.
> 
> > add labels for Italian process documents to resolve label references.
> 
> I think we have agreed to not use labels but instead to sue the directive
> 
> :doc: instead. This fix should happen in the document that points here. When
> :I
> posted the new translations I removed those labels but forgot to fix:
> it_IT/process/5.Posting.rst, it_IT/process/submitting-patches.rst and it_IT/
> process/howto.rst
> 
> :doc:`../process/email-clients`
> :doc:`../process/management-style`
> 
> I should be more meticulous and regenerate the full translation every time.
> Lesson learned. Sorry for that and thanks
> 
> > Signed-off-by: Lukas Bulwahn 
> > ---
> > Jonathan, please pick this quick fix of warnings.
> > 
> > applies on doc-next and next-20200529
> > 
> >  Documentation/translations/it_IT/kernel-hacking/hacking.rst   | 4 ++--
> >  Documentation/translations/it_IT/process/email-clients.rst| 2 ++
> >  Documentation/translations/it_IT/process/management-style.rst | 2 ++
> >  3 files changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> > b/Documentation/translations/it_IT/kernel-hacking/hacking.rst index
> > 6aab27a8d323..e9a2e92134f0 100644
> > --- a/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> > +++ b/Documentation/translations/it_IT/kernel-hacking/hacking.rst
> > @@ -634,7 +634,7 @@ Definita in ``include/linux/export.h``
> > 
> >  Questa è una variate di `EXPORT_SYMBOL()` che permette di specificare uno
> >  spazio dei nomi. Lo spazio dei nomi è documentato in
> > 
> > -:doc:`../core-api/symbol-namespaces`
> > +:doc:`../../../core-api/symbol-namespaces`
> > 
> >  :c:func:`EXPORT_SYMBOL_NS_GPL()`
> >  
> >  
> > 
> > @@ -643,7 +643,7 @@ Definita in ``include/linux/export.h``
> > 
> >  Questa è una variate di `EXPORT_SYMBOL_GPL()` che permette di specificare
> > 
> > uno spazio dei nomi. Lo spazio dei nomi è documentato in
> > -:doc:`../core-api/symbol-namespaces`
> > +:doc:`../../../core-api/symbol-namespaces`
> > 
> >  Procedure e convenzioni
> >  ===
> > 
> > diff --git a/Documentation/translations/it_IT/process/email-clients.rst
> > b/Documentation/translations/it_IT/process/email-clients.rst index
> > 89abf6d325f2..66d3d65776f7 100644
> > --- a/Documentation/translations/it_IT/process/email-clients.rst
> > +++ b/Documentation/translations/it_IT/process/email-clients.rst
> > @@ -3,6 +3,8 @@
> > 
> >  :Original: :doc:`../../../process/email-clients`
> >  :Translator: Alessia Mantegazza 
> > 
> > +.. _it_email_clients:
> > +
> > 
> >  Informazioni sui programmi di posta elettronica per Linux
> >  =
> > 
> > diff --git a/Documentation/translations/it_IT/process/management-style.rst
> > b/Documentation/translations/it_IT/process/management-style.rst index
> > c709285138a7..76ed074082ea 100644
> > --- a/Documentation/translations/it_IT/process/management-style.rst
> > +++ b/Documentation/translations/it_IT/process/management-style.rst
> > @@ -3,6 +3,8 @@
> > 
> >  :Original: :doc:`../../../process/management-style`
> >  :Translator: Alessia Mantegazza 
> > 
> > +.. _it_managementstyle:
> > +
> > 
> >  Il modello di gestione del kernel Linux
> >  ===

Re: [RFC PATCH 1/2] Drivers: hv: vmbus: Re-balance channel interrupts across CPUs at CPU hotplug

[Andrea Parri]

> > @@ -515,6 +519,8 @@ static void vmbus_add_channel_work(struct work_struct 
> > *work)
> > if (ret != 0) {
> > pr_err("unable to add child device object (relid %d)\n",
> > newchannel->offermsg.child_relid);
> > +   if (hv_is_perf_channel(newchannel))
> > +   free_chn_counts(&newchannel->device_obj->chn_cnt);
> 
> You could drop the "if" condition and just always call free_chn_counts() since
> it will do the right thing for non-perf channels where the memory was never
> allocated.

Well, AFAICT, the above would do the "right" thing for non-perf channels
without calling kfree() twice.  ;-)  It would also serve as a hard-coded
"reminder" of the fact that there is no alloc_chn_counts() for them.  No
strong opinions though, will drop for the next submission...


> > +static void filter_vp_index(struct hv_device *hv_dev, cpumask_var_t 
> > cpu_msk)
> > +{
> > +   /*
> > +* The selection of the target CPUs is performed in two domains,
> > +* the device domain and the connection domain.  At each domain,
> > +* in turn, invalid CPUs are filtered out at two levels, the CPU
> 
> I would drop the word "invalid".  You are filtering out CPUs that meet the
> criteria in the sentence starting after the colon below.

Agreed, will drop.


> > +static void balance_vp_index(struct vmbus_channel *chn,
> > +struct hv_device *hv_dev, cpumask_var_t cpu_msk)
> > +{
> > +   u32 cur_cpu = chn->target_cpu, tgt_cpu = cur_cpu;
> > +
> > +   if (chn->state != CHANNEL_OPENED_STATE) {
> > +   /*
> > +* The channel may never have been opened or it may be in
> > +* a closed/closing state; if so, do not touch the target
> > +* CPU of this channel.
> > +*/
> > +   goto update_chn_cnts;
> > +   }
> > +
> > +   /*
> > +* The channel was open, and it will remain open until we release
> > +* channel_mutex, cf. the use of channel_mutex and channel->state
> > +* in vmbus_disconnect_ring() -> vmbus_close_internal().
> > +*/
> > +
> > +   if (!hv_is_perf_channel(chn)) {
> > +   /*
> > +* Only used by the CPU hot removal path, remark that
> > +* the connect CPU can not go offline.
> 
> To be super explicit in the comment:  If the channel is not a
> performance channel, then it does not participate in the balancing,
> and we move it back to interrupting the VMBUS_CONNECT_CPU for
> lack of a better choice.  Because non-perf channels are initially set to 
> interrupt the VMBUS_CONNECT_CPU, the only way a non-perf channel
> could be found in this state (i.e., set to a CPU other than
> VMBUS_CONNECT_CPU) is a manual change through the sysfs interface.

The comment was indeed rather meant to make explicit a "please go read
the caller, carefully..." where, among other things, at least parts of
the remarks you pointed out above are spelled out.  But I won't be the
one stingy with comments!  ;-)  Will apply, thanks for the suggestion.


> > +void vmbus_balance_vp_indexes_at_cpuhp(unsigned int cpu, bool add)
> > +{
> > +   struct vmbus_channel *chn, *sc;
> > +   cpumask_var_t cpu_msk;
> > +
> > +   lockdep_assert_cpus_held();
> > +   lockdep_assert_held(&vmbus_connection.channel_mutex);
> > +
> > +   WARN_ON(!cpumask_test_cpu(cpu, cpu_online_mask));
> > +
> > +   /* See the header comment for vmbus_send_modifychannel(). */
> > +   if (vmbus_proto_version < VERSION_WIN10_V4_1)
> > +   return;
> > +
> > +   if (!alloc_cpumask_var(&cpu_msk, GFP_KERNEL))
> > +   return;
> > +
> > +   reset_chn_counts(&vmbus_connection.chn_cnt);
> > +
> > +   list_for_each_entry(chn, &vmbus_connection.chn_list, listentry) {
> > +   struct hv_device *dev = chn->device_obj;
> > +
> > +   /*
> > +* The device may not have been allocated/assigned to
> > +* the primary channel yet; if so, do not balance the
> > +* channels associated to this device.  If dev != NULL,
> > +* the synchronization on channel_mutex ensures that
> > +* the device's chn_cnt has been (properly) allocated
> > +* *and* initialized, cf. vmbus_add_channel_work().
> > +*/
> > +   if (dev == NULL)
> > +   continue;
> > +
> > +   /*
> > +* By design, non-"perf" channels do not take part in
> > +* the balancing process.
> > +*
> > +* The user may have assigned some non-"perf" channel
> > +* to this CPU.  To satisfy the user's request to hot
> > +* remove the CPU, we will re-assign such channels to
> > +* the connect CPU; cf. balance_vp_index().
> > +*/
> > +   if (!hv_is_perf_channel(chn)) {
> > +   if (add)
> > +   continue;
> > +   /*
> > +* Assume that the non-"perf" channel has no
> > +  

include/linux/compiler.h:350:38: error: call to '__compiletime_assert_7252' declared with attribute error: BUILD_BUG_ON failed: sizeof(struct ctio_crc2_to_fw) != 64

[kernel test robot]

Hi Bart,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   b170290c2836c40ab565736ba37681eb3dfd79b8
commit: df95f39ae76474d922d9be9c0260dc263c451b09 scsi: qla2xxx: Introduce the 
be_id_t and le_id_t data types for FC src/dst IDs
date:   10 months ago
config: arm-randconfig-s032-20200607 (attached as .config)
compiler: arm-linux-gnueabi-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-247-gcadbd124-dirty
git checkout df95f39ae76474d922d9be9c0260dc263c451b09
# save the attached .config to linux build tree
make W=1 C=1 ARCH=arm CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

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

All errors (new ones prefixed by >>, old ones prefixed by <<):

cc1: warning: arch/arm/plat-iop/include: No such file or directory 
[-Wmissing-include-dirs]
In file included from include/linux/kernel.h:11,
from drivers/scsi/qla2xxx/qla_def.h:10,
from drivers/scsi/qla2xxx/qla_os.c:7:
drivers/scsi/qla2xxx/qla_os.c: In function 'qla2x00_module_init':
include/linux/compiler.h:350:38: error: call to '__compiletime_assert_7238' 
declared with attribute error: BUILD_BUG_ON failed: sizeof(cmd_entry_t) != 64
350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
|  ^
include/linux/compiler.h:331:4: note: in definition of macro 
'__compiletime_assert'
331 |prefix ## suffix(); |^~
include/linux/compiler.h:350:2: note: in expansion of macro 
'_compiletime_assert'
350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
|  ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
|  ^~~~
drivers/scsi/qla2xxx/qla_os.c:7238:2: note: in expansion of macro 'BUILD_BUG_ON'
7238 |  BUILD_BUG_ON(sizeof(cmd_entry_t) != 64);
|  ^~~~
include/linux/compiler.h:350:38: error: call to '__compiletime_assert_7242' 
declared with attribute error: BUILD_BUG_ON failed: sizeof(ms_iocb_entry_t) != 
64
350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
|  ^
include/linux/compiler.h:331:4: note: in definition of macro 
'__compiletime_assert'
331 |prefix ## suffix(); |^~
include/linux/compiler.h:350:2: note: in expansion of macro 
'_compiletime_assert'
350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
|  ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
|  ^~~~
drivers/scsi/qla2xxx/qla_os.c:7242:2: note: in expansion of macro 'BUILD_BUG_ON'
7242 |  BUILD_BUG_ON(sizeof(ms_iocb_entry_t) != 64);
|  ^~~~
include/linux/compiler.h:350:38: error: call to '__compiletime_assert_7243' 
declared with attribute error: BUILD_BUG_ON failed: sizeof(request_t) != 64
350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
|  ^
include/linux/compiler.h:331:4: note: in definition of macro 
'__compiletime_assert'
331 |prefix ## suffix(); |^~
include/linux/compiler.h:350:2: note: in expansion of macro 
'_compiletime_assert'
350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
|  ^~~
include/linux/build_bug.h:39:37: note: in expansion of macro 
'compiletime_assert'
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~
include/linux/build_bug.h:50:2: note: in expansion of macro 'BUILD_BUG_ON_MSG'
50 |  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
|  ^~~~
drivers/scsi/qla2xxx/qla_os.c:7243:2: note: in expansion of macro 'BUILD_BUG_ON'
7243 |  BUILD_BUG_ON(sizeof(request_t) != 64);
|  ^~~~
>> include/linux/compiler.h:350:38: error: call to '__compiletime_assert_7252' 
>> declared with attribute error: BUILD_BUG_ON failed: sizeof(struct 
>> ctio_crc2_to_fw) != 64
350 |  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
|  ^
include/linux/compiler.h:331:4: note: in definition of macro 
'__compiletime_assert'
331 |prefix ## suffix(); |^~
include/linux/compiler.h:350:2

[PATCH 1/1] fpga: dfl: Fix dead store

[trix]

From: Tom Rix 

Using clang's scan-build/view this issue was flagged in fpga-mgr.c

  drivers/fpga/fpga-mgr.c:585:3: warning: Value stored to 'ret' is never read 
[deadcode.DeadStores]
  ret = id;

A similar issue was flagged in fpga-bridge.

So remove the unused stores.

Signed-off-by: Tom Rix 
---
 drivers/fpga/fpga-bridge.c | 6 ++
 drivers/fpga/fpga-mgr.c| 4 +---
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/fpga/fpga-bridge.c b/drivers/fpga/fpga-bridge.c
index 4bab9028940a..2deccacc3aa7 100644
--- a/drivers/fpga/fpga-bridge.c
+++ b/drivers/fpga/fpga-bridge.c
@@ -328,7 +328,7 @@ struct fpga_bridge *fpga_bridge_create(struct device *dev, 
const char *name,
   void *priv)
 {
struct fpga_bridge *bridge;
-   int id, ret = 0;
+   int id, ret;
 
if (!name || !strlen(name)) {
dev_err(dev, "Attempt to register with no name!\n");
@@ -340,10 +340,8 @@ struct fpga_bridge *fpga_bridge_create(struct device *dev, 
const char *name,
return NULL;
 
id = ida_simple_get(&fpga_bridge_ida, 0, 0, GFP_KERNEL);
-   if (id < 0) {
-   ret = id;
+   if (id < 0)
goto error_kfree;
-   }
 
mutex_init(&bridge->mutex);
INIT_LIST_HEAD(&bridge->node);
diff --git a/drivers/fpga/fpga-mgr.c b/drivers/fpga/fpga-mgr.c
index e05104f5e40c..f38bab01432e 100644
--- a/drivers/fpga/fpga-mgr.c
+++ b/drivers/fpga/fpga-mgr.c
@@ -581,10 +581,8 @@ struct fpga_manager *fpga_mgr_create(struct device *dev, 
const char *name,
return NULL;
 
id = ida_simple_get(&fpga_mgr_ida, 0, 0, GFP_KERNEL);
-   if (id < 0) {
-   ret = id;
+   if (id < 0)
goto error_kfree;
-   }
 
mutex_init(&mgr->ref_mutex);
 
-- 
2.26.0

[PATCH 0/1] fpga: dfl: Fix dead store

[trix]

From: Tom Rix 

Repo linux-next
Tag next-20200605

A couple of fixes for dead stores found by clang's sa tool scan-build

Tom Rix (1):
  Fix dead store

 drivers/fpga/fpga-bridge.c | 6 ++
 drivers/fpga/fpga-mgr.c| 4 +---
 2 files changed, 3 insertions(+), 7 deletions(-)

-- 
2.26.0

Re: [Cocci] [PATCH 1/2] Coccinelle: extend memdup_user transformation with GFP_USER

[Julia Lawall]

On Sat, 6 Jun 2020, Denis Efremov wrote:

>
>
> On 6/6/20 11:24 AM, Julia Lawall wrote:
> >
> >
> > On Sat, 30 May 2020, Denis Efremov wrote:
> >
> >> Match GFP_USER allocations with memdup_user.cocci rule.
> >> Commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER") switched
> >> memdup_user() from GFP_KERNEL to GFP_USER. In most cases it is still
> >> a good idea to use memdup_user() for GFP_KERNEL allocations. The
> >> motivation behind altering memdup_user() to GFP_USER is here:
> >> https://lkml.org/lkml/2018/1/6/333
> >
> > Should the rule somehow document the cases in which memdup_user should now
> > not be used?
> >
> > julia
> >
> >
> >>
> >> Signed-off-by: Denis Efremov 
> >> ---
> >>  scripts/coccinelle/api/memdup_user.cocci | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/scripts/coccinelle/api/memdup_user.cocci 
> >> b/scripts/coccinelle/api/memdup_user.cocci
> >> index c809ab10bbce..49f487e6a5c8 100644
> >> --- a/scripts/coccinelle/api/memdup_user.cocci
> >> +++ b/scripts/coccinelle/api/memdup_user.cocci
> >> @@ -20,7 +20,7 @@ expression from,to,size;
> >>  identifier l1,l2;
> >>  @@
> >>
> >> --  to = \(kmalloc\|kzalloc\)(size,GFP_KERNEL);
> >> +-  to = \(kmalloc\|kzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
>
> Actually, we can add optional __GFP_NOWARN here to match such cases as:
> GFP_KERNEL | __GFP_NOWARN
>
> However, I don't know how to express it in elegant way. Something like?
> (
> -  to = \(kmalloc\|kzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
> |
> -  to = \(kmalloc\|kzalloc\)(size, GFP_KERNEL|__GFP_NOWARN);
> |
> -  to = \(kmalloc\|kzalloc\)(size, GFP_USER|__GFP_NOWARN);
> )

I guess you could do:

\(GFP_KERNEL\|GFP_USER\|\(GFP_KERNEL\|GFP_USER\)|__GFP_NOWARN\)

julia

Re: [Cocci] [PATCH 1/2] Coccinelle: extend memdup_user transformation with GFP_USER

[Denis Efremov]

On 6/6/20 11:24 AM, Julia Lawall wrote:
> 
> 
> On Sat, 30 May 2020, Denis Efremov wrote:
> 
>> Match GFP_USER allocations with memdup_user.cocci rule.
>> Commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER") switched
>> memdup_user() from GFP_KERNEL to GFP_USER. In most cases it is still
>> a good idea to use memdup_user() for GFP_KERNEL allocations. The
>> motivation behind altering memdup_user() to GFP_USER is here:
>> https://lkml.org/lkml/2018/1/6/333
> 
> Should the rule somehow document the cases in which memdup_user should now
> not be used?
> 
> julia
> 
> 
>>
>> Signed-off-by: Denis Efremov 
>> ---
>>  scripts/coccinelle/api/memdup_user.cocci | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/scripts/coccinelle/api/memdup_user.cocci 
>> b/scripts/coccinelle/api/memdup_user.cocci
>> index c809ab10bbce..49f487e6a5c8 100644
>> --- a/scripts/coccinelle/api/memdup_user.cocci
>> +++ b/scripts/coccinelle/api/memdup_user.cocci
>> @@ -20,7 +20,7 @@ expression from,to,size;
>>  identifier l1,l2;
>>  @@
>>
>> --  to = \(kmalloc\|kzalloc\)(size,GFP_KERNEL);
>> +-  to = \(kmalloc\|kzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));

Actually, we can add optional __GFP_NOWARN here to match such cases as:
GFP_KERNEL | __GFP_NOWARN

However, I don't know how to express it in elegant way. Something like?
(
-  to = \(kmalloc\|kzalloc\)(size,\(GFP_KERNEL\|GFP_USER\));
|
-  to = \(kmalloc\|kzalloc\)(size, GFP_KERNEL|__GFP_NOWARN);
|
-  to = \(kmalloc\|kzalloc\)(size, GFP_USER|__GFP_NOWARN);
)

Thanks,
Denis

Re: [Cocci] [PATCH 1/2] Coccinelle: extend memdup_user transformation with GFP_USER

[Denis Efremov]

On 6/6/20 11:24 AM, Julia Lawall wrote:
> 
> 
> On Sat, 30 May 2020, Denis Efremov wrote:
> 
>> Match GFP_USER allocations with memdup_user.cocci rule.
>> Commit 6c2c97a24f09 ("memdup_user(): switch to GFP_USER") switched
>> memdup_user() from GFP_KERNEL to GFP_USER. In most cases it is still
>> a good idea to use memdup_user() for GFP_KERNEL allocations. The
>> motivation behind altering memdup_user() to GFP_USER is here:
>> https://lkml.org/lkml/2018/1/6/333
> 
> Should the rule somehow document the cases in which memdup_user should now
> not be used?

As for now, I can't provide a counterexample. GPF_USER is more permissive than
GFP_KERNEL. It's completely ok to use GPF_USER with copy_from_user. Given that
memdup_user() was "silently" switched to GPF_USER from GPF_KERNEL with no 
callside
fixes, I think it's ok to recommend to use memdup_user for GPF_KERNEL matches 
with
no additional restrictions.

Thanks,
Denis

Re: [PATCH RESEND] device_cgroup: Fix RCU list debugging warning

[Stephen Rothwell]

Hi all,

On Mon, 6 Apr 2020 16:29:50 +0530 Amol Grover  wrote:
>
> exceptions may be traversed using list_for_each_entry_rcu()
> outside of an RCU read side critical section BUT under the
> protection of decgroup_mutex. Hence add the corresponding
> lockdep expression to fix the following false-positive
> warning:
> 
> [2.304417] =
> [2.304418] WARNING: suspicious RCU usage
> [2.304420] 5.5.4-stable #17 Tainted: GE
> [2.304422] -
> [2.304424] security/device_cgroup.c:355 RCU-list traversed in non-reader 
> section!!
> 
> Signed-off-by: Amol Grover 
> ---
>  security/device_cgroup.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/security/device_cgroup.c b/security/device_cgroup.c
> index 7d0f8f7431ff..b7da9e0970d9 100644
> --- a/security/device_cgroup.c
> +++ b/security/device_cgroup.c
> @@ -352,7 +352,8 @@ static bool match_exception_partial(struct list_head 
> *exceptions, short type,
>  {
>   struct dev_exception_item *ex;
>  
> - list_for_each_entry_rcu(ex, exceptions, list) {
> + list_for_each_entry_rcu(ex, exceptions, list,
> + lockdep_is_held(&devcgroup_mutex)) {
>   if ((type & DEVCG_DEV_BLOCK) && !(ex->type & DEVCG_DEV_BLOCK))
>   continue;
>   if ((type & DEVCG_DEV_CHAR) && !(ex->type & DEVCG_DEV_CHAR))
> -- 
> 2.24.1
> 

I have been carrying the above patch in linux-next for some time now.
I have been carrying it because it fixes problems for syzbot (see the
third warning in
https://lore.kernel.org/linux-next/cact4y+ynjk+kq0pfb5fe-q1bqe2t1jq_mvkhf--z80z3wky...@mail.gmail.com/).
Is there some reason it has not been applied to some tree?

-- 
Cheers,
Stephen Rothwell


pgpAmuW2UkYbG.pgp
Description: OpenPGP digital signature

drivers/net/ethernet/huawei/hinic/hinic_main.c:796:25: sparse: sparse: cast to restricted __be16

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   b170290c2836c40ab565736ba37681eb3dfd79b8
commit: 1f62cfa19a619f82c098468660b7950477101d45 hinic: add net_device_ops 
associated with vf
date:   6 weeks ago
config: arm64-randconfig-s032-20200607 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-247-gcadbd124-dirty
git checkout 1f62cfa19a619f82c098468660b7950477101d45
# save the attached .config to linux build tree
make W=1 C=1 ARCH=arm64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

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


sparse warnings: (new ones prefixed by >>)

>> drivers/net/ethernet/huawei/hinic/hinic_main.c:796:25: sparse: sparse: cast 
>> to restricted __be16

vim +796 drivers/net/ethernet/huawei/hinic/hinic_main.c

   778  
   779  static void hinic_tx_timeout(struct net_device *netdev, unsigned int 
txqueue)
   780  {
   781  struct hinic_dev *nic_dev = netdev_priv(netdev);
   782  u16 sw_pi, hw_ci, sw_ci;
   783  struct hinic_sq *sq;
   784  u16 num_sqs, q_id;
   785  
   786  num_sqs = hinic_hwdev_num_qps(nic_dev->hwdev);
   787  
   788  netif_err(nic_dev, drv, netdev, "Tx timeout\n");
   789  
   790  for (q_id = 0; q_id < num_sqs; q_id++) {
   791  if (!netif_xmit_stopped(netdev_get_tx_queue(netdev, 
q_id)))
   792  continue;
   793  
   794  sq = hinic_hwdev_get_sq(nic_dev->hwdev, q_id);
   795  sw_pi = atomic_read(&sq->wq->prod_idx) & sq->wq->mask;
 > 796  hw_ci = be16_to_cpu(*(u16 *)(sq->hw_ci_addr)) & 
 > sq->wq->mask;
   797  sw_ci = atomic_read(&sq->wq->cons_idx) & sq->wq->mask;
   798  netif_err(nic_dev, drv, netdev, "Txq%d: sw_pi: %d, 
hw_ci: %d, sw_ci: %d, napi->state: 0x%lx\n",
   799q_id, sw_pi, hw_ci, sw_ci,
   800nic_dev->txqs[q_id].napi.state);
   801  }
   802  }
   803  

---
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 RFC] uaccess: user_access_begin_after_access_ok()

[Michael S. Tsirkin]

On Fri, Jun 05, 2020 at 06:03:38PM +0800, Jason Wang wrote:
> 
> On 2020/6/5 上午12:49, Michael S. Tsirkin wrote:
> > > > 2. Second argument to translate_desc is a GPA, isn't it?
> > > No, it's IOVA, this function will be called only when IOTLB is enabled.
> > > 
> > > Thanks
> > Right IOVA. Point stands how does it make sense to cast
> > a userspace pointer to an IOVA? I guess it's just
> > because it's talking to qemu actually, so it's abusing
> > the notation a bit ...
> > 
> 
> Yes, but the issues are:
> 
> 1) VHOST_SET_VRING_ADDR is used for iotlb and !iotlb
> 2) so did the memory accessors
> 
> Unless we differ separate IOTLB datapath out, there's probably not easy to
> have another notation.
> 
> Thanks

With the batching/format independence rework, it might be possible to
separate that down the road. We'll see.

-- 
MST

Re: [PATCH v4 1/3] virtio: add dma-buf support for exported objects

[Michael S. Tsirkin]

On Fri, Jun 05, 2020 at 10:28:42AM +0900, David Stevens wrote:
> On Fri, Jun 5, 2020 at 4:05 AM Michael S. Tsirkin  wrote:
> >
> > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > > This change adds a new flavor of dma-bufs that can be used by virtio
> > > drivers to share exported objects. A virtio dma-buf can be queried by
> > > virtio drivers to obtain the UUID which identifies the underlying
> > > exported object.
> > >
> > > Signed-off-by: David Stevens 
> >
> > Is this just for graphics? If yes I'd rather we put it in the graphics
> > driver. We can always move it later ...
> 
> As stated in the cover letter, this will be used by virtio-video.
> 
> The proposed virtio-video patches: 
> https://markmail.org/thread/p5d3k566srtdtute
> The patch which imports these dma-bufs (slightly out of data, uses v3
> of this patch set): https://markmail.org/thread/j4xlqaaim266qpks
> 
> > > ---
> > >  drivers/virtio/Makefile |  2 +-
> > >  drivers/virtio/virtio.c |  6 +++
> > >  drivers/virtio/virtio_dma_buf.c | 89 +
> > >  include/linux/virtio.h  |  1 +
> > >  include/linux/virtio_dma_buf.h  | 58 +
> > >  5 files changed, 155 insertions(+), 1 deletion(-)
> > >  create mode 100644 drivers/virtio/virtio_dma_buf.c
> > >  create mode 100644 include/linux/virtio_dma_buf.h
> > >
> > > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > > index 29a1386ecc03..ecdae5b596de 100644
> > > --- a/drivers/virtio/Makefile
> > > +++ b/drivers/virtio/Makefile
> > > @@ -1,5 +1,5 @@
> > >  # SPDX-License-Identifier: GPL-2.0
> > > -obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
> > > +obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o virtio_dma_buf.o
> > >  obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
> > >  obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
> > >  virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
> > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > > index a977e32a88f2..5d46f0ded92d 100644
> > > --- a/drivers/virtio/virtio.c
> > > +++ b/drivers/virtio/virtio.c
> > > @@ -357,6 +357,12 @@ int register_virtio_device(struct virtio_device *dev)
> > >  }
> > >  EXPORT_SYMBOL_GPL(register_virtio_device);
> > >
> > > +bool is_virtio_device(struct device *dev)
> > > +{
> > > + return dev->bus == &virtio_bus;
> > > +}
> > > +EXPORT_SYMBOL_GPL(is_virtio_device);
> > > +
> > >  void unregister_virtio_device(struct virtio_device *dev)
> > >  {
> > >   int index = dev->index; /* save for after device release */
> > > diff --git a/drivers/virtio/virtio_dma_buf.c 
> > > b/drivers/virtio/virtio_dma_buf.c
> > > new file mode 100644
> > > index ..23e3399b11ed
> > > --- /dev/null
> > > +++ b/drivers/virtio/virtio_dma_buf.c
> > > @@ -0,0 +1,89 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > +/*
> > > + * dma-bufs for virtio exported objects
> > > + *
> > > + * Copyright (C) 2020 Google, Inc.
> > > + */
> > > +
> > > +#include 
> > > +
> > > +/**
> > > + * virtio_dma_buf_export - Creates a new dma-buf for a virtio exported 
> > > object
> > > + *
> > > + * This wraps dma_buf_export() to allow virtio drivers to create a 
> > > dma-buf
> > > + * for an virtio exported object that can be queried by other virtio 
> > > drivers
> > > + * for the object's UUID.
> > > + */
> > > +struct dma_buf *virtio_dma_buf_export(
> > > + const struct virtio_dma_buf_export_info *virtio_exp_info)
> > > +{
> > > + struct dma_buf_export_info exp_info;
> > > +
> > > + if (!virtio_exp_info->ops
> > > + || virtio_exp_info->ops->ops.attach != 
> > > &virtio_dma_buf_attach
> > > + || !virtio_exp_info->ops->get_uuid) {
> > > + return ERR_PTR(-EINVAL);
> > > + }
> > > +
> > > + exp_info.exp_name = virtio_exp_info->exp_name;
> > > + exp_info.owner = virtio_exp_info->owner;
> > > + exp_info.ops = &virtio_exp_info->ops->ops;
> > > + exp_info.size = virtio_exp_info->size;
> > > + exp_info.flags = virtio_exp_info->flags;
> > > + exp_info.resv = virtio_exp_info->resv;
> > > + exp_info.priv = virtio_exp_info->priv;
> > > + BUILD_BUG_ON(sizeof(struct virtio_dma_buf_export_info)
> > > +  != sizeof(struct dma_buf_export_info));
> >
> > This is the only part that gives me pause. Why do we need this hack?
> > What's wrong with just using dma_buf_export_info directly,
> > and if you want the virtio ops, just using container_off?
> 
> This approach provides a more explicit type signature and a little
> more type safety, I think. If others don't think it's a worthwhile
> tradeoff, I can remove it.
> 
> -David

The cost is that if dma_buf_export_info changes even slightly, we get
weird crashes.

-- 
MST

Re: [Possible PATCH] iommu/qcom: Change CONFIG_BIG_ENDIAN to CONFIG_CPU_BIG_ENDIAN

[Rob Clark]

On Sat, Jun 6, 2020 at 12:16 PM Joe Perches  wrote:
>
> CONFIG_BIG_ENDIAN does not exist as a Kconfig symbol.
>
> Signed-off-by: Joe Perches 
> ---
>
> I don't have the hardware, so I can't tell if this is a
> correct change, but it is a logical one.

I'm not sure *anyone* has a working snapdragon big-endian setup these
days.. sboyd used to tinker with that ages ago.

But, SCTLR.E is the bit to set for big-endian, so this looks like the
right thing to do.

Reviewed-by: Rob Clark 

> Found by a test script that looks for IS_ENABLED(FOO)
> where FOO must also exist in Kconfig files.
>
>  drivers/iommu/qcom_iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
> index c3e1fbd1988c..69e113471ecb 100644
> --- a/drivers/iommu/qcom_iommu.c
> +++ b/drivers/iommu/qcom_iommu.c
> @@ -304,7 +304,7 @@ static int qcom_iommu_init_domain(struct iommu_domain 
> *domain,
>   ARM_SMMU_SCTLR_M | ARM_SMMU_SCTLR_S1_ASIDPNE |
>   ARM_SMMU_SCTLR_CFCFG;
>
> -   if (IS_ENABLED(CONFIG_BIG_ENDIAN))
> +   if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
> reg |= ARM_SMMU_SCTLR_E;
>
> iommu_writel(ctx, ARM_SMMU_CB_SCTLR, reg);
>

[PATCH] i40e: silence an UBSAN false positive

[Qian Cai]

virtchnl_rss_lut.lut is used for the RSS lookup table, but in
i40e_vc_config_rss_lut(), it is indexed by subscript results in a false
positive.

 UBSAN: array-index-out-of-bounds in 
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:2983:15
 index 1 is out of range for type 'u8 [1]'
 CPU: 34 PID: 871 Comm: kworker/34:2 Not tainted 5.7.0-next-20200605+ #5
 Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 
03/09/2018
 Workqueue: i40e i40e_service_task [i40e]
 Call Trace:
  dump_stack+0xa7/0xea
  ubsan_epilogue+0x9/0x45
  __ubsan_handle_out_of_bounds+0x6f/0x80
  i40e_vc_process_vf_msg+0x457c/0x4660 [i40e]
  i40e_service_task+0x96c/0x1ab0 [i40e]
  process_one_work+0x57d/0xbd0
  worker_thread+0x63/0x5b0
  kthread+0x20c/0x230
  ret_from_fork+0x22/0x30

Fixes: d510497b8397 ("i40e: add input validation for virtchnl handlers")
Signed-off-by: Qian Cai 
---
 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c 
b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 56b9e445732b..d5a959d91ba9 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -2971,6 +2971,7 @@ static int i40e_vc_config_rss_lut(struct i40e_vf *vf, u8 
*msg)
struct i40e_vsi *vsi = NULL;
i40e_status aq_ret = 0;
u16 i;
+   u8 *lut = vrl->lut;
 
if (!test_bit(I40E_VF_STATE_ACTIVE, &vf->vf_states) ||
!i40e_vc_isvalid_vsi_id(vf, vrl->vsi_id) ||
@@ -2980,13 +2981,13 @@ static int i40e_vc_config_rss_lut(struct i40e_vf *vf, 
u8 *msg)
}
 
for (i = 0; i < vrl->lut_entries; i++)
-   if (vrl->lut[i] >= vf->num_queue_pairs) {
+   if (lut[i] >= vf->num_queue_pairs) {
aq_ret = I40E_ERR_PARAM;
goto err;
}
 
vsi = pf->vsi[vf->lan_vsi_idx];
-   aq_ret = i40e_config_rss(vsi, NULL, vrl->lut, I40E_VF_HLUT_ARRAY_SIZE);
+   aq_ret = i40e_config_rss(vsi, NULL, lut, I40E_VF_HLUT_ARRAY_SIZE);
/* send the response to the VF */
 err:
return i40e_vc_send_resp_to_vf(vf, VIRTCHNL_OP_CONFIG_RSS_LUT,
-- 
2.21.0 (Apple Git-122.2)

Re: [PATCH v26 03/15] leds: multicolor: Introduce a multicolor class definition

[Jacek Anaszewski]

Dan,

On 6/6/20 6:39 PM, Dan Murphy wrote:

Pavek

Thanks for the review

On 6/6/20 10:53 AM, Pavel Machek wrote:

Hi!


Introduce a multicolor class that groups colored LEDs
within a LED node.

The multi color class groups monochrome LEDs and allows controlling two
aspects of the final combined color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness file.

Acked-by: Jacek Anaszewski 
Signed-off-by: Dan Murphy 
diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor 
b/Documentation/ABI/testing/sysfs-class-led-multicolor

new file mode 100644

[...]

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9533,6 +9533,14 @@ F:    Documentation/devicetree/bindings/leds/
  F:    drivers/leds/
  F:    include/linux/leds.h
+LED MULTICOLOR FRAMEWORK
+M:    Dan Murphy 
+L:    linux-l...@vger.kernel.org

I'd like to be mentioned here, too. "M: Pavel Machek
". And I'm not sure if I should be taking MAINTAINER
file update through a LED tree. Should definitely go to separate
patch.


Oh definitely.  I thought it was implied that you and Jacek are both 
Maintainers as well.


I will add you but will wait to see if Jacek wants to be added.


Actually I don't think that we need to add this separate entry
for LED multicolor class. This is still under LED subsystem,
and I didn't add anything for LED class flash.


I will separate this out and make it a separate patch


--
Best regards,
Jacek Anaszewski

[ANNOUNCE] 4.9.226-rt145

[Clark Williams]

Hello RT-list!

I'm pleased to announce the 4.9.226-rt145 stable release.

Note that since 4.9-rt is in maintenance mode, this is just the result
of merging in the latest linux-stable releases; no changes were made to
the PREEMPT_RT patches for the 4.9 tree.

You can get this release via the git tree at:

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

  branch: v4.9-rt
  Head SHA1: c301c11d2fbcfbc83b536b0209d5ee24b8fe4d13

Or to build 4.9.226-rt145 directly, the following patches should be applied:

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

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

  
https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.226-rt145.patch.xz


You can also build from 4.9.224-rt144 by applying the incremental patch:

  
https://www.kernel.org/pub/linux/kernel/projects/rt/4.9/incr/patch-4.9.224-rt144-rt145.patch.xz

Enjoy!
Clark

[Possible PATCH]arm64: ftrace: Change CONFIG_FTRACE_WITH_REGS to CONFIG_DYNAMIC_FTRACE_WITH_REGS

[Joe Perches]

CONFIG_FTRACE_WITH_REGS does not exist as a Kconfig symbol.

Signed-off-by: Joe Perches 
---

I don't have the hardware, so I can't tell if this is a
correct change, but it is a logical one.

Found by a test script that looks for IS_ENABLED(FOO)
where FOO must also exist in Kconfig files.

 arch/arm64/kernel/ftrace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index 8618faa82e6d..86a5cf9bc19a 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -69,7 +69,8 @@ static struct plt_entry *get_ftrace_plt(struct module *mod, 
unsigned long addr)
 
if (addr == FTRACE_ADDR)
return &plt[FTRACE_PLT_IDX];
-   if (addr == FTRACE_REGS_ADDR && IS_ENABLED(CONFIG_FTRACE_WITH_REGS))
+   if (addr == FTRACE_REGS_ADDR &&
+   IS_ENABLED(CONFIG_DYNAMIC_FTRACE_WITH_REGS))
return &plt[FTRACE_REGS_PLT_IDX];
 #endif
return NULL;

[Possible PATCH] iommu/qcom: Change CONFIG_BIG_ENDIAN to CONFIG_CPU_BIG_ENDIAN

[Joe Perches]

CONFIG_BIG_ENDIAN does not exist as a Kconfig symbol.

Signed-off-by: Joe Perches 
---

I don't have the hardware, so I can't tell if this is a
correct change, but it is a logical one.

Found by a test script that looks for IS_ENABLED(FOO)
where FOO must also exist in Kconfig files.

 drivers/iommu/qcom_iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
index c3e1fbd1988c..69e113471ecb 100644
--- a/drivers/iommu/qcom_iommu.c
+++ b/drivers/iommu/qcom_iommu.c
@@ -304,7 +304,7 @@ static int qcom_iommu_init_domain(struct iommu_domain 
*domain,
  ARM_SMMU_SCTLR_M | ARM_SMMU_SCTLR_S1_ASIDPNE |
  ARM_SMMU_SCTLR_CFCFG;
 
-   if (IS_ENABLED(CONFIG_BIG_ENDIAN))
+   if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
reg |= ARM_SMMU_SCTLR_E;
 
iommu_writel(ctx, ARM_SMMU_CB_SCTLR, reg);

Re: [GIT PULL] PCI changes for v5.8

[pr-tracker-bot]

The pull request you sent on Fri, 5 Jun 2020 15:22:57 -0500:

> git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git 
> tags/pci-v5.8-changes

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3925c3bbdf886f1ddf64461b9b380e1bb36f90c1

Thank you!

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

Re: [GIT PULL] dmi update for v5.8

[pr-tracker-bot]

The pull request you sent on Sat, 6 Jun 2020 17:13:20 +0200:

> git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging.git 
> dmi-for-linus

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

Thank you!

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

Re: [GIT PULL 1/2] Kbuild updates for v5.8-rc1

[pr-tracker-bot]

The pull request you sent on Sun, 7 Jun 2020 00:18:22 +0900:

> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git 
> tags/kbuild-v5.8

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

Thank you!

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

Re: [GIT PULL 2/2] Kconfig updates for v5.8-rc1

[pr-tracker-bot]

The pull request you sent on Sun, 7 Jun 2020 00:21:54 +0900:

> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git 
> tags/kconfig-v5.8

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

Thank you!

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

Re: [GIT PULL] dma-mapping updates for 5.8, part 2

[pr-tracker-bot]

The pull request you sent on Sat, 6 Jun 2020 18:09:32 +0200:

> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.8-2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6f2dc3d335457d9c815be9f4fd3dc8eff92fcef7

Thank you!

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

Re: [GIT PULL] dma-mapping updates for 5.8, part 1

[pr-tracker-bot]

The pull request you sent on Sat, 6 Jun 2020 18:06:57 +0200:

> git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.8

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1ee18de92927f37e6948d5a6fc73cbf89f806905

Thank you!

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

[PATCH] Fix build failure of OCFS2 when TCP/IP is disabled

[Tom Seewald]

After commit 12abc5ee7873 ("tcp: add tcp_sock_set_nodelay") and
commit c488aeadcbd0 ("tcp: add tcp_sock_set_user_timeout"), building the
kernel with OCFS2_FS=y but without INET=y causes it to fail with:

ld: fs/ocfs2/cluster/tcp.o: in function `o2net_accept_many':
tcp.c:(.text+0x21b1): undefined reference to `tcp_sock_set_nodelay'
ld: tcp.c:(.text+0x21c1): undefined reference to `tcp_sock_set_user_timeout
'
ld: fs/ocfs2/cluster/tcp.o: in function `o2net_start_connect':
tcp.c:(.text+0x2633): undefined reference to `tcp_sock_set_nodelay'
ld: tcp.c:(.text+0x2643): undefined reference to `tcp_sock_set_user_timeout
'

This is due to tcp_sock_set_nodelay() and tcp_sock_set_user_timeout() being
declared in linux/tcp.h and defined in net/ipv4/tcp.c, which depend on
TCP/IP being enabled.

To fix this, make OCFS2_FS depend on INET=y which already requires NET=y.

Signed-off-by: Tom Seewald 
---
 fs/ocfs2/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ocfs2/Kconfig b/fs/ocfs2/Kconfig
index 1177c33df895..aca16624b370 100644
--- a/fs/ocfs2/Kconfig
+++ b/fs/ocfs2/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config OCFS2_FS
tristate "OCFS2 file system support"
-   depends on NET && SYSFS && CONFIGFS_FS
+   depends on INET && SYSFS && CONFIGFS_FS
select JBD2
select CRC32
select QUOTA
-- 
2.20.1

Re: [PATCH] sr: dwc2/gadget: remove unneccessary if

[Pavel Machek]

Hi!

> > We don't really need if/else to set variable to 1/0.
> > 
> > Signed-off-by: Pavel Machek (CIP) 
> > 
> > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> > index 12b98b466287..f9f6fd470c81 100644
> > --- a/drivers/usb/dwc2/gadget.c
> > +++ b/drivers/usb/dwc2/gadget.c
> > @@ -1761,10 +1761,7 @@ static int dwc2_hsotg_process_req_feature(struct 
> > dwc2_hsotg *hsotg,
> > case USB_RECIP_DEVICE:
> > switch (wValue) {
> > case USB_DEVICE_REMOTE_WAKEUP:
> > -   if (set)
> > -   hsotg->remote_wakeup_allowed = 1;
> > -   else
> > -   hsotg->remote_wakeup_allowed = 0;
> > +   hsotg->remote_wakeup_allowed = set;
> > break;
> >   
> > case USB_DEVICE_TEST_MODE:
> > 
> 
> It's good catch, but 'set' declared as 'bool' while 
> 'remote_wakeup_allowed' is 'unsigned int'. Maybe update 'set' type to same.

I know set is bool. But that should not matter, code is okay and
compiler will do the right thing:

pavel@amd:/tmp$ cat delme.c
#include 

void main(void)
{
  bool a = false;
int b = a;
 }
 pavel@amd:/tmp$ gcc -std=c99 -Wall delme.c
delme.c:3:6: warning: return type of ‘main’ is not ‘int’ [-Wmain]
 void main(void)
   ^
   delme.c: In function ‘main’:
 delme.c:6:7: warning: unused variable ‘b’
 [-Wunused-variable]
  int b = a;
 ^

Best regards,
Pavel
-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany


signature.asc
Description: Digital signature

drivers/block/umem.c:287:16: sparse: expected unsigned int value

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9fa88c5d3f5eae3e68ef20d226c3f13e21490668
commit: 05933aac7b11911955de307a329dc2a7a14b7bd0 ia64: remove now unused 
machvec indirections
date:   10 months ago
config: ia64-randconfig-s031-20200607 (attached as .config)
compiler: ia64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-247-gcadbd124-dirty
git checkout 05933aac7b11911955de307a329dc2a7a14b7bd0
# save the attached .config to linux build tree
make W=1 C=1 ARCH=ia64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

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


sparse warnings: (new ones prefixed by >>)

   ./arch/ia64/include/generated/uapi/asm/unistd_64.h:348:39: sparse: sparse: 
no newline at end of file
   drivers/block/umem.c:267:32: sparse: sparse: incorrect type in assignment 
(different base types) @@ expected restricted __le64 [usertype] 
sem_control_bits @@ got restricted __le32 [usertype] control_bits @@
   drivers/block/umem.c:267:32: sparse: expected restricted __le64 
[usertype] sem_control_bits
   drivers/block/umem.c:267:32: sparse: got restricted __le32 [usertype] 
control_bits
   drivers/block/umem.c:287:16: sparse: sparse: incorrect type in argument 1 
(different base types) @@ expected unsigned int [usertype] value @@ got 
restricted __le32 [usertype] @@
>> drivers/block/umem.c:287:16: sparse: expected unsigned int [usertype] 
>> value
   drivers/block/umem.c:287:16: sparse: got restricted __le32 [usertype]
   drivers/block/umem.c:291:16: sparse: sparse: incorrect type in argument 1 
(different base types) @@ expected unsigned int [usertype] value @@ got 
restricted __le32 [usertype] @@
   drivers/block/umem.c:291:16: sparse: expected unsigned int [usertype] 
value
   drivers/block/umem.c:291:16: sparse: got restricted __le32 [usertype]
   drivers/block/umem.c:295:16: sparse: sparse: incorrect type in argument 1 
(different base types) @@ expected unsigned int [usertype] value @@ got 
restricted __le32 [usertype] @@
   drivers/block/umem.c:295:16: sparse: expected unsigned int [usertype] 
value
   drivers/block/umem.c:295:16: sparse: got restricted __le32 [usertype]
   drivers/block/umem.c:398:32: sparse: sparse: incorrect type in assignment 
(different base types) @@ expected restricted __le64 [usertype] 
sem_control_bits @@ got restricted __le32 [usertype] control_bits @@
   drivers/block/umem.c:398:32: sparse: expected restricted __le64 
[usertype] sem_control_bits
   drivers/block/umem.c:398:32: sparse: got restricted __le32 [usertype] 
control_bits
   drivers/block/umem.c:429:31: sparse: sparse: cast to restricted __le32
   drivers/block/umem.c:429:31: sparse: sparse: cast from restricted __le64
   drivers/block/umem.c:457:33: sparse: sparse: cast to restricted __le32
   drivers/block/umem.c:457:33: sparse: sparse: cast from restricted __le64
   drivers/block/umem.c:461:28: sparse: sparse: cast to restricted __le32
   drivers/block/umem.c:461:28: sparse: sparse: cast from restricted __le64
   drivers/block/umem.c:550:22: sparse: sparse: cast to restricted __le32
   drivers/block/umem.c:559:24: sparse: sparse: incorrect type in argument 1 
(different base types) @@ expected unsigned int [usertype] value @@ got 
restricted __le32 [usertype] @@
   drivers/block/umem.c:559:24: sparse: expected unsigned int [usertype] 
value
   drivers/block/umem.c:559:24: sparse: got restricted __le32 [usertype]
   drivers/block/umem.c:573:29: sparse: sparse: cast to restricted __le32
   drivers/block/umem.c:575:29: sparse: sparse: cast to restricted __le32
   drivers/block/umem.c:577:29: sparse: sparse: cast to restricted __le32
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:225:22: sparse: sparse: incorrect type in argument 
1 (different base types) @@ expected unsigned int [usertype] value @@ 
got restricted __le32 [usertype] @@
   include/asm-generic/io.h:225:22: sparse: expected unsigned int 
[usertype] value
   include/asm-generic/io.h:225:22: sparse: got restricted __le32 [usertype]
   include/asm-generic/io.h:225:22: sparse: sp

[rcu:dev.2020.06.02a 67/90] include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'long unsigned int'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
dev.2020.06.02a
head:   5216948905dd07a84cef8a7dc72c2ec076802efd
commit: 7d16add62717136b1839f0b3d7ea4cbb98f38c2a [67/90] rcuperf: Fix 
kfree_mult to match printk() format
config: parisc-randconfig-r022-20200607 (attached as .config)
compiler: hppa-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 7d16add62717136b1839f0b3d7ea4cbb98f38c2a
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=parisc 

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

All warnings (new ones prefixed by >>, old ones prefixed by <<):

In file included from include/linux/mm.h:95,
from kernel/rcu/rcuperf.c:15:
include/asm-generic/pgtable.h: In function 'pte_clear_not_present_full':
arch/parisc/include/asm/pgtable.h:96:9: warning: variable 'old_pte' set but not 
used [-Wunused-but-set-variable]
96 |   pte_t old_pte;  | ^~~
arch/parisc/include/asm/pgtable.h:322:34: note: in expansion of macro 
'set_pte_at'
322 | #define pte_clear(mm, addr, xp)  set_pte_at(mm, addr, xp, __pte(0))
|  ^~
include/asm-generic/pgtable.h:202:2: note: in expansion of macro 'pte_clear'
202 |  pte_clear(mm, address, ptep);
|  ^
include/asm-generic/pgtable.h: In function '__ptep_modify_prot_commit':
arch/parisc/include/asm/pgtable.h:96:9: warning: variable 'old_pte' set but not 
used [-Wunused-but-set-variable]
96 |   pte_t old_pte;  | ^~~
include/asm-generic/pgtable.h:641:2: note: in expansion of macro 'set_pte_at'
641 |  set_pte_at(vma->vm_mm, addr, ptep, pte);
|  ^~
In file included from include/linux/printk.h:7,
from include/linux/kernel.h:15,
from kernel/rcu/rcuperf.c:13:
kernel/rcu/rcuperf.c: In function 'kfree_perf_init':
>> include/linux/kern_levels.h:5:18: warning: format '%zu' expects argument of 
>> type 'size_t', but argument 2 has type 'long unsigned int' [-Wformat=]
5 | #define KERN_SOH "001"  /* ASCII Start Of Header */
|  ^~
include/linux/kern_levels.h:9:20: note: in expansion of macro 'KERN_SOH'
9 | #define KERN_ALERT KERN_SOH "1" /* action must be taken immediately */
|^~~~
include/linux/printk.h:295:9: note: in expansion of macro 'KERN_ALERT'
295 |  printk(KERN_ALERT pr_fmt(fmt), ##__VA_ARGS__)
| ^~
kernel/rcu/rcuperf.c:727:2: note: in expansion of macro 'pr_alert'
727 |  pr_alert("kfree object size=%zun", kfree_mult * sizeof(struct 
kfree_obj));
|  ^~~~
kernel/rcu/rcuperf.c:727:32: note: format string is defined here
727 |  pr_alert("kfree object size=%zun", kfree_mult * sizeof(struct 
kfree_obj));
|  ~~^
||
|unsigned int
|  %lu

vim +5 include/linux/kern_levels.h

314ba3520e513a Joe Perches 2012-07-30  4  
04d2c8c83d0e3a Joe Perches 2012-07-30 @5  #define KERN_SOH  "\001"  
/* ASCII Start Of Header */
04d2c8c83d0e3a Joe Perches 2012-07-30  6  #define KERN_SOH_ASCII'\001'
04d2c8c83d0e3a Joe Perches 2012-07-30  7  

:: The code at line 5 was first introduced by commit
:: 04d2c8c83d0e3ac5f78aeede51babb3236200112 printk: convert the format for 
KERN_ to a 2 byte pattern

:: TO: Joe Perches 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:543:54: sparse: sparse: incorrect type in argument 2 (different address spaces)

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9fa88c5d3f5eae3e68ef20d226c3f13e21490668
commit: a425b6e1c69ba907b72b737a4d44f8cfbc43ce3c hinic: add mailbox function 
support
date:   6 weeks ago
config: arm64-randconfig-s032-20200607 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-247-gcadbd124-dirty
git checkout a425b6e1c69ba907b72b737a4d44f8cfbc43ce3c
# save the attached .config to linux build tree
make W=1 C=1 ARCH=arm64 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'

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


sparse warnings: (new ones prefixed by >>)

>> drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:543:54: sparse: sparse: 
>> incorrect type in argument 2 (different address spaces) @@ expected void 
>> volatile [noderef]  *addr @@ got unsigned char [usertype] * @@
>> drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:543:54: sparse: 
>> expected void volatile [noderef]  *addr
>> drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:543:54: sparse: got 
>> unsigned char [usertype] *
   drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:566:58: sparse: sparse: 
incorrect type in argument 2 (different address spaces) @@ expected void 
volatile [noderef]  *addr @@ got unsigned char [usertype] * @@
   drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:566:58: sparse: 
expected void volatile [noderef]  *addr
   drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:566:58: sparse: got 
unsigned char [usertype] *
   drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:601:6: sparse: sparse: 
symbol 'dump_mox_reg' was not declared. Should it be static?
>> drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:618:22: sparse: sparse: 
>> cast to restricted __be64
>> drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:1057:25: sparse: sparse: 
>> incorrect type in assignment (different address spaces) @@ expected 
>> unsigned char [usertype] *data @@ got void [noderef]  * @@
>> drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:1057:25: sparse: 
>> expected unsigned char [usertype] *data
>> drivers/net/ethernet/huawei/hinic/hinic_hw_mbox.c:1057:25: sparse: got 
>> void [noderef]  *
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: 
incorrect type in argument 1 (different base types) @@ expected unsigned 
int [usertype] val @@ got restricted __be32 [usertype] @@
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: expected 
unsigned int [usertype] val
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: got 
restricted __be32 [usertype]
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: 
incorrect type in argument 1 (different base types) @@ expected unsigned 
int [usertype] val @@ got restricted __be32 [usertype] @@
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: expected 
unsigned int [usertype] val
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: got 
restricted __be32 [usertype]
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:250:16: sparse: sparse: cast 
to restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:250:16: sparse: sparse: cast 
to restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: cast 
from restricted __be32
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: sparse: 
incorrect type in argument 1 (different base types) @@ expected unsigned 
int [usertype] val @@ got restricted __be32 [usertype] @@
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: expected 
unsigned int [usertype] val
   drivers/net/ethernet/huawei/hinic/hinic_hw_if.h:256:9: sparse: got 
restricted __be32 [usertype]
   drivers/net/ethernet/huawei

Re: [PATCH v3 1/2] usb: serial: Add MaxLinear/Exar USB to Serial driver

[Manivannan Sadhasivam]

Hi Johan,

Thanks for the review. Please find the replies inline.

On Tue, May 19, 2020 at 02:33:38PM +0200, Johan Hovold wrote:
> On Fri, May 01, 2020 at 12:19:23AM +0530, m...@kernel.org wrote:
> > From: Manivannan Sadhasivam 
> > 
> > Add support for MaxLinear/Exar USB to Serial converters. This driver
> > only supports XR21V141X series but it can be extended to other series
> > from Exar as well in future.
> > 
> > This driver is inspired from the initial one submitted by Patong Yang:
> > 
> > https://patchwork.kernel.org/patch/10543261/
> > 
> > While the initial driver was a custom tty USB driver exposing whole
> > new serial interface ttyXRUSBn, this version is completely based on USB
> > serial core thus exposing the interfaces as ttyUSBn. This will avoid
> > the overhead of exposing a new USB serial interface which the userspace
> > tools are unaware of.
> > 
> > Signed-off-by: Manivannan Sadhasivam 
> > ---
> >  drivers/usb/serial/Kconfig |   9 +
> >  drivers/usb/serial/Makefile|   1 +
> >  drivers/usb/serial/xr_serial.c | 624 +
> >  3 files changed, 634 insertions(+)
> >  create mode 100644 drivers/usb/serial/xr_serial.c
> > 
> > diff --git a/drivers/usb/serial/Kconfig b/drivers/usb/serial/Kconfig
> > index 25d7e0c36d38..8f6ad9f94735 100644
> > --- a/drivers/usb/serial/Kconfig
> > +++ b/drivers/usb/serial/Kconfig
> > @@ -644,6 +644,15 @@ config USB_SERIAL_UPD78F0730
> >   To compile this driver as a module, choose M here: the
> >   module will be called upd78f0730.
> >  
> > +config USB_SERIAL_XR
> > +   tristate "USB MaxLinear/Exar USB to Serial driver"
> > +   help
> > + Say Y here if you want to use MaxLinear/Exar USB to Serial converter
> > + devices.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called xr_serial.
> > +
> >  config USB_SERIAL_DEBUG
> > tristate "USB Debugging Device"
> > help
> > diff --git a/drivers/usb/serial/Makefile b/drivers/usb/serial/Makefile
> > index 2d491e434f11..4f69c2a3aff3 100644
> > --- a/drivers/usb/serial/Makefile
> > +++ b/drivers/usb/serial/Makefile
> > @@ -62,4 +62,5 @@ obj-$(CONFIG_USB_SERIAL_VISOR)+= 
> > visor.o
> >  obj-$(CONFIG_USB_SERIAL_WISHBONE)  += wishbone-serial.o
> >  obj-$(CONFIG_USB_SERIAL_WHITEHEAT) += whiteheat.o
> >  obj-$(CONFIG_USB_SERIAL_XIRCOM)+= keyspan_pda.o
> > +obj-$(CONFIG_USB_SERIAL_XR)+= xr_serial.o
> >  obj-$(CONFIG_USB_SERIAL_XSENS_MT)  += xsens_mt.o
> > diff --git a/drivers/usb/serial/xr_serial.c b/drivers/usb/serial/xr_serial.c
> > new file mode 100644
> > index ..fdb9ddf8bd95
> > --- /dev/null
> > +++ b/drivers/usb/serial/xr_serial.c
> > @@ -0,0 +1,624 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * MaxLinear/Exar USB to Serial driver
> > + *
> > + * Based on initial driver written by Patong Yang 
> > + *
> > + * Copyright (c) 2020 Manivannan Sadhasivam 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct xr_uart_regs {
> > +   u8 enable;
> > +   u8 format;
> > +   u8 flow_ctrl;
> > +   u8 xon_char;
> > +   u8 xoff_char;
> > +   u8 loopback;
> > +   u8 tx_break;
> > +   u8 rs485_delay;
> > +   u8 gpio_mode;
> > +   u8 gpio_dir;
> > +   u8 gpio_int_mask;
> > +   u8 gpio_set;
> > +   u8 gpio_clr;
> > +   u8 gpio_status;
> > +};
> > +
> > +struct xr_port_private {
> > +   const struct xr_uart_regs *regs;
> > +};
> > +
> > +struct xr_txrx_clk_mask {
> > +   u16 tx;
> > +   u16 rx0;
> > +   u16 rx1;
> > +};
> > +
> > +#define XR21V141X_ID   0x1410
> > +#define XR_INT_OSC_HZ  4800
> > +
> > +/* USB Requests */
> > +#define XR_SET_XR21V141X   0
> > +#define XR_GET_XR21V141X   1
> > +
> > +#define XR21V141X_CLOCK_DIVISOR_0  0x4
> > +#define XR21V141X_CLOCK_DIVISOR_1  0x5
> > +#define XR21V141X_CLOCK_DIVISOR_2  0x6
> > +#define XR21V141X_TX_CLOCK_MASK_0  0x7
> > +#define XR21V141X_TX_CLOCK_MASK_1  0x8
> > +#define XR21V141X_RX_CLOCK_MASK_0  0x9
> > +#define XR21V141X_RX_CLOCK_MASK_1  0xa
> > +
> > +/* XR21V141X register blocks */
> > +#define XR21V141X_UART_REG_BLOCK   0
> > +#define XR21V141X_URM_REG_BLOCK4
> > +#define XR21V141X_UART_CUSTOM_BLOCK0x66
> > +
> > +/* XR21V141X UART Manager Registers */
> > +#define XR21V141X_URM_FIFO_ENABLE_REG  0x10
> > +#define XR21V141X_URM_ENABLE_TX_FIFO   0x1
> > +#define XR21V141X_URM_ENABLE_RX_FIFO   0x2
> > +
> > +#define XR21V141X_URM_RX_FIFO_RESET0x18
> > +#define XR21V141X_URM_TX_FIFO_RESET0x1c
> 
> Did you mean to use "UMR" above? What does URM stand for otherwise?
> 

UART Manager. I'll just use 'UART_MANAGER' to make it more explicit.

> > +
> > +#define UART_ENABLE_TX 0x1
> > +#define UART_ENABLE_RX 0x2
> > +
> > +#define UART_MODE_RI  

RE: [RFC PATCH 5/5] scsi: ufs: Prepare HPB read for cached sub-region

[Avri Altman]

> +static bool ufshpb_test_ppn_dirty(struct ufshpb_lu *hpb, int rgn_idx,
> +  int srgn_idx, int srgn_offset, int cnt)


> +
> +   for (i = 0; i < bit_len; i++) {
> +   if (test_bit(srgn_offset + i, srgn->mctx->ppn_dirty))
Maybe use a mask or hweight instead of testing bit by bit?

> +static void
> +ufshpb_set_hpb_read_to_upiu(struct ufshpb_lu *hpb, struct ufshcd_lrb
> *lrbp,
> + u32 lpn, u64 ppn,  unsigned int 
> transfer_len)
> +{
> +   unsigned char *cdb = lrbp->ucd_req_ptr->sc.cdb;
> +
> +   cdb[0] = UFSHPB_READ;
> +
> +   put_unaligned_be32(lpn, &cdb[2]);
Is this needed? The lba is already occupying bytes 2..5

> +   put_unaligned_be64(ppn, &cdb[6]);
> +   cdb[14] = transfer_len;
> +}
> +

Thanks,
Avri

RE: [RFC PATCH 4/5] scsi: ufs: L2P map management for HPB read

[Avri Altman]

> 
> A pinned region is a pre-set regions on the UFS device that is always
> activate-state and
This sentence got cut off

> 
> The data structure for map data request and L2P map uses mempool API,
> minimizing allocation overhead while avoiding static allocation.

Maybe one or two more sentences to explain the L2P framework:
Each hpb lun maintains 2 "to-do" lists: 
 - hpb->lh_inact_rgn - regions to be inactivated, and 
 - hpb->lh_act_srgn - subregions to be activated
Those lists are being checked on every resume and completion interrupt.

> 
> Signed-off-by: Daejun Park 
> ---
> +   for (i = 0; i < hpb->pages_per_srgn; i++) {
> +   mctx->m_page[i] = mempool_alloc(ufshpb_drv.ufshpb_page_pool,
> +   GFP_KERNEL);
> +   memset(page_address(mctx->m_page[i]), 0, PAGE_SIZE);
Better move this memset after if (!mctx->m_page[i]).
And maybe use clear_page instead?

> +   if (!mctx->m_page[i]) {
> +   for (j = 0; j < i; j++)
> +   mempool_free(mctx->m_page[j],
> +ufshpb_drv.ufshpb_page_pool);
> +   goto release_ppn_dirty;
> +   }


> +static inline int ufshpb_add_region(struct ufshpb_lu *hpb,
> +   struct ufshpb_region *rgn)
> +{
Maybe better describe what this function does - ufshpb_get_rgn_map_ctx ?

> +
> +static int ufshpb_evict_region(struct ufshpb_lu *hpb, struct ufshpb_region
> *rgn)
> +{
> +   unsigned long flags;
> +   int ret = 0;
> +
> +   spin_lock_irqsave(&hpb->hpb_state_lock, flags);
> +   if (rgn->rgn_state == HPB_RGN_PINNED) {
> +   dev_warn(&hpb->hpb_lu_dev,
> +"pinned region cannot drop-out. region %d\n",
> +rgn->rgn_idx);
> +   goto out;
> +   }
> +
> +   if (!list_empty(&rgn->list_lru_rgn)) {
> +   if (ufshpb_check_issue_state_srgns(hpb, rgn)) {
So if one of its subregions has inflight map request - you add it to the 
"starved" list?
Why call it starved?


> +static int ufshpb_issue_map_req(struct ufshpb_lu *hpb,
> +   struct ufshpb_region *rgn,
> +   struct ufshpb_subregion *srgn)
> +{
> +   struct ufshpb_req *map_req;
> +   unsigned long flags;
> +   int ret = 0;
> +
> +   spin_lock_irqsave(&hpb->hpb_state_lock, flags);
> +   /*
> +* Since the region state change occurs only in the hpb task-work,
> +* the state of the region cannot HPB_RGN_INACTIVE at this point.
> +* The region state must be changed in the hpb task-work
I think that you called this worker map_work?


> +   spin_unlock_irqrestore(&hpb->hpb_state_lock, flags);
> +   ret = ufshpb_add_region(hpb, rgn);
If this is not an active region,
Although the device indicated to activate a specific subregion, 
You are activating all the subregions of that region.
You should elaborate on that in your commit log,
and explain why this is the correct activation course.

> +   /*
> +* If the active region and the inactive region are the same,
> +* we will inactivate this region.
> +* The device could check this (region inactivated) and
> +* will response the proper active region information
> +*/
> +   spin_lock(&hpb->rsp_list_lock);
> +   for (i = 0; i < rsp_field->active_rgn_cnt; i++) {
> +   rgn_idx =
> +   
> be16_to_cpu(rsp_field->hpb_active_field[i].active_rgn);
> +   srgn_idx =
> +   
> be16_to_cpu(rsp_field->hpb_active_field[i].active_srgn);
get_unaligned instead of be16_to_cpu ?

> +
> +   dev_dbg(&hpb->hpb_lu_dev, "activate(%d) region %d - %d\n",
> +   i, rgn_idx, srgn_idx);
> +   ufshpb_update_active_info(hpb, rgn_idx, srgn_idx);
> +   atomic_inc(&hpb->stats.rb_active_cnt);
> +   }
> +
> +   for (i = 0; i < rsp_field->inactive_rgn_cnt; i++) {
> +   rgn_idx = be16_to_cpu(rsp_field->hpb_inactive_field[i]);
> +   dev_dbg(&hpb->hpb_lu_dev, "inactivate(%d) region %d\n",
> +   i, rgn_idx);
> +   ufshpb_update_inactive_info(hpb, rgn_idx);
> +   atomic_inc(&hpb->stats.rb_inactive_cnt);
> +   }
> +   spin_unlock(&hpb->rsp_list_lock);
> +
> +   dev_dbg(&hpb->hpb_lu_dev, "Noti: #ACT %u #INACT %u\n",
> +   rsp_field->active_rgn_cnt, rsp_field->inactive_rgn_cnt);
> +
> +   queue_work(ufshpb_drv.ufshpb_wq, &hpb->map_work);
> +}
> +
> +/* routine : isr (ufs) */
> +static void ufshpb_rsp_upiu(struct ufs_hba *hba, struct ufshcd_lrb *lrbp)
> +{
> +   struct ufshpb_lu *hpb;
> +   struct ufshpb_rsp_field *rsp_field;
> +   int data_seg_len, ret;
> +
> +   data_seg_len = be32_to_cpu(lrbp->ucd_rsp_ptr->header.d

[PATCH] kprobes: use strncpy_from_kernel_nofault() in fetch_store_string()

[Sven Schnelle]

With the latest linux-next i noticed that some tests in the
ftrace test suites are failing on s390, namely:

[FAIL] Kprobe event symbol argument
[FAIL] Kprobe event with comm arguments

The following doesn't work anymore:

cd /sys/kernel/tracing
echo 'p:testprobe _do_fork comm=$comm ' >kprobe_events
echo 1 >events/kprobes/testprobe/enable
cat trace

it will just show

test.sh-519   [012] 18.580625: testprobe: (_do_fork+0x0/0x3c8) 
comm=(fault)

Looking at the source i see that there are two helpers for reading strings:

fetch_store_string_user() -> read string from user space
fetch_store_string() -> read string from kernel space(?)

but in the end both are using strncpy_from_user_nofault(), but
fetch_store_string() should use strncpy_from_kernel_nofault().

Signed-off-by: Sven Schnelle 
Acked-by: Masami Hiramatsu 
Acked-by: Christoph Hellwig 
---
 kernel/trace/trace_kprobe.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index b1f21d558e45..ea8d0b094f1b 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -1278,7 +1278,7 @@ fetch_store_string(unsigned long addr, void *dest, void 
*base)
 * Try to get string again, since the string can be changed while
 * probing.
 */
-   ret = strncpy_from_user_nofault(__dest, (void *)addr, maxlen);
+   ret = strncpy_from_kernel_nofault(__dest, (void *)addr, maxlen);
if (ret >= 0)
*(u32 *)dest = make_data_loc(ret, __dest - base);
 
-- 
2.17.1

Re: [kernfs] ea7c5fc39a: stress-ng.stream.ops_per_sec 11827.2% improvement

[Greg Kroah-Hartman]

On Sat, Jun 06, 2020 at 11:52:16PM +0800, kernel test robot wrote:
> Greeting,
> 
> FYI, we noticed a 11827.2% improvement of stress-ng.stream.ops_per_sec due to 
> commit:
> 
> 
> commit: ea7c5fc39ab005b501e0c7666c29db36321e4f74 ("[PATCH 1/4] kernfs: switch 
> kernfs to use an rwsem")
> url: 
> https://github.com/0day-ci/linux/commits/Ian-Kent/kernfs-proposed-locking-and-concurrency-improvement/20200525-134849
> 

Seriously?  That's a huge performance increase, and one that feels
really odd.  Why would a stress-ng test be touching sysfs?

thanks,

greg k-h

WARNING in tipc_msg_append

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:5e9eeccc tipc: fix NULL pointer dereference in streaming
git tree:   net
console output: https://syzkaller.appspot.com/x/log.txt?x=15ee307a10
kernel config:  https://syzkaller.appspot.com/x/.config?x=a16ddbc78955e3a9
dashboard link: https://syzkaller.appspot.com/bug?extid=75139a7d2605236b0b7f
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=118e296110
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=10534c1e10

The bug was bisected to:

commit 0a3e060f340dbe232ffa290c40f879b7f7db595b
Author: Tuong Lien 
Date:   Tue May 26 09:38:38 2020 +

tipc: add test for Nagle algorithm effectiveness

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1097e65a10
final crash:https://syzkaller.appspot.com/x/report.txt?x=1297e65a10
console output: https://syzkaller.appspot.com/x/log.txt?x=1497e65a10

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+75139a7d2605236b0...@syzkaller.appspotmail.com
Fixes: 0a3e060f340d ("tipc: add test for Nagle algorithm effectiveness")

[ cut here ]
WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150 check_copy_size 
include/linux/thread_info.h:150 [inline]
WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150 copy_from_iter 
include/linux/uio.h:144 [inline]
WARNING: CPU: 0 PID: 6808 at include/linux/thread_info.h:150 
tipc_msg_append+0x49a/0x5e0 net/tipc/msg.c:242
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 6808 Comm: syz-executor028 Not tainted 5.7.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+0x188/0x20d lib/dump_stack.c:118
 panic+0x2e3/0x75c kernel/panic.c:221
 __warn.cold+0x2f/0x35 kernel/panic.c:582
 report_bug+0x27b/0x2f0 lib/bug.c:195
 fixup_bug arch/x86/kernel/traps.c:105 [inline]
 fixup_bug arch/x86/kernel/traps.c:100 [inline]
 do_error_trap+0x12b/0x220 arch/x86/kernel/traps.c:197
 do_invalid_op+0x32/0x40 arch/x86/kernel/traps.c:216
 invalid_op+0x23/0x30 arch/x86/entry/entry_64.S:1027
RIP: 0010:check_copy_size include/linux/thread_info.h:150 [inline]
RIP: 0010:copy_from_iter include/linux/uio.h:144 [inline]
RIP: 0010:tipc_msg_append+0x49a/0x5e0 net/tipc/msg.c:242
Code: 18 48 89 f8 48 c1 e8 03 42 80 3c 38 00 0f 85 2e 01 00 00 49 83 7e 18 00 
0f 84 d4 fc ff ff e8 4d e7 da f9 0f 0b e8 46 e7 da f9 <0f> 0b 41 bc f2 ff ff ff 
e8 39 e7 da f9 44 89 e0 48 83 c4 50 5b 5d
RSP: 0018:c90001627770 EFLAGS: 00010293
RAX: 88808efd0580 RBX: 0018 RCX: 8798a901
RDX:  RSI: 8798 RDI: 0007
RBP: ffe8 R08: 88808efd0580 R09: ed1012e78f1d
R10: 8880973c78e7 R11: ed1012e78f1c R12: 8880973c78e8
R13: 8880973c78d0 R14: 888095fbecc0 R15: dc00
 __tipc_sendstream+0xac3/0x1200 net/tipc/socket.c:1578
 tipc_sendstream+0x4c/0x70 net/tipc/socket.c:1533
 tipc_send_packet+0x3c/0x60 net/tipc/socket.c:1638
 sock_sendmsg_nosec net/socket.c:652 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:672
 sys_sendmsg+0x32f/0x810 net/socket.c:2352
 ___sys_sendmsg+0x100/0x170 net/socket.c:2406
 __sys_sendmmsg+0x195/0x480 net/socket.c:2496
 __do_sys_sendmmsg net/socket.c:2525 [inline]
 __se_sys_sendmmsg net/socket.c:2522 [inline]
 __x64_sys_sendmmsg+0x99/0x100 net/socket.c:2522
 do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
 entry_SYSCALL_64_after_hwframe+0x49/0xb3
RIP: 0033:0x4401e9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fff7b6a58b8 EFLAGS: 0246 ORIG_RAX: 0133
RAX: ffda RBX: 004002c8 RCX: 004401e9
RDX: 04924924924926c8 RSI: 20236fc8 RDI: 0004
RBP: 006ca018 R08:  R09: 004002c8
R10:  R11: 0246 R12: 00401a70
R13: 00401b00 R14:  R15: 
Kernel Offset: disabled
Rebooting in 86400 seconds..


---
This bug 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 bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [GIT PULL] PCI changes for v5.8

[Linus Torvalds]

On Fri, Jun 5, 2020 at 1:23 PM Bjorn Helgaas  wrote:
>
> You should see two conflicts:
>
>   2) Documentation/devicetree/bindings/pci/cdns-pcie.yaml: conflict
>   between Rob's 3d21a4609335 ("dt-bindings: Remove cases of 'allOf'
>   containing a '$ref'") and Kishon's fb5f8f3ca5f8 ("dt-bindings: PCI:
>   cadence: Deprecate inbound/outbound specific bindings").
>
>   Kishon moved a hunk from cdns-pcie.yaml to cdns-pcie-ep.yaml and
>   cdns-pcie-host.yaml, so I think the new homes need Rob's change:
>
> Documentation/devicetree/bindings/pci/cdns-pcie-ep.yaml
> Documentation/devicetree/bindings/pci/cdns-pcie-host.yaml

I decided not to touch those two files, because the AllOf rules seem
strange, and not all were updated anyway, so I'm going to leave it to
others (ie Rob) to decide how they want to handle it.

I suspect your resolution is correct, but I also suspect it doesn't
_matter_, and since I don't understand the yaml rules I'll leave it
alone.

Rob?

  Linus

Re: [PATCH v10 6/6] powerpc/papr_scm: Implement support for PAPR_PDSM_HEALTH

[Segher Boessenkool]

On Sat, Jun 06, 2020 at 06:04:11PM +0530, Vaibhav Jain wrote:
> >> +  /* update health struct with various flags derived from health bitmap */
> >> +  health = (struct nd_papr_pdsm_health) {
> >> +  .dimm_unarmed = p->health_bitmap & PAPR_PMEM_UNARMED_MASK,
> >> +  .dimm_bad_shutdown = p->health_bitmap & 
> >> PAPR_PMEM_BAD_SHUTDOWN_MASK,
> >> +  .dimm_bad_restore = p->health_bitmap & 
> >> PAPR_PMEM_BAD_RESTORE_MASK,
> >> +  .dimm_encrypted = p->health_bitmap & PAPR_PMEM_ENCRYPTED,
> >> +  .dimm_locked = p->health_bitmap & PAPR_PMEM_SCRUBBED_AND_LOCKED,
> >> +  .dimm_scrubbed = p->health_bitmap & 
> >> PAPR_PMEM_SCRUBBED_AND_LOCKED,
> >
> > Are you sure these work?  These are not assignments to a bool so I don't 
> > think
> > gcc will do what you want here.
> Yeah, somehow this slipped by and didnt show up in my tests. I checked
> the assembly dump and seems GCC was silently skipping initializing these
> fields without making any noise.

It's not "skipping" that, it initialises the field to 0, just like your
code said it should :-)

If you think GCC should warn for this, please open a PR?  It is *normal*
for bit-fields to be truncated from what is assigned to it, but maybe we
could warn for it in the 1-bit case (we currently don't seem to, even
when the bit-field type is _Bool).

Thanks,


Segher

Re: [PATCH v4] platform: x86: Add ACPI driver for ChromeOS

[Dmitry Torokhov]

Hi Rafael,

On Fri, Jun 05, 2020 at 01:17:15PM +0200, Rafael J. Wysocki wrote:
> 
> First off, GGL0001 is not a valid ACPI device ID, because the GGL prefix is 
> not
> present in the list at https://uefi.org/acpi_id_list
> 
> There are two ways to address that.  One would be to take the GOOG prefix
> (present in the list above), append a proper unique number (if I were to
> guess, I would say that 0001 had been reserved already) to it and then
> put the resulting device ID into the firmware, to be returned _HID for the
> device in question (you can add a _CID returning "GGL0001" so it can be
> found by the old invalid ID at least from the kernel).

This is not going to happen, as there are devices in the wild with such
firmware (i.e. Samus - Google Pixel 2 - was shipped in 2015). Even if
Google were to release updated firmware (which is quite unlikely), it
does not mean that users who are not using Chrome OS would apply updated
firmware.

> The other one would
> be to properly register the GGL prefix for Google and establish a process for
> allocating IDs with that prefix internally.

I think it depends on whether there are more instances of "GGL" prefix.
I thought we mostly used GOOG for everything.

Thanks.

-- 
Dmitry

Re: [PATCH 2/2] net: dsa: qca8k: introduce SGMII configuration options

[Jonathan McDowell]

On Sat, Jun 06, 2020 at 02:43:56PM +0100, Russell King - ARM Linux admin wrote:
> On Sat, Jun 06, 2020 at 11:59:09AM +0100, Jonathan McDowell wrote:
> > So the device in question is a 7 port stand alone switch chip. There's a
> > single SGMII port which is configurable between port 0 + 6 (they can
> > also be configure up as RGMII, while the remaining 5 ports have their
> > own phys).
> > 
> > It sounds like there's a strong preference to try and auto configure
> > things as much as possible, so I should assume the CPU port is in MAC
> > mode, and anything not tagged as a CPU port is talking to a PHY/BASEX.
> > 
> > I assume I can use PHY_INTERFACE_MODE_1000BASEX on the
> > phylink_mac_config call to choose BASEX?
> 
> Yes, but from what you've mentioned above, I think I need to ensure that
> there's a proper understanding here.
> 
> 1000BASE-X is the IEEE 802.3 defined 1G single lane Serdes protocol.
> SGMII is different; it's a vendor derivative of 1000BASE-X which has
> become a de-facto standard.
> 
> Both are somewhat compatible with each other; SGMII brings with it
> additional data replication to achieve 100M and 10M speeds, while
> keeping the link running at 1.25Gbaud.  In both cases, there is a
> 16-bit "configuration" word that is passed between the partners.
> 
> 1000BASE-X uses this configuration word to advertise the abilities of
> each end, which is limited to duplex and pause modes only.  This you
> get by specifying the phy-mode="1000base-x" and
> managed="in-band-status" in DT.
> 
> SGMII uses this configuration word for the media side to inform the
> system side which mode it wishes to operate the link: the speed and
> duplex.  Some vendors extend it to include EEE parameters as well,
> or pause modes.  You get this via phy-mode="sgmii" and
> managed="in-band-status" in DT.
> 
> Then there are variants where the configuration word is not present.
> In this case, the link has to be manually configured, and without the
> configuration word, SGMII operating at 1G is compatible with
> 1000base-X operating at 1G.  Fixed-link can be used for this, although
> fixed-link will always report that the link is up at the moment; that
> may change in the future, it's something that is being looked into at
> the moment.

The hardware I'm using has the switch connected to the CPU via the SGMII
link, and all instances I can find completely disable inband
configuration for that case. However the data sheet has an SGMII control
register which allows configuration of the various auto-negotiation
parameters (as well as whether we're base-x or sgmii) so I think the
full flexibility is there.

I've got an initial port over to using phylink and picking up the
parameters that way (avoiding any device tree option changes) that seems
to be working, but I'll do a bit more testing before sending out a v2
RFC.

J.

-- 
/-\ | There are always at least two ways
|@/  Debian GNU/Linux Developer | to program the same thing.
\-  |

Re: [PATCH v1 2/2] of: property: Improve cycle detection when one of the devices is never added

[Saravana Kannan]

On Fri, Jun 5, 2020 at 5:36 PM Saravana Kannan  wrote:
>
> Consider this example where -> means LHS device is a consumer of RHS
> device and indentation represents "child of" of the previous device.
>
> Device A -> Device C
>
> Device B -> Device A
> Device C
>
> Without this commit:
> 1. Device A is added.
> 2. Device A is added to waiting for supplier list (Device C)
> 3. Device B is added
> 4. Device B is linked as a consumer to Device A
> 5. Device A doesn't probe because it's waiting for Device C to be added.
> 6. Device B doesn't probe because Device A hasn't probed.
> 7. Device C will never be added because it's parent hasn't probed.
>
> So, Device A, B and C will be in a probe/add deadlock.
>
> This commit detects this scenario and stops trying to create a device
> link between Device A and Device C since doing so would create a cycle:
> Device A -> Devic C -(parent)-> Device B -> Device A.
>
> With this commit:
> 1. Device A is added.
> 3. Device B is added
> 4. Device B is linked as a consumer to Device A
> 5. Device A probes.
> 6. Device B probes because Device A has probed.
> 7. Device C is added and probed.
>
> Signed-off-by: Saravana Kannan 
> ---
>  drivers/of/property.c | 44 +--
>  1 file changed, 38 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 1f2086f4e7ce..7eebe21274a4 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1014,6 +1014,20 @@ static bool of_is_ancestor_of(struct device_node 
> *test_ancestor,
> return false;
>  }
>
> +static struct device *of_get_next_parent_dev(struct device_node *np)
> +{
> +   struct device *dev = NULL;
> +
> +   of_node_get(np);
> +   do {
> +   np = of_get_next_parent(np);
> +   if (np)
> +   dev = get_dev_from_fwnode(&np->fwnode);
> +   } while (np && !dev);
> +   of_node_put(np);
> +   return dev;
> +}
> +
>  /**
>   * of_link_to_phandle - Add device link to supplier from supplier phandle
>   * @dev: consumer device
> @@ -1035,10 +1049,9 @@ static bool of_is_ancestor_of(struct device_node 
> *test_ancestor,
>  static int of_link_to_phandle(struct device *dev, struct device_node *sup_np,
>   u32 dl_flags)
>  {
> -   struct device *sup_dev;
> +   struct device *sup_dev, *sup_par_dev;
> int ret = 0;
> struct device_node *tmp_np = sup_np;
> -   int is_populated;
>
> of_node_get(sup_np);
> /*
> @@ -1075,16 +1088,35 @@ static int of_link_to_phandle(struct device *dev, 
> struct device_node *sup_np,
> return -EINVAL;
> }
> sup_dev = get_dev_from_fwnode(&sup_np->fwnode);
> -   is_populated = of_node_check_flag(sup_np, OF_POPULATED);
> -   of_node_put(sup_np);
> -   if (!sup_dev && is_populated) {
> +   if (!sup_dev && of_node_check_flag(sup_np, OF_POPULATED)) {
> /* Early device without struct device. */
> dev_dbg(dev, "Not linking to %pOFP - No struct device\n",
> sup_np);
> +   of_node_put(sup_np);
> return -ENODEV;
> } else if (!sup_dev) {
> -   return -EAGAIN;
> +   sup_par_dev = of_get_next_parent_dev(sup_np);
> +   of_node_put(sup_np);
> +
> +   /*
> +* DL_FLAG_SYNC_STATE_ONLY doesn't block probing, so cycle
> +* detection isn't necessary and shouldn't be done.
> +*/
> +   if (dl_flags & DL_FLAG_SYNC_STATE_ONLY)
> +   return -EAGAIN;

I need to put_device(sup_par_dev) before I return here and at other places
below. I'll send a v2 later to fix this.


-Saravana

> +
> +   /*
> +* If devices haven't been created for any of the ancestors, 
> we
> +* can't check for cycles. So let's try again later.
> +*/
> +   if (!sup_par_dev)
> +   return -EAGAIN;
> +
> +   /* Cyclic dependency detected, don't try to link */
> +   if (device_is_dependent(dev, sup_par_dev))
> +   return -EINVAL;
> }
> +   of_node_put(sup_np);
> if (!device_link_add(dev, sup_dev, dl_flags))
> ret = -EINVAL;
> put_device(sup_dev);
> --
> 2.27.0.278.ge193c7cf3a9-goog
>

Re: BUG: kernel NULL pointer dereference from check_preempt_wakeup()

[Paul E. McKenney]

On Fri, Jun 05, 2020 at 05:51:26PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 05, 2020 at 11:41:59AM -0700, Paul E. McKenney wrote:
> > On Fri, Jun 05, 2020 at 07:16:07AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jun 05, 2020 at 03:14:51PM +0200, Peter Zijlstra wrote:
> > > 
> > > No KCSAN.  GCC 8.2.1.  No cgroups unless the kernel creates some.
> > > No userspace other than a C-language binary named "init" that
> > > sleeps in an infinite loop.
> > > 
> > > .config attached.
> > 
> > And in case it is helpful, here is the output of "git bisect view",
> > which lists rather more commits than "git bisect run" claims, but there
> > are only a few scheduler commits below.  I don't see anything that
> > I can prove can cause this problem, but there are some that are at
> > least related to this code path.
> > 
> > Is there anything that is actually relevant?
> 
> And the run with the WARN and tracing did hit two failures, and the
> corresponding console logs are in the attached tarball.  Both of them
> triggered a warning as well as the failure.

And the current state of the bisection, for whatever it is worth.

Thanx, Paul



dbe9337109c2 sched/cpuacct: Fix charge cpuacct.usage_sys
04f5c362ec6d sched/fair: Replace zero-length array with flexible-array
95d685935a2e sched/pelt: Sync util/runnable_sum with PELT window when 
propagating
12aa2587388d sched/cpuacct: Use __this_cpu_add() instead of this_cpu_ptr()
7d148be69e3a sched/fair: Optimize enqueue_task_fair()
9013196a467e Merge branch 'sched/urgent'
2a0a24ebb499 sched: Make scheduler_ipi inline
90b5363acd47 sched: Clean up scheduler_ipi()
b1d1779e5ef7 sched/core: Simplify sched_init()
12ac6782a40a sched/swait: Reword some of the main description
17c891ab3491 sched/fair: Use __this_cpu_read() in wake_wide()
bf2c59fce407 sched/core: Fix illegal RCU from offline CPUs
f38f12d1e081 sched/fair: Mark sched_init_granularity __init
5a6d6a6ccb5f sched/fair: Refill bandwidth before scaling
457d1f465778 sched: Extract the task putting code from pick_next_task()
d91cecc15662 sched: Make newidle_balance() static again
36c5bdc43870 sched/topology: Kill SD_LOAD_BALANCE
e669ac8ab952 sched: Remove checks against SD_LOAD_BALANCE
9818427c6270 sched/debug: Make sd->flags sysctl read-only
45da27732b0b sched/fair: find_idlest_group(): Remove unused sd_flag parameter
586b58cac8b4 exit: Move preemption fixup up, move blocking operations down
64297f2b03cc sched/fair: Simplify the code of should_we_balance()
ab93a4bc955b sched/fair: Remove distribute_running from CFS bandwidth
e98fa02c4f2e sched/fair: Eliminate bandwidth race between throttling and 
distribution
f080d93e1d41 sched/debug: Fix trival print_task() format

Re: [PATCH 1/2][RFC] PM-runtime: Move all runtime usage related function to runtime.c

[Chen Yu]

On Sat, Jun 06, 2020 at 03:05:35AM +0800, Chen Yu wrote:
> In order to track all the runtime usage count change, move the code
> related to runtime usage count change from pm_runtime.h to runtime.c,
> so that in runtime.c we can leverage trace event to do the tracking.
> Meanwhile export pm_runtime_get_noresume() and pm_runtime_put_noidle()
> so the module can use them.
> 
> No functional change.
>
There is a compile issue found by lkp, will send a
new version out.

Thanks,
Chenyu

Re: [GIT PULL] workqueue changes for v5.8-rc1

[pr-tracker-bot]

The pull request you sent on Fri, 5 Jun 2020 16:20:22 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-5.8

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

Thank you!

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

Re: [GIT PULL] cgroup changes for v5.8-rc1

[pr-tracker-bot]

The pull request you sent on Fri, 5 Jun 2020 16:06:01 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-5.8

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4a7e89c5ec0238017a757131eb9ab8dc111f961c

Thank you!

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

Re: [GIT PULL] integrity subsystem updates for v5.8

[pr-tracker-bot]

The pull request you sent on Fri, 05 Jun 2020 13:02:28 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity.git 
> tags/integrity-v5.8

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3c0ad98c2eda5ff30d23777e30744be6f7b8f097

Thank you!

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

[GIT PULL] arch/sh updates for 5.8

[Rich Felker]

The following changes since commit 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162:

  Linux 5.7 (2020-05-31 16:49:15 -0700)

are available in the Git repository at:

  git://git.libc.org/linux-sh tags/sh-for-5.8

for you to fetch changes up to 37744feebc086908fd89760650f458ab19071750:

  sh: remove sh5 support (2020-06-01 14:48:52 -0400)


Fix for arch/sh build regression with newer binutils, removal of SH5,
fixes for module exports, and misc cleanup.


Arnd Bergmann (1):
  sh: remove sh5 support

Bin Meng (1):
  sh: Replace CONFIG_MTD_M25P80 with CONFIG_MTD_SPI_NOR in 
sh7757lcr_defconfig

Krzysztof Kozlowski (2):
  sh: sh4a: Bring back tmu3_device early device
  sh: configs: Cleanup old Kconfig IO scheduler options

Kuninori Morimoto (4):
  sh: Add missing DECLARE_EXPORT() for __ashiftrt_r4_xx
  sh: Convert iounmap() macros to inline functions
  sh: Convert ins[bwl]/outs[bwl] macros to inline functions
  sh: add missing EXPORT_SYMBOL() for __delay

Romain Naour (1):
  arch/sh: vmlinux.scr

 arch/sh/Kconfig   |   62 +-
 arch/sh/Kconfig.cpu   |9 -
 arch/sh/Kconfig.debug |   13 +-
 arch/sh/Makefile  |   29 +-
 arch/sh/boot/compressed/Makefile  |   12 +-
 arch/sh/boot/compressed/misc.c|8 -
 arch/sh/boot/compressed/vmlinux.scr   |2 +-
 arch/sh/configs/apsh4ad0a_defconfig   |3 +-
 arch/sh/configs/kfr2r09_defconfig |2 -
 arch/sh/configs/magicpanelr2_defconfig|2 -
 arch/sh/configs/polaris_defconfig |1 -
 arch/sh/configs/r7780mp_defconfig |2 -
 arch/sh/configs/r7785rp_defconfig |2 -
 arch/sh/configs/rsk7201_defconfig |2 -
 arch/sh/configs/rsk7203_defconfig |2 -
 arch/sh/configs/rsk7264_defconfig |2 -
 arch/sh/configs/rsk7269_defconfig |2 -
 arch/sh/configs/sdk7786_defconfig |3 +-
 arch/sh/configs/se7206_defconfig  |2 -
 arch/sh/configs/se7343_defconfig  |1 -
 arch/sh/configs/se7619_defconfig  |2 -
 arch/sh/configs/se7705_defconfig  |2 -
 arch/sh/configs/se7712_defconfig  |2 -
 arch/sh/configs/se7721_defconfig  |2 -
 arch/sh/configs/se7722_defconfig  |2 -
 arch/sh/configs/se7780_defconfig  |1 -
 arch/sh/configs/sh7710voipgw_defconfig|1 -
 arch/sh/configs/sh7757lcr_defconfig   |2 +-
 arch/sh/configs/shmin_defconfig   |2 -
 arch/sh/configs/ul2_defconfig |2 -
 arch/sh/drivers/pci/Makefile  |1 -
 arch/sh/drivers/pci/ops-sh5.c |   65 -
 arch/sh/drivers/pci/pci-sh5.c |  217 
 arch/sh/drivers/pci/pci-sh5.h |  108 --
 arch/sh/include/asm/barrier.h |4 +-
 arch/sh/include/asm/bitops.h  |   26 -
 arch/sh/include/asm/bl_bit.h  |   11 +-
 arch/sh/include/asm/bl_bit_64.h   |   37 -
 arch/sh/include/asm/bugs.h|4 -
 arch/sh/include/asm/cache_insns.h |   12 +-
 arch/sh/include/asm/cache_insns_64.h  |   20 -
 arch/sh/include/asm/checksum.h|6 +-
 arch/sh/include/asm/elf.h |   23 -
 arch/sh/include/asm/extable.h |4 -
 arch/sh/include/asm/fixmap.h  |4 -
 arch/sh/include/asm/io.h  |6 +-
 arch/sh/include/asm/io_noioport.h |   34 +-
 arch/sh/include/asm/irq.h |3 -
 arch/sh/include/asm/mmu_context.h |   12 -
 arch/sh/include/asm/mmu_context_64.h  |   75 --
 arch/sh/include/asm/page.h|   21 +-
 arch/sh/include/asm/pgtable.h |   17 -
 arch/sh/include/asm/pgtable_64.h  |  307 -
 arch/sh/include/asm/posix_types.h |6 +-
 arch/sh/include/asm/processor.h   |   14 +-
 arch/sh/include/asm/processor_64.h|  212 ---
 arch/sh/include/asm/ptrace_64.h   |   14 -
 arch/sh/include/asm/string.h  |6 +-
 arch/sh/include/asm/string_64.h   |   21 -
 arch/sh/include/asm/switch_to.h   |   11 +-
 arch/sh/include/asm/switch_to_64.h|   32 -
 arch/sh/include/asm/syscall.h |6 +-
 arch/sh/include/asm/syscall_64.h  |   75 --
 arch/sh/include/asm/syscalls.h|9 +-
 arch/sh/include/asm/syscalls_64.h |   18 -
 arch/sh/include/asm/thread_info.h |4 +-
 arch/sh/include/asm/tlb.h |6 +-
 arch/sh/include/asm/tlb_64.h  |   68 -
 arch/sh/include/asm/traps.h   |4 -
 arch/sh/include/asm/traps_64.h|   35 -
 arch/sh/include/asm/types.h   |5 -
 arch/sh/include/asm/uaccess.h |4 -
 arch/sh/include/asm/uaccess_64.h  |   85 --
 a

[PATCH] Bluetooth: hci_qca: Simplify determination of serial clock on/off state from votes

[Matthias Kaehlcke]

The serial clocks should be on when there is a vote for at least one
of the clocks (RX or TX), and off when there is no 'on' vote. The
current logic to determine the combined state is a bit redundant
in the code paths for different types of votes, use a single
statement in the common path instead.

Signed-off-by: Matthias Kaehlcke 
---

 drivers/bluetooth/hci_qca.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 836949d827ee9..997ddab26a33b 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -289,25 +289,21 @@ static void serial_clock_vote(unsigned long vote, struct 
hci_uart *hu)
case HCI_IBS_TX_VOTE_CLOCK_ON:
qca->tx_vote = true;
qca->tx_votes_on++;
-   new_vote = true;
break;
 
case HCI_IBS_RX_VOTE_CLOCK_ON:
qca->rx_vote = true;
qca->rx_votes_on++;
-   new_vote = true;
break;
 
case HCI_IBS_TX_VOTE_CLOCK_OFF:
qca->tx_vote = false;
qca->tx_votes_off++;
-   new_vote = qca->rx_vote | qca->tx_vote;
break;
 
case HCI_IBS_RX_VOTE_CLOCK_OFF:
qca->rx_vote = false;
qca->rx_votes_off++;
-   new_vote = qca->rx_vote | qca->tx_vote;
break;
 
default:
@@ -315,6 +311,8 @@ static void serial_clock_vote(unsigned long vote, struct 
hci_uart *hu)
return;
}
 
+   new_vote = qca->rx_vote | qca->tx_vote;
+
if (new_vote != old_vote) {
if (new_vote)
__serial_clock_on(hu->tty);
-- 
2.27.0.278.ge193c7cf3a9-goog

Re: [PATCH v26 03/15] leds: multicolor: Introduce a multicolor class definition

[Dan Murphy]

Pavek

Thanks for the review

On 6/6/20 10:53 AM, Pavel Machek wrote:

Hi!


Introduce a multicolor class that groups colored LEDs
within a LED node.

The multi color class groups monochrome LEDs and allows controlling two
aspects of the final combined color: hue and lightness. The former is
controlled via the intensity file and the latter is controlled
via brightness file.

Acked-by: Jacek Anaszewski 
Signed-off-by: Dan Murphy 
diff --git a/Documentation/ABI/testing/sysfs-class-led-multicolor 
b/Documentation/ABI/testing/sysfs-class-led-multicolor
new file mode 100644
index ..7d33a82a4b07
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-led-multicolor
@@ -0,0 +1,34 @@
+What:  /sys/class/leds//brightness
+Date:  March 2020
+KernelVersion: 5.8
+Contact:   Dan Murphy 
+Description:   read/write
+   Writing to this file will update all LEDs within the group to a
+   calculated percentage of what each color LED intensity is set
+   to. The percentage is calculated for each grouped LED via the
+   equation below:
+   led_brightness = brightness * multi_intensity/max_brightness
+
+   For additional details please refer to
+   Documentation/leds/leds-class-multicolor.rst.
+
+   The value of the color is from 0 to
+   /sys/class/leds//max_brightness.

It is not too clear to me what "color" means here.

It would be worth mentioning that this is single integer.


OK I will update this



+What:  /sys/class/leds//multi_index
+Date:  March 2020
+KernelVersion: 5.8
+Contact:   Dan Murphy 
+Description:   read
+   The multi_index array, when read, will output the LED colors
+   by name as they are indexed in the multi_intensity file.

This should specify that it is array of strings.


Yeah this sounds better



+What:  /sys/class/leds//multi_intensity
+Date:  March 2020
+KernelVersion: 5.8
+Contact:   Dan Murphy 
+Description:   read/write
+   Intensity level for the LED color within the array.
+   The intensities for each color must be entered based on the
+   multi_index array.

I'd mention here that it is array of integers, and what the maximum
values are.


Same here.  I will indicate max value cannot exceed max_brightness

But that was what the max_intensity file was for in prior patchsets.




--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9533,6 +9533,14 @@ F:   Documentation/devicetree/bindings/leds/
  F:drivers/leds/
  F:include/linux/leds.h
  
+LED MULTICOLOR FRAMEWORK

+M: Dan Murphy 
+L: linux-l...@vger.kernel.org

I'd like to be mentioned here, too. "M: Pavel Machek
". And I'm not sure if I should be taking MAINTAINER
file update through a LED tree. Should definitely go to separate
patch.


Oh definitely.  I thought it was implied that you and Jacek are both 
Maintainers as well.


I will add you but will wait to see if Jacek wants to be added.

I will separate this out and make it a separate patch





diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9cdc4cfc5d11..fe7d90d4fa23 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -30,6 +30,16 @@ config LEDS_CLASS_FLASH
  for the flash related features of a LED device. It can be built
  as a module.
  
+config LEDS_CLASS_MULTI_COLOR

+   tristate "LED MultiColor LED Class Support"

"LED MultiColor Class Support"


OK.

Dan



Best regards,
Pavel

Re: [PATCH v5 07/11] PCI: qcom: Define some PARF params needed for ipq8064 SoC

[Stanimir Varbanov]

Hi,

On 6/2/20 2:53 PM, Ansuel Smith wrote:
> Set some specific value for Tx De-Emphasis, Tx Swing and Rx equalization
> needed on some ipq8064 based device (Netgear R7800 for example). Without
> this the system locks on kernel load.
> 
> Fixes: 82a823833f4e ("PCI: qcom: Add Qualcomm PCIe controller driver")
> Signed-off-by: Ansuel Smith 
> Cc: sta...@vger.kernel.org # v4.5+
> Reviewed-by: Rob Herring 
> ---
>  drivers/pci/controller/dwc/pcie-qcom.c | 27 ++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c 
> b/drivers/pci/controller/dwc/pcie-qcom.c
> index f2ea1ab6f584..f5398b0d270c 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -46,6 +46,9 @@
>  
>  #define PCIE20_PARF_PHY_CTRL 0x40
>  #define PCIE20_PARF_PHY_REFCLK   0x4C
> +#define PHY_REFCLK_SSP_ENBIT(16)
> +#define PHY_REFCLK_USE_PAD   BIT(12)

These two are not used in the patch, please move it in 08/11.

> +
>  #define PCIE20_PARF_DBI_BASE_ADDR0x168
>  #define PCIE20_PARF_SLV_ADDR_SPACE_SIZE  0x16C
>  #define PCIE20_PARF_MHI_CLOCK_RESET_CTRL 0x174
> @@ -77,6 +80,18 @@
>  #define DBI_RO_WR_EN 1
>  
>  #define PERST_DELAY_US   1000
> +/* PARF registers */
> +#define PCIE20_PARF_PCS_DEEMPH   0x34
> +#define PCS_DEEMPH_TX_DEEMPH_GEN1(x) ((x) << 16)
> +#define PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(x)   ((x) << 8)
> +#define PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(x) ((x) << 0)
> +
> +#define PCIE20_PARF_PCS_SWING0x38
> +#define PCS_SWING_TX_SWING_FULL(x)   ((x) << 8)
> +#define PCS_SWING_TX_SWING_LOW(x)((x) << 0)
> +
> +#define PCIE20_PARF_CONFIG_BITS  0x50
> +#define PHY_RX0_EQ(x)((x) << 24)
>  
>  #define PCIE20_v3_PARF_SLV_ADDR_SPACE_SIZE   0x358
>  #define SLV_ADDR_SPACE_SZ0x1000
> @@ -293,6 +308,7 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
>   struct qcom_pcie_resources_2_1_0 *res = &pcie->res.v2_1_0;
>   struct dw_pcie *pci = pcie->pci;
>   struct device *dev = pci->dev;
> + struct device_node *node = dev->of_node;
>   u32 val;
>   int ret;
>  
> @@ -347,6 +363,17 @@ static int qcom_pcie_init_2_1_0(struct qcom_pcie *pcie)
>   val &= ~BIT(0);
>   writel(val, pcie->parf + PCIE20_PARF_PHY_CTRL);
>  
> + if (of_device_is_compatible(node, "qcom,pcie-ipq8064")) {
> + writel(PCS_DEEMPH_TX_DEEMPH_GEN1(24) |
> +PCS_DEEMPH_TX_DEEMPH_GEN2_3_5DB(24) |
> +PCS_DEEMPH_TX_DEEMPH_GEN2_6DB(34),
> +pcie->parf + PCIE20_PARF_PCS_DEEMPH);
> + writel(PCS_SWING_TX_SWING_FULL(120) |
> +PCS_SWING_TX_SWING_LOW(120),
> +pcie->parf + PCIE20_PARF_PCS_SWING);

Please fix the indentations above.

> + writel(PHY_RX0_EQ(4), pcie->parf + PCIE20_PARF_CONFIG_BITS);
> + }
> +
>   /* enable external reference clock */
>   val = readl(pcie->parf + PCIE20_PARF_PHY_REFCLK);
>   val |= BIT(16);
> 

-- 
regards,
Stan

Re: [PATCH 5.4 00/38] 5.4.45-rc1 review

[Naresh Kamboju]

On Fri, 5 Jun 2020 at 19:49, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.4.45 release.
> There are 38 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 07 Jun 2020 13:54:56 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.45-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.4.45-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.4.y
git commit: 0e4e419d5fc3f776cc5ac829737dd6020f89f2a6
git describe: v5.4.44-39-g0e4e419d5fc3
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.44-39-g0e4e419d5fc3

No regressions (compared to build v5.4.44)

No fixes (compared to build v5.4.44)

Ran 32219 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan

Test Suites
---
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* libgpiod
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-sched-tests
* ltp-syscalls-tests
* perf
* v4l2-compliance
* libhugetlbfs
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-ipc-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-securebits-tests
* network-basic-tests
* ltp-controllers-tests
* ltp-open-posix-tests
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH] io: pressure: zpa2326: handle pm_runtime_get_sync failure

[Jonathan Cameron]

On Thu,  4 Jun 2020 21:44:44 -0500
Navid Emamdoost  wrote:

> Calling pm_runtime_get_sync increments the counter even in case of
> failure, causing incorrect ref count. Call pm_runtime_put if
> pm_runtime_get_sync fails.
> 
> Signed-off-by: Navid Emamdoost 

Hi Navid,

This looks to be a fix, be it for a case that we are hopefully
unlikely to ever hit.  Please could you add an appropriate
Fixes tag so we can work out how far to backport it?

Patch looks good to me so if you just reply with a suitable
tag I can add it whilst applying.

Thanks,

Jonathan

> ---
>  drivers/iio/pressure/zpa2326.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/pressure/zpa2326.c b/drivers/iio/pressure/zpa2326.c
> index 99dfe33ee402..245f2e2d412b 100644
> --- a/drivers/iio/pressure/zpa2326.c
> +++ b/drivers/iio/pressure/zpa2326.c
> @@ -664,8 +664,10 @@ static int zpa2326_resume(const struct iio_dev 
> *indio_dev)
>   int err;
>  
>   err = pm_runtime_get_sync(indio_dev->dev.parent);
> - if (err < 0)
> + if (err < 0) {
> + pm_runtime_put(indio_dev->dev.parent);
>   return err;
> + }
>  
>   if (err > 0) {
>   /*

Re: [PATCH 5.6 00/43] 5.6.17-rc1 review

[Naresh Kamboju]

On Fri, 5 Jun 2020 at 19:48, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 5.6.17 release.
> There are 43 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sun, 07 Jun 2020 13:54:56 +.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.6.17-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.6.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 5.6.17-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-5.6.y
git commit: 6266fb28693fc3d724b6a365a86e04a846a4f991
git describe: v5.6.16-44-g6266fb28693f
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-5.6-oe/build/v5.6.16-44-g6266fb28693f

No regressions (compared to build v5.6.16)

No fixes (compared to build v5.6.16)

Ran 33592 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c
- hi6220-hikey
- i386
- juno-r2
- juno-r2-compat
- juno-r2-kasan
- nxp-ls2088
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15
- x86
- x86-kasan

Test Suites
---
* build
* install-android-platform-tools-r2600
* install-android-platform-tools-r2800
* kselftest
* kselftest/drivers
* kselftest/filesystems
* kselftest/net
* libgpiod
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-dio-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* perf
* ltp-cve-tests
* ltp-hugetlb-tests
* ltp-mm-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-open-posix-tests
* network-basic-tests
* v4l2-compliance
* kvm-unit-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-native/drivers
* kselftest-vsyscall-mode-native/filesystems
* kselftest-vsyscall-mode-native/net
* kselftest-vsyscall-mode-none
* kselftest-vsyscall-mode-none/drivers
* kselftest-vsyscall-mode-none/filesystems
* kselftest-vsyscall-mode-none/net

-- 
Linaro LKFT
https://lkft.linaro.org

[GIT PULL] dma-mapping updates for 5.8, part 2

[Christoph Hellwig]

These were in a separate stable branch so that various media and drm
trees could pull the in for bug fixes, but looking at linux-next that
hasn't actually happened yet.  Still sending the APIs to you in the
hope that these bug fixes get picked up for 5.8 in one way or another.


The following changes since commit 24085f70a6e1b0cb647ec92623284641d8270637:

  Merge tag 'trace-v5.7-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace (2020-05-12 
11:06:26 -0700)

are available in the Git repository at:

  git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.8-2

for you to fetch changes up to 48530d9fab0d3bf08827f9167be54acf66d4d457:

  iommu: add generic helper for mapping sgtable objects (2020-05-13 15:48:20 
+0200)


dma-mapping updates for 5.8, part 2

 - add DMA mapping helpers for struct sg_table (Marek Szyprowski)


Marek Szyprowski (3):
  dma-mapping: add generic helpers for mapping sgtable objects
  scatterlist: add generic wrappers for iterating over sgtable objects
  iommu: add generic helper for mapping sgtable objects

 include/linux/dma-mapping.h | 80 +
 include/linux/iommu.h   | 16 +
 include/linux/scatterlist.h | 50 ++--
 3 files changed, 143 insertions(+), 3 deletions(-)

[GIT PULL] dma-mapping updates for 5.8, part 1

[Christoph Hellwig]

The following changes since commit ae83d0b416db002fe95601e7f97f64b59514d936:

  Linux 5.7-rc2 (2020-04-19 14:35:30 -0700)

are available in the Git repository at:

  git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.8

for you to fetch changes up to 298f3db6ee690259927b105d5ad1079563361323:

  dma-contiguous: fix comment for dma_release_from_contiguous (2020-04-25 
13:17:06 +0200)


dma-mapping updates for 5.8, part 1

 - enhance the dma pool to allow atomic allocation on x86 with AMD SEV
   (David Rientjes)
 - two small cleanups (Jason Yan and Peter Collingbourne)


David Rientjes (7):
  dma-remap: separate DMA atomic pools from direct remap code
  dma-pool: add additional coherent pools to map to gfp mask
  dma-pool: dynamically expanding atomic pools
  dma-direct: atomic allocations must come from atomic coherent pools
  dma-pool: add pool sizes to debugfs
  x86/mm: unencrypted non-blocking DMA allocations use coherent pools
  dma-pool: scale the default DMA coherent pool size with memory capacity

Jason Yan (1):
  dma-debug: make __dma_entry_alloc_check_leak() static

Peter Collingbourne (1):
  dma-contiguous: fix comment for dma_release_from_contiguous

 arch/x86/Kconfig|   1 +
 drivers/iommu/dma-iommu.c   |   5 +-
 include/linux/dma-direct.h  |   2 +
 include/linux/dma-mapping.h |   6 +-
 kernel/dma/Kconfig  |   6 +-
 kernel/dma/Makefile |   1 +
 kernel/dma/contiguous.c |   4 +-
 kernel/dma/debug.c  |   2 +-
 kernel/dma/direct.c |  56 --
 kernel/dma/pool.c   | 264 
 kernel/dma/remap.c  | 121 +---
 11 files changed, 327 insertions(+), 141 deletions(-)
 create mode 100644 kernel/dma/pool.c

Re: [PATCH v2 6/6] iio: remove left-over parent assignments

[Jonathan Cameron]

On Wed, 3 Jun 2020 14:40:23 +0300
Alexandru Ardelean  wrote:

> These were found by doing some shell magic:
> 
> for file in $(git grep -w devm_iio_device_alloc | cut -d: -f1 | sort | uniq) 
> ; do
>   if grep 'parent =' $file | grep -v trig | grep -vq devm_; then
>   echo "$file -> $(grep "parent =" $file)"
>   fi
> done
> ---
> 
> The output is bearable [after the semantic patch is applied].
> There is a mix of trigger assignments with some iio device parent
> assignments that are removed via this patch.
> 
> Signed-off-by: Alexandru Ardelean 

I added a bunch more via a grep of simple parent\ = 
and eyeballing it.  Much easier to do after your patches as far
fewer entries.

vcnl3020 (new)
ms5611 (hidden via an extra call)
st_sensors_spi (hidden via an extra call)
st_sensors_i2c (hidden via an extra call)
cros_ec_sensors_core (hidden via an extra call)
> ---
>  drivers/iio/accel/kxcjk-1013.c| 1 -
>  drivers/iio/accel/mma8452.c   | 1 -
>  drivers/iio/accel/mma9553.c   | 1 -
>  drivers/iio/adc/ad7192.c  | 1 -
>  drivers/iio/adc/hx711.c   | 1 -
>  drivers/iio/adc/max1363.c | 2 --
>  drivers/iio/adc/mcp3911.c | 1 -
>  drivers/iio/adc/qcom-spmi-iadc.c  | 1 -
>  drivers/iio/amplifiers/ad8366.c   | 1 -
>  drivers/iio/chemical/vz89x.c  | 1 -
>  drivers/iio/dac/ad5770r.c | 1 -
>  drivers/iio/health/afe4403.c  | 1 -
>  drivers/iio/health/afe4404.c  | 1 -
>  drivers/iio/humidity/dht11.c  | 1 -
>  drivers/iio/humidity/hts221_core.c| 1 -
>  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c| 1 -
>  drivers/iio/light/cm3605.c| 1 -
>  drivers/iio/light/ltr501.c| 1 -
>  drivers/iio/magnetometer/ak8975.c | 1 -
>  drivers/iio/orientation/hid-sensor-rotation.c | 1 -
>  drivers/iio/potentiostat/lmp91000.c   | 1 -
>  drivers/iio/proximity/ping.c  | 1 -
>  drivers/iio/proximity/pulsedlight-lidar-lite-v2.c | 1 -
>  drivers/iio/proximity/srf04.c | 1 -
>  drivers/iio/proximity/srf08.c | 1 -
>  drivers/iio/temperature/tsys01.c  | 1 -
>  drivers/staging/iio/addac/adt7316.c   | 1 -
>  27 files changed, 28 deletions(-)
> 
> diff --git a/drivers/iio/accel/kxcjk-1013.c b/drivers/iio/accel/kxcjk-1013.c
> index c9924a65c32a..6b93521c0e17 100644
> --- a/drivers/iio/accel/kxcjk-1013.c
> +++ b/drivers/iio/accel/kxcjk-1013.c
> @@ -1311,7 +1311,6 @@ static int kxcjk1013_probe(struct i2c_client *client,
>  
>   mutex_init(&data->mutex);
>  
> - indio_dev->dev.parent = &client->dev;
>   indio_dev->channels = kxcjk1013_channels;
>   indio_dev->num_channels = ARRAY_SIZE(kxcjk1013_channels);
>   indio_dev->available_scan_masks = kxcjk1013_scan_masks;
> diff --git a/drivers/iio/accel/mma8452.c b/drivers/iio/accel/mma8452.c
> index 00e100fc845a..ef3df402fc3c 100644
> --- a/drivers/iio/accel/mma8452.c
> +++ b/drivers/iio/accel/mma8452.c
> @@ -1592,7 +1592,6 @@ static int mma8452_probe(struct i2c_client *client,
>   i2c_set_clientdata(client, indio_dev);
>   indio_dev->info = &mma8452_info;
>   indio_dev->name = id->name;
> - indio_dev->dev.parent = &client->dev;
>   indio_dev->modes = INDIO_DIRECT_MODE;
>   indio_dev->channels = data->chip_info->channels;
>   indio_dev->num_channels = data->chip_info->num_channels;
> diff --git a/drivers/iio/accel/mma9553.c b/drivers/iio/accel/mma9553.c
> index 312070dcf035..c15908faa381 100644
> --- a/drivers/iio/accel/mma9553.c
> +++ b/drivers/iio/accel/mma9553.c
> @@ -1103,7 +1103,6 @@ static int mma9553_probe(struct i2c_client *client,
>   if (ret < 0)
>   return ret;
>  
> - indio_dev->dev.parent = &client->dev;
>   indio_dev->channels = mma9553_channels;
>   indio_dev->num_channels = ARRAY_SIZE(mma9553_channels);
>   indio_dev->name = name;
> diff --git a/drivers/iio/adc/ad7192.c b/drivers/iio/adc/ad7192.c
> index 08ba1a8f05eb..a0837d7e9176 100644
> --- a/drivers/iio/adc/ad7192.c
> +++ b/drivers/iio/adc/ad7192.c
> @@ -970,7 +970,6 @@ static int ad7192_probe(struct spi_device *spi)
>  
>   spi_set_drvdata(spi, indio_dev);
>   st->chip_info = of_device_get_match_data(&spi->dev);
> - indio_dev->dev.parent = &spi->dev;
>   indio_dev->name = st->chip_info->name;
>   indio_dev->modes = INDIO_DIRECT_MODE;
>  
> diff --git a/drivers/iio/adc/hx711.c b/drivers/iio/adc/hx711.c
> index c8686558429b..6a173531d355 100644
> --- a/drivers/iio/adc/hx711.c
> +++ b/drivers/iio/adc/hx711.c
> @@ -551,7 +551,6 @@ static int hx711_probe(struct platform_device *pdev)
>   platform_set_drvdata(pdev, indio_dev);
>  
>   indi