Re: [PATCH v2] of: resolver: Add missing of_node_get and of_node_put

[Pantelis Antoniou]

Hi Rob,

> On Feb 12, 2016, at 01:18 , Rob Herring  wrote:
> 
> On Wed, Feb 3, 2016 at 12:09 PM, Amitoj Kaur Chawla
>  wrote:
>> In __of_find_node_by_full_name, add an of_node_get when detecting the
>> desired element, to ensure that it ends up with a reference count that is
>> one greater than on entering the function.
>> 
>> Also in __of_find_node_by_full_name, add an of_node_put on breaking
>> out of the for_each_child_of_node loop, to ensure that the reference
>> count of the returned value is not double incremented. This change
>> was made using Coccinelle.
> 
> Pantelis, are you convinced this is correct (albeit somewhat pointless)?
> 

This is good enough. It’s a local method and we won’t ever try to use
it outside of the resolver. We need to fix the reference counting properly
sometime in the future.

> Rob

Regards

— Pantelis

Re: [PATCH v8 3/3] tty: 8250_omap: Use software emulated RS485 direction control

[Matwey V. Kornilov]

2016-02-11 23:19 GMT+03:00 Ильяс Гасанов :
> 2016-02-11 22:08 GMT+03:00 Matwey V. Kornilov :
>> Thanks for pointing out. serial8250_unregister_port should set
>> serial8250_ports[line].em485 to NULL in order to prevent unneeded
>> activation when this struct is reused.
>
> Then the allocated/initialized resources should be freed/released as well.

Sure, I've already sketched the patch, but to test it, I need some
time to build 8250_omap as a module and setup networking console and
kgdb over network.

>
>> You would be able to use serial8250_em485_register in omap8250_probe
>> on  before serial8250_register_8250_port() if
>> serial8250_register_8250_port could replicate em485 member state.
>> But there are alternatives in implementation.
>
> I'm considering adding the relevant code to the omap8250_startup and
> omap8250_shutdown callback functions. However the serial driver
> documentation claims that these don't have port->lock taken when
> invoked, only port_sem.
>
>> serial8250_register_8250_port may either copy pointer up->em485 to
>> uart->em485 or perform deep copy.
>
> Actually, "up" here in omap8250_probe is not a pointer but a struct
> variable on stack, so copying the pointer to it is out of question.
>

up->em485 is always pointer, however you are right, that
serial8250_em485_init stores pointer to up when the timers are inited.
More complex issue here that serial8250_em485_init need to set RTS to
proper state and probably can't do that before
serial8250_register_8250_port. So omap8250_probe should directly or
indirectly use serial8250_get_port(priv->line) after
serial8250_register_8250_port. As for me, possible solution could be
to add a wrapper:

int serial8250_em485_init_by_line(int line) {
struct uart_8250_port *uart = _ports[line];
int ret;
unsigned long flags;

spin_lock_irqsave(>port.lock, flags);
ret = serial8250_em485_init(uart).
spin_unlock_irqrestore(>port.lock, flags);

return ret;
}

>
> Regards,
> Ilyas G.
>



-- 
With best regards,
Matwey V. Kornilov.
Sternberg Astronomical Institute, Lomonosov Moscow State University, Russia
119991, Moscow, Universitetsky pr-k 13, +7 (495) 9392382

Re: [PATCH 3.12 32/64] unix: properly account for FDs passed over unix sockets

[Jiri Slaby]

On 02/11/2016, 06:32 PM, Willy Tarreau wrote:
> Hi Jiri,
> 
> On Thu, Feb 11, 2016 at 02:59:08PM +0100, Jiri Slaby wrote:
>> From: willy tarreau 
>>
>> 3.12-stable review patch.  If anyone has any objections, please let me know.
>>
>> ===
>>
>> [ Upstream commit 712f4aad406bb1ed67f3f98d04c044191f0ff593 ]
>>
>> It is possible for a process to allocate and accumulate far more FDs than
>> the process' limit by sending them over a unix socket then closing them
>> to keep the process' fd count low.
>>
>> This change addresses this problem by keeping track of the number of FDs
>> in flight per user and preventing non-privileged processes from having
>> more FDs in flight than their configured FD limit.
>>
>> Reported-by: socketp...@gmail.com
>> Reported-by: Tetsuo Handa 
>> Mitigates: CVE-2013-4312 (Linux 2.0+)
>> Suggested-by: Linus Torvalds 
>> Acked-by: Hannes Frederic Sowa 
>> Signed-off-by: Willy Tarreau 
>> Signed-off-by: David S. Miller 
>> Signed-off-by: Jiri Slaby 
> 
> A possible issue was reported regarding this patch, and Hannes
> implemented a fix that's not yet in mainline. I guess it's
> preferable to postpone this patch for now.

Hi,

yes definitely. Thanks for noting.

For reference:
http://article.gmane.org/gmane.linux.kernel/2142236

thanks,
-- 
js
suse labs

Re: [PATCH v5 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver

[Benjamin Tissoires]

On Feb 11 2016 or thereabouts, Andrew Duggan wrote:
> On 02/11/2016 02:05 AM, Benjamin Tissoires wrote:
> >On Feb 10 2016 or thereabouts, Andrew Duggan wrote:
> >>This is the v5 patch series which fixes the issues identified by kbuild
> >>and coccinelle in the previous patch series. These include:
> >>
> >>- Using ARRAY_SIZE instead of a custom macro to calculate the size of the
> >>   function handler array.
> >>- Remove setting the .owner field for the driver in rmi_i2c and rmi_spi
> >>   since the i2c-core and spi set that field.
> >>- Fix if statment in rmi_f30 which was testing has_led twice instead of
> >>   testing has_gpio.
> >>
> >Thanks Andrew for the (hopefully) last respin.
> >
> >For the rmi4 core/bus:
> >Tested-by: Benjamin Tissoires 
> >
> >The HID part does not apply on top of Jiri's tree, so we might want to
> >prevent Dmitri to pick this patch up for now (the 10/10).
> >
> >Regarding the SMBus part, I have pushed my rebase on top of your v5
> >here:
> >https://github.com/bentiss/linux/tree/synaptics-rmi4-smbus-v4.5-rc3%2B
> >
> >There is no trackpoint support (no PS/2 redirection) nor support for the
> >embedded buttons. I think it would be good to already merge the current
> >RMI4 bits so at least I2C and SPI could use it, and then figure out the
> >remaining parts for HID and SMBus.
> 
> Yes, my hid-rmi patch b786ae8e269b (HID: rmi: Check that the device is a RMI
> device in suspend and resume callbacks) is in Jiri's tree, but not yet
> anywhere else. Including the HID patch in this patch series has probably
> unnecessarily complicated things since HID is a separate tree. It is self
> contained and I can resubmit HID support as a standalone patch once the core
> has been accepted.
> 
> But, I do think that HID support is ready to go and the changes need to get
> the patch to apply cleanly on top of b786ae8e269b are minimal.

I agree that the HID part should use rmi4 core as soon as possible. It's
just that the patch in this series conflicts with the upstream HID tree.
And this usually requires coordination between Jiri and Dmitry. I was
mentioning it to avoid having Linus to handle the merge himself, or at
least so we can explain to him how the merge should be done because of
the conflict.

Cheers,
Benjamin

> 
> Andrew
> 
> >Cheers,
> >Benjamin
> >
> >>Thanks,
> >>Andrew
> >>
> >>Andrew Duggan (10):
> >>   Input: synaptics-rmi4: Add support for Synaptics RMI4 devices
> >>   Input: synaptics-rmi4: Add I2C transport driver
> >>   Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices
> >>   Input: synaptics-rmi4: Add support for 2D sensors and F11
> >>   Input: synaptics-rmi4: Add device tree support for 2d sensors and F11
> >>   Input: synaptics-rmi4: Add support for F12
> >>   Input: synaptics-rmi4: Add support for F30
> >>   Input: synaptics-rmi4: Add SPI transport driver
> >>   Input: synaptics-rmi4: Add device tree support to the SPI transport
> >> driver
> >>   HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4
> >>
> >>  .../bindings/input/rmi4/rmi_2d_sensor.txt  |   56 +
> >>  .../devicetree/bindings/input/rmi4/rmi_f01.txt |   39 +
> >>  .../devicetree/bindings/input/rmi4/rmi_i2c.txt |   53 +
> >>  .../devicetree/bindings/input/rmi4/rmi_spi.txt |   57 +
> >>  .../bindings/input/touchscreen/touchscreen.txt |2 +
> >>  Documentation/devicetree/bindings/spi/spi-bus.txt  |2 +
> >>  .../devicetree/bindings/vendor-prefixes.txt|1 +
> >>  drivers/hid/Kconfig|2 +-
> >>  drivers/hid/hid-rmi.c  |  891 ++---
> >>  drivers/input/Kconfig  |2 +
> >>  drivers/input/Makefile |2 +
> >>  drivers/input/rmi4/Kconfig |   63 +
> >>  drivers/input/rmi4/Makefile|   13 +
> >>  drivers/input/rmi4/rmi_2d_sensor.c |  329 +
> >>  drivers/input/rmi4/rmi_2d_sensor.h |   87 ++
> >>  drivers/input/rmi4/rmi_bus.c   |  419 +++
> >>  drivers/input/rmi4/rmi_bus.h   |  182 +++
> >>  drivers/input/rmi4/rmi_driver.c| 1055 
> >>  drivers/input/rmi4/rmi_driver.h|  105 ++
> >>  drivers/input/rmi4/rmi_f01.c   |  624 ++
> >>  drivers/input/rmi4/rmi_f11.c   | 1317 
> >> 
> >>  drivers/input/rmi4/rmi_f12.c   |  457 +++
> >>  drivers/input/rmi4/rmi_f30.c   |  407 ++
> >>  drivers/input/rmi4/rmi_i2c.c   |  397 ++
> >>  drivers/input/rmi4/rmi_spi.c   |  589 +
> >>  include/linux/rmi.h|  359 ++
> >>  include/uapi/linux/input.h |1 +
> >>  27 files changed, 6693 insertions(+), 818 deletions(-)
> >>  create mode 100644 
> 

[PATCH] IB/core: Replace memset with eth_zero_addr

[Amitoj Kaur Chawla]

Use eth_zero_addr to assign the zero address to the given address
array instead of memset when second argument is address of zero.

The Coccinelle semantic patch used to make this change is as follows:

// 
@eth_zero_addr@
expression e;
@@

-memset(e,0x00,ETH_ALEN);
+eth_zero_addr(e);
// 

Signed-off-by: Amitoj Kaur Chawla 
---
 drivers/infiniband/core/sa_query.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/sa_query.c 
b/drivers/infiniband/core/sa_query.c
index f334090..4b3ac76 100644
--- a/drivers/infiniband/core/sa_query.c
+++ b/drivers/infiniband/core/sa_query.c
@@ -1221,7 +1221,7 @@ static void ib_sa_path_rec_callback(struct ib_sa_query 
*sa_query,
rec.net = NULL;
rec.ifindex = 0;
rec.gid_type = IB_GID_TYPE_IB;
-   memset(rec.dmac, 0, ETH_ALEN);
+   eth_zero_addr(rec.dmac);
query->callback(status, , query->context);
} else
query->callback(status, NULL, query->context);
-- 
1.9.1

RE: [PATCH v6 0/3] cpufreq: Replace timers with utilization update callbacks

[Doug Smythies]

On 2016.02.11 14:50 Doug Smythies wrote:
> On 2016.02.10 22:03 Srinivas Pandruvada wrote:
>> On Wednesday, February 10, 2016 03:11:43 PM Doug Smythies wrote:

>>> My test computer has an older model i7 (Intel(R) Core(TM) i7-2600K CPU @ 
>>> 3.40GHz)
>> Thanks Doug. If you have specific workloads, please compare performance.

> My work so far has been testing functionality, with unrealistic workloads 
> specifically
> designed to exaggerate issues, in this case the duration problem.
>
> I'll look at some real world workload scenarios.

Turbostat used for package power, starts before Phoronix tests starts,
and ends after Phoronix test ends.

Control Sample: Kernel 4.5-rc3:
Phoronix ffmpeg: turbostat 180 Sec. 12.07 Sec. Ave. 27.14 Watts.
Phoronix apache: turbostat 200 Sec. 19797.0 R.P.S. Ave. 34.01 Watts.
Phoronix kernel: turbostat 180 Sec. 139.93 Sec. 49.09 Watts.
Phoronix Postmark (Disk Test): turbostat 200 Sec. 5813 T.P.S. Ave. 21.33 Watts.

Kernel 4.5-rc3 + RJW 3 patch set version 7:
Phoronix ffmpeg: turbostat 180 Sec. 11.67 Sec. Ave. 27.35 Watts.
Phoronix apache: turbostat 200 Sec. 19430.7 R.P.S. Ave. 34.18 Watts.
Phoronix kernel: turbostat 180 Sec. 139.81 Sec. 48.80 Watts.
Phoronix Postmark (Disk Test): turbostat 200 Sec. 5683 T.P.S. Ave. 22.41 Watts.

... Doug

[PATCH] Platform: goldfish: goldfish_pipe.c: Add DMA support using managed version

[Shraddha Barke]

setup_access_params_addr has 2 goals-

-Initialize the access_params field so that it can be used to send and read
commands from the device in access_with_param
-Get a bus address for the allocated memory to transfer to the device.

Replace the combination of devm_kzalloc and _pa() with dmam_alloc_coherent.
Coherent mapping guarantees that the device and CPU are in sync.

Signed-off-by: Shraddha Barke 
---
 drivers/platform/goldfish/goldfish_pipe.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/goldfish/goldfish_pipe.c 
b/drivers/platform/goldfish/goldfish_pipe.c
index e7a29e2..49f877d 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * IMPORTANT: The following constants must match the ones used and defined
@@ -217,17 +218,18 @@ static int valid_batchbuffer_addr(struct 
goldfish_pipe_dev *dev,
 static int setup_access_params_addr(struct platform_device *pdev,
struct goldfish_pipe_dev *dev)
 {
-   u64 paddr;
+   dma_addr_t dma_handle;
struct access_params *aps;
 
-   aps = devm_kzalloc(>dev, sizeof(struct access_params), 
GFP_KERNEL);
-   if (!aps)
-   return -1;
+   aps = dmam_alloc_coherent(>dev, sizeof(struct access_params),
+   _handle, GFP_KERNEL);
+   if (!aps) {
+   dev_err(>dev, "allocate buffer failed\n");
+   return -ENOMEM;
+   }
 
-   /* FIXME */
-   paddr = __pa(aps);
-   writel((u32)(paddr >> 32), dev->base + PIPE_REG_PARAMS_ADDR_HIGH);
-   writel((u32)paddr, dev->base + PIPE_REG_PARAMS_ADDR_LOW);
+   writel(upper_32_bits(dma_handle), dev->base + 
PIPE_REG_PARAMS_ADDR_HIGH);
+   writel(lower_32_bits(dma_handle), dev->base + PIPE_REG_PARAMS_ADDR_LOW);
 
if (valid_batchbuffer_addr(dev, aps)) {
dev->aps = aps;
-- 
2.1.4

[GIT] EVM hmac security fix

[James Morris]

Please pull this patch for the EVM code, which fixes CVE-2016-2085.


The following changes since commit c05235d50f681bf685e7290cae05ab3b4fa493f3:

  Merge tag 'gpio-v4.5-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio (2016-02-11 
11:25:55 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git 
for-linus

Ryan Ware (1):
  EVM: Use crypto_memneq() for digest comparisons

 security/integrity/evm/evm_main.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

---

commit 613317bd212c585c20796c10afe5daaa95d4b0a1
Author: Ryan Ware 
Date:   Thu Feb 11 15:58:44 2016 -0800

EVM: Use crypto_memneq() for digest comparisons

This patch fixes vulnerability CVE-2016-2085.  The problem exists
because the vm_verify_hmac() function includes a use of memcmp().
Unfortunately, this allows timing side channel attacks; specifically
a MAC forgery complexity drop from 2^128 to 2^12.  This patch changes
the memcmp() to the cryptographically safe crypto_memneq().

Reported-by: Xiaofei Rex Guo 
Signed-off-by: Ryan Ware 
Cc: sta...@vger.kernel.org
Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris 

diff --git a/security/integrity/evm/evm_main.c 
b/security/integrity/evm/evm_main.c
index f716025..e6ea9d4 100644
--- a/security/integrity/evm/evm_main.c
+++ b/security/integrity/evm/evm_main.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "evm.h"
 
 int evm_initialized;
@@ -148,7 +149,7 @@ static enum integrity_status evm_verify_hmac(struct dentry 
*dentry,
   xattr_value_len, calc.digest);
if (rc)
break;
-   rc = memcmp(xattr_data->digest, calc.digest,
+   rc = crypto_memneq(xattr_data->digest, calc.digest,
sizeof(calc.digest));
if (rc)
rc = -EINVAL;

Re: Small writes being split with fdatasync based on non-aligned partition ending

[Sitsofe Wheeler]

CC'ing Jens Axboe.

On 11 February 2016 at 09:54, Jens Rosenboom  wrote:
> 2016-02-11 4:48 GMT+01:00 Sitsofe Wheeler :
>> Trying to cc the GNU parted and linux-block mailing lists.
>>
>> On 9 February 2016 at 13:02, Jens Rosenboom  wrote:
>>> While trying to reproduce some performance issues I have been seeing
>>> with Ceph, I have come across a strange behaviour which is seemingly
>>> affected only by the end point (and thereby the size) of a partition
>>> being an odd number of sectors. Since all documentation about
>>> alignment only refers to the starting point of the partition, this was
>>> pretty surprising and I would like to know whether this is expected
>>> behaviour or maybe a kernel issue.
>>>
>>> The command I am using is pretty simple:
>>>
>>> fio --rw=randwrite --size=1G --fdatasync=1 --bs=4k
>>> --filename=/dev/sdb2 --runtime=10 --name=test
>>>
>>> The difference shows itself when the partition is created either by
>>> sgdisk or by parted:
>>>
>>> sgdisk --new=2:6000M: /dev/sdb
>>>
>>> parted -s /dev/sdb mkpart osd-device-1-block 6291456000B 100%
>>>
>>> The difference in the partition table looks like this:
>>>
>>> <  2  6291456000B  1600320962559B  1594029506560B
>>> osd-device-1-block
>>> ---
  2  6291456000B  1600321297919B  1594029841920B   
 osd-device-1-block
>>
>> Looks like parted took you at your word when you asked for your
>> partition at 100%. Just out of curiosity if you try and make the same
>> partition interactively with parted do you get any warnings after
>> making and after running align-check ?
>
> No warnings and everything fine for align-check. I found out that I
> can get the same effect if I step the partition ending manually in
> parted in 1s increments. The sequence of write sizes is 8, 1, 2, 1, 4,
> 1, 2, 1, 8, ... which corresponds to the size (unit s) of the
> resulting partion mod 8.

OK. Could you add the output of
grep . /sys/block/nvme0n1/queue/*size
sgdisk -D /dev/sdb
and could you post the information about the whole partition table.
Does sgdisk create a similar problem ending if you use
sgdisk --new=2:0 /dev/sdb
? It seems strange that the end of the disk (and thus a 100% sized
partition) wouldn't end on a multiple of 4k...

>>> So this is really only the end of the partition that is different.
>>> However, in the first case, the 4k writes all get broken up into 512b
>>> writes somewhere in the kernel, as can be seen with btrace:
>>>
>>>   8,16   3   36 0.000102666  8184  A  WS 12353985 + 1 <- (8,18) 
>>> 65985
>>>   8,16   3   37 0.000102739  8184  Q  WS 12353985 + 1 [fio]
>>>   8,16   3   38 0.000102875  8184  M  WS 12353985 + 1 [fio]
>>>   8,16   3   39 0.000103038  8184  A  WS 12353986 + 1 <- (8,18) 
>>> 65986
>>>   8,16   3   40 0.000103109  8184  Q  WS 12353986 + 1 [fio]
>>>   8,16   3   41 0.000103196  8184  M  WS 12353986 + 1 [fio]
>>>   8,16   3   42 0.000103335  8184  A  WS 12353987 + 1 <- (8,18) 
>>> 65987
>>>   8,16   3   43 0.000103403  8184  Q  WS 12353987 + 1 [fio]
>>>   8,16   3   44 0.000103489  8184  M  WS 12353987 + 1 [fio]
>>>   8,16   3   45 0.000103609  8184  A  WS 12353988 + 1 <- (8,18) 
>>> 65988
>>>   8,16   3   46 0.000103678  8184  Q  WS 12353988 + 1 [fio]
>>>   8,16   3   47 0.000103767  8184  M  WS 12353988 + 1 [fio]
>>>   8,16   3   48 0.000103879  8184  A  WS 12353989 + 1 <- (8,18) 
>>> 65989
>>>   8,16   3   49 0.000103947  8184  Q  WS 12353989 + 1 [fio]
>>>   8,16   3   50 0.000104035  8184  M  WS 12353989 + 1 [fio]
>>>   8,16   3   51 0.000104150  8184  A  WS 12353990 + 1 <- (8,18) 
>>> 65990
>>>   8,16   3   52 0.000104219  8184  Q  WS 12353990 + 1 [fio]
>>>   8,16   3   53 0.000104307  8184  M  WS 12353990 + 1 [fio]
>>>   8,16   3   54 0.000104452  8184  A  WS 12353991 + 1 <- (8,18) 
>>> 65991
>>>   8,16   3   55 0.000104520  8184  Q  WS 12353991 + 1 [fio]
>>>   8,16   3   56 0.000104609  8184  M  WS 12353991 + 1 [fio]
>>>   8,16   3   57 0.000104885  8184  I  WS 12353984 + 8 [fio]
>>>
>>> whereas in the second case, I'm getting the expected 4k writes:
>>>
>>>   8,16   6   42 1266874889.659842036  8409  A  WS 12340232 + 8 <-
>>> (8,18) 52232
>>>   8,16   6   43 1266874889.659842167  8409  Q  WS 12340232 + 8 [fio]
>>>   8,16   6   44 1266874889.659842393  8409  G  WS 12340232 + 8 [fio]
>>
>> This is weird because --size=1G should mean that fio is "seeing" an
>> aligned end. Does direct=1 with a sequential job of iodepth=1 show the
>> problem too?
>
> IIUC fio uses the size only to find out where to write to, it opens
> the block device and passes the resulting fd to the fdatasync call, so
> the kernel will not know about what size fio thinks the device has. In
> fact, the effect is the same without the size=1G option, I used it
> just to make sure that the writes do not go anywhere near the badly
> aligned 

[PATCH v5 2/8] Staging: rts5208: rtsx_transport.c: Align to open parenthesis

[Shaun Ren]

This patch fixes the alignment issue reported by checkpatch.pl:

CHECK: Alignment should match open parenthesis

Add a unsigned char *sgbuffer in rtsx_stor_access_xfer_buffer to make the
following memcpy logic easier to read.

Add a struct scatterlist *sg in the use_sg branch of
rtsx_transfer_data_partial to make the parameters of the
rtsx_transfer_sglist_adma_partial call fit in 80 character lines after
aligning them to the open parenthesis.

Refactor memcpy logic in rtsx_stor_access_xfer_buf to make it more legible.

Signed-off-by: Shaun Ren 
---
 drivers/staging/rts5208/rtsx_transport.c | 69 +++-
Changes since v3
  * Fixed misalignment of the last parameter of rtsx_stor_access_xfer_buf()
  * Refactored memcpy in rtsx_stor_access_xfer_buf() for legibility

 1 file changed, 41 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 91fdccf..b6de93f 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -42,22 +42,28 @@
  */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
-   unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
-   unsigned int *offset, enum xfer_buf_dir dir)
+  unsigned int buflen,
+  struct scsi_cmnd *srb,
+  unsigned int *index,
+  unsigned int *offset,
+  enum xfer_buf_dir dir)
 {
unsigned int cnt;
 
/* If not using scatter-gather, just transfer the data directly. */
if (scsi_sg_count(srb) == 0) {
+   unsigned char *sgbuffer;
+
if (*offset >= scsi_bufflen(srb))
return 0;
cnt = min(buflen, scsi_bufflen(srb) - *offset);
+
+   sgbuffer = (unsigned char *)scsi_sglist(srb) + *offset;
+
if (dir == TO_XFER_BUF)
-   memcpy((unsigned char *) scsi_sglist(srb) + *offset,
-   buffer, cnt);
+   memcpy(sgbuffer, buffer, cnt);
else
-   memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
-   *offset, cnt);
+   memcpy(buffer, sgbuffer, cnt);
*offset += cnt;
 
/*
@@ -126,7 +132,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char 
*buffer,
  * SCSI residue.
  */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
-   unsigned int buflen, struct scsi_cmnd *srb)
+   unsigned int buflen, struct scsi_cmnd *srb)
 {
unsigned int index = 0, offset = 0;
 
@@ -137,7 +143,7 @@ void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 }
 
 void rtsx_stor_get_xfer_buf(unsigned char *buffer,
-   unsigned int buflen, struct scsi_cmnd *srb)
+   unsigned int buflen, struct scsi_cmnd *srb)
 {
unsigned int index = 0, offset = 0;
 
@@ -191,8 +197,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
/* set the result so the higher layers expect this data */
srb->result = SAM_STAT_CHECK_CONDITION;
memcpy(srb->sense_buffer,
-   (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
-   sizeof(struct sense_data_t));
+  (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+  sizeof(struct sense_data_t));
}
 
return;
@@ -202,7 +208,7 @@ Handle_Errors:
 }
 
 void rtsx_add_cmd(struct rtsx_chip *chip,
-   u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
+ u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
 {
u32 *cb = (u32 *)(chip->host_cmds_ptr);
u32 val = 0;
@@ -321,9 +327,11 @@ static inline void rtsx_add_sg_tbl(
 }
 
 static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
-   struct scatterlist *sg, int num_sg, unsigned int *index,
-   unsigned int *offset, int size,
-   enum dma_data_direction dma_dir, int timeout)
+struct scatterlist *sg, int num_sg,
+unsigned int *index,
+unsigned int *offset, int size,
+enum dma_data_direction dma_dir,
+int timeout)
 {
struct rtsx_dev *rtsx = chip->rtsx;
struct completion trans_done;
@@ -486,8 +494,9 @@ out:
 }
 
 static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
-   struct scatterlist *sg, int num_sg,
-   enum dma_data_direction dma_dir, int timeout)
+struct scatterlist *sg, 

Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset

[Kishon Vijay Abraham I]

Hi Suman,

On Friday 12 February 2016 02:13 AM, Suman Anna wrote:
> On 02/09/2016 11:38 PM, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
>>> Hi Paul,
>>>
>>> On 02/09/2016 01:36 PM, Paul Walmsley wrote:
 Hi Suman 

 On Tue, 9 Feb 2016, Suman Anna wrote:

> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
 On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:

> Paul, what do you think is the best way forward to perform reset?

 Many of the IP blocks with PRM hardreset lines are processor IP 
 blocks. 
 Those often need special reset handling to ensure that WFI/HLT-like 
 instructions are executed after reset.  This special handling ensures 
 that 
 the IP blocks' bus initiator interfaces indicate that they are in 
 standby 
 to the PRCM - thus allowing power management for the rest of the chip 
 to 
 work correctly.

 But that doesn't seem to be the case with PCIe - and maybe others - 
 possibly some of the MMUs?  
>>>
>>> Yeah, the sequencing between clocks and resets would still be the same
>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>
>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs. 
>>  
>> We've stated that the main point of the custom hardreset code is to 
>> handle 
>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>> there would be an equivalent for MMUs.  Thoughts?
>
> The current OMAP IOMMU code already leverages the pdata ops for
> performing the resets, so not adding the flags would also require
> additional changes in the driver.
>
> Also, the reset lines controlling the MMUs actually also manage the
> reset for all the other sub-modules other than the processor cores
> within the sub-systems. We have currently different issues (see [1] for
> eg. around the IPU sub-system entering RET in between), so from a PM
> point of view, we do prefer to place the MMUs also in reset when we are
> runtime suspended.

 Should we reassert hardreset in _idle() for IP blocks that don't have 
 HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
 mechanism for the uncore hardreset lines, or are there other quirks?

 Also - would that address the potential issue that you mentioned with the 
 PCIe block, or is that a different issue?
>>>
>>> Yeah, I think that would address the PCIe block issue in terms of reset
>>> state balancing between pm_runtime_get_sync() and pm_runtime_put()
>>> calls. Right now, they are unbalanced. The PCIe block is using these
>>> only in probe and remove, so it should work for that IP.
>>
>> As I mentioned before this would result in undesired behavior during
>> suspend/resume cycle in PCIe. (This should be okay for the current mainline
>> code but would break once we add suspend/resume support for PCIe).
> 
> Yeah, I was wondering if some peripheral would want only the clock to be
> controlled during _idle() and not reset. Even then for the PCIe case
> that you are talking about, going through a pm_runtime_get_sync(),
> pm_runtime_put_sync()/pm_runtime_put() deasserts the resets everytime

right. But it'll deassert a line which is already deasserted. So it actually
doesn't do a reset again.
> _enable() is called. Right now, the code block has ignored the return
> value from the _hardreset_deassert(), but if you check it and bail out,
> then your get_sync() would start failing from the second invocation.

hmm.. yeah.
> 
> Can you elaborate more on what kind of issues you will see on
> suspend/resume cycle with PCIe? Do note that _idle() gets called through

At this point there are other issues w.r.t suspend/resume in PCI-dra7xx but as
such reset of the controller is not desired during suspend/resume cycle and
it'll result in the register contents being reset (haven't tested it though).

Thanks
Kishon

Re: [PATCH v3 3/3] pci: dra7xx: use pdata callbacks to perform reset

[Kishon Vijay Abraham I]

Hi,

On Friday 12 February 2016 12:57 AM, Paul Walmsley wrote:
> Hi Kishon, Suman,
> 
> On Wed, 10 Feb 2016, Kishon Vijay Abraham I wrote:
> 
>> On Wednesday 10 February 2016 07:12 AM, Suman Anna wrote:
>>> On 02/09/2016 01:36 PM, Paul Walmsley wrote:
 On Tue, 9 Feb 2016, Suman Anna wrote:
> On 02/09/2016 02:49 AM, Paul Walmsley wrote:
>> On Mon, 8 Feb 2016, Suman Anna wrote:
>>> On 02/07/2016 08:48 PM, Paul Walmsley wrote:
 On Tue, 2 Feb 2016, Kishon Vijay Abraham I wrote:

> Paul, what do you think is the best way forward to perform reset?

 Many of the IP blocks with PRM hardreset lines are processor IP 
 blocks. 
 Those often need special reset handling to ensure that WFI/HLT-like 
 instructions are executed after reset.  This special handling ensures 
 that 
 the IP blocks' bus initiator interfaces indicate that they are in 
 standby 
 to the PRCM - thus allowing power management for the rest of the chip 
 to 
 work correctly.

 But that doesn't seem to be the case with PCIe - and maybe others - 
 possibly some of the MMUs?  
>>>
>>> Yeah, the sequencing between clocks and resets would still be the same
>>> for MMUs, so, adding the custom flags for MMUs is fine.
>>
>> I'm curious as to whether HWMOD_CUSTOM_HARDRESET is needed for the MMUs. 
>>  
>> We've stated that the main point of the custom hardreset code is to 
>> handle 
>> processors that need to be placed into WFI/HLT, but it doesn't seem like 
>> there would be an equivalent for MMUs.  Thoughts?
>
> The current OMAP IOMMU code already leverages the pdata ops for
> performing the resets, so not adding the flags would also require
> additional changes in the driver.
>
> Also, the reset lines controlling the MMUs actually also manage the
> reset for all the other sub-modules other than the processor cores
> within the sub-systems. We have currently different issues (see [1] for
> eg. around the IPU sub-system entering RET in between), so from a PM
> point of view, we do prefer to place the MMUs also in reset when we are
> runtime suspended.

 Should we reassert hardreset in _idle() for IP blocks that don't have 
 HWMOD_CUSTOM_HARDRESET set on them?  Would that allow us to use this 
 mechanism for the uncore hardreset lines, or are there other quirks?

 Also - would that address the potential issue that you mentioned with the 
 PCIe block, or is that a different issue?
>>>
>>> Yeah, I think that would address the PCIe block issue in terms of reset
>>> state balancing between pm_runtime_get_sync() and pm_runtime_put()
>>> calls. Right now, they are unbalanced. The PCIe block is using these
>>> only in probe and remove, so it should work for that IP.
>>
>> As I mentioned before this would result in undesired behavior during
>> suspend/resume cycle in PCIe. (This should be okay for the current mainline
>> code but would break once we add suspend/resume support for PCIe).
> 
> I'd like to understand where we're currently at here.  It looks like we're 
> waiting for testing from Suman, and we're waiting for Kishon to try using 
> the bind/unbind driver model hook to see if that wedges PCIe?  Does this 
> match your collective understanding of the status here?

I got to try this and looks like even without this series there are other PM
issues possible introduced by Commit 5de85b9d57ab ("PM / runtime: Re-init
runtime PM states at probe error and driver unbind").

Now I get this error if I tried to modprobe after rmmod pci-dra7xx.
[   54.352860] dra7-pcie 5100.pcie: omap_device: omap_device_enable()
called from invalid state 1
[   54.362318] dra7-pcie 5100.pcie: pm_runtime_get_sync failed
[   54.368624] dra7-pcie: probe of 5100.pcie failed with error -22

>From the thread that fixes this issue [1], looks like drivers that use
*_autosuspend() get this issue. However I don't use *_autosuspend() in
pci-dra7xx. Maybe pci core has this? This has to be debugged further. But I
feel this is not related to the problem that we are trying to solve right now
(dra7 hangs if PCI driver is enabled) and given the fact that pci-dra7xx driver
is now modeled as built-in driver, this can be deferred.

[1] -> http://www.spinics.net/lists/arm-kernel/msg481845.html

> 
> Thinking about the question of what to do about hardreset assertion in 
> idle, if we need it, we could add a hwmod flag to control that mode.  I 
> would consider it a temporary workaround until we have the hwmod code 
> moved into a bus driver and the bus driver/hwmod code can hook into the 
> LDM .remove operation (and connect it to .shutdown, etc.)  Suman/Kishon: 
> is it your understanding that we could remove the existing hardreset 
> control in the IOMMU drivers and the PCIe driver if we had these options 
> in the hwmod code? 

[patch 2/2] misc: mic: silence an overflow warning

[Dan Carpenter]

Static checkers complain that the this is a potential array overflow.
We verify that it's not on the next line so this code is OK, but
static checker warnings are annoying.

Signed-off-by: Dan Carpenter 
---
We would have caught CVE-2015-5327 if we had ordered it to check first
before using the offset.

diff --git a/drivers/misc/mic/vop/vop_vringh.c 
b/drivers/misc/mic/vop/vop_vringh.c
index c3613f3..e94c7fb 100644
--- a/drivers/misc/mic/vop/vop_vringh.c
+++ b/drivers/misc/mic/vop/vop_vringh.c
@@ -848,12 +848,13 @@ static int vop_virtio_copy_desc(struct vop_vdev *vdev,
struct mic_copy_desc *copy)
 {
int err;
-   struct vop_vringh *vvr = >vvr[copy->vr_idx];
+   struct vop_vringh *vvr;
 
err = vop_verify_copy_args(vdev, copy);
if (err)
return err;
 
+   vvr = >vvr[copy->vr_idx];
mutex_lock(>vr_mutex);
if (!vop_vdevup(vdev)) {
err = -ENODEV;

[patch 1/2] misc: mic: use after free printing error message

[Dan Carpenter]

Swap the printk and kfree() to avoid a use after free bug.

Fixes: 61e9c905df78 ('misc: mic: Enable VOP host side functionality')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/misc/mic/vop/vop_vringh.c 
b/drivers/misc/mic/vop/vop_vringh.c
index c1dd000..c3613f3 100644
--- a/drivers/misc/mic/vop/vop_vringh.c
+++ b/drivers/misc/mic/vop/vop_vringh.c
@@ -290,9 +290,9 @@ static int vop_virtio_add_device(struct vop_vdev *vdev,
 
ret = vop_copy_dp_entry(vdev, argp, , );
if (ret) {
-   kfree(vdev);
dev_err(vop_dev(vdev), "%s %d err %d\n",
__func__, __LINE__, ret);
+   kfree(vdev);
return ret;
}
 

[patch] regulator: qcom-saw: testing the wrong variable

[Dan Carpenter]

We accidentally test "config.regmap" which is zero instead of
"vreg->regmap".

Fixes: 18bba3b50355 ('regulator: qcom-saw: Add support for SAW regulators')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/regulator/qcom_saw-regulator.c 
b/drivers/regulator/qcom_saw-regulator.c
index c800f16..c00f0df 100644
--- a/drivers/regulator/qcom_saw-regulator.c
+++ b/drivers/regulator/qcom_saw-regulator.c
@@ -186,8 +186,8 @@ static int qcom_saw_regulator_probe(struct platform_device 
*pdev)
 
vreg->regmap = syscon_node_to_regmap(saw_np);
of_node_put(saw_np);
-   if (IS_ERR(config.regmap))
-   return PTR_ERR(config.regmap);
+   if (IS_ERR(vreg->regmap))
+   return PTR_ERR(vreg->regmap);
 
snprintf(name, sizeof(name), "krait%d", cpu);
 

Re: [PATCH] tty/serial: digicolor: Fix bad usage of IS_ERR_VALUE

[Andrzej Hajda]

On 02/11/2016 04:32 PM, Guenter Roeck wrote:
> On Thu, Feb 11, 2016 at 07:45:11AM +0100, Andrzej Hajda wrote:
>> On 02/11/2016 04:38 AM, Guenter Roeck wrote:
>>> On 02/10/2016 07:21 AM, Arnd Bergmann wrote:
 On Tuesday 09 February 2016 18:37:46 Guenter Roeck wrote:
> On 02/09/2016 07:26 AM, Arnd Bergmann wrote:
>> On Tuesday 09 February 2016 07:08:59 Guenter Roeck wrote:
>>> IS_ERR_VALUE() assumes that its parameter is an unsigned long.
>>> It can not be used to check if an unsigned int reflects an error.
>>> Doing so can result in the following build warning.
>>>
>>> drivers/tty/serial/digicolor-usart.c: In function 
>>> ‘digicolor_uart_probe’:
>>> include/linux/err.h:21:38: warning:
>>>   comparison is always false due to limited range of data type
>>> drivers/tty/serial/digicolor-usart.c:485:6: note:
>>>   in expansion of macro ‘IS_ERR_VALUE’
>>>
>>> If that warning is seen, an error return from platform_get_irq() is 
>>> missed.
>>>
>>>
>> The patch looks correct to me, but what compiler version and which kernel
>> tree is it that triggered the warning?
>>
>> Andrzej Hajda just modified the definition of IS_ERR_VALUE(), and the
>> changes are still under discussion, but I don't see that warning with
>> any of the versions.
>>
> I see it with gcc 5.1 and 5.2 (and W=1). I did not see / notice Andrzej's 
> patch.
>
> I agree that fixing the problem in IS_ERR_VALUE() is preferrable.
>
>
 Ah, W=1 explains it. We are still debating about the proper solution. Al 
 Viro
 pointed out that most users of IS_ERR_VALUE() shouldn't be using it at all,
 so your patch is probably best here after all.

>>> Yes, after looking into it some more I agree. Coccinelle should be able to 
>>> handle
>>> most of the conversions automatically. I actually tried to write a script, 
>>> just
>>> for the fun of it, but it misses some of the problem cases in patch mode.
>>> Maybe I get it working tonight.
>>>
>>> Guenter
>>>
>> Maybe it can be helpful. The script which classifies all IS_ERR_VALUE
>> usages as
>> correct, signed, incorrect and unknown (cocci was not able to detect type).
>> Adding patch mode should be quite simple.
>>
>> // Options: --all-includes --include
>> include/uapi/linux/netfilter_ipv6/ip6_tables.h --include
>> include/uapi/linux/netfilter_ipv4/ip_tables.h --include
>> include/uapi/linux/netfilter_arp/arp_tables.h --include
>> include/uapi/linux/netfilter/x_tables.h --include include/linux/mm_types.h
>>
>> virtual context
>> virtual report
>>
>> @r@
>> typedef bool, u8, u16, u32, u64, s8, s16, s32, s64, __u64, dma_addr_t,
>> Elf32_Addr, Elf64_Addr;
>> {unsigned long, size_t} ev;
>> {short, int, long, s16, s32, ssize_t} ew;
>> {char, unsigned char, unsigned short, unsigned int, long long, unsigned
>> long long, bool, u8, u16, u32, u64, s64, __u64, dma_addr_t, Elf32_Addr,
>> Elf64_Addr} ei;
>> expression eu;
>> position p;
>> @@
>>
>> IS_ERR_VALUE(\(ev \| ew \| ei \| eu \))@p
>>
>> @script:python depends on report@
>> p << r.p = [];
>> ev << r.ev = "";
>> ew << r.ew = "";
>> ei << r.ei = "";
>> eu << r.eu = "";
> This doesn't work for me; it bails out at the assignments. If I remove
> the assignments, it does not report anything.
>
> Any idea what might be wrong ?

Old version of spatch. Default values are supported since 1.0.3.

Regards
Andrzej

[patch] rapidio: mport_cdev: fix some error codes

[Dan Carpenter]

copy_to_user() returns the number of bytes not copied but we want to
return an error code.

Fixes: a45bfc36bf0d ('rapidio: add mport char device driver')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
b/drivers/rapidio/devices/rio_mport_cdev.c
index 6d56725..a3369d1 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -2140,9 +2140,10 @@ static long mport_cdev_ioctl(struct file *filp,
return maint_port_idx_get(data, (void __user *)arg);
case RIO_MPORT_GET_PROPERTIES:
md->properties.hdid = md->mport->host_deviceid;
-   err = copy_to_user((void __user *)arg, &(data->md->properties),
-  sizeof(data->md->properties));
-   break;
+   if (copy_to_user((void __user *)arg, &(data->md->properties),
+sizeof(data->md->properties)))
+   return -EFAULT;
+   return 0;
case RIO_ENABLE_DOORBELL_RANGE:
return rio_mport_add_db_filter(data, (void __user *)arg);
case RIO_DISABLE_DOORBELL_RANGE:
@@ -2155,8 +2156,10 @@ static long mport_cdev_ioctl(struct file *filp,
data->event_mask = arg;
return 0;
case RIO_GET_EVENT_MASK:
-   return copy_to_user((void __user *)arg, >event_mask,
-   sizeof(data->event_mask));
+   if (copy_to_user((void __user *)arg, >event_mask,
+   sizeof(data->event_mask)))
+   return -EFAULT;
+   return 0;
case RIO_MAP_OUTBOUND:
return rio_mport_obw_map(filp, (void __user *)arg);
case RIO_MAP_INBOUND:

Re: [PATCH] cpufreq: Avoid unnecessary locking in show() and store()

[Viresh Kumar]

On 11-02-16, 02:25, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> 
> The show() and store() routines in the cpufreq core don't need to
> acquire all of the locks to check if the struct freq_attr they want
> to use really provides the callbacks they need as expected, so change
> them to avoid doing that.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c |   27 +++
>  1 file changed, 11 insertions(+), 16 deletions(-)
> 
> Index: linux-pm/drivers/cpufreq/cpufreq.c
> ===
> --- linux-pm.orig/drivers/cpufreq/cpufreq.c
> +++ linux-pm/drivers/cpufreq/cpufreq.c
> @@ -862,13 +862,11 @@ static ssize_t show(struct kobject *kobj
>   struct freq_attr *fattr = to_attr(attr);
>   ssize_t ret;
>  
> - down_read(>rwsem);
> -
> - if (fattr->show)
> - ret = fattr->show(policy, buf);
> - else
> - ret = -EIO;
> + if (!fattr->show)
> + return -EIO;
>  
> + down_read(>rwsem);
> + ret = fattr->show(policy, buf);
>   up_read(>rwsem);
>  
>   return ret;
> @@ -881,20 +879,17 @@ static ssize_t store(struct kobject *kob
>   struct freq_attr *fattr = to_attr(attr);
>   ssize_t ret = -EINVAL;
>  
> - get_online_cpus();
> -
> - if (!cpu_online(policy->cpu))
> - goto unlock;
> + if (!fattr->store)
> + return -EIO;
>  
> - down_write(>rwsem);
> + get_online_cpus();
>  
> - if (fattr->store)
> + if (cpu_online(policy->cpu)) {
> + down_write(>rwsem);
>   ret = fattr->store(policy, buf, count);
> - else
> - ret = -EIO;
> + up_write(>rwsem);
> + }
>  
> - up_write(>rwsem);
> -unlock:

I have no problems with the patch as is, but how are we going to benefit from it
?

'if (fattr->show/store)' is never ever going to fail, unless we have a bug here.
So, even we may want to add a WARN_ON() for that case instead.

-- 
viresh

Re: [PATCH] ext4: fix potential integer overflow

[Theodore Ts'o]

On Wed, Jan 20, 2016 at 11:18:08AM -0500, Insu Yun wrote:
> Since sizeof(ext_new_group_data) > sizeof(ext_new_flex_group_data),
> integer overflow could be happened.
> Therefore, need to fix integer overflow sanitization.
> 
> Signed-off-by: Insu Yun 

Thanks, applied.

- Ted

Re: [PATCH] ext4: add a line break for proc mb_groups display

[Theodore Ts'o]

On Wed, Feb 03, 2016 at 02:12:44PM -0700, Andreas Dilger wrote:
> 
> > On Feb 3, 2016, at 6:19 AM, Huaitong Han  wrote:
> > 
> > This patch adds a line break for proc mb_groups display.
> > 
> > Signed-off-by: Huaitong Han 
> 
> Reviewed-by: Andreas Dilger 

Thanks, applied.

- Ted

Re: linux-next: Tree for Feb 12

[Sudip Mukherjee]

On Fri, Feb 12, 2016 at 04:20:35PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20160211:

since last few days with gcc-4.6.3, x86_64 and i386 defconfig and
allmodconfig builds are failing with the error:
"arch/x86/include/asm/tlbflush.h:26:18: error: memory input 0 is not
directly addressable"

But with gcc-4.8.2 and later it builds fine. Should I try to bisect and
find the problem or its not worth for gcc-4.6.3 ?

regards
sudip

blk: accessing invalid memory with "blk-mq: dynamic h/w context count"

[Sasha Levin]

Hi all,

I've started seeing the following errors on boot:

[6035791.296570] 
==
[6035791.297467] BUG: KASAN: slab-out-of-bounds in 
loop_init_request+0x19c/0x1c0 at addr 880052e5c190
[6035791.298355] Write of size 8 by task swapper/0/1
[6035791.298842] 
=
[6035791.299751] BUG kmalloc-512 (Tainted: GW  ): kasan: bad access 
detected
[6035791.300736] 
-
[6035791.300736]
[6035791.301696] Disabling lock debugging due to kernel taint
[6035791.302220] INFO: Slab 0xea00014b9700 objects=32 used=32 fp=0x 
 (null) flags=0x1f80004080
[6035791.303218] INFO: Object 0x880052e5c000 @offset=0 fp=0x  (null)
[6035791.303218]
[6035791.304047] Object 880052e5c000: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.304955] Object 880052e5c010: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.305970] Object 880052e5c020: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.306916] Object 880052e5c030: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.307908] Object 880052e5c040: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.308903] Object 880052e5c050: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.309959] Object 880052e5c060: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.310896] Object 880052e5c070: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.311849] Object 880052e5c080: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.312784] Object 880052e5c090: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.313734] Object 880052e5c0a0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.314646] Object 880052e5c0b0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.315567] Object 880052e5c0c0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.316519] Object 880052e5c0d0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.317475] Object 880052e5c0e0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.318461] Object 880052e5c0f0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.319428] Object 880052e5c100: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.320548] Object 880052e5c110: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.321680] Object 880052e5c120: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.322585] Object 880052e5c130: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.323587] Object 880052e5c140: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.324574] Object 880052e5c150: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.325505] Object 880052e5c160: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.326449] Object 880052e5c170: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.327412] Object 880052e5c180: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.328329] Object 880052e5c190: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.329200] Object 880052e5c1a0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.330117] Object 880052e5c1b0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.331000] Object 880052e5c1c0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.331949] Object 880052e5c1d0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.332888] Object 880052e5c1e0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.333886] Object 880052e5c1f0: 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00  
[6035791.334813] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GB   W   
4.5.0-rc3-next-20160211-sasha-00028-g542d18e-dirty #2898
[6035791.335884]  11000a714ed2 534d57fe 8800538a7718 
a34d4a15
[6035791.336796]   fbfff5eec534 41b58ab3 
aefba520
[6035791.337631]  a34d489f 534d57fe 88018422 
aefd813f
[6035791.338458] Call Trace:
[6035791.338756] dump_stack (lib/dump_stack.c:53)
[6035791.340573] print_trailer (mm/slub.c:661)
[6035791.341117] object_err (mm/slub.c:668)
[6035791.341738] kasan_report_error (include/linux/kasan.h:28 
mm/kasan

[GIT PULL] SCSI fixes for 4.5-rc3

[James Bottomley]

A set of seven fixes.  Two regressions in the new hisi_sas arm driver,
a blacklist entry for the marvell console which was causing a reset
cascade without it, a race fix in the WRITE_SAME/DISCARD routines, a
retry fix for the rdac driver, without which, it would prematurely
return EIO and a couple of fixes for the hyper-v storvsc driver.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Hannes Reinecke (1):
  scsi_dh_rdac: always retry MODE SELECT on command lock violation

John Garry (2):
  hisi_sas: fix v1 hw check for slot error
  hisi_sas: add dependency for HAS_IOMEM

K. Y. Srinivasan (2):
  storvsc: Use the specified target ID in device lookup
  storvsc: Install the storvsc specific timeout handler for FC devices

Martin K. Petersen (1):
  block/sd: Return -EREMOTEIO when WRITE SAME and DISCARD are disabled

Mika Westerberg (1):
  SCSI: Add Marvell Console to VPD blacklist

and the diffstat:

 block/blk-core.c   |  6 --
 drivers/scsi/device_handler/scsi_dh_rdac.c |  4 +++-
 drivers/scsi/hisi_sas/Kconfig  |  2 +-
 drivers/scsi/hisi_sas/hisi_sas_v1_hw.c |  9 +++--
 drivers/scsi/scsi_devinfo.c|  1 +
 drivers/scsi/sd.c  |  4 ++--
 drivers/scsi/storvsc_drv.c | 16 +++-
 include/linux/blkdev.h |  9 ++---
 8 files changed, 31 insertions(+), 20 deletions(-)

With the full diff below.

James

---

diff --git a/block/blk-core.c b/block/blk-core.c
index ab51685..b83d297 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2455,14 +2455,16 @@ struct request *blk_peek_request(struct request_queue 
*q)
 
rq = NULL;
break;
-   } else if (ret == BLKPREP_KILL) {
+   } else if (ret == BLKPREP_KILL || ret == BLKPREP_INVALID) {
+   int err = (ret == BLKPREP_INVALID) ? -EREMOTEIO : -EIO;
+
rq->cmd_flags |= REQ_QUIET;
/*
 * Mark this request as started so we don't trigger
 * any debug logic in the end I/O path.
 */
blk_start_request(rq);
-   __blk_end_request_all(rq, -EIO);
+   __blk_end_request_all(rq, err);
} else {
printk(KERN_ERR "%s: bad return=%d\n", __func__, ret);
break;
diff --git a/drivers/scsi/device_handler/scsi_dh_rdac.c 
b/drivers/scsi/device_handler/scsi_dh_rdac.c
index 3613581..93880ed 100644
--- a/drivers/scsi/device_handler/scsi_dh_rdac.c
+++ b/drivers/scsi/device_handler/scsi_dh_rdac.c
@@ -562,7 +562,7 @@ static int mode_select_handle_sense(struct scsi_device 
*sdev,
/*
 * Command Lock contention
 */
-   err = SCSI_DH_RETRY;
+   err = SCSI_DH_IMM_RETRY;
break;
default:
break;
@@ -612,6 +612,8 @@ retry:
err = mode_select_handle_sense(sdev, h->sense);
if (err == SCSI_DH_RETRY && retry_cnt--)
goto retry;
+   if (err == SCSI_DH_IMM_RETRY)
+   goto retry;
}
if (err == SCSI_DH_OK) {
h->state = RDAC_STATE_ACTIVE;
diff --git a/drivers/scsi/hisi_sas/Kconfig b/drivers/scsi/hisi_sas/Kconfig
index b676618..d1dd161 100644
--- a/drivers/scsi/hisi_sas/Kconfig
+++ b/drivers/scsi/hisi_sas/Kconfig
@@ -1,6 +1,6 @@
 config SCSI_HISI_SAS
tristate "HiSilicon SAS"
-   depends on HAS_DMA
+   depends on HAS_DMA && HAS_IOMEM
depends on ARM64 || COMPILE_TEST
select SCSI_SAS_LIBSAS
select BLK_DEV_INTEGRITY
diff --git a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
index 057fdeb..eea24d7 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v1_hw.c
@@ -1289,13 +1289,10 @@ static int slot_complete_v1_hw(struct hisi_hba 
*hisi_hba,
goto out;
}
 
-   if (cmplt_hdr_data & CMPLT_HDR_ERR_RCRD_XFRD_MSK) {
-   if (!(cmplt_hdr_data & CMPLT_HDR_CMD_CMPLT_MSK) ||
-   !(cmplt_hdr_data & CMPLT_HDR_RSPNS_XFRD_MSK))
-   ts->stat = SAS_DATA_OVERRUN;
-   else
-   slot_err_v1_hw(hisi_hba, task, slot);
+   if (cmplt_hdr_data & CMPLT_HDR_ERR_RCRD_XFRD_MSK &&
+   !(cmplt_hdr_data & CMPLT_HDR_RSPNS_XFRD_MSK)) {
 
+   slot_err_v1_hw(hisi_hba, task, slot);
goto out;
}
 
diff --git a/drivers/scsi/scsi_devinfo.c b/drivers/scsi/scsi_devinfo.c
index 47b9d13..da2e068 100644
--- a/drivers/scsi/scsi_devinfo.c
+++ b/drivers/scsi/scsi_devinfo.c
@@ -205,6 

Re: [PATCH 04/14] clk: sunxi: add ahb1 clock for A83T

[Vishnu Patekar]

Hello Maxime,

On Thu, Feb 4, 2016 at 4:01 PM, Maxime Ripard
 wrote:
> On Thu, Feb 04, 2016 at 02:06:45PM +0800, Vishnu Patekar wrote:
>> Hello Maxime,
>>
>>
>> On Tue, Feb 2, 2016 at 9:17 PM, Maxime Ripard
>>  wrote:
>> > Hi,
>> >
>> > On Sun, Jan 31, 2016 at 09:20:56AM +0800, Vishnu Patekar wrote:
>> >> AHB1 on A83T is similar to ahb1 on A31, except parents are different.
>> >> clock index 0b1x is PLL6.
>> >>
>> >> Signed-off-by: Vishnu Patekar 
>> >
>> > If the clock is the same but the parents are different, then we don't
>> > need to duplicate all the logic. Simply add the number of parents to
>> > mux_data, and you're all set.
>>
>> Problem here is: parent 0b10 for A31 ahb1 is AXI, 0b11 is pll6/pre_div.
>> 0b10 and 0b11 is pll6/pre_div.
>> So, just adding number of parents to mux_data will not solve problem.
>
> Is anyone using 0b11 ? Can't we just ignore it?
Yes, it's used, 0b11 is pll6 parent in case of A31.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

linux-next: Tree for Feb 12

[Stephen Rothwell]

Hi all,

Changes since 20160211:

The kvm-arm tree gained a conflict against the arm64 tree.

The aio tree still had a build failure so I used the version from
next-20160111.

Non-merge commits (relative to Linus' tree): 4277
 3754 files changed, 149171 insertions(+), 67859 deletions(-)



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

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

Below is a summary of the state of the merge.

I am currently merging 239 trees (counting Linus' and 36 trees of patches
pending for Linus' tree).

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

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

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

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c05235d50f68 Merge tag 'gpio-v4.5-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7)
Merging arm-current/fixes (e972c37459c8 ARM: 8519/1: ICST: try other dividends 
than 1)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (0fe53e8d335b powerpc/powernv: Fix stale PE primary 
bus)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (ca0bb0798022 Add sun4v_wdt watchdog driver)
Merging net/master (a1b14d27ed09 bpf: fix branch offset adjustment on backjumps 
after patching ctx expansion)
Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops)
Merging ipvs/master (b16c29191dc8 netfilter: nf_conntrack: use safer way to 
lock all buckets)
Merging wireless-drivers/master (d76d65fd2695 rtlwifi: fix broken VHT support)
Merging mac80211/master (212c5a5e6ba6 mac80211: minstrel: Change expected 
throughput unit back to Kbps)
Merging sound-current/for-linus (397da2d0ab0d Merge branch 'topic/core-fixes' 
into for-linus)
Merging pci-current/for-linus (0cf1337e0b83 PCI: rcar: Add device tree support 
for r8a7793)
Merging driver-core.current/driver-core-linus (00cd29b799e3 klist: fix starting 
point removed bug in klist iterators)
Merging tty.current/tty-linus (c8053b587627 Revert "8250: uniphier: allow 
modular build with 8250 console")
Merging usb.current/usb-linus (89140fdaf11a xhci: harden xhci_find_next_ext_cap 
against device removal)
Merging usb-gadget-fixes/fixes (6a4290cc28be usb: dwc3: gadget: set the OTG 
flag in dwc3 gadget driver.)
Merging usb-serial-fixes/usb-linus (4152b387da81 USB: option: fix Cinterion 
AHxx enumeration)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: 
fix a possible NULL dereference)
Merging staging.current/staging-linus (388f7b1d6e8c Linux 4.5-rc3)
Merging char-misc.current/char-misc-linus (3b2b9ead3214 nvmem: qfprom: Specify 
LE device endianness)
Merging input-current/for-linus (ff84dabe3c6e Input: colibri-vf50-ts - add 
missing #include )
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (16ab8a5cbea4 vfio/noiommu: Don't use 
iommu_

Re: [RFC][PATCH v3 4/4] printk: set may_schedule for some of console_trylock callers

[Sergey Senozhatsky]

On (02/11/16 17:10), Petr Mladek wrote:
[..]
> > well, I believe it's ok. __rcu_read_lock() for CONFIG_PREEMPT_RCU
> > does current->rcu_read_lock_nesting++, so rcu_preempt_depth() works
> > as expected. otherwise, for !CONFIG_PREEMPT_RCU kernel,
> > __rcu_read_lock() does
> > 
> > if (IS_ENABLED(CONFIG_PREEMPT_COUNT))
> > preempt_disable()
> > 
> > 
> > - if we run "CONFIG_PREEMPT_RCU" then rcu_preempt_depth()
> >   works here.
> > 
> > - if we run "!CONFIG_PREEMPT_RCU && CONFIG_PREEMPT_COUNT"
> >   then preemptible() works for us
> > 
> > - if we run "!CONFIG_PREEMPT_RCU && !CONFIG_PREEMPT_COUNT"
> >   then preemptible() is always 0.
> 
> I feel convinced. But we should somehow document it. I think how
> to do it effectively. I think that the following text would help
> me if I read it:
> 
>   /*
>* Safe context for rescheduling is detected only when
>* PREEMPT_COUNT is enabled. preemptible() always returns
>* false otherwise.
>*
>* RCU read sections must be detected separately. They
>* have a separate preemption counter when PREEMPT_RCU
>* is enabled.
>*/
> 
> I wanted to highlight why exactly the check returns 0 in !PREEMPT_COUNT
> kernel. I missed this a bit in you original comment. But feel free
> to change it as you like.

good point. thanks! will re-spin the patch set later today,
have no reliable internet connection at the moment.

-ss

Re: [PATCH] ext4: ioctl: fix erroneous return value

[Theodore Ts'o]

On Thu, Feb 11, 2016 at 10:58:58AM -0500, Anton Protopopov wrote:
> The ext4_ioctl_setflags() function which is used in the ioctls
> EXT4_IOC_SETFLAGS and EXT4_IOC_FSSETXATTR may return the positive value
> EPERM instead of -EPERM in case of error. This bug was introduced by a
> recent commit 9b7365fc.

Nice catch!  Thanks, applied.

- Ted

Re: [BUG REPORT] use of unreachable() masks uninitialized variables warnings

[Jeff Merkey]

On 2/11/16, Theodore Ts'o  wrote:
> On Thu, Feb 11, 2016 at 11:12:12AM -0700, Jeff Merkey wrote:
>>
>> That's good to know, they could be false positives, but it was kind of
>> wierd behavior caused by that macro.
>
> If it is true, it sounds more like a compiler bug to me.  Any
> statements a BUG() call are unreachable.  If the compiler assumes that
> in the case of:
>
>   if (a)
>   BUG();
>   printf("foo bar\n");
>   
> That the printf is not reachable, that's a compiler bug.  And not a
> problem in the BUG() macro.
>
> It might be that it's worthwhile to use other static code analysis
> tools.  Many people will look at warnings from Coverity and clang to
> find potential problems, since these tend to find more warnings than
> just using gcc.  The problem with some of these, including Coverity,
> is that they can be __too__ noisy, and if 90% of the warnings are
> false positives, most people won't take the time to weed out several
> dozen bogus warnings to find the one good one.
>

Did you remove the calls to unreachable() before you did the build?
Remove the call to that function from the BUG() macro, then do a
build, and tell me I am seeing things.

Jeff

Re: [PATCH v8 2/4] tee: generic TEE subsystem

[Al Viro]

On Thu, Feb 11, 2016 at 06:14:35PM +0100, Jens Wiklander wrote:

> +static int tee_ioctl_shm_alloc(struct tee_context *ctx,
> + struct tee_ioctl_shm_alloc_data __user *udata)
> +{
> + long ret;
> + struct tee_ioctl_shm_alloc_data data;
> + struct tee_shm *shm;
> +
> + if (copy_from_user(, udata, sizeof(data)))
> + return -EFAULT;
> +
> + /* Currently no input flags are supported */
> + if (data.flags)
> + return -EINVAL;
> +
> + data.fd = -1;
> +
> + shm = tee_shm_alloc(ctx->teedev, data.size,
> + TEE_SHM_MAPPED | TEE_SHM_DMA_BUF);
> + if (IS_ERR(shm))
> + return PTR_ERR(shm);
> +
> + data.flags = shm->flags;
> + data.size = shm->size;
> + data.fd = tee_shm_get_fd(shm);
> + if (data.fd < 0) {
> + ret = data.fd;
> + goto err;
> + }
> +
> + if (copy_to_user(udata, , sizeof(data))) {
> + ret = -EFAULT;
> + goto err;
> + }
> + /*
> +  * When user space closes the file descriptor the shared memory
> +  * should be freed
> +  */
> + tee_shm_put(shm);
> + return 0;
> +err:
> + if (data.fd >= 0)
> + tee_shm_put_fd(data.fd);

This is completely broken.  Don't ever use that pattern.  Once something
is in descriptor table, that's _it_.  You are already past the point of
no return and there is no way to clean up.

In ABIs like that (and struct containing descriptor *is* a bad ABI design)
solution is
* allocate a descriptor
* do everything that might fail, including copy_to_user()/put_user(),
etc.
* if failed, release unused descriptor and do fput(), if you already
have a struct file reference that needs to be released.
* FINALLY, when nothing no failures are possible, fd_install() the
sucker in place.

And yes, dma_buf_fd() encourages that kind of braindamage.  It's tolerable
only in one case - when we are about to return descriptor number directly
as return value of syscall and really can't fail anymore.  Not the case
here.

Re: [PATCH v4 2/8] Staging: rts5208: rtsx_transport.c: Align to open parenthesis

[kbuild test robot]

Hi Shaun,

[auto build test WARNING on staging/staging-testing]
[also build test WARNING on v4.5-rc3 next-20160211]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Shaun-Ren/Staging-rts5208-Fix-coding-style/20160212-122003
config: xtensa-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

   drivers/staging/rts5208/rtsx_transport.c: In function 
'rtsx_stor_access_xfer_buf':
>> drivers/staging/rts5208/rtsx_transport.c:59:3: warning: ISO C90 forbids 
>> mixed declarations and code [-Wdeclaration-after-statement]
  unsigned char *sgbuffer = (unsigned char *)scsi_sglist(srb) +
  ^

vim +59 drivers/staging/rts5208/rtsx_transport.c

43  
44  unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
45 unsigned int buflen,
46 struct scsi_cmnd *srb,
47 unsigned int *index,
48 unsigned int *offset,
49 enum xfer_buf_dir dir)
50  {
51  unsigned int cnt;
52  
53  /* If not using scatter-gather, just transfer the data 
directly. */
54  if (scsi_sg_count(srb) == 0) {
55  if (*offset >= scsi_bufflen(srb))
56  return 0;
57  cnt = min(buflen, scsi_bufflen(srb) - *offset);
58  
  > 59  unsigned char *sgbuffer = (unsigned char 
*)scsi_sglist(srb) +
60  *offset;
61  
62  if (dir == TO_XFER_BUF)
63  memcpy(sgbuffer, buffer, cnt);
64  else
65  memcpy(buffer, sgbuffer, cnt);
66  *offset += cnt;
67  

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


.config.gz
Description: Binary data

Re: [BUG REPORT] use of unreachable() masks uninitialized variables warnings

[Jeff Merkey]

On 2/11/16, Jeff Merkey  wrote:
>> In your case, for example, I looked through several dozen warnings,
>> and they were ***all*** bogus.  Keep in mind that this might make me
>> less inclined to pay attention to complaints from you in the future.
>> The story of the buy who cried wolf too often comes to mind.
>>
>> Perhaps you could actually take a close look at the warnings, before
>> you fire off an e-mail?  If at least one of the warnings were valid
>> and pointed at an actual bug, it wouldn't have been a complete waste
>> of my time
>>
>
> I did take a close look at some of them (I reviewed them in assembler
> -- probably a closer look than you gave them) and it was somewhat
> confusing since the compiler was outputing jmp labels in the wrong
> places in the code after I removed the calls to unreachable().
>
> Ted, that's the problem with sitting around looking at C code all day
> trying to find bugs created by the linux macros with assembler output
> that does not map precisely to the C code.  I discovered this grepping
> around in the assembler output of these macro H libs.
>

In other words folks who sit around staring at C code all day looking
for bugs instead of looking at what the compiler output in assembler
are not going to have a clue as to what is busted in their C code.  I
worked on a bug for days with tglx that turned out to be a stupid
signed variable declaration outputing a sar instruction instead of a
shr.  6 years it was in linux and all the code reviews failed to catch
it.  An assembly language debugger went right to it and it was nailed
shortly thereafter.  Of course I had to endure lashing comments from
several folks who were in denial mode and wouldn't accept a simple
patch to just fix the damn thing  -- finally someone reported it on
sparc and it got fixed -- amazing.

Jeff

Re: [PATCH v4 2/8] Staging: rts5208: rtsx_transport.c: Align to open parenthesis

[Joe Perches]

On Thu, 2016-02-11 at 20:07 -0800, Shaun Ren wrote:
> This patch fixes the alignment issue reported by checkpatch.pl:
> 
> CHECK: Alignment should match open parenthesis
[]
> diff --git a/drivers/staging/rts5208/rtsx_transport.c 
> b/drivers/staging/rts5208/rtsx_transport.c
[]
> @@ -52,12 +55,14 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char 
> *buffer,
>   if (*offset >= scsi_bufflen(srb))
>   return 0;
>   cnt = min(buflen, scsi_bufflen(srb) - *offset);
> +
> + unsigned char *sgbuffer = (unsigned char *)scsi_sglist(srb) +
> + *offset;

Please don't declare variables in the middle of functions.
Variable declarations are only done at the beginning of functions.

> +
>   if (dir == TO_XFER_BUF)
> - memcpy((unsigned char *) scsi_sglist(srb) + *offset,
> - buffer, cnt);
> + memcpy(sgbuffer, buffer, cnt);
>   else
> - memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
> - *offset, cnt);
> + memcpy(buffer, sgbuffer, cnt);
>   *offset += cnt;

[PATCH 1/4] mfd: max77686: Add max77802 to I2C device ID table

[Javier Martinez Canillas]

The max77686 MFD driver supports both the Maxim 77686 and Maxim 77802
PMICs but only the OF device table contains entries for both devices.

The max77802 entry is missing in the I2C device ID table which isn't
a problem currently since the driver only supports DT but it will be
needed if the driver is changed to be built as a module since the I2C
core always reports a I2C modalias uevent so auto-load will not work.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/mfd/max77686.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index d959ebbb2194..1f30c97d6d4e 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -345,6 +345,7 @@ static int max77686_i2c_remove(struct i2c_client *i2c)
 
 static const struct i2c_device_id max77686_i2c_id[] = {
{ "max77686", TYPE_MAX77686 },
+   { "max77802", TYPE_MAX77802 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, max77686_i2c_id);
-- 
2.5.0

[PATCH 3/4] mfd: max77686: Allow driver to be built as a module

[Javier Martinez Canillas]

The driver's Kconfig symbol is a boolean but nothing prevents the driver
to be built as a module instead of built-in. It is true that most system
integrators will choose the latter but the config should not restrict it.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/mfd/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6c4ebd9f4cb6..005ace26230e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -493,8 +493,8 @@ config MFD_MAX14577
  of the device.
 
 config MFD_MAX77686
-   bool "Maxim Semiconductor MAX77686/802 PMIC Support"
-   depends on I2C=y
+   tristate "Maxim Semiconductor MAX77686/802 PMIC Support"
+   depends on I2C
depends on OF
select MFD_CORE
select REGMAP_I2C
-- 
2.5.0

[PATCH 0/4] mfd: max77686: Allow the driver to be built as a module

[Javier Martinez Canillas]

Hello,

The Maxim77802 PMIC driver uses a boolean Kconfig symbol but there isn't
really a reason to require the driver to be built-in.

It is true that since the PMIC provides clocks and regulators that could
be critical on a system, most integrators are not going to build it as a
module but it could be useful for multi-platform or distribution kernels
that support different systems by building as much as possible as module.

Besides this series, a patch for the max77686 regulator driver is needed
or the MFD max77686 driver module won't be installed by kbuild. I didn't
include the patch in this series to avoid cross-subsystems churn for the
maintainers and also because I don't consider that a regression since it
was not possible to build the driver as a module before anyways.

Also, all the defconfigs in mainline that enable the MFD max77686 driver
Kconfig symbol are using =y of course so it shouldn't be an issue to get
this set merged, before the max77686 regulator patch already posted [0].

[0]: https://patchwork.kernel.org/patch/8287431/

Best regards,
Javier


Javier Martinez Canillas (4):
  mfd: max77686: Add max77802 to I2C device ID table
  mfd: max77686: Use module_i2c_driver() instead of subsys initcall
  mfd: max77686: Allow driver to be built as a module
  mfd: max77686: Export OF module alias information

 drivers/mfd/Kconfig|  4 ++--
 drivers/mfd/max77686.c | 15 +++
 2 files changed, 5 insertions(+), 14 deletions(-)

-- 
2.5.0

[PATCH 4/4] mfd: max77686: Export OF module alias information

[Javier Martinez Canillas]

When the device is registered via OF, the OF table is used to match the
driver instead of the I2C device ID table but the entries in the latter
are used as aliasses to load the module if the driver was not built-in.

This is because the I2C core always reports an I2C module alias instead
of an OF one but that could change so it is better to always export it.

Signed-off-by: Javier Martinez Canillas 

---

 drivers/mfd/max77686.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index 2f563d0f83cc..b1ed9ed0828c 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -204,6 +204,7 @@ static const struct of_device_id max77686_pmic_dt_match[] = 
{
},
{ },
 };
+MODULE_DEVICE_TABLE(of, max77686_pmic_dt_match);
 
 static int max77686_i2c_probe(struct i2c_client *i2c,
  const struct i2c_device_id *id)
-- 
2.5.0

[PATCH 2/4] mfd: max77686: Use module_i2c_driver() instead of subsys initcall

[Javier Martinez Canillas]

The driver's init and exit function don't do anything besides adding and
deleting the I2C driver so the module_i2c_driver() macro could be used.

Currently is not being used because the driver is initialized at subsys
initcall level, claiming that this is done to allow consumers devices to
use the resources provided by this driver. But dependencies should be in
the DT and consumers drivers should not rely in the registration order.

Signed-off-by: Javier Martinez Canillas 
---

 drivers/mfd/max77686.c | 13 +
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/mfd/max77686.c b/drivers/mfd/max77686.c
index 1f30c97d6d4e..2f563d0f83cc 100644
--- a/drivers/mfd/max77686.c
+++ b/drivers/mfd/max77686.c
@@ -400,18 +400,7 @@ static struct i2c_driver max77686_i2c_driver = {
.id_table = max77686_i2c_id,
 };
 
-static int __init max77686_i2c_init(void)
-{
-   return i2c_add_driver(_i2c_driver);
-}
-/* init early so consumer devices can complete system boot */
-subsys_initcall(max77686_i2c_init);
-
-static void __exit max77686_i2c_exit(void)
-{
-   i2c_del_driver(_i2c_driver);
-}
-module_exit(max77686_i2c_exit);
+module_i2c_driver(max77686_i2c_driver);
 
 MODULE_DESCRIPTION("MAXIM 77686/802 multi-function core driver");
 MODULE_AUTHOR("Chiwoong Byun ");
-- 
2.5.0

Re: [BUG REPORT] use of unreachable() masks uninitialized variables warnings

[Jeff Merkey]

> In your case, for example, I looked through several dozen warnings,
> and they were ***all*** bogus.  Keep in mind that this might make me
> less inclined to pay attention to complaints from you in the future.
> The story of the buy who cried wolf too often comes to mind.
>
> Perhaps you could actually take a close look at the warnings, before
> you fire off an e-mail?  If at least one of the warnings were valid
> and pointed at an actual bug, it wouldn't have been a complete waste
> of my time
>

I did take a close look at some of them (I reviewed them in assembler
-- probably a closer look than you gave them) and it was somewhat
confusing since the compiler was outputing jmp labels in the wrong
places in the code after I removed the calls to unreachable().

Ted, that's the problem with sitting around looking at C code all day
trying to find bugs created by the linux macros with assembler output
that does not map precisely to the C code.  I discovered this grepping
around in the assembler output of these macro H libs.

If you like I can go over all the garbage assembler this gcc issue
generates around these BUG() macros with calls to unreachable which is
why I raised the issue.

Jeff

[git pull] drm amd fixes.

[Dave Airlie]

Hi Linus,

Been pretty quiet, this is an amdgpu fixes pull from AMD,
a bunch of powerplay stability fixes, race fix, hibernate fix,
and a possible circular locking fix.

Dave.

The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:

  Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux drm-fixes

for you to fetch changes up to c92a428f408b23215d1a27f652742094bfc50577:

  Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-02-11 08:39:07 +1000)


Alex Deucher (16):
  drm/amdgpu: add pcie cap module parameters (v2)
  drm/amdgpu/cik: don't mess with aspm if gpu is root bus
  drm/amdgpu/dpm/ci: switch over to the common pcie caps interface
  drm/amdgpu: handle uvd pg flags properly
  drm/amdgpu: handle vce pg flags properly
  drm/amdgpu: clean up vce pg flags for cz/st
  drm/amdgpu: be consistent with uvd cg flags
  drm/amd/powerplay/cz: disable uvd pg
  drm/amd/powerplay/cz: disable vce pg
  drm/amd/powerplay/tonga: disable uvd pg
  drm/amd/powerplay/tonga: disable vce pg
  drm/amdgpu: add a cgs interface to fetch cg and pg flags
  drm/amdgpu: remove unused cg defines
  drma/dmgpu: move cg and pg flags into shared headers
  drm/amdgpu/tonga: plumb pg flags through to powerplay
  drm/amdgpu/cz: plumb pg flags through to powerplay

Christian König (1):
  drm/amdgpu: fix issue with overlapping userptrs

Dave Airlie (1):
  Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes

Flora Cui (1):
  drm/amdgpu: fix s4 resume

Nicolai Hähnle (3):
  drm/amdgpu: hold reference to fences in amdgpu_sa_bo_new (v2)
  drm/amdgpu: remove unnecessary forward declaration
  drm/radeon: hold reference to fences in radeon_sa_bo_new

 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  47 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c   |   6 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c| 160 --
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   |   8 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c|   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_sa.c|   5 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c   |  19 +++
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c   |  11 +-
 drivers/gpu/drm/amd/amdgpu/cik.c  | 157 ++---
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c |   4 +-
 drivers/gpu/drm/amd/amdgpu/cz_dpm.c   |   6 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c |  70 +-
 drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c |  10 +-
 drivers/gpu/drm/amd/amdgpu/kv_dpm.c   |   8 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c |  10 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c |   8 ++
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c |   7 +-
 drivers/gpu/drm/amd/amdgpu/vce_v2_0.c |   5 +-
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c |   7 +-
 drivers/gpu/drm/amd/amdgpu/vi.c   |   3 +-
 drivers/gpu/drm/amd/include/amd_shared.h  |  32 +
 drivers/gpu/drm/amd/include/cgs_common.h  |   2 +
 drivers/gpu/drm/amd/powerplay/hwmgr/cz_hwmgr.c|  18 +++
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c |  19 ++-
 drivers/gpu/drm/radeon/radeon_sa.c|   5 +
 25 files changed, 373 insertions(+), 257 deletions(-)

Re: [BUG REPORT] use of unreachable() masks uninitialized variables warnings

[Jeff Merkey]

On 2/11/16, Theodore Ts'o  wrote:
> On Thu, Feb 11, 2016 at 11:12:12AM -0700, Jeff Merkey wrote:
>>
>> That's good to know, they could be false positives, but it was kind of
>> wierd behavior caused by that macro.
>
> If it is true, it sounds more like a compiler bug to me.  Any
> statements a BUG() call are unreachable.  If the compiler assumes that
> in the case of:
>
>   if (a)
>   BUG();
>   printf("foo bar\n");
>   
> That the printf is not reachable, that's a compiler bug.  And not a
> problem in the BUG() macro.
>
> It might be that it's worthwhile to use other static code analysis
> tools.  Many people will look at warnings from Coverity and clang to
> find potential problems, since these tend to find more warnings than
> just using gcc.  The problem with some of these, including Coverity,
> is that they can be __too__ noisy, and if 90% of the warnings are
> false positives, most people won't take the time to weed out several
> dozen bogus warnings to find the one good one.
>
> In your case, for example, I looked through several dozen warnings,
> and they were ***all*** bogus.  Keep in mind that this might make me
> less inclined to pay attention to complaints from you in the future.
> The story of the buy who cried wolf too often comes to mind.
>
> Perhaps you could actually take a close look at the warnings, before
> you fire off an e-mail?  If at least one of the warnings were valid
> and pointed at an actual bug, it wouldn't have been a complete waste
> of my time
>
> Best regards,
>
>   - Ted
>

Well, it's nice to know I wasn't imagining what I was seeing.  It
wasn't a complete waste of my time or yours since it revealed a
problem with gcc issuing warnings.  Not all of them were bogus BTW,
just inert would be better word.  I noticed it while enabling the
ability of the BUG() macro to emit an int3 instead of a ud2
instruction.

Jeff

[PATCH v4 2/8] Staging: rts5208: rtsx_transport.c: Align to open parenthesis

[Shaun Ren]

This patch fixes the alignment issue reported by checkpatch.pl:

CHECK: Alignment should match open parenthesis

Add a unsigned char *sgbuffer in rtsx_stor_access_xfer_buffer to make the
following memcpy logic easier to read.

Add a struct scatterlist *sg in the use_sg branch of
rtsx_transfer_data_partial to make the parameters of the
rtsx_transfer_sglist_adma_partial call fit in 80 character lines after
aligning them to the open parenthesis.

Refactor memcpy logic in rtsx_stor_access_xfer_buf to make it more legible.

Signed-off-by: Shaun Ren 
---
Changes since v3
  * Fixed misalignment of the last parameter of rtsx_stor_access_xfer_buf()
  * Refactored memcpy in rtsx_stor_access_xfer_buf() for legibility

 drivers/staging/rts5208/rtsx_transport.c | 68 +++-
 1 file changed, 40 insertions(+), 28 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 91fdccf..1a4da89 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -42,8 +42,11 @@
  */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
-   unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
-   unsigned int *offset, enum xfer_buf_dir dir)
+  unsigned int buflen,
+  struct scsi_cmnd *srb,
+  unsigned int *index,
+  unsigned int *offset,
+  enum xfer_buf_dir dir)
 {
unsigned int cnt;
 
@@ -52,12 +55,14 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char 
*buffer,
if (*offset >= scsi_bufflen(srb))
return 0;
cnt = min(buflen, scsi_bufflen(srb) - *offset);
+
+   unsigned char *sgbuffer = (unsigned char *)scsi_sglist(srb) +
+   *offset;
+
if (dir == TO_XFER_BUF)
-   memcpy((unsigned char *) scsi_sglist(srb) + *offset,
-   buffer, cnt);
+   memcpy(sgbuffer, buffer, cnt);
else
-   memcpy(buffer, (unsigned char *) scsi_sglist(srb) +
-   *offset, cnt);
+   memcpy(buffer, sgbuffer, cnt);
*offset += cnt;
 
/*
@@ -126,7 +131,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char 
*buffer,
  * SCSI residue.
  */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
-   unsigned int buflen, struct scsi_cmnd *srb)
+   unsigned int buflen, struct scsi_cmnd *srb)
 {
unsigned int index = 0, offset = 0;
 
@@ -137,7 +142,7 @@ void rtsx_stor_set_xfer_buf(unsigned char *buffer,
 }
 
 void rtsx_stor_get_xfer_buf(unsigned char *buffer,
-   unsigned int buflen, struct scsi_cmnd *srb)
+   unsigned int buflen, struct scsi_cmnd *srb)
 {
unsigned int index = 0, offset = 0;
 
@@ -191,8 +196,8 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
/* set the result so the higher layers expect this data */
srb->result = SAM_STAT_CHECK_CONDITION;
memcpy(srb->sense_buffer,
-   (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
-   sizeof(struct sense_data_t));
+  (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+  sizeof(struct sense_data_t));
}
 
return;
@@ -202,7 +207,7 @@ Handle_Errors:
 }
 
 void rtsx_add_cmd(struct rtsx_chip *chip,
-   u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
+ u8 cmd_type, u16 reg_addr, u8 mask, u8 data)
 {
u32 *cb = (u32 *)(chip->host_cmds_ptr);
u32 val = 0;
@@ -321,9 +326,11 @@ static inline void rtsx_add_sg_tbl(
 }
 
 static int rtsx_transfer_sglist_adma_partial(struct rtsx_chip *chip, u8 card,
-   struct scatterlist *sg, int num_sg, unsigned int *index,
-   unsigned int *offset, int size,
-   enum dma_data_direction dma_dir, int timeout)
+struct scatterlist *sg, int num_sg,
+unsigned int *index,
+unsigned int *offset, int size,
+enum dma_data_direction dma_dir,
+int timeout)
 {
struct rtsx_dev *rtsx = chip->rtsx;
struct completion trans_done;
@@ -486,8 +493,9 @@ out:
 }
 
 static int rtsx_transfer_sglist_adma(struct rtsx_chip *chip, u8 card,
-   struct scatterlist *sg, int num_sg,
-   enum dma_data_direction dma_dir, int timeout)
+struct scatterlist *sg, int num_sg,
+

[PATCH v4 4/8] Staging: rts5208: rtsx_transport.c: Add spaces around -

[Shaun Ren]

This patch fixes the following styling issue in rtsx_transport.c
as reported by checkpatch.pl:

CHECK: spaces preferred around that '-' (ctx:VxV)

Signed-off-by: Shaun Ren 
---
 drivers/staging/rts5208/rtsx_transport.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 1a6018a..d8c8436 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -85,8 +85,8 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
while (cnt < buflen && *index < scsi_sg_count(srb)) {
struct page *page = sg_page(sg) +
((sg->offset + *offset) >> PAGE_SHIFT);
-   unsigned int poff =
-   (sg->offset + *offset) & (PAGE_SIZE-1);
+   unsigned int poff = (sg->offset + *offset) &
+   (PAGE_SIZE - 1);
unsigned int sglen = sg->length - *offset;
 
if (sglen > buflen - cnt) {
-- 
2.7.0

[PATCH v4 7/8] Staging: rts5208: rtsx_transport.c: Remove unnecessary parentheses

[Shaun Ren]

This patch removes all unnecessary parentheses found by checkpatch.pl.

Signed-off-by: Shaun Ren 
---
Changes since v3
  * Fixed patch conflicts due to commit 9a66d05d82db
("Staging: rts5208: fix check for dma mapping error"), and
commit b3232842dbef ("Staging: rts5208: remove unnecessary parantheses")

 drivers/staging/rts5208/rtsx_transport.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 0d332f5..be3423a 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -193,7 +193,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
/* set the result so the higher layers expect this data */
srb->result = SAM_STAT_CHECK_CONDITION;
memcpy(srb->sense_buffer,
-  (unsigned char *)&(chip->sense_buffer[SCSI_LUN(srb)]),
+  (unsigned char *)>sense_buffer[SCSI_LUN(srb)],
   sizeof(struct sense_data_t));
}
 
@@ -367,7 +367,7 @@ static int rtsx_transfer_sglist_adma_partial(struct 
rtsx_chip *chip, u8 card,
 
spin_unlock_irq(>reg_lock);
 
-   sg_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+   sg_cnt = dma_map_sg(>pci->dev, sg, num_sg, dma_dir);
 
resid = size;
sg_ptr = sg;
@@ -481,7 +481,7 @@ static int rtsx_transfer_sglist_adma_partial(struct 
rtsx_chip *chip, u8 card,
 out:
rtsx->done = NULL;
rtsx->trans_state = STATE_TRANS_NONE;
-   dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+   dma_unmap_sg(>pci->dev, sg, num_sg, dma_dir);
 
if (err < 0)
rtsx_stop_cmd(chip, card);
@@ -531,7 +531,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip 
*chip, u8 card,
 
spin_unlock_irq(>reg_lock);
 
-   buf_cnt = dma_map_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+   buf_cnt = dma_map_sg(>pci->dev, sg, num_sg, dma_dir);
 
sg_ptr = sg;
 
@@ -629,7 +629,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip 
*chip, u8 card,
 out:
rtsx->done = NULL;
rtsx->trans_state = STATE_TRANS_NONE;
-   dma_unmap_sg(&(rtsx->pci->dev), sg, num_sg, dma_dir);
+   dma_unmap_sg(>pci->dev, sg, num_sg, dma_dir);
 
if (err < 0)
rtsx_stop_cmd(chip, card);
@@ -713,7 +713,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 
card, void *buf,
 out:
rtsx->done = NULL;
rtsx->trans_state = STATE_TRANS_NONE;
-   dma_unmap_single(&(rtsx->pci->dev), addr, len, dma_dir);
+   dma_unmap_single(>pci->dev, addr, len, dma_dir);
 
if (err < 0)
rtsx_stop_cmd(chip, card);
-- 
2.7.0

[PATCH v4 6/8] Staging: rts5208: rtsx_transport.c: Fix label naming convention

[Shaun Ren]

This patch fixes the following naming convention issue in rtsx_transport.c,
as reported by checkpatch.pl:

CHECK: Avoid CamelCase: 

Signed-off-by: Shaun Ren 
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 1ce9b9d..0d332f5 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -172,14 +172,14 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
if (rtsx_chk_stat(chip, RTSX_STAT_ABORT)) {
dev_dbg(rtsx_dev(chip), "-- command was aborted\n");
srb->result = DID_ABORT << 16;
-   goto Handle_Errors;
+   goto handle_errors;
}
 
/* if there is a transport error, reset and don't auto-sense */
if (result == TRANSPORT_ERROR) {
dev_dbg(rtsx_dev(chip), "-- transport indicates error, 
resetting\n");
srb->result = DID_ERROR << 16;
-   goto Handle_Errors;
+   goto handle_errors;
}
 
srb->result = SAM_STAT_GOOD;
@@ -199,7 +199,7 @@ void rtsx_invoke_transport(struct scsi_cmnd *srb, struct 
rtsx_chip *chip)
 
return;
 
-Handle_Errors:
+handle_errors:
return;
 }
 
-- 
2.7.0

[PATCH v4 5/8] Staging: rts5208: rtsx_transport.c: Remove extra newlines

[Shaun Ren]

This patch fixes the following issues in rtsx_transport.c as reported by
checkpatch.pl:

CHECK: Blank lines aren't necessary after an open brace '{'
CHECK: Please don't use multiple blank lines

Signed-off-by: Shaun Ren 
---
 drivers/staging/rts5208/rtsx_transport.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index d8c8436..1ce9b9d 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -90,12 +90,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char 
*buffer,
unsigned int sglen = sg->length - *offset;
 
if (sglen > buflen - cnt) {
-
/* Transfer ends within this s-g entry */
sglen = buflen - cnt;
*offset += sglen;
} else {
-
/* Transfer continues to next s-g entry */
*offset = 0;
++*index;
@@ -152,7 +150,6 @@ void rtsx_stor_get_xfer_buf(unsigned char *buffer,
scsi_set_resid(srb, scsi_bufflen(srb) - buflen);
 }
 
-
 /***
  * Transport routines
  ***/
-- 
2.7.0

[PATCH v4 3/8] Staging: rts5208: rtsx_transport.c: Remove spaces after casts

[Shaun Ren]

This patch removes all spaces after casts in rtsx_transport.c, as reported
by checkpatch.pl:

CHECK: No space is necessary after a cast

Signed-off-by: Shaun Ren 
---
 drivers/staging/rts5208/rtsx_transport.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index 1a4da89..1a6018a 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -72,7 +72,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 */
} else {
struct scatterlist *sg =
-   (struct scatterlist *) scsi_sglist(srb)
+   (struct scatterlist *)scsi_sglist(srb)
+ *index;
 
/*
-- 
2.7.0

[PATCH v4 8/8] Staging: rts5208: rtsx_transport.c: Fix comparisons to NULL

[Shaun Ren]

This patch changes all comparsions to NULL with !..., as reported by
checkpatch.pl.

Signed-off-by: Shaun Ren 
---
 drivers/staging/rts5208/rtsx_transport.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index be3423a..73e50ec 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -338,7 +338,7 @@ static int rtsx_transfer_sglist_adma_partial(struct 
rtsx_chip *chip, u8 card,
struct scatterlist *sg_ptr;
u32 val = TRIG_DMA;
 
-   if ((sg == NULL) || (num_sg <= 0) || !offset || !index)
+   if (!sg || (num_sg <= 0) || !offset || !index)
return -EIO;
 
if (dma_dir == DMA_TO_DEVICE)
@@ -502,7 +502,7 @@ static int rtsx_transfer_sglist_adma(struct rtsx_chip 
*chip, u8 card,
long timeleft;
struct scatterlist *sg_ptr;
 
-   if ((sg == NULL) || (num_sg <= 0))
+   if (!sg || (num_sg <= 0))
return -EIO;
 
if (dma_dir == DMA_TO_DEVICE)
@@ -649,7 +649,7 @@ static int rtsx_transfer_buf(struct rtsx_chip *chip, u8 
card, void *buf,
u32 val = 1 << 31;
long timeleft;
 
-   if ((buf == NULL) || (len <= 0))
+   if (!buf || (len <= 0))
return -EIO;
 
if (dma_dir == DMA_TO_DEVICE)
-- 
2.7.0

[PATCH v4 0/8] Staging: rts5208: Fix coding style

[Shaun Ren]

This set of patches fixes the coding style issues in rtsx_transport.c.

Changes since v3
 * Removed the extraneous SCSI comment in the first patch
 * Removed the last patch (Staging: rts5208: Add missing dma_mapping_error)
   as it is already done in change 9a66d05d82db
   (Staging: rts5208: fix check for dma mapping error)

Changes since v2
 * Incorporated Joshua Clayton's suggestions regarding the block comments



Shaun Ren (8):
  Staging: rts5208: rtsx_transport.c: Cleanup comments
  Staging: rts5208: rtsx_transport.c: Align to open parenthesis
  Staging: rts5208: rtsx_transport.c: Remove spaces after casts
  Staging: rts5208: rtsx_transport.c: Add spaces around -
  Staging: rts5208: rtsx_transport.c: Remove extra newlines
  Staging: rts5208: rtsx_transport.c: Fix label naming convention
  Staging: rts5208: rtsx_transport.c: Remove unnecessary parentheses
  Staging: rts5208: rtsx_transport.c: Fix comparisons to NULL

 drivers/staging/rts5208/rtsx_transport.c | 152 ---
 1 file changed, 81 insertions(+), 71 deletions(-)

-- 
2.7.0

[PATCH v4 1/8] Staging: rts5208: rtsx_transport.c: Cleanup comments

[Shaun Ren]

This patch fixes all multiline comments to conform to the coding style,
which states that multiline comments should start with "/*" and end
with "*/" on a separate line.

Also cleans up some comments to make them more clear and/or reflect what
the code is doing.

Signed-off-by: Shaun Ren 
---
Changes since v3
 * Removed the extraneous SCSI comment in the first patch in
   rtsx_stor_access_xfer_buf()

Changes since v2
 * Cleaned up comments as per Joshua Clayton's suggestions

 drivers/staging/rts5208/rtsx_transport.c | 53 
 1 file changed, 27 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/rts5208/rtsx_transport.c 
b/drivers/staging/rts5208/rtsx_transport.c
index f2eb18e..91fdccf 100644
--- a/drivers/staging/rts5208/rtsx_transport.c
+++ b/drivers/staging/rts5208/rtsx_transport.c
@@ -1,4 +1,5 @@
-/* Driver for Realtek PCI-Express card reader
+/*
+ * Driver for Realtek PCI-Express card reader
  *
  * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
  *
@@ -30,13 +31,15 @@
  * Scatter-gather transfer buffer access routines
  ***/
 
-/* Copy a buffer of length buflen to/from the srb's transfer buffer.
+/*
+ * Copy a buffer of length buflen to/from the srb's transfer buffer.
  * (Note: for scatter-gather transfers (srb->use_sg > 0), srb->request_buffer
  * points to a list of s-g entries and we ignore srb->request_bufflen.
  * For non-scatter-gather transfers, srb->request_buffer points to the
  * transfer buffer itself and srb->request_bufflen is the buffer's length.)
  * Update the *index and *offset variables so that the next copy will
- * pick up from where this one left off. */
+ * pick up from where this one left off.
+ */
 
 unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
unsigned int buflen, struct scsi_cmnd *srb, unsigned int *index,
@@ -44,8 +47,7 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
 {
unsigned int cnt;
 
-   /* If not using scatter-gather, just transfer the data directly.
-* Make certain it will fit in the available buffer space. */
+   /* If not using scatter-gather, just transfer the data directly. */
if (scsi_sg_count(srb) == 0) {
if (*offset >= scsi_bufflen(srb))
return 0;
@@ -58,22 +60,22 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char 
*buffer,
*offset, cnt);
*offset += cnt;
 
-   /* Using scatter-gather.  We have to go through the list one entry
+   /*
+* Using scatter-gather.  We have to go through the list one entry
 * at a time.  Each s-g entry contains some number of pages, and
-* each page has to be kmap()'ed separately.  If the page is already
-* in kernel-addressable memory then kmap() will return its address.
-* If the page is not directly accessible -- such as a user buffer
-* located in high memory -- then kmap() will map it to a temporary
-* position in the kernel's virtual address space. */
+* each page has to be kmap()'ed separately.
+*/
} else {
struct scatterlist *sg =
(struct scatterlist *) scsi_sglist(srb)
+ *index;
 
-   /* This loop handles a single s-g list entry, which may
+   /*
+* This loop handles a single s-g list entry, which may
 * include multiple pages.  Find the initial page structure
 * and the starting offset within the page, and update
-* the *offset and *index values for the next loop. */
+* the *offset and *index values for the next loop.
+*/
cnt = 0;
while (cnt < buflen && *index < scsi_sg_count(srb)) {
struct page *page = sg_page(sg) +
@@ -95,9 +97,6 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char *buffer,
++sg;
}
 
-   /* Transfer the data for all the pages in this
-* s-g entry.  For each page: call kmap(), do the
-* transfer, and call kunmap() immediately after. */
while (sglen > 0) {
unsigned int plen = min(sglen, (unsigned int)
PAGE_SIZE - poff);
@@ -122,8 +121,10 @@ unsigned int rtsx_stor_access_xfer_buf(unsigned char 
*buffer,
return cnt;
 }
 
-/* Store the contents of buffer into srb's transfer buffer and set the
-* SCSI residue. */
+/*
+ * Store the contents of buffer into srb's transfer buffer and set the
+ * SCSI residue.
+ */
 void rtsx_stor_set_xfer_buf(unsigned char *buffer,
unsigned int buflen, struct scsi_cmnd *srb)
 {
@@ -151,7 +152,8 @@ 

[PATCH] regulator: Rename files for max77686 and max77802 drivers

[Javier Martinez Canillas]

The max77686 and max77802 regulator drivers are for sub-devices of a MFD
driver for some PMIC blocks. But the same object file name (max77686.o)
was used for both the common MFD driver and the max77686 regulator one.

This confuses kbuild if both drivers are built as module causing the MFD
driver to not be copied when installing the modules.

Also, max77{686,802} are a quite generic name for MFD subdevices drivers
so it is better to rename them to max77{686,802}-regulator like it's the
case for most regulator drivers.

Signed-off-by: Javier Martinez Canillas 

---

 MAINTAINERS| 2 +-
 drivers/regulator/Makefile | 4 ++--
 drivers/regulator/{max77686.c => max77686-regulator.c} | 0
 drivers/regulator/{max77802.c => max77802-regulator.c} | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename drivers/regulator/{max77686.c => max77686-regulator.c} (100%)
 rename drivers/regulator/{max77802.c => max77802-regulator.c} (100%)

diff --git a/MAINTAINERS b/MAINTAINERS
index 97b99f24ea53..863eb59e101b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6904,7 +6904,7 @@ MAXIM MAX77802 MULTIFUNCTION PMIC DEVICE DRIVERS
 M: Javier Martinez Canillas 
 L: linux-kernel@vger.kernel.org
 S: Supported
-F: drivers/*/*max77802.c
+F: drivers/*/*max77802*.c
 F: Documentation/devicetree/bindings/*/*max77802.txt
 F: include/dt-bindings/*/*max77802.h
 
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 348cfd727350..bd6ae0ccd2e9 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -55,9 +55,9 @@ obj-$(CONFIG_REGULATOR_MAX8952) += max8952.o
 obj-$(CONFIG_REGULATOR_MAX8973) += max8973-regulator.o
 obj-$(CONFIG_REGULATOR_MAX8997) += max8997.o
 obj-$(CONFIG_REGULATOR_MAX8998) += max8998.o
-obj-$(CONFIG_REGULATOR_MAX77686) += max77686.o
+obj-$(CONFIG_REGULATOR_MAX77686) += max77686-regulator.o
 obj-$(CONFIG_REGULATOR_MAX77693) += max77693.o
-obj-$(CONFIG_REGULATOR_MAX77802) += max77802.o
+obj-$(CONFIG_REGULATOR_MAX77802) += max77802-regulator.o
 obj-$(CONFIG_REGULATOR_MC13783) += mc13783-regulator.o
 obj-$(CONFIG_REGULATOR_MC13892) += mc13892-regulator.o
 obj-$(CONFIG_REGULATOR_MC13XXX_CORE) +=  mc13xxx-regulator-core.o
diff --git a/drivers/regulator/max77686.c 
b/drivers/regulator/max77686-regulator.c
similarity index 100%
rename from drivers/regulator/max77686.c
rename to drivers/regulator/max77686-regulator.c
diff --git a/drivers/regulator/max77802.c 
b/drivers/regulator/max77802-regulator.c
similarity index 100%
rename from drivers/regulator/max77802.c
rename to drivers/regulator/max77802-regulator.c
-- 
2.5.0

Re: [GIT PULL] phy: for-4.5 -rc cycle

[Greg KH]

On Wed, Feb 10, 2016 at 12:15:04PM +0530, Kishon Vijay Abraham I wrote:
> Hi Greg,
> 
> Please find the pull request for this -rc cycle below. It contains a fix in
> phy core, twl4030-usb phy driver and a fix in Kconfig.
> 
> Consider merging it to this -rc cycle. Let me know if you want me to change
> anything.
> 
> Cheers
> Kishon
> 
> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
> 
>   Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git 
> tags/phy-for-4.5-rc

Pulled and pushed out, thanks.

greg k-h

Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)

[Aneesh Kumar K.V]

Gerald Schaefer  writes:

> On Thu, 11 Feb 2016 21:09:42 +0200
> "Kirill A. Shutemov"  wrote:
>
>> On Thu, Feb 11, 2016 at 07:22:23PM +0100, Gerald Schaefer wrote:
>> > Hi,
>> > 
>> > Sebastian Ott reported random kernel crashes beginning with v4.5-rc1 and
>> > he also bisected this to commit 61f5d698 "mm: re-enable THP". Further
>> > review of the THP rework patches, which cannot be bisected, revealed
>> > commit fecffad "s390, thp: remove infrastructure for handling splitting 
>> > PMDs"
>> > (and also similar commits for other archs).
>> > 
>> > This commit removes the THP splitting bit and also the architecture
>> > implementation of pmdp_splitting_flush(), which took care of the IPI for
>> > fast_gup serialization. The commit message says
>> > 
>> > pmdp_splitting_flush() is not needed too: on splitting PMD we will do
>> > pmdp_clear_flush() + set_pte_at().  pmdp_clear_flush() will do IPI as
>> > needed for fast_gup
>> > 
>> > The assumption that a TLB flush will also produce an IPI is wrong on s390,
>> > and maybe also on other architectures, and I thought that this was actually
>> > the main reason for having an arch-specific pmdp_splitting_flush().
>> > 
>> > At least PowerPC and ARM also had an individual implementation of
>> > pmdp_splitting_flush() that used kick_all_cpus_sync() instead of a TLB
>> > flush to send the IPI, and those were also removed. Putting the arch
>> > maintainers and mailing lists on cc to verify.
>> > 
>> > On s390 this will break the IPI serialization against fast_gup, which
>> > would certainly explain the random kernel crashes, please revert or fix
>> > the pmdp_splitting_flush() removal.
>> 
>> Sorry for that.
>> 
>> I believe, the problem was already addressed for PowerPC:
>> 
>> http://lkml.kernel.org/g/454980831-16631-1-git-send-email-aneesh.ku...@linux.vnet.ibm.com
>> 
>> I think kick_all_cpus_sync() in arch-specific pmdp_invalidate() would do
>> the trick, right?
>
> Hmm, not sure about that. After pmdp_invalidate(), a pmd_none() check in
> fast_gup will still return false, because the pmd is not empty (at least
> on s390).

Why can't we do this ? I did this for ppc64.

 void pmdp_invalidate(struct vm_area_struct *vma, unsigned long address,
 pmd_t *pmdp)
 {
-   pmd_hugepage_update(vma->vm_mm, address, pmdp, _PAGE_PRESENT, 0);
+   pmd_hugepage_update(vma->vm_mm, address, pmdp, ~0UL, 0);

>So I don't see spontaneously how it will help fast_gup to break
> out to the slow path in case of THP splitting.
>
>> 
>> If yes, I'll prepare patch tomorrow (some sleep required).
>> 
>
> We'll check if adding kick_all_cpus_sync() to pmdp_invalidate() helps.
> It would also be good if Martin has a look at this, he'll return on
> Monday.

-aneesh

Re: [PATCH v2] Staging: fix coding style in rtl8188eu/core

[Greg Kroah-Hartman]

On Wed, Feb 10, 2016 at 10:09:28PM +0100, Colin Vidal wrote:
> Set constant operand on right of test, and refactor the code in a more
> compact and readable way.

Please don't do two different things in the same patch, break this up
into different patches.

thanks,

gregk -h

Re: [GIT PULL] bcm2835 DT changes for 4.6

[Florian Fainelli]

On 10/02/2016 10:51, Eric Anholt wrote:
> Martin Sperl  writes:
> 
>>> On 09.02.2016, at 01:32, Eric Anholt  wrote:
>>>
>>> Hi Florian.  Here's the first set of patches for bcm2835 for 4.6.
>>> We've got more DT patches that are going to happen for new boards,
>>> too, but they're still getting polished.
>>>
>>> The following changes since commit 92e963f50fc74041b5e9e744c330dca48e04f08d:
>>>
>>>  Linux 4.5-rc1 (2016-01-24 13:06:47 -0800)
>>>
>>> are available in the git repository at:
>>>
>>>  g...@github.com:anholt/linux.git tags/bcm2835-dt-next-2016-02-04
>>>
>>> for you to fetch changes up to 5ec6f2cd8ec4bcd38ba199ea8711a5ec906d85e7:
>>>
>>>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT. 
>>> (2016-02-02 20:02:45 -0800)
>>>
>>> 
>>> This pull request covers mostly DT changes that didn't make it into
>>> 4.5 because required header files went through other trees.
>>>
>>> 
>>> Alexander Aring (1):
>>>  ARM: bcm2835: Add the Raspberry Pi power domain driver to the DT.
>>>
>>> Lubomir Rintel (1):
>>>  ARM: bcm2835: dt: Add Raspberry Pi Model A
>>>
>>> Martin Sperl (2):
>>>  ARM: bcm2835: add the auxiliary spi1 and spi2 to the device tree
>>>  ARM: bcm2835: follow dt uart node-naming convention
>>
>> Do you want me to resend a rebased version of:
>>  ARM: bcm2835: add bcm2835-aux-uart support to default DT
>>
>> The corresponding driver has been added to tty/tty-next.
> 
> It hadn't landed last time I checked.  A rebased version that you've
> tested would be great!

OK, please submit this in the next week or so at most, so we can get
this pull request merged, thanks!

Eric, do you have other changes outside of Device Tree?
--
Florian

[GIT PULL] xfs: fixes for 4.5-rc4

[Dave Chinner]

Hi Linus,

Can you please pull the XFS commit from the tag below? It contains a
fix for a regression introduced in 4.5-rc1 by the new log recovery
CRC validation code. Thanks!

-Dave.

The following changes since commit 36f90b0a2ddd60823fe193a85e60ff1906c2a9b3:

  Linux 4.5-rc2 (2016-01-31 18:12:16 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git 
tags/xfs-fixes-for-linus-4.5

for you to fetch changes up to 8e0bd4925bf693520295de403483efad4dc5cc16:

  xfs: fix endianness error when checking log block crc on big endian platforms 
(2016-02-08 11:03:58 +1100)


xfs: updates for 4.5-rc4

Contains:
o fix for endian conversion issue in new CRC validation in
  log recovery that was discovered on a ppc64 platform.


Darrick J. Wong (1):
  xfs: fix endianness error when checking log block crc on big endian 
platforms

 fs/xfs/xfs_log_recover.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
-- 
Dave Chinner
da...@fromorbit.com

Re: [tpmdd-devel] [PATCH] tpm: fix the cleanup of struct tpm_chip

[Jarkko Sakkinen]

On Thu, Feb 11, 2016 at 12:34:15PM -0700, Jason Gunthorpe wrote:
> On Tue, Feb 09, 2016 at 05:30:30AM +0200, Jarkko Sakkinen wrote:
> > If the initialization fails before tpm_chip_register(), put_device()
> > will be not called, which causes release callback not to be called.
> > This patch fixes the issue by adding put_device() to devres list of
> > the parent device.
> > 
> > Fixes: 313d21eeab ("tpm: device class for tpm")
> > Signed-off-by: Jarkko Sakkinen 
> > cc: sta...@vger.kernel.org
> >  drivers/char/tpm/tpm-chip.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> > index 1a9dcee..ea904d1 100644
> > +++ b/drivers/char/tpm/tpm-chip.c
> > @@ -136,6 +136,8 @@ struct tpm_chip *tpmm_chip_alloc(struct device *dev,
> > chip->cdev.owner = chip->pdev->driver->owner;
> > chip->cdev.kobj.parent = >dev.kobj;
> >  
> > +   devm_add_action(dev, (void (*)(void *)) put_device, >dev);
> > +
> 
> Erm, don't forget the error handling here.
> 
> Something like this:
> 
>   rc = devm_add_action(dev, (void (*)(void *)) put_device, >dev);
>   if (rc) {
>   put_device(>dev);
>   return ERR_PTR(rc);
>   }

I'll implement that as a separate commit since it is already in pull
request. Thanks.

/Jarkko

Re: [PATCH v2] hpet: drop stale link

[Greg Kroah-Hartman]

On Thu, Feb 11, 2016 at 01:05:01AM +0200, Michael S. Tsirkin wrote:
> Looks like the HPET spec at intel.com got moved.
> It isn't hard to find so drop the link, just mention
> the revision assumed.
> 
> Suggested-by: Thomas Gleixner 
> Signed-off-by: Michael S. Tsirkin 
> ---
> 
> Changes from v1:
>   actually drop the links, just say "revision 1"
>   in case a new one ever comes out.
> 
>  drivers/char/hpet.c   | 2 +-
>  Documentation/timers/hpet.txt | 4 +---
>  arch/x86/Kconfig  | 4 ++--
>  3 files changed, 4 insertions(+), 6 deletions(-)
> 

Acked-by: Greg Kroah-Hartman 

Re: [PATCH v5 RESEND 3/5] driver core: handle -EPROBE_DEFER from bus_type.match()

[Greg Kroah-Hartman]

On Wed, Feb 10, 2016 at 11:47:28AM +0100, Marek Szyprowski wrote:
> From: Tomeu Vizoso 
> 
> Allow implementations of the match() callback in struct bus_type to
> return errors and if it's -EPROBE_DEFER then queue the device for
> deferred probing.
> 
> This is useful to buses such as AMBA in which devices are registered
> before their matching information can be retrieved from the HW
> (typically because a clock driver hasn't probed yet).
> 
> Signed-off-by: Tomeu Vizoso 
> [changed if-else code structure, adjusted documentation to match the code,
> extended comments]
> Signed-off-by: Marek Szyprowski 
> Reviewed-by: Ulf Hansson 
> ---
>  Documentation/driver-model/porting.txt |  6 --
>  drivers/base/dd.c  | 24 ++--
>  include/linux/device.h |  7 +--
>  3 files changed, 31 insertions(+), 6 deletions(-)


Acked-by: Greg Kroah-Hartman 

Re: [PATCH v2] let kernfs_name_locked & kernfs_name return size_t

[Greg KH]

On Wed, Feb 10, 2016 at 08:07:05PM +0100, Christian Brauner wrote:
> Simple patch that changes the return value of kernfs_name_locked and 
> kernfs_name
> to size_t which alignes these functions with kernfs_path_len which also 
> returns
> size_t.
> 
> Patch was made against for-4.5 branch of Tejun's cgroup tree.  (As per Tejun's
> request, ccing gre...@linuxfoundation.org and linux-kernel@vger.kernel.org.)
> 
> Changelog
> 20150210: - Change return type of kernfs_name in kernfs.h as well.
>   - Build tested against Tejun's for-4.5 tree, 4.5-rc2 and
> mainline 4.5-rc3.
> 
> *Note*, the changes in kernfs.h change the dummy return value of the static
> inline definition of kernfs_name from -ENOSYS. I changed it to 0 analogous to
> kernfs_path_len. I don't know if this is considered a deal-breaker.

Please don't change that, that's a behavior change, not just a "cleanup
the return type" change.

thanks,

greg k-h

Re: [PATCH v8 2/4] tee: generic TEE subsystem

[Greg Kroah-Hartman]

On Thu, Feb 11, 2016 at 06:14:35PM +0100, Jens Wiklander wrote:
> Initial patch for generic TEE subsystem.
> This subsystem provides:
> * Registration/un-registration of TEE drivers.
> * Shared memory between normal world and secure world.
> * Ioctl interface for interaction with user space.
> * Sysfs implementation_id of TEE driver
> 
> A TEE (Trusted Execution Environment) driver is a driver that interfaces
> with a trusted OS running in some secure environment, for example,
> TrustZone on ARM cpus, or a separate secure co-processor etc.
> 
> The TEE subsystem can serve a TEE driver for a Global Platform compliant
> TEE, but it's not limited to only Global Platform TEEs.
> 
> This patch builds on other similar implementations trying to solve
> the same problem:
> * "optee_linuxdriver" by among others
>   Jean-michel DELORME and
>   Emmanuel MICHEL 
> * "Generic TrustZone Driver" by Javier González 
> 
> Signed-off-by: Jens Wiklander 

I need you to get other people to review this before I can accept this
series.  Please do that, surely someone else cares about this code
becides you?

thanks,

greg k-h

Re: [PATCH] Documentation: SubmittingPatches: Add note about Reviewed-by tags

[Anup Patel]

On Fri, Feb 12, 2016 at 7:42 AM, Florian Fainelli  wrote:
> As is now common in a lot of organization having an internal code review
> process (be it through Gerritt or other tools), patches extracted from
> this review process and submitted to public mailing-lists will have
> pre-existing Reviewed-by tags. Add a note about why these tags exists,
> and what a maintainer could be doing with those. Some maintainers did
> complain before that these tags had to be added when the patches get
> submitted to the public, while some just ignored and took the patches
> as-is.
>
> Signed-off-by: Florian Fainelli 
> ---
>  Documentation/SubmittingPatches | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
> index d603fa078235..b1b8e39bc5ee 100644
> --- a/Documentation/SubmittingPatches
> +++ b/Documentation/SubmittingPatches
> @@ -582,6 +582,14 @@ reviewers and to inform maintainers of the degree of 
> review which has been
>  done on the patch.  Reviewed-by: tags, when supplied by reviewers known to
>  understand the subject area and to perform thorough reviews, will normally
>  increase the likelihood of your patch getting into the kernel.
> +The presence of Reviewed-by tags for an initial patch submission are 
> indicative
> +of an existing internal review process that may occur at various 
> organizations,
> +prior to a mainline kernel submission.  The presence of these tags can give 
> the
> +maintainer a good appreciation that somebody has done an internal review
> +following the same guidelines as those done on a public mailing-list.
> +Maintainers are encouraged to maintain these tags while accepting and merging
> +patches, appreciation of these pre-existing Revivewed-by tags is left are 
> their
> +own discretion.

Typo fix "left are their own discretion" -> "left at their own discretion".

>
>  A Suggested-by: tag indicates that the patch idea is suggested by the person
>  named and ensures credit to the person for the idea. Please note that this
> --
> 2.1.0
>

Regards,
Anup

Re: [BUG REPORT] use of unreachable() masks uninitialized variables warnings

[Theodore Ts'o]

On Thu, Feb 11, 2016 at 11:12:12AM -0700, Jeff Merkey wrote:
> 
> That's good to know, they could be false positives, but it was kind of
> wierd behavior caused by that macro.

If it is true, it sounds more like a compiler bug to me.  Any
statements a BUG() call are unreachable.  If the compiler assumes that
in the case of:

if (a)
BUG();
printf("foo bar\n");

That the printf is not reachable, that's a compiler bug.  And not a
problem in the BUG() macro.

It might be that it's worthwhile to use other static code analysis
tools.  Many people will look at warnings from Coverity and clang to
find potential problems, since these tend to find more warnings than
just using gcc.  The problem with some of these, including Coverity,
is that they can be __too__ noisy, and if 90% of the warnings are
false positives, most people won't take the time to weed out several
dozen bogus warnings to find the one good one.

In your case, for example, I looked through several dozen warnings,
and they were ***all*** bogus.  Keep in mind that this might make me
less inclined to pay attention to complaints from you in the future.
The story of the buy who cried wolf too often comes to mind.

Perhaps you could actually take a close look at the warnings, before
you fire off an e-mail?  If at least one of the warnings were valid
and pointed at an actual bug, it wouldn't have been a complete waste
of my time

Best regards,

- Ted

linux-next: manual merge of the kvm-arm tree with the arm64 tree

[Stephen Rothwell]

Hi all,

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

  arch/arm/kvm/arm.c

between commit:

  6a26b548a2c4 ("arm64: kvm: deal with kernel symbols outside of linear 
mapping")

from the arm64 tree and commit:

  aa0bf2030bca ("ARM: KVM: Remove __kvm_hyp_code_start/__kvm_hyp_code_end")

from the kvm-arm tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/kvm/arm.c
index 975da6cfbf59,fcf6c130c986..
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@@ -982,9 -982,10 +982,10 @@@ static void cpu_init_hyp_mode(void *dum
pgd_ptr = kvm_mmu_get_httbr();
stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
hyp_stack_ptr = stack_page + PAGE_SIZE;
 -  vector_ptr = (unsigned long)__kvm_hyp_vector;
 +  vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
  
__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
+   __cpu_init_stage2();
  
kvm_arm_init_debug();
  }
@@@ -1074,8 -1075,7 +1075,8 @@@ static int init_hyp_mode(void
/*
 * Map the Hyp-code called directly from the host
 */
-   err = create_hyp_mappings(kvm_ksym_ref(__kvm_hyp_code_start),
- kvm_ksym_ref(__kvm_hyp_code_end));
 -  err = create_hyp_mappings(__hyp_text_start, __hyp_text_end);
++  err = create_hyp_mappings(kvm_ksym_ref(__hyp_text_start),
++kvm_ksym_ref(__hyp_text_end));
if (err) {
kvm_err("Cannot map world-switch code\n");
goto out_free_mappings;

[PATCH] Documentation: SubmittingPatches: Add note about Reviewed-by tags

[Florian Fainelli]

As is now common in a lot of organization having an internal code review
process (be it through Gerritt or other tools), patches extracted from
this review process and submitted to public mailing-lists will have
pre-existing Reviewed-by tags. Add a note about why these tags exists,
and what a maintainer could be doing with those. Some maintainers did
complain before that these tags had to be added when the patches get
submitted to the public, while some just ignored and took the patches
as-is.

Signed-off-by: Florian Fainelli 
---
 Documentation/SubmittingPatches | 8 
 1 file changed, 8 insertions(+)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index d603fa078235..b1b8e39bc5ee 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -582,6 +582,14 @@ reviewers and to inform maintainers of the degree of 
review which has been
 done on the patch.  Reviewed-by: tags, when supplied by reviewers known to
 understand the subject area and to perform thorough reviews, will normally
 increase the likelihood of your patch getting into the kernel.
+The presence of Reviewed-by tags for an initial patch submission are indicative
+of an existing internal review process that may occur at various organizations,
+prior to a mainline kernel submission.  The presence of these tags can give the
+maintainer a good appreciation that somebody has done an internal review
+following the same guidelines as those done on a public mailing-list.
+Maintainers are encouraged to maintain these tags while accepting and merging
+patches, appreciation of these pre-existing Revivewed-by tags is left are their
+own discretion.
 
 A Suggested-by: tag indicates that the patch idea is suggested by the person
 named and ensures credit to the person for the idea. Please note that this
-- 
2.1.0

Re: [PATCH 1/2] pinctrl: mediatek: fix direction control issue

[Hongzhou Yang]

On Fri, 2016-02-05 at 14:52 +0100, Linus Walleij wrote:
> On Thu, Feb 4, 2016 at 4:03 AM, Hongzhou Yang
>  wrote:
> > On Wed, 2016-02-03 at 09:24 +0800, Biao Huang wrote:
> >> Since input-enable/disable and input-schmitt-enable/disable are
> >> workable when gpio direction is input, so add direction setting
> >> when do input-enable/disable and input-schmitt-enable/disable
> >> properties.
> >>
> >> Signed-off-by: Biao Huang 
> >> ---
> >>  drivers/pinctrl/mediatek/pinctrl-mtk-common.c |2 ++
> >>  1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c 
> >> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> >> index 8cac73d..6eb01c9 100644
> >> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> >> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> >> @@ -352,6 +352,7 @@ static int mtk_pconf_parse_conf(struct pinctrl_dev 
> >> *pctldev,
> >>   ret = mtk_pconf_set_pull_select(pctl, pin, true, false, arg);
> >>   break;
> >>   case PIN_CONFIG_INPUT_ENABLE:
> >> + mtk_pmx_gpio_set_direction(pctldev, NULL, pin, true);
> >>   ret = mtk_pconf_set_ies_smt(pctl, pin, arg, param);
> >
> > Hi Linus,
> >
> > From pinctrl-bindings.txt, 'input-enable' property defined as following:
> > input-enable- enable input on pin (no effect on output)
> >
> > Since input enable and input direction are two different settings on our
> > SOC,
> 
> What does this mean? How can input have a "direction"?
> 
> Isn't the direction of an input always inbound, into the SoC?
> 
> Please elaborate.

Sorry for the late reply.
There are two conditions if external device input data into SOC.
1. Change GPIO direction to input.
2. Switch on input.


> > could you tell me the exact meaning of this property? Input enable
> > only? Or set input direction at the same time?
> 
> This was added in commit 8ba3f4d00078e7a49c60c0bd6298f29402c3a0a0
> "pinctrl: Adds slew-rate, input-enable/disable"
> by Sherman Yin so let's ask him first.

Thanks for this info.
>From Sherman's comment, PIN_CONFIG_INPUT_ENABLE seems only to stand for
the condition 2.

* @PIN_CONFIG_INPUT_ENABLE: enable the pin's input.  Note that this does
not affect the pin's ability to drive output.  1 enables input, 0
disables input.

Then I get confuse if we can change direction under this property.

Thanks.
Hongzhou

[PATCH v8 01/10] mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
Acked-by: Rob Herring 
Acked-by: Lee Jones 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index a474359dd206..fd39fa54571b 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -5,11 +5,12 @@ axp152 (X-Powers)
 axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
+axp223 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221"
-- reg: The I2C slave address for the AXP chip
+ "x-powers,axp221", "x-powers,axp223"
+- reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
@@ -51,7 +52,7 @@ LDO3  : LDO   : ldo3in-supply
 LDO4   : LDO   : ldo24in-supply: shared supply
 LDO5   : LDO   : ldo5in-supply
 
-AXP221 regulators, type, and corresponding input supply names:
+AXP221/AXP223 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
 ---- -
-- 
2.7.0

[PATCH v8 00/10] mfd: axp20x: Add support for RSB based AXP223

[Chen-Yu Tsai]

Hi everyone,

This is v8 of the AXP223 PMIC series. All the driver bits are acked.
Lee, please merge the first 8 patches. Once they're in, Maxime can take
the DTS patches.

Changes since v7:

  - Shortened commit message of "mfd: axp20x: Add missing copyright notice"

Changes since v6:

  - Add copyright notice to axp20x-rsb.c

  - Correct order of header files in axp20x-rsb.c

  - Use generic dev_set_drvdata() instead of sunxi_rsb_device_set_drvdata()

  - Drop file name from file headers

  - Add patch adding missing copyright notice for original axp20x author

Changes since v5:

  - Correct AXP223 address to 0x3a3.

Changes since v4:

  - Get rid of second parameter of axp20x_match_device() (new patch 2)

  - Match against dev->driver->of_match_table, so the entirety of
axp20x_match_device() can be kept in the core. (new patch 3)

  - Move *_device_id tables to bottom of the driver, right above driver
declaration. (patch 4 & 6)

  - Remove extra whitespaces while moving i2c specific code (patch 4)

  - Remove leftover whitespace and code style issues in axp20x core
(new patch 5)

  - Remove extra whitespaces in rsb specific code (patch 6)

Changes since v3:

  - Removed settings for axp223 reg_rtc_ldo from board dts files that
are already in axp22x.dtsi. The name is kept.

  - Dropped simplefb label and defconfig patches, as they are merged.

Changes since v2:

  - s/It's/Its/ for the commit messages of patches 5 and 7

  - Add Rob's Acked-by for patch 1

Changes since v1:

  - Dropped NMI interrupt controller dts patch (Merged)

  - Change MFD_AXP20X to represent the axp20x core, and drop MFD_AXP20X_CORE
  
  - Keep the axp20x core bits named axp20x.c

  - Add patch 7 to add AXP223 to sun8i-q8-common.dtsi

  - Add patch 8 & 9 to update defconfigs

  - Make axp20x drivers tristate and buildable as modules

  - Drop "_sunxi" substring from identifiers in axp20x-rsb driver


This series adds support for the Reduced Serial Bus based AXP223 PMIC.
The AXP223 is functionally identical to the AXP221, which we already
support. Only some default values for the regulators are different.
The defaults fit their recommended application, paired with different
SoCs.

Patch 1 adds AXP223 to the list of supported chips in the DT binding.

Patch 2 gets rid of the extra "struct device *" parameter from
axp20x_match_device().

Patch 3 makes axp20x_match_device() use dev->driver->of_match_table,
so the function can be library-ized without modification.

Patch 4 adds the missing copyright notice for axp20x's original author.

Patch 5 splits the axp20x mfd driver into 2 parts, a core library, and
an I2C driver.

Patch 6 cleans up some leftover whitespace issues in axp20x core.

Patch 7 adds an RSB based driver for the AXP223.

Patch 8 adds support for the AXP223 regulators

Patch 9 enables the AXP223 PMIC and its regulators for the Sinlinx
SinA33.

Patch 10 enables the AXP223 PMIC and its regulators for A23/A33 based
Q8 tablet devices.


Regards
ChenYu


Chen-Yu Tsai (10):
  mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
  mfd: axp20x: Remove second struct device * parameter for
axp20x_match_device()
  mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device()
  mfd: axp20x: Add missing copyright notice
  mfd: axp20x: Split the driver into core and i2c bits
  mfd: axp20x: Whitespace, open parenthesis alignment code style fixes
  mfd: axp20x: Add support for RSB based AXP223 PMIC
  regulator: axp20x: Support new AXP223 PMIC
  ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator
nodes
  ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes

 Documentation/devicetree/bindings/mfd/axp20x.txt |   7 +-
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts   |  76 +++-
 arch/arm/boot/dts/sun8i-q8-common.dtsi   |  83 +-
 drivers/mfd/Kconfig  |  25 --
 drivers/mfd/Makefile |   2 +
 drivers/mfd/axp20x-i2c.c | 104 ++
 drivers/mfd/axp20x-rsb.c |  80 +
 drivers/mfd/axp20x.c | 105 ++-
 drivers/regulator/axp20x-regulator.c |   3 +
 include/linux/mfd/axp20x.h   |  34 +++-
 10 files changed, 425 insertions(+), 94 deletions(-)
 create mode 100644 drivers/mfd/axp20x-i2c.c
 create mode 100644 drivers/mfd/axp20x-rsb.c

-- 
2.7.0

[PATCH v8 03/10] mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device()

[Chen-Yu Tsai]

In axp20x_match_device(), match the of_device_id table bound to the
device driver instead of pointing to axp20x_of_match directly. This
will allow us to keep axp20x_match_device() unmodified when we expand
the axp20x driver into multiple ones covering different interface
types.

of_device_get_match_data() cannot be used here as we need to know if
it failed to get a match, or if the match data value just happened to
be 0, as it is for the AXP152.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Lee Jones 
---
 drivers/mfd/axp20x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 685a78614f83..3e186f2dcac3 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -613,7 +613,7 @@ static int axp20x_match_device(struct axp20x_dev *axp20x)
const struct of_device_id *of_id;
 
if (dev->of_node) {
-   of_id = of_match_device(axp20x_of_match, dev);
+   of_id = of_match_device(dev->driver->of_match_table, dev);
if (!of_id) {
dev_err(dev, "Unable to match OF ID\n");
return -ENODEV;
-- 
2.7.0

[PATCH v8 06/10] mfd: axp20x: Whitespace, open parenthesis alignment code style fixes

[Chen-Yu Tsai]

This fixes some leftover code style issues in the axp20x core.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Lee Jones 
---
 drivers/mfd/axp20x.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 8e569bcfe3bc..3054ea4b95e8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -593,14 +593,14 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
dev_err(dev, "Unable to match OF ID\n");
return -ENODEV;
}
-   axp20x->variant = (long) of_id->data;
+   axp20x->variant = (long)of_id->data;
} else {
acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
if (!acpi_id || !acpi_id->driver_data) {
dev_err(dev, "Unable to match ACPI ID and data\n");
return -ENODEV;
}
-   axp20x->variant = (long) acpi_id->driver_data;
+   axp20x->variant = (long)acpi_id->driver_data;
}
 
switch (axp20x->variant) {
@@ -634,7 +634,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
return -EINVAL;
}
dev_info(dev, "AXP20x variant %s found\n",
-   axp20x_model_names[axp20x->variant]);
+axp20x_model_names[axp20x->variant]);
 
return 0;
 }
@@ -654,7 +654,7 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
}
 
ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
-   axp20x->nr_cells, NULL, 0, NULL);
+ axp20x->nr_cells, NULL, 0, NULL);
 
if (ret) {
dev_err(axp20x->dev, "failed to add MFD devices: %d\n", ret);
-- 
2.7.0

[PATCH v8 02/10] mfd: axp20x: Remove second struct device * parameter for axp20x_match_device()

[Chen-Yu Tsai]

The first argument passed to axp20x_match_device(), struct axp20x_dev *,
already contains a pointer to the device. By rearranging some code,
moving the assignment of the pointer before axp20x_match_device() is
called, we can eliminate the second parameter.

Suggested-by: Andy Shevchenko 
Signed-off-by: Chen-Yu Tsai 
Acked-by: Lee Jones 
---
 drivers/mfd/axp20x.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 9842199e2e6c..685a78614f83 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -606,8 +606,9 @@ static void axp20x_power_off(void)
 AXP20X_OFF);
 }
 
-static int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
+static int axp20x_match_device(struct axp20x_dev *axp20x)
 {
+   struct device *dev = axp20x->dev;
const struct acpi_device_id *acpi_id;
const struct of_device_id *of_id;
 
@@ -673,14 +674,14 @@ static int axp20x_i2c_probe(struct i2c_client *i2c,
if (!axp20x)
return -ENOMEM;
 
-   ret = axp20x_match_device(axp20x, >dev);
-   if (ret)
-   return ret;
-
axp20x->i2c_client = i2c;
axp20x->dev = >dev;
dev_set_drvdata(axp20x->dev, axp20x);
 
+   ret = axp20x_match_device(axp20x);
+   if (ret)
+   return ret;
+
axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
if (IS_ERR(axp20x->regmap)) {
ret = PTR_ERR(axp20x->regmap);
-- 
2.7.0

Re: [linux-sunxi] Re: [PATCH v7 04/10] mfd: axp20x: Add missing copyright notice

[Chen-Yu Tsai]

On Thu, Feb 11, 2016 at 11:24 PM, Lee Jones  wrote:
> On Mon, 25 Jan 2016, Lee Jones wrote:
>
>> On Wed, 13 Jan 2016, Chen-Yu Tsai wrote:
>>
>> > When the driver was merged, the original author did not include a proper
>> > copyright notice. This patch adds the notice, backdated to when the
>> > driver was merged.
>>
>> This is very wordy.
>>
>> "Supply a backdated copyright notice."
>
> Can you re-submit this set with this fixed and the Acks you collected?

Just did. Hopefully you'll see it in your inbox, and not your spam folder.

Thanks
ChenYu

[PATCH v8 08/10] regulator: axp20x: Support new AXP223 PMIC

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Mark Brown 
---
 drivers/regulator/axp20x-regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index f2e1a39ce0f3..e86d1fc2d80b 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,7 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
step = 75;
break;
case AXP221_ID:
+   case AXP223_ID:
min = 1800;
max = 4050;
def = 3000;
@@ -322,6 +323,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev 
*rdev, int id, u32 work
break;
 
case AXP221_ID:
+   case AXP223_ID:
if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5)
return -EINVAL;
 
@@ -360,6 +362,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
nregulators = AXP20X_REG_ID_MAX;
break;
case AXP221_ID:
+   case AXP223_ID:
regulators = axp22x_regulators;
nregulators = AXP22X_REG_ID_MAX;
break;
-- 
2.7.0

[PATCH v8 10/10] ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes

[Chen-Yu Tsai]

A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. Its
regulators provide power to various parts of the SoC and the board.

Also add lcd regulator supply for simplefb and update the existing
vmmc-supply for mmc0.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-q8-common.dtsi | 83 +-
 1 file changed, 81 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi 
b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index 1a69231d2da5..9d2b7e2f5975 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -56,7 +56,6 @@
brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
default-brightness-level = <8>;
enable-gpios = < 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
-   /* backlight is powered by AXP223 DC1SW */
};
 
chosen {
@@ -67,7 +66,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_q8>;
-   vmmc-supply = <_vcc3v0>;
+   vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -92,6 +91,82 @@
 
 _rsb {
status = "okay";
+
+   axp22x: pmic@3a3 {
+   compatible = "x-powers,axp223";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   eldoin-supply = <_dcdc1>;
+   };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <235>;
+   regulator-max-microvolt = <265>;
+   regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <270>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dc1sw {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-lcd";
+};
+
+_dc5ldo {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+   regulator-name = "vcc-rtc";
 };
 
 _uart {
@@ -99,3 +174,7 @@
pinctrl-0 = <_uart_pins_a>;
status = "okay";
 };
+
+_lcd {
+   vcc-lcd-supply = <_dc1sw>;
+};
-- 
2.7.0

[PATCH v8 09/10] ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes

[Chen-Yu Tsai]

This board has a X-Powers AXP223 PMIC connected via RSB. Its regulators
provide power to various parts of the SoC and the board.

Also update the regulator supply phandles.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 76 +-
 1 file changed, 73 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index bd2a3beb4629..fef6abc0a703 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -68,7 +68,7 @@
 };
 
  {
-   vref-supply = <_vcc3v0>;
+   vref-supply = <_dcdc1>;
status = "okay";
 
button@200 {
@@ -96,7 +96,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_sina33>;
-   vmmc-supply = <_vcc3v0>;
+   vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -106,7 +106,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_8bit_pins>;
-   vmmc-supply = <_vcc3v0>;
+   vmmc-supply = <_dcdc1>;
bus-width = <8>;
non-removable;
cap-mmc-hw-reset;
@@ -135,6 +135,76 @@
 
 _rsb {
status = "okay";
+
+   axp22x: pmic@3a3 {
+   compatible = "x-powers,axp223";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   eldoin-supply = <_dcdc1>;
+   };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <235>;
+   regulator-max-microvolt = <265>;
+   regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <270>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dc5ldo {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+   regulator-name = "vcc-rtc";
 };
 
  {
-- 
2.7.0

[PATCH v8 05/10] mfd: axp20x: Split the driver into core and i2c bits

[Chen-Yu Tsai]

The axp20x driver assumes the device is i2c based. This is not the
case with later chips, which use a proprietary 2 wire serial bus
by Allwinner called "Reduced Serial Bus".

This patch follows the example of mfd/wm831x and splits it into
an interface independent core, and an i2c specific glue layer.
MFD_AXP20X and the new MFD_AXP20X_I2C are changed to tristate
symbols, allowing the driver to be built as modules.

Whitespace and other style errors in the moved i2c specific code
have been fixed. Included but unused header files are removed as
well.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Lee Jones 
---
 drivers/mfd/Kconfig|  14 +++---
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/axp20x-i2c.c   | 104 +
 drivers/mfd/axp20x.c   |  90 +++
 include/linux/mfd/axp20x.h |  33 +-
 5 files changed, 161 insertions(+), 81 deletions(-)
 create mode 100644 drivers/mfd/axp20x-i2c.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9ca66de0c1c1..0037b9c933d9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -91,14 +91,18 @@ config MFD_BCM590XX
  Support for the BCM590xx PMUs from Broadcom
 
 config MFD_AXP20X
-   bool "X-Powers AXP20X"
+   tristate
select MFD_CORE
-   select REGMAP_I2C
select REGMAP_IRQ
-   depends on I2C=y
+
+config MFD_AXP20X_I2C
+   tristate "X-Powers AXP series PMICs with I2C"
+   select MFD_AXP20X
+   select REGMAP_I2C
+   depends on I2C
help
- If you say Y here you get support for the X-Powers AXP202, AXP209 and
- AXP288 power management IC (PMIC).
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with I2C.
  This driver include only the core APIs. You have to select individual
  components like regulators or the PEK (Power Enable Key) under the
  corresponding menus.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 0f230a6103f8..dba4f99d9044 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -111,6 +111,7 @@ obj-$(CONFIG_PMIC_DA9052)   += da9052-core.o
 obj-$(CONFIG_MFD_DA9052_SPI)   += da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)   += da9052-i2c.o
 obj-$(CONFIG_MFD_AXP20X)   += axp20x.o
+obj-$(CONFIG_MFD_AXP20X_I2C)   += axp20x-i2c.o
 
 obj-$(CONFIG_MFD_LP3943)   += lp3943.o
 obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
new file mode 100644
index ..b1b865822c07
--- /dev/null
+++ b/drivers/mfd/axp20x-i2c.c
@@ -0,0 +1,104 @@
+/*
+ * I2C driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK 
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the I2C variants.
+ *
+ * Copyright (C) 2014 Carlo Caione
+ *
+ * Author: Carlo Caione 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int axp20x_i2c_probe(struct i2c_client *i2c,
+   const struct i2c_device_id *id)
+{
+   struct axp20x_dev *axp20x;
+   int ret;
+
+   axp20x = devm_kzalloc(>dev, sizeof(*axp20x), GFP_KERNEL);
+   if (!axp20x)
+   return -ENOMEM;
+
+   axp20x->dev = >dev;
+   axp20x->irq = i2c->irq;
+   dev_set_drvdata(axp20x->dev, axp20x);
+
+   ret = axp20x_match_device(axp20x);
+   if (ret)
+   return ret;
+
+   axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
+   if (IS_ERR(axp20x->regmap)) {
+   ret = PTR_ERR(axp20x->regmap);
+   dev_err(>dev, "regmap init failed: %d\n", ret);
+   return ret;
+   }
+
+   return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_i2c_remove(struct i2c_client *i2c)
+{
+   struct axp20x_dev *axp20x = i2c_get_clientdata(i2c);
+
+   return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_i2c_of_match[] = {
+   { .compatible = "x-powers,axp152", .data = (void *)AXP152_ID },
+   { .compatible = "x-powers,axp202", .data = (void *)AXP202_ID },
+   { .compatible = "x-powers,axp209", .data = (void *)AXP209_ID },
+   { .compatible = "x-powers,axp221", .data = (void *)AXP221_ID },
+   { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
+
+/*
+ * This is useless for OF-enabled devices, but it is needed by I2C subsystem
+ */
+static const struct i2c_device_id axp20x_i2c_id[] = {
+   { },
+};
+MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
+
+static const struct acpi_device_id 

[PATCH v8 04/10] mfd: axp20x: Add missing copyright notice

[Chen-Yu Tsai]

Supply a backdated copyright notice.

Cc: Carlo Caione 
Signed-off-by: Chen-Yu Tsai 
Acked-by: Carlo Caione 
Acked-by: Lee Jones 
---
 drivers/mfd/axp20x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3e186f2dcac3..cec51e689d1d 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -5,6 +5,8 @@
  * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
  * as well as configurable GPIOs.
  *
+ * Copyright (C) 2014 Carlo Caione
+ *
  * Author: Carlo Caione 
  *
  * This program is free software; you can redistribute it and/or modify
-- 
2.7.0

[PATCH v8 07/10] mfd: axp20x: Add support for RSB based AXP223 PMIC

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Lee Jones 
---
 drivers/mfd/Kconfig| 11 +++
 drivers/mfd/Makefile   |  1 +
 drivers/mfd/axp20x-rsb.c   | 80 ++
 drivers/mfd/axp20x.c   |  2 ++
 include/linux/mfd/axp20x.h |  1 +
 5 files changed, 95 insertions(+)
 create mode 100644 drivers/mfd/axp20x-rsb.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0037b9c933d9..ae3990b5a2bf 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -107,6 +107,17 @@ config MFD_AXP20X_I2C
  components like regulators or the PEK (Power Enable Key) under the
  corresponding menus.
 
+config MFD_AXP20X_RSB
+   tristate "X-Powers AXP series PMICs with RSB"
+   select MFD_AXP20X
+   depends on SUNXI_RSB
+   help
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with RSB.
+ This driver include only the core APIs. You have to select individual
+ components like regulators or the PEK (Power Enable Key) under the
+ corresponding menus.
+
 config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index dba4f99d9044..c69ea744fd1a 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -112,6 +112,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)+= da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)   += da9052-i2c.o
 obj-$(CONFIG_MFD_AXP20X)   += axp20x.o
 obj-$(CONFIG_MFD_AXP20X_I2C)   += axp20x-i2c.o
+obj-$(CONFIG_MFD_AXP20X_RSB)   += axp20x-rsb.o
 
 obj-$(CONFIG_MFD_LP3943)   += lp3943.o
 obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
new file mode 100644
index ..28c20247c112
--- /dev/null
+++ b/drivers/mfd/axp20x-rsb.c
@@ -0,0 +1,80 @@
+/*
+ * RSB driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK 
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the RSB variants.
+ *
+ * Copyright (C) 2015 Chen-Yu Tsai
+ *
+ * Author: Chen-Yu Tsai 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int axp20x_rsb_probe(struct sunxi_rsb_device *rdev)
+{
+   struct axp20x_dev *axp20x;
+   int ret;
+
+   axp20x = devm_kzalloc(>dev, sizeof(*axp20x), GFP_KERNEL);
+   if (!axp20x)
+   return -ENOMEM;
+
+   axp20x->dev = >dev;
+   axp20x->irq = rdev->irq;
+   dev_set_drvdata(>dev, axp20x);
+
+   ret = axp20x_match_device(axp20x);
+   if (ret)
+   return ret;
+
+   axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev, axp20x->regmap_cfg);
+   if (IS_ERR(axp20x->regmap)) {
+   ret = PTR_ERR(axp20x->regmap);
+   dev_err(>dev, "regmap init failed: %d\n", ret);
+   return ret;
+   }
+
+   return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
+{
+   struct axp20x_dev *axp20x = sunxi_rsb_device_get_drvdata(rdev);
+
+   return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_rsb_of_match[] = {
+   { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+   { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
+
+static struct sunxi_rsb_driver axp20x_rsb_driver = {
+   .driver = {
+   .name   = "axp20x-rsb",
+   .of_match_table = of_match_ptr(axp20x_rsb_of_match),
+   },
+   .probe  = axp20x_rsb_probe,
+   .remove = axp20x_rsb_remove,
+};
+module_sunxi_rsb_driver(axp20x_rsb_driver);
+
+MODULE_DESCRIPTION("PMIC MFD sunXi RSB driver for AXP20X");
+MODULE_AUTHOR("Chen-Yu Tsai ");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 3054ea4b95e8..a57d6e940610 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -35,6 +35,7 @@ static const char * const axp20x_model_names[] = {
"AXP202",
"AXP209",
"AXP221",
+   "AXP223",
"AXP288",
 };
 
@@ -618,6 +619,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP221_ID:
+   case AXP223_ID:
axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
axp20x->cells = axp22x_cells;

Re: [PATCH] scripts/dtc: dtx_diff - add info to error message

[Rob Herring]

On Thu, Feb 11, 2016 at 6:50 PM, Frank Rowand  wrote:
> On 2/2/2016 11:02 AM, Frank Rowand wrote:
>> From: Frank Rowand 
>>
>> If kernel config options are not properly set, "make scripts" will not
>> compile dtc.  Update the unable to find dtc error message to check
>> the kernel config and give better advice on how to create dtc.
>>
>> Reword another error message to increase clarity.
>>
>> Signed-off-by: Frank Rowand 
>
> < snip >
>
> Ping, no reply on original email.

No comment, no reply. I only reply with "applied" when I actually
apply stuff which tends to be at least several weeks. Otherwise, I
might tell you applied and then miss it. :)

Anyway, now applied.

> In the thread about the of ir msi-map patch you mentioned that you have 
> nothing
> else queued for 4.5.  Is dtx_diff (and hopefully this patch) queued up for 
> 4.6?
> If so, could they instead go into 4.5 since they are support tools, and do not
> directly impact the kernel?

It's not a fix either though, so no, it's queued for 4.6 and has been
since -rc1.

Rob

Re: [PATCH v6 0/3] cpufreq: Replace timers with utilization update callbacks

[Rafael J. Wysocki]

On Fri, Feb 12, 2016 at 2:02 AM, Doug Smythies  wrote:
> On 2016.02.11 15:28 Rafael J. Wysocki wrote:
>> On 2106.02.11 14:50 Doug Smythies wrote:
>
>>> What I do have from my 2 hour idle tests is the of total number of passes 
>>> through
>>> the intel_pstate driver:
>>>
>>> Control sample: Kernel 4.3-rc3: 37949 passes.
>>> Kernel 4.3-rc3 + rjw 3 patch set v5: 180355 passes
>>> Kernel 4.3-rc3 + rjw 3 patch set v6: 201307 passes
>>> Kernel 4.3-rc3 + rjw 3 patch set v7: 203619 passes
>
>> That reflects how things work with the changes.  The driver is called
>> more often now and has to decide whether or not to take a sample.
>
> Opps. I didn't understand that point, and so only now looked more
> closely at the code.
>
>> It would be interesting to see how many of those were samples that
>> were actually taken if you can instrument that.
>
> So, those are samples that were taken. There is no trace information
> acquired when the new code decides not to take a sample (or so is my
> understanding from a quick look).

That's correct.  The trace only covers the samples that were actually taken.

> I did find a couple of cases where the duration (elapsed time between
> samples on a given CPU) was less than the nominal sample time. The search
> was not exhaustive. (Likely O.K. within expected jitter, just noting
> is all. The post processing tools use the kernel clock to do the
> calculation, as the duration calculated by the driver is not in the trace
> data.)
>
> 2 hour idle test: v5 patch 9.955 mSec sample 10078 CPU 1
> 2 hour idle test: v7 patch 9.968 mSec sample 49476 CPU 3
> Duration load test: v7 patch 9.982 mSec sample 10997 CPU 2

OK, so the order of magnitude looks reasonable at least.

Thanks,
Rafael

Re: WARNING: CPU: 0 PID: 3031 at ./arch/x86/include/asm/fpu/internal.h:530 fpu__restore+0x90/0x130()

[Andy Lutomirski]

On Thu, Feb 11, 2016 at 3:47 PM, Andy Lutomirski  wrote:
> On Thu, Feb 11, 2016 at 11:27 AM, Borislav Petkov  wrote:
>> Hey Andy,
>>
>> can you make any sense of this:
>>
>> [   90.573923] [ cut here ]
>> [   90.574977] WARNING: CPU: 0 PID: 3031 at 
>> ./arch/x86/include/asm/fpu/internal.h:530 fpu__restore+0x90/0x130()
>> [   90.576108] Modules linked in: hid_generic usbhid hid snd_hda_codec_hdmi 
>> snd_hda_codec_realtek snd_hda_codec_generic iTCO_wdt iTCO_vendor_support 
>> arc4 x86_pkg_temp_thermal coretemp kvm_intel kvm irqbypass crc32_pclmul 
>> crc32c_intel iwldvm mac80211 aesni_intel xts snd_hda_intel input_leds 
>> aes_i586 snd_hda_codec sdhci_pci lrw iwlwifi snd_hwdep gf128mul snd_hda_core 
>> ablk_helper cryptd ehci_pci pcspkr serio_raw xhci_pci sdhci snd_pcm sg 
>> mmc_core i2c_i801 cfg80211 lpc_ich mfd_core e1000e snd_timer ehci_hcd 
>> xhci_hcd thinkpad_acpi nvram wmi snd battery soundcore led_class ac thermal
>> [   90.580570] CPU: 0 PID: 3031 Comm: bash Not tainted 4.5.0-rc3+ #1
>> [   90.581380] Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 
>> 11/13/2012
>> [   90.582325]   0286 f158be4c c12cce56   
>> f158be80 c10567fb
>> [   90.583179]  c1866c2c  0bd7 c1859e8c 0212 c1025ab0 
>> 0212 c1025ab0
>> [   90.584142]  f2012b00 f2011f00 f2012d80 f158be90 c10568d2 0009 
>>  f158bea4
>> [   90.585002] Call Trace:
>> [   90.585854]  [] dump_stack+0x5f/0x89
>> [   90.586703]  [] warn_slowpath_common+0x8b/0xc0
>> [   90.587559]  [] ? fpu__restore+0x90/0x130
>> [   90.588520]  [] ? fpu__restore+0x90/0x130
>> [   90.589353]  [] warn_slowpath_null+0x22/0x30
>> [   90.590175]  [] fpu__restore+0x90/0x130
>> [   90.590993]  [] __fpu__restore_sig+0x268/0x4c0
>> [   90.591816]  [] fpu__restore_sig+0x2f/0x50
>> [   90.592636]  [] restore_sigcontext+0xe9/0x110
>> [   90.593449]  [] sys_sigreturn+0x9c/0xb0
>> [   90.594263]  [] do_syscall_32_irqs_on+0x59/0x340
>> [   90.595079]  [] entry_INT80_32+0x31/0x31
>> [   90.595922] ---[ end trace be617bef2982f473 ]---
>>
>> This is rc3 + latest tip/master and it happened when I did "make
>> mrproper" in the kernel repo.
>>
>> From a quick stare, it looks to me we're running do_syscall_32_irqs_on()
>> with IRQs on, sys_sigreturn() does current_pt_regs() but
>> __fpu__restore_sig() derefs current again and could be that that second
>> "current" is another current which already has ->fpregs_active set ?
>>
>> FPU + signal handling code in a single backtrace. My favourite!
>>
>> :-\
>
> Ugh.
>
> Can you send all the fpu info that the kernel prints really early when it 
> boots?
>

Are you running 32-bit userspace by any chance?  I'm guessing you're
hitting this in __fpu_restore_sig:

fpu__drop(fpu);
if (__copy_from_user(>state.xsave, buf_fx, state_size) ||
__copy_from_user(, buf, sizeof(env))) {
fpstate_init(>state);
err = -1;
} else {
sanitize_restored_xstate(tsk, , xfeatures, fx_only);
}

fpu->fpstate_active = 1;

<-- preempted right here

if (use_eager_fpu()) {
preempt_disable();
fpu__restore(fpu);
preempt_enable();
}

I don't see why this code deserves to work.  If I'm right, it can be
fixed by pulling the preempt_disable out of the if (use_eager_fpu())
to right above the fpstate_active = 1 line.  Don't bother trying to
optimize the !use_eager_fpu() case.

Once someone gets around to eagerly *allocating* the FPU context and
dropping CR0.TS usage entirely, then even that won't be enough unless
we do my suggesting of deferring FPU restore to
prepare_exit_to_usermode.  (Doing that will make all of this much,
much more sane.)


--Andy

RE: [PATCH v6 0/3] cpufreq: Replace timers with utilization update callbacks

[Doug Smythies]

On 2016.02.11 15:28 Rafael J. Wysocki wrote:
> On 2106.02.11 14:50 Doug Smythies wrote:

>> What I do have from my 2 hour idle tests is the of total number of passes 
>> through
>> the intel_pstate driver:
>>
>> Control sample: Kernel 4.3-rc3: 37949 passes.
>> Kernel 4.3-rc3 + rjw 3 patch set v5: 180355 passes
>> Kernel 4.3-rc3 + rjw 3 patch set v6: 201307 passes
>> Kernel 4.3-rc3 + rjw 3 patch set v7: 203619 passes

> That reflects how things work with the changes.  The driver is called
> more often now and has to decide whether or not to take a sample.

Opps. I didn't understand that point, and so only now looked more
closely at the code.

> It would be interesting to see how many of those were samples that
> were actually taken if you can instrument that.

So, those are samples that were taken. There is no trace information
acquired when the new code decides not to take a sample (or so is my
understanding from a quick look).

I did find a couple of cases where the duration (elapsed time between
samples on a given CPU) was less than the nominal sample time. The search
was not exhaustive. (Likely O.K. within expected jitter, just noting
is all. The post processing tools use the kernel clock to do the
calculation, as the duration calculated by the driver is not in the trace
data.)

2 hour idle test: v5 patch 9.955 mSec sample 10078 CPU 1
2 hour idle test: v7 patch 9.968 mSec sample 49476 CPU 3
Duration load test: v7 patch 9.982 mSec sample 10997 CPU 2

... Doug

Re: [PATCH v3 3/4] x86/signal/64: Re-add support for SS in the 64-bit signal context

[Andy Lutomirski]

On Thu, Feb 11, 2016 at 11:49 AM, Borislav Petkov  wrote:
> On Mon, Jan 25, 2016 at 01:34:14PM -0800, Andy Lutomirski wrote:
>
>> + * with a flat 32-bit selector.

How about:

Sigreturn restores SS as follows:

if (saved SS is valid || UC_STRICT_RESTORE_SS is set || saved CS is not 64-bit)
 new SS = saved SS
else
  new SS = a flat 32-bit data segment

>> +
>> + * This behavior serves two purposes.  It ensures that older programs
>> + * that are unaware of the signal context's SS slot and either construct
>> + * a signal context from scratch or that catch signals from segmented
>> + * contexts and change CS to a 64-bit selector won't crash due to a bad
>> + * SS value.
>
> I'm having hard time parsing that sentence and especially placing all
> those "either", "or", "and" connectors at the proper levels. Would it be
> more understandable as pseudocode?
>
>> It also ensures that signal handlers that do not modify
>> + * the signal context at all return back to the exact CS and SS state
>> + * that they came from.
>
> So my brain is reliably in a knot after this text.


How about:

--- cut here ---

This behavior serves three purposes:

 - Legacy programs that construct a 64-bit sigcontext from scratch
with zero or garbage in the SS slot (e.g. old CRIU) and call sigreturn
will still work.

 - Old DOSEMU versions sometimes catch a signal from a segmented
context, delete the old SS segment (with modify_ldt), and change the
saved CS to a 64-bit segment.  These DOSEMU versions expect sigreturn
to send them back to 64-bit mode without killing them, despite the
fact that the SS selector when the signal was raised is no longer
valid.  With UC_STRICT_RESTORE_SS clear, the kernel will fix up SS for
these DOSEMU versions.

 - Old and new programs that catch a signal and return without
modifying the saved context will end up in exactly the state they
started in.  Old kernels would lose track of the previous SS value.

--- cut here ---

FWIW, I have a DOSEMU patch that makes it use UC_STRICT_RESTORE_SS to
get the behavior it actually wants on new kernels.  It should make it
faster and more reliable than was possible before.

--Andy

Re: [PATCH] component: remove device from master match list on failed add

[Akshay Bhat]

Daniel Stone  collabora.com> writes:

> 
> Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
> Signed-off-by: Daniel Stone  collabora.com>

Tested-by: Akshay Bhat 

Tested on imx6 processor based board where re-probe was broken after a
probe deferral.

Re: [PATCH] scripts/dtc: dtx_diff - add info to error message

[Frank Rowand]

On 2/2/2016 11:02 AM, Frank Rowand wrote:
> From: Frank Rowand 
> 
> If kernel config options are not properly set, "make scripts" will not
> compile dtc.  Update the unable to find dtc error message to check
> the kernel config and give better advice on how to create dtc.
> 
> Reword another error message to increase clarity.
> 
> Signed-off-by: Frank Rowand 

< snip >

Ping, no reply on original email.

In the thread about the of ir msi-map patch you mentioned that you have nothing
else queued for 4.5.  Is dtx_diff (and hopefully this patch) queued up for 4.6?
If so, could they instead go into 4.5 since they are support tools, and do not
directly impact the kernel?

Thanks,

Frank

Re: [PATCH v3 4/4] selftests/x86: Add tests for UC_SIGCONTEXT_SS and UC_STRICT_RESTORE_SS

[Andy Lutomirski]

On Thu, Feb 11, 2016 at 11:53 AM, Borislav Petkov  wrote:
> On Mon, Jan 25, 2016 at 01:34:15PM -0800, Andy Lutomirski wrote:
>> This tests the two ABI-preserving cases that DOSEMU cares about, and
>> it also explicitly tests the new UC_SIGCONTEXT_SS and
>> UC_STRICT_RESTORE_SS flags.
>>
>> Signed-off-by: Andy Lutomirski 
>> ---
>>  tools/testing/selftests/x86/sigreturn.c | 240 
>> 
>>  1 file changed, 212 insertions(+), 28 deletions(-)
>>
>> diff --git a/tools/testing/selftests/x86/sigreturn.c 
>> b/tools/testing/selftests/x86/sigreturn.c
>> index b5aa1bab7416..43e840470e32 100644
>> --- a/tools/testing/selftests/x86/sigreturn.c
>> +++ b/tools/testing/selftests/x86/sigreturn.c
>> @@ -55,6 +55,47 @@
>>  #include 
>>
>>  /*
>> + * Copied from asm/ucontext.h, as asm/ucontext.h conflicts badly with the 
>> glibc
>> + * headers.
>> + */
>> +#ifdef __x86_64__
>> +/*
>> + * UC_SAVED_SS will be set when delivering 64-bit or x32 signals on
>> + * kernels that save SS in the sigcontext.  Kernels that set UC_SAVED_SS
>> + * allow signal handlers to set UC_RESTORE_SS; if UC_RESTORE_SS is set,
>> + * then sigreturn will restore SS.
>> + *
>> + * For compatibility with old programs, the kernel will *not* set
>> + * UC_RESTORE_SS when delivering signals.
>
> Those UC_SAVED_SS and UC_RESTORE_SS look stale to me.

Indeed.

>
>> + */
>> +#define UC_SIGCONTEXT_SS   0x2
>> +#define UC_STRICT_RESTORE_SS   0x4
>> +#endif
>> +
>> +/* Access rights as returned by LAR */
>> +#define AR_TYPE_RODATA   (0 * (1 << 9))
>> +#define AR_TYPE_RWDATA   (1 * (1 << 9))
>> +#define AR_TYPE_RODATA_EXPDOWN   (2 * (1 << 9))
>> +#define AR_TYPE_RWDATA_EXPDOWN   (3 * (1 << 9))
>> +#define AR_TYPE_XOCODE   (4 * (1 << 9))
>> +#define AR_TYPE_XRCODE   (5 * (1 << 9))
>> +#define AR_TYPE_XOCODE_CONF  (6 * (1 << 9))
>> +#define AR_TYPE_XRCODE_CONF  (7 * (1 << 9))
>> +#define AR_TYPE_MASK (7 * (1 << 9))
>> +
>> +#define AR_DPL0  (0 * (1 << 13))
>> +#define AR_DPL3  (3 * (1 << 13))
>> +#define AR_DPL_MASK  (3 * (1 << 13))
>> +
>> +#define AR_A (1 << 8)/* A means "accessed" */
>> +#define AR_S (1 << 12)   /* S means "not system" */
>> +#define AR_P (1 << 15)   /* P means "present" */
>> +#define AR_AVL   (1 << 20)   /* AVL does nothing */
>> +#define AR_L (1 << 21)   /* L means "long mode" */
>> +#define AR_DB(1 << 22)   /* D or B, depending 
>> on type */
>> +#define AR_G (1 << 23)   /* G means "limit in pages" */
>
> Why not include the kernel header instead of repeating it here again?
>

Too tangled.  Adding:

#include "../../../../arch/x86/include/asm/desc_defs.h"

Complains that u16 isn't a type.  Trying to include types.h doesn't
work well either.

--Andy

Re: [PATCH 2/2] kernel: sched: fix preempt_disable_ip recodring for preempt_disable()

[Steven Rostedt]

On Fri, 12 Feb 2016 08:27:01 +0800
kbuild test robot  wrote:

> Hi Sebastian,
> 
> [auto build test ERROR on tip/sched/core]
> [also build test ERROR on v4.5-rc3 next-20160211]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improving the system]
> 

Gotta love Wu's autobot!

> url:
> https://github.com/0day-ci/linux/commits/Sebastian-Andrzej-Siewior/ftrace-move-the-CALLER_ADDRx-macros-into-its-own-header/20160212-072259
> config: s390-allyesconfig (attached as .config)
> reproduce:
> wget 
> https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
>  -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=s390 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from include/linux/ftrace_caller.h:4:0,
> from include/linux/sched.h:62,
> from include/linux/kvm_host.h:15,
> from arch/s390/kernel/asm-offsets.c:10:
>arch/s390/include/asm/ftrace.h: In function 'ftrace_generate_call_insn':
> >> arch/s390/include/asm/ftrace.h:77:2: error: implicit declaration of 
> >> function 'is_module_addr' [-Werror=implicit-function-declaration]  
>  target = is_module_addr((void *) ip) ? ftrace_plt : FTRACE_ADDR;
>  ^
>In file included from include/linux/mm.h:67:0,
> from include/linux/kvm_host.h:17,
> from arch/s390/kernel/asm-offsets.c:10:
>arch/s390/include/asm/pgtable.h: At top level:
> >> arch/s390/include/asm/pgtable.h:120:19: error: static declaration of 
> >> 'is_module_addr' follows non-static declaration  
> static inline int is_module_addr(void *addr)

Looks like you need to add this? (maybe)

-- Steve

diff --git a/arch/s390/include/asm/ftrace.h b/arch/s390/include/asm/ftrace.h
index 836c56290499..16f24f92609d 100644
--- a/arch/s390/include/asm/ftrace.h
+++ b/arch/s390/include/asm/ftrace.h
@@ -12,6 +12,8 @@
 
 #ifndef __ASSEMBLY__
 
+#include 
+
 #define ftrace_return_address(n) __builtin_return_address(n)
 
 void _mcount(void);

RE: VMware PCI passthrough regression

[Jason Taylor]

> Actually that is a 4.2 kernel according to the dmesg in the bug tracker.

It's both. I had reproduced on 4.4.

> The oops is a genuine driver bug probably unearthed by the irq issue. That 
> should be reported seperately to the megasas folks.

Thanks, I sent an email to their list.

> - whether that kernel works on the real hardware with that LSI card
> - whether that kernel works in a KVM guest with that card passed through
> If one of those things break, we can certainly help to analyse that. If not, 
> then you need to talk to vmware.

Works fine on real hardware and KVM. Filed an issue with VMware and the fix is 
in the works.

Jason
---
PRIVACY STATEMENT:
This message is a PRIVATE communication.  This message and all attachments are 
a private communication sent by SimpliVity and are considered to be 
confidential or protected by privilege. If you are not the intended recipient, 
you are hereby notified that any disclosure, copying, distribution or use of 
the information contained in or attached to this message is strictly 
prohibited.  Please notify the sender of the delivery error by replying to this 
message, and then delete it from your system.
---

Re: [PATCH v6 2/2] clk: qcom: Add support for RPM Clocks

[Stephen Boyd]

On 12/15, Georgi Djakov wrote:
> diff --git a/drivers/clk/qcom/clk-rpm.c b/drivers/clk/qcom/clk-rpm.c
> new file mode 100644
> index ..7b0e85eefe70
> --- /dev/null
> +++ b/drivers/clk/qcom/clk-rpm.c
> @@ -0,0 +1,290 @@
> +
> +static int clk_rpm_prepare(struct clk_hw *hw)
> +{
> + struct clk_rpm *r = to_clk_rpm(hw);
> + unsigned long rate = r->rate;
> + int ret = 0;
> +
> + mutex_lock(_clk_lock);
> +
> + if (!rate)
> + goto out;
> +
> + if (r->branch)
> + rate = !!rate;
> +
> + ret = clk_rpm_set_rate_active(r, rate);
> +
> + if (ret)
> + goto out;
> +
> +out:
> + if (!ret)
> + r->enabled = true;
> +
> + mutex_unlock(_clk_lock);
> +
> + return ret;
> +}

I don't see any "peer" code in this file. Is there a reason we're
leaving out the active only vs active + sleep set style clocks?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v6 0/2] Add initial support for RPM clocks

[Stephen Boyd]

On 12/15, Georgi Djakov wrote:
> 
>  .../devicetree/bindings/clock/qcom,rpmcc.txt   |   37 ++
>  drivers/clk/qcom/Kconfig   |   29 ++
>  drivers/clk/qcom/Makefile  |2 +
>  drivers/clk/qcom/clk-rpm.c |  290 +
>  drivers/clk/qcom/clk-rpm.h |   71 

Do we need this header file?

>  drivers/clk/qcom/clk-smd-rpm.c |  433 
> 
>  drivers/clk/qcom/clk-smd-rpm.h |  142 +++

And this one too?

>From what I can tell they're only going to be included by the
clk-rpm and clk-smd-rpm C files. We can also avoid exporting the
RPM ops then if we're going to make the C files into full blown
platform drivers.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler

[Mark Brown]

On Thu, Feb 11, 2016 at 05:22:10PM -0500, Tejun Heo wrote:

> > +/**
> > + * struct bfq_data - per device data structure.
> > + * @queue: request queue for the managed device.
> > + * @sched_data: root @bfq_sched_data for the device.
> > + * @busy_queues: number of bfq_queues containing requests (including the
> > + *  queue in service, even if it is idling).
> ...

> I'm personally not a big fan of documenting struct fields this way.
> It's too easy to get them out of sync.

If it's something that gets included in a generated document then people
will tell you pretty quickly if it gets out of sync these days, 0day
notices and there's people sending fixes quite frequently.


signature.asc
Description: PGP signature

Re: [PATCH v2 4/6] clk: qcom: gdsc: Add GDSCs in msm8996 GCC

[Stephen Boyd]

On 12/01, Rajendra Nayak wrote:
> Add all data for the GDSCs which are part of msm8996 GCC block
> 
> Signed-off-by: Rajendra Nayak 
> ---

Forgot to mention that I left out the dtsi change here too.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 6/6] clk: qcom: mmcc8974: Use gdscs .parent and remove genpd calls

[Stephen Boyd]

On 12/01, Rajendra Nayak wrote:
> With gdsc driver capable of handling hierarchical power domains,
> specify oxili_gdsc as parent of oxilicx_gdsc.
> 
> Remove all direct calls to genpd from the mmcc clock driver. The
> adding and removing of subdomains is now handled from within
> the gdsc driver.
> 
> Signed-off-by: Rajendra Nayak 
> ---

Applied to clk-next + this squashed in

---8<
diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
index 6b2e4e808125..bcda56e81503 100644
--- a/drivers/clk/qcom/mmcc-msm8974.c
+++ b/drivers/clk/qcom/mmcc-msm8974.c
@@ -2617,7 +2617,6 @@ MODULE_DEVICE_TABLE(of, mmcc_msm8974_match_table);
 static int mmcc_msm8974_probe(struct platform_device *pdev)
 {
struct regmap *regmap;
-   int ret;
 
regmap = qcom_cc_map(pdev, _msm8974_desc);
if (IS_ERR(regmap))
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 5/6] clk: qcom: gdsc: Add mmcc gdscs for msm8996 family

[Stephen Boyd]

On 12/01, Rajendra Nayak wrote:
> Add all gdsc data which are part of mmcc on msm8996 family
> 
> Signed-off-by: Rajendra Nayak 
> ---

Applied to clk-next, but I dropped dtsi changes and squashed in
this patch

---8<---
diff --git a/drivers/clk/qcom/mmcc-msm8996.c b/drivers/clk/qcom/mmcc-msm8996.c
index a0a7338c67d1..6df7ff36b416 100644
--- a/drivers/clk/qcom/mmcc-msm8996.c
+++ b/drivers/clk/qcom/mmcc-msm8996.c
@@ -2918,7 +2918,7 @@ static struct clk_hw *mmcc_msm8996_hws[] = {
_div.hw,
 };
 
-struct gdsc mmagic_video_gdsc = {
+static struct gdsc mmagic_video_gdsc = {
.gdscr = 0x119c,
.gds_hw_ctrl = 0x120c,
.pd = {
@@ -2928,7 +2928,7 @@ struct gdsc mmagic_video_gdsc = {
.flags = VOTABLE,
 };
 
-struct gdsc mmagic_mdss_gdsc = {
+static struct gdsc mmagic_mdss_gdsc = {
.gdscr = 0x247c,
.gds_hw_ctrl = 0x2480,
.pd = {
@@ -2938,7 +2938,7 @@ struct gdsc mmagic_mdss_gdsc = {
.flags = VOTABLE,
 };
 
-struct gdsc mmagic_camss_gdsc = {
+static struct gdsc mmagic_camss_gdsc = {
.gdscr = 0x3c4c,
.gds_hw_ctrl = 0x3c50,
.pd = {
@@ -2948,7 +2948,7 @@ struct gdsc mmagic_camss_gdsc = {
.flags = VOTABLE,
 };
 
-struct gdsc venus_gdsc = {
+static struct gdsc venus_gdsc = {
.gdscr = 0x1024,
.cxcs = (unsigned int []){ 0x1028, 0x1034, 0x1038 },
.cxc_count = 3,
@@ -2959,7 +2959,7 @@ struct gdsc venus_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc venus_core0_gdsc = {
+static struct gdsc venus_core0_gdsc = {
.gdscr = 0x1040,
.cxcs = (unsigned int []){ 0x1048 },
.cxc_count = 1,
@@ -2969,7 +2969,7 @@ struct gdsc venus_core0_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc venus_core1_gdsc = {
+static struct gdsc venus_core1_gdsc = {
.gdscr = 0x1044,
.cxcs = (unsigned int []){ 0x104c },
.cxc_count = 1,
@@ -2979,7 +2979,7 @@ struct gdsc venus_core1_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc camss_gdsc = {
+static struct gdsc camss_gdsc = {
.gdscr = 0x34a0,
.cxcs = (unsigned int []){ 0x36bc, 0x36c4 },
.cxc_count = 2,
@@ -2990,7 +2990,7 @@ struct gdsc camss_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc vfe0_gdsc = {
+static struct gdsc vfe0_gdsc = {
.gdscr = 0x3664,
.cxcs = (unsigned int []){ 0x36a8 },
.cxc_count = 1,
@@ -3001,7 +3001,7 @@ struct gdsc vfe0_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc vfe1_gdsc = {
+static struct gdsc vfe1_gdsc = {
.gdscr = 0x3674,
.cxcs = (unsigned int []){ 0x36ac },
.cxc_count = 1,
@@ -3012,7 +3012,7 @@ struct gdsc vfe1_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc jpeg_gdsc = {
+static struct gdsc jpeg_gdsc = {
.gdscr = 0x35a4,
.cxcs = (unsigned int []){ 0x35a8, 0x35b0, 0x35c0, 0x35b8 },
.cxc_count = 4,
@@ -3023,7 +3023,7 @@ struct gdsc jpeg_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc cpp_gdsc = {
+static struct gdsc cpp_gdsc = {
.gdscr = 0x36d4,
.cxcs = (unsigned int []){ 0x36b0 },
.cxc_count = 1,
@@ -3034,7 +3034,7 @@ struct gdsc cpp_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc fd_gdsc = {
+static struct gdsc fd_gdsc = {
.gdscr = 0x3b64,
.cxcs = (unsigned int []){ 0x3b68, 0x3b6c },
.cxc_count = 2,
@@ -3045,7 +3045,7 @@ struct gdsc fd_gdsc = {
.pwrsts = PWRSTS_OFF_ON,
 };
 
-struct gdsc mdss_gdsc = {
+static struct gdsc mdss_gdsc = {
.gdscr = 0x2304,
.cxcs = (unsigned int []){ 0x2310, 0x231c },
.cxc_count = 2,
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 4/6] clk: qcom: gdsc: Add GDSCs in msm8996 GCC

[Stephen Boyd]

On 12/01, Rajendra Nayak wrote:
> Add all data for the GDSCs which are part of msm8996 GCC block
> 
> Signed-off-by: Rajendra Nayak 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/2] drm/fsl-dcu: use flat regmap cache

[Stefan Agner]

On 2016-02-02 17:06, Stefan Agner wrote:
> Using flat regmap cache instead of RB-tree to avoid the following
> lockdep warning on driver load:
> [0.697285] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755
> lockdep_trace_alloc+0x15c/0x160()
> [0.697449] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> 
> The RB-tree regmap cache needs to allocate new space on first
> writes. However, allocations in an atomic context (e.g. when a
> spinlock is held) are not allowed. The function regmap_write
> calls map->lock, which acquires a spinlock in the fast_io case.
> Since the FSL DCU driver uses MMIO, the regmap bus of type
> regmap_mmio is being used which has fast_io set to true.
> 
> The MMIO space of the DCU driver is reasonable condense, hence
> using the much faster flat regmap cache is anyway the better
> choice.

As discussed with Thierry on IRC, using regmap cache often does not
really make sense in the context of display controllers. While trying to
use the suspend/resume, I realized that the current implementation in
the DCU driver has bugs and does not work (e.g. an explicit READREG is
missing, but even with that in place, restoring all registers and enable
the controller then seem not to work reliable). Using the new
suspend/resume helpers seem to work better...

Therefor I NACK my own patch here and vote for removing the regcache
entirely (and use the new DRM supsend/resume helpers to implement
suspend/resume)...

--
Stefan 

> 
> Signed-off-by: Stefan Agner 
> Cc: Mark Brown 
> ---
> Changes since v1:
> - Do not move drm_dev_alloc
> 
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 18 +++---
>  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  6 --
>  2 files changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index e01c813..9c21aad 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -36,11 +36,11 @@ static bool fsl_dcu_drm_is_volatile_reg(struct
> device *dev, unsigned int reg)
>   return false;
>  }
>  
> -static const struct regmap_config fsl_dcu_regmap_config = {
> +static struct regmap_config fsl_dcu_regmap_config = {
>   .reg_bits = 32,
>   .reg_stride = 4,
>   .val_bits = 32,
> - .cache_type = REGCACHE_RBTREE,
> + .cache_type = REGCACHE_FLAT,
>  
>   .volatile_reg = fsl_dcu_drm_is_volatile_reg,
>  };
> @@ -260,12 +260,14 @@ static const struct fsl_dcu_soc_data
> fsl_dcu_ls1021a_data = {
>   .name = "ls1021a",
>   .total_layer = 16,
>   .max_layer = 4,
> + .max_register = LS1021A_DCU_MAX_REGISTER,
>  };
>  
>  static const struct fsl_dcu_soc_data fsl_dcu_vf610_data = {
>   .name = "vf610",
>   .total_layer = 64,
>   .max_layer = 6,
> + .max_register = VF610_DCU_MAX_REGISTER,
>  };
>  
>  static const struct of_device_id fsl_dcu_of_match[] = {
> @@ -331,6 +333,13 @@ static int fsl_dcu_drm_probe(struct platform_device 
> *pdev)
>   return ret;
>   }
>  
> + id = of_match_node(fsl_dcu_of_match, pdev->dev.of_node);
> + if (!id)
> + return -ENODEV;
> +
> + fsl_dev->soc = id->data;
> +
> + fsl_dcu_regmap_config.max_register = fsl_dev->soc->max_register;
>   fsl_dev->regmap = devm_regmap_init_mmio(dev, base,
>   _dcu_regmap_config);
>   if (IS_ERR(fsl_dev->regmap)) {
> @@ -338,11 +347,6 @@ static int fsl_dcu_drm_probe(struct platform_device 
> *pdev)
>   return PTR_ERR(fsl_dev->regmap);
>   }
>  
> - id = of_match_node(fsl_dcu_of_match, pdev->dev.of_node);
> - if (!id)
> - return -ENODEV;
> - fsl_dev->soc = id->data;
> -
>   drm = drm_dev_alloc(driver, dev);
>   if (!drm)
>   return -ENOMEM;
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> index 2a724f3..7c296a0 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> @@ -114,8 +114,6 @@
>  #define DCU_UPDATE_MODE_MODE BIT(31)
>  #define DCU_UPDATE_MODE_READREG  BIT(30)
>  
> -#define DCU_DCFB_MAX 0x300
> -
>  #define DCU_CTRLDESCLN(layer, reg)   (0x200 + (reg - 1) * 4 + (layer) * 0x40)
>  
>  #define DCU_LAYER_HEIGHT(x)  ((x) << 16)
> @@ -155,6 +153,9 @@
>  #define DCU_LAYER_POST_SKIP(x)   ((x) << 16)
>  #define DCU_LAYER_PRE_SKIP(x)(x)
>  
> +#define VF610_DCU_MAX_REGISTER   0x11fc
> +#define LS1021A_DCU_MAX_REGISTER 0x5fc
> +
>  #define FSL_DCU_RGB565   4
>  #define FSL_DCU_RGB888   5
>  #define FSL_DCU_ARGB 6
> @@ -175,6 +176,7 @@ struct fsl_dcu_soc_data {
>   unsigned int total_layer;
>   /*max layer number DCU supported*/
>   unsigned int max_layer;
> + unsigned int max_register;
>  };
>  
>  struct 

Re: [PATCH v2 1/6] clk: qcom: gdsc: Add support for hierarchical power domains

[Stephen Boyd]

On 12/01, Rajendra Nayak wrote:
> Some qcom SoCs' can have hierarchical power domains. Let the gdsc structs
> specify the parents (if any) and the driver add genpd subdomains for them.
> 
> Signed-off-by: Rajendra Nayak 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 2/6] clk: qcom: gdsc: Add support for gdscs with gds hw controller

[Stephen Boyd]

On 12/01, Rajendra Nayak wrote:
> Some gdsc power domains can have a gds_hw_controller block inside
> to help ensure all slave devices within the power domain are idle
> before the gdsc is actually switched off.
> This is mainly useful in power domains which host a MMU, in which
> case its necessary to make sure there are no outstanding MMU operations
> or pending bus transactions before the power domain is turned off.
> 
> In gdscs with gds_hw_controller block, its necessary to check the
> gds_hw_ctrl status bits instead of the ones in gdscr, to determine
> the state of the powerdomain.
> 
> While at it, also move away from using jiffies and use ktime APIs
> instead for busy looping on status bits.
> 
> Signed-off-by: Rajendra Nayak 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 3/6] clk: qcom: gdsc: Add support for votable gdscs

[Stephen Boyd]

On 12/01, Rajendra Nayak wrote:
> Some gdscs might be controlled via voting registers and might not
> really disable when the kernel intends to disable them (due to other
> votes keeping them enabled)
> Mark these gdscs with a flag for we do not check/wait on a disable
> status for these gdscs within the kernel disable callback.
> 
> Also at boot, if these GDSCs are found to be ON, we make sure we
> vote for them before we inform the genpd framework about their
> status. If genpd gets no users, it then disables (removes the vote)
> them as part of genpd_poweroff_unused()
> 
> Signed-off-by: Rajendra Nayak 
> ---

Applied to clk-next

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/2] kernel: sched: fix preempt_disable_ip recodring for preempt_disable()

[kbuild test robot]

Hi Sebastian,

[auto build test ERROR on tip/sched/core]
[also build test ERROR on v4.5-rc3 next-20160211]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Sebastian-Andrzej-Siewior/ftrace-move-the-CALLER_ADDRx-macros-into-its-own-header/20160212-072259
config: s390-allyesconfig (attached as .config)
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=s390 

All errors (new ones prefixed by >>):

   In file included from include/linux/ftrace_caller.h:4:0,
from include/linux/sched.h:62,
from include/linux/kvm_host.h:15,
from arch/s390/kernel/asm-offsets.c:10:
   arch/s390/include/asm/ftrace.h: In function 'ftrace_generate_call_insn':
>> arch/s390/include/asm/ftrace.h:77:2: error: implicit declaration of function 
>> 'is_module_addr' [-Werror=implicit-function-declaration]
 target = is_module_addr((void *) ip) ? ftrace_plt : FTRACE_ADDR;
 ^
   In file included from include/linux/mm.h:67:0,
from include/linux/kvm_host.h:17,
from arch/s390/kernel/asm-offsets.c:10:
   arch/s390/include/asm/pgtable.h: At top level:
>> arch/s390/include/asm/pgtable.h:120:19: error: static declaration of 
>> 'is_module_addr' follows non-static declaration
static inline int is_module_addr(void *addr)
  ^
   In file included from include/linux/ftrace_caller.h:4:0,
from include/linux/sched.h:62,
from include/linux/kvm_host.h:15,
from arch/s390/kernel/asm-offsets.c:10:
   arch/s390/include/asm/ftrace.h:77:11: note: previous implicit declaration of 
'is_module_addr' was here
 target = is_module_addr((void *) ip) ? ftrace_plt : FTRACE_ADDR;
  ^
   cc1: some warnings being treated as errors
   make[2]: *** [arch/s390/kernel/asm-offsets.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +/is_module_addr +77 arch/s390/include/asm/ftrace.h

e6d60b36 Heiko Carstens 2015-01-09  61  return 1;
e6d60b36 Heiko Carstens 2015-01-09  62  #else
c933146a Heiko Carstens 2014-10-15  63  if (insn->disp == 
MCOUNT_INSN_SIZE / 2)
c933146a Heiko Carstens 2014-10-15  64  return 1;
c933146a Heiko Carstens 2014-10-15  65  #endif
e6d60b36 Heiko Carstens 2015-01-09  66  #endif
c933146a Heiko Carstens 2014-10-15  67  return 0;
c933146a Heiko Carstens 2014-10-15  68  }
c933146a Heiko Carstens 2014-10-15  69  
c933146a Heiko Carstens 2014-10-15  70  static inline void 
ftrace_generate_call_insn(struct ftrace_insn *insn,
c933146a Heiko Carstens 2014-10-15  71  
 unsigned long ip)
c933146a Heiko Carstens 2014-10-15  72  {
c933146a Heiko Carstens 2014-10-15  73  #ifdef CONFIG_FUNCTION_TRACER
c933146a Heiko Carstens 2014-10-15  74  unsigned long target;
10dec7db Heiko Carstens 2014-08-15  75  
c933146a Heiko Carstens 2014-10-15  76  /* brasl r0,ftrace_caller */
c933146a Heiko Carstens 2014-10-15 @77  target = is_module_addr((void 
*) ip) ? ftrace_plt : FTRACE_ADDR;
c933146a Heiko Carstens 2014-10-15  78  insn->opc = 0xc005;
c933146a Heiko Carstens 2014-10-15  79  insn->disp = (target - ip) / 2;
c933146a Heiko Carstens 2014-10-15  80  #endif
c933146a Heiko Carstens 2014-10-15  81  }
c933146a Heiko Carstens 2014-10-15  82  
c933146a Heiko Carstens 2014-10-15  83  #endif /* __ASSEMBLY__ */
5d360a75 Heiko Carstens 2008-12-25  84  #endif /* _ASM_S390_FTRACE_H */

:: The code at line 77 was first introduced by commit
:: c933146a5e41e42ea3eb4f34fa02e201da3f068e s390/ftrace,kprobes: allow to 
patch first instruction

:: TO: Heiko Carstens 
:: CC: Martin Schwidefsky 

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


.config.gz
Description: Binary data

[PATCH] dtb: amd: Fix-up for ccn504 and kcs nodes

[Suravee Suthikulpanit]

From: Suravee Suthikulpanit 

This is a fix-up patch based on the review comment from
Arnd regarding:
* fix ccn504 address in the node name
* remove kcs interrupt-name

Signed-off-by: Brijesh Singh 
Signed-off-by: Suravee Suthikulpanit 
Cc: Arnd Bergmann 
---

Hi Olof,

Here are the changes from the V3 that I sent earlier. Sorry for confusion.
Would you please pull this into the next tree?

Thank you,
Suravee

 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi 
b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
index a7fc059..bd3adea 100644
--- a/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
+++ b/arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi
@@ -231,7 +231,7 @@
};
 
/* Perf CCN504 PMU */
-   ccn: ccn@0xe800 {
+   ccn: ccn@e800 {
compatible = "arm,ccn-504";
reg = <0x0 0xe800 0 0x100>;
interrupts = <0 380 4>;
@@ -243,7 +243,6 @@
device_type = "ipmi";
reg = <0x0 0xe001 0 0x8>;
interrupts = <0 389 4>;
-   interrupt-names = "ipmi_kcs";
reg-size = <1>;
reg-spacing = <4>;
};
-- 
2.5.0