Re: linux-next: Fixes tag needs some work in the sound-asoc tree

2019-07-28 Thread Peter Ujfalusi
Mark,

On 26/07/2019 15.11, Mark Brown wrote:
> On Fri, Jul 26, 2019 at 09:04:37AM +0300, Peter Ujfalusi wrote:
> 
>> Mark: can you either drop the patch and I'll send a new one with fixed
>> SHA1 or can you fix the commit message in place?
> 
> Both of which involve rebasing :(  Against my better judgement I
> rebased.

thank you and sorry again...

- Péter

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


Re: [PATCH v2] f2fs: separate NOCoW and pinfile semantics

2019-07-28 Thread Jaegeuk Kim
On 07/23, Chao Yu wrote:
> On 2019/7/23 10:36, Jaegeuk Kim wrote:
> > On 07/19, Chao Yu wrote:
> >> Pinning a file is heavy, because skipping pinned files make GC
> >> running with heavy load or no effect.
> > 
> > Pinned file is a part of NOCOW files, so I don't think we can simply drop it
> > for backward compatibility.
> 
> Yes,
> 
> But what I concerned is that pin file is too heavy, so in order to satisfy 
> below
> demand, how about introducing pin_file_2 flag to triggering IPU only during
> flush/writeback.

That can be done by cold files?

> 
> > 
> >>
> >> So that this patch propose to separate nocow and pinfile semantics:
> >> - NOCoW flag can only be set on regular file.
> >> - NOCoW file will only trigger IPU at common writeback/flush.
> >> - NOCow file will do OPU during GC.
> >>
> >> For the demand of 1) avoid fragment of file's physical block and
> >> 2) userspace don't care about file's specific physical address,
> >> tagging file as NOCoW will be cheaper than pinned one.
> 
> ^^^
> 
> Thanks,
> 
> >>
> >> Signed-off-by: Chao Yu 
> >> ---
> >> v2:
> >> - rebase code to fix compile error.
> >>  fs/f2fs/data.c |  3 ++-
> >>  fs/f2fs/f2fs.h |  1 +
> >>  fs/f2fs/file.c | 22 +++---
> >>  3 files changed, 22 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> >> index a2a28bb269bf..15fb8954c363 100644
> >> --- a/fs/f2fs/data.c
> >> +++ b/fs/f2fs/data.c
> >> @@ -1884,7 +1884,8 @@ static inline bool 
> >> check_inplace_update_policy(struct inode *inode,
> >>  
> >>  bool f2fs_should_update_inplace(struct inode *inode, struct f2fs_io_info 
> >> *fio)
> >>  {
> >> -  if (f2fs_is_pinned_file(inode))
> >> +  if (f2fs_is_pinned_file(inode) ||
> >> +  F2FS_I(inode)->i_flags & F2FS_NOCOW_FL)
> >>return true;
> >>  
> >>/* if this is cold file, we should overwrite to avoid fragmentation */
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >> index 596ab3e1dd7b..f6c5a3d2e659 100644
> >> --- a/fs/f2fs/f2fs.h
> >> +++ b/fs/f2fs/f2fs.h
> >> @@ -2374,6 +2374,7 @@ static inline void f2fs_change_bit(unsigned int nr, 
> >> char *addr)
> >>  #define F2FS_NOATIME_FL   0x0080 /* do not update 
> >> atime */
> >>  #define F2FS_INDEX_FL 0x1000 /* hash-indexed 
> >> directory */
> >>  #define F2FS_DIRSYNC_FL   0x0001 /* dirsync behaviour 
> >> (directories only) */
> >> +#define F2FS_NOCOW_FL 0x0080 /* Do not cow file */
> >>  #define F2FS_PROJINHERIT_FL   0x2000 /* Create with 
> >> parents projid */
> >>  
> >>  /* Flags that should be inherited by new inodes from their parent. */
> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >> index 7ca545874060..ae0fec54cac6 100644
> >> --- a/fs/f2fs/file.c
> >> +++ b/fs/f2fs/file.c
> >> @@ -1692,6 +1692,7 @@ static const struct {
> >>{ F2FS_NOATIME_FL,  FS_NOATIME_FL },
> >>{ F2FS_INDEX_FL,FS_INDEX_FL },
> >>{ F2FS_DIRSYNC_FL,  FS_DIRSYNC_FL },
> >> +  { F2FS_NOCOW_FL,FS_NOCOW_FL },
> >>{ F2FS_PROJINHERIT_FL,  FS_PROJINHERIT_FL },
> >>  };
> >>  
> >> @@ -1715,7 +1716,8 @@ static const struct {
> >>FS_NODUMP_FL |  \
> >>FS_NOATIME_FL | \
> >>FS_DIRSYNC_FL | \
> >> -  FS_PROJINHERIT_FL)
> >> +  FS_PROJINHERIT_FL | \
> >> +  FS_NOCOW_FL)
> >>  
> >>  /* Convert f2fs on-disk i_flags to FS_IOC_{GET,SET}FLAGS flags */
> >>  static inline u32 f2fs_iflags_to_fsflags(u32 iflags)
> >> @@ -1753,8 +1755,6 @@ static int f2fs_ioc_getflags(struct file *filp, 
> >> unsigned long arg)
> >>fsflags |= FS_ENCRYPT_FL;
> >>if (f2fs_has_inline_data(inode) || f2fs_has_inline_dentry(inode))
> >>fsflags |= FS_INLINE_DATA_FL;
> >> -  if (is_inode_flag_set(inode, FI_PIN_FILE))
> >> -  fsflags |= FS_NOCOW_FL;
> >>  
> >>fsflags &= F2FS_GETTABLE_FS_FL;
> >>  
> >> @@ -1794,6 +1794,22 @@ static int f2fs_ioc_setflags(struct file *filp, 
> >> unsigned long arg)
> >>if (ret)
> >>goto out;
> >>  
> >> +  if ((fsflags ^ old_fsflags) & FS_NOCOW_FL) {
> >> +  if (!S_ISREG(inode->i_mode)) {
> >> +  ret = -EINVAL;
> >> +  goto out;
> >> +  }
> >> +
> >> +  if (f2fs_should_update_outplace(inode, NULL)) {
> >> +  ret = -EINVAL;
> >> +  goto out;
> >> +  }
> >> +
> >> +  ret = f2fs_convert_inline_inode(inode);
> >> +  if (ret)
> >> +  goto out;
> >> +  }
> >> +
> >>ret = f2fs_setflags_common(inode, iflags,
> >>f2fs_fsflags_to_iflags(F2FS_SETTABLE_FS_FL));
> >>  out:
> >> -- 
> >> 2.18.0.rc1
> > .
> > 


Re: WARNING in __mmdrop

2019-07-28 Thread Jason Wang



On 2019/7/26 下午11:03, Jason Gunthorpe wrote:

On Fri, Jul 26, 2019 at 10:00:20PM +0800, Jason Wang wrote:

The question is, MMU notifier are allowed to be blocked on
invalidate_range_start() which could be much slower than synchronize_rcu()
to finish.

Looking at amdgpu_mn_invalidate_range_start_gfx() which calls
amdgpu_mn_invalidate_node() which did:

     r = reservation_object_wait_timeout_rcu(bo->tbo.resv,
     true, false, MAX_SCHEDULE_TIMEOUT);

...

The general guidance has been that invalidate_start should block
minimally, if at all.

I would say synchronize_rcu is outside that guidance.



Yes, I get this.




BTW, always returning EAGAIN for mmu_notifier_range_blockable() is not
good either, it should instead only return EAGAIN if any
vhost_map_range_overlap() is true.



Right, let me optimize that.

Thanks




Jason


[PATCH v2 6/6] pinctrl: aspeed: Add AST2600 pinmux support

2019-07-28 Thread Andrew Jeffery
The AST2600 pinmux is fairly similar to the previous generations of
ASPEED BMC SoCs in terms of architecture, though differ in some of the
design details. The complexity of the pin expressions is largely reduced
(e.g. there are no-longer signals with multiple expressions muxing them
to the associated pin), and there are now signals and buses with
multiple pin groups.

The driver implements pinmux support for all 244 GPIO-capable pins plus
a further four pins that are not GPIO capable but which expose multiple
signals. pinconf will be implemented in a follow-up patch.

The implementation has been smoke-tested under qemu, and run on hardware
by ASPEED.

Debugged-by: Johnny Huang 
Signed-off-by: Andrew Jeffery 

---
v2:
* Remove some redundant SIG_DESC_CLEAR()s from descriptors
---
 drivers/pinctrl/aspeed/Kconfig |8 +
 drivers/pinctrl/aspeed/Makefile|1 +
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c | 2355 
 3 files changed, 2364 insertions(+)
 create mode 100644 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c

diff --git a/drivers/pinctrl/aspeed/Kconfig b/drivers/pinctrl/aspeed/Kconfig
index 4cf54172f8fb..de8b185c4fee 100644
--- a/drivers/pinctrl/aspeed/Kconfig
+++ b/drivers/pinctrl/aspeed/Kconfig
@@ -23,3 +23,11 @@ config PINCTRL_ASPEED_G5
help
  Say Y here to enable pin controller support for Aspeed's 5th
  generation SoCs. GPIO is provided by a separate GPIO driver.
+
+config PINCTRL_ASPEED_G6
+   bool "Aspeed G6 SoC pin control"
+   depends on (MACH_ASPEED_G6 || COMPILE_TEST) && OF
+   select PINCTRL_ASPEED
+   help
+ Say Y here to enable pin controller support for Aspeed's 6th
+ generation SoCs. GPIO is provided by a separate GPIO driver.
diff --git a/drivers/pinctrl/aspeed/Makefile b/drivers/pinctrl/aspeed/Makefile
index ea8962645e49..489ea1778353 100644
--- a/drivers/pinctrl/aspeed/Makefile
+++ b/drivers/pinctrl/aspeed/Makefile
@@ -5,3 +5,4 @@ ccflags-y += $(call cc-option,-Woverride-init)
 obj-$(CONFIG_PINCTRL_ASPEED)   += pinctrl-aspeed.o pinmux-aspeed.o
 obj-$(CONFIG_PINCTRL_ASPEED_G4)+= pinctrl-aspeed-g4.o
 obj-$(CONFIG_PINCTRL_ASPEED_G5)+= pinctrl-aspeed-g5.o
+obj-$(CONFIG_PINCTRL_ASPEED_G6)+= pinctrl-aspeed-g6.o
diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
new file mode 100644
index ..b835c9bf3081
--- /dev/null
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c
@@ -0,0 +1,2355 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright (C) 2019 IBM Corp. */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../core.h"
+#include "../pinctrl-utils.h"
+#include "pinctrl-aspeed.h"
+
+#define SCU400 0x400 /* Multi-function Pin Control #1  */
+#define SCU404 0x404 /* Multi-function Pin Control #2  */
+#define SCU410 0x410 /* Multi-function Pin Control #4  */
+#define SCU414 0x414 /* Multi-function Pin Control #5  */
+#define SCU418 0x418 /* Multi-function Pin Control #6  */
+#define SCU41C 0x41C /* Multi-function Pin Control #7  */
+#define SCU430 0x430 /* Multi-function Pin Control #8  */
+#define SCU434 0x434 /* Multi-function Pin Control #9  */
+#define SCU438 0x438 /* Multi-function Pin Control #10 */
+#define SCU450 0x450 /* Multi-function Pin Control #14 */
+#define SCU4B0 0x4B0 /* Multi-function Pin Control #17 */
+#define SCU4B4 0x4B4 /* Multi-function Pin Control #18 */
+#define SCU4B8 0x4B8 /* Multi-function Pin Control #19 */
+#define SCU4BC 0x4BC /* Multi-function Pin Control #20 */
+#define SCU4D4 0x4D4 /* Multi-function Pin Control #22 */
+#define SCU4D8 0x4D8 /* Multi-function Pin Control #23 */
+#define SCU500 0x500 /* Hardware Strap 1 */
+#define SCU510 0x510 /* Hardware Strap 2 */
+#define SCU694 0x694 /* Multi-function Pin Control #25 */
+
+#define ASPEED_G6_NR_PINS 248
+
+#define M24 0
+SIG_EXPR_LIST_DECL_SESG(M24, MDC3, MDIO3, SIG_DESC_SET(SCU410, 0));
+SIG_EXPR_LIST_DECL_SESG(M24, SCL11, I2C11, SIG_DESC_SET(SCU4B0, 0));
+PIN_DECL_2(M24, GPIOA0, MDC3, SCL11);
+
+#define M25 1
+SIG_EXPR_LIST_DECL_SESG(M25, MDIO3, MDIO3, SIG_DESC_SET(SCU410, 1));
+SIG_EXPR_LIST_DECL_SESG(M25, SDA11, I2C11, SIG_DESC_SET(SCU4B0, 1));
+PIN_DECL_2(M25, GPIOA1, MDIO3, SDA11);
+
+FUNC_GROUP_DECL(MDIO3, M24, M25);
+FUNC_GROUP_DECL(I2C11, M24, M25);
+
+#define L26 2
+SIG_EXPR_LIST_DECL_SESG(L26, MDC4, MDIO4, SIG_DESC_SET(SCU410, 2));
+SIG_EXPR_LIST_DECL_SESG(L26, SCL12, I2C12, SIG_DESC_SET(SCU4B0, 2));
+PIN_DECL_2(L26, GPIOA2, MDC4, SCL12);
+
+#define K24 3
+SIG_EXPR_LIST_DECL_SESG(K24, MDIO4, MDIO4, SIG_DESC_SET(SCU410, 3));
+SIG_EXPR_LIST_DECL_SESG(K24, SDA12, I2C12, SIG_DESC_SET(SCU4B0, 3));
+PIN_DECL_2(K24, GPIOA3, MDIO4, SDA12);
+
+FUNC_GROUP_DECL(MDIO4, L26, K24);

[PATCH v2 5/6] pinctrl: aspeed: Add SIG_DESC_CLEAR() helper

2019-07-28 Thread Andrew Jeffery
The complement of SIG_DESC_SET().

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinmux-aspeed.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h 
b/drivers/pinctrl/aspeed/pinmux-aspeed.h
index 474820df6263..c59e936a7dde 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.h
@@ -508,6 +508,7 @@ struct aspeed_pin_desc {
  * @idx: The bit index in the register
  */
 #define SIG_DESC_SET(reg, idx) SIG_DESC_IP_BIT(ASPEED_IP_SCU, reg, idx, 1)
+#define SIG_DESC_CLEAR(reg, idx) SIG_DESC_IP_BIT(ASPEED_IP_SCU, reg, idx, 0)
 
 #define SIG_DESC_LIST_SYM(sig, group) sig_descs_ ## sig ## _ ## group
 #define SIG_DESC_LIST_DECL(sig, group, ...) \
-- 
2.20.1



[PATCH v2 1/6] dt-bindings: pinctrl: aspeed: Document AST2600 pinmux

2019-07-28 Thread Andrew Jeffery
The AST260 differs from the 2400 and 2500 in that it supports multiple
groups for a subset of functions.

Signed-off-by: Andrew Jeffery 

---
v2:
* Avoid patternProperties for fixed strings
* Don't needlessly quote strings
---
 .../pinctrl/aspeed,ast2600-pinctrl.yaml   | 115 ++
 1 file changed, 115 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml

diff --git 
a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml 
b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
new file mode 100644
index ..f83d888176cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: GPL-2.0+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/aspeed,ast2600-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 Pin Controller
+
+maintainers:
+  - Andrew Jeffery 
+
+description: |+
+  The pin controller node should be the child of a syscon node with the
+  required property:
+
+  - compatible: Should be one of the following:
+"aspeed,ast2600-scu", "syscon", "simple-mfd"
+
+  Refer to the the bindings described in
+  Documentation/devicetree/bindings/mfd/syscon.txt
+
+properties:
+  compatible:
+const: aspeed,ast2600-pinctrl
+
+patternProperties:
+  '^.*$':
+if:
+  type: object
+then:
+  properties:
+function:
+  allOf:
+- $ref: "/schemas/types.yaml#/definitions/string"
+- enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
+  ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, ESPI,
+  ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWSPIWP, GPIT0, GPIT1,
+  GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1, GPIU2,
+  GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, I2C1, I2C10, I2C11, I2C12,
+  I2C13, I2C14, I2C15, I2C16, I2C2, I2C3, I2C4, I2C5, I2C6, I2C7,
+  I2C8, I2C9, I3C3, I3C4, I3C5, I3C6, JTAGM, LHPD, LHSIRQ, LPC,
+  LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ, MACLINK1, MACLINK2,
+  MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3, MDIO4, NCTS1, NCTS2,
+  NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4, NDSR1, NDSR2, NDSR3,
+  NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1, NRI2, NRI3, NRI4, NRTS1,
+  NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE, PWM0, PWM1, PWM10, PWM11,
+  PWM12, PWM13, PWM14, PWM15, PWM2, PWM3, PWM4, PWM5, PWM6, PWM7,
+  PWM8, PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3,
+  RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12,
+  SALT13, SALT14, SALT15, SALT16, SALT2, SALT3, SALT4, SALT5,
+  SALT6, SALT7, SALT8, SALT9, SD1, SD2, SD3, SD3DAT4, SD3DAT5,
+  SD3DAT6, SD3DAT7, SGPM1, SGPS1, SIOONCTRL, SIOPBI, SIOPBO,
+  SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1,
+  SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11,
+  TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5,
+  TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1,
+  TXD2, TXD3, TXD4, UART10, UART11, UART12, UART13, UART6, UART7,
+  UART8, UART9, VB, VGAHS, VGAVS, WDTRST1, WDTRST2, WDTRST3,
+  WDTRST4, ]
+groups:
+  allOf:
+- $ref: "/schemas/types.yaml#/definitions/string"
+- enum: [ ADC0, ADC1, ADC10, ADC11, ADC12, ADC13, ADC14, ADC15,
+  ADC2, ADC3, ADC4, ADC5, ADC6, ADC7, ADC8, ADC9, BMCINT, ESPI,
+  ESPIALT, FSI1, FSI2, FWSPIABR, FWSPID, FWQSPID, FWSPIWP, GPIT0,
+  GPIT1, GPIT2, GPIT3, GPIT4, GPIT5, GPIT6, GPIT7, GPIU0, GPIU1,
+  GPIU2, GPIU3, GPIU4, GPIU5, GPIU6, GPIU7, HVI3C3, HVI3C4, I2C1,
+  I2C10, I2C11, I2C12, I2C13, I2C14, I2C15, I2C16, I2C2, I2C3,
+  I2C4, I2C5, I2C6, I2C7, I2C8, I2C9, I3C3, I3C4, I3C5, I3C6,
+  JTAGM, LHPD, LHSIRQ, LPC, LPCHC, LPCPD, LPCPME, LPCSMI, LSIRQ,
+  MACLINK1, MACLINK2, MACLINK3, MACLINK4, MDIO1, MDIO2, MDIO3,
+  MDIO4, NCTS1, NCTS2, NCTS3, NCTS4, NDCD1, NDCD2, NDCD3, NDCD4,
+  NDSR1, NDSR2, NDSR3, NDSR4, NDTR1, NDTR2, NDTR3, NDTR4, NRI1,
+  NRI2, NRI3, NRI4, NRTS1, NRTS2, NRTS3, NRTS4, OSCCLK, PEWAKE,
+  PWM0, PWM1, PWM10G0, PWM10G1, PWM11G0, PWM11G1, PWM12G0, PWM12G1,
+  PWM13G0, PWM13G1, PWM14G0, PWM14G1, PWM15G0, PWM15G1, PWM2, PWM3,
+  PWM4, PWM5, PWM6, PWM7, PWM8G0, PWM8G1, PWM9G0, PWM9G1, QSPI1,
+  QSPI2, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3,
+  RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1,
+  SALT11G0, SALT11G1, SALT12G0, SALT12G1, SALT13G0, SALT13G1,
+  SALT14G0, SALT14G1, SALT15G0, 

[PATCH v2 0/6] pinctrl: aspeed: Add AST2600 pinmux support

2019-07-28 Thread Andrew Jeffery
Hello,

This series adds pinmux support for the AST2600. v2 addresses some binding
comments from Rob and has some minor cleanups in the g6 driver implementation.

v1 can be found here:

https://lists.ozlabs.org/pipermail/linux-aspeed/2019-July/001999.html

Please review!

Andrew

Andrew Jeffery (6):
  dt-bindings: pinctrl: aspeed: Document AST2600 pinmux
  pinctrl: aspeed: Rename pin declaration macros
  pinctrl: aspeed: Add PIN_DECL_3() helper
  pinctrl: aspeed: Add multiple pin group support for functions
  pinctrl: aspeed: Add SIG_DESC_CLEAR() helper
  pinctrl: aspeed: Add AST2600 pinmux support

 .../pinctrl/aspeed,ast2600-pinctrl.yaml   |  115 +
 drivers/pinctrl/aspeed/Kconfig|8 +
 drivers/pinctrl/aspeed/Makefile   |1 +
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c| 1821 +++--
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c| 1865 +++--
 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c| 2355 +
 drivers/pinctrl/aspeed/pinmux-aspeed.h|  227 +-
 7 files changed, 4590 insertions(+), 1802 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml
 create mode 100644 drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c

-- 
2.20.1



[PATCH v2 3/6] pinctrl: aspeed: Add PIN_DECL_3() helper

2019-07-28 Thread Andrew Jeffery
This case is common in the AST2600, so add to the collection.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinmux-aspeed.h | 72 ++
 1 file changed, 40 insertions(+), 32 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h 
b/drivers/pinctrl/aspeed/pinmux-aspeed.h
index 0406beedd5ba..964dd5b242ac 100644
--- a/drivers/pinctrl/aspeed/pinmux-aspeed.h
+++ b/drivers/pinctrl/aspeed/pinmux-aspeed.h
@@ -604,38 +604,6 @@ struct aspeed_pin_desc {
static const struct aspeed_pin_desc PIN_SYM(pin) = \
{ #pin, PIN_EXPRS_PTR(pin) }
 
-/**
- * Declare a two-signal pin
- *
- * @pin: The pin number
- * @other: Macro name for "other" functionality (subjected to stringification)
- * @high: Macro name for the highest priority signal functions
- * @low: Macro name for the low signal functions
- *
- * For example:
- *
- * #define A8 56
- * SIG_EXPR_DECL(ROMD8, ROM16, SIG_DESC_SET(SCU90, 6));
- * SIG_EXPR_DECL(ROMD8, ROM16S, SIG_DESC_SET(HW_STRAP1, 4),
- *  { HW_STRAP1, GENMASK(1, 0), 0, 0 });
- * SIG_EXPR_LIST_DECL(ROMD8, SIG_EXPR_PTR(ROMD8, ROM16),
- *  SIG_EXPR_PTR(ROMD8, ROM16S));
- * SIG_EXPR_LIST_DECL_SINGLE(NCTS6, NCTS6, SIG_DESC_SET(SCU90, 7));
- * PIN_DECL_2(A8, GPIOH0, ROMD8, NCTS6);
- */
-#define PIN_DECL_2(pin, other, high, low) \
-   SIG_EXPR_LIST_DECL_SINGLE(other, other); \
-   PIN_DECL_(pin, \
-   SIG_EXPR_LIST_PTR(high), \
-   SIG_EXPR_LIST_PTR(low), \
-   SIG_EXPR_LIST_PTR(other))
-
-#define PIN_GROUP_SYM(func) pins_ ## func
-#define FUNC_GROUP_SYM(func) groups_ ## func
-#define FUNC_GROUP_DECL(func, ...) \
-   static const int PIN_GROUP_SYM(func)[] = { __VA_ARGS__ }; \
-   static const char *FUNC_GROUP_SYM(func)[] = { #func }
-
 /**
  * Declare a single signal pin
  *
@@ -670,6 +638,46 @@ struct aspeed_pin_desc {
SIG_EXPR_LIST_DECL_SINGLE(other, other); \
PIN_DECL_(pin, SIG_EXPR_LIST_PTR(sig), SIG_EXPR_LIST_PTR(other)); \
FUNC_GROUP_DECL(sig, pin)
+/**
+ * Declare a two-signal pin
+ *
+ * @pin: The pin number
+ * @other: Macro name for "other" functionality (subjected to stringification)
+ * @high: Macro name for the highest priority signal functions
+ * @low: Macro name for the low signal functions
+ *
+ * For example:
+ *
+ * #define A8 56
+ * SIG_EXPR_DECL(ROMD8, ROM16, SIG_DESC_SET(SCU90, 6));
+ * SIG_EXPR_DECL(ROMD8, ROM16S, SIG_DESC_SET(HW_STRAP1, 4),
+ *  { HW_STRAP1, GENMASK(1, 0), 0, 0 });
+ * SIG_EXPR_LIST_DECL(ROMD8, SIG_EXPR_PTR(ROMD8, ROM16),
+ *  SIG_EXPR_PTR(ROMD8, ROM16S));
+ * SIG_EXPR_LIST_DECL_SINGLE(NCTS6, NCTS6, SIG_DESC_SET(SCU90, 7));
+ * PIN_DECL_2(A8, GPIOH0, ROMD8, NCTS6);
+ */
+#define PIN_DECL_2(pin, other, high, low) \
+   SIG_EXPR_LIST_DECL_SINGLE(other, other); \
+   PIN_DECL_(pin, \
+   SIG_EXPR_LIST_PTR(high), \
+   SIG_EXPR_LIST_PTR(low), \
+   SIG_EXPR_LIST_PTR(other))
+
+#define PIN_DECL_3(pin, other, high, medium, low) \
+   SIG_EXPR_LIST_DECL_SINGLE(other, other); \
+   PIN_DECL_(pin, \
+   SIG_EXPR_LIST_PTR(high), \
+   SIG_EXPR_LIST_PTR(medium), \
+   SIG_EXPR_LIST_PTR(low), \
+   SIG_EXPR_LIST_PTR(other))
+
+#define PIN_GROUP_SYM(func) pins_ ## func
+#define FUNC_GROUP_SYM(func) groups_ ## func
+#define FUNC_GROUP_DECL(func, ...) \
+   static const int PIN_GROUP_SYM(func)[] = { __VA_ARGS__ }; \
+   static const char *FUNC_GROUP_SYM(func)[] = { #func }
+
 
 #define GPIO_PIN_DECL(pin, gpio) \
SIG_EXPR_LIST_DECL_SINGLE(gpio, gpio); \
-- 
2.20.1



[PATCH v2 2/6] pinctrl: aspeed: Rename pin declaration macros

2019-07-28 Thread Andrew Jeffery
Rename macros as follows:

* s/SS_PIN_DECL()/PIN_DECL_1()/
* s/MS_PIN_DECL()/PIN_DECL_2()/
* s/MS_PIN_DECL_()/PIN_DECL_()/

This is in preparation for adding PIN_DECL_3(). We could clean this up
with e.g. CPPMAGIC_MAP() from ccan, but that might be a bridge too far
given how much of a macro jungle we already have.

Signed-off-by: Andrew Jeffery 
---
 drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c | 372 +-
 drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 418 ++---
 drivers/pinctrl/aspeed/pinmux-aspeed.h |  20 +-
 3 files changed, 405 insertions(+), 405 deletions(-)

diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c 
b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
index 384396cbb22d..49ce5d62e442 100644
--- a/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
+++ b/drivers/pinctrl/aspeed/pinctrl-aspeed-g4.c
@@ -82,14 +82,14 @@ SSSF_PIN_DECL(E6, GPIOA3, TIMER4, SIG_DESC_SET(SCU80, 3));
 #define C5 4
 SIG_EXPR_LIST_DECL_SINGLE(SCL9, I2C9, I2C9_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(TIMER5, TIMER5, SIG_DESC_SET(SCU80, 4));
-MS_PIN_DECL(C5, GPIOA4, SCL9, TIMER5);
+PIN_DECL_2(C5, GPIOA4, SCL9, TIMER5);
 
 FUNC_GROUP_DECL(TIMER5, C5);
 
 #define B4 5
 SIG_EXPR_LIST_DECL_SINGLE(SDA9, I2C9, I2C9_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(TIMER6, TIMER6, SIG_DESC_SET(SCU80, 5));
-MS_PIN_DECL(B4, GPIOA5, SDA9, TIMER6);
+PIN_DECL_2(B4, GPIOA5, SDA9, TIMER6);
 
 FUNC_GROUP_DECL(TIMER6, B4);
 FUNC_GROUP_DECL(I2C9, C5, B4);
@@ -99,14 +99,14 @@ FUNC_GROUP_DECL(I2C9, C5, B4);
 #define A3 6
 SIG_EXPR_LIST_DECL_SINGLE(MDC2, MDIO2, MDIO2_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(TIMER7, TIMER7, SIG_DESC_SET(SCU80, 6));
-MS_PIN_DECL(A3, GPIOA6, MDC2, TIMER7);
+PIN_DECL_2(A3, GPIOA6, MDC2, TIMER7);
 
 FUNC_GROUP_DECL(TIMER7, A3);
 
 #define D5 7
 SIG_EXPR_LIST_DECL_SINGLE(MDIO2, MDIO2, MDIO2_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(TIMER8, TIMER8, SIG_DESC_SET(SCU80, 7));
-MS_PIN_DECL(D5, GPIOA7, MDIO2, TIMER8);
+PIN_DECL_2(D5, GPIOA7, MDIO2, TIMER8);
 
 FUNC_GROUP_DECL(TIMER8, D5);
 FUNC_GROUP_DECL(MDIO2, A3, D5);
@@ -127,7 +127,7 @@ SSSF_PIN_DECL(F18, GPIOB3, SALT4, SIG_DESC_SET(SCU80, 11));
 SIG_EXPR_DECL(LPCRST, LPCRST, SIG_DESC_SET(SCU80, 12));
 SIG_EXPR_DECL(LPCRST, LPCRSTS, SIG_DESC_SET(HW_STRAP1, 14));
 SIG_EXPR_LIST_DECL_DUAL(LPCRST, LPCRST, LPCRSTS);
-SS_PIN_DECL(E19, GPIOB4, LPCRST);
+PIN_DECL_1(E19, GPIOB4, LPCRST);
 
 FUNC_GROUP_DECL(LPCRST, E19);
 
@@ -135,7 +135,7 @@ FUNC_GROUP_DECL(LPCRST, E19);
 #define H19_DESCSIG_DESC_SET(SCU80, 13)
 SIG_EXPR_LIST_DECL_SINGLE(LPCPD, LPCPD, H19_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(LPCSMI, LPCSMI, H19_DESC);
-MS_PIN_DECL(H19, GPIOB5, LPCPD, LPCSMI);
+PIN_DECL_2(H19, GPIOB5, LPCPD, LPCSMI);
 
 FUNC_GROUP_DECL(LPCPD, H19);
 FUNC_GROUP_DECL(LPCSMI, H19);
@@ -151,7 +151,7 @@ SIG_EXPR_LIST_DECL_SINGLE(EXTRST, EXTRST,
 SIG_EXPR_LIST_DECL_SINGLE(SPICS1, SPICS1,
SIG_DESC_SET(SCU80, 15),
SIG_DESC_SET(SCU90, 31));
-MS_PIN_DECL(E18, GPIOB7, EXTRST, SPICS1);
+PIN_DECL_2(E18, GPIOB7, EXTRST, SPICS1);
 
 FUNC_GROUP_DECL(EXTRST, E18);
 FUNC_GROUP_DECL(SPICS1, E18);
@@ -162,12 +162,12 @@ FUNC_GROUP_DECL(SPICS1, E18);
 #define C4 16
 SIG_EXPR_LIST_DECL_SINGLE(SD1CLK, SD1, SD1_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(SCL10, I2C10, I2C10_DESC);
-MS_PIN_DECL(C4, GPIOC0, SD1CLK, SCL10);
+PIN_DECL_2(C4, GPIOC0, SD1CLK, SCL10);
 
 #define B3 17
 SIG_EXPR_LIST_DECL_SINGLE(SD1CMD, SD1, SD1_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(SDA10, I2C10, I2C10_DESC);
-MS_PIN_DECL(B3, GPIOC1, SD1CMD, SDA10);
+PIN_DECL_2(B3, GPIOC1, SD1CMD, SDA10);
 
 FUNC_GROUP_DECL(I2C10, C4, B3);
 
@@ -176,12 +176,12 @@ FUNC_GROUP_DECL(I2C10, C4, B3);
 #define A2 18
 SIG_EXPR_LIST_DECL_SINGLE(SD1DAT0, SD1, SD1_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(SCL11, I2C11, I2C11_DESC);
-MS_PIN_DECL(A2, GPIOC2, SD1DAT0, SCL11);
+PIN_DECL_2(A2, GPIOC2, SD1DAT0, SCL11);
 
 #define E5 19
 SIG_EXPR_LIST_DECL_SINGLE(SD1DAT1, SD1, SD1_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(SDA11, I2C11, I2C11_DESC);
-MS_PIN_DECL(E5, GPIOC3, SD1DAT1, SDA11);
+PIN_DECL_2(E5, GPIOC3, SD1DAT1, SDA11);
 
 FUNC_GROUP_DECL(I2C11, A2, E5);
 
@@ -190,12 +190,12 @@ FUNC_GROUP_DECL(I2C11, A2, E5);
 #define D4 20
 SIG_EXPR_LIST_DECL_SINGLE(SD1DAT2, SD1, SD1_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(SCL12, I2C12, I2C12_DESC);
-MS_PIN_DECL(D4, GPIOC4, SD1DAT2, SCL12);
+PIN_DECL_2(D4, GPIOC4, SD1DAT2, SCL12);
 
 #define C3 21
 SIG_EXPR_LIST_DECL_SINGLE(SD1DAT3, SD1, SD1_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(SDA12, I2C12, I2C12_DESC);
-MS_PIN_DECL(C3, GPIOC5, SD1DAT3, SDA12);
+PIN_DECL_2(C3, GPIOC5, SD1DAT3, SDA12);
 
 FUNC_GROUP_DECL(I2C12, D4, C3);
 
@@ -204,12 +204,12 @@ FUNC_GROUP_DECL(I2C12, D4, C3);
 #define B2 22
 SIG_EXPR_LIST_DECL_SINGLE(SD1CD, SD1, SD1_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(SCL13, I2C13, I2C13_DESC);
-MS_PIN_DECL(B2, GPIOC6, SD1CD, SCL13);
+PIN_DECL_2(B2, GPIOC6, SD1CD, SCL13);
 
 #define A1 23
 SIG_EXPR_LIST_DECL_SINGLE(SD1WP, SD1, SD1_DESC);
 SIG_EXPR_LIST_DECL_SINGLE(SDA13, I2C13, I2C13_DESC);
-MS_PIN_DECL(A1, GPIOC7, SD1WP, SDA13);
+PIN_DECL_2(A1, GPIOC7, 

Re: WARNING in __mmdrop

2019-07-28 Thread Jason Wang



On 2019/7/26 下午9:49, Michael S. Tsirkin wrote:

Ok, let me retry if necessary (but I do remember I end up with deadlocks
last try).

Ok, I play a little with this. And it works so far. Will do more testing
tomorrow.

One reason could be I switch to use get_user_pages_fast() to
__get_user_pages_fast() which doesn't need mmap_sem.

Thanks

OK that sounds good. If we also set a flag to make
vhost_exceeds_weight exit, then I think it will be all good.



After some experiments, I came up two methods:

1) switch to use vq->mutex, then we must take the vq lock during range 
checking (but I don't see obvious slowdown for 16vcpus + 16queues). 
Setting flags during weight check should work but it still can't address 
the worst case: wait for the page to be swapped in. Is this acceptable?


2) using current RCU but replace synchronize_rcu() with 
vhost_work_flush(). The worst case is the same as 1) but we can check 
range without holding any locks.


Which one did you prefer?

Thanks



Re: [BUG] infiniband: mlx5: a possible null-pointer dereference in set_roce_addr()

2019-07-28 Thread Leon Romanovsky
On Mon, Jul 29, 2019 at 05:26:30AM +, Parav Pandit wrote:
>
>
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org  > ow...@vger.kernel.org> On Behalf Of Parav Pandit
> > Sent: Monday, July 29, 2019 10:55 AM
> > To: Jia-Ju Bai ; l...@kernel.org;
> > dledf...@redhat.com; j...@ziepe.ca
> > Cc: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: RE: [BUG] infiniband: mlx5: a possible null-pointer dereference in
> > set_roce_addr()
> >
> > Hi Jia,
> >
> > > -Original Message-
> > > From: linux-rdma-ow...@vger.kernel.org  > > ow...@vger.kernel.org> On Behalf Of Jia-Ju Bai
> > > Sent: Monday, July 29, 2019 7:47 AM
> > > To: l...@kernel.org; dledf...@redhat.com; j...@ziepe.ca
> > > Cc: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
> > > Subject: [BUG] infiniband: mlx5: a possible null-pointer dereference
> > > in
> > > set_roce_addr()
> > >
> > > In set_roce_addr(), there is an if statement on line 589 to check
> > > whether gid is
> > > NULL:
> > >      if (gid)
> > >
> > > When gid is NULL, it is used on line 613:
> > >      return mlx5_core_roce_gid_set(..., gid->raw, ...);
> > >
> > > Thus, a possible null-pointer dereference may occur.
> > >
> > > This bug is found by a static analysis tool STCheck written by us.
> > >
> > While static checker is right, it is not a real bug, because gid->raw 
> > pointer
> > points to GID entry itself so when GID is NULL, gid->raw is NULL too.
> >
> > One way to suppress the static checker warning/error is below patch.
> > Will let Leon review it.
> >
> > > I do not know how to correctly fix this bug, so I only report it.
> > >
> > >
> > > Best wishes,
> > > Jia-Ju Bai
> >
> > From 30e055dba77e595bf88aebd3a9c75ed76bc9c65a Mon Sep 17 00:00:00
> > 2001
> > From: Parav Pandit 
> > Date: Mon, 29 Jul 2019 00:13:21 -0500
> > Subject: [PATCH] IB/mlx5: Avoid static checker warning for NULL access
> >
> > union ib_gid *gid and gid->raw pointers refers to the same address.
> > However some static checker reports this as possible NULL access warning in
> > call to mlx5_core_roce_gid_set().
> >
> > To suppress such warning, instead of working on raw GID element, expose API
> > using union ib_gid*.
> >
> > Reported-by: Jia-Ju Bai 
> > Signed-off-by: Parav Pandit 
> > ---
> >  drivers/infiniband/hw/mlx5/main.c   |  2 +-
> >  drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c | 12 +++-
> >  drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c   |  5 +++--
> >  drivers/net/ethernet/mellanox/mlx5/core/rdma.c  |  2 +-
> >  include/linux/mlx5/driver.h |  4 +++-
> >  5 files changed, 15 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/mlx5/main.c
> > b/drivers/infiniband/hw/mlx5/main.c
> > index c2a5780cb394..e60785bad7ef 100644
> > --- a/drivers/infiniband/hw/mlx5/main.c
> > +++ b/drivers/infiniband/hw/mlx5/main.c
> > @@ -610,7 +610,7 @@ static int set_roce_addr(struct mlx5_ib_dev *dev, u8
> > port_num,
> > }
> >
> > return mlx5_core_roce_gid_set(dev->mdev, index, roce_version,
> > - roce_l3_type, gid->raw, mac,
> > + roce_l3_type, , mac,
> >   vlan_id < VLAN_CFI_MASK, vlan_id,
> >   port_num);
> >  }
> > diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
> > b/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
> > index 4c50efe4e7f1..76b8236af9c7 100644
> > --- a/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
> > +++ b/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
> > @@ -850,6 +850,7 @@ struct mlx5_fpga_conn *mlx5_fpga_conn_create(struct
> > mlx5_fpga_device *fdev,
> >  enum mlx5_ifc_fpga_qp_type
> > qp_type)  {
> > struct mlx5_fpga_conn *ret, *conn;
> > +   struct ib_gid remote_gid = {};
> > u8 *remote_mac, *remote_ip;
> > int err;
> >
> > @@ -876,11 +877,12 @@ struct mlx5_fpga_conn
> > *mlx5_fpga_conn_create(struct mlx5_fpga_device *fdev,
> > goto err;
> > }
> >
> > -   /* Build Modified EUI-64 IPv6 address from the MAC address */
> > remote_ip = MLX5_ADDR_OF(fpga_qpc, conn->fpga_qpc, remote_ip);
> > -   remote_ip[0] = 0xfe;
> > -   remote_ip[1] = 0x80;
> > -   addrconf_addr_eui48(_ip[8], remote_mac);
> > +   memcpy(remote_gid.raw[0], remote_ip, sizeof(remote_gid.raw));
> > +   /* Build Modified EUI-64 IPv6 address from the MAC address */
> > +   remte_gid.raw[0] = 0xfe;
> > +   remte_gid.raw[1] = 0x80;
> > +   addrconf_addr_eui48(_gid.raw[8], remote_mac);
> >
> > err = mlx5_core_reserved_gid_alloc(fdev->mdev, 
> > >qp.sgid_index);
> > if (err) {
> > @@ -892,7 +894,7 @@ struct mlx5_fpga_conn *mlx5_fpga_conn_create(struct
> > mlx5_fpga_device *fdev,
> > err = mlx5_core_roce_gid_set(fdev->mdev, conn->qp.sgid_index,
> >  MLX5_ROCE_VERSION_2,
> >  

[v2] mailbox: imx: add support for imx v1 mu

2019-07-28 Thread Richard Zhu
There is a version1.0 MU on i.MX7ULP platform.
One new version ID register is added, and it's offset is 0.
TRn registers are defined at the offset 0x20 ~ 0x2C.
RRn registers are defined at the offset 0x40 ~ 0x4C.
SR/CR registers are defined at 0x60/0x64.
Extend this driver to support it.

Signed-off-by: Richard Zhu 
Suggested-by: Oleksij Rempel 
Reviewed-by: Dong Aisheng 
---
 drivers/mailbox/imx-mailbox.c | 67 ---
 1 file changed, 50 insertions(+), 17 deletions(-)

diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 25be8bb..8423a38 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -12,19 +12,11 @@
 #include 
 #include 
 
-/* Transmit Register */
-#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
-/* Receive Register */
-#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
-/* Status Register */
-#define IMX_MU_xSR 0x20
 #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
 #define IMX_MU_xSR_RFn(x)  BIT(24 + (3 - (x)))
 #define IMX_MU_xSR_TEn(x)  BIT(20 + (3 - (x)))
 #define IMX_MU_xSR_BRDIP   BIT(9)
 
-/* Control Register */
-#define IMX_MU_xCR 0x24
 /* General Purpose Interrupt Enable */
 #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
 /* Receive Interrupt Enable */
@@ -44,6 +36,13 @@ enum imx_mu_chan_type {
IMX_MU_TYPE_RXDB,   /* Rx doorbell */
 };
 
+struct imx_mu_dcfg {
+   u32 xTR[4]; /* Transmit Registers */
+   u32 xRR[4]; /* Receive Registers */
+   u32 xSR;/* Status Register */
+   u32 xCR;/* Control Register */
+};
+
 struct imx_mu_con_priv {
unsigned intidx;
charirq_desc[IMX_MU_CHAN_NAME_SIZE];
@@ -61,12 +60,39 @@ struct imx_mu_priv {
struct mbox_chanmbox_chans[IMX_MU_CHANS];
 
struct imx_mu_con_priv  con_priv[IMX_MU_CHANS];
+   const struct imx_mu_dcfg*dcfg;
struct clk  *clk;
int irq;
 
boolside_b;
 };
 
+static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
+   .xTR[0] = 0x0,
+   .xTR[1] = 0x4,
+   .xTR[2] = 0x8,
+   .xTR[3] = 0xC,
+   .xRR[0] = 0x10,
+   .xRR[1] = 0x14,
+   .xRR[2] = 0x18,
+   .xRR[3] = 0x1C,
+   .xSR= 0x20,
+   .xCR= 0x24,
+};
+
+static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
+   .xTR[0] = 0x20,
+   .xTR[1] = 0x24,
+   .xTR[2] = 0x28,
+   .xTR[3] = 0x2C,
+   .xRR[0] = 0x40,
+   .xRR[1] = 0x44,
+   .xRR[2] = 0x48,
+   .xRR[3] = 0x4C,
+   .xSR= 0x60,
+   .xCR= 0x64,
+};
+
 static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
 {
return container_of(mbox, struct imx_mu_priv, mbox);
@@ -88,10 +114,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32 
set, u32 clr)
u32 val;
 
spin_lock_irqsave(>xcr_lock, flags);
-   val = imx_mu_read(priv, IMX_MU_xCR);
+   val = imx_mu_read(priv, priv->dcfg->xCR);
val &= ~clr;
val |= set;
-   imx_mu_write(priv, val, IMX_MU_xCR);
+   imx_mu_write(priv, val, priv->dcfg->xCR);
spin_unlock_irqrestore(>xcr_lock, flags);
 
return val;
@@ -111,8 +137,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
struct imx_mu_con_priv *cp = chan->con_priv;
u32 val, ctrl, dat;
 
-   ctrl = imx_mu_read(priv, IMX_MU_xCR);
-   val = imx_mu_read(priv, IMX_MU_xSR);
+   ctrl = imx_mu_read(priv, priv->dcfg->xCR);
+   val = imx_mu_read(priv, priv->dcfg->xSR);
 
switch (cp->type) {
case IMX_MU_TYPE_TX:
@@ -138,10 +164,10 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
mbox_chan_txdone(chan, 0);
} else if (val == IMX_MU_xSR_RFn(cp->idx)) {
-   dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
+   dat = imx_mu_read(priv, priv->dcfg->xRR[cp->idx]);
mbox_chan_received_data(chan, (void *));
} else if (val == IMX_MU_xSR_GIPn(cp->idx)) {
-   imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), IMX_MU_xSR);
+   imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), priv->dcfg->xSR);
mbox_chan_received_data(chan, NULL);
} else {
dev_warn_ratelimited(priv->dev, "Not handled interrupt\n");
@@ -159,7 +185,7 @@ static int imx_mu_send_data(struct mbox_chan *chan, void 
*data)
 
switch (cp->type) {
case IMX_MU_TYPE_TX:
-   imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
+   imx_mu_write(priv, *arg, priv->dcfg->xTR[cp->idx]);
imx_mu_xcr_rmw(priv, IMX_MU_xCR_TIEn(cp->idx), 0);
break;
case IMX_MU_TYPE_TXDB:
@@ -257,7 +283,7 @@ static void imx_mu_init_generic(struct imx_mu_priv *priv)
return;
 
   

[v2] mailbox: imx: add support for imx v1 mu

2019-07-28 Thread Richard Zhu
Changes:
v1 --> v2:
  - Use to have the register layout linked on probe, suggested by
  Oleksij Rempel .
  - Add the Reviewed-by: Dong Aisheng  tag.

[v2] mailbox: imx: add support for imx v1 mu
---
 drivers/mailbox/imx-mailbox.c | 67 ---
 1 file changed, 50 insertions(+), 17 deletions(-)


Re: [PATCH v2] lkmm/docs: Correct ->prop example with additional rfe link

2019-07-28 Thread Boqun Feng
On Sun, Jul 28, 2019 at 11:35:44AM -0400, Joel Fernandes wrote:
[...]
> > > > > +load of y (rfe link), P2's smp_store_release() ensures that P2's load
> > > > > +of y executes before P2's store to z (second fence), which implies 
> > > > > that
> > > > > +that stores to x and y propagate to P2 before the 
> > > > > smp_store_release(), which
> > > > > +means that P2's smp_store_release() will propagate stores to x and y 
> > > > > to all
> > > > > +CPUs before the store to z propagates (A-cumulative property of this 
> > > > > fence).
> > > > > +Finally P0's load of z executes after P2's store to z has propagated 
> > > > > to
> > > > > +P0 (rfe link).
> > > > 
> > > > Again, a better change would be simply to replace the two instances of
> > > > "fence" in the original text with "cumul-fence".
> > > 
> > > Ok that's fine. But I still feel the rfe is not a part of the cumul-fence.
> > > The fences have nothing to do with the rfe. Or, I am missing something 
> > > quite
> > > badly.
> > > 
> > > Boqun, did you understand what Alan is saying?
> > > 
> > 
> > I think 'cumul-fence' that Alan mentioned is not a fence, but a
> > relation, which could be the result of combining a rfe relation and a
> > A-cumulative fence relation. Please see the section "PROPAGATION ORDER
> > RELATION: cumul-fence" or the definition of cumul-fence in
> > linux-kernel.cat.
> > 
> > Did I get you right, Alan? If so, your suggestion is indeed a better
> > change.
> 
> To be frank, I don't think it is better if that's what Alan meant. It is
> better to be explicit about the ->rfe so that the reader walking through the
> example can clearly see the ordering and make sense of it.
> 
> Just saying 'cumul-fence' and then hoping the reader sees the light is quite
> a big assumption and makes the document less readable.
> 

After a bit more rereading of the document, I still think Alan's way is
better ;-)

Please consider the context of paragraph, this is an explanation of an
example, which is about the previous sentence:

The formal definition of the prop relation involves a coe or
fre link, followed by an arbitrary number of cumul-fence links,
ending with an rfe link.

, so using "cumul-fence" actually matches the definition of ->prop.

For the ease of readers, I can think of two ways:

1.  Add a backwards reference to cumul-fence section here, right
before using its name.

2.  Use "->cumul-fence" notation rather than "cumul-fence" here,
i.e. add an arrow "->" before the name to call it out that name
"cumul-fence" here stands for links/relations rather than a
fence/barrier. Maybe it's better to convert all references to 
links/relations to the "->" notations in the whole doc.

Thoughts?

Regards,
Boqun

> I mean the fact that you are asking Alan for clarification, means that it is
> not that obvious ;)
> 
> thanks,
> 
>  - Joel
> 
> 


signature.asc
Description: PGP signature


Re: [BUG] ALSA: core: seq: a possible double-lock bug in snd_seq_midisynth_remove()

2019-07-28 Thread Takashi Iwai
On Mon, 29 Jul 2019 05:54:07 +0200,
Jia-Ju Bai wrote:
> 
> In snd_seq_midisynth_remove(), there is a possible double-lock bug:
> snd_seq_midisynth_remove()
>     mutex_lock(_mutex); -- line 421
>     snd_seq_delete_kernel_client() --- line 436
>     seq_free_client() -- line 2244
>     mutex_lock(_mutex); -- line 294
> 
> This bug is found by a static analysis tool STCheck written by us.

No, it's a false-positive report.  Both register_mutex's are
static, hence they are local to each file.  That is, you're looking at
two different mutexes.


Takashi


Re: [PATCH V4 net-next 00/10] net: hns3: some code optimizations & bugfixes & features

2019-07-28 Thread Saeed Mahameed
On Mon, 2019-07-29 at 10:53 +0800, Huazhong Tan wrote:
> This patch-set includes code optimizations, bugfixes and features for
> the HNS3 ethernet controller driver.
> 
> [patch 1/10] checks reset status before setting channel.
> 
> [patch 2/10] adds a NULL pointer checking.
> 
> [patch 3/10] removes reset level upgrading when current reset fails.
> 
> [patch 4/10] fixes a GFP flags errors when holding spin_lock.
> 
> [patch 5/10] modifies firmware version format.
> 
> [patch 6/10] adds some print information which is off by default.
> 
> [patch 7/10 - 8/10] adds two code optimizations about interrupt
> handler
> and work task.
> 
> [patch 9/10] adds support for using order 1 pages with a 4K buffer.
> 
> [patch 10/10] modifies messages prints with dev_info() instead of
> pr_info().
> 
> Change log:
> V3->V4: replace netif_info with netif_dbg in [patch 6/10]
> V2->V3: fixes comments from Saeed Mahameed and Joe Perches.
> V1->V2: fixes comments from Saeed Mahameed and
>   removes previous [patch 4/11] and [patch 11/11]
>   which needs further discussion, and adds a new
>   patch [10/10] suggested by Saeed Mahameed.
> 

Reviewed-by: Saeed Mahameed 


[PATCH 2/2] uprobe: collapse THP pmd after removing all uprobes

2019-07-28 Thread Song Liu
After all uprobes are removed from the huge page (with PTE pgtable), it
is possible to collapse the pmd and benefit from THP again. This patch
does the collapse by calling khugepaged_add_pte_mapped_thp().

Signed-off-by: Song Liu 
---
 kernel/events/uprobes.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 58ab7fc7272a..cc53789fefc6 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -470,6 +471,7 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct 
mm_struct *mm,
struct page *old_page, *new_page;
struct vm_area_struct *vma;
int ret, is_register, ref_ctr_updated = 0;
+   bool orig_page_huge = false;
 
is_register = is_swbp_insn();
uprobe = container_of(auprobe, struct uprobe, arch);
@@ -525,6 +527,9 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, struct 
mm_struct *mm,
 
/* dec_mm_counter for old_page */
dec_mm_counter(mm, MM_ANONPAGES);
+
+   if (PageCompound(orig_page))
+   orig_page_huge = true;
}
put_page(orig_page);
}
@@ -543,6 +548,10 @@ int uprobe_write_opcode(struct arch_uprobe *auprobe, 
struct mm_struct *mm,
if (ret && is_register && ref_ctr_updated)
update_ref_ctr(uprobe, mm, -1);
 
+   /* try collapse pmd for compound page */
+   if (!ret && orig_page_huge)
+   khugepaged_add_pte_mapped_thp(mm, vaddr & HPAGE_PMD_MASK);
+
return ret;
 }
 
-- 
2.17.1



[PATCH 0/2] khugepaged: collapse pmd for pte-mapped THP

2019-07-28 Thread Song Liu
This set is the newer version of 5/6 and 6/6 of [1]. v9 of 1-4 of
the work [2] was recently picked by Andrew.

Patch 1 enables khugepaged to handle pte-mapped THP. These THPs are left
in such state when khugepaged failed to get exclusive lock of mmap_sem.

Patch 2 leverages work in 1 for uprobe on THP. After [2], uprobe only
splits the PMD. When the uprobe is disabled, we get pte-mapped THP.
After this set, these pte-mapped THP will be collapsed as pmd-mapped.

[1] https://lkml.org/lkml/2019/6/23/23
[2] https://www.spinics.net/lists/linux-mm/msg185889.html

Song Liu (2):
  khugepaged: enable collapse pmd for pte-mapped THP
  uprobe: collapse THP pmd after removing all uprobes

 include/linux/khugepaged.h |  15 
 kernel/events/uprobes.c|   9 +++
 mm/khugepaged.c| 136 +
 3 files changed, 160 insertions(+)

--
2.17.1


[PATCH 1/2] khugepaged: enable collapse pmd for pte-mapped THP

2019-07-28 Thread Song Liu
khugepaged needs exclusive mmap_sem to access page table. When it fails
to lock mmap_sem, the page will fault in as pte-mapped THP. As the page
is already a THP, khugepaged will not handle this pmd again.

This patch enables the khugepaged to retry collapse the page table.

struct mm_slot (in khugepaged.c) is extended with an array, containing
addresses of pte-mapped THPs. We use array here for simplicity. We can
easily replace it with more advanced data structures when needed. This
array is protected by khugepaged_mm_lock.

In khugepaged_scan_mm_slot(), if the mm contains pte-mapped THP, we try
to collapse the page table.

Since collapse may happen at an later time, some pages may already fault
in. collapse_pte_mapped_thp() is added to properly handle these pages.
collapse_pte_mapped_thp() also double checks whether all ptes in this pmd
are mapping to the same THP. This is necessary because some subpage of
the THP may be replaced, for example by uprobe. In such cases, it is not
possible to collapse the pmd.

Signed-off-by: Song Liu 
---
 include/linux/khugepaged.h |  15 
 mm/khugepaged.c| 136 +
 2 files changed, 151 insertions(+)

diff --git a/include/linux/khugepaged.h b/include/linux/khugepaged.h
index 082d1d2a5216..2d700830fe0e 100644
--- a/include/linux/khugepaged.h
+++ b/include/linux/khugepaged.h
@@ -15,6 +15,16 @@ extern int __khugepaged_enter(struct mm_struct *mm);
 extern void __khugepaged_exit(struct mm_struct *mm);
 extern int khugepaged_enter_vma_merge(struct vm_area_struct *vma,
  unsigned long vm_flags);
+#ifdef CONFIG_SHMEM
+extern int khugepaged_add_pte_mapped_thp(struct mm_struct *mm,
+unsigned long addr);
+#else
+static inline int khugepaged_add_pte_mapped_thp(struct mm_struct *mm,
+   unsigned long addr)
+{
+   return 0;
+}
+#endif
 
 #define khugepaged_enabled()  \
(transparent_hugepage_flags &  \
@@ -73,6 +83,11 @@ static inline int khugepaged_enter_vma_merge(struct 
vm_area_struct *vma,
 {
return 0;
 }
+static inline int khugepaged_add_pte_mapped_thp(struct mm_struct *mm,
+   unsigned long addr)
+{
+   return 0;
+}
 #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
 
 #endif /* _LINUX_KHUGEPAGED_H */
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index eaaa21b23215..247c25aeb096 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -76,6 +76,7 @@ static __read_mostly DEFINE_HASHTABLE(mm_slots_hash, 
MM_SLOTS_HASH_BITS);
 
 static struct kmem_cache *mm_slot_cache __read_mostly;
 
+#define MAX_PTE_MAPPED_THP 8
 /**
  * struct mm_slot - hash lookup from mm to mm_slot
  * @hash: hash collision list
@@ -86,6 +87,10 @@ struct mm_slot {
struct hlist_node hash;
struct list_head mm_node;
struct mm_struct *mm;
+
+   /* pte-mapped THP in this mm */
+   int nr_pte_mapped_thp;
+   unsigned long pte_mapped_thp[MAX_PTE_MAPPED_THP];
 };
 
 /**
@@ -1281,11 +1286,141 @@ static void retract_page_tables(struct address_space 
*mapping, pgoff_t pgoff)
up_write(>vm_mm->mmap_sem);
mm_dec_nr_ptes(vma->vm_mm);
pte_free(vma->vm_mm, pmd_pgtable(_pmd));
+   } else if (down_read_trylock(>vm_mm->mmap_sem)) {
+   /* need down_read for khugepaged_test_exit() */
+   khugepaged_add_pte_mapped_thp(vma->vm_mm, addr);
+   up_read(>vm_mm->mmap_sem);
}
}
i_mmap_unlock_write(mapping);
 }
 
+/*
+ * Notify khugepaged that given addr of the mm is pte-mapped THP. Then
+ * khugepaged should try to collapse the page table.
+ */
+int khugepaged_add_pte_mapped_thp(struct mm_struct *mm, unsigned long addr)
+{
+   struct mm_slot *mm_slot;
+   int ret = 0;
+
+   /* hold mmap_sem for khugepaged_test_exit() */
+   VM_BUG_ON_MM(!rwsem_is_locked(>mmap_sem), mm);
+
+   if (unlikely(khugepaged_test_exit(mm)))
+   return 0;
+
+   if (!test_bit(MMF_VM_HUGEPAGE, >flags) &&
+   !test_bit(MMF_DISABLE_THP, >flags)) {
+   ret = __khugepaged_enter(mm);
+   if (ret)
+   return ret;
+   }
+
+   spin_lock(_mm_lock);
+   mm_slot = get_mm_slot(mm);
+   if (likely(mm_slot && mm_slot->nr_pte_mapped_thp < MAX_PTE_MAPPED_THP))
+   mm_slot->pte_mapped_thp[mm_slot->nr_pte_mapped_thp++] = addr;
+
+   spin_unlock(_mm_lock);
+   return 0;
+}
+
+/**
+ * Try to collapse a pte-mapped THP for mm at address haddr.
+ *
+ * This function checks whether all the PTEs in the PMD are pointing to the
+ * right THP. If so, retract the page table so the THP can refault in with
+ * as pmd-mapped.
+ */
+static void collapse_pte_mapped_thp(struct 

Re: [PATCH v2 0/5] Allocate memmap from hotadded memory

2019-07-28 Thread Rashmica Gupta
On Tue, 2019-07-16 at 14:28 +0200, David Hildenbrand wrote:
> On 02.07.19 08:42, Rashmica Gupta wrote:
> > Hi David,
> > 
> > Sorry for the late reply.
> 
> Hi,
> 
> sorry I was on PTO :)
> 
> > On Wed, 2019-06-26 at 10:28 +0200, David Hildenbrand wrote:
> > > On 26.06.19 10:15, Oscar Salvador wrote:
> > > > On Wed, Jun 26, 2019 at 10:11:06AM +0200, David Hildenbrand
> > > > wrote:
> > > > > Back then, I already mentioned that we might have some users
> > > > > that
> > > > > remove_memory() they never added in a granularity it wasn't
> > > > > added. My
> > > > > concerns back then were never fully sorted out.
> > > > > 
> > > > > arch/powerpc/platforms/powernv/memtrace.c
> > > > > 
> > > > > - Will remove memory in memory block size chunks it never
> > > > > added
> > > > > - What if that memory resides on a DIMM added via
> > > > > MHP_MEMMAP_DEVICE?
> > > > > 
> > > > > Will it at least bail out? Or simply break?
> > > > > 
> > > > > IOW: I am not yet 100% convinced that MHP_MEMMAP_DEVICE is
> > > > > save
> > > > > to be
> > > > > introduced.
> > > > 
> > > > Uhm, I will take a closer look and see if I can clear your
> > > > concerns.
> > > > TBH, I did not try to use
> > > > arch/powerpc/platforms/powernv/memtrace.c
> > > > yet.
> > > > 
> > > > I will get back to you once I tried it out.
> > > > 
> > > 
> > > BTW, I consider the code in
> > > arch/powerpc/platforms/powernv/memtrace.c
> > > very ugly and dangerous.
> > 
> > Yes it would be nice to clean this up.
> > 
> > > We should never allow to manually
> > > offline/online pages / hack into memory block states.
> > > 
> > > What I would want to see here is rather:
> > > 
> > > 1. User space offlines the blocks to be used
> > > 2. memtrace installs a hotplug notifier and hinders the blocks it
> > > wants
> > > to use from getting onlined.
> > > 3. memory is not added/removed/onlined/offlined in memtrace code.
> > > 
> > 
> > I remember looking into doing it a similar way. I can't recall the
> > details but my issue was probably 'how does userspace indicate to
> > the kernel that this memory being offlined should be removed'?
> 
> Instead of indicating a "size", indicate the offline memory blocks
> that
> the driver should use. E.g. by memory block id for each node
> 
> 0:20-24,1:30-32
> 
> Of course, other interfaces might make sense.
> 
> You can then start using these memory blocks and hinder them from
> getting onlined (as a safety net) via memory notifiers.
> 
> That would at least avoid you having to call
> add_memory/remove_memory/offline_pages/device_online/modifying
> memblock
> states manually.

I see what you're saying and that definitely sounds safer.

We would still need to call remove_memory and add_memory from memtrace
as
just offlining memory doesn't remove it from the linear page tables
(if 
it's still in the page tables then hardware can prefetch it and if
hardware tracing is using it then the box checkstops).

> 
> (binding the memory block devices to a driver would be nicer, but the
> infrastructure is not really there yet - we have no such drivers in
> place yet)
> 
> > I don't know the mm code nor how the notifiers work very well so I
> > can't quite see how the above would work. I'm assuming memtrace
> > would
> > register a hotplug notifier and when memory is offlined from
> > userspace,
> > the callback func in memtrace would be called if the priority was
> > high
> > enough? But how do we know that the memory being offlined is
> > intended
> > for usto touch? Is there a way to offline memory from userspace not
> > using sysfs or have I missed something in the sysfs interface?
> 
> The notifier would really only be used to hinder onlining as a safety
> net. User space prepares (offlines) the memory blocks and then tells
> the
> drivers which memory blocks to use.
> 
> > On a second read, perhaps you are assuming that memtrace is used
> > after
> > adding new memory at runtime? If so, that is not the case. If not,
> > then
> > would you be able to clarify what I'm not seeing?
> 
> The main problem I see is that you are calling
> add_memory/remove_memory() on memory your device driver doesn't own.
> It
> could reside on a DIMM if I am not mistaking (or later on
> paravirtualized memory devices like virtio-mem if I ever get to
> implement them ;) ).

This is just for baremetal/powernv so shouldn't affect virtual memory
devices.

> 
> How is it guaranteed that the memory you are allocating does not
> reside
> on a DIMM for example added via add_memory() by the ACPI driver?

Good point. We don't have ACPI on powernv but currently this would try
to remove memory from any online memory node, not just the ones that
are backed by RAM. oops.




RE: [EXT] Re: [PATCH] mailbox: imx: add support for imx v1 mu

2019-07-28 Thread Richard Zhu


> -Original Message-
> From: Dong Aisheng 
> Sent: 2019年7月29日 11:11
> To: Richard Zhu 
> Cc: jassisinghb...@gmail.com; Oleksij Rempel ;
> Aisheng Dong ; open list
> ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE 
> Subject: Re: [EXT] Re: [PATCH] mailbox: imx: add support for imx v1 mu
> 
> Caution: EXT Email
> 
> On Mon, Jul 29, 2019 at 11:03 AM Richard Zhu 
> wrote:
> >
> > Hi Aisheng:
> > Thanks for your comments.
> >
> > > -Original Message-
> > > From: Dong Aisheng 
> > > Sent: 2019年7月29日 10:35
> > > To: Richard Zhu 
> > > Cc: jassisinghb...@gmail.com; Oleksij Rempel
> > > ; Aisheng Dong ;
> open
> > > list ; moderated list:ARM/FREESCALE
> > > IMX / MXC ARM ARCHITECTURE 
> > > Subject: [EXT] Re: [PATCH] mailbox: imx: add support for imx v1 mu
> > >
> > > On Mon, Jul 29, 2019 at 10:36 AM Richard Zhu 
> > > wrote:
> > > >
> > > > There is a version1.0 MU on i.MX7ULP platform.
> > > > One new version ID register is added, and it's offset is 0.
> > > > TRn registers are defined at the offset 0x20 ~ 0x2C.
> > > > RRn registers are defined at the offset 0x40 ~ 0x4C.
> > > > SR/CR registers are defined at 0x60/0x64.
> > > > Extend this driver to support it.
> > > >
> > >
> > > If only the register base offset is different, there's probably a more 
> > > simple
> way.
> > > Please refer to:
> > >
> > [Richard Zhu] TRx, RRx and the CR/SR have the different offset addresses.
> > That means three different offset addresses should be manipulated if the
> solution listed above is used.
> > It seems that it's a little complex, and maybe introduce bugs when different
> offset address is manipulated.
> > According, the current method suggested by Oleksij is much clear, and easy 
> > to
> extend for future extension.
> >
> 
> I missed that.
> Maybe the patch title should be V2 and add Suggested-by: tag to reminder
> reviewer it's a new version?
> 
> If there're multiple offset differences. I'm fine with this way.
> Feel free to add my tag.
> Reviewed-by: Dong Aisheng 

[Richard Zhu] Thanks. Okay, understand.
Would resend it after change the commit.

> 
> Regards
> Aisheng
> 
> > Hi Olekiji:
> > How do you think about?
> >
> > Best Regards
> > Richard Zhu
> >
> > > Regards
> > > Aisheng
> > >
> > > > Signed-off-by: Richard Zhu 
> > > > ---
> > > >  drivers/mailbox/imx-mailbox.c | 67
> > > > ---
> > > >  1 file changed, 50 insertions(+), 17 deletions(-)
> > > >
> > > > diff --git a/drivers/mailbox/imx-mailbox.c
> > > > b/drivers/mailbox/imx-mailbox.c index 25be8bb..8423a38 100644
> > > > --- a/drivers/mailbox/imx-mailbox.c
> > > > +++ b/drivers/mailbox/imx-mailbox.c
> > > > @@ -12,19 +12,11 @@
> > > >  #include 
> > > >  #include 
> > > >
> > > > -/* Transmit Register */
> > > > -#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> > > > -/* Receive Register */
> > > > -#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> > > > -/* Status Register */
> > > > -#define IMX_MU_xSR 0x20
> > > >  #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
> > > >  #define IMX_MU_xSR_RFn(x)  BIT(24 + (3 - (x)))
> > > >  #define IMX_MU_xSR_TEn(x)  BIT(20 + (3 - (x)))
> > > >  #define IMX_MU_xSR_BRDIP   BIT(9)
> > > >
> > > > -/* Control Register */
> > > > -#define IMX_MU_xCR 0x24
> > > >  /* General Purpose Interrupt Enable */
> > > >  #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
> > > >  /* Receive Interrupt Enable */
> > > > @@ -44,6 +36,13 @@ enum imx_mu_chan_type {
> > > > IMX_MU_TYPE_RXDB,   /* Rx doorbell */
> > > >  };
> > > >
> > > > +struct imx_mu_dcfg {
> > > > +   u32 xTR[4]; /* Transmit Registers */
> > > > +   u32 xRR[4]; /* Receive Registers */
> > > > +   u32 xSR;/* Status Register */
> > > > +   u32 xCR;/* Control Register */
> > > > +};
> > > > +
> > > >  struct imx_mu_con_priv {
> > > > unsigned intidx;
> > > > char
> > > irq_desc[IMX_MU_CHAN_NAME_SIZE];
> > > > @@ -61,12 +60,39 @@ struct imx_mu_priv {
> > > > struct mbox_chanmbox_chans[IMX_MU_CHANS];
> > > >
> > > > struct imx_mu_con_priv  con_priv[IMX_MU_CHANS];
> > > > +   const struct imx_mu_dcfg*dcfg;
> > > > struct clk  *clk;
> > > > int irq;
> > > >
> > > > boolside_b;
> > > >  };
> > > >
> > > > +static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
> > > > +   .xTR[0] = 0x0,
> > > > +   .xTR[1] = 0x4,
> > > > +   .xTR[2] = 0x8,
> > > > +   .xTR[3] = 0xC,
> > > > +   .xRR[0] = 0x10,
> > > > +   .xRR[1] = 0x14,
> > > > +   .xRR[2] = 0x18,
> > > > +   .xRR[3] = 0x1C,
> > > > +   .xSR= 0x20,
> > > > +   .xCR= 0x24,
> > > > +};
> > > > +
> > > > +static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
> > > > +   .xTR[0] = 0x20,
> > > > +   .xTR[1] = 0x24,
> > > > +   .xTR[2] = 

Re: [PATCH] mmc: sdhci-s3c: Mark expected switch fall-through

2019-07-28 Thread Adrian Hunter
On 29/07/19 3:02 AM, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
> 
> This patch fixes the following warnings:
> 
> drivers/mmc/host/sdhci-s3c.c: In function 'sdhci_s3c_probe':
> drivers/mmc/host/sdhci-s3c.c:613:19: warning: this statement may fall through 
> [-Wimplicit-fallthrough=]
>host->mmc->caps |= MMC_CAP_8_BIT_DATA;
> drivers/mmc/host/sdhci-s3c.c:614:2: note: here
>   case 4:
>   ^~~~
> 
> Reported-by: Stephen Rothwell 
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Adrian Hunter 

> ---
>  drivers/mmc/host/sdhci-s3c.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
> index 8e4a8ba33f05..cefa0fb8cfde 100644
> --- a/drivers/mmc/host/sdhci-s3c.c
> +++ b/drivers/mmc/host/sdhci-s3c.c
> @@ -611,6 +611,7 @@ static int sdhci_s3c_probe(struct platform_device *pdev)
>   switch (pdata->max_width) {
>   case 8:
>   host->mmc->caps |= MMC_CAP_8_BIT_DATA;
> + /* Fall through */
>   case 4:
>   host->mmc->caps |= MMC_CAP_4_BIT_DATA;
>   break;
> 



RE: [BUG] infiniband: mlx5: a possible null-pointer dereference in set_roce_addr()

2019-07-28 Thread Parav Pandit


> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf Of Parav Pandit
> Sent: Monday, July 29, 2019 10:55 AM
> To: Jia-Ju Bai ; l...@kernel.org;
> dledf...@redhat.com; j...@ziepe.ca
> Cc: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: RE: [BUG] infiniband: mlx5: a possible null-pointer dereference in
> set_roce_addr()
> 
> Hi Jia,
> 
> > -Original Message-
> > From: linux-rdma-ow...@vger.kernel.org  > ow...@vger.kernel.org> On Behalf Of Jia-Ju Bai
> > Sent: Monday, July 29, 2019 7:47 AM
> > To: l...@kernel.org; dledf...@redhat.com; j...@ziepe.ca
> > Cc: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: [BUG] infiniband: mlx5: a possible null-pointer dereference
> > in
> > set_roce_addr()
> >
> > In set_roce_addr(), there is an if statement on line 589 to check
> > whether gid is
> > NULL:
> >      if (gid)
> >
> > When gid is NULL, it is used on line 613:
> >      return mlx5_core_roce_gid_set(..., gid->raw, ...);
> >
> > Thus, a possible null-pointer dereference may occur.
> >
> > This bug is found by a static analysis tool STCheck written by us.
> >
> While static checker is right, it is not a real bug, because gid->raw pointer
> points to GID entry itself so when GID is NULL, gid->raw is NULL too.
> 
> One way to suppress the static checker warning/error is below patch.
> Will let Leon review it.
> 
> > I do not know how to correctly fix this bug, so I only report it.
> >
> >
> > Best wishes,
> > Jia-Ju Bai
> 
> From 30e055dba77e595bf88aebd3a9c75ed76bc9c65a Mon Sep 17 00:00:00
> 2001
> From: Parav Pandit 
> Date: Mon, 29 Jul 2019 00:13:21 -0500
> Subject: [PATCH] IB/mlx5: Avoid static checker warning for NULL access
> 
> union ib_gid *gid and gid->raw pointers refers to the same address.
> However some static checker reports this as possible NULL access warning in
> call to mlx5_core_roce_gid_set().
> 
> To suppress such warning, instead of working on raw GID element, expose API
> using union ib_gid*.
> 
> Reported-by: Jia-Ju Bai 
> Signed-off-by: Parav Pandit 
> ---
>  drivers/infiniband/hw/mlx5/main.c   |  2 +-
>  drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c | 12 +++-
>  drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c   |  5 +++--
>  drivers/net/ethernet/mellanox/mlx5/core/rdma.c  |  2 +-
>  include/linux/mlx5/driver.h |  4 +++-
>  5 files changed, 15 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/infiniband/hw/mlx5/main.c
> b/drivers/infiniband/hw/mlx5/main.c
> index c2a5780cb394..e60785bad7ef 100644
> --- a/drivers/infiniband/hw/mlx5/main.c
> +++ b/drivers/infiniband/hw/mlx5/main.c
> @@ -610,7 +610,7 @@ static int set_roce_addr(struct mlx5_ib_dev *dev, u8
> port_num,
>   }
> 
>   return mlx5_core_roce_gid_set(dev->mdev, index, roce_version,
> -   roce_l3_type, gid->raw, mac,
> +   roce_l3_type, , mac,
> vlan_id < VLAN_CFI_MASK, vlan_id,
> port_num);
>  }
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
> b/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
> index 4c50efe4e7f1..76b8236af9c7 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
> @@ -850,6 +850,7 @@ struct mlx5_fpga_conn *mlx5_fpga_conn_create(struct
> mlx5_fpga_device *fdev,
>enum mlx5_ifc_fpga_qp_type
> qp_type)  {
>   struct mlx5_fpga_conn *ret, *conn;
> + struct ib_gid remote_gid = {};
>   u8 *remote_mac, *remote_ip;
>   int err;
> 
> @@ -876,11 +877,12 @@ struct mlx5_fpga_conn
> *mlx5_fpga_conn_create(struct mlx5_fpga_device *fdev,
>   goto err;
>   }
> 
> - /* Build Modified EUI-64 IPv6 address from the MAC address */
>   remote_ip = MLX5_ADDR_OF(fpga_qpc, conn->fpga_qpc, remote_ip);
> - remote_ip[0] = 0xfe;
> - remote_ip[1] = 0x80;
> - addrconf_addr_eui48(_ip[8], remote_mac);
> + memcpy(remote_gid.raw[0], remote_ip, sizeof(remote_gid.raw));
> + /* Build Modified EUI-64 IPv6 address from the MAC address */
> + remte_gid.raw[0] = 0xfe;
> + remte_gid.raw[1] = 0x80;
> + addrconf_addr_eui48(_gid.raw[8], remote_mac);
> 
>   err = mlx5_core_reserved_gid_alloc(fdev->mdev, 
> >qp.sgid_index);
>   if (err) {
> @@ -892,7 +894,7 @@ struct mlx5_fpga_conn *mlx5_fpga_conn_create(struct
> mlx5_fpga_device *fdev,
>   err = mlx5_core_roce_gid_set(fdev->mdev, conn->qp.sgid_index,
>MLX5_ROCE_VERSION_2,
>MLX5_ROCE_L3_TYPE_IPV6,
> -  remote_ip, remote_mac, true, 0,
> +  _gid, remote_mac, true, 0,
>MLX5_FPGA_PORT_NUM);
>   if (err) {
>  

RE: [BUG] infiniband: mlx5: a possible null-pointer dereference in set_roce_addr()

2019-07-28 Thread Parav Pandit
Hi Jia,

> -Original Message-
> From: linux-rdma-ow...@vger.kernel.org  ow...@vger.kernel.org> On Behalf Of Jia-Ju Bai
> Sent: Monday, July 29, 2019 7:47 AM
> To: l...@kernel.org; dledf...@redhat.com; j...@ziepe.ca
> Cc: linux-r...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [BUG] infiniband: mlx5: a possible null-pointer dereference in
> set_roce_addr()
> 
> In set_roce_addr(), there is an if statement on line 589 to check whether gid 
> is
> NULL:
>      if (gid)
> 
> When gid is NULL, it is used on line 613:
>      return mlx5_core_roce_gid_set(..., gid->raw, ...);
> 
> Thus, a possible null-pointer dereference may occur.
> 
> This bug is found by a static analysis tool STCheck written by us.
> 
While static checker is right, it is not a real bug, because gid->raw pointer 
points to GID entry itself so when GID is NULL, gid->raw is NULL too.

One way to suppress the static checker warning/error is below patch.
Will let Leon review it.

> I do not know how to correctly fix this bug, so I only report it.
> 
> 
> Best wishes,
> Jia-Ju Bai

From 30e055dba77e595bf88aebd3a9c75ed76bc9c65a Mon Sep 17 00:00:00 2001
From: Parav Pandit 
Date: Mon, 29 Jul 2019 00:13:21 -0500
Subject: [PATCH] IB/mlx5: Avoid static checker warning for NULL access

union ib_gid *gid and gid->raw pointers refers to the same address.
However some static checker reports this as possible NULL access
warning in call to mlx5_core_roce_gid_set().

To suppress such warning, instead of working on raw GID element,
expose API using union ib_gid*.

Reported-by: Jia-Ju Bai 
Signed-off-by: Parav Pandit 
---
 drivers/infiniband/hw/mlx5/main.c   |  2 +-
 drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c | 12 +++-
 drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c   |  5 +++--
 drivers/net/ethernet/mellanox/mlx5/core/rdma.c  |  2 +-
 include/linux/mlx5/driver.h |  4 +++-
 5 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/drivers/infiniband/hw/mlx5/main.c 
b/drivers/infiniband/hw/mlx5/main.c
index c2a5780cb394..e60785bad7ef 100644
--- a/drivers/infiniband/hw/mlx5/main.c
+++ b/drivers/infiniband/hw/mlx5/main.c
@@ -610,7 +610,7 @@ static int set_roce_addr(struct mlx5_ib_dev *dev, u8 
port_num,
}
 
return mlx5_core_roce_gid_set(dev->mdev, index, roce_version,
- roce_l3_type, gid->raw, mac,
+ roce_l3_type, , mac,
  vlan_id < VLAN_CFI_MASK, vlan_id,
  port_num);
 }
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c 
b/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
index 4c50efe4e7f1..76b8236af9c7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/fpga/conn.c
@@ -850,6 +850,7 @@ struct mlx5_fpga_conn *mlx5_fpga_conn_create(struct 
mlx5_fpga_device *fdev,
 enum mlx5_ifc_fpga_qp_type qp_type)
 {
struct mlx5_fpga_conn *ret, *conn;
+   struct ib_gid remote_gid = {};
u8 *remote_mac, *remote_ip;
int err;
 
@@ -876,11 +877,12 @@ struct mlx5_fpga_conn *mlx5_fpga_conn_create(struct 
mlx5_fpga_device *fdev,
goto err;
}
 
-   /* Build Modified EUI-64 IPv6 address from the MAC address */
remote_ip = MLX5_ADDR_OF(fpga_qpc, conn->fpga_qpc, remote_ip);
-   remote_ip[0] = 0xfe;
-   remote_ip[1] = 0x80;
-   addrconf_addr_eui48(_ip[8], remote_mac);
+   memcpy(remote_gid.raw[0], remote_ip, sizeof(remote_gid.raw));
+   /* Build Modified EUI-64 IPv6 address from the MAC address */
+   remte_gid.raw[0] = 0xfe;
+   remte_gid.raw[1] = 0x80;
+   addrconf_addr_eui48(_gid.raw[8], remote_mac);
 
err = mlx5_core_reserved_gid_alloc(fdev->mdev, >qp.sgid_index);
if (err) {
@@ -892,7 +894,7 @@ struct mlx5_fpga_conn *mlx5_fpga_conn_create(struct 
mlx5_fpga_device *fdev,
err = mlx5_core_roce_gid_set(fdev->mdev, conn->qp.sgid_index,
 MLX5_ROCE_VERSION_2,
 MLX5_ROCE_L3_TYPE_IPV6,
-remote_ip, remote_mac, true, 0,
+_gid, remote_mac, true, 0,
 MLX5_FPGA_PORT_NUM);
if (err) {
mlx5_fpga_err(fdev, "Failed to set SGID: %d\n", err);
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c 
b/drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c
index 7722a3f9bb68..9b8563a2bd50 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/gid.c
@@ -120,7 +120,8 @@ unsigned int mlx5_core_reserved_gids_count(struct 
mlx5_core_dev *dev)
 EXPORT_SYMBOL_GPL(mlx5_core_reserved_gids_count);
 
 int mlx5_core_roce_gid_set(struct mlx5_core_dev *dev, unsigned int index,
-   

Re: [BUG] infiniband: mlx5: a possible null-pointer dereference in set_roce_addr()

2019-07-28 Thread Leon Romanovsky
On Mon, Jul 29, 2019 at 10:16:30AM +0800, Jia-Ju Bai wrote:
> In set_roce_addr(), there is an if statement on line 589 to check whether
> gid is NULL:
>     if (gid)
>
> When gid is NULL, it is used on line 613:
>     return mlx5_core_roce_gid_set(..., gid->raw, ...);
>
> Thus, a possible null-pointer dereference may occur.
>
> This bug is found by a static analysis tool STCheck written by us.
>
> I do not know how to correctly fix this bug, so I only report it.

You should fix the tool, gid and gid->raw are the same pointers in C.

In this case, "mlx5_core_roce_gid_set(..., gid->raw, ...);" will be
equal to "mlx5_core_roce_gid_set(..., NULL, ...);" and
mlx5_core_roce_gid_set() is designed to handle this case.

Thanks

>
>
> Best wishes,
> Jia-Ju Bai


I WANT YOU TO USE THIS DONATION TO HELP THE POOR URGENT.

2019-07-28 Thread Mrs Ivvone Davida Balakiwal
My Sincere Greetings,

I am  Mrs  Ivvone D Balakiwal, I decided to donate what I have to you for 
investment towards the good work of charity organization, and also to help the 
motherless and the less privileged ones and to carry out a charitable works in 
your Country and around the World on my Behalf.

I am diagnosing of throat Cancer, hospitalize for good 2 years and some months 
now and quite obvious that I have few days to live, and I am a Widow no child; 
I decided to will/donate the sum of $ 9.5 million to you for the good work of 
God, and also to help the motherless and less privilege and also forth 
assistance of the widows. At the moment I can not take any telephone calls 
right now due to the fact that my relatives (that have squandered the funds for 
this purpose before) are around me and my health status also. I have adjusted 
my will and my lawyer is aware.

I have willed those properties to you by quoting my Personal File Routing and 
Account Information. And I have also notified the bank that I am willing that 
properties to you for a good, effective and prudent work.

It is right to say that I have been directed to do this by God.

I will be going in for a surgery soon and I want to make sure that I make this 
donation before undergoing this surgery. I will need your support to make this 
dream come through, could you let me know your interest to enable me give you 
further information.And I hereby advice to contact me by this email address  ( 
mrslvvonebalakiwa...@citromail.hu )

Looking forward to hearing from you  soon,

Yours sincerely,
   
Mrs Ivvone D Balakiwal




Re: [PATCH] modpost: check for static EXPORT_SYMBOL* functions

2019-07-28 Thread Stephen Rothwell
Hi Denis,

On Sun, 28 Jul 2019 13:09:06 +0300 Denis Efremov  wrote:
>
> Thus, the current implementation adds approx. 1 min for allmodconfig.

Just a reminder that some of us (just me?) do well over 100+ builds per
day ...  if this can be optimised some what that would be good.

-- 
Cheers,
Stephen Rothwell


pgpGYpN0Yq7wP.pgp
Description: OpenPGP digital signature


[PATCH v2] MIPS: Kconfig: remove HAVE_LATENCYTOP_SUPPORT

2019-07-28 Thread Fabian Mewes
HAVE_LATENCYTOP_SUPPORT was removed all together in da48d094ce5d7
("Kconfig: remove HAVE_LATENCYTOP_SUPPORT"). This commit removes
a leftover in the MIPS Kconfig.

Signed-off-by: Fabian Mewes 
---
v1..v2: specify commit's summary enclosed in ("")

 arch/mips/Kconfig |4 
 1 file changed, 4 deletions(-)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index d50fafd..4958734 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -3069,10 +3069,6 @@ config STACKTRACE_SUPPORT
bool
default y
 
-config HAVE_LATENCYTOP_SUPPORT
-   bool
-   default y
-
 config PGTABLE_LEVELS
int
default 4 if PAGE_SIZE_4KB && MIPS_VA_BITS_48
-- 
2.11.0



linux-next: Tree for Jul 29

2019-07-28 Thread Stephen Rothwell
Hi all,

Changes since 20190726:

The sh tree gained a conflict against Linus' tree.

The tip tree gained a conflict against Linus' tree.

I remerged the kspp-gustavo tree later to get some warning fixes.

The akpm-current tree lost its build failure.

Non-merge commits (relative to Linus' tree): 2571
 2915 files changed, 181840 insertions(+), 73157 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 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 301 trees (counting Linus' and 72 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 (609488bc979f Linux 5.3-rc2)
Merging fixes/master (c309b6f24222 Merge tag 'docs/v5.3-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media)
Merging kbuild-current/fixes (b25e8a23d4ea kbuild: remove unused single-used-m)
Merging arc-current/for-curr (24a20b0a443f ARC: [plat-hsdk]: Enable AXI DW DMAC 
in defconfig)
Merging arm-current/fixes (c5d0e49e8d8f ARM: 8867/1: vdso: pass --be8 to linker 
if necessary)
Merging arm-soc-fixes/arm/fixes (7bd9d465140a Merge tag 'imx-fixes-5.3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes)
Merging arm64-fixes/for-next/fixes (5a46d3f71d5e ACPI/IORT: Fix off-by-one 
check in iort_dev_find_its_id())
Merging m68k-current/for-linus (f28a1f16135c m68k: Don't select 
ARCH_HAS_DMA_PREP_COHERENT for nommu or coldfire)
Merging powerpc-fixes/fixes (3a855b7ac7d5 powerpc/papr_scm: Force a scm-unbind 
if initial scm-bind fails)
Merging s390-fixes/fixes (98abe0227827 MAINTAINERS: vfio-ccw: Remove myself as 
the maintainer)
Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (003bd5b4a7b4 r8169: don't use MSI before RTL8168d)
Merging bpf/master (5d01ab7bac46 libbpf: fix erroneous multi-closing of BTF FD)
Merging ipsec/master (22d6552f827e xfrm interface: fix management of phydev)
Merging netfilter/master (67d86835840a netfilter: nft_meta_bridge: Eliminate 
'out' label)
Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes')
Merging wireless-drivers/master (5f9e832c1370 Linus 5.3-rc1)
Merging mac80211/master (e6f4051123fd {nl,mac}80211: fix interface combinations 
on crypto controlled devices)
Merging rdma-fixes/for-rc (b7165bd0d6cb IB/mlx5: Fix RSS Toeplitz setup to be 
aligned with the HW specification)
Merging sound-current/for-linus (74bf71ed792a ALSA: hda: Fix 1-minute detection 
delay when i915 module is not available)
Merging sound-asoc-fixes/for-linus (3a03327120de Merge branch 'asoc-5.3' into 
asoc-linus)
Merging regmap-fixes/for-linus (5f9e832c1370 Linus 5.3-rc1)
Merging regulator-fixes/for-linus (a853c0a0b013 regulator: lp87565: Fix probe 
failure for "ti,lp87565")
Merging spi-fixes/for-linus (d24f33303ad1 Merge branch 'spi-5.3' into spi-linus)
Merging pci-current/for-linus (5f9e832c1370 Linus 5.3-rc1)
Merging driver-core.current/driver-core-linus (5f9e832c1370 Linus 5.3-rc1)
Merging tty.current/tty-linus (61d51456f357 vt: Grab console_lock around 
con_is_bound in show_bind)
Merging usb.current/usb-linus (d39b5bad8658 xhci: Fix crash if scatter gather 
is used with Immediate Data Transfer (IDT).)
Merging usb-gadget-fixes/fixes (42de8afc40c9 usb: dwc2: Use generic PHY width 
in params setup)
Merging usb-serial-fixes/usb-linus 

Re: [PATCH v7] driver core: Fix use-after-free and double free on glue directory

2019-07-28 Thread Prateek Sood
On 7/27/19 8:51 AM, Muchun Song wrote:
> There is a race condition between removing glue directory and adding a new
> device under the glue dir. It can be reproduced in following test:
> 
> CPU1: CPU2:
> 
> device_add()
>   get_device_parent()
> class_dir_create_and_add()
>   kobject_add_internal()
> create_dir()// create glue_dir
> 
>   device_add()
> get_device_parent()
>   kobject_get() // get 
> glue_dir
> 
> device_del()
>   cleanup_glue_dir()
> kobject_del(glue_dir)
> 
> kobject_add()
>   kobject_add_internal()
> create_dir() // in 
> glue_dir
>   sysfs_create_dir_ns()
> 
> kernfs_create_dir_ns(sd)
> 
>   sysfs_remove_dir() // glue_dir->sd=NULL
>   sysfs_put()// free glue_dir->sd
> 
>   // sd is freed
>   kernfs_new_node(sd)
> 
> kernfs_get(glue_dir)
> kernfs_add_one()
> kernfs_put()
> 
> Before CPU1 remove last child device under glue dir, if CPU2 add a new
> device under glue dir, the glue_dir kobject reference count will be
> increase to 2 via kobject_get() in get_device_parent(). And CPU2 has
> been called kernfs_create_dir_ns(), but not call kernfs_new_node().
> Meanwhile, CPU1 call sysfs_remove_dir() and sysfs_put(). This result in
> glue_dir->sd is freed and it's reference count will be 0. Then CPU2 call
> kernfs_get(glue_dir) will trigger a warning in kernfs_get() and increase
> it's reference count to 1. Because glue_dir->sd is freed by CPU1, the next
> call kernfs_add_one() by CPU2 will fail(This is also use-after-free)
> and call kernfs_put() to decrease reference count. Because the reference
> count is decremented to 0, it will also call kmem_cache_free() to free
> the glue_dir->sd again. This will result in double free.
> 
> In order to avoid this happening, we also should make sure that kernfs_node
> for glue_dir is released in CPU1 only when refcount for glue_dir kobj is
> 1 to fix this race.
> 
> The following calltrace is captured in kernel 4.14 with the following patch
> applied:
> 
> commit 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
> 
> --
> [3.633703] WARNING: CPU: 4 PID: 513 at .../fs/kernfs/dir.c:494
> Here is WARN_ON(!atomic_read(>count) in kernfs_get().
> 
> [3.633986] Call trace:
> [3.633991]  kernfs_create_dir_ns+0xa8/0xb0
> [3.633994]  sysfs_create_dir_ns+0x54/0xe8
> [3.634001]  kobject_add_internal+0x22c/0x3f0
> [3.634005]  kobject_add+0xe4/0x118
> [3.634011]  device_add+0x200/0x870
> [3.634017]  _request_firmware+0x958/0xc38
> [3.634020]  request_firmware_into_buf+0x4c/0x70
> 
> [3.634064] kernel BUG at .../mm/slub.c:294!
> Here is BUG_ON(object == fp) in set_freepointer().
> 
> [3.634346] Call trace:
> [3.634351]  kmem_cache_free+0x504/0x6b8
> [3.634355]  kernfs_put+0x14c/0x1d8
> [3.634359]  kernfs_create_dir_ns+0x88/0xb0
> [3.634362]  sysfs_create_dir_ns+0x54/0xe8
> [3.634366]  kobject_add_internal+0x22c/0x3f0
> [3.634370]  kobject_add+0xe4/0x118
> [3.634374]  device_add+0x200/0x870
> [3.634378]  _request_firmware+0x958/0xc38
> [3.634381]  request_firmware_into_buf+0x4c/0x70
> --
> 
> Fixes: 726e41097920 ("drivers: core: Remove glue dirs from sysfs earlier")
> 
> Signed-off-by: Muchun Song 
> Reviewed-by: Mukesh Ojha 
> ---
> 
> Change in v7:
>1. Update commit message.
> Change in v6:
>1. Remove hardcoding "1 "
> Change in v5:
>1. Revert to the v1 fix.
>2. Add some comment to explain why we need do this in
>   cleanup_glue_dir().
> Change in v4:
>1. Add some kerneldoc comment.
>2. Remove unlock_if_glue_dir().
>3. Rename get_device_parent_locked_if_glue_dir() to
>   get_device_parent_locked.
>4. Update commit message.
> Change in v3:
>Add change log.
> Change in v2:
>Fix device_move() also.
> 
>  drivers/base/core.c | 53 -
>  1 file changed, 52 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 4aeaa0c92bda..edc55160c5f0 100644
> --- 

[PATCH -tip] locking/rwsem: Check for operations on an uninitialized rwsem

2019-07-28 Thread Davidlohr Bueso
Currently rwsems is the only locking primitive that lacks this
debug feature. Add it under CONFIG_DEBUG_RWSEMS and do the magic
checking in the locking fastpath (trylock) operation such that
we cover all cases. The unlocking part is pretty straightforward.

Signed-off-by: Davidlohr Bueso 
---
 include/linux/rwsem.h  | 10 ++
 kernel/locking/rwsem.c | 22 ++
 2 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 9d9c663987d8..00d6054687dd 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -45,6 +45,9 @@ struct rw_semaphore {
 #endif
raw_spinlock_t wait_lock;
struct list_head wait_list;
+#ifdef CONFIG_DEBUG_RWSEMS
+   void *magic;
+#endif
 #ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map  dep_map;
 #endif
@@ -73,6 +76,12 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
 # define __RWSEM_DEP_MAP_INIT(lockname)
 #endif
 
+#ifdef CONFIG_DEBUG_RWSEMS
+# define __DEBUG_RWSEM_INITIALIZER(lockname) , .magic = 
+#else
+# define __DEBUG_RWSEM_INITIALIZER(lockname)
+#endif
+
 #ifdef CONFIG_RWSEM_SPIN_ON_OWNER
 #define __RWSEM_OPT_INIT(lockname) , .osq = OSQ_LOCK_UNLOCKED
 #else
@@ -85,6 +94,7 @@ static inline int rwsem_is_locked(struct rw_semaphore *sem)
  .wait_list = LIST_HEAD_INIT((name).wait_list),\
  .wait_lock = __RAW_SPIN_LOCK_UNLOCKED(name.wait_lock) \
  __RWSEM_OPT_INIT(name)\
+ __DEBUG_RWSEM_INITIALIZER(name)   \
  __RWSEM_DEP_MAP_INIT(name) }
 
 #define DECLARE_RWSEM(name) \
diff --git a/kernel/locking/rwsem.c b/kernel/locking/rwsem.c
index 37524a47f002..ab392ec51252 100644
--- a/kernel/locking/rwsem.c
+++ b/kernel/locking/rwsem.c
@@ -105,8 +105,9 @@
 #ifdef CONFIG_DEBUG_RWSEMS
 # define DEBUG_RWSEMS_WARN_ON(c, sem)  do {\
if (!debug_locks_silent &&  \
-   WARN_ONCE(c, "DEBUG_RWSEMS_WARN_ON(%s): count = 0x%lx, owner = 
0x%lx, curr 0x%lx, list %sempty\n",\
+   WARN_ONCE(c, "DEBUG_RWSEMS_WARN_ON(%s): count = 0x%lx, magic = 
0x%lx, owner = 0x%lx, curr 0x%lx, list %sempty\n",\
#c, atomic_long_read(&(sem)->count),\
+   (unsigned long) sem->magic, \
atomic_long_read(&(sem)->owner), (long)current, \
list_empty(&(sem)->wait_list) ? "" : "not "))   \
debug_locks_off();  \
@@ -329,6 +330,9 @@ void __init_rwsem(struct rw_semaphore *sem, const char 
*name,
 */
debug_check_no_locks_freed((void *)sem, sizeof(*sem));
lockdep_init_map(>dep_map, name, key, 0);
+#endif
+#ifdef CONFIG_DEBUG_RWSEMS
+   sem->magic = sem;
 #endif
atomic_long_set(>count, RWSEM_UNLOCKED_VALUE);
raw_spin_lock_init(>wait_lock);
@@ -1322,11 +1326,14 @@ static inline int __down_read_killable(struct 
rw_semaphore *sem)
 
 static inline int __down_read_trylock(struct rw_semaphore *sem)
 {
+   long tmp;
+
+   DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem);
+
/*
 * Optimize for the case when the rwsem is not locked at all.
 */
-   long tmp = RWSEM_UNLOCKED_VALUE;
-
+   tmp = RWSEM_UNLOCKED_VALUE;
do {
if (atomic_long_try_cmpxchg_acquire(>count, ,
tmp + RWSEM_READER_BIAS)) {
@@ -1367,8 +1374,11 @@ static inline int __down_write_killable(struct 
rw_semaphore *sem)
 
 static inline int __down_write_trylock(struct rw_semaphore *sem)
 {
-   long tmp = RWSEM_UNLOCKED_VALUE;
+   long tmp;
 
+   DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem);
+
+   tmp  = RWSEM_UNLOCKED_VALUE;
if (atomic_long_try_cmpxchg_acquire(>count, ,
RWSEM_WRITER_LOCKED)) {
rwsem_set_owner(sem);
@@ -1384,7 +1394,9 @@ inline void __up_read(struct rw_semaphore *sem)
 {
long tmp;
 
+   DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem);
DEBUG_RWSEMS_WARN_ON(!is_rwsem_reader_owned(sem), sem);
+
rwsem_clear_reader_owned(sem);
tmp = atomic_long_add_return_release(-RWSEM_READER_BIAS, >count);
DEBUG_RWSEMS_WARN_ON(tmp < 0, sem);
@@ -1402,12 +1414,14 @@ static inline void __up_write(struct rw_semaphore *sem)
 {
long tmp;
 
+   DEBUG_RWSEMS_WARN_ON(sem->magic != sem, sem);
/*
 * sem->owner may differ from current if the ownership is transferred
 * to an anonymous writer by setting the RWSEM_NONSPINNABLE bits.
 */
DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) &&
!rwsem_test_oflags(sem, RWSEM_NONSPINNABLE), sem);
+
rwsem_clear_owner(sem);
tmp = atomic_long_fetch_add_release(-RWSEM_WRITER_LOCKED, >count);
if (unlikely(tmp & RWSEM_FLAG_WAITERS))
-- 
2.16.4



Re: build error

2019-07-28 Thread Bhaskar Chowdhury


Matteo,

it's look like gcc is not in your normal PATH. Could you please locate
that fellow and realign it ,where is suppose to be.

Or if I understood right (I doubt that is why asking) that you might put
explicitly the architecture to target build with make also, that might
help.

Please do let me know, if I derailed grossly ...am not sure.. :)

Thanks,
Bhaskar

On 22:08 Sun 28 Jul 2019, Matteo Croce wrote:

Hi,

I get this build error with 5.3-rc2"

# make
arch/arm64/Makefile:58: gcc not found, check CROSS_COMPILE_COMPAT.  Stop.

I didn't bisect the tree, but I guess that this kconfig can be related

# grep CROSS_COMPILE_COMPAT .config
CONFIG_CROSS_COMPILE_COMPAT_VDSO=""

Does someone have any idea? Am I missing something?

Thanks,
--
Matteo Croce
per aspera ad upstream


signature.asc
Description: PGP signature


[PATCH 1/4] dt-bindings: net: Add aspeed,ast2600-mdio binding

2019-07-28 Thread Andrew Jeffery
The AST2600 splits out the MDIO bus controller from the MAC into its own
IP block and rearranges the register layout. Add a new binding to
describe the new hardware.

Signed-off-by: Andrew Jeffery 
---
 .../bindings/net/aspeed,ast2600-mdio.yaml | 61 +++
 1 file changed, 61 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml

diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml 
b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
new file mode 100644
index ..fa86f6438473
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
@@ -0,0 +1,61 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/aspeed,ast2600-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 MDIO Controller
+
+maintainers:
+  - Andrew Jeffery 
+
+description: |+
+  The ASPEED AST2600 MDIO controller is the third iteration of ASPEED's MDIO
+  bus register interface, this time also separating out the controller from the
+  MAC.
+
+properties:
+  compatible:
+const: aspeed,ast2600-mdio
+  reg:
+maxItems: 1
+description: The register range of the MDIO controller instance
+  "#address-cells":
+const: 1
+  "#size-cells":
+const: 0
+
+patternProperties:
+  "^ethernet-phy@[a-f0-9]$":
+properties:
+  reg:
+description:
+  The MDIO bus index of the PHY
+  compatible:
+enum:
+  - ethernet-phy-ieee802.3-c22
+  - ethernet-phy-ieee802.3-c45
+required:
+  - reg
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+
+examples:
+  - |
+mdio0: mdio@1e65 {
+compatible = "aspeed,ast2600-mdio";
+reg = <0x1e65 0x8>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+status = "okay";
+
+ethphy0: ethernet-phy@0 {
+compatible = "ethernet-phy-ieee802.3-c22";
+reg = <0>;
+};
+};
-- 
2.20.1



[PATCH 4/4] net: ftgmac100: Select ASPEED MDIO driver for the AST2600

2019-07-28 Thread Andrew Jeffery
Ensures we can talk to a PHY via MDIO on the AST2600, as the MDIO
controller is now separate from the MAC.

Signed-off-by: Andrew Jeffery 
---
 drivers/net/ethernet/faraday/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/faraday/Kconfig 
b/drivers/net/ethernet/faraday/Kconfig
index a9b105803fb7..73e4f2648e49 100644
--- a/drivers/net/ethernet/faraday/Kconfig
+++ b/drivers/net/ethernet/faraday/Kconfig
@@ -32,6 +32,7 @@ config FTGMAC100
depends on ARM || NDS32 || COMPILE_TEST
depends on !64BIT || BROKEN
select PHYLIB
+   select MDIO_ASPEED if MACH_ASPEED_G6
---help---
  This driver supports the FTGMAC100 Gigabit Ethernet controller
  from Faraday. It is used on Faraday A369, Andes AG102 and some
-- 
2.20.1



[PATCH 2/4] net: phy: Add mdio-aspeed

2019-07-28 Thread Andrew Jeffery
The AST2600 design separates the MDIO controllers from the MAC, which is
where they were placed in the AST2400 and AST2500. Further, the register
interface is reworked again, so now we have three possible different
interface implementations, however this driver only supports the
interface provided by the AST2600. The AST2400 and AST2500 will continue
to be supported by the MDIO support embedded in the FTGMAC100 driver.

Signed-off-by: Andrew Jeffery 
---
 drivers/net/phy/Kconfig   |  13 +++
 drivers/net/phy/Makefile  |   1 +
 drivers/net/phy/mdio-aspeed.c | 159 ++
 3 files changed, 173 insertions(+)
 create mode 100644 drivers/net/phy/mdio-aspeed.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 20f14c5fbb7e..206d8650ee7f 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -21,6 +21,19 @@ config MDIO_BUS
 
 if MDIO_BUS
 
+config MDIO_ASPEED
+   tristate "ASPEED MDIO bus controller"
+   depends on ARCH_ASPEED || COMPILE_TEST
+   depends on OF_MDIO && HAS_IOMEM
+   help
+ This module provides a driver for the independent MDIO bus
+ controllers found in the ASPEED AST2600 SoC. This is a driver for the
+ third revision of the ASPEED MDIO register interface - the first two
+ revisions are the "old" and "new" interfaces found in the AST2400 and
+ AST2500, embedded in the MAC. For legacy reasons, FTGMAC100 driver
+ continues to drive the embedded MDIO controller for the AST2400 and
+ AST2500 SoCs, so say N if AST2600 support is not required.
+
 config MDIO_BCM_IPROC
tristate "Broadcom iProc MDIO bus controller"
depends on ARCH_BCM_IPROC || COMPILE_TEST
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 839acb292c38..ba07c27e4208 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -22,6 +22,7 @@ libphy-$(CONFIG_LED_TRIGGER_PHY)  += phy_led_triggers.o
 obj-$(CONFIG_PHYLINK)  += phylink.o
 obj-$(CONFIG_PHYLIB)   += libphy.o
 
+obj-$(CONFIG_MDIO_ASPEED)  += mdio-aspeed.o
 obj-$(CONFIG_MDIO_BCM_IPROC)   += mdio-bcm-iproc.o
 obj-$(CONFIG_MDIO_BCM_UNIMAC)  += mdio-bcm-unimac.o
 obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
diff --git a/drivers/net/phy/mdio-aspeed.c b/drivers/net/phy/mdio-aspeed.c
new file mode 100644
index ..71496a9ff54a
--- /dev/null
+++ b/drivers/net/phy/mdio-aspeed.c
@@ -0,0 +1,159 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright (C) 2019 IBM Corp. */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "mdio-aspeed"
+
+#define ASPEED_MDIO_CTRL   0x0
+#define   ASPEED_MDIO_CTRL_FIREBIT(31)
+#define   ASPEED_MDIO_CTRL_ST  BIT(28)
+#define ASPEED_MDIO_CTRL_ST_C450
+#define ASPEED_MDIO_CTRL_ST_C221
+#define   ASPEED_MDIO_CTRL_OP  GENMASK(27, 26)
+#define MDIO_C22_OP_WRITE  0b01
+#define MDIO_C22_OP_READ   0b10
+#define   ASPEED_MDIO_CTRL_PHYAD   GENMASK(25, 21)
+#define   ASPEED_MDIO_CTRL_REGAD   GENMASK(20, 16)
+#define   ASPEED_MDIO_CTRL_MIIWDATAGENMASK(15, 0)
+
+#define ASPEED_MDIO_DATA   0x4
+#define   ASPEED_MDIO_DATA_MDC_THRES   GENMASK(31, 24)
+#define   ASPEED_MDIO_DATA_MDIO_EDGE   BIT(23)
+#define   ASPEED_MDIO_DATA_MDIO_LATCH  GENMASK(22, 20)
+#define   ASPEED_MDIO_DATA_IDLEBIT(16)
+#define   ASPEED_MDIO_DATA_MIIRDATAGENMASK(15, 0)
+
+#define ASPEED_MDIO_RETRIES10
+
+struct aspeed_mdio {
+   void __iomem *base;
+};
+
+static int aspeed_mdio_read(struct mii_bus *bus, int addr, int regnum)
+{
+   struct aspeed_mdio *ctx = bus->priv;
+   u32 ctrl;
+   int i;
+
+   dev_dbg(>dev, "%s: addr: %d, regnum: %d\n", __func__, addr,
+   regnum);
+
+   /* Just clause 22 for the moment */
+   ctrl = ASPEED_MDIO_CTRL_FIRE
+   | FIELD_PREP(ASPEED_MDIO_CTRL_ST, ASPEED_MDIO_CTRL_ST_C22)
+   | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_READ)
+   | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
+   | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, regnum);
+
+   iowrite32(ctrl, ctx->base + ASPEED_MDIO_CTRL);
+
+   for (i = 0; i < ASPEED_MDIO_RETRIES; i++) {
+   u32 data;
+
+   data = ioread32(ctx->base + ASPEED_MDIO_DATA);
+   if (data & ASPEED_MDIO_DATA_IDLE)
+   return FIELD_GET(ASPEED_MDIO_DATA_MIIRDATA, data);
+
+   udelay(100);
+   }
+
+   dev_err(>dev, "MDIO read failed\n");
+   return -EIO;
+}
+
+static int aspeed_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 
val)
+{
+   struct aspeed_mdio *ctx = bus->priv;
+   u32 ctrl;
+   int i;
+
+   dev_dbg(>dev, "%s: addr: %d, regnum: %d, val: 0x%x\n",
+   __func__, addr, regnum, val);
+
+   /* Just clause 22 for the 

[PATCH 3/4] net: ftgmac100: Add support for DT phy-handle property

2019-07-28 Thread Andrew Jeffery
phy-handle is necessary for the AST2600 which separates the MDIO
controllers from the MAC.

I've tried to minimise the intrusion of supporting the AST2600 to the
FTGMAC100 by leaving in place the existing MDIO support for the embedded
MDIO interface. The AST2400 and AST2500 continue to be supported this
way, as it avoids breaking/reworking existing devicetrees.

The AST2600 support by contrast requires the presence of the phy-handle
property in the MAC devicetree node to specify the appropriate PHY to
associate with the MAC. In the event that someone wants to specify the
MDIO bus topology under the MAC node on an AST2400 or AST2500, the
current auto-probe approach is done conditional on the absence of an
"mdio" child node of the MAC.

Signed-off-by: Andrew Jeffery 
---
 drivers/net/ethernet/faraday/ftgmac100.c | 37 +---
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c 
b/drivers/net/ethernet/faraday/ftgmac100.c
index 030fed65393e..563384b788ab 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1619,8 +1620,13 @@ static int ftgmac100_setup_mdio(struct net_device 
*netdev)
if (!priv->mii_bus)
return -EIO;
 
-   if (priv->is_aspeed) {
-   /* This driver supports the old MDIO interface */
+   if (of_device_is_compatible(np, "aspeed,ast2400-mac") ||
+   of_device_is_compatible(np, "aspeed,ast2500-mac")) {
+   /* The AST2600 has a separate MDIO controller */
+
+   /* For the AST2400 and AST2500 this driver only supports the
+* old MDIO interface
+*/
reg = ioread32(priv->base + FTGMAC100_OFFSET_REVR);
reg &= ~FTGMAC100_REVR_NEW_MDIO_INTERFACE;
iowrite32(reg, priv->base + FTGMAC100_OFFSET_REVR);
@@ -1797,7 +1803,8 @@ static int ftgmac100_probe(struct platform_device *pdev)
 
np = pdev->dev.of_node;
if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac") ||
-  of_device_is_compatible(np, "aspeed,ast2500-mac"))) {
+  of_device_is_compatible(np, "aspeed,ast2500-mac") ||
+  of_device_is_compatible(np, "aspeed,ast2600-mac"))) {
priv->rxdes0_edorr_mask = BIT(30);
priv->txdes0_edotr_mask = BIT(30);
priv->is_aspeed = true;
@@ -1817,7 +1824,29 @@ static int ftgmac100_probe(struct platform_device *pdev)
priv->ndev = ncsi_register_dev(netdev, ftgmac100_ncsi_handler);
if (!priv->ndev)
goto err_ncsi_dev;
-   } else {
+   } else if (np && of_get_property(np, "phy-handle", NULL)) {
+   struct phy_device *phy;
+
+   phy = of_phy_get_and_connect(priv->netdev, np,
+_adjust_link);
+   if (!phy) {
+   dev_err(>dev, "Failed to connect to phy\n");
+   goto err_setup_mdio;
+   }
+
+   /* Indicate that we support PAUSE frames (see comment in
+* Documentation/networking/phy.txt)
+*/
+   phy_support_asym_pause(phy);
+
+   /* Display what we found */
+   phy_attached_info(phy);
+   } else if (np && !of_get_child_by_name(np, "mdio")) {
+   /* Support legacy ASPEED devicetree descriptions that decribe a
+* MAC with an embedded MDIO controller but have no "mdio"
+* child node. Automatically scan the MDIO bus for available
+* PHYs.
+*/
priv->use_ncsi = false;
err = ftgmac100_setup_mdio(netdev);
if (err)
-- 
2.20.1



[PATCH 0/4] net: phy: Add AST2600 MDIO support

2019-07-28 Thread Andrew Jeffery
Hello,

This series adds support for the MDIO controllers found in the AST2600. In the
AST2500 and earlier the MDIO controller was embedded in the MAC; this has now
been separated out and the register interface rearranged (again).

Please review!

Andrew

Andrew Jeffery (4):
  dt-bindings: net: Add aspeed,ast2600-mdio binding
  net: phy: Add mdio-aspeed
  net: ftgmac100: Add support for DT phy-handle property
  net: ftgmac100: Select ASPEED MDIO driver for the AST2600

 .../bindings/net/aspeed,ast2600-mdio.yaml |  61 +++
 drivers/net/ethernet/faraday/Kconfig  |   1 +
 drivers/net/ethernet/faraday/ftgmac100.c  |  37 +++-
 drivers/net/phy/Kconfig   |  13 ++
 drivers/net/phy/Makefile  |   1 +
 drivers/net/phy/mdio-aspeed.c | 159 ++
 6 files changed, 268 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
 create mode 100644 drivers/net/phy/mdio-aspeed.c

-- 
2.20.1



Re: [PATCH] tracing: Prevent RCU EQS breakage in preemptirq events

2019-07-28 Thread Andy Lutomirski
On Sun, Jul 28, 2019 at 6:08 PM Eiichi Tsukata  wrote:
>
> If context tracking is enabled, causing page fault in preemptirq
> irq_enable or irq_disable events triggers the following RCU EQS warning.
>

Yuck.

> diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
> index be01a4d627c9..860eaf9780e5 100644
> --- a/kernel/context_tracking.c
> +++ b/kernel/context_tracking.c
> @@ -148,6 +148,11 @@ void __context_tracking_exit(enum ctx_state state)
> return;
>
> if (__this_cpu_read(context_tracking.state) == state) {
> +   /*
> +* Change state before executing codes which can trigger
> +* page fault leading unnecessary re-entrance.
> +*/
> +   __this_cpu_write(context_tracking.state, CONTEXT_KERNEL);

Seems reasonable.

> if (__this_cpu_read(context_tracking.active)) {
> /*
>  * We are going to run code that may use RCU. Inform
> @@ -159,7 +164,6 @@ void __context_tracking_exit(enum ctx_state state)
> trace_user_exit(0);
> }
> }
> -   __this_cpu_write(context_tracking.state, CONTEXT_KERNEL);
> }
> context_tracking_recursion_exit();
>  }
> diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c
> index 4d8e99fdbbbe..031b51cb94d0 100644
> --- a/kernel/trace/trace_preemptirq.c
> +++ b/kernel/trace/trace_preemptirq.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "trace.h"
>
>  #define CREATE_TRACE_POINTS
> @@ -49,9 +50,14 @@ NOKPROBE_SYMBOL(trace_hardirqs_off);
>
>  __visible void trace_hardirqs_on_caller(unsigned long caller_addr)
>  {
> +   enum ctx_state prev_state;
> +
> if (this_cpu_read(tracing_irq_cpu)) {
> -   if (!in_nmi())
> +   if (!in_nmi()) {
> +   prev_state = exception_enter();
> trace_irq_enable_rcuidle(CALLER_ADDR0, caller_addr);
> +   exception_exit(prev_state);
> +   }
> tracer_hardirqs_on(CALLER_ADDR0, caller_addr);
> this_cpu_write(tracing_irq_cpu, 0);
> }

This seems a bit distressing.  Now we're going to do a whole bunch of
context tracking transitions for each kernel entry.  Would a better
fix me to change trace_hardirqs_on_caller to skip the trace event if
the previous state was already IRQs on and, more importantly, to skip
tracing IRQs off if IRQs were already off?  The x86 code is very
careful to avoid ever having IRQs on and CONTEXT_USER at the same
time.

--Andy


Re: [PATCH] fs: xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling()

2019-07-28 Thread Darrick J. Wong
On Mon, Jul 29, 2019 at 11:24:01AM +0800, Jia-Ju Bai wrote:
> In xchk_da_btree_block_check_sibling(), there is an if statement on 
> line 274 to check whether ds->state->altpath.blk[level].bp is NULL:
> if (ds->state->altpath.blk[level].bp)
> 
> When ds->state->altpath.blk[level].bp is NULL, it is used on line 281: 
> xfs_trans_brelse(..., ds->state->altpath.blk[level].bp);
> struct xfs_buf_log_item   *bip = bp->b_log_item;
> ASSERT(bp->b_transp == tp);
> 
> Thus, possible null-pointer dereferences may occur.
> 
> To fix these bugs, ds->state->altpath.blk[level].bp is checked before
> being used.
> 
> These bugs are found by a static analysis tool STCheck written by us.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  fs/xfs/scrub/dabtree.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/scrub/dabtree.c b/fs/xfs/scrub/dabtree.c
> index 94c4f1de1922..33ff90c0dd70 100644
> --- a/fs/xfs/scrub/dabtree.c
> +++ b/fs/xfs/scrub/dabtree.c
> @@ -278,7 +278,9 @@ xchk_da_btree_block_check_sibling(
>   /* Compare upper level pointer to sibling pointer. */
>   if (ds->state->altpath.blk[level].blkno != sibling)
>   xchk_da_set_corrupt(ds, level);
> - xfs_trans_brelse(ds->dargs.trans, ds->state->altpath.blk[level].bp);
> + if (ds->state->altpath.blk[level].bp)
> + xfs_trans_brelse(ds->dargs.trans, 
> + 
> ds->state->altpath.blk[level].bp);

Indentation here (in xfs we use two spaces)

Also, uh, shouldn't we set ds->state->altpath.blk[level].bp to NULL
since we've released the buffer?

--D

>  out:
>   return error;
>  }
> -- 
> 2.17.0
> 


linux-next: build warning after merge of Linus' tree

2019-07-28 Thread Stephen Rothwell
Hi all,

After merging the origin tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

sound/aoa/codecs/onyx.c: In function 'onyx_snd_single_bit_get':
sound/aoa/codecs/onyx.c:377:37: warning: 'c' may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  ucontrol->value.integer.value[0] = !!(c & mask) ^ polarity;
 ^~~~

Introduced by commit

  f3d9478b2ce4 ("[ALSA] snd-aoa: add snd-aoa")

This warning has been around for a long time.  It could possibly be
suppressed by checking for errors returned by onyx_read_register().

-- 
Cheers,
Stephen Rothwell


pgpkKC13MfGC8.pgp
Description: OpenPGP digital signature


[v6 3/6] extable: Add function to search only kernel exception table

2019-07-28 Thread Santosh Sivaraj
Certain architecture specific operating modes (e.g., in powerpc machine
check handler that is unable to access vmalloc memory), the
search_exception_tables cannot be called because it also searches the module
exception tables if entry is not found in the kernel exception table.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Nicholas Piggin 
Signed-off-by: Santosh Sivaraj 
Reviewed-by: Nicholas Piggin 
---
 include/linux/extable.h |  2 ++
 kernel/extable.c| 11 +--
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/include/linux/extable.h b/include/linux/extable.h
index 41c5b3a25f67..81ecfaa83ad3 100644
--- a/include/linux/extable.h
+++ b/include/linux/extable.h
@@ -19,6 +19,8 @@ void trim_init_extable(struct module *m);
 
 /* Given an address, look for it in the exception tables */
 const struct exception_table_entry *search_exception_tables(unsigned long add);
+const struct exception_table_entry *
+search_kernel_exception_table(unsigned long addr);
 
 #ifdef CONFIG_MODULES
 /* For extable.c to search modules' exception tables. */
diff --git a/kernel/extable.c b/kernel/extable.c
index e23cce6e6092..f6c9406eec7d 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -40,13 +40,20 @@ void __init sort_main_extable(void)
}
 }
 
+/* Given an address, look for it in the kernel exception table */
+const
+struct exception_table_entry *search_kernel_exception_table(unsigned long addr)
+{
+   return search_extable(__start___ex_table,
+ __stop___ex_table - __start___ex_table, addr);
+}
+
 /* Given an address, look for it in the exception tables. */
 const struct exception_table_entry *search_exception_tables(unsigned long addr)
 {
const struct exception_table_entry *e;
 
-   e = search_extable(__start___ex_table,
-  __stop___ex_table - __start___ex_table, addr);
+   e = search_kernel_exception_table(addr);
if (!e)
e = search_module_extables(addr);
return e;
-- 
2.20.1



[v6 4/6] powerpc/memcpy: Add memcpy_mcsafe for pmem

2019-07-28 Thread Santosh Sivaraj
From: Balbir Singh 

The pmem infrastructure uses memcpy_mcsafe in the pmem layer so as to
convert machine check exceptions into a return value on failure in case
a machine check exception is encountered during the memcpy. The return
value is the number of bytes remaining to be copied.

This patch largely borrows from the copyuser_power7 logic and does not add
the VMX optimizations, largely to keep the patch simple. If needed those
optimizations can be folded in.

Signed-off-by: Balbir Singh 
[ar...@linux.ibm.com: Added symbol export]
[santosh: return remaining bytes instead of -EFAULT]
Signed-off-by: Santosh Sivaraj 
---
 arch/powerpc/include/asm/string.h   |   2 +
 arch/powerpc/lib/Makefile   |   2 +-
 arch/powerpc/lib/memcpy_mcsafe_64.S | 239 
 3 files changed, 242 insertions(+), 1 deletion(-)
 create mode 100644 arch/powerpc/lib/memcpy_mcsafe_64.S

diff --git a/arch/powerpc/include/asm/string.h 
b/arch/powerpc/include/asm/string.h
index 9bf6dffb4090..b72692702f35 100644
--- a/arch/powerpc/include/asm/string.h
+++ b/arch/powerpc/include/asm/string.h
@@ -53,7 +53,9 @@ void *__memmove(void *to, const void *from, __kernel_size_t 
n);
 #ifndef CONFIG_KASAN
 #define __HAVE_ARCH_MEMSET32
 #define __HAVE_ARCH_MEMSET64
+#define __HAVE_ARCH_MEMCPY_MCSAFE
 
+extern int memcpy_mcsafe(void *dst, const void *src, __kernel_size_t sz);
 extern void *__memset16(uint16_t *, uint16_t v, __kernel_size_t);
 extern void *__memset32(uint32_t *, uint32_t v, __kernel_size_t);
 extern void *__memset64(uint64_t *, uint64_t v, __kernel_size_t);
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index eebc782d89a5..fa6b1b657b43 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -39,7 +39,7 @@ obj-$(CONFIG_PPC_BOOK3S_64) += copyuser_power7.o 
copypage_power7.o \
   memcpy_power7.o
 
 obj64-y+= copypage_64.o copyuser_64.o mem_64.o hweight_64.o \
-  memcpy_64.o pmem.o
+  memcpy_64.o pmem.o memcpy_mcsafe_64.o
 
 obj64-$(CONFIG_SMP)+= locks.o
 obj64-$(CONFIG_ALTIVEC)+= vmx-helper.o
diff --git a/arch/powerpc/lib/memcpy_mcsafe_64.S 
b/arch/powerpc/lib/memcpy_mcsafe_64.S
new file mode 100644
index ..4d8a3d315992
--- /dev/null
+++ b/arch/powerpc/lib/memcpy_mcsafe_64.S
@@ -0,0 +1,239 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) IBM Corporation, 2011
+ * Derived from copyuser_power7.s by Anton Blanchard 
+ * Author - Balbir Singh 
+ */
+#include 
+#include 
+#include 
+
+   .macro err1
+100:
+   EX_TABLE(100b,.Ldo_err1)
+   .endm
+
+   .macro err2
+200:
+   EX_TABLE(200b,.Ldo_err2)
+   .endm
+
+.Ldo_err2:
+   ld  r22,STK_REG(R22)(r1)
+   ld  r21,STK_REG(R21)(r1)
+   ld  r20,STK_REG(R20)(r1)
+   ld  r19,STK_REG(R19)(r1)
+   ld  r18,STK_REG(R18)(r1)
+   ld  r17,STK_REG(R17)(r1)
+   ld  r16,STK_REG(R16)(r1)
+   ld  r15,STK_REG(R15)(r1)
+   ld  r14,STK_REG(R14)(r1)
+   addir1,r1,STACKFRAMESIZE
+.Ldo_err1:
+   /* Do a byte by byte copy to get the exact remaining size */
+   mtctr   r7
+100:   EX_TABLE(100b, .Ldone)
+46:
+err1;  lbz r0,0(r4)
+   addir4,r4,1
+err1;  stb r0,0(r3)
+   addir3,r3,1
+   bdnz46b
+   li  r3,0
+   blr
+
+.Ldone:
+   mfctr   r3
+   blr
+
+
+_GLOBAL(memcpy_mcsafe)
+   mr  r7,r5
+   cmpldi  r5,16
+   blt .Lshort_copy
+
+.Lcopy:
+   /* Get the source 8B aligned */
+   neg r6,r4
+   mtocrf  0x01,r6
+   clrldi  r6,r6,(64-3)
+
+   bf  cr7*4+3,1f
+err1;  lbz r0,0(r4)
+   addir4,r4,1
+err1;  stb r0,0(r3)
+   addir3,r3,1
+   subir7,r7,1
+
+1: bf  cr7*4+2,2f
+err1;  lhz r0,0(r4)
+   addir4,r4,2
+err1;  sth r0,0(r3)
+   addir3,r3,2
+   subir7,r7,2
+
+2: bf  cr7*4+1,3f
+err1;  lwz r0,0(r4)
+   addir4,r4,4
+err1;  stw r0,0(r3)
+   addir3,r3,4
+   subir7,r7,4
+
+3: sub r5,r5,r6
+   cmpldi  r5,128
+   blt 5f
+
+   mflrr0
+   stdur1,-STACKFRAMESIZE(r1)
+   std r14,STK_REG(R14)(r1)
+   std r15,STK_REG(R15)(r1)
+   std r16,STK_REG(R16)(r1)
+   std r17,STK_REG(R17)(r1)
+   std r18,STK_REG(R18)(r1)
+   std r19,STK_REG(R19)(r1)
+   std r20,STK_REG(R20)(r1)
+   std r21,STK_REG(R21)(r1)
+   std r22,STK_REG(R22)(r1)
+   std r0,STACKFRAMESIZE+16(r1)
+
+   srdir6,r5,7
+   mtctr   r6
+
+   /* Now do cacheline (128B) sized loads and stores. */
+   .align  5
+4:
+err2;  ld  r0,0(r4)
+err2;  ld  r6,8(r4)
+err2;  ld  r8,16(r4)
+err2;  ld  r9,24(r4)
+err2;  ld  r10,32(r4)
+err2;  ld  r11,40(r4)
+err2;  ld  r12,48(r4)
+err2;  ld  r14,56(r4)
+err2;  ld  r15,64(r4)
+err2;  ld  r16,72(r4)
+err2;  ld  

[v6 5/6] powerpc/mce: Handle UE event for memcpy_mcsafe

2019-07-28 Thread Santosh Sivaraj
If we take a UE on one of the instructions with a fixup entry, set nip
to continue execution at the fixup entry. Stop processing the event
further or print it.

Based-on-patch-by: Reza Arbab 
Cc: Reza Arbab 
Cc: Mahesh Salgaonkar 
Signed-off-by: Santosh Sivaraj 
---
 arch/powerpc/include/asm/mce.h  |  4 +++-
 arch/powerpc/kernel/mce.c   | 12 +++-
 arch/powerpc/kernel/mce_power.c | 15 +--
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index f3a6036b6bc0..e1931c8c2743 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -122,7 +122,8 @@ struct machine_check_event {
enum MCE_UeErrorType ue_error_type:8;
u8  effective_address_provided;
u8  physical_address_provided;
-   u8  reserved_1[5];
+   u8  ignore_event;
+   u8  reserved_1[4];
u64 effective_address;
u64 physical_address;
u8  reserved_2[8];
@@ -193,6 +194,7 @@ struct mce_error_info {
enum MCE_Initiator  initiator:8;
enum MCE_ErrorClass error_class:8;
boolsync_error;
+   boolignore_event;
 };
 
 #define MAX_MC_EVT 100
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index e78c4f18ea0a..2df132fe3354 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -144,7 +144,9 @@ void save_mce_event(struct pt_regs *regs, long handled,
if (phys_addr != ULONG_MAX) {
mce->u.ue_error.physical_address_provided = true;
mce->u.ue_error.physical_address = phys_addr;
-   machine_check_ue_event(mce);
+   mce->u.ue_error.ignore_event = mce_err->ignore_event;
+   if (!mce->u.ue_error.ignore_event)
+   machine_check_ue_event(mce);
}
}
return;
@@ -230,6 +232,14 @@ void machine_check_queue_event(void)
if (!get_mce_event(, MCE_EVENT_RELEASE))
return;
 
+   /*
+* Don't report this machine check because the caller has a asked us to
+* ignore the event, it has a fixup handler which will do the
+* appropriate error handling and reporting.
+*/
+   if (evt.error_type == MCE_ERROR_TYPE_UE && evt.u.ue_error.ignore_event)
+   return;
+
index = __this_cpu_inc_return(mce_queue_count) - 1;
/* If queue is full, just return for now. */
if (index >= MAX_MC_EVT) {
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index bed38a8e2e50..36ca45bbb273 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -11,6 +11,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Convert an address related to an mm to a physical address.
@@ -558,9 +560,18 @@ static int mce_handle_derror(struct pt_regs *regs,
return 0;
 }
 
-static long mce_handle_ue_error(struct pt_regs *regs)
+static long mce_handle_ue_error(struct pt_regs *regs,
+   struct mce_error_info *mce_err)
 {
long handled = 0;
+   const struct exception_table_entry *entry;
+
+   entry = search_kernel_exception_table(regs->nip);
+   if (entry) {
+   mce_err->ignore_event = true;
+   regs->nip = extable_fixup(entry);
+   return 1;
+   }
 
/*
 * On specific SCOM read via MMIO we may get a machine check
@@ -593,7 +604,7 @@ static long mce_handle_error(struct pt_regs *regs,
_addr);
 
if (!handled && mce_err.error_type == MCE_ERROR_TYPE_UE)
-   handled = mce_handle_ue_error(regs);
+   handled = mce_handle_ue_error(regs, _err);
 
save_mce_event(regs, handled, _err, regs->nip, addr, phys_addr);
 
-- 
2.20.1



[v6 6/6] powerpc: add machine check safe copy_to_user

2019-07-28 Thread Santosh Sivaraj
Use  memcpy_mcsafe() implementation to define copy_to_user_mcsafe()

Signed-off-by: Santosh Sivaraj 
---
 arch/powerpc/Kconfig   |  1 +
 arch/powerpc/include/asm/uaccess.h | 14 ++
 2 files changed, 15 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index f516796dd819..18d831f52fa7 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -135,6 +135,7 @@ config PPC
select ARCH_HAS_STRICT_KERNEL_RWX   if ((PPC_BOOK3S_64 || PPC32) && 
!RELOCATABLE && !HIBERNATION)
select ARCH_HAS_TICK_BROADCAST  if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAS_UACCESS_FLUSHCACHE  if PPC64
+   select ARCH_HAS_UACCESS_MCSAFE  if PPC64
select ARCH_HAS_UBSAN_SANITIZE_ALL
select ARCH_HAS_ZONE_DEVICE if PPC_BOOK3S_64
select ARCH_HAVE_NMI_SAFE_CMPXCHG
diff --git a/arch/powerpc/include/asm/uaccess.h 
b/arch/powerpc/include/asm/uaccess.h
index 8b03eb44e876..15002b51ff18 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -387,6 +387,20 @@ static inline unsigned long raw_copy_to_user(void __user 
*to,
return ret;
 }
 
+static __always_inline unsigned long __must_check
+copy_to_user_mcsafe(void __user *to, const void *from, unsigned long n)
+{
+   if (likely(check_copy_size(from, n, true))) {
+   if (access_ok(to, n)) {
+   allow_write_to_user(to, n);
+   n = memcpy_mcsafe((void *)to, from, n);
+   prevent_write_to_user(to, n);
+   }
+   }
+
+   return n;
+}
+
 extern unsigned long __clear_user(void __user *addr, unsigned long size);
 
 static inline unsigned long clear_user(void __user *addr, unsigned long size)
-- 
2.20.1



[v6 0/6] powerpc: implement machine check safe memcpy

2019-07-28 Thread Santosh Sivaraj
During a memcpy from a pmem device, if a machine check exception is
generated we end up in a panic. In case of fsdax read, this should
only result in a -EIO. Avoid MCE by implementing memcpy_mcsafe.

Before this patch series:

```
bash-4.4# mount -o dax /dev/pmem0 /mnt/pmem/
[ 7621.714094] Disabling lock debugging due to kernel taint
[ 7621.714099] MCE: CPU0: machine check (Severe) Host UE Load/Store [Not 
recovered]
[ 7621.714104] MCE: CPU0: NIP: [c0088978] memcpy_power7+0x418/0x7e0
[ 7621.714107] MCE: CPU0: Hardware error
[ 7621.714112] opal: Hardware platform error: Unrecoverable Machine Check 
exception
[ 7621.714118] CPU: 0 PID: 1368 Comm: mount Tainted: G   M  
5.2.0-rc5-00239-g241e39004581
#50
[ 7621.714123] NIP:  c0088978 LR: c08e16f8 CTR: 01de
[ 7621.714129] REGS: c000fffbfd70 TRAP: 0200   Tainted: G   M  
(5.2.0-rc5-00239-g241e39004581)
[ 7621.714131] MSR:  92209033   CR: 
24428840  XER: 0004
[ 7621.714160] CFAR: c00889a8 DAR: deadbeefdeadbeef DSISR: 8000 
IRQMASK: 0
[ 7621.714171] GPR00: 0e00 c000f0b8b1e0 c12cf100 
c000ed8e1100 
[ 7621.714186] GPR04: c2001100 0001 0200 
03fff1272000 
[ 7621.714201] GPR08: 8000 0010 0020 
0030 
[ 7621.714216] GPR12: 0040 7fffb8c6d390 0050 
0060 
[ 7621.714232] GPR16: 0070  0001 
c000f0b8b960 
[ 7621.714247] GPR20: 0001 c000f0b8b940 0001 
0001 
[ 7621.714262] GPR24: c1382560 c00c003b6380 c00c003b6380 
0001 
[ 7621.714277] GPR28:  0001 c200 
0001 
[ 7621.714294] NIP [c0088978] memcpy_power7+0x418/0x7e0
[ 7621.714298] LR [c08e16f8] pmem_do_bvec+0xf8/0x430
...  ...
```

After this patch series:

```
bash-4.4# mount -o dax /dev/pmem0 /mnt/pmem/
[25302.883978] Buffer I/O error on dev pmem0, logical block 0, async page read
[25303.020816] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your 
own risk
[25303.021236] EXT4-fs (pmem0): Can't read superblock on 2nd try
[25303.152515] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your 
own risk
[25303.284031] EXT4-fs (pmem0): DAX enabled. Warning: EXPERIMENTAL, use at your 
own risk
[25304.084100] UDF-fs: bad mount option "dax" or missing value
mount: /mnt/pmem: wrong fs type, bad option, bad superblock on /dev/pmem0, 
missing codepage or helper
program, or other error.
```

MCE is injected on a pmem address using mambo. The last patch which adds a nop
is only for testing on mambo, where r13 is not restored upon hitting vector 200.

The memcpy code can be optimised by adding VMX optimizations and GAS macros can
be used to enable code reusablity, which I will send as another series.

---
Change-log:
v6:
* Don't return pfn, all callees are expecting physical address anyway [nick]
* Patch re-ordering: move exception table patch before memcpy_mcsafe patch 
[nick]
* Reword commit log for search_exception_tables patch [nick]

v5:
* Don't use search_exception_tables since it searches for module exception 
tables
  also [Nicholas]
* Fix commit message for patch 2 [Nicholas]

v4:
* Squash return remaining bytes patch to memcpy_mcsafe implemtation patch 
[christophe]
* Access ok should be checked for copy_to_user_mcsafe() [christophe]

v3:
* Drop patch which enables DR/IR for external modules
* Drop notifier call chain, we don't want to do that in real mode
* Return remaining bytes from memcpy_mcsafe correctly
* We no longer restore r13 for simulator tests, rather use a nop at 
  vector 0x200 [workaround for simulator; not to be merged]

v2:
* Don't set RI bit explicitly [mahesh]
* Re-ordered series to get r13 workaround as the last patch
--

Balbir Singh (2):
  powerpc/mce: Fix MCE handling for huge pages
  powerpc/memcpy: Add memcpy_mcsafe for pmem

Reza Arbab (1):
  powerpc/mce: Make machine_check_ue_event() static

Santosh Sivaraj (3):
  extable: Add function to search only kernel exception table
  powerpc/mce: Handle UE event for memcpy_mcsafe
  powerpc: add machine check safe copy_to_user

 arch/powerpc/Kconfig |   1 +
 arch/powerpc/include/asm/mce.h   |   6 +-
 arch/powerpc/include/asm/string.h|   2 +
 arch/powerpc/include/asm/uaccess.h   |  14 ++
 arch/powerpc/kernel/mce.c|  16 +-
 arch/powerpc/kernel/mce_power.c  |  65 +---
 arch/powerpc/lib/Makefile|   2 +-
 arch/powerpc/lib/memcpy_mcsafe_64.S  | 239 +++
 arch/powerpc/platforms/pseries/ras.c |   9 +-
 include/linux/extable.h  |   2 +
 kernel/extable.c |  11 +-
 11 files changed, 326 insertions(+), 41 deletions(-)
 create mode 100644 arch/powerpc/lib/memcpy_mcsafe_64.S

-- 
2.20.1



[v6 1/6] powerpc/mce: Make machine_check_ue_event() static

2019-07-28 Thread Santosh Sivaraj
From: Reza Arbab 

The function doesn't get used outside this file, so make it static.

Signed-off-by: Reza Arbab 
Signed-off-by: Santosh Sivaraj 
Reviewed-by: Nicholas Piggin 
---
 arch/powerpc/kernel/mce.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index b18df633eae9..e78c4f18ea0a 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -33,7 +33,7 @@ static DEFINE_PER_CPU(struct machine_check_event[MAX_MC_EVT],
mce_ue_event_queue);
 
 static void machine_check_process_queued_event(struct irq_work *work);
-void machine_check_ue_event(struct machine_check_event *evt);
+static void machine_check_ue_event(struct machine_check_event *evt);
 static void machine_process_ue_event(struct work_struct *work);
 
 static struct irq_work mce_event_process_work = {
@@ -203,7 +203,7 @@ void release_mce_event(void)
 /*
  * Queue up the MCE event which then can be handled later.
  */
-void machine_check_ue_event(struct machine_check_event *evt)
+static void machine_check_ue_event(struct machine_check_event *evt)
 {
int index;
 
-- 
2.20.1



[v6 2/6] powerpc/mce: Fix MCE handling for huge pages

2019-07-28 Thread Santosh Sivaraj
From: Balbir Singh 

The current code would fail on huge pages addresses, since the shift would be
incorrect. Use the correct page shift value returned by __find_linux_pte() to
get the correct physical address. The code is more generic and can handle both
regular and compound pages.

Fixes: ba41e1e1ccb9 ("powerpc/mce: Hookup derror (load/store) UE errors")

Signed-off-by: Balbir Singh 
[ar...@linux.ibm.com: Fixup pseries_do_memory_failure()]
Signed-off-by: Reza Arbab 
[santosh: return physical address instead of pfn; change commit log]
Signed-off-by: Santosh Sivaraj 
---
 arch/powerpc/include/asm/mce.h   |  2 +-
 arch/powerpc/kernel/mce_power.c  | 50 ++--
 arch/powerpc/platforms/pseries/ras.c |  9 ++---
 3 files changed, 29 insertions(+), 32 deletions(-)

diff --git a/arch/powerpc/include/asm/mce.h b/arch/powerpc/include/asm/mce.h
index a4c6a74ad2fb..f3a6036b6bc0 100644
--- a/arch/powerpc/include/asm/mce.h
+++ b/arch/powerpc/include/asm/mce.h
@@ -209,7 +209,7 @@ extern void release_mce_event(void);
 extern void machine_check_queue_event(void);
 extern void machine_check_print_event_info(struct machine_check_event *evt,
   bool user_mode, bool in_guest);
-unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr);
+unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr);
 #ifdef CONFIG_PPC_BOOK3S_64
 void flush_and_reload_slb(void);
 #endif /* CONFIG_PPC_BOOK3S_64 */
diff --git a/arch/powerpc/kernel/mce_power.c b/arch/powerpc/kernel/mce_power.c
index a814d2dfb5b0..bed38a8e2e50 100644
--- a/arch/powerpc/kernel/mce_power.c
+++ b/arch/powerpc/kernel/mce_power.c
@@ -20,13 +20,14 @@
 #include 
 
 /*
- * Convert an address related to an mm to a PFN. NOTE: we are in real
- * mode, we could potentially race with page table updates.
+ * Convert an address related to an mm to a physical address.
+ * NOTE: we are in real mode, we could potentially race with page table 
updates.
  */
-unsigned long addr_to_pfn(struct pt_regs *regs, unsigned long addr)
+unsigned long addr_to_phys(struct pt_regs *regs, unsigned long addr)
 {
-   pte_t *ptep;
-   unsigned long flags;
+   pte_t *ptep, pte;
+   unsigned int shift;
+   unsigned long flags, phys_addr;
struct mm_struct *mm;
 
if (user_mode(regs))
@@ -35,14 +36,21 @@ unsigned long addr_to_pfn(struct pt_regs *regs, unsigned 
long addr)
mm = _mm;
 
local_irq_save(flags);
-   if (mm == current->mm)
-   ptep = find_current_mm_pte(mm->pgd, addr, NULL, NULL);
-   else
-   ptep = find_init_mm_pte(addr, NULL);
+   ptep = __find_linux_pte(mm->pgd, addr, NULL, );
local_irq_restore(flags);
+
if (!ptep || pte_special(*ptep))
return ULONG_MAX;
-   return pte_pfn(*ptep);
+
+   pte = *ptep;
+   if (shift > PAGE_SHIFT) {
+   unsigned long rpnmask = (1ul << shift) - PAGE_SIZE;
+
+   pte = __pte(pte_val(pte) | (addr & rpnmask));
+   }
+   phys_addr = pte_pfn(pte) << PAGE_SHIFT;
+
+   return phys_addr;
 }
 
 /* flush SLBs and reload */
@@ -354,18 +362,16 @@ static int mce_find_instr_ea_and_pfn(struct pt_regs 
*regs, uint64_t *addr,
 * faults
 */
int instr;
-   unsigned long pfn, instr_addr;
+   unsigned long instr_addr;
struct instruction_op op;
struct pt_regs tmp = *regs;
 
-   pfn = addr_to_pfn(regs, regs->nip);
-   if (pfn != ULONG_MAX) {
-   instr_addr = (pfn << PAGE_SHIFT) + (regs->nip & ~PAGE_MASK);
+   instr_addr = addr_to_phys(regs, regs->nip) + (regs->nip & ~PAGE_MASK);
+   if (instr_addr != ULONG_MAX) {
instr = *(unsigned int *)(instr_addr);
if (!analyse_instr(, , instr)) {
-   pfn = addr_to_pfn(regs, op.ea);
*addr = op.ea;
-   *phys_addr = (pfn << PAGE_SHIFT);
+   *phys_addr = addr_to_phys(regs, op.ea);
return 0;
}
/*
@@ -440,15 +446,9 @@ static int mce_handle_ierror(struct pt_regs *regs,
*addr = regs->nip;
if (mce_err->sync_error &&
table[i].error_type == MCE_ERROR_TYPE_UE) {
-   unsigned long pfn;
-
-   if (get_paca()->in_mce < MAX_MCE_DEPTH) {
-   pfn = addr_to_pfn(regs, regs->nip);
-   if (pfn != ULONG_MAX) {
-   *phys_addr =
-   (pfn << PAGE_SHIFT);
-   }
-   }
+   if (get_paca()->in_mce < MAX_MCE_DEPTH)
+   *phys_addr = addr_to_phys(regs,
+

Re: [RFC] net: phy: read link status twice when phy_check_link_status()

2019-07-28 Thread liuyonglong



On 2019/7/27 2:14, Heiner Kallweit wrote:
> On 26.07.2019 11:53, Yonglong Liu wrote:
>> According to the datasheet of Marvell phy and Realtek phy, the
>> copper link status should read twice, or it may get a fake link
>> up status, and cause up->down->up at the first time when link up.
>> This happens more oftem at Realtek phy.
>>
> This is not correct, there is no fake link up status.
> Read the comment in genphy_update_link, only link-down events
> are latched. Means if the first read returns link up, then there
> is no need for a second read. And in polling mode we don't do a
> second read because we want to detect also short link drops.
> 
> It would be helpful if you could describe your actual problem
> and whether you use polling or interrupt mode.
> 

[   44.498633] hns3 :bd:00.1 eth5: net open
[   44.504273] hns3 :bd:00.1: reg=0x1, data=0x79ad -> called from 
phy_start_aneg
[   44.532348] hns3 :bd:00.1: reg=0x1, data=0x798d -> called from 
phy_state_machine,update link.

According to the datasheet:
reg 1.5=0 now, means copper auto-negotiation not complete
reg 1.2=1 now, means link is up

We can see that, when we read the link up, the auto-negotiation
is not complete yet, so the speed is invalid.

I don't know why this happen, maybe this state is keep from bios?
Or we may do something else in the phy initialize to fix it?
And also confuse that why read twice can fix it?

[   44.554063] hns3 :bd:00.1: invalid speed (-1)
[   44.560412] hns3 :bd:00.1 eth5: failed to adjust link.
[   45.194870] hns3 :bd:00.1 eth5: link up
[   45.574095] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x7989
[   46.150051] hns3 :bd:00.1 eth5: link down
[   46.598074] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x7989
[   47.622075] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79a9
[   48.646077] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79ad
[   48.934050] hns3 :bd:00.1 eth5: link up
[   49.702140] hns3 :bd:00.1: phyid=3, reg=0x1, data=0x79ad

>> I add a fake status read, and can solve this problem.
>>
>> I also see that in genphy_update_link(), had delete the fake
>> read in polling mode, so I don't know whether my solution is
>> correct.
>>
>> Or provide a phydev->drv->read_status functions for the phy I
>> used is more acceptable?
>>
>> Signed-off-by: Yonglong Liu 
>> ---
>>  drivers/net/phy/phy.c | 8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
>> index ef7aa73..0c03edc 100644
>> --- a/drivers/net/phy/phy.c
>> +++ b/drivers/net/phy/phy.c
>> @@ -1,4 +1,7 @@
>>  // SPDX-License-Identifier: GPL-2.0+
>> +err = phy_read_status(phydev);
>> +if (err)
>> +return err;
> 
> This seems to be completely wrong at that place.
> 

Sorry, this can be ignore.

>>  /* Framework for configuring and reading PHY devices
>>   * Based on code in sungem_phy.c and gianfar_phy.c
>>   *
>> @@ -525,6 +528,11 @@ static int phy_check_link_status(struct phy_device 
>> *phydev)
>>  
>>  WARN_ON(!mutex_is_locked(>lock));
>>  
>> +/* Do a fake read */
>> +err = phy_read(phydev, MII_BMSR);
>> +if (err < 0)
>> +return err;
>> +
>>  err = phy_read_status(phydev);
>>  if (err)
>>  return err;
>>
> 
> 
> .
> 



[BUG] ALSA: core: seq: a possible double-lock bug in snd_seq_midisynth_remove()

2019-07-28 Thread Jia-Ju Bai

In snd_seq_midisynth_remove(), there is a possible double-lock bug:
snd_seq_midisynth_remove()
    mutex_lock(_mutex); -- line 421
    snd_seq_delete_kernel_client() --- line 436
    seq_free_client() -- line 2244
    mutex_lock(_mutex); -- line 294

This bug is found by a static analysis tool STCheck written by us.

I do not know how to correctly fix this bug, so I only report it.
A possible fix is to release the mutex lock before calling 
seq_free_client() in snd_seq_delete_kernel_client() and then acquiring 
the lock again after calling seq_free_client().



Best wishes,
Jia-Ju Bai


Re: [PATCH] x86: panic when a kernel stack overflow is detected

2019-07-28 Thread Andy Lutomirski
On Sun, Jul 28, 2019 at 6:59 PM Daniel Axtens  wrote:
>
> Currently, when a kernel stack overflow is detected via VMAP_STACK,
> the task is killed with die().
>
> This isn't safe, because we don't know how that process has affected
> kernel state. In particular, we don't know what locks have been taken.
> For example, we can hit a case with lkdtm where a thread takes a
> stack overflow in printk() after taking the logbuf_lock. In that case,
> we deadlock when the kernel next does a printk.
>
> Do not attempt to kill the process when a kernel stack overflow is
> detected. The system state is unknown, the only safe thing to do is
> panic(). (panic() also prints without taking locks so a useful debug
> splat is printed even when logbuf_lock is held.)

The thing I don't like about this is that it reduces the chance that
we successfully log anything to disk.

PeterZ, do you have any useful input here?  I wonder if we could do
something like printk_oh_crap() that is just printk() except that it
panics if it fails to return after a few seconds.

--Andy


linux-next: build warning after merge of the akpm-current tree

2019-07-28 Thread Stephen Rothwell
Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

drivers/infiniband/sw/siw/siw_mem.c: In function 'siw_free_plist':
drivers/infiniband/sw/siw/siw_mem.c:66:16: warning: unused variable 'p' 
[-Wunused-variable]
  struct page **p = chunk->plist;
^

Introduced by commit

  63630f9a8d72 ("mm/gup: add make_dirty arg to put_user_pages_dirty_lock()")

-- 
Cheers,
Stephen Rothwell


pgpyDzupnONUj.pgp
Description: OpenPGP digital signature


linux-next: build warning after merge of the akpm-current tree

2019-07-28 Thread Stephen Rothwell
Hi all,

After merging the akpm-current tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

lib/rbtree_test.c: In function 'check_augmented':
lib/rbtree_test.c:220:18: warning: unused variable 'rb' [-Wunused-variable]
  struct rb_node *rb;
  ^~

Introduced by commit

  33a64f781816 ("augmented-rbtree-add-new-rb_declare_callbacks_max-macro-fix-2")

-- 
Cheers,
Stephen Rothwell


pgpTauRTgVPnB.pgp
Description: OpenPGP digital signature


[BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()

2019-07-28 Thread Jia-Ju Bai
In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm 
is NULL.

Then, dst->xfrm is used on line 3840:
    xfrm_state_mtu(dst->xfrm, mtu);
    if (x->km.state != XFRM_STATE_VALID...)
    aead = x->data;

Thus, possible null-pointer dereferences may occur.

These bugs are found by a static analysis tool STCheck written by us.

I do not know how to correctly fix these bugs, so I only report them.


Best wishes,
Jia-Ju Bai



Re: [PATCH 6/8] PM / OPP: Support adjusting OPP voltages at runtime

2019-07-28 Thread Roger Lu
Dear Stephen Boyd,

This patch is derived from [1]. Please kindly shares the suggestion to
us. Thanks very much.

[1]: https://lore.kernel.org/patchwork/patch/599279/

Dear Viresh,

I followed _opp_set_availability() coding style to refine
dev_pm_opp_adjust_voltage() from this patch. Is this refinement suitable
for OPP core? Thanks a lot.

On Mon, 2019-05-20 at 12:47 +0800, Viresh Kumar wrote:
> On 16-05-19, 17:08, Andrew-sh.Cheng wrote:
> > From: Stephen Boyd 
> > 
> > On some SoCs the Adaptive Voltage Scaling (AVS) technique is
> > employed to optimize the operating voltage of a device. At a
> > given frequency, the hardware monitors dynamic factors and either
> > makes a suggestion for how much to adjust a voltage for the
> > current frequency, or it automatically adjusts the voltage
> > without software intervention. Add an API to the OPP library for
> > the former case, so that AVS type devices can update the voltages
> > for an OPP when the hardware determines the voltage should
> > change. The assumption is that drivers like CPUfreq or devfreq
> > will register for the OPP notifiers and adjust the voltage
> > according to suggestions that AVS makes.
> > 
> > This patch is devired from [1] submitted by Stephen.
> > [1] https://lore.kernel.org/patchwork/patch/599279/
> > 
> > Signed-off-by: Stephen Boyd 
> > Signed-off-by: Roger Lu 
> > ---
> >  drivers/opp/core.c | 78 
> > ++
> >  include/linux/pm_opp.h | 11 +++
> >  2 files changed, 89 insertions(+)
> 
> This is an rcu implementation which got removed long back from OPP core. 
> Please
> align this with the latest changes.
> 


/**
 * dev_pm_opp_adjust_voltage() - helper to change the voltage of an OPP
 * @dev:device for which we do this operation
 * @freq:   OPP frequency to adjust voltage of
 * @u_volt: new OPP voltage
 *
 * Return: -EINVAL for bad pointers, -ENOMEM if no memory available for
the
 * copy operation, returns 0 if no modifcation was done OR modification
was
 * successful.
 */
int dev_pm_opp_adjust_voltage(struct device *dev, unsigned long freq,
  unsigned long u_volt)
{
struct opp_table *opp_table;
struct dev_pm_opp *tmp_opp, *opp = ERR_PTR(-ENODEV);
int r = 0;

/* Find the opp_table */
opp_table = _find_opp_table(dev);
if (IS_ERR(opp_table)) {
r = PTR_ERR(opp_table);
dev_warn(dev, "%s: Device OPP not found (%d)\n", __func__, r);
return r;
}

mutex_lock(_table->lock);

/* Do we have the frequency? */
list_for_each_entry(tmp_opp, _table->opp_list, node) {
if (tmp_opp->rate == freq) {
opp = tmp_opp;
break;
}
}

if (IS_ERR(opp)) {
r = PTR_ERR(opp);
goto adjust_unlock;
}

/* Is update really needed? */
if (opp->supplies->u_volt == u_volt)
goto adjust_unlock;

opp->supplies->u_volt = u_volt;

dev_pm_opp_get(opp);
mutex_unlock(_table->lock);

/* Notify the voltage change of the OPP */
blocking_notifier_call_chain(_table->head,
OPP_EVENT_ADJUST_VOLTAGE,
 opp);

dev_pm_opp_put(opp);
goto adjust_put_table;

adjust_unlock:
mutex_unlock(_table->lock);
adjust_put_table:
dev_pm_opp_put_opp_table(opp_table);
return r;
}

Sincerely,
Roger Lu.



[PATCH] Input: applespi - Fix build error

2019-07-28 Thread YueHaibing
If CONFIG_KEYBOARD_APPLESPI=y but CONFIG_LEDS_CLASS=m
building fails:

drivers/input/keyboard/applespi.o: In function `applespi_probe':
applespi.c:(.text+0x1fcd): undefined reference to 
`devm_led_classdev_register_ext'

Wrap it in LEDS_CLASS macro to fix this.

Reported-by: Hulk Robot 
Fixes: 038b1a05eae6 ("Input: add Apple SPI keyboard and trackpad driver")
Signed-off-by: YueHaibing 
---
 drivers/input/keyboard/applespi.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/input/keyboard/applespi.c 
b/drivers/input/keyboard/applespi.c
index acf34a5..9c50b09 100644
--- a/drivers/input/keyboard/applespi.c
+++ b/drivers/input/keyboard/applespi.c
@@ -1790,11 +1790,13 @@ static int applespi_probe(struct spi_device *spi)
applespi->backlight_info.default_trigger = "kbd-backlight";
applespi->backlight_info.brightness_set  = applespi_set_bl_level;
 
+#ifdef CONFIG_LEDS_CLASS
sts = devm_led_classdev_register(>dev, >backlight_info);
if (sts)
dev_warn(>spi->dev,
 "Unable to register keyboard backlight class dev 
(%d)\n",
 sts);
+#endif
 
/* set up debugfs entries for touchpad dimensions logging */
applespi->debugfs_root = debugfs_create_dir("applespi", NULL);
-- 
2.7.4




Re: [PATCH] modpost: check for static EXPORT_SYMBOL* functions

2019-07-28 Thread Masahiro Yamada
On Sun, Jul 28, 2019 at 7:09 PM Denis Efremov  wrote:
>
> This patch adds a check to warn about static EXPORT_SYMBOL* functions
> during the modpost. In most of the cases, a static symbol marked for
> exporting is an odd combination that should be fixed either by deleting
> the exporting mark or by removing the static attribute and adding the
> appropriate declaration to headers.
>
> This check could help to detect the following problems:
> 1. 550113d4e9f5 ("i2c: add newly exported functions to the header, too")
> 2. 54638c6eaf44 ("net: phy: make exported variables non-static")
> 3. 98ef2046f28b ("mm: remove the exporting of totalram_pages")
> 4. 73df167c819e ("s390/zcrypt: remove the exporting of 
> ap_query_configuration")
> 5. a57caf8c527f ("sunrpc/cache: remove the exporting of cache_seq_next")
> 6. e4e4730698c9 ("crypto: skcipher - remove the exporting of 
> skcipher_walk_next")
> 7. 14b4c48bb1ce ("gve: Remove the exporting of gve_probe")
> 8. 9b79ee9773a8 ("scsi: libsas: remove the exporting of sas_wait_eh")
> 9. ...
>
> Build time impact, allmodconfig, Dell XPS 15 9570 (measurements 3x):
> $ make mrproper; make allmodconfig; time make -j12; \
>   git checkout HEAD~1; \
>   make mrproper; make allmodconfig; time make -j12
> 1.
>(with patch) 17635,94s user 1895,54s system 1085% cpu 29:59,22 total
>(w/o  patch) 17275,42s user 1803,87s system 1112% cpu 28:35,66 total
> 2.
>(with patch) 17369,51s user 1763,28s system % cpu 28:41,47 total
>(w/o  patch) 16880,50s user 1670,93s system 1113% cpu 27:46,56 total
> 3.
>(with patch) 17937,88s user 1842,53s system 1109% cpu 29:42,26 total
>(w/o  patch) 17267,55s user 1725,09s system % cpu 28:28,17 total
>
> Thus, the current implementation adds approx. 1 min for allmodconfig.
>
> Acked-by: Emil Velikov 
> Signed-off-by: Denis Efremov 
> ---
>  scripts/mod/modpost.c | 32 
>  1 file changed, 32 insertions(+)
>

>
> @@ -2425,6 +2443,7 @@ int main(int argc, char **argv)
> char *dump_write = NULL, *files_source = NULL;
> int opt;
> int err;
> +   size_t n;

Sorry, I missed to ask this in the previous version.

If there is not a particular reason,
may I ask you to use 'int' instead of 'size_t' here?

SYMBOL_HASH_SIZE (= 1024) is small enough, and
it will keep consistency with
the write_dump() function in this file.

If it is tedious to send a new version,
may I fix-up 'size_t' -> 'int' ?

Thanks.


> struct ext_sym_list *extsym_iter;
> struct ext_sym_list *extsym_start = NULL;
>
> @@ -2520,6 +2539,19 @@ int main(int argc, char **argv)
> if (sec_mismatch_count && sec_mismatch_fatal)
> fatal("modpost: Section mismatches detected.\n"
>   "Set CONFIG_SECTION_MISMATCH_WARN_ONLY=y to allow 
> them.\n");
> +   for (n = 0; n < SYMBOL_HASH_SIZE; n++) {
> +   struct symbol *s = symbolhash[n];
> +
> +   while (s) {
> +   if (s->is_static)
> +   warn("\"%s\" [%s] is the static %s\n",
> +s->name, s->module->name,
> +export_str(s->export));
> +
> +   s = s->next;
> +   }
> +   }
> +
> free(buf.p);
>
> return err;
> --
> 2.21.0
>


-- 
Best Regards
Masahiro Yamada


[PATCH] fs: xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling()

2019-07-28 Thread Jia-Ju Bai
In xchk_da_btree_block_check_sibling(), there is an if statement on 
line 274 to check whether ds->state->altpath.blk[level].bp is NULL:
if (ds->state->altpath.blk[level].bp)

When ds->state->altpath.blk[level].bp is NULL, it is used on line 281: 
xfs_trans_brelse(..., ds->state->altpath.blk[level].bp);
struct xfs_buf_log_item *bip = bp->b_log_item;
ASSERT(bp->b_transp == tp);

Thus, possible null-pointer dereferences may occur.

To fix these bugs, ds->state->altpath.blk[level].bp is checked before
being used.

These bugs are found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai 
---
 fs/xfs/scrub/dabtree.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/scrub/dabtree.c b/fs/xfs/scrub/dabtree.c
index 94c4f1de1922..33ff90c0dd70 100644
--- a/fs/xfs/scrub/dabtree.c
+++ b/fs/xfs/scrub/dabtree.c
@@ -278,7 +278,9 @@ xchk_da_btree_block_check_sibling(
/* Compare upper level pointer to sibling pointer. */
if (ds->state->altpath.blk[level].blkno != sibling)
xchk_da_set_corrupt(ds, level);
-   xfs_trans_brelse(ds->dargs.trans, ds->state->altpath.blk[level].bp);
+   if (ds->state->altpath.blk[level].bp)
+   xfs_trans_brelse(ds->dargs.trans, 
+   
ds->state->altpath.blk[level].bp);
 out:
return error;
 }
-- 
2.17.0



Re: [EXT] Re: [PATCH] mailbox: imx: add support for imx v1 mu

2019-07-28 Thread Dong Aisheng
On Mon, Jul 29, 2019 at 11:03 AM Richard Zhu  wrote:
>
> Hi Aisheng:
> Thanks for your comments.
>
> > -Original Message-
> > From: Dong Aisheng 
> > Sent: 2019年7月29日 10:35
> > To: Richard Zhu 
> > Cc: jassisinghb...@gmail.com; Oleksij Rempel ;
> > Aisheng Dong ; open list
> > ; moderated list:ARM/FREESCALE IMX / MXC
> > ARM ARCHITECTURE 
> > Subject: [EXT] Re: [PATCH] mailbox: imx: add support for imx v1 mu
> >
> > On Mon, Jul 29, 2019 at 10:36 AM Richard Zhu 
> > wrote:
> > >
> > > There is a version1.0 MU on i.MX7ULP platform.
> > > One new version ID register is added, and it's offset is 0.
> > > TRn registers are defined at the offset 0x20 ~ 0x2C.
> > > RRn registers are defined at the offset 0x40 ~ 0x4C.
> > > SR/CR registers are defined at 0x60/0x64.
> > > Extend this driver to support it.
> > >
> >
> > If only the register base offset is different, there's probably a more 
> > simple way.
> > Please refer to:
> >
> [Richard Zhu] TRx, RRx and the CR/SR have the different offset addresses.
> That means three different offset addresses should be manipulated if the 
> solution listed above is used.
> It seems that it's a little complex, and maybe introduce bugs when different 
> offset address is manipulated.
> According, the current method suggested by Oleksij is much clear, and easy to 
> extend for future extension.
>

I missed that.
Maybe the patch title should be V2 and add Suggested-by: tag to
reminder reviewer
it's a new version?

If there're multiple offset differences. I'm fine with this way.
Feel free to add my tag.
Reviewed-by: Dong Aisheng 

Regards
Aisheng

> Hi Olekiji:
> How do you think about?
>
> Best Regards
> Richard Zhu
>
> > Regards
> > Aisheng
> >
> > > Signed-off-by: Richard Zhu 
> > > ---
> > >  drivers/mailbox/imx-mailbox.c | 67
> > > ---
> > >  1 file changed, 50 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/mailbox/imx-mailbox.c
> > > b/drivers/mailbox/imx-mailbox.c index 25be8bb..8423a38 100644
> > > --- a/drivers/mailbox/imx-mailbox.c
> > > +++ b/drivers/mailbox/imx-mailbox.c
> > > @@ -12,19 +12,11 @@
> > >  #include 
> > >  #include 
> > >
> > > -/* Transmit Register */
> > > -#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> > > -/* Receive Register */
> > > -#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> > > -/* Status Register */
> > > -#define IMX_MU_xSR 0x20
> > >  #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
> > >  #define IMX_MU_xSR_RFn(x)  BIT(24 + (3 - (x)))
> > >  #define IMX_MU_xSR_TEn(x)  BIT(20 + (3 - (x)))
> > >  #define IMX_MU_xSR_BRDIP   BIT(9)
> > >
> > > -/* Control Register */
> > > -#define IMX_MU_xCR 0x24
> > >  /* General Purpose Interrupt Enable */
> > >  #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
> > >  /* Receive Interrupt Enable */
> > > @@ -44,6 +36,13 @@ enum imx_mu_chan_type {
> > > IMX_MU_TYPE_RXDB,   /* Rx doorbell */
> > >  };
> > >
> > > +struct imx_mu_dcfg {
> > > +   u32 xTR[4]; /* Transmit Registers */
> > > +   u32 xRR[4]; /* Receive Registers */
> > > +   u32 xSR;/* Status Register */
> > > +   u32 xCR;/* Control Register */
> > > +};
> > > +
> > >  struct imx_mu_con_priv {
> > > unsigned intidx;
> > > char
> > irq_desc[IMX_MU_CHAN_NAME_SIZE];
> > > @@ -61,12 +60,39 @@ struct imx_mu_priv {
> > > struct mbox_chanmbox_chans[IMX_MU_CHANS];
> > >
> > > struct imx_mu_con_priv  con_priv[IMX_MU_CHANS];
> > > +   const struct imx_mu_dcfg*dcfg;
> > > struct clk  *clk;
> > > int irq;
> > >
> > > boolside_b;
> > >  };
> > >
> > > +static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
> > > +   .xTR[0] = 0x0,
> > > +   .xTR[1] = 0x4,
> > > +   .xTR[2] = 0x8,
> > > +   .xTR[3] = 0xC,
> > > +   .xRR[0] = 0x10,
> > > +   .xRR[1] = 0x14,
> > > +   .xRR[2] = 0x18,
> > > +   .xRR[3] = 0x1C,
> > > +   .xSR= 0x20,
> > > +   .xCR= 0x24,
> > > +};
> > > +
> > > +static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
> > > +   .xTR[0] = 0x20,
> > > +   .xTR[1] = 0x24,
> > > +   .xTR[2] = 0x28,
> > > +   .xTR[3] = 0x2C,
> > > +   .xRR[0] = 0x40,
> > > +   .xRR[1] = 0x44,
> > > +   .xRR[2] = 0x48,
> > > +   .xRR[3] = 0x4C,
> > > +   .xSR= 0x60,
> > > +   .xCR= 0x64,
> > > +};
> > > +
> > >  static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller
> > > *mbox)  {
> > > return container_of(mbox, struct imx_mu_priv, mbox); @@ -88,10
> > > +114,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32 set,
> > u32 clr)
> > > u32 val;
> > >
> > > spin_lock_irqsave(>xcr_lock, flags);
> > > -   val = imx_mu_read(priv, IMX_MU_xCR);
> > > +   val = imx_mu_read(priv, priv->dcfg->xCR);
> > >  

[no subject]

2019-07-28 Thread Lin Xiulei
unsubscribe linux-kernel


[PATCH] scsi: mpt3sas: Fix a possible null-pointer dereference in mpt3sas_transport_update_links()

2019-07-28 Thread Jia-Ju Bai
In mpt3sas_transport_update_links(), there is an if statement 
on line 994 to check whether mpt3sas_phy->phy is NULL:
if (mpt3sas_phy->phy)

When mpt3sas_phy->phy is NULL, it is used on line 999:
dev_printk(KERN_INFO, _phy->phy->dev, ...)

Thus, a possible null-pointer dereference may occur.

To fix this bug, mpt3sas_phy->phy is checked before being used.

This bug is found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai 
---
 drivers/scsi/mpt3sas/mpt3sas_transport.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_transport.c 
b/drivers/scsi/mpt3sas/mpt3sas_transport.c
index 5324662751bf..df790a9877a0 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_transport.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_transport.c
@@ -995,7 +995,8 @@ mpt3sas_transport_update_links(struct MPT3SAS_ADAPTER *ioc,
mpt3sas_phy->phy->negotiated_linkrate =
_transport_convert_phy_link_rate(link_rate);
 
-   if ((ioc->logging_level & MPT_DEBUG_TRANSPORT))
+   if ((ioc->logging_level & MPT_DEBUG_TRANSPORT) && 
+   mpt3sas_phy->phy)
dev_printk(KERN_INFO, _phy->phy->dev,
"refresh: parent sas_addr(0x%016llx),\n"
"\tlink_rate(0x%02x), phy(%d)\n"
-- 
2.17.0



Re: [PATCH RESEND] autonuma: Fix scan period updating

2019-07-28 Thread Huang, Ying
Srikar Dronamraju  writes:

> * Huang, Ying  [2019-07-26 15:45:39]:
>
>> Hi, Srikar,
>> 
>> >
>> > More Remote + Private page Accesses:
>> > Most likely the Private accesses are going to be local accesses.
>> >
>> > In the unlikely event of the private accesses not being local, we should
>> > scan faster so that the memory and task consolidates.
>> >
>> > More Remote + Shared page Accesses: This means the workload has not
>> > consolidated and needs to scan faster. So we need to scan faster.
>> 
>> This sounds reasonable.  But
>> 
>> lr_ratio < NUMA_PERIOD_THRESHOLD
>> 
>> doesn't indicate More Remote.  If Local = Remote, it is also true.  If
>
> less lr_ratio means more remote.
>
>> there are also more Shared, we should slow down the scanning.  So, the
>
> Why should we slowing down if there are more remote shared accesses?
>
>> logic could be
>> 
>> if (lr_ratio >= NUMA_PERIOD_THRESHOLD)
>> slow down scanning
>> else if (sp_ratio >= NUMA_PERIOD_THRESHOLD) {
>> if (NUMA_PERIOD_SLOTS - lr_ratio >= NUMA_PERIOD_THRESHOLD)
>> speed up scanning

Thought about this again.  For example, a multi-threads workload runs on
a 4-sockets machine, and most memory accesses are shared.  The optimal
situation will be pseudo-interleaving, that is, spreading memory
accesses evenly among 4 NUMA nodes.  Where "share" >> "private", and
"remote" > "local".  And we should slow down scanning to reduce the
overhead.

What do you think about this?

Best Regards,
Huang, Ying

>> else
>> slow down scanning
>> } else
>>speed up scanning
>> 
>> This follows your idea better?
>> 
>> Best Regards,
>> Huang, Ying


RE: [EXT] Re: [PATCH] mailbox: imx: add support for imx v1 mu

2019-07-28 Thread Richard Zhu
Hi Aisheng:
Thanks for your comments.

> -Original Message-
> From: Dong Aisheng 
> Sent: 2019年7月29日 10:35
> To: Richard Zhu 
> Cc: jassisinghb...@gmail.com; Oleksij Rempel ;
> Aisheng Dong ; open list
> ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE 
> Subject: [EXT] Re: [PATCH] mailbox: imx: add support for imx v1 mu
> 
> On Mon, Jul 29, 2019 at 10:36 AM Richard Zhu 
> wrote:
> >
> > There is a version1.0 MU on i.MX7ULP platform.
> > One new version ID register is added, and it's offset is 0.
> > TRn registers are defined at the offset 0x20 ~ 0x2C.
> > RRn registers are defined at the offset 0x40 ~ 0x4C.
> > SR/CR registers are defined at 0x60/0x64.
> > Extend this driver to support it.
> >
> 
> If only the register base offset is different, there's probably a more simple 
> way.
> Please refer to:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel
> .org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git%2Fcom
> mit%2Fdrivers%2Ftty%2Fserial%2Ffsl_lpuart.c%3Fid%3D24b1e5f0e83c2aced80
> 96473d20c4cf6c1355f30data=02%7C01%7Chongxing.zhu%40nxp.com%
> 7C48b26de751464410249308d713ceae22%7C686ea1d3bc2b4c6fa92cd99c5c30
> 1635%7C0%7C1%7C636999650716588024sdata=7OEZB8HMbQqfe6KgD
> HtE7AKAtgPGJHXGeUiAFjAP28k%3Dreserved=0
> 
[Richard Zhu] TRx, RRx and the CR/SR have the different offset addresses.
That means three different offset addresses should be manipulated if the 
solution listed above is used.
It seems that it's a little complex, and maybe introduce bugs when different 
offset address is manipulated.
According, the current method suggested by Oleksij is much clear, and easy to 
extend for future extension.

Hi Olekiji:
How do you think about?

Best Regards
Richard Zhu

> Regards
> Aisheng
> 
> > Signed-off-by: Richard Zhu 
> > ---
> >  drivers/mailbox/imx-mailbox.c | 67
> > ---
> >  1 file changed, 50 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/mailbox/imx-mailbox.c
> > b/drivers/mailbox/imx-mailbox.c index 25be8bb..8423a38 100644
> > --- a/drivers/mailbox/imx-mailbox.c
> > +++ b/drivers/mailbox/imx-mailbox.c
> > @@ -12,19 +12,11 @@
> >  #include 
> >  #include 
> >
> > -/* Transmit Register */
> > -#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> > -/* Receive Register */
> > -#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> > -/* Status Register */
> > -#define IMX_MU_xSR 0x20
> >  #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
> >  #define IMX_MU_xSR_RFn(x)  BIT(24 + (3 - (x)))
> >  #define IMX_MU_xSR_TEn(x)  BIT(20 + (3 - (x)))
> >  #define IMX_MU_xSR_BRDIP   BIT(9)
> >
> > -/* Control Register */
> > -#define IMX_MU_xCR 0x24
> >  /* General Purpose Interrupt Enable */
> >  #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
> >  /* Receive Interrupt Enable */
> > @@ -44,6 +36,13 @@ enum imx_mu_chan_type {
> > IMX_MU_TYPE_RXDB,   /* Rx doorbell */
> >  };
> >
> > +struct imx_mu_dcfg {
> > +   u32 xTR[4]; /* Transmit Registers */
> > +   u32 xRR[4]; /* Receive Registers */
> > +   u32 xSR;/* Status Register */
> > +   u32 xCR;/* Control Register */
> > +};
> > +
> >  struct imx_mu_con_priv {
> > unsigned intidx;
> > char
> irq_desc[IMX_MU_CHAN_NAME_SIZE];
> > @@ -61,12 +60,39 @@ struct imx_mu_priv {
> > struct mbox_chanmbox_chans[IMX_MU_CHANS];
> >
> > struct imx_mu_con_priv  con_priv[IMX_MU_CHANS];
> > +   const struct imx_mu_dcfg*dcfg;
> > struct clk  *clk;
> > int irq;
> >
> > boolside_b;
> >  };
> >
> > +static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
> > +   .xTR[0] = 0x0,
> > +   .xTR[1] = 0x4,
> > +   .xTR[2] = 0x8,
> > +   .xTR[3] = 0xC,
> > +   .xRR[0] = 0x10,
> > +   .xRR[1] = 0x14,
> > +   .xRR[2] = 0x18,
> > +   .xRR[3] = 0x1C,
> > +   .xSR= 0x20,
> > +   .xCR= 0x24,
> > +};
> > +
> > +static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
> > +   .xTR[0] = 0x20,
> > +   .xTR[1] = 0x24,
> > +   .xTR[2] = 0x28,
> > +   .xTR[3] = 0x2C,
> > +   .xRR[0] = 0x40,
> > +   .xRR[1] = 0x44,
> > +   .xRR[2] = 0x48,
> > +   .xRR[3] = 0x4C,
> > +   .xSR= 0x60,
> > +   .xCR= 0x64,
> > +};
> > +
> >  static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller
> > *mbox)  {
> > return container_of(mbox, struct imx_mu_priv, mbox); @@ -88,10
> > +114,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32 set,
> u32 clr)
> > u32 val;
> >
> > spin_lock_irqsave(>xcr_lock, flags);
> > -   val = imx_mu_read(priv, IMX_MU_xCR);
> > +   val = imx_mu_read(priv, priv->dcfg->xCR);
> > val &= ~clr;
> > val |= set;
> > -   imx_mu_write(priv, val, IMX_MU_xCR);
> > +   imx_mu_write(priv, 

[PATCH] ath6kl: Fix a possible null-pointer dereference in ath6kl_htc_mbox_create()

2019-07-28 Thread Jia-Ju Bai
In ath6kl_htc_mbox_create(), when kzalloc() on line 2855 fails,
target->dev is assigned to NULL, and ath6kl_htc_mbox_cleanup(target) is
called on line 2885.

In ath6kl_htc_mbox_cleanup(), target->dev is used on line 2895:
ath6kl_hif_cleanup_scatter(target->dev->ar);

Thus, a null-pointer dereference may occur.

To fix this bug, kfree(target) is called and NULL is returned when
kzalloc() on line 2855 fails.

This bug is found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai 
---
 drivers/net/wireless/ath/ath6kl/htc_mbox.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath6kl/htc_mbox.c 
b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
index 65c31da43c47..998947ef63b6 100644
--- a/drivers/net/wireless/ath/ath6kl/htc_mbox.c
+++ b/drivers/net/wireless/ath/ath6kl/htc_mbox.c
@@ -2855,8 +2855,8 @@ static void *ath6kl_htc_mbox_create(struct ath6kl *ar)
target->dev = kzalloc(sizeof(*target->dev), GFP_KERNEL);
if (!target->dev) {
ath6kl_err("unable to allocate memory\n");
-   status = -ENOMEM;
-   goto err_htc_cleanup;
+   kfree(target);
+   return NULL;
}
 
spin_lock_init(>htc_lock);
-- 
2.17.0



Re: [PATCH] iio: tsl2772: Use device-managed API

2019-07-28 Thread Chuhong Yuan
Brian Masney  于2019年7月28日周日 下午4:31写道:
>
> On Sat, Jul 27, 2019 at 12:57:49PM +0100, Jonathan Cameron wrote:
> > On Fri, 26 Jul 2019 20:30:58 +0800
> > Chuhong Yuan  wrote:
> >
> > > Use devm_iio_device_register to simplify
> > > the code.
> > >
> > > Signed-off-by: Chuhong Yuan 
> >
> > Please try to pick up on likely reviewers in your cc list.  In this case
> > Brian did a lot of work cleaning these drivers up so I've added him.
> > Not everyone keeps up with the linux-iio list for some reason ;)
> >
> > Immediate thought was that you had broken the ordering but turns out
> > it is already buggy.
> >
> > As things stand, we remove the userspace interfaces (iio_device_unregister)
> > after turning off the power.   This is obviously a bad idea and also
> > form a purely "obviously correct" stand point, we aren't doing the reverse
> > of probe.
> >
> > So, I 'think' the right option is to reorder remove so that the power left
> > on until after the iio_device_unregister call. At that point, we can't
> > use devm_iio_device_register as we'll have the same incorrect ordering
> > we currently have.
> >
> > Brian, you looked at this driver most recently.  Thoughts?
>
> devm_add_action() could be used in the probe function to schedule the call
> to tsl2772_chip_off(). That would eliminate the need for
> tsl2772_remove(). See tsl2772_disable_regulators_action() for an example in
> that driver.
>

I find that we can use devm_add_action_or_reset() for
tsl2772_disable_regulators_action() to eliminate the fault handling code.

I am not sure whether devm_add_action() can be used for
tsl2772_chip_off() because it returns an integer, not void.
And the return value is used in several functions.

> Chuhong: Another potential cleanup to shrink the size of this driver is
> to move it over to the regulator_bulk_() API. I didn't realize that API
> existed at the time I introduced the regulator support. If you're
> interested in taking on that cleanup as well, I can test those changes
> for you if you don't have the hardware.
>
> Brian
>

Does that mean merging vdd_supply and vddio_supply to an array of
regulator_bulk_data and utilize regulator_bulk_() API to operate them
together?
If so, I can do that cleanup in next version.

I have an additional question that I find regulator_disable() is used in the
end of many .remove functions of drivers, which hinders us to use devm
functions.
One example is drivers/iio/light/gp2ap020a00f.c.
Is there any solution to this problem?

Regards,
Chuhong

>
> > > ---
> > >  drivers/iio/light/tsl2772.c | 4 +---
> > >  1 file changed, 1 insertion(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
> > > index 83cece921843..aa5891d105e8 100644
> > > --- a/drivers/iio/light/tsl2772.c
> > > +++ b/drivers/iio/light/tsl2772.c
> > > @@ -1877,7 +1877,7 @@ static int tsl2772_probe(struct i2c_client *clientp,
> > > if (ret < 0)
> > > return ret;
> > >
> > > -   ret = iio_device_register(indio_dev);
> > > +   ret = devm_iio_device_register(>dev, indio_dev);
> > > if (ret) {
> > > tsl2772_chip_off(indio_dev);
> > > dev_err(>dev,
> > > @@ -1928,8 +1928,6 @@ static int tsl2772_remove(struct i2c_client *client)
> > >
> > > tsl2772_chip_off(indio_dev);
> > >
> > > -   iio_device_unregister(indio_dev);
> > > -
> > > return 0;
> > >  }
> > >


Re: [PATCH v9 19/21] mm: Add generic ptdump

2019-07-28 Thread Anshuman Khandual


On 07/22/2019 09:12 PM, Steven Price wrote:
> Add a generic version of page table dumping that architectures can
> opt-in to
> 
> Signed-off-by: Steven Price 
> ---
>  include/linux/ptdump.h |  19 +
>  mm/Kconfig.debug   |  21 ++
>  mm/Makefile|   1 +
>  mm/ptdump.c| 161 +
>  4 files changed, 202 insertions(+)
>  create mode 100644 include/linux/ptdump.h
>  create mode 100644 mm/ptdump.c
> 
> diff --git a/include/linux/ptdump.h b/include/linux/ptdump.h
> new file mode 100644
> index ..eb8e78154be3
> --- /dev/null
> +++ b/include/linux/ptdump.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _LINUX_PTDUMP_H
> +#define _LINUX_PTDUMP_H
> +
> +struct ptdump_range {
> + unsigned long start;
> + unsigned long end;
> +};
> +
> +struct ptdump_state {
> + void (*note_page)(struct ptdump_state *st, unsigned long addr,
> +   int level, unsigned long val);
> + const struct ptdump_range *range;
> +};
> +
> +void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm);
> +
> +#endif /* _LINUX_PTDUMP_H */
> diff --git a/mm/Kconfig.debug b/mm/Kconfig.debug
> index 82b6a20898bd..7ad939b7140f 100644
> --- a/mm/Kconfig.debug
> +++ b/mm/Kconfig.debug
> @@ -115,3 +115,24 @@ config DEBUG_RODATA_TEST
>  depends on STRICT_KERNEL_RWX
>  ---help---
>This option enables a testcase for the setting rodata read-only.
> +
> +config GENERIC_PTDUMP
> + bool
> +
> +config PTDUMP_CORE
> + bool
> +
> +config PTDUMP_DEBUGFS
> + bool "Export kernel pagetable layout to userspace via debugfs"
> + depends on DEBUG_KERNEL
> + depends on DEBUG_FS
> + depends on GENERIC_PTDUMP
> + select PTDUMP_CORE

So PTDUMP_DEBUGFS depends on GENERIC_PTDUMP but selects PTDUMP_CORE. So any arch
subscribing this new generic PTDUMP by selecting GENERIC_PTDUMP needs to provide
some functions for PTDUMP_DEBUGFS which does not really have any code in generic
MM. Also ptdump_walk_pgd() is wrapped in PTDUMP_CORE not GENERIC_PTDUMP. Then 
what
does PTDUMP_GENERIC really indicate ? Bit confusing here.

The new ptdump_walk_pgd() symbol needs to be wrapped in a config symbol for sure
which should be selected in all platforms wishing to use it. GENERIC_PTDUMP can
be that config.

PTDUMP_DEBUGFS will require a full implementation (i.e PTDUMP_CORE) irrespective
of whether the platform subscribes GENERIC_PTDUMP or not. It should be something
like this.

config PTDUMP_DEBUGFS
bool "Export kernel pagetable layout to userspace via debugfs"
depends on DEBUG_KERNEL
depends on DEBUG_FS
select PTDUMP_CORE

PTDUMP_DEBUGFS need not depend on GENERIC_PTDUMP. All it requires is a 
PTDUMP_CORE
implementation which can optionally use ptdump_walk_pgd() through 
GENERIC_PTDUMP.
s/GENERIC_PTDUMP/PTDUMP_GENERIC to match and group with other configs.

DEBUG_WX can also be moved to generic MM like PTDUMP_DEBUGFS ?

> + help
> +   Say Y here if you want to show the kernel pagetable layout in a
> +   debugfs file. This information is only useful for kernel developers
> +   who are working in architecture specific areas of the kernel.
> +   It is probably not a good idea to enable this feature in a production
> +   kernel.
> +
> +   If in doubt, say N.
> diff --git a/mm/Makefile b/mm/Makefile
> index 338e528ad436..750a4c12d5da 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -104,3 +104,4 @@ obj-$(CONFIG_HARDENED_USERCOPY) += usercopy.o
>  obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
>  obj-$(CONFIG_HMM_MIRROR) += hmm.o
>  obj-$(CONFIG_MEMFD_CREATE) += memfd.o
> +obj-$(CONFIG_PTDUMP_CORE) += ptdump.o

Should be GENERIC_PTDUMP instead ?

> diff --git a/mm/ptdump.c b/mm/ptdump.c
> new file mode 100644
> index ..39befc9088b8
> --- /dev/null
> +++ b/mm/ptdump.c
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +#include 
> +#include 
> +#include 
> +
> +static int ptdump_pgd_entry(pgd_t *pgd, unsigned long addr,
> + unsigned long next, struct mm_walk *walk)
> +{
> + struct ptdump_state *st = walk->private;
> + pgd_t val = READ_ONCE(*pgd);
> +
> + if (pgd_leaf(val))
> + st->note_page(st, addr, 1, pgd_val(val));
> +
> + return 0;
> +}
> +
> +static int ptdump_p4d_entry(p4d_t *p4d, unsigned long addr,
> + unsigned long next, struct mm_walk *walk)
> +{
> + struct ptdump_state *st = walk->private;
> + p4d_t val = READ_ONCE(*p4d);
> +
> + if (p4d_leaf(val))
> + st->note_page(st, addr, 2, p4d_val(val));
> +
> + return 0;
> +}
> +
> +static int ptdump_pud_entry(pud_t *pud, unsigned long addr,
> + unsigned long next, struct mm_walk *walk)
> +{
> + struct ptdump_state *st = walk->private;
> + pud_t val = READ_ONCE(*pud);
> +
> + if (pud_leaf(val))
> + st->note_page(st, addr, 

[PATCH V4 net-next 02/10] net: hns3: add a check for get_reset_level

2019-07-28 Thread Huazhong Tan
From: Guangbin Huang 

For some cases, ops->get_reset_level may not be implemented, so we
should check whether it is NULL before calling get_reset_level.

Signed-off-by: Guangbin Huang 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 08af782..4d58c53 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -1963,7 +1963,7 @@ static pci_ers_result_t hns3_slot_reset(struct pci_dev 
*pdev)
 
ops = ae_dev->ops;
/* request the reset */
-   if (ops->reset_event) {
+   if (ops->reset_event && ops->get_reset_level) {
if (ae_dev->hw_err_reset_req) {
reset_type = ops->get_reset_level(ae_dev,
_dev->hw_err_reset_req);
-- 
2.7.4



[PATCH V4 net-next 08/10] net: hns3: add interrupt affinity support for misc interrupt

2019-07-28 Thread Huazhong Tan
From: Yunsheng Lin 

The misc interrupt is used to schedule the reset and mailbox
subtask, and service_task delayed_work is used to do periodic
management work each second.

This patch sets the above three subtask's affinity using the
misc interrupt' affinity.

Also this patch setups a affinity notify for misc interrupt to
allow user to change the above three subtask's affinity.

Signed-off-by: Yunsheng Lin 
Signed-off-by: Peng Li 
Signed-off-by: Huazhong Tan 
---
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 53 --
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|  4 ++
 2 files changed, 53 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 13c9697..30a7074 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -1270,6 +1270,12 @@ static int hclge_configure(struct hclge_dev *hdev)
 
hclge_init_kdump_kernel_config(hdev);
 
+   /* Set the init affinity based on pci func number */
+   i = cpumask_weight(cpumask_of_node(dev_to_node(>pdev->dev)));
+   i = i ? PCI_FUNC(hdev->pdev->devfn) % i : 0;
+   cpumask_set_cpu(cpumask_local_spread(i, dev_to_node(>pdev->dev)),
+   >affinity_mask);
+
return ret;
 }
 
@@ -2499,14 +2505,16 @@ static void hclge_mbx_task_schedule(struct hclge_dev 
*hdev)
 {
if (!test_bit(HCLGE_STATE_CMD_DISABLE, >state) &&
!test_and_set_bit(HCLGE_STATE_MBX_SERVICE_SCHED, >state))
-   schedule_work(>mbx_service_task);
+   queue_work_on(cpumask_first(>affinity_mask), system_wq,
+ >mbx_service_task);
 }
 
 static void hclge_reset_task_schedule(struct hclge_dev *hdev)
 {
if (!test_bit(HCLGE_STATE_REMOVING, >state) &&
!test_and_set_bit(HCLGE_STATE_RST_SERVICE_SCHED, >state))
-   schedule_work(>rst_service_task);
+   queue_work_on(cpumask_first(>affinity_mask), system_wq,
+ >rst_service_task);
 }
 
 static void hclge_task_schedule(struct hclge_dev *hdev)
@@ -2516,8 +2524,9 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
!test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state)) {
hdev->hw_stats.stats_timer++;
hdev->fd_arfs_expire_timer++;
-   mod_delayed_work(system_wq, >service_task,
-round_jiffies_relative(HZ));
+   mod_delayed_work_on(cpumask_first(>affinity_mask),
+   system_wq, >service_task,
+   round_jiffies_relative(HZ));
}
 }
 
@@ -2903,6 +2912,36 @@ static void hclge_get_misc_vector(struct hclge_dev *hdev)
hdev->num_msi_used += 1;
 }
 
+static void hclge_irq_affinity_notify(struct irq_affinity_notify *notify,
+ const cpumask_t *mask)
+{
+   struct hclge_dev *hdev = container_of(notify, struct hclge_dev,
+ affinity_notify);
+
+   cpumask_copy(>affinity_mask, mask);
+}
+
+static void hclge_irq_affinity_release(struct kref *ref)
+{
+}
+
+static void hclge_misc_affinity_setup(struct hclge_dev *hdev)
+{
+   irq_set_affinity_hint(hdev->misc_vector.vector_irq,
+ >affinity_mask);
+
+   hdev->affinity_notify.notify = hclge_irq_affinity_notify;
+   hdev->affinity_notify.release = hclge_irq_affinity_release;
+   irq_set_affinity_notifier(hdev->misc_vector.vector_irq,
+ >affinity_notify);
+}
+
+static void hclge_misc_affinity_teardown(struct hclge_dev *hdev)
+{
+   irq_set_affinity_notifier(hdev->misc_vector.vector_irq, NULL);
+   irq_set_affinity_hint(hdev->misc_vector.vector_irq, NULL);
+}
+
 static int hclge_misc_irq_init(struct hclge_dev *hdev)
 {
int ret;
@@ -8794,6 +8833,11 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
INIT_WORK(>rst_service_task, hclge_reset_service_task);
INIT_WORK(>mbx_service_task, hclge_mailbox_service_task);
 
+   /* Setup affinity after service timer setup because add_timer_on
+* is called in affinity notify.
+*/
+   hclge_misc_affinity_setup(hdev);
+
hclge_clear_all_event_cause(hdev);
hclge_clear_resetting_state(hdev);
 
@@ -8955,6 +8999,7 @@ static void hclge_uninit_ae_dev(struct hnae3_ae_dev 
*ae_dev)
struct hclge_dev *hdev = ae_dev->priv;
struct hclge_mac *mac = >hw.mac;
 
+   hclge_misc_affinity_teardown(hdev);
hclge_state_uninit(hdev);
 
if (mac->phydev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
index dde8f22..688e425 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h
+++ 

[PATCH V4 net-next 09/10] net: hns3: Add support for using order 1 pages with a 4K buffer

2019-07-28 Thread Huazhong Tan
From: Yunsheng Lin 

Hardware supports 0.5K, 1K, 2K, 4K RX buffer size, the
RX buffer can not be reused because the hns3_page_order
return 0 when page size and RX buffer size are both 4096.

So this patch changes the hns3_page_order to return 1 when
RX buffer is greater than half of the page size and page size
is less the 8192, and dev_alloc_pages has already been used
to allocate the compound page for RX buffer.

This patch also changes hnae3_* to hns3_* for page order
and RX buffer size calculation because they are used in
hns3 module.

Signed-off-by: Yunsheng Lin 
Reviewed-by: Peng Li 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 10 +-
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.h | 15 ---
 2 files changed, 17 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 0cf9301..d2df42d 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -2081,7 +2081,7 @@ static void hns3_set_default_feature(struct net_device 
*netdev)
 static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
 struct hns3_desc_cb *cb)
 {
-   unsigned int order = hnae3_page_order(ring);
+   unsigned int order = hns3_page_order(ring);
struct page *p;
 
p = dev_alloc_pages(order);
@@ -2092,7 +2092,7 @@ static int hns3_alloc_buffer(struct hns3_enet_ring *ring,
cb->page_offset = 0;
cb->reuse_flag = 0;
cb->buf  = page_address(p);
-   cb->length = hnae3_page_size(ring);
+   cb->length = hns3_page_size(ring);
cb->type = DESC_TYPE_PAGE;
 
return 0;
@@ -2395,7 +2395,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int 
i,
 {
struct hns3_desc *desc = >desc[ring->next_to_clean];
int size = le16_to_cpu(desc->rx.size);
-   u32 truesize = hnae3_buf_size(ring);
+   u32 truesize = hns3_buf_size(ring);
 
skb_add_rx_frag(skb, i, desc_cb->priv, desc_cb->page_offset + pull_len,
size - pull_len, truesize);
@@ -2410,7 +2410,7 @@ static void hns3_nic_reuse_page(struct sk_buff *skb, int 
i,
/* Move offset up to the next cache line */
desc_cb->page_offset += truesize;
 
-   if (desc_cb->page_offset + truesize <= hnae3_page_size(ring)) {
+   if (desc_cb->page_offset + truesize <= hns3_page_size(ring)) {
desc_cb->reuse_flag = 1;
/* Bump ref count on page before it is given */
get_page(desc_cb->priv);
@@ -2692,7 +2692,7 @@ static int hns3_add_frag(struct hns3_enet_ring *ring, 
struct hns3_desc *desc,
}
 
if (ring->tail_skb) {
-   head_skb->truesize += hnae3_buf_size(ring);
+   head_skb->truesize += hns3_buf_size(ring);
head_skb->data_len += le16_to_cpu(desc->rx.size);
head_skb->len += le16_to_cpu(desc->rx.size);
skb = ring->tail_skb;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
index 848b866..1a17856 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.h
@@ -608,9 +608,18 @@ static inline bool hns3_nic_resetting(struct net_device 
*netdev)
 
 #define tx_ring_data(priv, idx) ((priv)->ring_data[idx])
 
-#define hnae3_buf_size(_ring) ((_ring)->buf_size)
-#define hnae3_page_order(_ring) (get_order(hnae3_buf_size(_ring)))
-#define hnae3_page_size(_ring) (PAGE_SIZE << (u32)hnae3_page_order(_ring))
+#define hns3_buf_size(_ring) ((_ring)->buf_size)
+
+static inline unsigned int hns3_page_order(struct hns3_enet_ring *ring)
+{
+#if (PAGE_SIZE < 8192)
+   if (ring->buf_size > (PAGE_SIZE / 2))
+   return 1;
+#endif
+   return 0;
+}
+
+#define hns3_page_size(_ring) (PAGE_SIZE << hns3_page_order(_ring))
 
 /* iterator for handling rings in ring group */
 #define hns3_for_each_ring(pos, head) \
-- 
2.7.4



[PATCH V4 net-next 07/10] net: hns3: make hclge_service use delayed workqueue

2019-07-28 Thread Huazhong Tan
From: Yunsheng Lin 

Use delayed work instead of using timers to trigger the
hclge_serive.

Simplify the code with one less middle function and in order
to support misc irq affinity.

Signed-off-by: Yunsheng Lin 
Reviewed-by: Peng Li 
Signed-off-by: Huazhong Tan 
---
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 52 +-
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|  3 +-
 2 files changed, 21 insertions(+), 34 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 14199c4..13c9697 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -2513,8 +2513,12 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
 {
if (!test_bit(HCLGE_STATE_DOWN, >state) &&
!test_bit(HCLGE_STATE_REMOVING, >state) &&
-   !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state))
-   (void)schedule_work(>service_task);
+   !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, >state)) {
+   hdev->hw_stats.stats_timer++;
+   hdev->fd_arfs_expire_timer++;
+   mod_delayed_work(system_wq, >service_task,
+round_jiffies_relative(HZ));
+   }
 }
 
 static int hclge_get_mac_link_status(struct hclge_dev *hdev)
@@ -2729,25 +2733,6 @@ static int hclge_get_status(struct hnae3_handle *handle)
return hdev->hw.mac.link;
 }
 
-static void hclge_service_timer(struct timer_list *t)
-{
-   struct hclge_dev *hdev = from_timer(hdev, t, service_timer);
-
-   mod_timer(>service_timer, jiffies + HZ);
-   hdev->hw_stats.stats_timer++;
-   hdev->fd_arfs_expire_timer++;
-   hclge_task_schedule(hdev);
-}
-
-static void hclge_service_complete(struct hclge_dev *hdev)
-{
-   WARN_ON(!test_bit(HCLGE_STATE_SERVICE_SCHED, >state));
-
-   /* Flush memory before next watchdog */
-   smp_mb__before_atomic();
-   clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
-}
-
 static u32 hclge_check_event_cause(struct hclge_dev *hdev, u32 *clearval)
 {
u32 rst_src_reg, cmdq_src_reg, msix_src_reg;
@@ -3594,7 +3579,9 @@ static void hclge_update_vport_alive(struct hclge_dev 
*hdev)
 static void hclge_service_task(struct work_struct *work)
 {
struct hclge_dev *hdev =
-   container_of(work, struct hclge_dev, service_task);
+   container_of(work, struct hclge_dev, service_task.work);
+
+   clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
 
if (hdev->hw_stats.stats_timer >= HCLGE_STATS_TIMER_INTERVAL) {
hclge_update_stats_for_all(hdev);
@@ -3609,7 +3596,8 @@ static void hclge_service_task(struct work_struct *work)
hclge_rfs_filter_expire(hdev);
hdev->fd_arfs_expire_timer = 0;
}
-   hclge_service_complete(hdev);
+
+   hclge_task_schedule(hdev);
 }
 
 struct hclge_vport *hclge_get_vport(struct hnae3_handle *handle)
@@ -6148,10 +6136,13 @@ static void hclge_set_timer_task(struct hnae3_handle 
*handle, bool enable)
struct hclge_dev *hdev = vport->back;
 
if (enable) {
-   mod_timer(>service_timer, jiffies + HZ);
+   hclge_task_schedule(hdev);
} else {
-   del_timer_sync(>service_timer);
-   cancel_work_sync(>service_task);
+   /* Set the DOWN flag here to disable the service to be
+* scheduled again
+*/
+   set_bit(HCLGE_STATE_DOWN, >state);
+   cancel_delayed_work_sync(>service_task);
clear_bit(HCLGE_STATE_SERVICE_SCHED, >state);
}
 }
@@ -8590,12 +8581,10 @@ static void hclge_state_uninit(struct hclge_dev *hdev)
set_bit(HCLGE_STATE_DOWN, >state);
set_bit(HCLGE_STATE_REMOVING, >state);
 
-   if (hdev->service_timer.function)
-   del_timer_sync(>service_timer);
if (hdev->reset_timer.function)
del_timer_sync(>reset_timer);
-   if (hdev->service_task.func)
-   cancel_work_sync(>service_task);
+   if (hdev->service_task.work.func)
+   cancel_delayed_work_sync(>service_task);
if (hdev->rst_service_task.func)
cancel_work_sync(>rst_service_task);
if (hdev->mbx_service_task.func)
@@ -8800,9 +8789,8 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
 
hclge_dcb_ops_set(hdev);
 
-   timer_setup(>service_timer, hclge_service_timer, 0);
timer_setup(>reset_timer, hclge_reset_timer, 0);
-   INIT_WORK(>service_task, hclge_service_task);
+   INIT_DELAYED_WORK(>service_task, hclge_service_task);
INIT_WORK(>rst_service_task, hclge_reset_service_task);
INIT_WORK(>mbx_service_task, hclge_mailbox_service_task);
 
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.h 

[PATCH V4 net-next 05/10] net: hns3: modify firmware version display format

2019-07-28 Thread Huazhong Tan
From: Yufeng Mo 

This patch modifies firmware version display format in
hclge(vf)_cmd_init() and hns3_get_drvinfo(). Also, adds
some optimizations for firmware version display format.

Signed-off-by: Yufeng Mo 
Signed-off-by: Peng Li 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.h  |  9 +
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c   | 15 +--
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c   | 10 +-
 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 10 +-
 4 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 48c7b70..a4624db 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -179,6 +179,15 @@ struct hnae3_vector_info {
 #define HNAE3_RING_GL_RX 0
 #define HNAE3_RING_GL_TX 1
 
+#define HNAE3_FW_VERSION_BYTE3_SHIFT   24
+#define HNAE3_FW_VERSION_BYTE3_MASKGENMASK(31, 24)
+#define HNAE3_FW_VERSION_BYTE2_SHIFT   16
+#define HNAE3_FW_VERSION_BYTE2_MASKGENMASK(23, 16)
+#define HNAE3_FW_VERSION_BYTE1_SHIFT   8
+#define HNAE3_FW_VERSION_BYTE1_MASKGENMASK(15, 8)
+#define HNAE3_FW_VERSION_BYTE0_SHIFT   0
+#define HNAE3_FW_VERSION_BYTE0_MASKGENMASK(7, 0)
+
 struct hnae3_ring_chain_node {
struct hnae3_ring_chain_node *next;
u32 tqp_index;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index 5bff98a..e71c92b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -527,6 +527,7 @@ static void hns3_get_drvinfo(struct net_device *netdev,
 {
struct hns3_nic_priv *priv = netdev_priv(netdev);
struct hnae3_handle *h = priv->ae_handle;
+   u32 fw_version;
 
if (!h->ae_algo->ops->get_fw_version) {
netdev_err(netdev, "could not get fw version!\n");
@@ -545,8 +546,18 @@ static void hns3_get_drvinfo(struct net_device *netdev,
sizeof(drvinfo->bus_info));
drvinfo->bus_info[ETHTOOL_BUSINFO_LEN - 1] = '\0';
 
-   snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version), "0x%08x",
-priv->ae_handle->ae_algo->ops->get_fw_version(h));
+   fw_version = priv->ae_handle->ae_algo->ops->get_fw_version(h);
+
+   snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
+"%lu.%lu.%lu.%lu",
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE2_MASK,
+HNAE3_FW_VERSION_BYTE2_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE1_MASK,
+HNAE3_FW_VERSION_BYTE1_SHIFT),
+hnae3_get_field(fw_version, HNAE3_FW_VERSION_BYTE0_MASK,
+HNAE3_FW_VERSION_BYTE0_SHIFT));
 }
 
 static u32 hns3_get_link(struct net_device *netdev)
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
index 22f6acd..d9858f2 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
@@ -419,7 +419,15 @@ int hclge_cmd_init(struct hclge_dev *hdev)
}
hdev->fw_version = version;
 
-   dev_info(>pdev->dev, "The firmware version is %08x\n", version);
+   dev_info(>pdev->dev, "The firmware version is %lu.%lu.%lu.%lu\n",
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE2_MASK,
+HNAE3_FW_VERSION_BYTE2_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE1_MASK,
+HNAE3_FW_VERSION_BYTE1_SHIFT),
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE0_MASK,
+HNAE3_FW_VERSION_BYTE0_SHIFT));
 
return 0;
 
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
index 652b796..8f21eb3 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
@@ -405,7 +405,15 @@ int hclgevf_cmd_init(struct hclgevf_dev *hdev)
}
hdev->fw_version = version;
 
-   dev_info(>pdev->dev, "The firmware version is %08x\n", version);
+   dev_info(>pdev->dev, "The firmware version is %lu.%lu.%lu.%lu\n",
+hnae3_get_field(version, HNAE3_FW_VERSION_BYTE3_MASK,
+HNAE3_FW_VERSION_BYTE3_SHIFT),
+hnae3_get_field(version, 

[PATCH V4 net-next 04/10] net: hns3: change GFP flag during lock period

2019-07-28 Thread Huazhong Tan
From: Yufeng Mo 

When allocating memory, the GFP_KERNEL cannot be used during the
spin_lock period. This is because it may cause scheduling when holding
spin_lock. This patch changes GFP flag to GFP_ATOMIC in this case.

Fixes: dd74f815dd41 ("net: hns3: Add support for rule add/delete for flow 
director")
Signed-off-by: Yufeng Mo 
Signed-off-by: lipeng 00277521 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3c64d70..14199c4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -5796,7 +5796,7 @@ static int hclge_add_fd_entry_by_arfs(struct hnae3_handle 
*handle, u16 queue_id,
return -ENOSPC;
}
 
-   rule = kzalloc(sizeof(*rule), GFP_KERNEL);
+   rule = kzalloc(sizeof(*rule), GFP_ATOMIC);
if (!rule) {
spin_unlock_bh(>fd_rule_lock);
 
-- 
2.7.4



[PATCH V4 net-next 06/10] net: hns3: add debug messages to identify eth down cause

2019-07-28 Thread Huazhong Tan
From: Yonglong Liu 

Some times just see the eth interface have been down/up via
dmesg, but can not know why the eth down. So adds some debug
messages to identify the cause for this.

Signed-off-by: Yonglong Liu 
Signed-off-by: Peng Li 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c   | 18 ++
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c| 19 +++
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c| 11 +++
 3 files changed, 48 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4d58c53..0cf9301 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -459,6 +459,9 @@ static int hns3_nic_net_open(struct net_device *netdev)
h->ae_algo->ops->set_timer_task(priv->ae_handle, true);
 
hns3_config_xps(priv);
+
+   netif_dbg(h, drv, netdev, "net open\n");
+
return 0;
 }
 
@@ -519,6 +522,8 @@ static int hns3_nic_net_stop(struct net_device *netdev)
if (test_and_set_bit(HNS3_NIC_STATE_DOWN, >state))
return 0;
 
+   netif_dbg(h, drv, netdev, "net stop\n");
+
if (h->ae_algo->ops->set_timer_task)
h->ae_algo->ops->set_timer_task(priv->ae_handle, false);
 
@@ -1550,6 +1555,8 @@ static int hns3_setup_tc(struct net_device *netdev, void 
*type_data)
h = hns3_get_handle(netdev);
kinfo = >kinfo;
 
+   netif_dbg(h, drv, netdev, "setup tc: num_tc=%u\n", tc);
+
return (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
 }
@@ -1593,6 +1600,10 @@ static int hns3_ndo_set_vf_vlan(struct net_device 
*netdev, int vf, u16 vlan,
struct hnae3_handle *h = hns3_get_handle(netdev);
int ret = -EIO;
 
+   netif_dbg(h, drv, netdev,
+ "set vf vlan: vf=%d, vlan=%u, qos=%u, vlan_proto=%u\n",
+ vf, vlan, qos, vlan_proto);
+
if (h->ae_algo->ops->set_vf_vlan_filter)
ret = h->ae_algo->ops->set_vf_vlan_filter(h, vf, vlan,
  qos, vlan_proto);
@@ -1611,6 +1622,9 @@ static int hns3_nic_change_mtu(struct net_device *netdev, 
int new_mtu)
if (!h->ae_algo->ops->set_mtu)
return -EOPNOTSUPP;
 
+   netif_dbg(h, drv, netdev,
+ "change mtu from %u to %d\n", netdev->mtu, new_mtu);
+
ret = h->ae_algo->ops->set_mtu(h, new_mtu);
if (ret)
netdev_err(netdev, "failed to change MTU in hardware %d\n",
@@ -4395,6 +4409,10 @@ int hns3_set_channels(struct net_device *netdev,
if (kinfo->rss_size == new_tqp_num)
return 0;
 
+   netif_dbg(h, drv, netdev,
+ "set channels: tqp_num=%u, rxfh=%d\n",
+ new_tqp_num, rxfh_configured);
+
ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT);
if (ret)
return ret;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
index e71c92b..fe0f82a 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
@@ -311,6 +311,8 @@ static void hns3_self_test(struct net_device *ndev,
if (eth_test->flags != ETH_TEST_FL_OFFLINE)
return;
 
+   netif_dbg(h, drv, ndev, "self test start");
+
st_param[HNAE3_LOOP_APP][0] = HNAE3_LOOP_APP;
st_param[HNAE3_LOOP_APP][1] =
h->flags & HNAE3_SUPPORT_APP_LOOPBACK;
@@ -374,6 +376,8 @@ static void hns3_self_test(struct net_device *ndev,
 
if (if_running)
ndev->netdev_ops->ndo_open(ndev);
+
+   netif_dbg(h, drv, ndev, "self test end\n");
 }
 
 static int hns3_get_sset_count(struct net_device *netdev, int stringset)
@@ -604,6 +608,10 @@ static int hns3_set_pauseparam(struct net_device *netdev,
 {
struct hnae3_handle *h = hns3_get_handle(netdev);
 
+   netif_dbg(h, drv, netdev,
+ "set pauseparam: autoneg=%u, rx:%u, tx:%u\n",
+ param->autoneg, param->rx_pause, param->tx_pause);
+
if (h->ae_algo->ops->set_pauseparam)
return h->ae_algo->ops->set_pauseparam(h, param->autoneg,
   param->rx_pause,
@@ -743,6 +751,11 @@ static int hns3_set_link_ksettings(struct net_device 
*netdev,
if (cmd->base.speed == SPEED_1000 && cmd->base.duplex == DUPLEX_HALF)
return -EINVAL;
 
+   netif_dbg(handle, drv, netdev,
+ "set link(%s): autoneg=%u, speed=%u, duplex=%u\n",
+ netdev->phydev ? "phy" : "mac",
+ cmd->base.autoneg, cmd->base.speed, cmd->base.duplex);
+
/* Only support ksettings_set for netdev with phy attached for now */
  

[PATCH V4 net-next 10/10] net: hns3: use dev_info() instead of pr_info()

2019-07-28 Thread Huazhong Tan
dev_info() is more appropriate for printing messages when driver
initialization done, so switch to dev_info().

Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c   | 4 +++-
 drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 30a7074..4138780 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -8862,7 +8862,9 @@ static int hclge_init_ae_dev(struct hnae3_ae_dev *ae_dev)
hclge_state_init(hdev);
hdev->last_reset_time = jiffies;
 
-   pr_info("%s driver initialization finished.\n", HCLGE_DRIVER_NAME);
+   dev_info(>pdev->dev, "%s driver initialization finished.\n",
+HCLGE_DRIVER_NAME);
+
return 0;
 
 err_mdiobus_unreg:
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
index a13a0e1..ae0e6a6 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c
@@ -2695,7 +2695,8 @@ static int hclgevf_init_hdev(struct hclgevf_dev *hdev)
}
 
hdev->last_reset_time = jiffies;
-   pr_info("finished initializing %s driver\n", HCLGEVF_DRIVER_NAME);
+   dev_info(>pdev->dev, "finished initializing %s driver\n",
+HCLGEVF_DRIVER_NAME);
 
return 0;
 
-- 
2.7.4



[PATCH V4 net-next 03/10] net: hns3: remove upgrade reset level when reset fail

2019-07-28 Thread Huazhong Tan
Currently, hclge_reset_err_handle() will assert a global reset
when the failing count is smaller than MAX_RESET_FAIL_CNT, which
will affect other running functions.

So this patch removes this upgrading, and uses re-scheduling reset
task to do it.

Signed-off-by: Huazhong Tan 
Reviewed-by: Yunsheng Lin 
---
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 28 +++---
 1 file changed, 8 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
index 3fde5471..3c64d70 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
@@ -3305,7 +3305,7 @@ static int hclge_reset_prepare_wait(struct hclge_dev 
*hdev)
return ret;
 }
 
-static bool hclge_reset_err_handle(struct hclge_dev *hdev, bool is_timeout)
+static bool hclge_reset_err_handle(struct hclge_dev *hdev)
 {
 #define MAX_RESET_FAIL_CNT 5
 
@@ -3322,20 +3322,11 @@ static bool hclge_reset_err_handle(struct hclge_dev 
*hdev, bool is_timeout)
return false;
} else if (hdev->reset_fail_cnt < MAX_RESET_FAIL_CNT) {
hdev->reset_fail_cnt++;
-   if (is_timeout) {
-   set_bit(hdev->reset_type, >reset_pending);
-   dev_info(>pdev->dev,
-"re-schedule to wait for hw reset done\n");
-   return true;
-   }
-
-   dev_info(>pdev->dev, "Upgrade reset level\n");
-   hclge_clear_reset_cause(hdev);
-   set_bit(HNAE3_GLOBAL_RESET, >default_reset_request);
-   mod_timer(>reset_timer,
- jiffies + HCLGE_RESET_INTERVAL);
-
-   return false;
+   set_bit(hdev->reset_type, >reset_pending);
+   dev_info(>pdev->dev,
+"re-schedule reset task(%d)\n",
+hdev->reset_fail_cnt);
+   return true;
}
 
hclge_clear_reset_cause(hdev);
@@ -3382,7 +3373,6 @@ static int hclge_reset_stack(struct hclge_dev *hdev)
 static void hclge_reset(struct hclge_dev *hdev)
 {
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(hdev->pdev);
-   bool is_timeout = false;
int ret;
 
/* Initialize ae_dev reset status as well, in case enet layer wants to
@@ -3410,10 +3400,8 @@ static void hclge_reset(struct hclge_dev *hdev)
if (ret)
goto err_reset;
 
-   if (hclge_reset_wait(hdev)) {
-   is_timeout = true;
+   if (hclge_reset_wait(hdev))
goto err_reset;
-   }
 
hdev->rst_stats.hw_reset_done_cnt++;
 
@@ -3465,7 +3453,7 @@ static void hclge_reset(struct hclge_dev *hdev)
 err_reset_lock:
rtnl_unlock();
 err_reset:
-   if (hclge_reset_err_handle(hdev, is_timeout))
+   if (hclge_reset_err_handle(hdev))
hclge_reset_task_schedule(hdev);
 }
 
-- 
2.7.4



[PATCH V4 net-next 00/10] net: hns3: some code optimizations & bugfixes & features

2019-07-28 Thread Huazhong Tan
This patch-set includes code optimizations, bugfixes and features for
the HNS3 ethernet controller driver.

[patch 1/10] checks reset status before setting channel.

[patch 2/10] adds a NULL pointer checking.

[patch 3/10] removes reset level upgrading when current reset fails.

[patch 4/10] fixes a GFP flags errors when holding spin_lock.

[patch 5/10] modifies firmware version format.

[patch 6/10] adds some print information which is off by default.

[patch 7/10 - 8/10] adds two code optimizations about interrupt handler
and work task.

[patch 9/10] adds support for using order 1 pages with a 4K buffer.

[patch 10/10] modifies messages prints with dev_info() instead of
pr_info().

Change log:
V3->V4: replace netif_info with netif_dbg in [patch 6/10]
V2->V3: fixes comments from Saeed Mahameed and Joe Perches.
V1->V2: fixes comments from Saeed Mahameed and
removes previous [patch 4/11] and [patch 11/11]
which needs further discussion, and adds a new
patch [10/10] suggested by Saeed Mahameed.

Guangbin Huang (1):
  net: hns3: add a check for get_reset_level

Huazhong Tan (2):
  net: hns3: remove upgrade reset level when reset fail
  net: hns3: use dev_info() instead of pr_info()

Jian Shen (1):
  net: hns3: add reset checking before set channels

Yonglong Liu (1):
  net: hns3: add debug messages to identify eth down cause

Yufeng Mo (2):
  net: hns3: change GFP flag during lock period
  net: hns3: modify firmware version display format

Yunsheng Lin (3):
  net: hns3: make hclge_service use delayed workqueue
  net: hns3: add interrupt affinity support for misc interrupt
  net: hns3: Add support for using order 1 pages with a 4K buffer

 drivers/net/ethernet/hisilicon/hns3/hnae3.h|   9 ++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c|  33 -
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.h|  15 ++-
 drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c |  34 +-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c |  10 +-
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c |  11 ++
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c| 135 -
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|   7 +-
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c   |  10 +-
 .../ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c  |   3 +-
 10 files changed, 195 insertions(+), 72 deletions(-)

-- 
2.7.4



[PATCH V4 net-next 01/10] net: hns3: add reset checking before set channels

2019-07-28 Thread Huazhong Tan
From: Jian Shen 

hns3_set_channels() should check the resetting status firstly,
since the device will reinitialize when resetting. If the
reset has not completed, the hns3_set_channels() may access
invalid memory.

Signed-off-by: Jian Shen 
Signed-off-by: Huazhong Tan 
---
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 69f7ef8..08af782 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -4378,6 +4378,9 @@ int hns3_set_channels(struct net_device *netdev,
u16 org_tqp_num;
int ret;
 
+   if (hns3_nic_resetting(netdev))
+   return -EBUSY;
+
if (ch->rx_count || ch->tx_count)
return -EINVAL;
 
-- 
2.7.4



[PATCH] scsi: megaraid: Fix possible null-pointer dereferences in megasas_complete_cmd()

2019-07-28 Thread Jia-Ju Bai
In megasas_complete_cmd(), there is an if statement on line 3411 to
check whether cmd->scmd is NULL:
if (cmd->scmd)

When cmd->scmd is NULL, it is used at some places, such as on line 3286:
cmd->scmd->result = alt_status << 16;
on line 3295:
cmd->scmd->scsi_done(cmd->scmd);
on line 3343:
cmd->scmd->scsi_done(cmd->scmd);

Thus, possible null-pointer dereferences may occur.

To fix these bugs, cmd->scmd is checked before being used.

These bugs are found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai 
---
 drivers/scsi/megaraid/megaraid_sas_base.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c 
b/drivers/scsi/megaraid/megaraid_sas_base.c
index b2339d04a700..181c4d9cd707 100644
--- a/drivers/scsi/megaraid/megaraid_sas_base.c
+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
@@ -3440,6 +3440,9 @@ megasas_complete_cmd(struct megasas_instance *instance, 
struct megasas_cmd *cmd,
case MFI_CMD_LD_READ:
case MFI_CMD_LD_WRITE:
 
+   if (!cmd->scmd)
+   break;
+
if (alt_status) {
cmd->scmd->result = alt_status << 16;
exception = 1;
-- 
2.17.0



[PATCH net] net: ipv6: Fix a bug in ndisc_send_ns when netdev only has a global address

2019-07-28 Thread Su Yanjun
When we send mpls packets and the interface only has a
manual global ipv6 address, then the two hosts cant communicate.
I find that in ndisc_send_ns it only tries to get a ll address.
In my case, the executive path is as below.
ip6_output
 ->ip6_finish_output
  ->lwtunnel_xmit
   ->mpls_xmit
->neigh_resolve_output
 ->neigh_probe
  ->ndisc_solicit
   ->ndisc_send_ns

In RFC4861, 7.2.2 says
"If the source address of the packet prompting the solicitation is the
same as one of the addresses assigned to the outgoing interface, that
address SHOULD be placed in the IP Source Address of the outgoing
solicitation.  Otherwise, any one of the addresses assigned to the
interface should be used."

In this patch we try get a global address if we get ll address failed.

Signed-off-by: Su Yanjun 
---
 include/net/addrconf.h |  4 
 net/ipv6/addrconf.c| 34 ++
 net/ipv6/ndisc.c   |  8 ++--
 3 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index becdad5..006db8e 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -107,6 +107,10 @@ int __ipv6_get_lladdr(struct inet6_dev *idev, struct 
in6_addr *addr,
  u32 banned_flags);
 int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
u32 banned_flags);
+int __ipv6_get_addr(struct inet6_dev *idev, struct in6_addr *addr,
+ u32 banned_flags);
+int ipv6_get_addr(struct net_device *dev, struct in6_addr *addr,
+   u32 banned_flags);
 bool inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
  bool match_wildcard);
 bool inet_rcv_saddr_any(const struct sock *sk);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 521e320..4c0a43f 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1870,6 +1870,40 @@ int ipv6_get_lladdr(struct net_device *dev, struct 
in6_addr *addr,
return err;
 }
 
+int __ipv6_get_addr(struct inet6_dev *idev, struct in6_addr *addr,
+   u32 banned_flags)
+{
+   struct inet6_ifaddr *ifp;
+   int err = -EADDRNOTAVAIL;
+
+   list_for_each_entry_reverse(ifp, >addr_list, if_list) {
+   if (ifp->scope == 0 &&
+   !(ifp->flags & banned_flags)) {
+   *addr = ifp->addr;
+   err = 0;
+   break;
+   }
+   }
+   return err;
+}
+
+int ipv6_get_addr(struct net_device *dev, struct in6_addr *addr,
+ u32 banned_flags)
+{
+   struct inet6_dev *idev;
+   int err = -EADDRNOTAVAIL;
+
+   rcu_read_lock();
+   idev = __in6_dev_get(dev);
+   if (idev) {
+   read_lock_bh(>lock);
+   err = __ipv6_get_addr(idev, addr, banned_flags);
+   read_unlock_bh(>lock);
+   }
+   rcu_read_unlock();
+   return err;
+}
+
 static int ipv6_count_addresses(const struct inet6_dev *idev)
 {
const struct inet6_ifaddr *ifp;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 083cc1c..18ac2fb 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -606,8 +606,12 @@ void ndisc_send_ns(struct net_device *dev, const struct 
in6_addr *solicit,
 
if (!saddr) {
if (ipv6_get_lladdr(dev, _buf,
-  (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)))
-   return;
+  (IFA_F_TENTATIVE | IFA_F_OPTIMISTIC))) {
+   /* try global address */
+   if (ipv6_get_addr(dev, _buf,
+ (IFA_F_TENTATIVE | IFA_F_OPTIMISTIC)))
+   return;
+   }
saddr = _buf;
}
 
-- 
2.7.4





Re: [PATCH] mailbox: imx: add support for imx v1 mu

2019-07-28 Thread Dong Aisheng
On Mon, Jul 29, 2019 at 10:36 AM Richard Zhu  wrote:
>
> There is a version1.0 MU on i.MX7ULP platform.
> One new version ID register is added, and it's offset is 0.
> TRn registers are defined at the offset 0x20 ~ 0x2C.
> RRn registers are defined at the offset 0x40 ~ 0x4C.
> SR/CR registers are defined at 0x60/0x64.
> Extend this driver to support it.
>

If only the register base offset is different, there's probably a more
simple way.
Please refer to:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/tty/serial/fsl_lpuart.c?id=24b1e5f0e83c2aced8096473d20c4cf6c1355f30

Regards
Aisheng

> Signed-off-by: Richard Zhu 
> ---
>  drivers/mailbox/imx-mailbox.c | 67 
> ---
>  1 file changed, 50 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
> index 25be8bb..8423a38 100644
> --- a/drivers/mailbox/imx-mailbox.c
> +++ b/drivers/mailbox/imx-mailbox.c
> @@ -12,19 +12,11 @@
>  #include 
>  #include 
>
> -/* Transmit Register */
> -#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
> -/* Receive Register */
> -#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
> -/* Status Register */
> -#define IMX_MU_xSR 0x20
>  #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
>  #define IMX_MU_xSR_RFn(x)  BIT(24 + (3 - (x)))
>  #define IMX_MU_xSR_TEn(x)  BIT(20 + (3 - (x)))
>  #define IMX_MU_xSR_BRDIP   BIT(9)
>
> -/* Control Register */
> -#define IMX_MU_xCR 0x24
>  /* General Purpose Interrupt Enable */
>  #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
>  /* Receive Interrupt Enable */
> @@ -44,6 +36,13 @@ enum imx_mu_chan_type {
> IMX_MU_TYPE_RXDB,   /* Rx doorbell */
>  };
>
> +struct imx_mu_dcfg {
> +   u32 xTR[4]; /* Transmit Registers */
> +   u32 xRR[4]; /* Receive Registers */
> +   u32 xSR;/* Status Register */
> +   u32 xCR;/* Control Register */
> +};
> +
>  struct imx_mu_con_priv {
> unsigned intidx;
> charirq_desc[IMX_MU_CHAN_NAME_SIZE];
> @@ -61,12 +60,39 @@ struct imx_mu_priv {
> struct mbox_chanmbox_chans[IMX_MU_CHANS];
>
> struct imx_mu_con_priv  con_priv[IMX_MU_CHANS];
> +   const struct imx_mu_dcfg*dcfg;
> struct clk  *clk;
> int irq;
>
> boolside_b;
>  };
>
> +static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
> +   .xTR[0] = 0x0,
> +   .xTR[1] = 0x4,
> +   .xTR[2] = 0x8,
> +   .xTR[3] = 0xC,
> +   .xRR[0] = 0x10,
> +   .xRR[1] = 0x14,
> +   .xRR[2] = 0x18,
> +   .xRR[3] = 0x1C,
> +   .xSR= 0x20,
> +   .xCR= 0x24,
> +};
> +
> +static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
> +   .xTR[0] = 0x20,
> +   .xTR[1] = 0x24,
> +   .xTR[2] = 0x28,
> +   .xTR[3] = 0x2C,
> +   .xRR[0] = 0x40,
> +   .xRR[1] = 0x44,
> +   .xRR[2] = 0x48,
> +   .xRR[3] = 0x4C,
> +   .xSR= 0x60,
> +   .xCR= 0x64,
> +};
> +
>  static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
>  {
> return container_of(mbox, struct imx_mu_priv, mbox);
> @@ -88,10 +114,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32 
> set, u32 clr)
> u32 val;
>
> spin_lock_irqsave(>xcr_lock, flags);
> -   val = imx_mu_read(priv, IMX_MU_xCR);
> +   val = imx_mu_read(priv, priv->dcfg->xCR);
> val &= ~clr;
> val |= set;
> -   imx_mu_write(priv, val, IMX_MU_xCR);
> +   imx_mu_write(priv, val, priv->dcfg->xCR);
> spin_unlock_irqrestore(>xcr_lock, flags);
>
> return val;
> @@ -111,8 +137,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
> struct imx_mu_con_priv *cp = chan->con_priv;
> u32 val, ctrl, dat;
>
> -   ctrl = imx_mu_read(priv, IMX_MU_xCR);
> -   val = imx_mu_read(priv, IMX_MU_xSR);
> +   ctrl = imx_mu_read(priv, priv->dcfg->xCR);
> +   val = imx_mu_read(priv, priv->dcfg->xSR);
>
> switch (cp->type) {
> case IMX_MU_TYPE_TX:
> @@ -138,10 +164,10 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
> imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
> mbox_chan_txdone(chan, 0);
> } else if (val == IMX_MU_xSR_RFn(cp->idx)) {
> -   dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
> +   dat = imx_mu_read(priv, priv->dcfg->xRR[cp->idx]);
> mbox_chan_received_data(chan, (void *));
> } else if (val == IMX_MU_xSR_GIPn(cp->idx)) {
> -   imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), IMX_MU_xSR);
> +   imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), priv->dcfg->xSR);
> mbox_chan_received_data(chan, NULL);
> } else {
> dev_warn_ratelimited(priv->dev, "Not handled 

[PATCH] mailbox: imx: add support for imx v1 mu

2019-07-28 Thread Richard Zhu
There is a version1.0 MU on i.MX7ULP platform.
One new version ID register is added, and it's offset is 0.
TRn registers are defined at the offset 0x20 ~ 0x2C.
RRn registers are defined at the offset 0x40 ~ 0x4C.
SR/CR registers are defined at 0x60/0x64.
Extend this driver to support it.

Signed-off-by: Richard Zhu 
---
 drivers/mailbox/imx-mailbox.c | 67 ---
 1 file changed, 50 insertions(+), 17 deletions(-)

diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 25be8bb..8423a38 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -12,19 +12,11 @@
 #include 
 #include 
 
-/* Transmit Register */
-#define IMX_MU_xTRn(x) (0x00 + 4 * (x))
-/* Receive Register */
-#define IMX_MU_xRRn(x) (0x10 + 4 * (x))
-/* Status Register */
-#define IMX_MU_xSR 0x20
 #define IMX_MU_xSR_GIPn(x) BIT(28 + (3 - (x)))
 #define IMX_MU_xSR_RFn(x)  BIT(24 + (3 - (x)))
 #define IMX_MU_xSR_TEn(x)  BIT(20 + (3 - (x)))
 #define IMX_MU_xSR_BRDIP   BIT(9)
 
-/* Control Register */
-#define IMX_MU_xCR 0x24
 /* General Purpose Interrupt Enable */
 #define IMX_MU_xCR_GIEn(x) BIT(28 + (3 - (x)))
 /* Receive Interrupt Enable */
@@ -44,6 +36,13 @@ enum imx_mu_chan_type {
IMX_MU_TYPE_RXDB,   /* Rx doorbell */
 };
 
+struct imx_mu_dcfg {
+   u32 xTR[4]; /* Transmit Registers */
+   u32 xRR[4]; /* Receive Registers */
+   u32 xSR;/* Status Register */
+   u32 xCR;/* Control Register */
+};
+
 struct imx_mu_con_priv {
unsigned intidx;
charirq_desc[IMX_MU_CHAN_NAME_SIZE];
@@ -61,12 +60,39 @@ struct imx_mu_priv {
struct mbox_chanmbox_chans[IMX_MU_CHANS];
 
struct imx_mu_con_priv  con_priv[IMX_MU_CHANS];
+   const struct imx_mu_dcfg*dcfg;
struct clk  *clk;
int irq;
 
boolside_b;
 };
 
+static const struct imx_mu_dcfg imx_mu_cfg_imx6sx = {
+   .xTR[0] = 0x0,
+   .xTR[1] = 0x4,
+   .xTR[2] = 0x8,
+   .xTR[3] = 0xC,
+   .xRR[0] = 0x10,
+   .xRR[1] = 0x14,
+   .xRR[2] = 0x18,
+   .xRR[3] = 0x1C,
+   .xSR= 0x20,
+   .xCR= 0x24,
+};
+
+static const struct imx_mu_dcfg imx_mu_cfg_imx7ulp = {
+   .xTR[0] = 0x20,
+   .xTR[1] = 0x24,
+   .xTR[2] = 0x28,
+   .xTR[3] = 0x2C,
+   .xRR[0] = 0x40,
+   .xRR[1] = 0x44,
+   .xRR[2] = 0x48,
+   .xRR[3] = 0x4C,
+   .xSR= 0x60,
+   .xCR= 0x64,
+};
+
 static struct imx_mu_priv *to_imx_mu_priv(struct mbox_controller *mbox)
 {
return container_of(mbox, struct imx_mu_priv, mbox);
@@ -88,10 +114,10 @@ static u32 imx_mu_xcr_rmw(struct imx_mu_priv *priv, u32 
set, u32 clr)
u32 val;
 
spin_lock_irqsave(>xcr_lock, flags);
-   val = imx_mu_read(priv, IMX_MU_xCR);
+   val = imx_mu_read(priv, priv->dcfg->xCR);
val &= ~clr;
val |= set;
-   imx_mu_write(priv, val, IMX_MU_xCR);
+   imx_mu_write(priv, val, priv->dcfg->xCR);
spin_unlock_irqrestore(>xcr_lock, flags);
 
return val;
@@ -111,8 +137,8 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
struct imx_mu_con_priv *cp = chan->con_priv;
u32 val, ctrl, dat;
 
-   ctrl = imx_mu_read(priv, IMX_MU_xCR);
-   val = imx_mu_read(priv, IMX_MU_xSR);
+   ctrl = imx_mu_read(priv, priv->dcfg->xCR);
+   val = imx_mu_read(priv, priv->dcfg->xSR);
 
switch (cp->type) {
case IMX_MU_TYPE_TX:
@@ -138,10 +164,10 @@ static irqreturn_t imx_mu_isr(int irq, void *p)
imx_mu_xcr_rmw(priv, 0, IMX_MU_xCR_TIEn(cp->idx));
mbox_chan_txdone(chan, 0);
} else if (val == IMX_MU_xSR_RFn(cp->idx)) {
-   dat = imx_mu_read(priv, IMX_MU_xRRn(cp->idx));
+   dat = imx_mu_read(priv, priv->dcfg->xRR[cp->idx]);
mbox_chan_received_data(chan, (void *));
} else if (val == IMX_MU_xSR_GIPn(cp->idx)) {
-   imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), IMX_MU_xSR);
+   imx_mu_write(priv, IMX_MU_xSR_GIPn(cp->idx), priv->dcfg->xSR);
mbox_chan_received_data(chan, NULL);
} else {
dev_warn_ratelimited(priv->dev, "Not handled interrupt\n");
@@ -159,7 +185,7 @@ static int imx_mu_send_data(struct mbox_chan *chan, void 
*data)
 
switch (cp->type) {
case IMX_MU_TYPE_TX:
-   imx_mu_write(priv, *arg, IMX_MU_xTRn(cp->idx));
+   imx_mu_write(priv, *arg, priv->dcfg->xTR[cp->idx]);
imx_mu_xcr_rmw(priv, IMX_MU_xCR_TIEn(cp->idx), 0);
break;
case IMX_MU_TYPE_TXDB:
@@ -257,7 +283,7 @@ static void imx_mu_init_generic(struct imx_mu_priv *priv)
return;
 
/* Set default MU configuration */
-   

[PATCH] target: iscsi: iscsi_target_tpg: Fix a possible null-pointer dereference in iscsit_tpg_add_network_portal()

2019-07-28 Thread Jia-Ju Bai
In iscsit_tpg_add_network_portal(), there is an if statement on line 496
to check whether tpg->tpg_tiqn is NULL:
if (tpg->tpg_tiqn)

When tpg->tpg_tiqn is NULL, it is used on line 508:
pr_debug(..., tpg->tpg_tiqn->tiqn, ...);

Thus, a possible null-pointer dereference may occur.

To fix this bug, tpg->tpg_tiqn is checked before being used.

This bug is found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai 
---
 drivers/target/iscsi/iscsi_target_tpg.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/target/iscsi/iscsi_target_tpg.c 
b/drivers/target/iscsi/iscsi_target_tpg.c
index 8075f60fd02c..bf97be36ec1f 100644
--- a/drivers/target/iscsi/iscsi_target_tpg.c
+++ b/drivers/target/iscsi/iscsi_target_tpg.c
@@ -505,9 +505,11 @@ struct iscsi_tpg_np *iscsit_tpg_add_network_portal(
spin_unlock(_np_parent->tpg_np_parent_lock);
}
 
-   pr_debug("CORE[%s] - Added Network Portal: %pISpc,%hu on %s\n",
-   tpg->tpg_tiqn->tiqn, >np_sockaddr, tpg->tpgt,
-   np->np_transport->name);
+   if (tpg->tpg_tiqn) {
+   pr_debug("CORE[%s] - Added Network Portal: %pISpc,%hu on %s\n",
+   tpg->tpg_tiqn->tiqn, >np_sockaddr, tpg->tpgt,
+   np->np_transport->name);
+   }
 
return tpg_np;
 }
-- 
2.17.0



Re: [PATCH v2] kbuild: Fail if gold linker is detected

2019-07-28 Thread Masahiro Yamada
On Tue, Jul 23, 2019 at 5:17 PM Thomas Gleixner  wrote:
>
> On Tue, 23 Jul 2019, Thomas Gleixner wrote:
> > On Tue, 23 Jul 2019, Masahiro Yamada wrote:
> > > Right.
> > > I was able to build with ld.gold
> > >
> > > So, we can use gold, depending on the kernel configuration.
> >
> > That's exactly the problem. It breaks with random kernel configurations
> > which is not acceptable except for people who know what they are doing.
> >
> > I'm tired of dealing with half baken fixes and 'regression' reports. Either
> > there is an effort to fix the issues with gold like the clang people fix
> > their issues or it needs to be disabled. We have a clear statement that
> > gold developers have other priorities.
>
> That said, I'm perfectly happy to move this to x86 and leave it alone for
> other architectures, but it does not make sense to me.


I did not see opposition from other arch maintainers.


> If the gold fans care enough, then we can add something like
> CONFIG_I_WANT_TO_USE_GOLD_AND_DEAL_WITH_THE_FALLOUT_MYSELF.

Let's apply this and see.

If somebody really wants to use gold by his risk,
I will consider such a config option.


Applied to linux-kbuild.
Thanks.


-- 
Best Regards
Masahiro Yamada


Re: [PATCH V2] Kbuild: Handle PREEMPT_RT for version string and magic

2019-07-28 Thread Masahiro Yamada
On Mon, Jul 29, 2019 at 3:27 AM Thomas Gleixner  wrote:
>
> Update the build scripts and the version magic to reflect when
> CONFIG_PREEMPT_RT is enabled in the same way as CONFIG_PREEMPT is treated.
>
> The resulting version strings:
>
>   Linux m 5.3.0-rc1+ #100 SMP Fri Jul 26 ...
>   Linux m 5.3.0-rc1+ #101 SMP PREEMPT Fri Jul 26 ...
>   Linux m 5.3.0-rc1+ #102 SMP PREEMPT_RT Fri Jul 26 ...
>
> The module vermagic:
>
>   5.3.0-rc1+ SMP mod_unload modversions
>   5.3.0-rc1+ SMP preempt mod_unload modversions
>   5.3.0-rc1+ SMP preempt_rt mod_unload modversions
>
> Signed-off-by: Thomas Gleixner 
> Cc: Masahiro Yamada 
> Cc: Michal Marek 
> Cc: linux-kbu...@vger.kernel.org
> ---
> V2: Simplify the ifdeffery as pointed out by Masahiro


Applied to linux-kbuild.
Thanks.

-- 
Best Regards
Masahiro Yamada


[PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()

2019-07-28 Thread Jia-Ju Bai
In dequeue_func(), there is an if statement on line 74 to check whether
skb is NULL:
if (skb)

When skb is NULL, it is used on line 77:
prefetch(>end);

Thus, a possible null-pointer dereference may occur.

To fix this bug, skb->end is used when skb is not NULL.

This bug is found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai 
---
 net/sched/sch_codel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
index 25ef172c23df..30169b3adbbb 100644
--- a/net/sched/sch_codel.c
+++ b/net/sched/sch_codel.c
@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars 
*vars, void *ctx)
struct Qdisc *sch = ctx;
struct sk_buff *skb = __qdisc_dequeue_head(>q);
 
-   if (skb)
+   if (skb) {
sch->qstats.backlog -= qdisc_pkt_len(skb);
-
-   prefetch(>end); /* we'll need skb_shinfo() */
+   prefetch(>end); /* we'll need skb_shinfo() */
+   }
return skb;
 }
 
-- 
2.17.0



Re: [PATCH] iio: adc: sc27xx: Change to polling mode to read data

2019-07-28 Thread Baolin Wang
Hi Jonathan,

On Sun, 28 Jul 2019 at 01:27, Jonathan Cameron  wrote:
>
> On Thu, 25 Jul 2019 14:33:50 +0800
> Baolin Wang  wrote:
>
> > From: Freeman Liu 
> >
> > On Spreadtrum platform, the headphone will read one ADC channel multiple
> > times to identify the headphone type, and the headphone identification is
> > sensitive of the ADC reading time. And we found it will take longer time
> > to reading ADC data by using interrupt mode comparing with the polling
> > mode, thus we should change to polling mode to improve the efficiency
> > of reading data, which can identify the headphone type successfully.
> >
> > Signed-off-by: Freeman Liu 
> > Signed-off-by: Baolin Wang 
>
> Hi,
>
> My concerns with this sort of approach is that we may be sacrificing power
> efficiency for some usecases to support one demanding one.
>
> The maximum sleep time is 1 second (I think) which is probably too long
> to poll a register for in general.

1 second is the timeout time, that means something wrong when reading
the data taking 1 second, and we will poll the register status every
500 us.
>From the testing, polling mode takes less time than interrupt mode
when reading ADC data multiple times, so polling mode did not
sacrifice power
efficiency.

> Is there some way we can bound that time and perhaps switch between
> interrupt and polling modes depending on how long we expect to wait?

I do not think the interrupt mode is needed any more, since the ADC
reading is so fast enough usually. Thanks.

>
> Thanks,
>
> Jonathan
>
> > ---
> >  drivers/iio/adc/sc27xx_adc.c |   81 
> > ++
> >  1 file changed, 27 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/iio/adc/sc27xx_adc.c b/drivers/iio/adc/sc27xx_adc.c
> > index f7f7a189..ea864290 100644
> > --- a/drivers/iio/adc/sc27xx_adc.c
> > +++ b/drivers/iio/adc/sc27xx_adc.c
> > @@ -3,7 +3,6 @@
> >
> >  #include 
> >  #include 
> > -#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -46,14 +45,18 @@
> >  /* Bits definitions for SC27XX_ADC_INT_CLR registers */
> >  #define SC27XX_ADC_IRQ_CLR   BIT(0)
> >
> > +/* Bits definitions for SC27XX_ADC_INT_RAW registers */
> > +#define SC27XX_ADC_IRQ_RAW   BIT(0)
> > +
> >  /* Mask definition for SC27XX_ADC_DATA register */
> >  #define SC27XX_ADC_DATA_MASK GENMASK(11, 0)
> >
> >  /* Timeout (ms) for the trylock of hardware spinlocks */
> >  #define SC27XX_ADC_HWLOCK_TIMEOUT5000
> >
> > -/* Timeout (ms) for ADC data conversion according to ADC datasheet */
> > -#define SC27XX_ADC_RDY_TIMEOUT   100
> > +/* Timeout (us) for ADC data conversion according to ADC datasheet */
> > +#define SC27XX_ADC_RDY_TIMEOUT   100
>
> This is 10 x the value I think...
>
> > +#define SC27XX_ADC_POLL_RAW_STATUS   500
> >
> >  /* Maximum ADC channel number */
> >  #define SC27XX_ADC_CHANNEL_MAX   32
> > @@ -72,10 +75,8 @@ struct sc27xx_adc_data {
> >* subsystems which will access the unique ADC controller.
> >*/
> >   struct hwspinlock *hwlock;
> > - struct completion completion;
> >   int channel_scale[SC27XX_ADC_CHANNEL_MAX];
> >   u32 base;
> > - int value;
> >   int irq;
> >  };
> >
> > @@ -188,9 +189,7 @@ static int sc27xx_adc_read(struct sc27xx_adc_data 
> > *data, int channel,
> >  int scale, int *val)
> >  {
> >   int ret;
> > - u32 tmp;
> > -
> > - reinit_completion(>completion);
> > + u32 tmp, value, status;
> >
> >   ret = hwspin_lock_timeout_raw(data->hwlock, 
> > SC27XX_ADC_HWLOCK_TIMEOUT);
> >   if (ret) {
> > @@ -203,6 +202,11 @@ static int sc27xx_adc_read(struct sc27xx_adc_data 
> > *data, int channel,
> >   if (ret)
> >   goto unlock_adc;
> >
> > + ret = regmap_update_bits(data->regmap, data->base + 
> > SC27XX_ADC_INT_CLR,
> > +  SC27XX_ADC_IRQ_CLR, SC27XX_ADC_IRQ_CLR);
> > + if (ret)
> > + goto disable_adc;
> > +
> >   /* Configure the channel id and scale */
> >   tmp = (scale << SC27XX_ADC_SCALE_SHIFT) & SC27XX_ADC_SCALE_MASK;
> >   tmp |= channel & SC27XX_ADC_CHN_ID_MASK;
> > @@ -226,15 +230,22 @@ static int sc27xx_adc_read(struct sc27xx_adc_data 
> > *data, int channel,
> >   if (ret)
> >   goto disable_adc;
> >
> > - ret = wait_for_completion_timeout(>completion,
> > - msecs_to_jiffies(SC27XX_ADC_RDY_TIMEOUT));
> > - if (!ret) {
> > - dev_err(data->dev, "read ADC data timeout\n");
> > - ret = -ETIMEDOUT;
> > - } else {
> > - ret = 0;
> > + ret = regmap_read_poll_timeout(data->regmap,
> > +data->base + SC27XX_ADC_INT_RAW,
> > +status, (status & SC27XX_ADC_IRQ_RAW),
> > +SC27XX_ADC_POLL_RAW_STATUS,
> > +

[BUG] infiniband: mlx5: a possible null-pointer dereference in set_roce_addr()

2019-07-28 Thread Jia-Ju Bai
In set_roce_addr(), there is an if statement on line 589 to check 
whether gid is NULL:

    if (gid)

When gid is NULL, it is used on line 613:
    return mlx5_core_roce_gid_set(..., gid->raw, ...);

Thus, a possible null-pointer dereference may occur.

This bug is found by a static analysis tool STCheck written by us.

I do not know how to correctly fix this bug, so I only report it.


Best wishes,
Jia-Ju Bai


[PATCH] dma: stm32-mdma: Fix a possible null-pointer dereference in stm32_mdma_irq_handler()

2019-07-28 Thread Jia-Ju Bai
In stm32_mdma_irq_handler(), chan is checked on line 1368.
When chan is NULL, it is still used on line 1369:
dev_err(chan2dev(chan), "MDMA channel not initialized\n");

Thus, a possible null-pointer dereference may occur.

To fix this bug, "dev_dbg(mdma2dev(dmadev), ...)" is used instead.

Signed-off-by: Jia-Ju Bai 
---
 drivers/dma/stm32-mdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/stm32-mdma.c b/drivers/dma/stm32-mdma.c
index d6e919d3936a..1311de74bfdd 100644
--- a/drivers/dma/stm32-mdma.c
+++ b/drivers/dma/stm32-mdma.c
@@ -1366,7 +1366,7 @@ static irqreturn_t stm32_mdma_irq_handler(int irq, void 
*devid)
 
chan = >chan[id];
if (!chan) {
-   dev_err(chan2dev(chan), "MDMA channel not initialized\n");
+   dev_dbg(mdma2dev(dmadev), "MDMA channel not initialized\n");
goto exit;
}
 
-- 
2.17.0



linux-next: manual merge of the tip tree with Linus' tree

2019-07-28 Thread Stephen Rothwell
Hi all,

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

  arch/x86/include/uapi/asm/types.h

between commit:

  d9c525229521 ("treewide: add "WITH Linux-syscall-note" to SPDX tag of uapi 
headers")

from Linus' tree and commit:

  701010532164 ("x86/build: Remove unneeded uapi asm-generic wrappers")

from the tip tree.

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

-- 
Cheers,
Stephen Rothwell


pgpPtrDwdWOoG.pgp
Description: OpenPGP digital signature


[PATCH] x86: panic when a kernel stack overflow is detected

2019-07-28 Thread Daniel Axtens
Currently, when a kernel stack overflow is detected via VMAP_STACK,
the task is killed with die().

This isn't safe, because we don't know how that process has affected
kernel state. In particular, we don't know what locks have been taken.
For example, we can hit a case with lkdtm where a thread takes a
stack overflow in printk() after taking the logbuf_lock. In that case,
we deadlock when the kernel next does a printk.

Do not attempt to kill the process when a kernel stack overflow is
detected. The system state is unknown, the only safe thing to do is
panic(). (panic() also prints without taking locks so a useful debug
splat is printed even when logbuf_lock is held.)

Reported-by: Marco Elver 
Signed-off-by: Daniel Axtens 
---
 arch/x86/kernel/traps.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 4bb0f8447112..bfb0ec667c09 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -301,13 +301,14 @@ __visible void __noreturn handle_stack_overflow(const 
char *message,
struct pt_regs *regs,
unsigned long fault_address)
 {
-   printk(KERN_EMERG "BUG: stack guard page was hit at %p (stack is 
%p..%p)\n",
-(void *)fault_address, current->stack,
-(char *)current->stack + THREAD_SIZE - 1);
-   die(message, regs, 0);
+   /*
+* It's not safe to kill the task, as it's in kernel space and
+* might be holding important locks. Just panic.
+*/
 
-   /* Be absolutely certain we don't return. */
-   panic("%s", message);
+   panic("%s - stack guard page was hit at %p (stack is %p..%p)",
+ message, (void *)fault_address, current->stack,
+ (char *)current->stack + THREAD_SIZE - 1);
 }
 #endif
 
-- 
2.20.1



Re: [PATCH resend v2] lib: scatterlist: Fix to support no mapped sg

2019-07-28 Thread Zhou Wang
On 2019/7/24 11:54, Zhou Wang wrote:
> In function sg_split, the second sg_calculate_split will return -EINVAL
> when in_mapped_nents is 0.
> 
> Indeed there is no need to do second sg_calculate_split and sg_split_mapped
> when in_mapped_nents is 0, as in_mapped_nents indicates no mapped entry in
> original sgl.
> 
> Signed-off-by: Zhou Wang 
> Acked-by: Robert Jarzmik 
> ---
> v2: Just add Acked-by from Robert.
> 
>  lib/sg_split.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/lib/sg_split.c b/lib/sg_split.c
> index 9982c63..60a0bab 100644
> --- a/lib/sg_split.c
> +++ b/lib/sg_split.c
> @@ -176,11 +176,13 @@ int sg_split(struct scatterlist *in, const int 
> in_mapped_nents,
>* The order of these 3 calls is important and should be kept.
>*/
>   sg_split_phys(splitters, nb_splits);
> - ret = sg_calculate_split(in, in_mapped_nents, nb_splits, skip,
> -  split_sizes, splitters, true);
> - if (ret < 0)
> - goto err;
> - sg_split_mapped(splitters, nb_splits);
> + if (in_mapped_nents) {
> + ret = sg_calculate_split(in, in_mapped_nents, nb_splits, skip,
> +  split_sizes, splitters, true);
> + if (ret < 0)
> + goto err;
> + sg_split_mapped(splitters, nb_splits);
> + }
>  
>   for (i = 0; i < nb_splits; i++) {
>   out[i] = splitters[i].out_sg;
> 

Hi Jens,

I saw you are the committer of sg_splite.c, could you help to take this patch?

Many thanks,
Zhou



[PATCH v2] iio: light: si1145: Use device-managed APIs

2019-07-28 Thread Chuhong Yuan
Use device-managed APIs to simplify the code.
The remove functions are redundant now and can
be deleted.

Signed-off-by: Chuhong Yuan 
---
Changes in v2:
  - Split v1 into two patches.
  - Use devm_iio_trigger_register in probe_trigger,
delete redundant remove_trigger.
  - Return devm_iio_device_register directly as a
minor optimization.

 drivers/iio/light/si1145.c | 42 +-
 1 file changed, 5 insertions(+), 37 deletions(-)

diff --git a/drivers/iio/light/si1145.c b/drivers/iio/light/si1145.c
index 6579d2418814..982bba0c54e7 100644
--- a/drivers/iio/light/si1145.c
+++ b/drivers/iio/light/si1145.c
@@ -1261,7 +1261,7 @@ static int si1145_probe_trigger(struct iio_dev *indio_dev)
return ret;
}
 
-   ret = iio_trigger_register(trig);
+   ret = devm_iio_trigger_register(>dev, trig);
if (ret)
return ret;
 
@@ -1271,16 +1271,6 @@ static int si1145_probe_trigger(struct iio_dev 
*indio_dev)
return 0;
 }
 
-static void si1145_remove_trigger(struct iio_dev *indio_dev)
-{
-   struct si1145_data *data = iio_priv(indio_dev);
-
-   if (data->trig) {
-   iio_trigger_unregister(data->trig);
-   data->trig = NULL;
-   }
-}
-
 static int si1145_probe(struct i2c_client *client,
const struct i2c_device_id *id)
 {
@@ -1332,7 +1322,8 @@ static int si1145_probe(struct i2c_client *client,
if (ret < 0)
return ret;
 
-   ret = iio_triggered_buffer_setup(indio_dev, NULL,
+   ret = devm_iio_triggered_buffer_setup(>dev,
+   indio_dev, NULL,
si1145_trigger_handler, _buffer_setup_ops);
if (ret < 0)
return ret;
@@ -1340,23 +1331,12 @@ static int si1145_probe(struct i2c_client *client,
if (client->irq) {
ret = si1145_probe_trigger(indio_dev);
if (ret < 0)
-   goto error_free_buffer;
+   return ret;
} else {
dev_info(>dev, "no irq, using polling\n");
}
 
-   ret = iio_device_register(indio_dev);
-   if (ret < 0)
-   goto error_free_trigger;
-
-   return 0;
-
-error_free_trigger:
-   si1145_remove_trigger(indio_dev);
-error_free_buffer:
-   iio_triggered_buffer_cleanup(indio_dev);
-
-   return ret;
+   return devm_iio_device_register(>dev, indio_dev);
 }
 
 static const struct i2c_device_id si1145_ids[] = {
@@ -1371,23 +1351,11 @@ static const struct i2c_device_id si1145_ids[] = {
 };
 MODULE_DEVICE_TABLE(i2c, si1145_ids);
 
-static int si1145_remove(struct i2c_client *client)
-{
-   struct iio_dev *indio_dev = i2c_get_clientdata(client);
-
-   iio_device_unregister(indio_dev);
-   si1145_remove_trigger(indio_dev);
-   iio_triggered_buffer_cleanup(indio_dev);
-
-   return 0;
-}
-
 static struct i2c_driver si1145_driver = {
.driver = {
.name   = "si1145",
},
.probe  = si1145_probe,
-   .remove = si1145_remove,
.id_table = si1145_ids,
 };
 
-- 
2.20.1



[PATCH] staging: rtl8723bs: core: Remove unneeded variables sgi_20m,sgi_40m and sgi_80m

2019-07-28 Thread Hariprasad Kelam
htpriv.sgi_* variables are of type u8 ,instead of storing them in local
variables ,its better to read value directly from structure.

Signed-off-by: Hariprasad Kelam 
---
 drivers/staging/rtl8723bs/core/rtw_xmit.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8723bs/core/rtw_xmit.c 
b/drivers/staging/rtl8723bs/core/rtw_xmit.c
index b5dcb78..0690d5e 100644
--- a/drivers/staging/rtl8723bs/core/rtw_xmit.c
+++ b/drivers/staging/rtl8723bs/core/rtw_xmit.c
@@ -346,21 +346,18 @@ void _rtw_free_xmit_priv(struct xmit_priv *pxmitpriv)
 
 u8 query_ra_short_GI(struct sta_info *psta)
 {
-   u8 sgi = false, sgi_20m = false, sgi_40m = false, sgi_80m = false;
-
-   sgi_20m = psta->htpriv.sgi_20m;
-   sgi_40m = psta->htpriv.sgi_40m;
+   u8 sgi = false;
 
switch (psta->bw_mode) {
case CHANNEL_WIDTH_80:
-   sgi = sgi_80m;
+   sgi = false;
break;
case CHANNEL_WIDTH_40:
-   sgi = sgi_40m;
+   sgi = psta->htpriv.sgi_40m;
break;
case CHANNEL_WIDTH_20:
default:
-   sgi = sgi_20m;
+   sgi = psta->htpriv.sgi_20m;
break;
}
 
-- 
2.7.4



RE: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag for IMX8MQ_CLK_TMU_ROOT

2019-07-28 Thread Anson Huang
Hi, Abel/Daniel

> On 19-07-27 09:33:10, Daniel Baluta wrote:
> > On Sat, Jul 27, 2019 at 9:19 AM Anson Huang 
> wrote:
> > >
> > > Hi, Daniel
> > >
> > > > Subject: Re: [PATCH 5/6] clk: imx8mq: Remove CLK_IS_CRITICAL flag
> > > > for IMX8MQ_CLK_TMU_ROOT
> > > >
> > > > Hi all,
> > > >
> > > > latest linux-next hangs at boot.
> > > >
> > > > commit fde50b96be821ac9673a7e00847cc4605bd88f34 (HEAD ->
> master, tag:
> > > > next-20190726, origin/master, origin/HEAD)
> > > > Author: Stephen Rothwell 
> > > > Date:   Fri Jul 26 15:18:02 2019 +1000
> > > >
> > > > Add linux-next specific files for 20190726
> > > >
> > > > Signed-off-by: Stephen Rothwell 
> > > >
> > > >
> > > > I know this is crazy but reverting commit:
> > > >
> > > > commit 431bdd1df48ee2896ea9980d9153e3aeaf0c81ef
> (refs/bisect/bad)
> > > > Author: Anson Huang 
> > > > Date:   Fri Jul 5 12:56:11 2019 +0800
> > > >
> > > > clk: imx8mq: Remove CLK_IS_CRITICAL flag for
> > > > IMX8MQ_CLK_TMU_ROOT
> > > >
> > > > IMX8MQ_CLK_TMU_ROOT is ONLY used for thermal module, the
> driver
> > > > should manage this clock, so no need to have CLK_IS_CRITICAL flag
> > > > set.
> > > >
> > > >
> > > >
> > > > makes the boot work again.
> > > >
> > > > Any idea?
> > >
> > > I just found if disabling SDMA1, then kernel can boot up, it does
> > > NOT make sense TMU clock is related to SDMA1, I will check with design
> and get back to you soon.
> > >
> >
> > Hi Anson,
> >
> > Applying Abel's patch:
> >
> > commit 8816c47db6a82f55bb4d64f62fd9dd3af680f0e4 (HEAD -> master)
> > Author: Abel Vesa 
> > Date:   Tue Jun 25 12:01:56 2019 +0300
> >
> > clk: imx8mq: Mark AHB clock as critical
> >
> > Keep the AHB clock always on since there is no driver to control it and
> > all the other clocks that use it as parent rely on it being always 
> > enabled.
> >
> >
> >
> > The kernel boots up again.
> >
> > It make some sense. I don't understand though why having
> > IMX8MQ_CLK_TMU_ROOT as critical also "unhangs" the kernel.
> >
> 
> OK, so this is how it works.
> 
> By removing the critical flag from TMU, the AHB doesn't stay always on.
> With my patch the AHB is marked as critical and therefore stays on.
> 
> The sdma1_clk has as parent the ipg_root which in turn has as parent the
> ahb clock. And I think what happens is some read from the sdma registers
> hangs because, for whatever reason, enabling the sdma1_clk doesn't
> propagate to enable the ahb clock. I might be wrong though.
> 

I can explain why Abel's patch can fix this issue, the AHB clock is a MUST
always ON for system bus, while it does NOT have CLK_IS_CRITICAL flag set for 
now,
when SDMA1 is probed, it will enable its clock, and the clk path is 
sdma1_clk->ipg_root->ahb,
after SDMA1 probed done, it will disable its clock since no one use it, and it 
will trigger
the ahb clock to be OFF, as its usecount is added by 1 when probe and decreased 
by 1 after
SDMA1 probe done, so usecount=0 will trigger AHB clock to be OFF.

So I think the best solution should be applying Abel's patch as you mentioned 
upper, the TMU
clock patch is NOT the root cause, it just triggers this issue accidently☹

But I saw Abel's AHB patch is still under discussion, so I think we need to 
speed it up and make 
kernel boot up work for development. AHB/IPG are always critical for i.MX SoCs.

Thanks,
Anson.


Re: [PATCH 4.4 stable net] net: tcp: Fix use-after-free in tcp_write_xmit

2019-07-28 Thread maowenan



On 2019/7/27 19:40, Greg KH wrote:
> On Sat, Jul 27, 2019 at 07:22:30PM +0800, maowenan wrote:
>>
>>
>> On 2019/7/27 18:44, maowenan wrote:
>>>
>>>
>>> On 2019/7/24 20:13, maowenan wrote:


 On 2019/7/24 19:05, Greg KH wrote:
> On Wed, Jul 24, 2019 at 05:17:15PM +0800, Mao Wenan wrote:
>> There is one report about tcp_write_xmit use-after-free with version 
>> 4.4.136:
>>
>> BUG: KASAN: use-after-free in tcp_skb_pcount include/net/tcp.h:796 
>> [inline]
>> BUG: KASAN: use-after-free in tcp_init_tso_segs 
>> net/ipv4/tcp_output.c:1619 [inline]
>> BUG: KASAN: use-after-free in tcp_write_xmit+0x3fc2/0x4cb0 
>> net/ipv4/tcp_output.c:2056
>> Read of size 2 at addr 8801d6fc87b0 by task syz-executor408/4195
>>
>> CPU: 0 PID: 4195 Comm: syz-executor408 Not tainted 4.4.136-gfb7e319 #59
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS 
>> Google 01/01/2011
>>   7d8f38ecc03be946 8801d73b7710 81e0edad
>>  ea00075bf200 8801d6fc87b0  8801d6fc87b0
>>  dc00 8801d73b7748 815159b6 8801d6fc87b0
>> Call Trace:
>>  [] __dump_stack lib/dump_stack.c:15 [inline]
>>  [] dump_stack+0xc1/0x124 lib/dump_stack.c:51
>>  [] print_address_description+0x6c/0x216 
>> mm/kasan/report.c:252
>>  [] kasan_report_error mm/kasan/report.c:351 [inline]
>>  [] kasan_report.cold.7+0x175/0x2f7 
>> mm/kasan/report.c:408
>>  [] __asan_report_load2_noabort+0x14/0x20 
>> mm/kasan/report.c:427
>>  [] tcp_skb_pcount include/net/tcp.h:796 [inline]
>>  [] tcp_init_tso_segs net/ipv4/tcp_output.c:1619 
>> [inline]
>>  [] tcp_write_xmit+0x3fc2/0x4cb0 
>> net/ipv4/tcp_output.c:2056
>>  [] __tcp_push_pending_frames+0xa0/0x290 
>> net/ipv4/tcp_output.c:2307
>>  [] tcp_send_fin+0x176/0xab0 net/ipv4/tcp_output.c:2883
>>  [] tcp_close+0xca0/0xf70 net/ipv4/tcp.c:2112
>>  [] inet_release+0xff/0x1d0 net/ipv4/af_inet.c:435
>>  [] sock_release+0x96/0x1c0 net/socket.c:586
>>  [] sock_close+0x16/0x20 net/socket.c:1037
>>  [] __fput+0x235/0x6f0 fs/file_table.c:208
>>  [] fput+0x15/0x20 fs/file_table.c:244
>>  [] task_work_run+0x10f/0x190 kernel/task_work.c:115
>>  [] exit_task_work include/linux/task_work.h:21 
>> [inline]
>>  [] do_exit+0x9e5/0x26b0 kernel/exit.c:759
>>  [] do_group_exit+0x111/0x330 kernel/exit.c:889
>>  [] get_signal+0x4ec/0x14b0 kernel/signal.c:2321
>>  [] do_signal+0x8b/0x1d30 arch/x86/kernel/signal.c:712
>>  [] exit_to_usermode_loop+0x11a/0x160 
>> arch/x86/entry/common.c:248
>>  [] prepare_exit_to_usermode 
>> arch/x86/entry/common.c:283 [inline]
>>  [] syscall_return_slowpath+0x1b5/0x1f0 
>> arch/x86/entry/common.c:348
>>  [] int_ret_from_sys_call+0x25/0xa3
>>
>> Allocated by task 4194:
>>  [] save_stack_trace+0x26/0x50 
>> arch/x86/kernel/stacktrace.c:63
>>  [] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
>>  [] set_track mm/kasan/kasan.c:524 [inline]
>>  [] kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:616
>>  [] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:554
>>  [] slab_post_alloc_hook mm/slub.c:1349 [inline]
>>  [] slab_alloc_node mm/slub.c:2615 [inline]
>>  [] slab_alloc mm/slub.c:2623 [inline]
>>  [] kmem_cache_alloc+0xbe/0x2a0 mm/slub.c:2628
>>  [] kmem_cache_alloc_node include/linux/slab.h:350 
>> [inline]
>>  [] __alloc_skb+0xe6/0x600 net/core/skbuff.c:218
>>  [] alloc_skb_fclone include/linux/skbuff.h:856 
>> [inline]
>>  [] sk_stream_alloc_skb+0xa3/0x5d0 net/ipv4/tcp.c:833
>>  [] tcp_sendmsg+0xd34/0x2b00 net/ipv4/tcp.c:1178
>>  [] inet_sendmsg+0x203/0x4d0 net/ipv4/af_inet.c:755
>>  [] sock_sendmsg_nosec net/socket.c:625 [inline]
>>  [] sock_sendmsg+0xcc/0x110 net/socket.c:635
>>  [] SYSC_sendto+0x21c/0x370 net/socket.c:1665
>>  [] SyS_sendto+0x40/0x50 net/socket.c:1633
>>  [] entry_SYSCALL_64_fastpath+0x22/0x9e
>>
>> Freed by task 4194:
>>  [] save_stack_trace+0x26/0x50 
>> arch/x86/kernel/stacktrace.c:63
>>  [] save_stack+0x43/0xd0 mm/kasan/kasan.c:512
>>  [] set_track mm/kasan/kasan.c:524 [inline]
>>  [] kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:589
>>  [] slab_free_hook mm/slub.c:1383 [inline]
>>  [] slab_free_freelist_hook mm/slub.c:1405 [inline]
>>  [] slab_free mm/slub.c:2859 [inline]
>>  [] kmem_cache_free+0xbe/0x340 mm/slub.c:2881
>>  [] kfree_skbmem+0xcf/0x100 net/core/skbuff.c:635
>>  [] __kfree_skb+0x1d/0x20 net/core/skbuff.c:676
>>  [] sk_wmem_free_skb include/net/sock.h:1447 [inline]
>>  [] tcp_write_queue_purge include/net/tcp.h:1460 
>> [inline]
>>  [] tcp_connect_init net/ipv4/tcp_output.c:3122 
>> [inline]
>>  [] tcp_connect+0xb24/0x30c0 net/ipv4/tcp_output.c:3261
>>  [] tcp_v4_connect+0xf31/0x1890 

Re: [PATCH v2 2/2] extcon: axp288: Use for_each_set_bit() in axp288_extcon_log_rsi()

2019-07-28 Thread Chanwoo Choi
On 19. 7. 26. 오후 9:18, Andy Shevchenko wrote:
> This simplifies and standardizes axp288_extcon_log_rsi()
> by using for_each_set_bit() library function.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/extcon/extcon-axp288.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
> index 694a8d4a57ff..415afaf479e7 100644
> --- a/drivers/extcon/extcon-axp288.c
> +++ b/drivers/extcon/extcon-axp288.c
> @@ -121,7 +121,6 @@ static const char * const axp288_pwr_up_down_info[] = {
>   "Last shutdown caused by PMIC UVLO threshold",
>   "Last shutdown caused by SOC initiated cold off",
>   "Last shutdown caused by user pressing the power button",
> - NULL,
>  };
>  
>  /*
> @@ -130,8 +129,8 @@ static const char * const axp288_pwr_up_down_info[] = {
>   */
>  static void axp288_extcon_log_rsi(struct axp288_extcon_info *info)
>  {
> - const char * const *rsi;
>   unsigned int val, i, clear_mask = 0;
> + unsigned long bits;
>   int ret;
>  
>   ret = regmap_read(info->regmap, AXP288_PS_BOOT_REASON_REG, );
> @@ -140,12 +139,10 @@ static void axp288_extcon_log_rsi(struct 
> axp288_extcon_info *info)
>   return;
>   }
>  
> - for (i = 0, rsi = axp288_pwr_up_down_info; *rsi; rsi++, i++) {
> - if (val & BIT(i)) {
> - dev_dbg(info->dev, "%s\n", *rsi);
> - clear_mask |= BIT(i);
> - }
> - }
> + bits = val & GENMASK(ARRAY_SIZE(axp288_pwr_up_down_info) - 1, 0);
> + for_each_set_bit(i, , ARRAY_SIZE(axp288_pwr_up_down_info))
> + dev_dbg(info->dev, "%s\n", axp288_pwr_up_down_info[i]);
> + clear_mask = bits;
>  
>   /* Clear the register value for next reboot (write 1 to clear bit) */
>   regmap_write(info->regmap, AXP288_PS_BOOT_REASON_REG, clear_mask);
> 

Applied it. Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics


Re: [PATCH V3 net-next 06/10] net: hns3: add debug messages to identify eth down cause

2019-07-28 Thread tanhuazhong




On 2019/7/28 10:03, David Miller wrote:

From: Huazhong Tan 
Date: Sat, 27 Jul 2019 13:46:08 +0800


From: Yonglong Liu 

Some times just see the eth interface have been down/up via
dmesg, but can not know why the eth down. So adds some debug
messages to identify the cause for this.

Signed-off-by: Yonglong Liu 
Signed-off-by: Peng Li 
Signed-off-by: Huazhong Tan 
---
  drivers/net/ethernet/hisilicon/hns3/hns3_enet.c   | 18 ++
  drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c| 19 +++
  .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c| 11 +++
  3 files changed, 48 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
index 4d58c53..973c57b 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
@@ -459,6 +459,9 @@ static int hns3_nic_net_open(struct net_device *netdev)
h->ae_algo->ops->set_timer_task(priv->ae_handle, true);
  
  	hns3_config_xps(priv);

+
+   netif_info(h, drv, netdev, "net open\n");


These will pollute everyone's kernel logs for normal operations.

This is not reasonable at all, sorry.

Furthermore, even if it was appropriate, "netif_info()" is not "debug".



Will replace it with netif_dbg.
thanks.



.





Re: [PATCH v2 1/2] extcon: axp288: Add missed error check

2019-07-28 Thread Chanwoo Choi
On 19. 7. 26. 오후 9:18, Andy Shevchenko wrote:
> It seems from the very beginning the error check has been missed
> in axp288_extcon_log_rsi(). Add it here.
> 
> Cc: Ramakrishna Pallala 
> Signed-off-by: Andy Shevchenko 
> ---
> - added error message (Chanwoo)
>  drivers/extcon/extcon-axp288.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
> index 7254852e6ec0..694a8d4a57ff 100644
> --- a/drivers/extcon/extcon-axp288.c
> +++ b/drivers/extcon/extcon-axp288.c
> @@ -135,6 +135,11 @@ static void axp288_extcon_log_rsi(struct 
> axp288_extcon_info *info)
>   int ret;
>  
>   ret = regmap_read(info->regmap, AXP288_PS_BOOT_REASON_REG, );
> + if (ret < 0) {
> + dev_err(info->dev, "failed to read reset source indicator\n");
> + return;
> + }
> +
>   for (i = 0, rsi = axp288_pwr_up_down_info; *rsi; rsi++, i++) {
>   if (val & BIT(i)) {
>   dev_dbg(info->dev, "%s\n", *rsi);
> 

Applied it. Thanks.

-- 
Best Regards,
Chanwoo Choi
Samsung Electronics


[PATCH] tracing: Prevent RCU EQS breakage in preemptirq events

2019-07-28 Thread Eiichi Tsukata
If context tracking is enabled, causing page fault in preemptirq
irq_enable or irq_disable events triggers the following RCU EQS warning.

Reproducer:

  // CONFIG_PREEMPTIRQ_EVENTS=y
  // CONFIG_CONTEXT_TRACKING=y
  // CONFIG_RCU_EQS_DEBUG=y
  # echo 1 > events/preemptirq/irq_disable/enable
  # echo 1 > options/userstacktrace

  WARNING: CPU: 0 PID: 2574 at kernel/rcu/tree.c:262 
rcu_dynticks_eqs_exit+0x48/0x50
  CPU: 0 PID: 2574 Comm: sh Not tainted 5.3.0-rc1+ #105
  RIP: 0010:rcu_dynticks_eqs_exit+0x48/0x50
  Call Trace:
   rcu_eqs_exit+0x4e/0xd0
   rcu_user_exit+0x13/0x20
   __context_tracking_exit.part.0+0x74/0x120
   context_tracking_exit.part.0+0x28/0x50
   context_tracking_exit+0x1d/0x20
   do_page_fault+0xab/0x1b0
   do_async_page_fault+0x35/0xb0
   async_page_fault+0x3e/0x50
  RIP: 0010:arch_stack_walk_user+0x8e/0x100
   stack_trace_save_user+0x7d/0xa9
   trace_buffer_unlock_commit_regs+0x178/0x220
   trace_event_buffer_commit+0x6b/0x200
   trace_event_raw_event_preemptirq_template+0x7b/0xc0
   trace_hardirqs_off_caller+0xb3/0xf0
   trace_hardirqs_off_thunk+0x1a/0x20
   entry_SYSCALL_64_after_hwframe+0x3e/0xbe

Details of call trace and RCU EQS/Context:

  entry_SYSCALL_64_after_hwframe() EQS: IN, CTX: USER
trace_irq_disable_rcuidle()
  rcu_irq_enter_irqson()
rcu_dynticks_eqs_exit() EQS: IN => OUT
  stack_trace_save_user() EQS: OUT, CTX: USER
page_fault()
  do_page_fault()
exception_enter() EQS: OUT, CTX: USER
  context_tracking_exit()
rcu_eqs_exit()
  rcu_dynticks_eqs_exit() EQS: OUT => OUT? (warning)

trace_irq_disable/enable_rcuidle() are called from user mode in entry
code, and calls rcu_irq_enter_irqson() in __DO_TRACE(). This can cause
the state "RCU ESQ: OUT but CTX: USER", then stack_trace_save_user() can
cause page fault which calls rcu_dynticks_eqs_exit() again leads to hit
the EQS validation warning if CONFIG_RCU_EQS_DEBUG is enabled.

Fix it by calling exception_enter/exit() around
trace_irq_disable/enable_rcuidle() to enter CONTEXT_KERNEL before
tracing code causes page fault. Also makes the timing of state change to
CONTEXT_KERNL earlier to prevent tracing codes from calling
context_tracking_exit() recursively.

Ideally, the problem can be fixed by calling enter_from_user_mode() before
TRACE_IRQS_OFF in entry codes (then we need to tell lockdep that IRQs are
off eariler) and calling prepare_exit_to_usermode() after TRACE_IRQS_ON.
But this patch will be much simpler and limit the most change to tracing
codes.

Fixes: 865e63b04e9b ("tracing: Add back in rcu_irq_enter/exit_irqson() for 
rcuidle tracepoints")
Signed-off-by: Eiichi Tsukata 
---
 kernel/context_tracking.c   |  6 +-
 kernel/trace/trace_preemptirq.c | 15 +--
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
index be01a4d627c9..860eaf9780e5 100644
--- a/kernel/context_tracking.c
+++ b/kernel/context_tracking.c
@@ -148,6 +148,11 @@ void __context_tracking_exit(enum ctx_state state)
return;
 
if (__this_cpu_read(context_tracking.state) == state) {
+   /*
+* Change state before executing codes which can trigger
+* page fault leading unnecessary re-entrance.
+*/
+   __this_cpu_write(context_tracking.state, CONTEXT_KERNEL);
if (__this_cpu_read(context_tracking.active)) {
/*
 * We are going to run code that may use RCU. Inform
@@ -159,7 +164,6 @@ void __context_tracking_exit(enum ctx_state state)
trace_user_exit(0);
}
}
-   __this_cpu_write(context_tracking.state, CONTEXT_KERNEL);
}
context_tracking_recursion_exit();
 }
diff --git a/kernel/trace/trace_preemptirq.c b/kernel/trace/trace_preemptirq.c
index 4d8e99fdbbbe..031b51cb94d0 100644
--- a/kernel/trace/trace_preemptirq.c
+++ b/kernel/trace/trace_preemptirq.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "trace.h"
 
 #define CREATE_TRACE_POINTS
@@ -49,9 +50,14 @@ NOKPROBE_SYMBOL(trace_hardirqs_off);
 
 __visible void trace_hardirqs_on_caller(unsigned long caller_addr)
 {
+   enum ctx_state prev_state;
+
if (this_cpu_read(tracing_irq_cpu)) {
-   if (!in_nmi())
+   if (!in_nmi()) {
+   prev_state = exception_enter();
trace_irq_enable_rcuidle(CALLER_ADDR0, caller_addr);
+   exception_exit(prev_state);
+   }
tracer_hardirqs_on(CALLER_ADDR0, caller_addr);
this_cpu_write(tracing_irq_cpu, 0);
}
@@ -63,11 +69,16 @@ NOKPROBE_SYMBOL(trace_hardirqs_on_caller);
 
 __visible void trace_hardirqs_off_caller(unsigned long caller_addr)
 {
+   enum ctx_state prev_state;
+
if 

Re: [PATCH] ext4: Fix deadlock on page reclaim

2019-07-28 Thread Damien Le Moal
On 2019/07/29 8:42, Dave Chinner wrote:
> On Sat, Jul 27, 2019 at 02:59:59AM +, Damien Le Moal wrote:
>> On 2019/07/27 7:55, Theodore Y. Ts'o wrote:
>>> On Sat, Jul 27, 2019 at 08:44:23AM +1000, Dave Chinner wrote:
>
> This looks like something that could hit every file systems, so
> shouldn't we fix this in common code?  We could also look into
> just using memalloc_nofs_save for the page cache allocation path
> instead of the per-mapping gfp_mask.

 I think it has to be the entire IO path - any allocation from the
 underlying filesystem could recurse into the top level filesystem
 and then deadlock if the memory reclaim submits IO or blocks on
 IO completion from the upper filesystem. That's a bloody big hammer
 for something that is only necessary when there are stacked
 filesystems like this
>>>
>>> Yeah that's why using memalloc_nofs_save() probably makes the most
>>> sense, and dm_zoned should use that before it calls into ext4.
>>
>> Unfortunately, with this particular setup, that will not solve the problem.
>> dm-zoned submit BIOs to its backend drive in response to XFS activity. The
>> requests for these BIOs are passed along to the kernel tcmu HBA and end up in
>> that HBA command ring. The commands themselves are read from the ring and
>> executed by the tcmu-runner user process which executes them doing
>> pread()/pwrite() to the ext4 file. The tcmu-runner process being a different
>> context than the dm-zoned worker thread issuing the BIO,
>> memalloc_nofs_save/restore() calls in dm-zoned will have no effect.
> 
> Right, I'm talking about using memalloc_nofs_save() as a huge hammer
> in the pread/pwrite() calling context, not the bio submission
> context (which is typically GFP_NOFS above submit_bio() and GFP_NOIO
> below).

Yes, I understood your point. And I agree that it indeed would be a big hammer.
We should be able to do better than that :)

>> One simple hack would be an fcntl() or mount option to tell the FS to use
>> GFP_NOFS unconditionally, but avoiding the bug would mean making sure that 
>> the
>> applications or system setup is correct. So not so safe.
> 
> Wasn't there discussion at some point in the past about an interface
> for special processes to be able to mark themselves as PF_MEMALLOC
> (some kind of prctl, I think) for things like FUSE daemons? That
> would prevent direct reclaim recursion for these userspace daemons
> that are in the kernel memory reclaim IO path. It's the same
> situation there, isn't it? How does fuse deal with this problem?

I do not recall such discussion. But indeed FUSE may give some hints. Good idea.
Thanks. I will check.


-- 
Damien Le Moal
Western Digital Research


Re: next/master boot: 254 boots: 16 failed, 231 passed with 4 offline, 1 untried/unknown, 2 conflicts (next-20190726)

2019-07-28 Thread Bjorn Andersson
On Fri 26 Jul 06:48 PDT 2019, Mark Brown wrote:

> On Fri, Jul 26, 2019 at 05:18:01AM -0700, kernelci.org bot wrote:
> 
> The past few versions of -next failed to boot on apq8096-db820c:
> 
> > defconfig:
> > gcc-8:
> > apq8096-db820c: 1 failed lab
> 
> with an RCU stall towards the end of boot:
> 
> 00:03:40.521336  [   18.487538] qcom_q6v5_pas adsp-pil: adsp-pil supply px 
> not found, using dummy regulator
> 00:04:01.523104  [   39.499613] rcu: INFO: rcu_preempt detected stalls on 
> CPUs/tasks:
> 00:04:01.533371  [   39.499657] rcu:  2-...!: (0 ticks this GP) 
> idle=9ca/1/0x4000 softirq=1450/1450 fqs=50
> 00:04:01.537544  [   39.504689]   (detected by 0, t=5252 jiffies, g=2425, 
> q=619)
> 00:04:01.541727  [   39.513539] Task dump for CPU 2:
> 00:04:01.547929  [   39.519096] seq R  running task0   
> 199198 0x
> 
> Full details and logs at:
> 
>   https://kernelci.org/boot/id/5d3aa7ea59b5142ba868890f/
> 
> The last version that worked was from the 15th and there seem to be
> similar issues in mainline since -rc1.

Thanks for the report Mark, afaict the problem showed up in v5.3-rc1 as
well.

I think the problem is that the regulator supplying the GPU power
domain(s) isn't enabled - and I think there's a lack of agreement of how
this should be controlled.

But we have a partial fix for this floating around, I will give it a
spin.

Regards,
Bjorn


  1   2   3   4   >