Re: [PATCH v3] regmap: regmap-irq/gpio-max77620: add level-irq support

2018-12-26 Thread Matti Vaittinen
Hello All,

On Thu, Dec 27, 2018 at 09:35:31AM +0200, Matti Vaittinen wrote:
> On Wed, Dec 26, 2018 at 12:39:17PM +0100, Geert Uytterhoeven wrote:
> > Hi Matti,
> > 
> > On Tue, Dec 18, 2018 at 1:00 PM Matti Vaittinen
> >  wrote:
> > > Add level active IRQ support to regmap-irq irqchip. Change breaks
> > > existing regmap-irq type setting. Convert the existing drivers which
> > 
> > Indeed it does.
> > 
> > > use regmap-irq with trigger type setting (gpio-max77620) to work
> > > with this new approach. So we do not magically support level-active
> > > IRQs on gpio-max77620 - but add support to the regmap-irq for chips
> > > which support them =)
> > >
> > > We do not support distinguishing situation where HW supports rising
> > > and falling edge detection but not both. Separating this would require
> > > inventing yet another flags for IRQ types.
> > >
> > > Signed-off-by: Matti Vaittinen 
> > 
> > This is now upstream as commit 1c2928e3e3212252 ("regmap:
> > regmap-irq/gpio-max77620: add level-irq support"), and breaks da9063-rtc
> > on the Renesas Koelsch board:
> > 
> > genirq: Setting trigger mode 8 for irq 157 failed
> > (regmap_irq_set_type+0x0/0x140)
> > da9063-rtc da9063-rtc: Failed to request ALARM IRQ 157: -524
> > da9063-rtc: probe of da9063-rtc failed with error -524
> 
> This is strange as I do not see any type setting support code in
> drivers/mfd/da9063-irq.c. The type setting registers are neither
> specified in static const struct regmap_irq_chip da9063l_irq_chip nor
> in static const struct regmap_irq_chip da9063_irq_chip. Hence I don't
> understand how the da9063 could have been supporting IRQ type setting in
> first place.
> 
> > > ---
> > >
> > > Version 3 of this patch is intended to be functionally identical to v2.
> > > This patch is rebased on top of a tree which contains changes:
> > > "regmap: irq: handle HW using separate rising/falling edge interrupts"
> > > from Bartosz Golaszewski and the change
> > > "regmap: regmap-irq: Remove default irq type setting from core"
> > > (proposed here):
> > > https://lore.kernel.org/lkml/20181218105813.GA6957@localhost.localdomain/
> > >
> > > There should not be direct dependency to "regmap: regmap-irq: Remove
> > > default irq type setting from core" though. Patch was also tested to
> > > apply cleany on regmap-tree.
> > >
> > > Same statement regarding testing applies - gpio-max77620 are only
> > > tested to compile. All real testing would be _HIGHLY_ appreciated.
> > >
> > >  drivers/base/regmap/regmap-irq.c | 35 ++-
> > >  drivers/gpio/gpio-max77620.c | 96 
> > > ++--
> > >  include/linux/regmap.h   | 27 ---
> > >  3 files changed, 110 insertions(+), 48 deletions(-)
> > >
> > > diff --git a/drivers/base/regmap/regmap-irq.c 
> > > b/drivers/base/regmap/regmap-irq.c
> > > index 8b216b2e2c19..31d23c9a5ae7 100644
> > > --- a/drivers/base/regmap/regmap-irq.c
> > > +++ b/drivers/base/regmap/regmap-irq.c
> > > @@ -199,7 +199,7 @@ static void regmap_irq_enable(struct irq_data *data)
> > > const struct regmap_irq *irq_data = irq_to_regmap_irq(d, 
> > > data->hwirq);
> > > unsigned int mask, type;
> > >
> > > -   type = irq_data->type_falling_mask | irq_data->type_rising_mask;
> > > +   type = irq_data->type.type_falling_val | 
> > > irq_data->type.type_rising_val;
> > >
> > > /*
> > >  * The type_in_mask flag means that the underlying hardware uses
> > > @@ -234,27 +234,42 @@ static int regmap_irq_set_type(struct irq_data 
> > > *data, unsigned int type)
> > > struct regmap_irq_chip_data *d = irq_data_get_irq_chip_data(data);
> > > struct regmap *map = d->map;
> > > const struct regmap_irq *irq_data = irq_to_regmap_irq(d, 
> > > data->hwirq);
> > > -   int reg = irq_data->type_reg_offset / map->reg_stride;
> > > +   int reg;
> > > +   const struct regmap_irq_type *t = _data->type;
> > >
> > > -   if (!(irq_data->type_rising_mask | irq_data->type_falling_mask))
> > > -   return 0;
> > > +   if ((t->types_supported & type) != type)
> > > +   return -ENOTSUPP;
> > 
> > Given types_supported defaults to zero, I think this breaks every existing
> > setup using REGMAP_IRQ_REG().

Right. Now I see what you mean. Original code did:

if (!(irq_data->type_rising_mask | irq_data->type_falling_mask))
return 0;

Eg, even when the driver was not able to perform the type-setting this
failure was silently ignored, right. So doing:
   if ((t->types_supported & type) != type)
   return 0;
would be functionally equal. It feels like utterly wrong thing to do
(to me) - if driver is written to work with edge or level active
interrupts - and if the irq controller is not supporting this - then we
should warn the user. Just silently ignoring this sounds like asking for
irq storm or missed interrupts - but maybe I just don't get this =)

I'll 

Re: [PATCH V4 1/3] mmc: sdhci: add support for using external DMA devices

2018-12-26 Thread Adrian Hunter
On 11/12/18 11:12 AM, Chunyan Zhang wrote:
> Some standard SD host controllers can support both external dma
> controllers as well as ADMA/SDMA in which the SD host controller
> acts as DMA master. TI's omap controller is the case as an example.
> 
> Currently the generic SDHCI code supports ADMA/SDMA integrated in
> the host controller but does not have any support for external DMA
> controllers implemented using dmaengine, meaning that custom code is
> needed for any systems that use an external DMA controller with SDHCI.
> 
> Signed-off-by: Chunyan Zhang 

FYI, I am waiting on successful testing before reviewing these patches again.


Re: [PATCH v3] regmap: regmap-irq/gpio-max77620: add level-irq support

2018-12-26 Thread Matti Vaittinen
Hello Geert,

Sorry for waiting - I just opened my computer after the holidays.

On Wed, Dec 26, 2018 at 12:39:17PM +0100, Geert Uytterhoeven wrote:
> Hi Matti,
> 
> On Tue, Dec 18, 2018 at 1:00 PM Matti Vaittinen
>  wrote:
> > Add level active IRQ support to regmap-irq irqchip. Change breaks
> > existing regmap-irq type setting. Convert the existing drivers which
> 
> Indeed it does.
> 
> > use regmap-irq with trigger type setting (gpio-max77620) to work
> > with this new approach. So we do not magically support level-active
> > IRQs on gpio-max77620 - but add support to the regmap-irq for chips
> > which support them =)
> >
> > We do not support distinguishing situation where HW supports rising
> > and falling edge detection but not both. Separating this would require
> > inventing yet another flags for IRQ types.
> >
> > Signed-off-by: Matti Vaittinen 
> 
> This is now upstream as commit 1c2928e3e3212252 ("regmap:
> regmap-irq/gpio-max77620: add level-irq support"), and breaks da9063-rtc
> on the Renesas Koelsch board:
> 
> genirq: Setting trigger mode 8 for irq 157 failed
> (regmap_irq_set_type+0x0/0x140)
> da9063-rtc da9063-rtc: Failed to request ALARM IRQ 157: -524
> da9063-rtc: probe of da9063-rtc failed with error -524

This is strange as I do not see any type setting support code in
drivers/mfd/da9063-irq.c. The type setting registers are neither
specified in static const struct regmap_irq_chip da9063l_irq_chip nor
in static const struct regmap_irq_chip da9063_irq_chip. Hence I don't
understand how the da9063 could have been supporting IRQ type setting in
first place.

> > ---
> >
> > Version 3 of this patch is intended to be functionally identical to v2.
> > This patch is rebased on top of a tree which contains changes:
> > "regmap: irq: handle HW using separate rising/falling edge interrupts"
> > from Bartosz Golaszewski and the change
> > "regmap: regmap-irq: Remove default irq type setting from core"
> > (proposed here):
> > https://lore.kernel.org/lkml/20181218105813.GA6957@localhost.localdomain/
> >
> > There should not be direct dependency to "regmap: regmap-irq: Remove
> > default irq type setting from core" though. Patch was also tested to
> > apply cleany on regmap-tree.
> >
> > Same statement regarding testing applies - gpio-max77620 are only
> > tested to compile. All real testing would be _HIGHLY_ appreciated.
> >
> >  drivers/base/regmap/regmap-irq.c | 35 ++-
> >  drivers/gpio/gpio-max77620.c | 96 
> > ++--
> >  include/linux/regmap.h   | 27 ---
> >  3 files changed, 110 insertions(+), 48 deletions(-)
> >
> > diff --git a/drivers/base/regmap/regmap-irq.c 
> > b/drivers/base/regmap/regmap-irq.c
> > index 8b216b2e2c19..31d23c9a5ae7 100644
> > --- a/drivers/base/regmap/regmap-irq.c
> > +++ b/drivers/base/regmap/regmap-irq.c
> > @@ -199,7 +199,7 @@ static void regmap_irq_enable(struct irq_data *data)
> > const struct regmap_irq *irq_data = irq_to_regmap_irq(d, 
> > data->hwirq);
> > unsigned int mask, type;
> >
> > -   type = irq_data->type_falling_mask | irq_data->type_rising_mask;
> > +   type = irq_data->type.type_falling_val | 
> > irq_data->type.type_rising_val;
> >
> > /*
> >  * The type_in_mask flag means that the underlying hardware uses
> > @@ -234,27 +234,42 @@ static int regmap_irq_set_type(struct irq_data *data, 
> > unsigned int type)
> > struct regmap_irq_chip_data *d = irq_data_get_irq_chip_data(data);
> > struct regmap *map = d->map;
> > const struct regmap_irq *irq_data = irq_to_regmap_irq(d, 
> > data->hwirq);
> > -   int reg = irq_data->type_reg_offset / map->reg_stride;
> > +   int reg;
> > +   const struct regmap_irq_type *t = _data->type;
> >
> > -   if (!(irq_data->type_rising_mask | irq_data->type_falling_mask))
> > -   return 0;
> > +   if ((t->types_supported & type) != type)
> > +   return -ENOTSUPP;
> 
> Given types_supported defaults to zero, I think this breaks every existing
> setup using REGMAP_IRQ_REG().

Not really. The type setting support is not too old or widely used in
regmap_irq. If the type_base and num_type_reg in struct regmap_irq_chip
have not been given the type setting has not been supported. And the
macro REGMAP_IRQ_REG() has not been initializing those fields - they
must have been explicitly set by the driver. Only in-tree driver which
really used the regmap_irq type-setting was gpio-max77620 (if my
grepping did not go totally wrong). Is your version of
drivers/mfd/da9063-irq.c same I can see in
https://elixir.bootlin.com/linux/v4.20/source/drivers/mfd/da9063-irq.c ?

I will try to see if the regmap_irq code has just silently ignored irq
type setting requests if type setting information has not been populated
by driver. May that has been changed by my patch. I wonder what would be
the correct action if there is no type-setting information in
struct 

[PATCH 0/4] Add MediaTek MUSB Controller Driver

2018-12-26 Thread min.guo
From: Min Guo 

These patches introduce the MediaTek MUSB controller driver.

The driver can be configured as Dual-Role Device (DRD),
Peripheral Only and Host Only modes. This has beed tested on
MT2701 with a variety of devices in host mode and with the 
f_mass gadget driver in peripheral mode, plugging otg cables
in/out a lot of times in all possible imaginable plug orders

Min Guo (4):
  dt-bindings: usb: musb: Add support for MediaTek musb controller
  arm: dts: mt2701: Add usb2 device nodes
  usb: musb: Move musbhsdma macro definition to musb_dma.h
  usb: musb: Add support for MediaTek musb controller

 .../devicetree/bindings/usb/mediatek,musb.txt  |  49 ++
 arch/arm/boot/dts/mt2701-evb.dts   |  21 +
 arch/arm/boot/dts/mt2701.dtsi  |  34 ++
 drivers/usb/musb/Kconfig   |   8 +-
 drivers/usb/musb/Makefile  |   1 +
 drivers/usb/musb/mediatek.c| 562 +
 drivers/usb/musb/musb_core.c   |  10 +
 drivers/usb/musb/musb_core.h   |   1 +
 drivers/usb/musb/musb_dma.h|   7 +
 drivers/usb/musb/musb_host.c   |  79 ++-
 drivers/usb/musb/musb_regs.h   |   6 +
 drivers/usb/musb/musbhsdma.c   |  41 +-
 12 files changed, 782 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt
 create mode 100644 drivers/usb/musb/mediatek.c

-- 
1.9.1



[PATCH 4/4] usb: musb: Add support for MediaTek musb controller

2018-12-26 Thread min.guo
From: Min Guo 

This adds support for MediaTek musb controller in
host, peripheral and otg mode

Signed-off-by: Min Guo 
Signed-off-by: Yonglong Wu 
---
 drivers/usb/musb/Kconfig |   8 +-
 drivers/usb/musb/Makefile|   1 +
 drivers/usb/musb/mediatek.c  | 562 +++
 drivers/usb/musb/musb_core.c |  10 +
 drivers/usb/musb/musb_core.h |   1 +
 drivers/usb/musb/musb_dma.h  |   1 +
 drivers/usb/musb/musb_host.c |  79 --
 drivers/usb/musb/musb_regs.h |   6 +
 drivers/usb/musb/musbhsdma.c |  34 ++-
 9 files changed, 671 insertions(+), 31 deletions(-)
 create mode 100644 drivers/usb/musb/mediatek.c

diff --git a/drivers/usb/musb/Kconfig b/drivers/usb/musb/Kconfig
index ad08895..540fc9f 100644
--- a/drivers/usb/musb/Kconfig
+++ b/drivers/usb/musb/Kconfig
@@ -115,6 +115,12 @@ config USB_MUSB_JZ4740
depends on USB_MUSB_GADGET
depends on USB_OTG_BLACKLIST_HUB
 
+config USB_MUSB_MEDIATEK
+   tristate "MediaTek platforms"
+   depends on ARCH_MEDIATEK
+   depends on NOP_USB_XCEIV
+   depends on GENERIC_PHY
+
 config USB_MUSB_AM335X_CHILD
tristate
 
@@ -141,7 +147,7 @@ config USB_UX500_DMA
 
 config USB_INVENTRA_DMA
bool 'Inventra'
-   depends on USB_MUSB_OMAP2PLUS
+   depends on USB_MUSB_OMAP2PLUS || USB_MUSB_MEDIATEK
help
  Enable DMA transfers using Mentor's engine.
 
diff --git a/drivers/usb/musb/Makefile b/drivers/usb/musb/Makefile
index 3a88c79..63d82d0 100644
--- a/drivers/usb/musb/Makefile
+++ b/drivers/usb/musb/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_USB_MUSB_DA8XX)  += da8xx.o
 obj-$(CONFIG_USB_MUSB_UX500)   += ux500.o
 obj-$(CONFIG_USB_MUSB_JZ4740)  += jz4740.o
 obj-$(CONFIG_USB_MUSB_SUNXI)   += sunxi.o
+obj-$(CONFIG_USB_MUSB_MEDIATEK)+= mediatek.o
 
 
 obj-$(CONFIG_USB_MUSB_AM335X_CHILD)+= musb_am335x.o
diff --git a/drivers/usb/musb/mediatek.c b/drivers/usb/musb/mediatek.c
new file mode 100644
index 000..15a6460
--- /dev/null
+++ b/drivers/usb/musb/mediatek.c
@@ -0,0 +1,562 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 MediaTek Inc.
+ *
+ * Author:
+ *  Min Guo 
+ *  Yonglong Wu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "musb_core.h"
+#include "musb_dma.h"
+
+#define USB_L1INTS 0x00a0
+#define USB_L1INTM 0x00a4
+#define MTK_MUSB_TXFUNCADDR0x0480
+
+#define TX_INT_STATUS  BIT(0)
+#define RX_INT_STATUS  BIT(1)
+#define USBCOM_INT_STATUS  BIT(2)
+#define DMA_INT_STATUS BIT(3)
+
+#define DMA_INTR_STATUS_MSKGENMASK(7, 0)
+#define DMA_INTR_UNMASK_SET_MSKGENMASK(31, 24)
+
+enum mtk_vbus_id_state {
+   MTK_ID_FLOAT = 1,
+   MTK_ID_GROUND,
+   MTK_VBUS_OFF,
+   MTK_VBUS_VALID,
+};
+
+struct mtk_glue {
+   struct device *dev;
+   struct musb *musb;
+   struct platform_device *musb_pdev;
+   struct platform_device *usb_phy;
+   struct phy *phy;
+   struct usb_phy *xceiv;
+   enum phy_mode phy_mode;
+   struct clk *main;
+   struct clk *mcu;
+   struct clk *univpll;
+   struct regulator *vbus;
+   struct extcon_dev *edev;
+   struct notifier_block vbus_nb;
+   struct notifier_block id_nb;
+};
+
+static int mtk_musb_clks_get(struct mtk_glue *glue)
+{
+   struct device *dev = glue->dev;
+
+   glue->main = devm_clk_get(dev, "main");
+   if (IS_ERR(glue->main)) {
+   dev_err(dev, "fail to get main clock\n");
+   return PTR_ERR(glue->main);
+   }
+
+   glue->mcu = devm_clk_get(dev, "mcu");
+   if (IS_ERR(glue->mcu)) {
+   dev_err(dev, "fail to get mcu clock\n");
+   return PTR_ERR(glue->mcu);
+   }
+
+   glue->univpll = devm_clk_get(dev, "univpll");
+   if (IS_ERR(glue->univpll)) {
+   dev_err(dev, "fail to get univpll clock\n");
+   return PTR_ERR(glue->univpll);
+   }
+
+   return 0;
+}
+
+static int mtk_musb_clks_enable(struct mtk_glue *glue)
+{
+   int ret;
+
+   ret = clk_prepare_enable(glue->main);
+   if (ret) {
+   dev_err(glue->dev, "failed to enable main clock\n");
+   goto err_main_clk;
+   }
+
+   ret = clk_prepare_enable(glue->mcu);
+   if (ret) {
+   dev_err(glue->dev, "failed to enable mcu clock\n");
+   goto err_mcu_clk;
+   }
+
+   ret = clk_prepare_enable(glue->univpll);
+   if (ret) {
+   dev_err(glue->dev, "failed to enable univpll clock\n");
+   goto err_univpll_clk;
+   }
+
+   return 0;
+
+err_univpll_clk:
+   clk_disable_unprepare(glue->mcu);
+err_mcu_clk:
+   clk_disable_unprepare(glue->main);
+err_main_clk:
+   return ret;
+}
+
+static void mtk_musb_clks_disable(struct mtk_glue *glue)
+{
+   clk_disable_unprepare(glue->univpll);
+   

[PATCH 3/4] usb: musb: Move musbhsdma macro definition to musb_dma.h

2018-12-26 Thread min.guo
From: Min Guo 

Because the MediaTek musb controller dose not have a
separate DMA interrupt, these macros are required to
access the dma registers

Signed-off-by: Min Guo 
---
 drivers/usb/musb/musb_dma.h  | 6 ++
 drivers/usb/musb/musbhsdma.c | 7 +--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/musb/musb_dma.h b/drivers/usb/musb/musb_dma.h
index 8f60271..281e75d3 100644
--- a/drivers/usb/musb/musb_dma.h
+++ b/drivers/usb/musb/musb_dma.h
@@ -35,6 +35,12 @@
  *whether shared with the Inventra core or separate.
  */
 
+#define MUSB_HSDMA_BASE0x200
+#define MUSB_HSDMA_INTR(MUSB_HSDMA_BASE + 0)
+#define MUSB_HSDMA_CONTROL 0x4
+#define MUSB_HSDMA_ADDRESS 0x8
+#define MUSB_HSDMA_COUNT   0xc
+
 #defineDMA_ADDR_INVALID(~(dma_addr_t)0)
 
 #ifdef CONFIG_MUSB_PIO_ONLY
diff --git a/drivers/usb/musb/musbhsdma.c b/drivers/usb/musb/musbhsdma.c
index a688f7f..824adcb 100644
--- a/drivers/usb/musb/musbhsdma.c
+++ b/drivers/usb/musb/musbhsdma.c
@@ -10,12 +10,7 @@
 #include 
 #include 
 #include "musb_core.h"
-
-#define MUSB_HSDMA_BASE0x200
-#define MUSB_HSDMA_INTR(MUSB_HSDMA_BASE + 0)
-#define MUSB_HSDMA_CONTROL 0x4
-#define MUSB_HSDMA_ADDRESS 0x8
-#define MUSB_HSDMA_COUNT   0xc
+#include "musb_dma.h"
 
 #define MUSB_HSDMA_CHANNEL_OFFSET(_bchannel, _offset)  \
(MUSB_HSDMA_BASE + (_bchannel << 4) + _offset)
-- 
1.9.1



[PATCH 2/4] arm: dts: mt2701: Add usb2 device nodes

2018-12-26 Thread min.guo
From: Min Guo 

Add musb nodes and usb2 phy nodes for MT2701

Signed-off-by: Min Guo 
---
 arch/arm/boot/dts/mt2701-evb.dts | 21 +
 arch/arm/boot/dts/mt2701.dtsi| 34 ++
 2 files changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701-evb.dts b/arch/arm/boot/dts/mt2701-evb.dts
index be0edb3..2635911 100644
--- a/arch/arm/boot/dts/mt2701-evb.dts
+++ b/arch/arm/boot/dts/mt2701-evb.dts
@@ -6,6 +6,7 @@
  */
 
 /dts-v1/;
+#include 
 #include "mt2701.dtsi"
 
 / {
@@ -60,6 +61,20 @@
>;
default-brightness-level = <9>;
};
+
+   extcon_usb: extcon_iddig {
+   compatible = "linux,extcon-usb-gpio";
+   id-gpio = < 44 GPIO_ACTIVE_HIGH>;
+   };
+
+   usb_vbus: regulator@0 {
+   compatible = "regulator-fixed";
+   regulator-name = "usb_vbus";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   gpio = < 45 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 };
 
  {
@@ -229,3 +244,9 @@
  {
status = "okay";
 };
+
+ {
+   vbus-supply = <_vbus>;
+   extcon = <_usb>;
+   status = "okay";
+};
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 180377e..495ece9 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -670,6 +670,40 @@
};
};
 
+   usb2: usb@1120 {
+   compatible = "mediatek,mt2701-musb",
+   "mediatek,mtk-musb";
+   reg = <0 0x1120 0 0x1000>;
+   interrupts = ;
+   interrupt-names = "mc";
+   phys = < PHY_TYPE_USB2>;
+   phy-names = "usb2-phy";
+   dr_mode = "otg";
+   clocks = < CLK_PERI_USB0>,
+< CLK_PERI_USB0_MCU>,
+< CLK_PERI_USB_SLV>;
+   clock-names = "main","mcu","univpll";
+   power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
+   status = "disabled";
+   };
+
+   u2phy0: usb-phy@1121 {
+   compatible = "mediatek,generic-tphy-v1";
+   reg = <0 0x1121 0 0x0800>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "okay";
+
+   u2port2: usb-phy@1a1c4800 {
+   reg = <0 0x11210800 0 0x0100>;
+   clocks = < CLK_TOP_USB_PHY48M>;
+   clock-names = "ref";
+   #phy-cells = <1>;
+   status = "okay";
+   };
+   };
+
ethsys: syscon@1b00 {
compatible = "mediatek,mt2701-ethsys", "syscon";
reg = <0 0x1b00 0 0x1000>;
-- 
1.9.1



[PATCH 1/4] dt-bindings: usb: musb: Add support for MediaTek musb controller

2018-12-26 Thread min.guo
From: Min Guo 

This adds support for MediaTek musb controller in
host, peripheral and otg mode

Signed-off-by: Min Guo 
---
 .../devicetree/bindings/usb/mediatek,musb.txt  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/usb/mediatek,musb.txt

diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.txt 
b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
new file mode 100644
index 000..e899c9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mediatek,musb.txt
@@ -0,0 +1,49 @@
+MediaTek musb DRC/OTG controller
+---
+
+Required properties:
+ - compatible  : should be "mediatek,-musb",
+   "mediatek,mtk-musb", soc-model is the name of SoC, such as
+   mt2701, when using "mediatek,mtk-musb" compatible string, you
+   need SoC specific ones in addition, one of:
+   - "mediatek,mt2701-musb"
+ - reg : specifies physical base address and size of
+   the registers
+ - interrupts  : interrupt used by musb controller
+ - interrupt-names : must be "mc"
+ - phys: PHY specifier for the OTG phy
+ - phy-names   : should be "usb2-phy"
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+   refer to usb/generic.txt
+ - clocks  : a list of phandle + clock-specifier pairs, one for
+   each entry in clock-names
+ - clock-names : must contain "main","mcu","univpll"
+   for clocks of controller
+
+Optional properties:
+ - extcon : external connector for VBUS and IDPIN changes detection,
+   needed when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+   dual-role mode.
+ - power-domains   : a phandle to USB power domain node to control USB's
+   MTCMOS
+
+Example:
+
+usb2: usb@1120 {
+   compatible = "mediatek,mt2701-musb";
+   "mediatek,mtk-musb";
+   reg = <0 0x1120 0 0x1000>;
+   interrupts = ;
+   interrupt-names = "mc";
+   phys = < PHY_TYPE_USB2>;
+   phy-names = "usb2-phy";
+   vbus-supply = <_vbus>;
+   extcon = <_usb>;
+   dr_mode = "otg";
+   clocks = < CLK_PERI_USB0>,
+< CLK_PERI_USB0_MCU>,
+< CLK_PERI_USB_SLV>;
+   clock-names = "main","mcu","univpll";
+   power-domains = < MT2701_POWER_DOMAIN_IFR_MSC>;
+};
-- 
1.9.1



[PATCH] um: writev needs

2018-12-26 Thread Christoph Hellwig
vector_user.c doesn't compile without this for me.

Signed-off-by: Christoph Hellwig 
---
 arch/um/drivers/vector_user.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/um/drivers/vector_user.c b/arch/um/drivers/vector_user.c
index 3d8cdbdb4e66..41eefbcdc86f 100644
--- a/arch/um/drivers/vector_user.c
+++ b/arch/um/drivers/vector_user.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.19.2



[PATCH v6 3/6] Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990

2018-12-26 Thread Balakrishna Godavarthi
During initalization of wcn3990, we observed UART is reading some
stray bytes on the Rx line. This is logging Frame reassembly errors
on the serial console. This could be because of tristate of Tx line
of wcn3990 during boot up.

[  176.929612] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed 
(-84)
[  176.945734] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed 
(-84)
[  176.953298] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed 
(-84)
[  177.010660] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed 
(-84)
[  177.067633] Bluetooth: hci_qca.c:qca_recv() hci0: Frame reassembly failed 
(-84)

Now we enable a flag during bootup to stop executing proto receive
function and clear it back once the initialization is done.

Signed-off-by: Balakrishna Godavarthi 
Tested-by: Matthias Kaehlcke 
---
 drivers/bluetooth/hci_qca.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 63436023632d..0751b2359f6f 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -56,6 +56,7 @@
 
 /* Controller states */
 #define STATE_IN_BAND_SLEEP_ENABLED1
+#define STATE_DISCARD_RX   2
 
 #define IBS_WAKE_RETRANS_TIMEOUT_MS100
 #define IBS_TX_IDLE_TIMEOUT_MS 2000
@@ -511,6 +512,7 @@ static int qca_open(struct hci_uart *hu)
} else {
hu->init_speed = qcadev->init_speed;
hu->oper_speed = qcadev->oper_speed;
+   set_bit(STATE_DISCARD_RX, >flags);
ret = qca_power_setup(hu, true);
if (ret) {
destroy_workqueue(qca->workqueue);
@@ -903,6 +905,13 @@ static int qca_recv(struct hci_uart *hu, const void *data, 
int count)
if (!test_bit(HCI_UART_REGISTERED, >flags))
return -EUNATCH;
 
+   /* We discard Rx data received while device is in booting
+* stage, This is because of BT chip Tx line is in tristate.
+* Due to this we read some garbage data on UART Rx.
+*/
+   if (test_bit(STATE_DISCARD_RX, >flags))
+   return 0;
+
qca->rx_skb = h4_recv_buf(hu->hdev, qca->rx_skb, data, count,
  qca_recv_pkts, ARRAY_SIZE(qca_recv_pkts));
if (IS_ERR(qca->rx_skb)) {
@@ -1195,6 +1204,7 @@ static int qca_setup(struct hci_uart *hu)
if (ret)
return ret;
 
+   clear_bit(STATE_DISCARD_RX, >flags);
ret = qca_read_soc_version(hdev, _ver);
if (ret)
return ret;
@@ -1271,6 +1281,12 @@ static const struct qca_vreg_data qca_soc_data = {
 
 static void qca_power_shutdown(struct hci_uart *hu)
 {
+   struct qca_data *qca = hu->priv;
+
+   /* From this point we go into power off state. But serial port is
+* still open, discard all the garbage data received on the Rx line.
+*/
+   set_bit(STATE_DISCARD_RX, >flags);
host_set_baudrate(hu, 2400);
qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
qca_power_setup(hu, false);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 2/6] Bluetooth: hci_qca: Deassert RTS while baudrate change command

2018-12-26 Thread Balakrishna Godavarthi
This patch will help to stop frame reassembly errors while changing
the baudrate. This is because host send a change baudrate request
command to the chip with 115200 bps, Whereas chip will change their
UART clocks to the enable for new baudrate and sends the response
for the change request command with newer baudrate, On host side
we are still operating in 115200 bps which results of reading garbage
data. Here we are pulling RTS line, so that chip we will wait to send data
to host until host change its baudrate.

Signed-off-by: Balakrishna Godavarthi 
Tested-by: Matthias Kaehlcke 
Reviewed-by: Matthias Kaehlcke 
---
 drivers/bluetooth/hci_qca.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 507a2355c758..63436023632d 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t 
baudrate)
struct hci_uart *hu = hci_get_drvdata(hdev);
struct qca_data *qca = hu->priv;
struct sk_buff *skb;
-   struct qca_serdev *qcadev;
u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };
 
if (baudrate > QCA_BAUDRATE_320)
@@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t 
baudrate)
return -ENOMEM;
}
 
-   /* Disabling hardware flow control is mandatory while
-* sending change baudrate request to wcn3990 SoC.
-*/
-   qcadev = serdev_device_get_drvdata(hu->serdev);
-   if (qcadev->btsoc_type == QCA_WCN3990)
-   hci_uart_set_flow_control(hu, true);
-
/* Assign commands to change baudrate and packet type. */
skb_put_data(skb, cmd, sizeof(cmd));
hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
@@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t 
baudrate)
schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
set_current_state(TASK_RUNNING);
 
-   if (qcadev->btsoc_type == QCA_WCN3990)
-   hci_uart_set_flow_control(hu, false);
-
return 0;
 }
 
@@ -1087,6 +1076,7 @@ static int qca_check_speeds(struct hci_uart *hu)
 static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type speed_type)
 {
unsigned int speed, qca_baudrate;
+   struct qca_serdev *qcadev;
int ret;
 
if (speed_type == QCA_INIT_SPEED) {
@@ -1098,6 +1088,15 @@ static int qca_set_speed(struct hci_uart *hu, enum 
qca_speed_type speed_type)
if (!speed)
return 0;
 
+   /* Deassert RTS while changing the baudrate of chip and host.
+* This will prevent chip from transmitting its response with
+* the new baudrate while the host port is still operating at
+* the old speed.
+*/
+   qcadev = serdev_device_get_drvdata(hu->serdev);
+   if (qcadev->btsoc_type == QCA_WCN3990)
+   serdev_device_set_rts(hu->serdev, false);
+
qca_baudrate = qca_get_baudrate_value(speed);
bt_dev_dbg(hu->hdev, "Set UART speed to %d", speed);
ret = qca_set_baudrate(hu->hdev, qca_baudrate);
@@ -1105,6 +1104,9 @@ static int qca_set_speed(struct hci_uart *hu, enum 
qca_speed_type speed_type)
return ret;
 
host_set_baudrate(hu, speed);
+
+   if (qcadev->btsoc_type == QCA_WCN3990)
+   serdev_device_set_rts(hu->serdev, true);
}
 
return 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 1/6] Bluetooth: hci_qca: use wait_until_sent() for power pulses

2018-12-26 Thread Balakrishna Godavarthi
wcn3990 requires a power pulse to turn ON/OFF along with
regulators. Sometimes we are observing the power pulses are sent
out with some time delay, due to queuing these commands. This is
causing synchronization issues with chip, which intern delay the
chip setup or may end up with communication issues.

Signed-off-by: Balakrishna Godavarthi 
---
Changes in v6:
 * added serdev_device_write_flush() in qca_send_power_pulse
   instead during the power off pulse.

Changes in v5:
 * added serdev_device_write_flush() in qca_power_off().

---
 drivers/bluetooth/hci_qca.c | 38 ++---
 1 file changed, 14 insertions(+), 24 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index f036c8f98ea3..507a2355c758 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1013,11 +1013,9 @@ static inline void host_set_baudrate(struct hci_uart 
*hu, unsigned int speed)
hci_uart_set_baudrate(hu, speed);
 }
 
-static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
+static int qca_send_power_pulse(struct hci_uart *hu, u8 cmd)
 {
-   struct hci_uart *hu = hci_get_drvdata(hdev);
-   struct qca_data *qca = hu->priv;
-   struct sk_buff *skb;
+   int ret;
 
/* These power pulses are single byte command which are sent
 * at required baudrate to wcn3990. On wcn3990, we have an external
@@ -1029,19 +1027,17 @@ static int qca_send_power_pulse(struct hci_dev *hdev, 
u8 cmd)
 * save power. Disabling hardware flow control is mandatory while
 * sending power pulses to SoC.
 */
-   bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
-
-   skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
-   if (!skb)
-   return -ENOMEM;
-
+   serdev_device_write_flush(hu->serdev);
+   bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);
hci_uart_set_flow_control(hu, true);
+   ret = serdev_device_write_buf(hu->serdev, , sizeof(cmd));
+   if (ret < 0) {
+   bt_dev_err(hu->hdev, "failed to send power pulse %02x to SoC",
+  cmd);
+   return ret;
+   }
 
-   skb_put_u8(skb, cmd);
-   hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
-
-   skb_queue_tail(>txq, skb);
-   hci_uart_tx_wakeup(hu);
+   serdev_device_wait_until_sent(hu->serdev, 0);
 
/* Wait for 100 uS for SoC to settle down */
usleep_range(100, 200);
@@ -1116,7 +1112,6 @@ static int qca_set_speed(struct hci_uart *hu, enum 
qca_speed_type speed_type)
 
 static int qca_wcn3990_init(struct hci_uart *hu)
 {
-   struct hci_dev *hdev = hu->hdev;
struct qca_serdev *qcadev;
int ret;
 
@@ -1139,12 +1134,12 @@ static int qca_wcn3990_init(struct hci_uart *hu)
 
/* Forcefully enable wcn3990 to enter in to boot mode. */
host_set_baudrate(hu, 2400);
-   ret = qca_send_power_pulse(hdev, QCA_WCN3990_POWEROFF_PULSE);
+   ret = qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
if (ret)
return ret;
 
qca_set_speed(hu, QCA_INIT_SPEED);
-   ret = qca_send_power_pulse(hdev, QCA_WCN3990_POWERON_PULSE);
+   ret = qca_send_power_pulse(hu, QCA_WCN3990_POWERON_PULSE);
if (ret)
return ret;
 
@@ -1274,13 +1269,8 @@ static const struct qca_vreg_data qca_soc_data = {
 
 static void qca_power_shutdown(struct hci_uart *hu)
 {
-   struct serdev_device *serdev = hu->serdev;
-   unsigned char cmd = QCA_WCN3990_POWEROFF_PULSE;
-
host_set_baudrate(hu, 2400);
-   hci_uart_set_flow_control(hu, true);
-   serdev_device_write_buf(serdev, , sizeof(cmd));
-   hci_uart_set_flow_control(hu, false);
+   qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
qca_power_setup(hu, false);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 4/6] Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer

2018-12-26 Thread Balakrishna Godavarthi
During hci down we observed IBS sleep commands are queued in the Tx
buffer and hci_uart_write_work is sending data to the chip which is
not required as the chip is powered off. This patch will disable IBS
and flush the Tx buffer before we turn off the chip.

Signed-off-by: Balakrishna Godavarthi 
---
 drivers/bluetooth/hci_qca.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 0751b2359f6f..4677a6a2716a 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -1287,6 +1287,8 @@ static void qca_power_shutdown(struct hci_uart *hu)
 * still open, discard all the garbage data received on the Rx line.
 */
set_bit(STATE_DISCARD_RX, >flags);
+   clear_bit(STATE_IN_BAND_SLEEP_ENABLED, >flags);
+   qca_flush(hu);
host_set_baudrate(hu, 2400);
qca_send_power_pulse(hu, QCA_WCN3990_POWEROFF_PULSE);
qca_power_setup(hu, false);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 0/6] Bug fixes for Qualcomm BT chip wcn3990

2018-12-26 Thread Balakrishna Godavarthi
The below issues are found in the recent testing.

1. Observed device is not going into off state or not responding.
As wcn3990 require a power pulses to turn on the irrespctive of
igniting regulators, it was observed that power on or power off
pulses are not in sync with respective to chip.
The below patch will help us to wait until byte is pushed on to wires.  


* Bluetooth: hci_qca: use wait_until_sent() for power pulses

2. Observed Chip responding when we are in sleep.
   This is due to turn on flow control during change baudrate request.
   The below patch will only pull the RTS line high instead of turning off
   the flow.

   * Bluetooth: hci_qca: Pull RTS line high for baudrate change command.

3. Frame reassembly errors splashing on console.
   wcn3990 requires will use multiple baudrates during booting stage.
   i.e. 2400 bps while sending power off pulse
115200 bps while sending power on pulse
port close
port open
set baudrate to 115200 request the chip version.

  during above process, we are seeing some stray bytes coming up
  on the UART Rx FIFO it could be due to frequent baudrate change.

  This patch will stop the frame reassembly errors.

  * Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990

4. Disable IBS state machine and flush Tx buffer
   We are disabling IBS and flushing the Tx buffer before turning off the chip.
  
   This is due to IBS state machine is active when we turn off the chip.
   This will stop queuing IBS protocol bytes.

   * Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer

5. hci_qca: Update baudrate change wait time for wcn3990
   
   This patch will help to decrease the BT on time by 200ms.
   we updated the baudrate change wait time to 100ms instead of 300ms.
   
6. btqca: inject command complete event during fw download
   
   Qualcomm latest chip will not send an command complete event
   for last packet of the fw dump sent, so here we are inject an command 
   complete event.

   * Bluetooth: btqca: inject command complete event during fw download

Changes in v6:
 * added serdev_device_write_flush in qca_send_power_pulse().
 * added new patch to update the baudrate change wait time.

Changes in V5:
 * added serdev_device_write_flush before sending the power off pulse
   during shutdown.

Changes in v4:
 * used serdev_device_write_buf() instead of serdev_device_write().
 * added new patch to stop logging of 0xfc00 timeout on console.

Changes in v3:
 * moved IBS & qca_flush to different patch
 * updated comments in code fo Deassert RTS patch

Balakrishna Godavarthi (6):
  Bluetooth: hci_qca: use wait_until_sent() for power pulses
  Bluetooth: hci_qca: Deassert RTS while baudrate change command
  Bluetooth: hci_qca: Fix frame reassembly errors for wcn3990
  Bluetooth: hci_qca: Disable IBS state machine and flush Tx buffer
  Bluetooth: hci_qca: Update baudrate change wait time for wcn3990
  Bluetooth: btqca: inject command complete event during fw download

 drivers/bluetooth/btqca.c   | 39 +++-
 drivers/bluetooth/btqca.h   |  3 ++
 drivers/bluetooth/hci_qca.c | 88 ++---
 3 files changed, 94 insertions(+), 36 deletions(-)

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



[PATCH v6 6/6] Bluetooth: btqca: inject command complete event during fw download

2018-12-26 Thread Balakrishna Godavarthi
Latest qualcomm chips are not sending an command complete event for
every firmware packet sent to chip. They only respond with a vendor
specific event for the last firmware packet. This optimization will
decrease the BT ON time. Due to this we are seeing a timeout error
message logs on the console during firmware download. Now we are
injecting a command complete event once we receive an vendor specific
event for the last RAM firmware packet.

Signed-off-by: Balakrishna Godavarthi 
---
 drivers/bluetooth/btqca.c | 39 ++-
 drivers/bluetooth/btqca.h |  3 +++
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c
index ec9e03a6b778..0b533f65f652 100644
--- a/drivers/bluetooth/btqca.c
+++ b/drivers/bluetooth/btqca.c
@@ -144,6 +144,7 @@ static void qca_tlv_check_data(struct rome_config *config,
 * In case VSE is skipped, only the last segment is acked.
 */
config->dnld_mode = tlv_patch->download_mode;
+   config->dnld_type = config->dnld_mode;
 
BT_DBG("Total Length   : %d bytes",
   le32_to_cpu(tlv_patch->total_size));
@@ -264,6 +265,31 @@ static int qca_tlv_send_segment(struct hci_dev *hdev, int 
seg_size,
return err;
 }
 
+static int qca_inject_cmd_complete_event(struct hci_dev *hdev)
+{
+   struct hci_event_hdr *hdr;
+   struct hci_ev_cmd_complete *evt;
+   struct sk_buff *skb;
+
+   skb = bt_skb_alloc(sizeof(*hdr) + sizeof(*evt) + 1, GFP_KERNEL);
+   if (!skb)
+   return -ENOMEM;
+
+   hdr = skb_put(skb, sizeof(*hdr));
+   hdr->evt = HCI_EV_CMD_COMPLETE;
+   hdr->plen = sizeof(*evt) + 1;
+
+   evt = skb_put(skb, sizeof(*evt));
+   evt->ncmd = 1;
+   evt->opcode = HCI_OP_NOP;
+
+   skb_put_u8(skb, QCA_HCI_CC_SUCCESS);
+
+   hci_skb_pkt_type(skb) = HCI_EVENT_PKT;
+
+   return hci_recv_frame(hdev, skb);
+}
+
 static int qca_download_firmware(struct hci_dev *hdev,
  struct rome_config *config)
 {
@@ -297,11 +323,22 @@ static int qca_download_firmware(struct hci_dev *hdev,
ret = qca_tlv_send_segment(hdev, segsize, segment,
config->dnld_mode);
if (ret)
-   break;
+   goto out;
 
segment += segsize;
}
 
+   /* Latest qualcomm chipsets are not sending a command complete event
+* for every fw packet sent. They only respond with a vendor specific
+* event for the last packet. This optimization in the chip will
+* decrease the BT in initialization time. Here we will inject a command
+* complete event to avoid a command timeout error message.
+*/
+   if ((config->dnld_type == ROME_SKIP_EVT_VSE_CC ||
+   config->dnld_type == ROME_SKIP_EVT_VSE))
+   return qca_inject_cmd_complete_event(hdev);
+
+out:
release_firmware(fw);
 
return ret;
diff --git a/drivers/bluetooth/btqca.h b/drivers/bluetooth/btqca.h
index 0c01f375fe83..5c8fc54133e3 100644
--- a/drivers/bluetooth/btqca.h
+++ b/drivers/bluetooth/btqca.h
@@ -40,6 +40,8 @@
 #define QCA_WCN3990_POWERON_PULSE  0xFC
 #define QCA_WCN3990_POWEROFF_PULSE 0xC0
 
+#define QCA_HCI_CC_SUCCESS 0x00
+
 enum qca_bardrate {
QCA_BAUDRATE_115200 = 0,
QCA_BAUDRATE_57600,
@@ -81,6 +83,7 @@ struct rome_config {
char fwname[64];
uint8_t user_baud_rate;
enum rome_tlv_dnld_mode dnld_mode;
+   enum rome_tlv_dnld_mode dnld_type;
 };
 
 struct edl_event_hdr {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



[PATCH v6 5/6] Bluetooth: hci_qca: Update baudrate change wait time for wcn3990

2018-12-26 Thread Balakrishna Godavarthi
This patch will update the baudrate change request wait time from
300 ms to 100 ms. When host sends the change baudrate request to
the controller, controller sets its clock and wait until the
clocks settle down. Here the Wait time is required for both
host and controller to be on sync.

Signed-off-by: Balakrishna Godavarthi 
---

Changes in v6:
 * intial patch.

---
 drivers/bluetooth/hci_qca.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
index 4677a6a2716a..61b0fb1ff32f 100644
--- a/drivers/bluetooth/hci_qca.c
+++ b/drivers/bluetooth/hci_qca.c
@@ -60,7 +60,8 @@
 
 #define IBS_WAKE_RETRANS_TIMEOUT_MS100
 #define IBS_TX_IDLE_TIMEOUT_MS 2000
-#define BAUDRATE_SETTLE_TIMEOUT_MS 300
+#define ROME_BD_SETTLE_TIMEOUT_MS  300
+#define WCN3990_BD_SETTLE_TIMEOUT_MS   100
 
 /* susclk rate */
 #define SUSCLK_RATE_32KHZ  32768
@@ -972,8 +973,11 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t 
baudrate)
struct hci_uart *hu = hci_get_drvdata(hdev);
struct qca_data *qca = hu->priv;
struct sk_buff *skb;
+   struct qca_serdev *qcadev;
+   unsigned int bd_settling_timeout;
u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };
 
+   qcadev = serdev_device_get_drvdata(hu->serdev);
if (baudrate > QCA_BAUDRATE_320)
return -EINVAL;
 
@@ -996,8 +1000,12 @@ static int qca_set_baudrate(struct hci_dev *hdev, uint8_t 
baudrate)
 * controller will come back after they receive this HCI command
 * then host can communicate with new baudrate to controller
 */
+   bd_settling_timeout = qcadev->btsoc_type == QCA_WCN3990 ?
+  WCN3990_BD_SETTLE_TIMEOUT_MS :
+  ROME_BD_SETTLE_TIMEOUT_MS;
+
set_current_state(TASK_UNINTERRUPTIBLE);
-   schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
+   schedule_timeout(msecs_to_jiffies(bd_settling_timeout));
set_current_state(TASK_RUNNING);
 
return 0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project



Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS

2018-12-26 Thread james qian wang (Arm Technology China)
On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology 
> China) wrote:
> > Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> >   CRTC: according to the komeda_pipeline
> >   PLANE: according to komeda_layer (layer input pipeline)
> >   PRIVATE_OBJS: komeda_pipeline/component all will be treat as private_objs
> > 
> > komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> > kms object properties according to the komeda_dev, and pass/convert KMS's
> > requirement to komeda_dev.
> > 
> > Changes in v3:
> > - Fixed style problem found by checkpatch.pl --strict.
> > 
> > Changes in v2:
> > - Unified abbreviation of "pipeline" to "pipe".
> > 
> > Signed-off-by: James (Qian) Wang 
> > ---
> >  drivers/gpu/drm/arm/display/komeda/Makefile   |   6 +-
> >  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 106 +++
> >  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  19 +-
> >  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 169 ++
> >  .../gpu/drm/arm/display/komeda/komeda_kms.h   | 113 
> >  .../drm/arm/display/komeda/komeda_pipeline.h  |   3 +
> >  .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> >  .../arm/display/komeda/komeda_private_obj.c   |  88 +
> >  8 files changed, 608 insertions(+), 5 deletions(-)
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> > 
> > diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> > b/drivers/gpu/drm/arm/display/komeda/Makefile
> > index 25beae900ed2..1b875e5dc0f6 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> > +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> > @@ -9,7 +9,11 @@ komeda-y := \
> > komeda_dev.o \
> > komeda_format_caps.o \
> > komeda_pipeline.o \
> > -   komeda_framebuffer.o
> > +   komeda_framebuffer.o \
> > +   komeda_kms.o \
> > +   komeda_crtc.o \
> > +   komeda_plane.o \
> > +   komeda_private_obj.o
> >  
> >  komeda-y += \
> > d71/d71_dev.o
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > new file mode 100644
> > index ..5bb5a55f6b31
> > --- /dev/null
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > @@ -0,0 +1,106 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > + * Author: James.Qian.Wang 
> > + *
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "komeda_dev.h"
> > +#include "komeda_kms.h"
> > +
> > +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> > +};
> > +
> > +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> > +};
> > +
> > +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> > +  struct komeda_dev *mdev)
> > +{
> > +   struct komeda_crtc *crtc;
> > +   struct komeda_pipeline *master;
> > +   char str[16];
> > +   int i;
> > +
> > +   kms->n_crtcs = 0;
> > +
> > +   for (i = 0; i < mdev->n_pipelines; i++) {
> > +   crtc = >crtcs[kms->n_crtcs];
> > +   master = mdev->pipelines[i];
> > +
> > +   crtc->master = master;
> > +   crtc->slave  = NULL;
> > +
> > +   if (crtc->slave)
> > +   sprintf(str, "pipe-%d", crtc->slave->id);
> > +   else
> > +   sprintf(str, "None");
> > +
> > +   DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: %s.\n",
> > +kms->n_crtcs, master->id, str,
> > +master->of_output_dev ?
> > +master->of_output_dev->full_name : "None");
> > +
> > +   kms->n_crtcs++;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static struct drm_plane *
> > +get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> > +{
> > +   struct komeda_plane *kplane;
> > +   struct drm_plane *plane;
> > +
> > +   drm_for_each_plane(plane, >base) {
> > +   if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> > +   continue;
> > +
> > +   kplane = to_kplane(plane);
> > +   /* only master can be primary */
> > +   if (kplane->layer->base.pipeline == crtc->master)
> > +   return plane;
> > +   }
> > +
> > +   return NULL;
> > +}
> > +
> > +static int komeda_crtc_add(struct komeda_kms_dev *kms,
> > +  struct komeda_crtc *kcrtc)
> > +{
> > +   struct drm_crtc *crtc = >base;
> > +   int err;
> > +
> > +   err = drm_crtc_init_with_planes(>base, crtc,
> > +   get_crtc_primary(kms, 

Re: Fix 80d20d35af1e ("nohz: Fix local_timer_softirq_pending()") may have revealed another problem

2018-12-26 Thread Frederic Weisbecker
On Mon, Oct 15, 2018 at 10:58:54PM +0200, Heiner Kallweit wrote:
> On 28.09.2018 15:18, Frederic Weisbecker wrote:
> > On Thu, Sep 27, 2018 at 06:05:46PM +0200, Thomas Gleixner wrote:
> >> On Tue, 28 Aug 2018, Frederic Weisbecker wrote:
> >>> On Fri, Aug 24, 2018 at 07:06:32PM +0200, Heiner Kallweit wrote:
>  I tested it and Frederic is right, it doesn't help. Can it be somehow 
>  related to
>  the cpu being brought down during suspend? Because I get the warning 
>  only during
>  suspend when the cpu is inactive already (but still online).
> >>>
> >>> It's hard to tell, I haven't been able to reproduce on suspend to 
> >>> disk/mem.
> >>>
> >>> Does this script eventually trigger it after some time?
> >>
> >> Any update to this?
> > 
> > Heiner? Can you please test the script I sent to you?
> > 
> > Thanks.
> > 
> Sorry, took some time .. And yes, running your script triggers the message 
> too.
> 
> [   25.646015] x86: Booting SMP configuration:
> [   25.646044] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   25.664491] smpboot: CPU 1 is now offline
> [   25.679299] x86: Booting SMP configuration:
> [   25.679329] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   25.698449] smpboot: CPU 1 is now offline
> [   25.711698] x86: Booting SMP configuration:
> [   25.711727] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   25.729185] NOHZ: local_softirq_pending 202
> [   25.729229] NOHZ: local_softirq_pending 202
> [   25.730759] smpboot: CPU 1 is now offline
> [   25.744053] x86: Booting SMP configuration:
> [   25.744083] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   25.762520] smpboot: CPU 1 is now offline
> [   25.776834] x86: Booting SMP configuration:
> [   25.776863] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   25.794189] NOHZ: local_softirq_pending 202
> [   25.796672] smpboot: CPU 1 is now offline
> [   25.805970] x86: Booting SMP configuration:
> [   25.805999] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   25.827360] smpboot: CPU 1 is now offline
> [   25.839043] x86: Booting SMP configuration:
> [   25.839073] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   25.858184] NOHZ: local_softirq_pending 202
> [   25.862182] smpboot: CPU 1 is now offline
> [   25.873759] x86: Booting SMP configuration:
> [   25.873789] smpboot: Booting Node 0 Processor 1 APIC 0x2
> [   25.893385] smpboot: CPU 1 is now offline
> 

Sorry, I got sidetracked and almost forgot about it.

So this is triggered by CPU hotplug. At some point the CPU has an
opportunity to go idle and for some reason the timer softirq is still
pending. We need to know which timer this is about and why the timer
softirq keeps pending.

I'm going to need your help again. Can you please run the following (possibly
repeat until it triggers the bug) ?

   echo 1 > /sys/devices/system/cpu/cpu1/online

   # Pause and reset tracing
   echo 0 > /sys/kernel/debug/tracing/tracing_on
   echo > /sys/kernel/debug/tracing/trace

   # Turn on relevant events
   echo 1 > /sys/kernel/debug/tracing/events/timer/timer_*/enable
   echo 1 > /sys/kernel/debug/tracing/events/irq/softirq_*/enable
   echo 1 > /sys/kernel/debug/tracing/tracing_on

   # Trigger
   echo 0 > /sys/devices/system/cpu/cpu1/online

   echo 0 > /sys/kernel/debug/tracing/tracing_on

And please apply the following patch before. With all that I'll have the
relevant informations stored in /sys/kernel/debug/tracing/per_cpu/cpu1/trace
Please send its content to me. Thanks!

diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 69e673b..0e57a3b 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -892,6 +892,7 @@ static bool can_stop_idle_tick(int cpu, struct tick_sched 
*ts)
(local_softirq_pending() & SOFTIRQ_STOP_IDLE_MASK)) {
pr_warn("NOHZ: local_softirq_pending %02x\n",
(unsigned int) local_softirq_pending());
+   trace_dump_stack(0);
ratelimit++;
}
return false;



Re: [PATCH v3 1/9] drm/komeda: komeda_dev/pipeline/component definition and initialzation

2018-12-26 Thread james qian wang (Arm Technology China)
On Mon, Dec 24, 2018 at 07:57:41PM +0800, Liviu Dudau wrote:
> On Fri, Dec 21, 2018 at 09:58:55AM +, james qian wang (Arm Technology 
> China) wrote:
> > 1. Added a brief definition of komeda_dev/pipeline/component, this change
> >didn't add the detailed component features and capabilities, which will
> >be added in the following changes.
> > 2. Corresponding resources discovery and initialzation functions.
> > 
> > Signed-off-by: James (Qian) Wang 
> > 
> > Changes in v3:
> > - Fixed style problem found by checkpatch.pl --strict.
> > 
> > Changes in v2:
> > - Unified abbreviation of "pipeline" to "pipe".
> > ---
> >  drivers/gpu/drm/arm/Kconfig   |   2 +
> >  drivers/gpu/drm/arm/Makefile  |   1 +
> >  drivers/gpu/drm/arm/display/Kbuild|   3 +
> >  drivers/gpu/drm/arm/display/Kconfig   |  14 +
> >  .../drm/arm/display/include/malidp_product.h  |  23 ++
> >  .../drm/arm/display/include/malidp_utils.h|  16 +
> >  drivers/gpu/drm/arm/display/komeda/Makefile   |  11 +
> >  .../gpu/drm/arm/display/komeda/komeda_dev.c   | 117 ++
> >  .../gpu/drm/arm/display/komeda/komeda_dev.h   |  98 +
> >  .../drm/arm/display/komeda/komeda_pipeline.c  | 198 ++
> >  .../drm/arm/display/komeda/komeda_pipeline.h  | 350 ++
> >  11 files changed, 833 insertions(+)
> >  create mode 100644 drivers/gpu/drm/arm/display/Kbuild
> >  create mode 100644 drivers/gpu/drm/arm/display/Kconfig
> >  create mode 100644 drivers/gpu/drm/arm/display/include/malidp_product.h
> >  create mode 100644 drivers/gpu/drm/arm/display/include/malidp_utils.h
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/Makefile
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_dev.c
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_dev.h
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_pipeline.c
> >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_pipeline.h
> > 
> > diff --git a/drivers/gpu/drm/arm/Kconfig b/drivers/gpu/drm/arm/Kconfig
> > index f9f7761cb2f4..a204103b3efb 100644
> > --- a/drivers/gpu/drm/arm/Kconfig
> > +++ b/drivers/gpu/drm/arm/Kconfig
> > @@ -37,4 +37,6 @@ config DRM_MALI_DISPLAY
> >  
> >   If compiled as a module it will be called mali-dp.
> >  
> > +source "drivers/gpu/drm/arm/display/Kconfig"
> > +
> >  endmenu
> > diff --git a/drivers/gpu/drm/arm/Makefile b/drivers/gpu/drm/arm/Makefile
> > index 3bf31d1a4722..120bef801fcf 100644
> > --- a/drivers/gpu/drm/arm/Makefile
> > +++ b/drivers/gpu/drm/arm/Makefile
> > @@ -3,3 +3,4 @@ obj-$(CONFIG_DRM_HDLCD) += hdlcd.o
> >  mali-dp-y := malidp_drv.o malidp_hw.o malidp_planes.o malidp_crtc.o
> >  mali-dp-y += malidp_mw.o
> >  obj-$(CONFIG_DRM_MALI_DISPLAY) += mali-dp.o
> > +obj-$(CONFIG_DRM_KOMEDA) += display/
> > diff --git a/drivers/gpu/drm/arm/display/Kbuild 
> > b/drivers/gpu/drm/arm/display/Kbuild
> > new file mode 100644
> > index ..382f1ca831e4
> > --- /dev/null
> > +++ b/drivers/gpu/drm/arm/display/Kbuild
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +
> > +obj-$(CONFIG_DRM_KOMEDA) += komeda/
> > diff --git a/drivers/gpu/drm/arm/display/Kconfig 
> > b/drivers/gpu/drm/arm/display/Kconfig
> > new file mode 100644
> > index ..cec0639e3aa1
> > --- /dev/null
> > +++ b/drivers/gpu/drm/arm/display/Kconfig
> > @@ -0,0 +1,14 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +config DRM_KOMEDA
> > +   tristate "ARM Komeda display driver"
> > +   depends on DRM && OF
> > +   depends on COMMON_CLK
> > +   select DRM_KMS_HELPER
> > +   select DRM_KMS_CMA_HELPER
> > +   select DRM_GEM_CMA_HELPER
> > +   select VIDEOMODE_HELPERS
> > +   help
> > + Choose this option if you want to compile the ARM Komeda display
> > + Processor driver. It supports the D71 variants of the hardware.
> > +
> > + If compiled as a module it will be called komeda.
> > diff --git a/drivers/gpu/drm/arm/display/include/malidp_product.h 
> > b/drivers/gpu/drm/arm/display/include/malidp_product.h
> > new file mode 100644
> > index ..b35fc5db866b
> > --- /dev/null
> > +++ b/drivers/gpu/drm/arm/display/include/malidp_product.h
> > @@ -0,0 +1,23 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +/*
> > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > + * Author: James.Qian.Wang 
> > + *
> > + */
> > +#ifndef _MALIDP_PRODUCT_H_
> > +#define _MALIDP_PRODUCT_H_
> > +
> > +/* Product identification */
> > +#define MALIDP_CORE_ID(__product, __major, __minor, __status) \
> > +   __product) & 0x) << 16) | (((__major) & 0xF) << 12) | \
> > +   (((__minor) & 0xF) << 8) | ((__status) & 0xFF))
> > +
> > +#define MALIDP_CORE_ID_PRODUCT_ID(__core_id) ((__u32)(__core_id) >> 16)
> > +#define MALIDP_CORE_ID_MAJOR(__core_id)  (((__u32)(__core_id) >> 12) & 
> > 0xF)
> > +#define MALIDP_CORE_ID_MINOR(__core_id)  (((__u32)(__core_id) >> 8) & 
> > 0xF)
> > +#define 

Re: [PATCH v3 2/9] dt/bindings: drm/komeda: Add DT bindings for ARM display processor D71

2018-12-26 Thread james qian wang (Arm Technology China)
On Mon, Dec 24, 2018 at 08:00:51PM +0800, Liviu Dudau wrote:
> On Fri, Dec 21, 2018 at 09:59:12AM +, james qian wang (Arm Technology 
> China) wrote:
> > Add DT bindings documentation for the ARM display processor D71 and later
> > IPs.
> > 
> > Signed-off-by: James (Qian) Wang 
> > 
> > Changes in v3:
> > - Deleted unnecessary property: interrupt-names.
> > - Dropped 'ports' and moving 'port' up a level.
> > ---
> >  .../bindings/display/arm/arm,komeda.txt   | 79 +++
> >  1 file changed, 79 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/display/arm/arm,komeda.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/display/arm/arm,komeda.txt 
> > b/Documentation/devicetree/bindings/display/arm/arm,komeda.txt
> > new file mode 100644
> > index ..b4e450243c7d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/arm/arm,komeda.txt
> > @@ -0,0 +1,79 @@
> > +Device Tree bindings for ARM Komeda display driver
> > +
> > +Required properties:
> > +- compatible: Should be "arm,mali-d71"
> > +- reg: Physical base address and length of the registers in the system
> > +- interrupts: the interrupt line number of the device in the system
> > +- clocks: A list of phandle + clock-specifier pairs, one for each entry
> > +in 'clock-names'
> > +- clock-names: A list of clock names. It should contain:
> > +  - "mclk": for the main processor clock
> > +  - "pclk": for the APB interface clock
> > +- #address-cells: Must be 1
> > +- #size-cells: Must be 0
> > +
> > +Required properties for sub-node: pipeline@nq
> > +Each device contains one or two pipeline sub-nodes (at least one), each
> > +pipeline node should provide properties:
> > +- reg: Zero-indexed identifier for the pipeline
> > +- clocks: A list of phandle + clock-specifier pairs, one for each entry
> > +in 'clock-names'
> > +- clock-names: should contain:
> > +  - "pxclk": pixel clock
> > +  - "aclk": AXI interface clock
> > +
> > +- port: each pipeline connect to an encoder input port. The connection is
> > +modeled using the OF graph bindings specified in
> > +Documentation/devicetree/bindings/graph.txt
> > +
> > +Optional properties:
> > +  - memory-region: phandle to a node describing memory (see
> > +Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt)
> > +to be used for the framebuffer; if not present, the framebuffer may
> > +be located anywhere in memory.
> > +
> > +Example:
> > +/ {
> > +   ...
> > +
> > +   dp0: display@c0 {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +   compatible = "arm,mali-d71";
> > +   reg = <0xc0 0x2>;
> > +   interrupts = <0 168 4>;
> > +   clocks = <_mclk>, <_aclk>;
> > +   clock-names = "mclk", "pclk";
> > +
> > +   dp0_pipe0: pipeline@0 {
> > +   clocks = <>, <_aclk>;
> > +   clock-names = "pxclk", "aclk";
> > +   reg = <0>;
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> 
> These are undocumented and not necessary anyway, as the pipelines will
> inherit display's attributes.

thank you, will fix it in the next version.

> > +
> > +   port@0 {
> > +   dp0_pipe0_out: endpoint {
> > +   remote-endpoint = <_dvi0_in>;
> > +   };
> > +   };
> > +   };
> > +
> > +   dp0_pipe1: pipeline@1 {
> > +   clocks = <>, <_aclk>;
> > +   clock-names = "pxclk", "aclk";
> > +   reg = <1>;
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> 
> same here.

OK.

> 
> > +
> > +   port@0 {
> > +   dp0_pipe1_out: endpoint {
> > +   remote-endpoint = <_dvi1_in>;
> > +   };
> > +   };
> > +   };
> > +   };
> > +   ...
> > +};
> > -- 
> > 2.17.1
> > 
> 
> With these changes:
> 
> Reviewed-by: Liviu Dudau 
> 
> Best regards,
> Liviu
> 
> 
> -- 
> 
> | I would like to |
> | fix the world,  |
> | but they're not |
> | giving me the   |
>  \ source code!  /
>   ---
> ¯\_(ツ)_/¯


[PATCH v4 06/13] dt-bindings: irqchip: Introduce TISCI Interrupt router bindings

2018-12-26 Thread Lokesh Vutla
Add the DT binding documentation for Interrupt router driver.

Signed-off-by: Lokesh Vutla 
---
 .../interrupt-controller/ti,sci-intr.txt  | 85 +++
 MAINTAINERS   |  1 +
 2 files changed, 86 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt 
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
new file mode 100644
index ..4b0ca797fda1
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
@@ -0,0 +1,85 @@
+Texas Instruments K3 Interrupt Router
+=
+
+The Interrupt Router (INTR) module provides a mechanism to mux M
+interrupt inputs to N interrupt outputs, where all M inputs are selectable
+to be driven per N output. There is one register per output (MUXCNTL_N) that
+controls the selection.
+
+
+ Interrupt Router
+ +--+
+ |  Inputs Outputs  |
++---+| +--+ |
+| GPIO  |--->| | irq0 | |   Host IRQ
++---+| +--+ |  controller
+ |.+-+  |  +---+
++---+|.|  0  |  |->|  IRQ  |
+| INTA  |--->|.+-+  |  +---+
++---+|.  .  |
+ | +--+  .  |
+ | | irqM |+-+  |
+ | +--+|  N  |  |
+ | +-+  |
+ +--+
+
+Configuration of these MUXCNTL_N registers is done by a system controller
+(like the Device Memory and Security Controller on K3 AM654 SoC). System
+controller will keep track of the used and unused registers within the Router.
+Driver should request the system controller to get the range of GIC IRQs
+assigned to the requesting hosts. It is the drivers responsibility to keep
+track of Host IRQs.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Router Node:
+
+- compatible:  Must be "ti,sci-intr".
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+   interrupt source. The value should be 4.
+   First cell should contain the TISCI device ID of source
+   Second cell should contain the interrupt source offset
+   within the device
+   Third cell specifies the trigger type as defined
+   in interrupts.txt in this directory.
+   Fourth cell should be 1 if the irq is coming from
+   interrupt aggregator else 0.
+- ti,sci:  Phandle to TI-SCI compatible System controller node.
+- ti,sci-dst-id:   TISCI device ID of the destination IRQ controller.
+- ti,sci-rm-range-girq:Array of TISCI subtype ids representing the 
host irqs
+   assigned to this interrupt router. Each subtype id
+   corresponds to a range of host irqs.
+
+For more details on TISCI IRQ resource management refer:
+http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
+
+Example:
+
+The following example demonstrates both interrupt router node and the consumer
+node(main gpio) on the AM654 SoC:
+
+main_intr: interrupt-controller0 {
+   compatible = "ti,sci-intr";
+   interrupt-controller;
+   interrupt-parent = <>;
+   #interrupt-cells = <4>;
+   ti,sci = <>;
+   ti,sci-dst-id = <56>;
+   ti,sci-rm-range-girq = <0x1>;
+};
+
+main_gpio0: gpio@60 {
+   ...
+   interrupt-parent = <_intr>;
+   interrupts = <57 256 IRQ_TYPE_EDGE_RISING 0>,
+   <57 257 IRQ_TYPE_EDGE_RISING 0>,
+   <57 258 IRQ_TYPE_EDGE_RISING 0>,
+   <57 259 IRQ_TYPE_EDGE_RISING 0>,
+   <57 260 IRQ_TYPE_EDGE_RISING 0>,
+   <57 261 IRQ_TYPE_EDGE_RISING 0>;
+   ...
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 82dc44b09a7e..8c7513b02d50 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15023,6 +15023,7 @@ F:  
Documentation/devicetree/bindings/reset/ti,sci-reset.txt
 F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
 F: drivers/clk/keystone/sci-clk.c
 F: 

[RFC PATCH v4 09/13] genirq/msi: Add support for .msi_unprepare callback

2018-12-26 Thread Lokesh Vutla
Add an optional callback .msi_unprepare to struct msi_domain_ops.
This is used to clear any effect that is done by .msi_prepare callback.

Signed-off-by: Lokesh Vutla 
---
 include/linux/msi.h |  3 +++
 kernel/irq/msi.c| 10 ++
 2 files changed, 13 insertions(+)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index 474490826f8c..f35dd19f6c69 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -239,6 +239,8 @@ struct msi_domain_ops {
int (*msi_prepare)(struct irq_domain *domain,
   struct device *dev, int nvec,
   msi_alloc_info_t *arg);
+   void(*msi_unprepare)(struct irq_domain *domain, int nvec,
+void *data);
void(*msi_finish)(msi_alloc_info_t *arg, int retval);
void(*set_desc)(msi_alloc_info_t *arg,
struct msi_desc *desc);
@@ -319,6 +321,7 @@ void platform_msi_domain_free_irqs(struct device *dev);
 /* When an MSI domain is used as an intermediate domain */
 int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
int nvec, msi_alloc_info_t *args);
+void msi_domain_unprepare_irqs(struct irq_domain *domain, int nvec, void 
*data);
 int msi_domain_populate_irqs(struct irq_domain *domain, struct device *dev,
 int virq, int nvec, msi_alloc_info_t *args);
 struct irq_domain *
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index eb7459324113..1a1738690519 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -312,6 +312,16 @@ int msi_domain_prepare_irqs(struct irq_domain *domain, 
struct device *dev,
return ret;
 }
 
+void msi_domain_unprepare_irqs(struct irq_domain *domain, int nvec,
+  void *data)
+{
+   struct msi_domain_info *info = domain->host_data;
+   struct msi_domain_ops *ops = info->ops;
+
+   if (ops->msi_unprepare)
+   ops->msi_unprepare(domain, nvec, data);
+}
+
 int msi_domain_populate_irqs(struct irq_domain *domain, struct device *dev,
 int virq, int nvec, msi_alloc_info_t *arg)
 {
-- 
2.19.2



[RFC PATCH v4 10/13] soc: ti: Add MSI domain support for K3 Interrupt Aggregator

2018-12-26 Thread Lokesh Vutla
With the system coprocessor managing the range allocation of the
inputs to Interrupt Aggregator, it is difficult to represent
the device IRQs from DT.

The suggestion is to use MSI in such cases where devices wants
to allocate and group interrupts dynamically.

Create a MSI domain bus layer that allocates and frees MSIs for
a device.

APIs that are implemented are:
- inta_msi_create_irq_domain() that creates a MSI domain
- inta_msi_domain_alloc_group_irqs() that creates MSIs for the
  specified device and source indexes. All these are expected to
  be grouped by the parent interrupt controller to MSI domain.
- inta_msi_domain_free_group_irqs() frees the grouped irqs.

Signed-off-by: Lokesh Vutla 
---

- May be the same functionaly can be included in platform msi. But I would
  like to get a feedback on the approach.

 drivers/soc/ti/Kconfig |   6 +
 drivers/soc/ti/Makefile|   1 +
 drivers/soc/ti/k3_inta_msi.c   | 193 +
 include/linux/irqdomain.h  |   1 +
 include/linux/msi.h|   6 +
 include/linux/soc/ti/k3_inta_msi.h |  22 
 6 files changed, 229 insertions(+)
 create mode 100644 drivers/soc/ti/k3_inta_msi.c
 create mode 100644 include/linux/soc/ti/k3_inta_msi.h

diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index be4570baad96..7640490c2a6a 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -73,4 +73,10 @@ config TI_SCI_PM_DOMAINS
  called ti_sci_pm_domains. Note this is needed early in boot before
  rootfs may be available.
 
+config K3_INTA_MSI_DOMAIN
+   bool
+   select GENERIC_MSI_IRQ_DOMAIN
+   help
+ Driver to enable Interrupt Aggregator specific MSI Domain.
+
 endif # SOC_TI
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index a22edc0b258a..152b195273ee 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA)+= knav_dma.o
 obj-$(CONFIG_AMX3_PM)  += pm33xx.o
 obj-$(CONFIG_WKUP_M3_IPC)  += wkup_m3_ipc.o
 obj-$(CONFIG_TI_SCI_PM_DOMAINS)+= ti_sci_pm_domains.o
+obj-$(CONFIG_K3_INTA_MSI_DOMAIN)   += k3_inta_msi.o
diff --git a/drivers/soc/ti/k3_inta_msi.c b/drivers/soc/ti/k3_inta_msi.c
new file mode 100644
index ..4658a9f9e1c4
--- /dev/null
+++ b/drivers/soc/ti/k3_inta_msi.c
@@ -0,0 +1,193 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Aggregator driver MSI support
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifdef GENERIC_MSI_DOMAIN_OPS
+
+#define TI_SCI_DEV_ID_MASK 0x
+#define TI_SCI_DEV_ID_SHIFT16
+#define TI_SCI_IRQ_ID_MASK 0x
+#define TI_SCI_IRQ_ID_SHIFT0
+
+#define TO_HWIRQ(id, index)(((id & TI_SCI_DEV_ID_MASK) << \
+TI_SCI_DEV_ID_SHIFT) | \
+   (index & TI_SCI_IRQ_ID_MASK))
+static void inta_msi_set_desc(msi_alloc_info_t *arg, struct msi_desc *desc)
+{
+   arg->desc = desc;
+   arg->hwirq = TO_HWIRQ(desc->inta.dev_id, desc->inta.msi_index);
+}
+#else
+#define inta_msi_set_desc NULL
+#endif
+
+static void inta_msi_update_dom_ops(struct msi_domain_info *info)
+{
+   struct msi_domain_ops *ops = info->ops;
+
+   BUG_ON(!ops);
+
+   if (ops->set_desc == NULL)
+   ops->set_desc = inta_msi_set_desc;
+}
+
+static void inta_msi_write_msg(struct irq_data *data, struct msi_msg *msg)
+{
+}
+
+static void inta_msi_compose_msi_msg(struct irq_data *data,
+struct msi_msg *msg)
+{
+}
+
+static void inta_msi_update_chip_ops(struct msi_domain_info *info)
+{
+   struct irq_chip *chip = info->chip;
+
+   BUG_ON(!chip);
+   if (!chip->irq_mask)
+   chip->irq_mask = irq_chip_mask_parent;
+   if (!chip->irq_unmask)
+   chip->irq_unmask = irq_chip_unmask_parent;
+   if (!chip->irq_eoi)
+   chip->irq_eoi = irq_chip_eoi_parent;
+   if (!chip->irq_set_affinity)
+   chip->irq_set_affinity = msi_domain_set_affinity;
+   if (!chip->irq_write_msi_msg)
+   chip->irq_write_msi_msg = inta_msi_write_msg;
+   if (!chip->irq_compose_msi_msg)
+   chip->irq_compose_msi_msg = inta_msi_compose_msi_msg;
+}
+
+struct irq_domain *inta_msi_create_irq_domain(struct fwnode_handle *fwnode,
+ struct msi_domain_info *info,
+ struct irq_domain *parent)
+{
+   struct irq_domain *domain;
+
+   if (info->flags & MSI_FLAG_USE_DEF_DOM_OPS)
+   inta_msi_update_dom_ops(info);
+   if (info->flags & MSI_FLAG_USE_DEF_CHIP_OPS)
+   inta_msi_update_chip_ops(info);
+
+   domain = msi_create_irq_domain(fwnode, info, 

[RFC PATCH v4 12/13] irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver

2018-12-26 Thread Lokesh Vutla
Texas Instruments' K3 generation SoCs has an IP Interrupt Aggregator
which is an interrupt controller that does the following:
- Converts events to interrupts that can be understood by
  an interrupt router.
- Allows for multiplexing of events to interrupts.

Configuration of the interrupt aggregator registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.

Add support for Interrupt Aggregator driver over TISCI protocol.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Peter Ujfalusi 
---
 MAINTAINERS   |   1 +
 drivers/irqchip/Kconfig   |  12 +
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-ti-sci-inta.c | 561 ++
 4 files changed, 575 insertions(+)
 create mode 100644 drivers/irqchip/irq-ti-sci-inta.c

diff --git a/MAINTAINERS b/MAINTAINERS
index aebce615151e..7d12788c844a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15026,6 +15026,7 @@ F:  drivers/reset/reset-ti-sci.c
 F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
 F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
 F: drivers/irqchip/irq-ti-sci-intr.c
+F: drivers/irqchip/irq-ti-sci-inta.c
 
 Texas Instruments ASoC drivers
 M: Peter Ujfalusi 
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index a8d9bed0254b..d16fd39408ad 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -417,6 +417,18 @@ config TI_SCI_INTR_IRQCHIP
  If you wish to use interrupt router irq resources managed by the
  TI System Controller, say Y here. Otherwise, say N.
 
+config TI_SCI_INTA_IRQCHIP
+   bool
+   depends on TI_SCI_PROTOCOL && ARCH_K3
+   select IRQ_DOMAIN
+   select IRQ_DOMAIN_HIERARCHY
+   select K3_INTA_MSI_DOMAIN
+   help
+ This enables the irqchip driver support for K3 Interrupt aggregator
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt aggregator irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index b4ff376a08ef..a679490a7059 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
 obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
 obj-$(CONFIG_MADERA_IRQ)   += irq-madera.o
 obj-$(CONFIG_TI_SCI_INTR_IRQCHIP)  += irq-ti-sci-intr.o
+obj-$(CONFIG_TI_SCI_INTA_IRQCHIP)  += irq-ti-sci-inta.o
diff --git a/drivers/irqchip/irq-ti-sci-inta.c 
b/drivers/irqchip/irq-ti-sci-inta.c
new file mode 100644
index ..78bfc83a079a
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -0,0 +1,561 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Aggregator irqchip driver
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MAX_EVENTS_PER_VINT64
+
+#define VINT_ENABLE_SET_OFFSET 0x0
+#define VINT_ENABLE_CLR_OFFSET 0x8
+#define VINT_STATUS_OFFSET 0x18
+
+#define TI_SCI_DEV_ID_MASK 0x
+#define TI_SCI_DEV_ID_SHIFT16
+#define TI_SCI_IRQ_ID_MASK 0x
+#define TI_SCI_IRQ_ID_SHIFT0
+
+#define HWIRQ_TO_DEVID(hwirq)  (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
+(TI_SCI_DEV_ID_MASK))
+#define HWIRQ_TO_IRQID(hwirq)  ((hwirq) & (TI_SCI_IRQ_ID_MASK))
+
+/**
+ * struct ti_sci_inta_irq_domain - Structure representing a TISCI based
+ *Interrupt Aggregator IRQ domain.
+ * @sci:   Pointer to TISCI handle
+ * @vint:  TISCI resource pointer representing IA inerrupts.
+ * @global_event:TISCI resource pointer representing global events.
+ * @base:  Base address of the memory mapped IO registers
+ * @ia_id: TISCI device ID of this Interrupt Aggregator.
+ * @dst_id:TISCI device ID of the destination irq controller.
+ */
+struct ti_sci_inta_irq_domain {
+   const struct ti_sci_handle *sci;
+   struct ti_sci_resource *vint;
+   struct ti_sci_resource *global_event;
+   void __iomem *base;
+   u16 ia_id;
+   u16 dst_id;
+};
+
+/**
+ * struct ti_sci_inta_event_desc - Description of an event coming to
+ *Interrupt Aggregator.
+ * @global_event:  Global event number corresponding to this event
+ * @src_id:TISCI device ID of the event source
+ * @src_index: Event source index within the device.
+ */
+struct ti_sci_inta_event_desc {
+   u16 global_event;
+   u16 src_id;
+   u16 src_index;
+};
+
+/**
+ * struct ti_sci_inta_vint_desc - 

[PATCH v4 07/13] irqchip: ti-sci-intr: Add support for Interrupt Router driver

2018-12-26 Thread Lokesh Vutla
Texas Instruments' K3 generation SoCs has an IP Interrupt Router
that does allows for redirection of input interrupts to host
interrupt controller. Interrupt Router inputs are either from a
peripheral or from an Interrupt Aggregator which is another
interrupt controller.

Configuration of the interrupt router registers can only be done by
a system co-processor and the driver needs to send a message to this
co processor over TISCI protocol.

Add support for Interrupt Router driver over TISCI protocol.

Signed-off-by: Lokesh Vutla 
---
 MAINTAINERS   |   1 +
 drivers/irqchip/Kconfig   |  11 ++
 drivers/irqchip/Makefile  |   1 +
 drivers/irqchip/irq-ti-sci-intr.c | 310 ++
 4 files changed, 323 insertions(+)
 create mode 100644 drivers/irqchip/irq-ti-sci-intr.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 8c7513b02d50..4480eb2fe851 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15024,6 +15024,7 @@ F:  
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
 F: drivers/clk/keystone/sci-clk.c
 F: drivers/reset/reset-ti-sci.c
 F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+F: drivers/irqchip/irq-ti-sci-intr.c
 
 Texas Instruments ASoC drivers
 M: Peter Ujfalusi 
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 3d1e60779078..a8d9bed0254b 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -406,6 +406,17 @@ config IMX_IRQSTEER
help
  Support for the i.MX IRQSTEER interrupt multiplexer/remapper.
 
+config TI_SCI_INTR_IRQCHIP
+   bool
+   depends on TI_SCI_PROTOCOL && ARCH_K3
+   select IRQ_DOMAIN
+   select IRQ_DOMAIN_HIERARCHY
+   help
+ This enables the irqchip driver support for K3 Interrupt router
+ over TI System Control Interface available on some new TI's SoCs.
+ If you wish to use interrupt router irq resources managed by the
+ TI System Controller, say Y here. Otherwise, say N.
+
 endmenu
 
 config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index c93713d24b86..b4ff376a08ef 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -94,3 +94,4 @@ obj-$(CONFIG_CSKY_APB_INTC)   += irq-csky-apb-intc.o
 obj-$(CONFIG_SIFIVE_PLIC)  += irq-sifive-plic.o
 obj-$(CONFIG_IMX_IRQSTEER) += irq-imx-irqsteer.o
 obj-$(CONFIG_MADERA_IRQ)   += irq-madera.o
+obj-$(CONFIG_TI_SCI_INTR_IRQCHIP)  += irq-ti-sci-intr.o
diff --git a/drivers/irqchip/irq-ti-sci-intr.c 
b/drivers/irqchip/irq-ti-sci-intr.c
new file mode 100644
index ..a5396e08412c
--- /dev/null
+++ b/drivers/irqchip/irq-ti-sci-intr.c
@@ -0,0 +1,310 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Texas Instruments' K3 Interrupt Router irqchip driver
+ *
+ * Copyright (C) 2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Lokesh Vutla 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TI_SCI_DEV_ID_MASK 0x
+#define TI_SCI_DEV_ID_SHIFT16
+#define TI_SCI_IRQ_ID_MASK 0x
+#define TI_SCI_IRQ_ID_SHIFT0
+#define TI_SCI_EVENT_IRQ   BIT(0)
+
+#define HWIRQ_TO_DEVID(hwirq)  (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
+(TI_SCI_DEV_ID_MASK))
+#define HWIRQ_TO_IRQID(hwirq)  ((hwirq) & (TI_SCI_IRQ_ID_MASK))
+#define FWSPEC_TO_HWIRQ(fwspec)(((fwspec->param[0] & 
TI_SCI_DEV_ID_MASK) << \
+TI_SCI_DEV_ID_SHIFT) | \
+   (fwspec->param[1] & TI_SCI_IRQ_ID_MASK))
+
+/**
+ * struct ti_sci_intr_irq_domain - Structure representing a TISCI based
+ *Interrupt Router IRQ domain.
+ * @sci:   Pointer to TISCI handle
+ * @dst_irq:   TISCI resource pointer representing destination irq controller.
+ * @dst_id:TISCI device ID of the destination irq controller.
+ */
+struct ti_sci_intr_irq_domain {
+   const struct ti_sci_handle *sci;
+   struct ti_sci_resource *dst_irq;
+   u16 dst_id;
+};
+
+static struct irq_chip ti_sci_intr_irq_chip = {
+   .name   = "INTR",
+   .irq_eoi= irq_chip_eoi_parent,
+   .irq_mask   = irq_chip_mask_parent,
+   .irq_unmask = irq_chip_unmask_parent,
+   .irq_retrigger  = irq_chip_retrigger_hierarchy,
+   .irq_set_type   = irq_chip_set_type_parent,
+   .irq_set_affinity   = irq_chip_set_affinity_parent,
+};
+
+/**
+ * ti_sci_intr_irq_domain_translate() - Retrieve hwirq and type from
+ * IRQ firmware specific handler.
+ * @domain:Pointer to IRQ domain
+ * @fwspec:Pointer to IRQ specific firmware structure
+ * @hwirq: IRQ number identified by hardware
+ * @type:  IRQ type
+ *
+ * Return 0 if all went ok else appropriate error.
+ */
+static 

[RFC PATCH v4 11/13] dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings

2018-12-26 Thread Lokesh Vutla
Add the DT binding documentation for Interrupt Aggregator driver.

Signed-off-by: Lokesh Vutla 
---
 .../interrupt-controller/ti,sci-inta.txt  | 74 +++
 MAINTAINERS   |  1 +
 2 files changed, 75 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt 
b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
new file mode 100644
index ..17b1fbd90312
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
@@ -0,0 +1,74 @@
+Texas Instruments K3 Interrupt Aggregator
+=
+
+The Interrupt Aggregator (INTA) provides a centralized machine
+which handles the termination of system events to that they can
+be coherently processed by the host(s) in the system. A maximum
+of 64 events can be mapped to a single interrupt.
+
+
+  Interrupt Aggregator
+ +-+
+ |  IntmapVINT |
+ | +--+  ++|
+m -->| | vint  | bit  |  | 0 |.|63| vint0  |
+   . | +--+  ++|   +--+
+   . | .   .   |   | HOST |
+Globalevents  -->| .   .   |-->| IRQ  |
+   . | .   .   |   | CTRL |
+   . | .   .   |   +--+
+n -->| +--+  ++|
+ | | vint  | bit  |  | 0 |.|63| vintx  |
+ | +--+  ++|
+ | |
+ +-+
+
+Configuration of these Intmap registers that maps global events to vint is done
+by a system controller (like the Device Memory and Security Controller on K3
+AM654 SoC). Driver should request the system controller to get the range
+of global events and vints assigned to the requesting host. Management
+of these requested resources should be handled by driver and requests
+system controller to map specific global event to vint, bit pair.
+
+Communication between the host processor running an OS and the system
+controller happens through a protocol called TI System Control Interface
+(TISCI protocol). For more details refer:
+Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+
+TISCI Interrupt Aggregator Node:
+---
+- compatible:  Must be "ti,sci-inta".
+- reg: Should contain registers location and length.
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Specifies the number of cells needed to encode an
+   interrupt source. The value should be 4.
+   First cell should contain the TISCI device ID of source
+   Second cell should contain the event source offset
+   within the device
+   Third cell specified the interrupt number(vint)
+   reaching Interrupt aggregator.
+   Fourth cell specifies the trigger type as defined
+   in interrupts.txt in this directory.
+- interrupt-parent:phandle of irq parent for TISCI intr.
+- ti,sci:  Phandle to TI-SCI compatible System controller node.
+- ti,sci-dev-id:   TISCI device ID of the Interrupt Aggregator.
+- ti,sci-rm-range-vint:TISCI subtype id representing the virtual 
interrupts
+   (vints) range within this IA, assigned to the
+   requesting host context.
+- ti,sci-rm-range-global-event:TISCI subtype id representing the global
+   events range reaching this IA and are assigned
+   to the requesting host context.
+
+Example:
+
+main_udmass_inta: interrupt-controller@33d0 {
+   compatible = "ti,sci-inta";
+   reg = <0x0 0x33d0 0x0 0x10>;
+   interrupt-controller;
+   interrupt-parent = <_navss_intr>;
+   #interrupt-cells = <4>;
+   ti,sci = <>;
+   ti,sci-dev-id = <179>;
+   ti,sci-rm-range-vint = <0x0>;
+   ti,sci-rm-range-global-event = <0x1>;
+};
diff --git a/MAINTAINERS b/MAINTAINERS
index 4480eb2fe851..aebce615151e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15024,6 +15024,7 @@ F:  
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
 F: drivers/clk/keystone/sci-clk.c
 F: drivers/reset/reset-ti-sci.c
 F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt

[RFC PATCH v4 13/13] soc: ti: am6: Enable interrupt controller drivers

2018-12-26 Thread Lokesh Vutla
Select all the TISCI dependent interrupt controller drivers
for AM6 SoC.

Suggested-by: Marc Zyngier 
Signed-off-by: Lokesh Vutla 
---
 drivers/soc/ti/Kconfig | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 7640490c2a6a..145b701a3d96 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -5,6 +5,11 @@ if ARCH_K3
 
 config ARCH_K3_AM6_SOC
bool "K3 AM6 SoC"
+   select MAILBOX
+   select TI_MESSAGE_MANAGER
+   select TI_SCI_PROTOCOL
+   select TI_SCI_INTR_IRQCHIP
+   select TI_SCI_INTA_IRQCHIP
help
  Enable support for TI's AM6 SoC Family support
 
-- 
2.19.2



[RFC PATCH v4 08/13] genirq/msi: Add support for allocating single MSI for a device

2018-12-26 Thread Lokesh Vutla
Previously all msi for a device are allocated in one go
by calling msi_domain_alloc_irq() from a bus layer. This might
not be the case when a device is trying to allocate interrupts
dynamically based on a request to it.

So introduce msi_domain_alloc/free_irq() apis to allocate a single
msi. prepare and activate operations to be handled by bus layer
calling msi_domain_alloc/free_irq() apis.

Signed-off-by: Lokesh Vutla 
---
 include/linux/msi.h |  3 +++
 kernel/irq/msi.c| 62 +
 2 files changed, 43 insertions(+), 22 deletions(-)

diff --git a/include/linux/msi.h b/include/linux/msi.h
index 784fb52b9900..474490826f8c 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -301,8 +301,11 @@ int msi_domain_set_affinity(struct irq_data *data, const 
struct cpumask *mask,
 struct irq_domain *msi_create_irq_domain(struct fwnode_handle *fwnode,
 struct msi_domain_info *info,
 struct irq_domain *parent);
+int msi_domain_alloc_irq(struct irq_domain *domain, struct device *dev,
+struct msi_desc *desc,  msi_alloc_info_t *arg);
 int msi_domain_alloc_irqs(struct irq_domain *domain, struct device *dev,
  int nvec);
+void msi_domain_free_irq(struct msi_desc *desc);
 void msi_domain_free_irqs(struct irq_domain *domain, struct device *dev);
 struct msi_domain_info *msi_get_domain_info(struct irq_domain *domain);
 
diff --git a/kernel/irq/msi.c b/kernel/irq/msi.c
index ad26fbcfbfc8..eb7459324113 100644
--- a/kernel/irq/msi.c
+++ b/kernel/irq/msi.c
@@ -387,6 +387,35 @@ static bool msi_check_reservation_mode(struct irq_domain 
*domain,
return desc->msi_attrib.is_msix || desc->msi_attrib.maskbit;
 }
 
+int msi_domain_alloc_irq(struct irq_domain *domain, struct device *dev,
+struct msi_desc *desc,  msi_alloc_info_t *arg)
+{
+   struct msi_domain_info *info = domain->host_data;
+   struct msi_domain_ops *ops = info->ops;
+   int i, ret, virq;
+
+   ops->set_desc(arg, desc);
+
+   virq = __irq_domain_alloc_irqs(domain, -1, desc->nvec_used,
+  dev_to_node(dev), arg, false,
+  desc->affinity);
+   if (virq < 0) {
+   ret = -ENOSPC;
+   if (ops->handle_error)
+   ret = ops->handle_error(domain, desc, ret);
+   if (ops->msi_finish)
+   ops->msi_finish(arg, ret);
+   return ret;
+   }
+
+   for (i = 0; i < desc->nvec_used; i++) {
+   irq_set_msi_desc_off(virq, i, desc);
+   irq_debugfs_copy_devname(virq + i, dev);
+   }
+
+   return 0;
+}
+
 /**
  * msi_domain_alloc_irqs - Allocate interrupts from a MSI interrupt domain
  * @domain:The domain to allocate from
@@ -404,7 +433,7 @@ int msi_domain_alloc_irqs(struct irq_domain *domain, struct 
device *dev,
struct irq_data *irq_data;
struct msi_desc *desc;
msi_alloc_info_t arg;
-   int i, ret, virq;
+   int ret, virq;
bool can_reserve;
 
ret = msi_domain_prepare_irqs(domain, dev, nvec, );
@@ -412,24 +441,9 @@ int msi_domain_alloc_irqs(struct irq_domain *domain, 
struct device *dev,
return ret;
 
for_each_msi_entry(desc, dev) {
-   ops->set_desc(, desc);
-
-   virq = __irq_domain_alloc_irqs(domain, -1, desc->nvec_used,
-  dev_to_node(dev), , false,
-  desc->affinity);
-   if (virq < 0) {
-   ret = -ENOSPC;
-   if (ops->handle_error)
-   ret = ops->handle_error(domain, desc, ret);
-   if (ops->msi_finish)
-   ops->msi_finish(, ret);
+   ret = msi_domain_alloc_irq(domain, dev, desc, );
+   if (ret)
return ret;
-   }
-
-   for (i = 0; i < desc->nvec_used; i++) {
-   irq_set_msi_desc_off(virq, i, desc);
-   irq_debugfs_copy_devname(virq + i, dev);
-   }
}
 
if (ops->msi_finish)
@@ -487,6 +501,12 @@ int msi_domain_alloc_irqs(struct irq_domain *domain, 
struct device *dev,
return ret;
 }
 
+void msi_domain_free_irq(struct msi_desc *desc)
+{
+   irq_domain_free_irqs(desc->irq, desc->nvec_used);
+   desc->irq = 0;
+}
+
 /**
  * msi_domain_free_irqs - Free interrupts from a MSI interrupt @domain 
associated tp @dev
  * @domain:The domain to managing the interrupts
@@ -503,10 +523,8 @@ void msi_domain_free_irqs(struct irq_domain *domain, 
struct device *dev)
 * enough that there is no IRQ associated to this
 * entry. If that's the case, don't do anything.
 

[PATCH v4 04/13] firmware: ti_sci: Add RM mapping table for am654

2018-12-26 Thread Lokesh Vutla
From: Peter Ujfalusi 

Add the resource mapping table for AM654 SoC as defined
in http://downloads.ti.com/tisci/esd/latest/5_soc_doc/am6x/resasg_types.html
Introduce a new compatible for AM654 "ti,am654-sci" for using
this resource map table.

Reviewed-by: Rob Herring 
Signed-off-by: Peter Ujfalusi 
Signed-off-by: Lokesh Vutla 
---
 .../bindings/arm/keystone/ti,sci.txt  |  3 ++-
 drivers/firmware/ti_sci.c | 23 +++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt 
b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
index b56a02c10ae6..6f0cd31c1520 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
@@ -24,7 +24,8 @@ relationship between the TI-SCI parent node to the child node.
 
 Required properties:
 ---
-- compatible: should be "ti,k2g-sci"
+- compatible:  should be "ti,k2g-sci" for TI 66AK2G SoC
+   should be "ti,am654-sci" for for TI AM654 SoC
 - mbox-names:
"rx" - Mailbox corresponding to receive path
"tx" - Mailbox corresponding to transmit path
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 987bfb29475c..c2f0815edab6 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2500,10 +2500,33 @@ static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
.max_msgs = 20,
.max_msg_size = 64,
+   .rm_type_map = NULL,
+};
+
+static struct ti_sci_rm_type_map ti_sci_am654_rm_type_map[] = {
+   {.dev_id = 56, .type = 0x00b}, /* GIC_IRQ */
+   {.dev_id = 179, .type = 0x000}, /* MAIN_NAV_UDMASS_IA0 */
+   {.dev_id = 187, .type = 0x009}, /* MAIN_NAV_RA */
+   {.dev_id = 188, .type = 0x006}, /* MAIN_NAV_UDMAP */
+   {.dev_id = 194, .type = 0x007}, /* MCU_NAV_UDMAP */
+   {.dev_id = 195, .type = 0x00a}, /* MCU_NAV_RA */
+   {.dev_id = 0, .type = 0x000}, /* end of table */
+};
+
+/* Description for AM654 */
+static const struct ti_sci_desc ti_sci_pmmc_am654_desc = {
+   .default_host_id = 12,
+   /* Conservative duration */
+   .max_rx_timeout_ms = 1,
+   /* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
+   .max_msgs = 20,
+   .max_msg_size = 60,
+   .rm_type_map = ti_sci_am654_rm_type_map,
 };
 
 static const struct of_device_id ti_sci_of_match[] = {
{.compatible = "ti,k2g-sci", .data = _sci_pmmc_k2g_desc},
+   {.compatible = "ti,am654-sci", .data = _sci_pmmc_am654_desc},
{ /* Sentinel */ },
 };
 MODULE_DEVICE_TABLE(of, ti_sci_of_match);
-- 
2.19.2



[PATCH v4 05/13] firmware: ti_sci: Add helper apis to manage resources

2018-12-26 Thread Lokesh Vutla
Each resource with in the device can be uniquely identified
by a type and subtype as defined by TISCI. Since this is generic
across the devices, resource allocation also can be made generic
instead of each client driver handling the resource. So add helper
apis to manage the resource.

Signed-off-by: Lokesh Vutla 
---
 drivers/firmware/ti_sci.c  | 126 +
 include/linux/soc/ti/ti_sci_protocol.h |  48 ++
 2 files changed, 174 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index c2f0815edab6..b6804c214be9 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -2480,6 +2480,132 @@ const struct ti_sci_handle 
*devm_ti_sci_get_by_phandle(struct device *dev,
 }
 EXPORT_SYMBOL_GPL(devm_ti_sci_get_by_phandle);
 
+/*
+ * ti_sci_get_free_resource() - Get a free resource from TISCI resource.
+ * @res:   Pointer to the TISCI resource
+ *
+ * Return: resource num if all went ok else TI_SCI_RESOURCE_NULL.
+ */
+u16 ti_sci_get_free_resource(struct ti_sci_resource *res)
+{
+   unsigned long flags;
+   u16 set, free_bit;
+
+   raw_spin_lock_irqsave(>lock, flags);
+   for (set = 0; set < res->sets; set++) {
+   free_bit = find_first_zero_bit(res->desc[set].res_map,
+  res->desc[set].num);
+   if (free_bit != res->desc[set].num) {
+   set_bit(free_bit, res->desc[set].res_map);
+   raw_spin_unlock_irqrestore(>lock, flags);
+   return res->desc[set].start + free_bit;
+   }
+   }
+   raw_spin_unlock_irqrestore(>lock, flags);
+
+   return TI_SCI_RESOURCE_NULL;
+}
+EXPORT_SYMBOL_GPL(ti_sci_get_free_resource);
+
+/**
+ * ti_sci_release_resource() - Release a resource from TISCI resource.
+ * @res:   Pointer to the TISCI resource
+ */
+void ti_sci_release_resource(struct ti_sci_resource *res, u16 id)
+{
+   unsigned long flags;
+   u16 set;
+
+   raw_spin_lock_irqsave(>lock, flags);
+   for (set = 0; set < res->sets; set++) {
+   if (res->desc[set].start <= id &&
+   (res->desc[set].num + res->desc[set].start) > id)
+   clear_bit(id - res->desc[set].start,
+ res->desc[set].res_map);
+   }
+   raw_spin_unlock_irqrestore(>lock, flags);
+}
+EXPORT_SYMBOL_GPL(ti_sci_release_resource);
+
+/**
+ * devm_ti_sci_get_of_resource() - Get a TISCI resource assigned to a device
+ * @handle:TISCI handle
+ * @dev:   Device pointer to which the resource is assigned
+ * @of_prop:   property name by which the resource are represented
+ *
+ * Note: This function expects of_prop to be in the form of tuples
+ * . Allocates and initializes ti_sci_resource structure
+ * for each of_prop. Client driver can directly call
+ * ti_sci_(get_free, release)_resource apis for handling the resource.
+ *
+ * Return: Pointer to ti_sci_resource if all went well else appropriate
+ *error pointer.
+ */
+struct ti_sci_resource *
+devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
+   struct device *dev, u32 dev_id, char *of_prop)
+{
+   struct ti_sci_resource *res;
+   u32 resource_subtype;
+   u16 resource_type;
+   int i, ret;
+
+   res = devm_kzalloc(dev, sizeof(*res), GFP_KERNEL);
+   if (!res)
+   return ERR_PTR(-ENOMEM);
+
+   res->sets = of_property_count_elems_of_size(dev_of_node(dev), of_prop,
+   sizeof(u32));
+   if (res->sets < 0) {
+   dev_err(dev, "%s resource type ids not available\n", of_prop);
+   return ERR_PTR(res->sets);
+   }
+
+   res->desc = devm_kcalloc(dev, res->sets, sizeof(*res->desc),
+GFP_KERNEL);
+   if (!res->desc)
+   return ERR_PTR(-ENOMEM);
+
+   ret = ti_sci_get_resource_type(handle_to_ti_sci_info(handle), dev_id,
+  _type);
+   if (ret) {
+   dev_err(dev, "No valid resource type for %u\n", dev_id);
+   return ERR_PTR(-EINVAL);
+   }
+
+   for (i = 0; i < res->sets; i++) {
+   ret = of_property_read_u32_index(dev_of_node(dev), of_prop, i,
+_subtype);
+   if (ret)
+   return ERR_PTR(-EINVAL);
+
+   ret = handle->ops.rm_core_ops.get_range(handle, dev_id,
+   resource_subtype,
+   >desc[i].start,
+   >desc[i].num);
+   if (ret) {
+   dev_err(dev, "type %d subtype %d not allocated for host 
%d\n",
+   resource_type, resource_subtype,
+

[PATCH v4 02/13] firmware: ti_sci: Add support for RM core ops

2018-12-26 Thread Lokesh Vutla
TISCI provides support for getting the resources(IRQ, RING etc..)
assigned to a specific device. These resources can be handled by
the client and in turn sends TISCI cmd to configure the resources.

It is very important that client should keep track on usage of these
resources.

Add support for TISCI commands to get resource ranges.

Signed-off-by: Lokesh Vutla 
Signed-off-by: Peter Ujfalusi 
---
 drivers/firmware/ti_sci.c  | 170 +
 drivers/firmware/ti_sci.h  |  42 ++
 include/linux/soc/ti/ti_sci_protocol.h |  27 
 3 files changed, 239 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index f0cafa8a2ee9..a2a099b8f62a 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -64,6 +64,22 @@ struct ti_sci_xfers_info {
spinlock_t xfer_lock;
 };
 
+/**
+ * struct ti_sci_rm_type_map - Structure representing TISCI Resource
+ * management representation of dev_ids.
+ * @dev_id:TISCI device ID
+ * @type:  Corresponding id as identified by TISCI RM.
+ *
+ * Note: This is used only as a work around for using RM range apis
+ * for AM654 SoC. For future SoCs dev_id will be used as type
+ * for RM range APIs. In order to maintain ABI backward compatibility
+ * type is not being changed for AM654 SoC.
+ */
+struct ti_sci_rm_type_map {
+   u32 dev_id;
+   u16 type;
+};
+
 /**
  * struct ti_sci_desc - Description of SoC integration
  * @default_host_id:   Host identifier representing the compute entity
@@ -71,12 +87,14 @@ struct ti_sci_xfers_info {
  * @max_msgs: Maximum number of messages that can be pending
  *   simultaneously in the system
  * @max_msg_size: Maximum size of data per message that can be handled.
+ * @rm_type_map: RM resource type mapping structure.
  */
 struct ti_sci_desc {
u8 default_host_id;
int max_rx_timeout_ms;
int max_msgs;
int max_msg_size;
+   struct ti_sci_rm_type_map *rm_type_map;
 };
 
 /**
@@ -1617,6 +1635,153 @@ static int ti_sci_cmd_core_reboot(const struct 
ti_sci_handle *handle)
return ret;
 }
 
+static int ti_sci_get_resource_type(struct ti_sci_info *info, u16 dev_id,
+   u16 *type)
+{
+   struct ti_sci_rm_type_map *rm_type_map = info->desc->rm_type_map;
+   bool found = false;
+   int i;
+
+   /* If map is not provided then assume dev_id is used as type */
+   if (!rm_type_map) {
+   *type = dev_id;
+   return 0;
+   }
+
+   for (i = 0; rm_type_map[i].dev_id; i++) {
+   if (rm_type_map[i].dev_id == dev_id) {
+   *type = rm_type_map[i].type;
+   found = true;
+   break;
+   }
+   }
+
+   if (!found)
+   return -EINVAL;
+
+   return 0;
+}
+
+/**
+ * ti_sci_get_resource_range - Helper to get a range of resources assigned
+ *to a host. Resource is uniquely identified by
+ *type and subtype.
+ * @handle:Pointer to TISCI handle.
+ * @dev_id:TISCI device ID.
+ * @subtype:   Resource assignment subtype that is being requested
+ * from the given device.
+ * @s_host:Host processor ID to which the resources are allocated
+ * @range_start:   Start index of the resource range
+ * @range_num: Number of resources in the range
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_get_resource_range(const struct ti_sci_handle *handle,
+u32 dev_id, u8 subtype, u8 s_host,
+u16 *range_start, u16 *range_num)
+{
+   struct ti_sci_msg_resp_get_resource_range *resp;
+   struct ti_sci_msg_req_get_resource_range *req;
+   struct ti_sci_xfer *xfer;
+   struct ti_sci_info *info;
+   struct device *dev;
+   u16 type;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+   dev = info->dev;
+
+   xfer = ti_sci_get_one_xfer(info, TI_SCI_MSG_GET_RESOURCE_RANGE,
+  TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+  sizeof(*req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+
+   ret = ti_sci_get_resource_type(info, dev_id, );
+   if (ret) {
+   dev_err(dev, "rm type lookup failed for %u\n", dev_id);
+   goto fail;
+   }
+
+   req = (struct ti_sci_msg_req_get_resource_range *)xfer->xfer_buf;
+   req->secondary_host = s_host;
+   req->type = type & 

[PATCH v4 01/13] firmware: ti_sci: Add support to get TISCI handle using of_phandle

2018-12-26 Thread Lokesh Vutla
From: Grygorii Strashko 

TISCI has been updated to have support for Resource management(likes
interrupts etc..). And there can be multiple device instances of a
resource type in a SoC. So every driver corresponding to a resource type
should get a TISCI handle so that it can make TISCI calls. And each
DT node corresponding to a device should exist under its corresponding
bus node as per the SoC architecture.

But existing apis in TISCI library assumes that all TISCI users are
child nodes of TISCI. Which is not true in the above case. So introduce
(devm_)ti_sci_get_by_phandle() apis that can be used by TISCI users
to get TISCI handle using of phandle property.

Signed-off-by: Grygorii Strashko 
Signed-off-by: Lokesh Vutla 
---
 drivers/firmware/ti_sci.c  | 83 ++
 include/linux/soc/ti/ti_sci_protocol.h | 17 ++
 2 files changed, 100 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 69ed1464175c..f0cafa8a2ee9 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1781,6 +1781,89 @@ const struct ti_sci_handle 
*devm_ti_sci_get_handle(struct device *dev)
 }
 EXPORT_SYMBOL_GPL(devm_ti_sci_get_handle);
 
+/**
+ * ti_sci_get_by_phandle() - Get the TI SCI handle using DT phandle
+ * @np:device node
+ * @propname:  property name containing phandle on TISCI node
+ *
+ * NOTE: The function does not track individual clients of the framework
+ * and is expected to be maintained by caller of TI SCI protocol library.
+ * ti_sci_put_handle must be balanced with successful ti_sci_get_by_phandle
+ * Return: pointer to handle if successful, else:
+ * -EPROBE_DEFER if the instance is not ready
+ * -ENODEV if the required node handler is missing
+ * -EINVAL if invalid conditions are encountered.
+ */
+const struct ti_sci_handle *ti_sci_get_by_phandle(struct device_node *np,
+ const char *property)
+{
+   struct ti_sci_handle *handle = NULL;
+   struct device_node *ti_sci_np;
+   struct ti_sci_info *info;
+   struct list_head *p;
+
+   if (!np) {
+   pr_err("I need a device pointer\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   ti_sci_np = of_parse_phandle(np, property, 0);
+   if (!ti_sci_np)
+   return ERR_PTR(-ENODEV);
+
+   mutex_lock(_sci_list_mutex);
+   list_for_each(p, _sci_list) {
+   info = list_entry(p, struct ti_sci_info, node);
+   if (ti_sci_np == info->dev->of_node) {
+   handle = >handle;
+   info->users++;
+   break;
+   }
+   }
+   mutex_unlock(_sci_list_mutex);
+   of_node_put(ti_sci_np);
+
+   if (!handle)
+   return ERR_PTR(-EPROBE_DEFER);
+
+   return handle;
+}
+EXPORT_SYMBOL_GPL(ti_sci_get_by_phandle);
+
+/**
+ * devm_ti_sci_get_by_phandle() - Managed get handle using phandle
+ * @dev:   Device pointer requesting TISCI handle
+ * @propname:  property name containing phandle on TISCI node
+ *
+ * NOTE: This releases the handle once the device resources are
+ * no longer needed. MUST NOT BE released with ti_sci_put_handle.
+ * The function does not track individual clients of the framework
+ * and is expected to be maintained by caller of TI SCI protocol library.
+ *
+ * Return: 0 if all went fine, else corresponding error.
+ */
+const struct ti_sci_handle *devm_ti_sci_get_by_phandle(struct device *dev,
+  const char *property)
+{
+   const struct ti_sci_handle *handle;
+   const struct ti_sci_handle **ptr;
+
+   ptr = devres_alloc(devm_ti_sci_release, sizeof(*ptr), GFP_KERNEL);
+   if (!ptr)
+   return ERR_PTR(-ENOMEM);
+   handle = ti_sci_get_by_phandle(dev_of_node(dev), property);
+
+   if (!IS_ERR(handle)) {
+   *ptr = handle;
+   devres_add(dev, ptr);
+   } else {
+   devres_free(ptr);
+   }
+
+   return handle;
+}
+EXPORT_SYMBOL_GPL(devm_ti_sci_get_by_phandle);
+
 static int tisci_reboot_handler(struct notifier_block *nb, unsigned long mode,
void *cmd)
 {
diff --git a/include/linux/soc/ti/ti_sci_protocol.h 
b/include/linux/soc/ti/ti_sci_protocol.h
index 18435e5c6364..515587e9d373 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -217,6 +217,10 @@ struct ti_sci_handle {
 const struct ti_sci_handle *ti_sci_get_handle(struct device *dev);
 int ti_sci_put_handle(const struct ti_sci_handle *handle);
 const struct ti_sci_handle *devm_ti_sci_get_handle(struct device *dev);
+const struct ti_sci_handle *ti_sci_get_by_phandle(struct device_node *np,
+ const char *property);
+const struct ti_sci_handle *devm_ti_sci_get_by_phandle(struct device *dev,
+

[PATCH v4 03/13] firmware: ti_sci: Add support for IRQ management

2018-12-26 Thread Lokesh Vutla
TISCI abstracts the handling of IRQ routes where interrupt sources
are not directly connected to interrupt controller. Add support for
the set of TISCI commands for requesting and releasing IRQs.

Signed-off-by: Lokesh Vutla 
---
 drivers/firmware/ti_sci.c  | 446 +
 drivers/firmware/ti_sci.h  |  60 
 include/linux/soc/ti/ti_sci_protocol.h |  77 +
 3 files changed, 583 insertions(+)

diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index a2a099b8f62a..987bfb29475c 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -1782,6 +1782,439 @@ int ti_sci_cmd_get_resource_range_from_shost(const 
struct ti_sci_handle *handle,
 range_start, range_num);
 }
 
+/**
+ * ti_sci_manage_irq() - Helper api to configure/release the irq route between
+ *  the requested source and destination
+ * @handle:Pointer to TISCI handle.
+ * @valid_params:  Bit fields defining the validity of certain params
+ * @src_id:Device ID of the IRQ source
+ * @src_index: IRQ source index within the source device
+ * @dst_id:Device ID of the IRQ destination
+ * @dt_host_irq:   IRQ number of the destination device
+ * @ia_id: Device ID of the IA, if the IRQ flows through this IA
+ * @vint:  Virtual interrupt to be used within the IA
+ * @global_event:  Global event number to be used for the requesting event
+ * @vint_status_bit:   Virtual interrupt status bit to be used for the event
+ * @s_host:Secondary host ID to which the irq/event is being
+ * requested for.
+ * @type:  Request type irq set or release.
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_manage_irq(const struct ti_sci_handle *handle,
+u32 valid_params, u16 src_id, u16 src_index,
+u16 dst_id, u16 dst_host_irq, u16 ia_id, u16 vint,
+u16 global_event, u8 vint_status_bit, u8 s_host,
+u16 type)
+{
+   struct ti_sci_msg_req_manage_irq *req;
+   struct ti_sci_msg_hdr *resp;
+   struct ti_sci_xfer *xfer;
+   struct ti_sci_info *info;
+   struct device *dev;
+   int ret = 0;
+
+   if (IS_ERR(handle))
+   return PTR_ERR(handle);
+   if (!handle)
+   return -EINVAL;
+
+   info = handle_to_ti_sci_info(handle);
+   dev = info->dev;
+
+   xfer = ti_sci_get_one_xfer(info, type, TI_SCI_FLAG_REQ_ACK_ON_PROCESSED,
+  sizeof(*req), sizeof(*resp));
+   if (IS_ERR(xfer)) {
+   ret = PTR_ERR(xfer);
+   dev_err(dev, "Message alloc failed(%d)\n", ret);
+   return ret;
+   }
+   req = (struct ti_sci_msg_req_manage_irq *)xfer->xfer_buf;
+   req->valid_params = valid_params;
+   req->src_id = src_id;
+   req->src_index = src_index;
+   req->dst_id = dst_id;
+   req->dst_host_irq = dst_host_irq;
+   req->ia_id = ia_id;
+   req->vint = vint;
+   req->global_event = global_event;
+   req->vint_status_bit = vint_status_bit;
+   req->secondary_host = s_host;
+
+   ret = ti_sci_do_xfer(info, xfer);
+   if (ret) {
+   dev_err(dev, "Mbox send fail %d\n", ret);
+   goto fail;
+   }
+
+   resp = (struct ti_sci_msg_hdr *)xfer->xfer_buf;
+
+   ret = ti_sci_is_response_ack(resp) ? 0 : -ENODEV;
+
+fail:
+   ti_sci_put_one_xfer(>minfo, xfer);
+
+   return ret;
+}
+
+/**
+ * ti_sci_set_irq() - Helper api to configure the irq route between the
+ *   requested source and destination
+ * @handle:Pointer to TISCI handle.
+ * @valid_params:  Bit fields defining the validity of certain params
+ * @src_id:Device ID of the IRQ source
+ * @src_index: IRQ source index within the source device
+ * @dst_id:Device ID of the IRQ destination
+ * @dt_host_irq:   IRQ number of the destination device
+ * @ia_id: Device ID of the IA, if the IRQ flows through this IA
+ * @vint:  Virtual interrupt to be used within the IA
+ * @global_event:  Global event number to be used for the requesting event
+ * @vint_status_bit:   Virtual interrupt status bit to be used for the event
+ * @s_host:Secondary host ID to which the irq/event is being
+ * requested for.
+ *
+ * Return: 0 if all went fine, else return appropriate error.
+ */
+static int ti_sci_set_irq(const struct ti_sci_handle *handle, u32 valid_params,
+ u16 src_id, u16 src_index, u16 dst_id,
+ u16 dst_host_irq, u16 ia_id, u16 vint,
+ u16 global_event, u8 vint_status_bit, u8 s_host)
+{
+   pr_debug("%s: IRQ set with valid_params = 

[PATCH v4 00/13] Add support for TISCI irqchip drivers

2018-12-26 Thread Lokesh Vutla
TI AM65x SoC based on K3 architecture, introduced support for Events
which are message based interrupts with minimal latency. These events
are not compatible with regular interrupts and are valid only through
an event transport lane. An Interrupt Aggregator(INTA) is introduced
to convert these events to interrupts. INTA can also group 64 events
into a single interrupt. Now the SoC has many peripherals and a large
number of event sources (time sync or DMA), the use of events is
completely dependent on a user's specific application, which drives a
need for maximum flexibility in which event sources are used in the
system. It is also completely up to software control as to how the
events are serviced.

Because of the huge flexibility there are certain standard peripherals
(like GPIO etc)where all interrupts cannot be directly corrected to host
interrupt controller. For this purpose, Interrupt Router(INTR) is
introduced in the SoC. INTR just does a classic interrupt redirection.

So the SoC has 3 types of interrupt controllers:
- GIC500
- Interrupt Router
- Interrupt Aggregator

Below is a diagrammatic view of how SoC integration of these interrupt
controllers:(https://pastebin.ubuntu.com/p/9ngV3jdGj2/)

Device Index-x   Device Index-y
   | |
   | |
  
\   /
 \ /
  \  (global events)  /
  +---+   +-+
  |   |   | |
  | INTA  |   |  GPIO   |
  |   |   | |
  +---+   +-+
 |   (vint)|
 | |
\|/|
  +---+|
  |   |<---+
  |   INTR|
  |   |
  +---+
 |
 |
\|/ (gic irq)
  +---+
  |   |
  | GIC   |
  |   |
  +---+

While at it, TISCI abstracts the handling of all above IRQ routes where
interrupt sources are not directly connected to host interrupt controller.
That would be configuration of Interrupt Aggregator and Interrupt Router.

This series adds support for:
- TISCI commands needed for IRQ configuration
- Interrupt Router(INTR) and Interrupt Aggregator(INTA) drivers

Changes since v3:
- Fix documentation for Interrupt Router driver
- Rebased on top of latest next.
- Fully tested with DMA(using out of tree patches)
- Fixed a build error with allmodconfig

Grygorii Strashko (1):
  firmware: ti_sci: Add support to get TISCI handle using of_phandle

Lokesh Vutla (11):
  firmware: ti_sci: Add support for RM core ops
  firmware: ti_sci: Add support for IRQ management
  firmware: ti_sci: Add helper apis to manage resources
  dt-bindings: irqchip: Introduce TISCI Interrupt router bindings
  irqchip: ti-sci-intr: Add support for Interrupt Router driver
  genirq/msi: Add support for allocating single MSI for a device
  genirq/msi: Add support for .msi_unprepare callback
  soc: ti: Add MSI domain support for K3 Interrupt Aggregator
  dt-bindings: irqchip: Introduce TISCI Interrupt Aggregator bindings
  irqchip: ti-sci-inta: Add support for Interrupt Aggregator driver
  soc: ti: am6: Enable interrupt controller drivers

Peter Ujfalusi (1):
  firmware: ti_sci: Add RM mapping table for am654

 .../bindings/arm/keystone/ti,sci.txt  |   3 +-
 .../interrupt-controller/ti,sci-inta.txt  |  74 ++
 .../interrupt-controller/ti,sci-intr.txt  |  85 ++
 MAINTAINERS   |   4 +
 drivers/firmware/ti_sci.c | 848 ++
 drivers/firmware/ti_sci.h | 102 +++
 drivers/irqchip/Kconfig   |  23 +
 drivers/irqchip/Makefile  |   2 +
 drivers/irqchip/irq-ti-sci-inta.c | 561 
 drivers/irqchip/irq-ti-sci-intr.c | 310 +++
 drivers/soc/ti/Kconfig|  11 +
 drivers/soc/ti/Makefile   |   1 +
 drivers/soc/ti/k3_inta_msi.c  | 193 
 include/linux/irqdomain.h |   1 +
 include/linux/msi.h   |  12 +
 include/linux/soc/ti/k3_inta_msi.h|  22 +
 include/linux/soc/ti/ti_sci_protocol.h| 169 
 kernel/irq/msi.c  |  72 +-
 18 files changed, 2470 insertions(+), 23 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
 create mode 

[PATCH] arm/mm/pmsa-v8 : remove unneeded semicolon

2018-12-26 Thread Peng Hao
Remove unneeded semicolon.

Signed-off-by: Peng Hao 
---
 arch/arm/mm/pmsa-v8.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mm/pmsa-v8.c b/arch/arm/mm/pmsa-v8.c
index 617a83d..0d7d5fb 100644
--- a/arch/arm/mm/pmsa-v8.c
+++ b/arch/arm/mm/pmsa-v8.c
@@ -165,7 +165,7 @@ static int __init pmsav8_setup_ram(unsigned int number, 
phys_addr_t start,phys_a
return -EINVAL;
 
bar = start;
-   lar = (end - 1) & ~(PMSAv8_MINALIGN - 1);;
+   lar = (end - 1) & ~(PMSAv8_MINALIGN - 1);
 
bar |= PMSAv8_AP_PL1RW_PL0RW | PMSAv8_RGN_SHARED;
lar |= PMSAv8_LAR_IDX(PMSAv8_RGN_NORMAL) | PMSAv8_LAR_EN;
@@ -181,7 +181,7 @@ static int __init pmsav8_setup_io(unsigned int number, 
phys_addr_t start,phys_ad
return -EINVAL;
 
bar = start;
-   lar = (end - 1) & ~(PMSAv8_MINALIGN - 1);;
+   lar = (end - 1) & ~(PMSAv8_MINALIGN - 1);
 
bar |= PMSAv8_AP_PL1RW_PL0RW | PMSAv8_RGN_SHARED | PMSAv8_BAR_XN;
lar |= PMSAv8_LAR_IDX(PMSAv8_RGN_DEVICE_nGnRnE) | PMSAv8_LAR_EN;
-- 
1.8.3.1



[PATCH] arm/mach-iop13xx: remove duplicated argument in define

2018-12-26 Thread Peng Hao
Remove duplicated PCI_STATUS_REC_TARGET_ABORT.

Signed-off-by: Peng Hao 
---
 arch/arm/mach-iop13xx/pci.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm/mach-iop13xx/pci.h b/arch/arm/mach-iop13xx/pci.h
index 736168d..c6a0678 100644
--- a/arch/arm/mach-iop13xx/pci.h
+++ b/arch/arm/mach-iop13xx/pci.h
@@ -23,7 +23,6 @@
 #define IOP_PCI_STATUS_ERROR (PCI_STATUS_PARITY |   \
   PCI_STATUS_SIG_TARGET_ABORT | \
   PCI_STATUS_REC_TARGET_ABORT | \
-  PCI_STATUS_REC_TARGET_ABORT | \
   PCI_STATUS_REC_MASTER_ABORT | \
   PCI_STATUS_SIG_SYSTEM_ERROR | \
   PCI_STATUS_DETECTED_PARITY)
-- 
1.8.3.1



Re: [PATCH v1 3/8] kvm:vmx Enable loading CET state bit while guest CR4.CET is being set.

2018-12-26 Thread Yang,Weijiang
On Wed, Dec 26, 2018 at 04:52:38PM +0800, Liran Alon wrote:

Thanks Liran for pointing out the issues!
I'll fix them in next version.
> 
> 
> > On 26 Dec 2018, at 10:15, Yang Weijiang  wrote:
> > 
> > This bit controls whether guest CET states will be loaded on guest entry.
> > 
> > Signed-off-by: Zhang Yi Z 
> > Signed-off-by: Yang Weijiang 
> > ---
> > arch/x86/kvm/vmx.c | 19 +++
> > 1 file changed, 19 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index 7bbb8b26e901..25fa6bd2fb95 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -1045,6 +1045,8 @@ struct vcpu_vmx {
> > 
> > bool req_immediate_exit;
> > 
> > +   bool vcpu_cet_on;
> > +
> > /* Support for PML */
> > #define PML_ENTITY_NUM  512
> > struct page *pml_pg;
> > @@ -5409,6 +5411,23 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, 
> > unsigned long cr4)
> > return 1;
> > }
> > 
> > +   /*
> > +* When CET.CR4 is being set, it means we're enabling CET for
> 
> You probably meant to write here CR4.CET.
> 
> > +* the guest, then enable loading CET state bit in entry control.
> > +* Otherwise, clear loading CET bit to disable guest CET.
> > +*/
> > +   if (cr4 & X86_CR4_CET) {
> > +   if (!to_vmx(vcpu)->vcpu_cet_on) {
> > +   vmcs_set_bits(VM_ENTRY_CONTROLS,
> > + VM_ENTRY_LOAD_GUEST_CET_STATE);
> > +   to_vmx(vcpu)->vcpu_cet_on = 1;
> > +   }
> > +   } else if (to_vmx(vcpu)->vcpu_cet_on) {
> > +   vmcs_clear_bits(VM_ENTRY_CONTROLS,
> > +   VM_ENTRY_LOAD_GUEST_CET_STATE);
> > +   to_vmx(vcpu)->vcpu_cet_on = 0;
> > +   }
> > +
> > if (to_vmx(vcpu)->nested.vmxon && !nested_cr4_valid(vcpu, cr4))
> > return 1;
> > 
> > -- 
> > 2.17.1
> > 
> 
> I haven’t seen a patch in the series that modifies kvm_set_cr4() to verify 
> CR4.CET is not set when CET is not reported as supported by CPUID.
> I think that is missing from the series.
> 
> -Liran
> 
> 


[PATCH] kvm/eventfd : unnecessory conversion to bool

2018-12-26 Thread Peng Hao
Conversion to bool is not needed in ioeventfd_in_range.

Signed-off-by: Peng Hao 
---
 virt/kvm/eventfd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c
index b20b751..d4cdc9c 100644
--- a/virt/kvm/eventfd.c
+++ b/virt/kvm/eventfd.c
@@ -723,7 +723,7 @@ struct _ioeventfd {
return false;
}
 
-   return _val == p->datamatch ? true : false;
+   return _val == p->datamatch;
 }
 
 /* MMIO/PIO writes trigger an event if the addr/val match */
-- 
1.8.3.1



Re: [PATCH 04/10] pseries: ibmebus.c: convert to use BUS_ATTR_WO

2018-12-26 Thread Michael Ellerman
Greg Kroah-Hartman  writes:
> We are trying to get rid of BUS_ATTR() and the usage of that in
> ibmebus.c can be trivially converted to use BUS_ATTR_WO(), so use that
> instead.
>
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Tyrel Datwyler 
> Signed-off-by: Greg Kroah-Hartman 
> ---
>  arch/powerpc/platforms/pseries/ibmebus.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)

LGTM.

Acked-by: Michael Ellerman  (powerpc)

cheers

> diff --git a/arch/powerpc/platforms/pseries/ibmebus.c 
> b/arch/powerpc/platforms/pseries/ibmebus.c
> index 5b4a56131904..84e8ec4011ba 100644
> --- a/arch/powerpc/platforms/pseries/ibmebus.c
> +++ b/arch/powerpc/platforms/pseries/ibmebus.c
> @@ -261,8 +261,7 @@ static char *ibmebus_chomp(const char *in, size_t count)
>   return out;
>  }
>  
> -static ssize_t ibmebus_store_probe(struct bus_type *bus,
> -const char *buf, size_t count)
> +static ssize_t probe_store(struct bus_type *bus, const char *buf, size_t 
> count)
>  {
>   struct device_node *dn = NULL;
>   struct device *dev;
> @@ -298,10 +297,9 @@ static ssize_t ibmebus_store_probe(struct bus_type *bus,
>   return rc;
>   return count;
>  }
> -static BUS_ATTR(probe, 0200, NULL, ibmebus_store_probe);
> +static BUS_ATTR_WO(probe);
>  
> -static ssize_t ibmebus_store_remove(struct bus_type *bus,
> - const char *buf, size_t count)
> +static ssize_t remove_store(struct bus_type *bus, const char *buf, size_t 
> count)
>  {
>   struct device *dev;
>   char *path;
> @@ -325,7 +323,7 @@ static ssize_t ibmebus_store_remove(struct bus_type *bus,
>   return -ENODEV;
>   }
>  }
> -static BUS_ATTR(remove, 0200, NULL, ibmebus_store_remove);
> +static BUS_ATTR_WO(remove);
>  
>  static struct attribute *ibmbus_bus_attrs[] = {
>   _attr_probe.attr,
> -- 
> 2.20.1


Re: [PATCH v3 3/6] irqchip: sifive-plic: More flexible plic_irq_toggle()

2018-12-26 Thread Anup Patel
On Wed, Dec 19, 2018 at 9:58 PM Christoph Hellwig  wrote:
>
> On Tue, Dec 18, 2018 at 02:20:10PM +0530, Anup Patel wrote:
> > Actually these functions should not be inline because plic_toggle() uses
> > raw_spin_lock() and plic_irq_toggle() uses for-loop.
>
> So?  It still inlines the all of two instances into each caller
> for slightly different but related work.  Not sure it is 100% worth
> it, but probably more than the one to move the calculations to init
> time..

Not just at init time but these functions will also be used when
irq_affinity is changed by IRQ balancer at runtime.

Regards,
Anup


Re: [for-next][PATCH 09/24] seq_buf: Make seq_buf_puts() null-terminate the buffer

2018-12-26 Thread Michael Ellerman
Steven Rostedt  writes:

> On Fri, 21 Dec 2018 13:00:21 -0500
> Steven Rostedt  wrote:
>
>
>> > Can result in:
>> > 
>> >   Message is fooªªªªªsecret  
>> 
>> Sending this via quilt, and that we have non UTF8 characters causes
>> LKML to blow up.
>> 
>> There's a couple more patches with this issue. I'm going to fix up the
>> change logs and rebase them.
>
> Actually, this change log should have them. Bah, I'll just ignore it.
> The repo that gets pulled is fine.

Thanks, sorry for the bother. It doesn't really matter in this case
what's displayed, it's just an example.

cheers


Re: [RFC][PATCH v2 01/21] e820: cheat PMEM as DRAM

2018-12-26 Thread Dan Williams
On Wed, Dec 26, 2018 at 8:11 PM Fengguang Wu  wrote:
>
> On Wed, Dec 26, 2018 at 07:41:41PM -0800, Matthew Wilcox wrote:
> >On Wed, Dec 26, 2018 at 09:14:47PM +0800, Fengguang Wu wrote:
> >> From: Fan Du 
> >>
> >> This is a hack to enumerate PMEM as NUMA nodes.
> >> It's necessary for current BIOS that don't yet fill ACPI HMAT table.
> >>
> >> WARNING: take care to backup. It is mutual exclusive with libnvdimm
> >> subsystem and can destroy ndctl managed namespaces.
> >
> >Why depend on firmware to present this "correctly"?  It seems to me like
> >less effort all around to have ndctl label some namespaces as being for
> >this kind of use.
>
> Dave Hansen may be more suitable to answer your question. He posted
> patches to make PMEM NUMA node coexist with libnvdimm and ndctl:
>
> [PATCH 0/9] Allow persistent memory to be used like normal RAM
> https://lkml.org/lkml/2018/10/23/9
>
> That depends on future BIOS. So we did this quick hack to test out
> PMEM NUMA node for the existing BIOS.

No, it does not depend on a future BIOS.

Willy, have a look here [1], here [2], and here [3] for the
work-in-progress ndctl takeover approach (actually 'daxctl' in this
case).

[1]: https://lkml.org/lkml/2018/10/23/9
[2]: https://lkml.org/lkml/2018/10/31/243
[3]: https://lists.01.org/pipermail/linux-nvdimm/2018-November/018677.html


[PATCH] x86/kexec: fix a kexec_file_load failure

2018-12-26 Thread Dave Young
The code cleanup mentioned in Fixes tag changed the behavior of
kexec_locate_mem_hole.  The kexec_locate_mem_hole will try to
allocate free memory only when kbuf.mem is initialized as zero.

But in x86 kexec_file_load implementation there are a few places
the kbuf.mem is reused like below:
  /* kbuf initialized, kbuf.mem = 0 */
  ...
  kexec_add_buffer()
  ...
  kexec_add_buffer()

  The second kexec_add_buffer will reuse previous kbuf but not
  reinitialize the kbuf.mem.

Thus kexec_file_load failed because the sanity check failed.

So explictily reset mem = 0 to fix the issue.

Fixes: b6664ba42f14 ("s390, kexec_file: drop arch_kexec_mem_walk()")
Signed-off-by: Dave Young 
Cc: 
---
 arch/x86/kernel/crash.c   | 1 +
 arch/x86/kernel/kexec-bzimage64.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index f631a3f15587..37147509d2c8 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -469,6 +469,7 @@ int crash_load_segments(struct kimage *image)
 
kbuf.memsz = kbuf.bufsz;
kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
+   kbuf.mem = 0;
ret = kexec_add_buffer();
if (ret) {
vfree((void *)image->arch.elf_headers);
diff --git a/arch/x86/kernel/kexec-bzimage64.c 
b/arch/x86/kernel/kexec-bzimage64.c
index 278cd07228dd..558204bdf412 100644
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -434,6 +434,7 @@ static void *bzImage64_load(struct kimage *image, char 
*kernel,
kbuf.memsz = PAGE_ALIGN(header->init_size);
kbuf.buf_align = header->kernel_alignment;
kbuf.buf_min = MIN_KERNEL_LOAD_ADDR;
+   kbuf.mem = 0;
ret = kexec_add_buffer();
if (ret)
goto out_free_params;
@@ -448,6 +449,7 @@ static void *bzImage64_load(struct kimage *image, char 
*kernel,
kbuf.bufsz = kbuf.memsz = initrd_len;
kbuf.buf_align = PAGE_SIZE;
kbuf.buf_min = MIN_INITRD_LOAD_ADDR;
+   kbuf.mem = 0;
ret = kexec_add_buffer();
if (ret)
goto out_free_params;
-- 
2.17.0



Re: [PATCH 14/18] drm/mediatek: add connect function for ovl

2018-12-26 Thread CK Hu
Hi, Yongqiang:

On Mon, 2018-12-24 at 16:08 +0800, Yongqiang Niu wrote:
> This patch add connect function for ovl

Could you describe more about how ovl-2l works? I guess that ovl-2l is a
ovl hardware which has 3 layer, the bottom two layer is from DRAM and
the top layer is from another hardware (maybe the ovl). If my guess is
correct, why not just implement this function in mtk_ovl_layer_on()? In
mtk_ovl_layer_on(), you could do as

if (idx == ovl->data->layer_nr) {
mtk_ddp_write_mask((1 << 2), comp,
DISP_REG_OVL_DATAPATH_CON, OVL_BGCLR_SEL_IN);

return;
}

So does mtk_ovl_layer_off().

Regards,
CK

> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index a0ab760..3b2ce77 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -27,6 +27,8 @@
>  #define DISP_REG_OVL_EN  0x000c
>  #define DISP_REG_OVL_RST 0x0014
>  #define DISP_REG_OVL_ROI_SIZE0x0020
> +#define DISP_REG_OVL_DATAPATH_CON0x0024
> +#define OVL_BGCLR_SEL_INBIT(2)
>  #define DISP_REG_OVL_ROI_BGCLR   0x0028
>  #define DISP_REG_OVL_SRC_CON 0x002c
>  #define DISP_REG_OVL_CON(n)  (0x0030 + 0x20 * (n))
> @@ -245,6 +247,19 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp 
> *comp, unsigned int idx,
>   mtk_ovl_layer_on(comp, idx);
>  }
>  
> +static void mtk_ovl_connect(struct mtk_ddp_comp *comp,
> + enum mtk_ddp_comp_id prev)
> +{
> + int is_ovl = 0;
> +
> + if (prev == DDP_COMPONENT_OVL0 || prev == DDP_COMPONENT_OVL1 ||
> + prev == DDP_COMPONENT_OVL0_2L || prev == DDP_COMPONENT_OVL1_2L)
> + is_ovl = 1;
> +
> + mtk_ddp_write_mask((is_ovl << 2), comp,
> +DISP_REG_OVL_DATAPATH_CON, OVL_BGCLR_SEL_IN);
> +}
> +
>  static const struct mtk_ddp_comp_funcs mtk_disp_ovl_funcs = {
>   .config = mtk_ovl_config,
>   .start = mtk_ovl_start,
> @@ -255,6 +270,7 @@ static void mtk_ovl_layer_config(struct mtk_ddp_comp 
> *comp, unsigned int idx,
>   .layer_on = mtk_ovl_layer_on,
>   .layer_off = mtk_ovl_layer_off,
>   .layer_config = mtk_ovl_layer_config,
> + .connect = mtk_ovl_connect,
>  };
>  
>  static int mtk_disp_ovl_bind(struct device *dev, struct device *master,




Re: PROPOSAL: Extend inline asm syntax with size spec

2018-12-26 Thread Masahiro Yamada
Hi Peter,


On Wed, Oct 31, 2018 at 9:58 PM Peter Zijlstra  wrote:
>
> On Sat, Oct 13, 2018 at 09:33:35PM +0200, Borislav Petkov wrote:
> > Ok,
> >
> > with Segher's help I've been playing with his patch ontop of bleeding
> > edge gcc 9 and here are my observations. Please double-check me for
> > booboos so that they can be addressed while there's time.
> >
> > So here's what I see ontop of 4.19-rc7:
> >
> > First marked the alternative asm() as inline and undeffed the "inline"
> > keyword. I need to do that because of the funky games we do with
> > "inline" redefinitions in include/linux/compiler_types.h.
> >
> > And Segher hinted at either doing:
> >
> > asm volatile inline(...
> >
> > or
> >
> > asm volatile __inline__(...
> >
> > but both "inline" variants are defined as macros in that file.
> >
> > Which means we either need to #undef inline before using it in asm() or
> > come up with something cleverer.
>
> # git grep -e "\<__inline__\>" | wc -l
> 488
> # git grep -e "\<__inline\>" | wc -l
> 56
> # git grep -e "\" | wc -l
> 69598
>
> And we already have scripts/checkpatch.pl:
>
>   # Check for __inline__ and __inline, prefer inline
>
> Which suggests we do:
>
> git grep -l "\<__inline\(\|__\)\>" | while read file
> do
> sed -i -e 's/\<__inline\(\|__\)\>/inline/g' $file
> done
>
> and get it over with.


Do you have a plan to really do this?

This is a nice cleanup anyway.

I think the last minute of MW is
a good timing for the global replacement like this.




>
> Anyway, with the below patch, I get:
>
>textdata bss dec hex filename
> 173851835064780 1953892 244038551745f8f 
> defconfig-build/vmlinux
> 173856785064780 1953892 24404350174617e 
> defconfig-build/vmlinux
>
> Which shows we inline more (look for asm_volatile for the actual
> changes).
>
>
> So yes, this seems like something we could work with.
>
> ---
>  Documentation/trace/tracepoint-analysis.rst|  2 +-
>  Documentation/translations/ja_JP/SubmittingPatches |  4 +--
>  Documentation/translations/zh_CN/SubmittingPatches |  4 +--
>  arch/alpha/include/asm/atomic.h| 12 +++
>  arch/alpha/include/asm/bitops.h|  6 ++--
>  arch/alpha/include/asm/compiler.h  |  4 +--
>  arch/alpha/include/asm/dma.h   | 22 ++--
>  arch/alpha/include/asm/floppy.h|  4 +--
>  arch/alpha/include/asm/irq.h   |  2 +-
>  arch/alpha/include/asm/local.h |  4 +--
>  arch/alpha/include/asm/smp.h   |  2 +-
>  arch/arm/mach-iop32x/include/mach/uncompress.h |  2 +-
>  arch/arm/mach-iop33x/include/mach/uncompress.h |  2 +-
>  arch/arm/mach-ixp4xx/include/mach/uncompress.h |  2 +-
>  arch/ia64/hp/common/sba_iommu.c|  2 +-
>  arch/ia64/hp/sim/simeth.c  |  2 +-
>  arch/ia64/include/asm/atomic.h |  8 ++---
>  arch/ia64/include/asm/bitops.h | 34 +-
>  arch/ia64/include/asm/delay.h  | 14 
>  arch/ia64/include/asm/irq.h|  2 +-
>  arch/ia64/include/asm/page.h   |  2 +-
>  arch/ia64/include/asm/sn/leds.h|  2 +-
>  arch/ia64/include/asm/uaccess.h|  4 +--
>  arch/ia64/include/uapi/asm/rse.h   | 12 +++
>  arch/ia64/include/uapi/asm/swab.h  |  6 ++--
>  arch/ia64/oprofile/backtrace.c |  4 +--
>  arch/m68k/include/asm/blinken.h|  2 +-
>  arch/m68k/include/asm/checksum.h   |  2 +-
>  arch/m68k/include/asm/dma.h| 32 -
>  arch/m68k/include/asm/floppy.h |  8 ++---
>  arch/m68k/include/asm/nettel.h |  8 ++---
>  arch/m68k/mac/iop.c| 14 
>  arch/mips/include/asm/atomic.h | 16 -
>  arch/mips/include/asm/checksum.h   |  2 +-
>  arch/mips/include/asm/dma.h| 20 +--
>  arch/mips/include/asm/jazz.h   |  2 +-
>  arch/mips/include/asm/local.h  |  4 +--
>  arch/mips/include/asm/string.h |  8 ++---
>  arch/mips/kernel/binfmt_elfn32.c   |  2 +-
>  arch/nds32/include/asm/swab.h  |  4 +--
>  arch/parisc/include/asm/atomic.h   | 20 +--
>  arch/parisc/include/asm/bitops.h   | 18 +-
>  arch/parisc/include/asm/checksum.h |  4 +--
>  arch/parisc/include/asm/compat.h   |  2 +-
>  arch/parisc/include/asm/delay.h|  2 +-
>  arch/parisc/include/asm/dma.h  | 20 +--
>  arch/parisc/include/asm/ide.h  |  8 ++---
>  arch/parisc/include/asm/irq.h  

Re: [PATCH 13/18] drm/mediatek: add ddp write register common api

2018-12-26 Thread CK Hu
Hi, Yongqiang:

On Mon, 2018-12-24 at 16:08 +0800, Yongqiang Niu wrote:
> This patch add ddp write register common api
> 

I could not see anywhere you use these function. If the function is
useless, drop this patch.

Regards,
CK

> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 24 
>  drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h |  9 +
>  2 files changed, 33 insertions(+)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> index a97e27b..1c0f9cc 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
> @@ -84,6 +84,30 @@
>  #define DITHER_ADD_LSHIFT_G(x)   (((x) & 0x7) << 4)
>  #define DITHER_ADD_RSHIFT_G(x)   (((x) & 0x7) << 0)
>  
> +void mtk_ddp_write(unsigned int value, struct mtk_ddp_comp *comp,
> +unsigned int offset)
> +{
> + writel(value, comp->regs + offset);
> +}
> +
> +void mtk_ddp_write_relaxed(unsigned int value,
> +struct mtk_ddp_comp *comp,
> +unsigned int offset)
> +{
> + writel_relaxed(value, comp->regs + offset);
> +}
> +
> +void mtk_ddp_write_mask(unsigned int value,
> + struct mtk_ddp_comp *comp,
> + unsigned int offset,
> + unsigned int mask)
> +{
> + unsigned int tmp = readl(comp->regs + offset);
> +
> + tmp = (tmp & ~mask) | (value & mask);
> + writel(tmp, comp->regs + offset);
> +}
> +
>  void mtk_dither_set(struct mtk_ddp_comp *comp, unsigned int bpc,
>   unsigned int CFG)
>  {
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h 
> b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> index f2ab0b3..b908172 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h
> @@ -189,5 +189,14 @@ int mtk_ddp_comp_init(struct device *dev, struct 
> device_node *comp_node,
>  void mtk_ddp_comp_unregister(struct drm_device *drm, struct mtk_ddp_comp 
> *comp);
>  void mtk_dither_set(struct mtk_ddp_comp *comp, unsigned int bpc,
>   unsigned int CFG);
> +void mtk_ddp_write(unsigned int value, struct mtk_ddp_comp *comp,
> +unsigned int offset);
> +void mtk_ddp_write_relaxed(unsigned int value,
> +struct mtk_ddp_comp *comp,
> +unsigned int offset);
> +void mtk_ddp_write_mask(unsigned int value,
> + struct mtk_ddp_comp *comp,
> + unsigned int offset,
> + unsigned int mask);
>  
>  #endif /* MTK_DRM_DDP_COMP_H */




Re: [GIT PULL] scheduler changes for v4.21

2018-12-26 Thread Olof Johansson
Hi,

On Mon, Dec 24, 2018 at 2:45 PM Ingo Molnar  wrote:
>
> Linus,
>
> Please pull the latest sched-core-for-linus git tree from:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> sched-core-for-linus
>
># HEAD: 732cd75b8c920d3727e69957b14faa7c2d7c3b75 sched/fair: Select an 
> energy-efficient CPU on task wake-up
>
> The main changes in this cycle were:
>
>  - Introduce "Energy Aware Scheduling" - by Quentin Perret. This is a
>coherent topology description of CPUs in cooperation with the PM
>subsystem, with the goal to schedule more energy-efficiently on
>assymetric SMP platform - such as waking up tasks to the more
>energy-efficient CPUs first, as long as the system isn't
>oversubscribed.
>
>For details of the design, see:
>
>   https://marc.info/?l=linux-kernel=153243513908731=2
>
>  - Misc cleanups and smaller enhancements.

Looks like my warnings fix never made it in, even after a few pings.

Linus, can you apply directly? Causes warning noise on all !SMP ARM builds:

https://lore.kernel.org/lkml/20181125224105.123568-1-o...@lixom.net/


Thanks,

-Olof



-Olof


Re: [RFC][PATCH v2 01/21] e820: cheat PMEM as DRAM

2018-12-26 Thread Fengguang Wu

On Wed, Dec 26, 2018 at 07:41:41PM -0800, Matthew Wilcox wrote:

On Wed, Dec 26, 2018 at 09:14:47PM +0800, Fengguang Wu wrote:

From: Fan Du 

This is a hack to enumerate PMEM as NUMA nodes.
It's necessary for current BIOS that don't yet fill ACPI HMAT table.

WARNING: take care to backup. It is mutual exclusive with libnvdimm
subsystem and can destroy ndctl managed namespaces.


Why depend on firmware to present this "correctly"?  It seems to me like
less effort all around to have ndctl label some namespaces as being for
this kind of use.


Dave Hansen may be more suitable to answer your question. He posted
patches to make PMEM NUMA node coexist with libnvdimm and ndctl:

[PATCH 0/9] Allow persistent memory to be used like normal RAM
https://lkml.org/lkml/2018/10/23/9

That depends on future BIOS. So we did this quick hack to test out
PMEM NUMA node for the existing BIOS.

Thanks,
Fengguang


[PATCH] f2fs: sanity check of xattr entry size

2018-12-26 Thread Jaegeuk Kim
There is a security report where f2fs_getxattr() has a hole to expose wrong
memory region when the image is malformed like this.

f2fs_getxattr: entry->e_name_len: 4, size: 12288, buffer_size: 16384, len: 4

Cc: 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/xattr.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/xattr.c b/fs/f2fs/xattr.c
index f44b0c38398b..18d5ffbc5e8c 100644
--- a/fs/f2fs/xattr.c
+++ b/fs/f2fs/xattr.c
@@ -288,7 +288,7 @@ static int read_xattr_block(struct inode *inode, void 
*txattr_addr)
 static int lookup_all_xattrs(struct inode *inode, struct page *ipage,
unsigned int index, unsigned int len,
const char *name, struct f2fs_xattr_entry **xe,
-   void **base_addr)
+   void **base_addr, int *base_size)
 {
void *cur_addr, *txattr_addr, *last_addr = NULL;
nid_t xnid = F2FS_I(inode)->i_xattr_nid;
@@ -299,8 +299,8 @@ static int lookup_all_xattrs(struct inode *inode, struct 
page *ipage,
if (!size && !inline_size)
return -ENODATA;
 
-   txattr_addr = f2fs_kzalloc(F2FS_I_SB(inode),
-   inline_size + size + XATTR_PADDING_SIZE, GFP_NOFS);
+   *base_size = inline_size + size + XATTR_PADDING_SIZE;
+   txattr_addr = f2fs_kzalloc(F2FS_I_SB(inode), *base_size, GFP_NOFS);
if (!txattr_addr)
return -ENOMEM;
 
@@ -312,8 +312,10 @@ static int lookup_all_xattrs(struct inode *inode, struct 
page *ipage,
 
*xe = __find_inline_xattr(inode, txattr_addr, _addr,
index, len, name);
-   if (*xe)
+   if (*xe) {
+   *base_size = inline_size;
goto check;
+   }
}
 
/* read from xattr node block */
@@ -474,6 +476,7 @@ int f2fs_getxattr(struct inode *inode, int index, const 
char *name,
int error = 0;
unsigned int size, len;
void *base_addr = NULL;
+   int base_size;
 
if (name == NULL)
return -EINVAL;
@@ -484,7 +487,7 @@ int f2fs_getxattr(struct inode *inode, int index, const 
char *name,
 
down_read(_I(inode)->i_xattr_sem);
error = lookup_all_xattrs(inode, ipage, index, len, name,
-   , _addr);
+   , _addr, _size);
up_read(_I(inode)->i_xattr_sem);
if (error)
return error;
@@ -498,6 +501,11 @@ int f2fs_getxattr(struct inode *inode, int index, const 
char *name,
 
if (buffer) {
char *pval = entry->e_name + entry->e_name_len;
+
+   if (base_size - (pval - (char *)base_addr) < size) {
+   error = -ERANGE;
+   goto out;
+   }
memcpy(buffer, pval, size);
}
error = size;
-- 
2.19.0.605.g01d371f741-goog



Re: [PATCH v1] phy: qcom-ufs: Use iopoll.h readl_poll_timeout macro

2018-12-26 Thread Bjorn Andersson
On Fri 21 Dec 02:13 PST 2018, Marc Gonzalez wrote:

> The private copy of readl_poll_timeout is no longer needed.
> Use the implementation in iopoll.h instead.
> 
> Signed-off-by: Marc Gonzalez 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/phy/qualcomm/phy-qcom-ufs-i.h | 19 +--
>  1 file changed, 1 insertion(+), 18 deletions(-)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-ufs-i.h 
> b/drivers/phy/qualcomm/phy-qcom-ufs-i.h
> index 681644e43248..f798fb64de94 100644
> --- a/drivers/phy/qualcomm/phy-qcom-ufs-i.h
> +++ b/drivers/phy/qualcomm/phy-qcom-ufs-i.h
> @@ -23,24 +23,7 @@
>  #include 
>  #include 
>  #include 
> -
> -#define readl_poll_timeout(addr, val, cond, sleep_us, timeout_us) \
> -({ \
> - ktime_t timeout = ktime_add_us(ktime_get(), timeout_us); \
> - might_sleep_if(timeout_us); \
> - for (;;) { \
> - (val) = readl(addr); \
> - if (cond) \
> - break; \
> - if (timeout_us && ktime_compare(ktime_get(), timeout) > 0) { \
> - (val) = readl(addr); \
> - break; \
> - } \
> - if (sleep_us) \
> - usleep_range(DIV_ROUND_UP(sleep_us, 4), sleep_us); \
> - } \
> - (cond) ? 0 : -ETIMEDOUT; \
> -})
> +#include 
>  
>  #define UFS_QCOM_PHY_CAL_ENTRY(reg, val) \
>   {   \
> -- 
> 2.17.1


Re: [PATCH 3/3] RISC-V: Fix non-smp kernel boot on SMP systems

2018-12-26 Thread Anup Patel
On Thu, Dec 27, 2018 at 4:39 AM Atish Patra  wrote:
>
> In non-smp configuration, hartid can be higher that NR_CPUS.
> riscv_of_processor_hartid should not be compared to hartid to
> NR_CPUS in that case. Moreover, this function checks all the
> DT properties of a hart node. NR_CPUS comparison seems out of
> place.

This only explains change in arch/riscv/kernel/cpu.c

Create separate patch for it.

>
> Do cpuid comparison with NR_CPUs in smp setup code. Update the

Create separate patch for change in arch/riscv/kernel/smp.c

> drivers to handle appropriate code as well.

Create separate patches for riscv_timer and irq-sifive-plic.c
because they will probably go via different gitrepos.

>
> Signed-off-by: Atish Patra 
> ---
>  arch/riscv/kernel/cpu.c   |  4 
>  arch/riscv/kernel/smp.c   |  1 -
>  arch/riscv/kernel/smpboot.c   |  5 +
>  drivers/clocksource/riscv_timer.c | 21 ++---
>  drivers/irqchip/irq-sifive-plic.c |  5 +
>  5 files changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
> index b4a7d442..251ffab6 100644
> --- a/arch/riscv/kernel/cpu.c
> +++ b/arch/riscv/kernel/cpu.c
> @@ -34,10 +34,6 @@ int riscv_of_processor_hartid(struct device_node *node)
> pr_warn("Found CPU without hart ID\n");
> return -(ENODEV);
> }
> -   if (hart >= NR_CPUS) {
> -   pr_info("Found hart ID %d, which is above NR_CPUs.  Disabling 
> this hart\n", hart);
> -   return -(ENODEV);
> -   }
>
> if (of_property_read_string(node, "status", )) {
> pr_warn("CPU with hartid=%d has no \"status\" property\n", 
> hart);
> diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
> index 57b1383e..9ea7ac7d 100644
> --- a/arch/riscv/kernel/smp.c
> +++ b/arch/riscv/kernel/smp.c
> @@ -49,7 +49,6 @@ int riscv_hartid_to_cpuid(int hartid)
> return i;
>
> pr_err("Couldn't find cpu id for hartid [%d]\n", hartid);
> -   BUG();

Have a separate patch with explanation about why
we don't need BUG() here.

> return i;
>  }
>
> diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> index bb8cd242..05291840 100644
> --- a/arch/riscv/kernel/smpboot.c
> +++ b/arch/riscv/kernel/smpboot.c
> @@ -66,6 +66,11 @@ void __init setup_smp(void)
> found_boot_cpu = 1;
> continue;
> }
> +   if (cpuid >= NR_CPUS) {
> +   pr_warn("Invalid cpuid [%d] for hartid [%d]\n",
> +   cpuid, hart);
> +   break;
> +   }
>
> cpuid_to_hartid_map(cpuid) = hart;
> set_cpu_possible(cpuid, true);
> diff --git a/drivers/clocksource/riscv_timer.c 
> b/drivers/clocksource/riscv_timer.c
> index 084e97dc..acf2af10 100644
> --- a/drivers/clocksource/riscv_timer.c
> +++ b/drivers/clocksource/riscv_timer.c
> @@ -89,20 +89,35 @@ static int __init riscv_timer_init_dt(struct device_node 
> *n)
> struct clocksource *cs;
>
> hartid = riscv_of_processor_hartid(n);
> +   if (hartid < 0) {
> +   pr_warn("Not valid hartid for node [%pOF] error = [%d]\n",
> +   n, hartid);
> +   return hartid;
> +   }
> cpuid = riscv_hartid_to_cpuid(hartid);
>
> +   if (cpuid < 0)
> +   pr_warn("Invalid cpuid for hartid [%d]\n", hartid);
> +
> if (cpuid != smp_processor_id())
> return 0;
>
> +   pr_err("%s: Registering clocksource cpuid [%d] hartid [%d]\n",
> +  __func__, cpuid, hartid);
> cs = per_cpu_ptr(_clocksource, cpuid);
> -   clocksource_register_hz(cs, riscv_timebase);
> +   error = clocksource_register_hz(cs, riscv_timebase);
>
> +   if (error) {
> +   pr_err("RISCV timer register failed [%d] for cpu = [%d]\n",
> +  error, cpuid);
> +   return error;
> +   }
> error = cpuhp_setup_state(CPUHP_AP_RISCV_TIMER_STARTING,
>  "clockevents/riscv/timer:starting",
>  riscv_timer_starting_cpu, riscv_timer_dying_cpu);
> if (error)
> -   pr_err("RISCV timer register failed [%d] for cpu = [%d]\n",
> -  error, cpuid);
> +   pr_err("cpu hp setup state failed for RISCV timer [%d]\n",
> +  error);
> return error;
>  }
>
> diff --git a/drivers/irqchip/irq-sifive-plic.c 
> b/drivers/irqchip/irq-sifive-plic.c
> index 357e9daf..254ecd76 100644
> --- a/drivers/irqchip/irq-sifive-plic.c
> +++ b/drivers/irqchip/irq-sifive-plic.c
> @@ -237,6 +237,11 @@ static int __init plic_init(struct device_node *node,
> }
>
> cpu = riscv_hartid_to_cpuid(hartid);
> +   if (cpu < 0) {
> +   pr_warn("Invalid 

Re: [PATCH] mm: compaction.c: Propagate return value upstream

2018-12-26 Thread Matthew Wilcox
On Wed, Dec 26, 2018 at 01:42:56PM -0600, Aditya Pakki wrote:
> In sysctl_extfrag_handler(), proc_dointvec_minmax() can return an
> error. The fix propagates the error upstream in case of failure.

Why not just ...

Mel, Randy?  You seem to have been the prime instigators on this.

diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index 68250a57aace..70d0256edd31 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -88,8 +88,6 @@ extern int sysctl_compact_memory;
 extern int sysctl_compaction_handler(struct ctl_table *table, int write,
void __user *buffer, size_t *length, loff_t *ppos);
 extern int sysctl_extfrag_threshold;
-extern int sysctl_extfrag_handler(struct ctl_table *table, int write,
-   void __user *buffer, size_t *length, loff_t *ppos);
 extern int sysctl_compact_unevictable_allowed;
 
 extern int fragmentation_index(struct zone *zone, unsigned int order);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 5fc724e4e454..e9c69247fc29 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1439,7 +1439,7 @@ static struct ctl_table vm_table[] = {
.data   = _extfrag_threshold,
.maxlen = sizeof(int),
.mode   = 0644,
-   .proc_handler   = sysctl_extfrag_handler,
+   .proc_handler   = proc_dointvec_minmax,
.extra1 = _extfrag_threshold,
.extra2 = _extfrag_threshold,
},
diff --git a/mm/compaction.c b/mm/compaction.c
index 7c607479de4a..80b941d9b6e7 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1876,14 +1876,6 @@ int sysctl_compaction_handler(struct ctl_table *table, 
int write,
return 0;
 }
 
-int sysctl_extfrag_handler(struct ctl_table *table, int write,
-   void __user *buffer, size_t *length, loff_t *ppos)
-{
-   proc_dointvec_minmax(table, write, buffer, length, ppos);
-
-   return 0;
-}
-
 #if defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
 static ssize_t sysfs_compact_node(struct device *dev,
struct device_attribute *attr,


Re: [PATCH] usb: dvb: check status of mxl111sf_read_reg

2018-12-26 Thread Michael Ira Krufky
Kangjie,

On Wed, Dec 26, 2018 at 12:59 AM Kangjie Lu  wrote:
>
> When mxl111sf_read_reg fails, we shouldn't use "mode". The fix checks
> its return value using mxl_fail
>
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c
> index ffb6e7c72f57..aecc3d02fc1e 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-phy.c
> @@ -130,7 +130,8 @@ int mxl111sf_config_mpeg_in(struct mxl111sf_state *state,
> mxl_fail(ret);
>
> /* Configure MPEG Clock phase */
> -   mxl111sf_read_reg(state, V6_MPEG_IN_CLK_INV_REG, );
> +   ret = mxl111sf_read_reg(state, V6_MPEG_IN_CLK_INV_REG, );
> +   mxl_fail(ret);
>
> if (clock_phase == TSIF_NORMAL)
> mode &= ~V6_INVERTED_CLK_PHASE;
> --
> 2.17.2 (Apple Git-113)

It *looks* correct, however

If I recall correctly, this chip will often fail when reading
registers.   Notice, `mode` is initialized to zero at first, and not
again touched before being passed to the readreg function - this is on
purpose.   The value remains untouched if the read fails. and the
read _wil_ fail.  Maybe not always, but sometimes.

When you run with the patch applied, does it just spew errors?

-Mike


Re: [RFC][PATCH v2 01/21] e820: cheat PMEM as DRAM

2018-12-26 Thread Matthew Wilcox
On Wed, Dec 26, 2018 at 09:14:47PM +0800, Fengguang Wu wrote:
> From: Fan Du 
> 
> This is a hack to enumerate PMEM as NUMA nodes.
> It's necessary for current BIOS that don't yet fill ACPI HMAT table.
> 
> WARNING: take care to backup. It is mutual exclusive with libnvdimm
> subsystem and can destroy ndctl managed namespaces.

Why depend on firmware to present this "correctly"?  It seems to me like
less effort all around to have ndctl label some namespaces as being for
this kind of use.


[PATCH] nvmem: bcm-ocotp: Add ACPI support to BCM OCOTP

2018-12-26 Thread Srinath Mannam
Add ACPI support to bcm ocotp driver

This patch is based on Linux-4.20-rc7.

Signed-off-by: Srinath Mannam 
---
 drivers/nvmem/bcm-ocotp.c | 37 -
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/nvmem/bcm-ocotp.c b/drivers/nvmem/bcm-ocotp.c
index 4159b3f..a809751 100644
--- a/drivers/nvmem/bcm-ocotp.c
+++ b/drivers/nvmem/bcm-ocotp.c
@@ -11,13 +11,14 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 /*
@@ -78,9 +79,9 @@ static struct otpc_map otp_map_v2 = {
 };
 
 struct otpc_priv {
-   struct device   *dev;
-   void __iomem*base;
-   struct otpc_map *map;
+   struct device *dev;
+   void __iomem *base;
+   const struct otpc_map *map;
struct nvmem_config *config;
 };
 
@@ -237,16 +238,22 @@ static struct nvmem_config bcm_otpc_nvmem_config = {
 };
 
 static const struct of_device_id bcm_otpc_dt_ids[] = {
-   { .compatible = "brcm,ocotp" },
-   { .compatible = "brcm,ocotp-v2" },
+   { .compatible = "brcm,ocotp", .data = _map },
+   { .compatible = "brcm,ocotp-v2", .data = _map_v2 },
{ },
 };
 MODULE_DEVICE_TABLE(of, bcm_otpc_dt_ids);
 
+static const struct acpi_device_id bcm_otpc_acpi_ids[] = {
+   { .id = "BRCM0700", .driver_data = (kernel_ulong_t)_map },
+   { .id = "BRCM0701", .driver_data = (kernel_ulong_t)_map_v2 },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(acpi, bcm_otpc_acpi_ids);
+
 static int bcm_otpc_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
-   struct device_node *dn = dev->of_node;
struct resource *res;
struct otpc_priv *priv;
struct nvmem_device *nvmem;
@@ -257,14 +264,9 @@ static int bcm_otpc_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
-   if (of_device_is_compatible(dev->of_node, "brcm,ocotp"))
-   priv->map = _map;
-   else if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2"))
-   priv->map = _map_v2;
-   else {
-   dev_err(dev, "%s otpc config map not defined\n", __func__);
-   return -EINVAL;
-   }
+   priv->map = device_get_match_data(dev);
+   if (!priv->map)
+   return -ENODEV;
 
/* Get OTP base address register. */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
@@ -281,7 +283,7 @@ static int bcm_otpc_probe(struct platform_device *pdev)
reset_start_bit(priv->base);
 
/* Read size of memory in words. */
-   err = of_property_read_u32(dn, "brcm,ocotp-size", _words);
+   err = device_property_read_u32(dev, "brcm,ocotp-size", _words);
if (err) {
dev_err(dev, "size parameter not specified\n");
return -EINVAL;
@@ -294,7 +296,7 @@ static int bcm_otpc_probe(struct platform_device *pdev)
bcm_otpc_nvmem_config.dev = dev;
bcm_otpc_nvmem_config.priv = priv;
 
-   if (of_device_is_compatible(dev->of_node, "brcm,ocotp-v2")) {
+   if (priv->map == _map_v2) {
bcm_otpc_nvmem_config.word_size = 8;
bcm_otpc_nvmem_config.stride = 8;
}
@@ -315,6 +317,7 @@ static struct platform_driver bcm_otpc_driver = {
.driver = {
.name   = "brcm-otpc",
.of_match_table = bcm_otpc_dt_ids,
+   .acpi_match_table = ACPI_PTR(bcm_otpc_acpi_ids),
},
 };
 module_platform_driver(bcm_otpc_driver);
-- 
2.7.4



Re: [PATCH 2/3] RISC-V: Move cpuid to hartid mapping to SMP.

2018-12-26 Thread Anup Patel
On Thu, Dec 27, 2018 at 4:39 AM Atish Patra  wrote:
>
> Currently, logical CPU id to physical hartid mapping is
> defined for both smp and non-smp configurations. This
> is not required as we need this only for smp configuration.
> The mapping function can define directly boot_cpu_hartid
> for non-smp usecase.
>
> The reverse mapping function i.e. hartid to cpuid can be called
> for any valid but not booted harts. So it should return default
> cpu 0 only if it is a boot hartid
>
> Signed-off-by: Atish Patra 
> ---
>  arch/riscv/include/asm/smp.h | 13 +++--
>  arch/riscv/kernel/setup.c|  2 ++
>  2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
> index 41aa73b4..8f30300f 100644
> --- a/arch/riscv/include/asm/smp.h
> +++ b/arch/riscv/include/asm/smp.h
> @@ -22,12 +22,13 @@
>  /*
>   * Mapping between linux logical cpu index and hartid.
>   */
> -extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
> -#define cpuid_to_hartid_map(cpu)__cpuid_to_hartid_map[cpu]
>
> +extern unsigned long boot_cpu_hartid;
>  struct seq_file;
>
>  #ifdef CONFIG_SMP
> +extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
> +#define cpuid_to_hartid_map(cpu)__cpuid_to_hartid_map[cpu]
>
>  /* print IPI stats */
>  void show_ipi_stats(struct seq_file *p, int prec);
> @@ -58,7 +59,15 @@ static inline void show_ipi_stats(struct seq_file *p, int 
> prec)
>
>  static inline int riscv_hartid_to_cpuid(int hartid)
>  {
> +   if (hartid == boot_cpu_hartid)
> return 0;
> +   else
> +   return -1;
> +}
> +static inline unsigned long cpuid_to_hartid_map(int cpu)
> +{
> +
> +   return boot_cpu_hartid;
>  }
>
>  static inline void riscv_cpuid_to_hartid_mask(const struct cpumask *in,
> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> index 2c290e6a..bd4d7b85 100644
> --- a/arch/riscv/kernel/setup.c
> +++ b/arch/riscv/kernel/setup.c
> @@ -83,6 +83,7 @@ EXPORT_SYMBOL(empty_zero_page);
>  atomic_t hart_lottery;
>  unsigned long boot_cpu_hartid;
>
> +#ifdef CONFIG_SMP
>  unsigned long __cpuid_to_hartid_map[NR_CPUS] = {
> [0 ... NR_CPUS-1] = INVALID_HARTID
>  };
> @@ -91,6 +92,7 @@ void __init smp_setup_processor_id(void)
>  {
> cpuid_to_hartid_map(0) = boot_cpu_hartid;
>  }
> +#endif

Please move __cpuid_to_hartid_map[] and smp_setup_processor_id()
to arch/riscv/kernel/smp.c

Otherwise, looks good to me.

Reviewed-by: Anup Patel 


Re: [PATCH 1/3] RISC-V: Do not wait indefinitely in __cpu_up

2018-12-26 Thread Anup Patel
On Thu, Dec 27, 2018 at 4:39 AM Atish Patra  wrote:
>
> In SMP path, __cpu_up waits for other CPU to come online
> indefinitely. This is wrong as other CPU might be disabled
> in machine mode and possible CPU is set to the cpus present
> in DT.
>
> Introduce a completion variable and waits only for a second.
>
> Signed-off-by: Atish Patra 
> ---
>  arch/riscv/kernel/smpboot.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
> index 18cda0e8..bb8cd242 100644
> --- a/arch/riscv/kernel/smpboot.c
> +++ b/arch/riscv/kernel/smpboot.c
> @@ -39,6 +39,7 @@
>
>  void *__cpu_up_stack_pointer[NR_CPUS];
>  void *__cpu_up_task_pointer[NR_CPUS];
> +static DECLARE_COMPLETION(cpu_running);
>
>  void __init smp_prepare_boot_cpu(void)
>  {
> @@ -77,6 +78,7 @@ void __init setup_smp(void)
>
>  int __cpu_up(unsigned int cpu, struct task_struct *tidle)
>  {
> +   int ret = 0;
> int hartid = cpuid_to_hartid_map(cpu);
> tidle->thread_info.cpu = cpu;
>
> @@ -92,10 +94,15 @@ int __cpu_up(unsigned int cpu, struct task_struct *tidle)
>   task_stack_page(tidle) + THREAD_SIZE);
> WRITE_ONCE(__cpu_up_task_pointer[hartid], tidle);
>
> -   while (!cpu_online(cpu))
> -   cpu_relax();
> +   wait_for_completion_timeout(_running,
> +   msecs_to_jiffies(1000));
>
> -   return 0;
> +   if (!cpu_online(cpu)) {
> +   pr_crit("CPU%u: failed to come online\n", cpu);
> +   ret = -EIO;
> +   }
> +
> +   return ret;
>  }
>
>  void __init smp_cpus_done(unsigned int max_cpus)
> @@ -121,6 +128,7 @@ asmlinkage void __init smp_callin(void)
>  * a local TLB flush right now just in case.
>  */
> local_flush_tlb_all();
> +   complete(_running);
> /*
>  * Disable preemption before enabling interrupts, so we don't try to
>  * schedule a CPU that hasn't actually started yet.
> --
> 2.7.4
>

Looks good to me.

Reviewed-by: Anup Patel 


Re: [PATCH][next] KVM: x86: Fix bit shifting in update_intel_pt_cfg

2018-12-26 Thread Wei Yang
On Wed, Dec 26, 2018 at 02:40:59PM -0600, Gustavo A. R. Silva wrote:
>ctl_bitmask in pt_desc is of type u64. When an integer like 0xf is
>being left shifted more than 32 bits, the behavior is undefined.
>
>Fix this by adding suffix ULL to integer 0xf.
>
>Addresses-Coverity-ID: 1476095 ("Bad bit shift operation")
>Fixes: 6c0f0bba85a0 ("KVM: x86: Introduce a function to initialize the PT 
>configuration")
>Signed-off-by: Gustavo A. R. Silva 

Looks good.

Reviewed-by: Wei Yang 

>---
> arch/x86/kvm/vmx/vmx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
>index cbd55e7aeae5..251c68a74bbe 100644
>--- a/arch/x86/kvm/vmx/vmx.c
>+++ b/arch/x86/kvm/vmx/vmx.c
>@@ -7012,7 +7012,7 @@ static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
> 
>   /* unmask address range configure area */
>   for (i = 0; i < vmx->pt_desc.addr_range; i++)
>-  vmx->pt_desc.ctl_bitmask &= ~(0xf << (32 + i * 4));
>+  vmx->pt_desc.ctl_bitmask &= ~(0xfULL << (32 + i * 4));
> }
> 
> static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
>-- 
>2.20.1

-- 
Wei Yang
Help you, Help me


Re: [GIT PULL] sound updates for 4.21

2018-12-26 Thread Linus Torvalds
On Thu, Dec 20, 2018 at 7:38 AM Takashi Iwai  wrote:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git 
> tags/sound-4.21-rc1

Hmm.

It turns out that commit c337104b1a16 ("ALSA: HD-Audio: SKL+: abort
probe if DSP is present and Skylake driver selected") causes my laptop
(XPS13 9350) to no longer suspend.

The screen goes dark, but the power light never turns off. There's
nothing in the logs.

> Pierre-Louis Bossart (16):
>   ALSA: HD-Audio: SKL+: abort probe if DSP is present and Skylake driver 
> selected

Sadly, that commit does not revert cleanly, since it's preparatory for
a lot of other changes.

Here's the lspci output:

  /sbin/lspci -s 0:1f.3 -vn
  00:1f.3 0403: 8086:9d70 (rev 21) (prog-if 80)
  Subsystem: 1028:0704
  Flags: bus master, fast devsel, latency 32, IRQ 16
  Memory at dc328000 (64-bit, non-prefetchable) [size=16K]
  Memory at dc30 (64-bit, non-prefetchable) [size=64K]
  Capabilities: 
  Kernel driver in use: snd_soc_skl
  Kernel modules: snd_hda_intel, snd_soc_skl

and it's a bog-standard Intel i7-6560U laptop.

I have no real information, except that I bisected the (reliable)
behavior to this commit. Before that commit, suspend/resume works
fine. After that commit, suspend just hangs and leaves a dead machine.

Linus


Re: [PATCH v5 1/5] Bluetooth: hci_qca: use wait_until_sent() for power pulses

2018-12-26 Thread Balakrishna Godavarthi

Hi Matthias,

On 2018-12-27 03:51, Matthias Kaehlcke wrote:

On Wed, Dec 26, 2018 at 12:01:51PM +0530, Balakrishna Godavarthi wrote:

Hi Matthias,

On 2018-12-22 07:29, Matthias Kaehlcke wrote:
> On Thu, Dec 20, 2018 at 08:16:35PM +0530, Balakrishna Godavarthi wrote:
> > wcn3990 requires a power pulse to turn ON/OFF along with
> > regulators. Sometimes we are observing the power pulses are sent
> > out with some time delay, due to queuing these commands. This is
> > causing synchronization issues with chip, which intern delay the
> > chip setup or may end up with communication issues.
> >
> > Signed-off-by: Balakrishna Godavarthi 
> > ---
> >  drivers/bluetooth/hci_qca.c | 38
> > ++---
> >  1 file changed, 14 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index f036c8f98ea3..5a07c2370289 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -1013,11 +1013,9 @@ static inline void host_set_baudrate(struct
> > hci_uart *hu, unsigned int speed)
> >   hci_uart_set_baudrate(hu, speed);
> >  }
> >
> > -static int qca_send_power_pulse(struct hci_dev *hdev, u8 cmd)
> > +static int qca_send_power_pulse(struct hci_uart *hu, u8 cmd)
> >  {
> > - struct hci_uart *hu = hci_get_drvdata(hdev);
> > - struct qca_data *qca = hu->priv;
> > - struct sk_buff *skb;
> > + int ret;
> >
> >   /* These power pulses are single byte command which are sent
> >* at required baudrate to wcn3990. On wcn3990, we have an external
> > @@ -1029,19 +1027,16 @@ static int qca_send_power_pulse(struct
> > hci_dev *hdev, u8 cmd)
> >* save power. Disabling hardware flow control is mandatory while
> >* sending power pulses to SoC.
> >*/
> > - bt_dev_dbg(hdev, "sending power pulse %02x to SoC", cmd);
> > -
> > - skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
> > - if (!skb)
> > - return -ENOMEM;
> > -
> > + bt_dev_dbg(hu->hdev, "sending power pulse %02x to SoC", cmd);
> >   hci_uart_set_flow_control(hu, true);
> > + ret = serdev_device_write_buf(hu->serdev, , sizeof(cmd));
> > + if (ret < 0) {
> > + bt_dev_err(hu->hdev, "failed to send power pulse %02x to SoC",
> > +cmd);
> > + return ret;
> > + }
> >
> > - skb_put_u8(skb, cmd);
> > - hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
> > -
> > - skb_queue_tail(>txq, skb);
> > - hci_uart_tx_wakeup(hu);
> > + serdev_device_wait_until_sent(hu->serdev, 0);
>
> serdev_device_wait_until_sent() might only guarantee that the UART
> circular buffer is empty (see
> https://elixir.bootlin.com/linux/v4.19/source/drivers/tty/tty_ioctl.c#L225),
> not that the data has actually sent (e.g. it might be sitting in
> the UART FIFO). However with this:
>
> >   /* Wait for 100 uS for SoC to settle down */
> >   usleep_range(100, 200);
>
> we should probably be fine, unless there's tons of data in the
> FIFO.
>
> You currently call serdev_device_write_flush() in
> qca_power_shutdown(), I wonder if it would make sense to call it in
> qca_send_power_pulse(), regardless of whether it's an on or off

[Bala]: during sending the ON pulse we will not have any data in the
UART circular buffer as this is the first command to send and 
we are

sending it as soon as we open the port.
so i taught why should be flush the circular as it is already 
empty.



> pulse. In any case we don't care if the chip receives any 'pending'
> data when we switch it on or off, right?
>

[Bala]: during on we freshly open port and i see that flush() called 
while

port opening.

https://elixir.bootlin.com/linux/latest/source/drivers/tty/serial/serial_core.c#L207


I would argue that the serdev_device_write_flush() call in
qca_power_shutdown() is related with/needed for sending the power off
pulse, hence it should be part of qca_send_power_pulse(), unless it
adds a significant overhead and we really want to call it only in the
shutdown case.

Flushing the buffer should be fairly lightweight and power pulses are
only sent when the device is switched on or off, so the overhead
should be negligible. You *could* restrict the flush to the power off
pulse, assuming that the driver always re-opens the port in
qca_wcn3990_init() (tests with this patch set suggest this might not
be needed) and that serdev_device_open() flushes the buffer (which
seems a sane assumption). Yet given the minimal overhead I'd suggest
to not make assumptions about what happened previously in other code
and avoid the clutter of a condition that doesn't add much value.

[Bala]: will call the flush() while sending the power pulses 
irrespective of the pulse type.



Cheers

Matthias


--
Regards
Balakrishna.


Re: [PATCH v5 2/5] Bluetooth: hci_qca: Deassert RTS while baudrate change command

2018-12-26 Thread Balakrishna Godavarthi

Hi Matthias,

On 2018-12-27 01:55, Matthias Kaehlcke wrote:

Hi Balakrishna,

On Wed, Dec 26, 2018 at 11:15:30AM +0530, Balakrishna Godavarthi wrote:

Hi Matthias,

On 2018-12-22 06:01, Matthias Kaehlcke wrote:
> On Thu, Dec 20, 2018 at 08:16:36PM +0530, Balakrishna Godavarthi wrote:
> > This patch will help to stop frame reassembly errors while changing
> > the baudrate. This is because host send a change baudrate request
> > command to the chip with 115200 bps, Whereas chip will change their
> > UART clocks to the enable for new baudrate and sends the response
> > for the change request command with newer baudrate, On host side
> > we are still operating in 115200 bps which results of reading garbage
> > data. Here we are pulling RTS line, so that chip we will wait to
> > send data
> > to host until host change its baudrate.
> >
> > Signed-off-by: Balakrishna Godavarthi 
> > Tested-by: Matthias Kaehlcke 
> > Reviewed-by: Matthias Kaehlcke 
> > ---
> >  drivers/bluetooth/hci_qca.c | 24 +---
> >  1 file changed, 13 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c
> > index 5a07c2370289..1680ead6cc3d 100644
> > --- a/drivers/bluetooth/hci_qca.c
> > +++ b/drivers/bluetooth/hci_qca.c
> > @@ -963,7 +963,6 @@ static int qca_set_baudrate(struct hci_dev
> > *hdev, uint8_t baudrate)
> >   struct hci_uart *hu = hci_get_drvdata(hdev);
> >   struct qca_data *qca = hu->priv;
> >   struct sk_buff *skb;
> > - struct qca_serdev *qcadev;
> >   u8 cmd[] = { 0x01, 0x48, 0xFC, 0x01, 0x00 };
> >
> >   if (baudrate > QCA_BAUDRATE_320)
> > @@ -977,13 +976,6 @@ static int qca_set_baudrate(struct hci_dev
> > *hdev, uint8_t baudrate)
> >   return -ENOMEM;
> >   }
> >
> > - /* Disabling hardware flow control is mandatory while
> > -  * sending change baudrate request to wcn3990 SoC.
> > -  */
> > - qcadev = serdev_device_get_drvdata(hu->serdev);
> > - if (qcadev->btsoc_type == QCA_WCN3990)
> > - hci_uart_set_flow_control(hu, true);
> > -
> >   /* Assign commands to change baudrate and packet type. */
> >   skb_put_data(skb, cmd, sizeof(cmd));
> >   hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
> > @@ -999,9 +991,6 @@ static int qca_set_baudrate(struct hci_dev
> > *hdev, uint8_t baudrate)
> >   schedule_timeout(msecs_to_jiffies(BAUDRATE_SETTLE_TIMEOUT_MS));
> >   set_current_state(TASK_RUNNING);
> >
> > - if (qcadev->btsoc_type == QCA_WCN3990)
> > - hci_uart_set_flow_control(hu, false);
> > -
> >   return 0;
> >  }
> >
> > @@ -1086,6 +1075,7 @@ static int qca_check_speeds(struct hci_uart *hu)
> >  static int qca_set_speed(struct hci_uart *hu, enum qca_speed_type
> > speed_type)
> >  {
> >   unsigned int speed, qca_baudrate;
> > + struct qca_serdev *qcadev;
> >   int ret;
> >
> >   if (speed_type == QCA_INIT_SPEED) {
> > @@ -1097,6 +1087,15 @@ static int qca_set_speed(struct hci_uart *hu,
> > enum qca_speed_type speed_type)
> >   if (!speed)
> >   return 0;
> >
> > + /* Deassert RTS while changing the baudrate of chip and host.
> > +  * This will prevent chip from transmitting its response with
> > +  * the new baudrate while the host port is still operating at
> > +  * the old speed.
> > +  */
> > + qcadev = serdev_device_get_drvdata(hu->serdev);
> > + if (qcadev->btsoc_type == QCA_WCN3990)
> > + serdev_device_set_rts(hu->serdev, false);
> > +
> >   qca_baudrate = qca_get_baudrate_value(speed);
> >   bt_dev_dbg(hu->hdev, "Set UART speed to %d", speed);
> >   ret = qca_set_baudrate(hu->hdev, qca_baudrate);
> > @@ -1104,6 +1103,9 @@ static int qca_set_speed(struct hci_uart *hu,
> > enum qca_speed_type speed_type)
> >   return ret;
> >
> >   host_set_baudrate(hu, speed);
> > +
> > + if (qcadev->btsoc_type == QCA_WCN3990)
> > + serdev_device_set_rts(hu->serdev, true);
> >   }
> >
> >   return 0;
>
> I looked for ways to do without this change, but didn't find a good
> solution. There are several possible problems with baudrate changes:
>
> 1) send request to BT controller to change the baudrate
>
>   this is an asynchronous operation, the actual baudrate change can
>   be delayed for multiple reasons, e.g.:
>
>   - request sits in the BT driver's TX queue
>
> this could be worked around by checking skb_queue_empty()
>
>   - request sits in the UART buffer
>
> a workaround for this could be calling
> serdev_device_wait_until_sent() (only available with serdev though)
>
>   - the request sits in the UART FIFO
>
> will be sent out 'immediately'. no neat solution available AFAIK,
> a short sleep could be an effective workaround
>
>   - the controller may have a short delay to 

Re: [PATCHv2] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

2018-12-26 Thread Pingfan Liu
On Wed, Dec 26, 2018 at 9:47 AM Dave Young  wrote:
>
> On 12/14/18 at 12:07pm, Pingfan Liu wrote:
> > Customer reported a bug on a high end server with many pcie devices, where
> > kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> > though we still see much memory under 896 MB, the finding still failed
> > intermittently. Because currently we can only find region under 896 MB,
> > if w/0 ',high' specified. Then KASLR breaks 896 MB into several parts
> > randomly, and crashkernel reservation need be aligned to 128 MB, that's
> > why failure is found. It raises confusion to the end user that sometimes
> > crashkernel=X works while sometimes fails.
> > If want to make it succeed, customer can change kernel option to
> > "crashkernel=384M, high". Just this give "crashkernel=xx@yy" a very
> > limited space to behave even though its grammer looks more generic.
> > And we can't answer questions raised from customer that confidently:
> > 1) why it doesn't succeed to reserve 896 MB;
> > 2) what's wrong with memory region under 4G;
> > 3) why I have to add ',high', I only require 384 MB, not 3840 MB.
> >
> > This patch simplifies the method suggested in the mail [1]. It just goes
> > bottom-up to find a candidate region for crashkernel. The bottom-up may be
> > better compatible with the old reservation style, i.e. still want to get
> > memory region from 896 MB firstly, then [896 MB, 4G], finally above 4G.
> >
> > There is one trivial thing about the compatibility with old kexec-tools:
> > if the reserved region is above 896M, then old tool will fail to load
> > bzImage. But without this patch, the old tool also fail since there is no
> > memory below 896M can be reserved for crashkernel.
> >
> > [1]: http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
> > Signed-off-by: Pingfan Liu 
> > Cc: Dave Young 
> > Cc: Andrew Morton 
> > Cc: Baoquan He 
> > Cc: ying...@kernel.org,
> > Cc: vgo...@redhat.com
> > Cc: ke...@lists.infradead.org
> >
> > ---
> > v1->v2:
> >   improve commit log
> >  arch/x86/kernel/setup.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index d494b9b..60f12c4 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -541,15 +541,18 @@ static void __init reserve_crashkernel(void)
> >
> >   /* 0 means: find the address automatically */
> >   if (crash_base <= 0) {
> > + if (!memblock_bottom_up())
> > + memblock_set_bottom_up(true);
> >   /*
> >* Set CRASH_ADDR_LOW_MAX upper bound for crash memory,
> >* as old kexec-tools loads bzImage below that, unless
> >* "crashkernel=size[KMG],high" is specified.
> >*/
> >   crash_base = memblock_find_in_range(CRASH_ALIGN,
> > - high ? CRASH_ADDR_HIGH_MAX
> > -  : CRASH_ADDR_LOW_MAX,
> > - crash_size, CRASH_ALIGN);
> > + (max_pfn * PAGE_SIZE), crash_size, CRASH_ALIGN);
> > + if (!memblock_bottom_up())
> > + memblock_set_bottom_up(false);
>
> The previous memblock_set_bottom_up(true) set it as true, so
> "!memblock_bottom_up()" is impossible, not sure what is the point of
> this condition check.
>
> Do you want to restore the original memblock direction? If so a variable
> to save the old direction is needed.  But is this really necessary?
> Do you know any side effects of setting the bottom up as true?
>
Yes, will fix it.

Thanks
> > +
> >   if (!crash_base) {
> >   pr_info("crashkernel reservation failed - No suitable 
> > area found.\n");
> >   return;
> > --
> > 2.7.4
> >
> >
> > ___
> > kexec mailing list
> > ke...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
>
> Thanks
> Dave


[PATCH] sched: fix infinity loop in update_blocked_averages

2018-12-26 Thread Xie XiuQi
Zhepeng Xie report a bug, there is a infinity loop in
update_blocked_averages().

PID: 14233  TASK: 800b2de08fc0  CPU: 1   COMMAND: "docker"
 #0 [2213b9d0] update_blocked_averages at 0811e4a8
 #1 [2213ba60] pick_next_task_fair at 0812a3b4
 #2 [2213baf0] __schedule at 08deaa88
 #3 [2213bb70] schedule at 08deb1b8
 #4 [2213bb80] futex_wait_queue_me at 08180754
 #5 [2213bbd0] futex_wait at 0818192c
 #6 [2213bd00] do_futex at 08183ee4
 #7 [2213bde0] __arm64_sys_futex at 08184398
 #8 [2213be60] el0_svc_common at 080979ac
 #9 [2213bea0] el0_svc_handler at 08097a6c
 #10 [2213bff0] el0_svc at 08084044

rq->tmp_alone_branch introduced in 4.10, used to point to
the new beg of the list. If this cfs_rq is deleted somewhere
else, then the tmp_alone_branch will be illegal and cause
a list_add corruption.

(When enabled DEBUG_LIST, we fould this list_add corruption)

[ 2546.741103] list_add corruption. next->prev should be prev
(800b4d61ad40), but was 800ba434fa38. (next=800b6a95e740).
[ 2546.741130] [ cut here ]
[ 2546.741132] kernel BUG at lib/list_debug.c:25!
[ 2546.741136] Internal error: Oops - BUG: 0 [#1] SMP
[ 2546.742870] CPU: 1 PID: 29428 Comm: docker-runc Kdump: loaded Tainted: G E  
4.19.5-1.aarch64 #1
[ 2546.745415] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
[ 2546.747402] pstate: 4085 (nZcv daIf -PAN -UAO)
[ 2546.749015] pc : __list_add_valid+0x50/0x90
[ 2546.750485] lr : __list_add_valid+0x50/0x90
[ 2546.751975] sp : 1b5eb910
[ 2546.753286] x29: 1b5eb910 x28: 800abacf
[ 2546.754976] x27: 1b5ebbb0 x26: 0957
[ 2546.756665] x25: 0960d000 x24: 0250f41ca8f8
[ 2546.758366] x23: 800b6a95e740 x22: 800b4d61ad40
[ 2546.760066] x21: 800b4d61ad40 x20: 800ba434f080
[ 2546.761742] x19: 800b4d61ac00 x18: 
[ 2546.763425] x17:  x16: 
[ 2546.765089] x15: 09570748 x14: 662073617720
[ 2546.766755] x13: 747562202c293034 x12: 6461313664346230
[ 2546.768429] x11: 30382820 x10: 
[ 2546.770124] x9 : 0001 x8 : 09f34a0f
[ 2546.771831] x7 :  x6 : 250d
[ 2546.773525] x5 :  x4 : 
[ 2546.775227] x3 :  x2 : 70ef7f624013ca00
[ 2546.776929] x1 :  x0 : 0075
[ 2546.778623] Process docker-runc (pid: 29428, stack limit = 
0x293494a2)
[ 2546.780742] Call trace:
[ 2546.781955]  __list_add_valid+0x50/0x90
[ 2546.783469]  enqueue_entity+0x4a0/0x6e8
[ 2546.784957]  enqueue_task_fair+0xac/0x610
[ 2546.786502]  sched_move_task+0x134/0x178
[ 2546.787993]  cpu_cgroup_attach+0x40/0x78
[ 2546.789540]  cgroup_migrate_execute+0x378/0x3a8
[ 2546.791169]  cgroup_migrate+0x6c/0x90
[ 2546.792663]  cgroup_attach_task+0x148/0x238
[ 2546.794211]  __cgroup1_procs_write.isra.2+0xf8/0x160
[ 2546.795935]  cgroup1_procs_write+0x38/0x48
[ 2546.797492]  cgroup_file_write+0xa0/0x170
[ 2546.799010]  kernfs_fop_write+0x114/0x1e0
[ 2546.800558]  __vfs_write+0x60/0x190
[ 2546.801977]  vfs_write+0xac/0x1c0
[ 2546.803341]  ksys_write+0x6c/0xd8
[ 2546.804674]  __arm64_sys_write+0x24/0x30
[ 2546.806146]  el0_svc_common+0x78/0x100
[ 2546.807584]  el0_svc_handler+0x38/0x88
[ 2546.809017]  el0_svc+0x8/0xc

In this patch, we move rq->tmp_alone_branch point to its prev before delete it
from list.

Reported-by: Zhipeng Xie 
Cc: Bin Li 
Cc: [4.10+]
Fixes: 9c2791f936ef (sched/fair: Fix hierarchical order in rq->leaf_cfs_rq_list)
Signed-off-by: Xie XiuQi 
Tested-by: Zhipeng Xie 
---
 kernel/sched/fair.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index ac855b2..7a72702 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -347,6 +347,11 @@ static inline void list_add_leaf_cfs_rq(struct cfs_rq 
*cfs_rq)
 static inline void list_del_leaf_cfs_rq(struct cfs_rq *cfs_rq)
 {
if (cfs_rq->on_list) {
+   struct rq *rq = rq_of(cfs_rq);
+
+   if (rq->tmp_alone_branch == _rq->leaf_cfs_rq_list)
+   rq->tmp_alone_branch = cfs_rq->leaf_cfs_rq_list.prev;
+
list_del_rcu(_rq->leaf_cfs_rq_list);
cfs_rq->on_list = 0;
}
-- 
1.8.3.1



Re: [PATCHv2] x86/kdump: bugfix, make the behavior of crashkernel=X consistent with kaslr

2018-12-26 Thread Pingfan Liu
On Wed, Dec 26, 2018 at 9:58 AM Dave Young  wrote:
>
> On 12/14/18 at 12:07pm, Pingfan Liu wrote:
> > Customer reported a bug on a high end server with many pcie devices, where
> > kernel bootup with crashkernel=384M, and kaslr is enabled. Even
> > though we still see much memory under 896 MB, the finding still failed
> > intermittently. Because currently we can only find region under 896 MB,
> > if w/0 ',high' specified. Then KASLR breaks 896 MB into several parts
> > randomly, and crashkernel reservation need be aligned to 128 MB, that's
> > why failure is found. It raises confusion to the end user that sometimes
> > crashkernel=X works while sometimes fails.
> > If want to make it succeed, customer can change kernel option to
> > "crashkernel=384M, high". Just this give "crashkernel=xx@yy" a very
> > limited space to behave even though its grammer looks more generic.
> > And we can't answer questions raised from customer that confidently:
> > 1) why it doesn't succeed to reserve 896 MB;
> > 2) what's wrong with memory region under 4G;
> > 3) why I have to add ',high', I only require 384 MB, not 3840 MB.
> >
> > This patch simplifies the method suggested in the mail [1]. It just goes
> > bottom-up to find a candidate region for crashkernel. The bottom-up may be
> > better compatible with the old reservation style, i.e. still want to get
> > memory region from 896 MB firstly, then [896 MB, 4G], finally above 4G.
> >
> > There is one trivial thing about the compatibility with old kexec-tools:
> > if the reserved region is above 896M, then old tool will fail to load
> > bzImage. But without this patch, the old tool also fail since there is no
> > memory below 896M can be reserved for crashkernel.
> >
> > [1]: http://lists.infradead.org/pipermail/kexec/2017-October/019571.html
> > Signed-off-by: Pingfan Liu 
> > Cc: Dave Young 
> > Cc: Andrew Morton 
> > Cc: Baoquan He 
> > Cc: ying...@kernel.org,
> > Cc: vgo...@redhat.com
> > Cc: ke...@lists.infradead.org
> >
> > ---
> > v1->v2:
> >   improve commit log
> >  arch/x86/kernel/setup.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> > index d494b9b..60f12c4 100644
> > --- a/arch/x86/kernel/setup.c
> > +++ b/arch/x86/kernel/setup.c
> > @@ -541,15 +541,18 @@ static void __init reserve_crashkernel(void)
> >
> >   /* 0 means: find the address automatically */
> >   if (crash_base <= 0) {
> > + if (!memblock_bottom_up())
> > + memblock_set_bottom_up(true);
>
> Looking at the memblock_find_in_range_node code, it is allocating
> bottom up in case bottom_up is true, but it will try to allocate above
> kernel_end:
>
> bottom_up_start = max(start, kernel_end);
>
> If kernel lives very high eg. KASLR case, then this bottom up way does
> not help.  So probably previous old version to try 896M first then 4G
> then maxmem is better.
>
Yes, you are right. I will try to see whether it can be resolved or not.

Thanks,
Pingfan

> >   /*
> >* Set CRASH_ADDR_LOW_MAX upper bound for crash memory,
> >* as old kexec-tools loads bzImage below that, unless
> >* "crashkernel=size[KMG],high" is specified.
> >*/
> >   crash_base = memblock_find_in_range(CRASH_ALIGN,
> > - high ? CRASH_ADDR_HIGH_MAX
> > -  : CRASH_ADDR_LOW_MAX,
> > - crash_size, CRASH_ALIGN);
> > + (max_pfn * PAGE_SIZE), crash_size, CRASH_ALIGN);
> > + if (!memblock_bottom_up())
> > + memblock_set_bottom_up(false);
> > +
> >   if (!crash_base) {
> >   pr_info("crashkernel reservation failed - No suitable 
> > area found.\n");
> >   return;
> > --
> > 2.7.4
> >


Re: [GIT PULL] x86/cleanups for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Tue, 25 Dec 2018 00:00:33 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> x86-cleanups-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/312a466155108329c458049dc76a21ad56106960

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/boot changes for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Mon, 24 Dec 2018 23:55:00 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-boot-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9a126e788af8e0754d5d19cd98b3a2bc1711ff46

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/cpu changes for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Tue, 25 Dec 2018 00:03:57 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cpu-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/db2ab474c4a434872e1794c2af8b2e561caa756e

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/platform change for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Tue, 25 Dec 2018 00:12:47 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> x86-platform-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc2fd5f0f1aa85925be2322275ee2dc5ac3acdf4

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/build changes for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Mon, 24 Dec 2018 23:58:31 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-build-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6e54df001ac9262e3b78b34b87390fcb54677a0d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/amd-nb changes for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Mon, 24 Dec 2018 23:50:04 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-amd-nb-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8465625ab4700e3e1db506ed8a541f7796356d63

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/asm changes for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Mon, 24 Dec 2018 23:53:47 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-asm-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/38fabca18fc4c832ea95e2d14fb1ecde8b7dcc56

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/mm changes for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Tue, 25 Dec 2018 00:11:06 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e57d9f638af9673f38d9f09de66fa0a28303127d

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [GIT PULL] x86/fpu changes for v4.21

2018-12-26 Thread pr-tracker-bot
The pull request you sent on Tue, 25 Dec 2018 00:07:10 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-fpu-for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d6e867a6ae13bc02cd01c535764e5b051d26cf28

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker


Re: [PATCH] zram: idle writeback fixes and cleanup

2018-12-26 Thread Sergey Senozhatsky
On (12/24/18 12:35), Minchan Kim wrote:
[..]
> @@ -645,10 +680,13 @@ static ssize_t writeback_store(struct device *dev,
>   bvec.bv_len = PAGE_SIZE;
>   bvec.bv_offset = 0;
>  
> - if (zram->stop_writeback) {
> + spin_lock(>wb_limit_lock);
> + if (zram->wb_limit_enable && !zram->bd_wb_limit) {
> + spin_unlock(>wb_limit_lock);
>   ret = -EIO;
>   break;
>   }
> + spin_unlock(>wb_limit_lock);
[..]
> @@ -732,11 +771,10 @@ static ssize_t writeback_store(struct device *dev,
>   zram_set_element(zram, index, blk_idx);
>   blk_idx = 0;
>   atomic64_inc(>stats.pages_stored);
> - if (atomic64_add_unless(>stats.bd_wb_limit,
> - -1 << (PAGE_SHIFT - 12), 0)) {
> - if (atomic64_read(>stats.bd_wb_limit) == 0)
> - zram->stop_writeback = true;
> - }
> + spin_lock(>wb_limit_lock);
> + if (zram->wb_limit_enable && zram->bd_wb_limit > 0)
> + zram->bd_wb_limit -=  1UL << (PAGE_SHIFT - 12);
> + spin_unlock(>wb_limit_lock);

Do we really need ->wb_limit_lock spinlock? We kinda punch it twice
in this loop. If someone clears ->wb_limit_enable somewhere in between
then the worst thing to happen is that we will just write extra page
to the backing device; not a very big deal to me. Am I missing
something?

-ss


[PATCH] gdrom: fix a memory leak bug

2018-12-26 Thread Wenwen Wang
In probe_gdrom(), the buffer pointed by 'gd.cd_info' is allocated through
kzalloc() and is used to hold the information of the gdrom device. To
register and unregister the device, the pointer 'gd.cd_info' is passed to
the functions register_cdrom() and unregister_cdrom(), respectively.
However, this buffer is not freed after it is used, which can cause a
memory leak bug.

This patch simply frees the buffer 'gd.cd_info' in exit_gdrom() to fix the
above issue.

Signed-off-by: Wenwen Wang 
---
 drivers/cdrom/gdrom.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c
index a5b8afe..f8b7345 100644
--- a/drivers/cdrom/gdrom.c
+++ b/drivers/cdrom/gdrom.c
@@ -873,6 +873,7 @@ static void __exit exit_gdrom(void)
platform_device_unregister(pd);
platform_driver_unregister(_driver);
kfree(gd.toc);
+   kfree(gd.cd_info);
 }
 
 module_init(init_gdrom);
-- 
2.7.4



[PATCH v2] net: arcnet: Fix a possible concurrency use-after-free bug in arcnet_reply_tasklet()

2018-12-26 Thread Jia-Ju Bai
In drivers/net/arcnet/arcnet.c, the functions arcnet_reply_tasklet() and
arcnet_send_packet() may be concurrently executed.

arcnet_reply_tasklet()
  line 430: dev_kfree_skb(lp->outgoing.skb);

arcnet_send_packet()
  line 682: spin_lock_irqsave();
  line 690: lp->outgoing.skb = skb;
  line 691: proto->prepare_tx(..., skb->len, ...)

Thus, a possible concurrency use-after-free bugs may occur.

To fix this bug, the calls to spin_lock_irqsave() and
spin_unlock_irqrestore() are added in arcnet_reply_tasklet() to protect
dev_kfree_skb(lp->outgoing.skb).


Signed-off-by: Jia-Ju Bai 
---
v2:
* Add the definition of flags to fix the compilation error.
---
 drivers/net/arcnet/arcnet.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c
index 8459115d9d4e..1e1b12650964 100644
--- a/drivers/net/arcnet/arcnet.c
+++ b/drivers/net/arcnet/arcnet.c
@@ -401,6 +401,7 @@ static void arcnet_reply_tasklet(unsigned long data)
struct sock_exterr_skb *serr;
struct sock *sk;
int ret;
+   unsigned long flags;
 
local_irq_disable();
skb = lp->outgoing.skb;
@@ -426,10 +427,14 @@ static void arcnet_reply_tasklet(unsigned long data)
serr->ee.ee_data = skb_shinfo(skb)->tskey;
serr->ee.ee_info = lp->reply_status;
 
+   spin_lock_irqsave(>lock, flags);
+
/* finally erasing outgoing skb */
dev_kfree_skb(lp->outgoing.skb);
lp->outgoing.skb = NULL;
 
+   spin_unlock_irqrestore(>lock, flags);
+
ackskb->dev = lp->dev;
 
ret = sock_queue_err_skb(sk, ackskb);
-- 
2.17.0



[PATCH 2/2] blk-mq: save default hctx into ctx->hctxs for not-supported type

2018-12-26 Thread Jianchao Wang
Currently, we check whether the hctx type is supported every time
in hot path. Actually, this is not necessary, we could save the
default hctx into ctx->hctxs if the type is not supported when
map swqueues and use it directly with ctx->hctxs[type].

We also needn't check whether the poll is enabled or not, because
the caller would clear the REQ_HIPRI in that case.

Signed-off-by: Jianchao Wang 
---
 block/blk-mq.c |  9 -
 block/blk-mq.h | 15 ++-
 2 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 6898d24..1dab467 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2430,8 +2430,11 @@ static void blk_mq_map_swqueue(struct request_queue *q)
 
ctx = per_cpu_ptr(q->queue_ctx, i);
for (j = 0; j < set->nr_maps; j++) {
-   if (!set->map[j].nr_queues)
+   if (!set->map[j].nr_queues) {
+   ctx->hctxs[j] = blk_mq_map_queue_type(q,
+   HCTX_TYPE_DEFAULT, i);
continue;
+   }
 
hctx = blk_mq_map_queue_type(q, j, i);
ctx->hctxs[j] = hctx;
@@ -2454,6 +2457,10 @@ static void blk_mq_map_swqueue(struct request_queue *q)
 */
BUG_ON(!hctx->nr_ctx);
}
+
+   for (; j < HCTX_MAX_TYPES; j++)
+   ctx->hctxs[j] = blk_mq_map_queue_type(q,
+   HCTX_TYPE_DEFAULT, i);
}
 
mutex_unlock(>sysfs_lock);
diff --git a/block/blk-mq.h b/block/blk-mq.h
index 998f5cf..ed1ed45 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -98,7 +98,7 @@ static inline struct blk_mq_hw_ctx 
*blk_mq_map_queue_type(struct request_queue *
  * blk_mq_map_queue() - map (cmd_flags,type) to hardware queue
  * @q: request queue
  * @flags: request command flags
- * @cpu: CPU
+ * @ctx: mq cpu ctx
  */
 static inline struct blk_mq_hw_ctx *blk_mq_map_queue(struct request_queue *q,
 unsigned int flags,
@@ -106,15 +106,12 @@ static inline struct blk_mq_hw_ctx 
*blk_mq_map_queue(struct request_queue *q,
 {
enum hctx_type type = HCTX_TYPE_DEFAULT;
 
-   if ((flags & REQ_HIPRI) &&
-   q->tag_set->nr_maps > HCTX_TYPE_POLL && 
-   q->tag_set->map[HCTX_TYPE_POLL].nr_queues &&
-   test_bit(QUEUE_FLAG_POLL, >queue_flags))
+   /*
+* The caller ensure that if REQ_HIPRI, poll must be enabled.
+*/
+   if (flags & REQ_HIPRI)
type = HCTX_TYPE_POLL;
-
-   else if (((flags & REQ_OP_MASK) == REQ_OP_READ) &&
-q->tag_set->nr_maps > HCTX_TYPE_READ &&
-q->tag_set->map[HCTX_TYPE_READ].nr_queues)
+   else if ((flags & REQ_OP_MASK) == REQ_OP_READ)
type = HCTX_TYPE_READ;

return ctx->hctxs[type];
-- 
2.7.4



[PATCH 0/2] blk-mq: small optimization for accessing of queue map

2018-12-26 Thread Jianchao Wang
Hi Jens

These two patches are small optimization for accessing the queue mapping
in hot path. It saves the queue mapping results into blk_mq_ctx directly,
then we needn't do the complicated bounce on queue_hw_ctx[] map[] and
mq_map[].

Jianchao Wang(2)
  blk-mq: save queue mapping result into ctx directly
  blk-mq: save default hctx into ctx->hctxs for not-supported type

block/blk-mq-sched.c |  2 +-
block/blk-mq-tag.c   |  2 +-
block/blk-mq.c   | 13 ++---
block/blk-mq.h   | 20 +---
block/blk.h  |  2 +-
5 files changed, 22 insertions(+), 17 deletions(-)

Thanks
Jianchao
 


[PATCH 1/2] blk-mq: save queue mapping result into ctx directly

2018-12-26 Thread Jianchao Wang
Currelty, the queue mapping result is saved in a two-dimensional
array. In hot path, to get a hctx, we need do following,

  q->queue_hw_ctx[q->tag_set->map[type].mq_map[cpu]]

This looks not efficient. Actually, we could save the queue mapping
result into ctx directly with different hctx type, like,

  ctx->hctxs[type]

Signed-off-by: Jianchao Wang 
---
 block/blk-mq-sched.c | 2 +-
 block/blk-mq-tag.c   | 2 +-
 block/blk-mq.c   | 4 ++--
 block/blk-mq.h   | 5 +++--
 block/blk.h  | 2 +-
 5 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/block/blk-mq-sched.c b/block/blk-mq-sched.c
index 140933e..4090553 100644
--- a/block/blk-mq-sched.c
+++ b/block/blk-mq-sched.c
@@ -321,7 +321,7 @@ bool __blk_mq_sched_bio_merge(struct request_queue *q, 
struct bio *bio)
 {
struct elevator_queue *e = q->elevator;
struct blk_mq_ctx *ctx = blk_mq_get_ctx(q);
-   struct blk_mq_hw_ctx *hctx = blk_mq_map_queue(q, bio->bi_opf, ctx->cpu);
+   struct blk_mq_hw_ctx *hctx = blk_mq_map_queue(q, bio->bi_opf, ctx);
bool ret = false;
enum hctx_type type;
 
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 2089c6c..a4931fc 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -170,7 +170,7 @@ unsigned int blk_mq_get_tag(struct blk_mq_alloc_data *data)
 
data->ctx = blk_mq_get_ctx(data->q);
data->hctx = blk_mq_map_queue(data->q, data->cmd_flags,
-   data->ctx->cpu);
+   data->ctx);
tags = blk_mq_tags_from_data(data);
if (data->flags & BLK_MQ_REQ_RESERVED)
bt = >breserved_tags;
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 3ba37b9..6898d24 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -364,7 +364,7 @@ static struct request *blk_mq_get_request(struct 
request_queue *q,
}
if (likely(!data->hctx))
data->hctx = blk_mq_map_queue(q, data->cmd_flags,
-   data->ctx->cpu);
+   data->ctx);
if (data->cmd_flags & REQ_NOWAIT)
data->flags |= BLK_MQ_REQ_NOWAIT;
 
@@ -2434,7 +2434,7 @@ static void blk_mq_map_swqueue(struct request_queue *q)
continue;
 
hctx = blk_mq_map_queue_type(q, j, i);
-
+   ctx->hctxs[j] = hctx;
/*
 * If the CPU is already set in the mask, then we've
 * mapped this one already. This can happen if
diff --git a/block/blk-mq.h b/block/blk-mq.h
index d943d46..998f5cf 100644
--- a/block/blk-mq.h
+++ b/block/blk-mq.h
@@ -23,6 +23,7 @@ struct blk_mq_ctx {
 
unsigned intcpu;
unsigned short  index_hw[HCTX_MAX_TYPES];
+   struct blk_mq_hw_ctx *hctxs[HCTX_MAX_TYPES];
 
/* incremented at dispatch time */
unsigned long   rq_dispatched[2];
@@ -101,7 +102,7 @@ static inline struct blk_mq_hw_ctx 
*blk_mq_map_queue_type(struct request_queue *
  */
 static inline struct blk_mq_hw_ctx *blk_mq_map_queue(struct request_queue *q,
 unsigned int flags,
-unsigned int cpu)
+struct blk_mq_ctx *ctx)
 {
enum hctx_type type = HCTX_TYPE_DEFAULT;
 
@@ -116,7 +117,7 @@ static inline struct blk_mq_hw_ctx *blk_mq_map_queue(struct 
request_queue *q,
 q->tag_set->map[HCTX_TYPE_READ].nr_queues)
type = HCTX_TYPE_READ;

-   return blk_mq_map_queue_type(q, type, cpu);
+   return ctx->hctxs[type];
 }
 
 /*
diff --git a/block/blk.h b/block/blk.h
index 848278c..5d636ee 100644
--- a/block/blk.h
+++ b/block/blk.h
@@ -38,7 +38,7 @@ extern struct ida blk_queue_ida;
 static inline struct blk_flush_queue *
 blk_get_flush_queue(struct request_queue *q, struct blk_mq_ctx *ctx)
 {
-   return blk_mq_map_queue(q, REQ_OP_FLUSH, ctx->cpu)->fq;
+   return blk_mq_map_queue(q, REQ_OP_FLUSH, ctx)->fq;
 }
 
 static inline void __blk_get_queue(struct request_queue *q)
-- 
2.7.4



Re: [PATCH 11/18] drm/medaitek: add layer_nr for ovl private data

2018-12-26 Thread CK Hu
Hi, Yongqiang:

On Mon, 2018-12-24 at 16:08 +0800, Yongqiang Niu wrote:
> This patch add layer_nr for ovl private data
> 

I think you do this because ovl-2l and ovl share the same driver and the
ovl layer is different, so this patch is a preparation for ovl-2l and
ovl share the same driver. Describe more information for this patch.

Regards,
CK

> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index afb313c..a0ab760 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -60,6 +60,7 @@
>  struct mtk_disp_ovl_data {
>   unsigned int addr;
>   unsigned int gmc_bits;
> + unsigned int layer_nr;
>   bool fmt_rgb565_is_0;
>  };
>  
> @@ -137,7 +138,9 @@ static void mtk_ovl_config(struct mtk_ddp_comp *comp, 
> unsigned int w,
>  
>  static unsigned int mtk_ovl_layer_nr(struct mtk_ddp_comp *comp)
>  {
> - return 4;
> + struct mtk_disp_ovl *ovl = comp_to_ovl(comp);
> +
> + return ovl->data->layer_nr;
>  }
>  
>  static void mtk_ovl_layer_on(struct mtk_ddp_comp *comp, unsigned int idx)
> @@ -342,12 +345,14 @@ static int mtk_disp_ovl_remove(struct platform_device 
> *pdev)
>  static const struct mtk_disp_ovl_data mt2701_ovl_driver_data = {
>   .addr = DISP_REG_OVL_ADDR_MT2701,
>   .gmc_bits = 8,
> + .layer_nr = 4,
>   .fmt_rgb565_is_0 = false,
>  };
>  
>  static const struct mtk_disp_ovl_data mt8173_ovl_driver_data = {
>   .addr = DISP_REG_OVL_ADDR_MT8173,
>   .gmc_bits = 8,
> + .layer_nr = 4,
>   .fmt_rgb565_is_0 = true,
>  };
>  




Re: Crypto Update for 4.21

2018-12-26 Thread Herbert Xu
On Wed, Dec 26, 2018 at 10:49:08AM -0600, Eric Biggers wrote:
> On Wed, Dec 26, 2018 at 09:22:57PM +0800, Herbert Xu wrote:
> > 
> > Please pull from
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
> > 
> 
> Hi Herbert, that branch is still on an old commit.  Probably you forgot to 
> push.

Thanks Eric, it should be right now.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [RFC PATCH] media: rcar-vin: Allow independent VIN link enablement

2018-12-26 Thread Niklas Söderlund
Hi Steve,

Thanks for your patch.

On 2018-12-25 15:27:25 -0800, Steve Longerbeam wrote:
> There is a block of code in rvin_group_link_notify() that prevents
> enabling a link to a VIN node if any entity in the media graph is
> in use. This prevents enabling a VIN link even if there is an in-use
> entity somewhere in the graph that is independent of the link's
> pipeline.
> 
> For example, the code block will prevent enabling a link from
> the first rcar-csi2 receiver to a VIN node even if there is an
> enabled link somewhere far upstream on the second independent
> rcar-csi2 receiver pipeline.

Unfortunately this is by design and needed due to the hardware design.  
The different VIN endpoints shares a configuration register which 
controls the routing from the CSI-2 receivers to the VIN (register name 
CHSEL). Modifying the CHSEL register which is what happens when a link 
is enabled/disabled can have side effects on running streams even if 
they are not shown to be dependent in the media graph.

There is a CHSEL register in VIN0 which controls the routing from all 
CSI-2 receivers to VIN0-3 and a CHSEL register in VIN4 which controls 
the same for VIN4-7.

> 
> If this code block is meant to prevent modifying a link if the
> link is actively involved in streaming, there is already such a
> check in __media_entity_setup_link() that verifies the stream_count
> of the link's source and sink entities are both zero.

For the reason above the check in __media_entity_setup_link() is not 
enough :-( This register sharing is my least favorite thing about the 
VIN on Gen3 and forces the driver to become more complex as all VIN 
instances needs to know about each other and interact.

> 
> Remove the code block so that VIN node links can be enabled even if
> there are other independent in-use entities.

There is room for some improvement in this area disregarding the odd 
hardware design. It *could* be allowed to change a link terminating in  
VIN4-7 even if there is a stream running for one or more in VIN0-3.

I would be interested to test such a patch but to allow any link change 
which is allowed by __media_entity_setup_link() is unfortunately not 
possible, as I understand it. Maybe someone more clever then me can find 
ways to unlock even more then just the split between VIN0-3 and VIn4-7.

In essence the CHSEL register can not be changed if it's involved in a 
running pipeline even if the end result would be that the running 
pipeline would look the same. This is possible as there are multiple 
CHSEL settings where the same source is connected to a specific VIN 
while other members of the "subgroup of VINs" (e.g. VIN0-3) is routed to 
something else for the two CHSEL settings.

> 
> Fixes: c0cc5aef31 ("media: rcar-vin: add link notify for Gen3")
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/media/platform/rcar-vin/rcar-core.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c 
> b/drivers/media/platform/rcar-vin/rcar-core.c
> index f0719ce24b97..b2c9a876969e 100644
> --- a/drivers/media/platform/rcar-vin/rcar-core.c
> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
> @@ -116,7 +116,6 @@ static int rvin_group_link_notify(struct media_link 
> *link, u32 flags,
>   struct rvin_group, mdev);
>   unsigned int master_id, channel, mask_new, i;
>   unsigned int mask = ~0;
> - struct media_entity *entity;
>   struct video_device *vdev;
>   struct media_pad *csi_pad;
>   struct rvin_dev *vin = NULL;
> @@ -131,11 +130,6 @@ static int rvin_group_link_notify(struct media_link 
> *link, u32 flags,
>   !is_media_entity_v4l2_video_device(link->sink->entity))
>   return 0;
>  
> - /* If any entity is in use don't allow link changes. */
> - media_device_for_each_entity(entity, >mdev)
> - if (entity->use_count)
> - return -EBUSY;
> -
>   mutex_lock(>lock);
>  
>   /* Find the master VIN that controls the routes. */
> -- 
> 2.17.1
> 

-- 
Regards,
Niklas Söderlund


[PATCH] kvm:arm/arm64: vgic: remove unnecessary semicolon

2018-12-26 Thread Peng Hao
Remove unnecessary semicolon in vgic_put_irq.

Signed-off-by: Peng Hao 
---
 virt/kvm/arm/vgic/vgic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
index 7cfdfbc..f9ff5c7 100644
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -142,7 +142,7 @@ void vgic_put_irq(struct kvm *kvm, struct vgic_irq *irq)
if (!kref_put(>refcount, vgic_irq_release)) {
spin_unlock_irqrestore(>lpi_list_lock, flags);
return;
-   };
+   }
 
list_del(>lpi_list);
dist->lpi_list_count--;
-- 
1.8.3.1



[PATCH] kvm: arm/arm64 : vgic: remove unneeded semicolon

2018-12-26 Thread Peng Hao
Remove unneeded semicolon in kvm_vgic_hyp_init.

Signed-off-by: Peng Hao 
---
 virt/kvm/arm/vgic/vgic-init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/virt/kvm/arm/vgic/vgic-init.c b/virt/kvm/arm/vgic/vgic-init.c
index c0c0b88..3496155 100644
--- a/virt/kvm/arm/vgic/vgic-init.c
+++ b/virt/kvm/arm/vgic/vgic-init.c
@@ -510,7 +510,7 @@ int kvm_vgic_hyp_init(void)
break;
default:
ret = -ENODEV;
-   };
+   }
 
if (ret)
return ret;
-- 
1.8.3.1



RE: [PATCH v2] usb: chipidea: add a check for the availability of next child

2018-12-26 Thread Peter Chen
 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/usb/chipidea/ci_hdrc_msm.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
> b/drivers/usb/chipidea/ci_hdrc_msm.c
> index 880009987460..b7f7acef72d4 100644
> --- a/drivers/usb/chipidea/ci_hdrc_msm.c
> +++ b/drivers/usb/chipidea/ci_hdrc_msm.c
> @@ -250,6 +250,10 @@ static int ci_hdrc_msm_probe(struct platform_device
> *pdev)
>   ulpi_node = of_get_child_by_name(pdev->dev.of_node, "ulpi");
>   if (ulpi_node) {
>   phy_node = of_get_next_available_child(ulpi_node, NULL);
> + if (!phy_node) {
> + dev_err(>dev, "no child nodes found\n");
> + return -ENODEV;
> + }

There are still two issues for this patch:
- It can't return -ENODEV directly, instead, it needs to goto err_mux
- Before goto err_mux, it needs to call of_node_put(ulpi_node);

Besides, for kernel code style, you may leave one blank line after if () {} 
statement.

Peter

>   ci->hsic = of_device_is_compatible(phy_node, 
> "qcom,usb-hsic-phy");
>   of_node_put(phy_node);
>   }
> --
> 2.17.2 (Apple Git-113)



Re: [PATCH V2] SelfTest: KVM: Drop Asserts for madvise MADV_NOHUGEPAGE failure

2018-12-26 Thread shuah

Hi Paolo,

On 12/24/18 7:56 AM, Ahmed Soliman wrote:

Kind reminder to merge my patch into next

thanks.



I am assuming you will be picking this patch up. Please let me know if 
you want me to take it through kselftest tree.


thanks,
-- Shuah



[git pull] drm next leftovers for rc1

2018-12-26 Thread Dave Airlie
Hi Linus,

Daniel collected a couple of pulls after I want on holidays, back for
a couple of days, so may as well send them out.

This has exynos and etnaviv work for 4.21.

exynos:
- plane alpha and blending configurability

etnaviv:
- mostly cleanups in prep for new features.

Dave.

drm-next-2018-12-27:
drm etnaviv and exynos for rc1
The following changes since commit 2a3c83f5fe0770d13bbb71b23674886ff4111f44:

  Merge tag 'vmwgfx-next-2018-12-13' of
git://people.freedesktop.org/~thomash/linux into drm-next (2018-12-14
04:57:45 +1000)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm tags/drm-next-2018-12-27

for you to fetch changes up to 221b35fedee1b38b9cee99320f0c60263d229e14:

  Merge branch 'etnaviv/next' of
https://git.pengutronix.de/git/lst/linux into drm-next (2018-12-18
14:24:52 +0100)


drm etnaviv and exynos for rc1


Christoph Manszewski (2):
  drm/exynos: fimd: Make plane alpha configurable
  drm/exynos: fimd: Make pixel blend mode configurable

Daniel Vetter (2):
  Merge tag 'exynos-drm-next-for-v4.21-v2' of
git://git.kernel.org/.../daeinki/drm-exynos into drm-next
  Merge branch 'etnaviv/next' of
https://git.pengutronix.de/git/lst/linux into drm-next

Lucas Stach (5):
  drm/etnaviv: kill active fence tracking
  drm/etnaviv: consolidate hardware fence handling in etnaviv_gpu
  drm/etnaviv: remove unnecessary local irq disable
  drm/etnaviv: replace header include with forward declaration
  drm/etnaviv: remove lastctx member from gpu struct

Thomas Zimmermann (1):
  drm/etnaviv: Replace drm_dev_unref with drm_dev_put

 drivers/gpu/drm/etnaviv/etnaviv_buffer.c |   2 -
 drivers/gpu/drm/etnaviv/etnaviv_drv.c|  12 +--
 drivers/gpu/drm/etnaviv/etnaviv_drv.h|  11 ---
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c|  37 --
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h|  12 +--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 123 +--
 include/video/samsung_fimd.h |  10 +++
 7 files changed, 131 insertions(+), 76 deletions(-)


[PATCH v15] i2c: Add drivers for the AMD PCIe MP2 I2C controller

2018-12-26 Thread Elie Morisse
MP2 controllers have two separate busses, so may accommodate up to two I2C
adapters. Those adapters are listed in the ACPI namespace with the
"AMDI0011" HID, and probed by a platform driver.

Communication with the MP2 takes place through MMIO registers, or through
DMA for more than 32 bytes transfers.

This is major rework of the patch submitted by Nehal-bakulchandra Shah from
AMD (https://patchwork.kernel.org/patch/10597369/).

Most of the event handling of v3 was rewritten to make it work with more
than one bus (e.g on Ryzen-based Lenovo Yoga 530), and this version
contains many other improvements.

Signed-off-by: Elie Morisse 
---
Changes since v1 (https://www.spinics.net/lists/linux-i2c/msg34650.html):
-> Add fix for IOMMU
-> Add dependency of ACPI
-> Add locks to avoid the crash

Changes since v2 (https://patchwork.ozlabs.org/patch/961270/):

-> fix for review comments
-> fix for more than 32 bytes write issue

Changes since v3 (https://patchwork.kernel.org/patch/10597369/) by Elie M.:

-> support more than one bus/adapter
-> support more than one slave per bus
-> use the bus speed specified by the slaves declared in the DSDT instead of
   assuming speed == 400kbits/s
-> instead of kzalloc'ing a buffer for every less than 32 bytes reads, simply
   use i2c_msg.buf
-> fix buffer overreads/overflows when (<=32 bytes) message lengths aren't a
   multiple of 4 by using memcpy_fromio and memcpy_toio
-> use streaming DMA mappings instead of allocating a coherent DMA buffer for
   every >32 bytes read/write
-> properly check for timeouts during i2c_amd_xfer and increase it from 50
   jiffies to 250 msecs (which is more in line with other drivers)
-> complete amd_i2c_dev.msg even if the device doesn't return a xxx_success
   event, instead of stalling i2c_amd_xfer
-> removed the spinlock and mdelay during i2c_amd_pci_configure, I didn't see
   the point since it's already waiting for a i2c_busenable_complete event
-> add an adapter-specific mutex lock for i2c_amd_xfer, since we don't want
   parallel calls writing to AMD_C2P_MSG0 (or AMD_C2P_MSG1)
-> add a global mutex lock for registers AMD_C2P_MSG2 to AMD_C2P_MSG9,  which
   are shared across the two busses/adapters
-> add MODULE_DEVICE_TABLE to automatically load i2c-amd-platdrv if the DSDT
   enumerates devices with the "AMDI0011" HID
-> set maximum length of reads/writes to 4095 (event's length field is 12 bits)
-> basic PM support
-> style corrections to match the kernel code style, and tried to reduce code
   duplication whenever possible

Changes since v4 by Elie M.:

-> fix missing typecast warning
-> removed the duplicated entry in Kconfig

Changes since v5 by Elie M.:

-> move DMA mapping from the platform driver to the PCI driver
-> attempt to find the platform device's PCI parent through the _DEP ACPI method
   (if not found take the first MP2 device registred in the i2c-amd-pci-mp2
   driver, like before)
-> do not assume anymore that the PCI device is owned by the i2c-amd-pci-mp2
   driver
-> address other review comments by Bjorn Helgaas (meant for v3)

Changes since v6 by Elie M.:

-> remove unnecessary memcpy from the DMA buffer during i2c_amd_read_completion

Changes since v7 by Elie M.:

-> merge the two modules into one named i2c-amd-mp2, delete now useless exports
-> unlock the C2P mutex if i2c_amd_xfer_msg timeouts, to prevent stalling the
   MP2 controller if a slave doesn't respond to a read or write request
-> unmap the DMA buffer before read/write_complete
-> fix bus_disable commands handling (no more errors during module exit)
-> prefer managed versions of pci_ and dev_ functions whenever possible
-> increase adapter retries from 0 to 3
-> reduce code duplication in debugfs functions
-> address other review points by Bjorn Helgaas (except regarding the _DEP
   hint)

Changes since v8 by Elie M.:

-> remove mostly redundant amd_i2c_rw_config, refer to i2c_msg whenever
possible
-> use i2c_get_dma_safe_msg_buf and i2c_put_dma_safe_msg_buf
-> defer probe() by the platform driver if no MP2 device has been probed
yet by the PCI driver (which should address Bjorn Helgaas' concern while
preserving the platform driver)
-> if the interrupt following a command doesn't get handled after 250ms,
zero AMD_P2C_MSG_INTEN to prevent the MP2 from stalling for a few more
seconds
-> include AMD_P2C_MSG3 and fix typo in debugfs output
-> cosmetic fixes, code reduction, and better comments
-> add Nehal Shah and Shyam Sundar S K from AMD to the list of maintainers

Changes since v9 by Elie M.:

-> remove the xfer_lock mutex which was redundant with i2c_adapter.bus_lock
-> platform device remove() fixes (protection against the very unlikely
case that both the PCI and platform devices get detached manually and
simultaneously)
-> fix manually unbinding the PCI device and then rebinding, there was an
interrupt that wouldn't get serviced and thus the line got disabled
-> look for the MP2 device corresponding to an AMDI0011 ACPI device in
every device 

[PATCH AUTOSEL 3.18 05/12] USB: hso: Fix OOB memory access in hso_probe/hso_get_config_data

2018-12-26 Thread Sasha Levin
From: Hui Peng 

[ Upstream commit 5146f95df782b0ac61abde36567e718692725c89 ]

The function hso_probe reads if_num from the USB device (as an u8) and uses
it without a length check to index an array, resulting in an OOB memory read
in hso_probe or hso_get_config_data.

Add a length check for both locations and updated hso_probe to bail on
error.

This issue has been assigned CVE-2018-19985.

Reported-by: Hui Peng 
Reported-by: Mathias Payer 
Signed-off-by: Hui Peng 
Signed-off-by: Mathias Payer 
Reviewed-by: Sebastian Andrzej Siewior 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/usb/hso.c | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index babda7d8693e..f040bf558430 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -2814,6 +2814,12 @@ static int hso_get_config_data(struct usb_interface 
*interface)
return -EIO;
}
 
+   /* check if we have a valid interface */
+   if (if_num > 16) {
+   kfree(config_data);
+   return -EINVAL;
+   }
+
switch (config_data[if_num]) {
case 0x0:
result = 0;
@@ -2884,10 +2890,18 @@ static int hso_probe(struct usb_interface *interface,
 
/* Get the interface/port specification from either driver_info or from
 * the device itself */
-   if (id->driver_info)
+   if (id->driver_info) {
+   /* if_num is controlled by the device, driver_info is a 0 
terminated
+* array. Make sure, the access is in bounds! */
+   for (i = 0; i <= if_num; ++i)
+   if (((u32 *)(id->driver_info))[i] == 0)
+   goto exit;
port_spec = ((u32 *)(id->driver_info))[if_num];
-   else
+   } else {
port_spec = hso_get_config_data(interface);
+   if (port_spec < 0)
+   goto exit;
+   }
 
/* Check if we need to switch to alt interfaces prior to port
 * configuration */
-- 
2.19.1



[PATCH AUTOSEL 3.18 06/12] bnx2x: Clear fip MAC when fcoe offload support is disabled

2018-12-26 Thread Sasha Levin
From: Sudarsana Reddy Kalluru 

[ Upstream commit bbf666c1af916ed74795493c564df6fad462cc80 ]

On some customer setups it was observed that shmem contains a non-zero fip
MAC for 57711 which would lead to enabling of SW FCoE.
Add a software workaround to clear the bad fip mac address if no FCoE
connections are supported.

Signed-off-by: Sudarsana Reddy Kalluru 
Signed-off-by: Ariel Elior 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c 
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 8063e928827c..b121882c6d1b 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -11462,8 +11462,10 @@ static void bnx2x_get_fcoe_info(struct bnx2x *bp)
 * If maximum allowed number of connections is zero -
 * disable the feature.
 */
-   if (!bp->cnic_eth_dev.max_fcoe_conn)
+   if (!bp->cnic_eth_dev.max_fcoe_conn) {
bp->flags |= NO_FCOE_FLAG;
+   eth_zero_addr(bp->fip_mac);
+   }
 }
 
 static void bnx2x_get_cnic_info(struct bnx2x *bp)
-- 
2.19.1



[PATCH AUTOSEL 3.18 02/12] checkstack.pl: fix for aarch64

2018-12-26 Thread Sasha Levin
From: Qian Cai 

[ Upstream commit f1733a1d3cd32a9492f4cf866be37bb46e10163d ]

There is actually a space after "sp," like this,

280813c8:   a9bb7bfdstp x29, x30, [sp, #-80]!

Right now, checkstack.pl isn't able to print anything on aarch64,
because it won't be able to match the stating objdump line of a function
due to this missing space.  Hence, it displays every stack as zero-size.

After this patch, checkpatch.pl is able to match the start of a
function's objdump, and is then able to calculate each function's stack
correctly.

Link: http://lkml.kernel.org/r/20181207195843.38528-1-...@lca.pw
Signed-off-by: Qian Cai 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin 
---
 scripts/checkstack.pl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
index dd8397894d5c..12a6940741fe 100755
--- a/scripts/checkstack.pl
+++ b/scripts/checkstack.pl
@@ -46,8 +46,8 @@ my (@stack, $re, $dre, $x, $xs, $funcre);
$xs = "[0-9a-f ]";  # hex character or space
$funcre = qr/^$x* <(.*)>:$/;
if ($arch eq 'aarch64') {
-   #ffc0006325cc:   a9bb7bfdstp x29, x30, 
[sp,#-80]!
-   $re = qr/^.*stp.*sp,\#-([0-9]{1,8})\]\!/o;
+   #ffc0006325cc:   a9bb7bfdstp x29, x30, [sp, 
#-80]!
+   $re = qr/^.*stp.*sp, \#-([0-9]{1,8})\]\!/o;
} elsif ($arch eq 'arm') {
#c0008ffc:  e24dd064sub sp, sp, #100; 0x64
$re = qr/.*sub.*sp, sp, #(([0-9]{2}|[3-9])[0-9]{2})/o;
-- 
2.19.1



[PATCH AUTOSEL 3.18 08/12] x86/mtrr: Don't copy uninitialized gentry fields back to userspace

2018-12-26 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit 32043fa065b51e0b1433e48d118821c71b5cd65d ]

Currently the copy_to_user of data in the gentry struct is copying
uninitiaized data in field _pad from the stack to userspace.

Fix this by explicitly memset'ing gentry to zero, this also will zero any
compiler added padding fields that may be in struct (currently there are
none).

Detected by CoverityScan, CID#200783 ("Uninitialized scalar variable")

Fixes: b263b31e8ad6 ("x86, mtrr: Use explicit sizing and padding for the 64-bit 
ioctls")
Signed-off-by: Colin Ian King 
Signed-off-by: Thomas Gleixner 
Reviewed-by: Tyler Hicks 
Cc: secur...@kernel.org
Link: https://lkml.kernel.org/r/20181218172956.1440-1-colin.k...@canonical.com
Signed-off-by: Sasha Levin 
---
 arch/x86/kernel/cpu/mtrr/if.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/mtrr/if.c b/arch/x86/kernel/cpu/mtrr/if.c
index a041e094b8b9..5598de02d2b4 100644
--- a/arch/x86/kernel/cpu/mtrr/if.c
+++ b/arch/x86/kernel/cpu/mtrr/if.c
@@ -173,6 +173,8 @@ mtrr_ioctl(struct file *file, unsigned int cmd, unsigned 
long __arg)
struct mtrr_gentry gentry;
void __user *arg = (void __user *) __arg;
 
+   memset(, 0, sizeof(gentry));
+
switch (cmd) {
case MTRRIOC_ADD_ENTRY:
case MTRRIOC_SET_ENTRY:
-- 
2.19.1



[PATCH AUTOSEL 3.18 12/12] serial/sunsu: fix refcount leak

2018-12-26 Thread Sasha Levin
From: Yangtao Li 

[ Upstream commit d430aff8cd0c57502d873909c184e3b5753f8b88 ]

The function of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.

su_get_type() doesn't do that. The match node are used as an identifier
to compare against the current node, so we can directly drop the refcount
after getting the node from the path as it is not used as pointer.

Fix this by use a single variable and drop the refcount right after
of_find_node_by_path().

Signed-off-by: Yangtao Li 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/tty/serial/sunsu.c | 31 ++-
 1 file changed, 26 insertions(+), 5 deletions(-)

diff --git a/drivers/tty/serial/sunsu.c b/drivers/tty/serial/sunsu.c
index 5326ae195e5f..298c11556850 100644
--- a/drivers/tty/serial/sunsu.c
+++ b/drivers/tty/serial/sunsu.c
@@ -1380,22 +1380,43 @@ static inline struct console *SUNSU_CONSOLE(void)
 static enum su_type su_get_type(struct device_node *dp)
 {
struct device_node *ap = of_find_node_by_path("/aliases");
+   enum su_type rc = SU_PORT_PORT;
 
if (ap) {
const char *keyb = of_get_property(ap, "keyboard", NULL);
const char *ms = of_get_property(ap, "mouse", NULL);
+   struct device_node *match;
 
if (keyb) {
-   if (dp == of_find_node_by_path(keyb))
-   return SU_PORT_KBD;
+   match = of_find_node_by_path(keyb);
+
+   /*
+* The pointer is used as an identifier not
+* as a pointer, we can drop the refcount on
+* the of__node immediately after getting it.
+*/
+   of_node_put(match);
+
+   if (dp == match) {
+   rc = SU_PORT_KBD;
+   goto out;
+   }
}
if (ms) {
-   if (dp == of_find_node_by_path(ms))
-   return SU_PORT_MS;
+   match = of_find_node_by_path(ms);
+
+   of_node_put(match);
+
+   if (dp == match) {
+   rc = SU_PORT_MS;
+   goto out;
+   }
}
}
 
-   return SU_PORT_PORT;
+out:
+   of_node_put(ap);
+   return rc;
 }
 
 static int su_probe(struct platform_device *op)
-- 
2.19.1



[PATCH AUTOSEL 3.18 10/12] vxge: ensure data0 is initialized in when fetching firmware version information

2018-12-26 Thread Sasha Levin
From: Colin Ian King 

[ Upstream commit f7db2beb4c2c6cc8111f5ab90fc7363ca91107b6 ]

Currently variable data0 is not being initialized so a garbage value is
being passed to vxge_hw_vpath_fw_api and this value is being written to
the rts_access_steer_data0 register.  There are other occurrances where
data0 is being initialized to zero (e.g. in function
vxge_hw_upgrade_read_version) so I think it makes sense to ensure data0
is initialized likewise to 0.

Detected by CoverityScan, CID#140696 ("Uninitialized scalar variable")

Fixes: 8424e00dfd52 ("vxge: serialize access to steering control register")
Signed-off-by: Colin Ian King 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/neterion/vxge/vxge-config.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/neterion/vxge/vxge-config.c 
b/drivers/net/ethernet/neterion/vxge/vxge-config.c
index 2bbd01fcb9b0..4332ebbd7162 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-config.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-config.c
@@ -808,7 +808,7 @@ __vxge_hw_vpath_fw_ver_get(struct __vxge_hw_virtualpath 
*vpath,
struct vxge_hw_device_date *fw_date = _info->fw_date;
struct vxge_hw_device_version *flash_version = _info->flash_version;
struct vxge_hw_device_date *flash_date = _info->flash_date;
-   u64 data0, data1 = 0, steer_ctrl = 0;
+   u64 data0 = 0, data1 = 0, steer_ctrl = 0;
enum vxge_hw_status status;
 
status = vxge_hw_vpath_fw_api(vpath,
-- 
2.19.1



[PATCH AUTOSEL 3.18 09/12] xen/netfront: tolerate frags with no data

2018-12-26 Thread Sasha Levin
From: Juergen Gross 

[ Upstream commit d81c5054a5d1d4999c7cdead7636b6cd4af83d36 ]

At least old Xen net backends seem to send frags with no real data
sometimes. In case such a fragment happens to occur with the frag limit
already reached the frontend will BUG currently even if this situation
is easily recoverable.

Modify the BUG_ON() condition accordingly.

Tested-by: Dietmar Hahn 
Signed-off-by: Juergen Gross 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/xen-netfront.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 3bbfb09af65f..5d11e60d4995 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -913,7 +913,7 @@ static RING_IDX xennet_fill_frags(struct netfront_queue 
*queue,
if (skb_shinfo(skb)->nr_frags == MAX_SKB_FRAGS) {
unsigned int pull_to = NETFRONT_SKB_CB(skb)->pull_to;
 
-   BUG_ON(pull_to <= skb_headlen(skb));
+   BUG_ON(pull_to < skb_headlen(skb));
__pskb_pull_tail(skb, pull_to - skb_headlen(skb));
}
BUG_ON(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS);
-- 
2.19.1



[PATCH AUTOSEL 3.18 07/12] w90p910_ether: remove incorrect __init annotation

2018-12-26 Thread Sasha Levin
From: Arnd Bergmann 

[ Upstream commit 51367e423c6501a26e67d91a655d2bc892303462 ]

The get_mac_address() function is normally inline, but when it is
not, we get a warning that this configuration is broken:

WARNING: vmlinux.o(.text+0x4aff00): Section mismatch in reference from the 
function w90p910_ether_setup() to the function .init.text:get_mac_address()
The function w90p910_ether_setup() references
the function __init get_mac_address().
This is often because w90p910_ether_setup lacks a __init

Remove the __init to make it always do the right thing.

Signed-off-by: Arnd Bergmann 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/nuvoton/w90p910_ether.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/nuvoton/w90p910_ether.c 
b/drivers/net/ethernet/nuvoton/w90p910_ether.c
index 379b7fbded78..f15c97343c9b 100644
--- a/drivers/net/ethernet/nuvoton/w90p910_ether.c
+++ b/drivers/net/ethernet/nuvoton/w90p910_ether.c
@@ -918,7 +918,7 @@ static const struct net_device_ops w90p910_ether_netdev_ops 
= {
.ndo_change_mtu = eth_change_mtu,
 };
 
-static void __init get_mac_address(struct net_device *dev)
+static void get_mac_address(struct net_device *dev)
 {
struct w90p910_ether *ether = netdev_priv(dev);
struct platform_device *pdev;
-- 
2.19.1



[PATCH AUTOSEL 3.18 04/12] Input: omap-keypad - fix idle configuration to not block SoC idle states

2018-12-26 Thread Sasha Levin
From: Tony Lindgren 

[ Upstream commit e2ca26ec4f01486661b55b03597c13e2b9c18b73 ]

With PM enabled, I noticed that pressing a key on the droid4 keyboard will
block deeper idle states for the SoC. Let's fix this by using IRQF_ONESHOT
and stop constantly toggling the device OMAP4_KBD_IRQENABLE register as
suggested by Dmitry Torokhov .

>From the hardware point of view, looks like we need to manage the registers
for OMAP4_KBD_IRQENABLE and OMAP4_KBD_WAKEUPENABLE together to avoid
blocking deeper SoC idle states. And with toggling of OMAP4_KBD_IRQENABLE
register now gone with IRQF_ONESHOT, also the SoC idle state problem is
gone during runtime. We still also need to clear OMAP4_KBD_WAKEUPENABLE in
omap4_keypad_close() though to pair it with omap4_keypad_open() to prevent
blocking deeper SoC idle states after rmmod omap4-keypad.

Reported-by: Pavel Machek 
Signed-off-by: Tony Lindgren 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Sasha Levin 
---
 drivers/input/keyboard/omap4-keypad.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/input/keyboard/omap4-keypad.c 
b/drivers/input/keyboard/omap4-keypad.c
index 1739221aa5fa..75ea1e3e0e91 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -126,12 +126,8 @@ static irqreturn_t omap4_keypad_irq_handler(int irq, void 
*dev_id)
 {
struct omap4_keypad *keypad_data = dev_id;
 
-   if (kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS)) {
-   /* Disable interrupts */
-   kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
-OMAP4_VAL_IRQDISABLE);
+   if (kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS))
return IRQ_WAKE_THREAD;
-   }
 
return IRQ_NONE;
 }
@@ -173,11 +169,6 @@ static irqreturn_t omap4_keypad_irq_thread_fn(int irq, 
void *dev_id)
kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
 kbd_read_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS));
 
-   /* enable interrupts */
-   kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
-   OMAP4_DEF_IRQENABLE_EVENTEN |
-   OMAP4_DEF_IRQENABLE_LONGKEY);
-
return IRQ_HANDLED;
 }
 
@@ -214,9 +205,10 @@ static void omap4_keypad_close(struct input_dev *input)
 
disable_irq(keypad_data->irq);
 
-   /* Disable interrupts */
+   /* Disable interrupts and wake-up events */
kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQENABLE,
 OMAP4_VAL_IRQDISABLE);
+   kbd_writel(keypad_data, OMAP4_KBD_WAKEUPENABLE, 0);
 
/* clear pending interrupts */
kbd_write_irqreg(keypad_data, OMAP4_KBD_IRQSTATUS,
@@ -364,7 +356,7 @@ static int omap4_keypad_probe(struct platform_device *pdev)
}
 
error = request_threaded_irq(keypad_data->irq, omap4_keypad_irq_handler,
-omap4_keypad_irq_thread_fn, 0,
+omap4_keypad_irq_thread_fn, IRQF_ONESHOT,
 "omap4-keypad", keypad_data);
if (error) {
dev_err(>dev, "failed to register interrupt\n");
-- 
2.19.1



[PATCH AUTOSEL 3.18 11/12] net: netxen: fix a missing check and an uninitialized use

2018-12-26 Thread Sasha Levin
From: Kangjie Lu 

[ Upstream commit d134e486e831defd26130770181f01dfc6195f7d ]

When netxen_rom_fast_read() fails, "bios" is left uninitialized and may
contain random value, thus should not be used.

The fix ensures that if netxen_rom_fast_read() fails, we return "-EIO".

Signed-off-by: Kangjie Lu 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c 
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index 5c4068353f66..746612a88515 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
@@ -1125,7 +1125,8 @@ netxen_validate_firmware(struct netxen_adapter *adapter)
return -EINVAL;
}
val = nx_get_bios_version(adapter);
-   netxen_rom_fast_read(adapter, NX_BIOS_VERSION_OFFSET, (int *));
+   if (netxen_rom_fast_read(adapter, NX_BIOS_VERSION_OFFSET, (int *)))
+   return -EIO;
if ((__force u32)val != bios) {
dev_err(>dev, "%s: firmware bios is incompatible\n",
fw_name[fw_type]);
-- 
2.19.1



[PATCH AUTOSEL 3.18 01/12] powerpc: Fix COFF zImage booting on old powermacs

2018-12-26 Thread Sasha Levin
From: Paul Mackerras 

[ Upstream commit 5564597d51c8ff5b88d95c76255e18b13b760879 ]

Commit 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper
as a relocatable ET_DYN", 2011-04-12) changed the procedure descriptor
at the start of crt0.S to have a hard-coded start address of 0x50
rather than a reference to _zimage_start, presumably because having
a reference to a symbol introduced a relocation which is awkward to
handle in a position-independent executable.  Unfortunately, what is
at 0x50 in the COFF image is not the first instruction, but the
procedure descriptor itself, that is, a word containing 0x50,
which is not a valid instruction.  Hence, booting a COFF zImage
results in a "DEFAULT CATCH!, code=FFF00700" message from Open
Firmware.

This fixes the problem by (a) putting the procedure descriptor in the
data section and (b) adding a branch to _zimage_start as the first
instruction in the program.

Fixes: 6975a783d7b4 ("powerpc/boot: Allow building the zImage wrapper as a 
relocatable ET_DYN")
Signed-off-by: Paul Mackerras 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
---
 arch/powerpc/boot/crt0.S | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/boot/crt0.S b/arch/powerpc/boot/crt0.S
index 8539ac93b0de..dbb06588b594 100644
--- a/arch/powerpc/boot/crt0.S
+++ b/arch/powerpc/boot/crt0.S
@@ -15,7 +15,7 @@
 RELA = 7
 RELACOUNT = 0x6ff9
 
-   .text
+   .data
/* A procedure descriptor used when booting this as a COFF file.
 * When making COFF, this comes first in the link and we're
 * linked at 0x50.
@@ -23,6 +23,8 @@ RELACOUNT = 0x6ff9
.globl  _zimage_start_opd
 _zimage_start_opd:
.long   0x50, 0, 0, 0
+   .text
+   b   _zimage_start
 
 #ifdef __powerpc64__
 .balign 8
-- 
2.19.1



[PATCH AUTOSEL 3.18 03/12] xfrm: Fix bucket count reported to userspace

2018-12-26 Thread Sasha Levin
From: Benjamin Poirier 

[ Upstream commit ca92e173ab34a4f7fc4128bd372bd96f1af6f507 ]

sadhcnt is reported by `ip -s xfrm state count` as "buckets count", not the
hash mask.

Fixes: 28d8909bc790 ("[XFRM]: Export SAD info.")
Signed-off-by: Benjamin Poirier 
Signed-off-by: Steffen Klassert 
Signed-off-by: Sasha Levin 
---
 net/xfrm/xfrm_state.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 1dbffea4da34..3ac1565e4d4c 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -623,7 +623,7 @@ void xfrm_sad_getinfo(struct net *net, struct xfrmk_sadinfo 
*si)
 {
spin_lock_bh(>xfrm.xfrm_state_lock);
si->sadcnt = net->xfrm.state_num;
-   si->sadhcnt = net->xfrm.state_hmask;
+   si->sadhcnt = net->xfrm.state_hmask + 1;
si->sadhmcnt = xfrm_state_hashmax;
spin_unlock_bh(>xfrm.xfrm_state_lock);
 }
-- 
2.19.1



  1   2   3   4   5   6   >