Re: [PATCHv2 1/3] mm/numa: change the topo of build_zonelist_xx()

2018-12-20 Thread kbuild test robot
Hi Pingfan,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc7 next-20181220]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pingfan-Liu/mm-bugfix-for-NULL-reference-in-mm-on-all-archs/20181221-152625
config: riscv-tinyconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.1.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=riscv 

All errors (new ones prefixed by >>):

   mm/page_alloc.c: In function 'build_zonelists':
>> mm/page_alloc.c:5288:12: error: 'local_node' redeclared as different kind of 
>> symbol
 int node, local_node;
   ^~
   mm/page_alloc.c:5286:66: note: previous definition of 'local_node' was here
static void build_zonelists(struct zonelist *node_zonelists, int local_node)
 ^~

vim +/local_node +5288 mm/page_alloc.c

^1da177e4 Linus Torvalds2005-04-16  5285  
e6ee0d8bd Pingfan Liu   2018-12-20  5286  static void 
build_zonelists(struct zonelist *node_zonelists, int local_node)
^1da177e4 Linus Torvalds2005-04-16  5287  {
19655d348 Christoph Lameter 2006-09-25 @5288int node, local_node;
9d3be21bf Michal Hocko  2017-09-06  5289struct zoneref *zonerefs;
9d3be21bf Michal Hocko  2017-09-06  5290int nr_zones;
^1da177e4 Linus Torvalds2005-04-16  5291  
e6ee0d8bd Pingfan Liu   2018-12-20  5292zonerefs = 
node_zonelists[ZONELIST_FALLBACK]._zonerefs;
e6ee0d8bd Pingfan Liu   2018-12-20  5293nr_zones = 
build_zonerefs_node(local_node, zonerefs);
9d3be21bf Michal Hocko  2017-09-06  5294zonerefs += nr_zones;
^1da177e4 Linus Torvalds2005-04-16  5295  
^1da177e4 Linus Torvalds2005-04-16  5296/*
^1da177e4 Linus Torvalds2005-04-16  5297 * Now we build the zonelist so 
that it contains the zones
^1da177e4 Linus Torvalds2005-04-16  5298 * of all the other nodes.
^1da177e4 Linus Torvalds2005-04-16  5299 * We don't want to pressure a 
particular node, so when
^1da177e4 Linus Torvalds2005-04-16  5300 * building the zones for node 
N, we make sure that the
^1da177e4 Linus Torvalds2005-04-16  5301 * zones coming right after the 
local ones are those from
^1da177e4 Linus Torvalds2005-04-16  5302 * node N+1 (modulo N)
^1da177e4 Linus Torvalds2005-04-16  5303 */
^1da177e4 Linus Torvalds2005-04-16  5304for (node = local_node + 1; 
node < MAX_NUMNODES; node++) {
^1da177e4 Linus Torvalds2005-04-16  5305if (!node_online(node))
^1da177e4 Linus Torvalds2005-04-16  5306continue;
e6ee0d8bd Pingfan Liu   2018-12-20  5307nr_zones = 
build_zonerefs_node(node, zonerefs);
9d3be21bf Michal Hocko  2017-09-06  5308zonerefs += nr_zones;
^1da177e4 Linus Torvalds2005-04-16  5309}
^1da177e4 Linus Torvalds2005-04-16  5310for (node = 0; node < 
local_node; node++) {
^1da177e4 Linus Torvalds2005-04-16  5311if (!node_online(node))
^1da177e4 Linus Torvalds2005-04-16  5312continue;
e6ee0d8bd Pingfan Liu   2018-12-20  5313nr_zones = 
build_zonerefs_node(node, zonerefs);
9d3be21bf Michal Hocko  2017-09-06  5314zonerefs += nr_zones;
^1da177e4 Linus Torvalds2005-04-16  5315}
^1da177e4 Linus Torvalds2005-04-16  5316  
9d3be21bf Michal Hocko  2017-09-06  5317zonerefs->zone = NULL;
9d3be21bf Michal Hocko  2017-09-06  5318zonerefs->zone_idx = 0;
^1da177e4 Linus Torvalds2005-04-16  5319  }
^1da177e4 Linus Torvalds2005-04-16  5320  

:: The code at line 5288 was first introduced by commit
:: 19655d3487001d7df0e10e9cbfc27c758b77c2b5 [PATCH] linearly index 
zone->node_zonelists[]

:: TO: Christoph Lameter 
:: CC: Linus Torvalds 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


[PATCH 10/10] driver core: remove BUS_ATTR()

2018-12-20 Thread Greg Kroah-Hartman
There are now no in-kernel users of BUS_ATTR() so drop it from device.h

Everyone should use BUS_ATTR_RO/RW/WO() from now on.

Cc: "Rafael J. Wysocki" 
Signed-off-by: Greg Kroah-Hartman 
---
 include/linux/device.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/linux/device.h b/include/linux/device.h
index 1b25c7a43f4c..1e8ae731fb97 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -49,8 +49,6 @@ struct bus_attribute {
ssize_t (*store)(struct bus_type *bus, const char *buf, size_t count);
 };
 
-#define BUS_ATTR(_name, _mode, _show, _store)  \
-   struct bus_attribute bus_attr_##_name = __ATTR(_name, _mode, _show, 
_store)
 #define BUS_ATTR_RW(_name) \
struct bus_attribute bus_attr_##_name = __ATTR_RW(_name)
 #define BUS_ATTR_RO(_name) \
-- 
2.20.1



[PATCH 03/10] SCSI: fcoe: convert to use BUS_ATTR_WO

2018-12-20 Thread Greg Kroah-Hartman
We are trying to get rid of BUS_ATTR() and the usage of that in the fcoe
driver can be trivially converted to use BUS_ATTR_WO(), so use that
instead.

At the same time remove a unneeded EXPORT_SYMBOL() marking for the sysfs
callback function we are renaming, no idea of how that got into the
tree...

Cc: Johannes Thumshirn 
Cc: "James E.J. Bottomley" 
Cc: "Martin K. Petersen" 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/scsi/fcoe/fcoe_sysfs.c | 4 ++--
 drivers/scsi/fcoe/fcoe_transport.c | 7 ++-
 include/scsi/libfcoe.h | 6 ++
 3 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/scsi/fcoe/fcoe_sysfs.c b/drivers/scsi/fcoe/fcoe_sysfs.c
index 5c8310bade61..3c23b2624bd4 100644
--- a/drivers/scsi/fcoe/fcoe_sysfs.c
+++ b/drivers/scsi/fcoe/fcoe_sysfs.c
@@ -671,8 +671,8 @@ static const struct device_type fcoe_fcf_device_type = {
.release = fcoe_fcf_device_release,
 };
 
-static BUS_ATTR(ctlr_create, S_IWUSR, NULL, fcoe_ctlr_create_store);
-static BUS_ATTR(ctlr_destroy, S_IWUSR, NULL, fcoe_ctlr_destroy_store);
+static BUS_ATTR_WO(ctlr_create);
+static BUS_ATTR_WO(ctlr_destroy);
 
 static struct attribute *fcoe_bus_attrs[] = {
_attr_ctlr_create.attr,
diff --git a/drivers/scsi/fcoe/fcoe_transport.c 
b/drivers/scsi/fcoe/fcoe_transport.c
index f4909cd206d3..9edf82efda15 100644
--- a/drivers/scsi/fcoe/fcoe_transport.c
+++ b/drivers/scsi/fcoe/fcoe_transport.c
@@ -754,8 +754,7 @@ static int libfcoe_device_notification(struct 
notifier_block *notifier,
return NOTIFY_OK;
 }
 
-ssize_t fcoe_ctlr_create_store(struct bus_type *bus,
-  const char *buf, size_t count)
+ssize_t ctlr_create_store(struct bus_type *bus, const char *buf, size_t count)
 {
struct net_device *netdev = NULL;
struct fcoe_transport *ft = NULL;
@@ -817,8 +816,7 @@ ssize_t fcoe_ctlr_create_store(struct bus_type *bus,
return count;
 }
 
-ssize_t fcoe_ctlr_destroy_store(struct bus_type *bus,
-   const char *buf, size_t count)
+ssize_t ctlr_destroy_store(struct bus_type *bus, const char *buf, size_t count)
 {
int rc = -ENODEV;
struct net_device *netdev = NULL;
@@ -855,7 +853,6 @@ ssize_t fcoe_ctlr_destroy_store(struct bus_type *bus,
mutex_unlock(_mutex);
return rc;
 }
-EXPORT_SYMBOL(fcoe_ctlr_destroy_store);
 
 /**
  * fcoe_transport_create() - Create a fcoe interface
diff --git a/include/scsi/libfcoe.h b/include/scsi/libfcoe.h
index cb8a273732cf..44536f095681 100644
--- a/include/scsi/libfcoe.h
+++ b/include/scsi/libfcoe.h
@@ -405,10 +405,8 @@ int fcoe_transport_attach(struct fcoe_transport *ft);
 int fcoe_transport_detach(struct fcoe_transport *ft);
 
 /* sysfs store handler for ctrl_control interface */
-ssize_t fcoe_ctlr_create_store(struct bus_type *bus,
-  const char *buf, size_t count);
-ssize_t fcoe_ctlr_destroy_store(struct bus_type *bus,
-   const char *buf, size_t count);
+ssize_t ctlr_create_store(struct bus_type *bus, const char *buf, size_t count);
+ssize_t ctlr_destroy_store(struct bus_type *bus, const char *buf, size_t 
count);
 
 #endif /* _LIBFCOE_H */
 
-- 
2.20.1



[PATCH 05/10] rapidio: rio-sysfs.c: convert to use BUS_ATTR_WO

2018-12-20 Thread Greg Kroah-Hartman
We are trying to get rid of BUS_ATTR() and the usage of that in
rio-sysfs.c can be trivially converted to use BUS_ATTR_WO(), so use that
instead.

Cc: Matt Porter 
Cc: Alexandre Bounine 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/rapidio/rio-sysfs.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/rapidio/rio-sysfs.c b/drivers/rapidio/rio-sysfs.c
index 73e4b407f162..ad5e303dda05 100644
--- a/drivers/rapidio/rio-sysfs.c
+++ b/drivers/rapidio/rio-sysfs.c
@@ -290,8 +290,7 @@ const struct attribute_group *rio_dev_groups[] = {
NULL,
 };
 
-static ssize_t bus_scan_store(struct bus_type *bus, const char *buf,
-   size_t count)
+static ssize_t scan_store(struct bus_type *bus, const char *buf, size_t count)
 {
long val;
int rc;
@@ -314,7 +313,7 @@ static ssize_t bus_scan_store(struct bus_type *bus, const 
char *buf,
 
return rc;
 }
-static BUS_ATTR(scan, (S_IWUSR|S_IWGRP), NULL, bus_scan_store);
+static BUS_ATTR_WO(scan);
 
 static struct attribute *rio_bus_attrs[] = {
_attr_scan.attr,
-- 
2.20.1



[PATCH 04/10] pseries: ibmebus.c: convert to use BUS_ATTR_WO

2018-12-20 Thread Greg Kroah-Hartman
We are trying to get rid of BUS_ATTR() and the usage of that in
ibmebus.c can be trivially converted to use BUS_ATTR_WO(), so use that
instead.

Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Tyrel Datwyler 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/platforms/pseries/ibmebus.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/ibmebus.c 
b/arch/powerpc/platforms/pseries/ibmebus.c
index 5b4a56131904..84e8ec4011ba 100644
--- a/arch/powerpc/platforms/pseries/ibmebus.c
+++ b/arch/powerpc/platforms/pseries/ibmebus.c
@@ -261,8 +261,7 @@ static char *ibmebus_chomp(const char *in, size_t count)
return out;
 }
 
-static ssize_t ibmebus_store_probe(struct bus_type *bus,
-  const char *buf, size_t count)
+static ssize_t probe_store(struct bus_type *bus, const char *buf, size_t count)
 {
struct device_node *dn = NULL;
struct device *dev;
@@ -298,10 +297,9 @@ static ssize_t ibmebus_store_probe(struct bus_type *bus,
return rc;
return count;
 }
-static BUS_ATTR(probe, 0200, NULL, ibmebus_store_probe);
+static BUS_ATTR_WO(probe);
 
-static ssize_t ibmebus_store_remove(struct bus_type *bus,
-   const char *buf, size_t count)
+static ssize_t remove_store(struct bus_type *bus, const char *buf, size_t 
count)
 {
struct device *dev;
char *path;
@@ -325,7 +323,7 @@ static ssize_t ibmebus_store_remove(struct bus_type *bus,
return -ENODEV;
}
 }
-static BUS_ATTR(remove, 0200, NULL, ibmebus_store_remove);
+static BUS_ATTR_WO(remove);
 
 static struct attribute *ibmbus_bus_attrs[] = {
_attr_probe.attr,
-- 
2.20.1



[PATCH 06/10] block: rbd: convert to use BUS_ATTR_WO and RO

2018-12-20 Thread Greg Kroah-Hartman
We are trying to get rid of BUS_ATTR() and the usage of that in rbd.c
can be trivially converted to use BUS_ATTR_WO and RO, so use those
macros instead.

Cc: Ilya Dryomov 
Cc: Sage Weil 
Cc: Alex Elder 
Cc: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/block/rbd.c | 45 +++--
 1 file changed, 19 insertions(+), 26 deletions(-)

diff --git a/drivers/block/rbd.c b/drivers/block/rbd.c
index 8e5140bbf241..d871d364fdcf 100644
--- a/drivers/block/rbd.c
+++ b/drivers/block/rbd.c
@@ -428,14 +428,13 @@ static bool single_major = true;
 module_param(single_major, bool, 0444);
 MODULE_PARM_DESC(single_major, "Use a single major number for all rbd devices 
(default: true)");
 
-static ssize_t rbd_add(struct bus_type *bus, const char *buf,
-  size_t count);
-static ssize_t rbd_remove(struct bus_type *bus, const char *buf,
- size_t count);
-static ssize_t rbd_add_single_major(struct bus_type *bus, const char *buf,
-   size_t count);
-static ssize_t rbd_remove_single_major(struct bus_type *bus, const char *buf,
-  size_t count);
+static ssize_t add_store(struct bus_type *bus, const char *buf, size_t count);
+static ssize_t remove_store(struct bus_type *bus, const char *buf,
+   size_t count);
+static ssize_t add_single_major_store(struct bus_type *bus, const char *buf,
+ size_t count);
+static ssize_t remove_single_major_store(struct bus_type *bus, const char *buf,
+size_t count);
 static int rbd_dev_image_probe(struct rbd_device *rbd_dev, int depth);
 
 static int rbd_dev_id_to_minor(int dev_id)
@@ -464,16 +463,16 @@ static bool rbd_is_lock_owner(struct rbd_device *rbd_dev)
return is_lock_owner;
 }
 
-static ssize_t rbd_supported_features_show(struct bus_type *bus, char *buf)
+static ssize_t supported_features_show(struct bus_type *bus, char *buf)
 {
return sprintf(buf, "0x%llx\n", RBD_FEATURES_SUPPORTED);
 }
 
-static BUS_ATTR(add, 0200, NULL, rbd_add);
-static BUS_ATTR(remove, 0200, NULL, rbd_remove);
-static BUS_ATTR(add_single_major, 0200, NULL, rbd_add_single_major);
-static BUS_ATTR(remove_single_major, 0200, NULL, rbd_remove_single_major);
-static BUS_ATTR(supported_features, 0444, rbd_supported_features_show, NULL);
+static BUS_ATTR_WO(add);
+static BUS_ATTR_WO(remove);
+static BUS_ATTR_WO(add_single_major);
+static BUS_ATTR_WO(remove_single_major);
+static BUS_ATTR_RO(supported_features);
 
 static struct attribute *rbd_bus_attrs[] = {
_attr_add.attr,
@@ -5934,9 +5933,7 @@ static ssize_t do_rbd_add(struct bus_type *bus,
goto out;
 }
 
-static ssize_t rbd_add(struct bus_type *bus,
-  const char *buf,
-  size_t count)
+static ssize_t add_store(struct bus_type *bus, const char *buf, size_t count)
 {
if (single_major)
return -EINVAL;
@@ -5944,9 +5941,8 @@ static ssize_t rbd_add(struct bus_type *bus,
return do_rbd_add(bus, buf, count);
 }
 
-static ssize_t rbd_add_single_major(struct bus_type *bus,
-   const char *buf,
-   size_t count)
+static ssize_t add_single_major_store(struct bus_type *bus, const char *buf,
+ size_t count)
 {
return do_rbd_add(bus, buf, count);
 }
@@ -6050,9 +6046,7 @@ static ssize_t do_rbd_remove(struct bus_type *bus,
return count;
 }
 
-static ssize_t rbd_remove(struct bus_type *bus,
- const char *buf,
- size_t count)
+static ssize_t remove_store(struct bus_type *bus, const char *buf, size_t 
count)
 {
if (single_major)
return -EINVAL;
@@ -6060,9 +6054,8 @@ static ssize_t rbd_remove(struct bus_type *bus,
return do_rbd_remove(bus, buf, count);
 }
 
-static ssize_t rbd_remove_single_major(struct bus_type *bus,
-  const char *buf,
-  size_t count)
+static ssize_t remove_single_major_store(struct bus_type *bus, const char *buf,
+size_t count)
 {
return do_rbd_remove(bus, buf, count);
 }
-- 
2.20.1



[PATCH 00/10] Driver core: remove BUS_ATTR()

2018-12-20 Thread Greg Kroah-Hartman
In the quest to get rid of the need to specify any sysfs mode
attributes, let's get rid of BUS_ATTR() and move the few remaining users
of it over to use the "read write" and "write only" versions of the
macro.

Greg Kroah-Hartman (10):
  PCI: pci.c: convert to use BUS_ATTR_RW
  PCI: pci-sysfs.c: convert to use BUS_ATTR_WO
  SCSI: fcoe: convert to use BUS_ATTR_WO
  pseries: ibmebus.c: convert to use BUS_ATTR_WO
  rapidio: rio-sysfs.c: convert to use BUS_ATTR_WO
  block: rbd: convert to use BUS_ATTR_WO and RO
  driver core: bus: convert to use BUS_ATTR_WO and RW
  Documentation: driver core: remove use of BUS_ATTR
  driver core: drop use of BUS_ATTR()
  driver core: remove BUS_ATTR()

 Documentation/driver-model/bus.txt   |  8 ++---
 Documentation/filesystems/sysfs.txt  |  4 ++-
 arch/powerpc/platforms/pseries/ibmebus.c | 10 +++---
 drivers/base/bus.c   | 20 +++
 drivers/block/rbd.c  | 45 ++--
 drivers/pci/pci-sysfs.c  |  5 ++-
 drivers/pci/pci.c|  7 ++--
 drivers/rapidio/rio-sysfs.c  |  5 ++-
 drivers/scsi/fcoe/fcoe_sysfs.c   |  4 +--
 drivers/scsi/fcoe/fcoe_transport.c   |  7 ++--
 include/linux/device.h   |  2 --
 include/scsi/libfcoe.h   |  6 ++--
 12 files changed, 56 insertions(+), 67 deletions(-)

-- 
2.20.1



[PATCH 07/10] driver core: bus: convert to use BUS_ATTR_WO and RW

2018-12-20 Thread Greg Kroah-Hartman
We are trying to get rid of BUS_ATTR() and the usage of that in bus.c
can be trivially converted to use BUS_ATTR_WO and RW, so use those
macros instead.

Cc: "Rafael J. Wysocki" 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/base/bus.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 8bfd27ec73d6..f10d56c61a46 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -233,12 +233,12 @@ static ssize_t bind_store(struct device_driver *drv, 
const char *buf,
 }
 static DRIVER_ATTR_WO(bind);
 
-static ssize_t show_drivers_autoprobe(struct bus_type *bus, char *buf)
+static ssize_t drivers_autoprobe_show(struct bus_type *bus, char *buf)
 {
return sprintf(buf, "%d\n", bus->p->drivers_autoprobe);
 }
 
-static ssize_t store_drivers_autoprobe(struct bus_type *bus,
+static ssize_t drivers_autoprobe_store(struct bus_type *bus,
   const char *buf, size_t count)
 {
if (buf[0] == '0')
@@ -248,7 +248,7 @@ static ssize_t store_drivers_autoprobe(struct bus_type *bus,
return count;
 }
 
-static ssize_t store_drivers_probe(struct bus_type *bus,
+static ssize_t drivers_probe_store(struct bus_type *bus,
   const char *buf, size_t count)
 {
struct device *dev;
@@ -583,9 +583,8 @@ static void remove_bind_files(struct device_driver *drv)
driver_remove_file(drv, _attr_unbind);
 }
 
-static BUS_ATTR(drivers_probe, S_IWUSR, NULL, store_drivers_probe);
-static BUS_ATTR(drivers_autoprobe, S_IWUSR | S_IRUGO,
-   show_drivers_autoprobe, store_drivers_autoprobe);
+static BUS_ATTR_WO(drivers_probe);
+static BUS_ATTR_RW(drivers_autoprobe);
 
 static int add_probe_files(struct bus_type *bus)
 {
-- 
2.20.1



[PATCH 02/10] PCI: pci-sysfs.c: convert to use BUS_ATTR_WO

2018-12-20 Thread Greg Kroah-Hartman
We are trying to get rid of BUS_ATTR() and the usage of that in
pci-sysfs.c can be trivially converted to use BUS_ATTR_WO(), so use that
instead.

Cc: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/pci/pci-sysfs.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 9ecfe13157c0..25794c27c7a4 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -412,8 +412,7 @@ static ssize_t msi_bus_store(struct device *dev, struct 
device_attribute *attr,
 }
 static DEVICE_ATTR_RW(msi_bus);
 
-static ssize_t bus_rescan_store(struct bus_type *bus, const char *buf,
-   size_t count)
+static ssize_t rescan_store(struct bus_type *bus, const char *buf, size_t 
count)
 {
unsigned long val;
struct pci_bus *b = NULL;
@@ -429,7 +428,7 @@ static ssize_t bus_rescan_store(struct bus_type *bus, const 
char *buf,
}
return count;
 }
-static BUS_ATTR(rescan, (S_IWUSR|S_IWGRP), NULL, bus_rescan_store);
+static BUS_ATTR_WO(rescan);
 
 static struct attribute *pci_bus_attrs[] = {
_attr_rescan.attr,
-- 
2.20.1



[PATCH 09/10] driver core: drop use of BUS_ATTR()

2018-12-20 Thread Greg Kroah-Hartman
We are trying to get rid of BUS_ATTR() so drop the last user of it from
the tree.  We had to "open code" it in order to prevent a function name
conflict due to the use of DEVICE_ATTR_WO() earlier in the file :(

Cc: "Rafael J. Wysocki" 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/base/bus.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index f10d56c61a46..575bd6d752bd 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -830,7 +830,14 @@ static ssize_t bus_uevent_store(struct bus_type *bus,
kobject_synth_uevent(>p->subsys.kobj, buf, count);
return count;
 }
-static BUS_ATTR(uevent, S_IWUSR, NULL, bus_uevent_store);
+/*
+ * "open code" the old BUS_ATTR() macro here.  We want to use BUS_ATTR_WO()
+ * here, but can not use it as earlier in the file we have
+ * DEVICE_ATTR_WO(uevent), which would cause a clash with the with the store
+ * function name.
+ */
+static struct bus_attribute bus_attr_uevent = __ATTR(uevent, S_IWUSR, NULL,
+bus_uevent_store);
 
 /**
  * bus_register - register a driver-core subsystem
-- 
2.20.1



[PATCH 01/10] PCI: pci.c: convert to use BUS_ATTR_RW

2018-12-20 Thread Greg Kroah-Hartman
We are trying to get rid of BUS_ATTR() and the usage of that in pci.c
can be trivially converted to use BUS_ATTR_RW(), so use that instead.

Cc: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/pci/pci.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c9d8e3c837de..fda84538de79 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -6034,19 +6034,18 @@ static ssize_t pci_get_resource_alignment_param(char 
*buf, size_t size)
return count;
 }
 
-static ssize_t pci_resource_alignment_show(struct bus_type *bus, char *buf)
+static ssize_t resource_alignment_show(struct bus_type *bus, char *buf)
 {
return pci_get_resource_alignment_param(buf, PAGE_SIZE);
 }
 
-static ssize_t pci_resource_alignment_store(struct bus_type *bus,
+static ssize_t resource_alignment_store(struct bus_type *bus,
const char *buf, size_t count)
 {
return pci_set_resource_alignment_param(buf, count);
 }
 
-static BUS_ATTR(resource_alignment, 0644, pci_resource_alignment_show,
-   pci_resource_alignment_store);
+static BUS_ATTR_RW(resource_alignment);
 
 static int __init pci_resource_alignment_sysfs_init(void)
 {
-- 
2.20.1



[PATCH 08/10] Documentation: driver core: remove use of BUS_ATTR

2018-12-20 Thread Greg Kroah-Hartman
We are getting rid of the "raw" BUS_ATTR() macro, so fix up the
documentation to not refer to it anymore.

Cc: "Rafael J. Wysocki" 
Signed-off-by: Greg Kroah-Hartman 
---
 Documentation/driver-model/bus.txt  | 8 
 Documentation/filesystems/sysfs.txt | 4 +++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/Documentation/driver-model/bus.txt 
b/Documentation/driver-model/bus.txt
index b577a45b93ea..c247b488a567 100644
--- a/Documentation/driver-model/bus.txt
+++ b/Documentation/driver-model/bus.txt
@@ -124,11 +124,11 @@ struct bus_attribute {
ssize_t (*store)(struct bus_type *, const char * buf, size_t count);
 };
 
-Bus drivers can export attributes using the BUS_ATTR macro that works
-similarly to the DEVICE_ATTR macro for devices. For example, a definition 
-like this:
+Bus drivers can export attributes using the BUS_ATTR_RW macro that works
+similarly to the DEVICE_ATTR_RW macro for devices. For example, a
+definition like this:
 
-static BUS_ATTR(debug,0644,show_debug,store_debug);
+static BUS_ATTR_RW(debug);
 
 is equivalent to declaring:
 
diff --git a/Documentation/filesystems/sysfs.txt 
b/Documentation/filesystems/sysfs.txt
index a1426cabcef1..41411b0c60a3 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -344,7 +344,9 @@ struct bus_attribute {
 
 Declaring:
 
-BUS_ATTR(_name, _mode, _show, _store)
+static BUS_ATTR_RW(name);
+static BUS_ATTR_RO(name);
+static BUS_ATTR_WO(name);
 
 Creation/Removal:
 
-- 
2.20.1



Re: [PATCH 4.14 00/72] 4.14.90-stable review

2018-12-20 Thread Jinpu Wang
> From: Greg Kroah-Hartman 
> Date: 2018年12月20日周四 上午10:39
> Subject: [PATCH 4.14 00/72] 4.14.90-stable review
> To: 
> Cc: Greg Kroah-Hartman ,
> , ,
> , , ,
> , ,
> 
>
>
> This is the start of the stable review cycle for the 4.14.90 release.
> There are 72 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat Dec 22 08:59:06 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.90-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Merged, basic functional tests, no regression found.

Thanks,

-- 
Jack Wang
Linux Kernel Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
Phone: +49 30 57700-8042 | Fax: +49 30 57700-8598
E-mail: jinpu.w...@cloud.ionos.com | Web: www.ionos.de


Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim Weiss

Member of United Internet

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient of this e-mail, you are hereby
notified that saving, distribution or use of the content of this
e-mail in any way is prohibited. If you have received this e-mail in
error, please notify the sender and delete the e-mail.


Re: [PATCH V4 2/4] mmc: cqhci: DMA Configuration prior to CQE

2018-12-20 Thread Adrian Hunter
On 20/12/18 11:01 PM, Sowjanya Komatineni wrote:
> Hi Adrian,
> 
> Thank you for the feedback.
> 
>> This doesn't seem to relate to the host controller implementation.  
>> "The device" means the eMMC.
> 
> Yes, setting block size of 512B before enabling command queue is a device 
> specific 
> requirement not host specific. So thought to update in cqhci driver to follow 
> this 
> device specific sequence requirement. This also serves tegra sdhci host 
> strictly
> following this device specific requirement.

Not sure what you mean.  The eMMC block size is set by CMD16.  In fact CMD16
is not used because 512B is the default so it never needs to be changed.

> 
>> We don't want to disable and re-enable in the request function,
>> so that change is not good for controllers that don't have your problem.
>> Another thing to consider is that the block size register may not need to be 
>> changed
>> - for example when cqhci is halted to allow a manual discard, the block size 
>> register is
>> not updated, so I would expect its value to be unchanged.
> 
> Once block size is set prior to enabling CQE, it stays same till command 
> queue is 
> disabled and I don’t think it needs reconfiguration.
> 
>> There are ways you can solve this in your driver.  
>> You could look at using SDHCI I/O accessors, and/or implement your own 
>> ->enable() 
>> instead of calling sdhci_cqe_enable() directly.  Would that be feasible?
> 
> Sure, will provide updated patch that takes care of this inside tegra sdhci 
> host once you 
> confirm that we don’t plan to fix this device specific sequence requirement 
> in cqhci driver.
> 
> -Sowjanya
>  
> 



Re: [PATCH 1/2] dt-bindings: Add Qualcomm USB Super-Speed PHY bindings

2018-12-20 Thread Jorge Ramirez

On 12/20/18 18:07, Rob Herring wrote:

On Thu, Dec 20, 2018 at 10:52:45AM +0100, Jorge Ramirez-Ortiz wrote:

On 07/12/18 10:55:57, Jorge Ramirez-Ortiz wrote:

Binding description for Qualcomm's Synopsys 1.0.0 super-speed PHY
controller embedded in QCS404.

Based on Sriharsha Allenki's  original
definitions.

Signed-off-by: Jorge Ramirez-Ortiz 
Reviewed-by: Vinod Koul 

any follow up on this patchset?

Check DT patchwork[1] if you want to know where you are in the queue.
Just so happened to get to it now.


thanks for the info Rob. I honestly didnt know it operated in order! my 
fault




Rob

[1] https://patchwork.ozlabs.org/project/devicetree-bindings/list/





Re: [PATCH 1/2] dt-bindings: Add Qualcomm USB Super-Speed PHY bindings

2018-12-20 Thread Jorge Ramirez

On 12/20/18 18:37, Jack Pham wrote:

Hi Rob, Jorge,

On Thu, Dec 20, 2018 at 11:05:31AM -0600, Rob Herring wrote:

On Fri, Dec 07, 2018 at 10:55:57AM +0100, Jorge Ramirez-Ortiz wrote:

Binding description for Qualcomm's Synopsys 1.0.0 super-speed PHY
controller embedded in QCS404.

Based on Sriharsha Allenki's  original
definitions.

Signed-off-by: Jorge Ramirez-Ortiz 
Reviewed-by: Vinod Koul 
---
  .../devicetree/bindings/usb/qcom,usb-ssphy.txt | 78 ++
  1 file changed, 78 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/usb/qcom,usb-ssphy.txt

diff --git a/Documentation/devicetree/bindings/usb/qcom,usb-ssphy.txt 
b/Documentation/devicetree/bindings/usb/qcom,usb-ssphy.txt
new file mode 100644
index 000..fcf4e01
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/qcom,usb-ssphy.txt
@@ -0,0 +1,78 @@
+Qualcomm Synopsys 1.0.0 SS phy controller
+===
+
+Synopsys 1.0.0 ss phy controller supports SS usb connectivity on Qualcomm
+chipsets
+
+Required properties:
+
+- compatible:
+Value type: 
+Definition: Should contain "qcom,usb-ssphy".

What is "qcom,dwc3-ss-usb-phy" which already exists then?

Uh, apparently only the bindings doc is there but the driver never
landed. I guess it fell through the cracks nearly 4 years ago.

https://lore.kernel.org/patchwork/patch/499502/

Jorge, does Andy's version of this driver at all resemble what can be
used for QCS404?


the drivers seem quite different but I'll give it a go as well and 
compare (it is my understanding that the controller is the same - I will 
have access to the hardware documentation soon to compare)


but I'll come back to you on this.



Jack




Re: [PATCH] mfd: convert to DEFINE_SHOW_ATTRIBUTE

2018-12-20 Thread Lee Jones
On Fri, 21 Dec 2018, Frank Lee wrote:

> ping..

I've told you about this before:

"
Please don't do that.

If you think your patch has been missed, then please send it again as
a [RESEND].  In this case you will need to fix the $SUBJECT line too.
To see what it should look like do the following:
 
  `git log --oneline -- drivers/mfd`
 
Once fixed, s/[PATCH]/[RESEND/ and resubmit it.
"

In this case the $SUBJECT line is fine, but the rest is relevant.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 1/2] dt-bindings: Add Qualcomm USB Super-Speed PHY bindings

2018-12-20 Thread Jorge Ramirez

On 12/20/18 21:25, Stephen Boyd wrote:

Quoting Jorge Ramirez-Ortiz (2018-12-07 01:55:57)

+
+- qcom,vdd-voltage-level:
+Value type: 
+Definition: This is a list of three integer values  where
+each value corresponding to voltage corner in uV.

As far as I'm aware, this isn't how qcom's voltage corners are handled
or are going to be handled. Can't you hardcode it in the driver for now?




ok so you mean use a regulator to control the supply (with 
regulator-min-microvolt and max-microvolt properties instead?

I'll look into that

I guess we should pull back on this one as well?
https://lore.kernel.org/patchwork/patch/1026641/


RE: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for Arasan NAND Flash Controller

2018-12-20 Thread Naga Sureshkumar Relli
Hi Miquel,

> -Original Message-
> From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> Sent: Wednesday, December 19, 2018 7:57 PM
> To: Naga Sureshkumar Relli 
> Cc: Boris Brezillon ; r...@kernel.org; 
> rich...@nod.at;
> linux-kernel@vger.kernel.org; marek.va...@gmail.com; 
> linux-...@lists.infradead.org;
> nagasures...@gmail.com; Michal Simek ;
> computersforpe...@gmail.com; dw...@infradead.org; 
> martin.l...@keep-it-simple.com
> Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support for 
> Arasan
> NAND Flash Controller
> 
> Hi Naga,
> 
> + Martin
> 
> Naga Sureshkumar Relli  wrote on Tue, 18 Dec 2018
> 05:33:53 +:
> 
> > Hi Miquel,
> >
> > > -Original Message-
> > > From: Miquel Raynal [mailto:miquel.ray...@bootlin.com]
> > > Sent: Monday, December 17, 2018 10:11 PM
> > > To: Naga Sureshkumar Relli 
> > > Cc: Boris Brezillon ; r...@kernel.org;
> > > rich...@nod.at; linux- ker...@vger.kernel.org;
> > > marek.va...@gmail.com; linux-...@lists.infradead.org;
> > > nagasures...@gmail.com; Michal Simek ;
> > > computersforpe...@gmail.com; dw...@infradead.org
> > > Subject: Re: [LINUX PATCH v12 3/3] mtd: rawnand: arasan: Add support
> > > for Arasan NAND Flash Controller
> > >
> > > Hi Naga,
> > >
> > > [...]
> > >
> > > > Inserted biterror @ 48/7
> > > > Successfully corrected 25 bit errors per subpage Inserted biterror
> > > > @
> > > > 50/7 ECC failure, invalid data despite read success
> > > > root@xilinx-zc1751-dc2-2018_1:~#
> > > >
> > > > But even in this case also, driver is saying ECC failure but read 
> > > > success.
> > > > That means controller is able to detect errors on read page up to 24 
> > > > bit only.
> > > > After that there is no way to say to the upper layers that the
> > > > page is bad because of the
> > > limitation in the controller.
> > >
> > > This is more than a "limitation", the design is broken. I am not
> > > sure how to support such controller, and I am not sure if we even want to.
> >
> > The number of errors that are correctable is limited by a parameter
> > 't'(total number of errors), If there is a condition that the number of 
> > errors greater than 't',
> then the controller won't be able to detect that.
> > I guess this concept is same for other controllers as well.
> > In Arasan it is limited to 24-bit.
> >
> > Even, in case of Hamming, it is 1-bit error correction and 2-bit error 
> > detection.
> > What will happen if there are multiple errors(greater than 2-bit)?
> 
> Ok let's use the Hamming comparison in your ECC engine case.
> 
> -> hamming:
>  * 0 bf: everything is fine
>  * 1 bf: will be detected, corrected, signaled
>  * 2 bf: will be detected, not corrected, signaled
>  * 3+ bf: don't care
> 
> -> BCH:
>  * 0 bf: everything is fine
>  * 1-24 bf: will be detected, corrected, signaled
>  * 25 bf: everything is fine
>  * 26+ bf: don't care
> 
> Do you see the problem?
No.
> 
> In the 25 bf case, the controller is reporting that everything went fine 
> while it should report
> that it detected an uncorrectable situation.
> 
> Here are two leads to solve this issue, please investigate them both:
> 1/ Talk to your colleagues that developed the RTL, ask if there is a
>hidden/reserved bit for that purpose that is not documented.
I spoke to RTL guys, there is nothing hidden/reserved bit for this purpose.
I tried reading the status registers reserved bits, but they are raz(read as 
zero)

> 2/ Search for a status in the registers that might indicate that an
>error occurred, for instance "0 bf corrected" and "bf have been
>detected".
I tried reading status registers and other registers as well, but no luck.
> 
> NB: I know that, with a BCH ECC engine, error detection at (strength +
> 1) is not 100% sure but statistically it will almost always be detected and 
> in this case we
> need the controller to warn the user!
Ok, I understood now.

Thanks,
Naga Sureshkumar Relli
> 
> 
> Thanks,
> Miquèl


Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver

2018-12-20 Thread Jacek Anaszewski

On 12/20/18 9:31 PM, Jacek Anaszewski wrote:

On 12/19/18 10:50 PM, Dan Murphy wrote:

On 12/19/2018 03:36 PM, Jacek Anaszewski wrote:

Hi Dan and Pavel,

On 12/19/18 9:41 PM, Dan Murphy wrote:

Pavel

On 12/19/2018 02:10 PM, Pavel Machek wrote:

On Wed 2018-12-19 13:41:18, Dan Murphy wrote:

Pavel

Thanks for the review.

On 12/19/2018 01:34 PM, Pavel Machek wrote:

Hi!


+static DEVICE_ATTR_WO(ctrl_bank_a_mix);
+static DEVICE_ATTR_WO(ctrl_bank_b_mix);
+static DEVICE_ATTR_WO(ctrl_bank_c_mix);
+
+static struct attribute *lp5024_ctrl_bank_attrs[] = {
+    _attr_ctrl_bank_a_mix.attr,
+    _attr_ctrl_bank_b_mix.attr,
+    _attr_ctrl_bank_c_mix.attr,
+    NULL
+};
+ATTRIBUTE_GROUPS(lp5024_ctrl_bank);


...

+
+static DEVICE_ATTR_WO(led1_mix);
+static DEVICE_ATTR_WO(led2_mix);
+static DEVICE_ATTR_WO(led3_mix);
+
+static struct attribute *lp5024_led_independent_attrs[] = {
+    _attr_led1_mix.attr,
+    _attr_led2_mix.attr,
+    _attr_led3_mix.attr,
+    NULL
+};
+ATTRIBUTE_GROUPS(lp5024_led_independent);


Ok, so you are adding new sysfs files. Are they _really_ neccessary?
We'd like to have uniform interfaces for the leds.


Yes I am adding these for this driver.
They adjust the individual brightness of each LED connected (what 
the HW guys called mixing).


The standard brightness sysfs adjusts all 3 LEDs simultaneously so 
that all 3 LEDs brightness are

uniform.


1 LED, 1 brightness file... that's what we do. Why should this one 
be different?




Yes I understand this and 1 DT child node per LED out but...

This device has a single register to control 3 LEDs brightness as a 
group and individual brightness
registers to control the LEDs independently to mix the LEDs to a 
specific color.


There needs to be a way to control both so that developers can mix 
and adjust the individual RGB and
then control the brightness of the group during run time without 
touching the "mixing" value.


I don't think a user needs nor would want to have 24 different LED 
nodes with 24 different brightness files.

Or with the LP5036 that would have 36 LED nodes.

Table 1 in the data sheet shows how the outputs map to the control 
banks to the LED registers.


Some time ago we had discussion with Vesa Jääskeläinen about possible
approaches to RGB LEDs [0]. What seemed to be the most suitable
variation of the discussed out-of-tree approach was the "color" property
and array of color triplets defined in Device Tree per each color.



Why does Device tree define the color?

Rob indicated that Device tree is supposed to define the hardware.
This thread seems to be defining the operation.


Perceived colors produced by LEDs from different manufacturers may
differ and this alone should be deemed a sufficient argument for having
board specific color definitions.


Shouldn't the color be done via user space and not dt?


I think that we should keep the userspace interface as simple
as possible and backwards compatible with monochrome LEDs.

I also propose to avoid the introduction of a color sysfs
property in favor of creating separate LED class devices
for different "color ranges". The devices would drive the same
LED but using different preset color levels.


On the other hand, scattering the control over the hardware
among multiple LED class devices would complicate extension
of pattern trigger with the support for RGB LEDs.

I looks like we will need the "color" sysfs file  anyway.


We don't have to expose all device knobs to the userspace,
but instead provide some predefined configurations. It would
improve user experience by keeping LED class devices simple
in use. It would be Device Tree designer's responsibility to
provide color definitions that make sense for given RGB LED
controller and RGB LED element configuration.

Registering color palette with devm_rgb_register() you proposed
is also an option, but with one LED class device per color palette
it would mean allowing for creation/destruction of LED class
devices by any user having access to given LED's sysfs interface,
which is really bad solution.


With the "color" sysfs file it will make more sense to allow for user
defined color palettes.

--
Best regards,
Jacek Anaszewski


Re: [RFC][PATCH] printk: increase devkmsg write() ratelimit

2018-12-20 Thread Sergey Senozhatsky
On (12/20/18 08:58), Steven Rostedt wrote:
> > > Userspace processes should never be able to overwrite messages
> > > from the kernel.
> > 
> > I would agree.
> > 
> > It's a bit funny that kernel people first take the patch in and then,
> > when user-space begins to use the feature, start to object and ratelimit.
> 
> Please note the "kernel people" to first take it in, were also systemd
> developers.

Good point.

> Honestly, it should have been a separate buffer to begin with, and I
> wish I pushed for that when it was first added. It's not too late. We
> can still make it a separate buffer.

Ideally, yes, separating them will make sense.

[..]
> When the system is up and running, it works. But I believe systemd can
> still only use ksmsg for initial boot up messages before it does the
> chroot.
[..]
> Do you get systemd messages before chroot with this patch compared to
> what you get without it?

You are right.

systemd cannot log anything really early - there should be /dev/kmsg char
device so they can open() it and write() to it. IOW only after chr_dev_init()
they can append messages to devkmsg. Which is still early enough, perhaps
earlier than UART init. systemd can log to tty, but unlike logbuf messages,
messages written to tty cannot be re-played:

+->  chr_dev_init() create /dev/kmsg
|  persistent storage is not mounted yet
|  writes to /dev/kmsg work
|  ...
|chroot
|mount /dev/sdX
+->  journald starts
 pulls logbuf (devkmsg)
 syslog now works
 "systemd[1]: Starting Flush Journal to Persistent Storage..."

So without devkmsg some early systemd messages can be lost (between
chr_dev_init() and exec(journald)), just like you said; or (best case)
will go to serial log. Messages before chr_dev_init() will be lost
because there is no /dev/kmsg; messages after exec(journald) do not
necessarily depend on /dev/kmsg and can be logged via syslog/journal
interface.

-ss


Re: [PATCHv2] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

2018-12-20 Thread Baoquan He
On 12/21/18 at 03:18pm, Baoquan He wrote:
> On 12/14/18 at 12:07pm, Pingfan Liu wrote:
> > Customer reported a bug on a high end server with many pcie devices, where
> > kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> > though we still see much memory under 896 MB, the finding still failed
> > intermittently. Because currently we can only find region under 896 MB,
> > if w/0 ',high' specified. Then KASLR breaks 896 MB into several parts
> > randomly, and crashkernel reservation need be aligned to 128 MB, that's
> > why failure is found. It raises confusion to the end user that sometimes
> > crashkernel=X works while sometimes fails.
> > If want to make it succeed, customer can change kernel option to
> > "crashkernel=384M, high". Just this give "crashkernel=xx@yy" a very
> > limited space to behave even though its grammer looks more generic.
> > And we can't answer questions raised from customer that confidently:
> > 1) why it doesn't succeed to reserve 896 MB;
> > 2) what's wrong with memory region under 4G;
> > 3) why I have to add ',high', I only require 384 MB, not 3840 MB.
> > 
> > This patch simplifies the method suggested in the mail [1]. It just goes
> > bottom-up to find a candidate region for crashkernel. The bottom-up may be
> > better compatible with the old reservation style, i.e. still want to get
> > memory region from 896 MB firstly, then [896 MB, 4G], finally above 4G.
> > 
> > There is one trivial thing about the compatibility with old kexec-tools:
> > if the reserved region is above 896M, then old tool will fail to load
> > bzImage. But without this patch, the old tool also fail since there is no
> > memory below 896M can be reserved for crashkernel.
> > 
> > [1]: http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
> > Signed-off-by: Pingfan Liu 
> > Cc: Dave Young 
> > Cc: Andrew Morton 
> > Cc: Baoquan He 
> > Cc: ying...@kernel.org,
> > Cc: vgo...@redhat.com
> > Cc: ke...@lists.infradead.org
> > 
> > ---
> > v1->v2:
> >   improve commit log
> >  arch/x86/kernel/setup.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> This is a bug fix and urged by our customer.
> 
> I personally think crashkernel=xx@ is a generic synctax, the current
 ~~ s/@/M
> code making it search only under 896 MB seems not so reasonable.
> 
> Ack this patch.
> 
> Acked-by: Baoquan He 
> 
> Thanks
> Baoquan
> 
> > 
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index d494b9b..60f12c4 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -541,15 +541,18 @@ static void __init reserve_crashkernel(void)
> >  
> > /* 0 means: find the address automatically */
> > if (crash_base <= 0) {
> > +   if (!memblock_bottom_up())
> > +   memblock_set_bottom_up(true);
> > /*
> >  * Set CRASH_ADDR_LOW_MAX upper bound for crash memory,
> >  * as old kexec-tools loads bzImage below that, unless
> >  * "crashkernel=size[KMG],high" is specified.
> >  */
> > crash_base = memblock_find_in_range(CRASH_ALIGN,
> > -   high ? CRASH_ADDR_HIGH_MAX
> > -: CRASH_ADDR_LOW_MAX,
> > -   crash_size, CRASH_ALIGN);
> > +   (max_pfn * PAGE_SIZE), crash_size, CRASH_ALIGN);
> > +   if (!memblock_bottom_up())
> > +   memblock_set_bottom_up(false);
> > +
> > if (!crash_base) {
> > pr_info("crashkernel reservation failed - No suitable 
> > area found.\n");
> > return;
> > -- 
> > 2.7.4
> > 


[PATCH 05/21] PCI: imx6: Remove PCIE_PL_PFLR_* constants

2018-12-20 Thread Andrey Smirnov
Code using these constants was removed in commit a71280722eeb ("PCI:
imx6: Remove LTSSM disable workaround"). No functional change
intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 2265f4b40e39..60803f1f16f8 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -82,9 +82,6 @@ struct imx6_pcie {
 
 /* PCIe Port Logic registers (memory-mapped) */
 #define PL_OFFSET 0x700
-#define PCIE_PL_PFLR (PL_OFFSET + 0x08)
-#define PCIE_PL_PFLR_LINK_STATE_MASK   (0x3f << 16)
-#define PCIE_PL_PFLR_FORCE_LINK(1 << 15)
 #define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
 #define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
 #define PCIE_PHY_DEBUG_R1_XMLH_LINK_IN_TRAINING(1 << 29)
-- 
2.19.1



[PATCH 02/21] PCI: imx6: Remove redundant debug tracing

2018-12-20 Thread Andrey Smirnov
All calls to imx6_pcie_wait_for_link() share the same error path and
the state of PHY debug registers will already be printed there.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index c87ecc305dc7..6ffadc29d21b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -603,16 +603,9 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
 static int imx6_pcie_wait_for_link(struct imx6_pcie *imx6_pcie)
 {
struct dw_pcie *pci = imx6_pcie->pci;
-   struct device *dev = pci->dev;
 
/* check if the link is up or not */
-   if (!dw_pcie_wait_for_link(pci))
-   return 0;
-
-   dev_dbg(dev, "DEBUG_R0: 0x%08x, DEBUG_R1: 0x%08x\n",
-   dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R0),
-   dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R1));
-   return -ETIMEDOUT;
+   return dw_pcie_wait_for_link(pci);
 }
 
 static int imx6_pcie_wait_for_speed_change(struct imx6_pcie *imx6_pcie)
-- 
2.19.1



[PATCH 03/21] PCI: imx6: Return -ETIMEOUT from imx6_pcie_wait_for_speed_change()

2018-12-20 Thread Andrey Smirnov
Change error code from EINVAL to ETIMEDOUT in
imx6_pcie_wait_for_speed_change() since that error code seems more
appropriate.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 6ffadc29d21b..e990030564d8 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -624,7 +624,7 @@ static int imx6_pcie_wait_for_speed_change(struct imx6_pcie 
*imx6_pcie)
}
 
dev_err(dev, "Speed change timeout\n");
-   return -EINVAL;
+   return -ETIMEDOUT;
 }
 
 static void imx6_pcie_ltssm_enable(struct device *dev)
-- 
2.19.1



[PATCH 06/21] PCI: imx6: Remove PCIE_PHY_RX_ASIC_OUT* constants

2018-12-20 Thread Andrey Smirnov
Code using these constants was removed in commit a77c5422d758 ("PCI:
imx6: Remove broken Gen2 workaround"). No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 60803f1f16f8..937d630f8c9d 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -108,9 +108,6 @@ struct imx6_pcie {
 #define  PCIE_PHY_MPLL_MULTIPLIER_MASK 0x7f
 #define  PCIE_PHY_MPLL_MULTIPLIER_OVRD (0x1 << 9)
 
-#define PCIE_PHY_RX_ASIC_OUT 0x100D
-#define PCIE_PHY_RX_ASIC_OUT_VALID (1 << 0)
-
 #define PHY_RX_OVRD_IN_LO 0x1005
 #define PHY_RX_OVRD_IN_LO_RX_DATA_EN (1 << 5)
 #define PHY_RX_OVRD_IN_LO_RX_PLL_EN (1 << 3)
-- 
2.19.1



[PATCH 07/21] PCI: designware: Make use of IS_ALIGNED()

2018-12-20 Thread Andrey Smirnov
Make the intent a bit more clear as well as get rid of explicit
arithmetic by using IS_ALIGNED() to determine if "addr" is aligned to
"size". No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pcie-designware.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 93ef8c31fb39..67236379c61a 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -22,7 +22,7 @@
 
 int dw_pcie_read(void __iomem *addr, int size, u32 *val)
 {
-   if ((uintptr_t)addr & (size - 1)) {
+   if (!IS_ALIGNED((uintptr_t)addr, size)) {
*val = 0;
return PCIBIOS_BAD_REGISTER_NUMBER;
}
@@ -43,7 +43,7 @@ int dw_pcie_read(void __iomem *addr, int size, u32 *val)
 
 int dw_pcie_write(void __iomem *addr, int size, u32 val)
 {
-   if ((uintptr_t)addr & (size - 1))
+   if (!IS_ALIGNED((uintptr_t)addr, size))
return PCIBIOS_BAD_REGISTER_NUMBER;
 
if (size == 4)
-- 
2.19.1



Re: [PATCH] MAINTAINERS: update Android binder

2018-12-20 Thread Christian Brauner
On December 20, 2018 1:13:26 PM GMT+01:00, Martijn Coenen  
wrote:
>Thanks Christian for signing up!
>
>On Thu, Dec 20, 2018 at 12:09 PM Greg KH 
>wrote:
>> Ok, no objection from me, Todd/Martijn/Joel/Arve, can I get an ack
>from
>> someone?
>
>Acked-By: Martijn Coenen 

Thanks Martijn! Happy holidays!
Christian

>
>>
>> thanks,
>>
>> greg k-h



[PATCH] percpu_rwsem: fix missed wakeup due to reordering of load

2018-12-20 Thread Prateek Sood
P1 is releaseing the cpu_hotplug_lock and P2 is acquiring
cpu_hotplug_lock.

P1   P2
percpu_up_read() path  percpu_down_write() path

  rcu_sync_enter() //gp_state=GP_PASSED

rcu_sync_is_idle() //returns falsedown_write(rw_sem)

__percpu_up_read()

[L] task = rcu_dereference(w->task) //NULL

smp_rmb()  [S] w->task = current

smp_mb()

   [L] readers_active_check() //fails
 schedule()

[S] __this_cpu_dec(read_count)

Since load of task can result in NULL, it can lead to missed wakeup
in rcuwait_wake_up(). Above sequence violated the following constraint
in rcuwait_wake_up():

 WAITWAKE
[S] tsk = current [S] cond = true
MB (A)  MB (B)
[L] cond  [L] tsk

This can happen as smp_rmb() in rcuwait_wake_up() will provide ordering
of load before barrier with load and store after barrier for arm64
architecture. Here the requirement is to order store before smp_rmb()
with load after the smp_rmb().

For the usage of rcuwait_wake_up() in __percpu_up_read() full barrier
(smp_mb) is required to complete the constraint of rcuwait_wake_up().

Signed-off-by: Prateek Sood 
Acked-by: Davidlohr Bueso 

---
 kernel/exit.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/exit.c b/kernel/exit.c
index ac1a814..696e0e1 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -298,7 +298,7 @@ void rcuwait_wake_up(struct rcuwait *w)
/*
 * Order condition vs @task, such that everything prior to the load
 * of @task is visible. This is the condition as to why the user called
-* rcuwait_trywake() in the first place. Pairs with set_current_state()
+* rcuwait_wake_up() in the first place. Pairs with set_current_state()
 * barrier (A) in rcuwait_wait_event().
 *
 *WAITWAKE
@@ -306,7 +306,7 @@ void rcuwait_wake_up(struct rcuwait *w)
 *MB (A)  MB (B)
 *[L] cond[L] tsk
 */
-   smp_rmb(); /* (B) */
+   smp_mb(); /* (B) */
 
/*
 * Avoid using task_rcu_dereference() magic as long as we are careful,
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., 
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.



[PATCH 11/21] PCI: designware: Make use of BIT() in constant definitions

2018-12-20 Thread Andrey Smirnov
Avoid using explicit left shifts and convert various definitions to
use BIT() instead. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pcie-designware.c |  2 +-
 drivers/pci/controller/dwc/pcie-designware.h | 18 +-
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index d123ac290b9e..086e87a40316 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -300,7 +300,7 @@ void dw_pcie_disable_atu(struct dw_pcie *pci, int index,
}
 
dw_pcie_writel_dbi(pci, PCIE_ATU_VIEWPORT, region | index);
-   dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, ~PCIE_ATU_ENABLE);
+   dw_pcie_writel_dbi(pci, PCIE_ATU_CR2, (u32)~PCIE_ATU_ENABLE);
 }
 
 int dw_pcie_wait_for_link(struct dw_pcie *pci)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 58735fd01668..348e91b6daa2 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -40,11 +40,11 @@
 #define PORT_LOGIC_LTSSM_STATE_MASK0x1f
 #define PORT_LOGIC_LTSSM_STATE_L0  0x11
 #define PCIE_PORT_DEBUG1   0x72C
-#define PCIE_PORT_DEBUG1_LINK_UP   (0x1 << 4)
-#define PCIE_PORT_DEBUG1_LINK_IN_TRAINING  (0x1 << 29)
+#define PCIE_PORT_DEBUG1_LINK_UP   BIT(4)
+#define PCIE_PORT_DEBUG1_LINK_IN_TRAINING  BIT(29)
 
 #define PCIE_LINK_WIDTH_SPEED_CONTROL  0x80C
-#define PORT_LOGIC_SPEED_CHANGE(0x1 << 17)
+#define PORT_LOGIC_SPEED_CHANGEBIT(17)
 #define PORT_LOGIC_LINK_WIDTH_MASK (0x1f << 8)
 #define PORT_LOGIC_LINK_WIDTH_1_LANES  (0x1 << 8)
 #define PORT_LOGIC_LINK_WIDTH_2_LANES  (0x2 << 8)
@@ -58,8 +58,8 @@
 #define PCIE_MSI_INTR0_STATUS  0x830
 
 #define PCIE_ATU_VIEWPORT  0x900
-#define PCIE_ATU_REGION_INBOUND(0x1 << 31)
-#define PCIE_ATU_REGION_OUTBOUND   (0x0 << 31)
+#define PCIE_ATU_REGION_INBOUNDBIT(31)
+#define PCIE_ATU_REGION_OUTBOUND   0
 #define PCIE_ATU_REGION_INDEX2 (0x2 << 0)
 #define PCIE_ATU_REGION_INDEX1 (0x1 << 0)
 #define PCIE_ATU_REGION_INDEX0 (0x0 << 0)
@@ -69,8 +69,8 @@
 #define PCIE_ATU_TYPE_CFG0 (0x4 << 0)
 #define PCIE_ATU_TYPE_CFG1 (0x5 << 0)
 #define PCIE_ATU_CR2   0x908
-#define PCIE_ATU_ENABLE(0x1 << 31)
-#define PCIE_ATU_BAR_MODE_ENABLE   (0x1 << 30)
+#define PCIE_ATU_ENABLEBIT(31)
+#define PCIE_ATU_BAR_MODE_ENABLE   BIT(30)
 #define PCIE_ATU_LOWER_BASE0x90C
 #define PCIE_ATU_UPPER_BASE0x910
 #define PCIE_ATU_LIMIT 0x914
@@ -81,7 +81,7 @@
 #define PCIE_ATU_UPPER_TARGET  0x91C
 
 #define PCIE_MISC_CONTROL_1_OFF0x8BC
-#define PCIE_DBI_RO_WR_EN  (0x1 << 0)
+#define PCIE_DBI_RO_WR_EN  BIT(0)
 
 /*
  * iATU Unroll-specific register definitions
@@ -108,7 +108,7 @@
((region) << 9)
 
 #define PCIE_GET_ATU_INB_UNR_REG_OFFSET(region) \
-   (((region) << 9) | (0x1 << 8))
+   (((region) << 9) | BIT(8))
 
 #define MAX_MSI_IRQS   256
 #define MAX_MSI_IRQS_PER_CTRL  32
-- 
2.19.1



[PATCH 10/21] PCI: designware: imx6: Share PHY debug register definitions

2018-12-20 Thread Andrey Smirnov
Both pcie-designware.c and pci-imx6.c contain custom definitions for
PHY debug registers R0/R1 and on top of that there's already a
definition for R0 in pcie-designware.h. Move all of the definitions to
pcie-designware.h. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c|  6 ++
 drivers/pci/controller/dwc/pcie-designware.c | 12 +++-
 drivers/pci/controller/dwc/pcie-designware.h |  3 +++
 3 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 74faca11eeae..c0b073cf20c0 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -82,8 +82,6 @@ struct imx6_pcie {
 
 /* PCIe Port Logic registers (memory-mapped) */
 #define PL_OFFSET 0x700
-#define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
-#define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
 
 #define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
 #define PCIE_PHY_CTRL_DATA_LOC 0
@@ -706,8 +704,8 @@ static int imx6_pcie_establish_link(struct imx6_pcie 
*imx6_pcie)
 
 err_reset_phy:
dev_dbg(dev, "PHY DEBUG_R0=0x%08x DEBUG_R1=0x%08x\n",
-   dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R0),
-   dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R1));
+   dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG0),
+   dw_pcie_readl_dbi(pci, PCIE_PORT_DEBUG1));
imx6_pcie_reset_phy(imx6_pcie);
return ret;
 }
diff --git a/drivers/pci/controller/dwc/pcie-designware.c 
b/drivers/pci/controller/dwc/pcie-designware.c
index 67236379c61a..d123ac290b9e 100644
--- a/drivers/pci/controller/dwc/pcie-designware.c
+++ b/drivers/pci/controller/dwc/pcie-designware.c
@@ -14,12 +14,6 @@
 
 #include "pcie-designware.h"
 
-/* PCIe Port Logic registers */
-#define PLR_OFFSET 0x700
-#define PCIE_PHY_DEBUG_R1  (PLR_OFFSET + 0x2c)
-#define PCIE_PHY_DEBUG_R1_LINK_UP  (0x1 << 4)
-#define PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING (0x1 << 29)
-
 int dw_pcie_read(void __iomem *addr, int size, u32 *val)
 {
if (!IS_ALIGNED((uintptr_t)addr, size)) {
@@ -334,9 +328,9 @@ int dw_pcie_link_up(struct dw_pcie *pci)
if (pci->ops->link_up)
return pci->ops->link_up(pci);
 
-   val = readl(pci->dbi_base + PCIE_PHY_DEBUG_R1);
-   return ((val & PCIE_PHY_DEBUG_R1_LINK_UP) &&
-   (!(val & PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING)));
+   val = readl(pci->dbi_base + PCIE_PORT_DEBUG1);
+   return ((val & PCIE_PORT_DEBUG1_LINK_UP) &&
+   (!(val & PCIE_PORT_DEBUG1_LINK_IN_TRAINING)));
 }
 
 void dw_pcie_setup(struct dw_pcie *pci)
diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 9943d8c68335..58735fd01668 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -39,6 +39,9 @@
 #define PCIE_PORT_DEBUG0   0x728
 #define PORT_LOGIC_LTSSM_STATE_MASK0x1f
 #define PORT_LOGIC_LTSSM_STATE_L0  0x11
+#define PCIE_PORT_DEBUG1   0x72C
+#define PCIE_PORT_DEBUG1_LINK_UP   (0x1 << 4)
+#define PCIE_PORT_DEBUG1_LINK_IN_TRAINING  (0x1 << 29)
 
 #define PCIE_LINK_WIDTH_SPEED_CONTROL  0x80C
 #define PORT_LOGIC_SPEED_CHANGE(0x1 << 17)
-- 
2.19.1



[PATCH 09/21] PCI: imx6: Drop imx6_pcie_link_up()

2018-12-20 Thread Andrey Smirnov
Until commit 4d107d3b5a68 ("PCI: imx6: Move link up check into
imx6_pcie_wait_for_link()") the driver relied on both LINK_UP and
LINK_IN_TRAINING to determine if PCIE link was up.

I can't seem to find out why, but code using LINK_IN_TRAINING seem to
disappear after commit 886bc5ceb5cc ("PCI: designware: Add generic
dw_pcie_wait_for_link()") and from then on only LINK_UP seems to be
tested (dw_pcie_wait_for_link() -> dw_pcie_link_up() ->
imx6_pcie_link_up()).

At the same time the default behavior of dw_pcie_link_up() went from
using just LINK_UP in commit dac29e6c5460 ("PCI: designware: Add
default link up check if sub-driver doesn't override") to using both
LINK_IN_TRAINING and LINK_UP in commit 01c076732e82 ("PCI: designware:
Check LTSSM training bit before deciding link is up").

Given all that it seems that i.MX6 doesn't really need a special
.link_up() callback and imx6_pcie_link_up() can be dropped.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 937d630f8c9d..74faca11eeae 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -84,8 +84,6 @@ struct imx6_pcie {
 #define PL_OFFSET 0x700
 #define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)
 #define PCIE_PHY_DEBUG_R1 (PL_OFFSET + 0x2c)
-#define PCIE_PHY_DEBUG_R1_XMLH_LINK_IN_TRAINING(1 << 29)
-#define PCIE_PHY_DEBUG_R1_XMLH_LINK_UP (1 << 4)
 
 #define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
 #define PCIE_PHY_CTRL_DATA_LOC 0
@@ -732,12 +730,6 @@ static int imx6_pcie_host_init(struct pcie_port *pp)
return 0;
 }
 
-static int imx6_pcie_link_up(struct dw_pcie *pci)
-{
-   return dw_pcie_readl_dbi(pci, PCIE_PHY_DEBUG_R1) &
-   PCIE_PHY_DEBUG_R1_XMLH_LINK_UP;
-}
-
 static const struct dw_pcie_host_ops imx6_pcie_host_ops = {
.host_init = imx6_pcie_host_init,
 };
@@ -769,9 +761,7 @@ static int imx6_add_pcie_port(struct imx6_pcie *imx6_pcie,
return 0;
 }
 
-static const struct dw_pcie_ops dw_pcie_ops = {
-   .link_up = imx6_pcie_link_up,
-};
+static const struct dw_pcie_ops dw_pcie_ops;
 
 #ifdef CONFIG_PM_SLEEP
 static void imx6_pcie_ltssm_disable(struct device *dev)
-- 
2.19.1



[PATCH 13/21] PCI: imx6: Simplify bit operations in PHY functions

2018-12-20 Thread Andrey Smirnov
Simplify the code by incorporating left shifts into constant
defnitions as well as using FIELD_PREP/GENMASK. No functional change
intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 28 +--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 2737526158fa..40d348bb9a2b 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -84,11 +84,11 @@ struct imx6_pcie {
 #define PL_OFFSET 0x700
 
 #define PCIE_PHY_CTRL (PL_OFFSET + 0x114)
-#define PCIE_PHY_CTRL_DATA_LOC 0
-#define PCIE_PHY_CTRL_CAP_ADR_LOC 16
-#define PCIE_PHY_CTRL_CAP_DAT_LOC 17
-#define PCIE_PHY_CTRL_WR_LOC 18
-#define PCIE_PHY_CTRL_RD_LOC 19
+#define PCIE_PHY_CTRL_DATA(x)  FIELD_PREP(GENMASK(15, 0), (x))
+#define PCIE_PHY_CTRL_CAP_ADR  BIT(16)
+#define PCIE_PHY_CTRL_CAP_DAT  BIT(17)
+#define PCIE_PHY_CTRL_WR   BIT(18)
+#define PCIE_PHY_CTRL_RD   BIT(19)
 
 #define PCIE_PHY_STAT (PL_OFFSET + 0x110)
 #define PCIE_PHY_STAT_ACK_LOC 16
@@ -135,17 +135,17 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie, 
int addr)
u32 val;
int ret;
 
-   val = addr << PCIE_PHY_CTRL_DATA_LOC;
+   val = PCIE_PHY_CTRL_DATA(addr);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
 
-   val |= (0x1 << PCIE_PHY_CTRL_CAP_ADR_LOC);
+   val |= PCIE_PHY_CTRL_CAP_ADR;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
 
ret = pcie_phy_poll_ack(imx6_pcie, 1);
if (ret)
return ret;
 
-   val = addr << PCIE_PHY_CTRL_DATA_LOC;
+   val = PCIE_PHY_CTRL_DATA(addr);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, val);
 
return pcie_phy_poll_ack(imx6_pcie, 0);
@@ -163,7 +163,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, int *data)
return ret;
 
/* assert Read signal */
-   phy_ctl = 0x1 << PCIE_PHY_CTRL_RD_LOC;
+   phy_ctl = PCIE_PHY_CTRL_RD;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, phy_ctl);
 
ret = pcie_phy_poll_ack(imx6_pcie, 1);
@@ -191,11 +191,11 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, 
int addr, int data)
if (ret)
return ret;
 
-   var = data << PCIE_PHY_CTRL_DATA_LOC;
+   var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* capture data */
-   var |= (0x1 << PCIE_PHY_CTRL_CAP_DAT_LOC);
+   var |= PCIE_PHY_CTRL_CAP_DAT;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
ret = pcie_phy_poll_ack(imx6_pcie, 1);
@@ -203,7 +203,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
return ret;
 
/* deassert cap data */
-   var = data << PCIE_PHY_CTRL_DATA_LOC;
+   var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack de-assertion */
@@ -212,7 +212,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
return ret;
 
/* assert wr signal */
-   var = 0x1 << PCIE_PHY_CTRL_WR_LOC;
+   var = PCIE_PHY_CTRL_WR;
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack */
@@ -221,7 +221,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
return ret;
 
/* deassert wr signal */
-   var = data << PCIE_PHY_CTRL_DATA_LOC;
+   var = PCIE_PHY_CTRL_DATA(data);
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
 
/* wait for ack de-assertion */
-- 
2.19.1



[PATCH 14/21] PCI: imx6: Simplify pcie_phy_poll_ack()

2018-12-20 Thread Andrey Smirnov
Simplify pcie_phy_poll_ack() by incorporating shifting into constant
definition and convert the code to use 'bool'. No functional change
intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 40d348bb9a2b..ddab1859a07e 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -91,7 +91,7 @@ struct imx6_pcie {
 #define PCIE_PHY_CTRL_RD   BIT(19)
 
 #define PCIE_PHY_STAT (PL_OFFSET + 0x110)
-#define PCIE_PHY_STAT_ACK_LOC 16
+#define PCIE_PHY_STAT_ACK  BIT(16)
 
 /* PHY registers (not memory-mapped) */
 #define PCIE_PHY_ATEOVRD   0x10
@@ -108,16 +108,16 @@ struct imx6_pcie {
 #define PHY_RX_OVRD_IN_LO_RX_DATA_EN   BIT(5)
 #define PHY_RX_OVRD_IN_LO_RX_PLL_ENBIT(3)
 
-static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, int exp_val)
+static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, bool exp_val)
 {
struct dw_pcie *pci = imx6_pcie->pci;
-   u32 val;
+   bool val;
u32 max_iterations = 10;
u32 wait_counter = 0;
 
do {
-   val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
-   val = (val >> PCIE_PHY_STAT_ACK_LOC) & 0x1;
+   val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT) &
+   PCIE_PHY_STAT_ACK;
wait_counter++;
 
if (val == exp_val)
-- 
2.19.1



[PATCH 2/5] ihex: Check if zero-length record is at the end of the blob

2018-12-20 Thread Andrey Smirnov
When verifying the validity of IHEX file we need to make sure that
zero-length record we found is located at the end of the file. Not
doing that could result in an invalid file with a bogus zero-length in
the middle short-circuiting the check and being reported as valid.

Cc: Chris Healy 
Cc: Kyle McMartin 
Cc: Andrew Morton 
Cc: Masahiro Yamada 
Cc: David Woodhouse 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel 
Signed-off-by: Andrey Smirnov 
---
 include/linux/ihex.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 9c701521176b..9130f307a420 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -49,7 +49,7 @@ static inline int ihex_validate_fw(const struct firmware *fw)
 
for (; rec <= end; rec = __ihex_next_binrec(rec)) {
/* Zero length marks end of records */
-   if (!be16_to_cpu(rec->len))
+   if (rec == end && !be16_to_cpu(rec->len))
return 0;
}
return -EINVAL;
-- 
2.19.1



[PATCH 4/5] tools/firmware/ihex2fw: Simplify next record offset calculation

2018-12-20 Thread Andrey Smirnov
We can convert original expression for 'writelen" to use ALIGN as
follows:

(p->len + 9) & ~3 => (p->len + 6 + 3) & ~3 => ALIGN(p->len + 6, 4)

Now, subsituting "p->len + 6" with "p->len + sizeof(p->addr) +
sizeof(p->len)" we end up with the same expression as used by kernel
couterpart in linux/ihex.h:

ALIGN(p->len + sizeof(p->addr) + sizeof(p->len), 4)

That is a full size of the record, aligned to 4 bytes. No functional
change intended.

Cc: Chris Healy 
Cc: Kyle McMartin 
Cc: Andrew Morton 
Cc: Masahiro Yamada 
Cc: David Woodhouse 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel 
Signed-off-by: Andrey Smirnov 
---
 tools/firmware/ihex2fw.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/tools/firmware/ihex2fw.c b/tools/firmware/ihex2fw.c
index b58dd061e978..e081cef730d8 100644
--- a/tools/firmware/ihex2fw.c
+++ b/tools/firmware/ihex2fw.c
@@ -24,6 +24,10 @@
 #include 
 
 
+#define __ALIGN_KERNEL_MASK(x, mask)   (((x) + (mask)) & ~(mask))
+#define __ALIGN_KERNEL(x, a)   __ALIGN_KERNEL_MASK(x, (typeof(x))(a) - 
1)
+#define ALIGN(x, a)__ALIGN_KERNEL((x), (a))
+
 struct ihex_binrec {
struct ihex_binrec *next; /* not part of the real data structure */
 uint32_t addr;
@@ -259,13 +263,18 @@ static void file_record(struct ihex_binrec *record)
*p = record;
 }
 
+static uint16_t ihex_binrec_size(struct ihex_binrec *p)
+{
+   return p->len + sizeof(p->addr) + sizeof(p->len);
+}
+
 static int output_records(int outfd)
 {
unsigned char zeroes[6] = {0, 0, 0, 0, 0, 0};
struct ihex_binrec *p = records;
 
while (p) {
-   uint16_t writelen = (p->len + 9) & ~3;
+   uint16_t writelen = ALIGN(ihex_binrec_size(p), 4);
 
p->addr = htonl(p->addr);
p->len = htons(p->len);
-- 
2.19.1



[PATCH 20/21] PCI: designware: Make use of GENMASK/FIELD_PREP

2018-12-20 Thread Andrey Smirnov
Convert various mult-bit fields to be defined using
GENMASK/FIELD_PREP. This way bit field boundaries are defined in a
single place only as well as defined in a way that makes it easier to
verify them against reference manual. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pcie-designware.h | 29 +++-
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 348e91b6daa2..0de653284fca 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -11,6 +11,7 @@
 #ifndef _PCIE_DESIGNWARE_H
 #define _PCIE_DESIGNWARE_H
 
+#include 
 #include 
 #include 
 #include 
@@ -30,11 +31,12 @@
 
 /* Synopsys-specific PCIe configuration registers */
 #define PCIE_PORT_LINK_CONTROL 0x710
-#define PORT_LINK_MODE_MASK(0x3f << 16)
-#define PORT_LINK_MODE_1_LANES (0x1 << 16)
-#define PORT_LINK_MODE_2_LANES (0x3 << 16)
-#define PORT_LINK_MODE_4_LANES (0x7 << 16)
-#define PORT_LINK_MODE_8_LANES (0xf << 16)
+#define PORT_LINK_MODE_MASKGENMASK(21, 16)
+#define PORT_LINK_MODE(n)  FIELD_PREP(PORT_LINK_MODE_MASK, n)
+#define PORT_LINK_MODE_1_LANES PORT_LINK_MODE(0x1)
+#define PORT_LINK_MODE_2_LANES PORT_LINK_MODE(0x3)
+#define PORT_LINK_MODE_4_LANES PORT_LINK_MODE(0x7)
+#define PORT_LINK_MODE_8_LANES PORT_LINK_MODE(0xf)
 
 #define PCIE_PORT_DEBUG0   0x728
 #define PORT_LOGIC_LTSSM_STATE_MASK0x1f
@@ -45,11 +47,12 @@
 
 #define PCIE_LINK_WIDTH_SPEED_CONTROL  0x80C
 #define PORT_LOGIC_SPEED_CHANGEBIT(17)
-#define PORT_LOGIC_LINK_WIDTH_MASK (0x1f << 8)
-#define PORT_LOGIC_LINK_WIDTH_1_LANES  (0x1 << 8)
-#define PORT_LOGIC_LINK_WIDTH_2_LANES  (0x2 << 8)
-#define PORT_LOGIC_LINK_WIDTH_4_LANES  (0x4 << 8)
-#define PORT_LOGIC_LINK_WIDTH_8_LANES  (0x8 << 8)
+#define PORT_LOGIC_LINK_WIDTH_MASK GENMASK(12, 8)
+#define PORT_LOGIC_LINK_WIDTH(n)   FIELD_PREP(PORT_LOGIC_LINK_WIDTH_MASK, 
n)
+#define PORT_LOGIC_LINK_WIDTH_1_LANES  PORT_LOGIC_LINK_WIDTH(0x1)
+#define PORT_LOGIC_LINK_WIDTH_2_LANES  PORT_LOGIC_LINK_WIDTH(0x2)
+#define PORT_LOGIC_LINK_WIDTH_4_LANES  PORT_LOGIC_LINK_WIDTH(0x4)
+#define PORT_LOGIC_LINK_WIDTH_8_LANES  PORT_LOGIC_LINK_WIDTH(0x8)
 
 #define PCIE_MSI_ADDR_LO   0x820
 #define PCIE_MSI_ADDR_HI   0x824
@@ -75,9 +78,9 @@
 #define PCIE_ATU_UPPER_BASE0x910
 #define PCIE_ATU_LIMIT 0x914
 #define PCIE_ATU_LOWER_TARGET  0x918
-#define PCIE_ATU_BUS(x)(((x) & 0xff) << 24)
-#define PCIE_ATU_DEV(x)(((x) & 0x1f) << 19)
-#define PCIE_ATU_FUNC(x)   (((x) & 0x7) << 16)
+#define PCIE_ATU_BUS(x)FIELD_PREP(GENMASK(31, 24), x)
+#define PCIE_ATU_DEV(x)FIELD_PREP(GENMASK(23, 19), x)
+#define PCIE_ATU_FUNC(x)   FIELD_PREP(GENMASK(18, 16), x)
 #define PCIE_ATU_UPPER_TARGET  0x91C
 
 #define PCIE_MISC_CONTROL_1_OFF0x8BC
-- 
2.19.1



[PATCH 1/5] ihex: Share code between ihex_validate_fw() and ihex_next_binrec()

2018-12-20 Thread Andrey Smirnov
Convert both ihex_validate_fw() and ihex_next_binrec() to use a helper
function to calculate next record offest. This way we only have one
place implementing next record offset calculation logic. No functional
change intended.

Cc: Chris Healy 
Cc: Kyle McMartin 
Cc: Andrew Morton 
Cc: Masahiro Yamada 
Cc: David Woodhouse 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel 
Signed-off-by: Andrey Smirnov 
---
 include/linux/ihex.h | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 75c194391869..9c701521176b 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -23,29 +23,34 @@ struct ihex_binrec {
 
 /* Find the next record, taking into account the 4-byte alignment */
 static inline const struct ihex_binrec *
-ihex_next_binrec(const struct ihex_binrec *rec)
+__ihex_next_binrec(const struct ihex_binrec *rec)
 {
int next = ((be16_to_cpu(rec->len) + 5) & ~3) - 2;
rec = (void *)>data[next];
 
+   return rec;
+}
+
+static inline const struct ihex_binrec *
+ihex_next_binrec(const struct ihex_binrec *rec)
+{
+   rec = __ihex_next_binrec(rec);
+
return be16_to_cpu(rec->len) ? rec : NULL;
 }
 
 /* Check that ihex_next_binrec() won't take us off the end of the image... */
 static inline int ihex_validate_fw(const struct firmware *fw)
 {
-   const struct ihex_binrec *rec;
-   size_t ofs = 0;
+   const struct ihex_binrec *end, *rec;
 
-   while (ofs <= fw->size - sizeof(*rec)) {
-   rec = (void *)>data[ofs];
+   rec = (const void *)fw->data;
+   end = (const void *)>data[fw->size - sizeof(*end)];
 
+   for (; rec <= end; rec = __ihex_next_binrec(rec)) {
/* Zero length marks end of records */
if (!be16_to_cpu(rec->len))
return 0;
-
-   /* Point to next record... */
-   ofs += (sizeof(*rec) + be16_to_cpu(rec->len) + 3) & ~3;
}
return -EINVAL;
 }
-- 
2.19.1



[PATCH 5/5] tools/firmware/ihex2fw: Replace explicit alignment with ALIGN

2018-12-20 Thread Andrey Smirnov
(X + 3) & ~3 is the same as ALIGN(X, 4), so replace all of the
instances of the formwer in the code with the latter. While at it,
introduce a helper variable 'record_size' to avoid duplicating length
calculatin code. No functional change intended.

Cc: Chris Healy 
Cc: Kyle McMartin 
Cc: Andrew Morton 
Cc: Masahiro Yamada 
Cc: David Woodhouse 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel 
Signed-off-by: Andrey Smirnov 
---
 tools/firmware/ihex2fw.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/firmware/ihex2fw.c b/tools/firmware/ihex2fw.c
index e081cef730d8..8925b60e51f5 100644
--- a/tools/firmware/ihex2fw.c
+++ b/tools/firmware/ihex2fw.c
@@ -135,6 +135,7 @@ int main(int argc, char **argv)
 static int process_ihex(uint8_t *data, ssize_t size)
 {
struct ihex_binrec *record;
+   size_t record_size;
uint32_t offset = 0;
uint32_t data32;
uint8_t type, crc = 0, crcbyte = 0;
@@ -161,12 +162,13 @@ static int process_ihex(uint8_t *data, ssize_t size)
len <<= 8;
len += hex(data + i, ); i += 2;
}
-   record = malloc((sizeof (*record) + len + 3) & ~3);
+   record_size = ALIGN(sizeof(*record) + len, 4);
+   record = malloc(record_size);
if (!record) {
fprintf(stderr, "out of memory for records\n");
return -ENOMEM;
}
-   memset(record, 0, (sizeof(*record) + len + 3) & ~3);
+   memset(record, 0, record_size);
record->len = len;
 
/* now check if we have enough data to read everything */
-- 
2.19.1



[PATCH 3/5] ihex: Simplify next record offset calculation

2018-12-20 Thread Andrey Smirnov
Next record calucaltion can be reduced to a much more tivial ALIGN
operation as follows:

1. Splitting 5 into 2 + 3 we get

   next = ((be16_to_cpu(rec->len) + 2 + 3) & ~3) - 2(1)

2. Using ALIGN macro we reduce (1) to:

   ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2  (2)

3. Subsituting 'next' in original next record calucation we get:

   (void *)>data[ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2]  (3)

4. Converting array index to pointer arithmetic we convert (3) into:

   (void *)rec + sizeof(*rec) +
 ALIGN(be16_to_cpu(rec->len) + 2, 4) - 2(4)

5. Subsituting sizeof(*rec) with its value, 6, and substracting 2,
   in (4) we get:

   (void *)rec + ALIGN(be16_to_cpu(rec->len) + 2, 4) + 4(5)

6. Since ALIGN(X, 4) + 4 == ALIGN(X + 4, 4), (5) can be converted to:

   (void *)rec + ALIGN(be16_to_cpu(rec->len) + 6, 4)(6)

5. Subsituting 6 in (6) to sizeof(*rec) we get:

   (void *)rec + ALIGN(be16_to_cpu(rec->len) + sizeof(*rec), 4) (7)

Using expression (7) should make it more clear that next record is
located by adding full size of the current record (payload + auxiliary
data) aligned to 4 bytes, to the location of the current one. No
functional change intended.

Cc: Chris Healy 
Cc: Kyle McMartin 
Cc: Andrew Morton 
Cc: Masahiro Yamada 
Cc: David Woodhouse 
Cc: Greg Kroah-Hartman 
Cc: linux-kernel 
Signed-off-by: Andrey Smirnov 
---
 include/linux/ihex.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/ihex.h b/include/linux/ihex.h
index 9130f307a420..98cb5ce0b0a0 100644
--- a/include/linux/ihex.h
+++ b/include/linux/ihex.h
@@ -21,14 +21,18 @@ struct ihex_binrec {
uint8_t data[0];
 } __attribute__((packed));
 
+static inline uint16_t ihex_binrec_size(const struct ihex_binrec *p)
+{
+   return be16_to_cpu(p->len) + sizeof(*p);
+}
+
 /* Find the next record, taking into account the 4-byte alignment */
 static inline const struct ihex_binrec *
 __ihex_next_binrec(const struct ihex_binrec *rec)
 {
-   int next = ((be16_to_cpu(rec->len) + 5) & ~3) - 2;
-   rec = (void *)>data[next];
+   const void *p = rec;
 
-   return rec;
+   return p + ALIGN(ihex_binrec_size(rec), 4);
 }
 
 static inline const struct ihex_binrec *
-- 
2.19.1



[PATCH 17/21] PCI: imx6: Use common mask in imx6_pcie_reset_phy()

2018-12-20 Thread Andrey Smirnov
Simplify imx6_pcie_reset_phy() by using common mask. No functional
change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index bade9d608605..38c8e8baa077 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -230,18 +230,18 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, 
int addr, u16 data)
 
 static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
 {
+   const u16 mask = PHY_RX_OVRD_IN_LO_RX_DATA_EN |
+PHY_RX_OVRD_IN_LO_RX_PLL_EN;
u16 tmp;
 
pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, );
-   tmp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN |
-   PHY_RX_OVRD_IN_LO_RX_PLL_EN);
+   tmp |= mask;
pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp);
 
usleep_range(2000, 3000);
 
pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, );
-   tmp &= ~(PHY_RX_OVRD_IN_LO_RX_DATA_EN |
- PHY_RX_OVRD_IN_LO_RX_PLL_EN);
+   tmp &= ~mask;
pcie_phy_write(imx6_pcie, PHY_RX_OVRD_IN_LO, tmp);
 }
 
-- 
2.19.1



[PATCH 0/5] IHEX bug fix and some improvements

2018-12-20 Thread Andrey Smirnov
Everyone:

This series is a big-fix to a problem I encountered while using code
in  bundled with a number of small improvmements. The
bug fix is in commit:

[PATCH 2/5] ihex: Check if zero-length record is at the end of the

Small improvmentes are in the rest and all of them are purely
optional. Hopefully each commit is self-explanatory.

Feedback is welcome!

Thanks,
Andrey Smirnov

NOTE: This series is expected to be applied on top of [fimrware-patch]

[firmware-patch] 
lkml.kernel.org/r/20181017182718.32740-1-andrew.smir...@gmail.com

Andrey Smirnov (5):
  ihex: Share code between ihex_validate_fw() and ihex_next_binrec()
  ihex: Check if zero-length record is at the end of the blob
  ihex: Simplify next record offset calculation
  tools/firmware/ihex2fw: Simplify next record offset calculation
  tools/firmware/ihex2fw: Replace explicit alignment with ALIGN

 include/linux/ihex.h | 29 +++--
 tools/firmware/ihex2fw.c | 17 ++---
 2 files changed, 33 insertions(+), 13 deletions(-)

-- 
2.19.1



[PATCH 16/21] PCI: imx6: Pass data to dw_pcie_writel_dbi() directly

2018-12-20 Thread Andrey Smirnov
Save a couple of lines of code by dropping assignement to 'var' and
passing constants as via function arguments directly. No functional
change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 98e3730e75fa..bade9d608605 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -155,7 +155,6 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie, 
int addr)
 static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int addr, u16 *data)
 {
struct dw_pcie *pci = imx6_pcie->pci;
-   u32 phy_ctl;
int ret;
 
ret = pcie_phy_wait_ack(imx6_pcie, addr);
@@ -163,8 +162,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, u16 *data)
return ret;
 
/* assert Read signal */
-   phy_ctl = PCIE_PHY_CTRL_RD;
-   dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, phy_ctl);
+   dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, PCIE_PHY_CTRL_RD);
 
ret = pcie_phy_poll_ack(imx6_pcie, 1);
if (ret)
@@ -202,8 +200,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, u16 data)
return ret;
 
/* deassert cap data */
-   var = PCIE_PHY_CTRL_DATA(data);
-   dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
+   dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, PCIE_PHY_CTRL_DATA(data));
 
/* wait for ack de-assertion */
ret = pcie_phy_poll_ack(imx6_pcie, 0);
@@ -211,8 +208,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, u16 data)
return ret;
 
/* assert wr signal */
-   var = PCIE_PHY_CTRL_WR;
-   dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
+   dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, PCIE_PHY_CTRL_WR);
 
/* wait for ack */
ret = pcie_phy_poll_ack(imx6_pcie, 1);
@@ -220,8 +216,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, u16 data)
return ret;
 
/* deassert wr signal */
-   var = PCIE_PHY_CTRL_DATA(data);
-   dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, var);
+   dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, PCIE_PHY_CTRL_DATA(data));
 
/* wait for ack de-assertion */
ret = pcie_phy_poll_ack(imx6_pcie, 0);
-- 
2.19.1



[PATCH 12/21] PCI: imx6: Make use of BIT() in constant definitions

2018-12-20 Thread Andrey Smirnov
Avoid using explicit left shifts and convert various definitions to
use BIT() instead. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index c0b073cf20c0..2737526158fa 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -95,18 +95,18 @@ struct imx6_pcie {
 
 /* PHY registers (not memory-mapped) */
 #define PCIE_PHY_ATEOVRD   0x10
-#define  PCIE_PHY_ATEOVRD_EN   (0x1 << 2)
+#define  PCIE_PHY_ATEOVRD_EN   BIT(2)
 #define  PCIE_PHY_ATEOVRD_REF_CLKDIV_SHIFT 0
 #define  PCIE_PHY_ATEOVRD_REF_CLKDIV_MASK  0x1
 
 #define PCIE_PHY_MPLL_OVRD_IN_LO   0x11
 #define  PCIE_PHY_MPLL_MULTIPLIER_SHIFT2
 #define  PCIE_PHY_MPLL_MULTIPLIER_MASK 0x7f
-#define  PCIE_PHY_MPLL_MULTIPLIER_OVRD (0x1 << 9)
+#define  PCIE_PHY_MPLL_MULTIPLIER_OVRD BIT(9)
 
 #define PHY_RX_OVRD_IN_LO 0x1005
-#define PHY_RX_OVRD_IN_LO_RX_DATA_EN (1 << 5)
-#define PHY_RX_OVRD_IN_LO_RX_PLL_EN (1 << 3)
+#define PHY_RX_OVRD_IN_LO_RX_DATA_EN   BIT(5)
+#define PHY_RX_OVRD_IN_LO_RX_PLL_ENBIT(3)
 
 static int pcie_phy_poll_ack(struct imx6_pcie *imx6_pcie, int exp_val)
 {
-- 
2.19.1



[PATCH 21/21] PCI: designware: Remove superfluous shifting in definitions

2018-12-20 Thread Andrey Smirnov
Surrounding definitions no longer use explicit shift, so "<< 0" here
serve no purpose. Remove them. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pcie-designware.h | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
b/drivers/pci/controller/dwc/pcie-designware.h
index 0de653284fca..636689fd4ee7 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -63,14 +63,14 @@
 #define PCIE_ATU_VIEWPORT  0x900
 #define PCIE_ATU_REGION_INBOUNDBIT(31)
 #define PCIE_ATU_REGION_OUTBOUND   0
-#define PCIE_ATU_REGION_INDEX2 (0x2 << 0)
-#define PCIE_ATU_REGION_INDEX1 (0x1 << 0)
-#define PCIE_ATU_REGION_INDEX0 (0x0 << 0)
+#define PCIE_ATU_REGION_INDEX2 0x2
+#define PCIE_ATU_REGION_INDEX1 0x1
+#define PCIE_ATU_REGION_INDEX0 0x0
 #define PCIE_ATU_CR1   0x904
-#define PCIE_ATU_TYPE_MEM  (0x0 << 0)
-#define PCIE_ATU_TYPE_IO   (0x2 << 0)
-#define PCIE_ATU_TYPE_CFG0 (0x4 << 0)
-#define PCIE_ATU_TYPE_CFG1 (0x5 << 0)
+#define PCIE_ATU_TYPE_MEM  0x0
+#define PCIE_ATU_TYPE_IO   0x2
+#define PCIE_ATU_TYPE_CFG0 0x4
+#define PCIE_ATU_TYPE_CFG1 0x5
 #define PCIE_ATU_CR2   0x908
 #define PCIE_ATU_ENABLEBIT(31)
 #define PCIE_ATU_BAR_MODE_ENABLE   BIT(30)
-- 
2.19.1



[PATCH 18/21] PCI: imx6: Simplify bit operations in imx6_setup_phy_mpll()

2018-12-20 Thread Andrey Smirnov
Simplify bit operations in imx6_setup_phy_mpll() by using
GENMASK/FIELD_PREP. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 38c8e8baa077..678f5fa85e12 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -96,12 +96,10 @@ struct imx6_pcie {
 /* PHY registers (not memory-mapped) */
 #define PCIE_PHY_ATEOVRD   0x10
 #define  PCIE_PHY_ATEOVRD_EN   BIT(2)
-#define  PCIE_PHY_ATEOVRD_REF_CLKDIV_SHIFT 0
-#define  PCIE_PHY_ATEOVRD_REF_CLKDIV_MASK  0x1
+#define  PCIE_PHY_ATEOVRD_REF_CLKDIV   BIT(0)
 
 #define PCIE_PHY_MPLL_OVRD_IN_LO   0x11
-#define  PCIE_PHY_MPLL_MULTIPLIER_SHIFT2
-#define  PCIE_PHY_MPLL_MULTIPLIER_MASK 0x7f
+#define  PCIE_PHY_MPLL_MULTIPLIER  GENMASK(8, 2)
 #define  PCIE_PHY_MPLL_MULTIPLIER_OVRD BIT(9)
 
 #define PHY_RX_OVRD_IN_LO 0x1005
@@ -565,16 +563,14 @@ static int imx6_setup_phy_mpll(struct imx6_pcie 
*imx6_pcie)
}
 
pcie_phy_read(imx6_pcie, PCIE_PHY_MPLL_OVRD_IN_LO, );
-   val &= ~(PCIE_PHY_MPLL_MULTIPLIER_MASK <<
-PCIE_PHY_MPLL_MULTIPLIER_SHIFT);
-   val |= mult << PCIE_PHY_MPLL_MULTIPLIER_SHIFT;
+   val &= ~PCIE_PHY_MPLL_MULTIPLIER;
+   val |= FIELD_PREP(PCIE_PHY_MPLL_MULTIPLIER, mult);
val |= PCIE_PHY_MPLL_MULTIPLIER_OVRD;
pcie_phy_write(imx6_pcie, PCIE_PHY_MPLL_OVRD_IN_LO, val);
 
pcie_phy_read(imx6_pcie, PCIE_PHY_ATEOVRD, );
-   val &= ~(PCIE_PHY_ATEOVRD_REF_CLKDIV_MASK <<
-PCIE_PHY_ATEOVRD_REF_CLKDIV_SHIFT);
-   val |= div << PCIE_PHY_ATEOVRD_REF_CLKDIV_SHIFT;
+   val &= ~PCIE_PHY_ATEOVRD_REF_CLKDIV;
+   val |= FIELD_PREP(PCIE_PHY_ATEOVRD_REF_CLKDIV, div);
val |= PCIE_PHY_ATEOVRD_EN;
pcie_phy_write(imx6_pcie, PCIE_PHY_ATEOVRD, val);
 
-- 
2.19.1



[PATCH 15/21] PCI: imx6: Restrict PHY register data to 16-bit

2018-12-20 Thread Andrey Smirnov
PHY registers on i.MX6 are 16-bit wide, so we can get rid of explicit
masking if we restrict pcie_phy_read/pcie_phy_write to use 'u16'
instead of 'int'. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index ddab1859a07e..98e3730e75fa 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -152,10 +152,10 @@ static int pcie_phy_wait_ack(struct imx6_pcie *imx6_pcie, 
int addr)
 }
 
 /* Read from the 16-bit PCIe PHY control registers (not memory-mapped) */
-static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int addr, int *data)
+static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int addr, u16 *data)
 {
struct dw_pcie *pci = imx6_pcie->pci;
-   u32 val, phy_ctl;
+   u32 phy_ctl;
int ret;
 
ret = pcie_phy_wait_ack(imx6_pcie, addr);
@@ -170,8 +170,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, int *data)
if (ret)
return ret;
 
-   val = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
-   *data = val & 0x;
+   *data = dw_pcie_readl_dbi(pci, PCIE_PHY_STAT);
 
/* deassert Read signal */
dw_pcie_writel_dbi(pci, PCIE_PHY_CTRL, 0x00);
@@ -179,7 +178,7 @@ static int pcie_phy_read(struct imx6_pcie *imx6_pcie, int 
addr, int *data)
return pcie_phy_poll_ack(imx6_pcie, 0);
 }
 
-static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, int data)
+static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int addr, u16 data)
 {
struct dw_pcie *pci = imx6_pcie->pci;
u32 var;
@@ -236,7 +235,7 @@ static int pcie_phy_write(struct imx6_pcie *imx6_pcie, int 
addr, int data)
 
 static void imx6_pcie_reset_phy(struct imx6_pcie *imx6_pcie)
 {
-   u32 tmp;
+   u16 tmp;
 
pcie_phy_read(imx6_pcie, PHY_RX_OVRD_IN_LO, );
tmp |= (PHY_RX_OVRD_IN_LO_RX_DATA_EN |
@@ -547,7 +546,7 @@ static int imx6_setup_phy_mpll(struct imx6_pcie *imx6_pcie)
 {
unsigned long phy_rate = clk_get_rate(imx6_pcie->pcie_phy);
int mult, div;
-   u32 val;
+   u16 val;
 
switch (phy_rate) {
case 12500:
-- 
2.19.1



[PATCH 04/21] PCI: imx6: Remove duplicate macro definitions

2018-12-20 Thread Andrey Smirnov
Both PCIE_LINK_WIDTH_SPEED_CONTROL and PORT_LOGIC_SPEED_CHANGE are
already defined in pcie-desingware.h, so drop duplicate definintion in
pci-imx6.c. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index e990030564d8..2265f4b40e39 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -100,9 +100,6 @@ struct imx6_pcie {
 #define PCIE_PHY_STAT (PL_OFFSET + 0x110)
 #define PCIE_PHY_STAT_ACK_LOC 16
 
-#define PCIE_LINK_WIDTH_SPEED_CONTROL  0x80C
-#define PORT_LOGIC_SPEED_CHANGE(0x1 << 17)
-
 /* PHY registers (not memory-mapped) */
 #define PCIE_PHY_ATEOVRD   0x10
 #define  PCIE_PHY_ATEOVRD_EN   (0x1 << 2)
-- 
2.19.1



[PATCH 19/21] PCI: imx6: Remove magic numbers from imx6_pcie_establish_link()

2018-12-20 Thread Andrey Smirnov
Explicitly define PCIE_RC_LCSR_LINK_SPEED and remove magic numbers
from imx6_pcie_establish_link(). No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 678f5fa85e12..2b312f287fd7 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -79,6 +79,7 @@ struct imx6_pcie {
 #define PCIE_RC_LCR_MAX_LINK_SPEEDS_MASK   0xf
 
 #define PCIE_RC_LCSR   0x80
+#define PCIE_RC_LCSR_LINK_SPEEDGENMASK(19, 16)
 
 /* PCIe Port Logic registers (memory-mapped) */
 #define PL_OFFSET 0x700
@@ -688,8 +689,9 @@ static int imx6_pcie_establish_link(struct imx6_pcie 
*imx6_pcie)
dev_info(dev, "Link: Gen2 disabled\n");
}
 
-   tmp = dw_pcie_readl_dbi(pci, PCIE_RC_LCSR);
-   dev_info(dev, "Link up, Gen%i\n", (tmp >> 16) & 0xf);
+   tmp = FIELD_GET(PCIE_RC_LCSR_LINK_SPEED,
+   dw_pcie_readl_dbi(pci, PCIE_RC_LCSR));
+   dev_info(dev, "Link up, Gen%i\n", tmp);
return 0;
 
 err_reset_phy:
-- 
2.19.1



[PATCH 01/21] PCI: imx6: Simplify imx7d_pcie_wait_for_phy_pll_lock()

2018-12-20 Thread Andrey Smirnov
Make use of regmap_read_poll_timeout() to simplify
imx7d_pcie_wait_for_phy_pll_lock(). No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 drivers/pci/controller/dwc/pci-imx6.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index 26087b3da590..c87ecc305dc7 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -69,9 +69,8 @@ struct imx6_pcie {
 };
 
 /* Parameters for the waiting for PCIe PHY PLL to lock on i.MX7 */
-#define PHY_PLL_LOCK_WAIT_MAX_RETRIES  2000
-#define PHY_PLL_LOCK_WAIT_USLEEP_MIN   50
 #define PHY_PLL_LOCK_WAIT_USLEEP_MAX   200
+#define PHY_PLL_LOCK_WAIT_TIMEOUT  (2000 * PHY_PLL_LOCK_WAIT_USLEEP_MAX)
 
 /* PCIe Root Complex registers (memory-mapped) */
 #define PCIE_RC_LCR0x7c
@@ -418,20 +417,14 @@ static int imx6_pcie_enable_ref_clk(struct imx6_pcie 
*imx6_pcie)
 static void imx7d_pcie_wait_for_phy_pll_lock(struct imx6_pcie *imx6_pcie)
 {
u32 val;
-   unsigned int retries;
struct device *dev = imx6_pcie->pci->dev;
 
-   for (retries = 0; retries < PHY_PLL_LOCK_WAIT_MAX_RETRIES; retries++) {
-   regmap_read(imx6_pcie->iomuxc_gpr, IOMUXC_GPR22, );
-
-   if (val & IMX7D_GPR22_PCIE_PHY_PLL_LOCKED)
-   return;
-
-   usleep_range(PHY_PLL_LOCK_WAIT_USLEEP_MIN,
-PHY_PLL_LOCK_WAIT_USLEEP_MAX);
-   }
-
-   dev_err(dev, "PCIe PLL lock timeout\n");
+   if (regmap_read_poll_timeout(imx6_pcie->iomuxc_gpr,
+IOMUXC_GPR22, val,
+val & IMX7D_GPR22_PCIE_PHY_PLL_LOCKED,
+PHY_PLL_LOCK_WAIT_USLEEP_MAX,
+PHY_PLL_LOCK_WAIT_TIMEOUT))
+   dev_err(dev, "PCIe PLL lock timeout\n");
 }
 
 static void imx6_pcie_deassert_core_reset(struct imx6_pcie *imx6_pcie)
-- 
2.19.1



[PATCH 08/21] PCI: designware: Share code for dw_pcie_rd/wr_other_conf()

2018-12-20 Thread Andrey Smirnov
Default implementation of pcie_rd_other_conf() and
dw_pcie_wd_other_conf() share more than 80% of their code. Move shared
code into a dedicated subroutine and convert pcie_rd_other_conf() and
dw_pcie_wd_other_conf() to use it. No functional change intended.

Cc: Lorenzo Pieralisi 
Cc: Bjorn Helgaas 
Cc: Fabio Estevam 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Leonard Crestez 
Cc: "A.s. Dong" 
Cc: Richard Zhu 
Cc: linux-...@nxp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Signed-off-by: Andrey Smirnov 
---
 .../pci/controller/dwc/pcie-designware-host.c | 61 +++
 1 file changed, 23 insertions(+), 38 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c 
b/drivers/pci/controller/dwc/pcie-designware-host.c
index 721d60a5d9e4..8f957cd6901b 100644
--- a/drivers/pci/controller/dwc/pcie-designware-host.c
+++ b/drivers/pci/controller/dwc/pcie-designware-host.c
@@ -512,8 +512,9 @@ int dw_pcie_host_init(struct pcie_port *pp)
return ret;
 }
 
-static int dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
-u32 devfn, int where, int size, u32 *val)
+static int dw_pcie_access_other_conf(struct pcie_port *pp, struct pci_bus *bus,
+u32 devfn, int where, int size, u32 *val,
+bool write)
 {
int ret, type;
u32 busdev, cfg_size;
@@ -521,9 +522,6 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp, 
struct pci_bus *bus,
void __iomem *va_cfg_base;
struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
 
-   if (pp->ops->rd_other_conf)
-   return pp->ops->rd_other_conf(pp, bus, devfn, where, size, val);
-
busdev = PCIE_ATU_BUS(bus->number) | PCIE_ATU_DEV(PCI_SLOT(devfn)) |
 PCIE_ATU_FUNC(PCI_FUNC(devfn));
 
@@ -542,7 +540,11 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp, 
struct pci_bus *bus,
dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX1,
  type, cpu_addr,
  busdev, cfg_size);
-   ret = dw_pcie_read(va_cfg_base + where, size, val);
+   if (write)
+   ret = dw_pcie_write(va_cfg_base + where, size, *val);
+   else
+   ret = dw_pcie_read(va_cfg_base + where, size, val);
+
if (pci->num_viewport <= 2)
dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX1,
  PCIE_ATU_TYPE_IO, pp->io_base,
@@ -551,43 +553,26 @@ static int dw_pcie_rd_other_conf(struct pcie_port *pp, 
struct pci_bus *bus,
return ret;
 }
 
+static int dw_pcie_rd_other_conf(struct pcie_port *pp, struct pci_bus *bus,
+u32 devfn, int where, int size, u32 *val)
+{
+   if (pp->ops->rd_other_conf)
+   return pp->ops->rd_other_conf(pp, bus, devfn, where,
+ size, val);
+
+   return dw_pcie_access_other_conf(pp, bus, devfn, where, size, val,
+false);
+}
+
 static int dw_pcie_wr_other_conf(struct pcie_port *pp, struct pci_bus *bus,
 u32 devfn, int where, int size, u32 val)
 {
-   int ret, type;
-   u32 busdev, cfg_size;
-   u64 cpu_addr;
-   void __iomem *va_cfg_base;
-   struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
-
if (pp->ops->wr_other_conf)
-   return pp->ops->wr_other_conf(pp, bus, devfn, where, size, val);
-
-   busdev = PCIE_ATU_BUS(bus->number) | PCIE_ATU_DEV(PCI_SLOT(devfn)) |
-PCIE_ATU_FUNC(PCI_FUNC(devfn));
+   return pp->ops->wr_other_conf(pp, bus, devfn, where,
+ size, val);
 
-   if (bus->parent->number == pp->root_bus_nr) {
-   type = PCIE_ATU_TYPE_CFG0;
-   cpu_addr = pp->cfg0_base;
-   cfg_size = pp->cfg0_size;
-   va_cfg_base = pp->va_cfg0_base;
-   } else {
-   type = PCIE_ATU_TYPE_CFG1;
-   cpu_addr = pp->cfg1_base;
-   cfg_size = pp->cfg1_size;
-   va_cfg_base = pp->va_cfg1_base;
-   }
-
-   dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX1,
- type, cpu_addr,
- busdev, cfg_size);
-   ret = dw_pcie_write(va_cfg_base + where, size, val);
-   if (pci->num_viewport <= 2)
-   dw_pcie_prog_outbound_atu(pci, PCIE_ATU_REGION_INDEX1,
- PCIE_ATU_TYPE_IO, pp->io_base,
- pp->io_bus_addr, pp->io_size);
-
-   return ret;
+   return dw_pcie_access_other_conf(pp, bus, devfn, where, size, ,
+true);
 }
 
 static int dw_pcie_valid_device(struct pcie_port *pp, struct pci_bus *bus,
-- 
2.19.1



[PATCH 00/21] i.MX6, DesignWare PCI improvements

2018-12-20 Thread Andrey Smirnov
Everyone:

This is the series containing various small improvements that I made
while reading the code and researching commit history of pci-imx6.c
and pcie-designware*.c files. All changes are optional, so commits
that don't seem like an improvement can be easily dropped. Hopefully
each patch is self-explanatory.

I tested this series on i.MX6Q, i.MX7D and i.MX8MQ.

Feedback is welcome!

Thanks,
Andrey Smirnov

Andrey Smirnov (21):
  PCI: imx6: Simplify imx7d_pcie_wait_for_phy_pll_lock()
  PCI: imx6: Remove redundant debug tracing
  PCI: imx6: Return -ETIMEOUT from imx6_pcie_wait_for_speed_change()
  PCI: imx6: Remove duplicate macro definitions
  PCI: imx6: Remove PCIE_PL_PFLR_* constants
  PCI: imx6: Remove PCIE_PHY_RX_ASIC_OUT* constants
  PCI: designware: Make use of IS_ALIGNED()
  PCI: designware: Share code for dw_pcie_rd/wr_other_conf()
  PCI: imx6: Drop imx6_pcie_link_up()
  PCI: designware: imx6: Share PHY debug register definitions
  PCI: designware: Make use of BIT() in constant definitions
  PCI: imx6: Make use of BIT() in constant definitions
  PCI: imx6: Simplify bit operations in PHY functions
  PCI: imx6: Simplify pcie_phy_poll_ack()
  PCI: imx6: Restrict PHY register data to 16-bit
  PCI: imx6: Pass data to dw_pcie_writel_dbi() directly
  PCI: imx6: Use common mask in imx6_pcie_reset_phy()
  PCI: imx6: Simplify bit operations in imx6_setup_phy_mpll()
  PCI: imx6: Remove magic numbers from imx6_pcie_establish_link()
  PCI: designware: Make use of GENMASK/FIELD_PREP
  PCI: designware: Remove superfluous shifting in definitions

 drivers/pci/controller/dwc/pci-imx6.c | 151 +++---
 .../pci/controller/dwc/pcie-designware-host.c |  61 +++
 drivers/pci/controller/dwc/pcie-designware.c  |  18 +--
 drivers/pci/controller/dwc/pcie-designware.h  |  60 +++
 4 files changed, 116 insertions(+), 174 deletions(-)

-- 
2.19.1



[PATCH] lm80: fix a missing check of return value

2018-12-20 Thread Kangjie Lu
When lm80_read_value() fails, the read data is an error number. So let's
check its status before using the read data.

Signed-off-by: Kangjie Lu 
---
 drivers/hwmon/lm80.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/lm80.c b/drivers/hwmon/lm80.c
index fca6363cd77f..7457ff8bc860 100644
--- a/drivers/hwmon/lm80.c
+++ b/drivers/hwmon/lm80.c
@@ -628,6 +628,7 @@ static int lm80_probe(struct i2c_client *client,
struct device *dev = >dev;
struct device *hwmon_dev;
struct lm80_data *data;
+   int rv;
 
data = devm_kzalloc(dev, sizeof(struct lm80_data), GFP_KERNEL);
if (!data)
@@ -640,8 +641,14 @@ static int lm80_probe(struct i2c_client *client,
lm80_init_client(client);
 
/* A few vars need to be filled upon startup */
-   data->fan[f_min][0] = lm80_read_value(client, LM80_REG_FAN_MIN(1));
-   data->fan[f_min][1] = lm80_read_value(client, LM80_REG_FAN_MIN(2));
+   rv = lm80_read_value(client, LM80_REG_FAN_MIN(1));
+   if (rv < 0)
+   return rv;
+   data->fan[f_min][0] = rv;
+   rv = lm80_read_value(client, LM80_REG_FAN_MIN(2));
+   if (rv < 0)
+   return rv;
+   data->fan[f_min][1] = rv;
 
hwmon_dev = devm_hwmon_device_register_with_groups(dev, client->name,
   data, lm80_groups);
-- 
2.17.2 (Apple Git-113)



Re: [PATCH] mfd: cros_ec: Add support for MKBP more event flags

2018-12-20 Thread Lee Jones
On Thu, 20 Dec 2018, egran...@google.com wrote:

> From: Enrico Granata 
> 
> The ChromeOS EC has support for signaling to the host that
> a single IRQ can serve multiple MKBP events.
> 
> Doing this serves an optimization purpose, as it minimizes the
> number of round-trips into the interrupt handling machinery, and
> it proves beneficial to sensor timestamping as it keeps the desired
> synchronization of event times between the two processors.
> 
> This patch adds kernel support for this EC feature, allowing the
> ec_irq to loop until all events have been served.
> 
> Signed-off-by: Enrico Granata 
> ---

What is this?

A [RESEND]?  If so, you should s/[PATCH]/[RESEND/ in the subject line.

An updated patch?  If so, you need a Changelog here and a [PATCH v2].

Also, submitting in-reply-to isn't scalable.

Please resubmit this patch.

>  drivers/mfd/cros_ec.c   | 20 +--
>  drivers/platform/chrome/cros_ec_proto.c | 33 +++--
>  include/linux/mfd/cros_ec.h |  7 --
>  include/linux/mfd/cros_ec_commands.h| 15 +++
>  4 files changed, 53 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
> index fe6f83766144f..17903a378aa1a 100644
> --- a/drivers/mfd/cros_ec.c
> +++ b/drivers/mfd/cros_ec.c
> @@ -51,13 +51,16 @@ static const struct mfd_cell ec_pd_cell = {
>   .pdata_size = sizeof(pd_p),
>  };
>  
> -static irqreturn_t ec_irq_thread(int irq, void *data)
> +static bool ec_handle_event(struct cros_ec_device *ec_dev)
>  {
> - struct cros_ec_device *ec_dev = data;
>   bool wake_event = true;
>   int ret;
> + bool ec_has_more_events = false;
>  
>   ret = cros_ec_get_next_event(ec_dev, _event);
> + if (ret > 0)
> + ec_has_more_events =
> + ec_dev->event_data.event_type & EC_MKBP_HAS_MORE_EVENTS;
>  
>   /*
>* Signal only if wake host events or any interrupt if
> @@ -70,6 +73,19 @@ static irqreturn_t ec_irq_thread(int irq, void *data)
>   if (ret > 0)
>   blocking_notifier_call_chain(_dev->event_notifier,
>0, ec_dev);
> +
> + return ec_has_more_events;
> +}
> +
> +static irqreturn_t ec_irq_thread(int irq, void *data)
> +{
> + struct cros_ec_device *ec_dev = data;
> + bool ec_has_more_events;
> +
> + do {
> + ec_has_more_events = ec_handle_event(ec_dev);
> + } while (ec_has_more_events);
> +
>   return IRQ_HANDLED;
>  }
>  
> diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> b/drivers/platform/chrome/cros_ec_proto.c
> index b6fd4838f60f3..bb126d95b2fd4 100644
> --- a/drivers/platform/chrome/cros_ec_proto.c
> +++ b/drivers/platform/chrome/cros_ec_proto.c
> @@ -420,10 +420,14 @@ int cros_ec_query_all(struct cros_ec_device *ec_dev)
>   ret = cros_ec_get_host_command_version_mask(ec_dev,
>   EC_CMD_GET_NEXT_EVENT,
>   _mask);
> - if (ret < 0 || ver_mask == 0)
> + if (ret < 0 || ver_mask == 0) {
>   ec_dev->mkbp_event_supported = 0;
> - else
> - ec_dev->mkbp_event_supported = 1;
> + dev_info(ec_dev->dev, "MKBP not supported\n");
> + } else {
> + ec_dev->mkbp_event_supported = fls(ver_mask);
> + dev_info(ec_dev->dev, "MKBP support version %u\n",
> + ec_dev->mkbp_event_supported - 1);
> + }
>  
>   /*
>* Get host event wake mask, assume all events are wake events
> @@ -530,28 +534,19 @@ static int get_next_event(struct cros_ec_device *ec_dev)
>  {
>   u8 buffer[sizeof(struct cros_ec_command) + sizeof(ec_dev->event_data)];
>   struct cros_ec_command *msg = (struct cros_ec_command *)
> - static int cmd_version = 1;
> - int ret;
> + const int cmd_version = ec_dev->mkbp_event_supported - 1;
>  
>   if (ec_dev->suspended) {
>   dev_dbg(ec_dev->dev, "Device suspended.\n");
>   return -EHOSTDOWN;
>   }
>  
> - if (cmd_version == 1) {
> - ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> - sizeof(struct ec_response_get_next_event_v1));
> - if (ret < 0 || msg->result != EC_RES_INVALID_VERSION)
> - return ret;
> -
> - /* Fallback to version 0 for future send attempts */
> - cmd_version = 0;
> - }
> -
> - ret = get_next_event_xfer(ec_dev, msg, cmd_version,
> + if (cmd_version == 0)
> + return get_next_event_xfer(ec_dev, msg, 0,
> sizeof(struct ec_response_get_next_event));
>  
> - return ret;
> + return get_next_event_xfer(ec_dev, msg, cmd_version,
> + sizeof(struct ec_response_get_next_event_v1));
>  }
>  
>  static int get_keyboard_state_event(struct cros_ec_device *ec_dev)
> @@ -607,11 +602,13 

Re: Clang build error in drivers/scsi/smartpqi/smartpqi_init.c

2018-12-20 Thread Nathan Chancellor
On Fri, Dec 21, 2018 at 12:11:00AM -0700, Nathan Chancellor wrote:
> Hi all,
> 
> After commit 4fd22c13ad44 ("scsi: smartpqi: add ofa support"), an arm
> allyesconfig build with Clang fails with the following warning/error:
> 
> drivers/scsi/smartpqi/smartpqi_init.c:7473:2: warning: comparison of distinct 
> pointer types ('typeof ((sg_count)) *' (aka 'unsigned int *') and 'uint64_t 
> *' (aka 'unsigned long long *')) [-Wcompare-distinct-pointer-types]
> do_div(sg_count, chunk_size);
> ^~~~
> ./include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div'
> (void)(((typeof((n)) *)0) == ((uint64_t *)0));  \
>~~ ^  ~~~
> drivers/scsi/smartpqi/smartpqi_init.c:7473:2: error: incompatible pointer 
> types passing 'u32 *' (aka 'unsigned int *') to parameter of type 'uint64_t 
> *' (aka 'unsigned long long *') [-Werror,-Wincompatible-pointer-types]
> do_div(sg_count, chunk_size);
> ^~~~
> ./include/asm-generic/div64.h:239:22: note: expanded from macro 'do_div'
> __rem = __div64_32(&(n), __base);   \
>^~~~
> ./arch/arm/include/asm/div64.h:33:45: note: passing argument to parameter 'n' 
> here
> static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
> ^
> drivers/scsi/smartpqi/smartpqi_init.c:7473:2: warning: shift count >= width 
> of type [-Wshift-count-overflow]
> do_div(sg_count, chunk_size);
> ^~~~
> ./include/asm-generic/div64.h:235:25: note: expanded from macro 'do_div'
> } else if (likely(((n) >> 32) == 0)) {  \
>^  ~~
> ./include/linux/compiler.h:76:40: note: expanded from macro 'likely'
> # define likely(x)  __builtin_expect(!!(x), 1)
> ^
> 
> According to include/asm-generic/div64.h, the first parameter of do_div
> must be a 64-bit number, meaning the below diff would properly fix it.
> 
> However, I am not sure if there are any unintended consequences of this
> change, hence reaching out before sending it in. If you have a more
> preferred way of fixing it, please do so.
> 
> Thank you,
> Nathan
> 
> ==
> 
> diff --git a/drivers/scsi/smartpqi/smartpqi_init.c 
> b/drivers/scsi/smartpqi/smartpqi_init.c
> index e57fbff08f03..6a185a6172c4 100644
> --- a/drivers/scsi/smartpqi/smartpqi_init.c
> +++ b/drivers/scsi/smartpqi/smartpqi_init.c
> @@ -7460,7 +7460,7 @@ static void pqi_ofa_ctrl_unquiesce(struct pqi_ctrl_info 
> *ctrl_info)
>  static int pqi_ofa_alloc_mem(struct pqi_ctrl_info *ctrl_info,
> u32 total_size, u32 chunk_size)
>  {
> -   u32 sg_count;
> +   u64 sg_count;
> u32 size;
> int i;
> struct pqi_sg_descriptor *mem_descriptor = NULL;

Ugh disregard, I just looked at the SCSI tree and saw this was fixed
already:

https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=e52c9e0710d2f5d54a521d620a230ac2ae646dc7

Should have looked at it before sending, sorry for the noise!
Nathan


Re: [PATCHv2] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

2018-12-20 Thread Baoquan He
On 12/14/18 at 12:07pm, Pingfan Liu wrote:
> Customer reported a bug on a high end server with many pcie devices, where
> kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> though we still see much memory under 896 MB, the finding still failed
> intermittently. Because currently we can only find region under 896 MB,
> if w/0 ',high' specified. Then KASLR breaks 896 MB into several parts
> randomly, and crashkernel reservation need be aligned to 128 MB, that's
> why failure is found. It raises confusion to the end user that sometimes
> crashkernel=X works while sometimes fails.
> If want to make it succeed, customer can change kernel option to
> "crashkernel=384M, high". Just this give "crashkernel=xx@yy" a very
> limited space to behave even though its grammer looks more generic.
> And we can't answer questions raised from customer that confidently:
> 1) why it doesn't succeed to reserve 896 MB;
> 2) what's wrong with memory region under 4G;
> 3) why I have to add ',high', I only require 384 MB, not 3840 MB.
> 
> This patch simplifies the method suggested in the mail [1]. It just goes
> bottom-up to find a candidate region for crashkernel. The bottom-up may be
> better compatible with the old reservation style, i.e. still want to get
> memory region from 896 MB firstly, then [896 MB, 4G], finally above 4G.
> 
> There is one trivial thing about the compatibility with old kexec-tools:
> if the reserved region is above 896M, then old tool will fail to load
> bzImage. But without this patch, the old tool also fail since there is no
> memory below 896M can be reserved for crashkernel.
> 
> [1]: http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
> Signed-off-by: Pingfan Liu 
> Cc: Dave Young 
> Cc: Andrew Morton 
> Cc: Baoquan He 
> Cc: ying...@kernel.org,
> Cc: vgo...@redhat.com
> Cc: ke...@lists.infradead.org
> 
> ---
> v1->v2:
>   improve commit log
>  arch/x86/kernel/setup.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)

This is a bug fix and urged by our customer.

I personally think crashkernel=xx@ is a generic synctax, the current
code making it search only under 896 MB seems not so reasonable.

Ack this patch.

Acked-by: Baoquan He 

Thanks
Baoquan

> 
> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> index d494b9b..60f12c4 100644
> --- a/arch/x86/kernel/setup.c
> +++ b/arch/x86/kernel/setup.c
> @@ -541,15 +541,18 @@ static void __init reserve_crashkernel(void)
>  
>   /* 0 means: find the address automatically */
>   if (crash_base <= 0) {
> + if (!memblock_bottom_up())
> + memblock_set_bottom_up(true);
>   /*
>* Set CRASH_ADDR_LOW_MAX upper bound for crash memory,
>* as old kexec-tools loads bzImage below that, unless
>* "crashkernel=size[KMG],high" is specified.
>*/
>   crash_base = memblock_find_in_range(CRASH_ALIGN,
> - high ? CRASH_ADDR_HIGH_MAX
> -  : CRASH_ADDR_LOW_MAX,
> - crash_size, CRASH_ALIGN);
> + (max_pfn * PAGE_SIZE), crash_size, CRASH_ALIGN);
> + if (!memblock_bottom_up())
> + memblock_set_bottom_up(false);
> +
>   if (!crash_base) {
>   pr_info("crashkernel reservation failed - No suitable 
> area found.\n");
>   return;
> -- 
> 2.7.4
> 


Re: [PATCH v10 17/27] drivers: firmware: psci: Prepare to support PM domains

2018-12-20 Thread Daniel Lezcano
On 20/12/2018 22:37, Ulf Hansson wrote:
> On Thu, 20 Dec 2018 at 19:06, Daniel Lezcano  
> wrote:
>>
>> On 20/12/2018 16:49, Ulf Hansson wrote:
>>
>> [ ... ]
>>
> +#ifdef CONFIG_CPU_IDLE

 It would be nicer if you can remove the CONFIG_CPU_IDLE by replacing it
 with a specific one (eg. CONFIG_PSCI_IDLE) and make it depend on
 CONFIG_CPU_IDLE, so the config options stay contained in their
 respective subsystems directory.
>>>
>>> I am all for simplifying the Kconfig options in here, as indeed it's
>>> rather messy. However, I would rather avoid folding in additional
>>> cleanup changes to this series, is already extensive enough.
>>>
>>> Would you be okay if we deal with that on top?
>>
>> IMO, there are patches in this series which can be grouped into a
>> cleanup + set the scene patchset and merged immediately. An option
>> similar to ARM_SCMI_POWER_DOMAIN can be part of it.
> 
> I certainly agree to that. The tricky is, to know what pieces people
> are happy with to go in. :-)
> 
> Earlier, in v9 I tried your suggested approach (kind of), but then
> Lorenzo stated that it's kind of all or nothing. Maybe we can bring up
> that discussion again with him and see what we can figure out.
> 
>>
>> However, if you swear you will do the change after and sign with your
>> blood, I'm fine with that 0:)
>>
> 
> Whatever it takes!
> 
> Anyway, as stated, the reason why I want to tackle that on top, is
> that I don't want to make the series more extensive than it already
> is.
> 
> Agree?

Yes

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

Follow Linaro:   Facebook |
 Twitter |
 Blog



Clang build error in drivers/scsi/smartpqi/smartpqi_init.c

2018-12-20 Thread Nathan Chancellor
Hi all,

After commit 4fd22c13ad44 ("scsi: smartpqi: add ofa support"), an arm
allyesconfig build with Clang fails with the following warning/error:

drivers/scsi/smartpqi/smartpqi_init.c:7473:2: warning: comparison of distinct 
pointer types ('typeof ((sg_count)) *' (aka 'unsigned int *') and 'uint64_t *' 
(aka 'unsigned long long *')) [-Wcompare-distinct-pointer-types]
do_div(sg_count, chunk_size);
^~~~
./include/asm-generic/div64.h:222:28: note: expanded from macro 'do_div'
(void)(((typeof((n)) *)0) == ((uint64_t *)0));  \
   ~~ ^  ~~~
drivers/scsi/smartpqi/smartpqi_init.c:7473:2: error: incompatible pointer types 
passing 'u32 *' (aka 'unsigned int *') to parameter of type 'uint64_t *' (aka 
'unsigned long long *') [-Werror,-Wincompatible-pointer-types]
do_div(sg_count, chunk_size);
^~~~
./include/asm-generic/div64.h:239:22: note: expanded from macro 'do_div'
__rem = __div64_32(&(n), __base);   \
   ^~~~
./arch/arm/include/asm/div64.h:33:45: note: passing argument to parameter 'n' 
here
static inline uint32_t __div64_32(uint64_t *n, uint32_t base)
^
drivers/scsi/smartpqi/smartpqi_init.c:7473:2: warning: shift count >= width of 
type [-Wshift-count-overflow]
do_div(sg_count, chunk_size);
^~~~
./include/asm-generic/div64.h:235:25: note: expanded from macro 'do_div'
} else if (likely(((n) >> 32) == 0)) {  \
   ^  ~~
./include/linux/compiler.h:76:40: note: expanded from macro 'likely'
# define likely(x)  __builtin_expect(!!(x), 1)
^

According to include/asm-generic/div64.h, the first parameter of do_div
must be a 64-bit number, meaning the below diff would properly fix it.

However, I am not sure if there are any unintended consequences of this
change, hence reaching out before sending it in. If you have a more
preferred way of fixing it, please do so.

Thank you,
Nathan

==

diff --git a/drivers/scsi/smartpqi/smartpqi_init.c 
b/drivers/scsi/smartpqi/smartpqi_init.c
index e57fbff08f03..6a185a6172c4 100644
--- a/drivers/scsi/smartpqi/smartpqi_init.c
+++ b/drivers/scsi/smartpqi/smartpqi_init.c
@@ -7460,7 +7460,7 @@ static void pqi_ofa_ctrl_unquiesce(struct pqi_ctrl_info 
*ctrl_info)
 static int pqi_ofa_alloc_mem(struct pqi_ctrl_info *ctrl_info,
u32 total_size, u32 chunk_size)
 {
-   u32 sg_count;
+   u64 sg_count;
u32 size;
int i;
struct pqi_sg_descriptor *mem_descriptor = NULL;


Re: [PATCH 4.19 00/67] 4.19.12-stable review

2018-12-20 Thread Greg Kroah-Hartman
On Thu, Dec 20, 2018 at 08:33:23PM +0530, Naresh Kamboju wrote:
> On Thu, 20 Dec 2018 at 14:59, Greg Kroah-Hartman
>  wrote:
> >
> > This is the start of the stable review cycle for the 4.19.12 release.
> > There are 67 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Sat Dec 22 08:58:49 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.12-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.19.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.

That was fast, you all are getting quicker :)

Anyway, thanks for testing all of these kernels and letting me know.

greg k-h


Re: [PATCH 4.19 00/67] 4.19.12-stable review

2018-12-20 Thread Greg Kroah-Hartman
On Thu, Dec 20, 2018 at 10:29:59AM -0800, Guenter Roeck wrote:
> On Thu, Dec 20, 2018 at 10:18:12AM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.12 release.
> > There are 67 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Dec 22 08:58:49 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 155 pass: 155 fail: 0
> Qemu test results:
>   total: 328 pass: 328 fail: 0
> 
> Details are available at https://kerneltests.org/builders/.

Thanks for testing all of thse and letting me know.

greg k-h


Re: [PATCH 4.19 00/67] 4.19.12-stable review

2018-12-20 Thread Greg Kroah-Hartman
On Thu, Dec 20, 2018 at 03:48:09PM -0700, shuah wrote:
> On 12/20/18 2:18 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.19.12 release.
> > There are 67 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Sat Dec 22 08:58:49 UTC 2018.
> > Anything received after that time might be too late.
> > 
> > The whole patch series can be found in one patch at:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.12-rc1.gz
> > or in the git tree and branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.19.y
> > and the diffstat can be found below.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> 
> Compiled and booted on my test system. No dmesg regressions.

Thanks for testing all of these and letting me know.

greg k-h


[PATCH] media: mt312: fix a missing check of mt312 reset

2018-12-20 Thread Kangjie Lu
mt312_reset() may fail. Although it is called in the end of
mt312_set_frontend(), we better check its status and return its error
code upstream instead of 0.

Signed-off-by: Kangjie Lu 
---
 drivers/media/dvb-frontends/mt312.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/mt312.c 
b/drivers/media/dvb-frontends/mt312.c
index 03e74a729168..bfbb879469f2 100644
--- a/drivers/media/dvb-frontends/mt312.c
+++ b/drivers/media/dvb-frontends/mt312.c
@@ -645,7 +645,9 @@ static int mt312_set_frontend(struct dvb_frontend *fe)
if (ret < 0)
return ret;
 
-   mt312_reset(state, 0);
+   ret = mt312_reset(state, 0);
+   if (ret < 0)
+   return ret;
 
return 0;
 }
-- 
2.17.2 (Apple Git-113)



Re: [GIT PULL] asm-generic: syscall table script for arch/sh

2018-12-20 Thread Christoph Hellwig
> The conversion does not include the old 64-bit sh5 architecture, which
> has never shipped and not even compiled in a long time.

Maybe it is time to drop the code for it then?


Re: [PATCH v2 01/12] fs-verity: add a documentation file

2018-12-20 Thread Christoph Hellwig
On Thu, Dec 20, 2018 at 05:01:58PM -0500, Theodore Y. Ts'o wrote:
> That's simply not true.  Number one, fsverity is not mandatory for all
> file systems to implement.  If XFS doesn't want to implement fscrypt
> or fsverity, it doesn't have to.  Number two, we're not *making* any
> changes to the kernel code; nothing in mm/filemap.c, et. al.  So
> saying that we are making changes that are impacted by /everyone/ just
> doesn't make any sense.

Ted, I think you know yourself this isn't true.  Whenever we added
useful interface to one of the major file systems we had other pick
it up, and that is a good thing because the last thing we need is
fragmentation of interfaces.  And even if that wasn't the case I don't
think we should take short cuts, because even if an interface was just
for a file system or two it still needs to be properly desgined.

There is no reason to rush interfacs in, because everytime we have done
that it has turned out to be a very bad idea in retrospective.


[PATCH] touchscreen: elants: fix a missing check of return values

2018-12-20 Thread Kangjie Lu
elants_i2c_send() may fail, let's check its return values. The fix does
the check and reports an error message upon the failure.

Signed-off-by: Kangjie Lu 
---
 drivers/input/touchscreen/elants_i2c.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c 
b/drivers/input/touchscreen/elants_i2c.c
index f2cb23121833..cb3c1470bb68 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -245,8 +245,14 @@ static int elants_i2c_calibrate(struct elants_data *ts)
ts->state = ELAN_WAIT_RECALIBRATION;
reinit_completion(>cmd_done);
 
-   elants_i2c_send(client, w_flashkey, sizeof(w_flashkey));
-   elants_i2c_send(client, rek, sizeof(rek));
+   error = elants_i2c_send(client, w_flashkey, sizeof(w_flashkey));
+   error |= elants_i2c_send(client, rek, sizeof(rek));
+   if (error) {
+   dev_err(>dev,
+   "error in sending I2C messages for calibration: 
%d\n",
+   error);
+   return error;
+   }
 
enable_irq(client->irq);
 
-- 
2.17.2 (Apple Git-113)



Re: [PATCH v3 6/7] arm64: dts: xilinx: ultra96: Standardize LED labels and triggers

2018-12-20 Thread Michal Simek
On 21. 12. 18 3:37, Manivannan Sadhasivam wrote:
> On Mon, Oct 29, 2018 at 03:12:44PM +0530, Manivannan Sadhasivam wrote:
>> For all 96Boards, the following standard is used for onboard LEDs.
>>
>> green:user1  default-trigger: heartbeat
>> green:user2  default-trigger: mmc0/disk-activity(onboard-storage)
>> green:user3  default-trigger: mmc1 (SD-card)
>> green:user4  default-trigger: none, panic-indicator
>> yellow:wlan  default-trigger: phy0tx
>> blue:bt  default-trigger: hci0-power
>>
>> So lets adopt the same for Ultra96, which is one of the 96Boards
>> CE and AI platform. Since the WLAN and BT LEDs are hardwired onboard,
>> consolidate only User LEDs.
>>
> 
> Hello,
> 
> Any update on this patch?

I am still waiting for reaction from Rob.
We are keep trying to keep backward compatibility and this patch is
breaking it that's why I want to know DT guys reaction on this change.

Thanks,
Michal


Re: [RFC PATCH v2 04/11] powerpc/mm: Add a framework for Kernel Userspace Access Protection

2018-12-20 Thread Christophe Leroy




Le 21/12/2018 à 06:07, Michael Ellerman a écrit :

Christophe Leroy  writes:


This patch implements a framework for Kernel Userspace Access
Protection.

Then subarches will have to possibility to provide their own
implementation by providing setup_kuap() and lock/unlock_user_access()

Some platform will need to know the area accessed and whether it is
accessed from read, write or both. Therefore source, destination and
size and handed over to the two functions.

Signed-off-by: Christophe Leroy 


I think some of this code came from Russell's original patch?

In which case we should have his signed-off-by here.



Yes that's right the ppc64 part is from Russel. As it's still an RFC and 
there is still some work to be done I didn't pay much attention to 
Signed-off and other tags yet.


Signed-off-by: Russell Currey 


Christophe


[PATCH] netfilter: fix a missing check of nla put failure

2018-12-20 Thread Kangjie Lu
If nla_nest_start() may fail. The fix checks its return value and goes
to nla_put_failure if it fails.

Signed-off-by: Kangjie Lu 
---
 net/netfilter/nf_tables_api.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 2e61aab6ed73..bc1b9814f2ee 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -5689,6 +5689,8 @@ static int nf_tables_fill_flowtable_info(struct sk_buff 
*skb, struct net *net,
goto nla_put_failure;
 
nest = nla_nest_start(skb, NFTA_FLOWTABLE_HOOK);
+   if (!nest)
+   goto nla_put_failure;
if (nla_put_be32(skb, NFTA_FLOWTABLE_HOOK_NUM, 
htonl(flowtable->hooknum)) ||
nla_put_be32(skb, NFTA_FLOWTABLE_HOOK_PRIORITY, 
htonl(flowtable->priority)))
goto nla_put_failure;
-- 
2.17.2 (Apple Git-113)



Re: 4.20-rc6: WARNING: CPU: 30 PID: 197360 at net/core/flow_dissector.c:764 __skb_flow_dissect

2018-12-20 Thread Christian Borntraeger



On 20.12.2018 18:23, Willem de Bruijn wrote:
> On Thu, Dec 20, 2018 at 11:17 AM Ido Schimmel  wrote:
>>
>> On Thu, Dec 20, 2018 at 03:09:22PM +0100, Christian Borntraeger wrote:
>>> On 20.12.2018 10:12, Ido Schimmel wrote:
 +Willem

 On Thu, Dec 20, 2018 at 08:45:40AM +0100, Christian Borntraeger wrote:
> Folks,
>
> I got this warning today. I cant tell when and why this happened, so I do 
> not know yet how to reproduce.
> Maybe someone has a quick idea.
>
> [85109.572032] WARNING: CPU: 30 PID: 197360 at 
> net/core/flow_dissector.c:764 __skb_flow_dissect+0x1f0/0x1318

 I managed to trigger this warning as well the other day, but from a
 different call path:
>>>
>>> FWIW, it also seems to happen on 4.20-rc1. 4.19.0 seems fine. bisect seem 
>>> to have failed so
>>> my reproducer is not reliable.
>>
>> Yes, it is caused by commit d0e13a1488ad ("flow_dissector: lookup netns
>> by skb->sk if skb->dev is NULL")
>>
>> $ git tag --contains d0e13a1488ad
>> v4.20-rc1
>> v4.20-rc2
>> v4.20-rc3
>> v4.20-rc4
>> v4.20-rc5
>> v4.20-rc6
> 
> That tap_get_user_xdp path is also new for 4.20-rc1:
> 
> commit 0efac27791ee068075d80f07c55a229b1335ce12
> tap: accept an array of XDP buffs through sendmsg()
> 
> $ git describe --contains 0efac27791ee
> v4.20-rc1~14^2~382^2~1
> 
> In v4.19 and before all packets went through tap_get_user.

Hmmm, so maybe my bisect wasnt broken at all? It pointed to

commit 105bc1306e9b29c2aa2783b9524f7aec9b5a5b1f
Merge: 3475372ff60e4 d0e13a1488ad3
Author: David S. Miller 
AuthorDate: Tue Sep 25 20:29:38 2018 -0700
Commit: David S. Miller 
CommitDate: Tue Sep 25 20:29:38 2018 -0700

Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next



Re: [PATCH] percpu_rwsem: fix missed wakeup due to reordering of load

2018-12-20 Thread Prateek Sood
On 12/12/2018 08:58 PM, Andrea Parri wrote:
> On Fri, Nov 30, 2018 at 08:40:56PM +0530, Prateek Sood wrote:
>> In a scenario where cpu_hotplug_lock percpu_rw_semaphore is already
>> acquired for read operation by P1 using percpu_down_read().
>>
>> Now we have P1 in the path of releaseing the cpu_hotplug_lock and P2
>> is in the process of acquiring cpu_hotplug_lock.
>>
>> P1   P2
>> percpu_up_read() path  percpu_down_write() path
>>
>>   rcu_sync_enter() 
>> //gp_state=GP_PASSED
>>
>> rcu_sync_is_idle() //returns falsedown_write(rw_sem)
>>
>> __percpu_up_read()
>>
>> [L] task = rcu_dereference(w->task) //NULL
>>
>> smp_rmb()  [S] w->task = current
>>
>> smp_mb()
>>
>>[L] readers_active_check() //fails
>>   schedule()
>>
>> [S] __this_cpu_dec(read_count)
>>
>> Since load of task can result in NULL. This can lead to missed wakeup
>> in rcuwait_wake_up(). Above sequence violated the following constraint
>> in rcuwait_wake_up():
>>
>>   WAITWAKE
>> [S] tsk = current  [S] cond = true
>> MB (A)   MB (B)
>> [L] cond   [L] tsk
>>
>> This can happen as smp_rmb() in rcuwait_wake_up() will provide ordering
>> of load before barrier with load and store after barrier for arm64
>> architecture. Here the requirement is to order store before smp_rmb()
>> with load after the smp_rmb().
>>
>> For the usage of rcuwait_wake_up() in __percpu_up_read() full barrier
>> (smp_mb) is required to complete the constraint of rcuwait_wake_up().
>>
>> Signed-off-by: Prateek Sood 
> 
> I know this is going to sound ridiculous (coming from me or from
> the Italian that I am), but it looks like we could both work on
> our English. ;-)
> 
> But the fix seems correct to me:
> 
> Reviewed-by: Andrea Parri 
> 
> It might be a good idea to integrate this fix with fixes to the
> inline comments/annotations: for example, I see that the comment
> in rcuwait_wake_up() mentions a non-existing rcuwait_trywake();
Ok, I will update the comment in next version of the patch.

> moreover, the memory-barrier annotation "B" is used also for the
> smp_mb() preceding the __this_cpu_dec() in __percpu_up_read().
In this annotation "B" is corresponding to annotation "A" in
rcuwait_wait_event(). So this seems to be correct.

> 
>   Andrea
> 
> 
>> ---
>>  kernel/exit.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/kernel/exit.c b/kernel/exit.c
>> index f1d74f0..a10820d 100644
>> --- a/kernel/exit.c
>> +++ b/kernel/exit.c
>> @@ -306,7 +306,7 @@ void rcuwait_wake_up(struct rcuwait *w)
>>   *MB (A)  MB (B)
>>   *[L] cond[L] tsk
>>   */
>> -smp_rmb(); /* (B) */
>> +smp_mb(); /* (B) */
>>  
>>  /*
>>   * Avoid using task_rcu_dereference() magic as long as we are careful,
>> -- 
>> Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, 
>> Inc., 
>> is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.
>>


-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation
Center, Inc., is a member of Code Aurora Forum, a Linux Foundation
Collaborative Project


Re: [PATCH 1/2] mm: vmscan: skip KSM page in direct reclaim if priority is low

2018-12-20 Thread Yang Shi




On 12/20/18 10:04 PM, Hugh Dickins wrote:

On Thu, 20 Dec 2018, Andrew Morton wrote:

Is anyone interested in reviewing this?  Seems somewhat serious.
Thanks.

Somewhat serious, but no need to rush.


From: Yang Shi 
Subject: mm: vmscan: skip KSM page in direct reclaim if priority is low

When running a stress test, we occasionally run into the below hang issue:

Artificial load presumably.


INFO: task ksmd:205 blocked for more than 360 seconds.
   Tainted: GE 
4.9.128-001.ali3000_nightly_20180925_264.alios7.x86_64 #1

4.9-stable does not contain Andrea's 4.13 commit 2c653d0ee2ae
("ksm: introduce ksm_max_page_sharing per page deduplication limit").

The patch below is more economical than Andrea's, but I don't think
a second workaround should be added, unless Andrea's is shown to be
insufficient, even with its ksm_max_page_sharing tuned down to suit.

Yang, please try to reproduce on upstream, or backport Andrea's to
4.9-stable - thanks.


I believe Andrea's commit could workaround this problem too by limiting 
the number of sharing pages.


However, IMHO, even though we just have a few hundred pages share one 
KSM page, it still sounds not worth reclaiming it in direct reclaim in 
low priority. According to Andrea's commit log, it still takes a few 
msec to walk the rmap for 256 shared pages.


Thanks,
Yang



Hugh


"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
ksmdD0   205  2 0x
  882fa00418c0  882fa4b1 882fbf059d00
  882fa5bc1800 c900190c7c28 81725e58 810777c0
  00ffc900190c7c88 882fbf059d00 8138cc09 882fa4b1
Call Trace:
  [] ? __schedule+0x258/0x720
  [] ? do_flush_tlb_all+0x30/0x30
  [] ? free_cpumask_var+0x9/0x10
  [] schedule+0x36/0x80
  [] schedule_timeout+0x206/0x4b0
  [] ? native_flush_tlb_others+0x11f/0x180
  [] ? ktime_get+0x40/0xb0
  [] io_schedule_timeout+0xda/0x170
  [] ? bit_wait+0x60/0x60
  [] bit_wait_io+0x1b/0x60
  [] __wait_on_bit_lock+0x59/0xc0
  [] __lock_page+0x86/0xa0
  [] ? wake_atomic_t_function+0x60/0x60
  [] ksm_scan_thread+0xeb9/0x1430
  [] ? prepare_to_wait_event+0x100/0x100
  [] ? try_to_merge_with_ksm_page+0x850/0x850
  [] kthread+0xe6/0x100
  [] ? kthread_park+0x60/0x60
  [] ret_from_fork+0x46/0x60

ksmd found a suitable KSM page on the stable tree and is trying to lock
it.  But it is locked by the direct reclaim path which is walking the
page's rmap to get the number of referenced PTEs.

The KSM page rmap walk needs to iterate all rmap_items of the page and all
rmap anon_vmas of each rmap_item.  So it may take (# rmap_item * #
children processes) loops.  This number of loops might be very large in
the worst case, and may take a long time.

Typically, direct reclaim will not intend to reclaim too many pages, and
it is latency sensitive.  So it is not worth doing the long ksm page rmap
walk to reclaim just one page.

Skip KSM pages in direct reclaim if the reclaim priority is low, but still
try to reclaim KSM pages with high priority.

Link: 
http://lkml.kernel.org/r/1541618201-120667-1-git-send-email-yang@linux.alibaba.com
Signed-off-by: Yang Shi 
Cc: Vlastimil Babka 
Cc: Johannes Weiner 
Cc: Hugh Dickins 
Cc: Michal Hocko 
Cc: Andrea Arcangeli 
Signed-off-by: Andrew Morton 
---

  mm/vmscan.c |   23 +--
  1 file changed, 21 insertions(+), 2 deletions(-)

--- a/mm/vmscan.c~mm-vmscan-skip-ksm-page-in-direct-reclaim-if-priority-is-low
+++ a/mm/vmscan.c
@@ -1260,8 +1260,17 @@ static unsigned long shrink_page_list(st
}
}
  
-		if (!force_reclaim)

-   references = page_check_references(page, sc);
+   if (!force_reclaim) {
+   /*
+* Don't try to reclaim KSM page in direct reclaim if
+* the priority is not high enough.
+*/
+   if (PageKsm(page) && !current_is_kswapd() &&
+   sc->priority > (DEF_PRIORITY - 2))
+   references = PAGEREF_KEEP;
+   else
+   references = page_check_references(page, sc);
+   }
  
  		switch (references) {

case PAGEREF_ACTIVATE:
@@ -2136,6 +2145,16 @@ static void shrink_active_list(unsigned
}
}
  
+		/*

+* Skip KSM page in direct reclaim if priority is not
+* high enough.
+*/
+   if (PageKsm(page) && !current_is_kswapd() &&
+   sc->priority > (DEF_PRIORITY - 2)) {
+   putback_lru_page(page);
+   continue;
+   }
+
if (page_referenced(page, 0, sc->target_mem_cgroup,
_flags)) {
nr_rotated += hpage_nr_pages(page);
_




[PATCH] regulator: tps65910: fix a missing check of return value

2018-12-20 Thread Kangjie Lu
tps65910_reg_set_bits() may fail. The fix checks if it fails, and if so,
returns with its error code.

Signed-off-by: Kangjie Lu 
---
 drivers/regulator/tps65910-regulator.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/regulator/tps65910-regulator.c 
b/drivers/regulator/tps65910-regulator.c
index 02ccdaa226a7..5ebb6ee73f07 100644
--- a/drivers/regulator/tps65910-regulator.c
+++ b/drivers/regulator/tps65910-regulator.c
@@ -1102,8 +1102,10 @@ static int tps65910_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, pmic);
 
/* Give control of all register to control port */
-   tps65910_reg_set_bits(pmic->mfd, TPS65910_DEVCTRL,
+   err = tps65910_reg_set_bits(pmic->mfd, TPS65910_DEVCTRL,
DEVCTRL_SR_CTL_I2C_SEL_MASK);
+   if (err < 0)
+   return err;
 
switch (tps65910_chip_id(tps65910)) {
case TPS65910:
-- 
2.17.2 (Apple Git-113)



[v1] arm64: dts: sdm845: add interconnect DT entries for MDSS on SDM845

2018-12-20 Thread Jayant Shekhar
Add interconnect properties such as the source and the destination
ports for MDSS on SDM845.

Signed-off-by: Jayant Shekhar 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 0ded68c..ba97547 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2120,6 +2120,11 @@
interrupt-controller;
#interrupt-cells = <1>;
 
+   interconnects = <_hlos MASTER_MDP0 _hlos 
SLAVE_EBI1>,
+   <_hlos MASTER_MDP1 _hlos 
SLAVE_EBI1>;
+
+   interconnect-names = "mdp0-mem", "mdp1-mem";
+
iommus = <_smmu 0x880 0x8>,
 <_smmu 0xc80 0x8>;
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v3] mm, page_alloc: Fix has_unmovable_pages for HugePages

2018-12-20 Thread Oscar Salvador
v3 -> v2: Get rid of the round_up()
v2 -> v1: Adjust skip pages logic per Michal

>From 8c057ff497a078f28e293af8c0bd089893a57753 Mon Sep 17 00:00:00 2001
From: Oscar Salvador 
Date: Wed, 19 Dec 2018 00:04:18 +
Subject: [PATCH] mm, page_alloc: fix has_unmovable_pages for HugePages

While playing with gigantic hugepages and memory_hotplug, I triggered the
following #PF when "cat memoryX/removable":

<---
kernel: BUG: unable to handle kernel NULL pointer dereference at 
0008
kernel: #PF error: [normal kernel read fault]
kernel: PGD 0 P4D 0
kernel: Oops:  [#1] SMP PTI
kernel: CPU: 1 PID: 1481 Comm: cat Tainted: GE 
4.20.0-rc6-mm1-1-default+ #18
kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.0.0-prebuilt.qemu-project.org 04/01/2014
kernel: RIP: 0010:has_unmovable_pages+0x154/0x210
kernel: Code: 1b ff ff ff eb 32 48 8b 45 00 bf 00 10 00 00 a9 00 00 01 00 74 07 
0f b6 4d 51 48 d3 e7 e8 c4 81 05 00 48 85 c0 49 89 c1 75 7e <41> 8b 41 08 83 f8 
09 74 41 83 f8 1b 74 3c 4d 2b 64 24 58 49 81 ec
kernel: RSP: 0018:c9a1fd30 EFLAGS: 00010246
kernel: RAX:  RBX:  RCX: 0009
kernel: RDX: 82aed4f0 RSI: 1000 RDI: 1000
kernel: RBP: ea000180 R08: 0020 R09: 
kernel: R10: 1000 R11: 0003 R12: 88813ffd45c0
kernel: R13: 0006 R14: 0001 R15: ea00
kernel: FS:  7fd71d9b3500() GS:88813bb0() 
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 0008 CR3: 0001371c2002 CR4: 003606e0
kernel: DR0:  DR1:  DR2: 
kernel: DR3:  DR6: fffe0ff0 DR7: 0400
kernel: Call Trace:
kernel:  is_mem_section_removable+0x7d/0x100
kernel:  removable_show+0x90/0xb0
kernel:  dev_attr_show+0x1c/0x50
kernel:  sysfs_kf_seq_show+0xca/0x1b0
kernel:  seq_read+0x133/0x380
kernel:  __vfs_read+0x26/0x180
kernel:  vfs_read+0x89/0x140
kernel:  ksys_read+0x42/0x90
kernel:  do_syscall_64+0x5b/0x180
kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
kernel: RIP: 0033:0x7fd71d4c8b41
kernel: Code: fe ff ff 48 8d 3d 27 9e 09 00 48 83 ec 08 e8 96 02 02 00 66 0f 1f 
44 00 00 8b 05 ea fc 2c 00 48 63 ff 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 
77 57 f3 c3 0f 1f 44 00 00 55 53 48 89 d5 48 89
kernel: RSP: 002b:7ffeab5f6448 EFLAGS: 0246 ORIG_RAX: 
kernel: RAX: ffda RBX: 0002 RCX: 7fd71d4c8b41
kernel: RDX: 0002 RSI: 7fd71d809000 RDI: 0003
kernel: RBP: 0002 R08:  R09: 
kernel: R10: 038b R11: 0246 R12: 7fd71d809000
kernel: R13: 0003 R14: 7fd71d80900f R15: 0002
kernel: Modules linked in: af_packet(E) xt_tcpudp(E) ipt_REJECT(E) 
xt_conntrack(E) nf_conntrack(E) nf_defrag_ipv4(E) ip_set(E) nfnetlink(E) 
ebtable_nat(E) ebtable_broute(E) bridge(E) stp(E) llc(E) iptable_mangle(E) 
iptable_raw(E) iptable_security(E) ebtable_filter(E) ebtables(E) 
iptable_filter(E) ip_tables(E) x_tables(E) kvm_intel(E) kvm(E) irqbypass(E) 
crct10dif_pclmul(E) crc32_pclmul(E) ghash_clmulni_intel(E) bochs_drm(E) ttm(E) 
drm_kms_helper(E) drm(E) aesni_intel(E) virtio_net(E) syscopyarea(E) 
net_failover(E) sysfillrect(E) failover(E) aes_x86_64(E) crypto_simd(E) 
sysimgblt(E) cryptd(E) pcspkr(E) glue_helper(E) parport_pc(E) fb_sys_fops(E) 
i2c_piix4(E) parport(E) button(E) btrfs(E) libcrc32c(E) xor(E) 
zstd_decompress(E) zstd_compress(E) raid6_pq(E) sd_mod(E) ata_generic(E) 
ata_piix(E) ahci(E) libahci(E) serio_raw(E) crc32c_intel(E) virtio_pci(E) 
virtio_ring(E) virtio(E) libata(E) sg(E) scsi_mod(E) autofs4(E)
kernel: CR2: 0008
kernel: ---[ end trace 49cade81474e40e7 ]---
kernel: RIP: 0010:has_unmovable_pages+0x154/0x210
kernel: Code: 1b ff ff ff eb 32 48 8b 45 00 bf 00 10 00 00 a9 00 00 01 00 74 07 
0f b6 4d 51 48 d3 e7 e8 c4 81 05 00 48 85 c0 49 89 c1 75 7e <41> 8b 41 08 83 f8 
09 74 41 83 f8 1b 74 3c 4d 2b 64 24 58 49 81 ec
kernel: RSP: 0018:c9a1fd30 EFLAGS: 00010246
kernel: RAX:  RBX:  RCX: 0009
kernel: RDX: 82aed4f0 RSI: 1000 RDI: 1000
kernel: RBP: ea000180 R08: 0020 R09: 
kernel: R10: 1000 R11: 0003 R12: 88813ffd45c0
kernel: R13: 0006 R14: 0001 R15: ea00
kernel: FS:  7fd71d9b3500() GS:88813bb0() 
knlGS:
kernel: CS:  0010 DS:  ES:  CR0: 80050033
kernel: CR2: 0008 CR3: 0001371c2002 CR4: 003606e0
kernel: DR0:  DR1:  DR2: 
kernel: DR3:  DR6: fffe0ff0 DR7: 0400
--->

The reason is we do 

[PATCH] net: netxen: fix a missing check and an uninitialized use

2018-12-20 Thread Kangjie Lu
When netxen_rom_fast_read() fails, "bios" is left uninitialized and may
contain random value, thus should not be used.

The fix ensures that if netxen_rom_fast_read() fails, we return "-EIO".

Signed-off-by: Kangjie Lu 
---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c 
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index 0ea141ece19e..6547a9dd5935 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
@@ -1125,7 +1125,8 @@ netxen_validate_firmware(struct netxen_adapter *adapter)
return -EINVAL;
}
val = nx_get_bios_version(adapter);
-   netxen_rom_fast_read(adapter, NX_BIOS_VERSION_OFFSET, (int *));
+   if (netxen_rom_fast_read(adapter, NX_BIOS_VERSION_OFFSET, (int *)))
+   return -EIO;
if ((__force u32)val != bios) {
dev_err(>dev, "%s: firmware bios is incompatible\n",
fw_name[fw_type]);
-- 
2.17.2 (Apple Git-113)



[PATCH] kconfig: remove unused "file" field of yylval union

2018-12-20 Thread Masahiro Yamada
This has never been used.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/zconf.y | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 8a4d029..60ee8e7 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -36,7 +36,6 @@ static struct menu *current_menu, *current_entry;
 %union
 {
char *string;
-   struct file *file;
struct symbol *symbol;
struct expr *expr;
struct menu *menu;
-- 
2.7.4



Re: [PATCHv2 2/3] mm/numa: build zonelist when alloc for device on offline node

2018-12-20 Thread Pingfan Liu
On Thu, Dec 20, 2018 at 8:44 PM Michal Hocko  wrote:
>
> On Thu 20-12-18 20:26:28, Pingfan Liu wrote:
> > On Thu, Dec 20, 2018 at 7:35 PM Michal Hocko  wrote:
> > >
> > > On Thu 20-12-18 17:50:38, Pingfan Liu wrote:
> > > [...]
> > > > @@ -453,7 +456,12 @@ static inline int gfp_zonelist(gfp_t flags)
> > > >   */
> > > >  static inline struct zonelist *node_zonelist(int nid, gfp_t flags)
> > > >  {
> > > > - return NODE_DATA(nid)->node_zonelists + gfp_zonelist(flags);
> > > > + if (unlikely(!possible_zonelists[nid])) {
> > > > + WARN_ONCE(1, "alloc from offline node: %d\n", nid);
> > > > + if (unlikely(build_fallback_zonelists(nid)))
> > > > + nid = first_online_node;
> > > > + }
> > > > + return possible_zonelists[nid] + gfp_zonelist(flags);
> > > >  }
> > >
> > > No, please don't do this. We do not want to make things work magically
> >
> > For magically, if you mean directly replies on zonelist instead of on
> > pgdat struct, then it is easy to change
>
> No, I mean that we _know_ which nodes are possible. Platform is supposed
> to tell us. We should just do the intialization properly. What we do now
> instead is a pile of hacks that fit magically together. And that should
> be changed.
>
Not agree. Here is the typical lazy to do, and at this point there is
also possible node info for us to check and build pgdat instance.

> > > and we definitely do not want to put something like that into the hot
> >
> > But  the cose of "unlikely" can be ignored, why can it not be placed
> > in the path?
>
> unlikely will simply put the code outside of the hot path. The condition
> is still there. There are people desperately fighting to get every
> single cycle out of the page allocator. Now you want them to pay a
> branch which is relevant only for few obscure HW setups.
>
Data is more convincing.
I test with the following program  built with -O2 on x86. No
observable performance difference between adding an extra unlikely
condition. And it is apparent that the frequency of checking on
unlikely is much higher than my patch.
#include 
#define unlikely_notrace(x) __builtin_expect(!!(x), 0)
#define unlikely(x) unlikely_notrace(x)
#define TEST_UNLIKELY 1
int main(int argc, char *argv[])
{
unsigned long i,j;
unsigned long end = (unsigned long)1 << 36;
unsigned long x = 9;
for (i = 1; i < end; i++) {
#ifdef TEST_UNLIKELY
if (unlikely(i == end - 1))
x *= 8;
#endif
x *= i;
x = x%10 + 1;
}
return 0;
}

> > > path. We definitely need zonelists to be build transparently for all
> > > possible nodes during the init time.
> >
> > That is the point, whether the all nodes should be instanced at boot
> > time, or not be instanced until there is requirement.
>
> And that should be done at init time. We have all the information
> necessary at that time.
> --

Will see other guys' comment.

Thanks and regards,
Pingfan


drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:2547: undefined reference to `vxlan_fdb_find_uc'

2018-12-20 Thread kbuild test robot
tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9097a058d49e049925d8da72db07fffcee24efa0
commit: 1231e04f5bba47f87d0b690a2d58c771a59f93aa mlxsw: spectrum_switchdev: Add 
support for VxLAN encapsulation
date:   9 weeks ago
config: x86_64-randconfig-s2-12211040 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 1231e04f5bba47f87d0b690a2d58c771a59f93aa
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.o: In function 
`mlxsw_sp_switchdev_bridge_vxlan_fdb_event':
>> drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:2547: undefined 
>> reference to `vxlan_fdb_find_uc'

vim +2547 drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c

  2532  
  2533  static void
  2534  mlxsw_sp_switchdev_bridge_vxlan_fdb_event(struct mlxsw_sp *mlxsw_sp,
  2535struct 
mlxsw_sp_switchdev_event_work *
  2536switchdev_work,
  2537struct mlxsw_sp_fid *fid, 
__be32 vni)
  2538  {
  2539  struct switchdev_notifier_vxlan_fdb_info vxlan_fdb_info;
  2540  struct switchdev_notifier_fdb_info *fdb_info;
  2541  struct net_device *dev = switchdev_work->dev;
  2542  enum mlxsw_sp_l3proto proto;
  2543  union mlxsw_sp_l3addr addr;
  2544  int err;
  2545  
  2546  fdb_info = _work->fdb_info;
> 2547  err = vxlan_fdb_find_uc(dev, fdb_info->addr, vni, 
> _fdb_info);
  2548  if (err)
  2549  return;
  2550  
  2551  mlxsw_sp_switchdev_vxlan_addr_convert(_fdb_info.remote_ip,
  2552, );
  2553  
  2554  switch (switchdev_work->event) {
  2555  case SWITCHDEV_FDB_ADD_TO_DEVICE:
  2556  err = mlxsw_sp_port_fdb_tunnel_uc_op(mlxsw_sp,
  2557   
vxlan_fdb_info.eth_addr,
  2558   
mlxsw_sp_fid_index(fid),
  2559   proto, , 
true, false);
  2560  if (err)
  2561  return;
  2562  vxlan_fdb_info.offloaded = true;
  2563  call_switchdev_notifiers(SWITCHDEV_VXLAN_FDB_OFFLOADED, 
dev,
  2564   _fdb_info.info);
  2565  mlxsw_sp_fdb_call_notifiers(SWITCHDEV_FDB_OFFLOADED,
  2566  vxlan_fdb_info.eth_addr,
  2567  fdb_info->vid, dev, true);
  2568  break;
  2569  case SWITCHDEV_FDB_DEL_TO_DEVICE:
  2570  err = mlxsw_sp_port_fdb_tunnel_uc_op(mlxsw_sp,
  2571   
vxlan_fdb_info.eth_addr,
  2572   
mlxsw_sp_fid_index(fid),
  2573   proto, , 
false,
  2574   false);
  2575  vxlan_fdb_info.offloaded = false;
  2576  call_switchdev_notifiers(SWITCHDEV_VXLAN_FDB_OFFLOADED, 
dev,
  2577   _fdb_info.info);
  2578  break;
  2579  }
  2580  }
  2581  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


[PATCH] hwmon: lm80: fix a missing check of return value

2018-12-20 Thread Kangjie Lu
If lm80_read_value() fails, it returns a negative number instead of the
correct read data. Therefore, we should avoid using the data if it
fails.

The fix checks if lm80_read_value() fails, and if so, returns with the
error number.

Signed-off-by: Kangjie Lu 
---
 drivers/hwmon/lm80.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/hwmon/lm80.c b/drivers/hwmon/lm80.c
index 08e3945a6fbf..fca6363cd77f 100644
--- a/drivers/hwmon/lm80.c
+++ b/drivers/hwmon/lm80.c
@@ -360,9 +360,11 @@ static ssize_t set_fan_div(struct device *dev, struct 
device_attribute *attr,
struct i2c_client *client = data->client;
unsigned long min, val;
u8 reg;
-   int err = kstrtoul(buf, 10, );
-   if (err < 0)
-   return err;
+   int ret;
+
+   ret = kstrtoul(buf, 10, );
+   if (ret < 0)
+   return ret;
 
/* Save fan_min */
mutex_lock(>update_lock);
@@ -390,8 +392,11 @@ static ssize_t set_fan_div(struct device *dev, struct 
device_attribute *attr,
return -EINVAL;
}
 
-   reg = (lm80_read_value(client, LM80_REG_FANDIV) &
-  ~(3 << (2 * (nr + 1 | (data->fan_div[nr] << (2 * (nr + 1)));
+   ret = lm80_read_value(client, LM80_REG_FANDIV);
+   if (ret < 0)
+   return ret;
+   reg = (ret & ~(3 << (2 * (nr + 1
+ | (data->fan_div[nr] << (2 * (nr + 1)));
lm80_write_value(client, LM80_REG_FANDIV, reg);
 
/* Restore fan_min */
-- 
2.17.2 (Apple Git-113)



Re: [PATCH 1/2] mm: vmscan: skip KSM page in direct reclaim if priority is low

2018-12-20 Thread Hugh Dickins
On Thu, 20 Dec 2018, Andrew Morton wrote:
> 
> Is anyone interested in reviewing this?  Seems somewhat serious. 
> Thanks.

Somewhat serious, but no need to rush.

> 
> From: Yang Shi 
> Subject: mm: vmscan: skip KSM page in direct reclaim if priority is low
> 
> When running a stress test, we occasionally run into the below hang issue:

Artificial load presumably.

> 
> INFO: task ksmd:205 blocked for more than 360 seconds.
>   Tainted: GE 
> 4.9.128-001.ali3000_nightly_20180925_264.alios7.x86_64 #1

4.9-stable does not contain Andrea's 4.13 commit 2c653d0ee2ae
("ksm: introduce ksm_max_page_sharing per page deduplication limit").

The patch below is more economical than Andrea's, but I don't think
a second workaround should be added, unless Andrea's is shown to be
insufficient, even with its ksm_max_page_sharing tuned down to suit.

Yang, please try to reproduce on upstream, or backport Andrea's to
4.9-stable - thanks.

Hugh

> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> ksmdD0   205  2 0x
>  882fa00418c0  882fa4b1 882fbf059d00
>  882fa5bc1800 c900190c7c28 81725e58 810777c0
>  00ffc900190c7c88 882fbf059d00 8138cc09 882fa4b1
> Call Trace:
>  [] ? __schedule+0x258/0x720
>  [] ? do_flush_tlb_all+0x30/0x30
>  [] ? free_cpumask_var+0x9/0x10
>  [] schedule+0x36/0x80
>  [] schedule_timeout+0x206/0x4b0
>  [] ? native_flush_tlb_others+0x11f/0x180
>  [] ? ktime_get+0x40/0xb0
>  [] io_schedule_timeout+0xda/0x170
>  [] ? bit_wait+0x60/0x60
>  [] bit_wait_io+0x1b/0x60
>  [] __wait_on_bit_lock+0x59/0xc0
>  [] __lock_page+0x86/0xa0
>  [] ? wake_atomic_t_function+0x60/0x60
>  [] ksm_scan_thread+0xeb9/0x1430
>  [] ? prepare_to_wait_event+0x100/0x100
>  [] ? try_to_merge_with_ksm_page+0x850/0x850
>  [] kthread+0xe6/0x100
>  [] ? kthread_park+0x60/0x60
>  [] ret_from_fork+0x46/0x60
> 
> ksmd found a suitable KSM page on the stable tree and is trying to lock
> it.  But it is locked by the direct reclaim path which is walking the
> page's rmap to get the number of referenced PTEs.
> 
> The KSM page rmap walk needs to iterate all rmap_items of the page and all
> rmap anon_vmas of each rmap_item.  So it may take (# rmap_item * #
> children processes) loops.  This number of loops might be very large in
> the worst case, and may take a long time.
> 
> Typically, direct reclaim will not intend to reclaim too many pages, and
> it is latency sensitive.  So it is not worth doing the long ksm page rmap
> walk to reclaim just one page.
> 
> Skip KSM pages in direct reclaim if the reclaim priority is low, but still
> try to reclaim KSM pages with high priority.
> 
> Link: 
> http://lkml.kernel.org/r/1541618201-120667-1-git-send-email-yang@linux.alibaba.com
> Signed-off-by: Yang Shi 
> Cc: Vlastimil Babka 
> Cc: Johannes Weiner 
> Cc: Hugh Dickins 
> Cc: Michal Hocko 
> Cc: Andrea Arcangeli 
> Signed-off-by: Andrew Morton 
> ---
> 
>  mm/vmscan.c |   23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> --- a/mm/vmscan.c~mm-vmscan-skip-ksm-page-in-direct-reclaim-if-priority-is-low
> +++ a/mm/vmscan.c
> @@ -1260,8 +1260,17 @@ static unsigned long shrink_page_list(st
>   }
>   }
>  
> - if (!force_reclaim)
> - references = page_check_references(page, sc);
> + if (!force_reclaim) {
> + /*
> +  * Don't try to reclaim KSM page in direct reclaim if
> +  * the priority is not high enough.
> +  */
> + if (PageKsm(page) && !current_is_kswapd() &&
> + sc->priority > (DEF_PRIORITY - 2))
> + references = PAGEREF_KEEP;
> + else
> + references = page_check_references(page, sc);
> + }
>  
>   switch (references) {
>   case PAGEREF_ACTIVATE:
> @@ -2136,6 +2145,16 @@ static void shrink_active_list(unsigned
>   }
>   }
>  
> + /*
> +  * Skip KSM page in direct reclaim if priority is not
> +  * high enough.
> +  */
> + if (PageKsm(page) && !current_is_kswapd() &&
> + sc->priority > (DEF_PRIORITY - 2)) {
> + putback_lru_page(page);
> + continue;
> + }
> +
>   if (page_referenced(page, 0, sc->target_mem_cgroup,
>   _flags)) {
>   nr_rotated += hpage_nr_pages(page);
> _


Re: [PATCH] cifs: check kzalloc return

2018-12-20 Thread Steve French
Updated the patch with Joe's signed off and Nicholas's reviewed-by and
pushed to cifs-2.6.git for-next

See attached.

On Wed, Dec 19, 2018 at 4:58 AM Joe Perches via samba-technical
 wrote:
>
> On Wed, 2018-12-19 at 08:22 +0100, Nicholas Mc Guire wrote:
> > On Tue, Dec 18, 2018 at 09:33:58AM -0800, Joe Perches wrote:
> > > On Tue, 2018-12-18 at 17:27 +0100, Nicholas Mc Guire wrote:
> > > > kzalloc can return NULL so a check is needed. While there is a
> > > > check for ret_buf there is no check for the allocation of
> > > > ret_buf->crfid.fid - this check is thus added. Both call-sites
> > > > of tconInfoAlloc() check for NULL return of tconInfoAlloc()
> > > > so returning NULL on failure of kzalloc() here seems appropriate.
> > > > As the kzalloc() is the only thing here that can fail it is
> > > > moved to the beginning so as not to initialize other resources
> > > > on failure of kzalloc.
> > > >
> > > Perhaps use a more common style by returning early on the
> > > first possible failure too so the block can be unindented.
> []
> > > yup the restructured cleanup would be the better way to go
> >
> > rather than making this two patches I guess it would be the
> > best to just skip the intermediate kzalloc only cleanup -
> > atleast I see little value in that intermediat step - so
> > could you take care of the kzalloc() in your refactoring
> > please ?
>
> I did that in the patch I proposed, which is trivial.
> If you want to take it, please do.
>
> If you want a sign-off:
>
> Signed-off-by: Joe Perches 
>
> > > diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
> []
> > > @@ -111,21 +111,27 @@ struct cifs_tcon *
> > >  tconInfoAlloc(void)
> > >  {
> > > struct cifs_tcon *ret_buf;
> > > -   ret_buf = kzalloc(sizeof(struct cifs_tcon), GFP_KERNEL);
> > > -   if (ret_buf) {
> > > -   atomic_inc();
> > > -   ret_buf->tidStatus = CifsNew;
> > > -   ++ret_buf->tc_count;
> > > -   INIT_LIST_HEAD(_buf->openFileList);
> > > -   INIT_LIST_HEAD(_buf->tcon_list);
> > > -   spin_lock_init(_buf->open_file_lock);
> > > -   mutex_init(_buf->crfid.fid_mutex);
> > > -   ret_buf->crfid.fid = kzalloc(sizeof(struct cifs_fid),
> > > -GFP_KERNEL);
> > > -   spin_lock_init(_buf->stat_lock);
> > > -   atomic_set(_buf->num_local_opens, 0);
> > > -   atomic_set(_buf->num_remote_opens, 0);
> > > +
> > > +   ret_buf = kzalloc(sizeof(*ret_buf), GFP_KERNEL);
> > > +   if (!ret_buf)
> > > +   return NULL;
> > > +   ret_buf->crfid.fid = kzalloc(sizeof(*ret_buf->crfid.fid), GFP_KERNEL);
> > > +   if (!ret_buf->crfid.fid) {
> > > +   kfree(ret_buf);
> > > +   return NULL;
> > > }
> > > +
> > > +   atomic_inc();
> > > +   ret_buf->tidStatus = CifsNew;
> > > +   ++ret_buf->tc_count;
> > > +   INIT_LIST_HEAD(_buf->openFileList);
> > > +   INIT_LIST_HEAD(_buf->tcon_list);
> > > +   spin_lock_init(_buf->open_file_lock);
> > > +   mutex_init(_buf->crfid.fid_mutex);
> > > +   spin_lock_init(_buf->stat_lock);
> > > +   atomic_set(_buf->num_local_opens, 0);
> > > +   atomic_set(_buf->num_remote_opens, 0);
> > > +
> > > return ret_buf;
> > >  }
> > >
>
>
>


-- 
Thanks,

Steve
From 687f983f49d80037bee0125f431f8e0243c7ab77 Mon Sep 17 00:00:00 2001
From: Joe Perches 
Date: Thu, 20 Dec 2018 23:50:48 -0600
Subject: [PATCH] cifs: check kzalloc return

kzalloc can return NULL so an additional check is needed. While there
is a check for ret_buf there is no check for the allocation of
ret_buf->crfid.fid - this check is thus added. Both call-sites
of tconInfoAlloc() check for NULL return of tconInfoAlloc()
so returning NULL on failure of kzalloc() here seems appropriate.
As the kzalloc() is the only thing here that can fail it is
moved to the beginning so as not to initialize other resources
on failure of kzalloc.

Fixes: 3d4ef9a15343 ("smb3: fix redundant opens on root")
---

Problem located with an experimental coccinelle script

While at it make checkpatch happy by using *ret_buf->crfid.fid
rather than struct cifs_fid.

Signed-off-by: Joe Perches 
Reported-by: Nicholas Mc Guire 
Reviewed-by: Nicholas Mc Guire 
---
 fs/cifs/misc.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/fs/cifs/misc.c b/fs/cifs/misc.c
index 113980dba4d8..bee203055b30 100644
--- a/fs/cifs/misc.c
+++ b/fs/cifs/misc.c
@@ -111,21 +111,27 @@ struct cifs_tcon *
 tconInfoAlloc(void)
 {
 	struct cifs_tcon *ret_buf;
-	ret_buf = kzalloc(sizeof(struct cifs_tcon), GFP_KERNEL);
-	if (ret_buf) {
-		atomic_inc();
-		ret_buf->tidStatus = CifsNew;
-		++ret_buf->tc_count;
-		INIT_LIST_HEAD(_buf->openFileList);
-		INIT_LIST_HEAD(_buf->tcon_list);
-		spin_lock_init(_buf->open_file_lock);
-		mutex_init(_buf->crfid.fid_mutex);
-		ret_buf->crfid.fid = kzalloc(sizeof(struct cifs_fid),
-	 GFP_KERNEL);
-		spin_lock_init(_buf->stat_lock);
-		atomic_set(_buf->num_local_opens, 0);
-		

linux-next: manual merge of the kvm tree with the powerpc tree

2018-12-20 Thread Stephen Rothwell
Hi all,

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

  arch/powerpc/mm/fault.c

between commit:

  49a502ea23bf ("powerpc/mm: Make NULL pointer deferences explicit on bad page 
faults.")

from the powerpc tree and commit:

  d7b456152230 ("KVM: PPC: Book3S HV: Implement functions to access quadrants 1 
& 2")

from the kvm tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc arch/powerpc/mm/fault.c
index c866d9a710fe,2e6fb1d758c3..
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@@ -650,9 -636,9 +650,10 @@@ void bad_page_fault(struct pt_regs *reg
switch (TRAP(regs)) {
case 0x300:
case 0x380:
+   case 0xe00:
 -  printk(KERN_ALERT "Unable to handle kernel paging request for "
 -  "data at address 0x%08lx\n", regs->dar);
 +  pr_alert("BUG: %s at 0x%08lx\n",
 +   regs->dar < PAGE_SIZE ? "Kernel NULL pointer 
dereference" :
 +   "Unable to handle kernel data access", regs->dar);
break;
case 0x400:
case 0x480:


pgprpCixtn09g.pgp
Description: OpenPGP digital signature


Re: [PATCH v1 2/3] dt-bindings: mailbox: Document armada-37xx-rwtm-mailbox binding

2018-12-20 Thread Baruch Siach
Hi Marek,

Marek Behun writes:
>> > +- compatible :must be "marvell,armada-37xx-rwtm-mailbox"  
>> 
>> Don't use wildcards in compatible strings.
>
> You mean that "mailbox" shouldn't be there?

You should use '3700' instead of '37xx'.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -


Re: [RFC PATCH v2 04/11] powerpc/mm: Add a framework for Kernel Userspace Access Protection

2018-12-20 Thread Michael Ellerman
Christophe Leroy  writes:

> This patch implements a framework for Kernel Userspace Access
> Protection.
>
> Then subarches will have to possibility to provide their own
> implementation by providing setup_kuap() and lock/unlock_user_access()
>
> Some platform will need to know the area accessed and whether it is
> accessed from read, write or both. Therefore source, destination and
> size and handed over to the two functions.
>
> Signed-off-by: Christophe Leroy 

I think some of this code came from Russell's original patch?

In which case we should have his signed-off-by here.

cheers


Re: [PATCH] gpu: anx7808: fix a missing check of return value

2018-12-20 Thread Laurent Pinchart
Hi Kangjie,

Thank you for the patch.

On Thursday, 20 December 2018 09:41:16 EET Kangjie Lu wrote:
> Both anx78xx_set_bits() and anx78xx_clear_bits() in the poweron process
> may fail. The fix inserts checks for their return values. If the poweron
> process fails, it calls anx78xx_poweroff().
> 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/gpu/drm/bridge/analogix-anx78xx.c | 26 ---
>  1 file changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c index
> f8433c93f463..a57104c71739 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -610,20 +610,20 @@ static int anx78xx_enable_interrupts(struct anx78xx
> *anx78xx) return 0;
>  }
> 
> -static void anx78xx_poweron(struct anx78xx *anx78xx)
> +static int anx78xx_poweron(struct anx78xx *anx78xx)
>  {
>   struct anx78xx_platform_data *pdata = >pdata;
> - int err;
> + int err = 0;
> 
>   if (WARN_ON(anx78xx->powered))
> - return;
> + return err;

You can return 0 here.

> 
>   if (pdata->dvdd10) {
>   err = regulator_enable(pdata->dvdd10);
>   if (err) {
>   DRM_ERROR("Failed to enable DVDD10 regulator: %d\n",
> err);
> - return;
> + return err;
>   }
> 
>   usleep_range(1000, 2000);
> @@ -638,12 +638,18 @@ static void anx78xx_poweron(struct anx78xx *anx78xx)
>   gpiod_set_value_cansleep(pdata->gpiod_reset, 0);
> 
>   /* Power on registers module */
> - anx78xx_set_bits(anx78xx->map[I2C_IDX_TX_P2], SP_POWERDOWN_CTRL_REG,
> + err = anx78xx_set_bits(anx78xx->map[I2C_IDX_TX_P2], 
> SP_POWERDOWN_CTRL_REG,
> SP_HDCP_PD | SP_AUDIO_PD | SP_VIDEO_PD | SP_LINK_PD);
> - anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P2], SP_POWERDOWN_CTRL_REG,
> + err |= anx78xx_clear_bits(anx78xx->map[I2C_IDX_TX_P2],
> SP_POWERDOWN_CTRL_REG, SP_REGISTER_PD | SP_TOTAL_PD);

If both functions fail with a different error code, this may result in a 
meaningless error being returned. One option is to do

err = anx78xx_set_bits(...);
if (!err)
err = anx78xx_clear_bits(...);

The construct gets quickly ugly though, so I sometimes define register 
accessors as taking an int * for the error code instead of returning it.

void write(..., int *status)
{
if (*status)
return;

*status = real_write(...);
}

and then use it as

int status = 0;

write(..., );
write(..., );
write(..., );
write(..., );
write(..., );

return status;

This may be overkill here.

> + if (err) {
> + anx78xx_poweroff(anx78xx);
> + return err;
> + }
> 
>   anx78xx->powered = true;
> +
> + return err;

And return 0 here too, removing the need to initialize the err variable to 0.

>  }
> 
>  static void anx78xx_poweroff(struct anx78xx *anx78xx)
> @@ -1144,7 +1150,9 @@ static irqreturn_t anx78xx_hpd_threaded_handler(int
> irq, void *data) mutex_lock(>lock);
> 
>   /* Cable is pulled, power on the chip */
> - anx78xx_poweron(anx78xx);
> + err = anx78xx_poweron(anx78xx);
> + if (err)
> + DRM_ERROR("Failed to power on the chip: %d\n", err);

Wouldn't it be better to move the error message to the an78xx_poweron() 
function ? That way it would also be printed in the probe() path.

>   err = anx78xx_enable_interrupts(anx78xx);
>   if (err)
> @@ -1379,7 +1387,9 @@ static int anx78xx_i2c_probe(struct i2c_client
> *client, }
> 
>   /* Look for supported chip ID */
> - anx78xx_poweron(anx78xx);
> + err = anx78xx_poweron(anx78xx);
> + if (err)
> + goto err_poweroff;

If poweron fails, doesn't it clean up after itself ? Do you need to call 
poweroff here ?

>   err = regmap_read(anx78xx->map[I2C_IDX_TX_P2], SP_DEVICE_IDL_REG,
> );

-- 
Regards,

Laurent Pinchart





[PATCH v2] media: si2165: fix a missing check of return value

2018-12-20 Thread Kangjie Lu
si2165_readreg8() may fail. Looking into si2165_readreg8(), we will find
that "val_tmp" will be an uninitialized value when regmap_read() fails.
"val_tmp" is then assigned to "val". So if si2165_readreg8() fails,
"val" will be a random value. Further use will lead to undefined
behaviors. The fix checks if si2165_readreg8() fails, and if so, returns
its error code upstream.

Signed-off-by: Kangjie Lu 
---
 drivers/media/dvb-frontends/si2165.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index feacd8da421d..d55d8f169dca 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -275,18 +275,20 @@ static u32 si2165_get_fe_clk(struct si2165_state *state)
 
 static int si2165_wait_init_done(struct si2165_state *state)
 {
-   int ret = -EINVAL;
+   int ret;
u8 val = 0;
int i;
 
for (i = 0; i < 3; ++i) {
-   si2165_readreg8(state, REG_INIT_DONE, );
+   ret = si2165_readreg8(state, REG_INIT_DONE, );
+   if (ret < 0)
+   return ret;
if (val == 0x01)
return 0;
usleep_range(1000, 5);
}
dev_err(>client->dev, "init_done was not set\n");
-   return ret;
+   return -EINVAL;
 }
 
 static int si2165_upload_firmware_block(struct si2165_state *state,
-- 
2.17.2 (Apple Git-113)



Re: [PATCH v4 13/18] memory: mtk-smi: Add bus_sel for mt8183

2018-12-20 Thread Nicolas Boichat
On Sat, Dec 8, 2018 at 4:43 PM Yong Wu  wrote:
>
> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> mmu0 or mmu1 to balance the bandwidth via the smi-common register
> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>
> In mt8183, For better performance, we switch larb1/2/5/7 to enter
> mmu1 while the others still keep enter mmu0.
>
> In mt8173 and mt2712, we don't get the performance issue,
> Keep its default value(0x0), that means all the larbs enter mmu0.
>
> Signed-off-by: Yong Wu 
> ---
>  drivers/memory/mtk-smi.c | 22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-smi.c
> index ee6165e..88eb61a 100644
> --- a/drivers/memory/mtk-smi.c
> +++ b/drivers/memory/mtk-smi.c
> @@ -49,6 +49,12 @@
>  #define SMI_LARB_NONSEC_CON(id)(0x380 + ((id) * 4))
>  #define F_MMU_EN   BIT(0)
>
> +/* SMI COMMON */
> +#define SMI_BUS_SEL0x220
> +#define SMI_BUS_LARB_SHIFT(larbid) ((larbid) << 1)
> +/* All are MMU0 defaultly. Only specialize mmu1 here. */
> +#define F_MMU1_LARB(larbid)(0x1 << SMI_BUS_LARB_SHIFT(larbid))
> +
>  enum mtk_smi_gen {
> MTK_SMI_GEN1,
> MTK_SMI_GEN2
> @@ -57,6 +63,7 @@ enum mtk_smi_gen {
>  struct mtk_smi_common_plat {
> enum mtk_smi_gen gen;
> bool has_gals;
> +   u32  bus_sel; /* Balance some larbs to enter mmu0 or mmu1 
> */
>  };
>
>  struct mtk_smi_larb_gen {
> @@ -72,8 +79,8 @@ struct mtk_smi {
> struct clk  *clk_apb, *clk_smi;
> struct clk  *clk_gals0, *clk_gals1;
> struct clk  *clk_async; /*only needed by mt2701*/
> -   void __iomem*smi_ao_base;
> -
> +   void __iomem*smi_ao_base; /* only for gen1 */
> +   void __iomem*base;/* only for gen2 */
> const struct mtk_smi_common_plat *plat;
>  };
>
> @@ -409,6 +416,8 @@ static int __maybe_unused mtk_smi_larb_suspend(struct 
> device *dev)
>  static const struct mtk_smi_common_plat mtk_smi_common_mt8183 = {
> .gen  = MTK_SMI_GEN2,
> .has_gals = true,
> +   .bus_sel  = F_MMU1_LARB(1) | F_MMU1_LARB(2) | F_MMU1_LARB(5) |
> +   F_MMU1_LARB(7),

Maybe it's ok for now, but I wonder if this is something that should
be specified in device tree? Maybe different applications will want
different larb split between MMU0 and MMU1?

>  };
>
>  static const struct of_device_id mtk_smi_common_of_ids[] = {
> @@ -481,6 +490,11 @@ static int mtk_smi_common_probe(struct platform_device 
> *pdev)
> ret = clk_prepare_enable(common->clk_async);
> if (ret)
> return ret;
> +   } else {
> +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +   common->base = devm_ioremap_resource(dev, res);
> +   if (IS_ERR(common->base))
> +   return PTR_ERR(common->base);
> }
> pm_runtime_enable(dev);
> platform_set_drvdata(pdev, common);
> @@ -496,6 +510,7 @@ static int mtk_smi_common_remove(struct platform_device 
> *pdev)
>  static int __maybe_unused mtk_smi_common_resume(struct device *dev)
>  {
> struct mtk_smi *common = dev_get_drvdata(dev);
> +   u32 bus_sel = common->plat->bus_sel;
> int ret;
>
> ret = mtk_smi_clk_enable(common);
> @@ -503,6 +518,9 @@ static int __maybe_unused mtk_smi_common_resume(struct 
> device *dev)
> dev_err(common->dev, "Failed to enable clock(%d).\n", ret);
> return ret;
> }
> +
> +   if (common->plat->gen == MTK_SMI_GEN2 && bus_sel)
> +   writel(bus_sel, common->base + SMI_BUS_SEL);
> return 0;
>  }
>
> --
> 1.9.1
>


Re: [PATCH v4 10/18] iommu/mediatek: Add mt8183 IOMMU support

2018-12-20 Thread Nicolas Boichat
On Sat, Dec 8, 2018 at 4:42 PM Yong Wu  wrote:
>
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main differences between mt8183 and mt8173/mt2712:
> 1) mt8183 has only one M4U HW like mt8173 while mt2712 has two.
> 2) mt8183 don't have the "bclk" clock, it use the EMI clock instead.
> 3) mt8183 can support the dram over 4GB, but it doesn't call this "4GB
> mode".
> 4) mt8183 pgtable base register(0x0) extend bit[1:0] which represent
> the bit[33:32] in the physical address of the pgtable base, But the
> standard ttbr0[1] means the S bit which is enabled defaultly, Hence,
> we add a mask.
> 5) mt8183 HW has a GALS modules, SMI should enable "has_gals" support.
> 6) the larb-id in smi-common is remapped. M4U should enable
> larbid_remapped support.
>
> Signed-off-by: Yong Wu 
> ---
>  drivers/iommu/mtk_iommu.c | 31 ++-
>  drivers/iommu/mtk_iommu.h |  1 +
>  drivers/memory/mtk-smi.c  | 19 +++
>  3 files changed, 42 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index 8ab3b69..d91a554 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -36,6 +36,7 @@
>  #include "mtk_iommu.h"
>
>  #define REG_MMU_PT_BASE_ADDR   0x000
> +#define MMU_PT_ADDR_MASK   GENMASK(31, 7)
>
>  #define REG_MMU_INVALIDATE 0x020
>  #define F_ALL_INVLD0x2
> @@ -54,7 +55,7 @@
>  #define REG_MMU_CTRL_REG   0x110
>  #define F_MMU_PREFETCH_RT_REPLACE_MOD  BIT(4)
>  #define F_MMU_TF_PROTECT_SEL_SHIFT(data) \
> -   ((data)->plat_data->m4u_plat == M4U_MT2712 ? 4 : 5)
> +   ((data)->plat_data->m4u_plat == M4U_MT8173 ? 5 : 4)

Should the shift value be a member of plat_data instead?

>  /* It's named by F_MMU_TF_PROT_SEL in mt2712. */
>  #define F_MMU_TF_PROTECT_SEL(prot, data) \
> (((prot) & 0x3) << F_MMU_TF_PROTECT_SEL_SHIFT(data))
> @@ -347,7 +348,7 @@ static int mtk_iommu_attach_device(struct iommu_domain 
> *domain,
> /* Update the pgtable base address register of the M4U HW */
> if (!data->m4u_dom) {
> data->m4u_dom = dom;
> -   writel(dom->cfg.arm_v7s_cfg.ttbr[0],
> +   writel(dom->cfg.arm_v7s_cfg.ttbr[0] & MMU_PT_ADDR_MASK,
>data->base + REG_MMU_PT_BASE_ADDR);
> }
>
> @@ -510,6 +511,7 @@ static int mtk_iommu_of_xlate(struct device *dev, struct 
> of_phandle_args *args)
>
>  static int mtk_iommu_hw_init(const struct mtk_iommu_data *data)
>  {
> +   enum mtk_iommu_plat m4u_plat = data->plat_data->m4u_plat;
> u32 regval;
> int ret;
>
> @@ -520,7 +522,7 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data 
> *data)
> }
>
> regval = F_MMU_TF_PROTECT_SEL(2, data);
> -   if (data->plat_data->m4u_plat == M4U_MT8173)
> +   if (m4u_plat == M4U_MT8173)
> regval |= F_MMU_PREFETCH_RT_REPLACE_MOD;
> writel_relaxed(regval, data->base + REG_MMU_CTRL_REG);
>
> @@ -541,14 +543,14 @@ static int mtk_iommu_hw_init(const struct 
> mtk_iommu_data *data)
> F_INT_PRETETCH_TRANSATION_FIFO_FAULT;
> writel_relaxed(regval, data->base + REG_MMU_INT_MAIN_CONTROL);
>
> -   if (data->plat_data->m4u_plat == M4U_MT8173)
> +   if (m4u_plat == M4U_MT8173)
> regval = (data->protect_base >> 1) | (data->enable_4GB << 31);
> else
> regval = lower_32_bits(data->protect_base) |
>  upper_32_bits(data->protect_base);
> writel_relaxed(regval, data->base + REG_MMU_IVRP_PADDR);
>
> -   if (data->enable_4GB && data->plat_data->m4u_plat != M4U_MT8173) {
> +   if (data->enable_4GB && m4u_plat == M4U_MT2712) {
> /*
>  * If 4GB mode is enabled, the validate PA range is from
>  * 0x1__ to 0x1__. here record bit[32:30].
> @@ -558,8 +560,11 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data 
> *data)
> }
> writel_relaxed(0, data->base + REG_MMU_DCM_DIS);
>
> -   /* It's MISC control register whose default value is ok except 
> mt8173.*/
> -   if (data->plat_data->m4u_plat == M4U_MT8173)
> +   /*
> +* It's MISC control register whose default value is ok
> +* except mt8173 and mt8183.
> +*/
> +   if (m4u_plat == M4U_MT8173 || m4u_plat == M4U_MT8183)

Again, should this be a field in plat_data?

> writel_relaxed(0, data->base + REG_MMU_STANDARD_AXI_MODE);
>
> if (devm_request_irq(data->dev, data->irq, mtk_iommu_isr, 0,
> @@ -713,6 +718,7 @@ static int __maybe_unused mtk_iommu_resume(struct device 
> *dev)
>  {
> struct mtk_iommu_data *data = dev_get_drvdata(dev);
> struct mtk_iommu_suspend_reg 

[ANNOUNCE] 4.9.146-rt125

2018-12-20 Thread Julia Cartwright
Hello RT Folks!

I'm pleased to announce the 4.9.146-rt125 stable release.

Apologies for an update to the 4.9-rt tree being way overdue.

This release is just an update to the new stable 4.9.146 version
and no RT specific changes have been made.

You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v4.9-rt
  Head SHA1: 5b5e350d8c82f5dcbad136aeede6b73d41cd1e8a

Or to build 4.9.146-rt125 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v4.x/linux-4.9.tar.xz

  http://www.kernel.org/pub/linux/kernel/v4.x/patch-4.9.146.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/4.9/patch-4.9.146-rt125.patch.xz

Enjoy, and happy holidays,
Julia



[v6] PCI: imx: make msi work without CONFIG_PCIEPORTBUS=y

2018-12-20 Thread Richard Zhu
The MSI Enable bit in the MSI Capability (PCIe r4.0, sec 7.7.1.2)
controls whether a Function can request service using MSI.

i.MX6 Root Ports implement the MSI Capability and may use MSI to
request service for events like PME, hotplug, AER, etc.  In
addition, on i.MX6, the MSI Enable bit controls delivery of MSI
interrupts from components below the Root Port.

Prior to commit f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection
of CONFIG_PCIEPORTBUS"), enabling CONFIG_PCI_IMX6 automatically also
enabled CONFIG_PCIEPORTBUS, and when portdrv claimed the Root Ports,
it set the MSI Enable bit so it could use PME, hotplug, AER, etc.
As a side effect, that also enabled delivery of MSI interrupts from
downstream components.

After f3fdfc4ac3a2, the imx6q-pcie driver can operate without
portdrv, but that means imx6q-pcie must set the MSI Enable bit
itself if downstream components use MSI.

Fixes: f3fdfc4ac3a2 ("PCI: Remove host driver Kconfig selection of 
CONFIG_PCIEPORTBUS")

Signed-off-by: Richard Zhu 
Reviewed-by: Lucas Stach 
Tested-by: Sven Van Asbroeck 
Acked-by: Lorenzo Pieralisi 
---
Changes v1 -> v2:
* Assert the MSI_EN unconditionally when MSI is supported.
Changes v2 -> v3:
* Remove the IS_ENABLED(CONFIG_PCI_MSI) since the driver depends on
PCI_MSI_IRQ_DOMAIN
* Extended with a check for pci_msi_enabled() to see if the user
explicitly want legacy IRQs
Changes v3 -> v4:
* Refer to Bjorn's comments, refine the subject and commit log and change
the PCI_MSI_CAP to PCIE_RC_IMX6_MSI_CAP.
Changes v4 -> v5:
* Correct one spell mistake from PCIE_RC_MSI_IMX6_CAP to
PCIE_RC_IMX6_MSI_CAP.
Changes v5 -> v6:
* Update with Bjorn's commit.
* One "commit" added in "Prior to f3fdfc4ac3a2" refer to the complain of
checkpatch.pl.
---
 drivers/pci/controller/dwc/pci-imx6.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/pci/controller/dwc/pci-imx6.c 
b/drivers/pci/controller/dwc/pci-imx6.c
index e563ca9..73542dd 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -82,6 +82,7 @@ struct imx6_pcie {
 #define PHY_PLL_LOCK_WAIT_USLEEP_MAX   200
 
 /* PCIe Root Complex registers (memory-mapped) */
+#define PCIE_RC_IMX6_MSI_CAP   0x50
 #define PCIE_RC_LCR0x7c
 #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN1   0x1
 #define PCIE_RC_LCR_MAX_LINK_SPEEDS_GEN2   0x2
@@ -999,6 +1000,7 @@ static int imx6_pcie_probe(struct platform_device *pdev)
struct resource *dbi_base;
struct device_node *node = dev->of_node;
int ret;
+   u16 val;
 
imx6_pcie = devm_kzalloc(dev, sizeof(*imx6_pcie), GFP_KERNEL);
if (!imx6_pcie)
@@ -1149,6 +1151,14 @@ static int imx6_pcie_probe(struct platform_device *pdev)
if (ret < 0)
return ret;
 
+   if (pci_msi_enabled()) {
+   val = dw_pcie_readw_dbi(pci, PCIE_RC_IMX6_MSI_CAP +
+   PCI_MSI_FLAGS);
+   val |= PCI_MSI_FLAGS_ENABLE;
+   dw_pcie_writew_dbi(pci, PCIE_RC_IMX6_MSI_CAP +
+   PCI_MSI_FLAGS, val);
+   }
+
return 0;
 }
 
-- 
2.7.4



RE: [PATCH 1/2] Documentation: can: flexcan: add PE clock source property to device tree

2018-12-20 Thread Joakim Zhang

> -Original Message-
> From: Rob Herring 
> Sent: 2018年12月21日 4:23
> To: Joakim Zhang 
> Cc: m...@pengutronix.de; linux-...@vger.kernel.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; dl-linux-imx
> ; Aisheng Dong 
> Subject: Re: [PATCH 1/2] Documentation: can: flexcan: add PE clock source
> property to device tree
> 
> On Thu, Dec 13, 2018 at 07:07:57AM +, Joakim Zhang wrote:
> > From: Dong Aisheng 
> >
> > The FlexCAN controller can parse clock source property from DTS file
> > to select PE clock source.
> >
> > Signed-off-by: Dong Aisheng 
> > Signed-off-by: Joakim Zhang 
> > ---
> >  Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 8
> > 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > index bc77477c6878..a04168605998 100644
> > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > @@ -32,6 +32,13 @@ Optional properties:
> >  ack_gpr is the gpr register offset of CAN stop acknowledge.
> >  ack_bit is the bit offset of CAN stop acknowledge.
> >
> > +- fsl,clk-source: Select the clock source to the CAN Protocol Engine (PE).
> > + It's SoC Implementation dependent. Refer to RM for detailed
> 
> If SoC dependent, then it should be implied by the SoC specific compatible.
> Also, seems like you should add clock binding support here if you need more
> clock control.

Hi,

My expression here might not be very accurate, this property just help to 
select the clock source for
Protocol Engine (PE). FlexCAN ip support two PE clock sources, so we have to 
add this property to
let driver know that SoC has selected which one.

Best Regards,
Joakim Zhang

> > + definition. If this property is not set in device tree node
> > + then driver selects clock source 1 by default.
> > + 0: clock source 0 (oscillator clock)
> > + 1: clock source 1 (peripheral clock)
> > +
> >  Example:
> >
> > can@1c000 {
> > @@ -40,4 +47,5 @@ Example:
> > interrupts = <48 0x2>;
> > interrupt-parent = <>;
> > clock-frequency = <2>; // filled in by bootloader
> > +   fsl,clk-source = <0>; // select clock source 0 for PE
> > };
> > --
> > 2.17.1
> >


Re: [PATCH] serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250

2018-12-20 Thread Florian Fainelli
Le 12/20/18 à 9:38 AM, Guenter Roeck a écrit :
> On Thu, Dec 20, 2018 at 04:21:11PM +0100, Greg Kroah-Hartman wrote:
>> On Wed, Nov 14, 2018 at 05:11:25PM -0800, Guenter Roeck wrote:
>>> On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote:
>>>> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would
>>>> result in the inability for the kernel to have a valid console device,
>>>> which can be seen with:
>>>>
>>>> Warning: unable to open an initial console.
>>>>
>>>> and then:
>>>>
>>>> Run /init as init process
>>>> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0100
>>>>
>>>> Since SERIAL_OF_PLATFORM already depends on SERIAL_8250 && OF there
>>>> really is no drawback to defaulting this config to the value of
>>>> SERIAL_8250.
>>>>
>>>> Signed-off-by: Florian Fainelli 
>>>> Signed-off-by: Greg Kroah-Hartman 
>>>
>>> This patch results in situations where CONFIG_SERIAL_OF_PLATFORM is now
>>> defined where it was not previously. Example mpc85xx_defconfig. This in
>>> turn results in boot failures for those configurations, with an error
>>> message of
>>>
>>> of_serial: probe of e0004500.serial failed with error -22
>>>
>>> which wasn't seen before.
>>>
>>> Not sure if replacing a potential problem with a real one is really an
>>> improvement.`
>>
>> What ever was the result of this long thread?  Should I revert
>> something?  Or was a patch proposed?
>>
> The problem still exists in next-20181220.

I submitted a tentative patch to fix the problem, discussed it with
Michael and he had an alternative patch to 8250_core.c that should work
equally well though I was worried more breakage could be created that
way. Since clearly we have not been able to make much progress, maybe a
reversion of the original patch is appropriate, yes it's now sent a as a
reply to this mail! 

> 
> Unfortunately this is now just one failure of many in -next. I see more
> than 90 boot failures (out of ~330) there, not counting the build failures.
> And that is on a good day.
> 
> Guenter
> 


-- 
Florian


[PATCH] Revert "serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250"

2018-12-20 Thread Florian Fainelli
This reverts commit 6d11023c345e369bcb9d5a68b271764e362c1f6e ("serial:
8250: Default SERIAL_OF_PLATFORM to SERIAL_8250") since that breaks at
least mpc8544ds (PowerPC) using arch/powerpc/kernel/legacy_serial.c.

See https://lkml.org/lkml/2018/12/5/1491 for discussion and analysis

Fixes: 6d11023c345e ("serial: 8250: Default SERIAL_OF_PLATFORM to SERIAL_8250")
Signed-off-by: Florian Fainelli 
---
 drivers/tty/serial/8250/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index d7737dca0e48..15c2c5463835 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -484,7 +484,6 @@ config SERIAL_8250_PXA
 config SERIAL_OF_PLATFORM
tristate "Devicetree based probing for 8250 ports"
depends on SERIAL_8250 && OF
-   default SERIAL_8250
help
  This option is used for all 8250 compatible serial ports that
  are probed through devicetree, including Open Firmware based
-- 
2.19.1



Re: [PATCH] drm: add capability DRM_CAP_ASYNC_UPDATE

2018-12-20 Thread Tomasz Figa
On Thu, Dec 20, 2018 at 7:47 PM Daniel Vetter  wrote:
>
> On Thu, Dec 20, 2018 at 10:07 AM Tomasz Figa  wrote:
> >
> > Hi Helen,
> >
> > On Fri, Dec 14, 2018 at 10:35 AM Helen Koike  
> > wrote:
> > >
> > > Hi Tomasz,
> > >
> > > On 12/13/18 2:02 AM, Tomasz Figa wrote:
> > > > On Thu, Dec 6, 2018 at 1:12 AM Helen Koike  
> > > > wrote:
> > > >>
> > > >> Hi Ville
> > > >>
> > > >> On 11/27/18 11:34 AM, Ville Syrjälä wrote:
> > > >>> On Fri, Nov 23, 2018 at 07:53:26PM -0200, Helen Koike wrote:
> > >  Allow userspace to identify if the driver supports async update.
> > > >>>
> > > >>> And what exactly is an "async update"?
> > > >>
> > > >> I agree we are lacking docs on this, I'll send in the next version as
> > > >> soon as we agree on a name (please see below).
> > > >>
> > > >> For reference:
> > > >> https://lists.freedesktop.org/archives/dri-devel/2017-April/138586.html
> > > >>
> > > >>>
> > > >>> I keep asking people to come up with the a better name for this, and 
> > > >>> to
> > > >>> document what it actually means. Recently I've been think we should
> > > >>> maybe just adopt the vulkan terminology (immediate/fifo/mailbox) to
> > > >>> avoid introducing yet another set of names for the same thing. We'd
> > > >>> still want to document things properly though.
> > > >>
> > > >> Another name it was suggested was "atomic amend", this feature 
> > > >> basically
> > > >> allows userspace to complement an update previously sent (i.e. its in
> > > >> the queue and wasn't commited yet), it allows adding a plane update to
> > > >> the next commit. So what do you think in renaming it to "atomic amend"?
> > > >
> > > > Note that it doesn't seem to be what the code currently is doing. For
> > > > example, for cursor updates, it doesn't seem to be working on the
> > > > currently pending commit, but just directly issues an atomic async
> > > > update call to the planes. The code actually seems to fall back to a
> > > > normal sync commit, if there is an already pending commit touching the
> > > > same plane or including a modeset.
> > >
> > > It should fail as discussed at:
> > > https://patchwork.freedesktop.org/patch/243088/
> > >
> > > There was the following code inside the drm_atomic_helper_async_check()
> > > in the previous patch which would fallback to a normal commit if there
> > > isn't any pending commit to amend:
> > >
> > > +   if (!old_plane_state->commit)
> > > +   return -EINVAL;
> > >
> > > In the v2 of the patch https://patchwork.freedesktop.org/patch/263712/
> > > this got removed, but which means that async update will be enabled
> > > anyway. So the following code is wrong:
> > >
> > > -   if (state->legacy_cursor_update)
> > > +   if (state->async_update || state->legacy_cursor_update)
> > > state->async_update = !drm_atomic_helper_async_check(dev, 
> > > state);
> > >
> > > Does it make sense? If yes I'll fix this in the next version of the
> > > Atomic IOCTL patch (and also those two patches should be in the same
> > > series, I'll send them together next time).
> > >
> > > Thanks for pointing this out.
> > >
> > > Please let me know if you still don't agree on the name "atomic amend",
> > > or if I am missing something.
> >
> > I'll defer it to the DRM maintainers. From Chrome OS perspective, we
> > need a way to commit the cursor plane asynchronously from other
> > commits any time the cursor changes its position or framebuffer. As
> > long as the new API allows that and the maintainers are fine with it,
> > I think I should be okay with it too.
>
> If this is just about the cursor, why is the current legacy cursor
> ioctl not good enough? It's 2 ioctls instead of one, but I'm not sure
> if we want to support having a normal atomic commit and a cursor
> update in the same atomic ioctl, coming up with reasonable semantics
> for that will be complicated.
>
> Pointer to code that uses this would be better ofc.

Sorry, let me clarify that I was mostly referring to the respective
kernel functionality here, not the userspace extension.

As far as I know, Chromium still uses the legacy cursor ioctls and we
have our drivers implement them directly, bypassing the atomic commit
mechanism. However, it sounds like this async commit could let us
remove the custom implementations from the drivers and have a common
helper for it, which would be a good step forward.

Daniel, Daniele, Sean, Stephane, could you clarify what are our needs
for this userspace interface?

> -Daniel
>
> > Best regards,
> > Tomasz
> >
> > >
> > > Helen
> > >
> > > >
> > > > Best regards,
> > > > Tomasz
> > > >
> > > >> Or do you suggest another name? I am not familiar with vulkan 
> > > >> terminology.
> > > >>
> > > >>
> > > >> Thanks
> > > >> Helen
> > > >>
> > > >>>
> > > 
> > >  Signed-off-by: Enric Balletbo i Serra 
> > >  [prepared for upstream]
> > >  Signed-off-by: Helen Koike 
> > > 
> > >  ---
> > >  Hi,
> > > 
> > >  This patch 

[PATCH v3 0/2] perf tests: Check for ARM [vectors] page

2018-12-20 Thread Florian Fainelli
Hi all,

I just painfully learned that perf would segfault when
CONFIG_KUSER_HELPERS is disabled because it unconditionally makes use of
it. This patch series adds an ARM test for that by leveraging the
existing find_vdso_map() function and making it more generic and capable
of location any map within /proc/self/maps.

Changes in v3:

- remove find_vdso_map() call find_map() with VDSO__MAP_NAME

Changes in v2:

- use strlen() instead of sizeof() -1 since we made the page name a
  parameter
- use TEST_OK/TEST_FAIL in lieu of 0/-1
- added an error message indicating CONFIG_KUSER_HELPERS might be
  disabled

Florian Fainelli (2):
  perf tools: Make find_vdso_map() more modular
  perf tests: Add a test for the ARM 32-bit [vectors] page

 tools/perf/Makefile.perf  |  4 ++--
 tools/perf/arch/arm/tests/Build   |  1 +
 tools/perf/arch/arm/tests/arch-tests.c|  4 
 tools/perf/arch/arm/tests/vectors-page.c  | 24 +++
 tools/perf/perf-read-vdso.c   |  6 ++---
 tools/perf/tests/tests.h  |  5 
 .../perf/util/{find-vdso-map.c => find-map.c} |  7 +++---
 tools/perf/util/vdso.c|  6 ++---
 8 files changed, 45 insertions(+), 12 deletions(-)
 create mode 100644 tools/perf/arch/arm/tests/vectors-page.c
 rename tools/perf/util/{find-vdso-map.c => find-map.c} (71%)

-- 
2.17.1



[PATCH v3 1/2] perf tools: Make find_vdso_map() more modular

2018-12-20 Thread Florian Fainelli
In preparation for checking that the vectors page on the ARM
architecture, refactor the find_vdso_map() function to accept finding an
arbitrary string and create a dedicated helper function for that under
util/find-map.c and update the filename to find-map.c and all references
to it: perf-read-vdso.c and util/vdso.c.

Signed-off-by: Florian Fainelli 
---
 tools/perf/Makefile.perf| 4 ++--
 tools/perf/perf-read-vdso.c | 6 +++---
 tools/perf/util/{find-vdso-map.c => find-map.c} | 7 +++
 tools/perf/util/vdso.c  | 6 +++---
 4 files changed, 11 insertions(+), 12 deletions(-)
 rename tools/perf/util/{find-vdso-map.c => find-map.c} (71%)

diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index d95655489f7e..04e70a664adb 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -623,12 +623,12 @@ $(OUTPUT)perf-%: %.o $(PERFLIBS)
$(QUIET_LINK)$(CC) $(CFLAGS) -o $@ $(LDFLAGS) $(filter %.o,$^) $(LIBS)
 
 ifndef NO_PERF_READ_VDSO32
-$(OUTPUT)perf-read-vdso32: perf-read-vdso.c util/find-vdso-map.c
+$(OUTPUT)perf-read-vdso32: perf-read-vdso.c util/find-map.c
$(QUIET_CC)$(CC) -m32 $(filter -static,$(LDFLAGS)) -Wall -Werror -o $@ 
perf-read-vdso.c
 endif
 
 ifndef NO_PERF_READ_VDSOX32
-$(OUTPUT)perf-read-vdsox32: perf-read-vdso.c util/find-vdso-map.c
+$(OUTPUT)perf-read-vdsox32: perf-read-vdso.c util/find-map.c
$(QUIET_CC)$(CC) -mx32 $(filter -static,$(LDFLAGS)) -Wall -Werror -o $@ 
perf-read-vdso.c
 endif
 
diff --git a/tools/perf/perf-read-vdso.c b/tools/perf/perf-read-vdso.c
index 8c0ca0cc428f..aaa5210ea84a 100644
--- a/tools/perf/perf-read-vdso.c
+++ b/tools/perf/perf-read-vdso.c
@@ -5,17 +5,17 @@
 #define VDSO__MAP_NAME "[vdso]"
 
 /*
- * Include definition of find_vdso_map() also used in util/vdso.c for
+ * Include definition of find_map() also used in util/vdso.c for
  * building perf.
  */
-#include "util/find-vdso-map.c"
+#include "util/find-map.c"
 
 int main(void)
 {
void *start, *end;
size_t size, written;
 
-   if (find_vdso_map(, ))
+   if (find_map(, , VDSO__MAP_NAME))
return 1;
 
size = end - start;
diff --git a/tools/perf/util/find-vdso-map.c b/tools/perf/util/find-map.c
similarity index 71%
rename from tools/perf/util/find-vdso-map.c
rename to tools/perf/util/find-map.c
index d7823e3508fc..7b2300588ece 100644
--- a/tools/perf/util/find-vdso-map.c
+++ b/tools/perf/util/find-map.c
@@ -1,5 +1,5 @@
 // SPDX-License-Identifier: GPL-2.0
-static int find_vdso_map(void **start, void **end)
+static int find_map(void **start, void **end, const char *name)
 {
FILE *maps;
char line[128];
@@ -7,7 +7,7 @@ static int find_vdso_map(void **start, void **end)
 
maps = fopen("/proc/self/maps", "r");
if (!maps) {
-   fprintf(stderr, "vdso: cannot open maps\n");
+   fprintf(stderr, "cannot open maps\n");
return -1;
}
 
@@ -21,8 +21,7 @@ static int find_vdso_map(void **start, void **end)
if (m < 0)
continue;
 
-   if (!strncmp([m], VDSO__MAP_NAME,
-sizeof(VDSO__MAP_NAME) - 1))
+   if (!strncmp([m], name, strlen(name)))
found = 1;
}
 
diff --git a/tools/perf/util/vdso.c b/tools/perf/util/vdso.c
index 741af209b19d..3702cba11d7d 100644
--- a/tools/perf/util/vdso.c
+++ b/tools/perf/util/vdso.c
@@ -18,10 +18,10 @@
 #include "debug.h"
 
 /*
- * Include definition of find_vdso_map() also used in perf-read-vdso.c for
+ * Include definition of find_map() also used in perf-read-vdso.c for
  * building perf-read-vdso32 and perf-read-vdsox32.
  */
-#include "find-vdso-map.c"
+#include "find-map.c"
 
 #define VDSO__TEMP_FILE_NAME "/tmp/perf-vdso.so-XX"
 
@@ -76,7 +76,7 @@ static char *get_file(struct vdso_file *vdso_file)
if (vdso_file->found)
return vdso_file->temp_file_name;
 
-   if (vdso_file->error || find_vdso_map(, ))
+   if (vdso_file->error || find_map(, , VDSO__MAP_NAME))
return NULL;
 
size = end - start;
-- 
2.17.1



[PATCH v3 2/2] perf tests: Add a test for the ARM 32-bit [vectors] page

2018-12-20 Thread Florian Fainelli
perf on ARM requires CONFIG_KUSER_HELPERS to be turned on to allow some
independance with respect to the ARM CPU being used. Add a test which
tries to locate the [vectors] page, created when CONFIG_KUSER_HELPERS is
turned on to help asses the system's health.

Signed-off-by: Florian Fainelli 
---
 tools/perf/arch/arm/tests/Build  |  1 +
 tools/perf/arch/arm/tests/arch-tests.c   |  4 
 tools/perf/arch/arm/tests/vectors-page.c | 24 
 tools/perf/tests/tests.h |  5 +
 4 files changed, 34 insertions(+)
 create mode 100644 tools/perf/arch/arm/tests/vectors-page.c

diff --git a/tools/perf/arch/arm/tests/Build b/tools/perf/arch/arm/tests/Build
index 883c57ff0c08..d9ae2733f9cc 100644
--- a/tools/perf/arch/arm/tests/Build
+++ b/tools/perf/arch/arm/tests/Build
@@ -1,4 +1,5 @@
 libperf-y += regs_load.o
 libperf-y += dwarf-unwind.o
+libperf-y += vectors-page.o
 
 libperf-y += arch-tests.o
diff --git a/tools/perf/arch/arm/tests/arch-tests.c 
b/tools/perf/arch/arm/tests/arch-tests.c
index 5b1543c98022..6848101a855f 100644
--- a/tools/perf/arch/arm/tests/arch-tests.c
+++ b/tools/perf/arch/arm/tests/arch-tests.c
@@ -10,6 +10,10 @@ struct test arch_tests[] = {
.func = test__dwarf_unwind,
},
 #endif
+   {
+   .desc = "Vectors page",
+   .func = test__vectors_page,
+   },
{
.func = NULL,
},
diff --git a/tools/perf/arch/arm/tests/vectors-page.c 
b/tools/perf/arch/arm/tests/vectors-page.c
new file mode 100644
index ..7ffdd79971c8
--- /dev/null
+++ b/tools/perf/arch/arm/tests/vectors-page.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "tests/tests.h"
+#include "util/find-map.c"
+
+#define VECTORS__MAP_NAME "[vectors]"
+
+int test__vectors_page(struct test *test __maybe_unused,
+  int subtest __maybe_unused)
+{
+   void *start, *end;
+
+   if (find_map(, , VECTORS__MAP_NAME)) {
+   pr_err("%s not found, is CONFIG_KUSER_HELPERS enabled?\n",
+  VECTORS__MAP_NAME);
+   return TEST_FAIL;
+   }
+
+   return TEST_OK;
+}
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index b82f55fcc294..399f18ca71a3 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -119,4 +119,9 @@ int test__arch_unwind_sample(struct perf_sample *sample,
 struct thread *thread);
 #endif
 #endif
+
+#if defined(__arm__)
+int test__vectors_page(struct test *test, int subtest);
+#endif
+
 #endif /* TESTS_H */
-- 
2.17.1



[PATCH] panel-innolux: set display off in innolux_panel_unprepare

2018-12-20 Thread Hsin-Yi, Wang
Move mipi_dsi_dcs_set_display_off() from innolux_panel_disable()
to innolux_panel_unprepare(), so they are consistent with
innolux_panel_enable() and innolux_panel_prepare().

This also fixes some mode check and irq timeout issue in MTK dsi code.

Since some dsi code (e.g. mtk_dsi) have following call trace:
1. drm_panel_disable(), which calls innolux_panel_disable()
2. switch to cmd mode
3. drm_panel_unprepare(), which calls innolux_panel_unprepare()

However, mtk_dsi needs to be in cmd mode to be able to send commands
(e.g. mipi_dsi_dcs_set_display_off() and mipi_dsi_dcs_enter_sleep_mode()),
so we need these functions to be called after the switch to cmd mode happens,
i.e. in innolux_panel_unprepare.


Signed-off-by: Hsin-Yi, Wang 
---
 drivers/gpu/drm/panel/panel-innolux-p079zca.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index ca4ae45dd307..8e5724b63f1f 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -70,18 +70,12 @@ static inline struct innolux_panel *to_innolux_panel(struct 
drm_panel *panel)
 static int innolux_panel_disable(struct drm_panel *panel)
 {
struct innolux_panel *innolux = to_innolux_panel(panel);
-   int err;
 
if (!innolux->enabled)
return 0;
 
backlight_disable(innolux->backlight);
 
-   err = mipi_dsi_dcs_set_display_off(innolux->link);
-   if (err < 0)
-   DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
- err);
-
innolux->enabled = false;
 
return 0;
@@ -95,6 +89,11 @@ static int innolux_panel_unprepare(struct drm_panel *panel)
if (!innolux->prepared)
return 0;
 
+   err = mipi_dsi_dcs_set_display_off(innolux->link);
+   if (err < 0)
+   DRM_DEV_ERROR(panel->dev, "failed to set display off: %d\n",
+ err);
+
err = mipi_dsi_dcs_enter_sleep_mode(innolux->link);
if (err < 0) {
DRM_DEV_ERROR(panel->dev, "failed to enter sleep mode: %d\n",
-- 
2.18.1



Re: [PATCH v4 08/18] iommu/mediatek: Add larb-id remapped support

2018-12-20 Thread Nicolas Boichat
On Sat, Dec 8, 2018 at 4:42 PM Yong Wu  wrote:
>
> The larb-id may be remapped in the smi-common, this means the
> larb-id reported in the mtk_iommu_isr isn't the real larb-id,
>
> Take mt8183 as a example:
>M4U
> |
> -
> |   SMI common  |
> -0-7-5-6-1-2--3-4- <- Id remapped
>  | | | | | |  | |
> larb0 larb1 IPU0  IPU1 larb4 larb5  larb6  CCU
> disp  vdec  img   cam   venc  imgcam
> As above, larb0 connects with the id 0 in smi-common.
>   larb1 connects with the id 7 in smi-common.
>   ...
> If the larb-id reported in the isr is 7, actually it's larb1(vdec).
> In order to output the right larb-id in the isr, we add a larb-id
> remapping relationship in this patch.
>
> This also is a preparing patch for mt8183.
>
> Signed-off-by: Yong Wu 
> ---
>  drivers/iommu/mtk_iommu.c | 3 +++
>  drivers/iommu/mtk_iommu.h | 4 
>  2 files changed, 7 insertions(+)
>
> diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
> index eda062a..8ab3b69 100644
> --- a/drivers/iommu/mtk_iommu.c
> +++ b/drivers/iommu/mtk_iommu.c
> @@ -220,6 +220,9 @@ static irqreturn_t mtk_iommu_isr(int irq, void *dev_id)
> fault_larb = F_MMU0_INT_ID_LARB_ID(regval);
> fault_port = F_MMU0_INT_ID_PORT_ID(regval);
>
> +   if (data->plat_data->larbid_remap_enable)
> +   fault_larb = data->plat_data->larbid_remapped[fault_larb];
> +
> if (report_iommu_fault(>domain, data->dev, fault_iova,
>write ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ)) 
> {
> dev_err_ratelimited(
> diff --git a/drivers/iommu/mtk_iommu.h b/drivers/iommu/mtk_iommu.h
> index b8749ac..3877050 100644
> --- a/drivers/iommu/mtk_iommu.h
> +++ b/drivers/iommu/mtk_iommu.h
> @@ -47,6 +47,10 @@ struct mtk_iommu_plat_data {
>
> /* HW will use the EMI clock if there isn't the "bclk". */
> boolhas_bclk;
> +
> +   /* The larb-id may be remapped in the smi-common. */
> +   boollarbid_remap_enable;
> +   unsigned intlarbid_remapped[MTK_LARB_NR_MAX];

Wouldn't it be a little simpler if you just had
larbid_remap[MTK_LARB_NR_MAX] (no larbid_remap_enable), and just set
it to {0, 1, 2, 3, 4, 5, 6, 7} in platforms that don't need
complicated remapping?

Also, unsigned char/u8 array would be enough.

>  };
>
>  struct mtk_iommu_domain;
> --
> 1.9.1
>


RE: [PATCH 1/2] Documentation: can: flexcan: add PE clock source property to device tree

2018-12-20 Thread Aisheng Dong
> -Original Message-
> From: Rob Herring [mailto:r...@kernel.org]
> Sent: Friday, December 21, 2018 4:23 AM
> 
> On Thu, Dec 13, 2018 at 07:07:57AM +, Joakim Zhang wrote:
> > From: Dong Aisheng 
> >
> > The FlexCAN controller can parse clock source property from DTS file
> > to select PE clock source.
> >
> > Signed-off-by: Dong Aisheng 
> > Signed-off-by: Joakim Zhang 
> > ---
> >  Documentation/devicetree/bindings/net/can/fsl-flexcan.txt | 8
> > 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > index bc77477c6878..a04168605998 100644
> > --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
> > @@ -32,6 +32,13 @@ Optional properties:
> >  ack_gpr is the gpr register offset of CAN stop acknowledge.
> >  ack_bit is the bit offset of CAN stop acknowledge.
> >
> > +- fsl,clk-source: Select the clock source to the CAN Protocol Engine (PE).
> > + It's SoC Implementation dependent. Refer to RM for detailed
> 
> If SoC dependent, then it should be implied by the SoC specific compatible.
> Also, seems like you should add clock binding support here if you need more
> clock control.

The clock source selection is done by a register bit inside the IP block:
BIT13 CLKSRC CAN Engine Clock Source
0b - The CAN engine clock source is the oscillator clock. 
1b - The CAN engine clock source is the peripheral clock.

Currently it's written 1 by default during driver initialization.
drivers/net/can/flexcan.c
/* select "bus clock", chip must be disabled */
reg = priv->read(>ctrl);
reg |= FLEXCAN_CTRL_CLK_SRC;
priv->write(reg, >ctrl);

I'm not sure if it's a typical case to abstract CLKSRC bit into a common clock 
mux.
(Is there any similar case in kernel?)
But I think we can also use SoC specific compatible to write 0 for those special
Ones (currently only imx8qxp). Then this patch may not be needed.

Marc,
Please let us know if you have a different idea.

Regards
Dong Aisheng

> 
> > + definition. If this property is not set in device tree node
> > + then driver selects clock source 1 by default.
> > + 0: clock source 0 (oscillator clock)
> > + 1: clock source 1 (peripheral clock)
> > +
> >  Example:
> >
> > can@1c000 {
> > @@ -40,4 +47,5 @@ Example:
> > interrupts = <48 0x2>;
> > interrupt-parent = <>;
> > clock-frequency = <2>; // filled in by bootloader
> > +   fsl,clk-source = <0>; // select clock source 0 for PE
> > };
> > --
> > 2.17.1
> >


  1   2   3   4   5   6   7   8   9   10   >