[PATCH] mmc: meson-gx: remove IRQF_ONESHOT

[Jerome Brunet]

IRQF_ONESHOT was added to this driver to make sure the irq was not enabled
again until the thread part of the irq had finished doing its job.

Doing so upsets RT because, under RT, the hardirq part of the irq handler
is not migrated to a thread if the irq is claimed with IRQF_ONESHOT.
In this case, it has been reported to eventually trigger a deadlock with
the led subsystem.

Preventing RT from doing this migration was certainly not the intent, the
description of IRQF_ONESHOT does not really reflect this constraint:

 > IRQF_ONESHOT - Interrupt is not reenabled after the hardirq handler finished.
 >  Used by threaded interrupts which need to keep the
 >  irq line disabled until the threaded handler has been run.

This is exactly what this driver was trying to acheive so I'm still a bit
confused whether this is a driver or an RT issue.

Anyway, this can be solved driver side by manually disabling the IRQs
instead of the relying on the IRQF_ONESHOT. IRQF_ONESHOT may then be removed
while still making sure the irq won't trigger until the threaded part of
the handler is done.

Fixes: eb4d81127746 ("mmc: meson-gx: correct irq flag")
Reported-by: Brad Harper 
Cc: Sebastian Andrzej Siewior 
Signed-off-by: Jerome Brunet 
---
 drivers/mmc/host/meson-gx-mmc.c | 47 -
 1 file changed, 29 insertions(+), 18 deletions(-)

diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index 08a3b1c05acb..effc356db904 100644
--- a/drivers/mmc/host/meson-gx-mmc.c
+++ b/drivers/mmc/host/meson-gx-mmc.c
@@ -101,8 +101,7 @@
 #define   IRQ_RESP_STATUS BIT(14)
 #define   IRQ_SDIO BIT(15)
 #define   IRQ_EN_MASK \
-   (IRQ_CRC_ERR | IRQ_TIMEOUTS | IRQ_END_OF_CHAIN | IRQ_RESP_STATUS |\
-IRQ_SDIO)
+   (IRQ_CRC_ERR | IRQ_TIMEOUTS | IRQ_END_OF_CHAIN)
 
 #define SD_EMMC_CMD_CFG 0x50
 #define SD_EMMC_CMD_ARG 0x54
@@ -170,6 +169,7 @@ struct meson_host {
dma_addr_t descs_dma_addr;
 
int irq;
+   u32 irq_en;
 
bool vqmmc_enabled;
 };
@@ -842,22 +842,24 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
struct meson_host *host = dev_id;
struct mmc_command *cmd;
struct mmc_data *data;
-   u32 irq_en, status, raw_status;
+   u32  status, raw_status;
irqreturn_t ret = IRQ_NONE;
 
-   irq_en = readl(host->regs + SD_EMMC_IRQ_EN);
+   /* Disable irqs */
+   writel(0, host->regs + SD_EMMC_IRQ_EN);
+
raw_status = readl(host->regs + SD_EMMC_STATUS);
-   status = raw_status & irq_en;
+   status = raw_status & host->irq_en;
 
if (!status) {
dev_dbg(host->dev,
"Unexpected IRQ! irq_en 0x%08x - status 0x%08x\n",
-irq_en, raw_status);
-   return IRQ_NONE;
+host->irq_en, raw_status);
+   goto none;
}
 
if (WARN_ON(!host) || WARN_ON(!host->cmd))
-   return IRQ_NONE;
+   goto none;
 
/* ack all raised interrupts */
writel(status, host->regs + SD_EMMC_STATUS);
@@ -908,6 +910,11 @@ static irqreturn_t meson_mmc_irq(int irq, void *dev_id)
if (ret == IRQ_HANDLED)
meson_mmc_request_done(host->mmc, cmd->mrq);
 
+none:
+   /* Enable the irq again if the thread will not run */
+   if (ret != IRQ_WAKE_THREAD)
+   writel(host->irq_en, host->regs + SD_EMMC_IRQ_EN);
+
return ret;
 }
 
@@ -934,15 +941,17 @@ static irqreturn_t meson_mmc_irq_thread(int irq, void 
*dev_id)
struct mmc_command *next_cmd, *cmd = host->cmd;
struct mmc_data *data;
unsigned int xfer_bytes;
+   int ret = IRQ_HANDLED;
 
-   if (WARN_ON(!cmd))
-   return IRQ_NONE;
+   if (WARN_ON(!cmd)) {
+   ret = IRQ_NONE;
+   goto out;
+   }
 
if (cmd->error) {
meson_mmc_wait_desc_stop(host);
meson_mmc_request_done(host->mmc, cmd->mrq);
-
-   return IRQ_HANDLED;
+   goto out;
}
 
data = cmd->data;
@@ -959,7 +968,10 @@ static irqreturn_t meson_mmc_irq_thread(int irq, void 
*dev_id)
else
meson_mmc_request_done(host->mmc, cmd->mrq);
 
-   return IRQ_HANDLED;
+out:
+   /* Re-enable the irqs */
+   writel(host->irq_en, host->regs + SD_EMMC_IRQ_EN);
+   return ret;
 }
 
 /*
@@ -1133,13 +1145,12 @@ static int meson_mmc_probe(struct platform_device *pdev)
 
/* clear, ack and enable interrupts */
writel(0, host->regs + SD_EMMC_IRQ_EN);
-   writel(IRQ_CRC_ERR | IRQ_TIMEOUTS | IRQ_END_OF_CHAIN,
-  host->regs + SD_EMMC_STATUS);
-   writel(IRQ_CRC_ERR | IRQ_TIMEOUTS | IRQ_END_OF_CHAIN,
-  host->regs + SD_EMMC_IRQ_EN);
+   host->irq_en = IRQ_EN_MASK;
+   writel(host->irq_en, host->regs + SD_EMMC_STATUS);
+   writel(host->irq_en, host->regs + SD_EMMC_IRQ_EN);
 
 

[GIT PULL] Power management fixes for v5.9-rc8

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-5.9-rc8

with top-most commit 7bbe8f2a7e7e819c050212a4bc984f03dc85af9d

 Merge branch 'pm-cpufreq'

on top of commit a1b8638ba1320e6684aa98233c15255eb803fac7

 Linux 5.9-rc7

to receive power management fixes for 5.9-rc8.

These fix one more issue related to the recent RCU-lockdep
changes, a typo in documentation and add a missing return
statement to intel_pstate.

Specifics:

 - Fix up RCU usage for cpuidle on the ARM imx6q platform (Ulf
   Hansson).

 - Fix typo in the PM documentation (Yoann Congal).

 - Add return statement that is missing after recent changes
   in the intel_pstate driver (Zhang Rui).

Thanks!


---

Ulf Hansson (1):
  ARM: imx6q: Fixup RCU usage for cpuidle

Yoann Congal (1):
  Documentation: PM: Fix a reStructuredText syntax error

Zhang Rui (1):
  cpufreq: intel_pstate: Fix missing return statement

---

 Documentation/admin-guide/pm/cpuidle.rst | 2 +-
 arch/arm/mach-imx/cpuidle-imx6q.c| 4 +++-
 drivers/cpufreq/intel_pstate.c   | 1 +
 3 files changed, 5 insertions(+), 2 deletions(-)

Re: [PATCH 00/18] use semicolons rather than commas to separate statements

[Shuah Khan]

On 9/29/20 7:42 AM, Shuah Khan wrote:

On 9/29/20 7:34 AM, Joe Perches wrote:

On Tue, 2020-09-29 at 14:47 +0200, Julia Lawall wrote:

On Tue, 29 Sep 2020, Dan Carpenter wrote:
The times where commas are used deliberately to replace curly braces 
are

just evil.  Either way the code is cleaner with semi-colons.


I also found exaamples like the following to be particularly unforunate:

 fprintf(stderr,
 "page_nr %lu wrong count %Lu 
%Lu\n",

    page_nr, count,
    count_verify[page_nr]), exit(1);

The exit is very hard to see, unless you know to look for it.


I sent that patch last month.
https://patchwork.kernel.org/patch/11734877/



I see what happened. This patch touches lib, cpupower, and selftests.
Guess lost in the limbo of who takes it.

  tools/lib/subcmd/help.c    |  10 +-
  tools/power/cpupower/utils/cpufreq-set.c   |  14 +-
  tools/testing/selftests/vm/gup_benchmark.c |  18 +-
  tools/testing/selftests/vm/userfaultfd.c   | 296 +
  4 files changed, 210 insertions(+), 128 deletions(-)

I can take it through one of my trees.



Rafael, Andrew,

This patch is now applied to
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git 
fixes branch.


This spans pm, kselftest-mm tests and tools/lib and has been
in limbo for a few weeks for that reason.

I decided to take this through kselftest tree to avoid having
Joe split the patches.

thanks,
-- Shuah

Re: [mac80211_hwsim] 148fe295b7: hwsim.ap_long_preamble.fail

[Thomas Pedersen]

On 2020-10-02 01:29, kernel test robot wrote:

Greeting,

FYI, we noticed the following commit (built with gcc-9):

commit: 148fe295b7d9d892b2b0f47070233ccdc70c83cd ("mac80211_hwsim:
indicate support for S1G")
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master


in testcase: hwsim
version: hwsim-x86_64-6eb6cf0-1_20200619
with following parameters:

group: hwsim-04
ucode: 0x21



on test machine: 8 threads Intel(R) Core(TM) i7-3770K CPU @ 3.50GHz
with 16G memory

caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):


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


2020-10-06 00:22:09 ./run-tests.py ap_long_preamble
DEV: wlan0: 02:00:00:00:00:00
DEV: wlan1: 02:00:00:00:01:00
DEV: wlan2: 02:00:00:00:02:00
APDEV: wlan3
APDEV: wlan4
START ap_long_preamble 1/1
Test: AP with long preamble
Starting AP wlan3
Failed to enable hostapd interface wlan3
Traceback (most recent call last):
  File "./run-tests.py", line 533, in main
t(dev, apdev)
  File "/lkp/benchmarks/hwsim/tests/hwsim/test_ap_params.py", line
821, in test_ap_long_preamble
hapd = hostapd.add_ap(apdev[0], params)
  File "/lkp/benchmarks/hwsim/tests/hwsim/hostapd.py", line 581, in 
add_ap

hapd.enable()
  File "/lkp/benchmarks/hwsim/tests/hwsim/hostapd.py", line 248, in 
enable
raise Exception("Failed to enable hostapd interface " + 
self.ifname)

Exception: Failed to enable hostapd interface wlan3
FAIL ap_long_preamble 0.064398 2020-10-06 00:22:09.608978
passed 0 test case(s)
skipped 0 test case(s)
failed tests: ap_long_preamble


This is actually a bug in hostap which was exposed by this commit (and 
fixed by 
https://patchwork.ozlabs.org/project/hostap/patch/20200827225940.18151-1-tho...@adapt-ip.com/).


--
thomas

Re: [LKP] Re: [drm/dp] 6509ca051a: PANIC:double_fault

[Ville Syrjälä]

On Tue, Sep 29, 2020 at 01:26:09PM +0800, Rong Chen wrote:
> 
> 
> On 9/25/20 12:42 AM, Ville Syrjälä wrote:
> > On Thu, Sep 24, 2020 at 10:30:49PM +0800, kernel test robot wrote:
> >> Greeting,
> >>
> >> FYI, we noticed the following commit (built with gcc-9):
> >>
> >> commit: 6509ca051abf4ff60d63732badcb2173a715f741 ("drm/dp: Add 
> >> drm_dp_downstream_{min,max}_tmds_clock()")
> > That doesn't really do anything on its own. So can't see how it would
> > make anything blow up.
> 
> Hi Ville,
> 
> The issue is 100% reproducible, could you try the reproduce steps:
> 
> To reproduce:
> 
>  # build kernel
>   cd linux
>   cp config-5.9.0-rc4-00881-g6509ca051abf4 .config
>   make HOSTCC=gcc-9 CC=gcc-9 ARCH=i386 olddefconfig prepare 
> modules_prepare bzImage
> 
>  git clone https://github.com/intel/lkp-tests.git
>  cd lkp-tests
>  bin/lkp qemu -k  job-script # job-script is attached in 
> this email

Managed to find some Ubuntu machine where that would run.

$ time ./bin/lkp qemu -k ~/bzImage ~/job-script
...
[0.00] Linux version 5.9.0-rc4-00027-g6509ca051abf (...) (gcc (Gentoo 
9.3.0-r1 p3) 9.3.0, GNU ld (Gentoo 2.33.1 p2) 2.33.1) #2 SMP PREEMPT Fri Oct 2 
19:24:28 EEST 2020
...
[   12.717392] Applicom driver: $Id: ac.c,v 1.30 2000/03/22 16:03:57 dwmw2 Exp $
[   12.718889] ac.o: No PCI boards found.
[   12.719696] ac.o: For an ISA board you must supply memory and irq parameters.
[   12.721269] toshiba: not a supported Toshiba laptop
[   12.722779] random: get_random_u32 called from arch_rnd+0x1c/0x40 with 
crng_init=0
[   12.722784] random: get_random_u32 called from randomize_stack_top+0x35/0x50 
with crng_init=0
[   12.722787] random: get_random_u32 called from arch_align_stack+0x35/0x50 
with crng_init=0
...
real11m35,352s
user13m40,549s
sys 0m13,071s
$ echo $?
0

-- 
Ville Syrjälä
Intel

[PATCH 0/2] Enable GPIO and I2C configs for TI's J721e platform

[Faiz Abbas]

The following patches enable configs in the arm64 defconfig to support
GPIO and I2C support on TI's J721e platform.

Faiz Abbas (2):
  arm64: defconfig: Enable OMAP I2C driver
  arm64: defconfig: Enable DAVINCI_GPIO driver

 arch/arm64/configs/defconfig | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.17.1

[PATCH 2/2] arm64: defconfig: Enable DAVINCI_GPIO driver

[Faiz Abbas]

Enable support for devices compatible with TI's davinci gpio controllers.

Signed-off-by: Faiz Abbas 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0d5b81264fa1..c4b657644e33 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -497,6 +497,7 @@ CONFIG_PINCTRL_SDM845=y
 CONFIG_PINCTRL_SM8150=y
 CONFIG_PINCTRL_SM8250=y
 CONFIG_GPIO_ALTERA=m
+CONFIG_GPIO_DAVINCI=y
 CONFIG_GPIO_DWAPB=y
 CONFIG_GPIO_MB86S7X=y
 CONFIG_GPIO_MPC8XXX=y
-- 
2.17.1

[PATCH 1/2] arm64: defconfig: Enable OMAP I2C driver

[Faiz Abbas]

Enable support for devices compatible with TI's OMAP I2C controllers.

Signed-off-by: Faiz Abbas 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 55f9c35568bf..0d5b81264fa1 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -437,6 +437,7 @@ CONFIG_I2C_IMX=y
 CONFIG_I2C_IMX_LPI2C=y
 CONFIG_I2C_MESON=y
 CONFIG_I2C_MV64XXX=y
+CONFIG_I2C_OMAP=y
 CONFIG_I2C_OWL=y
 CONFIG_I2C_PXA=y
 CONFIG_I2C_QCOM_CCI=m
-- 
2.17.1

Re: [PATCH 3/3] task_work: use TIF_TASKWORK if available

[Jens Axboe]

On 10/2/20 9:52 AM, Jens Axboe wrote:
> On 10/2/20 9:31 AM, Thomas Gleixner wrote:
>> On Fri, Oct 02 2020 at 17:14, Oleg Nesterov wrote:
>>> Heh. To be honest I don't really like 1-2 ;)
>>
>> I do not like any of this :)
>>
>>> So I think that if we are going to add TIF_TASKWORK we should generalize
>>> this logic and turn it into TIF_NOTIFY_SIGNAL. Similar to TIF_NOTIFY_RESUME
>>> but implies signal_pending().
>>>
>>> IOW, something like
>>>
>>> void set_notify_signal(task)
>>> {
>>> if (!test_and_set_tsk_thread_flag(task, TIF_NOTIFY_SIGNAL)) {
>>> if (!wake_up_state(task, TASK_INTERRUPTIBLE))
>>> kick_process(t);
>>> }
>>> }
>>>
>>> // called by exit_to_user_mode_loop() if ti_work & _TIF_NOTIFY_SIGNAL
>>> void tracehook_notify_signal(regs)
>>> {
>>> clear_thread_flag(TIF_NOTIFY_SIGNAL);
>>> smp_mb__after_atomic();
>>> if (unlikely(current->task_works))
>>> task_work_run();
>>> }
>>>
>>> This way task_work_run() doesn't need to clear TIF_NOTIFY_SIGNAL and it can
>>> have more users.
>>
>> I think it's fundamentaly wrong that we have several places and several
>> flags which handle task_work_run() instead of having exactly one place
>> and one flag.
> 
> I don't disagree with that. I know it's not happening in this series, but
> if we to the TIF_NOTIFY_SIGNAL route and get all archs supporting that,
> then we can kill the signal and notify resume part of running task_work.
> And that leaves us with exactly one place that runs it.
> 
> So we can potentially improve the current situation in that regard.

I re-spun (and re-tested) the series, now based on TIF_NOTIFY_SIGNAL
instead. I won't be sending this one out before we've discussed it
some more, but wanted to let you know what it currently looks like:

https://git.kernel.dk/cgit/linux-block/log/?h=tif-task_work

-- 
Jens Axboe

Re: [PATCH v3 0/3] media: rockchip: Introduce driver for Rockchip's camera interface

[Dafna Hirschfeld]

Am 02.10.20 um 18:31 schrieb Ezequiel Garcia:

Hi Maxime,

On Tue, 22 Sep 2020 at 13:55, Maxime Chevallier
 wrote:


Hi everyone,

This is the third iteration of the series introducing a driver for the
PX30 camera interface.

This was previously known as the "cif" driver in other iterations, but
was renamed to "vip" following Ezequiel's advices to match the datasheet
name.

This is based on a BSP driver, and I'm not fully familiar with the media
and V4L2 frameworks, so I guess some review is still needed.

This new series adds some stability fixes, and introduces the
double-buffering frame handling, giving better performances.

Thanks to everyone who reviewed the first two iterations,

Maxime

Maxime Chevallier (3):
   media: dt-bindings: media: Document Rockchip VIP bindings
   media: rockchip: Introduce driver for Rockhip's camera interface


I can't find this "v3 2/3 media: rockchip: Introduce driver for
Rockhip's camera interface" patch in my mailbox. Perhaps it was too
large and got filtered?
Or maybe it's an issue on my side?


I do see it on my mailbox, if it helps..

Dafna,



Cheers,
Ezequiel

Re: [PATCH v2 3/3] dt-bindings: thermal: update sustainable-power with abstract scale

[Lukasz Luba]

On 10/2/20 4:47 PM, Doug Anderson wrote:

Hi,

On Fri, Oct 2, 2020 at 8:13 AM Lukasz Luba  wrote:


Hi Doug,

On 10/2/20 3:31 PM, Doug Anderson wrote:

Hi,

On Fri, Oct 2, 2020 at 4:45 AM Lukasz Luba  wrote:


Update the documentation for the binding 'sustainable-power' and allow
to provide values in an abstract scale. It is required when the cooling
devices use an abstract scale for their power values.

Signed-off-by: Lukasz Luba 
---
   .../devicetree/bindings/thermal/thermal-zones.yaml  | 13 +
   1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml 
b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
index 3ec9cc87ec50..4d8f2e37d1e6 100644
--- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
+++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
@@ -99,10 +99,15 @@ patternProperties:
 sustainable-power:
   $ref: /schemas/types.yaml#/definitions/uint32
   description:
-  An estimate of the sustainable power (in mW) that this thermal zone
-  can dissipate at the desired control temperature. For reference, the
-  sustainable power of a 4-inch phone is typically 2000mW, while on a
-  10-inch tablet is around 4500mW.
+  An estimate of the sustainable power (in mW or in an abstract scale)
+ that this thermal zone can dissipate at the desired control
+ temperature. For reference, the sustainable power of a 4-inch phone
+ is typically 2000mW, while on a 10-inch tablet is around 4500mW.
+
+ It is possible to express the sustainable power in an abstract
+ scale. This is the case when the related cooling devices use also
+ abstract scale to express their power usage. The scale must be
+ consistent.


Two thoughts:

1. If we're going to allow "sustainable-power" to be in abstract
scale, why not allow "dynamic-power-coefficient" to be in abstract
scale too?  I assume that the whole reason against that originally was
the idea of device tree purity, but if we're allowing the abstract
scale here then there seems no reason not to allow it for
"dynamic-power-coefficient".


With this binding it's a bit more tricky.
I also have to discuss a few things internally. This requirement of
uW/MHz/V^2 makes the code easier also for potential drivers
like GPU (which are going to register the devfreq cooling with EM).

Let me think about it, but for now I would just update these bits.
These are required to proper IPA operation, the dyn.-pow.-coef. is a
nice to have and possible next step.


I guess the problem is that Rajendra is currently planning to remove
all the "dynamic-power-coefficient" values from device tree right now
and move them to the source code because the numbers we currently have
in the device tree _are_ in abstract scale and thus violate the
bindings.  Moving this to source code won't help us get to more real
power numbers (since it'll still be abstract scale), it'll just be
pure churn.  If we're OK with the abstract scale in general then we
should allow it everywhere and not add churn for no reason.


IIUC he is still going to use the Energy Model, but with different
registration function. We have such a driver: scmi-cpufreq.c, which
uses em_dev_register_perf_domain(). He can still use EM, EAS, IPA
not violating anything.

The real problem that we want to address is with sustainable-power in
IPA. It is used in power budget calculation and if the devices operate
in abstract scale, then there is an issue.
There are two options to get that value:
1. from DT, which can have optimized value, stored by OEM engineer
2. from IPA estimation code, which just calculates it as a sum of
minimum OPP power for each cooling device.

The 2nd option might not be the best for a platform, so vendor/OEM
engineer might want to provide a better value in DT -> 1st option.
This is currently against the binding description and I have to fix it.





2. Is it worth adding some type of indication of what type of units
"sustainable-power" is represented in?  Maybe even a made up unit so
that you could tell the difference between made up units in the same
system?  I'd envision something like:

sustainable-power-units = "qualcomm,sc7180-bogoWatts"

...and on the dynamic-power-coefficient side, the same:

dynamic-power-coefficient-units = "qualcomm,sc7180-bogoWatts"

One could imagine someone even later (after devices are widely
distributed) figuring out translations between these bogoWatts numbers
and real Watts if someone could come up with a case where it matters.


To figure this out we don't need a new binding.
I think a simple comment in the DT would be enough for this, even e.g.:

sustainable-power = <100> /* bogoWatts */


There are some important differences:

a) Your comment is gone when the device tree is compiled.  If we
actually add a string to the device tree then, in theory, we can add

[RESEND PATCH v3] arm64: dts: renesas: align GPIO hog names with dtschema

[Krzysztof Kozlowski]

The convention for node names is to use hyphens, not underscores.
dtschema for pca95xx expects GPIO hogs to end with 'hog' suffix.

Signed-off-by: Krzysztof Kozlowski 
---
 .../boot/dts/renesas/r8a77951-salvator-xs.dts  |  2 +-
 .../boot/dts/renesas/r8a77965-salvator-xs.dts  |  2 +-
 arch/arm64/boot/dts/renesas/ulcb-kf.dtsi   | 14 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

The dt-schema changes were applied.

diff --git a/arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dts
index cef9da4376a3..e5922329a4b8 100644
--- a/arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77951-salvator-xs.dts
@@ -118,7 +118,7 @@
 };
 
  {
-   pcie_sata_switch {
+   pcie-sata-switch-hog {
gpio-hog;
gpios = <7 GPIO_ACTIVE_HIGH>;
output-low; /* enable SATA by default */
diff --git a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts 
b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
index 5cef64605464..d7e621101af7 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
+++ b/arch/arm64/boot/dts/renesas/r8a77965-salvator-xs.dts
@@ -55,7 +55,7 @@
 };
 
  {
-   pcie_sata_switch {
+   pcie-sata-switch-hog {
gpio-hog;
gpios = <7 GPIO_ACTIVE_HIGH>;
output-low; /* enable SATA by default */
diff --git a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi 
b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
index 202177706cde..e9ed2597f1c2 100644
--- a/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
+++ b/arch/arm64/boot/dts/renesas/ulcb-kf.dtsi
@@ -143,49 +143,49 @@
interrupt-parent = <>;
interrupts = <8 IRQ_TYPE_EDGE_FALLING>;
 
-   audio_out_off {
+   audio-out-off-hog {
gpio-hog;
gpios = <0 GPIO_ACTIVE_HIGH>; /* P00 */
output-high;
line-name = "Audio_Out_OFF";
};
 
-   hub_pwen {
+   hub-pwen-hog {
gpio-hog;
gpios = <6 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "HUB pwen";
};
 
-   hub_rst {
+   hub-rst-hog {
gpio-hog;
gpios = <7 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "HUB rst";
};
 
-   otg_extlpn {
+   otg-extlpn-hog {
gpio-hog;
gpios = <9 GPIO_ACTIVE_HIGH>;
output-high;
line-name = "OTG EXTLPn";
};
 
-   otg_offvbusn {
+   otg-offvbusn-hog {
gpio-hog;
gpios = <8 GPIO_ACTIVE_HIGH>;
output-low;
line-name = "OTG OFFVBUSn";
};
 
-   sd-wifi-mux {
+   sd-wifi-mux-hog {
gpio-hog;
gpios = <5 GPIO_ACTIVE_HIGH>;
output-low; /* Connect WL1837 */
line-name = "SD WiFi mux";
};
 
-   snd_rst {
+   snd-rst-hog {
gpio-hog;
gpios = <15 GPIO_ACTIVE_HIGH>; /* P17 */
output-high;
-- 
2.17.1

[RESEND PATCH v3] arm64: dts: mediatek: align GPIO hog names with dtschema

[Krzysztof Kozlowski]

The convention for node names is to use hyphens, not underscores.
dtschema for pca95xx expects GPIO hogs to end with 'hog' suffix.

Signed-off-by: Krzysztof Kozlowski 
---
 .../boot/dts/mediatek/pumpkin-common.dtsi | 26 +--
 1 file changed, 13 insertions(+), 13 deletions(-)

The dt-schema changes were applied.

diff --git a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi 
b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
index 29d8cf6df46b..351a1905a074 100644
--- a/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
+++ b/arch/arm64/boot/dts/mediatek/pumpkin-common.dtsi
@@ -63,91 +63,91 @@
gpio-controller;
#gpio-cells = <2>;
 
-   eint20_mux_sel0 {
+   eint20-mux-sel0-hog {
gpio-hog;
gpios = <0 0>;
input;
line-name = "eint20_mux_sel0";
};
 
-   expcon_mux_sel1 {
+   expcon-mux-sel1-hog {
gpio-hog;
gpios = <1 0>;
input;
line-name = "expcon_mux_sel1";
};
 
-   mrg_di_mux_sel2 {
+   mrg-di-mux-sel2-hog {
gpio-hog;
gpios = <2 0>;
input;
line-name = "mrg_di_mux_sel2";
};
 
-   sd_sdio_mux_sel3 {
+   sd-sdio-mux-sel3-hog {
gpio-hog;
gpios = <3 0>;
input;
line-name = "sd_sdio_mux_sel3";
};
 
-   sd_sdio_mux_ctrl7 {
+   sd-sdio-mux-ctrl7-hog {
gpio-hog;
gpios = <7 0>;
output-low;
line-name = "sd_sdio_mux_ctrl7";
};
 
-   hw_id0 {
+   hw-id0-hog {
gpio-hog;
gpios = <8 0>;
input;
line-name = "hw_id0";
};
 
-   hw_id1 {
+   hw-id1-hog {
gpio-hog;
gpios = <9 0>;
input;
line-name = "hw_id1";
};
 
-   hw_id2 {
+   hw-id2-hog {
gpio-hog;
gpios = <10 0>;
input;
line-name = "hw_id2";
};
 
-   fg_int_n {
+   fg-int-n-hog {
gpio-hog;
gpios = <11 0>;
input;
line-name = "fg_int_n";
};
 
-   usba_pwr_en {
+   usba-pwr-en-hog {
gpio-hog;
gpios = <12 0>;
output-high;
line-name = "usba_pwr_en";
};
 
-   wifi_3v3_pg {
+   wifi-3v3-pg-hog {
gpio-hog;
gpios = <13 0>;
input;
line-name = "wifi_3v3_pg";
};
 
-   cam_rst {
+   cam-rst-hog {
gpio-hog;
gpios = <14 0>;
output-low;
line-name = "cam_rst";
};
 
-   cam_pwdn {
+   cam-pwdn-hog {
gpio-hog;
gpios = <15 0>;
output-low;
-- 
2.17.1

[RESEND PATCH v3 1/2] ARM: dts: aspeed: fix PCA95xx GPIO expander properties on Portwell

[Krzysztof Kozlowski]

The PCA95xx GPIO expander requires GPIO controller properties to operate
properly.

Signed-off-by: Krzysztof Kozlowski 
Acked-by: Joel Stanley 
---
 arch/arm/boot/dts/aspeed-bmc-portwell-neptune.dts | 2 ++
 1 file changed, 2 insertions(+)

The dt-schema changes were applied.

diff --git a/arch/arm/boot/dts/aspeed-bmc-portwell-neptune.dts 
b/arch/arm/boot/dts/aspeed-bmc-portwell-neptune.dts
index 4a1ca8f5b6a7..03c161493ffc 100644
--- a/arch/arm/boot/dts/aspeed-bmc-portwell-neptune.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-portwell-neptune.dts
@@ -121,6 +121,8 @@
pca9555@27 {
compatible = "nxp,pca9555";
reg = <0x27>;
+   gpio-controller;
+   #gpio-cells = <2>;
};
 };
 
-- 
2.17.1

[RESEND PATCH v3 2/2] ARM: dts: aspeed: align GPIO hog names with dtschema

[Krzysztof Kozlowski]

dtschema for pca95xx expects GPIO hogs to end with 'hog' suffix.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts |  2 +-
 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts  | 16 
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts 
b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
index 21ae880c7530..d5ac379c909e 100644
--- a/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
@@ -564,7 +564,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus0 {
+   smbus0-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts 
b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
index cb85168f6761..577c211c469e 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
@@ -827,7 +827,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus0 {
+   smbus0-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
@@ -852,7 +852,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus1 {
+   smbus1-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
@@ -900,7 +900,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus2 {
+   smbus2-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
@@ -925,7 +925,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus3 {
+   smbus3-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
@@ -992,7 +992,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus4 {
+   smbus4-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
@@ -1017,7 +1017,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus5 {
+   smbus5-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
@@ -1065,7 +1065,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus6 {
+   smbus6-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
@@ -1090,7 +1090,7 @@
gpio-controller;
#gpio-cells = <2>;
 
-   smbus7 {
+   smbus7-hog {
gpio-hog;
gpios = <4 GPIO_ACTIVE_HIGH>;
output-high;
-- 
2.17.1

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

[Dmitry Osipenko]

02.10.2020 19:00, Dmitry Osipenko пишет:
> 02.10.2020 18:23, Dmitry Osipenko пишет:
>> 02.10.2020 09:08, Nicolin Chen пишет:
>>> Then when a client gets probed, of_iommu_configure() in
>>> iommu core will search DTB for swgroup ID and call ->of_xlate()
>>> to prepare an fwspec, similar to tegra_smmu_probe_device() and
>>> tegra_smmu_configure(). Then it'll call tegra_smmu_probe_device()
>>> again, and this time we shall return smmu->iommu pointer properly.
>>
>> I don't quite see where IOMMU core calls of_xlate().
>>
>> Have tried to at least boot-test this patch?
>>
> 
> I don't see how it ever could work because of_xlate() is only invoked from:
> 
> fsl_mc_dma_configure()->of_dma_configure_id()->of_iommu_configure()
> 
> Looks like the tegra_smmu_configure() is still needed.
> 
> I don't know how sun50i driver could work to be honest. Seems IOMMU is
> broken on sun50i, but maybe I'm missing something.
> 
> I added Maxime Ripard to this thread, who is the author of the
> sun50i-iommu driver.
> 

Actually, I now see that the other IOMMU drivers (qcom, exynos, etc) do
the same. So obviously I'm missing something and it should work..

Re: [PATCH 1/2] mmap locking API: Order lock of nascent mm outside lock of live mm

[Jann Horn]

On Fri, Oct 2, 2020 at 11:18 AM Michel Lespinasse  wrote:
> On Thu, Oct 1, 2020 at 6:25 PM Jann Horn  wrote:
> > Until now, the mmap lock of the nascent mm was ordered inside the mmap lock
> > of the old mm (in dup_mmap() and in UML's activate_mm()).
> > A following patch will change the exec path to very broadly lock the
> > nascent mm, but fine-grained locking should still work at the same time for
> > the new mm.
> > To do this in a way that lockdep is happy about, let's turn around the lock
> > ordering in both places that currently nest the locks.
> > Since SINGLE_DEPTH_NESTING is normally used for the inner nesting layer,
> > make up our own lock subclass MMAP_LOCK_SUBCLASS_NASCENT and use that
> > instead.
> >
> > The added locking calls in exec_mmap() are temporary; the following patch
> > will move the locking out of exec_mmap().
>
> Thanks for doing this.
>
> This is probably a silly question, but I am not sure exactly where we
> lock the old MM while bprm is creating the new MM ? I am guessing this
> would be only in setup_arg_pages(), copying the args and environment
> from the old the the new MM ? If that is correct, then wouldn't it be
> sufficient to use mmap_write_lock_nested in setup_arg_pages() ? Or, is
> the issue that we'd prefer to have a killable version of it there ?

We're also implicitly locking the old MM anytime we take page faults
before exec_mmap(), which basically means the various userspace memory
accesses in do_execveat_common(). This happens after bprm_mm_init(),
so we've already set bprm->vma at that point.

> Also FYI I was going to play with these patches a bit to help answer
> these questions on my own, but wasn't able to easily apply them as
> they came lightly mangled (whitespace issues) when I saved them.

Uuugh, dammit, I see what happened. Sorry about the trouble. Thanks
for telling me, guess I'll go back to sending patches the way I did it
before. :/

I guess I'll go make a v2 of this with some extra comment about where
the old MM is accessed, as Jason suggested, and without the whitespace
issues?

Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance

[Randy Dunlap]

On 10/2/20 8:39 AM, Van Leeuwen, Pascal wrote:
>> -Original Message-
>> From: Greg Kroah-Hartman 
>> Sent: Friday, October 2, 2020 5:13 PM
>> To: Van Leeuwen, Pascal 
>> Cc: Torsten Duwe ; Theodore Y. Ts'o ; 
>> linux-cry...@vger.kernel.org; Nicolai Stange
>> ; LKML ; Arnd Bergmann 
>> ; Eric W. Biederman
>> ; Alexander E. Patrakov ; Ahmed 
>> S. Darwish ; Willy
>> Tarreau ; Matthew Garrett ; Vito Caputo 
>> ; Andreas Dilger
>> ; Jan Kara ; Ray Strode 
>> ; William Jon McCann ;
>> zhangjs ; Andy Lutomirski ; 
>> Florian Weimer ; Lennart
>> Poettering ; Peter Matthias 
>> ; Marcelo Henrique Cerri
>> ; Neil Horman ; Randy 
>> Dunlap ; Julia Lawall
>> ; Dan Carpenter ; Andy Lavr 
>> ; Eric Biggers
>> ; Jason A. Donenfeld ; Stephan Müller 
>> ; Petr Tesarik
>> 
>> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST 
>> SP800-90B compliance
>>
>> <<< External Email >>>
>> On Fri, Oct 02, 2020 at 02:34:44PM +, Van Leeuwen, Pascal wrote:
>>>
>>>
>>>
 -Original Message-
 From: Greg Kroah-Hartman 
 Sent: Friday, October 2, 2020 4:04 PM
 To: Van Leeuwen, Pascal 
 Cc: Torsten Duwe ; Theodore Y. Ts'o ; 
 linux-cry...@vger.kernel.org; Nicolai Stange
 ; LKML ; Arnd Bergmann 
 ; Eric W. Biederman
 ; Alexander E. Patrakov ; Ahmed 
 S. Darwish ; Willy
 Tarreau ; Matthew Garrett ; Vito Caputo 
 ; Andreas Dilger
 ; Jan Kara ; Ray Strode 
 ; William Jon McCann
>> ;
 zhangjs ; Andy Lutomirski ; 
 Florian Weimer ; Lennart
 Poettering ; Peter Matthias 
 ; Marcelo Henrique Cerri
 ; Neil Horman ; Randy 
 Dunlap ; Julia Lawall
 ; Dan Carpenter ; Andy 
 Lavr ; Eric Biggers
 ; Jason A. Donenfeld ; Stephan 
 Müller ; Petr Tesarik
 
 Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST 
 SP800-90B compliance

 <<< External Email >>>
 On Fri, Oct 02, 2020 at 01:35:18PM +, Van Leeuwen, Pascal wrote:
> ** This message and any attachments are for the sole use of the intended 
> recipient(s). It may contain information that is
 confidential and privileged. If you are not the intended recipient of this 
 message, you are prohibited from printing, copying,
 forwarding or saving it. Please delete the message and attachments and 
 notify the sender immediately. **

 As per my legal department requests, this is now ignored and deleted on
 my system...

 Hint, it's not a valid footer for public mailing lists...

 greg k-h
>>> It's automatically added by our company mail server ... not something I can 
>>> control at all :-(
>>
>> Then your company can not contribute in Linux kernel development, as
>> this is obviously not allowed by such a footer.
>>
> Interesting, this has never been raised as a problem until today ...
> Going back through my mail archive, it looks like they started automatically 
> adding that some
> 3 months ago. Not that they informed anyone about that, it just silently 
> happened.
> 
>> Please work with your IT and legal department to fix this.
>>
> Eh ... Greg ... that's not how that works in the real world. In the real 
> world, legal and IT lay
> down the law and you just comply with that (or hack your way around it, if 
> you can ;-).

That's how it worked at $big_companies that I have worked at.

If it's a company/business requirement that you do Linux kernel development 
work, (is it?)
then they should make that possible on internal systems or give you access to
external email server(s).

> I'm already fighting the good fight trying to keep control of my development 
> machines
> because IT would just love to get rid of those (since not under IT control 
>  oh dear ...)
> And obviously, you cannot do kernel development on a machine without root 
> access.
> It's annoying enough already to require IT support to provide explicit 
> permission to open
> the task manager on my own company laptop ... grmbl.
> 
>>
>> thanks,
>>
>> greg k-h
> 
> Regards,
> Pascal van Leeuwen
> Silicon IP Architect Multi-Protocol Engines, Rambus Security
> Rambus ROTW Holding BV
> +31-73 6581953
> 
> Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by 
> Rambus.
> Please be so kind to update your e-mail address book with my new e-mail 
> address.
> 
> 
> ** This message and any attachments are for the sole use of the intended 
> recipient(s). It may contain information that is confidential and privileged. 
> If you are not the intended recipient of this message, you are prohibited 
> from printing, copying, forwarding or saving it. Please delete the message 
> and attachments and notify the sender immediately. **
> 
> Rambus Inc.
> 


-- 
~Randy

Re: [PATCH v3 0/3] media: rockchip: Introduce driver for Rockchip's camera interface

[Ezequiel Garcia]

Hi Maxime,

On Tue, 22 Sep 2020 at 13:55, Maxime Chevallier
 wrote:
>
> Hi everyone,
>
> This is the third iteration of the series introducing a driver for the
> PX30 camera interface.
>
> This was previously known as the "cif" driver in other iterations, but
> was renamed to "vip" following Ezequiel's advices to match the datasheet
> name.
>
> This is based on a BSP driver, and I'm not fully familiar with the media
> and V4L2 frameworks, so I guess some review is still needed.
>
> This new series adds some stability fixes, and introduces the
> double-buffering frame handling, giving better performances.
>
> Thanks to everyone who reviewed the first two iterations,
>
> Maxime
>
> Maxime Chevallier (3):
>   media: dt-bindings: media: Document Rockchip VIP bindings
>   media: rockchip: Introduce driver for Rockhip's camera interface

I can't find this "v3 2/3 media: rockchip: Introduce driver for
Rockhip's camera interface" patch in my mailbox. Perhaps it was too
large and got filtered?
Or maybe it's an issue on my side?

Cheers,
Ezequiel

Re: [PATCH 1/3] watchdog: cadence: Simplify with dev_err_probe()

[Krzysztof Kozlowski]

On Tue, Sep 01, 2020 at 08:49:52AM -0700, Guenter Roeck wrote:
> On Tue, Sep 01, 2020 at 05:31:39PM +0200, Krzysztof Kozlowski wrote:
> > Common pattern of handling deferred probe can be simplified with
> > dev_err_probe().  Less code and the error value gets printed.
> > 
> > Signed-off-by: Krzysztof Kozlowski 
> 
> Reviewed-by: Guenter Roeck 

Thanks for the review. Who could pick up these patches?

Best regards,
Krzysztof

drivers/net/wireless/realtek/rtw88/rtw8822c.c:2456:5: warning: variable 'corr_val' set but not used

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   472e5b056f000a778abb41f1e443de58eb259783
commit: ba0fbe236fb8a7b992e82d6eafb03a600f5eba43 rtw88: extract: make 8822c an 
individual kernel module
date:   5 months ago
config: parisc-randconfig-r024-20201002 (attached as .config)
compiler: hppa-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ba0fbe236fb8a7b992e82d6eafb03a600f5eba43
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout ba0fbe236fb8a7b992e82d6eafb03a600f5eba43
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=parisc 

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

All warnings (new ones prefixed by >>):

   In file included from include/linux/mm.h:95,
from include/linux/bvec.h:13,
from include/linux/skbuff.h:17,
from include/linux/if_ether.h:19,
from include/net/mac80211.h:18,
from drivers/net/wireless/realtek/rtw88/main.h:8,
from drivers/net/wireless/realtek/rtw88/rtw8822c.c:6:
   include/asm-generic/pgtable.h: In function 'pte_clear_not_present_full':
   arch/parisc/include/asm/pgtable.h:96:9: warning: variable 'old_pte' set but 
not used [-Wunused-but-set-variable]
  96 |   pte_t old_pte; \
 | ^~~
   arch/parisc/include/asm/pgtable.h:322:34: note: in expansion of macro 
'set_pte_at'
 322 | #define pte_clear(mm, addr, xp)  set_pte_at(mm, addr, xp, __pte(0))
 |  ^~
   include/asm-generic/pgtable.h:202:2: note: in expansion of macro 'pte_clear'
 202 |  pte_clear(mm, address, ptep);
 |  ^
   include/asm-generic/pgtable.h: In function '__ptep_modify_prot_commit':
   arch/parisc/include/asm/pgtable.h:96:9: warning: variable 'old_pte' set but 
not used [-Wunused-but-set-variable]
  96 |   pte_t old_pte; \
 | ^~~
   include/asm-generic/pgtable.h:641:2: note: in expansion of macro 'set_pte_at'
 641 |  set_pte_at(vma->vm_mm, addr, ptep, pte);
 |  ^~
   drivers/net/wireless/realtek/rtw88/rtw8822c.c: In function 
'rtw8822c_dpk_dc_corr_check':
>> drivers/net/wireless/realtek/rtw88/rtw8822c.c:2456:5: warning: variable 
>> 'corr_val' set but not used [-Wunused-but-set-variable]
2456 |  u8 corr_val, corr_idx;
 | ^~~~
--
   In file included from arch/parisc/include/asm/io.h:6,
from include/linux/io.h:13,
from include/linux/irq.h:20,
from arch/parisc/include/asm/hardirq.h:13,
from include/linux/hardirq.h:9,
from include/linux/interrupt.h:11,
from include/linux/pci.h:38,
from drivers/net/wireless/realtek/rtw88/pci.c:6:
   include/asm-generic/pgtable.h: In function 'pte_clear_not_present_full':
   arch/parisc/include/asm/pgtable.h:96:9: warning: variable 'old_pte' set but 
not used [-Wunused-but-set-variable]
  96 |   pte_t old_pte; \
 | ^~~
   arch/parisc/include/asm/pgtable.h:322:34: note: in expansion of macro 
'set_pte_at'
 322 | #define pte_clear(mm, addr, xp)  set_pte_at(mm, addr, xp, __pte(0))
 |  ^~
   include/asm-generic/pgtable.h:202:2: note: in expansion of macro 'pte_clear'
 202 |  pte_clear(mm, address, ptep);
 |  ^
   include/asm-generic/pgtable.h: In function '__ptep_modify_prot_commit':
   arch/parisc/include/asm/pgtable.h:96:9: warning: variable 'old_pte' set but 
not used [-Wunused-but-set-variable]
  96 |   pte_t old_pte; \
 | ^~~
   include/asm-generic/pgtable.h:641:2: note: in expansion of macro 'set_pte_at'
 641 |  set_pte_at(vma->vm_mm, addr, ptep, pte);
 |  ^~
   drivers/net/wireless/realtek/rtw88/pci.c: At top level:
>> drivers/net/wireless/realtek/rtw88/pci.c:1477:5: warning: no previous 
>> prototype for 'rtw_pci_probe' [-Wmissing-prototypes]
1477 | int rtw_pci_probe(struct pci_dev *pdev,
 | ^
>> drivers/net/wireless/realtek/rtw88/pci.c:1557:6: warning: no previous 
>> prototype for 'rtw_pci_remove' [-Wmissing-prototypes]
1557 | void rtw_pci_remove(struct pci_dev *pdev)
 |  ^~
>> drivers/net/wireless/realtek/rtw88/pci.c:1579:6: warning: no previous 
>> prototype for 'rtw_pci_shutdown' [-Wmissing

Re: [PATCH v3] mailbox: mediatek: Fix handling of platform_get_irq() error

[Krzysztof Kozlowski]

On Thu, Aug 27, 2020 at 08:25:07PM +0200, Krzysztof Kozlowski wrote:
> platform_get_irq() returns -ERRNO on error.  In such case casting to u32
> and comparing to 0 would pass the check.
> 
> Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v2:
> 1. Fix subject.
> 
> Changes since v1:
> 1. Correct u32->int,
> 2. Fix left-over '!'.
> ---
>  drivers/mailbox/mtk-cmdq-mailbox.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)

Any comments here? This is a bugfix.

Best regards,
Krzysztof

virtiofs: WARN_ON(out_sgs + in_sgs != total_sgs)

[Qian Cai]

Running some fuzzing on virtiofs from a non-privileged user could trigger a
warning in virtio_fs_enqueue_req():

WARN_ON(out_sgs + in_sgs != total_sgs);

# /usr/libexec/virtiofsd --socket-path=/tmp/vhostqemu -o source=$TESTDIR -o 
cache=always -o no_posix_lock
...
# mount -t virtiofs myfs /tmp
$ cd /tmp
$ trinity -C 48 --arch 64

>From the log, the final piece of the code from the process was:

ioctl(fd=343, cmd=0x5a004000, arg=0x4000);

[ 4327.977314] WARNING: CPU: 2 PID: 12259 at fs/fuse/virtio_fs.c:1151 
virtio_fs_enqueue_req+0xa86/0xdb0 [virtiofs]
[ 4327.983910] Modules linked in: cmtp kernelcapi hidp bnep bridge stp llc dlci 
pppoe rfcomm nfnetlink pptp gre can_bcm bluetooth ecdh_generic ecc l2tp_ppp 
l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppoxw
[ 4327.984068]  sunrpc dm_mirror dm_region_hash dm_log dm_mod
[ 4328.046826] CPU: 2 PID: 12259 Comm: trinity-c20 Kdump: loaded Not tainted 
5.9.0-rc7-next-20201002+ #5
[ 4328.053714] Hardware name: Red Hat KVM, BIOS 
1.14.0-1.module+el8.3.0+7638+07cf13d2 04/01/2014
[ 4328.059513] RIP: 0010:virtio_fs_enqueue_req+0xa86/0xdb0 [virtiofs]
[ 4328.063812] Code: c1 e7 05 48 03 7c 24 10 6a 00 e8 85 a4 ff ff 8d 48 01 58 
41 8d 54 0d 00 e9 d2 fb ff ff 48 89 ef e8 8f 33 5e f9 e9 42 fe ff ff <0f> 0b e9 
c7 fb ff ff 48 8b 7c 24 08 e8 c9 49 cf f8 0f b6 45 19
[ 4328.076709] RSP: 0018:8889fbb4f9c0 EFLAGS: 00010297
[ 4328.079112] RAX:  RBX: 8889c9ad88a8 RCX: 0003
[ 4328.083725] RDX: 0007 RSI:  RDI: 88810575c1cc
[ 4328.089156] RBP: 8889fbb4fe20 R08: ed1020aeb83c R09: 1000
[ 4328.095906] R10:  R11:  R12: 0008
[ 4328.101870] R13: 0004 R14: 0003 R15: 8889c9ad88d8
[ 4328.106674] FS:  7f1129d21740() GS:888a7e90() 
knlGS:
[ 4328.111642] CS:  0010 DS:  ES:  CR0: 80050033
[ 4328.114333] CR2: 002f CR3: 00090f4ea005 CR4: 00770ee0
[ 4328.117623] DR0:  DR1:  DR2: 
[ 4328.122782] DR3:  DR6: fffe0ff0 DR7: 0400
[ 4328.128516] PKRU: 5550
[ 4328.130769] Call Trace:
[ 4328.131992]  ? virtio_fs_probe+0x14d0/0x14d0 [virtiofs]
[ 4328.134465]  ? trace_hardirqs_on+0x1c/0x110
[ 4328.136419]  ? make_kprojid+0x20/0x20
[ 4328.138936]  ? __is_kernel_percpu_address+0x63/0x1e0
[ 4328.141899]  ? __module_address+0x3f/0x370
[ 4328.143835]  ? lockdep_hardirqs_on_prepare+0x4d0/0x4d0
[ 4328.146248]  ? virtio_fs_wake_pending_and_unlock+0x18b/0x610 [virtiofs]
[ 4328.149323]  ? lock_downgrade+0x730/0x730
[ 4328.151217]  ? lock_acquire+0x17f/0x7e0
[ 4328.152998]  ? fuse_simple_request+0x233/0x9f0 [fuse]
[ 4328.155360]  ? rcu_read_unlock+0x40/0x40
[ 4328.157169]  virtio_fs_wake_pending_and_unlock+0x1f0/0x610 [virtiofs]
virtio_fs_wake_pending_and_unlock at fs/fuse/virtio_fs.c:1227 (discriminator 10)
[ 4328.160173]  ? queue_request_and_unlock+0x11e/0x290 [fuse]
[ 4328.162685]  fuse_simple_request+0x3b2/0x9f0 [fuse]
__fuse_request_send at fs/fuse/dev.c:421
(inlined by) fuse_simple_request at fs/fuse/dev.c:503
[ 4328.164933]  fuse_do_ioctl+0x6c6/0x1280 [fuse]
[ 4328.166992]  ? fuse_readahead+0x1410/0x1410 [fuse]
[ 4328.169213]  ? hrtimer_forward+0x1b0/0x1b0
[ 4328.171113]  ? hrtimer_cancel+0x20/0x20
[ 4328.172903]  ? ioctl_file_clone+0x120/0x120
[ 4328.174849]  ? _raw_spin_unlock_irq+0x24/0x30
[ 4328.176871]  ? fuse_allow_current_process+0x235/0x2a0 [fuse]
[ 4328.181615]  __x64_sys_ioctl+0x128/0x190
[ 4328.184832]  do_syscall_64+0x33/0x40
[ 4328.190405]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 4328.196680] RIP: 0033:0x7f112963478d
[ 4328.200415] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d cb 56 2c 00 f7 d8 64 89 08
[ 4328.214734] RSP: 002b:7ffd75a76ea8 EFLAGS: 0246 ORIG_RAX: 
0010
[ 4328.220222] RAX: ffda RBX: 0010 RCX: 7f112963478d
[ 4328.224383] RDX: 4000 RSI: 5a004000 RDI: 0157
[ 4328.228838] RBP: 0010 R08: 00a6 R09: 2e2e2e2e
[ 4328.233241] R10: fffc R11: 0246 R12: 0002
[ 4328.237136] R13: 7f1129c8e058 R14: 7f1129d216c0 R15: 7f1129c8e000
[ 4328.240635] CPU: 2 PID: 12259 Comm: trinity-c20 Kdump: loaded Not tainted 
5.9.0-rc7-next-20201002+ #5
[ 4328.248370] Hardware name: Red Hat KVM, BIOS 
1.14.0-1.module+el8.3.0+7638+07cf13d2 04/01/2014
[ 4328.254499] Call Trace:
[ 4328.256522]  dump_stack+0x99/0xcb
[ 4328.259336]  __warn.cold.11+0xe/0x55
[ 4328.261944]  ? virtio_fs_enqueue_req+0xa86/0xdb0 [virtiofs]
[ 4328.264929]  report_bug+0x1af/0x260
[ 4328.266673]  handle_bug+0x44/0x80
[ 4328.270439]  exc_invalid_op+0x13/0x40
[ 4328.273490]  asm_exc_invalid_op+0x12/0x20
[ 4328.27

Re: [PATCH 05/14] fs: don't allow kernel reads and writes without iter ops

[Linus Torvalds]

On Thu, Oct 1, 2020 at 3:41 PM Al Viro  wrote:
>
> Better
> loff_t dummy = 0;
> ...
> wr = __kernel_write(file, data, bytes, );

No, just fix __kernel_write() to work correctly.

The fact is, NULL _is_ the right pointer for ppos these days.

That commit by Christoph is buggy: it replaces new_sync_write() with a
buggy open-coded version.

Notice how new_sync_write does

kiocb.ki_pos = (ppos ? *ppos : 0);
,,,
if (ret > 0 && ppos)
*ppos = kiocb.ki_pos;

but the open-coded version doesn't.

So just fix that in linux-next. The *last* thing we want is to have
different semantics for the "same" kernel functions.

   Linus

Re: [linux-sunxi] [PATCH v5 09/20] arm64: dts: allwinner: h6: Add DAI node and soundcard for HDMI

[Maxime Ripard]

On Fri, Oct 02, 2020 at 06:01:21PM +0200, Clément Péron wrote:
> Hi Chen-Yu,
> 
> On Mon, 28 Sep 2020 at 07:42, Chen-Yu Tsai  wrote:
> >
> > On Mon, Sep 28, 2020 at 1:32 PM Chen-Yu Tsai  wrote:
> > >
> > > On Mon, Sep 28, 2020 at 3:29 AM Clément Péron  
> > > wrote:
> > > >
> > > > From: Jernej Skrabec 
> > > >
> > > > Add the I2S node used by the HDMI and a simple-soundcard to
> > > > link audio between HDMI and I2S.
> > > >
> > > > Note that the HDMI codec requires an inverted frame clock and
> > > > a fixed I2S width. As there is no such option for I2S we use
> > > > TDM property of the simple-soundcard to do that.
> > > >
> > > > Signed-off-by: Jernej Skrabec 
> > > > Signed-off-by: Marcus Cooper 
> > > > Signed-off-by: Clément Péron 
> > > > ---
> > > >  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33 
> > > >  1 file changed, 33 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
> > > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > index 28c77d6872f6..a8853ee7885a 100644
> > > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > > @@ -67,6 +67,25 @@ de: display-engine {
> > > > status = "disabled";
> > > > };
> > > >
> > > > +   hdmi_sound: hdmi-sound {
> > > > +   compatible = "simple-audio-card";
> > > > +   simple-audio-card,format = "i2s";
> > > > +   simple-audio-card,name = "sun50i-h6-hdmi";
> > > > +   simple-audio-card,mclk-fs = <128>;
> > > > +   simple-audio-card,frame-inversion;
> > > > +   status = "disabled";
> > > > +
> > > > +   simple-audio-card,codec {
> > > > +   sound-dai = <>;
> > > > +   };
> > > > +
> > > > +   simple-audio-card,cpu {
> > > > +   sound-dai = <>;
> > > > +   dai-tdm-slot-num = <2>;
> > >
> > > Doesn't this end up limiting the number of audio channels HDMI can carry?
> > > AFAICT the TDM properties are all optional, so just leave it out.
> > >
> > > Same goes for the other two patches.
> > >
> > > > +   dai-tdm-slot-width = <32>;
> > > > +   };
> > > > +   };
> > > > +
> > > > osc24M: osc24M_clk {
> > > > #clock-cells = <0>;
> > > > compatible = "fixed-clock";
> > > > @@ -609,6 +628,19 @@ mdio: mdio {
> > > > };
> > > > };
> > > >
> > > > +   i2s1: i2s@5091000 {
> > > > +   #sound-dai-cells = <0>;
> > > > +   compatible = "allwinner,sun50i-h6-i2s";
> > > > +   reg = <0x05091000 0x1000>;
> > > > +   interrupts = ;
> > > > +   clocks = < CLK_BUS_I2S1>, < CLK_I2S1>;
> > > > +   clock-names = "apb", "mod";
> > > > +   dmas = < 4>, < 4>;
> > > > +   resets = < RST_BUS_I2S1>;
> > > > +   dma-names = "rx", "tx";
> >
> > Sorry, missed this one.
> >
> > Given that usage for this interface is transmit only, and there is no
> > RX DRQ number assigned to it, you should drop the RX DMA number and name.
> 
> Indeed if there is no DRQ number assigned we shouldn't have it in the
> device-tree
> 
> but Samuel told me that the `make dtbs_check` reports:
> 
> i2s@1c22800: dma-names:0: 'rx' was expected
> i2s@1c22800: dma-names: ['tx'] is too short
> i2s@1c22800: dmas: [[28, 27]] is too short
> 
> Should I fix the YAML so?

Yep :)

Maxime


signature.asc
Description: PGP signature

Re: [PATCH 1/1] blk-snap - Block snapshot module This module implements snapshot and changed block tracking functionality. It is intended to create backup copies of any block devices without usage of

[kernel test robot]

Hi Sergei,

I love your patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.9-rc7]
[cannot apply to block/for-next sparc-next/master next-20201002]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sergei-Shtepa/Block-snapshot-module-and-block-layer-filter-API/20201002-210406
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
472e5b056f000a778abb41f1e443de58eb259783
config: sparc-allyesconfig (attached as .config)
compiler: sparc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/61a37e3bb74afbef1b725eaf80405e0e6e5d64b7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Sergei-Shtepa/Block-snapshot-module-and-block-layer-filter-API/20201002-210406
git checkout 61a37e3bb74afbef1b725eaf80405e0e6e5d64b7
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=sparc 

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

All error/warnings (new ones prefixed by >>):

   drivers/block/blk-snap/snapstore_mem.c: In function 'snapstore_mem_destroy':
>> drivers/block/blk-snap/snapstore_mem.c:48:4: error: implicit declaration of 
>> function 'vfree'; did you mean 'kvfree'? 
>> [-Werror=implicit-function-declaration]
  48 |vfree(buffer_el->buff);
 |^
 |kvfree
   drivers/block/blk-snap/snapstore_mem.c: In function 
'snapstore_mem_get_block':
>> drivers/block/blk-snap/snapstore_mem.c:74:20: error: implicit declaration of 
>> function '__vmalloc'; did you mean '__kmalloc'? 
>> [-Werror=implicit-function-declaration]
  74 |  buffer_el->buff = __vmalloc(snapstore_block_size() * SECTOR_SIZE, 
GFP_NOIO);
 |^
 |__kmalloc
>> drivers/block/blk-snap/snapstore_mem.c:74:18: warning: assignment to 'void 
>> *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
  74 |  buffer_el->buff = __vmalloc(snapstore_block_size() * SECTOR_SIZE, 
GFP_NOIO);
 |  ^
   cc1: some warnings being treated as errors

vim +48 drivers/block/blk-snap/snapstore_mem.c

28  
29  void snapstore_mem_destroy(struct snapstore_mem *mem)
30  {
31  struct buffer_el *buffer_el;
32  
33  if (mem == NULL)
34  return;
35  
36  do {
37  buffer_el = NULL;
38  
39  mutex_lock(>blocks_lock);
40  if (!list_empty(>blocks)) {
41  buffer_el = list_entry(mem->blocks.next, struct 
buffer_el, link);
42  
43  list_del(_el->link);
44  }
45  mutex_unlock(>blocks_lock);
46  
47  if (buffer_el) {
  > 48  vfree(buffer_el->buff);
49  kfree(buffer_el);
50  }
51  } while (buffer_el);
52  
53  blk_descr_mem_pool_done(>pool);
54  
55  kfree(mem);
56  }
57  
58  void *snapstore_mem_get_block(struct snapstore_mem *mem)
59  {
60  struct buffer_el *buffer_el;
61  
62  if (mem->blocks_allocated >= mem->blocks_limit) {
63  pr_err("Unable to get block from snapstore in 
memory\n");
64  pr_err("Block limit is reached, allocated %ld, limit 
%ld\n", mem->blocks_allocated,
65 mem->blocks_limit);
66  return NULL;
67  }
68  
69  buffer_el = kzalloc(sizeof(struct buffer_el), GFP_KERNEL);
70  if (buffer_el == NULL)
71  return NULL;
72  INIT_LIST_HEAD(_el->link);
73  
  > 74  buffer_el->buff = __vmalloc(snapstore_block_size() * 
SECTOR_SIZE, GFP_NOIO);

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


.config.gz
Description: application/gzip

Re: [PATCH v7 2/2] soc: mediatek: add mt6779 devapc driver

[Chun-Kuang Hu]

Hi, Neal:

Neal Liu  於 2020年8月27日 週四 上午11:07寫道：
>
> MediaTek bus fabric provides TrustZone security support and data
> protection to prevent slaves from being accessed by unexpected
> masters.
> The security violation is logged and sent to the processor for
> further analysis or countermeasures.
>
> Any occurrence of security violation would raise an interrupt, and
> it will be handled by mtk-devapc driver. The violation
> information is printed in order to find the murderer.
>
> Signed-off-by: Neal Liu 
> ---
>  drivers/soc/mediatek/Kconfig  |9 ++
>  drivers/soc/mediatek/Makefile |1 +
>  drivers/soc/mediatek/mtk-devapc.c |  305 
> +
>  3 files changed, 315 insertions(+)
>  create mode 100644 drivers/soc/mediatek/mtk-devapc.c
>

[snip]

> +
> +static int mtk_devapc_probe(struct platform_device *pdev)
> +{
> +   struct device_node *node = pdev->dev.of_node;
> +   struct mtk_devapc_context *ctx;
> +   u32 devapc_irq;
> +   int ret;
> +
> +   if (IS_ERR(node))
> +   return -ENODEV;
> +
> +   ctx = devm_kzalloc(>dev, sizeof(*ctx), GFP_KERNEL);
> +   if (!ctx)
> +   return -ENOMEM;
> +
> +   ctx->data = of_device_get_match_data(>dev);
> +   ctx->dev = >dev;
> +
> +   ctx->infra_base = of_iomap(node, 0);
> +   if (!ctx->infra_base)
> +   return -EINVAL;
> +
> +   devapc_irq = irq_of_parse_and_map(node, 0);
> +   if (!devapc_irq)
> +   return -EINVAL;
> +
> +   ctx->infra_clk = devm_clk_get(>dev, "devapc-infra-clock");
> +   if (IS_ERR(ctx->infra_clk))
> +   return -EINVAL;
> +
> +   if (clk_prepare_enable(ctx->infra_clk))
> +   return -EINVAL;

What would happen if you do not enable this clock? I think this
hardware is already initialized in trust zone.

Regards,
Chun-Kuang.

> +
> +   ret = devm_request_irq(>dev, devapc_irq,
> +  (irq_handler_t)devapc_violation_irq,
> +  IRQF_TRIGGER_NONE, "devapc", ctx);
> +   if (ret) {
> +   clk_disable_unprepare(ctx->infra_clk);
> +   return ret;
> +   }
> +
> +   platform_set_drvdata(pdev, ctx);
> +
> +   start_devapc(ctx);
> +
> +   return 0;
> +}
> +

Re: [PATCH v3 01/27] Input: Simplify with dev_err_probe()

[Krzysztof Kozlowski]

On Thu, Aug 27, 2020 at 08:58:02PM +0200, Krzysztof Kozlowski wrote:
> Hi,
> 
> Changes since v2:
> 1. Add review tags,
> 2. Fixes after review (see individual patches).
> 3. Two new patches - 26 and 27.
> 
> 

Hi Dmitry,

Any comments here? Some of these nicely simplify the code or remove some
lines.

Best regards,
Krzysztof

> Best regards,
> Krzysztof
> 
> 
> 
> Krzysztof Kozlowski (27):
>   Input: gpio_keys_polled - Simplify with dev_err_probe()
>   Input: gpio-vibra - Simplify with dev_err_probe()
>   Input: pwm-beeper - Simplify with dev_err_probe()
>   Input: pwm-vibra - Simplify with dev_err_probe()
>   Input: rotary_encoder - Simplify with dev_err_probe()
>   Input: elan_i2c - Simplify with dev_err_probe()
>   Input: bu21013_ts - Simplify with dev_err_probe()
>   Input: bu21029_ts - Simplify with dev_err_probe()
>   Input: chipone_icn8318 - Simplify with dev_err_probe()
>   Input: cy8ctma140 - Simplify with dev_err_probe()
>   Input: edf-ft5x06 - Simplify with dev_err_probe()
>   Input: ektf2127 - Simplify with dev_err_probe()
>   Input: elants_i2c - Simplify with dev_err_probe()
>   Input: goodix - Simplify with dev_err_probe()
>   Input: melfas_mip4 - Simplify with dev_err_probe()
>   Input: pixcir_i2c_ts - Simplify with dev_err_probe()
>   Input: raydium_i2c_ts - Simplify with dev_err_probe()
>   Input: resistive-adc-touch - Simplify with dev_err_probe()
>   Input: silead - Simplify with dev_err_probe()
>   Input: sis_i2c - Simplify with dev_err_probe()
>   Input: surface3_spi - Simplify with dev_err_probe()
>   Input: sx8643 - Simplify with dev_err_probe()
>   Input: bcm-keypad - Simplify with dev_err_probe()
>   gpio: Add devm_fwnode_gpiod_get_optional() helpers
>   Input: gpio_keys - Simplify with dev_err_probe()
>   Input: bu21013_ts - Use local 'client->dev' variable in probe()
>   Input: bu21029_ts - Use local 'client->dev' variable in probe()
> 
>  drivers/gpio/gpiolib-devres.c | 71 ++
>  drivers/input/keyboard/bcm-keypad.c   | 14 ++--
>  drivers/input/keyboard/gpio_keys.c| 25 +++
>  drivers/input/keyboard/gpio_keys_polled.c |  8 +--
>  drivers/input/misc/gpio-vibra.c   | 20 ++
>  drivers/input/misc/pwm-beeper.c   | 19 ++---
>  drivers/input/misc/pwm-vibra.c| 20 ++
>  drivers/input/misc/rotary_encoder.c   |  8 +--
>  drivers/input/mouse/elan_i2c_core.c   |  9 +--
>  drivers/input/touchscreen/bu21013_ts.c| 72 ---
>  drivers/input/touchscreen/bu21029_ts.c| 53 ++
>  drivers/input/touchscreen/chipone_icn8318.c   |  8 +--
>  drivers/input/touchscreen/cy8ctma140.c|  8 +--
>  drivers/input/touchscreen/edt-ft5x06.c| 10 +--
>  drivers/input/touchscreen/ektf2127.c  |  8 +--
>  drivers/input/touchscreen/elants_i2c.c| 22 ++
>  drivers/input/touchscreen/goodix.c| 40 +++
>  drivers/input/touchscreen/melfas_mip4.c   |  9 +--
>  drivers/input/touchscreen/pixcir_i2c_ts.c | 38 --
>  drivers/input/touchscreen/raydium_i2c_ts.c| 30 +++-
>  .../input/touchscreen/resistive-adc-touch.c   |  8 +--
>  drivers/input/touchscreen/silead.c|  8 +--
>  drivers/input/touchscreen/sis_i2c.c   | 20 ++
>  drivers/input/touchscreen/surface3_spi.c  | 13 +---
>  drivers/input/touchscreen/sx8654.c| 10 +--
>  include/linux/gpio/consumer.h | 30 
>  26 files changed, 253 insertions(+), 328 deletions(-)
> 
> -- 
> 2.17.1
> 

Re: [PATCH v3 0/2] MTE support for KVM guest

[Andrew Jones]

On Fri, Oct 02, 2020 at 04:38:11PM +0100, Steven Price wrote:
> On 02/10/2020 15:36, Andrew Jones wrote:
> > On Fri, Sep 25, 2020 at 10:36:05AM +0100, Steven Price wrote:
> > > Version 3 of adding MTE support for KVM guests. See the previous (v2)
> > > posting for background:
> > > 
> > >   https://lore.kernel.org/r/20200904160018.29481-1-steven.price%40arm.com
> > > 
> > > These patches add support to KVM to enable MTE within a guest. They are
> > > based on Catalin's v9 MTE user-space support series[1] (currently in
> > > next).
> > > 
> > > Changes since v2:
> > > 
> > >   * MTE is no longer a VCPU feature, instead it is a VM cap.
> > > 
> > >   * Being a VM cap means easier probing (check for KVM_CAP_ARM_MTE).
> > > 
> > >   * The cap must be set before any VCPUs are created, preventing any
> > > shenanigans where MTE is enabled for the guest after memory accesses
> > > have been performed.
> > > 
> > > [1] 
> > > https://lore.kernel.org/r/20200904103029.32083-1-catalin.mari...@arm.com
> > > 
> > > Steven Price (2):
> > >arm64: kvm: Save/restore MTE registers
> > >arm64: kvm: Introduce MTE VCPU feature
> > > 
> > >   arch/arm64/include/asm/kvm_emulate.h   |  3 +++
> > >   arch/arm64/include/asm/kvm_host.h  |  7 +++
> > >   arch/arm64/include/asm/sysreg.h|  3 ++-
> > >   arch/arm64/kvm/arm.c   |  9 +
> > >   arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 14 ++
> > >   arch/arm64/kvm/mmu.c   | 15 +++
> > >   arch/arm64/kvm/sys_regs.c  | 20 +++-
> > >   include/uapi/linux/kvm.h   |  1 +
> > >   8 files changed, 66 insertions(+), 6 deletions(-)
> > > 
> > > -- 
> > > 2.20.1
> > > 
> > > 
> > 
> > Hi Steven,
> > 
> > These patches look fine to me, but I'd prefer we have a working
> > implementation in QEMU before we get too excited about the KVM
> > bits. kvmtool isn't sufficient since it doesn't support migration
> > (at least afaik). In the past we've implemented features in KVM
> > that look fine, but then issues have been discovered when trying
> > to enable them from QEMU, where we also support migration. This
> > feature looks like there's risk of issues with the userspace side.
> > Although these two patches would probably stay the same, even if
> > userspace requires more support.
> 
> I agree kvmtool isn't a great test because it doesn't support migration. The
> support in this series is just the basic support for MTE in a guest and we'd
> need to wait for the QEMU implementation before deciding whether we need any
> extra support (e.g. kernel interfaces for reading/writing tags as discussed
> before).
> 
> However, I don't think there's much danger of the support in this series
> changing - so extra support can be added when/if it's needed, but I don't
> think we need to block these series on that - QEMU can just probe for
> whatever additional support it needs before enabling MTE in a guest. I plan
> to rebase/repost after -rc1 when the user space support has been merged.
> 

Fair enough, but it feels like we'll be merging half a feature, leaving
the other half for somebody else to pick up later.

Thanks,
drew

Re: [PATCH] mm/util.c: Add error logs for commitment overflow

[pintu]

On 2020-10-02 17:47, Michal Hocko wrote:

__vm_enough_memory: commitment overflow: ppid:150, pid:164, 
pages:62451

fork failed[count:0]: Cannot allocate memory


While I understand that fork failing due to overrcomit heuristic is non
intuitive and I have seen people scratching heads due to this in the
past I am not convinced this is a right approach to tackle the problem.


Dear Michal,
First, thank you so much for your review and comments.
I totally agree with you.


First off, referencing pids is not really going to help much if process
is short lived.


Yes, I agree with you.
But I think this is most important mainly for short lived processes 
itself.
Because, when this situation occurs, no one knows who could be the 
culprit.
However, user keeps dumping "ps" or "top" in background to reproduce 
once again.
At this time, we can easily match the pid, process-name (at least in 
most cases).



Secondly, __vm_enough_memory is about any address space
allocation. Why would you be interested in parent when doing mmap?



Yes agree, we can remove ppid from here.
I thought it might be useful at least in case of fork (or short lived 
process).



Last but not least _once is questionable as well. The first instance
might happen early during the system lifetime and you will not learn
about future failures so the overall point of debuggability is 
seriously

inhibited.

Maybe what you want is to report higher up the call chain (fork?) and
have it ratelimited rather than _once? Or maybe just try to live with
the confusing situation?



Okay agree. I can change to pr_err_ratelimited.
In-fact, initially I thought to use ratelimited itself but then I 
thought

just once also should be fine at least.


Thanks,
Pintu

[PATCH v2 6/6] x86: mremap speedup - Enable HAVE_MOVE_PUD

[Kalesh Singh]

HAVE_MOVE_PUD enables remapping pages at the PUD level if both the
source and destination addresses are PUD-aligned.

With HAVE_MOVE_PUD enabled it can be inferred that there is approximately
a 13x improvement in performance on x86. (See data below).

--- Test Results -

The following results were obtained using a 5.4 kernel, by remapping
a PUD-aligned, 1GB sized region to a PUD-aligned destination.
The results from 10 iterations of the test are given below:

Total mremap times for 1GB data on x86. All times are in nanoseconds.

ControlHAVE_MOVE_PUD

180394 15089
235728 14056
238931 25741
187330 13838
241742 14187
177925 14778
182758 14728
160872 14418
205813 15107
245722 13998

205721.5   15594<-- Mean time in nanoseconds

A 1GB mremap completion time drops from ~205 microseconds
to ~15 microseconds on x86. (~13x speed up).

Signed-off-by: Kalesh Singh 
---
 arch/x86/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7101ac64bb20..ff6e2755cab8 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -198,6 +198,7 @@ config X86
select HAVE_MIXED_BREAKPOINTS_REGS
select HAVE_MOD_ARCH_SPECIFIC
select HAVE_MOVE_PMD
+   select HAVE_MOVE_PUD
select HAVE_NMI
select HAVE_OPROFILE
select HAVE_OPTPROBES
-- 
2.28.0.806.g8561365e88-goog

[PATCH][next] PCI/ASPM: fix an unintended sign extension of a u16

[Colin King]

From: Colin Ian King 

The multiplication of the u16 variable 'value' causes it to be
prompted to a int type and this is then sign extended to a u64.
When the result of the multiplication is > 0x7fff the upper
bits are all unitentionally set to 1 on a sign extension operation.
Fix this by explicitly casting value to a u64 to avoid the int
type promotion and the following sign extension.

Addresses-Coverity: ("Unintended sign extension")
Fixes: 5ccf2a6e483f ("PCI/ASPM: Add support for LTR _DSM")
Signed-off-by: Colin Ian King 
---
 drivers/pci/pci.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index db8feb2033e7..736197f9094b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3083,8 +3083,8 @@ static u64 pci_ltr_decode(u16 latency)
case 1: return value * 32;
case 2: return value * 1024;
case 3: return value * 32768;
-   case 4: return value * 1048576;
-   case 5: return value * 33554432;
+   case 4: return (uint64_t)value * 1048576;
+   case 5: return (uint64_t)value * 33554432;
}
return 0;
 }
-- 
2.27.0

Re: [PATCHv1] power: supply: document current direction

[Andreas Kemnade]

On Thu, 27 Aug 2020 16:02:48 +0200
Sebastian Reichel  wrote:

> Currently the sign for CURRENT_NOW and CURRENT_AVG is a bit
> of a mess. There are basically 3 different ways battery fuel
> gauges report the current:
> 
> 1. uses negative values for discharging and positive values
>for charging
> 2. uses positive values for discharging and negative values
>for discharging (opposit of 1)
> 3. only uses positive values
> 
> As a result userspace currently cannot use the sign at all in
> a generic way. Let's solve the issue by documenting a canonical
> way for reporting the data and ensure new drivers follow this
> way. Then existing drivers can be fixed on a case-by-case basis.
> 
> The 'negative value = battery discharging' has been choosen,
> since there are only very few drivers doing it the other way
> around.
> 
> Signed-off-by: Sebastian Reichel 
> ---

would be nice if this comes in, so that is it clearly specified.

Regards,
Andreas

[PATCH v2 5/6] arm64: mremap speedup - Enable HAVE_MOVE_PUD

[Kalesh Singh]

HAVE_MOVE_PUD enables remapping pages at the PUD level if both the
source and destination addresses are PUD-aligned.

With HAVE_MOVE_PUD enabled it can be inferred that there is approximately
a 19x improvement in performance on arm64. (See data below).

--- Test Results -

The following results were obtained using a 5.4 kernel, by remapping
a PUD-aligned, 1GB sized region to a PUD-aligned destination.
The results from 10 iterations of the test are given below:

Total mremap times for 1GB data on arm64. All times are in nanoseconds.

Control  HAVE_MOVE_PUD

1247761  74271
1219896  46771
1094792  59687
1227760  48385
1043698  7
1101771  50365
1159896  52500
1143594  75261
1025833  61354
1078125  48697

1134312.659395.7<-- Mean time in nanoseconds

A 1GB mremap completion time drops from ~1.1 milliseconds
to ~59 microseconds on arm64. (~19x speed up).

Signed-off-by: Kalesh Singh 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 844d089668e3..4d521f0a5863 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -122,6 +122,7 @@ config ARM64
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_MOVE_PMD
+   select HAVE_MOVE_PUD
select HAVE_PCI
select HAVE_ACPI_APEI if (ACPI && EFI)
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
-- 
2.28.0.806.g8561365e88-goog

[PATCH v2 4/6] arm64: Add set_pud_at() function

[Kalesh Singh]

set_pud_at() is used in move_normal_pud() for remapping
pages at the PUD level.

Signed-off-by: Kalesh Singh 
---
 arch/arm64/include/asm/pgtable.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index d5d3fbe73953..8848125e3024 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -415,6 +415,7 @@ static inline pmd_t pmd_mkdevmap(pmd_t pmd)
 #define pfn_pud(pfn,prot)  __pud(__phys_to_pud_val((phys_addr_t)(pfn) << 
PAGE_SHIFT) | pgprot_val(prot))
 
 #define set_pmd_at(mm, addr, pmdp, pmd)set_pte_at(mm, addr, (pte_t 
*)pmdp, pmd_pte(pmd))
+#define set_pud_at(mm, addr, pudp, pud)set_pte_at(mm, addr, (pte_t 
*)pudp, pud_pte(pud))
 
 #define __p4d_to_phys(p4d) __pte_to_phys(p4d_pte(p4d))
 #define __phys_to_p4d_val(phys)__phys_to_pte_val(phys)
-- 
2.28.0.806.g8561365e88-goog

[PATCH v2 3/6] mm: Speedup mremap on 1GB or larger regions

[Kalesh Singh]

Android needs to move large memory regions for garbage collection.
The GC requires moving physical pages of multi-gigabyte heap
using mremap. During this move, the application threads have to
be paused for correctness. It is critical to keep this pause as
short as possible to avoid jitters during user interaction.

Optimize mremap for >= 1GB-sized regions by moving at the PUD/PGD
level if the source and destination addresses are PUD-aligned.
For CONFIG_PGTABLE_LEVELS == 3, moving at the PUD level in effect moves
PGD entries, since the PUD entry is “folded back” onto the PGD entry.
Add HAVE_MOVE_PUD so that architectures where moving at the PUD level
isn't supported/tested can turn this off by not selecting the config.

Fix build test error from v1 of this series reported by
kernel test robot in [1].

[1] 
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org/thread/CKPGL4FH4NG7TGH2CVYX2UX76L25BTA3/

Signed-off-by: Kalesh Singh 
Reported-by: kernel test robot 
---
Changes in v2:
  - Update commit message with description of Android GC's use case.
  - Move set_pud_at() to a separate patch.
  - Use switch() instead of ifs in move_pgt_entry()
  - Fix build test error reported by kernel test robot on x86_64 in [1].
Guard move_huge_pmd() with IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE),
since this section doesn't get optimized out in the kernel test
robot's build test when HAVE_MOVE_PUD is enabled.
  - Keep WARN_ON_ONCE(1) instead of BUILD_BUG() for the aforementioned
reason.

 arch/Kconfig |   7 ++
 mm/mremap.c  | 220 ---
 2 files changed, 197 insertions(+), 30 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index af14a567b493..5eabaa00bf9b 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -602,6 +602,13 @@ config HAVE_IRQ_TIME_ACCOUNTING
  Archs need to ensure they use a high enough resolution clock to
  support irq time accounting and then call 
enable_sched_clock_irqtime().
 
+config HAVE_MOVE_PUD
+   bool
+   help
+ Architectures that select this are able to move page tables at the
+ PUD level. If there are only 3 page table levels, the move effectively
+ happens at the PGD level.
+
 config HAVE_MOVE_PMD
bool
help
diff --git a/mm/mremap.c b/mm/mremap.c
index 138abbae4f75..c1d6ab667d70 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -249,14 +249,176 @@ static bool move_normal_pmd(struct vm_area_struct *vma, 
unsigned long old_addr,
 
return true;
 }
+#else
+static inline bool move_normal_pmd(struct vm_area_struct *vma, unsigned long 
old_addr,
+ unsigned long new_addr, pmd_t *old_pmd, pmd_t *new_pmd)
+{
+   return false;
+}
 #endif
 
+#ifdef CONFIG_HAVE_MOVE_PUD
+static pud_t *get_old_pud(struct mm_struct *mm, unsigned long addr)
+{
+   pgd_t *pgd;
+   p4d_t *p4d;
+   pud_t *pud;
+
+   pgd = pgd_offset(mm, addr);
+   if (pgd_none_or_clear_bad(pgd))
+   return NULL;
+
+   p4d = p4d_offset(pgd, addr);
+   if (p4d_none_or_clear_bad(p4d))
+   return NULL;
+
+   pud = pud_offset(p4d, addr);
+   if (pud_none_or_clear_bad(pud))
+   return NULL;
+
+   return pud;
+}
+
+static pud_t *alloc_new_pud(struct mm_struct *mm, struct vm_area_struct *vma,
+   unsigned long addr)
+{
+   pgd_t *pgd;
+   p4d_t *p4d;
+   pud_t *pud;
+
+   pgd = pgd_offset(mm, addr);
+   p4d = p4d_alloc(mm, pgd, addr);
+   if (!p4d)
+   return NULL;
+   pud = pud_alloc(mm, p4d, addr);
+   if (!pud)
+   return NULL;
+
+   return pud;
+}
+
+static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
+ unsigned long new_addr, pud_t *old_pud, pud_t *new_pud)
+{
+   spinlock_t *old_ptl, *new_ptl;
+   struct mm_struct *mm = vma->vm_mm;
+   pud_t pud;
+
+   /*
+* The destination pud shouldn't be established, free_pgtables()
+* should have released it.
+*/
+   if (WARN_ON_ONCE(!pud_none(*new_pud)))
+   return false;
+
+   /*
+* We don't have to worry about the ordering of src and dst
+* ptlocks because exclusive mmap_lock prevents deadlock.
+*/
+   old_ptl = pud_lock(vma->vm_mm, old_pud);
+   new_ptl = pud_lockptr(mm, new_pud);
+   if (new_ptl != old_ptl)
+   spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
+
+   /* Clear the pud */
+   pud = *old_pud;
+   pud_clear(old_pud);
+
+   VM_BUG_ON(!pud_none(*new_pud));
+
+   /* Set the new pud */
+   set_pud_at(mm, new_addr, new_pud, pud);
+   flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
+   if (new_ptl != old_ptl)
+   spin_unlock(new_ptl);
+   spin_unlock(old_ptl);
+
+   return true;
+}
+#else
+static inline bool move_normal_pud(struct vm_area_struct *vma, unsigned long 
old_addr,
+

[PATCH v2 2/6] arm64: mremap speedup - Enable HAVE_MOVE_PMD

[Kalesh Singh]

HAVE_MOVE_PMD enables remapping pages at the PMD level if both the
source and destination addresses are PMD-aligned.

HAVE_MOVE_PMD is already enabled on x86. The original patch [1] that
introduced this config did not enable it on arm64 at the time because
of performance issues with flushing the TLB on every PMD move. These
issues have since been addressed in more recent releases with
improvements to the arm64 TLB invalidation and core mmu_gather code as
Will Deacon mentioned in [2].

>From the data below, it can be inferred that there is approximately
8x improvement in performance when HAVE_MOVE_PMD is enabled on arm64.

- Test Results --

The following results were obtained on an arm64 device running a 5.4
kernel, by remapping a PMD-aligned, 1GB sized region to a PMD-aligned
destination. The results from 10 iterations of the test are given below.
All times are in nanoseconds.

ControlHAVE_MOVE_PMD

92208331247761
90025521219896
92541151094792
87258851227760
93086461043698
90016671101771
87933851159896
87746361143594
95531251025833
93740101078125

9100885.4  1134312.6<-- Mean Time in nanoseconds

Total mremap time for a 1GB sized PMD-aligned region drops from
~9.1 milliseconds to ~1.1 milliseconds. (~8x speedup).

[1] https://lore.kernel.org/r/20181108181201.88826-3-joe...@google.com
[2] https://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg140837.html

Signed-off-by: Kalesh Singh 
---
 arch/arm64/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 6d232837cbee..844d089668e3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -121,6 +121,7 @@ config ARM64
select GENERIC_VDSO_TIME_NS
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
+   select HAVE_MOVE_PMD
select HAVE_PCI
select HAVE_ACPI_APEI if (ACPI && EFI)
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
-- 
2.28.0.806.g8561365e88-goog

[PATCH v2 1/6] kselftests: vm: Add mremap tests

[Kalesh Singh]

Test mremap on regions of various sizes and alignments and validate
data after remapping. Also provide total time for remapping
the region which is useful for performance comparison of the mremap
optimizations that move pages at the PMD/PUD levels if HAVE_MOVE_PMD
and/or HAVE_MOVE_PUD are enabled.

Signed-off-by: Kalesh Singh 
---
Changes in v2:
  - Reduce test time by only validating a certain threshold of the
remapped region (4MB by default). The -t flag can be used to
set a custom threshold in MB or no threshold by passing 0. (-t0).
mremap time is not provided in stdout for only partially validated
regions. This time is only applicable for comparison if the entire
mapped region was faulted in.
  - Use a random pattern for validating the remapped region. The -p
flag can be used to run the tests with a specified seed for the
random pattern.
  - Print test configs (threshold_mb and pattern_seed) to stdout.
  - Remove MAKE_SIMPLE_TEST macro.
  - Define named flags instead of 0 / 1.
  - Add comments for destination address' align_mask and offset.

 tools/testing/selftests/vm/.gitignore|   1 +
 tools/testing/selftests/vm/Makefile  |   1 +
 tools/testing/selftests/vm/mremap_test.c | 333 +++
 tools/testing/selftests/vm/run_vmtests   |  11 +
 4 files changed, 346 insertions(+)
 create mode 100644 tools/testing/selftests/vm/mremap_test.c

diff --git a/tools/testing/selftests/vm/.gitignore 
b/tools/testing/selftests/vm/.gitignore
index 849e8226395a..b3a183c36cb5 100644
--- a/tools/testing/selftests/vm/.gitignore
+++ b/tools/testing/selftests/vm/.gitignore
@@ -8,6 +8,7 @@ thuge-gen
 compaction_test
 mlock2-tests
 mremap_dontunmap
+mremap_test
 on-fault-limit
 transhuge-stress
 protection_keys
diff --git a/tools/testing/selftests/vm/Makefile 
b/tools/testing/selftests/vm/Makefile
index a9026706d597..f044808b45fa 100644
--- a/tools/testing/selftests/vm/Makefile
+++ b/tools/testing/selftests/vm/Makefile
@@ -16,6 +16,7 @@ TEST_GEN_FILES += map_populate
 TEST_GEN_FILES += mlock-random-test
 TEST_GEN_FILES += mlock2-tests
 TEST_GEN_FILES += mremap_dontunmap
+TEST_GEN_FILES += mremap_test
 TEST_GEN_FILES += on-fault-limit
 TEST_GEN_FILES += thuge-gen
 TEST_GEN_FILES += transhuge-stress
diff --git a/tools/testing/selftests/vm/mremap_test.c 
b/tools/testing/selftests/vm/mremap_test.c
new file mode 100644
index ..abe1f0a5a26a
--- /dev/null
+++ b/tools/testing/selftests/vm/mremap_test.c
@@ -0,0 +1,333 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2020 Google LLC
+ */
+#define _GNU_SOURCE
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../kselftest.h"
+
+#define EXPECT_SUCCESS 0
+#define EXPECT_FAILURE 1
+#define NON_OVERLAPPING 0
+#define OVERLAPPING 1
+#define NS_PER_SEC 10ULL
+#define VALIDATION_DEFAULT_THRESHOLD 4 /* 4MB */
+#define VALIDATION_NO_THRESHOLD 0  /* Verify the entire region */
+#define PATTERN_SIZE 3
+
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+#define MIN(X, Y) ((X) < (Y) ? (X) : (Y))
+
+struct config {
+   unsigned long long src_alignment;
+   unsigned long long dest_alignment;
+   unsigned long long region_size;
+   int overlapping;
+};
+
+struct test {
+   const char *name;
+   struct config config;
+   int expect_failure;
+};
+
+enum {
+   _1KB = 1ULL << 10,  /* 1KB -> not page aligned */
+   _4KB = 4ULL << 10,
+   _8KB = 8ULL << 10,
+   _1MB = 1ULL << 20,
+   _2MB = 2ULL << 20,
+   _4MB = 4ULL << 20,
+   _1GB = 1ULL << 30,
+   _2GB = 2ULL << 30,
+   PTE = _4KB,
+   PMD = _2MB,
+   PUD = _1GB,
+};
+
+#define MAKE_TEST(source_align, destination_align, size,   \
+ overlaps, should_fail, test_name) \
+{  \
+   .name = test_name,  \
+   .config = { \
+   .src_alignment = source_align,  \
+   .dest_alignment = destination_align,\
+   .region_size = size,\
+   .overlapping = overlaps,\
+   },  \
+   .expect_failure = should_fail   \
+}
+
+/*
+ * Returns the start address of the mapping on success, else returns
+ * NULL on failure.
+ */
+static void *get_source_mapping(struct config c)
+{
+   unsigned long long addr = 0ULL;
+   void *src_addr = NULL;
+retry:
+   addr += c.src_alignment;
+   src_addr = mmap((void *) addr, c.region_size, PROT_READ | PROT_WRITE,
+   MAP_FIXED | MAP_ANONYMOUS | MAP_SHARED, -1, 0);
+   if (src_addr == MAP_FAILED) {
+   if (errno == EPERM)
+   goto retry;
+   goto error;
+   }
+   /*
+* Check that the 

[PATCH v2 0/6] Speed up mremap on large regions

[Kalesh Singh]

This version 2 of the mremap speed up patches previously posted at:
https://lore.kernel.org/r/20200930222130.4175584-1-kaleshsi...@google.com

mremap time can be optimized by moving entries at the PMD/PUD level if
the source and destination addresses are PMD/PUD-aligned and
PMD/PUD-sized. Enable moving at the PMD and PUD levels on arm64 and
x86. Other architectures where this type of move is supported and known to
be safe can also opt-in to these optimizations by enabling HAVE_MOVE_PMD
and HAVE_MOVE_PUD.

Observed Performance Improvements for remapping a PUD-aligned 1GB-sized
region on x86 and arm64:

- HAVE_MOVE_PMD is already enabled on x86 : N/A
- Enabling HAVE_MOVE_PUD on x86   : ~13x speed up

- Enabling HAVE_MOVE_PMD on arm64 : ~ 8x speed up
- Enabling HAVE_MOVE_PUD on arm64 : ~19x speed up

  Altogether, HAVE_MOVE_PMD and HAVE_MOVE_PUD
  give a total of ~150x speed up on arm64.

Changes in v2:
  - Reduce mremap_test time by only validating a configurable
threshold of the remapped region, as per John.
  - Use a random pattern for mremap validation. Provide pattern
seed in test output, as per John.
  - Moved set_pud_at() to separate patch, per Kirill.
  - Use switch() instead of ifs in move_pgt_entry(), per Kirill.
  - Update commit message with description of Android
garbage collector use case for HAVE_MOVE_PUD, as per Joel.
  - Fix build test error reported by kernel test robot in [1].

[1] 
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org/thread/CKPGL4FH4NG7TGH2CVYX2UX76L25BTA3/

Kalesh Singh (6):
  kselftests: vm: Add mremap tests
  arm64: mremap speedup - Enable HAVE_MOVE_PMD
  mm: Speedup mremap on 1GB or larger regions
  arm64: Add set_pud_at() functions
  arm64: mremap speedup - Enable HAVE_MOVE_PUD
  x86: mremap speedup - Enable HAVE_MOVE_PUD

 arch/Kconfig |   7 +
 arch/arm64/Kconfig   |   2 +
 arch/arm64/include/asm/pgtable.h |   1 +
 arch/x86/Kconfig |   1 +
 mm/mremap.c  | 220 +--
 tools/testing/selftests/vm/.gitignore|   1 +
 tools/testing/selftests/vm/Makefile  |   1 +
 tools/testing/selftests/vm/mremap_test.c | 333 +++
 tools/testing/selftests/vm/run_vmtests   |  11 +
 9 files changed, 547 insertions(+), 30 deletions(-)
 create mode 100644 tools/testing/selftests/vm/mremap_test.c


base-commit: 472e5b056f000a778abb41f1e443de58eb259783
-- 
2.28.0.806.g8561365e88-goog

Re: [PATCH v3 2/2] arm64: kvm: Introduce MTE VCPU feature

[Andrew Jones]

On Fri, Oct 02, 2020 at 04:30:47PM +0100, Steven Price wrote:
> On 02/10/2020 15:30, Andrew Jones wrote:
> > On Fri, Sep 25, 2020 at 10:36:07AM +0100, Steven Price wrote:
> > > + if (system_supports_mte() && kvm->arch.mte_enabled && pfn_valid(pfn)) {
> > 
> > 'system_supports_mte() && kvm->arch.mte_enabled' is redundant, but I
> > assume system_supports_mte() is there to improve the efficiency of the
> > branch, as it's using cpus_have_const_cap().
> 
> system_supports_mte() compiles to 0 when MTE support isn't built in, so this
> code can be removed by the compiler,

I know. That's what I meant by "improve the efficiency of the branch"


> whereas with kvm->arch.mte_enabled I
> doubt the compiler can deduce that it is never set.
> 
> > Maybe a helper like
> > 
> >   static inline bool kvm_arm_mte_enabled(struct kvm *kvm)
> >   {
> > return system_supports_mte() && kvm->arch.mte_enabled;
> >   }
> > 
> > would allow both the more efficient branch and look less confusing
> > where it gets used.
> 
> I wasn't sure it was worth having a helper since this was the only place
> checking this condition. It's also a bit tricky putting this in a logical
> header file, kvm_host.h doesn't work because struct kvm hasn't been defined
> by then.

OK, but I feel like we're setting ourselves up to revisit these types of
conditions again when our memories fade or when new developers see them
for the first time and ask.

Thanks,
drew

> 
> Steve
> 
> > > + /*
> > > +  * VM will be able to see the page's tags, so we must ensure
> > > +  * they have been initialised.
> > > +  */
> > > + struct page *page = pfn_to_page(pfn);
> > > + long i, nr_pages = compound_nr(page);
> > > +
> > > + /* if PG_mte_tagged is set, tags have already been initialised 
> > > */
> > > + for (i = 0; i < nr_pages; i++, page++) {
> > > + if (!test_and_set_bit(PG_mte_tagged, >flags))
> > > + mte_clear_page_tags(page_address(page));
> > > + }
> > > + }
> > > +
> > >   if (writable)
> > >   kvm_set_pfn_dirty(pfn);
> > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> > > index a655f172b5ad..5010a47152b4 100644
> > > --- a/arch/arm64/kvm/sys_regs.c
> > > +++ b/arch/arm64/kvm/sys_regs.c
> > > @@ -1132,7 +1132,8 @@ static u64 read_id_reg(const struct kvm_vcpu *vcpu,
> > >   val &= ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
> > >   val &= ~(0xfUL << ID_AA64PFR0_AMU_SHIFT);
> > >   } else if (id == SYS_ID_AA64PFR1_EL1) {
> > > - val &= ~(0xfUL << ID_AA64PFR1_MTE_SHIFT);
> > > + if (!vcpu->kvm->arch.mte_enabled)
> > > + val &= ~(0xfUL << ID_AA64PFR1_MTE_SHIFT);
> > >   } else if (id == SYS_ID_AA64ISAR1_EL1 && 
> > > !vcpu_has_ptrauth(vcpu)) {
> > >   val &= ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
> > >(0xfUL << ID_AA64ISAR1_API_SHIFT) |
> > > @@ -1394,6 +1395,9 @@ static bool access_mte_regs(struct kvm_vcpu *vcpu, 
> > > struct sys_reg_params *p,
> > >   static unsigned int mte_visibility(const struct kvm_vcpu *vcpu,
> > >  const struct sys_reg_desc *rd)
> > >   {
> > > + if (vcpu->kvm->arch.mte_enabled)
> > > + return 0;
> > > +
> > >   return REG_HIDDEN_USER | REG_HIDDEN_GUEST;
> > >   }
> > > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > > index f6d86033c4fa..87678ed82ab4 100644
> > > --- a/include/uapi/linux/kvm.h
> > > +++ b/include/uapi/linux/kvm.h
> > > @@ -1035,6 +1035,7 @@ struct kvm_ppc_resize_hpt {
> > >   #define KVM_CAP_LAST_CPU 184
> > >   #define KVM_CAP_SMALLER_MAXPHYADDR 185
> > >   #define KVM_CAP_S390_DIAG318 186
> > > +#define KVM_CAP_ARM_MTE 188
> > >   #ifdef KVM_CAP_IRQ_ROUTING
> > > -- 
> > > 2.20.1
> > > 
> > > 
> > 
> > Besides the helper suggestion nit
> > 
> > Reviewed-by: Andrew Jones 
> > 
> 
> 

Re: [PATCH 1/1] mfd: sl28cpld: Depend on I2C

[Randy Dunlap]

On 10/2/20 1:35 AM, Lee Jones wrote:
> Fixes the following randconfig build error:
> 
>  ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_probe':
>  simple-mfd-i2c.c:(.text+0x48): undefined reference to 
> `__devm_regmap_init_i2c'
>  ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_driver_init':
>  simple-mfd-i2c.c:(.init.text+0x14): undefined reference to 
> `i2c_register_driver'
>  ld: drivers/mfd/simple-mfd-i2c.o: in function `simple_mfd_i2c_driver_exit':
>  simple-mfd-i2c.c:(.exit.text+0xd): undefined reference to `i2c_del_driver'
> 
> Reported-by: Randy Dunlap 
> Signed-off-by: Lee Jones 
> ---
>  drivers/mfd/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index bdf8cb962027b..8b99a13669bfc 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1188,6 +1188,7 @@ config MFD_SIMPLE_MFD_I2C
>  
>  config MFD_SL28CPLD
>   tristate "Kontron sl28cpld Board Management Controller"
> + depends on I2C
>   select MFD_SIMPLE_MFD_I2C
>   help
> Say yes here to enable support for the Kontron sl28cpld board
> 

Acked-by: Randy Dunlap  # build-tested

thanks.
-- 
~Randy

Re: [PATCH rdma-next v4 1/4] lib/scatterlist: Add support in dynamic allocation of SG table from pages

[Jason Gunthorpe]

On Fri, Oct 02, 2020 at 07:11:33PM +0300, Maor Gottlieb wrote:
> 
> On 10/2/2020 6:02 PM, Jason Gunthorpe wrote:
> > On Sun, Sep 27, 2020 at 09:46:44AM +0300, Leon Romanovsky wrote:
> > > +struct scatterlist *__sg_alloc_table_from_pages(struct sg_table *sgt,
> > > + struct page **pages, unsigned int n_pages, unsigned int offset,
> > > + unsigned long size, unsigned int max_segment,
> > > + struct scatterlist *prv, unsigned int left_pages,
> > > + gfp_t gfp_mask)
> > >   {
> > > - unsigned int chunks, cur_page, seg_len, i;
> > > + unsigned int chunks, cur_page, seg_len, i, prv_len = 0;
> > > + struct scatterlist *s = prv;
> > > + unsigned int table_size;
> > > + unsigned int tmp_nents;
> > >   int ret;
> > > - struct scatterlist *s;
> > > 
> > >   if (WARN_ON(!max_segment || offset_in_page(max_segment)))
> > > - return -EINVAL;
> > > + return ERR_PTR(-EINVAL);
> > > + if (IS_ENABLED(CONFIG_ARCH_NO_SG_CHAIN) && prv)
> > > + return ERR_PTR(-EOPNOTSUPP);
> > > +
> > > + tmp_nents = prv ? sgt->nents : 0;
> > > +
> > > + if (prv &&
> > > + page_to_pfn(sg_page(prv)) + (prv->length >> PAGE_SHIFT) ==
> > This calculation of the end doesn't consider sg->offset
> 
> Right, should be fixed.
> > 
> > > + page_to_pfn(pages[0]))
> > > + prv_len = prv->length;
> > > 
> > >   /* compute number of contiguous chunks */
> > >   chunks = 1;
> > > @@ -410,13 +461,17 @@ int __sg_alloc_table_from_pages(struct sg_table 
> > > *sgt, struct page **pages,
> > >   }
> > >   }
> > > 
> > > - ret = sg_alloc_table(sgt, chunks, gfp_mask);
> > > - if (unlikely(ret))
> > > - return ret;
> > > + if (!prv) {
> > > + /* Only the last allocation could be less than the maximum */
> > > + table_size = left_pages ? SG_MAX_SINGLE_ALLOC : chunks;
> > > + ret = sg_alloc_table(sgt, table_size, gfp_mask);
> > > + if (unlikely(ret))
> > > + return ERR_PTR(ret);
> > > + }
> > This is basically redundant right? Now that get_next_sg() can allocate
> > SGs it can just build them one by one, no need to preallocate.
> > 
> > Actually all the changes the the allocation seem like overkill, just
> > allocate a single new array directly in get_next_sg() whenever it
> > needs.
> 
> No, only the last allocation could be less than maximum. (as written in the
> comment).

The point is that get_next_sg is fully redundent with
sg_alloc_table() because it is always used in cases when prv is
set. There is zero reason to call sg_alloc_table here in the one case
where prv is not set.

Further this cleans up the spagehtti goto in the middle of the for
loop and avoids allocating an extra chunk if the page list fully fits
in prv.

Given how much smaller it is I think you should look more carefully.

Jason

[RESEND v3] dt-bindings: mailbox: fsl,mu: Add missing power-domains

[Krzysztof Kozlowski]

Add quite common property - power-domains - to fix dtbs_check warnings
like:

  arch/arm64/boot/dts/freescale/imx8qxp-mek.dt.yaml:
mailbox@5d28: 'power-domains' does not match any of the regexes: 
'pinctrl-[0-9]+'

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Dong Aisheng 

---

Hi Rob,

You previously reviewed this patch. Can you pick it up to your tree?

Best regards,
Krzysztof

Changes since v2:
1. Set maxItems to power domains to 1

Changes since v1:
1. Add missing properties instead of unevaluatedProperties
---
 Documentation/devicetree/bindings/mailbox/fsl,mu.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml 
b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
index 7ed096360be2..15cef82cd356 100644
--- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
+++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml
@@ -72,6 +72,9 @@ properties:
 description: boolean, if present, means it is for side B MU.
 type: boolean
 
+  power-domains:
+maxItems: 1
+
 required:
   - compatible
   - reg
-- 
2.17.1

Re: [PATCH] arm64: dts: qcom: sc7180: Fix one forgotten interconnect reference

[Georgi Djakov]

Thanks for the patch!

On 10/2/20 00:18, Douglas Anderson wrote:
> In commit e23b1220a246 ("arm64: dts: qcom: sc7180: Increase the number
> of interconnect cells") we missed increasing the cells on one
> interconnect.  That's no bueno.  Fix it.
> 
> NOTE: it appears that things aren't totally broken without this fix,
> but clearly something isn't going to be working right.  If nothing
> else, without this fix I see this in the logs:
> 
>   OF: /soc@0/mdss@ae0: could not get #interconnect-cells for 
> /soc@0/interrupt-controller@17a0
> 
> Fixes: e23b1220a246 ("arm64: dts: qcom: sc7180: Increase the number of 
> interconnect cells")
> Signed-off-by: Douglas Anderson 

Reviewed-by: Georgi Djakov 

BR,
Georgi

Re: [PATCH] mm/util.c: Add error logs for commitment overflow

[pintu]

On 2020-10-02 17:41, Matthew Wilcox wrote:



I don't think the __func__ is particularly useful information.  I would
also expect the name of the process to be more interesting than the 
PID.

And why is the ppid useful?



Dear Matthew, First, thank you so much for your review and comments.
I totally agree with you.
Yes, initially I included process-name but later removed it to shrink 
some lines.
I thought just pid should be enough to figure out the culprit process 
from dumps.

Okay, I agree __func__ can also be removed.
ppid, I thought might be useful, so I included it. Okay I will remove 
that too.



Wouldn't this message be more useful?

fork: Would overcommit system (pid:162 name:./consume-and-fork.out)



Okay, yes I think this should be sufficient.
But I think printing pages also should be good to indicate the users to 
lack

information about this commitment.


ie put it in dup_mmap() and use current->comm


Sorry, this part about dup_mmap(), I could not understand.


Thanks,
Pintu

Re: [PATCH 3/3] task_work: use TIF_TASKWORK if available

[Jens Axboe]

On 10/2/20 9:38 AM, Oleg Nesterov wrote:
> On 10/02, Thomas Gleixner wrote:
>>
>> I think it's fundamentaly wrong that we have several places and several
>> flags which handle task_work_run() instead of having exactly one place
>> and one flag.
> 
> Damn yes, agreed.

As mentioned in the other reply, this is actually a nice step towards
NOT having that be the case. Right now we have TWA_RESUME, which uses
TIF_NOTIFY_RESUME. Once all archs support TIF_NOTIFY_SIGNAL, then we can
totally drop TWA_NOTIFY resume, and use use TWA_SIGNAL as the default
for notify == true task_work users. And we can drop task_work noticing
and running in the signal handling as well, leaving us with only having
tracehook_notify_signal() running the task_work.

-- 
Jens Axboe

Re: [PATCH v7] Add MediaTek MT6779 devapc driver

[Chun-Kuang Hu]

Hi, Neal:

You may find Matthias in IRC [1], the channel name is #linux-mediatek

[1] https://webchat.freenode.net/

Neal Liu  於 2020年9月30日 週三 下午3:10寫道：
>
> Hi Matt,
>
> Hope this mail could find you well.
> Is everything okay?
> It would be glad if you could reply me no matter the review status.
>
> Thanks
>
> -Neal
>
> On Tue, 2020-09-22 at 15:13 +0800, Neal Liu wrote:
> > Hi Matthias,
> >
> > We need this driver supported on main-line.
> > Could you save your time for us to review it?
> > Thanks
> >
> > -Neal
> >
> > On Wed, 2020-09-16 at 16:58 +0800, Neal Liu wrote:
> > > Hi Rob, Matthias, Chun-Kuang,
> > >
> > > Sorry for pushing you so hard.
> > > May I know is this patch set is comfortable to apply on latest kernel?
> > > Thanks
> > >
> > > -Neal
> > >
> > > On Wed, 2020-09-09 at 16:37 +0800, Neal Liu wrote:
> > > > Hi Rob, Matthias, Chun-Kuang,
> > > >
> > > > Please kindly let me know your comments about this patch set.
> > > > Thanks
> > > >
> > > > -Neal
> > > >
> > > > On Wed, 2020-09-02 at 14:40 +0800, Neal Liu wrote:
> > > > > Hi Rob, Matthias, Chun-Kuang,
> > > > >
> > > > > Gentle ping for this patch set.
> > > > > Thanks
> > > > >
> > > > > -Neal
> > > > >
> > > > > On Thu, 2020-08-27 at 11:06 +0800, Neal Liu wrote:
> > > > > > These patch series introduce a MediaTek MT6779 devapc driver.
> > > > > >
> > > > > > MediaTek bus fabric provides TrustZone security support and data 
> > > > > > protection to prevent slaves from being accessed by unexpected 
> > > > > > masters.
> > > > > > The security violation is logged and sent to the processor for 
> > > > > > further analysis or countermeasures.
> > > > > >
> > > > > > Any occurrence of security violation would raise an interrupt, and 
> > > > > > it will be handled by mtk-devapc driver.
> > > > > > The violation information is printed in order to find the murderer.
> > > > > >
> > > > > > changes since v6:
> > > > > > - remove unnecessary mask/unmask module irq during ISR.
> > > > > >
> > > > > > changes since v5:
> > > > > > - remove redundant write reg operation.
> > > > > > - use static variable of vio_dbgs instead.
> > > > > > - add stop_devapc() if driver is removed.
> > > > > >
> > > > > > changes since v4:
> > > > > > - refactor data structure.
> > > > > > - merge two simple functions into one.
> > > > > > - refactor register setting to prevent too many function call 
> > > > > > overhead.
> > > > > >
> > > > > > changes since v3:
> > > > > > - revise violation handling flow to make it more easily to 
> > > > > > understand
> > > > > >   hardware behavior.
> > > > > > - add more comments to understand how hardware works.
> > > > > >
> > > > > > changes since v2:
> > > > > > - pass platform info through DT data.
> > > > > > - remove unnecessary function.
> > > > > > - remove slave_type because it always equals to 1 in current 
> > > > > > support SoC.
> > > > > > - use vio_idx_num instread of list all devices' index.
> > > > > > - add more comments to describe hardware behavior.
> > > > > >
> > > > > > changes since v1:
> > > > > > - move SoC specific part to DT data.
> > > > > > - remove unnecessary boundary check.
> > > > > > - remove unnecessary data type declaration.
> > > > > > - use read_poll_timeout() instread of for loop polling.
> > > > > > - revise coding style elegantly.
> > > > > >
> > > > > >
> > > > > > *** BLURB HERE ***
> > > > > >
> > > > > > Neal Liu (2):
> > > > > >   dt-bindings: devapc: add bindings for mtk-devapc
> > > > > >   soc: mediatek: add mt6779 devapc driver
> > > > > >
> > > > > >  .../bindings/soc/mediatek/devapc.yaml |  58 
> > > > > >  drivers/soc/mediatek/Kconfig  |   9 +
> > > > > >  drivers/soc/mediatek/Makefile |   1 +
> > > > > >  drivers/soc/mediatek/mtk-devapc.c | 305 
> > > > > > ++
> > > > > >  4 files changed, 373 insertions(+)
> > > > > >  create mode 100644 
> > > > > > Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> > > > > >  create mode 100644 drivers/soc/mediatek/mtk-devapc.c
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>

Re: [PATCH 3/3] hwmon: bt1-pvt: Wait for the completion with timeout

[Guenter Roeck]

On Sun, Sep 20, 2020 at 02:09:23PM +0300, Serge Semin wrote:
> If the PVT sensor is suddenly powered down while a caller is waiting for
> the conversion completion, the request won't be finished and the task will
> hang up on this procedure until the power is back up again. Let's call the
> wait_for_completion_timeout() method instead to prevent that. The cached
> timeout is exactly what we need to predict for how long conversion could
> normally last.
> 
> Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver")
> Signed-off-by: Serge Semin 

Applied.

Thanks,
Guenter

> ---
>  drivers/hwmon/bt1-pvt.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/bt1-pvt.c b/drivers/hwmon/bt1-pvt.c
> index 2600426a3b21..3e1d56585b91 100644
> --- a/drivers/hwmon/bt1-pvt.c
> +++ b/drivers/hwmon/bt1-pvt.c
> @@ -477,6 +477,7 @@ static int pvt_read_data(struct pvt_hwmon *pvt, enum 
> pvt_sensor_type type,
>long *val)
>  {
>   struct pvt_cache *cache = >cache[type];
> + unsigned long timeout;
>   u32 data;
>   int ret;
>  
> @@ -500,7 +501,14 @@ static int pvt_read_data(struct pvt_hwmon *pvt, enum 
> pvt_sensor_type type,
>   pvt_update(pvt->regs + PVT_INTR_MASK, PVT_INTR_DVALID, 0);
>   pvt_update(pvt->regs + PVT_CTRL, PVT_CTRL_EN, PVT_CTRL_EN);
>  
> - wait_for_completion(>conversion);
> + /*
> +  * Wait with timeout since in case if the sensor is suddenly powered
> +  * down the request won't be completed and the caller will hang up on
> +  * this procedure until the power is back up again. Multiply the
> +  * timeout by the factor of two to prevent a false timeout.
> +  */
> + timeout = 2 * usecs_to_jiffies(ktime_to_us(pvt->timeout));
> + ret = wait_for_completion_timeout(>conversion, timeout);
>  
>   pvt_update(pvt->regs + PVT_CTRL, PVT_CTRL_EN, 0);
>   pvt_update(pvt->regs + PVT_INTR_MASK, PVT_INTR_DVALID,
> @@ -510,6 +518,9 @@ static int pvt_read_data(struct pvt_hwmon *pvt, enum 
> pvt_sensor_type type,
>  
>   mutex_unlock(>iface_mtx);
>  
> + if (!ret)
> + return -ETIMEDOUT;
> +
>   if (type == PVT_TEMP)
>   *val = pvt_calc_poly(_N_to_temp, data);
>   else

Re: [PATCH 2/3] hwmon: bt1-pvt: Cache current update timeout

[Guenter Roeck]

On Sun, Sep 20, 2020 at 02:09:22PM +0300, Serge Semin wrote:
> Instead of converting the update timeout data to the milliseconds each
> time on the read procedure let's preserve the currently set timeout in the
> dedicated driver private data cache. The cached value will be then used in
> the timeout read method and in the alarm-less data conversion to prevent
> the caller task hanging up in case if the PVT sensor is suddenly powered
> down.
> 
> Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver")
> Signed-off-by: Serge Semin 

Applied.

Thanks,
Guenter

> ---
>  drivers/hwmon/bt1-pvt.c | 85 ++---
>  drivers/hwmon/bt1-pvt.h |  3 ++
>  2 files changed, 49 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/hwmon/bt1-pvt.c b/drivers/hwmon/bt1-pvt.c
> index f4b7353c078a..2600426a3b21 100644
> --- a/drivers/hwmon/bt1-pvt.c
> +++ b/drivers/hwmon/bt1-pvt.c
> @@ -655,44 +655,16 @@ static int pvt_write_trim(struct pvt_hwmon *pvt, long 
> val)
>  
>  static int pvt_read_timeout(struct pvt_hwmon *pvt, long *val)
>  {
> - unsigned long rate;
> - ktime_t kt;
> - u32 data;
> -
> - rate = clk_get_rate(pvt->clks[PVT_CLOCK_REF].clk);
> - if (!rate)
> - return -ENODEV;
> -
> - /*
> -  * Don't bother with mutex here, since we just read data from MMIO.
> -  * We also have to scale the ticks timeout up to compensate the
> -  * ms-ns-data translations.
> -  */
> - data = readl(pvt->regs + PVT_TTIMEOUT) + 1;
> + int ret;
>  
> - /*
> -  * Calculate ref-clock based delay (Ttotal) between two consecutive
> -  * data samples of the same sensor. So we first must calculate the
> -  * delay introduced by the internal ref-clock timer (Tref * Fclk).
> -  * Then add the constant timeout cuased by each conversion latency
> -  * (Tmin). The basic formulae for each conversion is following:
> -  *   Ttotal = Tref * Fclk + Tmin
> -  * Note if alarms are enabled the sensors are polled one after
> -  * another, so in order to have the delay being applicable for each
> -  * sensor the requested value must be equally redistirbuted.
> -  */
> -#if defined(CONFIG_SENSORS_BT1_PVT_ALARMS)
> - kt = ktime_set(PVT_SENSORS_NUM * (u64)data, 0);
> - kt = ktime_divns(kt, rate);
> - kt = ktime_add_ns(kt, PVT_SENSORS_NUM * PVT_TOUT_MIN);
> -#else
> - kt = ktime_set(data, 0);
> - kt = ktime_divns(kt, rate);
> - kt = ktime_add_ns(kt, PVT_TOUT_MIN);
> -#endif
> + ret = mutex_lock_interruptible(>iface_mtx);
> + if (ret)
> + return ret;
>  
>   /* Return the result in msec as hwmon sysfs interface requires. */
> - *val = ktime_to_ms(kt);
> + *val = ktime_to_ms(pvt->timeout);
> +
> + mutex_unlock(>iface_mtx);
>  
>   return 0;
>  }
> @@ -700,7 +672,7 @@ static int pvt_read_timeout(struct pvt_hwmon *pvt, long 
> *val)
>  static int pvt_write_timeout(struct pvt_hwmon *pvt, long val)
>  {
>   unsigned long rate;
> - ktime_t kt;
> + ktime_t kt, cache;
>   u32 data;
>   int ret;
>  
> @@ -713,7 +685,7 @@ static int pvt_write_timeout(struct pvt_hwmon *pvt, long 
> val)
>* between all available sensors to have the requested delay
>* applicable to each individual sensor.
>*/
> - kt = ms_to_ktime(val);
> + cache = kt = ms_to_ktime(val);
>  #if defined(CONFIG_SENSORS_BT1_PVT_ALARMS)
>   kt = ktime_divns(kt, PVT_SENSORS_NUM);
>  #endif
> @@ -742,6 +714,7 @@ static int pvt_write_timeout(struct pvt_hwmon *pvt, long 
> val)
>   return ret;
>  
>   pvt_set_tout(pvt, data);
> + pvt->timeout = cache;
>  
>   mutex_unlock(>iface_mtx);
>  
> @@ -1018,10 +991,17 @@ static int pvt_check_pwr(struct pvt_hwmon *pvt)
>   return ret;
>  }
>  
> -static void pvt_init_iface(struct pvt_hwmon *pvt)
> +static int pvt_init_iface(struct pvt_hwmon *pvt)
>  {
> + unsigned long rate;
>   u32 trim, temp;
>  
> + rate = clk_get_rate(pvt->clks[PVT_CLOCK_REF].clk);
> + if (!rate) {
> + dev_err(pvt->dev, "Invalid reference clock rate\n");
> + return -ENODEV;
> + }
> +
>   /*
>* Make sure all interrupts and controller are disabled so not to
>* accidentally have ISR executed before the driver data is fully
> @@ -1036,12 +1016,37 @@ static void pvt_init_iface(struct pvt_hwmon *pvt)
>   pvt_set_mode(pvt, pvt_info[pvt->sensor].mode);
>   pvt_set_tout(pvt, PVT_TOUT_DEF);
>  
> + /*
> +  * Preserve the current ref-clock based delay (Ttotal) between the
> +  * sensors data samples in the driver data so not to recalculate it
> +  * each time on the data requests and timeout reads. It consists of the
> +  * delay introduced by the internal ref-clock timer (N / Fclk) and the
> +  * constant timeout caused by each conversion latency (Tmin):
> +  *   Ttotal = N / Fclk + Tmin
> +  * If alarms are enabled the sensors 

Re: [PATCH 1/3] hwmon: bt1-pvt: Test sensor power supply on probe

[Guenter Roeck]

On Sun, Sep 20, 2020 at 02:09:21PM +0300, Serge Semin wrote:
> Baikal-T1 PVT sensor has got a dedicated power supply domain (feed up by
> the external GPVT/VPVT_18 pins). In case if it isn't powered up, the
> registers will be accessible, but the sensor conversion just won't happen.
> Due to that an attempt to read data from any PVT sensor will cause the
> task hanging up.  For instance that will happen if XP11 jumper isn't
> installed on the Baikal-T1-based BFK3.1 board. Let's at least test whether
> the conversion work on the device probe procedure. By doing so will make
> sure that the PVT sensor is powered up at least at boot time.
> 
> Fixes: 87976ce2825d ("hwmon: Add Baikal-T1 PVT sensor driver")
> Signed-off-by: Serge Semin 

Applied.

Thanks,
Guenter

> ---
>  drivers/hwmon/bt1-pvt.c | 40 
>  1 file changed, 40 insertions(+)
> 
> diff --git a/drivers/hwmon/bt1-pvt.c b/drivers/hwmon/bt1-pvt.c
> index 94698cae0497..f4b7353c078a 100644
> --- a/drivers/hwmon/bt1-pvt.c
> +++ b/drivers/hwmon/bt1-pvt.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -982,6 +983,41 @@ static int pvt_request_clks(struct pvt_hwmon *pvt)
>   return 0;
>  }
>  
> +static int pvt_check_pwr(struct pvt_hwmon *pvt)
> +{
> + unsigned long tout;
> + int ret = 0;
> + u32 data;
> +
> + /*
> +  * Test out the sensor conversion functionality. If it is not done on
> +  * time then the domain must have been unpowered and we won't be able
> +  * to use the device later in this driver.
> +  * Note If the power source is lost during the normal driver work the
> +  * data read procedure will either return -ETIMEDOUT (for the
> +  * alarm-less driver configuration) or just stop the repeated
> +  * conversion. In the later case alas we won't be able to detect the
> +  * problem.
> +  */
> + pvt_update(pvt->regs + PVT_INTR_MASK, PVT_INTR_ALL, PVT_INTR_ALL);
> + pvt_update(pvt->regs + PVT_CTRL, PVT_CTRL_EN, PVT_CTRL_EN);
> + pvt_set_tout(pvt, 0);
> + readl(pvt->regs + PVT_DATA);
> +
> + tout = PVT_TOUT_MIN / NSEC_PER_USEC;
> + usleep_range(tout, 2 * tout);
> +
> + data = readl(pvt->regs + PVT_DATA);
> + if (!(data & PVT_DATA_VALID)) {
> + ret = -ENODEV;
> + dev_err(pvt->dev, "Sensor is powered down\n");
> + }
> +
> + pvt_update(pvt->regs + PVT_CTRL, PVT_CTRL_EN, 0);
> +
> + return ret;
> +}
> +
>  static void pvt_init_iface(struct pvt_hwmon *pvt)
>  {
>   u32 trim, temp;
> @@ -1109,6 +1145,10 @@ static int pvt_probe(struct platform_device *pdev)
>   if (ret)
>   return ret;
>  
> + ret = pvt_check_pwr(pvt);
> + if (ret)
> + return ret;
> +
>   pvt_init_iface(pvt);
>  
>   ret = pvt_request_irq(pvt);

Re: [PATCH v2] dt-bindings: mfd: rohm,bd71837-pmic: Add common properties

[Krzysztof Kozlowski]

On Thu, Sep 17, 2020 at 09:37:54PM +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (clock-names,
> clock-output-names) with the common values (actually used in DTSes) to
> fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dt.yaml:
> pmic@4b: 'clock-names', 'clock-output-names', do not match any of the 
> regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Define the names, as used in existing DTS files.
> ---
>  .../devicetree/bindings/mfd/rohm,bd71837-pmic.yaml  | 6 ++
>  1 file changed, 6 insertions(+)

Dear Lee,

Could you take it via MFD tree? There is a review from Rob and ack from
author (Matti).

Best regards,
Krzysztof

Re: [PATCH v2 1/1] scsi: libiscsi: fix NOP race condition

[Lee Duncan]

On 9/25/20 11:41 AM, ldun...@suse.com wrote:
> From: Lee Duncan 
> 
> iSCSI NOPs are sometimes "lost", mistakenly sent to the
> user-land iscsid daemon instead of handled in the kernel,
> as they should be, resulting in a message from the daemon like:
> 
>> iscsid: Got nop in, but kernel supports nop handling.
> 
> This can occur because of the forward- and back-locks
> in the kernel iSCSI code, and the fact that an iSCSI NOP
> response can be processed before processing of the NOP send
> is complete. This can result in "conn->ping_task" being NULL
> in iscsi_nop_out_rsp(), when the pointer is actually in
> the process of being set.
> 
> To work around this, we add a new state to the "ping_task"
> pointer. In addition to NULL (not assigned) and a pointer
> (assigned), we add the state "being set", which is signaled
> with an INVALID pointer (using "-1").
> 
> Signed-off-by: Lee Duncan 
> ---
>  drivers/scsi/libiscsi.c | 13 ++---
>  include/scsi/libiscsi.h |  3 +++
>  2 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 1e9c3171fa9f..cade108c33b6 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -738,6 +738,9 @@ __iscsi_conn_send_pdu(struct iscsi_conn *conn, struct 
> iscsi_hdr *hdr,
>  task->conn->session->age);
>   }
>  
> + if (unlikely(READ_ONCE(conn->ping_task) == INVALID_SCSI_TASK))
> + WRITE_ONCE(conn->ping_task, task);
> +
>   if (!ihost->workq) {
>   if (iscsi_prep_mgmt_task(conn, task))
>   goto free_task;
> @@ -941,8 +944,11 @@ static int iscsi_send_nopout(struct iscsi_conn *conn, 
> struct iscsi_nopin *rhdr)
>  struct iscsi_nopout hdr;
>   struct iscsi_task *task;
>  
> - if (!rhdr && conn->ping_task)
> - return -EINVAL;
> + if (!rhdr) {
> + if (READ_ONCE(conn->ping_task))
> + return -EINVAL;
> + WRITE_ONCE(conn->ping_task, INVALID_SCSI_TASK);
> + }
>  
>   memset(, 0, sizeof(struct iscsi_nopout));
>   hdr.opcode = ISCSI_OP_NOOP_OUT | ISCSI_OP_IMMEDIATE;
> @@ -957,11 +963,12 @@ static int iscsi_send_nopout(struct iscsi_conn *conn, 
> struct iscsi_nopin *rhdr)
>  
>   task = __iscsi_conn_send_pdu(conn, (struct iscsi_hdr *), NULL, 0);
>   if (!task) {
> + if (!rhdr)
> + WRITE_ONCE(conn->ping_task, NULL);
>   iscsi_conn_printk(KERN_ERR, conn, "Could not send nopout\n");
>   return -EIO;
>   } else if (!rhdr) {
>   /* only track our nops */
> - conn->ping_task = task;
>   conn->last_ping = jiffies;
>   }
>  
> diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
> index c25fb86ffae9..b3bbd10eb3f0 100644
> --- a/include/scsi/libiscsi.h
> +++ b/include/scsi/libiscsi.h
> @@ -132,6 +132,9 @@ struct iscsi_task {
>   void*dd_data;   /* driver/transport data */
>  };
>  
> +/* invalid scsi_task pointer */
> +#define  INVALID_SCSI_TASK   (struct iscsi_task *)-1l
> +
>  static inline int iscsi_task_has_unsol_data(struct iscsi_task *task)
>  {
>   return task->unsol_r2t.data_length > task->unsol_r2t.sent;
> 

Ping?

-- 
Lee Duncan

Re: [PATCH v2 1/2] ARM: dts: rk3188: correct interrupt flags

[Krzysztof Kozlowski]

On Thu, Sep 17, 2020 at 08:52:10PM +0200, Krzysztof Kozlowski wrote:
> GPIO_ACTIVE_x flags are not correct in the context of interrupt flags.
> These are simple defines so they could be used in DTS but they will not
> have the same meaning:
> 1. GPIO_ACTIVE_HIGH = 0 = IRQ_TYPE_NONE
> 2. GPIO_ACTIVE_LOW  = 1 = IRQ_TYPE_EDGE_RISING
> 
> Correct the interrupt flags without affecting the code:
>   ACTIVE_HIGH => IRQ_TYPE_NONE
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Not tested on HW.
> 
> Changes since v1:
> 1. Correct title
> ---
>  arch/arm/boot/dts/rk3188-bqedison2qc.dts | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

Hi,

Any comments/review/testing from Heiko or other Rockchip folks? Shall I
cc here someone?

Best regards,
Krzysztof

Re: [PATCH rdma-next v4 1/4] lib/scatterlist: Add support in dynamic allocation of SG table from pages

[Maor Gottlieb]

On 10/2/2020 6:02 PM, Jason Gunthorpe wrote:

On Sun, Sep 27, 2020 at 09:46:44AM +0300, Leon Romanovsky wrote:

+struct scatterlist *__sg_alloc_table_from_pages(struct sg_table *sgt,
+   struct page **pages, unsigned int n_pages, unsigned int offset,
+   unsigned long size, unsigned int max_segment,
+   struct scatterlist *prv, unsigned int left_pages,
+   gfp_t gfp_mask)
  {
-   unsigned int chunks, cur_page, seg_len, i;
+   unsigned int chunks, cur_page, seg_len, i, prv_len = 0;
+   struct scatterlist *s = prv;
+   unsigned int table_size;
+   unsigned int tmp_nents;
int ret;
-   struct scatterlist *s;

if (WARN_ON(!max_segment || offset_in_page(max_segment)))
-   return -EINVAL;
+   return ERR_PTR(-EINVAL);
+   if (IS_ENABLED(CONFIG_ARCH_NO_SG_CHAIN) && prv)
+   return ERR_PTR(-EOPNOTSUPP);
+
+   tmp_nents = prv ? sgt->nents : 0;
+
+   if (prv &&
+   page_to_pfn(sg_page(prv)) + (prv->length >> PAGE_SHIFT) ==

This calculation of the end doesn't consider sg->offset


Right, should be fixed.



+   page_to_pfn(pages[0]))
+   prv_len = prv->length;

/* compute number of contiguous chunks */
chunks = 1;
@@ -410,13 +461,17 @@ int __sg_alloc_table_from_pages(struct sg_table *sgt, 
struct page **pages,
}
}

-   ret = sg_alloc_table(sgt, chunks, gfp_mask);
-   if (unlikely(ret))
-   return ret;
+   if (!prv) {
+   /* Only the last allocation could be less than the maximum */
+   table_size = left_pages ? SG_MAX_SINGLE_ALLOC : chunks;
+   ret = sg_alloc_table(sgt, table_size, gfp_mask);
+   if (unlikely(ret))
+   return ERR_PTR(ret);
+   }

This is basically redundant right? Now that get_next_sg() can allocate
SGs it can just build them one by one, no need to preallocate.

Actually all the changes the the allocation seem like overkill, just
allocate a single new array directly in get_next_sg() whenever it
needs.


No, only the last allocation could be less than maximum. (as written in 
the comment).

I am preferring to stick with the current implementation and fix the offset.


Something like this:

@@ -365,6 +372,37 @@ int sg_alloc_table(struct sg_table *table, unsigned int 
nents, gfp_t gfp_mask)
  }
  EXPORT_SYMBOL(sg_alloc_table);
  
+static struct scatterlist *get_next_sg(struct sg_table *table,

+   struct scatterlist *cur, unsigned long needed_sges,
+   gfp_t gfp_mask)
+{
+   struct scatterlist *new_sg;
+   unsigned int alloc_size;
+
+   if (cur) {
+   struct scatterlist *next_sg = sg_next(cur);
+
+   /* Check if last entry should be keeped for chainning */
+   if (!sg_is_last(next_sg) || needed_sges == 1)
+   return next_sg;
+   }
+
+   alloc_size = min_t(unsigned long, needed_sges, SG_MAX_SINGLE_ALLOC);
+   new_sg = sg_kmalloc(alloc_size, gfp_mask);
+   if (!new_sg)
+   return ERR_PTR(-ENOMEM);
+   sg_init_table(new_sg, alloc_size);
+   if (cur) {
+   __sg_chain(cur, new_sg);
+   table->orig_nents += alloc_size - 1;
+   } else {
+   table->sgl = new_sg;
+   table->orig_nents = alloc_size;
+   table->nents = 0;
+   }
+   return new_sg;
+}
+
  /**
   * __sg_alloc_table_from_pages - Allocate and initialize an sg table from
   * an array of pages
@@ -374,29 +412,64 @@ EXPORT_SYMBOL(sg_alloc_table);
   * @offset:  Offset from start of the first page to the start of a buffer
   * @size:Number of valid bytes in the buffer (after offset)
   * @max_segment: Maximum size of a scatterlist node in bytes (page aligned)
+ * @prv:Last populated sge in sgt
+ * @left_pages:  Left pages caller have to set after this call
   * @gfp_mask:  GFP allocation mask
   *
- *  Description:
- *Allocate and initialize an sg table from a list of pages. Contiguous
- *ranges of the pages are squashed into a single scatterlist node up to the
- *maximum size specified in @max_segment. An user may provide an offset at 
a
- *start and a size of valid data in a buffer specified by the page array.
- *The returned sg table is released by sg_free_table.
+ * Description:
+ *If @prv is NULL, allocate and initialize an sg table from a list of 
pages,
+ *else reuse the scatterlist passed in at @prv.
+ *Contiguous ranges of the pages are squashed into a single scatterlist
+ *entry up to the maximum size specified in @max_segment.  A user may
+ *provide an offset at a start and a size of valid data in a buffer
+ *specified by the page array.
   *
   * Returns:
- *   0 on success, negative error on failure
+ *   Last SGE in sgt on success, PTR_ERR on otherwise.
+ *  

Re: [PATCH v4 03/11] arm64, kfence: enable KFENCE for ARM64

[Jann Horn]

On Fri, Oct 2, 2020 at 4:19 PM Marco Elver  wrote:
>
> On Fri, 2 Oct 2020 at 08:48, Jann Horn  wrote:
> >
> > On Tue, Sep 29, 2020 at 3:38 PM Marco Elver  wrote:
> > > Add architecture specific implementation details for KFENCE and enable
> > > KFENCE for the arm64 architecture. In particular, this implements the
> > > required interface in . Currently, the arm64 version does
> > > not yet use a statically allocated memory pool, at the cost of a pointer
> > > load for each is_kfence_address().
> > [...]
> > > diff --git a/arch/arm64/include/asm/kfence.h 
> > > b/arch/arm64/include/asm/kfence.h
> > [...]
> > > +static inline bool arch_kfence_initialize_pool(void)
> > > +{
> > > +   const unsigned int num_pages = 
> > > ilog2(roundup_pow_of_two(KFENCE_POOL_SIZE / PAGE_SIZE));
> > > +   struct page *pages = alloc_pages(GFP_KERNEL, num_pages);
> > > +
> > > +   if (!pages)
> > > +   return false;
> > > +
> > > +   __kfence_pool = page_address(pages);
> > > +   return true;
> > > +}
> >
> > If you're going to do "virt_to_page(meta->addr)->slab_cache = cache;"
> > on these pages in kfence_guarded_alloc(), and pass them into kfree(),
> > you'd better mark these pages as non-compound - something like
> > alloc_pages_exact() or split_page() may help. Otherwise, I think when
> > SLUB's kfree() does virt_to_head_page() right at the start, that will
> > return a pointer to the first page of the entire __kfence_pool, and
> > then when it loads page->slab_cache, it gets some random cache and
> > stuff blows up. Kinda surprising that you haven't run into that during
> > your testing, maybe I'm missing something...
>
> I added a WARN_ON() check in kfence_initialize_pool() to check if our
> pages are compound or not; they are not.
>
> In slub.c, __GFP_COMP is passed to alloc_pages(), which causes them to
> have a compound head I believe.

Aah, I mixed up high-order pages and compound pages. Sorry for the noise.

[PATCH 2/2] ASoC: mchp-spdifrx: add driver for SPDIF RX

[Codrin Ciubotariu]

The new SPDIF RX controller is a serial port compliant with the IEC-60958
standard. It also supports programmable User Data and Channel Status
fields.

This IP is embedded in Microchip's sama7g5 SoC.

Signed-off-by: Codrin Ciubotariu 
---
 sound/soc/atmel/Kconfig|  13 +
 sound/soc/atmel/Makefile   |   2 +
 sound/soc/atmel/mchp-spdifrx.c | 954 +
 3 files changed, 969 insertions(+)
 create mode 100644 sound/soc/atmel/mchp-spdifrx.c

diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 93beb7d670a3..bd8854bfd2ee 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -144,4 +144,17 @@ config SND_MCHP_SOC_SPDIFTX
 
  This S/PDIF TX driver is compliant with IEC-60958 standard and
  includes programable User Data and Channel Status fields.
+
+config SND_MCHP_SOC_SPDIFRX
+   tristate "Microchip ASoC driver for boards using S/PDIF RX"
+   depends on OF && (ARCH_AT91 || COMPILE_TEST)
+   select SND_SOC_GENERIC_DMAENGINE_PCM
+   select REGMAP_MMIO
+   help
+ Say Y or M if you want to add support for Microchip S/PDIF RX ASoc
+ driver on the following Microchip platforms:
+ - sama7g5
+
+ This S/PDIF RX driver is compliant with IEC-60958 standard and
+ includes programable User Data and Channel Status fields.
 endif
diff --git a/sound/soc/atmel/Makefile b/sound/soc/atmel/Makefile
index 3fd89a0063df..016188397210 100644
--- a/sound/soc/atmel/Makefile
+++ b/sound/soc/atmel/Makefile
@@ -6,6 +6,7 @@ snd-soc-atmel_ssc_dai-objs := atmel_ssc_dai.o
 snd-soc-atmel-i2s-objs := atmel-i2s.o
 snd-soc-mchp-i2s-mcc-objs := mchp-i2s-mcc.o
 snd-soc-mchp-spdiftx-objs := mchp-spdiftx.o
+snd-soc-mchp-spdifrx-objs := mchp-spdifrx.o
 
 # pdc and dma need to both be built-in if any user of
 # ssc is built-in.
@@ -19,6 +20,7 @@ obj-$(CONFIG_SND_ATMEL_SOC_SSC) += snd-soc-atmel_ssc_dai.o
 obj-$(CONFIG_SND_ATMEL_SOC_I2S) += snd-soc-atmel-i2s.o
 obj-$(CONFIG_SND_MCHP_SOC_I2S_MCC) += snd-soc-mchp-i2s-mcc.o
 obj-$(CONFIG_SND_MCHP_SOC_SPDIFTX) += snd-soc-mchp-spdiftx.o
+obj-$(CONFIG_SND_MCHP_SOC_SPDIFRX) += snd-soc-mchp-spdifrx.o
 
 # AT91 Machine Support
 snd-soc-sam9g20-wm8731-objs := sam9g20_wm8731.o
diff --git a/sound/soc/atmel/mchp-spdifrx.c b/sound/soc/atmel/mchp-spdifrx.c
new file mode 100644
index ..6776d89d56df
--- /dev/null
+++ b/sound/soc/atmel/mchp-spdifrx.c
@@ -0,0 +1,954 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Driver for Microchip S/PDIF RX Controller
+//
+// Copyright (C) 2020 Microchip Technology Inc. and its subsidiaries
+//
+// Author: Codrin Ciubotariu 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/*
+ *  S/PDIF Receiver Controller Register map 
+ */
+#define SPDIFRX_CR 0x00/* Control Register */
+#define SPDIFRX_MR 0x04/* Mode Register */
+
+#define SPDIFRX_IER0x10/* Interrupt Enable Register */
+#define SPDIFRX_IDR0x14/* Interrupt Disable Register */
+#define SPDIFRX_IMR0x18/* Interrupt Mask Register */
+#define SPDIFRX_ISR0x1c/* Interrupt Status Register */
+#define SPDIFRX_RSR0x20/* Status Register */
+#define SPDIFRX_RHR0x24/* Holding Register */
+
+#define SPDIFRX_CHSR(channel, reg) \
+   (0x30 + (channel) * 0x30 + (reg) * 4)   /* Channel x Status Registers */
+
+#define SPDIFRX_CHUD(channel, reg) \
+   (0x48 + (channel) * 0x30 + (reg) * 4)   /* Channel x User Data 
Registers */
+
+#define SPDIFRX_WPMR   0xE4/* Write Protection Mode 
Register */
+#define SPDIFRX_WPSR   0xE8/* Write Protection Status 
Register */
+
+#define SPDIFRX_VERSION0xFC/* Version Register */
+
+/*
+ *  Control Register (Write-only) 
+ */
+#define SPDIFRX_CR_SWRST   BIT(0)  /* Software Reset */
+
+/*
+ *  Mode Register (Read/Write) 
+ */
+/* Receive Enable */
+#define SPDIFRX_MR_RXEN_MASK   GENMASK(0, 0)
+#define SPDIFRX_MR_RXEN_DISABLE(0 << 0)/* SPDIF 
Receiver Disabled */
+#define SPDIFRX_MR_RXEN_ENABLE (1 << 0)/* SPDIF Receiver 
Enabled */
+
+/* Validity Bit Mode */
+#define SPDIFRX_MR_VBMODE_MASK GENAMSK(1, 1)
+#define SPDIFRX_MR_VBMODE_ALWAYS_LOAD \
+   (0 << 1)/* Load sample regardles of validity bit value */
+#define SPDIFRX_MR_VBMODE_DISCARD_IF_VB1 \
+   (1 << 1)/* Load sample only if validity bit is 0 */
+
+/* Data Word Endian Mode */
+#define SPDIFRX_MR_ENDIAN_MASK GENMASK(2, 2)
+#define SPDIFRX_MR_ENDIAN_LITTLE   (0 << 2)/* Little Endian Mode */
+#define SPDIFRX_MR_ENDIAN_BIG  (1 << 2)/* Big Endian Mode */
+
+/* Parity Bit Mode */
+#define SPDIFRX_MR_PBMODE_MASK GENMASK(3, 3)
+#define 

[PATCH 0/2] Add driver for Microchip S/PDIF RX

[Codrin Ciubotariu]

The Sony/Philips Digital Interface Receiver (SPDIFRX) is a serial port
compliant with the IEC-60958 standard. Among its caracteristics, we
mention the following:
 - SPDIF/AES-EBU Compatible Serial Port
 - 32 Samples FIFO
 - Data Width Configurable to 24 bits, 20 bits or 16 bits
 - Packed and Unpacked Data Support for System Memory Optimization
 - Line State Events Report and Source of Interrupt
 - Line Error Rate Report
 - Full Memory Map of 192 bits for Channel 1 and Channel 2 Status and
   User Data
 - First 32-bit Status A, Status B Change Report and Source of Interrupt
 - Line Digital Filter
 - Register Write Protection
 - Abnormal Software Access and Internal Sequencer Integrity Check Reports

This interface is available in Microchip's SAMA7G5 SoC.

Codrin Ciubotariu (2):
  dt-bindings: sound: add DT bindings for Microchip S/PDIF RX Controller
  ASoC: mchp-spdifrx: add driver for SPDIF RX

 .../bindings/sound/mchp,spdifrx.yaml  |  73 ++
 sound/soc/atmel/Kconfig   |  13 +
 sound/soc/atmel/Makefile  |   2 +
 sound/soc/atmel/mchp-spdifrx.c| 954 ++
 4 files changed, 1042 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml
 create mode 100644 sound/soc/atmel/mchp-spdifrx.c

-- 
2.25.1

Re: [PATCH 0/8] Add support for UHS modes in TI's J721e and J7200 boards

[Faiz Abbas]

Hi Nishanth,

On 02/10/20 6:19 pm, Nishanth Menon wrote:
> On 10:14-20201002, Faiz Abbas wrote:
>> Hi Nishanth,
>>
>> On 02/10/20 12:43 am, Nishanth Menon wrote:
>>> On 00:35-20201002, Faiz Abbas wrote:
>>>> The following patches add support for UHS modes for TI's j721e and j7200
>>>> boards.
>>>>
>>>> Patches 1-3 add support for gpios to j7200-evm
>>>>
>>>> Patches 4-6 add support for voltage regulators for required by the
>>>> SD card in both devices as well as enable UHS modes at 1.8V
>>>>
>>>> Patches 5-6 add some required configs to the arm64 defconfig.
>>>>
>>>> This series depends on driver patches adding tuning support here:
>>>> https://lore.kernel.org/linux-arm-kernel/20200923105206.7988-1-faiz_ab...@ti.com/
>>>>
>>>> Faiz Abbas (8):
>>>>   arm64: dts: ti: k3-j7200-main: Add gpio nodes in main domain
>>>>   arm64: dts: ti: k3-j7200: Add gpio nodes in wakeup domain
>>>>   arm64: dts: ti: k3-j7200-common-proc-board: Disable unused gpio
>>>> modules
>>>>   arm64: dts: ti: k3-j721e-main: Add output tap delay values
>>>>   arm64: dts: ti: k3-j721e-common-proc-board: Add support SD card UHS
>>>> modes
>>>>   arm64: dts: ti: k3-j7200-common-proc-board: Add support SD card UHS
>>>> modes
>>>
>>> Split these up please!
>>
>> Into SD card UHS and gpio series?
>>
>>>>   arm64: defconfig: Enable OMAP I2C driver
>>>>   arm64: defconfig: Enable DAVINCI_GPIO driver
>>>>
>>>
>>> defconfig patches can be posted independent of dts patches, they go to
>>> different branches.
>>
>> I was trying to follow Arnd's advice here:
>> https://lore.kernel.org/linux-arm-kernel/CAK8P3a1JpCCCV-CVQj3+eMfWF+=4auhppv390tyj2pkn63_...@mail.gmail.com/
>>
>> He says that defconfig patches can be sent at the same time as dts updates 
>> and maintainers can send those
>> as separate pull requests.
> 
> BTW, [1] your patches 7/8 and 8/8 never hit the mailing list, So, I am
> commenting on the defconfig patches without actually seeing the patches,
> and solely based on $subject in the cover letter.

This is weird. They are there in my patches/ folder and I always do a "git 
send-email patches/* ..."

Not sure why they didn't get sent. My last send-email command does have all the 
patches being sent:

https://pastebin.ubuntu.com/p/VNWsrMcBZd/

> 
> The reason for my comment was that I think defconfig series could go
> independent of the remaining series into 5.10, since they are not
> related specifically to this series, they are probably needed even for
> am654 and j721e nodes that already exist and was a miss that we didn't
> enable. Tying that to this specific series didn't make sense to me.

You're right that they are not tied to the series.

> 
> But either way, we are way past rc7. I don't have enough time for
> these patches to bake in -next to make it to 5.10 window. So, lets try
> reposting this after rc1 tag is done so that I can send the defconfig
> (separately for 5.10 window) and the dts staged towards 5.11 (and no,
> I don't consider the dts patches as fixes - they are enabling the next
> level of functionality).
> 

Ok. I'll send only the defconfig patches in a new series and repost v2 of this 
at rc1.

Thanks,
Fai

Re: [PATCH 1/2] arm64: dts: apm: drop unused reg-io-width from DW APB GPIO controller

[Krzysztof Kozlowski]

On Thu, Sep 17, 2020 at 06:50:39PM +0200, Krzysztof Kozlowski wrote:
> The Synopsys DesignWare APB GPIO controller driver does not parse
> reg-io-width and dtschema does not allow it so drop it to fix dtschema
> warnings like:
> 
>   arch/arm64/boot/dts/apm/apm-mustang.dt.yaml: gpio@1c024000:
> 'reg-io-width' does not match any of the regexes: 
> '^gpio-(port|controller)@[0-9a-f]+$', 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---

Dear Arnd and Olof,

There is no response from APM maintainer, so maybe you could apply these
two patches directly? Optionally I could take it and send to you via
pull-request.

Best regards,
Krzysztof


> 
> Changes since v1:
> 1. New patch
> ---
>  arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 1 -
>  arch/arm64/boot/dts/apm/apm-storm.dtsi | 1 -
>  2 files changed, 2 deletions(-)
> 

Re: [PATCH v9 02/15] usb: typec: tcpci: Add set_vbus tcpci callback

[Badhri Jagan Sridharan]

Hi Greg,

Yes I tested it on usb-next before sending it out.

  630 |  tcpci->tcpc.enable_frs = tcpci_enable_frs;

In https://patchwork.kernel.org/project/linux-usb/list/?series=356837
i.e v9 version of this series,
Patch 7 i.e. https://patchwork.kernel.org/patch/11804847/ is where the
above line is added.

I restested in combinations [1]  [2] [3] [4]. All of them were clear
cherry-picks. I didnt any merge conflicts.

Maybe you are applying patches in a different order ?
If so can you post the git log for me to apply in the same order and test ?

Or Do you want me to rebase on top of usb-testing ?
I didnt see any merge conflicts though.

Thanks,
Badhri


[1] usb-testing all patches in series
https://patchwork.kernel.org/project/linux-usb/list/?series=356837
07684bb88ed4 (HEAD -> usb-testing) usb: typec: tcpci_maxim: Enable
auto discharge disconnect
1c97f5e32ba6 usb: typec: tcpci: Implement Auto discharge disconnect callbacks
1b829a062e6e usb: typec: tcpm: Implement enabling Auto Discharge
disconnect support
7ba4edfd9155 usb: typec: tcpm: Parse frs type-c current from device tree
01d47f2e98ba usb: typec: tcpci_max77759: Fix vbus stuck on upon
diconnecting sink
9e8ed3d8809c usb: typec: tcpci: frs sourcing vbus callback
8804a3f75563 usb: typec: tcpm: frs sourcing vbus callback
69fe6c1c7648 usb: typec: tcpci_maxim: Add support for Sink FRS
0a22d446c026 usb: typec: tcpci: Implement callbacks for FRS
93c622006aa6 usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)
14672081f2fd dt-bindings: connector: Add property to set initial
current cap for FRS
58372bd1d8e8 usb: typec: tcpci_maxim: Chip level TCPC driver
c16b09eaf60f dt-bindings: usb: Maxim type-c controller device tree
binding document
32d66c0449e1 usb: typec: tcpci: Add set_vbus tcpci callback
85e90e5054d6 usb: typec: tcpci: Add a getter method to retrieve
tcpm_port reference
97b65223c18f (origin/usb-testing) USB: core: remove polling for
/sys/kernel/debug/usb/devices
da0cb6310094 usb: typec: add support for STUSB160x Type-C controller family

[2] usb-testing: till patch4 in series
https://patchwork.kernel.org/project/linux-usb/list/?series=356837
58372bd1d8e8 (HEAD -> usb-testing) usb: typec: tcpci_maxim: Chip level
TCPC driver
c16b09eaf60f dt-bindings: usb: Maxim type-c controller device tree
binding document
32d66c0449e1 usb: typec: tcpci: Add set_vbus tcpci callback
85e90e5054d6 usb: typec: tcpci: Add a getter method to retrieve
tcpm_port reference
97b65223c18f (origin/usb-testing) USB: core: remove polling for
/sys/kernel/debug/usb/devices
da0cb6310094 usb: typec: add support for STUSB160x Type-C controller family

[3] usb-next all patches in series
https://patchwork.kernel.org/project/linux-usb/list/?series=356837
62b5171538da (HEAD -> usb-next) usb: typec: tcpci_maxim: Enable auto
discharge disconnect
ea8987805ba6 usb: typec: tcpci: Implement Auto discharge disconnect callbacks
af9a12b19352 usb: typec: tcpm: Implement enabling Auto Discharge
disconnect support
33aec604a529 usb: typec: tcpm: Parse frs type-c current from device tree
31df45f3df20 usb: typec: tcpci_max77759: Fix vbus stuck on upon
diconnecting sink
0945795f170d usb: typec: tcpci: frs sourcing vbus callback
c49080982064 usb: typec: tcpm: frs sourcing vbus callback
67a3ff254cc1 usb: typec: tcpci_maxim: Add support for Sink FRS
299582bbf78f usb: typec: tcpci: Implement callbacks for FRS
bb4eb3fb65df usb: typec: tcpm: Add support for Sink Fast Role SWAP(FRS)
5aad64e80460 dt-bindings: connector: Add property to set initial
current cap for FRS
6c59a16ddee2 usb: typec: tcpci_maxim: Chip level TCPC driver
172274d3e327 dt-bindings: usb: Maxim type-c controller device tree
binding document
bdba308a7164 usb: typec: tcpci: Add set_vbus tcpci callback
66b7b0d83399 usb: typec: tcpci: Add a getter method to retrieve
tcpm_port reference
59ee364bafb2 (origin/usb-next) Merge tag 'thunderbolt-for-v5.10-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt
into usb-next
bf1c67449833 USB: cdc-acm: clean up no-union-descriptor handling

[4] usb-next till patch4 in series
https://patchwork.kernel.org/project/linux-usb/list/?series=356837
6c59a16ddee2 (HEAD -> usb-next) usb: typec: tcpci_maxim: Chip level TCPC driver
172274d3e327 dt-bindings: usb: Maxim type-c controller device tree
binding document
bdba308a7164 usb: typec: tcpci: Add set_vbus tcpci callback
66b7b0d83399 usb: typec: tcpci: Add a getter method to retrieve
tcpm_port reference
59ee364bafb2 (origin/usb-next) Merge tag 'thunderbolt-for-v5.10-rc1'
of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt
into usb-next
bf1c67449833 USB: cdc-acm: clean up no-union-descriptor handling


On Fri, Oct 2, 2020 at 6:40 AM Greg Kroah-Hartman
 wrote:
>
> On Fri, Oct 02, 2020 at 03:39:52PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Sep 28, 2020 at 07:39:51PM -0700, Badhri Jagan Sridharan wrote:
> > > set_vbus callback allows TCPC which are TCPCI based, however,
> > > does not support turning on sink and source mode 

Re: [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs

[Matthias Kaehlcke]

On Thu, Oct 01, 2020 at 09:21:53PM -0400, Alan Stern wrote:
> On Thu, Oct 01, 2020 at 02:54:12PM -0700, Matthias Kaehlcke wrote:
> > Hi,
> > 
> > thanks for providing more insights on the USB hardware!
> 
> Sure.
> 
> > On Wed, Sep 30, 2020 at 09:24:13PM -0400, Alan Stern wrote:
> > > A hub that attaches only to the USB-3 data wires in a cable is not USB
> > > compliant.  A USB-2 device plugged into such a hub would not work.
> > > 
> > > But ports can be wired up in weird ways.  For example, it is possible
> > > to have the USB-3 wires from a port going directly to the host
> > > controller, while the USB-2 wires from the same port go through a
> > > USB-2 hub which is then connected to a separate host controller.  (In
> > > fact, my office computer has just such an arrangement.)
> > 
> > It's not clear to me how this case would be addressed when (some of) the
> > handling is done in xhci-plat.c We have two host controllers now, which one
> > is supposed to be in charge? I guess the idea is to specify the hub only
> > for one of the controllers?
> 
> I don't grasp the point of this question.  It doesn't seem to be
> relevant to the case you're concerned about -- your board isn't going to
> wire up the special hub in this weird way, is it?

When doing upstream development I try to look beyond my specific use case
and aim for solutions that are generally useful.

I don't know how common a configuration like the one on your office computer
is. If it isn't a fringe case it seems like we should support it if feasible.

> > > > Yes, I've been saying for some time we need a pre-probe. Or we need a
> > > > forced probe where the subsystem walks the DT nodes for the bus and
> > > > probes the devices in DT (if they're in DT, we know they are present).
> > > > This was the discussion only a few weeks ago for MDIO (which I think
> > > > concluded with they already do the latter).
> > > 
> > > This is why I suggested putting the new code into the xhci-platform
> > > driver.  That is the right place for doing these "pre-probes" of DT
> > > nodes for hubs attached to the host controller.
> > 
> > Reminder that the driver is not exclusively about powering the hub, but
> > also about powering it off conditionally during system suspend, depending
> > on what devices are connected to either of the busses. Should this also
> > be done in the xhci-platform driver?
> 
> It certainly could be.  The platform-specific xhci suspend and resume
> routines could power the hub on and off as needed, along with powering
> the host controller.
> 
> > Since we are talking about "pre-probes" I imagine the idea is to have a
> > USB device driver that implements the power on/off sequence (in pre_probe()
> > and handles the suspend/resume case. I already went through a variant of
> > this with an earlier version of the onboard_hub_driver, where suspend/resume
> > case was handled by the USB hub device. One of the problems with this was
> > that power must only be turned off after both USB hub devices have been
> > suspended. Some instance needs to be aware that there are two USB devices
> > and make the decision whether to cut the power during system suspend
> > or not, which is one of the reasons I ended up with the platform
> > driver. It's not clear to me how this would be addressed by using
> > "pre-probes". Potentially some of the handling could be done by
> > xhci-platform, but would that be really better than a dedicated driver?
> 
> _All_ of the handling could be done by xhci-plat.  Since the xHCI
> controller is the parent of both the USB-2 and USB-3 incarnations of
> the special hub, it won't get suspended until they are both in
> suspend, and it will get resumed before either of them.  Similarly,
> the power to the special hub could be switched on as part of the host
> controller's probe routine and switched off during the host
> controller's remove routine.
> 
> Using xhci-plat in this way would be better than a dedicated driver in
> the sense that it wouldn't then be necessary to make up a fictitious
> platform device and somehow describe it in DT.
> 
> The disadvantage is that we would end up with a driver that's
> nominally meant to handle host controllers but now also manages (at
> least in part) hubs.  A not-so-clean separation of functions.  But
> that's not terribly different from the way your current patch works,
> right?

Yes, this muddling of the xhci-plat code with the handling of hubs was
one of my concerns, but who am I to argue if you as USB maintainer see
that preferable over a dedicated driver. I suppose you are taking into
account that there will be a need for code for different hub models that
has to live somewhere (could be a dedicated file or directory).

And even if it is not my specific use case it would be nice to support
hubs that are part of a hierarchy and not wired directly to the host
controller. We don't necessarily have to implement all support for this
initially, but should have it in mind at least 

Re: [PATCH v6 4/5] PCI: only return true when dev io state is really changed

[Sinan Kaya]

On 9/30/2020 3:05 AM, Ethan Zhao wrote:
> When uncorrectable error happens, AER driver and DPC driver interrupt
> handlers likely call
> 
>pcie_do_recovery()
>->pci_walk_bus()
>  ->report_frozen_detected()
> 
> with pci_channel_io_frozen the same time.

We need some more data on this. If DPC is supported by HW, errors
should be triggered by DPC not AER.

If I remember right, there is a register that tells which AER errors
should be handled by DPC.

[GIT PULL] RISC-V Fixes for 5.9

[Palmer Dabbelt]

The following changes since commit a1b8638ba1320e6684aa98233c15255eb803fac7:

  Linux 5.9-rc7 (2020-09-27 14:38:10 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
tags/riscv-for-linus-5.9-rc8

for you to fetch changes up to aa9887608e77b835d51f05a54940380391cd4e21:

  RISC-V: Check clint_time_val before use (2020-09-30 11:05:14 -0700)


RISC-V Fixes for 5.9

I have two fixes for this week:

* The addition of a symbol export for clint_time_val, which has been inlined
  into some timex functions and can be used by drivers.
* A fix to avoid calling get_cycles() before the timers have been probed.

These both only effect !MMU systems.


Anup Patel (1):
  RISC-V: Check clint_time_val before use

Palmer Dabbelt (1):
  clocksource: clint: Export clint_time_val for modules

 arch/riscv/include/asm/stackprotector.h |  4 
 arch/riscv/include/asm/timex.h  | 13 +
 drivers/clocksource/timer-clint.c   |  1 +
 3 files changed, 14 insertions(+), 4 deletions(-)

Re: [PATCH] net: qrtr: ns: Fix the incorrect usage of rcu_read_lock()

[Manivannan Sadhasivam]

Hi Doug,

On Fri, Oct 02, 2020 at 08:28:51AM -0700, Doug Anderson wrote:
> Hi,
> 
> On Fri, Oct 2, 2020 at 7:15 AM Manivannan Sadhasivam
>  wrote:
> >
> > The rcu_read_lock() is not supposed to lock the kernel_sendmsg() API
> > since it has the lock_sock() in qrtr_sendmsg() which will sleep. Hence,
> > fix it by excluding the locking for kernel_sendmsg().
> >
> > Fixes: a7809ff90ce6 ("net: qrtr: ns: Protect radix_tree_deref_slot() using 
> > rcu read locks")
> > Reported-by: Doug Anderson 
> > Tested-by: Alex Elder 
> > Signed-off-by: Manivannan Sadhasivam 
> > ---
> >  net/qrtr/ns.c | 20 ++--
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/qrtr/ns.c b/net/qrtr/ns.c
> > index 934999b56d60..0515433de922 100644
> > --- a/net/qrtr/ns.c
> > +++ b/net/qrtr/ns.c
> > @@ -203,15 +203,17 @@ static int announce_servers(struct sockaddr_qrtr *sq)
> > /* Announce the list of servers registered in this node */
> > radix_tree_for_each_slot(slot, >servers, , 0) {
> > srv = radix_tree_deref_slot(slot);
> > +   rcu_read_unlock();
> 
> My RCU-fu is mediocre at best and my radix-tree knowledge is
> non-existent.  However:
> 
> => Reading through radix_tree_deref_slot() it says that if you are
> only holding the read lock that you need to be calling
> radix_tree_deref_retry().  Why don't I see that here?
> 

Well, I drew inspiration from peer drivers and didn't look into the API
documentation properly, my bad :(

> => Without any real knowledge, it seems super sketchy to drop the lock
> while iterating over the tree.  Somehow that feels unsafe.  Hrm, there
> seems to be a function radix_tree_iter_resume() that might be exactly
> what you want, but I'm not totally sure.  The only user I can see
> in-tree (other than radix tree regression testing) is btrfs-tests.c
> but it's using it together with radix_tree_deref_slot_protected().
> 
> In any case, my totally untested and totally knowedge-free proposal
> would look something like this:
> 
>   rcu_read_lock();
>   /* Announce the list of servers registered in this node */
>   radix_tree_for_each_slot(slot, >servers, , 0) {
> srv = radix_tree_deref_slot(slot);
> if (!srv)
>   continue;
> if (radix_tree_deref_retry(srv)) {
>   slot = radix_tree_iter_retry();
>   continue;
> }
> slot = radix_tree_iter_resume(slot, );
> rcu_read_unlock();
> 
> ret = service_announce_new(sq, srv);
> if (ret < 0) {
>   pr_err("failed to announce new service\n");
>   return ret;
> }
> 
> rcu_read_lock();
>   }
> 
>   rcu_read_unlock();
> 
> What a beast!  Given that this doesn't seem to be what anyone else in
> the kernel is doing exactly, it makes me suspect that there's a more
> fundamental design issue here, though...
> 

That's how it is supposed to be. So I'm going to roll out next revision with
your suggestion for the rest of the deref_slot() calls also.

Thanks for your time looking into this.

Regards,
Mani

> -Doug

Re: [RESEND PATCH] spmi: prefix spmi bus device names with "spmi"

[Mark Brown]

On Thu, Oct 01, 2020 at 05:45:00PM -0700, David Collins wrote:

> The SPMI regmap debugfs files are used extensively for testing and debug
> purposes internally at Qualcomm and by our customers.  It would be helpful
> if the more verbose naming scheme were accepted upstream to avoid
> confusion and broken test scripts.

...and doing this in the dev_name() should help other diagnostic users
(like dev_printk() for example).


signature.asc
Description: PGP signature

RE: [RFC PATCH 0/7] RAS/CEC: Extend CEC for errors count check on short time period

[Luck, Tony]

> Because from my x86 CPUs limited experience, the cache arrays are mostly
> fine and errors reported there are not something that happens very
> frequently so we don't even need to collect and count those.

On Intel X86 we leave the counting and threshold decisions about cache
health to the hardware. When a cache reaches the limit, it logs a "yellow"
status instead of "green" in the machine check bank (error is still marked
as "corrected"). The mcelog(8) daemon may attempt to take CPUs that share
that cache offline.

See Intel SDM volume 3B "15.4 Enhanced Cache Error Reporting"

-Tony

[PATCH 1/2] dt-bindings: sound: add DT bindings for Microchip S/PDIF RX Controller

[Codrin Ciubotariu]

This patch adds DT bindings for the new Microchip S/PDIF RX Controller
embedded inside sama7g5 SoCs.

Signed-off-by: Codrin Ciubotariu 
---
 .../bindings/sound/mchp,spdifrx.yaml  | 73 +++
 1 file changed, 73 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml

diff --git a/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml 
b/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml
new file mode 100644
index ..7d8bd4e14434
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mchp,spdifrx.yaml
@@ -0,0 +1,73 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mchp,spdifrx.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip S/PDIF Rx Controller Device Tree Bindings
+
+maintainers:
+  - Codrin Ciubotariu 
+
+description:
+The Microchip Sony/Philips Digital Interface Receiver is a
+serial port compliant with the IEC-60958 standard.
+
+properties:
+  "#sound-dai-cells":
+const: 0
+
+  compatible:
+const: microchip,sama7g5-spdifrx
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Peripheral Bus Clock
+  - description: Generic Clock
+
+  clock-names:
+items:
+  - const: pclk
+  - const: gclk
+
+  dmas:
+description: RX DMA Channel
+maxItems: 1
+
+  dma-names:
+const: rx
+
+required:
+  - "#sound-dai-cells"
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - dmas
+  - dma-names
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+spdifrx: spdifrx@e1614000 {
+#sound-dai-cells = <0>;
+compatible = "microchip,sama7g5-spdifrx";
+reg = <0xe1614000 0x4000>;
+interrupts = ;
+dmas = < AT91_XDMAC_DT_PERID(49)>;
+dma-names = "rx";
+clocks = < PMC_TYPE_PERIPHERAL 84>, < PMC_TYPE_GCK 84>;
+clock-names = "pclk", "gclk";
+};
-- 
2.25.1

Re: [PATCH] sched/deadline: Unthrottle PI boosted threads while enqueuing

[Peter Zijlstra]

On Fri, Oct 02, 2020 at 05:57:52PM +0200, Daniel Bristot de Oliveira wrote:
> On 9/18/20 8:00 AM, Juri Lelli wrote:
> > Hi Daniel,
> > 
> > On 16/09/20 09:06, Daniel Bristot de Oliveira wrote:
> >> stress-ng has a test (stress-ng --cyclic) that creates a set of threads
> >> under SCHED_DEADLINE with the following parameters:
> >>
> >> dl_runtime   =  1 (10 us)
> >> dl_deadline  = 10 (100 us)
> >> dl_period= 10 (100 us)
> >>
> >> These parameters are very aggressive. When using a system without HRTICK
> >> set, these threads can easily execute longer than the dl_runtime because
> >> the throttling happens with 1/HZ resolution.
> >>
> >> During the main part of the test, the system works just fine because
> >> the workload does not try to run over the 10 us. The problem happens at
> >> the end of the test, on the exit() path. During exit(), the threads need
> >> to do some cleanups that require real-time mutex locks, mainly those
> >> related to memory management, resulting in this scenario:
> >>
> >> Note: locks are rt_mutexes...
> >>  
> >> TASK A:TASK B: TASK C:
> >> activation
> >>activation
> >>activation
> >>
> >> lock(a): OK!   lock(b): OK!
> >>
> >>lock(a)
> >>-> block (task A owns it)
> >>  -> self notice/set throttled
> >>  +--<-> arm replenished timer
> >>  | switch-out
> >>  | lock(b)
> >>  | ->  B 
> >> prio>
> >>  | -> boost TASK B
> >>  |  unlock(a)  switch-out
> >>  |  -> handle lock a to B
> >>  |-> wakeup(B)
> >>  |  -> B is throttled:
> >>  |-> do not enqueue
> >>  | switch-out
> >>  |
> >>  |
> >>  +-> replenishment timer
> >>-> TASK B is boosted:
> >>  -> do not enqueue
> >>  
> >>
> >> BOOM: TASK B is runnable but !enqueued, holding TASK C: the system
> >> crashes with hung task C.
> >>
> >> This problem is avoided by removing the throttle state from the boosted
> >> thread while boosting it (by TASK A in the example above), allowing it to
> >> be queued and run boosted.
> >>
> >> The next replenishment will take care of the runtime overrun, pushing
> >> the deadline further away. See the "while (dl_se->runtime <= 0)" on
> >> replenish_dl_entity() for more information.
> >>
> >> Signed-off-by: Daniel Bristot de Oliveira 
> >> Reported-by: Mark Simmons 
> >> Reviewed-by: Juri Lelli 
> >> Tested-by: Mark Simmons 
> >> Cc: Ingo Molnar 
> >> Cc: Peter Zijlstra 
> >> Cc: Juri Lelli 
> >> Cc: Vincent Guittot 
> >> Cc: Dietmar Eggemann 
> >> Cc: Steven Rostedt 
> >> Cc: Ben Segall 
> >> Cc: Mel Gorman 
> >> Cc: Daniel Bristot de Oliveira 
> >> Cc: linux-kernel@vger.kernel.org
> >>
> >> ---
> > 
> > Thanks for this fix.
> > 
> > Acked-by: Juri Lelli 
> 
> This is a gentle ping... [we are facing this bug in practice :-(].

Sorry, queued now.

Re: [linux-sunxi] [PATCH v5 09/20] arm64: dts: allwinner: h6: Add DAI node and soundcard for HDMI

[Clément Péron]

Hi Chen-Yu,

On Mon, 28 Sep 2020 at 07:42, Chen-Yu Tsai  wrote:
>
> On Mon, Sep 28, 2020 at 1:32 PM Chen-Yu Tsai  wrote:
> >
> > On Mon, Sep 28, 2020 at 3:29 AM Clément Péron  wrote:
> > >
> > > From: Jernej Skrabec 
> > >
> > > Add the I2S node used by the HDMI and a simple-soundcard to
> > > link audio between HDMI and I2S.
> > >
> > > Note that the HDMI codec requires an inverted frame clock and
> > > a fixed I2S width. As there is no such option for I2S we use
> > > TDM property of the simple-soundcard to do that.
> > >
> > > Signed-off-by: Jernej Skrabec 
> > > Signed-off-by: Marcus Cooper 
> > > Signed-off-by: Clément Péron 
> > > ---
> > >  arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 33 
> > >  1 file changed, 33 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi 
> > > b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > index 28c77d6872f6..a8853ee7885a 100644
> > > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
> > > @@ -67,6 +67,25 @@ de: display-engine {
> > > status = "disabled";
> > > };
> > >
> > > +   hdmi_sound: hdmi-sound {
> > > +   compatible = "simple-audio-card";
> > > +   simple-audio-card,format = "i2s";
> > > +   simple-audio-card,name = "sun50i-h6-hdmi";
> > > +   simple-audio-card,mclk-fs = <128>;
> > > +   simple-audio-card,frame-inversion;
> > > +   status = "disabled";
> > > +
> > > +   simple-audio-card,codec {
> > > +   sound-dai = <>;
> > > +   };
> > > +
> > > +   simple-audio-card,cpu {
> > > +   sound-dai = <>;
> > > +   dai-tdm-slot-num = <2>;
> >
> > Doesn't this end up limiting the number of audio channels HDMI can carry?
> > AFAICT the TDM properties are all optional, so just leave it out.
> >
> > Same goes for the other two patches.
> >
> > > +   dai-tdm-slot-width = <32>;
> > > +   };
> > > +   };
> > > +
> > > osc24M: osc24M_clk {
> > > #clock-cells = <0>;
> > > compatible = "fixed-clock";
> > > @@ -609,6 +628,19 @@ mdio: mdio {
> > > };
> > > };
> > >
> > > +   i2s1: i2s@5091000 {
> > > +   #sound-dai-cells = <0>;
> > > +   compatible = "allwinner,sun50i-h6-i2s";
> > > +   reg = <0x05091000 0x1000>;
> > > +   interrupts = ;
> > > +   clocks = < CLK_BUS_I2S1>, < CLK_I2S1>;
> > > +   clock-names = "apb", "mod";
> > > +   dmas = < 4>, < 4>;
> > > +   resets = < RST_BUS_I2S1>;
> > > +   dma-names = "rx", "tx";
>
> Sorry, missed this one.
>
> Given that usage for this interface is transmit only, and there is no
> RX DRQ number assigned to it, you should drop the RX DMA number and name.

Indeed if there is no DRQ number assigned we shouldn't have it in the
device-tree

but Samuel told me that the `make dtbs_check` reports:

i2s@1c22800: dma-names:0: 'rx' was expected
i2s@1c22800: dma-names: ['tx'] is too short
i2s@1c22800: dmas: [[28, 27]] is too short

Should I fix the YAML so?

Regards,
Clement

>
> > > +   status = "disabled";
> > > +   };
> > > +
> > > spdif: spdif@5093000 {
> > > #sound-dai-cells = <0>;
> > > compatible = "allwinner,sun50i-h6-spdif";
> > > @@ -739,6 +771,7 @@ ohci3: usb@5311400 {
> > > };
> > >
> > > hdmi: hdmi@600 {
> > > +   #sound-dai-cells = <0>;
> > > compatible = "allwinner,sun50i-h6-dw-hdmi";
> > > reg = <0x0600 0x1>;
> > > reg-io-width = <1>;
> >
> > The rest of the patch looks OK.

Re: [RFC PATCH v3 4/4] objtool: fix x86 orc generation on big endian cross compiles

[Josh Poimboeuf]

On Thu, Oct 01, 2020 at 12:17:32AM +0200, Vasily Gorbik wrote:
> +++ b/tools/objtool/arch/x86/special.c
> @@ -9,7 +9,7 @@
>  
>  void arch_handle_alternative(unsigned short feature, struct special_alt *alt)
>  {
> - switch (feature) {
> + switch (le16_to_cpu(feature)) {

It might be cleaner for the endian conversion to be done when the
'feature' value is first read.

feature = *(unsigned short *)(sec->data->d_buf + offset +
  entry->feature);


>   case X86_FEATURE_SMAP:
>   /*
>* If UACCESS validation is enabled; force that alternative;
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 2df9f769412e..f20a4be2fb22 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -1370,7 +1370,7 @@ static int read_unwind_hints(struct objtool_file *file)
>   cfa = >cfi.cfa;
>  
>   if (hint->type == UNWIND_HINT_TYPE_RET_OFFSET) {
> - insn->ret_offset = hint->sp_offset;
> + insn->ret_offset = le16_to_cpu(hint->sp_offset);

Since this is common code, we might not always be able to assume the
value is little endian.  Could you make a more generic conversion macro
which -- when the target ELF file's endianness doesn't match the host
CPU's -- does a byte swap?  For example:

insn->ret_offset = bswap_if_needed(hint->sp_offset);

The macro could detect the type size, and would also know the
host/target endianness, and could swap accordingly.  It could then be
called for all such multi-byte reads.

-- 
Josh

Re: [PATCH v4 2/3] iommu/tegra-smmu: Rework tegra_smmu_probe_device()

[Dmitry Osipenko]

02.10.2020 18:23, Dmitry Osipenko пишет:
> 02.10.2020 09:08, Nicolin Chen пишет:
>> Then when a client gets probed, of_iommu_configure() in
>> iommu core will search DTB for swgroup ID and call ->of_xlate()
>> to prepare an fwspec, similar to tegra_smmu_probe_device() and
>> tegra_smmu_configure(). Then it'll call tegra_smmu_probe_device()
>> again, and this time we shall return smmu->iommu pointer properly.
> 
> I don't quite see where IOMMU core calls of_xlate().
> 
> Have tried to at least boot-test this patch?
> 

I don't see how it ever could work because of_xlate() is only invoked from:

fsl_mc_dma_configure()->of_dma_configure_id()->of_iommu_configure()

Looks like the tegra_smmu_configure() is still needed.

I don't know how sun50i driver could work to be honest. Seems IOMMU is
broken on sun50i, but maybe I'm missing something.

I added Maxime Ripard to this thread, who is the author of the
sun50i-iommu driver.

Re: [PATCH v13 19/26] mm: Re-introduce do_mmap_pgoff()

[Yu, Yu-cheng]

On 10/1/2020 7:06 PM, Peter Collingbourne wrote:

On Fri, Sep 25, 2020 at 7:57 AM Yu-cheng Yu  wrote:


There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:

 commit 45e55300f114 ("mm: remove unnecessary wrapper function 
do_mmap_pgoff()").

There is a new user now.  Shadow stack allocation passes VM_SHSTK to
do_mmap().  Re-introduce the vm_flags and do_mmap_pgoff().


I would prefer to change the callers to pass the additional 0 argument
instead of bringing the wrapper function back, but if we're going to
bring it back then we should fix the naming (both functions take a
pgoff argument, so the previous name do_mmap_pgoff() was just plain
confusing).

Peter



Thanks for your feedback.  Here is the updated patch.  I will re-send 
the whole series later.


Yu-cheng

==

From 6a9f1e6bcdb6e599a44d5f58cf4cebd28c4634a2 Mon Sep 17 00:00:00 2001
From: Yu-cheng Yu 
Date: Wed, 12 Aug 2020 14:01:58 -0700
Subject: [PATCH 19/26] mm: Re-introduce do_mmap_pgoff()

There was no more caller passing vm_flags to do_mmap(), and vm_flags was
removed from the function's input by:

commit 45e55300f114 ("mm: remove unnecessary wrapper function 
do_mmap_pgoff()").


There is a new user now.  Shadow stack allocation passes VM_SHSTK to
do_mmap().  Re-introduce vm_flags to do_mmap(), but without the old wrapper
do_mmap_pgoff().  Instead, fix all callers of the wrapper by passing a zero
vm_flags to do_mmap().

Signed-off-by: Yu-cheng Yu 
Cc: Peter Collingbourne 
Cc: Andrew Morton 
Cc: Oleg Nesterov 
Cc: linux...@kvack.org
---
 fs/aio.c   |  2 +-
 include/linux/mm.h |  3 ++-
 ipc/shm.c  |  2 +-
 mm/mmap.c  | 10 +-
 mm/nommu.c |  4 ++--
 mm/util.c  |  2 +-
 6 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/fs/aio.c b/fs/aio.c
index d5ec30385566..ca8c11665eea 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -527,7 +527,7 @@ static int aio_setup_ring(struct kioctx *ctx, 
unsigned int nr_events)


ctx->mmap_base = do_mmap(ctx->aio_ring_file, 0, ctx->mmap_size,
 PROT_READ | PROT_WRITE,
-MAP_SHARED, 0, , NULL);
+MAP_SHARED, 0, 0, , NULL);
mmap_write_unlock(mm);
if (IS_ERR((void *)ctx->mmap_base)) {
ctx->mmap_size = 0;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index e09d13699bbe..e020eea33138 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2560,7 +2560,8 @@ extern unsigned long mmap_region(struct file 
*file, unsigned long addr,

struct list_head *uf);
 extern unsigned long do_mmap(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot, unsigned long flags,
-   unsigned long pgoff, unsigned long *populate, struct list_head *uf);
+   vm_flags_t vm_flags, unsigned long pgoff, unsigned long *populate,
+   struct list_head *uf);
 extern int __do_munmap(struct mm_struct *, unsigned long, size_t,
   struct list_head *uf, bool downgrade);
 extern int do_munmap(struct mm_struct *, unsigned long, size_t,
diff --git a/ipc/shm.c b/ipc/shm.c
index e25c7c6106bc..91474258933d 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -1556,7 +1556,7 @@ long do_shmat(int shmid, char __user *shmaddr, int 
shmflg,

goto invalid;
}

-   addr = do_mmap(file, addr, size, prot, flags, 0, , NULL);
+   addr = do_mmap(file, addr, size, prot, flags, 0, 0, , NULL);
*raddr = addr;
err = 0;
if (IS_ERR_VALUE(addr))
diff --git a/mm/mmap.c b/mm/mmap.c
index 574b3f273462..fc04184d2eae 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1365,11 +1365,11 @@ static inline bool file_mmap_ok(struct file 
*file, struct inode *inode,

  */
 unsigned long do_mmap(struct file *file, unsigned long addr,
unsigned long len, unsigned long prot,
-   unsigned long flags, unsigned long pgoff,
-   unsigned long *populate, struct list_head *uf)
+   unsigned long flags, vm_flags_t vm_flags,
+   unsigned long pgoff, unsigned long *populate,
+   struct list_head *uf)
 {
struct mm_struct *mm = current->mm;
-   vm_flags_t vm_flags;
int pkey = 0;

*populate = 0;
@@ -1431,7 +1431,7 @@ unsigned long do_mmap(struct file *file, unsigned 
long addr,

 * to. we assume access permissions have been handled by the open
 * of the memory object, so we don't do any here.
 */
-   vm_flags = calc_vm_prot_bits(prot, pkey) | calc_vm_flag_bits(flags) |
+   vm_flags |= calc_vm_prot_bits(prot, pkey) | calc_vm_flag_bits(flags) |
mm->def_flags | VM_MAYREAD | VM_MAYWRITE | VM_MAYEXEC;

if (flags & MAP_LOCKED)
@@ -3007,7 +3007,7 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long, 
start, unsigned long, size,

[PATCH] MAINTAINERS: add dt binding headers to memory controller drivers entry

[Krzysztof Kozlowski]

Cover also the include/dt-bindings/memory/ headers in the memory
controller drivers entry.

Signed-off-by: Krzysztof Kozlowski 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 00214bbaa72c..6db9b677559b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11328,6 +11328,7 @@ S:  Maintained
 T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl.git
 F: Documentation/devicetree/bindings/memory-controllers/
 F: drivers/memory/
+F: include/dt-bindings/memory/
 
 MEMORY FREQUENCY SCALING DRIVERS FOR NVIDIA TEGRA
 M: Dmitry Osipenko 
-- 
2.17.1

Re: [PATCH] sched/deadline: Unthrottle PI boosted threads while enqueuing

[Daniel Bristot de Oliveira]

On 9/18/20 8:00 AM, Juri Lelli wrote:
> Hi Daniel,
> 
> On 16/09/20 09:06, Daniel Bristot de Oliveira wrote:
>> stress-ng has a test (stress-ng --cyclic) that creates a set of threads
>> under SCHED_DEADLINE with the following parameters:
>>
>> dl_runtime   =  1 (10 us)
>> dl_deadline  = 10 (100 us)
>> dl_period= 10 (100 us)
>>
>> These parameters are very aggressive. When using a system without HRTICK
>> set, these threads can easily execute longer than the dl_runtime because
>> the throttling happens with 1/HZ resolution.
>>
>> During the main part of the test, the system works just fine because
>> the workload does not try to run over the 10 us. The problem happens at
>> the end of the test, on the exit() path. During exit(), the threads need
>> to do some cleanups that require real-time mutex locks, mainly those
>> related to memory management, resulting in this scenario:
>>
>> Note: locks are rt_mutexes...
>>  
>> TASK A:  TASK B: TASK C:
>> activation
>>  activation
>>  activation
>>
>> lock(a): OK! lock(b): OK!
>>  
>>  lock(a)
>>  -> block (task A owns it)
>>-> self notice/set throttled
>>  +--<  -> arm replenished timer
>>  |   switch-out
>>  |   lock(b)
>>  |   ->  B 
>> prio>
>>  |   -> boost TASK B
>>  |  unlock(a)switch-out
>>  |  -> handle lock a to B
>>  |-> wakeup(B)
>>  |  -> B is throttled:
>>  |-> do not enqueue
>>  | switch-out
>>  |
>>  |
>>  +-> replenishment timer
>>  -> TASK B is boosted:
>>-> do not enqueue
>>  
>>
>> BOOM: TASK B is runnable but !enqueued, holding TASK C: the system
>> crashes with hung task C.
>>
>> This problem is avoided by removing the throttle state from the boosted
>> thread while boosting it (by TASK A in the example above), allowing it to
>> be queued and run boosted.
>>
>> The next replenishment will take care of the runtime overrun, pushing
>> the deadline further away. See the "while (dl_se->runtime <= 0)" on
>> replenish_dl_entity() for more information.
>>
>> Signed-off-by: Daniel Bristot de Oliveira 
>> Reported-by: Mark Simmons 
>> Reviewed-by: Juri Lelli 
>> Tested-by: Mark Simmons 
>> Cc: Ingo Molnar 
>> Cc: Peter Zijlstra 
>> Cc: Juri Lelli 
>> Cc: Vincent Guittot 
>> Cc: Dietmar Eggemann 
>> Cc: Steven Rostedt 
>> Cc: Ben Segall 
>> Cc: Mel Gorman 
>> Cc: Daniel Bristot de Oliveira 
>> Cc: linux-kernel@vger.kernel.org
>>
>> ---
> 
> Thanks for this fix.
> 
> Acked-by: Juri Lelli 

This is a gentle ping... [we are facing this bug in practice :-(].

-- Daniel

> Best,
> Juri
> 

Re: [PATCH v5 80/80] ARM: dts: bcm2711: Enable the display pipeline

[Dave Stevenson]

Hi Maxime

On Fri, 2 Oct 2020 at 16:19, Maxime Ripard  wrote:
>
> Hi Tim,
>
> On Thu, Oct 01, 2020 at 11:15:46AM +0100, Tim Gover wrote:
> > hdmi_enable_4k60=1 causes the firmware to select 3.3 GHz for the PLLC
> > VCO to support a core-frequency of 550 MHz which is the minimum
> > frequency required by the HVS at 4Kp60. The side effect is that if the
> > display clock requirements are lower than 4Kp60 then you will see
> > different core frequencies selected by DVFS.
> >
> > If enable_uart=1 and the mini-uart is selected (default unless
> > bluetooth is disabled) then the firmware will pin the core-frequency
> > to either core_freq max (500 or 550). Although, I think there is a way
> > of pinning it to a lower fixed frequency.
> >
> > The table in overclocking.md defines options for setting the maximum
> > core frequency but unless core_freq_min is specified DVFS will
> > automatically pick the lowest idle frequency required by the display
> > resolution.
>
> I'm wondering if there's some way to detect this from Linux? I guess it
> would be nice to be able to at least detect a broken config to warn /
> prevent an user that their situation is not going to be reliable / work
> really well (like if they have a 4k display without hdmi_enable_4kp60
> set, or the issue we're discussing here)

The main filter in the firmware is the parameter
hdmi_pixel_freq_limit. That can either be set manually from
config.txt, or defaults appropriately based on hdmi_enable_4kp60.
Under firmware_kms [1] I read back those values to use as a filter
within crtc_mode_valid[2].
I can't think of a nice way of exposing that without the vc4 driver
gaining a DT link to the firmware, and that starts to get ugly.

  Dave

[1] 
https://github.com/raspberrypi/linux/blob/rpi-5.9.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L1859
[2] 
https://github.com/raspberrypi/linux/blob/rpi-5.9.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L1077

Re: WARNING in get_signal

[Eric W. Biederman]

syzbot  writes:

> Hello,
>
> syzbot found the following issue on:

So this is:

static void do_jobctl_trap(void)
{
struct signal_struct *signal = current->signal;
int signr = current->jobctl & JOBCTL_STOP_SIGMASK;

if (current->ptrace & PT_SEIZED) {
if (!signal->group_stop_count &&
!(signal->flags & SIGNAL_STOP_STOPPED))
signr = SIGTRAP;
WARN_ON_ONCE(!signr);
^
ptrace_do_notify(signr, signr | (PTRACE_EVENT_STOP << 8),
 CLD_STOPPED);
} else {
WARN_ON_ONCE(!signr);
ptrace_stop(signr, CLD_STOPPED, 0, NULL);
current->exit_code = 0;
}
}

I have the state of this paged out of my head at the moment.

Oleg or Tejun do you remember what is supposed to keep signr from being
NULL?


It looks like this code was introduced in commit 73ddff2bee15 ("job
control: introduce JOBCTL_TRAP_STOP and use it for group stop trap").

Eric


> HEAD commit:fcadab74 Merge tag 'drm-fixes-2020-10-01-1' of git://anong..
> git tree:   upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=116865bd90
> kernel config:  https://syzkaller.appspot.com/x/.config?x=89ab6a0c48f30b49
> dashboard link: https://syzkaller.appspot.com/bug?extid=3485e3773f7da290eecc
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1211120b90
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16474c6790
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+3485e3773f7da290e...@syzkaller.appspotmail.com
>
> [ cut here ]
> WARNING: CPU: 1 PID: 6899 at kernel/signal.c:2431 do_jobctl_trap 
> kernel/signal.c:2431 [inline]
> WARNING: CPU: 1 PID: 6899 at kernel/signal.c:2431 get_signal+0x1b5c/0x1f00 
> kernel/signal.c:2621
> Kernel panic - not syncing: panic_on_warn set ...
> CPU: 1 PID: 6899 Comm: syz-executor116 Not tainted 5.9.0-rc7-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
> Google 01/01/2011
> Call Trace:
>  __dump_stack lib/dump_stack.c:77 [inline]
>  dump_stack+0x198/0x1fd lib/dump_stack.c:118
>  panic+0x382/0x7fb kernel/panic.c:231
>  __warn.cold+0x20/0x4b kernel/panic.c:600
>  report_bug+0x1bd/0x210 lib/bug.c:198
>  handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234
>  exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
>  asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
> RIP: 0010:do_jobctl_trap kernel/signal.c:2431 [inline]
> RIP: 0010:get_signal+0x1b5c/0x1f00 kernel/signal.c:2621
> Code: 00 48 c7 c2 40 da 8a 88 be d1 09 00 00 48 c7 c7 a0 da 8a 88 c6 05 09 8c 
> 09 0a 01 e8 43 97 11 00 e9 42 f5 ff ff e8 14 78 2b 00 <0f> 0b 41 bc 00 80 00 
> 00 e9 49 f9 ff ff 4c 89 ef e8 bf 4d 6c 00 e9
> RSP: 0018:c90005537ce8 EFLAGS: 00010093
> RAX:  RBX: 0001 RCX: 814abfc3
> RDX: 88809315c580 RSI: 814ac67c RDI: 0005
> RBP:  R08: 0001 R09: 88809315ca0f
> R10:  R11:  R12: 8000
> R13:  R14:  R15: dc00
>  arch_do_signal+0x82/0x2520 arch/x86/kernel/signal.c:811
>  exit_to_user_mode_loop kernel/entry/common.c:161 [inline]
>  exit_to_user_mode_prepare+0x1ae/0x200 kernel/entry/common.c:192
>  syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:267
>  ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:287
> RIP: 0033:0x446809
> Code: e8 5c b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
> 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 
> 83 8b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:7fbb8cdd1db8 EFLAGS: 0246 ORIG_RAX: 0038
> RAX:  RBX: 006dbc28 RCX: 00446809
> RDX:  RSI:  RDI: 0007a900
> RBP: 006dbc20 R08:  R09: 
> R10:  R11: 0246 R12: 006dbc2c
> R13: 7ffeca1e9fef R14: 7fbb8cdd29c0 R15: 20c49ba5e353f7cf
> Shutting down cpus with NMI
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this issue, for details see:
> https://goo.gl/tpsmEJ#testing-patches

[PATCH v3 7/7] usb: cdc-acm: add quirk to blacklist ETAS ES58X devices

[Vincent Mailhol]

The ES58X devices has a CDC ACM interface (used for debug
purpose). During probing, the device is thus recognized as USB Modem
(CDC ACM), preventing the etas-es58x module to load:
  usbcore: registered new interface driver etas_es58x
  usb 1-1.1: new full-speed USB device number 14 using xhci_hcd
  usb 1-1.1: New USB device found, idVendor=108c, idProduct=0159, bcdDevice= 
1.00
  usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
  usb 1-1.1: Product: ES581.4
  usb 1-1.1: Manufacturer: ETAS GmbH
  usb 1-1.1: SerialNumber: 2204355
  cdc_acm 1-1.1:1.0: No union descriptor, testing for castrated device
  cdc_acm 1-1.1:1.0: ttyACM0: USB ACM device

Thus, these have been added to the ignore list in
drivers/usb/class/cdc-acm.c

N.B. Future firmware release of the ES58X will remove the CDC-ACM
interface.

`lsusb -v` of the three devices variant (ES581.4, ES582.1 and
ES584.1):

  Bus 001 Device 011: ID 108c:0159 Robert Bosch GmbH ES581.4
  Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB   1.10
bDeviceClass2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor   0x108c Robert Bosch GmbH
idProduct  0x0159
bcdDevice1.00
iManufacturer   1 ETAS GmbH
iProduct2 ES581.4
iSerial 3 2204355
bNumConfigurations  1
Configuration Descriptor:
  bLength 9
  bDescriptorType 2
  wTotalLength   0x0035
  bNumInterfaces  1
  bConfigurationValue 1
  iConfiguration  5 Bus Powered Configuration
  bmAttributes 0x80
(Bus Powered)
  MaxPower  100mA
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting   0
bNumEndpoints   3
bInterfaceClass 2 Communications
bInterfaceSubClass  2 Abstract (modem)
bInterfaceProtocol  0
iInterface  4 ACM Control Interface
CDC Header:
  bcdCDC   1.10
CDC Call Management:
  bmCapabilities   0x01
call management
  bDataInterface  0
CDC ACM:
  bmCapabilities   0x06
sends break
line coding and serial state
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x81  EP 1 IN
  bmAttributes3
Transfer TypeInterrupt
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0010  1x 16 bytes
  bInterval  10
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x82  EP 2 IN
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0040  1x 64 bytes
  bInterval   0
Endpoint Descriptor:
  bLength 7
  bDescriptorType 5
  bEndpointAddress 0x03  EP 3 OUT
  bmAttributes2
Transfer TypeBulk
Synch Type   None
Usage Type   Data
  wMaxPacketSize 0x0040  1x 64 bytes
  bInterval   0
  Device Status: 0x
(Bus Powered)

  Bus 001 Device 012: ID 108c:0168 Robert Bosch GmbH ES582
  Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB   2.00
bDeviceClass2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor   0x108c Robert Bosch GmbH
idProduct  0x0168
bcdDevice1.00
iManufacturer   1 ETAS GmbH
iProduct2 ES582
iSerial 3 0108933
bNumConfigurations  1
Configuration Descriptor:
  bLength 9
  bDescriptorType 2
  wTotalLength   0x0043
  bNumInterfaces  2
  bConfigurationValue 1
  iConfiguration  0
  bmAttributes 0x80
(Bus Powered)
  MaxPower  500mA
  Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting   0
bNumEndpoints   1
bInterfaceClass 2 Communications
bInterfaceSubClass  2 Abstract (modem)
bInterfaceProtocol  1 AT-commands (v.25ter)
iInterface  0
CDC Header:

Re: [PATCH 3/3] task_work: use TIF_TASKWORK if available

[Jens Axboe]

On 10/2/20 9:14 AM, Oleg Nesterov wrote:
> Heh. To be honest I don't really like 1-2 ;)
> 
> Unfortunately, I do not see a better approach right now. Let me think
> until Monday, it is not that I think I will find a better solution, but
> I'd like to try anyway.
> 
> Let me comment 3/3 for now.

Thanks, appreciate your time on this!

>> +static void task_work_signal(struct task_struct *task)
>> +{
>> +#ifndef TIF_TASKWORK
>> +unsigned long flags;
>> +
>> +/*
>> + * Only grab the sighand lock if we don't already have some
>> + * task_work pending. This pairs with the smp_store_mb()
>> + * in get_signal(), see comment there.
>> + */
>> +if (!(READ_ONCE(task->jobctl) & JOBCTL_TASK_WORK) &&
>> +lock_task_sighand(task, )) {
>> +task->jobctl |= JOBCTL_TASK_WORK;
>> +signal_wake_up(task, 0);
>> +unlock_task_sighand(task, );
>> +}
>> +#else
>> +set_tsk_thread_flag(task, TIF_TASKWORK);
>> +set_notify_resume(task);
>> +#endif
> 
> Again, I can't understand. task_work_signal(task) should set TIF_TASKWORK
> to make signal_pending() = T _and_ wake/kick the target up, just like
> signal_wake_up() does. Why do we set TIF_NOTIFY_RESUME ?
> 
> So I think that if we are going to add TIF_TASKWORK we should generalize
> this logic and turn it into TIF_NOTIFY_SIGNAL. Similar to TIF_NOTIFY_RESUME
> but implies signal_pending().
> 
> IOW, something like
> 
>   void set_notify_signal(task)
>   {
>   if (!test_and_set_tsk_thread_flag(task, TIF_NOTIFY_SIGNAL)) {
>   if (!wake_up_state(task, TASK_INTERRUPTIBLE))
>   kick_process(t);
>   }
>   }
> 
>   // called by exit_to_user_mode_loop() if ti_work & _TIF_NOTIFY_SIGNAL
>   void tracehook_notify_signal(regs)
>   {
>   clear_thread_flag(TIF_NOTIFY_SIGNAL);
>   smp_mb__after_atomic();
>   if (unlikely(current->task_works))
>   task_work_run();
>   }
> 
> This way task_work_run() doesn't need to clear TIF_NOTIFY_SIGNAL and it can
> have more users.
> 
> What do you think?

I like that. It'll achieve the same thing as far as I'm concerned, but not
tie the functionality to task_work. Not that we have anything that'd use
it right now, but it still seems like a better base.

I'll adapt patch 2+3 for this, thanks Oleg.

-- 
Jens Axboe

Re: [PATCH 3/3] task_work: use TIF_TASKWORK if available

[Jens Axboe]

On 10/2/20 9:31 AM, Thomas Gleixner wrote:
> On Fri, Oct 02 2020 at 17:14, Oleg Nesterov wrote:
>> Heh. To be honest I don't really like 1-2 ;)
> 
> I do not like any of this :)
> 
>> So I think that if we are going to add TIF_TASKWORK we should generalize
>> this logic and turn it into TIF_NOTIFY_SIGNAL. Similar to TIF_NOTIFY_RESUME
>> but implies signal_pending().
>>
>> IOW, something like
>>
>>  void set_notify_signal(task)
>>  {
>>  if (!test_and_set_tsk_thread_flag(task, TIF_NOTIFY_SIGNAL)) {
>>  if (!wake_up_state(task, TASK_INTERRUPTIBLE))
>>  kick_process(t);
>>  }
>>  }
>>
>>  // called by exit_to_user_mode_loop() if ti_work & _TIF_NOTIFY_SIGNAL
>>  void tracehook_notify_signal(regs)
>>  {
>>  clear_thread_flag(TIF_NOTIFY_SIGNAL);
>>  smp_mb__after_atomic();
>>  if (unlikely(current->task_works))
>>  task_work_run();
>>  }
>>
>> This way task_work_run() doesn't need to clear TIF_NOTIFY_SIGNAL and it can
>> have more users.
> 
> I think it's fundamentaly wrong that we have several places and several
> flags which handle task_work_run() instead of having exactly one place
> and one flag.

I don't disagree with that. I know it's not happening in this series, but
if we to the TIF_NOTIFY_SIGNAL route and get all archs supporting that,
then we can kill the signal and notify resume part of running task_work.
And that leaves us with exactly one place that runs it.

So we can potentially improve the current situation in that regard.

-- 
Jens Axboe

[PATCH v3 5/7] can: dev: add a helper function to calculate the duration of one bit

[Vincent Mailhol]

Rename macro CAN_CALC_SYNC_SEG to CAN_SYNC_SEG and make it available
through include/linux/can/dev.h

Add an helper function can_bit_time() which returns the duration (in
time quanta) of one CAN bit.

Rationale for this patch: the sync segment and the bit time are two
concepts which are defined in the CAN ISO standard. Device drivers for
CAN might need those.

Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
additional information.

Signed-off-by: Vincent Mailhol 
---

Changes in v3: None

Changes in v2: None
---
 drivers/net/can/dev.c   | 13 ++---
 include/linux/can/dev.h | 15 +++
 2 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 8c3e11820e03..6070b4ab3bd8 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -60,7 +60,6 @@ EXPORT_SYMBOL_GPL(can_len2dlc);
 
 #ifdef CONFIG_CAN_CALC_BITTIMING
 #define CAN_CALC_MAX_ERROR 50 /* in one-tenth of a percent */
-#define CAN_CALC_SYNC_SEG 1
 
 /* Bit-timing calculation derived from:
  *
@@ -86,8 +85,8 @@ can_update_sample_point(const struct can_bittiming_const *btc,
int i;
 
for (i = 0; i <= 1; i++) {
-   tseg2 = tseg + CAN_CALC_SYNC_SEG -
-   (sample_point_nominal * (tseg + CAN_CALC_SYNC_SEG)) /
+   tseg2 = tseg + CAN_SYNC_SEG -
+   (sample_point_nominal * (tseg + CAN_SYNC_SEG)) /
1000 - i;
tseg2 = clamp(tseg2, btc->tseg2_min, btc->tseg2_max);
tseg1 = tseg - tseg2;
@@ -96,8 +95,8 @@ can_update_sample_point(const struct can_bittiming_const *btc,
tseg2 = tseg - tseg1;
}
 
-   sample_point = 1000 * (tseg + CAN_CALC_SYNC_SEG - tseg2) /
-   (tseg + CAN_CALC_SYNC_SEG);
+   sample_point = 1000 * (tseg + CAN_SYNC_SEG - tseg2) /
+   (tseg + CAN_SYNC_SEG);
sample_point_error = abs(sample_point_nominal - sample_point);
 
if (sample_point <= sample_point_nominal &&
@@ -145,7 +144,7 @@ static int can_calc_bittiming(struct net_device *dev, 
struct can_bittiming *bt,
/* tseg even = round down, odd = round up */
for (tseg = (btc->tseg1_max + btc->tseg2_max) * 2 + 1;
 tseg >= (btc->tseg1_min + btc->tseg2_min) * 2; tseg--) {
-   tsegall = CAN_CALC_SYNC_SEG + tseg / 2;
+   tsegall = CAN_SYNC_SEG + tseg / 2;
 
/* Compute all possible tseg choices (tseg=tseg1+tseg2) */
brp = priv->clock.freq / (tsegall * bt->bitrate) + tseg % 2;
@@ -223,7 +222,7 @@ static int can_calc_bittiming(struct net_device *dev, 
struct can_bittiming *bt,
 
/* real bitrate */
bt->bitrate = priv->clock.freq /
-   (bt->brp * (CAN_CALC_SYNC_SEG + tseg1 + tseg2));
+   (bt->brp * (CAN_SYNC_SEG + tseg1 + tseg2));
 
return 0;
 }
diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 791c452d98e1..77c3ea49b8fb 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -82,6 +82,21 @@ struct can_priv {
 #endif
 };
 
+#define CAN_SYNC_SEG 1
+
+/*
+ * can_bit_time() - Duration of one bit
+ *
+ * Please refer to ISO 11898-1:2015, section 11.3.1.1 "Bit time" for
+ * additional information.
+ *
+ * Return: the number of time quanta in one bit.
+ */
+static inline int can_bit_time(struct can_bittiming *bt)
+{
+   return CAN_SYNC_SEG + bt->prop_seg + bt->phase_seg1 + bt->phase_seg2;
+}
+
 /*
  * get_can_dlc(value) - helper macro to cast a given data length code (dlc)
  * to u8 and ensure the dlc value to be max. 8 bytes.
-- 
2.26.2

Re: [net-next PATCH v1 3/7] net: phy: Introduce fwnode_get_phy_id()

[Russell King - ARM Linux admin]

On Fri, Oct 02, 2020 at 08:14:07AM -0700, Florian Fainelli wrote:
> On 10/2/2020 4:05 AM, Grant Likely wrote:
> > On 30/09/2020 17:04, Calvin Johnson wrote:
> > > Extract phy_id from compatible string. This will be used by
> > > fwnode_mdiobus_register_phy() to create phy device using the
> > > phy_id.
> > > 
> > > Signed-off-by: Calvin Johnson 
> > > ---
> > > 
> > >   drivers/net/phy/phy_device.c | 32 +++-
> > >   include/linux/phy.h  |  5 +
> > >   2 files changed, 36 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> > > index c4aec56d0a95..162abde6223d 100644
> > > --- a/drivers/net/phy/phy_device.c
> > > +++ b/drivers/net/phy/phy_device.c
> > > @@ -9,6 +9,7 @@
> > >   #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -845,6 +846,27 @@ static int get_phy_c22_id(struct mii_bus *bus,
> > > int addr, u32 *phy_id)
> > >   return 0;
> > >   }
> > > +/* Extract the phy ID from the compatible string of the form
> > > + * ethernet-phy-id..
> > > + */
> > > +int fwnode_get_phy_id(struct fwnode_handle *fwnode, u32 *phy_id)
> > > +{
> > > +    unsigned int upper, lower;
> > > +    const char *cp;
> > > +    int ret;
> > > +
> > > +    ret = fwnode_property_read_string(fwnode, "compatible", );
> > > +    if (ret)
> > > +    return ret;
> > > +
> > > +    if (sscanf(cp, "ethernet-phy-id%4x.%4x", , ) == 2) {
> > > +    *phy_id = ((upper & 0x) << 16) | (lower & 0x);
> > > +    return 0;
> > > +    }
> > > +    return -EINVAL;
> > > +}
> > > +EXPORT_SYMBOL(fwnode_get_phy_id);
> > 
> > This block, and the changes in patch 4 duplicate functions from
> > drivers/of/of_mdio.c, but it doesn't refactor anything in
> > drivers/of/of_mdio.c to use the new path. Is your intent to bring all of
> > the parsing in these functions of "compatible" into the ACPI code path?
> > 
> > If so, then the existing code path needs to be refactored to work with
> > fwnode_handle instead of device_node.
> > 
> > If not, then the DT path in these functions should call out to of_mdio,
> > while the ACPI path only does what is necessary.
> 
> Rob has been asking before to have drivers/of/of_mdio.c be merged or at
> least relocated within drivers/net/phy where it would naturally belong. As a
> preliminary step towards ACPI support that would seem reasonable to do.

I think even I have commented on specific functions while reviewing
patches from NXP that the DT/ACPI code should use common bases...

I have been planning that if that doesn't get done, then I'd do it,
but really NXP should do it being the ones adding this infrastructure;
they should do the job properly and not take advantage of volunteers
in the community cleaning up their resulting submissions.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Re: [PATCH 1/1] blk-snap - Block snapshot module This module implements snapshot and changed block tracking functionality. It is intended to create backup copies of any block devices without usage of

[kernel test robot]

Hi Sergei,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.9-rc7]
[cannot apply to block/for-next sparc-next/master next-20201002]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Sergei-Shtepa/Block-snapshot-module-and-block-layer-filter-API/20201002-210406
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
472e5b056f000a778abb41f1e443de58eb259783
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://github.com/0day-ci/linux/commit/61a37e3bb74afbef1b725eaf80405e0e6e5d64b7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Sergei-Shtepa/Block-snapshot-module-and-block-layer-filter-API/20201002-210406
git checkout 61a37e3bb74afbef1b725eaf80405e0e6e5d64b7
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=m68k 

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

All warnings (new ones prefixed by >>):

   In file included from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/mutex.h:15,
from drivers/block/blk-snap/common.h:11,
from drivers/block/blk-snap/blk_deferred.c:3:
   include/linux/scatterlist.h: In function 'sg_set_buf':
   arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of 
pointer with null pointer [-Wextra]
 169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void 
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
 | ^~
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
  78 | # define unlikely(x) __builtin_expect(!!(x), 0)
 |  ^
   include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
 143 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~
   include/linux/scatterlist.h:143:10: note: in expansion of macro 
'virt_addr_valid'
 143 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~~
   drivers/block/blk-snap/blk_deferred.c: At top level:
>> drivers/block/blk-snap/blk_deferred.c:140:13: warning: no previous prototype 
>> for '_blk_deferred_bio_alloc' [-Wmissing-prototypes]
 140 | struct bio *_blk_deferred_bio_alloc(int nr_iovecs)
 | ^~~
>> drivers/block/blk-snap/blk_deferred.c:198:10: warning: no previous prototype 
>> for '_blk_deferred_submit_pages' [-Wmissing-prototypes]
 198 | sector_t _blk_deferred_submit_pages(struct block_device *blk_dev,
 |  ^~
--
   In file included from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/mutex.h:15,
from drivers/block/blk-snap/common.h:11,
from drivers/block/blk-snap/blk_descr_file.c:3:
   include/linux/scatterlist.h: In function 'sg_set_buf':
   arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of 
pointer with null pointer [-Wextra]
 169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void 
*)PAGE_OFFSET && (void *)(kaddr) < high_memory)
 | ^~
   include/linux/compiler.h:78:42: note: in definition of macro 'unlikely'
  78 | # define unlikely(x) __builtin_expect(!!(x), 0)
 |  ^
   include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON'
 143 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~
   include/linux/scatterlist.h:143:10: note: in expansion of macro 
'virt_addr_valid'
 143 |  BUG_ON(!virt_addr_valid(buf));
 |  ^~~
   drivers/block/blk-snap/blk_descr_file.c: At top level:
>> drivers/block/blk-snap/blk_descr_file.c:39:6: warning: no previous prototype 
>> for '_blk_descr_file_cleanup' [-Wmissing-prototypes]
  39 | void _blk_descr_file_cleanup(void *descr_array, size_t count)
 |  ^~~
--
   In file included from include/linux/kernel.h:11,
from include/linux/list.h:9,
from include/linux/mutex.h:15,
from drivers/block/blk-snap/common.h:11,
from drivers/block/blk-snap/blk_descr_mem.c:3:
   include/l

[PATCH v3 4/7] can: dev: __can_get_echo_skb(): fix the return length

[Vincent Mailhol]

The length of Remote Transmission Request (RTR) frames is always 0
bytes. The DLC represents the requested length, not the actual length
of the RTR. But __can_get_echo_skb() returns the DLC value regardless.

Apply get_can_len() function to retrieve the correct length.

Signed-off-by: Vincent Mailhol 
---

Changes in v3: None

Changes in v2: None
---
 drivers/net/can/dev.c | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index e291fda395a0..8c3e11820e03 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -481,14 +481,9 @@ __can_get_echo_skb(struct net_device *dev, unsigned int 
idx, u8 *len_ptr)
}
 
if (priv->echo_skb[idx]) {
-   /* Using "struct canfd_frame::len" for the frame
-* length is supported on both CAN and CANFD frames.
-*/
struct sk_buff *skb = priv->echo_skb[idx];
-   struct canfd_frame *cf = (struct canfd_frame *)skb->data;
-   u8 len = cf->len;
 
-   *len_ptr = len;
+   *len_ptr = get_can_len(skb);
priv->echo_skb[idx] = NULL;
 
return skb;
-- 
2.26.2

INFO: task hung in lock_sock_nested (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:87d5034d Merge tag 'mlx5-updates-2020-09-30' of git://git...
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1377fb3790
kernel config:  https://syzkaller.appspot.com/x/.config?x=7b5cc8ec2218e99d
dashboard link: https://syzkaller.appspot.com/bug?extid=fcf8ca5817d6e92c6567
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1456626790
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=14458a4d90

The issue was bisected to:

commit ab174ad8ef76276cadfdae98731d31797d265927
Author: Paolo Abeni 
Date:   Mon Sep 14 08:01:12 2020 +

mptcp: move ooo skbs into msk out of order queue.

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=124d00b390
final oops: https://syzkaller.appspot.com/x/report.txt?x=114d00b390
console output: https://syzkaller.appspot.com/x/log.txt?x=164d00b390

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+fcf8ca5817d6e92c6...@syzkaller.appspotmail.com
Fixes: ab174ad8ef76 ("mptcp: move ooo skbs into msk out of order queue.")

INFO: task syz-executor924:8165 blocked for more than 143 seconds.
  Not tainted 5.9.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor924 state:D stack:28120 pid: 8165 ppid:  6877 flags:0x4004
Call Trace:
 context_switch kernel/sched/core.c:3778 [inline]
 __schedule+0xec9/0x2280 kernel/sched/core.c:4527
 schedule+0xd0/0x2a0 kernel/sched/core.c:4602
 __lock_sock+0x13d/0x260 net/core/sock.c:2504
 lock_sock_nested+0xf1/0x110 net/core/sock.c:3043
 lock_sock include/net/sock.h:1581 [inline]
 sk_stream_wait_memory+0x775/0xe60 net/core/stream.c:145
 mptcp_sendmsg+0x53b/0x1910 net/mptcp/protocol.c:1196
 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:817
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:671
 __sys_sendto+0x21c/0x320 net/socket.c:1992
 __do_sys_sendto net/socket.c:2004 [inline]
 __se_sys_sendto net/socket.c:2000 [inline]
 __x64_sys_sendto+0xdd/0x1b0 net/socket.c:2000
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x44a519
Code: Bad RIP value.
RSP: 002b:7fbbeac93cd8 EFLAGS: 0246 ORIG_RAX: 002c
RAX: ffda RBX: 006dfc48 RCX: 0044a519
RDX: ffe7 RSI: 2100 RDI: 0003
RBP: 006dfc40 R08:  R09: 
R10: c000 R11: 0246 R12: 006dfc4c
R13: 7ffe07568e9f R14: 7fbbeac949c0 R15: 0064
INFO: task syz-executor924:8922 blocked for more than 144 seconds.
  Not tainted 5.9.0-rc6-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor924 state:D stack:28112 pid: 8922 ppid:  6876 flags:0x0004
Call Trace:
 context_switch kernel/sched/core.c:3778 [inline]
 __schedule+0xec9/0x2280 kernel/sched/core.c:4527
 schedule+0xd0/0x2a0 kernel/sched/core.c:4602
 __lock_sock+0x13d/0x260 net/core/sock.c:2504
 lock_sock_nested+0xf1/0x110 net/core/sock.c:3043
 lock_sock include/net/sock.h:1581 [inline]
 mptcp_close+0x8d/0xc60 net/mptcp/protocol.c:1914
 inet_release+0x12e/0x280 net/ipv4/af_inet.c:431
 __sock_release+0xcd/0x280 net/socket.c:596
 sock_close+0x18/0x20 net/socket.c:1277
 __fput+0x285/0x920 fs/file_table.c:281
 task_work_run+0xdd/0x190 kernel/task_work.c:141
 tracehook_notify_resume include/linux/tracehook.h:188 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:165 [inline]
 exit_to_user_mode_prepare+0x1e1/0x200 kernel/entry/common.c:192
 syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:267
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x408ec1
Code: Bad RIP value.
RSP: 002b:7ffe07568f10 EFLAGS: 0293 ORIG_RAX: 0003
RAX:  RBX: 0004 RCX: 00408ec1
RDX:  RSI:  RDI: 0003
RBP: 0007b8fc R08: 0001bb1414ac R09: 0001bb1414ac
R10: 7ffe07568f30 R11: 0293 R12: 006dfc50
R13: 0008 R14: 006dfc5c R15: 0064

Showing all locks held in the system:
3 locks held by kworker/1:0/17:
2 locks held by kworker/u4:4/155:
1 lock held by khungtaskd/1166:
 #0: 8a068400 (rcu_read_lock){}-{1:2}, at: 
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:5852
1 lock held by khugepaged/1181:
 #0: 8a133fc8 (lock#5){+.+.}-{3:3}, at: lru_add_drain_all+0x59/0x6c0 
mm/swap.c:780
1 lock held by in:imklog/6560:
 #0: 88809d19bbb0 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 
fs/file.c:930
3 locks held by kworker/0:2/8106:
1 lock held by syz-executor924/8922:
 #0: 888085719c90 (>s_type->i_mutex_key#13){+.+.}-{3:3}, at: inode_lock 
include/linux/fs.h:779 [inline]
 #0: 888085719c90 

[PATCH][next] perf: arm-cmn: fix less than zero check on unsigned dtc->irq

[Colin King]

From: Colin Ian King 

Currently the failure check on dtc->irq is always false because
dtc->irq is an unsigned int. Fix this by using a temporary signed
int for the less than zero error check.

Addresses-Coverity: ("Unsigned compared against 0")
Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")
Signed-off-by: Colin Ian King 
---
 drivers/perf/arm-cmn.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/perf/arm-cmn.c b/drivers/perf/arm-cmn.c
index a76ff594f3ca..21819af163f3 100644
--- a/drivers/perf/arm-cmn.c
+++ b/drivers/perf/arm-cmn.c
@@ -1246,11 +1246,13 @@ static int arm_cmn_init_dtc(struct arm_cmn *cmn, struct 
arm_cmn_node *dn, int id
 {
struct arm_cmn_dtc *dtc = cmn->dtc + idx;
struct arm_cmn_node *xp;
+   int irq;
 
dtc->base = dn->pmu_base - CMN_PMU_OFFSET;
-   dtc->irq = platform_get_irq(to_platform_device(cmn->dev), idx);
-   if (dtc->irq < 0)
-   return dtc->irq;
+   irq = platform_get_irq(to_platform_device(cmn->dev), idx);
+   if (irq < 0)
+   return irq;
+   dtc->irq = irq;
 
writel_relaxed(0, dtc->base + CMN_DT_PMCR);
writel_relaxed(0x1ff, dtc->base + CMN_DT_PMOVSR_CLR);
-- 
2.27.0

WARNING in get_signal

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:fcadab74 Merge tag 'drm-fixes-2020-10-01-1' of git://anong..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=116865bd90
kernel config:  https://syzkaller.appspot.com/x/.config?x=89ab6a0c48f30b49
dashboard link: https://syzkaller.appspot.com/bug?extid=3485e3773f7da290eecc
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1211120b90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=16474c6790

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

[ cut here ]
WARNING: CPU: 1 PID: 6899 at kernel/signal.c:2431 do_jobctl_trap 
kernel/signal.c:2431 [inline]
WARNING: CPU: 1 PID: 6899 at kernel/signal.c:2431 get_signal+0x1b5c/0x1f00 
kernel/signal.c:2621
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 6899 Comm: syz-executor116 Not tainted 5.9.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x198/0x1fd lib/dump_stack.c:118
 panic+0x382/0x7fb kernel/panic.c:231
 __warn.cold+0x20/0x4b kernel/panic.c:600
 report_bug+0x1bd/0x210 lib/bug.c:198
 handle_bug+0x38/0x90 arch/x86/kernel/traps.c:234
 exc_invalid_op+0x14/0x40 arch/x86/kernel/traps.c:254
 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
RIP: 0010:do_jobctl_trap kernel/signal.c:2431 [inline]
RIP: 0010:get_signal+0x1b5c/0x1f00 kernel/signal.c:2621
Code: 00 48 c7 c2 40 da 8a 88 be d1 09 00 00 48 c7 c7 a0 da 8a 88 c6 05 09 8c 
09 0a 01 e8 43 97 11 00 e9 42 f5 ff ff e8 14 78 2b 00 <0f> 0b 41 bc 00 80 00 00 
e9 49 f9 ff ff 4c 89 ef e8 bf 4d 6c 00 e9
RSP: 0018:c90005537ce8 EFLAGS: 00010093
RAX:  RBX: 0001 RCX: 814abfc3
RDX: 88809315c580 RSI: 814ac67c RDI: 0005
RBP:  R08: 0001 R09: 88809315ca0f
R10:  R11:  R12: 8000
R13:  R14:  R15: dc00
 arch_do_signal+0x82/0x2520 arch/x86/kernel/signal.c:811
 exit_to_user_mode_loop kernel/entry/common.c:161 [inline]
 exit_to_user_mode_prepare+0x1ae/0x200 kernel/entry/common.c:192
 syscall_exit_to_user_mode+0x7e/0x2e0 kernel/entry/common.c:267
 ret_from_fork+0x15/0x30 arch/x86/entry/entry_64.S:287
RIP: 0033:0x446809
Code: e8 5c b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
8b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7fbb8cdd1db8 EFLAGS: 0246 ORIG_RAX: 0038
RAX:  RBX: 006dbc28 RCX: 00446809
RDX:  RSI:  RDI: 0007a900
RBP: 006dbc20 R08:  R09: 
R10:  R11: 0246 R12: 006dbc2c
R13: 7ffeca1e9fef R14: 7fbb8cdd29c0 R15: 20c49ba5e353f7cf
Shutting down cpus with NMI
Kernel Offset: disabled
Rebooting in 86400 seconds..


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

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

[PATCH v3 3/7] can: dev: add a helper function to get the correct length of Classical frames

[Vincent Mailhol]

In classical CAN, the length of the data (i.e. CAN payload) is not
always equal to the DLC! If the frame is a Remote Transmission Request
(RTR), data length is always zero regardless of DLC value and else, if
the DLC is greater than 8, the length is 8. Contrary to common belief,
ISO 11898-1 Chapter 8.4.2.3 (DLC field) do allow DLCs greater than 8
for Classical Frames and specifies that those DLCs shall indicate that
the data field is 8 bytes long.

Above facts are widely unknown and so many developpers uses the "len"
field of "struct canfd_frame" to get the length of classical CAN
frames: this is incorrect!

This patch introduces function get_can_len() which can be used in
remediation. The function takes the SKB as an input in order to be
able to determine if the frame is classical or FD.

Signed-off-by: Vincent Mailhol 
---

Changes in v3:
  - Make get_can_len() return u8.
  - Make the skb const.

Changes in v2: None
---
 include/linux/can/dev.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 132b4133f9d0..791c452d98e1 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -177,6 +177,29 @@ u8 can_dlc2len(u8 can_dlc);
 /* map the sanitized data length to an appropriate data length code */
 u8 can_len2dlc(u8 len);
 
+/*
+ * get_can_len(skb) - get the length of the CAN payload.
+ *
+ * In classical CAN, the length of the data (i.e. CAN payload) is not
+ * always equal to the DLC! If the frame is a Remote Transmission
+ * Request (RTR), data length is always zero regardless of DLC value
+ * and else, if the DLC is greater than 8, the length is 8. Contrary
+ * to common belief, ISO 11898-1 Chapter 8.4.2.3 (DLC field) do allow
+ * DLCs greater than 8 for Classical Frames and specifies that those
+ * DLCs shall indicate that the data field is 8 bytes long.
+ */
+static inline u8 get_can_len(const struct sk_buff *skb)
+{
+   const struct canfd_frame *cf = (const struct canfd_frame *)skb->data;
+
+   if (can_is_canfd_skb(skb))
+   return min_t(u8, cf->len, CANFD_MAX_DLEN);
+   else if (cf->can_id & CAN_RTR_FLAG)
+   return 0;
+   else
+   return min_t(u8, cf->len, CAN_MAX_DLEN);
+}
+
 struct net_device *alloc_candev_mqs(int sizeof_priv, unsigned int echo_skb_max,
unsigned int txqs, unsigned int rxqs);
 #define alloc_candev(sizeof_priv, echo_skb_max) \
-- 
2.26.2

Re: [PATCH v2 3/3] dt-bindings: thermal: update sustainable-power with abstract scale

[Doug Anderson]

Hi,

On Fri, Oct 2, 2020 at 8:13 AM Lukasz Luba  wrote:
>
> Hi Doug,
>
> On 10/2/20 3:31 PM, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Oct 2, 2020 at 4:45 AM Lukasz Luba  wrote:
> >>
> >> Update the documentation for the binding 'sustainable-power' and allow
> >> to provide values in an abstract scale. It is required when the cooling
> >> devices use an abstract scale for their power values.
> >>
> >> Signed-off-by: Lukasz Luba 
> >> ---
> >>   .../devicetree/bindings/thermal/thermal-zones.yaml  | 13 +
> >>   1 file changed, 9 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml 
> >> b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> >> index 3ec9cc87ec50..4d8f2e37d1e6 100644
> >> --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> >> +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml
> >> @@ -99,10 +99,15 @@ patternProperties:
> >> sustainable-power:
> >>   $ref: /schemas/types.yaml#/definitions/uint32
> >>   description:
> >> -  An estimate of the sustainable power (in mW) that this thermal 
> >> zone
> >> -  can dissipate at the desired control temperature. For 
> >> reference, the
> >> -  sustainable power of a 4-inch phone is typically 2000mW, while 
> >> on a
> >> -  10-inch tablet is around 4500mW.
> >> +  An estimate of the sustainable power (in mW or in an abstract 
> >> scale)
> >> + that this thermal zone can dissipate at the desired control
> >> + temperature. For reference, the sustainable power of a 4-inch 
> >> phone
> >> + is typically 2000mW, while on a 10-inch tablet is around 4500mW.
> >> +
> >> + It is possible to express the sustainable power in an abstract
> >> + scale. This is the case when the related cooling devices use also
> >> + abstract scale to express their power usage. The scale must be
> >> + consistent.
> >
> > Two thoughts:
> >
> > 1. If we're going to allow "sustainable-power" to be in abstract
> > scale, why not allow "dynamic-power-coefficient" to be in abstract
> > scale too?  I assume that the whole reason against that originally was
> > the idea of device tree purity, but if we're allowing the abstract
> > scale here then there seems no reason not to allow it for
> > "dynamic-power-coefficient".
>
> With this binding it's a bit more tricky.
> I also have to discuss a few things internally. This requirement of
> uW/MHz/V^2 makes the code easier also for potential drivers
> like GPU (which are going to register the devfreq cooling with EM).
>
> Let me think about it, but for now I would just update these bits.
> These are required to proper IPA operation, the dyn.-pow.-coef. is a
> nice to have and possible next step.

I guess the problem is that Rajendra is currently planning to remove
all the "dynamic-power-coefficient" values from device tree right now
and move them to the source code because the numbers we currently have
in the device tree _are_ in abstract scale and thus violate the
bindings.  Moving this to source code won't help us get to more real
power numbers (since it'll still be abstract scale), it'll just be
pure churn.  If we're OK with the abstract scale in general then we
should allow it everywhere and not add churn for no reason.


> > 2. Is it worth adding some type of indication of what type of units
> > "sustainable-power" is represented in?  Maybe even a made up unit so
> > that you could tell the difference between made up units in the same
> > system?  I'd envision something like:
> >
> > sustainable-power-units = "qualcomm,sc7180-bogoWatts"
> >
> > ...and on the dynamic-power-coefficient side, the same:
> >
> > dynamic-power-coefficient-units = "qualcomm,sc7180-bogoWatts"
> >
> > One could imagine someone even later (after devices are widely
> > distributed) figuring out translations between these bogoWatts numbers
> > and real Watts if someone could come up with a case where it matters.
>
> To figure this out we don't need a new binding.
> I think a simple comment in the DT would be enough for this, even e.g.:
>
> sustainable-power = <100> /* bogoWatts */

There are some important differences:

a) Your comment is gone when the device tree is compiled.  If we
actually add a string to the device tree then, in theory, we can add
conversions in code (without touching the device tree) down the road.

b) I believe there can be more than one abstract scale present in a
single device tree, at least in theory.  Adding a string allows you to
know if you're comparing apples to apples or apples to organges.


> Thank you for your comments.
> BTW, I haven't put your 'Reviewed-by' because I have added this
> sustainable-power new stuff in patch 1/3. I will grateful if you
> have a look on that.

I can if needed, but I'd kinda like to get the above resolved first
since it feels like it could have an effect on the 

[PATCH v3 2/7] can: dev: fix type of get_can_dlc() and get_canfd_dlc() macros

[Vincent Mailhol]

The macros get_can_dlc() and get_canfd_dlc() are not visible in
userland. As such, type u8 should be preferred over type __u8.

Reference: https://lkml.org/lkml/2020/10/1/708
Signed-off-by: Vincent Mailhol 
---
 include/linux/can/dev.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/can/dev.h b/include/linux/can/dev.h
index 5e3d45525bd3..132b4133f9d0 100644
--- a/include/linux/can/dev.h
+++ b/include/linux/can/dev.h
@@ -84,13 +84,13 @@ struct can_priv {
 
 /*
  * get_can_dlc(value) - helper macro to cast a given data length code (dlc)
- * to __u8 and ensure the dlc value to be max. 8 bytes.
+ * to u8 and ensure the dlc value to be max. 8 bytes.
  *
  * To be used in the CAN netdriver receive path to ensure conformance with
  * ISO 11898-1 Chapter 8.4.2.3 (DLC field)
  */
-#define get_can_dlc(i) (min_t(__u8, (i), CAN_MAX_DLC))
-#define get_canfd_dlc(i)   (min_t(__u8, (i), CANFD_MAX_DLC))
+#define get_can_dlc(i) (min_t(u8, (i), CAN_MAX_DLC))
+#define get_canfd_dlc(i)   (min_t(u8, (i), CANFD_MAX_DLC))
 
 /* Check for outgoing skbs that have not been created by the CAN subsystem */
 static inline bool can_skb_headroom_valid(struct net_device *dev,
-- 
2.26.2

[PATCH v3 1/7] can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context

[Vincent Mailhol]

If a driver calls can_get_echo_skb() during a hardware IRQ (which is
often, but not always, the case), the 'WARN_ON(in_irq)' in
net/core/skbuff.c#skb_release_head_state() might be triggered, under
network congestion circumstances, together with the potential risk of
a NULL pointer dereference.

The root cause of this issue is the call to kfree_skb() instead of
dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().

This patch prevents the skb to be freed within the call to netif_rx()
by incrementing its reference count with skb_get(). The skb is finally
freed by one of the in-irq-context safe functions:
dev_consume_skb_any() or dev_kfree_skb_any().  The "any" version is
used because some drivers might call can_get_echo_skb() in a normal
context.

The reason for this issue to occur is that initially, in the core
network stack, loopback skb were not supposed to be received in
hardware IRQ context. The CAN stack is an exeption.

This bug was previously reported back in 2017 in [1] but the proposed
patch never got accepted.

While [1] directly modifies net/core/dev.c, we try to propose here a
smoother modification local to CAN network stack (the assumption
behind is that only CAN devices are affected by this issue).

[1] https://patchwork.ozlabs.org/patch/835236/

Signed-off-by: Vincent Mailhol 
---

Changes in v3: None

Changes in v2:
 - Minor changes of link format in the changelog.
---
 drivers/net/can/dev.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c
index 68834a2853c9..e291fda395a0 100644
--- a/drivers/net/can/dev.c
+++ b/drivers/net/can/dev.c
@@ -512,7 +512,11 @@ unsigned int can_get_echo_skb(struct net_device *dev, 
unsigned int idx)
if (!skb)
return 0;
 
-   netif_rx(skb);
+   skb_get(skb);
+   if (netif_rx(skb) == NET_RX_SUCCESS)
+   dev_consume_skb_any(skb);
+   else
+   dev_kfree_skb_any(skb);
 
return len;
 }
-- 
2.26.2

[PATCH] x86/kvm: Update the comment about asynchronous page fault in exc_page_fault()

[Vitaly Kuznetsov]

KVM was switched to interrupt-based mechanism for 'page ready' event
delivery in Linux-5.8 (see commit 2635b5c4a0e4 ("KVM: x86: interrupt based
APF 'page ready' event delivery")) and #PF (ab)use for 'page ready' event
delivery was removed. Linux guest switched to this new mechanism
exclusively in 5.9 (see commit b1d405751cd5 ("KVM: x86: Switch KVM guest to
using interrupts for page ready APF delivery")) so it is not possible to
get older KVM (APF mechanism won't be enabled). Update the comment in
exc_page_fault() to reflect the new reality.

Signed-off-by: Vitaly Kuznetsov 
---
 arch/x86/mm/fault.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 6e3e8a124903..3cf77592ac54 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1446,11 +1446,14 @@ DEFINE_IDTENTRY_RAW_ERRORCODE(exc_page_fault)
prefetchw(>mm->mmap_lock);
 
/*
-* KVM has two types of events that are, logically, interrupts, but
-* are unfortunately delivered using the #PF vector.  These events are
-* "you just accessed valid memory, but the host doesn't have it right
-* now, so I'll put you to sleep if you continue" and "that memory
-* you tried to access earlier is available now."
+* KVM uses #PF vector to deliver 'page not present' events to guests
+* (asynchronous page fault mechanism). The event happens when a
+* userspace task is trying to access some valid (from guest's point of
+* view) memory which is not currently mapped by the host (e.g. the
+* memory is swapped out). Note, the corresponding "page ready" event
+* which is injected when the memory becomes available, is delived via
+* an interrupt mechanism and not a #PF exception
+* (see arch/x86/kernel/kvm.c: sysvec_kvm_asyncpf_interrupt()).
 *
 * We are relying on the interrupted context being sane (valid RSP,
 * relevant locks not held, etc.), which is fine as long as the
-- 
2.25.4

[PATCH v3 0/7] can: add support for ETAS ES58X CAN USB

[Vincent Mailhol]

The purpose of this patch series is to introduce a new CAN USB
driver to support ETAS USB interfaces (ES58X series).

During development, issues in drivers/net/can/dev.c where discovered,
the fix for those issues are included in this patch series.

We also propose to add two helper functions in include/linux/can/dev.h
which we think can benefit other drivers: get_can_len() and
can_bit_time().

The driver indirectly relies on https://lkml.org/lkml/2020/9/26/251
([PATCH] can: raw: add missing error queue support) for the call to
skb_tx_timestamp() to work but can still compile without it.

*Side notes*: scripts/checkpatch.pl returns 4 'checks' findings in
[PATCH 5/6]. All those findings are of type: "Macro argument reuse 'x'
possible side-effects?".  Those arguments reuse are actually made by
calling either __stringify() or sizeof_field() which are both
pre-processor constant. Furthermore, those macro are never called with
arguments sensible to side-effects. So no actual side effect would
occur.

Changes in v3:
  - Added one additional patch: [PATCH v3 2/7] can: dev: fix type of
 get_can_dlc() and get_canfd_dlc() macros.
  - Make get_can_len() return u8 and make the skb const in PATCH 3/7.
  - Remove all the calls to likely() and unlikely() in PATCH 6/7.

Changes in v2:
  - Fixed -W1 warnings in PATCH 6/7 (v1 was tested with GCC -WExtra
  but not with -W1).
  - Added lsusb -v information in PATCH 7/7 and rephrased the comment.
  - Take care to put everyone in CC of each of the patch of the series
  (sorry for the mess in v1...)

Vincent Mailhol (7):
  can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ
context
  can: dev: fix type of get_can_dlc() and get_canfd_dlc() macros
  can: dev: add a helper function to get the correct length of Classical
frames
  can: dev: __can_get_echo_skb(): fix the return length
  can: dev: add a helper function to calculate the duration of one bit
  can: usb: etas_es58X: add support for ETAS ES58X CAN USB interfaces
  usb: cdc-acm: add quirk to blacklist ETAS ES58X devices

 drivers/net/can/dev.c   |   26 +-
 drivers/net/can/usb/Kconfig |9 +
 drivers/net/can/usb/Makefile|1 +
 drivers/net/can/usb/etas_es58x/Makefile |3 +
 drivers/net/can/usb/etas_es58x/es581_4.c|  559 
 drivers/net/can/usb/etas_es58x/es581_4.h|  237 ++
 drivers/net/can/usb/etas_es58x/es58x_core.c | 2725 +++
 drivers/net/can/usb/etas_es58x/es58x_core.h |  700 +
 drivers/net/can/usb/etas_es58x/es58x_fd.c   |  648 +
 drivers/net/can/usb/etas_es58x/es58x_fd.h   |  243 ++
 drivers/usb/class/cdc-acm.c |   11 +
 include/linux/can/dev.h |   44 +-
 12 files changed, 5189 insertions(+), 17 deletions(-)
 create mode 100644 drivers/net/can/usb/etas_es58x/Makefile
 create mode 100644 drivers/net/can/usb/etas_es58x/es581_4.c
 create mode 100644 drivers/net/can/usb/etas_es58x/es581_4.h
 create mode 100644 drivers/net/can/usb/etas_es58x/es58x_core.c
 create mode 100644 drivers/net/can/usb/etas_es58x/es58x_core.h
 create mode 100644 drivers/net/can/usb/etas_es58x/es58x_fd.c
 create mode 100644 drivers/net/can/usb/etas_es58x/es58x_fd.h

-- 
2.26.2

Re: [PATCH 1/1] ASoC: cs42l51: add soft dependency declaration

[Mark Brown]

On Fri, Oct 02, 2020 at 05:29:04PM +0200, Olivier Moysan wrote:
> When configured as module, CS42L51 codec driver uses two modules
> snd-soc-cs42l51 and snd-soc-cs42l51-i2c.
> Add soft dependency on snd-soc-cs42l51-i2c in snd-soc-cs42l51,
> to allow smart module dependency solving.

Doesn't the userspace tooling usually manage to figure this out from
symbol usage?


signature.asc
Description: PGP signature

Re: [PATCH] arm64: dts: allwinner: h6: add eMMC voltage property for Beelink GS1

[Clément Péron]

Hi Maxime,

On Wed, 30 Sep 2020 at 12:27, Maxime Ripard  wrote:
>
> Hi,
>
> On Mon, Sep 28, 2020 at 05:00:37PM +0200, Clément Péron wrote:
> > VQMMC supply is connected to BLDO2 which provides 1.8V.
> >
> > Let's reflect this in the device-tree.
>
> This commit log doesn't really explain what is going on though?
>
> > Fixes: 089bee8dd119 ("arm64: dts: allwinner: h6: Introduce Beelink GS1 
> > board")
> > Signed-off-by: Clément Péron 
> > ---
> >  arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts 
> > b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > index 049c21718846..3f20d2c9 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts
> > @@ -145,6 +145,7 @@  {
> >   vqmmc-supply = <_bldo2>;
>
> The Device Tree already expresses that the vqmmc supply is connected to
> BLDO2 which provides 1.8V here (together with the reg_bldo2 node).
>
> >   non-removable;
> >   cap-mmc-hw-reset;
> > + mmc-hs200-1_8v;
>
> Whereas this indicates that the eMMC supports the HS200 MMC mode at 1.8V

What about a comment like this:

Sunxi mmc driver can't distinguish at runtime what's the I/O voltage
for HS200 mode.
Add a property in the device-tree to notify mmc core about this configuration.


Regards,
Clement

>
> Maxime

WARNING in ieee80211_bss_info_change_notify

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:fcadab74 Merge tag 'drm-fixes-2020-10-01-1' of git://anong..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16217b5b90
kernel config:  https://syzkaller.appspot.com/x/.config?x=4e672827d2ffab1f
dashboard link: https://syzkaller.appspot.com/bug?extid=09d1cd2f71e6dd3bfd2c
compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=161112eb90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=124fc53390

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

syz-executor423 uses obsolete (PF_INET,SOCK_PACKET)
[ cut here ]
wlan0: Failed check-sdata-in-driver check, flags: 0x4
WARNING: CPU: 1 PID: 6893 at net/mac80211/driver-ops.h:172 drv_bss_info_changed 
net/mac80211/driver-ops.h:172 [inline]
WARNING: CPU: 1 PID: 6893 at net/mac80211/driver-ops.h:172 
ieee80211_bss_info_change_notify+0x2f4/0x3a0 net/mac80211/main.c:210
Kernel panic - not syncing: panic_on_warn set ...
CPU: 1 PID: 6893 Comm: syz-executor423 Not tainted 5.9.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1d6/0x29e lib/dump_stack.c:118
 panic+0x2c0/0x800 kernel/panic.c:231
 __warn+0x227/0x250 kernel/panic.c:600
 report_bug+0x1b1/0x2e0 lib/bug.c:198
 handle_bug+0x42/0x80 arch/x86/kernel/traps.c:234
 exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:254
 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:536
RIP: 0010:drv_bss_info_changed net/mac80211/driver-ops.h:172 [inline]
RIP: 0010:ieee80211_bss_info_change_notify+0x2f4/0x3a0 net/mac80211/main.c:210
Code: d1 f9 49 8b 87 40 06 00 00 49 81 c7 60 06 00 00 48 85 c0 4c 0f 45 f8 48 
c7 c7 14 2b 4f 89 4c 89 fe 89 ea 31 c0 e8 3c eb 62 f9 <0f> 0b e9 f3 fe ff ff e8 
00 4c 91 f9 0f 0b e9 e7 fe ff ff 44 89 e1
RSP: 0018:c900055e78d0 EFLAGS: 00010246
RAX: 195afe4c76626a00 RBX: 111012590bc1 RCX: 88809195a180
RDX:  RSI: 8000 RDI: 
RBP: 0004 R08: 815e2810 R09: ed1015d262c0
R10: ed1015d262c0 R11:  R12: 888092c85e08
R13: 0200 R14: dc00 R15: 888092c84000
 ieee80211_set_mcast_rate+0x38/0x40 net/mac80211/cfg.c:2453
 rdev_set_mcast_rate net/wireless/rdev-ops.h:1212 [inline]
 nl80211_set_mcast_rate+0x215/0x2c0 net/wireless/nl80211.c:9911
 genl_family_rcv_msg_doit net/netlink/genetlink.c:669 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:714 [inline]
 genl_rcv_msg+0xaf5/0xd70 net/netlink/genetlink.c:731
 netlink_rcv_skb+0x190/0x3a0 net/netlink/af_netlink.c:2470
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:742
 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline]
 netlink_unicast+0x786/0x940 net/netlink/af_netlink.c:1330
 netlink_sendmsg+0xa57/0xd70 net/netlink/af_netlink.c:1919
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg net/socket.c:671 [inline]
 sys_sendmsg+0x519/0x800 net/socket.c:2353
 ___sys_sendmsg net/socket.c:2407 [inline]
 __sys_sendmsg+0x2b1/0x360 net/socket.c:2440
 do_syscall_64+0x31/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x442039
Code: e8 ac 00 03 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
7b 07 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffcd5724568 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 0003 RCX: 00442039
RDX:  RSI: 2180 RDI: 0005
RBP:  R08: 0020 R09: 0020
R10:  R11: 0246 R12: 0032
R13:  R14: 000c R15: 0004
Kernel Offset: disabled
Rebooting in 86400 seconds..


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

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

RE: [DISCUSSION PATCH 00/41] random: possible ways towards NIST SP800-90B compliance

[Van Leeuwen, Pascal]

> -Original Message-
> From: Greg Kroah-Hartman 
> Sent: Friday, October 2, 2020 5:13 PM
> To: Van Leeuwen, Pascal 
> Cc: Torsten Duwe ; Theodore Y. Ts'o ; 
> linux-cry...@vger.kernel.org; Nicolai Stange
> ; LKML ; Arnd Bergmann 
> ; Eric W. Biederman
> ; Alexander E. Patrakov ; Ahmed S. 
> Darwish ; Willy
> Tarreau ; Matthew Garrett ; Vito Caputo 
> ; Andreas Dilger
> ; Jan Kara ; Ray Strode 
> ; William Jon McCann ;
> zhangjs ; Andy Lutomirski ; 
> Florian Weimer ; Lennart
> Poettering ; Peter Matthias 
> ; Marcelo Henrique Cerri
> ; Neil Horman ; Randy Dunlap 
> ; Julia Lawall
> ; Dan Carpenter ; Andy Lavr 
> ; Eric Biggers
> ; Jason A. Donenfeld ; Stephan Müller 
> ; Petr Tesarik
> 
> Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST 
> SP800-90B compliance
>
> <<< External Email >>>
> On Fri, Oct 02, 2020 at 02:34:44PM +, Van Leeuwen, Pascal wrote:
> >
> >
> >
> > > -Original Message-
> > > From: Greg Kroah-Hartman 
> > > Sent: Friday, October 2, 2020 4:04 PM
> > > To: Van Leeuwen, Pascal 
> > > Cc: Torsten Duwe ; Theodore Y. Ts'o ; 
> > > linux-cry...@vger.kernel.org; Nicolai Stange
> > > ; LKML ; Arnd Bergmann 
> > > ; Eric W. Biederman
> > > ; Alexander E. Patrakov ; 
> > > Ahmed S. Darwish ; Willy
> > > Tarreau ; Matthew Garrett ; Vito Caputo 
> > > ; Andreas Dilger
> > > ; Jan Kara ; Ray Strode 
> > > ; William Jon McCann
> ;
> > > zhangjs ; Andy Lutomirski ; 
> > > Florian Weimer ; Lennart
> > > Poettering ; Peter Matthias 
> > > ; Marcelo Henrique Cerri
> > > ; Neil Horman ; Randy 
> > > Dunlap ; Julia Lawall
> > > ; Dan Carpenter ; Andy 
> > > Lavr ; Eric Biggers
> > > ; Jason A. Donenfeld ; Stephan 
> > > Müller ; Petr Tesarik
> > > 
> > > Subject: Re: [DISCUSSION PATCH 00/41] random: possible ways towards NIST 
> > > SP800-90B compliance
> > >
> > > <<< External Email >>>
> > > On Fri, Oct 02, 2020 at 01:35:18PM +, Van Leeuwen, Pascal wrote:
> > > > ** This message and any attachments are for the sole use of the 
> > > > intended recipient(s). It may contain information that is
> > > confidential and privileged. If you are not the intended recipient of 
> > > this message, you are prohibited from printing, copying,
> > > forwarding or saving it. Please delete the message and attachments and 
> > > notify the sender immediately. **
> > >
> > > As per my legal department requests, this is now ignored and deleted on
> > > my system...
> > >
> > > Hint, it's not a valid footer for public mailing lists...
> > >
> > > greg k-h
> > It's automatically added by our company mail server ... not something I can 
> > control at all :-(
>
> Then your company can not contribute in Linux kernel development, as
> this is obviously not allowed by such a footer.
>
Interesting, this has never been raised as a problem until today ...
Going back through my mail archive, it looks like they started automatically 
adding that some
3 months ago. Not that they informed anyone about that, it just silently 
happened.

> Please work with your IT and legal department to fix this.
>
Eh ... Greg ... that's not how that works in the real world. In the real world, 
legal and IT lay
down the law and you just comply with that (or hack your way around it, if you 
can ;-).

I'm already fighting the good fight trying to keep control of my development 
machines
because IT would just love to get rid of those (since not under IT control  
oh dear ...)
And obviously, you cannot do kernel development on a machine without root 
access.
It's annoying enough already to require IT support to provide explicit 
permission to open
the task manager on my own company laptop ... grmbl.

>
> thanks,
>
> greg k-h

Regards,
Pascal van Leeuwen
Silicon IP Architect Multi-Protocol Engines, Rambus Security
Rambus ROTW Holding BV
+31-73 6581953

Note: The Inside Secure/Verimatrix Silicon IP team was recently acquired by 
Rambus.
Please be so kind to update your e-mail address book with my new e-mail address.


** This message and any attachments are for the sole use of the intended 
recipient(s). It may contain information that is confidential and privileged. 
If you are not the intended recipient of this message, you are prohibited from 
printing, copying, forwarding or saving it. Please delete the message and 
attachments and notify the sender immediately. **

Rambus Inc.

Re: [PATCH v3 0/2] MTE support for KVM guest

[Steven Price]

On 02/10/2020 15:36, Andrew Jones wrote:

On Fri, Sep 25, 2020 at 10:36:05AM +0100, Steven Price wrote:

Version 3 of adding MTE support for KVM guests. See the previous (v2)
posting for background:

  https://lore.kernel.org/r/20200904160018.29481-1-steven.price%40arm.com

These patches add support to KVM to enable MTE within a guest. They are
based on Catalin's v9 MTE user-space support series[1] (currently in
next).

Changes since v2:

  * MTE is no longer a VCPU feature, instead it is a VM cap.

  * Being a VM cap means easier probing (check for KVM_CAP_ARM_MTE).

  * The cap must be set before any VCPUs are created, preventing any
shenanigans where MTE is enabled for the guest after memory accesses
have been performed.

[1] https://lore.kernel.org/r/20200904103029.32083-1-catalin.mari...@arm.com

Steven Price (2):
   arm64: kvm: Save/restore MTE registers
   arm64: kvm: Introduce MTE VCPU feature

  arch/arm64/include/asm/kvm_emulate.h   |  3 +++
  arch/arm64/include/asm/kvm_host.h  |  7 +++
  arch/arm64/include/asm/sysreg.h|  3 ++-
  arch/arm64/kvm/arm.c   |  9 +
  arch/arm64/kvm/hyp/include/hyp/sysreg-sr.h | 14 ++
  arch/arm64/kvm/mmu.c   | 15 +++
  arch/arm64/kvm/sys_regs.c  | 20 +++-
  include/uapi/linux/kvm.h   |  1 +
  8 files changed, 66 insertions(+), 6 deletions(-)

--
2.20.1




Hi Steven,

These patches look fine to me, but I'd prefer we have a working
implementation in QEMU before we get too excited about the KVM
bits. kvmtool isn't sufficient since it doesn't support migration
(at least afaik). In the past we've implemented features in KVM
that look fine, but then issues have been discovered when trying
to enable them from QEMU, where we also support migration. This
feature looks like there's risk of issues with the userspace side.
Although these two patches would probably stay the same, even if
userspace requires more support.


I agree kvmtool isn't a great test because it doesn't support migration. 
The support in this series is just the basic support for MTE in a guest 
and we'd need to wait for the QEMU implementation before deciding 
whether we need any extra support (e.g. kernel interfaces for 
reading/writing tags as discussed before).


However, I don't think there's much danger of the support in this series 
changing - so extra support can be added when/if it's needed, but I 
don't think we need to block these series on that - QEMU can just probe 
for whatever additional support it needs before enabling MTE in a guest. 
I plan to rebase/repost after -rc1 when the user space support has been 
merged.


Steve

Re: [PATCH v4] kvm,x86: Exit to user space in case page fault error

[Vivek Goyal]

On Thu, Oct 01, 2020 at 03:33:20PM -0700, Sean Christopherson wrote:
> On Thu, Oct 01, 2020 at 05:55:08PM -0400, Vivek Goyal wrote:
> > On Mon, Sep 28, 2020 at 09:37:00PM -0700, Sean Christopherson wrote:
> > > On Mon, Jul 20, 2020 at 05:13:59PM -0400, Vivek Goyal wrote:
> > > > @@ -10369,6 +10378,36 @@ void kvm_set_rflags(struct kvm_vcpu *vcpu, 
> > > > unsigned long rflags)
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(kvm_set_rflags);
> > > >  
> > > > +static inline u32 kvm_error_gfn_hash_fn(gfn_t gfn)
> > > > +{
> > > > +   BUILD_BUG_ON(!is_power_of_2(ERROR_GFN_PER_VCPU));
> > > > +
> > > > +   return hash_32(gfn & 0x, 
> > > > order_base_2(ERROR_GFN_PER_VCPU));
> > > > +}
> > > > +
> > > > +static void kvm_add_error_gfn(struct kvm_vcpu *vcpu, gfn_t gfn)
> > > > +{
> > > > +   u32 key = kvm_error_gfn_hash_fn(gfn);
> > > > +
> > > > +   /*
> > > > +* Overwrite the previous gfn. This is just a hint to do
> > > > +* sync page fault.
> > > > +*/
> > > > +   vcpu->arch.apf.error_gfns[key] = gfn;
> > > > +}
> > > > +
> > > > +/* Returns true if gfn was found in hash table, false otherwise */
> > > > +static bool kvm_find_and_remove_error_gfn(struct kvm_vcpu *vcpu, gfn_t 
> > > > gfn)
> > > > +{
> > > > +   u32 key = kvm_error_gfn_hash_fn(gfn);
> > > 
> > > Mostly out of curiosity, do we really need a hash?  E.g. could we get away
> > > with an array of 4 values?  2 values?  Just wondering if we can avoid 64*8
> > > bytes per CPU.
> > 
> > We are relying on returning error when guest task retries fault. Fault
> > will be retried on same address if same task is run by vcpu after
> > "page ready" event. There is no guarantee that same task will be
> > run. In theory, this cpu could have a large number of tasks queued
> > and run these tasks before the faulting task is run again. Now say
> > there are 128 tasks being run and 32 of them have page fault
> > errors. Then if we keep 4 values, newer failures will simply
> > overwrite older failures and we will keep spinning instead of
> > exiting to user space.
> > 
> > That's why this array of 64 gfns and add gfns based on hash. This
> > does not completely elimiante the above possibility but chances
> > of one hitting this are very very slim.
> 
> But have you actually tried such a scenario?  In other words, is there good
> justification for burning the extra memory?

Its not easy to try and reproduce. So it is all theory  at this point of time.
If you are worried about memory usage, we can probably reduce the size
of hash table. Say from 64, reduce it to 8. I am fine with that. I think
initially I had a single error_gfn. But Vitaly had concerns about
above scenario, so I implemeted a hash table.

I think reducing hash table size to 8 or 16 probaly is a good middle
ground.

> 
> Alternatively, what about adding a new KVM request type to handle this?
> E.g. when the APF comes back with -EFAULT, snapshot the GFN and make a
> request.  The vCPU then gets kicked and exits to userspace.  Before exiting
> to userspace, the request handler resets vcpu->arch.apf.error_gfn.  Bad GFNs
> simply get if error_gfn is "valid", i.e. there's a pending request.

Sorry, I did not understand the above proposal. Can you please elaborate
a bit more. Part of it is that I don't know much about KVM requests.
Looking at the code it looks like that main loop is parsing if some
kvm request is pending and executing that action.

Don't we want to make sure that we exit to user space when guest retries
error gfn access again. In this case once we get -EFAULT, we will still
inject page_ready into guest. And then either same process or a different
process might run. 

So when exactly code raises a kvm request. If I raise it right when
I get -EFAULT, then kvm will exit to user space upon next entry
time. But there is no guarantee guest vcpu is running the process which
actually accessed the error gfn. And that probably means that register
state of cpu does not mean much and one can not easily figure out
which task tried to access the bad memory and when.

That's why we prepare a list of error gfn and only exit to user space
when error_gfn access is retried so that guest vcpu context is correct.

What am I missing?

Thanks
Vivek

> 
> That would guarantee the error is propagated to userspace, and doesn't lose
> any guest information as dropping error GFNs just means the guest will take
> more page fault exits.
> 
> > > One thought would be to use the index to handle the case of no error gfns 
> > > so
> > > that the size of the array doesn't affect lookup for the common case, e.g.
> > 
> > We are calculating hash of gfn (used as index in array). So lookup cost
> > is not driven by size of array. Its O(1) and not O(N). We just lookup
> > at one element in array and if it does not match, we return false.
> > 
> > u32 key = kvm_error_gfn_hash_fn(gfn);
> > 
> > if (vcpu->arch.apf.error_gfns[key] != gfn)
> > return 0;
> > 
> > 
> > > 

Re: [PATCH 3/3] task_work: use TIF_TASKWORK if available

[Oleg Nesterov]

On 10/02, Thomas Gleixner wrote:
>
> I think it's fundamentaly wrong that we have several places and several
> flags which handle task_work_run() instead of having exactly one place
> and one flag.

Damn yes, agreed.

Oleg.

KASAN: use-after-free Read in tipc_mcast_xmit (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:a59cf619 Merge branch 'Fix-bugs-in-Octeontx2-netdev-driver'
git tree:   bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=163c246790
kernel config:  https://syzkaller.appspot.com/x/.config?x=99a7c78965c75e07
dashboard link: https://syzkaller.appspot.com/bug?extid=e96a7ba46281824cc46a
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15ada44d90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1400746790

The issue was bisected to:

commit ff48b6222e65ebdba5a403ef1deba6214e749193
Author: Xin Long 
Date:   Sun Sep 13 11:37:31 2020 +

tipc: use skb_unshare() instead in tipc_buf_append()

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=125402b390
final oops: https://syzkaller.appspot.com/x/report.txt?x=115402b390
console output: https://syzkaller.appspot.com/x/log.txt?x=165402b390

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e96a7ba46281824cc...@syzkaller.appspotmail.com
Fixes: ff48b6222e65 ("tipc: use skb_unshare() instead in tipc_buf_append()")

R10:  R11: 0246 R12: 004028a0
R13: 00402930 R14:  R15: 
tipc: Failed do clone local mcast rcv buffer
==
BUG: KASAN: use-after-free in __skb_unlink include/linux/skbuff.h:2063 [inline]
BUG: KASAN: use-after-free in __skb_dequeue include/linux/skbuff.h:2082 [inline]
BUG: KASAN: use-after-free in __skb_queue_purge include/linux/skbuff.h:2793 
[inline]
BUG: KASAN: use-after-free in tipc_mcast_xmit+0xfaa/0x1170 net/tipc/bcast.c:422
Read of size 8 at addr 8880a73e2040 by task syz-executor657/6887

CPU: 1 PID: 6887 Comm: syz-executor657 Not tainted 5.9.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x198/0x1fd lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0xae/0x497 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
 __skb_unlink include/linux/skbuff.h:2063 [inline]
 __skb_dequeue include/linux/skbuff.h:2082 [inline]
 __skb_queue_purge include/linux/skbuff.h:2793 [inline]
 tipc_mcast_xmit+0xfaa/0x1170 net/tipc/bcast.c:422
 tipc_sendmcast+0xaaf/0xef0 net/tipc/socket.c:865
 __tipc_sendmsg+0xee3/0x18a0 net/tipc/socket.c:1454
 tipc_sendmsg+0x4c/0x70 net/tipc/socket.c:1387
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:671
 sys_sendmsg+0x6e8/0x810 net/socket.c:2353
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x4419d9
Code: e8 cc ac 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 
89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 
3b 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:7ffe0cace4c8 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX:  RCX: 004419d9
RDX:  RSI: 2280 RDI: 0004
RBP: f0ee R08: 0001 R09: 00402930
R10:  R11: 0246 R12: 004028a0
R13: 00402930 R14:  R15: 

Allocated by task 6887:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
 kasan_set_track mm/kasan/common.c:56 [inline]
 __kasan_kmalloc.constprop.0+0xbf/0xd0 mm/kasan/common.c:461
 slab_post_alloc_hook mm/slab.h:518 [inline]
 slab_alloc_node mm/slab.c:3254 [inline]
 kmem_cache_alloc_node+0x136/0x430 mm/slab.c:3574
 __alloc_skb+0x71/0x550 net/core/skbuff.c:198
 alloc_skb_fclone include/linux/skbuff.h:1144 [inline]
 tipc_buf_acquire+0x28/0xf0 net/tipc/msg.c:76
 tipc_msg_build+0x6b8/0x10c0 net/tipc/msg.c:428
 tipc_sendmcast+0x855/0xef0 net/tipc/socket.c:859
 __tipc_sendmsg+0xee3/0x18a0 net/tipc/socket.c:1454
 tipc_sendmsg+0x4c/0x70 net/tipc/socket.c:1387
 sock_sendmsg_nosec net/socket.c:651 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:671
 sys_sendmsg+0x6e8/0x810 net/socket.c:2353
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2407
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2440
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

Freed by task 6887:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:48
 kasan_set_track+0x1c/0x30 mm/kasan/common.c:56
 kasan_set_free_info+0x1b/0x30 mm/kasan/generic.c:355
 __kasan_slab_free+0xd8/0x120 mm/kasan/common.c:422
 __cache_free mm/slab.c:3418 [inline]
 kmem_cache_free.part.0+0x74/0x1e0 mm/slab.c:3693
 kfree_skbmem+0x166/0x1b0 net/core/skbuff.c:643
 kfree_skb+0x7d/0x100 include/linux/refcount.h:270