Re: F2FS Segmentation Fault

[Jaegeuk Kim]

On 07/13, Nathan Royce wrote:
> On Mon, Jul 13, 2020 at 7:03 PM Jaegeuk Kim  wrote:
> >
> > Hi Nathan,
> >
> > Could you try to say "N" here to move forward to fix the corrupted metadata?
> >
> > Thanks,
> *
> Do you want to restore lost files into ./lost_found/? [Y/N] N
> Info: Write valid nat_bits in checkpoint
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18eca] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ecb] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ecc] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ee3] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ee4] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18ee5] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18f78] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18f79] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x18f7a] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x4d621] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x4d622] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x7fa32] in NAT
> [FIX] (nullify_nat_entry:2273)  --> Remove nid [0x7fa33] in NAT
> Info: Write valid nat_bits in checkpoint
> 
> Done.
> *
> 
> *
> Info: Fix the reported corruption.
> Info: Force to fix corruption
> Info: Segments per section = 1
> Info: Sections per zone = 1
> Info: sector size = 512
> Info: total sectors = 124168159 (60628 MB)
> Info: MKFS version
>   "Linux version 5.1.15.a-1-hardened (builduser@slave-1) (gcc version
> 9.1.0 (GCC)) #1 SMP PREEMPT Thu Jun 27 11:33:04 CEST 2019"
> Info: FSCK version
>   from "Linux version 4.19.13-dirty (nater@devx64) (gcc version 8.2.1
> 20181127 (GCC)) #2 SMP PREEMPT Mon Dec 31 00:15:50 CST 2018"
> to "Linux version 4.19.13-dirty (nater@devx64) (gcc version 8.2.1
> 20181127 (GCC)) #2 SMP PREEMPT Mon Dec 31 00:15:50 CST 2018"
> Info: superblock features = 0 :
> Info: superblock encrypt level = 0, salt = 
> Info: total FS sectors = 124168152 (60628 MB)
> Info: CKPT version = 63f2b4a
> Info: checkpoint state = 281 :  allow_nocrc nat_bits unmount
> Info: No error was reported
> *
> I'm now booted in from my SDHC card. So it "seems" I'm good to go.
> But with the actions taken and the files I've seen displayed during
> the fsck, I'm thinking I'm going to reinstall all packages.
> Assuming the issue was related to the power outage, I do wonder why
> there weren't any fsck issues at bootup at that time. I hadn't had any
> disk issues before with that card.
> At least now I know the issue would be resolved by not saving the lost
> files and I can continue on my merry way.

I suspect the last power outage caused the FTL in the card firmware to point
the f2fs NAT table area to somewhere wrong flash cells. It may be possible
that we can't see any filesystem corruption easily, since it can corrupt
data area in higher possibility; this doesn't lead filesystem inconsistency.

I guess you use "-a" for fsck at boot up, which means scanning the disk when
runtime f2fs detects any inconsistent data. But that is true, only when the disk
guarantees SYNC_CACHE at least. Unfortunately, IMHO, such the flash card doesn't
support it gracefully, and thus, we can't rely on SYNC_CACHE which should be the
baseline to guarantee filesystem consistency. I think it'd be good to run "-f",
if sudden power cut happens in this case.

Thanks,

Re: [PATCH v2] checkpatch: Fix the usage of capture group ( ... )

[Lukas Bulwahn]

On Tue, 14 Jul 2020, Mrinal Pandey wrote:

> The usage of "capture group (...)" in the immediate condition after `&&`
> results in `$1` being uninitialized. This issues a warning "Use of
> uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl
> line 2638".
> 
> I noticed this bug while running checkpatch on the set of commits from
> v5.7 to v5.8-rc1 of the kernel on the commits with a diff content in
> their commit message.
> 
> This bug was introduced in the script by commit e518e9a59ec3
> ("checkpatch: emit an error when there's a diff in a changelog"). It has
> been in the script since then.
> 
> The author intended to store the match made by capture group in variable
> `$1`. This should have contained the name of the file as `[\w/]+` matched.
> However, this couldn't be accomplished due to usage of capture group and
> `$1` in the same regular expression.
> 
> Fix this by placing the capture group in the condition before `&&`.
> Thus, `$1` can be initialized to the text that capture group matches
> thereby setting it to the desired and required value.
> 
> Reviewed-by: Lukas Bulwahn 
> Tested-by: Lukas Bulwahn 
> Signed-off-by: Mrinal Pandey 
> ---
> Changes since v1:
> Add Reviewed-by and Tested-by tag
>


Usually, the maintainers pick up those tags when they apply a patch to 
their tree, and the patch authors do not need to add those tags and resend 
the patch as a new version on the mailing list.

Mrinal, can you please go through and check the kernel documentation on 
submitting patches and find the places where it is pointed out that the 
maintainers usually apply those tags and the authors usually do not need 
to resend a new version of the patch with the tags applied?

If you cannot find such a statement in the documentation, please let us 
know where it would ideally added in the documentation. We can then create 
a patch for that together.


Lukas

Re: [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning

[Andersen, John]

On Thu, Jul 09, 2020 at 09:27:43AM -0700, Andy Lutomirski wrote:
> On Thu, Jul 9, 2020 at 9:22 AM Dave Hansen  wrote:
> >
> > On 7/9/20 9:07 AM, Andy Lutomirski wrote:
> > > On Thu, Jul 9, 2020 at 8:56 AM Dave Hansen  wrote:
> > >> On 7/9/20 8:44 AM, Andersen, John wrote:
> > >>> Bits which are allowed to be pinned default to WP for CR0 and 
> > >>> SMEP,
> > >>> SMAP, and UMIP for CR4.
> > >> I think it also makes sense to have FSGSBASE in this set.
> > >>
> > >> I know it hasn't been tested, but I think we should do the legwork to
> > >> test it.  If not in this set, can we agree that it's a logical next step?
> > > I have no objection to pinning FSGSBASE, but is there a clear
> > > description of the threat model that this whole series is meant to
> > > address?  The idea is to provide a degree of protection against an
> > > attacker who is able to convince a guest kernel to write something
> > > inappropriate to CR4, right?  How realistic is this?
> >
> > If a quick search can find this:
> >
> > > https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html
> >
> > I'd pretty confident that the guys doing actual bad things have it in
> > their toolbox too.
> >
> 
> True, but we have the existing software CR4 pinning.  I suppose the
> virtualization version is stronger.
> 

Yes, as Kees said this will be stronger because it stops ROP and other gadget
based techniques which avoid the use of native_write_cr0/4().

With regards to what should be done in this patchset and what in other
patchsets. I have a fix for kexec thanks to Arvind's note about
TRAMPOLINE_32BIT_CODE_SIZE. The physical host boots fine now and the virtual
one can kexec fine.

What remains to be done on that front is to add some identifying information to
the kernel image to declare that it supports paravirtualized control register
pinning or not.

Liran suggested adding a section to the built image acting as a flag to signify
support for being kexec'd by a kernel with pinning enabled. If anyone has any
opinions on how they'd like to see this implemented please let me know.
Otherwise I'll just take a stab at it and you'll all see it hopefully in the
next version.

With regards to FSGSBASE, are we open to validating and adding that to the
DEFAULT set as a part of a separate patchset? This patchset is focused on
replicating the functionality we already have natively.


(If anyone got this email twice, sorry I messed up the From: field the first
time around)

Re: [PATCH 4/6] staging: qlge: qlge_main: Simplify while statements.

[Benjamin Poirier]

On 2020-07-13 17:50 +0530, Suraj Upadhyay wrote:
> Simplify while loops into more readable and simple for loops.
> 
> Signed-off-by: Suraj Upadhyay 
> ---
[...]
> @@ -1824,7 +1821,7 @@ static struct sk_buff *ql_build_rx_skb(struct 
> ql_adapter *qdev,
>   sbq_desc->p.skb = NULL;
>   skb_reserve(skb, NET_IP_ALIGN);
>   }
> - do {
> + for (; length > 0; length -= size, i++) {
>   lbq_desc = ql_get_curr_lchunk(qdev, rx_ring);
>   size = min(length, qdev->lbq_buf_size);
>  
> @@ -1839,7 +1836,7 @@ static struct sk_buff *ql_build_rx_skb(struct 
> ql_adapter *qdev,
>   skb->truesize += size;
>   length -= size;
>   i++;
> - } while (length > 0);
> + }

Looks like length and i modification should be removed from here. But in
this instance, maybe the original was better anyways.

Agreed with Dan. At least some of those loops can be converted to "count
up" loops for a more familiar appearance.


signature.asc
Description: PGP signature

Re: [PATCH 2/4] KVM: x86: Introduce paravirt feature CR0/CR4 pinning

[Andersen, John]

On Thu, Jul 09, 2020 at 09:27:43AM -0700, Andy Lutomirski wrote:
> On Thu, Jul 9, 2020 at 9:22 AM Dave Hansen  wrote:
> >
> > On 7/9/20 9:07 AM, Andy Lutomirski wrote:
> > > On Thu, Jul 9, 2020 at 8:56 AM Dave Hansen  wrote:
> > >> On 7/9/20 8:44 AM, Andersen, John wrote:
> > >>> Bits which are allowed to be pinned default to WP for CR0 and 
> > >>> SMEP,
> > >>> SMAP, and UMIP for CR4.
> > >> I think it also makes sense to have FSGSBASE in this set.
> > >>
> > >> I know it hasn't been tested, but I think we should do the legwork to
> > >> test it.  If not in this set, can we agree that it's a logical next step?
> > > I have no objection to pinning FSGSBASE, but is there a clear
> > > description of the threat model that this whole series is meant to
> > > address?  The idea is to provide a degree of protection against an
> > > attacker who is able to convince a guest kernel to write something
> > > inappropriate to CR4, right?  How realistic is this?
> >
> > If a quick search can find this:
> >
> > > https://googleprojectzero.blogspot.com/2017/05/exploiting-linux-kernel-via-packet.html
> >
> > I'd pretty confident that the guys doing actual bad things have it in
> > their toolbox too.
> >
> 
> True, but we have the existing software CR4 pinning.  I suppose the
> virtualization version is stronger.
> 

Yes, as Kees said this will be stronger because it stops ROP and other gadget
based techniques which avoid the use of native_write_cr0/4().

With regards to what should be done in this patchset and what in other
patchsets. I have a fix for kexec thanks to Arvind's note about
TRAMPOLINE_32BIT_CODE_SIZE. The physical host boots fine now and the virtual
one can kexec fine.

What remains to be done on that front is to add some identifying information to
the kernel image to declare that it supports paravirtualized control register
pinning or not.

Liran suggested adding a section to the built image acting as a flag to signify
support for being kexec'd by a kernel with pinning enabled. If anyone has any
opinions on how they'd like to see this implemented please let me know.
Otherwise I'll just take a stab at it and you'll all see it hopefully in the
next version.

With regards to FSGSBASE, are we open to validating and adding that to the
DEFAULT set as a part of a separate patchset? This patchset is focused on
replicating the functionality we already have natively.

Re: [PATCH v2] Since am437x have the same clock structure with am335x [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan probe failed on am437x platform.

[Stephen Rothwell]

Hi Dillon,

On Tue, 14 Jul 2020 13:21:07 +0800 dillon min  wrote:
>
> Thanks, how about the below commit message.
> 
> Subject: [PATCH v4] Fix dcan driver probe failed on am437x platform
> 
> Got following d_can probe errors with kernel 5.8-rc1 on am437x
> 
> [   10.730822] CAN device driver interface
> Starting Wait for Network to be Configured...
> [  OK  ] Reached target Network.
> [   10.787363] c_can_platform 481cc000.can: probe failed
> [   10.792484] c_can_platform: probe of 481cc000.can failed with
> error -2
> [   10.799457] c_can_platform 481d.can: probe failed
> [   10.804617] c_can_platform: probe of 481d.can failed with
> error -2
> 
> actually, Tony has fixed this issue on am335x with the patch [3]
> 
> Since am437x has the same clock structure with am335x
> [1][2], so reuse the code from Tony Lindgren's patch [3] to fix it.
> 
> 
> [1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
> Integration
> [2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
> Integration
> [3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")
> 
> Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during
> init to read revision")
> Signed-off-by: dillon min 
> ---
> 
> Hi Stephen,
> 
> This changes correct commit messages based on your reviewing.
> make Fixes tags to oneline.
> make all commit message tags at the end of commit message
> make Fixes tags before Signed-off-by line.
> add probe failed log to commit message.

Apart from the line wrapping, that looks better.  I assume that your
email client (looks like Gmail web gui) is wrapping the lines, please
see if you can stop it doing that (see the section on Gmail in
Documentation/process/email-clients.rst).

-- 
Cheers,
Stephen Rothwell


pgpfLWxR3ggvP.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 2/2] Add PWM fan controller driver for LGM SoC

[Tanwar, Rahul]

Hi Uwe,

On 14/7/2020 3:10 am, Uwe Kleine-König wrote:
> Hello,
>
> On Tue, Jun 30, 2020 at 03:55:32PM +0800, Rahul Tanwar wrote:
>> Intel Lightning Mountain(LGM) SoC contains a PWM fan controller.
>> This PWM controller does not have any other consumer, it is a
>> dedicated PWM controller for fan attached to the system. Add
>> driver for this PWM fan controller.
>>
>> Signed-off-by: Rahul Tanwar 
>> ---
>>  drivers/pwm/Kconfig |  11 ++
>>  drivers/pwm/Makefile|   1 +
>>  drivers/pwm/pwm-intel-lgm.c | 266 
>> 
>>  3 files changed, 278 insertions(+)
>>  create mode 100644 drivers/pwm/pwm-intel-lgm.c
>>
>> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
>> index cb8d739067d2..3486edab09c4 100644
>> --- a/drivers/pwm/Kconfig
>> +++ b/drivers/pwm/Kconfig
>> @@ -232,6 +232,17 @@ config PWM_IMX_TPM
>>To compile this driver as a module, choose M here: the module
>>will be called pwm-imx-tpm.
>>  
>> +config PWM_INTEL_LGM
>> +tristate "Intel LGM PWM support"
>> +depends on OF && HAS_IOMEM
>> +depends on X86 || COMPILE_TEST
>> +select REGMAP_MMIO
>> +help
>> +  Generic PWM fan controller driver for LGM SoC.
>> +
>> +  To compile this driver as a module, choose M here: the module
>> +  will be called pwm-intel-lgm.
>> +
>>  config PWM_IQS620A
>>  tristate "Azoteq IQS620A PWM support"
>>  depends on MFD_IQS62X || COMPILE_TEST
>> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
>> index a59c710e98c7..db154a6b4f51 100644
>> --- a/drivers/pwm/Makefile
>> +++ b/drivers/pwm/Makefile
>> @@ -20,6 +20,7 @@ obj-$(CONFIG_PWM_IMG)  += pwm-img.o
>>  obj-$(CONFIG_PWM_IMX1)  += pwm-imx1.o
>>  obj-$(CONFIG_PWM_IMX27) += pwm-imx27.o
>>  obj-$(CONFIG_PWM_IMX_TPM)   += pwm-imx-tpm.o
>> +obj-$(CONFIG_PWM_INTEL_LGM) += pwm-intel-lgm.o
>>  obj-$(CONFIG_PWM_IQS620A)   += pwm-iqs620a.o
>>  obj-$(CONFIG_PWM_JZ4740)+= pwm-jz4740.o
>>  obj-$(CONFIG_PWM_LP3943)+= pwm-lp3943.o
>> diff --git a/drivers/pwm/pwm-intel-lgm.c b/drivers/pwm/pwm-intel-lgm.c
>> new file mode 100644
>> index ..fddfedd56fc3
>> --- /dev/null
>> +++ b/drivers/pwm/pwm-intel-lgm.c
>> @@ -0,0 +1,266 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2020 Intel Corporation.
>> + *
>> + * Notes & Limitations:
> I'd like to have this "Limitations:" only to make it easily greppable.
>
>> + * - The hardware supports fixed period which is dependent on 2/3 or 4
>> + *   wire fan mode.
>> + * - Supports normal polarity. Does not support changing polarity.
>> + * - When PWM is disabled, output of PWM will become 0(inactive). It doesn't
>> + *   keep track of running period.
>> + * - When duty cycle is changed, PWM output may be a mix of previous setting
>> + *   and new setting for the first period. From second period, the output is
>> + *   based on new setting.
>> + * - It is a dedicated PWM fan controller. There are no other consumers for
>> + *   this PWM controller.
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define LGM_PWM_FAN_CON00x0
>> +#define LGM_PWM_FAN_EN_EN   BIT(0)
>> +#define LGM_PWM_FAN_EN_DIS  0x0
>> +#define LGM_PWM_FAN_EN_MSK  BIT(0)
>> +#define LGM_PWM_FAN_MODE_2WIRE  0x0
>> +#define LGM_PWM_FAN_MODE_4WIRE  0x1
>> +#define LGM_PWM_FAN_MODE_MSKBIT(1)
>> +#define LGM_PWM_FAN_DC_MSK  GENMASK(23, 16)
>> +
>> +#define LGM_PWM_FAN_CON10x4
>> +#define LGM_PWM_FAN_MAX_RPM_MSK GENMASK(15, 0)
>> +
>> +#define LGM_PWM_MAX_RPM (BIT(16) - 1)
>> +#define LGM_PWM_DEFAULT_RPM 4000
>> +#define LGM_PWM_MAX_DUTY_CYCLE  (BIT(8) - 1)
>> +
>> +#define LGM_PWM_DC_BITS 8
>> +
>> +#define LGM_PWM_PERIOD_2WIRE_NSECS  4000
>> +#define LGM_PWM_PERIOD_4WIRE_NSECS  4
>> +
>> +struct lgm_pwm_chip {
>> +struct pwm_chip chip;
>> +struct regmap *regmap;
>> +struct clk *clk;
>> +struct reset_control *rst;
>> +u32 period;
>> +};
>> +
>> +static inline struct lgm_pwm_chip *to_lgm_pwm_chip(struct pwm_chip *chip)
>> +{
>> +return container_of(chip, struct lgm_pwm_chip, chip);
>> +}
>> +
>> +static int lgm_pwm_enable(struct pwm_chip *chip, bool enable)
>> +{
>> +struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
>> +struct regmap *regmap = pc->regmap;
>> +
>> +regmap_update_bits(regmap, LGM_PWM_FAN_CON0, LGM_PWM_FAN_EN_MSK,
>> +   enable ? LGM_PWM_FAN_EN_EN : LGM_PWM_FAN_EN_DIS);
> regmap_update_bits has a return value. I think it is supposed to be
> checked.
>
>> +
>> +return 0;
>> +}
>> +
>> +static int lgm_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
>> + const struct pwm_state *state)
>> +{
>> +struct lgm_pwm_chip *pc = to_lgm_pwm_chip(chip);
>> +u32 

Re: [PATCH] tty: serial: qcom-geni-serial: Drop the icc bw votes in suspend for console

[Rajendra Nayak]

On 7/14/2020 6:23 AM, Doug Anderson wrote:

Rajendra,

On Fri, Jul 10, 2020 at 5:41 AM Greg KH  wrote:


On Thu, Jul 09, 2020 at 03:07:00PM +0530, Rajendra Nayak wrote:

When using the geni-serial as console, its important to be
able to hit the lowest possible power state in suspend,
even with no_console_suspend.
The only thing that prevents it today on platforms like the sc7180
is the interconnect BW votes, which we certainly don't need when
the system is in suspend. So in the suspend handler mark them as
ACTIVE_ONLY (0x3) and on resume switch them back to the ALWAYS tag (0x7)

Signed-off-by: Rajendra Nayak 
---
Note: Patch applies on qcom for-next, which has the ICC support patches.
The tag macros are currently not exported and hence the hardcoded values.
Perhaps if and when https://patchwork.kernel.org/patch/11619705/ lands I
can refresh this patch to use the macros.


Feel free to take this patch through that tree.

Acked-by: Greg Kroah-Hartman 


Could you post a v2?  Bjorn landed some of my geni serial patches to
make console / kgdb work better, but then I realized that your patch
no longer applies cleanly.  It's trivial to resolve, so hopefully a v2
should be quick and then Bjorn can land?


Thanks, just rebased and posted the v2.

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 4/5] MIPS: Ingenic: Fix bugs and add missing LED node for X1000.

[Zhou Yanjie]

1.The CU1000-Neo board actually uses X1000E instead of X1000,
  so the wrongly written "ingenic,x1000" in compatible should
  be changed to "ingenic,x1000e".
2.Adjust the order of nodes according to the corresponding
  address value.
3.Drop unnecessary node in "wlan_pwrseq".
4.Add the leds node to "cu1000-neo.dts".

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v4:
New patch.

 arch/mips/boot/dts/ingenic/cu1000-neo.dts | 114 +--
 arch/mips/boot/dts/ingenic/x1000.dtsi | 126 +++---
 2 files changed, 118 insertions(+), 122 deletions(-)

diff --git a/arch/mips/boot/dts/ingenic/cu1000-neo.dts 
b/arch/mips/boot/dts/ingenic/cu1000-neo.dts
index 03abd94acd84..22a1066d637b 100644
--- a/arch/mips/boot/dts/ingenic/cu1000-neo.dts
+++ b/arch/mips/boot/dts/ingenic/cu1000-neo.dts
@@ -7,8 +7,8 @@
 #include 
 
 / {
-   compatible = "yna,cu1000-neo", "ingenic,x1000";
-   model = "YSH & ATIL General Board CU Neo";
+   compatible = "yna,cu1000-neo", "ingenic,x1000e";
+   model = "YSH & ATIL General Board CU1000-Neo";
 
aliases {
serial2 = 
@@ -23,20 +23,19 @@
reg = <0x0 0x0400>;
};
 
+   leds {
+   compatible = "gpio-leds";
+   led-0 {
+   gpios = < 21 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc0";
+   };
+   };
+
wlan_pwrseq: msc1-pwrseq {
compatible = "mmc-pwrseq-simple";
 
-   clocks = <>;
-   clock-names = "ext_clock";
-
reset-gpios = < 17 GPIO_ACTIVE_LOW>;
post-power-on-delay-ms = <200>;
-
-   lpoclk: ap6212a {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <32768>;
-   };
};
 };
 
@@ -53,6 +52,13 @@
ingenic,pwm-channels-mask = <0xfa>;
 };
 
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart2>;
+};
+
  {
status = "okay";
 
@@ -61,43 +67,15 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c0>;
 
-   ads7830@48 {
+   ads7830: adc@48 {
compatible = "ti,ads7830";
reg = <0x48>;
};
 };
 
- {
-   pinctrl-names = "default";
-   pinctrl-0 = <_uart2>;
-
-   status = "okay";
-};
-
- {
-   phy-mode = "rmii";
-   phy-handle = <>;
-
-   pinctrl-names = "default";
-   pinctrl-0 = <_mac>;
-
-   snps,reset-gpio = < 23 GPIO_ACTIVE_LOW>; /* PC23 */
-   snps,reset-active-low;
-   snps,reset-delays-us = <0 1 3>;
-
-   status = "okay";
-};
-
- {
+ {
status = "okay";
 
-   lan8720a: ethernet-phy@0 {
-   compatible = "ethernet-phy-id0007.c0f0", 
"ethernet-phy-ieee802.3-c22";
-   reg = <0>;
-   };
-};
-
- {
bus-width = <8>;
max-frequency = <5000>;
 
@@ -105,26 +83,23 @@
pinctrl-0 = <_msc0>;
 
non-removable;
-
-   status = "okay";
 };
 
  {
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
bus-width = <4>;
max-frequency = <5000>;
 
pinctrl-names = "default";
pinctrl-0 = <_msc1>;
 
-   #address-cells = <1>;
-   #size-cells = <0>;
-
non-removable;
 
mmc-pwrseq = <_pwrseq>;
 
-   status = "okay";
-
ap6212a: wifi@1 {
compatible = "brcm,bcm4329-fmac";
reg = <1>;
@@ -137,23 +112,40 @@
};
 };
 
- {
-   pins_i2c0: i2c0 {
-   function = "i2c0";
-   groups = "i2c0-data";
-   bias-disable;
+ {
+   status = "okay";
+
+   phy-mode = "rmii";
+   phy-handle = <>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_mac>;
+
+   snps,reset-gpio = < 23 GPIO_ACTIVE_LOW>; /* PC23 */
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 3>;
+};
+
+ {
+   status = "okay";
+
+   lan8720a: ethernet-phy@0 {
+   compatible = "ethernet-phy-id0007.c0f0", 
"ethernet-phy-ieee802.3-c22";
+   reg = <0>;
};
+};
 
+ {
pins_uart2: uart2 {
function = "uart2";
groups = "uart2-data-d";
-   bias-disable;
+   bias-pull-up;
};
 
-   pins_mac: mac {
-   function = "mac";
-   groups = "mac";
-   bias-disable;
+   pins_i2c0: i2c0 {
+   function = "i2c0";
+   groups = "i2c0-data";
+   bias-pull-up;
};
 
pins_msc0: msc0 {
@@ -167,4 +159,10 @@
groups = "mmc1-1bit", "mmc1-4bit";
bias-disable;
};
+
+   pins_mac: mac {
+   function = "mac";
+   groups = "mac";
+   bias-disable;
+   };
 };
diff 

[PATCH v4 0/5] Add support for Ingenic X1830 SoC and Y CU1830-Neo board.

[Zhou Yanjie]

v3->v4:
1.Modify the commit message and add the change description
  for CU1000-Neo in patch [2/5].
2.The wrongly written "ingenic,x1000" in compatible is
  changed to "ingenic,x1000e" in "cu1000-neo.dts".
3.Adjust the order of nodes according to the corresponding
  address value for X1000.
4.Drop unnecessary node in "wlan_pwrseq" in "cu1000-neo.dts".
5.Add the leds node to "cu1000-neo.dts".

周琰杰 (Zhou Yanjie) (5):
  MIPS: Ingenic: Add Ingenic X1830 support.
  dt-bindings: MIPS: Add X1830 based CU1830-Neo and fix bug in
CU1000-Neo.
  MIPS: Ingenic: Add YSH & ATIL CU Neo board support.
  MIPS: Ingenic: Fix bugs and add missing LED node for X1000.
  MIPS: CU1000-Neo: Refresh defconfig to support LED.

 .../devicetree/bindings/mips/ingenic/devices.yaml  |  12 +-
 arch/mips/boot/dts/ingenic/Makefile|   1 +
 arch/mips/boot/dts/ingenic/cu1000-neo.dts  | 114 
 arch/mips/boot/dts/ingenic/cu1830-neo.dts  | 168 
 arch/mips/boot/dts/ingenic/x1000.dtsi  | 126 +
 arch/mips/boot/dts/ingenic/x1830.dtsi  | 300 +
 arch/mips/configs/cu1000-neo_defconfig |   4 +
 arch/mips/configs/cu1830-neo_defconfig | 123 +
 arch/mips/jz4740/Kconfig   |  10 +
 9 files changed, 733 insertions(+), 125 deletions(-)
 create mode 100644 arch/mips/boot/dts/ingenic/cu1830-neo.dts
 create mode 100644 arch/mips/boot/dts/ingenic/x1830.dtsi
 create mode 100644 arch/mips/configs/cu1830-neo_defconfig

-- 
2.11.0

[PATCH v4 3/5] MIPS: Ingenic: Add YSH & ATIL CU Neo board support.

[Zhou Yanjie]

Add a device tree and a defconfig for the Ingenic X1830 based
YSH & ATIL CU Neo board.

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v1->v2:
1.Add DT node for LED.
2.Update defconfig for LED.

v2->v3:
Adjust the order of nodes according to the
corresponding address value.

v3->v4:
No change.

 arch/mips/boot/dts/ingenic/Makefile   |   1 +
 arch/mips/boot/dts/ingenic/cu1830-neo.dts | 168 ++
 arch/mips/configs/cu1830-neo_defconfig| 123 ++
 arch/mips/jz4740/Kconfig  |   4 +
 4 files changed, 296 insertions(+)
 create mode 100644 arch/mips/boot/dts/ingenic/cu1830-neo.dts
 create mode 100644 arch/mips/configs/cu1830-neo_defconfig

diff --git a/arch/mips/boot/dts/ingenic/Makefile 
b/arch/mips/boot/dts/ingenic/Makefile
index e1654291a7b0..c33434fad007 100644
--- a/arch/mips/boot/dts/ingenic/Makefile
+++ b/arch/mips/boot/dts/ingenic/Makefile
@@ -3,5 +3,6 @@ dtb-$(CONFIG_JZ4740_QI_LB60)+= qi_lb60.dtb
 dtb-$(CONFIG_JZ4770_GCW0)  += gcw0.dtb
 dtb-$(CONFIG_JZ4780_CI20)  += ci20.dtb
 dtb-$(CONFIG_X1000_CU1000_NEO) += cu1000-neo.dtb
+dtb-$(CONFIG_X1830_CU1830_NEO) += cu1830-neo.dtb
 
 obj-$(CONFIG_BUILTIN_DTB)  += $(addsuffix .o, $(dtb-y))
diff --git a/arch/mips/boot/dts/ingenic/cu1830-neo.dts 
b/arch/mips/boot/dts/ingenic/cu1830-neo.dts
new file mode 100644
index ..640f96c00d63
--- /dev/null
+++ b/arch/mips/boot/dts/ingenic/cu1830-neo.dts
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "x1830.dtsi"
+#include 
+#include 
+#include 
+
+/ {
+   compatible = "yna,cu1830-neo", "ingenic,x1830";
+   model = "YSH & ATIL General Board CU1830-Neo";
+
+   aliases {
+   serial1 = 
+   };
+
+   chosen {
+   stdout-path = "serial1:115200n8";
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x0800>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   led-0 {
+   gpios = < 17 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc0";
+   };
+   };
+
+   wlan_pwrseq: msc1-pwrseq {
+   compatible = "mmc-pwrseq-simple";
+
+   reset-gpios = < 13 GPIO_ACTIVE_LOW>;
+   post-power-on-delay-ms = <200>;
+   };
+};
+
+ {
+   clock-frequency = <2400>;
+};
+
+ {
+   /* 1500 kHz for the system timer and clocksource */
+   assigned-clocks = < TCU_CLK_TIMER0>, < TCU_CLK_TIMER2>;
+   assigned-clock-rates = <150>, <150>;
+
+   /* Use channel #0 for the system timer channel #2 for the clocksource */
+   ingenic,pwm-channels-mask = <0xfa>;
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart1>;
+};
+
+ {
+   status = "okay";
+
+   clock-frequency = <40>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0>;
+
+   ads7830: adc@48 {
+   compatible = "ti,ads7830";
+   reg = <0x48>;
+   };
+};
+
+ {
+   status = "okay";
+
+   bus-width = <4>;
+   max-frequency = <5000>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_msc0>;
+
+   non-removable;
+};
+
+ {
+   status = "okay";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+   bus-width = <4>;
+   max-frequency = <5000>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_msc1>;
+
+   non-removable;
+
+   mmc-pwrseq = <_pwrseq>;
+
+   ap6212a: wifi@1 {
+   compatible = "brcm,bcm4329-fmac";
+   reg = <1>;
+
+   interrupt-parent = <>;
+   interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+   interrupt-names = "host-wake";
+
+   brcm,drive-strength = <10>;
+   };
+};
+
+ {
+   status = "okay";
+
+   phy-mode = "rmii";
+   phy-handle = <>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_mac>;
+
+   snps,reset-gpio = < 28 GPIO_ACTIVE_LOW>; /* PB28 */
+   snps,reset-active-low;
+   snps,reset-delays-us = <0 1 3>;
+};
+
+ {
+   status = "okay";
+
+   ip101gr: ethernet-phy@0 {
+   compatible = "ethernet-phy-id0243.0c54", 
"ethernet-phy-ieee802.3-c22";
+   reg = <0>;
+   };
+};
+
+ {
+   pins_uart1: uart1 {
+   function = "uart1";
+   groups = "uart1-data";
+   bias-pull-up;
+   };
+
+   pins_i2c0: i2c0 {
+   function = "i2c0";
+   groups = "i2c0-data";
+   bias-pull-up;
+   };
+
+   pins_msc0: msc0 {
+   function = "mmc0";
+   groups = "mmc0-1bit", "mmc0-4bit";
+   bias-disable;
+   };
+
+   pins_msc1: msc1 {
+   function = "mmc1";
+   groups = "mmc1-1bit", "mmc1-4bit";
+   

[PATCH v4 2/5] dt-bindings: MIPS: Add X1830 based CU1830-Neo and fix bug in CU1000-Neo.

[Zhou Yanjie]

1.Add bindings for Ingenic X1830 based board, prepare for later dts.
2.The CU1000-Neo board actually uses X1000E instead of X1000, so
  the wrongly written "ingenic,x1000" in bindings should be changed
  to "ingenic,x1000e", the corresponding dts file modification will
  be made in a patch later in this series.

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v1->v2:
No change.

v2->v3:
No change.

v3->v4:
Modify the commit message and add the change description
for CU1000-Neo.

 Documentation/devicetree/bindings/mips/ingenic/devices.yaml | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml 
b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
index d1175030781a..feb695be9f66 100644
--- a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
+++ b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
@@ -8,7 +8,8 @@ title: Ingenic XBurst based Platforms Device Tree Bindings
 
 maintainers:
   - 周琰杰 (Zhou Yanjie) 
-description: |
+
+description:
   Devices with a Ingenic XBurst CPU shall have the following properties.
 
 properties:
@@ -32,8 +33,13 @@ properties:
   - const: img,ci20
   - const: ingenic,jz4780
 
-  - description: YSH & ATIL General Board CU Neo
+  - description: YSH & ATIL General Board, CU1000 Module with Neo Backplane
 items:
   - const: yna,cu1000-neo
-  - const: ingenic,x1000
+  - const: ingenic,x1000e
+
+  - description: YSH & ATIL General Board, CU1830 Module with Neo Backplane
+items:
+  - const: yna,cu1830-neo
+  - const: ingenic,x1830
 ...
-- 
2.11.0

[PATCH v2] tty: serial: qcom-geni-serial: Drop the icc bw votes in suspend for console

[Rajendra Nayak]

When using the geni-serial as console, its important to be
able to hit the lowest possible power state in suspend,
even with no_console_suspend.
The only thing that prevents it today on platforms like the sc7180
is the interconnect BW votes, which we certainly don't need when
the system is in suspend. So in the suspend handler mark them as
ACTIVE_ONLY (0x3) and on resume switch them back to the ALWAYS tag (0x7)

Signed-off-by: Rajendra Nayak 
Reviewed-by: Akash Asthana 
Tested-by: Matthias Kaehlcke 
Acked-by: Greg Kroah-Hartman 
---
v2: Rebased on the latest qcom for-next

 drivers/soc/qcom/qcom-geni-se.c   |  9 +
 drivers/tty/serial/qcom_geni_serial.c | 16 +++-
 include/linux/qcom-geni-se.h  |  1 +
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
index e2a0ba2..355d503 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -771,6 +771,15 @@ int geni_icc_set_bw(struct geni_se *se)
 }
 EXPORT_SYMBOL(geni_icc_set_bw);
 
+void geni_icc_set_tag(struct geni_se *se, u32 tag)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(se->icc_paths); i++)
+   icc_set_tag(se->icc_paths[i].path, tag);
+}
+EXPORT_SYMBOL(geni_icc_set_tag);
+
 /* To do: Replace this by icc_bulk_enable once it's implemented in ICC core */
 int geni_icc_enable(struct geni_se *se)
 {
diff --git a/drivers/tty/serial/qcom_geni_serial.c 
b/drivers/tty/serial/qcom_geni_serial.c
index 583d903..07b7b6b 100644
--- a/drivers/tty/serial/qcom_geni_serial.c
+++ b/drivers/tty/serial/qcom_geni_serial.c
@@ -1505,16 +1505,30 @@ static int __maybe_unused 
qcom_geni_serial_sys_suspend(struct device *dev)
struct uart_port *uport = >uport;
struct qcom_geni_private_data *private_data = uport->private_data;
 
+   /*
+* This is done so we can hit the lowest possible state in suspend
+* even with no_console_suspend
+*/
+   if (uart_console(uport)) {
+   geni_icc_set_tag(>se, 0x3);
+   geni_icc_set_bw(>se);
+   }
return uart_suspend_port(private_data->drv, uport);
 }
 
 static int __maybe_unused qcom_geni_serial_sys_resume(struct device *dev)
 {
+   int ret;
struct qcom_geni_serial_port *port = dev_get_drvdata(dev);
struct uart_port *uport = >uport;
struct qcom_geni_private_data *private_data = uport->private_data;
 
-   return uart_resume_port(private_data->drv, uport);
+   ret = uart_resume_port(private_data->drv, uport);
+   if (uart_console(uport)) {
+   geni_icc_set_tag(>se, 0x7);
+   geni_icc_set_bw(>se);
+   }
+   return ret;
 }
 
 static const struct dev_pm_ops qcom_geni_serial_pm_ops = {
diff --git a/include/linux/qcom-geni-se.h b/include/linux/qcom-geni-se.h
index afa511e..8f385fb 100644
--- a/include/linux/qcom-geni-se.h
+++ b/include/linux/qcom-geni-se.h
@@ -454,6 +454,7 @@ void geni_se_rx_dma_unprep(struct geni_se *se, dma_addr_t 
iova, size_t len);
 int geni_icc_get(struct geni_se *se, const char *icc_ddr);
 
 int geni_icc_set_bw(struct geni_se *se);
+void geni_icc_set_tag(struct geni_se *se, u32 tag);
 
 int geni_icc_enable(struct geni_se *se);
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCH v4 5/5] MIPS: CU1000-Neo: Refresh defconfig to support LED.

[Zhou Yanjie]

Refresh CU1000-Neo's defconfig to support LED.

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v4:
New patch.

 arch/mips/configs/cu1000-neo_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/mips/configs/cu1000-neo_defconfig 
b/arch/mips/configs/cu1000-neo_defconfig
index 9b05a8fdabe1..6b471cdb16cf 100644
--- a/arch/mips/configs/cu1000-neo_defconfig
+++ b/arch/mips/configs/cu1000-neo_defconfig
@@ -74,6 +74,10 @@ CONFIG_JZ4740_WDT=y
 # CONFIG_USB_SUPPORT is not set
 CONFIG_MMC=y
 CONFIG_MMC_JZ4740=y
+CONFIG_NEW_LEDS=y
+CONFIG_LEDS_CLASS=y
+CONFIG_LEDS_GPIO=y
+CONFIG_LEDS_TRIGGERS=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_JZ4740=y
 CONFIG_DMADEVICES=y
-- 
2.11.0

[PATCH v4 1/5] MIPS: Ingenic: Add Ingenic X1830 support.

[Zhou Yanjie]

Support the Ingenic X1830 SoC using the code under arch/mips/jz4740.
This is left unselectable in Kconfig until a X1830 based board is
added in a later commit.

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
v1->v2:
No change.

v2->v3:
Adjust the order of nodes according to the
corresponding address value.

v3->v4:
No change.

 arch/mips/boot/dts/ingenic/x1830.dtsi | 300 ++
 arch/mips/jz4740/Kconfig  |   6 +
 2 files changed, 306 insertions(+)
 create mode 100644 arch/mips/boot/dts/ingenic/x1830.dtsi

diff --git a/arch/mips/boot/dts/ingenic/x1830.dtsi 
b/arch/mips/boot/dts/ingenic/x1830.dtsi
new file mode 100644
index ..eb1214481a33
--- /dev/null
+++ b/arch/mips/boot/dts/ingenic/x1830.dtsi
@@ -0,0 +1,300 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "ingenic,x1830";
+
+   cpuintc: interrupt-controller {
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   compatible = "mti,cpu-interrupt-controller";
+   };
+
+   intc: interrupt-controller@10001000 {
+   compatible = "ingenic,x1830-intc", "ingenic,jz4780-intc";
+   reg = <0x10001000 0x50>;
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <>;
+   interrupts = <2>;
+   };
+
+   exclk: ext {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   };
+
+   rtclk: rtc {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <32768>;
+   };
+
+   cgu: x1830-cgu@1000 {
+   compatible = "ingenic,x1830-cgu";
+   reg = <0x1000 0x100>;
+
+   #clock-cells = <1>;
+
+   clocks = <>, <>;
+   clock-names = "ext", "rtc";
+   };
+
+   tcu: timer@10002000 {
+   compatible = "ingenic,x1830-tcu", "ingenic,x1000-tcu", 
"simple-mfd";
+   reg = <0x10002000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x10002000 0x1000>;
+
+   #clock-cells = <1>;
+
+   clocks = < X1830_CLK_RTCLK
+  X1830_CLK_EXCLK
+  X1830_CLK_PCLK>;
+   clock-names = "rtc", "ext", "pclk";
+
+   interrupt-controller;
+   #interrupt-cells = <1>;
+
+   interrupt-parent = <>;
+   interrupts = <27 26 25>;
+
+   wdt: watchdog@0 {
+   compatible = "ingenic,x1830-watchdog", 
"ingenic,jz4780-watchdog";
+   reg = <0x0 0x10>;
+
+   clocks = < TCU_CLK_WDT>;
+   clock-names = "wdt";
+   };
+   };
+
+   rtc: rtc@10003000 {
+   compatible = "ingenic,x1830-rtc", "ingenic,jz4780-rtc";
+   reg = <0x10003000 0x4c>;
+
+   interrupt-parent = <>;
+   interrupts = <32>;
+
+   clocks = < X1830_CLK_RTCLK>;
+   clock-names = "rtc";
+   };
+
+   pinctrl: pin-controller@1001 {
+   compatible = "ingenic,x1830-pinctrl";
+   reg = <0x1001 0x800>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   gpa: gpio@0 {
+   compatible = "ingenic,x1830-gpio";
+   reg = <0>;
+
+   gpio-controller;
+   gpio-ranges = < 0 0 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <17>;
+   };
+
+   gpb: gpio@1 {
+   compatible = "ingenic,x1830-gpio";
+   reg = <1>;
+
+   gpio-controller;
+   gpio-ranges = < 0 32 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <16>;
+   };
+
+   gpc: gpio@2 {
+   compatible = "ingenic,x1830-gpio";
+   reg = <2>;
+
+   gpio-controller;
+   gpio-ranges = < 0 64 32>;
+   #gpio-cells = <2>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   interrupt-parent = <>;
+   interrupts = <15>;
+   };
+
+ 

Re: [PATCH v4 1/2] Add DT bindings YAML schema for PWM fan controller of LGM SoC

[Tanwar, Rahul]

Hi Rob,

On 14/7/2020 12:46 am, Rob Herring wrote:
> On Tue, Jun 30, 2020 at 03:55:31PM +0800, Rahul Tanwar wrote:
>> Intel's LGM(Lightning Mountain) SoC contains a PWM fan controller
>> which is only used to control the fan attached to the system. This
>> PWM controller does not have any other consumer other than fan.
>> Add DT bindings documentation for this PWM fan controller.
>>
>> Signed-off-by: Rahul Tanwar 
>> ---
>>  .../devicetree/bindings/pwm/intel,lgm-pwm.yaml | 50 
>> ++
>>  1 file changed, 50 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml 
>> b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
>> new file mode 100644
>> index ..120bf3d85a24
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml
>> @@ -0,0 +1,50 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/pwm/intel,lgm-pwm.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: LGM SoC PWM fan controller
>> +
>> +maintainers:
>> +  - Rahul Tanwar 
>> +
>> +properties:
>> +  compatible:
>> +const: intel,lgm-pwm
>> +
>> +  reg:
>> +maxItems: 1
>> +
>> +  clocks:
>> +maxItems: 1
>> +
>> +  resets:
>> +maxItems: 1
>> +
>> +  intel,fan-wire:
>> +$ref: '/schemas/types.yaml#/definitions/uint32'
>> +description: Specifies fan mode. Default when unspecified is 2.
>> +
>> +  intel,max-rpm:
>> +$ref: '/schemas/types.yaml#/definitions/uint32'
>> +description:
>> +  Specifies maximum RPM of fan attached to the system.
>> +  Default when unspecified is 4000.
> These are properties of the fan, not the PWM. And probably if you 
> need these properties then others would too, so they should be 
> common. Look at the pwm-fan.txt binding.

I checked pwm-fan.txt. I don't find any common property which matches
our fan properties of fan wire mode & max-rpm. Are you suggesting to
add these properties additionally in pwm-fan.txt as new common properties
and then use newly added generic name in our driver?

Also, we have a dedicated PWM fan controller. So do you think this driver
belongs to drivers/hwmon instead of drivers/pwm? Thanks.

Regards,
Rahul 

Re: [PATCH v2] Since am437x have the same clock structure with am335x [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan probe failed on am437x platform.

[dillon min]

On Tue, Jul 14, 2020 at 11:54 AM Stephen Rothwell  wrote:
>
> Hi Dillon,
>
> On Tue, 14 Jul 2020 11:43:31 +0800 dillon min  wrote:
> >
> > On Tue, Jul 14, 2020 at 11:38 AM Stephen Rothwell  
> > wrote:
> > >
> > > On Tue, 14 Jul 2020 11:23:18 +0800 dillon.min...@gmail.com wrote:
> > > >
> > > > From: dillon min 
> > > >
> > > > Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during 
> > > > init to read revision")
> > > >
> > > > [1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
> > > > Integration
> > > > [2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
> > > > Integration
> > > > [3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on 
> > > > am335x")
> > > >
> > > > Signed-off-by: dillon min 
> > > > ---
> > > >
> > > > Hi Stephen,
> > > >
> > > > This changes correct commit messages based on your reviewing.
> > > > make Fixes tags to oneline.
> > > > make all commit message tags at the end of commit message
> > >
> > > But the Fixes: line should be down with the Signed-off-by: line ...
> > >
> > Ok, should it be like this，i will resubmit it.
> >
> > Subject: [PATCH v2] Since am437x have the same clock structure with am335x
> >  [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan
> >  probe failed on the am437x platform.
>
> You should have a shorter subject and maybe the above could be the
> first paragraph of the commit message.
>
> >
> > [1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
> > Integration
> > [2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
> > Integration
> > [3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on 
> > am335x")
> >
> > Signed-off-by: dillon min 
> > Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during
> > init to read revision")
>
> No wrapping the the Fixes line, please and it would usually go before
> your Signed=off-by line

Hi Stephen,

Thanks, how about the below commit message.

Subject: [PATCH v4] Fix dcan driver probe failed on am437x platform

Got following d_can probe errors with kernel 5.8-rc1 on am437x

[   10.730822] CAN device driver interface
Starting Wait for Network to be Configured...
[  OK  ] Reached target Network.
[   10.787363] c_can_platform 481cc000.can: probe failed
[   10.792484] c_can_platform: probe of 481cc000.can failed with
error -2
[   10.799457] c_can_platform 481d.can: probe failed
[   10.804617] c_can_platform: probe of 481d.can failed with
error -2

actually, Tony has fixed this issue on am335x with the patch [3]

Since am437x has the same clock structure with am335x
[1][2], so reuse the code from Tony Lindgren's patch [3] to fix it.


[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")

Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during
init to read revision")
Signed-off-by: dillon min 
---

Hi Stephen,

This changes correct commit messages based on your reviewing.
make Fixes tags to oneline.
make all commit message tags at the end of commit message
make Fixes tags before Signed-off-by line.
add probe failed log to commit message.


> --
> Cheers,
> Stephen Rothwell

Re: [PATCH 0/5] RFC: connector: Add network namespace awareness

[Matt Bennett]

On Tue, 2020-07-14 at 15:03 +1000, Aleksa Sarai wrote:
> On 2020-07-13, Eric W. Biederman  wrote:
> > Matt Bennett  writes:
> > 
> > > On Thu, 2020-07-02 at 21:10 +0200, Christian Brauner wrote:
> > > > On Thu, Jul 02, 2020 at 08:17:38AM -0500, Eric W. Biederman wrote:
> > > > > Matt Bennett  writes:
> > > > > 
> > > > > > Previously the connector functionality could only be used by 
> > > > > > processes running in the
> > > > > > default network namespace. This meant that any process that uses 
> > > > > > the connector functionality
> > > > > > could not operate correctly when run inside a container. This is a 
> > > > > > draft patch series that
> > > > > > attempts to now allow this functionality outside of the default 
> > > > > > network namespace.
> > > > > > 
> > > > > > I see this has been discussed previously [1], but am not sure how 
> > > > > > my changes relate to all
> > > > > > of the topics discussed there and/or if there are any unintended 
> > > > > > side effects from my draft
> > > > > > changes.
> > > > > 
> > > > > Is there a piece of software that uses connector that you want to get
> > > > > working in containers?
> > > 
> > > We have an IPC system [1] where processes can register their socket
> > > details (unix, tcp, tipc, ...) to a 'monitor' process. Processes can
> > > then get notified when other processes they are interested in
> > > start/stop their servers and use the registered details to connect to
> > > them. Everything works unless a process crashes, in which case the
> > > monitoring process never removes their details. Therefore the
> > > monitoring process uses the connector functionality with
> > > PROC_EVENT_EXIT to detect when a process crashes and removes the
> > > details if it is a previously registered PID.
> > > 
> > > This was working for us until we tried to run our system in a container.
> > > 
> > > > > 
> > > > > I am curious what the motivation is because up until now there has 
> > > > > been
> > > > > nothing very interesting using this functionality.  So it hasn't been
> > > > > worth anyone's time to make the necessary changes to the code.
> > > > 
> > > > Imho, we should just state once and for all that the proc connector will
> > > > not be namespaced. This is such a corner-case thing and has been
> > > > non-namespaced for such a long time without consistent push for it to be
> > > > namespaced combined with the fact that this needs quite some code to
> > > > make it work correctly that I fear we end up buying more bugs than we're
> > > > selling features. And realistically, you and I will end up maintaining
> > > > this and I feel this is not worth the time(?). Maybe I'm being too
> > > > pessimistic though.
> > > > 
> > > 
> > > Fair enough. I can certainly look for another way to detect process
> > > crashes. Interestingly I found a patch set [2] on the mailing list
> > > that attempts to solve the problem I wish to solve, but it doesn't
> > > look like the patches were ever developed further. From reading the
> > > discussion thread on that patch set it appears that I should be doing
> > > some form of polling on the /proc files.
> > 
> > Recently Christian Brauner implemented pidfd complete with a poll
> > operation that reports when a process terminates.
> > 
> > If you are willing to change your userspace code switching to pidfd
> > should be all that you need.
> 
> While this does solve the problem of getting exit notifications in
> general, you cannot get the exit code. But if they don't care about that
> then we can solve that problem another time. :D
> 

From first glance using pidfd will do exactly what we need. Not being able
to get the exit code will not be an issue. In fact I think it will be an
improvement over the connector as the listener will now only be waiting for
the PIDs we actually care about - rather than getting woken up on every single
process exit and having to check if it cares about the PID.

Many thanks Eric and others,
Matt

Re: [PATCHv3 3/4] watchdog: rti-wdt: attach to running watchdog during probe

[Guenter Roeck]

On 7/13/20 6:18 AM, Tero Kristo wrote:
> If the RTI watchdog is running already during probe, the driver must
> configure itself to match the HW. Window size and timeout is probed from
> hardware, and the last keepalive ping is adjusted to match it also.
> 
> Signed-off-by: Tero Kristo 
> ---
>  drivers/watchdog/rti_wdt.c | 111 +
>  1 file changed, 101 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/watchdog/rti_wdt.c b/drivers/watchdog/rti_wdt.c
> index d456dd72d99a..45dfc546e371 100644
> --- a/drivers/watchdog/rti_wdt.c
> +++ b/drivers/watchdog/rti_wdt.c
> @@ -35,7 +35,11 @@
>  
>  #define RTIWWDRX_NMI 0xa
>  
> -#define RTIWWDSIZE_50P   0x50
> +#define RTIWWDSIZE_50P   0x50
> +#define RTIWWDSIZE_25P   0x500
> +#define RTIWWDSIZE_12P5  0x5000
> +#define RTIWWDSIZE_6P25  0x5
> +#define RTIWWDSIZE_3P125 0x50
>  
>  #define WDENABLE_KEY 0xa98559da
>  
> @@ -48,7 +52,7 @@
>  
>  #define DWDSTBIT(1)
>  
> -static int heartbeat;
> +static int heartbeat = DEFAULT_HEARTBEAT;
>  
>  /*
>   * struct to hold data for each WDT device
> @@ -79,11 +83,9 @@ static int rti_wdt_start(struct watchdog_device *wdd)
>* be petted during the open window; not too early or not too late.
>* The HW configuration options only allow for the open window size
>* to be 50% or less than that; we obviouly want to configure the open
> -  * window as large as possible so we select the 50% option. To avoid
> -  * any glitches, we accommodate 5% safety margin also, so we setup
> -  * the min_hw_hearbeat at 55% of the timeout period.
> +  * window as large as possible so we select the 50% option.
>*/
> - wdd->min_hw_heartbeat_ms = 11 * wdd->timeout * 1000 / 20;
> + wdd->min_hw_heartbeat_ms = 500 * wdd->timeout;
>  
>   /* Generate NMI when wdt expires */
>   writel_relaxed(RTIWWDRX_NMI, wdt->base + RTIWWDRXCTRL);
> @@ -110,7 +112,48 @@ static int rti_wdt_ping(struct watchdog_device *wdd)
>   return 0;
>  }
>  
> -static unsigned int rti_wdt_get_timeleft(struct watchdog_device *wdd)
> +static int rti_wdt_setup_hw_hb(struct watchdog_device *wdd, u32 wsize)
> +{
> + /*
> +  * RTI only supports a windowed mode, where the watchdog can only
> +  * be petted during the open window; not too early or not too late.
> +  * The HW configuration options only allow for the open window size
> +  * to be 50% or less than that.
> +  */
> + switch (wsize) {
> + case RTIWWDSIZE_50P:
> + /* 50% open window => 50% min heartbeat */
> + wdd->min_hw_heartbeat_ms = 500 * heartbeat;
> + break;
> +
> + case RTIWWDSIZE_25P:
> + /* 25% open window => 75% min heartbeat */
> + wdd->min_hw_heartbeat_ms = 750 * heartbeat;
> + break;
> +
> + case RTIWWDSIZE_12P5:
> + /* 12.5% open window => 87.5% min heartbeat */
> + wdd->min_hw_heartbeat_ms = 875 * heartbeat;
> + break;
> +
> + case RTIWWDSIZE_6P25:
> + /* 6.5% open window => 93.5% min heartbeat */
> + wdd->min_hw_heartbeat_ms = 935 * heartbeat;
> + break;
> +
> + case RTIWWDSIZE_3P125:
> + /* 3.125% open window => 96.9% min heartbeat */
> + wdd->min_hw_heartbeat_ms = 969 * heartbeat;
> + break;
> +
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static unsigned int rti_wdt_get_timeleft_ms(struct watchdog_device *wdd)
>  {
>   u64 timer_counter;
>   u32 val;
> @@ -123,11 +166,18 @@ static unsigned int rti_wdt_get_timeleft(struct 
> watchdog_device *wdd)
>  
>   timer_counter = readl_relaxed(wdt->base + RTIDWDCNTR);
>  
> + timer_counter *= 1000;
> +
>   do_div(timer_counter, wdt->freq);
>  
>   return timer_counter;
>  }
>  
> +static unsigned int rti_wdt_get_timeleft(struct watchdog_device *wdd)
> +{
> + return rti_wdt_get_timeleft_ms(wdd) / 1000;
> +}
> +
>  static const struct watchdog_info rti_wdt_info = {
>   .options = WDIOF_KEEPALIVEPING,
>   .identity = "K3 RTI Watchdog",
> @@ -148,6 +198,7 @@ static int rti_wdt_probe(struct platform_device *pdev)
>   struct watchdog_device *wdd;
>   struct rti_wdt_device *wdt;
>   struct clk *clk;
> + u32 last_ping = 0;
>  
>   wdt = devm_kzalloc(dev, sizeof(*wdt), GFP_KERNEL);
>   if (!wdt)
> @@ -169,6 +220,14 @@ static int rti_wdt_probe(struct platform_device *pdev)
>   return -EINVAL;
>   }
>  
> + /*
> +  * If watchdog is running at 32k clock, it is not accurate.
> +  * Adjust frequency down in this case so that we don't pet
> +  * the watchdog too often.
> +  */
> + if (wdt->freq < 32768)
> + wdt->freq = wdt->freq * 9 / 10;
> +

So this is now only a problem is the window size was set restrictively
in 

Re: [PATCH] ocfs2: Replace HTTP links with HTTPS ones

[Joseph Qi]

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

Acked-by: Joseph Qi 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely or at least not just 
> HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  Documentation/filesystems/dlmfs.rst | 2 +-
>  Documentation/filesystems/ocfs2.rst | 2 +-
>  fs/ocfs2/Kconfig| 6 +++---
>  fs/ocfs2/blockcheck.c   | 2 +-
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/Documentation/filesystems/dlmfs.rst 
> b/Documentation/filesystems/dlmfs.rst
> index 68daaa7facf9..28dd41a63be2 100644
> --- a/Documentation/filesystems/dlmfs.rst
> +++ b/Documentation/filesystems/dlmfs.rst
> @@ -12,7 +12,7 @@ dlmfs is built with OCFS2 as it requires most of its 
> infrastructure.
>  
>  :Project web page:http://ocfs2.wiki.kernel.org
>  :Tools web page:  https://github.com/markfasheh/ocfs2-tools
> -:OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/
> +:OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
>  
>  All code copyright 2005 Oracle except when otherwise noted.
>  
> diff --git a/Documentation/filesystems/ocfs2.rst 
> b/Documentation/filesystems/ocfs2.rst
> index 412386bc6506..42ca9a3d4c6e 100644
> --- a/Documentation/filesystems/ocfs2.rst
> +++ b/Documentation/filesystems/ocfs2.rst
> @@ -14,7 +14,7 @@ get "mount.ocfs2" and "ocfs2_hb_ctl".
>  
>  Project web page:http://ocfs2.wiki.kernel.org
>  Tools git tree:  https://github.com/markfasheh/ocfs2-tools
> -OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/
> +OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
>  
>  All code copyright 2005 Oracle except when otherwise noted.
>  
> diff --git a/fs/ocfs2/Kconfig b/fs/ocfs2/Kconfig
> index aca16624b370..5d11380d8724 100644
> --- a/fs/ocfs2/Kconfig
> +++ b/fs/ocfs2/Kconfig
> @@ -16,9 +16,9 @@ config OCFS2_FS
> You'll want to install the ocfs2-tools package in order to at least
> get "mount.ocfs2".
>  
> -   Project web page:http://oss.oracle.com/projects/ocfs2
> -   Tools web page:  http://oss.oracle.com/projects/ocfs2-tools
> -   OCFS2 mailing lists: http://oss.oracle.com/projects/ocfs2/mailman/
> +   Project web page:https://oss.oracle.com/projects/ocfs2
> +   Tools web page:  https://oss.oracle.com/projects/ocfs2-tools
> +   OCFS2 mailing lists: https://oss.oracle.com/projects/ocfs2/mailman/
>  
> For more information on OCFS2, see the file
> .
> diff --git a/fs/ocfs2/blockcheck.c b/fs/ocfs2/blockcheck.c
> index eaf042feaf5e..6e07ddb0e3c0 100644
> --- a/fs/ocfs2/blockcheck.c
> +++ b/fs/ocfs2/blockcheck.c
> @@ -124,7 +124,7 @@ u32 ocfs2_hamming_encode(u32 parity, void *data, unsigned 
> int d, unsigned int nr
>* parity bits that are part of the bit number
>* representation.  Huh?
>*
> -  * http://en.wikipedia.org/wiki/Hamming_code;>
> +  * https://en.wikipedia.org/wiki/Hamming_code;>
>* In other words, the parity bit at position 2^k
>* checks bits in positions having bit k set in
>* their binary representation.  Conversely, for
> 

procfs VmFlags table missing from online docs

[Chris Packham]

Hi,

I was just browsing 
https://www.kernel.org/doc/html/latest/filesystems/proc.html

The "VmFlags" description seems to be missing a table. It's there in 
Documentation/filesystems/proc.rst so I assume it's some sphinx/rst 
problem. Possibly the table is over indented?

Anyway I thought I'd let someone know.

Regards,
Chris

[PATCH] iio: adc: ad7124: move chip ID & name on the chip_info table

[Alexandru Ardelean]

This change does the following:
* removes the SPI device table in favor of the OF device table
* adds 'name' && 'chip_id' fields to chip_info
* implements chip ID & silicon revision checking; the device ID for
  AD7124-4 is 0x0, so just checking that value can be useless;
  but at least the silicon revision isn't 0, so a non-zero value can be
  used to check that "a" device is on the SPI bus; it's probably the best
  way to narrow it down to one of the 2 AD7124 chip IDs

Signed-off-by: Alexandru Ardelean 
---
 drivers/iio/adc/ad7124.c | 73 
 1 file changed, 59 insertions(+), 14 deletions(-)

diff --git a/drivers/iio/adc/ad7124.c b/drivers/iio/adc/ad7124.c
index bb53ab265b64..8dce06e9e69c 100644
--- a/drivers/iio/adc/ad7124.c
+++ b/drivers/iio/adc/ad7124.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -47,6 +48,15 @@
 #define AD7124_ADC_CTRL_MODE_MSK   GENMASK(5, 2)
 #define AD7124_ADC_CTRL_MODE(x)FIELD_PREP(AD7124_ADC_CTRL_MODE_MSK, x)
 
+/* AD7124 ID */
+#define AD7124_DEVICE_ID_MSK   GENMASK(7, 4)
+#define AD7124_DEVICE_ID_GET(x)FIELD_GET(AD7124_DEVICE_ID_MSK, 
x)
+#define AD7124_SILICON_REV_MSK GENMASK(3, 0)
+#define AD7124_SILICON_REV_GET(x)  FIELD_GET(AD7124_SILICON_REV_MSK, x)
+
+#define CHIPID_AD7124_40x0
+#define CHIPID_AD7124_80x1
+
 /* AD7124_CHANNEL_X */
 #define AD7124_CHANNEL_EN_MSK  BIT(15)
 #define AD7124_CHANNEL_EN(x)   FIELD_PREP(AD7124_CHANNEL_EN_MSK, x)
@@ -120,6 +130,8 @@ static const char * const ad7124_ref_names[] = {
 };
 
 struct ad7124_chip_info {
+   const char *name;
+   unsigned int chip_id;
unsigned int num_inputs;
 };
 
@@ -165,9 +177,13 @@ static const struct iio_chan_spec ad7124_channel_template 
= {
 
 static struct ad7124_chip_info ad7124_chip_info_tbl[] = {
[ID_AD7124_4] = {
+   .name = "ad7127-4",
+   .chip_id = CHIPID_AD7124_4,
.num_inputs = 8,
},
[ID_AD7124_8] = {
+   .name = "ad7127-8",
+   .chip_id = CHIPID_AD7124_8,
.num_inputs = 16,
},
 };
@@ -503,6 +519,34 @@ static int ad7124_soft_reset(struct ad7124_state *st)
return -EIO;
 }
 
+static int ad7124_check_chip_id(struct ad7124_state *st)
+{
+   unsigned int readval, chip_id, silicon_rev;
+   int ret;
+
+   ret = ad_sd_read_reg(>sd, AD7124_ID, 1, );
+   if (ret < 0)
+   return ret;
+
+   chip_id = AD7124_DEVICE_ID_GET(readval);
+   silicon_rev = AD7124_SILICON_REV_GET(readval);
+
+   if (chip_id != st->chip_info->chip_id) {
+   dev_err(>sd.spi->dev,
+   "Chip ID mismatch: expected %u, got %u\n",
+   st->chip_info->chip_id, chip_id);
+   return -ENODEV;
+   }
+
+   if (silicon_rev == 0) {
+   dev_err(>sd.spi->dev,
+   "Silicon revision empty. Chip may not be present\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
 static int ad7124_init_channel_vref(struct ad7124_state *st,
unsigned int channel_number)
 {
@@ -665,25 +709,28 @@ static int ad7124_setup(struct ad7124_state *st)
 
 static int ad7124_probe(struct spi_device *spi)
 {
-   const struct spi_device_id *id;
+   const struct ad7124_chip_info *info;
struct ad7124_state *st;
struct iio_dev *indio_dev;
int i, ret;
 
+   info = of_device_get_match_data(>dev);
+   if (!info)
+   return -ENODEV;
+
indio_dev = devm_iio_device_alloc(>dev, sizeof(*st));
if (!indio_dev)
return -ENOMEM;
 
st = iio_priv(indio_dev);
 
-   id = spi_get_device_id(spi);
-   st->chip_info = _chip_info_tbl[id->driver_data];
+   st->chip_info = info;
 
ad_sd_init(>sd, indio_dev, spi, _sigma_delta_info);
 
spi_set_drvdata(spi, indio_dev);
 
-   indio_dev->name = spi_get_device_id(spi)->name;
+   indio_dev->name = st->chip_info->name;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = _info;
 
@@ -721,6 +768,10 @@ static int ad7124_probe(struct spi_device *spi)
if (ret < 0)
goto error_clk_disable_unprepare;
 
+   ret = ad7124_check_chip_id(st);
+   if (ret)
+   goto error_clk_disable_unprepare;
+
ret = ad7124_setup(st);
if (ret < 0)
goto error_clk_disable_unprepare;
@@ -768,16 +819,11 @@ static int ad7124_remove(struct spi_device *spi)
return 0;
 }
 
-static const struct spi_device_id ad7124_id_table[] = {
-   { "ad7124-4", ID_AD7124_4 },
-   { "ad7124-8", ID_AD7124_8 },
-   {}
-};
-MODULE_DEVICE_TABLE(spi, ad7124_id_table);
-
 static const struct of_device_id ad7124_of_match[] = {
-   { .compatible = "adi,ad7124-4" },
-   { 

Re: [PATCH 0/5] RFC: connector: Add network namespace awareness

[Aleksa Sarai]

On 2020-07-13, Eric W. Biederman  wrote:
> Matt Bennett  writes:
> 
> > On Thu, 2020-07-02 at 21:10 +0200, Christian Brauner wrote:
> >> On Thu, Jul 02, 2020 at 08:17:38AM -0500, Eric W. Biederman wrote:
> >> > Matt Bennett  writes:
> >> > 
> >> > > Previously the connector functionality could only be used by processes 
> >> > > running in the
> >> > > default network namespace. This meant that any process that uses the 
> >> > > connector functionality
> >> > > could not operate correctly when run inside a container. This is a 
> >> > > draft patch series that
> >> > > attempts to now allow this functionality outside of the default 
> >> > > network namespace.
> >> > > 
> >> > > I see this has been discussed previously [1], but am not sure how my 
> >> > > changes relate to all
> >> > > of the topics discussed there and/or if there are any unintended side 
> >> > > effects from my draft
> >> > > changes.
> >> > 
> >> > Is there a piece of software that uses connector that you want to get
> >> > working in containers?
> >
> > We have an IPC system [1] where processes can register their socket
> > details (unix, tcp, tipc, ...) to a 'monitor' process. Processes can
> > then get notified when other processes they are interested in
> > start/stop their servers and use the registered details to connect to
> > them. Everything works unless a process crashes, in which case the
> > monitoring process never removes their details. Therefore the
> > monitoring process uses the connector functionality with
> > PROC_EVENT_EXIT to detect when a process crashes and removes the
> > details if it is a previously registered PID.
> >
> > This was working for us until we tried to run our system in a container.
> >
> >> > 
> >> > I am curious what the motivation is because up until now there has been
> >> > nothing very interesting using this functionality.  So it hasn't been
> >> > worth anyone's time to make the necessary changes to the code.
> >> 
> >> Imho, we should just state once and for all that the proc connector will
> >> not be namespaced. This is such a corner-case thing and has been
> >> non-namespaced for such a long time without consistent push for it to be
> >> namespaced combined with the fact that this needs quite some code to
> >> make it work correctly that I fear we end up buying more bugs than we're
> >> selling features. And realistically, you and I will end up maintaining
> >> this and I feel this is not worth the time(?). Maybe I'm being too
> >> pessimistic though.
> >> 
> >
> > Fair enough. I can certainly look for another way to detect process
> > crashes. Interestingly I found a patch set [2] on the mailing list
> > that attempts to solve the problem I wish to solve, but it doesn't
> > look like the patches were ever developed further. From reading the
> > discussion thread on that patch set it appears that I should be doing
> > some form of polling on the /proc files.
> 
> Recently Christian Brauner implemented pidfd complete with a poll
> operation that reports when a process terminates.
> 
> If you are willing to change your userspace code switching to pidfd
> should be all that you need.

While this does solve the problem of getting exit notifications in
general, you cannot get the exit code. But if they don't care about that
then we can solve that problem another time. :D

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH



signature.asc
Description: PGP signature

Re: [RFC PATCH 7/7] lazy tlb: shoot lazies, a non-refcounting lazy tlb option

[Nicholas Piggin]

Excerpts from Andy Lutomirski's message of July 14, 2020 4:18 am:
> 
>> On Jul 13, 2020, at 9:48 AM, Nicholas Piggin  wrote:
>> 
>> Excerpts from Andy Lutomirski's message of July 14, 2020 1:59 am:
 On Thu, Jul 9, 2020 at 6:57 PM Nicholas Piggin  wrote:
 
 On big systems, the mm refcount can become highly contented when doing
 a lot of context switching with threaded applications (particularly
 switching between the idle thread and an application thread).
 
 Abandoning lazy tlb slows switching down quite a bit in the important
 user->idle->user cases, so so instead implement a non-refcounted scheme
 that causes __mmdrop() to IPI all CPUs in the mm_cpumask and shoot down
 any remaining lazy ones.
 
 On a 16-socket 192-core POWER8 system, a context switching benchmark
 with as many software threads as CPUs (so each switch will go in and
 out of idle), upstream can achieve a rate of about 1 million context
 switches per second. After this patch it goes up to 118 million.
 
>>> 
>>> I read the patch a couple of times, and I have a suggestion that could
>>> be nonsense.  You are, effectively, using mm_cpumask() as a sort of
>>> refcount.  You're saying "hey, this mm has no more references, but it
>>> still has nonempty mm_cpumask(), so let's send an IPI and shoot down
>>> those references too."  I'm wondering whether you actually need the
>>> IPI.  What if, instead, you actually treated mm_cpumask as a refcount
>>> for real?  Roughly, in __mmdrop(), you would only free the page tables
>>> if mm_cpumask() is empty.  And, in the code that removes a CPU from
>>> mm_cpumask(), you would check if mm_users == 0 and, if so, check if
>>> you just removed the last bit from mm_cpumask and potentially free the
>>> mm.
>>> 
>>> Getting the locking right here could be a bit tricky -- you need to
>>> avoid two CPUs simultaneously exiting lazy TLB and thinking they
>>> should free the mm, and you also need to avoid an mm with mm_users
>>> hitting zero concurrently with the last remote CPU using it lazily
>>> exiting lazy TLB.  Perhaps this could be resolved by having mm_count
>>> == 1 mean "mm_cpumask() is might contain bits and, if so, it owns the
>>> mm" and mm_count == 0 meaning "now it's dead" and using some careful
>>> cmpxchg or dec_return to make sure that only one CPU frees it.
>>> 
>>> Or maybe you'd need a lock or RCU for this, but the idea would be to
>>> only ever take the lock after mm_users goes to zero.
>> 
>> I don't think it's nonsense, it could be a good way to avoid IPIs.
>> 
>> I haven't seen much problem here that made me too concerned about IPIs 
>> yet, so I think the simple patch may be good enough to start with
>> for powerpc. I'm looking at avoiding/reducing the IPIs by combining the
>> unlazying with the exit TLB flush without doing anything fancy with
>> ref counting, but we'll see.
> 
> I would be cautious with benchmarking here. I would expect that the
> nasty cases may affect power consumption more than performance — the 
> specific issue is IPIs hitting idle cores, and the main effects are to 
> slow down exit() a bit but also to kick the idle core out of idle. 
> Although, if the idle core is in a deep sleep, that IPI could be 
> *very* slow.

It will tend to be self-limiting to some degree (deeper idle cores
would tend to have less chance of IPI) but we have bigger issues on
powerpc with that, like broadcast IPIs to the mm cpumask for THP
management. Power hasn't really shown up as an issue but powerpc
CPUs may have their own requirements and issues there, shall we say.

> So I think it’s worth at least giving this a try.

To be clear it's not a complete solution itself. The problem is of 
course that mm cpumask gives you false negatives, so the bits
won't always clean up after themselves as CPUs switch away from their
lazy tlb mms.

I would suspect it _may_ help with garbage collecting some remainders
nicely after exit, but only with somewhat of a different accounting
system than powerpc uses -- we tie mm_cpumask to TLB valids, so it can
become spread over CPUs that don't (and even have never) used that mm
as a lazy mm I don't know that the self-culling trick would help
a great deal within that scheme.

So powerpc needs a bit more work on that side of things too, hence
looking at doing more of this in the final TLB shootdown.

There's actually a lot of other things we can do as well to reduce
IPIs, batching being a simple hammer, some kind of quiescing, testing
the remote CPU to check what active mm it is using, doing the un-lazy
at certain defined points etc, so I'm actually not worried about IPIs
suddenly popping up and rendering the whole concept unworkable. At
some point (unless we go something pretty complex like a SRCU type 
thing, or adding extra locking .e.g, to use_mm()), then at least 
sometimes an IPI will be required so I think it's reasonable to
start here and introduce complexity more slowly if it's justified.

Re: [RFC PATCH 17/35] hwmon: (sis5595) Tidy Success/Failure checks

[Guenter Roeck]

On 7/13/20 5:22 AM, Saheed O. Bolarinwa wrote:
> Remove unnecessary check for 0.
> 
> Signed-off-by: "Saheed O. Bolarinwa" 
> ---
> This patch depends on PATCH 16/35
> 
>  drivers/hwmon/sis5595.c | 13 -
>  drivers/hwmon/via686a.c | 13 -
>  drivers/hwmon/vt8231.c  | 13 -
>  3 files changed, 12 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/hwmon/sis5595.c b/drivers/hwmon/sis5595.c
> index 0ea174fb3048..91fdddaa4136 100644
> --- a/drivers/hwmon/sis5595.c
> +++ b/drivers/hwmon/sis5595.c
> @@ -825,8 +825,7 @@ static int sis5595_pci_probe(struct pci_dev *dev,
>   pci_write_config_word(dev, SIS5595_BASE_REG, force_addr);
>   }
>  
> - if (0 !=
> - pci_read_config_word(dev, SIS5595_BASE_REG, )) {
> + if (pci_read_config_word(dev, SIS5595_BASE_REG, )) {

Ah, there is is, and I see that others commented on it.
Single patch, please.

Guenter

Re: [RFC PATCH 16/35] hwmon: (sis5595) Change PCIBIOS_SUCCESSFUL to 0

[Guenter Roeck]

On 7/13/20 5:22 AM, Saheed O. Bolarinwa wrote:
> In reference to the PCI spec (Chapter 2), PCIBIOS* is an x86 concept.
> Their scope should be limited within arch/x86.
> 
> Change all PCIBIOS_SUCCESSFUL to 0
> 
> Signed-off-by: "Saheed O. Bolarinwa" 
> ---
>  drivers/hwmon/sis5595.c | 8 
>  drivers/hwmon/via686a.c | 8 
>  drivers/hwmon/vt8231.c  | 8 
>  3 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/hwmon/sis5595.c b/drivers/hwmon/sis5595.c
> index 0c6741f949f5..0ea174fb3048 100644
> --- a/drivers/hwmon/sis5595.c
> +++ b/drivers/hwmon/sis5595.c
> @@ -825,7 +825,7 @@ static int sis5595_pci_probe(struct pci_dev *dev,
>   pci_write_config_word(dev, SIS5595_BASE_REG, force_addr);
>   }
>  
> - if (PCIBIOS_SUCCESSFUL !=
> + if (0 !=
>   pci_read_config_word(dev, SIS5595_BASE_REG, )) {

Yoda programming already terrible is, but "0 !=" is even worse than that
(and completely unnecessary). If you want to clean this up, do it right
and drop those unnecessary comparisons.

Guenter

Re: [PATCH][next] scsi: cxgb4i: fix dereference of pointer tdata before it is null checked

[Martin K. Petersen]

On Thu, 9 Jul 2020 14:52:17 +0100, Colin King wrote:

> Currently pointer tdata is being dereferenced on the initialization of
> pointer skb before tdata is null checked. This could lead to a potential
> null pointer dereference.  Fix this by dereferencing tdata after tdata
> has been null pointer sanity checked.

Applied to 5.9/scsi-queue, thanks!

[1/1] scsi: cxgb4i: Fix dereference of pointer tdata before it is null checked
  https://git.kernel.org/mkp/scsi/c/b92a4a9f7be8

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] scsi: virtio_scsi: remove unnecessary condition check

[Martin K. Petersen]

On Thu, 9 Jul 2020 11:06:07 -0400, Xianting Tian wrote:

> kmem_cache_destroy and mempool_destroy can correctly handle
> null pointer parameter, so there is no need to check if the
> parameter is null before calling kmem_cache_destroy and
> mempool_destroy.

Applied to 5.9/scsi-queue, thanks!

[1/1] scsi: virtio_scsi: Remove unnecessary condition check
  https://git.kernel.org/mkp/scsi/c/92e8d0323a51

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v1 0/2] scsi: ufs: Fix and simplify setup_xfer_req vop and request's completion timestamp

[Martin K. Petersen]

On Mon, 6 Jul 2020 14:07:05 +0800, Stanley Chu wrote:

> This small series fixes and simplifies setup_xfer_req vop and request's 
> completion timestamp.
> 
> Stanley Chu (2):
>   scsi: ufs: Simplify completion timestamp for SCSI and query commands
>   scsi: ufs: Fix and simplify setup_xfer_req variant operation
> 
>  drivers/scsi/ufs/ufshcd.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Applied to 5.9/scsi-queue, thanks!

[1/2] scsi: ufs: Simplify completion timestamp for SCSI and query commands
  https://git.kernel.org/mkp/scsi/c/a3170376f7db
[2/2] scsi: ufs: Fix and simplify setup_xfer_req variant operation
  https://git.kernel.org/mkp/scsi/c/6edfdcfe285e

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v3] scsi: ufs-mediatek: Add inline encryption support

[Martin K. Petersen]

On Sun, 12 Jul 2020 08:32:26 +0800, Stanley Chu wrote:

> Add inline encryption support to ufs-mediatek.
> 
> The standards-compliant parts, such as querying the crypto capabilities
> and enabling crypto for individual UFS requests, are already handled by
> ufshcd-crypto.c, which itself is wired into the blk-crypto framework.
> 
> However MediaTek UFS host requires a vendor-specific hce_enable operation
> to allow crypto-related registers being accessed normally in kernel.
> After this step, MediaTek UFS host can work as standard-compliant host
> for inline-encryption related functions.

Applied to 5.9/scsi-queue, thanks!

[1/1] scsi: ufs-mediatek: Add inline encryption support
  https://git.kernel.org/mkp/scsi/c/46426552e74f

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH 0/2] hisi_sas: A couple of misc patches

[Martin K. Petersen]

On Mon, 13 Jul 2020 16:04:29 +0800, John Garry wrote:

> Includes a patch to speed up error handling and a kerneldoc clean-up.
> 
> John Garry (1):
>   scsi: hisi_sas: Remove one kerneldoc comment
> 
> Luo Jiaxing (1):
>   scsi: hisi_sas: Directly trigger SCSI error handling for completion
> errors
> 
> [...]

Applied to 5.9/scsi-queue, thanks!

[1/2] scsi: hisi_sas: Directly trigger SCSI error handling for completion errors
  https://git.kernel.org/mkp/scsi/c/05d91b557af9
[2/2] scsi: hisi_sas: Remove one kerneldoc comment
  https://git.kernel.org/mkp/scsi/c/3d570a28ee8d

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH v4 1/5] docs: IOMMU user API

[Jacob Pan]

Hi Alex,

On Mon, 13 Jul 2020 16:48:42 -0600
Alex Williamson  wrote:

> On Tue,  7 Jul 2020 16:43:45 -0700
> Jacob Pan  wrote:
> 
> > IOMMU UAPI is newly introduced to support communications between
> > guest virtual IOMMU and host IOMMU. There has been lots of
> > discussions on how it should work with VFIO UAPI and userspace in
> > general.
> > 
> > This document is indended to clarify the UAPI design and usage. The
> > mechenics of how future extensions should be achieved are also
> > covered  
> 
> mechanics
> 
will fix.

> > in this documentation.
> > 
> > Signed-off-by: Liu Yi L 
> > Signed-off-by: Jacob Pan 
> > ---
> >  Documentation/userspace-api/iommu.rst | 312
> > ++ 1 file changed, 312 insertions(+)
> >  create mode 100644 Documentation/userspace-api/iommu.rst
> > 
> > diff --git a/Documentation/userspace-api/iommu.rst
> > b/Documentation/userspace-api/iommu.rst new file mode 100644
> > index ..581b462c2cec
> > --- /dev/null
> > +++ b/Documentation/userspace-api/iommu.rst
> > @@ -0,0 +1,312 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +.. iommu:
> > +
> > +=
> > +IOMMU Userspace API
> > +=
> > +
> > +IOMMU UAPI is used for virtualization cases where communications
> > are +needed between physical and virtual IOMMU drivers. For native
> > +usage, IOMMU is a system device which does not need to communicate
> > +with user space directly.
> > +
> > +The primary use cases are guest Shared Virtual Address (SVA) and
> > +guest IO virtual address (IOVA), wherein a virtual IOMMU (vIOMMU)
> > is +required to communicate with the physical IOMMU in the host.
> > +
> > +.. contents:: :local:
> > +
> > +Functionalities
> > +===
> > +Communications of user and kernel involve both directions. The
> > +supported user-kernel APIs are as follows:
> > +
> > +1. Alloc/Free PASID
> > +2. Bind/unbind guest PASID (e.g. Intel VT-d)
> > +3. Bind/unbind guest PASID table (e.g. ARM sMMU)
> > +4. Invalidate IOMMU caches
> > +5. Service page requests
> > +
> > +Requirements
> > +
> > +The IOMMU UAPIs are generic and extensible to meet the following
> > +requirements:
> > +
> > +1. Emulated and para-virtualised vIOMMUs
> > +2. Multiple vendors (Intel VT-d, ARM sMMU, etc.)
> > +3. Extensions to the UAPI shall not break existing user space
> > +
> > +Interfaces
> > +==
> > +Although the data structures defined in IOMMU UAPI are
> > self-contained, +there is no user API functions introduced.
> > Instead, IOMMU UAPI is +designed to work with existing user driver
> > frameworks such as VFIO. +
> > +Extension Rules & Precautions
> > +-
> > +When IOMMU UAPI gets extended, the data structures can *only* be
> > +modified in two ways:
> > +
> > +1. Adding new fields by re-purposing the padding[] field. No size
> > change. +2. Adding new union members at the end. May increase in
> > size. +
> > +No new fields can be added *after* the variable sized union in
> > that it +will break backward compatibility when offset moves. In
> > both cases, a +new flag must be accompanied with a new field such
> > that the IOMMU +driver can process the data based on the new flag.
> > Version field is +only reserved for the unlikely event of UAPI
> > upgrade at its entirety. +
> > +It's *always* the caller's responsibility to indicate the size of
> > the +structure passed by setting argsz appropriately.
> > +Though at the same time, argsz is user provided data which is not
> > +trusted. The argsz field allows the user to indicate how much data
> > +they're providing, it's still the kernel's responsibility to
> > validate +whether it's correct and sufficient for the requested
> > operation. +
> > +Compatibility Checking
> > +--
> > +When IOMMU UAPI extension results in size increase, user such as
> > VFIO +has to handle the following cases:
> > +
> > +1. User and kernel has exact size match
> > +2. An older user with older kernel header (smaller UAPI size)
> > running on a
> > +   newer kernel (larger UAPI size)
> > +3. A newer user with newer kernel header (larger UAPI size) running
> > +   on an older kernel.
> > +4. A malicious/misbehaving user pass illegal/invalid size but
> > within
> > +   range. The data may contain garbage.  
> 
> I'm still not sure where VFIO has responsibility in managing any of
> these cases.  I think we've determined that VFIO is just the wrapper
> and call-through mechanism, it's the UAPI core implementation and
> IOMMU drivers that are responsible for this.
> 
That is right, I shall rewrite the responsibility to be held by IOMMU
core.
"When IOMMU UAPI extension results in size increase, IOMMU UAPI core
shall handle the following cases:"

> > +
> > +Feature Checking
> > +
> > +While launching a guest with vIOMMU, it is important to ensure
> > that host +can support the UAPI data structures to be used for
> > 

Re: [PATCH v3 4/6] powerpc/pseries/iommu: Remove default DMA window before creating DDW

[Alexey Kardashevskiy]

On 14/07/2020 12:40, Leonardo Bras wrote:
> Thank you for this feedback Alexey!
> 
> On Mon, 2020-07-13 at 17:33 +1000, Alexey Kardashevskiy wrote:
>> [...]
>>> -   int len, ret;
>>> +   int len, ret, reset_win_ext;
>>
>> Make it "reset_token".
> 
> Oh, it's not a token here, it just checks if the reset_win extension
> exists. The token would be returned in *value, but since we did not
> need it here, it's not copied.

ah right, so it is a bool actually.


> 
>>> [...]
>>> -out_failed:
>>> +out_restore_defwin:
>>> +   if (default_win && reset_win_ext == 0)
>>
>> reset_win_ext potentially may be uninitialized here. Yeah I know it is
>> tied to default_win but still.
> 
> I can't see it being used uninitialized here, as you said it's tied to
> default_win. 

Where it is declared - it is not initialized so in theory it can skip
"if (query.windows_available == 0)".


> Could you please tell me how it can be used uninitialized here, or what
> is bad by doing this way?
> 
>> After looking at this function for a few minutes, it could use some
>> refactoring (way too many gotos)  such as:
> 
> Yes, I agree.
> 
>> 1. move (query.page_size & xx) checks before "if
>> (query.windows_available == 0)"
> 
> Moving 'page_size selection' above 'checking windows available' will
> need us to duplicate the 'page_size selection' after the new query,
> inside the if.

page_size selection is not going to change, why?


> I mean, as query will be done again, it will need to get the (new) page
> size.
> 
>> 2. move "win64 = kzalloc(sizeof(struct property), GFP_KERNEL)" before
>> "if (query.windows_available == 0)"
> 
>> 3. call "reset_dma_window(dev, pdn)" inside the "if
>> (query.windows_available == 0)" branch.
> 
>> Then you can drop all "goto out_restore_defwin" and move default_win and
>> reset_win_ext inside "if (query.windows_available == 0)".
> 
> I did all changes suggested locally and did some analysis in the
> result:
> 
> I did not see a way to put default_win and reset_win_ext inside 
> "if (query.windows_available == 0)", because if we still need a way to
> know if the default window was removed, and if so, restore in case
> anything ever fails ahead (like creating the node property). 

Ah, I missed that new out_restore_defwin label is between other exit
labels. Sorry :-/


> But from that analysis I noted it's possible to remove all the new
> "goto out_restore_defwin", if we do default_win = NULL if
> ddw_read_ext() fails. 
> 
> So testing only default_win should always be enough to say if the
> default window was deleted, and reset_win_ext could be moved inside "if
> (query.windows_available == 0)".
> Also, it would avoid reset_win_ext being 'used uninitialized' and
> "out_restore_defwin:" would not be needed.
> 
> Against the current patch, we would have something like this:
> 
> #
> 
>  static u64 enable_ddw(struct pci_dev *dev, struct device_node *pdn)
>  {
> -   int len, ret, reset_win_ext;
> +   int len, ret;
> struct ddw_query_response query;
> struct ddw_create_response create;
> int page_shift;
> @@ -1173,25 +1173,28 @@ static u64 enable_ddw(struct pci_dev *dev,
> struct device_node *pdn)
>  * for extensions presence.
>  */
> if (query.windows_available == 0) {
> +   int reset_win_ext;
> default_win = of_find_property(pdn, "ibm,dma-window",
> NULL);
> if (!default_win)
> goto out_failed;
>  
> reset_win_ext = ddw_read_ext(pdn,
> DDW_EXT_RESET_DMA_WIN, NULL);
> -   if (reset_win_ext)
> +   if (reset_win_ext){
> +   default_win = NULL;
> goto out_failed;
> +   }


This says "if we can reset, then we fail", no?

> remove_dma_window(pdn, ddw_avail, default_win);


I think you can do "default_win=NULL" here and later at
out_restore_defwin check if it is NULL - then call reset.

> /* Query again, to check if the window is available */
> ret = query_ddw(dev, ddw_avail, , pdn);
> if (ret != 0)
> -   goto out_restore_defwin;
> +   goto out_failed;
>  
> if (query.windows_available == 0) {
> /* no windows are available for this device. */
> dev_dbg(>dev, "no free dynamic windows");
> -   goto out_restore_defwin;
> +   goto out_failed;
> }
> }
> if (query.page_size & 4) {
> @@ -1203,7 +1206,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
> device_node *pdn)
> } else {
> dev_dbg(>dev, "no supported direct page size in
> mask %x",
>   query.page_size);
> -   goto out_restore_defwin;
> +   goto out_failed;
> }
> /* verify the window * number of ptes will map the 

Re: [Ksummit-discuss] [PATCH v3] CodingStyle: Inclusive Terminology

[josh]

On Mon, Jul 13, 2020 at 10:02:24AM +0200, Takashi Iwai wrote:
> On Wed, 08 Jul 2020 20:14:27 +0200,
> Dan Williams wrote:
> > 
> > +Recommended replacements for 'blacklist/whitelist' are:
> > +'denylist / allowlist'
> > +'blocklist / passlist'
> 
> I started looking through the tree now and noticed there are lots of
> patterns like "whitelisted" or "blacklisted".  How can the words fit
> for those?  Actually, there are two cases like:
> 
> - Foo is blacklisted
> - Allow to load the non-whitelisted cards
> 
> Currently I'm replacing the former with "Foo is in denylist", but not
> sure about the latter case.  I thought Kees mentioned about this, but
> don't remember the proposal...

I find that "blocklist" works well as a verb: "foo is blocklisted",
"blocklist foo", or in some cases just "block foo" or "deny foo". For
the second case, phrasings like "allow loading non-safelisted cards" or
"allow loading cards not on the passlist" seem clear.

Re: [Freedreno] [PATCH] iommu/arm-smmu: Add a init_context_bank implementation hook

[Sai Prakash Ranjan]

On 2020-07-14 00:43, Jordan Crouse wrote:

On Mon, Jul 13, 2020 at 08:03:32PM +0100, Will Deacon wrote:

On Mon, Jul 13, 2020 at 11:00:32AM -0600, Jordan Crouse wrote:
> On Mon, Jul 13, 2020 at 04:11:23PM +0100, Will Deacon wrote:
> > On Thu, Jun 11, 2020 at 04:36:56PM -0600, Jordan Crouse wrote:
> > > Add a new implementation hook to allow the implementation specific code
> > > to tweek the context bank configuration just before it gets written.
> > > The first user will be the Adreno GPU implementation to turn on
> > > SCTLR.HUPCF to ensure that a page fault doesn't terminating pending
> > > transactions. Doing so could hang the GPU if one of the terminated
> > > transactions is a CP read.
> > >
> > > This depends on the arm-smmu adreno SMMU implementation [1].
> > >
> > > [1] https://patchwork.kernel.org/patch/11600943/
> > >
> > > Signed-off-by: Jordan Crouse 
> > > ---
> > >
> > >  drivers/iommu/arm-smmu-qcom.c | 13 +
> > >  drivers/iommu/arm-smmu.c  | 28 +---
> > >  drivers/iommu/arm-smmu.h  | 11 +++
> > >  3 files changed, 37 insertions(+), 15 deletions(-)
> >
> > This looks straightforward enough, but I don't want to merge this without
> > a user and Sai's series has open questions afaict.
>
> Not sure what you mean by a user in this context?
> Are you referring to https://patchwork.kernel.org/patch/11628541/?

Right, this post was just a single patch in isolation, whereas it was
reposted over at:

https://lore.kernel.org/r/cdcc6a1c95a84e774790389dc8b3b7f490dc.1593344119.git.saiprakash.ran...@codeaurora.org

so I'll ignore this one. Sorry, I'm just really struggling to keep 
track
of what is targetting 5.9, and I don't have tonnes of time to sift 
through

the backlog of duplicate postings :(


Yeah, that is our fault. There are too many cooks in the kitchen.

We need to pick either system cache or split pagetable and serialize
the other on top of it to get the impl code going and then build from 
there.
This particular patch can happily hang out in the background until the 
rest is

resolved.



My bad, sorry. Let us get split pagetable support reviewed first, then I 
can post
system cache support on top of it. As jordan said, this patch can 
hibernate until

those get resolved.

Thanks,
Sai

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

Re: [Linux-kernel-mentees] [PATCH v2] bpf: Fix NULL pointer dereference in __btf_resolve_helper_id()

[Andrii Nakryiko]

On Mon, Jul 13, 2020 at 6:29 PM Peilin Ye  wrote:
>
> Prevent __btf_resolve_helper_id() from dereferencing `btf_vmlinux`
> as NULL. This patch fixes the following syzbot bug:
>
> 
> https://syzkaller.appspot.com/bug?id=5edd146856fd513747c1992442732e5a0e9ba355
>
> Reported-by: syzbot+ee09bda7017345f1f...@syzkaller.appspotmail.com
> Signed-off-by: Peilin Ye 
> ---
> Thank you for reviewing my patch! I am new to Linux kernel development; would
> the log message and errno be appropriate for this case?

I think it's good enough, thanks for the fix.

Acked-by: Andrii Nakryiko 

>
> Change in v2:
> - Split NULL and IS_ERR cases.
>
>  kernel/bpf/btf.c | 5 +
>  1 file changed, 5 insertions(+)
>

[...]

[PATCH v6 1/2] dt-bindings: phy: Add USB PHY support for Intel LGM SoC

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Add the dt-schema to support USB PHY on Intel LGM SoC

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/phy/intel,lgm-usb-phy.yaml | 53 ++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml 
b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
new file mode 100644
index ..18609f50d458
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,lgm-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM USB PHY Device Tree Bindings
+
+maintainers:
+  - Vadivel Murugan Ramuthevar 
+
+properties:
+  compatible:
+const: intel,lgm-usb-phy
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  resets:
+items:
+  - description: USB PHY and Host controller reset
+  - description: APB BUS reset
+  - description: General Hardware reset
+
+  reset-names:
+items:
+  - const: phy
+  - const: apb
+  - const: phy31
+
+required:
+  - compatible
+  - clocks
+  - reg
+  - resets
+  - reset-names
+
+additionalProperties: false
+
+examples:
+  - |
+usb-phy@e7e0 {
+compatible = "intel,lgm-usb-phy";
+reg = <0xe7e0 0x1>;
+clocks = < 153>;
+resets = < 0x70 0x24>,
+ < 0x70 0x26>,
+ < 0x70 0x28>;
+reset-names = "phy", "apb", "phy31";
+};
-- 
2.11.0

[PATCH v6 2/2] phy: Add USB3 PHY support for Intel LGM SoC

[Ramuthevar,Vadivel MuruganX]

From: Ramuthevar Vadivel Murugan 

Add support for USB PHY on Intel LGM SoC.

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Philipp Zabel 
---
 drivers/phy/Kconfig   |  11 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-lgm-usb.c | 278 ++
 3 files changed, 290 insertions(+)
 create mode 100644 drivers/phy/phy-lgm-usb.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index b3ed94b98d9b..43ff5943f513 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -49,6 +49,17 @@ config PHY_XGENE
help
  This option enables support for APM X-Gene SoC multi-purpose PHY.
 
+config USB_LGM_PHY
+   tristate "INTEL Lightning Mountain USB PHY Driver"
+   depends on USB_SUPPORT
+   select USB_PHY
+   select REGULATOR
+   select REGULATOR_FIXED_VOLTAGE
+   help
+ Enable this to support Intel DWC3 PHY USB phy. This driver provides
+ interface to interact with USB GEN-II and USB 3.x PHY that is part
+ of the Intel network SOC.
+
 source "drivers/phy/allwinner/Kconfig"
 source "drivers/phy/amlogic/Kconfig"
 source "drivers/phy/broadcom/Kconfig"
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 310c149a9df5..c2cd6d756f5f 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_GENERIC_PHY_MIPI_DPHY) += phy-core-mipi-dphy.o
 obj-$(CONFIG_PHY_LPC18XX_USB_OTG)  += phy-lpc18xx-usb-otg.o
 obj-$(CONFIG_PHY_XGENE)+= phy-xgene.o
 obj-$(CONFIG_PHY_PISTACHIO_USB)+= phy-pistachio-usb.o
+obj-$(CONFIG_USB_LGM_PHY)  += phy-lgm-usb.o
 obj-$(CONFIG_ARCH_SUNXI)   += allwinner/
 obj-$(CONFIG_ARCH_MESON)   += amlogic/
 obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
diff --git a/drivers/phy/phy-lgm-usb.c b/drivers/phy/phy-lgm-usb.c
new file mode 100644
index ..1ec9ab266e08
--- /dev/null
+++ b/drivers/phy/phy-lgm-usb.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Intel LGM USB PHY driver
+ *
+ * Copyright (C) 2020 Intel Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CTRL1_OFFSET   0x14
+#define SRAM_EXT_LD_DONE   BIT(25)
+#define SRAM_INIT_DONE BIT(26)
+
+#define TCPC_OFFSET0x1014
+#define TCPC_MUX_CTL   GENMASK(1, 0)
+#define MUX_NC 0
+#define MUX_USB1
+#define MUX_DP 2
+#define MUX_USBDP  3
+#define TCPC_FLIPPED   BIT(2)
+#define TCPC_LOW_POWER_EN  BIT(3)
+#define TCPC_VALID BIT(4)
+#define TCPC_CONN  \
+   (TCPC_VALID | FIELD_PREP(TCPC_MUX_CTL, MUX_USB))
+#define TCPC_DISCONN   \
+   (TCPC_VALID | FIELD_PREP(TCPC_MUX_CTL, MUX_NC) | TCPC_LOW_POWER_EN)
+
+static const char *const PHY_RESETS[] = { "phy31", "phy", };
+static const char *const CTL_RESETS[] = { "apb", "ctrl", };
+
+struct tca_apb {
+   struct reset_control *resets[ARRAY_SIZE(PHY_RESETS)];
+   struct regulator *vbus;
+   struct work_struct wk;
+   struct usb_phy phy;
+
+   bool phy_initialized;
+   bool connected;
+};
+
+static int get_flipped(struct tca_apb *ta, bool *flipped)
+{
+   union extcon_property_value property;
+   int ret;
+
+   ret = extcon_get_property(ta->phy.edev, EXTCON_USB_HOST,
+ EXTCON_PROP_USB_TYPEC_POLARITY, );
+   if (ret) {
+   dev_err(ta->phy.dev, "no polarity property from extcon\n");
+   return ret;
+   }
+
+   *flipped = property.intval;
+
+   return ret;
+}
+
+static int phy_init(struct usb_phy *phy)
+{
+   struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+   void __iomem *ctrl1 = phy->io_priv + CTRL1_OFFSET;
+   int val, ret, i;
+
+   if (ta->phy_initialized)
+   return 0;
+
+   for (i = 0; i < ARRAY_SIZE(PHY_RESETS); i++)
+   reset_control_deassert(ta->resets[i]);
+
+   ret = readl_poll_timeout(ctrl1, val, val & SRAM_INIT_DONE, 10, 10 * 
1000);
+   if (ret) {
+   dev_err(ta->phy.dev, "SRAM init failed, 0x%x\n", val);
+   return ret;
+   }
+
+   writel(readl(ctrl1) | SRAM_EXT_LD_DONE, ctrl1);
+
+   ta->phy_initialized = true;
+   if (!ta->phy.edev) {
+   writel(TCPC_CONN, ta->phy.io_priv + TCPC_OFFSET);
+   return phy->set_vbus(phy, true);
+   }
+
+   schedule_work(>wk);
+
+   return ret;
+}
+
+static void phy_shutdown(struct usb_phy *phy)
+{
+   struct tca_apb *ta = container_of(phy, struct tca_apb, phy);
+   int i;
+
+   if (!ta->phy_initialized)
+   return;
+
+   ta->phy_initialized = false;
+   flush_work(>wk);
+   ta->phy.set_vbus(>phy, false);
+
+   ta->connected = false;
+   writel(TCPC_DISCONN, ta->phy.io_priv 

[PATCH v6 0/2] phy: Add USB PHY support on Intel LGM SoC

[Ramuthevar,Vadivel MuruganX]

The USB PHY provides the optimized for low power dissipation while active, 
idle, or on standby.
Requires minimal external components, a single resistor, for best operation.
Supports 10/5-Gbps high-speed data transmission rates through 3-m USB 3.x cable
---
v6:
 -  No Change
v5:
  - As per Felipe and Greg's suggestion usb phy driver reviewed patches
changed the folder from drivers/usb/phy to drivers/phy
  - Reviewed-By tag added in commit message
v4:
  - Andy's review comments addressed
  - drop the excess error debug prints
  - error check optimized
  - merge the split line to one line
v3:
  - Andy's review comments update
  - hardcode return value changed to actual return value from the callee
  - add error check is fixed according to the above
  - correct the assignment in redundant
  - combine the split line into one line
v2:
  - Address Phillip's review comments
  - replace devm_reset_control_get() by devm_reset_control_get_exclusive()
  - re-design the assert and deassert fucntion calls as per review comments
  - address kbuild bot warnings
  - add the comments
v1:
  - initial version

---
dt-bindings: usb: Add USB PHY support for Intel LGM SoC
v6: 
  - Fixed the bot issue.
  - replace node-name by usb-phy@ in example
v5:
  - Reviewed-By tag added
v4:
  - No Change
v3:
  - No Change
v2:
  - No Change
v1:
  - initial version


Ramuthevar Vadivel Murugan (2):
  dt-bindings: phy: Add USB PHY support for Intel LGM SoC
  phy: Add USB3 PHY support for Intel LGM SoC

 .../devicetree/bindings/phy/intel,lgm-usb-phy.yaml |  53 
 drivers/phy/Kconfig|  11 +
 drivers/phy/Makefile   |   1 +
 drivers/phy/phy-lgm-usb.c  | 278 +
 4 files changed, 343 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
 create mode 100644 drivers/phy/phy-lgm-usb.c

-- 
2.11.0

Re: [PATCH v2 4/4] scsi: ufs: Fix up and simplify error recovery mechanism

[Can Guo]

Hi Bart,

On 2020-07-14 11:52, Bart Van Assche wrote:

On 2020-07-13 19:28, Can Guo wrote:
o Queue eh_work on a single threaded workqueue to avoid concurrency 
between

  eh_works.


Please use another approach (mutex?) to serialize error handling. There 
are

already way too workqueues in a running Linux system.

o According to the UFSHCI JEDEC spec, hibern8 enter/exit error occurs 
when

  the link is broken. This actaully applies to any power mode change
  operations. In this change, if a power mode change operation 
(including
  AH8 enter/exit) fails, mark the link state as UIC_LINK_BROKEN_STATE 
and
  schedule eh_work. eh_work needs to do full reset and restore to 
recover
  the link back to active. Before the link state is recovered to 
active by
  eh_work, any power mode change attempts just return -ENOLINK to 
avoid

  consecutive HW error.

o To avoid concurrency between eh_work and link recovery, remove link
  recovery from hibern8 enter/exit func. If hibern8 enter/exit func 
fails,

  simply return error code and let eh_work run in parallel.

o Recover UFS hba runtime PM error in eh_work. If 
ufschd_suspend/resume
  fails due to UFS error, e.g. hibern8 enter/exit error and SSU cmd 
error,

  the runtime PM framework saves the error to dev.power.runtime_error.
  After that, hba runtime suspend/resume would not be invoked anymore 
until
  dev.power.runtime_error is cleared. The runtime PM error can be 
recovered
  in eh_work by calling pm_runtime_set_active() after reset and 
restore
  succeeds. Meanwhile, if pm_runtime_set_active() returns no error, 
which

  means dev.power.runtime_error is cleared, we also need to explicitly
  resume those scsi devices under hba in case any of them has failed 
to be

  resumed due to hba runtime resume error.

o Fix a racing problem between eh_work and ufshcd_suspend/resume. In 
the

  old code, it blocks scsi requests before schedules eh_work, but when
  eh_work calls pm_runtime_get_sync(), if ufshcd_suspend/resume is 
sending
  a scsi cmd, most likely the SSU cmd, pm_runtime_get_sync() will 
never
  return because scsi requests were blocked. To fix this racing 
problem,

  o Don't block scsi requests before schedule eh_work, but let eh_work
block scsi requests when eh_work is ready to start error recovery.
  o Meanwhile, if eh_work is schueduled due to fatal error, don't 
requeue
the scsi cmds sent from ufshcd_suspend/resume path, but simply let 
the
scsi cmds fail. If the scsi cmds fail, hba runtime suspend/resume 
fails

too, but it does hurt since eh_work recovers hba runtime PM error.

o Move host/regs dump in ufshcd_check_errors() to eh_work because 
heavy
  dump in IRQ context can lead to stability issues. In addition, some 
clean

  up in ufshcd_print_host_regs() and ufshcd_print_host_state().


The above list is a long list. To me that is a sign that this patch 
needs to

be split into multiple patches.

Thanks,

Bart.


Sure, will split it into a few patches.

Thanks,

Can Guo.

Re: [PATCH v2 3/4] ufs: ufs-qcom: Fix a few BUGs in func ufs_qcom_dump_dbg_regs()

[Can Guo]

Hi Bart,

On 2020-07-14 11:47, Bart Van Assche wrote:

On 2020-07-13 19:28, Can Guo wrote:
Dumping testbus registers needs to sleep a bit intermittently as there 
are
too many of them. Skip them for those contexts where sleep is not 
allowed.


Meanwhile, if ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() 
from
ufshcd_suspend/resume and/or clk gate/ungate context, 
pm_runtime_get_sync()

and ufshcd_hold() will cause racing problems. Fix it by removing the
unnecessary calls of pm_runtime_get_sync() and ufshcd_hold().

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufs-qcom.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2e6ddb5..3743c17 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1604,9 +1604,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host 
*host)

 */
}
mask <<= offset;
-
-   pm_runtime_get_sync(host->hba->dev);
-   ufshcd_hold(host->hba, false);
ufshcd_rmwl(host->hba, TEST_BUS_SEL,
(u32)host->testbus.select_major << 19,
REG_UFS_CFG1);
@@ -1619,8 +1616,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host 
*host)

 * committed before returning.
 */
mb();
-   ufshcd_release(host->hba);
-   pm_runtime_put_sync(host->hba->dev);

return 0;
 }
@@ -1658,11 +1653,13 @@ static void ufs_qcom_dump_dbg_regs(struct 
ufs_hba *hba)


/* sleep a bit intermittently as we are dumping too much data */
 	ufs_qcom_print_hw_debug_reg_all(hba, NULL, 
ufs_qcom_dump_regs_wrapper);

-   udelay(1000);
-   ufs_qcom_testbus_read(hba);
-   udelay(1000);
-   ufs_qcom_print_unipro_testbus(hba);
-   udelay(1000);
+   if (in_task()) {
+   udelay(1000);
+   ufs_qcom_testbus_read(hba);
+   udelay(1000);
+   ufs_qcom_print_unipro_testbus(hba);
+   udelay(1000);
+   }
 }


It is not clear to me how udelay() calls can help in code that takes 
long
since these functions use busy-waiting? Should the udelay() calls 
perhaps

be changed into cond_resched() calls?

Thanks,

Bart.


Maybe you are right, but this is not the purpose of this change. I am 
just

trying to make sure this func can be invoked from any contexts without
making troubles like schedule while atomic and/or race conditions.

Thanks,

Can Guo.

Re: [PATCH v2 1/4] scsi: ufs: Add checks before setting clk-gating states

[Can Guo]

Hi Bart,

On 2020-07-14 11:38, Bart Van Assche wrote:

On 2020-07-13 19:28, Can Guo wrote:
@@ -2538,7 +2540,8 @@ static int ufshcd_queuecommand(struct Scsi_Host 
*host, struct scsi_cmnd *cmd)

err = SCSI_MLQUEUE_HOST_BUSY;
goto out;
}
-   WARN_ON(hba->clk_gating.state != CLKS_ON);
+   if (ufshcd_is_clkgating_allowed(hba))
+   WARN_ON(hba->clk_gating.state != CLKS_ON);


A minor comment: has it been considered to change this into the
following?

WARN_ON(ufshcd_is_clkgating_allowed(hba) &&
hba->clk_gating.state != CLKS_ON);

Thanks,

Bart.


Sure, will do that.

Thanks,

Can Guo.

Re: [PATCH v2 2/4] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

[Can Guo]

On 2020-07-14 11:41, Bart Van Assche wrote:

On 2020-07-13 19:28, Can Guo wrote:

The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
decreased back in ufshcd_ungate_work() in a paired way. However, if
specific ufshcd_hold/release sequences are met, it is possible that
scsi_block_reqs_cnt is increased twice but only one ungate work is
queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() 
and

ufshcd_ungate_work() in a paired way, increase it only if queue_work()
returns true.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index ebf7a95..33214bb 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1611,12 +1611,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool 
async)

 */
/* fallthrough */
case CLKS_OFF:
-   ufshcd_scsi_block_requests(hba);
hba->clk_gating.state = REQ_CLKS_ON;
trace_ufshcd_clk_gating(dev_name(hba->dev),
hba->clk_gating.state);
-   queue_work(hba->clk_gating.clk_gating_workq,
-  >clk_gating.ungate_work);
+   if (queue_work(hba->clk_gating.clk_gating_workq,
+  >clk_gating.ungate_work))
+   ufshcd_scsi_block_requests(hba);
/*
 * fall through to check if we should wait for this
 * work to be done or not.


Since "ungate_work" involves calling ufshcd_scsi_unblock_requests() and
since this patch changes the order in which 
ufshcd_scsi_block_requests()

and queue_work() are called, I think this patch introduces a race
condition. Has it been considered to leave the 
ufshcd_scsi_block_requests()

call where it is and to call ufshcd_scsi_unblock_requests() if
queue_work() fails?

Thanks,

Bart.


Hi Bart,

The racing does not exist due to we still hold the spin lock here. 
Before

release the spin lock, the ungate_work, even it starts to run, cannot
move forward as it needs to require the spin lock once in the entrance.

static void ufshcd_ungate_work(struct work_struct *work)
{
...
spin_lock_irqsave(hba->host->host_lock, flags);
if (hba->clk_gating.state == CLKS_ON) {
spin_unlock_irqrestore(hba->host->host_lock, flags);
goto unblock_reqs;
}
...
}

Re: [PATCH] nvme: Remove redundant validation in nvme_start_ctrl()

[Chaitanya Kulkarni]

On 7/13/20 20:24, Baolin Wang wrote:
>> Since start keep alive is so small to make a function call how about we
>> in-line the call ? untested patch :-
> I am Okay about your suggestion. Will send v2 with your suggested-by tag
> if no other objection. Thanks.
> 

Keith, Christoph are you guys okay with this ? OR we want to keep the 
small helpers ?

Re: [PATCH] mm: mmap: Merge vma after call_mmap() if possible

[linmiaohe]

Andrew Morton  wrote:
> On Tue, 14 Jul 2020 11:07:44 +0800 linmiaohe  wrote:
>
>> The vm_flags may be changed after call_mmap() because drivers may set 
>> some flags for their own purpose. As a result, we failed to merge the 
>> adjacent vma due to the different vm_flags as userspace can't pass in the 
>> same one.
>> Try to merge vma after call_mmap() to fix this issue.
>
>Which drivers do this?

I searched the code and I see many drivers change the vm_flags, such as 
aio_ring_mmap set
VM_DONTEXPAND and amdgpu_mmap , binder_mmap also change the vm_flags , and so 
on...

Thanks.

WARNING in __nf_unregister_net_hook (2)

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:0aea6d5c Merge tag 'for-linus-5.8b-rc5-tag' of git://git.k..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1646fd6710
kernel config:  https://syzkaller.appspot.com/x/.config?x=b1a5a263f7a540cb
dashboard link: https://syzkaller.appspot.com/bug?extid=2570f2c036e3da5db176
compiler:   clang version 10.0.0 (https://github.com/llvm/llvm-project/ 
c2443155a0fb245c8f17f2c1c72b6ea391e86e81)
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1646988b10
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=132b126310

The bug was bisected to:

commit db8ab38880e06dedbfc879e75f5b0ddc495f4eb6
Author: Florian Westphal 
Date:   Thu Feb 28 11:02:52 2019 +

netfilter: nf_tables: merge ipv4 and ipv6 nat chain types

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=1013e3db10
final crash:https://syzkaller.appspot.com/x/report.txt?x=1213e3db10
console output: https://syzkaller.appspot.com/x/log.txt?x=1413e3db10

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2570f2c036e3da5db...@syzkaller.appspotmail.com
Fixes: db8ab38880e0 ("netfilter: nf_tables: merge ipv4 and ipv6 nat chain 
types")

[ cut here ]
hook not found, pf 2 num 0
WARNING: CPU: 0 PID: 6775 at net/netfilter/core.c:413 
__nf_unregister_net_hook+0x3e6/0x4a0 net/netfilter/core.c:413
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 6775 Comm: syz-executor554 Not tainted 5.8.0-rc4-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+0x1f0/0x31e lib/dump_stack.c:118
 panic+0x264/0x7a0 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:235
 exc_invalid_op+0x16/0x40 arch/x86/kernel/traps.c:255
 asm_exc_invalid_op+0x12/0x20 arch/x86/include/asm/idtentry.h:542
RIP: 0010:__nf_unregister_net_hook+0x3e6/0x4a0 net/netfilter/core.c:413
Code: 49 30 c3 02 01 48 8b 44 24 20 42 8a 04 28 84 c0 0f 85 ad 00 00 00 41 8b 
14 24 48 c7 c7 78 ad 08 89 89 de 31 c0 e8 6a 5a a0 fa <0f> 0b e9 04 ff ff ff 44 
89 e1 80 e1 07 80 c1 03 38 c1 0f 8c 44 fc
RSP: 0018:c90001277718 EFLAGS: 00010246
RAX: 08b629c459c08900 RBX: 0002 RCX: 8880941721c0
RDX:  RSI: 0008 RDI: 0282
RBP: 895b8008 R08: dc00 R09: fbfff16338a7
R10: fbfff16338a7 R11:  R12: 888094f5461c
R13: dc00 R14: 0050 R15: 895b7040
 nft_unregister_basechain_hooks net/netfilter/nf_tables_api.c:206 [inline]
 nft_table_disable net/netfilter/nf_tables_api.c:835 [inline]
 nf_tables_table_disable net/netfilter/nf_tables_api.c:868 [inline]
 nf_tables_commit+0x32d3/0x4d70 net/netfilter/nf_tables_api.c:7550
 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:486 [inline]
 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:544 [inline]
 nfnetlink_rcv+0x14a5/0x1e50 net/netfilter/nfnetlink.c:562
 netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
 netlink_unicast+0x786/0x940 net/netlink/af_netlink.c:1329
 netlink_sendmsg+0xa57/0xd70 net/netlink/af_netlink.c:1918
 sock_sendmsg_nosec net/socket.c:652 [inline]
 sock_sendmsg net/socket.c:672 [inline]
 sys_sendmsg+0x519/0x800 net/socket.c:2352
 ___sys_sendmsg net/socket.c:2406 [inline]
 __sys_sendmsg+0x2b1/0x360 net/socket.c:2439
 do_syscall_64+0x73/0xe0 arch/x86/entry/common.c:384
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x440709
Code: Bad RIP value.
RSP: 002b:7fff97b1aa78 EFLAGS: 0246 ORIG_RAX: 002e
RAX: ffda RBX: 004002c8 RCX: 00440709
RDX:  RSI: 2000c2c0 RDI: 0003
RBP: 006ca018 R08:  R09: 004002c8
R10: 0003 R11: 0246 R12: 00401f10
R13: 00401fa0 R14:  R15: 
Kernel Offset: disabled
Rebooting in 86400 seconds..


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

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [PATCH v2] Since am437x have the same clock structure with am335x [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan probe failed on am437x platform.

[Stephen Rothwell]

Hi Dillon,

On Tue, 14 Jul 2020 11:43:31 +0800 dillon min  wrote:
>
> On Tue, Jul 14, 2020 at 11:38 AM Stephen Rothwell  
> wrote:
> >
> > On Tue, 14 Jul 2020 11:23:18 +0800 dillon.min...@gmail.com wrote:  
> > >
> > > From: dillon min 
> > >
> > > Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during 
> > > init to read revision")
> > >
> > > [1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
> > > Integration
> > > [2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
> > > Integration
> > > [3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on 
> > > am335x")
> > >
> > > Signed-off-by: dillon min 
> > > ---
> > >
> > > Hi Stephen,
> > >
> > > This changes correct commit messages based on your reviewing.
> > > make Fixes tags to oneline.
> > > make all commit message tags at the end of commit message  
> >
> > But the Fixes: line should be down with the Signed-off-by: line ...
> >  
> Ok, should it be like this，i will resubmit it.
> 
> Subject: [PATCH v2] Since am437x have the same clock structure with am335x
>  [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan
>  probe failed on the am437x platform.

You should have a shorter subject and maybe the above could be the
first paragraph of the commit message.

> 
> [1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
> Integration
> [2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
> Integration
> [3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")
> 
> Signed-off-by: dillon min 
> Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during
> init to read revision")

No wrapping the the Fixes line, please and it would usually go before
your Signed=off-by line
-- 
Cheers,
Stephen Rothwell


pgpGxOqlg_FHr.pgp
Description: OpenPGP digital signature

Re: [PATCH v5 1/2] dt-bindings: phy: Add USB PHY support for Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Rob,

On 13/7/2020 11:07 pm, Rob Herring wrote:

On Mon, 13 Jul 2020 16:54:52 +0800, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

Add the dt-schema to support USB PHY on Intel LGM SoC

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Rob Herring 
---
  .../devicetree/bindings/phy/intel,lgm-usb-phy.yaml | 53 ++
  1 file changed, 53 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml




My bot found errors running 'make dt_binding_check' on your patch:

Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml: $id: relative 
path/filename doesn't match actual path or filename
expected: http://devicetree.org/schemas/phy/intel,lgm-usb-phy.yaml#


See https://patchwork.ozlabs.org/patch/1327785

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:

pip3 install git+https://github.com/devicetree-org/dt-schema.git@master 
--upgrade

Please check and re-submit.

Sure, will check and update, Thanks!

Regards
Vadivel

Re: [PATCH v5 1/2] dt-bindings: phy: Add USB PHY support for Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Rob,

On 13/7/2020 11:08 pm, Rob Herring wrote:

On Mon, Jul 13, 2020 at 04:54:52PM +0800, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

Add the dt-schema to support USB PHY on Intel LGM SoC

Signed-off-by: Ramuthevar Vadivel Murugan 

Reviewed-by: Rob Herring 
---
  .../devicetree/bindings/phy/intel,lgm-usb-phy.yaml | 53 ++
  1 file changed, 53 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml

diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml 
b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
new file mode 100644
index ..0fc76cd23774
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-usb-phy.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/intel,lgm-usb-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel LGM USB PHY Device Tree Bindings
+
+maintainers:
+  - Vadivel Murugan Ramuthevar 
+
+properties:
+  compatible:
+const: intel,lgm-usb-phy
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  resets:
+items:
+  - description: USB PHY and Host controller reset
+  - description: APB BUS reset
+  - description: General Hardware reset
+
+  reset-names:
+items:
+  - const: phy
+  - const: apb
+  - const: phy31
+
+required:
+  - compatible
+  - clocks
+  - reg
+  - resets
+  - reset-names
+
+additionalProperties: false
+
+examples:
+  - |
+usb_phy: usb_phy@e7e0 {


usb-phy@...

Noted, will updated.
Thanks!



+compatible = "intel,lgm-usb-phy";
+reg = <0xe7e0 0x1>;
+clocks = < 153>;
+resets = < 0x70 0x24>,
+ < 0x70 0x26>,
+ < 0x70 0x28>;
+reset-names = "phy", "apb", "phy31";
+};
--
2.11.0

Re: [PATCH v2 4/4] scsi: ufs: Fix up and simplify error recovery mechanism

[Bart Van Assche]

On 2020-07-13 19:28, Can Guo wrote:
> o Queue eh_work on a single threaded workqueue to avoid concurrency between
>   eh_works.

Please use another approach (mutex?) to serialize error handling. There are
already way too workqueues in a running Linux system.

> o According to the UFSHCI JEDEC spec, hibern8 enter/exit error occurs when
>   the link is broken. This actaully applies to any power mode change
>   operations. In this change, if a power mode change operation (including
>   AH8 enter/exit) fails, mark the link state as UIC_LINK_BROKEN_STATE and
>   schedule eh_work. eh_work needs to do full reset and restore to recover
>   the link back to active. Before the link state is recovered to active by
>   eh_work, any power mode change attempts just return -ENOLINK to avoid
>   consecutive HW error.
> 
> o To avoid concurrency between eh_work and link recovery, remove link
>   recovery from hibern8 enter/exit func. If hibern8 enter/exit func fails,
>   simply return error code and let eh_work run in parallel.
> 
> o Recover UFS hba runtime PM error in eh_work. If ufschd_suspend/resume
>   fails due to UFS error, e.g. hibern8 enter/exit error and SSU cmd error,
>   the runtime PM framework saves the error to dev.power.runtime_error.
>   After that, hba runtime suspend/resume would not be invoked anymore until
>   dev.power.runtime_error is cleared. The runtime PM error can be recovered
>   in eh_work by calling pm_runtime_set_active() after reset and restore
>   succeeds. Meanwhile, if pm_runtime_set_active() returns no error, which
>   means dev.power.runtime_error is cleared, we also need to explicitly
>   resume those scsi devices under hba in case any of them has failed to be
>   resumed due to hba runtime resume error.
> 
> o Fix a racing problem between eh_work and ufshcd_suspend/resume. In the
>   old code, it blocks scsi requests before schedules eh_work, but when
>   eh_work calls pm_runtime_get_sync(), if ufshcd_suspend/resume is sending
>   a scsi cmd, most likely the SSU cmd, pm_runtime_get_sync() will never
>   return because scsi requests were blocked. To fix this racing problem,
>   o Don't block scsi requests before schedule eh_work, but let eh_work
> block scsi requests when eh_work is ready to start error recovery.
>   o Meanwhile, if eh_work is schueduled due to fatal error, don't requeue
> the scsi cmds sent from ufshcd_suspend/resume path, but simply let the
> scsi cmds fail. If the scsi cmds fail, hba runtime suspend/resume fails
> too, but it does hurt since eh_work recovers hba runtime PM error.
> 
> o Move host/regs dump in ufshcd_check_errors() to eh_work because heavy
>   dump in IRQ context can lead to stability issues. In addition, some clean
>   up in ufshcd_print_host_regs() and ufshcd_print_host_state().

The above list is a long list. To me that is a sign that this patch needs to
be split into multiple patches.

Thanks,

Bart.

[PATCH v3] ARM: dts: Configure osc clock for d_can on am437x

[dillon . minfei]

From: dillon min 

V2 -> V3:
make Fixes tags after Signed-off-by line.

V1 -> V2:
correct commit messages based on Stephen Rothwell's reviewing.
make Fixes tags to oneline.
make all commit message tags at the end of commit message


V1:
Got following d_can probe errors with kernel 5.8-rc1 on am437x

[   10.730822] CAN device driver interface
Starting Wait for Network to be Configured...
[  OK  ] Reached target Network.
[   10.787363] c_can_platform 481cc000.can: probe failed
[   10.792484] c_can_platform: probe of 481cc000.can failed with
error -2
[   10.799457] c_can_platform 481d.can: probe failed
[   10.804617] c_can_platform: probe of 481d.can failed with
error -2

actually, Tony has fixed this issue on am335x, the patch [3]
commit messages:
"
The reason why the issue happens is because we now attempt to read the
interconnect target module revision register by first manually enabling
all the device clocks in sysc_probe(). And looks like d_can also needs
the osc clock in addition to the module clock, and it may or may not be
enabled depending on the bootloader version and if other devices have
already requested osc clock.

Let's fix the issue by adding osc clock as an optional clock for the
module for am335x. Note that am437x does not seem to list the osc clock
at all, so presumably it is not needed for am437x.
"

from TRM of am335x/am437x [1][2], they have the same clock structure,
so, we can just reuse [3] for am437x platform.

Tested on custom am4372 board.

[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")


dillon min (1):
  Since am437x have the same clock structure with am335x [1][2],
reuse the code from Tony Lindgren's patch [reference] to fix dcan
probe failed on am437x platform.

 arch/arm/boot/dts/am437x-l4.dtsi | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

-- 
2.7.4

[PATCH v3] Since am437x have the same clock structure with am335x [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan probe failed on am437x platform.

[dillon . minfei]

From: dillon min 


[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")

Signed-off-by: dillon min 
Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to 
read revision")
---

Hi Stephen,

This changes correct commit messages based on your reviewing.
make Fixes tags to oneline.
make all commit message tags at the end of commit message
make Fixes tags after Signed-off-by line.

 arch/arm/boot/dts/am437x-l4.dtsi | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
index 0d0f9fe4a882..4129affde54e 100644
--- a/arch/arm/boot/dts/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/am437x-l4.dtsi
@@ -1541,8 +1541,9 @@
reg = <0xcc020 0x4>;
reg-names = "rev";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
-   clocks = <_clkctrl AM4_L4LS_D_CAN0_CLKCTRL 0>;
-   clock-names = "fck";
+   clocks = <_clkctrl AM4_L4LS_D_CAN0_CLKCTRL 0>,
+   <_fck>;
+   clock-names = "fck", "osc";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xcc000 0x2000>;
@@ -1550,6 +1551,8 @@
dcan0: can@0 {
compatible = "ti,am4372-d_can", 
"ti,am3352-d_can";
reg = <0x0 0x2000>;
+   clocks = <_fck>;
+   clock-names = "fck";
syscon-raminit = <_conf 0x644 0>;
interrupts = ;
status = "disabled";
@@ -1561,8 +1564,9 @@
reg = <0xd0020 0x4>;
reg-names = "rev";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
-   clocks = <_clkctrl AM4_L4LS_D_CAN1_CLKCTRL 0>;
-   clock-names = "fck";
+   clocks = <_clkctrl AM4_L4LS_D_CAN1_CLKCTRL 0>,
+   <_fck>;
+   clock-names = "fck", "osc";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xd 0x2000>;
@@ -1570,6 +1574,8 @@
dcan1: can@0 {
compatible = "ti,am4372-d_can", 
"ti,am3352-d_can";
reg = <0x0 0x2000>;
+   clocks = <_fck>;
+   clock-name = "fck";
syscon-raminit = <_conf 0x644 1>;
interrupts = ;
status = "disabled";
-- 
2.7.4

Re: linux-next: build failure after merge of the tip tree

[Stephen Rothwell]

Hi all,

On Tue, 7 Jul 2020 12:33:01 +1000 Stephen Rothwell  
wrote:
>
> On Tue, 30 Jun 2020 12:54:59 +1000 Stephen Rothwell  
> wrote:
> >
> > On Mon, 22 Jun 2020 11:37:00 +1000 Stephen Rothwell  
> > wrote:  
> > >
> > > After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> > > failed like this:
> > > 
> > > ERROR: modpost: "sched_setscheduler" 
> > > [kernel/trace/ring_buffer_benchmark.ko] undefined!
> > > 
> > > Caused by commit
> > > 
> > >   616d91b68cd5 ("sched: Remove sched_setscheduler*() EXPORTs")
> > > 
> > > Missed one :-)
> > > 
> > > I have reverted that commit for today.
> > 
> > I am still reverting that commit.  
> 
> Ditto ...

Ping?
-- 
Cheers,
Stephen Rothwell


pgpf3TYnStxJt.pgp
Description: OpenPGP digital signature

Re: [PATCH v2 0/5] Dedicated CLINT timer driver

[Anup Patel]

On Tue, Jul 14, 2020 at 4:32 AM Palmer Dabbelt  wrote:
>
> On Sat, 27 Jun 2020 09:19:52 PDT (-0700), Anup Patel wrote:
> > The current RISC-V timer driver is convoluted and implements two
> > distinct timers:
> >  1. S-mode timer: This is for Linux RISC-V S-mode with MMU. The
> > clocksource is implemented using TIME CSR and clockevent device
> > is implemented using SBI Timer calls.
> >  2. M-mode timer: This is for Linux RISC-V M-mode without MMU. The
> > clocksource is implemented using CLINT MMIO time register and
> > clockevent device is implemented using CLINT MMIO timecmp registers.
> >
> > This patchset removes clint related code from RISC-V timer driver and
> > arch/riscv directory. Instead, the series adds a dedicated MMIO based
> > CLINT driver under drivers/clocksource directory which can be used by
> > Linux RISC-V M-mode (i.e NoMMU Linux RISC-V).
> >
> > The patchset is based up Linux-5.8-rc2 and can be found at riscv_clint_v2
> > branch of: https://github.com/avpatel/linux.git
> >
> > This series is tested on:
> >  1. QEMU RV64 virt machine using Linux RISC-V S-mode
> >  2. QEMU RV32 virt machine using Linux RISC-V S-mode
> >  3. QEMU RV64 virt machine using Linux RISC-V M-mode (i.e. NoMMU)
> >
> > Changes since v1:
> >  - Rebased series on Linux-5.8-rc2
> >  - Added pr_warn() for case where ipi_ops not available in PATCH1
> >  - Updated ipi_inject() prototype to use "struct cpumask *" in PATCH1
> >  - Updated CLINT_TIMER kconfig option to depend on RISCV_M_MODE in PATCH4
> >  - Added riscv,clint0 compatible string in DT bindings document
> >
> > Anup Patel (5):
> >   RISC-V: Add mechanism to provide custom IPI operations
> >   RISC-V: Remove CLINT related code
> >   clocksource/drivers/timer-riscv: Remove MMIO related stuff
> >   clocksource/drivers: Add CLINT timer driver
> >   dt-bindings: timer: Add CLINT bindings
>
> This all generally LGTM, though I haven't been through the code line-by-line
> yet.  It touches a bunch of trees, so I'd prefer to have some Acks before
> merging -- I'll dig through the RISC-V specific stuff, but the new CLINT 
> driver
> probhably deserves a look from one of the clocksource folks.
>
> I think the only issue is that the port will be broken between patch 2 and 4,
> as at that point we won't have an M-mode timer driver.  I think it shouldn't 
> be
> too much to just reorder these, LMK if you want to do it or you want me to.

Okay, I will try your suggestion to reorder patches. There is another minor
build issue reported by test bots which I will fix as well.

I will send v3 in a couple of days before end-of-week.

Regards,
Anup

>
> Thanks!
>
> >
> >  .../bindings/timer/sifive,clint.txt   |  34 +++
> >  arch/riscv/Kconfig|   2 +-
> >  arch/riscv/include/asm/clint.h|  39 ---
> >  arch/riscv/include/asm/smp.h  |  11 +
> >  arch/riscv/include/asm/timex.h|  28 +--
> >  arch/riscv/kernel/Makefile|   2 +-
> >  arch/riscv/kernel/clint.c |  44 
> >  arch/riscv/kernel/sbi.c   |  14 ++
> >  arch/riscv/kernel/setup.c |   2 -
> >  arch/riscv/kernel/smp.c   |  44 ++--
> >  arch/riscv/kernel/smpboot.c   |   4 +-
> >  drivers/clocksource/Kconfig   |  12 +-
> >  drivers/clocksource/Makefile  |   1 +
> >  drivers/clocksource/timer-clint.c | 229 ++
> >  drivers/clocksource/timer-riscv.c |  17 +-
> >  include/linux/cpuhotplug.h|   1 +
> >  16 files changed, 337 insertions(+), 147 deletions(-)
> >  create mode 100644 Documentation/devicetree/bindings/timer/sifive,clint.txt
> >  delete mode 100644 arch/riscv/include/asm/clint.h
> >  delete mode 100644 arch/riscv/kernel/clint.c
> >  create mode 100644 drivers/clocksource/timer-clint.c

Re: [PATCH] opp: ti-opp-supply: Replace HTTP links with HTTPS ones

[Viresh Kumar]

On 13-07-20, 20:05, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 
> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely or at least not just 
> HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
>  Sorry again to all maintainers who complained about subject lines.
>  Now I realized that you want an actually perfect prefixes,
>  not just subsystem ones.
>  I tried my best...
>  And yes, *I could* (at least half-)automate it.
>  Impossible is nothing! :)
> 
> 
>  drivers/opp/ti-opp-supply.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/opp/ti-opp-supply.c b/drivers/opp/ti-opp-supply.c
> index e3357e91decb..bd4771f388ab 100644
> --- a/drivers/opp/ti-opp-supply.c
> +++ b/drivers/opp/ti-opp-supply.c
> @@ -1,6 +1,6 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
> - * Copyright (C) 2016-2017 Texas Instruments Incorporated - 
> http://www.ti.com/
> + * Copyright (C) 2016-2017 Texas Instruments Incorporated - 
> https://www.ti.com/
>   *   Nishanth Menon 
>   *   Dave Gerlach 
>   *

Applied. Thanks.

-- 
viresh

Re: [PATCH v2 3/4] ufs: ufs-qcom: Fix a few BUGs in func ufs_qcom_dump_dbg_regs()

[Bart Van Assche]

On 2020-07-13 19:28, Can Guo wrote:
> Dumping testbus registers needs to sleep a bit intermittently as there are
> too many of them. Skip them for those contexts where sleep is not allowed.
> 
> Meanwhile, if ufs_qcom_dump_dbg_regs() calls ufs_qcom_testbus_config() from
> ufshcd_suspend/resume and/or clk gate/ungate context, pm_runtime_get_sync()
> and ufshcd_hold() will cause racing problems. Fix it by removing the
> unnecessary calls of pm_runtime_get_sync() and ufshcd_hold().
> 
> Signed-off-by: Can Guo 
> ---
>  drivers/scsi/ufs/ufs-qcom.c | 17 +++--
>  1 file changed, 7 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
> index 2e6ddb5..3743c17 100644
> --- a/drivers/scsi/ufs/ufs-qcom.c
> +++ b/drivers/scsi/ufs/ufs-qcom.c
> @@ -1604,9 +1604,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host)
>*/
>   }
>   mask <<= offset;
> -
> - pm_runtime_get_sync(host->hba->dev);
> - ufshcd_hold(host->hba, false);
>   ufshcd_rmwl(host->hba, TEST_BUS_SEL,
>   (u32)host->testbus.select_major << 19,
>   REG_UFS_CFG1);
> @@ -1619,8 +1616,6 @@ int ufs_qcom_testbus_config(struct ufs_qcom_host *host)
>* committed before returning.
>*/
>   mb();
> - ufshcd_release(host->hba);
> - pm_runtime_put_sync(host->hba->dev);
>  
>   return 0;
>  }
> @@ -1658,11 +1653,13 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba 
> *hba)
>  
>   /* sleep a bit intermittently as we are dumping too much data */
>   ufs_qcom_print_hw_debug_reg_all(hba, NULL, ufs_qcom_dump_regs_wrapper);
> - udelay(1000);
> - ufs_qcom_testbus_read(hba);
> - udelay(1000);
> - ufs_qcom_print_unipro_testbus(hba);
> - udelay(1000);
> + if (in_task()) {
> + udelay(1000);
> + ufs_qcom_testbus_read(hba);
> + udelay(1000);
> + ufs_qcom_print_unipro_testbus(hba);
> + udelay(1000);
> + }
>  }

It is not clear to me how udelay() calls can help in code that takes long
since these functions use busy-waiting? Should the udelay() calls perhaps
be changed into cond_resched() calls?

Thanks,

Bart.

Re: [PATCH v2 5/5] dt-bindings: timer: Add CLINT bindings

[Anup Patel]

On Tue, Jul 14, 2020 at 8:07 AM Rob Herring  wrote:
>
> On Sat, Jun 27, 2020 at 09:49:57PM +0530, Anup Patel wrote:
> > We add DT bindings documentation for CLINT device.
> >
> > Signed-off-by: Anup Patel 
> > Reviewed-by: Palmer Dabbelt 
> > ---
> >  .../bindings/timer/sifive,clint.txt   | 34 +++
> >  1 file changed, 34 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/timer/sifive,clint.txt
>
> Bindings should be in DT schema format now.

Okay, will update.

>
> >
> > diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.txt 
> > b/Documentation/devicetree/bindings/timer/sifive,clint.txt
> > new file mode 100644
> > index ..45b75347a7d5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/timer/sifive,clint.txt
> > @@ -0,0 +1,34 @@
> > +SiFive Core Local Interruptor (CLINT)
> > +-
> > +
> > +SiFive (and other RISC-V) SOCs include an implementation of the SiFive Core
> > +Local Interruptor (CLINT) for M-mode timer and inter-processor interrupts.
> > +
> > +It directly connects to the timer and inter-processor interrupt lines of
> > +various HARTs (or CPUs) so RISC-V per-HART (or per-CPU) local interrupt
> > +controller is the parent interrupt controller for CLINT device.
> > +
> > +The clock frequency of CLINT is specified via "timebase-frequency" DT
> > +property of "/cpus" DT node. The "timebase-frequency" DT property is
> > +described in: Documentation/devicetree/bindings/riscv/cpus.yaml
> > +
> > +Required properties:
> > +- compatible : should be "riscv,clint0" or "sifive,clint-1.0.0". A specific
>
> A new versioning scheme from SiFive? To review, we don't do version
> numbers unless there's a well defined and documented scheme. IOW, one
> that's not s/w folks just making up v1, v2, v3, etc.

The "riscv,clint0" is already used by various RISC-V systems (including QEMU).

The "sifive,clint-1.0.0" is for being consistent with the PLIC
versioning scheme.

There is no clear documentation of CLINT versioning scheme. I think it's best
to just drop "sifive,clint-1.0.0" . Agree ??

>
> > +  string identifying the actual implementation can be added if 
> > implementation
> > +  specific worked arounds are needed.
> > +- reg : Should contain 1 register range (address and length).
> > +- interrupts-extended : Specifies which HARTs (or CPUs) are connected to
> > +  the CLINT.  Each node pointed to should be a riscv,cpu-intc node, which
> > +  has a riscv node as parent.
> > +
> > +Example:
> > +
> > + clint@200 {
> > + compatible = "sifive,clint-1.0.0", "sifive,fu540-c000-clint";
>
> Doesn't match the binding.

Okay, will update.

>
> > + interrupts-extended = <
> > +  3  7
> > +  3  7
> > +  3  7
> > +  3  7>;
> > + reg = <0x200 0x400>;
> > + };
> > --
> > 2.25.1
> >

Regards,
Anup

Re: [PATCH 1/2] cpufreq: tegra186: Fix initial frequency

[Viresh Kumar]

On 13-07-20, 17:37, Jon Hunter wrote:
> 
> On 13/07/2020 04:25, Viresh Kumar wrote:
> > On 12-07-20, 11:06, Jon Hunter wrote:
> >> Commit 6cc3d0e9a097 ("cpufreq: tegra186: add
> >> CPUFREQ_NEED_INITIAL_FREQ_CHECK flag") fixed CPUFREQ support for
> >> Tegra186 but as a consequence the following warnings are now seen on
> >> boot ...
> >>
> >>  cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 0 KHz
> >>  cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 
> >> 2035200 KHz
> >>  cpufreq: cpufreq_online: CPU1: Running at unlisted freq: 0 KHz
> >>  cpufreq: cpufreq_online: CPU1: Unlisted initial frequency changed to: 
> >> 2035200 KHz
> >>  cpufreq: cpufreq_online: CPU2: Running at unlisted freq: 0 KHz
> >>  cpufreq: cpufreq_online: CPU2: Unlisted initial frequency changed to: 
> >> 2035200 KHz
> >>  cpufreq: cpufreq_online: CPU3: Running at unlisted freq: 0 KHz
> >>  cpufreq: cpufreq_online: CPU3: Unlisted initial frequency changed to: 
> >> 2035200 KHz
> >>  cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 0 KHz
> >>  cpufreq: cpufreq_online: CPU4: Unlisted initial frequency changed to: 
> >> 2035200 KHz
> >>  cpufreq: cpufreq_online: CPU5: Running at unlisted freq: 0 KHz
> >>  cpufreq: cpufreq_online: CPU5: Unlisted initial frequency changed to: 
> >> 2035200 KHz
> >>
> >> Although we could fix this by adding a 'get' operator for the Tegra186
> >> CPUFREQ driver, there is really little point because the CPUFREQ on
> >> Tegra186 is set by writing a value stored in the frequency table to a
> >> register and we just need to set the initial frequency.
> > 
> > The hardware still runs at the frequency requested by cpufreq core here, 
> > right ?
> 
> Yes.
> 
> > It is better to provide the get() callback as it is also used to show the
> > current frequency in userspace.
> 
> I looked at that and I saw that if the get() callback is not provided,
> the current frequency showed by userspace is policy->cur. For this
> device, policy->cur is accurate and so if we added the get() callback we
> essentially just going to return policy->cur. Therefore, given that we
> already know policy->cur, I did not see the point in adding a device
> specific handler to do the same thing.

The get() callback is supposed to read the frequency from hardware and
return it, no cached value here. policy->cur may end up being wrong in
case there is a bug.

-- 
viresh

Re: Null-ptr-deref due to "vfs, fsinfo: Add an RCU safe per-ns mount list"

[Stephen Rothwell]

Hi sll,

On Thu, 25 Jun 2020 11:25:17 +1000 Stephen Rothwell  
wrote:
>
> On Wed, 24 Jun 2020 11:57:07 -0400 Qian Cai  wrote:
> >
> > On Wed, May 13, 2020 at 12:29:52AM +0100, David Howells wrote:  
> > > Qian Cai  wrote:
> > > 
> > > > Reverted the linux-next commit ee8ad8190cb1 (“vfs, fsinfo: Add an RCU 
> > > > safe per-ns mount list”) fixed the null-ptr-deref.
> > > 
> > > Okay, I'm dropping this commit for now.
> > 
> > What's the point of re-adding this buggy patch to linux-next again since
> > 0621 without fixing the previous reported issue at all? Reverting the
> > commit will still fix the crash below immediately, i.e.,
> > 
> > dbc87e74d022 ("vfs, fsinfo: Add an RCU safe per-ns mount list")  
> 
> I have added a revert of that commit to linux-next today.

I am still reverting that commit ...

-- 
Cheers,
Stephen Rothwell


pgpBaqqbgqbU3.pgp
Description: OpenPGP digital signature

Re: [PATCH v2] Since am437x have the same clock structure with am335x [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan probe failed on am437x platform.

[dillon min]

On Tue, Jul 14, 2020 at 11:38 AM Stephen Rothwell  wrote:
>
> Hi,
>
> On Tue, 14 Jul 2020 11:23:18 +0800 dillon.min...@gmail.com wrote:
> >
> > From: dillon min 
> >
> > Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init 
> > to read revision")
> >
> > [1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
> > Integration
> > [2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
> > Integration
> > [3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on 
> > am335x")
> >
> > Signed-off-by: dillon min 
> > ---
> >
> > Hi Stephen,
> >
> > This changes correct commit messages based on your reviewing.
> > make Fixes tags to oneline.
> > make all commit message tags at the end of commit message
>
> But the Fixes: line should be down with the Signed-off-by: line ...
>
Ok, should it be like this，i will resubmit it.

Subject: [PATCH v2] Since am437x have the same clock structure with am335x
 [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan
 probe failed on the am437x platform.

[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")

Signed-off-by: dillon min 
Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during
init to read revision")

Thanks,
Dillon,
> --
> Cheers,
> Stephen Rothwell

Re: [PATCH v2 2/4] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

[Bart Van Assche]

On 2020-07-13 19:28, Can Guo wrote:
> The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
> decreased back in ufshcd_ungate_work() in a paired way. However, if
> specific ufshcd_hold/release sequences are met, it is possible that
> scsi_block_reqs_cnt is increased twice but only one ungate work is
> queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and
> ufshcd_ungate_work() in a paired way, increase it only if queue_work()
> returns true.
> 
> Signed-off-by: Can Guo 
> ---
>  drivers/scsi/ufs/ufshcd.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index ebf7a95..33214bb 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1611,12 +1611,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
>*/
>   /* fallthrough */
>   case CLKS_OFF:
> - ufshcd_scsi_block_requests(hba);
>   hba->clk_gating.state = REQ_CLKS_ON;
>   trace_ufshcd_clk_gating(dev_name(hba->dev),
>   hba->clk_gating.state);
> - queue_work(hba->clk_gating.clk_gating_workq,
> ->clk_gating.ungate_work);
> + if (queue_work(hba->clk_gating.clk_gating_workq,
> +>clk_gating.ungate_work))
> + ufshcd_scsi_block_requests(hba);
>   /*
>* fall through to check if we should wait for this
>* work to be done or not.

Since "ungate_work" involves calling ufshcd_scsi_unblock_requests() and
since this patch changes the order in which ufshcd_scsi_block_requests()
and queue_work() are called, I think this patch introduces a race
condition. Has it been considered to leave the ufshcd_scsi_block_requests()
call where it is and to call ufshcd_scsi_unblock_requests() if
queue_work() fails?

Thanks,

Bart.

Re: possible deadlock in shmem_fallocate (4)

[Eric Biggers]

On Tue, Jul 14, 2020 at 11:32:52AM +0800, Hillf Danton wrote:
> 
> Add FALLOC_FL_NOBLOCK and on the shmem side try to lock inode upon the
> new flag. And the overall upside is to keep the current gfp either in
> the khugepaged context or not.
> 
> --- a/include/uapi/linux/falloc.h
> +++ b/include/uapi/linux/falloc.h
> @@ -77,4 +77,6 @@
>   */
>  #define FALLOC_FL_UNSHARE_RANGE  0x40
>  
> +#define FALLOC_FL_NOBLOCK0x80
> +

You can't add a new UAPI flag to fix a kernel-internal problem like this.

- Eric

Re: [PATCH v2 2/3] dt-bindings: MIPS: Add Ingenic X1830 based boards.

[Zhou Yanjie]

Hi Rob,

在 2020/7/14 上午10:32, Rob Herring 写道:

On Fri, Jun 26, 2020 at 01:37:15AM +0800, 周琰杰 (Zhou Yanjie) wrote:

Add bindings for Ingenic X1830 based board, prepare for later dts.

Tested-by: 周正 (Zhou Zheng) 
Signed-off-by: 周琰杰 (Zhou Yanjie) 
---

Notes:
 v1->v2:
 No change.

  Documentation/devicetree/bindings/mips/ingenic/devices.yaml | 12 +---
  1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml 
b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
index d1175030781a..feb695be9f66 100644
--- a/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
+++ b/Documentation/devicetree/bindings/mips/ingenic/devices.yaml
@@ -8,7 +8,8 @@ title: Ingenic XBurst based Platforms Device Tree Bindings
  
  maintainers:

- 周琰杰 (Zhou Yanjie) 
-description: |
+
+description:
Devices with a Ingenic XBurst CPU shall have the following properties.
  
  properties:

@@ -32,8 +33,13 @@ properties:
- const: img,ci20
- const: ingenic,jz4780
  
-  - description: YSH & ATIL General Board CU Neo

+  - description: YSH & ATIL General Board, CU1000 Module with Neo Backplane
  items:
- const: yna,cu1000-neo
-  - const: ingenic,x1000
+  - const: ingenic,x1000e

What's this change? You can't just change bindings.



This is my fault, I will add the modification of the corresponding dts 
file in the next version.


Thanks and best regards!


+
+  - description: YSH & ATIL General Board, CU1830 Module with Neo Backplane
+items:
+  - const: yna,cu1830-neo
+  - const: ingenic,x1830
  ...
--
2.11.0

Re: [PATCH v2] Since am437x have the same clock structure with am335x [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan probe failed on am437x platform.

[Stephen Rothwell]

Hi,

On Tue, 14 Jul 2020 11:23:18 +0800 dillon.min...@gmail.com wrote:
>
> From: dillon min 
> 
> Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to 
> read revision")
> 
> [1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
> Integration
> [2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
> Integration
> [3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")
> 
> Signed-off-by: dillon min 
> ---
> 
> Hi Stephen,
> 
> This changes correct commit messages based on your reviewing.
> make Fixes tags to oneline.
> make all commit message tags at the end of commit message

But the Fixes: line should be down with the Signed-off-by: line ...

-- 
Cheers,
Stephen Rothwell


pgptyi4VyhZnZ.pgp
Description: OpenPGP digital signature

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

[kohada.tetsuh...@dc.mitsubishielectric.co.jp]

Thanks for your reply.

> >
> > /* validiate cached dentries */
> > -   for (i = 1; i < num_entries; i++) {
> > -   ep = exfat_get_dentry_cached(es, i);
> > -   if (!exfat_validate_entry(exfat_get_entry_type(ep), ))
> 
> > +   for (i = 1; i < es->num_entries; i++) {
> > +   if (!exfat_get_validated_dentry(es, i, TYPE_SECONDARY))
> > goto free_es;
> > }
> > +   if (!exfat_get_validated_dentry(es, 1, TYPE_STREAM))
> > +   goto free_es;
> 
> It looks better to move checking TYPE_STREAM above the for-loop.
> And then for-loop should start from index 2.

OK. I'll change that. 
However, this for-loop is considering changing to checksum verification.


> BTW, do you think it is enough to check only TYPE_SECONDARY not TYPE NAME?
> As you might know, FILE, STREAM and NAME entries must be consecutive in order.

I think it is appropriate as a check here.
TYPE_NAME starting without index=2 doesn't accept in 
exfat_get_uniname_from_ext_entry().
However, I think this is not enough.
This is because there is no check for name-length. (same with or without patch)

I will check the name-length in the next(or after next) patch.


BR
---
Kohada Tetsuhiro 

Re: [PATCH v2 1/4] scsi: ufs: Add checks before setting clk-gating states

[Bart Van Assche]

On 2020-07-13 19:28, Can Guo wrote:
> @@ -2538,7 +2540,8 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, 
> struct scsi_cmnd *cmd)
>   err = SCSI_MLQUEUE_HOST_BUSY;
>   goto out;
>   }
> - WARN_ON(hba->clk_gating.state != CLKS_ON);
> + if (ufshcd_is_clkgating_allowed(hba))
> + WARN_ON(hba->clk_gating.state != CLKS_ON);

A minor comment: has it been considered to change this into the
following?

WARN_ON(ufshcd_is_clkgating_allowed(hba) &&
hba->clk_gating.state != CLKS_ON);

Thanks,

Bart.

Re: [PATCH v2 2/2] ARM: dts: stm32: Enable MIPI DSI display support.

[Hua Dillon]

Hi, Adrian,

Just one suggestion for you.

Adrian Pop  于2020年7月3日周五 上午1:30写道：
>
> STM32f769-disco features a 4" MIPI DSI display: add support for it.
> On Cortex-M7 DMA can't use cached memory. For this reason I use a dedicated
> memory pool for DMA with no-cache attribute which is located at the end of
>  RAM.
>
> Signed-off-by: Adrian Pop 
> ---
>  arch/arm/boot/dts/stm32f746.dtsi  | 34 +++
>  arch/arm/boot/dts/stm32f769-disco.dts | 49 +++
>  2 files changed, 83 insertions(+)
>
> diff --git a/arch/arm/boot/dts/stm32f746.dtsi 
> b/arch/arm/boot/dts/stm32f746.dtsi
> index 93c063796780..577a812ca01c 100644
> --- a/arch/arm/boot/dts/stm32f746.dtsi
> +++ b/arch/arm/boot/dts/stm32f746.dtsi
> @@ -48,6 +48,19 @@ / {
> #address-cells = <1>;
> #size-cells = <1>;
>
> +   reserved-memory {
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   ranges;
> +
> +   linux,dma {
> +   compatible = "shared-dma-pool";
> +   linux,dma-default;
> +   no-map;
> +   reg = <0xc0f0 0x10>;
> +   };
> +   };
> +
Christoph Hellwig was submit a patch for !CONFIG_MMU platforms to support mmap.
the patch is : 1fbf57d05302 dma-direct: re-enable mmap for !CONFIG_MMU
i thought there is no need to create a reserved-memory for it.

> clocks {
> clk_hse: clk-hse {
> #clock-cells = <0>;
> @@ -75,6 +88,27 @@ clk_i2s_ckin: clk-i2s-ckin {
> };
>
> soc {
> +   ltdc: display-controller@40016800 {
> +   compatible = "st,stm32-ltdc";
> +   reg = <0x40016800 0x200>;
> +   interrupts = <88>, <89>;
> +   resets = < STM32F7_APB2_RESET(LTDC)>;
> +   clocks = < 1 CLK_LCD>;
> +   clock-names = "lcd";
> +   status = "disabled";
> +   };
> +
> +   dsi: dsi@40016c00 {
> +   compatible = "st,stm32-dsi";
> +   reg = <0x40016c00 0x800>;
> +   interrupts = <98>;
> +   clocks = < 1 CLK_F769_DSI>, <_hse>;
> +   clock-names = "pclk", "ref";
> +   resets = < STM32F7_APB2_RESET(DSI)>;
> +   reset-names = "apb";
> +   status = "disabled";
> +   };
> +
> timer2: timer@4000 {
> compatible = "st,stm32-timer";
> reg = <0x4000 0x400>;
> diff --git a/arch/arm/boot/dts/stm32f769-disco.dts 
> b/arch/arm/boot/dts/stm32f769-disco.dts
> index 1626e00bb2cb..a9e81b49809c 100644
> --- a/arch/arm/boot/dts/stm32f769-disco.dts
> +++ b/arch/arm/boot/dts/stm32f769-disco.dts
> @@ -153,3 +153,52 @@ _hs {
> pinctrl-names = "default";
> status = "okay";
>  };
> +
> + {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   status = "okay";
> +
> +   ports {
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   port@0 {
> +   reg = <0>;
> +   dsi_in: endpoint {
> +   remote-endpoint = <_out_dsi>;
> +   };
> +   };
> +
> +   port@1 {
> +   reg = <1>;
> +   dsi_out: endpoint {
> +   remote-endpoint = <_in_panel>;
> +   };
> +   };
> +
> +   };
> +
> +   panel: panel {
> +   compatible = "orisetech,otm8009a";
> +   reg = <0>;
> +   reset-gpios = < 15 GPIO_ACTIVE_LOW>;
> +   status = "okay";
> +
> +   port {
> +   dsi_in_panel: endpoint {
> +   remote-endpoint = <_out>;
> +   };
> +   };
> +   };
> +};
> +
> + {
> +   status = "okay";
> +
> +   port {
> +   ltdc_out_dsi: endpoint {
> +   remote-endpoint = <_in>;
> +   };
> +   };
> +};
> --
> 2.27.0
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] usb: typec: Comment correction for typec_partner_register_altmode

[Kyle Tso]

typec_register_altmode returns ERR_PTR on failure.

Signed-off-by: Kyle Tso 
---
 drivers/usb/typec/class.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/typec/class.c b/drivers/usb/typec/class.c
index c9234748537a..02655694f200 100644
--- a/drivers/usb/typec/class.c
+++ b/drivers/usb/typec/class.c
@@ -580,7 +580,7 @@ EXPORT_SYMBOL_GPL(typec_partner_set_identity);
  * SVID listed in response to Discover Modes command need to be listed in an
  * array in @desc.
  *
- * Returns handle to the alternate mode on success or NULL on failure.
+ * Returns handle to the alternate mode on success or ERR_PTR on failure.
  */
 struct typec_altmode *
 typec_partner_register_altmode(struct typec_partner *partner,
-- 
2.27.0.389.gc38d7665816-goog

[PATCH 2/2] usb: typec: tcpm: Error handling for tcpm_register_partner_altmodes

[Kyle Tso]

typec_partner_register_altmode returns ERR_PTR. Reset the pointer
altmode to NULL on failure.

Signed-off-by: Kyle Tso 
---
 drivers/usb/typec/tcpm/tcpm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 82b19ebd7838..a6d4b03ec250 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -1061,9 +1061,11 @@ static void tcpm_register_partner_altmodes(struct 
tcpm_port *port)
for (i = 0; i < modep->altmodes; i++) {
altmode = typec_partner_register_altmode(port->partner,
>altmode_desc[i]);
-   if (!altmode)
+   if (IS_ERR(altmode)) {
tcpm_log(port, "Failed to register partner SVID 0x%04x",
 modep->altmode_desc[i].svid);
+   altmode = NULL;
+   }
port->partner_altmode[i] = altmode;
}
 }
-- 
2.27.0.389.gc38d7665816-goog

[PATCH 0/2] tcpm: Error handling for tcpm_register_partner_altmodes

[Kyle Tso]

*** BLURB HERE ***

Kyle Tso (2):
  usb: typec: Comment correction for typec_partner_register_altmode
  usb: typec: tcpm: Error handling for tcpm_register_partner_altmodes

 drivers/usb/typec/class.c | 2 +-
 drivers/usb/typec/tcpm/tcpm.c | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

-- 
2.27.0.389.gc38d7665816-goog

Re: [PATCH] tipc: Don't using smp_processor_id() in preemptible code

[Eric Dumazet]

On 7/13/20 6:53 PM, qiang.zh...@windriver.com wrote:
> From: Zhang Qiang 
> 
> CPU: 0 PID: 6801 Comm: syz-executor201 Not tainted 5.8.0-rc4-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine,
> BIOS Google 01/01/2011
>
> Reported-by: syzbot+263f8c0d007dc09b2...@syzkaller.appspotmail.com
> Signed-off-by: Zhang Qiang 
> ---
>  net/tipc/crypto.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/tipc/crypto.c b/net/tipc/crypto.c
> index 8c47ded2edb6..520af0afe1b3 100644
> --- a/net/tipc/crypto.c
> +++ b/net/tipc/crypto.c
> @@ -399,9 +399,10 @@ static void tipc_aead_users_set(struct tipc_aead __rcu 
> *aead, int val)
>   */
>  static struct crypto_aead *tipc_aead_tfm_next(struct tipc_aead *aead)
>  {
> - struct tipc_tfm **tfm_entry = this_cpu_ptr(aead->tfm_entry);
> + struct tipc_tfm **tfm_entry = get_cpu_ptr(aead->tfm_entry);
>  
>   *tfm_entry = list_next_entry(*tfm_entry, list);
> + put_cpu_ptr(tfm_entry);
>   return (*tfm_entry)->tfm;
>  }
>  
> 

This seems to hide a real bug.

Presumably callers of this function should have disable preemption, and maybe 
interrupts as well.

In any case, a Fixes: tag would be welcomed.

RE: [PATCH v6 03/12] docs: x86: Add documentation for SVA (Shared Virtual Addressing)

[Liu, Yi L]

> From: Fenghua Yu 
> Sent: Tuesday, July 14, 2020 7:48 AM
> 
> From: Ashok Raj 
> 
> ENQCMD and Data Streaming Accelerator (DSA) and all of their associated 
> features
> are a complicated stack with lots of interconnected pieces.
> This documentation provides a big picture overview for all of the features.
> 
> Signed-off-by: Ashok Raj 
> Co-developed-by: Fenghua Yu 
> Signed-off-by: Fenghua Yu 
> Reviewed-by: Tony Luck 
> ---
> v3:
> - Replace deprecated intel_svm_bind_mm() by iommu_sva_bind_mm() (Baolu)
> - Fix a couple of typos (Baolu)
> 
> v2:
> - Fix the doc format and add the doc in toctree (Thomas)
> - Modify the doc for better description (Thomas, Tony, Dave)
> 
>  Documentation/x86/index.rst |   1 +
>  Documentation/x86/sva.rst   | 287 
>  2 files changed, 288 insertions(+)
>  create mode 100644 Documentation/x86/sva.rst
> 
> diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index
> 265d9e9a093b..e5d5ff096685 100644
> --- a/Documentation/x86/index.rst
> +++ b/Documentation/x86/index.rst
> @@ -30,3 +30,4 @@ x86-specific Documentation
> usb-legacy-support
> i386/index
> x86_64/index
> +   sva
> diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst new file 
> mode
> 100644 index ..7242a84169ef
> --- /dev/null
> +++ b/Documentation/x86/sva.rst
> @@ -0,0 +1,287 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +===
> +Shared Virtual Addressing (SVA) with ENQCMD
> +===
> +
> +Background
> +==
> +
> +Shared Virtual Addressing (SVA) allows the processor and device to use
> +the same virtual addresses avoiding the need for software to translate
> +virtual addresses to physical addresses. SVA is what PCIe calls Shared
> +Virtual Memory (SVM)
> +
> +In addition to the convenience of using application virtual addresses
> +by the device, it also doesn't require pinning pages for DMA.
> +PCIe Address Translation Services (ATS) along with Page Request
> +Interface
> +(PRI) allow devices to function much the same way as the CPU handling
> +application page-faults. For more information please refer to PCIe
> +specification Chapter 10: ATS Specification.
> +

nit: may be helpful to mention Chapter 10 of PCIe spec since 4.0. before that, 
ATS has its
own specification.

> +Use of SVA requires IOMMU support in the platform. IOMMU also is
> +required to support PCIe features ATS and PRI. ATS allows devices to
> +cache translations for the virtual address. IOMMU driver uses the
> +mmu_notifier() support to keep the device tlb cache and the CPU cache
> +in sync. PRI allows the device to request paging the virtual address
> +before using if they are not paged in the CPU page tables.
> +
> +
> +Shared Hardware Workqueues
> +==
> +
> +Unlike Single Root I/O Virtualization (SRIOV), Scalable IOV (SIOV)
> +permits the use of Shared Work Queues (SWQ) by both applications and
> +Virtual Machines (VM's). This allows better hardware utilization vs.
> +hard partitioning resources that could result in under utilization. In
> +order to allow the hardware to distinguish the context for which work
> +is being executed in the hardware by SWQ interface, SIOV uses Process
> +Address Space ID (PASID), which is a 20bit number defined by the PCIe SIG.
> +
> +PASID value is encoded in all transactions from the device. This allows
> +the IOMMU to track I/O on a per-PASID granularity in addition to using
> +the PCIe Resource Identifier (RID) which is the Bus/Device/Function.
> +
> +
> +ENQCMD
> +==
> +
> +ENQCMD is a new instruction on Intel platforms that atomically submits
> +a work descriptor to a device. The descriptor includes the operation to
> +be performed, virtual addresses of all parameters, virtual address of a
> +completion record, and the PASID (process address space ID) of the current 
> process.
> +
> +ENQCMD works with non-posted semantics and carries a status back if the
> +command was accepted by hardware. This allows the submitter to know if
> +the submission needs to be retried or other device specific mechanisms
> +to implement fairness or ensure forward progress can be made.
> +
> +ENQCMD is the glue that ensures applications can directly submit
> +commands to the hardware and also permit hardware to be aware of
> +application context to perform I/O operations via use of PASID.
> +

maybe a reader will ask about ENQCMDs after reading ENQCMD/S spec. :-)

> +Process Address Space Tagging
> +=
> +
> +A new thread scoped MSR (IA32_PASID) provides the connection between
> +user processes and the rest of the hardware. When an application first
> +accesses an SVA capable device this MSR is initialized with a newly
> +allocated PASID. The driver for the device calls an IOMMU specific api
> +that sets up the routing for DMA and page-requests.
> +
> +For example, the Intel Data Streaming 

Re: [for-next][PATCH 04/18] x86/ftrace: Do not jump to direct code in created trampolines

[Steven Rostedt]

On Fri, 3 Jul 2020 10:10:00 +0200
Peter Zijlstra  wrote:

> On Thu, Jul 02, 2020 at 05:58:16PM -0400, Steven Rostedt wrote:
> 
> > +   /* No need to test direct calls on created trampolines */
> > +   if (ops->flags & FTRACE_OPS_FL_SAVE_REGS) {
> > +   /* NOP the jnz 1f; but make sure it's a 2 byte jnz */
> > +   ip = trampoline + (jmp_offset - start_offset);
> > +   if (WARN_ON(*(char *)ip != 0x75))
> > +   goto fail;
> > +   ret = copy_from_kernel_nofault(ip, ideal_nops[2], 2);  
> 
> I really don't get this paranoia, what's wrong with memcpy() ?

Habit. As when ftrace was introduced, it was extremely careful about
touching memory like this. And even with all of that extra care, we
still broke NICs (actually, some of the reason those NICs broke was
because of the extra care we took :-p)

> 
> > +   if (ret < 0)
> > +   goto fail;
> > +   }  
> 
> How about something like this?
> 
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -359,17 +359,11 @@ create_trampoline(struct ftrace_ops *ops
>   npages = DIV_ROUND_UP(*tramp_size, PAGE_SIZE);
>  
>   /* Copy ftrace_caller onto the trampoline memory */
> - ret = copy_from_kernel_nofault(trampoline, (void *)start_offset, size);
> - if (WARN_ON(ret < 0))
> - goto fail;
> -
> - ip = trampoline + size;
> + memcpy(trampoline, (void *)start_offset, size);
>  
>   /* The trampoline ends with ret(q) */
> - retq = (unsigned long)ftrace_stub;
> - ret = copy_from_kernel_nofault(ip, (void *)retq, RET_SIZE);
> - if (WARN_ON(ret < 0))
> - goto fail;
> + ip = trampoline + size;
> + memcpy(ip, text_gen_insn(RET_INSN_OPCODE, NULL, NULL), RET_INSN_SIZE);
>  
>   /* No need to test direct calls on created trampolines */
>   if (ops->flags & FTRACE_OPS_FL_SAVE_REGS) {
> @@ -377,9 +371,7 @@ create_trampoline(struct ftrace_ops *ops
>   ip = trampoline + (jmp_offset - start_offset);
>   if (WARN_ON(*(char *)ip != 0x75))
>   goto fail;
> - ret = copy_from_kernel_nofault(ip, ideal_nops[2], 2);
> - if (ret < 0)
> - goto fail;
> + memcpy(ip, ideal_nops[2], 2);

If you want to add this change on top of this, then I'm fine with that.

If it breaks something, I can at least point the blame at you ;-)

-- Steve


>   }
>  
>   /*

[PATCH v2] checkpatch: Fix the usage of capture group ( ... )

[Mrinal Pandey]

The usage of "capture group (...)" in the immediate condition after `&&`
results in `$1` being uninitialized. This issues a warning "Use of
uninitialized value $1 in regexp compilation at ./scripts/checkpatch.pl
line 2638".

I noticed this bug while running checkpatch on the set of commits from
v5.7 to v5.8-rc1 of the kernel on the commits with a diff content in
their commit message.

This bug was introduced in the script by commit e518e9a59ec3
("checkpatch: emit an error when there's a diff in a changelog"). It has
been in the script since then.

The author intended to store the match made by capture group in variable
`$1`. This should have contained the name of the file as `[\w/]+` matched.
However, this couldn't be accomplished due to usage of capture group and
`$1` in the same regular expression.

Fix this by placing the capture group in the condition before `&&`.
Thus, `$1` can be initialized to the text that capture group matches
thereby setting it to the desired and required value.

Reviewed-by: Lukas Bulwahn 
Tested-by: Lukas Bulwahn 
Signed-off-by: Mrinal Pandey 
---
Changes since v1:
Add Reviewed-by and Tested-by tag

 scripts/checkpatch.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 4c820607540b..e73e998d582a 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2636,8 +2636,8 @@ sub process {
 
 # Check if the commit log has what seems like a diff which can confuse patch
if ($in_commit_log && !$commit_log_has_diff &&
-   (($line =~ m@^\s+diff\b.*a/[\w/]+@ &&
- $line =~ m@^\s+diff\b.*a/([\w/]+)\s+b/$1\b@) ||
+   (($line =~ m@^\s+diff\b.*a/([\w/]+)@ &&
+ $line =~ m@^\s+diff\b.*a/[\w/]+\s+b/$1\b@) ||
 $line =~ m@^\s*(?:\-\-\-\s+a/|\+\+\+\s+b/)@ ||
 $line =~ m/^\s*\@\@ \-\d+,\d+ \+\d+,\d+ \@\@/)) {
ERROR("DIFF_IN_COMMIT_MSG",
-- 
2.25.1



signature.asc
Description: PGP signature

[PATCH v2] Since am437x have the same clock structure with am335x [1][2], reuse the code from Tony Lindgren's patch [3] to fix dcan probe failed on am437x platform.

[dillon . minfei]

From: dillon min 

Fixes: 1a5cd7c23cc5 ("bus: ti-sysc: Enable all clocks directly during init to 
read revision")

[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")

Signed-off-by: dillon min 
---

Hi Stephen,

This changes correct commit messages based on your reviewing.
make Fixes tags to oneline.
make all commit message tags at the end of commit message


 arch/arm/boot/dts/am437x-l4.dtsi | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
index 0d0f9fe4a882..4129affde54e 100644
--- a/arch/arm/boot/dts/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/am437x-l4.dtsi
@@ -1541,8 +1541,9 @@
reg = <0xcc020 0x4>;
reg-names = "rev";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
-   clocks = <_clkctrl AM4_L4LS_D_CAN0_CLKCTRL 0>;
-   clock-names = "fck";
+   clocks = <_clkctrl AM4_L4LS_D_CAN0_CLKCTRL 0>,
+   <_fck>;
+   clock-names = "fck", "osc";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xcc000 0x2000>;
@@ -1550,6 +1551,8 @@
dcan0: can@0 {
compatible = "ti,am4372-d_can", 
"ti,am3352-d_can";
reg = <0x0 0x2000>;
+   clocks = <_fck>;
+   clock-names = "fck";
syscon-raminit = <_conf 0x644 0>;
interrupts = ;
status = "disabled";
@@ -1561,8 +1564,9 @@
reg = <0xd0020 0x4>;
reg-names = "rev";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
-   clocks = <_clkctrl AM4_L4LS_D_CAN1_CLKCTRL 0>;
-   clock-names = "fck";
+   clocks = <_clkctrl AM4_L4LS_D_CAN1_CLKCTRL 0>,
+   <_fck>;
+   clock-names = "fck", "osc";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0xd 0x2000>;
@@ -1570,6 +1574,8 @@
dcan1: can@0 {
compatible = "ti,am4372-d_can", 
"ti,am3352-d_can";
reg = <0x0 0x2000>;
+   clocks = <_fck>;
+   clock-name = "fck";
syscon-raminit = <_conf 0x644 1>;
interrupts = ;
status = "disabled";
-- 
2.7.4

Re: [PATCH] nvme: Remove redundant validation in nvme_start_ctrl()

[Baolin Wang]

On Mon, Jul 13, 2020 at 11:58:18PM +, Chaitanya Kulkarni wrote:
> On 7/12/20 23:31, Baolin Wang wrote:
> > We've already validated the 'kato' in nvme_start_keep_alive(), thus no
> > need to validate it again in nvme_start_ctrl(). Remove it.
> > 
> > Signed-off-by: Baolin Wang 
> > ---
> >   drivers/nvme/host/core.c | 3 +--
> >   1 file changed, 1 insertion(+), 2 deletions(-)
> > 
> > diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> > index 3d00ea4..a95e26e 100644
> > --- a/drivers/nvme/host/core.c
> > +++ b/drivers/nvme/host/core.c
> > @@ -4313,8 +4313,7 @@ void nvme_stop_ctrl(struct nvme_ctrl *ctrl)
> >   
> >   void nvme_start_ctrl(struct nvme_ctrl *ctrl)
> >   {
> > -   if (ctrl->kato)
> > -   nvme_start_keep_alive(ctrl);
> > +   nvme_start_keep_alive(ctrl);
> >   
> > nvme_enable_aen(ctrl);
> >   
> > 
> 
> Since start keep alive is so small to make a function call how about we 
> in-line the call ? untested patch :-

I am Okay about your suggestion. Will send v2 with your suggested-by tag
if no other objection. Thanks.

> 
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 09abf2ca33f5..c7289c23658a 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -4311,8 +4311,9 @@ EXPORT_SYMBOL_GPL(nvme_stop_ctrl);
> 
>   void nvme_start_ctrl(struct nvme_ctrl *ctrl)
>   {
> +   /* if ctrl keep alive time out is set start keep alive */
>  if (ctrl->kato)
> -   nvme_start_keep_alive(ctrl);
> +   queue_delayed_work(nvme_wq, >ka_work, ctrl->kato * 
> HZ);
> 
>  nvme_enable_aen(ctrl);
> 
> root@iouring nvme (xarray) # git diff
> diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
> index 09abf2ca33f5..08e1a6826b08 100644
> --- a/drivers/nvme/host/core.c
> +++ b/drivers/nvme/host/core.c
> @@ -1031,14 +1031,6 @@ static void nvme_keep_alive_work(struct 
> work_struct *work)
>  }
>   }
> 
> -static void nvme_start_keep_alive(struct nvme_ctrl *ctrl)
> -{
> -   if (unlikely(ctrl->kato == 0))
> -   return;
> -
> -   queue_delayed_work(nvme_wq, >ka_work, ctrl->kato * HZ);
> -}
> -
>   void nvme_stop_keep_alive(struct nvme_ctrl *ctrl)
>   {
>  if (unlikely(ctrl->kato == 0))
> @@ -4311,8 +4303,9 @@ EXPORT_SYMBOL_GPL(nvme_stop_ctrl);
> 
>   void nvme_start_ctrl(struct nvme_ctrl *ctrl)
>   {
> +   /* if ctrl keep alive time out is set start keep alive */
>  if (ctrl->kato)
> -   nvme_start_keep_alive(ctrl);
> +   queue_delayed_work(nvme_wq, >ka_work, ctrl->kato * 
> HZ);
> 
>  nvme_enable_aen(ctrl);
> 
> 

[PATCH v2] ARM: dts: Configure osc clock for d_can on am437x

[dillon . minfei]

From: dillon min 

V1 -> V2:
correct commit messages based on Stephen Rothwell's reviewing.
make Fixes tags to oneline.
make all commit message tags at the end of commit message


V1:
Got following d_can probe errors with kernel 5.8-rc1 on am437x

[   10.730822] CAN device driver interface
Starting Wait for Network to be Configured...
[  OK  ] Reached target Network.
[   10.787363] c_can_platform 481cc000.can: probe failed
[   10.792484] c_can_platform: probe of 481cc000.can failed with
error -2
[   10.799457] c_can_platform 481d.can: probe failed
[   10.804617] c_can_platform: probe of 481d.can failed with
error -2

actually, Tony has fixed this issue on am335x, the patch [3]
commit messages:
"
The reason why the issue happens is because we now attempt to read the
interconnect target module revision register by first manually enabling
all the device clocks in sysc_probe(). And looks like d_can also needs
the osc clock in addition to the module clock, and it may or may not be
enabled depending on the bootloader version and if other devices have
already requested osc clock.

Let's fix the issue by adding osc clock as an optional clock for the
module for am335x. Note that am437x does not seem to list the osc clock
at all, so presumably it is not needed for am437x.
"

from TRM of am335x/am437x [1][2], they have the same clock structure,
so, we can just reuse [3] for am437x platform.

Tested on custom am4372 board.

[1]: https://www.ti.com/lit/pdf/spruh73 Chapter-23, Figure 23-1. DCAN
Integration
[2]: https://www.ti.com/lit/pdf/spruhl7 Chapter-25, Figure 25-1. DCAN
Integration
[3]: commit 516f1117d0fb ("ARM: dts: Configure osc clock for d_can on am335x")


dillon min (1):
  Since am437x have the same clock structure with am335x [1][2],
reuse the code from Tony Lindgren's patch [reference] to fix dcan
probe failed on am437x platform.

 arch/arm/boot/dts/am437x-l4.dtsi | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

-- 
2.7.4

Re: [PATCH] mm: mmap: Merge vma after call_mmap() if possible

[Andrew Morton]

On Tue, 14 Jul 2020 11:07:44 +0800 linmiaohe  wrote:

> The vm_flags may be changed after call_mmap() because drivers may set some
> flags for their own purpose. As a result, we failed to merge the adjacent
> vma due to the different vm_flags as userspace can't pass in the same one.
> Try to merge vma after call_mmap() to fix this issue.

Which drivers do this?

Re: [PATCH v2 1/2] dt-bindings: devapc: add bindings for mtk-devapc

[Neal Liu]

On Fri, 2020-07-10 at 18:41 +0800, Matthias Brugger wrote:
> 
> On 09/07/2020 11:12, Neal Liu wrote:
> > Add bindings for mtk-devapc.
> > 
> > Signed-off-by: Neal Liu 
> > ---
> >   .../devicetree/bindings/soc/mediatek/devapc.yaml   |   82 
> > 
> >   1 file changed, 82 insertions(+)
> >   create mode 100644 
> > Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> > 
> > diff --git a/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml 
> > b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> > new file mode 100644
> > index 000..f08243e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/soc/mediatek/devapc.yaml
> > @@ -0,0 +1,82 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +# # Copyright 2020 MediaTek Inc.
> > +%YAML 1.2
> > +---
> > +$id: 
> > "https://urldefense.com/v3/__http://devicetree.org/schemas/soc/mediatek/devapc.yaml*__;Iw!!CTRNKA9wMg0ARbw!1TwSriUtXU2ZjXdZkLODgduBZYDtG23ix3jRxqvN3bdfV29MaK0FUZ5OrDu7VDBq$
> >  "
> > +$schema: 
> > "https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!1TwSriUtXU2ZjXdZkLODgduBZYDtG23ix3jRxqvN3bdfV29MaK0FUZ5OrNG2oecr$
> >  "
> > +
> > +title: MediaTek Device Access Permission Control driver
> > +
> > +description: |
> > +  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 and countermeasures.
> > +
> > +maintainers:
> > +  - Neal Liu 
> > +
> > +properties:
> > +  compatible:
> > +enum:
> > +  - mediatek,mt6779-devapc
> > +
> > +  reg:
> > +description: The base address of devapc register bank
> > +maxItems: 1
> > +
> > +  interrupts:
> > +description: A single interrupt specifier
> > +maxItems: 1
> > +
> > +  clocks:
> > +description: Contains module clock source and clock names
> > +maxItems: 1
> > +
> > +  clock-names:
> > +description: Names of the clocks list in clocks property
> > +maxItems: 1
> > +
> > +  mediatek-slv_type_num:
> > +description: Numbers of slave type in mediatek platform
> > +maxItems: 1
> 
> This should go in the DT data, have a look for example at:
> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/drivers/soc/mediatek/mtk-pmic-wrap.c*L1842__;Iw!!CTRNKA9wMg0ARbw!1TwSriUtXU2ZjXdZkLODgduBZYDtG23ix3jRxqvN3bdfV29MaK0FUZ5OrGIX64pv$
>  
> and
> https://urldefense.com/v3/__https://elixir.bootlin.com/linux/latest/source/drivers/soc/mediatek/mtk-pmic-wrap.c*L1777__;Iw!!CTRNKA9wMg0ARbw!1TwSriUtXU2ZjXdZkLODgduBZYDtG23ix3jRxqvN3bdfV29MaK0FUZ5OrFN70av_$
>  
> 

Okay, I'll try to follow this example.

> > +
> > +  mediatek-vio_dbgs:
> > +description: The mask bit and start bit of devapc violation debug 
> > registers
> > +maxItems: 5
> > +
> 
> same here
> 
> > +  mediatek-pds_offset:
> > +description: The offset of devapc pds registers
> > +maxItems: 1
> 
> same here
> 
> > +
> > +required:
> > +  - compatible
> > +  - reg
> > +  - interrupts
> > +  - clocks
> > +  - clock-names
> > +  - mediatek-slv_type_num
> > +  - mediatek-vio_dbgs
> > +  - mediatek-pds_offset
> > +
> > +examples:
> > +  - |
> > +#include 
> > +#include 
> > +
> > +devapc: devapc@10207000 {
> > +  compatible = "mediatek,mt6779-devapc";
> > +  reg = <0x10207000 0x1000>;
> > +  interrupts = ;
> > +  clocks = <_ao CLK_INFRA_DEVICE_APC>;
> > +  clock-names = "devapc-infra-clock";
> > +
> > +  mediatek-slv_type_num = /bits/ 8 <1>;
> > +  mediatek-vio_dbgs = <0x 0x0>,
> > +  <0x003F 0x10>,
> > +  <0x0040 0x16>,
> > +  <0x0080 0x17>,
> > +  <0x0F00 0x18>;
> > +  mediatek-pds_offset = <0x0 0x400 0x900 0x904
> > + 0xF00 0xF10 0xF14 0xF20>;
> > +};
> > 
> 
> ___
> Linux-mediatek mailing list
> linux-media...@lists.infradead.org
> https://urldefense.com/v3/__http://lists.infradead.org/mailman/listinfo/linux-mediatek__;!!CTRNKA9wMg0ARbw!1TwSriUtXU2ZjXdZkLODgduBZYDtG23ix3jRxqvN3bdfV29MaK0FUZ5OrOXSJ2_W$
>  

Re: [PATCH v2] dt-bindings: usb: ti,keystone-dwc3.yaml: Improve schema

[Rob Herring]

On Fri, 10 Jul 2020 14:33:37 +0300, Roger Quadros wrote:
> There were some review comments after the patch was integrated.
> Address those.
> 
> Fixes: 1883a934e156 ("dt-bindings: usb: convert keystone-usb.txt to YAML")
> Signed-off-by: Roger Quadros 
> ---
>  .../bindings/usb/ti,keystone-dwc3.yaml| 51 ++-
>  1 file changed, 37 insertions(+), 14 deletions(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH v2 2/5] dt-bindings: arm: Add Keem Bay bindings

[Rob Herring]

On Wed, Jul 08, 2020 at 06:50:17PM +0100, Daniele Alessandrelli wrote:
> From: Daniele Alessandrelli 
> 
> Document Intel Movidius SoC code-named Keem Bay, along with the Keem Bay
> EVM board.
> 
> Reviewed-by: Dinh Nguyen 
> Signed-off-by: Daniele Alessandrelli 
> ---
>  .../devicetree/bindings/arm/keembay.yaml  |  19 ++

>  include/dt-bindings/clock/keembay-clocks.h| 188 ++
>  include/dt-bindings/power/keembay-power.h |  19 ++

These belong with the clock and power bindings.

>  3 files changed, 226 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/keembay.yaml
>  create mode 100644 include/dt-bindings/clock/keembay-clocks.h
>  create mode 100644 include/dt-bindings/power/keembay-power.h
> 
> diff --git a/Documentation/devicetree/bindings/arm/keembay.yaml 
> b/Documentation/devicetree/bindings/arm/keembay.yaml
> new file mode 100644
> index ..f81b110046ca
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/keembay.yaml
> @@ -0,0 +1,19 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/arm/keembay.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Keem Bay platform device tree bindings
> +
> +maintainers:
> +  - Paul J. Murphy 
> +  - Daniele Alessandrelli 
> +
> +properties:
> +  compatible:
> +items:
> +  - enum:
> +- intel,keembay-evm
> +  - const: intel,keembay
> +...
> diff --git a/include/dt-bindings/clock/keembay-clocks.h 
> b/include/dt-bindings/clock/keembay-clocks.h
> new file mode 100644
> index ..a68e986dd565
> --- /dev/null
> +++ b/include/dt-bindings/clock/keembay-clocks.h
> @@ -0,0 +1,188 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (c) 2020 Intel Corporation.
> + *
> + * Device tree defines for clocks in Keem Bay.
> + */
> +
> +#ifndef __DT_BINDINGS_KEEMBAY_CLOCKS_H
> +#define __DT_BINDINGS_KEEMBAY_CLOCKS_H
> +
> +/* CPR_PLL region. CLK_ID: 0 - 11 */
> +#define KEEM_BAY_A53_PLL_START_ID (0)
> +#define KEEM_BAY_A53_PLL_0_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 0)
> +#define KEEM_BAY_A53_PLL_0_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 1)
> +#define KEEM_BAY_A53_PLL_0_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 2)
> +#define KEEM_BAY_A53_PLL_0_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 3)
> +#define KEEM_BAY_A53_PLL_1_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 4)
> +#define KEEM_BAY_A53_PLL_1_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 5)
> +#define KEEM_BAY_A53_PLL_1_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 6)
> +#define KEEM_BAY_A53_PLL_1_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 7)
> +#define KEEM_BAY_A53_PLL_2_OUT_0 (KEEM_BAY_A53_PLL_START_ID + 8)
> +#define KEEM_BAY_A53_PLL_2_OUT_1 (KEEM_BAY_A53_PLL_START_ID + 9)
> +#define KEEM_BAY_A53_PLL_2_OUT_2 (KEEM_BAY_A53_PLL_START_ID + 10)
> +#define KEEM_BAY_A53_PLL_2_OUT_3 (KEEM_BAY_A53_PLL_START_ID + 11)
> +#define KEEM_BAY_A53_PLL_MAX_ID (KEEM_BAY_A53_PLL_2_OUT_3)
> +
> +/* A53_CPR region. CLK_ID: 12 - 30 */
> +#define KEEM_BAY_A53_START_ID (KEEM_BAY_A53_PLL_MAX_ID + 1)
> +#define KEEM_BAY_A53_AON (KEEM_BAY_A53_START_ID + 0)
> +#define KEEM_BAY_A53_NOC (KEEM_BAY_A53_START_ID + 1)
> +#define KEEM_BAY_A53_FUSE (KEEM_BAY_A53_START_ID + 2)
> +#define KEEM_BAY_A53_ROM (KEEM_BAY_A53_START_ID + 3)
> +#define KEEM_BAY_A53_ICB (KEEM_BAY_A53_START_ID + 4)
> +#define KEEM_BAY_A53_GIC (KEEM_BAY_A53_START_ID + 5)
> +#define KEEM_BAY_A53_TIM (KEEM_BAY_A53_START_ID + 6)
> +#define KEEM_BAY_A53_GPIO (KEEM_BAY_A53_START_ID + 7)
> +#define KEEM_BAY_A53_JTAG (KEEM_BAY_A53_START_ID + 8)
> +#define KEEM_BAY_A53_MBIST_0 (KEEM_BAY_A53_START_ID + 9)
> +#define KEEM_BAY_A53_DSS (KEEM_BAY_A53_START_ID + 10)
> +#define KEEM_BAY_A53_MSS (KEEM_BAY_A53_START_ID + 11)
> +#define KEEM_BAY_A53_PSS (KEEM_BAY_A53_START_ID + 12)
> +#define KEEM_BAY_A53_PCIE (KEEM_BAY_A53_START_ID + 13)
> +#define KEEM_BAY_A53_VENC (KEEM_BAY_A53_START_ID + 14)
> +#define KEEM_BAY_A53_VDEC (KEEM_BAY_A53_START_ID + 15)
> +#define KEEM_BAY_A53_MBIST_1 (KEEM_BAY_A53_START_ID + 16)
> +#define KEEM_BAY_A53_MBIST_2 (KEEM_BAY_A53_START_ID + 17)
> +#define KEEM_BAY_A53_MBIST_3 (KEEM_BAY_A53_START_ID + 18)
> +#define KEEM_BAY_A53_MAX_ID (KEEM_BAY_A53_MBIST_3)
> +
> +/* A53_CPR_AUX region. CLK_ID: 31 - 57 */
> +#define KEEM_BAY_A53_AUX_START_ID (KEEM_BAY_A53_MAX_ID + 1)
> +#define KEEM_BAY_A53_AUX_32KHZ (KEEM_BAY_A53_AUX_START_ID + 0)
> +#define KEEM_BAY_A53_AUX_CPR (KEEM_BAY_A53_AUX_START_ID + 1)
> +#define KEEM_BAY_A53_AUX_TSENS (KEEM_BAY_A53_AUX_START_ID + 2)
> +#define KEEM_BAY_A53_AUX_GPIO0 (KEEM_BAY_A53_AUX_START_ID + 3)
> +#define KEEM_BAY_A53_AUX_GPIO1 (KEEM_BAY_A53_AUX_START_ID + 4)
> +#define KEEM_BAY_A53_AUX_GPIO2 (KEEM_BAY_A53_AUX_START_ID + 5)
> +#define KEEM_BAY_A53_AUX_GPIO3 (KEEM_BAY_A53_AUX_START_ID + 6)
> +#define KEEM_BAY_A53_AUX_DDR_REF (KEEM_BAY_A53_AUX_START_ID + 7)
> +#define KEEM_BAY_A53_AUX_DDR_REF_BYPASS (KEEM_BAY_A53_AUX_START_ID + 8)
> +#define KEEM_BAY_A53_AUX_RESERVED1 (KEEM_BAY_A53_AUX_START_ID + 9)
> 

Re: [PATCH v2 4/4] dt-bindings: clk: versaclock5: convert to yaml

[Rob Herring]

On Wed, Jul 08, 2020 at 09:40:35AM +0200, Luca Ceresoli wrote:
> Convert to yaml the VersaClock bindings document. The mapping between
> clock specifier and physical pins cannot be described formally in yaml
> schema, then keep it verbatim in the description field.
> 
> Signed-off-by: Luca Ceresoli 
> ---
>  .../bindings/clock/idt,versaclock5.txt| 125 --
>  .../bindings/clock/idt,versaclock5.yaml   | 160 ++
>  MAINTAINERS   |   1 +
>  3 files changed, 161 insertions(+), 125 deletions(-)
>  delete mode 100644 
> Documentation/devicetree/bindings/clock/idt,versaclock5.txt
>  create mode 100644 
> Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> 
> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt 
> b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> deleted file mode 100644
> index 9656d4cf221c..
> --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
> +++ /dev/null
> @@ -1,125 +0,0 @@
> -Binding for IDT VersaClock 5,6 programmable i2c clock generators.
> -
> -The IDT VersaClock 5 and VersaClock 6 are programmable i2c clock
> -generators providing from 3 to 12 output clocks.
> -
> -==I2C device node==
> -
> -Required properties:
> -- compatible:shall be one of
> - "idt,5p49v5923"
> - "idt,5p49v5925"
> - "idt,5p49v5933"
> - "idt,5p49v5935"
> - "idt,5p49v6901"
> - "idt,5p49v6965"
> -- reg:   i2c device address, shall be 0x68 or 0x6a.
> -- #clock-cells:  from common clock binding; shall be set to 1.
> -- clocks:from common clock binding; list of parent clock handles,
> - - 5p49v5923 and
> -   5p49v5925 and
> -   5p49v6901: (required) either or both of XTAL or CLKIN
> - reference clock.
> - - 5p49v5933 and
> - - 5p49v5935: (optional) property not present (internal
> - Xtal used) or CLKIN reference
> - clock.
> -- clock-names:   from common clock binding; clock input names, can be
> - - 5p49v5923 and
> -   5p49v5925 and
> -   5p49v6901: (required) either or both of "xin", "clkin".
> - - 5p49v5933 and
> - - 5p49v5935: (optional) property not present or "clkin".
> -
> -For all output ports, a corresponding, optional child node named OUT1,
> -OUT2, etc. can represent a each output, and the node can be used to
> -specify the following:
> -
> -- idt,mode: can be one of the following:
> - - VC5_LVPECL
> - - VC5_CMOS
> - - VC5_HCSL33
> - - VC5_LVDS
> - - VC5_CMOS2
> - - VC5_CMOSD
> - - VC5_HCSL25
> -
> -- idt,voltage-microvolts:  can be one of the following
> - - 180
> - - 250
> - - 330
> --  idt,slew-percent: Percent of normal, can be one of
> - - 80
> - - 85
> - - 90
> - - 100
> -
> -==Mapping between clock specifier and physical pins==
> -
> -When referencing the provided clock in the DT using phandle and
> -clock specifier, the following mapping applies:
> -
> -5P49V5923:
> - 0 -- OUT0_SEL_I2CB
> - 1 -- OUT1
> - 2 -- OUT2
> -
> -5P49V5933:
> - 0 -- OUT0_SEL_I2CB
> - 1 -- OUT1
> - 2 -- OUT4
> -
> -5P49V5925 and
> -5P49V5935:
> - 0 -- OUT0_SEL_I2CB
> - 1 -- OUT1
> - 2 -- OUT2
> - 3 -- OUT3
> - 4 -- OUT4
> -
> -5P49V6901:
> - 0 -- OUT0_SEL_I2CB
> - 1 -- OUT1
> - 2 -- OUT2
> - 3 -- OUT3
> - 4 -- OUT4
> -
> -==Example==
> -
> -/* 25MHz reference crystal */
> -ref25: ref25m {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <2500>;
> -};
> -
> -i2c-master-node {
> -
> - /* IDT 5P49V5923 i2c clock generator */
> - vc5: clock-generator@6a {
> - compatible = "idt,5p49v5923";
> - reg = <0x6a>;
> - #clock-cells = <1>;
> -
> - /* Connect XIN input to 25MHz reference */
> - clocks = <>;
> - clock-names = "xin";
> -
> - OUT1 {
> - idt,mode = ;
> - idt,voltage-microvolts = <180>;
> - idt,slew-percent = <80>;
> - };
> - OUT2 {
> - ...
> - };
> - ...
> - };
> -};
> -
> -/* Consumer referencing the 5P49V5923 pin OUT1 */
> -consumer {
> - ...
> - clocks = < 1>;
> - ...
> -}
> diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml 
> b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
> new file mode 100644
> index ..4bdfd6187b48
> --- /dev/null
> 

Re: possible deadlock in shmem_fallocate (4)

[syzbot]

syzbot has found a reproducer for the following crash on:

HEAD commit:11ba4688 Linux 5.8-rc5
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=175391fb10
kernel config:  https://syzkaller.appspot.com/x/.config?x=a160d1053fc89af5
dashboard link: https://syzkaller.appspot.com/bug?extid=7a0d9d0b26efefe61780
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=104d9c7710
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1343e95d10

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

==
WARNING: possible circular locking dependency detected
5.8.0-rc5-syzkaller #0 Not tainted
--
khugepaged/1158 is trying to acquire lock:
8882071865b0 (>s_type->i_mutex_key#15){+.+.}-{3:3}, at: inode_lock 
include/linux/fs.h:800 [inline]
8882071865b0 (>s_type->i_mutex_key#15){+.+.}-{3:3}, at: 
shmem_fallocate+0x153/0xd90 mm/shmem.c:2707

but task is already holding lock:
89c6c260 (fs_reclaim){+.+.}-{0:0}, at: fs_reclaim_release 
mm/page_alloc.c:4202 [inline]
89c6c260 (fs_reclaim){+.+.}-{0:0}, at: fs_reclaim_release 
mm/page_alloc.c:4198 [inline]
89c6c260 (fs_reclaim){+.+.}-{0:0}, at: __perform_reclaim 
mm/page_alloc.c:4227 [inline]
89c6c260 (fs_reclaim){+.+.}-{0:0}, at: __alloc_pages_direct_reclaim 
mm/page_alloc.c:4244 [inline]
89c6c260 (fs_reclaim){+.+.}-{0:0}, at: 
__alloc_pages_slowpath.constprop.0+0x1554/0x2780 mm/page_alloc.c:4650

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (fs_reclaim){+.+.}-{0:0}:
   __fs_reclaim_acquire mm/page_alloc.c:4183 [inline]
   fs_reclaim_acquire mm/page_alloc.c:4194 [inline]
   prepare_alloc_pages mm/page_alloc.c:4780 [inline]
   __alloc_pages_nodemask+0x3d1/0x930 mm/page_alloc.c:4832
   alloc_pages_vma+0xdd/0x720 mm/mempolicy.c:2255
   shmem_alloc_page+0x11f/0x1f0 mm/shmem.c:1502
   shmem_alloc_and_acct_page+0x161/0x8a0 mm/shmem.c:1527
   shmem_getpage_gfp+0x511/0x2450 mm/shmem.c:1823
   shmem_getpage mm/shmem.c:153 [inline]
   shmem_write_begin+0xf9/0x1d0 mm/shmem.c:2459
   generic_perform_write+0x20a/0x4f0 mm/filemap.c:3318
   __generic_file_write_iter+0x24b/0x610 mm/filemap.c:3447
   generic_file_write_iter+0x3a6/0x5c0 mm/filemap.c:3479
   call_write_iter include/linux/fs.h:1908 [inline]
   new_sync_write+0x422/0x650 fs/read_write.c:503
   vfs_write+0x59d/0x6b0 fs/read_write.c:578
   ksys_write+0x12d/0x250 fs/read_write.c:631
   do_syscall_64+0x60/0xe0 arch/x86/entry/common.c:384
   entry_SYSCALL_64_after_hwframe+0x44/0xa9

-> #0 (>s_type->i_mutex_key#15){+.+.}-{3:3}:
   check_prev_add kernel/locking/lockdep.c:2496 [inline]
   check_prevs_add kernel/locking/lockdep.c:2601 [inline]
   validate_chain kernel/locking/lockdep.c:3218 [inline]
   __lock_acquire+0x2acb/0x56e0 kernel/locking/lockdep.c:4380
   lock_acquire+0x1f1/0xad0 kernel/locking/lockdep.c:4959
   down_write+0x8d/0x150 kernel/locking/rwsem.c:1531
   inode_lock include/linux/fs.h:800 [inline]
   shmem_fallocate+0x153/0xd90 mm/shmem.c:2707
   ashmem_shrink_scan.part.0+0x2e9/0x490 
drivers/staging/android/ashmem.c:490
   ashmem_shrink_scan+0x6c/0xa0 drivers/staging/android/ashmem.c:473
   do_shrink_slab+0x3c6/0xab0 mm/vmscan.c:518
   shrink_slab+0x16f/0x5c0 mm/vmscan.c:679
   shrink_node_memcgs mm/vmscan.c:2658 [inline]
   shrink_node+0x519/0x1b60 mm/vmscan.c:2770
   shrink_zones mm/vmscan.c:2973 [inline]
   do_try_to_free_pages+0x38b/0x1340 mm/vmscan.c:3026
   try_to_free_pages+0x29a/0x8b0 mm/vmscan.c:3265
   __perform_reclaim mm/page_alloc.c:4223 [inline]
   __alloc_pages_direct_reclaim mm/page_alloc.c:4244 [inline]
   __alloc_pages_slowpath.constprop.0+0x949/0x2780 mm/page_alloc.c:4650
   __alloc_pages_nodemask+0x68f/0x930 mm/page_alloc.c:4863
   __alloc_pages include/linux/gfp.h:509 [inline]
   __alloc_pages_node include/linux/gfp.h:522 [inline]
   khugepaged_alloc_page+0xa0/0x170 mm/khugepaged.c:867
   collapse_huge_page mm/khugepaged.c:1056 [inline]
   khugepaged_scan_pmd mm/khugepaged.c:1349 [inline]
   khugepaged_scan_mm_slot mm/khugepaged.c:2110 [inline]
   khugepaged_do_scan mm/khugepaged.c:2193 [inline]
   khugepaged+0x3093/0x5a10 mm/khugepaged.c:2238
   kthread+0x3b5/0x4a0 kernel/kthread.c:291
   ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293

other info that might help us debug this:

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(fs_reclaim);
   lock(>s_type->i_mutex_key#15);
   

Re: [PATCH v2 2/2] soc: mediatek: add mtk-devapc driver

[Neal Liu]

Hi Chun-Kuang,

On Mon, 2020-07-13 at 22:20 +0800, Chun-Kuang Hu wrote:
> Hi, Neal:
> 
> Neal Liu  於 2020年7月13日 週一 下午4:27寫道：
> >
> > Hi Chun-Kuang,
> >
> > Thanks for your review.
> >
> > On Fri, 2020-07-10 at 22:21 +0800, Chun-Kuang Hu wrote:
> > > Hi, Neal:
> > >
> > > Neal Liu  於 2020年7月10日 週五 上午11:23寫道：
> > > >
> > > > Hi Chun-Kuang,
> > > >
> > > > Thanks for your review.
> > > >
> > > > On Thu, 2020-07-09 at 21:01 +0800, Chun-Kuang Hu wrote:
> > > > > Hi, Neal:
> > > > >
> > > > > Neal Liu  於 2020年7月9日 週四 下午5:13寫道：
> > > > > >
> > > > > > 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 
> > > > >
> > > > > [snip]
> > > > >
> > > > > > +
> > > > > > +static u32 get_shift_group(struct mtk_devapc_context *devapc_ctx,
> > > > > > +  int slave_type, int vio_idx)
> > > > >
> > > > > vio_idx  is useless, so remove it.
> > > > >
> > > >
> > > > yes, my mistake. I'll remove it on next patch.
> > > >
> > > > > > +{
> > > > > > +   u32 vio_shift_sta;
> > > > > > +   void __iomem *reg;
> > > > > > +   int bit;
> > > > > > +
> > > > > > +   reg = mtk_devapc_pd_get(devapc_ctx, slave_type, 
> > > > > > VIO_SHIFT_STA, 0);
> > > > > > +   vio_shift_sta = readl(reg);
> > > > > > +
> > > > > > +   for (bit = 0; bit < 32; bit++) {
> > > > > > +   if ((vio_shift_sta >> bit) & 0x1)
> > > > > > +   break;
> > > > > > +   }
> > > > > > +
> > > > > > +   return bit;
> > > > > > +}
> > > > > > +
> > > > >
> > > > > [snip]
> > > > >
> > > > > > +
> > > > > > +/*
> > > > > > + * devapc_violation_irq - the devapc Interrupt Service Routine 
> > > > > > (ISR) will dump
> > > > > > + *   violation information including which 
> > > > > > master violates
> > > > > > + *   access slave.
> > > > > > + */
> > > > > > +static irqreturn_t devapc_violation_irq(int irq_number,
> > > > > > +   struct mtk_devapc_context 
> > > > > > *devapc_ctx)
> > > > > > +{
> > > > > > +   const struct mtk_device_info **device_info;
> > > > > > +   int slave_type_num;
> > > > > > +   int vio_idx = -1;
> > > > > > +   int slave_type;
> > > > > > +
> > > > > > +   slave_type_num = devapc_ctx->slave_type_num;
> > > > > > +   device_info = devapc_ctx->device_info;
> > > > > > +
> > > > > > +   for (slave_type = 0; slave_type < slave_type_num; 
> > > > > > slave_type++) {
> > > > >
> > > > > If slave_type_num is 1, I think the code should be simpler.
> > > >
> > > > slave_type_num is depends on DT data, it's not always 1.
> > >
> > > Please change commit title to "add mt6779 mtk-devapc driver". This
> > > patch is just for mt6779. If slave_type_num = 1 in mt6779, there is
> > > only one slave and we don't need a slave_type variable. Add
> > > slave_type_num in the patch of adding one SoC which has multiple
> > > slaves.
> >
> > If slave_type_num value is passed from DT data, could we still assume
> > its value? Does it make sense to have this strong assumption?
> 
> Maintainer has asked you to move this data from device tree to driver
> [1], I doubt you could get this data from device tree. Even though
> device tree has this property, this driver support only mt6779 now, so
> it's not necessary to have slave_type_num because slave type is only
> 1. I think we should not consider support multiple SoC in this patch.
> 
> [1] 
> https://urldefense.com/v3/__https://patchwork.kernel.org/patch/11653911/__;!!CTRNKA9wMg0ARbw!2H8CQE__ALAhGUhNaL7yB1LXLskBkymEfb2FST0jrbJgmOMKa8-AeJXMAyUkHjAl$
>  
> 

Okay, I'll follow maintainer's suggestion.

> >
> > I'm going to remove mtk_device_info struct array, and pass all SoC
> > specific data from DT.
> > Is it okay to keep slave_type_num as a variance?
> >
> > >
> > > >
> > > > >
> > > > > > +   if (!mtk_devapc_dump_vio_dbg(devapc_ctx, 
> > > > > > slave_type, _idx))
> > > > > > +   continue;
> > > > > > +
> > > > > > +   /* Ensure that violation info are written before
> > > > > > +* further operations
> > > > > > +*/
> > > > > > +   smp_mb();
> > > > > > +
> > > > > > +   mask_module_irq(devapc_ctx, slave_type, vio_idx, 
> > > > > > true);
> > > > >
> > > > > Why do you mask irq?
> > > >
> > > > It has to mask slave's irq before clear violation status.
> > > > It's one of hardware design.
> > >
> > > If don't do this before 

Re: [PATCH v2 1/4] dt-bindings: clk: versaclock5: fix 'idt' prefix typos

[Rob Herring]

On Wed, 08 Jul 2020 09:40:32 +0200, Luca Ceresoli wrote:
> 'idt' is misspelled 'itd' in a few places, fix it.
> 
> Fixes: 34662f6e3084 ("dt: Add additional option bindings for IDT VersaClock")
> Signed-off-by: Luca Ceresoli 
> ---
>  Documentation/devicetree/bindings/clock/idt,versaclock5.txt | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

[RFC PATCH 3/4] selftests: rseq: define __rseq_abi with extensible size

[Mathieu Desnoyers]

Define the __rseq_abi with the extensible size feature.

Signed-off-by: Mathieu Desnoyers 
---
 tools/testing/selftests/rseq/rseq.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tools/testing/selftests/rseq/rseq.c 
b/tools/testing/selftests/rseq/rseq.c
index da2264c679b9..2c29215d4790 100644
--- a/tools/testing/selftests/rseq/rseq.c
+++ b/tools/testing/selftests/rseq/rseq.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rseq.h"
 
@@ -33,6 +34,8 @@
 
 __thread volatile struct rseq __rseq_abi = {
.cpu_id = RSEQ_CPU_ID_UNINITIALIZED,
+   .flags = RSEQ_TLS_FLAG_SIZE,
+   .user_size = offsetof(struct rseq, end),
 };
 
 /*
-- 
2.17.1

[PATCH] mm: mmap: Merge vma after call_mmap() if possible

[linmiaohe]

From: Miaohe Lin 

The vm_flags may be changed after call_mmap() because drivers may set some
flags for their own purpose. As a result, we failed to merge the adjacent
vma due to the different vm_flags as userspace can't pass in the same one.
Try to merge vma after call_mmap() to fix this issue.

Signed-off-by: Hongxiang Lou 
Signed-off-by: Miaohe Lin 
---
 mm/mmap.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index 59a4682ebf3f..9568117471f8 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -1689,7 +1689,7 @@ unsigned long mmap_region(struct file *file, unsigned 
long addr,
struct list_head *uf)
 {
struct mm_struct *mm = current->mm;
-   struct vm_area_struct *vma, *prev;
+   struct vm_area_struct *vma, *prev, *merge;
int error;
struct rb_node **rb_link, *rb_parent;
unsigned long charged = 0;
@@ -1773,6 +1773,20 @@ unsigned long mmap_region(struct file *file, unsigned 
long addr,
if (error)
goto unmap_and_free_vma;
 
+   /* If vm_flags changed after call_mmap(), we should try merge 
vma again
+* as we may succeed this time.
+*/
+   if (unlikely(vm_flags != vma->vm_flags && prev)) {
+   merge = vma_merge(mm, prev, vma->vm_start, vma->vm_end, 
vma->vm_flags,
+   NULL, vma->vm_file, vma->vm_pgoff, NULL, 
NULL_VM_UFFD_CTX);
+   if (merge) {
+   fput(file);
+   vm_area_free(vma);
+   vma = merge;
+   goto unmap_writable;
+   }
+   }
+
/* Can addr have changed??
 *
 * Answer: Yes, several device drivers can do it in their
@@ -1795,6 +1809,7 @@ unsigned long mmap_region(struct file *file, unsigned 
long addr,
vma_link(mm, vma, prev, rb_link, rb_parent);
/* Once vma denies write, undo our temporary denial count */
if (file) {
+unmap_writable:
if (vm_flags & VM_SHARED)
mapping_unmap_writable(file->f_mapping);
if (vm_flags & VM_DENYWRITE)
-- 
2.19.1

[RFC PATCH 0/4] rseq: Introduce extensible struct rseq

[Mathieu Desnoyers]

Recent discussion led to a solution for extending struct rseq. This is
an implementation of the proposed solution.

Now is a good time to agree on this scheme before the release of glibc
2.32, just in case there are small details to fix on the user-space
side in order to allow extending struct rseq.

Thanks,

Mathieu

Mathieu Desnoyers (4):
  selftests: rseq: Use fixed value as rseq_len parameter
  rseq: Allow extending struct rseq
  selftests: rseq: define __rseq_abi with extensible size
  selftests: rseq: print rseq extensible size in basic test

 include/linux/sched.h |  4 +++
 include/uapi/linux/rseq.h | 42 --
 kernel/rseq.c | 44 +++
 tools/testing/selftests/rseq/basic_test.c | 15 
 tools/testing/selftests/rseq/rseq.c   |  8 +++--
 5 files changed, 101 insertions(+), 12 deletions(-)

-- 
2.17.1

[RFC PATCH 2/4] rseq: Allow extending struct rseq

[Mathieu Desnoyers]

Add a __rseq_abi.flags "RSEQ_TLS_FLAG_SIZE", which indicates support for
extending struct rseq. This adds two new fields to struct rseq:
user_size and kernel_size.

The user_size field allows the size of the __rseq_abi definition (which
can be overridden by symbol interposition either by a preloaded library
or by the application) to be handed over to the kernel at registration.
This registration can be performed by a library, e.g. glibc, which does
not know there is interposition taking place.

The kernel_size is populated by the kernel when the "RSEQ_TLS_FLAG_SIZE"
flag is set in __rseq_abi.flags to the minimum between user_size and
the offset of the "end" field of struct rseq as known by the kernel.
This allows user-space to query which fields are effectively populated
by the kernel.

A rseq_size field is added to the task struct to keep track of the
"kernel_size" effective for each thread.

Signed-off-by: Mathieu Desnoyers 
---
 include/linux/sched.h |  4 
 include/uapi/linux/rseq.h | 37 --
 kernel/rseq.c | 42 +--
 3 files changed, 75 insertions(+), 8 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 692e327d7455..5d61a3197987 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1147,6 +1147,7 @@ struct task_struct {
 #ifdef CONFIG_RSEQ
struct rseq __user *rseq;
u32 rseq_sig;
+   u32 rseq_size;
/*
 * RmW on rseq_event_mask must be performed atomically
 * with respect to preemption.
@@ -1976,10 +1977,12 @@ static inline void rseq_fork(struct task_struct *t, 
unsigned long clone_flags)
if (clone_flags & CLONE_VM) {
t->rseq = NULL;
t->rseq_sig = 0;
+   t->rseq_size = 0;
t->rseq_event_mask = 0;
} else {
t->rseq = current->rseq;
t->rseq_sig = current->rseq_sig;
+   t->rseq_size = current->rseq_size;
t->rseq_event_mask = current->rseq_event_mask;
}
 }
@@ -1988,6 +1991,7 @@ static inline void rseq_execve(struct task_struct *t)
 {
t->rseq = NULL;
t->rseq_sig = 0;
+   t->rseq_size = 0;
t->rseq_event_mask = 0;
 }
 
diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h
index e11d9df5e564..03c0b5e9a859 100644
--- a/include/uapi/linux/rseq.h
+++ b/include/uapi/linux/rseq.h
@@ -37,6 +37,15 @@ enum rseq_cs_flags {
(1U << RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE_BIT),
 };
 
+enum rseq_tls_flags_bit {
+   /* enum rseq_cs_flags reserves bits 0-2. */
+   RSEQ_TLS_FLAG_SIZE_BIT = 3,
+};
+
+enum rseq_tls_flags {
+   RSEQ_TLS_FLAG_SIZE = (1U << RSEQ_TLS_FLAG_SIZE_BIT),
+};
+
 /* The rseq_len expected by rseq registration is always 32 bytes. */
 enum rseq_len_expected {
RSEQ_LEN_EXPECTED = 32,
@@ -133,8 +142,9 @@ struct rseq {
 *
 * This field should only be updated by the thread which
 * registered this data structure. Read by the kernel.
-* Mainly used for single-stepping through rseq critical sections
-* with debuggers.
+*
+* The RSEQ_CS flags are mainly used for single-stepping through rseq
+* critical sections with debuggers.
 *
 * - RSEQ_CS_FLAG_NO_RESTART_ON_PREEMPT
 * Inhibit instruction sequence block restart on preemption
@@ -145,8 +155,31 @@ struct rseq {
 * - RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE
 * Inhibit instruction sequence block restart on migration for
 * this thread.
+*
+* - RSEQ_TLS_FLAG_SIZE
+* Extensible struct rseq ABI. This flag should be statically
+* initialized.
 */
__u32 flags;
+   /*
+* With __rseq_abi.flags RSEQ_TLS_FLAG_SIZE set, user_size should be
+* statically initialized to offsetof(struct rseq, end).
+*/
+   __u16 user_size;
+   /*
+* With __rseq_abi.flags RSEQ_TLS_FLAG_SIZE set, if the kernel supports
+* extensible struct rseq ABI, the kernel_size field is populated by
+* the kernel to the minimum between user_size and the offset of the
+* "end" field within the struct rseq supported by the kernel on
+* successful registration. Should be initialized to 0.
+*/
+   __u16 kernel_size;
+
+   /*
+* Very last field of the structure, to calculate size excluding padding
+* with offsetof().
+*/
+   char end[];
 } __attribute__((aligned(4 * sizeof(__u64;
 
 #endif /* _UAPI_LINUX_RSEQ_H */
diff --git a/kernel/rseq.c b/kernel/rseq.c
index a4f86a9d6937..bbc57fc18573 100644
--- a/kernel/rseq.c
+++ b/kernel/rseq.c
@@ -96,6 +96,7 @@ static int rseq_update_cpu_id(struct task_struct *t)
 static int rseq_reset_rseq_cpu_id(struct task_struct *t)
 {
u32 cpu_id_start = 0, cpu_id = RSEQ_CPU_ID_UNINITIALIZED;
+   u16 

[RFC PATCH 4/4] selftests: rseq: print rseq extensible size in basic test

[Mathieu Desnoyers]

Print whether extensible size feature is supported by the kernel
and __rseq_abi definition, along with the contents of the kernel_size
field if it is available.

Signed-off-by: Mathieu Desnoyers 
---
 tools/testing/selftests/rseq/basic_test.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/tools/testing/selftests/rseq/basic_test.c 
b/tools/testing/selftests/rseq/basic_test.c
index d8efbfb89193..976e040574a1 100644
--- a/tools/testing/selftests/rseq/basic_test.c
+++ b/tools/testing/selftests/rseq/basic_test.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rseq.h"
 
@@ -35,6 +36,17 @@ void test_cpu_pointer(void)
sched_setaffinity(0, sizeof(affinity), );
 }
 
+static void print_rseq_size(void)
+{
+   bool supported = (__rseq_abi.flags & RSEQ_TLS_FLAG_SIZE) && 
__rseq_abi.kernel_size != 0;
+
+   printf("extensible struct rseq supported: %s",
+   supported ? "yes" : "no");
+   if (supported)
+   printf(" (kernel_size=%" PRIu16 ")", __rseq_abi.kernel_size);
+   printf("\n");
+}
+
 int main(int argc, char **argv)
 {
if (rseq_register_current_thread()) {
@@ -42,6 +54,9 @@ int main(int argc, char **argv)
errno, strerror(errno));
goto init_thread_error;
}
+
+   print_rseq_size();
+
printf("testing current cpu\n");
test_cpu_pointer();
if (rseq_unregister_current_thread()) {
-- 
2.17.1

[RFC PATCH 1/4] selftests: rseq: Use fixed value as rseq_len parameter

[Mathieu Desnoyers]

The rseq registration and unregistration expect a fixed-size length
(32 bytes). In preparation to extend struct rseq, pass a fixed value
rather than the size of the rseq structure.

Signed-off-by: Mathieu Desnoyers 
---
 include/uapi/linux/rseq.h   | 5 +
 tools/testing/selftests/rseq/rseq.c | 5 ++---
 2 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/uapi/linux/rseq.h b/include/uapi/linux/rseq.h
index 9a402fdb60e9..e11d9df5e564 100644
--- a/include/uapi/linux/rseq.h
+++ b/include/uapi/linux/rseq.h
@@ -37,6 +37,11 @@ enum rseq_cs_flags {
(1U << RSEQ_CS_FLAG_NO_RESTART_ON_MIGRATE_BIT),
 };
 
+/* The rseq_len expected by rseq registration is always 32 bytes. */
+enum rseq_len_expected {
+   RSEQ_LEN_EXPECTED = 32,
+};
+
 /*
  * struct rseq_cs is aligned on 4 * 8 bytes to ensure it is always
  * contained within a single cache-line. It is usually declared as
diff --git a/tools/testing/selftests/rseq/rseq.c 
b/tools/testing/selftests/rseq/rseq.c
index 7159eb777fd3..da2264c679b9 100644
--- a/tools/testing/selftests/rseq/rseq.c
+++ b/tools/testing/selftests/rseq/rseq.c
@@ -87,7 +87,7 @@ int rseq_register_current_thread(void)
}
if (__rseq_refcount++)
goto end;
-   rc = sys_rseq(&__rseq_abi, sizeof(struct rseq), 0, RSEQ_SIG);
+   rc = sys_rseq(&__rseq_abi, RSEQ_LEN_EXPECTED, 0, RSEQ_SIG);
if (!rc) {
assert(rseq_current_cpu_raw() >= 0);
goto end;
@@ -115,8 +115,7 @@ int rseq_unregister_current_thread(void)
}
if (--__rseq_refcount)
goto end;
-   rc = sys_rseq(&__rseq_abi, sizeof(struct rseq),
- RSEQ_FLAG_UNREGISTER, RSEQ_SIG);
+   rc = sys_rseq(&__rseq_abi, RSEQ_LEN_EXPECTED, RSEQ_FLAG_UNREGISTER, 
RSEQ_SIG);
if (!rc)
goto end;
__rseq_refcount = 1;
-- 
2.17.1

Re: [PATCH v2 3/4] x86: Expose SERIALIZE for supported cpuid

[Sean Christopherson]

On Tue, Jul 07, 2020 at 10:16:22AM +0800, Cathy Zhang wrote:
> SERIALIZE instruction is supported by intel processors,
> like Sapphire Rapids. Expose it in KVM supported cpuid.

Providing at least a rough overview of the instruction, e.g. its enumeration,
usage, fault rules, controls, etc... would be nice.  In isolation, the
changelog isn't remotely helpful in understanding the correctness of the
patch.

> Signed-off-by: Cathy Zhang 
> ---
>  arch/x86/kvm/cpuid.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 8a294f9..e603aeb 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -341,7 +341,8 @@ void kvm_set_cpu_caps(void)
>   kvm_cpu_cap_mask(CPUID_7_EDX,
>   F(AVX512_4VNNIW) | F(AVX512_4FMAPS) | F(SPEC_CTRL) |
>   F(SPEC_CTRL_SSBD) | F(ARCH_CAPABILITIES) | F(INTEL_STIBP) |
> - F(MD_CLEAR) | F(AVX512_VP2INTERSECT) | F(FSRM)
> + F(MD_CLEAR) | F(AVX512_VP2INTERSECT) | F(FSRM) |
> + F(SERIALIZE)
>   );
>  
>   /* TSC_ADJUST and ARCH_CAPABILITIES are emulated in software. */
> -- 
> 1.8.3.1
> 

RE: [PATCH v6 01/12] iommu: Change type of pasid to u32

[Liu, Yi L]

> From: Fenghua Yu 
> Sent: Tuesday, July 14, 2020 7:48 AM
> 
> PASID is defined as a few different types in iommu including "int",
> "u32", and "unsigned int". To be consistent and to match with uapi
> definitions, define PASID and its variations (e.g. max PASID) as "u32".
> "u32" is also shorter and a little more explicit than "unsigned int".
> 
> No PASID type change in uapi although it defines PASID as __u64 in
> some places.

just out of curious, why not using ioasid_t? In Linux kernel, PASID is
managed by ioasid.

Regards,
Yi Liu

> Suggested-by: Thomas Gleixner 
> Signed-off-by: Fenghua Yu 
> Reviewed-by: Tony Luck 
> Reviewed-by: Lu Baolu 
> Acked-by: Felix Kuehling 
> ---
> v6:
> - Change return type to u32 for kfd_pasid_alloc() (Felix)
> 
> v5:
> - Reviewed by Lu Baolu
> 
> v4:
> - Change PASID type from "unsigned int" to "u32" (Christoph)
> 
> v2:
> - Create this new patch to define PASID as "unsigned int" consistently in
>   iommu (Thomas)
> 
>  drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|  4 +--
>  .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c|  2 +-
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c |  2 +-
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c |  2 +-
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c |  2 +-
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.h |  2 +-
>  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.c   |  6 ++--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_ids.h   |  4 +--
>  drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  2 +-
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c|  8 ++---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h|  8 ++---
>  .../gpu/drm/amd/amdkfd/cik_event_interrupt.c  |  2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_dbgdev.c   |  2 +-
>  drivers/gpu/drm/amd/amdkfd/kfd_dbgmgr.h   |  2 +-
>  .../drm/amd/amdkfd/kfd_device_queue_manager.c |  7 ++---
>  drivers/gpu/drm/amd/amdkfd/kfd_events.c   |  8 ++---
>  drivers/gpu/drm/amd/amdkfd/kfd_events.h   |  4 +--
>  drivers/gpu/drm/amd/amdkfd/kfd_iommu.c|  6 ++--
>  drivers/gpu/drm/amd/amdkfd/kfd_pasid.c|  4 +--
>  drivers/gpu/drm/amd/amdkfd/kfd_priv.h | 20 ++--
>  drivers/gpu/drm/amd/amdkfd/kfd_process.c  |  2 +-
>  .../gpu/drm/amd/include/kgd_kfd_interface.h   |  2 +-
>  drivers/iommu/amd/amd_iommu.h | 10 +++---
>  drivers/iommu/amd/iommu.c | 31 ++-
>  drivers/iommu/amd/iommu_v2.c  | 20 ++--
>  drivers/iommu/intel/dmar.c|  7 +++--
>  drivers/iommu/intel/intel-pasid.h | 24 +++---
>  drivers/iommu/intel/iommu.c   |  4 +--
>  drivers/iommu/intel/pasid.c   | 31 +--
>  drivers/iommu/intel/svm.c | 12 +++
>  drivers/iommu/iommu.c |  2 +-
>  drivers/misc/uacce/uacce.c|  2 +-
>  include/linux/amd-iommu.h |  8 ++---
>  include/linux/intel-iommu.h   | 12 +++
>  include/linux/intel-svm.h |  2 +-
>  include/linux/iommu.h | 10 +++---
>  include/linux/uacce.h |  2 +-
>  38 files changed, 141 insertions(+), 141 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> index ffe149aafc39..dfef5a7e0f5a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> @@ -207,11 +207,11 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct
> kgd_dev *dst, struct kgd_dev *s
>   })
> 
>  /* GPUVM API */
> -int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, unsigned int
> pasid,
> +int amdgpu_amdkfd_gpuvm_create_process_vm(struct kgd_dev *kgd, u32 pasid,
>   void **vm, void **process_info,
>   struct dma_fence **ef);
>  int amdgpu_amdkfd_gpuvm_acquire_process_vm(struct kgd_dev *kgd,
> - struct file *filp, unsigned int pasid,
> + struct file *filp, u32 pasid,
>   void **vm, void **process_info,
>   struct dma_fence **ef);
>  void amdgpu_amdkfd_gpuvm_destroy_cb(struct amdgpu_device *adev,
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> index bf927f432506..ee531c3988d1 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c
> @@ -105,7 +105,7 @@ static void kgd_program_sh_mem_settings(struct kgd_dev
> *kgd, uint32_t vmid,
>   unlock_srbm(kgd);
>  }
> 
> -static int kgd_set_pasid_vmid_mapping(struct kgd_dev *kgd, unsigned int 
> pasid,
> +static int kgd_set_pasid_vmid_mapping(struct kgd_dev *kgd, u32 pasid,
> 

linux-next: manual merge of the drm-intel tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-intel tree got a conflict in:

  drivers/gpu/drm/drm_probe_helper.c

between commit:

  12c683e12cd8 ("drm: bridge: Pass drm_display_info to drm_bridge_funcs 
.mode_valid()")

from the drm tree and commit:

  1c26b8e09004 ("drm/probe_helper: Add 
drm_connector_helper_funcs.mode_valid_ctx")

from the drm-intel tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/drm_probe_helper.c
index 09e872e61315,601a4f25bb47..
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@@ -114,10 -116,8 +116,10 @@@ drm_mode_validate_pipeline(struct drm_d
}
  
bridge = drm_bridge_chain_get_first_bridge(encoder);
-   ret = drm_bridge_chain_mode_valid(bridge,
- >display_info,
- mode);
-   if (ret != MODE_OK) {
 -  *status = drm_bridge_chain_mode_valid(bridge, mode);
++  *status = drm_bridge_chain_mode_valid(bridge,
++>display_info,
++mode);
+   if (*status != MODE_OK) {
/* There is also no point in continuing for crtc check
 * here. */
continue;


pgp4ymVx0cSeO.pgp
Description: OpenPGP digital signature

Re: [PATCH v4 0/4] printk: replace ringbuffer

[Sergey Senozhatsky]

On (20/07/10 11:58), John Ogness wrote:
> 
> IMHO users of these sequence number interfaces need to see all the
> records individually and reassemble the LOG_CONT messages themselves if
> they want to. I believe that is the only sane path forward. To do this,
> the caller id will no longer be optional to the sequence number output
> since that is vital information to re-assemble the LOG_CONT messages.

Agreed. The caller id thus probably can be extended. Right now it only
tells us either we are in a process context (PID) or in something else.
This works sort of fine (I guess) because deeply nested printouts (printks
from NMI atop of process or irq printks) land in the deferred printk-safe
buffers, but things will change with the new logbuf (and after removal of
the logbuf_lock and per-CPU printk-safe buffers).

-ss

Re: [PATCH] net: xilinx: fix potential NULL dereference in temac_probe()

[Florian Fainelli]

On 7/13/2020 7:23 PM, Xu Wang wrote:
> platform_get_resource() may return NULL, add proper
> check to avoid potential NULL dereferencing.
> 
> Signed-off-by: Xu Wang 
> ---

If you use devm_ioremap_resource() you can remove the !res check
entirely which would be equally acceptable as a fix.

>  drivers/net/ethernet/xilinx/ll_temac_main.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/net/ethernet/xilinx/ll_temac_main.c 
> b/drivers/net/ethernet/xilinx/ll_temac_main.c
> index 929244064abd..85a767fa2ecf 100644
> --- a/drivers/net/ethernet/xilinx/ll_temac_main.c
> +++ b/drivers/net/ethernet/xilinx/ll_temac_main.c
> @@ -1408,6 +1408,8 @@ static int temac_probe(struct platform_device *pdev)
>  
>   /* map device registers */
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
>   lp->regs = devm_ioremap(>dev, res->start,
>   resource_size(res));
>   if (!lp->regs) {
> @@ -1503,6 +1505,8 @@ static int temac_probe(struct platform_device *pdev)
>   } else if (pdata) {
>   /* 2nd memory resource specifies DMA registers */
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> + if (!res)
> + return -EINVAL;
>   lp->sdma_regs = devm_ioremap(>dev, res->start,
>resource_size(res));
>   if (!lp->sdma_regs) {
> 

-- 
Florian

soft lockup in fanotify_read

[Francesco Ruggeri]

We are getting this soft lockup in fanotify_read.
The reason is that this code does not seem to scale to cases where there
are big bursts of events generated by fanotify_handle_event.
fanotify_read acquires group->notification_lock for each event.
fanotify_handle_event uses the lock to add one event, which also involves
fanotify_merge, which scans the whole list trying to find an event to
merge the new one with.
In our case fanotify_read is invoked with a buffer big enough for 200
events, and what happens is that every time fanotify_read dequeues an
event and releases the lock, fanotify_handle_event adds several more,
scanning a longer and longer list. This causes fanotify_read to wait
longer and longer for the lock, and the soft lockup happens before
fanotify_read can reach 200 events.
Is it intentional for fanotify_read to acquire the lock for each event,
rather than batching together a user buffer worth of events?

Thanks,
Francesco Ruggeri

[5752801.578813] watchdog: BUG: soft lockup - CPU#15 stuck for 22s! 
[fstrace:23105]
[5752801.586804] Modules linked in: ...
[5752801.586871] CPU: 15 PID: 23105 Comm: fstrace Tainted: GW  O L
4.19.112-16802951.AroraKernel419.el7.x86_64 #1
[5752801.586872] Hardware name: Supermicro SYS-6029TP-HTR/X11DPT-PS, BIOS 3.1 
04/30/2019
[5752801.586879] RIP: 0010:queued_spin_lock_slowpath+0x141/0x17c
[5752801.586881] Code: 5e c1 e9 12 83 e0 03 ff c9 48 c1 e0 04 48 63 c9 48 05 c0 
14 02 00 48 03 04 cd 20 e7 e9 81 48 89 10 8b 42 08 85 c0 75 04 f3 90  f5 48 
8b 0a 48 85 c9 74 03 0f 0d 09 8b 07 66 85 c0 74 93 f3 90
[5752801.586882] RSP: 0018:c90027c5fd18 EFLAGS: 0246 ORIG_RAX: 
ff13
[5752801.586883] RAX:  RBX: 8883a9078ce8 RCX: 
001e
[5752801.586884] RDX: 88df7f6e14c0 RSI: 0040 RDI: 
88b06306e30c
[5752801.586885] RBP: c90027c5fd18 R08: 0001 R09: 
811e8b7e
[5752801.586886] R10: c90027c5fce0 R11:  R12: 
88b06306e300
[5752801.586887] R13: ff935638 R14: 88b4af422600 R15: 
0018
[5752801.586888] FS:  () GS:88df7f6c(0063) 
knlGS:09c6a880
[5752801.586889] CS:  0010 DS: 002b ES: 002b CR0: 80050033
[5752801.586890] CR2: 09430914 CR3: 00035bbef006 CR4: 
007606e0
[5752801.586891] DR0: 0001864c DR1:  DR2: 

[5752801.586891] DR3:  DR6: fffe0ff0 DR7: 
0600
[5752801.586892] PKRU: 5554
[5752801.586892] Call Trace:
[5752801.586898]  do_raw_spin_lock+0x1a/0x1c
[5752801.586901]  _raw_spin_lock+0xe/0x10
[5752801.586905]  fanotify_read+0xa3/0x32d
[5752801.586912]  ? __wake_up_sync+0x12/0x12
[5752801.586916]  copy_oldmem_page+0xa9/0xa9
[5752801.586920]  ? fsnotify_perm+0x60/0x6c
[5752801.586921]  ? fsnotify_perm+0x60/0x6c
[5752801.586923]  ? security_file_permission+0x37/0x3e
[5752801.586926]  vfs_read+0xa4/0xdc
[5752801.586928]  ksys_read+0x64/0xab
[5752801.586930]  __ia32_sys_read+0x18/0x1a
[5752801.586933]  do_fast_syscall_32+0xaf/0xf6
[5752801.586935]  entry_SYSENTER_compat+0x6b/0x7a
[5752801.586936] RIP: 0023:0xf7f64c29
[5752801.586938] Code: 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 1c 24 c3 8b 34 24 c3 
90 90 90 90 90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 
c3 90 90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
[5752801.586939] RSP: 002b:ff933828 EFLAGS: 0246 ORIG_RAX: 
0003
[5752801.586940] RAX: ffda RBX: 0004 RCX: 
ff9348d0
[5752801.586941] RDX: 12c0 RSI: 09c72da8 RDI: 
ff9348d0
[5752801.586941] RBP: ff935ba8 R08:  R09: 

[5752801.586942] R10:  R11:  R12: 

[5752801.586942] R13:  R14:  R15: 

Re: [PATCH v2 1/4] dt-bindings: media: csi2dc: add bindings for microchip csi2dc

[Rob Herring]

On Fri, Jul 03, 2020 at 10:44:13AM +0300, Eugen Hristev wrote:
> Add bindings documentation for microchip CSI2 Demultiplexer controller.
> 
> CSI2DC is a demultiplexer from Synopsys IDI interface specification to
> parallel interface connection or direct memory access.
> 
> Signed-off-by: Eugen Hristev 
> ---
> Changes in v2:
> - fixed warnings reported by dt_binding_check
> 
> 
>  .../bindings/media/microchip,csi2dc.yaml  | 185 ++
>  1 file changed, 185 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> 
> diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml 
> b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> new file mode 100644
> index ..b7c46f7ad2a4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml
> @@ -0,0 +1,185 @@
> +# SPDX-License-Identifier: GPL-2.0-only

New bindings should be:

(GPL-2.0-only OR BSD-2-Clause)

> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Microchip CSI2 Demux Controller (CSI2DC)
> +
> +maintainers:
> +  - Eugen Hristev 
> +
> +description:
> +  CSI2DC - Camera Serial Interface 2 Demux Controller
> +
> +  CSI2DC is a hardware block that receives incoming data from an IDI 
> interface
> +  and filters packets based on their data type and virtual channel 
> identifier,
> +  then converts the byte stream into a cross clock domain to a pixel stream
> +  to a parallel interface that can be read by a sensor controller.
> +
> +  CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe
> +  is connected to a sensor controller and the data pipe is accessible
> +  as a DMA slave port to a DMA controller.
> +
> +  CSI2DC supports a single 'port' node as a source pad with Synopsys 32-bit
> +  IDI interface. The connected endpoint must be a IDI interface compatible
> +  device (like Synopsys CSI2HOST) , that can provide 32-bit IDI interface
> +  connection as sink pad.
> +  It should contain one 'port' child node with one child 'endpoint' node.
> +  This node should always have the 'reg' property as 0, being the first child
> +  node.

This information should be expressed as a schema.

> +  For media entity and endpoints please refer to the bindings defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.
> +  For Synopsys IDI interface please refer to
> +  Documentation/devicetree/bindings/media/snps,dw-csi-plat.txt
> +

> +  CSI2DC supports one 'port' node as sink pad with parallel interface. This 
> is
> +  called video pipe.
> +  The reg property inside this 'port' node must have the 'reg' property as 1,
> +  being the second child node.
> +  This node must have one 'endpoint', and this 'endpoint' is related to the
> +  virtual channel identifier.
> +  The 'reg' property inside this 'endpoint' represents the CSI2 virtual 
> channel
> +  identifier.
> +  This 'endpoint' can then be used as a source pad for another controller
> +  (next in pipeline).
> +  Please refer to the bindings defined in
> +  Documentation/devicetree/bindings/media/video-interfaces.txt.

And all this.

> +
> +  CSI2DC must have two clocks to function correctly. One clock is the
> +  peripheral clock for the inside functionality of the hardware block.
> +  This is named 'pclk'. The second clock must be the cross domain clock,
> +  in which CSI2DC will perform clock crossing. This clock must be fed
> +  by the next controller in pipeline, which usually is a sensor controller.
> +  Normally this clock should be given by this sensor controller who
> +  is also a clock source. This clock is named 'scck', sensor controller 
> clock.

Better to be part of 'clocks'.

> +
> +  CSI2DC also supports direct access to the data through AHB, via DMA 
> channel,
> +  called data pipe.
> +  Because of this, the sink 'port' child node (second) is not mandatory.
> +  If the sink 'port' child node is missing, only data pipe is available.
> +
> +properties:
> +  compatible:
> +const: microchip,sama7g5-csi2dc
> +
> +  reg:
> +description:
> +  Physical base address and length of the registers set for the device.

That is every 'reg' prop. Drop.

> +maxItems: 1
> +
> +  clocks:
> +maxItems: 2
> +
> +  clock-names:
> +items:
> +  - const: pclk
> +  - const: scck
> +
> +  microchip,clk-gated:
> +type: boolean
> +description:
> +  If present, indicates that the clock is gated.
> +  Otherwise, the clock is free-running.
> +
> +  microchip,inter-line-delay:
> +allOf:
> +- $ref: /schemas/types.yaml#/definitions/uint32
> +- minimum: 1
> +- maximum: 16
> +default: 16
> +description:
> +  Indicates how many clock cycles should be introduced between each line.
> +
> +  port@0:
> +type: object
> +description:
> +  Input port node, single endpoint describing the 

Re: [PATCH v2] panic: prevent panic_timeout * 1000 from overflow

[Matthew Wilcox]

On Mon, Jul 13, 2020 at 06:57:39PM -0700, Andrew Morton wrote:
> +++ a/kernel/panic.c
> @@ -313,13 +313,16 @@ void panic(const char *fmt, ...)
>* Delay timeout seconds before rebooting the machine.
>* We can't use the "normal" timers since we just panicked.
>*/
> + u64 timeout = panic_timeout * 1000; /* avoid overflow */

1000ULL to not truncate before the assignment.

> + u64 timer;

... as you implied later

u64 timer, timer_next;

> (untested)

Well, there's the rub.  Testing requires 49 days (2^32 / 1000 seconds).

mmotm 2020-07-13-19-49 uploaded

[Andrew Morton]

The mm-of-the-moment snapshot 2020-07-13-19-49 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

https://github.com/hnaz/linux-mm

The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is also available at

https://github.com/hnaz/linux-mm



This mmotm tree contains the following patches against 5.8-rc5:
(patches marked "*" will be included in linux-next)

* mm-shuffle-dont-move-pages-between-zones-and-dont-read-garbage-memmaps.patch
* mm-avoid-access-flag-update-tlb-flush-for-retried-page-fault.patch
* mm-close-race-between-munmap-and-expand_upwards-downwards.patch
* mm-close-race-between-munmap-and-expand_upwards-downwards-fix.patch
* vfs-xattr-mm-shmem-kernfs-release-simple-xattr-entry-in-a-right-way.patch
* mm-initialize-return-of-vm_insert_pages.patch
* mm-memcontrol-fix-oops-inside-mem_cgroup_get_nr_swap_pages.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* mm-memcg-fix-refcount-error-while-moving-and-swapping.patch
* mm-hugetlb-avoid-hardcoding-while-checking-if-cma-is-enabled.patch
* mailmap-add-entry-for-mike-rapoport.patch
* checkpatch-test-git_dir-changes.patch
* kthread-remove-incorrect-comment-in-kthread_create_on_cpu.patch
* scripts-tagssh-collect-compiled-source-precisely.patch
* scripts-tagssh-collect-compiled-source-precisely-v2.patch
* bloat-o-meter-support-comparing-library-archives.patch
* scripts-decode_stacktrace-skip-missing-symbols.patch
* scripts-decode_stacktrace-guess-basepath-if-not-specified.patch
* scripts-decode_stacktrace-guess-path-to-modules.patch
* scripts-decode_stacktrace-guess-path-to-vmlinux-by-release-name.patch
* const_structscheckpatch-add-regulator_ops.patch
* ocfs2-clear-links-count-in-ocfs2_mknod-if-an-error-occurs.patch
* ocfs2-fix-ocfs2-corrupt-when-iputting-an-inode.patch
* ocfs2-change-slot-number-type-s16-to-u16.patch
* ramfs-support-o_tmpfile.patch
* kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch
  mm.patch
* mm-treewide-rename-kzfree-to-kfree_sensitive.patch
* mm-ksize-should-silently-accept-a-null-pointer.patch
* mm-expand-config_slab_freelist_hardened-to-include-slab.patch
* slab-add-naive-detection-of-double-free.patch
* slab-add-naive-detection-of-double-free-fix.patch
* mm-slab-check-gfp_slab_bug_mask-before-alloc_pages-in-kmalloc_order.patch
* mm-slub-extend-slub_debug-syntax-for-multiple-blocks.patch
* mm-slub-extend-slub_debug-syntax-for-multiple-blocks-fix.patch
* mm-slub-make-some-slub_debug-related-attributes-read-only.patch
* mm-slub-remove-runtime-allocation-order-changes.patch
* mm-slub-make-remaining-slub_debug-related-attributes-read-only.patch
* mm-slub-make-reclaim_account-attribute-read-only.patch
* mm-slub-introduce-static-key-for-slub_debug.patch
* mm-slub-introduce-kmem_cache_debug_flags.patch
* mm-slub-introduce-kmem_cache_debug_flags-fix.patch
* mm-slub-extend-checks-guarded-by-slub_debug-static-key.patch
* mm-slab-slub-move-and-improve-cache_from_obj.patch
* mm-slab-slub-improve-error-reporting-and-overhead-of-cache_from_obj.patch
* mm-slab-slub-improve-error-reporting-and-overhead-of-cache_from_obj-fix.patch
* slub-drop-lockdep_assert_held-from-put_map.patch
* mm-kcsan-instrument-slab-slub-free-with-assert_exclusive_access.patch
* 
mm-debug_vm_pgtable-add-tests-validating-arch-helpers-for-core-mm-features.patch
* 
mm-debug_vm_pgtable-add-tests-validating-advanced-arch-page-table-helpers.patch
* 
mm-debug_vm_pgtable-add-tests-validating-advanced-arch-page-table-helpers-v5.patch
* mm-debug_vm_pgtable-add-debug-prints-for-individual-tests.patch
* documentation-mm-add-descriptions-for-arch-page-table-helpers.patch
*