date:20201102

Hi Diana,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   b7cbaf59f62f8ab8f157698f9e31642bff525bd0
commit: cc0ee20bd96971c10eba9a83ecf1c0733078a083 vfio/fsl-mc: trigger an 
interrupt via eventfd
date:   3 weeks ago
config: arm64-randconfig-r026-20201101 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
235dfcf70abca65dba5d80f1a42d1485bab8980c)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cc0ee20bd96971c10eba9a83ecf1c0733078a083
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout cc0ee20bd96971c10eba9a83ecf1c0733078a083
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

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

All warnings (new ones prefixed by >>):

>> drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:16:5: warning: no previous prototype 
>> for function 'vfio_fsl_mc_irqs_allocate' [-Wmissing-prototypes]
   int vfio_fsl_mc_irqs_allocate(struct vfio_fsl_mc_device *vdev)
   ^
   drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:16:1: note: declare 'static' if the 
function is not intended to be used outside of this translation unit
   int vfio_fsl_mc_irqs_allocate(struct vfio_fsl_mc_device *vdev)
   ^
   static 
   drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:121:8: error: implicit declaration of 
function 'fsl_mc_populate_irq_pool' [-Werror,-Wimplicit-function-declaration]
   ret = fsl_mc_populate_irq_pool(mc_cont,
 ^
   drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c:122:4: error: use of undeclared 
identifier 'FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS'
   FSL_MC_IRQ_POOL_MAX_TOTAL_IRQS);
   ^
   1 warning and 2 errors generated.

vim +/vfio_fsl_mc_irqs_allocate +16 drivers/vfio/fsl-mc/vfio_fsl_mc_intr.c

15  
  > 16  int vfio_fsl_mc_irqs_allocate(struct vfio_fsl_mc_device *vdev)
17  {
18  struct fsl_mc_device *mc_dev = vdev->mc_dev;
19  struct vfio_fsl_mc_irq *mc_irq;
20  int irq_count;
21  int ret, i;
22  
23  /* Device does not support any interrupt */
24  if (mc_dev->obj_desc.irq_count == 0)
25  return 0;
26  
27  /* interrupts were already allocated for this device */
28  if (vdev->mc_irqs)
29  return 0;
30  
31  irq_count = mc_dev->obj_desc.irq_count;
32  
33  mc_irq = kcalloc(irq_count, sizeof(*mc_irq), GFP_KERNEL);
34  if (!mc_irq)
35  return -ENOMEM;
36  
37  /* Allocate IRQs */
38  ret = fsl_mc_allocate_irqs(mc_dev);
39  if (ret) {
40  kfree(mc_irq);
41  return ret;
42  }
43  
44  for (i = 0; i < irq_count; i++) {
45  mc_irq[i].count = 1;
46  mc_irq[i].flags = VFIO_IRQ_INFO_EVENTFD;
47  }
48  
49  vdev->mc_irqs = mc_irq;
50  
51  return 0;
52  }
53  

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


.config.gz
Description: application/gzip

Re: [PATCH 5.9 24/74] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()

2020-11-02 Thread Hans-Peter Jansen

Am Dienstag, 3. November 2020, 07:35:29 CET schrieb Greg Kroah-Hartman:
> On Mon, Nov 02, 2020 at 10:34:08PM +0100, Hans-Peter Jansen wrote:
> 
> Ah, that kind of makes sense, I saw odd things with these patches that I
> couldn't figure out.
> 
> So, is there a symlink that I need to add/fix to resolve this?

rm tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S should 
do the trick.

Cheers,
Pete

Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL

On Mon, Nov 02, 2020 at 09:48:25PM +0100, Christian König wrote:
> Am 03.11.20 um 07:53 schrieb Greg KH:
> > On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote:
> > > Am 02.11.20 um 20:43 schrieb Alex Deucher:
> > > > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma  
> > > > wrote:
> > > > > Initializing global variable to 0 or NULL is not necessary and should
> > > > > be avoided. Issue reported by checkpatch script as:
> > > > > ERROR: do not initialise globals to 0 (or NULL).
> > > > I agree that this is technically correct, but a lot of people don't
> > > > seem to know that so we get a lot of comments about this code for the
> > > > variables that are not explicitly set.  Seems less confusing to
> > > > initialize them even if it not necessary.  I don't have a particularly
> > > > strong opinion on it however.
> > > Agree with Alex.
> > > 
> > > Especially for the module parameters we should have a explicit init value
> > > for documentation purposes, even when it is 0.
> > Why is this one tiny driver somehow special compared to the entire rest
> > of the kernel?  (hint, it isn't...)
> 
> And it certainly shouldn't :)
> 
> > Please follow the normal coding style rules, there's no reason to ignore
> > them unless you like to constantly reject patches like this that get
> > sent to you.
> 
> Yeah, that's a rather good point.
> 
> Not a particular strong opinion on this either, but when something global is
> set to 0 people usually do this to emphases that it is important that it is
> zero.

Again, no, that's not what we have been doing in the kernel for the past
20+ years.  If you do not set it to anything, we all know it is
important for it to be set to 0.  Otherwise we would explicitly set it
to something else.  And if we don't care, then that too doesn't matter
so we let it be 0 by not initializing it, it doesn't matter.

I think this very change is what started the whole "kernel janitor"
movement all those years ago, because it was easily proven that this
simple change saved both time and memory.

This shouldn't even be an argument we are having anymore...

thanks,

greg k-h

Re: [PATCH] ath10k: Introduce a devicetree quirk to skip host cap QMI requests

2020-11-02 Thread Amit Pundir

Hi Rob, Bjorn, Kalle,

On Thu, 29 Oct 2020 at 19:10, Bjorn Andersson
 wrote:
>
> On Tue 29 Sep 14:08 CDT 2020, Rob Herring wrote:
>
> > On Fri, Sep 25, 2020 at 11:59:41PM +0530, Amit Pundir wrote:
> > > There are firmware versions which do not support host capability
> > > QMI request. We suspect either the host cap is not implemented or
> > > there may be firmware specific issues, but apparently there seem
> > > to be a generation of firmware that has this particular behavior.
> > >
> > > For example, firmware build on Xiaomi Poco F1 (sdm845) phone:
> > > "QC_IMAGE_VERSION_STRING=WLAN.HL.2.0.c3-00257-QCAHLSWMTPLZ-1"
> > >
> > > If we do not skip the host cap QMI request on Poco F1, then we
> > > get a QMI_ERR_MALFORMED_MSG_V01 error message in the
> > > ath10k_qmi_host_cap_send_sync(). But this error message is not
> > > fatal to the firmware nor to the ath10k driver and we can still
> > > bring up the WiFi services successfully if we just ignore it.
> > >
> > > Hence introducing this DeviceTree quirk to skip host capability
> > > QMI request for the firmware versions which do not support this
> > > feature.
> >
> > So if you change the WiFi firmware, you may force a DT change too. Those
> > are pretty independent things otherwise.
> >
>
> Yes and that's not good. But I looked at somehow derive this from
> firmware version numbers etc and it's not working out, so I'm out of
> ideas for alternatives.
>
> > Why can't you just always ignore this error? If you can't deal with this
> > entirely in the driver, then it should be part of the WiFi firmware so
> > it's always in sync.
> >
>
> Unfortunately the firmware versions I've hit this problem on has gone
> belly up when receiving this request, that's why I asked Amit to add a
> flag to skip it.

So what is next for this DT quirk?

I'm OK to go back to my previous of_machine_is_compatible()
device specific hack, for now,
https://patchwork.kernel.org/project/linux-wireless/patch/1600328501-8832-1-git-send-email-amit.pun...@linaro.org/
till we have a reasonable fix in place or receive a vendor firmware
drop which fixes this problem (which I believe is highly unlikely
though, for this 2+ years old device).

Regards,
Amit Pundir

>
> That said, in the devices I've hit this I've managed to get newer
> firmware working, which doesn't have either problem.
>
> Regards,
> Bjorn

RE: [PATCH V2] arm64: dts: imx8mp-evk: add CAN support

2020-11-02 Thread Joakim Zhang


> -Original Message-
> From: Krzysztof Kozlowski 
> Sent: 2020年11月3日 15:39
> To: Joakim Zhang 
> Cc: shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> dl-linux-imx ; devicet...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> m...@pengutronix.de
> Subject: Re: [PATCH V2] arm64: dts: imx8mp-evk: add CAN support
> 
> On Tue, Nov 03, 2020 at 01:23:12AM +, Joakim Zhang wrote:
> >
> > > -Original Message-
> > > From: Krzysztof Kozlowski 
> > > Sent: 2020年11月2日 16:29
> > > To: Joakim Zhang 
> > > Cc: shawn...@kernel.org; s.ha...@pengutronix.de;
> feste...@gmail.com;
> > > dl-linux-imx ; devicet...@vger.kernel.org;
> > > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > > m...@pengutronix.de
> > > Subject: Re: [PATCH V2] arm64: dts: imx8mp-evk: add CAN support
> > >
> > > On Mon, Nov 02, 2020 at 10:16:34AM +0800, Joakim Zhang wrote:
> > > > Add CAN device node and pinctrl on i.MX8MP evk board.
> > > >
> > > > Signed-off-by: Joakim Zhang 
> > > > ---
> > > > ChangeLogs:
> > > > V1->V2:
> > > > * add missing space before '=',
> > > > fsl,clk-source= /bits/ 8 <0> -> fsl,clk-source = /bits/ 8 <0>
> > > > ---
> > > >  arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 62
> > > 
> > > >  arch/arm64/boot/dts/freescale/imx8mp.dtsi| 30 ++
> > > >  2 files changed, 92 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> > > > b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> > > > index 908b92bb4dcd..b10dce8767a4 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> > > > +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> > > > @@ -33,6 +33,28 @@
> > > >   <0x1 0x 0 0xc000>;
> > > > };
> > > >
> > > > +   reg_can1_stby: regulator-can1-stby {
> > > > +   compatible = "regulator-fixed";
> > > > +   regulator-name = "can1-stby";
> > > > +   pinctrl-names = "default";
> > > > +   pinctrl-0 = <_flexcan1_reg>;
> > > > +   regulator-min-microvolt = <330>;
> > > > +   regulator-max-microvolt = <330>;
> > > > +   gpio = < 5 GPIO_ACTIVE_HIGH>;
> > > > +   enable-active-high;
> > > > +   };
> > > > +
> > > > +   reg_can2_stby: regulator-can2-stby {
> > > > +   compatible = "regulator-fixed";
> > > > +   regulator-name = "can2-stby";
> > > > +   pinctrl-names = "default";
> > > > +   pinctrl-0 = <_flexcan2_reg>;
> > > > +   regulator-min-microvolt = <330>;
> > > > +   regulator-max-microvolt = <330>;
> > > > +   gpio = < 27 GPIO_ACTIVE_HIGH>;
> > > > +   enable-active-high;
> > > > +   };
> > > > +
> > > > reg_usdhc2_vmmc: regulator-usdhc2 {
> > > > compatible = "regulator-fixed";
> > > > pinctrl-names = "default";
> > > > @@ -45,6 +67,20 @@
> > > > };
> > > >  };
> > > >
> > > > + {
> > > > +   pinctrl-names = "default";
> > > > +   pinctrl-0 = <_flexcan1>;
> > > > +   xceiver-supply = <_can1_stby>;
> > > > +   status = "okay";
> > > > +};
> > > > +
> > > > + {
> > > > +   pinctrl-names = "default";
> > > > +   pinctrl-0 = <_flexcan2>;
> > > > +   xceiver-supply = <_can2_stby>;
> > > > +   status = "disabled";/* can2 pin conflict with pdm */ };
> > > > +
> > > >   {
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <_fec>;
> > > > @@ -144,6 +180,32 @@
> > > > >;
> > > > };
> > > >
> > > > +   pinctrl_flexcan1: flexcan1grp {
> > > > +   fsl,pins = <
> > > > +   MX8MP_IOMUXC_SPDIF_RX__CAN1_RX  0x154
> > > > +   MX8MP_IOMUXC_SPDIF_TX__CAN1_TX  0x154
> > > > +   >;
> > > > +   };
> > > > +
> > > > +   pinctrl_flexcan2: flexcan2grp {
> > > > +   fsl,pins = <
> > > > +   MX8MP_IOMUXC_SAI5_MCLK__CAN2_RX
> 0x154
> > > > +   MX8MP_IOMUXC_SAI5_RXD3__CAN2_TX 0x154
> > > > +   >;
> > > > +   };
> > > > +
> > > > +   pinctrl_flexcan1_reg: flexcan1reggrp {
> > > > +   fsl,pins = <
> > > > +   MX8MP_IOMUXC_SPDIF_EXT_CLK__GPIO5_IO05  0x154
> /*
> > > CAN1_STBY */
> > > > +   >;
> > > > +   };
> > > > +
> > > > +   pinctrl_flexcan2_reg: flexcan2reggrp {
> > > > +   fsl,pins = <
> > > > +   MX8MP_IOMUXC_SAI2_MCLK__GPIO4_IO27  0x154
> > > /* CAN2_STBY */
> > > > +   >;
> > > > +   };
> > > > +
> > > > pinctrl_gpio_led: gpioledgrp {
> > > > fsl,pins = <
> > > > MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16   0x19
> > > > diff --git

[PATCH v2] iio: adc: rockchip_saradc: fix missing clk_disable_unprepare() on error in rockchip_saradc_resume

Fix the missing clk_disable_unprepare() of info->pclk
before return from rockchip_saradc_resume in the error
handling case when fails to prepare and enable info->clk.

Fixes: 44d6f2ef94f9 ("iio: adc: add driver for Rockchip saradc")
Signed-off-by: Qinglang Miao 
---
 drivers/iio/adc/rockchip_saradc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/iio/adc/rockchip_saradc.c 
b/drivers/iio/adc/rockchip_saradc.c
index 1f3d7d639..5eb566274 100644
--- a/drivers/iio/adc/rockchip_saradc.c
+++ b/drivers/iio/adc/rockchip_saradc.c
@@ -461,9 +461,10 @@ static int rockchip_saradc_resume(struct device *dev)
return ret;
 
ret = clk_prepare_enable(info->clk);
-   if (ret)
+   if (ret) {
+   clk_disable_unprepare(info->pclk);
return ret;
-
+   }
return ret;
 }
 #endif
-- 
2.23.0

[PATCH v2] spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe

Fix the missing clk_disable_unprepare() before return
from mt7621_spi_probe in the error handling case.

Fixes: cbd66c626e16 ("spi: mt7621: Move SPI driver out of staging")
Signed-off-by: Qinglang Miao 
---
 drivers/spi/spi-mt7621.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/spi/spi-mt7621.c b/drivers/spi/spi-mt7621.c
index 2c3b7a2a1..2cdae7994 100644
--- a/drivers/spi/spi-mt7621.c
+++ b/drivers/spi/spi-mt7621.c
@@ -353,6 +353,7 @@ static int mt7621_spi_probe(struct platform_device *pdev)
master = spi_alloc_master(>dev, sizeof(*rs));
if (!master) {
dev_info(>dev, "master allocation failed\n");
+   clk_disable_unprepare(clk);
return -ENOMEM;
}
 
@@ -377,6 +378,7 @@ static int mt7621_spi_probe(struct platform_device *pdev)
ret = device_reset(>dev);
if (ret) {
dev_err(>dev, "SPI reset failed!\n");
+   clk_disable_unprepare(clk);
return ret;
}
 
-- 
2.23.0

Re: [PATCH v2] serial: txx9: add missing platform_driver_unregister() on error in serial_txx9_init

2020-11-02 Thread Greg Kroah-Hartman

On Tue, Nov 03, 2020 at 03:33:41PM +0800, Qinglang Miao wrote:
> Add the missing platform_driver_unregister() before return
> from serial_txx9_init in the error handling case when failed
> to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI
> defined.
> 
> Fixes: ab4382d27412 ("tty: move drivers/serial/ to drivers/tty/serial/")
> Signed-off-by: Qinglang Miao 
> ---
>  drivers/tty/serial/serial_txx9.c | 3 +++
>  1 file changed, 3 insertions(+)

What changed from v1?  Always put that below the --- line.

Please fix up and send v3.

thanks,

greg k-h

Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL

2020-11-02 Thread Christian König


Am 03.11.20 um 07:53 schrieb Greg KH:

On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote:

Am 02.11.20 um 20:43 schrieb Alex Deucher:

On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma  wrote:

Initializing global variable to 0 or NULL is not necessary and should
be avoided. Issue reported by checkpatch script as:
ERROR: do not initialise globals to 0 (or NULL).

I agree that this is technically correct, but a lot of people don't
seem to know that so we get a lot of comments about this code for the
variables that are not explicitly set.  Seems less confusing to
initialize them even if it not necessary.  I don't have a particularly
strong opinion on it however.

Agree with Alex.

Especially for the module parameters we should have a explicit init value
for documentation purposes, even when it is 0.

Why is this one tiny driver somehow special compared to the entire rest
of the kernel?  (hint, it isn't...)


And it certainly shouldn't :)


Please follow the normal coding style rules, there's no reason to ignore
them unless you like to constantly reject patches like this that get
sent to you.


Yeah, that's a rather good point.

Not a particular strong opinion on this either, but when something 
global is set to 0 people usually do this to emphases that it is 
important that it is zero.


Regards,
Christian.



thnaks,

greg k-h

[PATCH v2] spi: bcm63xx-hsspi: fix missing clk_disable_unprepare() on error in bcm63xx_hsspi_resume

Fix the missing clk_disable_unprepare() before return
from bcm63xx_hsspi_resume in the error handling case when
fails to prepare and enable bs->pll_clk.

Fixes: 0fd85869c2a9 ("spi/bcm63xx-hsspi: keep pll clk enabled")
Signed-off-by: Qinglang Miao 
---
 drivers/spi/spi-bcm63xx-hsspi.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/spi/spi-bcm63xx-hsspi.c b/drivers/spi/spi-bcm63xx-hsspi.c
index 9909b18f3..1f08d7553 100644
--- a/drivers/spi/spi-bcm63xx-hsspi.c
+++ b/drivers/spi/spi-bcm63xx-hsspi.c
@@ -494,8 +494,10 @@ static int bcm63xx_hsspi_resume(struct device *dev)
 
if (bs->pll_clk) {
ret = clk_prepare_enable(bs->pll_clk);
-   if (ret)
+   if (ret) {
+   clk_disable_unprepare(bs->clk);
return ret;
+   }
}
 
spi_master_resume(master);
-- 
2.23.0

[PATCH net-next v2 1/2][RESEND] net: phy: adin: disable diag clock & disable standby mode in config_aneg

2020-11-02 Thread Alexandru Ardelean

When the PHY powers up, the diagnostics clock isn't enabled (bit 2 in
register PHY_CTRL_1 (0x0012)).
Also, the PHY is not in standby mode, so bit 13 in PHY_CTRL_3 (0x0017) is
always set at power up.

The standby mode and the diagnostics clock are both meant to be for the
cable diagnostics feature of the PHY (in phylib this would be equivalent to
the cable-test support), and for the frame-generator feature of the PHY.

In standby mode, the PHY doesn't negotiate links or manage links.

To use the cable diagnostics/test (or frame-generator), the PHY must be
first set in standby mode, so that the link operation doesn't interfere.
Then, the diagnostics clock must be enabled.

For the cable-test feature, when the operation finishes, the PHY goes into
PHY_UP state, and the config_aneg hook is called.

For the ADIN PHY, we need to make sure that during autonegotiation
configuration/setup the PHY is removed from standby mode and the
diagnostics clock is disabled, so that normal operation is resumed.

This change does that by moving the set of the ADIN1300_LINKING_EN bit (2)
in the config_aneg (to disable standby mode).
Previously, this was set in the downshift setup, because the downshift
retry value and the ADIN1300_LINKING_EN are in the same register.

And the ADIN1300_DIAG_CLK_EN bit (13) is cleared, to disable the
diagnostics clock.

Reviewed-by: Andrew Lunn 
Signed-off-by: Alexandru Ardelean 
---

This is a re-send of:
 
https://lore.kernel.org/netdev/20201022074551.11520-1-alexandru.ardel...@analog.com/

Added 'Reviewed-by: Andrew Lunn ' to both patches.

 drivers/net/phy/adin.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 5bc3926c52f0..619d36685b5d 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -23,6 +23,7 @@
 #define ADIN1300_PHY_CTRL1 0x0012
 #define   ADIN1300_AUTO_MDI_EN BIT(10)
 #define   ADIN1300_MAN_MDIX_EN BIT(9)
+#define   ADIN1300_DIAG_CLK_EN BIT(2)
 
 #define ADIN1300_RX_ERR_CNT0x0014
 
@@ -326,10 +327,9 @@ static int adin_set_downshift(struct phy_device *phydev, 
u8 cnt)
return -E2BIG;
 
val = FIELD_PREP(ADIN1300_DOWNSPEED_RETRIES_MSK, cnt);
-   val |= ADIN1300_LINKING_EN;
 
rc = phy_modify(phydev, ADIN1300_PHY_CTRL3,
-   ADIN1300_LINKING_EN | ADIN1300_DOWNSPEED_RETRIES_MSK,
+   ADIN1300_DOWNSPEED_RETRIES_MSK,
val);
if (rc < 0)
return rc;
@@ -560,6 +560,14 @@ static int adin_config_aneg(struct phy_device *phydev)
 {
int ret;
 
+   ret = phy_clear_bits(phydev, ADIN1300_PHY_CTRL1, ADIN1300_DIAG_CLK_EN);
+   if (ret < 0)
+   return ret;
+
+   ret = phy_set_bits(phydev, ADIN1300_PHY_CTRL3, ADIN1300_LINKING_EN);
+   if (ret < 0)
+   return ret;
+
ret = adin_config_mdix(phydev);
if (ret)
return ret;
-- 
2.17.1

[PATCH net-next v2 2/2][RESEND] net: phy: adin: implement cable-test support

2020-11-02 Thread Alexandru Ardelean

The ADIN1300/ADIN1200 support cable diagnostics using TDR.

The cable fault detection is automatically run on all four pairs looking at
all combinations of pair faults by first putting the PHY in standby (clear
the LINK_EN bit, PHY_CTRL_3 register, Address 0x0017) and then enabling the
diagnostic clock (set the DIAG_CLK_EN bit, PHY_CTRL_1 register, Address
0x0012).

Cable diagnostics can then be run (set the CDIAG_RUN bit in the
CDIAG_RUN register, Address 0xBA1B). The results are reported for each pair
in the cable diagnostics results registers, CDIAG_DTLD_RSLTS_0,
CDIAG_DTLD_RSLTS_1, CDIAG_DTLD_RSLTS_2, and CDIAG_DTLD_RSLTS_3, Address
0xBA1D to Address 0xBA20).

The distance to the first fault for each pair is reported in the cable
fault distance registers, CDIAG_FLT_DIST_0, CDIAG_FLT_DIST_1,
CDIAG_FLT_DIST_2, and CDIAG_FLT_DIST_3, Address 0xBA21 to Address 0xBA24).

This change implements support for this using phylib's cable-test support.

Reviewed-by: Andrew Lunn 
Signed-off-by: Alexandru Ardelean 
---
 drivers/net/phy/adin.c | 138 +
 1 file changed, 138 insertions(+)

diff --git a/drivers/net/phy/adin.c b/drivers/net/phy/adin.c
index 619d36685b5d..3e66f97c7611 100644
--- a/drivers/net/phy/adin.c
+++ b/drivers/net/phy/adin.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -70,6 +71,31 @@
 #define ADIN1300_CLOCK_STOP_REG0x9400
 #define ADIN1300_LPI_WAKE_ERR_CNT_REG  0xa000
 
+#define ADIN1300_CDIAG_RUN 0xba1b
+#define   ADIN1300_CDIAG_RUN_ENBIT(0)
+
+/*
+ * The XSIM3/2/1 and XSHRT3/2/1 are actually relative.
+ * For CDIAG_DTLD_RSLTS(0) it's ADIN1300_CDIAG_RSLT_XSIM3/2/1
+ * For CDIAG_DTLD_RSLTS(1) it's ADIN1300_CDIAG_RSLT_XSIM3/2/0
+ * For CDIAG_DTLD_RSLTS(2) it's ADIN1300_CDIAG_RSLT_XSIM3/1/0
+ * For CDIAG_DTLD_RSLTS(3) it's ADIN1300_CDIAG_RSLT_XSIM2/1/0
+ */
+#define ADIN1300_CDIAG_DTLD_RSLTS(x)   (0xba1d + (x))
+#define   ADIN1300_CDIAG_RSLT_BUSY BIT(10)
+#define   ADIN1300_CDIAG_RSLT_XSIM3BIT(9)
+#define   ADIN1300_CDIAG_RSLT_XSIM2BIT(8)
+#define   ADIN1300_CDIAG_RSLT_XSIM1BIT(7)
+#define   ADIN1300_CDIAG_RSLT_SIM  BIT(6)
+#define   ADIN1300_CDIAG_RSLT_XSHRT3   BIT(5)
+#define   ADIN1300_CDIAG_RSLT_XSHRT2   BIT(4)
+#define   ADIN1300_CDIAG_RSLT_XSHRT1   BIT(3)
+#define   ADIN1300_CDIAG_RSLT_SHRT BIT(2)
+#define   ADIN1300_CDIAG_RSLT_OPEN BIT(1)
+#define   ADIN1300_CDIAG_RSLT_GOOD BIT(0)
+
+#define ADIN1300_CDIAG_FLT_DIST(x) (0xba21 + (x))
+
 #define ADIN1300_GE_SOFT_RESET_REG 0xff0c
 #define   ADIN1300_GE_SOFT_RESET   BIT(0)
 
@@ -741,10 +767,117 @@ static int adin_probe(struct phy_device *phydev)
return 0;
 }
 
+static int adin_cable_test_start(struct phy_device *phydev)
+{
+   int ret;
+
+   ret = phy_clear_bits(phydev, ADIN1300_PHY_CTRL3, ADIN1300_LINKING_EN);
+   if (ret < 0)
+   return ret;
+
+   ret = phy_clear_bits(phydev, ADIN1300_PHY_CTRL1, ADIN1300_DIAG_CLK_EN);
+   if (ret < 0)
+   return ret;
+
+   /* wait a bit for the clock to stabilize */
+   msleep(50);
+
+   return phy_set_bits_mmd(phydev, MDIO_MMD_VEND1, ADIN1300_CDIAG_RUN,
+   ADIN1300_CDIAG_RUN_EN);
+}
+
+static int adin_cable_test_report_trans(int result)
+{
+   int mask;
+
+   if (result & ADIN1300_CDIAG_RSLT_GOOD)
+   return ETHTOOL_A_CABLE_RESULT_CODE_OK;
+   if (result & ADIN1300_CDIAG_RSLT_OPEN)
+   return ETHTOOL_A_CABLE_RESULT_CODE_OPEN;
+
+   /* short with other pairs */
+   mask = ADIN1300_CDIAG_RSLT_XSHRT3 |
+  ADIN1300_CDIAG_RSLT_XSHRT2 |
+  ADIN1300_CDIAG_RSLT_XSHRT1;
+   if (result & mask)
+   return ETHTOOL_A_CABLE_RESULT_CODE_CROSS_SHORT;
+
+   if (result & ADIN1300_CDIAG_RSLT_SHRT)
+   return ETHTOOL_A_CABLE_RESULT_CODE_SAME_SHORT;
+
+   return ETHTOOL_A_CABLE_RESULT_CODE_UNSPEC;
+}
+
+static int adin_cable_test_report_pair(struct phy_device *phydev,
+  unsigned int pair)
+{
+   int fault_rslt;
+   int ret;
+
+   ret = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+  ADIN1300_CDIAG_DTLD_RSLTS(pair));
+   if (ret < 0)
+   return ret;
+
+   fault_rslt = adin_cable_test_report_trans(ret);
+
+   ret = ethnl_cable_test_result(phydev, pair, fault_rslt);
+   if (ret < 0)
+   return ret;
+
+   ret = phy_read_mmd(phydev, MDIO_MMD_VEND1,
+  ADIN1300_CDIAG_FLT_DIST(pair));
+   if (ret < 0)
+   return ret;
+
+   switch (fault_rslt) {
+   case ETHTOOL_A_CABLE_RESULT_CODE_OPEN:
+   case ETHTOOL_A_CABLE_RESULT_CODE_SAME_SHORT:
+   case

Re: [PATCH] powerpc/32s: Setup the early hash table at all time.

2020-11-02 Thread Christophe Leroy


Hi Andreas,

Le 30/10/2020 à 14:11, Andreas Schwab a écrit :

#
# Automatically generated file; DO NOT EDIT.
# Linux/powerpc 5.10.0-rc1 Kernel Configuration
#


I tried again on QEMU with both pmac32_defconfig and your config, and it boots.

I really can't understand what the problem is, because that patch only activates at all time 
something that has been working well when CONFIG_KASAN is set.


Would you mind checking that with that patch reverted, you are able to boot a kernel built with 
CONFIG_KASAN ?


Thanks
Christophe

RE: [PATCH v1 1/6] scsi: ufs-mediatek: Assign arguments with correct type

2020-11-02 Thread Stanley Chu

Hi Avri,

On Tue, 2020-11-03 at 07:12 +, Avri Altman wrote:
> > 
> > In ufs_mtk_unipro_set_lpm(), use specific unsigned values
> > as the argument to invoke ufshcd_dme_set().
> > 
> > In the same time, change the name of ufs_mtk_unipro_set_pm()
> > to ufs_mtk_unipro_set_lpm() to align the naming convention
> > in MediaTek UFS driver.
> > 
> > Signed-off-by: Stanley Chu 
> Looks like this patch is gilding the lily?

Thanks for the review.

Please see explanation below.

> 
> > ---
> >  drivers/scsi/ufs/ufs-mediatek.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/scsi/ufs/ufs-mediatek.c 
> > b/drivers/scsi/ufs/ufs-mediatek.c
> > index 8df73bc2f8cb..0196a89055b5 100644
> > --- a/drivers/scsi/ufs/ufs-mediatek.c
> > +++ b/drivers/scsi/ufs/ufs-mediatek.c
> > @@ -639,14 +639,14 @@ static int ufs_mtk_pwr_change_notify(struct
> > ufs_hba *hba,
> > return ret;
> >  }
> > 
> > -static int ufs_mtk_unipro_set_pm(struct ufs_hba *hba, bool lpm)
> > +static int ufs_mtk_unipro_set_lpm(struct ufs_hba *hba, bool lpm)
> >  {
> > int ret;
> > struct ufs_mtk_host *host = ufshcd_get_variant(hba);
> > 
> > ret = ufshcd_dme_set(hba,
> >  UIC_ARG_MIB_SEL(VS_UNIPROPOWERDOWNCONTROL, 0),
> > -lpm);
> > +lpm ? 1 : 0);
> bool is implicitly converted to int anyway?

This change is the echo of your suggestion in
https://patchwork.kernel.org/project/linux-scsi/patch/20200908064507.30774-4-stanley@mediatek.com/

Actually I think your suggestion is constructive that the accepted
values of VS_UNIPROPOWERDOWNCONTROL are better clearly defined so I use
the casting here in this patch.

> 
> > if (!ret || !lpm) {
> > /*
> >  * Forcibly set as non-LPM mode if UIC commands is failed
> > @@ -664,7 +664,7 @@ static int ufs_mtk_pre_link(struct ufs_hba *hba)
> > int ret;
> > u32 tmp;
> > 
> > -   ret = ufs_mtk_unipro_set_pm(hba, false);
> > +   ret = ufs_mtk_unipro_set_lpm(hba, false);
> > if (ret)
> > return ret;
> > 
> > @@ -774,7 +774,7 @@ static int ufs_mtk_link_set_hpm(struct ufs_hba
> > *hba)
> > if (err)
> > return err;
> > 
> > -   err = ufs_mtk_unipro_set_pm(hba, false);
> > +   err = ufs_mtk_unipro_set_lpm(hba, false);
> > if (err)
> > return err;
> > 
> > @@ -795,10 +795,10 @@ static int ufs_mtk_link_set_lpm(struct ufs_hba
> > *hba)
> >  {
> > int err;
> > 
> > -   err = ufs_mtk_unipro_set_pm(hba, true);
> > +   err = ufs_mtk_unipro_set_lpm(hba, true);
> > if (err) {
> > /* Resume UniPro state for following error recovery */
> > -   ufs_mtk_unipro_set_pm(hba, false);
> > +   ufs_mtk_unipro_set_lpm(hba, false);
> > return err;
> > }
> > 
> > --
> > 2.18.0

Thanks,
Stanley Chu

Re: [PATCH v7 0/6] Exynos: Simple QoS for exynos-bus using interconnect

2020-11-02 Thread Chanwoo Choi

Hi Sylwester,

When I tested this patchset on Odroid-U3,
After setting 0 bps by interconnect[1][2],
the frequency of devfreq devs sustain the high frequency
according to the pm qos request.

So, I try to find the cause of this situation.
In result, it seems that interconnect exynos driver
updates the pm qos request to devfreq device
during the kernel booting. Do you know why the exynos
interconnect driver request the pm qos during probe
without the mixer request?

PS. The passive governor has a bug related to PM_QOS interface.
So, I posted the patch[4].


[1] interconnect_graph
root@localhost:~# cat /sys/kernel/debug/interconnect/interconnect_graph 
digraph {
rankdir = LR
node [shape = record]
subgraph cluster_1 {
label = "soc:bus_dmc"
"2:bus_dmc" [label="2:bus_dmc
|avg_bw=0kBps
|peak_bw=0kBps"]
}
subgraph cluster_2 {
label = "soc:bus_leftbus"
"3:bus_leftbus" [label="3:bus_leftbus
|avg_bw=0kBps
|peak_bw=0kBps"]
}
subgraph cluster_3 {
label = "soc:bus_display"
"4:bus_display" [label="4:bus_display
|avg_bw=0kBps
|peak_bw=0kBps"]
}
"3:bus_leftbus" -> "2:bus_dmc"
"4:bus_display" -> "3:bus_leftbus"


[2] interconnect_summary
root@localhost:~# cat /sys/kernel/debug/interconnect/interconnect_summary 
 node  tag  avg peak

bus_dmc   00
  12c1.mixer 000
bus_leftbus   00
  12c1.mixer 000
bus_display   00
  12c1.mixer 000


[3] devfreq_summary
root@localhost:~# cat /sys/kernel/debug/devfreq/devfreq_summary 
devparent_dev governor
timer  polling_ms  cur_freq_Hz  min_freq_Hz  max_freq_Hz
-- -- --- 
-- --   
soc:bus_dmcnull   simple_ondemand 
deferrable 50444
soc:bus_acpsoc:bus_dmcpassive 
null026700126700
soc:bus_c2csoc:bus_dmcpassive 
null0414
soc:bus_leftbusnull   simple_ondemand 
deferrable 50222
soc:bus_rightbus   soc:bus_leftbuspassive 
null0212
soc:bus_displaysoc:bus_leftbuspassive 
null0222
soc:bus_fsys   soc:bus_leftbuspassive 
null013400113400
soc:bus_peri   soc:bus_leftbuspassive 
null01 50001
soc:bus_mfcsoc:bus_leftbuspassive 
null0212


[4] PM / devfreq: passive: Update frequency when start governor
https://patchwork.kernel.org/project/linux-pm/patch/20201103070646.18687-1-cw00.c...@samsung.com/


On 10/30/20 9:51 PM, Sylwester Nawrocki wrote:
> 
> This patchset adds interconnect API support for the Exynos SoC "samsung,
> exynos-bus" compatible devices, which already have their corresponding
> exynos-bus driver in the devfreq subsystem.  Complementing the devfreq
> driver with an interconnect functionality allows to ensure the QoS
> requirements of devices accessing the system memory (e.g. video processing
> devices) are fulfilled and aallows to avoid issues like the one discussed
> in thread [1].
> 
> This patch series adds implementation of the interconnect provider per each
> "samsung,exynos-bus" compatible DT node, with one interconnect node per
> provider.  The interconnect code which was previously added as a part of
> the devfreq driver has been converted to a separate platform driver.
> In the devfreq a corresponding virtual child platform device is registered.
> Integration of devfreq and interconnect frameworks is achieved through
> the PM QoS API.
> 
> A sample interconnect consumer for exynos-mixer is added in patches 5/6,
> 6/6, it is currently added only for exynos4412 and allows to

[PATCH v2] Input: st1232 - add support resolution reading

2020-11-02 Thread Andrej Valek

Hard-coding resolution for st1633 device was wrong. Some of LCDs like
YTS700TLBC-02-100C has assembled Sitronix st1633 touchcontroller too. But
the resolution is not 320x480 as was hard-coded.
Add new function which reads correct resolution directly from register.

Signed-off-by: Andrej Valek 
---
 drivers/input/touchscreen/st1232.c | 52 +-
 1 file changed, 36 insertions(+), 16 deletions(-)

diff --git a/drivers/input/touchscreen/st1232.c 
b/drivers/input/touchscreen/st1232.c
index 63b29c7279e29..1b4b139c85330 100644
--- a/drivers/input/touchscreen/st1232.c
+++ b/drivers/input/touchscreen/st1232.c
@@ -26,15 +26,14 @@
 #define ST1232_TS_NAME "st1232-ts"
 #define ST1633_TS_NAME "st1633-ts"
 
+#define REG_XY_RESOLUTION  0x04
+#define REG_XY_COORDINATES 0x12
 #define ST_TS_MAX_FINGERS  10
 
 struct st_chip_info {
boolhave_z;
-   u16 max_x;
-   u16 max_y;
u16 max_area;
u16 max_fingers;
-   u8  start_reg;
 };
 
 struct st1232_ts_data {
@@ -48,15 +47,14 @@ struct st1232_ts_data {
u8 *read_buf;
 };
 
-static int st1232_ts_read_data(struct st1232_ts_data *ts)
+static int st1232_ts_read_data(struct st1232_ts_data *ts, u8 reg)
 {
struct i2c_client *client = ts->client;
-   u8 start_reg = ts->chip_info->start_reg;
struct i2c_msg msg[] = {
{
.addr   = client->addr,
-   .len= sizeof(start_reg),
-   .buf= _reg,
+   .len= sizeof(reg),
+   .buf= ,
},
{
.addr   = client->addr,
@@ -74,6 +72,25 @@ static int st1232_ts_read_data(struct st1232_ts_data *ts)
return 0;
 }
 
+static int st1232_ts_read_resolution(struct st1232_ts_data *ts, u16 *max_x,
+u16 *max_y)
+{
+   u8 *buf;
+   int error;
+
+   /* select resolution register */
+   error = st1232_ts_read_data(ts, REG_XY_RESOLUTION);
+   if (error)
+   return error;
+
+   buf = ts->read_buf;
+
+   *max_x = ((buf[0] & 0x0070) << 4) | buf[1];
+   *max_y = ((buf[0] & 0x0007) << 8) | buf[2];
+
+   return 0;
+}
+
 static int st1232_ts_parse_and_report(struct st1232_ts_data *ts)
 {
struct input_dev *input = ts->input_dev;
@@ -123,7 +140,7 @@ static irqreturn_t st1232_ts_irq_handler(int irq, void 
*dev_id)
int count;
int error;
 
-   error = st1232_ts_read_data(ts);
+   error = st1232_ts_read_data(ts, REG_XY_COORDINATES);
if (error)
goto out;
 
@@ -157,20 +174,14 @@ static void st1232_ts_power_off(void *data)
 
 static const struct st_chip_info st1232_chip_info = {
.have_z = true,
-   .max_x  = 0x31f, /* 800 - 1 */
-   .max_y  = 0x1df, /* 480 -1 */
.max_area   = 0xff,
.max_fingers= 2,
-   .start_reg  = 0x12,
 };
 
 static const struct st_chip_info st1633_chip_info = {
.have_z = false,
-   .max_x  = 0x13f, /* 320 - 1 */
-   .max_y  = 0x1df, /* 480 -1 */
.max_area   = 0x00,
.max_fingers= 5,
-   .start_reg  = 0x12,
 };
 
 static int st1232_ts_probe(struct i2c_client *client,
@@ -179,6 +190,7 @@ static int st1232_ts_probe(struct i2c_client *client,
const struct st_chip_info *match;
struct st1232_ts_data *ts;
struct input_dev *input_dev;
+   u16 max_x, max_y;
int error;
 
match = device_get_match_data(>dev);
@@ -239,14 +251,22 @@ static int st1232_ts_probe(struct i2c_client *client,
input_dev->name = "st1232-touchscreen";
input_dev->id.bustype = BUS_I2C;
 
+   /* read resolution from chip */
+   error = st1232_ts_read_resolution(ts, _x, _y);
+   if (error) {
+   dev_err(>dev,
+   "Failed to read resolution: %d\n", error);
+   return error;
+   }
+
if (ts->chip_info->have_z)
input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0,
 ts->chip_info->max_area, 0, 0);
 
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
-0, ts->chip_info->max_x, 0, 0);
+0, max_x, 0, 0);
input_set_abs_params(input_dev, ABS_MT_POSITION_Y,
-0, ts->chip_info->max_y, 0, 0);
+0, max_y, 0, 0);
 
touchscreen_parse_properties(input_dev, true, >prop);
 
-- 
2.20.1

Re: [PATCH V2] arm64: dts: imx8mp-evk: add CAN support

2020-11-02 Thread Krzysztof Kozlowski

On Tue, Nov 03, 2020 at 01:23:12AM +, Joakim Zhang wrote:
> 
> > -Original Message-
> > From: Krzysztof Kozlowski 
> > Sent: 2020年11月2日 16:29
> > To: Joakim Zhang 
> > Cc: shawn...@kernel.org; s.ha...@pengutronix.de; feste...@gmail.com;
> > dl-linux-imx ; devicet...@vger.kernel.org;
> > linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> > m...@pengutronix.de
> > Subject: Re: [PATCH V2] arm64: dts: imx8mp-evk: add CAN support
> > 
> > On Mon, Nov 02, 2020 at 10:16:34AM +0800, Joakim Zhang wrote:
> > > Add CAN device node and pinctrl on i.MX8MP evk board.
> > >
> > > Signed-off-by: Joakim Zhang 
> > > ---
> > > ChangeLogs:
> > > V1->V2:
> > >   * add missing space before '=',
> > >   fsl,clk-source= /bits/ 8 <0> -> fsl,clk-source = /bits/ 8 <0>
> > > ---
> > >  arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 62
> > 
> > >  arch/arm64/boot/dts/freescale/imx8mp.dtsi| 30 ++
> > >  2 files changed, 92 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> > > b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> > > index 908b92bb4dcd..b10dce8767a4 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts
> > > @@ -33,6 +33,28 @@
> > > <0x1 0x 0 0xc000>;
> > >   };
> > >
> > > + reg_can1_stby: regulator-can1-stby {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "can1-stby";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_flexcan1_reg>;
> > > + regulator-min-microvolt = <330>;
> > > + regulator-max-microvolt = <330>;
> > > + gpio = < 5 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > + };
> > > +
> > > + reg_can2_stby: regulator-can2-stby {
> > > + compatible = "regulator-fixed";
> > > + regulator-name = "can2-stby";
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_flexcan2_reg>;
> > > + regulator-min-microvolt = <330>;
> > > + regulator-max-microvolt = <330>;
> > > + gpio = < 27 GPIO_ACTIVE_HIGH>;
> > > + enable-active-high;
> > > + };
> > > +
> > >   reg_usdhc2_vmmc: regulator-usdhc2 {
> > >   compatible = "regulator-fixed";
> > >   pinctrl-names = "default";
> > > @@ -45,6 +67,20 @@
> > >   };
> > >  };
> > >
> > > + {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_flexcan1>;
> > > + xceiver-supply = <_can1_stby>;
> > > + status = "okay";
> > > +};
> > > +
> > > + {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_flexcan2>;
> > > + xceiver-supply = <_can2_stby>;
> > > + status = "disabled";/* can2 pin conflict with pdm */ };
> > > +
> > >   {
> > >   pinctrl-names = "default";
> > >   pinctrl-0 = <_fec>;
> > > @@ -144,6 +180,32 @@
> > >   >;
> > >   };
> > >
> > > + pinctrl_flexcan1: flexcan1grp {
> > > + fsl,pins = <
> > > + MX8MP_IOMUXC_SPDIF_RX__CAN1_RX  0x154
> > > + MX8MP_IOMUXC_SPDIF_TX__CAN1_TX  0x154
> > > + >;
> > > + };
> > > +
> > > + pinctrl_flexcan2: flexcan2grp {
> > > + fsl,pins = <
> > > + MX8MP_IOMUXC_SAI5_MCLK__CAN2_RX 0x154
> > > + MX8MP_IOMUXC_SAI5_RXD3__CAN2_TX 0x154
> > > + >;
> > > + };
> > > +
> > > + pinctrl_flexcan1_reg: flexcan1reggrp {
> > > + fsl,pins = <
> > > + MX8MP_IOMUXC_SPDIF_EXT_CLK__GPIO5_IO05  0x154   /*
> > CAN1_STBY */
> > > + >;
> > > + };
> > > +
> > > + pinctrl_flexcan2_reg: flexcan2reggrp {
> > > + fsl,pins = <
> > > + MX8MP_IOMUXC_SAI2_MCLK__GPIO4_IO27  0x154
> > /* CAN2_STBY */
> > > + >;
> > > + };
> > > +
> > >   pinctrl_gpio_led: gpioledgrp {
> > >   fsl,pins = <
> > >   MX8MP_IOMUXC_NAND_READY_B__GPIO3_IO16   0x19
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > index 479312293036..ecccfbb4f5ad 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> > > @@ -552,6 +552,36 @@
> > >   status = "disabled";
> > >   };
> > >
> > > + flexcan1: can@308c {
> > > + compatible = "fsl,imx8mp-flexcan", 
> > > "fsl,imx6q-flexcan";
> > 
> > Undocumented compatible in
> > Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> 
> Hi Krzsztof,
> 
> Yes, I will resend the patch after below patch goes into mainline. Thanks.
> https://www.spinics.net/lists/linux-can/msg04896.html

Thanks for the link. It's all good and there is no need to resend
because your compatible is mentioned there.

Best regards,
Krzysztof

Re: [PATCH] x86/hyperv: Enable 15-bit APIC ID if the hypervisor supports it

Hi Dexuan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on tip/x86/core]
[also build test ERROR on tip/master v5.10-rc2 next-20201102]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Dexuan-Cui/x86-hyperv-Enable-15-bit-APIC-ID-if-the-hypervisor-supports-it/20201103-091414
base:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
238c91115cd05c71447ea071624a4c9fe661f970
config: i386-randconfig-r012-20201103 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/c4037b8c4cd61f970749c6685a3df5a1376193d2
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Dexuan-Cui/x86-hyperv-Enable-15-bit-APIC-ID-if-the-hypervisor-supports-it/20201103-091414
git checkout c4037b8c4cd61f970749c6685a3df5a1376193d2
# save the attached .config to linux build tree
make W=1 ARCH=i386 

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

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

>> arch/x86/kernel/cpu/mshyperv.c:397:8: error: 'struct x86_hyper_init' has no 
>> member named 'msi_ext_dest_id'
 397 |  .init.msi_ext_dest_id = ms_hyperv_msi_ext_dest_id,
 |^~~
>> arch/x86/kernel/cpu/mshyperv.c:397:26: error: initialization of 'void 
>> (*)(void)' from incompatible pointer type 'bool (*)(void)' {aka '_Bool 
>> (*)(void)'} [-Werror=incompatible-pointer-types]
 397 |  .init.msi_ext_dest_id = ms_hyperv_msi_ext_dest_id,
 |  ^
   arch/x86/kernel/cpu/mshyperv.c:397:26: note: (near initialization for 
'x86_hyper_ms_hyperv.init.init_platform')
>> arch/x86/kernel/cpu/mshyperv.c:398:24: warning: initialized field 
>> overwritten [-Woverride-init]
 398 |  .init.init_platform = ms_hyperv_init_platform,
 |^~~
   arch/x86/kernel/cpu/mshyperv.c:398:24: note: (near initialization for 
'x86_hyper_ms_hyperv.init.init_platform')
   cc1: some warnings being treated as errors

vim +397 arch/x86/kernel/cpu/mshyperv.c

   391  
   392  const __initconst struct hypervisor_x86 x86_hyper_ms_hyperv = {
   393  .name   = "Microsoft Hyper-V",
   394  .detect = ms_hyperv_platform,
   395  .type   = X86_HYPER_MS_HYPERV,
   396  .init.x2apic_available  = ms_hyperv_x2apic_available,
 > 397  .init.msi_ext_dest_id   = ms_hyperv_msi_ext_dest_id,
 > 398  .init.init_platform = ms_hyperv_init_platform,

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


.config.gz
Description: application/gzip

Re: [PATCH 2/2] ethernet: igb: e1000_phy: Check for ops.force_speed_duplex existence

2020-11-02 Thread Paul Menzel


Dear Jakub,


Am 03.11.20 um 01:19 schrieb Jakub Kicinski:

On Tue,  3 Nov 2020 00:13:07 +0100 Paul Menzel wrote:

From: Jeffrey Townsend 

The ops field might no be defined, so add a check.


This change should be first, otherwise AFAIU if someone builds the
kernel in between the commits (e.g. for bisection) it will crash.


Patch `[PATCH 1/2] ethernet: igb: Support PHY BCM5461S` has

phy->ops.force_speed_duplex = igb_phy_force_speed_duplex_82580;

so the ordering does not matter. I do not know, if Jeffrey can comment, 
but probably the check was just adding during development. Maybe an 
assert should be added instead?



The patch is taken from Open Network Linux (ONL), and it was added there
as part of the patch

 
packages/base/any/kernels/3.16+deb8/patches/driver-support-intel-igb-bcm5461X-phy.patch

in ONL commit f32316c63c (Support the BCM54616 and BCM5461S.) [1]. Part
of this commit was already upstreamed in Linux commit eeb0149660 (igb:
support BCM54616 PHY) in 2017.

I applied the forward-ported

 
packages/base/any/kernels/5.4-lts/patches/0002-driver-support-intel-igb-bcm5461S-phy.patch

added in ONL commit 5ace6bcdb3 (Add 5.4 LTS kernel build.) [2].

[1]: 
https://github.com/opencomputeproject/OpenNetworkLinux/commit/f32316c63ce3a64de125b7429115c6d45e942bd1
[2]: 
https://github.com/opencomputeproject/OpenNetworkLinux/commit/5ace6bcdb37cb8065dcd1d4404b3dcb6424f6331


No need to put this in every commit message.

We preserve the cover letter in tree as a merge commit message, so
explaining things once in the cover letter is sufficient.


I remember, but still find it confusing. If I look at a commit with `git 
show …`, I normally do not think of also looking at a possible cover 
letter as not many subsystems/projects do it, and I assume a commit is 
self-contained.


Could you share your development process


Cc: Jeffrey Townsend 


Jefferey will need to provide a sign-off as the author.


According to *Developer's Certificate of Origin 1.1* [3], it’s my 
understanding, that it is *not* required. The items (a), (b), and (c) 
are connected by an *or*.



(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part 
by me, under the same open source license (unless I am

permitted to submit under a different license), as indicated
in the file; or



Cc: John W Linville 
Signed-off-by: Paul Menzel 



Kind regards,

Paul


[3]: 
https://www.kernel.org/doc/html/v5.9/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin

Re: [PATCH] spi: add runtime PM for transfer_one_message

2020-11-02 Thread Chunyan Zhang

On Tue, 3 Nov 2020 at 02:17, Mark Brown  wrote:
>
> On Mon, Nov 02, 2020 at 07:22:39PM +0800, Chunyan Zhang wrote:
> > From: Chunyan Zhang 
>
> > Before transfer message, spi devices probably have been in runtime 
> > suspended,
> > that would cause the kernel crash on some platforms once access spi
> > registers, such as on Unisoc's SoCs. The spi devices can be suspended
> > until message transfer completed.
>
> This commit message is a bit hard to follow so I don't really understand
> what the issue is.  We only ever call transfer_one_message() from within
> __spi_pump_messages() which already handles auto_runtime_pm so I'm not
> seeing the situation where we might get to transfer_one_message()
> without having already runtime resumed the controller.  What exactly is
> the error situation here?  This code has been around for a while and I'm
> not aware of reports of issues here and I can't see anything unusual
> that the Spreadtrum driver is doing.

With further tests and looking into this part of code, the problem we
found recently on our platform which runs kernel 4.14 can be fixed by
this commit [1].
In a word,  there's no issue here indeed, this patch should be
ignored, sorry for the noise and thanks for your review.

Chunyan

[1] https://lkml.org/lkml/2019/10/30/173

>
> Also why are we doing this in transfer_one_message() where it will only
> work for controllers using that?  If we're missing runtime PM in some
> paths then presumably controllers with a custom implementation are also
> going to be affected as well, auto_runtime_pm is supposed to work for
> them as well.

Re: [net-next PATCH 3/3] octeontx2-af: Add devlink health reporters for NIX

Hi George,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/George-Cherian/Add-devlink-and-devlink-health-reporters-to/20201102-130844
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
c43fd36f7fec6c227c5e8a8ddd7d3fe97472182f
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/bdffba84e2716a5f218840ac6a80052587e48c59
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
George-Cherian/Add-devlink-and-devlink-health-reporters-to/20201102-130844
git checkout bdffba84e2716a5f218840ac6a80052587e48c59
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

   drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:19:5: warning: no 
previous prototype for 'rvu_report_pair_start' [-Wmissing-prototypes]
  19 | int rvu_report_pair_start(struct devlink_fmsg *fmsg, const char 
*name)
 | ^
   drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:30:5: warning: no 
previous prototype for 'rvu_report_pair_end' [-Wmissing-prototypes]
  30 | int rvu_report_pair_end(struct devlink_fmsg *fmsg)
 | ^~~
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:41:13: warning: no 
>> previous prototype for 'rvu_nix_af_rvu_intr_handler' [-Wmissing-prototypes]
  41 | irqreturn_t rvu_nix_af_rvu_intr_handler(int irq, void *rvu_irq)
 | ^~~
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:65:13: warning: no 
>> previous prototype for 'rvu_nix_af_err_intr_handler' [-Wmissing-prototypes]
  65 | irqreturn_t rvu_nix_af_err_intr_handler(int irq, void *rvu_irq)
 | ^~~
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:107:13: warning: no 
>> previous prototype for 'rvu_nix_af_ras_intr_handler' [-Wmissing-prototypes]
 107 | irqreturn_t rvu_nix_af_ras_intr_handler(int irq, void *rvu_irq)
 | ^~~
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:208:5: warning: no 
>> previous prototype for 'rvu_nix_register_interrupts' [-Wmissing-prototypes]
 208 | int rvu_nix_register_interrupts(struct rvu *rvu)
 | ^~~
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:376:5: warning: no 
>> previous prototype for 'rvu_nix_health_reporters_create' 
>> [-Wmissing-prototypes]
 376 | int rvu_nix_health_reporters_create(struct rvu_devlink *rvu_dl)
 | ^~~
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:400:6: warning: no 
>> previous prototype for 'rvu_nix_health_reporters_destroy' 
>> [-Wmissing-prototypes]
 400 | void rvu_nix_health_reporters_destroy(struct rvu_devlink *rvu_dl)
 |  ^~~~
   drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:569:5: warning: no 
previous prototype for 'rvu_npa_register_interrupts' [-Wmissing-prototypes]
 569 | int rvu_npa_register_interrupts(struct rvu *rvu)
 | ^~~

vim +/rvu_nix_af_rvu_intr_handler +41 
drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c

40  
  > 41  irqreturn_t rvu_nix_af_rvu_intr_handler(int irq, void *rvu_irq)
42  {
43  struct rvu_nix_event_cnt *nix_event_count;
44  struct rvu_devlink *rvu_dl = rvu_irq;
45  struct rvu *rvu;
46  int blkaddr;
47  u64 intr;
48  
49  rvu = rvu_dl->rvu;
50  blkaddr = rvu_get_blkaddr(rvu, BLKTYPE_NIX, 0);
51  if (blkaddr < 0)
52  return IRQ_NONE;
53  
54  nix_event_count = rvu_dl->nix_event_cnt;
55  intr = rvu_read64(rvu, blkaddr, NIX_AF_RVU_INT);
56  
57  if (intr & BIT_ULL(0))
58  nix_event_count->unmap_slot_count++;
59  
60  /* Clear interrupts */
61  rvu_write64(rvu, blkaddr, NIX_AF_RVU_INT, intr);
62  return IRQ_HANDLED;
63  }
64  
  > 65  irqreturn_t rvu_nix_af_err_intr_handler(int irq, void *rvu_irq)
66  {
67  struct rvu_nix_event_cnt *nix_event_count;
68  struct rvu_devlink *rvu_dl = rvu_irq;
69  struct rvu *rvu;
70  int blkaddr;
71  u64 intr;
72  
73  rvu = rvu_dl->rvu;
74  blkaddr = rvu_get_blkaddr(rvu, BLKTYPE_NIX, 0);
75

[tip:x86/cleanups] BUILD SUCCESS 4a2d2ed9bae16c14602e7aebba3f0c90f73fe786

   allnoconfig
i386 randconfig-a004-20201102
i386 randconfig-a006-20201102
i386 randconfig-a005-20201102
i386 randconfig-a001-20201102
i386 randconfig-a002-20201102
i386 randconfig-a003-20201102
i386 randconfig-a004-20201103
i386 randconfig-a006-20201103
i386 randconfig-a005-20201103
i386 randconfig-a001-20201103
i386 randconfig-a002-20201103
i386 randconfig-a003-20201103
x86_64   randconfig-a012-20201102
x86_64   randconfig-a015-20201102
x86_64   randconfig-a011-20201102
x86_64   randconfig-a013-20201102
x86_64   randconfig-a014-20201102
x86_64   randconfig-a016-20201102
i386 randconfig-a013-20201102
i386 randconfig-a015-20201102
i386 randconfig-a014-20201102
i386 randconfig-a016-20201102
i386 randconfig-a011-20201102
i386 randconfig-a012-20201102
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a004-20201102
x86_64   randconfig-a005-20201102
x86_64   randconfig-a003-20201102
x86_64   randconfig-a002-20201102
x86_64   randconfig-a006-20201102
x86_64   randconfig-a001-20201102

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

Re: [PATCH] KVM: VMX: Enable Notify VM exit

2020-11-02 Thread Xiaoyao Li


On 11/3/2020 2:08 PM, Tao Xu wrote:



On 11/3/20 12:43 AM, Andy Lutomirski wrote:

On Sun, Nov 1, 2020 at 10:14 PM Tao Xu  wrote:



...



+static int handle_notify(struct kvm_vcpu *vcpu)
+{
+   unsigned long exit_qualification = 
vmcs_readl(EXIT_QUALIFICATION);

+
+   /*
+    * Notify VM exit happened while executing iret from NMI,
+    * "blocked by NMI" bit has to be set before next VM entry.
+    */
+   if (exit_qualification & NOTIFY_VM_CONTEXT_VALID) {
+   if (enable_vnmi &&
+   (exit_qualification & INTR_INFO_UNBLOCK_NMI))
+   vmcs_set_bits(GUEST_INTERRUPTIBILITY_INFO,
+ GUEST_INTR_STATE_NMI);


This needs actual documentation in the SDM or at least ISE please.



Hi Andy,

Do you mean SDM or ISE should call out it needs to restore "blocked by 
NMI" if bit 12 of exit qualification is set and VMM decides to re-enter 
the guest?


you can refer to SDM 27.2.3 "Information about NMI unblocking Due to 
IRET" in latest SDM 325462-072US



Notify VM-Exit is defined in ISE, chapter 9.2:
https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf 



I will add this information into commit message. Thank you for reminding 
me.

Re: [PATCH v2] checkpatch: improve email parsing

2020-11-02 Thread Joe Perches

On Tue, 2020-11-03 at 11:28 +0530, Dwaipayan Ray wrote:
> On Tue, Nov 3, 2020 at 11:18 AM Dwaipayan Ray  wrote:
> > 
> > checkpatch doesn't report warnings for many common mistakes
> > in emails. Some of which are trailing commas and incorrect
> > use of email comments.
> > 
> > At the same time several false positives are reported due to
> > incorrect handling of mail comments. The most common of which
> > is due to the pattern:
> > 
> >  # X.X
> > 
> > Improve email parsing mechanism in checkpatch.
> > 
> > What is added:
> > 
> > - Support for multiple name/address comments.
> > - Improved handling of quoted names.
> > - Sanitize improperly formatted comments.
> > - Sanitize trailing semicolon or dot after email.
[]
> What do you think? Should warnings for the names which should
> be quoted be reported considering this result?

Clearly the quote suggestion is unnecessary.

I think that "cc: stable@(?:vger\.)?kernel\.org" should be
treated differently from other forms of invalid/odd address lines.

My suggestion is that the case insensitive form of

Cc: sta...@vger.kernel.org

or only another similar case insensitive forms with a
# comment separator like

Cc:  # some comment

be acceptable for stable.

All other forms with stable@ should emit some message.

And other -by: and cc: addresses should only have a form like

Signed-off-by: "Full.Name" (possible comment) 
or
Signed-off-by: Full Name (possible comment) 

etc..

and any additional content after .tld in the email address be flagged
with some message like "unexpected content after email address" rather
than "might be better as".

What do you think best?

Re: [PATCH] PCI: v3: fix missing clk_disable_unprepare() on error in v3_pci_probe

2020-11-02 Thread miaoqinglang





在 2020/11/2 21:48, Rob Herring 写道:

On Thu, Oct 29, 2020 at 8:28 PM Qinglang Miao  wrote:


Fix the missing clk_disable_unprepare() before return
from v3_pci_probe() in the error handling case.

Signed-off-by: Qinglang Miao 
---
  drivers/pci/controller/pci-v3-semi.c | 14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/controller/pci-v3-semi.c 
b/drivers/pci/controller/pci-v3-semi.c
index 154a53986..e24abc5b4 100644
--- a/drivers/pci/controller/pci-v3-semi.c
+++ b/drivers/pci/controller/pci-v3-semi.c
@@ -739,8 +739,10 @@ static int v3_pci_probe(struct platform_device *pdev)

 regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 v3->base = devm_ioremap_resource(dev, regs);
-   if (IS_ERR(v3->base))
+   if (IS_ERR(v3->base)) {
+   clk_disable_unprepare(clk);


You can reorder things moving the clock enable later (after mapping
resources, but before devm_request_irq) and avoid some of these. Also
move this check down:

if (readl(v3->base + V3_LB_IO_BASE) != (regs->start >> 16))


Hi Rob,

I've sent a new patch which reorder things and cover all error branches.

But I'm not sure why and where should I move this check down:
if (readl(v3->base + V3_LB_IO_BASE) != (regs->start >> 16)).  So I 
didn't move it in current version.


If you think it's still necessary, please let me know.

Thanks.



 return PTR_ERR(v3->base);
+   }
 /*
  * The hardware has a register with the physical base address
  * of the V3 controller itself, verify that this is the same
@@ -754,17 +756,22 @@ static int v3_pci_probe(struct platform_device *pdev)
 regs = platform_get_resource(pdev, IORESOURCE_MEM, 1);
 if (resource_size(regs) != SZ_16M) {
 dev_err(dev, "config mem is not 16MB!\n");
+   clk_disable_unprepare(clk);
 return -EINVAL;
 }
 v3->config_mem = regs->start;
 v3->config_base = devm_ioremap_resource(dev, regs);
-   if (IS_ERR(v3->config_base))
+   if (IS_ERR(v3->config_base)) {
+   clk_disable_unprepare(clk);
 return PTR_ERR(v3->config_base);
+   }

 /* Get and request error IRQ resource */
 irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
+   if (irq < 0) {
+   clk_disable_unprepare(clk);
 return irq;
+   }

 ret = devm_request_irq(dev, irq, v3_irq, 0,
 "PCIv3 error", v3);
@@ -772,6 +779,7 @@ static int v3_pci_probe(struct platform_device *pdev)
 dev_err(dev,
 "unable to request PCIv3 error IRQ %d (%d)\n",
 irq, ret);
+   clk_disable_unprepare(clk);
 return ret;


You still leave the clock enabled if pci_host_probe() fails.

Rob
.

[PATCH v2] PCI: v3: fix missing clk_disable_unprepare() on error in v3_pci_probe

Fix the missing clk_disable_unprepare() before return
from v3_pci_probe() in the error handling case.

Moving the clock enable later to avoid some fixes.

Fixes: 6e0832fa432e (" PCI: Collect all native drivers under 
drivers/pci/controller/")
Suggested-by: Rob Herring 
Signed-off-by: Qinglang Miao 
---
 drivers/pci/controller/pci-v3-semi.c | 40 
 1 file changed, 23 insertions(+), 17 deletions(-)

diff --git a/drivers/pci/controller/pci-v3-semi.c 
b/drivers/pci/controller/pci-v3-semi.c
index 154a53986..90520555b 100644
--- a/drivers/pci/controller/pci-v3-semi.c
+++ b/drivers/pci/controller/pci-v3-semi.c
@@ -725,18 +725,6 @@ static int v3_pci_probe(struct platform_device *pdev)
host->sysdata = v3;
v3->dev = dev;
 
-   /* Get and enable host clock */
-   clk = devm_clk_get(dev, NULL);
-   if (IS_ERR(clk)) {
-   dev_err(dev, "clock not found\n");
-   return PTR_ERR(clk);
-   }
-   ret = clk_prepare_enable(clk);
-   if (ret) {
-   dev_err(dev, "unable to enable clock\n");
-   return ret;
-   }
-
regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
v3->base = devm_ioremap_resource(dev, regs);
if (IS_ERR(v3->base))
@@ -761,17 +749,31 @@ static int v3_pci_probe(struct platform_device *pdev)
if (IS_ERR(v3->config_base))
return PTR_ERR(v3->config_base);
 
+   /* Get and enable host clock */
+   clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(clk)) {
+   dev_err(dev, "clock not found\n");
+   return PTR_ERR(clk);
+   }
+   ret = clk_prepare_enable(clk);
+   if (ret) {
+   dev_err(dev, "unable to enable clock\n");
+   return ret;
+   }
+
/* Get and request error IRQ resource */
irq = platform_get_irq(pdev, 0);
-   if (irq < 0)
+   if (irq < 0) {
+   clk_disable_unprepare(clk);
return irq;
-
+   }
ret = devm_request_irq(dev, irq, v3_irq, 0,
"PCIv3 error", v3);
if (ret < 0) {
dev_err(dev,
"unable to request PCIv3 error IRQ %d (%d)\n",
irq, ret);
+   clk_disable_unprepare(clk);
return ret;
}
 
@@ -814,13 +816,15 @@ static int v3_pci_probe(struct platform_device *pdev)
ret = v3_pci_setup_resource(v3, host, win);
if (ret) {
dev_err(dev, "error setting up resources\n");
+   clk_disable_unprepare(clk);
return ret;
}
}
ret = v3_pci_parse_map_dma_ranges(v3, np);
-   if (ret)
+   if (ret) {
+   clk_disable_unprepare(clk);
return ret;
-
+   }
/*
 * Disable PCI to host IO cycles, enable I/O buffers @3.3V,
 * set AD_LOW0 to 1 if one of the LB_MAP registers choose
@@ -862,8 +866,10 @@ static int v3_pci_probe(struct platform_device *pdev)
/* Special Integrator initialization */
if (of_device_is_compatible(np, "arm,integrator-ap-pci")) {
ret = v3_integrator_init(v3);
-   if (ret)
+   if (ret) {
+   clk_disable_unprepare(clk);
return ret;
+   }
}
 
/* Post-init: enable PCI memory and invalidate (master already on) */
-- 
2.23.0

[PATCH v2] serial: txx9: add missing platform_driver_unregister() on error in serial_txx9_init

Add the missing platform_driver_unregister() before return
from serial_txx9_init in the error handling case when failed
to register serial_txx9_pci_driver with macro ENABLE_SERIAL_TXX9_PCI
defined.

Fixes: ab4382d27412 ("tty: move drivers/serial/ to drivers/tty/serial/")
Signed-off-by: Qinglang Miao 
---
 drivers/tty/serial/serial_txx9.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/tty/serial/serial_txx9.c b/drivers/tty/serial/serial_txx9.c
index b4d89e317..7a07e7272 100644
--- a/drivers/tty/serial/serial_txx9.c
+++ b/drivers/tty/serial/serial_txx9.c
@@ -1280,6 +1280,9 @@ static int __init serial_txx9_init(void)
 
 #ifdef ENABLE_SERIAL_TXX9_PCI
ret = pci_register_driver(_txx9_pci_driver);
+   if (ret) {
+   platform_driver_unregister(_txx9_plat_driver);
+   }
 #endif
if (ret == 0)
goto out;
-- 
2.23.0

Re: [net-next PATCH 2/3] octeontx2-af: Add devlink health reporters for NPA

Hi George,

I love your patch! Perhaps something to improve:

[auto build test WARNING on net-next/master]

url:
https://github.com/0day-ci/linux/commits/George-Cherian/Add-devlink-and-devlink-health-reporters-to/20201102-130844
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
c43fd36f7fec6c227c5e8a8ddd7d3fe97472182f
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
# 
https://github.com/0day-ci/linux/commit/b407a9eab03c85981a41a1e03c88d04036a860d6
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
George-Cherian/Add-devlink-and-devlink-health-reporters-to/20201102-130844
git checkout b407a9eab03c85981a41a1e03c88d04036a860d6
# save the attached .config to linux build tree
make W=1 ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:18:5: warning: no 
>> previous prototype for 'rvu_report_pair_start' [-Wmissing-prototypes]
  18 | int rvu_report_pair_start(struct devlink_fmsg *fmsg, const char 
*name)
 | ^
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:29:5: warning: no 
>> previous prototype for 'rvu_report_pair_end' [-Wmissing-prototypes]
  29 | int rvu_report_pair_end(struct devlink_fmsg *fmsg)
 | ^~~
>> drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c:201:5: warning: no 
>> previous prototype for 'rvu_npa_register_interrupts' [-Wmissing-prototypes]
 201 | int rvu_npa_register_interrupts(struct rvu *rvu)
 | ^~~

vim +/rvu_report_pair_start +18 
drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c

17  
  > 18  int rvu_report_pair_start(struct devlink_fmsg *fmsg, const char *name)
19  {
20  int err;
21  
22  err = devlink_fmsg_pair_nest_start(fmsg, name);
23  if (err)
24  return err;
25  
26  return  devlink_fmsg_obj_nest_start(fmsg);
27  }
28  
  > 29  int rvu_report_pair_end(struct devlink_fmsg *fmsg)
30  {
31  int err;
32  
33  err = devlink_fmsg_obj_nest_end(fmsg);
34  if (err)
35  return err;
36  
37  return devlink_fmsg_pair_nest_end(fmsg);
38  }
39  
40  static irqreturn_t rvu_npa_af_rvu_intr_handler(int irq, void *rvu_irq)
41  {
42  struct rvu_npa_event_cnt *npa_event_count;
43  struct rvu_devlink *rvu_dl = rvu_irq;
44  struct rvu *rvu;
45  int blkaddr;
46  u64 intr;
47  
48  rvu = rvu_dl->rvu;
49  blkaddr = rvu_get_blkaddr(rvu, BLKTYPE_NPA, 0);
50  if (blkaddr < 0)
51  return IRQ_NONE;
52  
53  npa_event_count = rvu_dl->npa_event_cnt;
54  intr = rvu_read64(rvu, blkaddr, NPA_AF_RVU_INT);
55  
56  if (intr & BIT_ULL(0))
57  npa_event_count->unmap_slot_count++;
58  /* Clear interrupts */
59  rvu_write64(rvu, blkaddr, NPA_AF_RVU_INT, intr);
60  return IRQ_HANDLED;
61  }
62  
63  static int rvu_npa_inpq_to_cnt(u16 in,
64 struct rvu_npa_event_cnt 
*npa_event_count)
65  {
66  switch (in) {
67  case 0:
68  return 0;
69  case BIT(NPA_INPQ_NIX0_RX):
70  return npa_event_count->free_dis_nix0_rx_count++;
71  case BIT(NPA_INPQ_NIX0_TX):
72  return npa_event_count->free_dis_nix0_tx_count++;
73  case BIT(NPA_INPQ_NIX1_RX):
74  return npa_event_count->free_dis_nix1_rx_count++;
75  case BIT(NPA_INPQ_NIX1_TX):
76  return npa_event_count->free_dis_nix1_tx_count++;
77  case BIT(NPA_INPQ_SSO):
78  return npa_event_count->free_dis_sso_count++;
79  case BIT(NPA_INPQ_TIM):
80  return npa_event_count->free_dis_tim_count++;
81  case BIT(NPA_INPQ_DPI):
82  return npa_event_count->free_dis_dpi_count++;
83  case BIT(NPA_INPQ_AURA_OP):
84  return npa_event_count->free_dis_aura_count++;
85  case BIT(NPA_INPQ_INTERNAL_RSV):
86  return npa_event_count->free_dis_rsvd_count++;
87  }
88  
89  return npa_event_count->alloc_dis_rsvd_count++;
90  }
91  
92  static irqreturn_t rvu_npa_af_gen_intr_handler(int irq, void *rvu_irq)
93  {
94

Re: [PATCH v2 net] net: sch_generic: aviod concurrent reset and enqueue op for lockless qdisc

2020-11-02 Thread Yunsheng Lin

On 2020/11/3 0:55, Cong Wang wrote:
> On Fri, Oct 30, 2020 at 12:38 AM Yunsheng Lin  wrote:
>>
>> On 2020/10/30 3:05, Cong Wang wrote:
>>>
>>> I do not see how and why it should. synchronize_net() is merely an optimized
>>> version of synchronize_rcu(), it should wait for RCU readers, softirqs are 
>>> not
>>> necessarily RCU readers, net_tx_action() does not take RCU read lock either.
>>
>> Ok, make sense.
>>
>> Taking RCU read lock in net_tx_action() does not seems to solve the problem,
>> what about the time window between __netif_reschedule() and net_tx_action()?
>>
>> It seems we need to re-dereference the qdisc whenever RCU read lock is 
>> released
>> and qdisc is still in sd->output_queue or wait for the sd->output_queue to 
>> drain?
> 
> Not suggesting you to take RCU read lock. We already wait for TX action with
> a loop of sleep. To me, the only thing missing is just moving the
> reset after that
> wait.

__QDISC_STATE_SCHED is cleared before calling qdisc_run() in net_tx_action(),
some_qdisc_is_busy does not seem to wait fully for TX action, at least
qdisc is still being accessed even if __QDISC_STATE_DEACTIVATED is set.

> 
> 
>> If we do any additional reset that is not related to qdisc in 
>> dev_reset_queue(), we
>> can move it after some_qdisc_is_busy() checking.
>
> I am not suggesting to do an additional reset, I am suggesting to move
> your reset after the busy waiting.

 There maybe a deadlock here if we reset the qdisc after the 
 some_qdisc_is_busy() checking,
 because some_qdisc_is_busy() may require the qdisc reset to clear the skb, 
 so that
>>>
>>> some_qdisc_is_busy() checks the status of qdisc, not the skb queue.
>>
>> Is there any reason why we do not check the skb queue in the dqisc?
>> It seems there may be skb left when netdev is deactivated, maybe at least 
>> warn
>> about that when there is still skb left when netdev is deactivated?
>> Is that why we call qdisc_reset() to clear the leftover skb in 
>> qdisc_destroy()?
>>
>>>
>>>
 some_qdisc_is_busy() can return false. I am not sure this is really a 
 problem, but
 sch_direct_xmit() may requeue the skb when dev_hard_start_xmit return 
 TX_BUSY.
>>>
>>> Sounds like another reason we should move the reset as late as possible?
>>
>> Why?
> 
> You said "sch_direct_xmit() may requeue the skb", I agree. I assume you mean
> net_tx_action() calls sch_direct_xmit() which does the requeue then races with
> reset. No?
> 

Look at current code again, I think there is no race between sch_direct_xmit()
in net_tx_action() and dev_reset_queue() in dev_deactivate_many(), because
qdisc_lock(qdisc) or qdisc->seqlock has been taken when calling 
sch_direct_xmit()
or dev_reset_queue().


> 
>>
>> There current netdev down order is mainly below:
>>
>> netif_tx_stop_all_queues()
>>
>> dev_deactivate_queue()
>>
>> synchronize_net()
>>
>> dev_reset_queue()
>>
>> some_qdisc_is_busy()
>>
>>
>> You suggest to change it to below order, right?
>>
>> netif_tx_stop_all_queues()
>>
>> dev_deactivate_queue()
>>
>> synchronize_net()
>>
>> some_qdisc_is_busy()
>>
>> dev_reset_queue()
> 
> Yes.
> 
>>
>>
>> What is the semantics of some_qdisc_is_busy()?
> 
> Waiting for flying TX action.

It wait for __QDISC_STATE_SCHED to clear and qdisc running to finish, but
there is still time window between __QDISC_STATE_SCHED clearing and qdisc
running, right?

> 
>> From my understanding, we can do anything about the old qdisc (including
>> destorying the old qdisc) after some_qdisc_is_busy() return false.
> 
> But the current code does the reset _before_ some_qdisc_is_busy(). ;)

If lock is taken when doing reset, it does not matter if the reset is
before some_qdisc_is_busy(), right?

> 
> Thanks.
> .
>

Re: [PATCH v1] ARM: vfp: Use long jump to fix THUMB2 kernel compilation error

2020-11-02 Thread Ard Biesheuvel

On Thu, 29 Oct 2020 at 10:56, Ard Biesheuvel  wrote:
>
> On Mon, 26 Oct 2020 at 09:58, Ard Biesheuvel  wrote:
> >
> > On Thu, 22 Oct 2020 at 19:59, Ard Biesheuvel  wrote:
> > >
> > > On Thu, 22 Oct 2020 at 19:48, Russell King - ARM Linux admin
> > >  wrote:
> > > >
> > > > On Thu, Oct 22, 2020 at 06:33:17PM +0200, Ard Biesheuvel wrote:
> > > > > On Thu, 22 Oct 2020 at 18:23, Russell King - ARM Linux admin
> > > > >  wrote:
> > > > > >
> > > > > > On Thu, Oct 22, 2020 at 06:20:40PM +0200, Ard Biesheuvel wrote:
> > > > > > > On Thu, 22 Oct 2020 at 18:11, Russell King - ARM Linux admin
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > On Thu, Oct 22, 2020 at 06:06:32PM +0200, Ard Biesheuvel wrote:
> > > > > > > > > On Thu, 22 Oct 2020 at 17:57, Dmitry Osipenko 
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > 22.10.2020 10:06, Ard Biesheuvel пишет:
> > > > > > > > > > > On Thu, 22 Oct 2020 at 05:30, Kees Cook 
> > > > > > > > > > >  wrote:
> > > > > > > > > > >>
> > > > > > > > > > >> On Thu, Oct 22, 2020 at 03:00:06AM +0300, Dmitry 
> > > > > > > > > > >> Osipenko wrote:
> > > > > > > > > > >>> 22.10.2020 02:40, Kees Cook пишет:
> > > > > > > > > >  On Thu, Oct 22, 2020 at 01:57:37AM +0300, Dmitry 
> > > > > > > > > >  Osipenko wrote:
> > > > > > > > > > > The vfp_kmode_exception() function now is unreachable 
> > > > > > > > > > > using relative
> > > > > > > > > > > branching in THUMB2 kernel configuration, resulting 
> > > > > > > > > > > in a "relocation
> > > > > > > > > > > truncated to fit: R_ARM_THM_JUMP19 against symbol 
> > > > > > > > > > > `vfp_kmode_exception'"
> > > > > > > > > > > linker error. Let's use long jump in order to fix the 
> > > > > > > > > > > issue.
> > > > > > > > > > 
> > > > > > > > > >  Eek. Is this with gcc or clang?
> > > > > > > > > > >>>
> > > > > > > > > > >>> GCC 9.3.0
> > > > > > > > > > >>>
> > > > > > > > > > > Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and 
> > > > > > > > > > > AutoFDO input sections")
> > > > > > > > > > 
> > > > > > > > > >  Are you sure it wasn't 512dd2eebe55 ("arm/build: Add 
> > > > > > > > > >  missing sections") ?
> > > > > > > > > >  That commit may have implicitly moved the location of 
> > > > > > > > > >  .vfp11_veneer,
> > > > > > > > > >  though I thought I had chosen the correct position.
> > > > > > > > > > >>>
> > > > > > > > > > >>> I re-checked that the fixes tag is correct.
> > > > > > > > > > >>>
> > > > > > > > > > > Signed-off-by: Dmitry Osipenko 
> > > > > > > > > > > ---
> > > > > > > > > > >  arch/arm/vfp/vfphw.S | 3 ++-
> > > > > > > > > > >  1 file changed, 2 insertions(+), 1 deletion(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/arch/arm/vfp/vfphw.S 
> > > > > > > > > > > b/arch/arm/vfp/vfphw.S
> > > > > > > > > > > index 4fcff9f59947..6e2b29f0c48d 100644
> > > > > > > > > > > --- a/arch/arm/vfp/vfphw.S
> > > > > > > > > > > +++ b/arch/arm/vfp/vfphw.S
> > > > > > > > > > > @@ -82,7 +82,8 @@ ENTRY(vfp_support_entry)
> > > > > > > > > > >ldr r3, [sp, #S_PSR]@ Neither lazy 
> > > > > > > > > > > restore nor FP exceptions
> > > > > > > > > > >and r3, r3, #MODE_MASK  @ are supported in 
> > > > > > > > > > > kernel mode
> > > > > > > > > > >teq r3, #USR_MODE
> > > > > > > > > > > -  bne vfp_kmode_exception @ Returns through 
> > > > > > > > > > > lr
> > > > > > > > > > > +  ldr r1, =vfp_kmode_exception
> > > > > > > > > > > +  bxner1  @ Returns through 
> > > > > > > > > > > lr
> > > > > > > > > > >
> > > > > > > > > > >VFPFMRX r1, FPEXC   @ Is the VFP 
> > > > > > > > > > > enabled?
> > > > > > > > > > >DBGSTR1 "fpexc %08x", r1
> > > > > > > > > > 
> > > > > > > > > >  This seems like a workaround though? I suspect the 
> > > > > > > > > >  vfp11_veneer needs
> > > > > > > > > >  moving?
> > > > > > > > > > 
> > > > > > > > > > >>>
> > > > > > > > > > >>> I don't know where it needs to be moved. Please feel 
> > > > > > > > > > >>> free to make a
> > > > > > > > > > >>> patch if you have a better idea, I'll be glad to test 
> > > > > > > > > > >>> it.
> > > > > > > > > > >>
> > > > > > > > > > >> I might have just been distracted by the common "vfp" 
> > > > > > > > > > >> prefix. It's
> > > > > > > > > > >> possible that the text section shuffling just ended up 
> > > > > > > > > > >> being very large,
> > > > > > > > > > >> so probably this patch is right then!
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > > I already sent a fix for this issue:
> > > > > > > > > > >
> > > > > > > > > > > https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9018/1
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > The offending commit contains stable tag, so I assume that 
> >

[v2 4/4] spi: aspeed: Add ASPEED FMC/SPI memory controller driver

Add driver for ASPEED BMC FMC/SPI memory controller which
supports spi-mem interface.

There are three SPI memory controllers embedded in an ASPEED SoC.
Each of them can connect to two or three SPI NOR flashes. The first
SPI memory controller is also named as Firmware Memory Controller (FMC),
which is similar to SPI memory controller. After device AC on, MCU ROM
can fetch device boot code from FMC CS 0. Thus, there exists additional
registers for boot process control in FMC.

ASPEED SPI memory controller supports single, dual and quad mode for
SPI NOR flash. It also supports two types of command mode, user mode
and command read/write mode. User mode is traditional pure SPI operations
where all transmission is controlled by CPU. Contrarily, with command
read/write mode, SPI controller can send command and address automatically
when CPU read/write related remapped address.

Besides, different wafer processes of SPI NOR flash result in different
signal response time. This phenomenon will be enlarged when SPI clock
frequency increases. ASPEED SPI memory controller provides a mechanism
for timing compensation in order to satisfy various SPI NOR flash parts
and PCB layout.

Signed-off-by: Chin-Ting Kuo 
---
 v2: Fix sparse warnings reported by kernel test robot .

 drivers/spi/Kconfig  |  10 +
 drivers/spi/Makefile |   1 +
 drivers/spi/spi-aspeed.c | 969 +++
 3 files changed, 980 insertions(+)
 create mode 100644 drivers/spi/spi-aspeed.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 5cff60de8e83..caadf8647183 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -70,6 +70,16 @@ config SPI_AR934X
  This enables support for the SPI controller present on the
  Qualcomm Atheros AR934X/QCA95XX SoCs.
 
+config SPI_ASPEED
+   tristate "ASPEED FMC/SPI Memory Controller"
+   depends on OF && HAS_IOMEM
+   help
+ Enable driver for ASPEED FMC/SPI Memory Controller.
+
+ This driver is not a generic pure SPI driver, which
+ is especially designed for spi-mem framework with
+ SPI NOR flash direct read and write features.
+
 config SPI_ATH79
tristate "Atheros AR71XX/AR724X/AR913X SPI controller driver"
depends on ATH79 || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 6fea5821662e..9e62c650fca0 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_SPI_LOOPBACK_TEST)   += 
spi-loopback-test.o
 obj-$(CONFIG_SPI_ALTERA)   += spi-altera.o
 obj-$(CONFIG_SPI_AR934X)   += spi-ar934x.o
 obj-$(CONFIG_SPI_ARMADA_3700)  += spi-armada-3700.o
+obj-$(CONFIG_SPI_ASPEED)   += spi-aspeed.o
 obj-$(CONFIG_SPI_ATMEL)+= spi-atmel.o
 obj-$(CONFIG_SPI_ATMEL_QUADSPI)+= atmel-quadspi.o
 obj-$(CONFIG_SPI_AT91_USART)   += spi-at91-usart.o
diff --git a/drivers/spi/spi-aspeed.c b/drivers/spi/spi-aspeed.c
new file mode 100644
index ..f416f894a842
--- /dev/null
+++ b/drivers/spi/spi-aspeed.c
@@ -0,0 +1,969 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * ASPEED FMC/SPI Memory Controller Driver
+ *
+ * Copyright (c) 2020, ASPEED Corporation.
+ * Copyright (c) 2015-2016, IBM Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* ASPEED FMC/SPI memory control register related */
+#define OFFSET_CE_TYPE_SETTING 0x00
+#define OFFSET_CE_ADDR_MODE_CTRL   0x04
+#define OFFSET_INTR_CTRL_STATUS0x08
+#define OFFSET_ADDR_DATA_MASK  0x0c
+#define OFFSET_CE0_CTRL_REG0x10
+#define OFFSET_CE0_DECODE_RANGE_REG0x30
+#define OFFSET_DMA_CTRL0x80
+#define OFFSET_DMA_FLASH_ADDR_REG  0x84
+#define OFFSET_DMA_RAM_ADDR_REG0x88
+#define OFFSET_DMA_LEN_REG 0x8c
+#define OFFSET_DMA_CHECKSUM_RESULT 0x90
+#define OFFSET_CE0_TIMING_COMPENSATION 0x94
+
+#define CTRL_IO_SINGLE_DATA0
+#define CTRL_IO_DUAL_DATA  BIT(29)
+#define CTRL_IO_QUAD_DATA  BIT(30)
+
+#define CTRL_IO_MODE_USER  GENMASK(1, 0)
+#define CTRL_IO_MODE_CMD_READ  BIT(0)
+#define CTRL_IO_MODE_CMD_WRITE BIT(1)
+#define CTRL_STOP_ACTIVE   BIT(2)
+
+#define CALIBRATION_LEN0x400
+#define SPI_DAM_REQUESTBIT(31)
+#define SPI_DAM_GRANT  BIT(30)
+#define SPI_DMA_CALIB_MODE BIT(3)
+#define SPI_DMA_CALC_CKSUM BIT(2)
+#define SPI_DMA_ENABLE BIT(0)
+#define SPI_DMA_STATUS BIT(11)
+
+enum aspeed_spi_ctl_reg_value {
+   ASPEED_SPI_BASE,
+   ASPEED_SPI_READ,
+   ASPEED_SPI_WRITE,
+   ASPEED_SPI_MAX,
+};
+
+#define ASPEED_SPI_MAX_CS 5
+
+struct aspeed_spi_controller;
+struct aspeed_spi_chip;
+
+struct aspeed_spi_info {
+   uint32_t cmd_io_ctrl_mask;
+   uint32_t

[v2 2/4] ARM: dts: aspeed: ast2600: Update FMC/SPI controller setting for spi-aspeed.c

- Adjust the value format of "reg" property:
  Instead of platform_get_resource(),
  platform_get_resource_byname() function can be used
  for more human-readable.
- Add "num-cs" property for FMC/SPI controller:
  Each ASPEED FMC/SPI memory controller can support more
  than a chip select. By "num-cs" property, FMC/SPI
  controller driver can know how many chip select related
  registers should be initialized at the probe stage.
  Besdies, with this property, driver can avoid accessing
  chip select which CS number is larger than the maximum
  one supported by the controller.

Signed-off-by: Chin-Ting Kuo 
---
 arch/arm/boot/dts/aspeed-g6.dtsi | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed-g6.dtsi
index b58220a49cbd..8a5c798db54e 100644
--- a/arch/arm/boot/dts/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed-g6.dtsi
@@ -89,14 +89,16 @@
};
 
fmc: spi@1e62 {
-   reg = < 0x1e62 0xc4
-   0x2000 0x1000 >;
+   reg = <0x1e62 0xc4>,
+   <0x2000 0x1000>;
+   reg-names = "spi_ctrl_reg", "spi_mmap";
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2600-fmc";
clocks = < ASPEED_CLK_AHB>;
status = "disabled";
interrupts = ;
+   num-cs = <3>;
flash@0 {
reg = < 0 >;
compatible = "jedec,spi-nor";
@@ -118,12 +120,14 @@
};
 
spi1: spi@1e63 {
-   reg = < 0x1e63 0xc4
-   0x3000 0x1000 >;
+   reg = <0x1e63 0xc4>,
+   <0x3000 0x1000>;
+   reg-names = "spi_ctrl_reg", "spi_mmap";
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2600-spi";
clocks = < ASPEED_CLK_AHB>;
+   num-cs = <2>;
status = "disabled";
flash@0 {
reg = < 0 >;
@@ -140,12 +144,14 @@
};
 
spi2: spi@1e631000 {
-   reg = < 0x1e631000 0xc4
-   0x5000 0x1000 >;
+   reg = < 0x1e631000 0xc4>,
+   <0x5000 0x1000>;
+   reg-names = "spi_ctrl_reg", "spi_mmap";
#address-cells = <1>;
#size-cells = <0>;
compatible = "aspeed,ast2600-spi";
clocks = < ASPEED_CLK_AHB>;
+   num-cs = <3>;
status = "disabled";
flash@0 {
reg = < 0 >;
-- 
2.17.1

[v2 1/4] dt-bindings: spi: Add binding file for ASPEED FMC/SPI memory controller

Create binding file with YAML syntax for ASPEED FMC/SPI memory controller.

Signed-off-by: Chin-Ting Kuo 
---
 .../bindings/spi/aspeed,spi-aspeed.yaml   | 66 +++
 1 file changed, 66 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/aspeed,spi-aspeed.yaml

diff --git a/Documentation/devicetree/bindings/spi/aspeed,spi-aspeed.yaml 
b/Documentation/devicetree/bindings/spi/aspeed,spi-aspeed.yaml
new file mode 100644
index ..41b9692c7226
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/aspeed,spi-aspeed.yaml
@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/aspeed,spi-aspeed.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SPI memory controller for ASPEED SoCs
+
+maintainers:
+  - Chin-Ting Kuo 
+
+description: |
+  There are three SPI memory controllers embedded in a ASPEED SoC.
+  They are usually connected to SPI NOR flashes. Each of them has
+  more than a chip select. They also support SPI single, dual and
+  quad IO modes for SPI NOR flash.
+
+allOf:
+  - $ref: /spi/spi-controller.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - enum:
+  - aspeed,ast2600-fmc
+  - aspeed,ast2600-spi
+
+  reg:
+items:
+  - description: the control register location and length
+  - description: the flash memory mapping address and length
+
+  clocks:
+description: AHB bus clock which will be converted to SPI bus clock
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - num-cs
+
+unevaluatedProperties: false
+
+examples:
+  - |
+#include 
+spi1: spi@1e63 {
+  compatible = "aspeed,ast2600-spi";
+  reg = <0x1e63 0xc4>, <0x3000 0x1000>;
+  reg-names = "spi_ctrl_reg", "spi_mmap";
+  clocks = < ASPEED_CLK_AHB>;
+  num-cs = <2>;
+  #address-cells = <1>;
+  #size-cells = <0>;
+  flash@0 {
+compatible = "jedec,spi-nor";
+reg = <0>;
+spi-max-frequency = <5000>;
+  };
+  flash@1 {
+compatible = "jedec,spi-nor";
+reg = <1>;
+spi-max-frequency = <5000>;
+  };
+};
-- 
2.17.1

[v2 3/4] ARM: dts: aspeed: ast2600-evb: Adjust SPI flash configuration

- Enable FMC CS1 and SPI2 CS0 SPI NOR flashes since both of
  these two flashes are mounted on AST2600 EVB by default.
- Remove spi-max-frequency setting: 50MHz is usual SPI bus
  frequency adopted on AST2600 EVB which has already been
  configured in aspeed-g6.dtsi.

Signed-off-by: Chin-Ting Kuo 
---
 arch/arm/boot/dts/aspeed-ast2600-evb.dts | 26 
 1 file changed, 22 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/aspeed-ast2600-evb.dts 
b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
index 8d0f4656aa05..5a2e4612d155 100644
--- a/arch/arm/boot/dts/aspeed-ast2600-evb.dts
+++ b/arch/arm/boot/dts/aspeed-ast2600-evb.dts
@@ -96,12 +96,11 @@
 
  {
status = "okay";
+
flash@0 {
status = "okay";
m25p,fast-read;
label = "bmc";
-   spi-max-frequency = <5000>;
-
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
@@ -133,18 +132,37 @@
};
};
};
+
+   flash@1 {
+   status = "okay";
+   m25p,fast-read;
+   label = "fmc0:1";
+   };
 };
 
  {
status = "okay";
+
pinctrl-names = "default";
pinctrl-0 = <_spi1_default>;
 
flash@0 {
status = "okay";
m25p,fast-read;
-   label = "pnor";
-   spi-max-frequency = <1>;
+   label = "spi1:0";
+   };
+};
+
+ {
+   status = "okay";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_spi2_default>;
+
+   flash@0 {
+   status = "okay";
+   m25p,fast-read;
+   label = "spi2:0";
};
 };
 
-- 
2.17.1

[v2 0/4] Porting ASPEED FMC/SPI memory controller driver

This patch series aims to porting ASPEED FMC/SPI memory controller
driver with spi-mem interface. Adjust device tree setting of SPI NOR
flash in order to fit real AST2600 EVB and new SPI memory controller
driver. Also, this patch has been verified on AST2600-A1 EVB.

v2: Fix sparse warnings reported by kernel test robot .

Chin-Ting Kuo (4):
  dt-bindings: spi: Add binding file for ASPEED FMC/SPI memory
controller
  ARM: dts: aspeed: ast2600: Update FMC/SPI controller setting for
spi-aspeed.c
  ARM: dts: aspeed: ast2600-evb: Adjust SPI flash configuration
  spi: aspeed: Add ASPEED FMC/SPI memory controller driver

 .../bindings/spi/aspeed,spi-aspeed.yaml   |  66 ++
 arch/arm/boot/dts/aspeed-ast2600-evb.dts  |  26 +-
 arch/arm/boot/dts/aspeed-g6.dtsi  |  18 +-
 drivers/spi/Kconfig   |  10 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/spi-aspeed.c  | 969 ++
 6 files changed, 1080 insertions(+), 10 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/spi/aspeed,spi-aspeed.yaml
 create mode 100644 drivers/spi/spi-aspeed.c

-- 
2.17.1

Re: INFO: task can't die in nbd_ioctl

2020-11-02 Thread Ming Lei

On Sat, Oct 31, 2020 at 4:01 AM syzbot
 wrote:
>
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:4e78c578 Add linux-next specific files for 20201030
> git tree:   linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=158c179850
> kernel config:  https://syzkaller.appspot.com/x/.config?x=83318758268dc331
> dashboard link: https://syzkaller.appspot.com/bug?extid=69a90a5e8f6b59086b2a
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=15e051a850
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=15bf75b850

Not reproduce this issue by above C reproducer with the kernel config
in hours running
on linus tree.

Thanks,
Ming Lei

Re: [PATCH v1 2/2] scsi: ufs: Try to save power mode change and UIC cmd completion timeout

2020-11-02 Thread Stanley Chu

Hi Can,

Except for below nit, otherwise looks good to me.

Reviewed-by: Stanley Chu 

On Mon, 2020-11-02 at 22:24 -0800, Can Guo wrote:
> Use the uic_cmd->cmd_active as a flag to track the lifecycle of an UIC cmd.
> The flag is set before send the UIC cmd and cleared in IRQ handler. When a
> PMC or UIC cmd completion timeout happens, if the flag is not set, instead
> of returning timeout error, we still treat it as a successful operation.
> This is to deal with the scenario in which completion has been raised but
> the one waiting for the completion cannot be awaken in time due to kernel
> scheduling problem.
> 
> Signed-off-by: Can Guo 
> ---
>  drivers/scsi/ufs/ufshcd.c | 26 --
>  drivers/scsi/ufs/ufshcd.h |  2 ++
>  2 files changed, 26 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index efa7d86..7f33310 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -2122,10 +2122,20 @@ ufshcd_wait_for_uic_cmd(struct ufs_hba *hba, struct 
> uic_command *uic_cmd)
>   unsigned long flags;
>  
>   if (wait_for_completion_timeout(_cmd->done,
> - msecs_to_jiffies(UIC_CMD_TIMEOUT)))
> + msecs_to_jiffies(UIC_CMD_TIMEOUT))) {
>   ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
> - else
> + } else {
>   ret = -ETIMEDOUT;
> + dev_err(hba->dev,
> + "uic cmd 0x%x with arg3 0x%x completion timeout\n",
> + uic_cmd->command, uic_cmd->argument3);
> +
> + if (!uic_cmd->cmd_active) {
> + dev_err(hba->dev, "%s: UIC cmd has been completed, 
> return the result\n",
> + __func__);
> + ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
> + }
> + }
>  
>   spin_lock_irqsave(hba->host->host_lock, flags);
>   hba->active_uic_cmd = NULL;
> @@ -2157,6 +2167,7 @@ __ufshcd_send_uic_cmd(struct ufs_hba *hba, struct 
> uic_command *uic_cmd,
>   if (completion)
>   init_completion(_cmd->done);
>  
> + uic_cmd->cmd_active = 1;
>   ufshcd_dispatch_uic_cmd(hba, uic_cmd);
>  
>   return 0;
> @@ -3828,10 +3839,18 @@ static int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, 
> struct uic_command *cmd)
>   dev_err(hba->dev,
>   "pwr ctrl cmd 0x%x with mode 0x%x completion timeout\n",
>   cmd->command, cmd->argument3);
> +
> + if (!cmd->cmd_active) {
> + dev_err(hba->dev, "%s: Power Mode Change operation has 
> been completed, go check UPMCRS\n",
> + __func__);
> + goto check_upmcrs;
> + }
> +
>   ret = -ETIMEDOUT;
>   goto out;
>   }
>  
> +check_upmcrs:
>   status = ufshcd_get_upmcrs(hba);
>   if (status != PWR_LOCAL) {
>   dev_err(hba->dev,
> @@ -4923,11 +4942,14 @@ static irqreturn_t ufshcd_uic_cmd_compl(struct 
> ufs_hba *hba, u32 intr_status)
>   ufshcd_get_uic_cmd_result(hba);
>   hba->active_uic_cmd->argument3 =
>   ufshcd_get_dme_attr_val(hba);
> + if (!hba->uic_async_done)

Is this check necessary?

> + hba->active_uic_cmd->cmd_active = 0;
>   complete(>active_uic_cmd->done);
>   retval = IRQ_HANDLED;
>   }
>  
>   if ((intr_status & UFSHCD_UIC_PWR_MASK) && hba->uic_async_done) {
> + hba->active_uic_cmd->cmd_active = 0;
>   complete(hba->uic_async_done);
>   retval = IRQ_HANDLED;
>   }
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 66e5338..be982ed 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -64,6 +64,7 @@ enum dev_cmd_type {
>   * @argument1: UIC command argument 1
>   * @argument2: UIC command argument 2
>   * @argument3: UIC command argument 3
> + * @cmd_active: Indicate if UIC command is outstanding
>   * @done: UIC command completion
>   */
>  struct uic_command {
> @@ -71,6 +72,7 @@ struct uic_command {
>   u32 argument1;
>   u32 argument2;
>   u32 argument3;
> + int cmd_active;
>   struct completion done;
>  };
>  



Thanks,
Stanley Chu

drivers/i2c/busses/i2c-mlxbf.c:2296:8: error: implicit declaration of function 'acpi_device_uid'

Hi Khalil,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   b7cbaf59f62f8ab8f157698f9e31642bff525bd0
commit: b5b5b32081cd206baa6e58cca7f112d9723785d6 i2c: mlxbf: I2C SMBus driver 
for Mellanox BlueField SoC
date:   5 weeks ago
config: arm64-randconfig-r011-20201103 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
1fcd5d5655e29f85e12b402e32974f207cfedf32)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b5b5b32081cd206baa6e58cca7f112d9723785d6
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout b5b5b32081cd206baa6e58cca7f112d9723785d6
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64 

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

All errors (new ones prefixed by >>):

>> drivers/i2c/busses/i2c-mlxbf.c:2296:8: error: implicit declaration of 
>> function 'acpi_device_uid' [-Werror,-Wimplicit-function-declaration]
   uid = acpi_device_uid(adev);
 ^
   drivers/i2c/busses/i2c-mlxbf.c:2296:8: note: did you mean 'cpu_device_up'?
   include/linux/cpu.h:93:5: note: 'cpu_device_up' declared here
   int cpu_device_up(struct device *dev);
   ^
   drivers/i2c/busses/i2c-mlxbf.c:2296:6: warning: incompatible integer to 
pointer conversion assigning to 'const char *' from 'int' [-Wint-conversion]
   uid = acpi_device_uid(adev);
   ^ ~
   1 warning and 1 error generated.

vim +/acpi_device_uid +2296 drivers/i2c/busses/i2c-mlxbf.c

  2274  
  2275  static int mlxbf_i2c_acpi_probe(struct device *dev, struct 
mlxbf_i2c_priv *priv)
  2276  {
  2277  const struct acpi_device_id *aid;
  2278  struct acpi_device *adev;
  2279  unsigned long bus_id = 0;
  2280  const char *uid;
  2281  int ret;
  2282  
  2283  if (acpi_disabled)
  2284  return -ENOENT;
  2285  
  2286  adev = ACPI_COMPANION(dev);
  2287  if (!adev)
  2288  return -ENXIO;
  2289  
  2290  aid = acpi_match_device(mlxbf_i2c_acpi_ids, dev);
  2291  if (!aid)
  2292  return -ENODEV;
  2293  
  2294  priv->chip = (struct mlxbf_i2c_chip_info *)aid->driver_data;
  2295  
> 2296  uid = acpi_device_uid(adev);
  2297  if (!uid || !(*uid)) {
  2298  dev_err(dev, "Cannot retrieve UID\n");
  2299  return -ENODEV;
  2300  }
  2301  
  2302  ret = kstrtoul(uid, 0, _id);
  2303  if (!ret)
  2304  priv->bus = bus_id;
  2305  
  2306  return ret;
  2307  }
  2308  

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


.config.gz
Description: application/gzip

linux-next: Tree for Nov 3

2020-11-02 Thread Stephen Rothwell

Hi all,

Changes since 20201102:

The imx-mxs tree gained a build failure for which I reverted a commit.

The f2fs tree gained a build failure so I used the version from
next-20201102.

The amdgpu tree gained a conflict against Linus' tree.

The drm-misc tree gained a conflict against the amdgpu tree.

The pinctrl tree still had its build failure.

Non-merge commits (relative to Linus' tree): 2680
 3072 files changed, 350481 insertions(+), 36125 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig and htmldocs. And finally, a simple boot test
of the powerpc pseries_le_defconfig kernel in qemu (with and without
kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 327 trees (counting Linus' and 85 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (b7cbaf59f62f Merge branch 'akpm' (patches from Andrew))
Merging fixes/fixes (9123e3a74ec7 Linux 5.9-rc1)
Merging kbuild-current/fixes (d1889589a4f5 builddeb: Fix rootless build in 
setuid/setgid directory)
Merging arc-current/for-curr (3b57533b460c ARC: [plat-hsdk] Remap CCMs super 
early in asm boot trampoline)
Merging arm-current/fixes (9fa2e7af3d53 ARM: 9019/1: kprobes: Avoid 
fortify_panic() when copying optprobe template)
Merging arm64-fixes/for-next/fixes (ec9d78070de9 arm64: Change .weak to 
SYM_FUNC_START_WEAK_PI for arch/arm64/lib/mem*.S)
Merging arm-soc-fixes/arm/fixes (3d696f42c7f4 soc: ti: ti_sci_pm_domains: check 
for proper args count in xlate)
Merging drivers-memory-fixes/fixes (3650b228f83a Linux 5.10-rc1)
Merging m68k-current/for-linus (50c5feeea0af ide/macide: Convert Mac IDE driver 
to platform driver)
Merging powerpc-fixes/fixes (99f070b62322 powerpc/smp: Call rcu_cpu_starting() 
earlier)
Merging s390-fixes/fixes (8e90b4b1305a s390: correct __bootdata / 
__bootdata_preserved macros)
Merging sparc/master (0a95a6d1a4cd sparc: use for_each_child_of_node() macro)
Merging fscrypt-current/for-stable (2b4eae95c736 fscrypt: don't evict dirty 
inodes after removing key)
Merging net/master (99cab7107d91 net: dsa: qca8k: Fix port MTU setting)
Merging bpf/master (7a078d2d1880 libbpf, hashmap: Fix undefined behavior in 
hash_bits)
Merging ipsec/master (a779d91314ca net: xfrm: fix a race condition during 
allocing spi)
Merging netfilter/master (859191b234f8 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf)
Merging ipvs/master (c77761c8a594 netfilter: nf_fwd_netdev: clear timestamp in 
forwarding path)
Merging wireless-drivers/master (04516706bb99 iwlwifi: pcie: limit memory read 
spin time)
Merging mac80211/master (c2f468145211 mac80211: don't require VHT elements for 
HE on 2.4 GHz)
Merging rdma-fixes/for-rc (00469c97ef64 RDMA/vmw_pvrdma: Fix the active_speed 
and phys_state value)
Merging sound-current/for-linus (9fc149c3bce7 ALSA: hda: Reinstate 
runtime_allow() for all hda controllers)
Merging sound-asoc-fixes/for-linus (47568405ff83 Merge remote-tracking branch 
'asoc/for-5.10' into asoc-linus)
Merging regmap-fixes/for-linus (780f88b04704 Merge remote-tracking branch 
'regmap/for-5.10' into regmap-linus)
Merging regulator-fixes/for-linus (c432bf3e3d82 Merge remote-tracking branch 
'regulator/for-5.10' into regulator-linus)
Merging spi-fixes/for-linus (21d3055d1ac7 Merge remote-tracking branch 
'spi/for-5.10' into spi-linus)
Merging pci-current/for-linus (af0dd809f3d3 PCI: Add Designated Vendor-Specific 
Extended Capability #defines)
Merging driver-core.current/driver-core-linus (

RE: [PATCH v1 1/6] scsi: ufs-mediatek: Assign arguments with correct type

2020-11-02 Thread Avri Altman

> 
> In ufs_mtk_unipro_set_lpm(), use specific unsigned values
> as the argument to invoke ufshcd_dme_set().
> 
> In the same time, change the name of ufs_mtk_unipro_set_pm()
> to ufs_mtk_unipro_set_lpm() to align the naming convention
> in MediaTek UFS driver.
> 
> Signed-off-by: Stanley Chu 
Looks like this patch is gilding the lily?

> ---
>  drivers/scsi/ufs/ufs-mediatek.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
> index 8df73bc2f8cb..0196a89055b5 100644
> --- a/drivers/scsi/ufs/ufs-mediatek.c
> +++ b/drivers/scsi/ufs/ufs-mediatek.c
> @@ -639,14 +639,14 @@ static int ufs_mtk_pwr_change_notify(struct
> ufs_hba *hba,
> return ret;
>  }
> 
> -static int ufs_mtk_unipro_set_pm(struct ufs_hba *hba, bool lpm)
> +static int ufs_mtk_unipro_set_lpm(struct ufs_hba *hba, bool lpm)
>  {
> int ret;
> struct ufs_mtk_host *host = ufshcd_get_variant(hba);
> 
> ret = ufshcd_dme_set(hba,
>  UIC_ARG_MIB_SEL(VS_UNIPROPOWERDOWNCONTROL, 0),
> -lpm);
> +lpm ? 1 : 0);
bool is implicitly converted to int anyway?

> if (!ret || !lpm) {
> /*
>  * Forcibly set as non-LPM mode if UIC commands is failed
> @@ -664,7 +664,7 @@ static int ufs_mtk_pre_link(struct ufs_hba *hba)
> int ret;
> u32 tmp;
> 
> -   ret = ufs_mtk_unipro_set_pm(hba, false);
> +   ret = ufs_mtk_unipro_set_lpm(hba, false);
> if (ret)
> return ret;
> 
> @@ -774,7 +774,7 @@ static int ufs_mtk_link_set_hpm(struct ufs_hba
> *hba)
> if (err)
> return err;
> 
> -   err = ufs_mtk_unipro_set_pm(hba, false);
> +   err = ufs_mtk_unipro_set_lpm(hba, false);
> if (err)
> return err;
> 
> @@ -795,10 +795,10 @@ static int ufs_mtk_link_set_lpm(struct ufs_hba
> *hba)
>  {
> int err;
> 
> -   err = ufs_mtk_unipro_set_pm(hba, true);
> +   err = ufs_mtk_unipro_set_lpm(hba, true);
> if (err) {
> /* Resume UniPro state for following error recovery */
> -   ufs_mtk_unipro_set_pm(hba, false);
> +   ufs_mtk_unipro_set_lpm(hba, false);
> return err;
> }
> 
> --
> 2.18.0

[PATCH v3 5/6] MIPS: Loongson64: SMP: Fix up play_dead jump indicator

In play_dead function, the whole 64-bit PC mailbox was used as a indicator
to determine if the master core had written boot jump information.

However, after we introduced CSR mailsend, the hardware will not guarante
an atomic write for the 64-bit PC mailbox. Thus we have to use the lower
32-bit which is written at the last as the jump indicator instead.

Signed-off-by: Lu Zeng 
Signed-off-by: Jun Yi 
Signed-off-by: Tiezhu Yang 
---

v2: No changes
v3: Update the commit message and comment

 arch/mips/loongson64/smp.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c
index 736e98d..aa0cd72 100644
--- a/arch/mips/loongson64/smp.c
+++ b/arch/mips/loongson64/smp.c
@@ -764,9 +764,10 @@ static void loongson3_type3_play_dead(int *state_addr)
"1: li%[count], 0x100 \n" /* wait for init loop 
*/
"2: bnez  %[count], 2b\n" /* limit mailbox 
access */
"   addiu %[count], -1\n"
-   "   ld%[initfunc], 0x20(%[base])  \n" /* get PC via mailbox 
*/
+   "   lw%[initfunc], 0x20(%[base])  \n" /* check lower 32-bit 
as jump indicator */
"   beqz  %[initfunc], 1b \n"
"   nop   \n"
+   "   ld%[initfunc], 0x20(%[base])  \n" /* get PC (whole 
64-bit) via mailbox */
"   ld$sp, 0x28(%[base])  \n" /* get SP via mailbox 
*/
"   ld$gp, 0x30(%[base])  \n" /* get GP via mailbox 
*/
"   ld$a1, 0x38(%[base])  \n"
-- 
2.1.0

[PATCH v3 3/6] MIPS: Loongson64: Set IPI_Enable register per core by itself

In the current code, for example, core 1 sets Core[0, 1, 2, 3]_IPI_Enalbe
register and core 2, 3 do the same thing on the 1-way Loongson64 platform,
this is not necessary. Set IPI_Enable register per core by itself to avoid
duplicate operations and make the logic more clear.

Signed-off-by: Tiezhu Yang 
---

v2: No changes
v3: No changes

 arch/mips/loongson64/smp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c
index e744e1b..7d58853 100644
--- a/arch/mips/loongson64/smp.c
+++ b/arch/mips/loongson64/smp.c
@@ -348,8 +348,7 @@ static void loongson3_init_secondary(void)
/* Set interrupt mask, but don't enable */
change_c0_status(ST0_IM, imask);
 
-   for (i = 0; i < num_possible_cpus(); i++)
-   loongson3_ipi_write32(0x, 
ipi_en0_regs[cpu_logical_map(i)]);
+   loongson3_ipi_write32(0x, ipi_en0_regs[cpu_logical_map(cpu)]);
 
per_cpu(cpu_state, cpu) = CPU_ONLINE;
cpu_set_core(_data[cpu],
@@ -420,6 +419,7 @@ static void __init loongson3_smp_setup(void)
ipi_status0_regs_init();
ipi_en0_regs_init();
ipi_mailbox_buf_init();
+   loongson3_ipi_write32(0x, ipi_en0_regs[cpu_logical_map(0)]);
cpu_set_core(_data[0],
 cpu_logical_map(0) % loongson_sysconf.cores_per_package);
cpu_data[0].package = cpu_logical_map(0) / 
loongson_sysconf.cores_per_package;
-- 
2.1.0

[PATCH v3 1/6] MIPS: Loongson64: Do not write the read only field LPA of CP0_CONFIG3

The field LPA of CP0_CONFIG3 register is read only for Loongson64, so the
write operations are meaningless, remove them.

Signed-off-by: Tiezhu Yang 
---

v2: No changes
v3: No changes

 arch/mips/include/asm/mach-loongson64/kernel-entry-init.h | 8 
 arch/mips/loongson64/numa.c   | 3 ---
 2 files changed, 11 deletions(-)

diff --git a/arch/mips/include/asm/mach-loongson64/kernel-entry-init.h 
b/arch/mips/include/asm/mach-loongson64/kernel-entry-init.h
index 87a5bfb..e4d77f4 100644
--- a/arch/mips/include/asm/mach-loongson64/kernel-entry-init.h
+++ b/arch/mips/include/asm/mach-loongson64/kernel-entry-init.h
@@ -19,10 +19,6 @@
.macro  kernel_entry_setup
.setpush
.setmips64
-   /* Set LPA on LOONGSON3 config3 */
-   mfc0t0, CP0_CONFIG3
-   or  t0, (0x1 << 7)
-   mtc0t0, CP0_CONFIG3
/* Set ELPA on LOONGSON3 pagegrain */
mfc0t0, CP0_PAGEGRAIN
or  t0, (0x1 << 29)
@@ -54,10 +50,6 @@
.macro  smp_slave_setup
.setpush
.setmips64
-   /* Set LPA on LOONGSON3 config3 */
-   mfc0t0, CP0_CONFIG3
-   or  t0, (0x1 << 7)
-   mtc0t0, CP0_CONFIG3
/* Set ELPA on LOONGSON3 pagegrain */
mfc0t0, CP0_PAGEGRAIN
or  t0, (0x1 << 29)
diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
index cf9459f..c7e3cced 100644
--- a/arch/mips/loongson64/numa.c
+++ b/arch/mips/loongson64/numa.c
@@ -40,9 +40,6 @@ static void enable_lpa(void)
unsigned long value;
 
value = __read_32bit_c0_register($16, 3);
-   value |= 0x0080;
-   __write_32bit_c0_register($16, 3, value);
-   value = __read_32bit_c0_register($16, 3);
pr_info("CP0_Config3: CP0 16.3 (0x%lx)\n", value);
 
value = __read_32bit_c0_register($5, 1);
-- 
2.1.0

[PATCH v3 2/6] MIPS: Loongson64: Set the field ELPA of CP0_PAGEGRAIN only once

The field ELPA of CP0_PAGEGRAIN register is set at the beginning
of the kernel entry point in kernel-entry-init.h, no need to set
it again in numa.c, we can remove enable_lpa() and only print the
related information.

Signed-off-by: Tiezhu Yang 
---

v2: No changes
v3: No changes

 arch/mips/loongson64/numa.c | 17 ++---
 1 file changed, 2 insertions(+), 15 deletions(-)

diff --git a/arch/mips/loongson64/numa.c b/arch/mips/loongson64/numa.c
index c7e3cced..509b360 100644
--- a/arch/mips/loongson64/numa.c
+++ b/arch/mips/loongson64/numa.c
@@ -35,20 +35,6 @@ EXPORT_SYMBOL(__node_data);
 cpumask_t __node_cpumask[MAX_NUMNODES];
 EXPORT_SYMBOL(__node_cpumask);
 
-static void enable_lpa(void)
-{
-   unsigned long value;
-
-   value = __read_32bit_c0_register($16, 3);
-   pr_info("CP0_Config3: CP0 16.3 (0x%lx)\n", value);
-
-   value = __read_32bit_c0_register($5, 1);
-   value |= 0x2000;
-   __write_32bit_c0_register($5, 1, value);
-   value = __read_32bit_c0_register($5, 1);
-   pr_info("CP0_PageGrain: CP0 5.1 (0x%lx)\n", value);
-}
-
 static void cpu_node_probe(void)
 {
int i;
@@ -240,7 +226,8 @@ EXPORT_SYMBOL(pcibus_to_node);
 
 void __init prom_init_numa_memory(void)
 {
-   enable_lpa();
+   pr_info("CP0_Config3: CP0 16.3 (0x%x)\n", read_c0_config3());
+   pr_info("CP0_PageGrain: CP0 5.1 (0x%x)\n", read_c0_pagegrain());
prom_meminit();
 }
 EXPORT_SYMBOL(prom_init_numa_memory);
-- 
2.1.0

[PATCH v3 4/6] MIPS: Loongson64: Add Mail_Send support for 3A4000+ CPU

Loongson 3A4000+ CPU has per-core Mail_Send register to send mail,
there is no need to maintain register address of each core and node,
just simply specify cpu number.

Signed-off-by: Lu Zeng 
Signed-off-by: Jianmin Lv 
Signed-off-by: Tiezhu Yang 
---

v2: Add some callbacks in csr_ipi_probe()
v3: No changes

 .../include/asm/mach-loongson64/loongson_regs.h|  10 ++
 arch/mips/loongson64/smp.c | 120 +
 2 files changed, 107 insertions(+), 23 deletions(-)

diff --git a/arch/mips/include/asm/mach-loongson64/loongson_regs.h 
b/arch/mips/include/asm/mach-loongson64/loongson_regs.h
index 83dbb9f..1659935 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson_regs.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson_regs.h
@@ -227,6 +227,16 @@ static inline void csr_writeq(u64 val, u32 reg)
 #define CSR_IPI_SEND_CPU_SHIFT 16
 #define CSR_IPI_SEND_BLOCK BIT(31)
 
+#define LOONGSON_CSR_MAIL_BUF0 0x1020
+#define LOONGSON_CSR_MAIL_SEND 0x1048
+#define CSR_MAIL_SEND_BLOCKBIT_ULL(31)
+#define CSR_MAIL_SEND_BOX_LOW(box) (box << 1)
+#define CSR_MAIL_SEND_BOX_HIGH(box)((box << 1) + 1)
+#define CSR_MAIL_SEND_BOX_SHIFT2
+#define CSR_MAIL_SEND_CPU_SHIFT16
+#define CSR_MAIL_SEND_BUF_SHIFT32
+#define CSR_MAIL_SEND_H32_MASK 0xULL
+
 static inline u64 drdtime(void)
 {
int rID = 0;
diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c
index 7d58853..736e98d 100644
--- a/arch/mips/loongson64/smp.c
+++ b/arch/mips/loongson64/smp.c
@@ -53,6 +53,29 @@ static uint32_t core0_c0count[NR_CPUS];
 
 u32 (*ipi_read_clear)(int cpu);
 void (*ipi_write_action)(int cpu, u32 action);
+void (*ipi_write_enable)(int cpu);
+void (*ipi_clear_buf)(int cpu);
+void (*ipi_write_buf)(int cpu, struct task_struct *idle);
+
+/* send mail via Mail_Send register for 3A4000+ CPU */
+static void csr_mail_send(uint64_t data, int cpu, int mailbox)
+{
+   uint64_t val;
+
+   /* send high 32 bits */
+   val = CSR_MAIL_SEND_BLOCK;
+   val |= (CSR_MAIL_SEND_BOX_HIGH(mailbox) << CSR_MAIL_SEND_BOX_SHIFT);
+   val |= (cpu << CSR_MAIL_SEND_CPU_SHIFT);
+   val |= (data & CSR_MAIL_SEND_H32_MASK);
+   csr_writeq(val, LOONGSON_CSR_MAIL_SEND);
+
+   /* send low 32 bits */
+   val = CSR_MAIL_SEND_BLOCK;
+   val |= (CSR_MAIL_SEND_BOX_LOW(mailbox) << CSR_MAIL_SEND_BOX_SHIFT);
+   val |= (cpu << CSR_MAIL_SEND_CPU_SHIFT);
+   val |= (data << CSR_MAIL_SEND_BUF_SHIFT);
+   csr_writeq(val, LOONGSON_CSR_MAIL_SEND);
+};
 
 static u32 csr_ipi_read_clear(int cpu)
 {
@@ -79,6 +102,35 @@ static void csr_ipi_write_action(int cpu, u32 action)
}
 }
 
+static void csr_ipi_write_enable(int cpu)
+{
+   csr_writel(0x, LOONGSON_CSR_IPI_EN);
+}
+
+static void csr_ipi_clear_buf(int cpu)
+{
+   csr_writeq(0, LOONGSON_CSR_MAIL_BUF0);
+}
+
+static void csr_ipi_write_buf(int cpu, struct task_struct *idle)
+{
+   unsigned long startargs[4];
+
+   /* startargs[] are initial PC, SP and GP for secondary CPU */
+   startargs[0] = (unsigned long)_bootstrap;
+   startargs[1] = (unsigned long)__KSTK_TOS(idle);
+   startargs[2] = (unsigned long)task_thread_info(idle);
+   startargs[3] = 0;
+
+   pr_debug("CPU#%d, func_pc=%lx, sp=%lx, gp=%lx\n",
+   cpu, startargs[0], startargs[1], startargs[2]);
+
+   csr_mail_send(startargs[3], cpu_logical_map(cpu), 3);
+   csr_mail_send(startargs[2], cpu_logical_map(cpu), 2);
+   csr_mail_send(startargs[1], cpu_logical_map(cpu), 1);
+   csr_mail_send(startargs[0], cpu_logical_map(cpu), 0);
+}
+
 static u32 legacy_ipi_read_clear(int cpu)
 {
u32 action;
@@ -96,14 +148,53 @@ static void legacy_ipi_write_action(int cpu, u32 action)
loongson3_ipi_write32((u32)action, ipi_set0_regs[cpu]);
 }
 
+static void legacy_ipi_write_enable(int cpu)
+{
+   loongson3_ipi_write32(0x, ipi_en0_regs[cpu_logical_map(cpu)]);
+}
+
+static void legacy_ipi_clear_buf(int cpu)
+{
+   loongson3_ipi_write64(0, ipi_mailbox_buf[cpu_logical_map(cpu)] + 0x0);
+}
+
+static void legacy_ipi_write_buf(int cpu, struct task_struct *idle)
+{
+   unsigned long startargs[4];
+
+   /* startargs[] are initial PC, SP and GP for secondary CPU */
+   startargs[0] = (unsigned long)_bootstrap;
+   startargs[1] = (unsigned long)__KSTK_TOS(idle);
+   startargs[2] = (unsigned long)task_thread_info(idle);
+   startargs[3] = 0;
+
+   pr_debug("CPU#%d, func_pc=%lx, sp=%lx, gp=%lx\n",
+   cpu, startargs[0], startargs[1], startargs[2]);
+
+   loongson3_ipi_write64(startargs[3],
+   ipi_mailbox_buf[cpu_logical_map(cpu)] + 0x18);
+   loongson3_ipi_write64(startargs[2],
+   ipi_mailbox_buf[cpu_logical_map(cpu)] + 0x10);
+   loongson3_ipi_write64(startargs[1],
+

[PATCH v3 6/6] MIPS: Loongson64: Move decode_cpucfg() to loongson_regs.h

Since decode_cpucfg() is only used for Loongson64, just move
it to loongson_regs.h to avoid the pollution of common code
with #ifdef CONFIG_CPU_LOONGSON64.

Signed-off-by: Tiezhu Yang 
---

v2: No changes
v3: No changes

 .../include/asm/mach-loongson64/loongson_regs.h| 24 +
 arch/mips/kernel/cpu-probe.c   | 31 +-
 2 files changed, 25 insertions(+), 30 deletions(-)

diff --git a/arch/mips/include/asm/mach-loongson64/loongson_regs.h 
b/arch/mips/include/asm/mach-loongson64/loongson_regs.h
index 1659935..2d469d6 100644
--- a/arch/mips/include/asm/mach-loongson64/loongson_regs.h
+++ b/arch/mips/include/asm/mach-loongson64/loongson_regs.h
@@ -129,6 +129,30 @@ static inline u32 read_cpucfg(u32 reg)
 #define LOONGSON_CFG7_GCCAEQRP BIT(0)
 #define LOONGSON_CFG7_UCAWINP  BIT(1)
 
+static inline void decode_cpucfg(struct cpuinfo_mips *c)
+{
+   u32 cfg1 = read_cpucfg(LOONGSON_CFG1);
+   u32 cfg2 = read_cpucfg(LOONGSON_CFG2);
+   u32 cfg3 = read_cpucfg(LOONGSON_CFG3);
+
+   if (cfg1 & LOONGSON_CFG1_MMI)
+   c->ases |= MIPS_ASE_LOONGSON_MMI;
+
+   if (cfg2 & LOONGSON_CFG2_LEXT1)
+   c->ases |= MIPS_ASE_LOONGSON_EXT;
+
+   if (cfg2 & LOONGSON_CFG2_LEXT2)
+   c->ases |= MIPS_ASE_LOONGSON_EXT2;
+
+   if (cfg2 & LOONGSON_CFG2_LSPW) {
+   c->options |= MIPS_CPU_LDPTE;
+   c->guest.options |= MIPS_CPU_LDPTE;
+   }
+
+   if (cfg3 & LOONGSON_CFG3_LCAMP)
+   c->ases |= MIPS_ASE_LOONGSON_CAM;
+}
+
 static inline bool cpu_has_csr(void)
 {
if (cpu_has_cfg())
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index e685369..1fa2c8b 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -31,6 +31,7 @@
 #include "fpu-probe.h"
 
 #include 
+#include 
 
 /* Hardware capabilities */
 unsigned int elf_hwcap __read_mostly;
@@ -1692,33 +1693,6 @@ static inline void cpu_probe_cavium(struct cpuinfo_mips 
*c, unsigned int cpu)
}
 }
 
-#ifdef CONFIG_CPU_LOONGSON64
-#include 
-
-static inline void decode_cpucfg(struct cpuinfo_mips *c)
-{
-   u32 cfg1 = read_cpucfg(LOONGSON_CFG1);
-   u32 cfg2 = read_cpucfg(LOONGSON_CFG2);
-   u32 cfg3 = read_cpucfg(LOONGSON_CFG3);
-
-   if (cfg1 & LOONGSON_CFG1_MMI)
-   c->ases |= MIPS_ASE_LOONGSON_MMI;
-
-   if (cfg2 & LOONGSON_CFG2_LEXT1)
-   c->ases |= MIPS_ASE_LOONGSON_EXT;
-
-   if (cfg2 & LOONGSON_CFG2_LEXT2)
-   c->ases |= MIPS_ASE_LOONGSON_EXT2;
-
-   if (cfg2 & LOONGSON_CFG2_LSPW) {
-   c->options |= MIPS_CPU_LDPTE;
-   c->guest.options |= MIPS_CPU_LDPTE;
-   }
-
-   if (cfg3 & LOONGSON_CFG3_LCAMP)
-   c->ases |= MIPS_ASE_LOONGSON_CAM;
-}
-
 static inline void cpu_probe_loongson(struct cpuinfo_mips *c, unsigned int cpu)
 {
decode_configs(c);
@@ -1787,9 +1761,6 @@ static inline void cpu_probe_loongson(struct cpuinfo_mips 
*c, unsigned int cpu)
break;
}
 }
-#else
-static inline void cpu_probe_loongson(struct cpuinfo_mips *c, unsigned int 
cpu) { }
-#endif
 
 static inline void cpu_probe_ingenic(struct cpuinfo_mips *c, unsigned int cpu)
 {
-- 
2.1.0

[PATCH v3 0/6] Modify some registers operations and move decode_cpucfg() to loongson_regs.h

v2: Add some callbacks in csr_ipi probe() for patch #4
v3: Update the commit message and comment for patch #5

Tiezhu Yang (6):
  MIPS: Loongson64: Do not write the read only field LPA of CP0_CONFIG3
  MIPS: Loongson64: Set the field ELPA of CP0_PAGEGRAIN only once
  MIPS: Loongson64: Set IPI_Enable register per core by itself
  MIPS: Loongson64: Add Mail_Send support for 3A4000+ CPU
  MIPS: Loongson64: SMP: Fix up play_dead jump indicator
  MIPS: Loongson64: Move decode_cpucfg() to loongson_regs.h

 .../asm/mach-loongson64/kernel-entry-init.h|   8 --
 .../include/asm/mach-loongson64/loongson_regs.h|  34 ++
 arch/mips/kernel/cpu-probe.c   |  31 +-
 arch/mips/loongson64/numa.c|  20 +---
 arch/mips/loongson64/smp.c | 123 +
 5 files changed, 136 insertions(+), 80 deletions(-)

-- 
2.1.0

Re: [PATCH mlx5-next v1 11/11] RDMA/mlx5: Remove IB representors dead code

2020-11-02 Thread Roi Dayan





On 2020-11-01 10:15 PM, Leon Romanovsky wrote:

From: Leon Romanovsky 

Delete dead code.

Signed-off-by: Leon Romanovsky 
---
  drivers/infiniband/hw/mlx5/ib_rep.c | 31 +++--
  drivers/infiniband/hw/mlx5/ib_rep.h | 31 -
  2 files changed, 7 insertions(+), 55 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/ib_rep.c 
b/drivers/infiniband/hw/mlx5/ib_rep.c
index 9810bdd7f3bc..a1a9450ed92c 100644
--- a/drivers/infiniband/hw/mlx5/ib_rep.c
+++ b/drivers/infiniband/hw/mlx5/ib_rep.c
@@ -13,7 +13,7 @@ mlx5_ib_set_vport_rep(struct mlx5_core_dev *dev, struct 
mlx5_eswitch_rep *rep)
struct mlx5_ib_dev *ibdev;
int vport_index;

-   ibdev = mlx5_ib_get_uplink_ibdev(dev->priv.eswitch);
+   ibdev = mlx5_eswitch_uplink_get_proto_dev(dev->priv.eswitch, REP_IB);
vport_index = rep->vport_index;

ibdev->port[vport_index].rep = rep;
@@ -74,6 +74,11 @@ mlx5_ib_vport_rep_load(struct mlx5_core_dev *dev, struct 
mlx5_eswitch_rep *rep)
return ret;
  }

+static void *mlx5_ib_rep_to_dev(struct mlx5_eswitch_rep *rep)
+{
+   return rep->rep_data[REP_IB].priv;
+}
+
  static void
  mlx5_ib_vport_rep_unload(struct mlx5_eswitch_rep *rep)
  {
@@ -91,40 +96,18 @@ mlx5_ib_vport_rep_unload(struct mlx5_eswitch_rep *rep)
__mlx5_ib_remove(dev, dev->profile, MLX5_IB_STAGE_MAX);
  }

-static void *mlx5_ib_vport_get_proto_dev(struct mlx5_eswitch_rep *rep)
-{
-   return mlx5_ib_rep_to_dev(rep);
-}
-
  static const struct mlx5_eswitch_rep_ops rep_ops = {
.load = mlx5_ib_vport_rep_load,
.unload = mlx5_ib_vport_rep_unload,
-   .get_proto_dev = mlx5_ib_vport_get_proto_dev,
+   .get_proto_dev = mlx5_ib_rep_to_dev,
  };

-struct mlx5_ib_dev *mlx5_ib_get_rep_ibdev(struct mlx5_eswitch *esw,
- u16 vport_num)
-{
-   return mlx5_eswitch_get_proto_dev(esw, vport_num, REP_IB);
-}
-
  struct net_device *mlx5_ib_get_rep_netdev(struct mlx5_eswitch *esw,
  u16 vport_num)
  {
return mlx5_eswitch_get_proto_dev(esw, vport_num, REP_ETH);
  }

-struct mlx5_ib_dev *mlx5_ib_get_uplink_ibdev(struct mlx5_eswitch *esw)
-{
-   return mlx5_eswitch_uplink_get_proto_dev(esw, REP_IB);
-}
-
-struct mlx5_eswitch_rep *mlx5_ib_vport_rep(struct mlx5_eswitch *esw,
-  u16 vport_num)
-{
-   return mlx5_eswitch_vport_rep(esw, vport_num);
-}
-
  struct mlx5_flow_handle *create_flow_rule_vport_sq(struct mlx5_ib_dev *dev,
   struct mlx5_ib_sq *sq,
   u16 port)
diff --git a/drivers/infiniband/hw/mlx5/ib_rep.h 
b/drivers/infiniband/hw/mlx5/ib_rep.h
index 93f562735e89..ce1dcb105dbd 100644
--- a/drivers/infiniband/hw/mlx5/ib_rep.h
+++ b/drivers/infiniband/hw/mlx5/ib_rep.h
@@ -12,11 +12,6 @@
  extern const struct mlx5_ib_profile raw_eth_profile;

  #ifdef CONFIG_MLX5_ESWITCH
-struct mlx5_ib_dev *mlx5_ib_get_rep_ibdev(struct mlx5_eswitch *esw,
- u16 vport_num);
-struct mlx5_ib_dev *mlx5_ib_get_uplink_ibdev(struct mlx5_eswitch *esw);
-struct mlx5_eswitch_rep *mlx5_ib_vport_rep(struct mlx5_eswitch *esw,
-  u16 vport_num);
  int mlx5r_rep_init(void);
  void mlx5r_rep_cleanup(void);
  struct mlx5_flow_handle *create_flow_rule_vport_sq(struct mlx5_ib_dev *dev,
@@ -25,26 +20,6 @@ struct mlx5_flow_handle *create_flow_rule_vport_sq(struct 
mlx5_ib_dev *dev,
  struct net_device *mlx5_ib_get_rep_netdev(struct mlx5_eswitch *esw,
  u16 vport_num);
  #else /* CONFIG_MLX5_ESWITCH */
-static inline
-struct mlx5_ib_dev *mlx5_ib_get_rep_ibdev(struct mlx5_eswitch *esw,
- u16 vport_num)
-{
-   return NULL;
-}
-
-static inline
-struct mlx5_ib_dev *mlx5_ib_get_uplink_ibdev(struct mlx5_eswitch *esw)
-{
-   return NULL;
-}
-
-static inline
-struct mlx5_eswitch_rep *mlx5_ib_vport_rep(struct mlx5_eswitch *esw,
-  u16 vport_num)
-{
-   return NULL;
-}
-
  static inline int mlx5r_rep_init(void) { return 0; }
  static inline void mlx5r_rep_cleanup(void) {}
  static inline
@@ -62,10 +37,4 @@ struct net_device *mlx5_ib_get_rep_netdev(struct 
mlx5_eswitch *esw,
return NULL;
  }
  #endif
-
-static inline
-struct mlx5_ib_dev *mlx5_ib_rep_to_dev(struct mlx5_eswitch_rep *rep)
-{
-   return rep->rep_data[REP_IB].priv;
-}
  #endif /* __MLX5_IB_REP_H__ */
--
2.28.0



Reviewed-by: Roi Dayan

Re: [PATCH v1 1/2] scsi: ufs: Fix unbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

2020-11-02 Thread Stanley Chu

Hi Can,

On Mon, 2020-11-02 at 22:24 -0800, Can Guo wrote:
> The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
> decreased back in ufshcd_ungate_work() in a paired way. However, if
> specific ufshcd_hold/release sequences are met, it is possible that
> scsi_block_reqs_cnt is increased twice but only one ungate work is
> queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and

Just curious that how could this be possible? Would you have some failed
examples?

> ufshcd_ungate_work() in a paired way, increase it only if queue_work()
> returns true.
> 
> Signed-off-by: Can Guo 
> Reviewed-by: Hongwu Su 
> ---
>  drivers/scsi/ufs/ufshcd.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 847f355..efa7d86 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1634,12 +1634,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
>*/
>   /* fallthrough */
>   case CLKS_OFF:
> - ufshcd_scsi_block_requests(hba);
>   hba->clk_gating.state = REQ_CLKS_ON;
>   trace_ufshcd_clk_gating(dev_name(hba->dev),
>   hba->clk_gating.state);
> - queue_work(hba->clk_gating.clk_gating_workq,
> ->clk_gating.ungate_work);
> + if (queue_work(hba->clk_gating.clk_gating_workq,
> +>clk_gating.ungate_work))
> + ufshcd_scsi_block_requests(hba);
>   /*
>* fall through to check if we should wait for this
>* work to be done or not.

Thanks,
Stanley Chu

Re: [PATCH -next v2 1/2] watchdog: Clean up error handlings of __watchdog_register_device

2020-11-02 Thread Christophe Leroy


Hi,

Can you provide in the commit a description of what you are doing and why ?

Christophe

Le 03/11/2020 à 07:52, Wang Wensheng a écrit :

Signed-off-by: Wang Wensheng 
---
  drivers/watchdog/watchdog_core.c | 17 ++---
  1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 423844757812..c73871f41142 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -252,10 +252,8 @@ static int __watchdog_register_device(struct 
watchdog_device *wdd)
wdd->id = id;
  
  		ret = watchdog_dev_register(wdd);

-   if (ret) {
-   ida_simple_remove(_ida, id);
-   return ret;
-   }
+   if (ret)
+   goto id_remove;
}
  
  	/* Module parameter to force watchdog policy on reboot. */

@@ -273,9 +271,7 @@ static int __watchdog_register_device(struct 
watchdog_device *wdd)
if (ret) {
pr_err("watchdog%d: Cannot register reboot notifier 
(%d)\n",
   wdd->id, ret);
-   watchdog_dev_unregister(wdd);
-   ida_simple_remove(_ida, id);
-   return ret;
+   goto dev_unregister;
}
}
  
@@ -289,6 +285,13 @@ static int __watchdog_register_device(struct watchdog_device *wdd)

}
  
  	return 0;

+
+dev_unregister:
+   watchdog_dev_unregister(wdd);
+id_remove:
+   ida_simple_remove(_ida, id);
+
+   return ret;
  }
  
  /**

Re: [PATCH v4 1/2] ASoC: google: dt-bindings: modify machine bindings for two MICs case

2020-11-02 Thread Ajye Huang

Hi Rob,
Could you please kindly review this patch ?

 I had got your "reviewed-by" on v1 patch, the v1 depends on this patch series
(https://patchwork.kernel.org/patch/11773221) at that time.

Now, that patch what I depended (11773221) had made modification and
it was Applied to
   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
commit e158d2d83cab ("ASoC: google: dt-bindings: Add sc7180-trogdor
machine bindings")

I noted what I did on cover letter
Changes from v1 to v2:
- Documentation: Modify the dimc-gpios property description and examples.

That is why I bother you again to review it. Please let me know if
this looks good to you.
Thanks!

On Tue, Nov 3, 2020 at 10:54 AM Ajye Huang  wrote:
>
> Add a property "dmic-gpios" for switching between two MICs.
>
> Signed-off-by: Ajye Huang 
> ---
>  .../bindings/sound/google,sc7180-trogdor.yaml | 58 +++
>  1 file changed, 58 insertions(+)
>
> diff --git 
> a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml 
> b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
> index efc34689d6b5..9e0505467e57 100644
> --- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
> +++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml
> @@ -34,6 +34,9 @@ properties:
>"#size-cells":
>  const: 0
>
> +  dmic-gpios:
> +description: GPIO for switching between DMICs
> +
>  patternProperties:
>"^dai-link(@[0-9])?$":
>  description:
> @@ -81,6 +84,7 @@ additionalProperties: false
>  examples:
>
>- |
> +//Example 1
>  sound {
>  compatible = "google,sc7180-trogdor";
>  model = "sc7180-rt5682-max98357a-1mic";
> @@ -128,3 +132,57 @@ examples:
>  };
>  };
>  };
> +
> +  - |
> +//Example 2 (2mic case)
> +sound {
> +compatible = "google,sc7180-trogdor";
> +model = "sc7180-rt5682-max98357a-2mic";
> +
> +audio-routing =
> +"Headphone Jack", "HPOL",
> +"Headphone Jack", "HPOR";
> +
> +#address-cells = <1>;
> +#size-cells = <0>;
> +
> +dmic-gpios = < 86 0>;
> +
> +dai-link@0 {
> +link-name = "MultiMedia0";
> +reg = <0>;
> +cpu {
> +sound-dai = <_cpu 0>;
> +};
> +
> +codec {
> +sound-dai = < 0>;
> +};
> +};
> +
> +dai-link@1 {
> +link-name = "MultiMedia1";
> +reg = <1>;
> +cpu {
> +sound-dai = <_cpu 1>;
> +};
> +
> +codec {
> +sound-dai = <>;
> +};
> +};
> +
> +dai-link@2 {
> +link-name = "MultiMedia2";
> +reg = <2>;
> +cpu {
> +sound-dai = <_hdmi 0>;
> +};
> +
> +codec {
> +sound-dai = <_dp>;
> +};
> +};
> +};
> +
> +...
> --
> 2.25.1
>

[PATCH -next v2 1/2] watchdog: Clean up error handlings of __watchdog_register_device

2020-11-02 Thread Wang Wensheng

Signed-off-by: Wang Wensheng 
---
 drivers/watchdog/watchdog_core.c | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index 423844757812..c73871f41142 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -252,10 +252,8 @@ static int __watchdog_register_device(struct 
watchdog_device *wdd)
wdd->id = id;
 
ret = watchdog_dev_register(wdd);
-   if (ret) {
-   ida_simple_remove(_ida, id);
-   return ret;
-   }
+   if (ret)
+   goto id_remove;
}
 
/* Module parameter to force watchdog policy on reboot. */
@@ -273,9 +271,7 @@ static int __watchdog_register_device(struct 
watchdog_device *wdd)
if (ret) {
pr_err("watchdog%d: Cannot register reboot notifier 
(%d)\n",
   wdd->id, ret);
-   watchdog_dev_unregister(wdd);
-   ida_simple_remove(_ida, id);
-   return ret;
+   goto dev_unregister;
}
}
 
@@ -289,6 +285,13 @@ static int __watchdog_register_device(struct 
watchdog_device *wdd)
}
 
return 0;
+
+dev_unregister:
+   watchdog_dev_unregister(wdd);
+id_remove:
+   ida_simple_remove(_ida, id);
+
+   return ret;
 }
 
 /**
-- 
2.25.0

[PATCH] PM / devfreq: passive: Update frequency when start governor

2020-11-02 Thread Chanwoo Choi

If the parent device changes the their frequency before registering
the passive device, the passive device cannot receive the notification
from parent device and then the passive device cannot be able to
set the proper frequency according to the frequency of parent device.

So, when start the passive governor, update the frequency
according to the frequency of parent device.

Signed-off-by: Chanwoo Choi 
---
 drivers/devfreq/governor_passive.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/devfreq/governor_passive.c 
b/drivers/devfreq/governor_passive.c
index 63332e4a65ae..375aa636027c 100644
--- a/drivers/devfreq/governor_passive.c
+++ b/drivers/devfreq/governor_passive.c
@@ -141,6 +141,21 @@ static int devfreq_passive_event_handler(struct devfreq 
*devfreq,
if (!p_data->this)
p_data->this = devfreq;
 
+   /*
+* If the parent device changes the their frequency before
+* registering the passive device, the passive device cannot
+* receive the notification from parent device and then the
+* passive device cannot be able to set the proper frequency
+* according to the frequency of parent device.
+*
+* When start the passive governor, update the frequency
+* according to the frequency of parent device.
+*/
+   ret = devfreq_update_target(devfreq, parent->previous_freq);
+   if (ret < 0)
+   dev_warn(>dev,
+   "failed to update devfreq using passive governor\n");
+
nb->notifier_call = devfreq_passive_notifier_call;
ret = devfreq_register_notifier(parent, nb,
DEVFREQ_TRANSITION_NOTIFIER);
-- 
2.17.1

Re: [PATCH] drm/amdgpu: do not initialise global variables to 0 or NULL

On Mon, Nov 02, 2020 at 09:06:21PM +0100, Christian König wrote:
> Am 02.11.20 um 20:43 schrieb Alex Deucher:
> > On Mon, Nov 2, 2020 at 1:42 PM Deepak R Varma  wrote:
> > > Initializing global variable to 0 or NULL is not necessary and should
> > > be avoided. Issue reported by checkpatch script as:
> > > ERROR: do not initialise globals to 0 (or NULL).
> > I agree that this is technically correct, but a lot of people don't
> > seem to know that so we get a lot of comments about this code for the
> > variables that are not explicitly set.  Seems less confusing to
> > initialize them even if it not necessary.  I don't have a particularly
> > strong opinion on it however.
> 
> Agree with Alex.
> 
> Especially for the module parameters we should have a explicit init value
> for documentation purposes, even when it is 0.

Why is this one tiny driver somehow special compared to the entire rest
of the kernel?  (hint, it isn't...)

Please follow the normal coding style rules, there's no reason to ignore
them unless you like to constantly reject patches like this that get
sent to you.

thnaks,

greg k-h

[PATCH -next v2 2/2] watchdog: Fix potential dereferencing of null pointer

2020-11-02 Thread Wang Wensheng

A reboot notifier, which stops the WDT by calling the stop hook without
any check, would be registered when we set WDOG_STOP_ON_REBOOT flag.

Howerer we allow the WDT driver to omit the stop hook since commit
"d0684c8a93549" ("watchdog: Make stop function optional") and provide
a module parameter for user that controls the WDOG_STOP_ON_REBOOT flag
in commit 9232c80659e94 ("watchdog: Add stop_on_reboot parameter to
control reboot policy"). Together that commits make user potential to
insert a watchdog driver that don't provide a stop hook but with the
stop_on_reboot parameter set, then dereferencing of null pointer occurs
on system reboot.

Check the stop hook before registering the reboot notifier to fix the
issue.

Signed-off-by: Wang Wensheng 
---
 drivers/watchdog/watchdog_core.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/watchdog_core.c b/drivers/watchdog/watchdog_core.c
index c73871f41142..5269761ba072 100644
--- a/drivers/watchdog/watchdog_core.c
+++ b/drivers/watchdog/watchdog_core.c
@@ -265,8 +265,12 @@ static int __watchdog_register_device(struct 
watchdog_device *wdd)
}
 
if (test_bit(WDOG_STOP_ON_REBOOT, >status)) {
-   wdd->reboot_nb.notifier_call = watchdog_reboot_notifier;
+   if (!wdd->ops->stop) {
+   ret = -EINVAL;
+   goto dev_unregister;
+   }
 
+   wdd->reboot_nb.notifier_call = watchdog_reboot_notifier;
ret = register_reboot_notifier(>reboot_nb);
if (ret) {
pr_err("watchdog%d: Cannot register reboot notifier 
(%d)\n",
-- 
2.25.0

Re: [PATCH v2] drm/bridge: tpd12s015: Fix irq registering in tpd12s015_probe

2020-11-02 Thread Tomi Valkeinen

On 02/11/2020 16:30, YueHaibing wrote:
> gpiod_to_irq() return negative value in case of error,
> the existing code doesn't handle negative error codes.
> If the HPD gpio supports IRQs (gpiod_to_irq returns a
> valid number), we use the IRQ. If it doesn't (gpiod_to_irq
> returns an error), it gets polled via detect(). 
> 
> Fixes: cff5e6f7e83f ("drm/bridge: Add driver for the TI TPD12S015 HDMI level 
> shifter")
> Signed-off-by: YueHaibing 
> ---
> v2: Add checking for >= 0 and update commit message
> ---
>  drivers/gpu/drm/bridge/ti-tpd12s015.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-tpd12s015.c 
> b/drivers/gpu/drm/bridge/ti-tpd12s015.c
> index 514cbf0eac75..e0e015243a60 100644
> --- a/drivers/gpu/drm/bridge/ti-tpd12s015.c
> +++ b/drivers/gpu/drm/bridge/ti-tpd12s015.c
> @@ -160,7 +160,7 @@ static int tpd12s015_probe(struct platform_device *pdev)
>  
>   /* Register the IRQ if the HPD GPIO is IRQ-capable. */
>   tpd->hpd_irq = gpiod_to_irq(tpd->hpd_gpio);
> - if (tpd->hpd_irq) {
> + if (tpd->hpd_irq >= 0) {
>   ret = devm_request_threaded_irq(>dev, tpd->hpd_irq, NULL,
>   tpd12s015_hpd_isr,
>   IRQF_TRIGGER_RISING |
> 

Reviewed-by: Tomi Valkeinen 

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH v2 2/2] mm: prevent gup_fast from racing with COW during fork

2020-11-02 Thread Ahmed S. Darwish

On Mon, Nov 02, 2020 at 06:20:45PM -0800, John Hubbard wrote:
> On 11/2/20 4:41 PM, Ahmed S. Darwish wrote:
> > On Mon, Nov 02, 2020 at 08:25:32PM -0400, Jason Gunthorpe wrote:
> > > On Tue, Nov 03, 2020 at 01:17:12AM +0100, Ahmed S. Darwish wrote:
> > >
> > > > Please stick with the official exported API: raw_write_seqcount_begin().
> > >
> > > How did you know this was 'offical exported API' ??
> > >
> >
> > All the official exported seqlock.h APIs are marked with verbose
> > kernel-doc annotations on top. The rest are internal...
> >
>
> OK, but no one here was able to deduce that, probably because there is not
> enough consistency throughout the kernel to be able to assume such 
> things--even
> though your seqlock project is internally consistent. It's just not *quite*
> enough communication.
>
> I think if we added the following it would be very nice:
>

The problem is, I've already documented seqlock.h to death There are
more comments than code in there, and there is "seqlock.rst" under
Documentation/ to further describe the big picture.

There comes a point where you decide what level of documentation to add,
and what level to skip.

Because in the end, you don't want to confuse "Joe, the general driver
developer" with too much details that's not relevant to their task at
hand.  (I work in the Embedded domain, and I've seen so much ugly code
from embedded drivers/SoC developers already, sorry)

See for example my reply to Linus, where any talk about the lockdep-free
and barrier-free parts of the API was explicitly not mentioned in
seqlock.rst. This was done on purpose: 1) you want to keep the generic
case simple, but the special case do-able, 2) you want to encourage
people to use the standard entry/exit points as much as possible.

> a) Short comments to the "unofficial and internal" routines, identifying them 
> as
> such, and
>
> b) Short comments to the "official API for general use", also identifying
> those as such.
>

I really think the already added kernel-doc is sufficient...

See for example __read_seqcount_begin() and __read_seqcount_retry().
They begin with "__", but they are semi-external seqlock.h API that are
used by VFS to avoid barriers. And these APIs are then polymorphised
according to the write serialization lock type, and so on.

So the most consistent way for seqlock.h was to use kernel-doc as *the*
marker for exported functions.

This is not unique to seqlock.h by the way. The same pattern is heavily
used by the DRM folks.

Yes, of course, we can add even more comments to seqlock.h, but then, I
honestly think it would be too much that maybe people will just skip
reading the whole thing altogether...

> c) A comment about what makes "raw" actually raw, for seqlock.
>

That's already documented.

What more can really be written than what's in seqlock.h below??

  /**
   * raw_read_seqcount_begin() - begin a seqcount_t read section w/o lockdep

  /**
   * raw_seqcount_begin() - begin a seqcount_t read critical section w/o
   *lockdep and w/o counter stabilization

  /**
   * raw_write_seqcount_begin() - start a seqcount_t write section w/o lockdep

  /**
   * raw_write_seqcount_end() - end a seqcount_t write section w/o lockdep

>
> Since I'm proposing new work, I'll also offer to help, perhaps by putting 
> together
> a small patch to get it kicked off, if you approve of the idea.
>

Patches are always welcome of course, and please put me in Cc. I don't
approve or deny anything though, that's the locking maintainers job :)

Kind regards,

> John Hubbard
> NVIDIA

--
Ahmed S. Darwish
Linutronix GmbH

Re: [PATCH] thermal: ti-soc-thermal: Disable the CPU PM notifier for OMAP4430

2020-11-02 Thread J, KEERTHY





On 11/3/2020 12:12 PM, Peter Ujfalusi wrote:

Eduardo, Keerthy,

On 29/10/2020 12.51, Tony Lindgren wrote:

* Peter Ujfalusi  [201029 10:03]:

Disabling the notifier fixes the random shutdowns on OMAP4430 (ES2.0 and ES2.1)
but it does not cause any issues on OMAP4460 (PandaES) or OMAP3630 (BeagleXM).
Tony's duovero with OMAP4430 ES2.3 did not ninja-shutdown, but he also have
constant and steady stream of:
thermal thermal_zone0: failed to read out thermal zone (-5)


Works for me and I've verified duovero still keeps hitting core ret idle:


Can you pick this one up for 5.10 to make omap4430-sdp to be usable (to
not shut down randomly).
The regression was introduced in 5.10-rc1.


Peter,

Thanks for the fix.

Acked-by: Keerthy 

Best Regards,
Keerthy




Tested-by: Tony Lindgren 

Regards,

Tony



- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

Re: [PATCH] pwm: tiehrpwm: handle deferred probe with dev_err_probe()

2020-11-02 Thread Uwe Kleine-König

On Fri, Oct 30, 2020 at 10:12:54PM +0200, Grygorii Strashko wrote:
> The devm_clk_get() may return -EPROBE_DEFER which is not handled properly
> by TI EHRPWM driver and causes unnecessary boot log messages.
> 
> Hence, add proper deferred probe handling with new dev_err_probe() API.
> 
> Signed-off-by: Grygorii Strashko 

Reviewed-by: Uwe Kleine-König 

Thanks
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | https://www.pengutronix.de/ |


signature.asc
Description: PGP signature

Re: [PATCH v6 20/21] perf arm_spe: Decode memory tagging properties

2020-11-02 Thread Leo Yan

On Mon, Nov 02, 2020 at 04:25:36PM +, Dave Martin wrote:
> On Fri, Oct 30, 2020 at 02:57:23AM +, Leo Yan wrote:
> > From: Andre Przywara 
> > 
> > When SPE records a physical address, it can additionally tag the event
> > with information from the Memory Tagging architecture extension.
> > 
> > Decode the two additional fields in the SPE event payload.
> > 
> > [leoy: Refined patch to use predefined macros]
> > 
> > Signed-off-by: Andre Przywara 
> > Signed-off-by: Leo Yan 
> > ---
> >  tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c | 6 +-
> >  tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h | 2 ++
> >  2 files changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c 
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index 3fca65e9cbbf..9ec3057de86f 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -371,6 +371,7 @@ static int arm_spe_pkt_desc_addr(const struct 
> > arm_spe_pkt *packet,
> >  char *buf, size_t buf_len)
> >  {
> > int ns, el, idx = packet->index;
> > +   int ch, pat;
> > u64 payload = packet->payload;
> > int err = 0;
> >  
> > @@ -388,9 +389,12 @@ static int arm_spe_pkt_desc_addr(const struct 
> > arm_spe_pkt *packet,
> > "VA 0x%llx", payload);
> > case SPE_ADDR_PKT_HDR_INDEX_DATA_PHYS:
> > ns = !!SPE_ADDR_PKT_GET_NS(payload);
> > +   ch = !!SPE_ADDR_PKT_GET_CH(payload);
> > +   pat = SPE_ADDR_PKT_GET_PAT(payload);
> > payload = SPE_ADDR_PKT_ADDR_GET_BYTES_0_6(payload);
> > return arm_spe_pkt_snprintf(, , _len,
> > -   "PA 0x%llx ns=%d", payload, ns);
> > +   "PA 0x%llx ns=%d ch=%d, pat=%x",
> 
> Nit: given that this data is all closely related, do we really want the
> extra comma here?

No reason for adding comma.  Will remove it.

> (Note, I am not familiar with how this text is consumed, so if there are
> other reasons why the comma is needed then that's probably fine.)
> 
> > +   payload, ns, ch, pat);
> > default:
> > return 0;
> > }
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h 
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > index 7032fc141ad4..1ad14885c2a1 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.h
> > @@ -73,6 +73,8 @@ struct arm_spe_pkt {
> >  
> >  #define SPE_ADDR_PKT_GET_NS(v) (((v) & BIT_ULL(63)) >> 
> > 63)
> >  #define SPE_ADDR_PKT_GET_EL(v) (((v) & GENMASK_ULL(62, 
> > 61)) >> 61)
> > +#define SPE_ADDR_PKT_GET_CH(v) (((v) & BIT_ULL(62)) >> 
> > 62)
> > +#define SPE_ADDR_PKT_GET_PAT(v)(((v) & GENMASK_ULL(59, 
> > 56)) >> 56)
> 
> These seem to match the spec.
> 
> With or without addressing the nit above:
> 
> Reviewed-by: Dave Martin 

Thanks for reviewing.

> [...]
> 
> Cheers
> ---Dave

Re: [PATCH V2 05/10] x86/pks: Add PKS kernel API

On Mon, Nov 02, 2020 at 12:53:15PM -0800, ira.we...@intel.com wrote:
> From: Fenghua Yu 
> 
> PKS allows kernel users to define domains of page mappings which have
> additional protections beyond the paging protections.
> 
> Add an API to allocate, use, and free a protection key which identifies
> such a domain.  Export 5 new symbols pks_key_alloc(), pks_mknoaccess(),
> pks_mkread(), pks_mkrdwr(), and pks_key_free().  Add 2 new macros;
> PAGE_KERNEL_PKEY(key) and _PAGE_PKEY(pkey).
> 
> Update the protection key documentation to cover pkeys on supervisor
> pages.
> 
> Co-developed-by: Ira Weiny 
> Signed-off-by: Ira Weiny 
> Signed-off-by: Fenghua Yu 
> 
> ---
> Changes from V1
>   Per Dave Hansen
>   Add flags to pks_key_alloc() to help future proof the
>   interface if/when the key space is exhausted.
> 
> Changes from RFC V3
>   Per Dave Hansen
>   Put WARN_ON_ONCE in pks_key_free()
>   s/pks_mknoaccess/pks_mk_noaccess/
>   s/pks_mkread/pks_mk_readonly/
>   s/pks_mkrdwr/pks_mk_readwrite/
>   Change return pks_key_alloc() to EOPNOTSUPP when not
>   supported or configured
>   Per Peter Zijlstra
>   Remove unneeded preempt disable/enable
> ---
>  Documentation/core-api/protection-keys.rst | 102 ++---
>  arch/x86/include/asm/pgtable_types.h   |  12 ++
>  arch/x86/include/asm/pkeys.h   |  11 ++
>  arch/x86/include/asm/pkeys_common.h|   4 +
>  arch/x86/mm/pkeys.c| 126 +
>  include/linux/pgtable.h|   4 +
>  include/linux/pkeys.h  |  24 
>  7 files changed, 265 insertions(+), 18 deletions(-)
> 
> diff --git a/Documentation/core-api/protection-keys.rst 
> b/Documentation/core-api/protection-keys.rst
> index ec575e72d0b2..c4e6c480562f 100644
> --- a/Documentation/core-api/protection-keys.rst
> +++ b/Documentation/core-api/protection-keys.rst
> @@ -4,25 +4,33 @@
>  Memory Protection Keys
>  ==
>  
> -Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature
> -which is found on Intel's Skylake (and later) "Scalable Processor"
> -Server CPUs. It will be available in future non-server Intel parts
> -and future AMD processors.
> -
> -For anyone wishing to test or use this feature, it is available in
> -Amazon's EC2 C5 instances and is known to work there using an Ubuntu
> -17.04 image.
> -
>  Memory Protection Keys provides a mechanism for enforcing page-based
>  protections, but without requiring modification of the page tables
> -when an application changes protection domains.  It works by
> -dedicating 4 previously ignored bits in each page table entry to a
> -"protection key", giving 16 possible keys.
> +when an application changes protection domains.
> +
> +PKeys Userspace (PKU) is a feature which is found on Intel's Skylake 
> "Scalable
> +Processor" Server CPUs and later.  And It will be available in future
> +non-server Intel parts and future AMD processors.
> +
> +Future Intel processors will support Protection Keys for Supervisor pages
> +(PKS).
> +
> +For anyone wishing to test or use user space pkeys, it is available in 
> Amazon's
> +EC2 C5 instances and is known to work there using an Ubuntu 17.04 image.
> +
> +pkeys work by dedicating 4 previously Reserved bits in each page table entry 
> to
> +a "protection key", giving 16 possible keys.  User and Supervisor pages are
> +treated separately.
> +
> +Protections for each page are controlled with per CPU registers for each type
> +of page User and Supervisor.  Each of these 32 bit register stores two 
> separate
> +bits (Access Disable and Write Disable) for each key.
>  
> -There is also a new user-accessible register (PKRU) with two separate
> -bits (Access Disable and Write Disable) for each key.  Being a CPU
> -register, PKRU is inherently thread-local, potentially giving each
> -thread a different set of protections from every other thread.
> +For Userspace the register is user-accessible (rdpkru/wrpkru).  For
> +Supervisor, the register (MSR_IA32_PKRS) is accessible only to the kernel.
> +
> +Being a CPU register, pkeys are inherently thread-local, potentially giving
> +each thread an independent set of protections from every other thread.
>  
>  There are two new instructions (RDPKRU/WRPKRU) for reading and writing
>  to the new register.  The feature is only available in 64-bit mode,
> @@ -30,8 +38,11 @@ even though there is theoretically space in the PAE PTEs.  
> These
>  permissions are enforced on data access only and have no effect on
>  instruction fetches.
>  
> -Syscalls
> -
> +For kernel space rdmsr/wrmsr are used to access the kernel MSRs.
> +
> +
> +Syscalls for user space keys
> +
>  
>  There are 3 system calls which directly interact with pkeys::
>  
> @@ -98,3 +109,58 @@ with a read()::
>  The kernel will send a SIGSEGV

Re: [PATCH v4 0/6] resource: introduce union(), intersection() API

2020-11-02 Thread Greg Kroah-Hartman

On Mon, Nov 02, 2020 at 11:00:19PM +0200, Andy Shevchenko wrote:
> Some users may want to use resource library to manage their own resources,
> besides existing users that open code union() and intersection()
> implementations.
> 
> Provide a generic API for wider use.
> 
> Changelog v4:
> - added Rb tag (Rafael)
> - Cc'ed to LKML and Greg (Rafael)

Didn't we have some tests for this code somewhere?  Have you added tests
for the new functions you have added?  If not, can you do that so that
we "know" these work properly?

thanks,

greg k-h

Re: [PATCH] thermal: ti-soc-thermal: Disable the CPU PM notifier for OMAP4430

2020-11-02 Thread Peter Ujfalusi

Eduardo, Keerthy,

On 29/10/2020 12.51, Tony Lindgren wrote:
> * Peter Ujfalusi  [201029 10:03]:
>> Disabling the notifier fixes the random shutdowns on OMAP4430 (ES2.0 and 
>> ES2.1)
>> but it does not cause any issues on OMAP4460 (PandaES) or OMAP3630 
>> (BeagleXM).
>> Tony's duovero with OMAP4430 ES2.3 did not ninja-shutdown, but he also have
>> constant and steady stream of:
>> thermal thermal_zone0: failed to read out thermal zone (-5)
> 
> Works for me and I've verified duovero still keeps hitting core ret idle:

Can you pick this one up for 5.10 to make omap4430-sdp to be usable (to
not shut down randomly).
The regression was introduced in 5.10-rc1.

> Tested-by: Tony Lindgren 
> 
> Regards,
> 
> Tony
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

[f2fs-dev] [PATCH] f2fs: change write_hint for hot/warm nodes

2020-11-02 Thread Daejun Park

>From 818a76a9aee5bf225565264274d211edb07bae7d Mon Sep 17 00:00:00 2001
From: Daejun Park 
Date: Tue, 3 Nov 2020 15:30:26 +0900

In the fs-based mode of F2FS, the mapping of hot/warm node to
WRITE_LIFE_NOT_SET should be changed to WRITE_LIFE_SHORT.

As a result of analyzing the write pattern of f2fs using real workload,
hot/warm nodes have high update ratio close to hot data.[*]
However, F2FS passes write hints for hot/warm nodes as WRITE_LIFE_NOT_SET.

Furthermore, WRITE_LIFE_NOT_SET is a default value of write hint when it is
not provided from the file system.
In storage, write_hint is used to distinguish streams (e.g. NVMe).
So, the hot/warm node of F2FS is not distinguished from other write_hints,
which can make the wrong stream seperation.

* Liang, Yu, et al. "An empirical study of F2FS on mobile devices." 2017
IEEE 23rd International Conference on Embedded and Real-Time Computing
Systems and Applications (RTCSA).

Signed-off-by: Daejun Park 
---
 fs/f2fs/segment.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 1596502f7375..7b42bb10c6c3 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -3208,7 +3208,7 @@ enum rw_hint f2fs_io_type_to_rw_hint(struct f2fs_sb_info 
*sbi,
return WRITE_LIFE_EXTREME;
} else if (type == NODE) {
if (temp == WARM || temp == HOT)
-   return WRITE_LIFE_NOT_SET;
+   return WRITE_LIFE_SHORT;
else if (temp == COLD)
return WRITE_LIFE_NONE;
} else if (type == META) {
-- 
2.25.1

Re: [PATCH v6 06/21] perf arm-spe: Refactor printing string to buffer

2020-11-02 Thread Leo Yan

Hi Dave,

On Mon, Nov 02, 2020 at 05:06:53PM +, Dave Martin wrote:
> On Fri, Oct 30, 2020 at 02:57:09AM +, Leo Yan wrote:
> > When outputs strings to the decoding buffer with function snprintf(),
> > SPE decoder needs to detects if any error returns from snprintf() and if
> > so needs to directly bail out.  If snprintf() returns success, it needs
> > to update buffer pointer and reduce the buffer length so can continue to
> > output the next string into the consequent memory space.
> > 
> > This complex logics are spreading in the function arm_spe_pkt_desc() so
> > there has many duplicate codes for handling error detecting, increment
> > buffer pointer and decrement buffer size.
> > 
> > To avoid the duplicate code, this patch introduces a new helper function
> > arm_spe_pkt_snprintf() which is used to wrap up the complex logics, and
> > it's used by the caller arm_spe_pkt_desc(); if printing buffer is called
> > for multiple times in a flow, the error is a cumulative value and simply
> > returns its final value.
> > 
> > This patch also moves the variable 'blen' as the function's local
> > variable, this allows to remove the unnecessary braces and improve the
> > readability.
> > 
> > Suggested-by: Dave Martin 
> > Signed-off-by: Leo Yan 
> 
> This looks like a good refacroting now, but as pointed out by Andre this
> patch is now rather hard to review, since it combines the refactoring
> with other changes.
> 
> If reposting this series, it would be good if this could be split into a
> first patch that introduces arm_spe_pkt_snprintf() and just updates each
> snprintf() call site to use it, but without moving other code around or
> optimising anything, followed by one or more patches that clean up and
> simplify arm_spe_pkt_desc().

I will respin the patch set and follow this approach.

> If the series is otherwise mature though, then this rework may be
> overkill.
> 
> > ---
> >  .../arm-spe-decoder/arm-spe-pkt-decoder.c | 267 --
> >  1 file changed, 117 insertions(+), 150 deletions(-)
> > 
> > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c 
> > b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > index 04fd7fd7c15f..1ecaf9805b79 100644
> > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > @@ -9,6 +9,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "arm-spe-pkt-decoder.h"
> >  
> > @@ -258,192 +259,158 @@ int arm_spe_get_packet(const unsigned char *buf, 
> > size_t len,
> > return ret;
> >  }
> >  
> > +static int arm_spe_pkt_snprintf(int *err, char **buf_p, size_t *blen,
> > +   const char *fmt, ...)
> > +{
> > +   va_list ap;
> > +   int ret;
> > +
> > +   /* Bail out if any error occurred */
> > +   if (err && *err)
> > +   return *err;
> > +
> > +   va_start(ap, fmt);
> > +   ret = vsnprintf(*buf_p, *blen, fmt, ap);
> > +   va_end(ap);
> > +
> > +   if (ret < 0) {
> > +   if (err && !*err)
> > +   *err = ret;
> 
> What happens on buffer overrun (i.e., ret >= *blen)?
> 
> It looks to me like we'll advance buf_p too far, blen will wrap around,
> and the string at *buf_p won't be null terminated.  Because the return
> value is still >= 0, this condition will be returned up the stack as
> "success".

Thanks for pointint out this.  I never note for the potential issue
caused by returned value (ret >= *blen);  checked again for the
manual, it says:

"The functions snprintf() and vsnprintf() do not write more than size
bytes (including the terminating null byte ('\0')).  If the output was
truncated due to this limit, then the return value is the number of
characters (excluding  the  terminating  null  byte) which would have
been written to the final string if enough space had been available.
Thus, a return value of size or more means that the output was
truncated."

> Perhaps this can never happen given the actual buffer sizes and strings
> being printed, but it feels a bit unsafe.
> 
> 
> It may be better to clamp the adjustments to *buf_p and *blen to
> *blen - 1 in this case, and explicitly set (*buf_p)[*blen - 1] to '\0'.
> We _may_ want indicate failure in the return from arm_spe_pkt_desc() in
> this situation, but I don't know enough about how this code is called to
> enable me to judge that.

The caller arm_spe_dump() will print out the string if the return
value > 0 [1]; so I think it can simply return the string length which
has been written to the buffer (with the clamped value).  The function
can be refined as below:

static int arm_spe_pkt_snprintf(int *err, char **buf_p, size_t *blen,
const char *fmt, ...)
{
va_list ap;
int ret;

/* Bail out if any error occurred */
if (err && *err)
return *err;

va_start(ap, fmt);
ret = vsnprintf(*buf_p, *blen - 1, fmt, ap);

Re: [PATCH] KVM: VMX: Enable Notify VM exit

2020-11-02 Thread Xiaoyao Li


On 11/3/2020 2:25 AM, Paolo Bonzini wrote:

On 02/11/20 19:01, Andy Lutomirski wrote:

What's the point?  Surely the kernel should reliably mitigate the
flaw, and the kernel should decide how to do so.


There is some slowdown in trapping #DB and #AC unconditionally.  Though
for these two cases nobody should care so I agree with keeping the code
simple and keeping the workaround.


OK.


Also, why would this trigger after more than a few hundred cycles,
something like the length of the longest microcode loop?  HZ*10 seems
like a very generous estimate already.



As Sean said in another mail, 1/10 tick should be a placeholder.
Glad to see all of you think it should be smaller. We'll come up with 
more reasonable candidate once we can test on real silicon.

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

2020-11-02 Thread Shawn Guo

On Tue, Nov 03, 2020 at 12:00:08PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> After merging the imx-mxs tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
> 
> arch/arm/mach-imx/mmdc.c: In function 'imx_mmdc_remove':
> arch/arm/mach-imx/mmdc.c:465:24: error: 'mmdc_ipg_clk' undeclared (first use 
> in this function)
>   465 |  clk_disable_unprepare(mmdc_ipg_clk);
>   |^~~~
> 
> Caused by commit
> 
>   52172fdbc3a3 ("ARM: imx: add missing clk_disable_unprepare() when remove 
> imx_mmdc")
> 
> I have reverted that commit for today.

Sorry for the breakage, Stephen.  I dropped the commit from my branch.

Shawn

Re: [PATCH] misc: rtsx: Fix some bugs and add test mode for rts5261

On Tue, Nov 03, 2020 at 11:27:15AM +0800, rui_f...@realsil.com.cn wrote:
> From: Rui Feng 
> 
> 1.Add force test mode
> 2.Fix OCP function
> 3.Use aspm in way of backdoor
> 4.Fix PAD driving
> 5.Not support MMC default
> 6.Support CD reverse
> 7.Add hardware auto power down when unplug card

When you have to list the different things you are doing in a single
patch, that is a huge sign that you need to break this up into much
smaller patches.  Please turn this patch into a patch series, each patch
only doing one logical thing.

thanks,

greg k-h

Re: [PATCH v3 1/7] compiler-clang: add build check for clang 10.0.1

2020-11-02 Thread Nathan Chancellor

On Tue, Nov 03, 2020 at 06:55:21AM +0200, Jarkko Sakkinen wrote:
> On Wed, Sep 02, 2020 at 03:59:05PM -0700, Nick Desaulniers wrote:
> > During Plumbers 2020, we voted to just support the latest release of
> > Clang for now.  Add a compile time check for this.
> > 
> > We plan to remove workarounds for older versions now, which will break
> > in subtle and not so subtle ways.
> > 
> > Suggested-by: Sedat Dilek 
> > Suggested-by: Nathan Chancellor 
> > Suggested-by: Kees Cook 
> > Signed-off-by: Nick Desaulniers 
> > Tested-by: Sedat Dilek 
> > Reviewed-by: Kees Cook 
> > Reviewed-by: Miguel Ojeda 
> > Reviewed-by: Sedat Dilek 
> > Acked-by: Marco Elver 
> > Acked-by: Nathan Chancellor 
> > Acked-by: Sedat Dilek 
> > Link: https://github.com/ClangBuiltLinux/linux/issues/9
> > Link: https://github.com/ClangBuiltLinux/linux/issues/941
> > ---
> >  include/linux/compiler-clang.h | 8 
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
> > index cee0c728d39a..230604e7f057 100644
> > --- a/include/linux/compiler-clang.h
> > +++ b/include/linux/compiler-clang.h
> > @@ -3,6 +3,14 @@
> >  #error "Please don't include  directly, include 
> >  instead."
> >  #endif
> >  
> > +#define CLANG_VERSION (__clang_major__ * 1 \
> > ++ __clang_minor__ * 100\
> > ++ __clang_patchlevel__)
> > +
> > +#if CLANG_VERSION < 11
> > +# error Sorry, your version of Clang is too old - please use 10.0.1 or 
> > newer.
> > +#endif
> 
> 
> I'm trying to compile a BPF enabled test kernel for a live system and I
> get this error even though I have much newer clang:
> 
> ➜  ~ (master) ✔ clang --version  
> Ubuntu clang version 11.0.0-2
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> 
> Tried to Google for troubleshooter tips but this patch is basically the
> only hit I get :-)

Do you have a .config and command to reproduce the error?

Cheers,
Nathan

linux-next: build warning after merge of the nand tree

2020-11-02 Thread Stephen Rothwell

Hi all,

After merging the nand tree, today's linux-next build (htmldocs)
produced these warnings:

Error: Cannot open file drivers/mtd/nand/raw/nand_ecc.c
Error: Cannot open file drivers/mtd/nand/raw/nand_ecc.c

Caused by commit

  5c859c18150b ("mtd: nand: ecc-hamming: Move Hamming code to the generic NAND 
layer")

Tha sbove file is referred to in:

Documentation/driver-api/mtd/nand_ecc.rst
Documentation/driver-api/mtdnand.rst

-- 
Cheers,
Stephen Rothwell


pgpm0Wx34rtE7.pgp
Description: OpenPGP digital signature

Re: [PATCH 5.9 24/74] x86, powerpc: Rename memcpy_mcsafe() to copy_mc_to_{user, kernel}()

2020-11-02 Thread Greg Kroah-Hartman

On Mon, Nov 02, 2020 at 10:34:08PM +0100, Hans-Peter Jansen wrote:
> Hi Greg, hi Dan,
> 
> Am Samstag, 31. Oktober 2020, 12:36:06 CET schrieb Greg Kroah-Hartman:
> > From: Dan Williams 
> > 
> > commit ec6347bb43395cb92126788a1a5b25302543f815 upstream.
> > 
> > In reaction to a proposal to introduce a memcpy_mcsafe_fast()
> > implementation Linus points out that memcpy_mcsafe() is poorly named
> > relative to communicating the scope of the interface. Specifically what
> > addresses are valid to pass as source, destination, and what faults /
> > exceptions are handled.
> > 
> > 
> > Introduce an x86 copy_mc_fragile() name as the rename for the
> > low-level x86 implementation formerly named memcpy_mcsafe(). It is used
> > as the slow / careful backend that is supplanted by a fast
> > copy_mc_generic() in a follow-on patch.
> > 
> > One side-effect of this reorganization is that separating copy_mc_64.S
> > to its own file means that perf no longer needs to track dependencies
> > for its memcpy_64.S benchmarks.
> > 
> > ---
> > arch/powerpc/lib/copy_mc_64.S  |  242 
> > +
> > arch/powerpc/lib/memcpy_mcsafe_64.S|  242 
> > -
> 
> > tools/testing/selftests/powerpc/copyloops/copy_mc_64.S |  242 
> > + 
> 
> This change leaves a dangling symlink in 
> tools/testing/selftests/powerpc/copyloops behind. At least, this is, what I 
> could track down, when building 5.9.3 within an environment, that bails out 
> on this:
> 
> [ 2908s] calling /usr/lib/rpm/brp-suse.d/brp-25-symlink
> [ 2908s] ERROR: link target doesn't exist (neither in build root nor in 
> installed system):
> [ 2908s]   
> /usr/src/linux-5.9.3-lp152.3-vanilla/tools/testing/selftests/powerpc/copyloops/memcpy_mcsafe_64.S
>  -> /usr/src/linux-5.9.3-lp152.3-vanilla/arch/powerpc/lib/memcpy_mcsafe_64.S
> [ 2908s] Add the package providing the target to BuildRequires and Requires
> [ 2909s] INFO: relinking 
> /usr/src/linux-5.9.3-lp152.3-vanilla/tools/testing/selftests/powerpc/primitives/asm/asm-compat.h
>  -> ../../../../../../arch/powerpc/include/asm/asm-compat.h (was 
> ../.././../../../../arch/powerpc/include/asm/asm-compat.h)
> 
> Linus` tree seems to not suffer from this, though.

Ah, that kind of makes sense, I saw odd things with these patches that I
couldn't figure out.

So, is there a symlink that I need to add/fix to resolve this?

thanks,

greg k-h

Re: [PATCH v5 03/17] x86/acrn: Introduce an API to check if a VM is privileged

2020-11-02 Thread Shuo A Liu


Hi Boris,

On Mon  2.Nov'20 at 15:37:07 +0100, Borislav Petkov wrote:

On Mon, Oct 19, 2020 at 02:17:49PM +0800, shuo.a@intel.com wrote:

+bool acrn_is_privileged_vm(void)
+{
+   return cpuid_eax(acrn_cpuid_base() | ACRN_CPUID_FEATURES) &
+ACRN_FEATURE_PRIVILEGED_VM;


I asked in the previous review why that acrn_cpuid_base() is used here,
you said that the base might vary. Looking at hypervisor_cpuid_base(),
it searches in the range [0x4000, 0x4001] with an 0x100 offset.

So you're saying that ACRN_CPUID_FEATURES is the first leaf beyond the
base. Close?


Yes.



If so, why isn't the code doing this?

return cpuid_eax(acrn_cpuid_base() + 1)...

and why doesn't it have a comment above it explaining that the base can
change and it needs to be discovered each time?


The code just followed KVM style (see kvm_arch_para_features()).
I can change to use
cpuid_eax(acrn_cpuid_base() + 1)...
If you prefer to.

hypervisor_cpuid_base() implies the base is variable, no? We use
this function to detect the base.




+EXPORT_SYMBOL_GPL(acrn_is_privileged_vm);


Also, that acrn_is_privileged_vm() silly helper is used only once and
I don't like the exported symbols pollution we're doing. So make that
function give you the eax of ACRN_CPUID_FEATURES and callers can do
their testing themselves.


OK. Then i will define acrn_cpuid_base() as a static inline function in
asm/acrn.h for callers.



When it turns out that code patterns get repeated, you can then
aggregate stuff into a helper.


Got it. Thanks.

Thanks
shuo

[PATCH v1 1/2] scsi: ufs: Fix unbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

2020-11-02 Thread Can Guo

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

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

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 847f355..efa7d86 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1634,12 +1634,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
 */
/* fallthrough */
case CLKS_OFF:
-   ufshcd_scsi_block_requests(hba);
hba->clk_gating.state = REQ_CLKS_ON;
trace_ufshcd_clk_gating(dev_name(hba->dev),
hba->clk_gating.state);
-   queue_work(hba->clk_gating.clk_gating_workq,
-  >clk_gating.ungate_work);
+   if (queue_work(hba->clk_gating.clk_gating_workq,
+  >clk_gating.ungate_work))
+   ufshcd_scsi_block_requests(hba);
/*
 * fall through to check if we should wait for this
 * work to be done or not.
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH v1 2/2] scsi: ufs: Try to save power mode change and UIC cmd completion timeout

2020-11-02 Thread Can Guo

Use the uic_cmd->cmd_active as a flag to track the lifecycle of an UIC cmd.
The flag is set before send the UIC cmd and cleared in IRQ handler. When a
PMC or UIC cmd completion timeout happens, if the flag is not set, instead
of returning timeout error, we still treat it as a successful operation.
This is to deal with the scenario in which completion has been raised but
the one waiting for the completion cannot be awaken in time due to kernel
scheduling problem.

Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 26 --
 drivers/scsi/ufs/ufshcd.h |  2 ++
 2 files changed, 26 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index efa7d86..7f33310 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2122,10 +2122,20 @@ ufshcd_wait_for_uic_cmd(struct ufs_hba *hba, struct 
uic_command *uic_cmd)
unsigned long flags;
 
if (wait_for_completion_timeout(_cmd->done,
-   msecs_to_jiffies(UIC_CMD_TIMEOUT)))
+   msecs_to_jiffies(UIC_CMD_TIMEOUT))) {
ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
-   else
+   } else {
ret = -ETIMEDOUT;
+   dev_err(hba->dev,
+   "uic cmd 0x%x with arg3 0x%x completion timeout\n",
+   uic_cmd->command, uic_cmd->argument3);
+
+   if (!uic_cmd->cmd_active) {
+   dev_err(hba->dev, "%s: UIC cmd has been completed, 
return the result\n",
+   __func__);
+   ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
+   }
+   }
 
spin_lock_irqsave(hba->host->host_lock, flags);
hba->active_uic_cmd = NULL;
@@ -2157,6 +2167,7 @@ __ufshcd_send_uic_cmd(struct ufs_hba *hba, struct 
uic_command *uic_cmd,
if (completion)
init_completion(_cmd->done);
 
+   uic_cmd->cmd_active = 1;
ufshcd_dispatch_uic_cmd(hba, uic_cmd);
 
return 0;
@@ -3828,10 +3839,18 @@ static int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, 
struct uic_command *cmd)
dev_err(hba->dev,
"pwr ctrl cmd 0x%x with mode 0x%x completion timeout\n",
cmd->command, cmd->argument3);
+
+   if (!cmd->cmd_active) {
+   dev_err(hba->dev, "%s: Power Mode Change operation has 
been completed, go check UPMCRS\n",
+   __func__);
+   goto check_upmcrs;
+   }
+
ret = -ETIMEDOUT;
goto out;
}
 
+check_upmcrs:
status = ufshcd_get_upmcrs(hba);
if (status != PWR_LOCAL) {
dev_err(hba->dev,
@@ -4923,11 +4942,14 @@ static irqreturn_t ufshcd_uic_cmd_compl(struct ufs_hba 
*hba, u32 intr_status)
ufshcd_get_uic_cmd_result(hba);
hba->active_uic_cmd->argument3 =
ufshcd_get_dme_attr_val(hba);
+   if (!hba->uic_async_done)
+   hba->active_uic_cmd->cmd_active = 0;
complete(>active_uic_cmd->done);
retval = IRQ_HANDLED;
}
 
if ((intr_status & UFSHCD_UIC_PWR_MASK) && hba->uic_async_done) {
+   hba->active_uic_cmd->cmd_active = 0;
complete(hba->uic_async_done);
retval = IRQ_HANDLED;
}
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 66e5338..be982ed 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -64,6 +64,7 @@ enum dev_cmd_type {
  * @argument1: UIC command argument 1
  * @argument2: UIC command argument 2
  * @argument3: UIC command argument 3
+ * @cmd_active: Indicate if UIC command is outstanding
  * @done: UIC command completion
  */
 struct uic_command {
@@ -71,6 +72,7 @@ struct uic_command {
u32 argument1;
u32 argument2;
u32 argument3;
+   int cmd_active;
struct completion done;
 };
 
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

[PATCH] scsi: ufs: Try to save power mode change and UIC cmd completion timeout

2020-11-02 Thread Can Guo

Use the uic_cmd->cmd_active as a flag to track the lifecycle of an UIC cmd.
The flag is set before send the UIC cmd and cleared after the completion is
raised in IRQ handler. For a power mode change operation, including hibern8
enter/exit, the flag is cleared only after hba->uic_async_done completion
is raised. When completion timeout happens, if the flag is cleared, instead
of returning timeout error, simply ignore it.

Change-Id: Ie3cd6ae6221a44619925fb2cf78136a5617fdd5d
Signed-off-by: Can Guo 
---
 drivers/scsi/ufs/ufshcd.c | 26 --
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 252e022..8b291c3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2131,10 +2131,20 @@ ufshcd_wait_for_uic_cmd(struct ufs_hba *hba, struct 
uic_command *uic_cmd)
unsigned long flags;
 
if (wait_for_completion_timeout(_cmd->done,
-   msecs_to_jiffies(UIC_CMD_TIMEOUT)))
+   msecs_to_jiffies(UIC_CMD_TIMEOUT))) {
ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
-   else
+   } else {
ret = -ETIMEDOUT;
+   dev_err(hba->dev,
+   "uic cmd 0x%x with arg3 0x%x completion timeout\n",
+   uic_cmd->command, uic_cmd->argument3);
+
+   if (!uic_cmd->cmd_active) {
+   dev_err(hba->dev, "%s: UIC cmd has been completed, 
return the result\n",
+   __func__);
+   ret = uic_cmd->argument2 & MASK_UIC_COMMAND_RESULT;
+   }
+   }
 
spin_lock_irqsave(hba->host->host_lock, flags);
hba->active_uic_cmd = NULL;
@@ -2166,6 +2176,7 @@ __ufshcd_send_uic_cmd(struct ufs_hba *hba, struct 
uic_command *uic_cmd,
if (completion)
init_completion(_cmd->done);
 
+   uic_cmd->cmd_active = 1;
ufshcd_dispatch_uic_cmd(hba, uic_cmd);
 
return 0;
@@ -3944,10 +3955,18 @@ static int ufshcd_uic_pwr_ctrl(struct ufs_hba *hba, 
struct uic_command *cmd)
dev_err(hba->dev,
"pwr ctrl cmd 0x%x with mode 0x%x completion timeout\n",
cmd->command, cmd->argument3);
+
+   if (!cmd->cmd_active) {
+   dev_err(hba->dev, "%s: Power Mode Change operation has 
been completed, go check UPMCRS\n",
+   __func__);
+   goto check_upmcrs;
+   }
+
ret = -ETIMEDOUT;
goto out;
}
 
+check_upmcrs:
status = ufshcd_get_upmcrs(hba);
if (status != PWR_LOCAL) {
dev_err(hba->dev,
@@ -5060,11 +5079,14 @@ static irqreturn_t ufshcd_uic_cmd_compl(struct ufs_hba 
*hba, u32 intr_status)
hba->active_uic_cmd->argument3 =
ufshcd_get_dme_attr_val(hba);
complete(>active_uic_cmd->done);
+   if (!hba->uic_async_done)
+   hba->active_uic_cmd->cmd_active = 0;
retval = IRQ_HANDLED;
}
 
if ((intr_status & UFSHCD_UIC_PWR_MASK) && hba->uic_async_done) {
complete(hba->uic_async_done);
+   hba->active_uic_cmd->cmd_active = 0;
retval = IRQ_HANDLED;
}
return retval;
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.

Re: [PATCH] KVM: VMX: Enable Notify VM exit

2020-11-02 Thread Xiaoyao Li


On 11/3/2020 2:12 PM, Tao Xu wrote:



On 11/3/20 6:53 AM, Jim Mattson wrote:

On Sun, Nov 1, 2020 at 10:14 PM Tao Xu  wrote:


There are some cases that malicious virtual machines can cause CPU stuck
(event windows don't open up), e.g., infinite loop in microcode when
nested #AC (CVE-2015-5307). No event window obviously means no events,
e.g. NMIs, SMIs, and IRQs will all be blocked, may cause the related
hardware CPU can't be used by host or other VM.

To resolve those cases, it can enable a notify VM exit if no
event window occur in VMX non-root mode for a specified amount of
time (notify window).

Expose a module param for setting notify window, default setting it to
the time as 1/10 of periodic tick, and user can set it to 0 to disable
this feature.

TODO:
1. The appropriate value of notify window.
2. Another patch to disable interception of #DB and #AC when notify
VM-Exiting is enabled.

Co-developed-by: Xiaoyao Li 
Signed-off-by: Tao Xu 
Signed-off-by: Xiaoyao Li 


Do you have test cases?



yes we have. The nested #AC (CVE-2015-5307) is a known test case, though 
we need to tweak KVM to disable interception #AC for it.


Not yet, because we are waiting real silicon to do some test. I should 
add RFC next time before I test it in hardware.

Re: [PATCH v2 5/6] MIPS: Loongson64: Make sure the PC address is correct when 3A4000+ CPU hotplug


On 11/03/2020 01:28 PM, Jiaxun Yang wrote:



在 2020/11/3 11:15, Tiezhu Yang 写道:

In loongson3_type3_play_dead(), in order to make sure the PC address is
correct, use lw to read the low 32 bits first, if the result is not 
zero,
then use ld to read the whole 64 bits, otherwise there maybe exists 
atomic

problem due to write high 32 bits first and then low 32 bits, like this:

high 32 bits (write done)
   -- only read high 32-bits which is 
wrong

low 32 bits (not yet write done)

This problem is especially for Loongson 3A4000+ CPU due to using 
Mail_Send
register which can only send 32 bits data one time. Although it is 
hard to
reproduce, we can do something at the software level to avoid the 
risks for

3A4000+ CPU, this change has no influence on the other Loongson CPUs.

Signed-off-by: Lu Zeng 
Signed-off-by: Jun Yi 
Signed-off-by: Tiezhu Yang 


Hi Tiezhu,

Sorry that I didn't look this patch carefully in previous rev, here's 
my comments,


Firstly the commit message and code comment looks bogus...

I'd prefer


Hi Jiaxun,

Thanks for your detail review, it looks better.
Let me update it and then send v3.

Thanks,
Tiezhu



---
MIPS: Loongson64: SMP: Fix up play_dead jump indicator

In play_dead function, the whole 64-bit PC mailbox was used as a 
indicator

to determine if the master core had written boot jump information.

However, after we introduced CSR mailsend, the 64-bit PC mailbox won't be
written atomicly. Thus we have to use the lower 32-bit, which will be 
written at

the last, as the jump indicator instead.
--

Thanks.


---

v2: No changes

  arch/mips/loongson64/smp.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/mips/loongson64/smp.c b/arch/mips/loongson64/smp.c
index 736e98d..e32b46e 100644
--- a/arch/mips/loongson64/smp.c
+++ b/arch/mips/loongson64/smp.c
@@ -764,9 +764,10 @@ static void loongson3_type3_play_dead(int 
*state_addr)
  "1: li%[count], 0x100 \n" /* wait for init 
loop */
  "2: bnez  %[count], 2b\n" /* limit mailbox 
access */

  "   addiu %[count], -1\n"
-"   ld%[initfunc], 0x20(%[base])  \n" /* get PC via 
mailbox */
+"   lw%[initfunc], 0x20(%[base])  \n" /* get PC (low 32 
bits) via mailbox */


Here you can comment as "Check jump indicator (lower 32-bit of PC 
mailbox)"


Thanks.

- Jiaxun

  "   beqz  %[initfunc], 1b \n"
  "   nop   \n"
+"   ld%[initfunc], 0x20(%[base])  \n" /* get PC (whole 
64 bits) via mailbox */
  "   ld$sp, 0x28(%[base])  \n" /* get SP via 
mailbox */
  "   ld$gp, 0x30(%[base])  \n" /* get GP via 
mailbox */

  "   ld$a1, 0x38(%[base])  \n"

Re: [resource] 22b17dc667: Kernel panic - not syncing: Fatal exception

2020-11-02 Thread John Hubbard


On 11/2/20 10:06 PM, lkp wrote:

Greeting,

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

commit: 22b17dc667d36418ccabb9c668c4b489185fb40a ("[PATCH v5 13/15] resource: Move 
devmem revoke code to resource framework")
url: 
https://github.com/0day-ci/linux/commits/Daniel-Vetter/follow_pfn-and-other-iomap-races/20201030-181112
base: git://linuxtv.org/media_tree.git master

in testcase: fsmark
version: fsmark-x86_64-3.3-1_20201007
with following parameters:

iterations: 1x
nr_threads: 1t
disk: 1BRD_48G
fs: f2fs
fs2: nfsv4
filesize: 4M
test_size: 40G
sync_method: NoSync
cpufreq_governor: performance
ucode: 0x5002f01

test-description: The fsmark is a file system benchmark to test synchronous 
write workloads, for example, mail servers workload.
test-url: https://sourceforge.net/projects/fsmark/


on test machine: 192 threads Intel(R) Xeon(R) Platinum 9242 CPU @ 2.30GHz with 
192G memory

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




Yep, this is the same crash that I saw. And the .config also has

  # CONFIG_IO_STRICT_DEVMEM is not set

so it all makes sense.



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


[   28.644165] systemd[1]: RTC configured in localtime, applying delta of 0 
minutes to system time.

[   28.699473] #PF: supervisor read access in kernel mode
[   28.704611] #PF: error_code(0x) - not-present page
[   28.709749] PGD 0 P4D 0
[   28.712291] Oops:  [#1] SMP NOPTI
[   28.715956] CPU: 0 PID: 1 Comm: systemd Not tainted 
5.10.0-rc1-00015-g22b17dc667d3 #1
[   28.723793] RIP: 0010:do_dentry_open+0x1c9/0x360
[   28.728410] Code: 84 82 01 00 00 81 ca 00 00 04 00 89 53 44 48 8b 83 f0 00 00 00 
81 63 40 3f fc ff ff 48 8d bb 98 00 00 00 c7 43 34 00 00 00 00 <48> 8b 00 48 8b 
70 30 e8 2b cb f4 ff f6 43 41 40 74 5a 48 8b 83 f0
[   28.747157] RSP: 0018:c906fcc8 EFLAGS: 00010206
[   28.752380] RAX:  RBX: 8881502ad400 RCX: 
[   28.759506] RDX: 000a201d RSI: 8284d260 RDI: 8881502ad498
[   28.766639] RBP: 88a485a06490 R08:  R09: 8284d260
[   28.773769] R10: c906fcc8 R11: 756c6176006d656d R12: 
[   28.780895] R13: 8133ddc0 R14: 8881502ad410 R15: 8881502ad400
[   28.788028] FS:  7ff54afa1940() GS:888c4f60() 
knlGS:
[   28.796113] CS:  0010 DS:  ES:  CR0: 80050033
[   28.801858] CR2:  CR3: 000100120003 CR4: 007706f0
[   28.808983] DR0:  DR1:  DR2: 
[   28.816114] DR3:  DR6: fffe0ff0 DR7: 0400
[   28.823239] PKRU: 5554
[   28.825952] Call Trace:
[   28.828412]  path_openat+0xaa8/0x10a0
[   28.832073]  do_filp_open+0x91/0x100
[   28.835653]  ? acpi_os_wait_semaphore+0x48/0x80
[   28.840186]  ? __check_object_size+0x136/0x160
[   28.844631]  do_sys_openat2+0x20d/0x2e0
[   28.848470]  do_sys_open+0x44/0x80
[   28.851878]  do_syscall_64+0x33/0x40
[   28.855457]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   28.860509] RIP: 0033:0x7ff54c1521ae
[   28.864086] Code: 25 00 00 41 00 3d 00 00 41 00 74 48 48 8d 05 59 65 0d 00 8b 00 
85 c0 75 69 89 f2 b8 01 01 00 00 48 89 fe bf 9c ff ff ff 0f 05 <48> 3d 00 f0 ff 
ff 0f 87 a6 00 00 00 48 8b 4c 24 28 64 48 33 0c 25
[   28.882833] RSP: 002b:7ffd1c9586d0 EFLAGS: 0246 ORIG_RAX: 
0101
[   28.890399] RAX: ffda RBX: 7ffd1c9587d0 RCX: 7ff54c1521ae
[   28.897531] RDX: 0008 RSI: 7ff54bfa0e5a RDI: ff9c
[   28.904662] RBP: 7ffd1c9587d8 R08: 021f R09: 55f837cf4290
[   28.911796] R10:  R11: 0246 R12: 56dd9000
[   28.918927] R13:  R14: 7ffd1c9587d0 R15: 0002
[   28.926060] Modules linked in: ip_tables
[   28.929986] CR2: 
mDebian GNU/Linu
[   28.933416] ---[ end trace 94e4f9aa3df66098 ]---
[   28.939355] RIP: 0010:do_dentry_open+0x1c9/0x360
[   28.943975] Code: 84 82 01 00 00 81 ca 00 00 04 00 89 53 44 48 8b 83 f0 00 00 00 
81 63 40 3f fc ff ff 48 8d bb 98 00 00 00 c7 43 34 00 00 00 00 <48> 8b 00 48 8b 
70 30 e8 2b cb f4 ff f6 43 41 40 74 5a 48 8b 83 f0
[   28.962721] RSP: 0018:c906fcc8 EFLAGS: 00010206
[   28.967948] RAX:  RBX: 8881502ad400 RCX: 
[   28.975079] RDX: 000a201d RSI: 8284d260 RDI: 8881502ad498
[   28.982211] RBP: 88a485a06490 R08:  R09: 8284d260
[   28.989337] R10: c906fcc8 R11: 756c6176006d656d R12: 
[   28.996467] R13: 8133ddc0 R14: 8881502ad410 R15: 8881502ad400
[   29.003592] FS:  7ff54afa1940() GS:888c4f60() 
knlGS:
[   29.011668] CS:  0010 DS:  ES:  CR0:

Re: [PATCH] KVM: VMX: Enable Notify VM exit

2020-11-02 Thread Tao Xu





On 11/3/20 6:53 AM, Jim Mattson wrote:

On Sun, Nov 1, 2020 at 10:14 PM Tao Xu  wrote:


There are some cases that malicious virtual machines can cause CPU stuck
(event windows don't open up), e.g., infinite loop in microcode when
nested #AC (CVE-2015-5307). No event window obviously means no events,
e.g. NMIs, SMIs, and IRQs will all be blocked, may cause the related
hardware CPU can't be used by host or other VM.

To resolve those cases, it can enable a notify VM exit if no
event window occur in VMX non-root mode for a specified amount of
time (notify window).

Expose a module param for setting notify window, default setting it to
the time as 1/10 of periodic tick, and user can set it to 0 to disable
this feature.

TODO:
1. The appropriate value of notify window.
2. Another patch to disable interception of #DB and #AC when notify
VM-Exiting is enabled.

Co-developed-by: Xiaoyao Li 
Signed-off-by: Tao Xu 
Signed-off-by: Xiaoyao Li 


Do you have test cases?

Not yet, because we are waiting real silicon to do some test. I should 
add RFC next time before I test it in hardware.

Re: [PATCH v2 0/4] drm/bridge: ti-sn65dsi86: Support EDID reading

2020-11-02 Thread Vinod Koul

Hi,

Thanks Doug for adding me

On 02-11-20, 08:37, Doug Anderson wrote:
> > On Thu, Oct 29, 2020 at 06:17:34PM -0700, Stephen Boyd wrote:

> > Any chance we can convince you to prepare this bridge driver for use in
> > a chained bridge setup where the connector is created by the display
> > driver and uses drm_bridge_funcs?
> >
> > First step wuld be to introduce the use of a panel_bridge.
> > Then add get_edid to drm_bridge_funcs and maybe more helpers.
> >
> > Then natural final step would be to move connector creation to the
> > display driver - see how other uses drm_bridge_connector_init() to do so
> > - it is relatively simple.
> >
> > Should be doable - and reach out if you need some help.

Yes it is and doable and you find this at [1], would need a rebase
though.

> At some point I think Vinod tried to prepare a patch for this and I
> tried it, but it didn't just work.  I spent an hour or so poking at it
> and I couldn't quite figure out why and I couldn't find enough other
> examples to compare against to see what was wrong...  That was a few
> months ago, though.  Maybe things are in a better shape now?

It worked fine for me on Rb3 and db410c where we had HDMI connector. I
don't have a panel device to test and Bjorn tried to help out with a bit
of testing. This didn't work on the laptop, that is why I haven't posted
it yet.

This has conversion of msm driver and bridge drivers lt9611, adv7511 and
ti-sn65dsi86.

[1]: 
https://git.linaro.org/people/vinod.koul/kernel.git/log/?h=wip/msm_bridges_no_conn

Thanks
-- 
~Vinod

Re: [PATCH] misc: hisi_hikey_usb: use PTR_ERR_OR_ZERO

2020-11-02 Thread John Stultz

On Mon, Oct 26, 2020 at 11:02 AM Sudip Mukherjee
 wrote:
>
> Coccinelle suggested using PTR_ERR_OR_ZERO() and looking at the code,
> we can use PTR_ERR_OR_ZERO() instead of checking IS_ERR() and then
> doing 'return 0'.
>
> Signed-off-by: Sudip Mukherjee 

Thanks for sending this!

Acked-by: John Stultz 

thanks
-john

Re: [PATCH v3 3/4] powercap: Add AMD Fam17h RAPL support

2020-11-02 Thread Victor Ding

On Mon, Nov 2, 2020 at 12:39 PM Zhang Rui  wrote:
>
> On Tue, 2020-10-27 at 07:23 +, Victor Ding wrote:
> > This patch enables AMD Fam17h RAPL support for the power capping
> > framework. The support is as per AMD Fam17h Model31h (Zen2) and
> > model 00-ffh (Zen1) PPR.
> >
> > Tested by comparing the results of following two sysfs entries and
> > the
> > values directly read from corresponding MSRs via /dev/cpu/[x]/msr:
> >   /sys/class/powercap/intel-rapl/intel-rapl:0/energy_uj
> >   /sys/class/powercap/intel-rapl/intel-rapl:0/intel-
> > rapl:0:0/energy_uj
> >
> > Signed-off-by: Victor Ding 
> > Acked-by: Kim Phillips 
> >
> >
> > ---
> >
> > Changes in v3:
> > By Victor Ding 
> >  - Rebased to the latest code.
> >  - Created a new rapl_defaults for AMD CPUs.
> >  - Removed redundant setting to zeros.
> >  - Stopped using the fake power limit domain 1.
> >
> > Changes in v2:
> > By Kim Phillips :
> >  - Added Kim's Acked-by.
> >  - Added Daniel Lezcano to Cc.
> >  - (No code change).
> >
> >  arch/x86/include/asm/msr-index.h |  1 +
> >  drivers/powercap/intel_rapl_common.c |  6 ++
> >  drivers/powercap/intel_rapl_msr.c| 20 +++-
> >  3 files changed, 26 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/include/asm/msr-index.h
> > b/arch/x86/include/asm/msr-index.h
> > index 21917e134ad4..c36a083c8ec0 100644
> > --- a/arch/x86/include/asm/msr-index.h
> > +++ b/arch/x86/include/asm/msr-index.h
> > @@ -327,6 +327,7 @@
> >  #define MSR_PP1_POLICY   0x0642
> >
> >  #define MSR_AMD_RAPL_POWER_UNIT  0xc0010299
> > +#define MSR_AMD_CORE_ENERGY_STATUS   0xc001029a
> >  #define MSR_AMD_PKG_ENERGY_STATUS0xc001029b
> >
> >  /* Config TDP MSRs */
> > diff --git a/drivers/powercap/intel_rapl_common.c
> > b/drivers/powercap/intel_rapl_common.c
> > index 0b2830efc574..bedd780bed12 100644
> > --- a/drivers/powercap/intel_rapl_common.c
> > +++ b/drivers/powercap/intel_rapl_common.c
> > @@ -1011,6 +1011,10 @@ static const struct rapl_defaults
> > rapl_defaults_cht = {
> >   .compute_time_window = rapl_compute_time_window_atom,
> >  };
> >
> > +static const struct rapl_defaults rapl_defaults_amd = {
> > + .check_unit = rapl_check_unit_core,
> > +};
> > +
>
> why do we need power_unit and time_unit if we only want to expose the
> energy counter?
AMD's Power Unit MSR provides identical information as Intel's, including
time units, power units, and energy status units. By reusing the check unit
method, we could avoid code duplication as well as easing future enhance-
ment when AMD starts to support power limits.
>
> Plus, in rapl_init_domains(), PL1 is enabled for every RAPL Domain
> blindly, I'm not sure how this is handled on the AMD CPUs.
> Is PL1 invalidated by rapl_detect_powerlimit()? or is it still
> registered as a valid constraint into powercap sysfs I/F?
AMD's CORE_ENERGY_STAT MSR is like Intel's PP0_ENERGY_STATUS;
therefore, PL1 also always exists on AMD. rapl_detect_powerlimit() correctly
markes the domain as monitoring-only after finding power limit MSRs do not
exist.
>
> Currently, the code makes the assumption that there is only on power
> limit if priv->limits[domain_id] not set, we probably need to change
> this if we want to support RAPL domains with no power limit.
The existing code already supports RAPL domains with no power limit: PL1 is
enabled when there is zero or one power limit,
rapl_detect_powerlimit() will then
mark if PL1 is monitoring-only if power limit MSRs do not exist. Both AMD's RAPL
domains are monitoring-only and are correctly marked and handled.
>
> thanks,
> rui
> >  static const struct x86_cpu_id rapl_ids[] __initconst = {
> >   X86_MATCH_INTEL_FAM6_MODEL(SANDYBRIDGE, _default
> > s_core),
> >   X86_MATCH_INTEL_FAM6_MODEL(SANDYBRIDGE_X,   _defaults_core),
> > @@ -1061,6 +1065,8 @@ static const struct x86_cpu_id rapl_ids[]
> > __initconst = {
> >
> >   X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNL,_defaults_hsw_se
> > rver),
> >   X86_MATCH_INTEL_FAM6_MODEL(XEON_PHI_KNM,_defaults_hsw_se
> > rver),
> > +
> > + X86_MATCH_VENDOR_FAM(AMD, 0x17, _defaults_amd),
> >   {}
> >  };
> >  MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
> > diff --git a/drivers/powercap/intel_rapl_msr.c
> > b/drivers/powercap/intel_rapl_msr.c
> > index a819b3b89b2f..78213d4b5b16 100644
> > --- a/drivers/powercap/intel_rapl_msr.c
> > +++ b/drivers/powercap/intel_rapl_msr.c
> > @@ -49,6 +49,14 @@ static struct rapl_if_priv rapl_msr_priv_intel = {
> >   .limits[RAPL_DOMAIN_PLATFORM] = 2,
> >  };
> >
> > +static struct rapl_if_priv rapl_msr_priv_amd = {
> > + .reg_unit = MSR_AMD_RAPL_POWER_UNIT,
> > + .regs[RAPL_DOMAIN_PACKAGE] = {
> > + 0, MSR_AMD_PKG_ENERGY_STATUS, 0, 0, 0 },
> > + .regs[RAPL_DOMAIN_PP0] = {
> > + 0, MSR_AMD_CORE_ENERGY_STATUS, 0, 0, 0 },
> > +};
> > +
> >  /* Handles CPU hotplug on multi-socket systems.
> >   * If a CPU goes online

Re: [PATCH] ASoC: tegra: remove unneeded semicolon

2020-11-02 Thread Sameer Pujar


Hi Tom,


From: Tom Rix 

A semicolon is not needed after a switch statement.

Signed-off-by: Tom Rix 
---


Acked-by: Sameer Pujar 

Thanks for the update.

Re: [PATCH] KVM: VMX: Enable Notify VM exit

2020-11-02 Thread Tao Xu

On 11/3/20 12:43 AM, Andy Lutomirski wrote:

On Sun, Nov 1, 2020 at 10:14 PM Tao Xu wrote:

There are some cases that malicious virtual machines can cause CPU stuck
(event windows don't open up), e.g., infinite loop in microcode when
nested #AC (CVE-2015-5307). No event window obviously means no events,
e.g. NMIs, SMIs, and IRQs will all be blocked, may cause the related
hardware CPU can't be used by host or other VM.

To resolve those cases, it can enable a notify VM exit if no
event window occur in VMX non-root mode for a specified amount of
time (notify window).

Expose a module param for setting notify window, default setting it to
the time as 1/10 of periodic tick, and user can set it to 0 to disable
this feature.

TODO:
1. The appropriate value of notify window.
2. Another patch to disable interception of #DB and #AC when notify
VM-Exiting is enabled.

Whoa there.

A VM control that says "hey, CPU, if you messed up and livelocked for
a long time, please break out of the loop" is not a substitute for
fixing the livelocks. So I don't think you get do disable
interception of #DB and #AC. I also think you should print a loud
warning and have some intelligent handling when this new exit
triggers.

+static int handle_notify(struct kvm_vcpu *vcpu)
+{
+ unsigned long exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
+
+ /*
+* Notify VM exit happened while executing iret from NMI,
+* "blocked by NMI" bit has to be set before next VM entry.
+*/
+ if (exit_qualification & NOTIFY_VM_CONTEXT_VALID) {
+ if (enable_vnmi &&
+ (exit_qualification & INTR_INFO_UNBLOCK_NMI))
+ vmcs_set_bits(GUEST_INTERRUPTIBILITY_INFO,
+ GUEST_INTR_STATE_NMI);

This needs actual documentation in the SDM or at least ISE please.

Notify VM-Exit is defined in ISE, chapter 9.2:
https://software.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf

I will add this information into commit message. Thank you for reminding me.

[PATCH] MAINTAINERS: assign mediatek headers to Mediatek SoC support

2020-11-02 Thread Lukas Bulwahn

./include/soc/mediatek/smi.h and ./include/linux/soc/mediatek/infracfg.h
are currently not assigned to a specific section in MAINTAINERS.

./include/soc/mediatek/smi.h is the header file for definitions in
./drivers/memory/mtk-smi.c, which is assigned to the section ARM/Mediatek
SoC support in MAINTAINERS.

./include/linux/soc/mediatek/infracfg.h is the header file for definitions
in ./drivers/soc/mediatek/mtk-infracfg.c, which is assigned to the section
ARM/Mediatek SoC support in MAINTAINERS.

Hence, assign those header files to ARM/Mediatek SoC support as well.

Signed-off-by: Lukas Bulwahn 
---
Matthias, please pick this minor non-urgent cleanup patch.

This patch is part of an initial experiment to assign all files to
specific sections in MAINTAINERS. At the moment, about 3200 files are
currently not assigned to specific sections and maintainers.

If you think these cleanup patch cause more churn than value, please let
me know. Thanks.

 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index b4197e9da495..1703c7d2e146 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2066,6 +2066,8 @@ F:arch/arm/boot/dts/mt8*
 F: arch/arm/mach-mediatek/
 F: arch/arm64/boot/dts/mediatek/
 F: drivers/soc/mediatek/
+F: include/linux/soc/mediatek/infracfg.h
+F: include/soc/mediatek/smi.h
 N: mtk
 N: mt[678]
 K: mediatek
-- 
2.17.1

[PATCH 4/4] habanalabs/gaudi: add support for NIC QMANs

2020-11-02 Thread Oded Gabbay

Initialize the QMANs that are responsible to submit doorbells to the NIC
engines. Add support for stopping and disabling them, and reset them as
part of the hard-reset procedure of GAUDI. This will allow the user to
submit work to the NICs.

Add support for receiving events on QMAN errors from the firmware.

However, the nic_ports_mask is still initialized to 0. That means this code
won't initialize the QMANs just yet. That will be in a later patch.

Signed-off-by: Omer Shpigelman 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/common/habanalabs.h |   3 +-
 drivers/misc/habanalabs/gaudi/gaudi.c   | 741 ++--
 drivers/misc/habanalabs/gaudi/gaudiP.h  |  32 +
 3 files changed, 731 insertions(+), 45 deletions(-)

diff --git a/drivers/misc/habanalabs/common/habanalabs.h 
b/drivers/misc/habanalabs/common/habanalabs.h
index 7307e0b88b44..968431c7ce20 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -1633,8 +1633,6 @@ struct hl_mmu_funcs {
  * @pmmu_huge_range: is a different virtual addresses range used for PMMU with
  *   huge pages.
  * @init_done: is the initialization of the device done.
- * @mmu_enable: is MMU enabled.
- * @mmu_huge_page_opt: is MMU huge pages optimization enabled.
  * @device_cpu_disabled: is the device CPU disabled (due to timeouts)
  * @dma_mask: the dma mask that was set for this device
  * @in_debug: is device under debug. This, together with fpriv_list, enforces
@@ -1750,6 +1748,7 @@ struct hl_device {
u8  supports_cb_mapping;
 
/* Parameters for bring-up */
+   u64 nic_ports_mask;
u64 fw_loading;
u8  mmu_enable;
u8  mmu_huge_page_opt;
diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c 
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 930b26b1f445..065c2377c1fa 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -301,46 +301,46 @@ static enum hl_queue_type 
gaudi_queue_type[GAUDI_QUEUE_ID_SIZE] = {
QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_TPC_7_1 */
QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_TPC_7_2 */
QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_TPC_7_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_0_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_0_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_0_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_0_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_1_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_1_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_1_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_1_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_2_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_2_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_2_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_2_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_3_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_3_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_3_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_3_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_4_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_4_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_4_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_4_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_5_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_5_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_5_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_5_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_6_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_6_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_6_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_6_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_7_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_7_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_7_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_7_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_8_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_8_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_8_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_8_3 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_9_0 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_9_1 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_9_2 */
-   QUEUE_TYPE_NA,  /* GAUDI_QUEUE_ID_NIC_9_3 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_0_0 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_0_1 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_0_2 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_0_3 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_1_0 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_1_1 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_1_2 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_1_3 */
+   QUEUE_TYPE_INT, /* GAUDI_QUEUE_ID_NIC_2_0 */
+   QUEUE_TYPE_INT, /*

mtk_vcodec_fw.c:undefined reference to `scp_ipi_send'