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

[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: [PATCH] extcon: usb-gpio: Add VBUS detection support

[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)) {
> - dev_err(dev, "failed to 

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

[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: linux-next: build failure after merge of the rdma tree

[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

[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: [v6,2/2] QE: remove PPCisms for QE

[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

[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: [PATCH v2 5/5] ISDN-Gigaset: Enclose two expressions for the sizeof operator by parentheses

[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)

[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

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

[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

[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 0/3] ARM: dts: omap5 uevm: add LEDs, USR1 button and EEPROM

[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

[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 3/3] DT: EVM: add USR1 button

[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

[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

[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

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

[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

[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

[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: Release memory in gigaset_initcs() after an allocation failure

[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

[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: ISDN-Gigaset: Fine-tuning for three function implementations

[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.

[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.

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

[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

[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

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

[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

[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

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

[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

[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?

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

[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

[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.

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

[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

[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: [PATCH v2 1/2] config: Add new CONFIG_PROVE_LOCKING_SMALL

[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

[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: [RFC/PATCH] usb: misc: Add a driver for TC7USB40MU

[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

[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 v6 0/2] Add USB configuration for imx53

[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

[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 v3] mmc: sdhci-msm: Add pm_runtime and system PM support

[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

[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 v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI

[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

[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] ARM: dts: imx6: Add support for Toradex Colibri iMX6 module

[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>;
> + status = "okay";
> +
> +  

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

[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 1/7] selftest: sync: basic tests for sw_sync framework

[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

[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: [PATCH] scsi: be2iscsi: mark symbols static where possible

[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

[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: [x86-tip] strange nr_cpus= boot regression

[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

[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?

Re: [PATCH 00/11] splice cleanups

[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

[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;  \
  })
  

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

[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*

[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

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

[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

[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

[PATCH] igb: Realign bad indentation

[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

[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

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

[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()

[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 09/11] splice: use get_page_for_read()

[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

[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 08/11] filemap: add get_page_for_read() helper

[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.

[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 V2] sched/fair: Fix that tasks are not constrained by cfs_b->quota on hotplug core, when hotplug core is offline and then online.

[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

[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 06/11] pipe: no need to confirm page cache buf

[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

[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 

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

[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

[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

[PATCH] i40e: Make struct i40e_stats const

[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

[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 0/2] Improve libsas hotplug

[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

[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 

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

[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 a/drivers/scsi/libsas/sas_init.c b/drivers/scsi/libsas/sas_init.c
index 

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

[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
>

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

[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

[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 

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

[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 work_struct *work)
+static void sas_add_device(struct work_struct *work)

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

[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: [x86-tip] strange nr_cpus= boot regression

[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

[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: Regression in 4.8 - CPU speed set very low

[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

[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: [PATCH 00/17] clean up readlinks

[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

[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: [bug] crypto/vmx/p8_ghash memory corruption in 4.8-rc7

[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

['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: [PATCH v3] Input: elants_i2c - get product id on recovery mode for FW update

['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

[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: Regression in 4.8 - CPU speed set very low

[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

[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] watchdog: hpwdt: add support for iLO5

[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

[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: [PATCH 1/2] f2fs: fix to commit bio cache after flushing node pages

[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

[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

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

[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

[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

[PATCH v2] f2fs: introduce get_checkpoint_version for cleanup

[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