[PATCH 2/4] usb: renesas_usbhs: add a new callback for extcon notifier

[Yoshihiro Shimoda]

To set host/peripheral mode by using extcon notifier, this patch
adds a new callback as "notifier" in renesas_usbhs_platform_callback.

Signed-off-by: Yoshihiro Shimoda 
---
 include/linux/usb/renesas_usbhs.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/linux/usb/renesas_usbhs.h 
b/include/linux/usb/renesas_usbhs.h
index 67102f3..9482735 100644
--- a/include/linux/usb/renesas_usbhs.h
+++ b/include/linux/usb/renesas_usbhs.h
@@ -17,6 +17,7 @@
  */
 #ifndef RENESAS_USB_H
 #define RENESAS_USB_H
+#include 
 #include 
 #include 
 
@@ -98,6 +99,13 @@ struct renesas_usbhs_platform_callback {
 * VBUS control is needed for Host
 */
int (*set_vbus)(struct platform_device *pdev, int enable);
+
+   /*
+* option:
+* extcon notifier to set host/peripheral mode.
+*/
+   int (*notifier)(struct notifier_block *nb, unsigned long event,
+   void *data);
 };
 
 /*
-- 
1.9.1

[PATCH 4/4] usb: renesas_usbhs: add extcon notifier to set mode for non-otg channel

[Yoshihiro Shimoda]

This patch adds extcon notifier callback to set the mode of
host/peripheral by using extcon state (e.g phy-rcar-gen3-usb2) for
non-otg channel (e.g. R-Car D3).

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/common.c |  9 +
 drivers/usb/renesas_usbhs/common.h |  1 +
 drivers/usb/renesas_usbhs/rcar3.c  | 11 +++
 3 files changed, 21 insertions(+)

diff --git a/drivers/usb/renesas_usbhs/common.c 
b/drivers/usb/renesas_usbhs/common.c
index 56079bb..c5289b3 100644
--- a/drivers/usb/renesas_usbhs/common.c
+++ b/drivers/usb/renesas_usbhs/common.c
@@ -581,6 +581,15 @@ static int usbhs_probe(struct platform_device *pdev)
break;
case USBHS_TYPE_RCAR_GEN3_WITH_PLL:
priv->pfunc = usbhs_rcar3_with_pll_ops;
+   if (!IS_ERR_OR_NULL(priv->edev)) {
+   priv->nb.notifier_call = priv->pfunc.notifier;
+   ret = devm_extcon_register_notifier(>dev,
+   priv->edev,
+   EXTCON_USB_HOST,
+   >nb);
+   if (ret < 0)
+   dev_err(>dev, "no notifier registered\n");
+   }
break;
default:
if (!info->platform_callback.get_id) {
diff --git a/drivers/usb/renesas_usbhs/common.h 
b/drivers/usb/renesas_usbhs/common.h
index 6479778..c9747f0 100644
--- a/drivers/usb/renesas_usbhs/common.h
+++ b/drivers/usb/renesas_usbhs/common.h
@@ -249,6 +249,7 @@ struct usbhs_priv {
struct platform_device *pdev;
 
struct extcon_dev *edev;
+   struct notifier_block nb;
 
spinlock_t  lock;
 
diff --git a/drivers/usb/renesas_usbhs/rcar3.c 
b/drivers/usb/renesas_usbhs/rcar3.c
index b9a8453..d657309 100644
--- a/drivers/usb/renesas_usbhs/rcar3.c
+++ b/drivers/usb/renesas_usbhs/rcar3.c
@@ -112,6 +112,16 @@ static int usbhs_rcar3_get_id(struct platform_device *pdev)
return USBHS_GADGET;
 }
 
+int usbhs_rcar3_notifier(struct notifier_block *nb, unsigned long event,
+void *data)
+{
+   struct usbhs_priv *priv = container_of(nb, struct usbhs_priv, nb);
+
+   usbhs_rcar3_set_usbsel(priv, !!event);
+
+   return NOTIFY_DONE;
+}
+
 const struct renesas_usbhs_platform_callback usbhs_rcar3_ops = {
.power_ctrl = usbhs_rcar3_power_ctrl,
.get_id = usbhs_rcar3_get_id,
@@ -120,4 +130,5 @@ static int usbhs_rcar3_get_id(struct platform_device *pdev)
 const struct renesas_usbhs_platform_callback usbhs_rcar3_with_pll_ops = {
.power_ctrl = usbhs_rcar3_power_and_pll_ctrl,
.get_id = usbhs_rcar3_get_id,
+   .notifier = usbhs_rcar3_notifier,
 };
-- 
1.9.1

[PATCH 3/4] usb: renesas_usbhs: set the mode by using extcon state for non-otg channel

[Yoshihiro Shimoda]

The usbhs_rcar3_power_and_pll_ctrl() will be used by non-otg channel
(e.g. R-Car D3) and the previous code has hardcoded as peripheral mode.
So, this patch sets the mode by using extcon state.
If the channel doesn't get any extcon devices, this driver's behavior
is the same as before.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/rcar3.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/renesas_usbhs/rcar3.c 
b/drivers/usb/renesas_usbhs/rcar3.c
index 50e5fb5..b9a8453 100644
--- a/drivers/usb/renesas_usbhs/rcar3.c
+++ b/drivers/usb/renesas_usbhs/rcar3.c
@@ -27,6 +27,7 @@
  * Remarks: bit[31:11] and bit[9:6] should be 0
  */
 #define UGCTRL2_RESERVED_3 0x0001  /* bit[3:0] should be B'0001 */
+#define UGCTRL2_USB0SEL_EHCI   0x0010
 #define UGCTRL2_USB0SEL_HSUSB  0x0020
 #define UGCTRL2_USB0SEL_OTG0x0030
 #define UGCTRL2_VBUSSEL0x0400
@@ -49,6 +50,14 @@ static void usbhs_rcar3_set_ugctrl2(struct usbhs_priv *priv, 
u32 val)
usbhs_write32(priv, UGCTRL2, val | UGCTRL2_RESERVED_3);
 }
 
+static void usbhs_rcar3_set_usbsel(struct usbhs_priv *priv, bool ehci)
+{
+   if (ehci)
+   usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_EHCI);
+   else
+   usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_HSUSB);
+}
+
 static int usbhs_rcar3_power_ctrl(struct platform_device *pdev,
void __iomem *base, int enable)
 {
@@ -74,10 +83,14 @@ static int usbhs_rcar3_power_and_pll_ctrl(struct 
platform_device *pdev,
struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
u32 val;
int timeout = 1000;
+   bool is_host = false;
 
if (enable) {
usbhs_write32(priv, UGCTRL, 0); /* release PLLRESET */
-   usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_HSUSB);
+   if (priv->edev)
+   is_host = extcon_get_state(priv->edev, EXTCON_USB_HOST);
+
+   usbhs_rcar3_set_usbsel(priv, is_host);
 
usbhs_bset(priv, LPSTS, LPSTS_SUSPM, LPSTS_SUSPM);
do {
-- 
1.9.1

[PATCH 1/4] usb: renesas_usbhs: Add a function to write the UGCTRL2 register

[Yoshihiro Shimoda]

To cleanup the code, this patch adds a function to write the UGCTRL2
register.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/usb/renesas_usbhs/rcar3.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/renesas_usbhs/rcar3.c 
b/drivers/usb/renesas_usbhs/rcar3.c
index c929d29..50e5fb5 100644
--- a/drivers/usb/renesas_usbhs/rcar3.c
+++ b/drivers/usb/renesas_usbhs/rcar3.c
@@ -44,13 +44,17 @@ static u32 usbhs_read32(struct usbhs_priv *priv, u32 reg)
return ioread32(priv->base + reg);
 }
 
+static void usbhs_rcar3_set_ugctrl2(struct usbhs_priv *priv, u32 val)
+{
+   usbhs_write32(priv, UGCTRL2, val | UGCTRL2_RESERVED_3);
+}
+
 static int usbhs_rcar3_power_ctrl(struct platform_device *pdev,
void __iomem *base, int enable)
 {
struct usbhs_priv *priv = usbhs_pdev_to_priv(pdev);
 
-   usbhs_write32(priv, UGCTRL2, UGCTRL2_RESERVED_3 | UGCTRL2_USB0SEL_OTG |
- UGCTRL2_VBUSSEL);
+   usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_OTG | UGCTRL2_VBUSSEL);
 
if (enable) {
usbhs_bset(priv, LPSTS, LPSTS_SUSPM, LPSTS_SUSPM);
@@ -73,8 +77,7 @@ static int usbhs_rcar3_power_and_pll_ctrl(struct 
platform_device *pdev,
 
if (enable) {
usbhs_write32(priv, UGCTRL, 0); /* release PLLRESET */
-   usbhs_write32(priv, UGCTRL2, UGCTRL2_RESERVED_3 |
- UGCTRL2_USB0SEL_HSUSB);
+   usbhs_rcar3_set_ugctrl2(priv, UGCTRL2_USB0SEL_HSUSB);
 
usbhs_bset(priv, LPSTS, LPSTS_SUSPM, LPSTS_SUSPM);
do {
-- 
1.9.1

[PATCH 0/4] usb: renesas_usbhs: add extcon notifier for non-otg channel

[Yoshihiro Shimoda]

This patch set is based on the Felipe's usb.git / testing/next branch
(commit id = f2830ad455ec0fdc386baeb9d654f7095bf849da).

Yoshihiro Shimoda (4):
  usb: renesas_usbhs: Add a function to write the UGCTRL2 register
  usb: renesas_usbhs: add a new callback for extcon notifier
  usb: renesas_usbhs: set the mode by using extcon state for non-otg
channel
  usb: renesas_usbhs: add extcon notifier to set mode for non-otg
channel

The following patches are required for this feature.
 https://patchwork.kernel.org/patch/10109281/
 https://patchwork.kernel.org/patch/10109287/
 https://patchwork.kernel.org/patch/10109279/
 https://patchwork.kernel.org/patch/10109291/
 https://patchwork.kernel.org/patch/10109285/

 drivers/usb/renesas_usbhs/common.c |  9 +
 drivers/usb/renesas_usbhs/common.h |  1 +
 drivers/usb/renesas_usbhs/rcar3.c  | 35 +++
 include/linux/usb/renesas_usbhs.h  |  8 
 4 files changed, 49 insertions(+), 4 deletions(-)

-- 
1.9.1

[PATCH 4/5] phy: renesas: rcar-gen3-usb2: add rcar_gen3_role_swap_ops

[Yoshihiro Shimoda]

This patch add rcar_gen3_role_swap_ops to support other feature
(e.g. gpio handling) easily.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 51 +++-
 1 file changed, 43 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 6d6f3eb..5e509a9 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -83,11 +83,23 @@
 
 #define RCAR_GEN3_PHY_HAS_DEDICATED_PINS   1
 
+struct rcar_gen3_chan;
+struct rcar_gen3_role_swap_ops {
+   void (*init)(struct rcar_gen3_chan *ch);
+   void (*set_host)(struct rcar_gen3_chan *ch, int host);
+   bool (*is_host)(struct rcar_gen3_chan *ch);
+   void (*enable_vbus)(struct rcar_gen3_chan *ch, int vbus);
+   bool (*check_id)(struct rcar_gen3_chan *ch);
+   void (*enable_irq)(struct rcar_gen3_chan *ch, int enable);
+   irqreturn_t (*irq_handler)(struct rcar_gen3_chan *ch);
+};
+
 struct rcar_gen3_chan {
void __iomem *base;
struct extcon_dev *extcon;
struct phy *phy;
struct regulator *vbus;
+   const struct rcar_gen3_role_swap_ops *rs_ops;
struct work_struct work;
bool extcon_host;
bool has_otg_pins;
@@ -203,17 +215,20 @@ static void rcar_gen3_phy_usb2_work(struct work_struct 
*work)
 
 static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host)
 {
-   has_otg_pins_set_host(ch, host);
+   if (ch->rs_ops && ch->rs_ops->set_host)
+   ch->rs_ops->set_host(ch, host);
 }
 
 static void rcar_gen3_enable_vbus_ctrl(struct rcar_gen3_chan *ch, int vbus)
 {
-   has_otg_pins_enable_vbus(ch, vbus);
+   if (ch->rs_ops && ch->rs_ops->enable_vbus)
+   ch->rs_ops->enable_vbus(ch, vbus);
 }
 
 static void rcar_gen3_enable_otg_irq(struct rcar_gen3_chan *ch, int enable)
 {
-   has_otg_pins_enable_irq(ch, enable);
+   if (ch->rs_ops && ch->rs_ops->enable_irq)
+   ch->rs_ops->enable_irq(ch, enable);
 }
 
 static void rcar_gen3_init_for_host(struct rcar_gen3_chan *ch)
@@ -271,7 +286,10 @@ static void rcar_gen3_init_from_a_peri_to_a_host(struct 
rcar_gen3_chan *ch)
 
 static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
 {
-   return has_otg_pins_check_id(ch);
+   if (ch->rs_ops && ch->rs_ops->check_id)
+   return ch->rs_ops->check_id(ch);
+
+   return false;
 }
 
 static void rcar_gen3_device_recognition(struct rcar_gen3_chan *ch)
@@ -284,7 +302,10 @@ static void rcar_gen3_device_recognition(struct 
rcar_gen3_chan *ch)
 
 static bool rcar_gen3_is_host(struct rcar_gen3_chan *ch)
 {
-   return has_otg_pins_is_host(ch);
+   if (ch->rs_ops && ch->rs_ops->is_host)
+   return ch->rs_ops->is_host(ch);
+
+   return false;
 }
 
 static enum phy_mode rcar_gen3_get_phy_mode(struct rcar_gen3_chan *ch)
@@ -350,7 +371,8 @@ static ssize_t role_show(struct device *dev, struct 
device_attribute *attr,
 
 static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
 {
-   has_otg_pins_init(ch);
+   if (ch->rs_ops && ch->rs_ops->init)
+   ch->rs_ops->init(ch);
 
rcar_gen3_device_recognition(ch);
 }
@@ -425,9 +447,10 @@ static int rcar_gen3_phy_usb2_power_off(struct phy *p)
 static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void *_ch)
 {
struct rcar_gen3_chan *ch = _ch;
-   irqreturn_t ret;
+   irqreturn_t ret = IRQ_NONE;
 
-   ret = has_otg_pins_irq_handler(ch);
+   if (ch->rs_ops && ch->rs_ops->irq_handler)
+   ret = ch->rs_ops->irq_handler(ch);
if (ret == IRQ_HANDLED)
rcar_gen3_device_recognition(ch);
 
@@ -456,6 +479,16 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void 
*_ch)
EXTCON_NONE,
 };
 
+static const struct rcar_gen3_role_swap_ops has_otg_pins_ops = {
+   .init   = has_otg_pins_init,
+   .set_host   = has_otg_pins_set_host,
+   .is_host= has_otg_pins_is_host,
+   .enable_vbus= has_otg_pins_enable_vbus,
+   .check_id   = has_otg_pins_check_id,
+   .enable_irq = has_otg_pins_enable_irq,
+   .irq_handler= has_otg_pins_irq_handler,
+};
+
 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -493,6 +526,8 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
int ret;
 
channel->has_otg_pins = 
(uintptr_t)of_device_get_match_data(dev);
+   if (channel->has_otg_pins)
+   channel->rs_ops = _otg_pins_ops;
channel->extcon = devm_extcon_dev_allocate(dev,
rcar_gen3_phy_cable);
if (IS_ERR(channel->extcon))
-- 
1.9.1

[PATCH 2/5] phy: renesas: rcar-gen3-usb2: unify OBINTEN handling

[Yoshihiro Shimoda]

This patch unifies the OBINTEN handling to clean-up the code.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index c22d65a..beeaa30 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -147,6 +147,18 @@ static void rcar_gen3_enable_vbus_ctrl(struct 
rcar_gen3_chan *ch, int vbus)
writel(val, usb2_base + USB2_ADPCTRL);
 }
 
+static void rcar_gen3_enable_otg_irq(struct rcar_gen3_chan *ch, int enable)
+{
+   void __iomem *usb2_base = ch->base;
+   u32 val = readl(usb2_base + USB2_OBINTEN);
+
+   if (enable)
+   val |= USB2_OBINT_BITS;
+   else
+   val &= ~USB2_OBINT_BITS;
+   writel(val, usb2_base + USB2_OBINTEN);
+}
+
 static void rcar_gen3_init_for_host(struct rcar_gen3_chan *ch)
 {
rcar_gen3_set_linectrl(ch, 1, 1);
@@ -192,16 +204,12 @@ static void rcar_gen3_init_for_a_peri(struct 
rcar_gen3_chan *ch)
 
 static void rcar_gen3_init_from_a_peri_to_a_host(struct rcar_gen3_chan *ch)
 {
-   void __iomem *usb2_base = ch->base;
-   u32 val;
-
-   val = readl(usb2_base + USB2_OBINTEN);
-   writel(val & ~USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
+   rcar_gen3_enable_otg_irq(ch, 0);
 
rcar_gen3_enable_vbus_ctrl(ch, 0);
rcar_gen3_init_for_host(ch);
 
-   writel(val | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
+   rcar_gen3_enable_otg_irq(ch, 1);
 }
 
 static bool rcar_gen3_check_id(struct rcar_gen3_chan *ch)
@@ -291,8 +299,7 @@ static void rcar_gen3_init_otg(struct rcar_gen3_chan *ch)
val = readl(usb2_base + USB2_VBCTRL);
writel(val | USB2_VBCTRL_DRVVBUSSEL, usb2_base + USB2_VBCTRL);
writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTSTA);
-   val = readl(usb2_base + USB2_OBINTEN);
-   writel(val | USB2_OBINT_BITS, usb2_base + USB2_OBINTEN);
+   rcar_gen3_enable_otg_irq(ch, 1);
val = readl(usb2_base + USB2_ADPCTRL);
writel(val | USB2_ADPCTRL_IDPULLUP, usb2_base + USB2_ADPCTRL);
val = readl(usb2_base + USB2_LINECTRL1);
-- 
1.9.1

[PATCH 5/5] phy: renesas: rcar-gen3-usb2: add gpio handling

[Yoshihiro Shimoda]

Some R-Car SoCs (e.g. R-Car D3) doesn't have dedicated pins of VBUS
and ID. So, they may be connected to gpio pins. To handle the gpio
pins, this patch adds the handling of VBUS and ID pins instead of
dedicated pins.

Signed-off-by: Yoshihiro Shimoda 
---
 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |  2 +
 drivers/phy/renesas/phy-rcar-gen3-usb2.c   | 77 --
 2 files changed, 72 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt 
b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
index 99b651b..851582f 100644
--- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
+++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
@@ -27,6 +27,8 @@ channel as USB OTG:
 - interrupts: interrupt specifier for the PHY.
 - vbus-supply: Phandle to a regulator that provides power to the VBUS. This
   regulator will be managed during the PHY power on/off sequence.
+- renesas,vbus-gpios: use gpio to control vbus instead of dedicated pin.
+- renesas,id-gpios: use gpio to detect id instead of dedicated pin.
 
 Example (R-Car H3):
 
diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 5e509a9..0b6333d 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -13,6 +13,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -100,9 +101,12 @@ struct rcar_gen3_chan {
struct phy *phy;
struct regulator *vbus;
const struct rcar_gen3_role_swap_ops *rs_ops;
+   struct gpio_desc *gpio_vbus;
+   struct gpio_desc *gpio_id;
struct work_struct work;
bool extcon_host;
bool has_otg_pins;
+   bool has_gpio;
 };
 
 static void rcar_gen3_set_linectrl(struct rcar_gen3_chan *ch, int dp, int dm)
@@ -199,6 +203,36 @@ static void has_otg_pins_init(struct rcar_gen3_chan *ch)
   usb2_base + USB2_LINECTRL1);
 }
 
+static void gpio_enable_vbus(struct rcar_gen3_chan *ch, int vbus)
+{
+   gpiod_set_value(ch->gpio_vbus, vbus);
+}
+
+static bool gpio_check_id(struct rcar_gen3_chan *ch)
+{
+   return gpiod_get_value(ch->gpio_id);
+}
+
+static void gpio_set_host(struct rcar_gen3_chan *ch, int host)
+{
+   /* In gpio ops, this driver will modify the extcon_host by sysfs */
+   if (ch->extcon_host != !!host) {
+   ch->extcon_host = !!host;
+   schedule_work(>work);
+   }
+}
+
+static bool gpio_is_host(struct rcar_gen3_chan *ch)
+{
+   return ch->extcon_host;
+}
+
+static irqreturn_t gpio_irq_handler(struct rcar_gen3_chan *ch)
+{
+   /* Nop because the driver will get gpio value after exited */
+   return IRQ_HANDLED;
+}
+
 static void rcar_gen3_phy_usb2_work(struct work_struct *work)
 {
struct rcar_gen3_chan *ch = container_of(work, struct rcar_gen3_chan,
@@ -323,7 +357,7 @@ static ssize_t role_store(struct device *dev, struct 
device_attribute *attr,
bool is_b_device;
enum phy_mode cur_mode, new_mode;
 
-   if (!ch->has_otg_pins || !ch->phy->init_count)
+   if (!(ch->has_otg_pins || ch->has_gpio) || !ch->phy->init_count)
return -EIO;
 
if (!strncmp(buf, "host", strlen("host")))
@@ -361,7 +395,7 @@ static ssize_t role_show(struct device *dev, struct 
device_attribute *attr,
 {
struct rcar_gen3_chan *ch = dev_get_drvdata(dev);
 
-   if (!ch->has_otg_pins || !ch->phy->init_count)
+   if (!(ch->has_otg_pins || ch->has_gpio) || !ch->phy->init_count)
return -EIO;
 
return sprintf(buf, "%s\n", rcar_gen3_is_host(ch) ? "host" :
@@ -388,7 +422,7 @@ static int rcar_gen3_phy_usb2_init(struct phy *p)
writel(USB2_OC_TIMSET_INIT, usb2_base + USB2_OC_TIMSET);
 
/* Initialize otg part */
-   if (channel->has_otg_pins)
+   if (channel->has_otg_pins || channel->has_gpio)
rcar_gen3_init_otg(channel);
 
return 0;
@@ -489,6 +523,14 @@ static irqreturn_t rcar_gen3_phy_usb2_irq(int irq, void 
*_ch)
.irq_handler= has_otg_pins_irq_handler,
 };
 
+static const struct rcar_gen3_role_swap_ops gpio_ops = {
+   .set_host   = gpio_set_host,
+   .is_host= gpio_is_host,
+   .enable_vbus= gpio_enable_vbus,
+   .check_id   = gpio_check_id,
+   .irq_handler= gpio_irq_handler,
+};
+
 static int rcar_gen3_phy_usb2_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -513,9 +555,30 @@ static int rcar_gen3_phy_usb2_probe(struct platform_device 
*pdev)
 
INIT_WORK(>work, rcar_gen3_phy_usb2_work);
 
-   /* call request_irq for OTG */
+   channel->gpio_vbus = devm_gpiod_get(dev, "renesas,vbus", GPIOD_OUT_LOW);
+   if (IS_ERR(channel->gpio_vbus) &&
+   PTR_ERR(channel->gpio_vbus) == -EPROBE_DEFER)
+   return PTR_ERR(channel->gpio_vbus);
+
+   

[PATCH 1/5] phy: renesas: rcar-gen3-usb2: call INIT_WORK() anyway

[Yoshihiro Shimoda]

In the future, the work struct will be used by non-irq related code.
So, this patch moves the INIT_WORK() timing.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index 9c90e7d..c22d65a 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -431,10 +431,11 @@ static int rcar_gen3_phy_usb2_probe(struct 
platform_device *pdev)
if (IS_ERR(channel->base))
return PTR_ERR(channel->base);
 
+   INIT_WORK(>work, rcar_gen3_phy_usb2_work);
+
/* call request_irq for OTG */
irq = platform_get_irq(pdev, 0);
if (irq >= 0) {
-   INIT_WORK(>work, rcar_gen3_phy_usb2_work);
irq = devm_request_irq(dev, irq, rcar_gen3_phy_usb2_irq,
   IRQF_SHARED, dev_name(dev), channel);
if (irq < 0)
-- 
1.9.1

[PATCH 3/5] phy: renesas: rcar-gen3-usb2: use prefix "has_otg_pins_" for dedicated pins handling

[Yoshihiro Shimoda]

To support gpio handling in the future, this patch clean-ups the code
to use prefix "has_otg_pins_" functions.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/phy/renesas/phy-rcar-gen3-usb2.c | 130 ---
 1 file changed, 85 insertions(+), 45 deletions(-)

diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c 
b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
index beeaa30..6d6f3eb 100644
--- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
+++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
@@ -93,21 +93,21 @@ struct rcar_gen3_chan {
bool has_otg_pins;
 };
 
-static void rcar_gen3_phy_usb2_work(struct work_struct *work)
+static void rcar_gen3_set_linectrl(struct rcar_gen3_chan *ch, int dp, int dm)
 {
-   struct rcar_gen3_chan *ch = container_of(work, struct rcar_gen3_chan,
-work);
+   void __iomem *usb2_base = ch->base;
+   u32 val = readl(usb2_base + USB2_LINECTRL1);
 
-   if (ch->extcon_host) {
-   extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, true);
-   extcon_set_state_sync(ch->extcon, EXTCON_USB, false);
-   } else {
-   extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, false);
-   extcon_set_state_sync(ch->extcon, EXTCON_USB, true);
-   }
+   dev_vdbg(>phy->dev, "%s: %08x, %d, %d\n", __func__, val, dp, dm);
+   val &= ~(USB2_LINECTRL1_DP_RPD | USB2_LINECTRL1_DM_RPD);
+   if (dp)
+   val |= USB2_LINECTRL1_DP_RPD;
+   if (dm)
+   val |= USB2_LINECTRL1_DM_RPD;
+   writel(val, usb2_base + USB2_LINECTRL1);
 }
 
-static void rcar_gen3_set_host_mode(struct rcar_gen3_chan *ch, int host)
+static void has_otg_pins_set_host(struct rcar_gen3_chan *ch, int host)
 {
void __iomem *usb2_base = ch->base;
u32 val = readl(usb2_base + USB2_COMMCTRL);
@@ -120,21 +120,27 @@ static void rcar_gen3_set_host_mode(struct rcar_gen3_chan 
*ch, int host)
writel(val, usb2_base + USB2_COMMCTRL);
 }
 
-static void rcar_gen3_set_linectrl(struct rcar_gen3_chan *ch, int dp, int dm)
+static bool has_otg_pins_is_host(struct rcar_gen3_chan *ch)
+{
+   return !(readl(ch->base + USB2_COMMCTRL) & USB2_COMMCTRL_OTG_PERI);
+}
+
+static irqreturn_t has_otg_pins_irq_handler(struct rcar_gen3_chan *ch)
 {
void __iomem *usb2_base = ch->base;
-   u32 val = readl(usb2_base + USB2_LINECTRL1);
+   u32 status = readl(usb2_base + USB2_OBINTSTA);
+   irqreturn_t ret = IRQ_NONE;
 
-   dev_vdbg(>phy->dev, "%s: %08x, %d, %d\n", __func__, val, dp, dm);
-   val &= ~(USB2_LINECTRL1_DP_RPD | USB2_LINECTRL1_DM_RPD);
-   if (dp)
-   val |= USB2_LINECTRL1_DP_RPD;
-   if (dm)
-   val |= USB2_LINECTRL1_DM_RPD;
-   writel(val, usb2_base + USB2_LINECTRL1);
+   if (status & USB2_OBINT_BITS) {
+   dev_vdbg(>phy->dev, "%s: %08x\n", __func__, status);
+   writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTSTA);
+   ret = IRQ_HANDLED;
+   }
+
+   return ret;
 }
 
-static void rcar_gen3_enable_vbus_ctrl(struct rcar_gen3_chan *ch, int vbus)
+static void has_otg_pins_enable_vbus(struct rcar_gen3_chan *ch, int vbus)
 {
void __iomem *usb2_base = ch->base;
u32 val = readl(usb2_base + USB2_ADPCTRL);
@@ -147,7 +153,7 @@ static void rcar_gen3_enable_vbus_ctrl(struct 
rcar_gen3_chan *ch, int vbus)
writel(val, usb2_base + USB2_ADPCTRL);
 }
 
-static void rcar_gen3_enable_otg_irq(struct rcar_gen3_chan *ch, int enable)
+static void has_otg_pins_enable_irq(struct rcar_gen3_chan *ch, int enable)
 {
void __iomem *usb2_base = ch->base;
u32 val = readl(usb2_base + USB2_OBINTEN);
@@ -159,6 +165,57 @@ static void rcar_gen3_enable_otg_irq(struct rcar_gen3_chan 
*ch, int enable)
writel(val, usb2_base + USB2_OBINTEN);
 }
 
+static bool has_otg_pins_check_id(struct rcar_gen3_chan *ch)
+{
+   return !!(readl(ch->base + USB2_ADPCTRL) & USB2_ADPCTRL_IDDIG);
+}
+
+static void has_otg_pins_init(struct rcar_gen3_chan *ch)
+{
+   void __iomem *usb2_base = ch->base;
+   u32 val;
+
+   val = readl(usb2_base + USB2_VBCTRL);
+   writel(val | USB2_VBCTRL_DRVVBUSSEL, usb2_base + USB2_VBCTRL);
+   writel(USB2_OBINT_BITS, usb2_base + USB2_OBINTSTA);
+   has_otg_pins_enable_irq(ch, 1);
+   val = readl(usb2_base + USB2_ADPCTRL);
+   writel(val | USB2_ADPCTRL_IDPULLUP, usb2_base + USB2_ADPCTRL);
+   val = readl(usb2_base + USB2_LINECTRL1);
+   rcar_gen3_set_linectrl(ch, 0, 0);
+   writel(val | USB2_LINECTRL1_DPRPD_EN | USB2_LINECTRL1_DMRPD_EN,
+  usb2_base + USB2_LINECTRL1);
+}
+
+static void rcar_gen3_phy_usb2_work(struct work_struct *work)
+{
+   struct rcar_gen3_chan *ch = container_of(work, struct rcar_gen3_chan,
+work);
+
+   if (ch->extcon_host) {
+   extcon_set_state_sync(ch->extcon, 

[PATCH 0/5] phy: renesas: rcar-gen3-usb2: add gpio handling for R-Car D3

[Yoshihiro Shimoda]

This patch set is based on the latest linux-phy / next branch
(commit id = 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323).

This new feature will be used by the renesas_usbhs driver on R-Car D3.

Yoshihiro Shimoda (5):
  phy: renesas: rcar-gen3-usb2: call INIT_WORK() anyway
  phy: renesas: rcar-gen3-usb2: unify OBINTEN handling
  phy: renesas: rcar-gen3-usb2: use prefix "has_otg_pins_" for dedicated
pins handling
  phy: renesas: rcar-gen3-usb2: add rcar_gen3_role_swap_ops
  phy: renesas: rcar-gen3-usb2: add gpio handlings

 .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt |   2 +
 drivers/phy/renesas/phy-rcar-gen3-usb2.c   | 262 -
 2 files changed, 206 insertions(+), 58 deletions(-)

-- 
1.9.1

[BUG] renesas/ravb: two possible sleep-in-atomic bugs in ravb_set_link_ksettings and ravb_nway_reset

[Jia-Ju Bai]

Accoring to drivers/net/ethernet/renesas/ravb_main.c, the driver may 
sleep under a spinlock.

The function call paths are:
ravb_set_link_ksettings (acquire the spinlock)
  phy_ethtool_ksettings_set
phy_start_aneg
  phy_start_aneg_priv
mutex_lock --> may sleep

ravb_nway_reset (acquire the spinlock)
  phy_start_aneg
phy_start_aneg_priv
  mutex_lock --> may sleep

I do not find a good way to fix them, so I only report.
These possible bugs are found by my static analysis tool (DSAC) and 
checked by my code review.



Thanks,
Jia-Ju Bai

[BUG] renesas/sh_eth: two possible sleep-in-atomic bugs in sh_eth_set_link_ksettings and sh_eth_nway_reset

[Jia-Ju Bai]

Accoring to drivers/net/ethernet/renesas/sh_eth.c, the driver may sleep 
under a spinlock.

The function call paths are:
sh_eth_set_link_ksettings (acquire the spinlock)
  phy_ethtool_ksettings_set
phy_start_aneg
  phy_start_aneg_priv
mutex_lock --> may sleep

sh_eth_nway_reset (acquire the spinlock)
  phy_start_aneg
phy_start_aneg_priv
  mutex_lock --> may sleep

I do not find a good way to fix them, so I only report.
These possible bugs are found by my static analysis tool (DSAC) and 
checked by my code review.



Thanks,
Jia-Ju Bai

[PATCH] mmc: renesas_sdhi: Add MODULE_LICENSE

[Yoshihiro Shimoda]

From: Masaharu Hayakawa 

The following error occurs when loading renesas_sdhi_core.c module,
so add MODULE_LICENSE("GPL v2").

 renesas_sdhi_core: module license 'unspecified' taints kernel.

Signed-off-by: Masaharu Hayakawa 
Fixes: 9d08428afb72 ("mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main module 
file")
Cc:  # v4.13+
[Shimoda: Added Fixes tag and Cc to the stable ML]
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/mmc/host/renesas_sdhi_core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/mmc/host/renesas_sdhi_core.c 
b/drivers/mmc/host/renesas_sdhi_core.c
index fcf7235..157e1d9 100644
--- a/drivers/mmc/host/renesas_sdhi_core.c
+++ b/drivers/mmc/host/renesas_sdhi_core.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -667,3 +668,5 @@ int renesas_sdhi_remove(struct platform_device *pdev)
return 0;
 }
 EXPORT_SYMBOL_GPL(renesas_sdhi_remove);
+
+MODULE_LICENSE("GPL v2");
-- 
1.9.1

Hang on Salvator-X(S) with v4.15-rc3

[Geert Uytterhoeven]

With the attached config, Salvator-X(S) (H3 ES1/2 and M3-W) hang during boot.
This does not happen with renesas-defconfig.


WARNING: possible recursive locking detected
4.15.0-rc3-salvator-x #1515 Not tainted

kworker/2:1/58 is trying to acquire lock:
 ((wq_completion)"events"){+.+.}, at: []
wait_for_completion+0x14/0x1c

but task is already holding lock:
 ((wq_completion)"events"){+.+.}, at: []
process_one_work+0x1a8/0x648

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock((wq_completion)"events");
  lock((wq_completion)"events");

 *** DEADLOCK ***

 May be due to missing lock nesting notation

3 locks held by kworker/2:1/58:
 #0:  ((wq_completion)"events"){+.+.}, at: []
process_one_work+0x1a8/0x648
 #1:  (deferred_probe_work){+.+.}, at: []
process_one_work+0x1a8/0x648
 #2:  (>mutex){}, at: [<78a5bb8f>] __device_attach+0x28/0xf8

stack backtrace:
CPU: 2 PID: 58 Comm: kworker/2:1 Not tainted 4.15.0-rc3-salvator-x #1515
Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
Workqueue: events deferred_probe_work_func
Call trace:
 dump_backtrace+0x0/0x118
 show_stack+0x14/0x1c
 dump_stack+0xb4/0xf0
 __lock_acquire+0xfe0/0x1208
 lock_acquire+0x19c/0x24c
 wait_for_common+0x68/0x1f0
 wait_for_completion+0x14/0x1c
 flush_workqueue+0x19c/0x3c4
 drm_mode_config_cleanup+0x84/0x22c
 rcar_du_remove+0x38/0x50
 rcar_du_probe+0x114/0x12c
 platform_drv_probe+0x58/0xa4
 driver_probe_device+0x178/0x2f8
 __device_attach_driver+0xa0/0xb0
 bus_for_each_drv+0x74/0x90
 __device_attach+0x90/0xf8
 device_initial_probe+0x10/0x18
 bus_probe_device+0x2c/0x90
 deferred_probe_work_func+0x108/0x13c
 process_one_work+0x328/0x648
 process_scheduled_works+0x30/0x40
 worker_thread+0x260/0x350
 kthread+0x158/0x160
 ret_from_fork+0x10/0x18

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds


salvator-config.gz
Description: GNU Zip compressed data

Re: [PATCH] gpio: Add helpers to determin direction of gpiods

[Wolfram Sang]

Hey Linus,

thanks for doing this.

On Sun, Dec 10, 2017 at 01:23:40AM +0100, Linus Walleij wrote:
> The gpiod_get_direction() returns 1 for input and 0 for output
> but it's pretty hard to remember which one is which and generally
> unintuitive and messy to provide #defines so let's simply add
> two static inlines to do the job.
> 
> Cc: Wolfram Sang 
> Suggested-by: Wolfram Sang 
> Signed-off-by: Linus Walleij 
> ---
>  Documentation/gpio/consumer.txt | 14 +++---
>  include/linux/gpio/consumer.h   | 25 +
>  2 files changed, 36 insertions(+), 3 deletions(-)

You need to fix the kerneldoc for 'gpiod_get_direction", too. It still
mentions GPIOF_DIR_*.

> +static inline bool gpiod_is_input(struct gpio_desc *desc)
> +{
> + int ret = gpiod_get_direction(desc);
> + if (ret < 0) {
> + pr_err("GPIO: failed to get direction\n");

Is that really helpful for the user if we don't say which GPIO failed?

> + /* It is usually safest to assume we are input */
> + return true;
> + }
> + return !!ret;
> +}

Regards,

   Wolfram



signature.asc
Description: PGP signature

Re: arm64: unhandled level 0 translation fault

[Geert Uytterhoeven]

Hi Will,

On Tue, Dec 12, 2017 at 5:57 PM, Will Deacon  wrote:
> On Tue, Dec 12, 2017 at 05:00:33PM +0100, Geert Uytterhoeven wrote:
>> On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven
>>  wrote:
>> > On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon  wrote:
>> >> On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
>> >>> During userspace (Debian jessie NFS root) boot on arm64:
>> >>>
>> >>> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
>> >>> esr 0x9204, in dash[adf77000+1a000]
>> >>> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
>> >>> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
>> >>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 
>> >>> ES2.0+ (DT)
>> >>> pstate: 8000 (Nzcv daif -PAN -UAO)
>> >>> pc : 0xadf8a51c
>> >>> lr : 0xadf8ac08
>> >>> sp : cffeac00
>> >>> x29: cffeac00 x28: adfa1000
>> >>> x27: cffebf7c x26: cffead20
>> >>> x25: cea1c5f0 x24: 
>> >>> x23: adfa1000 x22: adfa1000
>> >>> x21:  x20: 0008
>> >>> x19:  x18: cffeb500
>> >>> x17: a22babfc x16: adfa1ae8
>> >>> x15: a2363588 x14: 
>> >>> x13: 0020 x12: 0010
>> >>> x11: 0101010101010101 x10: adfa1000
>> >>> x9 : ff81 x8 : adfa2000
>> >>> x7 :  x6 : 
>> >>> x5 : adfa2338 x4 : adfa2000
>> >>> x3 : adfa2338 x2 : 
>> >>> x1 : adfa28b0 x0 : adfa4c30
>> >>>
>> >>> Sometimes it happens with other processes, but the main address, esr, and
>> >>> pstate values are always the same.
>> >>>
>> >>> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
>> >>> releases, so the last time was two weeks ago), but never saw the issue
>> >>> before until today, so probably v4.15-rc1 is OK.
>> >>> Unfortunately it doesn't happen during every boot, which makes it
>> >>> cumbersome to bisect.
>> >>>
>> >>> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
>> >>> and even without today's arm64/for-next/core merged in, I still managed 
>> >>> to
>> >>> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
>> >>> v4.15-rc3.
>> >>
>> >> Urgh, this looks nasty. Thanks for the report! A few questions:
>> >>
>> >>  - Can you share your .config somewhere please?
>> >
>> > I managed to reproduce it on plain v4.15-rc3 using both arm64_defconfig, 
>> > and
>> > renesas_defconfig (from Simon's repo).
>>
>> v4.15-rc2 is affected, too.
>
> Do you reckon you can bisect between -rc1 and -rc2? We've been unable to
> reproduce this on any of our systems, unfortunately.

I've tried, but ended up on an unrelated XFS merge commit. Probably I
marked a few commits good due to not seeing this heisenbug.

For reference, here's the bisect log.

Bad commits showed one or both of "unhandled level 0 translation fault" and
"invalid pointer". Good commits didn't show any during 6 tries.

git bisect start
# bad: [ae64f9bd1d3621b5e60d7363bc20afb46aede215] Linux 4.15-rc2
git bisect bad ae64f9bd1d3621b5e60d7363bc20afb46aede215
# good: [4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323] Linux 4.15-rc1
git bisect good 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323
# good: [9e0600f5cf6cecfcab5046d1453a9538c054d8a7] Merge tag
'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
git bisect good 9e0600f5cf6cecfcab5046d1453a9538c054d8a7
# good: [503505bfea19b7d69e2572297e6defa0f9c2404e] Merge branch
'drm-fixes-4.15' of git://people.freedesktop.org/~agd5f/linux into
drm-fixes
git bisect good 503505bfea19b7d69e2572297e6defa0f9c2404e
# good: [ae753ee2771a1bacade56411bb98037b2545c929] Merge tag
'afs-fixes-20171201' of
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
git bisect good ae753ee2771a1bacade56411bb98037b2545c929
# good: [e1ba1c99dad92c5917b22b1047cf36e4426b124a] Merge tag
'riscv-for-linus-4.15-rc2_cleanups' of
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux
git bisect good e1ba1c99dad92c5917b22b1047cf36e4426b124a
# bad: [2db767d9889cef087149a5eaa35c1497671fa40f] Merge tag
'nfs-for-4.15-2' of git://git.linux-nfs.org/projects/anna/linux-nfs
git bisect bad 2db767d9889cef087149a5eaa35c1497671fa40f
# good: [22a6c83777ac7c17d6c63891beeeac24cf5da450] xfs: ubsan fixes
git bisect good 22a6c83777ac7c17d6c63891beeeac24cf5da450
# bad: [788c1da05b73aee68ed98f05b577c308351f5619] Merge tag
'xfs-4.15-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux
git bisect bad 788c1da05b73aee68ed98f05b577c308351f5619
# good: [3b42d385753c22b29d259ccb9d4c3f419e583b30] xfs: scrub inode
mode properly
git bisect good 3b42d385753c22b29d259ccb9d4c3f419e583b30
# good: [373b0589dc8d58bc09c9a28d03611ae4fb216057] xfs: Properly retry
failed dquot items in case of error during buffer writeback
git bisect 

Re: [PATCH 1/2] PCI: rcar: Fix use-after-free in probe error path

[Bjorn Helgaas]

On Thu, Dec 07, 2017 at 11:15:19AM +0100, Geert Uytterhoeven wrote:
> If CONFIG_DEBUG_SLAB=y, and no PCIe card is inserted, the kernel crashes
> during probe on r8a7791/koelsch:
> 
> rcar-pcie fe00.pcie: PCIe link down
> Unable to handle kernel paging request at virtual address 6b6b6b6b
> 
> (seeing this message requires earlycon and keep_bootcon).
> 
> Indeed, pci_free_host_bridge() frees the PCI host bridge, including the
> embedded rcar_pcie object, so pci_free_resource_list() must not be
> called afterwards.
> 
> To fix this, move the call to pci_free_resource_list() up, and update the
> label name accordingly.
> 
> Fixes: ddd535f1ea3eb27e ("PCI: rcar: Fix memory leak when no PCIe card is 
> inserted")
> Signed-off-by: Geert Uytterhoeven 

Applied with Simon's and Lorenzo's acks to for-linus for v4.15, thanks!

I'll leave the second patch up to Lorenzo for v4.16, since it doesn't seem
as critical.

> ---
>  drivers/pci/host/pcie-rcar.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
> index 12796eccb2befd91..52ab3cb0a0bfe065 100644
> --- a/drivers/pci/host/pcie-rcar.c
> +++ b/drivers/pci/host/pcie-rcar.c
> @@ -1128,12 +1128,12 @@ static int rcar_pcie_probe(struct platform_device 
> *pdev)
>   err = rcar_pcie_get_resources(pcie);
>   if (err < 0) {
>   dev_err(dev, "failed to request resources: %d\n", err);
> - goto err_free_bridge;
> + goto err_free_resource_list;
>   }
>  
>   err = rcar_pcie_parse_map_dma_ranges(pcie, dev->of_node);
>   if (err)
> - goto err_free_bridge;
> + goto err_free_resource_list;
>  
>   pm_runtime_enable(dev);
>   err = pm_runtime_get_sync(dev);
> @@ -1176,9 +1176,9 @@ static int rcar_pcie_probe(struct platform_device *pdev)
>  err_pm_disable:
>   pm_runtime_disable(dev);
>  
> -err_free_bridge:
> - pci_free_host_bridge(bridge);
> +err_free_resource_list:
>   pci_free_resource_list(>resources);
> + pci_free_host_bridge(bridge);
>  
>   return err;
>  }
> -- 
> 2.7.4
> 

[PATCH 3/3] ARM: dts: r8a7745: Add CMT SoC specific support

[Fabrizio Castro]

Add CMT[01] support to SoC DT.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 arch/arm/boot/dts/r8a7745.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7745.dtsi b/arch/arm/boot/dts/r8a7745.dtsi
index 0fa7861..765a80d 100644
--- a/arch/arm/boot/dts/r8a7745.dtsi
+++ b/arch/arm/boot/dts/r8a7745.dtsi
@@ -235,6 +235,36 @@
  IRQ_TYPE_LEVEL_LOW)>;
};
 
+   cmt0: timer@ffca {
+   compatible = "renesas,r8a7745-cmt0",
+"renesas,rcar-gen2-cmt0";
+   reg = <0 0xffca 0 0x1004>;
+   interrupts = ,
+;
+   clocks = < CPG_MOD 124>;
+   clock-names = "fck";
+   power-domains = < R8A7745_PD_ALWAYS_ON>;
+   resets = < 124>;
+   };
+
+   cmt1: timer@e613 {
+   compatible = "renesas,r8a7745-cmt1",
+"renesas,rcar-gen2-cmt1";
+   reg = <0 0xe613 0 0x1004>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+;
+   clocks = < CPG_MOD 329>;
+   clock-names = "fck";
+   power-domains = < R8A7745_PD_ALWAYS_ON>;
+   resets = < 329>;
+   };
+
cpg: clock-controller@e615 {
compatible = "renesas,r8a7745-cpg-mssr";
reg = <0 0xe615 0 0x1000>;
-- 
2.7.4

[PATCH 2/3] ARM: dts: r8a7743: Add CMT SoC specific support

[Fabrizio Castro]

Add CMT[01] support to SoC DT.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 arch/arm/boot/dts/r8a7743.dtsi | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 59860c8..0e2834a 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -262,6 +262,36 @@
  IRQ_TYPE_LEVEL_LOW)>;
};
 
+   cmt0: timer@ffca {
+   compatible = "renesas,r8a7743-cmt0",
+"renesas,rcar-gen2-cmt0";
+   reg = <0 0xffca 0 0x1004>;
+   interrupts = ,
+;
+   clocks = < CPG_MOD 124>;
+   clock-names = "fck";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 124>;
+   };
+
+   cmt1: timer@e613 {
+   compatible = "renesas,r8a7743-cmt1",
+"renesas,rcar-gen2-cmt1";
+   reg = <0 0xe613 0 0x1004>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+;
+   clocks = < CPG_MOD 329>;
+   clock-names = "fck";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 329>;
+   };
+
cpg: clock-controller@e615 {
compatible = "renesas,r8a7743-cpg-mssr";
reg = <0 0xe615 0 0x1000>;
-- 
2.7.4

[PATCH 1/3] dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support

[Fabrizio Castro]

Document SoC specific compatible strings for r8a7743 and r8a7745.
No driver change is needed as the fallback strings will activate
the right code.

Signed-off-by: Fabrizio Castro 
Reviewed-by: Biju Das 
---
 Documentation/devicetree/bindings/timer/renesas,cmt.txt | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/timer/renesas,cmt.txt 
b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
index d740989..1e4fe98 100644
--- a/Documentation/devicetree/bindings/timer/renesas,cmt.txt
+++ b/Documentation/devicetree/bindings/timer/renesas,cmt.txt
@@ -22,6 +22,10 @@ Required Properties:
 
 - "renesas,r8a73a4-cmt0" for the 32-bit CMT0 device included in r8a73a4.
 - "renesas,r8a73a4-cmt1" for the 48-bit CMT1 device included in r8a73a4.
+- "renesas,r8a7743-cmt0" for the 32-bit CMT0 device included in r8a7743.
+- "renesas,r8a7743-cmt1" for the 48-bit CMT1 device included in r8a7743.
+- "renesas,r8a7745-cmt0" for the 32-bit CMT0 device included in r8a7745.
+- "renesas,r8a7745-cmt1" for the 48-bit CMT1 device included in r8a7745.
 - "renesas,r8a7790-cmt0" for the 32-bit CMT0 device included in r8a7790.
 - "renesas,r8a7790-cmt1" for the 48-bit CMT1 device included in r8a7790.
 - "renesas,r8a7791-cmt0" for the 32-bit CMT0 device included in r8a7791.
@@ -31,9 +35,11 @@ Required Properties:
 - "renesas,r8a7794-cmt0" for the 32-bit CMT0 device included in r8a7794.
 - "renesas,r8a7794-cmt1" for the 48-bit CMT1 device included in r8a7794.
 
-- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2.
-- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2.
-   These are fallbacks for r8a73a4 and all the R-Car Gen2
+- "renesas,rcar-gen2-cmt0" for 32-bit CMT0 devices included in R-Car Gen2 
or
+   RZ/G1.
+- "renesas,rcar-gen2-cmt1" for 48-bit CMT1 devices included in R-Car Gen2 
or
+   RZ/G1.
+   These are fallbacks for r8a73a4, all the R-Car Gen2 and RZ/G1
entries listed above.
 
   - reg: base address and length of the registers block for the timer module.
-- 
2.7.4

[PATCH 0/3] Add CMT support to r8a774[35]

[Fabrizio Castro]

This series adds CMT support for r8a7743 and r8a7745.

Thanks,

Fabrizio Castro (3):
  dt-bindings: timer: renesas, cmt: Document r8a774[35] CMT support
  ARM: dts: r8a7743: Add CMT SoC specific support
  ARM: dts: r8a7745: Add CMT SoC specific support

 .../devicetree/bindings/timer/renesas,cmt.txt  | 12 ++---
 arch/arm/boot/dts/r8a7743.dtsi | 30 ++
 arch/arm/boot/dts/r8a7745.dtsi | 30 ++
 3 files changed, 69 insertions(+), 3 deletions(-)

-- 
2.7.4

[PATCH 2/5] ARM: dts: r8a7743: Add audio clocks

[Biju Das]

Describe the external audio clocks required by the sound driver.
Boards that provide audio clocks need to override the clock frequencies.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/r8a7743.dtsi | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index c09c667..2f0ec9d 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1238,6 +1238,29 @@
clock-frequency = <0>;
};
 
+   /*
+* The external audio clocks are configured as 0 Hz fixed frequency
+* clocks by default.
+* Boards that provide audio clocks should override them.
+*/
+   audio_clk_a: audio_clk_a {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   audio_clk_b: audio_clk_b {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   audio_clk_c: audio_clk_c {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
/* External USB clock - can be overridden by the board */
usb_extal_clk: usb_extal {
compatible = "fixed-clock";
-- 
1.9.1

[PATCH 5/5] ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec

[Biju Das]

This patch enables SGTL5000 audio codec on the carrier board.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/iwg20d-q7-common.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm/boot/dts/iwg20d-q7-common.dtsi 
b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
index 54470c6..2070b14 100644
--- a/arch/arm/boot/dts/iwg20d-q7-common.dtsi
+++ b/arch/arm/boot/dts/iwg20d-q7-common.dtsi
@@ -20,6 +20,20 @@
stdout-path = "serial0:115200n8";
};
 
+   audio_clock: audio_clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2600>;
+   };
+
+   reg_1p5v: 1p5v {
+   compatible = "regulator-fixed";
+   regulator-name = "1P5V";
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-always-on;
+   };
+
vcc_sdhi1: regulator-vcc-sdhi1 {
compatible = "regulator-fixed";
 
@@ -83,6 +97,16 @@
compatible = "ti,bq32000";
reg = <0x68>;
};
+
+   sgtl5000: codec@0a {
+   compatible = "fsl,sgtl5000";
+   #sound-dai-cells = <0>;
+   reg = <0x0a>;
+   clocks = <_clock>;
+   VDDA-supply = <_3p3v>;
+   VDDIO-supply = <_3p3v>;
+   VDDD-supply = <_1p5v>;
+   };
 };
 
  {
-- 
1.9.1

[PATCH 3/5] ARM: dts: r8a7743: Add audio DMAC support

[Biju Das]

Instantiate the two audio DMA controllers on the r8a7743 device tree.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/r8a7743.dtsi | 62 ++
 1 file changed, 62 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index 2f0ec9d..b60527a 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -359,6 +359,68 @@
dma-channels = <15>;
};
 
+   audma0: dma-controller@ec70 {
+   compatible = "renesas,dmac-r8a7743",
+"renesas,rcar-dmac";
+   reg = <0 0xec70 0 0x1>;
+   interrupts = ;
+   interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12";
+   clocks = < CPG_MOD 502>;
+   clock-names = "fck";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 502>;
+   #dma-cells = <1>;
+   dma-channels = <13>;
+   };
+
+   audma1: dma-controller@ec72 {
+   compatible = "renesas,dmac-r8a7743",
+"renesas,rcar-dmac";
+   reg = <0 0xec72 0 0x1>;
+   interrupts = ;
+   interrupt-names = "error",
+ "ch0", "ch1", "ch2", "ch3",
+ "ch4", "ch5", "ch6", "ch7",
+ "ch8", "ch9", "ch10", "ch11",
+ "ch12";
+   clocks = < CPG_MOD 501>;
+   clock-names = "fck";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 501>;
+   #dma-cells = <1>;
+   dma-channels = <13>;
+   };
+
usb_dmac0: dma-controller@e65a {
compatible = "renesas,r8a7743-usb-dmac",
 "renesas,usb-dmac";
-- 
1.9.1

[PATCH 1/5] ARM: shmobile: defconfig: Enable SGTL5000 audio codec

[Biju Das]

The iWave RZ/G1M Q7 carrier board supports I2S audio codec "SGTL5000".

To increase hardware support enable the driver in the shmobile_defconfig
multiplatform configuration.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/configs/shmobile_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/shmobile_defconfig 
b/arch/arm/configs/shmobile_defconfig
index 7b4fc01..d60dbe1 100644
--- a/arch/arm/configs/shmobile_defconfig
+++ b/arch/arm/configs/shmobile_defconfig
@@ -173,6 +173,7 @@ CONFIG_SND_SOC=y
 CONFIG_SND_SOC_SH4_FSI=y
 CONFIG_SND_SOC_RCAR=y
 CONFIG_SND_SOC_AK4642=y
+CONFIG_SND_SOC_SGTL5000=y
 CONFIG_SND_SOC_WM8978=y
 CONFIG_SND_SIMPLE_SCU_CARD=y
 CONFIG_USB=y
-- 
1.9.1

[PATCH 4/5] ARM: dts: r8a7743: Add sound support

[Biju Das]

Define the generic r8a7743(RZ/G1M) part of  the sound device node.

This patch is based on the r8a7791 sound work by Kuninori Morimoto.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 arch/arm/boot/dts/r8a7743.dtsi | 185 +
 1 file changed, 185 insertions(+)

diff --git a/arch/arm/boot/dts/r8a7743.dtsi b/arch/arm/boot/dts/r8a7743.dtsi
index b60527a..59860c8 100644
--- a/arch/arm/boot/dts/r8a7743.dtsi
+++ b/arch/arm/boot/dts/r8a7743.dtsi
@@ -1290,6 +1290,191 @@
resets = < 319>;
status = "disabled";
};
+
+   rcar_sound: sound@ec50 {
+   /*
+* #sound-dai-cells is required
+*
+* Single DAI : #sound-dai-cells = <0>; 
<_sound>;
+* Multi  DAI : #sound-dai-cells = <1>; 
<_sound N>;
+*/
+   compatible = "renesas,rcar_sound-r8a7743",
+"renesas,rcar_sound-gen2";
+   reg = <0 0xec50 0 0x1000>, /* SCU */
+ <0 0xec5a 0 0x100>,  /* ADG */
+ <0 0xec54 0 0x1000>, /* SSIU */
+ <0 0xec541000 0 0x280>,  /* SSI */
+ <0 0xec74 0 0x200>;  /* Audio DMAC peri peri*/
+   reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+
+   clocks = < CPG_MOD 1005>,
+< CPG_MOD 1006>, < CPG_MOD 1007>,
+< CPG_MOD 1008>, < CPG_MOD 1009>,
+< CPG_MOD 1010>, < CPG_MOD 1011>,
+< CPG_MOD 1012>, < CPG_MOD 1013>,
+< CPG_MOD 1014>, < CPG_MOD 1015>,
+< CPG_MOD 1022>, < CPG_MOD 1023>,
+< CPG_MOD 1024>, < CPG_MOD 1025>,
+< CPG_MOD 1026>, < CPG_MOD 1027>,
+< CPG_MOD 1028>, < CPG_MOD 1029>,
+< CPG_MOD 1030>, < CPG_MOD 1031>,
+< CPG_MOD 1021>, < CPG_MOD 1020>,
+< CPG_MOD 1021>, < CPG_MOD 1020>,
+< CPG_MOD 1019>, < CPG_MOD 1018>,
+<_clk_a>, <_clk_b>, <_clk_c>,
+< CPG_CORE R8A7743_CLK_M2>;
+   clock-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6", 
"ssi.5",
+ "ssi.4", "ssi.3", "ssi.2", "ssi.1", 
"ssi.0",
+ "src.9", "src.8", "src.7", "src.6", 
"src.5",
+ "src.4", "src.3", "src.2", "src.1", 
"src.0",
+ "ctu.0", "ctu.1",
+ "mix.0", "mix.1",
+ "dvc.0", "dvc.1",
+ "clk_a", "clk_b", "clk_c", "clk_i";
+   power-domains = < R8A7743_PD_ALWAYS_ON>;
+   resets = < 1005>,
+< 1006>, < 1007>, < 1008>, < 
1009>,
+< 1010>, < 1011>, < 1012>, < 
1013>,
+< 1014>, < 1015>;
+   reset-names = "ssi-all",
+ "ssi.9", "ssi.8", "ssi.7", "ssi.6", 
"ssi.5",
+ "ssi.4", "ssi.3", "ssi.2", "ssi.1", 
"ssi.0";
+   status = "disabled";
+
+   rcar_sound,dvc {
+   dvc0: dvc-0 {
+   dmas = < 0xbc>;
+   dma-names = "tx";
+   };
+   dvc1: dvc-1 {
+   dmas = < 0xbe>;
+   dma-names = "tx";
+   };
+   };
+
+   rcar_sound,mix {
+   mix0: mix-0 { };
+   mix1: mix-1 { };
+   };
+
+   rcar_sound,ctu {
+   ctu00: ctu-0 { };
+   ctu01: ctu-1 { };
+   ctu02: ctu-2 { };
+   ctu03: ctu-3 { };
+   ctu10: ctu-4 { };
+   ctu11: ctu-5 { };
+   ctu12: ctu-6 { };
+   ctu13: ctu-7 { };
+   };
+
+   rcar_sound,src {
+   src0: 

[PATCH 0/5] Add Sound support for iWave RZ/G1M board

[Biju Das]

This series aims to add sound support for iWave RZ/G1M board.

This patch series has documentation dependency on 
https://patchwork.kernel.org/patch/10108014/

Biju Das (5):
  ARM: shmobile: defconfig: Enable SGTL5000 audio codec
  ARM: dts: r8a7743: Add audio clocks
  ARM: dts: r8a7743: Add audio DMAC support
  ARM: dts: r8a7743: Add sound support
  ARM: dts: iwg20d-q7-common: Enable SGTL5000 audio codec

 arch/arm/boot/dts/iwg20d-q7-common.dtsi |  24 +++
 arch/arm/boot/dts/r8a7743.dtsi  | 270 
 arch/arm/configs/shmobile_defconfig |   1 +
 3 files changed, 295 insertions(+)

-- 
1.9.1

[PATCH] dt-bindings: ASoC: rsnd: Add device tree support for r8a774[35]

[Biju Das]

Document r8a774[35] specific compatible strings. The Renesas RZ/G1[ME]
(r8a774[35]) sound modules are identical to the R-Car Gen2 family.
No driver change is needed as the fallback compatible string
"renesas,rcar_sound-gen2" activates the right code in the driver.

Signed-off-by: Biju Das 
Reviewed-by: Fabrizio Castro 
---
 Documentation/devicetree/bindings/sound/renesas,rsnd.txt | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt 
b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index 085bec3..b3c28bd 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -4,7 +4,7 @@ Renesas R-Car sound
 * Modules
 =
 
-Renesas R-Car sound is constructed from below modules
+Renesas R-Car and RZ/G sound is constructed from below modules
 (for Gen2 or later)
 
  SCU   : Sampling Rate Converter Unit
@@ -334,9 +334,11 @@ Required properties:
 
 - compatible   : "renesas,rcar_sound-", fallbacks
  "renesas,rcar_sound-gen1" if generation1, and
- "renesas,rcar_sound-gen2" if generation2
+ "renesas,rcar_sound-gen2" if generation2 (or 
RZ/G1)
  "renesas,rcar_sound-gen3" if generation3
  Examples with soctypes are:
+   - "renesas,rcar_sound-r8a7743" (RZ/G1M)
+   - "renesas,rcar_sound-r8a7745" (RZ/G1E)
- "renesas,rcar_sound-r8a7778" (R-Car M1A)
- "renesas,rcar_sound-r8a7779" (R-Car H1)
- "renesas,rcar_sound-r8a7790" (R-Car H2)
-- 
1.9.1

Re: [PATCH 0/2] PCI: rcar: Misc error path fixes

[Lorenzo Pieralisi]

On Tue, Dec 12, 2017 at 11:16:58AM -0600, Bjorn Helgaas wrote:
> On Thu, Dec 07, 2017 at 11:15:18AM +0100, Geert Uytterhoeven wrote:
> > Hi Simon, Lorenzo, Bjorn,
> > 
> > This patch series fixes two issues in the error path for the R-Car PCIe
> > host bridge driver.
> > 
> > The first issue is triggered easily by not having a PCIe card inserted,
> > and may cause a crash.
> > 
> > Thanks!
> > 
> > Geert Uytterhoeven (2):
> >   PCI: rcar: Fix use-after-free in probe error path
> >   PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures
> > 
> >  drivers/pci/host/pcie-rcar.c | 11 +++
> >  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> The first fixes ddd535f1ea3eb27e, which appeared in v4.14-rc1.  The
> second fixes 5d2917d469faab72, which appeared in v4.5-rc1.
> 
> After the merge window I normally just pull in critical fixes and
> fixes to things we merged during the window.
> 
> I think the first makes sense for v4.15 because it can cause a crash
> with no obvious way to debug it.  The second one feels like v4.16
> material to me.
> 
> Thoughts?  We're trying to sort out how to handle this sort of thing
> between Lorenzo and myself, so I apologize for the confusion here.

This sounds absolutely reasonable for me.

Thanks !
Lorenzo

Re: [PATCH 0/2] PCI: rcar: Misc error path fixes

[Geert Uytterhoeven]

Hi Bjorn,

On Tue, Dec 12, 2017 at 6:16 PM, Bjorn Helgaas  wrote:
> On Thu, Dec 07, 2017 at 11:15:18AM +0100, Geert Uytterhoeven wrote:
>> This patch series fixes two issues in the error path for the R-Car PCIe
>> host bridge driver.
>>
>> The first issue is triggered easily by not having a PCIe card inserted,
>> and may cause a crash.
>>
>> Thanks!
>>
>> Geert Uytterhoeven (2):
>>   PCI: rcar: Fix use-after-free in probe error path
>>   PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures
>>
>>  drivers/pci/host/pcie-rcar.c | 11 +++
>>  1 file changed, 7 insertions(+), 4 deletions(-)
>
> The first fixes ddd535f1ea3eb27e, which appeared in v4.14-rc1.  The
> second fixes 5d2917d469faab72, which appeared in v4.5-rc1.
>
> After the merge window I normally just pull in critical fixes and
> fixes to things we merged during the window.
>
> I think the first makes sense for v4.15 because it can cause a crash
> with no obvious way to debug it.  The second one feels like v4.16
> material to me.
>
> Thoughts?  We're trying to sort out how to handle this sort of thing
> between Lorenzo and myself, so I apologize for the confusion here.

Sounds fine to me.
The first one happens all the time if no PCIe card is present.
The second one is non-critical.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] gpio: gpio-rcar: Support S2RAM

[Yoshihiro Kaneko]

Hi Simon-san, Geert-san,

I am sorry for my late reply.

2017-12-07 19:27 GMT+09:00 Simon Horman :
> On Thu, Dec 07, 2017 at 10:26:53AM +0100, Geert Uytterhoeven wrote:
>> On Thu, Dec 7, 2017 at 10:21 AM, Geert Uytterhoeven
>>  wrote:
>> >>> >  struct gpio_rcar_priv {
>> >>> > void __iomem *base;
>> >>> > spinlock_t lock;
>> >>> > @@ -41,6 +51,7 @@ struct gpio_rcar_priv {
>> >>> > unsigned int irq_parent;
>> >>> > bool has_both_edge_trigger;
>> >>> > bool needs_clk;
>> >>> > +   struct gpio_rcar_bank_info bank_info[32];
>> >>>
>> >>> That's 32 x 7 = 224 bytes in total.
>> >>>
>> >>> What about just using 7 u32s instead, one for each register to save?
>> >>> That way you only need 7 x 4 = 28 bytes, and you can probably optimize
>> >>> the code to just save/restore the whole register at once.
>> >>
>> >> So the suggestion is to use a u32 instead of struct gpio_rcar_bank_info,
>> >> and for each field of struct gpio_rcar_bank_info use a bit in the u32?
>> >>
>> >> If so, probably one could go a step further and use a u8 as there are
>> >> currently only 7 fields, thus using 32 x 1 = 32 bytes rather than
>> >> 32 x 4 = 128 bytes.
>> >
>> > I think you misunderstood.
>> > The patch has one gpio_rcar_bank_info for each GPIO.
>> > Each bank has 7 bits (bools), one for each register.
>> > Indexing is done through bank_info[]..
>> > Saving/restoring bits requires converting from hardware register layout to
>> > stored layout ("transposing a 32 x 7 matrix to a 7 x 32 matrix").
>> >
>> > I proposed 7 u32s, one for each register, storing the similar bits for all
>> > 32 GPIOs.
>> > So indexing is reversed, becoming regs[] & BIT(), which is
>> > similar to how the data is stored in hardware registers.
>> > Storing all bits related to a single register in a single u32 may allow to
>> > save/restore all bits of the register in a single operation.
>>
>> More clarification: it's the difference between "int array[7][32]" and
>> "int array[32][7]".  Both store the same amount of data.
>> But if the hardware uses the former organization, you want to
>> save/restore using the same organization, else it requires an expensive
>> transformation.
>
> Thanks, you are correct that I misunderstood.
> I understand now.
>
> Kaneko-san, could you take a look at switching this around and posting an RFT?

Sure, will do.

Thanks,
Kaneko

Re: [PATCH 0/2] PCI: rcar: Misc error path fixes

[Bjorn Helgaas]

On Thu, Dec 07, 2017 at 11:15:18AM +0100, Geert Uytterhoeven wrote:
>   Hi Simon, Lorenzo, Bjorn,
> 
> This patch series fixes two issues in the error path for the R-Car PCIe
> host bridge driver.
> 
> The first issue is triggered easily by not having a PCIe card inserted,
> and may cause a crash.
> 
> Thanks!
> 
> Geert Uytterhoeven (2):
>   PCI: rcar: Fix use-after-free in probe error path
>   PCI: rcar: Handle rcar_pcie_parse_request_of_pci_ranges() failures
> 
>  drivers/pci/host/pcie-rcar.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)

The first fixes ddd535f1ea3eb27e, which appeared in v4.14-rc1.  The
second fixes 5d2917d469faab72, which appeared in v4.5-rc1.

After the merge window I normally just pull in critical fixes and
fixes to things we merged during the window.

I think the first makes sense for v4.15 because it can cause a crash
with no obvious way to debug it.  The second one feels like v4.16
material to me.

Thoughts?  We're trying to sort out how to handle this sort of thing
between Lorenzo and myself, so I apologize for the confusion here.

Bjorn

Re: arm64: unhandled level 0 translation fault

[Will Deacon]

On Tue, Dec 12, 2017 at 05:00:33PM +0100, Geert Uytterhoeven wrote:
> On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven
>  wrote:
> > On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon  wrote:
> >> On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
> >>> During userspace (Debian jessie NFS root) boot on arm64:
> >>>
> >>> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
> >>> esr 0x9204, in dash[adf77000+1a000]
> >>> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
> >>> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
> >>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 
> >>> ES2.0+ (DT)
> >>> pstate: 8000 (Nzcv daif -PAN -UAO)
> >>> pc : 0xadf8a51c
> >>> lr : 0xadf8ac08
> >>> sp : cffeac00
> >>> x29: cffeac00 x28: adfa1000
> >>> x27: cffebf7c x26: cffead20
> >>> x25: cea1c5f0 x24: 
> >>> x23: adfa1000 x22: adfa1000
> >>> x21:  x20: 0008
> >>> x19:  x18: cffeb500
> >>> x17: a22babfc x16: adfa1ae8
> >>> x15: a2363588 x14: 
> >>> x13: 0020 x12: 0010
> >>> x11: 0101010101010101 x10: adfa1000
> >>> x9 : ff81 x8 : adfa2000
> >>> x7 :  x6 : 
> >>> x5 : adfa2338 x4 : adfa2000
> >>> x3 : adfa2338 x2 : 
> >>> x1 : adfa28b0 x0 : adfa4c30
> >>>
> >>> Sometimes it happens with other processes, but the main address, esr, and
> >>> pstate values are always the same.
> >>>
> >>> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
> >>> releases, so the last time was two weeks ago), but never saw the issue
> >>> before until today, so probably v4.15-rc1 is OK.
> >>> Unfortunately it doesn't happen during every boot, which makes it
> >>> cumbersome to bisect.
> >>>
> >>> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
> >>> and even without today's arm64/for-next/core merged in, I still managed to
> >>> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
> >>> v4.15-rc3.
> >>
> >> Urgh, this looks nasty. Thanks for the report! A few questions:
> >>
> >>  - Can you share your .config somewhere please?
> >
> > I managed to reproduce it on plain v4.15-rc3 using both arm64_defconfig, and
> > renesas_defconfig (from Simon's repo).
> 
> v4.15-rc2 is affected, too.

Do you reckon you can bisect between -rc1 and -rc2? We've been unable to
reproduce this on any of our systems, unfortunately.

Will

Re: arm64: unhandled level 0 translation fault

[Geert Uytterhoeven]

Hi Will,

On Tue, Dec 12, 2017 at 4:11 PM, Geert Uytterhoeven
 wrote:
> On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon  wrote:
>> On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
>>> During userspace (Debian jessie NFS root) boot on arm64:
>>>
>>> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
>>> esr 0x9204, in dash[adf77000+1a000]
>>> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
>>> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
>>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ 
>>> (DT)
>>> pstate: 8000 (Nzcv daif -PAN -UAO)
>>> pc : 0xadf8a51c
>>> lr : 0xadf8ac08
>>> sp : cffeac00
>>> x29: cffeac00 x28: adfa1000
>>> x27: cffebf7c x26: cffead20
>>> x25: cea1c5f0 x24: 
>>> x23: adfa1000 x22: adfa1000
>>> x21:  x20: 0008
>>> x19:  x18: cffeb500
>>> x17: a22babfc x16: adfa1ae8
>>> x15: a2363588 x14: 
>>> x13: 0020 x12: 0010
>>> x11: 0101010101010101 x10: adfa1000
>>> x9 : ff81 x8 : adfa2000
>>> x7 :  x6 : 
>>> x5 : adfa2338 x4 : adfa2000
>>> x3 : adfa2338 x2 : 
>>> x1 : adfa28b0 x0 : adfa4c30
>>>
>>> Sometimes it happens with other processes, but the main address, esr, and
>>> pstate values are always the same.
>>>
>>> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
>>> releases, so the last time was two weeks ago), but never saw the issue
>>> before until today, so probably v4.15-rc1 is OK.
>>> Unfortunately it doesn't happen during every boot, which makes it
>>> cumbersome to bisect.
>>>
>>> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
>>> and even without today's arm64/for-next/core merged in, I still managed to
>>> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
>>> v4.15-rc3.
>>
>> Urgh, this looks nasty. Thanks for the report! A few questions:
>>
>>  - Can you share your .config somewhere please?
>
> I managed to reproduce it on plain v4.15-rc3 using both arm64_defconfig, and
> renesas_defconfig (from Simon's repo).

v4.15-rc2 is affected, too.

>>  - What was your last known-good kernel?
>
> v4.15-rc1.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Laurent Pinchart]

Hi Mauro,

On Tuesday, 12 December 2017 14:39:32 EET Mauro Carvalho Chehab wrote:
> Em Thu, 23 Nov 2017 15:21:01 +0100 Greg Kroah-Hartman escreveu:
> > On Thu, Nov 23, 2017 at 11:07:51AM -0200, Mauro Carvalho Chehab wrote:
> >> Em Thu, 16 Nov 2017 02:33:48 +0200 Laurent Pinchart escreveu:
> >>> Device unplug being asynchronous, it naturally races with operations
> >>> performed by userspace through ioctls or other file operations on
> >>> video device nodes.
> >>> 
> >>> This leads to potential access to freed memory or to other resources
> >>> during device access if unplug occurs during device access. To solve
> >>> this, we need to wait until all device access completes when
> >>> unplugging the device, and block all further access when the device is
> >>> being unplugged.
> >>> 
> >>> Three new functions are introduced. The video_device_enter() and
> >>> video_device_exit() functions must be used to mark entry and exit from
> >>> all code sections where the device can be accessed. The
> >>> video_device_unplug() function is then used in the unplug handler to
> >>> mark the device as being unplugged and wait for all access to
> >>> complete.
> >>> 
> >>> As an example mark the ioctl handler as a device access section. Other
> >>> file operations need to be protected too, and blocking ioctls (such as
> >>> VIDIOC_DQBUF) need to be handled as well.
> >>> 
> >>> Signed-off-by: Laurent Pinchart
> >>> 
> >>> ---
> >>> 
> >>>  drivers/media/v4l2-core/v4l2-dev.c | 57 ++
> >>>  include/media/v4l2-dev.h   | 47 ++
> >>>  2 files changed, 104 insertions(+)

[snip]

> >> I'm c/c Greg here, as I don't think, that, the way it is, it
> >> belongs at V4L2 core.
> >> 
> >> I mean: if this is a problem that affects all drivers, it would should,
> >> instead, be sitting at the driver's core.
> > 
> > What "problem" is trying to be solved here?  One where your specific
> > device type races with your specific user api?  Doesn't sound very
> > driver-core specific to me :)
> > 
> > As an example, what other bus/device type needs this?  If you can see
> > others that do, then sure, move it into the core.  But for just one, I
> > don't know if that's really needed here, do you?
> 
> The problem that this patch is trying to solve is related to
> hot-unplugging a platform device[1]. Quoting Laurent's comments about
> it on IRC:
> 
>   "it applies to all platform devices at least"

Note how I said "at least" :-) I2C, SPI and PCI devices are affected too, and 
after a closer look at USB today I believe USB devices are affected as well.

>   "I'm actually considering moving that code to the device core as
>it applies to all drivers that have device nodes, but I'm not
>sure that will be feasible it won't hurt other devices
>it applies to I2C and SPI as well at least and PCI too"
> 
> [1] https://linuxtv.org/irc/irclogger_log/media-maint?date=2017-11-23,Thu
> 
> For USB drivers, hot-unplug seems to work fine for media drivers,
> although keeping it working require tests from time to time, as
> it is not hard to break hotplug support. so, currently, I don't see
> the need of anything like that for non-platform drivers.

I2C, SPI and PCI are non-platform drivers, and USB seems to be affected too. 
The race window is small, making it difficult to reproduce the problem, but 
with carefully placed delays it gets much easier to hit the race.

> My point here is that adding a new lock inside the media core that
> would be used for all media drivers, including the ones that don't need
> doesn't sound a good idea.

Why not, if it doesn't affect performances (or anything else) negatively ?

> So, if this is something that applies to all platform drivers (including
> non-media ones), or if are there anything that can be done at driver's core
> that would improve hotplug support for all buses, making it more stable or
> easier to implement, then it would make sense to improve the driver's core.
> If not, this sounds a driver-specific issue whose fix doesn't belong to the
> media core.

It's clearly not a driver-specific issue as most, if not all, drivers are 
affected.

I've replied to Greg's e-mail in this thread with more details, let's try to 
keep the discussion there to avoid splitting it in multiple sub-threads.

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Laurent Pinchart]

Hi Greg and Mauro,

On Thursday, 23 November 2017 16:21:01 EET Greg Kroah-Hartman wrote:
> On Thu, Nov 23, 2017 at 11:07:51AM -0200, Mauro Carvalho Chehab wrote:
> > Em Thu, 16 Nov 2017 02:33:48 +0200 Laurent Pinchart escreveu:
> >> Device unplug being asynchronous, it naturally races with operations
> >> performed by userspace through ioctls or other file operations on video
> >> device nodes.
> >> 
> >> This leads to potential access to freed memory or to other resources
> >> during device access if unplug occurs during device access. To solve
> >> this, we need to wait until all device access completes when unplugging
> >> the device, and block all further access when the device is being
> >> unplugged.
> >> 
> >> Three new functions are introduced. The video_device_enter() and
> >> video_device_exit() functions must be used to mark entry and exit from
> >> all code sections where the device can be accessed. The
> >> video_device_unplug() function is then used in the unplug handler to
> >> mark the device as being unplugged and wait for all access to complete.
> >> 
> >> As an example mark the ioctl handler as a device access section. Other
> >> file operations need to be protected too, and blocking ioctls (such as
> >> VIDIOC_DQBUF) need to be handled as well.
> >> 
> >> Signed-off-by: Laurent Pinchart
> >> 
> >> ---
> >> 
> >>  drivers/media/v4l2-core/v4l2-dev.c | 57 
> >>  include/media/v4l2-dev.h   | 47 +++
> >>  2 files changed, 104 insertions(+)
> >> 
> >> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> >> b/drivers/media/v4l2-core/v4l2-dev.c index c647ba648805..c73c6d49e7cf
> >> 100644
> >> --- a/drivers/media/v4l2-core/v4l2-dev.c
> >> +++ b/drivers/media/v4l2-core/v4l2-dev.c
> >> @@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device
> >> *vdev)
> >>  }
> >>  EXPORT_SYMBOL(video_device_release_empty);
> >> 
> >> +int video_device_enter(struct video_device *vdev)
> >> +{
> >> +  bool unplugged;
> >> +
> >> +  spin_lock(>unplug_lock);
> >> +  unplugged = vdev->unplugged;
> >> +  if (!unplugged)
> >> +  vdev->access_refcount++;
> >> +  spin_unlock(>unplug_lock);
> >> +
> >> +  return unplugged ? -ENODEV : 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(video_device_enter);
> >> +
> >> +void video_device_exit(struct video_device *vdev)
> >> +{
> >> +  bool wake_up;
> >> +
> >> +  spin_lock(>unplug_lock);
> >> +  WARN_ON(--vdev->access_refcount < 0);
> >> +  wake_up = vdev->access_refcount == 0;
> >> +  spin_unlock(>unplug_lock);
> >> +
> >> +  if (wake_up)
> >> +  wake_up(>unplug_wait);
> >> +}
> >> +EXPORT_SYMBOL_GPL(video_device_exit);
> >> +
> >> +void video_device_unplug(struct video_device *vdev)
> >> +{
> >> +  bool unplug_blocked;
> >> +
> >> +  spin_lock(>unplug_lock);
> >> +  unplug_blocked = vdev->access_refcount > 0;
> >> +  vdev->unplugged = true;
> >> +  spin_unlock(>unplug_lock);
> >> +
> >> +  if (!unplug_blocked)
> >> +  return;
> >> +
> >> +  if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
> >> +  msecs_to_jiffies(15)))
> >> +  WARN(1, "Timeout waiting for device access to complete\n");
> >> +}
> >> +EXPORT_SYMBOL_GPL(video_device_unplug);
> >> +
> >>  static inline void video_get(struct video_device *vdev)
> >>  {
> >>get_device(>dev);
> >> @@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned
> >> int cmd, unsigned long arg)
> >>struct video_device *vdev = video_devdata(filp);
> >>int ret = -ENODEV;
> >> 
> >> +  ret = video_device_enter(vdev);
> >> +  if (ret < 0)
> >> +  return ret;
> >> +
> >>if (vdev->fops->unlocked_ioctl) {
> >>struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
> >> 
> >> @@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned
> >> int cmd, unsigned long arg)
> >>return -ERESTARTSYS;
> >>if (video_is_registered(vdev))
> >>ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
> >> +  else
> >> +  ret = -ENODEV;
> >>if (lock)
> >>mutex_unlock(lock);
> >>} else
> >>ret = -ENOTTY;
> >> 
> >> +  video_device_exit(vdev);
> >>return ret;
> >>  }
> >> 
> >> @@ -841,6 +894,10 @@ int __video_register_device(struct video_device
> >> *vdev, int type, int nr,
> >>if (WARN_ON(!vdev->v4l2_dev))
> >>return -EINVAL;
> >> 
> >> +  /* unplug support */
> >> +  spin_lock_init(>unplug_lock);
> >> +  init_waitqueue_head(>unplug_wait);
> >> +
> > 
> > I'm c/c Greg here, as I don't think, that, the way it is, it
> > belongs at V4L2 core.
> > 
> > I mean: if this is a problem that affects all drivers, it would should,
> > instead, be sitting at the driver's core.
> 
> What "problem" is trying to be solved here?  One where your specific
> device type races with your specific user 

Re: arm64: unhandled level 0 translation fault

[Geert Uytterhoeven]

Hi Will,

On Tue, Dec 12, 2017 at 11:36 AM, Will Deacon  wrote:
> On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
>> During userspace (Debian jessie NFS root) boot on arm64:
>>
>> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
>> esr 0x9204, in dash[adf77000+1a000]
>> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
>> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
>> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ 
>> (DT)
>> pstate: 8000 (Nzcv daif -PAN -UAO)
>> pc : 0xadf8a51c
>> lr : 0xadf8ac08
>> sp : cffeac00
>> x29: cffeac00 x28: adfa1000
>> x27: cffebf7c x26: cffead20
>> x25: cea1c5f0 x24: 
>> x23: adfa1000 x22: adfa1000
>> x21:  x20: 0008
>> x19:  x18: cffeb500
>> x17: a22babfc x16: adfa1ae8
>> x15: a2363588 x14: 
>> x13: 0020 x12: 0010
>> x11: 0101010101010101 x10: adfa1000
>> x9 : ff81 x8 : adfa2000
>> x7 :  x6 : 
>> x5 : adfa2338 x4 : adfa2000
>> x3 : adfa2338 x2 : 
>> x1 : adfa28b0 x0 : adfa4c30
>>
>> Sometimes it happens with other processes, but the main address, esr, and
>> pstate values are always the same.
>>
>> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
>> releases, so the last time was two weeks ago), but never saw the issue
>> before until today, so probably v4.15-rc1 is OK.
>> Unfortunately it doesn't happen during every boot, which makes it
>> cumbersome to bisect.
>>
>> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
>> and even without today's arm64/for-next/core merged in, I still managed to
>> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
>> v4.15-rc3.
>
> Urgh, this looks nasty. Thanks for the report! A few questions:
>
>  - Can you share your .config somewhere please?

I managed to reproduce it on plain v4.15-rc3 using both arm64_defconfig, and
renesas_defconfig (from Simon's repo).

>  - What was your last known-good kernel?

v4.15-rc1.

>  - Have you seen it on any other Soc?

I haven't seen it on any Renesas arm32 SoC, only on arm64.

>  - What's the CPU in your SoC?

Quad Cortex A57.

> If I can reproduce the failure here, then I should be able to debug ASAP.

Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Laurent Pinchart]

Hi Mauro,

On Thursday, 23 November 2017 15:07:51 EET Mauro Carvalho Chehab wrote:
> Em Thu, 16 Nov 2017 02:33:48 +0200 Laurent Pinchart escreveu:
> > Device unplug being asynchronous, it naturally races with operations
> > performed by userspace through ioctls or other file operations on video
> > device nodes.
> > 
> > This leads to potential access to freed memory or to other resources
> > during device access if unplug occurs during device access. To solve
> > this, we need to wait until all device access completes when unplugging
> > the device, and block all further access when the device is being
> > unplugged.
> > 
> > Three new functions are introduced. The video_device_enter() and
> > video_device_exit() functions must be used to mark entry and exit from
> > all code sections where the device can be accessed. The
> > video_device_unplug() function is then used in the unplug handler to
> > mark the device as being unplugged and wait for all access to complete.
> > 
> > As an example mark the ioctl handler as a device access section. Other
> > file operations need to be protected too, and blocking ioctls (such as
> > VIDIOC_DQBUF) need to be handled as well.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/media/v4l2-core/v4l2-dev.c | 57 +
> >  include/media/v4l2-dev.h   | 47 +++
> >  2 files changed, 104 insertions(+)

[snip]

> I'm c/c Greg here, as I don't think, that, the way it is, it
> belongs at V4L2 core.
> 
> I mean: if this is a problem that affects all drivers, it would should,
> instead, be sitting at the driver's core.
> 
> If, otherwise, this is specific to rcar-vin (and other platform drivers),
> that's likely should be inside the drivers that require it.
> 
> That's said, I remember we had to add some things in the past for
> USB drivers hot unplug to happen softly. I don't remember the specifics
> anymore, but it was solved by both a V4L2 core and changes at USB
> drivers.
> 
> One of the things that it was added, on that time, was this patch:
> 
>   commit ae6cfaace120f4330715b56265ce0e4a710e1276
>   Author: Hans Verkuil 
>   Date:   Sat Mar 14 08:28:45 2009 -0300
> 
>   V4L/DVB (11044): v4l2-device: add v4l2_device_disconnect
> 
> So, I would expect that a change at V4L2 core (or at driver core) that
> would be applied would also be affecting USB drivers disconnect logic
> and v4l2_device_disconnect() function.

I wasn't aware of v4l2_device_disconnect(), thank you for pointing it out.

I don't know what the full history behind that function is, but I don't see 
why it's needed. struct device instances are refcounted, the struct device 
corresponding to a USB device or USB interface doesn't get freed when a device 
is disconnected as long as a reference is present. We take such a reference in 
v4l2_device_register(), so there should be no problem.

[snip]

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Laurent Pinchart]

Hi Hans,

On Friday, 17 November 2017 13:09:20 EET Hans Verkuil wrote:
> On 16/11/17 01:33, Laurent Pinchart wrote:
> > Device unplug being asynchronous, it naturally races with operations
> > performed by userspace through ioctls or other file operations on video
> > device nodes.
> > 
> > This leads to potential access to freed memory or to other resources
> > during device access if unplug occurs during device access. To solve
> > this, we need to wait until all device access completes when unplugging
> > the device, and block all further access when the device is being
> > unplugged.
> > 
> > Three new functions are introduced. The video_device_enter() and
> > video_device_exit() functions must be used to mark entry and exit from
> > all code sections where the device can be accessed. The
> > video_device_unplug() function is then used in the unplug handler to
> > mark the device as being unplugged and wait for all access to complete.
> > 
> > As an example mark the ioctl handler as a device access section. Other
> > file operations need to be protected too, and blocking ioctls (such as
> > VIDIOC_DQBUF) need to be handled as well.
> 
> As long as the queue field in struct video_device is filled in properly
> this shouldn't be a problem.
> 
> This looks pretty good, simple and straightforward.

Thank you.

> Do we need something similar for media_device? Other devices?

I believe so, which is why I'm wondering whether this shouldn't somehow go to 
the device core (and in the cdev core). Not all devices will need such an 
infrastructure as some subsystems already protect against device access after 
unbind (USB is one of them if I'm not mistaken), but it certainly shouldn't 
hurt.

DRM is also considering a similar implementation, but based on srcu to lower 
the performance penalty. I feel that's going a bit overboard but I have no 
numbers yet to confirm or infirm the suspicion.

> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/media/v4l2-core/v4l2-dev.c | 57 +
> >  include/media/v4l2-dev.h   | 47 +++
> >  2 files changed, 104 insertions(+)

[snip]

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Laurent Pinchart]

Hi Kieran,

On Thursday, 16 November 2017 16:47:11 EET Kieran Bingham wrote:
> On 16/11/17 12:32, Sakari Ailus wrote:
> > Hi Laurent,
> > 
> > Thank you for the initiative to bring up and address the matter!
> 
> I concur - this looks like a good start towards managing the issue.
> 
> One potential thing spotted on top of Sakari's review inline below, of
> course I suspect this was more of a prototype/consideration patch.
> 
> > On Thu, Nov 16, 2017 at 02:33:48AM +0200, Laurent Pinchart wrote:
> >> Device unplug being asynchronous, it naturally races with operations
> >> performed by userspace through ioctls or other file operations on video
> >> device nodes.
> >> 
> >> This leads to potential access to freed memory or to other resources
> >> during device access if unplug occurs during device access. To solve
> >> this, we need to wait until all device access completes when unplugging
> >> the device, and block all further access when the device is being
> >> unplugged.
> >> 
> >> Three new functions are introduced. The video_device_enter() and
> >> video_device_exit() functions must be used to mark entry and exit from
> >> all code sections where the device can be accessed. The
> > 
> > I wonder if it'd help splitting this patch into two: one that introduces
> > the mechanism and the other that uses it. Up to you.
> > 
> > Nevertheless, it'd be better to have other system calls covered as well.
> > 
> >> video_device_unplug() function is then used in the unplug handler to
> >> mark the device as being unplugged and wait for all access to complete.
> >> 
> >> As an example mark the ioctl handler as a device access section. Other
> >> file operations need to be protected too, and blocking ioctls (such as
> >> VIDIOC_DQBUF) need to be handled as well.
> >> 
> >> Signed-off-by: Laurent Pinchart
> >> 
> >> ---
> >> 
> >>  drivers/media/v4l2-core/v4l2-dev.c | 57 
> >>  include/media/v4l2-dev.h   | 47 +++
> >>  2 files changed, 104 insertions(+)
> >> 
> >> diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> >> b/drivers/media/v4l2-core/v4l2-dev.c index c647ba648805..c73c6d49e7cf
> >> 100644
> >> --- a/drivers/media/v4l2-core/v4l2-dev.c
> >> +++ b/drivers/media/v4l2-core/v4l2-dev.c

[snip]

> >> @@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned
> >> int cmd, unsigned long arg)
> >>struct video_device *vdev = video_devdata(filp);
> >>int ret = -ENODEV;
> > 
> > You could leave ret unassigned here.
> > 
> >> +  ret = video_device_enter(vdev);
> >> +  if (ret < 0)
> >> +  return ret;
> >> +
> >>if (vdev->fops->unlocked_ioctl) {
> >>struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
> >> 
> >> @@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned
> >> int cmd, unsigned long arg)
> >>return -ERESTARTSYS;
> 
> It looks like that return -ERESTARTSYS might need a video_device_exit() too?

Oops. Of course. I'll fix that. Thanks for catching the issue.

> >>if (video_is_registered(vdev))
> >>ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
> >> +  else
> >> +  ret = -ENODEV;
> >>if (lock)
> >>mutex_unlock(lock);
> >>} else
> >>ret = -ENOTTY;
> >> 
> >> +  video_device_exit(vdev);
> >>return ret;
> >>  }

-- 
Regards,

Laurent Pinchart

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Laurent Pinchart]

Hi Sakari,

On Thursday, 16 November 2017 14:32:37 EET Sakari Ailus wrote:
> On Thu, Nov 16, 2017 at 02:33:48AM +0200, Laurent Pinchart wrote:
> > Device unplug being asynchronous, it naturally races with operations
> > performed by userspace through ioctls or other file operations on video
> > device nodes.
> > 
> > This leads to potential access to freed memory or to other resources
> > during device access if unplug occurs during device access. To solve
> > this, we need to wait until all device access completes when unplugging
> > the device, and block all further access when the device is being
> > unplugged.
> > 
> > Three new functions are introduced. The video_device_enter() and
> > video_device_exit() functions must be used to mark entry and exit from
> > all code sections where the device can be accessed. The
> 
> I wonder if it'd help splitting this patch into two: one that introduces
> the mechanism and the other that uses it. Up to you.

Sure, I'm not opposed to that. The second patch would be a bit small, but that 
will change when I'll add support for more system calls.

> Nevertheless, it'd be better to have other system calls covered as well.
> 
> > video_device_unplug() function is then used in the unplug handler to
> > mark the device as being unplugged and wait for all access to complete.
> > 
> > As an example mark the ioctl handler as a device access section. Other
> > file operations need to be protected too, and blocking ioctls (such as
> > VIDIOC_DQBUF) need to be handled as well.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/media/v4l2-core/v4l2-dev.c | 57 +
> >  include/media/v4l2-dev.h   | 47 +++
> >  2 files changed, 104 insertions(+)
> > 
> > diff --git a/drivers/media/v4l2-core/v4l2-dev.c
> > b/drivers/media/v4l2-core/v4l2-dev.c index c647ba648805..c73c6d49e7cf
> > 100644
> > --- a/drivers/media/v4l2-core/v4l2-dev.c
> > +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > @@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device
> > *vdev)> 
> >  }
> >  EXPORT_SYMBOL(video_device_release_empty);
> > 
> > +int video_device_enter(struct video_device *vdev)
> > +{
> > +   bool unplugged;
> > +
> > +   spin_lock(>unplug_lock);
> > +   unplugged = vdev->unplugged;
> > +   if (!unplugged)
> > +   vdev->access_refcount++;
> > +   spin_unlock(>unplug_lock);
> > +
> > +   return unplugged ? -ENODEV : 0;
> > +}
> > +EXPORT_SYMBOL_GPL(video_device_enter);
> > +
> > +void video_device_exit(struct video_device *vdev)
> > +{
> > +   bool wake_up;
> > +
> > +   spin_lock(>unplug_lock);
> > +   WARN_ON(--vdev->access_refcount < 0);
> > +   wake_up = vdev->access_refcount == 0;
> > +   spin_unlock(>unplug_lock);
> > +
> > +   if (wake_up)
> > +   wake_up(>unplug_wait);
> > +}
> > +EXPORT_SYMBOL_GPL(video_device_exit);
> 
> Is there a need to export the two, i.e. wouldn't you only call them from
> the framework, or the same module?

There could be a need to call these functions from entry points that are not 
controlled by the V4L2 core, such as sysfs or debugfs. We could keep the 
functions internal for now and only export them when the need arises, but if 
we want to document how drivers need to handle race conditions between device 
access and device unbind, we need to have them exported.

> > +
> > +void video_device_unplug(struct video_device *vdev)
> > +{
> > +   bool unplug_blocked;
> > +
> > +   spin_lock(>unplug_lock);
> > +   unplug_blocked = vdev->access_refcount > 0;
> > +   vdev->unplugged = true;
> 
> Shouldn't this be set to false in video_register_device()?

Yes it should. I currently rely on the fact that the memory is zeroed when 
allocated, but I shouldn't. I'll fix that.

> > +   spin_unlock(>unplug_lock);
> > +
> > +   if (!unplug_blocked)
> > +   return;
> 
> Not necessary, wait_event_timeout() handles this already.

I'll fix this as well.

> > +
> > +   if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
> > +   msecs_to_jiffies(15)))
> > +   WARN(1, "Timeout waiting for device access to complete\n");
> 
> Why a timeout? Does this get somehow less problematic over time? :-)

Not quite :-) This should never happen, but driver and/or core bugs could 
cause a timeout. In that case I think proceeding after a timeout is a better 
option than deadlocking forever.

> > +}
> > +EXPORT_SYMBOL_GPL(video_device_unplug);
> > +
> > 
> >  static inline void video_get(struct video_device *vdev)
> >  {
> >  
> > get_device(>dev);
> > 
> > @@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned
> > int cmd, unsigned long arg)> 
> > struct video_device *vdev = video_devdata(filp);
> > int ret = -ENODEV;
> 
> You could leave ret unassigned here.

I'll fix that.

> > +   ret = video_device_enter(vdev);
> > +   if (ret < 0)
> > +   return 

Re: [PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag

[Ulf Hansson]

On 12 December 2017 at 09:16, Geert Uytterhoeven  wrote:
> Hi Ulf,
>
> On Mon, Dec 11, 2017 at 9:59 PM, Ulf Hansson  wrote:
>> That together with an option of allowing "consumed resource-devices"
>> (irqchip) to be included in the wakeup path. I am thinking, perhaps
>> another driver PM flag (DPM_FLAG_WAKEUP_PATH), that the PM core looks
>> at and sets ->power.wakeup_path flag for the device and its parents.
>
> This is complicated by the fact that currently the device and irq
> subsystems don't really share data. E.g. {en,dis}able_irq_wake() and
> irq_set_irq_wake() don't take a device parameter, only an interrupt number,
> and conversion from interrupt numbers to devices is non-trivial.
> That's why I handled it in the irqchip drivers in the series referenced
> below.

Yes, that seems like a good way forward for now.

We can always look into how to extend the irq subsystem to deal with
this internally, but I rather leave that to be done as a separate
task.

[...]

Kind regards
Uffe

renesas-drivers-2017-12-12-v4.15-rc3

[Geert Uytterhoeven]

I have pushed renesas-drivers-2017-12-12-v4.15-rc3 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git

This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.

Today's version is based on renesas-devel-20171211-v4.15-rc3.

Included branches with driver code:
  - clk-renesas
  - sh-pfc
  - topic/rcar-genpd-wakeup-v3-rebased1
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/rcar-gen3-z-clk-v3
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/cpufreq-automatic
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/rcar-gen3-cpufreq-dts-v2
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/ipmmu-driver-v5
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/ipmmu-bindings
  - git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
  - git://git.ragnatech.se/linux#for-renesas-drivers

Included fixes:
  - clk: renesas: rcar-gen3: Fix Z and Z2 clock frequency
  - clk: renesas: rcar-gen3: Fix Z2 clock frequency calculation
  - [LOCAL] arm64: defconfig: Update renesas_defconfig

Included subsystem trees:
  - git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
  - git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
  - git://people.freedesktop.org/~airlied/linux#drm-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
  - git://linuxtv.org/mchehab/media-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
  - git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
  - git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
  - git://git.infradead.org/users/vkoul/slave-dma.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
  - git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
  - git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
  - git://github.com/bzolnier/linux.git#fbdev-for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
  - git://www.linux-watchdog.org/linux-watchdog-next.git#master
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
  - git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
  - 
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
  - git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
  - git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

[Mauro Carvalho Chehab]

Em Thu, 23 Nov 2017 15:21:01 +0100
Greg Kroah-Hartman  escreveu:

> On Thu, Nov 23, 2017 at 11:07:51AM -0200, Mauro Carvalho Chehab wrote:
> > Hi Laurent,
> > 
> > Em Thu, 16 Nov 2017 02:33:48 +0200
> > Laurent Pinchart  escreveu:
> >   
> > > Device unplug being asynchronous, it naturally races with operations
> > > performed by userspace through ioctls or other file operations on video
> > > device nodes.
> > > 
> > > This leads to potential access to freed memory or to other resources
> > > during device access if unplug occurs during device access. To solve
> > > this, we need to wait until all device access completes when unplugging
> > > the device, and block all further access when the device is being
> > > unplugged.
> > > 
> > > Three new functions are introduced. The video_device_enter() and
> > > video_device_exit() functions must be used to mark entry and exit from
> > > all code sections where the device can be accessed. The
> > > video_device_unplug() function is then used in the unplug handler to
> > > mark the device as being unplugged and wait for all access to complete.
> > > 
> > > As an example mark the ioctl handler as a device access section. Other
> > > file operations need to be protected too, and blocking ioctls (such as
> > > VIDIOC_DQBUF) need to be handled as well.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > 
> > > ---
> > >  drivers/media/v4l2-core/v4l2-dev.c | 57 
> > > ++
> > >  include/media/v4l2-dev.h   | 47 +++
> > >  2 files changed, 104 insertions(+)
> > > 
> > > diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
> > > b/drivers/media/v4l2-core/v4l2-dev.c
> > > index c647ba648805..c73c6d49e7cf 100644
> > > --- a/drivers/media/v4l2-core/v4l2-dev.c
> > > +++ b/drivers/media/v4l2-core/v4l2-dev.c
> > > @@ -156,6 +156,52 @@ void video_device_release_empty(struct video_device 
> > > *vdev)
> > >  }
> > >  EXPORT_SYMBOL(video_device_release_empty);
> > >  
> > > +int video_device_enter(struct video_device *vdev)
> > > +{
> > > + bool unplugged;
> > > +
> > > + spin_lock(>unplug_lock);
> > > + unplugged = vdev->unplugged;
> > > + if (!unplugged)
> > > + vdev->access_refcount++;
> > > + spin_unlock(>unplug_lock);
> > > +
> > > + return unplugged ? -ENODEV : 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(video_device_enter);
> > > +
> > > +void video_device_exit(struct video_device *vdev)
> > > +{
> > > + bool wake_up;
> > > +
> > > + spin_lock(>unplug_lock);
> > > + WARN_ON(--vdev->access_refcount < 0);
> > > + wake_up = vdev->access_refcount == 0;
> > > + spin_unlock(>unplug_lock);
> > > +
> > > + if (wake_up)
> > > + wake_up(>unplug_wait);
> > > +}
> > > +EXPORT_SYMBOL_GPL(video_device_exit);
> > > +
> > > +void video_device_unplug(struct video_device *vdev)
> > > +{
> > > + bool unplug_blocked;
> > > +
> > > + spin_lock(>unplug_lock);
> > > + unplug_blocked = vdev->access_refcount > 0;
> > > + vdev->unplugged = true;
> > > + spin_unlock(>unplug_lock);
> > > +
> > > + if (!unplug_blocked)
> > > + return;
> > > +
> > > + if (!wait_event_timeout(vdev->unplug_wait, !vdev->access_refcount,
> > > + msecs_to_jiffies(15)))
> > > + WARN(1, "Timeout waiting for device access to complete\n");
> > > +}
> > > +EXPORT_SYMBOL_GPL(video_device_unplug);
> > > +
> > >  static inline void video_get(struct video_device *vdev)
> > >  {
> > >   get_device(>dev);
> > > @@ -351,6 +397,10 @@ static long v4l2_ioctl(struct file *filp, unsigned 
> > > int cmd, unsigned long arg)
> > >   struct video_device *vdev = video_devdata(filp);
> > >   int ret = -ENODEV;
> > >  
> > > + ret = video_device_enter(vdev);
> > > + if (ret < 0)
> > > + return ret;
> > > +
> > >   if (vdev->fops->unlocked_ioctl) {
> > >   struct mutex *lock = v4l2_ioctl_get_lock(vdev, cmd);
> > >  
> > > @@ -358,11 +408,14 @@ static long v4l2_ioctl(struct file *filp, unsigned 
> > > int cmd, unsigned long arg)
> > >   return -ERESTARTSYS;
> > >   if (video_is_registered(vdev))
> > >   ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
> > > + else
> > > + ret = -ENODEV;
> > >   if (lock)
> > >   mutex_unlock(lock);
> > >   } else
> > >   ret = -ENOTTY;
> > >  
> > > + video_device_exit(vdev);
> > >   return ret;
> > >  }
> > >  
> > > @@ -841,6 +894,10 @@ int __video_register_device(struct video_device 
> > > *vdev, int type, int nr,
> > >   if (WARN_ON(!vdev->v4l2_dev))
> > >   return -EINVAL;
> > >  
> > > + /* unplug support */
> > > + spin_lock_init(>unplug_lock);
> > > + init_waitqueue_head(>unplug_wait);
> > > +  
> > 
> > I'm c/c Greg here, as I don't think, that, the way it is, it
> > belongs at V4L2 core.
> > 
> > I mean: if this is a problem that affects all drivers, it 

Re: [PATCH v4 0/9] vsp1: TLB optimisation and DL caching

[Geert Uytterhoeven]

Hi Kieran,

On Fri, Nov 17, 2017 at 4:47 PM, Kieran Bingham
 wrote:
> Each display list currently allocates an area of DMA memory to store register
> settings for the VSP1 to process. Each of these allocations adds pressure to
> the IPMMU TLB entries.
>
> We can reduce the pressure by pre-allocating larger areas and dividing the 
> area
> across multiple bodies represented as a pool.
>
> With this reconfiguration of bodies, we can adapt the configuration code to
> separate out constant hardware configuration and cache it for re-use.
>
> --
>
> The patches provided in this series can be found at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git  
> tags/vsp1/tlb-optimise/v4

This started to conflict with commit dd286a531461748f ("v4l: vsp1:
Start and stop DRM pipeline independently of planes"), causing build
failures as it changes the signature of vsp1_entity_route_setup(), and
removed several VSP1_ENTITY_PARAMS_* definitions.

After fixing those, it hangs after:
 [drm] No driver support for vblank timestamp query.

So I dropped the above for today's release.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: arm64: unhandled level 0 translation fault

[Will Deacon]

Hi Geert,

On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven wrote:
> During userspace (Debian jessie NFS root) boot on arm64:
> 
> rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
> esr 0x9204, in dash[adf77000+1a000]
> CPU: 0 PID: 1083 Comm: rpcbind Not tainted
> 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
> Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ 
> (DT)
> pstate: 8000 (Nzcv daif -PAN -UAO)
> pc : 0xadf8a51c
> lr : 0xadf8ac08
> sp : cffeac00
> x29: cffeac00 x28: adfa1000
> x27: cffebf7c x26: cffead20
> x25: cea1c5f0 x24: 
> x23: adfa1000 x22: adfa1000
> x21:  x20: 0008
> x19:  x18: cffeb500
> x17: a22babfc x16: adfa1ae8
> x15: a2363588 x14: 
> x13: 0020 x12: 0010
> x11: 0101010101010101 x10: adfa1000
> x9 : ff81 x8 : adfa2000
> x7 :  x6 : 
> x5 : adfa2338 x4 : adfa2000
> x3 : adfa2338 x2 : 
> x1 : adfa28b0 x0 : adfa4c30
> 
> Sometimes it happens with other processes, but the main address, esr, and
> pstate values are always the same.
> 
> I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
> releases, so the last time was two weeks ago), but never saw the issue
> before until today, so probably v4.15-rc1 is OK.
> Unfortunately it doesn't happen during every boot, which makes it
> cumbersome to bisect.
> 
> My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
> and even without today's arm64/for-next/core merged in, I still managed to
> reproduce the issue, so I believe it was introduced in v4.15-rc2 or
> v4.15-rc3.

Urgh, this looks nasty. Thanks for the report! A few questions:

 - Can you share your .config somewhere please?
 - What was your last known-good kernel?
 - Have you seen it on any other Soc?
 - What's the CPU in your SoC?

If I can reproduce the failure here, then I should be able to debug ASAP.

Cheers,

Will

arm64: unhandled level 0 translation fault

[Geert Uytterhoeven]

Hi Catalin, Will, et al,

During userspace (Debian jessie NFS root) boot on arm64:

rpcbind[1083]: unhandled level 0 translation fault (11) at 0x0008,
esr 0x9204, in dash[adf77000+1a000]
CPU: 0 PID: 1083 Comm: rpcbind Not tainted
4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
pstate: 8000 (Nzcv daif -PAN -UAO)
pc : 0xadf8a51c
lr : 0xadf8ac08
sp : cffeac00
x29: cffeac00 x28: adfa1000
x27: cffebf7c x26: cffead20
x25: cea1c5f0 x24: 
x23: adfa1000 x22: adfa1000
x21:  x20: 0008
x19:  x18: cffeb500
x17: a22babfc x16: adfa1ae8
x15: a2363588 x14: 
x13: 0020 x12: 0010
x11: 0101010101010101 x10: adfa1000
x9 : ff81 x8 : adfa2000
x7 :  x6 : 
x5 : adfa2338 x4 : adfa2000
x3 : adfa2338 x2 : 
x1 : adfa28b0 x0 : adfa4c30

Sometimes it happens with other processes, but the main address, esr, and
pstate values are always the same.

I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
releases, so the last time was two weeks ago), but never saw the issue
before until today, so probably v4.15-rc1 is OK.
Unfortunately it doesn't happen during every boot, which makes it
cumbersome to bisect.

My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
and even without today's arm64/for-next/core merged in, I still managed to
reproduce the issue, so I believe it was introduced in v4.15-rc2 or
v4.15-rc3.

Once, when the kernel message above wasn't shown, I got an error from
userspace, which may be related:
*** Error in `/bin/sh': free(): invalid pointer: 0xdd970988 ***

Do you have a clue?
Thanks!

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v1 05/10] arch: sh: migor: Use new renesas-ceu camera driver

[Laurent Pinchart]

Hi Jacopo,

Thank you for the patch.

On Wednesday, 15 November 2017 12:55:58 EET Jacopo Mondi wrote:
> Migo-R platform uses sh_mobile_ceu camera driver, which is now being
> replaced by a proper V4L2 camera driver named 'renesas-ceu'.
> 
> Move Migo-R platform to use the v4l2 renesas-ceu camera driver
> interface and get rid of soc_camera defined components used to register
> sensor drivers.
> 
> Also, memory for CEU video buffers is now reserved with membocks APIs,
> and need to be declared as dma_coherent during machine initialization to
> remove that architecture specific part from CEU driver.
> 
> Signed-off-by: Jacopo Mondi 
> ---
>  arch/sh/boards/mach-migor/setup.c | 164 --
>  1 file changed, 76 insertions(+), 88 deletions(-)
> 
> diff --git a/arch/sh/boards/mach-migor/setup.c
> b/arch/sh/boards/mach-migor/setup.c index 98aa094..10a9b3c 100644
> --- a/arch/sh/boards/mach-migor/setup.c
> +++ b/arch/sh/boards/mach-migor/setup.c
> @@ -27,7 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -308,62 +308,80 @@ static struct platform_device migor_lcdc_device = {
>  static struct clk *camera_clk;
>  static DEFINE_MUTEX(camera_lock);
> 
> -static void camera_power_on(int is_tw)
> +static void camera_vio_clk_on(void)
>  {
> - mutex_lock(_lock);
> -
>   /* Use 10 MHz VIO_CKO instead of 24 MHz to work
>* around signal quality issues on Panel Board V2.1.
>*/
>   camera_clk = clk_get(NULL, "video_clk");
>   clk_set_rate(camera_clk, 1000);
>   clk_enable(camera_clk); /* start VIO_CKO */
> -
> - /* use VIO_RST to take camera out of reset */
> - mdelay(10);
> - if (is_tw) {
> - gpio_set_value(GPIO_PTT2, 0);
> - gpio_set_value(GPIO_PTT0, 0);
> - } else {
> - gpio_set_value(GPIO_PTT0, 1);
> - }
> - gpio_set_value(GPIO_PTT3, 0);
> - mdelay(10);
> - gpio_set_value(GPIO_PTT3, 1);
> - mdelay(10); /* wait to let chip come out of reset */
>  }
> 
> -static void camera_power_off(void)
> +static void camera_disable(void)
>  {
> - clk_disable(camera_clk); /* stop VIO_CKO */
> + /* stop VIO_CKO */
> + clk_disable(camera_clk);
>   clk_put(camera_clk);
> 
> + gpio_set_value(GPIO_PTT0, 0);
> + gpio_set_value(GPIO_PTT2, 1);
>   gpio_set_value(GPIO_PTT3, 0);
> +
>   mutex_unlock(_lock);
>  }
> 
> -static int ov7725_power(struct device *dev, int mode)
> +static void camera_reset(void)
>  {
> - if (mode)
> - camera_power_on(0);
> - else
> - camera_power_off();
> + /* use VIO_RST to take camera out of reset */
> + gpio_set_value(GPIO_PTT3, 0);
> + mdelay(10);
> + gpio_set_value(GPIO_PTT3, 1);
> + mdelay(10);
> +}
> +
> +static int ov7725_enable(void)
> +{
> + mutex_lock(_lock);
> + camera_vio_clk_on();
> + mdelay(10);
> + gpio_set_value(GPIO_PTT0, 1);
> +
> + camera_reset();
> 
>   return 0;
>  }
> 
> -static int tw9910_power(struct device *dev, int mode)
> +static int tw9910_enable(void)
>  {
> - if (mode)
> - camera_power_on(1);
> - else
> - camera_power_off();
> + mutex_lock(_lock);
> + camera_vio_clk_on();
> + mdelay(10);
> + gpio_set_value(GPIO_PTT2, 0);
> +
> + camera_reset();
> 
>   return 0;
>  }

After studying the schematics, and if you can confirm that R26 is not mounted 
on the panel board, I think all this could be handled by the OV7720 and TW9910 
drivers.

The clock is easy, it's used by the OV7720 only, just expose it as the input 
clock for that device. On a side note, your ov772x driver in this series tries 
to get a clock named "mclk", but it should be named "xclk" as that's how the 
chip's input signal is named. The TW9910 has its own crystal oscillator so it 
won't be affected. As a bonus point the clock will remain off when capturing 
from the TW9910.

The TV_IN_EN and CAM_EN signals (PTT2 and PTT0 GPIOs respectively) shouldn't 
be difficult either. You can expose them as the PDN and PWDN GPIOs for the 
OV7720 and TW9910 and handle them in the respective drivers. CAM_EN also 
controls the digital video bus multiplexing, and unless I'm mistaken it will 
just work as a side effect of power down signal control as long as you make 
sure that the OV7720 remains in power down when not selected as the CEU input.

The VIO_RST signal (PTT3 GPIO) is a bit more annoying, as it is shared by both 
the OV7720 and TW9910 as their reset signal, and as far as I know GPIOs can't 
be easily shared between drivers.

Using a reset controller might be an option but I can't see any reset 
controller driver for GPIOs. https://patchwork.kernel.org/patch/3978091/ seems 
not to have been merged. This being said, having to instantiate a reset 
controller to share a GPIO is annoying, I wonder if it would make sense to add 
support for shared 

Re: [PATCH 3/3] arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes

[Geert Uytterhoeven]

On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
 wrote:
> Add reg properties to pciec[01] placeholder nodes
>
> This is to stop the compiler complaining as follows:
> $ make
> ...
>   DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning 
> (unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
> property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning 
> (unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
> property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
> Node /soc/pcie@fe00 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
> Node /soc/pcie@ee80 missing or empty reg/ranges property
>   DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning 
> (unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
> property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning 
> (unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
> property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): 
> Node /soc/pcie@fe00 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): 
> Node /soc/pcie@ee80 missing or empty reg/ranges property
>   DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning 
> (unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
> property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning 
> (unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
> property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
> Node /soc/pcie@fe00 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
> Node /soc/pcie@ee80 missing or empty reg/ranges property
>   DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
> (unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
> property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
> (unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
> property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
> (simple_bus_reg): Node /soc/pcie@fe00 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
> (simple_bus_reg): Node /soc/pcie@ee80 missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically

[Geert Uytterhoeven]

On Tue, Dec 12, 2017 at 9:27 AM, Simon Horman
 wrote:
> Sort root sub-nodes alphabetically for allow for easier maintenance
> of this file.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus

[Geert Uytterhoeven]

Hi Simon,

On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
 wrote:
> Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
> The nodes that have been moved do not have any register properties and thus
> shouldn't be placed on the bus.

[...]

> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 
but a few minor comments below...

> --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
> @@ -154,6 +154,26 @@
> clock-frequency = <0>;
> };
>
> +   pmu_a57 {
> +   compatible = "arm,cortex-a57-pmu";
> +   interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
> + < GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
> +   interrupt-affinity = <_0>,
> +<_1>;
> +   };
> +
> +   pmu_a53 {
> +   compatible = "arm,cortex-a53-pmu";
> +   interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
> + < GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
> + < GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
> + < GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
> +   interrupt-affinity = <_0>,
> +<_1>,
> +<_2>,
> +<_3>;

Merge these 4 into a single line?

> @@ -2027,4 +1971,64 @@
> resets = < 822>;
> };
> };
> +
> +   timer {
> +   compatible = "arm,armv8-timer";
> +   interrupts-extended = < GIC_PPI 13
> +  (GIC_CPU_MASK_SIMPLE(6) |
> +   IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 14
> +  (GIC_CPU_MASK_SIMPLE(6) |
> +   IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 11
> +  (GIC_CPU_MASK_SIMPLE(6) |
> +   IRQ_TYPE_LEVEL_LOW)>,
> + < GIC_PPI 10
> +  (GIC_CPU_MASK_SIMPLE(6) |
> +   IRQ_TYPE_LEVEL_LOW)>;

I think you can do a better job here, by trying not to break entries across
multiple lines ;-)

(Oops, we already have it this way in r8a7795.dtsi)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically

[Geert Uytterhoeven]

On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
 wrote:
> Sort root sub-nodes alphabetically for allow for easier maintenance
> of this file.
>
> Signed-off-by: Simon Horman 

Reviewed-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically

[Simon Horman]

Sort root sub-nodes alphabetically for allow for easier maintenance
of this file.

Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7795.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

 Based on renesas-devel-20171211-v4.15-rc3

diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index a851c88e1e04..62dfc7781cc1 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -30,11 +30,6 @@
i2c7 = _dvfs;
};
 
-   psci {
-   compatible = "arm,psci-1.0", "arm,psci-0.2";
-   method = "smc";
-   };
-
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -208,6 +203,11 @@
 <_3>;
};
 
+   psci {
+   compatible = "arm,psci-1.0", "arm,psci-0.2";
+   method = "smc";
+   };
+
soc: soc {
compatible = "simple-bus";
interrupt-parent = <>;
-- 
2.11.0

[PATCH 0/3] arm64: dts: renesas: r8a7796: cleanup of make dtb W=1

[Simon Horman]

Hi,

this short series makes make dtb W=1 builds clean.

Patch 1 sorts subnodes of the root node into alphabetical order
to... well bring some order to things.

Patch 2 moves nodes without reg properties out of the SoC bus,
this is in keeping with recent work for the r8a7795 SoC.

Patch 3 adds reg property to the place holder peciec[01] nodes

Et voilà, make dtb W=1 no longer emits warnings.

$ aarch64-linux-gnu-gcc --version
aarch64-linux-gnu-gcc (Linaro GCC 5.4-2017.05) 5.4.1 20170404
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Based on renesas-devel-20171211-v4.15-rc3

Simon Horman (3):
  arm64: dts: renesas: r8a7796: sort subnodes of root node
alphabetically
  arm64: dts: renesas: r8a7796: move nodes which have no reg property
out of bus
  arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes

 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 216 ---
 1 file changed, 111 insertions(+), 105 deletions(-)

-- 
2.11.0

[PATCH 2/3] arm64: dts: renesas: r8a7796: move nodes which have no reg property out of bus

[Simon Horman]

Move pmu_a5[73], timer and thermal-zones nodes from soc node to root node.
The nodes that have been moved do not have any register properties and thus
shouldn't be placed on the bus.

This problem is flagged by the compiler as follows:
$ make
...
  DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/thermal-zones missing or empty reg/ranges property
...
  DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/thermal-zones missing or empty reg/ranges property
...
  DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/thermal-zones missing or empty reg/ranges property
...
  DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
...
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): 
Node /soc/timer missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a57 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): 
Node /soc/pmu_a53 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): 
Node /soc/thermal-zones missing or empty reg/ranges property
...

Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 156 ---
 1 file changed, 80 insertions(+), 76 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index c1b0d0344329..bf971979aba8 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -154,6 +154,26 @@
clock-frequency = <0>;
};
 
+   pmu_a57 {
+   compatible = "arm,cortex-a57-pmu";
+   interrupts-extended = < GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-affinity = <_0>,
+<_1>;
+   };
+
+   pmu_a53 {
+   compatible = "arm,cortex-a53-pmu";
+   interrupts-extended = < GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>,
+ < GIC_SPI 87 IRQ_TYPE_LEVEL_HIGH>;
+   interrupt-affinity = <_0>,
+<_1>,
+<_2>,
+<_3>;
+   };
+
psci {
compatible = "arm,psci-1.0", "arm,psci-0.2";
method = "smc";
@@ -190,18 +210,6 @@
resets = < 408>;
};
 
-   timer {
-   compatible = "arm,armv8-timer";
-   interrupts = ,
-,
-,
-;
-   };
-
wdt0: watchdog@e602 {
compatible = "renesas,r8a7796-wdt",
 "renesas,rcar-gen3-wdt";
@@ -337,26 +345,6 @@
reg = <0 0xe606 0 0x50c>;
};
 
-   pmu_a57 {
-   compatible = "arm,cortex-a57-pmu";
-   interrupts = ,
-;
-   interrupt-affinity = <_0>,
-<_1>;
-   

[PATCH 1/3] arm64: dts: renesas: r8a7796: sort subnodes of root node alphabetically

[Simon Horman]

Sort root sub-nodes alphabetically for allow for easier maintenance
of this file.

Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 66 
 1 file changed, 33 insertions(+), 33 deletions(-)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index cc0cca7c0494..c1b0d0344329 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -30,9 +30,34 @@
i2c7 = _dvfs;
};
 
-   psci {
-   compatible = "arm,psci-1.0", "arm,psci-0.2";
-   method = "smc";
+   /*
+* The external audio clocks are configured as 0 Hz fixed frequency
+* clocks by default.
+* Boards that provide audio clocks should override them.
+*/
+   audio_clk_a: audio_clk_a {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   audio_clk_b: audio_clk_b {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   audio_clk_c: audio_clk_c {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
+   };
+
+   /* External CAN clock - to be overridden by boards that provide it */
+   can_clk: can {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <0>;
};
 
cpus {
@@ -122,34 +147,16 @@
clock-frequency = <0>;
};
 
-   /*
-* The external audio clocks are configured as 0 Hz fixed frequency
-* clocks by default.
-* Boards that provide audio clocks should override them.
-*/
-   audio_clk_a: audio_clk_a {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
-   audio_clk_b: audio_clk_b {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
-   audio_clk_c: audio_clk_c {
+   /* External PCIe clock - can be overridden by the board */
+   pcie_bus_clk: pcie_bus {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <0>;
};
 
-   /* External CAN clock - to be overridden by boards that provide it */
-   can_clk: can {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
+   psci {
+   compatible = "arm,psci-1.0", "arm,psci-0.2";
+   method = "smc";
};
 
/* External SCIF clock - to be overridden by boards that provide it */
@@ -159,13 +166,6 @@
clock-frequency = <0>;
};
 
-   /* External PCIe clock - can be overridden by the board */
-   pcie_bus_clk: pcie_bus {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
soc {
compatible = "simple-bus";
interrupt-parent = <>;
-- 
2.11.0

[PATCH 3/3] arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes

[Simon Horman]

Add reg properties to pciec[01] placeholder nodes

This is to stop the compiler complaining as follows:
$ make
...
  DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning 
(unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning 
(unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/pcie@fe00 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): 
Node /soc/pcie@ee80 missing or empty reg/ranges property
  DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): 
Node /soc/pcie@fe00 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): 
Node /soc/pcie@ee80 has a unit name, but no reg property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/pcie@fe00 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node 
/soc/pcie@ee80 missing or empty reg/ranges property
  DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning 
(unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning 
(unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/pcie@fe00 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): 
Node /soc/pcie@ee80 missing or empty reg/ranges property
  DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
(unit_address_vs_reg): Node /soc/pcie@fe00 has a unit name, but no reg 
property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning 
(unit_address_vs_reg): Node /soc/pcie@ee80 has a unit name, but no reg 
property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): 
Node /soc/pcie@fe00 missing or empty reg/ranges property
arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): 
Node /soc/pcie@ee80 missing or empty reg/ranges property

Signed-off-by: Simon Horman 
---
 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi 
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index bf971979aba8..388229072050 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -1762,10 +1762,12 @@
};
 
pciec0: pcie@fe00 {
+   reg = <0 0xfe00 0 0x8>;
/* placeholder */
};
 
pciec1: pcie@ee80 {
+   reg = <0 0xee80 0 0x8>;
/* placeholder */
};
 
-- 
2.11.0

Re: [PATCH v2 2/3] PM / core: Add IN_BAND_WAKEUP driver flag

[Geert Uytterhoeven]

Hi Ulf,

On Mon, Dec 11, 2017 at 9:59 PM, Ulf Hansson  wrote:
> That together with an option of allowing "consumed resource-devices"
> (irqchip) to be included in the wakeup path. I am thinking, perhaps
> another driver PM flag (DPM_FLAG_WAKEUP_PATH), that the PM core looks
> at and sets ->power.wakeup_path flag for the device and its parents.

This is complicated by the fact that currently the device and irq
subsystems don't really share data. E.g. {en,dis}able_irq_wake() and
irq_set_irq_wake() don't take a device parameter, only an interrupt number,
and conversion from interrupt numbers to devices is non-trivial.
That's why I handled it in the irqchip drivers in the series referenced
below.

> [1]
> https://www.spinics.net/lists/linux-renesas-soc/msg19947.html

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds