Re: [PATCH] iio/adc/ltc2497: Driver for Linear Technology LTC2497 ADC

[Michael Hennerich]

On 23.03.2017 12:28, Peter Meerwald-Stadler wrote:

On Thu, 23 Mar 2017, michael.henner...@analog.com wrote:


From: Michael Hennerich 


comments below


Hi Peter,

Thanks for the review -
comments inline.




Signed-off-by: Michael Hennerich 
---
 .../devicetree/bindings/iio/adc/ltc2497.txt|  13 +
 MAINTAINERS|   1 +
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/ltc2497.c  | 263 +
 5 files changed, 289 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/ltc2497.txt
 create mode 100644 drivers/iio/adc/ltc2497.c

diff --git a/Documentation/devicetree/bindings/iio/adc/ltc2497.txt 
b/Documentation/devicetree/bindings/iio/adc/ltc2497.txt
new file mode 100644
index 000..c2829c19
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ltc2497.txt
@@ -0,0 +1,13 @@
+* Linear Technology / Analog Devices LTC2497 ADC
+
+Required properties:
+ - compatible: Should be "lltc,ltc2497"
+ - reg: Should contain the ADC I2C address
+ - vref-supply: The regulator supply for ADC reference voltage
+
+Example:
+   ltc2497: adc@76 {
+   compatible = "lltc,ltc2497";
+   reg = <0x76>;
+   vref-supply = <_reg>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index a7d6f9a..173043c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -813,6 +813,7 @@ W:  http://wiki.analog.com/
 W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/iio/*/ad*
+F: drivers/iio/adc/ltc2497*
 X: drivers/iio/*/adjd*
 F: drivers/staging/iio/*/ad*
 F: drivers/staging/iio/trigger/iio-trig-bfin-timer.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 2268a6f..141cf4a 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -326,6 +326,17 @@ config LTC2485
  To compile this driver as a module, choose M here: the module will be
  called ltc2485.

+config LTC2497
+   tristate "Linear Technology LTC2497 ADC driver"
+   depends on I2C
+   help
+ Say yes here to build support for Linear Technology LTC2497
+ 16-Bit 8-/16-Channel Delta Sigma ADC.
+ Provides direct access via sysfs


the line "Provides..." should be removed I think, it confuses me at least


Sure I can remove - originally added to make checkpatch happy.




+
+ To compile this driver as a module, choose M here: the module will be
+ called ltc2497.
+
 config MAX1027
tristate "Maxim max1027 ADC driver"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 73dbe39..9d626b5 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
 obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
 obj-$(CONFIG_LTC2485) += ltc2485.o
+obj-$(CONFIG_LTC2497) += ltc2497.o
 obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX11100) += max11100.o
 obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c
new file mode 100644
index 000..0452715
--- /dev/null
+++ b/drivers/iio/adc/ltc2497.c
@@ -0,0 +1,263 @@
+/*
+ * ltc2497.c - Driver for Linear Technology LTC2497 ADC
+ *
+ * Copyright (C) 2017 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ *
+ * Datasheet: http://cds.linear.com/docs/en/datasheet/2497fd.pdf
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define LTC2497_ENABLE 0xA0
+#define LTC2497_SGL(1 << 4)
+#define LTC2497_DIFF   (0 << 4)
+#define LTC2497_SIGN   (1 << 3)
+#define LTC2497_CONFIG_DEFAULT LTC2497_ENABLE
+#define LTC2497_CONVERSION_TIME_MS 150ULL


is the ULL really needed?


Needed? - maybe not - but probably not wrong ktime_ms_delta() returns 
64bit and we later do some comparisons...





+struct ltc2497_st {
+   struct i2c_client *client;
+   struct regulator *ref;
+   ktime_t time_prev;
+   u8 addr_prev;
+};
+
+static int ltc2497_wait_conv(struct ltc2497_st *st)
+{
+   s64 time_elapsed;
+
+   time_elapsed = ktime_ms_delta(ktime_get(), st->time_prev);
+
+   if (time_elapsed < LTC2497_CONVERSION_TIME_MS) {
+   /* delay if conversion time not passed
+* since last read or write
+*/
+   msleep(LTC2497_CONVERSION_TIME_MS - time_elapsed);
+   return 0;
+   }
+
+   if (time_elapsed - LTC2497_CONVERSION_TIME_MS <= 0) {
+   /* We're in automatic mode -
+* so the last reading is stil not outdated
+*/
+   return 0;
+   }
+
+   return -ETIMEDOUT;
+}
+
+static int 

Re: [PATCH] iio/adc/ltc2497: Driver for Linear Technology LTC2497 ADC

[Michael Hennerich]

On 23.03.2017 12:28, Peter Meerwald-Stadler wrote:

On Thu, 23 Mar 2017, michael.henner...@analog.com wrote:


From: Michael Hennerich 


comments below


Hi Peter,

Thanks for the review -
comments inline.




Signed-off-by: Michael Hennerich 
---
 .../devicetree/bindings/iio/adc/ltc2497.txt|  13 +
 MAINTAINERS|   1 +
 drivers/iio/adc/Kconfig|  11 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/ltc2497.c  | 263 +
 5 files changed, 289 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/ltc2497.txt
 create mode 100644 drivers/iio/adc/ltc2497.c

diff --git a/Documentation/devicetree/bindings/iio/adc/ltc2497.txt 
b/Documentation/devicetree/bindings/iio/adc/ltc2497.txt
new file mode 100644
index 000..c2829c19
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/ltc2497.txt
@@ -0,0 +1,13 @@
+* Linear Technology / Analog Devices LTC2497 ADC
+
+Required properties:
+ - compatible: Should be "lltc,ltc2497"
+ - reg: Should contain the ADC I2C address
+ - vref-supply: The regulator supply for ADC reference voltage
+
+Example:
+   ltc2497: adc@76 {
+   compatible = "lltc,ltc2497";
+   reg = <0x76>;
+   vref-supply = <_reg>;
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index a7d6f9a..173043c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -813,6 +813,7 @@ W:  http://wiki.analog.com/
 W: http://ez.analog.com/community/linux-device-drivers
 S: Supported
 F: drivers/iio/*/ad*
+F: drivers/iio/adc/ltc2497*
 X: drivers/iio/*/adjd*
 F: drivers/staging/iio/*/ad*
 F: drivers/staging/iio/trigger/iio-trig-bfin-timer.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 2268a6f..141cf4a 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -326,6 +326,17 @@ config LTC2485
  To compile this driver as a module, choose M here: the module will be
  called ltc2485.

+config LTC2497
+   tristate "Linear Technology LTC2497 ADC driver"
+   depends on I2C
+   help
+ Say yes here to build support for Linear Technology LTC2497
+ 16-Bit 8-/16-Channel Delta Sigma ADC.
+ Provides direct access via sysfs


the line "Provides..." should be removed I think, it confuses me at least


Sure I can remove - originally added to make checkpatch happy.




+
+ To compile this driver as a module, choose M here: the module will be
+ called ltc2497.
+
 config MAX1027
tristate "Maxim max1027 ADC driver"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 73dbe39..9d626b5 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
 obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
 obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
 obj-$(CONFIG_LTC2485) += ltc2485.o
+obj-$(CONFIG_LTC2497) += ltc2497.o
 obj-$(CONFIG_MAX1027) += max1027.o
 obj-$(CONFIG_MAX11100) += max11100.o
 obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/ltc2497.c b/drivers/iio/adc/ltc2497.c
new file mode 100644
index 000..0452715
--- /dev/null
+++ b/drivers/iio/adc/ltc2497.c
@@ -0,0 +1,263 @@
+/*
+ * ltc2497.c - Driver for Linear Technology LTC2497 ADC
+ *
+ * Copyright (C) 2017 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ *
+ * Datasheet: http://cds.linear.com/docs/en/datasheet/2497fd.pdf
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#define LTC2497_ENABLE 0xA0
+#define LTC2497_SGL(1 << 4)
+#define LTC2497_DIFF   (0 << 4)
+#define LTC2497_SIGN   (1 << 3)
+#define LTC2497_CONFIG_DEFAULT LTC2497_ENABLE
+#define LTC2497_CONVERSION_TIME_MS 150ULL


is the ULL really needed?


Needed? - maybe not - but probably not wrong ktime_ms_delta() returns 
64bit and we later do some comparisons...





+struct ltc2497_st {
+   struct i2c_client *client;
+   struct regulator *ref;
+   ktime_t time_prev;
+   u8 addr_prev;
+};
+
+static int ltc2497_wait_conv(struct ltc2497_st *st)
+{
+   s64 time_elapsed;
+
+   time_elapsed = ktime_ms_delta(ktime_get(), st->time_prev);
+
+   if (time_elapsed < LTC2497_CONVERSION_TIME_MS) {
+   /* delay if conversion time not passed
+* since last read or write
+*/
+   msleep(LTC2497_CONVERSION_TIME_MS - time_elapsed);
+   return 0;
+   }
+
+   if (time_elapsed - LTC2497_CONVERSION_TIME_MS <= 0) {
+   /* We're in automatic mode -
+* so the last reading is stil not outdated
+*/
+   return 0;
+   }
+
+   return -ETIMEDOUT;
+}
+
+static int ltc2497_read(struct ltc2497_st *st, u8 address, int *val)
+{
+

Reply my email please!!!

[i...@ono.com]

--

I apologize if this email violates your privacy. It is important and 
urgent.

One Mr Edgar Davies who won huge amount in our recent draw is seriously 
ill has  few weeks to live so his wife and only daughter became so 
devastated and they told us that they were not interested in the money 
claiming that his life is what matters most to them not the money. Can 
l work with you to claim it? I am the manager so I know the steps to 
take to make it legal without any problem.
I will explain more when I get your reply.  
PLEASE REPLY VIA: mycontactss @ yandex.com
Harrison
--

Reply my email please!!!

[i...@ono.com]

--

I apologize if this email violates your privacy. It is important and 
urgent.

One Mr Edgar Davies who won huge amount in our recent draw is seriously 
ill has  few weeks to live so his wife and only daughter became so 
devastated and they told us that they were not interested in the money 
claiming that his life is what matters most to them not the money. Can 
l work with you to claim it? I am the manager so I know the steps to 
take to make it legal without any problem.
I will explain more when I get your reply.  
PLEASE REPLY VIA: mycontactss @ yandex.com
Harrison
--

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

[Dmitry Vyukov]

On Thu, Mar 23, 2017 at 3:34 PM, Alan Stern  wrote:
> On Thu, 23 Mar 2017, Dmitry Vyukov wrote:
>
>> Hello,
>>
>> I've got the following report while running syzkaller fuzzer on
>> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected
>> kmalloc failure, most likely it's the root cause.
>
> I find this bug report puzzling.  Maybe I don't understand it
> correctly -- it appears that the so-called use-after-free actually
> occurs _before_ the memory is deallocated!
>
>> FAULT_INJECTION: forcing a failure.
> Skipping this part.  Is it relevant?  It seems to refer to a different
> memory buffer.
>
>> ==
>> BUG: KASAN: use-after-free in __list_add_valid+0xc6/0xd0
>> lib/list_debug.c:26 at addr 88003c377a20
>> Read of size 8 by task syz-executor7/3348
>> CPU: 3 PID: 3348 Comm: syz-executor7 Not tainted 4.11.0-rc3+ #364
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>
> Here are the revelant pieces of the stack traces.  Everything below
> these parts is the same, and everything above them is unimportant.
> (And everything happened in the same process.)  The use-after-free
> access occurred within this call:
>
>>  usb_start_wait_urb+0x135/0x320 drivers/usb/core/message.c:56
>>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>
>
> Here's where the allocation call occurred:
>
>> Allocated:
>> PID = 3348
> ...
>>  usb_internal_control_msg drivers/usb/core/message.c:93 [inline]
>
>
> And here's where the buffer was deallocated:
>
>> Freed:
>> PID = 3348
> ...
>>  usb_start_wait_urb+0x234/0x320 drivers/usb/core/message.c:78
>>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>
> Putting these together:
>
> The memory was allocated in usb_internal_control_msg() line 93.
> The later events occurred within the call in line 100 to
> usb_start_wait_urb().
>
> The invalid access occurred within usb_start_wait_urb() line 56.
>
> The memory was deallocated within usb_start_wait_urb() line 78.
>
> Since these routines don't involve any loops or backward jumps, this
> says that the invalid access occurred before the memory was
> deallocated!  So why is it reported as a problem?


My first guess would be that pid 3348 did 2 calls to open and the urb
was somehow referenced across these calls. Is it possible?

Re: [v1 0/9] Early boot time stamps for x86

[Pasha Tatashin]

Hi Thomas,

Thank you very much for looking at this patchset. Comments below:

On 03/23/2017 06:56 AM, Thomas Gleixner wrote:

On Wed, 22 Mar 2017, Pasha Tatashin wrote:

Yes, I am certain it is 0 or  near 0 on reset on this machine. Because, I


Emphasis on "this machine'

It's not guaranteed especially not on reboot and not with creative BIOSes
fiddling with the TSC_ADJUST value.

 - It CANNOT be used to measure BIOS boot time reliably


Yes, understood, I will remove comment about BIOS time from the next 
cover letter.


However, I think the pr_info() with offset is still useful at least for 
those whose BIOS does not alter TSC_ADJUST, also it is consisten with 
every other clocksource in linux where offset is printed in pr_info().


From Intel PRM 2016/12:
The time-stamp counter (as implemented in the P6 family, Pentium, 
Pentium M, Pentium 4, Intel Xeon, Intel Core Solo and Intel Core Duo 
processors and later processors) is a 64-bit counter that is set to 0 
following a RESET of the processor


Since early boot time stamps feature target processors that are later 
than "Pentium 4" because invariant TSC flag is checked, it is safe to 
assume that offset is going to be valid on power-on if TSC_ADJUST  was 
not altered




 - If BIOS wreckaged TSC_ADJUST, then your whole time stamping goes out the
   window once the kernel sanitized it.


I will add a condition to tsc_early_init() to check for TSC_ADJUST if it 
is not 0, disable early TSC feature. Does this sound OK?


Thank you,
Pasha

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

[Dmitry Vyukov]

On Thu, Mar 23, 2017 at 3:34 PM, Alan Stern  wrote:
> On Thu, 23 Mar 2017, Dmitry Vyukov wrote:
>
>> Hello,
>>
>> I've got the following report while running syzkaller fuzzer on
>> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected
>> kmalloc failure, most likely it's the root cause.
>
> I find this bug report puzzling.  Maybe I don't understand it
> correctly -- it appears that the so-called use-after-free actually
> occurs _before_ the memory is deallocated!
>
>> FAULT_INJECTION: forcing a failure.
> Skipping this part.  Is it relevant?  It seems to refer to a different
> memory buffer.
>
>> ==
>> BUG: KASAN: use-after-free in __list_add_valid+0xc6/0xd0
>> lib/list_debug.c:26 at addr 88003c377a20
>> Read of size 8 by task syz-executor7/3348
>> CPU: 3 PID: 3348 Comm: syz-executor7 Not tainted 4.11.0-rc3+ #364
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> Call Trace:
>
> Here are the revelant pieces of the stack traces.  Everything below
> these parts is the same, and everything above them is unimportant.
> (And everything happened in the same process.)  The use-after-free
> access occurred within this call:
>
>>  usb_start_wait_urb+0x135/0x320 drivers/usb/core/message.c:56
>>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>
>
> Here's where the allocation call occurred:
>
>> Allocated:
>> PID = 3348
> ...
>>  usb_internal_control_msg drivers/usb/core/message.c:93 [inline]
>
>
> And here's where the buffer was deallocated:
>
>> Freed:
>> PID = 3348
> ...
>>  usb_start_wait_urb+0x234/0x320 drivers/usb/core/message.c:78
>>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]
>
> Putting these together:
>
> The memory was allocated in usb_internal_control_msg() line 93.
> The later events occurred within the call in line 100 to
> usb_start_wait_urb().
>
> The invalid access occurred within usb_start_wait_urb() line 56.
>
> The memory was deallocated within usb_start_wait_urb() line 78.
>
> Since these routines don't involve any loops or backward jumps, this
> says that the invalid access occurred before the memory was
> deallocated!  So why is it reported as a problem?


My first guess would be that pid 3348 did 2 calls to open and the urb
was somehow referenced across these calls. Is it possible?

Re: [v1 0/9] Early boot time stamps for x86

[Pasha Tatashin]

Hi Thomas,

Thank you very much for looking at this patchset. Comments below:

On 03/23/2017 06:56 AM, Thomas Gleixner wrote:

On Wed, 22 Mar 2017, Pasha Tatashin wrote:

Yes, I am certain it is 0 or  near 0 on reset on this machine. Because, I


Emphasis on "this machine'

It's not guaranteed especially not on reboot and not with creative BIOSes
fiddling with the TSC_ADJUST value.

 - It CANNOT be used to measure BIOS boot time reliably


Yes, understood, I will remove comment about BIOS time from the next 
cover letter.


However, I think the pr_info() with offset is still useful at least for 
those whose BIOS does not alter TSC_ADJUST, also it is consisten with 
every other clocksource in linux where offset is printed in pr_info().


From Intel PRM 2016/12:
The time-stamp counter (as implemented in the P6 family, Pentium, 
Pentium M, Pentium 4, Intel Xeon, Intel Core Solo and Intel Core Duo 
processors and later processors) is a 64-bit counter that is set to 0 
following a RESET of the processor


Since early boot time stamps feature target processors that are later 
than "Pentium 4" because invariant TSC flag is checked, it is safe to 
assume that offset is going to be valid on power-on if TSC_ADJUST  was 
not altered




 - If BIOS wreckaged TSC_ADJUST, then your whole time stamping goes out the
   window once the kernel sanitized it.


I will add a condition to tsc_early_init() to check for TSC_ADJUST if it 
is not 0, disable early TSC feature. Does this sound OK?


Thank you,
Pasha

Re: [PATCH v2 5/7] clk: tegra: don't warn for PLL defaults unnecessarily

[Jon Hunter]

Hi Peter,

On 23/02/17 10:44, Peter De Schrijver wrote:
> If the PLL is on, only warn if the defaults are not yet set. Otherwise be
> silent.
> 
> Signed-off-by: Peter De Schrijver <pdeschrij...@nvidia.com>

This patch is breaking boot for Tegra210 Smaug on -next [0]. Reverting
this on top of -next allows the board to boot again. I have not had
chance to dig into this any further yet, but can unless you have some
thoughts.

Cheers
Jon

[0]
https://nvtb.github.io//linux-next/test_next-20170323/20170323021534/boot/tegra210-smaug/tegra210-smaug/defconfig_log.txt

-- 
nvpublic

Re: [PATCH v2 5/7] clk: tegra: don't warn for PLL defaults unnecessarily

[Jon Hunter]

Hi Peter,

On 23/02/17 10:44, Peter De Schrijver wrote:
> If the PLL is on, only warn if the defaults are not yet set. Otherwise be
> silent.
> 
> Signed-off-by: Peter De Schrijver 

This patch is breaking boot for Tegra210 Smaug on -next [0]. Reverting
this on top of -next allows the board to boot again. I have not had
chance to dig into this any further yet, but can unless you have some
thoughts.

Cheers
Jon

[0]
https://nvtb.github.io//linux-next/test_next-20170323/20170323021534/boot/tegra210-smaug/tegra210-smaug/defconfig_log.txt

-- 
nvpublic

[PATCH 0/6 v5] [GIT PULL] ftrace/x86: Ftrace cleanup and add support for -mfentry on x86_32

[Steven Rostedt]

[
 Ingo, Thomas or H.Peter,

 I believe this is all set to go now. I updated those patches that Linus
 commented on and I don't believe there are any more issues. I ran this
 through several tests (although some of my tests are failing due to
 bugs introduced by others in 4.11-rc2). You can take this as a patch
 series, or you can pull from my tree defined below. It's based on 4.11-rc2
 as I noticed that tip/x86/core is rather outdated, and Linus is fine with
 basing off of his tagged releases.
]


With the issues of gcc screwing around with the mcount stack frame causing
function graph tracer to panic on x86_32, and with Linus saying that we
should start deprecating mcount (at least on x86), I figured that x86_32
needs to support fentry.

First, I renamed mcount_64.S to ftrace_64.S. As we want to get away from
mcount, having the ftrace code in a file called mcount seems rather backwards.

Next I moved the ftrace code out of entry_32.S. It's not in entry_64.S
and it does not belong in entry_32.S.

I noticed that the x86_32 code has the same issue as the x86_64 did
in the past with respect to a stack frame. I fixed that just for the main
ftrace_caller. The ftrace_regs_caller is rather special, and so is
function graph tracing.

I realized the ftrace_regs_caller code was complex due to me aggressively
saving flags, even though I could still do push, lea and mov without
changing them. That made the logic a little nicer.

Finally I added the fentry code.

I tested this with an older compiler (for mcount) with and without
FRAME_POINTER set. I also did it with a new compiler (with fentry), with and
without FRAME_POINTER. I tested function tracing, stack tracing, function_graph
tracing, and kprobes (as that uses the ftrace_regs_caller).

Please pull (or take the patch series) from:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/x86/ftrace

Head SHA1: fadff4e942659f37a2374438dbb12388a9518107


Steven Rostedt (VMware) (6):
  ftrace/x86_64: Rename mcount_64.S to ftrace_64.S
  ftrace/x86_32: Move the ftrace specific code out of entry_32.S
  ftrace/x86_32: Add stack frame pointer to ftrace_caller
  ftrace/x86_32: Clean up ftrace_regs_caller
  ftrace/x86_32: Add -mfentry support to x86_32 with DYNAMIC_FTRACE set
  ftrace/x86: Use Makefile logic instead of #ifdef for compiling ftrace_*.o



Changes since v4:

 * s/mcount_/ftrace_/ in comment header that states the name.
  (Namhyung Kim)

 * Added Masami's Reviewed-by tag to patch 3

 arch/x86/Kconfig |   2 +-
 arch/x86/entry/entry_32.S| 169 --
 arch/x86/kernel/Makefile |   5 +-
 arch/x86/kernel/ftrace_32.S  | 246 +++
 arch/x86/kernel/{mcount_64.S => ftrace_64.S} |   6 +-
 5 files changed, 251 insertions(+), 177 deletions(-)
 create mode 100644 arch/x86/kernel/ftrace_32.S
 rename arch/x86/kernel/{mcount_64.S => ftrace_64.S} (98%)


Diff against v4:

diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index de50c9084d16..97ede82aeb8c 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -1,5 +1,5 @@
 /*
- *  linux/arch/x86_64/mcount_64.S
+ *  linux/arch/x86_64/ftrace_32.S
  *
  *  Copyright (C) 2017  Steven Rostedt, VMware Inc.
  */
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index b9c46919d4fc..aef2361e7f83 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -1,5 +1,5 @@
 /*
- *  linux/arch/x86_64/mcount_64.S
+ *  linux/arch/x86_64/ftrace_64.S
  *
  *  Copyright (C) 2014  Steven Rostedt, Red Hat Inc
  */

[PATCH 6/6 v5] ftrace/x86: Use Makefile logic instead of #ifdef for compiling ftrace_*.o

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

Currently ftrace_32.S and ftrace_64.S are compiled even when
CONFIG_FUNCTION_TRACER is not set. This means there's an unnecessary #ifdef
to protect the code. Instead of using preprocessor directives, only compile
those files when FUNCTION_TRACER is defined.

Link: http://lkml.kernel.org/r/20170316210043.peycxdxktwwn6cid@treble
Suggested-by: Josh Poimboeuf 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/Makefile| 4 ++--
 arch/x86/kernel/ftrace_32.S | 3 ---
 arch/x86/kernel/ftrace_64.S | 4 
 3 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 55e8902c461f..4b994232cb57 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -46,8 +46,7 @@ obj-$(CONFIG_MODIFY_LDT_SYSCALL)  += ldt.o
 obj-y  += setup.o x86_init.o i8259.o irqinit.o jump_label.o
 obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y  += probe_roms.o
-obj-$(CONFIG_X86_64)   += sys_x86_64.o ftrace_64.o
-obj-$(CONFIG_X86_32)   += ftrace_32.o
+obj-$(CONFIG_X86_64)   += sys_x86_64.o
 obj-$(CONFIG_X86_ESPFIX64) += espfix_64.o
 obj-$(CONFIG_SYSFS)+= ksysfs.o
 obj-y  += bootflag.o e820.o
@@ -83,6 +82,7 @@ obj-y += apic/
 obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
 obj-$(CONFIG_DYNAMIC_FTRACE)   += ftrace.o
 obj-$(CONFIG_LIVEPATCH)+= livepatch.o
+obj-$(CONFIG_FUNCTION_TRACER)  += ftrace_$(BITS).o
 obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
 obj-$(CONFIG_FTRACE_SYSCALLS)  += ftrace.o
 obj-$(CONFIG_X86_TSC)  += trace_clock.o
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 15acf54083c1..97ede82aeb8c 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -10,8 +10,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_FUNCTION_TRACER
-
 #ifdef CC_USING_FENTRY
 # define function_hook __fentry__
 EXPORT_SYMBOL(__fentry__)
@@ -208,7 +206,6 @@ ftrace_stub:
jmp ftrace_stub
 END(function_hook)
 #endif /* CONFIG_DYNAMIC_FTRACE */
-#endif /* CONFIG_FUNCTION_TRACER */
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENTRY(ftrace_graph_caller)
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index fc0fe0e6c2de..aef2361e7f83 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -13,9 +13,6 @@
.code64
.section .entry.text, "ax"
 
-
-#ifdef CONFIG_FUNCTION_TRACER
-
 #ifdef CC_USING_FENTRY
 # define function_hook __fentry__
 EXPORT_SYMBOL(__fentry__)
@@ -297,7 +294,6 @@ trace:
jmp fgraph_trace
 END(function_hook)
 #endif /* CONFIG_DYNAMIC_FTRACE */
-#endif /* CONFIG_FUNCTION_TRACER */
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENTRY(ftrace_graph_caller)
-- 
2.10.2

[PATCH 0/6 v5] [GIT PULL] ftrace/x86: Ftrace cleanup and add support for -mfentry on x86_32

[Steven Rostedt]

[
 Ingo, Thomas or H.Peter,

 I believe this is all set to go now. I updated those patches that Linus
 commented on and I don't believe there are any more issues. I ran this
 through several tests (although some of my tests are failing due to
 bugs introduced by others in 4.11-rc2). You can take this as a patch
 series, or you can pull from my tree defined below. It's based on 4.11-rc2
 as I noticed that tip/x86/core is rather outdated, and Linus is fine with
 basing off of his tagged releases.
]


With the issues of gcc screwing around with the mcount stack frame causing
function graph tracer to panic on x86_32, and with Linus saying that we
should start deprecating mcount (at least on x86), I figured that x86_32
needs to support fentry.

First, I renamed mcount_64.S to ftrace_64.S. As we want to get away from
mcount, having the ftrace code in a file called mcount seems rather backwards.

Next I moved the ftrace code out of entry_32.S. It's not in entry_64.S
and it does not belong in entry_32.S.

I noticed that the x86_32 code has the same issue as the x86_64 did
in the past with respect to a stack frame. I fixed that just for the main
ftrace_caller. The ftrace_regs_caller is rather special, and so is
function graph tracing.

I realized the ftrace_regs_caller code was complex due to me aggressively
saving flags, even though I could still do push, lea and mov without
changing them. That made the logic a little nicer.

Finally I added the fentry code.

I tested this with an older compiler (for mcount) with and without
FRAME_POINTER set. I also did it with a new compiler (with fentry), with and
without FRAME_POINTER. I tested function tracing, stack tracing, function_graph
tracing, and kprobes (as that uses the ftrace_regs_caller).

Please pull (or take the patch series) from:

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
tip/x86/ftrace

Head SHA1: fadff4e942659f37a2374438dbb12388a9518107


Steven Rostedt (VMware) (6):
  ftrace/x86_64: Rename mcount_64.S to ftrace_64.S
  ftrace/x86_32: Move the ftrace specific code out of entry_32.S
  ftrace/x86_32: Add stack frame pointer to ftrace_caller
  ftrace/x86_32: Clean up ftrace_regs_caller
  ftrace/x86_32: Add -mfentry support to x86_32 with DYNAMIC_FTRACE set
  ftrace/x86: Use Makefile logic instead of #ifdef for compiling ftrace_*.o



Changes since v4:

 * s/mcount_/ftrace_/ in comment header that states the name.
  (Namhyung Kim)

 * Added Masami's Reviewed-by tag to patch 3

 arch/x86/Kconfig |   2 +-
 arch/x86/entry/entry_32.S| 169 --
 arch/x86/kernel/Makefile |   5 +-
 arch/x86/kernel/ftrace_32.S  | 246 +++
 arch/x86/kernel/{mcount_64.S => ftrace_64.S} |   6 +-
 5 files changed, 251 insertions(+), 177 deletions(-)
 create mode 100644 arch/x86/kernel/ftrace_32.S
 rename arch/x86/kernel/{mcount_64.S => ftrace_64.S} (98%)


Diff against v4:

diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index de50c9084d16..97ede82aeb8c 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -1,5 +1,5 @@
 /*
- *  linux/arch/x86_64/mcount_64.S
+ *  linux/arch/x86_64/ftrace_32.S
  *
  *  Copyright (C) 2017  Steven Rostedt, VMware Inc.
  */
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index b9c46919d4fc..aef2361e7f83 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -1,5 +1,5 @@
 /*
- *  linux/arch/x86_64/mcount_64.S
+ *  linux/arch/x86_64/ftrace_64.S
  *
  *  Copyright (C) 2014  Steven Rostedt, Red Hat Inc
  */

[PATCH 6/6 v5] ftrace/x86: Use Makefile logic instead of #ifdef for compiling ftrace_*.o

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

Currently ftrace_32.S and ftrace_64.S are compiled even when
CONFIG_FUNCTION_TRACER is not set. This means there's an unnecessary #ifdef
to protect the code. Instead of using preprocessor directives, only compile
those files when FUNCTION_TRACER is defined.

Link: http://lkml.kernel.org/r/20170316210043.peycxdxktwwn6cid@treble
Suggested-by: Josh Poimboeuf 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/Makefile| 4 ++--
 arch/x86/kernel/ftrace_32.S | 3 ---
 arch/x86/kernel/ftrace_64.S | 4 
 3 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 55e8902c461f..4b994232cb57 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -46,8 +46,7 @@ obj-$(CONFIG_MODIFY_LDT_SYSCALL)  += ldt.o
 obj-y  += setup.o x86_init.o i8259.o irqinit.o jump_label.o
 obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y  += probe_roms.o
-obj-$(CONFIG_X86_64)   += sys_x86_64.o ftrace_64.o
-obj-$(CONFIG_X86_32)   += ftrace_32.o
+obj-$(CONFIG_X86_64)   += sys_x86_64.o
 obj-$(CONFIG_X86_ESPFIX64) += espfix_64.o
 obj-$(CONFIG_SYSFS)+= ksysfs.o
 obj-y  += bootflag.o e820.o
@@ -83,6 +82,7 @@ obj-y += apic/
 obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
 obj-$(CONFIG_DYNAMIC_FTRACE)   += ftrace.o
 obj-$(CONFIG_LIVEPATCH)+= livepatch.o
+obj-$(CONFIG_FUNCTION_TRACER)  += ftrace_$(BITS).o
 obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
 obj-$(CONFIG_FTRACE_SYSCALLS)  += ftrace.o
 obj-$(CONFIG_X86_TSC)  += trace_clock.o
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 15acf54083c1..97ede82aeb8c 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -10,8 +10,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_FUNCTION_TRACER
-
 #ifdef CC_USING_FENTRY
 # define function_hook __fentry__
 EXPORT_SYMBOL(__fentry__)
@@ -208,7 +206,6 @@ ftrace_stub:
jmp ftrace_stub
 END(function_hook)
 #endif /* CONFIG_DYNAMIC_FTRACE */
-#endif /* CONFIG_FUNCTION_TRACER */
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENTRY(ftrace_graph_caller)
diff --git a/arch/x86/kernel/ftrace_64.S b/arch/x86/kernel/ftrace_64.S
index fc0fe0e6c2de..aef2361e7f83 100644
--- a/arch/x86/kernel/ftrace_64.S
+++ b/arch/x86/kernel/ftrace_64.S
@@ -13,9 +13,6 @@
.code64
.section .entry.text, "ax"
 
-
-#ifdef CONFIG_FUNCTION_TRACER
-
 #ifdef CC_USING_FENTRY
 # define function_hook __fentry__
 EXPORT_SYMBOL(__fentry__)
@@ -297,7 +294,6 @@ trace:
jmp fgraph_trace
 END(function_hook)
 #endif /* CONFIG_DYNAMIC_FTRACE */
-#endif /* CONFIG_FUNCTION_TRACER */
 
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 ENTRY(ftrace_graph_caller)
-- 
2.10.2

[PATCH 1/6 v5] ftrace/x86_64: Rename mcount_64.S to ftrace_64.S

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

With the advent of -mfentry that uses the new "fentry" hook over mcount, the
mcount name is obsolete. Having the code file that ftrace hooks into called
"mcount*.S" is rather misleading. Rename it to ftrace_64.S

Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/Makefile | 4 ++--
 arch/x86/kernel/{mcount_64.S => ftrace_64.S} | 0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/x86/kernel/{mcount_64.S => ftrace_64.S} (100%)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 84c00592d359..d3743a37e990 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -27,7 +27,7 @@ KASAN_SANITIZE_stacktrace.o := n
 
 OBJECT_FILES_NON_STANDARD_head_$(BITS).o   := y
 OBJECT_FILES_NON_STANDARD_relocate_kernel_$(BITS).o:= y
-OBJECT_FILES_NON_STANDARD_mcount_$(BITS).o := y
+OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
 OBJECT_FILES_NON_STANDARD_test_nx.o:= y
 
 # If instrumentation of this dir is enabled, boot hangs during first second.
@@ -46,7 +46,7 @@ obj-$(CONFIG_MODIFY_LDT_SYSCALL)  += ldt.o
 obj-y  += setup.o x86_init.o i8259.o irqinit.o jump_label.o
 obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y  += probe_roms.o
-obj-$(CONFIG_X86_64)   += sys_x86_64.o mcount_64.o
+obj-$(CONFIG_X86_64)   += sys_x86_64.o ftrace_64.o
 obj-$(CONFIG_X86_ESPFIX64) += espfix_64.o
 obj-$(CONFIG_SYSFS)+= ksysfs.o
 obj-y  += bootflag.o e820.o
diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/ftrace_64.S
similarity index 100%
rename from arch/x86/kernel/mcount_64.S
rename to arch/x86/kernel/ftrace_64.S
-- 
2.10.2

[PATCH 1/6 v5] ftrace/x86_64: Rename mcount_64.S to ftrace_64.S

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

With the advent of -mfentry that uses the new "fentry" hook over mcount, the
mcount name is obsolete. Having the code file that ftrace hooks into called
"mcount*.S" is rather misleading. Rename it to ftrace_64.S

Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/Makefile | 4 ++--
 arch/x86/kernel/{mcount_64.S => ftrace_64.S} | 0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/x86/kernel/{mcount_64.S => ftrace_64.S} (100%)

diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 84c00592d359..d3743a37e990 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -27,7 +27,7 @@ KASAN_SANITIZE_stacktrace.o := n
 
 OBJECT_FILES_NON_STANDARD_head_$(BITS).o   := y
 OBJECT_FILES_NON_STANDARD_relocate_kernel_$(BITS).o:= y
-OBJECT_FILES_NON_STANDARD_mcount_$(BITS).o := y
+OBJECT_FILES_NON_STANDARD_ftrace_$(BITS).o := y
 OBJECT_FILES_NON_STANDARD_test_nx.o:= y
 
 # If instrumentation of this dir is enabled, boot hangs during first second.
@@ -46,7 +46,7 @@ obj-$(CONFIG_MODIFY_LDT_SYSCALL)  += ldt.o
 obj-y  += setup.o x86_init.o i8259.o irqinit.o jump_label.o
 obj-$(CONFIG_IRQ_WORK)  += irq_work.o
 obj-y  += probe_roms.o
-obj-$(CONFIG_X86_64)   += sys_x86_64.o mcount_64.o
+obj-$(CONFIG_X86_64)   += sys_x86_64.o ftrace_64.o
 obj-$(CONFIG_X86_ESPFIX64) += espfix_64.o
 obj-$(CONFIG_SYSFS)+= ksysfs.o
 obj-y  += bootflag.o e820.o
diff --git a/arch/x86/kernel/mcount_64.S b/arch/x86/kernel/ftrace_64.S
similarity index 100%
rename from arch/x86/kernel/mcount_64.S
rename to arch/x86/kernel/ftrace_64.S
-- 
2.10.2

Re: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver

[Lucas Stach]

Hi Dong,

Am Freitag, den 24.03.2017, 14:24 +0800 schrieb Dong Aisheng:
[...]
> > +static struct platform_driver imx7_pgc_domain_driver = {
> > +   .driver = {
> > +   .name = "imx7-pgc",
> > +   },
> > +   .probe= imx7_pgc_domain_probe,
> > +   .remove   = imx7_pgc_domain_remove,
> > +   .id_table = imx7_pgc_domain_id,
> > +};
> > +builtin_platform_driver(imx7_pgc_domain_driver)
> 
> Again, i have a fundamental question about this patch implementation
> that why we choose above way to register the power domain?
> 
> I'm sorry that i did not know too much history.
> Would you guys please help share some information?
> 
> Because AFAIK this way will register each domain as a power domain
> provider which is a bit violate the real HW and current power domain
> framework design. And it is a bit more complicated to use than before.
> 
> IMHO i would rather prefer the old traditional and simpler way that one
> provider (GPC) supplies multiple domains (PCIE/MIPI/HSIC PHY domain)
> than this patch does.
> 
> However, i might be wrong. Please help to clear.

This way we can properly describe each power domain with the regulator
supplying the domain and the clocks of the devices inside the domain in
the device tree.

This is needed as for the upstream version we are controlling the
regulator from the GPC driver, as opposed to the downstream version,
where each device has to implement the regulator handling and power
up/down sequencing.

See the rationale in the commits adding the multidomain support to the
i.MX6 GPC.

Regards,
Lucas

Re: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver

[Lucas Stach]

Hi Dong,

Am Freitag, den 24.03.2017, 14:24 +0800 schrieb Dong Aisheng:
[...]
> > +static struct platform_driver imx7_pgc_domain_driver = {
> > +   .driver = {
> > +   .name = "imx7-pgc",
> > +   },
> > +   .probe= imx7_pgc_domain_probe,
> > +   .remove   = imx7_pgc_domain_remove,
> > +   .id_table = imx7_pgc_domain_id,
> > +};
> > +builtin_platform_driver(imx7_pgc_domain_driver)
> 
> Again, i have a fundamental question about this patch implementation
> that why we choose above way to register the power domain?
> 
> I'm sorry that i did not know too much history.
> Would you guys please help share some information?
> 
> Because AFAIK this way will register each domain as a power domain
> provider which is a bit violate the real HW and current power domain
> framework design. And it is a bit more complicated to use than before.
> 
> IMHO i would rather prefer the old traditional and simpler way that one
> provider (GPC) supplies multiple domains (PCIE/MIPI/HSIC PHY domain)
> than this patch does.
> 
> However, i might be wrong. Please help to clear.

This way we can properly describe each power domain with the regulator
supplying the domain and the clocks of the devices inside the domain in
the device tree.

This is needed as for the upstream version we are controlling the
regulator from the GPC driver, as opposed to the downstream version,
where each device has to implement the regulator handling and power
up/down sequencing.

See the rationale in the commits adding the multidomain support to the
i.MX6 GPC.

Regards,
Lucas

[PATCH 2/6 v5] ftrace/x86_32: Move the ftrace specific code out of entry_32.S

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

The function tracing hook code for ftrace is not an entry point from
userspace and does not belong in the entry_*.S files. It has already been
moved out of entry_64.S. This moves it out of entry_32.S into its own
ftrace_32.S file.

Also updated the comment in ftrace_64.S to state the correct file name.

Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/entry/entry_32.S   | 169 --
 arch/x86/kernel/Makefile|   1 +
 arch/x86/kernel/ftrace_32.S | 177 
 arch/x86/kernel/ftrace_64.S |   2 +-
 4 files changed, 179 insertions(+), 170 deletions(-)
 create mode 100644 arch/x86/kernel/ftrace_32.S

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 57f7ec35216e..169b3b0c5ec6 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -35,16 +35,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
.section .entry.text, "ax"
@@ -886,172 +883,6 @@ BUILD_INTERRUPT3(hyperv_callback_vector, 
HYPERVISOR_CALLBACK_VECTOR,
 
 #endif /* CONFIG_HYPERV */
 
-#ifdef CONFIG_FUNCTION_TRACER
-#ifdef CONFIG_DYNAMIC_FTRACE
-
-ENTRY(mcount)
-   ret
-END(mcount)
-
-ENTRY(ftrace_caller)
-   pushl   %eax
-   pushl   %ecx
-   pushl   %edx
-   pushl   $0  /* Pass NULL as regs pointer */
-   movl4*4(%esp), %eax
-   movl0x4(%ebp), %edx
-   movlfunction_trace_op, %ecx
-   subl$MCOUNT_INSN_SIZE, %eax
-
-.globl ftrace_call
-ftrace_call:
-   callftrace_stub
-
-   addl$4, %esp/* skip NULL pointer */
-   popl%edx
-   popl%ecx
-   popl%eax
-.Lftrace_ret:
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-.globl ftrace_graph_call
-ftrace_graph_call:
-   jmp ftrace_stub
-#endif
-
-/* This is weak to keep gas from relaxing the jumps */
-WEAK(ftrace_stub)
-   ret
-END(ftrace_caller)
-
-ENTRY(ftrace_regs_caller)
-   pushf   /* push flags before compare (in cs location) */
-
-   /*
-* i386 does not save SS and ESP when coming from kernel.
-* Instead, to get sp, >sp is used (see ptrace.h).
-* Unfortunately, that means eflags must be at the same location
-* as the current return ip is. We move the return ip into the
-* ip location, and move flags into the return ip location.
-*/
-   pushl   4(%esp) /* save return ip into ip slot 
*/
-
-   pushl   $0  /* Load 0 into orig_ax */
-   pushl   %gs
-   pushl   %fs
-   pushl   %es
-   pushl   %ds
-   pushl   %eax
-   pushl   %ebp
-   pushl   %edi
-   pushl   %esi
-   pushl   %edx
-   pushl   %ecx
-   pushl   %ebx
-
-   movl13*4(%esp), %eax/* Get the saved flags */
-   movl%eax, 14*4(%esp)/* Move saved flags into 
regs->flags location */
-   /* clobbering return ip */
-   movl$__KERNEL_CS, 13*4(%esp)
-
-   movl12*4(%esp), %eax/* Load ip (1st parameter) */
-   subl$MCOUNT_INSN_SIZE, %eax /* Adjust ip */
-   movl0x4(%ebp), %edx /* Load parent ip (2nd 
parameter) */
-   movlfunction_trace_op, %ecx /* Save ftrace_pos in 3rd 
parameter */
-   pushl   %esp/* Save pt_regs as 4th 
parameter */
-
-GLOBAL(ftrace_regs_call)
-   callftrace_stub
-
-   addl$4, %esp/* Skip pt_regs */
-   movl14*4(%esp), %eax/* Move flags back into cs */
-   movl%eax, 13*4(%esp)/* Needed to keep addl  from 
modifying flags */
-   movl12*4(%esp), %eax/* Get return ip from regs->ip 
*/
-   movl%eax, 14*4(%esp)/* Put return ip back for ret */
-
-   popl%ebx
-   popl%ecx
-   popl%edx
-   popl%esi
-   popl%edi
-   popl%ebp
-   popl%eax
-   popl%ds
-   popl%es
-   popl%fs
-   popl%gs
-   addl$8, %esp/* Skip orig_ax and ip */
-   popf/* Pop flags at end (no addl to 
corrupt flags) */
-   jmp .Lftrace_ret
-
-   popf
-   jmp ftrace_stub
-#else /* ! CONFIG_DYNAMIC_FTRACE */
-
-ENTRY(mcount)
-   cmpl$__PAGE_OFFSET, %esp
-   jb  ftrace_stub /* Paging not enabled yet? */
-
-   cmpl$ftrace_stub, ftrace_trace_function
-   jnz .Ltrace
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-   cmpl$ftrace_stub, ftrace_graph_return
-   jnz ftrace_graph_caller
-
-   cmpl

Re: [PATCH v7 1/2] dt-bindings: Add GPCv2 power gating driver

[Dong Aisheng]

On Tue, Mar 21, 2017 at 07:50:03AM -0700, Andrey Smirnov wrote:
> Add DT bindings for power domain driver for GPCv2 IP block found in
> i.MX7 SoCs.
> 
> Cc: yurov...@gmail.com
> Cc: Lucas Stach 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Fabio Estevam 
> Cc: Dong Aisheng 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Rob Herring 
> Signed-off-by: Andrey Smirnov 
> ---
>  .../devicetree/bindings/power/fsl,imx-gpcv2.txt| 71 
> ++
>  include/dt-bindings/power/imx7-power.h | 18 ++
>  2 files changed, 89 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>  create mode 100644 include/dt-bindings/power/imx7-power.h
> 
> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt 
> b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> new file mode 100644
> index 000..02f45c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> @@ -0,0 +1,71 @@
> +Freescale i.MX General Power Controller v2
> +==
> +
> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
> +Control (PGC) for various power domains.
> +
> +Required properties:
> +
> +- compatible: Should be "fsl,imx7d-gpc"
> +
> +- reg: should be register base and length as documented in the
> +  datasheet
> +
> +- interrupts: Should contain GPC interrupt request 1
> +
> +Power domains contained within GPC node are generic power domain
> +providers, documented in
> +Documentation/devicetree/bindings/power/power_domain.txt, which are
> +described as subnodes of the power gating controller 'pgc' node,
> +which, in turn, is expected to contain the following:
> +
> +Required properties:
> +
> +- reg: Power domain index. Valid values are defined in
> +  include/dt-bindings/power/imx7-power.h
> +
> +- #power-domain-cells: Should be 0
> +
> +Optional properties:
> +
> +- power-supply: Power supply used to power the domain
> +
> +Example:
> +
> + gpc: gpc@303a {
> + compatible = "fsl,imx7d-gpc";
> + reg = <0x303a 0x1000>;
> + interrupt-controller;
> + interrupts = ;
> + #interrupt-cells = <3>;
> + interrupt-parent = <>;
> +
> + pgc {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pgc_pcie_phy: power-domain@3 {
> + #power-domain-cells = <0>;
> +
> + reg = ;
> + power-supply = <_1p0d>;
> + };
> + };
> + };
> +
> +
> +Specifying power domain for IP modules
> +==
> +
> +IP cores belonging to a power domain should contain a 'power-domains'
> +property that is a phandle for PGC node representing the domain.
> +
> +Example of a device that is part of the PCIE_PHY power domain:
> +
> + pcie: pcie@3380 {
> +   reg = <0x3380 0x4000>,
> + <0x4ff0 0x8>;
> + /* ... */
> + power-domains = <_pcie_phy>;
> + /* ... */
> + };
> diff --git a/include/dt-bindings/power/imx7-power.h 
> b/include/dt-bindings/power/imx7-power.h
> new file mode 100644
> index 000..eb70023
> --- /dev/null
> +++ b/include/dt-bindings/power/imx7-power.h
> @@ -0,0 +1,18 @@
> +/*
> + *  Copyright (C) 2017 Impinj
> + *
> + * 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.
> + */
> +
> +#ifndef __DT_BINDINGS_IMX7_POWER_H__
> +#define __DT_BINDINGS_IMX7_POWER_H__
> +
> +#define IMX7_POWER_DOMAIN_USB_HSIC_PHY   0
> +#define IMX7_POWER_DOMAIN_USB_OTG2_PHY   1
> +#define IMX7_POWER_DOMAIN_USB_OTG1_PHY   2
> +#define IMX7_POWER_DOMAIN_PCIE_PHY   3
> +#define IMX7_POWER_DOMAIN_MIPI_PHY   4

Nitpick: Probably better to define according to the reference manual
defined order.

0x800 ~ 0x83F : PGC for A7 core0
0x840 ~ 0x87F: PGC for A7 core1
0x880 ~ 0x8BF: PGC for A7 SCU
0xA00 ~ 0xA3F: PGC for fastmix/megamix
0xC00 ~ 0xC3F: PGC for MIPI PHY
0xC40 ~ 0xC7F: PGC for PCIE_PHY
0xC80 ~ 0xCBF: Reserved
0xCC0 ~ 0xCFF: Reserved
0xD00 ~ 0xD3F: PGC for USB HSIC PHY

You can drop A7 core/scu/fastmix/megamix as well.

> +
> +#endif
> -- 
> 2.9.3
> 

Regards
Dong Aisheng

[PATCH 5/6 v5] ftrace/x86_32: Add -mfentry support to x86_32 with DYNAMIC_FTRACE set

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

x86_64 has had fentry support for some time. I did not add support to x86_32
as I was unsure if it will be used much in the future. It is still very much
used, and there's issues with function graph tracing with gcc playing around
with the mcount frames, causing function graph to panic. The fentry code
does not have this issue, and is able to cope as there is no frame to mess
up.

Note, this only add support for fentry when DYNAMIC_FTRACE is set. There's
really no reason to not have that set, because the performance of the
machine drops significantly when it's not enabled. I only keep
!DYNAMIC_FTRACE around to test it off, as there's still some archs that have
FTRACE but not DYNAMIC_FTRACE.

Reviewed-by: Masami Hiramatsu 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/Kconfig|  2 +-
 arch/x86/kernel/ftrace_32.S | 82 +++--
 2 files changed, 73 insertions(+), 11 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc98d5a294ee..8c17146427ca 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -127,7 +127,7 @@ config X86
select HAVE_EBPF_JITif X86_64
select HAVE_EFFICIENT_UNALIGNED_ACCESS
select HAVE_EXIT_THREAD
-   select HAVE_FENTRY  if X86_64
+   select HAVE_FENTRY  if X86_64 || DYNAMIC_FTRACE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 63e28504debf..15acf54083c1 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -11,26 +11,68 @@
 #include 
 
 #ifdef CONFIG_FUNCTION_TRACER
+
+#ifdef CC_USING_FENTRY
+# define function_hook __fentry__
+EXPORT_SYMBOL(__fentry__)
+#else
+# define function_hook mcount
+EXPORT_SYMBOL(mcount)
+#endif
+
 #ifdef CONFIG_DYNAMIC_FTRACE
 
-ENTRY(mcount)
+/* mcount uses a frame pointer even if CONFIG_FRAME_POINTER is not set */
+#if !defined(CC_USING_FENTRY) || defined(CONFIG_FRAME_POINTER)
+# define USING_FRAME_POINTER
+#endif
+
+#ifdef USING_FRAME_POINTER
+# define MCOUNT_FRAME  1   /* using frame = true  */
+#else
+# define MCOUNT_FRAME  0   /* using frame = false */
+#endif
+
+ENTRY(function_hook)
ret
-END(mcount)
+END(function_hook)
 
 ENTRY(ftrace_caller)
 
+#ifdef USING_FRAME_POINTER
+# ifdef CC_USING_FENTRY
+   /*
+* Frame pointers are of ip followed by bp.
+* Since fentry is an immediate jump, we are left with
+* parent-ip, function-ip. We need to add a frame with
+* parent-ip followed by ebp.
+*/
+   pushl   4(%esp) /* parent ip */
pushl   %ebp
movl%esp, %ebp
-
+   pushl   2*4(%esp)   /* function ip */
+# endif
+   /* For mcount, the function ip is directly above */
+   pushl   %ebp
+   movl%esp, %ebp
+#endif
pushl   %eax
pushl   %ecx
pushl   %edx
pushl   $0  /* Pass NULL as regs pointer */
-   movl5*4(%esp), %eax
-   /* Copy original ebp into %edx */
+
+#ifdef USING_FRAME_POINTER
+   /* Load parent ebp into edx */
movl4*4(%esp), %edx
+#else
+   /* There's no frame pointer, load the appropriate stack addr instead */
+   lea 4*4(%esp), %edx
+#endif
+
+   movl(MCOUNT_FRAME+4)*4(%esp), %eax  /* load the rip */
/* Get the parent ip */
-   movl0x4(%edx), %edx
+   movl4(%edx), %edx   /* edx has ebp */
+
movlfunction_trace_op, %ecx
subl$MCOUNT_INSN_SIZE, %eax
 
@@ -42,7 +84,14 @@ ftrace_call:
popl%edx
popl%ecx
popl%eax
+#ifdef USING_FRAME_POINTER
popl%ebp
+# ifdef CC_USING_FENTRY
+   addl$4,%esp /* skip function ip */
+   popl%ebp/* this is the orig bp */
+   addl$4, %esp/* skip parent ip */
+# endif
+#endif
 .Lftrace_ret:
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 .globl ftrace_graph_call
@@ -83,6 +132,10 @@ ENTRY(ftrace_regs_caller)
pushl   %edx
pushl   %ecx
pushl   %ebx
+#ifdef CC_USING_FENTRY
+   /* Load 4 off of the parent ip addr into ebp */
+   lea 14*4(%esp), %ebp
+#endif
 
movl12*4(%esp), %eax/* Load ip (1st parameter) */
subl$MCOUNT_INSN_SIZE, %eax /* Adjust ip */
@@ -121,7 +174,7 @@ GLOBAL(ftrace_regs_call)
jmp .Lftrace_ret
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
-ENTRY(mcount)
+ENTRY(function_hook)
cmpl$__PAGE_OFFSET, %esp
jb  ftrace_stub /* Paging not enabled 

[PATCH 2/6 v5] ftrace/x86_32: Move the ftrace specific code out of entry_32.S

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

The function tracing hook code for ftrace is not an entry point from
userspace and does not belong in the entry_*.S files. It has already been
moved out of entry_64.S. This moves it out of entry_32.S into its own
ftrace_32.S file.

Also updated the comment in ftrace_64.S to state the correct file name.

Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/entry/entry_32.S   | 169 --
 arch/x86/kernel/Makefile|   1 +
 arch/x86/kernel/ftrace_32.S | 177 
 arch/x86/kernel/ftrace_64.S |   2 +-
 4 files changed, 179 insertions(+), 170 deletions(-)
 create mode 100644 arch/x86/kernel/ftrace_32.S

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 57f7ec35216e..169b3b0c5ec6 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -35,16 +35,13 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
.section .entry.text, "ax"
@@ -886,172 +883,6 @@ BUILD_INTERRUPT3(hyperv_callback_vector, 
HYPERVISOR_CALLBACK_VECTOR,
 
 #endif /* CONFIG_HYPERV */
 
-#ifdef CONFIG_FUNCTION_TRACER
-#ifdef CONFIG_DYNAMIC_FTRACE
-
-ENTRY(mcount)
-   ret
-END(mcount)
-
-ENTRY(ftrace_caller)
-   pushl   %eax
-   pushl   %ecx
-   pushl   %edx
-   pushl   $0  /* Pass NULL as regs pointer */
-   movl4*4(%esp), %eax
-   movl0x4(%ebp), %edx
-   movlfunction_trace_op, %ecx
-   subl$MCOUNT_INSN_SIZE, %eax
-
-.globl ftrace_call
-ftrace_call:
-   callftrace_stub
-
-   addl$4, %esp/* skip NULL pointer */
-   popl%edx
-   popl%ecx
-   popl%eax
-.Lftrace_ret:
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-.globl ftrace_graph_call
-ftrace_graph_call:
-   jmp ftrace_stub
-#endif
-
-/* This is weak to keep gas from relaxing the jumps */
-WEAK(ftrace_stub)
-   ret
-END(ftrace_caller)
-
-ENTRY(ftrace_regs_caller)
-   pushf   /* push flags before compare (in cs location) */
-
-   /*
-* i386 does not save SS and ESP when coming from kernel.
-* Instead, to get sp, >sp is used (see ptrace.h).
-* Unfortunately, that means eflags must be at the same location
-* as the current return ip is. We move the return ip into the
-* ip location, and move flags into the return ip location.
-*/
-   pushl   4(%esp) /* save return ip into ip slot 
*/
-
-   pushl   $0  /* Load 0 into orig_ax */
-   pushl   %gs
-   pushl   %fs
-   pushl   %es
-   pushl   %ds
-   pushl   %eax
-   pushl   %ebp
-   pushl   %edi
-   pushl   %esi
-   pushl   %edx
-   pushl   %ecx
-   pushl   %ebx
-
-   movl13*4(%esp), %eax/* Get the saved flags */
-   movl%eax, 14*4(%esp)/* Move saved flags into 
regs->flags location */
-   /* clobbering return ip */
-   movl$__KERNEL_CS, 13*4(%esp)
-
-   movl12*4(%esp), %eax/* Load ip (1st parameter) */
-   subl$MCOUNT_INSN_SIZE, %eax /* Adjust ip */
-   movl0x4(%ebp), %edx /* Load parent ip (2nd 
parameter) */
-   movlfunction_trace_op, %ecx /* Save ftrace_pos in 3rd 
parameter */
-   pushl   %esp/* Save pt_regs as 4th 
parameter */
-
-GLOBAL(ftrace_regs_call)
-   callftrace_stub
-
-   addl$4, %esp/* Skip pt_regs */
-   movl14*4(%esp), %eax/* Move flags back into cs */
-   movl%eax, 13*4(%esp)/* Needed to keep addl  from 
modifying flags */
-   movl12*4(%esp), %eax/* Get return ip from regs->ip 
*/
-   movl%eax, 14*4(%esp)/* Put return ip back for ret */
-
-   popl%ebx
-   popl%ecx
-   popl%edx
-   popl%esi
-   popl%edi
-   popl%ebp
-   popl%eax
-   popl%ds
-   popl%es
-   popl%fs
-   popl%gs
-   addl$8, %esp/* Skip orig_ax and ip */
-   popf/* Pop flags at end (no addl to 
corrupt flags) */
-   jmp .Lftrace_ret
-
-   popf
-   jmp ftrace_stub
-#else /* ! CONFIG_DYNAMIC_FTRACE */
-
-ENTRY(mcount)
-   cmpl$__PAGE_OFFSET, %esp
-   jb  ftrace_stub /* Paging not enabled yet? */
-
-   cmpl$ftrace_stub, ftrace_trace_function
-   jnz .Ltrace
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-   cmpl$ftrace_stub, ftrace_graph_return
-   jnz ftrace_graph_caller
-
-   cmpl$ftrace_graph_entry_stub, ftrace_graph_entry
-   

Re: [PATCH v7 1/2] dt-bindings: Add GPCv2 power gating driver

[Dong Aisheng]

On Tue, Mar 21, 2017 at 07:50:03AM -0700, Andrey Smirnov wrote:
> Add DT bindings for power domain driver for GPCv2 IP block found in
> i.MX7 SoCs.
> 
> Cc: yurov...@gmail.com
> Cc: Lucas Stach 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Fabio Estevam 
> Cc: Dong Aisheng 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Rob Herring 
> Signed-off-by: Andrey Smirnov 
> ---
>  .../devicetree/bindings/power/fsl,imx-gpcv2.txt| 71 
> ++
>  include/dt-bindings/power/imx7-power.h | 18 ++
>  2 files changed, 89 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>  create mode 100644 include/dt-bindings/power/imx7-power.h
> 
> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt 
> b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> new file mode 100644
> index 000..02f45c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> @@ -0,0 +1,71 @@
> +Freescale i.MX General Power Controller v2
> +==
> +
> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
> +Control (PGC) for various power domains.
> +
> +Required properties:
> +
> +- compatible: Should be "fsl,imx7d-gpc"
> +
> +- reg: should be register base and length as documented in the
> +  datasheet
> +
> +- interrupts: Should contain GPC interrupt request 1
> +
> +Power domains contained within GPC node are generic power domain
> +providers, documented in
> +Documentation/devicetree/bindings/power/power_domain.txt, which are
> +described as subnodes of the power gating controller 'pgc' node,
> +which, in turn, is expected to contain the following:
> +
> +Required properties:
> +
> +- reg: Power domain index. Valid values are defined in
> +  include/dt-bindings/power/imx7-power.h
> +
> +- #power-domain-cells: Should be 0
> +
> +Optional properties:
> +
> +- power-supply: Power supply used to power the domain
> +
> +Example:
> +
> + gpc: gpc@303a {
> + compatible = "fsl,imx7d-gpc";
> + reg = <0x303a 0x1000>;
> + interrupt-controller;
> + interrupts = ;
> + #interrupt-cells = <3>;
> + interrupt-parent = <>;
> +
> + pgc {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pgc_pcie_phy: power-domain@3 {
> + #power-domain-cells = <0>;
> +
> + reg = ;
> + power-supply = <_1p0d>;
> + };
> + };
> + };
> +
> +
> +Specifying power domain for IP modules
> +==
> +
> +IP cores belonging to a power domain should contain a 'power-domains'
> +property that is a phandle for PGC node representing the domain.
> +
> +Example of a device that is part of the PCIE_PHY power domain:
> +
> + pcie: pcie@3380 {
> +   reg = <0x3380 0x4000>,
> + <0x4ff0 0x8>;
> + /* ... */
> + power-domains = <_pcie_phy>;
> + /* ... */
> + };
> diff --git a/include/dt-bindings/power/imx7-power.h 
> b/include/dt-bindings/power/imx7-power.h
> new file mode 100644
> index 000..eb70023
> --- /dev/null
> +++ b/include/dt-bindings/power/imx7-power.h
> @@ -0,0 +1,18 @@
> +/*
> + *  Copyright (C) 2017 Impinj
> + *
> + * 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.
> + */
> +
> +#ifndef __DT_BINDINGS_IMX7_POWER_H__
> +#define __DT_BINDINGS_IMX7_POWER_H__
> +
> +#define IMX7_POWER_DOMAIN_USB_HSIC_PHY   0
> +#define IMX7_POWER_DOMAIN_USB_OTG2_PHY   1
> +#define IMX7_POWER_DOMAIN_USB_OTG1_PHY   2
> +#define IMX7_POWER_DOMAIN_PCIE_PHY   3
> +#define IMX7_POWER_DOMAIN_MIPI_PHY   4

Nitpick: Probably better to define according to the reference manual
defined order.

0x800 ~ 0x83F : PGC for A7 core0
0x840 ~ 0x87F: PGC for A7 core1
0x880 ~ 0x8BF: PGC for A7 SCU
0xA00 ~ 0xA3F: PGC for fastmix/megamix
0xC00 ~ 0xC3F: PGC for MIPI PHY
0xC40 ~ 0xC7F: PGC for PCIE_PHY
0xC80 ~ 0xCBF: Reserved
0xCC0 ~ 0xCFF: Reserved
0xD00 ~ 0xD3F: PGC for USB HSIC PHY

You can drop A7 core/scu/fastmix/megamix as well.

> +
> +#endif
> -- 
> 2.9.3
> 

Regards
Dong Aisheng

[PATCH 5/6 v5] ftrace/x86_32: Add -mfentry support to x86_32 with DYNAMIC_FTRACE set

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

x86_64 has had fentry support for some time. I did not add support to x86_32
as I was unsure if it will be used much in the future. It is still very much
used, and there's issues with function graph tracing with gcc playing around
with the mcount frames, causing function graph to panic. The fentry code
does not have this issue, and is able to cope as there is no frame to mess
up.

Note, this only add support for fentry when DYNAMIC_FTRACE is set. There's
really no reason to not have that set, because the performance of the
machine drops significantly when it's not enabled. I only keep
!DYNAMIC_FTRACE around to test it off, as there's still some archs that have
FTRACE but not DYNAMIC_FTRACE.

Reviewed-by: Masami Hiramatsu 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/Kconfig|  2 +-
 arch/x86/kernel/ftrace_32.S | 82 +++--
 2 files changed, 73 insertions(+), 11 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cc98d5a294ee..8c17146427ca 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -127,7 +127,7 @@ config X86
select HAVE_EBPF_JITif X86_64
select HAVE_EFFICIENT_UNALIGNED_ACCESS
select HAVE_EXIT_THREAD
-   select HAVE_FENTRY  if X86_64
+   select HAVE_FENTRY  if X86_64 || DYNAMIC_FTRACE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index 63e28504debf..15acf54083c1 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -11,26 +11,68 @@
 #include 
 
 #ifdef CONFIG_FUNCTION_TRACER
+
+#ifdef CC_USING_FENTRY
+# define function_hook __fentry__
+EXPORT_SYMBOL(__fentry__)
+#else
+# define function_hook mcount
+EXPORT_SYMBOL(mcount)
+#endif
+
 #ifdef CONFIG_DYNAMIC_FTRACE
 
-ENTRY(mcount)
+/* mcount uses a frame pointer even if CONFIG_FRAME_POINTER is not set */
+#if !defined(CC_USING_FENTRY) || defined(CONFIG_FRAME_POINTER)
+# define USING_FRAME_POINTER
+#endif
+
+#ifdef USING_FRAME_POINTER
+# define MCOUNT_FRAME  1   /* using frame = true  */
+#else
+# define MCOUNT_FRAME  0   /* using frame = false */
+#endif
+
+ENTRY(function_hook)
ret
-END(mcount)
+END(function_hook)
 
 ENTRY(ftrace_caller)
 
+#ifdef USING_FRAME_POINTER
+# ifdef CC_USING_FENTRY
+   /*
+* Frame pointers are of ip followed by bp.
+* Since fentry is an immediate jump, we are left with
+* parent-ip, function-ip. We need to add a frame with
+* parent-ip followed by ebp.
+*/
+   pushl   4(%esp) /* parent ip */
pushl   %ebp
movl%esp, %ebp
-
+   pushl   2*4(%esp)   /* function ip */
+# endif
+   /* For mcount, the function ip is directly above */
+   pushl   %ebp
+   movl%esp, %ebp
+#endif
pushl   %eax
pushl   %ecx
pushl   %edx
pushl   $0  /* Pass NULL as regs pointer */
-   movl5*4(%esp), %eax
-   /* Copy original ebp into %edx */
+
+#ifdef USING_FRAME_POINTER
+   /* Load parent ebp into edx */
movl4*4(%esp), %edx
+#else
+   /* There's no frame pointer, load the appropriate stack addr instead */
+   lea 4*4(%esp), %edx
+#endif
+
+   movl(MCOUNT_FRAME+4)*4(%esp), %eax  /* load the rip */
/* Get the parent ip */
-   movl0x4(%edx), %edx
+   movl4(%edx), %edx   /* edx has ebp */
+
movlfunction_trace_op, %ecx
subl$MCOUNT_INSN_SIZE, %eax
 
@@ -42,7 +84,14 @@ ftrace_call:
popl%edx
popl%ecx
popl%eax
+#ifdef USING_FRAME_POINTER
popl%ebp
+# ifdef CC_USING_FENTRY
+   addl$4,%esp /* skip function ip */
+   popl%ebp/* this is the orig bp */
+   addl$4, %esp/* skip parent ip */
+# endif
+#endif
 .Lftrace_ret:
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 .globl ftrace_graph_call
@@ -83,6 +132,10 @@ ENTRY(ftrace_regs_caller)
pushl   %edx
pushl   %ecx
pushl   %ebx
+#ifdef CC_USING_FENTRY
+   /* Load 4 off of the parent ip addr into ebp */
+   lea 14*4(%esp), %ebp
+#endif
 
movl12*4(%esp), %eax/* Load ip (1st parameter) */
subl$MCOUNT_INSN_SIZE, %eax /* Adjust ip */
@@ -121,7 +174,7 @@ GLOBAL(ftrace_regs_call)
jmp .Lftrace_ret
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
-ENTRY(mcount)
+ENTRY(function_hook)
cmpl$__PAGE_OFFSET, %esp
jb  ftrace_stub /* Paging not enabled yet? */
 
@@ -153,9 +206,8 @@ ftrace_stub:
popl%ecx
popl%eax
 

[PATCH 4/6 v5] ftrace/x86_32: Clean up ftrace_regs_caller

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

When ftrace_regs_caller was created, it was designed to preserve flags as
much as possible as it needed to act just like a breakpoint triggered on the
same location. But the design is over complicated as it treated all
operations as modifying flags. But push, mov and lea do not modify flags.
This means the code can become more simplified by allowing flags to be
stored further down.

Making ftrace_regs_caller simpler will also be useful in implementing fentry
logic.

Link: http://lkml.kernel.org/r/20170316135328.36123...@gandalf.local.home
[ simpler logic to save flags ]
Suggested-by: Linus Torvalds 
Reviewed-by: Masami Hiramatsu 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/ftrace_32.S | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index a28f1907e1e1..63e28504debf 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -56,23 +56,27 @@ WEAK(ftrace_stub)
 END(ftrace_caller)
 
 ENTRY(ftrace_regs_caller)
-   pushf   /* push flags before compare (in cs location) */
-
/*
 * i386 does not save SS and ESP when coming from kernel.
 * Instead, to get sp, >sp is used (see ptrace.h).
 * Unfortunately, that means eflags must be at the same location
 * as the current return ip is. We move the return ip into the
-* ip location, and move flags into the return ip location.
+* regs->ip location, and move flags into the return ip location.
 */
-   pushl   4(%esp) /* save return ip into ip slot 
*/
-
+   pushl   $__KERNEL_CS
+   pushl   4(%esp) /* Save the return ip */
pushl   $0  /* Load 0 into orig_ax */
pushl   %gs
pushl   %fs
pushl   %es
pushl   %ds
pushl   %eax
+
+   /* Get flags and place them into the return ip slot */
+   pushf
+   popl%eax
+   movl%eax, 8*4(%esp)
+
pushl   %ebp
pushl   %edi
pushl   %esi
@@ -80,11 +84,6 @@ ENTRY(ftrace_regs_caller)
pushl   %ecx
pushl   %ebx
 
-   movl13*4(%esp), %eax/* Get the saved flags */
-   movl%eax, 14*4(%esp)/* Move saved flags into 
regs->flags location */
-   /* clobbering return ip */
-   movl$__KERNEL_CS, 13*4(%esp)
-
movl12*4(%esp), %eax/* Load ip (1st parameter) */
subl$MCOUNT_INSN_SIZE, %eax /* Adjust ip */
movl0x4(%ebp), %edx /* Load parent ip (2nd 
parameter) */
@@ -95,10 +94,14 @@ GLOBAL(ftrace_regs_call)
callftrace_stub
 
addl$4, %esp/* Skip pt_regs */
-   movl14*4(%esp), %eax/* Move flags back into cs */
-   movl%eax, 13*4(%esp)/* Needed to keep addl  from 
modifying flags */
-   movl12*4(%esp), %eax/* Get return ip from regs->ip 
*/
-   movl%eax, 14*4(%esp)/* Put return ip back for ret */
+
+   /* restore flags */
+   push14*4(%esp)
+   popf
+
+   /* Move return ip back to its original location */
+   movl12*4(%esp), %eax
+   movl%eax, 14*4(%esp)
 
popl%ebx
popl%ecx
@@ -111,12 +114,11 @@ GLOBAL(ftrace_regs_call)
popl%es
popl%fs
popl%gs
-   addl$8, %esp/* Skip orig_ax and ip */
-   popf/* Pop flags at end (no addl to 
corrupt flags) */
-   jmp .Lftrace_ret
 
-   popf
-   jmp ftrace_stub
+   /* use lea to not affect flags */
+   lea 3*4(%esp), %esp /* Skip orig_ax, ip and cs */
+
+   jmp .Lftrace_ret
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
 ENTRY(mcount)
-- 
2.10.2

[PATCH 3/6 v5] ftrace/x86_32: Add stack frame pointer to ftrace_caller

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

The function hook ftrace_caller does not create its own stack frame, and
this causes the ftrace stack trace to miss the first function when doing
stack traces.

 # echo schedule:stacktrace > /sys/kernel/tracing/set_ftrace_filter

Before:
 -0 [002] .N..29.865807: 
 => cpu_startup_entry
 => start_secondary
 => startup_32_smp
   <...>-7 [001] 29.866509: 
 => kthread
 => ret_from_fork
   <...>-1 [000] 29.865377: 
 => poll_schedule_timeout
 => do_select
 => core_sys_select
 => SyS_select
 => do_fast_syscall_32
 => entry_SYSENTER_32

After:
  -0 [002] .N..31.234853: 
 => do_idle
 => cpu_startup_entry
 => start_secondary
 => startup_32_smp
   <...>-7 [003] 31.235140: 
 => rcu_gp_kthread
 => kthread
 => ret_from_fork
   <...>-1819  [000] 31.264172: 
 => schedule_hrtimeout_range
 => poll_schedule_timeout
 => do_sys_poll
 => SyS_ppoll
 => do_fast_syscall_32
 => entry_SYSENTER_32

Reviewed-by: Josh Poimboeuf 
Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/ftrace_32.S | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index f380604514e4..a28f1907e1e1 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -18,12 +18,19 @@ ENTRY(mcount)
 END(mcount)
 
 ENTRY(ftrace_caller)
+
+   pushl   %ebp
+   movl%esp, %ebp
+
pushl   %eax
pushl   %ecx
pushl   %edx
pushl   $0  /* Pass NULL as regs pointer */
-   movl4*4(%esp), %eax
-   movl0x4(%ebp), %edx
+   movl5*4(%esp), %eax
+   /* Copy original ebp into %edx */
+   movl4*4(%esp), %edx
+   /* Get the parent ip */
+   movl0x4(%edx), %edx
movlfunction_trace_op, %ecx
subl$MCOUNT_INSN_SIZE, %eax
 
@@ -35,6 +42,7 @@ ftrace_call:
popl%edx
popl%ecx
popl%eax
+   popl%ebp
 .Lftrace_ret:
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 .globl ftrace_graph_call
-- 
2.10.2

[PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

[David Hildenbrand]

No caller currently checks the return value of
kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
freeing their device. A stale reference will remain in the io_bus,
getting at least used again, when the iobus gets teared down on
kvm_destroy_vm() - leading to use after free errors.

There is nothing the callers could do, except retrying over and over
again.

So let's simply remove the bus altogether, print an error and make
sure no one can access this broken bus again (returning -ENOMEM on any
attempt to access it).

Fixes: e93f8a0f821e ("KVM: convert io_bus to SRCU")
Cc: sta...@vger.kernel.org # 3.4+
Reported-by: Dmitry Vyukov 
Signed-off-by: David Hildenbrand 
---

Based on kvm/queue, where we just got 2a108a4e7c1 ("KVM: x86: clear bus
pointer when destroyed"), which added a check we need here.

---
 include/linux/kvm_host.h |  4 ++--
 virt/kvm/kvm_main.c  | 39 +++
 2 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 2c14ad9..d025074 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -162,8 +162,8 @@ int kvm_io_bus_read(struct kvm_vcpu *vcpu, enum kvm_bus 
bus_idx, gpa_t addr,
int len, void *val);
 int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus bus_idx, gpa_t addr,
int len, struct kvm_io_device *dev);
-int kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
- struct kvm_io_device *dev);
+void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
+  struct kvm_io_device *dev);
 struct kvm_io_device *kvm_io_bus_get_dev(struct kvm *kvm, enum kvm_bus bus_idx,
 gpa_t addr);
 
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 7445566..e1be4b4 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3476,6 +3476,8 @@ int kvm_io_bus_write(struct kvm_vcpu *vcpu, enum kvm_bus 
bus_idx, gpa_t addr,
};
 
bus = srcu_dereference(vcpu->kvm->buses[bus_idx], >kvm->srcu);
+   if (!bus)
+   return -ENOMEM;
r = __kvm_io_bus_write(vcpu, bus, , val);
return r < 0 ? r : 0;
 }
@@ -3493,6 +3495,8 @@ int kvm_io_bus_write_cookie(struct kvm_vcpu *vcpu, enum 
kvm_bus bus_idx,
};
 
bus = srcu_dereference(vcpu->kvm->buses[bus_idx], >kvm->srcu);
+   if (!bus)
+   return -ENOMEM;
 
/* First try the device referenced by cookie. */
if ((cookie >= 0) && (cookie < bus->dev_count) &&
@@ -3543,6 +3547,8 @@ int kvm_io_bus_read(struct kvm_vcpu *vcpu, enum kvm_bus 
bus_idx, gpa_t addr,
};
 
bus = srcu_dereference(vcpu->kvm->buses[bus_idx], >kvm->srcu);
+   if (!bus)
+   return -ENOMEM;
r = __kvm_io_bus_read(vcpu, bus, , val);
return r < 0 ? r : 0;
 }
@@ -3555,6 +3561,9 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus 
bus_idx, gpa_t addr,
struct kvm_io_bus *new_bus, *bus;
 
bus = kvm->buses[bus_idx];
+   if (!bus)
+   return -ENOMEM;
+
/* exclude ioeventfd which is limited by maximum fd */
if (bus->dev_count - bus->ioeventfd_count > NR_IOBUS_DEVS - 1)
return -ENOSPC;
@@ -3574,45 +3583,41 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum 
kvm_bus bus_idx, gpa_t addr,
 }
 
 /* Caller must hold slots_lock. */
-int kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
- struct kvm_io_device *dev)
+void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
+  struct kvm_io_device *dev)
 {
-   int i, r;
+   int i;
struct kvm_io_bus *new_bus, *bus;
 
bus = kvm->buses[bus_idx];
-
-   /*
-* It's possible the bus being released before hand. If so,
-* we're done here.
-*/
if (!bus)
-   return 0;
+   return;
 
-   r = -ENOENT;
for (i = 0; i < bus->dev_count; i++)
if (bus->range[i].dev == dev) {
-   r = 0;
break;
}
 
-   if (r)
-   return r;
+   if (i == bus->dev_count)
+   return;
 
new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count - 1) *
  sizeof(struct kvm_io_range)), GFP_KERNEL);
-   if (!new_bus)
-   return -ENOMEM;
+   if (!new_bus)  {
+   pr_err("kvm: failed to shrink bus, removing it completely\n");
+   goto broken;
+   }
 
memcpy(new_bus, bus, sizeof(*bus) + i * sizeof(struct kvm_io_range));
new_bus->dev_count--;
memcpy(new_bus->range + i, bus->range + i + 1,
   (new_bus->dev_count - i) * sizeof(struct kvm_io_range));
 
+broken:

[PATCH 4/6 v5] ftrace/x86_32: Clean up ftrace_regs_caller

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

When ftrace_regs_caller was created, it was designed to preserve flags as
much as possible as it needed to act just like a breakpoint triggered on the
same location. But the design is over complicated as it treated all
operations as modifying flags. But push, mov and lea do not modify flags.
This means the code can become more simplified by allowing flags to be
stored further down.

Making ftrace_regs_caller simpler will also be useful in implementing fentry
logic.

Link: http://lkml.kernel.org/r/20170316135328.36123...@gandalf.local.home
[ simpler logic to save flags ]
Suggested-by: Linus Torvalds 
Reviewed-by: Masami Hiramatsu 
Reviewed-by: Josh Poimboeuf 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/ftrace_32.S | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index a28f1907e1e1..63e28504debf 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -56,23 +56,27 @@ WEAK(ftrace_stub)
 END(ftrace_caller)
 
 ENTRY(ftrace_regs_caller)
-   pushf   /* push flags before compare (in cs location) */
-
/*
 * i386 does not save SS and ESP when coming from kernel.
 * Instead, to get sp, >sp is used (see ptrace.h).
 * Unfortunately, that means eflags must be at the same location
 * as the current return ip is. We move the return ip into the
-* ip location, and move flags into the return ip location.
+* regs->ip location, and move flags into the return ip location.
 */
-   pushl   4(%esp) /* save return ip into ip slot 
*/
-
+   pushl   $__KERNEL_CS
+   pushl   4(%esp) /* Save the return ip */
pushl   $0  /* Load 0 into orig_ax */
pushl   %gs
pushl   %fs
pushl   %es
pushl   %ds
pushl   %eax
+
+   /* Get flags and place them into the return ip slot */
+   pushf
+   popl%eax
+   movl%eax, 8*4(%esp)
+
pushl   %ebp
pushl   %edi
pushl   %esi
@@ -80,11 +84,6 @@ ENTRY(ftrace_regs_caller)
pushl   %ecx
pushl   %ebx
 
-   movl13*4(%esp), %eax/* Get the saved flags */
-   movl%eax, 14*4(%esp)/* Move saved flags into 
regs->flags location */
-   /* clobbering return ip */
-   movl$__KERNEL_CS, 13*4(%esp)
-
movl12*4(%esp), %eax/* Load ip (1st parameter) */
subl$MCOUNT_INSN_SIZE, %eax /* Adjust ip */
movl0x4(%ebp), %edx /* Load parent ip (2nd 
parameter) */
@@ -95,10 +94,14 @@ GLOBAL(ftrace_regs_call)
callftrace_stub
 
addl$4, %esp/* Skip pt_regs */
-   movl14*4(%esp), %eax/* Move flags back into cs */
-   movl%eax, 13*4(%esp)/* Needed to keep addl  from 
modifying flags */
-   movl12*4(%esp), %eax/* Get return ip from regs->ip 
*/
-   movl%eax, 14*4(%esp)/* Put return ip back for ret */
+
+   /* restore flags */
+   push14*4(%esp)
+   popf
+
+   /* Move return ip back to its original location */
+   movl12*4(%esp), %eax
+   movl%eax, 14*4(%esp)
 
popl%ebx
popl%ecx
@@ -111,12 +114,11 @@ GLOBAL(ftrace_regs_call)
popl%es
popl%fs
popl%gs
-   addl$8, %esp/* Skip orig_ax and ip */
-   popf/* Pop flags at end (no addl to 
corrupt flags) */
-   jmp .Lftrace_ret
 
-   popf
-   jmp ftrace_stub
+   /* use lea to not affect flags */
+   lea 3*4(%esp), %esp /* Skip orig_ax, ip and cs */
+
+   jmp .Lftrace_ret
 #else /* ! CONFIG_DYNAMIC_FTRACE */
 
 ENTRY(mcount)
-- 
2.10.2

[PATCH 3/6 v5] ftrace/x86_32: Add stack frame pointer to ftrace_caller

[Steven Rostedt]

From: "Steven Rostedt (VMware)" 

The function hook ftrace_caller does not create its own stack frame, and
this causes the ftrace stack trace to miss the first function when doing
stack traces.

 # echo schedule:stacktrace > /sys/kernel/tracing/set_ftrace_filter

Before:
 -0 [002] .N..29.865807: 
 => cpu_startup_entry
 => start_secondary
 => startup_32_smp
   <...>-7 [001] 29.866509: 
 => kthread
 => ret_from_fork
   <...>-1 [000] 29.865377: 
 => poll_schedule_timeout
 => do_select
 => core_sys_select
 => SyS_select
 => do_fast_syscall_32
 => entry_SYSENTER_32

After:
  -0 [002] .N..31.234853: 
 => do_idle
 => cpu_startup_entry
 => start_secondary
 => startup_32_smp
   <...>-7 [003] 31.235140: 
 => rcu_gp_kthread
 => kthread
 => ret_from_fork
   <...>-1819  [000] 31.264172: 
 => schedule_hrtimeout_range
 => poll_schedule_timeout
 => do_sys_poll
 => SyS_ppoll
 => do_fast_syscall_32
 => entry_SYSENTER_32

Reviewed-by: Josh Poimboeuf 
Reviewed-by: Masami Hiramatsu 
Signed-off-by: Steven Rostedt (VMware) 
---
 arch/x86/kernel/ftrace_32.S | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S
index f380604514e4..a28f1907e1e1 100644
--- a/arch/x86/kernel/ftrace_32.S
+++ b/arch/x86/kernel/ftrace_32.S
@@ -18,12 +18,19 @@ ENTRY(mcount)
 END(mcount)
 
 ENTRY(ftrace_caller)
+
+   pushl   %ebp
+   movl%esp, %ebp
+
pushl   %eax
pushl   %ecx
pushl   %edx
pushl   $0  /* Pass NULL as regs pointer */
-   movl4*4(%esp), %eax
-   movl0x4(%ebp), %edx
+   movl5*4(%esp), %eax
+   /* Copy original ebp into %edx */
+   movl4*4(%esp), %edx
+   /* Get the parent ip */
+   movl0x4(%edx), %edx
movlfunction_trace_op, %ecx
subl$MCOUNT_INSN_SIZE, %eax
 
@@ -35,6 +42,7 @@ ftrace_call:
popl%edx
popl%ecx
popl%eax
+   popl%ebp
 .Lftrace_ret:
 #ifdef CONFIG_FUNCTION_GRAPH_TRACER
 .globl ftrace_graph_call
-- 
2.10.2

[PATCH v1] KVM: kvm_io_bus_unregister_dev() should never fail

[David Hildenbrand]

No caller currently checks the return value of
kvm_io_bus_unregister_dev(). This is evil, as all callers silently go on
freeing their device. A stale reference will remain in the io_bus,
getting at least used again, when the iobus gets teared down on
kvm_destroy_vm() - leading to use after free errors.

There is nothing the callers could do, except retrying over and over
again.

So let's simply remove the bus altogether, print an error and make
sure no one can access this broken bus again (returning -ENOMEM on any
attempt to access it).

Fixes: e93f8a0f821e ("KVM: convert io_bus to SRCU")
Cc: sta...@vger.kernel.org # 3.4+
Reported-by: Dmitry Vyukov 
Signed-off-by: David Hildenbrand 
---

Based on kvm/queue, where we just got 2a108a4e7c1 ("KVM: x86: clear bus
pointer when destroyed"), which added a check we need here.

---
 include/linux/kvm_host.h |  4 ++--
 virt/kvm/kvm_main.c  | 39 +++
 2 files changed, 25 insertions(+), 18 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 2c14ad9..d025074 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -162,8 +162,8 @@ int kvm_io_bus_read(struct kvm_vcpu *vcpu, enum kvm_bus 
bus_idx, gpa_t addr,
int len, void *val);
 int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus bus_idx, gpa_t addr,
int len, struct kvm_io_device *dev);
-int kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
- struct kvm_io_device *dev);
+void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
+  struct kvm_io_device *dev);
 struct kvm_io_device *kvm_io_bus_get_dev(struct kvm *kvm, enum kvm_bus bus_idx,
 gpa_t addr);
 
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 7445566..e1be4b4 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -3476,6 +3476,8 @@ int kvm_io_bus_write(struct kvm_vcpu *vcpu, enum kvm_bus 
bus_idx, gpa_t addr,
};
 
bus = srcu_dereference(vcpu->kvm->buses[bus_idx], >kvm->srcu);
+   if (!bus)
+   return -ENOMEM;
r = __kvm_io_bus_write(vcpu, bus, , val);
return r < 0 ? r : 0;
 }
@@ -3493,6 +3495,8 @@ int kvm_io_bus_write_cookie(struct kvm_vcpu *vcpu, enum 
kvm_bus bus_idx,
};
 
bus = srcu_dereference(vcpu->kvm->buses[bus_idx], >kvm->srcu);
+   if (!bus)
+   return -ENOMEM;
 
/* First try the device referenced by cookie. */
if ((cookie >= 0) && (cookie < bus->dev_count) &&
@@ -3543,6 +3547,8 @@ int kvm_io_bus_read(struct kvm_vcpu *vcpu, enum kvm_bus 
bus_idx, gpa_t addr,
};
 
bus = srcu_dereference(vcpu->kvm->buses[bus_idx], >kvm->srcu);
+   if (!bus)
+   return -ENOMEM;
r = __kvm_io_bus_read(vcpu, bus, , val);
return r < 0 ? r : 0;
 }
@@ -3555,6 +3561,9 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum kvm_bus 
bus_idx, gpa_t addr,
struct kvm_io_bus *new_bus, *bus;
 
bus = kvm->buses[bus_idx];
+   if (!bus)
+   return -ENOMEM;
+
/* exclude ioeventfd which is limited by maximum fd */
if (bus->dev_count - bus->ioeventfd_count > NR_IOBUS_DEVS - 1)
return -ENOSPC;
@@ -3574,45 +3583,41 @@ int kvm_io_bus_register_dev(struct kvm *kvm, enum 
kvm_bus bus_idx, gpa_t addr,
 }
 
 /* Caller must hold slots_lock. */
-int kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
- struct kvm_io_device *dev)
+void kvm_io_bus_unregister_dev(struct kvm *kvm, enum kvm_bus bus_idx,
+  struct kvm_io_device *dev)
 {
-   int i, r;
+   int i;
struct kvm_io_bus *new_bus, *bus;
 
bus = kvm->buses[bus_idx];
-
-   /*
-* It's possible the bus being released before hand. If so,
-* we're done here.
-*/
if (!bus)
-   return 0;
+   return;
 
-   r = -ENOENT;
for (i = 0; i < bus->dev_count; i++)
if (bus->range[i].dev == dev) {
-   r = 0;
break;
}
 
-   if (r)
-   return r;
+   if (i == bus->dev_count)
+   return;
 
new_bus = kmalloc(sizeof(*bus) + ((bus->dev_count - 1) *
  sizeof(struct kvm_io_range)), GFP_KERNEL);
-   if (!new_bus)
-   return -ENOMEM;
+   if (!new_bus)  {
+   pr_err("kvm: failed to shrink bus, removing it completely\n");
+   goto broken;
+   }
 
memcpy(new_bus, bus, sizeof(*bus) + i * sizeof(struct kvm_io_range));
new_bus->dev_count--;
memcpy(new_bus->range + i, bus->range + i + 1,
   (new_bus->dev_count - i) * sizeof(struct kvm_io_range));
 
+broken:
rcu_assign_pointer(kvm->buses[bus_idx], new_bus);

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

[Alan Stern]

On Thu, 23 Mar 2017, Dmitry Vyukov wrote:

> Hello,
> 
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected
> kmalloc failure, most likely it's the root cause.

I find this bug report puzzling.  Maybe I don't understand it 
correctly -- it appears that the so-called use-after-free actually 
occurs _before_ the memory is deallocated!

> FAULT_INJECTION: forcing a failure.
Skipping this part.  Is it relevant?  It seems to refer to a different
memory buffer.

> ==
> BUG: KASAN: use-after-free in __list_add_valid+0xc6/0xd0
> lib/list_debug.c:26 at addr 88003c377a20
> Read of size 8 by task syz-executor7/3348
> CPU: 3 PID: 3348 Comm: syz-executor7 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:

Here are the revelant pieces of the stack traces.  Everything below
these parts is the same, and everything above them is unimportant.  
(And everything happened in the same process.)  The use-after-free
access occurred within this call:

>  usb_start_wait_urb+0x135/0x320 drivers/usb/core/message.c:56
>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]


Here's where the allocation call occurred:

> Allocated:
> PID = 3348
...
>  usb_internal_control_msg drivers/usb/core/message.c:93 [inline]


And here's where the buffer was deallocated:

> Freed:
> PID = 3348
...
>  usb_start_wait_urb+0x234/0x320 drivers/usb/core/message.c:78
>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]

Putting these together:

The memory was allocated in usb_internal_control_msg() line 93.
The later events occurred within the call in line 100 to
usb_start_wait_urb().

The invalid access occurred within usb_start_wait_urb() line 56.

The memory was deallocated within usb_start_wait_urb() line 78.

Since these routines don't involve any loops or backward jumps, this 
says that the invalid access occurred before the memory was 
deallocated!  So why is it reported as a problem?

Alan

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

[Alan Stern]

On Thu, 23 Mar 2017, Dmitry Vyukov wrote:

> Hello,
> 
> I've got the following report while running syzkaller fuzzer on
> 093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Not the preceding injected
> kmalloc failure, most likely it's the root cause.

I find this bug report puzzling.  Maybe I don't understand it 
correctly -- it appears that the so-called use-after-free actually 
occurs _before_ the memory is deallocated!

> FAULT_INJECTION: forcing a failure.
Skipping this part.  Is it relevant?  It seems to refer to a different
memory buffer.

> ==
> BUG: KASAN: use-after-free in __list_add_valid+0xc6/0xd0
> lib/list_debug.c:26 at addr 88003c377a20
> Read of size 8 by task syz-executor7/3348
> CPU: 3 PID: 3348 Comm: syz-executor7 Not tainted 4.11.0-rc3+ #364
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:

Here are the revelant pieces of the stack traces.  Everything below
these parts is the same, and everything above them is unimportant.  
(And everything happened in the same process.)  The use-after-free
access occurred within this call:

>  usb_start_wait_urb+0x135/0x320 drivers/usb/core/message.c:56
>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]


Here's where the allocation call occurred:

> Allocated:
> PID = 3348
...
>  usb_internal_control_msg drivers/usb/core/message.c:93 [inline]


And here's where the buffer was deallocated:

> Freed:
> PID = 3348
...
>  usb_start_wait_urb+0x234/0x320 drivers/usb/core/message.c:78
>  usb_internal_control_msg drivers/usb/core/message.c:100 [inline]

Putting these together:

The memory was allocated in usb_internal_control_msg() line 93.
The later events occurred within the call in line 100 to
usb_start_wait_urb().

The invalid access occurred within usb_start_wait_urb() line 56.

The memory was deallocated within usb_start_wait_urb() line 78.

Since these routines don't involve any loops or backward jumps, this 
says that the invalid access occurred before the memory was 
deallocated!  So why is it reported as a problem?

Alan

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

[James Morse]

Hi Punit,

On 01/02/17 21:38, Tyler Baicar wrote:
> From: "Jonathan (Zhixiong) Zhang" 
> 
> If ACPI_APEI and MEMORY_FAILURE is configured, select
> ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery
> when such memory failure is reported through ACPI APEI. APEI
> (ACPI Platform Error Interfaces) provides a means for the
> platform to convey error information to the kernel.
> 
> Declare ARCH_SUPPORTS_MEMORY_FAILURE, as arm64 does support
> memory failure recovery attempt.

Am I right in thinking we should wait for the hugepage issue you found with
hwpoison [0] to be fixed before arm64 can have ARCH_SUPPORTS_MEMORY_FAILURE?

(If so, can this patch become part of that series to they are obviously 
related!)

Thanks,

James

[0] https://www.spinics.net/lists/arm-kernel/msg568995.html




> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index f92778d..4cd12a0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -15,6 +15,8 @@ config ARM64
>   select ARCH_HAS_SG_CHAIN
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
>   select ARCH_USE_CMPXCHG_LOCKREF
> + select ACPI_APEI_MEMORY_FAILURE if ACPI_APEI && MEMORY_FAILURE
> + select ARCH_SUPPORTS_MEMORY_FAILURE
>   select ARCH_SUPPORTS_ATOMIC_RMW
>   select ARCH_SUPPORTS_NUMA_BALANCING
>   select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
> 

Re: [PATCH] arm64: kconfig: allow support for memory failure handling

[James Morse]

Hi Punit,

On 01/02/17 21:38, Tyler Baicar wrote:
> From: "Jonathan (Zhixiong) Zhang" 
> 
> If ACPI_APEI and MEMORY_FAILURE is configured, select
> ACPI_APEI_MEMORY_FAILURE. This enables memory failure recovery
> when such memory failure is reported through ACPI APEI. APEI
> (ACPI Platform Error Interfaces) provides a means for the
> platform to convey error information to the kernel.
> 
> Declare ARCH_SUPPORTS_MEMORY_FAILURE, as arm64 does support
> memory failure recovery attempt.

Am I right in thinking we should wait for the hugepage issue you found with
hwpoison [0] to be fixed before arm64 can have ARCH_SUPPORTS_MEMORY_FAILURE?

(If so, can this patch become part of that series to they are obviously 
related!)

Thanks,

James

[0] https://www.spinics.net/lists/arm-kernel/msg568995.html




> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index f92778d..4cd12a0 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -15,6 +15,8 @@ config ARM64
>   select ARCH_HAS_SG_CHAIN
>   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
>   select ARCH_USE_CMPXCHG_LOCKREF
> + select ACPI_APEI_MEMORY_FAILURE if ACPI_APEI && MEMORY_FAILURE
> + select ARCH_SUPPORTS_MEMORY_FAILURE
>   select ARCH_SUPPORTS_ATOMIC_RMW
>   select ARCH_SUPPORTS_NUMA_BALANCING
>   select ARCH_WANT_COMPAT_IPC_PARSE_VERSION
> 

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[Felix Fietkau]

On 2017-03-23 15:25, John Crispin wrote:
> 
> 
> On 23/03/17 15:09, Felix Fietkau wrote:
>> On 2017-03-23 09:06, Sean Wang wrote:
>>> Hi Andrew,
>>>
>>> The purpose for the regmap table registered is to
>>>
>>> provide a way which helps us to look up a specific
>>>
>>> register on the switch through regmap-debugfs.
>>>
>>>
>>> And not all ranges of register is defined
>>>
>>> so I only include the meaningful ones in a sparse way
>>>
>>> for the table.
>> I think in that case it might be nice to make regmap support optional in
>> order to avoid pulling in bloat on platforms that don't need it.
>>
>> - Felix
>>
> The 2 relevant platforms are mips/ralink and arm/mediatek. both require 
> regmap for the eth_sysctl syscon if they want to utilize the mtk_soc_eth 
> driver which is a prereq for mt7530. so regmap cannot be optional here.
Makes sense, thanks.

- Felix

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[Felix Fietkau]

On 2017-03-23 15:25, John Crispin wrote:
> 
> 
> On 23/03/17 15:09, Felix Fietkau wrote:
>> On 2017-03-23 09:06, Sean Wang wrote:
>>> Hi Andrew,
>>>
>>> The purpose for the regmap table registered is to
>>>
>>> provide a way which helps us to look up a specific
>>>
>>> register on the switch through regmap-debugfs.
>>>
>>>
>>> And not all ranges of register is defined
>>>
>>> so I only include the meaningful ones in a sparse way
>>>
>>> for the table.
>> I think in that case it might be nice to make regmap support optional in
>> order to avoid pulling in bloat on platforms that don't need it.
>>
>> - Felix
>>
> The 2 relevant platforms are mips/ralink and arm/mediatek. both require 
> regmap for the eth_sysctl syscon if they want to utilize the mtk_soc_eth 
> driver which is a prereq for mt7530. so regmap cannot be optional here.
Makes sense, thanks.

- Felix

[PATCH v2] Add initial SX3000b platform code to MIPS arch

[Amit Kama IL]

Add support for interrupt controller unit.
Use cpu_wait instead of endless loop in cpu_halt.
Make coding style changes and documentation additions to platform 
configuration options.

Signed-off-by: Amit Kama 

 arch/mips/Kconfig |   29 
 arch/mips/boot/dts/sx3000/Makefile|   13 
 arch/mips/boot/dts/sx3000/sx3000.dtsi |  141 +
 arch/mips/boot/dts/sx3000/sx3000_bbb.dts  |  110 
 arch/mips/boot/dts/sx3000/sx3000_devboard.dts |  175 +
 arch/mips/boot/dts/sx3000/sx3000_idu3.dts |  150 +
 arch/mips/boot/dts/sx3000/sx3000_idu4.dts |  134 +
 arch/mips/configs/sx3000b_defconfig   | 2365 ++
 arch/mips/include/asm/mach-sx3000/irq.h   |   18 
 arch/mips/include/asm/mach-sx3000/kernel-entry-init.h |   54 
 arch/mips/sx3000/Kconfig  |   18 
 arch/mips/sx3000/Makefile |1 
 arch/mips/sx3000/Platform |3 
 arch/mips/sx3000/init.c   |  123 
 arch/mips/sx3000/irq.c|   35 
 arch/mips/sx3000/sx3000-reset.c   |   54 
 arch/mips/sx3000/time.c   |   59 
 drivers/irqchip/irq-sx3000b.c |  303 ++
 18 files changed, 3785 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a008a9f..1bcb300
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -551,6 +551,31 @@ config MACH_PIC32
  Microchip PIC32 is a family of general-purpose 32 bit MIPS core
  microcontrollers.
 
+config MACH_SX3000
+   bool "Satixfy SX3000b based boards"
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_SUPPORTS_LITTLE_ENDIAN
+   select SYS_SUPPORTS_MIPS_CPS
+   select SYS_SUPPORTS_MULTITHREADING
+   select SYS_HAS_CPU_MIPS32_R2
+   select SYS_HAS_CPU_MIPS32_R3_5
+   select SYS_HAS_EARLY_PRINTK
+   select USE_GENERIC_EARLY_PRINTK_8250
+   select DMA_MAYBE_COHERENT
+   select ARCH_WANT_OPTIONAL_GPIOLIB
+   select LIBFDT
+   select USE_OF
+   select BUILTIN_DTB
+   select IRQ_MIPS_CPU
+   select MIPS_GIC
+   select SX3000_ICU
+   select MIPS_CPU_SCACHE
+   select CLKSRC_MIPS_GIC
+   select COMMON_CLK
+   select BOOT_RAW
+   help
+ This enables support for Satixfy's SX3000b SoC
+ platforms.
+ The properties herein are basic CPU subsystem
+ configurations only.
+
 config NEC_MARKEINS
bool "NEC EMMA2RH Mark-eins board"
select SOC_EMMA2RH
@@ -1022,6 +1047,7 @@ source "arch/mips/pmcs-msp71xx/Kconfig"
 source "arch/mips/ralink/Kconfig"
 source "arch/mips/sgi-ip27/Kconfig"
 source "arch/mips/sibyte/Kconfig"
+source "arch/mips/sx3000/Kconfig"
 source "arch/mips/txx9/Kconfig"
 source "arch/mips/vr41xx/Kconfig"
 source "arch/mips/cavium-octeon/Kconfig"
diff --git a/arch/mips/boot/dts/sx3000/Makefile 
b/arch/mips/boot/dts/sx3000/Makefile
index 000..8b73c39
+++ b/arch/mips/boot/dts/sx3000/Makefile
@@ -0,0 +1,13 @@
+dtb-$(CONFIG_SX3000_DEVBOARD)  += sx3000_devboard.dtb
+dtb-$(CONFIG_SX3000_BBB)   += sx3000_bbb.dtb
+dtb-$(SX3000_IDU3) += sx3000_idu3.dtb
+dtb-$(SX3000_IDU4) += sx3000_idu4.dtb
+
+
+obj-y  += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
+
+# Force kbuild to make empty built-in.o if necessary
+obj-   += dummy.o
+
+always := $(dtb-y)
+clean-files:= *.dtb *.dtb.S
diff --git a/arch/mips/boot/dts/sx3000/sx3000.dtsi 
b/arch/mips/boot/dts/sx3000/sx3000.dtsi
index 000..8557282
+++ b/arch/mips/boot/dts/sx3000/sx3000.dtsi
@@ -0,0 +1,141 @@
+/*
+ * Copyright (C) 2016 Satixfy Technologies
+ * Author: Amit Kama 
+ *
+ * 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 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "satixfy,sx3000";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "mti,interaptiv";
+   clocks  = <>;
+   reg = <0>;
+   };
+   };
+
+   gic: interrupt-controller@1d90 {
+   compatible = "mti,gic";
+   //reg = <0x1D90 0x2>;
+   memory-region = <_memory_mapped_area>;
+
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   timer {
+   compatible = "mti,gic-timer";
+   interrupts = ;
+   clocks = <>;
+   };
+   };
+

[PATCH v2] Add initial SX3000b platform code to MIPS arch

[Amit Kama IL]

Add support for interrupt controller unit.
Use cpu_wait instead of endless loop in cpu_halt.
Make coding style changes and documentation additions to platform 
configuration options.

Signed-off-by: Amit Kama 

 arch/mips/Kconfig |   29 
 arch/mips/boot/dts/sx3000/Makefile|   13 
 arch/mips/boot/dts/sx3000/sx3000.dtsi |  141 +
 arch/mips/boot/dts/sx3000/sx3000_bbb.dts  |  110 
 arch/mips/boot/dts/sx3000/sx3000_devboard.dts |  175 +
 arch/mips/boot/dts/sx3000/sx3000_idu3.dts |  150 +
 arch/mips/boot/dts/sx3000/sx3000_idu4.dts |  134 +
 arch/mips/configs/sx3000b_defconfig   | 2365 ++
 arch/mips/include/asm/mach-sx3000/irq.h   |   18 
 arch/mips/include/asm/mach-sx3000/kernel-entry-init.h |   54 
 arch/mips/sx3000/Kconfig  |   18 
 arch/mips/sx3000/Makefile |1 
 arch/mips/sx3000/Platform |3 
 arch/mips/sx3000/init.c   |  123 
 arch/mips/sx3000/irq.c|   35 
 arch/mips/sx3000/sx3000-reset.c   |   54 
 arch/mips/sx3000/time.c   |   59 
 drivers/irqchip/irq-sx3000b.c |  303 ++
 18 files changed, 3785 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index a008a9f..1bcb300
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -551,6 +551,31 @@ config MACH_PIC32
  Microchip PIC32 is a family of general-purpose 32 bit MIPS core
  microcontrollers.
 
+config MACH_SX3000
+   bool "Satixfy SX3000b based boards"
+   select SYS_SUPPORTS_32BIT_KERNEL
+   select SYS_SUPPORTS_LITTLE_ENDIAN
+   select SYS_SUPPORTS_MIPS_CPS
+   select SYS_SUPPORTS_MULTITHREADING
+   select SYS_HAS_CPU_MIPS32_R2
+   select SYS_HAS_CPU_MIPS32_R3_5
+   select SYS_HAS_EARLY_PRINTK
+   select USE_GENERIC_EARLY_PRINTK_8250
+   select DMA_MAYBE_COHERENT
+   select ARCH_WANT_OPTIONAL_GPIOLIB
+   select LIBFDT
+   select USE_OF
+   select BUILTIN_DTB
+   select IRQ_MIPS_CPU
+   select MIPS_GIC
+   select SX3000_ICU
+   select MIPS_CPU_SCACHE
+   select CLKSRC_MIPS_GIC
+   select COMMON_CLK
+   select BOOT_RAW
+   help
+ This enables support for Satixfy's SX3000b SoC
+ platforms.
+ The properties herein are basic CPU subsystem
+ configurations only.
+
 config NEC_MARKEINS
bool "NEC EMMA2RH Mark-eins board"
select SOC_EMMA2RH
@@ -1022,6 +1047,7 @@ source "arch/mips/pmcs-msp71xx/Kconfig"
 source "arch/mips/ralink/Kconfig"
 source "arch/mips/sgi-ip27/Kconfig"
 source "arch/mips/sibyte/Kconfig"
+source "arch/mips/sx3000/Kconfig"
 source "arch/mips/txx9/Kconfig"
 source "arch/mips/vr41xx/Kconfig"
 source "arch/mips/cavium-octeon/Kconfig"
diff --git a/arch/mips/boot/dts/sx3000/Makefile 
b/arch/mips/boot/dts/sx3000/Makefile
index 000..8b73c39
+++ b/arch/mips/boot/dts/sx3000/Makefile
@@ -0,0 +1,13 @@
+dtb-$(CONFIG_SX3000_DEVBOARD)  += sx3000_devboard.dtb
+dtb-$(CONFIG_SX3000_BBB)   += sx3000_bbb.dtb
+dtb-$(SX3000_IDU3) += sx3000_idu3.dtb
+dtb-$(SX3000_IDU4) += sx3000_idu4.dtb
+
+
+obj-y  += $(patsubst %.dtb, %.dtb.o, $(dtb-y))
+
+# Force kbuild to make empty built-in.o if necessary
+obj-   += dummy.o
+
+always := $(dtb-y)
+clean-files:= *.dtb *.dtb.S
diff --git a/arch/mips/boot/dts/sx3000/sx3000.dtsi 
b/arch/mips/boot/dts/sx3000/sx3000.dtsi
index 000..8557282
+++ b/arch/mips/boot/dts/sx3000/sx3000.dtsi
@@ -0,0 +1,141 @@
+/*
+ * Copyright (C) 2016 Satixfy Technologies
+ * Author: Amit Kama 
+ *
+ * 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 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "satixfy,sx3000";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "mti,interaptiv";
+   clocks  = <>;
+   reg = <0>;
+   };
+   };
+
+   gic: interrupt-controller@1d90 {
+   compatible = "mti,gic";
+   //reg = <0x1D90 0x2>;
+   memory-region = <_memory_mapped_area>;
+
+   interrupt-controller;
+   #interrupt-cells = <3>;
+   timer {
+   compatible = "mti,gic-timer";
+   interrupts = ;
+   clocks = <>;
+   };
+   };
+
+   icu: interrupt-controller@1d4d {
+ 

Re: [PATCHv3 1/2] mfd: cpcap: implement irq sense helper

[Lee Jones]

On Tue, 21 Mar 2017, Sebastian Reichel wrote:

> CPCAP can sense if IRQ is currently set or not. This
> functionality is required for a few subdevices, such
> as the power button and usb phy modules.
> 
> Acked-by: Tony Lindgren 
> Signed-off-by: Sebastian Reichel 
> ---
> Changes since PATCHv2:
>  - Collect Acked-by/Tested-by
>  - Fix typo in EXPORT_SYMBOL_GPL
> ---
>  drivers/mfd/motorola-cpcap.c   | 25 +
>  include/linux/mfd/motorola-cpcap.h |  2 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> index 6aeada7d7ce5..a1e364b42e47 100644
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
> @@ -32,6 +32,31 @@ struct cpcap_ddata {
>   struct regmap *regmap;
>  };
>  
> +static int cpcap_sense_irq(struct regmap *regmap, int irq)
> +{
> + int reg = CPCAP_REG_INTS1 + (irq / 16) * 4;
> + int mask = 1 << (irq % 16);

Can you place all this bit-wise hoop jumping in macros please?

Also please use the BIT() macro.

> + int err, val;
> +
> + if (irq < 0 || irq > 64)
> + return -EINVAL;

What's wrong with IRQ 65?

I'm *guessing* there isn't one.

You can make this clearer by defining CPCAP_SENSE_IRQ_MAX.

> + err = regmap_read(regmap, reg, );
> + if (err)
> + return err;
> +
> + return !!(val & mask);
> +}
> +
> +int cpcap_sense_virq(struct regmap *regmap, int virq)
> +{
> + struct regmap_irq_chip_data *d = irq_get_chip_data(virq);
> + int base = regmap_irq_chip_get_base(d);
> +
> + return cpcap_sense_irq(regmap, virq - base);
> +}
> +EXPORT_SYMBOL_GPL(cpcap_sense_virq);
> +
>  static int cpcap_check_revision(struct cpcap_ddata *cpcap)
>  {
>   u16 vendor, rev;
> diff --git a/include/linux/mfd/motorola-cpcap.h 
> b/include/linux/mfd/motorola-cpcap.h
> index b4031c2b2214..7629e0d24d26 100644
> --- a/include/linux/mfd/motorola-cpcap.h
> +++ b/include/linux/mfd/motorola-cpcap.h
> @@ -290,3 +290,5 @@ static inline int cpcap_get_vendor(struct device *dev,
>  
>   return 0;
>  }
> +
> +int cpcap_sense_virq(struct regmap *regmap, int virq);

extern?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCHv3 1/2] mfd: cpcap: implement irq sense helper

[Lee Jones]

On Tue, 21 Mar 2017, Sebastian Reichel wrote:

> CPCAP can sense if IRQ is currently set or not. This
> functionality is required for a few subdevices, such
> as the power button and usb phy modules.
> 
> Acked-by: Tony Lindgren 
> Signed-off-by: Sebastian Reichel 
> ---
> Changes since PATCHv2:
>  - Collect Acked-by/Tested-by
>  - Fix typo in EXPORT_SYMBOL_GPL
> ---
>  drivers/mfd/motorola-cpcap.c   | 25 +
>  include/linux/mfd/motorola-cpcap.h |  2 ++
>  2 files changed, 27 insertions(+)
> 
> diff --git a/drivers/mfd/motorola-cpcap.c b/drivers/mfd/motorola-cpcap.c
> index 6aeada7d7ce5..a1e364b42e47 100644
> --- a/drivers/mfd/motorola-cpcap.c
> +++ b/drivers/mfd/motorola-cpcap.c
> @@ -32,6 +32,31 @@ struct cpcap_ddata {
>   struct regmap *regmap;
>  };
>  
> +static int cpcap_sense_irq(struct regmap *regmap, int irq)
> +{
> + int reg = CPCAP_REG_INTS1 + (irq / 16) * 4;
> + int mask = 1 << (irq % 16);

Can you place all this bit-wise hoop jumping in macros please?

Also please use the BIT() macro.

> + int err, val;
> +
> + if (irq < 0 || irq > 64)
> + return -EINVAL;

What's wrong with IRQ 65?

I'm *guessing* there isn't one.

You can make this clearer by defining CPCAP_SENSE_IRQ_MAX.

> + err = regmap_read(regmap, reg, );
> + if (err)
> + return err;
> +
> + return !!(val & mask);
> +}
> +
> +int cpcap_sense_virq(struct regmap *regmap, int virq)
> +{
> + struct regmap_irq_chip_data *d = irq_get_chip_data(virq);
> + int base = regmap_irq_chip_get_base(d);
> +
> + return cpcap_sense_irq(regmap, virq - base);
> +}
> +EXPORT_SYMBOL_GPL(cpcap_sense_virq);
> +
>  static int cpcap_check_revision(struct cpcap_ddata *cpcap)
>  {
>   u16 vendor, rev;
> diff --git a/include/linux/mfd/motorola-cpcap.h 
> b/include/linux/mfd/motorola-cpcap.h
> index b4031c2b2214..7629e0d24d26 100644
> --- a/include/linux/mfd/motorola-cpcap.h
> +++ b/include/linux/mfd/motorola-cpcap.h
> @@ -290,3 +290,5 @@ static inline int cpcap_get_vendor(struct device *dev,
>  
>   return 0;
>  }
> +
> +int cpcap_sense_virq(struct regmap *regmap, int virq);

extern?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Sagalovitch, Serguei]

Christian,

- Are we going to support resizing BAR when kernel 
modesetting  is not enabled and we are running in console 
under VBIOS control (VESA/VGA)? 

- Should we restore PCI configuration if amdgpu
will be unloaded?

- In function amdgpu_resize_bar0():
  If resizing for "max" size failed should we try other 
sizes? What do you think?


Sincerely yours,
Serguei Sagalovitch


From: amd-gfx  on behalf of Zhang, Jerry 

Sent: March 15, 2017 10:41 PM
To: Alex Deucher
Cc: Zhou, David(ChunMing); Ayyappa Ch; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org; 
platform-driver-...@vger.kernel.org; Christian König; helg...@kernel.org; 
amd-...@lists.freedesktop.org
Subject: RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
    
Thanks for your info.
I see.

Regards,
Jerry (Junwei Zhang)

Linux Base Graphics
SRDC Software Development
_


> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Thursday, March 16, 2017 10:25
> To: Zhang, Jerry
> Cc: Christian König; Zhou, David(ChunMing); Ayyappa Ch; linux-
> p...@vger.kernel.org; linux-kernel@vger.kernel.org; dri-
> de...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> helg...@kernel.org; amd-...@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> 
> On Wed, Mar 15, 2017 at 10:19 PM, Zhang, Jerry  wrote:
> >> -Original Message-
> >> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> Behalf Of Christian K?nig
> >> Sent: Wednesday, March 15, 2017 17:29
> >> To: Zhou, David(ChunMing); Ayyappa Ch
> >> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; amd-
> >> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> >> helg...@kernel.org; dri-de...@lists.freedesktop.org
> >> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >>
> >> Yes, exactly that.
> >
> > (I'm not familiar with PCI too much.)
> > Is there any restrict for PCI device?
> > I'm concerning if any PCI couldn't support it on some motherboard.
> 
> It depends on the PCI root bridge.  This patch set only implements support for
> AMD root bridges.  Intel and other vendors would need similar code.
> 
> Alex
> 
> >
> >>
> >> Christian.
> >>
> >> Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
> >> > Does that means we don't need invisible vram later?
> >> >
> >> > David
> >> >
> >> > -Original Message-
> >> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> > Behalf Of Christian K?nig
> >> > Sent: Wednesday, March 15, 2017 3:38 PM
> >> > To: Ayyappa Ch 
> >> > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> > amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> >> > helg...@kernel.org; dri-de...@lists.freedesktop.org
> >> > Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >> >
> >> > Carizzo is an APU and resizing BARs isn't needed nor supported there.
> >> > The CPU can access the full stolen VRAM directly on that hardware.
> >> >
> >> > As far as I know ASICs with support for this are Tonga, Fiji and all 
> >> > Polaris
> variants.
> >> >
> >> > Christian.
> >> >
> >> > Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> >> >> Is it possible on Carrizo asics? Or only supports on newer asics?
> >> >>
> >> >> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> >> >>  wrote:
> >> >>> From: Christian König 
> >> >>>
> >> >>> Try to resize BAR0 to let CPU access all of VRAM.
> >> >>>
> >> >>> Signed-off-by: Christian König 
> >> >>> ---
> >> >>>    drivers/gpu/drm/amd/amdgpu/amdgpu.h    |  1 +
> >> >>>    drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
> >> +
> >> >>>    drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
> >> >>>    drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
> >> >>>    4 files changed, 40 insertions(+), 6 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> index 3b81ded..905ded9 100644
> >> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> >> amdgpu_device *adev, struct ttm_tt *ttm,
> >> >>>    struct ttm_mem_reg *mem);
> >> >>>    void amdgpu_vram_location(struct amdgpu_device *adev, struct
> >> amdgpu_mc *mc, u64 base);
> >> >>>    void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> >> >>> amdgpu_mc *mc);
> >> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> >> >>>    void amdgpu_ttm_set_active_vram_size(struct amdgpu_device
> >> >>> *adev,
> >> u64 size);
> >> >>>    int 

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

[Sagalovitch, Serguei]

Christian,

- Are we going to support resizing BAR when kernel 
modesetting  is not enabled and we are running in console 
under VBIOS control (VESA/VGA)? 

- Should we restore PCI configuration if amdgpu
will be unloaded?

- In function amdgpu_resize_bar0():
  If resizing for "max" size failed should we try other 
sizes? What do you think?


Sincerely yours,
Serguei Sagalovitch


From: amd-gfx  on behalf of Zhang, Jerry 

Sent: March 15, 2017 10:41 PM
To: Alex Deucher
Cc: Zhou, David(ChunMing); Ayyappa Ch; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org; 
platform-driver-...@vger.kernel.org; Christian König; helg...@kernel.org; 
amd-...@lists.freedesktop.org
Subject: RE: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
    
Thanks for your info.
I see.

Regards,
Jerry (Junwei Zhang)

Linux Base Graphics
SRDC Software Development
_


> -Original Message-
> From: Alex Deucher [mailto:alexdeuc...@gmail.com]
> Sent: Thursday, March 16, 2017 10:25
> To: Zhang, Jerry
> Cc: Christian König; Zhou, David(ChunMing); Ayyappa Ch; linux-
> p...@vger.kernel.org; linux-kernel@vger.kernel.org; dri-
> de...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> helg...@kernel.org; amd-...@lists.freedesktop.org
> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> 
> On Wed, Mar 15, 2017 at 10:19 PM, Zhang, Jerry  wrote:
> >> -Original Message-
> >> From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> Behalf Of Christian K?nig
> >> Sent: Wednesday, March 15, 2017 17:29
> >> To: Zhou, David(ChunMing); Ayyappa Ch
> >> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; amd-
> >> g...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> >> helg...@kernel.org; dri-de...@lists.freedesktop.org
> >> Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >>
> >> Yes, exactly that.
> >
> > (I'm not familiar with PCI too much.)
> > Is there any restrict for PCI device?
> > I'm concerning if any PCI couldn't support it on some motherboard.
> 
> It depends on the PCI root bridge.  This patch set only implements support for
> AMD root bridges.  Intel and other vendors would need similar code.
> 
> Alex
> 
> >
> >>
> >> Christian.
> >>
> >> Am 15.03.2017 um 09:25 schrieb Zhou, David(ChunMing):
> >> > Does that means we don't need invisible vram later?
> >> >
> >> > David
> >> >
> >> > -Original Message-
> >> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> >> > Behalf Of Christian K?nig
> >> > Sent: Wednesday, March 15, 2017 3:38 PM
> >> > To: Ayyappa Ch 
> >> > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> > amd-...@lists.freedesktop.org; platform-driver-...@vger.kernel.org;
> >> > helg...@kernel.org; dri-de...@lists.freedesktop.org
> >> > Subject: Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access
> >> >
> >> > Carizzo is an APU and resizing BARs isn't needed nor supported there.
> >> > The CPU can access the full stolen VRAM directly on that hardware.
> >> >
> >> > As far as I know ASICs with support for this are Tonga, Fiji and all 
> >> > Polaris
> variants.
> >> >
> >> > Christian.
> >> >
> >> > Am 15.03.2017 um 08:23 schrieb Ayyappa Ch:
> >> >> Is it possible on Carrizo asics? Or only supports on newer asics?
> >> >>
> >> >> On Mon, Mar 13, 2017 at 6:11 PM, Christian König
> >> >>  wrote:
> >> >>> From: Christian König 
> >> >>>
> >> >>> Try to resize BAR0 to let CPU access all of VRAM.
> >> >>>
> >> >>> Signed-off-by: Christian König 
> >> >>> ---
> >> >>>    drivers/gpu/drm/amd/amdgpu/amdgpu.h    |  1 +
> >> >>>    drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29
> >> +
> >> >>>    drivers/gpu/drm/amd/amdgpu/gmc_v7_0.c  |  8 +---
> >> >>>    drivers/gpu/drm/amd/amdgpu/gmc_v8_0.c  |  8 +---
> >> >>>    4 files changed, 40 insertions(+), 6 deletions(-)
> >> >>>
> >> >>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> index 3b81ded..905ded9 100644
> >> >>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
> >> >>> @@ -1719,6 +1719,7 @@ uint64_t amdgpu_ttm_tt_pte_flags(struct
> >> amdgpu_device *adev, struct ttm_tt *ttm,
> >> >>>    struct ttm_mem_reg *mem);
> >> >>>    void amdgpu_vram_location(struct amdgpu_device *adev, struct
> >> amdgpu_mc *mc, u64 base);
> >> >>>    void amdgpu_gtt_location(struct amdgpu_device *adev, struct
> >> >>> amdgpu_mc *mc);
> >> >>> +void amdgpu_resize_bar0(struct amdgpu_device *adev);
> >> >>>    void amdgpu_ttm_set_active_vram_size(struct amdgpu_device
> >> >>> *adev,
> >> u64 size);
> >> >>>    int amdgpu_ttm_init(struct amdgpu_device *adev);
> >> >>>    void amdgpu_ttm_fini(struct amdgpu_device *adev); diff --git
> >> >>> a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> >> >>> 

[PATCH 18/17] x86: Use generic pci_mmap_resource_range()

[David Woodhouse]

From: David Woodhouse 

Signed-off-by: David Woodhouse 
---
Actually it turns out this is fairly trivial for x86 too; it just looked
more interesting at first glance. But pgprot_writecombine() and
pgprot_device() will both do the right thing here, and allowing WC
conditionally based on pat_enabled() is already working so we'll never
get asked to do that when we don't want to.

 arch/x86/include/asm/pci.h |  1 +
 arch/x86/pci/i386.c| 48 --
 2 files changed, 1 insertion(+), 48 deletions(-)

diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 734cc94..f513cc2 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -104,6 +104,7 @@ int pcibios_set_irq_routing(struct pci_dev *dev, int pin, 
int irq);
 
 #define HAVE_PCI_MMAP
 #define arch_can_pci_mmap_wc() pat_enabled()
+#define ARCH_GENERIC_PCI_MMAP_RESOURCE
 
 #ifdef CONFIG_PCI
 extern void early_quirks(void);
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 8ca5e5d..68499cf 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -406,51 +406,3 @@ void __init pcibios_resource_survey(void)
 */
ioapic_insert_resources();
 }
-
-static const struct vm_operations_struct pci_mmap_ops = {
-   .access = generic_access_phys,
-};
-
-int pci_mmap_page_range(struct pci_dev *dev, int bar,
-   struct vm_area_struct *vma,
-   enum pci_mmap_state mmap_state, int write_combine)
-{
-   unsigned long prot;
-
-   /* I/O space cannot be accessed via normal processor loads and
-* stores on this platform.
-*/
-   if (mmap_state == pci_mmap_io)
-   return -EINVAL;
-
-   prot = pgprot_val(vma->vm_page_prot);
-
-   /*
-* Return error if pat is not enabled and write_combine is requested.
-* Caller can followup with UC MINUS request and add a WC mtrr if there
-* is a free mtrr slot.
-*/
-   if (!pat_enabled() && write_combine)
-   return -EINVAL;
-
-   if (pat_enabled() && write_combine)
-   prot |= cachemode2protval(_PAGE_CACHE_MODE_WC);
-   else if (pat_enabled() || boot_cpu_data.x86 > 3)
-   /*
-* ioremap() and ioremap_nocache() defaults to UC MINUS for now.
-* To avoid attribute conflicts, request UC MINUS here
-* as well.
-*/
-   prot |= cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS);
-
-   vma->vm_page_prot = __pgprot(prot);
-
-   if (io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
-  vma->vm_end - vma->vm_start,
-  vma->vm_page_prot))
-   return -EAGAIN;
-
-   vma->vm_ops = _mmap_ops;
-
-   return 0;
-}
-- 
2.9.3

[PATCH 18/17] x86: Use generic pci_mmap_resource_range()

[David Woodhouse]

From: David Woodhouse 

Signed-off-by: David Woodhouse 
---
Actually it turns out this is fairly trivial for x86 too; it just looked
more interesting at first glance. But pgprot_writecombine() and
pgprot_device() will both do the right thing here, and allowing WC
conditionally based on pat_enabled() is already working so we'll never
get asked to do that when we don't want to.

 arch/x86/include/asm/pci.h |  1 +
 arch/x86/pci/i386.c| 48 --
 2 files changed, 1 insertion(+), 48 deletions(-)

diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 734cc94..f513cc2 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -104,6 +104,7 @@ int pcibios_set_irq_routing(struct pci_dev *dev, int pin, 
int irq);
 
 #define HAVE_PCI_MMAP
 #define arch_can_pci_mmap_wc() pat_enabled()
+#define ARCH_GENERIC_PCI_MMAP_RESOURCE
 
 #ifdef CONFIG_PCI
 extern void early_quirks(void);
diff --git a/arch/x86/pci/i386.c b/arch/x86/pci/i386.c
index 8ca5e5d..68499cf 100644
--- a/arch/x86/pci/i386.c
+++ b/arch/x86/pci/i386.c
@@ -406,51 +406,3 @@ void __init pcibios_resource_survey(void)
 */
ioapic_insert_resources();
 }
-
-static const struct vm_operations_struct pci_mmap_ops = {
-   .access = generic_access_phys,
-};
-
-int pci_mmap_page_range(struct pci_dev *dev, int bar,
-   struct vm_area_struct *vma,
-   enum pci_mmap_state mmap_state, int write_combine)
-{
-   unsigned long prot;
-
-   /* I/O space cannot be accessed via normal processor loads and
-* stores on this platform.
-*/
-   if (mmap_state == pci_mmap_io)
-   return -EINVAL;
-
-   prot = pgprot_val(vma->vm_page_prot);
-
-   /*
-* Return error if pat is not enabled and write_combine is requested.
-* Caller can followup with UC MINUS request and add a WC mtrr if there
-* is a free mtrr slot.
-*/
-   if (!pat_enabled() && write_combine)
-   return -EINVAL;
-
-   if (pat_enabled() && write_combine)
-   prot |= cachemode2protval(_PAGE_CACHE_MODE_WC);
-   else if (pat_enabled() || boot_cpu_data.x86 > 3)
-   /*
-* ioremap() and ioremap_nocache() defaults to UC MINUS for now.
-* To avoid attribute conflicts, request UC MINUS here
-* as well.
-*/
-   prot |= cachemode2protval(_PAGE_CACHE_MODE_UC_MINUS);
-
-   vma->vm_page_prot = __pgprot(prot);
-
-   if (io_remap_pfn_range(vma, vma->vm_start, vma->vm_pgoff,
-  vma->vm_end - vma->vm_start,
-  vma->vm_page_prot))
-   return -EAGAIN;
-
-   vma->vm_ops = _mmap_ops;
-
-   return 0;
-}
-- 
2.9.3

Re: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver

[Dong Aisheng]

On Tue, Mar 21, 2017 at 07:50:04AM -0700, Andrey Smirnov wrote:
> Add code allowing for control of various power domains managed by GPCv2
> IP block found in i.MX7 series of SoCs. Power domains covered by this
> patch are:
> 
> - PCIE PHY
> - MIPI PHY
> - USB HSIC PHY
> - USB OTG1/2 PHY
> 

You probably may need drop USB OTG which is not claimed in current RM.
See the PGC definition in 5.5.10 GPC Memory Map section.

Each PGC (CPU type, MIX type, PU type) will occupy 64 Bytes address space,
the specific base address of each PGC are listed as below.
• 0x800 ~ 0x83F : PGC for A7 core0
• 0x840 ~ 0x87F: PGC for A7 core1
• 0x880 ~ 0x8BF: PGC for A7 SCU
• 0xA00 ~ 0xA3F: PGC for fastmix/megamix
• 0xC00 ~ 0xC3F: PGC for MIPI PHY
• 0xC40 ~ 0xC7F: PGC for PCIE_PHY
• 0xC80 ~ 0xCBF: Reserved
• 0xCC0 ~ 0xCFF: Reserved
• 0xD00 ~ 0xD3F: PGC for USB HSIC PHY

And in 5.4 Power Management Unit (PMU) chapter,
you will find the USB OTG phy power is directly supplied by
VDD_USB_OTG1_3P3_IN/VDD_USB_OTG2_3P3_IN.

http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX7DRM.pdf

I understand that there's also some USB OTG code exist in NXP internal
tree, but that's legacy for early doc implementation and may be deprecated.
so i assume it should be gone.

Hopefully i will double confirm with our IC designer tomorrow.

> Support for any other power domain controlled by GPC is not present, and
> can be added at some later point.
> 
> Testing of this code was done against a PCIe driver.
> 
> Cc: yurov...@gmail.com
> Cc: Lucas Stach 
> Cc: Fabio Estevam 
> Cc: Dong Aisheng 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>  drivers/soc/Kconfig  |   1 +
>  drivers/soc/imx/Kconfig  |  10 ++
>  drivers/soc/imx/Makefile |   1 +
>  drivers/soc/imx/gpcv2.c  | 365 
> +++
>  4 files changed, 377 insertions(+)
>  create mode 100644 drivers/soc/imx/Kconfig
>  create mode 100644 drivers/soc/imx/gpcv2.c
> 
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index f09023f..8943543 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>  
>  source "drivers/soc/bcm/Kconfig"
>  source "drivers/soc/fsl/Kconfig"
> +source "drivers/soc/imx/Kconfig"
>  source "drivers/soc/mediatek/Kconfig"
>  source "drivers/soc/qcom/Kconfig"
>  source "drivers/soc/rockchip/Kconfig"
> diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
> new file mode 100644
> index 000..bc7f0ee0
> --- /dev/null
> +++ b/drivers/soc/imx/Kconfig
> @@ -0,0 +1,10 @@
> +menu "i.MX SoC drivers"
> +
> +config IMX7_PM_DOMAINS
> + bool "i.MX7 PM domains"
> + select PM_GENERIC_DOMAINS
> + depends on SOC_IMX7D || (COMPILE_TEST && OF)
> + default y if SOC_IMX7D
> +
> +endmenu
> +
> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
> index 35861f5..5b6e396 100644
> --- a/drivers/soc/imx/Makefile
> +++ b/drivers/soc/imx/Makefile
> @@ -1 +1,2 @@
>  obj-y += gpc.o
> +obj-$(CONFIG_IMX7_PM_DOMAINS) += gpcv2.o
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> new file mode 100644
> index 000..a27c5f8
> --- /dev/null
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -0,0 +1,365 @@
> +/*
> + * Copyright 2017 Impinj, Inc
> + * Author: Andrey Smirnov 
> + *
> + * Based on the code of analogus driver:
> + *
> + * Copyright 2015-2017 Pengutronix, Lucas Stach 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GPC_PGC_CPU_MAPPING  0xec
> +#define USB_HSIC_PHY_A7_DOMAIN   BIT(6)
> +#define USB_OTG2_PHY_A7_DOMAIN   BIT(5)
> +#define USB_OTG1_PHY_A7_DOMAIN   BIT(4)
> +#define PCIE_PHY_A7_DOMAIN   BIT(3)
> +#define MIPI_PHY_A7_DOMAIN   BIT(2)
> +
> +#define GPC_PU_PGC_SW_PUP_REQ0xf8
> +#define GPC_PU_PGC_SW_PDN_REQ0x104
> +#define USB_HSIC_PHY_SW_Pxx_REQ  BIT(4)
> +#define USB_OTG2_PHY_SW_Pxx_REQ  BIT(3)
> +#define USB_OTG1_PHY_SW_Pxx_REQ  BIT(2)
> +#define PCIE_PHY_SW_Pxx_REQ  BIT(1)
> +#define MIPI_PHY_SW_Pxx_REQ  BIT(0)
> +

After apply, what i see is:
#define GPC_PU_PGC_SW_PUP_REQ   0xf8
#define GPC_PU_PGC_SW_PDN_REQ   0x104
#define USB_HSIC_PHY_SW_Pxx_REQ BIT(4)
#define USB_OTG2_PHY_SW_Pxx_REQ BIT(3)
#define USB_OTG1_PHY_SW_Pxx_REQ BIT(2)
#define PCIE_PHY_SW_Pxx_REQ BIT(1)
#define MIPI_PHY_SW_Pxx_REQ BIT(0)

Looks quite tight,
Can we have one more TAB for the definition?
Like:
#define GPC_PU_PGC_SW_PUP_REQ  

Re: [PATCH v7 2/2] soc/imx: Add GPCv2 power gating driver

[Dong Aisheng]

On Tue, Mar 21, 2017 at 07:50:04AM -0700, Andrey Smirnov wrote:
> Add code allowing for control of various power domains managed by GPCv2
> IP block found in i.MX7 series of SoCs. Power domains covered by this
> patch are:
> 
> - PCIE PHY
> - MIPI PHY
> - USB HSIC PHY
> - USB OTG1/2 PHY
> 

You probably may need drop USB OTG which is not claimed in current RM.
See the PGC definition in 5.5.10 GPC Memory Map section.

Each PGC (CPU type, MIX type, PU type) will occupy 64 Bytes address space,
the specific base address of each PGC are listed as below.
• 0x800 ~ 0x83F : PGC for A7 core0
• 0x840 ~ 0x87F: PGC for A7 core1
• 0x880 ~ 0x8BF: PGC for A7 SCU
• 0xA00 ~ 0xA3F: PGC for fastmix/megamix
• 0xC00 ~ 0xC3F: PGC for MIPI PHY
• 0xC40 ~ 0xC7F: PGC for PCIE_PHY
• 0xC80 ~ 0xCBF: Reserved
• 0xCC0 ~ 0xCFF: Reserved
• 0xD00 ~ 0xD3F: PGC for USB HSIC PHY

And in 5.4 Power Management Unit (PMU) chapter,
you will find the USB OTG phy power is directly supplied by
VDD_USB_OTG1_3P3_IN/VDD_USB_OTG2_3P3_IN.

http://www.nxp.com/assets/documents/data/en/reference-manuals/IMX7DRM.pdf

I understand that there's also some USB OTG code exist in NXP internal
tree, but that's legacy for early doc implementation and may be deprecated.
so i assume it should be gone.

Hopefully i will double confirm with our IC designer tomorrow.

> Support for any other power domain controlled by GPC is not present, and
> can be added at some later point.
> 
> Testing of this code was done against a PCIe driver.
> 
> Cc: yurov...@gmail.com
> Cc: Lucas Stach 
> Cc: Fabio Estevam 
> Cc: Dong Aisheng 
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Andrey Smirnov 
> ---
>  drivers/soc/Kconfig  |   1 +
>  drivers/soc/imx/Kconfig  |  10 ++
>  drivers/soc/imx/Makefile |   1 +
>  drivers/soc/imx/gpcv2.c  | 365 
> +++
>  4 files changed, 377 insertions(+)
>  create mode 100644 drivers/soc/imx/Kconfig
>  create mode 100644 drivers/soc/imx/gpcv2.c
> 
> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
> index f09023f..8943543 100644
> --- a/drivers/soc/Kconfig
> +++ b/drivers/soc/Kconfig
> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>  
>  source "drivers/soc/bcm/Kconfig"
>  source "drivers/soc/fsl/Kconfig"
> +source "drivers/soc/imx/Kconfig"
>  source "drivers/soc/mediatek/Kconfig"
>  source "drivers/soc/qcom/Kconfig"
>  source "drivers/soc/rockchip/Kconfig"
> diff --git a/drivers/soc/imx/Kconfig b/drivers/soc/imx/Kconfig
> new file mode 100644
> index 000..bc7f0ee0
> --- /dev/null
> +++ b/drivers/soc/imx/Kconfig
> @@ -0,0 +1,10 @@
> +menu "i.MX SoC drivers"
> +
> +config IMX7_PM_DOMAINS
> + bool "i.MX7 PM domains"
> + select PM_GENERIC_DOMAINS
> + depends on SOC_IMX7D || (COMPILE_TEST && OF)
> + default y if SOC_IMX7D
> +
> +endmenu
> +
> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
> index 35861f5..5b6e396 100644
> --- a/drivers/soc/imx/Makefile
> +++ b/drivers/soc/imx/Makefile
> @@ -1 +1,2 @@
>  obj-y += gpc.o
> +obj-$(CONFIG_IMX7_PM_DOMAINS) += gpcv2.o
> diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c
> new file mode 100644
> index 000..a27c5f8
> --- /dev/null
> +++ b/drivers/soc/imx/gpcv2.c
> @@ -0,0 +1,365 @@
> +/*
> + * Copyright 2017 Impinj, Inc
> + * Author: Andrey Smirnov 
> + *
> + * Based on the code of analogus driver:
> + *
> + * Copyright 2015-2017 Pengutronix, Lucas Stach 
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define GPC_PGC_CPU_MAPPING  0xec
> +#define USB_HSIC_PHY_A7_DOMAIN   BIT(6)
> +#define USB_OTG2_PHY_A7_DOMAIN   BIT(5)
> +#define USB_OTG1_PHY_A7_DOMAIN   BIT(4)
> +#define PCIE_PHY_A7_DOMAIN   BIT(3)
> +#define MIPI_PHY_A7_DOMAIN   BIT(2)
> +
> +#define GPC_PU_PGC_SW_PUP_REQ0xf8
> +#define GPC_PU_PGC_SW_PDN_REQ0x104
> +#define USB_HSIC_PHY_SW_Pxx_REQ  BIT(4)
> +#define USB_OTG2_PHY_SW_Pxx_REQ  BIT(3)
> +#define USB_OTG1_PHY_SW_Pxx_REQ  BIT(2)
> +#define PCIE_PHY_SW_Pxx_REQ  BIT(1)
> +#define MIPI_PHY_SW_Pxx_REQ  BIT(0)
> +

After apply, what i see is:
#define GPC_PU_PGC_SW_PUP_REQ   0xf8
#define GPC_PU_PGC_SW_PDN_REQ   0x104
#define USB_HSIC_PHY_SW_Pxx_REQ BIT(4)
#define USB_OTG2_PHY_SW_Pxx_REQ BIT(3)
#define USB_OTG1_PHY_SW_Pxx_REQ BIT(2)
#define PCIE_PHY_SW_Pxx_REQ BIT(1)
#define MIPI_PHY_SW_Pxx_REQ BIT(0)

Looks quite tight,
Can we have one more TAB for the definition?
Like:
#define GPC_PU_PGC_SW_PUP_REQ   0xf8

> +#define GPC_MAX_REGISTER 0x1000
> +
> +#define GPC_PGC_nCTRL_PCRBIT(0)
> +
> +struct imx7_pgc_domain {
> + struct 

Please I want you to patiently read this offer.?

[Mr.Hassan Habib]

Hello.

I know this means of communication may not be morally right to you as a person 
but I also have had a great thought about it and I have come to this conclusion 
which I am about to share with you.

INTRODUCTION:I am the Credit Manager U. B. A Bank of Burkina Faso Ouagadougou
and in one way or the other was hoping you will cooperate with me as a partner 
in a project of transferring an abandoned fund of a late customer of the bank 
worth of $18,000,000 (Eighteen Million Dollars US).

This will be disbursed or shared between the both of us in these percentages, 
55% to me and 35% to you while 10% will be for expenses both parties might have 
incurred during the process of transferring.
I
await for your response so that we can commence on this project as soon as 
possible.

Reply to this Email:mr_habib2...@yahoo.com

Regards,
Mr.Hassan Habib.

Credit Manager U.B.A Bank of
Burkina Faso Ouagadougou

Please I want you to patiently read this offer.?

[Mr.Hassan Habib]

Hello.

I know this means of communication may not be morally right to you as a person 
but I also have had a great thought about it and I have come to this conclusion 
which I am about to share with you.

INTRODUCTION:I am the Credit Manager U. B. A Bank of Burkina Faso Ouagadougou
and in one way or the other was hoping you will cooperate with me as a partner 
in a project of transferring an abandoned fund of a late customer of the bank 
worth of $18,000,000 (Eighteen Million Dollars US).

This will be disbursed or shared between the both of us in these percentages, 
55% to me and 35% to you while 10% will be for expenses both parties might have 
incurred during the process of transferring.
I
await for your response so that we can commence on this project as soon as 
possible.

Reply to this Email:mr_habib2...@yahoo.com

Regards,
Mr.Hassan Habib.

Credit Manager U.B.A Bank of
Burkina Faso Ouagadougou

Re: [PATCH v2 1/7] pinctrl: Renesas RZ/A1 pin and gpio controller

[jacopo]

Hi Geert,
   thanks for detailed review

On Wed, Mar 22, 2017 at 11:26:58AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  
> wrote:
> > Add combined gpio and pin controller driver for Renesas RZ/A1
> > r7s72100 SoC.
> >
> > Signed-off-by: Jacopo Mondi 
> 
> Thanks for your patch!
> 
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-rza1.c
> 
> > +/*
> > + * This pincontroller/gpio combined driver support Renesas devices of RZ/A1
> > + * family.
> > + * This includes SoCs which are sub- or super- sets of this particular 
> > line,
> > + * as RZ/A1H (r7s721000), RZ/A1M (r7s721001) and RZ/A1L (r7s721002) are.
> 
> RZ/A1M = r7s721010, RZ/A1L = r7s721020
> 
> > +#define RZA1_ADDR(mem, reg, port)  ((mem) + (reg) + ((port) * 4))
> 
> 
> > +
> > +#define RZA1_NPORTS12
> > +#define RZA1_PINS_PER_PORT 16
> > +#define RZA1_NPINS (RZA1_PINS_PER_PORT * RZA1_NPORTS)
> > +#define RZA1_PIN_TO_PORT(pin)  ((pin) / RZA1_PINS_PER_PORT)
> > +#define RZA1_PIN_TO_OFFSET(pin)((pin) % RZA1_PINS_PER_PORT)
> > +
> > +/*
> > + * Be careful here: the pin configuration subnodes in device tree 
> > enumerates
> 
> enumerate
> 
> > + * alternate functions from 1 to 8; subtract 1 before using macros so to 
> > match
> > + * registers configuration which expects numbers from 0 to 7 instead.
> 
> register configuration
> 
> > + */
> > +#define MUX_FUNC_OFFS  3
> > +#define MUX_FUNC_MASK  (BIT(MUX_FUNC_OFFS) - 1)
> > +#define MUX_FUNC_PFC_MASK  BIT(0)
> > +#define MUX_FUNC_PFCE_MASK BIT(1)
> > +#define MUX_FUNC_PFCEA_MASKBIT(2)
> > +#define MUX_CONF_BIDIR BIT(0)
> > +#define MUX_CONF_SWIO_INPUTBIT(1)
> > +#define MUX_CONF_SWIO_OUTPUT   BIT(2)
> > +
> > +/**
> > + * rza1_pin_conf - describes a pin position, id, mux config and output 
> > value
> > + *
> > + * Use uint32_t to match types used in of_device nodes argument lists.
> > + *
> > + * @id: the pin identifier from 0 to RZA1_NPINS
> > + * @port: the port where pin sits on
> > + * @offset: pin offset in the port
> > + * @mux: alternate function configuration settings
> > + * @value: output value to set the pin to
> > + */
> > +struct rza1_pin_conf {
> > +   uint32_t id;
> > +   uint32_t port;
> > +   uint32_t offset;
> > +   uint32_t mux_conf;
> > +   uint32_t value;
> 
> In the kernel, we tend to use u32 instead of uint32_t.
> But many of these fields can be smaller than 32 bits, right, saving some
> memory (important when running with built-in RAM only).
> 

I'll move these to u8 (and u16 where appropriate) and fix all the
above grammar comments

> > +/**
> > + * rza1_pinctrl - RZ pincontroller device
> > + *
> > + * @dev: parent device structure
> > + * @mutex: protect [pinctrl|pinmux]_generic functions
> > + * @base: logical address base
> > + * @nports: number of pin controller ports
> > + * @ports: pin controller banks
> > + * @ngpiochips: number of gpio chips
> > + * @gpio_ranges: gpio ranges for pinctrl core
> > + * @pins: pin array for pinctrl core
> > + * @desc: pincontroller desc for pinctrl core
> > + * @pctl: pinctrl device
> > + */
> > +struct rza1_pinctrl {
> > +   struct device *dev;
> > +
> > +   struct mutex mutex;
> > +
> > +   void __iomem *base;
> > +
> > +   unsigned int nport;
> > +   struct rza1_port *ports;
> > +
> > +   unsigned int ngpiochips;
> > +
> > +   struct pinctrl_gpio_range *gpio_ranges;
> > +   struct pinctrl_pin_desc *pins;
> > +   struct pinctrl_desc desc;
> > +   struct pinctrl_dev *pctl;
> 
> It's a good idea not to mix pointers and integers, as the pointers will
> be 64-bit on 64-bit platforms, leading to gaps due to alignment rules.
> Not super-important here, as (for now) this driver is meant for 32-bit SoCs.
> 

I grouped this variables "logically", and even if I understand your
concerns, there will be a single "struct rza1_pinctrl" per driver
instance, so I hope we can tollerate some padding bytes in favour of more
clearness. Also, as you said, there are no 64-bits RZ platforms atm.

> > +/**
> > + * rza1_set_bit() - un-locked set/clear a single bit in pin configuration
> > + * registers
> > + */
> > +static inline void rza1_set_bit(const struct rza1_port *port,
> > +   unsigned int reg, unsigned int offset,
> > +   bool set)
> 
> I think "reg" and "set" still fit on the previous lines (many more cases
> in other functions).
> 
> I'd call "offset" "bit" (and "reg" "offset"?)

I'll s/offset/bit and s/offset/pin where appropriate

> 
> > +{
> > +   void __iomem *mem = RZA1_ADDR(port->base, reg, port->id);
> 
> I think this would be easier to read without using the RZA1_ADDR() macro.
> 

Don't know... I can change this if you 

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

[Jan Beulich]

>>> On 23.03.17 at 14:56,  wrote:
> On 23/03/17 14:37, Jan Beulich wrote:
> On 23.03.17 at 13:52,  wrote:
>>> Connecting to the backend isn't working reliably in xen-fbfront: in
>>> case XenbusStateInitWait of the backend has been missed the backend
>>> transition to XenbusStateConnected will trigger the connected state
>>> only without doing the actions required when the backend has
>>> connected.
>> 
>> Looks like xen-kbdfront does exactly the same - shouldn't it also be
>> changed then?
> 
> I posted that patch 2 days ago. :-)

Oh, I'm sorry - the completely different title misguided me.

Jan

Re: [PATCH v2 1/7] pinctrl: Renesas RZ/A1 pin and gpio controller

[jacopo]

Hi Geert,
   thanks for detailed review

On Wed, Mar 22, 2017 at 11:26:58AM +0100, Geert Uytterhoeven wrote:
> Hi Jacopo,
> 
> On Mon, Mar 20, 2017 at 5:14 PM, Jacopo Mondi  
> wrote:
> > Add combined gpio and pin controller driver for Renesas RZ/A1
> > r7s72100 SoC.
> >
> > Signed-off-by: Jacopo Mondi 
> 
> Thanks for your patch!
> 
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-rza1.c
> 
> > +/*
> > + * This pincontroller/gpio combined driver support Renesas devices of RZ/A1
> > + * family.
> > + * This includes SoCs which are sub- or super- sets of this particular 
> > line,
> > + * as RZ/A1H (r7s721000), RZ/A1M (r7s721001) and RZ/A1L (r7s721002) are.
> 
> RZ/A1M = r7s721010, RZ/A1L = r7s721020
> 
> > +#define RZA1_ADDR(mem, reg, port)  ((mem) + (reg) + ((port) * 4))
> 
> 
> > +
> > +#define RZA1_NPORTS12
> > +#define RZA1_PINS_PER_PORT 16
> > +#define RZA1_NPINS (RZA1_PINS_PER_PORT * RZA1_NPORTS)
> > +#define RZA1_PIN_TO_PORT(pin)  ((pin) / RZA1_PINS_PER_PORT)
> > +#define RZA1_PIN_TO_OFFSET(pin)((pin) % RZA1_PINS_PER_PORT)
> > +
> > +/*
> > + * Be careful here: the pin configuration subnodes in device tree 
> > enumerates
> 
> enumerate
> 
> > + * alternate functions from 1 to 8; subtract 1 before using macros so to 
> > match
> > + * registers configuration which expects numbers from 0 to 7 instead.
> 
> register configuration
> 
> > + */
> > +#define MUX_FUNC_OFFS  3
> > +#define MUX_FUNC_MASK  (BIT(MUX_FUNC_OFFS) - 1)
> > +#define MUX_FUNC_PFC_MASK  BIT(0)
> > +#define MUX_FUNC_PFCE_MASK BIT(1)
> > +#define MUX_FUNC_PFCEA_MASKBIT(2)
> > +#define MUX_CONF_BIDIR BIT(0)
> > +#define MUX_CONF_SWIO_INPUTBIT(1)
> > +#define MUX_CONF_SWIO_OUTPUT   BIT(2)
> > +
> > +/**
> > + * rza1_pin_conf - describes a pin position, id, mux config and output 
> > value
> > + *
> > + * Use uint32_t to match types used in of_device nodes argument lists.
> > + *
> > + * @id: the pin identifier from 0 to RZA1_NPINS
> > + * @port: the port where pin sits on
> > + * @offset: pin offset in the port
> > + * @mux: alternate function configuration settings
> > + * @value: output value to set the pin to
> > + */
> > +struct rza1_pin_conf {
> > +   uint32_t id;
> > +   uint32_t port;
> > +   uint32_t offset;
> > +   uint32_t mux_conf;
> > +   uint32_t value;
> 
> In the kernel, we tend to use u32 instead of uint32_t.
> But many of these fields can be smaller than 32 bits, right, saving some
> memory (important when running with built-in RAM only).
> 

I'll move these to u8 (and u16 where appropriate) and fix all the
above grammar comments

> > +/**
> > + * rza1_pinctrl - RZ pincontroller device
> > + *
> > + * @dev: parent device structure
> > + * @mutex: protect [pinctrl|pinmux]_generic functions
> > + * @base: logical address base
> > + * @nports: number of pin controller ports
> > + * @ports: pin controller banks
> > + * @ngpiochips: number of gpio chips
> > + * @gpio_ranges: gpio ranges for pinctrl core
> > + * @pins: pin array for pinctrl core
> > + * @desc: pincontroller desc for pinctrl core
> > + * @pctl: pinctrl device
> > + */
> > +struct rza1_pinctrl {
> > +   struct device *dev;
> > +
> > +   struct mutex mutex;
> > +
> > +   void __iomem *base;
> > +
> > +   unsigned int nport;
> > +   struct rza1_port *ports;
> > +
> > +   unsigned int ngpiochips;
> > +
> > +   struct pinctrl_gpio_range *gpio_ranges;
> > +   struct pinctrl_pin_desc *pins;
> > +   struct pinctrl_desc desc;
> > +   struct pinctrl_dev *pctl;
> 
> It's a good idea not to mix pointers and integers, as the pointers will
> be 64-bit on 64-bit platforms, leading to gaps due to alignment rules.
> Not super-important here, as (for now) this driver is meant for 32-bit SoCs.
> 

I grouped this variables "logically", and even if I understand your
concerns, there will be a single "struct rza1_pinctrl" per driver
instance, so I hope we can tollerate some padding bytes in favour of more
clearness. Also, as you said, there are no 64-bits RZ platforms atm.

> > +/**
> > + * rza1_set_bit() - un-locked set/clear a single bit in pin configuration
> > + * registers
> > + */
> > +static inline void rza1_set_bit(const struct rza1_port *port,
> > +   unsigned int reg, unsigned int offset,
> > +   bool set)
> 
> I think "reg" and "set" still fit on the previous lines (many more cases
> in other functions).
> 
> I'd call "offset" "bit" (and "reg" "offset"?)

I'll s/offset/bit and s/offset/pin where appropriate

> 
> > +{
> > +   void __iomem *mem = RZA1_ADDR(port->base, reg, port->id);
> 
> I think this would be easier to read without using the RZA1_ADDR() macro.
> 

Don't know... I can change this if you prefer... there's nothing nasty
hidden behind this 

Re: [Xen-devel] [PATCH] xen, fbfront: fix connecting to backend

[Jan Beulich]

>>> On 23.03.17 at 14:56,  wrote:
> On 23/03/17 14:37, Jan Beulich wrote:
> On 23.03.17 at 13:52,  wrote:
>>> Connecting to the backend isn't working reliably in xen-fbfront: in
>>> case XenbusStateInitWait of the backend has been missed the backend
>>> transition to XenbusStateConnected will trigger the connected state
>>> only without doing the actions required when the backend has
>>> connected.
>> 
>> Looks like xen-kbdfront does exactly the same - shouldn't it also be
>> changed then?
> 
> I posted that patch 2 days ago. :-)

Oh, I'm sorry - the completely different title misguided me.

Jan

[PATCH] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

[michael.hennerich]

From: Michael Hennerich 

This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.

Signed-off-by: Michael Hennerich 
---
 .../devicetree/bindings/i2c/i2c-mux-ltc4306.txt|  61 
 MAINTAINERS|   8 +
 drivers/i2c/muxes/Kconfig  |  10 +
 drivers/i2c/muxes/Makefile |   1 +
 drivers/i2c/muxes/i2c-mux-ltc4306.c| 365 +
 5 files changed, 445 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
 create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
new file mode 100644
index 000..1e98c6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
@@ -0,0 +1,61 @@
+* Linear Technology / Analog Devices I2C bus switch
+
+Required Properties:
+
+  - compatible: Must contain one of the following.
+"lltc,ltc4305", "lltc,ltc4306"
+  - reg: The I2C address of the device.
+
+  The following required properties are defined externally:
+
+  - Standard I2C mux properties. See i2c-mux.txt in this directory.
+  - I2C child bus nodes. See i2c-mux.txt in this directory.
+
+Optional Properties:
+
+  - enable-gpios: Reference to the GPIO connected to the enable input.
+  - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
+children in idle state. This is necessary for example, if there are several
+multiplexers on the bus and the devices behind them use same I2C addresses.
+  - gpio-controller: Marks the device node as a GPIO Controller.
+  - #gpio-cells: Should be two.  The first cell is the pin number and
+   the second cell is used to specify flags.
+   See ../gpio/gpio.txt for more information.
+  - ltc,downstream-accelerators-enable: Enables the rise time accelerators
+   on the downstream port.
+  - ltc,upstream-accelerators-enable: Enables the rise time accelerators
+   on the upstream port.
+
+Example:
+
+   ltc4306: i2c-mux@4a {
+   compatible = "lltc,ltc4306";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x4a>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   i2c@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   eeprom@50 {
+   compatible = "at,24c02";
+   reg = <0x50>;
+   };
+   };
+
+   i2c@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   eeprom@50 {
+   compatible = "at,24c02";
+   reg = <0x50>;
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index c776906..9a27a19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7698,6 +7698,14 @@ S:   Maintained
 F: Documentation/hwmon/ltc4261
 F: drivers/hwmon/ltc4261.c
 
+LTC4306 I2C MULTIPLEXER DRIVER
+M: Michael Hennerich 
+W: http://ez.analog.com/community/linux-device-drivers
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/i2c/muxes/i2c-mux-ltc4306.c
+F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
+
 LTP (Linux Test Project)
 M: Mike Frysinger 
 M: Cyril Hrubis 
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17..f501b3b 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -30,6 +30,16 @@ config I2C_MUX_GPIO
  This driver can also be built as a module.  If so, the module
  will be called i2c-mux-gpio.
 
+config I2C_MUX_LTC4306
+   tristate "LTC LTC4306/5 I2C multiplexer"
+   select GPIOLIB
+   help
+ If you say yes here you get support for the LTC LTC4306 or LTC4305
+ I2C mux/switch devices.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-mux-ltc4306.
+
 config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa4..a452d09 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
 
 

[PATCH] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch

[michael.hennerich]

From: Michael Hennerich 

This patch adds support for the Analog Devices / Linear Technology
LTC4306 and LTC4305 4/2 Channel I2C Bus Multiplexer/Switches.
The LTC4306 optionally provides two general purpose input/output pins
(GPIOs) that can be configured as logic inputs, opendrain outputs or
push-pull outputs via the generic GPIOLIB framework.

Signed-off-by: Michael Hennerich 
---
 .../devicetree/bindings/i2c/i2c-mux-ltc4306.txt|  61 
 MAINTAINERS|   8 +
 drivers/i2c/muxes/Kconfig  |  10 +
 drivers/i2c/muxes/Makefile |   1 +
 drivers/i2c/muxes/i2c-mux-ltc4306.c| 365 +
 5 files changed, 445 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
 create mode 100644 drivers/i2c/muxes/i2c-mux-ltc4306.c

diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt 
b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
new file mode 100644
index 000..1e98c6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
@@ -0,0 +1,61 @@
+* Linear Technology / Analog Devices I2C bus switch
+
+Required Properties:
+
+  - compatible: Must contain one of the following.
+"lltc,ltc4305", "lltc,ltc4306"
+  - reg: The I2C address of the device.
+
+  The following required properties are defined externally:
+
+  - Standard I2C mux properties. See i2c-mux.txt in this directory.
+  - I2C child bus nodes. See i2c-mux.txt in this directory.
+
+Optional Properties:
+
+  - enable-gpios: Reference to the GPIO connected to the enable input.
+  - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all
+children in idle state. This is necessary for example, if there are several
+multiplexers on the bus and the devices behind them use same I2C addresses.
+  - gpio-controller: Marks the device node as a GPIO Controller.
+  - #gpio-cells: Should be two.  The first cell is the pin number and
+   the second cell is used to specify flags.
+   See ../gpio/gpio.txt for more information.
+  - ltc,downstream-accelerators-enable: Enables the rise time accelerators
+   on the downstream port.
+  - ltc,upstream-accelerators-enable: Enables the rise time accelerators
+   on the upstream port.
+
+Example:
+
+   ltc4306: i2c-mux@4a {
+   compatible = "lltc,ltc4306";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x4a>;
+
+   gpio-controller;
+   #gpio-cells = <2>;
+
+   i2c@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   eeprom@50 {
+   compatible = "at,24c02";
+   reg = <0x50>;
+   };
+   };
+
+   i2c@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   eeprom@50 {
+   compatible = "at,24c02";
+   reg = <0x50>;
+   };
+   };
+   };
diff --git a/MAINTAINERS b/MAINTAINERS
index c776906..9a27a19 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7698,6 +7698,14 @@ S:   Maintained
 F: Documentation/hwmon/ltc4261
 F: drivers/hwmon/ltc4261.c
 
+LTC4306 I2C MULTIPLEXER DRIVER
+M: Michael Hennerich 
+W: http://ez.analog.com/community/linux-device-drivers
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/i2c/muxes/i2c-mux-ltc4306.c
+F: Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt
+
 LTP (Linux Test Project)
 M: Mike Frysinger 
 M: Cyril Hrubis 
diff --git a/drivers/i2c/muxes/Kconfig b/drivers/i2c/muxes/Kconfig
index 10b3d17..f501b3b 100644
--- a/drivers/i2c/muxes/Kconfig
+++ b/drivers/i2c/muxes/Kconfig
@@ -30,6 +30,16 @@ config I2C_MUX_GPIO
  This driver can also be built as a module.  If so, the module
  will be called i2c-mux-gpio.
 
+config I2C_MUX_LTC4306
+   tristate "LTC LTC4306/5 I2C multiplexer"
+   select GPIOLIB
+   help
+ If you say yes here you get support for the LTC LTC4306 or LTC4305
+ I2C mux/switch devices.
+
+ This driver can also be built as a module.  If so, the module
+ will be called i2c-mux-ltc4306.
+
 config I2C_MUX_PCA9541
tristate "NXP PCA9541 I2C Master Selector"
help
diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
index 9948fa4..a452d09 100644
--- a/drivers/i2c/muxes/Makefile
+++ b/drivers/i2c/muxes/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_I2C_DEMUX_PINCTRL) += i2c-demux-pinctrl.o
 
 obj-$(CONFIG_I2C_MUX_GPIO) += i2c-mux-gpio.o
 obj-$(CONFIG_I2C_MUX_MLXCPLD)  += i2c-mux-mlxcpld.o
+obj-$(CONFIG_I2C_MUX_LTC4306)  += 

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[John Crispin]

On 23/03/17 15:09, Felix Fietkau wrote:

On 2017-03-23 09:06, Sean Wang wrote:

Hi Andrew,

The purpose for the regmap table registered is to

provide a way which helps us to look up a specific

register on the switch through regmap-debugfs.


And not all ranges of register is defined

so I only include the meaningful ones in a sparse way

for the table.

I think in that case it might be nice to make regmap support optional in
order to avoid pulling in bloat on platforms that don't need it.

- Felix

The 2 relevant platforms are mips/ralink and arm/mediatek. both require 
regmap for the eth_sysctl syscon if they want to utilize the mtk_soc_eth 
driver which is a prereq for mt7530. so regmap cannot be optional here.


John




___
Linux-mediatek mailing list
linux-media...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[John Crispin]

On 23/03/17 15:09, Felix Fietkau wrote:

On 2017-03-23 09:06, Sean Wang wrote:

Hi Andrew,

The purpose for the regmap table registered is to

provide a way which helps us to look up a specific

register on the switch through regmap-debugfs.


And not all ranges of register is defined

so I only include the meaningful ones in a sparse way

for the table.

I think in that case it might be nice to make regmap support optional in
order to avoid pulling in bloat on platforms that don't need it.

- Felix

The 2 relevant platforms are mips/ralink and arm/mediatek. both require 
regmap for the eth_sysctl syscon if they want to utilize the mtk_soc_eth 
driver which is a prereq for mt7530. so regmap cannot be optional here.


John




___
Linux-mediatek mailing list
linux-media...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

Re: Purpose of PCI address in ranges property

[Arnd Bergmann]

On Thu, Mar 23, 2017 at 3:59 AM, valmiki  wrote:
> On 3/20/2017 3:15 AM, Arnd Bergmann wrote:
>>
>> On Sun, Mar 19, 2017 at 3:14 PM, valmiki  wrote:
>>>
>>> Hi,
>>>
>>> When ranges property is being parsed using
>>> of_pci_get_host_bridge_resources,
>>> the pci address is being used for
>>> calculating the offset for pci_add_resource_offset.
>>>
>>> What is this offset for ?
>>>
>>> So the cpu address is being used for programming memory base and limit
>>> registers ?
>>
>>
>> Linux IORESOURCE_MEM resources are defined in terms of CPU addresses,
>> while PCI config space BAR registers are programmed with bus addresses.
>> These are often the same, but on some machines they are not, which results
>> in an offset that has to be used when accessing the BARs.
>>
> Thanks Arnd. So mem base and limit registers of RP are programmed with CPU
> addresses,
> and EP BARs are programmed with PCI bus addresses ?
> So when will this offset be used, only when RP assigns BAR's to RP ?

I think depending on your platform, we either assign the BARs or we
read the ones that the firmware has assigned, and either way the
offset has to be applied in or way or the other.

  Arnd

Re: Purpose of PCI address in ranges property

[Arnd Bergmann]

On Thu, Mar 23, 2017 at 3:59 AM, valmiki  wrote:
> On 3/20/2017 3:15 AM, Arnd Bergmann wrote:
>>
>> On Sun, Mar 19, 2017 at 3:14 PM, valmiki  wrote:
>>>
>>> Hi,
>>>
>>> When ranges property is being parsed using
>>> of_pci_get_host_bridge_resources,
>>> the pci address is being used for
>>> calculating the offset for pci_add_resource_offset.
>>>
>>> What is this offset for ?
>>>
>>> So the cpu address is being used for programming memory base and limit
>>> registers ?
>>
>>
>> Linux IORESOURCE_MEM resources are defined in terms of CPU addresses,
>> while PCI config space BAR registers are programmed with bus addresses.
>> These are often the same, but on some machines they are not, which results
>> in an offset that has to be used when accessing the BARs.
>>
> Thanks Arnd. So mem base and limit registers of RP are programmed with CPU
> addresses,
> and EP BARs are programmed with PCI bus addresses ?
> So when will this offset be used, only when RP assigns BAR's to RP ?

I think depending on your platform, we either assign the BARs or we
read the ones that the firmware has assigned, and either way the
offset has to be applied in or way or the other.

  Arnd

Re: fs: use-after-free in path_lookupat

[Dmitry Vyukov]

On Sun, Mar 5, 2017 at 8:18 PM, Al Viro  wrote:
> On Sun, Mar 05, 2017 at 06:33:18PM +0100, Dmitry Vyukov wrote:
>
>> Added more debug output.
>>
>> name_to_handle_at(r4, &(0x7f003000-0x6)="2e2f62757300",
>> &(0x7f003000-0xd)={0xc, 0x0, "cd21"}, &(0x7f002000)=0x0,
>> 0x1000)
>>
>> actually passes name="" because of the overlapping addresses. Flags
>> contain AT_EMPTY_PATH.
>
> Bloody hell...  So you end up with name == (char *)>handle_type + 3?
> Looks like it would be a lot more useful to dump the actual contents of
> those suckers right before the syscall...
>
> Anyway, that explains WTF is going on.  The bug is in path_init() and
> it triggers when you pass something with dentry allocated by d_alloc_pseudo()
> as dfd, combined with empty pathname.  You need to have the file closed
> by another thread, and have that another thread get out of closing syscall
> (close(), dup2(), etc.) before the caller of path_init() gets to
> complete_walk().  We need to make sure that this sucker gets DCACHE_RCUPDATE
> while it's still guaranteed to be pinned down.  Could you try to reproduce
> with the patch below applied?
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 6f7d96368734..70840281a41c 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2226,11 +2226,16 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
> nd->path = f.file->f_path;
> if (flags & LOOKUP_RCU) {
> rcu_read_lock();
> -   nd->inode = nd->path.dentry->d_inode;
> -   nd->seq = 
> read_seqcount_begin(>path.dentry->d_seq);
> +   if (unlikely(!(dentry->d_flags & DCACHE_RCUACCESS))) {
> +   spin_lock(>d_lock);
> +   dentry->d_flags |= DCACHE_RCUACCESS;
> +   spin_unlock(>d_lock);
> +   }
> +   nd->inode = dentry->d_inode;
> +   nd->seq = read_seqcount_begin(>d_seq);
> } else {
> path_get(>path);
> -   nd->inode = nd->path.dentry->d_inode;
> +   nd->inode = dentry->d_inode;
> }
> fdput(f);
> return s;


Al, please send this patch officially. I am running with it since then
and have not seen the crashes, nor any other issues that look related.

Thanks!

Re: fs: use-after-free in path_lookupat

[Dmitry Vyukov]

On Sun, Mar 5, 2017 at 8:18 PM, Al Viro  wrote:
> On Sun, Mar 05, 2017 at 06:33:18PM +0100, Dmitry Vyukov wrote:
>
>> Added more debug output.
>>
>> name_to_handle_at(r4, &(0x7f003000-0x6)="2e2f62757300",
>> &(0x7f003000-0xd)={0xc, 0x0, "cd21"}, &(0x7f002000)=0x0,
>> 0x1000)
>>
>> actually passes name="" because of the overlapping addresses. Flags
>> contain AT_EMPTY_PATH.
>
> Bloody hell...  So you end up with name == (char *)>handle_type + 3?
> Looks like it would be a lot more useful to dump the actual contents of
> those suckers right before the syscall...
>
> Anyway, that explains WTF is going on.  The bug is in path_init() and
> it triggers when you pass something with dentry allocated by d_alloc_pseudo()
> as dfd, combined with empty pathname.  You need to have the file closed
> by another thread, and have that another thread get out of closing syscall
> (close(), dup2(), etc.) before the caller of path_init() gets to
> complete_walk().  We need to make sure that this sucker gets DCACHE_RCUPDATE
> while it's still guaranteed to be pinned down.  Could you try to reproduce
> with the patch below applied?
>
> diff --git a/fs/namei.c b/fs/namei.c
> index 6f7d96368734..70840281a41c 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -2226,11 +2226,16 @@ static const char *path_init(struct nameidata *nd, 
> unsigned flags)
> nd->path = f.file->f_path;
> if (flags & LOOKUP_RCU) {
> rcu_read_lock();
> -   nd->inode = nd->path.dentry->d_inode;
> -   nd->seq = 
> read_seqcount_begin(>path.dentry->d_seq);
> +   if (unlikely(!(dentry->d_flags & DCACHE_RCUACCESS))) {
> +   spin_lock(>d_lock);
> +   dentry->d_flags |= DCACHE_RCUACCESS;
> +   spin_unlock(>d_lock);
> +   }
> +   nd->inode = dentry->d_inode;
> +   nd->seq = read_seqcount_begin(>d_seq);
> } else {
> path_get(>path);
> -   nd->inode = nd->path.dentry->d_inode;
> +   nd->inode = dentry->d_inode;
> }
> fdput(f);
> return s;


Al, please send this patch officially. I am running with it since then
and have not seen the crashes, nor any other issues that look related.

Thanks!

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

[Marc Zyngier]

On 23/03/17 13:05, Mason wrote:
> I think this version is ready for review.
> It has all the required bits and pieces.
> I still have a few questions, embedded as comments in the code.
> (Missing are ancillary changes to Kconfig, Makefile)

May I suggest that if you think that a patch is ready for review, it
should really contain all the bits that make it an actual patch? That
would include an actual commit log and all what is required to actually
compile it. Not to mention a SoB.

We rely (at least I certainly do) on things like the kbuild robot
picking up stuff from the list and giving it a go. Also, it makes it a
much more efficient use of the reviewer time not to review the same
thing twice...

That being said:

> ---
>  drivers/pci/host/pcie-tango.c | 350 
> ++
>  1 file changed, 350 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-tango.c
> 
> diff --git a/drivers/pci/host/pcie-tango.c b/drivers/pci/host/pcie-tango.c
> new file mode 100644
> index ..b2e6448aed2d
> --- /dev/null
> +++ b/drivers/pci/host/pcie-tango.c
> @@ -0,0 +1,350 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MSI_COUNT 32

Is this something that is hardcoded? Unlikely to ever change?

> +
> +struct tango_pcie {
> + void __iomem *mux;
> + void __iomem *msi_status;
> + void __iomem *msi_mask;
> + phys_addr_t msi_doorbell;
> + struct mutex lock; /* lock for updating msi_mask */
> + struct irq_domain *irq_domain;
> + struct irq_domain *msi_domain;
> + int irq;
> +};
> +
> +/*** MSI CONTROLLER SUPPORT ***/
> +
> +static void tango_msi_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct tango_pcie *pcie;
> + unsigned long status, virq;
> + int pos;
> +
> + chained_irq_enter(chip, desc);
> + pcie = irq_desc_get_handler_data(desc);
> +
> + status = readl_relaxed(pcie->msi_status);

Please use types that unambiguously match that of the MMIO accessor (u32
in this case). On a 64bit system, unsigned long is likely to be 64bit.
You can assign it to an unsigned long before calling the
for_each_set_bit operator.

> + writel_relaxed(status, pcie->msi_status); /* clear IRQs */

Why isn't this your irq_ack method instead of open-coding it?

> +
> + for_each_set_bit(pos, , MSI_COUNT) {
> + virq = irq_find_mapping(pcie->irq_domain, pos);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + pr_err("Unhandled MSI: %d\n", pos);

Please rate-limit this.

> + }
> +
> + chained_irq_exit(chip, desc);
> +}
> +
> +static struct irq_chip tango_msi_irq_chip = {
> + .name = "MSI",
> + .irq_mask = pci_msi_mask_irq,
> + .irq_unmask = pci_msi_unmask_irq,
> +};
> +
> +static struct msi_domain_info msi_domain_info = {
> + .flags  = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,

No support for MSI-X? Why?

> + .chip   = _msi_irq_chip,
> +};
> +
> +static void tango_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct tango_pcie *pcie = irq_data_get_irq_chip_data(data);
> +
> + msg->address_lo = lower_32_bits(pcie->msi_doorbell);
> + msg->address_hi = upper_32_bits(pcie->msi_doorbell);
> + msg->data = data->hwirq;
> +}
> +
> +static int tango_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> +  return -EINVAL;
> +}
> +
> +static struct irq_chip tango_msi_chip = {
> + .name   = "MSI",
> + .irq_compose_msi_msg= tango_compose_msi_msg,
> + .irq_set_affinity   = tango_set_affinity,
> +};
> +
> +static int tango_irq_domain_alloc(struct irq_domain *domain, unsigned int 
> virq,
> + unsigned int nr_irqs, void *args)
> +{
> + struct tango_pcie *pcie = domain->host_data;
> + int pos, err = 0;
> + u32 mask;
> +
> + if (nr_irqs != 1) /* When does that happen? */
> + return -EINVAL;

Only if the end-point wants to use Multi-MSI. You don't advertise
support for it, so it should never happen.

> +
> + mutex_lock(>lock);
> +
> + mask = readl_relaxed(pcie->msi_mask);

Do you really need to read this from the HW each time you allocate an
interrupt? That feels pretty crazy. You're much better off having an
in-memory bitmap that will make things more efficient, and avoid the
following bug...

> + pos = find_first_zero_bit(, MSI_COUNT);

... where using a u32 as a bitmap is a very bad idea (because not the
whole world is a 32bit, little endian platform).

> + if (pos < MSI_COUNT)
> + writel(mask | BIT(pos), pcie->msi_mask);

And it would make a lot more sense to move this write (which should be
relaxed) to irq_unmask. Also, calling msi_mask for something that is an
enable register is a bit counter intuitive.

> + else
> + err = -ENOSPC;
> +
> + mutex_unlock(>lock);
> 

Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory

[Will Deacon]

Hi Stephen,

On Fri, Feb 24, 2017 at 05:39:08PM -0800, Stephen Boyd wrote:
> Quoting James Morse (2017-02-20 03:10:10)
> > On 17/02/17 15:53, Stephen Boyd wrote:
> > > Quoting James Morse (2017-02-17 03:00:39)
> > >> On 17/02/17 01:19, Stephen Boyd wrote:
> > >>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > >>> index 156169c6981b..8bd4e7f11c70 100644
> > >>> --- a/arch/arm64/mm/fault.c
> > >>> +++ b/arch/arm64/mm/fault.c
> > >>> @@ -177,9 +193,19 @@ static void __do_kernel_fault(struct mm_struct 
> > >>> *mm, unsigned long addr,
> > >>>* No handler, we'll have to terminate things with extreme 
> > >>> prejudice.
> > >>>*/
> > >>>   bust_spinlocks(1);
> > >>> - pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
> > >>> -  (addr < PAGE_SIZE) ? "NULL pointer dereference" :
> > >>> -  "paging request", addr);
> > >>> +
> > >>> + if (is_permission_fault(esr, regs)) {
> > >>
> > >> is_permission_fault() was previously guarded with a 'addr > >> check, this
> > >> is because it assumes software-PAN is relevant.
> > >>
> > >> The corner case is when the kernel accesses TTBR1-mapped memory while
> > >> software-PAN happens to have swivelled TTBR0. Translation faults will be 
> > >> matched
> > >> by is_permission_fault(), but permission faults won't.
> > > 
> > > If I understand correctly, and I most definitely don't because there are
> > > quite a few combinations, you're saying that __do_kernel_fault() could
> > > be called if the kernel attempts to access some userspace address with
> > > software PAN? That won't be caught in do_page_fault() with the previous
> > > is_permission_fault() check?
> > 
> > You're right the user-address side of things will get caught in 
> > do_page_fault().
> > I was trying to badly-explain 'is_permission_fault(esr)' isn't as general
> > purpose as its name and prototype suggest, it only gives the results that 
> > the
> > PAN checks expect when called with a user address.
> 
> Ok. I'd rather not change the function in this patch because I'm only
> moving the code around to use it higher up in the file. But if you
> prefer I can combine the code movement with the addition of a new 'addr'
> argument to this function and rework things based on that.

Are you planning to send a v3 of this?

Will

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

[Christoph Hellwig]

On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote:
>
>
> On 2017年03月23日 08:30, Laura Abbott wrote:
>> Hi,
>>
>> Fedora has received multiple reports of crashes when running
>> 4.11 as a guest
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1430297
>> https://bugzilla.redhat.com/show_bug.cgi?id=1434462
>> https://bugzilla.kernel.org/show_bug.cgi?id=194911
>> https://bugzilla.redhat.com/show_bug.cgi?id=1433899
>>
>> The crashes are not always consistent but they are generally
>> some flavor of oops or GPF in virtio related code. Multiple people
>> have done bisections (Thank you Thorsten Leemhuis and
>> Richard W.M. Jones) and found this commit to be at fault
>>
>> 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507 is the first bad commit
>> commit 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507
>> Author: Christoph Hellwig 
>> Date:   Sun Feb 5 18:15:19 2017 +0100
>>
>>  virtio_pci: use shared interrupts for virtqueues
>>   This lets IRQ layer handle dispatching IRQs to separate handlers 
>> for the
>>  case where we don't have per-VQ MSI-X vectors, and allows us to greatly
>>  simplify the code based on the assumption that we always have interrupt
>>  vector 0 (legacy INTx or config interrupt for MSI-X) available, and
>>  any other interrupt is request/freed throught the VQ, even if the
>>  actual interrupt line might be shared in some cases.
>>   This allows removing a great deal of variables keeping track of 
>> the
>>  interrupt state in struct virtio_pci_device, as we can now simply walk 
>> the
>>  list of VQs and deal with per-VQ interrupt handlers there, and only 
>> treat
>>  vector 0 special.
>>   Additionally clean up the VQ allocation code to properly unwind 
>> on error
>>  instead of having a single global cleanup label, which is error prone,
>>  and in this case also leads to more code.
>>   Signed-off-by: Christoph Hellwig 
>>  Signed-off-by: Michael S. Tsirkin 
>>
>> :04 04 79a8267ffb73f9d244267c5f68365305bddd4696 
>> 8832a160b978710bbd24ba6966f462b3faa27fcc M   drivers
>>
>> It doesn't revert cleanly so we haven't been able to do a clean
>> test. Any ideas?
>>
>> Thanks,
>> Laura
>
> Hello:
>
> Can you try the attached patch to see if it solves the problem? (At least 
> it silent KASan warnings for me).

This looks like a correct fix to me, independent of fixing the original
bug or not:

Reviewed-by: Christoph Hellwig 

Re: [RFC PATCH v0.2] PCI: Add support for tango PCIe host bridge

[Marc Zyngier]

On 23/03/17 13:05, Mason wrote:
> I think this version is ready for review.
> It has all the required bits and pieces.
> I still have a few questions, embedded as comments in the code.
> (Missing are ancillary changes to Kconfig, Makefile)

May I suggest that if you think that a patch is ready for review, it
should really contain all the bits that make it an actual patch? That
would include an actual commit log and all what is required to actually
compile it. Not to mention a SoB.

We rely (at least I certainly do) on things like the kbuild robot
picking up stuff from the list and giving it a go. Also, it makes it a
much more efficient use of the reviewer time not to review the same
thing twice...

That being said:

> ---
>  drivers/pci/host/pcie-tango.c | 350 
> ++
>  1 file changed, 350 insertions(+)
>  create mode 100644 drivers/pci/host/pcie-tango.c
> 
> diff --git a/drivers/pci/host/pcie-tango.c b/drivers/pci/host/pcie-tango.c
> new file mode 100644
> index ..b2e6448aed2d
> --- /dev/null
> +++ b/drivers/pci/host/pcie-tango.c
> @@ -0,0 +1,350 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define MSI_COUNT 32

Is this something that is hardcoded? Unlikely to ever change?

> +
> +struct tango_pcie {
> + void __iomem *mux;
> + void __iomem *msi_status;
> + void __iomem *msi_mask;
> + phys_addr_t msi_doorbell;
> + struct mutex lock; /* lock for updating msi_mask */
> + struct irq_domain *irq_domain;
> + struct irq_domain *msi_domain;
> + int irq;
> +};
> +
> +/*** MSI CONTROLLER SUPPORT ***/
> +
> +static void tango_msi_isr(struct irq_desc *desc)
> +{
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct tango_pcie *pcie;
> + unsigned long status, virq;
> + int pos;
> +
> + chained_irq_enter(chip, desc);
> + pcie = irq_desc_get_handler_data(desc);
> +
> + status = readl_relaxed(pcie->msi_status);

Please use types that unambiguously match that of the MMIO accessor (u32
in this case). On a 64bit system, unsigned long is likely to be 64bit.
You can assign it to an unsigned long before calling the
for_each_set_bit operator.

> + writel_relaxed(status, pcie->msi_status); /* clear IRQs */

Why isn't this your irq_ack method instead of open-coding it?

> +
> + for_each_set_bit(pos, , MSI_COUNT) {
> + virq = irq_find_mapping(pcie->irq_domain, pos);
> + if (virq)
> + generic_handle_irq(virq);
> + else
> + pr_err("Unhandled MSI: %d\n", pos);

Please rate-limit this.

> + }
> +
> + chained_irq_exit(chip, desc);
> +}
> +
> +static struct irq_chip tango_msi_irq_chip = {
> + .name = "MSI",
> + .irq_mask = pci_msi_mask_irq,
> + .irq_unmask = pci_msi_unmask_irq,
> +};
> +
> +static struct msi_domain_info msi_domain_info = {
> + .flags  = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS,

No support for MSI-X? Why?

> + .chip   = _msi_irq_chip,
> +};
> +
> +static void tango_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
> +{
> + struct tango_pcie *pcie = irq_data_get_irq_chip_data(data);
> +
> + msg->address_lo = lower_32_bits(pcie->msi_doorbell);
> + msg->address_hi = upper_32_bits(pcie->msi_doorbell);
> + msg->data = data->hwirq;
> +}
> +
> +static int tango_set_affinity(struct irq_data *irq_data,
> + const struct cpumask *mask, bool force)
> +{
> +  return -EINVAL;
> +}
> +
> +static struct irq_chip tango_msi_chip = {
> + .name   = "MSI",
> + .irq_compose_msi_msg= tango_compose_msi_msg,
> + .irq_set_affinity   = tango_set_affinity,
> +};
> +
> +static int tango_irq_domain_alloc(struct irq_domain *domain, unsigned int 
> virq,
> + unsigned int nr_irqs, void *args)
> +{
> + struct tango_pcie *pcie = domain->host_data;
> + int pos, err = 0;
> + u32 mask;
> +
> + if (nr_irqs != 1) /* When does that happen? */
> + return -EINVAL;

Only if the end-point wants to use Multi-MSI. You don't advertise
support for it, so it should never happen.

> +
> + mutex_lock(>lock);
> +
> + mask = readl_relaxed(pcie->msi_mask);

Do you really need to read this from the HW each time you allocate an
interrupt? That feels pretty crazy. You're much better off having an
in-memory bitmap that will make things more efficient, and avoid the
following bug...

> + pos = find_first_zero_bit(, MSI_COUNT);

... where using a u32 as a bitmap is a very bad idea (because not the
whole world is a 32bit, little endian platform).

> + if (pos < MSI_COUNT)
> + writel(mask | BIT(pos), pcie->msi_mask);

And it would make a lot more sense to move this write (which should be
relaxed) to irq_unmask. Also, calling msi_mask for something that is an
enable register is a bit counter intuitive.

> + else
> + err = -ENOSPC;
> +
> + mutex_unlock(>lock);
> 

Re: [PATCH v2] arm64: print a fault message when attempting to write RO memory

[Will Deacon]

Hi Stephen,

On Fri, Feb 24, 2017 at 05:39:08PM -0800, Stephen Boyd wrote:
> Quoting James Morse (2017-02-20 03:10:10)
> > On 17/02/17 15:53, Stephen Boyd wrote:
> > > Quoting James Morse (2017-02-17 03:00:39)
> > >> On 17/02/17 01:19, Stephen Boyd wrote:
> > >>> diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
> > >>> index 156169c6981b..8bd4e7f11c70 100644
> > >>> --- a/arch/arm64/mm/fault.c
> > >>> +++ b/arch/arm64/mm/fault.c
> > >>> @@ -177,9 +193,19 @@ static void __do_kernel_fault(struct mm_struct 
> > >>> *mm, unsigned long addr,
> > >>>* No handler, we'll have to terminate things with extreme 
> > >>> prejudice.
> > >>>*/
> > >>>   bust_spinlocks(1);
> > >>> - pr_alert("Unable to handle kernel %s at virtual address %08lx\n",
> > >>> -  (addr < PAGE_SIZE) ? "NULL pointer dereference" :
> > >>> -  "paging request", addr);
> > >>> +
> > >>> + if (is_permission_fault(esr, regs)) {
> > >>
> > >> is_permission_fault() was previously guarded with a 'addr > >> check, this
> > >> is because it assumes software-PAN is relevant.
> > >>
> > >> The corner case is when the kernel accesses TTBR1-mapped memory while
> > >> software-PAN happens to have swivelled TTBR0. Translation faults will be 
> > >> matched
> > >> by is_permission_fault(), but permission faults won't.
> > > 
> > > If I understand correctly, and I most definitely don't because there are
> > > quite a few combinations, you're saying that __do_kernel_fault() could
> > > be called if the kernel attempts to access some userspace address with
> > > software PAN? That won't be caught in do_page_fault() with the previous
> > > is_permission_fault() check?
> > 
> > You're right the user-address side of things will get caught in 
> > do_page_fault().
> > I was trying to badly-explain 'is_permission_fault(esr)' isn't as general
> > purpose as its name and prototype suggest, it only gives the results that 
> > the
> > PAN checks expect when called with a user address.
> 
> Ok. I'd rather not change the function in this patch because I'm only
> moving the code around to use it higher up in the file. But if you
> prefer I can combine the code movement with the addition of a new 'addr'
> argument to this function and rework things based on that.

Are you planning to send a v3 of this?

Will

Re: [REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest

[Christoph Hellwig]

On Thu, Mar 23, 2017 at 01:13:50PM +0800, Jason Wang wrote:
>
>
> On 2017年03月23日 08:30, Laura Abbott wrote:
>> Hi,
>>
>> Fedora has received multiple reports of crashes when running
>> 4.11 as a guest
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=1430297
>> https://bugzilla.redhat.com/show_bug.cgi?id=1434462
>> https://bugzilla.kernel.org/show_bug.cgi?id=194911
>> https://bugzilla.redhat.com/show_bug.cgi?id=1433899
>>
>> The crashes are not always consistent but they are generally
>> some flavor of oops or GPF in virtio related code. Multiple people
>> have done bisections (Thank you Thorsten Leemhuis and
>> Richard W.M. Jones) and found this commit to be at fault
>>
>> 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507 is the first bad commit
>> commit 07ec51480b5eb1233f8c1b0f5d7a7c8d1247c507
>> Author: Christoph Hellwig 
>> Date:   Sun Feb 5 18:15:19 2017 +0100
>>
>>  virtio_pci: use shared interrupts for virtqueues
>>   This lets IRQ layer handle dispatching IRQs to separate handlers 
>> for the
>>  case where we don't have per-VQ MSI-X vectors, and allows us to greatly
>>  simplify the code based on the assumption that we always have interrupt
>>  vector 0 (legacy INTx or config interrupt for MSI-X) available, and
>>  any other interrupt is request/freed throught the VQ, even if the
>>  actual interrupt line might be shared in some cases.
>>   This allows removing a great deal of variables keeping track of 
>> the
>>  interrupt state in struct virtio_pci_device, as we can now simply walk 
>> the
>>  list of VQs and deal with per-VQ interrupt handlers there, and only 
>> treat
>>  vector 0 special.
>>   Additionally clean up the VQ allocation code to properly unwind 
>> on error
>>  instead of having a single global cleanup label, which is error prone,
>>  and in this case also leads to more code.
>>   Signed-off-by: Christoph Hellwig 
>>  Signed-off-by: Michael S. Tsirkin 
>>
>> :04 04 79a8267ffb73f9d244267c5f68365305bddd4696 
>> 8832a160b978710bbd24ba6966f462b3faa27fcc M   drivers
>>
>> It doesn't revert cleanly so we haven't been able to do a clean
>> test. Any ideas?
>>
>> Thanks,
>> Laura
>
> Hello:
>
> Can you try the attached patch to see if it solves the problem? (At least 
> it silent KASan warnings for me).

This looks like a correct fix to me, independent of fixing the original
bug or not:

Reviewed-by: Christoph Hellwig 

Re: [PATCH] qedf: fix wrong le16 conversion

[Martin K. Petersen]

Arnd Bergmann  writes:

> gcc points out that we are converting a 16-bit integer into a 32-bit
> little-endian type and assigning that to 16-bit little-endian
> will end up with a zero:
>
> drivers/scsi/qedf/drv_fcoe_fw_funcs.c: In function 
> 'init_initiator_rw_fcoe_task':
> include/uapi/linux/byteorder/big_endian.h:32:26: error: large integer 
> implicitly truncated to unsigned type [-Werror=overflow]
>   t_st_ctx->read_write.rx_id = cpu_to_le32(FCOE_RX_ID);
>
> The correct solution appears to be to just use a 16-bit byte swap instead.
>
> Fixes: be086e7c53f1 ("qed*: Utilize Firmware 8.15.3.0")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/scsi/qedf/drv_fcoe_fw_funcs.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Dave: Since you queued the firmware patch, mind taking this fix through
your tree?

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] qedf: fix wrong le16 conversion

[Martin K. Petersen]

Arnd Bergmann  writes:

> gcc points out that we are converting a 16-bit integer into a 32-bit
> little-endian type and assigning that to 16-bit little-endian
> will end up with a zero:
>
> drivers/scsi/qedf/drv_fcoe_fw_funcs.c: In function 
> 'init_initiator_rw_fcoe_task':
> include/uapi/linux/byteorder/big_endian.h:32:26: error: large integer 
> implicitly truncated to unsigned type [-Werror=overflow]
>   t_st_ctx->read_write.rx_id = cpu_to_le32(FCOE_RX_ID);
>
> The correct solution appears to be to just use a 16-bit byte swap instead.
>
> Fixes: be086e7c53f1 ("qed*: Utilize Firmware 8.15.3.0")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/scsi/qedf/drv_fcoe_fw_funcs.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Dave: Since you queued the firmware patch, mind taking this fix through
your tree?

-- 
Martin K. Petersen  Oracle Linux Engineering

Re: [PATCH] xen, fbfront: fix connecting to backend

[Boris Ostrovsky]

On 03/23/2017 08:52 AM, Juergen Gross wrote:
> Connecting to the backend isn't working reliably in xen-fbfront: in
> case XenbusStateInitWait of the backend has been missed the backend
> transition to XenbusStateConnected will trigger the connected state
> only without doing the actions required when the backend has
> connected.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

Re: [PATCH] xen, fbfront: fix connecting to backend

[Boris Ostrovsky]

On 03/23/2017 08:52 AM, Juergen Gross wrote:
> Connecting to the backend isn't working reliably in xen-fbfront: in
> case XenbusStateInitWait of the backend has been missed the backend
> transition to XenbusStateConnected will trigger the connected state
> only without doing the actions required when the backend has
> connected.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

fs: GPF in deactivate_locked_super

[Dmitry Vyukov]

Hello,

I've got the following crash while running syzkaller on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure, most likely it's the root cause.


FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 4874 Comm: syz-executor3 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 kzalloc include/linux/slab.h:495 [inline]
 register_shrinker+0x10e/0x2d0 mm/vmscan.c:284
 sget_userns+0xbf2/0xe40 fs/super.c:521
 mount_ns+0x6d/0x190 fs/super.c:1026
 mqueue_mount+0xbe/0xe0 ipc/mqueue.c:340
 mount_fs+0x66/0x2f0 fs/super.c:1223
 vfs_kern_mount.part.23+0xc6/0x4b0 fs/namespace.c:979
 vfs_kern_mount fs/namespace.c:3293 [inline]
 kern_mount_data+0x50/0xb0 fs/namespace.c:3293
 mq_init_ns+0x167/0x220 ipc/mqueue.c:1418
 create_ipc_ns ipc/namespace.c:57 [inline]
 copy_ipcs+0x39b/0x580 ipc/namespace.c:83
 create_new_namespaces+0x285/0x8c0 kernel/nsproxy.c:86
 unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
 SYSC_unshare kernel/fork.c:2319 [inline]
 SyS_unshare+0x664/0xf80 kernel/fork.c:2269
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7fb4faa4e858 EFLAGS: 0286 ORIG_RAX: 0110
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX:  RSI:  RDI: 0a04
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7fb4faa4e618 R15: 7fb4faa4e788

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4874 Comm: syz-executor3 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 8800390760c0 task.stack: 880039228000
RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
RSP: 0018:88003922ef00 EFLAGS: 00010246
RAX: dc00 RBX:  RCX: 
RDX:  RSI: 88003a232ea0 RDI: 88003a232ea8
RBP: 88003922ef18 R08: fbfff0c0242c R09: 0001
R10: 8800390760c0 R11: fbfff0c0242b R12: 
R13: dc00 R14: 88003a232740 R15: 88003a232ea0
FS:  7fb4faa4f700() GS:88003fd0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2ff7 CR3: 43a01000 CR4: 26e0
DR0: 2000 DR1: 2000 DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Call Trace:
 __list_del_entry include/linux/list.h:116 [inline]
 list_del include/linux/list.h:124 [inline]
 unregister_shrinker+0x79/0x300 mm/vmscan.c:301
 deactivate_locked_super+0x75/0xe0 fs/super.c:308
 deactivate_super+0x151/0x160 fs/super.c:340
 cleanup_mnt+0xb2/0x160 fs/namespace.c:1115
 mntput_no_expire+0x6e9/0xaa0 fs/namespace.c:1181
 mntput fs/namespace.c:1191 [inline]
 kern_unmount+0x9c/0xd0 fs/namespace.c:2995
 mq_put_mnt+0x37/0x50 ipc/mqueue.c:1434
 put_ipc_ns+0x4d/0x160 ipc/namespace.c:150
 free_nsproxy+0xde/0x230 kernel/nsproxy.c:179
 switch_task_namespaces+0xaa/0xc0 kernel/nsproxy.c:228
 exit_task_namespaces+0x17/0x20 kernel/nsproxy.c:233
 do_exit+0x1ac6/0x26d0 kernel/exit.c:878
 do_group_exit+0x149/0x400 kernel/exit.c:983
 get_signal+0x696/0x1810 kernel/signal.c:2318
 do_signal+0x90/0x1ee0 arch/x86/kernel/signal.c:808
 exit_to_usermode_loop+0x1e5/0x2d0 arch/x86/entry/common.c:157
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
RIP: 0033:0x445b79
RSP: 002b:7fb4faa4e858 EFLAGS: 0202 ORIG_RAX: 00ca
RAX: 0001 RBX: 00708000 RCX: 00445b79
RDX: 0009 RSI: 0001 RDI: 00708024
RBP: 1d10 R08:  R09: 
R10:  R11: 0202 R12: 006dfdd0
R13: 8208ae63 R14: 2000a000 R15: 
Code: 00 00 00 00 ad de 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de
48 89 da 48 39 c3 74 65 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df <80>
3c 02 00 75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8
RIP: __list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51 RSP: 88003922ef00
---[ end trace 569c84071b70c014 ]---

fs: GPF in deactivate_locked_super

[Dmitry Vyukov]

Hello,

I've got the following crash while running syzkaller on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure, most likely it's the root cause.


FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 4874 Comm: syz-executor3 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 kzalloc include/linux/slab.h:495 [inline]
 register_shrinker+0x10e/0x2d0 mm/vmscan.c:284
 sget_userns+0xbf2/0xe40 fs/super.c:521
 mount_ns+0x6d/0x190 fs/super.c:1026
 mqueue_mount+0xbe/0xe0 ipc/mqueue.c:340
 mount_fs+0x66/0x2f0 fs/super.c:1223
 vfs_kern_mount.part.23+0xc6/0x4b0 fs/namespace.c:979
 vfs_kern_mount fs/namespace.c:3293 [inline]
 kern_mount_data+0x50/0xb0 fs/namespace.c:3293
 mq_init_ns+0x167/0x220 ipc/mqueue.c:1418
 create_ipc_ns ipc/namespace.c:57 [inline]
 copy_ipcs+0x39b/0x580 ipc/namespace.c:83
 create_new_namespaces+0x285/0x8c0 kernel/nsproxy.c:86
 unshare_nsproxy_namespaces+0xae/0x1e0 kernel/nsproxy.c:205
 SYSC_unshare kernel/fork.c:2319 [inline]
 SyS_unshare+0x664/0xf80 kernel/fork.c:2269
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7fb4faa4e858 EFLAGS: 0286 ORIG_RAX: 0110
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX:  RSI:  RDI: 0a04
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7fb4faa4e618 R15: 7fb4faa4e788

kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 4874 Comm: syz-executor3 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 8800390760c0 task.stack: 880039228000
RIP: 0010:__list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51
RSP: 0018:88003922ef00 EFLAGS: 00010246
RAX: dc00 RBX:  RCX: 
RDX:  RSI: 88003a232ea0 RDI: 88003a232ea8
RBP: 88003922ef18 R08: fbfff0c0242c R09: 0001
R10: 8800390760c0 R11: fbfff0c0242b R12: 
R13: dc00 R14: 88003a232740 R15: 88003a232ea0
FS:  7fb4faa4f700() GS:88003fd0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 2ff7 CR3: 43a01000 CR4: 26e0
DR0: 2000 DR1: 2000 DR2: 
DR3:  DR6: 0ff0 DR7: 0600
Call Trace:
 __list_del_entry include/linux/list.h:116 [inline]
 list_del include/linux/list.h:124 [inline]
 unregister_shrinker+0x79/0x300 mm/vmscan.c:301
 deactivate_locked_super+0x75/0xe0 fs/super.c:308
 deactivate_super+0x151/0x160 fs/super.c:340
 cleanup_mnt+0xb2/0x160 fs/namespace.c:1115
 mntput_no_expire+0x6e9/0xaa0 fs/namespace.c:1181
 mntput fs/namespace.c:1191 [inline]
 kern_unmount+0x9c/0xd0 fs/namespace.c:2995
 mq_put_mnt+0x37/0x50 ipc/mqueue.c:1434
 put_ipc_ns+0x4d/0x160 ipc/namespace.c:150
 free_nsproxy+0xde/0x230 kernel/nsproxy.c:179
 switch_task_namespaces+0xaa/0xc0 kernel/nsproxy.c:228
 exit_task_namespaces+0x17/0x20 kernel/nsproxy.c:233
 do_exit+0x1ac6/0x26d0 kernel/exit.c:878
 do_group_exit+0x149/0x400 kernel/exit.c:983
 get_signal+0x696/0x1810 kernel/signal.c:2318
 do_signal+0x90/0x1ee0 arch/x86/kernel/signal.c:808
 exit_to_usermode_loop+0x1e5/0x2d0 arch/x86/entry/common.c:157
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
RIP: 0033:0x445b79
RSP: 002b:7fb4faa4e858 EFLAGS: 0202 ORIG_RAX: 00ca
RAX: 0001 RBX: 00708000 RCX: 00445b79
RDX: 0009 RSI: 0001 RDI: 00708024
RBP: 1d10 R08:  R09: 
R10:  R11: 0202 R12: 006dfdd0
R13: 8208ae63 R14: 2000a000 R15: 
Code: 00 00 00 00 ad de 49 39 c4 74 66 48 b8 00 02 00 00 00 00 ad de
48 89 da 48 39 c3 74 65 48 c1 ea 03 48 b8 00 00 00 00 00 fc ff df <80>
3c 02 00 75 7b 48 8b 13 48 39 f2 75 57 49 8d 7c 24 08 48 b8
RIP: __list_del_entry_valid+0x7e/0x150 lib/list_debug.c:51 RSP: 88003922ef00
---[ end trace 569c84071b70c014 ]---

Re: [PATCH] xen, fbfront: add support for specifying size via xenstore

[Boris Ostrovsky]

On 03/23/2017 08:53 AM, Juergen Gross wrote:
> Today xen-fbfront supports specifying the display size via module
> parameters only. Add support for specifying the size via Xenstore in
> order to enable doing this easily via the domain's Xen configuration.
>
> Add an error message in case the configured display size conflicts
> with video memory size.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

Re: [PATCH] xen, fbfront: add support for specifying size via xenstore

[Boris Ostrovsky]

On 03/23/2017 08:53 AM, Juergen Gross wrote:
> Today xen-fbfront supports specifying the display size via module
> parameters only. Add support for specifying the size via Xenstore in
> order to enable doing this easily via the domain's Xen configuration.
>
> Add an error message in case the configured display size conflicts
> with video memory size.
>
> Signed-off-by: Juergen Gross 

Reviewed-by: Boris Ostrovsky 

lib, fs, cgroup: WARNING in percpu_ref_kill_and_confirm

[Dmitry Vyukov]

Hello,

The following program triggers WARNING in percpu_ref_kill_and_confirm:
https://gist.githubusercontent.com/dvyukov/bcfcef3d6b24b9fd841b88ee20c14d4b/raw/a54aeeb09ad1e0659b0ed87ef5efc4480ab2536f/gistfile1.txt

[ cut here ]
WARNING: CPU: 3 PID: 19987 at lib/percpu-refcount.c:317
percpu_ref_kill_and_confirm+0x303/0x3c0 lib/percpu-refcount.c:316
percpu_ref_kill_and_confirm called more than once on css_release!
CPU: 3 PID: 19987 Comm: a.out Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 panic+0x20c/0x423 kernel/panic.c:180
 __warn+0x1c4/0x1e0 kernel/panic.c:541
 warn_slowpath_fmt+0xc1/0x100 kernel/panic.c:564
 percpu_ref_kill_and_confirm+0x303/0x3c0 lib/percpu-refcount.c:316
 percpu_ref_kill include/linux/percpu-refcount.h:119 [inline]
 cgroup_kill_sb+0x31d/0x480 kernel/cgroup/cgroup.c:1834
 deactivate_locked_super+0x99/0xe0 fs/super.c:309
 deactivate_super+0x151/0x160 fs/super.c:340
 cleanup_mnt+0xb2/0x160 fs/namespace.c:1115
 __cleanup_mnt+0x16/0x20 fs/namespace.c:1122
 task_work_run+0x1a4/0x270 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
RIP: 0033:0x443129
RSP: 002b:7ffe06080018 EFLAGS: 0202 ORIG_RAX: 00a5
RAX: ffec RBX: 004002b0 RCX: 00443129
RDX: 2019cff9 RSI: 2000c000 RDI: 204ff000
RBP: 7ffe06080060 R08: 201db000 R09: 
R10: c084 R11: 0202 R12: 
R13: 004025b0 R14: 00402640 R15: 

On commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae

lib, fs, cgroup: WARNING in percpu_ref_kill_and_confirm

[Dmitry Vyukov]

Hello,

The following program triggers WARNING in percpu_ref_kill_and_confirm:
https://gist.githubusercontent.com/dvyukov/bcfcef3d6b24b9fd841b88ee20c14d4b/raw/a54aeeb09ad1e0659b0ed87ef5efc4480ab2536f/gistfile1.txt

[ cut here ]
WARNING: CPU: 3 PID: 19987 at lib/percpu-refcount.c:317
percpu_ref_kill_and_confirm+0x303/0x3c0 lib/percpu-refcount.c:316
percpu_ref_kill_and_confirm called more than once on css_release!
CPU: 3 PID: 19987 Comm: a.out Not tainted 4.11.0-rc3+ #365
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 panic+0x20c/0x423 kernel/panic.c:180
 __warn+0x1c4/0x1e0 kernel/panic.c:541
 warn_slowpath_fmt+0xc1/0x100 kernel/panic.c:564
 percpu_ref_kill_and_confirm+0x303/0x3c0 lib/percpu-refcount.c:316
 percpu_ref_kill include/linux/percpu-refcount.h:119 [inline]
 cgroup_kill_sb+0x31d/0x480 kernel/cgroup/cgroup.c:1834
 deactivate_locked_super+0x99/0xe0 fs/super.c:309
 deactivate_super+0x151/0x160 fs/super.c:340
 cleanup_mnt+0xb2/0x160 fs/namespace.c:1115
 __cleanup_mnt+0x16/0x20 fs/namespace.c:1122
 task_work_run+0x1a4/0x270 kernel/task_work.c:116
 tracehook_notify_resume include/linux/tracehook.h:191 [inline]
 exit_to_usermode_loop+0x24d/0x2d0 arch/x86/entry/common.c:161
 prepare_exit_to_usermode arch/x86/entry/common.c:191 [inline]
 syscall_return_slowpath+0x3bd/0x460 arch/x86/entry/common.c:260
 entry_SYSCALL_64_fastpath+0xc0/0xc2
RIP: 0033:0x443129
RSP: 002b:7ffe06080018 EFLAGS: 0202 ORIG_RAX: 00a5
RAX: ffec RBX: 004002b0 RCX: 00443129
RDX: 2019cff9 RSI: 2000c000 RDI: 204ff000
RBP: 7ffe06080060 R08: 201db000 R09: 
R10: c084 R11: 0202 R12: 
R13: 004025b0 R14: 00402640 R15: 

On commit 093b995e3b55a0ae0670226ddfcb05bfbf0099ae

loop: WARNING in sysfs_remove_group

[Dmitry Vyukov]

Hello,

I've got the following WARNING while running syzkaller on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure, most likely it's the root cause.

FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 3 PID: 21172 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
 kmem_cache_zalloc include/linux/slab.h:653 [inline]
 __kernfs_new_node+0xd1/0x430 fs/kernfs/dir.c:629
 kernfs_new_node+0x80/0xf0 fs/kernfs/dir.c:661
 kernfs_create_dir_ns+0x41/0x140 fs/kernfs/dir.c:933
 kernfs_create_dir include/linux/kernfs.h:477 [inline]
 internal_create_group+0xf7/0x8f0 fs/sysfs/group.c:124
 sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
 loop_sysfs_init drivers/block/loop.c:802 [inline]
 loop_set_fd drivers/block/loop.c:940 [inline]
 lo_ioctl+0xbbf/0x1670 drivers/block/loop.c:1341
 __blkdev_driver_ioctl block/ioctl.c:297 [inline]
 blkdev_ioctl+0xcf6/0x1f80 block/ioctl.c:594
 block_ioctl+0xde/0x120 fs/block_dev.c:1978
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f8df2ef7858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0006 RSI: 4c00 RDI: 0005
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7f8df2ef7618 R15: 7f8df2ef7788
[ cut here ]
WARNING: CPU: 0 PID: 21188 at fs/sysfs/group.c:237
sysfs_remove_group+0x167/0x1c0 fs/sysfs/group.c:235
sysfs group 'loop' not found for kobject 'loop6'
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 21188 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 panic+0x20c/0x423 kernel/panic.c:180
 __warn+0x1c4/0x1e0 kernel/panic.c:541
 warn_slowpath_fmt+0xc1/0x100 kernel/panic.c:564
 sysfs_remove_group+0x167/0x1c0 fs/sysfs/group.c:235
 loop_sysfs_exit drivers/block/loop.c:808 [inline]
 loop_clr_fd+0x46d/0xa90 drivers/block/loop.c:1055
 lo_ioctl+0x1dc/0x1670 drivers/block/loop.c:1348
 __blkdev_driver_ioctl block/ioctl.c:297 [inline]
 blkdev_ioctl+0xcf6/0x1f80 block/ioctl.c:594
 block_ioctl+0xde/0x120 fs/block_dev.c:1978
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f8df2ed6858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 007080a8 RCX: 00445b79
RDX:  RSI: 4c01 RDI: 0005
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 
R13:  R14: 7f8df2ed79c0 R15: 7f8df2ed7700

loop: WARNING in sysfs_remove_group

[Dmitry Vyukov]

Hello,

I've got the following WARNING while running syzkaller on
093b995e3b55a0ae0670226ddfcb05bfbf0099ae. Note the preceding injected
kmalloc failure, most likely it's the root cause.

FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 3 PID: 21172 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 fail_dump lib/fault-inject.c:45 [inline]
 should_fail+0x78a/0x870 lib/fault-inject.c:154
 should_failslab+0xec/0x120 mm/failslab.c:31
 slab_pre_alloc_hook mm/slab.h:434 [inline]
 slab_alloc mm/slab.c:3394 [inline]
 kmem_cache_alloc+0x200/0x720 mm/slab.c:3570
 kmem_cache_zalloc include/linux/slab.h:653 [inline]
 __kernfs_new_node+0xd1/0x430 fs/kernfs/dir.c:629
 kernfs_new_node+0x80/0xf0 fs/kernfs/dir.c:661
 kernfs_create_dir_ns+0x41/0x140 fs/kernfs/dir.c:933
 kernfs_create_dir include/linux/kernfs.h:477 [inline]
 internal_create_group+0xf7/0x8f0 fs/sysfs/group.c:124
 sysfs_create_group+0x1f/0x30 fs/sysfs/group.c:156
 loop_sysfs_init drivers/block/loop.c:802 [inline]
 loop_set_fd drivers/block/loop.c:940 [inline]
 lo_ioctl+0xbbf/0x1670 drivers/block/loop.c:1341
 __blkdev_driver_ioctl block/ioctl.c:297 [inline]
 blkdev_ioctl+0xcf6/0x1f80 block/ioctl.c:594
 block_ioctl+0xde/0x120 fs/block_dev.c:1978
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f8df2ef7858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 00708000 RCX: 00445b79
RDX: 0006 RSI: 4c00 RDI: 0005
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 004a7e31
R13:  R14: 7f8df2ef7618 R15: 7f8df2ef7788
[ cut here ]
WARNING: CPU: 0 PID: 21188 at fs/sysfs/group.c:237
sysfs_remove_group+0x167/0x1c0 fs/sysfs/group.c:235
sysfs group 'loop' not found for kobject 'loop6'
Kernel panic - not syncing: panic_on_warn set ...

CPU: 0 PID: 21188 Comm: syz-executor4 Not tainted 4.11.0-rc3+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:16 [inline]
 dump_stack+0x1b8/0x28d lib/dump_stack.c:52
 panic+0x20c/0x423 kernel/panic.c:180
 __warn+0x1c4/0x1e0 kernel/panic.c:541
 warn_slowpath_fmt+0xc1/0x100 kernel/panic.c:564
 sysfs_remove_group+0x167/0x1c0 fs/sysfs/group.c:235
 loop_sysfs_exit drivers/block/loop.c:808 [inline]
 loop_clr_fd+0x46d/0xa90 drivers/block/loop.c:1055
 lo_ioctl+0x1dc/0x1670 drivers/block/loop.c:1348
 __blkdev_driver_ioctl block/ioctl.c:297 [inline]
 blkdev_ioctl+0xcf6/0x1f80 block/ioctl.c:594
 block_ioctl+0xde/0x120 fs/block_dev.c:1978
 vfs_ioctl fs/ioctl.c:45 [inline]
 do_vfs_ioctl+0x1af/0x16d0 fs/ioctl.c:685
 SYSC_ioctl fs/ioctl.c:700 [inline]
 SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x445b79
RSP: 002b:7f8df2ed6858 EFLAGS: 0286 ORIG_RAX: 0010
RAX: ffda RBX: 007080a8 RCX: 00445b79
RDX:  RSI: 4c01 RDI: 0005
RBP: 0086 R08:  R09: 
R10:  R11: 0286 R12: 
R13:  R14: 7f8df2ed79c0 R15: 7f8df2ed7700

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[Felix Fietkau]

On 2017-03-23 09:06, Sean Wang wrote:
> Hi Andrew,
> 
> The purpose for the regmap table registered is to 
> 
> provide a way which helps us to look up a specific 
> 
> register on the switch through regmap-debugfs.
> 
> 
> And not all ranges of register is defined
> 
> so I only include the meaningful ones in a sparse way 
> 
> for the table.
I think in that case it might be nice to make regmap support optional in
order to avoid pulling in bloat on platforms that don't need it.

- Felix

Re: [PATCH net-next v2 5/5] net-next: dsa: add dsa support for Mediatek MT7530 switch

[Felix Fietkau]

On 2017-03-23 09:06, Sean Wang wrote:
> Hi Andrew,
> 
> The purpose for the regmap table registered is to 
> 
> provide a way which helps us to look up a specific 
> 
> register on the switch through regmap-debugfs.
> 
> 
> And not all ranges of register is defined
> 
> so I only include the meaningful ones in a sparse way 
> 
> for the table.
I think in that case it might be nice to make regmap support optional in
order to avoid pulling in bloat on platforms that don't need it.

- Felix

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

[Steven Rostedt]

On Thu, 23 Mar 2017 19:36:51 +0900
Byungchul Park  wrote:

> On Thu, Mar 23, 2017 at 10:44:45AM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote:  
> > > It would be better to avoid pushing tasks to other cpu within
> > > a SD_PREFER_SIBLING domain, instead, get more chances to check
> > > other siblings.  
> > 
> > Did you forget to post the rt equivalent to patch 1?  
> 
> No. Fortunately, rt currently works as patch 1 does.

I'm thinking that the rt and deadline search for lowest rq functions
should be merged as one.

What they are doing is looking for the rq with the lowest priority.
deadline currently doesn't care if it picks an rq with an rt task
running on it, even when there's an rq with no rt tasks that the dl task
can migrate to. The same goes with rt. It could place an RT task on an
rq running a deadline task without knowing the rt task wont be able to
run on that cpu immediately.

-- Steve

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

[Steven Rostedt]

On Thu, 23 Mar 2017 19:36:51 +0900
Byungchul Park  wrote:

> On Thu, Mar 23, 2017 at 10:44:45AM +0100, Peter Zijlstra wrote:
> > On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote:  
> > > It would be better to avoid pushing tasks to other cpu within
> > > a SD_PREFER_SIBLING domain, instead, get more chances to check
> > > other siblings.  
> > 
> > Did you forget to post the rt equivalent to patch 1?  
> 
> No. Fortunately, rt currently works as patch 1 does.

I'm thinking that the rt and deadline search for lowest rq functions
should be merged as one.

What they are doing is looking for the rq with the lowest priority.
deadline currently doesn't care if it picks an rq with an rt task
running on it, even when there's an rq with no rt tasks that the dl task
can migrate to. The same goes with rt. It could place an RT task on an
rq running a deadline task without knowing the rt task wont be able to
run on that cpu immediately.

-- Steve

Re: [PATCH v5] KVM: VMX: Fix enable VPID conditions

[David Hildenbrand]

> - if (!cpu_has_vmx_vpid())
> + if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
> + !(cpu_has_vmx_invvpid_single() || cpu_has_vmx_invvpid_global()))

I still don't like this way of indentation, but looks like I am the only
one complaining :)

So I think this patch is just fine now.

>   enable_vpid = 0;
> +
>   if (!cpu_has_vmx_shadow_vmcs())
>   enable_shadow_vmcs = 0;
>   if (enable_shadow_vmcs)
> 


-- 

Thanks,

David

Re: [PATCH v5] KVM: VMX: Fix enable VPID conditions

[David Hildenbrand]

> - if (!cpu_has_vmx_vpid())
> + if (!cpu_has_vmx_vpid() || !cpu_has_vmx_invvpid() ||
> + !(cpu_has_vmx_invvpid_single() || cpu_has_vmx_invvpid_global()))

I still don't like this way of indentation, but looks like I am the only
one complaining :)

So I think this patch is just fine now.

>   enable_vpid = 0;
> +
>   if (!cpu_has_vmx_shadow_vmcs())
>   enable_shadow_vmcs = 0;
>   if (enable_shadow_vmcs)
> 


-- 

Thanks,

David

Re: [PATCH v3] refcount: add refcount_t API kernel-doc comments

[Kees Cook]

On Thu, Mar 23, 2017 at 12:40 AM, Ingo Molnar  wrote:
>
> * Kees Cook  wrote:
>
>> On Fri, Mar 10, 2017 at 7:34 AM, David Windsor  wrote:
>> > v3: rebase against latest Linus tree; re-add include/linux/refcount.h
>> > missing from v2 series
>> >
>> > Signed-off-by: David Windsor 
>>
>> Reviewed-by: Kees Cook 
>>
>> Ingo, can you pull this into tip? I like having more documentation here. :)
>
> So I hopped into my time machine and applied it to tip:locking/core as of 
> March
> 13th:
>
>   commit bd174169c7a12a37b3b4aa2221f084ade010b182
>   Author: David Windsor 
>   AuthorDate: Fri Mar 10 10:34:12 2017 -0500
>   Commit: Ingo Molnar 
>   CommitDate: Mon Mar 13 07:41:08 2017 +0100
>
> You are welcome! ;-)

I love time-travelling maintainers! They are very tolerant of people
who don't double-check -next first. :)

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

Re: [PATCH v3] refcount: add refcount_t API kernel-doc comments

[Kees Cook]

On Thu, Mar 23, 2017 at 12:40 AM, Ingo Molnar  wrote:
>
> * Kees Cook  wrote:
>
>> On Fri, Mar 10, 2017 at 7:34 AM, David Windsor  wrote:
>> > v3: rebase against latest Linus tree; re-add include/linux/refcount.h
>> > missing from v2 series
>> >
>> > Signed-off-by: David Windsor 
>>
>> Reviewed-by: Kees Cook 
>>
>> Ingo, can you pull this into tip? I like having more documentation here. :)
>
> So I hopped into my time machine and applied it to tip:locking/core as of 
> March
> 13th:
>
>   commit bd174169c7a12a37b3b4aa2221f084ade010b182
>   Author: David Windsor 
>   AuthorDate: Fri Mar 10 10:34:12 2017 -0500
>   Commit: Ingo Molnar 
>   CommitDate: Mon Mar 13 07:41:08 2017 +0100
>
> You are welcome! ;-)

I love time-travelling maintainers! They are very tolerant of people
who don't double-check -next first. :)

Thanks!

-Kees

-- 
Kees Cook
Pixel Security

[PATCH] sched/completions: use true/false for bool returns

[Nicholas Mc Guire]

Use true/false for bool rather than 1|0 both in the code and the 
documentation

Signed-off-by: Nicholas Mc Guire <der.h...@hofr.at>
---

Found by coccinelle: boolreturn.cocci complains about
./kernel/sched/completion.c:281:9-10: WARNING: return of 0/1 in function 
'try_wait_for_completion' with return type bool
in addition the int type should also be a bool here and assigned 
appropriately along with fixing up the documentation.
completion_done() was using true/false but the header still was showing
0|1 - so fix up the header to reflect the bool type there as well.

Patch was compile tested with: x86_64_defconfig

Patch is against 4.11-rc3 (localversion-next is next-20170323)

 kernel/sched/completion.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index 53f9558..ef92b15 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -258,8 +258,8 @@ EXPORT_SYMBOL(wait_for_completion_killable_timeout);
  * try_wait_for_completion - try to decrement a completion without blocking
  * @x: completion structure
  *
- * Return: 0 if a decrement cannot be done without blocking
- *  1 if a decrement succeeded.
+ * Return: false if a decrement cannot be done without blocking
+ *  true if a decrement succeeded.
  *
  * If a completion is being used as a counting completion,
  * attempt to decrement the counter without blocking. This
@@ -269,7 +269,7 @@ EXPORT_SYMBOL(wait_for_completion_killable_timeout);
 bool try_wait_for_completion(struct completion *x)
 {
unsigned long flags;
-   int ret = 1;
+   bool ret = true;
 
/*
 * Since x->done will need to be locked only
@@ -278,11 +278,11 @@ bool try_wait_for_completion(struct completion *x)
 * return early in the blocking case.
 */
if (!READ_ONCE(x->done))
-   return 0;
+   return false;
 
spin_lock_irqsave(>wait.lock, flags);
if (!x->done)
-   ret = 0;
+   ret = false;
else if (x->done != UINT_MAX)
x->done--;
spin_unlock_irqrestore(>wait.lock, flags);
@@ -294,8 +294,8 @@ EXPORT_SYMBOL(try_wait_for_completion);
  * completion_done - Test to see if a completion has any waiters
  * @x: completion structure
  *
- * Return: 0 if there are waiters (wait_for_completion() in progress)
- *  1 if there are no waiters.
+ * Return: false if there are waiters (wait_for_completion() in progress)
+ *  true if there are no waiters.
  *
  */
 bool completion_done(struct completion *x)
-- 
2.1.4

[PATCH] sched/completions: use true/false for bool returns

[Nicholas Mc Guire]

Use true/false for bool rather than 1|0 both in the code and the 
documentation

Signed-off-by: Nicholas Mc Guire 
---

Found by coccinelle: boolreturn.cocci complains about
./kernel/sched/completion.c:281:9-10: WARNING: return of 0/1 in function 
'try_wait_for_completion' with return type bool
in addition the int type should also be a bool here and assigned 
appropriately along with fixing up the documentation.
completion_done() was using true/false but the header still was showing
0|1 - so fix up the header to reflect the bool type there as well.

Patch was compile tested with: x86_64_defconfig

Patch is against 4.11-rc3 (localversion-next is next-20170323)

 kernel/sched/completion.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/completion.c b/kernel/sched/completion.c
index 53f9558..ef92b15 100644
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -258,8 +258,8 @@ EXPORT_SYMBOL(wait_for_completion_killable_timeout);
  * try_wait_for_completion - try to decrement a completion without blocking
  * @x: completion structure
  *
- * Return: 0 if a decrement cannot be done without blocking
- *  1 if a decrement succeeded.
+ * Return: false if a decrement cannot be done without blocking
+ *  true if a decrement succeeded.
  *
  * If a completion is being used as a counting completion,
  * attempt to decrement the counter without blocking. This
@@ -269,7 +269,7 @@ EXPORT_SYMBOL(wait_for_completion_killable_timeout);
 bool try_wait_for_completion(struct completion *x)
 {
unsigned long flags;
-   int ret = 1;
+   bool ret = true;
 
/*
 * Since x->done will need to be locked only
@@ -278,11 +278,11 @@ bool try_wait_for_completion(struct completion *x)
 * return early in the blocking case.
 */
if (!READ_ONCE(x->done))
-   return 0;
+   return false;
 
spin_lock_irqsave(>wait.lock, flags);
if (!x->done)
-   ret = 0;
+   ret = false;
else if (x->done != UINT_MAX)
x->done--;
spin_unlock_irqrestore(>wait.lock, flags);
@@ -294,8 +294,8 @@ EXPORT_SYMBOL(try_wait_for_completion);
  * completion_done - Test to see if a completion has any waiters
  * @x: completion structure
  *
- * Return: 0 if there are waiters (wait_for_completion() in progress)
- *  1 if there are no waiters.
+ * Return: false if there are waiters (wait_for_completion() in progress)
+ *  true if there are no waiters.
  *
  */
 bool completion_done(struct completion *x)
-- 
2.1.4

[PATCH V2] hangcheck-timer: Fix typo in comment

[Zhang, Shile (Nokia - CN/Hangzhou)]

Correct patch for the typo.
Sorry for I sent first patch w/o commit log and second patch with incorrect fix.
Thanks!

Fix the typo "alloted" -> "allotted" in comment.

Signed-off-by: Shile Zhang 
---
 drivers/char/hangcheck-timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c
index 4f33737..5406b90 100644
--- a/drivers/char/hangcheck-timer.c
+++ b/drivers/char/hangcheck-timer.c
@@ -32,7 +32,7 @@
  * timer and 180 seconds for the margin of error.  IOW, a timer is set
  * for 60 seconds.  When the timer fires, the callback checks the
  * actual duration that the timer waited.  If the duration exceeds the
- * alloted time and margin (here 60 + 180, or 240 seconds), the machine
+ * allotted time and margin (here 60 + 180, or 240 seconds), the machine
  * is restarted.  A healthy machine will have the duration match the
  * expected timeout very closely.
  */
-- 
2.6.2

[PATCH V2] hangcheck-timer: Fix typo in comment

[Zhang, Shile (Nokia - CN/Hangzhou)]

Correct patch for the typo.
Sorry for I sent first patch w/o commit log and second patch with incorrect fix.
Thanks!

Fix the typo "alloted" -> "allotted" in comment.

Signed-off-by: Shile Zhang 
---
 drivers/char/hangcheck-timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c
index 4f33737..5406b90 100644
--- a/drivers/char/hangcheck-timer.c
+++ b/drivers/char/hangcheck-timer.c
@@ -32,7 +32,7 @@
  * timer and 180 seconds for the margin of error.  IOW, a timer is set
  * for 60 seconds.  When the timer fires, the callback checks the
  * actual duration that the timer waited.  If the duration exceeds the
- * alloted time and margin (here 60 + 180, or 240 seconds), the machine
+ * allotted time and margin (here 60 + 180, or 240 seconds), the machine
  * is restarted.  A healthy machine will have the duration match the
  * expected timeout very closely.
  */
-- 
2.6.2

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

[Daniel Vetter]

On Thu, Mar 23, 2017 at 12:01:30PM +, Daniel Stone wrote:
> Hi Michel,
> 
> On 23 March 2017 at 08:53, Michel Dänzer  wrote:
> > Otherwise this can also prevent modesets e.g. for switching VTs, when
> > multiple monitors with different native resolutions are connected.
> >
> > The depths must match though, so keep the != test for that.
> >
> > Also update the DRM_DEBUG output to be slightly more accurate, this
> > doesn't only affect requests from userspace.
> 
> This test looks much more sensible, and also fixes VT switching for me.
> 
> Reviewed-by: Daniel Stone 

Applied to drm-misc-fixes, will send a pull request for it asap.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH] drm/fb-helper: Allow var->x/yres(_virtual) < fb->width/height again

[Daniel Vetter]

On Thu, Mar 23, 2017 at 12:01:30PM +, Daniel Stone wrote:
> Hi Michel,
> 
> On 23 March 2017 at 08:53, Michel Dänzer  wrote:
> > Otherwise this can also prevent modesets e.g. for switching VTs, when
> > multiple monitors with different native resolutions are connected.
> >
> > The depths must match though, so keep the != test for that.
> >
> > Also update the DRM_DEBUG output to be slightly more accurate, this
> > doesn't only affect requests from userspace.
> 
> This test looks much more sensible, and also fixes VT switching for me.
> 
> Reviewed-by: Daniel Stone 

Applied to drm-misc-fixes, will send a pull request for it asap.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

[Steven Rostedt]

On Thu, 23 Mar 2017 18:21:23 +0900
Byungchul Park  wrote:

> On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote:
> > It would be better to avoid pushing tasks to other cpu within
> > a SD_PREFER_SIBLING domain, instead, get more chances to check other
> > siblings.  
> 
> +cc ghask...@novell.com
> +cc srost...@redhat.com
> 

Neither of us work at those companies anymore.

-- Steve

Re: [PATCH v3 3/3] sched/rt: Add support for SD_PREFER_SIBLING on find_lowest_rq()

[Steven Rostedt]

On Thu, 23 Mar 2017 18:21:23 +0900
Byungchul Park  wrote:

> On Thu, Mar 23, 2017 at 11:12:49AM +0900, Byungchul Park wrote:
> > It would be better to avoid pushing tasks to other cpu within
> > a SD_PREFER_SIBLING domain, instead, get more chances to check other
> > siblings.  
> 
> +cc ghask...@novell.com
> +cc srost...@redhat.com
> 

Neither of us work at those companies anymore.

-- Steve

Re: [PATCH 15/15] i2c-cht-wc: Add Intel Cherry Trail Whiskey Cove SMBUS controller driver

[Hans de Goede]

Hi,

On 17-03-17 19:22, Andy Shevchenko wrote:

On Fri, 2017-03-17 at 10:55 +0100, Hans de Goede wrote:

The Intel Cherry Trail Whiskey Cove PMIC has a builtin SMBUS
controller
for talking to an external PMIC. Add a driver for this.


Looking to all this mess we have with PMICs, perhaps some file under
Documentation to explain all those dependencies with nice ASCII flow
charts would be created.


With Sebastian's suggestion to turn the fuel-gauge driver
into a full-blown power_supply driver things luckily aren't
quite that messy anymore.




+#define CHT_WC_I2C_CTRL0x5e24
+#define CHT_WC_I2C_CTRL_WR BIT(0)
+#define CHT_WC_I2C_CTRL_RD BIT(1)
+#define CHT_WC_I2C_CLIENT_ADDR 0x5e25
+#define CHT_WC_I2C_REG_OFFSET  0x5e26
+#define CHT_WC_I2C_WRDATA  0x5e27
+#define CHT_WC_I2C_RDDATA  0x5e28
+
+#define CHT_WC_EXTCHGRIRQ  0x6e0a
+#define CHT_WC_EXTCHGRIRQ_CLIENT_IRQ   BIT(0)
+#define CHT_WC_EXTCHGRIRQ_WRITE_IRQBIT(1)
+#define CHT_WC_EXTCHGRIRQ_READ_IRQ BIT(2)
+#define CHT_WC_EXTCHGRIRQ_NACK_IRQ BIT(3)




+#define CHT_WC_EXTCHGRIRQ_ADAP_IRQS((u8)(BIT(1) | BIT(2) |
BIT(3)))


_IRQ_MASK ?

GENMASK() ?


Both good idea, both fixed for v2. Note I'm not posting
v2 until the bq24190_charger patches are in place
(so that the device-properties to use are known).


+#define CHT_WC_EXTCHGRIRQ_MSK  0x6e17



+struct cht_wc_i2c_adap {
+   struct i2c_adapter adapter;
+   wait_queue_head_t wait;
+   struct irq_chip irqchip;
+   struct mutex irqchip_lock;
+   struct regmap *regmap;
+   struct irq_domain *irq_domain;
+   struct i2c_client *client;
+   int client_irq;
+   u8 irq_mask;
+   u8 old_irq_mask;
+   bool nack;
+   bool done;
+};
+
+static irqreturn_t cht_wc_i2c_adap_thread_handler(int id, void *data)
+{
+   struct cht_wc_i2c_adap *adap = data;
+   int ret, reg;
+
+   /* Read irqs */


IRQs


+   ret = regmap_read(adap->regmap, CHT_WC_EXTCHGRIRQ, );
+   if (ret) {
+   dev_err(>adapter.dev, "Error reading extchgrirq
reg\n");
+   return IRQ_NONE;
+   }
+
+   reg &= ~adap->irq_mask;
+
+   /*
+* Immediately ack irqs, so that if new irqs arrives while
we're
+* handling the previous ones our irq will re-trigger when
we're done.
+*/
+   ret = regmap_write(adap->regmap, CHT_WC_EXTCHGRIRQ, reg);
+   if (ret)
+   dev_err(>adapter.dev, "Error writing extchgrirq
reg\n");
+
+   /*
+* Do NOT use handle_nested_irq here, the client irq handler
will
+* likely want to do i2c transfers and the i2c controller
uses this
+* interrupt handler as well, so running the client irq
handler from
+* this thread will cause things to lock up.
+*/
+   if (reg & CHT_WC_EXTCHGRIRQ_CLIENT_IRQ) {
+   /*
+* generic_handle_irq expects local irqs to be
disabled
+* as normally it is called from interrupt context.
+*/
+   local_irq_disable();
+   generic_handle_irq(adap->client_irq);
+   local_irq_enable();
+   }
+
+   if (reg & CHT_WC_EXTCHGRIRQ_ADAP_IRQS) {



+   if (reg & CHT_WC_EXTCHGRIRQ_NACK_IRQ)
+   adap->nack = true;


adap->nack = !!(reg & ...);


Good idea, fixed for v2.




+   adap->done = true;
+   wake_up(>wait);
+   }
+
+   return IRQ_HANDLED;
+}



+static u32 cht_wc_i2c_adap_master_func(struct i2c_adapter *adap)
+{
+   /* This i2c adapter only supports smbus byte transfers */


smbus -> SMBUS


+   return I2C_FUNC_SMBUS_BYTE_DATA;
+}
+
+static int cht_wc_i2c_adap_smbus_xfer(struct i2c_adapter *_adap, u16
addr,
+ unsigned short flags, char
read_write,
+ u8 command, int size,
+ union i2c_smbus_data *data)
+{
+   struct cht_wc_i2c_adap *adap = i2c_get_adapdata(_adap);
+   int ret, reg;
+



+
+   /* 3 second timeout, during cable plug the PMIC responds
quite slow */
+   ret = wait_event_timeout(adap->wait, adap->done, HZ * 3);


3 * HZ


Fixed for v2 (as well as all the capitalization remarks)




+   if (ret == 0)
+   return -ETIMEDOUT;
+   if (adap->nack)
+   return -EIO;
+
+   if (read_write == I2C_SMBUS_READ) {
+   ret = regmap_read(adap->regmap, CHT_WC_I2C_RDDATA,
);
+   if (ret)
+   return ret;
+
+   data->byte = reg;
+   }
+
+   return 0;
+}



+/ irqchip for the client connected to the extchgr i2c adapter
/


Useless ?


It is meant as a visual separator between the i2c-adapter and
irqchip code.




+static void cht_wc_i2c_irq_lock(struct irq_data *data)
+{
+   struct cht_wc_i2c_adap *adap =

Re: [PATCH 15/15] i2c-cht-wc: Add Intel Cherry Trail Whiskey Cove SMBUS controller driver

[Hans de Goede]

Hi,

On 17-03-17 19:22, Andy Shevchenko wrote:

On Fri, 2017-03-17 at 10:55 +0100, Hans de Goede wrote:

The Intel Cherry Trail Whiskey Cove PMIC has a builtin SMBUS
controller
for talking to an external PMIC. Add a driver for this.


Looking to all this mess we have with PMICs, perhaps some file under
Documentation to explain all those dependencies with nice ASCII flow
charts would be created.


With Sebastian's suggestion to turn the fuel-gauge driver
into a full-blown power_supply driver things luckily aren't
quite that messy anymore.




+#define CHT_WC_I2C_CTRL0x5e24
+#define CHT_WC_I2C_CTRL_WR BIT(0)
+#define CHT_WC_I2C_CTRL_RD BIT(1)
+#define CHT_WC_I2C_CLIENT_ADDR 0x5e25
+#define CHT_WC_I2C_REG_OFFSET  0x5e26
+#define CHT_WC_I2C_WRDATA  0x5e27
+#define CHT_WC_I2C_RDDATA  0x5e28
+
+#define CHT_WC_EXTCHGRIRQ  0x6e0a
+#define CHT_WC_EXTCHGRIRQ_CLIENT_IRQ   BIT(0)
+#define CHT_WC_EXTCHGRIRQ_WRITE_IRQBIT(1)
+#define CHT_WC_EXTCHGRIRQ_READ_IRQ BIT(2)
+#define CHT_WC_EXTCHGRIRQ_NACK_IRQ BIT(3)




+#define CHT_WC_EXTCHGRIRQ_ADAP_IRQS((u8)(BIT(1) | BIT(2) |
BIT(3)))


_IRQ_MASK ?

GENMASK() ?


Both good idea, both fixed for v2. Note I'm not posting
v2 until the bq24190_charger patches are in place
(so that the device-properties to use are known).


+#define CHT_WC_EXTCHGRIRQ_MSK  0x6e17



+struct cht_wc_i2c_adap {
+   struct i2c_adapter adapter;
+   wait_queue_head_t wait;
+   struct irq_chip irqchip;
+   struct mutex irqchip_lock;
+   struct regmap *regmap;
+   struct irq_domain *irq_domain;
+   struct i2c_client *client;
+   int client_irq;
+   u8 irq_mask;
+   u8 old_irq_mask;
+   bool nack;
+   bool done;
+};
+
+static irqreturn_t cht_wc_i2c_adap_thread_handler(int id, void *data)
+{
+   struct cht_wc_i2c_adap *adap = data;
+   int ret, reg;
+
+   /* Read irqs */


IRQs


+   ret = regmap_read(adap->regmap, CHT_WC_EXTCHGRIRQ, );
+   if (ret) {
+   dev_err(>adapter.dev, "Error reading extchgrirq
reg\n");
+   return IRQ_NONE;
+   }
+
+   reg &= ~adap->irq_mask;
+
+   /*
+* Immediately ack irqs, so that if new irqs arrives while
we're
+* handling the previous ones our irq will re-trigger when
we're done.
+*/
+   ret = regmap_write(adap->regmap, CHT_WC_EXTCHGRIRQ, reg);
+   if (ret)
+   dev_err(>adapter.dev, "Error writing extchgrirq
reg\n");
+
+   /*
+* Do NOT use handle_nested_irq here, the client irq handler
will
+* likely want to do i2c transfers and the i2c controller
uses this
+* interrupt handler as well, so running the client irq
handler from
+* this thread will cause things to lock up.
+*/
+   if (reg & CHT_WC_EXTCHGRIRQ_CLIENT_IRQ) {
+   /*
+* generic_handle_irq expects local irqs to be
disabled
+* as normally it is called from interrupt context.
+*/
+   local_irq_disable();
+   generic_handle_irq(adap->client_irq);
+   local_irq_enable();
+   }
+
+   if (reg & CHT_WC_EXTCHGRIRQ_ADAP_IRQS) {



+   if (reg & CHT_WC_EXTCHGRIRQ_NACK_IRQ)
+   adap->nack = true;


adap->nack = !!(reg & ...);


Good idea, fixed for v2.




+   adap->done = true;
+   wake_up(>wait);
+   }
+
+   return IRQ_HANDLED;
+}



+static u32 cht_wc_i2c_adap_master_func(struct i2c_adapter *adap)
+{
+   /* This i2c adapter only supports smbus byte transfers */


smbus -> SMBUS


+   return I2C_FUNC_SMBUS_BYTE_DATA;
+}
+
+static int cht_wc_i2c_adap_smbus_xfer(struct i2c_adapter *_adap, u16
addr,
+ unsigned short flags, char
read_write,
+ u8 command, int size,
+ union i2c_smbus_data *data)
+{
+   struct cht_wc_i2c_adap *adap = i2c_get_adapdata(_adap);
+   int ret, reg;
+



+
+   /* 3 second timeout, during cable plug the PMIC responds
quite slow */
+   ret = wait_event_timeout(adap->wait, adap->done, HZ * 3);


3 * HZ


Fixed for v2 (as well as all the capitalization remarks)




+   if (ret == 0)
+   return -ETIMEDOUT;
+   if (adap->nack)
+   return -EIO;
+
+   if (read_write == I2C_SMBUS_READ) {
+   ret = regmap_read(adap->regmap, CHT_WC_I2C_RDDATA,
);
+   if (ret)
+   return ret;
+
+   data->byte = reg;
+   }
+
+   return 0;
+}



+/ irqchip for the client connected to the extchgr i2c adapter
/


Useless ?


It is meant as a visual separator between the i2c-adapter and
irqchip code.




+static void cht_wc_i2c_irq_lock(struct irq_data *data)
+{
+   struct cht_wc_i2c_adap *adap =

Re: [PATCH v3 0/5] ATA/ARM: convert ARM/DaVinci to use libata PATA drivers

[Sekhar Nori]

On Wednesday 22 March 2017 11:50 PM, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patchset adds Palmchip BK3710 IDE controller driver to
> libata and switches ARM/DaVinci to use it (instead of the old
> IDE driver).
> 
> Sekhar, please check that it still works after changes, thanks.

Did some basic mount/read/write tests, it passed.

Thanks,
Sekhar

Re: perf_callchain_user oops

[Dave Jones]

On Thu, Mar 23, 2017 at 10:40:22AM +0100, Peter Zijlstra wrote:
 > On Wed, Mar 22, 2017 at 10:58:04PM -0400, Dave Jones wrote:
 > > Not seen this one before..
 > > 
 > > Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
 > 
 > That's a write fault reaching no_context() afaict.
 > 
 > > CPU: 1 PID: 24420 Comm: trinity-main Not tainted 4.11.0-rc3-think+ #3 
 > > task: 8804f4c85440 task.stack: c90001d38000
 > > RIP: 0010:perf_callchain_user+0x11e/0x220
 > > RSP: :c90001d3ba98 EFLAGS: 00010246
 > > RAX: 88044c59c2a8 RBX: c90001d3bae8 RCX: 562bce3f6e40
 > > RDX: 562bce3f6e40 RSI: 7fffeff0 RDI: 
 > > RBP: c90001d3bab8 R08: bff0 R09: dff0
 > > R10: 2faa R11: 2fab R12: 8804f4c85440
 > > R13: c90001d3bf58 R14: c90001d3bf58 R15: 
 > > FS:  7f34b3969b40() GS:880507a0() 
 > > knlGS:
 > > CS:  0010 DS:  ES:  CR0: 80050033
 > > CR2: 88044c5b4000 CR3: 00044c584000 CR4: 001406e0
 > > DR0: 7f34b382e000 DR1:  DR2: 
 > > DR3:  DR6: 0ff0 DR7: 0600
 > > Call Trace:
 > >  get_perf_callchain+0x258/0x2b0
 > >  perf_callchain+0x79/0x80
 > >  perf_prepare_sample+0x27e/0x360
 > >  perf_event_output_forward+0x75/0x160
 > 
 > Any chance you could run scripts/faddr2line on this output?
 > 
 > I cannot seem to match the Code with a defconfig build of that function.

$ scripts/faddr2line arch/x86/events/core.o  perf_callchain_user+0x11e 
perf_callchain_user+0x11e/0x220:
perf_callchain_store at include/linux/perf_event.h:1148
 (inlined by) perf_callchain_user at arch/x86/events/core.c:2444

$ scripts/faddr2line kernel/events/callchain.o get_perf_callchain+0x258/0x2b0 
perf_callchain+0x79/0x80 
get_perf_callchain+0x258/0x2b0:
get_perf_callchain at kernel/events/callchain.c:237

perf_callchain+0x79/0x80:
perf_callchain at kernel/events/callchain.c:194

$ scripts/faddr2line kernel/events/core.o perf_prepare_sample+0x27e/0x360
perf_prepare_sample+0x27e/0x360:
perf_prepare_sample at kernel/events/core.c:5991

$ scripts/faddr2line kernel/events/core.o perf_event_output_forward+0x75/0x160
perf_event_output_forward+0x75/0x160:
__perf_event_output at kernel/events/core.c:6104
 (inlined by) perf_event_output_forward at kernel/events/core.c:6120

Re: [PATCH v3 0/5] ATA/ARM: convert ARM/DaVinci to use libata PATA drivers

[Sekhar Nori]

On Wednesday 22 March 2017 11:50 PM, Bartlomiej Zolnierkiewicz wrote:
> Hi,
> 
> This patchset adds Palmchip BK3710 IDE controller driver to
> libata and switches ARM/DaVinci to use it (instead of the old
> IDE driver).
> 
> Sekhar, please check that it still works after changes, thanks.

Did some basic mount/read/write tests, it passed.

Thanks,
Sekhar

Re: perf_callchain_user oops

[Dave Jones]

On Thu, Mar 23, 2017 at 10:40:22AM +0100, Peter Zijlstra wrote:
 > On Wed, Mar 22, 2017 at 10:58:04PM -0400, Dave Jones wrote:
 > > Not seen this one before..
 > > 
 > > Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC
 > 
 > That's a write fault reaching no_context() afaict.
 > 
 > > CPU: 1 PID: 24420 Comm: trinity-main Not tainted 4.11.0-rc3-think+ #3 
 > > task: 8804f4c85440 task.stack: c90001d38000
 > > RIP: 0010:perf_callchain_user+0x11e/0x220
 > > RSP: :c90001d3ba98 EFLAGS: 00010246
 > > RAX: 88044c59c2a8 RBX: c90001d3bae8 RCX: 562bce3f6e40
 > > RDX: 562bce3f6e40 RSI: 7fffeff0 RDI: 
 > > RBP: c90001d3bab8 R08: bff0 R09: dff0
 > > R10: 2faa R11: 2fab R12: 8804f4c85440
 > > R13: c90001d3bf58 R14: c90001d3bf58 R15: 
 > > FS:  7f34b3969b40() GS:880507a0() 
 > > knlGS:
 > > CS:  0010 DS:  ES:  CR0: 80050033
 > > CR2: 88044c5b4000 CR3: 00044c584000 CR4: 001406e0
 > > DR0: 7f34b382e000 DR1:  DR2: 
 > > DR3:  DR6: 0ff0 DR7: 0600
 > > Call Trace:
 > >  get_perf_callchain+0x258/0x2b0
 > >  perf_callchain+0x79/0x80
 > >  perf_prepare_sample+0x27e/0x360
 > >  perf_event_output_forward+0x75/0x160
 > 
 > Any chance you could run scripts/faddr2line on this output?
 > 
 > I cannot seem to match the Code with a defconfig build of that function.

$ scripts/faddr2line arch/x86/events/core.o  perf_callchain_user+0x11e 
perf_callchain_user+0x11e/0x220:
perf_callchain_store at include/linux/perf_event.h:1148
 (inlined by) perf_callchain_user at arch/x86/events/core.c:2444

$ scripts/faddr2line kernel/events/callchain.o get_perf_callchain+0x258/0x2b0 
perf_callchain+0x79/0x80 
get_perf_callchain+0x258/0x2b0:
get_perf_callchain at kernel/events/callchain.c:237

perf_callchain+0x79/0x80:
perf_callchain at kernel/events/callchain.c:194

$ scripts/faddr2line kernel/events/core.o perf_prepare_sample+0x27e/0x360
perf_prepare_sample+0x27e/0x360:
perf_prepare_sample at kernel/events/core.c:5991

$ scripts/faddr2line kernel/events/core.o perf_event_output_forward+0x75/0x160
perf_event_output_forward+0x75/0x160:
__perf_event_output at kernel/events/core.c:6104
 (inlined by) perf_event_output_forward at kernel/events/core.c:6120