[PATCH] platform/chrome: cros_ec_trace: update generating script

2019-07-23 Thread Tzung-Bi Shih
To remove ", \" from the last line.

Signed-off-by: Tzung-Bi Shih 
---
 drivers/platform/chrome/cros_ec_trace.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/chrome/cros_ec_trace.c 
b/drivers/platform/chrome/cros_ec_trace.c
index 0a76412095a9..9b6aba22441f 100644
--- a/drivers/platform/chrome/cros_ec_trace.c
+++ b/drivers/platform/chrome/cros_ec_trace.c
@@ -6,7 +6,23 @@
 #define TRACE_SYMBOL(a) {a, #a}
 
 // Generate the list using the following script:
-// sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1), \\/p' 
include/linux/mfd/cros_ec_commands.h
+// sed -n 's/^#define \(EC_CMD_[[:alnum:]_]*\)\s.*/\tTRACE_SYMBOL(\1), \\/p' \
+// include/linux/mfd/cros_ec_commands.h | awk '
+// BEGIN {
+//   on = 0;
+// }
+// {
+//   if (on)
+// print buf;
+//   else
+// on = 1;
+//   buf = $0;
+// }
+// END {
+//   gsub(/, \\/, "", buf);
+//   print buf;
+// }
+// '
 #define EC_CMDS \
TRACE_SYMBOL(EC_CMD_PROTO_VERSION), \
TRACE_SYMBOL(EC_CMD_HELLO), \
-- 
2.22.0.657.g960e92d24f-goog



Re: [PATCH v3] sched/topology: Improve load balancing on AMD EPYC

2019-07-23 Thread Peter Zijlstra
On Tue, Jul 23, 2019 at 12:42:48PM +0100, Mel Gorman wrote:
> On Tue, Jul 23, 2019 at 11:48:30AM +0100, Matt Fleming wrote:
> > SD_BALANCE_{FORK,EXEC} and SD_WAKE_AFFINE are stripped in sd_init()
> > for any sched domains with a NUMA distance greater than 2 hops
> > (RECLAIM_DISTANCE). The idea being that it's expensive to balance
> > across domains that far apart.
> > 
> > However, as is rather unfortunately explained in
> > 
> >   commit 32e45ff43eaf ("mm: increase RECLAIM_DISTANCE to 30")
> > 
> > the value for RECLAIM_DISTANCE is based on node distance tables from
> > 2011-era hardware.
> > 
> > Current AMD EPYC machines have the following NUMA node distances:
> > 
> > node distances:
> > node   0   1   2   3   4   5   6   7
> >   0:  10  16  16  16  32  32  32  32
> >   1:  16  10  16  16  32  32  32  32
> >   2:  16  16  10  16  32  32  32  32
> >   3:  16  16  16  10  32  32  32  32
> >   4:  32  32  32  32  10  16  16  16
> >   5:  32  32  32  32  16  10  16  16
> >   6:  32  32  32  32  16  16  10  16
> >   7:  32  32  32  32  16  16  16  10
> > 
> > where 2 hops is 32.
> > 
> > The result is that the scheduler fails to load balance properly across
> > NUMA nodes on different sockets -- 2 hops apart.
> > 
> > For example, pinning 16 busy threads to NUMA nodes 0 (CPUs 0-7) and 4
> > (CPUs 32-39) like so,
> > 
> >   $ numactl -C 0-7,32-39 ./spinner 16
> > 
> > causes all threads to fork and remain on node 0 until the active
> > balancer kicks in after a few seconds and forcibly moves some threads
> > to node 4.
> > 
> > Override node_reclaim_distance for AMD Zen.
> > 
> > Signed-off-by: Matt Fleming 
> > Cc: "Suthikulpanit, Suravee" 
> > Cc: Mel Gorman 
> > Cc: "Lendacky, Thomas" 
> > Cc: Borislav Petkov 
> 
> Acked-by: Mel Gorman 
> 
> The only caveat I can think of is that a future generation of Zen might
> take a different magic number than 32 as their remote distance. If or
> when this happens, it'll need additional smarts but lacking a crystal
> ball, we can cross that bridge when we come to it.

I just suggested to Matt on IRC we could do something along these lines,
but we can do that later.

--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1611,6 +1611,12 @@ void sched_init_numa(void)
}
 
/*
+* Set the reclaim distance at 2 hops instead of at a fixed distance 
value.
+*/
+   if (level >= 2)
+   node_reclaim_distance = sched_domains_numa_distance[2];
+
+   /*
 * 'level' contains the number of unique distances
 *
 * The sched_domains_numa_distance[] array includes the actual distance


Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool

2019-07-23 Thread Jon Hunter


On 23/07/2019 11:49, Jose Abreu wrote:
> From: Jon Hunter 
> Date: Jul/23/2019, 11:38:33 (UTC+00:00)
> 
>>
>> On 23/07/2019 11:07, Jose Abreu wrote:
>>> From: Jon Hunter 
>>> Date: Jul/23/2019, 11:01:24 (UTC+00:00)
>>>
 This appears to be a winner and by disabling the SMMU for the ethernet
 controller and reverting commit 954a03be033c7cef80ddc232e7cbdb17df735663
 this worked! So yes appears to be related to the SMMU being enabled. We
 had to enable the SMMU for ethernet recently due to commit
 954a03be033c7cef80ddc232e7cbdb17df735663.
>>>
>>> Finally :)
>>>
>>> However, from "git show 954a03be033c7cef80ddc232e7cbdb17df735663":
>>>
>>> + There are few reasons to allow unmatched stream bypass, and
>>> + even fewer good ones.  If saying YES here breaks your board
>>> + you should work on fixing your board.
>>>
>>> So, how can we fix this ? Is your ethernet DT node marked as 
>>> "dma-coherent;" ?
>>
>> TBH I have no idea. I can't say I fully understand your change or how it
>> is breaking things for us.
>>
>> Currently, the Tegra DT binding does not have 'dma-coherent' set. I see
>> this is optional, but I am not sure how you determine whether or not
>> this should be set.
> 
> From my understanding it means that your device / IP DMA accesses are 
> coherent regarding the CPU point of view. I think it will be the case if GMAC 
> is not behind any kind of IOMMU in the HW arch.

I understand what coherency is, I just don't know how you tell if this
implementation of the ethernet controller is coherent or not.

Jon

-- 
nvpublic


[PATCH] Input: Apple SPI keyboard needs CRC16

2019-07-23 Thread Arnd Bergmann
In some rare randconfig builds, CRC16 is disabled, which leads
to a link error:

drivers/input/keyboard/applespi.o: In function `applespi_send_cmd_msg':
applespi.c:(.text+0x449f): undefined reference to `crc16'
drivers/input/keyboard/applespi.o: In function `applespi_verify_crc':
applespi.c:(.text+0x7538): undefined reference to `crc16'

This symbol is meant to be selected for each user in Kconfig,
so do that here as well.

Fixes: 038b1a05eae6 ("Input: add Apple SPI keyboard and trackpad driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/input/keyboard/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 8e9c3ea9d5e7..ebb19e21473e 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -76,6 +76,7 @@ config KEYBOARD_APPLESPI
depends on ACPI && EFI
depends on SPI
depends on X86 || COMPILE_TEST
+   select CRC16
help
  Say Y here if you are running Linux on any Apple MacBook8,1 or later,
  or any MacBookPro13,* or MacBookPro14,*.
-- 
2.20.0



[PATCH RFC] mm/page_idle: simple idle page tracking for virtual memory

2019-07-23 Thread Konstantin Khlebnikov
The page_idle tracking feature currently requires looking up the pagemap
for a process followed by interacting with /sys/kernel/mm/page_idle.
This is quite cumbersome and can be error-prone too. If between
accessing the per-PID pagemap and the global page_idle bitmap, if
something changes with the page then the information is not accurate.
More over looking up PFN from pagemap in Android devices is not
supported by unprivileged process and requires SYS_ADMIN and gives 0 for
the PFN.

This patch adds simplified interface which works only with mapped pages:
Run: "echo 6 > /proc/pid/clear_refs" to mark all mapped pages as idle.
Pages that still idle are marked with bit 57 in /proc/pid/pagemap.
Total size of idle pages is shown in /proc/pid/smaps (_rollup).

Piece of comment is stolen from Joel Fernandes 

Signed-off-by: Konstantin Khlebnikov 
Link: 
https://lore.kernel.org/lkml/20190722213205.140845-1-j...@joelfernandes.org/
---
 Documentation/admin-guide/mm/pagemap.rst |3 ++-
 Documentation/filesystems/proc.txt   |3 +++
 fs/proc/task_mmu.c   |   33 --
 3 files changed, 36 insertions(+), 3 deletions(-)

diff --git a/Documentation/admin-guide/mm/pagemap.rst 
b/Documentation/admin-guide/mm/pagemap.rst
index 340a5aee9b80..d7ee60287584 100644
--- a/Documentation/admin-guide/mm/pagemap.rst
+++ b/Documentation/admin-guide/mm/pagemap.rst
@@ -21,7 +21,8 @@ There are four components to pagemap:
 * Bit  55pte is soft-dirty (see
   :ref:`Documentation/admin-guide/mm/soft-dirty.rst `)
 * Bit  56page exclusively mapped (since 4.2)
-* Bits 57-60 zero
+* Bit  57page is idle
+* Bits 58-60 zero
 * Bit  61page is file-page or shared-anon (since 3.5)
 * Bit  62page swapped
 * Bit  63page present
diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index 99ca040e3f90..d222be8b4eb9 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -574,6 +574,9 @@ To reset the peak resident set size ("high water mark") to 
the process's
 current value:
 > echo 5 > /proc/PID/clear_refs
 
+To mark all mapped pages as idle:
+> echo 6 > /proc/PID/clear_refs
+
 Any other value written to /proc/PID/clear_refs will have no effect.
 
 The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 731642e0f5a0..6da952574a1f 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -413,6 +413,7 @@ struct mem_size_stats {
unsigned long private_clean;
unsigned long private_dirty;
unsigned long referenced;
+   unsigned long idle;
unsigned long anonymous;
unsigned long lazyfree;
unsigned long anonymous_thp;
@@ -479,6 +480,10 @@ static void smaps_account(struct mem_size_stats *mss, 
struct page *page,
if (young || page_is_young(page) || PageReferenced(page))
mss->referenced += size;
 
+   /* Not accessed and still idle. */
+   if (!young && page_is_idle(page))
+   mss->idle += size;
+
/*
 * Then accumulate quantities that may depend on sharing, or that may
 * differ page-by-page.
@@ -799,6 +804,9 @@ static void __show_smap(struct seq_file *m, const struct 
mem_size_stats *mss,
SEQ_PUT_DEC(" kB\nPrivate_Clean:  ", mss->private_clean);
SEQ_PUT_DEC(" kB\nPrivate_Dirty:  ", mss->private_dirty);
SEQ_PUT_DEC(" kB\nReferenced: ", mss->referenced);
+#ifdef CONFIG_IDLE_PAGE_TRACKING
+   SEQ_PUT_DEC(" kB\nIdle:   ", mss->idle);
+#endif
SEQ_PUT_DEC(" kB\nAnonymous:  ", mss->anonymous);
SEQ_PUT_DEC(" kB\nLazyFree:   ", mss->lazyfree);
SEQ_PUT_DEC(" kB\nAnonHugePages:  ", mss->anonymous_thp);
@@ -969,6 +977,7 @@ enum clear_refs_types {
CLEAR_REFS_MAPPED,
CLEAR_REFS_SOFT_DIRTY,
CLEAR_REFS_MM_HIWATER_RSS,
+   CLEAR_REFS_SOFT_ACCESS,
CLEAR_REFS_LAST,
 };
 
@@ -1045,6 +1054,7 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned long 
addr,
pte_t *pte, ptent;
spinlock_t *ptl;
struct page *page;
+   int young;
 
ptl = pmd_trans_huge_lock(pmd, vma);
if (ptl) {
@@ -1058,8 +1068,16 @@ static int clear_refs_pte_range(pmd_t *pmd, unsigned 
long addr,
 
page = pmd_page(*pmd);
 
+   young = pmdp_test_and_clear_young(vma, addr, pmd);
+
+   if (cp->type == CLEAR_REFS_SOFT_ACCESS) {
+   if (young)
+   set_page_young(page);
+   set_page_idle(page);
+   goto out;
+   }
+
/* Clear accessed and referenced bits. */
-   pmdp_test_and_clear_young(vma, addr, pmd);
test_and_clear_page_young(page);
ClearPageReferenced(page);
 out:
@@ -1086,8 +1104,16 @@ 

Re: get_maintainers.pl subsystem output

2019-07-23 Thread Joe Perches
On Tue, 2019-07-23 at 09:29 +0200, Duda, Sebastian wrote:
> Hi Joe,
> 
> when analyzing the patch 
> `<20150128012747.824898...@linuxfoundation.org>` [1] with 

https://lore.kernel.org/lkml/220150128012747.824898...@linuxfoundation.org

> `get_maintainers.pl --subsystem --status --separator , /tmp/patch`, 
> there is the following output:

[]

> > Run the script with multiple invocations. once for each file
> > modified by the patch.

For example: perhaps use something like:

$ grep -h '^\+\+\+ b/'  | \
  sed 's@^\+\+\+ b/@@' | sort | uniq | \
  while read file ; do \
./scripts/get_maintainer.pl --nogit --nogit-fallback --subsystem --status 
--separator , $file ; \
  done

or use parallel like:

$ grep -h '^\+\+\+ b/'  | \
  sed 's@^\+\+\+ b/@@' | sort | uniq | \
  parallel -k ./scripts/get_maintainer.pl --nogit --nogit-fallback --subsystem 
--status --separator ,

runtime on my system for this is

Using while read loop:

real0m2.509s
user0m2.236s
sys 0m0.296s

Using parallel:

real0m1.340s
user0m4.159s
sys 0m0.429s




[PATCH] serial: 8250_omap: Fix idling for unloaded serdev drivers

2019-07-23 Thread Tony Lindgren
For many years omap variants have been setting the runtime PM
autosuspend delay to -1 to prevent unsafe policy with lossy first
character on wake-up. The user must specifically enable the timeout
for UARTs if desired.

We must not enable the workaround for serdev devices though. It leads
into UARTs not idling if no serdev devices are loaded and there is no
sysfs entry to configure the UART in that case. And this means that
my PM may not work unless the serdev modules are loaded.

We can detect a serdev device being configured based on a dts child
node, and we can simply skip the workround in that case. And the
serdev driver can idle the port during runtime when suitable if an
out-of-band wake-up GPIO line exists for example.

Let's also add some comments to the workaround while at it.

Cc: Johan Hovold 
Signed-off-by: Tony Lindgren 
---
 drivers/tty/serial/8250/8250_omap.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_omap.c 
b/drivers/tty/serial/8250/8250_omap.c
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -1234,7 +1234,16 @@ static int omap8250_probe(struct platform_device *pdev)
 
device_init_wakeup(>dev, true);
pm_runtime_use_autosuspend(>dev);
-   pm_runtime_set_autosuspend_delay(>dev, -1);
+
+   /*
+* Disable runtime PM until autosuspend delay unless specifically
+* enabled by the user via sysfs. This is the historic way to
+* prevent an unsafe default policy with lossy characters on wake-up.
+* For serdev devices this is not needed, the policy can be managed by
+* the serdev driver.
+*/
+   if (!of_get_available_child_count(pdev->dev.of_node))
+   pm_runtime_set_autosuspend_delay(>dev, -1);
 
pm_runtime_irq_safe(>dev);
pm_runtime_enable(>dev);
-- 
2.21.0


[PATCH] memstick: r592: Use dev_get_drvdata

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/memstick/host/r592.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/memstick/host/r592.c b/drivers/memstick/host/r592.c
index 2932f421b3ea..dd3a1f3dcc19 100644
--- a/drivers/memstick/host/r592.c
+++ b/drivers/memstick/host/r592.c
@@ -847,8 +847,7 @@ static void r592_remove(struct pci_dev *pdev)
 #ifdef CONFIG_PM_SLEEP
 static int r592_suspend(struct device *core_dev)
 {
-   struct pci_dev *pdev = to_pci_dev(core_dev);
-   struct r592_device *dev = pci_get_drvdata(pdev);
+   struct r592_device *dev = dev_get_drvdata(core_dev);
 
r592_clear_interrupts(dev);
memstick_suspend_host(dev->host);
@@ -858,8 +857,7 @@ static int r592_suspend(struct device *core_dev)
 
 static int r592_resume(struct device *core_dev)
 {
-   struct pci_dev *pdev = to_pci_dev(core_dev);
-   struct r592_device *dev = pci_get_drvdata(pdev);
+   struct r592_device *dev = dev_get_drvdata(core_dev);
 
r592_clear_interrupts(dev);
r592_enable_device(dev, false);
-- 
2.20.1



[PATCH] mfd: timberdale: Use dev_get_drvdata

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/mfd/timberdale.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index 60c122e9b39f..faecbca6dba3 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -626,8 +626,7 @@ static const struct mfd_cell timberdale_cells_bar2[] = {
 static ssize_t show_fw_ver(struct device *dev, struct device_attribute *attr,
char *buf)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct timberdale_device *priv = pci_get_drvdata(pdev);
+   struct timberdale_device *priv = dev_get_drvdata(dev);
 
return sprintf(buf, "%d.%d.%d\n", priv->fw.major, priv->fw.minor,
priv->fw.config);
-- 
2.20.1



[PATCH] media: pci: Use dev_get_drvdata where possible

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/media/pci/intel/ipu3/ipu3-cio2.c | 3 +--
 drivers/media/pci/pt1/pt1.c  | 6 ++
 drivers/media/pci/pt3/pt3.c  | 6 ++
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/media/pci/intel/ipu3/ipu3-cio2.c 
b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
index c1d133e17e4b..50a34bcd4d14 100644
--- a/drivers/media/pci/intel/ipu3/ipu3-cio2.c
+++ b/drivers/media/pci/intel/ipu3/ipu3-cio2.c
@@ -2000,8 +2000,7 @@ static int __maybe_unused cio2_suspend(struct device *dev)
 
 static int __maybe_unused cio2_resume(struct device *dev)
 {
-   struct pci_dev *pci_dev = to_pci_dev(dev);
-   struct cio2_device *cio2 = pci_get_drvdata(pci_dev);
+   struct cio2_device *cio2 = dev_get_drvdata(dev);
int r = 0;
struct cio2_queue *q = cio2->cur_queue;
 
diff --git a/drivers/media/pci/pt1/pt1.c b/drivers/media/pci/pt1/pt1.c
index e51c80bc4646..72b191cfeb54 100644
--- a/drivers/media/pci/pt1/pt1.c
+++ b/drivers/media/pci/pt1/pt1.c
@@ -1217,8 +1217,7 @@ static void pt1_i2c_init(struct pt1 *pt1)
 
 static int pt1_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct pt1 *pt1 = pci_get_drvdata(pdev);
+   struct pt1 *pt1 = dev_get_drvdata(dev);
 
pt1_init_streams(pt1);
pt1_disable_ram(pt1);
@@ -1230,8 +1229,7 @@ static int pt1_suspend(struct device *dev)
 
 static int pt1_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct pt1 *pt1 = pci_get_drvdata(pdev);
+   struct pt1 *pt1 = dev_get_drvdata(dev);
int ret;
int i;
 
diff --git a/drivers/media/pci/pt3/pt3.c b/drivers/media/pci/pt3/pt3.c
index 7a7afae4c84c..c0bc86793355 100644
--- a/drivers/media/pci/pt3/pt3.c
+++ b/drivers/media/pci/pt3/pt3.c
@@ -626,8 +626,7 @@ static void pt3_cleanup_adapter(struct pt3_board *pt3, int 
index)
 
 static int pt3_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct pt3_board *pt3 = pci_get_drvdata(pdev);
+   struct pt3_board *pt3 = dev_get_drvdata(dev);
int i;
struct pt3_adapter *adap;
 
@@ -646,8 +645,7 @@ static int pt3_suspend(struct device *dev)
 
 static int pt3_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct pt3_board *pt3 = pci_get_drvdata(pdev);
+   struct pt3_board *pt3 = dev_get_drvdata(dev);
int i, ret;
struct pt3_adapter *adap;
 
-- 
2.20.1



[PATCH] ide: Use dev_get_drvdata where possible

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/ide/siimage.c   | 3 +--
 drivers/ide/via82cxxx.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/ide/siimage.c b/drivers/ide/siimage.c
index 57eea5a9047f..c4b20f350b84 100644
--- a/drivers/ide/siimage.c
+++ b/drivers/ide/siimage.c
@@ -648,8 +648,7 @@ static void sil_quirkproc(ide_drive_t *drive)
 
 static void init_iops_siimage(ide_hwif_t *hwif)
 {
-   struct pci_dev *dev = to_pci_dev(hwif->dev);
-   struct ide_host *host = pci_get_drvdata(dev);
+   struct ide_host *host = dev_get_drvdata(hwif->dev);
 
hwif->hwif_data = NULL;
 
diff --git a/drivers/ide/via82cxxx.c b/drivers/ide/via82cxxx.c
index 977cb00398b0..63a3aca506fc 100644
--- a/drivers/ide/via82cxxx.c
+++ b/drivers/ide/via82cxxx.c
@@ -175,8 +175,7 @@ static void via_set_speed(ide_hwif_t *hwif, u8 dn, struct 
ide_timing *timing)
 static void via_set_drive(ide_hwif_t *hwif, ide_drive_t *drive)
 {
ide_drive_t *peer = ide_get_pair_dev(drive);
-   struct pci_dev *dev = to_pci_dev(hwif->dev);
-   struct ide_host *host = pci_get_drvdata(dev);
+   struct ide_host *host = dev_get_drvdata(hwif->dev);
struct via82cxxx_dev *vdev = host->host_priv;
struct ide_timing t, p;
unsigned int T, UT;
-- 
2.20.1



[PATCH] IB/usnic: Use dev_get_drvdata

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c 
b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
index eeb07b245ef9..a354c7c86547 100644
--- a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
@@ -194,7 +194,7 @@ find_free_vf_and_create_qp_grp(struct usnic_ib_dev 
*us_ibdev,
return ERR_CAST(dev_list);
for (i = 0; dev_list[i]; i++) {
dev = dev_list[i];
-   vf = pci_get_drvdata(to_pci_dev(dev));
+   vf = dev_get_drvdata(dev);
spin_lock(>lock);
vnic = vf->vnic;
if (!usnic_vnic_check_room(vnic, res_spec)) {
-- 
2.20.1



Re: [PATCH 0/6] ARM: psci: cpuidle: PSCI CPUidle rework

2019-07-23 Thread Ulf Hansson
On Mon, 22 Jul 2019 at 17:37, Lorenzo Pieralisi
 wrote:
>
> Current PSCI CPUidle driver is built on top of the generic ARM
> CPUidle infrastructure that relies on the architectural back-end
> idle operations to initialize and enter idle states.
>
> On ARM64 systems, PSCI is the only interface the kernel ever uses
> to enter idle states, so, having to rely on a generic ARM CPUidle
> driver when there is and there will always be only one method
> for entering idle states proved to be overkill, more so given
> that on ARM 32-bit systems (that can also enable the generic
> ARM CPUidle driver) only one additional idle back-end was
> ever added:
>
> drivers/soc/qcom/spm.c
>
> and it can be easily converted to a full-fledged CPUidle driver
> without requiring the generic ARM CPUidle framework.
>
> Furthermore, the generic ARM CPUidle infrastructure forces the
> PSCI firmware layer to keep CPUidle specific information in it,
> which does not really fit its purpose that should be kernel
> control/data structure agnostic.
>
> Lastly, the interface between the generic ARM CPUidle driver and
> the arch back-end requires an idle state index to be passed to
> suspend operations, with idle states back-end internals (such
> as idle state parameters) hidden in architectural back-ends and
> not available to the generic ARM CPUidle driver.
>
> To improve the above mentioned shortcomings, implement a stand
> alone PSCI CPUidle driver; this improves the current kernel
> code from several perspective:
>
> - Move CPUidle internal knowledge into CPUidle driver out of
>   the PSCI firmware interface
> - Give the PSCI CPUidle driver control over power state parameters,
>   in particular in preparation for PSCI OSI support
> - Remove generic CPUidle operations infrastructure from the kernel
>
> This patchset does not go as far as removing the generic ARM CPUidle
> infrastructure in order to collect feedback on the new approach
> before completing the removal from the kernel, the generic and PSCI
> CPUidle driver are left to co-exist.

I like the approach and I think this series definitely moves things in
the right direction.

Of course, some additional cleanups/re-works on top are needed to show
its full benefit, but step by step we reach that point.

>
> Tested on Juno platform with both DT and ACPI boot firmwares.
>
> Cc: Will Deacon 
> Cc: Ulf Hansson 
> Cc: Sudeep Holla 
> Cc: Daniel Lezcano 
> Cc: Catalin Marinas 
> Cc: Mark Rutland 
> Cc: "Rafael J. Wysocki" 
>
> Lorenzo Pieralisi (6):
>   ARM: cpuidle: Remove useless header include
>   ARM: cpuidle: Remove overzealous error logging
>   drivers: firmware: psci: Decouple checker from generic ARM CPUidle
>   ARM: psci: cpuidle: Introduce PSCI CPUidle driver
>   ARM: psci: cpuidle: Enable PSCI CPUidle driver
>   PSCI: cpuidle: Refactor CPU suspend power_state parameter handling
>
>  MAINTAINERS  |   8 +
>  arch/arm/configs/imx_v6_v7_defconfig |   1 +
>  arch/arm64/configs/defconfig |   1 +
>  arch/arm64/kernel/cpuidle.c  |  50 +-
>  arch/arm64/kernel/psci.c |   4 -
>  drivers/cpuidle/Kconfig.arm  |   7 +
>  drivers/cpuidle/Makefile |   1 +
>  drivers/cpuidle/cpuidle-arm.c|  13 +-
>  drivers/cpuidle/cpuidle-psci.c   | 235 +++
>  drivers/firmware/psci/psci.c | 167 +--
>  drivers/firmware/psci/psci_checker.c |  16 +-
>  include/linux/cpuidle.h  |  17 +-
>  include/linux/psci.h |   4 +-
>  13 files changed, 338 insertions(+), 186 deletions(-)
>  create mode 100644 drivers/cpuidle/cpuidle-psci.c
>
> --
> 2.21.0
>

For the series, besides the minor comments I had on patch 4, feel free to add:

Reviewed-by: Ulf Hansson 

Kind regards
Uffe


[tip:x86/cleanups] x86/bitops: Use __builtin_constant_p() directly instead of IS_IMMEDIATE()

2019-07-23 Thread tip-bot for Masahiro Yamada
Commit-ID:  bdd50d7421b2f8fd99f953e1f747e0cb3f3bed64
Gitweb: https://git.kernel.org/tip/bdd50d7421b2f8fd99f953e1f747e0cb3f3bed64
Author: Masahiro Yamada 
AuthorDate: Tue, 23 Jul 2019 16:44:15 +0900
Committer:  Thomas Gleixner 
CommitDate: Tue, 23 Jul 2019 13:44:18 +0200

x86/bitops: Use __builtin_constant_p() directly instead of IS_IMMEDIATE()

__builtin_constant_p(nr) is used everywhere now. It does not make much
sense to define IS_IMMEDIATE() as its alias.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Thomas Gleixner 
Link: 
https://lkml.kernel.org/r/20190723074415.26811-1-yamada.masah...@socionext.com

---
 arch/x86/include/asm/bitops.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/bitops.h b/arch/x86/include/asm/bitops.h
index ba15d53c1ca7..7d1f6a49bfae 100644
--- a/arch/x86/include/asm/bitops.h
+++ b/arch/x86/include/asm/bitops.h
@@ -45,14 +45,13 @@
  * We do the locked ops that don't return the old value as
  * a mask operation on a byte.
  */
-#define IS_IMMEDIATE(nr)   (__builtin_constant_p(nr))
 #define CONST_MASK_ADDR(nr, addr)  WBYTE_ADDR((void *)(addr) + ((nr)>>3))
 #define CONST_MASK(nr) (1 << ((nr) & 7))
 
 static __always_inline void
 arch_set_bit(long nr, volatile unsigned long *addr)
 {
-   if (IS_IMMEDIATE(nr)) {
+   if (__builtin_constant_p(nr)) {
asm volatile(LOCK_PREFIX "orb %1,%0"
: CONST_MASK_ADDR(nr, addr)
: "iq" ((u8)CONST_MASK(nr))
@@ -72,7 +71,7 @@ arch___set_bit(long nr, volatile unsigned long *addr)
 static __always_inline void
 arch_clear_bit(long nr, volatile unsigned long *addr)
 {
-   if (IS_IMMEDIATE(nr)) {
+   if (__builtin_constant_p(nr)) {
asm volatile(LOCK_PREFIX "andb %1,%0"
: CONST_MASK_ADDR(nr, addr)
: "iq" ((u8)~CONST_MASK(nr)));
@@ -123,7 +122,7 @@ arch___change_bit(long nr, volatile unsigned long *addr)
 static __always_inline void
 arch_change_bit(long nr, volatile unsigned long *addr)
 {
-   if (IS_IMMEDIATE(nr)) {
+   if (__builtin_constant_p(nr)) {
asm volatile(LOCK_PREFIX "xorb %1,%0"
: CONST_MASK_ADDR(nr, addr)
: "iq" ((u8)CONST_MASK(nr)));


Re: [PATCH 6/6] PSCI: cpuidle: Refactor CPU suspend power_state parameter handling

2019-07-23 Thread Ulf Hansson
On Mon, 22 Jul 2019 at 17:38, Lorenzo Pieralisi
 wrote:
>
> Current PSCI code handles idle state entry through the
> psci_cpu_suspend_enter() API, that takes an idle state index as a
> parameter and convert the index into a previously initialized
> power_state parameter before calling the PSCI.CPU_SUSPEND() with it.
>
> This is unwieldly, since it forces the PSCI firmware layer to keep track
> of power_state parameter for every idle state so that the
> index->power_state conversion can be made in the PSCI firmware layer
> instead of the CPUidle driver implementations.
>
> Move the power_state handling out of drivers/firmware/psci
> into the respective ACPI/DT PSCI CPUidle backends and convert
> the psci_cpu_suspend_enter() API to get the power_state
> parameter as input, which makes it closer to its firmware
> interface PSCI.CPU_SUSPEND() API.
>
> A notable side effect is that the PSCI ACPI/DT CPUidle backends
> now can directly handle (and if needed update) power_state
> parameters before handing them over to the PSCI firmware
> interface to trigger PSCI.CPU_SUSPEND() calls.
>
> Signed-off-by: Lorenzo Pieralisi 
> Cc: Will Deacon 
> Cc: Ulf Hansson 
> Cc: Sudeep Holla 
> Cc: Daniel Lezcano 
> Cc: Catalin Marinas 
> Cc: Mark Rutland 
> Cc: "Rafael J. Wysocki" 
> ---
>  arch/arm64/kernel/cpuidle.c|  47 +-
>  drivers/cpuidle/cpuidle-psci.c |  87 +-
>  drivers/firmware/psci/psci.c   | 158 ++---
>  include/linux/cpuidle.h|  17 +++-
>  include/linux/psci.h   |   4 +-
>  5 files changed, 153 insertions(+), 160 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
> index 4bcd1bca0dfc..e4d6af2fdec7 100644
> --- a/arch/arm64/kernel/cpuidle.c
> +++ b/arch/arm64/kernel/cpuidle.c
> @@ -47,6 +47,44 @@ int arm_cpuidle_suspend(int index)
>
>  #define ARM64_LPI_IS_RETENTION_STATE(arch_flags) (!(arch_flags))
>
> +static int psci_acpi_cpu_init_idle(unsigned int cpu)
> +{
> +   int i, count;
> +   struct acpi_lpi_state *lpi;
> +   struct acpi_processor *pr = per_cpu(processors, cpu);
> +
> +   /*
> +* If the PSCI cpu_suspend function hook has not been initialized
> +* idle states must not be enabled, so bail out
> +*/
> +   if (!psci_ops.cpu_suspend)
> +   return -EOPNOTSUPP;
> +
> +   if (unlikely(!pr || !pr->flags.has_lpi))
> +   return -EINVAL;
> +
> +   count = pr->power.count - 1;
> +   if (count <= 0)
> +   return -ENODEV;
> +
> +   for (i = 0; i < count; i++) {
> +   u32 state;
> +
> +   lpi = >power.lpi_states[i + 1];
> +   /*
> +* Only bits[31:0] represent a PSCI power_state while
> +* bits[63:32] must be 0x0 as per ARM ACPI FFH Specification
> +*/
> +   state = lpi->address;
> +   if (!psci_power_state_is_valid(state)) {
> +   pr_warn("Invalid PSCI power state %#x\n", state);
> +   return -EINVAL;
> +   }
> +   }
> +
> +   return 0;
> +}
> +
>  int acpi_processor_ffh_lpi_probe(unsigned int cpu)
>  {
> return psci_acpi_cpu_init_idle(cpu);
> @@ -54,10 +92,13 @@ int acpi_processor_ffh_lpi_probe(unsigned int cpu)
>
>  int acpi_processor_ffh_lpi_enter(struct acpi_lpi_state *lpi)
>  {
> +   u32 state = lpi->address;
> +
> if (ARM64_LPI_IS_RETENTION_STATE(lpi->arch_flags))
> -   return CPU_PM_CPU_IDLE_ENTER_RETENTION(psci_cpu_suspend_enter,
> -   lpi->index);
> +   return 
> CPU_PM_CPU_IDLE_ENTER_RETENTION_PARAM(psci_cpu_suspend_enter,
> +   lpi->index, state);
> else
> -   return CPU_PM_CPU_IDLE_ENTER(psci_cpu_suspend_enter, 
> lpi->index);
> +   return CPU_PM_CPU_IDLE_ENTER_PARAM(psci_cpu_suspend_enter,
> +lpi->index, state);
>  }

I am not sure where the acpi+psci cpuidle code really belongs. Perhaps
some code should be moved into separate acpi+psci cpuidle driver?

In any case and whatever makes sense, it can be done on top of the
current series.

[...]

Kind regards
Uffe


Re: [PATCH 4/6] ARM: psci: cpuidle: Introduce PSCI CPUidle driver

2019-07-23 Thread Ulf Hansson
[...]

> +++ b/drivers/cpuidle/cpuidle-psci.c
> @@ -0,0 +1,150 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * PSCI CPU idle driver.
> + *
> + * Copyright (C) 2019 ARM Ltd.
> + * Author: Lorenzo Pieralisi 
> + */
> +
> +#define pr_fmt(fmt) "CPUidle PSCI: " fmt
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 

This should go away, right?

> +
> +#include "dt_idle_states.h"
> +
> +static int psci_enter_idle_state(struct cpuidle_device *dev,
> +   struct cpuidle_driver *drv, int idx)
> +{
> +   return CPU_PM_CPU_IDLE_ENTER(psci_cpu_suspend_enter, idx);
> +}
> +
> +static struct cpuidle_driver psci_idle_driver __initdata = {
> +   .name = "psci_idle",
> +   .owner = THIS_MODULE,
> +   /*
> +* PSCI idle states relies on architectural WFI to
> +* be represented as state index 0.
> +*/
> +   .states[0] = {
> +   .enter  = psci_enter_idle_state,
> +   .exit_latency   = 1,
> +   .target_residency   = 1,
> +   .power_usage= UINT_MAX,
> +   .name   = "WFI",
> +   .desc   = "ARM WFI",
> +   }
> +};
> +
> +static const struct of_device_id psci_idle_state_match[] __initconst = {
> +   { .compatible = "arm,idle-state",
> + .data = psci_enter_idle_state },
> +   { },
> +};
> +
> +static int __init psci_idle_init_cpu(int cpu)
> +{
> +   struct cpuidle_driver *drv;
> +   struct device_node *cpu_node;
> +   const char *enable_method;
> +   int ret = 0;
> +
> +   drv = kmemdup(_idle_driver, sizeof(*drv), GFP_KERNEL);
> +   if (!drv)
> +   return -ENOMEM;
> +
> +   drv->cpumask = (struct cpumask *)cpumask_of(cpu);
> +
> +   cpu_node = of_get_cpu_node(cpu, NULL);
> +   if (!cpu_node)
> +   return -ENODEV;

You should free drv in case of error here (goto out_kfree_drv; etc).

> +
> +   /*
> +* Check whether the enable-method for the cpu is PSCI, fail
> +* if it is not.
> +*/
> +   enable_method = of_get_property(cpu_node, "enable-method", NULL);
> +   if (!enable_method || (strcmp(enable_method, "psci")))
> +   ret = -ENODEV;
> +
> +   of_node_put(cpu_node);
> +   if (ret)
> +   return ret;

You should free drv in case of error here (goto out_kfree_drv;).

> +
> +   /*
> +* Initialize idle states data, starting at index 1, since
> +* by default idle state 0 is the quiescent state reached
> +* by the cpu by executing the wfi instruction.
> +*
> +* If no DT idle states are detected (ret == 0) let the driver
> +* initialization fail accordingly since there is no reason to
> +* initialize the idle driver if only wfi is supported, the
> +* default archictectural back-end already executes wfi
> +* on idle entry.
> +*/
> +   ret = dt_init_idle_driver(drv, psci_idle_state_match, 1);
> +   if (ret <= 0) {
> +   ret = ret ? : -ENODEV;
> +   goto out_kfree_drv;
> +   }
> +
> +   /*
> +* Initialize PSCI idle states.
> +*/
> +   ret = psci_cpu_init_idle(cpu);
> +   if (ret) {
> +   pr_err("CPU %d failed to PSCI idle\n", cpu);
> +   goto out_kfree_drv;
> +   }
> +
> +   ret = cpuidle_register(drv, NULL);
> +   if (ret)
> +   goto out_kfree_drv;
> +
> +   return 0;
> +
> +out_kfree_drv:
> +   kfree(drv);
> +   return ret;
> +}
> +

[...]

Kind regards
Uffe


[tip:x86/build] x86/build: Remove unneeded uapi asm-generic wrappers

2019-07-23 Thread tip-bot for Masahiro Yamada
Commit-ID:  701010532164eaacd415ec5683717da03f4b822d
Gitweb: https://git.kernel.org/tip/701010532164eaacd415ec5683717da03f4b822d
Author: Masahiro Yamada 
AuthorDate: Tue, 23 Jul 2019 20:26:45 +0900
Committer:  Thomas Gleixner 
CommitDate: Tue, 23 Jul 2019 13:42:14 +0200

x86/build: Remove unneeded uapi asm-generic wrappers

These are listed in include/uapi/asm-generic/Kbuild, so Kbuild will
automatically generate them.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Thomas Gleixner 
Link: 
https://lkml.kernel.org/r/20190723112646.14046-1-yamada.masah...@socionext.com

---
 arch/x86/include/uapi/asm/errno.h| 1 -
 arch/x86/include/uapi/asm/fcntl.h| 1 -
 arch/x86/include/uapi/asm/ioctl.h| 1 -
 arch/x86/include/uapi/asm/ioctls.h   | 1 -
 arch/x86/include/uapi/asm/ipcbuf.h   | 1 -
 arch/x86/include/uapi/asm/param.h| 1 -
 arch/x86/include/uapi/asm/resource.h | 1 -
 arch/x86/include/uapi/asm/termbits.h | 1 -
 arch/x86/include/uapi/asm/termios.h  | 1 -
 arch/x86/include/uapi/asm/types.h| 7 ---
 10 files changed, 16 deletions(-)

diff --git a/arch/x86/include/uapi/asm/errno.h 
b/arch/x86/include/uapi/asm/errno.h
deleted file mode 100644
index 4c82b503d92f..
--- a/arch/x86/include/uapi/asm/errno.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/fcntl.h 
b/arch/x86/include/uapi/asm/fcntl.h
deleted file mode 100644
index 46ab12db5739..
--- a/arch/x86/include/uapi/asm/fcntl.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/ioctl.h 
b/arch/x86/include/uapi/asm/ioctl.h
deleted file mode 100644
index b279fe06dfe5..
--- a/arch/x86/include/uapi/asm/ioctl.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/ioctls.h 
b/arch/x86/include/uapi/asm/ioctls.h
deleted file mode 100644
index ec34c760665e..
--- a/arch/x86/include/uapi/asm/ioctls.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/ipcbuf.h 
b/arch/x86/include/uapi/asm/ipcbuf.h
deleted file mode 100644
index 84c7e51cb6d0..
--- a/arch/x86/include/uapi/asm/ipcbuf.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/param.h 
b/arch/x86/include/uapi/asm/param.h
deleted file mode 100644
index 965d45427975..
--- a/arch/x86/include/uapi/asm/param.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/resource.h 
b/arch/x86/include/uapi/asm/resource.h
deleted file mode 100644
index 04bc4db8921b..
--- a/arch/x86/include/uapi/asm/resource.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/termbits.h 
b/arch/x86/include/uapi/asm/termbits.h
deleted file mode 100644
index 3935b106de79..
--- a/arch/x86/include/uapi/asm/termbits.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/termios.h 
b/arch/x86/include/uapi/asm/termios.h
deleted file mode 100644
index 280d78a9d966..
--- a/arch/x86/include/uapi/asm/termios.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/types.h 
b/arch/x86/include/uapi/asm/types.h
deleted file mode 100644
index df55e1ddb0c9..
--- a/arch/x86/include/uapi/asm/types.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _ASM_X86_TYPES_H
-#define _ASM_X86_TYPES_H
-
-#include 
-
-#endif /* _ASM_X86_TYPES_H */


Re: [PATCH v3] sched/topology: Improve load balancing on AMD EPYC

2019-07-23 Thread Mel Gorman
On Tue, Jul 23, 2019 at 11:48:30AM +0100, Matt Fleming wrote:
> SD_BALANCE_{FORK,EXEC} and SD_WAKE_AFFINE are stripped in sd_init()
> for any sched domains with a NUMA distance greater than 2 hops
> (RECLAIM_DISTANCE). The idea being that it's expensive to balance
> across domains that far apart.
> 
> However, as is rather unfortunately explained in
> 
>   commit 32e45ff43eaf ("mm: increase RECLAIM_DISTANCE to 30")
> 
> the value for RECLAIM_DISTANCE is based on node distance tables from
> 2011-era hardware.
> 
> Current AMD EPYC machines have the following NUMA node distances:
> 
> node distances:
> node   0   1   2   3   4   5   6   7
>   0:  10  16  16  16  32  32  32  32
>   1:  16  10  16  16  32  32  32  32
>   2:  16  16  10  16  32  32  32  32
>   3:  16  16  16  10  32  32  32  32
>   4:  32  32  32  32  10  16  16  16
>   5:  32  32  32  32  16  10  16  16
>   6:  32  32  32  32  16  16  10  16
>   7:  32  32  32  32  16  16  16  10
> 
> where 2 hops is 32.
> 
> The result is that the scheduler fails to load balance properly across
> NUMA nodes on different sockets -- 2 hops apart.
> 
> For example, pinning 16 busy threads to NUMA nodes 0 (CPUs 0-7) and 4
> (CPUs 32-39) like so,
> 
>   $ numactl -C 0-7,32-39 ./spinner 16
> 
> causes all threads to fork and remain on node 0 until the active
> balancer kicks in after a few seconds and forcibly moves some threads
> to node 4.
> 
> Override node_reclaim_distance for AMD Zen.
> 
> Signed-off-by: Matt Fleming 
> Cc: "Suthikulpanit, Suravee" 
> Cc: Mel Gorman 
> Cc: "Lendacky, Thomas" 
> Cc: Borislav Petkov 

Acked-by: Mel Gorman 

The only caveat I can think of is that a future generation of Zen might
take a different magic number than 32 as their remote distance. If or
when this happens, it'll need additional smarts but lacking a crystal
ball, we can cross that bridge when we come to it.

-- 
Mel Gorman
SUSE Labs


[PATCH] ia64: remove unneeded uapi asm-generic wrappers

2019-07-23 Thread Masahiro Yamada
These are listed in include/uapi/asm-generic/Kbuild, so Kbuild will
automatically generate them.

Signed-off-by: Masahiro Yamada 
---

 arch/ia64/include/uapi/asm/errno.h  | 2 --
 arch/ia64/include/uapi/asm/ioctl.h  | 2 --
 arch/ia64/include/uapi/asm/ioctls.h | 7 ---
 3 files changed, 11 deletions(-)
 delete mode 100644 arch/ia64/include/uapi/asm/errno.h
 delete mode 100644 arch/ia64/include/uapi/asm/ioctl.h
 delete mode 100644 arch/ia64/include/uapi/asm/ioctls.h

diff --git a/arch/ia64/include/uapi/asm/errno.h 
b/arch/ia64/include/uapi/asm/errno.h
deleted file mode 100644
index 9addba592646..
--- a/arch/ia64/include/uapi/asm/errno.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#include 
diff --git a/arch/ia64/include/uapi/asm/ioctl.h 
b/arch/ia64/include/uapi/asm/ioctl.h
deleted file mode 100644
index b809c4566e5f..
--- a/arch/ia64/include/uapi/asm/ioctl.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#include 
diff --git a/arch/ia64/include/uapi/asm/ioctls.h 
b/arch/ia64/include/uapi/asm/ioctls.h
deleted file mode 100644
index b86001940209..
--- a/arch/ia64/include/uapi/asm/ioctls.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _ASM_IA64_IOCTLS_H
-#define _ASM_IA64_IOCTLS_H
-
-#include 
-
-#endif /* _ASM_IA64_IOCTLS_H */
-- 
2.17.1



[PATCH] sparc: remove unneeded uapi/asm/statfs.h

2019-07-23 Thread Masahiro Yamada
statfs.h is listed in include/uapi/asm-generic/Kbuild, so Kbuild will
automatically generate it.

Signed-off-by: Masahiro Yamada 
---

 arch/sparc/include/uapi/asm/statfs.h | 7 ---
 1 file changed, 7 deletions(-)
 delete mode 100644 arch/sparc/include/uapi/asm/statfs.h

diff --git a/arch/sparc/include/uapi/asm/statfs.h 
b/arch/sparc/include/uapi/asm/statfs.h
deleted file mode 100644
index 20c8f5bd340e..
--- a/arch/sparc/include/uapi/asm/statfs.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef ___ASM_SPARC_STATFS_H
-#define ___ASM_SPARC_STATFS_H
-
-#include 
-
-#endif
-- 
2.17.1



[PATCH] sh: remove unneeded uapi asm-generic wrappers

2019-07-23 Thread Masahiro Yamada
These are listed in include/uapi/asm-generic/Kbuild, so Kbuild will
automatically generate them.

Signed-off-by: Masahiro Yamada 
---

 arch/sh/include/uapi/asm/setup.h | 2 --
 arch/sh/include/uapi/asm/types.h | 2 --
 2 files changed, 4 deletions(-)
 delete mode 100644 arch/sh/include/uapi/asm/setup.h
 delete mode 100644 arch/sh/include/uapi/asm/types.h

diff --git a/arch/sh/include/uapi/asm/setup.h b/arch/sh/include/uapi/asm/setup.h
deleted file mode 100644
index 4bd19f80f9b0..
--- a/arch/sh/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#include 
diff --git a/arch/sh/include/uapi/asm/types.h b/arch/sh/include/uapi/asm/types.h
deleted file mode 100644
index 68100e108ea6..
--- a/arch/sh/include/uapi/asm/types.h
+++ /dev/null
@@ -1,2 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#include 
-- 
2.17.1



[PATCH] arm64: remove unneeded uapi/asm/stat.h

2019-07-23 Thread Masahiro Yamada
stat.h is listed in include/uapi/asm-generic/Kbuild, so Kbuild will
automatically generate it.

Signed-off-by: Masahiro Yamada 
---

 arch/arm64/include/uapi/asm/stat.h | 17 -
 1 file changed, 17 deletions(-)
 delete mode 100644 arch/arm64/include/uapi/asm/stat.h

diff --git a/arch/arm64/include/uapi/asm/stat.h 
b/arch/arm64/include/uapi/asm/stat.h
deleted file mode 100644
index 313325fa22fa..
--- a/arch/arm64/include/uapi/asm/stat.h
+++ /dev/null
@@ -1,17 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * Copyright (C) 2012 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
- */
-#include 
-- 
2.17.1



Applied "ASoC: rt5665: Fix a typo in the name of a function" to the asoc tree

2019-07-23 Thread Mark Brown
The patch

   ASoC: rt5665: Fix a typo in the name of a function

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From f90aa354be7bffaec2b440eb1831c429ecb1a5e2 Mon Sep 17 00:00:00 2001
From: Christophe JAILLET 
Date: Mon, 22 Jul 2019 23:26:39 +0200
Subject: [PATCH] ASoC: rt5665: Fix a typo in the name of a function

All function names start with rt5665_, except 'rt5655_set_verf()'.
It is likely a typo.

Fix it to be consistent.

Signed-off-by: Christophe JAILLET 
Link: 
https://lore.kernel.org/r/20190722212639.26954-1-christophe.jail...@wanadoo.fr
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/rt5665.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/codecs/rt5665.c b/sound/soc/codecs/rt5665.c
index c050d84a6916..68299ce26d3e 100644
--- a/sound/soc/codecs/rt5665.c
+++ b/sound/soc/codecs/rt5665.c
@@ -2566,7 +2566,7 @@ static int set_dmic_power(struct snd_soc_dapm_widget *w,
return 0;
 }
 
-static int rt5655_set_verf(struct snd_soc_dapm_widget *w,
+static int rt5665_set_verf(struct snd_soc_dapm_widget *w,
struct snd_kcontrol *kcontrol, int event)
 {
struct snd_soc_component *component = 
snd_soc_dapm_to_component(w->dapm);
@@ -2686,11 +2686,11 @@ static const struct snd_soc_dapm_widget 
rt5665_dapm_widgets[] = {
SND_SOC_DAPM_SUPPLY("Mic Det Power", RT5665_PWR_VOL,
RT5665_PWR_MIC_DET_BIT, 0, NULL, 0),
SND_SOC_DAPM_SUPPLY("Vref1", RT5665_PWR_ANLG_1, RT5665_PWR_VREF1_BIT, 0,
-   rt5655_set_verf, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU),
+   rt5665_set_verf, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU),
SND_SOC_DAPM_SUPPLY("Vref2", RT5665_PWR_ANLG_1, RT5665_PWR_VREF2_BIT, 0,
-   rt5655_set_verf, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU),
+   rt5665_set_verf, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU),
SND_SOC_DAPM_SUPPLY("Vref3", RT5665_PWR_ANLG_1, RT5665_PWR_VREF3_BIT, 0,
-   rt5655_set_verf, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU),
+   rt5665_set_verf, SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_POST_PMU),
 
/* ASRC */
SND_SOC_DAPM_SUPPLY_S("I2S1 ASRC", 1, RT5665_ASRC_1,
-- 
2.20.1



Applied "regulator: stm32-booster: Remove .min_uV and .list_voltage for fixed regulator" to the regulator tree

2019-07-23 Thread Mark Brown
The patch

   regulator: stm32-booster: Remove .min_uV and .list_voltage for fixed 
regulator

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 03b77f0b8587a9a0f9d2f1503da3d120aa6fe730 Mon Sep 17 00:00:00 2001
From: Axel Lin 
Date: Tue, 23 Jul 2019 09:41:02 +0800
Subject: [PATCH] regulator: stm32-booster: Remove .min_uV and .list_voltage
 for fixed regulator

Setting .n_voltages = 1 and .fixed_uV is enough for fixed regulator,
remove the redundant .min_uV and .list_voltage settings.

Signed-off-by: Axel Lin 
Acked-by: Fabrice Gasnier 
Link: https://lore.kernel.org/r/20190723014102.25103-1-axel@ingics.com
Signed-off-by: Mark Brown 
---
 drivers/regulator/stm32-booster.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/regulator/stm32-booster.c 
b/drivers/regulator/stm32-booster.c
index 2a897666c650..03f162ffd144 100644
--- a/drivers/regulator/stm32-booster.c
+++ b/drivers/regulator/stm32-booster.c
@@ -20,7 +20,6 @@
 #define STM32MP1_SYSCFG_EN_BOOSTER_MASKBIT(8)
 
 static const struct regulator_ops stm32h7_booster_ops = {
-   .list_voltage   = regulator_list_voltage_linear,
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
@@ -31,7 +30,6 @@ static const struct regulator_desc stm32h7_booster_desc = {
.supply_name = "vdda",
.n_voltages = 1,
.type = REGULATOR_VOLTAGE,
-   .min_uV = 330,
.fixed_uV = 330,
.ramp_delay = 66000, /* up to 50us to stabilize */
.ops = _booster_ops,
@@ -53,7 +51,6 @@ static int stm32mp1_booster_disable(struct regulator_dev 
*rdev)
 }
 
 static const struct regulator_ops stm32mp1_booster_ops = {
-   .list_voltage   = regulator_list_voltage_linear,
.enable = stm32mp1_booster_enable,
.disable= stm32mp1_booster_disable,
.is_enabled = regulator_is_enabled_regmap,
@@ -64,7 +61,6 @@ static const struct regulator_desc stm32mp1_booster_desc = {
.supply_name = "vdda",
.n_voltages = 1,
.type = REGULATOR_VOLTAGE,
-   .min_uV = 330,
.fixed_uV = 330,
.ramp_delay = 66000,
.ops = _booster_ops,
-- 
2.20.1



Re: [PATCH v3 2/2] Input: soc_button_array - Add support for newer surface devices

2019-07-23 Thread Maximilian Luz

On 7/22/19 10:00 AM, Enrico Weigelt, metux IT consult wrote:

On 20.07.19 17:05, Maximilian Luz wrote:

Power and volume button support for 5th and 6th generation Microsoft
Surface devices via soc_button_array.

Note that these devices use the same MSHW0040 device as on the Surface
Pro 4, however the implementation is different (GPIOs vs. ACPI
notifications). Thus some checking is required to ensure we only load
this driver on the correct devices.


Could this also used on the older (pre pro4) devices (also using the
gpios directly, and leave off acpi notifications) ?


As far as I can tell, no. The Pro 4 and Pro 3 don't have any GPIOs on
MSHW0028/MSHW0040. Book 1 has GPIOs but for a different purpose. The Pro
2 has a standard PNP0C0C power button (no idea how the volume buttons
are handled there, but also seems to be different from what I can gather
from DSDT). I can't say anything for the Pro 1 and non-Pro devices.

Maximilian


Applied "ASoC: pcm3168a: Fix a typo in the name of a constant" to the asoc tree

2019-07-23 Thread Mark Brown
The patch

   ASoC: pcm3168a: Fix a typo in the name of a constant

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From f8f85216f8d309daadb37aba8a4b0826783d8747 Mon Sep 17 00:00:00 2001
From: Christophe JAILLET 
Date: Mon, 22 Jul 2019 23:15:28 +0200
Subject: [PATCH] ASoC: pcm3168a: Fix a typo in the name of a constant

There is a typo in PCM1368A_MAX_SYSCLK, it should be PCM3168A_MAX_SYSCLK
(1 and 3 switched in 3168)

Signed-off-by: Christophe JAILLET 
Link: 
https://lore.kernel.org/r/20190722211528.26600-1-christophe.jail...@wanadoo.fr
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/pcm3168a.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/pcm3168a.c b/sound/soc/codecs/pcm3168a.c
index f1104d7d6426..5d59ce254821 100644
--- a/sound/soc/codecs/pcm3168a.c
+++ b/sound/soc/codecs/pcm3168a.c
@@ -263,7 +263,7 @@ static unsigned int pcm3168a_scki_ratios[] = {
 #define PCM3168A_NUM_SCKI_RATIOS_DAC   ARRAY_SIZE(pcm3168a_scki_ratios)
 #define PCM3168A_NUM_SCKI_RATIOS_ADC   (ARRAY_SIZE(pcm3168a_scki_ratios) - 2)
 
-#define PCM1368A_MAX_SYSCLK36864000
+#define PCM3168A_MAX_SYSCLK36864000
 
 static int pcm3168a_reset(struct pcm3168a_priv *pcm3168a)
 {
@@ -296,7 +296,7 @@ static int pcm3168a_set_dai_sysclk(struct snd_soc_dai *dai,
struct pcm3168a_priv *pcm3168a = 
snd_soc_component_get_drvdata(dai->component);
int ret;
 
-   if (freq > PCM1368A_MAX_SYSCLK)
+   if (freq > PCM3168A_MAX_SYSCLK)
return -EINVAL;
 
ret = clk_set_rate(pcm3168a->scki, freq);
-- 
2.20.1



Applied "ASoC: fsl_esai: recover the channel swap after xrun" to the asoc tree

2019-07-23 Thread Mark Brown
The patch

   ASoC: fsl_esai: recover the channel swap after xrun

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-5.4

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 7ccafa2b3879612ab9ed88bb6664bd4085957186 Mon Sep 17 00:00:00 2001
From: Shengjiu Wang 
Date: Thu, 11 Jul 2019 18:49:46 +0800
Subject: [PATCH] ASoC: fsl_esai: recover the channel swap after xrun

There is chip errata ERR008000, the reference doc is
(https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf),

The issue is "While using ESAI transmit or receive and
an underrun/overrun happens, channel swap may occur.
The only recovery mechanism is to reset the ESAI."

This issue exist in imx3/imx5/imx6(partial) series.

In this commit add a tasklet to handle reset of ESAI
after xrun happens to recover the channel swap.

Signed-off-by: Shengjiu Wang 
Acked-by: Nicolin Chen 
Link: 
https://lore.kernel.org/r/326035cb99975361699d9ed748054b08bc06a341.1562842206.git.shengjiu.w...@nxp.com
Signed-off-by: Mark Brown 
---
 sound/soc/fsl/fsl_esai.c | 74 
 1 file changed, 74 insertions(+)

diff --git a/sound/soc/fsl/fsl_esai.c b/sound/soc/fsl/fsl_esai.c
index ab460d6d7432..4ce8ac769244 100644
--- a/sound/soc/fsl/fsl_esai.c
+++ b/sound/soc/fsl/fsl_esai.c
@@ -32,6 +32,7 @@
  * @extalclk: esai clock source to derive HCK, SCK and FS
  * @fsysclk: system clock source to derive HCK, SCK and FS
  * @spbaclk: SPBA clock (optional, depending on SoC design)
+ * @task: tasklet to handle the reset operation
  * @fifo_depth: depth of tx/rx FIFO
  * @slot_width: width of each DAI slot
  * @slots: number of slots
@@ -42,6 +43,7 @@
  * @sck_div: if using PSR/PM dividers for SCKx clock
  * @slave_mode: if fully using DAI slave mode
  * @synchronous: if using tx/rx synchronous mode
+ * @reset_at_xrun: flags for enable reset operaton
  * @name: driver name
  */
 struct fsl_esai {
@@ -53,6 +55,7 @@ struct fsl_esai {
struct clk *extalclk;
struct clk *fsysclk;
struct clk *spbaclk;
+   struct tasklet_struct task;
u32 fifo_depth;
u32 slot_width;
u32 slots;
@@ -65,6 +68,7 @@ struct fsl_esai {
bool sck_div[2];
bool slave_mode;
bool synchronous;
+   bool reset_at_xrun;
char name[32];
 };
 
@@ -73,8 +77,16 @@ static irqreturn_t esai_isr(int irq, void *devid)
struct fsl_esai *esai_priv = (struct fsl_esai *)devid;
struct platform_device *pdev = esai_priv->pdev;
u32 esr;
+   u32 saisr;
 
regmap_read(esai_priv->regmap, REG_ESAI_ESR, );
+   regmap_read(esai_priv->regmap, REG_ESAI_SAISR, );
+
+   if ((saisr & (ESAI_SAISR_TUE | ESAI_SAISR_ROE)) &&
+   esai_priv->reset_at_xrun) {
+   dev_dbg(>dev, "reset module for xrun\n");
+   tasklet_schedule(_priv->task);
+   }
 
if (esr & ESAI_ESR_TINIT_MASK)
dev_dbg(>dev, "isr: Transmission Initialized\n");
@@ -635,10 +647,17 @@ static void fsl_esai_trigger_start(struct fsl_esai 
*esai_priv, bool tx)
   ESAI_xSMB_xS_MASK, ESAI_xSMB_xS(mask));
regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
   ESAI_xSMA_xS_MASK, ESAI_xSMA_xS(mask));
+
+   /* Enable Exception interrupt */
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+  ESAI_xCR_xEIE_MASK, ESAI_xCR_xEIE);
 }
 
 static void fsl_esai_trigger_stop(struct fsl_esai *esai_priv, bool tx)
 {
+   regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
+  ESAI_xCR_xEIE_MASK, 0);
+
regmap_update_bits(esai_priv->regmap, REG_ESAI_xCR(tx),
   tx ? ESAI_xCR_TE_MASK : ESAI_xCR_RE_MASK, 0);
regmap_update_bits(esai_priv->regmap, REG_ESAI_xSMA(tx),
@@ -653,6 +672,51 @@ static void fsl_esai_trigger_stop(struct fsl_esai 
*esai_priv, bool tx)
   ESAI_xFCR_xFR, 0);
 }
 
+static void fsl_esai_hw_reset(unsigned long arg)
+{
+   struct fsl_esai *esai_priv = (struct fsl_esai *)arg;
+   bool tx = true, rx = false, enabled[2];
+   u32 tfcr, rfcr;
+
+   /* Save the registers */
+   regmap_read(esai_priv->regmap, 

Applied "regulator: act8865: Add support for act8600 charger" to the regulator tree

2019-07-23 Thread Mark Brown
The patch

   regulator: act8865: Add support for act8600 charger

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 2d09a79bf637f91d1bbfcfd4520e3639dd15897c Mon Sep 17 00:00:00 2001
From: Maarten ter Huurne 
Date: Mon, 22 Jul 2019 21:14:18 -0400
Subject: [PATCH] regulator: act8865: Add support for act8600 charger

This provides a way to monitor battery charge status via the power
supply subsystem.

Signed-off-by: Maarten ter Huurne 
Signed-off-by: Paul Cercueil 
Link: https://lore.kernel.org/r/20190723011418.29143-1-p...@crapouillou.net
Signed-off-by: Mark Brown 
---
 drivers/regulator/act8865-regulator.c | 84 +++
 1 file changed, 84 insertions(+)

diff --git a/drivers/regulator/act8865-regulator.c 
b/drivers/regulator/act8865-regulator.c
index cf72d7c6b8c9..e63285de485d 100644
--- a/drivers/regulator/act8865-regulator.c
+++ b/drivers/regulator/act8865-regulator.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -118,6 +119,11 @@
 #define ACT8600_LDO10_ENA  0x40/* ON - [6] */
 #define ACT8600_SUDCDC_VSEL_MASK   0xFF/* SUDCDC VSET - [7:0] */
 
+#define ACT8600_APCH_CHG_ACIN  BIT(7)
+#define ACT8600_APCH_CHG_USB   BIT(6)
+#define ACT8600_APCH_CSTATE0   BIT(5)
+#define ACT8600_APCH_CSTATE1   BIT(4)
+
 /*
  * ACT8865 voltage number
  */
@@ -372,6 +378,75 @@ static void act8865_power_off(void)
while (1);
 }
 
+static int act8600_charger_get_status(struct regmap *map)
+{
+   unsigned int val;
+   int ret;
+   u8 state0, state1;
+
+   ret = regmap_read(map, ACT8600_APCH_STAT, );
+   if (ret < 0)
+   return ret;
+
+   state0 = val & ACT8600_APCH_CSTATE0;
+   state1 = val & ACT8600_APCH_CSTATE1;
+
+   if (state0 && !state1)
+   return POWER_SUPPLY_STATUS_CHARGING;
+   if (!state0 && state1)
+   return POWER_SUPPLY_STATUS_NOT_CHARGING;
+   if (!state0 && !state1)
+   return POWER_SUPPLY_STATUS_DISCHARGING;
+
+   return POWER_SUPPLY_STATUS_UNKNOWN;
+}
+
+static int act8600_charger_get_property(struct power_supply *psy,
+   enum power_supply_property psp, union power_supply_propval *val)
+{
+   struct regmap *map = power_supply_get_drvdata(psy);
+   int ret;
+
+   switch (psp) {
+   case POWER_SUPPLY_PROP_STATUS:
+   ret = act8600_charger_get_status(map);
+   if (ret < 0)
+   return ret;
+
+   val->intval = ret;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static enum power_supply_property act8600_charger_properties[] = {
+   POWER_SUPPLY_PROP_STATUS,
+};
+
+static const struct power_supply_desc act8600_charger_desc = {
+   .name = "act8600-charger",
+   .type = POWER_SUPPLY_TYPE_BATTERY,
+   .properties = act8600_charger_properties,
+   .num_properties = ARRAY_SIZE(act8600_charger_properties),
+   .get_property = act8600_charger_get_property,
+};
+
+static int act8600_charger_probe(struct device *dev, struct regmap *regmap)
+{
+   struct power_supply *charger;
+   struct power_supply_config cfg = {
+   .drv_data = regmap,
+   .of_node = dev->of_node,
+   };
+
+   charger = devm_power_supply_register(dev, _charger_desc, );
+
+   return IS_ERR(charger) ? PTR_ERR(charger) : 0;
+}
+
 static int act8865_pmic_probe(struct i2c_client *client,
  const struct i2c_device_id *i2c_id)
 {
@@ -483,6 +558,15 @@ static int act8865_pmic_probe(struct i2c_client *client,
}
}
 
+   if (type == ACT8600) {
+   ret = act8600_charger_probe(dev, act8865->regmap);
+   if (ret < 0) {
+   if (ret != -EPROBE_DEFER)
+   dev_err(dev, "Failed to probe charger");
+   return ret;
+   }
+   }
+
i2c_set_clientdata(client, act8865);
 
return 0;
-- 
2.20.1



Re: [PATCH] [net-next] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param

2019-07-23 Thread Arnd Bergmann
On Tue, Jul 23, 2019 at 1:21 PM Maxim Mikityanskiy  wrote:
> On 2019-07-08 18:16, Maxim Mikityanskiy wrote:
> > On 2019-07-08 15:55, Arnd Bergmann wrote:
> >> -mlx5e_build_xsk_cparam(priv, params, xsk, );
> >> +cparam = kzalloc(sizeof(*cparam), GFP_KERNEL);
> >
> > Similar code in mlx5e_open_channels (en_main.c) uses kvzalloc. Although
> > the struct is currently smaller than a page anyway, and there should be
> > no difference in behavior now, I suggest using the same alloc function
> > to keep code uniform.
> >
> >>  /* Create a dedicated SQ for posting NOPs whenever we need an IRQ to 
> >> be
> >>   * triggered and NAPI to be called on the correct CPU.
> >>   */
> >> -err = mlx5e_open_icosq(c, params, , >xskicosq);
> >> +err = mlx5e_open_icosq(c, params, >icosq, >xskicosq);
> >>  if (unlikely(err))
> >>  goto err_close_icocq;
> >>
> >
> > Here is kfree missing. It's a memory leak in the good path.
>
> Arnd, I'm going to take over your patch and respin it, addressing my own
> comments, because it's been quite a while, and we want to have this fix.
>
> Thanks for spotting it.

Thanks for taking care of it now. I was planning to do a respin, but
the reply got lost in the depth of my inbox so I forgot about it.

  Arnd


[PATCH 8/8] ARM: dts: Fix lcdc sysc flags for am3

2019-07-23 Thread Tony Lindgren
The LCDC controller on am335x has a sysconfig register without a
SOFTRESET bit. Let's configure that by setting ti,sysc-mask = <0>
as otherwise we get the following warning:

ti-sysc 4830e000.target-module: idlemodes 0087 != 0007

And the legacy platform data has LCDC midle unconfigured so let's
remove that property.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/am33xx-l4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -2038,7 +2038,7 @@
reg = <0xe000 0x4>,
  <0xe054 0x4>;
reg-names = "rev", "sysc";
-   ti,sysc-midle ;
+   ti,sysc-mask = <0>;
ti,sysc-sidle = ,
,
;
-- 
2.21.0


[PATCH 7/8] ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7

2019-07-23 Thread Tony Lindgren
We are currently using a wrong register for dcan revision. Although
this is currently only used for detecting the dcan module, let's
fix it to avoid confusion.

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/am33xx-l4.dtsi | 4 
 arch/arm/boot/dts/am437x-l4.dtsi | 4 
 arch/arm/boot/dts/dra7-l4.dtsi   | 4 ++--
 drivers/bus/ti-sysc.c| 3 ++-
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/am33xx-l4.dtsi b/arch/arm/boot/dts/am33xx-l4.dtsi
--- a/arch/arm/boot/dts/am33xx-l4.dtsi
+++ b/arch/arm/boot/dts/am33xx-l4.dtsi
@@ -1758,6 +1758,8 @@
 
target-module@cc000 {   /* 0x481cc000, ap 60 
46.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
+   reg = <0xcc020 0x4>;
+   reg-names = "rev";
ti,hwmods = "d_can0";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <_clkctrl AM3_L4LS_D_CAN0_CLKCTRL 0>,
@@ -1780,6 +1782,8 @@
 
target-module@d {   /* 0x481d, ap 62 
42.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
+   reg = <0xd0020 0x4>;
+   reg-names = "rev";
ti,hwmods = "d_can1";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <_clkctrl AM3_L4LS_D_CAN1_CLKCTRL 0>,
diff --git a/arch/arm/boot/dts/am437x-l4.dtsi b/arch/arm/boot/dts/am437x-l4.dtsi
--- a/arch/arm/boot/dts/am437x-l4.dtsi
+++ b/arch/arm/boot/dts/am437x-l4.dtsi
@@ -1574,6 +1574,8 @@
 
target-module@cc000 {   /* 0x481cc000, ap 50 
46.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
+   reg = <0xcc020 0x4>;
+   reg-names = "rev";
ti,hwmods = "d_can0";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <_clkctrl AM4_L4LS_D_CAN0_CLKCTRL 0>;
@@ -1593,6 +1595,8 @@
 
target-module@d {   /* 0x481d, ap 52 
3a.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
+   reg = <0xd0020 0x4>;
+   reg-names = "rev";
ti,hwmods = "d_can1";
/* Domains (P, C): per_pwrdm, l4ls_clkdm */
clocks = <_clkctrl AM4_L4LS_D_CAN1_CLKCTRL 0>;
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -3020,7 +3020,7 @@
 
target-module@8 {   /* 0x4848, ap 31 
16.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
-   reg = <0x8 0x4>;
+   reg = <0x80020 0x4>;
reg-names = "rev";
clocks = <_clkctrl DRA7_L4PER2_DCAN2_CLKCTRL 0>;
clock-names = "fck";
@@ -4572,7 +4572,7 @@
 
target-module@c000 {/* 0x4ae3c000, ap 30 
04.0 */
compatible = "ti,sysc-omap4", "ti,sysc";
-   reg = <0xc000 0x4>;
+   reg = <0xc020 0x4>;
reg-names = "rev";
clocks = <_clkctrl DRA7_WKUPAON_DCAN1_CLKCTRL 
0>;
clock-names = "fck";
diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1267,7 +1267,8 @@ static const struct sysc_revision_quirk 
sysc_revision_quirks[] = {
SYSC_QUIRK("control", 0, 0, 0x10, -1, 0x4900, 0x, 0),
SYSC_QUIRK("cpgmac", 0, 0x1200, 0x1208, 0x1204, 0x4edb1902,
   0x00f0, 0),
-   SYSC_QUIRK("dcan", 0, 0, -1, -1, 0x, 0x, 0),
+   SYSC_QUIRK("dcan", 0, 0x20, -1, -1, 0xa3170504, 0x, 0),
+   SYSC_QUIRK("dcan", 0, 0x20, -1, -1, 0x4edb1902, 0x, 0),
SYSC_QUIRK("dmic", 0, 0, 0x10, -1, 0x5001, 0x, 0),
SYSC_QUIRK("dwc3", 0, 0, 0x10, -1, 0x500a0200, 0x, 0),
SYSC_QUIRK("epwmss", 0, 0, 0x4, -1, 0x4741, 0x, 0),
-- 
2.21.0


[PATCH 6/8] ARM: dts: Fix flags for gpio7

2019-07-23 Thread Tony Lindgren
The ti,no-idle-on-init and ti,no-reset-on-init flags need to be at
the interconnect target module level for the modules that have it
defined. Otherwise we get the following warnings:

dts flag should be at module level for ti,no-idle-on-init
dts flag should be at module level for ti,no-reset-on-init

Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi | 2 +-
 arch/arm/boot/dts/dra7-evm.dts  | 2 +-
 arch/arm/boot/dts/dra7-l4.dtsi  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -379,7 +379,7 @@
};
 };
 
- {
+_target {
ti,no-reset-on-init;
ti,no-idle-on-init;
 };
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -498,7 +498,7 @@
phy-supply = <_reg>;
 };
 
- {
+_target {
ti,no-reset-on-init;
ti,no-idle-on-init;
 };
diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -1261,7 +1261,7 @@
};
};
 
-   target-module@51000 {   /* 0x48051000, ap 45 
2e.0 */
+   gpio7_target: target-module@51000 { /* 0x48051000, 
ap 45 2e.0 */
compatible = "ti,sysc-omap2", "ti,sysc";
ti,hwmods = "gpio7";
reg = <0x51000 0x4>,
-- 
2.21.0


[PATCH 0/8] ti-sysc related warning fixes for v5.3-rc cycle

2019-07-23 Thread Tony Lindgren
Hi all,

I noticed that with recent ti-sysc driver changes some new warnings
have crept in. Mostly they are caused by having different configuration
in the dts compared to the legacy platform data. Let's fix these first
before we continue dropping the legacy platform data.

I also noticed we need two fixes for the ti-sysc driver while looking
at the warnings.

Regards,

Tony

Tony Lindgren (8):
  ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss
  ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc
  bus: ti-sysc: Fix handling of forced idle
  bus: ti-sysc: Fix using configured sysc mask value
  ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8
  ARM: dts: Fix flags for gpio7
  ARM: dts: Fix incorrect dcan register mapping for am3, am4 and dra7
  ARM: dts: Fix lcdc sysc flags for am3

 arch/arm/boot/dts/am33xx-l4.dtsi  |  6 +++-
 arch/arm/boot/dts/am437x-l4.dtsi  |  4 +++
 .../boot/dts/am57xx-beagle-x15-common.dtsi|  2 +-
 arch/arm/boot/dts/dra7-evm.dts|  2 +-
 arch/arm/boot/dts/dra7-l4.dtsi| 31 ---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c|  2 +-
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |  3 +-
 drivers/bus/ti-sysc.c | 10 +++---
 8 files changed, 31 insertions(+), 29 deletions(-)

-- 
2.21.0


[PATCH 1/8] ARM: OMAP2+: Fix missing SYSC_HAS_RESET_STATUS for dra7 epwmss

2019-07-23 Thread Tony Lindgren
TRM says PWMSS_SYSCONFIG bit for SOFTRESET changes to zero when
reset is completed. Let's configure it as otherwise we get warnings
on boot when we check the data against dts provided data. Eventually
the legacy platform data will be just dropped, but let's fix the
warning first.

Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -379,7 +379,8 @@ static struct omap_hwmod dra7xx_dcan2_hwmod = {
 static struct omap_hwmod_class_sysconfig dra7xx_epwmss_sysc = {
.rev_offs   = 0x0,
.sysc_offs  = 0x4,
-   .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET,
+   .sysc_flags = SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_RESET_STATUS,
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= _hwmod_sysc_type2,
 };
-- 
2.21.0


[PATCH 2/8] ARM: OMAP2+: Remove unconfigured midlemode for am3 lcdc

2019-07-23 Thread Tony Lindgren
We currently get a warning for lcdc because of a difference
with dts provided configuration compared to the legacy platform
data. This is because lcdc has SYSC_HAS_MIDLEMODE configured in
the platform data without configuring the modes.

Let's fix the warning by removing SYSC_HAS_MIDLEMODE. Note that
the am335x TRM lists SYSC_HAS_MIDLEMODE, but it is unused.

Signed-off-by: Tony Lindgren 
---
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c 
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -231,7 +231,7 @@ static struct omap_hwmod am33xx_control_hwmod = {
 static struct omap_hwmod_class_sysconfig lcdc_sysc = {
.rev_offs   = 0x0,
.sysc_offs  = 0x54,
-   .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+   .sysc_flags = SYSC_HAS_SIDLEMODE,
.idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
.sysc_fields= _hwmod_sysc_type2,
 };
-- 
2.21.0


[PATCH 4/8] bus: ti-sysc: Fix using configured sysc mask value

2019-07-23 Thread Tony Lindgren
We have cases where there are no softreset bits like with am335x lcdc.
In that case ti,sysc-mask = <0> needs to be handled properly.

Signed-off-by: Tony Lindgren 
---
 drivers/bus/ti-sysc.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -1692,10 +1692,7 @@ static int sysc_init_sysc_mask(struct sysc *ddata)
if (error)
return 0;
 
-   if (val)
-   ddata->cfg.sysc_val = val & ddata->cap->sysc_mask;
-   else
-   ddata->cfg.sysc_val = ddata->cap->sysc_mask;
+   ddata->cfg.sysc_val = val & ddata->cap->sysc_mask;
 
return 0;
 }
-- 
2.21.0


[PATCH] x86/build: remove unneeded uapi asm-generic wrappers

2019-07-23 Thread Masahiro Yamada
These are listed in include/uapi/asm-generic/Kbuild, so Kbuild will
automatically generate them.

Signed-off-by: Masahiro Yamada 
---

 arch/x86/include/uapi/asm/errno.h| 1 -
 arch/x86/include/uapi/asm/fcntl.h| 1 -
 arch/x86/include/uapi/asm/ioctl.h| 1 -
 arch/x86/include/uapi/asm/ioctls.h   | 1 -
 arch/x86/include/uapi/asm/ipcbuf.h   | 1 -
 arch/x86/include/uapi/asm/param.h| 1 -
 arch/x86/include/uapi/asm/resource.h | 1 -
 arch/x86/include/uapi/asm/termbits.h | 1 -
 arch/x86/include/uapi/asm/termios.h  | 1 -
 arch/x86/include/uapi/asm/types.h| 7 ---
 10 files changed, 16 deletions(-)
 delete mode 100644 arch/x86/include/uapi/asm/errno.h
 delete mode 100644 arch/x86/include/uapi/asm/fcntl.h
 delete mode 100644 arch/x86/include/uapi/asm/ioctl.h
 delete mode 100644 arch/x86/include/uapi/asm/ioctls.h
 delete mode 100644 arch/x86/include/uapi/asm/ipcbuf.h
 delete mode 100644 arch/x86/include/uapi/asm/param.h
 delete mode 100644 arch/x86/include/uapi/asm/resource.h
 delete mode 100644 arch/x86/include/uapi/asm/termbits.h
 delete mode 100644 arch/x86/include/uapi/asm/termios.h
 delete mode 100644 arch/x86/include/uapi/asm/types.h

diff --git a/arch/x86/include/uapi/asm/errno.h 
b/arch/x86/include/uapi/asm/errno.h
deleted file mode 100644
index 4c82b503d92f..
--- a/arch/x86/include/uapi/asm/errno.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/fcntl.h 
b/arch/x86/include/uapi/asm/fcntl.h
deleted file mode 100644
index 46ab12db5739..
--- a/arch/x86/include/uapi/asm/fcntl.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/ioctl.h 
b/arch/x86/include/uapi/asm/ioctl.h
deleted file mode 100644
index b279fe06dfe5..
--- a/arch/x86/include/uapi/asm/ioctl.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/ioctls.h 
b/arch/x86/include/uapi/asm/ioctls.h
deleted file mode 100644
index ec34c760665e..
--- a/arch/x86/include/uapi/asm/ioctls.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/ipcbuf.h 
b/arch/x86/include/uapi/asm/ipcbuf.h
deleted file mode 100644
index 84c7e51cb6d0..
--- a/arch/x86/include/uapi/asm/ipcbuf.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/param.h 
b/arch/x86/include/uapi/asm/param.h
deleted file mode 100644
index 965d45427975..
--- a/arch/x86/include/uapi/asm/param.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/resource.h 
b/arch/x86/include/uapi/asm/resource.h
deleted file mode 100644
index 04bc4db8921b..
--- a/arch/x86/include/uapi/asm/resource.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/termbits.h 
b/arch/x86/include/uapi/asm/termbits.h
deleted file mode 100644
index 3935b106de79..
--- a/arch/x86/include/uapi/asm/termbits.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/termios.h 
b/arch/x86/include/uapi/asm/termios.h
deleted file mode 100644
index 280d78a9d966..
--- a/arch/x86/include/uapi/asm/termios.h
+++ /dev/null
@@ -1 +0,0 @@
-#include 
diff --git a/arch/x86/include/uapi/asm/types.h 
b/arch/x86/include/uapi/asm/types.h
deleted file mode 100644
index 9d5c11a24279..
--- a/arch/x86/include/uapi/asm/types.h
+++ /dev/null
@@ -1,7 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _ASM_X86_TYPES_H
-#define _ASM_X86_TYPES_H
-
-#include 
-
-#endif /* _ASM_X86_TYPES_H */
-- 
2.17.1



[PATCH 5/8] ARM: dts: Drop bogus ahclkr clocks for dra7 mcasp 3 to 8

2019-07-23 Thread Tony Lindgren
The ahclkr clkctrl clock bit 28 only exists for mcasp 1 and 2 on dra7.
Otherwise we get the following warning on beagle-x15:

ti-sysc 48468000.target-module: could not add child clock ahclkr: -19

Fixes: 5241ccbf2819 ("ARM: dts: Add missing ranges for dra7 mcasp l3 ports")
Signed-off-by: Tony Lindgren 
---
 arch/arm/boot/dts/dra7-l4.dtsi | 25 ++---
 1 file changed, 10 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-l4.dtsi b/arch/arm/boot/dts/dra7-l4.dtsi
--- a/arch/arm/boot/dts/dra7-l4.dtsi
+++ b/arch/arm/boot/dts/dra7-l4.dtsi
@@ -2818,9 +2818,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 0>,
-<_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 
24>,
-<_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 
28>;
-   clock-names = "fck", "ahclkx", "ahclkr";
+<_clkctrl DRA7_L4PER2_MCASP3_CLKCTRL 
24>;
+   clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x68000 0x2000>,
@@ -2854,9 +2853,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 0>,
-<_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 
24>,
-<_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 
28>;
-   clock-names = "fck", "ahclkx", "ahclkr";
+<_clkctrl DRA7_L4PER2_MCASP4_CLKCTRL 
24>;
+   clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x6c000 0x2000>,
@@ -2890,9 +2888,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 0>,
-<_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 
24>,
-<_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 
28>;
-   clock-names = "fck", "ahclkx", "ahclkr";
+<_clkctrl DRA7_L4PER2_MCASP5_CLKCTRL 
24>;
+   clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x7 0x2000>,
@@ -2926,9 +2923,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 0>,
-<_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 
24>,
-<_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 
28>;
-   clock-names = "fck", "ahclkx", "ahclkr";
+<_clkctrl DRA7_L4PER2_MCASP6_CLKCTRL 
24>;
+   clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x74000 0x2000>,
@@ -2962,9 +2958,8 @@
;
/* Domains (P, C): l4per_pwrdm, l4per2_clkdm */
clocks = <_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 0>,
-<_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 
24>,
-<_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 
28>;
-   clock-names = "fck", "ahclkx", "ahclkr";
+<_clkctrl DRA7_L4PER2_MCASP7_CLKCTRL 
24>;
+   clock-names = "fck", "ahclkx";
#address-cells = <1>;
#size-cells = <1>;
ranges = <0x0 0x78000 0x2000>,
-- 
2.21.0


[PATCH 3/8] bus: ti-sysc: Fix handling of forced idle

2019-07-23 Thread Tony Lindgren
For some devices we can get the following warning on boot:

ti-sysc 48485200.target-module: sysc_disable_module: invalid midlemode

Fix this by treating SYSC_IDLE_FORCE like we do for the other bits
for idlemodes mask.

Fixes: d59b60564cbf ("bus: ti-sysc: Add generic enable/disable functions")
Cc: Roger Quadros 
Signed-off-by: Tony Lindgren 
---
 drivers/bus/ti-sysc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bus/ti-sysc.c b/drivers/bus/ti-sysc.c
--- a/drivers/bus/ti-sysc.c
+++ b/drivers/bus/ti-sysc.c
@@ -949,7 +949,7 @@ static int sysc_best_idle_mode(u32 idlemodes, u32 
*best_mode)
*best_mode = SYSC_IDLE_SMART_WKUP;
else if (idlemodes & BIT(SYSC_IDLE_SMART))
*best_mode = SYSC_IDLE_SMART;
-   else if (idlemodes & SYSC_IDLE_FORCE)
+   else if (idlemodes & BIT(SYSC_IDLE_FORCE))
*best_mode = SYSC_IDLE_FORCE;
else
return -EINVAL;
-- 
2.21.0


Re: [PATCH RFT] regulator: lp87565: Fix probe failure for "ti,lp87565"

2019-07-23 Thread Mark Brown
On Thu, Jul 11, 2019 at 07:35:17PM +0800, Axel Lin wrote:
> The "ti,lp87565" compatible string is still in of_lp87565_match_table,
> but current code will return -EINVAL because lp87565->dev_type is unknown.
> This was working in earlier kernel versions, so fix it.

This doesn't seem to apply against current code, please check and
resend.


signature.asc
Description: PGP signature


RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool

2019-07-23 Thread Jose Abreu
From: Robin Murphy 
Date: Jul/23/2019, 11:29:28 (UTC+00:00)

> On 23/07/2019 11:07, Jose Abreu wrote:
> > From: Jon Hunter 
> > Date: Jul/23/2019, 11:01:24 (UTC+00:00)
> > 
> >> This appears to be a winner and by disabling the SMMU for the ethernet
> >> controller and reverting commit 954a03be033c7cef80ddc232e7cbdb17df735663
> >> this worked! So yes appears to be related to the SMMU being enabled. We
> >> had to enable the SMMU for ethernet recently due to commit
> >> 954a03be033c7cef80ddc232e7cbdb17df735663.
> > 
> > Finally :)
> > 
> > However, from "git show 954a03be033c7cef80ddc232e7cbdb17df735663":
> > 
> > + There are few reasons to allow unmatched stream bypass, and
> > + even fewer good ones.  If saying YES here breaks your board
> > + you should work on fixing your board.
> > 
> > So, how can we fix this ? Is your ethernet DT node marked as
> > "dma-coherent;" ?
> 
> The first thing to try would be booting the failing setup with 
> "iommu.passthrough=1" (or using CONFIG_IOMMU_DEFAULT_PASSTHROUGH) - if 
> that makes things seem OK, then the problem is likely related to address 
> translation; if not, then it's probably time to start looking at nasties 
> like coherency and ordering, although in principle I wouldn't expect the 
> SMMU to have too much impact there.
> 
> Do you know if the SMMU interrupts are working correctly? If not, it's 
> possible that an incorrect address or mapping direction could lead to 
> the DMA transaction just being silently terminated without any fault 
> indication, which generally presents as inexplicable weirdness (I've 
> certainly seen that on another platform with the mix of an unsupported 
> interrupt controller and an 'imperfect' ethernet driver).
> 
> Just to confirm, has the original patch been tested with 
> CONFIG_DMA_API_DEBUG to rule out any high-level mishaps?

Yes but both my setups don't have any IOMMU: One is x86 + SWIOTLB and 
another is just coherent regarding CPU.

---
Thanks,
Jose Miguel Abreu


Re: [PATCH] [net-next] net/mlx5e: xsk: dynamically allocate mlx5e_channel_param

2019-07-23 Thread Maxim Mikityanskiy
On 2019-07-08 18:16, Maxim Mikityanskiy wrote:
> On 2019-07-08 15:55, Arnd Bergmann wrote:
>> -mlx5e_build_xsk_cparam(priv, params, xsk, );
>> +cparam = kzalloc(sizeof(*cparam), GFP_KERNEL);
> 
> Similar code in mlx5e_open_channels (en_main.c) uses kvzalloc. Although
> the struct is currently smaller than a page anyway, and there should be
> no difference in behavior now, I suggest using the same alloc function
> to keep code uniform.
> 
>>  /* Create a dedicated SQ for posting NOPs whenever we need an IRQ to be
>>   * triggered and NAPI to be called on the correct CPU.
>>   */
>> -err = mlx5e_open_icosq(c, params, , >xskicosq);
>> +err = mlx5e_open_icosq(c, params, >icosq, >xskicosq);
>>  if (unlikely(err))
>>  goto err_close_icocq;
>>
> 
> Here is kfree missing. It's a memory leak in the good path.

Arnd, I'm going to take over your patch and respin it, addressing my own 
comments, because it's been quite a while, and we want to have this fix.

Thanks for spotting it.


Re: get_maintainers.pl subsystem output

2019-07-23 Thread Joe Perches
On Tue, 2019-07-23 at 10:42 +0200, Lukas Bulwahn wrote:
> On Tue, Jul 23, 2019 at 9:30 AM Duda, Sebastian  wrote:
> > when analyzing the patch
> > `<20150128012747.824898...@linuxfoundation.org>` [1] with
> > `get_maintainers.pl --subsystem --status --separator , /tmp/patch`,
> > there is the following output:
> > 
> >  Chris Mason  (maintainer:BTRFS FILE SYSTEM),Josef Bacik
> >  (maintainer:BTRFS FILE SYSTEM),David Sterba
> >  (maintainer:BTRFS FILE SYSTEM),Alexander Viro
> >  (maintainer:FILESYSTEMS (VFS and
> > infrastructure)),"Theodore Ts'o"  (maintainer:EXT4 FILE
> > SYSTEM),Andreas Dilger  (maintainer:EXT4 FILE
> > SYSTEM),Jaegeuk Kim  (maintainer:F2FS FILE
> > SYSTEM),Changman Lee  (maintainer:F2FS FILE
> > SYSTEM),Miklos Szeredi  (maintainer:FUSE: FILESYSTEM
> > IN USERSPACE),Steven Whitehouse  (supporter:GFS2
> > FILE SYSTEM),Anton Altaparmakov  (supporter:NTFS
> > FILESYSTEM),Hugh Dickins  (maintainer:TMPFS (SHMEM
> > FILESYSTEM)),linux-bt...@vger.kernel.org (open list:BTRFS FILE
> > SYSTEM),linux-kernel@vger.kernel.org (open
> > list),linux-fsde...@vger.kernel.org (open list:FILESYSTEMS (VFS and
> > infrastructure)),linux-e...@vger.kernel.org (open list:EXT4 FILE
> > SYSTEM),linux-f2fs-de...@lists.sourceforge.net (open list:F2FS FILE
> > SYSTEM),fuse-de...@lists.sourceforge.net (open list:FUSE: FILESYSTEM IN
> > USERSPACE),cluster-de...@redhat.com (open list:GFS2 FILE
> > SYSTEM),linux-ntfs-...@lists.sourceforge.net (open list:NTFS
> > FILESYSTEM),linux...@kvack.org (open list:MEMORY MANAGEMENT)
> >  Maintained,Buried alive in reporters,Supported
> >  BTRFS FILE SYSTEM,THE REST,FILESYSTEMS (VFS and infrastructure),EXT4
> > FILE SYSTEM,F2FS FILE SYSTEM,FUSE: FILESYSTEM IN USERSPACE,GFS2 FILE
> > SYSTEM,NTFS FILESYSTEM,MEMORY MANAGEMENT,TMPFS (SHMEM FILESYSTEM)
> > 
> > How can I parse this output automatically? or how can I generate a
> > parsable output?
[]
> > I need the tuples of subsystems and status:
> > (THE REST, Buried alive in reporters)
> > (TMPFS, Maintained)
> > (BTRFS FILE SYSTEM, Maintained)
> > …
> > (GFS2 FILE SYSTEM, Supported)
> > 
> > I'm not aware how to reliably assign the statuses to the subsystems.

Again, run the script using the individual files
contained in a patch
instead of the entire patch.

I again suggest using gnu parallel.

> Joe, I hope this example makes more clear what and how Sebastian would
> actually like to have the information from the MAINTAINERS file
> presented for our use case. Currently, we would consider
> get_maintainer.pl to be the proper place for such a feature in the
> upstream development.

I believe I understand how you want to use
the get_maintainer script output.

> Joe, would you support and would you accept if we extend
> get_maintainer.pl to provide output of the status in such a way that
> the status output can be clearly mapped to the subsystem?

Not really, no.  I don't see much value in your
request to others.  It seems you are doing some
academic work rather than actually using it for
sending patches.

You are of course welcome to extexd the script
in whatever manner you need for your own use,
but even here, I don't believe you need to do
anything to the script but change how you use it.





Re: [PATCH 4.19] kconfig: fix missing choice values in auto.conf

2019-07-23 Thread Greg KH
On Tue, Jul 23, 2019 at 08:09:36PM +0900, Masahiro Yamada wrote:
> commit 8e2442a5f86e1f77b86401fce274a7f622740bc4 upstream.

Now queued up, thanks!

greg k-h


[PATCH] i2c: busses: Use dev_get_drvdata where possible

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/i2c/busses/i2c-designware-pcidrv.c | 6 ++
 drivers/i2c/busses/i2c-i801.c  | 3 +--
 2 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c 
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 76810deb2de6..7d2e6959679c 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -173,8 +173,7 @@ static struct dw_pci_controller dw_pci_controllers[] = {
 #ifdef CONFIG_PM
 static int i2c_dw_pci_suspend(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct dw_i2c_dev *i_dev = pci_get_drvdata(pdev);
+   struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
 
i_dev->suspended = true;
i_dev->disable(i_dev);
@@ -184,8 +183,7 @@ static int i2c_dw_pci_suspend(struct device *dev)
 
 static int i2c_dw_pci_resume(struct device *dev)
 {
-   struct pci_dev *pdev = to_pci_dev(dev);
-   struct dw_i2c_dev *i_dev = pci_get_drvdata(pdev);
+   struct dw_i2c_dev *i_dev = dev_get_drvdata(dev);
int ret;
 
ret = i_dev->init(i_dev);
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index f2956936c3f2..a6469978e735 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1912,8 +1912,7 @@ static int i801_suspend(struct device *dev)
 
 static int i801_resume(struct device *dev)
 {
-   struct pci_dev *pci_dev = to_pci_dev(dev);
-   struct i801_priv *priv = pci_get_drvdata(pci_dev);
+   struct i801_priv *priv = dev_get_drvdata(dev);
 
i801_enable_host_notify(>adapter);
 
-- 
2.20.1



[PATCH] HID: intel-ish-hid: Use dev_get_drvdata where possible

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/hid/intel-ish-hid/ipc/pci-ish.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c 
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index aa80b4d3b740..7047c14516c9 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -204,8 +204,7 @@ static struct device __maybe_unused *ish_resume_device;
  */
 static void __maybe_unused ish_resume_handler(struct work_struct *work)
 {
-   struct pci_dev *pdev = to_pci_dev(ish_resume_device);
-   struct ishtp_device *dev = pci_get_drvdata(pdev);
+   struct ishtp_device *dev = dev_get_drvdata(ish_resume_device);
uint32_t fwsts;
int ret;
 
-- 
2.20.1



[PATCH] drm/vmwgfx: Use dev_get_drvdata

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 9506190a0300..8f5f5980c9d8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1448,8 +1448,7 @@ static int vmw_pm_resume(struct device *kdev)
 
 static int vmw_pm_freeze(struct device *kdev)
 {
-   struct pci_dev *pdev = to_pci_dev(kdev);
-   struct drm_device *dev = pci_get_drvdata(pdev);
+   struct drm_device *dev = dev_get_drvdata(kdev);
struct vmw_private *dev_priv = vmw_priv(dev);
int ret;
 
@@ -1497,8 +1496,7 @@ static int vmw_pm_freeze(struct device *kdev)
 
 static int vmw_pm_restore(struct device *kdev)
 {
-   struct pci_dev *pdev = to_pci_dev(kdev);
-   struct drm_device *dev = pci_get_drvdata(pdev);
+   struct drm_device *dev = dev_get_drvdata(kdev);
struct vmw_private *dev_priv = vmw_priv(dev);
int ret;
 
-- 
2.20.1



[PATCH 4.19] kconfig: fix missing choice values in auto.conf

2019-07-23 Thread Masahiro Yamada
commit 8e2442a5f86e1f77b86401fce274a7f622740bc4 upstream.

Since commit 00c864f8903d ("kconfig: allow all config targets to write
auto.conf if missing"), Kconfig creates include/config/auto.conf in the
defconfig stage when it is missing.

Joonas Kylmälä reported incorrect auto.conf generation under some
circumstances.

To reproduce it, apply the following diff:

|  --- a/arch/arm/configs/imx_v6_v7_defconfig
|  +++ b/arch/arm/configs/imx_v6_v7_defconfig
|  @@ -345,14 +345,7 @@ CONFIG_USB_CONFIGFS_F_MIDI=y
|   CONFIG_USB_CONFIGFS_F_HID=y
|   CONFIG_USB_CONFIGFS_F_UVC=y
|   CONFIG_USB_CONFIGFS_F_PRINTER=y
|  -CONFIG_USB_ZERO=m
|  -CONFIG_USB_AUDIO=m
|  -CONFIG_USB_ETH=m
|  -CONFIG_USB_G_NCM=m
|  -CONFIG_USB_GADGETFS=m
|  -CONFIG_USB_FUNCTIONFS=m
|  -CONFIG_USB_MASS_STORAGE=m
|  -CONFIG_USB_G_SERIAL=m
|  +CONFIG_USB_FUNCTIONFS=y
|   CONFIG_MMC=y
|   CONFIG_MMC_SDHCI=y
|   CONFIG_MMC_SDHCI_PLTFM=y

And then, run:

$ make ARCH=arm mrproper imx_v6_v7_defconfig

You will see CONFIG_USB_FUNCTIONFS=y is correctly contained in the
.config, but not in the auto.conf.

Please note drivers/usb/gadget/legacy/Kconfig is included from a choice
block in drivers/usb/gadget/Kconfig. So USB_FUNCTIONFS is a choice value.

This is probably a similar situation described in commit beaaddb62540
("kconfig: tests: test defconfig when two choices interact").

When sym_calc_choice() is called, the choice symbol forgets the
SYMBOL_DEF_USER unless all of its choice values are explicitly set by
the user.

The choice symbol is given just one chance to recall it because
set_all_choice_values() is called if SYMBOL_NEED_SET_CHOICE_VALUES
is set.

When sym_calc_choice() is called again, the choice symbol forgets it
forever, since SYMBOL_NEED_SET_CHOICE_VALUES is a one-time aid.
Hence, we cannot call sym_clear_all_valid() again and again.

It is crazy to repeat set and unset of internal flags. However, we
cannot simply get rid of "sym->flags &= flags | ~SYMBOL_DEF_USER;"
Doing so would re-introduce the problem solved by commit 5d09598d488f
("kconfig: fix new choices being skipped upon config update").

To work around the issue, conf_write_autoconf() stopped calling
sym_clear_all_valid().

conf_write() must be changed accordingly. Currently, it clears
SYMBOL_WRITE after the symbol is written into the .config file. This
is needed to prevent it from writing the same symbol multiple times in
case the symbol is declared in two or more locations. I added the new
flag SYMBOL_WRITTEN, to track the symbols that have been written.

Anyway, this is a cheesy workaround in order to suppress the issue
as far as defconfig is concerned.

Handling of choices is totally broken. sym_clear_all_valid() is called
every time a user touches a symbol from the GUI interface. To reproduce
it, just add a new symbol drivers/usb/gadget/legacy/Kconfig, then touch
around unrelated symbols from menuconfig. USB_FUNCTIONFS will disappear
from the .config file.

I added the Fixes tag since it is more fatal than before. But, this
has been broken since long long time before, and still it is.
We should take a closer look to fix this correctly somehow.

Fixes: 00c864f8903d ("kconfig: allow all config targets to write auto.conf if 
missing")
Cc: linux-stable  # 4.19+
Reported-by: Joonas Kylmälä 
Signed-off-by: Masahiro Yamada 
Tested-by: Joonas Kylmälä 
---
 scripts/kconfig/confdata.c | 7 +++
 scripts/kconfig/expr.h | 1 +
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 91d0a5c014ac..fd99ae90a618 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -834,11 +834,12 @@ int conf_write(const char *name)
 "#\n"
 "# %s\n"
 "#\n", str);
-   } else if (!(sym->flags & SYMBOL_CHOICE)) {
+   } else if (!(sym->flags & SYMBOL_CHOICE) &&
+  !(sym->flags & SYMBOL_WRITTEN)) {
sym_calc_value(sym);
if (!(sym->flags & SYMBOL_WRITE))
goto next;
-   sym->flags &= ~SYMBOL_WRITE;
+   sym->flags |= SYMBOL_WRITTEN;
 
conf_write_symbol(out, sym, _printer_cb, NULL);
}
@@ -1024,8 +1025,6 @@ int conf_write_autoconf(int overwrite)
if (!overwrite && is_present(autoconf_name))
return 0;
 
-   sym_clear_all_valid();
-
conf_write_dep("include/config/auto.conf.cmd");
 
if (conf_split_config())
diff --git a/scripts/kconfig/expr.h b/scripts/kconfig/expr.h
index 7c329e179007..43a87f8ea738 100644
--- a/scripts/kconfig/expr.h
+++ b/scripts/kconfig/expr.h
@@ -141,6 +141,7 @@ struct symbol {
 #define SYMBOL_OPTIONAL   0x0100  /* choice is optional - values can be 'n' */
 #define SYMBOL_WRITE  0x0200  /* write symbol to file (KCONFIG_CONFIG) */
 #define 

Re: [PATCH] rcu: Make jiffies_till_sched_qs writable

2019-07-23 Thread Byungchul Park
On Fri, Jul 19, 2019 at 04:33:56PM -0400, Joel Fernandes wrote:
> On Fri, Jul 19, 2019 at 3:57 PM Paul E. McKenney  
> wrote:
> >
> > On Fri, Jul 19, 2019 at 06:57:58PM +0900, Byungchul Park wrote:
> > > On Fri, Jul 19, 2019 at 4:43 PM Paul E. McKenney  
> > > wrote:
> > > >
> > > > On Thu, Jul 18, 2019 at 08:52:52PM -0400, Joel Fernandes wrote:
> > > > > On Thu, Jul 18, 2019 at 8:40 PM Byungchul Park 
> > > > >  wrote:
> > > > > [snip]
> > > > > > > - There is a bug in the CPU stopper machinery itself preventing it
> > > > > > > from scheduling the stopper on Y. Even though Y is not holding up 
> > > > > > > the
> > > > > > > grace period.
> > > > > >
> > > > > > Or any thread on Y is busy with preemption/irq disabled preventing 
> > > > > > the
> > > > > > stopper from being scheduled on Y.
> > > > > >
> > > > > > Or something is stuck in ttwu() to wake up the stopper on Y due to 
> > > > > > any
> > > > > > scheduler locks such as pi_lock or rq->lock or something.
> > > > > >
> > > > > > I think what you mentioned can happen easily.
> > > > > >
> > > > > > Basically we would need information about preemption/irq disabled
> > > > > > sections on Y and scheduler's current activity on every cpu at that 
> > > > > > time.
> > > > >
> > > > > I think all that's needed is an NMI backtrace on all CPUs. An ARM we
> > > > > don't have NMI solutions and only IPI or interrupt based backtrace
> > > > > works which should at least catch and the preempt disable and softirq
> > > > > disable cases.
> > > >
> > > > True, though people with systems having hundreds of CPUs might not
> > > > thank you for forcing an NMI backtrace on each of them.  Is it possible
> > > > to NMI only the ones that are holding up the CPU stopper?
> > >
> > > What a good idea! I think it's possible!
> > >
> > > But we need to think about the case NMI doesn't work when the
> > > holding-up was caused by IRQ disabled.
> > >
> > > Though it's just around the corner of weekend, I will keep thinking
> > > on it during weekend!
> >
> > Very good!
> 
> Me too will think more about it ;-) Agreed with point about 100s of
> CPUs usecase,
> 
> Thanks, have a great weekend,

BTW, if there's any long code section with irq/preemption disabled, then
the problem would be not only about RCU stall. And we can also use
latency tracer or something to detect the bad situation.

So in this case, sending ipi/nmi to the CPUs where the stoppers cannot
to be scheduled does not give us additional meaningful information.

I think Paul started to think about this to solve some real problem. I
seriously love to help RCU and it's my pleasure to dig deep into kind of
RCU stuff, but I've yet to define exactly what problem is. Sorry.

Could you share the real issue? I think you don't have to reproduce it.
Just sharing the issue that you got inspired from is enough. Then I
might be able to develop 'how' with Joel! :-) It's our pleasure!

Thanks,
Byungchul


Re: [PATCH] [v2] waitqueue: shut up clang -Wuninitialized warnings

2019-07-23 Thread Arnd Bergmann
On Tue, Jul 23, 2019 at 12:50 PM Peter Zijlstra  wrote:
> On Fri, Jul 19, 2019 at 01:36:00PM +0200, Arnd Bergmann wrote:
> > --- a/include/linux/wait.h
> > +++ b/include/linux/wait.h
> > @@ -70,8 +70,17 @@ extern void __init_waitqueue_head(struct wait_queue_head 
> > *wq_head, const char *n
> >  #ifdef CONFIG_LOCKDEP
> >  # define __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) \
> >   ({ init_waitqueue_head(); name; })
> > -# define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \
> > +# if defined(__clang__) && __clang_major__ <= 9
> > +/* work around https://bugs.llvm.org/show_bug.cgi?id=42604 */
> > +#  define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name)
> >   \
> > + _Pragma("clang diagnostic push")  
> >   \
> > + _Pragma("clang diagnostic ignored \"-Wuninitialized\"")   
> >   \
> > + struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> >   \
> > + _Pragma("clang diagnostic pop")
> > +# else
> > +#  define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \
> >   struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> > +# endif
>
> While this is indeed much better than before; do we really want to do
> this? That is, since clang-9 release will not need this, we're basically
> doing the above for pre-release compilers only.

Kernelci currently builds arch/arm and arch/arm64 kernels with clang-8,
and probably won't change to clang-9 until after that is released,
presumably in September.

Anyone doing x86 builds would use a clang-9 snapshot today
because of the asm-goto support, but so far the fix has not
been merged there either. I think the chances of it getting
fixed before the release are fairly good, but I don't know how
long it will actually take.

   Arnd


Re: [PATCH 11/11] firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possible

2019-07-23 Thread Sudeep Holla
On Mon, Jul 22, 2019 at 02:29:53PM -0700, Stephen Boyd wrote:
> Quoting Sudeep Holla (2019-07-08 08:47:30)
> > CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum
> > number of pending asynchronous clock rate changes supported by the
> > platform. If it's non-zero, then we should be able to use asynchronous
> > clock rate set for any clocks until the maximum limit is reached.
> >
> > Keeping the current count of pending asynchronous clock set rate
> > requests, we can decide if we can you asynchronous request for the
>
> This last part of the sentence doesn't read properly. Please rewrite.
>

Will fix.

> > incoming/new request.
> >
> > Signed-off-by: Sudeep Holla 
> > ---
> >  drivers/firmware/arm_scmi/clock.c | 21 ++---
> >  1 file changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/firmware/arm_scmi/clock.c 
> > b/drivers/firmware/arm_scmi/clock.c
> > index dd215bd11a58..70044b7c812e 100644
> > --- a/drivers/firmware/arm_scmi/clock.c
> > +++ b/drivers/firmware/arm_scmi/clock.c
> > @@ -221,21 +222,35 @@ static int scmi_clock_rate_set(const struct 
> > scmi_handle *handle, u32 clk_id,
> >u64 rate)
> >  {
> > int ret;
> > +   u32 flags = 0;
> > struct scmi_xfer *t;
> > struct scmi_clock_set_rate *cfg;
> > +   struct clock_info *ci = handle->clk_priv;
> >
> > ret = scmi_xfer_get_init(handle, CLOCK_RATE_SET, 
> > SCMI_PROTOCOL_CLOCK,
> >  sizeof(*cfg), 0, );
> > if (ret)
> > return ret;
> >
> > +   if (ci->max_async_req) {
> > +   if (atomic_inc_return(>cur_async_req) < 
> > ci->max_async_req)
> > +   flags |= CLOCK_SET_ASYNC;
> > +   else
> > +   atomic_dec(>cur_async_req);
>
> Can this be combined with the atomic_dec() below and done after either
> transfer?
>

Yes but cleaner.

> > +   }
> > +
> > cfg = t->tx.buf;
> > -   cfg->flags = cpu_to_le32(0);
> > +   cfg->flags = cpu_to_le32(flags);
> > cfg->id = cpu_to_le32(clk_id);
> > cfg->value_low = cpu_to_le32(rate & 0x);
> > cfg->value_high = cpu_to_le32(rate >> 32);
> >
> > -   ret = scmi_do_xfer(handle, t);
> > +   if (flags & CLOCK_SET_ASYNC) {
> > +   ret = scmi_do_xfer_with_response(handle, t);
> > +   atomic_dec(>cur_async_req);
> > +   } else {
> > +   ret = scmi_do_xfer(handle, t);
> > +   }
>
> I mean putting the atomic_dec() here.
>

Understood and done locally, will post as v2.

--
Regards,
Sudeep


Re: [PATCH V6 RESEND 0/3] arm64/mm: Enable memory hot remove

2019-07-23 Thread Mark Rutland
Hi Anshuman,

On Mon, Jul 15, 2019 at 11:47:47AM +0530, Anshuman Khandual wrote:
> This series enables memory hot remove on arm64 after fixing a memblock
> removal ordering problem in generic try_remove_memory() and a possible
> arm64 platform specific kernel page table race condition. This series
> is based on linux-next (next-20190712).
> 
> Concurrent vmalloc() and hot-remove conflict:
> 
> As pointed out earlier on the v5 thread [2] there can be potential conflict
> between concurrent vmalloc() and memory hot-remove operation. This can be
> solved or at least avoided with some possible methods. The problem here is
> caused by inadequate locking in vmalloc() which protects installation of a
> page table page but not the walk or the leaf entry modification.
> 
> Option 1: Making locking in vmalloc() adequate
> 
> Current locking scheme protects installation of page table pages but not the
> page table walk or leaf entry creation which can conflict with hot-remove.
> This scheme is sufficient for now as vmalloc() works on mutually exclusive
> ranges which can proceed concurrently only if their shared page table pages
> can be created while inside the lock. It achieves performance improvement
> which will be compromised if entire vmalloc() operation (even if with some
> optimization) has to be completed under a lock.
> 
> Option 2: Making sure hot-remove does not happen during vmalloc()
> 
> Take mem_hotplug_lock in read mode through [get|put]_online_mems() constructs
> for the entire duration of vmalloc(). It protects from concurrent memory hot
> remove operation and does not add any significant overhead to other concurrent
> vmalloc() threads. It solves the problem in right way unless we do not want to
> extend the usage of mem_hotplug_lock in generic MM.
> 
> Option 3: Memory hot-remove does not free (conflicting) page table pages
> 
> Don't not free page table pages (if any) for vmemmap mappings after unmapping
> it's virtual range. The only downside here is that some page table pages might
> remain empty and unused until next memory hot-add operation of the same memory
> range.
> 
> Option 4: Dont let vmalloc and vmemmap share intermediate page table pages
> 
> The conflict does not arise if vmalloc and vmemap range do not share kernel
> page table pages to start with. If such placement can be ensured in platform
> kernel virtual address layout, this problem can be successfully avoided.
> 
> There are two generic solutions (Option 1 and 2) and two platform specific
> solutions (Options 2 and 3). This series has decided to go with (Option 3)
> which requires minimum changes while self-contained inside the functionality.

... while also leaking memory, right?

In my view, option 2 or 4 would have been preferable. Were there
specific technical reasons to not go down either of those routes? I'm
not sure that minimizing changes is the right rout given that this same
problem presumably applies to other architectures, which will need to be
fixed.

Do we know why we aren't seeing issues on other architectures? e.g. is
the issue possible but rare (and hence not reported), or masked by
something else (e.g. the layout of the kernel VA space)?

I'd like to solve the underyling issue before we start adding new
functionality.

> Testing:
> 
> Memory hot remove has been tested on arm64 for 4K, 16K, 64K page config
> options with all possible CONFIG_ARM64_VA_BITS and CONFIG_PGTABLE_LEVELS
> combinations. Its only build tested on non-arm64 platforms.

Could you please share how you've tested this?

Having instructions so that I could reproduce this locally would be very
helpful.

Thanks,
Mark.


Re: [PATCH] regulator: act8865: support regulator-pull-down property

2019-07-23 Thread Mark Brown
On Mon, Jul 22, 2019 at 08:13:29PM +0200, Michał Mirosław wrote:
> AC8865 has internal 1.5k pull-down resistor that can be enabled when LDO
> is shut down.

This changelog...

>  static const struct regulator_ops act8865_ldo_ops = {
> + .list_voltage   = regulator_list_voltage_linear_range,
> + .map_voltage= regulator_map_voltage_linear_range,
> + .get_voltage_sel= regulator_get_voltage_sel_regmap,
> + .set_voltage_sel= regulator_set_voltage_sel_regmap,

...doesn't obviously match this code change which looks to be
implementing voltage setting (as well as the pull down stuff but still).


signature.asc
Description: PGP signature


[PATCH] phy: marvell: phy-mvebu-cp110-comphy: Add of_node_put() before return

2019-07-23 Thread Nishka Dasgupta
Each iteration of for_each_available_child_of_node puts the previous
node, but in the case of a return from the middle of the loop, there is
no put, thus causing a memory leak. Hence add an of_node_put before the
return in two places.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
 drivers/phy/marvell/phy-mvebu-cp110-comphy.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c 
b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
index d98e0451f6a1..f7a16dc6e171 100644
--- a/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-cp110-comphy.c
@@ -626,12 +626,16 @@ static int mvebu_comphy_probe(struct platform_device 
*pdev)
}
 
lane = devm_kzalloc(>dev, sizeof(*lane), GFP_KERNEL);
-   if (!lane)
+   if (!lane) {
+   of_node_put(child);
return -ENOMEM;
+   }
 
phy = devm_phy_create(>dev, child, _comphy_ops);
-   if (IS_ERR(phy))
+   if (IS_ERR(phy)) {
+   of_node_put(child);
return PTR_ERR(phy);
+   }
 
lane->priv = priv;
lane->mode = PHY_MODE_INVALID;
-- 
2.19.1



[PATCH] phy: marvell: phy-mvebu-a3700-comphy: Add of_node_put() before return

2019-07-23 Thread Nishka Dasgupta
Each iteration of for_each_available_child_of_node puts the previous
node, but in the case of a return from the middle of the loop, there is
no put, thus causing a memory leak. Hence add an of_node_put before the
return in two places.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
 drivers/phy/marvell/phy-mvebu-a3700-comphy.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/marvell/phy-mvebu-a3700-comphy.c 
b/drivers/phy/marvell/phy-mvebu-a3700-comphy.c
index 8812a104c233..0ebac46435bd 100644
--- a/drivers/phy/marvell/phy-mvebu-a3700-comphy.c
+++ b/drivers/phy/marvell/phy-mvebu-a3700-comphy.c
@@ -277,13 +277,17 @@ static int mvebu_a3700_comphy_probe(struct 
platform_device *pdev)
}
 
lane = devm_kzalloc(>dev, sizeof(*lane), GFP_KERNEL);
-   if (!lane)
+   if (!lane) {
+   of_node_put(child);
return -ENOMEM;
+   }
 
phy = devm_phy_create(>dev, child,
  _a3700_comphy_ops);
-   if (IS_ERR(phy))
+   if (IS_ERR(phy)) {
+   of_node_put(child);
return PTR_ERR(phy);
+   }
 
lane->dev = >dev;
lane->mode = PHY_MODE_INVALID;
-- 
2.19.1



Re: [PATCH] [v2] waitqueue: shut up clang -Wuninitialized warnings

2019-07-23 Thread Peter Zijlstra
On Fri, Jul 19, 2019 at 01:36:00PM +0200, Arnd Bergmann wrote:
> When CONFIG_LOCKDEP is set, every use of DECLARE_WAIT_QUEUE_HEAD_ONSTACK()
> produces an bogus warning from clang, which is particularly annoying
> for allmodconfig builds:
> 
> fs/namei.c:1646:34: error: variable 'wq' is uninitialized when used within 
> its own initialization [-Werror,-Wuninitialized]
> DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wq);
> ^~
> include/linux/wait.h:74:63: note: expanded from macro 
> 'DECLARE_WAIT_QUEUE_HEAD_ONSTACK'
> struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
>  ^~~~
> include/linux/wait.h:72:33: note: expanded from macro 
> '__WAIT_QUEUE_HEAD_INIT_ONSTACK'
> ({ init_waitqueue_head(); name; })
>^~~~
> 
> A patch for clang has already been proposed and should soon be
> merged for clang-9, but for now all clang versions produce the
> warning in an otherwise (almost) clean allmodconfig build.
> 
> Link: https://bugs.llvm.org/show_bug.cgi?id=31829
> Link: https://bugs.llvm.org/show_bug.cgi?id=42604
> Link: https://lore.kernel.org/lkml/20190703081119.209976-1-a...@arndb.de/
> Link: https://reviews.llvm.org/D64678
> Link: 
> https://storage.kernelci.org/next/master/next-20190717/arm64/allmodconfig/clang-8/build-warnings.log
> Suggested-by: Nathan Chancellor 
> Cc: Peter Zijlstra 
> Signed-off-by: Arnd Bergmann 
> ---
> v2: given that kernelci is getting close to reporting a clean build for
> clang, I'm trying again with a less invasive approach after my
> first version was not too popular.
> ---
>  include/linux/wait.h | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index ddb959641709..276499ae1a3e 100644
> --- a/include/linux/wait.h
> +++ b/include/linux/wait.h
> @@ -70,8 +70,17 @@ extern void __init_waitqueue_head(struct wait_queue_head 
> *wq_head, const char *n
>  #ifdef CONFIG_LOCKDEP
>  # define __WAIT_QUEUE_HEAD_INIT_ONSTACK(name) \
>   ({ init_waitqueue_head(); name; })
> -# define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \
> +# if defined(__clang__) && __clang_major__ <= 9
> +/* work around https://bugs.llvm.org/show_bug.cgi?id=42604 */
> +#  define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name)  
> \
> + _Pragma("clang diagnostic push")
> \
> + _Pragma("clang diagnostic ignored \"-Wuninitialized\"") 
> \
> + struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)  
> \
> + _Pragma("clang diagnostic pop")
> +# else
> +#  define DECLARE_WAIT_QUEUE_HEAD_ONSTACK(name) \
>   struct wait_queue_head name = __WAIT_QUEUE_HEAD_INIT_ONSTACK(name)
> +# endif

While this is indeed much better than before; do we really want to do
this? That is, since clang-9 release will not need this, we're basically
doing the above for pre-release compilers only.



RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool

2019-07-23 Thread Jose Abreu
From: Jon Hunter 
Date: Jul/23/2019, 11:38:33 (UTC+00:00)

> 
> On 23/07/2019 11:07, Jose Abreu wrote:
> > From: Jon Hunter 
> > Date: Jul/23/2019, 11:01:24 (UTC+00:00)
> > 
> >> This appears to be a winner and by disabling the SMMU for the ethernet
> >> controller and reverting commit 954a03be033c7cef80ddc232e7cbdb17df735663
> >> this worked! So yes appears to be related to the SMMU being enabled. We
> >> had to enable the SMMU for ethernet recently due to commit
> >> 954a03be033c7cef80ddc232e7cbdb17df735663.
> > 
> > Finally :)
> > 
> > However, from "git show 954a03be033c7cef80ddc232e7cbdb17df735663":
> > 
> > + There are few reasons to allow unmatched stream bypass, and
> > + even fewer good ones.  If saying YES here breaks your board
> > + you should work on fixing your board.
> > 
> > So, how can we fix this ? Is your ethernet DT node marked as 
> > "dma-coherent;" ?
> 
> TBH I have no idea. I can't say I fully understand your change or how it
> is breaking things for us.
> 
> Currently, the Tegra DT binding does not have 'dma-coherent' set. I see
> this is optional, but I am not sure how you determine whether or not
> this should be set.

From my understanding it means that your device / IP DMA accesses are coherent 
regarding the CPU point of view. I think it will be the case if GMAC is not 
behind any kind of IOMMU in the HW arch.

I don't know about this SMMU but the source does have some special 
conditions when device is dma-coherent.

---
Thanks,
Jose Miguel Abreu


[PATCH] phy: marvell: phy-armada38x-comphy: Add of_node_put() before return

2019-07-23 Thread Nishka Dasgupta
Each iteration of for_each_available_child_of_node puts the previous
node, but in the case of a return from the middle of the loop, there is
no put, thus causing a memory leak. Hence add an of_node_put before the
return.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
 drivers/phy/marvell/phy-armada38x-comphy.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/marvell/phy-armada38x-comphy.c 
b/drivers/phy/marvell/phy-armada38x-comphy.c
index 3e00bc679d4e..6960dfd8ad8c 100644
--- a/drivers/phy/marvell/phy-armada38x-comphy.c
+++ b/drivers/phy/marvell/phy-armada38x-comphy.c
@@ -200,8 +200,10 @@ static int a38x_comphy_probe(struct platform_device *pdev)
}
 
phy = devm_phy_create(>dev, child, _comphy_ops);
-   if (IS_ERR(phy))
+   if (IS_ERR(phy)) {
+   of_node_put(child);
return PTR_ERR(phy);
+   }
 
priv->lane[val].base = base + 0x28 * val;
priv->lane[val].priv = priv;
-- 
2.19.1



[PATCH v3] sched/topology: Improve load balancing on AMD EPYC

2019-07-23 Thread Matt Fleming
SD_BALANCE_{FORK,EXEC} and SD_WAKE_AFFINE are stripped in sd_init()
for any sched domains with a NUMA distance greater than 2 hops
(RECLAIM_DISTANCE). The idea being that it's expensive to balance
across domains that far apart.

However, as is rather unfortunately explained in

  commit 32e45ff43eaf ("mm: increase RECLAIM_DISTANCE to 30")

the value for RECLAIM_DISTANCE is based on node distance tables from
2011-era hardware.

Current AMD EPYC machines have the following NUMA node distances:

node distances:
node   0   1   2   3   4   5   6   7
  0:  10  16  16  16  32  32  32  32
  1:  16  10  16  16  32  32  32  32
  2:  16  16  10  16  32  32  32  32
  3:  16  16  16  10  32  32  32  32
  4:  32  32  32  32  10  16  16  16
  5:  32  32  32  32  16  10  16  16
  6:  32  32  32  32  16  16  10  16
  7:  32  32  32  32  16  16  16  10

where 2 hops is 32.

The result is that the scheduler fails to load balance properly across
NUMA nodes on different sockets -- 2 hops apart.

For example, pinning 16 busy threads to NUMA nodes 0 (CPUs 0-7) and 4
(CPUs 32-39) like so,

  $ numactl -C 0-7,32-39 ./spinner 16

causes all threads to fork and remain on node 0 until the active
balancer kicks in after a few seconds and forcibly moves some threads
to node 4.

Override node_reclaim_distance for AMD Zen.

Signed-off-by: Matt Fleming 
Cc: "Suthikulpanit, Suravee" 
Cc: Mel Gorman 
Cc: "Lendacky, Thomas" 
Cc: Borislav Petkov 
---
 arch/x86/kernel/cpu/amd.c |  3 +++
 include/linux/topology.h  | 14 ++
 kernel/sched/topology.c   |  3 ++-
 mm/khugepaged.c   |  2 +-
 mm/page_alloc.c   |  2 +-
 5 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 8d4e50428b68..d94bf83d5ee6 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -824,6 +825,8 @@ static void init_amd_zn(struct cpuinfo_x86 *c)
 {
set_cpu_cap(c, X86_FEATURE_ZEN);
 
+   node_reclaim_distance = 32;
+
/*
 * Fix erratum 1076: CPB feature bit not being set in CPUID.
 * Always set it, except when running under a hypervisor.
diff --git a/include/linux/topology.h b/include/linux/topology.h
index 47a3e3c08036..579522ec446c 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -59,6 +59,20 @@ int arch_update_cpu_topology(void);
  */
 #define RECLAIM_DISTANCE 30
 #endif
+
+/*
+ * The following tunable allows platforms to override the default node
+ * reclaim distance (RECLAIM_DISTANCE) if remote memory accesses are
+ * sufficiently fast that the default value actually hurts
+ * performance.
+ *
+ * AMD EPYC machines use this because even though the 2-hop distance
+ * is 32 (3.2x slower than a local memory access) performance actually
+ * *improves* if allowed to reclaim memory and load balance tasks
+ * between NUMA nodes 2-hops apart.
+ */
+extern int __read_mostly node_reclaim_distance;
+
 #ifndef PENALTY_FOR_NODE_WITH_CPUS
 #define PENALTY_FOR_NODE_WITH_CPUS (1)
 #endif
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index f751ce0b783e..f684fde00536 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -1284,6 +1284,7 @@ static int
sched_domains_curr_level;
 intsched_max_numa_distance;
 static int *sched_domains_numa_distance;
 static struct cpumask  ***sched_domains_numa_masks;
+int __read_mostly  node_reclaim_distance = RECLAIM_DISTANCE;
 #endif
 
 /*
@@ -1402,7 +1403,7 @@ sd_init(struct sched_domain_topology_level *tl,
 
sd->flags &= ~SD_PREFER_SIBLING;
sd->flags |= SD_SERIALIZE;
-   if (sched_domains_numa_distance[tl->numa_level] > 
RECLAIM_DISTANCE) {
+   if (sched_domains_numa_distance[tl->numa_level] > 
node_reclaim_distance) {
sd->flags &= ~(SD_BALANCE_EXEC |
   SD_BALANCE_FORK |
   SD_WAKE_AFFINE);
diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index eaaa21b23215..ccede2425c3f 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -710,7 +710,7 @@ static bool khugepaged_scan_abort(int nid)
for (i = 0; i < MAX_NUMNODES; i++) {
if (!khugepaged_node_load[i])
continue;
-   if (node_distance(nid, i) > RECLAIM_DISTANCE)
+   if (node_distance(nid, i) > node_reclaim_distance)
return true;
}
return false;
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 272c6de1bf4e..0d54cd2c43a4 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3522,7 +3522,7 @@ bool zone_watermark_ok_safe(struct zone *z, unsigned int 
order,
 static bool zone_allows_reclaim(struct zone *local_zone, struct zone *zone)
 {
return 

[PATCH 9/9] irqchip/gic-v3: Add EPPI range support

2019-07-23 Thread Marc Zyngier
Expand the pre-existing PPI support to be able to deal with the
Extended PPI range (EPPI). This includes obtaining the number of PPIs
from each individual redistributor, and compute the minimum set
(just in case someone builds something really clever...).

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-v3.c   | 42 +-
 include/linux/irqchip/arm-gic-v3.h | 12 +
 2 files changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index b85acab4a6a1..c91e4c759c95 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -104,6 +104,7 @@ static DEFINE_PER_CPU(bool, has_rss);
 enum gic_intid_range {
PPI_RANGE,
SPI_RANGE,
+   EPPI_RANGE,
ESPI_RANGE,
LPI_RANGE,
__INVALID_RANGE__
@@ -116,6 +117,8 @@ static enum gic_intid_range 
__get_intid_range(irq_hw_number_t hwirq)
return PPI_RANGE;
case 32 ... 1019:
return SPI_RANGE;
+   case EPPI_BASE_INTID ... 1119:
+   return EPPI_RANGE;
case ESPI_BASE_INTID ... 8191:
return ESPI_RANGE;
case 8192 ... GENMASK(23, 0):
@@ -137,13 +140,15 @@ static inline unsigned int gic_irq(struct irq_data *d)
 
 static inline int gic_irq_in_rdist(struct irq_data *d)
 {
-   return get_intid_range(d) == PPI_RANGE;
+   enum gic_intid_range range = get_intid_range(d);
+   return range == PPI_RANGE || range == EPPI_RANGE;
 }
 
 static inline void __iomem *gic_dist_base(struct irq_data *d)
 {
switch (get_intid_range(d)) {
case PPI_RANGE:
+   case EPPI_RANGE:
/* SGI+PPI -> SGI_base for this CPU */
return gic_data_rdist_sgi_base();
 
@@ -242,6 +247,14 @@ static u32 convert_offset_index(struct irq_data *d, u32 
offset, u32 *index)
case SPI_RANGE:
*index = d->hwirq;
return offset;
+   case EPPI_RANGE:
+   /*
+* Contrary to the ESPI range, the EPPI range is contiguous
+* to the PPI range in the registers, so let's adjust the
+* displacement accordingly. Consistency is overrated.
+*/
+   *index = d->hwirq - EPPI_BASE_INTID + 32;
+   return offset;
case ESPI_RANGE:
*index = d->hwirq - ESPI_BASE_INTID;
switch (offset) {
@@ -414,6 +427,8 @@ static u32 gic_get_ppi_index(struct irq_data *d)
switch (get_intid_range(d)) {
case PPI_RANGE:
return d->hwirq - 16;
+   case EPPI_RANGE:
+   return d->hwirq - EPPI_BASE_INTID + 16;
default:
unreachable();
}
@@ -507,6 +522,7 @@ static void gic_eoimode1_eoi_irq(struct irq_data *d)
 
 static int gic_set_type(struct irq_data *d, unsigned int type)
 {
+   enum gic_intid_range range;
unsigned int irq = gic_irq(d);
void (*rwp_wait)(void);
void __iomem *base;
@@ -517,9 +533,11 @@ static int gic_set_type(struct irq_data *d, unsigned int 
type)
if (irq < 16)
return -EINVAL;
 
+   range = get_intid_range(d);
+
/* SPIs have restrictions on the supported types */
-   if (irq >= 32 && type != IRQ_TYPE_LEVEL_HIGH &&
-type != IRQ_TYPE_EDGE_RISING)
+   if ((range == SPI_RANGE || range == ESPI_RANGE) &&
+   type != IRQ_TYPE_LEVEL_HIGH && type != IRQ_TYPE_EDGE_RISING)
return -EINVAL;
 
if (gic_irq_in_rdist(d)) {
@@ -533,9 +551,9 @@ static int gic_set_type(struct irq_data *d, unsigned int 
type)
offset = convert_offset_index(d, GICD_ICFGR, );
 
ret = gic_configure_irq(index, type, base + offset, rwp_wait);
-   if (ret && irq < 32) {
+   if (ret && (range == PPI_RANGE || range == EPPI_RANGE)) {
/* Misconfigured PPIs are usually not fatal */
-   pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16);
+   pr_warn("GIC: PPI INTID%d is secure or misconfigured\n", irq);
ret = 0;
}
 
@@ -833,7 +851,7 @@ static int __gic_update_rdist_properties(struct 
redist_region *region,
u64 typer = gic_read_typer(ptr + GICR_TYPER);
gic_data.rdists.has_vlpis &= !!(typer & GICR_TYPER_VLPIS);
gic_data.rdists.has_direct_lpi &= !!(typer & GICR_TYPER_DirectLPIS);
-   gic_data.ppi_nr = 16;
+   gic_data.ppi_nr = min(GICR_TYPER_NR_PPIS(typer), gic_data.ppi_nr);
 
return 1;
 }
@@ -1218,6 +1236,7 @@ static int gic_irq_domain_map(struct irq_domain *d, 
unsigned int irq,
 
switch (__get_intid_range(hw)) {
case PPI_RANGE:
+   case EPPI_RANGE:
irq_set_percpu_devid(irq);
irq_domain_set_info(d, irq, hw, chip, d->host_data,
handle_percpu_devid_irq, NULL, NULL);
@@ -1262,15 +1281,24 @@ static int 

[PATCH 1/9] irqchip/gic: Rework gic_configure_irq to take the full ICFGR base

2019-07-23 Thread Marc Zyngier
gic_configure_irq is currently passed the (re)distributor address,
to which it applies an a fixed offset to get to the configuration
registers. This offset is constant across all GICs, or rather it was
until to v3.1...

An easy way out is for the individual drivers to pass the base
address of the configuration register for the considered interrupt.
At the same time, move part of the error handling back to the
individual drivers, as things are about to change on that front.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-common.c | 14 +-
 drivers/irqchip/irq-gic-v3.c | 11 ++-
 drivers/irqchip/irq-gic.c| 10 +-
 drivers/irqchip/irq-hip04.c  |  7 ++-
 4 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index b0a8215a13fc..6900b6f0921c 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -63,7 +63,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
 * for "irq", depending on "type".
 */
raw_spin_lock_irqsave(_controller_lock, flags);
-   val = oldval = readl_relaxed(base + GIC_DIST_CONFIG + confoff);
+   val = oldval = readl_relaxed(base + confoff);
if (type & IRQ_TYPE_LEVEL_MASK)
val &= ~confmask;
else if (type & IRQ_TYPE_EDGE_BOTH)
@@ -83,14 +83,10 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
 * does not allow us to set the configuration or we are in a
 * non-secure mode, and hence it may not be catastrophic.
 */
-   writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
-   if (readl_relaxed(base + GIC_DIST_CONFIG + confoff) != val) {
-   if (WARN_ON(irq >= 32))
-   ret = -EINVAL;
-   else
-   pr_warn("GIC: PPI%d is secure or misconfigured\n",
-   irq - 16);
-   }
+   writel_relaxed(val, base + confoff);
+   if (readl_relaxed(base + confoff) != val)
+   ret = -EINVAL;
+
raw_spin_unlock_irqrestore(_controller_lock, flags);
 
if (sync_access)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 9bca4896fa6f..915b4ae8667f 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -407,6 +407,7 @@ static int gic_set_type(struct irq_data *d, unsigned int 
type)
unsigned int irq = gic_irq(d);
void (*rwp_wait)(void);
void __iomem *base;
+   int ret;
 
/* Interrupt configuration for SGIs can't be changed */
if (irq < 16)
@@ -425,7 +426,15 @@ static int gic_set_type(struct irq_data *d, unsigned int 
type)
rwp_wait = gic_dist_wait_for_rwp;
}
 
-   return gic_configure_irq(irq, type, base, rwp_wait);
+
+   ret = gic_configure_irq(irq, type, base + GICD_ICFGR, rwp_wait);
+   if (ret && irq < 32) {
+   /* Misconfigured PPIs are usually not fatal */
+   pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16);
+   ret = 0;
+   }
+
+   return ret;
 }
 
 static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index e45f45e68720..ab48760acabb 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -291,6 +291,7 @@ static int gic_set_type(struct irq_data *d, unsigned int 
type)
 {
void __iomem *base = gic_dist_base(d);
unsigned int gicirq = gic_irq(d);
+   int ret;
 
/* Interrupt configuration for SGIs can't be changed */
if (gicirq < 16)
@@ -301,7 +302,14 @@ static int gic_set_type(struct irq_data *d, unsigned int 
type)
type != IRQ_TYPE_EDGE_RISING)
return -EINVAL;
 
-   return gic_configure_irq(gicirq, type, base, NULL);
+   ret = gic_configure_irq(gicirq, type, base + GIC_DIST_CONFIG, NULL);
+   if (ret && gicirq < 32) {
+   /* Misconfigured PPIs are usually not fatal */
+   pr_warn("GIC: PPI%d is secure or misconfigured\n", gicirq - 16);
+   ret = 0;
+   }
+
+   return ret;
 }
 
 static int gic_irq_set_vcpu_affinity(struct irq_data *d, void *vcpu)
diff --git a/drivers/irqchip/irq-hip04.c b/drivers/irqchip/irq-hip04.c
index cf705827599c..1626131834a6 100644
--- a/drivers/irqchip/irq-hip04.c
+++ b/drivers/irqchip/irq-hip04.c
@@ -130,7 +130,12 @@ static int hip04_irq_set_type(struct irq_data *d, unsigned 
int type)
 
raw_spin_lock(_controller_lock);
 
-   ret = gic_configure_irq(irq, type, base, NULL);
+   ret = gic_configure_irq(irq, type, base + GIC_DIST_CONFIG, NULL);
+   if (ret && irq < 32) {
+   /* Misconfigured PPIs are usually not fatal */
+   pr_warn("GIC: PPI%d is secure or misconfigured\n", irq - 16);
+   ret = 0;
+   }
 
   

[PATCH 8/9] dt-bindings: interrupt-controller: arm,gic-v3: Describe EPPI range support

2019-07-23 Thread Marc Zyngier
Update the GICv3 binding to allow interrupts in the EPPI range.

Signed-off-by: Marc Zyngier 
---
 .../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml 
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
index 98a3ecda8e07..1fe147daca4c 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
@@ -44,12 +44,13 @@ properties:
   be at least 4.
 
   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
-  interrupts, 2 for interrupts in the Extended SPI range. Other values
-  are reserved for future use.
+  interrupts, 2 for interrupts in the Extended SPI range, 3 for the
+  Extended PPI range. Other values are reserved for future use.
 
   The 2nd cell contains the interrupt number for the interrupt type.
   SPI interrupts are in the range [0-987]. PPI interrupts are in the
   range [0-15]. Extented SPI interrupts are in the range [0-1023].
+  Extended PPI interrupts are in the range [0-127].
 
   The 3rd cell is the flags, encoded as follows:
   bits[3:0] trigger type and level flags.
-- 
2.20.1



[PATCH 7/9] irqchip/gic-v3: Dynamically allocate PPI partition descriptors

2019-07-23 Thread Marc Zyngier
Again, PPIs are becoming a variable set. Let's hack the PPI partition
code to make the top-level array dynamically allocated.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-v3.c | 14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index ec0f885fa373..b85acab4a6a1 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -52,7 +52,7 @@ struct gic_chip_data {
u64 flags;
boolhas_rss;
unsigned intppi_nr;
-   struct partition_desc   *ppi_descs[16];
+   struct partition_desc   **ppi_descs;
 };
 
 static struct gic_chip_data gic_data __read_mostly;
@@ -1350,7 +1350,8 @@ static int gic_irq_domain_select(struct irq_domain *d,
 * then we need to match the partition domain.
 */
if (fwspec->param_count >= 4 &&
-   fwspec->param[0] == 1 && fwspec->param[3] != 0)
+   fwspec->param[0] == 1 && fwspec->param[3] != 0 &&
+   gic_data.ppi_descs)
return d == 
partition_get_domain(gic_data.ppi_descs[fwspec->param[1]]);
 
return d == gic_data.domain;
@@ -1371,6 +1372,9 @@ static int partition_domain_translate(struct irq_domain 
*d,
struct device_node *np;
int ret;
 
+   if (!gic_data.ppi_descs)
+   return -ENOMEM;
+
np = of_find_node_by_phandle(fwspec->param[3]);
if (WARN_ON(!np))
return -EINVAL;
@@ -1527,6 +1531,10 @@ static void __init gic_populate_ppi_partitions(struct 
device_node *gic_node)
if (!parts_node)
return;
 
+   gic_data.ppi_descs = kcalloc(gic_data.ppi_nr, 
sizeof(*gic_data.ppi_descs), GFP_KERNEL);
+   if (!gic_data.ppi_descs)
+   return;
+
nr_parts = of_get_child_count(parts_node);
 
if (!nr_parts)
@@ -1578,7 +1586,7 @@ static void __init gic_populate_ppi_partitions(struct 
device_node *gic_node)
part_idx++;
}
 
-   for (i = 0; i < 16; i++) {
+   for (i = 0; i < gic_data.ppi_nr; i++) {
unsigned int irq;
struct partition_desc *desc;
struct irq_fwspec ppi_fwspec = {
-- 
2.20.1



[PATCH 6/9] irqchip/gic-v3: Dynamically allocate PPI NMI refcounts

2019-07-23 Thread Marc Zyngier
As we're about to have a variable number of PPIs, let's make the
allocation of the NMI refcounts dynamic. Also apply some minor
cleanups (moving things around).

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-v3.c | 47 ++--
 1 file changed, 34 insertions(+), 13 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 2d4ecf36d0fd..ec0f885fa373 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -88,7 +88,7 @@ static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
 static DEFINE_STATIC_KEY_FALSE(supports_pseudo_nmis);
 
 /* ppi_nmi_refs[n] == number of cpus having ppi[n + 16] set as NMI */
-static refcount_t ppi_nmi_refs[16];
+static refcount_t *ppi_nmi_refs;
 
 static struct gic_kvm_info gic_v3_kvm_info;
 static DEFINE_PER_CPU(bool, has_rss);
@@ -409,6 +409,16 @@ static void gic_irq_set_prio(struct irq_data *d, u8 prio)
writeb_relaxed(prio, base + offset + index);
 }
 
+static u32 gic_get_ppi_index(struct irq_data *d)
+{
+   switch (get_intid_range(d)) {
+   case PPI_RANGE:
+   return d->hwirq - 16;
+   default:
+   unreachable();
+   }
+}
+
 static int gic_irq_nmi_setup(struct irq_data *d)
 {
struct irq_desc *desc = irq_to_desc(d->irq);
@@ -429,10 +439,12 @@ static int gic_irq_nmi_setup(struct irq_data *d)
return -EINVAL;
 
/* desc lock should already be held */
-   if (gic_irq(d) < 32) {
+   if (gic_irq_in_rdist(d)) {
+   u32 idx = gic_get_ppi_index(d);
+
/* Setting up PPI as NMI, only switch handler for first NMI */
-   if (!refcount_inc_not_zero(_nmi_refs[gic_irq(d) - 16])) {
-   refcount_set(_nmi_refs[gic_irq(d) - 16], 1);
+   if (!refcount_inc_not_zero(_nmi_refs[idx])) {
+   refcount_set(_nmi_refs[idx], 1);
desc->handle_irq = handle_percpu_devid_fasteoi_nmi;
}
} else {
@@ -464,9 +476,11 @@ static void gic_irq_nmi_teardown(struct irq_data *d)
return;
 
/* desc lock should already be held */
-   if (gic_irq(d) < 32) {
+   if (gic_irq_in_rdist(d)) {
+   u32 idx = gic_get_ppi_index(d);
+
/* Tearing down NMI, only switch handler for last NMI */
-   if (refcount_dec_and_test(_nmi_refs[gic_irq(d) - 16]))
+   if (refcount_dec_and_test(_nmi_refs[idx]))
desc->handle_irq = handle_percpu_devid_irq;
} else {
desc->handle_irq = handle_fasteoi_irq;
@@ -1390,7 +1404,19 @@ static void gic_enable_nmi_support(void)
 {
int i;
 
-   for (i = 0; i < 16; i++)
+   if (!gic_prio_masking_enabled())
+   return;
+
+   if (gic_has_group0() && !gic_dist_security_disabled()) {
+   pr_warn("SCR_EL3.FIQ is cleared, cannot enable use of 
pseudo-NMIs\n");
+   return;
+   }
+
+   ppi_nmi_refs = kcalloc(gic_data.ppi_nr, sizeof(*ppi_nmi_refs), 
GFP_KERNEL);
+   if (!ppi_nmi_refs)
+   return;
+
+   for (i = 0; i < gic_data.ppi_nr; i++)
refcount_set(_nmi_refs[i], 0);
 
static_branch_enable(_pseudo_nmis);
@@ -1468,12 +1494,7 @@ static int __init gic_init_bases(void __iomem *dist_base,
gicv2m_init(handle, gic_data.domain);
}
 
-   if (gic_prio_masking_enabled()) {
-   if (!gic_has_group0() || gic_dist_security_disabled())
-   gic_enable_nmi_support();
-   else
-   pr_warn("SCR_EL3.FIQ is cleared, cannot enable use of 
pseudo-NMIs\n");
-   }
+   gic_enable_nmi_support();
 
return 0;
 
-- 
2.20.1



[PATCH 5/9] irqchip/gic: Prepare for more than 16 PPIs

2019-07-23 Thread Marc Zyngier
GICv3.1 allows up to 80 PPIs (16 legaci PPIs and 64 Extended PPIs),
meaning we can't just leave the old 16 hardcoded everywhere.

We also need to add the infrastructure to discuver the number of PPIs
on a per redistributor basis, although we still pretend there is only
16 of them for now.

No functional change.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-common.c | 19 ---
 drivers/irqchip/irq-gic-common.h |  2 +-
 drivers/irqchip/irq-gic-v3.c | 22 +++---
 drivers/irqchip/irq-gic.c|  2 +-
 drivers/irqchip/irq-hip04.c  |  2 +-
 5 files changed, 30 insertions(+), 17 deletions(-)

diff --git a/drivers/irqchip/irq-gic-common.c b/drivers/irqchip/irq-gic-common.c
index 6900b6f0921c..14110db01c05 100644
--- a/drivers/irqchip/irq-gic-common.c
+++ b/drivers/irqchip/irq-gic-common.c
@@ -128,26 +128,31 @@ void gic_dist_config(void __iomem *base, int gic_irqs,
sync_access();
 }
 
-void gic_cpu_config(void __iomem *base, void (*sync_access)(void))
+void gic_cpu_config(void __iomem *base, int nr, void (*sync_access)(void))
 {
int i;
 
/*
 * Deal with the banked PPI and SGI interrupts - disable all
-* PPI interrupts, ensure all SGI interrupts are enabled.
-* Make sure everything is deactivated.
+* private interrupts. Make sure everything is deactivated.
 */
-   writel_relaxed(GICD_INT_EN_CLR_X32, base + GIC_DIST_ACTIVE_CLEAR);
-   writel_relaxed(GICD_INT_EN_CLR_PPI, base + GIC_DIST_ENABLE_CLEAR);
-   writel_relaxed(GICD_INT_EN_SET_SGI, base + GIC_DIST_ENABLE_SET);
+   for (i = 0; i < nr; i += 32) {
+   writel_relaxed(GICD_INT_EN_CLR_X32,
+  base + GIC_DIST_ACTIVE_CLEAR + i / 8);
+   writel_relaxed(GICD_INT_EN_CLR_X32,
+  base + GIC_DIST_ENABLE_CLEAR + i / 8);
+   }
 
/*
 * Set priority on PPI and SGI interrupts
 */
-   for (i = 0; i < 32; i += 4)
+   for (i = 0; i < nr; i += 4)
writel_relaxed(GICD_INT_DEF_PRI_X4,
base + GIC_DIST_PRI + i * 4 / 4);
 
+   /* Ensure all SGI interrupts are now enabled */
+   writel_relaxed(GICD_INT_EN_SET_SGI, base + GIC_DIST_ENABLE_SET);
+
if (sync_access)
sync_access();
 }
diff --git a/drivers/irqchip/irq-gic-common.h b/drivers/irqchip/irq-gic-common.h
index 5a46b6b57750..ccba8b0fe0f5 100644
--- a/drivers/irqchip/irq-gic-common.h
+++ b/drivers/irqchip/irq-gic-common.h
@@ -22,7 +22,7 @@ int gic_configure_irq(unsigned int irq, unsigned int type,
void __iomem *base, void (*sync_access)(void));
 void gic_dist_config(void __iomem *base, int gic_irqs,
 void (*sync_access)(void));
-void gic_cpu_config(void __iomem *base, void (*sync_access)(void));
+void gic_cpu_config(void __iomem *base, int nr, void (*sync_access)(void));
 void gic_enable_quirks(u32 iidr, const struct gic_quirk *quirks,
void *data);
 void gic_enable_of_quirks(const struct device_node *np,
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index d328a8de533f..2d4ecf36d0fd 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -51,6 +51,7 @@ struct gic_chip_data {
u32 nr_redist_regions;
u64 flags;
boolhas_rss;
+   unsigned intppi_nr;
struct partition_desc   *ppi_descs[16];
 };
 
@@ -812,19 +813,24 @@ static int gic_populate_rdist(void)
return -ENODEV;
 }
 
-static int __gic_update_vlpi_properties(struct redist_region *region,
-   void __iomem *ptr)
+static int __gic_update_rdist_properties(struct redist_region *region,
+void __iomem *ptr)
 {
u64 typer = gic_read_typer(ptr + GICR_TYPER);
gic_data.rdists.has_vlpis &= !!(typer & GICR_TYPER_VLPIS);
gic_data.rdists.has_direct_lpi &= !!(typer & GICR_TYPER_DirectLPIS);
+   gic_data.ppi_nr = 16;
 
return 1;
 }
 
-static void gic_update_vlpi_properties(void)
+static void gic_update_rdist_properties(void)
 {
-   gic_iterate_rdists(__gic_update_vlpi_properties);
+   gic_data.ppi_nr = UINT_MAX;
+   gic_iterate_rdists(__gic_update_rdist_properties);
+   if (WARN_ON(gic_data.ppi_nr == UINT_MAX))
+   gic_data.ppi_nr = 0;
+   pr_info("%d PPIs implemented\n", gic_data.ppi_nr);
pr_info("%sVLPI support, %sdirect LPI support\n",
!gic_data.rdists.has_vlpis ? "no " : "",
!gic_data.rdists.has_direct_lpi ? "no " : "");
@@ -964,6 +970,7 @@ static int gic_dist_supports_lpis(void)
 static void gic_cpu_init(void)
 {
void __iomem *rbase;
+   int i;
 
/* Register ourselves with the rest of the world */
if (gic_populate_rdist())
@@ 

[PATCH 3/9] dt-bindings: interrupt-controller: arm,gic-v3: Describe ESPI range support

2019-07-23 Thread Marc Zyngier
GICv3.1 introduces support for new interrupt ranges, one of them being
the Extended SPI range (ESPI). The DT binding is extended to deal with
it as a new interrupt class.

Signed-off-by: Marc Zyngier 
---
 .../devicetree/bindings/interrupt-controller/arm,gic-v3.yaml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml 
b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
index c34df35a25fc..98a3ecda8e07 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
+++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
@@ -44,11 +44,12 @@ properties:
   be at least 4.
 
   The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
-  interrupts. Other values are reserved for future use.
+  interrupts, 2 for interrupts in the Extended SPI range. Other values
+  are reserved for future use.
 
   The 2nd cell contains the interrupt number for the interrupt type.
   SPI interrupts are in the range [0-987]. PPI interrupts are in the
-  range [0-15].
+  range [0-15]. Extented SPI interrupts are in the range [0-1023].
 
   The 3rd cell is the flags, encoded as follows:
   bits[3:0] trigger type and level flags.
-- 
2.20.1



[PATCH 4/9] irqchip/gic-v3: Add ESPI range support

2019-07-23 Thread Marc Zyngier
Add the required support for the ESPI range, which behave exactly like
the SPIs of old, only with new funky INTIDs.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-v3.c   | 85 --
 include/linux/irqchip/arm-gic-v3.h | 17 +-
 2 files changed, 85 insertions(+), 17 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 2371e0a70215..d328a8de533f 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -51,13 +51,16 @@ struct gic_chip_data {
u32 nr_redist_regions;
u64 flags;
boolhas_rss;
-   unsigned intirq_nr;
struct partition_desc   *ppi_descs[16];
 };
 
 static struct gic_chip_data gic_data __read_mostly;
 static DEFINE_STATIC_KEY_TRUE(supports_deactivate_key);
 
+#define GIC_ID_NR  (1U << GICD_TYPER_ID_BITS(gic_data.rdists.gicd_typer))
+#define GIC_LINE_NRGICD_TYPER_SPIS(gic_data.rdists.gicd_typer)
+#define GIC_ESPI_NRGICD_TYPER_ESPIS(gic_data.rdists.gicd_typer)
+
 /*
  * The behaviours of RPR and PMR registers differ depending on the value of
  * SCR_EL3.FIQ, and the behaviour of non-secure priority registers of the
@@ -100,6 +103,7 @@ static DEFINE_PER_CPU(bool, has_rss);
 enum gic_intid_range {
PPI_RANGE,
SPI_RANGE,
+   ESPI_RANGE,
LPI_RANGE,
__INVALID_RANGE__
 };
@@ -111,6 +115,8 @@ static enum gic_intid_range 
__get_intid_range(irq_hw_number_t hwirq)
return PPI_RANGE;
case 32 ... 1019:
return SPI_RANGE;
+   case ESPI_BASE_INTID ... 8191:
+   return ESPI_RANGE;
case 8192 ... GENMASK(23, 0):
return LPI_RANGE;
default:
@@ -141,6 +147,7 @@ static inline void __iomem *gic_dist_base(struct irq_data 
*d)
return gic_data_rdist_sgi_base();
 
case SPI_RANGE:
+   case ESPI_RANGE:
/* SPI -> dist_base */
return gic_data.dist_base;
 
@@ -234,6 +241,31 @@ static u32 convert_offset_index(struct irq_data *d, u32 
offset, u32 *index)
case SPI_RANGE:
*index = d->hwirq;
return offset;
+   case ESPI_RANGE:
+   *index = d->hwirq - ESPI_BASE_INTID;
+   switch (offset) {
+   case GICD_ISENABLER:
+   return GICD_ISENABLERnE;
+   case GICD_ICENABLER:
+   return GICD_ICENABLERnE;
+   case GICD_ISPENDR:
+   return GICD_ISPENDRnE;
+   case GICD_ICPENDR:
+   return GICD_ICPENDRnE;
+   case GICD_ISACTIVER:
+   return GICD_ISACTIVERnE;
+   case GICD_ICACTIVER:
+   return GICD_ICACTIVERnE;
+   case GICD_IPRIORITYR:
+   return GICD_IPRIORITYRnE;
+   case GICD_ICFGR:
+   return GICD_ICFGRnE;
+   case GICD_IROUTER:
+   return GICD_IROUTERnE;
+   default:
+   break;
+   }
+   break;
default:
break;
}
@@ -316,7 +348,7 @@ static int gic_irq_set_irqchip_state(struct irq_data *d,
 {
u32 reg;
 
-   if (d->hwirq >= gic_data.irq_nr) /* PPI/SPI only */
+   if (d->hwirq >= 8192) /* PPI/SPI only */
return -EINVAL;
 
switch (which) {
@@ -343,7 +375,7 @@ static int gic_irq_set_irqchip_state(struct irq_data *d,
 static int gic_irq_get_irqchip_state(struct irq_data *d,
 enum irqchip_irq_state which, bool *val)
 {
-   if (d->hwirq >= gic_data.irq_nr) /* PPI/SPI only */
+   if (d->hwirq >= 8192) /* PPI/SPI only */
return -EINVAL;
 
switch (which) {
@@ -567,7 +599,12 @@ static asmlinkage void __exception_irq_entry 
gic_handle_irq(struct pt_regs *regs
gic_arch_enable_irqs();
}
 
-   if (likely(irqnr > 15 && irqnr < 1020) || irqnr >= 8192) {
+   /* Check for special IDs first */
+   if ((irqnr >= 1020 && irqnr <= 1023))
+   return;
+
+   /* Treat anything but SGIs in a uniform way */
+   if (likely(irqnr > 15)) {
int err;
 
if (static_branch_likely(_deactivate_key))
@@ -655,10 +692,26 @@ static void __init gic_dist_init(void)
 * do the right thing if the kernel is running in secure mode,
 * but that's not the intended use case anyway.
 */
-   for (i = 32; i < gic_data.irq_nr; i += 32)
+   for (i = 32; i < GIC_LINE_NR; i += 32)
writel_relaxed(~0, base + GICD_IGROUPR + i / 8);
 
-   gic_dist_config(base, gic_data.irq_nr, gic_dist_wait_for_rwp);
+   /* Extended SPI range, not handled by the GICv2/GICv3 common code */
+   for (i = 0; i < GIC_ESPI_NR; i += 32) {
+

[PATCH] net: dsa: sja1105: sja1105_main: Add of_node_put()

2019-07-23 Thread Nishka Dasgupta
Each iteration of for_each_child_of_node puts the previous node, but in
the case of a return from the middle of the loop, there is no put, thus
causing a memory leak. Hence add an of_node_put before the return.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
 drivers/net/dsa/sja1105/sja1105_main.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/dsa/sja1105/sja1105_main.c 
b/drivers/net/dsa/sja1105/sja1105_main.c
index 32bf3a7cc3b6..6ed5f1e35789 100644
--- a/drivers/net/dsa/sja1105/sja1105_main.c
+++ b/drivers/net/dsa/sja1105/sja1105_main.c
@@ -625,6 +625,7 @@ static int sja1105_parse_ports_node(struct sja1105_private 
*priv,
if (of_property_read_u32(child, "reg", ) < 0) {
dev_err(dev, "Port number not defined in device tree "
"(property \"reg\")\n");
+   of_node_put(child);
return -ENODEV;
}
 
@@ -634,6 +635,7 @@ static int sja1105_parse_ports_node(struct sja1105_private 
*priv,
dev_err(dev, "Failed to read phy-mode or "
"phy-interface-type property for port %d\n",
index);
+   of_node_put(child);
return -ENODEV;
}
ports[index].phy_mode = phy_mode;
@@ -643,6 +645,7 @@ static int sja1105_parse_ports_node(struct sja1105_private 
*priv,
if (!of_phy_is_fixed_link(child)) {
dev_err(dev, "phy-handle or fixed-link "
"properties missing!\n");
+   of_node_put(child);
return -ENODEV;
}
/* phy-handle is missing, but fixed-link isn't.
-- 
2.19.1



[PATCH 2/9] irqchip/gic-v3: Add INTID range and convertion primitives

2019-07-23 Thread Marc Zyngier
In the beginning, life was simple. The GIC driver mostly cared about
PPIs, SPIs and LPIs, all with nicely layed out ranges.

We're about to change all that, with new ranges such as EPPI and ESPI
interleaved in the middle of the no-irq-land between the "special IDs"
and the LPI range. Boo.

In order to make our life less hellish, let's introduce a set of primitives
that will allow ranges to be identified easily and offsets to be remapped.

So far, there is no functionnal change.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic-v3.c | 112 ++-
 1 file changed, 83 insertions(+), 29 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 915b4ae8667f..2371e0a70215 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -97,6 +97,32 @@ static DEFINE_PER_CPU(bool, has_rss);
 /* Our default, arbitrary priority value. Linux only uses one anyway. */
 #define DEFAULT_PMR_VALUE  0xf0
 
+enum gic_intid_range {
+   PPI_RANGE,
+   SPI_RANGE,
+   LPI_RANGE,
+   __INVALID_RANGE__
+};
+
+static enum gic_intid_range __get_intid_range(irq_hw_number_t hwirq)
+{
+   switch (hwirq) {
+   case 16 ... 31:
+   return PPI_RANGE;
+   case 32 ... 1019:
+   return SPI_RANGE;
+   case 8192 ... GENMASK(23, 0):
+   return LPI_RANGE;
+   default:
+   return __INVALID_RANGE__;
+   }
+}
+
+static enum gic_intid_range get_intid_range(struct irq_data *d)
+{
+   return __get_intid_range(d->hwirq);
+}
+
 static inline unsigned int gic_irq(struct irq_data *d)
 {
return d->hwirq;
@@ -104,18 +130,23 @@ static inline unsigned int gic_irq(struct irq_data *d)
 
 static inline int gic_irq_in_rdist(struct irq_data *d)
 {
-   return gic_irq(d) < 32;
+   return get_intid_range(d) == PPI_RANGE;
 }
 
 static inline void __iomem *gic_dist_base(struct irq_data *d)
 {
-   if (gic_irq_in_rdist(d))/* SGI+PPI -> SGI_base for this CPU */
+   switch (get_intid_range(d)) {
+   case PPI_RANGE:
+   /* SGI+PPI -> SGI_base for this CPU */
return gic_data_rdist_sgi_base();
 
-   if (d->hwirq <= 1023)   /* SPI -> dist_base */
+   case SPI_RANGE:
+   /* SPI -> dist_base */
return gic_data.dist_base;
 
-   return NULL;
+   default:
+   return NULL;
+   }
 }
 
 static void gic_do_wait_for_rwp(void __iomem *base)
@@ -196,24 +227,46 @@ static void gic_enable_redist(bool enable)
 /*
  * Routines to disable, enable, EOI and route interrupts
  */
+static u32 convert_offset_index(struct irq_data *d, u32 offset, u32 *index)
+{
+   switch (get_intid_range(d)) {
+   case PPI_RANGE:
+   case SPI_RANGE:
+   *index = d->hwirq;
+   return offset;
+   default:
+   break;
+   }
+
+   WARN_ON(1);
+   *index = d->hwirq;
+   return offset;
+}
+
 static int gic_peek_irq(struct irq_data *d, u32 offset)
 {
-   u32 mask = 1 << (gic_irq(d) % 32);
void __iomem *base;
+   u32 index, mask;
+
+   offset = convert_offset_index(d, offset, );
+   mask = 1 << (index % 32);
 
if (gic_irq_in_rdist(d))
base = gic_data_rdist_sgi_base();
else
base = gic_data.dist_base;
 
-   return !!(readl_relaxed(base + offset + (gic_irq(d) / 32) * 4) & mask);
+   return !!(readl_relaxed(base + offset + (index / 32) * 4) & mask);
 }
 
 static void gic_poke_irq(struct irq_data *d, u32 offset)
 {
-   u32 mask = 1 << (gic_irq(d) % 32);
void (*rwp_wait)(void);
void __iomem *base;
+   u32 index, mask;
+
+   offset = convert_offset_index(d, offset, );
+   mask = 1 << (index % 32);
 
if (gic_irq_in_rdist(d)) {
base = gic_data_rdist_sgi_base();
@@ -223,7 +276,7 @@ static void gic_poke_irq(struct irq_data *d, u32 offset)
rwp_wait = gic_dist_wait_for_rwp;
}
 
-   writel_relaxed(mask, base + offset + (gic_irq(d) / 32) * 4);
+   writel_relaxed(mask, base + offset + (index / 32) * 4);
rwp_wait();
 }
 
@@ -316,8 +369,11 @@ static int gic_irq_get_irqchip_state(struct irq_data *d,
 static void gic_irq_set_prio(struct irq_data *d, u8 prio)
 {
void __iomem *base = gic_dist_base(d);
+   u32 offset, index;
 
-   writeb_relaxed(prio, base + GICD_IPRIORITYR + gic_irq(d));
+   offset = convert_offset_index(d, GICD_IPRIORITYR, );
+
+   writeb_relaxed(prio, base + offset + index);
 }
 
 static int gic_irq_nmi_setup(struct irq_data *d)
@@ -407,6 +463,7 @@ static int gic_set_type(struct irq_data *d, unsigned int 
type)
unsigned int irq = gic_irq(d);
void (*rwp_wait)(void);
void __iomem *base;
+   u32 offset, index;
int ret;
 
/* Interrupt configuration for SGIs can't be changed */
@@ -426,8 +483,9 @@ static int 

[PATCH 0/9] irqchip/gic-v3: Add support for GICv3.1 extended PPI/SPI ranges

2019-07-23 Thread Marc Zyngier
Apparently, having ~1000 wired interrupts is not enough, and some
people need more. Fear not! The GIC Achitecture Department hereby
grants you another 1024 SPIs, together with 64 PPIs, provided that you
implement GICv3.1 (see [1] for the details)

This series implements the required support, which requires a bit of
infrastructure rework in order to make the thing less horrible...

This has been tested on a FastModel.

[1] https://developer.arm.com/docs/ihi0069/latest (version E)

Marc Zyngier (9):
  irqchip/gic: Rework gic_configure_irq to take the full ICFGR base
  irqchip/gic-v3: Add INTID range and convertion primitives
  dt-bindings: interrupt-controller: arm,gic-v3: Describe ESPI range
support
  irqchip/gic-v3: Add ESPI range support
  irqchip/gic: Prepare for more than 16 PPIs
  irqchip/gic-v3: Dynamically allocate PPI NMI refcounts
  irqchip/gic-v3: Dynamically allocate PPI partition descriptors
  dt-bindings: interrupt-controller: arm,gic-v3: Describe EPPI range
support
  irqchip/gic-v3: Add EPPI range support

 .../interrupt-controller/arm,gic-v3.yaml  |   6 +-
 drivers/irqchip/irq-gic-common.c  |  33 +-
 drivers/irqchip/irq-gic-common.h  |   2 +-
 drivers/irqchip/irq-gic-v3.c  | 323 ++
 drivers/irqchip/irq-gic.c |  12 +-
 drivers/irqchip/irq-hip04.c   |   9 +-
 include/linux/irqchip/arm-gic-v3.h|  29 +-
 7 files changed, 319 insertions(+), 95 deletions(-)

-- 
2.20.1



Re: WARNING in __mmdrop

2019-07-23 Thread Michael S. Tsirkin
On Tue, Jul 23, 2019 at 04:42:19PM +0800, Jason Wang wrote:
> > So how about this: do exactly what you propose but as a 2 patch series:
> > start with the slow safe patch, and add then return uaddr optimizations
> > on top. We can then more easily reason about whether they are safe.
> 
> 
> If you stick, I can do this.

So I definitely don't insist but I'd like us to get back to where
we know existing code is very safe (if not super fast) and
optimizing from there.  Bugs happen but I'd like to see a bisect
giving us "oh it's because of XYZ optimization" and not the
general "it's somewhere within this driver" that we are getting
now.

Maybe the way to do this is to revert for this release cycle
and target the next one. What do you think?

-- 
MST


[PATCH] irqchip: irq-mbigen: Add of_node_put() before return

2019-07-23 Thread Nishka Dasgupta
Each iteration of for_each_child_of_node puts the previous node, but
in the case of a return from the middle of the loop, there is no put,
thus causing a memory leak. Add an of_node_put before the return in
three places.
Issue found with Coccinelle.

Signed-off-by: Nishka Dasgupta 
---
 drivers/irqchip/irq-mbigen.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-mbigen.c b/drivers/irqchip/irq-mbigen.c
index 3dd28382d5f5..3f09f658e8e2 100644
--- a/drivers/irqchip/irq-mbigen.c
+++ b/drivers/irqchip/irq-mbigen.c
@@ -241,12 +241,15 @@ static int mbigen_of_create_domain(struct platform_device 
*pdev,
 
parent = platform_bus_type.dev_root;
child = of_platform_device_create(np, NULL, parent);
-   if (!child)
+   if (!child) {
+   of_node_put(np);
return -ENOMEM;
+   }
 
if (of_property_read_u32(child->dev.of_node, "num-pins",
 _pins) < 0) {
dev_err(>dev, "No num-pins property\n");
+   of_node_put(np);
return -EINVAL;
}
 
@@ -254,8 +257,10 @@ static int mbigen_of_create_domain(struct platform_device 
*pdev,
   mbigen_write_msg,
   _domain_ops,
   mgn_chip);
-   if (!domain)
+   if (!domain) {
+   of_node_put(np);
return -ENOMEM;
+   }
}
 
return 0;
-- 
2.19.1



[PATCH] drm/gma500: Use dev_get_drvdata where possible

2019-07-23 Thread Chuhong Yuan
Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan 
---
 drivers/gpu/drm/gma500/power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/power.c b/drivers/gpu/drm/gma500/power.c
index bea8578846d1..d67e01ce7766 100644
--- a/drivers/gpu/drm/gma500/power.c
+++ b/drivers/gpu/drm/gma500/power.c
@@ -308,7 +308,7 @@ int psb_runtime_resume(struct device *dev)
 
 int psb_runtime_idle(struct device *dev)
 {
-   struct drm_device *drmdev = pci_get_drvdata(to_pci_dev(dev));
+   struct drm_device *drmdev = dev_get_drvdata(dev);
struct drm_psb_private *dev_priv = drmdev->dev_private;
if (dev_priv->display_count)
return 0;
-- 
2.20.1



Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool

2019-07-23 Thread Jon Hunter


On 23/07/2019 11:07, Jose Abreu wrote:
> From: Jon Hunter 
> Date: Jul/23/2019, 11:01:24 (UTC+00:00)
> 
>> This appears to be a winner and by disabling the SMMU for the ethernet
>> controller and reverting commit 954a03be033c7cef80ddc232e7cbdb17df735663
>> this worked! So yes appears to be related to the SMMU being enabled. We
>> had to enable the SMMU for ethernet recently due to commit
>> 954a03be033c7cef80ddc232e7cbdb17df735663.
> 
> Finally :)
> 
> However, from "git show 954a03be033c7cef80ddc232e7cbdb17df735663":
> 
> + There are few reasons to allow unmatched stream bypass, and
> + even fewer good ones.  If saying YES here breaks your board
> + you should work on fixing your board.
> 
> So, how can we fix this ? Is your ethernet DT node marked as 
> "dma-coherent;" ?

TBH I have no idea. I can't say I fully understand your change or how it
is breaking things for us.

Currently, the Tegra DT binding does not have 'dma-coherent' set. I see
this is optional, but I am not sure how you determine whether or not
this should be set.

Jon

-- 
nvpublic


Re: [PATCH v9 2/8] sched/core: Streamlining calls to task_rq_unlock()

2019-07-23 Thread Peter Zijlstra
On Mon, Jul 22, 2019 at 11:08:17AM +0200, Dietmar Eggemann wrote:

> Not sure, there is another little issue on 3/8 since uclamp is in
> v5.3-rc1 as well commit 69842cba9ace8 ("sched/uclamp: Add CPU's clamp
> buckets refcounting").

Also, 8/8, but all conflicts are trivial and I've fixed them up.


Re: [PATCH v9 2/8] sched/core: Streamlining calls to task_rq_unlock()

2019-07-23 Thread Peter Zijlstra
On Mon, Jul 22, 2019 at 10:32:14AM +0200, Juri Lelli wrote:

> Thanks for reporting. The set is based on cgroup/for-next (as of last
> week), though. I can of course rebase on tip/sched/core or mainline if
> needed.

TJ; I would like to take these patches through the scheduler tree if you
don't mind. Afaict there's no real conflict vs cgroup/for-next (I
applied the patches and then did a pull of cgroup/for-next which
finished without complaints).



Re: [PATCH] phy: qcom-qmp: Correct READY_STATUS poll break condition

2019-07-23 Thread Marc Gonzalez
On 19/07/2019 17:50, Marc Gonzalez wrote:

> On 13/06/2019 11:10, Marc Gonzalez wrote:
> 
>> Here are my observations for a 8998 board:
>>
>> 1) If I apply only the readl_poll_timeout() fix (not the mask_pcs_ready 
>> fixup)
>> qcom_pcie_probe() fails with a timeout in phy_init.
>> => this is in line with your regression analysis.
>>
>> 2) Your patch also fixes a long-standing bug in UFS init whereby sending
>> lots of information to the console during phy init would lead to an
>> incorrectly diagnosed time-out.
>>
>> Good stuff!
>>
>> Reviewed-by: Marc Gonzalez 
>> Tested-by: Marc Gonzalez 
> 
> It looks like this patch fixed UFS, but broke PCIe and USB3 ^_^
> 
> qcom-qmp-phy 1c06000.phy: Registered Qcom-QMP phy
> qcom-qmp-phy c01.phy: Registered Qcom-QMP phy
> qcom-qmp-phy 1da7000.phy: Registered Qcom-QMP phy
> 
> qcom-qmp-phy 1c06000.phy: BEFORE=00a6 AFTER=00a6
> qcom-qmp-phy 1c06000.phy: phy initialization timed-out
> phy phy-1c06000.phy.0: phy init failed --> -110
> qcom-pcie: probe of 1c0.pci failed with error -110
> 
> qcom-qmp-phy 1da7000.phy: BEFORE=0040 AFTER=000d
> 
> qcom-qmp-phy c01.phy: BEFORE=69696969 AFTER=b7b7b7b7
> qcom-qmp-phy c01.phy: phy initialization timed-out
> phy phy-c01.phy.1: phy init failed --> -110
> dwc3 a80.dwc3: failed to initialize core: -110
> dwc3: probe of a80.dwc3 failed with error -110
> 
> 
> Downstream code for PCIe is:
> 
> static bool pcie_phy_is_ready(struct msm_pcie_dev_t *dev)
> {
>   if (dev->phy_ver >= 0x20) {
>   if (readl_relaxed(dev->phy + PCIE_N_PCS_STATUS(dev->rc_idx, 
> dev->common_phy)) & BIT(6))
>   return false;
>   else
>   return true;
>   }
> 
>   if (!(readl_relaxed(dev->phy + PCIE_COM_PCS_READY_STATUS) & 0x1))
>   return false;
>   else
>   return true;
> }
> 
> AFAICT:
> PCIe and USB3 QMP PHYs are ready when PHYSTATUS=BIT(6) goes to 0.
> But UFS is ready when PCS_READY=BIT(0) goes to 1.
> 
> 
> Can someone verify that USB3 is broken on 845 with 885bd765963b?

Suggested fix:

diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c 
b/drivers/phy/qualcomm/phy-qcom-qmp.c
index 34ff6434da8f..11c1b02f0206 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
@@ -1447,6 +1447,11 @@ static int qcom_qmp_phy_com_exit(struct qcom_qmp *qmp)
return 0;
 }
 
+static bool phy_is_ready(unsigned int val, unsigned int mask)
+{
+   return mask == PCS_READY ? val & mask : !(val & mask);
+}
+
 static int qcom_qmp_phy_enable(struct phy *phy)
 {
struct qmp_phy *qphy = phy_get_drvdata(phy);
@@ -1548,7 +1553,7 @@ static int qcom_qmp_phy_enable(struct phy *phy)
status = pcs + cfg->regs[QPHY_PCS_READY_STATUS];
mask = cfg->mask_pcs_ready;
 
-   ret = readl_poll_timeout(status, val, val & mask, 10,
+   ret = readl_poll_timeout(status, val, phy_is_ready(val, mask), 10,
 PHY_INIT_COMPLETE_TIMEOUT);
if (ret) {
dev_err(qmp->dev, "phy initialization timed-out\n");


Re: [PATCH v3 3/5] OPP: Improve require-opps linking

2019-07-23 Thread Viresh Kumar
$subject doesn't have correct property name.

On 17-07-19, 15:23, Saravana Kannan wrote:
> Currently, the linking of required-opps fails silently if the
> destination OPP table hasn't been added before the source OPP table is
> added. This puts an unnecessary requirement that the destination table
> be added before the source table is added.
> 
> In reality, the destination table is needed only when we try to
> translate from source OPP to destination OPP. So, instead of
> completely failing, retry linking the tables when the translation is
> attempted.
> 
> Signed-off-by: Saravana Kannan 
> ---
>  drivers/opp/core.c | 32 +++-
>  drivers/opp/of.c   | 91 ++
>  drivers/opp/opp.h  |  5 +++
>  3 files changed, 71 insertions(+), 57 deletions(-)

Here is the general feedback and requirements I have:

- We shouldn't do it from _set_required_opps() but way earlier, it
  shouldn't affect the fast path (where we change the frequency).

- Programming required-opps for half of the properties isn't correct,
  i.e. in case only few of the required-opps are parsed until now. So
  setting of rate shouldn't even start unless the OPP table is fully
  initialized with all required-opps in it.

-- 
viresh


Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool

2019-07-23 Thread Robin Murphy

On 23/07/2019 11:07, Jose Abreu wrote:

From: Jon Hunter 
Date: Jul/23/2019, 11:01:24 (UTC+00:00)


This appears to be a winner and by disabling the SMMU for the ethernet
controller and reverting commit 954a03be033c7cef80ddc232e7cbdb17df735663
this worked! So yes appears to be related to the SMMU being enabled. We
had to enable the SMMU for ethernet recently due to commit
954a03be033c7cef80ddc232e7cbdb17df735663.


Finally :)

However, from "git show 954a03be033c7cef80ddc232e7cbdb17df735663":

+ There are few reasons to allow unmatched stream bypass, and
+ even fewer good ones.  If saying YES here breaks your board
+ you should work on fixing your board.

So, how can we fix this ? Is your ethernet DT node marked as
"dma-coherent;" ?


The first thing to try would be booting the failing setup with 
"iommu.passthrough=1" (or using CONFIG_IOMMU_DEFAULT_PASSTHROUGH) - if 
that makes things seem OK, then the problem is likely related to address 
translation; if not, then it's probably time to start looking at nasties 
like coherency and ordering, although in principle I wouldn't expect the 
SMMU to have too much impact there.


Do you know if the SMMU interrupts are working correctly? If not, it's 
possible that an incorrect address or mapping direction could lead to 
the DMA transaction just being silently terminated without any fault 
indication, which generally presents as inexplicable weirdness (I've 
certainly seen that on another platform with the mix of an unsupported 
interrupt controller and an 'imperfect' ethernet driver).


Just to confirm, has the original patch been tested with 
CONFIG_DMA_API_DEBUG to rule out any high-level mishaps?


Robin.


[PATCH] hexagon: remove asm/bitsperlong.h

2019-07-23 Thread Masahiro Yamada
Remove hexagon-specific bitsperlong.h so that it falls back to
include/uapi/asm-generic/bitsperlong.h

Kbuild will automatically create a wrapper of it.

Signed-off-by: Masahiro Yamada 
---

 arch/hexagon/include/uapi/asm/bitsperlong.h | 27 -
 1 file changed, 27 deletions(-)
 delete mode 100644 arch/hexagon/include/uapi/asm/bitsperlong.h

diff --git a/arch/hexagon/include/uapi/asm/bitsperlong.h 
b/arch/hexagon/include/uapi/asm/bitsperlong.h
deleted file mode 100644
index 5adca0d26913..
--- a/arch/hexagon/include/uapi/asm/bitsperlong.h
+++ /dev/null
@@ -1,27 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * Copyright (c) 2010-2011, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
- * 02110-1301, USA.
- */
-
-#ifndef __ASM_HEXAGON_BITSPERLONG_H
-#define __ASM_HEXAGON_BITSPERLONG_H
-
-#define __BITS_PER_LONG 32
-
-#include 
-
-#endif
-- 
2.17.1



Re: WARNING in __mmdrop

2019-07-23 Thread Michael S. Tsirkin
On Tue, Jul 23, 2019 at 04:42:19PM +0800, Jason Wang wrote:
> 
> On 2019/7/23 下午3:56, Michael S. Tsirkin wrote:
> > On Tue, Jul 23, 2019 at 01:48:52PM +0800, Jason Wang wrote:
> > > On 2019/7/23 下午1:02, Michael S. Tsirkin wrote:
> > > > On Tue, Jul 23, 2019 at 11:55:28AM +0800, Jason Wang wrote:
> > > > > On 2019/7/22 下午4:02, Michael S. Tsirkin wrote:
> > > > > > On Mon, Jul 22, 2019 at 01:21:59PM +0800, Jason Wang wrote:
> > > > > > > On 2019/7/21 下午6:02, Michael S. Tsirkin wrote:
> > > > > > > > On Sat, Jul 20, 2019 at 03:08:00AM -0700, syzbot wrote:
> > > > > > > > > syzbot has bisected this bug to:
> > > > > > > > > 
> > > > > > > > > commit 7f466032dc9e5a61217f22ea34b2df932786bbfc
> > > > > > > > > Author: Jason Wang 
> > > > > > > > > Date:   Fri May 24 08:12:18 2019 +
> > > > > > > > > 
> > > > > > > > > vhost: access vq metadata through kernel virtual 
> > > > > > > > > address
> > > > > > > > > 
> > > > > > > > > bisection log:  
> > > > > > > > > https://syzkaller.appspot.com/x/bisect.txt?x=149a8a2060
> > > > > > > > > start commit:   6d21a41b Add linux-next specific files for 
> > > > > > > > > 20190718
> > > > > > > > > git tree:   linux-next
> > > > > > > > > final crash:
> > > > > > > > > https://syzkaller.appspot.com/x/report.txt?x=169a8a2060
> > > > > > > > > console output: 
> > > > > > > > > https://syzkaller.appspot.com/x/log.txt?x=129a8a2060
> > > > > > > > > kernel config:  
> > > > > > > > > https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
> > > > > > > > > dashboard link: 
> > > > > > > > > https://syzkaller.appspot.com/bug?extid=e58112d71f77113ddb7b
> > > > > > > > > syz repro:  
> > > > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=10139e6860
> > > > > > > > > 
> > > > > > > > > Reported-by: 
> > > > > > > > > syzbot+e58112d71f77113dd...@syzkaller.appspotmail.com
> > > > > > > > > Fixes: 7f466032dc9e ("vhost: access vq metadata through 
> > > > > > > > > kernel virtual
> > > > > > > > > address")
> > > > > > > > > 
> > > > > > > > > For information about bisection process see: 
> > > > > > > > > https://goo.gl/tpsmEJ#bisection
> > > > > > > > OK I poked at this for a bit, I see several things that
> > > > > > > > we need to fix, though I'm not yet sure it's the reason for
> > > > > > > > the failures:
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 1. mmu_notifier_register shouldn't be called from 
> > > > > > > > vhost_vring_set_num_addr
> > > > > > > >That's just a bad hack,
> > > > > > > This is used to avoid holding lock when checking whether the 
> > > > > > > addresses are
> > > > > > > overlapped. Otherwise we need to take spinlock for each 
> > > > > > > invalidation request
> > > > > > > even if it was the va range that is not interested for us. This 
> > > > > > > will be very
> > > > > > > slow e.g during guest boot.
> > > > > > KVM seems to do exactly that.
> > > > > > I tried and guest does not seem to boot any slower.
> > > > > > Do you observe any slowdown?
> > > > > Yes I do.
> > > > > 
> > > > > 
> > > > > > Now I took a hard look at the uaddr hackery it really makes
> > > > > > me nervious. So I think for this release we want something
> > > > > > safe, and optimizations on top. As an alternative revert the
> > > > > > optimization and try again for next merge window.
> > > > > Will post a series of fixes, let me know if you're ok with that.
> > > > > 
> > > > > Thanks
> > > > I'd prefer you to take a hard look at the patch I posted
> > > > which makes code cleaner,
> > > 
> > > I did. But it looks to me a series that is only about 60 lines of code can
> > > fix all the issues we found without reverting the uaddr optimization.
> > Another thing I like about the patch I posted is that
> > it removes 60 lines of code, instead of adding more :)
> > Mostly because of unifying everything into
> > a single cleanup function and using kfree_rcu.
> 
> 
> Yes.
> 
> 
> > 
> > So how about this: do exactly what you propose but as a 2 patch series:
> > start with the slow safe patch, and add then return uaddr optimizations
> > on top. We can then more easily reason about whether they are safe.
> 
> 
> If you stick, I can do this.

Given I realized my patch is buggy in that
it does not wait for outstanding maps, I don't
insist.

> 
> > Basically you are saying this:
> > - notifiers are only needed to invalidate maps
> > - we make sure any uaddr change invalidates maps anyway
> > - thus it's ok not to have notifiers since we do
> >   not have maps
> > 
> > All this looks ok but the question is why do we
> > bother unregistering them. And the answer seems to
> > be that this is so we can start with a balanced
> > counter: otherwise we can be between _start and
> > _end calls.
> 
> 
> Yes, since there could be multiple co-current invalidation requests. We need
> count them to make sure we don't pin wrong pages.
> 
> 
> > 
> > I also wonder about ordering. kvm has this:
> > /*
> >   

Re: [PATCH] cpufreq: schedutil: Don't skip freq update when limits change

2019-07-23 Thread Rafael J. Wysocki
On Tue, Jul 23, 2019 at 11:15 AM Viresh Kumar  wrote:
>
> On 23-07-19, 00:10, Doug Smythies wrote:
> > On 2019.07.21 23:52 Viresh Kumar wrote:
> >
> > > To avoid reducing the frequency of a CPU prematurely, we skip reducing
> > > the frequency if the CPU had been busy recently.
> > >
> > > This should not be done when the limits of the policy are changed, for
> > > example due to thermal throttling. We should always get the frequency
> > > within limits as soon as possible.
> > >
> > > Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to 
> > > UINT_MAX")
> > > Cc: v4.18+  # v4.18+
> > > Reported-by: Doug Smythies 
> > > Signed-off-by: Viresh Kumar 
> > > ---
> > > @Doug: Please try this patch, it must fix the issue you reported.
> >
> > It fixes the driver = acpi-cpufreq ; governor = schedutil test case
> > It does not fix the driver = intel_cpufreq ; governor = schedutil test case
> >
> > I have checked my results twice, but will check again in the day or two.
>
> The patch you tried to revert wasn't doing any driver specific stuff
> but only schedutil. If that revert fixes your issue with both the
> drivers, then this patch should do it as well.
>
> I am clueless now on what can go wrong with intel_cpufreq driver with
> schedutil now.
>
> Though there is one difference between intel_cpufreq and acpi_cpufreq,
> intel_cpufreq has fast_switch_possible=true and so it uses slightly
> different path in schedutil. I tried to look from that perspective as
> well but couldn't find anything wrong.

acpi-cpufreq should use fast switching on the Doug's system too.

> If you still find intel_cpufreq to be broken, even with this patch,
> please set fast_switch_possible=false instead of true in
> __intel_pstate_cpu_init() and try tests again. That shall make it very
> much similar to acpi-cpufreq driver.

I wonder if this helps.  Even so, we want fast switching to be used by
intel_cpufreq.

Anyway, it looks like the change reverted by the Doug's patch
introduced a race condition that had not been present before.  Namely,
need_freq_update is cleared in get_next_freq() when it is set _or_
when the new freq is different from the cached one, so in the latter
case if it happens to be set by sugov_limits() after evaluating
sugov_should_update_freq() (which returned 'true' for timing reasons),
that update will be lost now. [Previously the update would not be
lost, because the clearing of need_freq_update depended only on its
current value.] Where it matters is that in the "need_freq_update set"
case, the "premature frequency reduction avoidance" should not be
applied (as you noticed and hence the $subject patch).

However, even with the $subject patch, need_freq_update may still be
set by sugov_limits() after the check added by it and then cleared by
get_next_freq(), so it doesn't really eliminate the problem.

IMO eliminating would require invalidating next_freq this way or
another when need_freq_update is set in sugov_should_update_freq(),
which was done before commit ecd2884291261e3fddbc7651ee11a20d596bb514.


[PATCH 2/2] dt-bindings: IDU-intc: Add support for edge-triggered interrupts

2019-07-23 Thread Mischa Jonker
This updates the documentation for supporting  a optional extra interrupt
cell to specify edge vs level triggered.

Signed-off-by: Mischa Jonker 
---
 .../interrupt-controller/snps,archs-idu-intc.txt   | 30 ++
 1 file changed, 20 insertions(+), 10 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt
index 09fc02b..a5c1db9 100644
--- 
a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt
@@ -1,20 +1,30 @@
 * ARC-HS Interrupt Distribution Unit
 
-  This optional 2nd level interrupt controller can be used in SMP 
configurations for
-  dynamic IRQ routing, load balancing of common/external IRQs towards core 
intc.
+  This optional 2nd level interrupt controller can be used in SMP 
configurations
+  for dynamic IRQ routing, load balancing of common/external IRQs towards core
+  intc.
 
 Properties:
 
 - compatible: "snps,archs-idu-intc"
 - interrupt-controller: This is an interrupt controller.
-- #interrupt-cells: Must be <1>.
-
-  Value of the cell specifies the "common" IRQ from peripheral to IDU. Number N
-  of the particular interrupt line of IDU corresponds to the line N+24 of the
-  core interrupt controller.
-
-  intc accessed via the special ARC AUX register interface, hence "reg" 
property
-  is not specified.
+- #interrupt-cells: Must be <1> or <2>.
+
+  Value of the first cell specifies the "common" IRQ from peripheral to IDU.
+  Number N of the particular interrupt line of IDU corresponds to the line N+24
+  of the core interrupt controller.
+
+  The (optional) second cell specifies any of the following flags:
+- bits[3:0] trigger type and level flags
+1 = low-to-high edge triggered
+2 = NOT SUPPORTED (high-to-low edge triggered)
+4 = active high level-sensitive <<< DEFAULT
+8 = NOT SUPPORTED (active low level-sensitive)
+  When no second cell is specified, the interrupt is assumed to be level
+  sensitive.
+
+  The interrupt controller is accessed via the special ARC AUX register
+  interface, hence "reg" property is not specified.
 
 Example:
core_intc: core-interrupt-controller {
-- 
2.8.3



[PATCH 1/2] ARCv2: IDU-intc: Add support for edge-triggered interrupts

2019-07-23 Thread Mischa Jonker
This adds support for an optional extra interrupt cell to specify edge
vs level triggered. It is backward compatible with dts files with only
one cell, and will default to level-triggered in such a case.

Signed-off-by: Mischa Jonker 
---
 arch/arc/kernel/mcip.c | 56 --
 include/soc/arc/mcip.h | 11 ++
 2 files changed, 61 insertions(+), 6 deletions(-)

diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c
index 18b493d..fc45564 100644
--- a/arch/arc/kernel/mcip.c
+++ b/arch/arc/kernel/mcip.c
@@ -202,8 +202,8 @@ static void idu_set_dest(unsigned int cmn_irq, unsigned int 
cpu_mask)
__mcip_cmd_data(CMD_IDU_SET_DEST, cmn_irq, cpu_mask);
 }
 
-static void idu_set_mode(unsigned int cmn_irq, unsigned int lvl,
-  unsigned int distr)
+static void idu_set_mode(unsigned int cmn_irq, bool set_lvl, unsigned int lvl,
+bool set_distr, unsigned int distr)
 {
union {
unsigned int word;
@@ -212,8 +212,11 @@ static void idu_set_mode(unsigned int cmn_irq, unsigned 
int lvl,
};
} data;
 
-   data.distr = distr;
-   data.lvl = lvl;
+   data.word = __mcip_cmd_read(CMD_IDU_READ_MODE, cmn_irq);
+   if (set_distr)
+   data.distr = distr;
+   if (set_lvl)
+   data.lvl = lvl;
__mcip_cmd_data(CMD_IDU_SET_MODE, cmn_irq, data.word);
 }
 
@@ -240,6 +243,25 @@ static void idu_irq_unmask(struct irq_data *data)
raw_spin_unlock_irqrestore(_lock, flags);
 }
 
+static void idu_irq_ack(struct irq_data *data)
+{
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(_lock, flags);
+   __mcip_cmd(CMD_IDU_ACK_CIRQ, data->hwirq);
+   raw_spin_unlock_irqrestore(_lock, flags);
+}
+
+static void idu_irq_mask_ack(struct irq_data *data)
+{
+   unsigned long flags;
+
+   raw_spin_lock_irqsave(_lock, flags);
+   __mcip_cmd_data(CMD_IDU_SET_MASK, data->hwirq, 1);
+   __mcip_cmd(CMD_IDU_ACK_CIRQ, data->hwirq);
+   raw_spin_unlock_irqrestore(_lock, flags);
+}
+
 static int
 idu_irq_set_affinity(struct irq_data *data, const struct cpumask *cpumask,
 bool force)
@@ -263,13 +285,32 @@ idu_irq_set_affinity(struct irq_data *data, const struct 
cpumask *cpumask,
else
distribution_mode = IDU_M_DISTRI_RR;
 
-   idu_set_mode(data->hwirq, IDU_M_TRIG_LEVEL, distribution_mode);
+   idu_set_mode(data->hwirq, false, 0, true, distribution_mode);
 
raw_spin_unlock_irqrestore(_lock, flags);
 
return IRQ_SET_MASK_OK;
 }
 
+static int idu_irq_set_type(struct irq_data *data, u32 type)
+{
+   unsigned long flags;
+
+   if (type & ~(IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH))
+   return -EINVAL;
+
+   raw_spin_lock_irqsave(_lock, flags);
+
+   idu_set_mode(data->hwirq, true,
+type & IRQ_TYPE_EDGE_RISING ? IDU_M_TRIG_EDGE :
+  IDU_M_TRIG_LEVEL,
+false, 0);
+
+   raw_spin_unlock_irqrestore(_lock, flags);
+
+   return 0;
+}
+
 static void idu_irq_enable(struct irq_data *data)
 {
/*
@@ -289,7 +330,10 @@ static struct irq_chip idu_irq_chip = {
.name   = "MCIP IDU Intc",
.irq_mask   = idu_irq_mask,
.irq_unmask = idu_irq_unmask,
+   .irq_ack= idu_irq_ack,
+   .irq_mask_ack   = idu_irq_mask_ack,
.irq_enable = idu_irq_enable,
+   .irq_set_type   = idu_irq_set_type,
 #ifdef CONFIG_SMP
.irq_set_affinity   = idu_irq_set_affinity,
 #endif
@@ -317,7 +361,7 @@ static int idu_irq_map(struct irq_domain *d, unsigned int 
virq, irq_hw_number_t
 }
 
 static const struct irq_domain_ops idu_irq_ops = {
-   .xlate  = irq_domain_xlate_onecell,
+   .xlate  = irq_domain_xlate_onetwocell,
.map= idu_irq_map,
 };
 
diff --git a/include/soc/arc/mcip.h b/include/soc/arc/mcip.h
index 50f49e0..d1a93c7 100644
--- a/include/soc/arc/mcip.h
+++ b/include/soc/arc/mcip.h
@@ -46,7 +46,9 @@ struct mcip_cmd {
 #define CMD_IDU_ENABLE 0x71
 #define CMD_IDU_DISABLE0x72
 #define CMD_IDU_SET_MODE   0x74
+#define CMD_IDU_READ_MODE  0x75
 #define CMD_IDU_SET_DEST   0x76
+#define CMD_IDU_ACK_CIRQ   0x79
 #define CMD_IDU_SET_MASK   0x7C
 
 #define IDU_M_TRIG_LEVEL   0x0
@@ -119,4 +121,13 @@ static inline void __mcip_cmd_data(unsigned int cmd, 
unsigned int param,
__mcip_cmd(cmd, param);
 }
 
+/*
+ * Read MCIP register
+ */
+static inline unsigned int __mcip_cmd_read(unsigned int cmd, unsigned int 
param)
+{
+   __mcip_cmd(cmd, param);
+   return read_aux_reg(ARC_REG_MCIP_READBACK);
+}
+
 #endif
-- 
2.8.3



Re: [GIT PULL] pidfd fixes

2019-07-23 Thread Christian Brauner
On Tue, Jul 23, 2019 at 12:12:49PM +0200, Oleg Nesterov wrote:
> On 07/22, Linus Torvalds wrote:
> >
> > So if we set EXIT_ZOMBIE early, then I think we should change the
> > EXIT_DEAD case too. IOW, do something like this on top:
> > 
> >   --- a/kernel/exit.c
> >   +++ b/kernel/exit.c
> >   @@ -734,9 +734,10 @@ static void exit_notify(struct task_struct
> > *tsk, int group_dead)
> > autoreap = true;
> > }
> > 
> >   - tsk->exit_state = autoreap ? EXIT_DEAD : EXIT_ZOMBIE;
> >   - if (tsk->exit_state == EXIT_DEAD)
> >   + if (autoreap) {
> >   + tsk->exit_state = EXIT_DEAD;
> > list_add(>ptrace_entry, );
> >   + }
> 
> Yes, this needs cleanups. Actually I was going to suggest another change
> below, this way do_notify_pidfd() is only called when it is really needed.
> But then I decided a trivial one-liner makes more sense for the start.

Yeah, that was my thinking exactly.

> 
> I'll try to think. Perhaps we should also change do_notify_parent() to set
> p->exit_state, at least if autoreap. Then the early exit_state = EXIT_ZOMBIE
> won't look so confusing and we can do more (minor) cleanups.

You mind sending that as a proper patch?
I also have a few more cleanups for other parts I intend to send later
this week. I'd pick this one up too.

> 
> Oleg.
> 
> --- x/kernel/exit.c
> +++ x/kernel/exit.c
> @@ -182,6 +182,13 @@ static void delayed_put_task_struct(struct rcu_head *rhp)
>   put_task_struct(tsk);
>  }
>  
> +static void do_notify_pidfd(struct task_struct *task)
> +{
> + struct pid *pid;
> +
> + pid = task_pid(task);
> + wake_up_all(>wait_pidfd);
> +}
>  
>  void release_task(struct task_struct *p)
>  {
> @@ -218,6 +225,8 @@ void release_task(struct task_struct *p)
>   zap_leader = do_notify_parent(leader, leader->exit_signal);
>   if (zap_leader)
>   leader->exit_state = EXIT_DEAD;
> +
> + do_notify_pidfd(leader);
>   }
>  
>   write_unlock_irq(_lock);
> @@ -710,7 +719,7 @@ static void forget_original_parent(struct task_struct 
> *father,
>   */
>  static void exit_notify(struct task_struct *tsk, int group_dead)
>  {
> - bool autoreap;
> + bool autoreap, xxx;

In case you don't mind the length of it how about:

bool autoreap, leading_empty_thread_group;

It's not the prettiest names but having rather descriptive var names in
these codepaths seems like a good idea to me.
It also reads very naturally further below:

if (leading_empty_thread_group || unlikely(tsk->ptrace)) {
int sig = leading_empty_thread_group && !ptrace_reparented(tsk)
? tsk->exit_signal : SIGCHLD;

>   struct task_struct *p, *n;
>   LIST_HEAD(dead);
>  
> @@ -720,23 +729,22 @@ static void exit_notify(struct task_struct *tsk, int 
> group_dead)
>   if (group_dead)
>   kill_orphaned_pgrp(tsk->group_leader, NULL);
>  
> - if (unlikely(tsk->ptrace)) {
> - int sig = thread_group_leader(tsk) &&
> - thread_group_empty(tsk) &&
> - !ptrace_reparented(tsk) ?
> - tsk->exit_signal : SIGCHLD;
> + autoreap = true;
> + xxx = thread_group_leader(tsk) && thread_group_empty(tsk);
> +
> + if (xxx || unlikely(tsk->ptrace)) {
> + int sig = xxx && !ptrace_reparented(tsk)
> + ? tsk->exit_signal : SIGCHLD;
>   autoreap = do_notify_parent(tsk, sig);
> - } else if (thread_group_leader(tsk)) {
> - autoreap = thread_group_empty(tsk) &&
> - do_notify_parent(tsk, tsk->exit_signal);
> - } else {
> - autoreap = true;
>   }
>  
>   tsk->exit_state = autoreap ? EXIT_DEAD : EXIT_ZOMBIE;
>   if (tsk->exit_state == EXIT_DEAD)
>   list_add(>ptrace_entry, );
>  
> + if (xxx)
> + do_notify_pidfd(tsk);
> +
>   /* mt-exec, de_thread() is waiting for group leader */
>   if (unlikely(tsk->signal->notify_count < 0))
>   wake_up_process(tsk->signal->group_exit_task);
> --- x/kernel/signal.c
> +++ x/kernel/signal.c
> @@ -1881,14 +1881,6 @@ int send_sigqueue(struct sigqueue *q, struct pid *pid, 
> enum pid_type type)
>   return ret;
>  }
>  
> -static void do_notify_pidfd(struct task_struct *task)
> -{
> - struct pid *pid;
> -
> - pid = task_pid(task);
> - wake_up_all(>wait_pidfd);
> -}
> -
>  /*
>   * Let a parent know about the death of a child.
>   * For a stopped/continued status change, use do_notify_parent_cldstop 
> instead.
> @@ -1912,9 +1904,6 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
>   BUG_ON(!tsk->ptrace &&
>  (tsk->group_leader != tsk || !thread_group_empty(tsk)));
>  
> - /* Wake up all pidfd waiters */
> - do_notify_pidfd(tsk);
> -
>   if (sig != SIGCHLD) {
>   /*
>* This is only possible if parent == real_parent.
> 


[PATCH] selftests: kmod: Fix typo in kmod.sh

2019-07-23 Thread Masanari Iida
This patch fixes some spelling typos in kmod.sh

Signed-off-by: Masanari Iida 
---
 tools/testing/selftests/kmod/kmod.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/kmod/kmod.sh 
b/tools/testing/selftests/kmod/kmod.sh
index 0a76314b4414..8b944cf042f6 100755
--- a/tools/testing/selftests/kmod/kmod.sh
+++ b/tools/testing/selftests/kmod/kmod.sh
@@ -28,7 +28,7 @@
 # override by exporting to your environment prior running this script.
 # For instance this script assumes you do not have xfs loaded upon boot.
 # If this is false, export DEFAULT_KMOD_FS="ext4" prior to running this
-# script if the filesyste module you don't have loaded upon bootup
+# script if the filesystem module you don't have loaded upon bootup
 # is ext4 instead. Refer to allow_user_defaults() for a list of user
 # override variables possible.
 #
@@ -263,7 +263,7 @@ config_get_test_result()
 config_reset()
 {
if ! echo -n "1" >"$DIR"/reset; then
-   echo "$0: reset shuld have worked" >&2
+   echo "$0: reset should have worked" >&2
exit 1
fi
 }
@@ -488,7 +488,7 @@ usage()
echo Example uses:
echo
echo "${TEST_NAME}.sh   -- executes all tests"
-   echo "${TEST_NAME}.sh -t 0008   -- Executes test ID 0008 number of 
times is recomended"
+   echo "${TEST_NAME}.sh -t 0008   -- Executes test ID 0008 number of 
times is recommended"
echo "${TEST_NAME}.sh -w 0008   -- Watch test ID 0008 run until an 
error occurs"
echo "${TEST_NAME}.sh -s 0008   -- Run test ID 0008 once"
echo "${TEST_NAME}.sh -c 0008 3 -- Run test ID 0008 three times"
-- 
2.22.0.545.g9c9b961d7eb1



[PATCH] h8300: move definition of __kernel_size_t etc. to posix_types.h

2019-07-23 Thread Masahiro Yamada
These types should be defined in posix_types.h, not in bitsperlong.h .

With these defines moved, h8300-specific bitsperlong.h is no longer
needed since Kbuild will automatically create a wrapper of
include/uapi/asm-generic/bitsperlong.h

Signed-off-by: Masahiro Yamada 
---

 arch/h8300/include/uapi/asm/bitsperlong.h | 15 ---
 arch/h8300/include/uapi/asm/posix_types.h | 13 +
 2 files changed, 13 insertions(+), 15 deletions(-)
 delete mode 100644 arch/h8300/include/uapi/asm/bitsperlong.h
 create mode 100644 arch/h8300/include/uapi/asm/posix_types.h

diff --git a/arch/h8300/include/uapi/asm/bitsperlong.h 
b/arch/h8300/include/uapi/asm/bitsperlong.h
deleted file mode 100644
index a33e358f1c1b..
--- a/arch/h8300/include/uapi/asm/bitsperlong.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI__ASM_H8300_BITS_PER_LONG
-#define _UAPI__ASM_H8300_BITS_PER_LONG
-
-#include 
-
-#if !defined(__ASSEMBLY__)
-/* h8300-unknown-linux required long */
-#define __kernel_size_t __kernel_size_t
-typedef unsigned long  __kernel_size_t;
-typedef long   __kernel_ssize_t;
-typedef long   __kernel_ptrdiff_t;
-#endif
-
-#endif /* _UAPI__ASM_H8300_BITS_PER_LONG */
diff --git a/arch/h8300/include/uapi/asm/posix_types.h 
b/arch/h8300/include/uapi/asm/posix_types.h
new file mode 100644
index ..3efc9dd59476
--- /dev/null
+++ b/arch/h8300/include/uapi/asm/posix_types.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
+#ifndef _UAPI_ASM_POSIX_TYPES_H
+#define _UAPI_ASM_POSIX_TYPES_H
+
+/* h8300-unknown-linux required long */
+#define __kernel_size_t __kernel_size_t
+typedef unsigned long  __kernel_size_t;
+typedef long   __kernel_ssize_t;
+typedef long   __kernel_ptrdiff_t;
+
+#include 
+
+#endif /* _UAPI_ASM_POSIX_TYPES_H */
-- 
2.17.1



Re: [PATCH] RDMA/hns: Fix build error for hip08

2019-07-23 Thread Leon Romanovsky
On Tue, Jul 23, 2019 at 06:06:22PM +0800, Yuehaibing wrote:
>
> On 2019/7/23 15:43, Leon Romanovsky wrote:
> > On Tue, Jul 23, 2019 at 10:49:08AM +0800, YueHaibing wrote:
> >> If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
> >> but INFINIBAND_HNS is y, building fails:
> >>
> >> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function 
> >> `hns_roce_hw_v2_exit':
> >> hns_roce_hw_v2.c:(.exit.text+0xd): undefined reference to 
> >> `hnae3_unregister_client'
> >> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function 
> >> `hns_roce_hw_v2_init':
> >> hns_roce_hw_v2.c:(.init.text+0xd): undefined reference to 
> >> `hnae3_register_client'
> >
> > It means that you have a problem with header files of your hns3.
>
> hnae3_unregister_client is a EXPORT_SYMBOL. If INFINIBAND_HNS is y,
> hns-roce-hw-v2 will be built-in, but as HNS3 is set to m, linking will failed.

One of the possible solution is to add "select" identifier to your
Kconfig, it will ensure that HNS3 will be set to "y" too.

Thanks


Re: [PATCH v9 00/21] Generic page walk and ptdump

2019-07-23 Thread Mark Rutland
On Mon, Jul 22, 2019 at 04:41:49PM +0100, Steven Price wrote:
> This is a slight reworking and extension of my previous patch set
> (Convert x86 & arm64 to use generic page walk), but I've continued the
> version numbering as most of the changes are the same. In particular
> this series ends with a generic PTDUMP implemention for arm64 and x86.
> 
> Many architectures current have a debugfs file for dumping the kernel
> page tables. Currently each architecture has to implement custom
> functions for this because the details of walking the page tables used
> by the kernel are different between architectures.
> 
> This series extends the capabilities of walk_page_range() so that it can
> deal with the page tables of the kernel (which have no VMAs and can
> contain larger huge pages than exist for user space). A generic PTDUMP
> implementation is the implemented making use of the new functionality of
> walk_page_range() and finally arm64 and x86 are switch to using it,
> removing the custom table walkers.
> 
> To enable a generic page table walker to walk the unusual mappings of
> the kernel we need to implement a set of functions which let us know
> when the walker has reached the leaf entry. After a suggestion from Will
> Deacon I've chosen the name p?d_leaf() as this (hopefully) describes
> the purpose (and is a new name so has no historic baggage). Some
> architectures have p?d_large macros but this is easily confused with
> "large pages".
> 
> Mostly this is a clean up and there should be very little functional
> change. The exceptions are:
> 
> * x86 PTDUMP debugfs output no longer display pages which aren't
>   present (patch 14).
> 
> * arm64 has the ability to efficiently process KASAN pages (which
>   previously only x86 implemented). This means that the combination of
>   KASAN and DEBUG_WX is now useable.

Are there any visible changes to the arm64 output?

Could you dump a before/after example somewhere?

Thanks,
Mark.


Re: [PATCH v9 11/21] mm: pagewalk: Add p4d_entry() and pgd_entry()

2019-07-23 Thread Mark Rutland
On Mon, Jul 22, 2019 at 04:42:00PM +0100, Steven Price wrote:
> pgd_entry() and pud_entry() were removed by commit 0b1fbfe50006c410
> ("mm/pagewalk: remove pgd_entry() and pud_entry()") because there were
> no users. We're about to add users so reintroduce them, along with
> p4d_entry() as we now have 5 levels of tables.
> 
> Note that commit a00cc7d9dd93d66a ("mm, x86: add support for
> PUD-sized transparent hugepages") already re-added pud_entry() but with
> different semantics to the other callbacks. Since there have never
> been upstream users of this, revert the semantics back to match the
> other callbacks. This means pud_entry() is called for all entries, not
> just transparent huge pages.
> 
> Signed-off-by: Steven Price 
> ---
>  include/linux/mm.h | 15 +--
>  mm/pagewalk.c  | 27 ---
>  2 files changed, 25 insertions(+), 17 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 0334ca97c584..b22799129128 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1432,15 +1432,14 @@ void unmap_vmas(struct mmu_gather *tlb, struct 
> vm_area_struct *start_vma,
>  
>  /**
>   * mm_walk - callbacks for walk_page_range
> - * @pud_entry: if set, called for each non-empty PUD (2nd-level) entry
> - *  this handler should only handle pud_trans_huge() puds.
> - *  the pmd_entry or pte_entry callbacks will be used for
> - *  regular PUDs.
> - * @pmd_entry: if set, called for each non-empty PMD (3rd-level) entry
> + * @pgd_entry: if set, called for each non-empty PGD (top-level) entry
> + * @p4d_entry: if set, called for each non-empty P4D entry
> + * @pud_entry: if set, called for each non-empty PUD entry
> + * @pmd_entry: if set, called for each non-empty PMD entry

How are these expected to work with folding?

For example, on arm64 with 64K pages and 42-bit VA, you can have 2-level
tables where the PGD is P4D, PUD, and PMD. IIUC we'd invoke the
callbacks for each of those levels where we found an entry in the pgd.

Either the callee handle that, or we should inhibit the callbacks when
levels are folded, and I think that needs to be explcitly stated either
way.

IIRC on x86 the p4d folding is dynamic depending on whether the HW
supports 5-level page tables. Maybe that implies the callee has to
handle that.

Thanks,
Mark.


>   *  this handler is required to be able to handle
>   *  pmd_trans_huge() pmds.  They may simply choose to
>   *  split_huge_page() instead of handling it explicitly.
> - * @pte_entry: if set, called for each non-empty PTE (4th-level) entry
> + * @pte_entry: if set, called for each non-empty PTE (lowest-level) entry
>   * @pte_hole: if set, called for each hole at all levels
>   * @hugetlb_entry: if set, called for each hugetlb entry
>   * @test_walk: caller specific callback function to determine whether
> @@ -1455,6 +1454,10 @@ void unmap_vmas(struct mmu_gather *tlb, struct 
> vm_area_struct *start_vma,
>   * (see the comment on walk_page_range() for more details)
>   */
>  struct mm_walk {
> + int (*pgd_entry)(pgd_t *pgd, unsigned long addr,
> +  unsigned long next, struct mm_walk *walk);
> + int (*p4d_entry)(p4d_t *p4d, unsigned long addr,
> +  unsigned long next, struct mm_walk *walk);
>   int (*pud_entry)(pud_t *pud, unsigned long addr,
>unsigned long next, struct mm_walk *walk);
>   int (*pmd_entry)(pmd_t *pmd, unsigned long addr,
> diff --git a/mm/pagewalk.c b/mm/pagewalk.c
> index c3084ff2569d..98373a9f88b8 100644
> --- a/mm/pagewalk.c
> +++ b/mm/pagewalk.c
> @@ -90,15 +90,9 @@ static int walk_pud_range(p4d_t *p4d, unsigned long addr, 
> unsigned long end,
>   }
>  
>   if (walk->pud_entry) {
> - spinlock_t *ptl = pud_trans_huge_lock(pud, walk->vma);
> -
> - if (ptl) {
> - err = walk->pud_entry(pud, addr, next, walk);
> - spin_unlock(ptl);
> - if (err)
> - break;
> - continue;
> - }
> + err = walk->pud_entry(pud, addr, next, walk);
> + if (err)
> + break;
>   }
>  
>   split_huge_pud(walk->vma, pud, addr);
> @@ -131,7 +125,12 @@ static int walk_p4d_range(pgd_t *pgd, unsigned long 
> addr, unsigned long end,
>   break;
>   continue;
>   }
> - if (walk->pmd_entry || walk->pte_entry)
> + if (walk->p4d_entry) {
> + err = walk->p4d_entry(p4d, addr, next, walk);
> + if (err)
> + break;
> + }
> + if (walk->pud_entry || walk->pmd_entry || walk->pte_entry)
>   err = 

Re: [GIT PULL] pidfd fixes

2019-07-23 Thread Oleg Nesterov
On 07/22, Linus Torvalds wrote:
>
> So if we set EXIT_ZOMBIE early, then I think we should change the
> EXIT_DEAD case too. IOW, do something like this on top:
> 
>   --- a/kernel/exit.c
>   +++ b/kernel/exit.c
>   @@ -734,9 +734,10 @@ static void exit_notify(struct task_struct
> *tsk, int group_dead)
> autoreap = true;
> }
> 
>   - tsk->exit_state = autoreap ? EXIT_DEAD : EXIT_ZOMBIE;
>   - if (tsk->exit_state == EXIT_DEAD)
>   + if (autoreap) {
>   + tsk->exit_state = EXIT_DEAD;
> list_add(>ptrace_entry, );
>   + }

Yes, this needs cleanups. Actually I was going to suggest another change
below, this way do_notify_pidfd() is only called when it is really needed.
But then I decided a trivial one-liner makes more sense for the start.

I'll try to think. Perhaps we should also change do_notify_parent() to set
p->exit_state, at least if autoreap. Then the early exit_state = EXIT_ZOMBIE
won't look so confusing and we can do more (minor) cleanups.

Oleg.

--- x/kernel/exit.c
+++ x/kernel/exit.c
@@ -182,6 +182,13 @@ static void delayed_put_task_struct(struct rcu_head *rhp)
put_task_struct(tsk);
 }
 
+static void do_notify_pidfd(struct task_struct *task)
+{
+   struct pid *pid;
+
+   pid = task_pid(task);
+   wake_up_all(>wait_pidfd);
+}
 
 void release_task(struct task_struct *p)
 {
@@ -218,6 +225,8 @@ void release_task(struct task_struct *p)
zap_leader = do_notify_parent(leader, leader->exit_signal);
if (zap_leader)
leader->exit_state = EXIT_DEAD;
+
+   do_notify_pidfd(leader);
}
 
write_unlock_irq(_lock);
@@ -710,7 +719,7 @@ static void forget_original_parent(struct task_struct 
*father,
  */
 static void exit_notify(struct task_struct *tsk, int group_dead)
 {
-   bool autoreap;
+   bool autoreap, xxx;
struct task_struct *p, *n;
LIST_HEAD(dead);
 
@@ -720,23 +729,22 @@ static void exit_notify(struct task_struct *tsk, int 
group_dead)
if (group_dead)
kill_orphaned_pgrp(tsk->group_leader, NULL);
 
-   if (unlikely(tsk->ptrace)) {
-   int sig = thread_group_leader(tsk) &&
-   thread_group_empty(tsk) &&
-   !ptrace_reparented(tsk) ?
-   tsk->exit_signal : SIGCHLD;
+   autoreap = true;
+   xxx = thread_group_leader(tsk) && thread_group_empty(tsk);
+
+   if (xxx || unlikely(tsk->ptrace)) {
+   int sig = xxx && !ptrace_reparented(tsk)
+   ? tsk->exit_signal : SIGCHLD;
autoreap = do_notify_parent(tsk, sig);
-   } else if (thread_group_leader(tsk)) {
-   autoreap = thread_group_empty(tsk) &&
-   do_notify_parent(tsk, tsk->exit_signal);
-   } else {
-   autoreap = true;
}
 
tsk->exit_state = autoreap ? EXIT_DEAD : EXIT_ZOMBIE;
if (tsk->exit_state == EXIT_DEAD)
list_add(>ptrace_entry, );
 
+   if (xxx)
+   do_notify_pidfd(tsk);
+
/* mt-exec, de_thread() is waiting for group leader */
if (unlikely(tsk->signal->notify_count < 0))
wake_up_process(tsk->signal->group_exit_task);
--- x/kernel/signal.c
+++ x/kernel/signal.c
@@ -1881,14 +1881,6 @@ int send_sigqueue(struct sigqueue *q, struct pid *pid, 
enum pid_type type)
return ret;
 }
 
-static void do_notify_pidfd(struct task_struct *task)
-{
-   struct pid *pid;
-
-   pid = task_pid(task);
-   wake_up_all(>wait_pidfd);
-}
-
 /*
  * Let a parent know about the death of a child.
  * For a stopped/continued status change, use do_notify_parent_cldstop instead.
@@ -1912,9 +1904,6 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
BUG_ON(!tsk->ptrace &&
   (tsk->group_leader != tsk || !thread_group_empty(tsk)));
 
-   /* Wake up all pidfd waiters */
-   do_notify_pidfd(tsk);
-
if (sig != SIGCHLD) {
/*
 * This is only possible if parent == real_parent.



RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool

2019-07-23 Thread Jose Abreu
From: Jon Hunter 
Date: Jul/23/2019, 11:01:24 (UTC+00:00)

> This appears to be a winner and by disabling the SMMU for the ethernet
> controller and reverting commit 954a03be033c7cef80ddc232e7cbdb17df735663
> this worked! So yes appears to be related to the SMMU being enabled. We
> had to enable the SMMU for ethernet recently due to commit
> 954a03be033c7cef80ddc232e7cbdb17df735663.

Finally :)

However, from "git show 954a03be033c7cef80ddc232e7cbdb17df735663":

+ There are few reasons to allow unmatched stream bypass, and
+ even fewer good ones.  If saying YES here breaks your board
+ you should work on fixing your board.

So, how can we fix this ? Is your ethernet DT node marked as 
"dma-coherent;" ?

---
Thanks,
Jose Miguel Abreu


Re: [PATCH] RDMA/hns: Fix build error for hip08

2019-07-23 Thread Yuehaibing


On 2019/7/23 15:43, Leon Romanovsky wrote:
> On Tue, Jul 23, 2019 at 10:49:08AM +0800, YueHaibing wrote:
>> If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
>> but INFINIBAND_HNS is y, building fails:
>>
>> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function 
>> `hns_roce_hw_v2_exit':
>> hns_roce_hw_v2.c:(.exit.text+0xd): undefined reference to 
>> `hnae3_unregister_client'
>> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function 
>> `hns_roce_hw_v2_init':
>> hns_roce_hw_v2.c:(.init.text+0xd): undefined reference to 
>> `hnae3_register_client'
> 
> It means that you have a problem with header files of your hns3.

hnae3_unregister_client is a EXPORT_SYMBOL. If INFINIBAND_HNS is y,
hns-roce-hw-v2 will be built-in, but as HNS3 is set to m, linking will failed.

I can't see how to fix this in header files of hns3, or am I missing something?

> 
>>
>> Reported-by: Hulk Robot 
>> Fixes: dd74282df573 ("RDMA/hns: Initialize the PCI device for hip08 RoCE")
>> Signed-off-by: YueHaibing 
>> ---
>>  drivers/infiniband/hw/hns/Kconfig | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/infiniband/hw/hns/Kconfig 
>> b/drivers/infiniband/hw/hns/Kconfig
>> index b59da5d..4371c80 100644
>> --- a/drivers/infiniband/hw/hns/Kconfig
>> +++ b/drivers/infiniband/hw/hns/Kconfig
>> @@ -23,7 +23,8 @@ config INFINIBAND_HNS_HIP06
>>
>>  config INFINIBAND_HNS_HIP08
>>  bool "Hisilicon Hip08 Family RoCE support"
>> -depends on INFINIBAND_HNS && PCI && HNS3
>> +depends on INFINIBAND_HNS && (INFINIBAND_HNS = HNS3)
> 
> This is wrong.
> 
>> +depends on PCI
>>  ---help---
>>RoCE driver support for Hisilicon RoCE engine in Hisilicon Hip08 SoC.
>>The RoCE engine is a PCI device.
>> --
>> 2.7.4
>>
>>
> 
> .
> 



Re: [PATCH v3 5/5] PM / devfreq: Add required OPPs support to passive governor

2019-07-23 Thread Viresh Kumar
On 17-07-19, 15:23, Saravana Kannan wrote:
> Look at the required OPPs of the "parent" device to determine the OPP that
> is required from the slave device managed by the passive governor. This
> allows having mappings between a parent device and a slave device even when
> they don't have the same number of OPPs.
> 
> Signed-off-by: Saravana Kannan 
> Acked-by: MyungJoo Ham 
> Acked-by: Chanwoo Choi 
> ---
>  drivers/devfreq/governor_passive.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/devfreq/governor_passive.c 
> b/drivers/devfreq/governor_passive.c
> index 58308948b863..24ce94c80f06 100644
> --- a/drivers/devfreq/governor_passive.c
> +++ b/drivers/devfreq/governor_passive.c
> @@ -19,7 +19,7 @@ static int devfreq_passive_get_target_freq(struct devfreq 
> *devfreq,
>   = (struct devfreq_passive_data *)devfreq->data;
>   struct devfreq *parent_devfreq = (struct devfreq *)p_data->parent;
>   unsigned long child_freq = ULONG_MAX;
> - struct dev_pm_opp *opp;
> + struct dev_pm_opp *opp = NULL, *p_opp = NULL;

This won't be required if ...

>   int i, count, ret = 0;
>  
>   /*
> @@ -56,13 +56,20 @@ static int devfreq_passive_get_target_freq(struct devfreq 
> *devfreq,
>* list of parent device. Because in this case, *freq is temporary
>* value which is decided by ondemand governor.
>*/
> - opp = devfreq_recommended_opp(parent_devfreq->dev.parent, freq, 0);
> - if (IS_ERR(opp)) {
> - ret = PTR_ERR(opp);
> + p_opp = devfreq_recommended_opp(parent_devfreq->dev.parent, freq, 0);
> + if (IS_ERR(p_opp)) {
> + ret = PTR_ERR(p_opp);
>   goto out;
>   }
>  
> - dev_pm_opp_put(opp);
> + if (devfreq->opp_table && parent_devfreq->opp_table)
> + opp = dev_pm_opp_xlate_opp(parent_devfreq->opp_table,
> +devfreq->opp_table, p_opp);

you put p_opp right here.

Also shouldn't you try to get p_opp under the above if block only? As
that is the only user of it ?

> + if (opp) {
> + *freq = dev_pm_opp_get_freq(opp);
> + dev_pm_opp_put(opp);
> + goto out;
> + }
>  
>   /*
>* Get the OPP table's index of decided freqeuncy by governor
> @@ -89,6 +96,9 @@ static int devfreq_passive_get_target_freq(struct devfreq 
> *devfreq,
>   *freq = child_freq;
>  
>  out:
> + if (!IS_ERR_OR_NULL(opp))
> + dev_pm_opp_put(p_opp);
> +
>   return ret;
>  }
>  
> -- 
> 2.22.0.510.g264f2c817a-goog

-- 
viresh


Re: [PATCH] psi: get poll_work to run when calling poll syscall next time

2019-07-23 Thread Caspar Zhang
On Tue, Jul 23, 2019 at 02:45:39PM +0800, Jason Xing wrote:
> Only when calling the poll syscall the first time can user
> receive POLLPRI correctly. After that, user always fails to
> acquire the event signal.
>
> Reproduce case:
> 1. Get the monitor code in Documentation/accounting/psi.txt
> 2. Run it, and wait for the event triggered.
> 3. Kill and restart the process.
>
> If the user doesn't kill the monitor process, it seems the
> poll_work works fine. After killing and restarting the monitor,
> the poll_work in kernel will never run again due to the wrong
> value of poll_scheduled. Therefore, we should reset the value
> as group_init() does after the last trigger is destroyed.
>
> Signed-off-by: Jason Xing 

Reviewed-by: Caspar Zhang 

> ---
>  kernel/sched/psi.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/kernel/sched/psi.c b/kernel/sched/psi.c
> index 7acc632..66f4385 100644
> --- a/kernel/sched/psi.c
> +++ b/kernel/sched/psi.c
> @@ -1133,6 +1133,12 @@ static void psi_trigger_destroy(struct kref *ref)
>   if (kworker_to_destroy) {
>   kthread_cancel_delayed_work_sync(>poll_work);
>   kthread_destroy_worker(kworker_to_destroy);
> + /*
> +  * The poll_work should have the chance to be put into the
> +  * kthread queue when calling poll syscall next time. So
> +  * reset poll_scheduled to zero as group_init() does
> +  */
> + atomic_set(>poll_scheduled, 0);
>   }
>   kfree(t);
>  }
> --
> 1.8.3.1
>

--
Thanks,
Caspar


Re: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool

2019-07-23 Thread Jon Hunter


On 23/07/2019 09:14, Jose Abreu wrote:
> From: Jose Abreu 
> Date: Jul/22/2019, 15:04:49 (UTC+00:00)
> 
>> From: Jon Hunter 
>> Date: Jul/22/2019, 13:05:38 (UTC+00:00)
>>
>>>
>>> On 22/07/2019 12:39, Jose Abreu wrote:
 From: Lars Persson 
 Date: Jul/22/2019, 12:11:50 (UTC+00:00)

> On Mon, Jul 22, 2019 at 12:18 PM Ilias Apalodimas
>  wrote:
>>
>> On Thu, Jul 18, 2019 at 07:48:04AM +, Jose Abreu wrote:
>>> From: Jon Hunter 
>>> Date: Jul/17/2019, 19:58:53 (UTC+00:00)
>>>
 Let me know if you have any thoughts.
>>>
>>> Can you try attached patch ?
>>>
>>
>> The log says  someone calls panic() right?
>> Can we trye and figure were that happens during the stmmac init phase?
>>
>
> The reason for the panic is hidden in this one line of the kernel logs:
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b
>
> The init process is killed by SIGSEGV (signal 11 = 0xb).
>
> I would suggest you look for data corruption bugs in the RX path. If
> the code is fetched from the NFS mount then a corrupt RX buffer can
> trigger a crash in userspace.
>
> /Lars


 Jon, I'm not familiar with ARM. Are the buffer addresses being allocated 
 in a coherent region ? Can you try attached patch which adds full memory 
 barrier before the sync ?
>>>
>>> TBH I am not sure about the buffer addresses either. The attached patch
>>> did not help. Same problem persists.
>>
>> OK. I'm just guessing now at this stage but can you disable SMP ?

I tried limiting the number of CPUs to one by setting 'maxcpus=0' on the
kernel command line. However, this did not help.

>> We have to narrow down if this is coherency issue but you said that 
>> booting without NFS and then mounting manually the share works ... So, 
>> can you share logs with same debug prints in this condition in order to 
>> compare ?
> 
> Jon, I have one ARM based board and I can't face your issue but I 
> noticed that my buffer addresses are being mapped using SWIOTLB. Can you 
> disable IOMMU support on your setup and let me know if the problem 
> persists ?

This appears to be a winner and by disabling the SMMU for the ethernet
controller and reverting commit 954a03be033c7cef80ddc232e7cbdb17df735663
this worked! So yes appears to be related to the SMMU being enabled. We
had to enable the SMMU for ethernet recently due to commit
954a03be033c7cef80ddc232e7cbdb17df735663.

Cheers
Jon

-- 
nvpublic


[PATCH] security: smack: Fix possible null-pointer dereferences in smack_socket_sock_rcv_skb()

2019-07-23 Thread Jia-Ju Bai
In smack_socket_sock_rcv_skb(), there is an if statement 
on line 3920 to check whether skb is NULL:
if (skb && skb->secmark != 0)

This check indicates skb can be NULL in some cases.

But on lines 3931 and 3932, skb is used:
ad.a.u.net->netif = skb->skb_iif;
ipv6_skb_to_auditdata(skb, , NULL);

Thus, possible null-pointer dereferences may occur when skb is NULL.

To fix these possible bugs, an if statement is added to check skb.

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

Signed-off-by: Jia-Ju Bai 
---
 security/smack/smack_lsm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 4c5e5a438f8b..5c9fc8ba6e57 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -3925,6 +3925,8 @@ static int smack_socket_sock_rcv_skb(struct sock *sk, 
struct sk_buff *skb)
skp = smack_ipv6host_label();
if (skp == NULL)
skp = smack_net_ambient;
+   if (skb == NULL)
+   break;
 #ifdef CONFIG_AUDIT
smk_ad_init_net(, __func__, LSM_AUDIT_DATA_NET, );
ad.a.u.net->family = family;
-- 
2.17.0



Re: [PATCH 0/4] Sleeping functions in invalid context bug fixes

2019-07-23 Thread Ilya Dryomov
On Fri, Jul 19, 2019 at 5:20 PM Jeff Layton  wrote:
>
> On Fri, 2019-07-19 at 15:32 +0100, Luis Henriques wrote:
> > Hi,
> >
> > I'm sending three "sleeping function called from invalid context" bug
> > fixes that I had on my TODO for a while.  All of them are ceph_buffer_put
> > related, and all the fixes follow the same pattern: delay the operation
> > until the ci->i_ceph_lock is released.
> >
> > The first patch simply allows ceph_buffer_put to receive a NULL buffer so
> > that the NULL check doesn't need to be performed in all the other patches.
> > IOW, it's not really required, just convenient.
> >
> > (Note: maybe these patches should all be tagged for stable.)
> >
> > Luis Henriques (4):
> >   libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer
> >   ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()
> >   ceph: fix buffer free while holding i_ceph_lock in
> > __ceph_build_xattrs_blob()
> >   ceph: fix buffer free while holding i_ceph_lock in fill_inode()
> >
> >  fs/ceph/caps.c  |  5 -
> >  fs/ceph/inode.c |  7 ---
> >  fs/ceph/snap.c  |  4 +++-
> >  fs/ceph/super.h |  2 +-
> >  fs/ceph/xattr.c | 19 ++-
> >  include/linux/ceph/buffer.h |  3 ++-
> >  6 files changed, 28 insertions(+), 12 deletions(-)
>
> This all looks good to me. I'll plan to merge these into the testing
> branch soon, and tag them for stable.
>
> PS: On a related note (and more of a question for Ilya)...
>
> I'm wondering if we get any benefit from having our own ceph_kvmalloc
> routine. Why are we not better off using the stock kvmalloc routine
> instead? Forcing a vmalloc just because we've gone above 32k allocation
> doesn't seem like the right thing to do.

I don't remember off the top of my head and can't check right now.
Could be that kvmalloc() didn't exist back then.  I'll add that to my
TODO list.

Thanks,

Ilya


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

2019-07-23 Thread Mark Rutland
On Mon, Jul 22, 2019 at 04:42:08PM +0100, Steven Price wrote:
> Add a generic version of page table dumping that architectures can
> opt-in to
> 
> Signed-off-by: Steven Price 

[...]

> +#ifdef CONFIG_KASAN
> +/*
> + * This is an optimization for KASAN=y case. Since all kasan page tables
> + * eventually point to the kasan_early_shadow_page we could call note_page()
> + * right away without walking through lower level page tables. This saves
> + * us dozens of seconds (minutes for 5-level config) while checking for
> + * W+X mapping or reading kernel_page_tables debugfs file.
> + */
> +static inline bool kasan_page_table(struct ptdump_state *st, void *pt,
> + unsigned long addr)
> +{
> + if (__pa(pt) == __pa(kasan_early_shadow_pmd) ||
> +#ifdef CONFIG_X86
> + (pgtable_l5_enabled() &&
> + __pa(pt) == __pa(kasan_early_shadow_p4d)) ||
> +#endif
> + __pa(pt) == __pa(kasan_early_shadow_pud)) {
> + st->note_page(st, addr, 5, pte_val(kasan_early_shadow_pte[0]));
> + return true;
> + }
> + return false;

Having you tried this with CONFIG_DEBUG_VIRTUAL?

The kasan_early_shadow_pmd is a kernel object rather than a linear map
object, so you should use __pa_symbol for that.

It's a bit horrid to have to test multiple levels in one function; can't
we check the relevant level inline in each of the test_p?d funcs?

They're optional anyway, so they only need to be defined for
CONFIG_KASAN.

Thanks,
Mark.

> +}
> +#else
> +static inline bool kasan_page_table(struct ptdump_state *st, void *pt,
> + unsigned long addr)
> +{
> + return false;
> +}
> +#endif
> +
> +static int ptdump_test_p4d(unsigned long addr, unsigned long next,
> +p4d_t *p4d, struct mm_walk *walk)
> +{
> + struct ptdump_state *st = walk->private;
> +
> + if (kasan_page_table(st, p4d, addr))
> + return 1;
> + return 0;
> +}
> +static int ptdump_test_pud(unsigned long addr, unsigned long next,
> +pud_t *pud, struct mm_walk *walk)
> +{
> + struct ptdump_state *st = walk->private;
> +
> + if (kasan_page_table(st, pud, addr))
> + return 1;
> + return 0;
> +}
> +
> +static int ptdump_test_pmd(unsigned long addr, unsigned long next,
> +pmd_t *pmd, struct mm_walk *walk)
> +{
> + struct ptdump_state *st = walk->private;
> +
> + if (kasan_page_table(st, pmd, addr))
> + return 1;
> + return 0;
> +}
> +
> +static int ptdump_hole(unsigned long addr, unsigned long next,
> +struct mm_walk *walk)
> +{
> + struct ptdump_state *st = walk->private;
> +
> + st->note_page(st, addr, -1, 0);
> +
> + return 0;
> +}
> +
> +void ptdump_walk_pgd(struct ptdump_state *st, struct mm_struct *mm)
> +{
> + struct mm_walk walk = {
> + .mm = mm,
> + .pgd_entry  = ptdump_pgd_entry,
> + .p4d_entry  = ptdump_p4d_entry,
> + .pud_entry  = ptdump_pud_entry,
> + .pmd_entry  = ptdump_pmd_entry,
> + .pte_entry  = ptdump_pte_entry,
> + .test_p4d   = ptdump_test_p4d,
> + .test_pud   = ptdump_test_pud,
> + .test_pmd   = ptdump_test_pmd,
> + .pte_hole   = ptdump_hole,
> + .private= st
> + };
> + const struct ptdump_range *range = st->range;
> +
> + down_read(>mmap_sem);
> + while (range->start != range->end) {
> + walk_page_range(range->start, range->end, );
> + range++;
> + }
> + up_read(>mmap_sem);
> +
> + /* Flush out the last page */
> + st->note_page(st, 0, 0, 0);
> +}
> -- 
> 2.20.1
> 


Re: [PATCH v3 2/5] OPP: Add function to look up required OPP's for a given OPP

2019-07-23 Thread Viresh Kumar
On 17-07-19, 15:23, Saravana Kannan wrote:
> Add a function that allows looking up required OPPs given a source OPP
> table, destination OPP table and the source OPP.
> 
> Signed-off-by: Saravana Kannan 
> ---
>  drivers/opp/core.c | 54 ++
>  include/linux/pm_opp.h | 11 +
>  2 files changed, 65 insertions(+)
> 
> diff --git a/drivers/opp/core.c b/drivers/opp/core.c
> index 438fcd134d93..72c055a3f6b7 100644
> --- a/drivers/opp/core.c
> +++ b/drivers/opp/core.c
> @@ -1883,6 +1883,60 @@ void dev_pm_opp_detach_genpd(struct opp_table 
> *opp_table)
>  }
>  EXPORT_SYMBOL_GPL(dev_pm_opp_detach_genpd);
>  
> +/**
> + * dev_pm_opp_xlate_opp() - Find required OPP for src_table OPP.
> + * @src_table: OPP table which has dst_table as one of its required OPP 
> table.
> + * @dst_table: Required OPP table of the src_table.
> + * @pstate: OPP of the src_table.

You should use @ before parameters in the comments as well ? Just like
you did that below.

> + *
> + * This function returns the OPP (present in @dst_table) pointed out by the
> + * "required-opps" property of the OPP (present in @src_table).
> + *
> + * The callers are required to call dev_pm_opp_put() for the returned OPP 
> after
> + * use.
> + *
> + * Return: destination table OPP on success, otherwise NULL on errors.
> + */
> +struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,

Please name it dev_pm_opp_xlate_required_opp().

> + struct opp_table *dst_table,
> + struct dev_pm_opp *src_opp)
> +{
> + struct dev_pm_opp *opp, *dest_opp = NULL;
> + int i;
> +
> + if (!src_table || !dst_table || !src_opp)
> + return NULL;
> +
> + for (i = 0; i < src_table->required_opp_count; i++) {
> + if (src_table->required_opp_tables[i]->np == dst_table->np)

Why can't we just compare the table pointers instead ? Yeah, I know
that's how I wrote that in the other xlate function, but I am confused
now :)

> + break;
> + }
> +
> + if (unlikely(i == src_table->required_opp_count)) {
> + pr_err("%s: Couldn't find matching OPP table (%p: %p)\n",
> +__func__, src_table, dst_table);
> + return NULL;
> + }
> +
> + mutex_lock(_table->lock);
> +
> + list_for_each_entry(opp, _table->opp_list, node) {
> + if (opp == src_opp) {
> + dest_opp = opp->required_opps[i];
> + dev_pm_opp_get(dest_opp);
> + goto unlock;
> + }
> + }
> +
> + pr_err("%s: Couldn't find matching OPP (%p: %p)\n", __func__, src_table,
> +dst_table);
> +
> +unlock:
> + mutex_unlock(_table->lock);
> +
> + return dest_opp;
> +}
> +
>  /**
>   * dev_pm_opp_xlate_performance_state() - Find required OPP's pstate for 
> src_table.
>   * @src_table: OPP table which has dst_table as one of its required OPP 
> table.
> diff --git a/include/linux/pm_opp.h b/include/linux/pm_opp.h
> index af5021f27cb7..36f52b9cf24a 100644
> --- a/include/linux/pm_opp.h
> +++ b/include/linux/pm_opp.h
> @@ -131,6 +131,9 @@ void dev_pm_opp_unregister_set_opp_helper(struct 
> opp_table *opp_table);
>  struct opp_table *dev_pm_opp_attach_genpd(struct device *dev, const char 
> **names);
>  void dev_pm_opp_detach_genpd(struct opp_table *opp_table);
>  int dev_pm_opp_xlate_performance_state(struct opp_table *src_table, struct 
> opp_table *dst_table, unsigned int pstate);
> +struct dev_pm_opp *dev_pm_opp_xlate_opp(struct opp_table *src_table,
> + struct opp_table *dst_table,
> + struct dev_pm_opp *src_opp);
>  int dev_pm_opp_set_rate(struct device *dev, unsigned long target_freq);
>  int dev_pm_opp_set_sharing_cpus(struct device *cpu_dev, const struct cpumask 
> *cpumask);
>  int dev_pm_opp_get_sharing_cpus(struct device *cpu_dev, struct cpumask 
> *cpumask);
> @@ -304,6 +307,14 @@ static inline int 
> dev_pm_opp_xlate_performance_state(struct opp_table *src_table
>   return -ENOTSUPP;
>  }
>  
> +static inline struct dev_pm_opp *dev_pm_opp_xlate_opp(
> + struct opp_table *src_table,
> + struct opp_table *dst_table,
> + struct dev_pm_opp *src_opp)
> +{
> + return NULL;
> +}
> +

Keep the order of declaring routines same, so this goes before the
other xlate routine.

>  static inline int dev_pm_opp_set_rate(struct device *dev, unsigned long 
> target_freq)
>  {
>   return -ENOTSUPP;
> -- 
> 2.22.0.510.g264f2c817a-goog

-- 
viresh


<    2   3   4   5   6   7   8   9   >