date:20180930

v2:
- add a-bs
- add examples for non-anon tests [Mike]
- use brackets properly for nested ifs [Mike]

Recently I wrote some uffd write-protection test for the
not-yet-published uffd-wp tree, and I picked these common patches out
first for the selftest which even suite for master.

Any feedback is welcomed.  Please have a look, thanks.

Peter Xu (3):
  userfaultfd: selftest: cleanup help messages
  userfaultfd: selftest: generalize read and poll
  userfaultfd: selftest: recycle lock threads first

 tools/testing/selftests/vm/userfaultfd.c | 134 +--
 1 file changed, 77 insertions(+), 57 deletions(-)

-- 
2.17.1

[PATCH v2 1/3] userfaultfd: selftest: cleanup help messages

Firstly, the help in the comment region is obsolete, now we support
three parameters.  Since at it, change it and move it into the help
message of the program.

Also, the help messages dumped here and there is obsolete too.  Use a
single usage() helper.

Acked-by: Mike Rapoport 
Signed-off-by: Peter Xu 
---
 tools/testing/selftests/vm/userfaultfd.c | 46 ++--
 1 file changed, 28 insertions(+), 18 deletions(-)

diff --git a/tools/testing/selftests/vm/userfaultfd.c 
b/tools/testing/selftests/vm/userfaultfd.c
index 7b8171e3128a..5ff3a4f9173e 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -34,18 +34,6 @@
  * per-CPU threads 1 by triggering userfaults inside
  * pthread_mutex_lock will also verify the atomicity of the memory
  * transfer (UFFDIO_COPY).
- *
- * The program takes two parameters: the amounts of physical memory in
- * megabytes (MiB) of the area and the number of bounces to execute.
- *
- * # 100MiB 9 bounces
- * ./userfaultfd 100 9
- *
- * # 1GiB 99 bounces
- * ./userfaultfd 1000 99
- *
- * # 10MiB-~6GiB 999 bounces, continue forever unless an error triggers
- * while ./userfaultfd $[RANDOM % 6000 + 10] 999; do true; done
  */
 
 #define _GNU_SOURCE
@@ -115,6 +103,30 @@ pthread_attr_t attr;
 ~(unsigned long)(sizeof(unsigned long long) \
  -  1)))
 
+const char *examples =
+"# Run anonymous memory test on 100MiB region with 9 bounces:\n"
+"./userfaultfd anon 100 9\n\n"
+"# Run share memory test on 1GiB region with 99 bounces:\n"
+"./userfaultfd shmem 1000 99\n\n"
+"# Run hugetlb memory test on 256MiB region with 50 bounces (using 
/dev/hugepages/hugefile):\n"
+"./userfaultfd hugetlb 256 50 /dev/hugepages/hugefile\n\n"
+"# Run the same hugetlb test but using shmem:\n"
+"./userfaultfd hugetlb_shared 256 50 /dev/hugepages/hugefile\n\n"
+"# 10MiB-~6GiB 999 bounces anonymous test, "
+"continue forever unless an error triggers\n"
+"while ./userfaultfd anon $[RANDOM % 6000 + 10] 999; do true; done\n\n";
+
+static void usage(void)
+{
+   fprintf(stderr, "\nUsage: ./userfaultfd"
+   "[hugetlbfs_file]\n\n");
+   fprintf(stderr, "Supported : anon, hugetlb, "
+   "hugetlb_shared, shmem\n\n");
+   fprintf(stderr, "Examples:\n\n");
+   fprintf(stderr, examples);
+   exit(1);
+}
+
 static int anon_release_pages(char *rel_area)
 {
int ret = 0;
@@ -1272,8 +1284,7 @@ static void sigalrm(int sig)
 int main(int argc, char **argv)
 {
if (argc < 4)
-   fprintf(stderr, "Usage:
[hugetlbfs_file]\n"),
-   exit(1);
+   usage();
 
if (signal(SIGALRM, sigalrm) == SIG_ERR)
fprintf(stderr, "failed to arm SIGALRM"), exit(1);
@@ -1286,20 +1297,19 @@ int main(int argc, char **argv)
nr_cpus;
if (!nr_pages_per_cpu) {
fprintf(stderr, "invalid MiB\n");
-   fprintf(stderr, "Usage:  \n"), exit(1);
+   usage();
}
 
bounces = atoi(argv[3]);
if (bounces <= 0) {
fprintf(stderr, "invalid bounces\n");
-   fprintf(stderr, "Usage:  \n"), exit(1);
+   usage();
}
nr_pages = nr_pages_per_cpu * nr_cpus;
 
if (test_type == TEST_HUGETLB) {
if (argc < 5)
-   fprintf(stderr, "Usage: hugetlb   
\n"),
-   exit(1);
+   usage();
huge_fd = open(argv[4], O_CREAT | O_RDWR, 0755);
if (huge_fd < 0) {
fprintf(stderr, "Open of %s failed", argv[3]);
-- 
2.17.1

[PATCH v2 3/3] userfaultfd: selftest: recycle lock threads first

Now we recycle the uffd servicing threads earlier than the lock
threads.  It might happen that when the lock thread is still blocked at
a pthread mutex lock while the servicing thread has already quitted for
the cpu so the lock thread will be blocked forever and hang the test
program.  To fix the possible race, recycle the lock threads first.

This never happens with current missing-only tests, but when I start to
run the write-protection tests (the feature is not yet posted upstream)
it happens every time of the run possibly because in that new test we'll
need to service two page faults for each lock operation.

Acked-by: Mike Rapoport 
Signed-off-by: Peter Xu 
---
 tools/testing/selftests/vm/userfaultfd.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/vm/userfaultfd.c 
b/tools/testing/selftests/vm/userfaultfd.c
index 7a8c6937cc67..5d1db824f73a 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -626,6 +626,12 @@ static int stress(unsigned long *userfaults)
if (uffd_test_ops->release_pages(area_src))
return 1;
 
+
+   finished = 1;
+   for (cpu = 0; cpu < nr_cpus; cpu++)
+   if (pthread_join(locking_threads[cpu], NULL))
+   return 1;
+
for (cpu = 0; cpu < nr_cpus; cpu++) {
char c;
if (bounces & BOUNCE_POLL) {
@@ -643,11 +649,6 @@ static int stress(unsigned long *userfaults)
}
}
 
-   finished = 1;
-   for (cpu = 0; cpu < nr_cpus; cpu++)
-   if (pthread_join(locking_threads[cpu], NULL))
-   return 1;
-
return 0;
 }
 
-- 
2.17.1

[PATCH v2 2/3] userfaultfd: selftest: generalize read and poll

We do very similar things in read and poll modes, but we're copying the
codes around.  Share the codes properly on reading the message and
handling the page fault to make the code cleaner.  Meanwhile this solves
previous mismatch of behaviors between the two modes on that the old
code:

- did not check EAGAIN case in read() mode
- ignored BOUNCE_VERIFY check in read() mode

Signed-off-by: Peter Xu 
---
 tools/testing/selftests/vm/userfaultfd.c | 77 +---
 1 file changed, 43 insertions(+), 34 deletions(-)

diff --git a/tools/testing/selftests/vm/userfaultfd.c 
b/tools/testing/selftests/vm/userfaultfd.c
index 5ff3a4f9173e..7a8c6937cc67 100644
--- a/tools/testing/selftests/vm/userfaultfd.c
+++ b/tools/testing/selftests/vm/userfaultfd.c
@@ -451,6 +451,43 @@ static int copy_page(int ufd, unsigned long offset)
return __copy_page(ufd, offset, false);
 }
 
+static int uffd_read_msg(int ufd, struct uffd_msg *msg)
+{
+   int ret = read(uffd, msg, sizeof(*msg));
+
+   if (ret != sizeof(*msg)) {
+   if (ret < 0) {
+   if (errno == EAGAIN)
+   return 1;
+   else
+   perror("blocking read error"), exit(1);
+   } else {
+   fprintf(stderr, "short read\n"), exit(1);
+   }
+   }
+
+   return 0;
+}
+
+/* Return 1 if page fault handled by us; otherwise 0 */
+static int uffd_handle_page_fault(struct uffd_msg *msg)
+{
+   unsigned long offset;
+
+   if (msg->event != UFFD_EVENT_PAGEFAULT)
+   fprintf(stderr, "unexpected msg event %u\n",
+   msg->event), exit(1);
+
+   if (bounces & BOUNCE_VERIFY &&
+   msg->arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WRITE)
+   fprintf(stderr, "unexpected write fault\n"), exit(1);
+
+   offset = (char *)(unsigned long)msg->arg.pagefault.address - area_dst;
+   offset &= ~(page_size-1);
+
+   return copy_page(uffd, offset);
+}
+
 static void *uffd_poll_thread(void *arg)
 {
unsigned long cpu = (unsigned long) arg;
@@ -458,7 +495,6 @@ static void *uffd_poll_thread(void *arg)
struct uffd_msg msg;
struct uffdio_register uffd_reg;
int ret;
-   unsigned long offset;
char tmp_chr;
unsigned long userfaults = 0;
 
@@ -482,25 +518,15 @@ static void *uffd_poll_thread(void *arg)
if (!(pollfd[0].revents & POLLIN))
fprintf(stderr, "pollfd[0].revents %d\n",
pollfd[0].revents), exit(1);
-   ret = read(uffd, &msg, sizeof(msg));
-   if (ret < 0) {
-   if (errno == EAGAIN)
-   continue;
-   perror("nonblocking read error"), exit(1);
-   }
+   if (uffd_read_msg(uffd, &msg))
+   continue;
switch (msg.event) {
default:
fprintf(stderr, "unexpected msg event %u\n",
msg.event), exit(1);
break;
case UFFD_EVENT_PAGEFAULT:
-   if (msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WRITE)
-   fprintf(stderr, "unexpected write fault\n"), 
exit(1);
-   offset = (char *)(unsigned 
long)msg.arg.pagefault.address -
-   area_dst;
-   offset &= ~(page_size-1);
-   if (copy_page(uffd, offset))
-   userfaults++;
+   userfaults += uffd_handle_page_fault(&msg);
break;
case UFFD_EVENT_FORK:
close(uffd);
@@ -528,8 +554,6 @@ static void *uffd_read_thread(void *arg)
 {
unsigned long *this_cpu_userfaults;
struct uffd_msg msg;
-   unsigned long offset;
-   int ret;
 
this_cpu_userfaults = (unsigned long *) arg;
*this_cpu_userfaults = 0;
@@ -538,24 +562,9 @@ static void *uffd_read_thread(void *arg)
/* from here cancellation is ok */
 
for (;;) {
-   ret = read(uffd, &msg, sizeof(msg));
-   if (ret != sizeof(msg)) {
-   if (ret < 0)
-   perror("blocking read error"), exit(1);
-   else
-   fprintf(stderr, "short read\n"), exit(1);
-   }
-   if (msg.event != UFFD_EVENT_PAGEFAULT)
-   fprintf(stderr, "unexpected msg event %u\n",
-   msg.event), exit(1);
-   if (bounces & BOUNCE_VERIFY &&
-   msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WRITE)
-   fprintf(stderr, "unexpected write fault\n"), exit(1);
-   offset = (char *)(unsigned long)msg.arg.pagefault.addres

[PATCH] staging: ks7010: Remove unnecessary null check

2018-09-30 Thread Aymen Qader

Remove the unnecessary socket buffer null check in hostif_data_request.
There is already an appropriate null check in the calling function:

(ks_wlan_net.c) ks_wlan_start_xmit

Signed-off-by: Aymen Qader 
---
 drivers/staging/ks7010/ks_hostif.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/ks7010/ks_hostif.c 
b/drivers/staging/ks7010/ks_hostif.c
index 0e554e3359b5..ca030d3f609f 100644
--- a/drivers/staging/ks7010/ks_hostif.c
+++ b/drivers/staging/ks7010/ks_hostif.c
@@ -1023,8 +1023,8 @@ int hostif_data_request(struct ks_wlan_private *priv, 
struct sk_buff *skb)
priv->wpa.mic_failure.stop) {
if (netif_queue_stopped(priv->net_dev))
netif_wake_queue(priv->net_dev);
-   if (skb)
-   dev_kfree_skb(skb);
+
+   dev_kfree_skb(skb);
 
return 0;
}
-- 
2.17.1

Re: [LKP] [fsnotify] 60f7ed8c7c: will-it-scale.per_thread_ops -5.9% regression

2018-09-30 Thread Amir Goldstein

On Sun, Sep 30, 2018 at 9:50 AM kernel test robot  wrote:
>
> Greeting,
>
> FYI, we noticed a -5.9% regression of will-it-scale.per_thread_ops due to 
> commit:
>
>
> commit: 60f7ed8c7c4d06aeda448c6da74621552ee739aa ("fsnotify: send path type 
> events to group with super block marks")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
>
> in testcase: will-it-scale
> on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 
> 64G memory
> with following parameters:
>
> nr_task: 16
> mode: thread
> test: unlink2
> cpufreq_governor: performance
>
> test-description: Will It Scale takes a testcase and runs it from 1 through 
> to n parallel copies to see if the testcase will scale. It builds both a 
> process and threads based test in order to see any differences between the 
> two.
> test-url: https://github.com/antonblanchard/will-it-scale
>
>
>
> Details are as below:
> -->
>
>
> To reproduce:
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp install job.yaml  # job file is attached in this email
> bin/lkp run job.yaml
>
> =
> compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase:
>   
> gcc-7/performance/x86_64-rhel-7.2/thread/16/debian-x86_64-2018-04-03.cgz/lkp-bdw-ep3d/unlink2/will-it-scale
>
> commit:
>   1e6cb72399 ("fsnotify: add super block object type")
>   60f7ed8c7c ("fsnotify: send path type events to group with super block 
> marks")
>

I have to admit this looks strange.
All this commit does is dereference mnt->mnt.mnt_sb and then
sb->s_fsnotify_mask/sb->s_fsnotify_marks to find that they are zero.
AFAICT there should be no extra contention added by this commit and it's
hard to believe that parallel unlink workload would suffer from this change.

I will try to install lkp-tests to verify this on my own system, but
until proven
otherwise I will regard this as false positive.

Thanks,
Amir.

Re: [LKP] [fsnotify] 60f7ed8c7c: will-it-scale.per_thread_ops -5.9% regression

2018-09-30 Thread Amir Goldstein

On Sun, Sep 30, 2018 at 12:00 PM Amir Goldstein  wrote:
>
> On Sun, Sep 30, 2018 at 9:50 AM kernel test robot  
> wrote:
> >
> > Greeting,
> >
> > FYI, we noticed a -5.9% regression of will-it-scale.per_thread_ops due to 
> > commit:
> >
> >
> > commit: 60f7ed8c7c4d06aeda448c6da74621552ee739aa ("fsnotify: send path type 
> > events to group with super block marks")
> > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >
> > in testcase: will-it-scale
> > on test machine: 88 threads Intel(R) Xeon(R) CPU E5-2699 v4 @ 2.20GHz with 
> > 64G memory
> > with following parameters:
> >
> > nr_task: 16
> > mode: thread
> > test: unlink2
> > cpufreq_governor: performance
> >
> > test-description: Will It Scale takes a testcase and runs it from 1 through 
> > to n parallel copies to see if the testcase will scale. It builds both a 
> > process and threads based test in order to see any differences between the 
> > two.
> > test-url: https://github.com/antonblanchard/will-it-scale
> >
> >
> >
> > Details are as below:
> > -->
> >
> >
> > To reproduce:
> >
> > git clone https://github.com/intel/lkp-tests.git
> > cd lkp-tests
> > bin/lkp install job.yaml  # job file is attached in this email
> > bin/lkp run job.yaml
> >
> > =
> > compiler/cpufreq_governor/kconfig/mode/nr_task/rootfs/tbox_group/test/testcase:
> >   
> > gcc-7/performance/x86_64-rhel-7.2/thread/16/debian-x86_64-2018-04-03.cgz/lkp-bdw-ep3d/unlink2/will-it-scale
> >
> > commit:
> >   1e6cb72399 ("fsnotify: add super block object type")
> >   60f7ed8c7c ("fsnotify: send path type events to group with super block 
> > marks")
> >
>
> I have to admit this looks strange.
> All this commit does is dereference mnt->mnt.mnt_sb and then
> sb->s_fsnotify_mask/sb->s_fsnotify_marks to find that they are zero.
> AFAICT there should be no extra contention added by this commit and it's
> hard to believe that parallel unlink workload would suffer from this change.
>
> I will try to install lkp-tests to verify this on my own system, but
> until proven
> otherwise I will regard this as false positive.
>

Actually, is it possible to ask for a private test with the following patch
to optimize out an unneeded srcu_derefence().
This optimization (assuming it is correct) could in fact improve scaling
compared to upstream, because there are already 2 calls to
fsnotify_first_mark in the code. The blamed commit just adds a 3rd one.
I am assuming that() in the test there is an fsnotify mount mark (maybe setup
by systemd) otherwise, the optimization in line 351 would have not reached
the extra fsnotify_first_mark() call.
Can you confirm or disprove the assumption that an fanotify mount mark
is present during the test?

Thanks,
Amir.


diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
index 422fbc6dffde..8d45d82e09ff 100644
--- a/fs/notify/fsnotify.c
+++ b/fs/notify/fsnotify.c
@@ -246,6 +246,9 @@ static struct fsnotify_mark
*fsnotify_first_mark(struct fsnotify_mark_connector
struct fsnotify_mark_connector *conn;
struct hlist_node *node = NULL;

+   if (!*connp)
+   return NULL;
+
conn = srcu_dereference(*connp, &fsnotify_mark_srcu);
if (conn)
node = srcu_dereference(conn->list.first, &fsnotify_mark_srcu);

[PATCH v2 3/4] spi: spi-fsl-dspi: Fix cmd_fifo is written before tx_fifo

This patch fixes the problem of invalid data writing during the XSPI
mode transfer of the dspi controller.
In XSPI mode,When I executed TX FIFO first and then CMD FIFO for XSPI
transmission, I found that SPIx_SR[TFIWF]=1(Invalid Data present in TX
FIFO since CMD FIFO is empty).
This is the time when no data can be read or written (all the data
obtained is equal to 0).

Signed-off-by: Chuanhua Han 
---
Changes in v2:
 -The original patch is divided into multiple patches(the original
patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
mode"),one of which is segmented.

 drivers/spi/spi-fsl-dspi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 4dc1064bf408..96e790e90997 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -590,6 +590,7 @@ static void dspi_tcfq_write(struct fsl_dspi *dspi)
 */
u32 data = dspi_pop_tx(dspi);
 
+   cmd_fifo_write(dspi);
if (dspi->cur_chip->ctar_val & SPI_CTAR_LSBFE(1)) {
/* LSB */
tx_fifo_write(dspi, data & 0x);
@@ -599,7 +600,6 @@ static void dspi_tcfq_write(struct fsl_dspi *dspi)
tx_fifo_write(dspi, data >> 16);
tx_fifo_write(dspi, data & 0x);
}
-   cmd_fifo_write(dspi);
} else {
/* Write one entry to both TX FIFO and CMD FIFO
 * simultaneously.
-- 
2.17.1

[PATCH v2 4/4] spi: spi-fsl-dspi: Fix adjust the byte order when sending and receiving data

This patch fixes the byte order inversion problem in the XSPI mode of
the dspi controller during data transfer.
In XSPI mode,When I read and write data without converting the byte
order of the data, and read and write the data directly, I tested spi
flash connected by the dspi controller and found that the byte
order of the data was reversed by the correct byte order.
When I changed the byte order according to the SPIx_CTARn[LSBFE] flag,
the correct data was obtained.

Signed-off-by: Chuanhua Han 
---
Changes in v2:
 -The original patch is divided into multiple patches(the original
patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
mode"),one of which is segmented.

 drivers/spi/spi-fsl-dspi.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 96e790e90997..44cc2bd0120e 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -220,9 +220,15 @@ static u32 dspi_pop_tx(struct fsl_dspi *dspi)
if (dspi->bytes_per_word == 1)
txdata = *(u8 *)dspi->tx;
else if (dspi->bytes_per_word == 2)
-   txdata = *(u16 *)dspi->tx;
+   if (dspi->cur_chip->ctar_val & SPI_CTAR_LSBFE(1))
+   txdata =  cpu_to_le16(*(u16 *)dspi->tx);
+   else
+   txdata =  cpu_to_be16(*(u16 *)dspi->tx);
else  /* dspi->bytes_per_word == 4 */
-   txdata = *(u32 *)dspi->tx;
+   if (dspi->cur_chip->ctar_val & SPI_CTAR_LSBFE(1))
+   txdata = cpu_to_le32(*(u32 *)dspi->tx);
+   else
+   txdata = cpu_to_be32(*(u32 *)dspi->tx);
dspi->tx += dspi->bytes_per_word;
}
dspi->len -= dspi->bytes_per_word;
@@ -246,9 +252,15 @@ static void dspi_push_rx(struct fsl_dspi *dspi, u32 rxdata)
if (dspi->bytes_per_word == 1)
*(u8 *)dspi->rx = rxdata;
else if (dspi->bytes_per_word == 2)
-   *(u16 *)dspi->rx = rxdata;
+   if (dspi->cur_chip->ctar_val & SPI_CTAR_LSBFE(1))
+   *(u16 *)dspi->rx = be16_to_cpu(rxdata);
+   else
+   *(u16 *)dspi->rx = be16_to_cpu(rxdata);
else /* dspi->bytes_per_word == 4 */
-   *(u32 *)dspi->rx = rxdata;
+   if (dspi->cur_chip->ctar_val & SPI_CTAR_LSBFE(1))
+   *(u32 *)dspi->rx = le32_to_cpu(rxdata);
+   else
+   *(u32 *)dspi->rx = be32_to_cpu(rxdata);
dspi->rx += dspi->bytes_per_word;
 }
 
@@ -593,12 +605,12 @@ static void dspi_tcfq_write(struct fsl_dspi *dspi)
cmd_fifo_write(dspi);
if (dspi->cur_chip->ctar_val & SPI_CTAR_LSBFE(1)) {
/* LSB */
-   tx_fifo_write(dspi, data & 0x);
tx_fifo_write(dspi, data >> 16);
+   tx_fifo_write(dspi, data & 0x);
} else {
/* MSB */
-   tx_fifo_write(dspi, data >> 16);
tx_fifo_write(dspi, data & 0x);
+   tx_fifo_write(dspi, data >> 16);
}
} else {
/* Write one entry to both TX FIFO and CMD FIFO
-- 
2.17.1

[PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of undefined bitmask for rxdata

This patch fixes the problem of rxdata being equal to 0 during the XSPI
mode transfer of the dspi controller.
In XSPI mode, If it is not deleted, the value of rxdata will be equal
to 0, and the data received will not be received correctly, causing the
receiving transfer of the spi to fail.

Signed-off-by: Chuanhua Han 
---
Changes in v2:
 -The original patch is divided into multiple patches(the original
patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
mode"),one of which is segmented.

 drivers/spi/spi-fsl-dspi.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 3082e72e4f6c..4dc1064bf408 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -243,9 +243,6 @@ static void dspi_push_rx(struct fsl_dspi *dspi, u32 rxdata)
if (!dspi->rx)
return;
 
-   /* Mask of undefined bits */
-   rxdata &= (1 << dspi->bits_per_word) - 1;
-
if (dspi->bytes_per_word == 1)
*(u8 *)dspi->rx = rxdata;
else if (dspi->bytes_per_word == 2)
-- 
2.17.1

[PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function

Before we add this spi_transfer to the spi_message chain table, we need
bits_per_word_mask based on spi_control to set the bits_per_word of
this spi_transfer.

Signed-off-by: Chuanhua Han 
---
Changes in v2:
 -The original patch is divided into multiple patches(the original
patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
mode"),one of which is segmented.

 drivers/spi/spi-mem.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
index eb72dba71d83..717e711c0952 100644
--- a/drivers/spi/spi-mem.c
+++ b/drivers/spi/spi-mem.c
@@ -175,6 +175,41 @@ bool spi_mem_supports_op(struct spi_mem *mem, const struct 
spi_mem_op *op)
 }
 EXPORT_SYMBOL_GPL(spi_mem_supports_op);
 
+/**
+ * spi_set_xfer_bpw() - Set the bits_per_word for each transfer based on
+ * the bits_per_word_mask of the spi controller
+ * @ctrl: the spi controller
+ * @xfer: the spi transfer
+ *
+ * This function sets the bits_per_word for each transfer based on the spi
+ * controller's bits_per_word_mask to improve the efficiency of spi transport.
+ *
+ * Return: 0 in case of success, a negative error code otherwise.
+ */
+int spi_set_xfer_bpw(struct spi_controller *ctlr, struct spi_transfer *xfer)
+{
+   if (!ctlr || !xfer) {
+   dev_err(&ctlr->dev,
+   "Fail to set bits_per_word for spi transfer\n");
+   return -EINVAL;
+   }
+
+   if (ctlr->bits_per_word_mask) {
+   if (!(xfer->len % 4)) {
+   if (ctlr->bits_per_word_mask & SPI_BPW_MASK(32))
+   xfer->bits_per_word = 32;
+   } else if (!(xfer->len % 2)) {
+   if (ctlr->bits_per_word_mask & SPI_BPW_MASK(16))
+   xfer->bits_per_word = 16;
+   } else {
+   xfer->bits_per_word = 8;
+   }
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(spi_set_xfer_bpw);
+
 /**
  * spi_mem_exec_op() - Execute a memory operation
  * @mem: the SPI memory
@@ -252,6 +287,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct 
spi_mem_op *op)
xfers[xferpos].tx_buf = tmpbuf;
xfers[xferpos].len = sizeof(op->cmd.opcode);
xfers[xferpos].tx_nbits = op->cmd.buswidth;
+   spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
spi_message_add_tail(&xfers[xferpos], &msg);
xferpos++;
totalxferlen++;
@@ -266,6 +302,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct 
spi_mem_op *op)
xfers[xferpos].tx_buf = tmpbuf + 1;
xfers[xferpos].len = op->addr.nbytes;
xfers[xferpos].tx_nbits = op->addr.buswidth;
+   spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
spi_message_add_tail(&xfers[xferpos], &msg);
xferpos++;
totalxferlen += op->addr.nbytes;
@@ -276,6 +313,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct 
spi_mem_op *op)
xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1;
xfers[xferpos].len = op->dummy.nbytes;
xfers[xferpos].tx_nbits = op->dummy.buswidth;
+   spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
spi_message_add_tail(&xfers[xferpos], &msg);
xferpos++;
totalxferlen += op->dummy.nbytes;
@@ -291,6 +329,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct 
spi_mem_op *op)
}
 
xfers[xferpos].len = op->data.nbytes;
+   spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
spi_message_add_tail(&xfers[xferpos], &msg);
xferpos++;
totalxferlen += op->data.nbytes;
-- 
2.17.1

Re: [PATCH v2 2/3] userfaultfd: selftest: generalize read and poll

2018-09-30 Thread Mike Rapoport

On Sun, Sep 30, 2018 at 03:42:58PM +0800, Peter Xu wrote:
> We do very similar things in read and poll modes, but we're copying the
> codes around.  Share the codes properly on reading the message and
> handling the page fault to make the code cleaner.  Meanwhile this solves
> previous mismatch of behaviors between the two modes on that the old
> code:
> 
> - did not check EAGAIN case in read() mode
> - ignored BOUNCE_VERIFY check in read() mode
> 
> Signed-off-by: Peter Xu 

Acked-by: Mike Rapoport 

> ---
>  tools/testing/selftests/vm/userfaultfd.c | 77 +---
>  1 file changed, 43 insertions(+), 34 deletions(-)
> 
> diff --git a/tools/testing/selftests/vm/userfaultfd.c 
> b/tools/testing/selftests/vm/userfaultfd.c
> index 5ff3a4f9173e..7a8c6937cc67 100644
> --- a/tools/testing/selftests/vm/userfaultfd.c
> +++ b/tools/testing/selftests/vm/userfaultfd.c
> @@ -451,6 +451,43 @@ static int copy_page(int ufd, unsigned long offset)
>   return __copy_page(ufd, offset, false);
>  }
> 
> +static int uffd_read_msg(int ufd, struct uffd_msg *msg)
> +{
> + int ret = read(uffd, msg, sizeof(*msg));
> +
> + if (ret != sizeof(*msg)) {
> + if (ret < 0) {
> + if (errno == EAGAIN)
> + return 1;
> + else
> + perror("blocking read error"), exit(1);
> + } else {
> + fprintf(stderr, "short read\n"), exit(1);
> + }
> + }
> +
> + return 0;
> +}
> +
> +/* Return 1 if page fault handled by us; otherwise 0 */
> +static int uffd_handle_page_fault(struct uffd_msg *msg)
> +{
> + unsigned long offset;
> +
> + if (msg->event != UFFD_EVENT_PAGEFAULT)
> + fprintf(stderr, "unexpected msg event %u\n",
> + msg->event), exit(1);
> +
> + if (bounces & BOUNCE_VERIFY &&
> + msg->arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WRITE)
> + fprintf(stderr, "unexpected write fault\n"), exit(1);
> +
> + offset = (char *)(unsigned long)msg->arg.pagefault.address - area_dst;
> + offset &= ~(page_size-1);
> +
> + return copy_page(uffd, offset);
> +}
> +
>  static void *uffd_poll_thread(void *arg)
>  {
>   unsigned long cpu = (unsigned long) arg;
> @@ -458,7 +495,6 @@ static void *uffd_poll_thread(void *arg)
>   struct uffd_msg msg;
>   struct uffdio_register uffd_reg;
>   int ret;
> - unsigned long offset;
>   char tmp_chr;
>   unsigned long userfaults = 0;
> 
> @@ -482,25 +518,15 @@ static void *uffd_poll_thread(void *arg)
>   if (!(pollfd[0].revents & POLLIN))
>   fprintf(stderr, "pollfd[0].revents %d\n",
>   pollfd[0].revents), exit(1);
> - ret = read(uffd, &msg, sizeof(msg));
> - if (ret < 0) {
> - if (errno == EAGAIN)
> - continue;
> - perror("nonblocking read error"), exit(1);
> - }
> + if (uffd_read_msg(uffd, &msg))
> + continue;
>   switch (msg.event) {
>   default:
>   fprintf(stderr, "unexpected msg event %u\n",
>   msg.event), exit(1);
>   break;
>   case UFFD_EVENT_PAGEFAULT:
> - if (msg.arg.pagefault.flags & UFFD_PAGEFAULT_FLAG_WRITE)
> - fprintf(stderr, "unexpected write fault\n"), 
> exit(1);
> - offset = (char *)(unsigned 
> long)msg.arg.pagefault.address -
> - area_dst;
> - offset &= ~(page_size-1);
> - if (copy_page(uffd, offset))
> - userfaults++;
> + userfaults += uffd_handle_page_fault(&msg);
>   break;
>   case UFFD_EVENT_FORK:
>   close(uffd);
> @@ -528,8 +554,6 @@ static void *uffd_read_thread(void *arg)
>  {
>   unsigned long *this_cpu_userfaults;
>   struct uffd_msg msg;
> - unsigned long offset;
> - int ret;
> 
>   this_cpu_userfaults = (unsigned long *) arg;
>   *this_cpu_userfaults = 0;
> @@ -538,24 +562,9 @@ static void *uffd_read_thread(void *arg)
>   /* from here cancellation is ok */
> 
>   for (;;) {
> - ret = read(uffd, &msg, sizeof(msg));
> - if (ret != sizeof(msg)) {
> - if (ret < 0)
> - perror("blocking read error"), exit(1);
> - else
> - fprintf(stderr, "short read\n"), exit(1);
> - }
> - if (msg.event != UFFD_EVENT_PAGEFAULT)
> - fprintf(stderr, "unexpected msg event %u\n",
> - msg.event), exit(1);
> - if (bounces & BOUNCE_VERIFY &&
> - msg.arg.pagefault.flags

Re: [PATCH] MAINTAINERS: Update clock binding entry for Actions Semi Owl SoCs

2018-09-30 Thread Andreas Färber

Am 29.09.18 um 09:32 schrieb Manivannan Sadhasivam:
> commit d0e45d686a3e ("dt-bindings: clock: Add S700 support for Actions
> Semi Soc's")'
> 
> renamed the clock binding for Actions Semi Owl SoCs from
> actions,s900-cmu.txt to actions,owl-cmu.txt inorder to accommodate all
> members of Owl family SoCs. Hence, update the relevant entry in
> MAINTAINERS file.
> 
> Signed-off-by: Manivannan Sadhasivam 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index fff353db7536..e9d6ce3243ce 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1191,7 +1191,7 @@ F:  drivers/soc/actions/
>  F:   include/dt-bindings/power/owl-*
>  F:   include/linux/soc/actions/
>  F:   Documentation/devicetree/bindings/arm/actions.txt
> -F:   Documentation/devicetree/bindings/clock/actions,s900-cmu.txt
> +F:   Documentation/devicetree/bindings/clock/actions,owl-cmu.txt
>  F:   Documentation/devicetree/bindings/dma/owl-dma.txt
>  F:   Documentation/devicetree/bindings/i2c/i2c-owl.txt

These two lines do not yet exist on v4.20/arm64 branch - rebased and
applied.

>  F:   Documentation/devicetree/bindings/pinctrl/actions,s900-pinctrl.txt

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function

Hi Chuanhua,

On Sun, 30 Sep 2018 17:25:32 +0800
Chuanhua Han  wrote:

> Before we add this spi_transfer to the spi_message chain table, we need
> bits_per_word_mask based on spi_control to set the bits_per_word of
> this spi_transfer.

Let's make it clearer: this is wrong. The spi-mem protocol is just
using bytes, not custom size words. Fix the fsl-dspi driver if needed,
but don't try to adjust xfer->bits_per_word in spi-mem.c, because this
is inappropriate.

Regards,

Boris

> 
> Signed-off-by: Chuanhua Han 
> ---
> Changes in v2:
>  -The original patch is divided into multiple patches(the original
> patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> mode"),one of which is segmented.
> 
>  drivers/spi/spi-mem.c | 39 +++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c
> index eb72dba71d83..717e711c0952 100644
> --- a/drivers/spi/spi-mem.c
> +++ b/drivers/spi/spi-mem.c
> @@ -175,6 +175,41 @@ bool spi_mem_supports_op(struct spi_mem *mem, const 
> struct spi_mem_op *op)
>  }
>  EXPORT_SYMBOL_GPL(spi_mem_supports_op);
>  
> +/**
> + * spi_set_xfer_bpw() - Set the bits_per_word for each transfer based on
> + *   the bits_per_word_mask of the spi controller
> + * @ctrl: the spi controller
> + * @xfer: the spi transfer
> + *
> + * This function sets the bits_per_word for each transfer based on the spi
> + * controller's bits_per_word_mask to improve the efficiency of spi 
> transport.
> + *
> + * Return: 0 in case of success, a negative error code otherwise.
> + */
> +int spi_set_xfer_bpw(struct spi_controller *ctlr, struct spi_transfer *xfer)
> +{
> + if (!ctlr || !xfer) {
> + dev_err(&ctlr->dev,
> + "Fail to set bits_per_word for spi transfer\n");
> + return -EINVAL;
> + }
> +
> + if (ctlr->bits_per_word_mask) {
> + if (!(xfer->len % 4)) {
> + if (ctlr->bits_per_word_mask & SPI_BPW_MASK(32))
> + xfer->bits_per_word = 32;
> + } else if (!(xfer->len % 2)) {
> + if (ctlr->bits_per_word_mask & SPI_BPW_MASK(16))
> + xfer->bits_per_word = 16;
> + } else {
> + xfer->bits_per_word = 8;
> + }
> + }
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(spi_set_xfer_bpw);
> +
>  /**
>   * spi_mem_exec_op() - Execute a memory operation
>   * @mem: the SPI memory
> @@ -252,6 +287,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct 
> spi_mem_op *op)
>   xfers[xferpos].tx_buf = tmpbuf;
>   xfers[xferpos].len = sizeof(op->cmd.opcode);
>   xfers[xferpos].tx_nbits = op->cmd.buswidth;
> + spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
>   spi_message_add_tail(&xfers[xferpos], &msg);
>   xferpos++;
>   totalxferlen++;
> @@ -266,6 +302,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct 
> spi_mem_op *op)
>   xfers[xferpos].tx_buf = tmpbuf + 1;
>   xfers[xferpos].len = op->addr.nbytes;
>   xfers[xferpos].tx_nbits = op->addr.buswidth;
> + spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
>   spi_message_add_tail(&xfers[xferpos], &msg);
>   xferpos++;
>   totalxferlen += op->addr.nbytes;
> @@ -276,6 +313,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct 
> spi_mem_op *op)
>   xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1;
>   xfers[xferpos].len = op->dummy.nbytes;
>   xfers[xferpos].tx_nbits = op->dummy.buswidth;
> + spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
>   spi_message_add_tail(&xfers[xferpos], &msg);
>   xferpos++;
>   totalxferlen += op->dummy.nbytes;
> @@ -291,6 +329,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const struct 
> spi_mem_op *op)
>   }
>  
>   xfers[xferpos].len = op->data.nbytes;
> + spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
>   spi_message_add_tail(&xfers[xferpos], &msg);
>   xferpos++;
>   totalxferlen += op->data.nbytes;

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of undefined bitmask for rxdata

On Sun, 30 Sep 2018 17:25:33 +0800
Chuanhua Han  wrote:

> This patch fixes the problem of rxdata being equal to 0 during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode, If it is not deleted, the value of rxdata will be equal
> to 0, and the data received will not be received correctly, causing the
> receiving transfer of the spi to fail.
> 
> Signed-off-by: Chuanhua Han 
> ---
> Changes in v2:
>  -The original patch is divided into multiple patches(the original
> patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> mode"),one of which is segmented.
> 
>  drivers/spi/spi-fsl-dspi.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 3082e72e4f6c..4dc1064bf408 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -243,9 +243,6 @@ static void dspi_push_rx(struct fsl_dspi *dspi, u32 
> rxdata)
>   if (!dspi->rx)
>   return;
>  
> - /* Mask of undefined bits */
> - rxdata &= (1 << dspi->bits_per_word) - 1;
> -

Why not

if (dspi->bits_per_word)
rxdata &= (1 << dspi->bits_per_word) - 1;

>   if (dspi->bytes_per_word == 1)
>   *(u8 *)dspi->rx = rxdata;
>   else if (dspi->bytes_per_word == 2)

RE: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of undefined bitmask for rxdata



> -Original Message-
> From: Boris Brezillon 
> Sent: 2018年9月30日 18:07
> To: Chuanhua Han 
> Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; e...@deif.com
> Subject: Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of
> undefined bitmask for rxdata
> 
> On Sun, 30 Sep 2018 17:25:33 +0800
> Chuanhua Han  wrote:
> 
> > This patch fixes the problem of rxdata being equal to 0 during the
> > XSPI mode transfer of the dspi controller.
> > In XSPI mode, If it is not deleted, the value of rxdata will be equal
> > to 0, and the data received will not be received correctly, causing
> > the receiving transfer of the spi to fail.
> >
> > Signed-off-by: Chuanhua Han 
> > ---
> > Changes in v2:
> >  -The original patch is divided into multiple patches(the original
> > patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> > mode"),one of which is segmented.
> >
> >  drivers/spi/spi-fsl-dspi.c | 3 ---
> >  1 file changed, 3 deletions(-)
> >
> > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > index 3082e72e4f6c..4dc1064bf408 100644
> > --- a/drivers/spi/spi-fsl-dspi.c
> > +++ b/drivers/spi/spi-fsl-dspi.c
> > @@ -243,9 +243,6 @@ static void dspi_push_rx(struct fsl_dspi *dspi, u32
> rxdata)
> > if (!dspi->rx)
> > return;
> >
> > -   /* Mask of undefined bits */
> > -   rxdata &= (1 << dspi->bits_per_word) - 1;
> > -
> 
> Why not
In xspi mode, the value of rxdata after the statement is processed is equal to 
0 no matter what data is received.
> 
>   if (dspi->bits_per_word)
>   rxdata &= (1 << dspi->bits_per_word) - 1;
> 
> > if (dspi->bytes_per_word == 1)
> > *(u8 *)dspi->rx = rxdata;
> > else if (dspi->bytes_per_word == 2)

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of undefined bitmask for rxdata

On Sun, 30 Sep 2018 10:10:14 +
Chuanhua Han  wrote:

> > -Original Message-
> > From: Boris Brezillon 
> > Sent: 2018年9月30日 18:07
> > To: Chuanhua Han 
> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; e...@deif.com
> > Subject: Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of
> > undefined bitmask for rxdata
> > 
> > On Sun, 30 Sep 2018 17:25:33 +0800
> > Chuanhua Han  wrote:
> >   
> > > This patch fixes the problem of rxdata being equal to 0 during the
> > > XSPI mode transfer of the dspi controller.
> > > In XSPI mode, If it is not deleted, the value of rxdata will be equal
> > > to 0, and the data received will not be received correctly, causing
> > > the receiving transfer of the spi to fail.
> > >
> > > Signed-off-by: Chuanhua Han 
> > > ---
> > > Changes in v2:
> > >  -The original patch is divided into multiple patches(the original
> > > patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> > > mode"),one of which is segmented.
> > >
> > >  drivers/spi/spi-fsl-dspi.c | 3 ---
> > >  1 file changed, 3 deletions(-)
> > >
> > > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> > > index 3082e72e4f6c..4dc1064bf408 100644
> > > --- a/drivers/spi/spi-fsl-dspi.c
> > > +++ b/drivers/spi/spi-fsl-dspi.c
> > > @@ -243,9 +243,6 @@ static void dspi_push_rx(struct fsl_dspi *dspi, u32  
> > rxdata)  
> > >   if (!dspi->rx)
> > >   return;
> > >
> > > - /* Mask of undefined bits */
> > > - rxdata &= (1 << dspi->bits_per_word) - 1;
> > > -  
> > 
> > Why not  
> In xspi mode, the value of rxdata after the statement is processed is equal 
> to 0 no matter what data is received.

Only if dspi->bits_per_word is 0.

Actually, I just had a look, and xfer->bits_per_word should never be 0
because spi_validate() makes sure it's initialized [1]. Don't know
where dpsi->bits_per_word comes from, but maybe you have a problem
there (dpsi->bits_per_word and xfer->bits_per_word not in sync).

[1]https://elixir.bootlin.com/linux/v4.19-rc5/source/drivers/spi/spi.c#L2869

Re: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function

Boris Brezillon  writes:

> Hi Chuanhua,
>
> On Sun, 30 Sep 2018 17:25:32 +0800
> Chuanhua Han  wrote:
>
>> Before we add this spi_transfer to the spi_message chain table, we need
>> bits_per_word_mask based on spi_control to set the bits_per_word of
>> this spi_transfer.
>
> Let's make it clearer: this is wrong. The spi-mem protocol is just
> using bytes, not custom size words. Fix the fsl-dspi driver if needed,
> but don't try to adjust xfer->bits_per_word in spi-mem.c, because this
> is inappropriate.

I don't think there is a "fix" needed in fsl-dspi driver for this.

I am not sure, but I think that what Han is trying to achieve here is
better performance.
And wile the XSPI mode does provide better performance for sending one
32 bit word, than normal mode providees for sending 4 x 8 bit words.
But as you say, this is wrong.

To improve performance, the fsl-dspi driver should be fixed to work in
DMA mode.  Implementation of erratum A-011218 is necessary in order to
use DSPI DMA mode on LS1021A.
I was planning to work on that, but haven't had the time for it.
So if you want better performance for spi-mem on LS1021A DSPI, please
work on this.

/Esben

RE: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function



> -Original Message-
> From: Boris Brezillon 
> Sent: 2018年9月30日 18:04
> To: Chuanhua Han 
> Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; e...@deif.com
> Subject: Re: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function
> 
> Hi Chuanhua,
> 
> On Sun, 30 Sep 2018 17:25:32 +0800
> Chuanhua Han  wrote:
> 
> > Before we add this spi_transfer to the spi_message chain table, we
> > need bits_per_word_mask based on spi_control to set the bits_per_word
> > of this spi_transfer.
> 
> Let's make it clearer: this is wrong. The spi-mem protocol is just using 
> bytes,
> not custom size words. Fix the fsl-dspi driver if needed, but don't try to 
> adjust
> xfer->bits_per_word in spi-mem.c, because this is inappropriate.
The value of bits_per_word is only known before the spi_message_add_tail 
function is called, 
and dspi controllers only decide which mode (8bit, 16bit, or 32bit) to use for 
data
transfer based on the value of the transfer->bits_per_word.

> 
> Regards,
> 
> Boris
> 
> >
> > Signed-off-by: Chuanhua Han 
> > ---
> > Changes in v2:
> >  -The original patch is divided into multiple patches(the original
> > patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> > mode"),one of which is segmented.
> >
> >  drivers/spi/spi-mem.c | 39
> +++
> >  1 file changed, 39 insertions(+)
> >
> > diff --git a/drivers/spi/spi-mem.c b/drivers/spi/spi-mem.c index
> > eb72dba71d83..717e711c0952 100644
> > --- a/drivers/spi/spi-mem.c
> > +++ b/drivers/spi/spi-mem.c
> > @@ -175,6 +175,41 @@ bool spi_mem_supports_op(struct spi_mem
> *mem,
> > const struct spi_mem_op *op)  }
> > EXPORT_SYMBOL_GPL(spi_mem_supports_op);
> >
> > +/**
> > + * spi_set_xfer_bpw() - Set the bits_per_word for each transfer based on
> > + * the bits_per_word_mask of the spi controller
> > + * @ctrl: the spi controller
> > + * @xfer: the spi transfer
> > + *
> > + * This function sets the bits_per_word for each transfer based on
> > +the spi
> > + * controller's bits_per_word_mask to improve the efficiency of spi
> transport.
> > + *
> > + * Return: 0 in case of success, a negative error code otherwise.
> > + */
> > +int spi_set_xfer_bpw(struct spi_controller *ctlr, struct spi_transfer
> > +*xfer) {
> > +   if (!ctlr || !xfer) {
> > +   dev_err(&ctlr->dev,
> > +   "Fail to set bits_per_word for spi transfer\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   if (ctlr->bits_per_word_mask) {
> > +   if (!(xfer->len % 4)) {
> > +   if (ctlr->bits_per_word_mask & SPI_BPW_MASK(32))
> > +   xfer->bits_per_word = 32;
> > +   } else if (!(xfer->len % 2)) {
> > +   if (ctlr->bits_per_word_mask & SPI_BPW_MASK(16))
> > +   xfer->bits_per_word = 16;
> > +   } else {
> > +   xfer->bits_per_word = 8;
> > +   }
> > +   }
> > +
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(spi_set_xfer_bpw);
> > +
> >  /**
> >   * spi_mem_exec_op() - Execute a memory operation
> >   * @mem: the SPI memory
> > @@ -252,6 +287,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const
> struct spi_mem_op *op)
> > xfers[xferpos].tx_buf = tmpbuf;
> > xfers[xferpos].len = sizeof(op->cmd.opcode);
> > xfers[xferpos].tx_nbits = op->cmd.buswidth;
> > +   spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
> > spi_message_add_tail(&xfers[xferpos], &msg);
> > xferpos++;
> > totalxferlen++;
> > @@ -266,6 +302,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const
> struct spi_mem_op *op)
> > xfers[xferpos].tx_buf = tmpbuf + 1;
> > xfers[xferpos].len = op->addr.nbytes;
> > xfers[xferpos].tx_nbits = op->addr.buswidth;
> > +   spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
> > spi_message_add_tail(&xfers[xferpos], &msg);
> > xferpos++;
> > totalxferlen += op->addr.nbytes;
> > @@ -276,6 +313,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const
> struct spi_mem_op *op)
> > xfers[xferpos].tx_buf = tmpbuf + op->addr.nbytes + 1;
> > xfers[xferpos].len = op->dummy.nbytes;
> > xfers[xferpos].tx_nbits = op->dummy.buswidth;
> > +   spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
> > spi_message_add_tail(&xfers[xferpos], &msg);
> > xferpos++;
> > totalxferlen += op->dummy.nbytes;
> > @@ -291,6 +329,7 @@ int spi_mem_exec_op(struct spi_mem *mem, const
> struct spi_mem_op *op)
> > }
> >
> > xfers[xferpos].len = op->data.nbytes;
> > +   spi_set_xfer_bpw(ctlr, &xfers[xferpos]);
> > spi_message_add_tail(&xfers[xferpos], &msg);
> > xferpos++;
> > totalxferlen += op->data.nbytes;

Re: [PATCH v2 4/4] spi: spi-fsl-dspi: Fix adjust the byte order when sending and receiving data

Chuanhua Han  writes:

> This patch fixes the byte order inversion problem in the XSPI mode of
> the dspi controller during data transfer.
> In XSPI mode,When I read and write data without converting the byte
> order of the data, and read and write the data directly, I tested spi
> flash connected by the dspi controller and found that the byte
> order of the data was reversed by the correct byte order.
> When I changed the byte order according to the SPIx_CTARn[LSBFE] flag,
> the correct data was obtained.

I believe this is related to patch 1/4 of this series, and your attempt
on pushing the 8-bit spi-mem data into 32-bit SPI words.  The
byte-ordering for that does not belong here, and will likely break
byte-ordering for other (proper) use of XSPI mode.

My advice is that you focus your effort on implementing/fixing DMA mode,
ie. erratum A-011218.
A proper implementation of that will be appreciated, and should give you
much better performance than XSPI mode would be able to give you.

/Esben

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of undefined bitmask for rxdata

Chuanhua Han  writes:

> This patch fixes the problem of rxdata being equal to 0 during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode, If it is not deleted, the value of rxdata will be equal
> to 0, and the data received will not be received correctly, causing the
> receiving transfer of the spi to fail.
>
> Signed-off-by: Chuanhua Han 
> ---
> Changes in v2:
>  -The original patch is divided into multiple patches(the original
> patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> mode"),one of which is segmented.
>
>  drivers/spi/spi-fsl-dspi.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 3082e72e4f6c..4dc1064bf408 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -243,9 +243,6 @@ static void dspi_push_rx(struct fsl_dspi *dspi, u32 
> rxdata)
>   if (!dspi->rx)
>   return;
>  
> - /* Mask of undefined bits */
> - rxdata &= (1 << dspi->bits_per_word) - 1;

What is the dspi->bits_per_word value when your rxdata is set equal to
0?  Could this perhaps also be related to byte ordering problems?

>   if (dspi->bytes_per_word == 1)
>   *(u8 *)dspi->rx = rxdata;
>   else if (dspi->bytes_per_word == 2)

/Esben

Re: [PATCH v2 3/4] spi: spi-fsl-dspi: Fix cmd_fifo is written before tx_fifo

Chuanhua Han  writes:

> This patch fixes the problem of invalid data writing during the XSPI
> mode transfer of the dspi controller.
> In XSPI mode,When I executed TX FIFO first and then CMD FIFO for XSPI
> transmission, I found that SPIx_SR[TFIWF]=1(Invalid Data present in TX
> FIFO since CMD FIFO is empty).
> This is the time when no data can be read or written (all the data
> obtained is equal to 0).
>
> Signed-off-by: Chuanhua Han 
> ---
> Changes in v2:
>  -The original patch is divided into multiple patches(the original
> patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> mode"),one of which is segmented.
>
>  drivers/spi/spi-fsl-dspi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> index 4dc1064bf408..96e790e90997 100644
> --- a/drivers/spi/spi-fsl-dspi.c
> +++ b/drivers/spi/spi-fsl-dspi.c
> @@ -590,6 +590,7 @@ static void dspi_tcfq_write(struct fsl_dspi *dspi)
>*/
>   u32 data = dspi_pop_tx(dspi);
>  
> + cmd_fifo_write(dspi);
>   if (dspi->cur_chip->ctar_val & SPI_CTAR_LSBFE(1)) {
>   /* LSB */
>   tx_fifo_write(dspi, data & 0x);
> @@ -599,7 +600,6 @@ static void dspi_tcfq_write(struct fsl_dspi *dspi)
>   tx_fifo_write(dspi, data >> 16);
>   tx_fifo_write(dspi, data & 0x);
>   }
> - cmd_fifo_write(dspi);
>   } else {
>   /* Write one entry to both TX FIFO and CMD FIFO
>* simultaneously.

I will try and find time to test this on our systems at work.

/Esben

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of undefined bitmask for rxdata

Boris Brezillon  writes:

> On Sun, 30 Sep 2018 10:10:14 +
> Chuanhua Han  wrote:
>
>> > -Original Message-
>> > From: Boris Brezillon 
>> > Sent: 2018年9月30日 18:07
>> > To: Chuanhua Han 
>> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
>> > linux-kernel@vger.kernel.org; e...@deif.com
>> > Subject: Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of
>> > undefined bitmask for rxdata
>> > 
>> > On Sun, 30 Sep 2018 17:25:33 +0800
>> > Chuanhua Han  wrote:
>> >   
>> > > This patch fixes the problem of rxdata being equal to 0 during the
>> > > XSPI mode transfer of the dspi controller.
>> > > In XSPI mode, If it is not deleted, the value of rxdata will be equal
>> > > to 0, and the data received will not be received correctly, causing
>> > > the receiving transfer of the spi to fail.
>> > >
>> > > Signed-off-by: Chuanhua Han 
>> > > ---
>> > > Changes in v2:
>> > >  -The original patch is divided into multiple patches(the original
>> > > patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
>> > > mode"),one of which is segmented.
>> > >
>> > >  drivers/spi/spi-fsl-dspi.c | 3 ---
>> > >  1 file changed, 3 deletions(-)
>> > >
>> > > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
>> > > index 3082e72e4f6c..4dc1064bf408 100644
>> > > --- a/drivers/spi/spi-fsl-dspi.c
>> > > +++ b/drivers/spi/spi-fsl-dspi.c
>> > > @@ -243,9 +243,6 @@ static void dspi_push_rx(struct fsl_dspi *dspi, u32  
>> > rxdata)  
>> > >  if (!dspi->rx)
>> > >  return;
>> > >
>> > > -/* Mask of undefined bits */
>> > > -rxdata &= (1 << dspi->bits_per_word) - 1;
>> > > -  
>> > 
>> > Why not  
>> In xspi mode, the value of rxdata after the statement is processed is equal
>> to 0 no matter what data is received.
>
> Only if dspi->bits_per_word is 0.
>
> Actually, I just had a look, and xfer->bits_per_word should never be 0
> because spi_validate() makes sure it's initialized [1]. Don't know
> where dpsi->bits_per_word comes from, but maybe you have a problem
> there (dpsi->bits_per_word and xfer->bits_per_word not in sync).
>
> [1]https://elixir.bootlin.com/linux/v4.19-rc5/source/drivers/spi/spi.c#L2869

dspi->bits_per_word = xfer->bits_per_word

https://elixir.bootlin.com/linux/v4.19-rc5/source/drivers/spi/spi-fsl-dspi.c#L697

So it should never be out of sync, and it should never be 0.

As I mentioned in another mail, I suspect what Han is observing is
caused by byte ordering, so that the mask masks the wrong data.
Maybe related to the byte-ordering fix patch.

/Esben

RE: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of undefined bitmask for rxdata



> -Original Message-
> From: Boris Brezillon 
> Sent: 2018年9月30日 18:17
> To: Chuanhua Han 
> Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; e...@deif.com
> Subject: Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of
> undefined bitmask for rxdata
> 
> On Sun, 30 Sep 2018 10:10:14 +
> Chuanhua Han  wrote:
> 
> > > -Original Message-
> > > From: Boris Brezillon 
> > > Sent: 2018年9月30日 18:07
> > > To: Chuanhua Han 
> > > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; e...@deif.com
> > > Subject: Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the
> > > processing of undefined bitmask for rxdata
> > >
> > > On Sun, 30 Sep 2018 17:25:33 +0800
> > > Chuanhua Han  wrote:
> > >
> > > > This patch fixes the problem of rxdata being equal to 0 during the
> > > > XSPI mode transfer of the dspi controller.
> > > > In XSPI mode, If it is not deleted, the value of rxdata will be
> > > > equal to 0, and the data received will not be received correctly,
> > > > causing the receiving transfer of the spi to fail.
> > > >
> > > > Signed-off-by: Chuanhua Han 
> > > > ---
> > > > Changes in v2:
> > > >  -The original patch is divided into multiple patches(the original
> > > > patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> > > > mode"),one of which is segmented.
> > > >
> > > >  drivers/spi/spi-fsl-dspi.c | 3 ---
> > > >  1 file changed, 3 deletions(-)
> > > >
> > > > diff --git a/drivers/spi/spi-fsl-dspi.c
> > > > b/drivers/spi/spi-fsl-dspi.c index 3082e72e4f6c..4dc1064bf408
> > > > 100644
> > > > --- a/drivers/spi/spi-fsl-dspi.c
> > > > +++ b/drivers/spi/spi-fsl-dspi.c
> > > > @@ -243,9 +243,6 @@ static void dspi_push_rx(struct fsl_dspi
> > > > *dspi, u32
> > > rxdata)
> > > > if (!dspi->rx)
> > > > return;
> > > >
> > > > -   /* Mask of undefined bits */
> > > > -   rxdata &= (1 << dspi->bits_per_word) - 1;
> > > > -
> > >
> > > Why not
> > In xspi mode, the value of rxdata after the statement is processed is equal 
> > to
> 0 no matter what data is received.
> 
> Only if dspi->bits_per_word is 0.
> 
> Actually, I just had a look, and xfer->bits_per_word should never be 0 because
> spi_validate() makes sure it's initialized [1]. Don't know where
> dpsi->bits_per_word comes from, but maybe you have a problem there
> (dpsi->bits_per_word and xfer->bits_per_word not in sync).
> 
> [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feli
> xir.bootlin.com%2Flinux%2Fv4.19-rc5%2Fsource%2Fdrivers%2Fspi%2Fspi.c%23
> L2869&data=02%7C01%7Cchuanhua.han%40nxp.com%7Cd92a3b54ccf0
> 4d1c1f3208d626bde775%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C
> 0%7C636738994411369491&sdata=piLwfBc0kzMhOnI5uubHYJ9tbe%2BR
> KENKbYiLrkY1c30%3D&reserved=0
OK, Let me analyze it again,Thanks!

RE: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function



> -Original Message-
> From: Esben Haabendal  On Behalf Of Esben
> Haabendal
> Sent: 2018年9月30日 18:18
> To: Boris Brezillon 
> Cc: Chuanhua Han ; broo...@kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function
> 
> Boris Brezillon  writes:
> 
> > Hi Chuanhua,
> >
> > On Sun, 30 Sep 2018 17:25:32 +0800
> > Chuanhua Han  wrote:
> >
> >> Before we add this spi_transfer to the spi_message chain table, we
> >> need bits_per_word_mask based on spi_control to set the bits_per_word
> >> of this spi_transfer.
> >
> > Let's make it clearer: this is wrong. The spi-mem protocol is just
> > using bytes, not custom size words. Fix the fsl-dspi driver if needed,
> > but don't try to adjust xfer->bits_per_word in spi-mem.c, because this
> > is inappropriate.
> 
> I don't think there is a "fix" needed in fsl-dspi driver for this.
> 
> I am not sure, but I think that what Han is trying to achieve here is better
> performance.
> And wile the XSPI mode does provide better performance for sending one
> 32 bit word, than normal mode providees for sending 4 x 8 bit words.
> But as you say, this is wrong.
> 
> To improve performance, the fsl-dspi driver should be fixed to work in DMA
> mode.  Implementation of erratum A-011218 is necessary in order to use
> DSPI DMA mode on LS1021A.
> I was planning to work on that, but haven't had the time for it.
> So if you want better performance for spi-mem on LS1021A DSPI, please work
> on this.
> 
> /Esben
Hi，
Another colleague is responsible for the DMA transmission of dspi.
I am not clear about it. I just fix the transmission of XSPI mode with several 
patches. 
Thank you for your comments.

Re: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function

On Sun, 30 Sep 2018 10:18:18 +
Chuanhua Han  wrote:

> > -Original Message-
> > From: Boris Brezillon 
> > Sent: 2018年9月30日 18:04
> > To: Chuanhua Han 
> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; e...@deif.com
> > Subject: Re: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function
> > 
> > Hi Chuanhua,
> > 
> > On Sun, 30 Sep 2018 17:25:32 +0800
> > Chuanhua Han  wrote:
> >   
> > > Before we add this spi_transfer to the spi_message chain table, we
> > > need bits_per_word_mask based on spi_control to set the bits_per_word
> > > of this spi_transfer.  
> > 
> > Let's make it clearer: this is wrong. The spi-mem protocol is just using 
> > bytes,
> > not custom size words. Fix the fsl-dspi driver if needed, but don't try to 
> > adjust
> > xfer->bits_per_word in spi-mem.c, because this is inappropriate.  
> The value of bits_per_word is only known before the spi_message_add_tail 
> function is called,

No, it's not. It's known from the beginning, and spi_setup() defaults
to 8 when spidev->bits_per_word is 0, which is exactly what we
want. Then, when you send a message through, spi_sync(), spi_validate()
makes sure that each transfer in the message has a
xfer->bits_per_word != 0 and when that's not the case, it sets it to
spi->bits_per_word [2].

Really, there's nothing to fix in spi-mem.c, because it's already doing
the right thing (leaving ->bits_per_word to 0 so that it's set to
spi->bits_per_word, which should be 8). Maybe we have a bug somewhere
else though.

[1]https://elixir.bootlin.com/linux/v4.19-rc5/source/drivers/spi/spi.c#L2803
[2]https://elixir.bootlin.com/linux/v4.19-rc5/source/drivers/spi/spi.c#L2869

[STABLE PATCH] slub: make ->cpu_partial unsigned int

2018-09-30 Thread zhong jiang

From: Alexey Dobriyan 

[ Upstream commit e5d9998f3e09359b372a037a6ac55ba235d95d57 ]

/*
 * cpu_partial determined the maximum number of objects
 * kept in the per cpu partial lists of a processor.
 */

Can't be negative.

I hit a real issue that it will result in a large number of memory leak.
Becuase Freeing slabs are in interrupt context. So it can trigger this issue.
put_cpu_partial can be interrupted more than once.
due to a union struct of lru and pobjects in struct page, when other core 
handles
page->lru list, for eaxmple, remove_partial in freeing slab code flow, It will
result in pobjects being a negative value(0xdead). Therefore, a large number
of slabs will be added to per_cpu partial list.

I had posted the issue to community before. The detailed issue description is 
as follows.

https://www.spinics.net/lists/kernel/msg2870979.html

After applying the patch, The issue is fixed. So the patch is a effective 
bugfix.
It should go into stable.

Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobri...@gmail.com
Signed-off-by: Alexey Dobriyan 
Acked-by: Christoph Lameter 
Cc: Pekka Enberg 
Cc: David Rientjes 
Cc: Joonsoo Kim 
Cc:  # 4.4.x
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: zhong jiang 
---
 include/linux/slub_def.h | 3 ++-
 mm/slub.c| 6 +++---
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
index 3388511..9b681f2 100644
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@ -67,7 +67,8 @@ struct kmem_cache {
int size;   /* The size of an object including meta data */
int object_size;/* The size of an object without meta data */
int offset; /* Free pointer offset. */
-   int cpu_partial;/* Number of per cpu partial objects to keep 
around */
+   /* Number of per cpu partial objects to keep around */
+   unsigned int cpu_partial;
struct kmem_cache_order_objects oo;
 
/* Allocation and freeing of slabs */
diff --git a/mm/slub.c b/mm/slub.c
index 2284c43..c33b0e1 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1661,7 +1661,7 @@ static void *get_partial_node(struct kmem_cache *s, 
struct kmem_cache_node *n,
 {
struct page *page, *page2;
void *object = NULL;
-   int available = 0;
+   unsigned int available = 0;
int objects;
 
/*
@@ -4674,10 +4674,10 @@ static ssize_t cpu_partial_show(struct kmem_cache *s, 
char *buf)
 static ssize_t cpu_partial_store(struct kmem_cache *s, const char *buf,
 size_t length)
 {
-   unsigned long objects;
+   unsigned int objects;
int err;
 
-   err = kstrtoul(buf, 10, &objects);
+   err = kstrtouint(buf, 10, &objects);
if (err)
return err;
if (objects && !kmem_cache_has_cpu_partial(s))
-- 
1.7.12.4

Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing of undefined bitmask for rxdata

On Sun, 30 Sep 2018 12:37:38 +0200
Esben Haabendal  wrote:

> Boris Brezillon  writes:
> 
> > On Sun, 30 Sep 2018 10:10:14 +
> > Chuanhua Han  wrote:
> >  
> >> > -Original Message-
> >> > From: Boris Brezillon 
> >> > Sent: 2018年9月30日 18:07
> >> > To: Chuanhua Han 
> >> > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> >> > linux-kernel@vger.kernel.org; e...@deif.com
> >> > Subject: Re: [PATCH v2 2/4] spi: spi-fsl-dspi: Fix delete the processing 
> >> > of
> >> > undefined bitmask for rxdata
> >> > 
> >> > On Sun, 30 Sep 2018 17:25:33 +0800
> >> > Chuanhua Han  wrote:
> >> > 
> >> > > This patch fixes the problem of rxdata being equal to 0 during the
> >> > > XSPI mode transfer of the dspi controller.
> >> > > In XSPI mode, If it is not deleted, the value of rxdata will be equal
> >> > > to 0, and the data received will not be received correctly, causing
> >> > > the receiving transfer of the spi to fail.
> >> > >
> >> > > Signed-off-by: Chuanhua Han 
> >> > > ---
> >> > > Changes in v2:
> >> > >  -The original patch is divided into multiple patches(the original
> >> > > patch theme is "spi: spi-fsl-dspi: Fix support for XSPI transport
> >> > > mode"),one of which is segmented.
> >> > >
> >> > >  drivers/spi/spi-fsl-dspi.c | 3 ---
> >> > >  1 file changed, 3 deletions(-)
> >> > >
> >> > > diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
> >> > > index 3082e72e4f6c..4dc1064bf408 100644
> >> > > --- a/drivers/spi/spi-fsl-dspi.c
> >> > > +++ b/drivers/spi/spi-fsl-dspi.c
> >> > > @@ -243,9 +243,6 @@ static void dspi_push_rx(struct fsl_dspi *dspi, 
> >> > > u32
> >> > rxdata)
> >> > >if (!dspi->rx)
> >> > >return;
> >> > >
> >> > > -  /* Mask of undefined bits */
> >> > > -  rxdata &= (1 << dspi->bits_per_word) - 1;
> >> > > -
> >> > 
> >> > Why not
> >> In xspi mode, the value of rxdata after the statement is processed is equal
> >> to 0 no matter what data is received.  
> >
> > Only if dspi->bits_per_word is 0.
> >
> > Actually, I just had a look, and xfer->bits_per_word should never be 0
> > because spi_validate() makes sure it's initialized [1]. Don't know
> > where dpsi->bits_per_word comes from, but maybe you have a problem
> > there (dpsi->bits_per_word and xfer->bits_per_word not in sync).
> >
> > [1]https://elixir.bootlin.com/linux/v4.19-rc5/source/drivers/spi/spi.c#L2869
> >   
> 
> dspi->bits_per_word = xfer->bits_per_word
> 
> https://elixir.bootlin.com/linux/v4.19-rc5/source/drivers/spi/spi-fsl-dspi.c#L697
> 
> So it should never be out of sync, and it should never be 0.
> 
> As I mentioned in another mail, I suspect what Han is observing is
> caused by byte ordering, so that the mask masks the wrong data.
> Maybe related to the byte-ordering fix patch.

Okay. Wait and see then.

RE: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function



> -Original Message-
> From: Boris Brezillon 
> Sent: 2018年9月30日 18:40
> To: Chuanhua Han 
> Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; e...@deif.com
> Subject: Re: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw function
> 
> On Sun, 30 Sep 2018 10:18:18 +
> Chuanhua Han  wrote:
> 
> > > -Original Message-
> > > From: Boris Brezillon 
> > > Sent: 2018年9月30日 18:04
> > > To: Chuanhua Han 
> > > Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; e...@deif.com
> > > Subject: Re: [PATCH v2 1/4] spi: spi-mem: Add the spi_set_xfer_bpw
> > > function
> > >
> > > Hi Chuanhua,
> > >
> > > On Sun, 30 Sep 2018 17:25:32 +0800
> > > Chuanhua Han  wrote:
> > >
> > > > Before we add this spi_transfer to the spi_message chain table, we
> > > > need bits_per_word_mask based on spi_control to set the
> > > > bits_per_word of this spi_transfer.
> > >
> > > Let's make it clearer: this is wrong. The spi-mem protocol is just
> > > using bytes, not custom size words. Fix the fsl-dspi driver if
> > > needed, but don't try to adjust
> > > xfer->bits_per_word in spi-mem.c, because this is inappropriate.
> > The value of bits_per_word is only known before the
> > spi_message_add_tail function is called,
> 
> No, it's not. It's known from the beginning, and spi_setup() defaults to 8 
> when
> spidev->bits_per_word is 0, which is exactly what we want. Then, when you
> send a message through, spi_sync(), spi_validate() makes sure that each
> transfer in the message has a
> xfer->bits_per_word != 0 and when that's not the case, it sets it to
> spi->bits_per_word [2].
> 
> Really, there's nothing to fix in spi-mem.c, because it's already doing the 
> right
> thing (leaving ->bits_per_word to 0 so that it's set to
> spi->bits_per_word, which should be 8). Maybe we have a bug somewhere
> else though.
> 
> [1]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feli
> xir.bootlin.com%2Flinux%2Fv4.19-rc5%2Fsource%2Fdrivers%2Fspi%2Fspi.c%23
> L2803&data=02%7C01%7Cchuanhua.han%40nxp.com%7C48694d5d7cd
> a460b3e0b08d626c11e3f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C636739008212287814&sdata=5wYyFaZjk9kkbZtR0w0uS2YFlfNjC
> Gz3SN80Ws599j0%3D&reserved=0
> [2]https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Feli
> xir.bootlin.com%2Flinux%2Fv4.19-rc5%2Fsource%2Fdrivers%2Fspi%2Fspi.c%23
> L2869&data=02%7C01%7Cchuanhua.han%40nxp.com%7C48694d5d7cd
> a460b3e0b08d626c11e3f%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7
> C0%7C636739008212287814&sdata=ibwl%2BZuk%2FMLagsudNetwgda
> hR1VVKBqI2ByL6225H50%3D&reserved=0
I'll take the time to study this.
October 1 to October 7 is the National Day of our country. I need to take a 
vacation.
I may not reply to the email in time during this period. 
Thank you very much for your valuable advice!!!

Re: [PATCH V6 20/33] csky/dma: fix up dma_mapping error

On Sat, Sep 29, 2018 at 11:08:41PM +0800, Guo Ren wrote:
> On Fri, Sep 28, 2018 at 09:21:16AM -0700, Christoph Hellwig wrote:
> > On Fri, Sep 28, 2018 at 08:51:17AM +0800, Guo Ren wrote:
> > > The arch_sync_dma_for_cpu()/arch_sync_dma_for_device() implementation is
> > > broken for some combinations that end up in a BUG() instead of performing
> > > the necessary flushes.
> > 
> > This should be folded into the original patch adding this code.
> Ok, I'll rebase it.
Sorry, my git-tree has been included in linux-next. I really don't want to 
rebase
it.

Re: [PATCH] [v3] HID: add support for Apple Magic Trackpad 2

2018-09-30 Thread Henrik Rydberg


Hi Sean,


Gentle reminder, thank you!

On Thu, Sep 20, 2018 at 4:13 PM Sean O'Brien  wrote:

USB device
 Vendor 05ac (Apple)
 Device 0265 (Magic Trackpad 2)
Bluetooth device
 Vendor 004c (Apple)
 Device 0265 (Magic Trackpad 2)

Add support for Apple Magic Trackpad 2 over USB and bluetooth, putting
the device in multi-touch mode.

Signed-off-by: Claudio Mettler 
Signed-off-by: Marek Wyborski 
Signed-off-by: Sean O'Brien 
---

  drivers/hid/hid-ids.h|   1 +
  drivers/hid/hid-magicmouse.c | 149 +++
  2 files changed, 134 insertions(+), 16 deletions(-)


This version looks good.

Reviewed-by: Henrik Rydberg 

Thank you!

Henrik

Re: Bad MAINTAINERS pattern in section 'PARALLEL LCD/KEYPAD PANEL DRIVER'

2018-09-30 Thread Miguel Ojeda

Hi Joe,

On Sat, Sep 29, 2018 at 12:03 AM Joe Perches  wrote:
>
> Please fix this defect appropriately.

Thanks, will send a PR.

Cheers,
Miguel

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

2018-09-30 Thread Luke Kenneth Casson Leighton

https://linux.slashdot.org/story/18/09/27/1529236/linus-torvalds-on-linuxs-code-of-conduct#comments

linus: ah... um... okay so this is beginning to remind me of dr who
films, the comedy film "the world's end", and various other b-movie
horror shows where people were taken over through mind-control or
replaced.

so i apologise, i'm going to stop pussy-footing around and ask HAVE
YOU FUCKING LOST IT, GET YOUR HEAD OUT YOUR ARSE, STOP FEELING SORRY
FOR YOURSELF AND GET BACK TO BEING AN ENGINEER, YOU ARE ON A
CHEAGEUUH YOU SORRY LITTLE PROGRAMMER

*cough*. enough NLP-esque shock tactics with a bit of comedy thrown
in to take the sting out of it... allow me to return to rational
insights.

(1) you apologised for your behaviour, and it's fantastic that you
recognised that there was a problem and asked for help. however, you
*may* be feeling a little guilty, and it's clearly knocked your
confidence, and that unfortunately has allowed political correctness
to "creep in" where we know it never, ever belongs: in engineering.

the next thing you know, the fucking guilt-ridden morons who want the
words "master" and "slave" erased from the history books will be
telling you that we have to change SPI's "MOSI" and "MISO" to...
god... i dunno... "ROWI and RIWO" - "requestor" and "worker" or
something incredibly stupid:

Requestor: "i'm awfully sorry, if you wouldn't mind, if it's not too
much trouble mr worker, when you have the time and you're not on your
union-mandated break, could you deal with this bit-change for me?"

(2) more and more people are raising the fact that the change was made
without consultation. this *is* going to bite everyone. i strongly,
strongly suggest reverting it: i made the point very clear that it
wasn't the actual CoC that was the problem, it was that you, yourself,
were not really obeying it (so nobody else could, either).

(3) let's look at what toxic documents named "codes of conduct" look
like from an engineering perspective:

#define BEHAVIOUR_GOOD() ((~BEHAVIOUR_BAD) == 0)
#define BEHAVIOUR_BAD BEHAVIOUR_SEXIST | BEHAVIOUR_RACIST |
BEHAVIOUR_NAZI |
BEHAVIOUR_UNPLEASANT |
BEHAVIOUR_RELIGIOUS_EXTREMIST
#define BEHAVIOUR_RELIGIOUS_EXTREMIST \
BEHAVIOUR_ANTI_CHRISTIAN \
BEHAVIOUR_ANTI_MUSLIM \
...

#define BEHAVIOUR_ANTI_MUSLIM 0x1
#define BEHAVIOUR_ANTI_CHRISTIAN 0x2
...
...
...
// oops fuck we're gonna run out of bits extremely quickly

do you see where that's going? do you get the point already? if an
engineer proposed the above patch to create the toxic CoC document
that insidiously crept in recently, you and pretty much everyone would
think that the submitter had a fucking screw loose and needed
psychiatric help.

these toxic documents do not have to spell it out, but they *imply*
that there are (deep breath...) spics, wocs, niggers, honky white
bastards, chinks kooks and their mothers too all trying to ATTACK the
project, and we'd better make sure that they're all excluded,
otherwise we're all in trouble, eh?

i apologise for using these words: if you are a decent human being you
should by now feeling physically sick to your stomach at having read
that paragraph, that those words were even used... yet they're not
actually *in* that toxic document, but they don't have to be: people
are still thinking them. like the "don't think of a pink elephant"
our subconscious mind cannot help by strip out the "don't".

bottom line: the *entire linux kernel project* has now been
*completely poisoned* by that document.

put another way: an engineer would go, "wtf??" and would say "we don't
need to fill every single bit in the bitfield and then invert it for
god's sake! just say "good behaviour is expected" and be done with
it!!"

so why not say, instead of that absolute god-awful list, "everyone is
welcome; everyone belongs". you see the difference? you see how
simple and empowering that is? it's INVITING people to participate,
and it's pretty obvious that if someone feels *UN*welcome, the rules
have been broken and they can raise it as an issue. rather than
absolutely terrifying and sickening absolutely everybody.

the analogy is the story of mother theresa being invited to an
"anti-war" rally. she declined... and said, "if ever you hold a PEACE
rally, i'd be delighted to attend".

so come on, linus: wake up, man. just because this is outside of your
area of expertise does not mean that you have to let go of the reins.
*get a grip*. use your engineering expertise, apply it to the
problem, work with *EVERYONE* and work out an *ACCEPTABLE* solution.

warmest,

Re: Re: Linux 4.19-rc4 released, an apology, and a maintainership note

2018-09-30 Thread lkcl

> That written: Quite some of the rude mails that contained swearwords I 
> read from you have been about code, not persons. I think this is an 
> important distinction. I do not have much of an issue with swearing at 
> code :), especially when it is in some humorous way.

 absolutely, and this is one thing that a lot of people are, sadly,
 trained pretty much from birth to be incapable of understanding:
 namely the difference between criticism of the PERSON and criticism
 of the ACTION.

 (1) "YOU are bad! GO STAND IN THE NAUGHTY CORNER!"
 (2) "That was a BAD thing to do!"
 (3) "That hurt my feelings that you did that"

 the first is the way that poorly-trained parents and kindergarten
 teachers talk to children.

 the second is... only marginally better, but it's a start

 the third is how UNICEF trains teachers to treat children as human beings.

> Code quality indeed is important.
> As are human interactions.

 absolutely.  it's not about the code, it's always, *always* about people.
 we just happen to be writing code, but ultimately we are doing so in the
 service of other PEOPLE.

 l.

[GIT PULL] auxdisplay for v4.19-rc6

2018-09-30 Thread Miguel Ojeda

Hi Greg,

Please pull this trivial fix in MAINTAINERS for auxdisplay.

Cheers,
Miguel

The following changes since commit 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84:

  Linux 4.19-rc5 (2018-09-23 19:15:18 +0200)

are available in the Git repository at:

  https://github.com/ojeda/linux.git tags/auxdisplay-for-greg-v4.19-rc6

for you to fetch changes up to 03d179a840ce9e694db9d69bb643fdee04cfd28f:

  MAINTAINERS: fix reference to moved drivers/{misc => auxdisplay}/panel.c 
(2018-09-30 13:50:05 +0200)


A trivial fix for auxdisplay

  - MAINTAINERS reference fix for moved file
Reported by Joe Perches


Miguel Ojeda (1):
  MAINTAINERS: fix reference to moved drivers/{misc => auxdisplay}/panel.c

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH] ARM: SAMSUNG: limit SAMSUNG_PM_DEBUG config option to non-Exynos platforms

2018-09-30 Thread Krzysztof Kozlowski

On Fri, Sep 28, 2018 at 06:34:55PM +0200, Bartlomiej Zolnierkiewicz wrote:
> 
> 
> On 09/28/2018 03:54 PM, Krzysztof Kozlowski wrote:
> > On Fri, 28 Sep 2018 at 15:37, Bartlomiej Zolnierkiewicz
> >  wrote:
> >>
> >> "Samsung PM Suspend debug" feature (controlled by SAMSUNG_PM_DEBUG
> >> config option) is not working properly (debug messages are not
> >> displayed after resume) on Exynos platforms because GPIOs restore
> >> code is not implemented.
> > 
> > AFAIR, it worked properly for the suspend part showing more logs.
> > Unless it changed, the feature looks still useful.
> 
> Yes, it shows few additional messages from mach/plat specific suspend
> code but it breaks the assumption that features (even debug ones)
> work correctly and make you invest time in debugging known broken
> code.

OK, let's remove it. However in such case this change leaves useless
S3C_PMDBG and other s3c_pm_* in Exynos code. They should go away along
with SAMSUNG_PM_DEBUG.

Best regards,
Krzysztof

> 
> In case it is needed/useful (which should be rather rare situation)
> one can always easily revert the commit locally.
> 
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics

Re: [STABLE PATCH] slub: make ->cpu_partial unsigned int

On Sun, Sep 30, 2018 at 06:28:21PM +0800, zhong jiang wrote:
> From: Alexey Dobriyan 
> 
> [ Upstream commit e5d9998f3e09359b372a037a6ac55ba235d95d57 ]
> 
> /*
>  * cpu_partial determined the maximum number of objects
>  * kept in the per cpu partial lists of a processor.
>  */
> 
> Can't be negative.
> 
> I hit a real issue that it will result in a large number of memory leak.
> Becuase Freeing slabs are in interrupt context. So it can trigger this issue.
> put_cpu_partial can be interrupted more than once.
> due to a union struct of lru and pobjects in struct page, when other core 
> handles
> page->lru list, for eaxmple, remove_partial in freeing slab code flow, It will
> result in pobjects being a negative value(0xdead). Therefore, a large 
> number
> of slabs will be added to per_cpu partial list.
> 
> I had posted the issue to community before. The detailed issue description is 
> as follows.
> 
> https://www.spinics.net/lists/kernel/msg2870979.html
> 
> After applying the patch, The issue is fixed. So the patch is a effective 
> bugfix.
> It should go into stable.
> 
> Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobri...@gmail.com
> Signed-off-by: Alexey Dobriyan 
> Acked-by: Christoph Lameter 
> Cc: Pekka Enberg 
> Cc: David Rientjes 
> Cc: Joonsoo Kim 
> Cc:  # 4.4.x

This didn't apply to 4.14.y and any reason you didn't cc: the stable
mailing list for the other stable developers to see it?

I've fixed up the patch, but next time please always cc: the stable
list.

thanks,

greg k-h

Re: [STABLE PATCH] slub: make ->cpu_partial unsigned int

2018-09-30 Thread Matthew Wilcox

On Sun, Sep 30, 2018 at 06:28:21PM +0800, zhong jiang wrote:
> From: Alexey Dobriyan 
> 
> [ Upstream commit e5d9998f3e09359b372a037a6ac55ba235d95d57 ]
> 
> /*
>  * cpu_partial determined the maximum number of objects
>  * kept in the per cpu partial lists of a processor.
>  */
> 
> Can't be negative.
> 
> I hit a real issue that it will result in a large number of memory leak.
> Becuase Freeing slabs are in interrupt context. So it can trigger this issue.
> put_cpu_partial can be interrupted more than once.
> due to a union struct of lru and pobjects in struct page, when other core 
> handles
> page->lru list, for eaxmple, remove_partial in freeing slab code flow, It will
> result in pobjects being a negative value(0xdead). Therefore, a large 
> number
> of slabs will be added to per_cpu partial list.
> 
> I had posted the issue to community before. The detailed issue description is 
> as follows.
> 
> https://www.spinics.net/lists/kernel/msg2870979.html
> 
> After applying the patch, The issue is fixed. So the patch is a effective 
> bugfix.
> It should go into stable.
> 
> Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobri...@gmail.com
> Signed-off-by: Alexey Dobriyan 
> Acked-by: Christoph Lameter 

Hang on.  Christoph acked the _original_ patch going into upstream.
When he reviewed this patch for _stable_ last week, he asked for more
investigation.  Including this patch in stable is misleading.

> Cc: Pekka Enberg 
> Cc: David Rientjes 
> Cc: Joonsoo Kim 
> Cc:  # 4.4.x
> Signed-off-by: Andrew Morton 
> Signed-off-by: Linus Torvalds 
> Signed-off-by: zhong jiang 
> ---
>  include/linux/slub_def.h | 3 ++-
>  mm/slub.c| 6 +++---
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/slub_def.h b/include/linux/slub_def.h
> index 3388511..9b681f2 100644
> --- a/include/linux/slub_def.h
> +++ b/include/linux/slub_def.h
> @@ -67,7 +67,8 @@ struct kmem_cache {
>   int size;   /* The size of an object including meta data */
>   int object_size;/* The size of an object without meta data */
>   int offset; /* Free pointer offset. */
> - int cpu_partial;/* Number of per cpu partial objects to keep 
> around */
> + /* Number of per cpu partial objects to keep around */
> + unsigned int cpu_partial;
>   struct kmem_cache_order_objects oo;
>  
>   /* Allocation and freeing of slabs */
> diff --git a/mm/slub.c b/mm/slub.c
> index 2284c43..c33b0e1 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -1661,7 +1661,7 @@ static void *get_partial_node(struct kmem_cache *s, 
> struct kmem_cache_node *n,
>  {
>   struct page *page, *page2;
>   void *object = NULL;
> - int available = 0;
> + unsigned int available = 0;
>   int objects;
>  
>   /*
> @@ -4674,10 +4674,10 @@ static ssize_t cpu_partial_show(struct kmem_cache *s, 
> char *buf)
>  static ssize_t cpu_partial_store(struct kmem_cache *s, const char *buf,
>size_t length)
>  {
> - unsigned long objects;
> + unsigned int objects;
>   int err;
>  
> - err = kstrtoul(buf, 10, &objects);
> + err = kstrtouint(buf, 10, &objects);
>   if (err)
>   return err;
>   if (objects && !kmem_cache_has_cpu_partial(s))
> -- 
> 1.7.12.4
>

Re: [STABLE PATCH] slub: make ->cpu_partial unsigned int

On Sun, Sep 30, 2018 at 05:50:38AM -0700, Matthew Wilcox wrote:
> On Sun, Sep 30, 2018 at 06:28:21PM +0800, zhong jiang wrote:
> > From: Alexey Dobriyan 
> > 
> > [ Upstream commit e5d9998f3e09359b372a037a6ac55ba235d95d57 ]
> > 
> > /*
> >  * cpu_partial determined the maximum number of objects
> >  * kept in the per cpu partial lists of a processor.
> >  */
> > 
> > Can't be negative.
> > 
> > I hit a real issue that it will result in a large number of memory leak.
> > Becuase Freeing slabs are in interrupt context. So it can trigger this 
> > issue.
> > put_cpu_partial can be interrupted more than once.
> > due to a union struct of lru and pobjects in struct page, when other core 
> > handles
> > page->lru list, for eaxmple, remove_partial in freeing slab code flow, It 
> > will
> > result in pobjects being a negative value(0xdead). Therefore, a large 
> > number
> > of slabs will be added to per_cpu partial list.
> > 
> > I had posted the issue to community before. The detailed issue description 
> > is as follows.
> > 
> > https://www.spinics.net/lists/kernel/msg2870979.html
> > 
> > After applying the patch, The issue is fixed. So the patch is a effective 
> > bugfix.
> > It should go into stable.
> > 
> > Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobri...@gmail.com
> > Signed-off-by: Alexey Dobriyan 
> > Acked-by: Christoph Lameter 
> 
> Hang on.  Christoph acked the _original_ patch going into upstream.
> When he reviewed this patch for _stable_ last week, he asked for more
> investigation.  Including this patch in stable is misleading.

But the original patch has been in upstream for a long time now (it went
into 4.17-rc1).  If there was a real problem here, whouldn't it have
been resolved already?

And the patch in mainline has Christoph's ack...

thanks,

greg k-h

Re: [PATCH v2] x86/earlyprintk: Add a force option for pciserial device

2018-09-30 Thread Feng Tang

Hi Borislav,

On Sat, Sep 29, 2018 at 06:34:58PM +0200, Borislav Petkov wrote:
> On Fri, Sep 28, 2018 at 05:40:08PM +0800, Feng Tang wrote:
> > "pciserial" earlyprintk helps much on many modern x86 platforms,
> > but unfortunately there are still some platforms whose PCI UART
> > devices have wrong PCI class code, which will be blocked by current
> > class code check.
> > 
> > Add a option "force" so that developer could still use a UART device
> > even it has wrong class code, with format "",B:D.F,force,baud". And
> 
> This new parameter and its meaning needs to be documented where
> pciserial is documented.

Ok, will change the kernel-parameters.txt in next version.

> 
> > the original format ",B:D.F,baud" is kept unchanged.
> > 
> > Suggested-by: Borislav Petkov 
> > Signed-off-by: Feng Tang 
> > ---
> >  arch/x86/kernel/early_printk.c | 26 --
> >  1 file changed, 20 insertions(+), 6 deletions(-)
> > 
> > diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
> > index 5e801c8..35d0f66 100644
> > --- a/arch/x86/kernel/early_printk.c
> > +++ b/arch/x86/kernel/early_printk.c
> > @@ -213,8 +213,10 @@ static unsigned int mem32_serial_in(unsigned long 
> > addr, int offset)
> >   * early_pci_serial_init()
> >   *
> >   * This function is invoked when the early_printk param starts with 
> > "pciserial"
> > - * The rest of the param should be ",B:D.F,baud" where B, D & F describe 
> > the
> > - * location of a PCI device that must be a UART device.
> > + * The rest of the param should be ",B:D.F,baud" or ",B:D.F,force,baud", 
> > where
> > + * B, D & F describe the location of a PCI device that must be a UART 
> > device,
> > + * "force" is optional and means insisting using a UART device with a wrong
> > + * pci class code.
> >   */
> >  static __init void early_pci_serial_init(char *s)
> >  {
> > @@ -224,6 +226,7 @@ static __init void early_pci_serial_init(char *s)
> > u32 classcode, bar0;
> > u16 cmdreg;
> > char *e;
> > +   int force = 0;
> >  
> >  
> > /*
> > @@ -252,6 +255,15 @@ static __init void early_pci_serial_init(char *s)
> > if (*s == ',')
> > s++;
> >  
> > +   /* User may insist to use a UART device with wrong class code */
> > +   if (!strncmp(s, "force", 5)) {
> > +   force = 1;
> > +   s += 5;
> > +
> > +   if (*s == ',')
> > +   s++;
> 
> No, you need to force the presence of "," otherwise cmdlines like this:
> 
> earlyprintk=pciserial,0:XX.X,forcedoodoo
> 
> work too.

Got your point. As the following [,baudrate] is also optional, and this
"force" could be the last option for pciserial. The check may be

if (!strncmp(s, "force,", 6) || !strncmp(s, "force ", 6)) {
force = 1;
s += 6;
}


> > +   }
> > +
> > /*
> >  * Second, find the device from the BDF
> >  */
> > @@ -262,10 +274,12 @@ static __init void early_pci_serial_init(char *s)
> > /*
> >  * Verify it is a UART type device
> >  */
> > -   if (((classcode >> 16 != PCI_CLASS_COMMUNICATION_MODEM) &&
> > -(classcode >> 16 != PCI_CLASS_COMMUNICATION_SERIAL)) ||
> > -  (((classcode >> 8) & 0xff) != 0x02)) /* 16550 I/F at BAR0 */
> > -   return;
> > +   if (!force) {
> > +   if (((classcode >> 16 != PCI_CLASS_COMMUNICATION_MODEM) &&
> > +(classcode >> 16 != PCI_CLASS_COMMUNICATION_SERIAL)) ||
> > +  (((classcode >> 8) & 0xff) != 0x02)) /* 16550 I/F at BAR0 */
> > +   return;
> 
> Move the force check in here ^

Do you mean this? 

if (((classcode >> 16 != PCI_CLASS_COMMUNICATION_MODEM) &&
 (classcode >> 16 != PCI_CLASS_COMMUNICATION_SERIAL)) ||
   (((classcode >> 8) & 0xff) != 0x02)) /* 16550 I/F at BAR0 */ {
if (!force)
return;
}

Thanks,
Feng

Re: [STABLE PATCH] slub: make ->cpu_partial unsigned int

2018-09-30 Thread Matthew Wilcox

On Sun, Sep 30, 2018 at 06:10:26AM -0700, Greg KH wrote:
> On Sun, Sep 30, 2018 at 05:50:38AM -0700, Matthew Wilcox wrote:
> > On Sun, Sep 30, 2018 at 06:28:21PM +0800, zhong jiang wrote:
> > > From: Alexey Dobriyan 
> > > 
> > > [ Upstream commit e5d9998f3e09359b372a037a6ac55ba235d95d57 ]
> > > 
> > > /*
> > >  * cpu_partial determined the maximum number of objects
> > >  * kept in the per cpu partial lists of a processor.
> > >  */
> > > 
> > > Can't be negative.
> > > 
> > > I hit a real issue that it will result in a large number of memory leak.
> > > Becuase Freeing slabs are in interrupt context. So it can trigger this 
> > > issue.
> > > put_cpu_partial can be interrupted more than once.
> > > due to a union struct of lru and pobjects in struct page, when other core 
> > > handles
> > > page->lru list, for eaxmple, remove_partial in freeing slab code flow, It 
> > > will
> > > result in pobjects being a negative value(0xdead). Therefore, a large 
> > > number
> > > of slabs will be added to per_cpu partial list.
> > > 
> > > I had posted the issue to community before. The detailed issue 
> > > description is as follows.
> > > 
> > > https://www.spinics.net/lists/kernel/msg2870979.html
> > > 
> > > After applying the patch, The issue is fixed. So the patch is a effective 
> > > bugfix.
> > > It should go into stable.
> > > 
> > > Link: http://lkml.kernel.org/r/20180305200730.15812-15-adobri...@gmail.com
> > > Signed-off-by: Alexey Dobriyan 
> > > Acked-by: Christoph Lameter 
> > 
> > Hang on.  Christoph acked the _original_ patch going into upstream.
> > When he reviewed this patch for _stable_ last week, he asked for more
> > investigation.  Including this patch in stable is misleading.
> 
> But the original patch has been in upstream for a long time now (it went
> into 4.17-rc1).  If there was a real problem here, whouldn't it have
> been resolved already?
> 
> And the patch in mainline has Christoph's ack...

I'm not saying there's a problem with the patch.  It's that the rationale
for backporting doesn't make any damned sense.  There's something going
on that nobody understands.  This patch is probably masking an underlying
problem that will pop back up and bite us again someday.

Re: [GIT PULL] auxdisplay for v4.19-rc6

2018-09-30 Thread Greg Kroah-Hartman

On Sun, Sep 30, 2018 at 02:15:55PM +0200, Miguel Ojeda wrote:
> Hi Greg,
> 
> Please pull this trivial fix in MAINTAINERS for auxdisplay.
> 
> Cheers,
> Miguel
> 
> The following changes since commit 6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84:
> 
>   Linux 4.19-rc5 (2018-09-23 19:15:18 +0200)
> 
> are available in the Git repository at:
> 
>   https://github.com/ojeda/linux.git tags/auxdisplay-for-greg-v4.19-rc6

Now pulled, thanks.

greg k-h

[no subject]

2018-09-30 Thread Sheng Li Hung





I am Mr.Sheng Li Hung, from china I got your information while search for
a reliable person, I have a very profitable business proposition for you
and i can assure you that you will not regret been part of this mutual
beneficial transaction after completion. Kindly get back to me for more
details on this email id: shengl...@outlook.com

Thanks
Mr Sheng Li Hung

Re: Bad MAINTAINERS pattern in section 'PARALLEL LCD/KEYPAD PANEL DRIVER'

2018-09-30 Thread Miguel Ojeda

On Sun, Sep 30, 2018 at 1:44 PM Miguel Ojeda
 wrote:
>
> On Sat, Sep 29, 2018 at 12:03 AM Joe Perches  wrote:
> >
> > Please fix this defect appropriately.
>
> Thanks, will send a PR.
>

Done & merged by Greg.

Cheers,
Miguel

Re: [PATCH] kbuild: remove unneeded link_multi_deps

2018-09-30 Thread Masahiro Yamada

2018年9月13日(木) 17:22 Masahiro Yamada :
>
> Since commit c8589d1e9e01 ("kbuild: handle multi-objs dependency
> appropriately"), $^ really represents all the prerequisite of the
> composite object being built.
>
> Hence, $(filter-out FORCE,$^) contains all the objects to link
> together, which is much simpler than link_multi_deps calculation.
>
> Signed-off-by: Masahiro Yamada 
> ---

Applied to linux-kbuild.


>  scripts/Makefile.build | 20 ++--
>  1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> index cb03774..d7fa203 100644
> --- a/scripts/Makefile.build
> +++ b/scripts/Makefile.build
> @@ -485,28 +485,12 @@ targets += $(obj)/lib-ksyms.o
>
>  endif
>
> -#
> -# Rule to link composite objects
> -#
> -#  Composite objects are specified in kbuild makefile as follows:
> -#-objs := 
> -#  or
> -#-y:= 
> -#  or
> -#-m:= 
> -#  The -m syntax only works if  is a module
> -link_multi_deps = \
> -$(filter $(addprefix $(obj)/, \
> -$($(subst $(obj)/,,$(@:.o=-objs)))\
> -$($(subst $(obj)/,,$(@:.o=-y)))   \
> -$($(subst $(obj)/,,$(@:.o=-m, $^)
> -
>  quiet_cmd_link_multi-m = LD [M]  $@
> -cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(link_multi_deps) 
> $(cmd_secanalysis)
> +cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter-out FORCE,$^) 
> $(cmd_secanalysis)
>
>  $(multi-used-m): FORCE
> $(call if_changed,link_multi-m)
> -   @{ echo $(@:.o=.ko); echo $(link_multi_deps); \
> +   @{ echo $(@:.o=.ko); echo $(filter-out FORCE,$^); \
>$(cmd_undef_syms); } > $(MODVERDIR)/$(@F:.o=.mod)
>  $(call multi_depend, $(multi-used-m), .o, -objs -y -m)
>
> --
> 2.7.4
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2] kbuild: add --include-dir flag only for out-of-tree build

2018-09-30 Thread Masahiro Yamada

2018年9月14日(金) 15:33 Masahiro Yamada :
>
> The --include-dir flag is used to include check-in Makefiles from
> $(objtree) without $(srctree)/ prefix.  Obviously, this is unneeded
> for in-tree build.  Add the flag just before changing the working
> directory.
>
> This becomes effective after invoking sub-make.  Add a little bit
> comments about it.
>
> Signed-off-by: Masahiro Yamada 
> ---


Applied to linux-kbuild.



> Changes in v2:
>   - Add some more comments
>
>  Makefile | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index f8c8e12..233b57d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -15,10 +15,9 @@ NAME = Merciless Moray
>  PHONY := _all
>  _all:
>
> -# o Do not use make's built-in rules and variables
> -#   (this increases performance and avoids hard-to-debug behaviour);
> -# o Look for make include files relative to root of kernel src
> -MAKEFLAGS += -rR --include-dir=$(CURDIR)
> +# Do not use make's built-in rules and variables
> +# (this increases performance and avoids hard-to-debug behaviour)
> +MAKEFLAGS += -rR
>
>  # Avoid funny character set dependencies
>  unexport LC_ALL
> @@ -136,6 +135,13 @@ KBUILD_OUTPUT := $(shell mkdir -p $(KBUILD_OUTPUT) && cd 
> $(KBUILD_OUTPUT) \
>  $(if $(KBUILD_OUTPUT),, \
>   $(error failed to create output directory "$(saved-output)"))
>
> +# Look for make include files relative to root of kernel src
> +#
> +# This does not become effective immediately because MAKEFLAGS is re-parsed
> +# once after the Makefile is read.  It is OK since we are going to invoke
> +# 'sub-make' below.
> +MAKEFLAGS += --include-dir=$(CURDIR)
> +
>  PHONY += $(MAKECMDGOALS) sub-make
>
>  $(filter-out _all sub-make $(CURDIR)/Makefile, $(MAKECMDGOALS)) _all: 
> sub-make
> --
> 2.7.4
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 1/4] kbuild: remove VERSION and PATCHLEVEL from $(objtree)/Makefile

2018-09-30 Thread Masahiro Yamada

2018年9月18日(火) 17:46 Masahiro Yamada :
>
> Neither VERSION nor PATCHLEVEL is used in any useful way.
>
> Signed-off-by: Masahiro Yamada 
> ---

Series, applies to linux-kbuild.


>  Makefile   | 3 +--
>  scripts/mkmakefile | 6 --
>  2 files changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index d2976b5..6e1a059 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -482,8 +482,7 @@ PHONY += outputmakefile
>  outputmakefile:
>  ifneq ($(KBUILD_SRC),)
> $(Q)ln -fsn $(srctree) source
> -   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile \
> -   $(srctree) $(objtree) $(VERSION) $(PATCHLEVEL)
> +   $(Q)$(CONFIG_SHELL) $(srctree)/scripts/mkmakefile $(srctree) 
> $(objtree)
>  endif
>
>  ifeq ($(cc-name),clang)
> diff --git a/scripts/mkmakefile b/scripts/mkmakefile
> index e19d656..e2106444 100755
> --- a/scripts/mkmakefile
> +++ b/scripts/mkmakefile
> @@ -7,9 +7,6 @@
>  # Usage
>  # $1 - Kernel src directory
>  # $2 - Output directory
> -# $3 - version
> -# $4 - patchlevel
> -
>
>  test ! -r $2/Makefile -o -O $2/Makefile || exit 0
>  # Only overwrite automatically generated Makefiles
> @@ -25,9 +22,6 @@ fi
>  cat << EOF > $2/Makefile
>  # Automatically generated by $0: don't edit
>
> -VERSION = $3
> -PATCHLEVEL = $4
> -
>  lastword = \$(word \$(words \$(1)),\$(1))
>  makedir := \$(dir \$(call lastword,\$(MAKEFILE_LIST)))
>
> --
> 2.7.4
>


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 0/3] namei: implement various scoping AT_* flags

2018-09-30 Thread Alban Crequy

On Sat, Sep 29, 2018 at 12:35 PM Aleksa Sarai  wrote:
>
> The need for some sort of control over VFS's path resolution (to avoid
> malicious paths resulting in inadvertent breakouts) has been a very
> long-standing desire of many userspace applications. This patchset is a
> revival of Al Viro's old AT_NO_JUMPS[1] patchset with a few additions.
>
> The most obvious change is that AT_NO_JUMPS has been split as dicussed
> in the original thread, along with a further split of AT_NO_PROCLINKS
> which means that each individual property of AT_NO_JUMPS is now a
> separate flag:
>
>   * Path-based escapes from the starting-point using "/" or ".." are
> blocked by AT_BENEATH.
>   * Mountpoint crossings are blocked by AT_XDEV.
>   * /proc/$pid/fd/$fd resolution is blocked by AT_NO_PROCLINKS (more
> correctly it actually blocks any user of nd_jump_link() because it
> allows out-of-VFS path resolution manipulation).
>
> AT_NO_JUMPS is now effectively (AT_BENEATH|AT_XDEV|AT_NO_PROCLINKS). At
> Linus' suggestion in the original thread, I've also implemented
> AT_NO_SYMLINKS which just denies _all_ symlink resolution (including
> "proclink" resolution).

It seems quite useful to me.

> An additional improvement was made to AT_XDEV. The original AT_NO_JUMPS
> path didn't consider "/tmp/.." as a mountpoint crossing -- this patch
> blocks this as well (feel free to ask me to remove it if you feel this
> is not sane).
>
> Currently I've only enabled these for openat(2) and the stat(2) family.
> I would hope we could enable it for basically every *at(2) syscall --
> but many of them appear to not have a @flags argument and thus we'll
> need to add several new syscalls to do this. I'm more than happy to send
> those patches, but I'd prefer to know that this preliminary work is
> acceptable before doing a bunch of copy-paste to add new sets of *at(2)
> syscalls.

What do you think of an equivalent feature AT_NO_SYMLINKS flag for mount()?

I guess that would have made the fix for CVE-2017-1002101 in
Kubernetes easier to write:
https://kubernetes.io/blog/2018/04/04/fixing-subpath-volume-vulnerability/

> One additional feature I've implemented is AT_THIS_ROOT (I imagine this
> is probably going to be more contentious than the refresh of
> AT_NO_JUMPS, so I've included it in a separate patch). The patch itself
> describes my reasoning, but the shortened version of the premise is that
> continer runtimes need to have a way to resolve paths within a
> potentially malicious rootfs. Container runtimes currently do this in
> userspace[2] which has implicit race conditions that are not resolvable
> in userspace (or use fork+exec+chroot and SCM_RIGHTS passing which is
> inefficient). AT_THIS_ROOT allows for per-call chroot-like semantics for
> path resolution, which would be invaluable for us -- and the
> implementation is basically identical to AT_BENEATH (except that we
> don't return errors when someone actually hits the root).
>
> I've added some selftests for this, but it's not clear to me whether
> they should live here or in xfstests (as far as I can tell there are no
> other VFS tests in selftests, while there are some tests that look like
> generic VFS tests in xfstests). If you'd prefer them to be included in
> xfstests, let me know.
>
> [1]: https://lore.kernel.org/patchwork/patch/784221/
> [2]: https://github.com/cyphar/filepath-securejoin
>
> Aleksa Sarai (3):
>   namei: implement O_BENEATH-style AT_* flags
>   namei: implement AT_THIS_ROOT chroot-like path resolution
>   selftests: vfs: add AT_* path resolution tests
>
>  fs/fcntl.c|   2 +-
>  fs/namei.c| 158 --
>  fs/open.c |  10 ++
>  fs/stat.c |  15 +-
>  include/linux/fcntl.h |   3 +-
>  include/linux/namei.h |   8 +
>  include/uapi/asm-generic/fcntl.h  |  20 +++
>  include/uapi/linux/fcntl.h|  10 ++
>  tools/testing/selftests/Makefile  |   1 +
>  tools/testing/selftests/vfs/.gitignore|   1 +
>  tools/testing/selftests/vfs/Makefile  |  13 ++
>  tools/testing/selftests/vfs/at_flags.h|  40 +
>  tools/testing/selftests/vfs/common.sh |  37 
>  .../selftests/vfs/tests/0001_at_beneath.sh|  72 
>  .../selftests/vfs/tests/0002_at_xdev.sh   |  54 ++
>  .../vfs/tests/0003_at_no_proclinks.sh |  50 ++
>  .../vfs/tests/0004_at_no_symlinks.sh  |  49 ++
>  .../selftests/vfs/tests/0005_at_this_root.sh  |  66 
>  tools/testing/selftests/vfs/vfs_helper.c  | 154 +
>  19 files changed, 707 insertions(+), 56 deletions(-)
>  create mode 100644 tools/testing/selftests/vfs/.gitignore
>  create mode 100644 tools/testing/selftests/vfs/Makefile
>  create mode 100644 tools/testing/selftests/vfs/at_flags.h
>  create mode

Re: [PATCH RT 2/2] watchdog, rt: prevent deferral of watchdogd wakeup


On 09/28/2018 02:03 PM, Julia Cartwright wrote:

When PREEMPT_RT_FULL is enabled, all hrtimer expiry functions are
deferred for execution into the context of ktimersoftd unless otherwise
annotated.

Deferring the expiry of the hrtimer used by the watchdog core, however,
is a waste, as the callback does nothing but queue a kthread work item
and wakeup watchdogd.

It's worst then that, too: the deferral through ktimersoftd also means
that for correct behavior a user must adjust the scheduling parameters
of both watchdogd _and_ ktimersoftd, which is unnecessary and has other
side effects (like causing unrelated expiry functions to execute at
potentially elevated priority).

Instead, mark the hrtimer used by the watchdog core as being _HARD to
allow it's execution directly from hardirq context.  The work done in
this expiry function is well-bounded and minimal.

A user still must adjust the scheduling parameters of the watchdogd
to be correct w.r.t. their application needs.

Cc: Guenter Roeck 
Reported-and-tested-by: Steffen Trumtrar 
Reported-by: Tim Sander 
Signed-off-by: Julia Cartwright 


Acked-by: Guenter Roeck 


---
  drivers/watchdog/watchdog_dev.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ffbdc4642ea5..9c2b3e5cebdc 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -945,7 +945,7 @@ static int watchdog_cdev_register(struct watchdog_device 
*wdd, dev_t devno)
return -ENODEV;
  
  	kthread_init_work(&wd_data->work, watchdog_ping_work);

-   hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+   hrtimer_init(&wd_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
wd_data->timer.function = watchdog_timer_expired;
  
  	if (wdd->id == 0) {

Re: [PATCH 0/3] namei: implement various scoping AT_* flags

2018-09-30 Thread Christian Brauner

On September 30, 2018 3:54:31 PM GMT+02:00, Alban Crequy  
wrote:
>On Sat, Sep 29, 2018 at 12:35 PM Aleksa Sarai 
>wrote:
>>
>> The need for some sort of control over VFS's path resolution (to
>avoid
>> malicious paths resulting in inadvertent breakouts) has been a very
>> long-standing desire of many userspace applications. This patchset is
>a
>> revival of Al Viro's old AT_NO_JUMPS[1] patchset with a few
>additions.
>>
>> The most obvious change is that AT_NO_JUMPS has been split as
>dicussed
>> in the original thread, along with a further split of AT_NO_PROCLINKS
>> which means that each individual property of AT_NO_JUMPS is now a
>> separate flag:
>>
>>   * Path-based escapes from the starting-point using "/" or ".." are
>> blocked by AT_BENEATH.
>>   * Mountpoint crossings are blocked by AT_XDEV.
>>   * /proc/$pid/fd/$fd resolution is blocked by AT_NO_PROCLINKS (more
>> correctly it actually blocks any user of nd_jump_link()
>because it
>> allows out-of-VFS path resolution manipulation).
>>
>> AT_NO_JUMPS is now effectively (AT_BENEATH|AT_XDEV|AT_NO_PROCLINKS).
>At
>> Linus' suggestion in the original thread, I've also implemented
>> AT_NO_SYMLINKS which just denies _all_ symlink resolution (including
>> "proclink" resolution).
>
>It seems quite useful to me.
>
>> An additional improvement was made to AT_XDEV. The original
>AT_NO_JUMPS
>> path didn't consider "/tmp/.." as a mountpoint crossing -- this patch
>> blocks this as well (feel free to ask me to remove it if you feel
>this
>> is not sane).
>>
>> Currently I've only enabled these for openat(2) and the stat(2)
>family.
>> I would hope we could enable it for basically every *at(2) syscall --
>> but many of them appear to not have a @flags argument and thus we'll
>> need to add several new syscalls to do this. I'm more than happy to
>send
>> those patches, but I'd prefer to know that this preliminary work is
>> acceptable before doing a bunch of copy-paste to add new sets of
>*at(2)
>> syscalls.
>
>What do you think of an equivalent feature AT_NO_SYMLINKS flag for
>mount()?

That's something we discussed  but that would need to be part of the new mount 
API work by David. The current mount API doesn't take AT_* flags since it 
doesn't operate on fds and we're (sort of) out of mount flags.

>
>I guess that would have made the fix for CVE-2017-1002101 in
>Kubernetes easier to write:
>https://kubernetes.io/blog/2018/04/04/fixing-subpath-volume-vulnerability/
>
>> One additional feature I've implemented is AT_THIS_ROOT (I imagine
>this
>> is probably going to be more contentious than the refresh of
>> AT_NO_JUMPS, so I've included it in a separate patch). The patch
>itself
>> describes my reasoning, but the shortened version of the premise is
>that
>> continer runtimes need to have a way to resolve paths within a
>> potentially malicious rootfs. Container runtimes currently do this in
>> userspace[2] which has implicit race conditions that are not
>resolvable
>> in userspace (or use fork+exec+chroot and SCM_RIGHTS passing which is
>> inefficient). AT_THIS_ROOT allows for per-call chroot-like semantics
>for
>> path resolution, which would be invaluable for us -- and the
>> implementation is basically identical to AT_BENEATH (except that we
>> don't return errors when someone actually hits the root).
>>
>> I've added some selftests for this, but it's not clear to me whether
>> they should live here or in xfstests (as far as I can tell there are
>no
>> other VFS tests in selftests, while there are some tests that look
>like
>> generic VFS tests in xfstests). If you'd prefer them to be included
>in
>> xfstests, let me know.
>>
>> [1]: https://lore.kernel.org/patchwork/patch/784221/
>> [2]: https://github.com/cyphar/filepath-securejoin
>>
>> Aleksa Sarai (3):
>>   namei: implement O_BENEATH-style AT_* flags
>>   namei: implement AT_THIS_ROOT chroot-like path resolution
>>   selftests: vfs: add AT_* path resolution tests
>>
>>  fs/fcntl.c|   2 +-
>>  fs/namei.c| 158
>--
>>  fs/open.c |  10 ++
>>  fs/stat.c |  15 +-
>>  include/linux/fcntl.h |   3 +-
>>  include/linux/namei.h |   8 +
>>  include/uapi/asm-generic/fcntl.h  |  20 +++
>>  include/uapi/linux/fcntl.h|  10 ++
>>  tools/testing/selftests/Makefile  |   1 +
>>  tools/testing/selftests/vfs/.gitignore|   1 +
>>  tools/testing/selftests/vfs/Makefile  |  13 ++
>>  tools/testing/selftests/vfs/at_flags.h|  40 +
>>  tools/testing/selftests/vfs/common.sh |  37 
>>  .../selftests/vfs/tests/0001_at_beneath.sh|  72 
>>  .../selftests/vfs/tests/0002_at_xdev.sh   |  54 ++
>>  .../vfs/tests/0003_at_no_proclinks.sh |  50 ++
>>  .../vfs/tests/0004_at_no_symlinks.sh  |  49

Re: [PATCH 3.16 000/131] 3.16.59-rc1 review


On 09/29/2018 02:43 PM, Ben Hutchings wrote:

This is the start of the stable review cycle for the 3.16.59 release.
There are 131 patches in this series, which will be posted as responses
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Mon Oct 01 21:43:06 UTC 2018.
Anything received after that time might be too late.



Build results:
total: 139 pass: 139 fail: 0
Qemu test results:
total: 217 pass: 217 fail: 0

Details are available at https://kerneltests.org/builders/.

Guenter

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

2018-09-30 Thread Martin Steigerwald

l...@lkcl.net - 30.09.18, 14:09:
> > That written: Quite some of the rude mails that contained swearwords
> > I read from you have been about code, not persons. I think this is
> > an important distinction. I do not have much of an issue with
> > swearing at code :), especially when it is in some humorous way.
> 
>  absolutely, and this is one thing that a lot of people are, sadly,
>  trained pretty much from birth to be incapable of understanding:
>  namely the difference between criticism of the PERSON and criticism
>  of the ACTION.
> 
>  (1) "YOU are bad! GO STAND IN THE NAUGHTY CORNER!"
>  (2) "That was a BAD thing to do!"
>  (3) "That hurt my feelings that you did that"
> 
>  the first is the way that poorly-trained parents and kindergarten
>  teachers talk to children.
> 
>  the second is... only marginally better, but it's a start
> 
>  the third is how UNICEF trains teachers to treat children as human
> beings.

During releasing a lot of limiting "stuff" I found that probably nothing 
written or said can hurt my feelings unless I let it do so or even… 
unless I choose (!) to feel hurt about it. So at times I am clear about 
this, I´d say: "I have chosen to feel hurt about what you did."

However in this human experience a lot of people, including myself, 
still hold on to a lot of limiting "stuff" which invites feeling hurt. 
We, as humankind, have a history of hurting each other.

During this releasing work I also learned about two key ingredients of 
successful relationships: Harmlessness and mutuality. I opted out of the 
hurting cycle as best I can. And so I choose to write in a way that 
moves around what from my own experience of feeling hurt I know could 
hurt others. I choose to write in a harmless way so to say. While still 
aiming to bring my point across. A very important ingredient for this is 
to write from my own experience. 

Of course others can feel hurt about something I would not feel hurt 
about and I may not be aware that the other might feel hurt about. That 
is why in such a case it is important to give and receive feedback. 
Still when writing from my own experience without saying that anything 
is wrong with the other, it appears to be unlikely to trigger hurt. That 
is at least my experience so far.

Thanks,
-- 
Martin

[RFC 0/5] MIPS: Lexra LX5280 CPU + Realtek RTL8186 SoC support

Hi,

This RFC patch series adds all the necessary code
to successfully boot Linux on the Realtek RTL8186 SoC.

Boot log with this series applied (+one DT patch that adds partitions) is 
available here:
https://gist.github.com/yashac3/483decfa8db014edfb055ba5a1f9996e

Network drivers and other misc drivers are not included
in this patch set (they will be sent in the future).


This patch series includes:
- Patch 1: Lexra LX5280 CPU support (MIPS)
- Patches 2-4: DT bindings for hardware supported in patch 5
- Patch 5: RTL8186 SoC support (MIPS code, timer driver, irqchip, device tree)


What's still missing:

1) Upstream toolchain support for the Lexra LX5280 CPU.
   (Still WIP) GCC and binutils patches are available at [1][2].
   Buildroot with these patches applied is available at [3].

   The toolchain work is still WIP and I'm planning to send it
   for review when it will be ready.

   Still, feel free to comment on this work too.

2) Reading the TLB size from device tree:
   (The reason there's no DT bindings for the LX5280 in this series)

   As there's no way to get the TLB size from the hardware,
   is must be passed in the DT.

   Currently in arch/mips, the FDT is not available in the cpu_probe()
   stage, where the 'tlbsize' field of the cpu data is set.

   Any ideas/suggestions on how to solve that?


This patch series is on top of v4.18 + 5 prerequisite patches that
are in mips-next for 4.20. [4][5].

This patch series is also available at:
https://github.com/yashac3/linux-rtl8186/commits/rtl8186-porting-for-upstream-4.18


Please review.

Thanks,
Yasha


[1] https://github.com/yashac3/gcc/commits/lx5280-gcc-8_2_0
[2] https://github.com/yashac3/binutils-gdb/commits/lx5280-porting-master
[3] https://github.com/yashac3/buildroot/commits/lx5280_master
[4] https://www.linux-mips.org/archives/linux-mips/2018-09/msg00769.html
[5] https://www.linux-mips.org/archives/linux-mips/2018-09/msg00775.html


Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Daniel Lezcano 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-m...@linux-mips.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org


Yasha Cherikovsky (5):
  MIPS: Add support for the Lexra LX5280 CPU
  dt-binding: timer: Document RTL8186 SoC DT bindings
  dt-binding: interrupt-controller: Document RTL8186 SoC DT bindings
  dt-binding: mips: Document Realtek SoC DT bindings
  MIPS: Add Realtek RTL8186 SoC support

 .../interrupt-controller/realtek,rtl8186-intc |  18 ++
 .../devicetree/bindings/mips/realtek.txt  |   9 +
 .../bindings/timer/realtek,rtl8186-timer.txt  |  17 ++
 arch/mips/Kbuild.platforms|   1 +
 arch/mips/Kconfig |  47 +++-
 arch/mips/Makefile|   1 +
 arch/mips/boot/compressed/uart-16550.c|   5 +
 arch/mips/boot/dts/Makefile   |   1 +
 arch/mips/boot/dts/realtek/Makefile   |   4 +
 arch/mips/boot/dts/realtek/rtl8186.dtsi   |  86 ++
 .../dts/realtek/rtl8186_edimax_br_6204wg.dts  |  45 
 arch/mips/configs/rtl8186_defconfig   | 112 
 arch/mips/include/asm/cpu-features.h  |   3 +
 arch/mips/include/asm/cpu-type.h  |   4 +
 arch/mips/include/asm/cpu.h   |   9 +
 arch/mips/include/asm/isadep.h|   3 +-
 arch/mips/include/asm/mach-rtl8186/rtl8186.h  |  37 +++
 arch/mips/include/asm/mipsregs.h  |  10 +
 arch/mips/include/asm/module.h|   2 +
 arch/mips/include/asm/pgtable-32.h|   7 +-
 arch/mips/include/asm/pgtable-bits.h  |   9 +-
 arch/mips/include/asm/pgtable.h   |   6 +-
 arch/mips/include/asm/stackframe.h|   9 +-
 arch/mips/include/asm/traps.h |   2 +
 arch/mips/kernel/Makefile |   2 +
 arch/mips/kernel/cpu-probe.c  |   6 +
 arch/mips/kernel/entry.S  |   3 +-
 arch/mips/kernel/genex.S  |   6 +-
 arch/mips/kernel/idle.c   |  10 +
 arch/mips/kernel/process.c|   3 +-
 arch/mips/kernel/traps.c  |  42 +++
 arch/mips/lib/Makefile|   1 +
 arch/mips/mm/Makefile |   1 +
 arch/mips/mm/c-lx5280.c   | 251 ++
 arch/mips/mm/cache.c  |   6 +
 arch/mips/mm/fault.c  |   4 +
 arch/mips/mm/tlbex.c  |   1 +
 arch/mips/rtl8186/Makefile|   2 +
 arch/mips/rtl8186/Platform|   7 +
 arch/mips/rtl8186/irq.c   |   8 +
 arch/mips/rtl8186/prom.c  |  15 ++
 arch/mips/rtl8186/setup.c |  80 ++
 arch/mips/rtl8186/time.c  |  10 +
 drivers/clocksource/Kconfig   |   9 +
 drivers/clocksource/Makefile

[RFC 2/5] dt-binding: timer: Document RTL8186 SoC DT bindings

This patch adds device tree binding doc for the
Realtek RTL8186 SoC timer controller.

Signed-off-by: Yasha Cherikovsky 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: devicet...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 .../bindings/timer/realtek,rtl8186-timer.txt| 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt 
b/Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt
new file mode 100644
index ..eaa6292c16e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/realtek,rtl8186-timer.txt
@@ -0,0 +1,17 @@
+Realtek RTL8186 SoC timer
+
+Required properties:
+
+- compatible : Should be "realtek,rtl8186-timer".
+- reg : Specifies base physical address and size of the registers.
+- interrupts : The interrupt number of the timer.
+- clocks: phandle to the source clock (usually a 22 MHz fixed clock)
+
+Example:
+
+timer {
+   compatible = "realtek,rtl8186-timer";
+   reg = <0x1d010050 0x30>;
+   interrupts = <0>;
+   clocks = <&sysclk>;
+};
-- 
2.19.0

[RFC 3/5] dt-binding: interrupt-controller: Document RTL8186 SoC DT bindings

This patch adds device tree binding doc for the
Realtek RTL8186 SoC interrupt controller.

Signed-off-by: Yasha Cherikovsky 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: devicet...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 .../interrupt-controller/realtek,rtl8186-intc  | 18 ++
 1 file changed, 18 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/realtek,rtl8186-intc

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl8186-intc 
b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl8186-intc
new file mode 100644
index ..21956d210021
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/realtek,rtl8186-intc
@@ -0,0 +1,18 @@
+Realtek RTL8186 SoC interrupt controller
+
+Required properties:
+
+- compatible : should be "realtek,rtl8186-intc"
+- interrupt-controller : Identifies the node as an interrupt controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+intc: interrupt-controller@1d01 {
+   compatible = "realtek,rtl8186-intc";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   reg = <0x1d01 0x8>;
+};
-- 
2.19.0

[RFC 4/5] dt-binding: mips: Document Realtek SoC DT bindings

This patch adds device tree binding doc for Realtek MIPS SoCs.

It includes a compatible string for the Realtek RTL8186 SoC.

Signed-off-by: Yasha Cherikovsky 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: devicet...@vger.kernel.org
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 Documentation/devicetree/bindings/mips/realtek.txt | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/realtek.txt

diff --git a/Documentation/devicetree/bindings/mips/realtek.txt 
b/Documentation/devicetree/bindings/mips/realtek.txt
new file mode 100644
index ..09d19758168a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/realtek.txt
@@ -0,0 +1,9 @@
+Realtek MIPS SoC device tree bindings
+
+1. SoCs
+
+Each device tree must specify a compatible value for the Realtek SoC
+it uses in the compatible property of the root node. The compatible
+value must be one of the following values:
+
+  realtek,rtl8186-soc
-- 
2.19.0

[RFC 5/5] MIPS: Add Realtek RTL8186 SoC support

The Realtek RTL8186 SoC is a MIPS based SoC
used in some home routers [1][2].

The hardware includes Lexra LX5280 CPU with a TLB,
two Ethernet controllers, a WLAN controller and more.

With this patch, it is possible to successfully boot
the kernel and load userspace on the Edimax BR-6204Wg
router.
Network drivers support will come in future patches.

This patch includes:
- New MIPS rtl8186 platform
- Core platform setup code (mostly DT based)
- New Kconfig option
- defconfig file
- MIPS zboot UART support
- RTL8186 interrupt controller driver
- RTL8186 timer driver
- Device tree files for the RTL8186 SoC and Edimax BR-6204Wg
  router

[1] https://www.linux-mips.org/wiki/Realtek_SOC#Realtek_RTL8186
[2] https://wikidevi.com/wiki/Realtek_RTL8186

Signed-off-by: Yasha Cherikovsky 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: Daniel Lezcano 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: linux-m...@linux-mips.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
 arch/mips/Kbuild.platforms|   1 +
 arch/mips/Kconfig |  17 ++
 arch/mips/boot/compressed/uart-16550.c|   5 +
 arch/mips/boot/dts/Makefile   |   1 +
 arch/mips/boot/dts/realtek/Makefile   |   4 +
 arch/mips/boot/dts/realtek/rtl8186.dtsi   |  86 +++
 .../dts/realtek/rtl8186_edimax_br_6204wg.dts  |  45 
 arch/mips/configs/rtl8186_defconfig   | 112 +
 arch/mips/include/asm/mach-rtl8186/rtl8186.h  |  37 +++
 arch/mips/rtl8186/Makefile|   2 +
 arch/mips/rtl8186/Platform|   7 +
 arch/mips/rtl8186/irq.c   |   8 +
 arch/mips/rtl8186/prom.c  |  15 ++
 arch/mips/rtl8186/setup.c |  80 +++
 arch/mips/rtl8186/time.c  |  10 +
 drivers/clocksource/Kconfig   |   9 +
 drivers/clocksource/Makefile  |   1 +
 drivers/clocksource/timer-rtl8186.c   | 220 ++
 drivers/irqchip/Kconfig   |   5 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-rtl8186.c | 107 +
 21 files changed, 773 insertions(+)
 create mode 100644 arch/mips/boot/dts/realtek/Makefile
 create mode 100644 arch/mips/boot/dts/realtek/rtl8186.dtsi
 create mode 100644 arch/mips/boot/dts/realtek/rtl8186_edimax_br_6204wg.dts
 create mode 100644 arch/mips/configs/rtl8186_defconfig
 create mode 100644 arch/mips/include/asm/mach-rtl8186/rtl8186.h
 create mode 100644 arch/mips/rtl8186/Makefile
 create mode 100644 arch/mips/rtl8186/Platform
 create mode 100644 arch/mips/rtl8186/irq.c
 create mode 100644 arch/mips/rtl8186/prom.c
 create mode 100644 arch/mips/rtl8186/setup.c
 create mode 100644 arch/mips/rtl8186/time.c
 create mode 100644 drivers/clocksource/timer-rtl8186.c
 create mode 100644 drivers/irqchip/irq-rtl8186.c

diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index ac7ad54f984f..2793741f05e5 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -27,6 +27,7 @@ platforms += pmcs-msp71xx
 platforms += pnx833x
 platforms += ralink
 platforms += rb532
+platforms += rtl8186
 platforms += sgi-ip22
 platforms += sgi-ip27
 platforms += sgi-ip32
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index bbeabd6b0a80..2f2ef09a1961 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -344,6 +344,23 @@ config MACH_DECSTATION
 
  otherwise choose R3000.
 
+config MACH_RTL8186
+   bool "Realtek RTL8186 SoC"
+   select SYS_SUPPORTS_BIG_ENDIAN
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_HAS_CPU_LX5280
+   select DMA_NONCOHERENT
+   select SYS_SUPPORTS_ZBOOT_UART16550
+   select SYS_HAS_EARLY_PRINTK
+   select USE_GENERIC_EARLY_PRINTK_8250
+   select USE_OF
+   select COMMON_CLK
+   select RTL8186_IRQ
+   select RTL8186_TIMER
+   select BUILTIN_DTB
+   help
+ Realtek RTL8186 SoC support.
+
 config MACH_JAZZ
bool "Jazz family of machines"
select ARCH_MIGHT_HAVE_PC_PARPORT
diff --git a/arch/mips/boot/compressed/uart-16550.c 
b/arch/mips/boot/compressed/uart-16550.c
index aee8d7b8f091..99314df48718 100644
--- a/arch/mips/boot/compressed/uart-16550.c
+++ b/arch/mips/boot/compressed/uart-16550.c
@@ -35,6 +35,11 @@
 #define IOTYPE unsigned int
 #endif
 
+#ifdef CONFIG_MACH_RTL8186
+#define UART0_BASE 0xbd0100c3
+#define PORT(offset) (UART0_BASE + (4 * offset))
+#endif
+
 #ifndef IOTYPE
 #define IOTYPE char
 #endif
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 1e79cab8e269..50dc192bbde5 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -11,6 +11,7 @@ subdir-y  += ni
 subdir-y   += pic32
 subdir-y   += qca
 subdir-y   += ralink
+subdir-y   += realtek
 subdir-y   += xilfpga

[RFC 1/5] MIPS: Add support for the Lexra LX5280 CPU

The Lexra LX5280 CPU [1][2] implements the MIPS-I ISA,
without unaligned load/store instructions (lwl, lwr, swl, swr).
The programming model of this CPU is very similar
to the R3000 programming model, with a few differences.

The Realtek RTL8186 SoC has this CPU, so this patch is required
for future RTL8186 SoC support.

The LX5280 CPU has no documented TLB unit (only SMMU, a simple MMU unit
which is not enough for usual Linux).
However, the RTL8186 SoC does include a TLB unit with the CPU
(programmed like R3000 TLB).

So this patch adds support *only* for LX5280s that have a TLB unit.

This patch includes:
- Adding Kconfig entries for LX5280
- Adding CPU_LX5280 to the cpu_type_enum
- Passing -march=lx5280 to the compiler
- Using existing R3000 code/behavior where possible
- Wait instruction support (for better idle power consuption)
- RDHWR instruction emulation from the page fault handler
  (more details in a code comment)

[1] https://www.linux-mips.org/wiki/Lexra
[2] https://wikidevi.com/wiki/Lexra_LX5280

Signed-off-by: Yasha Cherikovsky 
Cc: Ralf Baechle 
Cc: Paul Burton 
Cc: James Hogan 
Cc: linux-m...@linux-mips.org
Cc: linux-kernel@vger.kernel.org
---
 arch/mips/Kconfig|  30 +++-
 arch/mips/Makefile   |   1 +
 arch/mips/include/asm/cpu-features.h |   3 +
 arch/mips/include/asm/cpu-type.h |   4 +
 arch/mips/include/asm/cpu.h  |   9 +
 arch/mips/include/asm/isadep.h   |   3 +-
 arch/mips/include/asm/mipsregs.h |  10 ++
 arch/mips/include/asm/module.h   |   2 +
 arch/mips/include/asm/pgtable-32.h   |   7 +-
 arch/mips/include/asm/pgtable-bits.h |   9 +-
 arch/mips/include/asm/pgtable.h  |   6 +-
 arch/mips/include/asm/stackframe.h   |   9 +-
 arch/mips/include/asm/traps.h|   2 +
 arch/mips/kernel/Makefile|   2 +
 arch/mips/kernel/cpu-probe.c |   6 +
 arch/mips/kernel/entry.S |   3 +-
 arch/mips/kernel/genex.S |   6 +-
 arch/mips/kernel/idle.c  |  10 ++
 arch/mips/kernel/process.c   |   3 +-
 arch/mips/kernel/traps.c |  42 +
 arch/mips/lib/Makefile   |   1 +
 arch/mips/mm/Makefile|   1 +
 arch/mips/mm/c-lx5280.c  | 251 +++
 arch/mips/mm/cache.c |   6 +
 arch/mips/mm/fault.c |   4 +
 arch/mips/mm/tlbex.c |   1 +
 26 files changed, 408 insertions(+), 23 deletions(-)
 create mode 100644 arch/mips/mm/c-lx5280.c

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a6b0391996ea..bbeabd6b0a80 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -1558,6 +1558,17 @@ config CPU_R3000
  might be a safe bet.  If the resulting kernel does not work,
  try to recompile with R3000.
 
+config CPU_LX5280
+   bool "LX5280"
+   depends on SYS_HAS_CPU_LX5280
+   select CPU_SUPPORTS_32BIT_KERNEL
+   help
+ Choose this option to build a kernel for the Lexra LX5280 CPU.
+ Lexra LX5280 implements the MIPS-I instruction set, without
+ unaligned load and store instructions (lwl, lwr, swl, swr).
+ Only LX5280 CPUs with a TLB unit are supported.
+
+
 config CPU_TX39XX
bool "R39XX"
depends on SYS_HAS_CPU_TX39XX
@@ -1939,6 +1950,9 @@ config SYS_HAS_CPU_R3000
 config SYS_HAS_CPU_TX39XX
bool
 
+config SYS_HAS_CPU_LX5280
+   bool
+
 config SYS_HAS_CPU_VR41XX
bool
 
@@ -2169,7 +2183,7 @@ config PAGE_SIZE_8KB
 
 config PAGE_SIZE_16KB
bool "16kB"
-   depends on !CPU_R3000 && !CPU_TX39XX
+   depends on !CPU_R3000 && !CPU_TX39XX && !CPU_LX5280
help
  Using 16kB page size will result in higher performance kernel at
  the price of higher memory consumption.  This option is available on
@@ -2188,7 +2202,7 @@ config PAGE_SIZE_32KB
 
 config PAGE_SIZE_64KB
bool "64kB"
-   depends on !CPU_R3000 && !CPU_TX39XX
+   depends on !CPU_R3000 && !CPU_TX39XX && !CPU_LX5280
help
  Using 64kB page size will result in higher performance kernel at
  the price of higher memory consumption.  This option is available on
@@ -2256,15 +2270,15 @@ config CPU_HAS_PREFETCH
 
 config CPU_GENERIC_DUMP_TLB
bool
-   default y if !(CPU_R3000 || CPU_R8000 || CPU_TX39XX)
+   default y if !(CPU_R3000 || CPU_R8000 || CPU_TX39XX || CPU_LX5280)
 
 config CPU_R4K_FPU
bool
-   default y if !(CPU_R3000 || CPU_TX39XX)
+   default y if !(CPU_R3000 || CPU_TX39XX || CPU_LX5280)
 
 config CPU_R4K_CACHE_TLB
bool
-   default y if !(CPU_R3000 || CPU_R8000 || CPU_SB1 || CPU_TX39XX || 
CPU_CAVIUM_OCTEON)
+   default y if !(CPU_R3000 || CPU_R8000 || CPU_SB1 || CPU_TX39XX || 
CPU_CAVIUM_OCTEON || CPU_LX5280)
 
 config MIPS_MT_SMP
bool "MIPS MT SMP support (1 TC on each available VPE)"
@@ -2501,7 +2515,7 @@ config CPU_MIPSR2_IRQ_EI
 
 config CPU_HAS_SYNC
bool
-   depends on !CPU_R3

Re: Leaking Path in XFS's ioctl interface(missing LSM check)

2018-09-30 Thread Alan Cox

> > CAP_SYS_ADMIN is also a bit weird because low level access usually
> > implies you can bypass access controls so you should also check
> > CAP_SYS_DAC ?  
> 
> Do you mean CAP_DAC_READ_SEARCH as per the newer handle syscalls?
> But that only allows bypassing directory search operations, so maybe
> you mean CAP_DAC_OVERRIDE?

It depends what the ioctl allows you to do. If it allows me to bypass
DAC and manipulate the file system to move objects around then it's a
serious issue.

The underlying problem is if CAP_SYS_ADMIN is able to move objects around
then I can move modules around. We already have a problem with
CAP_DAC_OVERRIDE giving you CAP_SYS_RAWIO (ie totally owning the machine)
unless the modules are signed, if xfs allows ADMIN as well then
CAP_SYS_ADMIN is much easier to obtain and you'd get total system
ownership from it.

Not good.

> Regardless, this horse bolted long before those syscalls were
> introduced.  The time to address this issue was when XFS was merged
> into linux all those years ago, back when the apps that run in
> highly secure restricted environments that use these interfaces were
> being ported to linux. We can't change this now without breaking
> userspace

That's what people said about setuid shell scripts.

I'd like to understand better what can be done. We can argue afterwards
about what if anything to do about it and if it is possible to abuse it.

Alan

Linux 4.19-rc6

Hi all,

It's been another week, so as normal, another -rc release is here.  For
a -rc6 release, it's pretty normal.  There are more individual merges
from different trees than -rc5, but the number of changes is much lower
than last week.  Lots of different driver tree updates, along with some
some x86 and a risc-v fix.

Full details are in the shortlog below, and as always, please go test
and report any problems.  It all "just works" on my systems, and I have
not heard of any major outstanding issues as of this point in time.

thanks,

greg k-h

Aaron Ma (1):
  Input: elantech - enable middle button of touchpad on ThinkPad P72

Adrian Hunter (1):
  scsi: ufs: Disable blk-mq for now

Alaa Hleihel (1):
  net/mlx5: Check for SQ and not RQ state when modifying hairpin SQ

Alan Stern (3):
  USB: remove LPM management from usb_driver_claim_interface()
  USB: fix error handling in usb_driver_claim_interface()
  USB: handle NULL config in usb_find_alt_setting()

Alexander Shishkin (3):
  intel_th: Fix device removal logic
  intel_th: Fix resource handling for ACPI glue layer
  intel_th: pci: Add Ice Lake PCH support

Alexandre Belloni (1):
  clocksource/drivers/timer-atmel-pit: Properly handle error cases

Alexandru Gheorghe (2):
  drm: mali-dp: Call drm_crtc_vblank_reset on device init
  drm/malidp: Fix writeback in NV12

Alexey Kardashevskiy (1):
  powerpc/powernv/ioda2: Reduce upper limit for DMA window size (again)

Andreas Schwab (1):
  Input: atakbd - fix Atari keymap

Anson Huang (1):
  Input: egalax_ts - add system wakeup support

Antoine Tenart (4):
  net: mvpp2: fix a txq_done race condition
  net: mvneta: fix the Rx desc buffer DMA unmapping
  net: mscc: fix the frame extraction into the skb
  net: mvneta: fix the remaining Rx descriptor unmapping issues

Arindam Nath (1):
  iommu/amd: Return devid as alias for ACPI HID devices

Arnd Bergmann (2):
  media: camss: mark PM functions as __maybe_unused
  media: camss: add missing includes

Bart Van Assche (1):
  IB/srp: Avoid that sg_reset -d ${srp_device} triggers an infinite loop

Bhawanpreet Lakha (1):
  drm/amd/display: Fix Edid emulation for linux

Bin Liu (1):
  usb: musb: dsps: do not disable CPPI41 irq in driver teardown

Bjorn Helgaas (1):
  MAINTAINERS: Update PPC contacts for PCI core error handling

Boris Brezillon (2):
  spi: spi-mem: Add missing description for data.nbytes field
  spi: spi-mem: Move the DMA-able constraint doc to the kerneldoc header

Boris Ostrovsky (1):
  xen/blkfront: When purging persistent grants, keep them in the buffer

Christian Lamparter (1):
  net: emac: fix fixed-link setup for the RTL8363SB switch

Christoph Hellwig (1):
  dma-mapping: add the missing ARCH_HAS_SYNC_DMA_FOR_CPU_ALL declaration

Christophe Leroy (2):
  serial: cpm_uart: return immediately from console poll
  powerpc: fix csum_ipv6_magic() on little endian platforms

Cong Wang (1):
  ucma: fix a use-after-free in ucma_resolve_ip()

Damien Le Moal (1):
  block: fix deadline elevator drain for zoned block devices

Dan Carpenter (1):
  devlink: double free in devlink_resource_fill()

Daniel Kurtz (1):
  pinctrl/amd: poll InterruptEnable bits in amd_gpio_irq_set_type

Dave Jiang (2):
  uaccess: Fix is_source param for check_copy_size() in 
copy_to_iter_mcsafe()
  device-dax: Add missing address_space_operations

David S. Miller (1):
  rds: Fix build regression.

Davide Caratti (1):
  bnxt_en: don't try to offload VLAN 'modify' action

Dmitry Safonov (1):
  tty: Drop tty->count on tty_reopen() failure

Eli Cohen (1):
  net/mlx5: Fix read from coherent memory

Eric Dumazet (15):
  netpoll: make ndo_poll_controller() optional
  bonding: use netpoll_poll_dev() helper
  ixgbe: remove ndo_poll_controller
  ixgbevf: remove ndo_poll_controller
  fm10k: remove ndo_poll_controller
  ixgb: remove ndo_poll_controller
  igb: remove ndo_poll_controller
  ice: remove ndo_poll_controller
  i40evf: remove ndo_poll_controller
  mlx4: remove ndo_poll_controller
  mlx5: remove ndo_poll_controller
  bnx2x: remove ndo_poll_controller
  bnxt: remove ndo_poll_controller
  nfp: remove ndo_poll_controller
  tun: remove ndo_poll_controller

Friedemann Gerold (1):
  net: aquantia: memory corruption on jumbo frames

Gaku Inami (1):
  spi: sh-msiof: Fix invalid SPI use during system suspend

Geert Uytterhoeven (2):
  spi: rspi: Fix invalid SPI use during system suspend
  spi: rspi: Fix interrupted DMA transfers

Greg Kroah-Hartman (1):
  Linux 4.19-rc6

Guoju Fang (1):
  bcache: add separate workqueue for journal_write to avoid deadlock

Gustavo A. R. Silva (1):
  tty: vt_ioctl: fix potential Spectre v1

Hans Verkuil (2):
  media: video_function_calls.rst: drop obsolete video-set-attributes 
reference
  media: staging/me

Re: [PATCH v6 2/2] iio: proximity: vl53l0x: add interrupt support

2018-09-30 Thread Jonathan Cameron




On 30 September 2018 00:49:43 BST, Rob Herring  wrote:
>On Sat, Sep 29, 2018 at 6:10 AM Jonathan Cameron 
>wrote:
>>
>> On Fri, 28 Sep 2018 18:52:13 -0500
>> Rob Herring  wrote:
>>
>> > On Fri, Sep 28, 2018 at 4:36 AM Song Qiang
> wrote:
>> > >
>> > > On Wed, Sep 26, 2018 at 05:46:18PM -0500, Rob Herring wrote:
>> > > > On Sat, Sep 22, 2018 at 04:05:23PM +0100, Jonathan Cameron
>wrote:
>> > > > > On Tue, 18 Sep 2018 16:24:22 +0800
>> > > > > Song Qiang  wrote:
>> > > > >
>> > > > > > The first version of this driver issues a measuring request
>and polling
>> > > > > > for a status register in the device for measuring
>completes.
>> > > > > > vl53l0x support configuring GPIO1 on it to generate
>interrupt to
>> > > > > > indicate that new measurement is ready. This patch adds
>support for
>> > > > > > using this mechanisim to reduce cpu cost.
>> > > > > >
>> > > > > > Signed-off-by: Song Qiang 
>> > > > > Hi Song.
>> > > > >
>> > > > > Looks correct in principal but a few things to tidy up before
>> > > > > this is ready to apply.
>> > > > >
>> > > > > Also we have an unrelated change in here to check the devices
>ID.
>> > > > > That should be in it's own patch.
>> > > > >
>> > > > > Thanks,
>> > > > >
>> > > > > Jonathan
>> > > > > > ---
>> > > > > >  .../bindings/iio/proximity/vl53l0x.txt|  14 +-
>> > > >
>> > > > This should have been split with the complete binding in one
>patch
>> > > > rather than piecemeal driver feature by feature.
>> > > >
>> > >
>> > > Hi Rob,
>>
>> Hi Rob, Song,
>>
>> > >
>> > > A few days ago when I was submitting this driver, I didn't do it
>very
>> > > well, the function of this driver is limited. I added interrupt
>support
>> > > the next day after you acked my first patch. I thought it's not
>polite
>> > > to add something after someone acked that patch, so I send the
>interrupt
>> > > support as a second patch. The first patch is merged to togreg
>now, but
>> > > this doesn't. I don't know when can I add new functions to the
>code that
>> > > just merged to togreg branch, could you offer some suggestions?
>> >
>> > You just needed to state why you didn't add a ack. But really, just
>> > don't send things except as RFC until they are "done".
>>
>> The RFC bit actually disagree on.  This driver could be considered
>'done'
>> with just patch 1.  The driver worked, it was useful. When the early
>> versions of that patch came out Song had no idea how much work it
>would
>> be to add interrupt support.  As it turns out it was simple - it
>often isn't :(
>
>I meant specifically in the context of this getting revised within a
>number of days. I agree that drivers don't have to be complete, but
>bindings should be as complete as possible. You can't foresee
>everything, but I don't think that applies in this case.
>
>> > What to do next depends on Jonathan and whether he wants a
>follow-up
>> > patch or he will drop the first one.
>>
>> Yeah. I should have picked up on the binding in the second patch and
>merged
>> it.  I'd seen the first patch a few times before so was happy with it
>and
>> applied before actually looking at the second.
>>
>> If they had come in separate series in my view the partial binding
>then
>> extend with 'optional' elements is fine.  The number of times I've
>discovered
>> issues with documentation of hardware that would have made any
>binding written
>> from the docs wrong is non trivial. So in my view it is always a
>gamble to
>> write bindings until you have tested they work.  I have not problem
>with
>> people who are confident and want to add them from the start though.
>
>Well, if they were broken is some way, I don't think backwards
>compatibility matters and we can still fix things. I'm not talking
>about complex cases here. It is pretty trivial to determine whether a
>device has an interrupt or not.
>
>>
>> Obviously this only works for optional elements.
>>
>> So follow up patch for 'optional' stuff is fine by me.  The only real
>> issue to my mind here is that they were in the same series, so we
>should
>> have seen a separate precursor patch giving the binding for all of
>it.
>
>Certainly, that can't be avoided sometimes and is fine. It's really
>the time frame for this particular case and reviewer bandwidth.

Agreed. The timing wasn't ideal (in this limited sense)  Song got this done 
much faster than I normally expect
when someone says, I'll do this later! 

Thanks for clarifying.

Jonathan
>
>Rob

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [RFC PATCH] soc: qcom: rmtfs_mem: Control remoteproc from rmtfs_mem

2018-09-30 Thread Sibi Sankar


On 2018-09-25 22:59, Brian Norris wrote:

Hi Bjorn,

On Tue, Sep 25, 2018 at 01:06:07AM -0700, Bjorn Andersson wrote:

rmtfs_mem provides access to physical storage and is crucial for the
operation of the Qualcomm modem subsystem.

The rmtfs_mem implementation must be available before the modem
subsystem is booted and a solution where the modem remoteproc will
verify that the rmtfs_mem is available has been discussed in the past.
But this would not handle the case where the rmtfs_mem provider is
restarted, which would cause fatal loss of access to the storage 
device

for the modem.

The suggestion is therefor to link the rmtfs_mem to its associated
remote processor instance and control it based on the availability of
the rmtfs_mem implementation.


But what does "availability" mean? If I'm reading your rmtfs daemon
properly, "availability" should mean that the daemon is up and has
registered a RMTFS_QMI_SERVICE. But in this patch, you're keying off of
the open() call, which sounds like you're introducing a race condition
-- we might have open()ed the RMTFS memory but we're not actually
completely ready to service requests.

So rather than looking for open(), I think somebody needs to be looking
for the appearance and disappearance of the RMTFS_QMI_SERVICE. (Looking
for disappearance would resolve the daemon restart issue, no?) That
"somebody" could be the remoteproc driver I suppose 
(qmi_add_lookup()?),

or...couldn't it just be the modem itself? Do you actually need to
restart the entire modem when the RMTFS service goes away, or do you
just need to pause storage activity?



Hi Brian,

It might be more logical to make that "somebody" the rmtfs_mem driver 
itself, since
the modem as such does not have any direct functional dependency on 
rmtfs_mem i.e
the firmware can be configured to run on rmtfs_mem or internal fs. So in 
such cases
where the modem is running on internal fs, it would be undesirable to 
have a hard

coded dependency for rmtfs_mem in remoteproc modem itself.

Wouldn't it be simpler/quicker to fix this in kernel than churning out 
new firmware
releases. A fix in firmware will also mean that this becomes one-off fix 
for dragon
boards diverging the firmware branch from whats used in android for 
8916/8974/8996.



Signed-off-by: Bjorn Andersson 
---

The currently implemented workaround in the Linaro QCOMLT releases is 
to
blacklist the qcom_q6v5_pil kernel module and load this explicitly 
after rmtfs

has been started.

With this patch the modem module can be loaded automatically by the
platform_bus and will only be booted as the rmtfs becomes available. 
Performing
actions such as upgrading (and restarting) the rmtfs service will 
cause the
modem to automatically restart and hence continue to function after 
the

upgrade.

 .../reserved-memory/qcom,rmtfs-mem.txt|  7 ++
 drivers/remoteproc/qcom_q6v5_pil.c|  1 +
 drivers/soc/qcom/Kconfig  |  1 +
 drivers/soc/qcom/rmtfs_mem.c  | 23 
++-

 4 files changed, 31 insertions(+), 1 deletion(-)


...
diff --git a/drivers/soc/qcom/rmtfs_mem.c 
b/drivers/soc/qcom/rmtfs_mem.c

index 8a3678c2e83c..8b08be310397 100644
--- a/drivers/soc/qcom/rmtfs_mem.c
+++ b/drivers/soc/qcom/rmtfs_mem.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,8 @@ struct qcom_rmtfs_mem {
unsigned int client_id;

unsigned int perms;
+
+   struct rproc *rproc;
 };

 static ssize_t qcom_rmtfs_mem_show(struct device *dev,
@@ -80,11 +83,18 @@ static int qcom_rmtfs_mem_open(struct inode 
*inode, struct file *filp)

struct qcom_rmtfs_mem *rmtfs_mem = container_of(inode->i_cdev,
struct qcom_rmtfs_mem,
cdev);
+   int ret = 0;

get_device(&rmtfs_mem->dev);
filp->private_data = rmtfs_mem;

-   return 0;
+   if (rmtfs_mem->rproc) {
+   ret = rproc_boot(rmtfs_mem->rproc);
+   if (ret)
+   put_device(&rmtfs_mem->dev);
+   }
+
+   return ret;
 }
 static ssize_t qcom_rmtfs_mem_read(struct file *filp,
  char __user *buf, size_t count, loff_t *f_pos)
@@ -127,6 +137,9 @@ static int qcom_rmtfs_mem_release(struct inode 
*inode, struct file *filp)

 {
struct qcom_rmtfs_mem *rmtfs_mem = filp->private_data;

+   if (rmtfs_mem->rproc)
+   rproc_shutdown(rmtfs_mem->rproc);
+
put_device(&rmtfs_mem->dev);

return 0;
@@ -156,6 +169,7 @@ static int qcom_rmtfs_mem_probe(struct 
platform_device *pdev)

struct qcom_scm_vmperm perms[2];
struct reserved_mem *rmem;
struct qcom_rmtfs_mem *rmtfs_mem;
+   phandle rproc_phandle;
u32 client_id;
u32 vmid;
int ret;
@@ -181,6 +195,13 @@ static int qcom_rmtfs_mem_probe(struct 
platform_device *pdev)

Re: [PATCH v13 1/2] leds: core: Introduce LED pattern trigger

2018-09-30 Thread Jacek Anaszewski

Hi Baolin,

Thank you for adding the dimming support.

I've tested it and detected severe problem when
delta_t is lower than 50, i.e. UPDATE_INTERVAL.

echo "10 49 20 49" > pattern

results after a while in a system wide freeze, see the following
kernel log:

[  210.593592] rcu: INFO: rcu_sched self-detected stall on CPU
[  210.593601] rcu: 4-: (21134 ticks this GP) idle=5b6/0/0x3
softirq=4843/4843 fqs=5250
[  210.593602] rcu:  (t=21000 jiffies g=25697 q=79)
[  210.593605] NMI backtrace for cpu 4
[  210.593608] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 4.19.0-rc1+ #156
[  210.593609] Hardware name: Gigabyte Technology Co., Ltd.
Z97-HD3/Z97-HD3, BIOS F6 06/11/2014
[  210.593609] Call Trace:
[  210.593612]  
[  210.593618]  dump_stack+0x46/0x5b
[  210.593621]  nmi_cpu_backtrace+0x90/0xa0
[  210.593625]  ? lapic_can_unplug_cpu+0x90/0x90
[  210.593627]  nmi_trigger_cpumask_backtrace+0x8d/0xc0
[  210.593630]  rcu_dump_cpu_stacks+0x83/0xb3
[  210.593632]  rcu_check_callbacks+0x5aa/0x710
[  210.593636]  ? tick_sched_do_timer+0x50/0x50
[  210.593638]  update_process_times+0x23/0x50
[  210.593640]  tick_sched_handle+0x2f/0x40
[  210.593642]  tick_sched_timer+0x32/0x70
[  210.593644]  __hrtimer_run_queues+0xf7/0x270
[  210.593646]  hrtimer_interrupt+0x11d/0x270
[  210.593649]  smp_apic_timer_interrupt+0x5d/0x130
[  210.593651]  apic_timer_interrupt+0xf/0x20
[  210.593655] RIP: 0010:pattern_trig_timer_function+0x23/0x100
[  210.593657] Code: ff ff eb f6 0f 1f 00 41 54 4c 8d a7 b0 df ff ff 55
53 48 89 fb 49 8d ac 24 18 20 00 00 48 89 ef e8 f2 d3 29 00 eb 16 8b 53
f4 <8b> 08 39 ca 77 05 83 f9 31 77 6d 4c 89 e7 e8 aa f9 ff ff 80 7b f8
[  210.593658] RSP: 0018:8d1017903eb8 EFLAGS: 0216 ORIG_RAX:
ff13
[  210.593659] RAX: 8d0fe7330010 RBX: 8d0fe7332050 RCX:
0031
[  210.593660] RDX:  RSI: 0014 RDI:
000a
[  210.593661] RBP: 8d0fe7332018 R08: 8d1017903f08 R09:
8d1017903f08
[  210.593662] R10: 002c1cd5e92f R11:  R12:
8d0fe733
[  210.593663] R13: aa738a70 R14:  R15:
0001
[  210.593665]  ? apic_timer_interrupt+0xa/0x20
[  210.593666]  ? pattern_trig_activate+0xc0/0xc0
[  210.593669]  ? pattern_trig_timer_function+0x36/0x100
[  210.593671]  call_timer_fn+0x26/0x130
[  210.593672]  run_timer_softirq+0x1cc/0x400
[  210.593674]  ? enqueue_hrtimer+0x35/0x90
[  210.593676]  ? __hrtimer_run_queues+0x127/0x270
[  210.593679]  ? recalibrate_cpu_khz+0x10/0x10
[  210.593681]  __do_softirq+0x104/0x2a5
[  210.593685]  irq_exit+0x9d/0xa0
[  210.593687]  smp_apic_timer_interrupt+0x67/0x130
[  210.593688]  apic_timer_interrupt+0xf/0x20
[  210.593689]  
[  210.593693] RIP: 0010:cpuidle_enter_state+0xf8/0x2a0
[  210.593694] Code: c7 0f 1f 44 00 00 31 ff e8 65 69 95 ff 80 7c 24 03
00 74 12 9c 58 f6 c4 02 0f 85 8c 01 00 00 31 ff e8 7c 41 9a ff fb 4d 29
e7 <48> ba cf f7 53 e3 a5 9b c4 20 4c 89 f8 4c 89 fd 48 f7 ea 48 c1 fd
[  210.593695] RSP: 0018:b0fc00cf7e88 EFLAGS: 0206 ORIG_RAX:
ff13
[  210.593696] RAX: 8d1017920dc0 RBX: 8d1014b49c00 RCX:
001f
[  210.593697] RDX:  RSI: 00c1514cc3a0 RDI:

[  210.593698] RBP: 0001 R08: fffbcf10adc2 R09:
afc7
[  210.593699] R10: 003c R11: 8d101791fe68 R12:
002c1d11a32d
[  210.593700] R13: 0001 R14: 0004 R15:
00011a82
[  210.593703]  ? cpuidle_enter_state+0xdb/0x2a0
[  210.593705]  do_idle+0x1f5/0x250
[  210.593707]  cpu_startup_entry+0x6a/0x70
[  210.593709]  start_secondary+0x183/0x1b0
[  210.593711]  secondary_startup_64+0xa4/0xb0

Probably the best solution would be to avoid the dimming if
delta_t is lower than UPDATE_INTERVAL.

Besides the above, please refer also to my comments below.

On 09/27/2018 07:04 AM, Baolin Wang wrote:
> This patch adds one new led trigger that LED device can configure
> the software or hardware pattern and trigger it.
> 
> Consumers can write 'pattern' file to enable the software pattern
> which alters the brightness for the specified duration with one
> software timer.
> 
> Moreover consumers can write 'hw_pattern' file to enable the hardware
> pattern for some LED controllers which can autonomously control
> brightness over time, according to some preprogrammed hardware
> patterns.
> 
> Signed-off-by: Raphael Teysseyre 
> Signed-off-by: Baolin Wang 
> ---
> Changes from v12:
>  - Add gradual dimming support for software pattern.
> 
> Changes from v11:
>  - Change -1 means repeat indefinitely.
> 
> Changes from v10:
>  - Change 'int' to 'u32' for delta_t field.
> 
> Changes from v9:
>  - None.
> 
> Changes from v8:
>  - None.
> 
> Changes from v7:
>  - Move the SC27XX hardware patterns description into its own ABI file.
> 
> Changes from v6:
>  - Improve commit message.
>  - Optimize the description of the hw_pattern file.
>  - Simplify some logics.
> 
> Changes fr

Re: ovl: hash non-dir by lower inode for fsnotify

On Fri, Sep 28, 2018 at 10:24:34AM -0700, Mark Salyzyn wrote:
> On 09/07/2018 02:51 AM, Greg KH wrote:
> > As this patch is deemed "good", can you please resend it in a
> > non-corrupted way so that I can apply it to the 4.14.y tree?
> > 
> > thanks,
> > 
> > greg k-h
> 
> The toll of numerous vacations, and manic priorities that resulted, sorry
> for the delay, composed and resent.

No worries, thanks for the patch, now queued up.

greg k-h

Re: [PATCH v3 8/9] jump_table: move entries into ro_after_init region

Hi,

On Tue, Sep 18, 2018 at 11:51:43PM -0700, Ard Biesheuvel wrote:
> The __jump_table sections emitted into the core kernel and into
> each module consist of statically initialized references into
> other parts of the code, and with the exception of entries that
> point into init code, which are defused at post-init time, these
> data structures are never modified.
> 
> So let's move them into the ro_after_init section, to prevent them
> from being corrupted inadvertently by buggy code, or deliberately
> by an attacker.
> 
> Reviewed-by: Kees Cook 
> Acked-by: Jessica Yu 
> Signed-off-by: Ard Biesheuvel 

This patch results in build failures when trying to build s390
images.

s390-linux-ld:./arch/s390/kernel/vmlinux.lds:41: syntax error

Bisect log is attached.

Guenter

---
# bad: [4794a36bf08dfa89fe636e5080db9d8350e255dd] Add linux-next specific files 
for 20180928
# good: [6bf4ca7fbc85d80446ac01c0d1d77db4d91a6d84] Linux 4.19-rc5
git bisect start 'HEAD' 'v4.19-rc5'
# good: [d5b0eb1f139e00e8fd18329d446688b19859755e] Merge remote-tracking branch 
'crypto/master'
git bisect good d5b0eb1f139e00e8fd18329d446688b19859755e
# bad: [d9c3085241c16503e659c2d7f43578f297bf30dc] Merge remote-tracking branch 
'tip/auto-latest'
git bisect bad d9c3085241c16503e659c2d7f43578f297bf30dc
# good: [db9825c95498280718c4687fcf712016f5b6f5f6] Merge tag 
'drm-intel-next-2018-09-21' of git://anongit.freedesktop.org/drm/drm-intel into 
drm-next
git bisect good db9825c95498280718c4687fcf712016f5b6f5f6
# good: [b22777af06f425911c85d8a2c6b4ed929d4e829f] Merge remote-tracking branch 
'mmc/next'
git bisect good b22777af06f425911c85d8a2c6b4ed929d4e829f
# bad: [14cb9d65a396c00eb44e1af967f1c393593f3a4c] Merge branch 'x86/microcode'
git bisect bad 14cb9d65a396c00eb44e1af967f1c393593f3a4c
# good: [c6b5da093a8ba740b71dd0052f3846016986fd21] perf intel-pt: Add decoder 
flags for trace begin / end
git bisect good c6b5da093a8ba740b71dd0052f3846016986fd21
# bad: [441a6b5c97e0136b416a2c12a0c361423a47c717] Merge branch 'sched/core'
git bisect bad 441a6b5c97e0136b416a2c12a0c361423a47c717
# bad: [d43b23bddade094b1a64a087bc5626a065c3c6e5] Merge branch 'locking/core'
git bisect bad d43b23bddade094b1a64a087bc5626a065c3c6e5
# good: [fa70f0d2ce96a892b38fbbaa60584af536f21f97] Merge tag 'efi-next' of 
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core
git bisect good fa70f0d2ce96a892b38fbbaa60584af536f21f97
# bad: [ecf89ab872e94999366834689198c436c06ab68f] Merge branch 'core/core'
git bisect bad ecf89ab872e94999366834689198c436c06ab68f
# good: [9fc0f798ab8a6c042d811e45086260eb59be45c1] x86/jump_label: Switch to 
jump_entry accessors
git bisect good 9fc0f798ab8a6c042d811e45086260eb59be45c1
# good: [19483677684b6ca01606f58503cb79cdfbbc7c72] jump_label: Annotate entries 
that operate on __init code earlier
git bisect good 19483677684b6ca01606f58503cb79cdfbbc7c72
# bad: [13ddb52c165ba47d153b7b040931a5cbe9220866] s390/jump_label: Switch to 
relative references
git bisect bad 13ddb52c165ba47d153b7b040931a5cbe9220866
# bad: [e872267b8bcbb179e21ccc7118f258873d6e7a59] jump_table: Move entries into 
ro_after_init region
git bisect bad e872267b8bcbb179e21ccc7118f258873d6e7a59
# first bad commit: [e872267b8bcbb179e21ccc7118f258873d6e7a59] jump_table: Move 
entries into ro_after_init region

Re: [PATCH 3/4] soc: actions: sps: Add S900 power domains

2018-09-30 Thread Andreas Färber

Am 24.06.18 um 15:07 schrieb Andreas Färber:
> Am 11.04.2018 um 18:40 schrieb Manivannan Sadhasivam:
>> Add power domains for Actions Semi S900 SoC.
>>
>> Signed-off-by: Manivannan Sadhasivam 
>> ---
>>  drivers/soc/actions/owl-sps.c | 58 
>> +++
>>  1 file changed, 58 insertions(+)
> 
> Reviewed-by: Andreas Färber 

Series merged now via topic branch.

Thanks,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [PATCH 5/5] fpga: dfl-fme-region: Use platform_get_drvdata()

2018-09-30 Thread Greg Kroah-Hartman

On Wed, Sep 12, 2018 at 09:43:27AM -0500, Alan Tull wrote:
> From: Moritz Fischer 
> 
> Use platform_get_drvdata() in remove() function of
> the platform driver rather than dev_get_drvdata()
> to match the platform_set_drvdata in the probe().
> 
> Signed-off-by: Moritz Fischer 
> Acked-by: Alan Tull 
> ---
>  drivers/fpga/dfl-fme-region.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
> index 51a5ac2..3fa0de2 100644
> --- a/drivers/fpga/dfl-fme-region.c
> +++ b/drivers/fpga/dfl-fme-region.c
> @@ -66,7 +66,7 @@ static int fme_region_probe(struct platform_device *pdev)
>  
>  static int fme_region_remove(struct platform_device *pdev)
>  {
> - struct fpga_region *region = dev_get_drvdata(&pdev->dev);
> + struct fpga_region *region = platform_get_drvdata(pdev);

This is nice, but not a bugfix.  I'll wait for 4.20-rc1 for this patch.

thanks,

greg k-h

Re: [PATCH 4/5] fpga: of-fpga-region: Use platform_set_drvdata

2018-09-30 Thread Greg Kroah-Hartman

On Wed, Sep 12, 2018 at 09:43:26AM -0500, Alan Tull wrote:
> From: Moritz Fischer 
> 
> Use platform_set_drvdata rather than dev_set_drvdata
> to match the platform_get_drvdata in the _remove()
> function of the platform driver.
> 
> Signed-off-by: Moritz Fischer 
> Acked-by: Alan Tull 
> ---
>  drivers/fpga/of-fpga-region.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/fpga/of-fpga-region.c b/drivers/fpga/of-fpga-region.c
> index 052a134..d6a70e4 100644
> --- a/drivers/fpga/of-fpga-region.c
> +++ b/drivers/fpga/of-fpga-region.c
> @@ -421,7 +421,7 @@ static int of_fpga_region_probe(struct platform_device 
> *pdev)
>   goto eprobe_free;
>  
>   of_platform_populate(np, fpga_region_of_match, NULL, ®ion->dev);
> - dev_set_drvdata(dev, region);
> + platform_set_drvdata(pdev, region);

Again, not really a bugfix :)

[RFC PATCH v2] soc: qcom: rmtfs_mem: Control remoteproc from rmtfs_mem

2018-09-30 Thread Sibi Sankar

From: Bjorn Andersson 

rmtfs_mem provides access to physical storage and is crucial for the
operation of the Qualcomm modem subsystem.

The rmtfs_mem implementation must be available before the modem
subsystem is booted and a solution where the modem remoteproc will
verify that the rmtfs_mem is available has been discussed in the past.
But this would not handle the case where the rmtfs_mem provider is
restarted, which would cause fatal loss of access to the storage device
for the modem.

The suggestion is therefore to link the rmtfs_mem to its associated
remote processor instance and control it based on the availability of
the rmtfs_mem implementation.

Signed-off-by: Bjorn Andersson 
[sibis: Added qmi lookup for Remote file system service]
Signed-off-by: Sibi Sankar 
---

The currently implemented workaround in the Linaro QCOMLT releases is to
blacklist the qcom_q6v5_pil kernel module and load this explicitly after rmtfs
has been started.

With this patch the modem module can be loaded automatically by the
platform_bus and will only be booted as the rmtfs becomes available. Performing
actions such as upgrading (and restarting) the rmtfs service will cause the
modem to automatically restart and hence continue to function after the
upgrade.

v2:
  Remove rproc_boot/shutdown from rmtfs_mem open/release and add
  qmi lookup for Remote file system service to address Brian's
  race concerns.

 .../reserved-memory/qcom,rmtfs-mem.txt|  7 ++
 drivers/remoteproc/qcom_q6v5_pil.c|  1 +
 drivers/soc/qcom/Kconfig  |  2 +
 drivers/soc/qcom/rmtfs_mem.c  | 65 ++-
 4 files changed, 72 insertions(+), 3 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt 
b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt
index 8562ba1dce69..95b209e7f5d1 100644
--- a/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt
+++ b/Documentation/devicetree/bindings/reserved-memory/qcom,rmtfs-mem.txt
@@ -32,6 +32,13 @@ access block device data using the Remote Filesystem 
protocol.
Value type: 
Definition: vmid of the remote processor, to set up memory protection.
 
+- rproc:
+   Usage: optional
+   Value type: 
+   Definition: reference to a remoteproc node, that should be powered up
+   while the remote file system memory instance is ready to
+   handle requests from the remote subsystem.
+
 = EXAMPLE
 The following example shows the remote filesystem memory setup for APQ8016,
 with the rmtfs region for the Hexagon DSP (id #1) located at 0x8670.
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c 
b/drivers/remoteproc/qcom_q6v5_pil.c
index d7a4b9eca5d2..1445a38e8b34 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -1142,6 +1142,7 @@ static int q6v5_probe(struct platform_device *pdev)
qproc = (struct q6v5 *)rproc->priv;
qproc->dev = &pdev->dev;
qproc->rproc = rproc;
+   rproc->auto_boot = false;
platform_set_drvdata(pdev, qproc);
 
ret = q6v5_init_mem(qproc, pdev);
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 8a7b8dea6990..4e3345944325 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -86,7 +86,9 @@ config QCOM_QMI_HELPERS
 config QCOM_RMTFS_MEM
tristate "Qualcomm Remote Filesystem memory driver"
depends on ARCH_QCOM
+   depends on REMOTEPROC
select QCOM_SCM
+   select QCOM_QMI_HELPERS
help
  The Qualcomm remote filesystem memory driver is used for allocating
  and exposing regions of shared memory with remote processors for the
diff --git a/drivers/soc/qcom/rmtfs_mem.c b/drivers/soc/qcom/rmtfs_mem.c
index 97bb5989aa21..757e30083f67 100644
--- a/drivers/soc/qcom/rmtfs_mem.c
+++ b/drivers/soc/qcom/rmtfs_mem.c
@@ -18,11 +18,13 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 #define QCOM_RMTFS_MEM_DEV_MAX (MINORMASK + 1)
 
@@ -31,6 +33,7 @@ static dev_t qcom_rmtfs_mem_major;
 struct qcom_rmtfs_mem {
struct device dev;
struct cdev cdev;
+   struct qmi_handle rmtfs_hdl;
 
void *base;
phys_addr_t addr;
@@ -39,6 +42,8 @@ struct qcom_rmtfs_mem {
unsigned int client_id;
 
unsigned int perms;
+
+   struct rproc *rproc;
 };
 
 static ssize_t qcom_rmtfs_mem_show(struct device *dev,
@@ -141,6 +146,36 @@ static const struct file_operations qcom_rmtfs_mem_fops = {
.llseek = default_llseek,
 };
 
+static int rmtfs_new_server(struct qmi_handle *qmi,
+struct qmi_service *service)
+{
+   int ret = 0;
+   struct qcom_rmtfs_mem *rmtfs_mem = container_of(qmi,
+   struct qcom_rmtfs_mem,
+   rmtfs_hdl);

[PATCH V7 7/8] dt-bindings: timer: gx6605s SOC timer

 - Dt-bindings doc for gx6605s SOC's system timer.

Signed-off-by: Guo Ren 
Reviewed-by: Rob Herring 
---
 .../bindings/timer/csky,gx6605s-timer.txt  | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt

diff --git a/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt 
b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
new file mode 100644
index 000..6b04344
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
@@ -0,0 +1,42 @@
+=
+gx6605s SOC Timer
+=
+
+The timer is used in gx6605s soc as system timer and the driver
+contain clk event and clk source.
+
+==
+timer node bindings definition
+==
+
+   Description: Describes gx6605s SOC timer
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,gx6605s-timer"
+   - reg
+   Usage: required
+   Value type: 
+   Definition:  in soc from cpu view
+   - clocks
+   Usage: required
+   Value type: phandle + clock specifier cells
+   Definition: must be input clk node
+   - interrupt
+   Usage: required
+   Value type: 
+   Definition: must be timer irq num defined by soc
+
+Examples:
+-
+
+   timer0: timer@20a000 {
+   compatible = "csky,gx6605s-timer";
+   reg = <0x0020a000 0x400>;
+   clocks = <&dummy_apb_clk>;
+   interrupts = <10>;
+   interrupt-parent = <&intc>;
+   };
-- 
2.7.4

[PATCH V7 4/8] dt-bindings: timer: C-SKY Multi-processor timer

Dt-bingdings doc for C-SKY SMP system setting.

Changelog:
 - Drop the interrupt-parent.

Signed-off-by: Guo Ren 
---
 .../devicetree/bindings/timer/csky,mptimer.txt | 42 ++
 1 file changed, 42 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/timer/csky,mptimer.txt

diff --git a/Documentation/devicetree/bindings/timer/csky,mptimer.txt 
b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
new file mode 100644
index 000..15cfec0
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
@@ -0,0 +1,42 @@
+
+C-SKY Multi-processors Timer
+
+
+C-SKY multi-processors timer is designed for C-SKY SMP system and the
+regs is accessed by cpu co-processor 4 registers with mtcr/mfcr.
+
+ - PTIM_CTLR "cr<0, 14>" Control reg to start reset timer.
+ - PTIM_TSR  "cr<1, 14>" Interrupt cleanup status reg.
+ - PTIM_CCVR "cr<3, 14>" Current counter value reg.
+ - PTIM_LVR  "cr<6, 14>" Window value reg to triger next event.
+
+==
+timer node bindings definition
+==
+
+   Description: Describes SMP timer
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,mptimer"
+   - clocks
+   Usage: required
+   Value type: 
+   Definition: must be input clk node
+   - interrupts
+   Usage: required
+   Value type: 
+   Definition: must be timer irq num defined by soc
+
+Examples:
+-
+
+   timer: timer {
+   compatible = "csky,mptimer";
+   clocks = <&dummy_apb_clk>;
+   interrupts = <16>;
+   interrupt-parent = <&intc>;
+   };
-- 
2.7.4

[PATCH V7 5/8] dt-bindings: interrupt-controller: C-SKY APB intc

 - Dt-bindings doc about C-SKY apb bus interrupt controller.

Signed-off-by: Guo Ren 
Reviewed-by: Rob Herring 
---
 .../interrupt-controller/csky,apb-intc.txt | 62 ++
 1 file changed, 62 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
new file mode 100644
index 000..44286dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
@@ -0,0 +1,62 @@
+==
+C-SKY APB Interrupt Controller
+==
+
+C-SKY APB Interrupt Controller is a simple soc interrupt controller
+on the apb bus and we only use it as root irq controller.
+
+ - csky,apb-intc is used in a lot of csky fpgas and socs, it support 64 irq 
nums.
+ - csky,dual-apb-intc consists of 2 apb-intc and 128 irq nums supported.
+ - csky,gx6605s-intc is gx6605s soc internal irq interrupt controller, 64 irq 
nums.
+
+=
+intc node bindings definition
+=
+
+   Description: Describes APB interrupt controller
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,apb-intc"
+   "csky,dual-apb-intc"
+   "csky,gx6605s-intc"
+   - #interrupt-cells
+   Usage: required
+   Value type: 
+   Definition: must be <1>
+   - reg
+   Usage: required
+   Value type: 
+   Definition:  in soc from cpu view
+   - interrupt-controller:
+   Usage: required
+   - csky,support-pulse-signal:
+   Usage: select
+   Description: to support pulse signal flag
+
+Examples:
+-
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,apb-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,dual-apb-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
+
+   intc: interrupt-controller@50 {
+   compatible = "csky,gx6605s-intc";
+   #interrupt-cells = <1>;
+   reg = <0x0050 0x400>;
+   interrupt-controller;
+   };
-- 
2.7.4

[PATCH V7 2/8] dt-bindings: interrupt-controller: C-SKY SMP intc

Dt-bindings doc about C-SKY Multi-processors interrupt controller.

Changelog:
 - Should be: '#interrupt-cells' not 'interrupt-cells'

Signed-off-by: Guo Ren 
---
 .../bindings/interrupt-controller/csky,mpintc.txt  | 40 ++
 1 file changed, 40 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt 
b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
new file mode 100644
index 000..ab921f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt
@@ -0,0 +1,40 @@
+===
+C-SKY Multi-processors Interrupt Controller
+===
+
+C-SKY Multi-processors Interrupt Controller is designed for ck807/ck810/ck860
+SMP soc, and it also could be used in non-SMP system.
+
+Interrupt number definition:
+
+  0-15  : software irq, and we use 15 as our IPI_IRQ.
+ 16-31  : private  irq, and we use 16 as the co-processor timer.
+ 31-1024: common irq for soc ip.
+
+=
+intc node bindings definition
+=
+
+   Description: Describes SMP interrupt controller
+
+   PROPERTIES
+
+   - compatible
+   Usage: required
+   Value type: 
+   Definition: must be "csky,mpintc"
+   - #interrupt-cells
+   Usage: required
+   Value type: 
+   Definition: must be <1>
+   - interrupt-controller:
+   Usage: required
+
+Examples:
+-
+
+   intc: interrupt-controller {
+   compatible = "csky,mpintc";
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   };
-- 
2.7.4

[PATCH V7 1/8] irqchip: add C-SKY SMP interrupt controller

 - Irq-csky-mpintc is C-SKY smp system interrupt controller and it
   could support 16 soft irqs, 16 private irqs, and 992 max common
   irqs.

Changelog:
 - Move IPI_IRQ into the driver
 - Remove irq_set_default_host() and use set_ipi_irq_mapping()
 - Change name with upstream feed-back
 - Change irq map, reserve soft_irq & private_irq space
 - Add License and Copyright
 - Support set_affinity for irq balance in SMP

Signed-off-by: Guo Ren 
---
 drivers/irqchip/Kconfig   |   8 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-csky-mpintc.c | 195 ++
 3 files changed, 204 insertions(+)
 create mode 100644 drivers/irqchip/irq-csky-mpintc.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 383e7b7..92e1c20 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -371,6 +371,14 @@ config QCOM_PDC
  Power Domain Controller driver to manage and configure wakeup
  IRQs for Qualcomm Technologies Inc (QTI) mobile chips.
 
+config CSKY_MPINTC
+   bool "C-SKY Multi Processor Interrupt Controller"
+   depends on CSKY
+   help
+ Say yes here to enable C-SKY SMP interrupt controller driver used
+ for C-SKY SMP system. In fact it's not mmio map and it use ld/st
+ to visit the controller's register inside CPU.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index fbd1ec8..6b739ea 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -87,4 +87,5 @@ obj-$(CONFIG_MESON_IRQ_GPIO)  += irq-meson-gpio.o
 obj-$(CONFIG_GOLDFISH_PIC) += irq-goldfish-pic.o
 obj-$(CONFIG_NDS32)+= irq-ativic32.o
 obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
+obj-$(CONFIG_CSKY_MPINTC)  += irq-csky-mpintc.o
 obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
diff --git a/drivers/irqchip/irq-csky-mpintc.c 
b/drivers/irqchip/irq-csky-mpintc.c
new file mode 100644
index 000..2b424d27
--- /dev/null
+++ b/drivers/irqchip/irq-csky-mpintc.c
@@ -0,0 +1,195 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct irq_domain *root_domain;
+static void __iomem *INTCG_base;
+static void __iomem *INTCL_base;
+
+#define IPI_IRQ15
+#define INTC_IRQS  256
+#define COMM_IRQ_BASE  32
+
+#define INTCG_SIZE 0x8000
+#define INTCL_SIZE 0x1000
+#define INTC_SIZE  INTCL_SIZE*nr_cpu_ids + INTCG_SIZE
+
+#define INTCG_ICTLR0x0
+#define INTCG_CICFGR   0x100
+#define INTCG_CIDSTR   0x1000
+
+#define INTCL_PICTLR   0x0
+#define INTCL_SIGR 0x60
+#define INTCL_HPPIR0x68
+#define INTCL_RDYIR0x6c
+#define INTCL_SENR 0xa0
+#define INTCL_CENR 0xa4
+#define INTCL_CACR 0xb4
+
+static DEFINE_PER_CPU(void __iomem *, intcl_reg);
+
+static void csky_mpintc_handler(struct pt_regs *regs)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   do {
+   handle_domain_irq(root_domain,
+ readl_relaxed(reg_base + INTCL_RDYIR),
+ regs);
+   } while (readl_relaxed(reg_base + INTCL_HPPIR) & BIT(31));
+}
+
+static void csky_mpintc_enable(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_SENR);
+}
+
+static void csky_mpintc_disable(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_CENR);
+}
+
+static void csky_mpintc_eoi(struct irq_data *d)
+{
+   void __iomem *reg_base = this_cpu_read(intcl_reg);
+
+   writel_relaxed(d->hwirq, reg_base + INTCL_CACR);
+}
+
+#ifdef CONFIG_SMP
+static int csky_irq_set_affinity(struct irq_data *d,
+const struct cpumask *mask_val,
+bool force)
+{
+   unsigned int cpu;
+   unsigned int offset = 4 * (d->hwirq - COMM_IRQ_BASE);
+
+   if (!force)
+   cpu = cpumask_any_and(mask_val, cpu_online_mask);
+   else
+   cpu = cpumask_first(mask_val);
+
+   if (cpu >= nr_cpu_ids)
+   return -EINVAL;
+
+   /* Enable interrupt destination */
+   cpu |= BIT(31);
+
+   writel_relaxed(cpu, INTCG_base + INTCG_CIDSTR + offset);
+
+   irq_data_update_effective_affinity(d, cpumask_of(cpu));
+
+   return IRQ_SET_MASK_OK_DONE;
+}
+#endif
+
+static struct irq_chip csky_irq_chip = {
+   .name   = "C-SKY SMP Intc",
+   .irq_eoi= csky_mpintc_eoi,
+   .irq_enable = csky_mpintc_enable,
+   .irq_disable= csky_mpintc_disable,
+#ifdef CONFIG_SMP
+   .irq_set_affinity = csky_irq_set_affinity,
+#endif
+};
+
+sta

[PATCH V7 8/8] clocksource: add gx6605s SOC system timer

Changelog:
 - Add License and Copyright
 - Use timer-of framework
 - Change name with upstream feedback
 - Use clksource_mmio framework

Signed-off-by: Guo Ren 
---
 drivers/clocksource/Kconfig |   8 ++
 drivers/clocksource/Makefile|   1 +
 drivers/clocksource/timer-gx6605s.c | 150 
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/clocksource/timer-gx6605s.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a28043f..0f38acc 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -628,4 +628,12 @@ config CSKY_MPTIMER
  Say yes here to enable C-SKY SMP timer driver used for C-SKY SMP
  system.
 
+config GX6605S_TIMER
+   bool "Gx6605s SOC system timer driver"
+   depends on CSKY
+   select CLKSRC_MMIO
+   select TIMER_OF
+   help
+ This option enables support for gx6605s SOC's timer.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 848c676..7a1b0f4 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_X86_NUMACHIP)+= numachip.o
 obj-$(CONFIG_ATCPIT100_TIMER)  += timer-atcpit100.o
 obj-$(CONFIG_RISCV_TIMER)  += riscv_timer.o
 obj-$(CONFIG_CSKY_MPTIMER) += csky_mptimer.o
+obj-$(CONFIG_GX6605S_TIMER)+= timer-gx6605s.o
diff --git a/drivers/clocksource/timer-gx6605s.c 
b/drivers/clocksource/timer-gx6605s.c
new file mode 100644
index 000..10194c9
--- /dev/null
+++ b/drivers/clocksource/timer-gx6605s.c
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+
+#include "timer-of.h"
+
+#define CLKSRC_OFFSET  0x40
+
+#define TIMER_STATUS   0x00
+#define TIMER_VALUE0x04
+#define TIMER_CONTRL   0x10
+#define TIMER_CONFIG   0x20
+#define TIMER_DIV  0x24
+#define TIMER_INI  0x28
+
+#define GX6605S_STATUS_CLR BIT(0)
+#define GX6605S_CONTRL_RST BIT(0)
+#define GX6605S_CONTRL_START   BIT(1)
+#define GX6605S_CONFIG_EN  BIT(0)
+#define GX6605S_CONFIG_IRQ_EN  BIT(1)
+
+static irqreturn_t gx6605s_timer_interrupt(int irq, void *dev)
+{
+   struct clock_event_device *ce = (struct clock_event_device *) dev;
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   writel_relaxed(GX6605S_STATUS_CLR, base + TIMER_STATUS);
+
+   ce->event_handler(ce);
+
+   return IRQ_HANDLED;
+}
+
+static int gx6605s_timer_set_oneshot(struct clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   /* reset and stop counter */
+   writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+   /* enable with irq and start */
+   writel_relaxed(GX6605S_CONFIG_EN | GX6605S_CONFIG_IRQ_EN, base + 
TIMER_CONFIG);
+
+   return 0;
+}
+
+static int gx6605s_timer_set_next_event(unsigned long delta, struct 
clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   /* use reset to pause timer */
+   writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+   /* config next timeout value */
+   writel_relaxed(ULONG_MAX - delta, base + TIMER_INI);
+   writel_relaxed(GX6605S_CONTRL_START, base + TIMER_CONTRL);
+
+   return 0;
+}
+
+static int gx6605s_timer_shutdown(struct clock_event_device *ce)
+{
+   void __iomem *base = timer_of_base(to_timer_of(ce));
+
+   writel_relaxed(0, base + TIMER_CONTRL);
+   writel_relaxed(0, base + TIMER_CONFIG);
+
+   return 0;
+}
+
+static struct timer_of to = {
+   .flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
+   .clkevt = {
+   .rating = 300,
+   .features   = CLOCK_EVT_FEAT_DYNIRQ |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_state_shutdown = gx6605s_timer_shutdown,
+   .set_state_oneshot  = gx6605s_timer_set_oneshot,
+   .set_next_event = gx6605s_timer_set_next_event,
+   .cpumask= cpu_possible_mask,
+   },
+   .of_irq = {
+   .handler= gx6605s_timer_interrupt,
+   .flags  = IRQF_TIMER | IRQF_IRQPOLL,
+   },
+};
+
+static u64 notrace gx6605s_sched_clock_read(void)
+{
+   void __iomem *base;
+
+   base = timer_of_base(&to) + CLKSRC_OFFSET;
+
+   return (u64) readl_relaxed(base + TIMER_VALUE);
+}
+
+static void gx6605s_clkevt_init(void __iomem *base)
+{
+   writel_relaxed(0, base + TIMER_DIV);
+   writel_relaxed(0, base + TIMER_CONFIG);
+
+   clockevents_config_and_register(&to.clkevt, timer_of_rate(&to), 2, 
ULONG_MAX);
+}
+
+static int gx6605s_clksrc_init(void __iomem *base)
+{
+   writel_relaxed(0, base + TIMER_DIV);
+   writel_relaxed(0, base + TIMER_INI);
+
+   w

[PATCH V7 6/8] irqchip: add C-SKY APB bus interrupt controller

 - irq-csky-apb-intc is a simple SOC interrupt controller which is
   used in a lot of C-SKY CPU SOC products.

Changelog:
 - use "bool ret" instead of "int ret"
 - add support-pulse-signal in irq-csky-apb-intc.c
 - change name with upstream feed-back
 - add INTC_IFR to clear irq-pending
 - remove CSKY_VECIRQ_LEGENCY
 - change to generic irq chip framework
 - add License and Copyright
 - use irq_domain_add_linear instead of leagcy

Signed-off-by: Guo Ren 
---
 drivers/irqchip/Kconfig |   8 ++
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/irq-csky-apb-intc.c | 260 
 3 files changed, 269 insertions(+)
 create mode 100644 drivers/irqchip/irq-csky-apb-intc.c

diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 92e1c20..bf12549 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -379,6 +379,14 @@ config CSKY_MPINTC
  for C-SKY SMP system. In fact it's not mmio map and it use ld/st
  to visit the controller's register inside CPU.
 
+config CSKY_APB_INTC
+   bool "C-SKY APB Interrupt Controller"
+   depends on CSKY
+   help
+ Say yes here to enable C-SKY APB interrupt controller driver used
+ by C-SKY single core SOC system. It use mmio map apb-bus to visit
+ the controller's register.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 6b739ea..72eaf53 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -88,4 +88,5 @@ obj-$(CONFIG_GOLDFISH_PIC)+= irq-goldfish-pic.o
 obj-$(CONFIG_NDS32)+= irq-ativic32.o
 obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
 obj-$(CONFIG_CSKY_MPINTC)  += irq-csky-mpintc.o
+obj-$(CONFIG_CSKY_APB_INTC)+= irq-csky-apb-intc.o
 obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
diff --git a/drivers/irqchip/irq-csky-apb-intc.c 
b/drivers/irqchip/irq-csky-apb-intc.c
new file mode 100644
index 000..cfe32a7
--- /dev/null
+++ b/drivers/irqchip/irq-csky-apb-intc.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define INTC_IRQS  64
+
+#define CK_INTC_ICR0x00
+#define CK_INTC_PEN31_00   0x14
+#define CK_INTC_PEN63_32   0x2c
+#define CK_INTC_NEN31_00   0x10
+#define CK_INTC_NEN63_32   0x28
+#define CK_INTC_SOURCE 0x40
+#define CK_INTC_DUAL_BASE  0x100
+
+#define GX_INTC_PEN31_00   0x00
+#define GX_INTC_PEN63_32   0x04
+#define GX_INTC_NEN31_00   0x40
+#define GX_INTC_NEN63_32   0x44
+#define GX_INTC_NMASK31_00 0x50
+#define GX_INTC_NMASK63_32 0x54
+#define GX_INTC_SOURCE 0x60
+
+static void __iomem *reg_base;
+static struct irq_domain *root_domain;
+
+static int nr_irq = INTC_IRQS;
+
+/*
+ * When controller support pulse signal, the PEN_reg will hold on signal
+ * without software trigger.
+ *
+ * So, to support pulse signal we need to clear IFR_reg and the address of
+ * IFR_offset is NEN_offset - 8.
+ */
+static void irq_ck_mask_set_bit(struct irq_data *d)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+   struct irq_chip_type *ct = irq_data_get_chip_type(d);
+   unsigned long ifr = ct->regs.mask - 8;
+   u32 mask = d->mask;
+
+   irq_gc_lock(gc);
+   *ct->mask_cache |= mask;
+   irq_reg_writel(gc, *ct->mask_cache, ct->regs.mask);
+   irq_reg_writel(gc, irq_reg_readl(gc, ifr) & ~mask, ifr);
+   irq_gc_unlock(gc);
+}
+
+static void __init ck_set_gc(struct device_node *node, void __iomem *reg_base,
+u32 mask_reg, u32 irq_base)
+{
+   struct irq_chip_generic *gc;
+
+   gc = irq_get_domain_generic_chip(root_domain, irq_base);
+   gc->reg_base = reg_base;
+   gc->chip_types[0].regs.mask = mask_reg;
+   gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
+   gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
+
+   if (of_find_property(node, "csky,support-pulse-signal", NULL))
+   gc->chip_types[0].chip.irq_unmask = irq_ck_mask_set_bit;
+}
+
+static inline u32 build_channel_val(u32 idx, u32 magic)
+{
+   u32 res;
+
+   /*
+* Set the same index for each channel
+*/
+   res = idx | (idx << 8) | (idx << 16) | (idx << 24);
+
+   /*
+* Set the channel magic number in descending order.
+* The magic is 0x00010203 for ck-intc
+* The magic is 0x03020100 for gx6605s-intc
+*/
+   return res | magic;
+}
+
+static inline void setup_irq_channel(u32 magic, void __iomem *reg_addr)
+{
+   u32 i;
+
+   /* Setup 64 channel slots */
+   for (i = 0; i < INTC_IRQS; i += 4) {
+   writel_relaxed(build_channel_val(i, magic), reg_addr + i);
+

[PATCH V7 3/8] clocksource: add C-SKY SMP timer

This timer is used by SMP system and use mfcr/mtcr instruction
to access the regs.

Changelog:
 - Remove #define CPUHP_AP_CSKY_TIMER_STARTING
 - Add CPUHP_AP_CSKY_TIMER_STARTING in cpuhotplug.h
 - Support csky mp timer alpha version.
 - Just use low-counter with 32bit width as clocksource.
 - Coding convention with upstream feed-back.

Signed-off-by: Guo Ren 
---
 drivers/clocksource/Kconfig|   8 ++
 drivers/clocksource/Makefile   |   1 +
 drivers/clocksource/csky_mptimer.c | 176 +
 include/linux/cpuhotplug.h |   1 +
 4 files changed, 186 insertions(+)
 create mode 100644 drivers/clocksource/csky_mptimer.c

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a11f4ba..a28043f 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -620,4 +620,12 @@ config RISCV_TIMER
  is accessed via both the SBI and the rdcycle instruction.  This is
  required for all RISC-V systems.
 
+config CSKY_MPTIMER
+   bool "C-SKY Multi Processor Timer"
+   depends on CSKY
+   select TIMER_OF
+   help
+ Say yes here to enable C-SKY SMP timer driver used for C-SKY SMP
+ system.
+
 endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index db51b24..848c676 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -79,3 +79,4 @@ obj-$(CONFIG_CLKSRC_ST_LPC)   += clksrc_st_lpc.o
 obj-$(CONFIG_X86_NUMACHIP) += numachip.o
 obj-$(CONFIG_ATCPIT100_TIMER)  += timer-atcpit100.o
 obj-$(CONFIG_RISCV_TIMER)  += riscv_timer.o
+obj-$(CONFIG_CSKY_MPTIMER) += csky_mptimer.o
diff --git a/drivers/clocksource/csky_mptimer.c 
b/drivers/clocksource/csky_mptimer.c
new file mode 100644
index 000..9dc3cfb
--- /dev/null
+++ b/drivers/clocksource/csky_mptimer.c
@@ -0,0 +1,176 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "timer-of.h"
+
+#define PTIM_CCVR  "cr<3, 14>"
+#define PTIM_CTLR  "cr<0, 14>"
+#define PTIM_LVR   "cr<6, 14>"
+#define PTIM_TSR   "cr<1, 14>"
+
+static int csky_mptimer_set_next_event(unsigned long delta, struct 
clock_event_device *ce)
+{
+   mtcr(PTIM_LVR, delta);
+
+   return 0;
+}
+
+static int csky_mptimer_shutdown(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 0);
+
+   return 0;
+}
+
+static int csky_mptimer_oneshot(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 1);
+
+   return 0;
+}
+
+static int csky_mptimer_oneshot_stopped(struct clock_event_device *ce)
+{
+   mtcr(PTIM_CTLR, 0);
+
+   return 0;
+}
+
+static DEFINE_PER_CPU(struct timer_of, csky_to) = {
+   .flags  = TIMER_OF_CLOCK,
+   .clkevt = {
+   .rating = 300,
+   .features   = CLOCK_EVT_FEAT_PERCPU |
+ CLOCK_EVT_FEAT_ONESHOT,
+   .set_state_shutdown = csky_mptimer_shutdown,
+   .set_state_oneshot  = csky_mptimer_oneshot,
+   .set_state_oneshot_stopped  = csky_mptimer_oneshot_stopped,
+   .set_next_event = csky_mptimer_set_next_event,
+   },
+   .of_irq = {
+   .flags  = IRQF_TIMER,
+   .percpu = 1,
+   },
+};
+
+static irqreturn_t timer_interrupt(int irq, void *dev)
+{
+   struct timer_of *to = this_cpu_ptr(&csky_to);
+
+   mtcr(PTIM_TSR, 0);
+
+   to->clkevt.event_handler(&to->clkevt);
+
+   return IRQ_HANDLED;
+}
+
+/*
+ * clock event for percpu
+ */
+static int csky_mptimer_starting_cpu(unsigned int cpu)
+{
+   struct timer_of *to = per_cpu_ptr(&csky_to, cpu);
+
+   to->clkevt.cpumask = cpumask_of(cpu);
+
+   clockevents_config_and_register(&to->clkevt, timer_of_rate(to), 2, 
ULONG_MAX);
+
+   enable_percpu_irq(timer_of_irq(to), 0);
+
+   return 0;
+}
+
+static int csky_mptimer_dying_cpu(unsigned int cpu)
+{
+   struct timer_of *to = per_cpu_ptr(&csky_to, cpu);
+
+   disable_percpu_irq(timer_of_irq(to));
+
+   return 0;
+}
+
+/*
+ * clock source
+ */
+static u64 sched_clock_read(void)
+{
+   return (u64) mfcr(PTIM_CCVR);
+}
+
+static u64 clksrc_read(struct clocksource *c)
+{
+   return (u64) mfcr(PTIM_CCVR);
+}
+
+struct clocksource csky_clocksource = {
+   .name   = "csky",
+   .rating = 400,
+   .mask   = CLOCKSOURCE_MASK(32),
+   .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
+   .read   = clksrc_read,
+};
+
+static int __init csky_mptimer_init(struct device_node *np)
+{
+   int ret, cpu;
+   struct timer_of *to;
+   int rate = 0;
+   int irq  = 0;
+
+   /*
+* Csky_mptimer is designed for C-SKY SMP multi-processors

[PATCH] MAINTAINERS: MIPS/LOONGSON2 ARCHITECTURE - Use the normal wildcard style

2018-09-30 Thread Joe Perches

Neither git nor get_maintainer understands the curly brace style.

Signed-off-by: Joe Perches 
---
 MAINTAINERS | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c62b724bb60..f6ab4f3bccfb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9770,7 +9770,8 @@ MIPS/LOONGSON2 ARCHITECTURE
 M: Jiaxun Yang 
 L: linux-m...@linux-mips.org
 S: Maintained
-F: arch/mips/loongson64/*{2e/2f}*
+F: arch/mips/loongson64/fuloong-2e/
+F: arch/mips/loongson64/lemote-2f/
 F: arch/mips/include/asm/mach-loongson64/
 F: drivers/*/*loongson2*
 F: drivers/*/*/*loongson2*

RE!!

2018-09-30 Thread Ms CHIANG Lai Yuen JP

I will want you to partner me in a business...

---
This email has been checked for viruses by AVG.
https://www.avg.com

Re: [RFC/RFT PATCH v1 0/9] mtd: fsl: quadspi: Fixes for fsl-quadspi.c driver (vybrid HW)

2018-09-30 Thread Lukasz Majewski

Hi Boris,

> Hi Lukasz,
> 
> On Sat, 29 Sep 2018 23:02:40 +0200
> Lukasz Majewski  wrote:
> 
> > > Talking about that, can you try to port your fixes on top of
> > > Frieder's patchset? I'm pretty sure some bug fixes are irrelevant
> > > after the migration to spi-mem (patch 1, 3, 4, 5, 6, 7 and 9
> > > should be dropped I think).
> > 
> > The problem is that Frieder's patch is using IP command mode for
> > transfers smaller than AHB RX fifo size.
> > This according to the comment in the current driver is broken in HW
> > for Vybrid (so this is a regression).  
> 
> Why not fixing that in the new driver?

I did not say that I will not fix it in the new driver :-)

The problem is that I'm waiting for NXP's community reply - to get some
more info regarding the bug.

> 
> > 
> > I'm also wondering if other users of vf610 based boards experience
> > issues with QSPI?  
> 
> Are you sure the 4 I/O lines are wired on your design? 

This is a somewhat special case.

There are two identical SPI-NOR memories: one with QUAD lines connected
and second only for DUAL due to HW design decision.

> Anyway, if it's
> a bug that only hurts vf610, you should mask quad modes in ->hwcaps
> (or patch fsl_qspi_supports_op() in the new driver), not change the
> SPI NOR definition.

Yes, this was also pointed out by Cyrille - and yes, I do agree that I
shouldn't mask it.

> 
> > 
> > In my case, after running the UBI/UBIFS tests (on the original and
> > new driver without those "fixes") I cannot mount the volume after
> > creation as the header is wrongly read.  
> 
> I'm not denying this fact, I'm just saying, now that you've found
> where the issue comes from, you can also port the fix to the new
> driver.

Yes, as the old driver is now in a "good enough" shape (though I don't
know the exact HW bug reason) - the code can be ported to the new
driver.

> 
> Regards,
> 
> Boris
> 
> __
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de


pgpCKjrkSJNUm.pgp
Description: OpenPGP digital signature

Re: Linux 4.19-rc4 released, an apology, and a maintainership note

2018-09-30 Thread Luke Kenneth Casson Leighton

On Sun, Sep 30, 2018 at 3:07 PM, Martin Steigerwald  wrote:

> l...@lkcl.net - 30.09.18, 14:09:
>>  the third is how UNICEF trains teachers to treat children as human
>> beings.
>
> During releasing a lot of limiting "stuff" I found that probably nothing
> written or said can hurt my feelings unless I let it do so or even…
> unless I choose (!) to feel hurt about it. So at times I am clear about
> this, I´d say: "I have chosen to feel hurt about what you did."

 it's interesting to me to note that you use the word "releasing".
that's a keyword that i recognise from energy work, which,
surprisingly is increasingly being recognised and used by individuals
and businesses all over the world.  it seems that people are beginning
to recognise it's actually effective and no longer associated with
cloud-cuckoo-land "detached-from-reality" new age hippies.  i was
going to [privately] recommend someone who specifically works with
businesses and organisations to linus: i haven't heard from him yet.

> However in this human experience a lot of people, including myself,
> still hold on to a lot of limiting "stuff" which invites feeling hurt.
> We, as humankind, have a history of hurting each other.

 this is why i recommended http://pndc.com in my earlier post.  one of
the documents there points out that due to our still-remaining
"survival" instincts from millenia of evolution, words *literally* can
have the same effect on us as if we were actually physically and i
MEAN literally physically being attacked... [*IF WE CHOOSE* to be].

 where people have not yet learned the difference between "that was a
bad thing to do" and "YOU are bad" (and interpret those as being
exactly the same thing), we have a compound effect.  one person says
"that's a really dumb piece of code", the person hearing it interprets
it as "you're a fucking idiot", and has a LITERAL physical response to
the words [that you didn't actually say] as if you'd just punched them
in the mouth.

> During this releasing work I also learned about two key ingredients of
> successful relationships: Harmlessness and mutuality. I opted out of the
> hurting cycle as best I can. And so I choose to write in a way that
> moves around what from my own experience of feeling hurt I know could
> hurt others. I choose to write in a harmless way so to say. While still
> aiming to bring my point across. A very important ingredient for this is
> to write from my own experience.

 yes, absolutely.  that's pretty much word-for-word exactly the advice
given on the _other_ resource i recommended to linus,
http://www.crnhq.org/.  let me find it ok, "appropriate
assertiveness": http://www.crnhq.org/CR-Kit.aspx?rw=c#assertiveness

 quote:

 " The essence of Appropriate Assertiveness is being able to state
your case without arousing the defences of the other person. The
secret of success lies in saying how it is for you rather than what
they should or shouldn't do. "The way I see it...", attached to your
assertive statement, helps. A skilled "I" statement goes even
further."

 and it goes on from there.

> Of course others can feel hurt about something I would not feel hurt
> about and I may not be aware that the other might feel hurt about. That
> is why in such a case it is important to give and receive feedback.
> Still when writing from my own experience without saying that anything
> is wrong with the other, it appears to be unlikely to trigger hurt. That
> is at least my experience so far.

 exactly.  i believe you may be interested to know of the next phases
in that: the crnhq's "appropriate assertiveness" advice has a really
good template for keeping things to "I", and at the same time
successfully getting the point across.  i won't quote all of it to
you.

 i believe crhnq is written by a guy who has stopped warring tribes
from centuries of killing each other (and i don't mean
metaphorically), so it's clearly effective.

 caveat: my only concern about these kinds of ways of thinking is,
sometimes you do actually genuinely need to give people a short, sharp
shock: that's part of NLP.  *after* the shock, you can be "nice" to
them: where previously they were pathologically unable to listen, a
shock gets them out of the psychosis that they were in.  it's also a
recognised medical treatment for people who are hysterical in disaster
/ emergency scenarios to shock them out of their screaming fit.  note:
not recommended without proper training!!

l.

[PATCH] s390: vmlinux.lds: move JUMP_TABLE_DATA into output section

2018-09-30 Thread Ard Biesheuvel

Commit e872267b8bcbb179 ("jump_table: move entries into ro_after_init
region") moved the __jump_table input section into the __ro_after_init
output section, but inadvertently put the macro in the wrong place in
the s390 linker script. Let's fix that.

Fixes: e872267b8bcbb179 ("jump_table: move entries into ro_after_init region")
Reported-by: Guenter Roeck 
Cc: Heiko Carstens 
Cc: Kees Cook 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Martin Schwidefsky 
Cc: Jessica Yu 
Cc: Peter Zijlstra 
Signed-off-by: Ard Biesheuvel 
---
 arch/s390/kernel/vmlinux.lds.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S
index 4042bbf3f9ad..457713f48734 100644
--- a/arch/s390/kernel/vmlinux.lds.S
+++ b/arch/s390/kernel/vmlinux.lds.S
@@ -64,9 +64,9 @@ SECTIONS
__start_ro_after_init = .;
.data..ro_after_init : {
 *(.data..ro_after_init)
+   JUMP_TABLE_DATA
}
EXCEPTION_TABLE(16)
-   JUMP_TABLE_DATA
. = ALIGN(PAGE_SIZE);
__end_ro_after_init = .;
 
-- 
2.17.1

Re: [PATCH] s390: vmlinux.lds: move JUMP_TABLE_DATA into output section

2018-09-30 Thread Kees Cook

On Sun, Sep 30, 2018 at 9:49 AM, Ard Biesheuvel
 wrote:
> Commit e872267b8bcbb179 ("jump_table: move entries into ro_after_init
> region") moved the __jump_table input section into the __ro_after_init
> output section, but inadvertently put the macro in the wrong place in
> the s390 linker script. Let's fix that.
>
> Fixes: e872267b8bcbb179 ("jump_table: move entries into ro_after_init region")
> Reported-by: Guenter Roeck 
> Cc: Heiko Carstens 
> Cc: Kees Cook 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Martin Schwidefsky 
> Cc: Jessica Yu 
> Cc: Peter Zijlstra 
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Kees Cook 

-Kees

> ---
>  arch/s390/kernel/vmlinux.lds.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S
> index 4042bbf3f9ad..457713f48734 100644
> --- a/arch/s390/kernel/vmlinux.lds.S
> +++ b/arch/s390/kernel/vmlinux.lds.S
> @@ -64,9 +64,9 @@ SECTIONS
> __start_ro_after_init = .;
> .data..ro_after_init : {
>  *(.data..ro_after_init)
> +   JUMP_TABLE_DATA
> }
> EXCEPTION_TABLE(16)
> -   JUMP_TABLE_DATA
> . = ALIGN(PAGE_SIZE);
> __end_ro_after_init = .;
>
> --
> 2.17.1
>



-- 
Kees Cook
Pixel Security

Re: [PATCH 3.16 000/131] 3.16.59-rc1 review

2018-09-30 Thread Ben Hutchings

On Sun, 2018-09-30 at 07:06 -0700, Guenter Roeck wrote:
> On 09/29/2018 02:43 PM, Ben Hutchings wrote:
> > This is the start of the stable review cycle for the 3.16.59 release.
> > There are 131 patches in this series, which will be posted as responses
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Mon Oct 01 21:43:06 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 139 pass: 139 fail: 0
> Qemu test results:
>   total: 217 pass: 217 fail: 0
> 
> Details are available at https://kerneltests.org/builders/.

Thanks for checking.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC




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

Re: [PATCH] s390: vmlinux.lds: move JUMP_TABLE_DATA into output section

On Sun, Sep 30, 2018 at 06:49:50PM +0200, Ard Biesheuvel wrote:
> Commit e872267b8bcbb179 ("jump_table: move entries into ro_after_init
> region") moved the __jump_table input section into the __ro_after_init
> output section, but inadvertently put the macro in the wrong place in
> the s390 linker script. Let's fix that.
> 
> Fixes: e872267b8bcbb179 ("jump_table: move entries into ro_after_init region")
> Reported-by: Guenter Roeck 
> Cc: Heiko Carstens 
> Cc: Kees Cook 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: Martin Schwidefsky 
> Cc: Jessica Yu 
> Cc: Peter Zijlstra 
> Signed-off-by: Ard Biesheuvel 

Tested-by: Guenter Roeck 

> ---
>  arch/s390/kernel/vmlinux.lds.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/s390/kernel/vmlinux.lds.S b/arch/s390/kernel/vmlinux.lds.S
> index 4042bbf3f9ad..457713f48734 100644
> --- a/arch/s390/kernel/vmlinux.lds.S
> +++ b/arch/s390/kernel/vmlinux.lds.S
> @@ -64,9 +64,9 @@ SECTIONS
>   __start_ro_after_init = .;
>   .data..ro_after_init : {
>*(.data..ro_after_init)
> + JUMP_TABLE_DATA
>   }
>   EXCEPTION_TABLE(16)
> - JUMP_TABLE_DATA
>   . = ALIGN(PAGE_SIZE);
>   __end_ro_after_init = .;
>  
> -- 
> 2.17.1
>

Re: [PATCH v2 05/11] arm64: dts: msm8916: Update coresight bindings for hardware ports

On Thu, Sep 27, 2018 at 09:18:06AM +0100, Suzuki K Poulose wrote:
> Hi Andy
> 
> On 09/12/2018 02:53 PM, Suzuki K Poulose wrote:
> >Switch to updated coresight bindings for hw ports
> >
> >Cc: Andy Gross 
> >Cc: David Brown 
> >Cc: Ivan T. Ivanov 
> >Cc: Mathieu Poirier 
> >Signed-off-by: Suzuki K Poulose 
> >---
> >Changes since v1:
> >  - Fixed TPIU port direction
> >  - Use better subject tag for the patch
> >---
> 
> 
> Please could you pull this and the patch for ARM (Patch 9/11)  ?
> 
> Suzuki

Done.  Thanks

[GIT PULL] pstore fix for v4.19-rc7

2018-09-30 Thread Kees Cook

Hi Greg,

Please pull this pstore fix for v4.19-rc7.

Thanks!

-Kees

The following changes since commit 831b624df1b420c8f9281ed1307a8db23afb72df:

  pstore: Fix incorrect persistent ram buffer mapping (2018-09-13 09:14:57 
-0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/pstore-v4.19-rc7

for you to fetch changes up to bac6f6cda206ad7cbe0c73c35e494377ce9c4749:

  pstore/ram: Fix failure-path memory leak in ramoops_init (2018-09-30 10:15:41 
-0700)


Fixes for v4.19-rc7

- Fix failure-path memory leak in ramoops_init (nixiaoming)


Kees Cook (1):
  pstore/ram: Fix failure-path memory leak in ramoops_init

 fs/pstore/ram.c | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

-- 
Kees Cook
Pixel Security

[PATCH] staging: rtlwifi: Removed unused define and code efuse_re_pg* from wifi.h

2018-09-30 Thread Rick Veens

The following:
 bool efuse_re_pg_sec1flag;
 u8 efuse_re_pg_data[8];
are not referenced anywhere in the rtlwifi code.

Signed-off-by: Rick Veens 
---
 drivers/staging/rtlwifi/wifi.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/staging/rtlwifi/wifi.h b/drivers/staging/rtlwifi/wifi.h
index a45f0eb..9cb6c79 100644
--- a/drivers/staging/rtlwifi/wifi.h
+++ b/drivers/staging/rtlwifi/wifi.h
@@ -1840,10 +1840,6 @@ struct rtl_efuse {
u8 efuse_map[2][EFUSE_MAX_LOGICAL_SIZE];
u16 efuse_usedbytes;
u8 efuse_usedpercentage;
-#ifdef EFUSE_REPG_WORKAROUND
-   bool efuse_re_pg_sec1flag;
-   u8 efuse_re_pg_data[8];
-#endif
 
u8 autoload_failflag;
u8 autoload_status;
-- 
2.1.4

Re: [PATCH] staging: rtlwifi: Removed unused define and code efuse_re_pg* from wifi.h

2018-09-30 Thread Joe Perches

On Sun, 2018-09-30 at 20:29 +0200, Rick Veens wrote:
> The following:
>  bool efuse_re_pg_sec1flag;
>  u8 efuse_re_pg_data[8];
> are not referenced anywhere in the rtlwifi code.
> 
> Signed-off-by: Rick Veens 
> ---
>  drivers/staging/rtlwifi/wifi.h | 4 

Presumably the equivalent uses in
drivers/net/wireless/realtek/rtlwifi/wifi.h
should be removed as well.

> diff --git a/drivers/staging/rtlwifi/wifi.h b/drivers/staging/rtlwifi/wifi.h
[]
> @@ -1840,10 +1840,6 @@ struct rtl_efuse {
>   u8 efuse_map[2][EFUSE_MAX_LOGICAL_SIZE];
>   u16 efuse_usedbytes;
>   u8 efuse_usedpercentage;
> -#ifdef EFUSE_REPG_WORKAROUND
> - bool efuse_re_pg_sec1flag;
> - u8 efuse_re_pg_data[8];
> -#endif
>  
>   u8 autoload_failflag;
>   u8 autoload_status;

[GIT PULL] Qualcomm ARM64 DT updates for 4.20

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git 
tags/qcom-arm64-for-4.20

for you to fetch changes up to 6db0483cf622fc690e32e0804f8b86061f13962a:

  Revert "dt-bindings: thermal: qcom-spmi-temp-alarm: Fix documentation of 
'reg'" (2018-09-30 12:59:52 -0500)


Qualcomm ARM64 Updates for v4.20

* Update Coresight for MSM8916
* Switch to use mailbox for smp2p and smd on MSM8996
* Add dispcc, dsp, USB, regulator, and other nodes for SDM845
* Drop model/compatible from MSM8916 and MSM8996
* Add compat for db820c
* Add MSM8998 SoC and board support along with associated nodes
* Add RESIN/PON for Qualcomm PM8916 and PM8994


Andy Gross (2):
  Revert "dt-bindings: iio: vadc: Fix documentation of 'reg'"
  Revert "dt-bindings: thermal: qcom-spmi-temp-alarm: Fix documentation of 
'reg'"

Bjorn Andersson (10):
  arm64: dts: qcom: msm8998: Add RPM and regulators for MTP
  arm64: dts: qcom: msm8998: Add tsens and thermal-zones
  arm64: dts: qcom: msm8998: Add pmi8998 file
  arm64: dts: qcom: msm8998: Add smem related nodes
  arm64: dts: qcom: msm8998: Add firmware node
  arm64: dts: qcom: msm8998: Add the qfprom node
  arm64: dts: qcom: msm8998: Add smp2p nodes
  arm64: dts: qcom: Populate pm8998 with additional nodes
  arm64: dts: qcom: sdm845: Add adsp, cdsp and slpi smp2p
  arm64: dts: msm8996: Transition smp2p and smd to mailbox

Douglas Anderson (2):
  arm64: dts: qcom: sdm845-mtp: Add RPMh VRM/XOB regulators
  arm64: dts: qcom: sdm845-mtp: Add nodes for USB

Joonwoo Park (1):
  arm64: dts: Add msm8998 SoC and MTP board support

Manu Gautam (1):
  arm64: dts: qcom: sdm845: Add USB-related nodes

Matthias Kaehlcke (6):
  dt-bindings: iio: vadc: Fix documentation of 'reg'
  arm64: dts: qcom: pm8998: Add adc node
  arm64: dts: sdm845: Add dispcc node
  dt-bindings: thermal: qcom-spmi-temp-alarm: Fix documentation of 'reg'
  arm64: dts: qcom: pm8998: Add spmi-temp-alarm node
  arm64: dts: qcom: pm8998: Add pm8998 thermal zone

Niklas Cassel (3):
  arm64: dts: db820c: Add qcom,apq8096 to compatible string
  arm64: dts: msm8916: Drop model and compatible
  arm64: dts: msm8996: Drop model

Sibi Sankar (1):
  arm64: dts: qcom: Add AOSS reset driver node for SDM845

Suzuki K Poulose (1):
  arm64: dts: msm8916: Update coresight bindings for hardware ports

Vinod Koul (4):
  arm64: dts: qcom: pm8916: Add PON node
  arm64: dts: qcom: pm8994: Add PON node
  arm64: dts: qcom: apq8016-sbc: Add resin node
  arm64: dts: qcom: apq8096-db820c: Add resin node

 arch/arm64/boot/dts/qcom/Makefile|   1 +
 arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi|  14 +
 arch/arm64/boot/dts/qcom/apq8096-db820c.dts  |   2 +-
 arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi |  14 +
 arch/arm64/boot/dts/qcom/msm8916.dtsi|  98 ++--
 arch/arm64/boot/dts/qcom/msm8996.dtsi|  15 +-
 arch/arm64/boot/dts/qcom/msm8998-mtp.dts |  13 +
 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi| 243 ++
 arch/arm64/boot/dts/qcom/msm8998.dtsi| 690 +++
 arch/arm64/boot/dts/qcom/pm8916.dtsi |  18 +-
 arch/arm64/boot/dts/qcom/pm8994.dtsi |  18 +
 arch/arm64/boot/dts/qcom/pm8998.dtsi |  75 ++-
 arch/arm64/boot/dts/qcom/pmi8998.dtsi|  40 ++
 arch/arm64/boot/dts/qcom/sdm845-mtp.dts  | 382 +++
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 300 
 15 files changed, 1858 insertions(+), 65 deletions(-)
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-mtp.dts
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998-mtp.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/msm8998.dtsi
 create mode 100644 arch/arm64/boot/dts/qcom/pmi8998.dtsi

[GIT PULL] Qualcomm Defconfig updates for 4.20

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git 
tags/qcom-defconfig-for-4.20

for you to fetch changes up to 54c2678cd198f61555796bbda5e1727e6e1858f1:

  ARM: qcom_defconfig: Enable MAILBOX (2018-09-13 15:39:19 -0500)


Qualcomm ARM Based defconfig Updates for v4.20

* Enable MAILBOX


Frank Rowand (1):
  ARM: qcom_defconfig: Enable MAILBOX

 arch/arm/configs/qcom_defconfig | 1 +
 1 file changed, 1 insertion(+)

[GIT PULL] Qualcomm Driver updates for 4.20

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git 
tags/qcom-drivers-for-4.20

for you to fetch changes up to 579fde69dc1467a033ff44ced75ff368b9d3d072:

  Merge branch 'drivers-for-4.20' into drivers-for-4.20-final (2018-09-30 
12:44:33 -0500)


Qualcomm ARM Based Driver Updates for v4.20

* Refactor of SCM compatibles and clock requirements
* SMEM cleanup
* Add LLCC EDAC driver
* Fixes for GENI clocks and macros
* Fix includes for llcc-slice and smem
* String overflow fixes for APR and wcnss_ctrl
* Fixup for COMPILE_TEST of qcom driver Kconfigs
* Cleanup of Kconfig depends of rpmh, smd_rpm, smsm, and smp2p
* Add SCM dependencies to SPM and rmtfs-mem


Alex Elder (12):
  soc: qcom: smem: rename variable in qcom_smem_get_global()
  soc: qcom: smem: initialize region struct only when successful
  soc: qcom: smem: always ignore partitions with 0 offset or size
  soc: qcom: smem: small refactor in qcom_smem_enumerate_partitions()
  soc: qcom: smem: verify both host ids in partition header
  soc: qcom: smem: require order of host ids to match
  soc: qcom: smem: introduce qcom_smem_partition_header()
  soc: qcom: smem: verify partition header size
  soc: qcom: smem: verify partition offset_free_uncached
  soc: qcom: smem: small change in global entry loop
  soc: qcom: smem: verify partition host ids match
  soc: qcom: smem: a few last cleanups

Andy Gross (2):
  Merge tag 'qcom-geni-immutable-for-mark-brown' into drivers-for-4.20-final
  Merge branch 'drivers-for-4.20' into drivers-for-4.20-final

Bjorn Andersson (4):
  soc: qcom: rmtfs-mem: Validate that scm is available
  dt-bindings: firmware: scm: Refactor compatibles and clocks
  firmware: qcom: scm: Refactor clock handling
  dt-bindings: firmware: scm: Add MSM8998 and SDM845

Channagoud Kadabi (1):
  drivers: edac: Add EDAC driver support for QCOM SoCs

Colin Ian King (1):
  soc: qcom: apr: fix spelling mistake: "paket" -> "packet"

Douglas Anderson (4):
  soc: qcom: geni: Don't ignore clk_round_rate() errors in 
geni_se_clk_tbl_get()
  soc: qcom: geni: geni_se_clk_freq_match() should always accept multiples
  soc: qcom: geni: Don't ignore clk_round_rate() errors in 
geni_se_clk_tbl_get()
  soc: qcom: geni: geni_se_clk_freq_match() should always accept multiples

Felix Fietkau (1):
  soc: qcom: spm: add SCM probe dependency

Lina Iyer (1):
  drivers: qcom: rpmh-rsc: clear wait_for_compl after use

Niklas Cassel (9):
  soc: qcom: smem: Add missing include of sizes.h
  soc: qcom: llcc-slice: Add missing include of sizes.h
  soc: qcom: smp2p: Add select IRQ_DOMAIN
  soc: qcom: smsm: Add select IRQ_DOMAIN
  soc: qcom: Remove bogus depends on OF from QCOM_SMD_RPM
  soc: qcom: Remove depends on OF from QCOM_RPMH
  soc: qcom: wcnss_ctrl: Avoid string overflow
  soc: qcom: apr: Avoid string overflow
  soc: qcom: Allow COMPILE_TEST of qcom SoC Kconfigs

Stephen Boyd (2):
  soc: qcom: geni: Make version macros simpler
  soc: qcom: geni: Make version macros simpler

Venkata Narendra Kumar Gutta (3):
  soc: qcom: Add broadcast base for Last Level Cache Controller (LLCC)
  soc: qcom: Add support to register LLCC EDAC driver
  dt-bindings: msm: Update documentation of qcom,llcc

 .../devicetree/bindings/arm/msm/qcom,llcc.txt  |  19 +-
 .../devicetree/bindings/firmware/qcom,scm.txt  |  33 +-
 MAINTAINERS|   8 +
 drivers/edac/Kconfig   |  14 +
 drivers/edac/Makefile  |   1 +
 drivers/edac/qcom_edac.c   | 414 +
 drivers/firmware/qcom_scm.c|  74 ++--
 drivers/soc/qcom/Kconfig   |  21 +-
 drivers/soc/qcom/apr.c |   6 +-
 drivers/soc/qcom/llcc-slice.c  |  74 ++--
 drivers/soc/qcom/qcom-geni-se.c|  41 +-
 drivers/soc/qcom/rmtfs_mem.c   |   5 +
 drivers/soc/qcom/rpmh-rsc.c|   2 +
 drivers/soc/qcom/smem.c| 174 +
 drivers/soc/qcom/spm.c |   3 +
 drivers/soc/qcom/wcnss_ctrl.c  |   2 +-
 include/linux/qcom-geni-se.h   |  13 +-
 include/linux/soc/qcom/llcc-qcom.h |  30 +-
 18 files changed, 732 insertions(+), 202 deletions(-)
 create mode 100644 drivers/edac/qcom_edac.c

[GIT PULL] Qualcomm Device Tree updates for 4.20

The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:

  Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git 
tags/qcom-dts-for-4.20

for you to fetch changes up to ca02f96b95ca1a50344e7e2a7bb43fbb825aa3a2:

  ARM: dts: qcom: Update coresight bindings for hardware ports (2018-09-30 
13:14:05 -0500)


Qualcomm Device Tree Changes for v4.20

* Fix IRQ constants usage on MSM8974
* Add led, gpio-button, sdcc, and pcie nodes for IPQ8064
* Move/cleanup common nodes for IPQ8064
* Add i2c sensor nodes for MSM8974 Hammerhead
* Fixes for SAW, kpss, opp, pci range, and space/tab on IPQ4019
* Update coresight bindings


Brian Masney (3):
  ARM: dts: qcom: msm8974-hammerhead: add device tree bindings for mpu6515
  ARM: dts: qcom: msm8974-hammerhead: add device tree bindings for ALS / 
proximity
  ARM: dts: qcom-msm8974: change invalid flag IRQ NONE to valid value

Christian Lamparter (1):
  ARM: dts: qcom: ipq4019: fix cpu0's qcom,saw2 reg value

Frank Rowand (6):
  ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_PPI
  ARM: dts: qcom-msm8974: use named constant for interrupt type GIC_SPI
  ARM: dts: qcom-msm8974: use named constant for interrupt flag EDGE RISING
  ARM: dts: qcom-msm8974: use named constant for interrupt flag LEVEL HIGH
  ARM: dts: qcom-msm8974: use named constant for interrupt flag NONE
  ARM: dts: qcom-msm8974: change invalid flag IRQ NONE to valid value

John Crispin (1):
  ARM: dts: qcom: ipq4019: fix space vs tab indenting inside 
qcom-ipq4019.dtsi

Mathias Kresin (1):
  ARM: dts: qcom: ipq4019: fix PCI range

Matthew McClintock (2):
  ARM: dts: qcom: ipq4019: use v2 of the kpss bringup mechanism
  ARM: dts: qcom: ipq4019: add cpu operating points for cpufreq support

Sricharan R (4):
  ARM: dts: qcom: Add pcie nodes for ipq8064
  ARM: dts: qcom: Add sdcc nodes for ipq8064
  ARM: dts: qcom: Move common nodes to ipq8064-v.1.0.dtsi
  ARM: dts: qcom: Add led and gpio-button nodes to ipq8064 boards

Suzuki K Poulose (1):
  ARM: dts: qcom: Update coresight bindings for hardware ports

 arch/arm/boot/dts/qcom-apq8064.dtsi|  71 ++---
 arch/arm/boot/dts/qcom-ipq4019.dtsi| 143 ++-
 arch/arm/boot/dts/qcom-ipq8064-ap148.dts   |  83 +-
 arch/arm/boot/dts/qcom-ipq8064-v1.0.dtsi   | 125 +
 arch/arm/boot/dts/qcom-ipq8064.dtsi| 286 +
 .../dts/qcom-msm8974-lge-nexus5-hammerhead.dts |  83 ++
 arch/arm/boot/dts/qcom-msm8974.dtsi| 198 --
 7 files changed, 731 insertions(+), 258 deletions(-)

[GIT PULL] Qualcomm ARM64 Defconfig updates for 4.20