Re: Re: [PATCH] drm/panfrost: fix runtime pm imbalance on error

[dinghao . liu]

Hi Steve,

There are two bailing out points in panfrost_job_hw_submit(): one is 
the error path beginning from pm_runtime_get_sync(), the other one is 
the error path beginning from WARN_ON() in the if statement. The pm 
imbalance fixed in this patch is between these two paths. I think the 
caller of panfrost_job_hw_submit() cannot distinguish this imbalance 
outside this function. 

panfrost_job_timedout() calls pm_runtime_put_noidle() for every job it 
finds, but all jobs are added to the pfdev->jobs just before calling
panfrost_job_hw_submit(). Therefore I think the imbalance still exists.
But I'm not very sure if we should add pm_runtime_put on the error path
after pm_runtime_get_sync(), or remove pm_runtime_put one the error path
after WARN_ON(). 

As for the problem about panfrost_devfreq_record_busy(), this may be a 
new bug and requires independent patch to fix it.

Regards,
Dinghao


> On 20/05/2020 12:05, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > the call returns an error code. Thus a pairing decrement is needed
> > on the error handling path to keep the counter balanced.
> > 
> > Signed-off-by: Dinghao Liu 
> 
> Actually I think we have the opposite problem. To be honest we don't 
> handle this situation very well. By the time panfrost_job_hw_submit() is 
> called the job has already been added to the pfdev->jobs array, so it's 
> considered submitted even if it never actually lands on the hardware. So 
> in the case of this function bailing out early we will then (eventually) 
> hit a timeout and trigger a GPU reset.
> 
> panfrost_job_timedout() iterates through the pfdev->jobs array and calls 
> pm_runtime_put_noidle() for each job it finds. So there's no inbalance 
> here that I can see.
> 
> Have you actually observed the situation where pm_runtime_get_sync() 
> returns a failure?
> 
> HOWEVER, it appears that by bailing out early the call to 
> panfrost_devfreq_record_busy() is never made, which as far as I can see 
> means that there may be an extra call to panfrost_devfreq_record_idle() 
> when the jobs have timed out. Which could underflow the counter.
> 
> But equally looking at panfrost_job_timedout(), we only call 
> panfrost_devfreq_record_idle() *once* even though multiple jobs might be 
> processed.
> 
> There's a completely untested patch below which in theory should fix that...
> 
> Steve
> 
> 8<---
> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c 
> b/drivers/gpu/drm/panfrost/panfrost_job.c
> index 7914b1570841..f9519afca29d 100644
> --- a/drivers/gpu/drm/panfrost/panfrost_job.c
> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c
> @@ -145,6 +145,8 @@ static void panfrost_job_hw_submit(struct 
> panfrost_job *job, int js)
>   u64 jc_head = job->jc;
>   int ret;
> 
> + panfrost_devfreq_record_busy(pfdev);
> +
>   ret = pm_runtime_get_sync(pfdev->dev);
>   if (ret < 0)
>   return;
> @@ -155,7 +157,6 @@ static void panfrost_job_hw_submit(struct 
> panfrost_job *job, int js)
>   }
> 
>   cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu);
> - panfrost_devfreq_record_busy(pfdev);
> 
>   job_write(pfdev, JS_HEAD_NEXT_LO(js), jc_head & 0x);
>   job_write(pfdev, JS_HEAD_NEXT_HI(js), jc_head >> 32);
> @@ -410,12 +411,12 @@ static void panfrost_job_timedout(struct 
> drm_sched_job *sched_job)
>   for (i = 0; i < NUM_JOB_SLOTS; i++) {
>   if (pfdev->jobs[i]) {
>   pm_runtime_put_noidle(pfdev->dev);
> + panfrost_devfreq_record_idle(pfdev);
>   pfdev->jobs[i] = NULL;
>   }
>   }
>   spin_unlock_irqrestore(&pfdev->js->job_lock, flags);
> 
> - panfrost_devfreq_record_idle(pfdev);
>   panfrost_device_reset(pfdev);
> 
>   for (i = 0; i < NUM_JOB_SLOTS; i++)

[PATCH 4/4] habanalabs: don't allow hard reset with open processes

[Oded Gabbay]

From: Omer Shpigelman 

When the MMU is heavily used by the engines, unmapping might take a lot of
time due to a full MMU cache invalidation done as part of the unmap flow.
Hence we might not be able to kill all open processes before going to hard
reset the device, as it involves unmapping of all user memory.
In case of a failure in killing all open processes, we should stop the
hard reset flow as it might lead to a kernel crash - one thread (killing
of a process) is updating MMU structures that other thread (hard reset) is
freeing.
Stopping a hard reset flow leaves the device as nonoperational and the
user can then initiate a hard reset via sysfs to reinitialize the device.

Signed-off-by: Omer Shpigelman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/device.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c
index 4a4a446f479e..2b38a119704c 100644
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -726,7 +726,7 @@ int hl_device_resume(struct hl_device *hdev)
return rc;
 }
 
-static void device_kill_open_processes(struct hl_device *hdev)
+static int device_kill_open_processes(struct hl_device *hdev)
 {
u16 pending_total, pending_cnt;
struct hl_fpriv *hpriv;
@@ -779,9 +779,7 @@ static void device_kill_open_processes(struct hl_device 
*hdev)
ssleep(1);
}
 
-   if (!list_empty(&hdev->fpriv_list))
-   dev_crit(hdev->dev,
-   "Going to hard reset with open user contexts\n");
+   return list_empty(&hdev->fpriv_list) ? 0 : -EBUSY;
 }
 
 static void device_hard_reset_pending(struct work_struct *work)
@@ -908,7 +906,12 @@ int hl_device_reset(struct hl_device *hdev, bool 
hard_reset,
 * process can't really exit until all its CSs are done, which
 * is what we do in cs rollback
 */
-   device_kill_open_processes(hdev);
+   rc = device_kill_open_processes(hdev);
+   if (rc) {
+   dev_crit(hdev->dev,
+   "Failed to kill all open processes, stopping 
hard reset\n");
+   goto out_err;
+   }
 
/* Flush the Event queue workers to make sure no other thread is
 * reading or writing to registers during the reset
@@ -1391,7 +1394,9 @@ void hl_device_fini(struct hl_device *hdev)
 * can't really exit until all its CSs are done, which is what we
 * do in cs rollback
 */
-   device_kill_open_processes(hdev);
+   rc = device_kill_open_processes(hdev);
+   if (rc)
+   dev_crit(hdev->dev, "Failed to kill all open processes\n");
 
hl_cb_pool_fini(hdev);
 
-- 
2.17.1

[PATCH 3/4] habanalabs: GAUDI does not support soft-reset

[Oded Gabbay]

GAUDI does not support soft-reset as it leaves the NIC ports in an awkward
state, where their QMANs were reset but the NIC itself is still working.

In addition, there is not much sense in doing soft-reset when training is
done on multiple GAUDIs.

Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/device.c  |  6 +
 drivers/misc/habanalabs/gaudi/gaudi.c | 38 +++
 drivers/misc/habanalabs/goya/goya.c   |  1 +
 drivers/misc/habanalabs/habanalabs.h  |  2 ++
 drivers/misc/habanalabs/sysfs.c   |  5 
 5 files changed, 35 insertions(+), 17 deletions(-)

diff --git a/drivers/misc/habanalabs/device.c b/drivers/misc/habanalabs/device.c
index 4b6c8de46dd8..4a4a446f479e 100644
--- a/drivers/misc/habanalabs/device.c
+++ b/drivers/misc/habanalabs/device.c
@@ -801,6 +801,7 @@ static void device_hard_reset_pending(struct work_struct 
*work)
  * @hdev: pointer to habanalabs device structure
  * @hard_reset: should we do hard reset to all engines or just reset the
  *  compute/dma engines
+ * @from_hard_reset_thread: is the caller the hard-reset thread
  *
  * Block future CS and wait for pending CS to be enqueued
  * Call ASIC H/W fini
@@ -823,6 +824,11 @@ int hl_device_reset(struct hl_device *hdev, bool 
hard_reset,
return 0;
}
 
+   if ((!hard_reset) && (!hdev->supports_soft_reset)) {
+   dev_dbg(hdev->dev, "Doing hard-reset instead of soft-reset\n");
+   hard_reset = true;
+   }
+
/*
 * Prevent concurrency in this function - only one reset should be
 * done at any given time. Only need to perform this if we didn't
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c 
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 3d4a569914d3..92a5130f06fb 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -5774,7 +5774,7 @@ static void gaudi_handle_eqe(struct hl_device *hdev,
u16 event_type = ((ctl & EQ_CTL_EVENT_TYPE_MASK)
>> EQ_CTL_EVENT_TYPE_SHIFT);
u8 cause;
-   bool soft_reset_required;
+   bool reset_required;
 
gaudi->events_stat[event_type]++;
gaudi->events_stat_aggregate[event_type]++;
@@ -5840,16 +5840,18 @@ static void gaudi_handle_eqe(struct hl_device *hdev,
case GAUDI_EVENT_TPC6_DEC:
case GAUDI_EVENT_TPC7_DEC:
gaudi_print_irq_info(hdev, event_type, true);
-   soft_reset_required = gaudi_tpc_read_interrupts(hdev,
+   reset_required = gaudi_tpc_read_interrupts(hdev,
tpc_dec_event_to_tpc_id(event_type),
"AXI_SLV_DEC_Error");
-   if (soft_reset_required) {
-   dev_err_ratelimited(hdev->dev,
-   "soft reset required due to %s\n",
-   gaudi_irq_map_table[event_type].name);
-   hl_device_reset(hdev, false, false);
+   if (reset_required) {
+   dev_err(hdev->dev, "hard reset required due to %s\n",
+   gaudi_irq_map_table[event_type].name);
+
+   if (hdev->hard_reset_on_fw_events)
+   hl_device_reset(hdev, true, false);
+   } else {
+   hl_fw_unmask_irq(hdev, event_type);
}
-   hl_fw_unmask_irq(hdev, event_type);
break;
 
case GAUDI_EVENT_TPC0_KRN_ERR:
@@ -5861,16 +5863,18 @@ static void gaudi_handle_eqe(struct hl_device *hdev,
case GAUDI_EVENT_TPC6_KRN_ERR:
case GAUDI_EVENT_TPC7_KRN_ERR:
gaudi_print_irq_info(hdev, event_type, true);
-   soft_reset_required = gaudi_tpc_read_interrupts(hdev,
+   reset_required = gaudi_tpc_read_interrupts(hdev,
tpc_krn_event_to_tpc_id(event_type),
"KRN_ERR");
-   if (soft_reset_required) {
-   dev_err_ratelimited(hdev->dev,
-   "soft reset required due to %s\n",
-   gaudi_irq_map_table[event_type].name);
-   hl_device_reset(hdev, false, false);
+   if (reset_required) {
+   dev_err(hdev->dev, "hard reset required due to %s\n",
+   gaudi_irq_map_table[event_type].name);
+
+   if (hdev->hard_reset_on_fw_events)
+   hl_device_reset(hdev, true, false);
+   } else {
+   hl_fw_unmask_irq(hdev, event_type);
}
-   hl_fw_unmask_irq(hdev, event_type);
break;
 
case GAUDI_EVENT_PCIE_CORE_SERR:
@@ -5921,8 +5925,8 @@ static void gaudi_handle_eqe(struct hl_device *hdev,
 
case GA

[PATCH 2/4] habanalabs: add print for soft reset due to event

[Oded Gabbay]

From: Omer Shpigelman 

Print the event name that caused the soft reset.

Signed-off-by: Omer Shpigelman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/gaudi/gaudi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c 
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 093384731f0d..3d4a569914d3 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -5843,8 +5843,12 @@ static void gaudi_handle_eqe(struct hl_device *hdev,
soft_reset_required = gaudi_tpc_read_interrupts(hdev,
tpc_dec_event_to_tpc_id(event_type),
"AXI_SLV_DEC_Error");
-   if (soft_reset_required)
+   if (soft_reset_required) {
+   dev_err_ratelimited(hdev->dev,
+   "soft reset required due to %s\n",
+   gaudi_irq_map_table[event_type].name);
hl_device_reset(hdev, false, false);
+   }
hl_fw_unmask_irq(hdev, event_type);
break;
 
@@ -5860,8 +5864,12 @@ static void gaudi_handle_eqe(struct hl_device *hdev,
soft_reset_required = gaudi_tpc_read_interrupts(hdev,
tpc_krn_event_to_tpc_id(event_type),
"KRN_ERR");
-   if (soft_reset_required)
+   if (soft_reset_required) {
+   dev_err_ratelimited(hdev->dev,
+   "soft reset required due to %s\n",
+   gaudi_irq_map_table[event_type].name);
hl_device_reset(hdev, false, false);
+   }
hl_fw_unmask_irq(hdev, event_type);
break;
 
-- 
2.17.1

[PATCH 1/4] habanalabs: improve MMU cache invalidation code

[Oded Gabbay]

From: Omer Shpigelman 

A new sequence is introduced to invalidate the MMU cache in order to avoid
timeouts.

Signed-off-by: Omer Shpigelman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/gaudi/gaudi.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c 
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 4cb1f71dd4f1..093384731f0d 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -5982,16 +5982,18 @@ static void gaudi_mmu_invalidate_cache(struct hl_device 
*hdev, bool is_hard,
timeout_usec = MMU_CONFIG_TIMEOUT_USEC;
 
/* L0 & L1 invalidation */
-   WREG32(mmSTLB_INV_ALL_START, 1);
+   WREG32(mmSTLB_INV_PS, 2);
 
rc = hl_poll_timeout(
hdev,
-   mmSTLB_INV_ALL_START,
+   mmSTLB_INV_PS,
status,
!status,
1000,
timeout_usec);
 
+   WREG32(mmSTLB_INV_SET, 0);
+
if (rc)
dev_notice_ratelimited(hdev->dev,
"Timeout when waiting for MMU cache invalidation\n");
-- 
2.17.1

[PATCH] i2c: stm32f7: Fix runtime PM imbalance in stm32f7_i2c_reg_slave

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/i2c/busses/i2c-stm32f7.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 330ffed011e0..602cf35649c8 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1767,8 +1767,10 @@ static int stm32f7_i2c_reg_slave(struct i2c_client 
*slave)
return ret;
 
ret = pm_runtime_get_sync(dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_autosuspend(dev);
return ret;
+   }
 
if (!stm32f7_i2c_is_slave_registered(i2c_dev))
stm32f7_i2c_enable_wakeup(i2c_dev, true);
-- 
2.17.1

Re: [PATCH v4 7/7] firmware: smccc: Add ARCH_SOC_ID support

[Sudeep Holla]

On Wed, May 20, 2020 at 11:51:47PM +0200, Arnd Bergmann wrote:
> On Mon, May 18, 2020 at 1:55 PM Sudeep Holla  wrote:
> >
> > On Mon, May 18, 2020 at 11:30:21AM +0200, Arnd Bergmann wrote:
> > > On Mon, May 18, 2020 at 11:12 AM Sudeep Holla  
> > > wrote:
> > >
> > > > +static ssize_t
> > > > +jep106_cont_bank_code_show(struct device *dev, struct device_attribute 
> > > > *attr,
> > > > +  char *buf)
> > > > +{
> > > > +   return sprintf(buf, "0x%02x\n", 
> > > > JEP106_BANK_CONT_CODE(soc_id_version));
> > > > +}
> > > > +
> > > > +static DEVICE_ATTR_RO(jep106_cont_bank_code);
> > > > +
> > > > +static ssize_t
> > > > +jep106_identification_code_show(struct device *dev,
> > > > +   struct device_attribute *attr, char 
> > > > *buf)
> > > > +{
> > > > +   return sprintf(buf, "0x%02x\n", JEP106_ID_CODE(soc_id_version));
> > > > +}
> > >
> > > I think we should try hard to avoid nonstandard attributes for the soc 
> > > device.
> > >
> >
> > I agree with that in general but this is bit different for below mentioned
> > reason.
> >
> > > Did you run into a problem with finding one of the existing attributes
> > > that can be used to hold the fields?
> > >
> >
> > Not really! The 2 JEP106 codes can be used to derive the manufacturer which
> > could match one of the existing attributes. However doing so might require
> > importing the huge JEP106 list as it needs to be maintained and updated
> > in the kernel. Also that approach will have the compatibility issue and
> > that is the reason for introducing these attributes representing raw
> > values for userspace.
>
> I was thinking they codes could just be part of the normal strings rather
> than get translated. Can you give an example what they would look like
> with your current code?
>

Sure. Couple of example:
Cont Code   Identifier   Manufacturer
0   0x1 AMD
0   0x0eFreescale (Motorola)
4   0x3bARM

I initially thought of value like "jep106-0-1" for AMD "jep-4-3b" for
ARM,..etc for the standard attribute family or machine. But I was not
convinced fully on that approach as it will be deviation from normal
values in those attributes. Further this represents the vendor name
rather than the family or machine.

> If  you think they should be standard attributes, how about adding them
> to the default list, and hardcoding them in the other soc device drivers
> based on the information we have available there?
>

That may be possible, I can take a look at the existing drivers and
check if that is feasible(which I think should be). Thanks for that
suggestion.

--
Regards,
Sudeep

[1] https://github.com/skottler/memtest86/blob/master/jedec_id.h

Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support

[Sudeep Holla]

On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote:
> On Wed, May 20, 2020 at 11:29 PM Will Deacon  wrote:
> >
> > On Mon, 18 May 2020 10:12:15 +0100, Sudeep Holla wrote:
> > > This patch series adds support for SMCCCv1.2 ARCH_SOC_ID.
> > > This doesn't add other changes added in SMCCC v1.2 yet. They will
> > > follow these soon along with its first user SPCI/PSA-FF.
> > >
> > > This is tested using upstream TF-A + the patch[3] fixing the original
> > > implementation there.
> > >
> > > [...]
> >
> > Applied to arm64 (for-next/smccc), thanks!
> >
> > [1/7] firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC v1.1 
> > and above
> >   https://git.kernel.org/arm64/c/e5bfb21d98b6
> > [2/7] firmware: smccc: Update link to latest SMCCC specification
> >   https://git.kernel.org/arm64/c/15c704ab6244
> > [3/7] firmware: smccc: Add the definition for SMCCCv1.2 version/error codes
> >   https://git.kernel.org/arm64/c/0441bfe7f00a
> > [4/7] firmware: smccc: Drop smccc_version enum and use 
> > ARM_SMCCC_VERSION_1_x instead
> >   https://git.kernel.org/arm64/c/ad5a57dfe434
> > [5/7] firmware: smccc: Refactor SMCCC specific bits into separate file
> >   https://git.kernel.org/arm64/c/f2ae97062a48
> > [6/7] firmware: smccc: Add function to fetch SMCCC version
> >   https://git.kernel.org/arm64/c/a4fb17465182
> > [7/7] firmware: smccc: Add ARCH_SOC_ID support
> >   https://git.kernel.org/arm64/c/ce6488f0ce09
> >
> > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable to 
> > me,
> > but please shout if you'd rather I dropped this in order to pursue an
> > alternative approach.
>
> I missed the reply earlier, thanks for pointing me to it again.
>
> I'm not entirely convinced, but don't revert it for now because of that,
> I assume we can find a solution.
>

I liked your idea of making this generic and hardcode values if required
for other drivers. I will take a look at that/

> However, please have a look at the build failure report for patch 5
> and fix it if you can see what went wrong.
>

Any pointers for that failure ? I seem to have missed them. I pushed
branch couple of times to my tree but got build success both times.
Any specific config or compilers ?

--
Regards,
Sudeep

[PATCH] i2c: stm32f7: Fix runtime PM imbalance in stm32f7_i2c_unreg_slave

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/i2c/busses/i2c-stm32f7.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 330ffed011e0..6f5f0fa68385 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -1837,8 +1837,10 @@ static int stm32f7_i2c_unreg_slave(struct i2c_client 
*slave)
WARN_ON(!i2c_dev->slave[id]);
 
ret = pm_runtime_get_sync(i2c_dev->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_autosuspend(i2c_dev->dev);
return ret;
+   }
 
if (id == 0) {
mask = STM32F7_I2C_OAR1_OA1EN;
-- 
2.17.1

Re: [patch V6 10/37] x86/entry: Switch XEN/PV hypercall entry to IDTENTRY

[Thomas Gleixner]

Boris Ostrovsky  writes:

> On 5/20/20 3:16 PM, Thomas Gleixner wrote:
>
>
>> +__visible noinstr void xen_pv_evtchn_do_upcall(struct pt_regs *regs)
>> +{
>> +struct pt_regs *old_regs;
>> +bool inhcall;
>> +
>> +idtentry_enter(regs);
>> +old_regs = set_irq_regs(regs);
>> +
>> +run_on_irqstack(__xen_pv_evtchn_do_upcall, NULL, regs);
>
>
> We need to handle nested case (i.e. !irq_needs_irq_stack(), like in your
> original version). Moving get_and_clear_inhcall() up should prevent
> scheduling when this happens.

I locally changed run_on_irqstack() to do the magic checks and select the
right one.

Thanks,

tglx

[RFC PATCH linux-next] drm/msm/dpu: dpu_setup_dspp_pcc() can be static

[kbuild test robot]

Fixes: 4259ff7ae509 ("drm/msm/dpu: add support for pcc color block in dpu 
driver")
Signed-off-by: kbuild test robot 
---
 dpu_hw_dspp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
index b5189cece3c66..a7a24539921f3 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c
@@ -22,7 +22,7 @@
 #define PCC_BLUE_G_OFF 0x24
 #define PCC_BLUE_B_OFF 0x30
 
-void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
+static void dpu_setup_dspp_pcc(struct dpu_hw_dspp *ctx,
struct dpu_hw_pcc_cfg *cfg)
 {
 

Re: [PATCH v13 00/11] Convert PWM period and duty cycle to u64

[Lee Jones]

On Wed, 20 May 2020, Guru Das Srinagesh wrote:

> On Mon, Apr 27, 2020 at 07:44:34AM +0100, Lee Jones wrote:
> > On Fri, 24 Apr 2020, Guru Das Srinagesh wrote:
> > 
> > > On Fri, Apr 24, 2020 at 07:43:03AM +0100, Lee Jones wrote:
> > > > A great deal of mailing lists contain numerous protections against
> > > > things like flooding and spamming.  One of those protections is a
> > > > check for "Too many recipients to the message".  Most of the time this
> > > > simply requires moderator intervention by way of review and approval,
> > > > but this ultimately depends on the ML's configuration.
> > > > 
> > > > The first thing to ascertain is why your recipients list is so large.
> > > > Have you added every reviewer, subsystem-maintainer, maintainer and
> > > > contributor suggested by get-maintainer.pl?  If so, consider pruning
> > > > that a little.  Contributors do not tend to care about subsequent
> > > > changes to a file.  As someone who receives a lot of patches, I tend
> > > > to get fed-up when receiving patches simply because I made a change X
> > > > years ago.  Stick to listed maintainers/reviewers in the first
> > > > instance and see how far that takes you.
> > > 
> > > Thank you for the detailed reply. I did this in the first few patchsets
> > > and then when a few patches didn't get any attention, expanded the
> > > audience thus. Still, around 50% of the patches in this series remain
> > > unreviewed by anyone.
> > 
> > This isn't a reason to add more recipients (who are likely to care
> > even less than your original group).  However it *is* a good argument
> > for including all of the specified maintainers/reviewers in on all of
> > the patches.
> > 
> > > > If your recipients list is as succinct as reasonably possible, maybe
> > > > just accept that every version isn't going to be archived by every
> > > > ML.  It's still much more useful for the correct people to have
> > > > visibility into the set than for it to be archived multiple times.
> > > 
> > > Thank you, will prune the list and remove past contributors from the
> > > Cc-list and add all parties to all patches.
> > 
> > Great.  Once you've done that, we can start to help you acquire the
> > Acks you need on your remaining patches.
> 
> Hi Lee, Thierry, Uwe,
> 
> In v14 of this patchset I've pruned the list of contributors, removed
> past contributors from the cc-list, and added all parties to all patches
> (except for the patches that are yet to reviewed, for which I've added
> what get_maintainer.pl showed me). I've also resent v14 a couple of
> times already, with around a week's time interval between resends, and
> somehow it seems like this set has lost traction.
> 
> Could you please indicate what next steps I should take to have more
> eyes on the unreviewed patches? Only 4 out of 11 patches remain
> unreviewed.

Looks like we're waiting on Thierry (again).

This has been a common theme over the past few months.

Perhaps he has changed employer/project?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v3 08/14] mips: MAAR: Use more precise address mask

[Thomas Bogendoerfer]

On Thu, May 21, 2020 at 03:34:37AM +0300, Serge Semin wrote:
> Indeed according to the MIPS32 Privileged Resource Architecgture the MAAR
> pair register address field either takes [12:31] bits for non-XPA systems
> and [12:55] otherwise. In any case the current address mask is just
> wrong for 64-bit and 32-bits XPA chips. So lets extend it to 59-bits
> of physical address value. This shall cover the 64-bits architecture and
> systems with XPA enabled, and won't cause any problem for non-XPA 32-bit
> systems, since address values exceeding the architecture specific MAAR
> mask will be just truncated with setting zeros in the unsupported upper
> bits.
> 
> Co-developed-by: Alexey Malahov 
> Signed-off-by: Alexey Malahov 
> Signed-off-by: Serge Semin 
> Cc: Thomas Bogendoerfer 
> Cc: Paul Burton 
> Cc: Ralf Baechle 
> Cc: Arnd Bergmann 
> Cc: Rob Herring 
> Cc: devicet...@vger.kernel.org
> 
> ---
> 
> Changelog v3:
> - In accordance with MIPS32/64 Privileged Resource Architecture Extend
>   the MAAR Addr mask to value [12:55] instead of P5600-specific [12:35].
> ---
>  arch/mips/include/asm/mipsregs.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

applied to mips-next.

Thomas.

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

Re: [PATCH v3 00/14] mips: Prepare MIPS-arch code for Baikal-T1 SoC support

[Thomas Bogendoerfer]

On Thu, May 21, 2020 at 03:42:17AM +0300, Serge Semin wrote:
> On Thu, May 21, 2020 at 03:34:29AM +0300, Serge Semin wrote:
> >
> > This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
> > base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
> > tag: v5.7-rc4
> 
> Thomas,
> Please note that this patchset is based on the Linux 5.7-rc4 tree (it most 
> likely
> will get cleanly applied on rc6 as well), while mips-next is still at rc1. Due
> to that the patchset fails to be applied on mips-next. I think it would be
> better first to merge the last Linux tree into the mips-next, then try to 
> merge
> this patchset in. Should you have any problem after that, please let me know.
> I'll resend the patchset being rebased on top of the new mips-next tree.

no, that's not how it works. Please rebase your patches on top of
mips-next. Thank you.

Thomas.

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

Re: [PATCH] MIPS: SGI-IP27: Remove not used definition TICK_SIZE in ip27-timer.c

[Thomas Bogendoerfer]

On Wed, May 20, 2020 at 03:08:02PM +0800, Tiezhu Yang wrote:
> After commit f5ff0a280201 ("[MIPS] Use generic NTP code for all MIPS
> platforms"), TICK_SIZE is not used in ip27-timer.c for many years,
> remove it.
> 
> Signed-off-by: Tiezhu Yang 
> ---
> 
> Hi Thomas,
> 
> I find this not used definition TICK_SIZE just now, maybe I should send
> these cleanup patches in a patch series, sorry for that if it is noisy.

no problem:-)

>  arch/mips/sgi-ip27/ip27-timer.c | 2 --
>  1 file changed, 2 deletions(-)

applied to mips-next.

Thomas.

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

RE: [PATCH] e1000e: Disable TSO for buffer overrun workaround

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org  On
> Behalf Of Kai-Heng Feng
> Sent: Thursday, May 7, 2020 7:21 AM
> To: Kirsher, Jeffrey T 
> Cc: Kai-Heng Feng ; David S. Miller
> ; Neftin, Sasha ; Dima
> Ruinskiy ; Avargil, Raanan
> ; moderated list:INTEL ETHERNET DRIVERS  wired-...@lists.osuosl.org>; open list:NETWORKING DRIVERS
> ; open list 
> Subject: [PATCH] e1000e: Disable TSO for buffer overrun workaround
> 
> Commit b10effb92e27 ("e1000e: fix buffer overrun while the I219 is
> processing DMA transactions") imposes roughly 30% performance penalty.
> 
> The commit log states that "Disabling TSO eliminates performance loss
> for TCP traffic without a noticeable impact on CPU performance", so
> let's disable TSO by default to regain the loss.
> 
> Fixes: b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing
> DMA transactions")
> BugLink: https://bugs.launchpad.net/bugs/1802691
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/net/ethernet/intel/e1000e/netdev.c | 4 
>  1 file changed, 4 insertions(+)
Tested-by: Aaron Brown 

Re: [PATCH] mm, memcg: reclaim more aggressively before high allocator throttling

[Michal Hocko]

On Wed 20-05-20 21:26:50, Chris Down wrote:
> Michal Hocko writes:
> > Let me try to understand the actual problem. The high memory reclaim has
> > a target which is proportional to the amount of charged memory. For most
> > requests that would be SWAP_CLUSTER_MAX though (resp. N times that where
> > N is the number of memcgs in excess up the hierarchy). I can see to be
> > insufficient if the memcg is already in a large excess but if the
> > reclaim can make a forward progress this should just work fine because
> > each charging context should reclaim at least the contributed amount.
> > 
> > Do you have any insight on why this doesn't work in your situation?
> > Especially with such a large inactive file list I would be really
> > surprised if the reclaim was not able to make a forward progress.
> 
> Reclaim can fail for any number of reasons, which is why we have retries
> sprinkled all over for it already. It doesn't seem hard to believe that it
> might just fail for transient reasons and drive us deeper into the hole as a
> result.

Reclaim can certainly fail. It is however surprising to see it fail with
such a large inactive lru list and reasonably small reclaim target.
Having the full LRU of dirty pages sounds a bit unusual, IO throttling
for v2 and explicit throttling during the reclaim for v1 should prevent
from that. If the reclaim gives up too easily then this should be
addressed at the reclaim level.

> In this case, a.) the application is producing tons of dirty pages, and b.)
> we have really heavy systemwide I/O contention on the affected machines.
> This high load is one of the reasons that direct and kswapd reclaim cannot
> keep up, and thus nr_pages can become a number of orders of magnitude larger
> than SWAP_CLUSTER_MAX. This is trivially reproducible on these machines,
> it's not an edge case.

Please elaborate some more. memcg_nr_pages_over_high shouldn't really
depend on the system wide activity. It should scale with the requested
charges. So yes it can get large for something like a large read/write
which does a lot of allocations in a single syscall before returning to
the userspace.
 
But ok, let's say that the reclaim target is large and then a single
reclaim attempt might fail. Then I am wondering why your patch is not
really targetting to reclaim memcg_nr_pages_over_high pages and instead
push for reclaim down to the high limit.

The main problem I see with that approach is that the loop could easily
lead to reclaim unfairness when a heavy producer which doesn't leave the
kernel (e.g. a large read/write call) can keep a different task doing
all the reclaim work. The loop is effectivelly unbound when there is a
reclaim progress and so the return to the userspace is by no means
proportional to the requested memory/charge.
-- 
Michal Hocko
SUSE Labs

[PATCH v3] kdb: Remove the misfeature 'KDBFLAGS'

[Wei Li]

Currently, 'KDBFLAGS' is an internal variable of kdb, it is combined
by 'KDBDEBUG' and state flags. It will be shown only when 'KDBDEBUG'
is set, and the user can define an environment variable named 'KDBFLAGS'
too. These are puzzling indeed.

After communication with Daniel, it seems that 'KDBFLAGS' is a misfeature.
So let's replace 'KDBFLAGS' with 'KDBDEBUG' to just show the value we
wrote into. After this modification, we can use `md4c1 kdb_flags` instead,
to observe the state flags.

Suggested-by: Daniel Thompson 
Signed-off-by: Wei Li 
---
v2 -> v3:
 - Change to replace the internal env 'KDBFLAGS' with 'KDBDEBUG'.
v1 -> v2:
 - Fix lack of braces.

 kernel/debug/kdb/kdb_main.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/debug/kdb/kdb_main.c b/kernel/debug/kdb/kdb_main.c
index 4fc43fb17127..392029287083 100644
--- a/kernel/debug/kdb/kdb_main.c
+++ b/kernel/debug/kdb/kdb_main.c
@@ -418,8 +418,7 @@ int kdb_set(int argc, const char **argv)
argv[2]);
return 0;
}
-   kdb_flags = (kdb_flags &
-~(KDB_DEBUG_FLAG_MASK << KDB_DEBUG_FLAG_SHIFT))
+   kdb_flags = (kdb_flags & ~KDB_DEBUG(MASK))
| (debugflags << KDB_DEBUG_FLAG_SHIFT);
 
return 0;
@@ -2081,7 +2080,8 @@ static int kdb_env(int argc, const char **argv)
}
 
if (KDB_DEBUG(MASK))
-   kdb_printf("KDBFLAGS=0x%x\n", kdb_flags);
+   kdb_printf("KDBDEBUG=0x%x\n",
+   (kdb_flags & KDB_DEBUG(MASK)) >> KDB_DEBUG_FLAG_SHIFT);
 
return 0;
 }
-- 
2.17.1

linux-next: manual merge of the usb-gadget tree with the usb tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the usb-gadget tree got a conflict in:

  drivers/usb/cdns3/gadget.c

between commit:

  e9010320f2d9 ("usb: cdns3: gadget: make a bunch of functions static")

from the usb tree and commit:

  e2e77a94078b ("usb: cdns3: mark local functions static")

from the usb-gadget tree.

I fixed it up (the difference was the indentation of contiuation lines -
I juts used the latter) and can carry the fix as necessary. This is now
fixed as far as linux-next is concerned, but any non trivial conflicts
should be mentioned to your upstream maintainer when your tree is
submitted for merging.  You may also want to consider cooperating with
the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpA72TQF3J1h.pgp
Description: OpenPGP digital signature

Re: [RFC PATCH] kbuild: add variables for compression tools

[Masahiro Yamada]

On Fri, May 15, 2020 at 6:40 PM Denis Efremov  wrote:
>
> It seems that I missed a couple of tar commands in the patch:
> scripts/Makefile.package
> scripts/package/buildtar
>
> On 5/15/20 5:20 AM, Masahiro Yamada wrote:
> > On Thu, May 14, 2020 at 10:14 PM Denis Efremov  wrote:
> >>
> >
> > commit 5054e88a7934d5ff5ec14231c8b8676161bb45fa
> > Author: Paul Eggert 
> > Date:   Mon Mar 16 14:25:17 2015 -0700
> >
> > gzip: make the GZIP env var obsolescent
>
> Other implementations can depend on this.
> pigz still parses GZIP env var:
> https://github.com/madler/pigz/blob/master/pigz.c#L4346
>
> >
> > Some possible options I came up with:
> >
> >
> > [1] Use KGZIP for now, but BZIP2, XZ, etc. for the others.
> >
> > (Then, rename KGZIP to GZIP when the time comes)
> >
> >
> > [2] Do not take this patch
> >
> > The whole build process is parallelized
> > by 'make -j $(nproc)'.
> >
> > If you are still eager to use pigz instead gzip,
> > use a symbolic link or a wrapper shell script.
> >
> > $ ln -s /usr/bin/pigz  /$HOME/bin/gzip
> > $ PATH="$HOME/bin:$PATH"
> >
>
> [3] GZIP at frontend, KGZIP or _GZIP internally? Something like:
>
> $ cat Makefile
> GZIP=gzip
> override KGZIP=$(GZIP) # optional overrdide. Used to force GZIP value
># in case: make KGZIP=test
>
> unexport GZIP


The command line option is really strong,
so you cannot negate it by 'unexport GZIP'.

override GZIP :=

does not work either in sub-make.





> export KGZIP
>
> default:
> @env | grep GZIP
>
> $ make GZIP=test
> KGZIP=test
>
> Thanks,
> Denis



-- 
Best Regards
Masahiro Yamada

Re: [tip: locking/kcsan] READ_ONCE: Use data_race() to avoid KCSAN instrumentation

[Borislav Petkov]

On Thu, May 21, 2020 at 12:30:39AM +0200, Marco Elver wrote:
> This should be fixed when the series that includes this commit is applied:
> https://lore.kernel.org/lkml/20200515150338.190344-9-el...@google.com/

Yap, that fixes it.

Thx.

-- 
Regards/Gruss,
Boris.

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

RE: [PATCH net-next] igb: make igb_set_fc_watermarks() return void

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org  On
> Behalf Of Jason Yan
> Sent: Thursday, May 7, 2020 4:09 AM
> To: Kirsher, Jeffrey T ; da...@davemloft.net;
> yanai...@huawei.com; intel-wired-...@lists.osuosl.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH net-next] igb: make igb_set_fc_watermarks() return void
> 
> This function always return 0 now, we can make it return void to
> simplify the code. This fixes the following coccicheck warning:
> 
> drivers/net/ethernet/intel/igb/e1000_mac.c:728:5-12: Unneeded variable:
> "ret_val". Return "0" on line 751
> 
> Signed-off-by: Jason Yan 
> ---
>  drivers/net/ethernet/intel/igb/e1000_mac.c | 9 +++--
>  1 file changed, 3 insertions(+), 6 deletions(-)
>
Tested-by: Aaron Brown 

Re: [PATCH v3 2/2] mfd: ene-kb3930: Add driver for ENE KB3930 Embedded Controller

[Lee Jones]

On Wed, 20 May 2020, Lubomir Rintel wrote:

> This driver provides access to the EC RAM of said embedded controller
> attached to the I2C bus as well as optionally supporting its slightly weird
> power-off/restart protocol.
> 
> A particular implementation of the EC firmware can be identified by a
> model byte. If this driver identifies the Dell Ariel platform, it
> registers the appropriate cells.
> 
> Signed-off-by: Lubomir Rintel 
> 
> ---
> Changes since v2:
> - Sort the includes
> - s/EC_MODEL_ID/EC_MODEL/
> - Add a couple of clarifying comments
> - Use #defines for values used in poweroff routine
> - Remove priority from a restart notifier block
> - s/priv/ddata/
> - s/ec_ram/ram_regmap/ for the regmap name
> - Fix the error handling when getting off gpios was not successful
> - Remove a useless dev_info at the end of probe()
> - Use i2c probe_new() callback, drop i2c_device_id
> - Modify the logic in checking the model ID
> 
>  drivers/mfd/Kconfig  |  10 ++
>  drivers/mfd/Makefile |   1 +
>  drivers/mfd/ene-kb3930.c | 215 +++
>  3 files changed, 226 insertions(+)
>  create mode 100644 drivers/mfd/ene-kb3930.c

Really starting to take shape.

Just a couple of nits, then we're good to go.

> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 0a59249198d3..dae18a2beab5 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -398,6 +398,16 @@ config MFD_DLN2
> etc. must be enabled in order to use the functionality of
> the device.
>  
> +config MFD_ENE_KB3930
> + tristate "ENE KB3930 Embedded Controller support"
> + depends on I2C
> + depends on MACH_MMP3_DT || COMPILE_TEST
> + select MFD_CORE
> + help
> +   This adds support for accessing the registers on ENE KB3930, Embedded
> +   Controller. Additional drivers such as LEDS_ARIEL must be enabled in
> +   order to use the functionality of the device.

Can you mention/describe all of the sub-devices please?

[...]

> +struct kb3930 *global_kb3930;

Can we call this kb3930_power_off please.

[...]

> +static int kb3930_probe(struct i2c_client *client)
> +{
> + struct device *dev = &client->dev;
> + struct device_node *np = dev->of_node;
> + struct kb3930 *ddata;
> + unsigned int model;
> + int ret;
> +
> + if (global_kb3930)
> + return -EEXIST;

This should not happen.  If .probe() is called twice, either
-EDEFER_PROBE was returned or a new device was registered.

[...]

> + /* These are the cells valid for model == 'J' only. */
> + ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO,
> +ariel_ec_cells,
> +ARRAY_SIZE(ariel_ec_cells),
> +NULL, 0, NULL);
> + if (ret < 0)

if (ret)

> + return ret;

[...]

> +static struct i2c_driver kb3930_driver = {
> + .probe_new = kb3930_probe,
> + .remove = kb3930_remove,
> + .driver = {
> + .name = "ene-kb3930",
> + .of_match_table = of_match_ptr(kb3930_dt_ids),
> + },
> +};
> +

Remove this line please.

> +module_i2c_driver(kb3930_driver);
> +
> +MODULE_AUTHOR("Lubomir Rintel ");
> +MODULE_DESCRIPTION("ENE KB3930 Embedded Controller Driver");
> +MODULE_LICENSE("Dual BSD/GPL");

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

[PATCH] xhci: Fix runtime PM imbalance on error

[Dinghao Liu]

When dma_set_mask_and_coherent() returns an error code,
a pairing runtime PM usage counter decrement is needed
to keep the counter balanced.

Also, call pm_runtime_disable() when dma_set_mask_and_coherent()
returns an error code.

Signed-off-by: Dinghao Liu 
---
 drivers/usb/host/xhci-histb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-histb.c b/drivers/usb/host/xhci-histb.c
index 5546e7e013a8..1d22a664477f 100644
--- a/drivers/usb/host/xhci-histb.c
+++ b/drivers/usb/host/xhci-histb.c
@@ -240,7 +240,7 @@ static int xhci_histb_probe(struct platform_device *pdev)
/* Initialize dma_mask and coherent_dma_mask to 32-bits */
ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
if (ret)
-   return ret;
+   goto disable_pm
 
hcd = usb_create_hcd(driver, dev, dev_name(dev));
if (!hcd) {
-- 
2.17.1

Re: [PATCH v3 00/14] mips: Prepare MIPS-arch code for Baikal-T1 SoC support

[Arnd Bergmann]

On Thu, May 21, 2020 at 9:18 AM Thomas Bogendoerfer
 wrote:
> On Thu, May 21, 2020 at 03:42:17AM +0300, Serge Semin wrote:
> > On Thu, May 21, 2020 at 03:34:29AM +0300, Serge Semin wrote:
> > >
> > > This patchset is rebased and tested on the mainline Linux kernel 5.7-rc4:
> > > base-commit: 0e698dfa2822 ("Linux 5.7-rc4")
> > > tag: v5.7-rc4
> >
> > Thomas,
> > Please note that this patchset is based on the Linux 5.7-rc4 tree (it most 
> > likely
> > will get cleanly applied on rc6 as well), while mips-next is still at rc1. 
> > Due
> > to that the patchset fails to be applied on mips-next. I think it would be
> > better first to merge the last Linux tree into the mips-next, then try to 
> > merge
> > this patchset in. Should you have any problem after that, please let me 
> > know.
> > I'll resend the patchset being rebased on top of the new mips-next tree.
>
> no, that's not how it works. Please rebase your patches on top of
> mips-next. Thank you.

Right, backmerges should generally be avoided. However if something
between rc1 and rc4 is required to make Baikal-T1 work, rebasing it to
rc1 would make it non-bisectable, which is also bad.

Serge, are you aware of something in -rc4 that is needed as a dependency?

   Arnd

Re: [PATCH] mm, memcg: reclaim more aggressively before high allocator throttling

[Michal Hocko]

On Wed 20-05-20 13:51:35, Johannes Weiner wrote:
> On Wed, May 20, 2020 at 07:04:30PM +0200, Michal Hocko wrote:
> > On Wed 20-05-20 12:51:31, Johannes Weiner wrote:
> > > On Wed, May 20, 2020 at 06:07:56PM +0200, Michal Hocko wrote:
> > > > On Wed 20-05-20 15:37:12, Chris Down wrote:
> > > > > In Facebook production, we've seen cases where cgroups have been put
> > > > > into allocator throttling even when they appear to have a lot of slack
> > > > > file caches which should be trivially reclaimable.
> > > > > 
> > > > > Looking more closely, the problem is that we only try a single cgroup
> > > > > reclaim walk for each return to usermode before calculating whether or
> > > > > not we should throttle. This single attempt doesn't produce enough
> > > > > pressure to shrink for cgroups with a rapidly growing amount of file
> > > > > caches prior to entering allocator throttling.
> > > > > 
> > > > > As an example, we see that threads in an affected cgroup are stuck in
> > > > > allocator throttling:
> > > > > 
> > > > > # for i in $(cat cgroup.threads); do
> > > > > > grep over_high "/proc/$i/stack"
> > > > > > done
> > > > > [<0>] mem_cgroup_handle_over_high+0x10b/0x150
> > > > > [<0>] mem_cgroup_handle_over_high+0x10b/0x150
> > > > > [<0>] mem_cgroup_handle_over_high+0x10b/0x150
> > > > > 
> > > > > ...however, there is no I/O pressure reported by PSI, despite a lot of
> > > > > slack file pages:
> > > > > 
> > > > > # cat memory.pressure
> > > > > some avg10=78.50 avg60=84.99 avg300=84.53 total=5702440903
> > > > > full avg10=78.50 avg60=84.99 avg300=84.53 total=5702116959
> > > > > # cat io.pressure
> > > > > some avg10=0.00 avg60=0.00 avg300=0.00 total=78051391
> > > > > full avg10=0.00 avg60=0.00 avg300=0.00 total=78049640
> > > > > # grep _file memory.stat
> > > > > inactive_file 1370939392
> > > > > active_file 661635072
> > > > > 
> > > > > This patch changes the behaviour to retry reclaim either until the
> > > > > current task goes below the 10ms grace period, or we are making no
> > > > > reclaim progress at all. In the latter case, we enter reclaim 
> > > > > throttling
> > > > > as before.
> > > > 
> > > > Let me try to understand the actual problem. The high memory reclaim has
> > > > a target which is proportional to the amount of charged memory. For most
> > > > requests that would be SWAP_CLUSTER_MAX though (resp. N times that where
> > > > N is the number of memcgs in excess up the hierarchy). I can see to be
> > > > insufficient if the memcg is already in a large excess but if the
> > > > reclaim can make a forward progress this should just work fine because
> > > > each charging context should reclaim at least the contributed amount.
> > > > 
> > > > Do you have any insight on why this doesn't work in your situation?
> > > > Especially with such a large inactive file list I would be really
> > > > surprised if the reclaim was not able to make a forward progress.
> > > 
> > > The workload we observed this in was downloading a large file and
> > > writing it to disk, which means that a good chunk of that memory was
> > > dirty. The first reclaim pass appears to make little progress because
> > > it runs into dirty pages.
> > 
> > OK, I see but why does the subsequent reclaim attempt makes a forward
> > progress? Is this just because dirty pages are flushed in the mean time?
> > Because if this is the case then the underlying problem seems to be that
> > the reclaim should be throttled on dirty data.
> 
> That's what I assume. Chris wanted to do more reclaim tracing. But is
> this actually important beyond maybe curiosity?

Yes, because it might show that there is a deeper problem. Having an
extremely large file list full of dirty data and pre-mature failure for
the reclaim sounds like a problem that is worth looking into closely.

> We retry every other reclaim invocation on forward progress. There is
> not a single naked call to try_to_free_pages(), and this here is the
> only exception where we don't loop on try_to_free_mem_cgroup_pages().

I am not saying the looping over try_to_free_pages is wrong. I do care
about the final reclaim target. That shouldn't be arbitrary. We have
established a target which is proportional to the requested amount of
memory. And there is a good reason for that. If any task tries to
reclaim down to the high limit then this might lead to a large
unfairness when heavy producers piggy back on the active reclaimer(s).

I wouldn't mind to loop over try_to_free_pages to meet the requested
memcg_nr_pages_over_high target.

[...]

> > > > Also if the current high reclaim scaling is insufficient then we should
> > > > be handling that via memcg_nr_pages_over_high rather than effectivelly
> > > > unbound number of reclaim retries.
> > > 
> > > ???
> > 
> > I am not sure what you are asking here.
> 
> You expressed that some alternate solution B would be preferable,
> without any detail on why you think t

RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Hi Thinh,
> -Original Message-
> From: Thinh Nguyen 
> Sent: 2020年5月21日 9:56
> To: Jun Li ; Felipe Balbi ; Jun Li
> 
> Cc: John Stultz ; lkml 
> ; Yu
> Chen ; Greg Kroah-Hartman ; 
> Rob
> Herring ; Mark Rutland ; ShuFan Lee
> ; Heikki Krogerus ;
> Suzuki K Poulose ; Chunfeng Yun
> ; Hans de Goede ; Andy 
> Shevchenko
> ; Valentin Schneider ;
> Jack Pham ; Linux USB List ; 
> open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
> ;
> Peter Chen 
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by 
> device
> controller
> 
> Thinh Nguyen wrote:
> > Jun Li wrote:
> >> Hi
> >>
> >>> -Original Message-
> >>> From: Thinh Nguyen 
> >>> Sent: 2020年5月19日 14:46
> >>> To: Jun Li ; Felipe Balbi ; Jun Li
> >>> 
> >>> Cc: John Stultz ; lkml
> >>> ; Yu Chen ; Greg
> >>> Kroah-Hartman ; Rob Herring
> >>> ; Mark Rutland ; ShuFan
> >>> Lee ; Heikki Krogerus
> >>> ;
> >>> Suzuki K Poulose ; Chunfeng Yun
> >>> ; Hans de Goede ;
> >>> Andy Shevchenko ; Valentin Schneider
> >>> ; Jack Pham ;
> >>> Linux USB List ; open list:OPEN FIRMWARE
> >>> AND FLATTENED DEVICE TREE BINDINGS ;
> >>> Peter Chen 
> >>> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct
> >>> cleared by device controller
> >>>
> >>> Thinh Nguyen wrote:
>  Jun Li wrote:
> >> -Original Message-
> >> From: Felipe Balbi  On Behalf Of Felipe Balbi
> >> Sent: 2020年5月16日 19:57
> >> To: Jun Li ; Thinh Nguyen
> >> ; Jun Li 
> >> Cc: John Stultz ; lkml
> >> ; Yu Chen ;
> >> Greg Kroah-Hartman ; Rob Herring
> >> ; Mark Rutland ; ShuFan
> >> Lee ; Heikki Krogerus
> >> ;
> >> Suzuki K Poulose ; Chunfeng Yun
> >> ; Hans de Goede ;
> >> Andy Shevchenko ; Valentin Schneider
> >> ; Jack Pham ;
> >> Linux USB List ; open list:OPEN
> >> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> >> ; Peter Chen ;
> >> Thinh Nguyen 
> >> Subject: RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for
> >> CmdAct cleared by device controller
> >>
> >>
> >> Hi,
> >>
> >> Jun Li  writes:
> >> Hi Thinh, could you comment this?
> > You only need to wake up the usb2 phy when issuing the command
> > while running in highspeed or below. If you're running in SS
> > or higher, internally the controller does it for you for usb3 phy.
> > In Jun's case, it seems like it takes longer for his phy to wake up.
> >
> > IMO, in this case, I think it's fine to increase the command 
> > timeout.
>  Is there an upper limit to this? Is 32k clock the slowest that
>  can be fed to the PHY as a suspend clock?
> >>> Yes, 32K clock is the slowest, Per DWC3 document on Power Down
> >>> Scale (bits 31:19 of GCTL):
> >>>
> >>> "Power Down Scale (PwrDnScale)
> >>> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock
> >>> source to a small part of the USB3 controller that operates when
> >>> the SS PHY is in its lowest power (P3) state, and therefore does not 
> >>> provide
> a clock.
> >>> The Power Down Scale field specifies how many suspend_clk
> >>> periods fit into a 16 kHz clock period. When performing the
> >>> division, round up the remainder.
> >>> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz
> >>> Suspend clock, Power Down Scale = 25000 kHz/16 kHz = 13'd1563
> >>> (rounder up)
> >>> Note:
> >>> - Minimum Suspend clock frequency is 32 kHz
> >>> - Maximum Suspend clock frequency is 125 MHz"
> >> Cool, now do we have an upper bound for how many clock cycles it
> >> takes to wake up the PHY?
> > My understanding is this ep command does not wake up the SS PHY,
> > the SS PHY still stays at P3 when execute this ep command. The
> > time required here is to wait controller complete something for
> > this ep command with 32K clock.
>  Sorry I made a mistake. You're right. Just checked with one of the
>  RTL engineers, and it doesn't need to wake up the phy. However, if
>  it is eSS speed, it may take longer time as the command may be
>  completing with the suspend clock.
> 
> >>> What's the value for GCTL[7:6]?
> >> 2'b00
> >>
> >> Thanks
> >> Li Jun
> > (Sorry for the delay reply)
> >
> > If it's 0, then the ram clock should be the same as the bus_clk, which
> > is odd since you mentioned that the suspend_clk is used instead while in P3.
> 
> Just checked with the RTL engineer, even if GCTL[7:6] is set to 0, internally 
> it
> can still run with suspend clock during P3.

Thanks for your check.
> 
> > Anyway, I was looking for a way maybe to improve the speed during
> > issuing a command. One way is to set GUSB3PIPECTL[17]=0, and it should
> > wakeup the phy anytime. I think Felipe suggested it. It's odd that it
> > doesn't work for you. I don't have other ideas beside increasing the
> > command timeout.
> >
> 
> In any case, increas

Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support

[Arnd Bergmann]

On Thu, May 21, 2020 at 9:07 AM Sudeep Holla  wrote:
>
> On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote:
> > On Wed, May 20, 2020 at 11:29 PM Will Deacon  wrote:
> > >
> > > On Mon, 18 May 2020 10:12:15 +0100, Sudeep Holla wrote:
> > > > This patch series adds support for SMCCCv1.2 ARCH_SOC_ID.
> > > > This doesn't add other changes added in SMCCC v1.2 yet. They will
> > > > follow these soon along with its first user SPCI/PSA-FF.
> > > >
> > > > This is tested using upstream TF-A + the patch[3] fixing the original
> > > > implementation there.
> > > >
> > > > [...]
> > >
> > > Applied to arm64 (for-next/smccc), thanks!
> > >
> > > [1/7] firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC 
> > > v1.1 and above
> > >   https://git.kernel.org/arm64/c/e5bfb21d98b6
> > > [2/7] firmware: smccc: Update link to latest SMCCC specification
> > >   https://git.kernel.org/arm64/c/15c704ab6244
> > > [3/7] firmware: smccc: Add the definition for SMCCCv1.2 version/error 
> > > codes
> > >   https://git.kernel.org/arm64/c/0441bfe7f00a
> > > [4/7] firmware: smccc: Drop smccc_version enum and use 
> > > ARM_SMCCC_VERSION_1_x instead
> > >   https://git.kernel.org/arm64/c/ad5a57dfe434
> > > [5/7] firmware: smccc: Refactor SMCCC specific bits into separate file
> > >   https://git.kernel.org/arm64/c/f2ae97062a48
> > > [6/7] firmware: smccc: Add function to fetch SMCCC version
> > >   https://git.kernel.org/arm64/c/a4fb17465182
> > > [7/7] firmware: smccc: Add ARCH_SOC_ID support
> > >   https://git.kernel.org/arm64/c/ce6488f0ce09
> > >
> > > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable to 
> > > me,
> > > but please shout if you'd rather I dropped this in order to pursue an
> > > alternative approach.
> >
> > I missed the reply earlier, thanks for pointing me to it again.
> >
> > I'm not entirely convinced, but don't revert it for now because of that,
> > I assume we can find a solution.
> >
>
> I liked your idea of making this generic and hardcode values if required
> for other drivers. I will take a look at that/
>
> > However, please have a look at the build failure report for patch 5
> > and fix it if you can see what went wrong.
> >
>
> Any pointers for that failure ? I seem to have missed them. I pushed
> branch couple of times to my tree but got build success both times.
> Any specific config or compilers ?

See below for the reply from the 0day build bot to your email. It seems it
was not sent to the mailing list, but you were on Cc. Looking at it now,
the fix should be trivial.

Arnd

8<---
I love your patch! Perhaps something to improve:

[auto build test WARNING on soc/for-next]
[also build test WARNING on arm64/for-next/core linus/master v5.7-rc6
next-20200519]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Sudeep-Holla/firmware-smccc-Add-basic-SMCCC-v1-2-ARCH_SOC_ID-support/20200518-171401
base:   https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
config: arm64-randconfig-r026-20200519 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
135b877874fae96b4372c8a3fbfaa8ff44ff86e3)
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64

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

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

>> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for 
>> function 'arm_smccc_version_init' [-Wmissing-prototypes]
void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
^
drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the
function is not intended to be used outside of this translation unit
void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit conduit)
^
static
1 warning generated.

vim +/arm_smccc_version_init +14 drivers/firmware/smccc/smccc.c

13
  > 14 void __init arm_smccc_version_init(u32 version, enum
arm_smccc_conduit conduit)
15 {
16 smccc_version = version;
17 smccc_conduit = conduit;
18 }
19

Re: [PATCH v6 09/12] mmap locking API: add mmap_assert_locked() and mmap_assert_write_locked()

[Vlastimil Babka]

On 5/20/20 7:29 AM, Michel Lespinasse wrote:
> Add new APIs to assert that mmap_sem is held.
> 
> Using this instead of rwsem_is_locked and lockdep_assert_held[_write]
> makes the assertions more tolerant of future changes to the lock type.
> 
> Signed-off-by: Michel Lespinasse 

Reviewed-by: Vlastimil Babka 

[PATCH] usb: musb: Fix runtime PM imbalance on error

[Dinghao Liu]

When copy_from_user() returns an error code, a pairing
runtime PM usage counter decrement is needed to keep
the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/usb/musb/musb_debugfs.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 7b6281ab62ed..837c38a5e4ef 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -178,8 +178,11 @@ static ssize_t musb_test_mode_write(struct file *file,
 
memset(buf, 0x00, sizeof(buf));
 
-   if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
+   if (copy_from_user(buf, ubuf, min_t(size_t, sizeof(buf) - 1, count))) {
+   pm_runtime_mark_last_busy(musb->controller);
+   pm_runtime_put_autosuspend(musb->controller);
return -EFAULT;
+   }
 
if (strstarts(buf, "force host full-speed"))
test = MUSB_TEST_FORCE_HOST | MUSB_TEST_FORCE_FS;
-- 
2.17.1

Re: [PATCH v6 11/12] mmap locking API: convert mmap_sem API comments

[Vlastimil Babka]

On 5/20/20 7:29 AM, Michel Lespinasse wrote:
> Convert comments that reference old mmap_sem APIs to reference
> corresponding new mmap locking APIs instead.
> 
> Signed-off-by: Michel Lespinasse 

Reviewed-by: Vlastimil Babka 

Re: [PATCH] input: i8042: Remove special PowerPC handling

[Michael Ellerman]

Dmitry Torokhov  writes:
> Hi Michael,
>
> On Wed, May 20, 2020 at 04:07:00PM +1000, Michael Ellerman wrote:
>> [ + Dmitry & linux-input ]
>> 
>> Nathan Chancellor  writes:
>> > This causes a build error with CONFIG_WALNUT because kb_cs and kb_data
>> > were removed in commit 917f0af9e5a9 ("powerpc: Remove arch/ppc and
>> > include/asm-ppc").
>> >
>> > ld.lld: error: undefined symbol: kb_cs
>> >> referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
>> >> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
>> >> referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
>> >> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
>> >> referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28)
>> >> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
>> >
>> > ld.lld: error: undefined symbol: kb_data
>> >> referenced by i8042.c:309 (drivers/input/serio/i8042.c:309)
>> >> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
>> >> referenced by i8042-ppcio.h:33 (drivers/input/serio/i8042-ppcio.h:33)
>> >> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
>> >> referenced by i8042.c:319 (drivers/input/serio/i8042.c:319)
>> >> input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a
>> >> referenced 15 more times
>> >
>> > Presumably since nobody has noticed this for the last 12 years, there is
>> > not anyone actually trying to use this driver so we can just remove this
>> > special walnut code and use the generic header so it builds for all
>> > configurations.
>> >
>> > Fixes: 917f0af9e5a9 ("powerpc: Remove arch/ppc and include/asm-ppc")
>> > Reported-by: kbuild test robot 
>> > Signed-off-by: Nathan Chancellor 
>> > ---
>> >  drivers/input/serio/i8042-ppcio.h | 57 ---
>> >  drivers/input/serio/i8042.h   |  2 --
>> >  2 files changed, 59 deletions(-)
>> >  delete mode 100644 drivers/input/serio/i8042-ppcio.h
>> 
>> This LGTM.
>> 
>> Acked-by: Michael Ellerman  (powerpc)
>> 
>> I assumed drivers/input/serio would be pretty quiet, but there's
>> actually some commits to it in linux-next. So perhaps this should go via
>> the input tree.
>> 
>> Dmitry do you want to take this, or should I take it via powerpc?
>> 
>> Original patch is here:
>>   
>> https://lore.kernel.org/lkml/20200518181043.3363953-1-natechancel...@gmail.com
>
> I'm fine with you taking it through powerpc.
>
> Acked-by: Dmitry Torokhov 

Thanks.

> Also, while I have your attention ;), could you please ack or take
> https://lore.kernel.org/lkml/20191002214854.GA114387@dtor-ws/ as I
> believe this is the last user or input_polled_dev API and I would like
> to drop it from the tree.

Ooof. Sorry, you are very patient :)

I have put it in my next-test.

In future feel free to send me mail off-list, or ping me on irc, if I
haven't picked something up after several months!

cheers

[PATCH] usb: cdns3: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/usb/cdns3/cdns3-ti.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/cdns3/cdns3-ti.c b/drivers/usb/cdns3/cdns3-ti.c
index 5685ba11480b..e701ab56b0a7 100644
--- a/drivers/usb/cdns3/cdns3-ti.c
+++ b/drivers/usb/cdns3/cdns3-ti.c
@@ -138,7 +138,7 @@ static int cdns_ti_probe(struct platform_device *pdev)
error = pm_runtime_get_sync(dev);
if (error < 0) {
dev_err(dev, "pm_runtime_get_sync failed: %d\n", error);
-   goto err_get;
+   goto err;
}
 
/* assert RESET */
@@ -185,7 +185,6 @@ static int cdns_ti_probe(struct platform_device *pdev)
 
 err:
pm_runtime_put_sync(data->dev);
-err_get:
pm_runtime_disable(data->dev);
 
return error;
-- 
2.17.1

Re: [PATCH 3.16 00/99] 3.16.84-rc1 review

[Guenter Roeck]

On 5/20/20 7:47 PM, Chen-Yu Tsai wrote:
> On Thu, May 21, 2020 at 5:23 AM Guenter Roeck  wrote:
>>
>> On 5/20/20 7:13 AM, Ben Hutchings wrote:
>>> This is the start of the stable review cycle for the 3.16.84 release.
>>> There are 99 patches in this series, which will be posted as responses
>>> to this one.  If anyone has any issues with these being applied, please
>>> let me know.
>>>
>>> Responses should be made by Fri May 22 20:00:00 UTC 2020.
>>> Anything received after that time might be too late.
>>>
>> Build results:
>> total: 135 pass: 135 fail: 0
>> Qemu test results:
>> total: 230 pass: 227 fail: 3
>> Failed tests:
>> arm:cubieboard:multi_v7_defconfig:mem512:sun4i-a10-cubieboard:initrd
>> 
>> arm:cubieboard:multi_v7_defconfig:usb:mem512:sun4i-a10-cubieboard:rootfs
>> 
>> arm:cubieboard:multi_v7_defconfig:sata:mem512:sun4i-a10-cubieboard:rootfs
>>
>> The arm tests fail due to a compile error.
>>
>> drivers/clk/tegra/clk-tegra-periph.c:524:65: error: 'CLK_IS_CRITICAL' 
>> undeclared here (not in a function); did you mean 'CLK_IS_BASIC'?
> 
> This looks like a result of having
> 
>   clk: tegra: Mark fuse clock as critical
>  [bf83b96f87ae2abb1e535306ea53608e8de5dfbb]
> 
> In which case you probably need to add
> 
> 32b9b1096186 clk: Allow clocks to be marked as CRITICAL
> 

Then you might also need commit ef56b79b66f ("clk: fix critical
clock locking") which fixes it.

Guenter

RE: [PATCH 3/4] habanalabs: GAUDI does not support soft-reset

[Tomer Tayar]

On Thu, May 21, 2020 at 10:02, Oded Gabbay  wrote:
> GAUDI does not support soft-reset as it leaves the NIC ports in an awkward
> state, where their QMANs were reset but the NIC itself is still working.
> 
> In addition, there is not much sense in doing soft-reset when training is
> done on multiple GAUDIs.
> 
> Signed-off-by: Oded Gabbay 

Reviewed-by: Tomer Tayar 

Re: next-0519 on thinkpad x60: sound related? window manager crash

[Pavel Machek]

Hi!

> My window manager stopped responding. I was able to recover machine
> using sysrq-k.
> 
> I started writing nice report, when session failed second time. And
> then third time on next attempt.
> 
> Any ideas?
> 
> I'll send this out before this locks up...

Today it crashed again, with similar oops in the log.

My records say:

fb57b1fabcb2 (HEAD, tag: next-20200519, origin/master, origin/HEAD) HEAD@{0}: 
checkout: moving from bdecf38f228bcca73b31ada98b5b7ba1215eb9c9 to next-20200519
bdecf38f228b (tag: next-20200515) HEAD@{1}: checkout: moving from 
30e2206e11ce27ae910cc0dab21472429e400a87 to next-20200515

So it is well possible that 0515 worked okay for few
days. Hmm. Perhaps I'll try going to 0516 and see if it is stable?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: PGP signature

Re: [PATCH net 0/3] rxrpc: Fix retransmission timeout and ACK discard

[David Howells]

I've posted a new version of this with a fixed description for patch 1.

David

Re: [PATCH v6 12/12] mmap locking API: convert mmap_sem comments

[Vlastimil Babka]

On 5/20/20 7:29 AM, Michel Lespinasse wrote:
> Convert comments that reference mmap_sem to reference mmap_lock instead.
> 
> Signed-off-by: Michel Lespinasse 

Reviewed-by: Vlastimil Babka 

But:

> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index a1247d3553da..1bf46e2e0cec 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -224,7 +224,7 @@ static int mpol_new_bind(struct mempolicy *pol, const 
> nodemask_t *nodes)
>   * handle an empty nodemask with MPOL_PREFERRED here.
>   *
>   * Must be called holding task's alloc_lock to protect task's mems_allowed
> - * and mempolicy.  May also be called holding the mmap_semaphore for write.
> + * and mempolicy.  May also be called holding the mmap_lockaphore for write.
>   */
>  static int mpol_set_nodemask(struct mempolicy *pol,
>const nodemask_t *nodes, struct nodemask_scratch *nsc)

:)

Re: [PATCH 29/33] rxrpc: add rxrpc_sock_set_min_security_level

[David Howells]

Christoph Hellwig  wrote:

> Add a helper to directly set the RXRPC_MIN_SECURITY_LEVEL sockopt from
> kernel space without going through a fake uaccess.
> 
> Thanks to David Howells for the documentation updates.
> 
> Signed-off-by: Christoph Hellwig 

Acked-by: David Howells 

[PATCH] spi: spi-ti-qspi: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/spi/spi-ti-qspi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 366a3e5cca6b..6d24cff2693c 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -175,6 +175,7 @@ static int ti_qspi_setup(struct spi_device *spi)
ret = pm_runtime_get_sync(qspi->dev);
if (ret < 0) {
dev_err(qspi->dev, "pm_runtime_get_sync() failed\n");
+   pm_runtime_put_autosuspend(qspi->dev);
return ret;
}
 
-- 
2.17.1

RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Hi Felipe,

> -Original Message-
> From: Felipe Balbi  On Behalf Of Felipe Balbi
> Sent: 2020年5月21日 14:23
> To: Thinh Nguyen ; Jun Li ; Jun Li
> 
> Cc: John Stultz ; lkml 
> ; Yu
> Chen ; Greg Kroah-Hartman ; 
> Rob
> Herring ; Mark Rutland ; ShuFan Lee
> ; Heikki Krogerus ;
> Suzuki K Poulose ; Chunfeng Yun
> ; Hans de Goede ; Andy 
> Shevchenko
> ; Valentin Schneider ;
> Jack Pham ; Linux USB List ; 
> open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
> ;
> Peter Chen 
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by 
> device
> controller
> 
> 
> Hi Jun,
> 
> Felipe Balbi  writes:
> >> In any case, increasing the timeout should be fine with me. It maybe
> >> difficult to determine the max timeout base on the slowest clock rate
> >> and number of cycles. Different controller and controller versions
> >> behave differently and may have different number of clock cycles to
> >> complete a command.
> >>
> >> The RTL engineer recommended timeout to be at least 1ms (which maybe
> >> more than the polling rate of this patch). I'm fine with either the
> >> rate provided by this tested patch or higher.
> >
> > A whole ms waiting for a command to complete? Wow, that's a lot of
> > time blocking the CPU. It looks like, perhaps, we should move to
> > command completion interrupts. The difficulty here is that we issue
> > commands from within the interrupt handler and, as such, can't
> > wait_for_completion().
> >
> > Meanwhile, we will take the timeout increase I guess, otherwise NXP
> > won't have a working setup.
> 
> patch 1 in this series doesn't apply to testing/next. Care to rebase and 
> resend?

Sure, I will rebase and resend this patch with timeout loop 5000.

Thanks
Li Jun
> 
> Thank you
> 
> --
> balbi

RE: [PATCH 4.4 00/86] 4.4.224-rc1 review

[Chris Paterson]

Hello Greg,

> From: stable-ow...@vger.kernel.org  On
> Behalf Of Greg Kroah-Hartman
> Sent: 18 May 2020 18:36
> 
> This is the start of the stable review cycle for the 4.4.224 release.
> There are 86 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.

No build/boot issues seen for CIP configs for Linux Linux 4.4.224-rc1 
(5614224b8432).

Build/test pipeline/logs: 
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/147257290
GitLab CI pipeline: 
https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.4.y.yml
Relevant LAVA jobs: 
https://lava.ciplatform.org/scheduler/alljobs?length=25&search=561422#table

Kind regards, Chris

> 
> Responses should be made by Wed, 20 May 2020 17:32:42 +.
> 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.4.224-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.4.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h
> 
> -
> Pseudo-Shortlog of commits:
> 
> Greg Kroah-Hartman 
> Linux 4.4.224-rc1
> 
> Sergei Trofimovich 
> Makefile: disallow data races on gcc-10 as well
> 
> Jim Mattson 
> KVM: x86: Fix off-by-one error in kvm_vcpu_ioctl_x86_setup_mce
> 
> Geert Uytterhoeven 
> ARM: dts: r8a7740: Add missing extal2 to CPG node
> 
> Kai-Heng Feng 
> Revert "ALSA: hda/realtek: Fix pop noise on ALC225"
> 
> Wei Yongjun 
> usb: gadget: legacy: fix error return code in cdc_bind()
> 
> Wei Yongjun 
> usb: gadget: legacy: fix error return code in gncm_bind()
> 
> Christophe JAILLET 
> usb: gadget: audio: Fix a missing error return value in audio_bind()
> 
> Christophe JAILLET 
> usb: gadget: net2272: Fix a memory leak in an error handling path in
> 'net2272_plat_probe()'
> 
> Eric W. Biederman 
> exec: Move would_dump into flush_old_exec
> 
> Borislav Petkov 
> x86: Fix early boot crash on gcc-10, third try
> 
> Fabio Estevam 
> ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entries
> 
> Kyungtae Kim 
> USB: gadget: fix illegal array access in binding with UDC
> 
> Takashi Iwai 
> ALSA: rawmidi: Initialize allocated buffers
> 
> Takashi Iwai 
> ALSA: rawmidi: Fix racy buffer resize under concurrent accesses
> 
> Takashi Iwai 
> ALSA: hda/realtek - Limit int mic boost for Thinkpad T530
> 
> Paolo Abeni 
> netlabel: cope with NULL catmap
> 
> Paolo Abeni 
> net: ipv4: really enforce backoff for redirects
> 
> Cong Wang 
> net: fix a potential recursive NETDEV_FEAT_CHANGE
> 
> Linus Torvalds 
> gcc-10: avoid shadowing standard library 'free()' in crypto
> 
> Boris Ostrovsky 
> x86/paravirt: Remove the unused irq_enable_sysexit pv op
> 
> Keith Busch 
> blk-mq: Allow blocking queue tag iter callbacks
> 
> Jianchao Wang 
> blk-mq: sync the update nr_hw_queues with blk_mq_queue_tag_busy_iter
> 
> Gabriel Krisman Bertazi 
> blk-mq: Allow timeouts to run while queue is freezing
> 
> Christoph Hellwig 
> block: defer timeouts to a workqueue
> 
> Linus Torvalds 
> gcc-10: disable 'restrict' warning for now
> 
> Linus Torvalds 
> gcc-10: disable 'stringop-overflow' warning for now
> 
> Linus Torvalds 
> gcc-10: disable 'array-bounds' warning for now
> 
> Linus Torvalds 
> gcc-10: disable 'zero-length-bounds' warning for now
> 
> Linus Torvalds 
> Stop the ad-hoc games with -Wno-maybe-initialized
> 
> Masahiro Yamada 
> kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
> 
> Linus Torvalds 
> gcc-10 warnings: fix low-hanging fruit
> 
> Jason Gunthorpe 
> pnp: Use list_for_each_entry() instead of open coding
> 
> Jack Morgenstein 
> IB/mlx4: Test return value of calls to ib_get_cached_pkey
> 
> Arnd Bergmann 
> netfilter: conntrack: avoid gcc-10 zero-length-bounds warning
> 
> Gal Pressman 
> net/mlx5: Fix driver load error flow when firmware is stuck
> 
> Anjali Singhai Jain 
> i40e: avoid NVM acquire deadlock during NVM update
> 
> Ben Hutchings 
> scsi: qla2xxx: Avoid double completion of abort command
> 
> zhong jiang 
> mm/memory_hotplug.c: fix overflow in test_pages_in_a_zone()
> 
> Jiri Benc 
> gre: do not keep the GRE header around in collect medata mode
> 
> John Hurley 
> net: openvswitch: fix csum updates for MPLS actions
> 
> Vasily Averin 
> ipc/util.c: sysvipc_find_ipc() incorrectly updates position index
> 
> Vasily Averin 
> drm/qxl: lost qxl_bo_kunmap_atomic_page in qxl_image_init_helper()
> 
> Lubomir Rintel 
> dmaengine: mmp_tdma: Reset channel error on release
> 
> Madhuparna Bhowmik 
> dmaengine: pch_dma.c: Avoid data race between probe and irq handler
> 
> Ronnie Sahlber

Re: [PATCH v13 5/6] rtc: mt6397: Add support for the MediaTek MT6358 RTC

[Lee Jones]

On Sat, 16 May 2020, Matthias Brugger wrote:

> Hi Lee,
> 
> On 21/04/2020 05:00, Hsin-Hsiung Wang wrote:
> > From: Ran Bi 
> > 
> > This add support for the MediaTek MT6358 RTC. Driver using
> > compatible data to store different RTC_WRTGR address offset.
> > This replace RTC_WRTGR to RTC_WRTGR_MT6323 in mt6323-poweroff
> > driver which only needed by armv7 CPU without ATF.
> > 
> > Signed-off-by: Ran Bi 
> > Signed-off-by: Hsin-Hsiung Wang 
> > Reviewed-by: Nicolas Boichat 
> > Acked-by: Alexandre Belloni 
> > Acked-by: Sebastian Reichel 
> > Reviewed-by: Yingjoe Chen 
> 
> We have Acked-by from rtc and reset drivers maintainers. Are you OK to take 
> them
> through your mfd branch?
> 
> Are you planning to queue them for v5.8?
> 
> Just asking because if so I'd queue patch 6 through my tree.

Yes, please take patch 6.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

RE: [PATCH 4.19 00/80] 4.19.124-rc1 review

[Chris Paterson]

Hello Greg,

> From: stable-ow...@vger.kernel.org  On
> Behalf Of Greg Kroah-Hartman
> Sent: 18 May 2020 18:36
> 
> This is the start of the stable review cycle for the 4.19.124 release.
> There are 80 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.

No build/boot issues seen for CIP configs for Linux 4.19.124-rc1 (ff1170bc0ae9).

Build/test pipeline/logs: 
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/147257412
GitLab CI pipeline: 
https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
Relevant LAVA jobs: 
https://lava.ciplatform.org/scheduler/alljobs?length=25&search=ff1170#table

Kind regards, Chris

> 
> Responses should be made by Wed, 20 May 2020 17:32:42 +.
> 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.124-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
> 
> -
> Pseudo-Shortlog of commits:
> 
> Greg Kroah-Hartman 
> Linux 4.19.124-rc1
> 
> Sergei Trofimovich 
> Makefile: disallow data races on gcc-10 as well
> 
> Jim Mattson 
> KVM: x86: Fix off-by-one error in kvm_vcpu_ioctl_x86_setup_mce
> 
> Geert Uytterhoeven 
> ARM: dts: r8a7740: Add missing extal2 to CPG node
> 
> Yoshihiro Shimoda 
> arm64: dts: renesas: r8a77980: Fix IPMMU VIP[01] nodes
> 
> Geert Uytterhoeven 
> ARM: dts: r8a73a4: Add missing CMT1 interrupts
> 
> Chen-Yu Tsai 
> arm64: dts: rockchip: Rename dwc3 device nodes on rk3399 to make dtc
> happy
> 
> Chen-Yu Tsai 
> arm64: dts: rockchip: Replace RK805 PMIC node name with "pmic" on rk3328
> boards
> 
> Marc Zyngier 
> clk: Unlink clock if failed to prepare or enable
> 
> Kai-Heng Feng 
> Revert "ALSA: hda/realtek: Fix pop noise on ALC225"
> 
> Wei Yongjun 
> usb: gadget: legacy: fix error return code in cdc_bind()
> 
> Wei Yongjun 
> usb: gadget: legacy: fix error return code in gncm_bind()
> 
> Christophe JAILLET 
> usb: gadget: audio: Fix a missing error return value in audio_bind()
> 
> Christophe JAILLET 
> usb: gadget: net2272: Fix a memory leak in an error handling path in
> 'net2272_plat_probe()'
> 
> John Stultz 
> dwc3: Remove check for HWO flag in dwc3_gadget_ep_reclaim_trb_sg()
> 
> Justin Swartz 
> clk: rockchip: fix incorrect configuration of rk3228 aclk_gpu* clocks
> 
> Eric W. Biederman 
> exec: Move would_dump into flush_old_exec
> 
> Josh Poimboeuf 
> x86/unwind/orc: Fix error handling in __unwind_start()
> 
> Borislav Petkov 
> x86: Fix early boot crash on gcc-10, third try
> 
> Adam McCoy 
> cifs: fix leaked reference on requeued write
> 
> Fabio Estevam 
> ARM: dts: imx27-phytec-phycard-s-rdk: Fix the I2C1 pinctrl entries
> 
> Kishon Vijay Abraham I 
> ARM: dts: dra7: Fix bus_dma_limit for PCIe
> 
> Sriharsha Allenki 
> usb: xhci: Fix NULL pointer dereference when enqueuing trbs from urb sg 
> list
> 
> Kyungtae Kim 
> USB: gadget: fix illegal array access in binding with UDC
> 
> Li Jun 
> usb: host: xhci-plat: keep runtime active when removing host
> 
> Eugeniu Rosca 
> usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B
> 
> Jesus Ramos 
> ALSA: usb-audio: Add control message quirk delay for Kingston HyperX
> headset
> 
> Takashi Iwai 
> ALSA: rawmidi: Fix racy buffer resize under concurrent accesses
> 
> Takashi Iwai 
> ALSA: hda/realtek - Limit int mic boost for Thinkpad T530
> 
> Linus Torvalds 
> gcc-10: avoid shadowing standard library 'free()' in crypto
> 
> Linus Torvalds 
> gcc-10: disable 'restrict' warning for now
> 
> Linus Torvalds 
> gcc-10: disable 'stringop-overflow' warning for now
> 
> Linus Torvalds 
> gcc-10: disable 'array-bounds' warning for now
> 
> Linus Torvalds 
> gcc-10: disable 'zero-length-bounds' warning for now
> 
> Linus Torvalds 
> Stop the ad-hoc games with -Wno-maybe-initialized
> 
> Masahiro Yamada 
> kbuild: compute false-positive -Wmaybe-uninitialized cases in Kconfig
> 
> Linus Torvalds 
> gcc-10 warnings: fix low-hanging fruit
> 
> Jason Gunthorpe 
> pnp: Use list_for_each_entry() instead of open coding
> 
> Samu Nuutamo 
> hwmon: (da9052) Synchronize access with mfd
> 
> Jack Morgenstein 
> IB/mlx4: Test return value of calls to ib_get_cached_pkey
> 
> Stefano Brivio 
> netfilter: nft_set_rbtree: Introduce and use nft_rbtree_interval_start()
> 
> Christoph Hellwig 
> arm64: fix the flush_icache_range arguments in machine_kexec
> 
> Arnd Bergmann 
> netfilter: conntrack: avoid gcc-10 zero-length-bounds warning
> 
> Dave Wysochanski 
> NFSv4: Fix fscache coo

[PATCH] spi: tegra20-slink: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/spi/spi-tegra20-slink.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-tegra20-slink.c b/drivers/spi/spi-tegra20-slink.c
index 7f4d932dade7..15361db00982 100644
--- a/drivers/spi/spi-tegra20-slink.c
+++ b/drivers/spi/spi-tegra20-slink.c
@@ -1118,6 +1118,7 @@ static int tegra_slink_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "pm runtime get failed, e = %d\n", ret);
+   pm_runtime_put(&pdev->dev);
goto exit_pm_disable;
}
tspi->def_command_reg  = SLINK_M_S;
-- 
2.17.1

Re: [PATCH v6 12/12] mmap locking API: convert mmap_sem comments

[Michel Lespinasse]

On Thu, May 21, 2020 at 12:42 AM Vlastimil Babka  wrote:
> On 5/20/20 7:29 AM, Michel Lespinasse wrote:
> > Convert comments that reference mmap_sem to reference mmap_lock instead.
> >
> > Signed-off-by: Michel Lespinasse 
>
> Reviewed-by: Vlastimil Babka 
>
> But:
>
> > diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> > index a1247d3553da..1bf46e2e0cec 100644
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -224,7 +224,7 @@ static int mpol_new_bind(struct mempolicy *pol, const 
> > nodemask_t *nodes)
> >   * handle an empty nodemask with MPOL_PREFERRED here.
> >   *
> >   * Must be called holding task's alloc_lock to protect task's mems_allowed
> > - * and mempolicy.  May also be called holding the mmap_semaphore for write.
> > + * and mempolicy.  May also be called holding the mmap_lockaphore for 
> > write.
> >   */
> >  static int mpol_set_nodemask(struct mempolicy *pol,
> >const nodemask_t *nodes, struct nodemask_scratch *nsc)
>
> :)

Haha, good catch !

-- 
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.

[PATCH] spi: tegra20-sflash: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/spi/spi-tegra20-sflash.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-tegra20-sflash.c b/drivers/spi/spi-tegra20-sflash.c
index 514429379206..159efbc55a53 100644
--- a/drivers/spi/spi-tegra20-sflash.c
+++ b/drivers/spi/spi-tegra20-sflash.c
@@ -491,6 +491,7 @@ static int tegra_sflash_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "pm runtime get failed, e = %d\n", ret);
+   pm_runtime_put(&pdev->dev);
goto exit_pm_disable;
}
 
-- 
2.17.1

[PATCH v3] selftests/timens: handle a case when alarm clocks are not supported

[Andrei Vagin]

This can happen if a testing node doesn't have RTC (real time clock)
hardware or it doesn't support alarms.

Fixes: 61c57676035d ("selftests/timens: Add Time Namespace test for supported 
clocks")
Acked-by: Vincenzo Frascino 
Reported-by: Vincenzo Frascino 
Signed-off-by: Andrei Vagin 
---
v2: fix timer.c and timerfd.c too.
v3: add Reported-by and Fixes tags.

 tools/testing/selftests/timens/clock_nanosleep.c |  2 +-
 tools/testing/selftests/timens/timens.c  |  2 +-
 tools/testing/selftests/timens/timens.h  | 13 -
 tools/testing/selftests/timens/timer.c   |  5 +
 tools/testing/selftests/timens/timerfd.c |  5 +
 5 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/timens/clock_nanosleep.c 
b/tools/testing/selftests/timens/clock_nanosleep.c
index 8e7b7c72ef65..72d41b955fb2 100644
--- a/tools/testing/selftests/timens/clock_nanosleep.c
+++ b/tools/testing/selftests/timens/clock_nanosleep.c
@@ -119,7 +119,7 @@ int main(int argc, char *argv[])
 
ksft_set_plan(4);
 
-   check_config_posix_timers();
+   check_supported_timers();
 
if (unshare_timens())
return 1;
diff --git a/tools/testing/selftests/timens/timens.c 
b/tools/testing/selftests/timens/timens.c
index 098be7c83be3..52b6a1185f52 100644
--- a/tools/testing/selftests/timens/timens.c
+++ b/tools/testing/selftests/timens/timens.c
@@ -155,7 +155,7 @@ int main(int argc, char *argv[])
 
nscheck();
 
-   check_config_posix_timers();
+   check_supported_timers();
 
ksft_set_plan(ARRAY_SIZE(clocks) * 2);
 
diff --git a/tools/testing/selftests/timens/timens.h 
b/tools/testing/selftests/timens/timens.h
index e09e7e39bc52..d4fc52d47146 100644
--- a/tools/testing/selftests/timens/timens.h
+++ b/tools/testing/selftests/timens/timens.h
@@ -14,15 +14,26 @@
 #endif
 
 static int config_posix_timers = true;
+static int config_alarm_timers = true;
 
-static inline void check_config_posix_timers(void)
+static inline void check_supported_timers(void)
 {
+   struct timespec ts;
+
if (timer_create(-1, 0, 0) == -1 && errno == ENOSYS)
config_posix_timers = false;
+
+   if (clock_gettime(CLOCK_BOOTTIME_ALARM, &ts) == -1 && errno == EINVAL)
+   config_alarm_timers = false;
 }
 
 static inline bool check_skip(int clockid)
 {
+   if (!config_alarm_timers && clockid == CLOCK_BOOTTIME_ALARM) {
+   ksft_test_result_skip("CLOCK_BOOTTIME_ALARM isn't supported\n");
+   return true;
+   }
+
if (config_posix_timers)
return false;
 
diff --git a/tools/testing/selftests/timens/timer.c 
b/tools/testing/selftests/timens/timer.c
index 96dba11ebe44..5e7f0051bd7b 100644
--- a/tools/testing/selftests/timens/timer.c
+++ b/tools/testing/selftests/timens/timer.c
@@ -22,6 +22,9 @@ int run_test(int clockid, struct timespec now)
timer_t fd;
int i;
 
+   if (check_skip(clockid))
+   return 0;
+
for (i = 0; i < 2; i++) {
struct sigevent sevp = {.sigev_notify = SIGEV_NONE};
int flags = 0;
@@ -74,6 +77,8 @@ int main(int argc, char *argv[])
 
nscheck();
 
+   check_supported_timers();
+
ksft_set_plan(3);
 
clock_gettime(CLOCK_MONOTONIC, &mtime_now);
diff --git a/tools/testing/selftests/timens/timerfd.c 
b/tools/testing/selftests/timens/timerfd.c
index eff1ec5ff215..9edd43d6b2c1 100644
--- a/tools/testing/selftests/timens/timerfd.c
+++ b/tools/testing/selftests/timens/timerfd.c
@@ -28,6 +28,9 @@ int run_test(int clockid, struct timespec now)
long long elapsed;
int fd, i;
 
+   if (check_skip(clockid))
+   return 0;
+
if (tclock_gettime(clockid, &now))
return pr_perror("clock_gettime(%d)", clockid);
 
@@ -81,6 +84,8 @@ int main(int argc, char *argv[])
 
nscheck();
 
+   check_supported_timers();
+
ksft_set_plan(3);
 
clock_gettime(CLOCK_MONOTONIC, &mtime_now);
-- 
2.24.1

Re: [PATCH 0/3] tracing/kprobes: Fix event generation API etc.

[Masami Hiramatsu]

On Wed, 20 May 2020 10:40:05 -0400
Steven Rostedt  wrote:

> On Wed, 20 May 2020 10:33:46 -0400
> Steven Rostedt  wrote:
> 
> > On Wed, 20 May 2020 23:22:20 +0900
> > Masami Hiramatsu  wrote:
> > 
> > > Hi Steve,
> > > 
> > > It seems this fixes are not picked up yet.
> > > Would you have any consideration?
> > >   
> > 
> > 
> > Ah, I missed your reply to my comment :-/
> > 
> > Yeah, I'll pull that in now and start testing it.
> > 
> > Thanks for the reminder.
> 
> No, it's already in mainline:
> 
> Merged: 192ffb7515839b1cc8457e0a8c1e09783de019d3
> 
> With commits:
> 
>  dcbd21c9fca5e954fd4e3d91884907eb6d47187e
>  da0f1f4167e3af69e1d8b32d6d65195ddd2bfb64
>  5b4dcd2d201a395ad4054067bfae4a07554fbd65

Oops, I must have checked another branch. Sorry.

Thank you!

-- 
Masami Hiramatsu 

RE: [PATCH] e1000e: Relax condition to trigger reset for ME workaround

[Brown, Aaron F]

> From: netdev-ow...@vger.kernel.org  On
> Behalf Of Punit Agrawal
> Sent: Thursday, May 14, 2020 9:31 PM
> To: Kirsher, Jeffrey T 
> Cc: daniel.sangor...@toshiba.co.jp; Punit Agrawal
> ; Alexander Duyck
> ; David S. Miller ;
> intel-wired-...@lists.osuosl.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] e1000e: Relax condition to trigger reset for ME workaround
> 
> It's an error if the value of the RX/TX tail descriptor does not match
> what was written. The error condition is true regardless the duration
> of the interference from ME. But the driver only performs the reset if
> E1000_ICH_FWSM_PCIM2PCI_COUNT (2000) iterations of 50us delay have
> transpired. The extra condition can lead to inconsistency between the
> state of hardware as expected by the driver.
> 
> Fix this by dropping the check for number of delay iterations.
> 
> While at it, also make __ew32_prepare() static as it's not used
> anywhere else.
> 
> Signed-off-by: Punit Agrawal 
> Reviewed-by: Alexander Duyck 
> Cc: Jeff Kirsher 
> Cc: "David S. Miller" 
> Cc: intel-wired-...@lists.osuosl.org
> Cc: net...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> Hi Jeff,
> 
> If there are no further comments please consider merging the patch.
> 
> Also, should it be marked for backport to stable?
> 
> Thanks,
> Punit
> 
> RFC[0] -> v1:
> * Dropped return value for __ew32_prepare() as it's not used
> * Made __ew32_prepare() static
> * Added tags
> 
> [0] https://lkml.org/lkml/2020/5/12/20
> 
>  drivers/net/ethernet/intel/e1000e/e1000.h  |  1 -
>  drivers/net/ethernet/intel/e1000e/netdev.c | 12 +---
>  2 files changed, 5 insertions(+), 8 deletions(-)
> 
Tested-by: Aaron Brown 

Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support

[Will Deacon]

On Thu, May 21, 2020 at 09:34:10AM +0200, Arnd Bergmann wrote:
> On Thu, May 21, 2020 at 9:07 AM Sudeep Holla  wrote:
> > On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote:
> > > On Wed, May 20, 2020 at 11:29 PM Will Deacon  wrote:
> > > > Applied to arm64 (for-next/smccc), thanks!
> > > >
> > > > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable 
> > > > to me,
> > > > but please shout if you'd rather I dropped this in order to pursue an
> > > > alternative approach.
> > >
> > > I missed the reply earlier, thanks for pointing me to it again.

D'oh, I took your silence as "no objections". Oh well!

> > > I'm not entirely convinced, but don't revert it for now because of that,
> > > I assume we can find a solution.

Ok, cheers. It's on a separate branch so it's easy enough to drop if
necessary (i.e. no reverts needed). Sudeep -- please send any extra patches
on top of the branch.

> > I liked your idea of making this generic and hardcode values if required
> > for other drivers. I will take a look at that/
> >
> > > However, please have a look at the build failure report for patch 5
> > > and fix it if you can see what went wrong.
> > >
> >
> > Any pointers for that failure ? I seem to have missed them. I pushed
> > branch couple of times to my tree but got build success both times.
> > Any specific config or compilers ?
> 
> See below for the reply from the 0day build bot to your email. It seems it
> was not sent to the mailing list, but you were on Cc. Looking at it now,
> the fix should be trivial.

[...]

> >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for 
> >> function 'arm_smccc_version_init' [-Wmissing-prototypes]
> void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit 
> conduit)
> ^
> drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the
> function is not intended to be used outside of this translation unit
> void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit 
> conduit)

I saw that when I applied the patches, but since the function is called from
another compilation unit (psci/psci.o), I just ignored it as we have loads
of these already and it only screams if you build with W=1.

Will

[PATCH] spi: tegra114: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/spi/spi-tegra114.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
index 83edabdb41ad..5b3faa29f945 100644
--- a/drivers/spi/spi-tegra114.c
+++ b/drivers/spi/spi-tegra114.c
@@ -1398,6 +1398,7 @@ static int tegra_spi_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0) {
dev_err(&pdev->dev, "pm runtime get failed, e = %d\n", ret);
+   pm_runtime_put(&pdev->dev);
goto exit_pm_disable;
}
 
-- 
2.17.1

RE: remove kernel_setsockopt and kernel_getsockopt v2

[David Laight]

From: Christoph Hellwig
> Sent: 20 May 2020 20:55
> 
> this series removes the kernel_setsockopt and kernel_getsockopt
> functions, and instead switches their users to small functions that
> implement setting (or in one case getting) a sockopt directly using
> a normal kernel function call with type safety and all the other
> benefits of not having a function call.
> 
> In some cases these functions seem pretty heavy handed as they do
> a lock_sock even for just setting a single variable, but this mirrors
> the real setsockopt implementation unlike a few drivers that just set
> set the fields directly.

How much does this increase the kernel code by?

You are also replicating a lot of code making it more
difficult to maintain.

I don't think the performance of an socket option code
really matters - it is usually done once when a socket
is initialised and the other costs of establishing a
connection will dominate.

Pulling the user copies outside the [gs]etsocksopt switch
statement not only reduces the code size (source and object)
and trivially allows kernel_[sg]sockopt() to me added to
the list of socket calls.

It probably isn't possible to pull the usercopies right
out into the syscall wrapper because of some broken
requests.

I worried about whether getsockopt() should read the entire
user buffer first. SCTP needs the some of it often (including a
sockaddr_storage in one case), TCP needs it once.
However the cost of reading a few words is small, and a big
buffer probably needs setting to avoid leaking kernel
memory if the structure has holes or fields that don't get set.
Reading from userspace solves both issues.

David

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

[PATCH] watchdog: Fix runtime PM imbalance on error

[Dinghao Liu]

When watchdog_register_device() returns an error code,
a pairing runtime PM usage counter decrement is needed
to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/watchdog/omap_wdt.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/watchdog/omap_wdt.c b/drivers/watchdog/omap_wdt.c
index 9b91882fe3c4..1616f93dfad7 100644
--- a/drivers/watchdog/omap_wdt.c
+++ b/drivers/watchdog/omap_wdt.c
@@ -273,6 +273,7 @@ static int omap_wdt_probe(struct platform_device *pdev)
 
ret = watchdog_register_device(&wdev->wdog);
if (ret) {
+   pm_runtime_put(wdev->dev);
pm_runtime_disable(wdev->dev);
return ret;
}
-- 
2.17.1

[PATCH v4] PCI: cadence: Use "dma-ranges" instead of "cdns,no-bar-match-nbits" property

[Kishon Vijay Abraham I]

Cadence PCIe core driver (host mode) uses "cdns,no-bar-match-nbits"
property to configure the number of bits passed through from PCIe
address to internal address in Inbound Address Translation register.
This only used the NO MATCH BAR.

However standard PCI dt-binding already defines "dma-ranges" to
describe the address ranges accessible by PCIe controller. Add support
in Cadence PCIe host driver to parse dma-ranges and configure the
inbound regions for BAR0, BAR1 and NO MATCH BAR. Cadence IP specifies
maximum size for BAR0 as 256GB, maximum size for BAR1 as 2 GB.

This adds support to take the next biggest region in "dma-ranges" and
find the smallest BAR that each of the regions fit in and if there is
no BAR big enough to hold the region, split the region to see if it can
be fitted using multiple BARs.

"dma-ranges" of J721E will be
dma-ranges = <0x0200 0x0 0x0 0x0 0x0 0x1 0x0>;
Since there is no BAR which can hold 2^48 size, NO_MATCH_BAR will be
used here.

Legacy device tree binding compatibility is maintained by retaining
support for "cdns,no-bar-match-nbits".

Signed-off-by: Kishon Vijay Abraham I 
---
The previous version of the patch can be found @
https://lore.kernel.org/linux-arm-kernel/20200508130646.23939-5-kis...@ti.com/

Changes from v3:
*) The whole logic of how we select a BAR to fit a region from
dma-ranges has been changed.
  1) First select the biggest region in "dma-ranges" (after combining
 adjacent regions)
  2) Try to fit this region in a smallest available BAR whose size is
 greater than the region size
  3) If no such BAR is available try to find biggest availalbe BAR
 whose size is lesser than the region size and only fit part of the
 region in that BAR.
  4) Repeat steps 3 and 4, to fit the remaining region size.
 .../controller/cadence/pcie-cadence-host.c| 254 +-
 drivers/pci/controller/cadence/pcie-cadence.h |  28 +-
 2 files changed, 265 insertions(+), 17 deletions(-)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-host.c 
b/drivers/pci/controller/cadence/pcie-cadence-host.c
index 6ecebb79057a..cf8b34b71b8f 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-host.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-host.c
@@ -11,6 +11,12 @@
 
 #include "pcie-cadence.h"
 
+static u64 bar_max_size[] = {
+   [RP_BAR0] = _ULL(128 * SZ_2G),
+   [RP_BAR1] = SZ_2G,
+   [RP_NO_BAR] = _BITULL(63),
+};
+
 void __iomem *cdns_pci_map_bus(struct pci_bus *bus, unsigned int devfn,
   int where)
 {
@@ -106,6 +112,226 @@ static int cdns_pcie_host_init_root_port(struct 
cdns_pcie_rc *rc)
return 0;
 }
 
+static int cdns_pcie_host_bar_ib_config(struct cdns_pcie_rc *rc,
+   enum cdns_pcie_rp_bar bar,
+   u64 cpu_addr, u64 size,
+   unsigned long flags)
+{
+   struct cdns_pcie *pcie = &rc->pcie;
+   u32 addr0, addr1, aperture, value;
+
+   if (!rc->avail_ib_bar[bar])
+   return -EBUSY;
+
+   rc->avail_ib_bar[bar] = false;
+
+   aperture = ilog2(size);
+   addr0 = CDNS_PCIE_AT_IB_RP_BAR_ADDR0_NBITS(aperture) |
+   (lower_32_bits(cpu_addr) & GENMASK(31, 8));
+   addr1 = upper_32_bits(cpu_addr);
+   cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_RP_BAR_ADDR0(bar), addr0);
+   cdns_pcie_writel(pcie, CDNS_PCIE_AT_IB_RP_BAR_ADDR1(bar), addr1);
+
+   if (bar == RP_NO_BAR)
+   return 0;
+
+   value = cdns_pcie_readl(pcie, CDNS_PCIE_LM_RC_BAR_CFG);
+   if (size + cpu_addr >= SZ_4G) {
+   if (!(flags & IORESOURCE_PREFETCH))
+   value |= LM_RC_BAR_CFG_CTRL_MEM_64BITS(bar);
+   value |= LM_RC_BAR_CFG_CTRL_PREF_MEM_64BITS(bar);
+   } else {
+   if (!(flags & IORESOURCE_PREFETCH))
+   value |= LM_RC_BAR_CFG_CTRL_MEM_32BITS(bar);
+   value |= LM_RC_BAR_CFG_CTRL_PREF_MEM_32BITS(bar);
+   }
+
+   value |= LM_RC_BAR_CFG_APERTURE(bar, aperture);
+   cdns_pcie_writel(pcie, CDNS_PCIE_LM_RC_BAR_CFG, value);
+
+   return 0;
+}
+
+static enum cdns_pcie_rp_bar
+cdns_pcie_host_find_min_bar(struct cdns_pcie_rc *rc, u64 size)
+{
+   enum cdns_pcie_rp_bar bar, sel_bar;
+
+   sel_bar = RP_BAR_UNDEFINED;
+   for (bar = RP_BAR0; bar <= RP_NO_BAR; bar++) {
+   if (!rc->avail_ib_bar[bar])
+   continue;
+
+   if (size <= bar_max_size[bar]) {
+   if (sel_bar == RP_BAR_UNDEFINED) {
+   sel_bar = bar;
+   continue;
+   }
+
+   if (bar_max_size[bar] < bar_max_size[sel_bar])
+   sel_bar = bar;
+   }
+   }
+
+   return sel_bar;
+}
+
+static enum cdns_pcie_rp_bar
+cdns_pcie_host_find_max_bar(struct cdns_pcie_rc *rc, u64 size)
+{
+

Re: [PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally

[Xiaoyao Li]

On 5/21/2020 12:56 AM, Maxim Levitsky wrote:

On Wed, 2020-05-20 at 18:33 +0200, Vitaly Kuznetsov wrote:

Maxim Levitsky  writes:


This msr is only available when the host supports WAITPKG feature.

This breaks a nested guest, if the L1 hypervisor is set to ignore
unknown msrs, because the only other safety check that the
kernel does is that it attempts to read the msr and
rejects it if it gets an exception.

Fixes: 6e3ba4abce KVM: vmx: Emulate MSR IA32_UMWAIT_CONTROL

Signed-off-by: Maxim Levitsky 
---
  arch/x86/kvm/x86.c | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index fe3a24fd6b263..9c507b32b1b77 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -5314,6 +5314,10 @@ static void kvm_init_msr_list(void)
if (msrs_to_save_all[i] - MSR_ARCH_PERFMON_EVENTSEL0 >=
min(INTEL_PMC_MAX_GENERIC, x86_pmu.num_counters_gp))
continue;
+   break;
+   case MSR_IA32_UMWAIT_CONTROL:
+   if (!kvm_cpu_cap_has(X86_FEATURE_WAITPKG))
+   continue;


I'm probably missing something but (if I understand correctly) the only
effect of dropping MSR_IA32_UMWAIT_CONTROL from msrs_to_save would be
that KVM userspace won't see it in e.g. KVM_GET_MSR_INDEX_LIST. But why
is this causing an issue? I see both vmx_get_msr()/vmx_set_msr() have
'host_initiated' check:

case MSR_IA32_UMWAIT_CONTROL:
 if (!msr_info->host_initiated && !vmx_has_waitpkg(vmx))
 return 1;


Here it fails like that:

1. KVM_GET_MSR_INDEX_LIST returns this msrs, and qemu notes that
it is supported in 'has_msr_umwait' global var


In general, KVM_GET_MSR_INDEX_LIST won't return MSR_IA32_UMWAIT_CONTROL 
if KVM cannot read this MSR, see kvm_init_msr_list().


You hit issue because you used "ignore_msrs".

Re: [PATCH] spi: tegra20-slink: Fix runtime PM imbalance on error

[Andy Shevchenko]

On Thu, May 21, 2020 at 10:50 AM Dinghao Liu  wrote:
>
> pm_runtime_get_sync() increments the runtime PM usage counter even
> when it returns an error code. Thus a pairing decrement is needed on
> the error handling path to keep the counter balanced.

...

> ret = pm_runtime_get_sync(&pdev->dev);
> if (ret < 0) {
> dev_err(&pdev->dev, "pm runtime get failed, e = %d\n", ret);

> +   pm_runtime_put(&pdev->dev);

For all your patches, please, double check what you are proposing.

Here, I believe, the correct one will be _put_noidle().

AFAIU you are not supposed to actually suspend the device in case of error.
But I might be mistaken, thus see above.

> goto exit_pm_disable;
> }

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support

[Sudeep Holla]

On Thu, May 21, 2020 at 09:34:10AM +0200, Arnd Bergmann wrote:
> On Thu, May 21, 2020 at 9:07 AM Sudeep Holla  wrote:
> >
> > On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote:
> > > On Wed, May 20, 2020 at 11:29 PM Will Deacon  wrote:
> > > >
> > > > On Mon, 18 May 2020 10:12:15 +0100, Sudeep Holla wrote:
> > > > > This patch series adds support for SMCCCv1.2 ARCH_SOC_ID.
> > > > > This doesn't add other changes added in SMCCC v1.2 yet. They will
> > > > > follow these soon along with its first user SPCI/PSA-FF.
> > > > >
> > > > > This is tested using upstream TF-A + the patch[3] fixing the original
> > > > > implementation there.
> > > > >
> > > > > [...]
> > > >
> > > > Applied to arm64 (for-next/smccc), thanks!
> > > >
> > > > [1/7] firmware: smccc: Add HAVE_ARM_SMCCC_DISCOVERY to identify SMCCC 
> > > > v1.1 and above
> > > >   https://git.kernel.org/arm64/c/e5bfb21d98b6
> > > > [2/7] firmware: smccc: Update link to latest SMCCC specification
> > > >   https://git.kernel.org/arm64/c/15c704ab6244
> > > > [3/7] firmware: smccc: Add the definition for SMCCCv1.2 version/error 
> > > > codes
> > > >   https://git.kernel.org/arm64/c/0441bfe7f00a
> > > > [4/7] firmware: smccc: Drop smccc_version enum and use 
> > > > ARM_SMCCC_VERSION_1_x instead
> > > >   https://git.kernel.org/arm64/c/ad5a57dfe434
> > > > [5/7] firmware: smccc: Refactor SMCCC specific bits into separate file
> > > >   https://git.kernel.org/arm64/c/f2ae97062a48
> > > > [6/7] firmware: smccc: Add function to fetch SMCCC version
> > > >   https://git.kernel.org/arm64/c/a4fb17465182
> > > > [7/7] firmware: smccc: Add ARCH_SOC_ID support
> > > >   https://git.kernel.org/arm64/c/ce6488f0ce09
> > > >
> > > > Arnd -- Sudeep's reply to you about the sysfs groups seemed reasonable 
> > > > to me,
> > > > but please shout if you'd rather I dropped this in order to pursue an
> > > > alternative approach.
> > >
> > > I missed the reply earlier, thanks for pointing me to it again.
> > >
> > > I'm not entirely convinced, but don't revert it for now because of that,
> > > I assume we can find a solution.
> > >
> >
> > I liked your idea of making this generic and hardcode values if required
> > for other drivers. I will take a look at that/
> >
> > > However, please have a look at the build failure report for patch 5
> > > and fix it if you can see what went wrong.
> > >
> >
> > Any pointers for that failure ? I seem to have missed them. I pushed
> > branch couple of times to my tree but got build success both times.
> > Any specific config or compilers ?
> 
> See below for the reply from the 0day build bot to your email. It seems it
> was not sent to the mailing list, but you were on Cc. Looking at it now,
> the fix should be trivial.
> 

Ah, clang it is. I must start building with clang regularly.
Thanks for pointing it out. Somehow few of these kbuild-bot emails
has been marked junk last few days. Sorry for the noise.

-- 
Regards,
Sudeep

[PATCH] dmaengine: tegra210-adma: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/dma/tegra210-adma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
index c4ce5dfb149b..8f5e4949d720 100644
--- a/drivers/dma/tegra210-adma.c
+++ b/drivers/dma/tegra210-adma.c
@@ -870,7 +870,7 @@ static int tegra_adma_probe(struct platform_device *pdev)
 
ret = pm_runtime_get_sync(&pdev->dev);
if (ret < 0)
-   goto rpm_disable;
+   goto rpm_put;
 
ret = tegra_adma_init(tdma);
if (ret)
@@ -921,7 +921,6 @@ static int tegra_adma_probe(struct platform_device *pdev)
dma_async_device_unregister(&tdma->dma_dev);
 rpm_put:
pm_runtime_put_sync(&pdev->dev);
-rpm_disable:
pm_runtime_disable(&pdev->dev);
 irq_dispose:
while (--i >= 0)
-- 
2.17.1

Re: [PATCH] spi: tegra20-slink: Fix runtime PM imbalance on error

[Andy Shevchenko]

On Thu, May 21, 2020 at 11:04 AM Andy Shevchenko
 wrote:
> On Thu, May 21, 2020 at 10:50 AM Dinghao Liu  wrote:

Any I have coccinelle script for this, I can share with you.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 08/10] swiotlb-xen: introduce phys_to_dma/dma_to_phys translations

[Julien Grall]

Hi,

On 21/05/2020 00:45, Stefano Stabellini wrote:

From: Stefano Stabellini 

Call dma_to_phys in is_xen_swiotlb_buffer.
Call phys_to_dma in xen_phys_to_bus.
Call dma_to_phys in xen_bus_to_phys.

Everything is taken care of by these changes except for
xen_swiotlb_alloc_coherent and xen_swiotlb_free_coherent, which need a
few explicit phys_to_dma/dma_to_phys calls.


The commit message explains what the code is doing but doesn't explain 
why this is needed.




Signed-off-by: Stefano Stabellini 
---
  drivers/xen/swiotlb-xen.c | 20 
  1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index c50448fd9b75..d011c4c7aa72 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -64,14 +64,16 @@ static inline dma_addr_t xen_phys_to_bus(struct device 
*dev, phys_addr_t paddr)
  
  	dma |= paddr & ~XEN_PAGE_MASK;
  
-	return dma;

+   return phys_to_dma(dev, dma);
  }
  
-static inline phys_addr_t xen_bus_to_phys(struct device *dev, dma_addr_t baddr)

+static inline phys_addr_t xen_bus_to_phys(struct device *dev,
+ dma_addr_t dma_addr)
  {
+   phys_addr_t baddr = dma_to_phys(dev, dma_addr);
unsigned long xen_pfn = bfn_to_pfn(XEN_PFN_DOWN(baddr));
-   dma_addr_t dma = (dma_addr_t)xen_pfn << XEN_PAGE_SHIFT;
-   phys_addr_t paddr = dma;
+   phys_addr_t paddr = (xen_pfn << XEN_PAGE_SHIFT) |
+   (baddr & ~XEN_PAGE_MASK);
  
  	paddr |= baddr & ~XEN_PAGE_MASK;
  
@@ -99,7 +101,7 @@ static inline int range_straddles_page_boundary(phys_addr_t p, size_t size)
  
  static int is_xen_swiotlb_buffer(struct device *dev, dma_addr_t dma_addr)

  {
-   unsigned long bfn = XEN_PFN_DOWN(dma_addr);
+   unsigned long bfn = XEN_PFN_DOWN(dma_to_phys(dev, dma_addr));
unsigned long xen_pfn = bfn_to_local_pfn(bfn);
phys_addr_t paddr = XEN_PFN_PHYS(xen_pfn);
  
@@ -304,11 +306,11 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t size,

if (hwdev && hwdev->coherent_dma_mask)
dma_mask = hwdev->coherent_dma_mask;
  
-	/* At this point dma_handle is the physical address, next we are

+   /* At this point dma_handle is the dma address, next we are
 * going to set it to the machine address.
 * Do not use virt_to_phys(ret) because on ARM it doesn't correspond
 * to *dma_handle. */
-   phys = *dma_handle;
+   phys = dma_to_phys(hwdev, *dma_handle);
dev_addr = xen_phys_to_bus(hwdev, phys);
if (((dev_addr + size - 1 <= dma_mask)) &&
!range_straddles_page_boundary(phys, size))
@@ -319,6 +321,7 @@ xen_swiotlb_alloc_coherent(struct device *hwdev, size_t 
size,
xen_free_coherent_pages(hwdev, size, ret, 
(dma_addr_t)phys, attrs);
return NULL;
}
+   *dma_handle = phys_to_dma(hwdev, *dma_handle);
SetPageXenRemapped(virt_to_page(ret));
}
memset(ret, 0, size);
@@ -351,7 +354,8 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
TestClearPageXenRemapped(pg))
xen_destroy_contiguous_region(phys, order);
  
-	xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);

+   xen_free_coherent_pages(hwdev, size, vaddr, phys_to_dma(hwdev, phys),
+   attrs);
  }
  
  /*




Cheers,

--
Julien Grall

Re: [PATCH 02/10] swiotlb-xen: remove start_dma_addr

[Julien Grall]

Hi,

On 21/05/2020 00:45, Stefano Stabellini wrote:

From: Stefano Stabellini 

It is not strictly needed. Call virt_to_phys on xen_io_tlb_start
instead. It will be useful not to have a start_dma_addr around with the
next patches.

Signed-off-by: Stefano Stabellini 
---
  drivers/xen/swiotlb-xen.c | 5 +
  1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index a42129cba36e..b5e0492b07b9 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -52,8 +52,6 @@ static unsigned long xen_io_tlb_nslabs;
   * Quick lookup value of the bus address of the IOTLB.
   */
  
-static u64 start_dma_addr;

-
  /*
   * Both of these functions should avoid XEN_PFN_PHYS because phys_addr_t
   * can be 32bit when dma_addr_t is 64bit leading to a loss in
@@ -241,7 +239,6 @@ int __ref xen_swiotlb_init(int verbose, bool early)
m_ret = XEN_SWIOTLB_EFIXUP;
goto error;
}
-   start_dma_addr = xen_virt_to_bus(xen_io_tlb_start);
if (early) {
if (swiotlb_init_with_tbl(xen_io_tlb_start, xen_io_tlb_nslabs,
 verbose))
@@ -389,7 +386,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 */
trace_swiotlb_bounced(dev, dev_addr, size, swiotlb_force);
  
-	map = swiotlb_tbl_map_single(dev, start_dma_addr, phys,

+   map = swiotlb_tbl_map_single(dev, virt_to_phys(xen_io_tlb_start), phys,


xen_virt_to_bus() is implemented as xen_phys_to_bus(virt_to_phys()). Can 
you explain how the two are equivalent?


Cheers,

--
Julien Grall

Re: [PATCH 01/10] swiotlb-xen: use vmalloc_to_page on vmalloc virt addresses

[Julien Grall]

Hi,

On 21/05/2020 00:45, Stefano Stabellini wrote:

From: Boris Ostrovsky 

Don't just assume that virt_to_page works on all virtual addresses.
Instead add a is_vmalloc_addr check and use vmalloc_to_page on vmalloc
virt addresses.


Can you provide an example where swiotlb is used with vmalloc()?


Signed-off-by: Boris Ostrovsky 
Signed-off-by: Stefano Stabellini 
---
  drivers/xen/swiotlb-xen.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index b6d27762c6f8..a42129cba36e 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -335,6 +335,7 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
int order = get_order(size);
phys_addr_t phys;
u64 dma_mask = DMA_BIT_MASK(32);
+   struct page *pg;
  
  	if (hwdev && hwdev->coherent_dma_mask)

dma_mask = hwdev->coherent_dma_mask;
@@ -346,9 +347,11 @@ xen_swiotlb_free_coherent(struct device *hwdev, size_t 
size, void *vaddr,
/* Convert the size to actually allocated. */
size = 1UL << (order + XEN_PAGE_SHIFT);
  
+	pg = is_vmalloc_addr(vaddr) ? vmalloc_to_page(vaddr) :

+ virt_to_page(vaddr);


Common DMA code seems to protect this check with CONFIG_DMA_REMAP. Is it 
something we want to do it here as well? Or is there any other condition 
where vmalloc can happen?



if (!WARN_ON((dev_addr + size - 1 > dma_mask) ||
 range_straddles_page_boundary(phys, size)) &&
-   TestClearPageXenRemapped(virt_to_page(vaddr)))
+   TestClearPageXenRemapped(pg))
xen_destroy_contiguous_region(phys, order);
  
  	xen_free_coherent_pages(hwdev, size, vaddr, (dma_addr_t)phys, attrs);




Cheers,

--
Julien Grall

Re: [PATCH v5 09/19] mtd: spi-nor: sfdp: parse xSPI Profile 1.0 table

[masonccyang]

Hi Pratyush, 

> > 
> > > > > +/**
> > > > > + * spi_nor_parse_profile1() - parse the xSPI Profile 1.0 table
> > > > > + * @nor:  pointer to a 'struct spi_nor'
> > > > > + * @param_header:   pointer to the 'struct 
sfdp_parameter_header' 
> > > > describing
> > > > > + * the 4-Byte Address Instruction Table length and 
version.
> > > > > + * @params:  pointer to the 'struct 
spi_nor_flash_parameter' to 
> > be.
> > > > > + *
> > > > > + * Return: 0 on success, -errno otherwise.
> > > > > + */
> > > > > +static int spi_nor_parse_profile1(struct spi_nor *nor,
> > > > > +  const struct sfdp_parameter_header 
*profile1_header,
> > > > > +  struct spi_nor_flash_parameter *params)
> > > > > +{
> > > > > +   u32 *table, opcode, addr;
> > > > > +   size_t len;
> > > > > +   int ret, i;
> > > > > +
> > > > > +   len = profile1_header->length * sizeof(*table);
> > > > > +   table = kmalloc(len, GFP_KERNEL);
> > > > > +   if (!table)
> > > > > +  return -ENOMEM;
> > > > > +
> > > > > +   addr = SFDP_PARAM_HEADER_PTP(profile1_header);
> > > > > +   ret = spi_nor_read_sfdp(nor, addr, len, table);
> > > > > +   if (ret)
> > > > > +  goto out;
> > > > > +
> > > > > +   /* Fix endianness of the table DWORDs. */
> > > > > +   for (i = 0; i < profile1_header->length; i++)
> > > > > +  table[i] = le32_to_cpu(table[i]);
> > > > > +
> > > > > +   /* Get 8D-8D-8D fast read opcode and dummy cycles. */
> > > > > +   opcode = FIELD_GET(PROFILE1_DWORD1_RD_FAST_CMD, table[0]);
> > > > > +
> > > > > +   /*
> > > > > +* Update the fast read settings. We set the default dummy 
> > cycles to 
> > > > 20
> > > > > +* here. Flashes can change this value if they need to when 
> > enabling
> > > > > +* octal mode.
> > > > > +*/
> > > > > + 
spi_nor_set_read_settings(¶ms->reads[SNOR_CMD_READ_8_8_8_DTR],
> > > > > +  0, 20, opcode,
> > > > > +  SNOR_PROTO_8_8_8_DTR);
> > > > > +
> > > > 
> > > > 
> > > > I thought we have a agreement that only do parse here, no other 
read 
> > > > parameters setting.
> > > 
> > > Yes, and I considered it. But it didn't make much sense to me to 
> > > introduce an extra member in struct spi_nor just to make this call 
in 
> > > some other function later.
> > > 
> > > Why exactly do you think doing this here is bad? The way I see it, 
we 
> > > avoid carrying around an extra member in spi_nor and this also 
allows 
> > > flashes to change the read settings easily in a post-sfdp hook. The 
> > > 4bait parsing function does something similar.
> > 
> > I think it's not a question for good or bad. 
> > 
> > 4bait parsing function parse the 4-Byte Address Instruction Table
> > and set up read/pp parameters there for sure.
> > 
> > Here we give the function name spi_nor_parse_profile1() but also 
> 
> But the function that parses 4bait table is also called 
> spi_nor_parse_4bait(). 
> 
> > do others setting that has nothing to do with it, 
> 
> Why has setting read opcode and dummy cycles got nothing to do with it? 
> The purpose of the Profile 1.0 table is to tell us the Read Fast command 

> and dummy cycles, among other things. I think it _does_ have something 
> to do with it.

As you know I mean this function just do parse parameter of profile 1 
table
and keep these value data for later usage.

A device supports xSPI profile table could work in either 8S-8S-8S or 
8D-8D-8D mode.
It seems to setup these parameters somewhere out here is betters.

> 
> Just like the 4bait table tells us the 4-byte opcodes and we set them up 

> in our data structures, the profile 1.0 table tells us the 8D read 
> opcode and dummy cycles, and we set them up in our data structures.
> 
> > it seems not good for SW module design. 
> > oh, it's my humble opinion.
> > 
> > > 
> > > What are the benefits of doing it otherwise?
> > 
> > For other Octal Flash like mx25*
> 
> I mean from a design perspective. How does it make the code better, or 
> the job of people who need to read/change it easier?

yes, agreed.
I also need to patch for 8S-8S-8S mode, not only 8D-8D-8D mode.
That's why we have some discussions.

thanks & best regards,
Mason

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=



=

Re: [PATCH v4 0/7] firmware: smccc: Add basic SMCCC v1.2 + ARCH_SOC_ID support

[Sudeep Holla]

On Thu, May 21, 2020 at 08:57:56AM +0100, Will Deacon wrote:
> On Thu, May 21, 2020 at 09:34:10AM +0200, Arnd Bergmann wrote:
> > On Thu, May 21, 2020 at 9:07 AM Sudeep Holla  wrote:
> > > On Wed, May 20, 2020 at 11:54:16PM +0200, Arnd Bergmann wrote:
> > > > On Wed, May 20, 2020 at 11:29 PM Will Deacon  wrote:
> > > > > Applied to arm64 (for-next/smccc), thanks!
> > > > >
> > > > > Arnd -- Sudeep's reply to you about the sysfs groups seemed 
> > > > > reasonable to me,
> > > > > but please shout if you'd rather I dropped this in order to pursue an
> > > > > alternative approach.
> > > >
> > > > I missed the reply earlier, thanks for pointing me to it again.
> 
> D'oh, I took your silence as "no objections". Oh well!
> 
> > > > I'm not entirely convinced, but don't revert it for now because of that,
> > > > I assume we can find a solution.
> 
> Ok, cheers. It's on a separate branch so it's easy enough to drop if
> necessary (i.e. no reverts needed). Sudeep -- please send any extra patches
> on top of the branch.
>

Indeed, it is also last patch in the series. However if Arnd is happy
with the sysfs names, we can move to generic code later without breaking
anything.

We need not revert or drop it now. I will leave that to you or Arnd to
decide. Just that it may be too late to get acks for all the soc sysfs
drivers in time for v5.8

I am fine if you want to drop the last patch.

> > > I liked your idea of making this generic and hardcode values if required
> > > for other drivers. I will take a look at that/
> > >
> > > > However, please have a look at the build failure report for patch 5
> > > > and fix it if you can see what went wrong.
> > > >
> > >
> > > Any pointers for that failure ? I seem to have missed them. I pushed
> > > branch couple of times to my tree but got build success both times.
> > > Any specific config or compilers ?
> > 
> > See below for the reply from the 0day build bot to your email. It seems it
> > was not sent to the mailing list, but you were on Cc. Looking at it now,
> > the fix should be trivial.
> 
> [...]
> 
> > >> drivers/firmware/smccc/smccc.c:14:13: warning: no previous prototype for 
> > >> function 'arm_smccc_version_init' [-Wmissing-prototypes]
> > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit 
> > conduit)
> > ^
> > drivers/firmware/smccc/smccc.c:14:1: note: declare 'static' if the
> > function is not intended to be used outside of this translation unit
> > void __init arm_smccc_version_init(u32 version, enum arm_smccc_conduit 
> > conduit)
> 
> I saw that when I applied the patches, but since the function is called from
> another compilation unit (psci/psci.o), I just ignored it as we have loads
> of these already and it only screams if you build with W=1.
> 

/me confused. Do you need the fix for this warning or you are happy to ignore?

-- 
Regards,
Sudeep

Re: io_uring vs CPU hotplug, was Re: [PATCH 5/9] blk-mq: don't set data->ctx and data->hctx in blk_mq_alloc_request_hctx

[Thomas Gleixner]

Ming Lei  writes:
> On Thu, May 21, 2020 at 12:14:18AM +0200, Thomas Gleixner wrote:
>> When the CPU is finally offlined, i.e. the CPU cleared the online bit in
>> the online mask is definitely too late simply because it still runs on
>> that outgoing CPU _after_ the hardware queue is shut down and drained.
>
> IMO, the patch in Christoph's blk-mq-hotplug.2 still works for percpu
> kthread.
>
> It is just not optimal in the retrying, but it should be fine. When the
> percpu kthread is scheduled on the CPU to be offlined:
>
> - if the kthread doesn't observe the INACTIVE flag, the allocated request
> will be drained.
>
> - otherwise, the kthread just retries and retries to allocate & release,
> and sooner or later, its time slice is consumed, and migrated out, and the
> cpu hotplug handler will get chance to run and move on, then the cpu is
> shutdown.

1) This is based on the assumption that the kthread is in the SCHED_OTHER
   scheduling class. Is that really a valid assumption?

2) What happens in the following scenario:

   unplug

 mq_offline
   set_ctx_inactive()
   drain_io()
   
   io_kthread()
   try_queue()
   wait_on_ctx()

   Can this happen and if so what will wake up that thread?

I'm not familiar enough with that code to answer #2, but this really
wants to be properly described and documented.

Thanks,

tglx

[GIT PULL] Immutable branch between MFD, Power and RTC due for the v5.8 merge window

[Lee Jones]

Enjoy!

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git 
ib-mfd-power-rtc-v5.8

for you to fetch changes up to 29ee40091e27615530c0ba7773a2879d8266381e:

  rtc: mt6397: Add support for the MediaTek MT6358 RTC (2020-05-21 08:55:48 
+0100)


Immutable branch between MFD, Power and RTC due for the v5.8 merge window


Hsin-Hsiung Wang (4):
  mfd: mt6397: Modify suspend/resume behavior
  mfd: mt6397: Trim probe function to support different chips more cleanly
  dt-bindings: mfd: Add compatible for the MediaTek MT6358 PMIC
  mfd: Add support for the MediaTek MT6358 PMIC

Ran Bi (1):
  rtc: mt6397: Add support for the MediaTek MT6358 RTC

 Documentation/devicetree/bindings/mfd/mt6397.txt |  14 +-
 drivers/mfd/Makefile |   2 +-
 drivers/mfd/mt6358-irq.c | 235 +++
 drivers/mfd/mt6397-core.c| 101 
 drivers/mfd/mt6397-irq.c |  35 ++-
 drivers/power/reset/mt6323-poweroff.c|   2 +-
 drivers/rtc/rtc-mt6397.c |  18 +-
 include/linux/mfd/mt6358/core.h  | 158 +
 include/linux/mfd/mt6358/registers.h | 282 +++
 include/linux/mfd/mt6397/core.h  |   5 +
 include/linux/mfd/mt6397/rtc.h   |   9 +-
 11 files changed, 799 insertions(+), 62 deletions(-)
 create mode 100644 drivers/mfd/mt6358-irq.c
 create mode 100644 include/linux/mfd/mt6358/core.h
 create mode 100644 include/linux/mfd/mt6358/registers.h

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 1/3] bridge: mrp: Add br_mrp_unique_ifindex function

[Nikolay Aleksandrov]

On 20/05/2020 16:09, Horatiu Vultur wrote:
> It is not allow to have the same net bridge port part of multiple MRP
> rings. Therefore add a check if the port is used already in a different
> MRP. In that case return failure.
> 
> Fixes: 9a9f26e8f7ea ("bridge: mrp: Connect MRP API with the switchdev API")
> Signed-off-by: Horatiu Vultur 
> ---
>  net/bridge/br_mrp.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/net/bridge/br_mrp.c b/net/bridge/br_mrp.c
> index d7bc09de4c139..a5a3fa59c078a 100644
> --- a/net/bridge/br_mrp.c
> +++ b/net/bridge/br_mrp.c
> @@ -37,6 +37,32 @@ static struct br_mrp *br_mrp_find_id(struct net_bridge 
> *br, u32 ring_id)
>   return res;
>  }
>  
> +static bool br_mrp_unique_ifindex(struct net_bridge *br, u32 ifindex)
> +{
> + struct br_mrp *mrp;
> + bool res = true;
> +
> + rcu_read_lock();

Why do you need the rcu_read_lock() here when lockdep_rtnl_is_held() is used?
You should be able to just do rtnl_dereference() below as this is used only
under rtnl.

> + list_for_each_entry_rcu(mrp, &br->mrp_list, list,
> + lockdep_rtnl_is_held()) {
> + struct net_bridge_port *p;
> +
> + p = rcu_dereference(mrp->p_port);
> + if (p && p->dev->ifindex == ifindex) {
> + res = false;
> + break;
> + }
> +
> + p = rcu_dereference(mrp->s_port);
> + if (p && p->dev->ifindex == ifindex) {
> + res = false;
> + break;
> + }
> + }
> + rcu_read_unlock();
> + return res;
> +}
> +
>  static struct br_mrp *br_mrp_find_port(struct net_bridge *br,
>  struct net_bridge_port *p)
>  {
> @@ -255,6 +281,11 @@ int br_mrp_add(struct net_bridge *br, struct 
> br_mrp_instance *instance)
>   !br_mrp_get_port(br, instance->s_ifindex))
>   return -EINVAL;
>  
> + /* It is not possible to have the same port part of multiple rings */
> + if (!br_mrp_unique_ifindex(br, instance->p_ifindex) ||
> + !br_mrp_unique_ifindex(br, instance->s_ifindex))
> + return -EINVAL;
> +
>   mrp = kzalloc(sizeof(*mrp), GFP_KERNEL);
>   if (!mrp)
>   return -ENOMEM;
> 

Re: [PATCH v2] libata: Use per port sync for detach

[John Garry]

On 21/05/2020 05:30, Kai-Heng Feng wrote:

Commit 130f4caf145c ("libata: Ensure ata_port probe has completed before
detach") may cause system freeze during suspend.

Using async_synchronize_full() in PM callbacks is wrong, since async
callbacks that are already scheduled may wait for not-yet-scheduled
callbacks, causes a circular dependency.

Instead of using big hammer like async_synchronize_full(), use async
cookie to make sure port probe are synced, without affecting other
scheduled PM callbacks.



Apart from nit, it looks ok.

Cheers,
John


Fixes: 130f4caf145c ("libata: Ensure ata_port probe has completed before 
detach")
BugLink: https://bugs.launchpad.net/bugs/1867983
Suggested-by: John Garry 
Signed-off-by: Kai-Heng Feng 
---
v2:
  - Sync up to cookie + 1.
  - Squash the synchronization into the same loop.

  drivers/ata/libata-core.c | 9 -
  include/linux/libata.h| 3 +++
  2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index beca5f91bb4c..b6be84f2cecb 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -42,7 +42,6 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
  #include 
@@ -5778,7 +5777,7 @@ int ata_host_register(struct ata_host *host, struct 
scsi_host_template *sht)
/* perform each probe asynchronously */
for (i = 0; i < host->n_ports; i++) {
struct ata_port *ap = host->ports[i];
-   async_schedule(async_port_probe, ap);
+   ap->cookie = async_schedule(async_port_probe, ap);
}
  
  	return 0;

@@ -5921,10 +5920,10 @@ void ata_host_detach(struct ata_host *host)
int i;
  
  	/* Ensure ata_port probe has completed */


nit: maybe we can relocate this comment


-   async_synchronize_full();
-
-   for (i = 0; i < host->n_ports; i++)
+   for (i = 0; i < host->n_ports; i++) {
+   async_synchronize_cookie(host->ports[i]->cookie + 1);
ata_port_detach(host->ports[i]);
+   }
  
  	/* the host is dead now, dissociate ACPI */

ata_acpi_dissociate(host);
diff --git a/include/linux/libata.h b/include/linux/libata.h
index cffa4714bfa8..ae6dfc107ea8 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -22,6 +22,7 @@
  #include 
  #include 
  #include 
+#include 
  
  /*

   * Define if arch has non-standard setup.  This is a _PCI_ standard
@@ -872,6 +873,8 @@ struct ata_port {
struct timer_list   fastdrain_timer;
unsigned long   fastdrain_cnt;
  
+	async_cookie_t		cookie;

+
int em_message_type;
void*private_data;
  

Re: [PATCH 3/3] bridge: mrp: Restore port state when deleting MRP instance

[Nikolay Aleksandrov]

On 20/05/2020 16:09, Horatiu Vultur wrote:
> When a MRP instance is deleted, then restore the port according to the
> bridge state. If the bridge is up then the ports will be in forwarding
> state otherwise will be in disabled state.
> 
> Fixes: 9a9f26e8f7ea ("bridge: mrp: Connect MRP API with the switchdev API")
> Signed-off-by: Horatiu Vultur 
> ---
>  net/bridge/br_mrp.c | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 

Acked-by: Nikolay Aleksandrov 

> diff --git a/net/bridge/br_mrp.c b/net/bridge/br_mrp.c
> index a5a3fa59c078a..bdd8920c15053 100644
> --- a/net/bridge/br_mrp.c
> +++ b/net/bridge/br_mrp.c
> @@ -229,6 +229,7 @@ static void br_mrp_test_work_expired(struct work_struct 
> *work)
>  static void br_mrp_del_impl(struct net_bridge *br, struct br_mrp *mrp)
>  {
>   struct net_bridge_port *p;
> + u8 state;
>  
>   /* Stop sending MRP_Test frames */
>   cancel_delayed_work_sync(&mrp->test_work);
> @@ -240,20 +241,24 @@ static void br_mrp_del_impl(struct net_bridge *br, 
> struct br_mrp *mrp)
>   p = rtnl_dereference(mrp->p_port);
>   if (p) {
>   spin_lock_bh(&br->lock);
> - p->state = BR_STATE_FORWARDING;
> + state = netif_running(br->dev) ?
> + BR_STATE_FORWARDING : BR_STATE_DISABLED;
> + p->state = state;
>   p->flags &= ~BR_MRP_AWARE;
>   spin_unlock_bh(&br->lock);
> - br_mrp_port_switchdev_set_state(p, BR_STATE_FORWARDING);
> + br_mrp_port_switchdev_set_state(p, state);
>   rcu_assign_pointer(mrp->p_port, NULL);
>   }
>  
>   p = rtnl_dereference(mrp->s_port);
>   if (p) {
>   spin_lock_bh(&br->lock);
> - p->state = BR_STATE_FORWARDING;
> + state = netif_running(br->dev) ?
> + BR_STATE_FORWARDING : BR_STATE_DISABLED;
> + p->state = state;
>   p->flags &= ~BR_MRP_AWARE;
>   spin_unlock_bh(&br->lock);
> - br_mrp_port_switchdev_set_state(p, BR_STATE_FORWARDING);
> + br_mrp_port_switchdev_set_state(p, state);
>   rcu_assign_pointer(mrp->s_port, NULL);
>   }
>  
> 

Re: [PATCH 4.19 00/80] 4.19.124-rc1 review

[Greg Kroah-Hartman]

On Thu, May 21, 2020 at 07:49:42AM +, Chris Paterson wrote:
> Hello Greg,
> 
> > From: stable-ow...@vger.kernel.org  On
> > Behalf Of Greg Kroah-Hartman
> > Sent: 18 May 2020 18:36
> > 
> > This is the start of the stable review cycle for the 4.19.124 release.
> > There are 80 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.
> 
> No build/boot issues seen for CIP configs for Linux 4.19.124-rc1 
> (ff1170bc0ae9).
> 
> Build/test pipeline/logs: 
> https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/pipelines/147257412
> GitLab CI pipeline: 
> https://gitlab.com/cip-project/cip-testing/linux-cip-pipelines/-/blob/master/trees/linux-4.19.y.yml
> Relevant LAVA jobs: 
> https://lava.ciplatform.org/scheduler/alljobs?length=25&search=ff1170#table

Thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 09/10] xen/arm: introduce phys/dma translations in xen_dma_sync_for_*

[Julien Grall]

Hi,

On 21/05/2020 00:45, Stefano Stabellini wrote:

From: Stefano Stabellini 

Add phys_to_dma/dma_to_phys calls to
xen_dma_sync_for_cpu, xen_dma_sync_for_device, and
xen_arch_need_swiotlb.

In xen_arch_need_swiotlb, take the opportunity to switch to the simpler
pfn_valid check we use everywhere else.

dma_cache_maint is fixed by the next patch.


Like patch #8, this explains what the code is doing not why this is 
necessary.




Signed-off-by: Stefano Stabellini 
---
  arch/arm/xen/mm.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index f2414ea40a79..7639251bcc79 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -1,5 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0-only
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -75,7 +76,7 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t 
handle,
  phys_addr_t paddr, size_t size,
  enum dma_data_direction dir)
  {
-   if (pfn_valid(PFN_DOWN(handle)))
+   if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle
arch_sync_dma_for_cpu(paddr, size, dir);
else if (dir != DMA_TO_DEVICE)
dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
@@ -85,7 +86,7 @@ void xen_dma_sync_for_device(struct device *dev, dma_addr_t 
handle,
 phys_addr_t paddr, size_t size,
 enum dma_data_direction dir)
  {
-   if (pfn_valid(PFN_DOWN(handle)))
+   if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle
arch_sync_dma_for_device(paddr, size, dir);
else if (dir == DMA_FROM_DEVICE)
dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
@@ -97,8 +98,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
   phys_addr_t phys,
   dma_addr_t dev_addr)
  {
-   unsigned int xen_pfn = XEN_PFN_DOWN(phys);
-   unsigned int bfn = XEN_PFN_DOWN(dev_addr);
+   unsigned int bfn = XEN_PFN_DOWN(dma_to_phys(dev, dev_addr));
  
  	/*

 * The swiotlb buffer should be used if
@@ -115,7 +115,7 @@ bool xen_arch_need_swiotlb(struct device *dev,
 * require a bounce buffer because the device doesn't support coherent
 * memory and we are not able to flush the cache.
 */
-   return (!hypercall_cflush && (xen_pfn != bfn) &&
+   return (!hypercall_cflush && !pfn_valid(bfn) &&


I believe this change is incorrect. The bfn is a frame based on Xen page 
granularity (always 4K) while pfn_valid() is expecting a frame based on 
the Kernel page granularity.



!dev_is_dma_coherent(dev));
  }
  



Cheers,

--
Julien Grall

Re: [PATCH 09/15] device core: Add ability to handle multiple dma offsets

[Christoph Hellwig]

On Wed, May 20, 2020 at 03:36:16PM -0700, Dan Williams wrote:
> Certainly blindly cc'ing everyone recommended by
> scripts/get_maintainers.pl is overkill, but finding that subset is a
> bit of an art.

Yes.  But I'd rather be not Cced and just find the complete thread on
a list.  But all the lists I'm on and have managed to read through
yesterday didn't have the full series either.

linux-next: build failure after merge of the userns tree

[Stephen Rothwell]

Hi all,

After merging the userns tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

In file included from init/do_mounts.c:9:
include/linux/security.h: In function 'security_bprm_repopulate_creds':
include/linux/security.h:580:9: error: implicit declaration of function 
'cap_bprm_repopluate_creds'; did you mean 'cap_bprm_repopulate_creds'? 
[-Werror=implicit-function-declaration]
  580 |  return cap_bprm_repopluate_creds(bprm);
  | ^
  | cap_bprm_repopulate_creds

Caused by commit

  d9d67b76eed6 ("exec: Convert security_bprm_set_creds into 
security_bprm_repopulate_creds")

I have used the userns tree from next-20200519 for today.

-- 
Cheers,
Stephen Rothwell


pgpjlfT6OtD8a.pgp
Description: OpenPGP digital signature

Re: [PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally

[Paolo Bonzini]

On 21/05/20 06:33, Xiaoyao Li wrote:
> I remember there is certainly some reason why we don't expose WAITPKG to
> guest by default.

That's a userspace policy decision.  KVM_GET_SUPPORTED_CPUID should
still tell userspace that it's supported.

Paolo

> Tao, please help clarify it.

Re: Re: [PATCH] spi: tegra20-slink: Fix runtime PM imbalance on error

[dinghao . liu]

Hi Andy,

Thank you for your advice! I will fix the problem in the next edition
of patch. The coccinelle script will be very helpful and I'm looking 
forward to it.

Regards,
Dinghao 

"Andy Shevchenko" 写道：
> On Thu, May 21, 2020 at 11:04 AM Andy Shevchenko
>  wrote:
> > On Thu, May 21, 2020 at 10:50 AM Dinghao Liu  wrote:
> 
> Any I have coccinelle script for this, I can share with you.
> 
> -- 
> With Best Regards,
> Andy Shevchenko

Re: [PATCH 10/10] xen/arm: call dma_to_phys on the dma_addr_t parameter of dma_cache_maint

[Julien Grall]

On 21/05/2020 00:45, Stefano Stabellini wrote:

From: Stefano Stabellini 

Add a struct device* parameter to dma_cache_maint.

Translate the dma_addr_t parameter of dma_cache_maint by calling
dma_to_phys. Do it for the first page and all the following pages, in
case of multipage handling.


The term 'page' is confusing here. Are we referring to Xen page or Linux 
page?


Also, same as patch #8 and #9 regarding the commit message.



Signed-off-by: Stefano Stabellini 
---
  arch/arm/xen/mm.c | 15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 7639251bcc79..6ddf3b3c1ab5 100644
--- a/arch/arm/xen/mm.c
+++ b/arch/arm/xen/mm.c
@@ -43,15 +43,18 @@ unsigned long xen_get_swiotlb_free_pages(unsigned int order)
  static bool hypercall_cflush = false;
  
  /* buffers in highmem or foreign pages cannot cross page boundaries */

-static void dma_cache_maint(dma_addr_t handle, size_t size, u32 op)
+static void dma_cache_maint(struct device *dev, dma_addr_t handle,
+   size_t size, u32 op)
  {
struct gnttab_cache_flush cflush;
  
-	cflush.a.dev_bus_addr = handle & XEN_PAGE_MASK;

cflush.offset = xen_offset_in_page(handle);
cflush.op = op;
+   handle &= XEN_PAGE_MASK;
  
  	do {

+   cflush.a.dev_bus_addr = dma_to_phys(dev, handle);
+
if (size + cflush.offset > XEN_PAGE_SIZE)
cflush.length = XEN_PAGE_SIZE - cflush.offset;
else
@@ -60,7 +63,7 @@ static void dma_cache_maint(dma_addr_t handle, size_t size, 
u32 op)
HYPERVISOR_grant_table_op(GNTTABOP_cache_flush, &cflush, 1);
  
  		cflush.offset = 0;

-   cflush.a.dev_bus_addr += cflush.length;
+   handle += cflush.length;
size -= cflush.length;
} while (size);
  }
@@ -79,7 +82,7 @@ void xen_dma_sync_for_cpu(struct device *dev, dma_addr_t 
handle,
if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle
arch_sync_dma_for_cpu(paddr, size, dir);
else if (dir != DMA_TO_DEVICE)
-   dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
+   dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL);
  }
  
  void xen_dma_sync_for_device(struct device *dev, dma_addr_t handle,

@@ -89,9 +92,9 @@ void xen_dma_sync_for_device(struct device *dev, dma_addr_t 
handle,
if (pfn_valid(PFN_DOWN(dma_to_phys(dev, handle
arch_sync_dma_for_device(paddr, size, dir);
else if (dir == DMA_FROM_DEVICE)
-   dma_cache_maint(handle, size, GNTTAB_CACHE_INVAL);
+   dma_cache_maint(dev, handle, size, GNTTAB_CACHE_INVAL);
else
-   dma_cache_maint(handle, size, GNTTAB_CACHE_CLEAN);
+   dma_cache_maint(dev, handle, size, GNTTAB_CACHE_CLEAN);
  }
  
  bool xen_arch_need_swiotlb(struct device *dev,




Cheers,

--
Julien Grall

Re: [PATCH v5 01/19] spi: spi-mem: allow specifying whether an op is DTR or not

[masonccyang]

Hi Pratyush,

Given cmd.nbytes a initial value & check it !

> 
> [PATCH v5 01/19] spi: spi-mem: allow specifying whether an op is DTR or 
not
> 
> Each phase is given a separate 'dtr' field so mixed protocols like
> 4S-4D-4D can be supported.
> 
> Signed-off-by: Pratyush Yadav 
> ---
>  drivers/spi/spi-mem.c   | 3 +++
>  include/linux/spi/spi-mem.h | 8 
>  2 files changed, 11 insertions(+)
> 
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index 9a86cc27fcc0..93e255287ab9 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -156,6 +156,9 @@ bool spi_mem_default_supports_op(struct spi_mem 
*mem,
> op->data.dir == SPI_MEM_DATA_OUT))
>return false;
> 
> +   if (op->cmd.dtr || op->addr.dtr || op->dummy.dtr || op->data.dtr)
> +  return false;
> +

+   if (op->cmd.nbytes != 1)
+   return false;

> return true;
>  }
>  EXPORT_SYMBOL_GPL(spi_mem_default_supports_op);


 static int spi_mem_check_op(const struct spi_mem_op *op)
 {
-if (!op->cmd.buswidth)
+if (!op->cmd.buswidth || op->cmd.nbytes < 1 || 
op->cmd.nbytes > 2)
 return -EINVAL;


> diff --git a/include/linux/spi/spi-mem.h b/include/linux/spi/spi-mem.h
> index af9ff2f0f1b2..e3dcb956bf61 100644
> --- a/include/linux/spi/spi-mem.h
> +++ b/include/linux/spi/spi-mem.h

#define SPI_MEM_OP_CMD(__opcode, __buswidth)\
 {   \
 .buswidth = __buswidth, \
 .opcode = __opcode, \
+.nbytes = 1,\
 }



> @@ -71,9 +71,11 @@ enum spi_mem_data_dir {
>   * struct spi_mem_op - describes a SPI memory operation
>   * @cmd.buswidth: number of IO lines used to transmit the command
>   * @cmd.opcode: operation opcode
> + * @cmd.dtr: whether the command opcode should be sent in DTR mode or 
not
>   * @addr.nbytes: number of address bytes to send. Can be zero if the 
operation
>   *   does not need to send an address
>   * @addr.buswidth: number of IO lines used to transmit the address 
cycles
> + * @addr.dtr: whether the address should be sent in DTR mode or not
>   * @addr.val: address value. This value is always sent MSB first on the 
bus.
>   * Note that only @addr.nbytes are taken into account in this
>   * address value, so users should make sure the value fits in 
the
> @@ -81,7 +83,9 @@ enum spi_mem_data_dir {
>   * @dummy.nbytes: number of dummy bytes to send after an opcode or 
address. Can
>   *be zero if the operation does not require dummy bytes
>   * @dummy.buswidth: number of IO lanes used to transmit the dummy bytes
> + * @dummy.dtr: whether the dummy bytes should be sent in DTR mode or 
not
>   * @data.buswidth: number of IO lanes used to send/receive the data
> + * @data.dtr: whether the data should be sent in DTR mode or not
>   * @data.dir: direction of the transfer
>   * @data.nbytes: number of data bytes to send/receive. Can be zero if 
the
>   *   operation does not involve transferring data
> @@ -91,22 +95,26 @@ enum spi_mem_data_dir {
>  struct spi_mem_op {
> struct {
>u8 buswidth;
> +  u8 dtr : 1;
>u8 opcode;
> } cmd;
> 
> struct {
>u8 nbytes;
>u8 buswidth;
> +  u8 dtr : 1;
>u64 val;
> } addr;
> 
> struct {
>u8 nbytes;
>u8 buswidth;
> +  u8 dtr : 1;
> } dummy;
> 
> struct {
>u8 buswidth;
> +  u8 dtr : 1;
>enum spi_mem_data_dir dir;
>unsigned int nbytes;
>union {
> -- 
> 2.26.2
> 

thanks & best regards,
Mason

CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information 
and/or personal data, which is protected by applicable laws. Please be 
reminded that duplication, disclosure, distribution, or use of this e-mail 
(and/or its attachments) or any part thereof is prohibited. If you receive 
this e-mail in error, please notify us immediately and delete this mail as 
well as its attachment(s) from your system. In addition, please be 
informed that collection, processing, and/or use of personal data is 
prohibited unless expressly permitted by personal data protection laws. 
Thank you for your attention and cooperation.

Macronix International Co., Ltd.

=





CONFIDENTIALITY NOTE:

This e-mail and any attachments may contain confidential information and/or 
personal data, which is protected by applicable laws. Please be reminded that 
duplication, disclosure, distribution, or use of this e-mail (and/or its 
attachments) or any part thereof is prohibited. If you receive this e-mail in 
error, please notify us immediately and delete this mail as well 

Re: [sched/fair] 0b0695f2b3: phoronix-test-suite.compress-gzip.0.seconds 19.8% regression

[Oliver Sang]

On Wed, May 20, 2020 at 03:04:48PM +0200, Vincent Guittot wrote:
> On Thu, 14 May 2020 at 19:09, Vincent Guittot
>  wrote:
> >
> > Hi Oliver,
> >
> > On Thu, 14 May 2020 at 16:05, kernel test robot  
> > wrote:
> > >
> > > Hi Vincent Guittot,
> > >
> > > Below report FYI.
> > > Last year, we actually reported an improvement "[sched/fair] 0b0695f2b3:
> > > vm-scalability.median 3.1% improvement" on link [1].
> > > but now we found the regression on pts.compress-gzip.
> > > This seems align with what showed in "[v4,00/10] sched/fair: rework the 
> > > CFS
> > > load balance" (link [2]), where showed the reworked load balance could 
> > > have
> > > both positive and negative effect for different test suites.
> >
> > We have tried to run  all possible use cases but it's impossible to
> > covers all so there were a possibility that one that is not covered,
> > would regressed.
> >
> > > And also from link [3], the patch set risks regressions.
> > >
> > > We also confirmed this regression on another platform
> > > (Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz with 8G memory),
> > > below is the data (lower is better).
> > > v5.44.1
> > > fcf0553db6f4c79387864f6e4ab4a891601f395e4.01
> > > 0b0695f2b34a4afa3f6e9aa1ff0e5336d8dad9124.89
> > > v5.55.18
> > > v5.64.62
> > > v5.7-rc24.53
> > > v5.7-rc34.59
> > >
> > > It seems there are some recovery on latest kernels, but not fully back.
> > > We were just wondering whether you could share some lights the further 
> > > works
> > > on the load balance after patch set [2] which could cause the performance
> > > change?
> > > And whether you have plan to refine the load balance algorithm further?
> >
> > I'm going to have a look at your regression to understand what is
> > going wrong and how it can be fixed
> 
> I have run the benchmark on my local setups to try to reproduce the
> regression and I don't see the regression. But my setups are different
> from your so it might be a problem specific to yours

Hi Vincent, which OS are you using? We found the regression on Clear OS,
but it cannot reproduce on Debian.
On https://www.phoronix.com/scan.php?page=article&item=mac-win-linux2018&num=5
it was mentioned that -
Gzip compression is much faster out-of-the-box on Clear Linux due to it 
exploiting
multi-threading capabilities compared to the other operating systems Gzip 
support. 

> 
> After analysing the benchmark, it doesn't overload the system and is
> mainly based on 1 main gzip thread with few others waking up and
> sleeping around.
> 
> I thought that scheduler could be too aggressive when trying to
> balance the threads on your system, which could generate more task
> migrations and impact the performance. But this doesn't seem to be the
> case because perf-stat.i.cpu-migrations is -8%. On the other side, the
> context switch is +16% and more interestingly idle state C1E and C6
> usages increase more than 50%. I don't know if we can rely or this
> value or not but I wonder if it could be that threads are now spread
> on different CPUs which generates idle time on the busy CPUs but the
> added time to enter/leave these states hurts the performance.
> 
> Could you make some traces of both kernels ? Tracing sched events
> should be enough to understand the behavior
> 
> Regards,
> Vincent
> 
> >
> > Thanks
> > Vincent
> >
> > > thanks
> > >
> > > [1] 
> > > https://lists.01.org/hyperkitty/list/l...@lists.01.org/thread/SANC7QLYZKUNMM6O7UNR3OAQAKS5BESE/
> > > [2] https://lore.kernel.org/patchwork/cover/1141687/
> > > [3] 
> > > https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.5-Scheduler

[RFC PATCH linux-next] drm/msm/a6xx: a6xx_hfi_send_start() can be static

[kbuild test robot]

Fixes: 8167e6fa76c8 ("drm/msm/a6xx: HFI v2 for A640 and A650")
Signed-off-by: kbuild test robot 
---
 a6xx_hfi.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/adreno/a6xx_hfi.c 
b/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
index f9db69e771214..9921e632f1ca2 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_hfi.c
@@ -342,7 +342,7 @@ static int a6xx_hfi_send_test(struct a6xx_gmu *gmu)
NULL, 0);
 }
 
-int a6xx_hfi_send_start(struct a6xx_gmu *gmu)
+static int a6xx_hfi_send_start(struct a6xx_gmu *gmu)
 {
struct a6xx_hfi_msg_start msg = { 0 };
 
@@ -350,7 +350,7 @@ int a6xx_hfi_send_start(struct a6xx_gmu *gmu)
NULL, 0);
 }
 
-int a6xx_hfi_send_core_fw_start(struct a6xx_gmu *gmu)
+static int a6xx_hfi_send_core_fw_start(struct a6xx_gmu *gmu)
 {
struct a6xx_hfi_msg_core_fw_start msg = { 0 };
 

Re: [patch V6 12/37] x86/entry: Provide idtentry_entry/exit_cond_rcu()

[Thomas Gleixner]

"Paul E. McKenney"  writes:
> On Wed, May 20, 2020 at 03:15:31PM -0700, Paul E. McKenney wrote:
> Same patch, but with updated commit log based on IRC discussion
> with Andy.

Fun. I came up with the same thing before going to bed. Just that I
named the function differently: rcu_irq_enter_check_tick()

>  #if defined(CONFIG_TINY_RCU)
>  
> +static inline void tickle_nohz_for_rcu(void)
> +{
> +}
> +
>  static inline void rcu_nmi_enter(void)
>  {
>  }
> @@ -23,6 +27,7 @@ static inline void rcu_nmi_exit(void)
>  }
>  
>  #else
> +extern void tickle_nohz_for_rcu(void);

And I made this a NOP for for !NOHZ_FULL systems and avoided the call if
context tracking is not enabled at boot.

void __rcu_irq_enter_check_tick(void);

static inline void rcu_irq_enter_check_tick(void)
{
if (context_tracking_enabled())
__rcu_irq_enter_check_tick();
}

Thanks,

tglx

Re: [PATCH 31/33] sctp: add sctp_sock_set_nodelay

[Christoph Hellwig]

On Wed, May 20, 2020 at 08:39:13PM -0300, Marcelo Ricardo Leitner wrote:
> On Wed, May 20, 2020 at 04:23:55PM -0700, David Miller wrote:
> > From: Marcelo Ricardo Leitner 
> > Date: Wed, 20 May 2020 20:10:01 -0300
> > 
> > > The duplication with sctp_setsockopt_nodelay() is quite silly/bad.
> > > Also, why have the 'true' hardcoded? It's what dlm uses, yes, but the
> > > API could be a bit more complete than that.
> > 
> > The APIs are being designed based upon what in-tree users actually
> > make use of.  We can expand things later if necessary.
> 
> Sometimes expanding things later can be though, thus why the worry.
> But ok, I get it. Thanks.
> 
> The comment still applies, though. (re the duplication)

Where do you see duplication?

sctp_setsockopt_nodelay does the following things:

 - verifies optlen, returns -EINVAL if it doesn't match
 - calls get_user, returns -EFAULT on error
 - converts the value from get_user to a boolean and assigns it
   to sctp_sk(sk)->nodelay
 - returns 0.

sctp_sock_set_nodelay does:

 - call lock_sock
 - assign true to sctp_sk(sk)->nodelay
 - call release_sock
 - does not return an error code

[PATCH v2 2/3] arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic

[Wesley Cheng]

Enable the flexible TX FIFO resize logic on SM8150.  Using a larger TX FIFO
SZ can help account for situations when system latency is greater than the
USB bus transmission latency.

Signed-off-by: Wesley Cheng 
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index a36512d..c285233 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -708,6 +708,7 @@
interrupts = ;
snps,dis_u2_susphy_quirk;
snps,dis_enblslpm_quirk;
+   tx-fifo-resize;
phys = <&usb_1_hsphy>, <&usb_1_ssphy>;
phy-names = "usb2-phy", "usb3-phy";
};
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 0/3] Re-introduce TX FIFO resize for larger EP bursting

[Wesley Cheng]

Changes in V2:
 - Modified TXFIFO resizing logic to ensure that each EP is reserved a
   FIFO.
 - Removed dev_dbg() prints and fixed typos from patches
 - Added some more description on the dt-bindings commit message

Reviewed-by: Felipe Balbi 
Reviewed-by: Rob Herring 

Currently, there is no functionality to allow for resizing the TXFIFOs, and
relying on the HW default setting for the TXFIFO depth.  In most cases, the
HW default is probably sufficient, but for USB compositions that contain
multiple functions that require EP bursting, the default settings
might not be enough.  Also to note, the current SW will assign an EP to a
function driver w/o checking to see if the TXFIFO size for that particular
EP is large enough. (this is a problem if there are multiple HW defined
values for the TXFIFO size)

It is mentioned in the SNPS databook that a minimum of TX FIFO depth = 3
is required for an EP that supports bursting.  Otherwise, there may be
frequent occurences of bursts ending.  For high bandwidth functions,
such as data tethering (protocols that support data aggregation), mass
storage, and media transfer protocol (over FFS), the bMaxBurst value can be
large, and a bigger TXFIFO depth may prove to be beneficial in terms of USB
throughput. (which can be associated to system access latency, etc...)  It
allows for a more consistent burst of traffic, w/o any interruptions, as
data is readily available in the FIFO.

With testing done using the mass storage function driver, the results show
that with a larger TXFIFO depth, the bandwidth increased significantly.

Test Parameters:
 - Platform: Qualcomm SM8150
 - bMaxBurst = 6
 - USB req size = 256kB
 - Num of USB reqs = 16
 - USB Speed = Super-Speed
 - Function Driver: Mass Storage (w/ ramdisk)
 - Test Application: CrystalDiskMark

Results:

TXFIFO Depth = 3 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 193.60
  |   | 195.86
  |   | 184.77
  |   | 193.60
---

TXFIFO Depth = 6 max packets

Test Case | Data Size | AVG tput (in MB/s)
---
Sequential|1 GB x | 
Read  |9 loops| 287.35
  |   | 304.94
  |   | 289.64
  |   | 293.61
---

Wesley Cheng (3):
  usb: dwc3: Resize TX FIFOs to meet EP bursting requirements
  arm64: boot: dts: qcom: sm8150: Enable dynamic TX FIFO resize logic
  dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

 Documentation/devicetree/bindings/usb/dwc3.txt |   2 +-
 arch/arm64/boot/dts/qcom/sm8150.dtsi   |   1 +
 drivers/usb/dwc3/core.c|   2 +
 drivers/usb/dwc3/core.h|   8 ++
 drivers/usb/dwc3/ep0.c |  37 -
 drivers/usb/dwc3/gadget.c  | 111 +
 6 files changed, 159 insertions(+), 2 deletions(-)

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

[PATCH v2 3/3] dt-bindings: usb: dwc3: Add entry for tx-fifo-resize

[Wesley Cheng]

Re-introduce the comment for the tx-fifo-resize setting for the DWC3
controller.  This allows for vendors to control if they require the TX FIFO
resizing logic on their HW, as the default FIFO size configurations may
already be sufficient.

Signed-off-by: Wesley Cheng 
Reviewed-by: Rob Herring 
---
 Documentation/devicetree/bindings/usb/dwc3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
index 9946ff9..489f5da 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -105,7 +105,7 @@ Optional properties:
1-16 (DWC_usb31 programming guide section 1.2.3) to
enable periodic ESS TX threshold.
 
- -  tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
  - snps,incr-burst-type-adjustment: Value for INCR burst type of GSBUSCFG0
register, undefined length INCR burst type enable and 
INCRx type.
When just one value, which means INCRX burst mode 
enabled. When
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 1/3] usb: dwc3: Resize TX FIFOs to meet EP bursting requirements

[Wesley Cheng]

Some devices have USB compositions which may require multiple endpoints
that support EP bursting.  HW defined TX FIFO sizes may not always be
sufficient for these compositions.  By utilizing flexible TX FIFO
allocation, this allows for endpoints to request the required FIFO depth to
achieve higher bandwidth.  With some higher bMaxBurst configurations, using
a larger TX FIFO size results in better TX throughput.

Ensure that one TX FIFO is reserved for every IN endpoint.  This allows for
the FIFO logic to prevent running out of FIFO space.

Signed-off-by: Wesley Cheng 
Reviewed-by: Felipe Balbi 
---
 drivers/usb/dwc3/core.c   |   2 +
 drivers/usb/dwc3/core.h   |   8 
 drivers/usb/dwc3/ep0.c|  37 +++-
 drivers/usb/dwc3/gadget.c | 111 ++
 4 files changed, 157 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index edc1715..cca5554 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1304,6 +1304,8 @@ static void dwc3_get_properties(struct dwc3 *dwc)
&tx_thr_num_pkt_prd);
device_property_read_u8(dev, "snps,tx-max-burst-prd",
&tx_max_burst_prd);
+   dwc->needs_fifo_resize = device_property_read_bool(dev,
+   "tx-fifo-resize");
 
dwc->disable_scramble_quirk = device_property_read_bool(dev,
"snps,disable_scramble_quirk");
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index 4c171a8..ce0bf28 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -675,6 +675,7 @@ struct dwc3_event_buffer {
  * isochronous START TRANSFER command failure workaround
  * @start_cmd_status: the status of testing START TRANSFER command with
  * combo_num = 'b00
+ * @fifo_depth: allocated TXFIFO depth
  */
 struct dwc3_ep {
struct usb_ep   endpoint;
@@ -727,6 +728,7 @@ struct dwc3_ep {
/* For isochronous START TRANSFER workaround only */
u8  combo_num;
int start_cmd_status;
+   int fifo_depth;
 };
 
 enum dwc3_phy {
@@ -1004,6 +1006,7 @@ struct dwc3_scratchpad_array {
  * 1   - utmi_l1_suspend_n
  * @is_fpga: true when we are using the FPGA board
  * @pending_events: true when we have pending IRQs to be handled
+ * @needs_fifo_resize: not all users might want fifo resizing, flag it
  * @pullups_connected: true when Run/Stop bit is set
  * @setup_packet_pending: true when there's a Setup Packet in FIFO. Workaround
  * @three_stage_setup: set if we perform a three phase setup
@@ -1044,6 +1047,8 @@ struct dwc3_scratchpad_array {
  * @dis_metastability_quirk: set to disable metastability quirk.
  * @imod_interval: set the interrupt moderation interval in 250ns
  * increments or 0 to disable.
+ * @last_fifo_depth: total TXFIFO depth of all enabled USB IN/INT endpoints
+ * @num_ep_resized: the number of TX FIFOs that have already been resized
  */
 struct dwc3 {
struct work_struct  drd_work;
@@ -1204,6 +1209,7 @@ struct dwc3 {
unsignedis_utmi_l1_suspend:1;
unsignedis_fpga:1;
unsignedpending_events:1;
+   unsignedneeds_fifo_resize:1;
unsignedpullups_connected:1;
unsignedsetup_packet_pending:1;
unsignedthree_stage_setup:1;
@@ -1236,6 +1242,8 @@ struct dwc3 {
unsigneddis_metastability_quirk:1;
 
u16 imod_interval;
+   int last_fifo_depth;
+   int num_ep_resized;
 };
 
 #define INCRX_BURST_MODE 0
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 6dee4da..76db9b5 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -601,8 +601,9 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
 {
enum usb_device_state state = dwc->gadget.state;
u32 cfg;
-   int ret;
+   int ret, num, size;
u32 reg;
+   struct dwc3_ep *dep;
 
cfg = le16_to_cpu(ctrl->wValue);
 
@@ -611,6 +612,40 @@ static int dwc3_ep0_set_config(struct dwc3 *dwc, struct 
usb_ctrlrequest *ctrl)
return -EINVAL;
 
case USB_STATE_ADDRESS:
+   /*
+* If tx-fifo-resize flag is not set for the controller, then
+* do not clear existing allocated TXFIFO since we do not
+* allocate it again in dwc3_gadget_resize_tx_fifos
+*/
+   if (dwc->needs_fifo_resize) {
+   /* Read ep0IN related TXFIFO size */
+   dep = dwc->eps[1];
+   size = dwc3_readl(dwc->regs, DWC3_GTXFIFOSIZ(0));
+   if (dwc3_is_usb31(dwc))

[PATCH] smp: Function call tracepoints

[Wojciech Kudla]

Following the feedback after the first approach:
https://lkml.kernel.org/r/20200520135156.go317...@hirez.programming.kicks-ass.net

This patch introduces generic SMP function call trace points:
- smp:function_call_issue (captures target cpumask and function pointer)
- smp:function_call_execute (captures executing cpu and function pointer)

Events show function symbols instead of pointers when printk()-ed

Signed-off-by: Wojciech Kudla 
---
 include/trace/events/smp.h | 67 ++
 kernel/smp.c   | 18 +-
 2 files changed, 84 insertions(+), 1 deletion(-)
 create mode 100644 include/trace/events/smp.h

diff --git a/include/trace/events/smp.h b/include/trace/events/smp.h
new file mode 100644
index ..ecbd2bb7613b
--- /dev/null
+++ b/include/trace/events/smp.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM smp
+
+#if !defined(_TRACE_SMP_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_SMP_H
+
+#include 
+
+/**
+ * function_call_issue - called when an smp call is made
+ *
+ * @mask: mask of recipient CPUs for the SMP  function call
+ * @function: pointer to the function to be executed
+ *
+ */
+TRACE_EVENT(function_call_issue,
+
+   TP_PROTO(const struct cpumask *mask, smp_call_func_t func),
+
+   TP_ARGS(mask, func),
+
+   TP_STRUCT__entry(
+   __bitmask(target_cpus, nr_cpumask_bits)
+   __field(smp_call_func_t, func)
+   ),
+
+   TP_fast_assign(
+   __assign_bitmask(target_cpus, cpumask_bits(mask), 
nr_cpumask_bits);
+   __entry->func = func;
+   ),
+
+   TP_printk("target_mask=%s, function=%pS", 
+   __get_bitmask(target_cpus), __entry->func)
+);
+
+
+/**
+ * function_call_execute - called when smp call is executed on the target cpu
+ *
+ * @cpu: cpu the SMP function call is being executed on
+ * @function: pointer to the function to be executed
+ *
+ */
+TRACE_EVENT(function_call_execute,
+
+   TP_PROTO(int cpu, smp_call_func_t func),
+
+   TP_ARGS(cpu, func),
+
+   TP_STRUCT__entry(
+   __field(int, cpu)
+   __field(smp_call_func_t, func)
+   ),
+
+   TP_fast_assign(
+   __entry->cpu = cpu;
+   __entry->func = func;
+   ),
+
+   TP_printk("cpu=%d, function=%pS", __entry->cpu, __entry->func)
+);
+
+#endif /* _TRACE_SMP_H */
+
+/* This part must be outside protection */
+#include 
diff --git a/kernel/smp.c b/kernel/smp.c
index 7dbcb402c2fc..acb20bd118e0 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -21,6 +21,9 @@
 #include 
 #include 
 
+#define CREATE_TRACE_POINTS
+#include 
+
 #include "smpboot.h"
 
 enum {
@@ -176,8 +179,12 @@ static int generic_exec_single(int cpu, call_single_data_t 
*csd,
 * locking and barrier primitives. Generic code isn't really
 * equipped to do the right thing...
 */
-   if (llist_add(&csd->llist, &per_cpu(call_single_queue, cpu)))
+   if (llist_add(&csd->llist, &per_cpu(call_single_queue, cpu))) {
+   if (trace_function_call_issue_enabled())
+   trace_function_call_issue(cpumask_of(cpu), func);
+
arch_send_call_function_single_ipi(cpu);
+   }
 
return 0;
 }
@@ -241,10 +248,17 @@ static void flush_smp_call_function_queue(bool 
warn_cpu_offline)
 
/* Do we wait until *after* callback? */
if (csd->flags & CSD_FLAG_SYNCHRONOUS) {
+   if (trace_function_call_execute_enabled())
+   trace_function_call_execute(smp_processor_id(), 
func);
+
func(info);
csd_unlock(csd);
} else {
csd_unlock(csd);
+
+   if (trace_function_call_execute_enabled())
+   trace_function_call_execute(smp_processor_id(), 
func);
+
func(info);
}
}
@@ -474,6 +488,8 @@ void smp_call_function_many(const struct cpumask *mask,
__cpumask_set_cpu(cpu, cfd->cpumask_ipi);
}
 
+   trace_function_call_issue(cfd->cpumask_ipi, func);
+
/* Send a message to all CPUs in the map */
arch_send_call_function_ipi_mask(cfd->cpumask_ipi);
 
-- 
2.17.1

Re: [PATCH] spi: tegra20-slink: Fix runtime PM imbalance on error

[Jon Hunter]

On 21/05/2020 09:04, Andy Shevchenko wrote:
> On Thu, May 21, 2020 at 10:50 AM Dinghao Liu  wrote:
>>
>> pm_runtime_get_sync() increments the runtime PM usage counter even
>> when it returns an error code. Thus a pairing decrement is needed on
>> the error handling path to keep the counter balanced.
> 
> ...
> 
>> ret = pm_runtime_get_sync(&pdev->dev);
>> if (ret < 0) {
>> dev_err(&pdev->dev, "pm runtime get failed, e = %d\n", ret);
> 
>> +   pm_runtime_put(&pdev->dev);
> 
> For all your patches, please, double check what you are proposing.
> 
> Here, I believe, the correct one will be _put_noidle().
> 
> AFAIU you are not supposed to actually suspend the device in case of error.
> But I might be mistaken, thus see above.
> 
>> goto exit_pm_disable;
>> }


Is there any reason why this is not handled in pm_runtime_get itself?
Jon

-- 
nvpublic

Re: [PATCH v1] Revert "software node: Simplify software_node_release() function"

[Petr Mladek]

On Wed 2020-05-20 11:21:49, Brendan Higgins wrote:
> On Wed, May 20, 2020 at 9:42 AM Andy Shevchenko
>  wrote:
> >
> > On Wed, May 20, 2020 at 05:02:27PM +0200, Petr Mladek wrote:
> > > On Thu 2020-02-27 16:00:01, Brendan Higgins wrote:
> >
> > > I have found similar report from a test robot, see
> > > https://lore.kernel.org/lkml/20200303002816.GW6548@shao2-debian/
> > >
> > >
> > > I was staring into it for a while and do not understand it. The revert
> > > makes sense. I wonder if it somehow changes the order in which
> > > the release methods are called.
> > >
> > > Anyway, reverting the revert makes test_printf working.
> >
> > There is a proper fix IIRC from Heikki in driver core (no link at hand, 
> > sorry).
> 
> The fix for this patch can be found here: https://lkml.org/lkml/2020/5/13/1070

Thanks for hint. This patch helped.

Best Regards,
Petr

VERY VERY URGENT,

[Mr.Basham Zebdani]

FROM MR.BASHAM ZEBDANI
AUDIT& ACCOUNT MANAGER
BANK OF AFRICA (B.O.A)
OUAGADOUGOU BURKINA FASO
WEST AFRICA.

Dear Friend,

With due respect, I have decided to contact you on
abusinesstransaction  that will be beneficial to both of us. At the
bank last account and  auditing evaluation, my staffs came across an
old account which was being maintained by a foreign client who we
learn was among the deceased passengers of motor accident on
November.2003, the deceased was unable to run this account since his
death. Theaccount has  remained dormant without the knowledge of his
family since it was put in a  safe deposit account in the bank for
future investment by the client.

Since his demise, even the members of his family haven't applied for
claims  over this fund and it has been in the safe deposit account
until I  discovered that it cannot be claimed since our client
isaforeign national and we are sure that he has no next of kin here to
file claims over the money. As the director of the department, this
discovery was brought to my office so as to decide what is to bedone.I
decided to seek ways through which to transfer this money out of the
bank and out of the country too.

The total amount in the account is 18.6 million with my positions as
staffs  of the bank, I am handicapped because I cannot operate foreign
accounts and  cannot lay bonafide claim over this money. The client
was a foreign  national and you will only be asked to act as his next
of kin and I will  supply you with all the necessary information and
bank data to assist you in being able to transfer this money to any
bank of your  choice where this money could be transferred into.The
total sum will be shared as follows: 50% for me, 50% for you and
expenses incidental occur  during the transfer will be incur by both
of us. The transfer is risk free on both sides hence you are going to
follow my instruction till the fund  transfer to your account. Since I
work in this bank that is why you should  be confident in the success
of this transaction because you will be updated with information as at
when desired.

I will wish you to keep this transaction secret and confidential as I
am hoping to retire with my share of this money at the end of
transaction  which will be when this money is safety in your account.I
will then come over to your country for sharing according to the
previously agreed percentages. You might even have to advise me on
possibilities of investment in your country or elsewhere of our
choice. May  God help you to help me to a restive retirement,Amen,And
You have to  contact me through my private e-mail
at(bashamzebd...@gmail.com)Please for further information and inquires
feel free to contact me back immediately for more explanation and
better understanding I want you to assure me your capability of
handling this  project with trust by providing me your following
information details such as:

(1)NAME..
(2)AGE:
(3)SEX:.
(4)PHONE NUMBER:.
(5)OCCUPATION:.
(6)YOUR COUNTRY:.

Yours sincerely,
Mr.Basham Zebdani

Re: [PATCH 2/2] kvm/x86: don't expose MSR_IA32_UMWAIT_CONTROL unconditionally

[Paolo Bonzini]

On 21/05/20 08:44, Tao Xu wrote:
> 
> I am sorry, I mean:
> By default, we don't expose WAITPKG to guest. For QEMU, we can use
> "-overcommit cpu-pm=on" to use WAITPKG.

But UMONITOR, UMWAIT and TPAUSE are not NOPs on older processors (which
I should have checked before committing your patch, I admit).  So you
have broken "-cpu host -overcommit cpu-pm=on" on any processor that
doesn't have WAITPKG.  I'll send a patch.

Paolo

Re: [PATCH 32/33] net: add a new bind_add method

[Christoph Hellwig]

On Wed, May 20, 2020 at 08:00:25PM -0300, Marcelo Ricardo Leitner wrote:
> > +   if (err)
> > +   return err;
> > +
> > +   lock_sock(sk);
> > +   err = sctp_do_bind(sk, (union sctp_addr *)addr, af->sockaddr_len);
> > +   if (!err)
> > +   err = sctp_send_asconf_add_ip(sk, addr, 1);
> 
> Some problems here.
> - addr may contain a list of addresses
> - the addresses, then, are not being validated
> - sctp_do_bind may fail, on which it requires some undoing
>   (like sctp_bindx_add does)
> - code duplication with sctp_setsockopt_bindx.

sctp_do_bind and thus this function only support a single address, as
that is the only thing that the DLM code requires.  I could move the
user copy out of sctp_setsockopt_bindx and reuse that, but it is a
rather rcane API.

> 
> This patch will conflict with David's one,
> [PATCH net-next] sctp: Pull the user copies out of the individual sockopt 
> functions.

Do you have a link?  A quick google search just finds your mail that
I'm replying to.

> (I'll finish reviewing it in the sequence)
> 
> AFAICT, this patch could reuse/build on his work in there. The goal is
> pretty much the same and would avoid the issues above.
> 
> This patch could, then, point the new bind_add proto op to the updated
> sctp_setsockopt_bindx almost directly.
> 
> Question then is: dlm never removes an addr from the bind list. Do we
> want to add ops for both? Or one that handles both operations?
> Anyhow, having the add operation but not the del seems very weird to
> me.

We generally only add operations for things that we actually use.
bind_del is another logical op, but we can trivially add that when we
need it.

Re: [PATCH v3 0/3] lib/vsprintf: Introduce %ptT for time64_t

[Petr Mladek]

On Wed 2020-05-20 20:43:33, Sergey Senozhatsky wrote:
> On (20/05/15 18:02), Petr Mladek wrote:
> > On Wed 2020-04-15 20:00:43, Andy Shevchenko wrote:
> > > It is a logical continuation of previously applied %ptR for struct 
> > > rtc_time.
> > > We have few users of time64_t that would like to print it.
> > 
> > It seems that everything was explained and the patches look good to
> > me. If we allowed %ptR then it makes sense to allow %ptT as well.
> > 
> > For all three patches:
> > 
> > Rewieved-by: Petr Mladek 
> 
> Acked-by: Sergey Senozhatsky 

This patchset has been committed into printk/linux.git,
branch for-5.8-printf-time64_t.

Note that it is a new git repo with shared write access.

Best Regards,
Petr

[PATCH] dmaengine: ti: edma: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/dma/ti/edma.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/dma/ti/edma.c b/drivers/dma/ti/edma.c
index c4a5c170c1f9..609ce2607eb7 100644
--- a/drivers/dma/ti/edma.c
+++ b/drivers/dma/ti/edma.c
@@ -2402,8 +2402,7 @@ static int edma_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
dev_err(dev, "pm_runtime_get_sync() failed\n");
-   pm_runtime_disable(dev);
-   return ret;
+   goto err_disable_pm;
}
 
/* Get eDMA3 configuration from IP */
-- 
2.17.1

Re: [PATCH] spi: tegra20-slink: Fix runtime PM imbalance on error

[Jon Hunter]

On 21/05/2020 09:38, Jon Hunter wrote:
> 
> On 21/05/2020 09:04, Andy Shevchenko wrote:
>> On Thu, May 21, 2020 at 10:50 AM Dinghao Liu  wrote:
>>>
>>> pm_runtime_get_sync() increments the runtime PM usage counter even
>>> when it returns an error code. Thus a pairing decrement is needed on
>>> the error handling path to keep the counter balanced.
>>
>> ...
>>
>>> ret = pm_runtime_get_sync(&pdev->dev);
>>> if (ret < 0) {
>>> dev_err(&pdev->dev, "pm runtime get failed, e = %d\n", ret);
>>
>>> +   pm_runtime_put(&pdev->dev);
>>
>> For all your patches, please, double check what you are proposing.
>>
>> Here, I believe, the correct one will be _put_noidle().
>>
>> AFAIU you are not supposed to actually suspend the device in case of error.
>> But I might be mistaken, thus see above.
>>
>>> goto exit_pm_disable;
>>> }
> 
> 
> Is there any reason why this is not handled in pm_runtime_get itself?

Ah I see a response from Rafael here:
https://lkml.org/lkml/2020/5/20/1100

OK so this is intentional and needs to be fixed.

Jon

-- 
nvpublic

[PATCH] staging: rtl8192e: Using comparison to true is error prone

[John Oldman]

clear below issues reported by checkpatch.pl:

CHECK: Using comparison to true is error prone
CHECK: Using comparison to false is error prone

Signed-off-by: John Oldman 
---
 drivers/staging/rtl8192e/rtl8192e/rtl_dm.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c 
b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
index 43494a2b6f05..462835684e8b 100644
--- a/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
+++ b/drivers/staging/rtl8192e/rtl8192e/rtl_dm.c
@@ -456,7 +456,7 @@ static void _rtl92e_dm_bandwidth_autoswitch(struct 
net_device *dev)
if (priv->CurrentChannelBW == HT_CHANNEL_WIDTH_20 ||
   !priv->rtllib->bandwidth_auto_switch.bautoswitch_enable)
return;
-   if (priv->rtllib->bandwidth_auto_switch.bforced_tx20Mhz == false) {
+   if (!priv->rtllib->bandwidth_auto_switch.bforced_tx20Mhz) {
if (priv->undecorated_smoothed_pwdb <=
priv->rtllib->bandwidth_auto_switch.threshold_40Mhzto20Mhz)
priv->rtllib->bandwidth_auto_switch.bforced_tx20Mhz = 
true;
@@ -1297,7 +1297,7 @@ static void _rtl92e_dm_dig_init(struct net_device *dev)
 static void _rtl92e_dm_ctrl_initgain_byrssi(struct net_device *dev)
 {
 
-   if (dm_digtable.dig_enable_flag == false)
+   if (!dm_digtable.dig_enable_flag)
return;
 
if (dm_digtable.dig_algorithm == DIG_ALGO_BY_FALSE_ALARM)
@@ -1332,7 +1332,7 @@ static void _rtl92e_dm_ctrl_initgain_byrssi_driver(struct 
net_device *dev)
u8 i;
static u8   fw_dig;
 
-   if (dm_digtable.dig_enable_flag == false)
+   if (!dm_digtable.dig_enable_flag)
return;
 
if (dm_digtable.dig_algorithm_switch)
@@ -1366,7 +1366,7 @@ static void 
_rtl92e_dm_ctrl_initgain_byrssi_false_alarm(struct net_device *dev)
static u32 reset_cnt;
u8 i;
 
-   if (dm_digtable.dig_enable_flag == false)
+   if (!dm_digtable.dig_enable_flag)
return;
 
if (dm_digtable.dig_algorithm_switch) {
@@ -1501,7 +1501,7 @@ static void _rtl92e_dm_initial_gain(struct net_device 
*dev)
reset_cnt = 0;
}
 
-   if (rtllib_act_scanning(priv->rtllib, true) == true) {
+   if (rtllib_act_scanning(priv->rtllib, true)) {
force_write = 1;
return;
}
-- 
2.17.1

Re: [PATCH RFC] sched: Add a per-thread core scheduling interface

[Peter Zijlstra]

On Wed, May 20, 2020 at 06:26:42PM -0400, Joel Fernandes (Google) wrote:
> Add a per-thread core scheduling interface which allows a thread to tag
> itself and enable core scheduling. Based on discussion at OSPM with
> maintainers, we propose a prctl(2) interface accepting values of 0 or 1.
>  1 - enable core scheduling for the task.
>  0 - disable core scheduling for the task.

Yeah, so this is a terrible interface :-)

It doens't allow tasks for form their own groups (by for example setting
the key to that of another task).

It is also horribly ill defined what it means to 'enable', with whoem
is it allows to share a core.

> Special cases:

> (1)
> The core-scheduling patchset contains a CGroup interface as well. In
> order for us to respect users of that interface, we avoid overriding the
> tag if a task was CGroup-tagged because the task becomes inconsistent
> with the CGroup tag. Instead return -EBUSY.
> 
> (2)
> If a task is prctl-tagged, allow the CGroup interface to override
> the task's tag.

OK, so cgroup always wins; is why is that a good thing?

> ChromeOS will use core-scheduling to securely enable hyperthreading.
> This cuts down the keypress latency in Google docs from 150ms to 50ms
> while improving the camera streaming frame rate by ~3%.

It doesn't consider permissions.

Basically, with the way you guys use it, it should be a CAP_SYS_ADMIN
only to enable core-sched.

That also means we should very much default to disable.

Re: [PATCH 09/12] devfreq: add mediatek cci devfreq

[andrew-sh.cheng]

On Wed, 2020-05-20 at 13:31 +0100, Mark Brown wrote:
> On Wed, May 20, 2020 at 11:43:04AM +0800, Andrew-sh.Cheng wrote:
> 
> > +   cci_df->proc_reg = devm_regulator_get_optional(cci_dev, "proc");
> > +   ret = PTR_ERR_OR_ZERO(cci_df->proc_reg);
> > +   if (ret) {
> > +   if (ret != -EPROBE_DEFER)
> > +   dev_err(cci_dev, "failed to get regulator for CCI: 
> > %d\n",
> > +   ret);
> > +   return ret;
> > +   }
> > +   ret = regulator_enable(cci_df->proc_reg);
> 
> The code appears to require a regulator (and I'm guessing the device
> needs power) so why is this using regulator_get_optional()?

Hi Mark,

Do you mean, why not use regulator_get_exclusive() or regulator_get()?
Because cci and cpu litter core shared buck, it cannot use
regulator_get_exclusive().
Because both cci and cpu want to tune voltage, it cannot use
regulator_get(), otherwise it will get dummy regulator even this buck
doesn't register.as regulator.

BR,
Andrew-sh.Cheng

[PATCH] sata_rcar: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
when it returns an error code. Thus a pairing decrement is needed on
the error handling path to keep the counter balanced.

Signed-off-by: Dinghao Liu 
---
 drivers/ata/sata_rcar.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/ata/sata_rcar.c b/drivers/ata/sata_rcar.c
index 980aacdbcf3b..cfa0e732dfd0 100644
--- a/drivers/ata/sata_rcar.c
+++ b/drivers/ata/sata_rcar.c
@@ -907,7 +907,7 @@ static int sata_rcar_probe(struct platform_device *pdev)
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
if (ret < 0)
-   goto err_pm_disable;
+   goto err_pm_put;
 
host = ata_host_alloc(dev, 1);
if (!host) {
@@ -937,7 +937,6 @@ static int sata_rcar_probe(struct platform_device *pdev)
 
 err_pm_put:
pm_runtime_put(dev);
-err_pm_disable:
pm_runtime_disable(dev);
return ret;
 }
-- 
2.17.1

Re: mm: mkfs.ext4 invoked oom-killer on i386 - pagecache_get_page

[Naresh Kamboju]

On Thu, 21 May 2020 at 08:10, Yafang Shao  wrote:
>
> On Thu, May 21, 2020 at 2:00 AM Naresh Kamboju
>  wrote:
> >
> > On Wed, 20 May 2020 at 17:26, Naresh Kamboju  
> > wrote:
> > >
> > >
> > > This issue is specific on 32-bit architectures i386 and arm on linux-next 
> > > tree.
> > > As per the test results history this problem started happening from
> > > mkfs -t ext4 /dev/disk/by-id/ata-SanDisk_SSD_PLUS_120GB_190804A00BE5
> > >
> > >
> > > Problem:
> > > [   38.802375] dd invoked oom-killer: gfp_mask=0x100cc0(GFP_USER),
> > > order=0, oom_score_adj=0
> >
> My guess is that we made the same mistake in commit "mm, memcg:
> decouple e{low,min} state mutations from protection
> checks" that it read a stale memcg protection in
> mem_cgroup_below_low() and mem_cgroup_below_min().
>
> Bellow is a possble fix,

Sorry. The proposed fix did not work.
I have took your patch and applied on top of linux-next master branch and
tested and mkfs -t ext4 invoked oom-killer.

After patch applied test log link,
https://lkft.validation.linaro.org/scheduler/job/1443936#L1168


test  log,
+ mkfs -t ext4 /dev/disk/by-id/ata-TOSHIBA_MG04ACA100N_Y8NRK0BPF6XF
mke2fs 1.43.8 (1-Jan-2018)
Creating filesystem with 244190646 4k blocks and 61054976 inodes
Filesystem UUID: ab107250-bf18-4357-a06a-67f2bfcc1048
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968,
10240, 214990848
Allocating group tables:0/7453   done
Writing inode tables:0/7453   done
Creating journal (262144 blocks): [   34.423940] mkfs.ext4 invoked
oom-killer: gfp_mask=0x101cc0(GFP_USER|__GFP_WRITE), order=0,
oom_score_adj=0
[   34.433694] CPU: 0 PID: 402 Comm: mkfs.ext4 Not tainted
5.7.0-rc6-next-20200519+ #1
[   34.441342] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.2 05/23/2018
[   34.448734] Call Trace:
[   34.451196]  dump_stack+0x54/0x76
[   34.454517]  dump_header+0x40/0x1f0
[   34.458008]  ? oom_badness+0x1f/0x120
[   34.461673]  ? ___ratelimit+0x6c/0xe0
[   34.465332]  oom_kill_process+0xc9/0x110
[   34.469255]  out_of_memory+0xd7/0x2f0
[   34.472916]  __alloc_pages_nodemask+0xdd1/0xe90
[   34.477446]  ? set_bh_page+0x33/0x50
[   34.481016]  ? __xa_set_mark+0x4d/0x70
[   34.484762]  pagecache_get_page+0xbe/0x250
[   34.488859]  grab_cache_page_write_begin+0x1a/0x30
[   34.493645]  block_write_begin+0x25/0x90
[   34.497569]  blkdev_write_begin+0x1e/0x20
[   34.501574]  ? bdev_evict_inode+0xc0/0xc0
[   34.505578]  generic_perform_write+0x95/0x190
[   34.509927]  __generic_file_write_iter+0xe0/0x1a0
[   34.514626]  blkdev_write_iter+0xbf/0x1c0
[   34.518630]  __vfs_write+0x122/0x1e0
[   34.522200]  vfs_write+0x8f/0x1b0
[   34.525510]  ksys_pwrite64+0x60/0x80
[   34.529081]  __ia32_sys_ia32_pwrite64+0x16/0x20
[   34.533604]  do_fast_syscall_32+0x66/0x240
[   34.537697]  entry_SYSENTER_32+0xa5/0xf8
[   34.541613] EIP: 0xb7f3c549
[   34.544403] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01
10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f
34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90
8d 76
[   34.563140] EAX: ffda EBX: 0003 ECX: b7830010 EDX: 0040
[   34.569397] ESI: 3840 EDI: 0074 EBP: 07438400 ESP: bff1e650
[   34.575654] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 0246
[   34.582453] Mem-Info:
[   34.584732] active_anon:5713 inactive_anon:2169 isolated_anon:0
[   34.584732]  active_file:4040 inactive_file:211204 isolated_file:0
[   34.584732]  unevictable:0 dirty:17270 writeback:6240 unstable:0
[   34.584732]  slab_reclaimable:5856 slab_unreclaimable:3439
[   34.584732]  mapped:6192 shmem:2258 pagetables:178 bounce:0
[   34.584732]  free:265105 free_pcp:1330 free_cma:0
[   34.618483] Node 0 active_anon:22852kB inactive_anon:8676kB
active_file:16160kB inactive_file:844816kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB mapped:24768kB dirty:69080kB
writeback:19628kB shmem:9032kB writeback_tmp:0kB unstable:0kB
all_unreclaimable? yes
[   34.642354] DMA free:3588kB min:68kB low:84kB high:100kB
reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:11848kB unevictable:0kB
writepending:11856kB present:15964kB managed:15876kB mlocked:0kB
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[   34.670194] lowmem_reserve[]: 0 824 1947 824
[   34.674483] Normal free:4228kB min:3636kB low:4544kB high:5452kB
reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB
active_file:1136kB inactive_file:786456kB unevictable:0kB
writepending:68084kB present:884728kB managed:845324kB mlocked:0kB
kernel_stack:1104kB pagetables:0kB bounce:0kB free_pcp:3056kB
local_pcp:388kB free_cma:0kB
[   34.704243] lowmem_reserve[]: 0 0 8980 0
[   34.708189] HighMem free:1053028kB min:512kB low:1748kB high:2984kB
reserved_highatomic:0KB active_anon:2285