[PATCH 2/5] USB: serial: f81232: add high baud rate support

[Ji-Ze Hong (Peter Hong)]

The F81232 had 4 clocksource 1.846/18.46/14.77/24MHz and baud rates
can be up to 1.5Mbits with 24MHz.

F81232 Clock registers (106h)

Bit1-0: Clock source selector
00: 1.846MHz.
01: 18.46MHz.
10: 24MHz.
11: 14.77MHz.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81232.c | 105 +++-
 1 file changed, 94 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 46836041c50e..bdd7f337cd5f 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -28,7 +28,8 @@ static const struct usb_device_id id_table[] = {
 MODULE_DEVICE_TABLE(usb, id_table);
 
 /* Maximum baudrate for F81232 */
-#define F81232_MAX_BAUDRATE115200
+#define F81232_MAX_BAUDRATE150
+#define F81232_DEF_BAUDRATE9600
 
 /* USB Control EP parameter */
 #define F81232_REGISTER_REQUEST0xa0
@@ -44,18 +45,42 @@ MODULE_DEVICE_TABLE(usb, id_table);
 #define LINE_STATUS_REGISTER   (0x05 + SERIAL_BASE_ADDRESS)
 #define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
 
+/*
+ * F81232 Clock registers (106h)
+ *
+ * Bit1-0: Clock source selector
+ * 00: 1.846MHz.
+ * 01: 18.46MHz.
+ * 10: 24MHz.
+ * 11: 14.77MHz.
+ */
+#define F81232_CLK_REGISTER0x106
+#define F81232_CLK_1_846_MHZ   0
+#define F81232_CLK_18_46_MHZ   BIT(0)
+#define F81232_CLK_24_MHZ  BIT(1)
+#define F81232_CLK_14_77_MHZ   (BIT(1) | BIT(0))
+#define F81232_CLK_MASKGENMASK(1, 0)
+
 struct f81232_private {
struct mutex lock;
u8 modem_control;
u8 modem_status;
+   speed_t baud_base;
struct work_struct lsr_work;
struct work_struct interrupt_work;
struct usb_serial_port *port;
 };
 
-static int calc_baud_divisor(speed_t baudrate)
+static u32 const baudrate_table[] = { 115200, 921600, 1152000, 150 };
+static u8 const clock_table[] = { F81232_CLK_1_846_MHZ, F81232_CLK_14_77_MHZ,
+   F81232_CLK_18_46_MHZ, F81232_CLK_24_MHZ };
+
+static int calc_baud_divisor(speed_t baudrate, speed_t clockrate)
 {
-   return DIV_ROUND_CLOSEST(F81232_MAX_BAUDRATE, baudrate);
+   if (!baudrate)
+   return 0;
+
+   return DIV_ROUND_CLOSEST(clockrate, baudrate);
 }
 
 static int f81232_get_register(struct usb_serial_port *port, u16 reg, u8 *val)
@@ -129,6 +154,21 @@ static int f81232_set_register(struct usb_serial_port 
*port, u16 reg, u8 val)
return status;
 }
 
+static int f81232_set_mask_register(struct usb_serial_port *port, u16 reg,
+   u8 mask, u8 val)
+{
+   int status;
+   u8 tmp;
+
+   status = f81232_get_register(port, reg, );
+   if (status)
+   return status;
+
+   tmp = (tmp & ~mask) | (val & mask);
+
+   return f81232_set_register(port, reg, tmp);
+}
+
 static void f81232_read_msr(struct usb_serial_port *port)
 {
int status;
@@ -346,13 +386,53 @@ static void f81232_break_ctl(struct tty_struct *tty, int 
break_state)
 */
 }
 
-static void f81232_set_baudrate(struct usb_serial_port *port, speed_t baudrate)
+static int f81232_find_clk(speed_t baudrate)
+{
+   int idx;
+
+   for (idx = 0; idx < ARRAY_SIZE(baudrate_table); ++idx) {
+   if (baudrate <= baudrate_table[idx] &&
+   baudrate_table[idx] % baudrate == 0)
+   return idx;
+   }
+
+   return -EINVAL;
+}
+
+static void f81232_set_baudrate(struct tty_struct *tty,
+   struct usb_serial_port *port, speed_t baudrate,
+   speed_t old_baudrate)
 {
+   struct f81232_private *priv = usb_get_serial_port_data(port);
u8 lcr;
int divisor;
int status = 0;
+   int i;
+   int idx;
+   speed_t baud_list[] = {baudrate, old_baudrate, F81232_DEF_BAUDRATE};
+
+   for (i = 0; i < ARRAY_SIZE(baud_list); ++i) {
+   idx = f81232_find_clk(baud_list[i]);
+   if (idx >= 0) {
+   baudrate = baud_list[i];
+   tty_encode_baud_rate(tty, baudrate, baudrate);
+   break;
+   }
+   }
 
-   divisor = calc_baud_divisor(baudrate);
+   if (idx < 0)
+   return;
+
+   priv->baud_base = baudrate_table[idx];
+   divisor = calc_baud_divisor(baudrate, priv->baud_base);
+
+   status = f81232_set_mask_register(port, F81232_CLK_REGISTER,
+   F81232_CLK_MASK, clock_table[idx]);
+   if (status) {
+   dev_err(>dev, "%s failed to set CLK_REG: %d\n",
+   __func__, status);
+

[PATCH 5/5] USB: serial: f81232: fix bulk_in/out size

[Ji-Ze Hong (Peter Hong)]

Fix Fintek F81232 bulk_in/out size to 64/16 according to the spec.
http://html.alldatasheet.com/html-pdf/406315/FINTEK/F81232/1762/8/F81232.html

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81232.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index a054f69446fd..f3ee537d643c 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -769,8 +769,7 @@ static struct usb_serial_driver f81232_device = {
},
.id_table = id_table,
.num_ports =1,
-   .bulk_in_size = 256,
-   .bulk_out_size =256,
+   .bulk_out_size =16,
.open = f81232_open,
.close =f81232_close,
.dtr_rts =  f81232_dtr_rts,
-- 
2.7.4

[PATCH 4/5] USB: serial: f81232: implement break control

[Ji-Ze Hong (Peter Hong)]

Implement Fintek F81232 break on/off with LCR register.
It's the same with 16550A LCR register layout.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81232.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index dadf024ae494..a054f69446fd 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -377,13 +377,18 @@ static void f81232_process_read_urb(struct urb *urb)
 
 static void f81232_break_ctl(struct tty_struct *tty, int break_state)
 {
-   /* FIXME - Stubbed out for now */
+   struct usb_serial_port *port = tty->driver_data;
+   struct f81232_private *priv = usb_get_serial_port_data(port);
+   int status;
 
-   /*
-* break_state = -1 to turn on break, and 0 to turn off break
-* see drivers/char/tty_io.c to see it used.
-* last_set_data_urb_value NEVER has the break bit set in it.
-*/
+   mutex_lock(>lock);
+
+   status = f81232_set_mask_register(port, LINE_CONTROL_REGISTER,
+   UART_LCR_SBC, !!break_state);
+   if (status)
+   dev_err(>dev, "set break failed: %d\n", status);
+
+   mutex_unlock(>lock);
 }
 
 static int f81232_find_clk(speed_t baudrate)
-- 
2.7.4

[PATCH 2/5] USB: serial: f81232: add high baud rate support

[Ji-Ze Hong (Peter Hong)]

The F81232 had 4 clocksource 1.846/18.46/14.77/24MHz and baud rates
can be up to 1.5Mbits with 24MHz.

F81232 Clock registers (106h)

Bit1-0: Clock source selector
00: 1.846MHz.
01: 18.46MHz.
10: 24MHz.
11: 14.77MHz.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81232.c | 105 +++-
 1 file changed, 94 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 46836041c50e..bdd7f337cd5f 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -28,7 +28,8 @@ static const struct usb_device_id id_table[] = {
 MODULE_DEVICE_TABLE(usb, id_table);
 
 /* Maximum baudrate for F81232 */
-#define F81232_MAX_BAUDRATE115200
+#define F81232_MAX_BAUDRATE150
+#define F81232_DEF_BAUDRATE9600
 
 /* USB Control EP parameter */
 #define F81232_REGISTER_REQUEST0xa0
@@ -44,18 +45,42 @@ MODULE_DEVICE_TABLE(usb, id_table);
 #define LINE_STATUS_REGISTER   (0x05 + SERIAL_BASE_ADDRESS)
 #define MODEM_STATUS_REGISTER  (0x06 + SERIAL_BASE_ADDRESS)
 
+/*
+ * F81232 Clock registers (106h)
+ *
+ * Bit1-0: Clock source selector
+ * 00: 1.846MHz.
+ * 01: 18.46MHz.
+ * 10: 24MHz.
+ * 11: 14.77MHz.
+ */
+#define F81232_CLK_REGISTER0x106
+#define F81232_CLK_1_846_MHZ   0
+#define F81232_CLK_18_46_MHZ   BIT(0)
+#define F81232_CLK_24_MHZ  BIT(1)
+#define F81232_CLK_14_77_MHZ   (BIT(1) | BIT(0))
+#define F81232_CLK_MASKGENMASK(1, 0)
+
 struct f81232_private {
struct mutex lock;
u8 modem_control;
u8 modem_status;
+   speed_t baud_base;
struct work_struct lsr_work;
struct work_struct interrupt_work;
struct usb_serial_port *port;
 };
 
-static int calc_baud_divisor(speed_t baudrate)
+static u32 const baudrate_table[] = { 115200, 921600, 1152000, 150 };
+static u8 const clock_table[] = { F81232_CLK_1_846_MHZ, F81232_CLK_14_77_MHZ,
+   F81232_CLK_18_46_MHZ, F81232_CLK_24_MHZ };
+
+static int calc_baud_divisor(speed_t baudrate, speed_t clockrate)
 {
-   return DIV_ROUND_CLOSEST(F81232_MAX_BAUDRATE, baudrate);
+   if (!baudrate)
+   return 0;
+
+   return DIV_ROUND_CLOSEST(clockrate, baudrate);
 }
 
 static int f81232_get_register(struct usb_serial_port *port, u16 reg, u8 *val)
@@ -129,6 +154,21 @@ static int f81232_set_register(struct usb_serial_port 
*port, u16 reg, u8 val)
return status;
 }
 
+static int f81232_set_mask_register(struct usb_serial_port *port, u16 reg,
+   u8 mask, u8 val)
+{
+   int status;
+   u8 tmp;
+
+   status = f81232_get_register(port, reg, );
+   if (status)
+   return status;
+
+   tmp = (tmp & ~mask) | (val & mask);
+
+   return f81232_set_register(port, reg, tmp);
+}
+
 static void f81232_read_msr(struct usb_serial_port *port)
 {
int status;
@@ -346,13 +386,53 @@ static void f81232_break_ctl(struct tty_struct *tty, int 
break_state)
 */
 }
 
-static void f81232_set_baudrate(struct usb_serial_port *port, speed_t baudrate)
+static int f81232_find_clk(speed_t baudrate)
+{
+   int idx;
+
+   for (idx = 0; idx < ARRAY_SIZE(baudrate_table); ++idx) {
+   if (baudrate <= baudrate_table[idx] &&
+   baudrate_table[idx] % baudrate == 0)
+   return idx;
+   }
+
+   return -EINVAL;
+}
+
+static void f81232_set_baudrate(struct tty_struct *tty,
+   struct usb_serial_port *port, speed_t baudrate,
+   speed_t old_baudrate)
 {
+   struct f81232_private *priv = usb_get_serial_port_data(port);
u8 lcr;
int divisor;
int status = 0;
+   int i;
+   int idx;
+   speed_t baud_list[] = {baudrate, old_baudrate, F81232_DEF_BAUDRATE};
+
+   for (i = 0; i < ARRAY_SIZE(baud_list); ++i) {
+   idx = f81232_find_clk(baud_list[i]);
+   if (idx >= 0) {
+   baudrate = baud_list[i];
+   tty_encode_baud_rate(tty, baudrate, baudrate);
+   break;
+   }
+   }
 
-   divisor = calc_baud_divisor(baudrate);
+   if (idx < 0)
+   return;
+
+   priv->baud_base = baudrate_table[idx];
+   divisor = calc_baud_divisor(baudrate, priv->baud_base);
+
+   status = f81232_set_mask_register(port, F81232_CLK_REGISTER,
+   F81232_CLK_MASK, clock_table[idx]);
+   if (status) {
+   dev_err(>dev, "%s failed to set CLK_REG: %d\n",
+   __func__, status);
+   return;
+   }
 

[PATCH 5/5] USB: serial: f81232: fix bulk_in/out size

[Ji-Ze Hong (Peter Hong)]

Fix Fintek F81232 bulk_in/out size to 64/16 according to the spec.
http://html.alldatasheet.com/html-pdf/406315/FINTEK/F81232/1762/8/F81232.html

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81232.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index a054f69446fd..f3ee537d643c 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -769,8 +769,7 @@ static struct usb_serial_driver f81232_device = {
},
.id_table = id_table,
.num_ports =1,
-   .bulk_in_size = 256,
-   .bulk_out_size =256,
+   .bulk_out_size =16,
.open = f81232_open,
.close =f81232_close,
.dtr_rts =  f81232_dtr_rts,
-- 
2.7.4

[PATCH 4/5] USB: serial: f81232: implement break control

[Ji-Ze Hong (Peter Hong)]

Implement Fintek F81232 break on/off with LCR register.
It's the same with 16550A LCR register layout.

Signed-off-by: Ji-Ze Hong (Peter Hong) 
---
 drivers/usb/serial/f81232.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index dadf024ae494..a054f69446fd 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -377,13 +377,18 @@ static void f81232_process_read_urb(struct urb *urb)
 
 static void f81232_break_ctl(struct tty_struct *tty, int break_state)
 {
-   /* FIXME - Stubbed out for now */
+   struct usb_serial_port *port = tty->driver_data;
+   struct f81232_private *priv = usb_get_serial_port_data(port);
+   int status;
 
-   /*
-* break_state = -1 to turn on break, and 0 to turn off break
-* see drivers/char/tty_io.c to see it used.
-* last_set_data_urb_value NEVER has the break bit set in it.
-*/
+   mutex_lock(>lock);
+
+   status = f81232_set_mask_register(port, LINE_CONTROL_REGISTER,
+   UART_LCR_SBC, !!break_state);
+   if (status)
+   dev_err(>dev, "set break failed: %d\n", status);
+
+   mutex_unlock(>lock);
 }
 
 static int f81232_find_clk(speed_t baudrate)
-- 
2.7.4

[PATCH] nvme-pci: ensure nvme_timeout complete before initializing procedure

[Jianchao Wang]

There could be a nvme_timeout running with nvme_dev_disable in
parallel. The requests held by timeout path cannot be canceled
by nvme_dev_disable. Consequently, the nvme_timeout maybe still
running after nvme_dev_disable completes. Then there could be a
race between nvme_dev_disable in nvme_timeout and initializing
procedure in nvme_reset_work.
nvme_timeout   nvme_reset_work
if (RESETTING) nvme_dev_disable
nvme_dev_disable   initializing

To fix it, ensure all the q->timeout_work complete before the
initializing procedure in nvme_reset_work. At the moment, all the
outstanding requests should have been handled by nvme_dev_disable
or nvme_timeout.
So introduce nvme_sync_queues which invokes blk_sync_queue. In
addition to this, add blk_mq_kick_requeue_list into nvme_start_queues
and nvme_kill_queues to avoid IO hang in requeue_list, because
blk_sync_queue will cancel the requeue_work.

Link: https://lkml.org/lkml/2018/1/19/68
Suggested-by: Keith Busch 
Signed-off-by: Keith Busch 
Signed-off-by: Jianchao Wang 
---
 drivers/nvme/host/core.c | 20 ++--
 drivers/nvme/host/nvme.h |  1 +
 drivers/nvme/host/pci.c  |  9 -
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 23b3e53..c2ea8adb 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3443,7 +3443,11 @@ void nvme_kill_queues(struct nvme_ctrl *ctrl)
revalidate_disk(ns->disk);
blk_set_queue_dying(ns->queue);
 
-   /* Forcibly unquiesce queues to avoid blocking dispatch */
+   /*
+* Forcibly kick requeue and unquiesce queues to avoid blocking
+* dispatch
+*/
+   blk_mq_kick_requeue_list(ns->queue);
blk_mq_unquiesce_queue(ns->queue);
}
mutex_unlock(>namespaces_mutex);
@@ -3513,12 +3517,24 @@ void nvme_start_queues(struct nvme_ctrl *ctrl)
struct nvme_ns *ns;
 
mutex_lock(>namespaces_mutex);
-   list_for_each_entry(ns, >namespaces, list)
+   list_for_each_entry(ns, >namespaces, list) {
+   blk_mq_kick_requeue_list(ns->queue);
blk_mq_unquiesce_queue(ns->queue);
+   }
mutex_unlock(>namespaces_mutex);
 }
 EXPORT_SYMBOL_GPL(nvme_start_queues);
 
+void nvme_sync_queues(struct nvme_ctrl *ctrl)
+{
+   struct nvme_ns *ns;
+
+   mutex_lock(>namespaces_mutex);
+   list_for_each_entry(ns, >namespaces, list)
+   blk_sync_queue(ns->queue);
+   mutex_unlock(>namespaces_mutex);
+}
+EXPORT_SYMBOL_GPL(nvme_sync_queues);
 int nvme_reinit_tagset(struct nvme_ctrl *ctrl, struct blk_mq_tag_set *set)
 {
if (!ctrl->ops->reinit_request)
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index a44eeca..01faea6 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -370,6 +370,7 @@ int nvme_sec_submit(void *data, u16 spsp, u8 secp, void 
*buffer, size_t len,
 void nvme_complete_async_event(struct nvme_ctrl *ctrl, __le16 status,
union nvme_result *res);
 
+void nvme_sync_queues(struct nvme_ctrl *ctrl);
 void nvme_stop_queues(struct nvme_ctrl *ctrl);
 void nvme_start_queues(struct nvme_ctrl *ctrl);
 void nvme_kill_queues(struct nvme_ctrl *ctrl);
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index f5207bc..9ba7e55 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2318,8 +2318,15 @@ static void nvme_reset_work(struct work_struct *work)
 * If we're called to reset a live controller first shut it down before
 * moving on.
 */
-   if (dev->ctrl.ctrl_config & NVME_CC_ENABLE)
+   if (dev->ctrl.ctrl_config & NVME_CC_ENABLE) {
nvme_dev_disable(dev, false);
+   /* nvme_timeout could run in parallel, consequently,
+* nvme_dev_disable invoked by nvme_timeout could race with
+* following initializing procedure. So add nvme_sync_queues
+* here to ensure nvme_timeout to be completed.
+*/
+   nvme_sync_queues(>ctrl);
+   }
 
/*
 * Introduce RECONNECTING state from nvme-fc/rdma transports to mark the
-- 
2.7.4

[PATCH] nvme-pci: ensure nvme_timeout complete before initializing procedure

[Jianchao Wang]

There could be a nvme_timeout running with nvme_dev_disable in
parallel. The requests held by timeout path cannot be canceled
by nvme_dev_disable. Consequently, the nvme_timeout maybe still
running after nvme_dev_disable completes. Then there could be a
race between nvme_dev_disable in nvme_timeout and initializing
procedure in nvme_reset_work.
nvme_timeout   nvme_reset_work
if (RESETTING) nvme_dev_disable
nvme_dev_disable   initializing

To fix it, ensure all the q->timeout_work complete before the
initializing procedure in nvme_reset_work. At the moment, all the
outstanding requests should have been handled by nvme_dev_disable
or nvme_timeout.
So introduce nvme_sync_queues which invokes blk_sync_queue. In
addition to this, add blk_mq_kick_requeue_list into nvme_start_queues
and nvme_kill_queues to avoid IO hang in requeue_list, because
blk_sync_queue will cancel the requeue_work.

Link: https://lkml.org/lkml/2018/1/19/68
Suggested-by: Keith Busch 
Signed-off-by: Keith Busch 
Signed-off-by: Jianchao Wang 
---
 drivers/nvme/host/core.c | 20 ++--
 drivers/nvme/host/nvme.h |  1 +
 drivers/nvme/host/pci.c  |  9 -
 3 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 23b3e53..c2ea8adb 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -3443,7 +3443,11 @@ void nvme_kill_queues(struct nvme_ctrl *ctrl)
revalidate_disk(ns->disk);
blk_set_queue_dying(ns->queue);
 
-   /* Forcibly unquiesce queues to avoid blocking dispatch */
+   /*
+* Forcibly kick requeue and unquiesce queues to avoid blocking
+* dispatch
+*/
+   blk_mq_kick_requeue_list(ns->queue);
blk_mq_unquiesce_queue(ns->queue);
}
mutex_unlock(>namespaces_mutex);
@@ -3513,12 +3517,24 @@ void nvme_start_queues(struct nvme_ctrl *ctrl)
struct nvme_ns *ns;
 
mutex_lock(>namespaces_mutex);
-   list_for_each_entry(ns, >namespaces, list)
+   list_for_each_entry(ns, >namespaces, list) {
+   blk_mq_kick_requeue_list(ns->queue);
blk_mq_unquiesce_queue(ns->queue);
+   }
mutex_unlock(>namespaces_mutex);
 }
 EXPORT_SYMBOL_GPL(nvme_start_queues);
 
+void nvme_sync_queues(struct nvme_ctrl *ctrl)
+{
+   struct nvme_ns *ns;
+
+   mutex_lock(>namespaces_mutex);
+   list_for_each_entry(ns, >namespaces, list)
+   blk_sync_queue(ns->queue);
+   mutex_unlock(>namespaces_mutex);
+}
+EXPORT_SYMBOL_GPL(nvme_sync_queues);
 int nvme_reinit_tagset(struct nvme_ctrl *ctrl, struct blk_mq_tag_set *set)
 {
if (!ctrl->ops->reinit_request)
diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
index a44eeca..01faea6 100644
--- a/drivers/nvme/host/nvme.h
+++ b/drivers/nvme/host/nvme.h
@@ -370,6 +370,7 @@ int nvme_sec_submit(void *data, u16 spsp, u8 secp, void 
*buffer, size_t len,
 void nvme_complete_async_event(struct nvme_ctrl *ctrl, __le16 status,
union nvme_result *res);
 
+void nvme_sync_queues(struct nvme_ctrl *ctrl);
 void nvme_stop_queues(struct nvme_ctrl *ctrl);
 void nvme_start_queues(struct nvme_ctrl *ctrl);
 void nvme_kill_queues(struct nvme_ctrl *ctrl);
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index f5207bc..9ba7e55 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2318,8 +2318,15 @@ static void nvme_reset_work(struct work_struct *work)
 * If we're called to reset a live controller first shut it down before
 * moving on.
 */
-   if (dev->ctrl.ctrl_config & NVME_CC_ENABLE)
+   if (dev->ctrl.ctrl_config & NVME_CC_ENABLE) {
nvme_dev_disable(dev, false);
+   /* nvme_timeout could run in parallel, consequently,
+* nvme_dev_disable invoked by nvme_timeout could race with
+* following initializing procedure. So add nvme_sync_queues
+* here to ensure nvme_timeout to be completed.
+*/
+   nvme_sync_queues(>ctrl);
+   }
 
/*
 * Introduce RECONNECTING state from nvme-fc/rdma transports to mark the
-- 
2.7.4

[PATCH TRIVIAL] bsg: use pr_debug instead of hand crafted macros

[Johannes Thumshirn]

Use pr_debug instead of hand crafted macros. This way it is not needed to
re-compile the kernel to enable bsg debug outputs and it's possible to
selectively enable specific prints.

Signed-off-by: Johannes Thumshirn 
---
 block/bsg.c | 35 +--
 1 file changed, 13 insertions(+), 22 deletions(-)

diff --git a/block/bsg.c b/block/bsg.c
index 452f94f1c5d4..508e73c60add 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -55,14 +55,6 @@ enum {
 #define BSG_DEFAULT_CMDS   64
 #define BSG_MAX_DEVS   32768
 
-#undef BSG_DEBUG
-
-#ifdef BSG_DEBUG
-#define dprintk(fmt, args...) printk(KERN_ERR "%s: " fmt, __func__, ##args)
-#else
-#define dprintk(fmt, args...)
-#endif
-
 static DEFINE_MUTEX(bsg_mutex);
 static DEFINE_IDR(bsg_minor_idr);
 
@@ -123,7 +115,7 @@ static struct bsg_command *bsg_alloc_command(struct 
bsg_device *bd)
 
bc->bd = bd;
INIT_LIST_HEAD(>list);
-   dprintk("%s: returning free cmd %p\n", bd->name, bc);
+   pr_debug("%s: returning free cmd %p\n", bd->name, bc);
return bc;
 out:
spin_unlock_irq(>lock);
@@ -222,7 +214,8 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr, 
fmode_t mode)
if (!bcd->class_dev)
return ERR_PTR(-ENXIO);
 
-   dprintk("map hdr %llx/%u %llx/%u\n", (unsigned long long) 
hdr->dout_xferp,
+   pr_debug("map hdr %llx/%u %llx/%u\n",
+(unsigned long long) hdr->dout_xferp,
hdr->dout_xfer_len, (unsigned long long) hdr->din_xferp,
hdr->din_xfer_len);
 
@@ -299,7 +292,7 @@ static void bsg_rq_end_io(struct request *rq, blk_status_t 
status)
struct bsg_device *bd = bc->bd;
unsigned long flags;
 
-   dprintk("%s: finished rq %p bc %p, bio %p\n",
+   pr_debug("%s: finished rq %p bc %p, bio %p\n",
bd->name, rq, bc, bc->bio);
 
bc->hdr.duration = jiffies_to_msecs(jiffies - bc->hdr.duration);
@@ -333,7 +326,7 @@ static void bsg_add_command(struct bsg_device *bd, struct 
request_queue *q,
list_add_tail(>list, >busy_list);
spin_unlock_irq(>lock);
 
-   dprintk("%s: queueing rq %p, bc %p\n", bd->name, rq, bc);
+   pr_debug("%s: queueing rq %p, bc %p\n", bd->name, rq, bc);
 
rq->end_io_data = bc;
blk_execute_rq_nowait(q, NULL, rq, at_head, bsg_rq_end_io);
@@ -379,7 +372,7 @@ static struct bsg_command *bsg_get_done_cmd(struct 
bsg_device *bd)
}
} while (1);
 
-   dprintk("%s: returning done %p\n", bd->name, bc);
+   pr_debug("%s: returning done %p\n", bd->name, bc);
 
return bc;
 }
@@ -390,7 +383,7 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq, 
struct sg_io_v4 *hdr,
struct scsi_request *req = scsi_req(rq);
int ret = 0;
 
-   dprintk("rq %p bio %p 0x%x\n", rq, bio, req->result);
+   pr_debug("rq %p bio %p 0x%x\n", rq, bio, req->result);
/*
 * fill in all the output members
 */
@@ -469,7 +462,7 @@ static int bsg_complete_all_commands(struct bsg_device *bd)
struct bsg_command *bc;
int ret, tret;
 
-   dprintk("%s: entered\n", bd->name);
+   pr_debug("%s: entered\n", bd->name);
 
/*
 * wait for all commands to complete
@@ -572,7 +565,7 @@ bsg_read(struct file *file, char __user *buf, size_t count, 
loff_t *ppos)
int ret;
ssize_t bytes_read;
 
-   dprintk("%s: read %zd bytes\n", bd->name, count);
+   pr_debug("%s: read %zd bytes\n", bd->name, count);
 
bsg_set_block(bd, file);
 
@@ -646,7 +639,7 @@ bsg_write(struct file *file, const char __user *buf, size_t 
count, loff_t *ppos)
ssize_t bytes_written;
int ret;
 
-   dprintk("%s: write %zd bytes\n", bd->name, count);
+   pr_debug("%s: write %zd bytes\n", bd->name, count);
 
if (unlikely(uaccess_kernel()))
return -EINVAL;
@@ -664,7 +657,7 @@ bsg_write(struct file *file, const char __user *buf, size_t 
count, loff_t *ppos)
if (!bytes_written || err_block_err(ret))
bytes_written = ret;
 
-   dprintk("%s: returning %zd\n", bd->name, bytes_written);
+   pr_debug("%s: returning %zd\n", bd->name, bytes_written);
return bytes_written;
 }
 
@@ -717,7 +710,7 @@ static int bsg_put_device(struct bsg_device *bd)
hlist_del(>dev_list);
mutex_unlock(_mutex);
 
-   dprintk("%s: tearing down\n", bd->name);
+   pr_debug("%s: tearing down\n", bd->name);
 
/*
 * close can always block
@@ -744,9 +737,7 @@ static struct bsg_device *bsg_add_device(struct inode 
*inode,
 struct file *file)
 {
struct bsg_device *bd;
-#ifdef BSG_DEBUG
unsigned char buf[32];
-#endif
 
if (!blk_queue_scsi_passthrough(rq)) {
WARN_ONCE(true, "Attempt to register a non-SCSI queue\n");
@@ -771,7 +762,7 @@ static struct bsg_device *bsg_add_device(struct inode 

[PATCH TRIVIAL] bsg: use pr_debug instead of hand crafted macros

[Johannes Thumshirn]

Use pr_debug instead of hand crafted macros. This way it is not needed to
re-compile the kernel to enable bsg debug outputs and it's possible to
selectively enable specific prints.

Signed-off-by: Johannes Thumshirn 
---
 block/bsg.c | 35 +--
 1 file changed, 13 insertions(+), 22 deletions(-)

diff --git a/block/bsg.c b/block/bsg.c
index 452f94f1c5d4..508e73c60add 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -55,14 +55,6 @@ enum {
 #define BSG_DEFAULT_CMDS   64
 #define BSG_MAX_DEVS   32768
 
-#undef BSG_DEBUG
-
-#ifdef BSG_DEBUG
-#define dprintk(fmt, args...) printk(KERN_ERR "%s: " fmt, __func__, ##args)
-#else
-#define dprintk(fmt, args...)
-#endif
-
 static DEFINE_MUTEX(bsg_mutex);
 static DEFINE_IDR(bsg_minor_idr);
 
@@ -123,7 +115,7 @@ static struct bsg_command *bsg_alloc_command(struct 
bsg_device *bd)
 
bc->bd = bd;
INIT_LIST_HEAD(>list);
-   dprintk("%s: returning free cmd %p\n", bd->name, bc);
+   pr_debug("%s: returning free cmd %p\n", bd->name, bc);
return bc;
 out:
spin_unlock_irq(>lock);
@@ -222,7 +214,8 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr, 
fmode_t mode)
if (!bcd->class_dev)
return ERR_PTR(-ENXIO);
 
-   dprintk("map hdr %llx/%u %llx/%u\n", (unsigned long long) 
hdr->dout_xferp,
+   pr_debug("map hdr %llx/%u %llx/%u\n",
+(unsigned long long) hdr->dout_xferp,
hdr->dout_xfer_len, (unsigned long long) hdr->din_xferp,
hdr->din_xfer_len);
 
@@ -299,7 +292,7 @@ static void bsg_rq_end_io(struct request *rq, blk_status_t 
status)
struct bsg_device *bd = bc->bd;
unsigned long flags;
 
-   dprintk("%s: finished rq %p bc %p, bio %p\n",
+   pr_debug("%s: finished rq %p bc %p, bio %p\n",
bd->name, rq, bc, bc->bio);
 
bc->hdr.duration = jiffies_to_msecs(jiffies - bc->hdr.duration);
@@ -333,7 +326,7 @@ static void bsg_add_command(struct bsg_device *bd, struct 
request_queue *q,
list_add_tail(>list, >busy_list);
spin_unlock_irq(>lock);
 
-   dprintk("%s: queueing rq %p, bc %p\n", bd->name, rq, bc);
+   pr_debug("%s: queueing rq %p, bc %p\n", bd->name, rq, bc);
 
rq->end_io_data = bc;
blk_execute_rq_nowait(q, NULL, rq, at_head, bsg_rq_end_io);
@@ -379,7 +372,7 @@ static struct bsg_command *bsg_get_done_cmd(struct 
bsg_device *bd)
}
} while (1);
 
-   dprintk("%s: returning done %p\n", bd->name, bc);
+   pr_debug("%s: returning done %p\n", bd->name, bc);
 
return bc;
 }
@@ -390,7 +383,7 @@ static int blk_complete_sgv4_hdr_rq(struct request *rq, 
struct sg_io_v4 *hdr,
struct scsi_request *req = scsi_req(rq);
int ret = 0;
 
-   dprintk("rq %p bio %p 0x%x\n", rq, bio, req->result);
+   pr_debug("rq %p bio %p 0x%x\n", rq, bio, req->result);
/*
 * fill in all the output members
 */
@@ -469,7 +462,7 @@ static int bsg_complete_all_commands(struct bsg_device *bd)
struct bsg_command *bc;
int ret, tret;
 
-   dprintk("%s: entered\n", bd->name);
+   pr_debug("%s: entered\n", bd->name);
 
/*
 * wait for all commands to complete
@@ -572,7 +565,7 @@ bsg_read(struct file *file, char __user *buf, size_t count, 
loff_t *ppos)
int ret;
ssize_t bytes_read;
 
-   dprintk("%s: read %zd bytes\n", bd->name, count);
+   pr_debug("%s: read %zd bytes\n", bd->name, count);
 
bsg_set_block(bd, file);
 
@@ -646,7 +639,7 @@ bsg_write(struct file *file, const char __user *buf, size_t 
count, loff_t *ppos)
ssize_t bytes_written;
int ret;
 
-   dprintk("%s: write %zd bytes\n", bd->name, count);
+   pr_debug("%s: write %zd bytes\n", bd->name, count);
 
if (unlikely(uaccess_kernel()))
return -EINVAL;
@@ -664,7 +657,7 @@ bsg_write(struct file *file, const char __user *buf, size_t 
count, loff_t *ppos)
if (!bytes_written || err_block_err(ret))
bytes_written = ret;
 
-   dprintk("%s: returning %zd\n", bd->name, bytes_written);
+   pr_debug("%s: returning %zd\n", bd->name, bytes_written);
return bytes_written;
 }
 
@@ -717,7 +710,7 @@ static int bsg_put_device(struct bsg_device *bd)
hlist_del(>dev_list);
mutex_unlock(_mutex);
 
-   dprintk("%s: tearing down\n", bd->name);
+   pr_debug("%s: tearing down\n", bd->name);
 
/*
 * close can always block
@@ -744,9 +737,7 @@ static struct bsg_device *bsg_add_device(struct inode 
*inode,
 struct file *file)
 {
struct bsg_device *bd;
-#ifdef BSG_DEBUG
unsigned char buf[32];
-#endif
 
if (!blk_queue_scsi_passthrough(rq)) {
WARN_ONCE(true, "Attempt to register a non-SCSI queue\n");
@@ -771,7 +762,7 @@ static struct bsg_device *bsg_add_device(struct inode 
*inode,

Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

[Christophe LEROY]

Le 20/01/2018 à 18:56, Segher Boessenkool a écrit :

Hi!

On Sat, Jan 20, 2018 at 09:22:50AM +0100, christophe leroy wrote:

On PPC32, the address space is limited to 4Gbytes, hence only the
low
slices will be used. As of today, the code uses
SLICE_LOW_TOP (0x1ul) and compares it with addr to determine
if addr refers to low or high space.
On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
0x1ul degrades to 0. Therefore, the patch modifies
SLICE_LOW_TOP to (0xul) and modifies the tests to
(addr <= SLICE_LOW_TOP) which will then always be true on PPC32
as addr has type 'unsigned long' while not modifying the PPC64
behaviour.


It should work to define SLICE_LOW_TOP as 0x1ull and keep
everything else the same, no?


great, yes it works indeed.




I don't think so. When I had the missing prototype, the compilation goes
ok, including the final link. Which means at the end the code is not
included since radix_enabled() evaluates to 0.

Many many parts of the kernel are based on this assumption.


Segher, what is your opinion on the above ? Can we consider that a ' if
(nbits)' will always be compiled out when nbits is a #define constant,
or should we duplicate the macros as suggested in order to avoid
unneccessary 'if' test on platforms where 'nbits' is always not null by
definition ?


Doing things like

if (nbits)
some_undeclared_function();

will likely work in practice if the condition evaluates to false at
compile time, but a) it will warn; b) it is just yuck; and c) it will
not always work (for example, you get the wrong prototype in this case,
not lethal here with most ABIs, but ugh).

Just make sure to declare all functions, or define it to some empty
thing, or #ifdeffery if you have to.  There are many options, it is
not hard, and if it means you have to pull code further apart that is
not so bad: you get cleaner, clearer code.


Ok, if I understand well, your comment applies to the following indeed, 
so you confirm the #ifdef is necessary.


--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -553,9 +553,11 @@ unsigned long hugetlb_get_unmapped_area(struct file 
*file, unsigned long addr,

struct hstate *hstate = hstate_file(file);
int mmu_psize = shift_to_mmu_psize(huge_page_shift(hstate));

+#ifdef CONFIG_PPC_RADIX_MMU
if (radix_enabled())
return radix__hugetlb_get_unmapped_area(file, addr, len,
   pgoff, flags);
+#endif
return slice_get_unmapped_area(addr, len, flags, mmu_psize, 1);
 }
 #endif


However, my question was related to another part of the current 
patchset, where the functions are always refined:



On PPC32 we set:

+#define SLICE_LOW_SHIFT28
+#define SLICE_HIGH_SHIFT   0

On PPC64 we set:

 #define SLICE_LOW_SHIFT28
 #define SLICE_HIGH_SHIFT   40

We define:

+#define slice_bitmap_zero(dst, nbits) \
+   do { if (nbits) bitmap_zero(dst, nbits); } while (0)


We have a function with:
{
slice_bitmap_zero(ret->low_slices, SLICE_NUM_LOW);
slice_bitmap_zero(ret->high_slices, SLICE_NUM_HIGH);
}

So the question is to find the better approach. Is the above approach 
correct, including performance wise ?
Or should we define two sets of the macro slice_bitmap_zero(), one for 
CONFIG_PPC32 with the 'if (nbits)' test and one for CONFIG_PPC64 without 
the unnecessary test ?


Or should we avoid this macro entirely and instead do something like:

{
bitmap_zero(ret->low_slices, SLICE_NUM_LOW);
#if SLICE_NUM_HIGH != 0
bitmap_zero(ret->high_slices, SLICE_NUM_HIGH);
#endif
}

And if we say the 'macro' approach is OK, should it be better the use a 
static inline function instead ?


Thanks,
Christophe

Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32

[Christophe LEROY]

Le 20/01/2018 à 18:56, Segher Boessenkool a écrit :

Hi!

On Sat, Jan 20, 2018 at 09:22:50AM +0100, christophe leroy wrote:

On PPC32, the address space is limited to 4Gbytes, hence only the
low
slices will be used. As of today, the code uses
SLICE_LOW_TOP (0x1ul) and compares it with addr to determine
if addr refers to low or high space.
On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
0x1ul degrades to 0. Therefore, the patch modifies
SLICE_LOW_TOP to (0xul) and modifies the tests to
(addr <= SLICE_LOW_TOP) which will then always be true on PPC32
as addr has type 'unsigned long' while not modifying the PPC64
behaviour.


It should work to define SLICE_LOW_TOP as 0x1ull and keep
everything else the same, no?


great, yes it works indeed.




I don't think so. When I had the missing prototype, the compilation goes
ok, including the final link. Which means at the end the code is not
included since radix_enabled() evaluates to 0.

Many many parts of the kernel are based on this assumption.


Segher, what is your opinion on the above ? Can we consider that a ' if
(nbits)' will always be compiled out when nbits is a #define constant,
or should we duplicate the macros as suggested in order to avoid
unneccessary 'if' test on platforms where 'nbits' is always not null by
definition ?


Doing things like

if (nbits)
some_undeclared_function();

will likely work in practice if the condition evaluates to false at
compile time, but a) it will warn; b) it is just yuck; and c) it will
not always work (for example, you get the wrong prototype in this case,
not lethal here with most ABIs, but ugh).

Just make sure to declare all functions, or define it to some empty
thing, or #ifdeffery if you have to.  There are many options, it is
not hard, and if it means you have to pull code further apart that is
not so bad: you get cleaner, clearer code.


Ok, if I understand well, your comment applies to the following indeed, 
so you confirm the #ifdef is necessary.


--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -553,9 +553,11 @@ unsigned long hugetlb_get_unmapped_area(struct file 
*file, unsigned long addr,

struct hstate *hstate = hstate_file(file);
int mmu_psize = shift_to_mmu_psize(huge_page_shift(hstate));

+#ifdef CONFIG_PPC_RADIX_MMU
if (radix_enabled())
return radix__hugetlb_get_unmapped_area(file, addr, len,
   pgoff, flags);
+#endif
return slice_get_unmapped_area(addr, len, flags, mmu_psize, 1);
 }
 #endif


However, my question was related to another part of the current 
patchset, where the functions are always refined:



On PPC32 we set:

+#define SLICE_LOW_SHIFT28
+#define SLICE_HIGH_SHIFT   0

On PPC64 we set:

 #define SLICE_LOW_SHIFT28
 #define SLICE_HIGH_SHIFT   40

We define:

+#define slice_bitmap_zero(dst, nbits) \
+   do { if (nbits) bitmap_zero(dst, nbits); } while (0)


We have a function with:
{
slice_bitmap_zero(ret->low_slices, SLICE_NUM_LOW);
slice_bitmap_zero(ret->high_slices, SLICE_NUM_HIGH);
}

So the question is to find the better approach. Is the above approach 
correct, including performance wise ?
Or should we define two sets of the macro slice_bitmap_zero(), one for 
CONFIG_PPC32 with the 'if (nbits)' test and one for CONFIG_PPC64 without 
the unnecessary test ?


Or should we avoid this macro entirely and instead do something like:

{
bitmap_zero(ret->low_slices, SLICE_NUM_LOW);
#if SLICE_NUM_HIGH != 0
bitmap_zero(ret->high_slices, SLICE_NUM_HIGH);
#endif
}

And if we say the 'macro' approach is OK, should it be better the use a 
static inline function instead ?


Thanks,
Christophe

Re: [PATCH 4.4 100/115] scsi: hpsa: destroy sas transport properties before scsi_host

[Greg Kroah-Hartman]

On Sun, Jan 21, 2018 at 11:05:42PM +, Ben Hutchings wrote:
> On Mon, 2017-12-18 at 16:49 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Martin Wilck 
> > 
> > 
> > [ Upstream commit dfb2e6f46b3074eb85203d8f0888b71ec1c2e37a ]
> > 
> > This patch cleans up a lot of warnings when unloading the driver.
> [...]
> > This patch did not help until Hannes's
> > commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod")
> > was applied to the kernel.
> [...]
> 
> So shouldn't that also be applied to stable branches?

Odd, it should :(

Sasha, any ideas here why that didn't happen?

thanks,

greg k-h

Re: [PATCH 4.4 100/115] scsi: hpsa: destroy sas transport properties before scsi_host

[Greg Kroah-Hartman]

On Sun, Jan 21, 2018 at 11:05:42PM +, Ben Hutchings wrote:
> On Mon, 2017-12-18 at 16:49 +0100, Greg Kroah-Hartman wrote:
> > 4.4-stable review patch.  If anyone has any objections, please let me know.
> > 
> > --
> > 
> > From: Martin Wilck 
> > 
> > 
> > [ Upstream commit dfb2e6f46b3074eb85203d8f0888b71ec1c2e37a ]
> > 
> > This patch cleans up a lot of warnings when unloading the driver.
> [...]
> > This patch did not help until Hannes's
> > commit 9441284fbc39 ("scsi-fixup-kernel-warning-during-rmmod")
> > was applied to the kernel.
> [...]
> 
> So shouldn't that also be applied to stable branches?

Odd, it should :(

Sasha, any ideas here why that didn't happen?

thanks,

greg k-h

[PATCH] dmaengine: dmatest: fix container_of member in dmatest_callback

[Yang Shunyong]

The type of arg passed to dmatest_callback is struct dmatest_done.
It refers to test_done in struct dmatest_thread, not done_wait.

Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
Signed-off-by: Yang Shunyong 
---
 drivers/dma/dmatest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index ec5f9d2bc820..906e85d6dedc 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
 {
struct dmatest_done *done = arg;
struct dmatest_thread *thread =
-   container_of(arg, struct dmatest_thread, done_wait);
+   container_of(arg, struct dmatest_thread, test_done);
if (!thread->done) {
done->done = true;
wake_up_all(done->wait);
-- 
1.8.3.1

[PATCH] dmaengine: dmatest: fix container_of member in dmatest_callback

[Yang Shunyong]

The type of arg passed to dmatest_callback is struct dmatest_done.
It refers to test_done in struct dmatest_thread, not done_wait.

Fixes: 6f6a23a213be ("dmaengine: dmatest: move callback wait ...")
Signed-off-by: Yang Shunyong 
---
 drivers/dma/dmatest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c
index ec5f9d2bc820..906e85d6dedc 100644
--- a/drivers/dma/dmatest.c
+++ b/drivers/dma/dmatest.c
@@ -355,7 +355,7 @@ static void dmatest_callback(void *arg)
 {
struct dmatest_done *done = arg;
struct dmatest_thread *thread =
-   container_of(arg, struct dmatest_thread, done_wait);
+   container_of(arg, struct dmatest_thread, test_done);
if (!thread->done) {
done->done = true;
wake_up_all(done->wait);
-- 
1.8.3.1

Re: [PATCH] PCI: altera: Fix bool initialization in tlp_read_packet

[Ley Foon Tan]

On Fri, 2018-01-19 at 21:26 -0600, Gustavo A. R. Silva wrote:
> Bool initializations should use true and false.
> 
> This issue was detected with the help of Coccinelle.
> 
> Fixes: eaa6111b70a7 ("PCI: altera: Add Altera PCIe host controller
> driver")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/pci/host/pcie-altera.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-
> altera.c
> index 5cc4f59..f9ee090 100644
> --- a/drivers/pci/host/pcie-altera.c
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -156,7 +156,7 @@ static bool altera_pcie_valid_device(struct
> altera_pcie *pcie,
>  static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
>  {
> int i;
> -   bool sop = 0;
> +   bool sop = false;
> u32 ctrl;
> u32 reg0, reg1;
> u32 comp_status = 1;
> --
> 2.7.4

Acked-by: Ley Foon Tan 

Re: [PATCH] PCI: altera: Fix bool initialization in tlp_read_packet

[Ley Foon Tan]

On Fri, 2018-01-19 at 21:26 -0600, Gustavo A. R. Silva wrote:
> Bool initializations should use true and false.
> 
> This issue was detected with the help of Coccinelle.
> 
> Fixes: eaa6111b70a7 ("PCI: altera: Add Altera PCIe host controller
> driver")
> Signed-off-by: Gustavo A. R. Silva 
> ---
>  drivers/pci/host/pcie-altera.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-
> altera.c
> index 5cc4f59..f9ee090 100644
> --- a/drivers/pci/host/pcie-altera.c
> +++ b/drivers/pci/host/pcie-altera.c
> @@ -156,7 +156,7 @@ static bool altera_pcie_valid_device(struct
> altera_pcie *pcie,
>  static int tlp_read_packet(struct altera_pcie *pcie, u32 *value)
>  {
> int i;
> -   bool sop = 0;
> +   bool sop = false;
> u32 ctrl;
> u32 reg0, reg1;
> u32 comp_status = 1;
> --
> 2.7.4

Acked-by: Ley Foon Tan 

Re: [PATCH] mmc: davinci: suppress error message on EPROBE_DEFER

[Ulf Hansson]

On 21 January 2018 at 21:28, David Lechner  wrote:
> This suppresses printing an error message during probe of the TI DaVinci
> MMC driver when the error is EPROBE_DEFER.
>
> Cc: Ulf Hansson 
> Signed-off-by: David Lechner 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/davinci_mmc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
> index c5309cc..8e36317 100644
> --- a/drivers/mmc/host/davinci_mmc.c
> +++ b/drivers/mmc/host/davinci_mmc.c
> @@ -1253,8 +1253,9 @@ static int davinci_mmcsd_probe(struct platform_device 
> *pdev)
> pdev->id_entry = match->data;
> ret = mmc_of_parse(mmc);
> if (ret) {
> -   dev_err(>dev,
> -   "could not parse of data: %d\n", ret);
> +   if (ret != -EPROBE_DEFER)
> +   dev_err(>dev,
> +   "could not parse of data: %d\n", ret);
> goto parse_fail;
> }
> } else {
> --
> 2.7.4
>

Re: [PATCH] mmc: davinci: suppress error message on EPROBE_DEFER

[Ulf Hansson]

On 21 January 2018 at 21:28, David Lechner  wrote:
> This suppresses printing an error message during probe of the TI DaVinci
> MMC driver when the error is EPROBE_DEFER.
>
> Cc: Ulf Hansson 
> Signed-off-by: David Lechner 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/davinci_mmc.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
> index c5309cc..8e36317 100644
> --- a/drivers/mmc/host/davinci_mmc.c
> +++ b/drivers/mmc/host/davinci_mmc.c
> @@ -1253,8 +1253,9 @@ static int davinci_mmcsd_probe(struct platform_device 
> *pdev)
> pdev->id_entry = match->data;
> ret = mmc_of_parse(mmc);
> if (ret) {
> -   dev_err(>dev,
> -   "could not parse of data: %d\n", ret);
> +   if (ret != -EPROBE_DEFER)
> +   dev_err(>dev,
> +   "could not parse of data: %d\n", ret);
> goto parse_fail;
> }
> } else {
> --
> 2.7.4
>

Re: [PATCH] mmc: davinci: dont' use module_platform_driver_probe()

[Ulf Hansson]

On 21 January 2018 at 21:09, David Lechner  wrote:
> This changes module_platform_driver_probe() to module_platform_driver()
> in the TI DaVinci MMC driver.
>
> On device tree systems, we can get a -EPROBE_DEFER when using a pinmux
> for the CD GPIO, which results in the driver never loading because
> module_platform_driver_probe() prevents it from being re-probed.
>
> So, we replace module_platform_driver_probe() with
> module_platform_driver() and removed the __init attributes accordingly.
>
> Cc: Ulf Hansson 
> Signed-off-by: David Lechner 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/davinci_mmc.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
> index 351330d..c5309cc 100644
> --- a/drivers/mmc/host/davinci_mmc.c
> +++ b/drivers/mmc/host/davinci_mmc.c
> @@ -174,7 +174,7 @@ module_param(poll_loopcount, uint, S_IRUGO);
>  MODULE_PARM_DESC(poll_loopcount,
>  "Maximum polling loop count. Default = 32");
>
> -static unsigned __initdata use_dma = 1;
> +static unsigned use_dma = 1;
>  module_param(use_dma, uint, 0);
>  MODULE_PARM_DESC(use_dma, "Whether to use DMA or not. Default = 1");
>
> @@ -496,8 +496,7 @@ static int mmc_davinci_start_dma_transfer(struct 
> mmc_davinci_host *host,
> return ret;
>  }
>
> -static void __init_or_module
> -davinci_release_dma_channels(struct mmc_davinci_host *host)
> +static void davinci_release_dma_channels(struct mmc_davinci_host *host)
>  {
> if (!host->use_dma)
> return;
> @@ -506,7 +505,7 @@ davinci_release_dma_channels(struct mmc_davinci_host 
> *host)
> dma_release_channel(host->dma_rx);
>  }
>
> -static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host)
> +static int davinci_acquire_dma_channels(struct mmc_davinci_host *host)
>  {
> host->dma_tx = dma_request_chan(mmc_dev(host->mmc), "tx");
> if (IS_ERR(host->dma_tx)) {
> @@ -1201,7 +1200,7 @@ static int mmc_davinci_parse_pdata(struct mmc_host *mmc)
> return 0;
>  }
>
> -static int __init davinci_mmcsd_probe(struct platform_device *pdev)
> +static int davinci_mmcsd_probe(struct platform_device *pdev)
>  {
> const struct of_device_id *match;
> struct mmc_davinci_host *host = NULL;
> @@ -1414,11 +1413,12 @@ static struct platform_driver davinci_mmcsd_driver = {
> .pm = davinci_mmcsd_pm_ops,
> .of_match_table = davinci_mmc_dt_ids,
> },
> +   .probe  = davinci_mmcsd_probe,
> .remove = __exit_p(davinci_mmcsd_remove),
> .id_table   = davinci_mmc_devtype,
>  };
>
> -module_platform_driver_probe(davinci_mmcsd_driver, davinci_mmcsd_probe);
> +module_platform_driver(davinci_mmcsd_driver);
>
>  MODULE_AUTHOR("Texas Instruments India");
>  MODULE_LICENSE("GPL");
> --
> 2.7.4
>

Re: [PATCH] mmc: davinci: dont' use module_platform_driver_probe()

[Ulf Hansson]

On 21 January 2018 at 21:09, David Lechner  wrote:
> This changes module_platform_driver_probe() to module_platform_driver()
> in the TI DaVinci MMC driver.
>
> On device tree systems, we can get a -EPROBE_DEFER when using a pinmux
> for the CD GPIO, which results in the driver never loading because
> module_platform_driver_probe() prevents it from being re-probed.
>
> So, we replace module_platform_driver_probe() with
> module_platform_driver() and removed the __init attributes accordingly.
>
> Cc: Ulf Hansson 
> Signed-off-by: David Lechner 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/davinci_mmc.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
> index 351330d..c5309cc 100644
> --- a/drivers/mmc/host/davinci_mmc.c
> +++ b/drivers/mmc/host/davinci_mmc.c
> @@ -174,7 +174,7 @@ module_param(poll_loopcount, uint, S_IRUGO);
>  MODULE_PARM_DESC(poll_loopcount,
>  "Maximum polling loop count. Default = 32");
>
> -static unsigned __initdata use_dma = 1;
> +static unsigned use_dma = 1;
>  module_param(use_dma, uint, 0);
>  MODULE_PARM_DESC(use_dma, "Whether to use DMA or not. Default = 1");
>
> @@ -496,8 +496,7 @@ static int mmc_davinci_start_dma_transfer(struct 
> mmc_davinci_host *host,
> return ret;
>  }
>
> -static void __init_or_module
> -davinci_release_dma_channels(struct mmc_davinci_host *host)
> +static void davinci_release_dma_channels(struct mmc_davinci_host *host)
>  {
> if (!host->use_dma)
> return;
> @@ -506,7 +505,7 @@ davinci_release_dma_channels(struct mmc_davinci_host 
> *host)
> dma_release_channel(host->dma_rx);
>  }
>
> -static int __init davinci_acquire_dma_channels(struct mmc_davinci_host *host)
> +static int davinci_acquire_dma_channels(struct mmc_davinci_host *host)
>  {
> host->dma_tx = dma_request_chan(mmc_dev(host->mmc), "tx");
> if (IS_ERR(host->dma_tx)) {
> @@ -1201,7 +1200,7 @@ static int mmc_davinci_parse_pdata(struct mmc_host *mmc)
> return 0;
>  }
>
> -static int __init davinci_mmcsd_probe(struct platform_device *pdev)
> +static int davinci_mmcsd_probe(struct platform_device *pdev)
>  {
> const struct of_device_id *match;
> struct mmc_davinci_host *host = NULL;
> @@ -1414,11 +1413,12 @@ static struct platform_driver davinci_mmcsd_driver = {
> .pm = davinci_mmcsd_pm_ops,
> .of_match_table = davinci_mmc_dt_ids,
> },
> +   .probe  = davinci_mmcsd_probe,
> .remove = __exit_p(davinci_mmcsd_remove),
> .id_table   = davinci_mmc_devtype,
>  };
>
> -module_platform_driver_probe(davinci_mmcsd_driver, davinci_mmcsd_probe);
> +module_platform_driver(davinci_mmcsd_driver);
>
>  MODULE_AUTHOR("Texas Instruments India");
>  MODULE_LICENSE("GPL");
> --
> 2.7.4
>

Re: [PATCH] mmc: tmio: hide unused tmio_mmc_clk_disable/tmio_mmc_clk_enable functions

[Ulf Hansson]

On 19 January 2018 at 15:54, Arnd Bergmann  wrote:
> When CONFIG_PM is disabled, we get a warning about the clock handling
> being unused:
>
> drivers/mmc/host/tmio_mmc_core.c:937:13: error: 'tmio_mmc_clk_disable' 
> defined but not used [-Werror=unused-function]
>  static void tmio_mmc_clk_disable(struct tmio_mmc_host *host)
>  ^~~~
> drivers/mmc/host/tmio_mmc_core.c:929:12: error: 'tmio_mmc_clk_enable' defined 
> but not used [-Werror=unused-function]
>  static int tmio_mmc_clk_enable(struct tmio_mmc_host *host)
> ^~~
>
> As the clock handling is now done elsewhere, this is only used when
> power management is enabled. We could make the functions as __maybe_unused,
> but since there is already an #ifdef section, it seems easier to move
> the helpers closer to their callers.
>
> Fixes: b21fc294387e ("mmc: tmio: move clk_enable/disable out of 
> tmio_mmc_host_probe()")
> Signed-off-by: Arnd Bergmann 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/tmio_mmc_core.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_core.c 
> b/drivers/mmc/host/tmio_mmc_core.c
> index 6d8719be75a8..33494241245a 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -926,20 +926,6 @@ static void tmio_mmc_done_work(struct work_struct *work)
> tmio_mmc_finish_request(host);
>  }
>
> -static int tmio_mmc_clk_enable(struct tmio_mmc_host *host)
> -{
> -   if (!host->clk_enable)
> -   return -ENOTSUPP;
> -
> -   return host->clk_enable(host);
> -}
> -
> -static void tmio_mmc_clk_disable(struct tmio_mmc_host *host)
> -{
> -   if (host->clk_disable)
> -   host->clk_disable(host);
> -}
> -
>  static void tmio_mmc_power_on(struct tmio_mmc_host *host, unsigned short vdd)
>  {
> struct mmc_host *mmc = host->mmc;
> @@ -1337,6 +1323,20 @@ void tmio_mmc_host_remove(struct tmio_mmc_host *host)
>  EXPORT_SYMBOL_GPL(tmio_mmc_host_remove);
>
>  #ifdef CONFIG_PM
> +static int tmio_mmc_clk_enable(struct tmio_mmc_host *host)
> +{
> +   if (!host->clk_enable)
> +   return -ENOTSUPP;
> +
> +   return host->clk_enable(host);
> +}
> +
> +static void tmio_mmc_clk_disable(struct tmio_mmc_host *host)
> +{
> +   if (host->clk_disable)
> +   host->clk_disable(host);
> +}
> +
>  int tmio_mmc_host_runtime_suspend(struct device *dev)
>  {
> struct tmio_mmc_host *host = dev_get_drvdata(dev);
> --
> 2.9.0
>

Re: [PATCH] mmc: tmio: hide unused tmio_mmc_clk_disable/tmio_mmc_clk_enable functions

[Ulf Hansson]

On 19 January 2018 at 15:54, Arnd Bergmann  wrote:
> When CONFIG_PM is disabled, we get a warning about the clock handling
> being unused:
>
> drivers/mmc/host/tmio_mmc_core.c:937:13: error: 'tmio_mmc_clk_disable' 
> defined but not used [-Werror=unused-function]
>  static void tmio_mmc_clk_disable(struct tmio_mmc_host *host)
>  ^~~~
> drivers/mmc/host/tmio_mmc_core.c:929:12: error: 'tmio_mmc_clk_enable' defined 
> but not used [-Werror=unused-function]
>  static int tmio_mmc_clk_enable(struct tmio_mmc_host *host)
> ^~~
>
> As the clock handling is now done elsewhere, this is only used when
> power management is enabled. We could make the functions as __maybe_unused,
> but since there is already an #ifdef section, it seems easier to move
> the helpers closer to their callers.
>
> Fixes: b21fc294387e ("mmc: tmio: move clk_enable/disable out of 
> tmio_mmc_host_probe()")
> Signed-off-by: Arnd Bergmann 

Thanks, applied for next!

Kind regards
Uffe

> ---
>  drivers/mmc/host/tmio_mmc_core.c | 28 ++--
>  1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mmc/host/tmio_mmc_core.c 
> b/drivers/mmc/host/tmio_mmc_core.c
> index 6d8719be75a8..33494241245a 100644
> --- a/drivers/mmc/host/tmio_mmc_core.c
> +++ b/drivers/mmc/host/tmio_mmc_core.c
> @@ -926,20 +926,6 @@ static void tmio_mmc_done_work(struct work_struct *work)
> tmio_mmc_finish_request(host);
>  }
>
> -static int tmio_mmc_clk_enable(struct tmio_mmc_host *host)
> -{
> -   if (!host->clk_enable)
> -   return -ENOTSUPP;
> -
> -   return host->clk_enable(host);
> -}
> -
> -static void tmio_mmc_clk_disable(struct tmio_mmc_host *host)
> -{
> -   if (host->clk_disable)
> -   host->clk_disable(host);
> -}
> -
>  static void tmio_mmc_power_on(struct tmio_mmc_host *host, unsigned short vdd)
>  {
> struct mmc_host *mmc = host->mmc;
> @@ -1337,6 +1323,20 @@ void tmio_mmc_host_remove(struct tmio_mmc_host *host)
>  EXPORT_SYMBOL_GPL(tmio_mmc_host_remove);
>
>  #ifdef CONFIG_PM
> +static int tmio_mmc_clk_enable(struct tmio_mmc_host *host)
> +{
> +   if (!host->clk_enable)
> +   return -ENOTSUPP;
> +
> +   return host->clk_enable(host);
> +}
> +
> +static void tmio_mmc_clk_disable(struct tmio_mmc_host *host)
> +{
> +   if (host->clk_disable)
> +   host->clk_disable(host);
> +}
> +
>  int tmio_mmc_host_runtime_suspend(struct device *dev)
>  {
> struct tmio_mmc_host *host = dev_get_drvdata(dev);
> --
> 2.9.0
>

Re: Re: ACPI: sbshc: remove raw pointer from printk message

[Greg Kroah-Hartman]

On Mon, Jan 22, 2018 at 11:19:36AM +0800, wang_q...@venustech.com.cn wrote:
> 
>  I has recvied a cve-id from mitre.org for this security bug .
> should this cve-id( CVE-2018-5750) be mentioned in kernel change log?

Only if Rafael wants to hand-edit the patch, it's not really needed for
a kernel log commit message to have CVE items in it, especially as the
id was received after the patch was created and submitted.

thanks,

greg k-h

Re: Re: ACPI: sbshc: remove raw pointer from printk message

[Greg Kroah-Hartman]

On Mon, Jan 22, 2018 at 11:19:36AM +0800, wang_q...@venustech.com.cn wrote:
> 
>  I has recvied a cve-id from mitre.org for this security bug .
> should this cve-id( CVE-2018-5750) be mentioned in kernel change log?

Only if Rafael wants to hand-edit the patch, it's not really needed for
a kernel log commit message to have CVE items in it, especially as the
id was received after the patch was created and submitted.

thanks,

greg k-h

Re: [PATCH][next] staging: ccree: fix memory leaks in cc_ivgen_init

[Gilad Ben-Yossef]

On Fri, Jan 12, 2018 at 6:10 PM, Colin King  wrote:
> From: Colin Ian King 
>
> The current error exit path in function cc_ivgen_init via label
> 'out' free's resources from the drvdata->ivgen_handle context.
> However, drvdata->ivgen_handle has not been assigned to the
> context ivgen_ctx at this point, so the resources are not freed.
> Fix this by setting drvdata->ivgen_handle to ivgen_ctx as early
> as possible so that the clean up error exit return path can free
> the resources.
>
> Detected by CoveritScan, CID#1463795 ("Resource leak")
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/ccree/cc_ivgen.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/ccree/cc_ivgen.c 
> b/drivers/staging/ccree/cc_ivgen.c
> index 25a3131a93ce..c47f419b277b 100644
> --- a/drivers/staging/ccree/cc_ivgen.c
> +++ b/drivers/staging/ccree/cc_ivgen.c
> @@ -178,6 +178,8 @@ int cc_ivgen_init(struct cc_drvdata *drvdata)
> if (!ivgen_ctx)
> return -ENOMEM;
>
> +   drvdata->ivgen_handle = ivgen_ctx;
> +
> /* Allocate pool's header for initial enc. key/IV */
> ivgen_ctx->pool_meta = dma_alloc_coherent(device, CC_IVPOOL_META_SIZE,
>   _ctx->pool_meta_dma,
> @@ -196,8 +198,6 @@ int cc_ivgen_init(struct cc_drvdata *drvdata)
> goto out;
> }
>
> -   drvdata->ivgen_handle = ivgen_ctx;
> -
> return cc_init_iv_sram(drvdata);
>
>  out:
> --
> 2.15.1
>

Good catch!

Acked-by: Gilad Ben-Yossef 

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH][next] staging: ccree: fix memory leaks in cc_ivgen_init

[Gilad Ben-Yossef]

On Fri, Jan 12, 2018 at 6:10 PM, Colin King  wrote:
> From: Colin Ian King 
>
> The current error exit path in function cc_ivgen_init via label
> 'out' free's resources from the drvdata->ivgen_handle context.
> However, drvdata->ivgen_handle has not been assigned to the
> context ivgen_ctx at this point, so the resources are not freed.
> Fix this by setting drvdata->ivgen_handle to ivgen_ctx as early
> as possible so that the clean up error exit return path can free
> the resources.
>
> Detected by CoveritScan, CID#1463795 ("Resource leak")
>
> Signed-off-by: Colin Ian King 
> ---
>  drivers/staging/ccree/cc_ivgen.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/ccree/cc_ivgen.c 
> b/drivers/staging/ccree/cc_ivgen.c
> index 25a3131a93ce..c47f419b277b 100644
> --- a/drivers/staging/ccree/cc_ivgen.c
> +++ b/drivers/staging/ccree/cc_ivgen.c
> @@ -178,6 +178,8 @@ int cc_ivgen_init(struct cc_drvdata *drvdata)
> if (!ivgen_ctx)
> return -ENOMEM;
>
> +   drvdata->ivgen_handle = ivgen_ctx;
> +
> /* Allocate pool's header for initial enc. key/IV */
> ivgen_ctx->pool_meta = dma_alloc_coherent(device, CC_IVPOOL_META_SIZE,
>   _ctx->pool_meta_dma,
> @@ -196,8 +198,6 @@ int cc_ivgen_init(struct cc_drvdata *drvdata)
> goto out;
> }
>
> -   drvdata->ivgen_handle = ivgen_ctx;
> -
> return cc_init_iv_sram(drvdata);
>
>  out:
> --
> 2.15.1
>

Good catch!

Acked-by: Gilad Ben-Yossef 

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

[RFC PATCH net-next] net: aquantia: aq_fw2x_get_mac_permanent() can be static

[kbuild test robot]

Fixes: a57d3929b838 ("net: aquantia: Introduce support for new firmware on AQC 
cards")
Signed-off-by: Fengguang Wu 
---
 hw_atl_utils_fw2x.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
index 8cfce95..39cd3a2 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
@@ -107,7 +107,7 @@ static int aq_fw2x_update_link_status(struct aq_hw_s *self)
return 0;
 }
 
-int aq_fw2x_get_mac_permanent(struct aq_hw_s *self, u8 *mac)
+static int aq_fw2x_get_mac_permanent(struct aq_hw_s *self, u8 *mac)
 {
int err = 0;
u32 h = 0U;

[RFC PATCH net-next] net: aquantia: aq_fw2x_get_mac_permanent() can be static

[kbuild test robot]

Fixes: a57d3929b838 ("net: aquantia: Introduce support for new firmware on AQC 
cards")
Signed-off-by: Fengguang Wu 
---
 hw_atl_utils_fw2x.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
index 8cfce95..39cd3a2 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils_fw2x.c
@@ -107,7 +107,7 @@ static int aq_fw2x_update_link_status(struct aq_hw_s *self)
return 0;
 }
 
-int aq_fw2x_get_mac_permanent(struct aq_hw_s *self, u8 *mac)
+static int aq_fw2x_get_mac_permanent(struct aq_hw_s *self, u8 *mac)
 {
int err = 0;
u32 h = 0U;

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

[Benjamin Poirier]

On 2018/01/20 09:21, Alexander Duyck wrote:
> On Fri, Jan 19, 2018 at 2:55 PM, Benjamin Poirier
>  wrote:
> > On 2018/01/20 07:45, Benjamin Poirier wrote:
> > [...]
> >> >
> >> > I'm of the mind that we need to cut down on the code thrash.  This
> >> > driver is supposed to have been in a "maintenance" mode for the last
> >> > year or so as there aren't being any new parts added is my
> >> > understanding. As-is I don't see any reason why 16ecba59bc33 ("e1000e:
> >> > Do not read ICR in Other interrupt", v4.5-rc1) was submitted or
> >> > accepted in the first place. I don't see any notes about it fixing any
> >> > bug or addressing any issue and it seems like that is the start of all
> >> > the issues we have been having recently with RXO triggering more
> >> > interrupts, various link issues, and this most recent VMware issue.
> >>
> >> I'm sorry to say but you're the one who suggested that change:
> >>
> >> http://lkml.iu.edu/hypermail/linux/kernel/1510.3/03528.html
> >>
> >> On 2015/10/28 23:08, Alexander Duyck wrote:
> >> > On 10/22/2015 05:32 PM, Benjamin Poirier wrote:
> >> [...]
> >> >
> >> > I would argue your first patch probably didn't go far enough to remove 
> >> > dead
> >> > code.  Specifically you should only ever get into this function if LSC is
> >> > set.  There are no other causes that should trigger this.  As such you 
> >> > could
> >> > probably remove the ICR read, and instead replace it with an ICR write of
> >> > the LSC bit since OTHER is already cleared via EIAC.
> >> >
> >
> > ... The assumption that "There are no other causes that should trigger
> > this." turned out to be wrong and that caused the RXO problems. Clearing
> > OTHER via EIAC is causing the problems with vmware now. I don't think
> > you foresaw those problems back in 2015 and neither did I.
> 
> Well that explains why I felt like I was explaining things to a
> younger version of myself. I was a bit more relaxed in terms of being
> willing to make arbitrary changes a few years ago. I tend to be a bit
> more conservative now, at least as far as having justifications as to
> why I want to do things. With any change you end up taking on risk,
> and so usually a patch has a justification as to why you are making
> the change.
> 
> Unfortunately at the time I didn't have all the information and based
> my suggestion on a bad assumption. I would guess at the time I was
> thinking of doing general code cleanup. Other drivers such as igb work
> this way, but it led us down the path we are on now where we are
> having to make one fix after another. It is leading in the opposite
> direction of maintainability as this is all becoming more complex.
> Suggesting this was a bad decision on my part at the time. I'm only
> human, I make mistakes.. :-)

Thanks for the introspection.

> 
> With further review of the code I am seeing various other issues that
> could still pop up as I am not certain we should even have the "other"
> interrupt messing with the NAPI polling or packet accounting logic at
> all. The question I would have at this point is if we revert
> 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1)
> and all the related fixes for it, what do we end up with?

The patch I submitted for the current vmware issue actually finishes
reverting commit 16ecba59bc33.

I believe the relevant commits to consider are:

16ecba59bc33 e1000e: Do not read ICR in Other interrupt (v4.5-rc1)
a61cfe4ffad7 e1000e: Do not write lsc to ics in msi-x mode (v4.5-rc1)
0a8047ac68e5 e1000e: Fix msi-x interrupt automask (v4.5-rc1)

19110cfbb34d e1000e: Separate signaling for link check/link up
 (v4.15-rc1)
4aea7a5c5e94 e1000e: Avoid receiver overrun interrupt bursts (v4.15-rc1)

4110e02eb45e e1000e: Fix e1000_check_for_copper_link_ich8lan return
 value. (v4.15-rc8)

(submitted)  e1000e: Remove Other from EIAC.

commit 4aea7a5c5e94 essentially reverts a61cfe4ffad7 and part of
16ecba59bc33 (ICR read). The submitted patch reverts the rest of
16ecba59bc33 (EIAC clearing of Other).

> It seems
> like the code is slowly heading back in the direction of where it was
> originally anyway since there have been a number of partial reverts.
> I'm wondering what would happen if we were to just short-cut that and
> audit the patches involved to see what we really need and don't.
> 
> Your patch as proposed is essentially another step in that direction.
> I'm thinking we may want to drop my currently proposed fix for now and
> instead look at going through and figure out what changes after that
> first one are still really needed.

If the patch that I submitted for the current vmware issue is merged,
the significant commits that are left are:

0a8047ac68e5 e1000e: Fix msi-x interrupt automask (v4.5-rc1)
Fixes a problem in the irq disabling of the napi implementation.

19110cfbb34d e1000e: Separate signaling for link check/link up
 (v4.15-rc1)
Fixes link flapping 

Re: [Intel-wired-lan] [RFC PATCH] e1000e: Remove Other from EIAC.

[Benjamin Poirier]

On 2018/01/20 09:21, Alexander Duyck wrote:
> On Fri, Jan 19, 2018 at 2:55 PM, Benjamin Poirier
>  wrote:
> > On 2018/01/20 07:45, Benjamin Poirier wrote:
> > [...]
> >> >
> >> > I'm of the mind that we need to cut down on the code thrash.  This
> >> > driver is supposed to have been in a "maintenance" mode for the last
> >> > year or so as there aren't being any new parts added is my
> >> > understanding. As-is I don't see any reason why 16ecba59bc33 ("e1000e:
> >> > Do not read ICR in Other interrupt", v4.5-rc1) was submitted or
> >> > accepted in the first place. I don't see any notes about it fixing any
> >> > bug or addressing any issue and it seems like that is the start of all
> >> > the issues we have been having recently with RXO triggering more
> >> > interrupts, various link issues, and this most recent VMware issue.
> >>
> >> I'm sorry to say but you're the one who suggested that change:
> >>
> >> http://lkml.iu.edu/hypermail/linux/kernel/1510.3/03528.html
> >>
> >> On 2015/10/28 23:08, Alexander Duyck wrote:
> >> > On 10/22/2015 05:32 PM, Benjamin Poirier wrote:
> >> [...]
> >> >
> >> > I would argue your first patch probably didn't go far enough to remove 
> >> > dead
> >> > code.  Specifically you should only ever get into this function if LSC is
> >> > set.  There are no other causes that should trigger this.  As such you 
> >> > could
> >> > probably remove the ICR read, and instead replace it with an ICR write of
> >> > the LSC bit since OTHER is already cleared via EIAC.
> >> >
> >
> > ... The assumption that "There are no other causes that should trigger
> > this." turned out to be wrong and that caused the RXO problems. Clearing
> > OTHER via EIAC is causing the problems with vmware now. I don't think
> > you foresaw those problems back in 2015 and neither did I.
> 
> Well that explains why I felt like I was explaining things to a
> younger version of myself. I was a bit more relaxed in terms of being
> willing to make arbitrary changes a few years ago. I tend to be a bit
> more conservative now, at least as far as having justifications as to
> why I want to do things. With any change you end up taking on risk,
> and so usually a patch has a justification as to why you are making
> the change.
> 
> Unfortunately at the time I didn't have all the information and based
> my suggestion on a bad assumption. I would guess at the time I was
> thinking of doing general code cleanup. Other drivers such as igb work
> this way, but it led us down the path we are on now where we are
> having to make one fix after another. It is leading in the opposite
> direction of maintainability as this is all becoming more complex.
> Suggesting this was a bad decision on my part at the time. I'm only
> human, I make mistakes.. :-)

Thanks for the introspection.

> 
> With further review of the code I am seeing various other issues that
> could still pop up as I am not certain we should even have the "other"
> interrupt messing with the NAPI polling or packet accounting logic at
> all. The question I would have at this point is if we revert
> 16ecba59bc33 ("e1000e: Do not read ICR in Other interrupt", v4.5-rc1)
> and all the related fixes for it, what do we end up with?

The patch I submitted for the current vmware issue actually finishes
reverting commit 16ecba59bc33.

I believe the relevant commits to consider are:

16ecba59bc33 e1000e: Do not read ICR in Other interrupt (v4.5-rc1)
a61cfe4ffad7 e1000e: Do not write lsc to ics in msi-x mode (v4.5-rc1)
0a8047ac68e5 e1000e: Fix msi-x interrupt automask (v4.5-rc1)

19110cfbb34d e1000e: Separate signaling for link check/link up
 (v4.15-rc1)
4aea7a5c5e94 e1000e: Avoid receiver overrun interrupt bursts (v4.15-rc1)

4110e02eb45e e1000e: Fix e1000_check_for_copper_link_ich8lan return
 value. (v4.15-rc8)

(submitted)  e1000e: Remove Other from EIAC.

commit 4aea7a5c5e94 essentially reverts a61cfe4ffad7 and part of
16ecba59bc33 (ICR read). The submitted patch reverts the rest of
16ecba59bc33 (EIAC clearing of Other).

> It seems
> like the code is slowly heading back in the direction of where it was
> originally anyway since there have been a number of partial reverts.
> I'm wondering what would happen if we were to just short-cut that and
> audit the patches involved to see what we really need and don't.
> 
> Your patch as proposed is essentially another step in that direction.
> I'm thinking we may want to drop my currently proposed fix for now and
> instead look at going through and figure out what changes after that
> first one are still really needed.

If the patch that I submitted for the current vmware issue is merged,
the significant commits that are left are:

0a8047ac68e5 e1000e: Fix msi-x interrupt automask (v4.5-rc1)
Fixes a problem in the irq disabling of the napi implementation.

19110cfbb34d e1000e: Separate signaling for link check/link up
 (v4.15-rc1)
Fixes link flapping caused by a race condition in 

[PATCH] clk: qcom: Add Global Clock controller (GCC) driver for SDM845

[Amit Nischal]

Add support for the global clock controller found on SDM845
based devices. This should allow most non-multimedia device
drivers to probe and control their clocks.

Signed-off-by: Taniya Das 
Signed-off-by: Amit Nischal 
---

This patch is dependent on below changes:
1. https://patchwork.kernel.org/patch/10139991/
2. https://patchwork.kernel.org/patch/10139987/
3. https://patchwork.kernel.org/patch/10144621/

 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 drivers/clk/qcom/Kconfig   |9 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/gcc-sdm845.c  | 3642 
 include/dt-bindings/clock/qcom,gcc-sdm845.h|  251 ++
 5 files changed, 3904 insertions(+)
 create mode 100644 drivers/clk/qcom/gcc-sdm845.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm845.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 551d03b..bf2355d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -18,6 +18,7 @@ Required properties :
"qcom,gcc-msm8994"
"qcom,gcc-msm8996"
"qcom,gcc-mdm9615"
+   "qcom,gcc-sdm845"

 - reg : shall contain base register location and length
 - #clock-cells : shall contain 1
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index fbf4532..91e4557 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -226,3 +226,12 @@ config SPMI_PMIC_CLKDIV
  Technologies, Inc. SPMI PMIC. It configures the frequency of
  clkdiv outputs of the PMIC. These clocks are typically wired
  through alternate functions on GPIO pins.
+
+config SDM_GCC_845
+   tristate "SDM845 Global Clock Controller"
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the global clock controller on Qualcomm Technologies, Inc
+ sdm845 devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ i2c, USB, UFS, SD/eMMC, PCIe, etc.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 230332c..1aa23b3 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_MSM_GCC_8960) += gcc-msm8960.o
 obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
 obj-$(CONFIG_MSM_GCC_8994) += gcc-msm8994.o
 obj-$(CONFIG_MSM_GCC_8996) += gcc-msm8996.o
+obj-$(CONFIG_SDM_GCC_845)  += gcc-sdm845.o
 obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
new file mode 100644
index 000..2981357
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -0,0 +1,3642 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "clk-alpha-pll.h"
+#include "gdsc.h"
+#include "reset.h"
+
+#define GCC_MMSS_MISC  0x09FFC
+#define GCC_GPU_MISC   0x71028
+
+#define CXO_FREQUENCY  1920
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+static struct freq_tbl cxo_safe_src_f = {
+   .freq = CXO_FREQUENCY,
+   .src = 0,
+   .pre_div = 1,
+   .m = 0,
+   .n = 0,
+};
+
+enum {
+   P_BI_TCXO,
+   P_AUD_REF_CLK,
+   P_CORE_BI_PLL_TEST_SE,
+   P_GPLL0_OUT_EVEN,
+   P_GPLL0_OUT_MAIN,
+   P_GPLL4_OUT_MAIN,
+   P_SLEEP_CLK,
+};
+
+static const struct parent_map gcc_parent_map_0[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_GPLL0_OUT_EVEN, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_0[] = {
+   "bi_tcxo",
+   "gpll0",
+   "gpll0_out_even",
+   "core_bi_pll_test_se",
+};
+
+static const struct parent_map gcc_parent_map_1[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_SLEEP_CLK, 5 },
+   { P_GPLL0_OUT_EVEN, 6 },
+   { 

[PATCH] clk: qcom: Add Global Clock controller (GCC) driver for SDM845

[Amit Nischal]

Add support for the global clock controller found on SDM845
based devices. This should allow most non-multimedia device
drivers to probe and control their clocks.

Signed-off-by: Taniya Das 
Signed-off-by: Amit Nischal 
---

This patch is dependent on below changes:
1. https://patchwork.kernel.org/patch/10139991/
2. https://patchwork.kernel.org/patch/10139987/
3. https://patchwork.kernel.org/patch/10144621/

 .../devicetree/bindings/clock/qcom,gcc.txt |1 +
 drivers/clk/qcom/Kconfig   |9 +
 drivers/clk/qcom/Makefile  |1 +
 drivers/clk/qcom/gcc-sdm845.c  | 3642 
 include/dt-bindings/clock/qcom,gcc-sdm845.h|  251 ++
 5 files changed, 3904 insertions(+)
 create mode 100644 drivers/clk/qcom/gcc-sdm845.c
 create mode 100644 include/dt-bindings/clock/qcom,gcc-sdm845.h

diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt 
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 551d03b..bf2355d 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -18,6 +18,7 @@ Required properties :
"qcom,gcc-msm8994"
"qcom,gcc-msm8996"
"qcom,gcc-mdm9615"
+   "qcom,gcc-sdm845"

 - reg : shall contain base register location and length
 - #clock-cells : shall contain 1
diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
index fbf4532..91e4557 100644
--- a/drivers/clk/qcom/Kconfig
+++ b/drivers/clk/qcom/Kconfig
@@ -226,3 +226,12 @@ config SPMI_PMIC_CLKDIV
  Technologies, Inc. SPMI PMIC. It configures the frequency of
  clkdiv outputs of the PMIC. These clocks are typically wired
  through alternate functions on GPIO pins.
+
+config SDM_GCC_845
+   tristate "SDM845 Global Clock Controller"
+   depends on COMMON_CLK_QCOM
+   help
+ Support for the global clock controller on Qualcomm Technologies, Inc
+ sdm845 devices.
+ Say Y if you want to use peripheral devices such as UART, SPI,
+ i2c, USB, UFS, SD/eMMC, PCIe, etc.
diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index 230332c..1aa23b3 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -29,6 +29,7 @@ obj-$(CONFIG_MSM_GCC_8960) += gcc-msm8960.o
 obj-$(CONFIG_MSM_GCC_8974) += gcc-msm8974.o
 obj-$(CONFIG_MSM_GCC_8994) += gcc-msm8994.o
 obj-$(CONFIG_MSM_GCC_8996) += gcc-msm8996.o
+obj-$(CONFIG_SDM_GCC_845)  += gcc-sdm845.o
 obj-$(CONFIG_MSM_LCC_8960) += lcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8960) += mmcc-msm8960.o
 obj-$(CONFIG_MSM_MMCC_8974) += mmcc-msm8974.o
diff --git a/drivers/clk/qcom/gcc-sdm845.c b/drivers/clk/qcom/gcc-sdm845.c
new file mode 100644
index 000..2981357
--- /dev/null
+++ b/drivers/clk/qcom/gcc-sdm845.c
@@ -0,0 +1,3642 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "clk-pll.h"
+#include "clk-rcg.h"
+#include "clk-branch.h"
+#include "clk-alpha-pll.h"
+#include "gdsc.h"
+#include "reset.h"
+
+#define GCC_MMSS_MISC  0x09FFC
+#define GCC_GPU_MISC   0x71028
+
+#define CXO_FREQUENCY  1920
+
+#define F(f, s, h, m, n) { (f), (s), (2 * (h) - 1), (m), (n) }
+
+static struct freq_tbl cxo_safe_src_f = {
+   .freq = CXO_FREQUENCY,
+   .src = 0,
+   .pre_div = 1,
+   .m = 0,
+   .n = 0,
+};
+
+enum {
+   P_BI_TCXO,
+   P_AUD_REF_CLK,
+   P_CORE_BI_PLL_TEST_SE,
+   P_GPLL0_OUT_EVEN,
+   P_GPLL0_OUT_MAIN,
+   P_GPLL4_OUT_MAIN,
+   P_SLEEP_CLK,
+};
+
+static const struct parent_map gcc_parent_map_0[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_GPLL0_OUT_EVEN, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const gcc_parent_names_0[] = {
+   "bi_tcxo",
+   "gpll0",
+   "gpll0_out_even",
+   "core_bi_pll_test_se",
+};
+
+static const struct parent_map gcc_parent_map_1[] = {
+   { P_BI_TCXO, 0 },
+   { P_GPLL0_OUT_MAIN, 1 },
+   { P_SLEEP_CLK, 5 },
+   { P_GPLL0_OUT_EVEN, 6 },
+   { P_CORE_BI_PLL_TEST_SE, 7 },
+};
+
+static const char * const 

Re: [PATCH 3/7] crypto: ccree: add ablkcipher support

[Gilad Ben-Yossef]

On Thu, Jan 11, 2018 at 12:03 PM, Stephan Mueller  wrote:
> Am Donnerstag, 11. Januar 2018, 10:17:10 CET schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> + // verify weak keys
>> + if (ctx_p->flow_mode == S_DIN_to_DES) {
>> + if (!des_ekey(tmp, key) &&
>> + (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_WEAK_KEY)) {
>> + tfm->crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
>> + dev_dbg(dev, "weak DES key");
>> + return -EINVAL;
>> + }
>> + }
>> + if (ctx_p->cipher_mode == DRV_CIPHER_XTS &&
>> + xts_check_key(tfm, key, keylen)) {
>> + dev_dbg(dev, "weak XTS key");
>> + return -EINVAL;
>> + }
>> + if (ctx_p->flow_mode == S_DIN_to_DES &&
>> + keylen == DES3_EDE_KEY_SIZE &&
>> + cc_verify_3des_keys(key, keylen)) {
>> + dev_dbg(dev, "weak 3DES key");
>> + return -EINVAL;
>> + }
>
> For the DES key, wouldn't it make sense to use __des3_ede_setkey?
>
> Note, I would plan to release a patch for review to change that function to
> disallow key1 == key2 or key1 == key3 or key2 == key3 in FIPS mode.

I took your advise and did just that in v2.

Thanks for the review!

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH 3/7] crypto: ccree: add ablkcipher support

[Gilad Ben-Yossef]

On Thu, Jan 11, 2018 at 12:03 PM, Stephan Mueller  wrote:
> Am Donnerstag, 11. Januar 2018, 10:17:10 CET schrieb Gilad Ben-Yossef:
>
> Hi Gilad,
>
>> + // verify weak keys
>> + if (ctx_p->flow_mode == S_DIN_to_DES) {
>> + if (!des_ekey(tmp, key) &&
>> + (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_WEAK_KEY)) {
>> + tfm->crt_flags |= CRYPTO_TFM_RES_WEAK_KEY;
>> + dev_dbg(dev, "weak DES key");
>> + return -EINVAL;
>> + }
>> + }
>> + if (ctx_p->cipher_mode == DRV_CIPHER_XTS &&
>> + xts_check_key(tfm, key, keylen)) {
>> + dev_dbg(dev, "weak XTS key");
>> + return -EINVAL;
>> + }
>> + if (ctx_p->flow_mode == S_DIN_to_DES &&
>> + keylen == DES3_EDE_KEY_SIZE &&
>> + cc_verify_3des_keys(key, keylen)) {
>> + dev_dbg(dev, "weak 3DES key");
>> + return -EINVAL;
>> + }
>
> For the DES key, wouldn't it make sense to use __des3_ede_setkey?
>
> Note, I would plan to release a patch for review to change that function to
> disallow key1 == key2 or key1 == key3 or key2 == key3 in FIPS mode.

I took your advise and did just that in v2.

Thanks for the review!

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH 3/7] crypto: ccree: add ablkcipher support

[Gilad Ben-Yossef]

Hi Corentin,


On Thu, Jan 11, 2018 at 12:01 PM, Corentin Labbe
 wrote:
> On Thu, Jan 11, 2018 at 09:17:10AM +, Gilad Ben-Yossef wrote:
>> Add CryptoCell ablkcipher support
>>
>
> Hello
>
> I have some minor comments:
>
> ablkcipher is deprecated, so you need to use skcipher instead.

Fixed in v2.

>
>> Signed-off-by: Gilad Ben-Yossef 
>> ---
>>  drivers/crypto/ccree/Makefile|2 +-
>>  drivers/crypto/ccree/cc_buffer_mgr.c |  125 
>>  drivers/crypto/ccree/cc_buffer_mgr.h |   10 +
>>  drivers/crypto/ccree/cc_cipher.c | 1167 
>> ++
>>  drivers/crypto/ccree/cc_cipher.h |   74 +++
>>  drivers/crypto/ccree/cc_driver.c |   11 +
>>  drivers/crypto/ccree/cc_driver.h |2 +
>>  7 files changed, 1390 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/crypto/ccree/cc_cipher.c
>>  create mode 100644 drivers/crypto/ccree/cc_cipher.h
>>
> [...]
>> +
>> +struct tdes_keys {
>> + u8  key1[DES_KEY_SIZE];
>> + u8  key2[DES_KEY_SIZE];
>> + u8  key3[DES_KEY_SIZE];
>> +};
>> +
>> +static const u8 zero_buff[] = {  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
>> +
>
> This constant is used nowhere.

Fixed in v2.

>
>> +/* The function verifies that tdes keys are not weak.*/
>> +static int cc_verify_3des_keys(const u8 *key, unsigned int keylen)
>> +{
>> + struct tdes_keys *tdes_key = (struct tdes_keys *)key;
>> +
>> + /* verify key1 != key2 and key3 != key2*/
>> + if ((memcmp((u8 *)tdes_key->key1, (u8 *)tdes_key->key2,
>> + sizeof(tdes_key->key1)) == 0) ||
>> + (memcmp((u8 *)tdes_key->key3, (u8 *)tdes_key->key2,
>> + sizeof(tdes_key->key3)) == 0)) {
>> + return -ENOEXEC;
>> + }
>> +
>> + return 0;
>> +}
>
> All driver testing 3des key also use des_ekey()

Well, the weak key test which is part of des_ekey() are not needed
AFAIK for 3des
as per RFC2451 and the HW does 3des key expansion so that function is not useful
here.

>
> [...]
>> +static void cc_cipher_complete(struct device *dev, void *cc_req, int err)
>> +{
>> + struct ablkcipher_request *areq = (struct ablkcipher_request *)cc_req;
>> + struct scatterlist *dst = areq->dst;
>> + struct scatterlist *src = areq->src;
>> + struct blkcipher_req_ctx *req_ctx = ablkcipher_request_ctx(areq);
>> + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
>> + unsigned int ivsize = crypto_ablkcipher_ivsize(tfm);
>> + struct ablkcipher_request *req = (struct ablkcipher_request *)areq;
>> +
>> + cc_unmap_blkcipher_request(dev, req_ctx, ivsize, src, dst);
>> + kfree(req_ctx->iv);
>
> kzfree for all stuff with IV/key

Fixed in v2.
>
> [...]
>> +
>> +#ifdef CRYPTO_TFM_REQ_HW_KEY
>> +
>> +static inline bool cc_is_hw_key(struct crypto_tfm *tfm)
>> +{
>> + return (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_HW_KEY);
>> +}
>> +
>> +#else
>> +
>> +struct arm_hw_key_info {
>> + int hw_key1;
>> + int hw_key2;
>> +};
>> +
>> +static inline bool cc_is_hw_key(struct crypto_tfm *tfm)
>> +{
>> + return false;
>> +}
>> +
>> +#endif /* CRYPTO_TFM_REQ_HW_KEY */
>
> I see nowhere any use/documentation of CRYPTO_TFM_REQ_HW_KEY, so a cleaning 
> could be done

You are right. It's a badly implemented stub function. I'll drop the
ifdef as it is useless right now.

Many thanks for the review!

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH 3/7] crypto: ccree: add ablkcipher support

[Gilad Ben-Yossef]

Hi Corentin,


On Thu, Jan 11, 2018 at 12:01 PM, Corentin Labbe
 wrote:
> On Thu, Jan 11, 2018 at 09:17:10AM +, Gilad Ben-Yossef wrote:
>> Add CryptoCell ablkcipher support
>>
>
> Hello
>
> I have some minor comments:
>
> ablkcipher is deprecated, so you need to use skcipher instead.

Fixed in v2.

>
>> Signed-off-by: Gilad Ben-Yossef 
>> ---
>>  drivers/crypto/ccree/Makefile|2 +-
>>  drivers/crypto/ccree/cc_buffer_mgr.c |  125 
>>  drivers/crypto/ccree/cc_buffer_mgr.h |   10 +
>>  drivers/crypto/ccree/cc_cipher.c | 1167 
>> ++
>>  drivers/crypto/ccree/cc_cipher.h |   74 +++
>>  drivers/crypto/ccree/cc_driver.c |   11 +
>>  drivers/crypto/ccree/cc_driver.h |2 +
>>  7 files changed, 1390 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/crypto/ccree/cc_cipher.c
>>  create mode 100644 drivers/crypto/ccree/cc_cipher.h
>>
> [...]
>> +
>> +struct tdes_keys {
>> + u8  key1[DES_KEY_SIZE];
>> + u8  key2[DES_KEY_SIZE];
>> + u8  key3[DES_KEY_SIZE];
>> +};
>> +
>> +static const u8 zero_buff[] = {  0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
>> + 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0};
>> +
>
> This constant is used nowhere.

Fixed in v2.

>
>> +/* The function verifies that tdes keys are not weak.*/
>> +static int cc_verify_3des_keys(const u8 *key, unsigned int keylen)
>> +{
>> + struct tdes_keys *tdes_key = (struct tdes_keys *)key;
>> +
>> + /* verify key1 != key2 and key3 != key2*/
>> + if ((memcmp((u8 *)tdes_key->key1, (u8 *)tdes_key->key2,
>> + sizeof(tdes_key->key1)) == 0) ||
>> + (memcmp((u8 *)tdes_key->key3, (u8 *)tdes_key->key2,
>> + sizeof(tdes_key->key3)) == 0)) {
>> + return -ENOEXEC;
>> + }
>> +
>> + return 0;
>> +}
>
> All driver testing 3des key also use des_ekey()

Well, the weak key test which is part of des_ekey() are not needed
AFAIK for 3des
as per RFC2451 and the HW does 3des key expansion so that function is not useful
here.

>
> [...]
>> +static void cc_cipher_complete(struct device *dev, void *cc_req, int err)
>> +{
>> + struct ablkcipher_request *areq = (struct ablkcipher_request *)cc_req;
>> + struct scatterlist *dst = areq->dst;
>> + struct scatterlist *src = areq->src;
>> + struct blkcipher_req_ctx *req_ctx = ablkcipher_request_ctx(areq);
>> + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
>> + unsigned int ivsize = crypto_ablkcipher_ivsize(tfm);
>> + struct ablkcipher_request *req = (struct ablkcipher_request *)areq;
>> +
>> + cc_unmap_blkcipher_request(dev, req_ctx, ivsize, src, dst);
>> + kfree(req_ctx->iv);
>
> kzfree for all stuff with IV/key

Fixed in v2.
>
> [...]
>> +
>> +#ifdef CRYPTO_TFM_REQ_HW_KEY
>> +
>> +static inline bool cc_is_hw_key(struct crypto_tfm *tfm)
>> +{
>> + return (crypto_tfm_get_flags(tfm) & CRYPTO_TFM_REQ_HW_KEY);
>> +}
>> +
>> +#else
>> +
>> +struct arm_hw_key_info {
>> + int hw_key1;
>> + int hw_key2;
>> +};
>> +
>> +static inline bool cc_is_hw_key(struct crypto_tfm *tfm)
>> +{
>> + return false;
>> +}
>> +
>> +#endif /* CRYPTO_TFM_REQ_HW_KEY */
>
> I see nowhere any use/documentation of CRYPTO_TFM_REQ_HW_KEY, so a cleaning 
> could be done

You are right. It's a badly implemented stub function. I'll drop the
ifdef as it is useless right now.

Many thanks for the review!

Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH 2/2] Input: sur40: Improve a size determination in sur40_probe()

[Martin Kepplinger]

On 2018-01-20 22:30, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 20 Jan 2018 22:16:14 +0100
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/sur40.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/sur40.c 
> b/drivers/input/touchscreen/sur40.c
> index c7a0a92b2044..946e1a0328b4 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -550,7 +550,7 @@ static int sur40_probe(struct usb_interface *interface,
>   return -ENODEV;
>  
>   /* Allocate memory for our device state and initialize it. */
> - sur40 = kzalloc(sizeof(struct sur40_state), GFP_KERNEL);
> + sur40 = kzalloc(sizeof(*sur40), GFP_KERNEL);
>   if (!sur40)
>   return -ENOMEM;
>  
> 

Re: [PATCH 2/2] Input: sur40: Improve a size determination in sur40_probe()

[Martin Kepplinger]

On 2018-01-20 22:30, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 20 Jan 2018 22:16:14 +0100
> 
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/sur40.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/sur40.c 
> b/drivers/input/touchscreen/sur40.c
> index c7a0a92b2044..946e1a0328b4 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -550,7 +550,7 @@ static int sur40_probe(struct usb_interface *interface,
>   return -ENODEV;
>  
>   /* Allocate memory for our device state and initialize it. */
> - sur40 = kzalloc(sizeof(struct sur40_state), GFP_KERNEL);
> + sur40 = kzalloc(sizeof(*sur40), GFP_KERNEL);
>   if (!sur40)
>   return -ENOMEM;
>  
> 

Re: [PATCH] Input: edt-ft5x06: Delete an error message for a failed memory allocation in edt_ft5x06_ts_probe()

[Martin Kepplinger]

On 2018-01-21 20:19, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sun, 21 Jan 2018 20:10:03 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/edt-ft5x06.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> b/drivers/input/touchscreen/edt-ft5x06.c
> index c53a3d7239e7..9d2799c90150 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -978,10 +978,8 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
>   dev_dbg(>dev, "probing for EDT FT5x06 I2C\n");
>  
>   tsdata = devm_kzalloc(>dev, sizeof(*tsdata), GFP_KERNEL);
> - if (!tsdata) {
> - dev_err(>dev, "failed to allocate driver data.\n");
> + if (!tsdata)
>   return -ENOMEM;
> - }
>  
>   chip_data = of_device_get_match_data(>dev);
>   if (!chip_data)
> 

Re: [PATCH] Input: edt-ft5x06: Delete an error message for a failed memory allocation in edt_ft5x06_ts_probe()

[Martin Kepplinger]

On 2018-01-21 20:19, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sun, 21 Jan 2018 20:10:03 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/edt-ft5x06.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/edt-ft5x06.c 
> b/drivers/input/touchscreen/edt-ft5x06.c
> index c53a3d7239e7..9d2799c90150 100644
> --- a/drivers/input/touchscreen/edt-ft5x06.c
> +++ b/drivers/input/touchscreen/edt-ft5x06.c
> @@ -978,10 +978,8 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
>   dev_dbg(>dev, "probing for EDT FT5x06 I2C\n");
>  
>   tsdata = devm_kzalloc(>dev, sizeof(*tsdata), GFP_KERNEL);
> - if (!tsdata) {
> - dev_err(>dev, "failed to allocate driver data.\n");
> + if (!tsdata)
>   return -ENOMEM;
> - }
>  
>   chip_data = of_device_get_match_data(>dev);
>   if (!chip_data)
> 

Re: [PATCH 1/2] Input: sur40: Delete an error message for a failed memory allocation in sur40_probe()

[Martin Kepplinger]

On 2018-01-20 22:28, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 20 Jan 2018 22:11:24 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/sur40.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/sur40.c 
> b/drivers/input/touchscreen/sur40.c
> index f16f8358c70a..c7a0a92b2044 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -591,7 +591,6 @@ static int sur40_probe(struct usb_interface *interface,
>   sur40->bulk_in_epaddr = endpoint->bEndpointAddress;
>   sur40->bulk_in_buffer = kmalloc(sur40->bulk_in_size, GFP_KERNEL);
>   if (!sur40->bulk_in_buffer) {
> - dev_err(>dev, "Unable to allocate input buffer.");
>   error = -ENOMEM;
>   goto err_free_polldev;
>   }
> 

Re: [PATCH 1/2] Input: sur40: Delete an error message for a failed memory allocation in sur40_probe()

[Martin Kepplinger]

On 2018-01-20 22:28, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Sat, 20 Jan 2018 22:11:24 +0100
> 
> Omit an extra message for a memory allocation failure in this function.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Acked-by: Martin Kepplinger 

> ---
>  drivers/input/touchscreen/sur40.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/input/touchscreen/sur40.c 
> b/drivers/input/touchscreen/sur40.c
> index f16f8358c70a..c7a0a92b2044 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -591,7 +591,6 @@ static int sur40_probe(struct usb_interface *interface,
>   sur40->bulk_in_epaddr = endpoint->bEndpointAddress;
>   sur40->bulk_in_buffer = kmalloc(sur40->bulk_in_size, GFP_KERNEL);
>   if (!sur40->bulk_in_buffer) {
> - dev_err(>dev, "Unable to allocate input buffer.");
>   error = -ENOMEM;
>   goto err_free_polldev;
>   }
> 

Re: [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks

[Li Kun]

On 2018/1/19 22:28, Will Deacon Wrote:

On Fri, Jan 19, 2018 at 11:37:24AM +0800, Li Kun wrote:

在 2018/1/17 18:07, Will Deacon 写道:

On Wed, Jan 17, 2018 at 12:10:33PM +0800, Yisheng Xie wrote:

On 2018/1/5 21:12, Will Deacon wrote:

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 5f7097d0cd12..d99b36555a16 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -246,6 +246,8 @@ asmlinkage void post_ttbr_update_workaround(void)
"ic iallu; dsb nsh; isb",
ARM64_WORKAROUND_CAVIUM_27456,
CONFIG_CAVIUM_ERRATUM_27456));
+
+   arm64_apply_bp_hardening();
  }

post_ttbr_update_workaround was used for fix Cavium erratum 2745? so does that
means, if we do not have this erratum, we do not need 
arm64_apply_bp_hardening()?
when mm_swtich and kernel_exit?

 From the code logical, it seems not only related to erratum 2745 anymore?
should it be renamed?

post_ttbr_update_workaround just runs code after a TTBR update, which
includes mitigations against variant 2 of "spectre" and also a workaround
for a Cavium erratum. These are separate issues.

But AFAIU, according to the theory of spectre, we don't need to clear the
BTB every time we return to user?
If we enable CONFIG_ARM64_SW_TTBR0_PAN, there will be a call to
arm64_apply_bp_hardening every time kernel exit to el0.
kernel_exit
 post_ttbr_update_workaround
 arm64_apply_bp_hardening

That's a really good point, thanks. What it means is that
post_ttbr_update_workaround is actually the wrong place for this, and we
should be doing it more directly on the switch_mm path -- probably in
check_and_switch_context.

Yes, that's exactly what i mean.:-)


Will


--
Best Regards
Li Kun

Re: [PATCH v2 07/11] arm64: Add skeleton to harden the branch predictor against aliasing attacks

[Li Kun]

On 2018/1/19 22:28, Will Deacon Wrote:

On Fri, Jan 19, 2018 at 11:37:24AM +0800, Li Kun wrote:

在 2018/1/17 18:07, Will Deacon 写道:

On Wed, Jan 17, 2018 at 12:10:33PM +0800, Yisheng Xie wrote:

On 2018/1/5 21:12, Will Deacon wrote:

diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
index 5f7097d0cd12..d99b36555a16 100644
--- a/arch/arm64/mm/context.c
+++ b/arch/arm64/mm/context.c
@@ -246,6 +246,8 @@ asmlinkage void post_ttbr_update_workaround(void)
"ic iallu; dsb nsh; isb",
ARM64_WORKAROUND_CAVIUM_27456,
CONFIG_CAVIUM_ERRATUM_27456));
+
+   arm64_apply_bp_hardening();
  }

post_ttbr_update_workaround was used for fix Cavium erratum 2745? so does that
means, if we do not have this erratum, we do not need 
arm64_apply_bp_hardening()?
when mm_swtich and kernel_exit?

 From the code logical, it seems not only related to erratum 2745 anymore?
should it be renamed?

post_ttbr_update_workaround just runs code after a TTBR update, which
includes mitigations against variant 2 of "spectre" and also a workaround
for a Cavium erratum. These are separate issues.

But AFAIU, according to the theory of spectre, we don't need to clear the
BTB every time we return to user?
If we enable CONFIG_ARM64_SW_TTBR0_PAN, there will be a call to
arm64_apply_bp_hardening every time kernel exit to el0.
kernel_exit
 post_ttbr_update_workaround
 arm64_apply_bp_hardening

That's a really good point, thanks. What it means is that
post_ttbr_update_workaround is actually the wrong place for this, and we
should be doing it more directly on the switch_mm path -- probably in
check_and_switch_context.

Yes, that's exactly what i mean.:-)


Will


--
Best Regards
Li Kun

[RFC PATCH net-next] net: aquantia: hw_atl_utils_mpi_set_speed() can be static

[kbuild test robot]

Fixes: 0c58c35f02c2 ("net: aquantia: Introduce firmware ops callbacks")
Signed-off-by: Fengguang Wu 
---
 hw_atl_utils.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index 967f0fd..ad87338 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -483,7 +483,7 @@ void hw_atl_utils_mpi_read_stats(struct aq_hw_s *self,
 err_exit:;
 }
 
-int hw_atl_utils_mpi_set_speed(struct aq_hw_s *self, u32 speed)
+static int hw_atl_utils_mpi_set_speed(struct aq_hw_s *self, u32 speed)
 {
u32 val = aq_hw_read_reg(self, HW_ATL_MPI_CONTROL_ADR);
 

[RFC PATCH net-next] net: aquantia: hw_atl_utils_mpi_set_speed() can be static

[kbuild test robot]

Fixes: 0c58c35f02c2 ("net: aquantia: Introduce firmware ops callbacks")
Signed-off-by: Fengguang Wu 
---
 hw_atl_utils.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c 
b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
index 967f0fd..ad87338 100644
--- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
+++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_utils.c
@@ -483,7 +483,7 @@ void hw_atl_utils_mpi_read_stats(struct aq_hw_s *self,
 err_exit:;
 }
 
-int hw_atl_utils_mpi_set_speed(struct aq_hw_s *self, u32 speed)
+static int hw_atl_utils_mpi_set_speed(struct aq_hw_s *self, u32 speed)
 {
u32 val = aq_hw_read_reg(self, HW_ATL_MPI_CONTROL_ADR);
 

[PATCH 5/6] x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI

[Jan Kiszka]

From: Jan Kiszka 

Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.

Saves some bytes in the Jailhouse non-root kernel.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig  | 6 +-
 arch/x86/kernel/Makefile  | 2 +-
 arch/x86/kernel/cpu/amd.c | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f2038417a590..77ba0eb0a258 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2597,7 +2597,7 @@ config PCI_DIRECT
 config PCI_MMCONFIG
bool "Support mmconfig PCI config space access" if X86_64
default y
-   depends on PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY || 
X86_64)
+   depends on PCI && (ACPI || SFI || JAILHOUSE_GUEST) && (PCI_GOMMCONFIG 
|| PCI_GOANY || X86_64)
 
 config PCI_OLPC
def_bool y
@@ -2612,6 +2612,10 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
+config MMCONF_FAM10H
+   def_bool y
+   depends on PCI_MMCONFIG && ACPI
+
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index aed9296dccd3..b2c9e230e2fe 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -143,6 +143,6 @@ ifeq ($(CONFIG_X86_64),y)
obj-$(CONFIG_GART_IOMMU)+= amd_gart_64.o aperture_64.o
obj-$(CONFIG_CALGARY_IOMMU) += pci-calgary_64.o tce_64.o
 
-   obj-$(CONFIG_PCI_MMCONFIG)  += mmconf-fam10h_64.o
+   obj-$(CONFIG_MMCONF_FAM10H) += mmconf-fam10h_64.o
obj-y   += vsmp_64.o
 endif
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index ea831c858195..47edf599f6fd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -690,7 +690,7 @@ static void init_amd_k8(struct cpuinfo_x86 *c)
 
 static void init_amd_gh(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_MMCONF_FAM10H
/* do this for boot cpu */
if (c == _cpu_data)
check_enable_amd_mmconf_dmi();
-- 
2.13.6

[PATCH 5/6] x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI

[Jan Kiszka]

From: Jan Kiszka 

Jailhouse does not use ACPI, but it does support MMCONFIG. Make sure the
latter can be built without having to enable ACPI as well. Primarily, we
need to make the AMD mmconf-fam10h_64 depend upon MMCONFIG and ACPI,
instead of just the former.

Saves some bytes in the Jailhouse non-root kernel.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig  | 6 +-
 arch/x86/kernel/Makefile  | 2 +-
 arch/x86/kernel/cpu/amd.c | 2 +-
 3 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f2038417a590..77ba0eb0a258 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2597,7 +2597,7 @@ config PCI_DIRECT
 config PCI_MMCONFIG
bool "Support mmconfig PCI config space access" if X86_64
default y
-   depends on PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY || 
X86_64)
+   depends on PCI && (ACPI || SFI || JAILHOUSE_GUEST) && (PCI_GOMMCONFIG 
|| PCI_GOANY || X86_64)
 
 config PCI_OLPC
def_bool y
@@ -2612,6 +2612,10 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
+config MMCONF_FAM10H
+   def_bool y
+   depends on PCI_MMCONFIG && ACPI
+
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index aed9296dccd3..b2c9e230e2fe 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -143,6 +143,6 @@ ifeq ($(CONFIG_X86_64),y)
obj-$(CONFIG_GART_IOMMU)+= amd_gart_64.o aperture_64.o
obj-$(CONFIG_CALGARY_IOMMU) += pci-calgary_64.o tce_64.o
 
-   obj-$(CONFIG_PCI_MMCONFIG)  += mmconf-fam10h_64.o
+   obj-$(CONFIG_MMCONF_FAM10H) += mmconf-fam10h_64.o
obj-y   += vsmp_64.o
 endif
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index ea831c858195..47edf599f6fd 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -690,7 +690,7 @@ static void init_amd_k8(struct cpuinfo_x86 *c)
 
 static void init_amd_gh(struct cpuinfo_x86 *c)
 {
-#ifdef CONFIG_X86_64
+#ifdef CONFIG_MMCONF_FAM10H
/* do this for boot cpu */
if (c == _cpu_data)
check_enable_amd_mmconf_dmi();
-- 
2.13.6

[PATCH 6/6] MAINTAINERS: Add entry for Jailhouse

[Jan Kiszka]

From: Jan Kiszka 

Signed-off-by: Jan Kiszka 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 426ba037d943..dd51a2012b36 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7468,6 +7468,13 @@ Q:   
http://patchwork.linuxtv.org/project/linux-media/list/
 S: Maintained
 F: drivers/media/dvb-frontends/ix2505v*
 
+JAILHOUSE HYPERVISOR INTERFACE
+M: Jan Kiszka 
+L: jailhouse-...@googlegroups.com
+S: Maintained
+F: arch/x86/kernel/jailhouse.c
+F: arch/x86/include/asm/jailhouse_para.h
+
 JC42.4 TEMPERATURE SENSOR DRIVER
 M: Guenter Roeck 
 L: linux-hw...@vger.kernel.org
-- 
2.13.6

[PATCH 0/6] jailhouse: Enhance secondary Jailhouse guest support /wrt PCI

[Jan Kiszka]

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest
is currently pending in the tip tree. This builds on top and enhances
the PCI support for x86 and also ARM guests (ARM[64] does not require
platform patches and works already).

Key elements of this series are:
 - detection of Jailhouse via device tree hypervisor node
 - function-level PCI scan if Jailhouse is detected
 - MMCONFIG support for x86 guests

As most changes affect x86, I would suggest to route the series also via
tip after the necessary acks are collected.

Jan

[1] https://lkml.org/lkml/2017/11/27/125
[2] http://jailhouse-project.org

CC: Benedikt Spranger 
CC: Mark Rutland 
CC: Otavio Pontes 
CC: Rob Herring 

Jan Kiszka (5):
  jailhouse: Provide detection for non-x86 systems
  pci: Scan all functions when probing while running over Jailhouse
  x86: Consolidate PCI_MMCONFIG configs
  x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI
  MAINTAINERS: Add entry for Jailhouse

Otavio Pontes (1):
  x86/jailhouse: Enable PCI mmconfig access in inmates

 Documentation/devicetree/bindings/jailhouse.txt |  8 
 MAINTAINERS |  7 +++
 arch/x86/Kconfig| 11 ++-
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 arch/x86/include/asm/pci_x86.h  |  2 ++
 arch/x86/kernel/Makefile|  2 +-
 arch/x86/kernel/cpu/amd.c   |  2 +-
 arch/x86/kernel/jailhouse.c |  7 +++
 arch/x86/pci/legacy.c   |  4 +++-
 arch/x86/pci/mmconfig-shared.c  |  4 ++--
 drivers/pci/probe.c |  4 +++-
 include/linux/hypervisor.h  | 17 +++--
 12 files changed, 56 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

-- 
2.13.6

[PATCH 6/6] MAINTAINERS: Add entry for Jailhouse

[Jan Kiszka]

From: Jan Kiszka 

Signed-off-by: Jan Kiszka 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 426ba037d943..dd51a2012b36 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7468,6 +7468,13 @@ Q:   
http://patchwork.linuxtv.org/project/linux-media/list/
 S: Maintained
 F: drivers/media/dvb-frontends/ix2505v*
 
+JAILHOUSE HYPERVISOR INTERFACE
+M: Jan Kiszka 
+L: jailhouse-...@googlegroups.com
+S: Maintained
+F: arch/x86/kernel/jailhouse.c
+F: arch/x86/include/asm/jailhouse_para.h
+
 JC42.4 TEMPERATURE SENSOR DRIVER
 M: Guenter Roeck 
 L: linux-hw...@vger.kernel.org
-- 
2.13.6

[PATCH 0/6] jailhouse: Enhance secondary Jailhouse guest support /wrt PCI

[Jan Kiszka]

Basic x86 support [1] for running Linux as secondary Jailhouse [2] guest
is currently pending in the tip tree. This builds on top and enhances
the PCI support for x86 and also ARM guests (ARM[64] does not require
platform patches and works already).

Key elements of this series are:
 - detection of Jailhouse via device tree hypervisor node
 - function-level PCI scan if Jailhouse is detected
 - MMCONFIG support for x86 guests

As most changes affect x86, I would suggest to route the series also via
tip after the necessary acks are collected.

Jan

[1] https://lkml.org/lkml/2017/11/27/125
[2] http://jailhouse-project.org

CC: Benedikt Spranger 
CC: Mark Rutland 
CC: Otavio Pontes 
CC: Rob Herring 

Jan Kiszka (5):
  jailhouse: Provide detection for non-x86 systems
  pci: Scan all functions when probing while running over Jailhouse
  x86: Consolidate PCI_MMCONFIG configs
  x86/jailhouse: Allow to use PCI_MMCONFIG without ACPI
  MAINTAINERS: Add entry for Jailhouse

Otavio Pontes (1):
  x86/jailhouse: Enable PCI mmconfig access in inmates

 Documentation/devicetree/bindings/jailhouse.txt |  8 
 MAINTAINERS |  7 +++
 arch/x86/Kconfig| 11 ++-
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 arch/x86/include/asm/pci_x86.h  |  2 ++
 arch/x86/kernel/Makefile|  2 +-
 arch/x86/kernel/cpu/amd.c   |  2 +-
 arch/x86/kernel/jailhouse.c |  7 +++
 arch/x86/pci/legacy.c   |  4 +++-
 arch/x86/pci/mmconfig-shared.c  |  4 ++--
 drivers/pci/probe.c |  4 +++-
 include/linux/hypervisor.h  | 17 +++--
 12 files changed, 56 insertions(+), 14 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

-- 
2.13.6

[PATCH 4/6] x86: Consolidate PCI_MMCONFIG configs

[Jan Kiszka]

From: Jan Kiszka 

Not sure if those two worked by design or just by chance so far. In any
case, it's at least cleaner and clearer to express this in a single
config statement.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 423e4b64e683..f2038417a590 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2595,8 +2595,9 @@ config PCI_DIRECT
depends on PCI && (X86_64 || (PCI_GODIRECT || PCI_GOANY || PCI_GOOLPC 
|| PCI_GOMMCONFIG))
 
 config PCI_MMCONFIG
-   def_bool y
-   depends on X86_32 && PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || 
PCI_GOANY)
+   bool "Support mmconfig PCI config space access" if X86_64
+   default y
+   depends on PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY || 
X86_64)
 
 config PCI_OLPC
def_bool y
@@ -2611,10 +2612,6 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
-config PCI_MMCONFIG
-   bool "Support mmconfig PCI config space access"
-   depends on X86_64 && PCI && ACPI
-
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
-- 
2.13.6

[PATCH 3/6] x86/jailhouse: Enable PCI mmconfig access in inmates

[Jan Kiszka]

From: Otavio Pontes 

Use the PCI mmconfig base address exported by jailhouse in boot
parameters in order to access the memory mapped PCI configuration space.

Signed-off-by: Otavio Pontes 
[Jan: rebased, fixed !CONFIG_PCI_MMCONFIG]
Signed-off-by: Jan Kiszka 
---
 arch/x86/include/asm/pci_x86.h | 2 ++
 arch/x86/kernel/jailhouse.c| 7 +++
 arch/x86/pci/mmconfig-shared.c | 4 ++--
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index eb66fa9cd0fc..959d618dbb17 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -151,6 +151,8 @@ extern int pci_mmconfig_insert(struct device *dev, u16 seg, 
u8 start, u8 end,
   phys_addr_t addr);
 extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
 extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+extern struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+   int end, u64 addr);
 
 extern struct list_head pci_mmcfg_list;
 
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index b68fd895235a..7fe2a73da0b3 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -124,6 +124,13 @@ static int __init jailhouse_pci_arch_init(void)
if (pcibios_last_bus < 0)
pcibios_last_bus = 0xff;
 
+#ifdef CONFIG_PCI_MMCONFIG
+   if (setup_data.pci_mmconfig_base) {
+   pci_mmconfig_add(0, 0, 0xff, setup_data.pci_mmconfig_base);
+   pci_mmcfg_arch_init();
+   }
+#endif
+
return 0;
 }
 
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 96684d0adcf9..0e590272366b 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -94,8 +94,8 @@ static struct pci_mmcfg_region *pci_mmconfig_alloc(int 
segment, int start,
return new;
 }
 
-static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
-   int end, u64 addr)
+struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+int end, u64 addr)
 {
struct pci_mmcfg_region *new;
 
-- 
2.13.6

[PATCH 4/6] x86: Consolidate PCI_MMCONFIG configs

[Jan Kiszka]

From: Jan Kiszka 

Not sure if those two worked by design or just by chance so far. In any
case, it's at least cleaner and clearer to express this in a single
config statement.

Signed-off-by: Jan Kiszka 
---
 arch/x86/Kconfig | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 423e4b64e683..f2038417a590 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2595,8 +2595,9 @@ config PCI_DIRECT
depends on PCI && (X86_64 || (PCI_GODIRECT || PCI_GOANY || PCI_GOOLPC 
|| PCI_GOMMCONFIG))
 
 config PCI_MMCONFIG
-   def_bool y
-   depends on X86_32 && PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || 
PCI_GOANY)
+   bool "Support mmconfig PCI config space access" if X86_64
+   default y
+   depends on PCI && (ACPI || SFI) && (PCI_GOMMCONFIG || PCI_GOANY || 
X86_64)
 
 config PCI_OLPC
def_bool y
@@ -2611,10 +2612,6 @@ config PCI_DOMAINS
def_bool y
depends on PCI
 
-config PCI_MMCONFIG
-   bool "Support mmconfig PCI config space access"
-   depends on X86_64 && PCI && ACPI
-
 config PCI_CNB20LE_QUIRK
bool "Read CNB20LE Host Bridge Windows" if EXPERT
depends on PCI
-- 
2.13.6

[PATCH 3/6] x86/jailhouse: Enable PCI mmconfig access in inmates

[Jan Kiszka]

From: Otavio Pontes 

Use the PCI mmconfig base address exported by jailhouse in boot
parameters in order to access the memory mapped PCI configuration space.

Signed-off-by: Otavio Pontes 
[Jan: rebased, fixed !CONFIG_PCI_MMCONFIG]
Signed-off-by: Jan Kiszka 
---
 arch/x86/include/asm/pci_x86.h | 2 ++
 arch/x86/kernel/jailhouse.c| 7 +++
 arch/x86/pci/mmconfig-shared.c | 4 ++--
 3 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/pci_x86.h b/arch/x86/include/asm/pci_x86.h
index eb66fa9cd0fc..959d618dbb17 100644
--- a/arch/x86/include/asm/pci_x86.h
+++ b/arch/x86/include/asm/pci_x86.h
@@ -151,6 +151,8 @@ extern int pci_mmconfig_insert(struct device *dev, u16 seg, 
u8 start, u8 end,
   phys_addr_t addr);
 extern int pci_mmconfig_delete(u16 seg, u8 start, u8 end);
 extern struct pci_mmcfg_region *pci_mmconfig_lookup(int segment, int bus);
+extern struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+   int end, u64 addr);
 
 extern struct list_head pci_mmcfg_list;
 
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index b68fd895235a..7fe2a73da0b3 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -124,6 +124,13 @@ static int __init jailhouse_pci_arch_init(void)
if (pcibios_last_bus < 0)
pcibios_last_bus = 0xff;
 
+#ifdef CONFIG_PCI_MMCONFIG
+   if (setup_data.pci_mmconfig_base) {
+   pci_mmconfig_add(0, 0, 0xff, setup_data.pci_mmconfig_base);
+   pci_mmcfg_arch_init();
+   }
+#endif
+
return 0;
 }
 
diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
index 96684d0adcf9..0e590272366b 100644
--- a/arch/x86/pci/mmconfig-shared.c
+++ b/arch/x86/pci/mmconfig-shared.c
@@ -94,8 +94,8 @@ static struct pci_mmcfg_region *pci_mmconfig_alloc(int 
segment, int start,
return new;
 }
 
-static struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
-   int end, u64 addr)
+struct pci_mmcfg_region *__init pci_mmconfig_add(int segment, int start,
+int end, u64 addr)
 {
struct pci_mmcfg_region *new;
 
-- 
2.13.6

[PATCH v1 1/1] perf/x86/amd/power: do not load amd power module in intel platform

[Xiao Liang]

"power" module can be loaded if it is not amd processor.

And user cannot unload it after loaded it. The following call trace generated
when tried to unload it.

 BUG: unable to handle kernel NULL pointer dereference at   (null)
 IP: __list_del_entry_valid+0x29/0x90
 PGD 0 P4D 0
 Oops:  [#1] SMP PTI
 CPU: 1 PID: 26046 Comm: modprobe Not tainted 4.14.13-300.fc27.x86_64 #1
 Hardware name: Xen HVM domU, BIOS 4.9.1 12/12/2017
 task: 9a138f8dddc0 task.stack: b0ec41cbc000
 RIP: 0010:__list_del_entry_valid+0x29/0x90

 Call Trace:
  perf_pmu_unregister+0x25/0xf0
  amd_power_pmu_exit+0x1c/0xd23 [power]
  SyS_delete_module+0x1a8/0x2b0
  ? exit_to_usermode_loop+0x8f/0xb0
  entry_SYSCALL_64_fastpath+0x20/0x83
 RIP: 0033:0x7fb67d78e5c7

Signed-off-by: Xiao Liang 
---
 arch/x86/events/amd/power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/amd/power.c b/arch/x86/events/amd/power.c
index a6eee5ac4f58..2aefacf5c5b2 100644
--- a/arch/x86/events/amd/power.c
+++ b/arch/x86/events/amd/power.c
@@ -277,7 +277,7 @@ static int __init amd_power_pmu_init(void)
int ret;
 
if (!x86_match_cpu(cpu_match))
-   return 0;
+   return -ENODEV;
 
if (!boot_cpu_has(X86_FEATURE_ACC_POWER))
return -ENODEV;
-- 
2.14.3

[PATCH 2/6] pci: Scan all functions when probing while running over Jailhouse

[Jan Kiszka]

From: Jan Kiszka 

PCI and PCIBIOS probing only scans devices at function number 0/8/16/...
Subdevices (e.g. multiqueue) have function numbers which are not a
multiple of 8.

The simple hypervisor Jailhouse passes subdevices directly w/o providing
a virtual PCI topology like KVM. As a consequence a PCI passthrough from
Jailhouse to a guest will not be detected by Linux.

Based on patch by Benedikt Spranger, adding Jailhouse probing to avoid
changing the behavior in the absence of the hypervisor.

CC: Benedikt Spranger 
Signed-off-by: Jan Kiszka 
---
 arch/x86/pci/legacy.c | 4 +++-
 drivers/pci/probe.c   | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/legacy.c b/arch/x86/pci/legacy.c
index 1cb01abcb1be..a7b0476b4f44 100644
--- a/arch/x86/pci/legacy.c
+++ b/arch/x86/pci/legacy.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Discover remaining PCI buses in case there are peer host bridges.
@@ -34,13 +35,14 @@ int __init pci_legacy_init(void)
 
 void pcibios_scan_specific_bus(int busn)
 {
+   int stride = jailhouse_paravirt() ? 1 : 8;
int devfn;
u32 l;
 
if (pci_find_bus(0, busn))
return;
 
-   for (devfn = 0; devfn < 256; devfn += 8) {
+   for (devfn = 0; devfn < 256; devfn += stride) {
if (!raw_pci_read(0, busn, devfn, PCI_VENDOR_ID, 2, ) &&
l != 0x && l != 0x) {
DBG("Found device at %02x:%02x [%04x]\n", busn, devfn, 
l);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 14e0ea1ff38b..60ad14c8245f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci.h"
 
 #define CARDBUS_LATENCY_TIMER  176 /* secondary latency timer */
@@ -2454,6 +2455,7 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
  unsigned int available_buses)
 {
unsigned int used_buses, normal_bridges = 0, hotplug_bridges = 0;
+   unsigned int stride = jailhouse_paravirt() ? 1 : 8;
unsigned int start = bus->busn_res.start;
unsigned int devfn, cmax, max = start;
struct pci_dev *dev;
@@ -2461,7 +2463,7 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
dev_dbg(>dev, "scanning bus\n");
 
/* Go find them, Rover! */
-   for (devfn = 0; devfn < 0x100; devfn += 8)
+   for (devfn = 0; devfn < 0x100; devfn += stride)
pci_scan_slot(bus, devfn);
 
/* Reserve buses for SR-IOV capability. */
-- 
2.13.6

[PATCH v1 1/1] perf/x86/amd/power: do not load amd power module in intel platform

[Xiao Liang]

"power" module can be loaded if it is not amd processor.

And user cannot unload it after loaded it. The following call trace generated
when tried to unload it.

 BUG: unable to handle kernel NULL pointer dereference at   (null)
 IP: __list_del_entry_valid+0x29/0x90
 PGD 0 P4D 0
 Oops:  [#1] SMP PTI
 CPU: 1 PID: 26046 Comm: modprobe Not tainted 4.14.13-300.fc27.x86_64 #1
 Hardware name: Xen HVM domU, BIOS 4.9.1 12/12/2017
 task: 9a138f8dddc0 task.stack: b0ec41cbc000
 RIP: 0010:__list_del_entry_valid+0x29/0x90

 Call Trace:
  perf_pmu_unregister+0x25/0xf0
  amd_power_pmu_exit+0x1c/0xd23 [power]
  SyS_delete_module+0x1a8/0x2b0
  ? exit_to_usermode_loop+0x8f/0xb0
  entry_SYSCALL_64_fastpath+0x20/0x83
 RIP: 0033:0x7fb67d78e5c7

Signed-off-by: Xiao Liang 
---
 arch/x86/events/amd/power.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/events/amd/power.c b/arch/x86/events/amd/power.c
index a6eee5ac4f58..2aefacf5c5b2 100644
--- a/arch/x86/events/amd/power.c
+++ b/arch/x86/events/amd/power.c
@@ -277,7 +277,7 @@ static int __init amd_power_pmu_init(void)
int ret;
 
if (!x86_match_cpu(cpu_match))
-   return 0;
+   return -ENODEV;
 
if (!boot_cpu_has(X86_FEATURE_ACC_POWER))
return -ENODEV;
-- 
2.14.3

[PATCH 2/6] pci: Scan all functions when probing while running over Jailhouse

[Jan Kiszka]

From: Jan Kiszka 

PCI and PCIBIOS probing only scans devices at function number 0/8/16/...
Subdevices (e.g. multiqueue) have function numbers which are not a
multiple of 8.

The simple hypervisor Jailhouse passes subdevices directly w/o providing
a virtual PCI topology like KVM. As a consequence a PCI passthrough from
Jailhouse to a guest will not be detected by Linux.

Based on patch by Benedikt Spranger, adding Jailhouse probing to avoid
changing the behavior in the absence of the hypervisor.

CC: Benedikt Spranger 
Signed-off-by: Jan Kiszka 
---
 arch/x86/pci/legacy.c | 4 +++-
 drivers/pci/probe.c   | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/legacy.c b/arch/x86/pci/legacy.c
index 1cb01abcb1be..a7b0476b4f44 100644
--- a/arch/x86/pci/legacy.c
+++ b/arch/x86/pci/legacy.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Discover remaining PCI buses in case there are peer host bridges.
@@ -34,13 +35,14 @@ int __init pci_legacy_init(void)
 
 void pcibios_scan_specific_bus(int busn)
 {
+   int stride = jailhouse_paravirt() ? 1 : 8;
int devfn;
u32 l;
 
if (pci_find_bus(0, busn))
return;
 
-   for (devfn = 0; devfn < 256; devfn += 8) {
+   for (devfn = 0; devfn < 256; devfn += stride) {
if (!raw_pci_read(0, busn, devfn, PCI_VENDOR_ID, 2, ) &&
l != 0x && l != 0x) {
DBG("Found device at %02x:%02x [%04x]\n", busn, devfn, 
l);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 14e0ea1ff38b..60ad14c8245f 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "pci.h"
 
 #define CARDBUS_LATENCY_TIMER  176 /* secondary latency timer */
@@ -2454,6 +2455,7 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
  unsigned int available_buses)
 {
unsigned int used_buses, normal_bridges = 0, hotplug_bridges = 0;
+   unsigned int stride = jailhouse_paravirt() ? 1 : 8;
unsigned int start = bus->busn_res.start;
unsigned int devfn, cmax, max = start;
struct pci_dev *dev;
@@ -2461,7 +2463,7 @@ static unsigned int pci_scan_child_bus_extend(struct 
pci_bus *bus,
dev_dbg(>dev, "scanning bus\n");
 
/* Go find them, Rover! */
-   for (devfn = 0; devfn < 0x100; devfn += 8)
+   for (devfn = 0; devfn < 0x100; devfn += stride)
pci_scan_slot(bus, devfn);
 
/* Reserve buses for SR-IOV capability. */
-- 
2.13.6

[PATCH 1/6] jailhouse: Provide detection for non-x86 systems

[Jan Kiszka]

From: Jan Kiszka 

Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.

CC: Rob Herring 
CC: Mark Rutland 
Signed-off-by: Jan Kiszka 
---
 Documentation/devicetree/bindings/jailhouse.txt |  8 
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 include/linux/hypervisor.h  | 17 +++--
 3 files changed, 24 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

diff --git a/Documentation/devicetree/bindings/jailhouse.txt 
b/Documentation/devicetree/bindings/jailhouse.txt
new file mode 100644
index ..2901c25ff340
--- /dev/null
+++ b/Documentation/devicetree/bindings/jailhouse.txt
@@ -0,0 +1,8 @@
+Jailhouse non-root cell device tree bindings
+
+
+When running in a non-root Jailhouse cell (partition), the device tree of this
+platform shall have a top-level "hypervisor" node with the following
+properties:
+
+- compatible = "jailhouse,cell"
diff --git a/arch/x86/include/asm/jailhouse_para.h 
b/arch/x86/include/asm/jailhouse_para.h
index 875b54376689..b885a961a150 100644
--- a/arch/x86/include/asm/jailhouse_para.h
+++ b/arch/x86/include/asm/jailhouse_para.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL2.0 */
 
 /*
- * Jailhouse paravirt_ops implementation
+ * Jailhouse paravirt detection
  *
  * Copyright (c) Siemens AG, 2015-2017
  *
diff --git a/include/linux/hypervisor.h b/include/linux/hypervisor.h
index b19563f9a8eb..fc08b433c856 100644
--- a/include/linux/hypervisor.h
+++ b/include/linux/hypervisor.h
@@ -8,15 +8,28 @@
  */
 
 #ifdef CONFIG_X86
+
+#include 
 #include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
x86_platform.hyper.pin_vcpu(cpu);
 }
-#else
+
+#else /* !CONFIG_X86 */
+
+#include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
 }
-#endif
+
+static inline bool jailhouse_paravirt(void)
+{
+   return of_find_compatible_node(NULL, NULL, "jailhouse,cell");
+}
+
+#endif /* !CONFIG_X86 */
 
 #endif /* __LINUX_HYPEVISOR_H */
-- 
2.13.6

[PATCH 1/6] jailhouse: Provide detection for non-x86 systems

[Jan Kiszka]

From: Jan Kiszka 

Implement jailhouse_paravirt() via device tree probing on architectures
!= x86. Will be used by the PCI core.

CC: Rob Herring 
CC: Mark Rutland 
Signed-off-by: Jan Kiszka 
---
 Documentation/devicetree/bindings/jailhouse.txt |  8 
 arch/x86/include/asm/jailhouse_para.h   |  2 +-
 include/linux/hypervisor.h  | 17 +++--
 3 files changed, 24 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/jailhouse.txt

diff --git a/Documentation/devicetree/bindings/jailhouse.txt 
b/Documentation/devicetree/bindings/jailhouse.txt
new file mode 100644
index ..2901c25ff340
--- /dev/null
+++ b/Documentation/devicetree/bindings/jailhouse.txt
@@ -0,0 +1,8 @@
+Jailhouse non-root cell device tree bindings
+
+
+When running in a non-root Jailhouse cell (partition), the device tree of this
+platform shall have a top-level "hypervisor" node with the following
+properties:
+
+- compatible = "jailhouse,cell"
diff --git a/arch/x86/include/asm/jailhouse_para.h 
b/arch/x86/include/asm/jailhouse_para.h
index 875b54376689..b885a961a150 100644
--- a/arch/x86/include/asm/jailhouse_para.h
+++ b/arch/x86/include/asm/jailhouse_para.h
@@ -1,7 +1,7 @@
 /* SPDX-License-Identifier: GPL2.0 */
 
 /*
- * Jailhouse paravirt_ops implementation
+ * Jailhouse paravirt detection
  *
  * Copyright (c) Siemens AG, 2015-2017
  *
diff --git a/include/linux/hypervisor.h b/include/linux/hypervisor.h
index b19563f9a8eb..fc08b433c856 100644
--- a/include/linux/hypervisor.h
+++ b/include/linux/hypervisor.h
@@ -8,15 +8,28 @@
  */
 
 #ifdef CONFIG_X86
+
+#include 
 #include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
x86_platform.hyper.pin_vcpu(cpu);
 }
-#else
+
+#else /* !CONFIG_X86 */
+
+#include 
+
 static inline void hypervisor_pin_vcpu(int cpu)
 {
 }
-#endif
+
+static inline bool jailhouse_paravirt(void)
+{
+   return of_find_compatible_node(NULL, NULL, "jailhouse,cell");
+}
+
+#endif /* !CONFIG_X86 */
 
 #endif /* __LINUX_HYPEVISOR_H */
-- 
2.13.6

[PATCH] arm: Initialize hrtimer-based broadcast clockevent

[Jan Kiszka]

Analogously to 9358d755bd5c, this registers a broadcast clockevent in
case no hardware broadcast timer is available and the per-CPU timers can
be stopped in deep power states.

Partitions of the Jailhouse hypervisor fall in this category.
Registering the workaround timer allows to enter high-resolution mode in
that case.

Signed-off-by: Jan Kiszka 
---
 arch/arm/kernel/time.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 629f8e9981f1..0a45d861ef8e 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -12,6 +12,7 @@
  *  reading the RTC at bootup, etc...
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -121,5 +122,7 @@ void __init time_init(void)
of_clk_init(NULL);
 #endif
timer_probe();
+
+   tick_setup_hrtimer_broadcast();
}
 }

[PATCH] arm: Initialize hrtimer-based broadcast clockevent

[Jan Kiszka]

Analogously to 9358d755bd5c, this registers a broadcast clockevent in
case no hardware broadcast timer is available and the per-CPU timers can
be stopped in deep power states.

Partitions of the Jailhouse hypervisor fall in this category.
Registering the workaround timer allows to enter high-resolution mode in
that case.

Signed-off-by: Jan Kiszka 
---
 arch/arm/kernel/time.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index 629f8e9981f1..0a45d861ef8e 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -12,6 +12,7 @@
  *  reading the RTC at bootup, etc...
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -121,5 +122,7 @@ void __init time_init(void)
of_clk_init(NULL);
 #endif
timer_probe();
+
+   tick_setup_hrtimer_broadcast();
}
 }

[ANNOUNCE] Git v2.16.1

[Junio C Hamano]

The latest maintenance release Git v2.16.1 is now available at
the usual places.

This is solely to fix a brown-paper bag bug that broke "git clone"
on case insensitive filesystems of certain projects.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.16.1'
tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://github.com/gitster/git



Git v2.16.1 Release Notes
=

Fixes since v2.16
-

 * "git clone" segfaulted when cloning a project that happens to
   track two paths that differ only in case on a case insensitive
   filesystem.

Does not contain any other documentation updates or code clean-ups.



Changes since v2.16.0 are as follows:

Eric Sunshine (1):
  t5601-clone: test case-conflicting files on case-insensitive filesystem

Junio C Hamano (1):
  Git 2.16.1

brian m. carlson (1):
  repository: pre-initialize hash algo pointer

[ANNOUNCE] Git v2.16.1

[Junio C Hamano]

The latest maintenance release Git v2.16.1 is now available at
the usual places.

This is solely to fix a brown-paper bag bug that broke "git clone"
on case insensitive filesystems of certain projects.

The tarballs are found at:

https://www.kernel.org/pub/software/scm/git/

The following public repositories all have a copy of the 'v2.16.1'
tag and the 'maint' branch that the tag points at:

  url = https://kernel.googlesource.com/pub/scm/git/git
  url = git://repo.or.cz/alt-git.git
  url = https://github.com/gitster/git



Git v2.16.1 Release Notes
=

Fixes since v2.16
-

 * "git clone" segfaulted when cloning a project that happens to
   track two paths that differ only in case on a case insensitive
   filesystem.

Does not contain any other documentation updates or code clean-ups.



Changes since v2.16.0 are as follows:

Eric Sunshine (1):
  t5601-clone: test case-conflicting files on case-insensitive filesystem

Junio C Hamano (1):
  Git 2.16.1

brian m. carlson (1):
  repository: pre-initialize hash algo pointer

Re: [PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread

[Jin, Yao]

On 1/16/2018 9:17 PM, Jiri Olsa wrote:

On Tue, Jan 16, 2018 at 09:06:09PM +0800, Jin, Yao wrote:

Just tested. But looks it's not OK for '--per-thread' case.


yea, I haven't tested much.. might need soem tweaking,
but my point was that it could be doable on one place
instead of introducing another if possible

jirka



Hi Jiri,

I ever considered to move the operation of removing error thread to 
perf_evsel__fallback(). The perf_evsel__fallback() is common code and 
it's shared by perf report, perf stat and perf top.


While finally I think it'd better let the caller decide to remove error 
thread and try again, or just return the warning message. 
perf_evsel__fallback() probably doesn't know what the caller want to do.


That's my current thinking. Maybe there will be a better fix...

Thanks
Jin Yao

Re: [PATCH] perf stat: Ignore error thread when enabling system-wide --per-thread

[Jin, Yao]

On 1/16/2018 9:17 PM, Jiri Olsa wrote:

On Tue, Jan 16, 2018 at 09:06:09PM +0800, Jin, Yao wrote:

Just tested. But looks it's not OK for '--per-thread' case.


yea, I haven't tested much.. might need soem tweaking,
but my point was that it could be doable on one place
instead of introducing another if possible

jirka



Hi Jiri,

I ever considered to move the operation of removing error thread to 
perf_evsel__fallback(). The perf_evsel__fallback() is common code and 
it's shared by perf report, perf stat and perf top.


While finally I think it'd better let the caller decide to remove error 
thread and try again, or just return the warning message. 
perf_evsel__fallback() probably doesn't know what the caller want to do.


That's my current thinking. Maybe there will be a better fix...

Thanks
Jin Yao

[PATCH v2 6/6] powerpc: wii.dts: Add GPIO line names

[Jonathan Neuschäfer]

These are the GPIO line names on a Nintendo Wii, as documented in:
https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs

Signed-off-by: Jonathan Neuschäfer 
---

v2:
- no change
---
 arch/powerpc/boot/dts/wii.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index 7235e375919c..07d5e84e98b1 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -178,6 +178,14 @@
gpio-controller;
ngpios = <24>;
 
+   gpio-line-names =
+   "POWER", "SHUTDOWN", "FAN", "DC_DC",
+   "DI_SPIN", "SLOT_LED", "EJECT_BTN", "SLOT_IN",
+   "SENSOR_BAR", "DO_EJECT", "EEP_CS", "EEP_CLK",
+   "EEP_MOSI", "EEP_MISO", "AVE_SCL", "AVE_SDA",
+   "DEBUG0", "DEBUG1", "DEBUG2", "DEBUG3",
+   "DEBUG4", "DEBUG5", "DEBUG6", "DEBUG7";
+
/*
 * This is commented out while a standard binding
 * for i2c over gpio is defined.
-- 
2.15.1

[PATCH v2 6/6] powerpc: wii.dts: Add GPIO line names

[Jonathan Neuschäfer]

These are the GPIO line names on a Nintendo Wii, as documented in:
https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs

Signed-off-by: Jonathan Neuschäfer 
---

v2:
- no change
---
 arch/powerpc/boot/dts/wii.dts | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index 7235e375919c..07d5e84e98b1 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -178,6 +178,14 @@
gpio-controller;
ngpios = <24>;
 
+   gpio-line-names =
+   "POWER", "SHUTDOWN", "FAN", "DC_DC",
+   "DI_SPIN", "SLOT_LED", "EJECT_BTN", "SLOT_IN",
+   "SENSOR_BAR", "DO_EJECT", "EEP_CS", "EEP_CLK",
+   "EEP_MOSI", "EEP_MISO", "AVE_SCL", "AVE_SDA",
+   "DEBUG0", "DEBUG1", "DEBUG2", "DEBUG3",
+   "DEBUG4", "DEBUG5", "DEBUG6", "DEBUG7";
+
/*
 * This is commented out while a standard binding
 * for i2c over gpio is defined.
-- 
2.15.1

[PATCH v2 5/6] powerpc: wii.dts: Add ngpios property

[Jonathan Neuschäfer]

The Hollywood GPIO controller supports 32 GPIOs, but on the Wii, only 24
are used.

Signed-off-by: Jonathan Neuschäfer 
---

v2:
- no change
---
 arch/powerpc/boot/dts/wii.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index 40b324b6391e..7235e375919c 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -176,6 +176,7 @@
compatible = "nintendo,hollywood-gpio";
reg = <0x0d8000c0 0x40>;
gpio-controller;
+   ngpios = <24>;
 
/*
 * This is commented out while a standard binding
-- 
2.15.1

[PATCH v2 5/6] powerpc: wii.dts: Add ngpios property

[Jonathan Neuschäfer]

The Hollywood GPIO controller supports 32 GPIOs, but on the Wii, only 24
are used.

Signed-off-by: Jonathan Neuschäfer 
---

v2:
- no change
---
 arch/powerpc/boot/dts/wii.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index 40b324b6391e..7235e375919c 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -176,6 +176,7 @@
compatible = "nintendo,hollywood-gpio";
reg = <0x0d8000c0 0x40>;
gpio-controller;
+   ngpios = <24>;
 
/*
 * This is commented out while a standard binding
-- 
2.15.1

Re: [PATCH 02/13] powerpc/powernv: Set correct configuration space size for opencapi devices

[Andrew Donnellan]

On 20/01/18 20:52, Michael Ellerman wrote:> On my Power8 PowerVM LPAR:



Will fix...

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: [PATCH 02/13] powerpc/powernv: Set correct configuration space size for opencapi devices

[Andrew Donnellan]

On 20/01/18 20:52, Michael Ellerman wrote:> On my Power8 PowerVM LPAR:



Will fix...

--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

[PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack

[Jonathan Neuschäfer]

On the Nintendo Wii, there are two ranges of physical memory, and MMIO
in between, but Linux on ppc32 doesn't support discontiguous memory.
Therefore a hack was introduced in commit c5df7f775148 ("powerpc: allow
ioremap within reserved memory regions") and commit de32400dd26e ("wii:
use both mem1 and mem2 as ram"):

 - Treat the area from the start of the first memory area (MEM1) to the
   end of the second (MEM2) as one big memory area, but mark the part
   that doesn't belong to MEM1 or MEM2 as reserved.
 - Only on the Wii, allow ioremap to be used on reserved memory.

This hack, however, doesn't account for the "resource"-based API in
kernel/resource.c, because __request_region performs its own checks.

Extend the hack to kernel/resource.c, to allow more drivers to allocate
their MMIO regions on the Wii.

Signed-off-by: Jonathan Neuschäfer 
Cc: Albert Herranz 
---

v2:
- CC Albert Herranz, who introduced this hack in 2009.
---
 kernel/resource.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 54ba6de3757c..bb3d329329da 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1134,6 +1134,24 @@ resource_size_t resource_alignment(struct resource *res)
 
 static DECLARE_WAIT_QUEUE_HEAD(muxed_resource_wait);
 
+/*
+ * On some ppc32 platforms (Nintendo Wii), reserved memory is used to work
+ * around the fact that Linux doesn't support discontiguous memory (all memory
+ * is treated as one large area with holes punched in it), and reserved memory
+ * is allowed to be allocated.
+ */
+#ifdef CONFIG_PPC32
+static bool conflict_ignored(struct resource *conflict)
+{
+   extern int __allow_ioremap_reserved;
+
+   return __allow_ioremap_reserved &&
+   (conflict->flags & IORESOURCE_SYSRAM);
+}
+#else
+static bool conflict_ignored(struct resource *conflict) { return false; }
+#endif
+
 /**
  * __request_region - create a new busy resource region
  * @parent: parent resource descriptor
@@ -1166,8 +1184,9 @@ struct resource * __request_region(struct resource 
*parent,
res->desc = parent->desc;
 
conflict = __request_resource(parent, res);
-   if (!conflict)
+   if (!conflict || conflict_ignored(conflict))
break;
+
if (conflict != parent) {
if (!(conflict->flags & IORESOURCE_BUSY)) {
parent = conflict;
-- 
2.15.1

[PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack

[Jonathan Neuschäfer]

On the Nintendo Wii, there are two ranges of physical memory, and MMIO
in between, but Linux on ppc32 doesn't support discontiguous memory.
Therefore a hack was introduced in commit c5df7f775148 ("powerpc: allow
ioremap within reserved memory regions") and commit de32400dd26e ("wii:
use both mem1 and mem2 as ram"):

 - Treat the area from the start of the first memory area (MEM1) to the
   end of the second (MEM2) as one big memory area, but mark the part
   that doesn't belong to MEM1 or MEM2 as reserved.
 - Only on the Wii, allow ioremap to be used on reserved memory.

This hack, however, doesn't account for the "resource"-based API in
kernel/resource.c, because __request_region performs its own checks.

Extend the hack to kernel/resource.c, to allow more drivers to allocate
their MMIO regions on the Wii.

Signed-off-by: Jonathan Neuschäfer 
Cc: Albert Herranz 
---

v2:
- CC Albert Herranz, who introduced this hack in 2009.
---
 kernel/resource.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 54ba6de3757c..bb3d329329da 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1134,6 +1134,24 @@ resource_size_t resource_alignment(struct resource *res)
 
 static DECLARE_WAIT_QUEUE_HEAD(muxed_resource_wait);
 
+/*
+ * On some ppc32 platforms (Nintendo Wii), reserved memory is used to work
+ * around the fact that Linux doesn't support discontiguous memory (all memory
+ * is treated as one large area with holes punched in it), and reserved memory
+ * is allowed to be allocated.
+ */
+#ifdef CONFIG_PPC32
+static bool conflict_ignored(struct resource *conflict)
+{
+   extern int __allow_ioremap_reserved;
+
+   return __allow_ioremap_reserved &&
+   (conflict->flags & IORESOURCE_SYSRAM);
+}
+#else
+static bool conflict_ignored(struct resource *conflict) { return false; }
+#endif
+
 /**
  * __request_region - create a new busy resource region
  * @parent: parent resource descriptor
@@ -1166,8 +1184,9 @@ struct resource * __request_region(struct resource 
*parent,
res->desc = parent->desc;
 
conflict = __request_resource(parent, res);
-   if (!conflict)
+   if (!conflict || conflict_ignored(conflict))
break;
+
if (conflict != parent) {
if (!(conflict->flags & IORESOURCE_BUSY)) {
parent = conflict;
-- 
2.15.1

[PATCH v2 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller

[Jonathan Neuschäfer]

The Nintendo Wii game console has a GPIO controller, which is used for
the optical disk slot LED, buttons, poweroff, etc. This patch adds a
binding for this GPIO controller.

Signed-off-by: Jonathan Neuschäfer 
Reviewed-by: Rob Herring 
---

v2:
- Drop the leading zero in the example, as suggested by Rob Herring
- Add some text to the commit message, as suggested by Linus Walleij
---
 .../bindings/gpio/nintendo,hollywood-gpio.txt  | 27 ++
 .../devicetree/bindings/powerpc/nintendo/wii.txt   |  9 +---
 2 files changed, 28 insertions(+), 8 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt

diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt 
b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
new file mode 100644
index ..20fc72d9e61e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
@@ -0,0 +1,27 @@
+Nintendo Wii (Hollywood) GPIO controller
+
+Required properties:
+- compatible: "nintendo,hollywood-gpio
+- reg: Physical base address and length of the controller's registers.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be <2>. The first cell is the pin number and the
+  second cell is used to specify optional parameters:
+   - bit 0 specifies polarity (0 for normal, 1 for inverted).
+
+Optional properties:
+- ngpios: see Documentation/devicetree/bindings/gpio/gpio.txt
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- interrupts: Interrupt specifier for the controller's Broadway (PowerPC)
+  interrupt.
+- interrupt-parent: phandle of the parent interrupt controller.
+
+Example:
+
+   GPIO: gpio@d8000c0 {
+   #gpio-cells = <2>;
+   compatible = "nintendo,hollywood-gpio";
+   reg = <0x0d8000c0 0x40>;
+   gpio-controller;
+   ngpios = <24>;
+   }
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt 
b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index 36afa322b04b..a3dc4b9fa11a 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -152,14 +152,7 @@ Nintendo Wii device tree
 
 1.l) The General Purpose I/O (GPIO) controller node
 
-  Represents the dual access 32 GPIO controller interface.
-
-  Required properties:
-
-  - #gpio-cells : <2>
-  - compatible : should be "nintendo,hollywood-gpio"
-  - reg : should contain the IPC registers location and length
-  - gpio-controller
+  see Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
 
 1.m) The control node
 
-- 
2.15.1

[PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii

[Jonathan Neuschäfer]

The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
that supports a configurable number of pins (up to 32), interrupts, and
some special mechanisms to share the controller between the system's
security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
not supported.

This patch adds a basic driver for this GPIO controller. Interrupt
support will come in a later patch.

This patch is based on code developed by Albert Herranz and the GameCube
Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
has grown quite dissimilar.

Signed-off-by: Jonathan Neuschäfer 
Cc: Albert Herranz 
Cc: Segher Boessenkool 
---

v2:
- Change hlwd_gpio_driver.driver.name to "gpio-hlwd" to match the
  filename (was "hlwd_gpio")
- Remove unnecessary include of linux/of_gpio.h, as suggested by Linus
  Walleij.
- Add struct device pointer to context struct to make it possible to use
  dev_info(hlwd->dev, "..."), as suggested by Linus Walleij
- Use the GPIO_GENERIC library to reduce code size, as suggested by
  Linus Walleij
- Use iowrite32be instead of __raw_writel for big-endian MMIO access, as
  suggested by Linus Walleij
- Remove commit message paragraph suggesting to diff against the
  original driver, because it's so different now
---
 drivers/gpio/Kconfig |   9 
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-hlwd.c | 123 +++
 3 files changed, 133 insertions(+)
 create mode 100644 drivers/gpio/gpio-hlwd.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d6a8e851ad13..47606dfe06cc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -229,6 +229,15 @@ config GPIO_GRGPIO
  Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
  VHDL IP core library.
 
+config GPIO_HLWD
+   tristate "Nintendo Wii (Hollywood) GPIO"
+   depends on OF_GPIO
+   select GPIO_GENERIC
+   help
+ Select this to support the GPIO controller of the Nintendo Wii.
+
+ If unsure, say N.
+
 config GPIO_ICH
tristate "Intel ICH GPIO"
depends on PCI && X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4bc24febb889..492f62d0eb59 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_GPIO_FTGPIO010)  += gpio-ftgpio010.o
 obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
 obj-$(CONFIG_GPIO_GPIO_MM) += gpio-gpio-mm.o
 obj-$(CONFIG_GPIO_GRGPIO)  += gpio-grgpio.o
+obj-$(CONFIG_GPIO_HLWD)+= gpio-hlwd.o
 obj-$(CONFIG_HTC_EGPIO)+= gpio-htc-egpio.o
 obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
 obj-$(CONFIG_GPIO_INGENIC) += gpio-ingenic.o
diff --git a/drivers/gpio/gpio-hlwd.c b/drivers/gpio/gpio-hlwd.c
new file mode 100644
index ..cf3f05a1621c
--- /dev/null
+++ b/drivers/gpio/gpio-hlwd.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2008-2009 The GameCube Linux Team
+// Copyright (C) 2008,2009 Albert Herranz
+// Copyright (C) 2017-2018 Jonathan Neuschäfer
+//
+// Nintendo Wii (Hollywood) GPIO driver
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Register names and offsets courtesy of WiiBrew:
+ * https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs
+ *
+ * Note that for most registers, there are two versions:
+ * - HW_GPIOB_* Is always accessible by the Broadway PowerPC core, but does
+ *   always give access to all GPIO lines
+ * - HW_GPIO_* Is only accessible by the Broadway PowerPC code if the memory
+ *   firewall (AHBPROT) in the Hollywood chipset has been configured to allow
+ *   such access.
+ *
+ * The ownership of each GPIO line can be configured in the HW_GPIO_OWNER
+ * register: A one bit configures the line for access via the HW_GPIOB_*
+ * registers, a zero bit indicates access via HW_GPIO_*. This driver uses
+ * HW_GPIOB_*.
+ */
+#define HW_GPIOB_OUT   0x00
+#define HW_GPIOB_DIR   0x04
+#define HW_GPIOB_IN0x08
+#define HW_GPIOB_INTLVL0x0c
+#define HW_GPIOB_INTFLAG   0x10
+#define HW_GPIOB_INTMASK   0x14
+#define HW_GPIOB_INMIR 0x18
+#define HW_GPIO_ENABLE 0x1c
+#define HW_GPIO_OUT0x20
+#define HW_GPIO_DIR0x24
+#define HW_GPIO_IN 0x28
+#define HW_GPIO_INTLVL 0x2c
+#define HW_GPIO_INTFLAG0x30
+#define HW_GPIO_INTMASK0x34
+#define HW_GPIO_INMIR  0x38
+#define HW_GPIO_OWNER  0x3c
+
+
+struct hlwd_gpio {
+   struct gpio_chip gpioc;
+   void __iomem *regs;
+   struct device *dev;
+};
+
+static int hlwd_gpio_probe(struct platform_device *pdev)
+{
+   struct hlwd_gpio *hlwd;
+   struct resource *regs_resource;
+   u32 ngpios;
+   int res;
+
+   hlwd = 

[PATCH v2 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller

[Jonathan Neuschäfer]

The Nintendo Wii game console has a GPIO controller, which is used for
the optical disk slot LED, buttons, poweroff, etc. This patch adds a
binding for this GPIO controller.

Signed-off-by: Jonathan Neuschäfer 
Reviewed-by: Rob Herring 
---

v2:
- Drop the leading zero in the example, as suggested by Rob Herring
- Add some text to the commit message, as suggested by Linus Walleij
---
 .../bindings/gpio/nintendo,hollywood-gpio.txt  | 27 ++
 .../devicetree/bindings/powerpc/nintendo/wii.txt   |  9 +---
 2 files changed, 28 insertions(+), 8 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt

diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt 
b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
new file mode 100644
index ..20fc72d9e61e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
@@ -0,0 +1,27 @@
+Nintendo Wii (Hollywood) GPIO controller
+
+Required properties:
+- compatible: "nintendo,hollywood-gpio
+- reg: Physical base address and length of the controller's registers.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be <2>. The first cell is the pin number and the
+  second cell is used to specify optional parameters:
+   - bit 0 specifies polarity (0 for normal, 1 for inverted).
+
+Optional properties:
+- ngpios: see Documentation/devicetree/bindings/gpio/gpio.txt
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- interrupts: Interrupt specifier for the controller's Broadway (PowerPC)
+  interrupt.
+- interrupt-parent: phandle of the parent interrupt controller.
+
+Example:
+
+   GPIO: gpio@d8000c0 {
+   #gpio-cells = <2>;
+   compatible = "nintendo,hollywood-gpio";
+   reg = <0x0d8000c0 0x40>;
+   gpio-controller;
+   ngpios = <24>;
+   }
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt 
b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index 36afa322b04b..a3dc4b9fa11a 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -152,14 +152,7 @@ Nintendo Wii device tree
 
 1.l) The General Purpose I/O (GPIO) controller node
 
-  Represents the dual access 32 GPIO controller interface.
-
-  Required properties:
-
-  - #gpio-cells : <2>
-  - compatible : should be "nintendo,hollywood-gpio"
-  - reg : should contain the IPC registers location and length
-  - gpio-controller
+  see Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
 
 1.m) The control node
 
-- 
2.15.1

[PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii

[Jonathan Neuschäfer]

The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
that supports a configurable number of pins (up to 32), interrupts, and
some special mechanisms to share the controller between the system's
security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
not supported.

This patch adds a basic driver for this GPIO controller. Interrupt
support will come in a later patch.

This patch is based on code developed by Albert Herranz and the GameCube
Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
has grown quite dissimilar.

Signed-off-by: Jonathan Neuschäfer 
Cc: Albert Herranz 
Cc: Segher Boessenkool 
---

v2:
- Change hlwd_gpio_driver.driver.name to "gpio-hlwd" to match the
  filename (was "hlwd_gpio")
- Remove unnecessary include of linux/of_gpio.h, as suggested by Linus
  Walleij.
- Add struct device pointer to context struct to make it possible to use
  dev_info(hlwd->dev, "..."), as suggested by Linus Walleij
- Use the GPIO_GENERIC library to reduce code size, as suggested by
  Linus Walleij
- Use iowrite32be instead of __raw_writel for big-endian MMIO access, as
  suggested by Linus Walleij
- Remove commit message paragraph suggesting to diff against the
  original driver, because it's so different now
---
 drivers/gpio/Kconfig |   9 
 drivers/gpio/Makefile|   1 +
 drivers/gpio/gpio-hlwd.c | 123 +++
 3 files changed, 133 insertions(+)
 create mode 100644 drivers/gpio/gpio-hlwd.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d6a8e851ad13..47606dfe06cc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -229,6 +229,15 @@ config GPIO_GRGPIO
  Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
  VHDL IP core library.
 
+config GPIO_HLWD
+   tristate "Nintendo Wii (Hollywood) GPIO"
+   depends on OF_GPIO
+   select GPIO_GENERIC
+   help
+ Select this to support the GPIO controller of the Nintendo Wii.
+
+ If unsure, say N.
+
 config GPIO_ICH
tristate "Intel ICH GPIO"
depends on PCI && X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4bc24febb889..492f62d0eb59 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_GPIO_FTGPIO010)  += gpio-ftgpio010.o
 obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
 obj-$(CONFIG_GPIO_GPIO_MM) += gpio-gpio-mm.o
 obj-$(CONFIG_GPIO_GRGPIO)  += gpio-grgpio.o
+obj-$(CONFIG_GPIO_HLWD)+= gpio-hlwd.o
 obj-$(CONFIG_HTC_EGPIO)+= gpio-htc-egpio.o
 obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
 obj-$(CONFIG_GPIO_INGENIC) += gpio-ingenic.o
diff --git a/drivers/gpio/gpio-hlwd.c b/drivers/gpio/gpio-hlwd.c
new file mode 100644
index ..cf3f05a1621c
--- /dev/null
+++ b/drivers/gpio/gpio-hlwd.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2008-2009 The GameCube Linux Team
+// Copyright (C) 2008,2009 Albert Herranz
+// Copyright (C) 2017-2018 Jonathan Neuschäfer
+//
+// Nintendo Wii (Hollywood) GPIO driver
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Register names and offsets courtesy of WiiBrew:
+ * https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs
+ *
+ * Note that for most registers, there are two versions:
+ * - HW_GPIOB_* Is always accessible by the Broadway PowerPC core, but does
+ *   always give access to all GPIO lines
+ * - HW_GPIO_* Is only accessible by the Broadway PowerPC code if the memory
+ *   firewall (AHBPROT) in the Hollywood chipset has been configured to allow
+ *   such access.
+ *
+ * The ownership of each GPIO line can be configured in the HW_GPIO_OWNER
+ * register: A one bit configures the line for access via the HW_GPIOB_*
+ * registers, a zero bit indicates access via HW_GPIO_*. This driver uses
+ * HW_GPIOB_*.
+ */
+#define HW_GPIOB_OUT   0x00
+#define HW_GPIOB_DIR   0x04
+#define HW_GPIOB_IN0x08
+#define HW_GPIOB_INTLVL0x0c
+#define HW_GPIOB_INTFLAG   0x10
+#define HW_GPIOB_INTMASK   0x14
+#define HW_GPIOB_INMIR 0x18
+#define HW_GPIO_ENABLE 0x1c
+#define HW_GPIO_OUT0x20
+#define HW_GPIO_DIR0x24
+#define HW_GPIO_IN 0x28
+#define HW_GPIO_INTLVL 0x2c
+#define HW_GPIO_INTFLAG0x30
+#define HW_GPIO_INTMASK0x34
+#define HW_GPIO_INMIR  0x38
+#define HW_GPIO_OWNER  0x3c
+
+
+struct hlwd_gpio {
+   struct gpio_chip gpioc;
+   void __iomem *regs;
+   struct device *dev;
+};
+
+static int hlwd_gpio_probe(struct platform_device *pdev)
+{
+   struct hlwd_gpio *hlwd;
+   struct resource *regs_resource;
+   u32 ngpios;
+   int res;
+
+   hlwd = devm_kzalloc(>dev, sizeof(*hlwd), GFP_KERNEL);
+   if (!hlwd)
+   return 

[PATCH v2 2/6] powerpc: wii: Explicitly configure GPIO owner for poweroff pin

[Jonathan Neuschäfer]

The Hollywood chipset's GPIO controller has two sets of registers: One
for access by the PowerPC CPU, and one for access by the ARM coprocessor
(but both are accessible from the PPC because the memory firewall
(AHBPROT) is usually disabled when booting Linux, today).

The wii_power_off function currently assumes that the poweroff GPIO pin
is configured for use via the ARM side, but the upcoming GPIO driver
configures all pins for use via the PPC side, breaking poweroff.

Configure the owner register explicitly in wii_power_off to make
wii_power_off work with and without the new GPIO driver.

I think the Wii can be switched to the generic gpio-poweroff driver,
after the GPIO driver is merged.

Signed-off-by: Jonathan Neuschäfer 
---

v2:
- no change
---
 arch/powerpc/platforms/embedded6xx/wii.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/platforms/embedded6xx/wii.c 
b/arch/powerpc/platforms/embedded6xx/wii.c
index 79a1fe54ebc9..6e6db1e16d71 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -45,6 +45,7 @@
 #define HW_GPIO_BASE(idx)  (idx * 0x20)
 #define HW_GPIO_OUT(idx)   (HW_GPIO_BASE(idx) + 0)
 #define HW_GPIO_DIR(idx)   (HW_GPIO_BASE(idx) + 4)
+#define HW_GPIO_OWNER  (HW_GPIO_BASE(1) + 0x1c)
 
 #define HW_GPIO_SHUTDOWN   (1<<1)
 #define HW_GPIO_SLOT_LED   (1<<5)
@@ -177,6 +178,12 @@ static void wii_power_off(void)
local_irq_disable();
 
if (hw_gpio) {
+   /*
+* set the owner of the shutdown pin to ARM, because it is
+* accessed through the registers for the ARM, below
+*/
+   clrbits32(hw_gpio + HW_GPIO_OWNER, HW_GPIO_SHUTDOWN);
+
/* make sure that the poweroff GPIO is configured as output */
setbits32(hw_gpio + HW_GPIO_DIR(1), HW_GPIO_SHUTDOWN);
 
-- 
2.15.1

[PATCH v2 0/6] Nintendo Wii GPIO driver

[Jonathan Neuschäfer]

This series adds a driver for the GPIO controller used in the Nintendo
Wii game console.

The driver itself, and the related devicetree work should be pretty
uncontroversial, but due to the system architecture of the Wii, I also
had to extend an old resource allocation hack to kernel/resource.c: On
the Wii, there are two separate RAM ranges, with MMIO right in the
middle, but AFAIK, Linux on PPC32 doesn't support discontiguous memory
properly. So the hack is to allocate one big RAM range with a hole
(marked as reserved memory) for MMIO in the middle.

Because this series touches different subsystems (GPIO, DT, core
resource management), I guess it should be picked up patch-by-patch by
the different maintainers.

The main difference between v2 and the previous version is that I
rewrote the driver on top of the GPIO_GENERIC library, saving 60 lines
of code.

Jonathan Neuschäfer (6):
  resource: Extend the PPC32 reserved memory hack
  powerpc: wii: Explicitly configure GPIO owner for poweroff pin
  gpio: Add GPIO driver for Nintendo Wii
  dt-bindings: gpio: Add binding for Wii GPIO controller
  powerpc: wii.dts: Add ngpios property
  powerpc: wii.dts: Add GPIO line names

 .../bindings/gpio/nintendo,hollywood-gpio.txt  |  27 +
 .../devicetree/bindings/powerpc/nintendo/wii.txt   |   9 +-
 arch/powerpc/boot/dts/wii.dts  |   9 ++
 arch/powerpc/platforms/embedded6xx/wii.c   |   7 ++
 drivers/gpio/Kconfig   |   9 ++
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-hlwd.c   | 123 +
 kernel/resource.c  |  21 +++-
 8 files changed, 197 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
 create mode 100644 drivers/gpio/gpio-hlwd.c

-- 
2.15.1

[PATCH v2 2/6] powerpc: wii: Explicitly configure GPIO owner for poweroff pin

[Jonathan Neuschäfer]

The Hollywood chipset's GPIO controller has two sets of registers: One
for access by the PowerPC CPU, and one for access by the ARM coprocessor
(but both are accessible from the PPC because the memory firewall
(AHBPROT) is usually disabled when booting Linux, today).

The wii_power_off function currently assumes that the poweroff GPIO pin
is configured for use via the ARM side, but the upcoming GPIO driver
configures all pins for use via the PPC side, breaking poweroff.

Configure the owner register explicitly in wii_power_off to make
wii_power_off work with and without the new GPIO driver.

I think the Wii can be switched to the generic gpio-poweroff driver,
after the GPIO driver is merged.

Signed-off-by: Jonathan Neuschäfer 
---

v2:
- no change
---
 arch/powerpc/platforms/embedded6xx/wii.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/powerpc/platforms/embedded6xx/wii.c 
b/arch/powerpc/platforms/embedded6xx/wii.c
index 79a1fe54ebc9..6e6db1e16d71 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -45,6 +45,7 @@
 #define HW_GPIO_BASE(idx)  (idx * 0x20)
 #define HW_GPIO_OUT(idx)   (HW_GPIO_BASE(idx) + 0)
 #define HW_GPIO_DIR(idx)   (HW_GPIO_BASE(idx) + 4)
+#define HW_GPIO_OWNER  (HW_GPIO_BASE(1) + 0x1c)
 
 #define HW_GPIO_SHUTDOWN   (1<<1)
 #define HW_GPIO_SLOT_LED   (1<<5)
@@ -177,6 +178,12 @@ static void wii_power_off(void)
local_irq_disable();
 
if (hw_gpio) {
+   /*
+* set the owner of the shutdown pin to ARM, because it is
+* accessed through the registers for the ARM, below
+*/
+   clrbits32(hw_gpio + HW_GPIO_OWNER, HW_GPIO_SHUTDOWN);
+
/* make sure that the poweroff GPIO is configured as output */
setbits32(hw_gpio + HW_GPIO_DIR(1), HW_GPIO_SHUTDOWN);
 
-- 
2.15.1

[PATCH v2 0/6] Nintendo Wii GPIO driver

[Jonathan Neuschäfer]

This series adds a driver for the GPIO controller used in the Nintendo
Wii game console.

The driver itself, and the related devicetree work should be pretty
uncontroversial, but due to the system architecture of the Wii, I also
had to extend an old resource allocation hack to kernel/resource.c: On
the Wii, there are two separate RAM ranges, with MMIO right in the
middle, but AFAIK, Linux on PPC32 doesn't support discontiguous memory
properly. So the hack is to allocate one big RAM range with a hole
(marked as reserved memory) for MMIO in the middle.

Because this series touches different subsystems (GPIO, DT, core
resource management), I guess it should be picked up patch-by-patch by
the different maintainers.

The main difference between v2 and the previous version is that I
rewrote the driver on top of the GPIO_GENERIC library, saving 60 lines
of code.

Jonathan Neuschäfer (6):
  resource: Extend the PPC32 reserved memory hack
  powerpc: wii: Explicitly configure GPIO owner for poweroff pin
  gpio: Add GPIO driver for Nintendo Wii
  dt-bindings: gpio: Add binding for Wii GPIO controller
  powerpc: wii.dts: Add ngpios property
  powerpc: wii.dts: Add GPIO line names

 .../bindings/gpio/nintendo,hollywood-gpio.txt  |  27 +
 .../devicetree/bindings/powerpc/nintendo/wii.txt   |   9 +-
 arch/powerpc/boot/dts/wii.dts  |   9 ++
 arch/powerpc/platforms/embedded6xx/wii.c   |   7 ++
 drivers/gpio/Kconfig   |   9 ++
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-hlwd.c   | 123 +
 kernel/resource.c  |  21 +++-
 8 files changed, 197 insertions(+), 9 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
 create mode 100644 drivers/gpio/gpio-hlwd.c

-- 
2.15.1

[PATCH v3] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

[Suravee Suthikulpanit]

VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which requires
IOTLB flushing for every unmapping. This results in large IOTLB flushing
overhead when handling pass-through devices has a large number of mapped
IOVAs (e.g. GPUs). This could also cause IOTLB invalidate time-out issue
on AMD IOMMU with certain dGPUs.

This can be avoided by using the new IOTLB flushing interface.

Cc: Alex Williamson 
Cc: Joerg Roedel 
Signed-off-by: Suravee Suthikulpanit 
---
Changes from V2: (https://lkml.org/lkml/2017/12/27/43)

  * In vfio_unmap_unpin(), fallback to use slow IOTLB flush
when fast IOTLB flush fails (per Alex).

  * Do not adopt fast IOTLB flush in map_try_harder().

  * Submit VFIO and AMD IOMMU patches separately.

 drivers/vfio/vfio_iommu_type1.c | 98 +
 1 file changed, 98 insertions(+)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index e30e29a..5c40b00 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -102,6 +102,13 @@ struct vfio_pfn {
atomic_tref_count;
 };
 
+struct vfio_regions {
+   struct list_head list;
+   dma_addr_t iova;
+   phys_addr_t phys;
+   size_t len;
+};
+
 #define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)\
(!list_empty(>domain_list))
 
@@ -479,6 +486,36 @@ static long vfio_unpin_pages_remote(struct vfio_dma *dma, 
dma_addr_t iova,
return unlocked;
 }
 
+/*
+ * Generally, VFIO needs to unpin remote pages after each IOTLB flush.
+ * Therefore, when using IOTLB flush sync interface, VFIO need to keep track
+ * of these regions (currently using a list).
+ *
+ * This value specifies maximum number of regions for each IOTLB flush sync.
+ */
+#define VFIO_IOMMU_TLB_SYNC_MAX512
+
+static long vfio_sync_unpin(struct vfio_dma *dma, struct vfio_domain *domain,
+   struct list_head *regions)
+{
+   long unlocked = 0;
+   struct vfio_regions *entry, *next;
+
+   iommu_tlb_sync(domain->domain);
+
+   list_for_each_entry_safe(entry, next, regions, list) {
+   unlocked += vfio_unpin_pages_remote(dma,
+   entry->iova,
+   entry->phys >> PAGE_SHIFT,
+   entry->len >> PAGE_SHIFT,
+   false);
+   list_del(>list);
+   kfree(entry);
+   }
+   cond_resched();
+   return unlocked;
+}
+
 static int vfio_pin_page_external(struct vfio_dma *dma, unsigned long vaddr,
  unsigned long *pfn_base, bool do_accounting)
 {
@@ -648,12 +685,40 @@ static int vfio_iommu_type1_unpin_pages(void *iommu_data,
return i > npage ? npage : (i > 0 ? i : -EINVAL);
 }
 
+static size_t try_unmap_unpin_fast(struct vfio_domain *domain, dma_addr_t iova,
+  size_t len, phys_addr_t phys,
+  struct list_head *unmapped_regions)
+{
+   struct vfio_regions *entry;
+   size_t unmapped;
+
+   entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+   if (!entry)
+   return -ENOMEM;
+
+   unmapped = iommu_unmap_fast(domain->domain, iova, len);
+   if (WARN_ON(!unmapped)) {
+   kfree(entry);
+   return -EINVAL;
+   }
+
+   iommu_tlb_range_add(domain->domain, iova, unmapped);
+   entry->iova = iova;
+   entry->phys = phys;
+   entry->len  = unmapped;
+   list_add_tail(>list, unmapped_regions);
+   return unmapped;
+}
+
 static long vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma,
 bool do_accounting)
 {
dma_addr_t iova = dma->iova, end = dma->iova + dma->size;
struct vfio_domain *domain, *d;
+   struct list_head unmapped_regions;
+   bool use_fastpath = true;
long unlocked = 0;
+   int cnt = 0;
 
if (!dma->size)
return 0;
@@ -661,6 +726,8 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu, 
struct vfio_dma *dma,
if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu))
return 0;
 
+   INIT_LIST_HEAD(_regions);
+
/*
 * We use the IOMMU to track the physical addresses, otherwise we'd
 * need a much more complicated tracking system.  Unfortunately that
@@ -698,6 +765,33 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu, 
struct vfio_dma *dma,
break;
}
 
+   /*
+* First, try to use fast unmap/unpin. In case of failure,
+* sync upto the current point, and continue the slow
+* unmap/unpin path.
+*/
+   

[PATCH v3] vfio/type1: Adopt fast IOTLB flush interface when unmap IOVAs

[Suravee Suthikulpanit]

VFIO IOMMU type1 currently upmaps IOVA pages synchronously, which requires
IOTLB flushing for every unmapping. This results in large IOTLB flushing
overhead when handling pass-through devices has a large number of mapped
IOVAs (e.g. GPUs). This could also cause IOTLB invalidate time-out issue
on AMD IOMMU with certain dGPUs.

This can be avoided by using the new IOTLB flushing interface.

Cc: Alex Williamson 
Cc: Joerg Roedel 
Signed-off-by: Suravee Suthikulpanit 
---
Changes from V2: (https://lkml.org/lkml/2017/12/27/43)

  * In vfio_unmap_unpin(), fallback to use slow IOTLB flush
when fast IOTLB flush fails (per Alex).

  * Do not adopt fast IOTLB flush in map_try_harder().

  * Submit VFIO and AMD IOMMU patches separately.

 drivers/vfio/vfio_iommu_type1.c | 98 +
 1 file changed, 98 insertions(+)

diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index e30e29a..5c40b00 100644
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -102,6 +102,13 @@ struct vfio_pfn {
atomic_tref_count;
 };
 
+struct vfio_regions {
+   struct list_head list;
+   dma_addr_t iova;
+   phys_addr_t phys;
+   size_t len;
+};
+
 #define IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu)\
(!list_empty(>domain_list))
 
@@ -479,6 +486,36 @@ static long vfio_unpin_pages_remote(struct vfio_dma *dma, 
dma_addr_t iova,
return unlocked;
 }
 
+/*
+ * Generally, VFIO needs to unpin remote pages after each IOTLB flush.
+ * Therefore, when using IOTLB flush sync interface, VFIO need to keep track
+ * of these regions (currently using a list).
+ *
+ * This value specifies maximum number of regions for each IOTLB flush sync.
+ */
+#define VFIO_IOMMU_TLB_SYNC_MAX512
+
+static long vfio_sync_unpin(struct vfio_dma *dma, struct vfio_domain *domain,
+   struct list_head *regions)
+{
+   long unlocked = 0;
+   struct vfio_regions *entry, *next;
+
+   iommu_tlb_sync(domain->domain);
+
+   list_for_each_entry_safe(entry, next, regions, list) {
+   unlocked += vfio_unpin_pages_remote(dma,
+   entry->iova,
+   entry->phys >> PAGE_SHIFT,
+   entry->len >> PAGE_SHIFT,
+   false);
+   list_del(>list);
+   kfree(entry);
+   }
+   cond_resched();
+   return unlocked;
+}
+
 static int vfio_pin_page_external(struct vfio_dma *dma, unsigned long vaddr,
  unsigned long *pfn_base, bool do_accounting)
 {
@@ -648,12 +685,40 @@ static int vfio_iommu_type1_unpin_pages(void *iommu_data,
return i > npage ? npage : (i > 0 ? i : -EINVAL);
 }
 
+static size_t try_unmap_unpin_fast(struct vfio_domain *domain, dma_addr_t iova,
+  size_t len, phys_addr_t phys,
+  struct list_head *unmapped_regions)
+{
+   struct vfio_regions *entry;
+   size_t unmapped;
+
+   entry = kzalloc(sizeof(*entry), GFP_KERNEL);
+   if (!entry)
+   return -ENOMEM;
+
+   unmapped = iommu_unmap_fast(domain->domain, iova, len);
+   if (WARN_ON(!unmapped)) {
+   kfree(entry);
+   return -EINVAL;
+   }
+
+   iommu_tlb_range_add(domain->domain, iova, unmapped);
+   entry->iova = iova;
+   entry->phys = phys;
+   entry->len  = unmapped;
+   list_add_tail(>list, unmapped_regions);
+   return unmapped;
+}
+
 static long vfio_unmap_unpin(struct vfio_iommu *iommu, struct vfio_dma *dma,
 bool do_accounting)
 {
dma_addr_t iova = dma->iova, end = dma->iova + dma->size;
struct vfio_domain *domain, *d;
+   struct list_head unmapped_regions;
+   bool use_fastpath = true;
long unlocked = 0;
+   int cnt = 0;
 
if (!dma->size)
return 0;
@@ -661,6 +726,8 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu, 
struct vfio_dma *dma,
if (!IS_IOMMU_CAP_DOMAIN_IN_CONTAINER(iommu))
return 0;
 
+   INIT_LIST_HEAD(_regions);
+
/*
 * We use the IOMMU to track the physical addresses, otherwise we'd
 * need a much more complicated tracking system.  Unfortunately that
@@ -698,6 +765,33 @@ static long vfio_unmap_unpin(struct vfio_iommu *iommu, 
struct vfio_dma *dma,
break;
}
 
+   /*
+* First, try to use fast unmap/unpin. In case of failure,
+* sync upto the current point, and continue the slow
+* unmap/unpin path.
+*/
+   if (use_fastpath) {
+   unmapped = 

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Randy,

On 01/22/2018 10:15 AM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we
want to control here, there might be some clocks only be needed when
accessing mmu registers.

but i'm not very sure about that, will confirm it with Simon Xue.


confirmed with Simon, there might be some iommus don't have a pd, and 
the CONFIG_PM could be disabled.


so it might be better to control clocks in iommu driver itself.

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Randy,

On 01/22/2018 10:15 AM, JeffyChen wrote:

Hi Randy,

On 01/22/2018 09:18 AM, Randy Li wrote:



Also the power domain driver could manage the clocks as well, I would
suggest to use pm_runtime_*.


actually the clocks required by pm domain may not be the same as what we
want to control here, there might be some clocks only be needed when
accessing mmu registers.

but i'm not very sure about that, will confirm it with Simon Xue.


confirmed with Simon, there might be some iommus don't have a pd, and 
the CONFIG_PM could be disabled.


so it might be better to control clocks in iommu driver itself.

Re: [RFC PATCH v2 2/2] iommu/amd: Add support for fast IOTLB flushing

[Suravee Suthikulpanit]

Hi Joerg,

Do you have any feedback regarding this patch for AMD IOMMU? I'm re-sending the 
patch 1/2
separately per Alex's suggestion.

Thanks,
Suravee

On 12/27/17 4:20 PM, Suravee Suthikulpanit wrote:

Implement the newly added IOTLB flushing interface for AMD IOMMU.

Signed-off-by: Suravee Suthikulpanit 
---
  drivers/iommu/amd_iommu.c   | 73 -
  drivers/iommu/amd_iommu_init.c  |  7 
  drivers/iommu/amd_iommu_types.h |  7 
  3 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 7d5eb00..42fe365 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -129,6 +129,12 @@ struct dma_ops_domain {
  static struct iova_domain reserved_iova_ranges;
  static struct lock_class_key reserved_rbtree_key;
  
+struct amd_iommu_flush_entries {

+   struct list_head list;
+   unsigned long iova;
+   size_t size;
+};
+
  /
   *
   * Helper functions
@@ -3043,7 +3049,6 @@ static size_t amd_iommu_unmap(struct iommu_domain *dom, 
unsigned long iova,
unmap_size = iommu_unmap_page(domain, iova, page_size);
mutex_unlock(>api_lock);
  
-	domain_flush_tlb_pde(domain);

domain_flush_complete(domain);
  
  	return unmap_size;

@@ -3163,6 +3168,69 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
return dev_data->defer_attach;
  }
  
+static void amd_iommu_flush_iotlb_all(struct iommu_domain *domain)

+{
+   struct protection_domain *dom = to_pdomain(domain);
+
+   domain_flush_tlb_pde(dom);
+}
+
+static void amd_iommu_iotlb_range_add(struct iommu_domain *domain,
+ unsigned long iova, size_t size)
+{
+   struct amd_iommu_flush_entries *entry, *p;
+   unsigned long flags;
+   bool found = false;
+
+   spin_lock_irqsave(_iommu_flush_list_lock, flags);
+   list_for_each_entry(p, _iommu_flush_list, list) {
+   if (iova != p->iova)
+   continue;
+
+   if (size > p->size) {
+   p->size = size;
+   pr_debug("%s: update range: iova=%#lx, size = %#lx\n",
+__func__, p->iova, p->size);
+   }
+   found = true;
+   break;
+   }
+
+   if (!found) {
+   entry = kzalloc(sizeof(struct amd_iommu_flush_entries),
+   GFP_KERNEL);
+   if (entry) {
+   pr_debug("%s: new range: iova=%lx, size=%#lx\n",
+__func__, iova, size);
+
+   entry->iova = iova;
+   entry->size = size;
+   list_add(>list, _iommu_flush_list);
+   }
+   }
+   spin_unlock_irqrestore(_iommu_flush_list_lock, flags);
+}
+
+static void amd_iommu_iotlb_sync(struct iommu_domain *domain)
+{
+   struct protection_domain *pdom = to_pdomain(domain);
+   struct amd_iommu_flush_entries *entry, *next;
+   unsigned long flags;
+
+   /* Note:
+* Currently, IOMMU driver just flushes the whole IO/TLB for
+* a given domain. So, just remove entries from the list here.
+*/
+   spin_lock_irqsave(_iommu_flush_list_lock, flags);
+   list_for_each_entry_safe(entry, next, _iommu_flush_list, list) {
+   list_del(>list);
+   kfree(entry);
+   }
+   spin_unlock_irqrestore(_iommu_flush_list_lock, flags);
+
+   domain_flush_tlb_pde(pdom);
+}
+
  const struct iommu_ops amd_iommu_ops = {
.capable = amd_iommu_capable,
.domain_alloc = amd_iommu_domain_alloc,
@@ -3181,6 +3249,9 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
.apply_resv_region = amd_iommu_apply_resv_region,
.is_attach_deferred = amd_iommu_is_attach_deferred,
.pgsize_bitmap  = AMD_IOMMU_PGSIZES,
+   .flush_iotlb_all = amd_iommu_flush_iotlb_all,
+   .iotlb_range_add = amd_iommu_iotlb_range_add,
+   .iotlb_sync = amd_iommu_iotlb_sync,
  };
  
  /*

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 6fe2d03..e8f8cee 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -185,6 +185,12 @@ struct ivmd_header {
  bool amd_iommu_force_isolation __read_mostly;
  
  /*

+ * IOTLB flush list
+ */
+LIST_HEAD(amd_iommu_flush_list);
+spinlock_t amd_iommu_flush_list_lock;
+
+/*
   * List of protection domains - used during resume
   */
  LIST_HEAD(amd_iommu_pd_list);
@@ -2490,6 +2496,7 @@ static int __init early_amd_iommu_init(void)
__set_bit(0, amd_iommu_pd_alloc_bitmap);
  
  	spin_lock_init(_iommu_pd_lock);

+   

Re: [RFC PATCH v2 2/2] iommu/amd: Add support for fast IOTLB flushing

[Suravee Suthikulpanit]

Hi Joerg,

Do you have any feedback regarding this patch for AMD IOMMU? I'm re-sending the 
patch 1/2
separately per Alex's suggestion.

Thanks,
Suravee

On 12/27/17 4:20 PM, Suravee Suthikulpanit wrote:

Implement the newly added IOTLB flushing interface for AMD IOMMU.

Signed-off-by: Suravee Suthikulpanit 
---
  drivers/iommu/amd_iommu.c   | 73 -
  drivers/iommu/amd_iommu_init.c  |  7 
  drivers/iommu/amd_iommu_types.h |  7 
  3 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 7d5eb00..42fe365 100644
--- a/drivers/iommu/amd_iommu.c
+++ b/drivers/iommu/amd_iommu.c
@@ -129,6 +129,12 @@ struct dma_ops_domain {
  static struct iova_domain reserved_iova_ranges;
  static struct lock_class_key reserved_rbtree_key;
  
+struct amd_iommu_flush_entries {

+   struct list_head list;
+   unsigned long iova;
+   size_t size;
+};
+
  /
   *
   * Helper functions
@@ -3043,7 +3049,6 @@ static size_t amd_iommu_unmap(struct iommu_domain *dom, 
unsigned long iova,
unmap_size = iommu_unmap_page(domain, iova, page_size);
mutex_unlock(>api_lock);
  
-	domain_flush_tlb_pde(domain);

domain_flush_complete(domain);
  
  	return unmap_size;

@@ -3163,6 +3168,69 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
return dev_data->defer_attach;
  }
  
+static void amd_iommu_flush_iotlb_all(struct iommu_domain *domain)

+{
+   struct protection_domain *dom = to_pdomain(domain);
+
+   domain_flush_tlb_pde(dom);
+}
+
+static void amd_iommu_iotlb_range_add(struct iommu_domain *domain,
+ unsigned long iova, size_t size)
+{
+   struct amd_iommu_flush_entries *entry, *p;
+   unsigned long flags;
+   bool found = false;
+
+   spin_lock_irqsave(_iommu_flush_list_lock, flags);
+   list_for_each_entry(p, _iommu_flush_list, list) {
+   if (iova != p->iova)
+   continue;
+
+   if (size > p->size) {
+   p->size = size;
+   pr_debug("%s: update range: iova=%#lx, size = %#lx\n",
+__func__, p->iova, p->size);
+   }
+   found = true;
+   break;
+   }
+
+   if (!found) {
+   entry = kzalloc(sizeof(struct amd_iommu_flush_entries),
+   GFP_KERNEL);
+   if (entry) {
+   pr_debug("%s: new range: iova=%lx, size=%#lx\n",
+__func__, iova, size);
+
+   entry->iova = iova;
+   entry->size = size;
+   list_add(>list, _iommu_flush_list);
+   }
+   }
+   spin_unlock_irqrestore(_iommu_flush_list_lock, flags);
+}
+
+static void amd_iommu_iotlb_sync(struct iommu_domain *domain)
+{
+   struct protection_domain *pdom = to_pdomain(domain);
+   struct amd_iommu_flush_entries *entry, *next;
+   unsigned long flags;
+
+   /* Note:
+* Currently, IOMMU driver just flushes the whole IO/TLB for
+* a given domain. So, just remove entries from the list here.
+*/
+   spin_lock_irqsave(_iommu_flush_list_lock, flags);
+   list_for_each_entry_safe(entry, next, _iommu_flush_list, list) {
+   list_del(>list);
+   kfree(entry);
+   }
+   spin_unlock_irqrestore(_iommu_flush_list_lock, flags);
+
+   domain_flush_tlb_pde(pdom);
+}
+
  const struct iommu_ops amd_iommu_ops = {
.capable = amd_iommu_capable,
.domain_alloc = amd_iommu_domain_alloc,
@@ -3181,6 +3249,9 @@ static bool amd_iommu_is_attach_deferred(struct 
iommu_domain *domain,
.apply_resv_region = amd_iommu_apply_resv_region,
.is_attach_deferred = amd_iommu_is_attach_deferred,
.pgsize_bitmap  = AMD_IOMMU_PGSIZES,
+   .flush_iotlb_all = amd_iommu_flush_iotlb_all,
+   .iotlb_range_add = amd_iommu_iotlb_range_add,
+   .iotlb_sync = amd_iommu_iotlb_sync,
  };
  
  /*

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 6fe2d03..e8f8cee 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -185,6 +185,12 @@ struct ivmd_header {
  bool amd_iommu_force_isolation __read_mostly;
  
  /*

+ * IOTLB flush list
+ */
+LIST_HEAD(amd_iommu_flush_list);
+spinlock_t amd_iommu_flush_list_lock;
+
+/*
   * List of protection domains - used during resume
   */
  LIST_HEAD(amd_iommu_pd_list);
@@ -2490,6 +2496,7 @@ static int __init early_amd_iommu_init(void)
__set_bit(0, amd_iommu_pd_alloc_bitmap);
  
  	spin_lock_init(_iommu_pd_lock);

+   spin_lock_init(_iommu_flush_list_lock);
  
  	/*

 * now the 

Re: [v3, 3/6] dt: booting-without-of: DT fix s/#interrupt-cell/#interrupt-cells/

[Michael Ellerman]

On Fri, 2017-06-02 at 12:38:46 UTC, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> Acked-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/4be4119d1fbd93c44d5c639735c312

cheers

Re: [v3, 3/6] dt: booting-without-of: DT fix s/#interrupt-cell/#interrupt-cells/

[Michael Ellerman]

On Fri, 2017-06-02 at 12:38:46 UTC, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven 
> Acked-by: Rob Herring 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/4be4119d1fbd93c44d5c639735c312

cheers

Re: powerpc: dts: Remove leading 0x and 0s from bindings notation

[Michael Ellerman]

On Thu, 2017-12-14 at 16:54:00 UTC, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 
> "0x"
> 
> and
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
> 
> Converted using the following command:
> 
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e 
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 
> \{/g" {} +
> 
> For simplicity, two sed expressions were used to solve each warnings 
> separately.
> 
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
> 
> https://elinux.org/Device_Tree_Linux#Linux_conventions
> 
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x 
> from bindings notation")
> 
> Reported-by: David Daney 
> Suggested-by: Rob Herring 
> Signed-off-by: Mathieu Malaterre 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/600ecc1936be075f611f299755e2de

cheers

Re: [RESEND] powerpc: mpic_timer: avoid struct timeval

[Michael Ellerman]

On Tue, 2018-01-16 at 17:01:50 UTC, Arnd Bergmann wrote:
> In an effort to remove all instances of 'struct timeval'
> from the kernel, I'm changing the powerpc mpic_timer interface
> to use plain seconds instead. There is only one user of this
> interface, and that doesn't use the microseconds portion, so
> the code gets noticeably simpler in the process.
> 
> Signed-off-by: Arnd Bergmann 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/11ed8c5569b149a065184dc8ce2241

cheers

Re: powerpc: dts: Remove leading 0x and 0s from bindings notation

[Michael Ellerman]

On Thu, 2017-12-14 at 16:54:00 UTC, Mathieu Malaterre wrote:
> Improve the DTS files by removing all the leading "0x" and zeros to fix the
> following dtc warnings:
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 
> "0x"
> 
> and
> 
> Warning (unit_address_format): Node /XXX unit name should not have leading 0s
> 
> Converted using the following command:
> 
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e 
> "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 
> \{/g" {} +
> 
> For simplicity, two sed expressions were used to solve each warnings 
> separately.
> 
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
> 
> https://elinux.org/Device_Tree_Linux#Linux_conventions
> 
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x 
> from bindings notation")
> 
> Reported-by: David Daney 
> Suggested-by: Rob Herring 
> Signed-off-by: Mathieu Malaterre 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/600ecc1936be075f611f299755e2de

cheers

Re: [RESEND] powerpc: mpic_timer: avoid struct timeval

[Michael Ellerman]

On Tue, 2018-01-16 at 17:01:50 UTC, Arnd Bergmann wrote:
> In an effort to remove all instances of 'struct timeval'
> from the kernel, I'm changing the powerpc mpic_timer interface
> to use plain seconds instead. There is only one user of this
> interface, and that doesn't use the microseconds portion, so
> the code gets noticeably simpler in the process.
> 
> Signed-off-by: Arnd Bergmann 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/11ed8c5569b149a065184dc8ce2241

cheers

Re: [RESEND] spufs: use timespec64 for timestamps

[Michael Ellerman]

On Tue, 2018-01-16 at 17:00:35 UTC, Arnd Bergmann wrote:
> The switch log prints the tv_sec portion of timespec as a 32-bit
> number, while overflows in 2106. It also uses the timespec type,
> which is safe on 64-bit architectures, but deprecated because
> it causes overflows in 2038 elsewhere.
> 
> This changes it to timespec64 and printing a 64-bit number for
> consistency.
> 
> Signed-off-by: Arnd Bergmann 
> Acked-by: Jeremy Kerr 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/cef37ac119b1abffcb41a9a7067929

cheers

Re: [RESEND] spufs: use timespec64 for timestamps

[Michael Ellerman]

On Tue, 2018-01-16 at 17:00:35 UTC, Arnd Bergmann wrote:
> The switch log prints the tv_sec portion of timespec as a 32-bit
> number, while overflows in 2106. It also uses the timespec type,
> which is safe on 64-bit architectures, but deprecated because
> it causes overflows in 2038 elsewhere.
> 
> This changes it to timespec64 and printing a 64-bit number for
> consistency.
> 
> Signed-off-by: Arnd Bergmann 
> Acked-by: Jeremy Kerr 

Applied to powerpc next, thanks.

https://git.kernel.org/powerpc/c/cef37ac119b1abffcb41a9a7067929

cheers