Re: [PATCH] extcon: usb-gpio: Add VBUS detection support

2016-09-26 Thread Peter Chen
On Tue, Sep 20, 2016 at 05:53:55PM +0300, Roger Quadros wrote:
> Driver can now work with both ID and VBUS pins or either one of
> them.
> 
> There can be the following 3 cases
> 
> 1) Both ID and VBUS GPIOs are available:
> 
> ID = LOW -> USB_HOST active, USB inactive
> ID = HIGH -> USB_HOST inactive, USB state is same as VBUS.
> 
> 2) Only ID GPIO is available:
> 
> ID = LOW -> USB_HOST active, USB inactive
> ID = HIGH -> USB_HOST inactive, USB active
> 
> 3) Only VBUS GPIO is available:
> 
> VBUS = LOW -> USB_HOST inactive, USB inactive
> VBUS = HIGH -> USB_HOST inactive, USB active
> 
> Signed-off-by: Roger Quadros 
> ---
>  .../devicetree/bindings/extcon/extcon-usb-gpio.txt |   3 +
>  drivers/extcon/extcon-usb-gpio.c   | 169 
> -
>  2 files changed, 132 insertions(+), 40 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt 
> b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> index af0b903..dfc14f7 100644
> --- a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> +++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
> @@ -5,7 +5,10 @@ connected to a GPIO pin.
>  
>  Required properties:
>  - compatible: Should be "linux,extcon-usb-gpio"
> +
> +Either one of id-gpio or vbus-gpio must be present. Both can be present as 
> well.
>  - id-gpio: gpio for USB ID pin. See gpio binding.
> +- vbus-gpio: gpio for USB VBUS pin.
>  
>  Example: Examples of extcon-usb-gpio node in dra7-evm.dts as listed below:
>   extcon_usb1 {
> diff --git a/drivers/extcon/extcon-usb-gpio.c 
> b/drivers/extcon/extcon-usb-gpio.c
> index a27d350..d589c5f 100644
> --- a/drivers/extcon/extcon-usb-gpio.c
> +++ b/drivers/extcon/extcon-usb-gpio.c
> @@ -24,7 +24,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -36,7 +35,9 @@ struct usb_extcon_info {
>   struct extcon_dev *edev;
>  
>   struct gpio_desc *id_gpiod;
> + struct gpio_desc *vbus_gpiod;
>   int id_irq;
> + int vbus_irq;
>  
>   unsigned long debounce_jiffies;
>   struct delayed_work wq_detcable;
> @@ -48,31 +49,47 @@ static const unsigned int usb_extcon_cable[] = {
>   EXTCON_NONE,
>  };
>  
> +/*
> + * "USB" = VBUS and "USB-HOST" = !ID, so we have:
> + * Both "USB" and "USB-HOST" can't be set as active at the
> + * same time so if "USB-HOST" is active (i.e. ID is 0)  we keep "USB" 
> inactive
> + * even if VBUS is on.
> + *
> + *  State  |ID   |   VBUS
> + * 
> + *  [1] USB|H|H
> + *  [2] none   |H|L
> + *  [3] USB-HOST   |L|H
> + *  [4] USB-HOST   |L|L
> + *
> + * In case we have only one of these signals:
> + * - VBUS only - we want to distinguish between [1] and [2], so ID is always 
> 1.
> + * - ID only - we want to distinguish between [1] and [4], so VBUS = ID.
> +*/
>  static void usb_extcon_detect_cable(struct work_struct *work)
>  {
> - int id;
> + int id, vbus;
>   struct usb_extcon_info *info = container_of(to_delayed_work(work),
>   struct usb_extcon_info,
>   wq_detcable);
>  
> - /* check ID and update cable state */
> - id = gpiod_get_value_cansleep(info->id_gpiod);
> - if (id) {
> - /*
> -  * ID = 1 means USB HOST cable detached.
> -  * As we don't have event for USB peripheral cable attached,
> -  * we simulate USB peripheral attach here.
> -  */
> + /* check ID and VBUS and update cable state */
> + id = info->id_gpiod ?
> + gpiod_get_value_cansleep(info->id_gpiod) : 1;
> + vbus = info->vbus_gpiod ?
> + gpiod_get_value_cansleep(info->vbus_gpiod) : id;
> +
> + /* at first we clean states which are no longer active */
> + if (id)
>   extcon_set_state_sync(info->edev, EXTCON_USB_HOST, false);
> - extcon_set_state_sync(info->edev, EXTCON_USB, true);
> - } else {
> - /*
> -  * ID = 0 means USB HOST cable attached.
> -  * As we don't have event for USB peripheral cable detached,
> -  * we simulate USB peripheral detach here.
> -  */
> + if (!vbus)
>   extcon_set_state_sync(info->edev, EXTCON_USB, false);
> +
> + if (!id) {
>   extcon_set_state_sync(info->edev, EXTCON_USB_HOST, true);
> + } else {
> + if (vbus)
> + extcon_set_state_sync(info->edev, EXTCON_USB, true);
>   }
>  }
>  
> @@ -101,12 +118,21 @@ static int usb_extcon_probe(struct platform_device 
> *pdev)
>   return -ENOMEM;
>  
>   info->dev = dev;
> - info->id_gpiod = devm_gpiod_get(>dev, "id", GPIOD_IN);
> - if (IS_ERR(info->id_gpiod)) {
> - 

Re: linux-next: build failure after merge of the rdma tree

2016-09-26 Thread Stephen Rothwell
Hi Christoph,

On Tue, 27 Sep 2016 07:04:15 +0200 Christoph Hellwig  wrote:
>
> On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote:
> > Hi Doug,
> > 
> > After merging the rdma tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:  
> 
> Please just disable broken staging code like lustre for the linux-next
> builds. We had that discussion before, didn't we?

Yeah, sorry.  Note, however, that you bothered to fix up this same
staging file in another of your patches ...

-- 
Cheers,
Stephen Rothwell


RE: [v6,2/2] QE: remove PPCisms for QE

2016-09-26 Thread Qiang Zhao
On Tue, Sep 27, 2016 at 7:12AM -0500, Scott Wood wrote:

> -Original Message-
> From: Scott Wood [mailto:o...@buserror.net]
> Sent: Tuesday, September 27, 2016 7:12 AM
> To: Qiang Zhao 
> Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie
> ; linux-kernel@vger.kernel.org
> Subject: Re: [v6,2/2] QE: remove PPCisms for QE
> 
> On Mon, 2016-09-26 at 01:46 +, Qiang Zhao wrote:
> > On Sun, Sep 25, 2016 at 12:19PM -0500, Scott Wood wrote:
> >
> > >
> > > -Original Message-
> > > From: Scott Wood [mailto:o...@buserror.net]
> > > Sent: Sunday, September 25, 2016 12:19 PM
> > > To: Qiang Zhao 
> > > Cc: linuxppc-...@lists.ozlabs.org; pku@gmail.com; X.B. Xie
> > > ; linux-kernel@vger.kernel.org
> > > Subject: Re: [v6,2/2] QE: remove PPCisms for QE
> > >
> > > On Sat, Sep 24, 2016 at 11:14:11PM -0500, Scott Wood wrote:
> > > >
> > > > On Fri, Sep 23, 2016 at 10:20:32AM +0800, Zhao Qiang wrote:
> > > > >
> > > > > QE was supported on PowerPC, and dependent on PPC, Now it is
> > > > > supported on other platforms. so remove PPCisms.
> > > > >
> > > > > Signed-off-by: Zhao Qiang 
> > > > > ---
> > > > > Changes for v2:
> > > > >   - na
> > > > > Changes for v3:
> > > > >   - add NO_IRQ
> > > > > Changes for v4:
> > > > >   - modify spin_event_timeout to opencoded timeout loop
> > > > >   - remove NO_IRQ
> > > > >   - modify virq_to_hw to opencoed code Changes for v5:
> > > > >   - modify commit msg
> > > > >   - modify depends of QUICC_ENGINE
> > > > >   - add kerneldoc header for qe_issue_cmd Changes for v6:
> > > > >   - add dependency on FSL_SOC and PPC32 for drivers
> > > > >     depending on QUICC_ENGING but not available on ARM
> > > > >
> > > > >  drivers/irqchip/qe_ic.c| 28 +++-
> > > > >  drivers/net/ethernet/freescale/Kconfig | 10 ++---
> > > > >  drivers/soc/fsl/qe/Kconfig |  2 +-
> > > > >  drivers/soc/fsl/qe/qe.c| 80
> > > > > -
> > > > > -
> > > > >  drivers/soc/fsl/qe/qe_io.c | 42 --
> > > > >  drivers/soc/fsl/qe/qe_tdm.c|  8 ++--
> > > > >  drivers/soc/fsl/qe/ucc.c   | 10 ++---
> > > > >  drivers/soc/fsl/qe/ucc_fast.c  | 68
> > > > > ++---
> > > > > 
> > > > >  drivers/tty/serial/Kconfig |  2 +-
> > > > >  drivers/usb/gadget/udc/Kconfig |  2 +-
> > > > >  drivers/usb/host/Kconfig   |  2 +-
> > > > >  include/soc/fsl/qe/qe.h|  1 -
> > > > >  include/soc/fsl/qe/qe_ic.h | 12 ++---
> > > > >  13 files changed, 141 insertions(+), 126 deletions(-)
> > > > I assume this means you'll be updating
> > > > http://patchwork.ozlabs.org/patch/654473/
> > > > to be based on top of this...
> > > Apparently that assumption was wrong, since I now see that you're
> > > patching drivers/irqchip/qe_ic.c rather than drivers/soc/fsl/qe/qe_ic.c.
> > > Please keep the drivers/irqchip stuff separate and send to the
> > > appropriate maintainers.
> > >
> > You means separate drivers/irqchip/qe_ic.c part from this patch and
> > send it with the other qe_ic patches?
> > Is it acceptable if I modify qe_ic.c with drivers/soc/fsl/qe/qe_ic.c,
> > then send qe_ic patches to move qe_ic to drivers/irqchip?
> 
> I'd recommend against it.  It would complicate getting the drivers/irqchip
> patchset merged.  In any case, it's too late for 4.9.

Ok, thank you for your recommend.

BR
-Zhao Qiang


Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

2016-09-26 Thread SF Markus Elfring
> When you need to make changes to patches that are part of a series,
> you must resubmit the entire series,

I imagine that will happen when the patch review time passed by a bit
more as Paul Bolle requested it yesterday.


> not just the things that are changes.

Thanks for your reminder.

Regards,
Markus


Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

2016-09-26 Thread Krzysztof Hałasa
Andrey Utkin  writes:

>> Does (only) adding the
>> 
>>  pci_read_config_word(solo_dev->pdev, PCI_STATUS, );
>> 
>> in solo_reg_write() help?
>
> Yes.
> I have posted a patch with this change few days ago, I thought you have
> noticed it.

Well, I think you haven't sent me a copy. Anyway, it would be great to
determine where exactly writes need a flush. Adding it everywhere is a
bit suboptimal, one would think.

Can you share some details about the machine you are experiencing the
problems on? CPU, chipset? I'd try to see if I can recreate the problem.

Alternatively, you could investigate yourself - at first you could put
pci_read_config_word() at the end of subroutines (including return
statements) using solo_reg_write(). And in that solo_p2m_dma_desc(),
before wait_for_completion_timeout(). Then eliminate them using some
sort of binary search to see which ones are required.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland


[PATCH 0/3] ARM: dts: omap5 uevm: add LEDs, USR1 button and EEPROM

2016-09-26 Thread H. Nikolaus Schaller
These patches configure
* the EEPROM
* the LEDs (with some default triggers)
* the USR1 gpio button
for the OMAP5 UEVM board.

H. Nikolaus Schaller (3):
  DT: EVM: add EEPROM
  DT: EVM: add LEDs
  DT: EVM: add USR1 button

 arch/arm/boot/dts/omap5-uevm.dts | 92 
 1 file changed, 92 insertions(+)

-- 
2.7.3



[PATCH 3/3] DT: EVM: add USR1 button

2016-09-26 Thread H. Nikolaus Schaller
Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap5-uevm.dts | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 19f5f0a..1b919f5 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -18,6 +18,25 @@
reg = <0x8000 0x7F00>; /* 2032 MB */
};
 
+   evm_keys {
+   compatible = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_keys_pins>;
+
+   #address-cells = <7>;
+   #size-cells = <0>;
+
+   btn1 {
+   label = "BTN1";
+   linux,code = <169>;
+   gpios = < 19 GPIO_ACTIVE_LOW>;/* gpio3_83 */
+   gpio-key,wakeup;
+   autorepeat;
+   debounce_interval = <50>;
+   };
+   };
+
evm_leds {
compatible = "gpio-leds";
 
@@ -105,6 +124,12 @@
 };
 
 _pmx_core {
+   evm_keys_pins: pinmux_evm_keys_gpio_pins {
+   pinctrl-single,pins = <
+   OMAP5_IOPAD(0x0b6, PIN_INPUT | MUX_MODE6)   /* 
gpio3_83 */
+   >;
+   };
+
i2c5_pins: pinmux_i2c5_pins {
pinctrl-single,pins = <
OMAP5_IOPAD(0x1c6, PIN_INPUT | MUX_MODE0)   
/* i2c5_scl */
-- 
2.7.3



[PATCH 1/3] DT: EVM: add EEPROM

2016-09-26 Thread H. Nikolaus Schaller
Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap5-uevm.dts | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 36ff7c3..be659e8 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -23,6 +23,13 @@
vdda-supply = <_reg>;
 };
 
+ {
+   eeprom@50 {
+   compatible = "atmel,24c02";
+   reg = <0x50>;
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins>;
-- 
2.7.3



[PATCH 2/3] DT: EVM: add LEDs

2016-09-26 Thread H. Nikolaus Schaller
Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap5-uevm.dts | 60 
 1 file changed, 60 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index be659e8..19f5f0a 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -17,6 +17,66 @@
device_type = "memory";
reg = <0x8000 0x7F00>; /* 2032 MB */
};
+
+   evm_leds {
+   compatible = "gpio-leds";
+
+   led@1 {
+   label = "omap5:red:led";
+   gpios = < 17 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc0";
+   default-state = "off";
+   };
+
+   led@2 {
+   label = "omap5:green:led";
+   gpios = < 18 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc1";
+   default-state = "off";
+   };
+
+   led@3 {
+   label = "omap5:blue:led";
+   gpios = < 19 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc2";
+   default-state = "off";
+   };
+
+   led@4 {
+   label = "omap5:green:led1";
+   gpios = < 2 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-on";
+   default-state = "off";
+   };
+
+   led@5 {
+   label = "omap5:green:led2";
+   gpios = < 3 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "default-on";
+   default-state = "off";
+   };
+
+   led@6 {
+   label = "omap5:green:led3";
+   gpios = < 4 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   default-state = "off";
+   };
+
+   led@7 {
+   label = "omap5:green:led4";
+   gpios = < 5 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   default-state = "off";
+   };
+
+   led@8 {
+   label = "omap5:green:led5";
+   gpios = < 6 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   default-state = "off";
+   };
+   };
 };
 
  {
-- 
2.7.3



Re: ISDN-Gigaset: Release memory in gigaset_initcs() after an allocation failure

2016-09-26 Thread SF Markus Elfring
>> Memory was not released (as it would be expected) when one call
>> of further resource reservations failed.
> 
> This was the only thing in this series that triggered more than a,
> very uninspired, "meh" on first read.

Will it matter here if the function "kfree" will be called for the
data structure members "bcs" and "inbuf" after a later function call
failed within the implementation of "gigaset_initcs"?

Regards,
Markus


Re: ISDN-Gigaset: Fine-tuning for three function implementations

2016-09-26 Thread SF Markus Elfring
>>   Use kmalloc_array() in two functions
>>   Improve another size determination in gigaset_initcs()
>>   Delete an error message for a failed memory allocation
>>   Release memory in gigaset_initcs() after an allocation failure
> 
> Which "static source code analysis" was used for that discovery?

Are you eventually asking more for the development tools which were involved 
here?

* Coccinelle software

* Script "checkpatch.pl"

* My own eyes with help of a current text editor and its programming support

Regards,
Markus


RE: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.

2016-09-26 Thread Liav Rehana


-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de] 
Sent: Tuesday, September 27, 2016 3:01 AM
To: Liav Rehana 
Cc: john.stu...@linaro.org; linux-kernel@vger.kernel.org; Elad Kanfi 
; Noam Camus 
Subject: Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in 
its calculation.

On Mon, 26 Sep 2016, Liav Rehana wrote:
>> During the calculation of the nsec variable in the inline function 
>> timekeeping_delta_to_ns, it may undergo a sign extension if its msb is 
>> set just before the shift. The sign extension may, in some cases, gain 
>> it a value near the maximum value of the 64-bit range. This is bad 
>> when it is later used in a division function, such as 
>> __iter_div_u64_rem, where the amount of loops it will go through to 
>> calculate the division will be too large.
>> The following commit fixes that chance of sign extension,

>Again. This does not fix anything, it papers over the underlying problem that 
>the calling code hands in a delta which is big enough to overflow the 
>multiplication into the negative space. >You just extend the range of deltas 
>which are handled gracefully, but that does not fix the underlying problem as 
>we still can run into the multiplication overflow. It won't cause the >result 
>to be negative, but it will be crap nevertheless.

>> while maintaining the type of the nsec variable as signed for other 
>> functions that use this variable, for possible legit negative time 
>> intervals.

>What is this maintaining? The type of this variable changes to u64 and other 
>functions cannot use this variable at all because it's local to that function. 
>This sentence makes no sense at >all.

About your first note, I understand that it doesn't fix the overflow chance, 
but I'm not quite sure what can be done about that. If there was a code in the 
calling function that detects
such event, what do you think can be done about it ? Would you just print a 
warning and lower delta as to not overflow after the multiplication ? If not, 
how do you think the problem I ran into can be fixed, if not by eliminating the 
possibility for sign extension the way I did ?

About the other note, I understood from you and John that there are some cases 
where negative time intervals are valid. What I meant by 'maintaining the type 
of the nsec variable as signed' was, that for the other functions that call the 
function I've changed, they do define a variable named nsec, and they define it 
as signed. In their implementation they assign him a value that is returned 
from the function I've changed. While the nsec variable is unsigned now in the 
function that calculates it, it can still return a value with an MSB that is 
set, which will be handled as negative in the caller function, where it was 
defined as signed. In that case, the change I added just removes the 
possibility of a sign extension, but the nsec variable will still be viewed as 
negative on the caller functions where it was supposed to return a negative 
value in the function I've changed.


linux-next: manual merge of the gpio tree with the arm-soc tree

2016-09-26 Thread Stephen Rothwell
Hi Linus,

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

  arch/arm/mach-omap2/board-rx51-peripherals.c

between commit:

  9b7141d01a76 ("ARM: OMAP2+: Drop legacy board file for n900")

from the arm-soc tree and commit:

  9132ce450bd1 ("ARM: omap2: fix missing include")

from the gpio tree.

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

-- 
Cheers,
Stephen Rothwell


[PATCH] Fix a issue that Alps Touchpad cursor does not work

2016-09-26 Thread Masaki Ota
fix Touchpad cursor does not work after touching Touchpad 
by 3 or more fingers.

Issue reproduction procedure
1.Three or more fingers put on Touchpad.
2.release fingers from Touchpad.
3.move the cursor by one finger.
4.the cursor does not move.

Cause
This code does not notify multi fingers state correctly to system.
For example, when three fingers release from Touchpad,
fingers state is 3 -> 0. It needs to notify
first, second and third finger's releasing state.
But this code does not notify second and third finger's
releasing state by "break" code.

Solution
Delete "break" code, and move xyz input code to the correct place.

Signed-off-by: Masaki Ota 
---
 drivers/hid/hid-alps.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index 048befd..610df92 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -190,16 +190,16 @@ static int alps_raw_event(struct hid_device *hdev,
if (z != 0) {
input_mt_report_slot_state(hdata->input,
MT_TOOL_FINGER, 1);
+   input_report_abs(hdata->input,
+   ABS_MT_POSITION_X, x);
+   input_report_abs(hdata->input,
+   ABS_MT_POSITION_Y, y);
+   input_report_abs(hdata->input,
+   ABS_MT_PRESSURE, z);
} else {
input_mt_report_slot_state(hdata->input,
MT_TOOL_FINGER, 0);
-   break;
}
-
-   input_report_abs(hdata->input, ABS_MT_POSITION_X, x);
-   input_report_abs(hdata->input, ABS_MT_POSITION_Y, y);
-   input_report_abs(hdata->input, ABS_MT_PRESSURE, z);
-
}
 
input_mt_sync_frame(hdata->input);
-- 
2.7.4



Re: linux-next: build failure after merge of the rdma tree

2016-09-26 Thread Christoph Hellwig
On Tue, Sep 27, 2016 at 11:23:34AM +1000, Stephen Rothwell wrote:
> Hi Doug,
> 
> After merging the rdma tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

Please just disable broken staging code like lustre for the linux-next
builds. We had that discussion before, didn't we?


linux-next: manual merge of the gpio tree with the i2c tree

2016-09-26 Thread Stephen Rothwell
Hi Linus,

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

  drivers/gpio/gpio-pca953x.c

between commit:

  6212e1d6ed40 ("gpio: pca953x: variable 'id' was used twice")

from the i2c tree and commit:

  e23efa30 ("gpio: pca954x: Add vcc regulator and enable it")

from the gpio tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpio/gpio-pca953x.c
index 018f39cc19c8,5d059866d17a..
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@@ -765,29 -759,41 +759,43 @@@ static int pca953x_probe(struct i2c_cli
  
chip->client = client;
  
+   reg = devm_regulator_get(>dev, "vcc");
+   if (IS_ERR(reg)) {
+   ret = PTR_ERR(reg);
+   if (ret != -EPROBE_DEFER)
+   dev_err(>dev, "reg get err: %d\n", ret);
+   return ret;
+   }
+   ret = regulator_enable(reg);
+   if (ret) {
+   dev_err(>dev, "reg en err: %d\n", ret);
+   return ret;
+   }
+   chip->regulator = reg;
+ 
 -  if (id) {
 -  chip->driver_data = id->driver_data;
 +  if (i2c_id) {
 +  chip->driver_data = i2c_id->driver_data;
} else {
 -  const struct acpi_device_id *id;
 +  const struct acpi_device_id *acpi_id;
const struct of_device_id *match;
  
match = of_match_device(pca953x_dt_ids, >dev);
if (match) {
chip->driver_data = (int)(uintptr_t)match->data;
} else {
 -  id = acpi_match_device(pca953x_acpi_ids, >dev);
 -  if (!id) {
 +  acpi_id = acpi_match_device(pca953x_acpi_ids, 
>dev);
-   if (!acpi_id)
-   return -ENODEV;
++  if (!acpi_id) {
+   ret = -ENODEV;
+   goto err_exit;
+   }
  
 -  chip->driver_data = id->driver_data;
 +  chip->driver_data = acpi_id->driver_data;
}
}
  
-   chip->chip_type = PCA_CHIP_TYPE(chip->driver_data);
- 
mutex_init(>i2c_lock);
 +  lockdep_set_subclass(>i2c_lock,
 +   i2c_adapter_depth(client->adapter));
  
/* initialize cached registers from their original values.
 * we can't share this chip with another i2c master.


Re: [PATCH v2 1/2] config: Add new CONFIG_PROVE_LOCKING_SMALL

2016-09-26 Thread Sam Ravnborg
Hi Babu.

On Mon, Sep 26, 2016 at 03:31:37PM -0700, Babu Moger wrote:
> Adding the new config parameter CONFIG_PROVE_LOCKING_SMALL for sparc.
> 
> This feature limits the space used for "Lock debugging: prove locking
> correctness" by about 4MB. The current sparc systms have the limitation of
> 32MB size for kernel size including .text, .data and .bss sections. With
> PROVE_LOCKING feature, the kernel size could grow beyond this limit and
> causing system bootup issues. With this option, kernel limits the size
> of the entries of lock_chains, stack_trace etc. so that kernel fits in
> required size limit.  This is only visible for sparc.
> 
> Signed-off-by: Babu Moger 
> ---
>  lib/Kconfig.debug |   17 +
>  1 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index b9cfdbf..c79de25 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1035,6 +1035,7 @@ config PROVE_LOCKING
>   select DEBUG_MUTEXES
>   select DEBUG_LOCK_ALLOC
>   select TRACE_IRQFLAGS
> + select PROVE_LOCKING_SMALL if SPARC
>   default n
>   help
>This feature enables the kernel to prove that all locking
> @@ -1070,6 +1071,22 @@ config PROVE_LOCKING
>  
>For more details, see Documentation/locking/lockdep-design.txt.
>  
> +config PROVE_LOCKING_SMALL
> + bool "Limit the space for prove locking correctness"
> + depends on PROVE_LOCKING && SPARC
> + help
> +  This feature limits the space used for "Lock debugging: prove
> +  locking correctness" by about 4MB. In sparc system, all the
> +  kernel's code, data, and bss, must have locked translations in
> +  the TLB so that it does not hit TLB misses. The current sparc
> +  chips have 8 TLB entries available that may be locked down, and
> +  with a 4mb page size, this gives a maximum of 32mb of memory for
> +  the kernel size. With PROVE_LOCKING feature, the kernel size could
> +  grow beyond this limit and causing system bootup issues. With
> +  this option, kernel limits the size of the entries of lock_chains,
> +  stack_trace etc. to debug PROVE_LOCKING so that kernel size fits
> +  in 32MB. This is only visible for SPARC.

Since this is only relevant for sparc, and for sparc this is "select"ed,
then there is limited/no gain having this as a visible menu config option.

How about adding just a simple non-visible config symbol:

config PROVE_LOCKING_SMALL
bool

The nice help text can be added to the H file, and the select
can be move to the sparc/Kconfig file where it really belongs.

Sam


Re: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

2016-09-26 Thread Peter Chen
On Mon, Sep 26, 2016 at 11:44:50AM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-09-25 20:29:27)
> > On Thu, Sep 22, 2016 at 11:51:02AM -0700, Stephen Boyd wrote:
> > > Quoting Peter Chen (2016-09-16 18:16:05)
> > > > On Wed, Sep 14, 2016 at 01:55:02AM -0700, Stephen Boyd wrote:
> > > > > Quoting Stephen Boyd (2016-09-13 18:42:46)
> > > > > > On the db410c 96boards platform we have a TC7USB40MU[1] on the
> > > > > > board to mux the D+/D- lines from the SoC between a micro usb
> > > > > > "device" port and a USB hub for "host" roles. Upon a role switch,
> > > > > > we need to change this mux to forward the D+/D- lines to either
> > > > > > the port or the hub. Therefore, introduce a driver for this
> > > > > > device that intercepts extcon USB_HOST events and logically
> > > > > > asserts a gpio to mux the "host" D+/D- lines when a host cable is
> > > > > > attached. When the cable goes away, it will logically deassert
> > > > > > the gpio and mux the "device" lines.
> > > > > > 
> > > > > > [1] 
> > > > > > https://toshiba.semicon-storage.com/ap-en/product/logic/bus-switch/detail.TC7USB40MU.html
> > > > > > 
> > > > > > Cc: MyungJoo Ham 
> > > > > > Cc: Chanwoo Choi 
> > > > > > Cc: 
> > > > > > Signed-off-by: Stephen Boyd 
> > > > > > ---
> > > > > > 
> > > > > > Should I make the extcon part optional? I could see a case where 
> > > > > > there are two
> > > > > > "OTG" ports connected to the mux (or two hubs), and for some reason 
> > > > > > the
> > > > > > software may want to mux between them at runtime. If we mandate an 
> > > > > > extcon,
> > > > > > that won't be possible to support. Perhaps it would be better to 
> > > > > > have
> > > > > > the node, but connect it to the usb controller with a phandle 
> > > > > > (maybe of_graph
> > > > > > endpoints would be useful too) so that when the controller wants to 
> > > > > > mux over
> > > > > > a port it can do so.
> > > > > 
> > > > > Here's some dts mock-up on top of the db410c for the of_graph stuff. I
> > > > > haven't written any code around it, but the idea is to allow the 
> > > > > binding
> > > > > to specify how the mux is connected to upstream and downstream D+/D-
> > > > > lines. This way, we can do some dt parsing of the endpoints and their
> > > > > parent nodes to figure out if the mux needs to be set high or low to 
> > > > > use
> > > > > a device connector or a usb hub based on if the id cable is present.
> > > > > Maybe I'm over thinking things though and we could just have a DT
> > > > > property for that.
> > > > > 
> > > > >   soc {
> > > > >   usb@78d9000 {
> > > > >   extcon = <_id>, <_id>;
> > > > 
> > > > Why you have two same extcon phandler? From my mind, one should id,
> > > > another should is vbus. Besides, I find extcon-usb-gpio.c is lack of
> > > > vbus support, how you support vbus detection for
> > > > connection/disconnection with PC for your chipidea msm patch set?
> > > 
> > > This was already in the dts files for db410c. In the chipidea binding
> > > one is for EXTCON_USB (vbus) and one is for EXTCON_USB_HOST (id). My
> > > understanding is that extcon-usb-gpio.c sends events for both EXTCON_USB
> > > and EXTCON_USB_HOST when the gpio changes state. vbus detection is not
> > > that great on this board because we only have on gpio for this.
> > 
> > I think extcon-usb-gpio.c needs to extend for supporting vbus event,
> > otherwise, the micro-b cable's connect/disconnect will introduce
> > EXTCON_USB_HOST event, if you use two <_idx> for both id and
> > vbus event.
> > 
> 
> Sorry, I'm lost now. extcon-usb-gpio.c already supports EXTCON_USB as an
> event. Is the problem that we're using two of the same phandles in the
> binding?

No, ID and VBUS are different events.

http://www.spinics.net/lists/linux-usb/msg147004.html

-- 

Best Regards,
Peter Chen


Re: [PATCH v6 0/2] Add USB configuration for imx53

2016-09-26 Thread Peter Chen
On Mon, Sep 26, 2016 at 01:14:18PM +0200, Fabien Lahoudere wrote:
> Changes in V2:
>   - Patches sent to early with bad contents
> Changes in V3:
>   - Change subject
>   - Split "configure imx for ULPI phy" for disable-oc code
> Changes in V4:
>   - Fix "Change switch order" commit message
>   - Indent switch/case (set case on the same column as switch)
>   - Remove useless test in "Change switch order"
> Changes in V5:
>   - Squash "Change switch order" and "configure imx for ULPI phy"
>   - Add device tree binding documentation
> Changes in v6:
>   - Remove dt binding because we can disable the feature by using an 
>   existing binding
> 
> Fabien Lahoudere (2):
>   usb: chipidea: imx: configure imx for ULPI phy
>   usb: chipidea: imx: Disable internal 60Mhz clock with ULPI PHY
> 
>  drivers/usb/chipidea/ci_hdrc_imx.c |  4 ++
>  drivers/usb/chipidea/ci_hdrc_imx.h |  1 +
>  drivers/usb/chipidea/usbmisc_imx.c | 86 
> +++---
>  3 files changed, 77 insertions(+), 14 deletions(-)
> 
> -- 
> 2.1.4
> 

I will queue them, thanks.

-- 

Best Regards,
Peter Chen


Re: [PATCH v3] mmc: sdhci-msm: Add pm_runtime and system PM support

2016-09-26 Thread Ritesh Harjani

Hi Ulf,


On 9/23/2016 3:37 PM, Ulf Hansson wrote:

[...]


Is there anything else needed in msm sdhci driver so that the auto
tuning is taken care of?



I am not familiar with any other than sdhci-esdhc-imx which supports
the SDHCI_TUNING_MODE_3. I may be wrong though.

In the sdhci-esdhc-imx case, enabling of auto tuning seems to be done
in esdhc_post_tuning(), where a vendor specific register
(ESDHC_MIX_CTRL) is being written to. Perhaps something similar in
your case?


Thanks Ulf for the comments. Will check this and see if there is
something of this sort we have to do to achieve auto tuning.
Adding Ritesh who has been posting some SDHCI MSM patches recently in
case he knows about this.



Internally, we don't use this Auto re-tuning and rely on explicit re-tune by
host driver.

Question though -
1. why do we need to call sdhci_runtime_resume/suspend from
sdhci_msm_runtime_suspend/resume?
From what I see is, sdhci_runtime_susend/resume will do reset and re-program
of host->pwr and host->clk because of which a retune will be required for
the next command after runtime resume.

We can *only* disable and enable the clocks in
sdhci_msm_runtime_suspend/resume?
Thoughts? With this, I suppose you would not see any issue.


I see.

I assumes that means saving/restoring register context will
automatically handled by some other outer logic, when doing clock
gating/ungating?

In other words, if the controller has valid tuning values, those will
be re-used and restored when clock ungating happens?
Yes, that is my understanding too. I double confirmed with HW team about 
this. So, even if we gate the clock directly at GCC, sdhc msm controller 
is capable of restoring it's register values.


In this case, it is not required to call for 
sdhci_runtime_suspend/resume from sdhci_msm_runtime routines right?
Instead we can only have disabling/enabling of clks from 
sdhci_msm_runtime_suspend/resume. Does this sounds good?








Though for this issue, since internally also auto retuning is never used, we
can have this mode disabled. I can once again check with HW team to get more
details about this mode for MSM controller.



Regards,
Pramod





Kind regards
Uffe
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



Re: [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

2016-09-26 Thread maitysanchayan
Hello,

Ping?

- Sanchayan.

On 16-09-19 10:41:51, Sanchayan Maity wrote:
> Remove the use of DDC I2C bus bitbang to support reading of EDID
> and rely on support from internal HDMI I2C master controller instead.
> As a result remove the device tree property ddc-i2c-bus.
> 
> Signed-off-by: Sanchayan Maity 
> ---
> Changes since v1:
> 
> Change the ranking in i2c aliases
> 
> v1: https://lkml.org/lkml/2016/9/14/55
> ---
>  arch/arm/boot/dts/imx6q-apalis-ixora.dts | 12 +++-
>  arch/arm/boot/dts/imx6qdl-apalis.dtsi| 25 +
>  2 files changed, 12 insertions(+), 25 deletions(-)
> 
> diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts 
> b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> index 207b85b..82b81e0 100644
> --- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> +++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
> @@ -55,10 +55,9 @@
>"fsl,imx6q";
>  
>   aliases {
> - i2c0 = 
> - i2c1 = 
> - i2c2 = 
> - i2c3 = 
> + i2c0 = 
> + i2c1 = 
> + i2c2 = 
>   };
>  
>   aliases {
> @@ -186,11 +185,6 @@
>  };
>  
>   {
> - ddc-i2c-bus = <>;
> - status = "okay";
> -};
> -
> - {
>   status = "okay";
>  };
>  
> diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi 
> b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> index 99e323b..8c67dd8 100644
> --- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
> @@ -53,18 +53,6 @@
>   status = "disabled";
>   };
>  
> - /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
> - i2cddc: i2c@0 {
> - compatible = "i2c-gpio";
> - pinctrl-names = "default";
> - pinctrl-0 = <_i2c_ddc>;
> - gpios = < 16 GPIO_ACTIVE_HIGH /* sda */
> -   30 GPIO_ACTIVE_HIGH /* scl */
> - >;
> - i2c-gpio,delay-us = <2>;/* ~100 kHz */
> - status = "disabled";
> - };
> -
>   reg_1p8v: regulator-1p8v {
>   compatible = "regulator-fixed";
>   regulator-name = "1P8V";
> @@ -209,6 +197,12 @@
>   };
>  };
>  
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_hdmi_ddc>;
> + status = "disabled";
> +};
> +
>  /*
>   * GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
>   * board)
> @@ -633,11 +627,10 @@
>   >;
>   };
>  
> - pinctrl_i2c_ddc: gpioi2cddcgrp {
> + pinctrl_hdmi_ddc: hdmiddcgrp {
>   fsl,pins = <
> - /* DDC bitbang */
> - MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
> - MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
> + MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
> + MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
>   >;
>   };
>  
> -- 
> 2.9.3
> 


Re: [PATCH] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

2016-09-26 Thread maitysanchayan
Hello,

Ping?

- Sanchayan.

On 16-09-21 16:54:38, Sanchayan Maity wrote:
> Add support for Toradex Colibri iMX6 module.
> 
> Signed-off-by: Sanchayan Maity 
> ---
>  arch/arm/boot/dts/Makefile   |   1 +
>  arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts | 253 
>  arch/arm/boot/dts/imx6qdl-colibri.dtsi   | 890 
> +++
>  3 files changed, 1144 insertions(+)
>  create mode 100644 arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
>  create mode 100644 arch/arm/boot/dts/imx6qdl-colibri.dtsi
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index f79cac2..44ff380 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -323,6 +323,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
>   imx6dl-aristainetos_7.dtb \
>   imx6dl-aristainetos2_4.dtb \
>   imx6dl-aristainetos2_7.dtb \
> + imx6dl-colibri-eval-v3.dtb \
>   imx6dl-cubox-i.dtb \
>   imx6dl-dfi-fs700-m60.dtb \
>   imx6dl-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts 
> b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> new file mode 100644
> index 000..e0c2172
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-colibri-eval-v3.dts
> @@ -0,0 +1,253 @@
> +/*
> + * Copyright 2014-2016 Toradex AG
> + * Copyright 2012 Freescale Semiconductor, Inc.
> + * Copyright 2011 Linaro Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * version 2 as published by the Free Software Foundation.
> + *
> + * This file is distributed in the hope that it will be useful
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-colibri.dtsi"
> +
> +/ {
> + model = "Toradex Colibri iMX6DL/S on Colibri Evaluation Board V3";
> + compatible = "toradex,colibri_imx6dl-eval-v3", "toradex,colibri_imx6dl",
> +  "fsl,imx6dl";
> +
> + aliases {
> + i2c0 = 
> + i2c1 = 
> + };
> +
> + aliases {
> + rtc0 = _i2c;
> + rtc1 = _rtc;
> + };
> +
> + clocks {
> + /* Fixed crystal dedicated to mcp251x */
> + clk16m: clk@1 {
> + compatible = "fixed-clock";
> + reg = <1>;
> + #clock-cells = <0>;
> + clock-frequency = <1600>;
> + clock-output-names = "clk16m";
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <_gpio_keys>;
> +
> + wakeup {
> + label = "Wake-Up";
> + gpios = < 22 GPIO_ACTIVE_HIGH>; /* SODIMM 45 */
> + linux,code = ;
> + debounce-interval = <10>;
> + wakeup-source;
> + };
> + };
> +
> + lcd_display: display@di0 {
> + compatible = "fsl,imx-parallel-display";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interface-pix-fmt = "bgr666";
> + pinctrl-names = "default";
> + pinctrl-0 = <_ipu1_lcdif>;
> + 

Re: [PATCH 1/7] selftest: sync: basic tests for sw_sync framework

2016-09-26 Thread Michael Ellerman
Emilio López  writes:
> El 22/09/16 a las 06:43, Michael Ellerman escribió:
>> Emilio López  writes:
>>
>> Please don't include the *kernel* headers, they're really not meant to
>> be used in userspace programs :)
>>
>>> +CFLAGS += -I../../../../usr/include/
>>
>> That is the correct place to get them from. They'll have been put there
>> by 'make headers_install'.
>
> My inspiration here has been tools/testing/selftests/memfd/Makefile, 
> which does it this way. If I only include the ones on usr then it 
> doesn't build, as there's no sync_file.h available, even after running 
> make headers_install. How am I supposed to use the ioctls from there?

It looks like it's missing from include/uapi/linux/Kbuild, you need to
add it to the list of exported headers:

diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index dd604395606b..40411b4ff012 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -397,6 +397,7 @@ header-y += stddef.h
 header-y += string.h
 header-y += suspend_ioctls.h
 header-y += swab.h
+header-y += sync_file.h
 header-y += synclink.h
 header-y += sysctl.h
 header-y += sysinfo.h


cheers


RE: [PATCH] scsi: be2iscsi: mark symbols static where possible

2016-09-26 Thread Jitendra Bhivare
> -Original Message-
> From: Baoyou Xie [mailto:baoyou@linaro.org]
> Sent: Monday, September 26, 2016 5:31 PM
> To: subbu.seethara...@broadcom.com; ketan.muka...@broadcom.com;
> jitendra.bhiv...@broadcom.com; j...@linux.vnet.ibm.com;
> martin.peter...@oracle.com
> Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org;
a...@arndb.de;
> baoyou@linaro.org; xie.bao...@zte.com.cn; han@zte.com.cn;
> tang.qiang...@zte.com.cn
> Subject: [PATCH] scsi: be2iscsi: mark symbols static where possible
>
> We get 6 warnings when building kernel with W=1:
> drivers/scsi/be2iscsi/be_main.c:65:1: warning: no previous prototype for
> 'beiscsi_log_enable_disp' [-Wmissing-prototypes]
> drivers/scsi/be2iscsi/be_main.c:78:1: warning: no previous prototype for
> 'beiscsi_log_enable_change' [-Wmissing-prototypes]
> drivers/scsi/be2iscsi/be_main.c:97:1: warning: no previous prototype for
> 'beiscsi_log_enable_store' [-Wmissing-prototypes]
> drivers/scsi/be2iscsi/be_main.c:116:1: warning: no previous prototype
for
> 'beiscsi_log_enable_init' [-Wmissing-prototypes]
> drivers/scsi/be2iscsi/be_main.c:4587:5: warning: no previous prototype
for
> 'beiscsi_iotask_v2' [-Wmissing-prototypes]
> drivers/scsi/be2iscsi/be_main.c:4976:6: warning: no previous prototype
for
> 'beiscsi_hba_attrs_init' [-Wmissing-prototypes]
>
> In fact, these functions are only used in the file in which they are
declared and
> don't need a declaration, but can be made static.
>
> So this patch marks these functions with 'static'.
>
> Signed-off-by: Baoyou Xie 
> ---
[JB] Looks good.
Reviewed by: Jitendra Bhivare 


Re: [x86-tip] strange nr_cpus= boot regression

2016-09-26 Thread Borislav Petkov
Mike Galbraith  wrote:
>Whew, no mythical creature infestation.  Thanks, next encounter with
>such an artifact should provide markedly less entertainment.

Oh, no worries. Next time it'll be something else. 
There's no dull day with this this kernel thing ;-)
-- 
Sent from a small device: formatting sucks and brevity is inevitable. 


Re: [PATCH 00/11] splice cleanups

2016-09-26 Thread Al Viro
On Wed, Sep 14, 2016 at 10:37:05AM +0200, Miklos Szeredi wrote:
> This contains assorted cleanups in the splice area:
> 
>  - add helpers for pipe buf ops instead of directly calling them
> 
>  - page cache buf doesn't seem to need confirming (since ages)
> 
>  - generic_file_splice_read() and generic_file_read() have lots of
>duplication
> 
> Git tree is here:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git#splice

My apologies for not replying back when it had been first posted, especially
since I'd been actively messing with splice-related code at that time
(it started in "xfs_file_splice_read: possible circular locking dependency
detected" thread on xfs list).  I've no objections against your inline
helpers.  I'm not so sure about ->confirm() and I really think that
__generic_file_splice_read() should simply die.

Could you rebase the beginning of that thing on top of #work.splice_read
in vfs.git?


linux-next: manual merge of the percpu tree with the asm-generic tree

2016-09-26 Thread Stephen Rothwell
Hi all,

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

  include/asm-generic/percpu.h

between commit:

  acbdf0e98066 ("percpu: make this_cpu_generic_read notrace")

from the asm-generic tree and commit:

  1b5ca1212742 ("percpu: improve generic percpu modify-return implementation")

from the percpu tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/asm-generic/percpu.h
index 70fefec69e61,40e887068da2..
--- a/include/asm-generic/percpu.h
+++ b/include/asm-generic/percpu.h
@@@ -108,9 -118,9 +118,9 @@@ do {   

  #define this_cpu_generic_read(pcp)\
  ({\
typeof(pcp) __ret;  \
 -  preempt_disable();  \
 +  preempt_disable_notrace();  \
-   __ret = *this_cpu_ptr(&(pcp));  \
+   __ret = raw_cpu_generic_read(pcp);  \
 -  preempt_enable();   \
 +  preempt_enable_notrace();   \
__ret;  \
  })
  


Re: thousands of kworker processes with 4.7.x and 4.8-rc*

2016-09-26 Thread Tomasz Chmielewski

On 2016-09-26 04:07, Nikolay Borisov wrote:


Not sure if that's expected behaviour or not.



Why don't you sample the stacks of some of those kworker processes to
see if they are all executing a parituclar piece of work. That might
help you narrow down where they originate from. Cat multiple
/proc/$kworker-pid/stack files and see if a pattern emerges.


FYI, it was reproduced and bisected here (scroll to the bottom):

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1626564


Tomasz Chmielewski
https://lxadm.com


[PATCH] igb: Realign bad indentation

2016-09-26 Thread Joe Perches
Statements should start on tabstops.

Use a single statement and test instead of multiple tests.

Signed-off-by: Joe Perches 
---
 drivers/net/ethernet/intel/igb/e1000_mac.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/intel/igb/e1000_mac.c 
b/drivers/net/ethernet/intel/igb/e1000_mac.c
index 5010e2232c50..5eff82678f0b 100644
--- a/drivers/net/ethernet/intel/igb/e1000_mac.c
+++ b/drivers/net/ethernet/intel/igb/e1000_mac.c
@@ -792,15 +792,13 @@ static s32 igb_set_default_fc(struct e1000_hw *hw)
 * control setting, then the variable hw->fc will
 * be initialized based on a value in the EEPROM.
 */
-   if (hw->mac.type == e1000_i350) {
+   if (hw->mac.type == e1000_i350)
lan_offset = NVM_82580_LAN_FUNC_OFFSET(hw->bus.func);
-   ret_val = hw->nvm.ops.read(hw, NVM_INIT_CONTROL2_REG
-  + lan_offset, 1, _data);
-} else {
-   ret_val = hw->nvm.ops.read(hw, NVM_INIT_CONTROL2_REG,
-  1, _data);
-}
+   else
+   lan_offset = 0;
 
+   ret_val = hw->nvm.ops.read(hw, NVM_INIT_CONTROL2_REG + lan_offset,
+  1, _data);
if (ret_val) {
hw_dbg("NVM Read Error\n");
goto out;
@@ -808,8 +806,7 @@ static s32 igb_set_default_fc(struct e1000_hw *hw)
 
if ((nvm_data & NVM_WORD0F_PAUSE_MASK) == 0)
hw->fc.requested_mode = e1000_fc_none;
-   else if ((nvm_data & NVM_WORD0F_PAUSE_MASK) ==
-NVM_WORD0F_ASM_DIR)
+   else if ((nvm_data & NVM_WORD0F_PAUSE_MASK) == NVM_WORD0F_ASM_DIR)
hw->fc.requested_mode = e1000_fc_tx_pause;
else
hw->fc.requested_mode = e1000_fc_full;
-- 
2.10.0.rc2.1.g053435c



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

2016-09-26 Thread Stephen Rothwell
Hi all,

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

  arch/arm/include/asm/arch_gicv3.h

between commit:

  91ef84428a86 ("irqchip/gic-v3: Reset BPR during initialization")

from the tip tree and commit:

  3d9cd95f90b2 ("ARM: gic-v3: Work around definition of gic_write_bpr1")

from the kvm-arm tree.

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



-- 
Cheers,
Stephen Rothwell


Re: [PATCH 09/11] splice: use get_page_for_read()

2016-09-26 Thread Al Viro
On Wed, Sep 14, 2016 at 10:37:14AM +0200, Miklos Szeredi wrote:
> What __generic_file_splice_read() does is get a series of uptodate pages
> and put them into the pipe buffer.
> 
> The get_page_for_read() helper can now be used to get the pages,
> simplifying the code and making sure the splice(2) stays in sync with
> read(2).
> 
> For example get_page_for_read() can handle partially uptodate pages and now
> splice can take advantage of these as well.

... or, better yet, kill __generic_file_splice_read() off.


Re: [PATCH 08/11] filemap: add get_page_for_read() helper

2016-09-26 Thread Al Viro
On Wed, Sep 14, 2016 at 10:37:13AM +0200, Miklos Szeredi wrote:
> Getting the page for reading is pretty complicated.  This functionality is
> also duplicated between generic_file_read() generic_file_splice_read().
> 
> So first extract the common code from do_generic_file_read() into a
> separate helper function that takes a filp, the page index, the offset into
> the page and the byte count and returns the page ready for reading (or an
> error).
> 
> This makes do_generic_file_read() much easier to read as well.

__generic_file_splice_read() horrors are not going to survive - see the
patchset posted on fsdevel.  do_generic_file_read() getting easier to
read is certainly a good thing, provided that we don't screw the code
generation for what's a fairly hot path.  IOW, that one really needs
profiling.


Re: [PATCH V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

2016-09-26 Thread Jeehong Kim


On 2016년 09월 23일 01:53, bseg...@google.com wrote:
> Jeehong Kim  writes:
>
>>> Peter Zijlstra  writes:
>>>
 You forgot to Cc Ben, who gave you feedback on v1, which is rather poor
 style. Also, I don't see how kernel-janitors is relevant to this patch.
 This is very much not a janitorial thing.

 (also, why send it twice?)

 On Tue, Aug 30, 2016 at 10:12:40PM +0900, Jeehong Kim wrote:
> In case that CONFIG_HOTPLUG_CPU and CONFIG_CFS_BANDWIDTH is turned on
> and tasks in bandwidth controlled task group run on hotplug core,
> the tasks are not controlled by cfs_b->quota when hotplug core is offline
> and then online. The remaining tasks in task group consume all of
> cfs_b->quota on other cores.
>
> The cause of this problem is described as below:
>
> 1. When hotplug core is offline while tasks in task group run
> on hotplug core, unregister_fair_sched_group() deletes
> leaf_cfs_rq_list of tg->cfs_rq[cpu] from _of(cfs_rq)->leaf_cfs_rq_list.
>
> 2. Then, when hotplug core is online, update_runtime_enabled()
 Peter Zijlstra  writes:
 You forgot to Cc Ben, who gave you feedback on v1, which is rather poor
 style. Also, I don't see how kernel-janitors is relevant to this patch.
 This is very much not a janitorial thing.

 (also, why send it twice?)

 On Tue, Aug 30, 2016 at 10:12:40PM +0900, Jeehong Kim wrote:
> In case that CONFIG_HOTPLUG_CPU and CONFIG_CFS_BANDWIDTH is turned on
> and tasks in bandwidth controlled task group run on hotplug core,
> the tasks are not controlled by cfs_b->quota when hotplug core is offline
> and then online. The remaining tasks in task group consume all of
> cfs_b->quota on other cores.
>
> The cause of this problem is described as below:
>
> 1. When hotplug core is offline while tasks in task group run
> on hotplug core, unregister_fair_sched_group() deletes
> leaf_cfs_rq_list of tg->cfs_rq[cpu] from _of(cfs_rq)->leaf_cfs_rq_list.
>
> 2. Then, when hotplug core is online, update_runtime_enabled()
> registers cfs_b->quota on cfs_rq->runtime_enabled of all leaf cfs_rq
> on runqueue. However, because this is before enqueue_entity() adds
> _rq->leaf_cfs_rq_list on _of(cfs_rq)->leaf_cfs_rq_list,
> cfs->quota is not register on cfs_rq->runtime_enabled.
>
> To resolve this problem, this patch makes update_runtime_enabled()
> registers cfs_b->quota by using walk_tg_tree_from().

> +static int __maybe_unused __update_runtime_enabled(struct task_group 
> *tg, void *data)
>  {
> +struct rq *rq = data;
> +struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)];
> +struct cfs_bandwidth *cfs_b = _rq->tg->cfs_bandwidth;
>
> +raw_spin_lock(_b->lock);
> +raw_spin_unlock(_b->lock);
>
> +return 0;
> +}
> +
> +static void __maybe_unused update_runtime_enabled(struct rq *rq)
> +{
> +struct cfs_rq *cfs_rq = >cfs;
> +
> +/* register cfs_b->quota on the whole tg tree */
> +rcu_read_lock();
> +walk_tg_tree_from(cfs_rq->tg, __update_runtime_enabled, tg_nop, 
> (void *)rq);
> +rcu_read_unlock();
>  }
 Looks ok, performance on hotplug doesn't really matter. Ben, you happy
 with this?
>>> I'm not 100% sure about the exact timings and mechanics of hotplug, but
>>> cfs-bandwidth wise this is ok. We may still have runtime_remaining = 1,
>>> or we may have < 0 and yet be unthrottled, but either case is ok, even
>>> if hotplug allows tasks to have migrated here already (I'm not sure,
>>> looking at the code).
>>>
>>> Now that I check again you can just loop over the list of tgs rather
>>> than the hierarchical walk_tg_tree_from, but there's certainly no harm
>>> in it.
>> Ben,
>>
>> Is there additional revision which I have to do?
>> If so, could you let me know about that?
>>
>> Regards,
>> Jeehong Kim
> Oh, no, this is fine by me.
>
>
>

Ben,

If this is fine to you, could you sign off on this patch?

Regards,
Jeehong Kim.




Re: [PATCH 06/11] pipe: no need to confirm page cache buf

2016-09-26 Thread Al Viro
On Wed, Sep 14, 2016 at 10:37:11AM +0200, Miklos Szeredi wrote:

> Things could happen to that page that make it not uptodate while sitting in
> the pipe, but it's questionable whether we should care about that.
> Checking for being uptodate in the face of such page state change is always
> going to be racy.

I'm not sure it's the right thing to do here; that area looks like a victim
of serious bitrot - once upon a time it was ->map(), which used to lock
page, verity that it's valid, and kmap it.  ->unmap() did kunmap + unlock.

Then the validate part got split off (->pin(), later renamed to ->confirm()),
with lock _not_ held over the kmap/kunmap.  That's the point when it got racy,
AFAICS.  OTOH, I would really hate to hold a page locked over e.g. copying to
userland - too easy to get deadlocks that way.

Jens, could you comment?  Pages definitely shouldn't be getting into pipe
without having been uptodate; the question is what (if anything) should be
done about having a page go non-uptodate (on truncate, hole-punching, etc.)
while a reference to it is sitting in a pipe buffer.


Re: [PATCH 1/4] mm, compaction: more reliably increase direct compaction priority-fix

2016-09-26 Thread Hillf Danton
On Tuesday, September 27, 2016 12:20 AM Vlastimil Babka wrote 
> 
> When increasing the compaction priority, also reset retries. Otherwise we can
> consume all retries on the lower priorities. Also pull the retries increment
> into should_compact_retry() so it counts only the rounds where we actually
> rely on it.
> 
> Suggested-by: Michal Hocko 
> Signed-off-by: Vlastimil Babka 
> Acked-by: Michal Hocko 
> Cc: Mel Gorman 
> Cc: Joonsoo Kim 
> Cc: David Rientjes 
> Cc: Rik van Riel 
> ---
Acked-by: Hillf Danton 




[PATCH] i40e: Make struct i40e_stats const

2016-09-26 Thread Joe Perches
Move some data to text

$ size drivers/net/ethernet/intel/i40e/i40e_ethtool.o*
   textdata bss dec hex filename
  25012   0  32   2504461d4 
drivers/net/ethernet/intel/i40e/i40e_ethtool.o.new
  228682120  32   2502061bc 
drivers/net/ethernet/intel/i40e/i40e_ethtool.o.old

Signed-off-by: Joe Perches 
---
 drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c 
b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 1835186b62c9..d8847a19dc6b 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -104,7 +104,7 @@ static const struct i40e_stats i40e_gstrings_misc_stats[] = 
{
  * The PF_STATs are appended to the netdev stats only when ethtool -S
  * is queried on the base PF netdev, not on the VMDq or FCoE netdev.
  */
-static struct i40e_stats i40e_gstrings_stats[] = {
+static const struct i40e_stats i40e_gstrings_stats[] = {
I40E_PF_STAT("rx_bytes", stats.eth.rx_bytes),
I40E_PF_STAT("tx_bytes", stats.eth.tx_bytes),
I40E_PF_STAT("rx_unicast", stats.eth.rx_unicast),
-- 
2.10.0.rc2.1.g053435c



[RFC][PATCH v2 0/2] Improve libsas hotplug

2016-09-26 Thread Yijing Wang
v1-v2: Fix memory allocation issue in interrupt context.

Yijing Wang (2):
  libsas: Alloc dynamic work to avoid missing sas events
  libsas: Fix hotplug issue in libsas

 drivers/scsi/libsas/sas_ata.c   |  34 ++---
 drivers/scsi/libsas/sas_discover.c  | 245 ++--
 drivers/scsi/libsas/sas_event.c |  61 +
 drivers/scsi/libsas/sas_expander.c  |  54 ++--
 drivers/scsi/libsas/sas_init.c  |  31 -
 drivers/scsi/libsas/sas_internal.h  |  45 ++-
 drivers/scsi/libsas/sas_phy.c   |  50 +++-
 drivers/scsi/libsas/sas_port.c  |  35 --
 drivers/scsi/libsas/sas_scsi_host.c |  23 
 include/scsi/libsas.h   |  13 +-
 include/scsi/sas_ata.h  |   4 +-
 11 files changed, 404 insertions(+), 191 deletions(-)

-- 
2.5.0



[RFC][PATCH v2 1/2] libsas: Alloc dynamic work to avoid missing sas events

2016-09-26 Thread Yijing Wang
Now libsas hotplug work is static, LLDD driver queue
the hotplug work into shost->work_q. If LLDD driver
burst post lots hotplug event to libsas, the hotplug
events may pending in the workqueue like

shost->workq
tail | PHYE_LOSS_OF_SIGNAL  | PORTE_BYTES_DMAED | head

In this case, if a new PORTE_BYTES_DMAED event coming,
it would be lost, because we can not queue a work which
is already pending in the workqueue, also libsas has a
pending bit to avoid queue the same event.

The lost hotplug event make something confusing, e.g.
we have sas disks connected hardware, but we can not
found them in kernel.

This patch remove the static defined hotplug work,
and use dynamic work to avoid missing hotplug events.

Signed-off-by: Yijing Wang 
Signed-off-by: Yousong He 
Signed-off-by: Qilin Chen 
---
 drivers/scsi/libsas/sas_event.c| 61 ++
 drivers/scsi/libsas/sas_init.c |  5 +---
 drivers/scsi/libsas/sas_internal.h |  3 ++
 drivers/scsi/libsas/sas_phy.c  | 50 +--
 drivers/scsi/libsas/sas_port.c | 23 +++---
 include/scsi/libsas.h  |  8 -
 6 files changed, 66 insertions(+), 84 deletions(-)

diff --git a/drivers/scsi/libsas/sas_event.c b/drivers/scsi/libsas/sas_event.c
index aadbd53..091f5c4 100644
--- a/drivers/scsi/libsas/sas_event.c
+++ b/drivers/scsi/libsas/sas_event.c
@@ -27,6 +27,10 @@
 #include "sas_internal.h"
 #include "sas_dump.h"
 
+static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
+   [HAE_RESET] = sas_hae_reset,
+};
+
 void sas_queue_work(struct sas_ha_struct *ha, struct sas_work *sw)
 {
if (!test_bit(SAS_HA_REGISTERED, >state))
@@ -40,17 +44,14 @@ void sas_queue_work(struct sas_ha_struct *ha, struct 
sas_work *sw)
scsi_queue_work(ha->core.shost, >work);
 }
 
-static void sas_queue_event(int event, unsigned long *pending,
-   struct sas_work *work,
+static void sas_queue_event(int event, struct sas_work *work,
struct sas_ha_struct *ha)
 {
-   if (!test_and_set_bit(event, pending)) {
-   unsigned long flags;
+   unsigned long flags;
 
-   spin_lock_irqsave(>lock, flags);
-   sas_queue_work(ha, work);
-   spin_unlock_irqrestore(>lock, flags);
-   }
+   spin_lock_irqsave(>lock, flags);
+   sas_queue_work(ha, work);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 
@@ -111,52 +112,60 @@ void sas_enable_revalidation(struct sas_ha_struct *ha)
if (!test_and_clear_bit(ev, >pending))
continue;
 
-   sas_queue_event(ev, >pending, >disc_work[ev].work, ha);
+   sas_queue_event(ev, >disc_work[ev].work, ha);
}
mutex_unlock(>disco_mutex);
 }
 
 static void notify_ha_event(struct sas_ha_struct *sas_ha, enum ha_event event)
 {
+   struct sas_ha_event *ev;
+
BUG_ON(event >= HA_NUM_EVENTS);
 
-   sas_queue_event(event, _ha->pending,
-   _ha->ha_events[event].work, sas_ha);
+   ev = kzalloc(sizeof(*ev), GFP_ATOMIC);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_ha_event_fns[event]);
+   ev->ha = sas_ha;
+   sas_queue_event(event, >work, sas_ha);
 }
 
 static void notify_port_event(struct asd_sas_phy *phy, enum port_event event)
 {
+   struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
 
BUG_ON(event >= PORT_NUM_EVENTS);
 
-   sas_queue_event(event, >port_events_pending,
-   >port_events[event].work, ha);
+   ev = kzalloc(sizeof(*ev), GFP_ATOMIC);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_port_event_fns[event]);
+   ev->phy = phy;
+   sas_queue_event(event, >work, ha);
 }
 
 void sas_notify_phy_event(struct asd_sas_phy *phy, enum phy_event event)
 {
+   struct asd_sas_event *ev;
struct sas_ha_struct *ha = phy->ha;
 
BUG_ON(event >= PHY_NUM_EVENTS);
 
-   sas_queue_event(event, >phy_events_pending,
-   >phy_events[event].work, ha);
+   ev = kzalloc(sizeof(*ev), GFP_ATOMIC);
+   if (!ev)
+   return;
+
+   INIT_SAS_WORK(>work, sas_phy_event_fns[event]);
+   ev->phy = phy;
+   sas_queue_event(event, >work, ha);
 }
 
 int sas_init_events(struct sas_ha_struct *sas_ha)
 {
-   static const work_func_t sas_ha_event_fns[HA_NUM_EVENTS] = {
-   [HAE_RESET] = sas_hae_reset,
-   };
-
-   int i;
-
-   for (i = 0; i < HA_NUM_EVENTS; i++) {
-   INIT_SAS_WORK(_ha->ha_events[i].work, sas_ha_event_fns[i]);
-   sas_ha->ha_events[i].ha = sas_ha;
-   }
-
sas_ha->notify_ha_event = notify_ha_event;
sas_ha->notify_port_event = notify_port_event;
sas_ha->notify_phy_event = sas_notify_phy_event;
diff --git 

Re: [PATCH] power: supply: bq24910_charger: reset first_time check

2016-09-26 Thread Matt Ranostay
Hold off on this one. Currently reworking a patch series that won't
need this change after all.

On Thu, Sep 22, 2016 at 8:32 PM, Matt Ranostay  wrote:
> bq24190_register_reset() function needs to reset the bdi->first_time
> condition every time to avoid spurious interrupts in suspend/resume.
>
> Signed-off-by: Matt Ranostay 
> ---
>  drivers/power/supply/bq24190_charger.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/power/supply/bq24190_charger.c 
> b/drivers/power/supply/bq24190_charger.c
> index f5746b9f4e83..cc1dbdb1737f 100644
> --- a/drivers/power/supply/bq24190_charger.c
> +++ b/drivers/power/supply/bq24190_charger.c
> @@ -513,6 +513,8 @@ static int bq24190_register_reset(struct bq24190_dev_info 
> *bdi)
> int ret, limit = 100;
> u8 v;
>
> +   bdi->first_time = true;
> +
> /* Reset the registers */
> ret = bq24190_write_mask(bdi, BQ24190_REG_POC,
> BQ24190_REG_POC_RESET_MASK,
> @@ -1375,7 +1377,6 @@ static int bq24190_probe(struct i2c_client *client,
> bdi->model = id->driver_data;
> strncpy(bdi->model_name, id->name, I2C_NAME_SIZE);
> mutex_init(>f_reg_lock);
> -   bdi->first_time = true;
> bdi->charger_health_valid = false;
> bdi->battery_health_valid = false;
> bdi->battery_status_valid = false;
> --
> 2.7.4
>


[RFC][PATCH v2 2/2] libsas: Fix hotplug issue in libsas

2016-09-26 Thread Yijing Wang
Now the libsas hotplug has some issues, Dan Williams report
a similar bug here:
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg39187.html

The root cause of the issues is we use one workqueue(shost->work_q) to
process libsas event, and we divide a hot-on or hot-remove flow to several
events to process. E.g. we start a new work and queue it into the same
workqueue in sas_deform_port() to remove the children devices after
the sas port. So if there is one hot-on event between remove sas port
and destruct the children devices, some unexpected errors would
be caused.

This patch modify hotplug event process mechanism to solve the
hotplug problems in libsas. We move device add/del operation to
a new workqueue(named sas_dev_wq).

And we use sas_port_alloc_num to replace sas_port_alloc function
because when discovery is concurrently executing with the device
adding or destroying, the old sas port resource may have not
completely deleted, the new sas port resource of the same name
will be created, and this will cause calltrace about sysfs
device node.

Signed-off-by: Yijing Wang 
Signed-off-by: Yousong He 
Signed-off-by: Qilin Chen 
---
 drivers/scsi/libsas/sas_ata.c   |  34 ++---
 drivers/scsi/libsas/sas_discover.c  | 245 ++--
 drivers/scsi/libsas/sas_expander.c  |  54 ++--
 drivers/scsi/libsas/sas_init.c  |  26 +++-
 drivers/scsi/libsas/sas_internal.h  |  46 ++-
 drivers/scsi/libsas/sas_port.c  |  12 +-
 drivers/scsi/libsas/sas_scsi_host.c |  23 
 include/scsi/libsas.h   |   5 +-
 include/scsi/sas_ata.h  |   4 +-
 9 files changed, 340 insertions(+), 109 deletions(-)

diff --git a/drivers/scsi/libsas/sas_ata.c b/drivers/scsi/libsas/sas_ata.c
index 763f012..877efa8 100644
--- a/drivers/scsi/libsas/sas_ata.c
+++ b/drivers/scsi/libsas/sas_ata.c
@@ -619,32 +619,22 @@ static int sas_get_ata_command_set(struct domain_device 
*dev)
return ata_dev_classify();
 }
 
-void sas_probe_sata(struct asd_sas_port *port)
+void sas_probe_sata_device(struct domain_device *dev)
 {
-   struct domain_device *dev, *n;
-
-   mutex_lock(>ha->disco_mutex);
-   list_for_each_entry(dev, >disco_list, disco_list_node) {
-   if (!dev_is_sata(dev))
-   continue;
-
-   ata_sas_async_probe(dev->sata_dev.ap);
-   }
-   mutex_unlock(>ha->disco_mutex);
+   struct asd_sas_port *port = dev->port;
 
-   list_for_each_entry_safe(dev, n, >disco_list, disco_list_node) {
-   if (!dev_is_sata(dev))
-   continue;
+   if (!port || !port->ha || !dev_is_sata(dev))
+   return;
 
-   sas_ata_wait_eh(dev);
+   ata_sas_async_probe(dev->sata_dev.ap);
 
-   /* if libata could not bring the link up, don't surface
-* the device
-*/
-   if (ata_dev_disabled(sas_to_ata_dev(dev)))
-   sas_fail_probe(dev, __func__, -ENODEV);
-   }
+   sas_ata_wait_eh(dev);
 
+   /* if libata could not bring the link up, don't surface
+* the device
+*/
+   if (ata_dev_disabled(sas_to_ata_dev(dev)))
+   sas_fail_probe(dev, __func__, -ENODEV);
 }
 
 static void sas_ata_flush_pm_eh(struct asd_sas_port *port, const char *func)
@@ -729,7 +719,7 @@ int sas_discover_sata(struct domain_device *dev)
if (res)
return res;
 
-   sas_discover_event(dev->port, DISCE_PROBE);
+   sas_notify_device_event(dev, SAS_DEVICE_ADD);
return 0;
 }
 
diff --git a/drivers/scsi/libsas/sas_discover.c 
b/drivers/scsi/libsas/sas_discover.c
index 60de662..ea57c66 100644
--- a/drivers/scsi/libsas/sas_discover.c
+++ b/drivers/scsi/libsas/sas_discover.c
@@ -34,6 +34,12 @@
 #include 
 #include "../scsi_sas_internal.h"
 
+
+static void sas_unregister_common_dev(struct asd_sas_port *port,
+   struct domain_device *dev);
+static void sas_unregister_fail_dev(struct asd_sas_port *port,
+   struct domain_device *dev);
+
 /* -- Basic task processing for discovery purposes -- */
 
 void sas_init_dev(struct domain_device *dev)
@@ -158,11 +164,8 @@ static int sas_get_port_device(struct asd_sas_port *port)
 
if (dev_is_sata(dev) || dev->dev_type == SAS_END_DEVICE)
list_add_tail(>disco_list_node, >disco_list);
-   else {
-   spin_lock_irq(>dev_list_lock);
-   list_add_tail(>dev_list_node, >dev_list);
-   spin_unlock_irq(>dev_list_lock);
-   }
+   else
+   list_add_tail(>dev_list_node, >expander_list);
 
spin_lock_irq(>phy_list_lock);
list_for_each_entry(phy, >phy_list, port_phy_el)
@@ -212,34 +215,83 @@ void sas_notify_lldd_dev_gone(struct domain_device *dev)
}
 }
 
-static void sas_probe_devices(struct 

Re: [x86-tip] strange nr_cpus= boot regression

2016-09-26 Thread Mike Galbraith
On Mon, 2016-09-26 at 15:35 -0400, Thomas Gleixner wrote:
> On Mon, 26 Sep 2016, Thomas Gleixner wrote:
> > Can you please provide your .config and the dmesg of a bad and a good run?
> 
> Don't bother. I found it.
> 
> It's a merge artifact. So git bisect pointing at the merge commit is
> entirely correct.
> 
> mainline moves 
> 
>   >  num_processors++;
> 
> to a different place in the function. See commit c291b0151585.
> 
> Now the nodeid patch set in x86/apic does not have this commit and so
> f7c28833c2520 removes  num_processors++ from the original location before
> c291b0151585.

Whew, no mythical creature infestation.  Thanks, next encounter with
such an artifact should provide markedly less entertainment.

-Mike


RE: Regression in 4.8 - CPU speed set very low

2016-09-26 Thread Doug Smythies
On 2016.09.26 18:31 Srinivas Pandruvada wrote:
> On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote:
>> On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote: 
>>> On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger wrote:
>>> But for both we need a reproducer anyway.
>> I do not have a reliable reproducer. The condition has always
>> happened when 
>> running a high-compute job such as a 'make -j8' on the kernel, or
>> building the 
>> RPM for openSUSE's implementation of VirtualBox. The latter is what
>> I'm using 
>> for most of my testing.

Run some CPU stressor and get all your CPU's going at 100% load.
And watch your core temperatures while you do so.

> 
>>> It also would be good to rule out the thermal throttling (as per
>>> the Srinivas' comments).

It is almost certainly thermal throttling, or similar causing
Clock modulation, of it seems 50%.

>>> 
>>> For now, please tell me what's in
>>> /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
>> 80
> Your effective freq is lower than 800MHz. One of the possible reason is
> thermal throttling.
>
> What distro you are using?

And what make and model of LapTop?





Re: [PATCH 00/17] clean up readlinks

2016-09-26 Thread Al Viro
On Mon, Sep 12, 2016 at 09:29:02PM +0200, Miklos Szeredi wrote:
> The first patch is actually a bug fix, but I put it into this bunch for
> simplicity...
> 
> The rest are really cleanups as well as minor bugfixes that are byproducts
> of the cleanups.
> 
> This series builds on the fact that i_op.readlink is already set to
> generic_readlink() in 43/50 of the cases.  And of those 7 only 4 are doing
> something special.  So more than 90% of readlinks are/could actually just
> call back into get_link.
> 
> The interesting cases are:
> 
>  - AFS, which has readlink but not get_link
>  - proc, that allow jumping while following symlinks
> 
> The first is handled by setting IOP_NOFOLLOW on the inode by the fs.
> 
> The second one is handled by introducing is_following_link() which returns
> a bool depending on whether current->nameidata is NULL or not.  If it
> returns false ->get_link() should behave as ->readlink() did.  Otherwise it
> should behave as id did previously.
> 
> Builds and boots.  Can even read symlinks.

I have no problem with "let's get rid of generic_readlink" - not that
it bought us much, but sure, if you want to have decision made based upon
the combination of flags, let's do it.  Just make NULL ->readlink + non-NULL
->get_link() mean generic_readlink(), and we are done.  Especially if you
do the usual "set the flag on inode the first time we need to check".
I also have no problem with overlayfs and ecryptfs assuming that we only deal
with normal symlinks.

Overloading ->get_link() for procfs-style ones is just plain wrong,
though.  Your current->nameidata != NULL thing is bloody brittle - what
happens if some code triggers those readlinks when called by something
during pathname resolution?  Sure, right now existing callers won't.
But it doesn't take much to grow such a place _and_ have the implications
go unnoticed for quite a while.


Re: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

2016-09-26 Thread Herbert Xu
On Mon, Sep 26, 2016 at 02:43:17PM -0300, Marcelo Cerri wrote:
> 
> Wouldn't be enough to provide a pair of import/export functions as the
> padlock-sha driver does?

I don't think that will help as ultimately you need to call the
export function on the fallback and that's what requires the extra
memory.  In fact very operation involving the fallback will need
that extra memory too.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode for FW update

2016-09-26 Thread 'Dmitry Torokhov'
On Mon, Sep 26, 2016 at 10:30:56AM +0800, Johnny.Chuang wrote:
> There is only one different which is adding a new empty line for coding
> style.
> 
> > if (!error)
> > -   error = elants_i2c_query_fw_id(ts);
> > +   error = error2;
> > +
> > if (!error)
> > error = elants_i2c_query_fw_version(ts);

OK, since I already applied the other version I'll ignore this one as
the difference is not important.

Thanks.

> 
> -Original Message-
> From: Dmitry Torokhov [mailto:dmitry.torok...@gmail.com] 
> Sent: Saturday, September 24, 2016 5:31 AM
> To: Johnny Chuang
> Cc: Daniel Kurtz; Jennifer Tsai; linux-kernel@vger.kernel.org;
> linux-in...@vger.kernel.org; James Chen; Paul Liang; Jeff Chuang; Agnes
> Cheng
> Subject: Re: [PATCH v3] Input: elants_i2c - get product id on recovery mode
> for FW update
> 
> On Fri, Sep 23, 2016 at 04:01:17PM +0800, Johnny Chuang wrote:
> > This CL takes the responsibility for getting product/hardware id on 
> > recovery mode.
> > It will fix firmware update script could not find correspond firmware 
> > file name on recovery mode.
> > BTW, firmware must need to support reading product/hardware id on boot 
> > code.
> > 
> > Signed-off-by: Johnny Chuang 
> 
> This appears to be exactly the same as to what I already have in my "next"
> branch...
> 
> > ---
> >  drivers/input/touchscreen/elants_i2c.c | 31 
> > ---
> >  1 file changed, 20 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/input/touchscreen/elants_i2c.c 
> > b/drivers/input/touchscreen/elants_i2c.c
> > index ac09855..02aec28 100644
> > --- a/drivers/input/touchscreen/elants_i2c.c
> > +++ b/drivers/input/touchscreen/elants_i2c.c
> > @@ -298,7 +298,7 @@ static u16 elants_i2c_parse_version(u8 *buf)
> > return get_unaligned_be32(buf) >> 4;  }
> >  
> > -static int elants_i2c_query_fw_id(struct elants_data *ts)
> > +static int elants_i2c_query_hw_version(struct elants_data *ts)
> >  {
> > struct i2c_client *client = ts->client;
> > int error, retry_cnt;
> > @@ -318,8 +318,13 @@ static int elants_i2c_query_fw_id(struct elants_data
> *ts)
> > error, (int)sizeof(resp), resp);
> > }
> >  
> > -   dev_err(>dev,
> > -   "Failed to read fw id or fw id is invalid\n");
> > +   if (error) {
> > +   dev_err(>dev,
> > +   "Failed to read fw id: %d\n", error);
> > +   return error;
> > +   }
> > +
> > +   dev_err(>dev, "Invalid fw id: %#04x\n", ts->hw_version);
> >  
> > return -EINVAL;
> >  }
> > @@ -508,7 +513,7 @@ static int elants_i2c_fastboot(struct i2c_client 
> > *client)  static int elants_i2c_initialize(struct elants_data *ts)  {
> > struct i2c_client *client = ts->client;
> > -   int error, retry_cnt;
> > +   int error, error2, retry_cnt;
> > const u8 hello_packet[] = { 0x55, 0x55, 0x55, 0x55 };
> > const u8 recov_packet[] = { 0x55, 0x55, 0x80, 0x80 };
> > u8 buf[HEADER_SIZE];
> > @@ -553,18 +558,22 @@ static int elants_i2c_initialize(struct elants_data
> *ts)
> > }
> > }
> >  
> > +   /* hw version is available even if device in recovery state */
> > +   error2 = elants_i2c_query_hw_version(ts);
> > if (!error)
> > -   error = elants_i2c_query_fw_id(ts);
> > +   error = error2;
> > +
> > if (!error)
> > error = elants_i2c_query_fw_version(ts);
> > +   if (!error)
> > +   error = elants_i2c_query_test_version(ts);
> > +   if (!error)
> > +   error = elants_i2c_query_bc_version(ts);
> > +   if (!error)
> > +   error = elants_i2c_query_ts_info(ts);
> >  
> > -   if (error) {
> > +   if (error)
> > ts->iap_mode = ELAN_IAP_RECOVERY;
> > -   } else {
> > -   elants_i2c_query_test_version(ts);
> > -   elants_i2c_query_bc_version(ts);
> > -   elants_i2c_query_ts_info(ts);
> > -   }
> >  
> > return 0;
> >  }
> > --
> > 1.8.3.2
> > 
> 
> -- 
> Dmitry
> 

-- 
Dmitry


Re: Regression in 4.8 - CPU speed set very low

2016-09-26 Thread Larry Finger

On 09/26/2016 08:30 PM, Srinivas Pandruvada wrote:

On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote:

On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote:


On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger  wrote:


On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote:



On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger

 wrote:




Maybe it's better to try diagnose the problem instead of
spending more
time on bisection.


In my original post, I asked for such help, but nothing until
today. I had
no idea what to check, but now I have a better idea.



I'd like to know whether or not 4.7 was definitely good,
though.


I never saw this problem with 4.7, but given the difficulty in
triggering
the problem, my tests may not have been definitive.






If it is one of them, it may be a while before I dare call
this one
"good".
In one respect, that is good as I will be traveling tomorrow
and
Wednesday.


What does "cat
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say?


intel_pstate

You probably don't need to worry about all of the cpufreq changes
in
4.8-rc, then.  Only a few of them affect intel_pstate and I don't
see
how any of them may lead to the observed symptoms.

First off, if you have a reproducer, please run it on 4.7 and see
if
you can trigger the issue in there.

I'm running 4.8-rc7 at the moment hoping to trigger the problem and
get the data
requested by Srinivas. Once I get that, I will try 4.7 again.



Second, it would be good to have a look at the output from the
cpu_frequency and pstate_sample tracepoints around when the issue
triggers.  The pstate_sample one would be more interesting.

But for both we need a reproducer anyway.

I do not have a reliable reproducer. The condition has always
happened when
running a high-compute job such as a 'make -j8' on the kernel, or
building the
RPM for openSUSE's implementation of VirtualBox. The latter is what
I'm using
for most of my testing.



It also would be good to rule out the thermal throttling (as per
the
Srinivas' comments).

For now, please tell me what's in
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq

80

Your effective freq is lower than 800MHz. One of the possible reason is
thermal throttling.

What distro you are using?


openSUSE Leap 42.1.

Larry




Re: [PATCH] watchdog: hpwdt: add support for iLO5

2016-09-26 Thread Guenter Roeck

On 09/26/2016 11:57 AM, Brian Boylston wrote:

iLO5 will offer the same watchdog timer as previous generations, but the
PCI subsystem vendor ID will be PCI_VENDOR_ID_HP_3PAR (0x1590) instead of
PCI_VENDOR_ID_HP (0x103c).  Add 0x1590 to the whitelist and be more
specific when ignoring the 103c,1979 device.

Signed-off-by: Brian Boylston 


Reviewed-by: Guenter Roeck 


---
 drivers/watchdog/hpwdt.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/watchdog/hpwdt.c b/drivers/watchdog/hpwdt.c
index 8f89bd8..70c7194 100644
--- a/drivers/watchdog/hpwdt.c
+++ b/drivers/watchdog/hpwdt.c
@@ -39,7 +39,7 @@
 #include 
 #include 

-#define HPWDT_VERSION  "1.3.3"
+#define HPWDT_VERSION  "1.4.0"
 #define SECS_TO_TICKS(secs)((secs) * 1000 / 128)
 #define TICKS_TO_SECS(ticks)   ((ticks) * 128 / 1000)
 #define HPWDT_MAX_TIMERTICKS_TO_SECS(65535)
@@ -814,7 +814,8 @@ static int hpwdt_init_one(struct pci_dev *dev,
 * not run on a legacy ASM box.
 * So we only support the G5 ProLiant servers and higher.
 */
-   if (dev->subsystem_vendor != PCI_VENDOR_ID_HP) {
+   if (dev->subsystem_vendor != PCI_VENDOR_ID_HP &&
+   dev->subsystem_vendor != PCI_VENDOR_ID_HP_3PAR) {
dev_warn(>dev,
"This server does not have an iLO2+ ASIC.\n");
return -ENODEV;
@@ -823,7 +824,8 @@ static int hpwdt_init_one(struct pci_dev *dev,
/*
 * Ignore all auxilary iLO devices with the following PCI ID
 */
-   if (dev->subsystem_device == 0x1979)
+   if (dev->subsystem_vendor == PCI_VENDOR_ID_HP &&
+   dev->subsystem_device == 0x1979)
return -ENODEV;

if (pci_enable_device(dev)) {





Re: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages

2016-09-26 Thread Chao Yu
On 2016/9/27 9:39, Jaegeuk Kim wrote:
> On Tue, Sep 27, 2016 at 08:57:41AM +0800, Chao Yu wrote:
>> Hi Jaegeuk,
>>
>> On 2016/9/27 2:33, Jaegeuk Kim wrote:
>>> Hi Chao,
>>>
>>> On Tue, Sep 27, 2016 at 12:09:52AM +0800, Chao Yu wrote:
 From: Chao Yu 

 In sync_node_pages, we won't check and commit last merged pages in private
 bio cache of f2fs, as these pages were taged as writeback, someone who is
 waiting for writebacking of the page will be blocked until the cache was
 committed by someone else.

 We need to commit node type bio cache to avoid potential deadlock or long
 delay of waiting writeback.

 Signed-off-by: Chao Yu 
 ---
  fs/f2fs/node.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)

 diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
 index 9faddcd..f73f774 100644
 --- a/fs/f2fs/node.c
 +++ b/fs/f2fs/node.c
 @@ -1416,6 +1416,7 @@ int sync_node_pages(struct f2fs_sb_info *sbi, struct 
 writeback_control *wbc)
struct pagevec pvec;
int step = 0;
int nwritten = 0;
 +  int ret = 0;
  
pagevec_init(, 0);
  
 @@ -1436,7 +1437,8 @@ next_step:
  
if (unlikely(f2fs_cp_error(sbi))) {
pagevec_release();
 -  return -EIO;
 +  ret = -EIO;
 +  goto out;
}
  
/*
 @@ -1487,6 +1489,8 @@ continue_unlock:
  
if (NODE_MAPPING(sbi)->a_ops->writepage(page, wbc))
unlock_page(page);
 +  else
 +  nwritten++;
  
if (--wbc->nr_to_write == 0)
break;
 @@ -1504,7 +1508,10 @@ continue_unlock:
step++;
goto next_step;
}
 -  return nwritten;
 +out:
 +  if (nwritten)
 +  f2fs_submit_merged_bio(sbi, NODE, WRITE);
>>>
>>> IIRC, we don't need to flush this, since f2fs_submit_merged_bio_cond() would
>>> handle this in f2fs_wait_on_page_writeback().
>>
>> Yes, it covers all the cases in f2fs private codes, but there are still some
>> codes in mm or fs directory, and they didn't use f2fs_wait_on_page_writeback
>> when waiting page writeback. Such as do_writepages && filemap_fdatawait in
>> __writeback_single_inode...
> 
> The do_writepages() is okay, which will call f2fs_write_node_pages().
> The __writeback_single_inode() won't do filemap_fdatawait() with WB_SYNC_ALL.
> We don't need to take care of truncation as well.
> 
> Any missing one?

Another is: while testing with first version of checkpoint error injection, I
encounter below dump stack:

"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
mount   D 8801c1bf7960 0 97685  97397 0x0008
 8801c1bf7960 8801c1bf7930 88017590 8801c1bf7980
 8801c1bf8000  7fff 88021f7be340
 817c8880 8801c1bf7978 817c80a5 880214f58fc0
Call Trace:
 [] ? bit_wait+0x50/0x50
 [] schedule+0x35/0x80
 [] schedule_timeout+0x292/0x3d0
 [] ? xen_clocksource_get_cycles+0x15/0x20
 [] ? ktime_get+0x3c/0xb0
 [] ? bit_wait+0x50/0x50
 [] io_schedule_timeout+0xa6/0x110
 [] bit_wait_io+0x1b/0x60
 [] __wait_on_bit+0x64/0x90
 [] wait_on_page_bit+0xc4/0xd0
 [] ? autoremove_wake_function+0x40/0x40
 [] truncate_inode_pages_range+0x409/0x840
 [] ? pcpu_free_area+0x13d/0x1a0
 [] ? wake_up_bit+0x25/0x30
 [] truncate_inode_pages_final+0x4c/0x60
 [] f2fs_evict_inode+0x48/0x390 [f2fs]
 [] evict+0xc7/0x1a0
 [] iput+0x197/0x200
 [] f2fs_fill_super+0xab2/0x1130 [f2fs]
 [] mount_bdev+0x184/0x1c0
 [] ? f2fs_commit_super+0x100/0x100 [f2fs]
 [] f2fs_mount+0x15/0x20 [f2fs]
 [] mount_fs+0x39/0x160
 [] vfs_kern_mount+0x67/0x110
 [] do_mount+0x1bb/0xc80
 [] SyS_mount+0x83/0xd0
 [] do_syscall_64+0x6e/0x170
 [] entry_SYSCALL64_slow_path+0x25/0x25

Any thoughts?

> 
>>
>> Thanks,
>>
>>>
>>> Thanks,
>>>
 +  return ret;
  }
  
  int wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino)
 -- 
 2.7.2
>>>
>>> .
>>>
> 
> .
> 



Re: [x86-tip] strange nr_cpus= boot regression

2016-09-26 Thread Dou Liyang

Hi tglx,

I'm sorry for the late reply.
Awfully sorry that I could not do anything help.

In fact, it's my fault.
I should re-base my patches after the commit c291b0151585 in time.

I learned a lot from it.
Thank a lot, and once again my apologies.

Thanks,

Dou

At 09/27/2016 01:36 AM, Thomas Gleixner wrote:

CC'ed: Dou Liyang

On Mon, 26 Sep 2016, Mike Galbraith wrote:


I've encountered a strange regression in tip, symptom is that if you
boot with nr_cpus=nr_you_have, what actually boots is nr_you_have/2.
 Do not pass nr_cpus=, and all is well.


What's the number of possible cpus in your system?


Bisection repeatedly goes as below, pointing to the nodeid merge,
despite both timers/core and x86/apic (nodeid) being fine.  Take tip
HEAD, extract all of the commits from nodeid (plus the fix), and revert
them in a quilt tree, the tree remains busted.


So you remove all the nodeid commits from tip/master and it's still broken?


Checkout the timers/core merge commit, and merge nodeid with that, it is
indeed bad.



Bisecting  takes you right the merge commit, with no commit
being 'bad', see logs.


That's more than strange. An empty merge commit being the culprit.

Thanks,

tglx







[PATCH v2] f2fs: introduce get_checkpoint_version for cleanup

2016-09-26 Thread Tiezhu Yang
There exists almost same codes when get the value of pre_version
and cur_version in function validate_checkpoint, this patch adds
get_checkpoint_version to clean up redundant codes.

Signed-off-by: Tiezhu Yang 
---
 fs/f2fs/checkpoint.c | 63 ++--
 1 file changed, 37 insertions(+), 26 deletions(-)

diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index de8693c..2dbc834 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -663,45 +663,56 @@ static void write_orphan_inodes(struct f2fs_sb_info *sbi, 
block_t start_blk)
}
 }
 
-static struct page *validate_checkpoint(struct f2fs_sb_info *sbi,
-   block_t cp_addr, unsigned long long *version)
+static int get_checkpoint_version(struct f2fs_sb_info *sbi, block_t cp_addr,
+   struct f2fs_checkpoint *cp_block, struct page *cp_page,
+   unsigned long long *version)
 {
-   struct page *cp_page_1, *cp_page_2 = NULL;
unsigned long blk_size = sbi->blocksize;
-   struct f2fs_checkpoint *cp_block;
-   unsigned long long cur_version = 0, pre_version = 0;
-   size_t crc_offset;
+   size_t crc_offset = 0;
__u32 crc = 0;
 
-   /* Read the 1st cp block in this CP pack */
-   cp_page_1 = get_meta_page(sbi, cp_addr);
+   cp_page = get_meta_page(sbi, cp_addr);
+   cp_block = (struct f2fs_checkpoint *)page_address(cp_page);
 
-   /* get the version number */
-   cp_block = (struct f2fs_checkpoint *)page_address(cp_page_1);
crc_offset = le32_to_cpu(cp_block->checksum_offset);
-   if (crc_offset >= blk_size)
-   goto invalid_cp1;
+   if (crc_offset >= blk_size) {
+   f2fs_msg(sbi->sb, KERN_WARNING,
+   "%s: crc_offset is greater than or equal to blk_size.",
+   __func__);
+   return -EINVAL;
+   }
 
crc = le32_to_cpu(*((__le32 *)((unsigned char *)cp_block + 
crc_offset)));
-   if (!f2fs_crc_valid(sbi, crc, cp_block, crc_offset))
-   goto invalid_cp1;
+   if (!f2fs_crc_valid(sbi, crc, cp_block, crc_offset)) {
+   f2fs_msg(sbi->sb, KERN_WARNING,
+   "%s: f2fs_crc_valid returns false.", __func__);
+   return -EINVAL;
+   }
 
-   pre_version = cur_cp_version(cp_block);
+   *version = cur_cp_version(cp_block);
+   return 0;
+}
 
-   /* Read the 2nd cp block in this CP pack */
-   cp_addr += le32_to_cpu(cp_block->cp_pack_total_block_count) - 1;
-   cp_page_2 = get_meta_page(sbi, cp_addr);
+static struct page *validate_checkpoint(struct f2fs_sb_info *sbi,
+   block_t cp_addr, unsigned long long *version)
+{
+   struct page *cp_page_1 = NULL, *cp_page_2 = NULL;
+   struct f2fs_checkpoint *cp_block = NULL;
+   unsigned long long cur_version = 0, pre_version = 0;
+   int err;
 
-   cp_block = (struct f2fs_checkpoint *)page_address(cp_page_2);
-   crc_offset = le32_to_cpu(cp_block->checksum_offset);
-   if (crc_offset >= blk_size)
-   goto invalid_cp2;
+   err = get_checkpoint_version(sbi, cp_addr, cp_block,
+   cp_page_1, version);
+   if (err)
+   goto invalid_cp1;
+   pre_version = *version;
 
-   crc = le32_to_cpu(*((__le32 *)((unsigned char *)cp_block + 
crc_offset)));
-   if (!f2fs_crc_valid(sbi, crc, cp_block, crc_offset))
+   cp_addr += le32_to_cpu(cp_block->cp_pack_total_block_count) - 1;
+   err = get_checkpoint_version(sbi, cp_addr, cp_block,
+   cp_page_2, version);
+   if (err)
goto invalid_cp2;
-
-   cur_version = cur_cp_version(cp_block);
+   cur_version = *version;
 
if (cur_version == pre_version) {
*version = cur_version;
-- 
1.8.3.1

Re: [PATCH v3] net: ip, diag -- Add diag interface for raw sockets

2016-09-26 Thread David Ahern
On 9/26/16 4:38 PM, Cyrill Gorcunov wrote:
> Something like
> 
> Index: linux-ml.git/include/uapi/linux/inet_diag.h
> ===
> --- linux-ml.git.orig/include/uapi/linux/inet_diag.h2016-09-11 
> 20:56:18.191584145 +0300
> +++ linux-ml.git/include/uapi/linux/inet_diag.h 2016-09-27 01:34:08.413172394 
> +0300
> @@ -38,7 +38,7 @@ struct inet_diag_req_v2 {
> __u8sdiag_family;
> __u8sdiag_protocol;
> __u8idiag_ext;
> -   __u8pad;
> +   __u8sdiag_raw_protocol; /* SOCK_RAW only, @pad for others */

Seems like that should be a union to keep the API.


> __u32   idiag_states;
> struct inet_diag_sockid id;
>  };
> 
> and in raw-diag module we will use @sdiag_raw_protocol instead of
> @sdiag_protocol field. Didn't cover ss tool source code yet but
> I think the idea is seen. Still not sure if start using @pad here
> is a good idea (it's uapi), maybe beter to ask nla attribute which would
> come right afterh the inet_diag_req_v2 message?
> 

seems reasonable to me since 2 protocols need to be sent to the kernel.

Alternatively, sdiag_protocol could be the actual protocol and the pad union be 
a flag field with say bit 0 = INET_DIAG_FLAG_SOCK_RAW. Allows other overrides 
in the future if needed.


Re: [PATCH v5 8/8] iommu/amd: Update domain into to dte entry during device driver init

2016-09-26 Thread Baoquan He
On 09/20/16 at 02:53pm, Joerg Roedel wrote:
> Hmm, have you tried hooking this into the set_dma_mask call-back? Every
> driver should call it for its device, so that should be a better
> indicator to now map a new domain.

Hi Joerg,

I tried hooking this into set_dma_mask call-back, but on my local
machine with amd iommu v2, an ohci pci device doesn't call set_dma_mask.
Then IO_PAGE_FAULT printing flooded.

00:12.0 USB controller: Advanced Micro Devices, Inc. [AMD] FCH USB OHCI 
Controller (rev 11)

Below is the patch I made using set_dma_mask call-back. So should we do
as the original method, or use set_dma_mask method and add set_dma_mask
calling in those driver which missed calling it?


>From 1ca66f886a46839cb937fd1e6a1d84b6719f23c4 Mon Sep 17 00:00:00 2001
From: Baoquan He 
Date: Mon, 12 Sep 2016 08:05:15 +0800
Subject: [PATCH] iommu/amd: Update domain into to dte entry during device
 driver init

All devices are supposed to reset themselves at device driver initialization
stage. At this time if in kdump kernel those on-flight DMA will be stopped
because of device reset. It's best time to update the protection domain info,
especially pte_root, to dte entry which the device relates to. Usually
device driver initialization will call set_dma_mask to set the
limitation of dma address. Do it in set_dma_mask call-back is a good
chance.

Signed-off-by: Baoquan He 
---
 drivers/iommu/amd_iommu.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 6c37300..2a0b1ce 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -2653,6 +2653,27 @@ static int amd_iommu_dma_supported(struct device *dev, 
u64 mask)
return check_device(dev);
 }
 
+static int set_dma_mask(struct device *dev, u64 mask)
+{
+   struct iommu_dev_data *dev_data = get_dev_data(dev);
+   struct protection_domain *domain = get_domain(dev);
+   u16 alias = amd_iommu_alias_table[dev_data->devid];
+   struct amd_iommu *iommu = amd_iommu_rlookup_table[dev_data->devid];
+
+   if (translation_pre_enabled(iommu) && !dev_data->domain_updated) {
+   dev_data->domain_updated = true;
+   set_dte_entry(dev_data->devid, domain, dev_data->ats.enabled);
+   if (alias != dev_data->devid)
+   set_dte_entry(alias, domain, dev_data->ats.enabled);
+   device_flush_dte(dev_data);
+   }
+
+   if (!dev->dma_mask || !amd_iommu_dma_supported(dev, mask))
+   return -EIO;
+   *dev->dma_mask = mask;
+   return 0;
+}
+
 static struct dma_map_ops amd_iommu_dma_ops = {
.alloc  = alloc_coherent,
.free   = free_coherent,
@@ -2661,6 +2682,7 @@ static struct dma_map_ops amd_iommu_dma_ops = {
.map_sg = map_sg,
.unmap_sg   = unmap_sg,
.dma_supported  = amd_iommu_dma_supported,
+   .set_dma_mask   = set_dma_mask,
 };
 
 static int init_reserved_iova_ranges(void)
-- 
2.5.5



Re: [PATCH 3/4] autofs - make mountpoint checks namespace aware

2016-09-26 Thread Ian Kent
On Mon, 2016-09-26 at 11:05 -0500, Eric W. Biederman wrote:
> Ian Kent  writes:
> 
> > On Fri, 2016-09-23 at 14:15 -0500, Eric W. Biederman wrote:
> > > Ian Kent  writes:
> > > 
> > > 2> On Thu, 2016-09-22 at 20:37 -0500, Eric W. Biederman wrote:
> > > > > Ian Kent  writes:
> > > > > 
> > > > > > On Thu, 2016-09-22 at 10:43 -0500, Eric W. Biederman wrote:
> > > > > > > Ian Kent  writes:
> > > > > > > 
> > > > > > > > Eric, Mateusz, I appreciate your spending time on this and
> > > > > > > > particularly
> > > > > > > > pointing
> > > > > > > > out my embarrassingly stupid is_local_mountpoint() usage
> > > > > > > > mistake.
> > > > > > > > 
> > > > > > > > Please accept my apology for the inconvenience.
> > > > > > > > 
> > > > > > > > If all goes well (in testing) I'll have follow up patches to
> > > > > > > > correct
> > > > > > > > this
> > > > > > > > fairly
> > > > > > > > soon.
> > > > > > > 
> > > > > > > Related question.  Do you happen to know how many mounts per mount
> > > > > > > namespace tend to be used?  It looks like it is going to be wise
> > > > > > > to
> > > > > > > put
> > > > > > > a configurable limit on that number.  And I would like the default
> > > > > > > to
> > > > > > > be
> > > > > > > something high enough most people don't care.  I believe autofs is
> > > > > > > likely where people tend to use the most mounts.
> > > > 
> > > > Yes, I agree, I did want to try and avoid changing the parameters to
> > > > ->d_mamange() but passing a struct path pointer might be better in the
> > > > long
> > > > run
> > > > anyway.
> > > 
> > > Given that there is exactly one implementation of d_manage in the tree I
> > > don't imagine it will be disruptive to change that.
> > 
> > Yes, but it could be used by external modules.
> > 
> > And there's also have_submounts().
> 
> Good point about have_submounts.
> 
> > I can update that using the existing d_walk() infrastructure or take it
> > (mostly)
> > into the autofs module and get rid of have_submounts().
> > 
> > I'll go with the former to start with and see what people think.
> 
> That will be interesting to so.  It is not clear to me that if d_walk
> needs to be updated, and if d_walk doesn't need to be updated I would
> be surprised to see it take into autofs.  But I am happy to look at the
> end result and see what you come up with.

I didn't mean d_walk() itself, just the have_submounts() function that's used
only by autofs these days. That's all I'll be changing.

To take this functionality into the autofs module shouldn't be a big deal as it
amounts to a directory traversal with a check at each node.

But I vaguely remember talk of wanting to get rid of have_submounts() and autofs
being the only remaining user.

So I mentioned it to try and elicit a comment, ;)

> 
> Eric


Re: [PATCH 00/14] perf clang: Support compiling BPF script use builtin clang

2016-09-26 Thread Wangnan (F)



On 2016/9/27 7:58, Arnaldo Carvalho de Melo wrote:


Le 26 sept. 2016 8:47 PM, "Alexei Starovoitov" 
> a 
écrit :

>
> On Mon, Sep 26, 2016 at 09:49:30AM +0800, Wangnan (F) wrote:
> >
> >
> > On 2016/9/24 23:16, Alexei Starovoitov wrote:
> > >On Fri, Sep 23, 2016 at 12:49:47PM +, Wang Nan wrote:
> > >>This patch set is the first step to implement features I announced
> > >>in LinuxCon NA 2016. See page 31 of:
> > >>
> > >> 
http://events.linuxfoundation.org/sites/events/files/slides/Performance%20Monitoring%20and%20Analysis%20Using%20perf%20and%20BPF_1.pdf

> > >>
> > >>This patch set links LLVM and Clang libraries to perf, so perf
> > >>is able to compile BPF script to BPF object on the fly.
> > >Nice!
> > >So single perf binary won't have llvm external dependency anymore
> > >or both ways will be maintained?
> > >The command line stays the same?
> >
> > Yes. This patch set doesn't change interface. It compiles BPF script
> > with builtin clang, and if it fail, fall back to external clang.
> >
> > >If I understand the patches correctly, this set is establishing
> > >the basic functionality and more complex features coming?
> > >
> >
> > Yes. Following steps are:
> >
> >  1. Ease of use improvement: automatically include BPF functions
> > declaration and macros.
>
> +1
>
> >  2. Perf's hook: compile part of BPF script into native code, run
> > them in perf when something happen. Create a channel, coordinate
> > BPF and native code use bpf-output event.
>
> +1
>
> >  3. Define a new language to support common profiling task. I'm not
> > very clear what the new language should be. It may looks like lua,
> > perf converts it to C then to LLVM IR with builtin clang.
>
> Many tracing languages were invented in the past.
> At this point I'm not sure what exactly new language will solve.
> To make it easier to write bpf programs?
> I think it will be more fruitful to tweak clang/llvm to add
> good warnings/errors for cases where we know that C is not going
> be compiled into the code that the kernel verifier will accept.
> Like we can complain about loops, unitialized variables,
> non-inlined and unkown helper functions... all from clang/llvm.
> imo that would be the better path forward and will help
> both tracing and networking users that write in this restricted C.

++1
>



OK. Now let's focus on the first two goals. After that let's consider
how to help writing BPF program.

Thank you.




Re: [PATCH] of: thermal: Fixed governor at each thermal zone

2016-09-26 Thread Zhang Rui
On 一, 2016-09-19 at 10:18 +0900, Inhyuk Kang wrote:
> It is necessary to be added governor at each thermal_zone.
> Because some governors should be operated in the during the kernel
> booting
> in order to avoid heating problem.
> 
> Default governor cannot be covered all thermal zones policy because
> some thermal zones want to apply different one.
> For example, the power allocator governor operates differently with
> step wise governor.
> Hence, it is better to parse governor parameter from the device tree.
> 
> Signed-off-by: Inhyuk Kang 
> 
The patch looks okay to me.
Eduardo, what do you think of this patch?

thanks,
rui
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-
> thermal.c
> index b8e509c..382c440 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -970,6 +970,7 @@ int __init of_parse_thermal_zones(void)
>   struct thermal_zone_device *zone;
>   struct thermal_zone_params *tzp;
>   int i, mask = 0;
> + const char *governor;
>   u32 prop;
>  
>   tz = thermal_of_build_thermal_zone(child);
> @@ -996,6 +997,9 @@ int __init of_parse_thermal_zones(void)
>   if (!of_property_read_u32(child, "sustainable-
> power", ))
>   tzp->sustainable_power = prop;
>  
> + if (!of_property_read_string(child, "governor-name", 
> ))
> + strcpy(tzp->governor_name, governor);
> +
>   for (i = 0; i < tz->ntrips; i++)
>   mask |= 1 << i;
>  


linux-next: manual merge of the drm-exynos tree with the drm tree

2016-09-26 Thread Stephen Rothwell
Hi Inki,

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

  drivers/gpu/drm/exynos/exynos_drm_drv.c

between commit:

  2b58e98d42af ("drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support 
for plane commit")

from the drm tree and commit:

  3a87f9383457 ("drm/exynos: fix pending update handling")

from the drm-exynos tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/exynos/exynos_drm_drv.c
index 486943e70f70,a1bc13f4f30a..
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@@ -89,25 -63,9 +63,9 @@@ static void exynos_atomic_commit_comple
 * have the relevant clocks enabled to perform the update.
 */
  
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
- 
-   atomic_set(_crtc->pending_update, 0);
-   }
- 
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   struct exynos_drm_crtc *exynos_crtc =
-   to_exynos_crtc(plane->crtc);
- 
-   if (!plane->crtc)
-   continue;
- 
-   atomic_inc(_crtc->pending_update);
-   }
- 
 -  drm_atomic_helper_commit_planes(dev, state, false);
 +  drm_atomic_helper_commit_planes(dev, state, 0);
  
-   exynos_atomic_wait_for_commit(state);
+   drm_atomic_helper_wait_for_vblanks(dev, state);
  
drm_atomic_helper_cleanup_planes(dev, state);
  


Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression

2016-09-26 Thread Jaegeuk Kim
On Tue, Sep 27, 2016 at 08:50:02AM +0800, Huang, Ying wrote:
> Jaegeuk Kim  writes:
> 
> > On Mon, Sep 26, 2016 at 02:26:06PM +0800, Huang, Ying wrote:
> >> Hi, Jaegeuk,
> >> 
> >> "Huang, Ying"  writes:
> >> 
> >> > Jaegeuk Kim  writes:
> >> >
> >> >> Hello,
> >> >>
> >> >> On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote:
> >> >>> Hi Jaegeuk,
> >> >>> 
> >> >>> > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% regression
> >> >>> > > >> >
> >> >>> > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via 
> >> >>> > > >> > mdadm.  The
> >> >>> > > >> > steps for aim7 is,
> >> >>> > > >> >
> >> >>> > > >> > cat > workfile < >> >>> > > >> > FILESIZE: 1M
> >> >>> > > >> > POOLSIZE: 10M
> >> >>> > > >> > 10 sync_disk_rw
> >> >>> > > >> > EOF
> >> >>> > > >> >
> >> >>> > > >> > (
> >> >>> > > >> > echo $HOSTNAME
> >> >>> > > >> > echo sync_disk_rw
> >> >>> > > >> >
> >> >>> > > >> > echo 1
> >> >>> > > >> > echo 600
> >> >>> > > >> > echo 2
> >> >>> > > >> > echo 600
> >> >>> > > >> > echo 1
> >> >>> > > >> > ) | ./multitask -t &
> >> >>> > > >>
> >> >>> > > >> Any update on these 2 regressions?  Is the information is 
> >> >>> > > >> enough for you
> >> >>> > > >> to reproduce?
> >> >>> > > >
> >> >>> > > > Sorry, I've had no time to dig this due to business travel now.
> >> >>> > > > I'll check that when back to US.
> >> >>> > > 
> >> >>> > > Any update?
> >> >>> > 
> >> >>> > Sorry, how can I get multitask binary?
> >> >>> 
> >> >>> It's part of aim7, which can be downloaded here:
> >> >>> 
> >> >>> http://nchc.dl.sourceforge.net/project/aimbench/aim-suite7/Initial%20release/s7110.tar.Z
> >> >>
> >> >> Thank you for the codes.
> >> >>
> >> >> I've run this workload on the latest f2fs and compared performance 
> >> >> having
> >> >> without the reported patch. (1TB nvme SSD, 16 cores, 16GB DRAM)
> >> >> Interestingly, I could find slight performance improvement rather than
> >> >> regression. :(
> >> >> Not sure how to reproduce this.
> >> >
> >> > I think the difference lies on disk used.  The ramdisk is used in the
> >> > original test, but it appears that your memory is too small to setup the
> >> > RAM disk for test.  So it may be impossible for you to reproduce the
> >> > test unless you can find more memory :)
> >> >
> >> > But we can help you to root cause the issue.  What additional data do
> >> > you want?  perf-profile data before and after the patch?
> >> 
> >> Any update to this regression?
> >
> > Sorry, no. But meanwhile, I've purchased more DRAMs. :)
> > Now I'm with 128GB DRAM. I can configure 64GB as pmem.
> > Is it worth to try the test again?
> 
> I think you are the decision maker for this.  You can judge whether the
> test is reasonable.  And we can adjust our test accordingly.
> 
> BTW: For this test, we use brd ram disk and raid to test.

Okay, let me try this again.
Thanks,

> 
> Best Regards,
> Huang, Ying


Re: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages

2016-09-26 Thread Jaegeuk Kim
On Tue, Sep 27, 2016 at 08:57:41AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> On 2016/9/27 2:33, Jaegeuk Kim wrote:
> > Hi Chao,
> > 
> > On Tue, Sep 27, 2016 at 12:09:52AM +0800, Chao Yu wrote:
> >> From: Chao Yu 
> >>
> >> In sync_node_pages, we won't check and commit last merged pages in private
> >> bio cache of f2fs, as these pages were taged as writeback, someone who is
> >> waiting for writebacking of the page will be blocked until the cache was
> >> committed by someone else.
> >>
> >> We need to commit node type bio cache to avoid potential deadlock or long
> >> delay of waiting writeback.
> >>
> >> Signed-off-by: Chao Yu 
> >> ---
> >>  fs/f2fs/node.c | 11 +--
> >>  1 file changed, 9 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> >> index 9faddcd..f73f774 100644
> >> --- a/fs/f2fs/node.c
> >> +++ b/fs/f2fs/node.c
> >> @@ -1416,6 +1416,7 @@ int sync_node_pages(struct f2fs_sb_info *sbi, struct 
> >> writeback_control *wbc)
> >>struct pagevec pvec;
> >>int step = 0;
> >>int nwritten = 0;
> >> +  int ret = 0;
> >>  
> >>pagevec_init(, 0);
> >>  
> >> @@ -1436,7 +1437,8 @@ next_step:
> >>  
> >>if (unlikely(f2fs_cp_error(sbi))) {
> >>pagevec_release();
> >> -  return -EIO;
> >> +  ret = -EIO;
> >> +  goto out;
> >>}
> >>  
> >>/*
> >> @@ -1487,6 +1489,8 @@ continue_unlock:
> >>  
> >>if (NODE_MAPPING(sbi)->a_ops->writepage(page, wbc))
> >>unlock_page(page);
> >> +  else
> >> +  nwritten++;
> >>  
> >>if (--wbc->nr_to_write == 0)
> >>break;
> >> @@ -1504,7 +1508,10 @@ continue_unlock:
> >>step++;
> >>goto next_step;
> >>}
> >> -  return nwritten;
> >> +out:
> >> +  if (nwritten)
> >> +  f2fs_submit_merged_bio(sbi, NODE, WRITE);
> > 
> > IIRC, we don't need to flush this, since f2fs_submit_merged_bio_cond() would
> > handle this in f2fs_wait_on_page_writeback().
> 
> Yes, it covers all the cases in f2fs private codes, but there are still some
> codes in mm or fs directory, and they didn't use f2fs_wait_on_page_writeback
> when waiting page writeback. Such as do_writepages && filemap_fdatawait in
> __writeback_single_inode...

The do_writepages() is okay, which will call f2fs_write_node_pages().
The __writeback_single_inode() won't do filemap_fdatawait() with WB_SYNC_ALL.
We don't need to take care of truncation as well.

Any missing one?

> 
> Thanks,
> 
> > 
> > Thanks,
> > 
> >> +  return ret;
> >>  }
> >>  
> >>  int wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino)
> >> -- 
> >> 2.7.2
> > 
> > .
> > 


Re: [PATCH v2] fs/select: add vmalloc fallback for select(2)

2016-09-26 Thread Eric Dumazet
On Mon, 2016-09-26 at 17:01 -0700, Andrew Morton wrote:

> I don't share Eric's concerns about performance here.  If the vmalloc()
> is called, we're about to write to that quite large amount of memory
> which we just allocated, and the vmalloc() overhead will be relatively
> low.

I did not care of the performance of this particular select() system
call really, but other cpus because of more TLB invalidations.

At least CONFIG_DEBUG_PAGEALLOC=y builds should be impacted, but maybe
we do not care.




Re: Regression in 4.8 - CPU speed set very low

2016-09-26 Thread Srinivas Pandruvada
On Mon, 2016-09-26 at 19:48 -0500, Larry Finger wrote:
> On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote:
> > 
> > On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger  > r.net> wrote:
> > > 
> > > On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote:
> > > > 
> > > > 
> > > > On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger
> > >  wrote:
> > > > 
> > > > 
> > > > 
> > > > Maybe it's better to try diagnose the problem instead of
> > > > spending more
> > > > time on bisection.
> > > 
> > > In my original post, I asked for such help, but nothing until
> > > today. I had
> > > no idea what to check, but now I have a better idea.
> > > 
> > > > 
> > > > I'd like to know whether or not 4.7 was definitely good,
> > > > though.
> > > 
> > > I never saw this problem with 4.7, but given the difficulty in
> > > triggering
> > > the problem, my tests may not have been definitive.
> > > > 
> > > > 
> > > > 
> > > > > 
> > > > > If it is one of them, it may be a while before I dare call
> > > > > this one
> > > > > "good".
> > > > > In one respect, that is good as I will be traveling tomorrow
> > > > > and
> > > > > Wednesday.
> > > > 
> > > > What does "cat
> > > > /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say?
> > > 
> > > intel_pstate
> > You probably don't need to worry about all of the cpufreq changes
> > in
> > 4.8-rc, then.  Only a few of them affect intel_pstate and I don't
> > see
> > how any of them may lead to the observed symptoms.
> > 
> > First off, if you have a reproducer, please run it on 4.7 and see
> > if
> > you can trigger the issue in there.
> I'm running 4.8-rc7 at the moment hoping to trigger the problem and
> get the data 
> requested by Srinivas. Once I get that, I will try 4.7 again.
> > 
> > 
> > Second, it would be good to have a look at the output from the
> > cpu_frequency and pstate_sample tracepoints around when the issue
> > triggers.  The pstate_sample one would be more interesting.
> > 
> > But for both we need a reproducer anyway.
> I do not have a reliable reproducer. The condition has always
> happened when 
> running a high-compute job such as a 'make -j8' on the kernel, or
> building the 
> RPM for openSUSE's implementation of VirtualBox. The latter is what
> I'm using 
> for most of my testing.
> 
> > 
> > It also would be good to rule out the thermal throttling (as per
> > the
> > Srinivas' comments).
> > 
> > For now, please tell me what's in
> > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
> 80
Your effective freq is lower than 800MHz. One of the possible reason is
thermal throttling.

What distro you are using?


Thanks,
Srinivas



Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

2016-09-26 Thread Martin K. Petersen
> "Lee" == Lee Duncan  writes:

Lee,

Lee> Chris Leech and I are taking over as open-iscsi maintainers.

Do you want me to queue the MAINTAINER update?

Lee>  * Removed git repository, since code in tree

Is it your plan to go through the SCSI tree?

-- 
Martin K. Petersen  Oracle Linux Engineering


linux-next: build failure after merge of the rdma tree

2016-09-26 Thread Stephen Rothwell
Hi Doug,

After merging the rdma tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c: In function 
'kiblnd_hdev_setup_mrs':
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:7: error: implicit 
declaration of function 'ib_get_dma_mr' [-Werror=implicit-function-declaration]
  mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
   ^
drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c:2317:5: warning: assignment 
makes pointer from integer without a cast [-Wint-conversion]
  mr = ib_get_dma_mr(hdev->ibh_pd, acflags);
 ^

Caused by commit

  5ef990f06bd7 ("IB/core: remove ib_get_dma_mr")

I have used the rdma tree from next-20160923 for today.

-- 
Cheers,
Stephen Rothwell


RE: UFS API in the kernel

2016-09-26 Thread Kiwoong Kim
Hi.

If you want to declare some things for user interface,
is it be better to put those thing include/uapi/linux/ than include/linux?

Agreed with Mr. Pinto's opinion with respect to implementing additional ioctls.

Regards.

> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.org] On Behalf Of Shaun Tancheff
> Sent: Tuesday, September 27, 2016 4:23 AM
> To: Joao Pinto
> Cc: linux-s...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: UFS API in the kernel
> 
> On Thu, Sep 22, 2016 at 10:21 AM, Joao Pinto 
> wrote:
> > Hi!
> >
> > I am designing an application that has the goal to be an utility for
> > Unipro and UFS testing purposes. This application is going to run on
> > top of a recent Linux Kernel containing the new UFS stack (including the
> new DWC drivers).
> >
> > I am considering doing the following:
> > a) Create a new config item called CONFIG_UFS_CHARDEV which is going
> > to create a char device responsible to make some IOCTL available for
> > user-space applications
> > b) Create a linux/ufs.h header file that contains data structures
> > declarations that will be needed in user-space applications
> 
> I am not very familiar with UFS devices, that said you should have an sgX
> chardev being created already so you can handle SG_IO requests.
> There also appear to be some sysfs entries being created.
> 
> So between sg and sysfs you should be able to handle any user-space out of
> band requests without resorting to making a new chardev.
> 
> Adding more sysfs entries, if you need them, should be fine.
> 
> You may find it easier to expand on the existing interfaces than to get
> consensus on a new driver and ioctls.
> 
> Hope this helps,
> Shaun
> 
> > Could you please advise me about what the correct approach should be
> > to make it as standard as possible and usable in the future?
> >
> > Thank you very much for your help!
> >
> > regards,
> > Joao
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-scsi"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__vger.kernel.org_ma
> > jordomo-2Dinfo.html=DQICaQ=IGDlg0lD0b-nebmJJ0Kp8A=Wg5NqlNlVTT7Ug
> > l8V50qIHLe856QW0qfG3WVYGOrWzA=vJFB6pCywWtdvkgHz9Vc0jQz0xzeyZlr-7eCWY
> > u88nM=yiQLPFpqmMrbqLZz1Jb3aNqOje2dRMLJHEzUDobwcXc=
> 
> 
> 
> --
> Shaun Tancheff
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html




[PATCH] bus: qcom-ebi2: make it explicitly non-modular

2016-09-26 Thread Paul Gortmaker
The Kconfig currently controlling compilation of this code is:

drivers/bus/Kconfig:config QCOM_EBI2
drivers/bus/Kconfig:bool "Qualcomm External Bus Interface 2 (EBI2)"

...meaning that it currently is not being built as a module by anyone.

Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.

Since module_platform_driver() uses the same init level priority as
builtin_platform_driver() the init ordering remains unchanged with
this commit.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

We don't replace module.h with init.h since the file already has that.

Cc: Linus Walleij 
Signed-off-by: Paul Gortmaker 
---
 drivers/bus/qcom-ebi2.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/bus/qcom-ebi2.c b/drivers/bus/qcom-ebi2.c
index a6444244c411..d34a6ef02827 100644
--- a/drivers/bus/qcom-ebi2.c
+++ b/drivers/bus/qcom-ebi2.c
@@ -14,7 +14,6 @@
  * hardware.
  */
 
-#include 
 #include 
 #include 
 #include 
@@ -402,7 +401,4 @@ static struct platform_driver qcom_ebi2_driver = {
.of_match_table = qcom_ebi2_of_match,
},
 };
-module_platform_driver(qcom_ebi2_driver);
-MODULE_AUTHOR("Linus Walleij ");
-MODULE_DESCRIPTION("Qualcomm EBI2 driver");
-MODULE_LICENSE("GPL");
+builtin_platform_driver(qcom_ebi2_driver);
-- 
2.10.0



[PATCH] padata: remove recently added module usage from bool code

2016-09-26 Thread Paul Gortmaker
In commit 30e92153b4e6 ("padata: Convert to hotplug state machine")
this file started using module.h and got module_init and module_exit
added to it.

However the Kconfig for it is:

   init/Kconfig:config PADATA
   init/Kconfig:   depends on SMP
   init/Kconfig:   bool

...and so it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.

Cc: Steffen Klassert 
Cc: Thomas Gleixner 
Cc: Sebastian Andrzej Siewior 
Cc: linux-cry...@vger.kernel.org
Signed-off-by: Paul Gortmaker 
---
 kernel/padata.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/kernel/padata.c b/kernel/padata.c
index 7848f0566403..355807e52b1e 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -30,7 +30,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define MAX_OBJ_NUM 1000
 
@@ -1043,11 +1043,6 @@ static __init int padata_driver_init(void)
hp_online = ret;
return 0;
 }
-module_init(padata_driver_init);
+device_initcall(padata_driver_init);
 
-static __exit void padata_driver_exit(void)
-{
-   cpuhp_remove_multi_state(hp_online);
-}
-module_exit(padata_driver_exit);
 #endif
-- 
2.10.0



Re: [PATCH 1/3] megaraid_sas: mark symbols static where possible

2016-09-26 Thread Martin K. Petersen
> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get a few warnings when building kernel with W=1:
Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:94:5: warning: no
Baoyou> previous prototype for 'mega_mod64' [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:112:5: warning: no
Baoyou> previous prototype for 'mega_div64_32' [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:177:6: warning: no
Baoyou> previous prototype for 'MR_PopulateDrvRaidMap'
Baoyou> [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:315:5: warning: no
Baoyou> previous prototype for 'MR_GetSpanBlock' [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:451:5: warning: no
Baoyou> previous prototype for 'mr_spanset_get_span_block'
Baoyou> [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:692:4: warning: no
Baoyou> previous prototype for 'get_arm' [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:815:4: warning: no
Baoyou> previous prototype for 'MR_GetPhyParams' [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fp.c:1293:4: warning: no
Baoyou> previous prototype for 'megasas_get_best_arm_pd'
Baoyou> [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fusion.c:106:1: warning: no
Baoyou> previous prototype for 'megasas_enable_intr_fusion'
Baoyou> [-Wmissing-prototypes]
Baoyou> drivers/scsi/megaraid/megaraid_sas_fusion.c:127:1: warning: no
Baoyou> previous prototype for 'megasas_disable_intr_fusion'
Baoyou> [-Wmissing-prototypes] 

Does not apply. Please make sure your patches are against my for-next
branch.

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCHv2] MAINTAINERS: Update open-iscsi maintainers

2016-09-26 Thread Christoph Hellwig
On Mon, Sep 26, 2016 at 03:25:30PM -0700, Lee Duncan wrote:
> Chris Leech and I are taking over as open-iscsi maintainers.

Can we get rid of the horribly unusable googlegroups list and just
move everything to linux-scsi while we're at it?


Re: [PATCH] [SCSI] mvsas: mark symbols static where possible

2016-09-26 Thread Martin K. Petersen
> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get a few warnings when building kernel with W=1:
Baoyou> drivers/scsi/mvsas/mv_sas.c:77:18: warning: no previous
Baoyou> prototype for 'mvs_find_dev_mvi' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_sas.c:105:5: warning: no previous
Baoyou> prototype for 'mvs_find_dev_phyno' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_sas.c:1161:20: warning: no previous
Baoyou> prototype for 'mvs_alloc_dev' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_sas.c:1178:6: warning: no previous
Baoyou> prototype for 'mvs_free_dev' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_sas.c:1188:5: warning: no previous
Baoyou> prototype for 'mvs_dev_found_notify' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_sas.c:1244:6: warning: no previous
Baoyou> prototype for 'mvs_dev_gone_notify' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_sas.c:1614:6: warning: no previous
Baoyou> prototype for 'mvs_set_sense' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_sas.c:1653:6: warning: no previous
Baoyou> prototype for 'mvs_fill_ssp_resp_iu' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_64xx.c:139:6: warning: no previous
Baoyou> prototype for 'mvs_64xx_clear_srs_irq' [-Wmissing-prototypes]
Baoyou> drivers/scsi/mvsas/mv_64xx.c:566:6: warning: no previous
Baoyou> prototype for 'mvs_64xx_make_prd' [-Wmissing-prototypes] 

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH] pm8001: mark symbols static where possible

2016-09-26 Thread Martin K. Petersen
> "Baoyou" == Baoyou Xie  writes:

Baoyou> We get 2 warnings when building kernel with W=1:
Baoyou> drivers/scsi/pm8001/pm8001_sas.c:530:23: warning: no previous
Baoyou> prototype for 'pm8001_alloc_dev' [-Wmissing-prototypes]
Baoyou> drivers/scsi/pm8001/pm8001_hwi.c:4495:5: warning: no previous
Baoyou> prototype for 'pm8001_chip_phy_stop_req' [-Wmissing-prototypes]

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering


Re: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages

2016-09-26 Thread Chao Yu
Hi Jaegeuk,

On 2016/9/27 2:33, Jaegeuk Kim wrote:
> Hi Chao,
> 
> On Tue, Sep 27, 2016 at 12:09:52AM +0800, Chao Yu wrote:
>> From: Chao Yu 
>>
>> In sync_node_pages, we won't check and commit last merged pages in private
>> bio cache of f2fs, as these pages were taged as writeback, someone who is
>> waiting for writebacking of the page will be blocked until the cache was
>> committed by someone else.
>>
>> We need to commit node type bio cache to avoid potential deadlock or long
>> delay of waiting writeback.
>>
>> Signed-off-by: Chao Yu 
>> ---
>>  fs/f2fs/node.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
>> index 9faddcd..f73f774 100644
>> --- a/fs/f2fs/node.c
>> +++ b/fs/f2fs/node.c
>> @@ -1416,6 +1416,7 @@ int sync_node_pages(struct f2fs_sb_info *sbi, struct 
>> writeback_control *wbc)
>>  struct pagevec pvec;
>>  int step = 0;
>>  int nwritten = 0;
>> +int ret = 0;
>>  
>>  pagevec_init(, 0);
>>  
>> @@ -1436,7 +1437,8 @@ next_step:
>>  
>>  if (unlikely(f2fs_cp_error(sbi))) {
>>  pagevec_release();
>> -return -EIO;
>> +ret = -EIO;
>> +goto out;
>>  }
>>  
>>  /*
>> @@ -1487,6 +1489,8 @@ continue_unlock:
>>  
>>  if (NODE_MAPPING(sbi)->a_ops->writepage(page, wbc))
>>  unlock_page(page);
>> +else
>> +nwritten++;
>>  
>>  if (--wbc->nr_to_write == 0)
>>  break;
>> @@ -1504,7 +1508,10 @@ continue_unlock:
>>  step++;
>>  goto next_step;
>>  }
>> -return nwritten;
>> +out:
>> +if (nwritten)
>> +f2fs_submit_merged_bio(sbi, NODE, WRITE);
> 
> IIRC, we don't need to flush this, since f2fs_submit_merged_bio_cond() would
> handle this in f2fs_wait_on_page_writeback().

Yes, it covers all the cases in f2fs private codes, but there are still some
codes in mm or fs directory, and they didn't use f2fs_wait_on_page_writeback
when waiting page writeback. Such as do_writepages && filemap_fdatawait in
__writeback_single_inode...

Thanks,

> 
> Thanks,
> 
>> +return ret;
>>  }
>>  
>>  int wait_on_node_pages_writeback(struct f2fs_sb_info *sbi, nid_t ino)
>> -- 
>> 2.7.2
> 
> .
> 



Re: [LKP] [lkp] [xfs] 68a9f5e700: aim7.jobs-per-min -13.6% regression

2016-09-26 Thread Huang, Ying
Christoph Hellwig  writes:

> Hi Ying,
>
>> Any update to this regression?
>
> Not really.  We've optimized everything we could in XFS without
> dropping the architecture that we really want to move to.  Now we're
> waiting for some MM behavior to be fixed that this unconvered.  But
> in the end will probabkly stuck with a slight regression in this
> artificial workload.

I see.  Thanks for update.  Please keep me posted.

Best Regards,
Huang, Ying


Re: [LKP] [lkp] [f2fs] ec795418c4: fsmark.files_per_sec -36.3% regression

2016-09-26 Thread Huang, Ying
Jaegeuk Kim  writes:

> On Mon, Sep 26, 2016 at 02:26:06PM +0800, Huang, Ying wrote:
>> Hi, Jaegeuk,
>> 
>> "Huang, Ying"  writes:
>> 
>> > Jaegeuk Kim  writes:
>> >
>> >> Hello,
>> >>
>> >> On Sat, Aug 27, 2016 at 10:13:34AM +0800, Fengguang Wu wrote:
>> >>> Hi Jaegeuk,
>> >>> 
>> >>> > > >> > - [lkp] [f2fs] b93f771286: aim7.jobs-per-min -81.2% regression
>> >>> > > >> >
>> >>> > > >> > The disk is 4 12G ram disk, and setup RAID0 on them via mdadm.  
>> >>> > > >> > The
>> >>> > > >> > steps for aim7 is,
>> >>> > > >> >
>> >>> > > >> > cat > workfile <> >>> > > >> > FILESIZE: 1M
>> >>> > > >> > POOLSIZE: 10M
>> >>> > > >> > 10 sync_disk_rw
>> >>> > > >> > EOF
>> >>> > > >> >
>> >>> > > >> > (
>> >>> > > >> > echo $HOSTNAME
>> >>> > > >> > echo sync_disk_rw
>> >>> > > >> >
>> >>> > > >> > echo 1
>> >>> > > >> > echo 600
>> >>> > > >> > echo 2
>> >>> > > >> > echo 600
>> >>> > > >> > echo 1
>> >>> > > >> > ) | ./multitask -t &
>> >>> > > >>
>> >>> > > >> Any update on these 2 regressions?  Is the information is enough 
>> >>> > > >> for you
>> >>> > > >> to reproduce?
>> >>> > > >
>> >>> > > > Sorry, I've had no time to dig this due to business travel now.
>> >>> > > > I'll check that when back to US.
>> >>> > > 
>> >>> > > Any update?
>> >>> > 
>> >>> > Sorry, how can I get multitask binary?
>> >>> 
>> >>> It's part of aim7, which can be downloaded here:
>> >>> 
>> >>> http://nchc.dl.sourceforge.net/project/aimbench/aim-suite7/Initial%20release/s7110.tar.Z
>> >>
>> >> Thank you for the codes.
>> >>
>> >> I've run this workload on the latest f2fs and compared performance having
>> >> without the reported patch. (1TB nvme SSD, 16 cores, 16GB DRAM)
>> >> Interestingly, I could find slight performance improvement rather than
>> >> regression. :(
>> >> Not sure how to reproduce this.
>> >
>> > I think the difference lies on disk used.  The ramdisk is used in the
>> > original test, but it appears that your memory is too small to setup the
>> > RAM disk for test.  So it may be impossible for you to reproduce the
>> > test unless you can find more memory :)
>> >
>> > But we can help you to root cause the issue.  What additional data do
>> > you want?  perf-profile data before and after the patch?
>> 
>> Any update to this regression?
>
> Sorry, no. But meanwhile, I've purchased more DRAMs. :)
> Now I'm with 128GB DRAM. I can configure 64GB as pmem.
> Is it worth to try the test again?

I think you are the decision maker for this.  You can judge whether the
test is reasonable.  And we can adjust our test accordingly.

BTW: For this test, we use brd ram disk and raid to test.

Best Regards,
Huang, Ying


Re: Regression in 4.8 - CPU speed set very low

2016-09-26 Thread Larry Finger

On 09/26/2016 07:21 PM, Rafael J. Wysocki wrote:

On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger  wrote:

On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote:


On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger


 wrote:



Maybe it's better to try diagnose the problem instead of spending more
time on bisection.



In my original post, I asked for such help, but nothing until today. I had
no idea what to check, but now I have a better idea.


I'd like to know whether or not 4.7 was definitely good, though.



I never saw this problem with 4.7, but given the difficulty in triggering
the problem, my tests may not have been definitive.




If it is one of them, it may be a while before I dare call this one
"good".
In one respect, that is good as I will be traveling tomorrow and
Wednesday.



What does "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say?



intel_pstate


You probably don't need to worry about all of the cpufreq changes in
4.8-rc, then.  Only a few of them affect intel_pstate and I don't see
how any of them may lead to the observed symptoms.

First off, if you have a reproducer, please run it on 4.7 and see if
you can trigger the issue in there.


I'm running 4.8-rc7 at the moment hoping to trigger the problem and get the data 
requested by Srinivas. Once I get that, I will try 4.7 again.


Second, it would be good to have a look at the output from the
cpu_frequency and pstate_sample tracepoints around when the issue
triggers.  The pstate_sample one would be more interesting.

But for both we need a reproducer anyway.


I do not have a reliable reproducer. The condition has always happened when 
running a high-compute job such as a 'make -j8' on the kernel, or building the 
RPM for openSUSE's implementation of VirtualBox. The latter is what I'm using 
for most of my testing.



It also would be good to rule out the thermal throttling (as per the
Srinivas' comments).

For now, please tell me what's in
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq


80

Larry



[linux-next] do_task_stat: BUG: unable to handle kernel paging request at ffffc9000041bfd8

2016-09-26 Thread Tetsuo Handa
Hello.

I'm hitting below bug when a process $pid terminates while somebody else is 
reading
/proc/$pid/stat . According to https://lkml.org/lkml/2016/8/21/10 , it was 
already
fixed. But it seems to me that this bug is still in linux-next-20160923.
Is this a different bug?

[  191.915694] BUG: unable to handle kernel paging request at c941bfd8
[  191.917803] IP: [] do_task_stat+0x951/0xb90
[  191.919477] PGD 7e051067 PUD 7e052067 PMD 36ae6067 PTE 0
[  191.921029] Oops:  [#1] PREEMPT SMP
[  191.922167] Modules linked in: ebtable_nat ebtable_broute bridge stp llc 
ebtable_filter ebtables coretemp pcspkr sg i2c_piix4 sd_mod ata_generic 
pata_acpi serio_raw ahci libahci e1000 mptspi scsi_transport_spi mptscsih 
mptbase ata_piix vmwgfx drm_kms_helper syscopyarea sysfillrect sysimgblt 
fb_sys_fops ttm drm i2c_core libata
[  191.931246] CPU: 0 PID: 10894 Comm: oom_preempt2 Not tainted 
4.8.0-rc7-next-20160923+ #472
[  191.933683] Hardware name: VMware, Inc. VMware Virtual Platform/440BX 
Desktop Reference Platform, BIOS 6.00 07/02/2015
[  191.936572] task: 88007698ce80 task.stack: c90004fe4000
[  191.938425] RIP: 0010:[]  [] 
do_task_stat+0x951/0xb90
[  191.940678] RSP: 0018:c90004fe7c40  EFLAGS: 00010202
[  191.942273] RAX: c941c000 RBX: 8800790060c0 RCX: 
[  191.944404] RDX: 0001 RSI:  RDI: 88007913ef00
[  191.946369] RBP: c90004fe7d60 R08: 0001 R09: 
[  191.948502] R10: 0001 R11:  R12: 88007913ef00
[  191.950577] R13: 8800773913c0 R14: 0001 R15: 81a28da0
[  191.952923] FS:  7f56f12bb740() GS:88007ea0() 
knlGS:
[  191.955128] CS:  0010 DS:  ES:  CR0: 80050033
[  191.957154] CR2: c941bfd8 CR3: 79d18000 CR4: 001406f0
[  191.959227] Stack:
[  191.960242]  28e0 0401  
00438000
[  191.962471]  8800794ee500 000a 28e0 

[  191.964715]  28e0   

[  191.967027] Call Trace:
[  191.968340]  [] proc_tgid_stat+0xf/0x20
[  191.970087]  [] proc_single_show+0x4b/0x80
[  191.971900]  [] seq_read+0x100/0x380
[  191.973578]  [] __vfs_read+0x32/0x130
[  191.975280]  [] ? security_file_permission+0x9e/0xc0
[  191.977290]  [] vfs_read+0x89/0x130
[  191.978981]  [] SyS_pread64+0x82/0xb0
[  191.980761]  [] do_syscall_64+0x5c/0x170
[  191.982682]  [] entry_SYSCALL64_slow_path+0x25/0x25
[  191.984657] Code: ff e8 84 11 ea ff 48 8b 85 50 ff ff ff 49 03 87 b8 01 00 
00 48 89 85 50 ff ff ff e9 e8 f8 ff ff 49 8b 84 24 58 08 00 00 4c 89 e7 <48> 8b 
40 d8 48 89 85 48 ff ff ff e8 af 69 e3 ff 48 89 85 40 ff 
[  191.991974] RIP  [] do_task_stat+0x951/0xb90
[  191.993931]  RSP 
[  191.995383] CR2: c941bfd8
[  191.997003] ---[ end trace 8bdf0d4222ebcddb ]---

I can't find a patch titled "[DEBUG] forcibly free stacks immediately" in 
linux-next.
Which patch should I try reverting?


Re: [PATCH] crypto: sha1-powerpc: little-endian support

2016-09-26 Thread Paulo Flabiano Smorigo
Fri, Sep 23, 2016 at 04:31:56PM -0300, Marcelo Cerri wrote:
> The driver does not handle endianness properly when loading the input
> data.

Indeed. I tested in both endianesses and it's working fine. Thanks!

Herbert, can we go ahead with this fix?

> 
> Signed-off-by: Marcelo Cerri 
> ---
>  arch/powerpc/crypto/sha1-powerpc-asm.S | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/crypto/sha1-powerpc-asm.S 
> b/arch/powerpc/crypto/sha1-powerpc-asm.S
> index 125e165..82ddc9b 100644
> --- a/arch/powerpc/crypto/sha1-powerpc-asm.S
> +++ b/arch/powerpc/crypto/sha1-powerpc-asm.S
> @@ -7,6 +7,15 @@
>  #include 
>  #include 
> 
> +#ifdef __BIG_ENDIAN__
> +#define LWZ(rt, d, ra)   \
> + lwz rt,d(ra)
> +#else
> +#define LWZ(rt, d, ra)   \
> + li  rt,d;   \
> + lwbrx   rt,rt,ra
> +#endif
> +
>  /*
>   * We roll the registers for T, A, B, C, D, E around on each
>   * iteration; T on iteration t is A on iteration t+1, and so on.
> @@ -23,7 +32,7 @@
>  #define W(t) (((t)%16)+16)
> 
>  #define LOADW(t) \
> - lwz W(t),(t)*4(r4)
> + LWZ(W(t),(t)*4,r4)
> 
>  #define STEPD0_LOAD(t)   \
>   andcr0,RD(t),RB(t); \
> @@ -33,7 +42,7 @@
>   add r0,RE(t),r15;   \
>   add RT(t),RT(t),r6; \
>   add r14,r0,W(t);\
> - lwz W((t)+4),((t)+4)*4(r4); \
> + LWZ(W((t)+4),((t)+4)*4,r4); \
>   rotlwi  RB(t),RB(t),30; \
>   add RT(t),RT(t),r14
> 
> -- 
> 2.7.4
> 

-- 
Paulo Flabiano Smorigo
IBM Linux Technology Center



Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

2016-09-26 Thread Rich Felker
On Mon, Sep 26, 2016 at 07:55:13PM -0400, Thomas Gleixner wrote:
> On Mon, 26 Sep 2016, Rich Felker wrote:
> > On Mon, Sep 26, 2016 at 11:27:14PM +0200, Daniel Lezcano wrote:
> > Based on use of ftrace, I was able to see situations where a second
> > timer hardirq happened immediately after one occurred, before the
> > timer softirq could run. My theory is that this is causing some kind
> > of feedback loop where new timer expirations keep getting scheduled
> > with a very short interval such that the softirq never gets to run
> > (until other interrupt activity disrups the feedback loop). I tried
> > reverting 4e85876a9d2a977b4a07389da8c07edf76d10825 which seemed
> > relevant and it didn't help, but on further review (right now) there
> > seem to be a few related commits just before it that might be
> > responsible for the regression. I'll see if I can dig up anything else
> > useful.
> 
> Interesting theory, but lets look at the data from the other thread:
> 
>  -0 [001] d.h.  2646.702790: irq_handler_entry: irq=72 
> name=jcore_pit
>   -0 [001] d.h.  2646.703398: softirq_raise: vec=1 
> [action=TIMER]
>   -0 [001] d.h.  2646.703607: softirq_raise: vec=9 
> [action=RCU]
>   -0 [001] d.h.  2646.703884: softirq_raise: vec=7 
> [action=SCHED]
>   -0 [001] d.h.  2646.704191: irq_handler_exit: irq=72 
> ret=handled
> 
> So it takes 1.4ms to finish the timer irq handler
> 
>   -0 [001] d.H.  2646.704509: irq_handler_entry: irq=72 
> name=jcore_pit
>   -0 [001] d.H.  2646.704990: softirq_raise: vec=1 
> [action=TIMER]
>   -0 [001] d.H.  2646.705182: softirq_raise: vec=9 
> [action=RCU]
>   -0 [001] d.H.  2646.705465: softirq_raise: vec=7 
> [action=SCHED]
>   -0 [001] d.H.  2646.705761: irq_handler_exit: irq=72 
> ret=handled
> 
> And 1.2ms in this case
> 
> 
>   -0 [001] d.H.  2646.706071: irq_handler_entry: irq=72 
> name=jcore_pit
>   -0 [001] d.H.  2646.706328: irq_handler_exit: irq=72 
> ret=handled
> 
> So this one is actually short enough that the soft interrupt can excute and
> obviously no new timer is scheduled close enough.
> 
>   -0 [001] ..s.  2646.706530: softirq_entry: vec=1 
> [action=TIMER]
> 
> Now the obvious question arises: Why is that handler taking that long? And

I'm not sure. Even at our clock rate of 50 MHz, 1.2ms is 6 cycles.
It's possible much of that overhead is coming from ftrace. I can play
around again with just logging the minimum intervals that are
programmed, and not using ftrace.

> sure the next event being programmed shortely after the other has to do
> with various factors (HZ setting, High-resolution timers enabled?). W/o
> having the corresponding hrtimer tracepoints available (start and expire)
> it's hard to tell what's going on.

I do have hrtimers enabled. If it would be helpful I could try again
with traces for them enabled too.

> But I can tell for sure that there is no feedback loop and its not
> disrupted by some other interrupt.

FYI no rcu_sched messages or noticable stalls were observed with
tracing active. The cpu load from tracing is so high that I would not
expect to see the same behavior. I probably failed to make that clear
before; sorry.

> The above trace is merily seing the PIT
> irq and nothing else.

It is showing another one happening before the softirq side of the
first could run, right? Of course this is probably due to overall
ftrace slowness. CONFIG_DYNAMIC_FTRACE does not work on big-endian sh
(the objdump needed at build time is hard-coded to assume sh is
little-endian and I haven't yet worked out what all needs to be fixed)
so I suspect that may be the cause of ftrace being so slow when it's
turned on.

Oddly, the min_delta cutoff needed to prevent the stalls was on the
same order of magnitude as these numbers (2.5ms almost entirely made
them go away; 5ms completely).

> Can you please provide a trace with hrtimer tracepoints enabled and tell us
> the settings of CONFIG_HZ and whether high resolution timers are enabled or
> not.

Yes. I think these are the relevant config items:

CONFIG_HZ=100
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

Let me know if I missed any. I'll try getting a trace and follow up
again.

> That workaround of setting min_delta to some absurd big number looks fishy
> at best.

I agree. I'd like to find the right fix, but usability badly suffers
without either a proper fix or a workaround.

Rich


Re: [PATCH v4] add u64 number parser

2016-09-26 Thread J Freyensee
On Sun, 2016-09-25 at 09:14 -0700, James Smart wrote:
> add u64 number parser
> 
> Reverted back to version 2 of the patch.  This adds the interface
> using existing logic. Comments from the prior reviewers to move to
> kasprintf were rejected by Linus.
> 
> Signed-off-by: James Smart 

Acked-by: Jay Freyensee 



Re: [PATCH] lpfc: mark symbols static where possible

2016-09-26 Thread Martin K. Petersen
> "Baoyou" == Baoyou Xie  writes:

Baoyou> In fact, these functions are only used in the file in which they
Baoyou> are declared and don't need a declaration, but can be made
Baoyou> static.  so this patch marks these functions with 'static'.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering


[PATCH] perf: sched-pipe add support for packet I/O mode

2016-09-26 Thread Shuah Khan
Add support to run sched-pipe benchmark test on pipe with packet I/O mode.

Signed-off-by: Shuah Khan 
---
 tools/perf/bench/sched-pipe.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
index 1dc2d13..c6e1b7a 100644
--- a/tools/perf/bench/sched-pipe.c
+++ b/tools/perf/bench/sched-pipe.c
@@ -41,9 +41,16 @@ static   int loops = LOOPS_DEFAULT;
 /* Use processes by default: */
 static boolthreaded;
 
+/* Use non-packet (normal) I/O mode by default.
+ * In packet mode, each write is a separate packet.
+ */
+static boolpacket_mode;
+
 static const struct option options[] = {
OPT_INTEGER('l', "loop",, "Specify number of 
loops"),
OPT_BOOLEAN('T', "threaded",,  "Specify 
threads/process based task setup"),
+   OPT_BOOLEAN('P', "packet mode", _mode,
+   "Specify packet I/O mode - "),
OPT_END()
 };
 
@@ -83,6 +90,7 @@ int bench_sched_pipe(int argc, const char **argv, const char 
*prefix __maybe_unu
unsigned long long result_usec = 0;
int nr_threads = 2;
int t;
+   int flags = 0;
 
/*
 * why does "ret" exist?
@@ -94,6 +102,18 @@ int bench_sched_pipe(int argc, const char **argv, const 
char *prefix __maybe_unu
 
argc = parse_options(argc, argv, options, bench_sched_pipe_usage, 0);
 
+   if (packet_mode) {
+   /* BUG_ON doesn't make sense exit if pipe2() fails */
+   flags = O_DIRECT;
+   ret = pipe2(pipe_1, flags);
+   if (ret)
+   exit(1);
+   ret = pipe2(pipe_2, flags);
+   if (ret)
+   exit(1);
+   printf("Running sched-pipe in packet I/O mode\n\n");
+   }
+
BUG_ON(pipe(pipe_1));
BUG_ON(pipe(pipe_2));
 
-- 
2.7.4



[PATCH] pinctrl: freescale: avoid overwriting pin config when freeing GPIO

2016-09-26 Thread Stefan Agner
If a GPIO gets freed after selecting a new pinctrl configuration
the driver should not change pinctrl anymore. Otherwise this will
likely lead to a unusable pin configuration for the newly selected
pinctrl.

Signed-off-by: Stefan Agner 
---
This turned out to be problematic when using the I2C GPIO bus recovery
functionality. After muxing back to I2C, the GPIO is being freed, which
cased I2C to stop working completely.

--
Stefan

 drivers/pinctrl/freescale/pinctrl-imx.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
b/drivers/pinctrl/freescale/pinctrl-imx.c
index 4761320..61cfa95 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -361,8 +361,13 @@ static void imx_pmx_gpio_disable_free(struct pinctrl_dev 
*pctldev,
if (pin_reg->mux_reg == -1)
return;
 
-   /* Clear IBE/OBE/PUE to disable the pin (Hi-Z) */
reg = readl(ipctl->base + pin_reg->mux_reg);
+
+   /* Only change pad configuration if pad is still a GPIO */
+   if (reg & (0x7 << 20))
+   return;
+
+   /* Clear IBE/OBE/PUE to disable the pin (Hi-Z) */
reg &= ~0x7;
writel(reg, ipctl->base + pin_reg->mux_reg);
 }
-- 
2.10.0



Re: Regression in 4.8 - CPU speed set very low

2016-09-26 Thread Rafael J. Wysocki
On Tue, Sep 27, 2016 at 1:53 AM, Larry Finger  wrote:
> On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote:
>>
>> On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger
>
>  wrote:
>>
>>
>> Maybe it's better to try diagnose the problem instead of spending more
>> time on bisection.
>
>
> In my original post, I asked for such help, but nothing until today. I had
> no idea what to check, but now I have a better idea.
>
>> I'd like to know whether or not 4.7 was definitely good, though.
>
>
> I never saw this problem with 4.7, but given the difficulty in triggering
> the problem, my tests may not have been definitive.
>>
>>
>>> If it is one of them, it may be a while before I dare call this one
>>> "good".
>>> In one respect, that is good as I will be traveling tomorrow and
>>> Wednesday.
>>
>>
>> What does "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say?
>
>
> intel_pstate

You probably don't need to worry about all of the cpufreq changes in
4.8-rc, then.  Only a few of them affect intel_pstate and I don't see
how any of them may lead to the observed symptoms.

First off, if you have a reproducer, please run it on 4.7 and see if
you can trigger the issue in there.

Second, it would be good to have a look at the output from the
cpu_frequency and pstate_sample tracepoints around when the issue
triggers.  The pstate_sample one would be more interesting.

But for both we need a reproducer anyway.

It also would be good to rule out the thermal throttling (as per the
Srinivas' comments).

For now, please tell me what's in
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq

Thanks,
Rafael


[PATCH] i2c: imx: defer probe if bus recovery GPIOs are not ready

2016-09-26 Thread Stefan Agner
Some SoC might load the GPIO driver after the I2C driver and
using the I2C bus recovery mechanism via GPIOs. In this case
it is crucial to defer probing if the GPIO request functions
do so, otherwise the I2C driver gets loaded without recovery
mechanisms enabled.

Signed-off-by: Stefan Agner 
---
This is an actual issue on NXP Vybrid devices on which the GPIO
driver gets loaded rather later.

--
Stefan

 drivers/i2c/busses/i2c-imx.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 592a8f2..47fc1f1 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1009,10 +1009,13 @@ static int i2c_imx_init_recovery_info(struct 
imx_i2c_struct *i2c_imx,
rinfo->sda_gpio = of_get_named_gpio(pdev->dev.of_node, "sda-gpios", 0);
rinfo->scl_gpio = of_get_named_gpio(pdev->dev.of_node, "scl-gpios", 0);
 
-   if (!gpio_is_valid(rinfo->sda_gpio) ||
-   !gpio_is_valid(rinfo->scl_gpio) ||
-   IS_ERR(i2c_imx->pinctrl_pins_default) ||
-   IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
+   if (rinfo->sda_gpio == -EPROBE_DEFER ||
+   rinfo->scl_gpio == -EPROBE_DEFER) {
+   return -EPROBE_DEFER;
+   } else if (!gpio_is_valid(rinfo->sda_gpio) ||
+  !gpio_is_valid(rinfo->scl_gpio) ||
+  IS_ERR(i2c_imx->pinctrl_pins_default) ||
+  IS_ERR(i2c_imx->pinctrl_pins_gpio)) {
dev_dbg(>dev, "recovery information incomplete\n");
return 0;
}
-- 
2.10.0



Re: [PATCH v3 5/5] mm: enable CONFIG_MOVABLE_NODE on powerpc

2016-09-26 Thread Reza Arbab

On Tue, Sep 27, 2016 at 07:15:41AM +1000, Benjamin Herrenschmidt wrote:

What is that business with a command line argument ? Do that mean that
we'll need some magic command line argument to properly handle LPC memory
on CAPI devices or GPUs ? If yes that's bad ... kernel arguments should
be a last resort.


Well, movable_node is just a boolean, meaning "allow nodes which contain 
only movable memory". It's _not_ like "movable_node=10,13-15,17", if 
that's what you were thinking.



We should have all the information we need from the device-tree.

Note also that we shouldn't need to create those nodes at boot time,
we need to add the ability to create the whole thing at runtime, we may know
that there's an NPU with an LPC window in the system but we won't know if it's
used until it is and for CAPI we just simply don't know until some PCI device
gets turned into CAPI mode and starts claiming LPC memory...


Yes, this is what is planned for, if I'm understanding you correctly.

In the dt, the PCI device node has a phandle pointing to the memory 
node. The memory node describes the window into which we can hotplug at 
runtime.


--
Reza Arbab



Re: [PATCH] net: tg3: use new api ethtool_{get|set}_link_ksettings

2016-09-26 Thread David Miller
From: Philippe Reynes 
Date: Sun, 25 Sep 2016 23:31:24 +0200

> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
> 
> Signed-off-by: Philippe Reynes 

Applied, thanks.


Re: [PATCH v3 4/5] powerpc/mm: restore top-down allocation when using movable_node

2016-09-26 Thread Reza Arbab

On Tue, Sep 27, 2016 at 07:12:31AM +1000, Benjamin Herrenschmidt wrote:
In any case, if the memory hasn't been hotplug, this shouldn't be 
necessary as we shouldn't be considering it for allocation.


Right. To be clear, the background info I put in the commit log refers 
to x86, where the SRAT can describe movable nodes which exist at boot.  
They're trying to avoid allocations from those nodes before they've been 
identified.


On power, movable nodes can only exist via hotplug, so that scenario 
can't happen. We can immediately go back to top-down allocation. That is 
the missing call being added in the patch.


--
Reza Arbab



Re: [PATCH] elevator: remove second argument in elevator_init()

2016-09-26 Thread Alexey Klimov
On Thu, Mar 31, 2016 at 1:34 AM, Jens Axboe  wrote:
> On 03/30/2016 05:31 PM, Alexey Klimov wrote:
>>
>> Hi all,
>>
>> On Wed, Jan 27, 2016 at 9:01 PM, Jeff Moyer  wrote:
>>>
>>> Alexey Klimov  writes:
>>>
 Last user of elevator_init() with non-NULL name as second argument
 that supposed to be s390 dasd driver has gone few releases ago.
 Drivers rely on elevator_change(), elevator_switch() and friends
 for example. Right now elevator_init() is always called as
 elevator_init(q, NULL).

 Patch removes passing of second name argument and its usage.

 While we're at it fix following if-check after removed lines. We know
 that elevator_type e is initialized by NULL and need to check only
 chosen_elevator.

 Signed-off-by: Alexey Klimov 
>>>
>>>
>>> Reviewed-by: Jeff Moyer 
>>
>>
>>
>> what is the status of this patch? Is it that wrong and are there some
>> concerns or do I need to resend it?
>
>
> It looks fine, I'll pick it up for 4.7.
>
> --
> Jens Axboe


So, I guess this one was lost: I can't find it in the tree.
Looks like the easiest way will be to rebase (and check that it's
still fine) and resend. Right?

Best regards,
Alexey.


linux-next: manual merge of the vfs-jk tree with the fuse tree

2016-09-26 Thread Stephen Rothwell
Hi Jan,

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

  fs/fuse/dir.c

between commits:

  3b3fb74935ce ("fuse: invalidate dir dentry after chmod")
  5f69e628df75 ("fuse: fix killing s[ug]id in setattr")

from the fuse tree and commit:

  62490330769c ("fuse: Propagate dentry down to inode_change_ok()")

from the vfs-jk tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc fs/fuse/dir.c
index f7c84ab835ca,b23502174682..
--- a/fs/fuse/dir.c
+++ b/fs/fuse/dir.c
@@@ -1618,10 -1606,10 +1619,10 @@@ int fuse_do_setattr(struct dentry *dent
int err;
bool trust_local_cmtime = is_wb && S_ISREG(inode->i_mode);
  
 -  if (!(fc->flags & FUSE_DEFAULT_PERMISSIONS))
 +  if (!fc->default_permissions)
attr->ia_valid |= ATTR_FORCE;
  
-   err = inode_change_ok(inode, attr);
+   err = setattr_prepare(dentry, attr);
if (err)
return err;
  
@@@ -1715,61 -1703,101 +1716,61 @@@ error
  static int fuse_setattr(struct dentry *entry, struct iattr *attr)
  {
struct inode *inode = d_inode(entry);
 -
 -  if (!fuse_allow_current_process(get_fuse_conn(inode)))
 -  return -EACCES;
 -
 -  if (attr->ia_valid & ATTR_FILE)
 -  return fuse_do_setattr(entry, attr, attr->ia_file);
 -  else
 -  return fuse_do_setattr(entry, attr, NULL);
 -}
 -
 -static int fuse_getattr(struct vfsmount *mnt, struct dentry *entry,
 -  struct kstat *stat)
 -{
 -  struct inode *inode = d_inode(entry);
struct fuse_conn *fc = get_fuse_conn(inode);
 +  struct file *file = (attr->ia_valid & ATTR_FILE) ? attr->ia_file : NULL;
 +  int ret;
  
 -  if (!fuse_allow_current_process(fc))
 +  if (!fuse_allow_current_process(get_fuse_conn(inode)))
return -EACCES;
  
 -  return fuse_update_attributes(inode, stat, NULL, NULL);
 -}
 -
 -static int fuse_setxattr(struct dentry *unused, struct inode *inode,
 -   const char *name, const void *value,
 -   size_t size, int flags)
 -{
 -  struct fuse_conn *fc = get_fuse_conn(inode);
 -  FUSE_ARGS(args);
 -  struct fuse_setxattr_in inarg;
 -  int err;
 -
 -  if (fc->no_setxattr)
 -  return -EOPNOTSUPP;
 +  if (attr->ia_valid & (ATTR_KILL_SUID | ATTR_KILL_SGID)) {
 +  attr->ia_valid &= ~(ATTR_KILL_SUID | ATTR_KILL_SGID |
 +  ATTR_MODE);
  
 -  memset(, 0, sizeof(inarg));
 -  inarg.size = size;
 -  inarg.flags = flags;
 -  args.in.h.opcode = FUSE_SETXATTR;
 -  args.in.h.nodeid = get_node_id(inode);
 -  args.in.numargs = 3;
 -  args.in.args[0].size = sizeof(inarg);
 -  args.in.args[0].value = 
 -  args.in.args[1].size = strlen(name) + 1;
 -  args.in.args[1].value = name;
 -  args.in.args[2].size = size;
 -  args.in.args[2].value = value;
 -  err = fuse_simple_request(fc, );
 -  if (err == -ENOSYS) {
 -  fc->no_setxattr = 1;
 -  err = -EOPNOTSUPP;
 -  }
 -  if (!err) {
 -  fuse_invalidate_attr(inode);
 -  fuse_update_ctime(inode);
 +  /*
 +   * The only sane way to reliably kill suid/sgid is to do it in
 +   * the userspace filesystem
 +   *
 +   * This should be done on write(), truncate() and chown().
 +   */
 +  if (!fc->handle_killpriv) {
 +  int kill;
 +
 +  /*
 +   * ia_mode calculation may have used stale i_mode.
 +   * Refresh and recalculate.
 +   */
 +  ret = fuse_do_getattr(inode, NULL, file);
 +  if (ret)
 +  return ret;
 +
 +  attr->ia_mode = inode->i_mode;
 +  kill = should_remove_suid(entry);
 +  if (kill & ATTR_KILL_SUID) {
 +  attr->ia_valid |= ATTR_MODE;
 +  attr->ia_mode &= ~S_ISUID;
 +  }
 +  if (kill & ATTR_KILL_SGID) {
 +  attr->ia_valid |= ATTR_MODE;
 +  attr->ia_mode &= ~S_ISGID;
 +  }
 +  }
}
 -  return err;
 -}
 -
 -static ssize_t fuse_getxattr(struct dentry *entry, struct inode *inode,
 -   const char *name, void *value, size_t size)
 -{
 -  struct fuse_conn *fc = get_fuse_conn(inode);

Re: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

2016-09-26 Thread David Miller

When you need to make changes to patches that are part of a series,
you must resubmit the entire series, not just the things that
are changes.


Re: [PATCH] timekeeping: Change type of nsec variable to unsigned in its calculation.

2016-09-26 Thread Thomas Gleixner
On Mon, 26 Sep 2016, Liav Rehana wrote:
> During the calculation of the nsec variable in the inline function
> timekeeping_delta_to_ns, it may undergo a sign extension if its msb
> is set just before the shift. The sign extension may, in some cases,
> gain it a value near the maximum value of the 64-bit range. This is
> bad when it is later used in a division function, such as
> __iter_div_u64_rem, where the amount of loops it will go through to
> calculate the division will be too large.
> The following commit fixes that chance of sign extension,

Again. This does not fix anything, it papers over the underlying problem
that the calling code hands in a delta which is big enough to overflow the
multiplication into the negative space. You just extend the range of deltas
which are handled gracefully, but that does not fix the underlying problem
as we still can run into the multiplication overflow. It won't cause the
result to be negative, but it will be crap nevertheless.

> while maintaining the type of the nsec variable as signed for other
> functions that use this variable, for possible legit negative time
> intervals.

What is this maintaining? The type of this variable changes to u64 and
other functions cannot use this variable at all because it's local to that
function. This sentence makes no sense at all.

Thanks,

tglx


Re: [PATCH v2] fs/select: add vmalloc fallback for select(2)

2016-09-26 Thread Andrew Morton
On Thu, 22 Sep 2016 18:43:59 +0200 Vlastimil Babka  wrote:

> The select(2) syscall performs a kmalloc(size, GFP_KERNEL) where size grows
> with the number of fds passed. We had a customer report page allocation
> failures of order-4 for this allocation. This is a costly order, so it might
> easily fail, as the VM expects such allocation to have a lower-order fallback.
> 
> Such trivial fallback is vmalloc(), as the memory doesn't have to be
> physically contiguous. Also the allocation is temporary for the duration of 
> the
> syscall, so it's unlikely to stress vmalloc too much.
> 
> Note that the poll(2) syscall seems to use a linked list of order-0 pages, so
> it doesn't need this kind of fallback.
> 
> ...
>
> --- a/fs/select.c
> +++ b/fs/select.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -558,6 +559,7 @@ int core_sys_select(int n, fd_set __user *inp, fd_set 
> __user *outp,
>   struct fdtable *fdt;
>   /* Allocate small arguments on the stack to save memory and be faster */
>   long stack_fds[SELECT_STACK_ALLOC/sizeof(long)];
> + unsigned long alloc_size;
>  
>   ret = -EINVAL;
>   if (n < 0)
> @@ -580,8 +582,12 @@ int core_sys_select(int n, fd_set __user *inp, fd_set 
> __user *outp,
>   bits = stack_fds;
>   if (size > sizeof(stack_fds) / 6) {
>   /* Not enough space in on-stack array; must use kmalloc */
> + alloc_size = 6 * size;

Well.  `size' is `unsigned'.  The multiplication will be done as 32-bit
so there was no point in making `alloc_size' unsigned long.

So can we tighten up the types in this function?  size_t might make
sense, but vmalloc() takes a ulong.

>   ret = -ENOMEM;
> - bits = kmalloc(6 * size, GFP_KERNEL);
> + bits = kmalloc(alloc_size, GFP_KERNEL|__GFP_NOWARN);
> + if (!bits && alloc_size > PAGE_SIZE)
> + bits = vmalloc(alloc_size);

I don't share Eric's concerns about performance here.  If the vmalloc()
is called, we're about to write to that quite large amount of memory
which we just allocated, and the vmalloc() overhead will be relatively
low.

>   if (!bits)
>   goto out_nofds;
>   }
> @@ -618,7 +624,7 @@ int core_sys_select(int n, fd_set __user *inp, fd_set 
> __user *outp,
>  
>  out:
>   if (bits != stack_fds)
> - kfree(bits);
> + kvfree(bits);
>  out_nofds:
>   return ret;

It otherwise looks OK to me.


Re: [PATCH v7 2/2] clocksource: add J-Core timer/clocksource driver

2016-09-26 Thread Thomas Gleixner
On Mon, 26 Sep 2016, Rich Felker wrote:
> On Mon, Sep 26, 2016 at 11:27:14PM +0200, Daniel Lezcano wrote:
> Based on use of ftrace, I was able to see situations where a second
> timer hardirq happened immediately after one occurred, before the
> timer softirq could run. My theory is that this is causing some kind
> of feedback loop where new timer expirations keep getting scheduled
> with a very short interval such that the softirq never gets to run
> (until other interrupt activity disrups the feedback loop). I tried
> reverting 4e85876a9d2a977b4a07389da8c07edf76d10825 which seemed
> relevant and it didn't help, but on further review (right now) there
> seem to be a few related commits just before it that might be
> responsible for the regression. I'll see if I can dig up anything else
> useful.

Interesting theory, but lets look at the data from the other thread:

 -0 [001] d.h.  2646.702790: irq_handler_entry: irq=72 
name=jcore_pit
  -0 [001] d.h.  2646.703398: softirq_raise: vec=1 
[action=TIMER]
  -0 [001] d.h.  2646.703607: softirq_raise: vec=9 
[action=RCU]
  -0 [001] d.h.  2646.703884: softirq_raise: vec=7 
[action=SCHED]
  -0 [001] d.h.  2646.704191: irq_handler_exit: irq=72 
ret=handled

So it takes 1.4ms to finish the timer irq handler

  -0 [001] d.H.  2646.704509: irq_handler_entry: irq=72 
name=jcore_pit
  -0 [001] d.H.  2646.704990: softirq_raise: vec=1 
[action=TIMER]
  -0 [001] d.H.  2646.705182: softirq_raise: vec=9 
[action=RCU]
  -0 [001] d.H.  2646.705465: softirq_raise: vec=7 
[action=SCHED]
  -0 [001] d.H.  2646.705761: irq_handler_exit: irq=72 
ret=handled

And 1.2ms in this case
  

  -0 [001] d.H.  2646.706071: irq_handler_entry: irq=72 
name=jcore_pit
  -0 [001] d.H.  2646.706328: irq_handler_exit: irq=72 
ret=handled

So this one is actually short enough that the soft interrupt can excute and
obviously no new timer is scheduled close enough.

  -0 [001] ..s.  2646.706530: softirq_entry: vec=1 
[action=TIMER]

Now the obvious question arises: Why is that handler taking that long? And
sure the next event being programmed shortely after the other has to do
with various factors (HZ setting, High-resolution timers enabled?). W/o
having the corresponding hrtimer tracepoints available (start and expire)
it's hard to tell what's going on.

But I can tell for sure that there is no feedback loop and its not
disrupted by some other interrupt. The above trace is merily seing the PIT
irq and nothing else.

Can you please provide a trace with hrtimer tracepoints enabled and tell us
the settings of CONFIG_HZ and whether high resolution timers are enabled or
not.

That workaround of setting min_delta to some absurd big number looks fishy
at best.

Thanks,

tglx


Re: [PATCH trival 1/2] bpf: clean up put_cpu_var usage

2016-09-26 Thread Alexei Starovoitov
On Mon, Sep 26, 2016 at 11:14:50AM -0700, Shaohua Li wrote:
> put_cpu_var takes the percpu data, not the data returned from
> get_cpu_var.
> 
> This doesn't change the behavior.
> 
> Cc: Tejun Heo 
> Cc: Alexei Starovoitov 
> Signed-off-by: Shaohua Li 

Looks good. Nice catch.
Please rebase to net-next tree and send it to netdev list.
Otherwise we'll have conflicts at the time of the merge window.

> ---
>  kernel/bpf/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
> index 03fd23d..b73913b 100644
> --- a/kernel/bpf/core.c
> +++ b/kernel/bpf/core.c
> @@ -1031,7 +1031,7 @@ u64 bpf_user_rnd_u32(u64 r1, u64 r2, u64 r3, u64 r4, 
> u64 r5)
>  
>   state = _cpu_var(bpf_user_rnd_state);
>   res = prandom_u32_state(state);
> - put_cpu_var(state);
> + put_cpu_var(bpf_user_rnd_state);
>  
>   return res;
>  }
> -- 
> 2.9.3
> 


Re: Regression in 4.8 - CPU speed set very low

2016-09-26 Thread Larry Finger

On 09/26/2016 05:16 PM, Rafael J. Wysocki wrote:

On Tue, Sep 27, 2016 at 12:09 AM, Larry Finger

 wrote:


Maybe it's better to try diagnose the problem instead of spending more
time on bisection.


In my original post, I asked for such help, but nothing until today. I had no 
idea what to check, but now I have a better idea.



I'd like to know whether or not 4.7 was definitely good, though.


I never saw this problem with 4.7, but given the difficulty in triggering the 
problem, my tests may not have been definitive.



If it is one of them, it may be a while before I dare call this one "good".
In one respect, that is good as I will be traveling tomorrow and Wednesday.


What does "cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver" say?


intel_pstate

Larry




Re: [PATCH 00/14] perf clang: Support compiling BPF script use builtin clang

2016-09-26 Thread Alexei Starovoitov
On Mon, Sep 26, 2016 at 09:49:30AM +0800, Wangnan (F) wrote:
> 
> 
> On 2016/9/24 23:16, Alexei Starovoitov wrote:
> >On Fri, Sep 23, 2016 at 12:49:47PM +, Wang Nan wrote:
> >>This patch set is the first step to implement features I announced
> >>in LinuxCon NA 2016. See page 31 of:
> >>
> >>  
> >> http://events.linuxfoundation.org/sites/events/files/slides/Performance%20Monitoring%20and%20Analysis%20Using%20perf%20and%20BPF_1.pdf
> >>
> >>This patch set links LLVM and Clang libraries to perf, so perf
> >>is able to compile BPF script to BPF object on the fly.
> >Nice!
> >So single perf binary won't have llvm external dependency anymore
> >or both ways will be maintained?
> >The command line stays the same?
> 
> Yes. This patch set doesn't change interface. It compiles BPF script
> with builtin clang, and if it fail, fall back to external clang.
> 
> >If I understand the patches correctly, this set is establishing
> >the basic functionality and more complex features coming?
> >
> 
> Yes. Following steps are:
> 
>  1. Ease of use improvement: automatically include BPF functions
> declaration and macros.

+1

>  2. Perf's hook: compile part of BPF script into native code, run
> them in perf when something happen. Create a channel, coordinate
> BPF and native code use bpf-output event.

+1

>  3. Define a new language to support common profiling task. I'm not
> very clear what the new language should be. It may looks like lua,
> perf converts it to C then to LLVM IR with builtin clang.

Many tracing languages were invented in the past.
At this point I'm not sure what exactly new language will solve.
To make it easier to write bpf programs?
I think it will be more fruitful to tweak clang/llvm to add
good warnings/errors for cases where we know that C is not going
be compiled into the code that the kernel verifier will accept.
Like we can complain about loops, unitialized variables,
non-inlined and unkown helper functions... all from clang/llvm.
imo that would be the better path forward and will help
both tracing and networking users that write in this restricted C.



[PATCH 2/3] regulator: max77693: Also manipulate the fast charge current

2016-09-26 Thread Wolfgang Wiedmeyer
For MAX77693, the fast charge current also needs to be manipulated for
proper charging. The fast charge current is only set in the case of
the MAX77693 type, as the MAX77843 properly manipulates the fast
charge current.
The fast charge current is set to the next possible value below the
maximum input current.

Signed-off-by: Wolfgang Wiedmeyer 
---
 drivers/regulator/max77693-regulator.c | 45 +++---
 1 file changed, 42 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/max77693-regulator.c 
b/drivers/regulator/max77693-regulator.c
index cfbb951..e2f7584 100644
--- a/drivers/regulator/max77693-regulator.c
+++ b/drivers/regulator/max77693-regulator.c
@@ -54,14 +54,19 @@ struct chg_reg_data {
unsigned int linear_mask;
unsigned int uA_step;
unsigned int min_sel;
+
+   bool set_fast;
+   unsigned int fast_reg;
+   unsigned int fast_mask;
 };
 
 /*
  * MAX77693 CHARGER regulator - Min : 20mA, Max : 2580mA, step : 20mA
  * 0x00, 0x01, 0x2, 0x03   = 60 mA
  * 0x04 ~ 0x7E = (60 + (X - 3) * 20) mA
- * Actually for MAX77693 the driver manipulates the maximum input current,
- * not the fast charge current (output). This should be fixed.
+ * Actually for MAX77693 the driver manipulates the maximum input current
+ * and the fast charge current (output) because the fast charge current
+ * is not set.
  *
  * On MAX77843 the calculation formula is the same (except values).
  * Fortunately it properly manipulates the fast charge current.
@@ -100,6 +105,8 @@ static int max77693_chg_set_current_limit(struct 
regulator_dev *rdev,
const struct chg_reg_data *reg_data = rdev_get_drvdata(rdev);
unsigned int chg_min_uA = rdev->constraints->min_uA;
int sel = 0;
+   unsigned int data;
+   int ret;
 
while (chg_min_uA + reg_data->uA_step * sel < min_uA)
sel++;
@@ -110,7 +117,35 @@ static int max77693_chg_set_current_limit(struct 
regulator_dev *rdev,
/* the first four codes for charger current are all 60mA */
sel += reg_data->min_sel;
 
-   return regmap_write(rdev->regmap, reg_data->linear_reg, sel);
+   ret = regmap_write(rdev->regmap, reg_data->linear_reg, sel);
+   if (ret < 0)
+   return ret;
+
+   if (reg_data->set_fast) {
+   /* disable fast charge if minimum value */
+   if (sel == reg_data->min_sel)
+   data = 0;
+   else {
+   /*
+* set the fast charge current to the closest value
+* below the input current
+*/
+   ret = regmap_read(rdev->regmap, reg_data->fast_reg,
+ );
+   if (ret < 0)
+   return ret;
+
+   sel *= reg_data->uA_step / 1000; /* convert to mA */
+   data &= ~reg_data->fast_mask;
+   data |= sel * 10 / 333; /* 0.1A/3 steps */
+   }
+
+   ret = regmap_write(rdev->regmap, reg_data->fast_reg, data);
+   if (ret < 0)
+   return ret;
+   }
+
+   return 0;
 }
 /* end of CHARGER regulator ops */
 
@@ -197,6 +232,9 @@ static const struct chg_reg_data max77693_chg_reg_data = {
.linear_mask= CHG_CNFG_09_CHGIN_ILIM_MASK,
.uA_step= 2,
.min_sel= 3,
+   .set_fast   = true,
+   .fast_reg   = MAX77693_CHG_REG_CHG_CNFG_02,
+   .fast_mask  = CHG_CNFG_02_CC_MASK,
 };
 
 #definemax77843_regulator_desc_esafeout(num)   {   
\
@@ -237,6 +275,7 @@ static const struct chg_reg_data max77843_chg_reg_data = {
.linear_mask= MAX77843_CHG_FAST_CHG_CURRENT_MASK,
.uA_step= MAX77843_CHG_FAST_CHG_CURRENT_STEP,
.min_sel= 2,
+   .set_fast   = false,
 };
 
 static int max77693_pmic_probe(struct platform_device *pdev)
-- 
2.8.0.rc3



[PATCH 3/3] power_supply: max77693: Listen for cable events and enable charging

2016-09-26 Thread Wolfgang Wiedmeyer
This patch adds a listener for extcon cable events and enables
charging if an USB cable is connected. It recognizes SDP and DCP cable
types and treats them the same (same input current and fast charge
current). The maximum input current is set before the charger is
enabled and before the charger gets disabled, the maximum input
current is set to zero. The listener is inspired by the listener
implementation that was used for the AXP288 Charger driver.

The patch also adds support for the CURRENT_NOW property. It reads the
fast charge current that gets set before the charger is enabled or
disabled.

Signed-off-by: Wolfgang Wiedmeyer 
---
 drivers/power/Kconfig|   2 +-
 drivers/power/max77693_charger.c | 171 +++
 2 files changed, 172 insertions(+), 1 deletion(-)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index acd4a15..28254d3 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -372,7 +372,7 @@ config CHARGER_MAX14577
 
 config CHARGER_MAX77693
tristate "Maxim MAX77693 battery charger driver"
-   depends on MFD_MAX77693
+   depends on MFD_MAX77693 && REGULATOR_MAX77693
help
  Say Y to enable support for the Maxim MAX77693 battery charger.
 
diff --git a/drivers/power/max77693_charger.c b/drivers/power/max77693_charger.c
index 060cab5..922f43f 100644
--- a/drivers/power/max77693_charger.c
+++ b/drivers/power/max77693_charger.c
@@ -22,8 +22,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define MAX77693_CHARGER_NAME  "max77693-charger"
+#define MAX77693_EXTCON_DEV_NAME   "max77693-muic"
 static const char *max77693_charger_model  = "MAX77693";
 static const char *max77693_charger_manufacturer   = "Maxim Integrated";
 
@@ -31,12 +34,21 @@ struct max77693_charger {
struct device   *dev;
struct max77693_dev *max77693;
struct power_supply *charger;
+   struct regulator*regu;
 
u32 constant_volt;
u32 min_system_volt;
u32 thermal_regulation_temp;
u32 batttery_overcurrent;
u32 charge_input_threshold_volt;
+
+   /* SDP/DCP USB charging cable notifications */
+   struct {
+   struct extcon_dev *edev;
+   bool connected;
+   struct notifier_block nb;
+   struct work_struct work;
+   } cable;
 };
 
 static int max77693_get_charger_state(struct regmap *regmap, int *val)
@@ -207,12 +219,28 @@ static int max77693_get_online(struct regmap *regmap, int 
*val)
return 0;
 }
 
+int max77693_get_charge_current(struct regmap *regmap, int *val)
+{
+   unsigned int data;
+   int ret;
+
+   ret = regmap_read(regmap, MAX77693_CHG_REG_CHG_CNFG_02, );
+   if (ret < 0)
+   return ret;
+
+   data &= CHG_CNFG_02_CC_MASK;
+   *val = data * 333 / 10; /* 3 steps/0.1A */
+
+   return 0;
+}
+
 static enum power_supply_property max77693_charger_props[] = {
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_CHARGE_TYPE,
POWER_SUPPLY_PROP_HEALTH,
POWER_SUPPLY_PROP_PRESENT,
POWER_SUPPLY_PROP_ONLINE,
+   POWER_SUPPLY_PROP_CURRENT_NOW,
POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_MANUFACTURER,
 };
@@ -241,6 +269,9 @@ static int max77693_charger_get_property(struct 
power_supply *psy,
case POWER_SUPPLY_PROP_ONLINE:
ret = max77693_get_online(regmap, >intval);
break;
+   case POWER_SUPPLY_PROP_CURRENT_NOW:
+   ret = max77693_get_charge_current(regmap, >intval);
+   break;
case POWER_SUPPLY_PROP_MODEL_NAME:
val->strval = max77693_charger_model;
break;
@@ -295,6 +326,7 @@ static ssize_t fast_charge_timer_show(struct device *dev,
 
data &= CHG_CNFG_01_FCHGTIME_MASK;
data >>= CHG_CNFG_01_FCHGTIME_SHIFT;
+
switch (data) {
case 0x1 ... 0x7:
/* Starting from 4 hours, step by 2 hours */
@@ -582,6 +614,97 @@ static int max77693_set_charge_input_threshold_volt(struct 
max77693_charger *chg
CHG_CNFG_12_VCHGINREG_MASK, data);
 }
 
+static int max77693_enable_charger(struct max77693_charger *chg, bool enable)
+{
+   int ret;
+
+   if (enable) {
+   regulator_set_current_limit(chg->regu,
+   CHG_CNFG_09_CHGIN_ILIM_500_MIN,
+   CHG_CNFG_09_CHGIN_ILIM_500_MAX);
+   if (ret < 0)
+   return ret;
+
+   ret = regulator_enable(chg->regu);
+   if (ret < 0)
+   return ret;
+   } else {
+   /* sets fast charge current to zero */
+   ret = regulator_set_current_limit(chg->regu,
+ 

Re: [PATCH] kcov: properly check if we are in an interrupt

2016-09-26 Thread Andrew Morton
On Fri, 23 Sep 2016 16:51:13 +0200 Andrey Konovalov  
wrote:

> in_interrupt() returns a nonzero value when we are either in an
> interrupt or have bh disabled via local_bh_disable(). Since we are
> interested in only ignoring coverage from actual interrupts, do a
> proper check of whether we are really in an interrupt.
> 
> Signed-off-by: Andrey Konovalov 
> ---
> It would look totally better to reuse in_irq(), in_serving_softirq() and
> in_nmi() instead of checking flags manually, but that leads to slower
> generated code (three separate tests for each of the flags). Would it be
> better to add another macro to preempt.h that would check if we're actually
> in interrupt and use it?

Yes please.  Is there anywhere else where such a macro can be used?

> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -54,7 +54,8 @@ void notrace __sanitizer_cov_trace_pc(void)
>* We are interested in code coverage as a function of a syscall inputs,
>* so we ignore code executed in interrupts.
>*/
> - if (!t || in_interrupt())
> + if (!t || (preempt_count() & (HARDIRQ_MASK | SOFTIRQ_OFFSET
> + | NMI_MASK)))

Or include a prominent and very apologetic comment here explaining why
it is open-coded.  But I do agree that not open-coding it is better.


[PATCH 0/3] max77693: USB event listener for charger

2016-09-26 Thread Wolfgang Wiedmeyer
This patch series adds an USB event listener to the charger driver
that enables charging if an USB cable is connected. Before the charger
can be enabled, the maximum input current and the fast charge current
need to be set. In order to make this possible, the regulator function
that sets the current needs to be extended. 

Wolfgang Wiedmeyer (3):
  mfd: max77693: Add defines for charger current control
  regulator: max77693: Also manipulate the fast charge current
  power_supply: max77693: Listen for cable events and enable charging

 drivers/power/Kconfig  |   2 +-
 drivers/power/max77693_charger.c   | 171 +
 drivers/regulator/max77693-regulator.c |  45 -
 include/linux/mfd/max77693-private.h   |   7 ++
 4 files changed, 221 insertions(+), 4 deletions(-)

-- 
2.8.0.rc3



[PATCH 1/3] mfd: max77693: Add defines for charger current control

2016-09-26 Thread Wolfgang Wiedmeyer
This prepares for an updated regulator and charger driver. The defines
are needed to set the maximum input current and the fast charge
current.

Signed-off-by: Wolfgang Wiedmeyer 
---
 include/linux/mfd/max77693-private.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/mfd/max77693-private.h 
b/include/linux/mfd/max77693-private.h
index 3c7a63b..ca18344 100644
--- a/include/linux/mfd/max77693-private.h
+++ b/include/linux/mfd/max77693-private.h
@@ -222,6 +222,9 @@ enum max77693_charger_battery_state {
 #define CHG_CNFG_00_CHG_MASK   0x1
 #define CHG_CNFG_00_BUCK_MASK  0x4
 
+/* MAX77693 CHG_CNFG_02 register */
+#define CHG_CNFG_02_CC_MASK0x3F
+
 /* MAX77693_CHG_REG_CHG_CNFG_01 register */
 #define CHG_CNFG_01_FCHGTIME_SHIFT 0
 #define CHG_CNFG_01_CHGRSTRT_SHIFT 4
@@ -258,6 +261,10 @@ enum max77693_charger_battery_state {
 
 /* MAX77693 CHG_CNFG_09 Register */
 #define CHG_CNFG_09_CHGIN_ILIM_MASK0x7F
+#define CHG_CNFG_09_CHGIN_ILIM_500_MAX 50
+#define CHG_CNFG_09_CHGIN_ILIM_500_MIN 47
+#define CHG_CNFG_09_CHGIN_ILIM_0_MAX   6
+#define CHG_CNFG_09_CHGIN_ILIM_0_MIN   0
 
 /* MAX77693 CHG_CTRL Register */
 #define SAFEOUT_CTRL_SAFEOUT1_MASK 0x3
-- 
2.8.0.rc3



Re: [PATCH v2] raid6/test/test.c: bug fix: Specify aligned(alignment) attributes to the char arrays

2016-09-26 Thread Shaohua Li
On Mon, Sep 26, 2016 at 02:37:38PM -0700, Gayatri Kammela wrote:
> Specifying the aligned attributes to the char data[NDISKS][PAGE_SIZE],
> char recovi[PAGE_SIZE] and char recovi[PAGE_SIZE] arrays, so that all
> malloc memory is page boundary aligned.
> 
> Without these alignment attributes, the test causes a segfault in
> userspace when the NDISKS are changed to 4 from 16.
> 
> The RAID stripes will be page aligned anyway, so we want to test what
> the kernel actually will execute.

Applied, thanks!


  1   2   3   4   5   6   7   >