Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism

[Daniel Lezcano]

Hi Ming Lei,

On 03/09/2019 05:30, Ming Lei wrote:

[ ... ]


>>> 2) irq/timing doesn't cover softirq
>>
>> That's solvable, right?
> 
> Yeah, we can extend irq/timing, but ugly for irq/timing, since irq/timing
> focuses on hardirq predication, and softirq isn't involved in that
> purpose.
> 
>>  
>>> Daniel, could you take a look and see if irq flood detection can be
>>> implemented easily by irq/timing.c?
>>
>> I assume you can take a look as well, right?
> 
> Yeah, I have looked at the code for a while, but I think that irq/timing
> could become complicated unnecessarily for covering irq flood detection,
> meantime it is much less efficient for detecting IRQ flood.

In the series, there is nothing describing rigorously the problem (I can
only guess) and why the proposed solution solves it.

What is your definition of an 'irq flood'? A high irq load? An irq
arriving while we are processing the previous one in the bottom halves?

The patch 2/4 description says "however IO completion is only done on
one of these submission CPU cores". That describes the bottleneck and
then the patch says "Add IRQF_RESCUE_THREAD to create one interrupt
thread handler", what is the rational between the bottleneck (problem)
and the irqf_rescue_thread (solution)?

Is it really the solution to track the irq timings to detect a flood?



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [RFC 2/5] ARM: dts: add support for opp-v2 for omap34xx and omap36xx

[H. Nikolaus Schaller]

> Am 03.09.2019 um 04:38 schrieb Viresh Kumar :
> 
> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
>> +opp1-12500 {
>> +opp-hz = /bits/ 64 <12500>;
>> +// we currently only select the max voltage from table 
>> Table 3-3 of the omap3530 Data sheet (SPRS507F)
>> +//  could also be single 
>> +opp-microvolt = <975000 975000 975000>;
>> +// first value is silicon revision, second one 720MHz 
>> Device Identification
> 
>> +opp-supported-hw = <0x 3>;
> 
> I don't see the driver changes using this field, am I missing
> something ?

This is parsed by _opp_is_supported() which is called
indirectly by ti_cpufreq_probe().

BR,
Nikolaus

Re: [PATCH] clocksource: atmel-st: Variable sr in at91rm9200_timer_interrupt() could be uninitialized

[Yizhuo Zhai]

In function regmap_read(),  there're two places which could make the read fail.

First, if "reg" and  "map->reg_stride" are not aligned, then remap_read() will
return -EINVAL without initialize variable "val".

Second, _regmap_read() could also fail and return error code if "val" is not
initialized. The caller remap_read() returns the same error code, but
at91rm9200_timer_interrupt() does not use this information.

On Mon, Sep 2, 2019 at 3:37 PM Alexandre Belloni
 wrote:
>
> On 02/09/2019 15:29:46-0700, Yizhuo wrote:
> > Inside function at91rm9200_timer_interrupt(), variable sr could
> > be uninitialized if regmap_read() fails. However, sr is used
>
> Could you elaborate on how this could fail?
>
> > to decide the control flow later in the if statement, which is
> > potentially unsafe. We could check the return value of
> > regmap_read() and print an error here.
> >
> > Signed-off-by: Yizhuo 
> > ---
> >  drivers/clocksource/timer-atmel-st.c | 8 +++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/clocksource/timer-atmel-st.c 
> > b/drivers/clocksource/timer-atmel-st.c
> > index ab0aabfae5f0..061a3f27847e 100644
> > --- a/drivers/clocksource/timer-atmel-st.c
> > +++ b/drivers/clocksource/timer-atmel-st.c
> > @@ -48,8 +48,14 @@ static inline unsigned long read_CRTR(void)
> >  static irqreturn_t at91rm9200_timer_interrupt(int irq, void *dev_id)
> >  {
> >   u32 sr;
> > + int ret;
> > +
> > + ret = regmap_read(regmap_st, AT91_ST_SR, );
> > + if (ret) {
> > + pr_err("Fail to read AT91_ST_SR.\n");
> > + return ret;
> > + }
> >
> > - regmap_read(regmap_st, AT91_ST_SR, );
> >   sr &= irqmask;
> >
> >   /*
> > --
> > 2.17.1
> >
>
> --
> Alexandre Belloni, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



-- 
Kind Regards,

Yizhuo Zhai

Computer Science, Graduate Student
University of California, Riverside

Re: [PATCH] powerpc: Avoid clang warnings around setjmp and longjmp

[Nathan Chancellor]

On Thu, Aug 29, 2019 at 09:59:48AM +, David Laight wrote:
> From: Nathan Chancellor
> > Sent: 28 August 2019 19:45
> ...
> > However, I think that -fno-builtin-* would be appropriate here because
> > we are providing our own setjmp implementation, meaning clang should not
> > be trying to do anything with the builtin implementation like building a
> > declaration for it.
> 
> Isn't implementing setjmp impossible unless you tell the compiler that
> you function is 'setjmp-like' ?

No idea, PowerPC is the only architecture that does such a thing.

https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/tree/arch/powerpc/kernel/misc.S#n43

Goes back all the way to before git history (all the way to ppc64's
addition actually):

https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=61542216fa90397a2e70c46583edf26bc81994df

https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/arch/ppc64/xmon/setjmp.c?id=5f12b0bff93831620218e8ed3970903ecb7861ce

I would just like this warning fixed given that PowerPC builds with
-Werror by default so it is causing a build failure in our CI.

Cheers,
Nathan

Re: [PATCH] ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL

[Takashi Iwai]

On Tue, 03 Sep 2019 07:30:04 +0200,
Jian-Hong Pan wrote:
> 
> Takashi Iwai  於 2019年9月2日 週一 下午7:41寫道：
> >
> > On Mon, 02 Sep 2019 12:00:56 +0200,
> > Jian-Hong Pan wrote:
> > >
> > > Original pin node values of ASUS UX431FL with ALC294:
> > >
> > > 0x12 0xb7a60140
> > > 0x13 0x4000
> > > 0x14 0x90170110
> > > 0x15 0x41f0
> > > 0x16 0x41f0
> > > 0x17 0x90170111
> > > 0x18 0x41f0
> > > 0x19 0x41f0
> > > 0x1a 0x41f0
> > > 0x1b 0x41f0
> > > 0x1d 0x4066852d
> > > 0x1e 0x41f0
> > > 0x1f 0x41f0
> > > 0x21 0x04211020
> > >
> > > 1. Has duplicated internal speakers (0x14 & 0x17) which makes the output
> > >route become confused. So, the output volume cannot be changed by
> > >setting.
> > > 2. Misses the headset mic pin node.
> > >
> > > This patch disables the confusing speaker (NID 0x14) and enables the
> > > headset mic (NID 0x19).
> >
> > Is 0x14 really a dead pin?  Or is a surround/bass speaker or such?
> 
> I checked Windows (updated to latest and including Realtek MEDIA) on
> ASUS UX431FL laptop again.  Although it has two internal speaker pins,
> there is only one set of internal speaker including left/right
> channels.  And the audio test (Speaker Setup) only shows left/right
> channels.  So, NID 0x14 can be disabled.

OK, thanks for clarification.
I applied the patch now.


Takashi

RE: "fs/namei.c: keep track of nd->root refcount status" causes boot panic

[Dexuan Cui]

> From: Dexuan-Linux Cui 
> Sent: Monday, September 2, 2019 10:22 PM
> To: Qian Cai 
> Cc: Al Viro ; linux-fsde...@vger.kernel.org; LKML
> ; Dexuan Cui ; Lili Deng
> (Wicresoft North America Ltd) 
> Subject: Re: "fs/namei.c: keep track of nd->root refcount status" causes boot
> panic
> 
> On Mon, Sep 2, 2019 at 9:22 PM Qian Cai  wrote:
> >
> > The linux-next commit "fs/namei.c: keep track of nd->root refcount status”
> [1] causes boot panic on all
> > architectures here on today’s linux-next (0902). Reverted it will fix the 
> > issue.
> 
> I believe I'm seeing the same issue with next-20190902 in a Linux VM
> running on Hyper-V (next-20190830 is good).
> 
> git-bisect points to the same commit in linux-next:
> e013ec23b823 ("fs/namei.c: keep track of nd->root refcount status")
> 
> I can reproduce the issue every time I reboot the system.
> 
> Thanks,
> Dexuan

BTW, I tried the patch https://lkml.org/lkml/2019/8/31/158 -- not helpful at 
all.

FYI: this is my call-trace:

[   16.843452] Run /init as init process
Loading, please wait...
starting version 239
[   16.936476] [ cut here ]
[   16.937929] DEBUG_LOCKS_WARN_ON(!test_bit(class_idx, lock_classes_in_use))
[   16.937929] WARNING: CPU: 10 PID: 366 at kernel/locking/lockdep.c:3850 
__lock_acquire.isra.34+0x50c/0x560
[   16.937929] Modules linked in:
[   16.937929] CPU: 10 PID: 366 Comm: udevadm Not tainted 5.3.0-rc1+ #26
[   16.937929] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090008  12/07/2018
[   16.937929] RIP: 0010:__lock_acquire.isra.34+0x50c/0x560
[   16.937929] Code: 00 85 c0 0f 84 72 fe ff ff 8b 1d af 5b 2b 01 85 db 0f 85 
64 fe ff ff 48 c7 c6 08 97 07...
[   16.937929] RSP: 0018:c90003ff3c40 EFLAGS: 00010086
[   16.937929] RAX:  RBX:  RCX: 
[   16.937929] RDX: 810e3d63 RSI: 0001 RDI: 822628a0
[   16.937929] RBP:  R08: 82c0e420 R09: 00039440
[   16.937929] R10: 001209f646b6 R11: 016e R12: 888276440040
[   16.937929] R13:  R14:  R15: 888276440818
[   16.937929] FS:  7f4ee2f0f8c0() GS:88827d70() 
knlGS:
[   16.937929] CS:  0010 DS:  ES:  CR0: 80050033
[   16.937929] CR2: 55dce7403000 CR3: 000276772003 CR4: 003606e0
[   16.937929] DR0:  DR1:  DR2: 
[   16.937929] DR3:  DR6: fffe0ff0 DR7: 0400
[   16.937929] Call Trace:
[   16.937929]  lock_acquire+0xae/0x160
[   16.937929]  ? dput.part.34+0x164/0x380
[   16.937929]  ? dput.part.34+0x29/0x380
[   16.937929]  _raw_spin_lock+0x2c/0x40
[   16.937929]  ? dput.part.34+0x164/0x380
[   16.937929]  dput.part.34+0x164/0x380
[   17.098529]  terminate_walk+0xde/0x100
[   17.098529]  path_lookupat.isra.62+0xa3/0x220
[   17.098529]  filename_lookup.part.77+0xa0/0x170
[   17.098529]  ? kmem_cache_alloc+0x169/0x2a0
[   17.098529]  do_readlinkat+0x5d/0x110
[   17.098529]  __x64_sys_readlinkat+0x1a/0x20
[   17.098529]  do_syscall_64+0x5d/0x1c0
[   17.098529]  ? prepare_exit_to_usermode+0x7b/0xb0
[   17.098529]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   17.098529] RIP: 0033:0x7f4ee378da4a
[   17.098529] Code: 48 8b 0d 49 84 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 
0f 1f 84 00 00 ...
[   17.098529] RSP: 002b:7fffbddb7968 EFLAGS: 0202 ORIG_RAX: 
010b
[   17.098529] RAX: ffda RBX: 55dce740b220 RCX: 7f4ee378da4a
[   17.098529] RDX: 55dce740b220 RSI: 55dce740b201 RDI: 0005
[   17.098529] RBP: 0064 R08: 55dce73fa010 R09: 
[   17.098529] R10: 0063 R11: 0202 R12: 55dce740b201
[   17.098529] R13: 0005 R14: 7fffbddb79f8 R15: 0063
[   17.098529] ---[ end trace 6af6f6ebcc3937e8 ]---

It looks the aforementioned patch causes a memory corruption.
If I revert the patch, everything will be back to normal.

Thanks,
Dexuan

Re: [PATCH 1/1] arm64: dts: qcom: Add Lenovo Yoga C630

[Bjorn Andersson]

On Mon 02 Sep 06:24 PDT 2019, Lee Jones wrote:

> From: Bjorn Andersson 
> 
> The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
> 
> Supported by this patch is: keyboard, battery monitoring, UFS storage,
> USB host and Bluetooth.

Applied this to next-20190829 and booted it, got a little bit of EFI FB,
then the screen goes blank and after a while I'm back in GRUB.

I've not been able to figure out what's causing this though.

Regards,
Bjorn

> 
> Signed-off-by: Bjorn Andersson 
> Signed-off-by: Lee Jones 
> ---
>  arch/arm64/boot/dts/qcom/Makefile |   1 +
>  .../boot/dts/qcom/sdm850-lenovo-yoga-c630.dts | 450 ++
>  2 files changed, 451 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> 
> diff --git a/arch/arm64/boot/dts/qcom/Makefile 
> b/arch/arm64/boot/dts/qcom/Makefile
> index 0a7e5dfce6f7..670c6c65f9e9 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -12,5 +12,6 @@ dtb-$(CONFIG_ARCH_QCOM) += sdm845-cheza-r2.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += sdm845-cheza-r3.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += sdm845-db845c.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += sdm845-mtp.dtb
> +dtb-$(CONFIG_ARCH_QCOM)  += sdm850-lenovo-yoga-c630.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += qcs404-evb-1000.dtb
>  dtb-$(CONFIG_ARCH_QCOM)  += qcs404-evb-4000.dtb
> diff --git a/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts 
> b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> new file mode 100644
> index ..3177b054035f
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dts
> @@ -0,0 +1,450 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Lenovo Yoga C630
> + *
> + * Copyright (c) 2019, Linaro Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include "sdm845.dtsi"
> +#include "pm8998.dtsi"
> +
> +/ {
> + model = "Lenovo Yoga C630";
> + compatible = "lenovo,yoga-c630", "qcom,sdm845";
> +
> + aliases {
> + hsuart0 = 
> + };
> +};
> +
> +_rsc {
> + pm8998-rpmh-regulators {
> + compatible = "qcom,pm8998-rpmh-regulators";
> + qcom,pmic-id = "a";
> +
> + vdd-l2-l8-l17-supply = <_s3a_1p35>;
> + vdd-l7-l12-l14-l15-supply = <_s5a_2p04>;
> +
> + vreg_s2a_1p125: smps2 {
> + };
> +
> + vreg_s3a_1p35: smps3 {
> + regulator-min-microvolt = <1352000>;
> + regulator-max-microvolt = <1352000>;
> + regulator-initial-mode = ;
> + };
> +
> + vreg_s4a_1p8: smps4 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-initial-mode = ;
> + };
> +
> + vreg_s5a_2p04: smps5 {
> + regulator-min-microvolt = <204>;
> + regulator-max-microvolt = <204>;
> + regulator-initial-mode = ;
> + };
> +
> + vreg_s7a_1p025: smps7 {
> + };
> +
> + vdd_qusb_hs0:
> + vdda_hp_pcie_core:
> + vdda_mipi_csi0_0p9:
> + vdda_mipi_csi1_0p9:
> + vdda_mipi_csi2_0p9:
> + vdda_mipi_dsi0_pll:
> + vdda_mipi_dsi1_pll:
> + vdda_qlink_lv:
> + vdda_qlink_lv_ck:
> + vdda_qrefs_0p875:
> + vdda_pcie_core:
> + vdda_pll_cc_ebi01:
> + vdda_pll_cc_ebi23:
> + vdda_sp_sensor:
> + vdda_ufs1_core:
> + vdda_ufs2_core:
> + vdda_usb1_ss_core:
> + vdda_usb2_ss_core:
> + vreg_l1a_0p875: ldo1 {
> + regulator-min-microvolt = <88>;
> + regulator-max-microvolt = <88>;
> + regulator-initial-mode = ;
> + };
> +
> + vddpx_10:
> + vreg_l2a_1p2: ldo2 {
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + regulator-initial-mode = ;
> + regulator-always-on;
> + };
> +
> + vreg_l3a_1p0: ldo3 {
> + };
> +
> + vdd_wcss_cx:
> + vdd_wcss_mx:
> + vdda_wcss_pll:
> + vreg_l5a_0p8: ldo5 {
> + regulator-min-microvolt = <80>;
> + regulator-max-microvolt = <80>;
> + regulator-initial-mode = ;
> + };
> +
> + vddpx_13:
> + vreg_l6a_1p8: ldo6 {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-initial-mode = ;
> +   

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

[Stephen Rothwell]

Hi Dan,

On Mon, 2 Sep 2019 22:31:00 -0700 Dan Williams  wrote:
>
> On Mon, Sep 2, 2019 at 4:45 PM Stephen Rothwell  wrote:
> >
> > Hi Jason,
> >
> > On Mon, 2 Sep 2019 10:51:41 + Jason Gunthorpe  
> > wrote:  
> > >
> > > On Mon, Sep 02, 2019 at 08:50:17PM +1000, Stephen Rothwell wrote:  
> > >  
> > > > ERROR: "nd_region_provider_data" [drivers/acpi/nfit/nfit.ko] undefined!
> > > > ERROR: "to_nd_blk_region" [drivers/acpi/nfit/nfit.ko] undefined!
> > > > ERROR: "nvdimm_region_notify" [drivers/acpi/nfit/nfit.ko] undefined!
> > > > ERROR: "nvdimm_blk_region_create" [drivers/acpi/nfit/nfit.ko] undefined!
> > > >
> > > > Caused by commit
> > > >
> > > >   126470c8a58b ("libnvdimm: Enable unit test infrastructure compile 
> > > > checks")
> > > >
> > > > I have reverted that commit for today.  
> > >
> > > Looks like more kconfig trouble, can you send Dan your kconfig? I'll
> > > drop this patch again
> > >  
> >
> > Thanks.  It was just an x86_64 allmodconfig build.  I don't actually
> > have the .config file (it gets cleaned up, sorry).  
> 
> Strange. x86_64 allmodconfig is certainly a 0day build target. Could
> this be toolchain dependent?

Possible, I guess.  I am cross compiling on a PowerPC LE host

$ x86_64-linux-gnu-gcc --version
x86_64-linux-gnu-gcc (Debian 9.2.1-4) 9.2.1 20190821

$ x86_64-linux-gnu-ld --version
GNU ld (GNU Binutils for Debian) 2.32.51.20190821

It could also be an interaction with something else in linux-next.
-- 
Cheers,
Stephen Rothwell


pgpueoDJj6ZQw.pgp
Description: OpenPGP digital signature

Re: [PATCH] ACPI: support for NXP i2c controller

[Oleksij Rempel]

Hi,

On 02.09.19 23:16, Andy Shevchenko wrote:

On Mon, Sep 2, 2019 at 11:58 PM Rafael J. Wysocki  wrote:


On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han  wrote:


Enable NXP i2c controller to boot with ACPI

Signed-off-by: Meenakshi Aggarwal 
Signed-off-by: Udit Kumar 
Signed-off-by: Chuanhua Han 


Wolfram, any objections to this from the i2c side?


May I propose amendment(s)?


@@ -44,6 +44,7 @@
  #include 
  #include 
  #include 



+#include 


If it's kept in order, better to go with it. (Yes, it is as I have checked)
However, property.h should be included instead, see below.


 const struct of_device_id *of_id = of_match_device(i2c_imx_dt_ids,
>dev);
+   const struct acpi_device_id *acpi_id =
+   acpi_match_device(i2c_imx_acpi_ids,
+ >dev);




 if (of_id)
 i2c_imx->hwdata = of_id->data;
+   else if (acpi_id)
+   i2c_imx->hwdata = (struct imx_i2c_hwdata *)
+   acpi_id->driver_data;



The above altogher may be replaced with

const struct imx_i2c_hwdata *match;
...
match = device_get_match_data(>dev);
if (match)
  i2c_imx->hwdata = match;
else
...


Instead of "may be replaced", I would say: it should be replaced :)


+   .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids),


Since there is no #ifdef guard no need to use ACPI_PTR().



What iMX/(other NXP?) SoCs are with ACPI support?  Where I can get one? I would like to 
know more about it.


Kind regards,
Oleksij Rempel

--
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

linux-next: manual merge of the devicetree tree with the samsung-krzk tree

[Stephen Rothwell]

Hi all,

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

  Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt

between commit:

  5833f5a5daf3 ("dt-bindings: gpu: mali: Add Samsung exynos5250 compatible")

from the samsung-krzk tree and commit:

  553cedf60056 ("dt-bindings: Convert Arm Mali Midgard GPU to DT schema")

from the devicetree tree.

I fixed it up (I just removed the txt file, some fixup will be requide for
the new yaml file) 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


pgpPP5cp2RKub.pgp
Description: OpenPGP digital signature

[PATCH] rtl8xxxu: add bluetooth co-existence support for single antenna

[Chris Chiu]

The RTL8723BU suffers the wifi disconnection problem while bluetooth
device connected. While wifi is doing tx/rx, the bluetooth will scan
without results. This is due to the wifi and bluetooth share the same
single antenna for RF communication and they need to have a mechanism
to collaborate.

BT information is provided via the packet sent from co-processor to
host (C2H). It contains the status of BT but the rtl8723bu_handle_c2h
dose not really handle it. And there's no bluetooth coexistence
mechanism to deal with it.

This commit adds a workqueue to set the tdma configurations and
coefficient table per the parsed bluetooth link status and given
wifi connection state. The tdma/coef table comes from the vendor
driver code of the RTL8192EU and RTL8723BU. However, this commit is
only for single antenna scenario which RTL8192EU is default dual
antenna. The rtl8xxxu_parse_rxdesc24 which invokes the handle_c2h
is only for 8723b and 8192e so the mechanism is expected to work
on both chips with single antenna. Note RTL8192EU dual antenna is
not supported.

Signed-off-by: Chris Chiu 
---
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu.h  |  37 +++
 .../realtek/rtl8xxxu/rtl8xxxu_8723b.c |   2 -
 .../wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 243 +-
 3 files changed, 275 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
index 582c2a346cec..22e95b11bfbb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.h
@@ -1220,6 +1220,37 @@ enum ratr_table_mode_new {
RATEID_IDX_BGN_3SS = 14,
 };
 
+#define BT_INFO_8723B_1ANT_B_FTP   BIT(7)
+#define BT_INFO_8723B_1ANT_B_A2DP  BIT(6)
+#define BT_INFO_8723B_1ANT_B_HID   BIT(5)
+#define BT_INFO_8723B_1ANT_B_SCO_BUSY  BIT(4)
+#define BT_INFO_8723B_1ANT_B_ACL_BUSY  BIT(3)
+#define BT_INFO_8723B_1ANT_B_INQ_PAGE  BIT(2)
+#define BT_INFO_8723B_1ANT_B_SCO_ESCO  BIT(1)
+#define BT_INFO_8723B_1ANT_B_CONNECTIONBIT(0)
+
+enum _BT_8723B_1ANT_STATUS {
+   BT_8723B_1ANT_STATUS_NON_CONNECTED_IDLE  = 0x0,
+   BT_8723B_1ANT_STATUS_CONNECTED_IDLE  = 0x1,
+   BT_8723B_1ANT_STATUS_INQ_PAGE= 0x2,
+   BT_8723B_1ANT_STATUS_ACL_BUSY= 0x3,
+   BT_8723B_1ANT_STATUS_SCO_BUSY= 0x4,
+   BT_8723B_1ANT_STATUS_ACL_SCO_BUSY= 0x5,
+   BT_8723B_1ANT_STATUS_MAX
+};
+
+struct rtl8xxxu_btcoex {
+   u8  bt_status;
+   boolbt_busy;
+   boolhas_sco;
+   boolhas_a2dp;
+   boolhas_hid;
+   boolhas_pan;
+   boolhid_only;
+   boola2dp_only;
+   boolc2h_bt_inquiry;
+};
+
 #define RTL8XXXU_RATR_STA_INIT 0
 #define RTL8XXXU_RATR_STA_HIGH 1
 #define RTL8XXXU_RATR_STA_MID  2
@@ -1340,6 +1371,10 @@ struct rtl8xxxu_priv {
 */
struct ieee80211_vif *vif;
struct delayed_work ra_watchdog;
+   struct work_struct c2hcmd_work;
+   struct sk_buff_head c2hcmd_queue;
+   spinlock_t c2hcmd_lock;
+   struct rtl8xxxu_btcoex bt_coex;
 };
 
 struct rtl8xxxu_rx_urb {
@@ -1486,6 +1521,8 @@ void rtl8xxxu_fill_txdesc_v2(struct ieee80211_hw *hw, 
struct ieee80211_hdr *hdr,
 struct rtl8xxxu_txdesc32 *tx_desc32, bool sgi,
 bool short_preamble, bool ampdu_enable,
 u32 rts_rate);
+void rtl8723bu_set_ps_tdma(struct rtl8xxxu_priv *priv,
+  u8 arg1, u8 arg2, u8 arg3, u8 arg4, u8 arg5);
 
 extern struct rtl8xxxu_fileops rtl8192cu_fops;
 extern struct rtl8xxxu_fileops rtl8192eu_fops;
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
index ceffe05bd65b..9ba661b3d767 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
@@ -1580,9 +1580,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
/*
 * Software control, antenna at WiFi side
 */
-#ifdef NEED_PS_TDMA
rtl8723bu_set_ps_tdma(priv, 0x08, 0x00, 0x00, 0x00, 0x00);
-#endif
 
rtl8xxxu_write32(priv, REG_BT_COEX_TABLE1, 0x);
rtl8xxxu_write32(priv, REG_BT_COEX_TABLE2, 0x);
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index a6f358b9e447..4f72c2d14d44 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -3820,9 +3820,8 @@ void rtl8xxxu_power_off(struct rtl8xxxu_priv *priv)
rtl8xxxu_write8(priv, REG_RSV_CTRL, 0x0e);
 }
 
-#ifdef NEED_PS_TDMA
-static void rtl8723bu_set_ps_tdma(struct rtl8xxxu_priv *priv,
- u8 arg1, u8 arg2, u8 arg3, u8 

Re: [PATCH] staging: exfat: fix uninitialized variable ret

[Nathan Chancellor]

On Fri, Aug 30, 2019 at 07:46:44PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Currently there are error return paths in ffsReadFile that
> exit via lable err_out that return and uninitialized error
> return in variable ret. Fix this by initializing ret to zero.
> 
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: c48c9f7ff32b ("staging: exfat: add exfat filesystem code to staging")
> Signed-off-by: Colin Ian King 

Clang also warns about this:

drivers/staging/exfat/exfat_super.c:885:6: warning: variable 'ret' is used 
uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (p_fs->dev_ejected)
^
drivers/staging/exfat/exfat_super.c:892:9: note: uninitialized use occurs here
return ret;
   ^~~
drivers/staging/exfat/exfat_super.c:885:2: note: remove the 'if' if its 
condition is always true
if (p_fs->dev_ejected)
^~
drivers/staging/exfat/exfat_super.c:776:9: note: initialize the variable 'ret' 
to silence this warning
int ret;
   ^
= 0
1 warning generated.

Reviewed-by: Nathan Chancellor 

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

[Dan Williams]

On Mon, Sep 2, 2019 at 4:45 PM Stephen Rothwell  wrote:
>
> Hi Jason,
>
> On Mon, 2 Sep 2019 10:51:41 + Jason Gunthorpe  wrote:
> >
> > On Mon, Sep 02, 2019 at 08:50:17PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> >
> > > ERROR: "nd_region_provider_data" [drivers/acpi/nfit/nfit.ko] undefined!
> > > ERROR: "to_nd_blk_region" [drivers/acpi/nfit/nfit.ko] undefined!
> > > ERROR: "nvdimm_region_notify" [drivers/acpi/nfit/nfit.ko] undefined!
> > > ERROR: "nvdimm_blk_region_create" [drivers/acpi/nfit/nfit.ko] undefined!
> > >
> > > Caused by commit
> > >
> > >   126470c8a58b ("libnvdimm: Enable unit test infrastructure compile 
> > > checks")
> > >
> > > I have reverted that commit for today.
> >
> > Looks like more kconfig trouble, can you send Dan your kconfig? I'll
> > drop this patch again
> >
>
> Thanks.  It was just an x86_64 allmodconfig build.  I don't actually
> have the .config file (it gets cleaned up, sorry).

Strange. x86_64 allmodconfig is certainly a 0day build target. Could
this be toolchain dependent?

[PATCH 3/3] spi: uniphier: introduce polling mode

[Keiji Hayashibara]

Introduce new polling mode for short size transfer. Either the estimated
transfer time is estimated to exceed 200us, or polling loop actually exceeds
200us, it switches to irq mode.

Signed-off-by: Keiji Hayashibara 
---
 drivers/spi/spi-uniphier.c | 81 +-
 1 file changed, 66 insertions(+), 15 deletions(-)

diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index d40ad93..6b83b25 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -16,6 +17,7 @@
 #include 
 
 #define SSI_TIMEOUT_MS 2000
+#define SSI_POLL_TIMEOUT_US200
 #define SSI_MAX_CLK_DIVIDER254
 #define SSI_MIN_CLK_DIVIDER4
 
@@ -290,21 +292,23 @@ static void uniphier_spi_recv(struct uniphier_spi_priv 
*priv)
 
 static void uniphier_spi_fill_tx_fifo(struct uniphier_spi_priv *priv)
 {
-   unsigned int tx_count;
+   unsigned int fifo_threshold, fill_bytes;
u32 val;
 
-   tx_count = DIV_ROUND_UP(priv->tx_bytes,
+   fifo_threshold = DIV_ROUND_UP(priv->rx_bytes,
bytes_per_word(priv->bits_per_word));
-   tx_count = min(tx_count, SSI_FIFO_DEPTH);
+   fifo_threshold = min(fifo_threshold, SSI_FIFO_DEPTH);
+
+   fill_bytes = fifo_threshold - (priv->rx_bytes - priv->tx_bytes);
 
/* set fifo threshold */
val = readl(priv->base + SSI_FC);
val &= ~(SSI_FC_TXFTH_MASK | SSI_FC_RXFTH_MASK);
-   val |= FIELD_PREP(SSI_FC_TXFTH_MASK, tx_count);
-   val |= FIELD_PREP(SSI_FC_RXFTH_MASK, tx_count);
+   val |= FIELD_PREP(SSI_FC_TXFTH_MASK, fifo_threshold);
+   val |= FIELD_PREP(SSI_FC_RXFTH_MASK, fifo_threshold);
writel(val, priv->base + SSI_FC);
 
-   while (tx_count--)
+   while (fill_bytes--)
uniphier_spi_send(priv);
 }
 
@@ -323,20 +327,14 @@ static void uniphier_spi_set_cs(struct spi_device *spi, 
bool enable)
writel(val, priv->base + SSI_FPS);
 }
 
-static int uniphier_spi_transfer_one(struct spi_master *master,
-struct spi_device *spi,
-struct spi_transfer *t)
+static int uniphier_spi_transfer_one_irq(struct spi_master *master,
+struct spi_device *spi,
+struct spi_transfer *t)
 {
struct uniphier_spi_priv *priv = spi_master_get_devdata(master);
struct device *dev = master->dev.parent;
unsigned long time_left;
 
-   /* Terminate and return success for 0 byte length transfer */
-   if (!t->len)
-   return 0;
-
-   uniphier_spi_setup_transfer(spi, t);
-
reinit_completion(>xfer_done);
 
uniphier_spi_fill_tx_fifo(priv);
@@ -356,6 +354,59 @@ static int uniphier_spi_transfer_one(struct spi_master 
*master,
return priv->error;
 }
 
+static int uniphier_spi_transfer_one_poll(struct spi_master *master,
+ struct spi_device *spi,
+ struct spi_transfer *t)
+{
+   struct uniphier_spi_priv *priv = spi_master_get_devdata(master);
+   int loop = SSI_POLL_TIMEOUT_US * 10;
+
+   while (priv->tx_bytes) {
+   uniphier_spi_fill_tx_fifo(priv);
+
+   while ((priv->rx_bytes - priv->tx_bytes) > 0) {
+   while (!(readl(priv->base + SSI_SR) & SSI_SR_RNE)
+   && loop--)
+   ndelay(100);
+
+   if (loop == -1)
+   goto irq_transfer;
+
+   uniphier_spi_recv(priv);
+   }
+   }
+
+   return 0;
+
+irq_transfer:
+   return uniphier_spi_transfer_one_irq(master, spi, t);
+}
+
+static int uniphier_spi_transfer_one(struct spi_master *master,
+struct spi_device *spi,
+struct spi_transfer *t)
+{
+   struct uniphier_spi_priv *priv = spi_master_get_devdata(master);
+   unsigned long threshold;
+
+   /* Terminate and return success for 0 byte length transfer */
+   if (!t->len)
+   return 0;
+
+   uniphier_spi_setup_transfer(spi, t);
+
+   /*
+* If the transfer operation will take longer than
+* SSI_POLL_TIMEOUT_US, it should use irq.
+*/
+   threshold = DIV_ROUND_UP(SSI_POLL_TIMEOUT_US * priv->speed_hz,
+   USEC_PER_SEC * BITS_PER_BYTE);
+   if (t->len > threshold)
+   return uniphier_spi_transfer_one_irq(master, spi, t);
+   else
+   return uniphier_spi_transfer_one_poll(master, spi, t);
+}
+
 static int uniphier_spi_prepare_transfer_hardware(struct spi_master *master)
 {
struct uniphier_spi_priv *priv = 

[PATCH 1/3] spi: uniphier: fix wrong register overwrite

[Keiji Hayashibara]

When it changes the spi mode, the register is overwritten incorrectly.
This commit fixes this register overwrite.

Signed-off-by: Keiji Hayashibara 
---
 drivers/spi/spi-uniphier.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index c1e6f32..e6ebbb1 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -214,6 +214,7 @@ static void uniphier_spi_setup_transfer(struct spi_device 
*spi,
if (!priv->is_save_param || priv->mode != spi->mode) {
uniphier_spi_set_mode(spi);
priv->mode = spi->mode;
+   priv->is_save_param = false;
}
 
if (!priv->is_save_param || priv->bits_per_word != t->bits_per_word) {
-- 
2.7.4

[PATCH 2/3] spi: uniphier: remove unnecessary code

[Keiji Hayashibara]

This commit removed if() because priv->is_save_param is always true.

Signed-off-by: Keiji Hayashibara 
---
 drivers/spi/spi-uniphier.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index e6ebbb1..d40ad93 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -227,8 +227,7 @@ static void uniphier_spi_setup_transfer(struct spi_device 
*spi,
priv->speed_hz = t->speed_hz;
}
 
-   if (!priv->is_save_param)
-   priv->is_save_param = true;
+   priv->is_save_param = true;
 
/* reset FIFOs */
val = SSI_FC_TXFFL | SSI_FC_RXFFL;
-- 
2.7.4

[PATCH 0/3] spi: uniphier: introduce polling mode and fix bug

[Keiji Hayashibara]

This series introduces new polling mode and fixes bug.

- Introduce new polling mode for short size transfer. Either the estimated
  transfer time is estimated to exceed 200us, or polling loop actually exceeds
  200us, it switches to irq mode.
- Fix a bug of register overwrite.
- Minor corrections.

Keiji Hayashibara (3):
  spi: uniphier: fix wrong register overwrite
  spi: uniphier: remove unnecessary code
  spi: uniphier: introduce polling mode

 drivers/spi/spi-uniphier.c | 85 --
 1 file changed, 68 insertions(+), 17 deletions(-)

-- 
2.7.4

Re: [PATCH] ALSA: hda/realtek - Enable internal speaker & headset mic of ASUS UX431FL

[Jian-Hong Pan]

Takashi Iwai  於 2019年9月2日 週一 下午7:41寫道：
>
> On Mon, 02 Sep 2019 12:00:56 +0200,
> Jian-Hong Pan wrote:
> >
> > Original pin node values of ASUS UX431FL with ALC294:
> >
> > 0x12 0xb7a60140
> > 0x13 0x4000
> > 0x14 0x90170110
> > 0x15 0x41f0
> > 0x16 0x41f0
> > 0x17 0x90170111
> > 0x18 0x41f0
> > 0x19 0x41f0
> > 0x1a 0x41f0
> > 0x1b 0x41f0
> > 0x1d 0x4066852d
> > 0x1e 0x41f0
> > 0x1f 0x41f0
> > 0x21 0x04211020
> >
> > 1. Has duplicated internal speakers (0x14 & 0x17) which makes the output
> >route become confused. So, the output volume cannot be changed by
> >setting.
> > 2. Misses the headset mic pin node.
> >
> > This patch disables the confusing speaker (NID 0x14) and enables the
> > headset mic (NID 0x19).
>
> Is 0x14 really a dead pin?  Or is a surround/bass speaker or such?

I checked Windows (updated to latest and including Realtek MEDIA) on
ASUS UX431FL laptop again.  Although it has two internal speaker pins,
there is only one set of internal speaker including left/right
channels.  And the audio test (Speaker Setup) only shows left/right
channels.  So, NID 0x14 can be disabled.

Jain-Hong Pan

> >
> > Signed-off-by: Jian-Hong Pan 
> > ---
> >  sound/pci/hda/patch_realtek.c | 12 
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c
> > index e333b3e30e31..0a1fa99a6723 100644
> > --- a/sound/pci/hda/patch_realtek.c
> > +++ b/sound/pci/hda/patch_realtek.c
> > @@ -5797,6 +5797,7 @@ enum {
> >   ALC286_FIXUP_ACER_AIO_HEADSET_MIC,
> >   ALC256_FIXUP_ASUS_MIC_NO_PRESENCE,
> >   ALC299_FIXUP_PREDATOR_SPK,
> > + ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC,
> >  };
> >
> >  static const struct hda_fixup alc269_fixups[] = {
> > @@ -6837,6 +6838,16 @@ static const struct hda_fixup alc269_fixups[] = {
> >   { }
> >   }
> >   },
> > + [ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC] = {
> > + .type = HDA_FIXUP_PINS,
> > + .v.pins = (const struct hda_pintbl[]) {
> > + { 0x14, 0x41f0 }, /* disable confusing internal 
> > speaker */
> > + { 0x19, 0x04a11150 }, /* use as headset mic, without 
> > its own jack detect */
> > + { }
> > + },
> > + .chained = true,
> > + .chain_id = ALC269_FIXUP_HEADSET_MODE_NO_HP_MIC
> > + },
> >  };
> >
> >  static const struct snd_pci_quirk alc269_fixup_tbl[] = {
> > @@ -6995,6 +7006,7 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] 
> > = {
> >   SND_PCI_QUIRK(0x1043, 0x1427, "Asus Zenbook UX31E", 
> > ALC269VB_FIXUP_ASUS_ZENBOOK),
> >   SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", 
> > ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A),
> >   SND_PCI_QUIRK(0x1043, 0x16e3, "ASUS UX50", ALC269_FIXUP_STEREO_DMIC),
> > + SND_PCI_QUIRK(0x1043, 0x17d1, "ASUS UX431FL", 
> > ALC294_FIXUP_ASUS_INTSPK_HEADSET_MIC),
> >   SND_PCI_QUIRK(0x1043, 0x1a13, "Asus G73Jw", ALC269_FIXUP_ASUS_G73JW),
> >   SND_PCI_QUIRK(0x1043, 0x1a30, "ASUS X705UD", ALC256_FIXUP_ASUS_MIC),
> >   SND_PCI_QUIRK(0x1043, 0x1b13, "Asus U41SV", ALC269_FIXUP_INV_DMIC),
> > --
> > 2.20.1
> >
> >

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

[Stephen Rothwell]

Hi all,

On Mon, 2 Sep 2019 14:26:40 + "Lendacky, Thomas"  
wrote:
>
> On 9/2/19 9:03 AM, Joerg Roedel wrote:
> > 
> > tl;dr: And IOMMU commit introduces a new user for sme_active() in
> > generic code, and commit
> > 
> > 284e21fab2cf x86, s390/mm: Move sme_active() and sme_me_mask to 
> > x86-specific header
> > 
> > breaks the build of drivers/iommu/ for all architectures not
> > implementing sme_active().
> > 
> > On Mon, Sep 02, 2019 at 04:39:51PM +1000, Stephen Rothwell wrote:  
> >> drivers/iommu/iommu.c: In function 'iommu_subsys_init':
> >> drivers/iommu/iommu.c:123:38: error: implicit declaration of function 
> >> 'sme_active'; did you mean 'cpu_active'? 
> >> [-Werror=implicit-function-declaration]
> >>123 |   if (iommu_default_passthrough() && sme_active()) {  
> 
> Maybe we should make this mem_encrypt_active(), since this will probably
> be needed if/when an IOMMU device is eventually added to a guest, and the
> referenced commit below doesn't remove that call.

I have done that for today:

From: Stephen Rothwell 
Date: Tue, 3 Sep 2019 15:19:34 +1000
Subject: [PATCH] iommu: use mem_encrypt_active() instead of sme_active()

Signed-off-by: Stephen Rothwell 
---
 drivers/iommu/iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 66cfacaa483d..b870044ecd49 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -120,7 +120,7 @@ static int __init iommu_subsys_init(void)
else
iommu_set_default_translated(false);
 
-   if (iommu_default_passthrough() && sme_active()) {
+   if (iommu_default_passthrough() && mem_encrypt_active()) {
pr_info("SME detected - Disabling default IOMMU 
Passthrough\n");
iommu_set_default_translated(false);
}
-- 
2.23.0.rc1

-- 
Cheers,
Stephen Rothwell


pgpLUni_l2Kxr.pgp
Description: OpenPGP digital signature

[PATCH v2 3/6] powerpc: Convert flush_icache_range & friends to C

[Alastair D'Silva]

From: Alastair D'Silva 

Similar to commit 22e9c88d486a
("powerpc/64: reuse PPC32 static inline flush_dcache_range()")
this patch converts the following ASM symbols to C:
flush_icache_range()
__flush_dcache_icache()
__flush_dcache_icache_phys()

This was done as we discovered a long-standing bug where the length of the
range was truncated due to using a 32 bit shift instead of a 64 bit one.

By converting these functions to C, it becomes easier to maintain.

flush_dcache_icache_phys() retains a critical assembler section as we must
ensure there are no memory accesses while the data MMU is disabled
(authored by Christophe Leroy). Since this has no external callers, it has
also been made static, allowing the compiler to inline it within
flush_dcache_icache_page().

Signed-off-by: Alastair D'Silva 
Signed-off-by: Christophe Leroy 
---
 arch/powerpc/include/asm/cache.h  |  26 ++---
 arch/powerpc/include/asm/cacheflush.h |  24 ++--
 arch/powerpc/kernel/misc_32.S | 117 
 arch/powerpc/kernel/misc_64.S | 102 -
 arch/powerpc/mm/mem.c | 152 +-
 5 files changed, 173 insertions(+), 248 deletions(-)

diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index f852d5cd746c..91c808c6738b 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -98,20 +98,7 @@ static inline u32 l1_icache_bytes(void)
 #endif
 #endif /* ! __ASSEMBLY__ */
 
-#if defined(__ASSEMBLY__)
-/*
- * For a snooping icache, we still need a dummy icbi to purge all the
- * prefetched instructions from the ifetch buffers. We also need a sync
- * before the icbi to order the the actual stores to memory that might
- * have modified instructions with the icbi.
- */
-#define PURGE_PREFETCHED_INS   \
-   sync;   \
-   icbi0,r3;   \
-   sync;   \
-   isync
-
-#else
+#if !defined(__ASSEMBLY__)
 #define __read_mostly __attribute__((__section__(".data..read_mostly")))
 
 #ifdef CONFIG_PPC_BOOK3S_32
@@ -145,6 +132,17 @@ static inline void dcbst(void *addr)
 {
__asm__ __volatile__ ("dcbst %y0" : : "Z"(*(u8 *)addr) : "memory");
 }
+
+static inline void icbi(void *addr)
+{
+   __asm__ __volatile__ ("icbi 0, %0" : : "r"(addr) : "memory");
+}
+
+static inline void iccci(void *addr)
+{
+   __asm__ __volatile__ ("iccci 0, %0" : : "r"(addr) : "memory");
+}
+
 #endif /* !__ASSEMBLY__ */
 #endif /* __KERNEL__ */
 #endif /* _ASM_POWERPC_CACHE_H */
diff --git a/arch/powerpc/include/asm/cacheflush.h 
b/arch/powerpc/include/asm/cacheflush.h
index ed57843ef452..4a1c9f0200e1 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -42,24 +42,20 @@ extern void flush_dcache_page(struct page *page);
 #define flush_dcache_mmap_lock(mapping)do { } while (0)
 #define flush_dcache_mmap_unlock(mapping)  do { } while (0)
 
-extern void flush_icache_range(unsigned long, unsigned long);
+void flush_icache_range(unsigned long start, unsigned long stop);
 extern void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
int len);
-extern void __flush_dcache_icache(void *page_va);
 extern void flush_dcache_icache_page(struct page *page);
-#if defined(CONFIG_PPC32) && !defined(CONFIG_BOOKE)
-extern void __flush_dcache_icache_phys(unsigned long physaddr);
-#else
-static inline void __flush_dcache_icache_phys(unsigned long physaddr)
-{
-   BUG();
-}
-#endif
-
-/*
- * Write any modified data cache blocks out to memory and invalidate them.
- * Does not invalidate the corresponding instruction cache blocks.
+void __flush_dcache_icache(void *page);
+
+/**
+ * flush_dcache_range(): Write any modified data cache blocks out to memory and
+ * invalidate them. Does not invalidate the corresponding instruction cache
+ * blocks.
+ *
+ * @start: the start address
+ * @stop: the stop address (exclusive)
  */
 static inline void flush_dcache_range(unsigned long start, unsigned long stop)
 {
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index fe4bd321730e..12b95e6799d4 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -318,123 +318,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_UNIFIED_ID_CACHE)
 EXPORT_SYMBOL(flush_instruction_cache)
 #endif /* CONFIG_PPC_8xx */
 
-/*
- * Write any modified data cache blocks out to memory
- * and invalidate the corresponding instruction cache blocks.
- * This is a no-op on the 601.
- *
- * flush_icache_range(unsigned long start, unsigned long stop)
- */
-_GLOBAL(flush_icache_range)
-BEGIN_FTR_SECTION
-   PURGE_PREFETCHED_INS
-   blr /* for 601, do nothing */
-END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
-   rlwinm  r3,r3,0,0,31 - L1_CACHE_SHIFT
-   subfr4,r3,r4
-   

[PATCH v2 6/6] powerpc: Don't flush caches when adding memory

[Alastair D'Silva]

From: Alastair D'Silva 

This operation takes a significant amount of time when hotplugging
large amounts of memory (~50 seconds with 890GB of persistent memory).

This was orignally in commit fb5924fddf9e
("powerpc/mm: Flush cache on memory hot(un)plug") to support memtrace,
but the flush on add is not needed as it is flushed on remove.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/mm/mem.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 854aaea2c6ae..2a14b5b93e19 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -111,7 +111,6 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
 {
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
-   u64 i;
int rc;
 
resize_hpt_for_hotplug(memblock_phys_mem_size());
@@ -124,12 +123,6 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
return -EFAULT;
}
 
-   for (i = 0; i < size; i += FLUSH_CHUNK_SIZE) {
-   flush_dcache_range(start + i,
-  min(start + size, start + i + 
FLUSH_CHUNK_SIZE));
-   cond_resched();
-   }
-
return __add_pages(nid, start_pfn, nr_pages, restrictions);
 }
 
-- 
2.21.0

[PATCH v2 5/6] powerpc: Remove 'extern' from func prototypes in cache headers

[Alastair D'Silva]

From: Alastair D'Silva 

The 'extern' keyword does not value-add for function prototypes.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/include/asm/cache.h  | 8 
 arch/powerpc/include/asm/cacheflush.h | 6 +++---
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index 91c808c6738b..54fffdf5a6ec 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -102,10 +102,10 @@ static inline u32 l1_icache_bytes(void)
 #define __read_mostly __attribute__((__section__(".data..read_mostly")))
 
 #ifdef CONFIG_PPC_BOOK3S_32
-extern long _get_L2CR(void);
-extern long _get_L3CR(void);
-extern void _set_L2CR(unsigned long);
-extern void _set_L3CR(unsigned long);
+long _get_L2CR(void);
+long _get_L3CR(void);
+void _set_L2CR(unsigned long val);
+void _set_L3CR(unsigned long val);
 #else
 #define _get_L2CR()0L
 #define _get_L3CR()0L
diff --git a/arch/powerpc/include/asm/cacheflush.h 
b/arch/powerpc/include/asm/cacheflush.h
index 4a1c9f0200e1..fa10dc19206c 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -38,15 +38,15 @@ static inline void flush_cache_vmap(unsigned long start, 
unsigned long end) { }
 #endif
 
 #define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 1
-extern void flush_dcache_page(struct page *page);
+void flush_dcache_page(struct page *page);
 #define flush_dcache_mmap_lock(mapping)do { } while (0)
 #define flush_dcache_mmap_unlock(mapping)  do { } while (0)
 
 void flush_icache_range(unsigned long start, unsigned long stop);
-extern void flush_icache_user_range(struct vm_area_struct *vma,
+void flush_icache_user_range(struct vm_area_struct *vma,
struct page *page, unsigned long addr,
int len);
-extern void flush_dcache_icache_page(struct page *page);
+void flush_dcache_icache_page(struct page *page);
 void __flush_dcache_icache(void *page);
 
 /**
-- 
2.21.0

[PATCH v2 4/6] powerpc: Chunk calls to flush_dcache_range in arch_*_memory

[Alastair D'Silva]

From: Alastair D'Silva 

When presented with large amounts of memory being hotplugged
(in my test case, ~890GB), the call to flush_dcache_range takes
a while (~50 seconds), triggering RCU stalls.

This patch breaks up the call into 1GB chunks, calling
cond_resched() inbetween to allow the scheduler to run.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/mm/mem.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index cd540123874d..854aaea2c6ae 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -104,11 +104,14 @@ int __weak remove_section_mapping(unsigned long start, 
unsigned long end)
return -ENODEV;
 }
 
+#define FLUSH_CHUNK_SIZE SZ_1G
+
 int __ref arch_add_memory(int nid, u64 start, u64 size,
struct mhp_restrictions *restrictions)
 {
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
+   u64 i;
int rc;
 
resize_hpt_for_hotplug(memblock_phys_mem_size());
@@ -120,7 +123,12 @@ int __ref arch_add_memory(int nid, u64 start, u64 size,
start, start + size, rc);
return -EFAULT;
}
-   flush_dcache_range(start, start + size);
+
+   for (i = 0; i < size; i += FLUSH_CHUNK_SIZE) {
+   flush_dcache_range(start + i,
+  min(start + size, start + i + 
FLUSH_CHUNK_SIZE));
+   cond_resched();
+   }
 
return __add_pages(nid, start_pfn, nr_pages, restrictions);
 }
@@ -131,13 +139,19 @@ void __ref arch_remove_memory(int nid, u64 start, u64 
size,
unsigned long start_pfn = start >> PAGE_SHIFT;
unsigned long nr_pages = size >> PAGE_SHIFT;
struct page *page = pfn_to_page(start_pfn) + vmem_altmap_offset(altmap);
+   u64 i;
int ret;
 
__remove_pages(page_zone(page), start_pfn, nr_pages, altmap);
 
/* Remove htab bolted mappings for this section of memory */
start = (unsigned long)__va(start);
-   flush_dcache_range(start, start + size);
+   for (i = 0; i < size; i += FLUSH_CHUNK_SIZE) {
+   flush_dcache_range(start + i,
+  min(start + size, start + i + 
FLUSH_CHUNK_SIZE));
+   cond_resched();
+   }
+
ret = remove_section_mapping(start, start + size);
WARN_ON_ONCE(ret);
 
-- 
2.21.0

[PATCH v2 2/6] powerpc: define helpers to get L1 icache sizes

[Alastair D'Silva]

From: Alastair D'Silva 

This patch adds helpers to retrieve icache sizes, and renames the existing
helpers to make it clear that they are for dcache.

Signed-off-by: Alastair D'Silva 
---
 arch/powerpc/include/asm/cache.h  | 29 +++
 arch/powerpc/include/asm/cacheflush.h | 12 +--
 2 files changed, 31 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/include/asm/cache.h b/arch/powerpc/include/asm/cache.h
index b3388d95f451..f852d5cd746c 100644
--- a/arch/powerpc/include/asm/cache.h
+++ b/arch/powerpc/include/asm/cache.h
@@ -55,25 +55,46 @@ struct ppc64_caches {
 
 extern struct ppc64_caches ppc64_caches;
 
-static inline u32 l1_cache_shift(void)
+static inline u32 l1_dcache_shift(void)
 {
return ppc64_caches.l1d.log_block_size;
 }
 
-static inline u32 l1_cache_bytes(void)
+static inline u32 l1_dcache_bytes(void)
 {
return ppc64_caches.l1d.block_size;
 }
+
+static inline u32 l1_icache_shift(void)
+{
+   return ppc64_caches.l1i.log_block_size;
+}
+
+static inline u32 l1_icache_bytes(void)
+{
+   return ppc64_caches.l1i.block_size;
+}
 #else
-static inline u32 l1_cache_shift(void)
+static inline u32 l1_dcache_shift(void)
 {
return L1_CACHE_SHIFT;
 }
 
-static inline u32 l1_cache_bytes(void)
+static inline u32 l1_dcache_bytes(void)
 {
return L1_CACHE_BYTES;
 }
+
+static inline u32 l1_icache_shift(void)
+{
+   return L1_CACHE_SHIFT;
+}
+
+static inline u32 l1_icache_bytes(void)
+{
+   return L1_CACHE_BYTES;
+}
+
 #endif
 #endif /* ! __ASSEMBLY__ */
 
diff --git a/arch/powerpc/include/asm/cacheflush.h 
b/arch/powerpc/include/asm/cacheflush.h
index eef388f2659f..ed57843ef452 100644
--- a/arch/powerpc/include/asm/cacheflush.h
+++ b/arch/powerpc/include/asm/cacheflush.h
@@ -63,8 +63,8 @@ static inline void __flush_dcache_icache_phys(unsigned long 
physaddr)
  */
 static inline void flush_dcache_range(unsigned long start, unsigned long stop)
 {
-   unsigned long shift = l1_cache_shift();
-   unsigned long bytes = l1_cache_bytes();
+   unsigned long shift = l1_dcache_shift();
+   unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
@@ -89,8 +89,8 @@ static inline void flush_dcache_range(unsigned long start, 
unsigned long stop)
  */
 static inline void clean_dcache_range(unsigned long start, unsigned long stop)
 {
-   unsigned long shift = l1_cache_shift();
-   unsigned long bytes = l1_cache_bytes();
+   unsigned long shift = l1_dcache_shift();
+   unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
@@ -108,8 +108,8 @@ static inline void clean_dcache_range(unsigned long start, 
unsigned long stop)
 static inline void invalidate_dcache_range(unsigned long start,
   unsigned long stop)
 {
-   unsigned long shift = l1_cache_shift();
-   unsigned long bytes = l1_cache_bytes();
+   unsigned long shift = l1_dcache_shift();
+   unsigned long bytes = l1_dcache_bytes();
void *addr = (void *)(start & ~(bytes - 1));
unsigned long size = stop - (unsigned long)addr + (bytes - 1);
unsigned long i;
-- 
2.21.0

[PATCH v2 0/6] powerpc: convert cache asm to C

[Alastair D'Silva]

From: Alastair D'Silva 

This series addresses a few issues discovered in how we flush caches:
1. Flushes were truncated at 4GB, so larger flushes were incorrect.
2. Flushing the dcache in arch_add_memory was unnecessary

This series also converts much of the cache assembler to C, with the
aim of making it easier to maintain.

Alastair D'Silva (6):
  powerpc: Allow flush_icache_range to work across ranges >4GB
  powerpc: define helpers to get L1 icache sizes
  powerpc: Convert flush_icache_range & friends to C
  powerpc: Chunk calls to flush_dcache_range in arch_*_memory
  powerpc: Remove 'extern' from func prototypes in cache headers
  powerpc: Don't flush caches when adding memory

Changelog:
 V2:
 - Replace C implementation of flush_dcache_icache_phys() with
   inline assembler authored by Christophe Leroy
 - Add memory clobbers for iccci implementation
 - Give __flush_dcache_icache a real implementation, it can't
   just be a wrapper around flush_icache_range()
 - Remove PPC64_CACHES from misc_64.S
 - Replace code duplicating clean_dcache_range() in
   flush_icache_range() with a call to clean_dcache_range()
 - Replace #ifdef CONFIG_44x with IS_ENABLED(...) in
   flush_icache_cange()
 - Use 1GB chunks instead of 16GB in arch_*_memory


 arch/powerpc/include/asm/cache.h  |  63 ++
 arch/powerpc/include/asm/cacheflush.h |  37 +++---
 arch/powerpc/kernel/misc_32.S | 117 ---
 arch/powerpc/kernel/misc_64.S | 102 -
 arch/powerpc/mm/mem.c | 159 +-
 5 files changed, 213 insertions(+), 265 deletions(-)

-- 
2.21.0

[PATCH v2 1/6] powerpc: Allow flush_icache_range to work across ranges >4GB

[Alastair D'Silva]

From: Alastair D'Silva 

When calling flush_icache_range with a size >4GB, we were masking
off the upper 32 bits, so we would incorrectly flush a range smaller
than intended.

This patch replaces the 32 bit shifts with 64 bit ones, so that
the full size is accounted for.

Signed-off-by: Alastair D'Silva 
Cc: sta...@vger.kernel.org
---
 arch/powerpc/kernel/misc_64.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index b55a7b4cb543..9bc0aa9aeb65 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -82,7 +82,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
subfr8,r6,r4/* compute length */
add r8,r8,r5/* ensure we get enough */
lwz r9,DCACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of cache block 
size */
-   srw.r8,r8,r9/* compute line count */
+   srd.r8,r8,r9/* compute line count */
beqlr   /* nothing to do? */
mtctr   r8
 1: dcbst   0,r6
@@ -98,7 +98,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
subfr8,r6,r4/* compute length */
add r8,r8,r5
lwz r9,ICACHEL1LOGBLOCKSIZE(r10)/* Get log-2 of Icache block 
size */
-   srw.r8,r8,r9/* compute line count */
+   srd.r8,r8,r9/* compute line count */
beqlr   /* nothing to do? */
mtctr   r8
 2: icbi0,r6
-- 
2.21.0

Re: "fs/namei.c: keep track of nd->root refcount status" causes boot panic

[Dexuan-Linux Cui]

On Mon, Sep 2, 2019 at 9:22 PM Qian Cai  wrote:
>
> The linux-next commit "fs/namei.c: keep track of nd->root refcount status” 
> [1] causes boot panic on all
> architectures here on today’s linux-next (0902). Reverted it will fix the 
> issue.

I believe I'm seeing the same issue with next-20190902 in a Linux VM
running on Hyper-V (next-20190830 is good).

git-bisect points to the same commit in linux-next:
e013ec23b823 ("fs/namei.c: keep track of nd->root refcount status")

I can reproduce the issue every time I reboot the system.

Thanks,
Dexuan

Re: [PATCH v7 5/6] powerpc/64: Make COMPAT user-selectable disabled on littleendian by default.

[Christophe Leroy]

On 09/02/2019 11:53 PM, Michael Ellerman wrote:

Segher Boessenkool  writes:

On Mon, Sep 02, 2019 at 12:03:12PM +1000, Michael Ellerman wrote:

Michal Suchanek  writes:

On bigendian ppc64 it is common to have 32bit legacy binaries but much
less so on littleendian.


I think the toolchain people will tell you that there is no 32-bit
little endian ABI defined at all, if anything works it's by accident.

 ^
 v2


There of course is a lot of powerpcle-* support.  The ABI used for it
on linux is the SYSV ABI, just like on BE 32-bit.


I was talking about ELFv2, which is 64-bit only. But that was based on
me thinking we had a hard assumption in the kernel that ppc64le kernels
always expect ELFv2 userland. Looking at the code though I was wrong
about that, it looks like we will run little endian ELFv1 binaries,
though I don't think anyone is testing it.


There also is specific powerpcle-linux support in GCC, and in binutils,
too.  Also, config.guess/config.sub supports it.  Half a year ago this
all built fine (no, I don't test it often either).

I don't think glibc supports it though, so I wonder if anyone builds an
actual system with it?  Maybe busybox or the like?


So I think we should not make this selectable, unless someone puts their
hand up to say they want it and are willing to test it and keep it
working.


What about actual 32-bit LE systems?  Does anyone still use those?


Not that I've ever heard of.



We dropped support from 32-bit LE at least with a1f3ae3fe8a1 
("powerpc/32: Use stmw/lmw for registers save/restore in asm").


Discussion about it can be found at 
https://patchwork.ozlabs.org/patch/899465/


Christophe

[PATCH] iio: imu: st_lsm6dsx: replace underscore with hyphen in device name

[Martin Kepplinger]

With the underscore character in the lsm9ds1_imu device name, we get the
following error below, so use a dash, just like the other device names do too.

[3.961399] Unable to handle kernel NULL pointer dereference at virtual 
address 0018
[4.010581] Mem abort info:
[4.013838]   ESR = 0x9604
[4.023602]   Exception class = DABT (current EL), IL = 32 bits
[4.047993]   SET = 0, FnV = 0
[4.052690]   EA = 0, S1PTW = 0
[4.056015] Data abort info:
[4.059020]   ISV = 0, ISS = 0x0004
[4.080106]   CM = 0, WnR = 0
[4.085237] user pgtable: 4k pages, 48-bit VAs, pgdp=e4f61000
[4.092194] [0018] pgd=
[4.097474] Internal error: Oops: 9604 [#1] PREEMPT SMP
[4.103286] Modules linked in: tcpci st_sensors st_lsm6dsx_i2c(+) tcpm 
st_lsm6dsx industrialio_triggered_buffer kfifo_buf vcnl4000 roles typec goodix 
snd_soc_sgtl5000 bq25890_charger snvs_pwrkey imx_sdma virt_dma qoriq_thermal 
imx2_wdt snd_soc_fsl_sai aes_ce_blk imx_pcm_dma crypto_simd watchdog 
crct10dif_ce ghash_ce sha2_ce snd_soc_simple_card snd_soc_gtm601 
snd_soc_simple_card_utils sha1_ce snd_soc_core snd_pcm_dmaengine snd_pcm 
snd_timer snd soundcore gpio_vibra usb_f_acm u_serial usb_f_rndis g_multi 
usb_f_mass_storage u_ether libcomposite ip_tables x_tables ipv6 nf_defrag_ipv6 
xhci_plat_hcd xhci_hcd usbcore dwc3 ulpi udc_core usb_common phy_fsl_imx8mq_usb
[4.105389] bq25890-charger 0-006b: Capacity for 3784000 is 86%
[4.164061] CPU: 1 PID: 344 Comm: systemd-udevd Tainted: GW 
5.3.0-rc2-g24e3d989d49f-dirty #161
[4.164063] Hardware name: Purism Librem 5 devkit (DT)
[4.164067] pstate: 8005 (Nzcv daif -PAN -UAO)
[4.164082] pc : st_lsm6dsx_i2c_probe+0x18/0x80 [st_lsm6dsx_i2c]
[4.164093] lr : i2c_device_probe+0x1f0/0x2b8
[4.164094] sp : 8000a499f970
[4.164097] x29: 8000a499f970 x28: 
[4.164100] x27: 10b7 x26: 8000a499fd68
[4.164104] x25: 1086 x24: 08a8b038
[4.164108] x23: 08a8b038 x22: 08a8b000
[4.164111] x21: 8000a55b2400 x20: 08a89000
[4.164115] x19: 8000a55b2400 x18: 
[4.164118] x17:  x16: 
[4.164121] x15: 0004 x14: fff0
[4.164125] x13: 10b6c898 x12: 0030
[4.164128] x11:  x10: 0101010101010101
[4.260542] x9 : fffc x8 : 0008
[4.266073] x7 : 0004 x6 : 1e0e1a00f2ade4ef
[4.271605] x5 : 6f642d72001a0e1e x4 : 80808080
[4.277136] x3 :  x2 : 08a8a000
[4.282667] x1 :  x0 : 8000a55b2400
[4.288199] Call trace:
[4.290753]  st_lsm6dsx_i2c_probe+0x18/0x80 [st_lsm6dsx_i2c]
[4.296648]  i2c_device_probe+0x1f0/0x2b8
[4.300825]  really_probe+0x168/0x368
[4.304638]  driver_probe_device.part.2+0x10c/0x128
[4.309716]  device_driver_attach+0x74/0xa0
[4.314071]  __driver_attach+0x84/0x130
[4.318065]  bus_for_each_dev+0x68/0xc8
[4.322058]  driver_attach+0x20/0x28
[4.325780]  bus_add_driver+0xd4/0x1f8
[4.329683]  driver_register+0x60/0x110
[4.333677]  i2c_register_driver+0x44/0x98
[4.337944]  st_lsm6dsx_driver_init+0x1c/0x1000 [st_lsm6dsx_i2c]
[4.344200]  do_one_initcall+0x58/0x1a8
[4.348195]  do_init_module+0x54/0x1d4
[4.352098]  load_module+0x1998/0x1c40
[4.356001]  __se_sys_finit_module+0xc0/0xd8
[4.360446]  __arm64_sys_finit_module+0x14/0x20
[4.365166]  el0_svc_common.constprop.0+0xb0/0x168
[4.370154]  el0_svc_handler+0x18/0x20
[4.374056]  el0_svc+0x8/0xc
[4.377059] Code: d283 910003fd a90153f3 aa0003f3 (f9400c34)
[4.383406] ---[ end trace 6dfe010c028e3371 ]---

Signed-off-by: Martin Kepplinger 
---

While this patch fixes my (formerly already mentioned) issue, it's
a question actually: Why does is this underscore character a problem?

thanks,

martin



 drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h 
b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
index 5e3cd96b0059..80e42c7dbcbe 100644
--- a/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
+++ b/drivers/iio/imu/st_lsm6dsx/st_lsm6dsx.h
@@ -24,7 +24,7 @@
 #define ST_LSM6DSR_DEV_NAME"lsm6dsr"
 #define ST_LSM6DS3TRC_DEV_NAME "lsm6ds3tr-c"
 #define ST_ISM330DHCX_DEV_NAME "ism330dhcx"
-#define ST_LSM9DS1_DEV_NAME"lsm9ds1_imu"
+#define ST_LSM9DS1_DEV_NAME"lsm9ds1-imu"
 
 enum st_lsm6dsx_hw_id {
ST_LSM6DS3_ID,
-- 
2.20.1

Re: [PATCH] ABI: Update dev-kmsg documentation to match current kernel behaviour

[Sergey Senozhatsky]

On (09/02/19 11:18), James Byrne wrote:
> Commit 5aa068ea4082 ("printk: remove games with previous record flags")
> abolished the practice of setting the log flag to 'c' for the first
> continuation line and '+' for subsequent lines. Now all continuation
> lines are flagged with 'c' and '+' is never used.
>
> Update the 'dev-kmsg' documentation to remove the reference to the
> obsolete '+' flag. In addition, state explicitly that only 8 bits of the
>  syslog prefix are used for the facility number when writing to
> /dev/kmsg.
>
> Signed-off-by: James Byrne 

Looks good to me.

Reviewed-by: Sergey Senozhatsky 

-ss

Re: [PATCH] soc/tegra: fuse: Add clock error check in tegra_fuse_readl

[Nagarjuna Kristam]

On 02-09-2019 16:15, Jon Hunter wrote:
> 
> On 28/08/2019 12:18, Nagarjuna Kristam wrote:
>> Tegra fuse clock handle is retrieved in tegra_fuse_probe().
>> tegra_fuse_readl() is exported symbol, which can be called from drivers
>> at any time. tegra_fuse_readl() enables fuse clock and reads corresponding
>> fuse register offset.
>>
>> Calling tegra_fuse_readl() before tegra_fuse_probe(), will cause data
>> abort. Add DEFER_PROBE error check for fuse clock in tegra_fuse_readl(),
>> to avoid enabling of fuse clock, before clock is available.
>>
>> Signed-off-by: Nagarjuna Kristam 
>> ---
>>  drivers/soc/tegra/fuse/fuse-tegra.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/soc/tegra/fuse/fuse-tegra.c 
>> b/drivers/soc/tegra/fuse/fuse-tegra.c
>> index 3eb44e6..21b39b7 100644
>> --- a/drivers/soc/tegra/fuse/fuse-tegra.c
>> +++ b/drivers/soc/tegra/fuse/fuse-tegra.c
>> @@ -186,7 +186,7 @@ u32 __init tegra_fuse_read_early(unsigned int offset)
>>  
>>  int tegra_fuse_readl(unsigned long offset, u32 *value)
>>  {
>> -if (!fuse->read)
>> +if (!fuse->read || (PTR_ERR(fuse->clk) == -EPROBE_DEFER))
>>  return -EPROBE_DEFER;
> 
> What about the case where fuse->clk is NULL or a different error value?
> 
> Jon
> 
Yes, all error checks are needed, will use IS_ERR as a separate condition for 
clock.

Thanks,
Nagarjuna

[PATCH 3/3] task: Clean house now that tasks on the runqueue are rcu protected

[Eric W. Biederman]

Use rcu_dereference instead of task_rcu_dereference.

Remove task_rcu_dereference.

Remove the complications of rcuwait that were in place because tasks
on the runqueue were not rcu protected.  It is now safe to call
wake_up_process if the target was know to be on the runqueue in the
current rcu interval.

Cc: Davidlohr Bueso 
Cc: Peter Zijlstra (Intel) 
Cc: Oleg Nesterov 
Ref: 8f95c90ceb54 ("sched/wait, RCU: Introduce rcuwait machinery")
Ref: 150593bf8693 ("sched/api: Introduce task_rcu_dereference() and 
try_get_task_struct()")
Signed-off-by: "Eric W. Biederman" 
---
 include/linux/rcuwait.h| 20 +++-
 include/linux/sched/task.h |  1 -
 kernel/exit.c  | 67 --
 kernel/sched/fair.c|  2 +-
 kernel/sched/membarrier.c  |  4 +--
 5 files changed, 7 insertions(+), 87 deletions(-)

diff --git a/include/linux/rcuwait.h b/include/linux/rcuwait.h
index 563290fc194f..75c97e4bbc57 100644
--- a/include/linux/rcuwait.h
+++ b/include/linux/rcuwait.h
@@ -6,16 +6,11 @@
 
 /*
  * rcuwait provides a way of blocking and waking up a single
- * task in an rcu-safe manner; where it is forbidden to use
- * after exit_notify(). task_struct is not properly rcu protected,
- * unless dealing with rcu-aware lists, ie: find_task_by_*().
+ * task in an rcu-safe manner.
  *
- * Alternatively we have task_rcu_dereference(), but the return
- * semantics have different implications which would break the
- * wakeup side. The only time @task is non-nil is when a user is
- * blocked (or checking if it needs to) on a condition, and reset
- * as soon as we know that the condition has succeeded and are
- * awoken.
+ * The only time @task is non-nil is when a user is blocked (or
+ * checking if it needs to) on a condition, and reset as soon as we
+ * know that the condition has succeeded and are awoken.
  */
 struct rcuwait {
struct task_struct __rcu *task;
@@ -37,13 +32,6 @@ extern void rcuwait_wake_up(struct rcuwait *w);
  */
 #define rcuwait_wait_event(w, condition)   \
 ({ \
-   /*  \
-* Complain if we are called after do_exit()/exit_notify(), \
-* as we cannot rely on the rcu critical region for the \
-* wakeup side. \
-*/ \
-   WARN_ON(current->exit_state);   \
-   \
rcu_assign_pointer((w)->task, current); \
for (;;) {  \
/*  \
diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index 4c44c37236b2..8bd51af44bf8 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -115,7 +115,6 @@ static inline void put_task_struct(struct task_struct *t)
__put_task_struct(t);
 }
 
-struct task_struct *task_rcu_dereference(struct task_struct **ptask);
 void put_task_struct_rcu_user(struct task_struct *task);
 
 #ifdef CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT
diff --git a/kernel/exit.c b/kernel/exit.c
index 2e259286f4e7..f943773622fc 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -234,69 +234,6 @@ void release_task(struct task_struct *p)
goto repeat;
 }
 
-/*
- * Note that if this function returns a valid task_struct pointer (!NULL)
- * task->usage must remain >0 for the duration of the RCU critical section.
- */
-struct task_struct *task_rcu_dereference(struct task_struct **ptask)
-{
-   struct sighand_struct *sighand;
-   struct task_struct *task;
-
-   /*
-* We need to verify that release_task() was not called and thus
-* delayed_put_task_struct() can't run and drop the last reference
-* before rcu_read_unlock(). We check task->sighand != NULL,
-* but we can read the already freed and reused memory.
-*/
-retry:
-   task = rcu_dereference(*ptask);
-   if (!task)
-   return NULL;
-
-   probe_kernel_address(>sighand, sighand);
-
-   /*
-* Pairs with atomic_dec_and_test() in put_task_struct(). If this task
-* was already freed we can not miss the preceding update of this
-* pointer.
-*/
-   smp_rmb();
-   if (unlikely(task != READ_ONCE(*ptask)))
-   goto retry;
-
-   /*
-* We've re-checked that "task == *ptask", now we have two different
-* cases:
-*
-* 1. This is actually the same task/task_struct. In this case
-*sighand != NULL tells us it is still alive.
-*
-* 2. This is another task which got the same memory for task_struct.
-*We can't know 

[PATCH 2/3] task: RCU protect tasks on the runqueue

[Eric W. Biederman]

In the ordinary case today the rcu grace period of a task comes when a
task is reaped, well after the task has left the runqueue.  This
change guarantees that the rcu grace period always happens after a
task has left the runqueue.  As this is something that usaually happens
today I do not expect any code correctness problems with this change.
At most I anticipate timing challenges.

The only code that will run later are the functions
perf_event_delayed_put, and trace-sched_process_free.  The function
perf_event_delayed_put in the final analysis is just a WARN_ON for
cases that I assume should never happen.  So I don't see any problem
with delaying it.

The function trace_sched_process_free is a trace point and thus user
space visible.   The strangest dependencies can happen but short
of the bizarre it appears to me that trace_sched_process_free is
getting a slightly more accurate picture of when a task struct
is free.  As it is now guaranteed that the process will not be
on the runqueue.

Resources for a process are freed in release_task or in __put_task_struct
when the reference count goes to 0.  Both of which are happening at
effectively the same time as before.  The rcu grace period is just
potentially happening a little bit later in the timeline.

In the common case of a process being reaped after it leaves the
runqueue everything will happen exactly as before.

In the case where a task self reaps we are pretty much guaranteed that
the rcu grace period is delayed.  So we should get quite a bit of
coverage in of this worst case for the change in a normal threaded
workload.  So I expect any issues to turn up quickly or not at all.

I have lightly tested this change and everything appears to work
fine.

Inspired-by: Linus Torvalds 
Inspired-by: Oleg Nesterov 
Signed-off-by: "Eric W. Biederman" 
---
 kernel/fork.c   | 11 +++
 kernel/sched/core.c |  7 ---
 2 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/kernel/fork.c b/kernel/fork.c
index 9f04741d5c70..7a74ade4e7d6 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -900,10 +900,13 @@ static struct task_struct *dup_task_struct(struct 
task_struct *orig, int node)
if (orig->cpus_ptr == >cpus_mask)
tsk->cpus_ptr = >cpus_mask;
 
-   /* One for the user space visible state that goes away when reaped. */
-   refcount_set(>rcu_users, 1);
-   /* One for the rcu users, and one for the scheduler */
-   refcount_set(>usage, 2);
+   /*
+* One for the user space visible state that goes away when reaped.
+* One for the scheduler.
+*/
+   refcount_set(>rcu_users, 2);
+   /* One for the rcu users */
+   refcount_set(>usage, 1);
 #ifdef CONFIG_BLK_DEV_IO_TRACE
tsk->btrace_seq = 0;
 #endif
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2b037f195473..802958407369 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3135,7 +3135,7 @@ static struct rq *finish_task_switch(struct task_struct 
*prev)
/* Task is done with its stack. */
put_task_stack(prev);
 
-   put_task_struct(prev);
+   put_task_struct_rcu_user(prev);
}
 
tick_nohz_task_switch();
@@ -3857,7 +3857,7 @@ static void __sched notrace __schedule(bool preempt)
 
if (likely(prev != next)) {
rq->nr_switches++;
-   rq->curr = next;
+   rcu_assign_pointer(rq->curr, next);
/*
 * The membarrier system call requires each architecture
 * to have a full memory barrier after updating
@@ -5863,7 +5863,8 @@ void init_idle(struct task_struct *idle, int cpu)
__set_task_cpu(idle, cpu);
rcu_read_unlock();
 
-   rq->curr = rq->idle = idle;
+   rq->idle = idle;
+   rcu_assign_pointer(rq->curr, idle);
idle->on_rq = TASK_ON_RQ_QUEUED;
 #ifdef CONFIG_SMP
idle->on_cpu = 1;
-- 
2.21.0.dirty

[PATCH 1/3] task: Add a count of task rcu users

[Eric W. Biederman]

Add a count of the number of rcu users (currently 1) of the task
struct so that we can later add the scheduler case and get rid of the
very subtle task_rcu_dereference, and just use rcu_dereference.

As suggested by Oleg have the count overlap rcu_head so that no
additional space in task_struct is required.

Inspired-by: Linus Torvalds 
Inspired-by: Oleg Nesterov 
Signed-off-by: "Eric W. Biederman" 
---
 include/linux/sched.h  | 5 -
 include/linux/sched/task.h | 1 +
 kernel/exit.c  | 7 ++-
 kernel/fork.c  | 7 +++
 4 files changed, 14 insertions(+), 6 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 9f51932bd543..99a4518b9b17 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1142,7 +1142,10 @@ struct task_struct {
 
struct tlbflush_unmap_batch tlb_ubc;
 
-   struct rcu_head rcu;
+   union {
+   refcount_t  rcu_users;
+   struct rcu_head rcu;
+   };
 
/* Cache last used pipe for splice(): */
struct pipe_inode_info  *splice_pipe;
diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index 0497091e40c1..4c44c37236b2 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -116,6 +116,7 @@ static inline void put_task_struct(struct task_struct *t)
 }
 
 struct task_struct *task_rcu_dereference(struct task_struct **ptask);
+void put_task_struct_rcu_user(struct task_struct *task);
 
 #ifdef CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT
 extern int arch_task_struct_size __read_mostly;
diff --git a/kernel/exit.c b/kernel/exit.c
index 5b4a5dcce8f8..2e259286f4e7 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -182,6 +182,11 @@ static void delayed_put_task_struct(struct rcu_head *rhp)
put_task_struct(tsk);
 }
 
+void put_task_struct_rcu_user(struct task_struct *task)
+{
+   if (refcount_dec_and_test(>rcu_users))
+   call_rcu(>rcu, delayed_put_task_struct);
+}
 
 void release_task(struct task_struct *p)
 {
@@ -222,7 +227,7 @@ void release_task(struct task_struct *p)
 
write_unlock_irq(_lock);
release_thread(p);
-   call_rcu(>rcu, delayed_put_task_struct);
+   put_task_struct_rcu_user(p);
 
p = leader;
if (unlikely(zap_leader))
diff --git a/kernel/fork.c b/kernel/fork.c
index 2852d0e76ea3..9f04741d5c70 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -900,10 +900,9 @@ static struct task_struct *dup_task_struct(struct 
task_struct *orig, int node)
if (orig->cpus_ptr == >cpus_mask)
tsk->cpus_ptr = >cpus_mask;
 
-   /*
-* One for us, one for whoever does the "release_task()" (usually
-* parent)
-*/
+   /* One for the user space visible state that goes away when reaped. */
+   refcount_set(>rcu_users, 1);
+   /* One for the rcu users, and one for the scheduler */
refcount_set(>usage, 2);
 #ifdef CONFIG_BLK_DEV_IO_TRACE
tsk->btrace_seq = 0;
-- 
2.21.0.dirty

[PATCH 0/3] task: Making tasks on the runqueue rcu protected

[Eric W. Biederman]

I have split this work into 3 simple patches, so the code is straight
forward to review and so that if any mistakes slip in it is easy to
bisect them.  In the process of review what it takes to remove
task_rcu_dereference I found yet another user of tasks on the
runqueue in rcu context; the rcuwait_event code.  That code only needs
it now unnecessary limits removed.

I have lightly tested it, and read through everything I can think of
that might be an issue.

Peter would this be a good fit for your scheduler tree?  If not I will
toss it onto a branch someplace and send it to Linus when the merge
window opens.

Oleg do you have any issues with this code?

Eric W. Biederman (3):
  task: Add a count of task rcu users
  task: RCU protect tasks on the runqueue
  task: Clean house now that tasks on the runqueue are rcu protected

 include/linux/rcuwait.h| 20 +++--
 include/linux/sched.h  |  5 +++-
 include/linux/sched/task.h |  2 +-
 kernel/exit.c  | 74 --
 kernel/fork.c  |  8 +++--
 kernel/sched/core.c|  7 +++--
 kernel/sched/fair.c|  2 +-
 kernel/sched/membarrier.c  |  4 +--
 8 files changed, 27 insertions(+), 95 deletions(-)

Eric

Re: [PATCH v4 1/5] vsock/virtio: limit the memory used per-socket

[Michael S. Tsirkin]

On Mon, Sep 02, 2019 at 11:57:23AM +0200, Stefano Garzarella wrote:
> > 
> > Assuming we miss nothing and buffers < 4K are broken,
> > I think we need to add this to the spec, possibly with
> > a feature bit to relax the requirement that all buffers
> > are at least 4k in size.
> > 
> 
> Okay, should I send a proposal to virtio-...@lists.oasis-open.org?

How about we also fix the bug for now?

-- 
MST

Re: [PATCH v4 2/5] vsock/virtio: reduce credit update messages

[Michael S. Tsirkin]

On Wed, Jul 17, 2019 at 01:30:27PM +0200, Stefano Garzarella wrote:
> In order to reduce the number of credit update messages,
> we send them only when the space available seen by the
> transmitter is less than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE.
> 
> Signed-off-by: Stefano Garzarella 
> ---
>  include/linux/virtio_vsock.h|  1 +
>  net/vmw_vsock/virtio_transport_common.c | 16 +---
>  2 files changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/include/linux/virtio_vsock.h b/include/linux/virtio_vsock.h
> index 7d973903f52e..49fc9d20bc43 100644
> --- a/include/linux/virtio_vsock.h
> +++ b/include/linux/virtio_vsock.h
> @@ -41,6 +41,7 @@ struct virtio_vsock_sock {
>  
>   /* Protected by rx_lock */
>   u32 fwd_cnt;
> + u32 last_fwd_cnt;
>   u32 rx_bytes;
>   struct list_head rx_queue;
>  };
> diff --git a/net/vmw_vsock/virtio_transport_common.c 
> b/net/vmw_vsock/virtio_transport_common.c
> index 095221f94786..a85559d4d974 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -211,6 +211,7 @@ static void virtio_transport_dec_rx_pkt(struct 
> virtio_vsock_sock *vvs,
>  void virtio_transport_inc_tx_pkt(struct virtio_vsock_sock *vvs, struct 
> virtio_vsock_pkt *pkt)
>  {
>   spin_lock_bh(>tx_lock);
> + vvs->last_fwd_cnt = vvs->fwd_cnt;
>   pkt->hdr.fwd_cnt = cpu_to_le32(vvs->fwd_cnt);
>   pkt->hdr.buf_alloc = cpu_to_le32(vvs->buf_alloc);
>   spin_unlock_bh(>tx_lock);
> @@ -261,6 +262,7 @@ virtio_transport_stream_do_dequeue(struct vsock_sock *vsk,
>   struct virtio_vsock_sock *vvs = vsk->trans;
>   struct virtio_vsock_pkt *pkt;
>   size_t bytes, total = 0;
> + u32 free_space;
>   int err = -EFAULT;
>  
>   spin_lock_bh(>rx_lock);
> @@ -291,11 +293,19 @@ virtio_transport_stream_do_dequeue(struct vsock_sock 
> *vsk,
>   virtio_transport_free_pkt(pkt);
>   }
>   }
> +
> + free_space = vvs->buf_alloc - (vvs->fwd_cnt - vvs->last_fwd_cnt);
> +
>   spin_unlock_bh(>rx_lock);
>  
> - /* Send a credit pkt to peer */
> - virtio_transport_send_credit_update(vsk, VIRTIO_VSOCK_TYPE_STREAM,
> - NULL);
> + /* We send a credit update only when the space available seen
> +  * by the transmitter is less than VIRTIO_VSOCK_MAX_PKT_BUF_SIZE

This is just repeating what code does though.
Please include the *reason* for the condition.
E.g. here's a better comment:

/* To reduce number of credit update messages,
 * don't update credits as long as lots of space is available.
 * Note: the limit chosen here is arbitrary. Setting the limit
 * too high causes extra messages. Too low causes transmitter
 * stalls. As stalls are in theory more expensive than extra
 * messages, we set the limit to a high value. TODO: experiment
 * with different values.
 */


> +  */
> + if (free_space < VIRTIO_VSOCK_MAX_PKT_BUF_SIZE) {
> + virtio_transport_send_credit_update(vsk,
> + VIRTIO_VSOCK_TYPE_STREAM,
> + NULL);
> + }
>  
>   return total;
>  
> -- 
> 2.20.1

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

[Stephen Rothwell]

Hi all,

After merging the regulator tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

ld: drivers/ata/ahci.o:(.opd+0x150): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/ata/ahci.o: in function `.regulator_bulk_set_supply_names':
ahci.c:(.text+0x1780): multiple definition of 
`.regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.text+0x2390): 
first defined here
ld: drivers/ata/libahci.o: in function `.regulator_bulk_set_supply_names':
(.text+0x84a0): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/ata/libahci.o:(.opd+0x5d0): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/ata/sata_mv.o:(.opd+0x690): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/ata/sata_mv.o: in function `.regulator_bulk_set_supply_names':
sata_mv.c:(.text+0xb9b0): multiple definition of 
`.regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.text+0x2390): 
first defined here
ld: drivers/usb/common/common.o: in function `.regulator_bulk_set_supply_names':
(.text+0x7d0): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/common/common.o:(.opd+0x120): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/core/usb.o: in function `.regulator_bulk_set_supply_names':
(.text+0x17d0): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/core/usb.o:(.opd+0x348): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/core/hub.o: in function `.regulator_bulk_set_supply_names':
(.text+0x2610): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/core/hub.o:(.opd+0x378): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/core/hcd.o: in function `.regulator_bulk_set_supply_names':
(.text+0x3020): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/core/hcd.o:(.opd+0x378): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/core/message.o: in function `.regulator_bulk_set_supply_names':
(.text+0x2350): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/core/message.o:(.opd+0x240): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/core/phy.o: in function `.regulator_bulk_set_supply_names':
(.text+0x700): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/core/phy.o:(.opd+0xc0): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/core/of.o: in function `.regulator_bulk_set_supply_names':
(.text+0x2f0): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/core/of.o:(.opd+0x48): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/phy/of.o: in function `.regulator_bulk_set_supply_names':
(.text+0x120): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/phy/of.o:(.opd+0x18): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/host/ehci-hcd.o: in function `.regulator_bulk_set_supply_names':
(.text+0x11830): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/host/ehci-hcd.o:(.opd+0x8d0): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/usb/host/ohci-hcd.o: in function `.regulator_bulk_set_supply_names':
(.text+0xe8d0): multiple definition of `.regulator_bulk_set_supply_names'; 
drivers/phy/phy-core.o:(.text+0x2390): first defined here
ld: drivers/usb/host/ohci-hcd.o:(.opd+0x570): multiple definition of 
`regulator_bulk_set_supply_names'; drivers/phy/phy-core.o:(.opd+0x3f0): first 
defined here
ld: drivers/of/platform.o: in function `.regulator_bulk_set_supply_names':

"fs/namei.c: keep track of nd->root refcount status" causes boot panic

[Qian Cai]

The linux-next commit "fs/namei.c: keep track of nd->root refcount status” [1] 
causes boot panic on all
architectures here on today’s linux-next (0902). Reverted it will fix the issue.

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=e013ec23b8231cf7f95605cbb0e47aa0e3d047a4

All config are here: https://github.com/cailca/linux-mm

[  104.088693][T1] Run /init as init process
[  104.155068][T1] 
==
[  104.163000][T1] BUG: KASAN: invalid-access in dput+0x94/0x8d0
[  104.169095][T1] Read of size 4 at addr  by task systemd/1
[  104.176227][T1] 
[  104.178416][T1] CPU: 166 PID: 1 Comm: systemd Not tainted 
5.3.0-rc6-next-20190902 #2
[  104.186504][T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB  
   , BIOS L50_5.13_1.11 06/18/2019
[  104.196935][T1] Call trace:
[  104.200091][T1]  dump_backtrace+0x0/0x264
[  104.204447][T1]  show_stack+0x20/0x2c
[  104.208460][T1]  dump_stack+0xb0/0x104
[  104.212558][T1]  __kasan_report+0x1fc/0x294
[  104.217088][T1]  kasan_report+0x10/0x18
[  104.221271][T1]  __hwasan_load4_noabort+0x84/0x8c
[  104.226320][T1]  dput+0x94/0x8d0
[  104.229902][T1]  path_put+0x24/0x40
[  104.233739][T1]  terminate_walk+0x98/0x124
[  104.238182][T1]  path_lookupat+0x1a8/0x3f8
[  104.242624][T1]  filename_lookup+0x84/0x128
[  104.247154][T1]  user_path_at_empty+0x54/0x68
[  104.251869][T1]  __arm64_sys_name_to_handle_at+0xd4/0x63c
[  104.257625][T1]  el0_svc_handler+0x16c/0x234
[  104.262240][T1]  el0_svc+0x8/0xc
[  104.265814][T1] 
==
[  104.273726][T1] Disabling lock debugging due to kernel taint
[  104.279758][T1] Unable to handle kernel paging request at virtual 
address 
[  104.288378][T1] Mem abort info:
[  104.291861][T1]   ESR = 0x9604
[  104.295619][T1]   EC = 0x25: DABT (current EL), IL = 32 bits
[  104.301619][T1]   SET = 0, FnV = 0
[  104.305375][T1]   EA = 0, S1PTW = 0
[  104.309203][T1] Data abort info:
[  104.312773][T1]   ISV = 0, ISS = 0x0004
[  104.317310][T1]   CM = 0, WnR = 0
[  104.320968][T1] [] address between user and kernel 
address ranges
[  104.328806][T1] Internal error: Oops: 9604 [#1] SMP
[  104.334375][T1] Modules linked in:
[  104.338127][T1] CPU: 166 PID: 1 Comm: systemd Tainted: GB
 5.3.0-rc6-next-20190902 #2
[  104.347601][T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB  
   , BIOS L50_5.13_1.11 06/18/2019
[  104.358033][T1] pstate: 6049 (nZCv daif +PAN -UAO)
[  104.363514][T1] pc : dput+0x94/0x8d0
[  104.367433][T1] lr : dput+0x94/0x8d0
[  104.371349][T1] sp : 29ff008b8054fb40
[  104.375353][T1] x29: 29ff008b8054fba0 x28: faff008b8052a0c0 
[  104.381357][T1] x27: 00080040 x26: 00080060 
[  104.387361][T1] x25: 0001 x24: faff008b8052a0c0 
[  104.393365][T1] x23: 0001 x22: 9000129e5cb8 
[  104.399368][T1] x21: 900010f4cb4a x20: faff008b8052a0d8 
[  104.405371][T1] x19:  x18:  
[  104.411374][T1] x17:  x16:  
[  104.417377][T1] x15:  x14: 4c20534f4942202c 
[  104.423380][T1] x13: 2020202020202020 x12:  
[  104.429383][T1] x11: 00fa x10: 8008b8052a0e 
[  104.435387][T1] x9 : 828cac3cb2455600 x8 : 828cac3cb2455600 
[  104.441389][T1] x7 :  x6 : 9000101dcf08 
[  104.447392][T1] x5 :  x4 : 0080 
[  104.453395][T1] x3 : 9000101d0e8c x2 : 0001 
[  104.459398][T1] x1 : 0001 x0 : faff008b8052a0d8 
[  104.465402][T1] Call trace:
[  104.468541][T1]  dput+0x94/0x8d0
[  104.472112][T1]  path_put+0x24/0x40
[  104.475945][T1]  terminate_walk+0x98/0x124
[  104.480385][T1]  path_lookupat+0x1a8/0x3f8
[  104.484826][T1]  filename_lookup+0x84/0x128
[  104.489353][T1]  user_path_at_empty+0x54/0x68
[  104.494055][T1]  __arm64_sys_name_to_handle_at+0xd4/0x63c
[  104.499798][T1]  el0_svc_handler+0x16c/0x234
[  104.504411][T1]  el0_svc+0x8/0xc
[  104.507989][T1] Code: aa1603e0 9400202a aa1303e0 97fdfb5c (39400268) 
[  104.515005][T1] ---[ end trace 8f0e764e24e4db67 ]---
[  104.520314][T1] Kernel panic - not syncing: Fatal exception
[  104.526386][T1] SMP: stopping secondary CPUs
[  104.531154][T1] Kernel Offset: disabled
[  104.535334][T1] CPU features: 0x0002,2c18
[  104.540032][T1] Memory Limit: none
[  104.543936][T1] ---[ end Kernel panic - not syncing: Fatal exception ]—



[   18.850684][T1] Run /init as init process
[   18.865679][T1] Kernel attempted to acc

[PATCH v3 1/2] uacce: Add documents for uacce

[Zhangfei Gao]

From: Kenneth Lee 

Uacce (Unified/User-space-access-intended Accelerator Framework) is
a kernel module targets to provide Shared Virtual Addressing (SVA)
between the accelerator and process.

This patch add document to explain how it works.

Signed-off-by: Kenneth Lee 
Signed-off-by: Zaibo Xu 
Signed-off-by: Zhou Wang 
Signed-off-by: Zhangfei Gao 
---
 Documentation/misc-devices/uacce.rst | 309 +++
 1 file changed, 309 insertions(+)
 create mode 100644 Documentation/misc-devices/uacce.rst

diff --git a/Documentation/misc-devices/uacce.rst 
b/Documentation/misc-devices/uacce.rst
new file mode 100644
index 000..211f796
--- /dev/null
+++ b/Documentation/misc-devices/uacce.rst
@@ -0,0 +1,309 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Introduction of Uacce
+=
+
+Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
+provide Shared Virtual Addressing (SVA) between accelerators and processes.
+So accelerator can access any data structure of the main cpu.
+This differs from the data sharing between cpu and io device, which share
+data content rather than address.
+Because of the unified address, hardware and user space of process can
+share the same virtual address in the communication.
+Uacce takes the hardware accelerator as a heterogeneous processor, while
+IOMMU share the same CPU page tables and as a result the same translation
+from va to pa.
+
+__   __
+   |  | |  |
+   |  User application (CPU)  | |   Hardware Accelerator   |
+   |__| |__|
+
+| |
+| va  | va
+V V
+ ____
+|  |  |  |
+|   MMU|  |  IOMMU   |
+|__|  |__|
+| |
+| |
+V pa  V pa
+___
+   |   |
+   |  Memory   |
+   |___|
+
+
+
+Architecture
+
+
+Uacce is the kernel module, taking charge of iommu and address sharing.
+The user drivers and libraries are called WarpDrive.
+
+A virtual concept, queue, is used for the communication. It provides a
+FIFO-like interface. And it maintains a unified address space between the
+application and all involved hardware.
+
+ ___  

+|   |   user API | 
   |
+| WarpDrive library | >  |  user 
driver   |
+|___|
||
+ ||
+ ||
+ | queue fd   |
+ ||
+ ||
+ v|
+ ___ _|
+|   |   | |   | 
mmap memory
+| Other framework   |   |  uacce  |   | 
r/w interface
+| crypto/nic/others |   |_|   |
+|___| |
+ |   ||
+ | register  | register   |
+ |   ||
+ |   ||
+ |_   __  |
+ |   | | |  | |
+  -  |  Device Driver  | |  IOMMU   | |
+ |_| |__| |
+ ||
+ |V
+ |
___
+ 

[PATCH v3 2/2] uacce: add uacce driver

[Zhangfei Gao]

From: Kenneth Lee 

Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device, which share
data content rather than address.
Since unified address, hardware and user space of process can share the
same virtual address in the communication.

Uacce create a chrdev for every registration, the queue is allocated to
the process when the chrdev is opened. Then the process can access the
hardware resource by interact with the queue file. By mmap the queue
file space to user space, the process can directly put requests to the
hardware without syscall to the kernel space.

Signed-off-by: Kenneth Lee 
Signed-off-by: Zaibo Xu 
Signed-off-by: Zhou Wang 
Signed-off-by: Zhangfei Gao 
---
 Documentation/ABI/testing/sysfs-driver-uacce |   47 ++
 drivers/misc/Kconfig |1 +
 drivers/misc/Makefile|1 +
 drivers/misc/uacce/Kconfig   |   13 +
 drivers/misc/uacce/Makefile  |2 +
 drivers/misc/uacce/uacce.c   | 1096 ++
 include/linux/uacce.h|  172 
 include/uapi/misc/uacce.h|   39 +
 8 files changed, 1371 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-uacce
 create mode 100644 drivers/misc/uacce/Kconfig
 create mode 100644 drivers/misc/uacce/Makefile
 create mode 100644 drivers/misc/uacce/uacce.c
 create mode 100644 include/linux/uacce.h
 create mode 100644 include/uapi/misc/uacce.h

diff --git a/Documentation/ABI/testing/sysfs-driver-uacce 
b/Documentation/ABI/testing/sysfs-driver-uacce
new file mode 100644
index 000..ee0a66e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-uacce
@@ -0,0 +1,47 @@
+What:   /sys/class/uacce/hisi_zip-/id
+Date:   Sep 2019
+KernelVersion:  5.3
+Contact:linux-accelerat...@lists.ozlabs.org
+Description:Id of the device.
+
+What:   /sys/class/uacce/hisi_zip-/api
+Date:   Sep 2019
+KernelVersion:  5.3
+Contact:linux-accelerat...@lists.ozlabs.org
+Description:Api of the device, used by application to match the correct 
driver
+
+What:   /sys/class/uacce/hisi_zip-/flags
+Date:   Sep 2019
+KernelVersion:  5.3
+Contact:linux-accelerat...@lists.ozlabs.org
+Description:Attributes of the device, see UACCE_DEV_xxx flag defined in 
uacce.h
+
+What:   /sys/class/uacce/hisi_zip-/available_instances
+Date:   Sep 2019
+KernelVersion:  5.3
+Contact:linux-accelerat...@lists.ozlabs.org
+Description:Available instances left of the device
+
+What:   /sys/class/uacce/hisi_zip-/algorithms
+Date:   Sep 2019
+KernelVersion:  5.3
+Contact:linux-accelerat...@lists.ozlabs.org
+Description:Algorithms supported by this accelerator
+
+What:   /sys/class/uacce/hisi_zip-/qfrs_offset
+Date:   Sep 2019
+KernelVersion:  5.3
+Contact:linux-accelerat...@lists.ozlabs.org
+Description:Page offsets of each queue file regions
+
+What:   /sys/class/uacce/hisi_zip-/numa_distance
+Date:   Sep 2019
+KernelVersion:  5.3
+Contact:linux-accelerat...@lists.ozlabs.org
+Description:Distance of device node to cpu node
+
+What:   /sys/class/uacce/hisi_zip-/node_id
+Date:   Sep 2019
+KernelVersion:  5.3
+Contact:linux-accelerat...@lists.ozlabs.org
+Description:Id of the numa node
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6abfc8e..8073eb8 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -502,4 +502,5 @@ source "drivers/misc/cxl/Kconfig"
 source "drivers/misc/ocxl/Kconfig"
 source "drivers/misc/cardreader/Kconfig"
 source "drivers/misc/habanalabs/Kconfig"
+source "drivers/misc/uacce/Kconfig"
 endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index abd8ae2..93a131b 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -58,4 +58,5 @@ obj-$(CONFIG_OCXL)+= ocxl/
 obj-y  += cardreader/
 obj-$(CONFIG_PVPANIC)  += pvpanic.o
 obj-$(CONFIG_HABANA_AI)+= habanalabs/
+obj-$(CONFIG_UACCE)+= uacce/
 obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
diff --git a/drivers/misc/uacce/Kconfig b/drivers/misc/uacce/Kconfig
new file mode 100644
index 000..e854354
--- /dev/null
+++ b/drivers/misc/uacce/Kconfig
@@ -0,0 +1,13 @@
+config UACCE
+   tristate "Accelerator Framework for User Land"
+   depends on IOMMU_API
+   help
+ UACCE provides interface for the user process to access the hardware
+ without interaction with the kernel space in data path.
+
+ The user-space interface is described in
+ include/uapi/misc/uacce.h
+
+ See 

[PATCH v3 0/2] Add uacce module for Accelerator

[Zhangfei Gao]

Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
provide Shared Virtual Addressing (SVA) between accelerators and processes.
So accelerator can access any data structure of the main cpu.
This differs from the data sharing between cpu and io device, which share
data content rather than address.
Because of unified address, hardware and user space of process can share
the same virtual address in the communication.

Uacce is intended to be used with Jean Philippe Brucker's SVA
patchset[1], which enables IO side page fault and PASID support. 
We have keep verifying with Jean's sva/current [2]
We also keep verifying with Eric's SMMUv3 Nested Stage patch [3]

This series and related zip & qm driver
https://github.com/Linaro/linux-kernel-warpdrive/tree/5.3-rc1-warpdrive-v3

The library and user application:
https://github.com/Linaro/warpdrive/tree/wdprd-v1-upstream

References:
[1] http://jpbrucker.net/sva/
[2] 
http://www.linux-arm.org/git?p=linux-jpb.git;a=shortlog;h=refs/heads/sva/current
[3] https://github.com/eauger/linux/tree/v5.3.0-rc0-2stage-v9

Change History:
v3:
Recommended by Greg, use sturct uacce_device instead of struct uacce,
and use struct *cdev in struct uacce_device, as a result, 
cdev can be released by itself when refcount decreased to 0.
So the two structures are decoupled and self-maintained by themsleves.
Also add dev.release for put_device.

v2:
Address comments from Greg and Jonathan
Modify interface uacce_register
Drop noiommu mode first

v1:
1. Rebase to 5.3-rc1
2. Build on iommu interface
3. Verifying with Jean's sva and Eric's nested mode iommu.
4. User library has developed a lot: support zlib, openssl etc.
5. Move to misc first

RFC3:
https://lkml.org/lkml/2018/11/12/1951

RFC2:
https://lwn.net/Articles/763990/


Background of why Uacce:
Von Neumann processor is not good at general data manipulation.
It is designed for control-bound rather than data-bound application.
The latter need less control path facility and more/specific ALUs.
So there are more and more heterogeneous processors, such as
encryption/decryption accelerators, TPUs, or
EDGE (Explicated Data Graph Execution) processors, introduced to gain
better performance or power efficiency for particular applications
these days.

There are generally two ways to make use of these heterogeneous processors:

The first is to make them co-processors, just like FPU.
This is good for some application but it has its own cons:
It changes the ISA set permanently.
You must save all state elements when the process is switched out.
But most data-bound processors have a huge set of state elements.
It makes the kernel scheduler more complex.

The second is Accelerator.
It is taken as a IO device from the CPU's point of view
(but it need not to be physically). The process, running on CPU,
hold a context of the accelerator and send instructions to it as if
it calls a function or thread running with FPU.
The context is bound with the processor itself.
So the state elements remain in the hardware context until
the context is released.

We believe this is the core feature of an "Accelerator" vs. Co-processor
or other heterogeneous processors.

The intention of Uacce is to provide the basic facility to backup
this scenario. Its first step is to make sure the accelerator and process
can share the same address space. So the accelerator ISA can directly
address any data structure of the main CPU.
This differs from the data sharing between CPU and IO device,
which share data content rather than address.
So it is different comparing to the other DMA libraries.

In the future, we may add more facility to support linking accelerator
library to the main application, or managing the accelerator context as
special thread.
But no matter how, this can be a solid start point for new processor
to be used as an "accelerator" as this is the essential requirement.


Kenneth Lee (2):
  uacce: Add documents for uacce
  uacce: add uacce driver

 Documentation/ABI/testing/sysfs-driver-uacce |   47 ++
 Documentation/misc-devices/uacce.rst |  309 
 drivers/misc/Kconfig |1 +
 drivers/misc/Makefile|1 +
 drivers/misc/uacce/Kconfig   |   13 +
 drivers/misc/uacce/Makefile  |2 +
 drivers/misc/uacce/uacce.c   | 1094 ++
 include/linux/uacce.h|  172 
 include/uapi/misc/uacce.h|   39 +
 9 files changed, 1678 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-driver-uacce
 create mode 100644 Documentation/misc-devices/uacce.rst
 create mode 100644 drivers/misc/uacce/Kconfig
 create mode 100644 drivers/misc/uacce/Makefile
 create mode 100644 drivers/misc/uacce/uacce.c
 create mode 100644 include/linux/uacce.h
 create mode 100644 include/uapi/misc/uacce.h

-- 
2.7.4

RE: [PATCH v2 5/6] mdev: Update sysfs documentation

[Parav Pandit]

> -Original Message-
> From: Cornelia Huck 
> Sent: Monday, September 2, 2019 8:07 PM
> To: Parav Pandit 
> Cc: alex.william...@redhat.com; Jiri Pirko ;
> kwankh...@nvidia.com; da...@davemloft.net; k...@vger.kernel.org;
> linux-kernel@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH v2 5/6] mdev: Update sysfs documentation
> 
> On Fri, 30 Aug 2019 13:10:17 +
> Parav Pandit  wrote:
> 
> > > -Original Message-
> > > From: Cornelia Huck 
> > > Sent: Friday, August 30, 2019 6:19 PM
> > > To: Parav Pandit 
> > > Cc: alex.william...@redhat.com; Jiri Pirko ;
> > > kwankh...@nvidia.com; da...@davemloft.net; k...@vger.kernel.org;
> > > linux- ker...@vger.kernel.org; net...@vger.kernel.org
> > > Subject: Re: [PATCH v2 5/6] mdev: Update sysfs documentation
> > >
> > > On Thu, 29 Aug 2019 06:19:03 -0500
> > > Parav Pandit  wrote:
> > >
> > > > Updated documentation for optional read only sysfs attribute.
> > >
> > > I'd probably merge this into the patch introducing the attribute.
> > >
> > Ok. I will spin v3.
> >
> > > >
> > > > Signed-off-by: Parav Pandit 
> > > > ---
> > > >  Documentation/driver-api/vfio-mediated-device.rst | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> > > > b/Documentation/driver-api/vfio-mediated-device.rst
> > > > index 25eb7d5b834b..0ab03d3f5629 100644
> > > > --- a/Documentation/driver-api/vfio-mediated-device.rst
> > > > +++ b/Documentation/driver-api/vfio-mediated-device.rst
> > > > @@ -270,6 +270,7 @@ Directories and Files Under the sysfs for Each
> > > > mdev
> > > Device
> > > >   |--- remove
> > > >   |--- mdev_type {link to its type}
> > > >   |--- vendor-specific-attributes [optional]
> > > > + |--- alias [optional]
> > >
> > > "optional" implies "not always present" to me, not "might return a
> > > read error if not available". Don't know if there's a better way to
> > > tag this? Or make it really optional? :)
> >
> > May be write it as,
> >
> > alias [ optional when requested by parent ]
> 
> I'm not sure what 'optional when requested' is supposed to mean...
> maybe something like 'content optional' or so?
> 
> >
> > >
> > > >
> > > >  * remove (write only)
> > > >
> > > > @@ -281,6 +282,10 @@ Example::
> > > >
> > > > # echo 1 > /sys/bus/mdev/devices/$mdev_UUID/remove
> > > >
> > > > +* alias (read only)
> > > > +Whenever a parent requested to generate an alias, each mdev is
> > > > +assigned a unique alias by the mdev core. This file shows the
> > > > +alias of the
> > > mdev device.
> > >
> > > It's not really the parent, but the vendor driver requesting this,
> > > right? Also,
> > At mdev level, it only knows parent->ops structure, whether parent is
> registered by vendor driver or something else.
> 
> Who else is supposed to create the mdev device?
If you nitpick the language what is the vendor id for sample mttty driver?
Mtty is not a 'vendor driver' per say.

> 
> >
> > > "each mdev" is a bit ambiguous,
> > It is in context of the parent. Sentence is not starting with "each mdev".
> > But may be more verbosely written as,
> >
> > Whenever a parent requested to generate an alias, Each mdev device of
> > such parent is assigned unique alias by the mdev core. This file shows the
> alias of the mdev device.
> 
> I'd really leave the parent out of this: this seems more like an
> implementation detail. It's more that alias may either contain an alias, or
> return a read error if no alias has been generated. Who requested the alias
> to be generated is probably not really of interest to the userspace reader.
>

The documentation is for user and developer both.
It is not the right claim that 'only user care' for this.
Otherwise all the .ko diagrams and API description etc doesn't make any sense 
to the user.

For user it doesn't matter whether alias length is provided by 'vendor driver' 
or 'registered parent'.
This note on who should specify the alias length is mainly for the developers.
 
> >
> > > created via that driver. Lastly, if we stick with the "returns an
> > > error if not implemented" approach, that should also be mentioned
> here.
> > Ok. Will spin v3 to describe it.
> >
> > >
> > > > +
> > > >  Mediated device Hot plug
> > > >  
> > > >
> >

RE: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias

[Parav Pandit]

> -Original Message-
> From: Cornelia Huck 
> Sent: Monday, September 2, 2019 8:16 PM
> To: Parav Pandit 
> Cc: alex.william...@redhat.com; Jiri Pirko ;
> kwankh...@nvidia.com; da...@davemloft.net; k...@vger.kernel.org;
> linux-kernel@vger.kernel.org; net...@vger.kernel.org
> Subject: Re: [PATCH v2 1/6] mdev: Introduce sha1 based mdev alias
> 
> On Fri, 30 Aug 2019 15:45:13 +
> Parav Pandit  wrote:
> 
> > > > > > > This detour via the local variable looks weird to me. Can
> > > > > > > you either create the alias directly in the mdev (would need
> > > > > > > to happen later in the function, but I'm not sure why you
> > > > > > > generate the alias before checking for duplicates anyway), or do
> an explicit copy?
> > > > > > Alias duplicate check is done after generating it, because
> > > > > > duplicate alias are
> > > > > not allowed.
> > > > > > The probability of collision is rare.
> > > > > > So it is speculatively generated without hold the lock,
> > > > > > because there is no
> > > > > need to hold the lock.
> > > > > > It is compared along with guid while mutex lock is held in single
> loop.
> > > > > > And if it is duplicate, there is no need to allocate mdev.
> > > > > >
> > > > > > It will be sub optimal to run through the mdev list 2nd time
> > > > > > after mdev
> > > > > creation and after generating alias for duplicate check.
> > > > >
> > > > > Ok, but what about copying it? I find this "set local variable
> > > > > to NULL after ownership is transferred" pattern a bit unintuitive.
> > > > > Copying it to the mdev (and then unconditionally freeing it)
> > > > > looks more
> > > obvious to me.
> > > > Its not unconditionally freed.
> > >
> > > That's not what I have been saying :(
> > >
> > Ah I see. You want to allocate alias memory twice; once inside mdev device
> and another one in _create() function.
> > _create() one you want to free unconditionally.
> >
> > Well, passing pointer is fine.
> 
> It's not that it doesn't work, but it feels fragile due to its 
> non-obviousness.
And its well commented as Alex asked.

> 
> > mdev_register_device() has similar little tricky pattern that makes parent =
> NULL on __find_parent_device() finds duplicate one.
> 
> I don't think that the two are comparable.
>
They are very similar.
Why parent should be marked null otherwise.

 > >
> > Ownership transfer is more straight forward code.
> 
> I have to disagree here.
>
Ok. It is better than allocating memory twice. So I prefer to stick to this 
method.
 
> >
> > It is similar to device_initialize(), device init sequence code, where once
> device_initialize is done, freeing the device memory will be left to the
> put_device(), we don't call kfree() on mdev device.
> 
> This does not really look similar to me: devices are refcounted structures,
> while strings aren't; you transfer a local pointer to a refcounted structure
> and then discard the local reference.

RE: [PATCH v3 01/11] PCI: designware-ep: Add multiple PFs support for DWC

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月3日 0:26
> To: Xiaowei Bao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> gre...@linuxfoundation.org; Z.q. Hou ;
> a...@arndb.de
> Subject: Re: [PATCH v3 01/11] PCI: designware-ep: Add multiple PFs support
> for DWC
> 
> On Mon, Sep 02, 2019 at 11:17:06AM +0800, Xiaowei Bao wrote:
> > Add multiple PFs support for DWC, different PF have different config
> > space we use pf-offset property which get from the DTS to access the
> > different pF
> 
> This needs to be updated as this no longer comes from the DT.

Yes, thanks

Thanks
Xiaowei

> 
> > config space.
> >
> > Signed-off-by: Xiaowei Bao 
> 
> 
> We're assuming:
> 
>  - The offset address (func_offset) between PF's in the memory map can be
>different between different DWC implementations. And also that it's
>possible for DWC implementations to address PFs without using an offset.
> 
>  - The current approach is preferable to adding DWC EP driver callbacks
>for writing to the EP config space (e.g. a variant of dw_pcie_writew_dbi
>that takes a func number).

Even if use the a variant of dw_pcie_writew_dbi, we also need a offset value 
form
different platform, due to the different platform may be have different 
implement
about this, so I am not sure how to implement the variant of dw_pcie_writew_dbi?
  
> 
> I'm keen to hear feedback from Jingoo/Gustavo on this.

OK, expect the feedback.

Thanks 
Xiaowei

> 
> Thanks,
> 
> Andrew Murray
> 
> > ---
> > v2:
> >  - Remove duplicate redundant code.
> >  - Reimplement the PF config space access way.
> > v3:
> >  - Integrate duplicate code for func_select.
> >  - Move PCIE_ATU_FUNC_NUM(pf) (pf << 20) to ((pf) << 20).
> >  - Add the comments for func_conf_select function.
> >
> >  drivers/pci/controller/dwc/pcie-designware-ep.c | 123
> 
> >  drivers/pci/controller/dwc/pcie-designware.c|  59 
> >  drivers/pci/controller/dwc/pcie-designware.h|  18 +++-
> >  3 files changed, 142 insertions(+), 58 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index 65f4792..eb851c2 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -19,12 +19,26 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > pci_epc_linkup(epc);
> >  }
> >
> > -static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno
> bar,
> > -  int flags)
> > +static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8
> > +func_no) {
> > +   unsigned int func_offset = 0;
> > +
> > +   if (ep->ops->func_conf_select)
> > +   func_offset = ep->ops->func_conf_select(ep, func_no);
> > +
> > +   return func_offset;
> > +}
> > +
> > +static void __dw_pcie_ep_reset_bar(struct dw_pcie *pci, u8 func_no,
> > +  enum pci_barno bar, int flags)
> >  {
> > u32 reg;
> > +   unsigned int func_offset = 0;
> > +   struct dw_pcie_ep *ep = >ep;
> > +
> > +   func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > -   reg = PCI_BASE_ADDRESS_0 + (4 * bar);
> > +   reg = func_offset + PCI_BASE_ADDRESS_0 + (4 * bar);
> > dw_pcie_dbi_ro_wr_en(pci);
> > dw_pcie_writel_dbi2(pci, reg, 0x0);
> > dw_pcie_writel_dbi(pci, reg, 0x0);
> > @@ -37,7 +51,12 @@ static void __dw_pcie_ep_reset_bar(struct dw_pcie
> > *pci, enum pci_barno bar,
> >
> >  void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)  {
> > -   __dw_pcie_ep_reset_bar(pci, bar, 0);
> > +   u8 func_no, funcs;
> > +
> > +   funcs = pci->ep.epc->max_functions;
> > +
> > +   for (func_no = 0; func_no < funcs; func_no++)
> > +   __dw_pcie_ep_reset_bar(pci, func_no, bar, 0);
> >  }
> >
> >  static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> > @@ -45,28 +64,31 @@ static int dw_pcie_ep_write_header(struct pci_epc
> > *epc, u8 func_no,  {
> > struct dw_pcie_ep *ep = epc_get_drvdata(epc);
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +   unsigned int func_offset = 0;
> > +
> > +   func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > dw_pcie_dbi_ro_wr_en(pci);
> > -   dw_pcie_writew_dbi(pci, PCI_VENDOR_ID, hdr->vendorid);
> > -   dw_pcie_writew_dbi(pci, PCI_DEVICE_ID, hdr->deviceid);
> > -   dw_pcie_writeb_dbi(pci, PCI_REVISION_ID, hdr->revid);
> > -   dw_pcie_writeb_dbi(pci, PCI_CLASS_PROG, hdr->progif_code);
> > -   dw_pcie_writew_dbi(pci, PCI_CLASS_DEVICE,
> > +   dw_pcie_writew_dbi(pci, func_offset + PCI_VENDOR_ID, hdr->vendorid);
> > +   

[PATCH] arm64: dts: lx2160a: add tmu device node

[Yuantian Tang]

Add the TMU (Thermal Monitoring Unit) device node to enable
TMU feature.

Signed-off-by: Yuantian Tang 
---
 .../arm64/boot/dts/freescale/fsl-lx2160a.dtsi | 108 +++---
 1 file changed, 92 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
index 39d497df769e..e70ddd01cd84 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi
@@ -6,6 +6,7 @@
 
 #include 
 #include 
+#include 
 
 /memreserve/ 0x8000 0x0001;
 
@@ -24,7 +25,7 @@
#size-cells = <0>;
 
// 8 clusters having 2 Cortex-A72 cores each
-   cpu@0 {
+   cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -38,9 +39,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@1 {
+   cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -54,9 +56,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@100 {
+   cpu100: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -70,9 +73,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@101 {
+   cpu101: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -86,9 +90,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@200 {
+   cpu200: cpu@200 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -102,9 +107,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@201 {
+   cpu201: cpu@201 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -118,9 +124,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@300 {
+   cpu300: cpu@300 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -134,9 +141,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@301 {
+   cpu301: cpu@301 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -150,9 +158,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@400 {
+   cpu400: cpu@400 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -166,9 +175,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
cpu-idle-states = <_pw20>;
+   #cooling-cells = <2>;
};
 
-   cpu@401 {
+   cpu401: cpu@401 {
device_type = "cpu";
compatible = "arm,cortex-a72";
enable-method = "psci";
@@ -182,9 +192,10 @@
i-cache-sets = <192>;
next-level-cache = <_l2>;
   

[PATCH v2 0/7] Nvidia Arm SMMUv2 Implementation

[Krishna Reddy]

Changes in v2:
- Prepare arm_smu_flush_ops for override.
- Remove NVIDIA_SMMUv2 and use ARM_SMMUv2 model as T194 SMMU hasn't modified 
ARM MMU-500.
- Add T194 specific compatible string - "nvidia,tegra194-smmu"
- Remove tlb_sync hook added in v1 and Override arm_smmu_flush_ops->tlb_sync() 
from implementation.
- Register implementation specific context/global fault hooks directly for irq 
handling.
- Update global/context interrupt list in DT and releant fault handling code in 
arm-smmu-nvidia.c.
- Implement reset hook in arm-smmu-nvidia.c to clear irq status and sync tlb.

v1 - https://lkml.org/lkml/2019/8/29/1588

Krishna Reddy (7):
  iommu/arm-smmu: prepare arm_smmu_flush_ops for override
  iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
  dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
  iommu/arm-smmu: Add global/context fault implementation hooks
  arm64: tegra: Add Memory controller DT node on T194
  arm64: tegra: Add DT node for T194 SMMU
  arm64: tegra: enable SMMU for SDHCI and EQOS on T194

 .../devicetree/bindings/iommu/arm,smmu.txt |   4 +
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi |   4 +
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   |  88 +++
 drivers/iommu/Makefile |   2 +-
 drivers/iommu/arm-smmu-impl.c  |   3 +
 drivers/iommu/arm-smmu-nvidia.c| 287 +
 drivers/iommu/arm-smmu.c   |  27 +-
 drivers/iommu/arm-smmu.h   |   8 +-
 9 files changed, 413 insertions(+), 12 deletions(-)
 create mode 100644 drivers/iommu/arm-smmu-nvidia.c

-- 
2.1.4

[PATCH v2 3/7] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU

[Krishna Reddy]

Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.

Signed-off-by: Krishna Reddy 
---
 Documentation/devicetree/bindings/iommu/arm,smmu.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 3133f3b..1d72fac 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -31,6 +31,10 @@ conditions.
   as below, SoC-specific compatibles:
   "qcom,sdm845-smmu-500", "arm,mmu-500"
 
+  NVIDIA SoCs that use more than one ARM MMU-500 together
+  needs following SoC-specific compatibles along with 
"arm,mmu-500":
+  "nvidia,tegra194-smmu"
+
 - reg   : Base address and size of the SMMU.
 
 - #global-interrupts : The number of global interrupts exposed by the
-- 
2.1.4

RE: [PATCH][usb-next] usb: cdns3: fix missing assignment of ret before error check on ret

[Pawel Laszczak]

Hi Colin

>Hi Colin
>
>>
>>From: Colin Ian King 
>>
>>Currently the check on a non-zero return code in ret is false because
>>ret has been initialized to zero.  I believe that ret should be assigned
>>to the return from the call to readl_poll_timeout_atomic before the
>>check on ret.  Since ret is being re-assinged the original initialization
>>of ret to zero can be removed.
>
>Thanks you for letting me know.
>Fortunately that's not a critical bug and has no impact for driver.
>I will correct it.
>
>Cheers
>Pawell
>
>>
>>Addresses-Coverity: ("'Constant' variable guards dead code")
>>Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver")
>>Signed-off-by: Colin Ian King 
>>---
>> drivers/usb/cdns3/gadget.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>>diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
>>index 3094ad65ffc9..0eb3022838d6 100644
>>--- a/drivers/usb/cdns3/gadget.c
>>+++ b/drivers/usb/cdns3/gadget.c
>>@@ -2154,7 +2154,7 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint 
>>*priv_ep)
>> {
>>  struct cdns3_device *priv_dev = priv_ep->cdns3_dev;
>>  struct usb_request *request;
>>- int ret = 0;
>>+ int ret;
>>  int val;
>>
>>  trace_cdns3_halt(priv_ep, 0, 0);
>>@@ -2162,8 +2162,8 @@ int __cdns3_gadget_ep_clear_halt(struct cdns3_endpoint 
>>*priv_ep)
>>  writel(EP_CMD_CSTALL | EP_CMD_EPRST, _dev->regs->ep_cmd);
>>
>>  /* wait for EPRST cleared */
>>- readl_poll_timeout_atomic(_dev->regs->ep_cmd, val,
>>-   !(val & EP_CMD_EPRST), 1, 100);
>>+ ret = readl_poll_timeout_atomic(_dev->regs->ep_cmd, val,
>>+ !(val & EP_CMD_EPRST), 1, 100);
>>  if (ret)
>>  return -EINVAL;

What about such condition:
if (unlikely(ret)) {
dev_err(priv_dev->dev, "Failed to clear halt %s (timeout).",
priv_ep->name);
return ret;
}

Invalid return value in this place is rather impossible case. If it occurs 
then it should be treated as critical error, so it could be good to have 
information about it.

Cheers,
Pawel

>>
>
>>--
>>2.20.1

Re: [PATCH 1/4] softirq: implement IRQ flood detection mechanism

[Ming Lei]

On Wed, Aug 28, 2019 at 04:07:19PM +0200, Thomas Gleixner wrote:
> On Wed, 28 Aug 2019, Ming Lei wrote:
> > On Wed, Aug 28, 2019 at 01:23:06PM +0200, Thomas Gleixner wrote:
> > > On Wed, 28 Aug 2019, Ming Lei wrote:
> > > > On Wed, Aug 28, 2019 at 01:09:44AM +0200, Thomas Gleixner wrote:
> > > > > > > Also how is that supposed to work when sched_clock is jiffies 
> > > > > > > based?
> > > > > > 
> > > > > > Good catch, looks ktime_get_ns() is needed.
> > > > > 
> > > > > And what is ktime_get_ns() returning when the only available 
> > > > > clocksource is
> > > > > jiffies?
> > > > 
> > > > IMO, it isn't one issue. If the only clocksource is jiffies, we needn't 
> > > > to
> > > > expect high IO performance. Then it is fine to always handle the irq in
> > > > interrupt context or thread context.
> > > > 
> > > > However, if it can be recognized runtime, irq_flood_detected() can
> > > > always return true or false.
> > > 
> > > Right. The clocksource is determined at runtime. And if there is no high
> > > resolution clocksource then that function will return crap.
> > 
> > This patch still works even though the only clocksource is jiffies.
> 
> Works by some definition of works, right?

I am not sure there is such system which doesn't provide any high resolution
clocksource, meantime there is one high performance storage device
attached, and expect top IO performance can be reached.

Suppose there is such system: I mean that irq_flood_detected() returns either
true or false, then the actual IO performance should be accepted on
system without high resolution clocksource from user view.

> 
> > > Well, yes. But it's trivial enough to utilize parts of it for your
> > > purposes.
> > 
> > >From the code of kernel/irq/timing.c:
> > 
> > 1) record_irq_time() only records the start time of one irq, and not
> > consider the time taken in interrupt handler, so we can't figure out
> > the real interval between two do_IRQ() on one CPU
> 
> I said utilize and that means that the infrastructure can be used and
> extended. I did not say that it solves your problem, right?

The infrastructure is for predicating when the next interrupt comes,
which is used in PM cases(usually for mobile phone or power sensitive
cases). However, IRQ flood is used in high performance system(usually
enterprise case). The two use cases are actually orthogonal, also:

1) if the irq timing infrastructure is used, we have to apply the
management code on irq flood detection, for example, we have to
build the irq timing code in kernel and enable it. Then performance
regression might be caused for enterprise application.

2) irq timing's runtime overload is much higher, irq_timings_push()
touches much more memory footprint, since it records recent 32
irq's timestamp. That isn't what IRQ flood detection wants, also
not enough for flood detection.

3) irq flood detection itself is very simple, just one EWMA
calculation, see the following code:

irq_update_interval() (called from irq_enter())
int cpu = raw_smp_processor_id();
struct irq_interval *inter = per_cpu_ptr(_irq_interval, cpu);
u64 delta = sched_clock_cpu(cpu) - inter->last_irq_end;

inter->avg = (inter->avg * IRQ_INTERVAL_EWMA_PREV_FACTOR +
delta * IRQ_INTERVAL_EWMA_CURR_FACTOR) /
IRQ_INTERVAL_EWMA_WEIGHT;

bool irq_flood_detected(void) (called from __handle_irq_event_percpu())
{
return raw_cpu_ptr(_irq_interval)->avg <= IRQ_FLOOD_THRESHOLD_NS;
}

irq_exit()
inter->last_irq_end = sched_clock_cpu(smp_processor_id());

So there is basically nothing shared between the two, only one percpu
variable is needed for detecting irq flood.

> 
> > 2) irq/timing doesn't cover softirq
> 
> That's solvable, right?

Yeah, we can extend irq/timing, but ugly for irq/timing, since irq/timing
focuses on hardirq predication, and softirq isn't involved in that
purpose.

>  
> > Daniel, could you take a look and see if irq flood detection can be
> > implemented easily by irq/timing.c?
> 
> I assume you can take a look as well, right?

Yeah, I have looked at the code for a while, but I think that irq/timing
could become complicated unnecessarily for covering irq flood detection,
meantime it is much less efficient for detecting IRQ flood.

thanks,
Ming

Re: [PATCH 3/3] arm64: defconfig: Enable Qualcomm QUSB2 PHY

[Bjorn Andersson]

On Mon 02 Sep 06:07 PDT 2019, Lee Jones wrote:

> Tested on the Lenovo Yoga C630 where this patch enables USB.
> Without it USB devices are not enumerated.
> 
> Signed-off-by: Lee Jones 

Reviewed-by: Bjorn Andersson 

> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index af7ca722b519..a94d002182ee 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -770,6 +770,7 @@ CONFIG_PHY_HISTB_COMBPHY=y
>  CONFIG_PHY_HISI_INNO_USB2=y
>  CONFIG_PHY_MVEBU_CP110_COMPHY=y
>  CONFIG_PHY_QCOM_QMP=m
> +CONFIG_PHY_QCOM_QUSB2=m
>  CONFIG_PHY_QCOM_USB_HS=y
>  CONFIG_PHY_RCAR_GEN3_PCIE=y
>  CONFIG_PHY_RCAR_GEN3_USB2=y
> -- 
> 2.17.1
> 

Re: [PATCH 2/3] arm64: defconfig: Enable the EFI Framebuffer

[Bjorn Andersson]

On Mon 02 Sep 06:07 PDT 2019, Lee Jones wrote:

> Tested on the Lenovo Yoga C630 where this patch enables the
> framebuffer (screen/monitor).  Without it the device appears
> not to boot.
> 
> Signed-off-by: Lee Jones 

Reviewed-by: Bjorn Andersson 

> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index 0fe943ac53b5..af7ca722b519 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -540,6 +540,7 @@ CONFIG_DRM_LIMA=m
>  CONFIG_DRM_PANFROST=m
>  CONFIG_FB=y
>  CONFIG_FB_MODE_HELPERS=y
> +CONFIG_FB_EFI=y
>  CONFIG_BACKLIGHT_GENERIC=m
>  CONFIG_BACKLIGHT_PWM=m
>  CONFIG_BACKLIGHT_LP855X=m
> -- 
> 2.17.1
> 

Re: [PATCH 1/3] arm64: defconfig: Enable Qualcomm GENI based I2C controller

[Bjorn Andersson]

On Mon 02 Sep 06:07 PDT 2019, Lee Jones wrote:

> Tested on the Lenovo Yoga C630 where this patch enables the
> keyboard, touchpad and touchscreen.
> 
> Signed-off-by: Lee Jones 

Reviewed-by: Bjorn Andersson 

> ---
>  arch/arm64/configs/defconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
> index facf19cc275d..0fe943ac53b5 100644
> --- a/arch/arm64/configs/defconfig
> +++ b/arch/arm64/configs/defconfig
> @@ -366,6 +366,7 @@ CONFIG_I2C_IMX_LPI2C=y
>  CONFIG_I2C_MESON=y
>  CONFIG_I2C_MV64XXX=y
>  CONFIG_I2C_PXA=y
> +CONFIG_I2C_QCOM_GENI=m
>  CONFIG_I2C_QUP=y
>  CONFIG_I2C_RK3X=y
>  CONFIG_I2C_SH_MOBILE=y
> -- 
> 2.17.1
> 

RE: [PATCH net-next] r8152: modify rtl8152_set_speed function

[Hayes Wang]

Heiner Kallweit [mailto:hkallwe...@gmail.com]
> Sent: Tuesday, September 03, 2019 2:37 AM
[...]
> Seeing all this code it might be a good idea to switch this driver
> to phylib, similar to what I did with r8169 some time ago.

It is too complex to be completed for me at the moment.
If this patch is unacceptable, I would submit other
patches first. Thanks.

Best Regards,
Hayes

RE: [PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support

[Anson Huang]

Hi, Fabio

> On Mon, Sep 2, 2019 at 11:05 PM Anson Huang 
> wrote:
> 
> > +   ret = input_register_device(input);
> > +   if (ret < 0) {
> > +   dev_err(>dev, "failed to register input device\n");
> > +   return ret;
> > +   }
> > +
> > +   pdata->input = input;
> > +   platform_set_drvdata(pdev, pdata);
> > +
> > +   ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE,
> SC_IRQ_BUTTON, true);
> > +   if (ret) {
> > +   dev_warn(>dev, "enable scu group irq failed\n");
> > +   return ret;
> 
> Better do a 'goto input_unregister' here instead and call
> input_unregister_device().

Agreed, will fix in V3 later.

Thanks,
Anson.

Re: [RFC v1] clk: core: support clocks that need to be enabled during re-parent

[Weiyi Lu]

On Tue, 2019-06-25 at 20:52 -0700, Stephen Boyd wrote:
> Quoting Weiyi Lu (2019-06-25 18:05:22)
> > On Tue, 2019-06-25 at 15:14 -0700, Stephen Boyd wrote:
> > > Quoting Weiyi Lu (2019-06-09 20:44:53)
> > > > When using property assigned-clock-parents to assign parent clocks,
> > > > core clocks might still be disabled during re-parent.
> > > > Add flag 'CLK_OPS_CORE_ENABLE' for those clocks must be enabled
> > > > during re-parent.
> > > > 
> > > > Signed-off-by: Weiyi Lu 
> > > 
> > > Can you further describe the scenario where this is a problem? Is it
> > > some sort of clk that is enabled by default out of the bootloader and is
> > > then configured to have an 'assigned-clock-parents' property to change
> > > the parent, but that clk needs to be "enabled" so that the framework
> > > turns on the parents for the parent switch?
> > 
> > When driver is built as module(.ko) and install at runtime after the
> > whole initialization stage. Clk might already be turned off before
> > configuring by assigned-clock-parents. For such clock design that need
> > to have clock enabled during re-parent, the configuration of
> > assigned-clock-parents might be failed. That's the problem we have now.
> 
> Great. Please put this sort of information in the commit text.
> 

OK, I'll do when sending next version.

> > Do you have any suggestion for such usage of clocks? Many thanks.
> > 
> 
> Ok, and in this case somehow CLK_OPS_PARENT_ENABLE flag doesn't work? Is
> that because the clk itself doesn't do anything unless it's enabled?  I
> seem to recall that we usually work around this by caching the state of
> the clk parents or frequencies and then when the clk prepare or enable
> op is called we actually write the hardware to change the state. There
> are some qcom clks like this and we basically just use the hardware
> itself to cache the state of the clk while it hasn't actually changed to
> be at that rate, because the clk is not enabled yet.
> 

Hi Stephen,

Will you recommend if we cache the state in the platform driver instead
of the hardware itself and then change the state when clk enable op is
called if we don't have such hardware design on MTK clocks?

> The main concern is that we're having to turn on clks to make things
> work, when it would be best to not turn on clks just so that register
> writes actually make a difference to what the hardware does.
> 

In my view, it's a safe operation to enable clock shortly to make things
work when its child clock is still disabled. What do you think?

RE: [PATCH] perf/x86/intel: Update ICL Core and Package C-state event counters

[Pan, Harry]

Thank you Peter for pointing out my miss, I appreciate that sincerely.

>   *   MSR_CORE_C3_RESIDENCY: CORE C3 Residency Counter
>   *  perf code: 0x01
>   *  Available model: NHM,WSM,SNB,IVB,HSW,BDW,SKL,GLM,
> - CNL
> + CNL,ICL

That has a missing * introduced by the last such patch. Please take this
opportunity to put it back in.

Re: [RFC v3] vhost: introduce mdev based hardware vhost backend

[Jason Wang]

On 2019/9/3 上午9:56, Tiwei Bie wrote:

On Mon, Sep 02, 2019 at 12:15:05PM +0800, Jason Wang wrote:

On 2019/8/28 下午1:37, Tiwei Bie wrote:

Details about this can be found here:

https://lwn.net/Articles/750770/

What's new in this version
==

There are three choices based on the discussion [1] in RFC v2:


#1. We expose a VFIO device, so we can reuse the VFIO container/group
  based DMA API and potentially reuse a lot of VFIO code in QEMU.

  But in this case, we have two choices for the VFIO device interface
  (i.e. the interface on top of VFIO device fd):

  A) we may invent a new vhost protocol (as demonstrated by the code
 in this RFC) on VFIO device fd to make it work in VFIO's way,
 i.e. regions and irqs.

  B) Or as you proposed, instead of inventing a new vhost protocol,
 we can reuse most existing vhost ioctls on the VFIO device fd
 directly. There should be no conflicts between the VFIO ioctls
 (type is 0x3B) and VHOST ioctls (type is 0xAF) currently.

#2. Instead of exposing a VFIO device, we may expose a VHOST device.
  And we will introduce a new mdev driver vhost-mdev to do this.
  It would be natural to reuse the existing kernel vhost interface
  (ioctls) on it as much as possible. But we will need to invent
  some APIs for DMA programming (reusing VHOST_SET_MEM_TABLE is a
  choice, but it's too heavy and doesn't support vIOMMU by itself).

This version is more like a quick PoC to try Jason's proposal on
reusing vhost ioctls. And the second way (#1/B) in above three
choices was chosen in this version to demonstrate the idea quickly.

Now the userspace API looks like this:

- VFIO's container/group based IOMMU API is used to do the
DMA programming.

- Vhost's existing ioctls are used to setup the device.

And the device will report device_api as "vfio-vhost".

Note that, there are dirty hacks in this version. If we decide to
go this way, some refactoring in vhost.c/vhost.h may be needed.

PS. The direct mapping of the notify registers isn't implemented
  in this version.

[1] https://lkml.org/lkml/2019/7/9/101


Thanks for the patch, see comments inline.



Signed-off-by: Tiwei Bie 
---
   drivers/vhost/Kconfig  |   9 +
   drivers/vhost/Makefile |   3 +
   drivers/vhost/mdev.c   | 382 +
   include/linux/vhost_mdev.h |  58 ++
   include/uapi/linux/vfio.h  |   2 +
   include/uapi/linux/vhost.h |   8 +
   6 files changed, 462 insertions(+)
   create mode 100644 drivers/vhost/mdev.c
   create mode 100644 include/linux/vhost_mdev.h

[...]

+
+   break;
+   }
+   case VFIO_DEVICE_GET_REGION_INFO:
+   case VFIO_DEVICE_GET_IRQ_INFO:
+   case VFIO_DEVICE_SET_IRQS:
+   case VFIO_DEVICE_RESET:
+   ret = -EINVAL;
+   break;
+
+   case VHOST_MDEV_SET_STATE:
+   ret = vhost_set_state(vdpa, argp);
+   break;


So this is used to start or stop the device. This means if userspace want to
drive a network device, the API is not 100% compatible. Any blocker for
this? E.g for SET_BACKEND, we can pass a fd and then identify the type of
backend.

This is a legacy from the previous RFC code. I didn't try to
get rid of it while getting this POC to work. I can try to make
the vhost ioctls fully compatible with the existing userspace
if possible.



That would be fine.





Another question is, how can user know the type of a device?

Maybe we can introduce an attribute in $UUID/ to tell the type.



Yes, something like this or using mdev types and identify through 
something similar to get_socket() etc.








+   case VHOST_GET_FEATURES:
+   ret = vhost_get_features(vdpa, argp);
+   break;
+   case VHOST_SET_FEATURES:
+   ret = vhost_set_features(vdpa, argp);
+   break;
+   case VHOST_GET_VRING_BASE:
+   ret = vhost_get_vring_base(vdpa, argp);
+   break;
+   default:
+   ret = vhost_dev_ioctl(>dev, cmd, argp);
+   if (ret == -ENOIOCTLCMD)
+   ret = vhost_vring_ioctl(>dev, cmd, argp);
+   }
+
+   return ret;
+}

[...]

+struct mdev_device;
+struct vhost_mdev;
+
+typedef int (*vhost_mdev_start_device_t)(struct vhost_mdev *vdpa);
+typedef int (*vhost_mdev_stop_device_t)(struct vhost_mdev *vdpa);
+typedef int (*vhost_mdev_set_features_t)(struct vhost_mdev *vdpa);
+typedef void (*vhost_mdev_notify_device_t)(struct vhost_mdev *vdpa, int 
queue_id);
+typedef u64 (*vhost_mdev_get_notify_addr_t)(struct vhost_mdev *vdpa, int 
queue_id);
+typedef u16 (*vhost_mdev_get_vring_base_t)(struct vhost_mdev *vdpa, int 
queue_id);
+typedef void (*vhost_mdev_features_changed_t)(struct vhost_mdev *vdpa);
+
+struct vhost_mdev_device_ops {
+   vhost_mdev_start_device_t   start;
+   vhost_mdev_stop_device_tstop;
+   

Re: [PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ

[Jian-Hong Pan]

Kalle Valo  於 2019年9月2日 週一 下午8:18寫道：
>
> Tony Chuang  writes:
>
> >> From: Jian-Hong Pan
> >> Subject: [PATCH v4] rtw88: pci: Move a mass of jobs in hw IRQ to soft IRQ
> >>
> >> There is a mass of jobs between spin lock and unlock in the hardware
> >> IRQ which will occupy much time originally. To make system work more
> >> efficiently, this patch moves the jobs to the soft IRQ (bottom half) to
> >> reduce the time in hardware IRQ.
> >>
> >> Signed-off-by: Jian-Hong Pan 
> >
> > Now it works fine with MSI interrupt enabled.
> >
> > But this patch is conflicting with MSI interrupt patch.
> > Is there a better way we can make Kalle apply them more smoothly?
> > I can rebase them and submit both if you're OK.

The rebase work is appreciated.

Thank you,
Jian-Hong Pan

> Yeah, submitting all the MSI patches in the same patchset is the easiest
> approach. That way they apply cleanly to wireless-drivers-next.
>
> --
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [GIT PULL] extcon next for v5.4

[Chanwoo Choi]

Dear Greg,

Gently ping. 

Best Regards,
Chanwoo Choi


On 19. 8. 26. 오전 11:55, Chanwoo Choi wrote:
> Dear Greg,
> 
> This is extcon-next pull request for v5.4. I add detailed description of
> this pull request on below. Please pull extcon with following updates.
> 
> 
> Detailed description for this pull request:
> 1. Clean up the and fix the minor issue of extcon provider driver
> - extcon-arizona/max77843 replace the helper function
>   with more correct helper function without operation changes.
> - extcon-fsa9480 supports the FSA880 variant by adding the compatible name.
> - extcon-arizona updates the dt-binding file for the readability.
> - extcon-gpio initializes the interrupt flags according to active-low state.
> - Clean up extcon-sm5502/axp288/adc-jack
> 
> Best Regards,
> Chanwoo Choi
> 
> 
> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
> 
>   Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon.git 
> tags/extcon-next-for-5.4
> 
> for you to fetch changes up to a3fc5723397703a56fb6083b3e2f2ac601d1dfe0:
> 
>   extcon: adc-jack: Remove dev_err() usage after platform_get_irq() 
> (2019-07-31 09:55:46 +0900)
> 
> 
> Andy Shevchenko (3):
>   extcon: arizona: Switch to use device_property_count_u32()
>   extcon: axp288: Add missed error check
>   extcon: axp288: Use for_each_set_bit() in axp288_extcon_log_rsi()
> 
> Charles Keepax (1):
>   extcon: arizona: Update binding example to use available defines
> 
> Linus Walleij (2):
>   extcon: fsa9480: Support the FSA880 variant
>   extcon: gpio: Request reasonable interrupts
> 
> Stephen Boyd (1):
>   extcon: adc-jack: Remove dev_err() usage after platform_get_irq()
> 
> Vasyl Gomonovych (1):
>   extcon: sm5502: Add IRQ_ONESHOT
> 
> Wolfram Sang (1):
>   extcon: extcon-max77843: convert to i2c_new_dummy_device
> 
>  .../devicetree/bindings/extcon/extcon-arizona.txt  |  2 +-
>  .../devicetree/bindings/extcon/extcon-fsa9480.txt  |  4 ++-
>  drivers/extcon/extcon-adc-jack.c   |  4 +--
>  drivers/extcon/extcon-arizona.c|  2 +-
>  drivers/extcon/extcon-axp288.c | 16 ++--
>  drivers/extcon/extcon-fsa9480.c|  1 +
>  drivers/extcon/extcon-gpio.c   | 29 
> ++
>  drivers/extcon/extcon-max77843.c   |  6 ++---
>  drivers/extcon/extcon-sm5502.c |  2 +-
>  9 files changed, 39 insertions(+), 27 deletions(-)
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

[v2,2/2] rtc: pcf85263/pcf85363: support PM, wakeup device, improve performance

[Biwen Li]

Add some features as follow:
- Set quartz oscillator load capacitance by DT
  (generate more accuracy frequency)
- Set quartz oscillator drive control by DT
  (reduce/increase the current consumption)
- Set low jitter mode by DT
  (improve jitter performance)
- Set wakeup source by DT
  (wakeup device from suspend
- Select interrupt output pin by DT
  (INTA/TS(INTB))
- Add power management
- Add ioctl to check rtc status
  (check whether oscillator of pcf85263/pcf85363 is stopped)

Datasheet url:
- https://www.nxp.com/docs/en/data-sheet/PCF85263A.pdf
- https://www.nxp.com/docs/en/data-sheet/PCF85363A.pdf

Signed-off-by: Martin Fuzzey 
Signed-off-by: Biwen Li 
---
Change in v2:
- Replace properties name
  quartz-load-capacitance -> quartz-load-femtofarads
  quartz-drive-strength -> nxp,quartz-drive-strength
  quartz-low-jitter -> nxp,quartz-low-jitter
- Set default interrupt-output-pin as "INTA"

 drivers/rtc/rtc-pcf85363.c | 278 +++--
 1 file changed, 265 insertions(+), 13 deletions(-)

diff --git a/drivers/rtc/rtc-pcf85363.c b/drivers/rtc/rtc-pcf85363.c
index 3450d615974d..030da4e764eb 100644
--- a/drivers/rtc/rtc-pcf85363.c
+++ b/drivers/rtc/rtc-pcf85363.c
@@ -18,6 +18,16 @@
 #include 
 #include 
 
+/* Quartz capacitance */
+#define PCF85363_QUARTZCAP_7pF 0
+#define PCF85363_QUARTZCAP_6pF 1
+#define PCF85363_QUARTZCAP_12p5pF  2
+
+/* Quartz drive strength */
+#define PCF85363_QUARTZDRIVE_100ko 0
+#define PCF85363_QUARTZDRIVE_60ko  1
+#define PCF85363_QUARTZDRIVE_500ko 2
+
 /*
  * Date/Time registers
  */
@@ -96,10 +106,20 @@
 #define FLAGS_PIF  BIT(7)
 
 #define PIN_IO_INTAPM  GENMASK(1, 0)
-#define PIN_IO_INTA_CLK0
-#define PIN_IO_INTA_BAT1
-#define PIN_IO_INTA_OUT2
-#define PIN_IO_INTA_HIZ3
+#define PIN_IO_INTAPM_SHIFT0
+#define PIN_IO_INTA_CLK(0 << PIN_IO_INTAPM_SHIFT)
+#define PIN_IO_INTA_BAT(1 << PIN_IO_INTAPM_SHIFT)
+#define PIN_IO_INTA_OUT(2 << PIN_IO_INTAPM_SHIFT)
+#define PIN_IO_INTA_HIZ(3 << PIN_IO_INTAPM_SHIFT)
+
+#define PIN_IO_TSPM GENMASK(3, 2)
+#define PIN_IO_TSPM_SHIFT  2
+#define PIN_IO_TS_DISABLE  (0x0 << PIN_IO_TSPM_SHIFT)
+#define PIN_IO_TS_INTB_OUT (0x1 << PIN_IO_TSPM_SHIFT)
+#define PIN_IO_TS_CLK_OUT  (0x2 << PIN_IO_TSPM_SHIFT)
+#define PIN_IO_TS_IN   (0x3 << PIN_IO_TSPM_SHIFT)
+
+#define PIN_IO_CLKPM   BIT(7) /* 0 = enable CLK pin,1 = disable CLK pin */
 
 #define STOP_EN_STOP   BIT(0)
 
@@ -107,9 +127,33 @@
 
 #define NVRAM_SIZE 0x40
 
+#define DT_SECS_OS BIT(7)
+
+#define CTRL_OSCILLATOR_CL_MASKGENMASK(1, 0)
+#define CTRL_OSCILLATOR_CL_SHIFT   0
+#define CTRL_OSCILLATOR_OSCD_MASK  GENMASK(3, 2)
+#define CTRL_OSCILLATOR_OSCD_SHIFT 2
+#define CTRL_OSCILLATOR_LOWJ   BIT(4)
+
+#define CTRL_FUNCTION_COF_OFF  0x7 /* No clock output */
+
+enum pcf85363_irqpin {
+   IRQPIN_INTA,
+   IRQPIN_INTB
+};
+
+static const char *const pcf85363_irqpin_names[] = {
+   [IRQPIN_INTA] = "INTA",
+   [IRQPIN_INTB] = "INTB"
+};
+
+
 struct pcf85363 {
+   struct device *dev;
struct rtc_device   *rtc;
struct regmap   *regmap;
+   enum pcf85363_irqpin irq_pin;
+   int irq;
 };
 
 struct pcf85x63_config {
@@ -210,14 +254,26 @@ static int _pcf85363_rtc_alarm_irq_enable(struct pcf85363 
*pcf85363, unsigned
 {
unsigned int alarm_flags = ALRM_SEC_A1E | ALRM_MIN_A1E | ALRM_HR_A1E |
   ALRM_DAY_A1E | ALRM_MON_A1E;
-   int ret;
+   int ret, reg;
 
ret = regmap_update_bits(pcf85363->regmap, DT_ALARM_EN, alarm_flags,
 enabled ? alarm_flags : 0);
if (ret)
return ret;
 
-   ret = regmap_update_bits(pcf85363->regmap, CTRL_INTA_EN,
+   switch (pcf85363->irq_pin) {
+   case IRQPIN_INTA:
+   reg = CTRL_INTA_EN;
+   break;
+
+   case IRQPIN_INTB:
+   reg = CTRL_INTB_EN;
+   break;
+
+   default:
+   return -EINVAL;
+   }
+   ret = regmap_update_bits(pcf85363->regmap, reg,
 INT_A1IE, enabled ? INT_A1IE : 0);
 
if (ret || enabled)
@@ -282,12 +338,55 @@ static irqreturn_t pcf85363_rtc_handle_irq(int irq, void 
*dev_id)
return IRQ_NONE;
 }
 
+static int pcf85363_osc_is_stopped(struct pcf85363 *pcf85363)
+{
+   unsigned int regval;
+   int ret;
+
+   ret = regmap_read(pcf85363->regmap, DT_SECS, );
+   if (ret)
+   return ret;
+
+   ret = regval & DT_SECS_OS ? 1 : 0;
+   if (ret)
+   dev_warn(pcf85363->dev, "Oscillator stop detected, date/time is 
not reliable.\n");
+
+   return ret;
+}
+
+static int pcf85363_ioctl(struct device *dev,
+ unsigned int cmd, unsigned long arg)

[v2,1/2] dt-bindings: rtc: pcf85263/pcf85363: add some properties

[Biwen Li]

Add some properties for pcf85263/pcf85363 as follows:
  - interrupt-output-pin: string type
  - quartz-load-femtofarads: integer type
  - nxp,quartz-drive-strength: integer type
  - nxp,quartz-low-jitter: bool type
  - wakeup-source: bool type

Signed-off-by: Martin Fuzzey 
Signed-off-by: Biwen Li 
---
Change in v2:
- Replace properties name
  quartz-load-capacitance -> quartz-load-femtofarads
  quartz-drive-strength -> nxp,quartz-drive-strength
  quartz-low-jitter -> nxp,quartz-low-jitter
- Replace drive strength name
  PCF85263_QUARTZDRIVE_NORMAL -> PCF85263_QUARTZDRIVE_100ko
  PCF85263_QUARTZDRIVE_LOW -> PCF85263_QUARTZDRIVE_60ko
  PCF85263_QUARTZDRIVE_HIGH -> PCF85263_QUARTZDRIVE_500ko
- Set default interrupt-output-pin as "INTA"

 .../devicetree/bindings/rtc/pcf85363.txt  | 29 +++
 include/dt-bindings/rtc/pcf85363.h| 15 ++
 2 files changed, 44 insertions(+)
 create mode 100644 include/dt-bindings/rtc/pcf85363.h

diff --git a/Documentation/devicetree/bindings/rtc/pcf85363.txt 
b/Documentation/devicetree/bindings/rtc/pcf85363.txt
index 94adc1cf93d9..588f688b30d1 100644
--- a/Documentation/devicetree/bindings/rtc/pcf85363.txt
+++ b/Documentation/devicetree/bindings/rtc/pcf85363.txt
@@ -8,10 +8,39 @@ Required properties:
 Optional properties:
 - interrupts: IRQ line for the RTC (not implemented).
 
+- interrupt-output-pin: The interrupt output pin must be
+  "INTA" or "INTB", default value is "INTA"
+
+- quartz-load-femtofarads: The internal capacitor to select for the quartz:
+   PCF85263_QUARTZCAP_7pF  [0]
+   PCF85263_QUARTZCAP_6pF  [1]
+   PCF85263_QUARTZCAP_12p5pF   [2] DEFAULT
+
+- nxp,quartz-drive-strength: Drive strength for the quartz:
+   PCF85263_QUARTZDRIVE_100ko  [0] DEFAULT
+   PCF85263_QUARTZDRIVE_60ko   [1]
+   PCF85263_QUARTZDRIVE_500ko  [2]
+
+- nxp,quartz-low-jitter: Boolean property, if present enables low jitter mode
+  which reduces jitter at the cost of increased power consumption.
+
+- wakeup-source: Boolean property, Please refer to
+  Documentation/devicetree/bindings/power/wakeup-source.txt
+
 Example:
 
 pcf85363: pcf85363@51 {
compatible = "nxp,pcf85363";
reg = <0x51>;
+
+   interrupt-parent = <>;
+   interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
+
+   #include 
+   wakeup-source;
+   interrupt-output-pin = "INTA";
+   quartz-load-femtofarads = ;
+   nxp,quartz-drive-strength = ;
+   nxp,quartz-low-jitter;
 };
 
diff --git a/include/dt-bindings/rtc/pcf85363.h 
b/include/dt-bindings/rtc/pcf85363.h
new file mode 100644
index ..f71b151bc481
--- /dev/null
+++ b/include/dt-bindings/rtc/pcf85363.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _DT_BINDINGS_RTC_PCF85363_H
+#define _DT_BINDINGS_RTC_PCF85363_H
+
+/* Quartz capacitance */
+#define PCF85363_QUARTZCAP_7pF 0
+#define PCF85363_QUARTZCAP_6pF 1
+#define PCF85363_QUARTZCAP_12p5pF  2
+
+/* Quartz drive strength */
+#define PCF85363_QUARTZDRIVE_100ko 0
+#define PCF85363_QUARTZDRIVE_60ko  1
+#define PCF85363_QUARTZDRIVE_500ko 2
+
+#endif /* _DT_BINDINGS_RTC_PCF85363_H */
-- 
2.17.1

Re: [RFC 2/5] ARM: dts: add support for opp-v2 for omap34xx and omap36xx

[Viresh Kumar]

On 03-09-19, 08:08, Viresh Kumar wrote:
> On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
> > +   opp1-12500 {
> > +   opp-hz = /bits/ 64 <12500>;
> > +   // we currently only select the max voltage from table 
> > Table 3-3 of the omap3530 Data sheet (SPRS507F)
> > +   //  could also be single 
> > +   opp-microvolt = <975000 975000 975000>;
> > +   // first value is silicon revision, second one 720MHz 
> > Device Identification
> 
> > +   opp-supported-hw = <0x 3>;
> 
> I don't see the driver changes using this field, am I missing
> something ?

The driver already had them it seems. Hmm..

-- 
viresh

Re: [PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support

[Fabio Estevam]

Hi Anson,

On Mon, Sep 2, 2019 at 11:05 PM Anson Huang  wrote:

> +   ret = input_register_device(input);
> +   if (ret < 0) {
> +   dev_err(>dev, "failed to register input device\n");
> +   return ret;
> +   }
> +
> +   pdata->input = input;
> +   platform_set_drvdata(pdev, pdata);
> +
> +   ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, 
> true);
> +   if (ret) {
> +   dev_warn(>dev, "enable scu group irq failed\n");
> +   return ret;

Better do a 'goto input_unregister' here instead and call
input_unregister_device().

Re: [RFC 2/5] ARM: dts: add support for opp-v2 for omap34xx and omap36xx

[Viresh Kumar]

On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
> + opp1-12500 {
> + opp-hz = /bits/ 64 <12500>;
> + // we currently only select the max voltage from table 
> Table 3-3 of the omap3530 Data sheet (SPRS507F)
> + //  could also be single 
> + opp-microvolt = <975000 975000 975000>;
> + // first value is silicon revision, second one 720MHz 
> Device Identification

> + opp-supported-hw = <0x 3>;

I don't see the driver changes using this field, am I missing
something ?

-- 
viresh

Re: [RFC 4/5] ARM: dts: omap3-n950-n9: remove opp-v1 table

[Viresh Kumar]

On 02-09-19, 12:55, H. Nikolaus Schaller wrote:
> With opp-v2 in omap36xx.dtsi and ti-cpufreq driver the
> 1GHz capability is automatically detected.
> 
> Signed-off-by: H. Nikolaus Schaller 
> ---
>  arch/arm/boot/dts/omap3-n950-n9.dtsi | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/omap3-n950-n9.dtsi 
> b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> index 5441e9ffdbb4..e98b0c615f19 100644
> --- a/arch/arm/boot/dts/omap3-n950-n9.dtsi
> +++ b/arch/arm/boot/dts/omap3-n950-n9.dtsi
> @@ -11,13 +11,6 @@
>   cpus {
>   cpu@0 {
>   cpu0-supply = <>;
> - operating-points = <
> - /* kHzuV */
> - 30  1012500
> - 60  120
> - 80  1325000
> - 100 1375000
> - >;
>   };
>   };

This should be merged with 2/5 ?

-- 
viresh

RE: [PATCH v3 04/11] PCI: designware-ep: Modify MSI and MSIX CAP way of finding

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月2日 23:07
> To: Xiaowei Bao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> 
> Subject: Re: [PATCH v3 04/11] PCI: designware-ep: Modify MSI and MSIX CAP
> way of finding
> 
> On Mon, Sep 02, 2019 at 11:17:09AM +0800, Xiaowei Bao wrote:
> > Each PF of EP device should have it's own MSI or MSIX capabitily
> > struct, so create a dw_pcie_ep_func struct and remover the msi_cap
> 
> remover?

Sorry. ^_^


> 
> > and msix_cap to this struce, and manage the PFs with a list.
> 
> struce?
> 
> >
> > Signed-off-by: Xiaowei Bao 
> > ---
> > v1:
> >  - This is a new patch, to fix the issue of MSI and MSIX CAP way of
> >finding.
> > v2:
> >  - No change.
> > v3:
> >  - No change.
> 
> This makes it look like you introduced the patch in v1 and haven't changed it
> since.
> 
> I think it's more common to have a history like this:
> 
> ---
> v3:
>  - Introduced new patch, to fix the issue of MSI and MSIX CAP way of
>finding.

OK, thanks, I am not clear the rules, thanks a lot for your help.

Thanks 
Xiaowei

> 
> 
> >
> >  drivers/pci/controller/dwc/pcie-designware-ep.c | 135
> +---
> >  drivers/pci/controller/dwc/pcie-designware.h|  18 +++-
> >  2 files changed, 134 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > index c3bc7bd..144eb12 100644
> > --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> > +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> > @@ -19,6 +19,19 @@ void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> > pci_epc_linkup(epc);
> >  }
> >
> > +struct dw_pcie_ep_func *
> > +dw_pcie_ep_get_func_from_ep(struct dw_pcie_ep *ep, u8 func_no) {
> > +   struct dw_pcie_ep_func *ep_func;
> > +
> > +   list_for_each_entry(ep_func, >func_list, list) {
> > +   if (ep_func->func_no == func_no)
> > +   return ep_func;
> > +   }
> > +
> > +   return NULL;
> > +}
> > +
> >  static unsigned int dw_pcie_ep_func_select(struct dw_pcie_ep *ep, u8
> > func_no)  {
> > unsigned int func_offset = 0;
> > @@ -59,6 +72,47 @@ void dw_pcie_ep_reset_bar(struct dw_pcie *pci,
> enum pci_barno bar)
> > __dw_pcie_ep_reset_bar(pci, func_no, bar, 0);  }
> >
> > +static u8 __dw_pcie_ep_find_next_cap(struct dw_pcie_ep *ep, u8
> func_no,
> > +   u8 cap_ptr, u8 cap)
> > +{
> > +   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +   unsigned int func_offset = 0;
> > +   u8 cap_id, next_cap_ptr;
> > +   u16 reg;
> > +
> > +   if (!cap_ptr)
> > +   return 0;
> > +
> > +   func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > +   reg = dw_pcie_readw_dbi(pci, func_offset + cap_ptr);
> > +   cap_id = (reg & 0x00ff);
> > +
> > +   if (cap_id > PCI_CAP_ID_MAX)
> > +   return 0;
> > +
> > +   if (cap_id == cap)
> > +   return cap_ptr;
> > +
> > +   next_cap_ptr = (reg & 0xff00) >> 8;
> > +   return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
> 
> Which tree have you based this patchset on? v5.3-rc3 and pci/dwc both
> already have this function (without the func_no). See beb4641a787d
> ("PCI: dwc: Add MSI-X callbacks handler").

There is a commit 7a6854f68 in the latest kernel.

Thanks 
Xiaowei

> 
> > +
> > +static u8 dw_pcie_ep_find_capability(struct dw_pcie_ep *ep, u8
> > +func_no, u8 cap) {
> > +   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +   unsigned int func_offset = 0;
> > +   u8 next_cap_ptr;
> > +   u16 reg;
> > +
> > +   func_offset = dw_pcie_ep_func_select(ep, func_no);
> > +
> > +   reg = dw_pcie_readw_dbi(pci, func_offset + PCI_CAPABILITY_LIST);
> > +   next_cap_ptr = (reg & 0x00ff);
> > +
> > +   return __dw_pcie_ep_find_next_cap(ep, func_no, next_cap_ptr, cap); }
> > +
> >  static int dw_pcie_ep_write_header(struct pci_epc *epc, u8 func_no,
> >struct pci_epf_header *hdr)
> >  {
> > @@ -246,13 +300,18 @@ static int dw_pcie_ep_get_msi(struct pci_epc
> *epc, u8 func_no)
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > u32 val, reg;
> > unsigned int func_offset = 0;
> > +   struct dw_pcie_ep_func *ep_func;
> >
> > -   if (!ep->msi_cap)
> > +   ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > +   if (!ep_func)
> > +   return -EINVAL;
> > +
> > +   if (!ep_func->msi_cap)
> > return -EINVAL;
> >
> > func_offset = dw_pcie_ep_func_select(ep, func_no);
> >
> > -   reg = ep->msi_cap + func_offset + PCI_MSI_FLAGS;
> > +   reg = ep_func->msi_cap + func_offset + PCI_MSI_FLAGS;
> 

RE: [PATCH] Input: elants_i2c - return real value of elants_i2c_initialize()

[Johnny.Chuang]

Hi Dmitry,

Thanks for your explanation.
If I want to abandon this patch, what's step I need to do?

Many thanks,
Johnny
-Original Message-
From: 'Dmitry Torokhov' [mailto:dmitry.torok...@gmail.com] 
Sent: Friday, August 30, 2019 2:30 AM
To: Johnny.Chuang
Cc: linux-kernel@vger.kernel.org; linux-in...@vger.kernel.org; STRD2-蔡惠嬋;
STRD2-陳崇明經理; '梁博翔'; 'jeff'
Subject: Re: [PATCH] Input: elants_i2c - return real value of
elants_i2c_initialize()

Hi Johnny,

On Wed, Aug 28, 2019 at 10:33:46AM +0800, Johnny.Chuang wrote:
> The return value of elants_i2c_initialize() was always 0.
> It maybe register input device when initialize fail.

We do not want to return error here, because it will abort probe, and then
we will not be able to initiate firmware flash flow so we can attempt to
recover the device.

If you want to try you can change the ts->iap_mode before trying to register
input device, but then you need to be very careful about registering and
unregistering it later, after flashing or re-flashing firmware.

> 
> Signed-off-by: Johnny Chuang 
> ---
>  drivers/input/touchscreen/elants_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/elants_i2c.c
> b/drivers/input/touchscreen/elants_i2c.c
> index d4ad24e..9c9816f 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -571,7 +571,7 @@ static int elants_i2c_initialize(struct elants_data
*ts)
>   if (error)
>   ts->iap_mode = ELAN_IAP_RECOVERY;
>  
> - return 0;
> + return error;
>  }
>  
>  /*
> --
> 2.7.4
> 

Thanks.

-- 
Dmitry

RE: [PATCH] i801_smbus: clear SMBALERT status bit and disable SMBALERT interrupt

[Xu, Lingyan (NSB - CN/Hangzhou)]

Hi Jean,
Thanks a lot for your comments. And, yes, it is dangerous that clear all 
interrupt bit here based my local test. And about the interrupt flood, I will 
show you in attached file. And I agree with you that add SMBALERT interrupt 
handler if possible, but I have no idea about what action is need in this 
handler because that it seams that i801 can not clear salve chip's status bit 
directly.


Best Regards!
Lingyan xu

-Original Message-
From: Jean Delvare  
Sent: 2019年8月28日 21:58
To: Xu, Lingyan (NSB - CN/Hangzhou) 
Cc: Adamski, Krzysztof (Nokia - PL/Wroclaw) ; 
Wiebe, Wladislav (Nokia - DE/Ulm) ; 
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i801_smbus: clear SMBALERT status bit and disable SMBALERT 
interrupt

Hi Lingyan,

On Mon, 12 Aug 2019 10:40:34 +0800, lingyxu wrote:
> From: Lingyan Xu 
> 
> In current i801 driver, SMBALERT interrupt is allowed (Slave Command 
> Register bit2 is 0).
> But these is no handler for SMBALERT interrupt in i801_isr, if there 
> is SMBALERT interrupt asserted and deasserted,
> i801 will have an irq flood for the related status bit is setted.
> 
> So SMBALERT interrupt handler is needed, and also, SMBALERT interrupt 
> will be generated from time to time if slave chip have some fault.
> So disable SMBALERT interrupt is also needed.
> 
> About the solution,
> please see http://www.farnell.com/datasheets/1581967.pdf
> Page632 P640 for more.
> 
> Signed-off-by: Lingyan Xu 
> ---
>  drivers/i2c/busses/i2c-i801.c |7 ++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-i801.c 
> b/drivers/i2c/busses/i2c-i801.c index f295693..033bafe 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -661,9 +661,11 @@ static irqreturn_t i801_isr(int irq, void *dev_id)
>* Clear irq sources and report transaction result.
>* ->status must be cleared before the next transaction is started.
>*/
> +
> + outb_p(status, SMBHSTSTS(priv));
> +
>   status &= SMBHSTSTS_INTR | STATUS_ERROR_FLAGS;
>   if (status) {
> - outb_p(status, SMBHSTSTS(priv));
>   priv->status = status;
>   wake_up(>waitq);
>   }

Looks scary. Writing the whole value of SMBHSTSTS back to itself without 
selecting which bits you write is dangerous. Specifically, writing back 
SMBHSTSTS_BYTE_DONE, SMBHSTSTS_INUSE_STS and SMBHSTSTS_HOST_BUSY could have 
unexpected consequences. I would feel much better if you would just explicitly 
add SMBHSTSTS_SMBALERT_STS to the list.

> @@ -1810,6 +1812,9 @@ static int i801_probe(struct pci_dev *dev, const struct 
> pci_device_id *id)
>   /* Default timeout in interrupt mode: 200 ms */
>   priv->adapter.timeout = HZ / 5;
>  
> + /* Disable SMBALERT interrupt */
> + outb_p(inb_p(SMBSLVCMD(priv)) | BIT(2), SMBSLVCMD(priv));

Please give SMBSLVCMD's BIT(2) a name and define it after 
SMBSLVCMD_HST_NTFY_INTREN.

Also it is mandatory to restore the value of SMBSLVCMD before returning the 
control back to the BIOS. Currently this is only being done when the 
FEATURE_HOST_NOTIFY bit is set because that's the only case where we change the 
value of that register, but if we change it unconditionally then it must be 
saved and restored unconditionally too.

> +
>   if (dev->irq == IRQ_NOTCONNECTED)
>   priv->features &= ~FEATURE_IRQ;
>  

That being said, if you see this interrupt flood, it means that at least one 
device on your SMBus would benefit from SMBus Alert being supported. The 
infrastructure is already there as we added support in a few I2C bus drivers 
already. So maybe instead of silencing the interrupts, we could add proper 
SMBus Alert support to the i2c-i801 driver?

Did you figure out which device is raising the SMBus Alert and why?

--
Jean Delvare
SUSE L3 Support

RE: [EXT] Re: [1/2] dt-bindings: rtc: pcf85263/pcf85363: add some properties

[Biwen Li]

> 
> Caution: EXT Email
> 
> On Fri, Aug 30, 2019 at 05:17:19PM +0800, Biwen Li wrote:
> > Add some properties for pcf85263/pcf85363 as follows:
> >   - interrupt-output-pin: string type
> >   - quartz-load-capacitance: integer type
> >   - quartz-drive-strength: integer type
> >   - quartz-low-jitter: bool type
> >   - wakeup-source: bool type
> >
> > Signed-off-by: Martin Fuzzey 
> > Signed-off-by: Biwen Li 
> > ---
> >  .../devicetree/bindings/rtc/pcf85363.txt  | 31
> +++
> >  include/dt-bindings/rtc/pcf85363.h| 15 +
> >  2 files changed, 46 insertions(+)
> >  create mode 100644 include/dt-bindings/rtc/pcf85363.h
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/pcf85363.txt
> > b/Documentation/devicetree/bindings/rtc/pcf85363.txt
> > index 94adc1cf93d9..d83359990bd7 100644
> > --- a/Documentation/devicetree/bindings/rtc/pcf85363.txt
> > +++ b/Documentation/devicetree/bindings/rtc/pcf85363.txt
> > @@ -8,10 +8,41 @@ Required properties:
> >  Optional properties:
> >  - interrupts: IRQ line for the RTC (not implemented).
> >
> > +- interrupt-output-pin: The interrupt output pin must be
> > +  "NONE", "INTA" or "INTB", default value is "NONE"
> > +
> > +- quartz-load-capacitance: The internal capacitor to select for the quartz:
> > + PCF85263_QUARTZCAP_7pF  [0]
> > + PCF85263_QUARTZCAP_6pF  [1]
> > + PCF85263_QUARTZCAP_12p5pF   [2] DEFAULT
> 
> We have a common property for this. Use it.
Ok, I will replace it in v2.
> 
> > +
> > +- quartz-drive-strength: Drive strength for the quartz:
> > + PCF85263_QUARTZDRIVE_NORMAL [0] DEFAULT
> > + PCF85263_QUARTZDRIVE_LOW[1]
> > + PCF85263_QUARTZDRIVE_HIGH   [2]
> > +
> > +- quartz-low-jitter: Boolean property, if present enables low jitter
> > +mode
> > +  which reduces jitter at the cost of increased power consumption.
> 
> These 2  need vendor prefixes.
Okay, I will add vendor prefixes in v2.
> 
> > +
> > +- wakeup-source: Boolean property, mark the chip as a wakeup source,
> > +  independently of the availability of an IRQ line connected to the SoC.
> > +  This is useful if the IRQ line is connected to a PMIC or other
> > +circuit
> > +  that can power up the device rather than to a normal SOC interrupt.
> > +
> >  Example:
> >
> >  pcf85363: pcf85363@51 {
> >   compatible = "nxp,pcf85363";
> >   reg = <0x51>;
> > +
> > + interrupt-parent = <>;
> > + interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
> > +
> > + #include 
> > + wakeup-source;
> > + interrupt-output-pin = "INTA";
> > + quartz-load-capacitance = ;
> > + quartz-drive-strength = ;
> > + quartz-low-jitter;
> >  };
> >
> > diff --git a/include/dt-bindings/rtc/pcf85363.h
> > b/include/dt-bindings/rtc/pcf85363.h
> > new file mode 100644
> > index ..2c06c28eb5ff
> > --- /dev/null
> > +++ b/include/dt-bindings/rtc/pcf85363.h
> > @@ -0,0 +1,15 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */ #ifndef
> > +_DT_BINDINGS_RTC_PCF85363_H #define
> _DT_BINDINGS_RTC_PCF85363_H
> > +
> > +/* Quartz capacitance */
> > +#define PCF85363_QUARTZCAP_7pF   0
> > +#define PCF85363_QUARTZCAP_6pF   1
> > +#define PCF85363_QUARTZCAP_12p5pF2
> > +
> > +/* Quartz drive strength */
> > +#define PCF85363_QUARTZDRIVE_NORMAL  0
> > +#define PCF85363_QUARTZDRIVE_LOW 1
> > +#define PCF85363_QUARTZDRIVE_HIGH2
> > +
> > +#endif /* _DT_BINDINGS_RTC_PCF85363_H */
> > --
> > 2.17.1
> >

Re: [PATCH 2/9] perf/core: Add PERF_SAMPLE_CGROUP feature

[Namhyung Kim]

Hi Tejun,

Sorry for the late reply.


On Fri, Aug 30, 2019 at 09:58:15PM -0700, Tejun Heo wrote:
> Hello,
> 
> On Sat, Aug 31, 2019 at 12:03:26PM +0900, Namhyung Kim wrote:
> > Hmm.. it looks hard to use fhandle as the identifier since perf
> > sampling is done in NMI context.  AFAICS the encode_fh part seems ok
> > but getting dentry/inode from a kernfs_node seems not.
> > 
> > I assume kernfs_node_id's ino and gen are same to its inode's.  Then
> > we might use kernfs_node for encoding but not sure you like it ;-)
> 
> Oh yeah, the whole cgroup id situation is kinda shitty and it's likely
> that it needs to be cleaned up a bit for this to be used widely.  The
> issues are...
> 
> * As identifiers, paths sucks.  It's too big and unwieldy and can be
>   rapidly reused for different instances.
> 
> * ino is compact but can't be easily mapped to path from userland and
>   also not unique.
> 
> * The fhandle identifier - currently ino+gen - is better in that it's
>   finite sized and compact and can be efficiently mapped to path from
>   userspace.  It's also mostly unique.  However, the way gen is
>   currently generated still has some chance of the same ID getting
>   reused and it isn't easily accessible from inside the kernel right
>   now.
> 
> Eventually, where we wanna be at is having a single 64bit identifier
> which can be easily used everywhere.  It should be pretty straight
> forward on 64bit machines - we can just use monotonically increasing
> id and use it for everything - ino, fhandle and internal cgroup id.
> On 32bit, it gets a bit complicated because ino is 32bit, so it'll
> need a custom allocator which bumps gen when the lower 32bit wraps and
> skips in-use inos.  Once we have that, we can use that for cgrp->id
> and fhandle and derive ino from it.
> 
> This is on the to-do list but obviously hasn't happened yet.  If you
> wanna take on it, great, but, otherwise, what can be done now is
> either moving gen+ino generation into cgroup and tell kernfs to use it
> or copy gen+ino into cgroup for easier access.  The former likely is
> the better approach given that it brings us closer to where we wanna
> be eventually.

So is my understanding below correct?

 * currently kernfs ino+gen is different than inode's ino+gen
 * but it'd be better to make them same
 * so move (generic?) inode's ino+gen logic to cgroup
 * and kernfs node use the same logic (and number)
 * so perf sampling code (NMI) just access kernfs node
 * and userspace can use file handle for comparison

Thanks,
Namhyung

RE: [PATCH v3 07/11] PCI: layerscape: Modify the way of getting capability with different PEX

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月2日 21:38
> To: Xiaowei Bao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> 
> Subject: Re: [PATCH v3 07/11] PCI: layerscape: Modify the way of getting
> capability with different PEX
> 
> On Mon, Sep 02, 2019 at 11:17:12AM +0800, Xiaowei Bao wrote:
> > The different PCIe controller in one board may be have different
> > capability of MSI or MSIX, so change the way of getting the MSI
> > capability, make it more flexible.
> >
> > Signed-off-by: Xiaowei Bao 
> 
> Please see the comments I just made to Kishon's feedback in the thread for
> this patch in series v2.

I have reply the comments in series v2, expect Kishon's feedback.

Thanks
Xiaowei

> 
> Thanks,
> 
> Andrew Murray
> 
> > ---
> > v2:
> >  - Remove the repeated assignment code.
> > v3:
> >  - Use ep_func msi_cap and msix_cap to decide the msi_capable and
> >msix_capable of pci_epc_features struct.
> >
> >  drivers/pci/controller/dwc/pci-layerscape-ep.c | 31
> > +++---
> >  1 file changed, 23 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index a9c552e..1e07287 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -22,6 +22,7 @@
> >
> >  struct ls_pcie_ep {
> > struct dw_pcie  *pci;
> > +   struct pci_epc_features *ls_epc;
> >  };
> >
> >  #define to_ls_pcie_ep(x)   dev_get_drvdata((x)->dev)
> > @@ -40,26 +41,31 @@ static const struct of_device_id
> ls_pcie_ep_of_match[] = {
> > { },
> >  };
> >
> > -static const struct pci_epc_features ls_pcie_epc_features = {
> > -   .linkup_notifier = false,
> > -   .msi_capable = true,
> > -   .msix_capable = false,
> > -   .bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > -};
> > -
> >  static const struct pci_epc_features*  ls_pcie_ep_get_features(struct
> > dw_pcie_ep *ep)  {
> > -   return _pcie_epc_features;
> > +   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +   struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > +
> > +   return pcie->ls_epc;
> >  }
> >
> >  static void ls_pcie_ep_init(struct dw_pcie_ep *ep)  {
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +   struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > +   struct dw_pcie_ep_func *ep_func;
> > enum pci_barno bar;
> >
> > +   ep_func = dw_pcie_ep_get_func_from_ep(ep, 0);
> > +   if (!ep_func)
> > +   return;
> > +
> > for (bar = BAR_0; bar <= BAR_5; bar++)
> > dw_pcie_ep_reset_bar(pci, bar);
> > +
> > +   pcie->ls_epc->msi_capable = ep_func->msi_cap ? true : false;
> > +   pcie->ls_epc->msix_capable = ep_func->msix_cap ? true : false;
> >  }
> >
> >  static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no, @@
> > -119,6 +125,7 @@ static int __init ls_pcie_ep_probe(struct platform_device
> *pdev)
> > struct device *dev = >dev;
> > struct dw_pcie *pci;
> > struct ls_pcie_ep *pcie;
> > +   struct pci_epc_features *ls_epc;
> > struct resource *dbi_base;
> > int ret;
> >
> > @@ -130,6 +137,10 @@ static int __init ls_pcie_ep_probe(struct
> platform_device *pdev)
> > if (!pci)
> > return -ENOMEM;
> >
> > +   ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
> > +   if (!ls_epc)
> > +   return -ENOMEM;
> > +
> > dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> "regs");
> > pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > if (IS_ERR(pci->dbi_base))
> > @@ -140,6 +151,10 @@ static int __init ls_pcie_ep_probe(struct
> platform_device *pdev)
> > pci->ops = _pcie_ep_ops;
> > pcie->pci = pci;
> >
> > +   ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > +
> > +   pcie->ls_epc = ls_epc;
> > +
> > platform_set_drvdata(pdev, pcie);
> >
> > ret = ls_add_pcie_ep(pcie, pdev);
> > --
> > 2.9.5
> >

RE: [PATCH v2 06/10] PCI: layerscape: Modify the way of getting capability with different PEX

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月2日 21:37
> To: Xiaowei Bao 
> Cc: Kishon Vijay Abraham I ; bhelg...@google.com;
> robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo Li
> ; lorenzo.pieral...@arm.co
> ; a...@arndb.de; gre...@linuxfoundation.org;
> M.h. Lian ; Mingkai Hu ;
> Roy Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org
> Subject: Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of getting
> capability with different PEX
> 
> On Fri, Aug 23, 2019 at 04:13:30AM +, Xiaowei Bao wrote:
> >
> >
> > > -Original Message-
> > > From: Kishon Vijay Abraham I 
> > > Sent: 2019年8月23日 11:40
> > > To: Xiaowei Bao ; bhelg...@google.com;
> > > robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> > > robh+Li
> > > ; lorenzo.pieral...@arm.co
> > > ; a...@arndb.de;
> > > gre...@linuxfoundation.org; M.h. Lian ;
> > > Mingkai Hu ; Roy Zang ;
> > > jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> > > linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > linuxppc-...@lists.ozlabs.org; andrew.mur...@arm.com
> > > Subject: Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of
> > > getting capability with different PEX
> > >
> > > Hi,
> > >
> > > (Fixed Lorenzo's email address. All the patches in the series have
> > > wrong email
> > > id)
> > >
> > > On 23/08/19 8:09 AM, Xiaowei Bao wrote:
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Kishon Vijay Abraham I 
> > > >> Sent: 2019年8月22日 19:44
> > > >> To: Xiaowei Bao ; bhelg...@google.com;
> > > >> robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > >> robh+Leo
> > > Li
> > > >> ; lorenzo.pieral...@arm.co; a...@arndb.de;
> > > >> gre...@linuxfoundation.org; M.h. Lian ;
> > > >> Mingkai Hu ; Roy Zang ;
> > > >> jingooh...@gmail.com; gustavo.pimen...@synopsys.com;
> > > >> linux-...@vger.kernel.org; devicet...@vger.kernel.org;
> > > >> linux-kernel@vger.kernel.org;
> > > >> linux-arm-ker...@lists.infradead.org;
> > > >> linuxppc-...@lists.ozlabs.org; andrew.mur...@arm.com
> > > >> Subject: Re: [PATCH v2 06/10] PCI: layerscape: Modify the way of
> > > >> getting capability with different PEX
> > > >>
> > > >> Hi,
> > > >>
> > > >> On 22/08/19 4:52 PM, Xiaowei Bao wrote:
> > > >>> The different PCIe controller in one board may be have different
> > > >>> capability of MSI or MSIX, so change the way of getting the MSI
> > > >>> capability, make it more flexible.
> > > >>
> > > >> please use different pci_epc_features table for different boards.
> > > > Thanks, I think that it will be more flexible to dynamically get
> > > > MSI or MSIX capability, Thus, we will not need to define the
> > > > pci_epc_feature for
> > > different boards.
> > >
> > > Is the restriction because you cannot have different compatible for
> > > different boards?
> > Sorry, I am not very clear what your mean, I think even if I use the
> > same compatible with different boards, each boards will enter the
> > probe function, in there I will get the MSI or MSIX PCIe capability of
> > the current controller in this board. Why do I need to define the
> pci_epc_feature for different boards?
> 
> At present you determine how to set the [msi,msix]_capable flags of
> pci_epc_features based on reading the function capabilities at probe time.
> Instead of doing this, is it possible that you can determine the flags based 
> on
> the compatible type alone? For example, is the MSI/MSIX capability the same
> for all fsl,ls2088a-pcie-ep devices?
> 
> If it isn't *necessary* to probe for this information at probe time, then you
> could instead create a static pci_epc_features structure and assign it to
> something in your drvdata. This may provide some benefits.
> 
> The dw_pcie_ep_get_features function would then look like:
> 
> static const struct pci_epc_features*
> ls_pcie_ep_get_features(struct dw_pcie_ep *ep) {
>   struct dw_pcie *pci = to_dw_pcie_from_pp(ep);
>   struct ls_pcie_ep *pcie = dev_get_drvdata(pci->dev);
>   return pcie->epc_features;
> }
> 
> This also means you can revert "[v3,03/11] PCI: designware-ep: Move the".
> 
> Is this what you had in mind Kishon?

Yes, I consider this scheme, but there is a issue with my board, e.g. my board 
have
three PCIE controllers, but only two controllers support MSI, I can't said that 
the 
board support the MSI feature, so I only set the msi_capabitily by reading the 
MSI
capability struct the current PCIE controller, I am also very entangled in this 
issue.
so, do you have better advice? Thanks a lot.

Thanks 
Xiaowei

> 
> Thanks,
> 
> Andrew Murray
> 
> > >
> > > Thanks
> > > Kishon
> > >
> > > >>
> > > >> Thanks
> > > >> Kishon
> > > >>>
> > > >>> Signed-off-by: Xiaowei Bao 
> > > 

RE: [PATCH 1/5] dt-bindings: fsl: scu: add scu power key binding

[Anson Huang]

Hi, Rob

> On Fri, Aug 30, 2019 at 04:53:45PM -0400, Anson Huang wrote:
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > controller, the system controller is in charge of system power, clock
> > and power key event etc. management, Linux kernel has to communicate
> > with system controller via MU (message unit) IPC to get power key
> > event, add binding doc for i.MX system controller power key driver.
> >
> > Signed-off-by: Anson Huang 
> > ---
> >  .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 18
> ++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index c149fad..001d0b7 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -157,6 +157,17 @@ Required properties:
> >  Optional properties:
> >  - timeout-sec: contains the watchdog timeout in seconds.
> >
> > +Power key bindings based on SCU Message Protocol
> > +
> > +
> > +Required properties:
> > +- compatible: should be:
> > +  "fsl,imx8qxp-sc-pwrkey"
> > +  followed by "fsl,imx-sc-pwrkey";
> > +- linux,keycodes: See
> > +Documentation/devicetree/bindings/input/keys.txt
> > +Optional Properties:
> > +- wakeup-source: See
> > +Documentation/devicetree/bindings/power/wakeup-source.txt
> > +
> >  Example (imx8qxp):
> >  -
> >  aliases {
> > @@ -220,6 +231,13 @@ firmware {
> > compatible = "fsl,imx8qxp-sc-rtc";
> > };
> >
> > +   scu_pwrkey: scu-pwrkey {
> > +   compatible = "fsl,imx8qxp-sc-pwrkey", "fsl,imx-sc-
> pwrkey";
> > +   linux,keycode = ;
> > +   wakeup-source;
> 
> wakeup-source implies an interrupt property.

After further check, I confirm this "wakeup-source" property is NOT needed for 
SCU general interrupt
wakeup, remove it in V2. 

> 
> > +   status = "disabled";
> 
> Don't should status in examples.

Removed it in V2, please help review, thanks.

Anson

[PATCH V2 2/5] input: keyboard: imx_sc: Add i.MX system controller power key support

[Anson Huang]

i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and power key etc..

Adds i.MX system controller power key driver support, Linux kernel
has to communicate with system controller via MU (message unit) IPC
to get power key's status.

Signed-off-by: Anson Huang 
---
Changes since V1:
- remove "wakeup-source" property operation, scu power key uses generic 
scu irq,
  no need to have this property for device wakeup operation.
---
 drivers/input/keyboard/Kconfig |   7 ++
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/imx_sc_pwrkey.c | 169 +
 3 files changed, 177 insertions(+)
 create mode 100644 drivers/input/keyboard/imx_sc_pwrkey.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 2e6d288..3aaeb9c 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -469,6 +469,13 @@ config KEYBOARD_IMX
  To compile this driver as a module, choose M here: the
  module will be called imx_keypad.
 
+config KEYBOARD_IMX_SC_PWRKEY
+   tristate "IMX SCU Power Key Driver"
+   depends on IMX_SCU
+   help
+ This is the system controller powerkey driver for NXP i.MX SoCs with
+ system controller inside.
+
 config KEYBOARD_NEWTON
tristate "Newton keyboard"
select SERIO
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 9510325..9ea5585 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL)+= hil_kbd.o
 obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
 obj-$(CONFIG_KEYBOARD_IPAQ_MICRO)  += ipaq-micro-keys.o
 obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
+obj-$(CONFIG_KEYBOARD_IMX_SC_PWRKEY)   += imx_sc_pwrkey.o
 obj-$(CONFIG_KEYBOARD_HP6XX)   += jornada680_kbd.o
 obj-$(CONFIG_KEYBOARD_HP7XX)   += jornada720_kbd.o
 obj-$(CONFIG_KEYBOARD_LKKBD)   += lkkbd.o
diff --git a/drivers/input/keyboard/imx_sc_pwrkey.c 
b/drivers/input/keyboard/imx_sc_pwrkey.c
new file mode 100644
index 000..53aa9a4
--- /dev/null
+++ b/drivers/input/keyboard/imx_sc_pwrkey.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2019 NXP.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DEBOUNCE_TIME  100
+#define REPEAT_INTERVAL60
+
+#define SC_IRQ_BUTTON  1
+#define SC_IRQ_GROUP_WAKE  3
+#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
+
+struct imx_pwrkey_drv_data {
+   int keycode;
+   bool keystate;  /* 1: pressed, 0: release */
+   bool delay_check;
+   struct delayed_work check_work;
+   struct input_dev *input;
+};
+
+struct imx_sc_msg_pwrkey {
+   struct imx_sc_rpc_msg hdr;
+   u8 state;
+};
+static struct imx_pwrkey_drv_data *pdata;
+static struct imx_sc_ipc *pwrkey_ipc_handle;
+
+static int imx_sc_pwrkey_notify(struct notifier_block *nb,
+   unsigned long event, void *group)
+{
+   if ((event & SC_IRQ_BUTTON) && (*(u8 *)group == SC_IRQ_GROUP_WAKE)
+   && !pdata->delay_check) {
+   pdata->delay_check = 1;
+   schedule_delayed_work(>check_work,
+ msecs_to_jiffies(REPEAT_INTERVAL));
+   }
+
+   return 0;
+}
+
+static void imx_sc_check_for_events(struct work_struct *work)
+{
+   struct input_dev *input = pdata->input;
+   struct imx_sc_msg_pwrkey msg;
+   struct imx_sc_rpc_msg *hdr = 
+   bool state;
+
+   hdr->ver = IMX_SC_RPC_VERSION;
+   hdr->svc = IMX_SC_RPC_SVC_MISC;
+   hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
+   hdr->size = 1;
+
+   /*
+* Current SCU firmware does NOT have return value for
+* this API, that means it is always successful.
+*/
+   imx_scu_call_rpc(pwrkey_ipc_handle, , true);
+   state = msg.state;
+
+   if (!state && !pdata->keystate)
+   state = true;
+
+   if (state ^ pdata->keystate) {
+   pm_wakeup_event(input->dev.parent, 0);
+   pdata->keystate = !!state;
+   input_event(input, EV_KEY, pdata->keycode, !!state);
+   input_sync(input);
+   if (!state)
+   pdata->delay_check = 0;
+   pm_relax(pdata->input->dev.parent);
+   }
+
+   if (state)
+   schedule_delayed_work(>check_work,
+ msecs_to_jiffies(DEBOUNCE_TIME));
+}
+
+static struct notifier_block imx_sc_pwrkey_notifier = {
+   .notifier_call = imx_sc_pwrkey_notify,
+};
+
+static int imx_sc_pwrkey_probe(struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct input_dev *input;
+   

[PATCH V2 5/5] arm64: defconfig: Enable CONFIG_KEYBOARD_IMX_SC_PWRKEY as module

[Anson Huang]

Select CONFIG_KEYBOARD_IMX_SC_PWRKEY as module by default to
support i.MX8QXP power key driver.

Signed-off-by: Anson Huang 
---
No changes.
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 49bb3d4..8178737 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -313,6 +313,7 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_ADC=m
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_SNVS_PWRKEY=m
+CONFIG_KEYBOARD_IMX_SC_PWRKEY=m
 CONFIG_KEYBOARD_CROS_EC=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ATMEL_MXT=m
-- 
2.7.4

[PATCH V2 3/5] arm64: dts: imx8qxp: Add scu power key node

[Anson Huang]

Add scu power key node for i.MX8QXP, disabled by default as it
depends on board design.

Signed-off-by: Anson Huang 
---
Changes since V1:
- remove "wakeup-source" property, as it is NOT needed for scu mu 
interrupt;
---
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi 
b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
index 1133b41..85c5534 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -174,6 +175,12 @@
#power-domain-cells = <1>;
};
 
+   scu_pwrkey: scu-pwrkey {
+   compatible = "fsl,imx8qxp-sc-pwrkey", 
"fsl,imx-sc-pwrkey";
+   linux,keycode = ;
+   status = "disabled";
+   };
+
rtc: rtc {
compatible = "fsl,imx8qxp-sc-rtc";
};
-- 
2.7.4

[PATCH V2 4/5] arm64: dts: imx8qxp-mek: Enable scu power key

[Anson Huang]

Enable scu power key for i.MX8QXP MEK board.

Signed-off-by: Anson Huang 
---
No changes.
---
 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts 
b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 1946805..f3df5c4 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -234,3 +234,7 @@
 _dsp {
status = "okay";
 };
+
+_pwrkey {
+   status = "okay";
+};
-- 
2.7.4

[PATCH V2 1/5] dt-bindings: fsl: scu: add scu power key binding

[Anson Huang]

NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and power key event etc. management, Linux kernel
has to communicate with system controller via MU (message unit)
IPC to get power key event, add binding doc for i.MX system
controller power key driver.

Signed-off-by: Anson Huang 
---
Changes since V1:
- remove "wakeup-source" property, as it is NOT needed for SCU 
interrupt;
- remove "status" in example.
---
 .../devicetree/bindings/arm/freescale/fsl,scu.txt  | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt 
b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index c149fad..f93e2e4 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -157,6 +157,15 @@ Required properties:
 Optional properties:
 - timeout-sec: contains the watchdog timeout in seconds.
 
+Power key bindings based on SCU Message Protocol
+
+
+Required properties:
+- compatible: should be:
+  "fsl,imx8qxp-sc-pwrkey"
+  followed by "fsl,imx-sc-pwrkey";
+- linux,keycodes: See Documentation/devicetree/bindings/input/keys.txt
+
 Example (imx8qxp):
 -
 aliases {
@@ -220,6 +229,11 @@ firmware {
compatible = "fsl,imx8qxp-sc-rtc";
};
 
+   scu_pwrkey: scu-pwrkey {
+   compatible = "fsl,imx8qxp-sc-pwrkey", 
"fsl,imx-sc-pwrkey";
+   linux,keycode = ;
+   };
+
watchdog {
compatible = "fsl,imx8qxp-sc-wdt", "fsl,imx-sc-wdt";
timeout-sec = <60>;
-- 
2.7.4

[PATCH v7] perf diff: Report noisy for cycles diff

[Jin Yao]

This patch prints the stddev and hist for the cycles diff of
program block. It can help us to understand if the cycles
is noisy or not.

This patch is inspired by Andi Kleen's patch
https://lwn.net/Articles/600471/

We create new option '--cycles-hist'.

Example:

perf record -b ./div
perf record -b ./div
perf diff -c cycles

  # Baseline   [Program Block Range] Cycles 
Diff  Shared Object  Symbol
  #   
..  
.  
  #
  46.72% [div.c:40 -> div.c:40] 
   0  div[.] main
  46.72% [div.c:42 -> div.c:44] 
   0  div[.] main
  46.72% [div.c:42 -> div.c:39] 
   0  div[.] main
  20.54% [random_r.c:357 -> random_r.c:394] 
   1  libc-2.27.so   [.] __random_r
  20.54% [random_r.c:357 -> random_r.c:380] 
   0  libc-2.27.so   [.] __random_r
  20.54% [random_r.c:388 -> random_r.c:388] 
   0  libc-2.27.so   [.] __random_r
  20.54% [random_r.c:388 -> random_r.c:391] 
   0  libc-2.27.so   [.] __random_r
  17.04% [random.c:288 -> random.c:291] 
   0  libc-2.27.so   [.] __random
  17.04% [random.c:291 -> random.c:291] 
   0  libc-2.27.so   [.] __random
  17.04% [random.c:293 -> random.c:293] 
   0  libc-2.27.so   [.] __random
  17.04% [random.c:295 -> random.c:295] 
   0  libc-2.27.so   [.] __random
  17.04% [random.c:295 -> random.c:295] 
   0  libc-2.27.so   [.] __random
  17.04% [random.c:298 -> random.c:298] 
   0  libc-2.27.so   [.] __random
   8.40% [div.c:22 -> div.c:25] 
   0  div[.] compute_flag
   8.40% [div.c:27 -> div.c:28] 
   0  div[.] compute_flag
   5.14%   [rand.c:26 -> rand.c:27] 
   0  libc-2.27.so   [.] rand
   5.14%   [rand.c:28 -> rand.c:28] 
   0  libc-2.27.so   [.] rand
   2.15% [rand@plt+0 -> rand@plt+0] 
   0  div[.] rand@plt
   0.00%
  [kernel.kallsyms]  [k] __x86_indirect_thunk_rax
   0.00%   [do_mmap+714 -> do_mmap+732] 
 -10  [kernel.kallsyms]  [k] do_mmap
   0.00%   [do_mmap+737 -> do_mmap+765] 
   1  [kernel.kallsyms]  [k] do_mmap
   0.00%   [do_mmap+262 -> do_mmap+299] 
   0  [kernel.kallsyms]  [k] do_mmap
   0.00% [__x86_indirect_thunk_r15+0 -> __x86_indirect_thunk_r15+0] 
   7  [kernel.kallsyms]  [k] __x86_indirect_thunk_r15
   0.00%   [native_sched_clock+0 -> native_sched_clock+119] 
  -1  [kernel.kallsyms]  [k] native_sched_clock
   0.00%[native_write_msr+0 -> native_write_msr+16] 
 -13  [kernel.kallsyms]  [k] native_write_msr

When we enable the option '--cycles-hist', the output is

perf diff -c cycles --cycles-hist

  # Baseline   [Program Block Range] Cycles 
Diffstddev/Hist  Shared Object  Symbol
  #   
..  
.  .  
  #
  46.72% [div.c:40 -> div.c:40] 
   0  ± 37.8% ▁█▁▁██▁█   div[.] main
  46.72% [div.c:42 -> div.c:44] 
   0  ± 49.4% ▁▁▂█   div[.] main
  46.72% [div.c:42 -> div.c:39] 
   0  ± 24.1% ▃█▂▄▁▃▂▁   div[.] main
  20.54% [random_r.c:357 -> random_r.c:394] 
   1  ± 33.5% ▅▂▁█▃▁▂▁   libc-2.27.so   [.] __random_r
  20.54% [random_r.c:357 -> random_r.c:380] 
   0  ± 39.4% ▁▁█▁██▅▁   libc-2.27.so   [.] __random_r
  20.54% [random_r.c:388 -> random_r.c:388] 
   0 libc-2.27.so   [.] __random_r
  20.54% [random_r.c:388 -> random_r.c:391] 
   0  ± 41.2% ▁▃▁▂█▄▃▁   libc-2.27.so   [.] __random_r
  17.04% 

Re: [PATCH v2 1/3] dt-bindings: mtd: cadence-qspi:add support for Intel lgm-qspi

[Ramuthevar, Vadivel MuruganX]

Hi Rob,

 Thank you for the review and Acked-by.

On 2/9/2019 9:39 PM, Rob Herring wrote:

On Tue, 27 Aug 2019 11:58:25 +0800, "Ramuthevar,Vadivel MuruganX"  
wrote:

From: Ramuthevar Vadivel Murugan 

Add new vendor specific compatible string to check Intel's Lightning
Mountain(LGM) QSPI features enablement in cadence-quadspi driver.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
  Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 1 +
  1 file changed, 1 insertion(+)


Acked-by: Rob Herring 


Acked-by tag will be updated in next patch-set.

Best Regards
Vadivel

RE: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for ls1088a

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月2日 21:06
> To: Xiaowei Bao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> 
> Subject: Re: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for
> ls1088a
> 
> On Mon, Sep 02, 2019 at 11:17:15AM +0800, Xiaowei Bao wrote:
> > Add PCIe EP node for ls1088a to support EP mode.
> >
> > Signed-off-by: Xiaowei Bao 
> > ---
> > v2:
> >  - Remove the pf-offset proparty.
> > v3:
> >  - No change.
> >
> >  arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31
> ++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > index c676d07..da246ab 100644
> > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > @@ -483,6 +483,17 @@
> > status = "disabled";
> > };
> >
> > +   pcie_ep@340 {
> > +   compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> 
> Here you specify a fallback "fsl,ls-pcie-ep" that is removed by this series.
> 
> Besides that, this looks OK.

As explained, the "fsl,ls-pcie-ep" is needed, due to the u-boot will fixup the 
status
property base on this compatible, I think we reserve this compatible is 
helpfully,
if delate this compatible, I have to modify the code of bootloader.

Thanks 
XIaowei

> 
> Thanks,
> 
> Andrew Murray
> 
> > +   reg = <0x00 0x0340 0x0 0x0010
> > +  0x20 0x 0x8 0x>;
> > +   reg-names = "regs", "addr_space";
> > +   num-ib-windows = <24>;
> > +   num-ob-windows = <128>;
> > +   max-functions = /bits/ 8 <2>;
> > +   status = "disabled";
> > +   };
> > +
> > pcie@350 {
> > compatible = "fsl,ls1088a-pcie";
> > reg = <0x00 0x0350 0x0 0x0010   /* controller
> registers */
> > @@ -508,6 +519,16 @@
> > status = "disabled";
> > };
> >
> > +   pcie_ep@350 {
> > +   compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > +   reg = <0x00 0x0350 0x0 0x0010
> > +  0x28 0x 0x8 0x>;
> > +   reg-names = "regs", "addr_space";
> > +   num-ib-windows = <6>;
> > +   num-ob-windows = <8>;
> > +   status = "disabled";
> > +   };
> > +
> > pcie@360 {
> > compatible = "fsl,ls1088a-pcie";
> > reg = <0x00 0x0360 0x0 0x0010   /* controller
> registers */
> > @@ -533,6 +554,16 @@
> > status = "disabled";
> > };
> >
> > +   pcie_ep@360 {
> > +   compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > +   reg = <0x00 0x0360 0x0 0x0010
> > +  0x30 0x 0x8 0x>;
> > +   reg-names = "regs", "addr_space";
> > +   num-ib-windows = <6>;
> > +   num-ob-windows = <8>;
> > +   status = "disabled";
> > +   };
> > +
> > smmu: iommu@500 {
> > compatible = "arm,mmu-500";
> > reg = <0 0x500 0 0x80>;
> > --
> > 2.9.5
> >

Re: [RFC v3] vhost: introduce mdev based hardware vhost backend

[Tiwei Bie]

On Mon, Sep 02, 2019 at 12:15:05PM +0800, Jason Wang wrote:
> On 2019/8/28 下午1:37, Tiwei Bie wrote:
> > Details about this can be found here:
> > 
> > https://lwn.net/Articles/750770/
> > 
> > What's new in this version
> > ==
> > 
> > There are three choices based on the discussion [1] in RFC v2:
> > 
> > > #1. We expose a VFIO device, so we can reuse the VFIO container/group
> > >  based DMA API and potentially reuse a lot of VFIO code in QEMU.
> > > 
> > >  But in this case, we have two choices for the VFIO device interface
> > >  (i.e. the interface on top of VFIO device fd):
> > > 
> > >  A) we may invent a new vhost protocol (as demonstrated by the code
> > > in this RFC) on VFIO device fd to make it work in VFIO's way,
> > > i.e. regions and irqs.
> > > 
> > >  B) Or as you proposed, instead of inventing a new vhost protocol,
> > > we can reuse most existing vhost ioctls on the VFIO device fd
> > > directly. There should be no conflicts between the VFIO ioctls
> > > (type is 0x3B) and VHOST ioctls (type is 0xAF) currently.
> > > 
> > > #2. Instead of exposing a VFIO device, we may expose a VHOST device.
> > >  And we will introduce a new mdev driver vhost-mdev to do this.
> > >  It would be natural to reuse the existing kernel vhost interface
> > >  (ioctls) on it as much as possible. But we will need to invent
> > >  some APIs for DMA programming (reusing VHOST_SET_MEM_TABLE is a
> > >  choice, but it's too heavy and doesn't support vIOMMU by itself).
> > This version is more like a quick PoC to try Jason's proposal on
> > reusing vhost ioctls. And the second way (#1/B) in above three
> > choices was chosen in this version to demonstrate the idea quickly.
> > 
> > Now the userspace API looks like this:
> > 
> > - VFIO's container/group based IOMMU API is used to do the
> >DMA programming.
> > 
> > - Vhost's existing ioctls are used to setup the device.
> > 
> > And the device will report device_api as "vfio-vhost".
> > 
> > Note that, there are dirty hacks in this version. If we decide to
> > go this way, some refactoring in vhost.c/vhost.h may be needed.
> > 
> > PS. The direct mapping of the notify registers isn't implemented
> >  in this version.
> > 
> > [1] https://lkml.org/lkml/2019/7/9/101
> 
> 
> Thanks for the patch, see comments inline.
> 
> 
> > 
> > Signed-off-by: Tiwei Bie 
> > ---
> >   drivers/vhost/Kconfig  |   9 +
> >   drivers/vhost/Makefile |   3 +
> >   drivers/vhost/mdev.c   | 382 +
> >   include/linux/vhost_mdev.h |  58 ++
> >   include/uapi/linux/vfio.h  |   2 +
> >   include/uapi/linux/vhost.h |   8 +
> >   6 files changed, 462 insertions(+)
> >   create mode 100644 drivers/vhost/mdev.c
> >   create mode 100644 include/linux/vhost_mdev.h
[...]
> > +
> > +   break;
> > +   }
> > +   case VFIO_DEVICE_GET_REGION_INFO:
> > +   case VFIO_DEVICE_GET_IRQ_INFO:
> > +   case VFIO_DEVICE_SET_IRQS:
> > +   case VFIO_DEVICE_RESET:
> > +   ret = -EINVAL;
> > +   break;
> > +
> > +   case VHOST_MDEV_SET_STATE:
> > +   ret = vhost_set_state(vdpa, argp);
> > +   break;
> 
> 
> So this is used to start or stop the device. This means if userspace want to
> drive a network device, the API is not 100% compatible. Any blocker for
> this? E.g for SET_BACKEND, we can pass a fd and then identify the type of
> backend.

This is a legacy from the previous RFC code. I didn't try to
get rid of it while getting this POC to work. I can try to make
the vhost ioctls fully compatible with the existing userspace
if possible.

> 
> Another question is, how can user know the type of a device?

Maybe we can introduce an attribute in $UUID/ to tell the type.

> 
> 
> > +   case VHOST_GET_FEATURES:
> > +   ret = vhost_get_features(vdpa, argp);
> > +   break;
> > +   case VHOST_SET_FEATURES:
> > +   ret = vhost_set_features(vdpa, argp);
> > +   break;
> > +   case VHOST_GET_VRING_BASE:
> > +   ret = vhost_get_vring_base(vdpa, argp);
> > +   break;
> > +   default:
> > +   ret = vhost_dev_ioctl(>dev, cmd, argp);
> > +   if (ret == -ENOIOCTLCMD)
> > +   ret = vhost_vring_ioctl(>dev, cmd, argp);
> > +   }
> > +
> > +   return ret;
> > +}
[...]
> > +struct mdev_device;
> > +struct vhost_mdev;
> > +
> > +typedef int (*vhost_mdev_start_device_t)(struct vhost_mdev *vdpa);
> > +typedef int (*vhost_mdev_stop_device_t)(struct vhost_mdev *vdpa);
> > +typedef int (*vhost_mdev_set_features_t)(struct vhost_mdev *vdpa);
> > +typedef void (*vhost_mdev_notify_device_t)(struct vhost_mdev *vdpa, int 
> > queue_id);
> > +typedef u64 (*vhost_mdev_get_notify_addr_t)(struct vhost_mdev *vdpa, int 
> > queue_id);
> > +typedef u16 (*vhost_mdev_get_vring_base_t)(struct vhost_mdev *vdpa, int 
> > queue_id);
> > +typedef void 

Re: [PATCH v2 1/2] dt-bindings: phy: intel-sdxc-phy: Add YAML schema for LGM SDXC PHY

[Ramuthevar, Vadivel MuruganX]

Hi Rob,

Thank you for review comments.

On 2/9/2019 9:38 PM, Rob Herring wrote:

On Wed, Aug 28, 2019 at 08:43:14PM +0800, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

Add a YAML schema to use the host controller driver with the
SDXC PHY on Intel's Lightning Mountain SoC.

Signed-off-by: Ramuthevar Vadivel Murugan 

---
  .../bindings/phy/intel,lgm-sdxc-phy.yaml   | 52 ++
  .../devicetree/bindings/phy/intel,syscon.yaml  | 33 ++
  2 files changed, 85 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
  create mode 100644 Documentation/devicetree/bindings/phy/intel,syscon.yaml

diff --git a/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml 
b/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
new file mode 100644
index ..99647207b414
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,lgm-sdxc-phy.yaml
@@ -0,0 +1,52 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,lgm-sdxc-phy.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Intel Lightning Mountain(LGM) SDXC PHY Device Tree Bindings
+
+maintainers:
+  - Ramuthevar Vadivel Murugan 
+
+allOf:
+  - $ref: "intel,syscon.yaml"

You don't need this. It should be selected and applied by the compatible
string matching.

Agreed, fix it in the next patch.

+
+description: Binding for SDXC PHY
+
+properties:
+  compatible:
+const: intel,lgm-sdxc-phy
+
+  intel,syscon:
+description: phandle to the sdxc through syscon
+
+  clocks:
+maxItems: 1
+
+  clock-names:
+maxItems: 1
+
+  "#phy-cells":
+const: 0
+
+required:
+  - "#phy-cells"
+  - compatible
+  - intel,syscon
+  - clocks
+  - clock-names
+
+additionalProperties: false
+
+examples:
+  - |
+sdxc_phy: sdxc_phy {
+compatible = "intel,lgm-sdxc-phy";
+intel,syscon = <>;

Make this a child of the below node and then you don't need this.

If there's a register address range associated with this, then add a reg
property.


Thanks for comments,  I have defined herewith example

sysconf: chiptop@e002 {
            compatible = "intel,syscon";
            reg = <0xe002 0x100>;

            emmc_phy: emmc_phy {
                compatible = "intel,lgm-emmc-phy";
            intel,syscon = <>;
                clocks = <>;
                clock-names = "emmcclk";
                #phy-cells = <0>;
           };
};

Is this way need to add right?


+clocks = <>;
+clock-names = "sdxcclk";
+#phy-cells = <0>;
+};
+
+...
diff --git a/Documentation/devicetree/bindings/phy/intel,syscon.yaml 
b/Documentation/devicetree/bindings/phy/intel,syscon.yaml
new file mode 100644
index ..d0b78805e49f
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/intel,syscon.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: GPL-2.0
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/phy/intel,syscon.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Syscon for eMMC/SDXC PHY Device Tree Bindings

Nothing else in this h/w block? If there are other functions, then this
should not be in bindings/phy/.

Drop this one.

+
+maintainers:
+  - Ramuthevar Vadivel Murugan 
+
+properties:
+  compatible:
+const: intel,syscon

Needs to be more specific and reflect h/w blocks. 'syscon' is a Linux
thing to some extent.

Agreed, will drop it.

Best Regards
vadivel

+
+  reg:
+maxItems: 1
+
+  "#reset-cells":
+   const: 1
+
+required:
+  - compatible
+  - reg
+  - "#reset-cells"
+
+examples:
+  - |
+sysconf: chiptop@e002 {
+   compatible = "intel,syscon", "syscon";
+   reg = <0xe002 0x100>;
+   #reset-cells = <1>;
+};
--
2.11.0

RE: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月2日 20:55
> To: Xiaowei Bao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> 
> Subject: Re: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in
> pci_device_id table
> 
> On Mon, Sep 02, 2019 at 11:17:16AM +0800, Xiaowei Bao wrote:
> > Add LS1088a in pci_device_id table so that pci-epf-test can be used
> > for testing PCIe EP in LS1088a.
> >
> > Signed-off-by: Xiaowei Bao 
> > ---
> > v2:
> >  - No change.
> > v3:
> >  - No change.
> >
> >  drivers/misc/pci_endpoint_test.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/misc/pci_endpoint_test.c
> > b/drivers/misc/pci_endpoint_test.c
> > index 6e208a0..d531951 100644
> > --- a/drivers/misc/pci_endpoint_test.c
> > +++ b/drivers/misc/pci_endpoint_test.c
> > @@ -793,6 +793,7 @@ static const struct pci_device_id
> pci_endpoint_test_tbl[] = {
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
> > { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
> > +   { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x80c0) },
> 
> The Freescale PCI devices are the only devices in this table that don't have a
> define for their device ID. I think a define should be created for both of the
> device IDs above.

OK, but I only define in this file, I am not sure this can define in 
include/linux/pci_ids.h
file 

Thanks 
Xiaowei

> 
> Thanks,
> 
> Andrew Murray
> 
> > { PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
> > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
> >   .driver_data = (kernel_ulong_t)_data
> > --
> > 2.9.5
> >

RE: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月2日 20:46
> To: Xiaowei Bao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> 
> Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for
> ls1088a and ls2088a
> 
> On Mon, Sep 02, 2019 at 11:17:14AM +0800, Xiaowei Bao wrote:
> > Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > difference between LS1 and LS2 platform, so refactor the code of the
> > EP driver.
> >
> > Signed-off-by: Xiaowei Bao 
> > ---
> > v2:
> >  - This is a new patch for supporting the ls1088a and ls2088a platform.
> > v3:
> >  - Adjust the some struct assignment order in probe function.
> >
> >  drivers/pci/controller/dwc/pci-layerscape-ep.c | 72
> > +++---
> >  1 file changed, 53 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index 5f0cb99..723bbe5 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -20,27 +20,29 @@
> >
> >  #define PCIE_DBI2_OFFSET   0x1000  /* DBI2 base address*/
> >
> > -struct ls_pcie_ep {
> > -   struct dw_pcie  *pci;
> > -   struct pci_epc_features *ls_epc;
> > +#define to_ls_pcie_ep(x)   dev_get_drvdata((x)->dev)
> > +
> > +struct ls_pcie_ep_drvdata {
> > +   u32 func_offset;
> > +   const struct dw_pcie_ep_ops *ops;
> > +   const struct dw_pcie_ops*dw_pcie_ops;
> >  };
> >
> > -#define to_ls_pcie_ep(x)   dev_get_drvdata((x)->dev)
> > +struct ls_pcie_ep {
> > +   struct dw_pcie  *pci;
> > +   struct pci_epc_features *ls_epc;
> > +   const struct ls_pcie_ep_drvdata *drvdata; };
> >
> >  static int ls_pcie_establish_link(struct dw_pcie *pci)  {
> > return 0;
> >  }
> >
> > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > .start_link = ls_pcie_establish_link,  };
> >
> > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > -   { .compatible = "fsl,ls-pcie-ep",},
> > -   { },
> > -};
> > -
> >  static const struct pci_epc_features*  ls_pcie_ep_get_features(struct
> > dw_pcie_ep *ep)  { @@ -87,10 +89,39 @@ static int
> > ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > }
> >  }
> >
> > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> > +   u8 func_no)
> > +{
> > +   struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > +   struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > +
> > +   WARN_ON(func_no && !pcie->drvdata->func_offset);
> > +   return pcie->drvdata->func_offset * func_no; }
> > +
> > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > .ep_init = ls_pcie_ep_init,
> > .raise_irq = ls_pcie_ep_raise_irq,
> > .get_features = ls_pcie_ep_get_features,
> > +   .func_conf_select = ls_pcie_ep_func_conf_select, };
> > +
> > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > +   .ops = _pcie_ep_ops,
> > +   .dw_pcie_ops = _ls_pcie_ep_ops,
> > +};
> > +
> > +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > +   .func_offset = 0x2,
> > +   .ops = _pcie_ep_ops,
> > +   .dw_pcie_ops = _ls_pcie_ep_ops,
> > +};
> > +
> > +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > +   { .compatible = "fsl,ls1046a-pcie-ep", .data = _ep_drvdata },
> > +   { .compatible = "fsl,ls1088a-pcie-ep", .data = _ep_drvdata },
> > +   { .compatible = "fsl,ls2088a-pcie-ep", .data = _ep_drvdata },
> > +   { },
> 
> This removes support for "fsl,ls-pcie-ep" - was that intentional? If you do 
> plan
> to drop it please make sure you explain why in the commit message. See also
> my comments in your dt-binding patch.

In fact, the u-boot will fixup the status property to 'status = enabled' in PCI 
node of 
the DTS base on "fsl,ls-pcie-ep" compatible, so "fsl,ls-pcie-ep" is used, I 
used this
compatible before, because the driver only support the LS1046a, but this time, 
I add
the LS1088a and LS2088a support, and these two boards have some difference form
LS1046a, so I changed the compatible. I am not sure whether need to add 
"fsl,ls-pcie-ep"
in there, could you give some advice, thanks a lot.

Thanks 
Xiaowei
 
> 
> Thanks,
> 
> Andrew Murray
> 
> >  };
> >
> >  static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@ -103,7
> > +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> > int ret;
> >
> > 

Re: [PATCH RFC v4 0/15] sched,fair: flatten CPU controller runqueues

[Rik van Riel]

On Mon, 2019-09-02 at 12:53 +0200, Dietmar Eggemann wrote:
> On 22/08/2019 04:17, Rik van Riel wrote:

> > My main TODO items for the next period of time are likely going to
> > be testing, testing, and testing. I hope to find and flush out any
> > corner case I can find, and make sure performance does not regress
> > with any workloads, and hopefully improves some.
> 
> I did some testing with a small & simple rt-app based test-case:
> 
> 2 CPUs (rq->cpu_capacity_orig=1024), CPUfreq performance governor
> 
> 2 taskgroups /tg0 and /tg1
> 
> 6 CFS tasks (periodic, 8/16ms (runtime/period))
> 
> /tg0 (cpu.shares=1024) ran 4 tasks and /tg1 (cpu.shares=1024) ran 2
> tasks
> 
> (arm64 defconfig with !CONFIG_NUMA_BALANCING,
> !CONFIG_SCHED_AUTOGROUP)
> 
> ---
> 
> v5.2:
> 
> The 2 /tg1 tasks ran 8/16ms. The 4 /tg0 tasks ran 4/16ms in the
> beginning and then 8/16ms after the 2 /tg1 tasks did finish.
> 
> ---
> 
> v5.2 + v4:
> 
> There is no runtime/period pattern visible anymore. I see a lot of
> extra
> wakeup latency for those tasks though.
> 
> v5.2 + (v4 without 07/15, 08/15, 15/15) didn't change much.

One thing to keep in mind is that with the hierarchical
CPU controller code, you are always either comparing
tg0 and tg1 (of equal priority), or tasks of equal priority,
once the load balancer has equalized the load between CPUs.

With the flat CPU controller, the preemption code is comparing
sched_entities with other sched_entities that have 2x the
priority, similar to a nice level 0 entity compared against a
nice level ~3 task.

I do not know whether the code has ever given a predictable
scheduling pattern when the CPU is fully loaded with a mix of
different priority tasks that each want a 50% duty cycle.

But maybe it has, and I need to look into that :)

Figuring out exactly what the preemption code should do might
be a good discussion for Plumbers, too.

-- 
All Rights Reversed.


signature.asc
Description: This is a digitally signed message part

RE: [PATCH v3 05/11] dt-bindings: pci: layerscape-pci: add compatible strings for ls1088a and ls2088a

[Xiaowei Bao]

> -Original Message-
> From: Andrew Murray 
> Sent: 2019年9月2日 20:32
> To: Xiaowei Bao 
> Cc: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org; Leo
> Li ; kis...@ti.com; lorenzo.pieral...@arm.com; M.h.
> Lian ; Mingkai Hu ; Roy
> Zang ; jingooh...@gmail.com;
> gustavo.pimen...@synopsys.com; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linuxppc-...@lists.ozlabs.org;
> a...@arndb.de; gre...@linuxfoundation.org; Z.q. Hou
> 
> Subject: Re: [PATCH v3 05/11] dt-bindings: pci: layerscape-pci: add compatible
> strings for ls1088a and ls2088a
> 
> On Mon, Sep 02, 2019 at 11:17:10AM +0800, Xiaowei Bao wrote:
> > Add compatible strings for ls1088a and ls2088a.
> >
> > Signed-off-by: Xiaowei Bao 
> > ---
> > v2:
> >  - No change.
> > v3:
> >  - Use one valid combination of compatible strings.
> >
> >  Documentation/devicetree/bindings/pci/layerscape-pci.txt | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > index e20ceaa..762ae41 100644
> > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> > @@ -22,7 +22,9 @@ Required properties:
> >  "fsl,ls1043a-pcie"
> >  "fsl,ls1012a-pcie"
> >EP mode:
> > -   "fsl,ls1046a-pcie-ep", "fsl,ls-pcie-ep"
> > +   "fsl,ls1046a-pcie-ep" "fsl,ls-pcie-ep"
> > +   "fsl,ls1088a-pcie-ep" "fsl,ls-pcie-ep"
> > +   "fsl,ls2088a-pcie-ep" "fsl,ls-pcie-ep"
> 
> This isn't consistent with "[PATCH v3 09/11] PCI: layerscape: Add EP mode..."
> as that patch drops the fallback "fsl,ls-pcie-ep". Either the fallback must be
> preserved in the driver, or you need to drop it here.
> 
> What if there are existing users that depend on the fallback?
> 
> (I'm also not sure if that comma should have been dropped).

Hi Andrew,

Thanks for your comments, I lose the comma.

Thanks 
Xiaowei

> 
> Thanks,
> 
> Andrew Murray
> 
> >  - reg: base addresses and lengths of the PCIe controller register blocks.
> >  - interrupts: A list of interrupt outputs of the controller. Must contain 
> > an
> >entry for each entry in the interrupt-names property.
> > --
> > 2.9.5
> >

Re: [PATCH 0/6] Optimize the Spreadtrum SC27xx fuel gauge

[Baolin Wang]

Hi Sebastian,

On Tue, 3 Sep 2019 at 05:04, Sebastian Reichel  wrote:
>
> Hi,
>
> On Wed, Jul 31, 2019 at 06:00:22PM +0800, Baolin Wang wrote:
> > This patch set adds new attributes for userspace, and fixes the the
> > accuracy issue of coulomb counter calculation, as well as optimizing
> > the battery capacity calibration in some abnormal scenarios.
> >
> > Any comments are welcome. Thanks.
>
> Thanks, queued. I slightly modified patch 4, so that int_mode is
> 'bool' instead of 'int'.

OK. Thanks.

-- 
Baolin Wang
Best Regards

RE: [PATCH] arm64: dts: imx8mn-ddr4-evk: Enable GPIO LED

[Anson Huang]

Hi, Pavel

> On Mon 2019-09-02 16:45:38, Anson Huang wrote:
> > i.MX8MN DDR4 EVK board has a GPIO LED to indicate status, add support
> > for it.
> 
> LED maintainers want to be on the cc list...

The get_maintainer.pl does NOT show the LED maintainers...But I have added it
in V2.

> 
> > @@ -15,6 +15,18 @@
> > stdout-path = 
> > };
> >
> > +   leds {
> > +   compatible = "gpio-leds";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_gpio_led>;
> > +
> > +   status {
> > +   label = "status";
> > +   gpios = < 16 GPIO_ACTIVE_HIGH>;
> > +   default-state = "on";
> > +   };
> 
> And we should really standardize labels for user-controlled status LEDs.
> Mentioning color would be nice, for a start.

OK, I change the label to "yellow:status" in V2, please help review, thanks.

Anson

[PATCH V2] arm64: dts: imx8mn-ddr4-evk: Enable GPIO LED

[Anson Huang]

i.MX8MN DDR4 EVK board has a GPIO LED to indicate status,
add support for it.

Signed-off-by: Anson Huang 
---
Changes since V1:
- Mention color in the label.
---
 arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts 
b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
index b698061..bf1c097 100644
--- a/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts
@@ -15,6 +15,18 @@
stdout-path = 
};
 
+   gpio-leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio_led>;
+
+   status {
+   label = "yellow:status";
+   gpios = < 16 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+
reg_usdhc2_vmmc: regulator-usdhc2 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -54,6 +66,12 @@
>;
};
 
+   pinctrl_gpio_led: gpioledgrp {
+   fsl,pins = <
+   MX8MN_IOMUXC_NAND_READY_B_GPIO3_IO160x19
+   >;
+   };
+
pinctrl_i2c1: i2c1grp {
fsl,pins = <
MX8MN_IOMUXC_I2C1_SCL_I2C1_SCL  0x41c3
-- 
2.7.4

RE: [PATCH v5 0/6] Deliver vGPU display refresh event to userspace

[Zhang, Tina]

Hi,

Some people are asking whether the display refresh irq could be provided by 
qemu vfio display?

Some background: currently, we have two display timers. One is provided by QEMU 
UI and the other one is provided by the vgpu. The vgpu display framebuffer 
consumers (i.e. QEMU UIs) depend on the UI timer to consume the contents in the 
vgpu display framebuffer, meanwhile the display framebuffer producer (e.g. 
gvt-g display model) updates the framebuffer content according to the vblank 
timer provided by gpu vendor driver. Since these two timers are not synced, 
tearing could be noticed. 

So, theoretically to solve this tearing problem, we could have two options:

Option 1: Like what we have in this patch set: stop the QEMU UI timer and let 
both the framebuffer consumers and the framebuffer producer sync to the display 
refresh event provided by vendor driver. So, QEMU UI can do the refresh 
depending on this display refresh event to make sure to have a tear-free 
framebuffer.

Option 2: QEMU provides the emulated display refresh event to the vgpus 
provided by vendor driver. For vgpus, the display refresh event can be 
considered as the vblank event which is leveraged by guest window manager to do 
the plane update or mode-setting.

People are asking if option 2 could be a better choice.

Thanks.

BR,
Tina

> -Original Message-
> From: Zhang, Tina
> Sent: Friday, August 16, 2019 10:35 AM
> To: intel-gvt-...@lists.freedesktop.org
> Cc: Zhang, Tina ; kra...@redhat.com;
> alex.william...@redhat.com; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Yuan, Hang ; Lv, Zhiyuan
> 
> Subject: [PATCH v5 0/6] Deliver vGPU display refresh event to userspace
> 
> This series tries to send the vGPU display refresh event to user land.
> 
> Instead of delivering page flip events only or vblank events only, we choose
> to combine two of them, i.e. post display refresh event at vblanks and skip
> some of them when no page flip happens. Vblanks as upper bound are safe
> and skipping no-page-flip vblanks guarantees both trivial performance
> impacts and good user experience without screen tearing. Plus, we have the
> mask/unmask mechansim providing user space flexibility to switch between
> event-notified refresh and classic timer-based refresh.
> 
> In addition, there are some cases that guest app only uses one framebuffer
> for both drawing and display. In such case, guest OS won't do the plane page
> flip when the framebuffer is updated, thus the user land won't be notified
> about the updated framebuffer. Hence, in single framebuffer case, we apply
> a heuristic to determine whether it is the case or not. If it is, notify user 
> land
> when each vblank event triggers.
> 
> v5:
> - Introduce a vGPU display irq cap which can notify user space with
>   both primary and cursor plane update events through one eventfd. (Gerd &
> Alex)
> v4:
> - Deliver page flip event and single framebuffer refresh event bounded by
> display vblanks. (Kechen)
> v3:
> - Deliver display vblank event instead of page flip event. (Zhenyu)
> v2:
> - Use VFIO irq chain to get eventfds from userspace instead of adding a new
> ABI. (Alex)
> v1:
> - https://patchwork.kernel.org/cover/10962341/
> 
> Kechen Lu (2):
>   drm/i915/gvt: Deliver async primary plane page flip events at vblank
>   drm/i915/gvt: Add cursor plane reg update trap emulation handler
> 
> Tina Zhang (4):
>   vfio: Define device specific irq type capability
>   vfio: Introduce vGPU display irq type
>   drm/i915/gvt: Register vGPU display event irq
>   drm/i915/gvt: Deliver vGPU refresh event to userspace
> 
>  drivers/gpu/drm/i915/gvt/cmd_parser.c |   6 +-
>  drivers/gpu/drm/i915/gvt/display.c|  49 +-
>  drivers/gpu/drm/i915/gvt/display.h|   3 +
>  drivers/gpu/drm/i915/gvt/gvt.h|   6 +
>  drivers/gpu/drm/i915/gvt/handlers.c   |  32 +++-
>  drivers/gpu/drm/i915/gvt/hypercall.h  |   1 +
>  drivers/gpu/drm/i915/gvt/interrupt.c  |   7 +
>  drivers/gpu/drm/i915/gvt/interrupt.h  |   3 +
>  drivers/gpu/drm/i915/gvt/kvmgt.c  | 230 +-
>  drivers/gpu/drm/i915/gvt/mpt.h|  17 ++
>  include/uapi/linux/vfio.h |  40 -
>  11 files changed, 375 insertions(+), 19 deletions(-)
> 
> --
> 2.17.1

Re: [PATCH] net: sched: taprio: Fix potential integer overflow in taprio_set_picos_per_byte

[Vladimir Oltean]

On Tue, 3 Sep 2019 at 04:08, Gustavo A. R. Silva  wrote:
>
> Add suffix LL to constant 1000 in order to avoid a potential integer
> overflow and give the compiler complete information about the proper
> arithmetic to use. Notice that this constant is being used in a context
> that expects an expression of type s64, but it's currently evaluated
> using 32-bit arithmetic.
>
> Addresses-Coverity-ID: 1453459 ("Unintentional integer overflow")
> Fixes: f04b514c0ce2 ("taprio: Set default link speed to 10 Mbps in 
> taprio_set_picos_per_byte")
> Signed-off-by: Gustavo A. R. Silva 
> ---

Acked-by: Vladimir Oltean 

>  net/sched/sch_taprio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
> index 8d8bc2ec5cd6..956f837436ea 100644
> --- a/net/sched/sch_taprio.c
> +++ b/net/sched/sch_taprio.c
> @@ -966,7 +966,7 @@ static void taprio_set_picos_per_byte(struct net_device 
> *dev,
>
>  skip:
> picos_per_byte = div64_s64(NSEC_PER_SEC * 1000LL * 8,
> -  speed * 1000 * 1000);
> +  speed * 1000LL * 1000);
>
> atomic64_set(>picos_per_byte, picos_per_byte);
> netdev_dbg(dev, "taprio: set %s's picos_per_byte to: %lld, linkspeed: 
> %d\n",
> --
> 2.23.0
>

Re: [PATCH] net: hisilicon: Variable "reg_value" in function mdio_sc_cfg_reg_write() could be uninitialized

[kbuild test robot]

Hi Yizhuo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc7 next-20190902]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Yizhuo/net-hisilicon-Variable-reg_value-in-function-mdio_sc_cfg_reg_write-could-be-uninitialized/20190903-071544
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh 

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

All errors (new ones prefixed by >>):

   In file included from include/linux/acpi.h:15:0,
from drivers/net//ethernet/hisilicon/hns_mdio.c:6:
   drivers/net//ethernet/hisilicon/hns_mdio.c: In function 
'mdio_sc_cfg_reg_write':
>> drivers/net//ethernet/hisilicon/hns_mdio.c:158:20: error: 'struct 
>> hns_mdio_device' has no member named 'regmap'
   dev_err(mdio_dev->regmap->dev, "Fail to read from the register\n");
   ^
   include/linux/device.h:1499:11: note: in definition of macro 'dev_err'
 _dev_err(dev, dev_fmt(fmt), ##__VA_ARGS__)
  ^~~

vim +158 drivers/net//ethernet/hisilicon/hns_mdio.c

   > 6  #include 
 7  #include 
 8  #include 
 9  #include 
10  #include 
11  #include 
12  #include 
13  #include 
14  #include 
15  #include 
16  #include 
17  #include 
18  #include 
19  #include 
20  #include 
21  #include 
22  
23  #define MDIO_DRV_NAME "Hi-HNS_MDIO"
24  #define MDIO_BUS_NAME "Hisilicon MII Bus"
25  
26  #define MDIO_TIMEOUT100
27  
28  struct hns_mdio_sc_reg {
29  u16 mdio_clk_en;
30  u16 mdio_clk_dis;
31  u16 mdio_reset_req;
32  u16 mdio_reset_dreq;
33  u16 mdio_clk_st;
34  u16 mdio_reset_st;
35  };
36  
37  struct hns_mdio_device {
38  u8 __iomem *vbase;  /* mdio reg base address */
39  struct regmap *subctrl_vbase;
40  struct hns_mdio_sc_reg sc_reg;
41  };
42  
43  /* mdio reg */
44  #define MDIO_COMMAND_REG0x0
45  #define MDIO_ADDR_REG   0x4
46  #define MDIO_WDATA_REG  0x8
47  #define MDIO_RDATA_REG  0xc
48  #define MDIO_STA_REG0x10
49  
50  /* cfg phy bit map */
51  #define MDIO_CMD_DEVAD_M0x1f
52  #define MDIO_CMD_DEVAD_S0
53  #define MDIO_CMD_PRTAD_M0x1f
54  #define MDIO_CMD_PRTAD_S5
55  #define MDIO_CMD_OP_S   10
56  #define MDIO_CMD_ST_S   12
57  #define MDIO_CMD_START_B14
58  
59  #define MDIO_ADDR_DATA_M0x
60  #define MDIO_ADDR_DATA_S0
61  
62  #define MDIO_WDATA_DATA_M   0x
63  #define MDIO_WDATA_DATA_S   0
64  
65  #define MDIO_RDATA_DATA_M   0x
66  #define MDIO_RDATA_DATA_S   0
67  
68  #define MDIO_STATE_STA_B0
69  
70  enum mdio_st_clause {
71  MDIO_ST_CLAUSE_45 = 0,
72  MDIO_ST_CLAUSE_22
73  };
74  
75  enum mdio_c22_op_seq {
76  MDIO_C22_WRITE = 1,
77  MDIO_C22_READ = 2
78  };
79  
80  enum mdio_c45_op_seq {
81  MDIO_C45_WRITE_ADDR = 0,
82  MDIO_C45_WRITE_DATA,
83  MDIO_C45_READ_INCREMENT,
84  MDIO_C45_READ
85  };
86  
87  /* peri subctrl reg */
88  #define MDIO_SC_CLK_EN  0x338
89  #define MDIO_SC_CLK_DIS 0x33C
90  #define MDIO_SC_RESET_REQ   0xA38
91  #define MDIO_SC_RESET_DREQ  0xA3C
92  #define MDIO_SC_CLK_ST  0x531C
93  #define MDIO_SC_RESET_ST0x5A1C
94  
95  static void mdio_write_reg(u8 __iomem *base, u32 reg, u32 value)
96  {
97  writel_relaxed(value, base + reg);
98  }
99  
   100  #define MDIO_WRITE_REG(a, reg, value) \
   101  mdio_write_reg((a)->vbase, (reg), (value))
   102  
   103  static u32 mdio_read_reg(u8 __iomem *base, u32 reg)
   104  {
   105  return readl_relaxed(base + reg);
   106  }
   107  
   108  #define mdio_set_field(origin, mask, shift, val) \
   109  do { \
   110  (origin) &= (~((mask) << (shift))); \
   111  (origin) |= (((val) & (mask)) << (shift)); \
   112  } while (0)
   113  
   114  #define mdio_get_field(origin, mask, shift) (((origin) >> (shift)

RE: [PATCH 1/7] iommu/arm-smmu: add Nvidia SMMUv2 implementation

[Krishna Reddy]

>>> +ARM_SMMU_MATCH_DATA(nvidia_smmuv2, ARM_SMMU_V2, NVIDIA_SMMUV2);
 
>> The ARM MMU-500 implementation is unmodified.  It is the way the are 
>> integrated and used together(for interleaved accesses) is different from 
>> regular ARM MMU-500.
>> I have added it to get the model number and to be able differentiate the 
>> SMMU implementation in arm-smmu-impl.c.

>In that case, I would rather keep smmu->model representing the MMU-500 
>microarchitecture - 
>since you'll still want to pick up errata workarounds etc. for that - and 
>detect the Tegra integration via an explicit of_device_is_compatible()
> check in arm_smmu_impl_init().

Looks good to me. 

>For comparison, under ACPI we'd probably have to detect integration details by 
>looking at table headers, separately
> from the IORT "Model" field, so I'd prefer if the DT vs. ACPI handling didn't 
> diverge more than necessary.

ACPI support for T194 can be added based on need in subsequent patches. For 
now, I am updating it for DT support.

-KR

[PATCH] net: sched: taprio: Fix potential integer overflow in taprio_set_picos_per_byte

[Gustavo A. R. Silva]

Add suffix LL to constant 1000 in order to avoid a potential integer
overflow and give the compiler complete information about the proper
arithmetic to use. Notice that this constant is being used in a context
that expects an expression of type s64, but it's currently evaluated
using 32-bit arithmetic.

Addresses-Coverity-ID: 1453459 ("Unintentional integer overflow")
Fixes: f04b514c0ce2 ("taprio: Set default link speed to 10 Mbps in 
taprio_set_picos_per_byte")
Signed-off-by: Gustavo A. R. Silva 
---
 net/sched/sch_taprio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c
index 8d8bc2ec5cd6..956f837436ea 100644
--- a/net/sched/sch_taprio.c
+++ b/net/sched/sch_taprio.c
@@ -966,7 +966,7 @@ static void taprio_set_picos_per_byte(struct net_device 
*dev,
 
 skip:
picos_per_byte = div64_s64(NSEC_PER_SEC * 1000LL * 8,
-  speed * 1000 * 1000);
+  speed * 1000LL * 1000);
 
atomic64_set(>picos_per_byte, picos_per_byte);
netdev_dbg(dev, "taprio: set %s's picos_per_byte to: %lld, linkspeed: 
%d\n",
-- 
2.23.0

Re: [PATCH] acpi/hmat: ACPI_HMAT_MEMORY_PD_VALID is deprecated in ACPI-6.3

[Daniel Black]

On Mon, 2 Sep 2019 23:28:50 +0200
"Rafael J. Wysocki"  wrote:

> On Tue, Aug 6, 2019 at 6:24 AM Daniel Black  wrote:
> >
> > ACPI-6.3 corresponds to when hmat revision was bumped from
> > 1 to 2. In this version ACPI_HMAT_MEMORY_PD_VALID was
> > deprecated and made reserved.
> >
> > As such in revision 2+ we shouldn't be testing this flag.
> >
> > This is as per ACPI-6.3, 5.2.27.3, Table 5-145
> > "Memory Proximity Domain Attributes Structure"
> > for Flags.
> >
> > Signed-off-by: Daniel Black   
> 
> Keith, any comments?

FYI this was found when I was testing Tao Xu's qemu implementation of HMAT 
ACPI-6.3 which has no implementation of  ACPI_HMAT_MEMORY_PD_VALID.

Current patch implementing Memory Proximity Domain Attributes Structure:
https://patchwork.kernel.org/patch/11125301/

Re: [kbuild-all] [tip: x86/vmware] input/vmmouse: Update the backdoor call with support for new instructions

[Philip Li]

On Mon, Sep 02, 2019 at 11:36:51AM +0200, Borislav Petkov wrote:
> On Mon, Sep 02, 2019 at 09:13:42AM +0800, Philip Li wrote:
> > Thanks Boris, it is applied, and will take effect soon.
> 
> Seems to has taken effect. I got the first build report.
thanks for the info, Boris, glad to know this.

> 
> Thx!
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> Good mailing practices for 400: avoid top-posting and trim the reply.

RE: [PATCH] HID: hyperv: Use in-place iterator API in the channel callback

[Dexuan Cui]

> -Original Message-
> From: Dexuan Cui 
> Sent: Monday, August 19, 2019 7:57 PM
> To: ji...@kernel.org; benjamin.tissoi...@redhat.com;
> linux-in...@vger.kernel.org; linux-hyp...@vger.kernel.org; Stephen
> Hemminger ; Sasha Levin
> ; sas...@kernel.org; Haiyang Zhang
> ; KY Srinivasan ; Michael
> Kelley 
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; Dexuan Cui
> 
> Subject: [PATCH] HID: hyperv: Use in-place iterator API in the channel 
> callback
> 
> Simplify the ring buffer handling with the in-place API.
> 
> Also avoid the dynamic allocation and the memory leak in the channel
> callback function.
> 
> Signed-off-by: Dexuan Cui 
> ---
> 
> Hi Jiri, Benjamin, can this patch go through Sasha's hyperv tree:
> https://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
> 
> This is a purely Hyper-V specific change.

Hi Jiri, Benjamin,
Are you OK if this patch for the Hyper-V HID driver goes through the Hyper-V
tree maintained by Sasha Levin? It's a purely Hyper-V change, and I have
been using the patch for several months and there is no regression.

Thanks,
-- Dexuan

Re: WARNING in __mark_chain_precision (2)

[Alexei Starovoitov]

On Thu, Aug 29, 2019 at 4:28 AM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:47ee6e86 selftests/bpf: remove wrong nhoff in flow dissect..
> git tree:   bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=16227fa660
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d4cf1ffb87d590d7
> dashboard link: https://syzkaller.appspot.com/bug?extid=c8d66267fd2b5955287e
> compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=10d26ebc60
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=127805ca60
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+c8d66267fd2b59552...@syzkaller.appspotmail.com
>
> [ cut here ]
> verifier backtracking bug
> WARNING: CPU: 0 PID: 8795 at kernel/bpf/verifier.c:1782
> __mark_chain_precision+0x197a/0x1ea0 kernel/bpf/verifier.c:1782

fyi
I found some time to debug it.
The following program will be incorrectly rejected
due to precision tracking bug.
(b7) r2 = 0
(bf) r3 = r10
(16) if w3 == 0xf6fffdfd goto pc+0
(7a) *(u64 *)(r3 -16) = -8
(79) r4 = *(u64 *)(r10 -16)
(b7) r6 = -1
(2d) if r4 > r6 goto pc+5

Still thinking how to fix it cleanly.