[RFC PATCH 4/6] serio: serport: add support for buffered write and receive
A tty ldisc naturally supports writing a buffer at a time, so convert the
serport driver to use the serio write_buf() function. For clients using
the existing interfaces, there is no change in functionality.
Signed-off-by: Rob Herring
---
drivers/input/serio/serport.c | 43 +++
1 file changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c
index a938c2b..5572c28 100644
--- a/drivers/input/serio/serport.c
+++ b/drivers/input/serio/serport.c
@@ -45,10 +45,10 @@ struct serport {
* Callback functions from the serio code.
*/
-static int serport_serio_write(struct serio *serio, unsigned char data)
+static int serport_serio_write_buf(struct serio *serio, const unsigned char
*data, size_t len)
{
struct serport *serport = serio->port_data;
- return -(serport->tty->ops->write(serport->tty, &data, 1) != 1);
+ return serport->tty->ops->write(serport->tty, data, len);
}
static int serport_serio_open(struct serio *serio)
@@ -133,26 +133,29 @@ static void serport_ldisc_receive(struct tty_struct *tty,
const unsigned char *c
if (!test_bit(SERPORT_ACTIVE, &serport->flags))
goto out;
- for (i = 0; i < count; i++) {
- if (fp) {
- switch (fp[i]) {
- case TTY_FRAME:
- ch_flags = SERIO_FRAME;
- break;
-
- case TTY_PARITY:
- ch_flags = SERIO_PARITY;
- break;
-
- default:
- ch_flags = 0;
- break;
+ if (serio_buffered_mode_enabled(serport->serio)) {
+ serio_receive_buf(serport->serio, cp, count);
+ } else {
+ for (i = 0; i < count; i++) {
+ if (fp) {
+ switch (fp[i]) {
+ case TTY_FRAME:
+ ch_flags = SERIO_FRAME;
+ break;
+
+ case TTY_PARITY:
+ ch_flags = SERIO_PARITY;
+ break;
+
+ default:
+ ch_flags = 0;
+ break;
+ }
}
- }
- serio_interrupt(serport->serio, cp[i], ch_flags);
+ serio_interrupt(serport->serio, cp[i], ch_flags);
+ }
}
-
out:
spin_unlock_irqrestore(&serport->lock, flags);
}
@@ -179,7 +182,7 @@ static ssize_t serport_ldisc_read(struct tty_struct * tty,
struct file * file, u
snprintf(serio->phys, sizeof(serio->phys), "%s/serio0", tty_name(tty));
serio->id = serport->id;
serio->id.type = SERIO_RS232;
- serio->write = serport_serio_write;
+ serio->write_buf = serport_serio_write_buf;
serio->open = serport_serio_open;
serio->close = serport_serio_close;
serio->port_data = serport;
--
2.9.3
[RFC PATCH 6/6] bluetooth: hack up ldisc to use serio
This hacks up the BT ldisc in place to work as a serio driver. It will
need refactoring into common, ldisc, and serio parts.
It is working under QEMU to the point the driver can bind to a serio
device via DT, register as a BT device, start sending out initial
packets and receive data (typed at a terminal). Now I need to find a
real device.
Still need to figure out how to plumb a few tty things like
TTY_DO_WRITE_WAKEUP bit handling and tty_unthrottle.
Signed-off-by: Rob Herring
---
drivers/bluetooth/hci_ldisc.c | 261 +-
drivers/bluetooth/hci_uart.h | 3 +
2 files changed, 109 insertions(+), 155 deletions(-)
diff --git a/drivers/bluetooth/hci_ldisc.c b/drivers/bluetooth/hci_ldisc.c
index dda9739..8149952 100644
--- a/drivers/bluetooth/hci_ldisc.c
+++ b/drivers/bluetooth/hci_ldisc.c
@@ -34,7 +34,9 @@
#include
#include
-#include
+#include
+#include
+#include
#include
#include
#include
@@ -138,7 +140,7 @@ int hci_uart_tx_wakeup(struct hci_uart *hu)
static void hci_uart_write_work(struct work_struct *work)
{
struct hci_uart *hu = container_of(work, struct hci_uart, write_work);
- struct tty_struct *tty = hu->tty;
+ struct serio *serio = hu->serio;
struct hci_dev *hdev = hu->hdev;
struct sk_buff *skb;
@@ -152,8 +154,8 @@ restart:
while ((skb = hci_uart_dequeue(hu))) {
int len;
- set_bit(TTY_DO_WRITE_WAKEUP, &tty->flags);
- len = tty->ops->write(tty, skb->data, skb->len);
+// set_bit(TTY_DO_WRITE_WAKEUP, &tty->flags);
+ len = serio_write_buf(serio, skb->data, skb->len);
hdev->stat.byte_tx += len;
skb_pull(skb, len);
@@ -215,17 +217,15 @@ static int hci_uart_open(struct hci_dev *hdev)
static int hci_uart_flush(struct hci_dev *hdev)
{
struct hci_uart *hu = hci_get_drvdata(hdev);
- struct tty_struct *tty = hu->tty;
- BT_DBG("hdev %p tty %p", hdev, tty);
+ BT_DBG("hdev %p serio %p", hdev, hu->serio);
if (hu->tx_skb) {
kfree_skb(hu->tx_skb); hu->tx_skb = NULL;
}
/* Flush any pending characters in the driver and discipline. */
- tty_ldisc_flush(tty);
- tty_driver_flush_buffer(tty);
+ serio_write_flush(hu->serio);
if (test_bit(HCI_UART_PROTO_READY, &hu->flags))
hu->proto->flush(hu);
@@ -261,6 +261,8 @@ static int hci_uart_send_frame(struct hci_dev *hdev, struct
sk_buff *skb)
/* Flow control or un-flow control the device */
void hci_uart_set_flow_control(struct hci_uart *hu, bool enable)
{
+ serio_set_flow_control(hu->serio, enable);
+#if 0
struct tty_struct *tty = hu->tty;
struct ktermios ktermios;
int status;
@@ -309,6 +311,7 @@ void hci_uart_set_flow_control(struct hci_uart *hu, bool
enable)
BT_DBG("Enabling hardware flow control: %s",
status ? "failed" : "success");
}
+#endif
}
void hci_uart_set_speeds(struct hci_uart *hu, unsigned int init_speed,
@@ -317,7 +320,7 @@ void hci_uart_set_speeds(struct hci_uart *hu, unsigned int
init_speed,
hu->init_speed = init_speed;
hu->oper_speed = oper_speed;
}
-
+#if 0
void hci_uart_init_tty(struct hci_uart *hu)
{
struct tty_struct *tty = hu->tty;
@@ -336,21 +339,13 @@ void hci_uart_init_tty(struct hci_uart *hu)
/* tty_set_termios() return not checked as it is always 0 */
tty_set_termios(tty, &ktermios);
}
-
+#endif
void hci_uart_set_baudrate(struct hci_uart *hu, unsigned int speed)
{
- struct tty_struct *tty = hu->tty;
- struct ktermios ktermios;
-
- ktermios = tty->termios;
- ktermios.c_cflag &= ~CBAUD;
- tty_termios_encode_baud_rate(&ktermios, speed, speed);
-
- /* tty_set_termios() return not checked as it is always 0 */
- tty_set_termios(tty, &ktermios);
+ int out_speed = serio_set_baudrate(hu->serio, speed);
BT_DBG("%s: New tty speeds: %d/%d", hu->hdev->name,
- tty->termios.c_ispeed, tty->termios.c_ospeed);
+ speed, out_speed);
}
static int hci_uart_setup(struct hci_dev *hdev)
@@ -428,83 +423,6 @@ done:
return 0;
}
-/* -- LDISC part -- */
-/* hci_uart_tty_open
- *
- * Called when line discipline changed to HCI_UART.
- *
- * Arguments:
- * ttypointer to tty info structure
- * Return Value:
- * 0 if success, otherwise error code
- */
-static int hci_uart_tty_open(struct tty_struct *tty)
-{
- struct hci_uart *hu;
-
- BT_DBG("tty %p", tty);
-
- /* Error if the tty has no write op instead of leaving an exploitable
- hole */
- if (tty->ops->write == NULL)
- return -EOPNOTSUPP;
-
- hu = kzalloc(sizeof(struct hci_uart), GFP_KERNEL);
- if (!hu) {
- BT_ERR("Can't allocate control structure");
- return -ENFILE;
-
[RFC PATCH 1/6] serio: add DT driver binding
This adds DT driver binding support to the serio bus. The parent of the
serio port device must have a device_node associated with it. Typically,
this would be the UART device node. The slave device must be a child node
of the UART device node.
Signed-off-by: Rob Herring
---
drivers/input/serio/serio.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index 1ca7f55..9e8eb7a 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Vojtech Pavlik ");
MODULE_DESCRIPTION("Serio abstraction core");
@@ -88,7 +89,7 @@ static void serio_disconnect_driver(struct serio *serio)
static int serio_match_port(const struct serio_device_id *ids, struct serio
*serio)
{
- while (ids->type || ids->proto) {
+ while (ids && (ids->type || ids->proto)) {
if ((ids->type == SERIO_ANY || ids->type == serio->id.type) &&
(ids->proto == SERIO_ANY || ids->proto == serio->id.proto)
&&
(ids->extra == SERIO_ANY || ids->extra == serio->id.extra)
&&
@@ -542,6 +543,8 @@ static void serio_init_port(struct serio *serio)
static void serio_add_port(struct serio *serio)
{
struct serio *parent = serio->parent;
+ struct device_node *parent_node =
+ serio->dev.parent ? serio->dev.parent->of_node : NULL;
int error;
if (parent) {
@@ -555,6 +558,8 @@ static void serio_add_port(struct serio *serio)
if (serio->start)
serio->start(serio);
+ serio->dev.of_node = of_get_next_available_child(parent_node, NULL);
+
error = device_add(&serio->dev);
if (error)
dev_err(&serio->dev,
@@ -902,6 +907,10 @@ static int serio_bus_match(struct device *dev, struct
device_driver *drv)
struct serio *serio = to_serio_port(dev);
struct serio_driver *serio_drv = to_serio_driver(drv);
+ if (of_driver_match_device(dev, drv)) {
+ printk("matched %s\n", dev->of_node->name);
+ return 1;
+ }
if (serio->manual_bind || serio_drv->manual_bind)
return 0;
--
2.9.3
[RFC PATCH 5/6] serio: add serial configuration functions
Just stub functions ATM.
Signed-off-by: Rob Herring
---
include/linux/serio.h | 16
1 file changed, 16 insertions(+)
diff --git a/include/linux/serio.h b/include/linux/serio.h
index 5d0b69f..5bf1754 100644
--- a/include/linux/serio.h
+++ b/include/linux/serio.h
@@ -41,6 +41,8 @@ struct serio {
void (*close)(struct serio *);
int (*start)(struct serio *);
void (*stop)(struct serio *);
+ void (*set_flow_control)(struct serio *, bool);
+ unsigned int (*set_baudrate)(struct serio *, unsigned int);
struct serio *parent;
/* Entry in parent->children list */
@@ -170,6 +172,20 @@ static inline void serio_drv_write_wakeup(struct serio
*serio)
serio->drv->write_wakeup(serio);
}
+static inline void serio_set_flow_control(struct serio *serio, bool enable)
+{
+ if (serio->set_flow_control)
+ serio->set_flow_control(serio, enable);
+}
+
+static inline unsigned int serio_set_baudrate(struct serio *serio, unsigned
int speed)
+{
+ if (serio->set_baudrate)
+ return serio->set_baudrate(serio, speed);
+
+ return 0;
+}
+
/*
* Use the following functions to manipulate serio's per-port
* driver-specific data.
--
2.9.3
[PATCH] x86, cpu: Fix node state for whether it contains CPU
In current kernel code, we only call node_set_state(cpu_to_node(cpu),
N_CPU) when a cpu is hot plugged. But we do not set the node state for
N_CPU when the cpus are brought online during boot.
So this could lead to failure when we check to see
if a node contains cpu with node_state(node_id, N_CPU).
One use case is in the node_reclaime function:
/*
* Only run node reclaim on the local node or on nodes that do
* not
* have associated processors. This will favor the local
* processor
* over remote processors and spread off node memory allocations
* as wide as possible.
*/
if (node_state(pgdat->node_id, N_CPU) && pgdat->node_id !=
numa_node_id())
return NODE_RECLAIM_NOSCAN;
I instrumented the kernel to call this function after boot and it
always returns 0 on a x86 desktop machine until I apply
the attached patch.
static int num_cpu_node(void)
{
int i, nr_cpu_nodes = 0;
for_each_node(i) {
if (node_state(i, N_CPU))
++ nr_cpu_nodes;
}
return nr_cpu_nodes;
}
I have not tested other architectues but they are likely
to have similar issue.
Signed-off-by: Tim Chen
---
arch/x86/kernel/smpboot.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index d8f7d01..04c0574 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -259,6 +259,7 @@ static void notrace start_secondary(void *unused)
lock_vector_lock();
setup_vector_irq(smp_processor_id());
set_cpu_online(smp_processor_id(), true);
+ node_set_state(cpu_to_node(smp_processor_id()), N_CPU);
unlock_vector_lock();
cpu_set_state_online(smp_processor_id());
x86_platform.nmi_init();
--
2.5.5
[RFC PATCH 1/6] serio: add OF driver binding
Signed-off-by: Rob Herring
---
drivers/input/serio/serio.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index 1ca7f55..6cfa22f 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
MODULE_AUTHOR("Vojtech Pavlik ");
MODULE_DESCRIPTION("Serio abstraction core");
@@ -88,7 +89,7 @@ static void serio_disconnect_driver(struct serio *serio)
static int serio_match_port(const struct serio_device_id *ids, struct serio
*serio)
{
- while (ids->type || ids->proto) {
+ while (ids && (ids->type || ids->proto)) {
if ((ids->type == SERIO_ANY || ids->type == serio->id.type) &&
(ids->proto == SERIO_ANY || ids->proto == serio->id.proto)
&&
(ids->extra == SERIO_ANY || ids->extra == serio->id.extra)
&&
@@ -107,6 +108,7 @@ static int serio_bind_driver(struct serio *serio, struct
serio_driver *drv)
{
int error;
+ printk("%s\n", __func__);
if (serio_match_port(drv->id_table, serio)) {
serio->dev.driver = &drv->driver;
@@ -133,6 +135,7 @@ static void serio_find_driver(struct serio *serio)
{
int error;
+ printk("%s\n", __func__);
error = device_attach(&serio->dev);
if (error < 0 && error != -EPROBE_DEFER)
dev_warn(&serio->dev,
@@ -542,8 +545,12 @@ static void serio_init_port(struct serio *serio)
static void serio_add_port(struct serio *serio)
{
struct serio *parent = serio->parent;
+ struct device_node *parent_node =
+ serio->dev.parent ? serio->dev.parent->of_node : NULL;
int error;
+ printk("%s\n", __func__);
+
if (parent) {
serio_pause_rx(parent);
list_add_tail(&serio->child_node, &parent->children);
@@ -555,6 +562,8 @@ static void serio_add_port(struct serio *serio)
if (serio->start)
serio->start(serio);
+ serio->dev.of_node = of_get_next_available_child(parent_node, NULL);
+
error = device_add(&serio->dev);
if (error)
dev_err(&serio->dev,
@@ -570,6 +579,8 @@ static void serio_destroy_port(struct serio *serio)
{
struct serio *child;
+ printk("%s\n", __func__);
+
while ((child = serio_get_pending_child(serio)) != NULL) {
serio_remove_pending_events(child);
put_device(&child->dev);
@@ -791,6 +802,7 @@ static int serio_driver_probe(struct device *dev)
struct serio *serio = to_serio_port(dev);
struct serio_driver *drv = to_serio_driver(dev->driver);
+ printk("%s\n", __func__);
return serio_connect_driver(serio, drv);
}
@@ -902,6 +914,12 @@ static int serio_bus_match(struct device *dev, struct
device_driver *drv)
struct serio *serio = to_serio_port(dev);
struct serio_driver *serio_drv = to_serio_driver(drv);
+ printk("%s\n", __func__);
+
+ if (of_driver_match_device(dev, drv)) {
+ printk("matched %s\n", dev->of_node->name);
+ return 1;
+ }
if (serio->manual_bind || serio_drv->manual_bind)
return 0;
--
2.9.3
[RFC PATCH 2/6] serio: serport: hacks to get DT probe to work
For DT matching, the serio->dev.parent is expected to be the UART device which is the tty's parent device. Not sure if this change has any side effects, but this is all just for testing. The spinlock causes deadlocks if serio_write is called from interrupt handler as write_wakeup gets called. This could be fixed by clearing TTY_DO_WRITE_WAKEUP if the spinlock is locked, but just doing quick hack for now. Signed-off-by: Rob Herring --- drivers/input/serio/serport.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/input/serio/serport.c b/drivers/input/serio/serport.c index 9c927d3..a938c2b 100644 --- a/drivers/input/serio/serport.c +++ b/drivers/input/serio/serport.c @@ -183,7 +183,7 @@ static ssize_t serport_ldisc_read(struct tty_struct * tty, struct file * file, u serio->open = serport_serio_open; serio->close = serport_serio_close; serio->port_data = serport; - serio->dev.parent = tty->dev; + serio->dev.parent = tty->dev->parent; serio_register_port(serport->serio); printk(KERN_INFO "serio: Serial port %s\n", tty_name(tty)); @@ -253,10 +253,10 @@ static void serport_ldisc_write_wakeup(struct tty_struct * tty) struct serport *serport = (struct serport *) tty->disc_data; unsigned long flags; - spin_lock_irqsave(&serport->lock, flags); +// spin_lock_irqsave(&serport->lock, flags); if (test_bit(SERPORT_ACTIVE, &serport->flags)) serio_drv_write_wakeup(serport->serio); - spin_unlock_irqrestore(&serport->lock, flags); +// spin_unlock_irqrestore(&serport->lock, flags); } /* -- 2.9.3
[PATCH] [media] tw5864-core: remove excessive irqsave
As warned by smatch:
drivers/media/pci/tw5864/tw5864-core.c:160 tw5864_h264_isr() error:
double lock 'irqsave:flags'
drivers/media/pci/tw5864/tw5864-core.c:174 tw5864_h264_isr() error:
double unlock 'irqsave:flags'
Two different spinlocks are obtained, so having two calls is correct,
but second irqsave is superfluous, and using same "flags" variable is
just wrong.
Reported-by: Mauro Carvalho Chehab
Signed-off-by: Andrey Utkin
---
drivers/media/pci/tw5864/tw5864-core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/pci/tw5864/tw5864-core.c
b/drivers/media/pci/tw5864/tw5864-core.c
index 440cd7b..1d43b96 100644
--- a/drivers/media/pci/tw5864/tw5864-core.c
+++ b/drivers/media/pci/tw5864/tw5864-core.c
@@ -157,12 +157,12 @@ static void tw5864_h264_isr(struct tw5864_dev *dev)
cur_frame = next_frame;
- spin_lock_irqsave(&input->slock, flags);
+ spin_lock(&input->slock);
input->frame_seqno++;
input->frame_gop_seqno++;
if (input->frame_gop_seqno >= input->gop)
input->frame_gop_seqno = 0;
- spin_unlock_irqrestore(&input->slock, flags);
+ spin_unlock(&input->slock);
} else {
dev_err(&dev->pci->dev,
"Skipped frame on input %d because all buffers busy\n",
--
2.9.2
[RFC PATCH 3/6] serio: add buffer receive and write functions
Currently, serio only supports a character at a time receive and write
functions. In order to support higher speed protocols like bluetooth,
buffer at a time functions are needed.
This mirrors the tty ldisc interface for write and receive_buf. Now that
a whole buffer can be queued, we need to be able to flush the write
queue as well.
While the write path doesn't require any updates to serio port drivers
as buffered write can be emulated with the existing write() function,
the receive path for port drivers must be updated to support the
buffered receive.
Signed-off-by: Rob Herring
---
drivers/input/serio/serio.c | 23 +++
include/linux/serio.h | 43 +++
2 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
index 9e8eb7a..c994581 100644
--- a/drivers/input/serio/serio.c
+++ b/drivers/input/serio/serio.c
@@ -989,6 +989,11 @@ int serio_open(struct serio *serio, struct serio_driver
*drv)
serio_set_drv(serio, NULL);
return -1;
}
+
+ /* Use buffer receive if the driver provides a callback */
+ if (drv->receive_buf)
+ set_bit(SERIO_MODE_BUFFERED, &drv->flags);
+
return 0;
}
EXPORT_SYMBOL(serio_open);
@@ -1024,6 +1029,24 @@ irqreturn_t serio_interrupt(struct serio *serio,
}
EXPORT_SYMBOL(serio_interrupt);
+int serio_receive_buf(struct serio *serio, const unsigned char *data, size_t
len)
+{
+ unsigned long flags;
+ int ret = 0;
+
+ spin_lock_irqsave(&serio->lock, flags);
+
+if (likely(serio->drv))
+ret = serio->drv->receive_buf(serio, data, len);
+ else if (device_is_registered(&serio->dev))
+ serio_rescan(serio);
+
+ spin_unlock_irqrestore(&serio->lock, flags);
+
+ return ret;
+}
+EXPORT_SYMBOL(serio_receive_buf);
+
struct bus_type serio_bus = {
.name = "serio",
.drv_groups = serio_driver_groups,
diff --git a/include/linux/serio.h b/include/linux/serio.h
index c733cff..5d0b69f 100644
--- a/include/linux/serio.h
+++ b/include/linux/serio.h
@@ -35,6 +35,8 @@ struct serio {
spinlock_t lock;
int (*write)(struct serio *, unsigned char);
+ int (*write_buf)(struct serio *, const unsigned char *, size_t);
+ void (*write_flush)(struct serio *);
int (*open)(struct serio *);
void (*close)(struct serio *);
int (*start)(struct serio *);
@@ -69,12 +71,16 @@ struct serio {
struct serio_driver {
const char *description;
+ unsigned long flags;
+
+#define SERIO_MODE_BUFFERED1
const struct serio_device_id *id_table;
bool manual_bind;
void (*write_wakeup)(struct serio *);
irqreturn_t (*interrupt)(struct serio *, unsigned char, unsigned int);
+ int (*receive_buf)(struct serio *, const unsigned char *, size_t);
int (*connect)(struct serio *, struct serio_driver *drv);
int (*reconnect)(struct serio *);
void (*disconnect)(struct serio *);
@@ -89,6 +95,12 @@ void serio_close(struct serio *serio);
void serio_rescan(struct serio *serio);
void serio_reconnect(struct serio *serio);
irqreturn_t serio_interrupt(struct serio *serio, unsigned char data, unsigned
int flags);
+int serio_receive_buf(struct serio *serio, const unsigned char *data, size_t
len);
+
+static inline bool serio_buffered_mode_enabled(struct serio *serio)
+{
+ return test_bit(SERIO_MODE_BUFFERED, &serio->drv->flags);
+}
void __serio_register_port(struct serio *serio, struct module *owner);
@@ -121,12 +133,35 @@ void serio_unregister_driver(struct serio_driver *drv);
module_driver(__serio_driver, serio_register_driver, \
serio_unregister_driver)
+static inline int serio_write_buf(struct serio *serio, const unsigned char
*data, size_t len)
+{
+ int ret;
+
+ if (serio->write_buf)
+ return serio->write_buf(serio, data, len);
+ else if (serio->write) {
+ int i;
+ for (i = 0; i < len; i++) {
+ ret = serio->write(serio, data[i]);
+ if (ret)
+ break;
+ }
+ return i;
+ }
+
+ return -1;
+}
+
static inline int serio_write(struct serio *serio, unsigned char data)
{
- if (serio->write)
- return serio->write(serio, data);
- else
- return -1;
+ int ret = serio_write_buf(serio, &data, 1);
+ return ret == 1 ? 0 : ret;
+}
+
+static inline void serio_write_flush(struct serio *serio)
+{
+ if (serio->write_flush)
+ serio->write_flush(serio);
}
static inline void serio_drv_write_wakeup(struct serio *serio)
--
2.9.3
[RFC PATCH 0/6] UART slave devices using serio
This is a new approach to supporting UART slave devices using the existing serio bus. After Arnd's proding, I took another look at serio and decided extending it does make sense. Using serio primarily requires adding DT based device matching and supporting buffer based write and receive. Currently, I'm using the existing serio serport ldisc for testing. This requires using inputattach to open the tty and set the ldisc which in turn registers a serio port with the serio core: inputattach -bare /dev/ttyAMA1 Once a tty_port based serio port driver is in place, this step will not be needed. Supporting cases like a USB UART will also work if the USB UART is described in DT. If not described in DT, I'm not sure if the existing serio manual binding is sufficient (Need to figure out how that works). Slave drivers also need other ways to specify additional data using module params perhaps. Getting DT overlays to work for non-discoverable devices behind discoverable buses (i.e. detached from a base DT) is another option, but that's not yet supported in general. I've done all the serio changes in place, but ultimately I think at least the core of serio should be moved out of drivers/input/. I don't think it belongs under drivers/tty/ or drivers/tty/serial/, so drivers/serio/? BT is working under QEMU to the point a slave driver can bind to a serio port device via DT, register as a BT device, start sending out initial packets and receive data (typed at a terminal). Now I need to find a real device. A git branch is available here[1]. Note it will get rebased. Rob [1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git serial-bus-serio Rob Herring (6): serio: add DT driver binding serio: serport: hacks to get DT probe to work serio: add buffer receive and write functions serio: serport: add support for buffered write and receive serio: add serial configuration functions bluetooth: hack up ldisc to use serio drivers/bluetooth/hci_ldisc.c | 261 +- drivers/bluetooth/hci_uart.h | 3 + drivers/input/serio/serio.c | 34 +- drivers/input/serio/serport.c | 49 include/linux/serio.h | 59 +- 5 files changed, 223 insertions(+), 183 deletions(-) -- 2.9.3
[RFT PATCH v2 0/4] usb: dwc2: Fix core reset and force mode delays
The following patch series addresses the core reset and force mode delay problems seen on some platforms. It is basically the same as this series of patches sent earlier this year: http://marc.info/?l=linux-usb&m=145921907525708&w=2 Except the first patch is omitted (already upstream) and the last patch is broken up into two patches. This series is trying to account for a variable delay from the IDDIG debounce filter when switching modes. This delay is a function of the PHY clock speed and can range from 5-50 ms. This delay must be taken into account on core reset and force modes. A full explanation is provided in the patch commit log and code comments. Patch 1 is a prerequisite to this fix. Patch 2 implements the delay for core reset. Patch 3 implements the delay for set/clear force modes. Patch 4 makes further optimizations to remove unnecessary calls to reset and force mode and avoid extra delays in the driver. RK3188 platforms: Michael Niewoehner reported problems with the previous set of patches that I suspect have to do with the last patch of this series. On Raspberry PI platforms: Stefan Wahren reported problems that should be solved by patches 1-3 of this series. Appreciate testing on these and any other platforms. Patch 1-2 can probably be merged right now as they shouldn't break anything. Patch 3 should solve the RPI problems and shouldn't have any issues on rk3188 either. Patch 4 likely will have the same issue as with rk3188 and will need to be investigated at a later time. Regards, John John Youn (4): usb: dwc2: gadget: Only initialize device if in device mode usb: dwc2: Add delay to core soft reset usb: dwc2: Properly account for the force mode delays usb: dwc2: Force mode optimizations drivers/usb/dwc2/core.c | 195 drivers/usb/dwc2/core.h | 2 +- drivers/usb/dwc2/gadget.c | 7 +- drivers/usb/dwc2/hcd.c | 6 +- drivers/usb/dwc2/hw.h | 1 + drivers/usb/dwc2/platform.c | 9 +- 6 files changed, 143 insertions(+), 77 deletions(-) -- 2.9.0
[PATCH v2] net: macb: Increase DMA TX buffer size
From: Nathan Sullivan In recent testing with the RT patchset, we have seen cases where the transmit ring can fill even with up to 200 txbds in the ring. Increase the size of the DMA TX ring to avoid overruns. Signed-off-by: Xander Huff Signed-off-by: Nathan Sullivan --- drivers/net/ethernet/cadence/macb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index 3256839..3efddb7 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -40,7 +40,7 @@ #define RX_RING_SIZE 512 /* must be power of 2 */ #define RX_RING_BYTES (sizeof(struct macb_dma_desc) * RX_RING_SIZE) -#define TX_RING_SIZE 128 /* must be power of 2 */ +#define TX_RING_SIZE 512 /* must be power of 2 */ #define TX_RING_BYTES (sizeof(struct macb_dma_desc) * TX_RING_SIZE) /* level of occupied TX descriptors under which we wake up TX process */ -- 1.9.1
[RFT PATCH v2 2/4] usb: dwc2: Add delay to core soft reset
Add a delay to the core soft reset function to account for the IDDIG
debounce filter.
If the current mode is host, either due to the force mode bit being
set (which persists after core reset) or the connector id pin, a core
soft reset will temporarily reset the mode to device and a delay from
the IDDIG debounce filter will occur before going back to host mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 97 +
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/hw.h | 1 +
3 files changed, 99 insertions(+)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 4135a5f..bb903e2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -238,6 +238,78 @@ int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg)
return ret;
}
+/**
+ * dwc2_wait_for_mode() - Waits for the controller mode.
+ * @hsotg: Programming view of the DWC_otg controller.
+ * @host_mode: If true, waits for host mode, otherwise device mode.
+ * @timeout: Time to wait in ms.
+ */
+static void dwc2_wait_for_mode(struct dwc2_hsotg *hsotg,
+ bool host_mode,
+ unsigned int timeout)
+{
+ ktime_t start;
+ ktime_t end;
+
+ dev_vdbg(hsotg->dev, "Waiting for %s mode\n",
+host_mode ? "host" : "device");
+
+ start = ktime_get();
+
+ while (1) {
+ s64 ms;
+
+ if (dwc2_is_host_mode(hsotg) == host_mode) {
+ dev_vdbg(hsotg->dev, "%s mode set\n",
+host_mode ? "Host" : "Device");
+ break;
+ }
+
+ end = ktime_get();
+ ms = ktime_to_ms(ktime_sub(end, start));
+
+ if (ms >= (s64)timeout) {
+ dev_warn(hsotg->dev, "%s: Couldn't set %s mode\n",
+__func__, host_mode ? "host" : "device");
+ break;
+ }
+
+ usleep_range(1000, 2000);
+ }
+}
+
+/**
+ * dwc2_iddig_filter_enabled() - Returns true if the IDDIG debounce
+ * filter is enabled.
+ */
+static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg *hsotg)
+{
+ u32 gsnpsid;
+ u32 ghwcfg4;
+
+ if (!dwc2_hw_is_otg(hsotg))
+ return false;
+
+ /* Check if core configuration includes the IDDIG filter. */
+ ghwcfg4 = dwc2_readl(hsotg->regs + GHWCFG4);
+ if (!(ghwcfg4 & GHWCFG4_IDDIG_FILT_EN))
+ return false;
+
+ /*
+* Check if the IDDIG debounce filter is bypassed. Available
+* in core version >= 3.10a.
+*/
+ gsnpsid = dwc2_readl(hsotg->regs + GSNPSID);
+ if (gsnpsid >= DWC2_CORE_REV_3_10a) {
+ u32 gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+
+ if (gotgctl & GOTGCTL_DBNCE_FLTR_BYPASS)
+ return false;
+ }
+
+ return true;
+}
+
/*
* Do core a soft reset of the core. Be careful with this because it
* resets all the internal state machines of the core.
@@ -246,9 +318,30 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
+ bool wait_for_host_mode = false;
dev_vdbg(hsotg->dev, "%s()\n", __func__);
+ /*
+* If the current mode is host, either due to the force mode
+* bit being set (which persists after core reset) or the
+* connector id pin, a core soft reset will temporarily reset
+* the mode to device. A delay from the IDDIG debounce filter
+* will occur before going back to host mode.
+*
+* Determine whether we will go back into host mode after a
+* reset and account for this delay after the reset.
+*/
+ if (dwc2_iddig_filter_enabled(hsotg)) {
+ u32 gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+ u32 gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
+
+ if (!(gotgctl & GOTGCTL_CONID_B) ||
+ (gusbcfg & GUSBCFG_FORCEHOSTMODE)) {
+ wait_for_host_mode = true;
+ }
+ }
+
/* Core Soft Reset */
greset = dwc2_readl(hsotg->regs + GRSTCTL);
greset |= GRSTCTL_CSFTRST;
@@ -277,6 +370,10 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
+ /* Wait up to 50 ms for the IDDIG debounce filter. */
+ if (wait_for_host_mode)
+ dwc2_wait_for_mode(hsotg, true, 50);
+
return 0;
}
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index d645512..2a21a04 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -890,6 +890,7 @@ struct dwc2_hsotg {
#define DWC2_CORE_REV_2_92a0x4f54292a
#define DWC2_CORE_REV_2_94a0x4f54294a
#define DWC2_CORE_REV_3_00a0x4f54300a
+#define DWC2_CORE_REV_3_10a0x4f54310a
#if IS_ENABLE
[RFT PATCH v2 4/4] usb: dwc2: Force mode optimizations
If the dr_mode is USB_DR_MODE_OTG, forcing the mode is needed during
driver probe to get the host and device specific HW parameters. Then we
clear the force mode bits so that the core operates in OTG mode.
The force mode bits should not be touched at any other time during the
driver lifetime and they should be preserved whenever the GUSBCFG
register is written to. The force mode bit values will presist across
soft resets of the core.
If the dr_mode is either USB_DR_MODE_HOST or USB_DR_MODE_PERIPHERAL, the
force mode is set just once at probe to configure the core as either a
host or peripheral.
Given the above, we no longer need any other reset delays, force delays,
or any forced modes anywhere else in the driver. So replace all calls to
dwc2_core_reset_and_force_dr_mode() with dwc2_core_reset() and remove
all other unnecessary delays.
Also remove the dwc2_force_mode_if_needed() function since the "if
needed" part is already taken care of by the polling in
dwc2_force_mode().
Finally, remove all other calls to dwc2_clear_force_mode().
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 66 ++---
drivers/usb/dwc2/core.h | 1 -
drivers/usb/dwc2/hcd.c | 6 ++---
drivers/usb/dwc2/platform.c | 9 ++-
4 files changed, 25 insertions(+), 57 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index caad6121..9b83b20 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -377,14 +377,14 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
return 0;
}
-/*
- * Force the mode of the controller.
+/**
+ * dwc2_force_mode() - Force the mode of the controller.
*
* Forcing the mode is needed for two cases:
*
* 1) If the dr_mode is set to either HOST or PERIPHERAL we force the
* controller to stay in a particular mode regardless of ID pin
- * changes. We do this usually after a core reset.
+ * changes. We do this once during probe.
*
* 2) During probe we want to read reset values of the hw
* configuration registers that are only available in either host or
@@ -401,7 +401,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
* the filter is configured and enabled. We poll the current mode of
* the controller to account for this delay.
*/
-static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
+static void dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
{
u32 gusbcfg;
u32 set;
@@ -413,17 +413,17 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg,
bool host)
* Force mode has no effect if the hardware is not OTG.
*/
if (!dwc2_hw_is_otg(hsotg))
- return false;
+ return;
/*
* If dr_mode is either peripheral or host only, there is no
* need to ever force the mode to the opposite mode.
*/
if (WARN_ON(host && hsotg->dr_mode == USB_DR_MODE_PERIPHERAL))
- return false;
+ return;
if (WARN_ON(!host && hsotg->dr_mode == USB_DR_MODE_HOST))
- return false;
+ return;
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
@@ -450,6 +450,11 @@ static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
{
u32 gusbcfg;
+ if (!dwc2_hw_is_otg(hsotg))
+ return;
+
+ dev_dbg(hsotg->dev, "Clearing force mode bits\n");
+
gusbcfg = dwc2_readl(hsotg->regs + GUSBCFG);
gusbcfg &= ~GUSBCFG_FORCEHOSTMODE;
gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
@@ -481,25 +486,6 @@ void dwc2_force_dr_mode(struct dwc2_hsotg *hsotg)
}
}
-/*
- * Do core a soft reset of the core. Be careful with this because it
- * resets all the internal state machines of the core.
- *
- * Additionally this will apply force mode as per the hsotg->dr_mode
- * parameter.
- */
-int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg *hsotg)
-{
- int retval;
-
- retval = dwc2_core_reset(hsotg);
- if (retval)
- return retval;
-
- dwc2_force_dr_mode(hsotg);
- return 0;
-}
-
/**
* dwc2_dump_host_registers() - Prints the host registers
*
@@ -1418,22 +1404,6 @@ void dwc2_set_parameters(struct dwc2_hsotg *hsotg,
dwc2_set_param_hibernation(hsotg, params->hibernation);
}
-/*
- * Forces either host or device mode if the controller is not
- * currently in that mode.
- *
- * Returns true if the mode was forced.
- */
-static bool dwc2_force_mode_if_needed(struct dwc2_hsotg *hsotg, bool host)
-{
- if (host && dwc2_is_host_mode(hsotg))
- return false;
- else if (!host && dwc2_is_device_mode(hsotg))
- return false;
-
- return dwc2_force_mode(hsotg, host);
-}
-
/*
* Gets host hardware parameters. Forces host mode if not currently in
* host mode. Should be called immediately after a core soft reset in
@@ -1444,21 +1414,17 @@ static void dwc2_get_host_hwparams(struct dwc2_hsotg
*hsotg)
struct dwc2_
[RFT PATCH v2 1/4] usb: dwc2: gadget: Only initialize device if in device mode
In dwc2_hsotg_udc_start(), don't initialize the controller for device
mode unless we are actually in device mode.
Signed-off-by: John Youn
---
drivers/usb/dwc2/gadget.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index af46adf..358ba5a 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3475,8 +3475,11 @@ static int dwc2_hsotg_udc_start(struct usb_gadget
*gadget,
otg_set_peripheral(hsotg->uphy->otg, &hsotg->gadget);
spin_lock_irqsave(&hsotg->lock, flags);
- dwc2_hsotg_init(hsotg);
- dwc2_hsotg_core_init_disconnected(hsotg, false);
+ if (dwc2_hw_is_device(hsotg)) {
+ dwc2_hsotg_init(hsotg);
+ dwc2_hsotg_core_init_disconnected(hsotg, false);
+ }
+
hsotg->enabled = 0;
spin_unlock_irqrestore(&hsotg->lock, flags);
--
2.9.0
[RFT PATCH v2 3/4] usb: dwc2: Properly account for the force mode delays
When a force mode bit is set and the IDDIG debounce filter is enabled,
there is a delay for the forced mode to take effect. This delay is due
to the IDDIG debounce filter and is variable depending on the platform's
PHY clock speed. To account for this delay we can poll for the expected
mode.
On a clear force mode, since we don't know what mode to poll for, delay
for a fixed 50 ms. This is the maximum delay based on the slowest PHY
clock speed.
Signed-off-by: John Youn
---
drivers/usb/dwc2/core.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index bb903e2..caad6121 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -397,9 +397,9 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
* Checks are done in this function to determine whether doing a force
* would be valid or not.
*
- * If a force is done, it requires a 25ms delay to take effect.
- *
- * Returns true if the mode was forced.
+ * If a force is done, it requires a IDDIG debounce filter delay if
+ * the filter is configured and enabled. We poll the current mode of
+ * the controller to account for this delay.
*/
static bool dwc2_force_mode(struct dwc2_hsotg *hsotg, bool host)
{
@@ -434,12 +434,17 @@ static bool dwc2_force_mode(struct dwc2_hsotg *hsotg,
bool host)
gusbcfg |= set;
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
- msleep(25);
- return true;
+ dwc2_wait_for_mode(hsotg, host, 50);
}
-/*
- * Clears the force mode bits.
+/**
+ * dwc2_clear_force_mode() - Clears the force mode bits.
+ *
+ * After clearing the bits, wait up to 50 ms to account for any
+ * potential IDDIG filter delay. We can't know if we expect this delay
+ * or not because the value of the connector ID status is affected by
+ * the force mode. We only need to call this once during probe if
+ * dr_mode == OTG.
*/
static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
{
@@ -450,11 +455,8 @@ static void dwc2_clear_force_mode(struct dwc2_hsotg *hsotg)
gusbcfg &= ~GUSBCFG_FORCEDEVMODE;
dwc2_writel(gusbcfg, hsotg->regs + GUSBCFG);
- /*
-* NOTE: This long sleep is _very_ important, otherwise the core will
-* not stay in host mode after a connector ID change!
-*/
- msleep(25);
+ if (dwc2_iddig_filter_enabled(hsotg))
+ msleep(50);
}
/*
@@ -477,12 +479,6 @@ void dwc2_force_dr_mode(struct dwc2_hsotg *hsotg)
__func__, hsotg->dr_mode);
break;
}
-
- /*
-* NOTE: This is required for some rockchip soc based
-* platforms.
-*/
- msleep(50);
}
/*
--
2.9.0
Re: kernel BUG at net/unix/garbage.c:149!"
On Thu, Aug 25, 2016 at 12:40 AM, Hannes Frederic Sowa wrote: > On 24.08.2016 16:24, Nikolay Borisov wrote: [SNIP] > > One commit which could have to do with that is > > commit fc64869c48494a401b1fb627c9ecc4e6c1d74b0d > Author: Andrey Ryabinin > Date: Wed May 18 19:19:27 2016 +0300 > > net: sock: move ->sk_shutdown out of bitfields. > > but that is only a wild guess. > > Which unix_sock did you extract specifically in the url you provided? In > unix_notinflight we are specifically checking an unix domain socket that > is itself being transferred over another af_unix domain socket and not > the unix domain socket being released at this point. So this is the state of the socket that is being passed to unix_notinflight. I have a complete crashdump so if you need more info to diagnose it I'm happy to provide it. I'm not too familiar with the code in question so I will need a bit of time to grasp what actually is happening. > > Can you reproduce this and maybe also with a newer kernel? Unfortunately I cannot reproduce this since it happened on a production server nor can I change the kernel. But clearly there is something wrong, and given that this is a stable kernel and no relevant changes have gone in latest stable I believe the problem (albeit hardly reproducible) would still persist. > > Thanks for the report, > Hannes >
Re: of_clk_add_(hw_)providers multipule times for one node?
Hi Stephen,
2016-08-25 3:08 GMT+09:00 Stephen Boyd :
> (Please trim replies)
>
> On 08/24, Masahiro Yamada wrote:
>>
>> Looks like the whole of my series was rejected,
>> but I was not sure why the following one was rejected.
>> https://patchwork.kernel.org/patch/9236563/
>>
>
> Replying to that patch would have been better.
>
>>
>> Could you explain why -EPROBE_DEFER should be returned
>> if both .get_hw and .get are missing.
>
> That's just a bug. Perhaps this patch would be better, and look,
> it saves 5 lines.
>
> ---8<
> drivers/clk/clk.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 71cc56712666..d3d26148cdfb 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3174,19 +3174,14 @@ __of_clk_get_hw_from_provider(struct of_clk_provider
> *provider,
> struct of_phandle_args *clkspec)
> {
> struct clk *clk;
> - struct clk_hw *hw = ERR_PTR(-EPROBE_DEFER);
>
> - if (provider->get_hw) {
> - hw = provider->get_hw(clkspec, provider->data);
> - } else if (provider->get) {
> - clk = provider->get(clkspec, provider->data);
> - if (!IS_ERR(clk))
> - hw = __clk_get_hw(clk);
> - else
> - hw = ERR_CAST(clk);
> - }
> + if (provider->get_hw)
> + return provider->get_hw(clkspec, provider->data);
>
> - return hw;
> + clk = provider->get(clkspec, provider->data);
> + if (IS_ERR(clk))
> + return ERR_CAST(clk);
> + return __clk_get_hw(clk);
> }
>
> struct clk *__of_clk_get_from_provider(struct of_phandle_args *clkspec,
Good.
Could you post it as a patch file?
Thanks!
--
Best Regards
Masahiro Yamada
Re: [PATCH 09/10] reset: zynq: add driver Kconfig option
2016-08-25 2:48 GMT+09:00 Masahiro Yamada : > 2016-08-24 22:29 GMT+09:00 Philipp Zabel : >> Visible only if COMPILE_TEST is enabled, this allows to include the >> driver in build tests. >> >> Cc: Moritz Fischer >> Cc: Michal Simek >> Cc: Sören Brinkmann >> Signed-off-by: Philipp Zabel >> --- >> drivers/reset/Kconfig | 6 ++ >> drivers/reset/Makefile | 2 +- >> 2 files changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig >> index 17030e2..86b49a2 100644 >> --- a/drivers/reset/Kconfig >> +++ b/drivers/reset/Kconfig >> @@ -67,6 +67,12 @@ config RESET_SUNXI >> help >> This enables the reset driver for Allwinner SoCs. >> >> +config RESET_ZYNQ >> + bool "ZYNQ Reset Driver" if COMPILE_TEST >> + default ARCH_ZYNQ >> + help >> + This enables the reset driver for Xilinx Zynq FPGAs. >> + > > Please move this below RESET_UNIPHIER > as I assume you are sorting Kconfig entries alphabetically. > > > Otherwise, > > Reviewed-by: Masahiro Yamada > >> + This enables the reset driver for Xilinx Zynq FPGAs. One more thing, I thought this statement is not precise because Zynq is not only an FPGA, but ARM SoC + FPGA. Please consider to reword "This enables the reset driver for Xilinx Zynq SoC" -- Best Regards Masahiro Yamada
Re: [PATCH] clk: h8300: Migrate to clk_hw based registration APIs
On 08/16, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Yoshinori Sato > Cc: > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH V5, 0/5] Add MediaTek USB3 DRD Driver
Hi, On Wed, 2016-08-24 at 13:29 +0200, Oliver Neukum wrote: > On Wed, 2016-08-24 at 14:42 +0800, chunfeng yun wrote: > > Dear all, > > > > Could you please help me to review the code? > > Is the structure > > struct qmu_gpd > > shared with the hardware? Do I read this correctly that > you do PIO to endpoint 0 but DMA to the others? > Yes, you are right. > Could you resend the series? > I will do it soon Thank you. > Regards > Oliver > >
[RESEND PATCH, v5 2/5] dt-bindings: mt8173-mtu3: add devicetree bindings
add a DT binding doc for MediaTek USB3 DRD driver
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/usb/mt8173-mtu3.txt| 87
1 file changed, 87 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
diff --git a/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
new file mode 100644
index 000..e049d19
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/mt8173-mtu3.txt
@@ -0,0 +1,87 @@
+The device node for Mediatek USB3.0 DRD controller
+
+Required properties:
+ - compatible : should be "mediatek,mt8173-mtu3"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for device IP and "ippc" for IP port control
+ - interrupts : interrupt used by the device IP
+ - power-domains : a phandle to USB power domain node to control USB's
+ mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must contain "sys_ck" for clock of controller;
+ "wakeup_deb_p0" and "wakeup_deb_p1" are optional, they are
+ depends on "mediatek,enable-wakeup"
+ - phys : a list of phandle + phy specifier pairs
+ - dr_mode : should be one of "host", "peripheral" or "otg",
+ refer to usb/generic.txt
+
+Optional properties:
+ - #address-cells, #size-cells : should be '2' if the device has sub-nodes
+ with 'reg' property
+ - ranges : allows valid 1:1 translation between child's address space and
+ parent's address space
+ - extcon : external connector for vbus and idpin changes detection, needed
+ when supports dual-role mode.
+ - vbus-supply : reference to the VBUS regulator, needed when supports
+ dual-role mode.
+ - pinctl-names : a pinctrl state named "default" must be defined,
+ "id_float" and "id_ground" are optinal which depends on
+ "mediatek,enable-manual-drd"
+ - pinctrl-0 : pin control group
+ See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
+
+ - maximum-speed : valid arguments are "super-speed", "high-speed" and
+ "full-speed"; refer to usb/generic.txt
+ - enable-manual-drd : supports manual dual-role switch via debugfs; usually
+ used when receptacle is TYPE-A and also wants to support dual-role
+ mode.
+ - mediatek,enable-wakeup : supports ip sleep wakeup used by host mode
+ - mediatek,syscon-wakeup : phandle to syscon used to access USB wakeup
+ control register, it depends on "mediatek,enable-wakeup".
+
+Sub-nodes:
+The xhci should be added as subnode to mtu3 as shown in the following example
+if host mode is enabled. The DT binding details of xhci can be found in:
+Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+
+Example:
+ssusb: usb@11271000 {
+ compatible = "mediatek,mt8173-mtu3";
+ reg = <0 0x11271000 0 0x3000>,
+ <0 0x11280700 0 0x0100>;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ phys = <&phy_port0 PHY_TYPE_USB3>,
+ <&phy_port1 PHY_TYPE_USB2>;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>,
+<&pericfg CLK_PERI_USB0>,
+<&pericfg CLK_PERI_USB1>;
+ clock-names = "sys_ck",
+ "wakeup_deb_p0",
+ "wakeup_deb_p1";
+ vusb33-supply = <&mt6397_vusb_reg>;
+ vbus-supply = <&usb_p0_vbus>;
+ extcon = <&extcon_usb>;
+ dr_mode = "otg";
+ mediatek,enable-wakeup;
+ mediatek,syscon-wakeup = <&pericfg>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ usb_host: xhci@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>;
+ reg-names = "mac";
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>;
+ clock-names = "sys_ck";
+ vusb33-supply = <&mt6397_vusb_reg>;
+ status = "disabled";
+ };
+};
--
1.7.9.5
Re: [PATCH 31/34] clk: twl6040: Migrate to clk_hw based registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Peter Ujfalusi > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: livepatch/module: make TAINT_LIVEPATCH module-specific
+++ Josh Poimboeuf [24/08/16 16:33 -0500]:
There's no reliable way to determine which module tainted the kernel
with CONFIG_LIVEPATCH. For example, /sys/module//taint
doesn't report it. Neither does the "mod -t" command in the crash tool.
Make it crystal clear who the guilty party is by converting
CONFIG_LIVEPATCH to a module taint flag.
This changes the behavior a bit: now the the flag gets set when the
module is loaded, rather than when it's enabled.
Did a quick sanity check and verified the module taint
shows up in crash and sysfs as expected, looks good.
Reviewed-by: Chunyu Hu
Signed-off-by: Josh Poimboeuf
Acked-by: Jessica Yu
---
kernel/livepatch/core.c | 3 ---
kernel/module.c | 35 ---
2 files changed, 12 insertions(+), 26 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 5fbabe0..af46438 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -545,9 +545,6 @@ static int __klp_enable_patch(struct klp_patch *patch)
list_prev_entry(patch, list)->state == KLP_DISABLED)
return -EBUSY;
- pr_notice_once("tainting kernel with TAINT_LIVEPATCH\n");
- add_taint(TAINT_LIVEPATCH, LOCKDEP_STILL_OK);
-
pr_notice("enabling patch '%s'\n", patch->mod->name);
klp_for_each_object(patch, obj) {
diff --git a/kernel/module.c b/kernel/module.c
index 529efae..fd5f95b 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1149,6 +1149,8 @@ static size_t module_flags_taint(struct module *mod, char
*buf)
buf[l++] = 'C';
if (mod->taints & (1 << TAINT_UNSIGNED_MODULE))
buf[l++] = 'E';
+ if (mod->taints & (1 << TAINT_LIVEPATCH))
+ buf[l++] = 'K';
/*
* TAINT_FORCED_RMMOD: could be added.
* TAINT_CPU_OUT_OF_SPEC, TAINT_MACHINE_CHECK, TAINT_BAD_PAGE don't
@@ -2791,26 +2793,6 @@ static int copy_chunked_from_user(void *dst, const void
__user *usrc, unsigned l
return 0;
}
-#ifdef CONFIG_LIVEPATCH
-static int find_livepatch_modinfo(struct module *mod, struct load_info *info)
-{
- mod->klp = get_modinfo(info, "livepatch") ? true : false;
-
- return 0;
-}
-#else /* !CONFIG_LIVEPATCH */
-static int find_livepatch_modinfo(struct module *mod, struct load_info *info)
-{
- if (get_modinfo(info, "livepatch")) {
- pr_err("%s: module is marked as livepatch module, but livepatch
support is disabled",
- mod->name);
- return -ENOEXEC;
- }
-
- return 0;
-}
-#endif /* CONFIG_LIVEPATCH */
-
/* Sets info->hdr and info->len. */
static int copy_module_from_user(const void __user *umod, unsigned long len,
struct load_info *info)
@@ -2969,9 +2951,16 @@ static int check_modinfo(struct module *mod, struct
load_info *info, int flags)
"is unknown, you have been warned.\n", mod->name);
}
- err = find_livepatch_modinfo(mod, info);
- if (err)
- return err;
+ if (get_modinfo(info, "livepatch")) {
+ if (!IS_ENABLED(CONFIG_LIVEPATCH)) {
+ pr_err("%s: module is marked as livepatch module, but
livepatch support is disabled\n",
+ mod->name);
+ return -ENOEXEC;
+ }
+ mod->klp = true;
+ pr_warn("%s: loading livepatch module.\n", mod->name);
+ add_taint_module(mod, TAINT_LIVEPATCH, LOCKDEP_STILL_OK);
+ }
/* Set up license info based on the info section */
set_license(mod, get_modinfo(info, "license"));
--
2.7.4
[RESEND PATCH V5, 0/5] Add MediaTek USB3 DRD Driver
>From e60d29d748a4e9f412c9bb08458083e97d3f523d Mon Sep 17 00:00:00 2001 From: Chunfeng Yun Date: Tue, 9 Aug 2016 16:12:31 +0800 Subject: [PATCH V5, 0/5] Add MediaTek USB3 DRD Driver These patches introduce the MediaTek USB3 dual-role controller driver. The driver can be configured as Dual-Role Device (DRD), Peripheral Only and Host Only (xHCI) modes. It works well with Mass Storage, RNDIS and g_zero on FS/HS and SS. And it is tested on MT8173 platform which only contains USB2.0 device IP, and on MT6290 platform which contains USB3.0 device IP. Change in v5: 1. modify some comments 2. rename some unsuitable variables 3. add reg-names property for host node 4. add USB_MTU3_DEBUG to control debug messages Change in v4: 1. fix build errors on non-mediatek platforms 2. provide manual dual-role switch via debugfs instead of sysfs Change in v3: 1. fix some typo error 2. rename mtu3.txt to mt8173-mtu3.txt Change in v2: 1. modify binding docs according to suggestions 2. modify some comments and remove some dummy blank lines 3. fix memory leakage Change in v2: 1. modify binding docs according to suggestions 2. modify some comments and remove some dummy blank lines 3. fix memory leakage Chunfeng Yun (5): dt-bindings: mt8173-xhci: support host side of dual-role mode dt-bindings: mt8173-mtu3: add devicetree bindings usb: xhci-mtk: make IPPC register optional usb: Add MediaTek USB3 DRD Driver arm64: dts: mediatek: add USB3 DRD driver .../devicetree/bindings/usb/mt8173-mtu3.txt| 87 ++ .../devicetree/bindings/usb/mt8173-xhci.txt| 54 +- arch/arm64/boot/dts/mediatek/mt8173-evb.dts| 46 +- arch/arm64/boot/dts/mediatek/mt8173.dtsi | 29 +- drivers/usb/Kconfig|2 + drivers/usb/Makefile |1 + drivers/usb/host/xhci-mtk.c| 36 +- drivers/usb/mtu3/Kconfig | 54 ++ drivers/usb/mtu3/Makefile | 19 + drivers/usb/mtu3/mtu3.h| 422 ++ drivers/usb/mtu3/mtu3_core.c | 874 +++ drivers/usb/mtu3/mtu3_dr.c | 375 + drivers/usb/mtu3/mtu3_dr.h | 108 +++ drivers/usb/mtu3/mtu3_gadget.c | 731 drivers/usb/mtu3/mtu3_gadget_ep0.c | 879 drivers/usb/mtu3/mtu3_host.c | 294 +++ drivers/usb/mtu3/mtu3_hw_regs.h| 473 +++ drivers/usb/mtu3/mtu3_plat.c | 490 +++ drivers/usb/mtu3/mtu3_qmu.c| 599 + drivers/usb/mtu3/mtu3_qmu.h| 43 + 20 files changed, 5598 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/mt8173-mtu3.txt create mode 100644 drivers/usb/mtu3/Kconfig create mode 100644 drivers/usb/mtu3/Makefile create mode 100644 drivers/usb/mtu3/mtu3.h create mode 100644 drivers/usb/mtu3/mtu3_core.c create mode 100644 drivers/usb/mtu3/mtu3_dr.c create mode 100644 drivers/usb/mtu3/mtu3_dr.h create mode 100644 drivers/usb/mtu3/mtu3_gadget.c create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c create mode 100644 drivers/usb/mtu3/mtu3_host.c create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h create mode 100644 drivers/usb/mtu3/mtu3_plat.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.h
Re: [PATCH v2] perf/x86/amd: Make HW_CACHE_REFERENCES and HW_CACHE_MISSES measure L2
(dropping stable@ from CC) On Wed, Aug 24, 2016 at 08:27:06PM +0200, Peter Zijlstra wrote: > They're not meant to be comparable between machines. I wouldn't even > compare the LLC numbers between two different Intel parts. > > These events are meant to profile a workload on the machine you run them > on. Big cache-miss/ref ratios indicate you loose performance because of > the memory subsystem and or data structure layout. Ah ok, then I've misunderstood Matt's justification in the commit message. FWIW: Acked-by: Borislav Petkov Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
Re: what is the purpose of SLAB and SLUB
On Tue, 23 Aug 2016, Andi Kleen wrote: > Why would you stop someone from working on SLAB if they want to? > > Forcibly enforcing a freeze on something can make sense if you're > in charge of a team to conserve resources, but in Linux the situation is > very different. I agree and frankly having multiple allocators is something good. Features that are good in one are copied to the other and enhanced in the process. I think this has driven code development quite a bit. Every allocator has a different basic approach to storage layout and synchronization which determines performance in various usage scenarios. The competition of seeing if the developer that is a fan of one can come up with a way to make performance better or storage use more effective in a situation where another shows better numbers is good. There may be more creative ways of coming up with new ways of laying out storage in the future and I would like to have the flexibility in the kernel to explore those if necessary with additional variations. The more common code we can isolate the easier it will become to just try out a new layout and a new form of serialization to see if it provides advantages.
[RESEND PATCH, v5 4/5] usb: Add MediaTek USB3 DRD Driver
This patch adds support for the MediaTek USB3 controller integrated into MT8173. It can be configured as Dual-Role Device (DRD), Peripheral Only and Host Only (xHCI) modes. Signed-off-by: Chunfeng Yun --- drivers/usb/Kconfig|2 + drivers/usb/Makefile |1 + drivers/usb/mtu3/Kconfig | 54 +++ drivers/usb/mtu3/Makefile | 19 + drivers/usb/mtu3/mtu3.h| 422 + drivers/usb/mtu3/mtu3_core.c | 874 +++ drivers/usb/mtu3/mtu3_dr.c | 375 +++ drivers/usb/mtu3/mtu3_dr.h | 108 + drivers/usb/mtu3/mtu3_gadget.c | 731 ++ drivers/usb/mtu3/mtu3_gadget_ep0.c | 879 drivers/usb/mtu3/mtu3_host.c | 294 drivers/usb/mtu3/mtu3_hw_regs.h| 473 +++ drivers/usb/mtu3/mtu3_plat.c | 490 drivers/usb/mtu3/mtu3_qmu.c| 599 drivers/usb/mtu3/mtu3_qmu.h| 43 ++ 15 files changed, 5364 insertions(+) create mode 100644 drivers/usb/mtu3/Kconfig create mode 100644 drivers/usb/mtu3/Makefile create mode 100644 drivers/usb/mtu3/mtu3.h create mode 100644 drivers/usb/mtu3/mtu3_core.c create mode 100644 drivers/usb/mtu3/mtu3_dr.c create mode 100644 drivers/usb/mtu3/mtu3_dr.h create mode 100644 drivers/usb/mtu3/mtu3_gadget.c create mode 100644 drivers/usb/mtu3/mtu3_gadget_ep0.c create mode 100644 drivers/usb/mtu3/mtu3_host.c create mode 100644 drivers/usb/mtu3/mtu3_hw_regs.h create mode 100644 drivers/usb/mtu3/mtu3_plat.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.c create mode 100644 drivers/usb/mtu3/mtu3_qmu.h diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index 8689dcb..9ca0bf0 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -95,6 +95,8 @@ source "drivers/usb/usbip/Kconfig" endif +source "drivers/usb/mtu3/Kconfig" + source "drivers/usb/musb/Kconfig" source "drivers/usb/dwc3/Kconfig" diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile index dca7856..7791af6 100644 --- a/drivers/usb/Makefile +++ b/drivers/usb/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_USB_DWC2)+= dwc2/ obj-$(CONFIG_USB_ISP1760) += isp1760/ obj-$(CONFIG_USB_MON) += mon/ +obj-$(CONFIG_USB_MTU3) += mtu3/ obj-$(CONFIG_PCI) += host/ obj-$(CONFIG_USB_EHCI_HCD) += host/ diff --git a/drivers/usb/mtu3/Kconfig b/drivers/usb/mtu3/Kconfig new file mode 100644 index 000..25cd619 --- /dev/null +++ b/drivers/usb/mtu3/Kconfig @@ -0,0 +1,54 @@ +# For MTK USB3.0 IP + +config USB_MTU3 + tristate "MediaTek USB3 Dual Role controller" + depends on EXTCON && (USB || USB_GADGET) && HAS_DMA + depends on ARCH_MEDIATEK || COMPILE_TEST + select USB_XHCI_MTK if USB_SUPPORT && USB_XHCI_HCD + help + Say Y or M here if your system runs on MediaTek SoCs with + Dual Role SuperSpeed USB controller. You can select usb + mode as peripheral role or host role, or both. + + If you don't know what this is, please say N. + + Choose M here to compile this driver as a module, and it + will be called mtu3.ko. + + +if USB_MTU3 +choice + bool "MTU3 Mode Selection" + default USB_MTU3_DUAL_ROLE if (USB && USB_GADGET) + default USB_MTU3_HOST if (USB && !USB_GADGET) + default USB_MTU3_GADGET if (!USB && USB_GADGET) + +config USB_MTU3_HOST + bool "Host only mode" + depends on USB=y || USB=USB_MTU3 + help + Select this when you want to use MTU3 in host mode only, + thereby the gadget feature will be regressed. + +config USB_MTU3_GADGET + bool "Gadget only mode" + depends on USB_GADGET=y || USB_GADGET=USB_MTU3 + help + Select this when you want to use MTU3 in gadget mode only, + thereby the host feature will be regressed. + +config USB_MTU3_DUAL_ROLE + bool "Dual Role mode" + depends on ((USB=y || USB=USB_MTU3) && (USB_GADGET=y || USB_GADGET=USB_MTU3)) + help + This is the default mode of working of MTU3 controller where + both host and gadget features are enabled. + +endchoice + +config USB_MTU3_DEBUG + bool "Enable Debugging Messages" + help + Say Y here to enable debugging messages in the MTU3 Driver. + +endif diff --git a/drivers/usb/mtu3/Makefile b/drivers/usb/mtu3/Makefile new file mode 100644 index 000..3e17ff7 --- /dev/null +++ b/drivers/usb/mtu3/Makefile @@ -0,0 +1,19 @@ + +ccflags-$(CONFIG_USB_MTU3_DEBUG) += -DDEBUG + +obj-$(CONFIG_USB_MTU3) += mtu3.o + +mtu3-y := mtu3_plat.o + +ifneq ($(filter y,$(CONFIG_USB_MTU3_HOST) $(CONFIG_USB_MTU3_DUAL_ROLE)),) + mtu3-y += mtu3_host.o +endif + +ifneq ($(filter y,$(CONFIG_USB_MTU3_GADGET) $(CONFIG_USB_MTU3_DUAL_ROLE)),) + mtu3-y += mtu3_core.o mtu3_gadget_ep0.o mtu3_gadget.o mtu3_qmu.o
Re: [PATCH 01/10] reset: ath79: add driver Kconfig option
2016-08-25 5:06 GMT+09:00 Arnd Bergmann : > On Thursday, August 25, 2016 3:18:55 AM CEST Masahiro Yamada wrote: >> Hi Arnd, >> >> >> 2016-08-25 0:51 GMT+09:00 Arnd Bergmann : >> > On Wednesday, August 24, 2016 3:28:53 PM CEST Philipp Zabel wrote: >> >> if RESET_CONTROLLER >> >> >> >> +config RESET_ATH79 >> >> + bool "AR71xx Reset Driver" if COMPILE_TEST >> >> + default ATH79 >> >> + help >> >> + This enables the ATH79 reset controller driver that supports the >> >> + AR71xx SoC reset controller. >> >> + >> >> >> > >> > Nice series! >> > >> > Just note that there is one possible problem with COMPILE_TEST >> > when the platforms are enabled, as you can then disable a driver >> > that is normally there, and that can in turn cause problems in >> > rare cases, e.g. when the driver has a global function that is >> > called from platform code. I don't know if any of the drivers >> > do that, but if they do, you'd have to use >> > >> > config RESET_ATH79 >> >bool "AR71xx Reset Driver" if COMPILE_TEST && !ATH79 >> >default ATH79 >> > >> > to ensure that it's impossible to disable the driver on platforms >> > that require it. >> >> Hmm, >> Can we do this only when we really have to do so? >> I think we should not care about such a rare case that may not happen. >> >> Let's start with only "if COMPILE_TEST", >> and take a look at it if a build error is detected. >> >> Anyway, depending on platform code is a sign of weird implementation. >> >> It might be better to find a potential issue rather than hide it. >> >> >> > > I just checked the object files in an allyesconfig build and found > one instance: > > arch/arm/mach-sunxi/sunxi.c:extern void __init sun6i_reset_init(void); > arch/arm/mach-sunxi/sunxi.c:sun6i_reset_init(); > drivers/reset/reset-sunxi.c:void __init sun6i_reset_init(void) > > We should definitely make sure this one is handled right, and maybe > check the source code for other instances. Hmm. Is is solved with RESET_OF_DECLARE(), like we have CLK_OF_DECLARE() ? Or, use something like postcore_initcall() to probe it really early? Not sure... -- Best Regards Masahiro Yamada
Re: [PATCH v3 1/5] drm/rockchip: sort registers define by chip's number
On 2016年08月23日 21:13, Sean Paul wrote: On Mon, Aug 22, 2016 at 8:40 PM, Mark yao wrote: On 2016年08月23日 04:30, Sean Paul wrote: On Thu, Aug 18, 2016 at 6:02 AM, Mark yao wrote: On 2016年08月18日 17:11, Daniel Vetter wrote: On Thu, Aug 18, 2016 at 05:08:14PM +0800, Mark yao wrote: Hi Sean Thanks for send v3 patch for rk3399 vop support. But sorry for that, I had changed my mind, those patches are deprecated, I have new rk3399 patch on my downstream kernel, I will upstream soon. Wut? Imo merge Sean's patch here, and then rebase your downstream patches on top of it. That you have a downstream tree which is out of sync with upstream shouldn't be a reason to stall upstream development. -Daniel Yeah, Sorry for that. In fact, on my downstream kernel, also have those patches, my new rk3399 patches are based on them, but the new rk3399 patches will cover the those patches, Sean's patches is old version. I just want to fast forward, don't want to send two version drivers to upstream. but if you and Dave feel ok for that, I have no problem:-) . merged Sean's patches and then apply new version patches. Ok, so can I get a review/ack for these revised patches then? Something is better than nothing, and there's a bunch of stuff that depends on these changes. Sean Yes, But I miss your [PATCH v3 0/5] and [PATCH v3 4/5]. do you mean the lost patches use v2 version? Yes, v2 4/5 was reviewed as-is, so I just applied it. Sean Applied this series to my drm-next. Thanks. Thanks. -- Ｍark Yao -- Ｍark Yao -- Ｍark Yao
Re: [PATCH v2 2/2] MAINTAINERS: document ASoC header files
Hi > include/sound/simple_card_utils.h is handled by ASoC maintainers, as > stated in https://lkml.org/lkml/2016/8/22/307, and > include/sound/simple_card.h seems to be an ASoC file too. In the future > there will be more files named like these ones so introduce a pattern to > match them. > > Signed-off-by: Nicolas Iooss > --- Acked-by: Kuninori Morimoto
[RESEND PATCH, v5 3/5] usb: xhci-mtk: make IPPC register optional
Make IPPC register optional to support host side of dual-role mode,
due to it is moved into common glue layer for simplification.
Signed-off-by: Chunfeng Yun
---
drivers/usb/host/xhci-mtk.c | 36 +---
1 file changed, 29 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 79959f1..4bf99b9 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -94,6 +94,9 @@ static int xhci_mtk_host_enable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
+ if (ippc == NULL)
+ return 0;
+
/* power on host ip */
value = readl(&ippc->ip_pw_ctr1);
value &= ~CTRL1_IP_HOST_PDN;
@@ -139,6 +142,9 @@ static int xhci_mtk_host_disable(struct xhci_hcd_mtk *mtk)
int ret;
int i;
+ if (ippc == NULL)
+ return 0;
+
/* power down all u3 ports */
for (i = 0; i < mtk->num_u3_ports; i++) {
value = readl(&ippc->u3_ctrl_p[i]);
@@ -173,6 +179,9 @@ static int xhci_mtk_ssusb_config(struct xhci_hcd_mtk *mtk)
struct mu3c_ippc_regs __iomem *ippc = mtk->ippc_regs;
u32 value;
+ if (ippc == NULL)
+ return 0;
+
/* reset whole ip */
value = readl(&ippc->ip_pw_ctr0);
value |= CTRL0_IP_SW_RST;
@@ -475,6 +484,7 @@ static void xhci_mtk_quirks(struct device *dev, struct
xhci_hcd *xhci)
/* called during probe() after chip reset completes */
static int xhci_mtk_setup(struct usb_hcd *hcd)
{
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
struct xhci_hcd_mtk *mtk = hcd_to_mtk(hcd);
int ret;
@@ -482,12 +492,21 @@ static int xhci_mtk_setup(struct usb_hcd *hcd)
ret = xhci_mtk_ssusb_config(mtk);
if (ret)
return ret;
+ }
+
+ ret = xhci_gen_setup(hcd, xhci_mtk_quirks);
+ if (ret)
+ return ret;
+
+ if (usb_hcd_is_primary_hcd(hcd)) {
+ mtk->num_u3_ports = xhci->num_usb3_ports;
+ mtk->num_u2_ports = xhci->num_usb2_ports;
ret = xhci_mtk_sch_init(mtk);
if (ret)
return ret;
}
- return xhci_gen_setup(hcd, xhci_mtk_quirks);
+ return ret;
}
static int xhci_mtk_probe(struct platform_device *pdev)
@@ -586,7 +605,7 @@ static int xhci_mtk_probe(struct platform_device *pdev)
mtk->hcd = platform_get_drvdata(pdev);
platform_set_drvdata(pdev, mtk);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mac");
hcd->regs = devm_ioremap_resource(dev, res);
if (IS_ERR(hcd->regs)) {
ret = PTR_ERR(hcd->regs);
@@ -595,11 +614,14 @@ static int xhci_mtk_probe(struct platform_device *pdev)
hcd->rsrc_start = res->start;
hcd->rsrc_len = resource_size(res);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- mtk->ippc_regs = devm_ioremap_resource(dev, res);
- if (IS_ERR(mtk->ippc_regs)) {
- ret = PTR_ERR(mtk->ippc_regs);
- goto put_usb2_hcd;
+ mtk->ippc_regs = NULL;
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ippc");
+ if (res) { /* ippc register is optional */
+ mtk->ippc_regs = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mtk->ippc_regs)) {
+ ret = PTR_ERR(mtk->ippc_regs);
+ goto put_usb2_hcd;
+ }
}
for (phy_num = 0; phy_num < mtk->num_phys; phy_num++) {
--
1.7.9.5
[RESEND PATCH, v5 1/5] dt-bindings: mt8173-xhci: support host side of dual-role mode
Some resources, such as IPPC register etc, shared with device
driver are moved into common glue layer when xHCI driver is the
host side of dual-role mode and they should be changed as optional
properties if they are required ones before. For clarity, add
a new part of binding to support host side of dual-role mode.
Additionally add optional properties of pinctrl for host only mode
Signed-off-by: Chunfeng Yun
Acked-by: Rob Herring
---
.../devicetree/bindings/usb/mt8173-xhci.txt| 54 +++-
1 file changed, 52 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
index b3a7ffa..2a930bd 100644
--- a/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mt8173-xhci.txt
@@ -2,10 +2,18 @@ MT8173 xHCI
The device node for Mediatek SOC USB3.0 host controller
+There are two scenarios: the first one only supports xHCI driver;
+the second one supports dual-role mode, and the host is based on xHCI
+driver. Take account of backward compatibility, we divide bindings
+into two parts.
+
+1st: only supports xHCI driver
+
+
Required properties:
- compatible : should contain "mediatek,mt8173-xhci"
- - reg : specifies physical base address and size of the registers,
- the first one for MAC, the second for IPPC
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC and "ippc" for IP port control
- interrupts : interrupt used by the controller
- power-domains : a phandle to USB power domain node to control USB's
mtcmos
@@ -27,12 +35,16 @@ Optional properties:
control register, it depends on "mediatek,wakeup-src".
- vbus-supply : reference to the VBUS regulator;
- usb3-lpm-capable : supports USB3.0 LPM
+ - pinctrl-names : a pinctrl state named "default" must be defined
+ - pinctrl-0 : pin control group
+ See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
Example:
usb30: usb@1127 {
compatible = "mediatek,mt8173-xhci";
reg = <0 0x1127 0 0x1000>,
<0 0x11280700 0 0x0100>;
+ reg-names = "mac", "ippc";
interrupts = ;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
clocks = <&topckgen CLK_TOP_USB30_SEL>,
@@ -49,3 +61,41 @@ usb30: usb@1127 {
mediatek,syscon-wakeup = <&pericfg>;
mediatek,wakeup-src = <1>;
};
+
+2nd: dual-role mode with xHCI driver
+
+
+In the case, xhci is added as subnode to mtu3. An example and the DT binding
+details of mtu3 can be found in:
+Documentation/devicetree/bindings/usb/mtu3.txt
+
+Required properties:
+ - compatible : should contain "mediatek,mt8173-xhci"
+ - reg : specifies physical base address and size of the registers
+ - reg-names: should be "mac" for xHCI MAC
+ - interrupts : interrupt used by the host controller
+ - power-domains : a phandle to USB power domain node to control USB's
+ mtcmos
+ - vusb33-supply : regulator of USB avdd3.3v
+
+ - clocks : a list of phandle + clock-specifier pairs, one for each
+ entry in clock-names
+ - clock-names : must be
+ "sys_ck": for clock of xHCI MAC
+
+Optional properties:
+ - vbus-supply : reference to the VBUS regulator;
+ - usb3-lpm-capable : supports USB3.0 LPM
+
+Example:
+usb30: usb@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>;
+ reg-names = "mac";
+ interrupts = ;
+ power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>;
+ clock-names = "sys_ck";
+ vusb33-supply = <&mt6397_vusb_reg>;
+ usb3-lpm-capable;
+};
--
1.7.9.5
Re: [PATCH] serial: 8250_mtk: support big baud rate.
On Fri, 2016-08-12 at 10:41 +0800, Long Cheng wrote:
> From: Eddie Huang
>
> mediatek can support baud rate up to 4M.
> the 'uart_get_baud_rate' function will limit the max baud rate.
> Modify max baud to remove the limit.
>
> Signed-off-by: Long Cheng
> ---
> drivers/tty/serial/8250/8250_mtk.c |6 +-
> drivers/tty/serial/8250/8250_port.c |4 +---
> 2 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_mtk.c
> b/drivers/tty/serial/8250/8250_mtk.c
> index 3611ec9..ce0cc47 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -62,7 +62,7 @@ mtk8250_set_termios(struct uart_port *port, struct ktermios
> *termios,
>*/
> baud = uart_get_baud_rate(port, termios, old,
> port->uartclk / 16 / 0x,
> - port->uartclk / 16);
> + port->uartclk);
>
> if (baud <= 115200) {
> serial_port_out(port, UART_MTK_HIGHS, 0x0);
> @@ -76,10 +76,6 @@ mtk8250_set_termios(struct uart_port *port, struct
> ktermios *termios,
> quot = DIV_ROUND_UP(port->uartclk, 4 * baud);
> } else {
> serial_port_out(port, UART_MTK_HIGHS, 0x3);
> -
> - /* Set to highest baudrate supported */
> - if (baud >= 1152000)
> - baud = 921600;
> quot = DIV_ROUND_UP(port->uartclk, 256 * baud);
> }
>
> diff --git a/drivers/tty/serial/8250/8250_port.c
> b/drivers/tty/serial/8250/8250_port.c
> index 7481b95..c45c1e3 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -2504,8 +2504,6 @@ static unsigned int serial8250_get_baud_rate(struct
> uart_port *port,
>struct ktermios *termios,
>struct ktermios *old)
> {
> - unsigned int tolerance = port->uartclk / 100;
> -
> /*
>* Ask the core to calculate the divisor for us.
>* Allow 1% tolerance at the upper limit so uart clks marginally
> @@ -2514,7 +2512,7 @@ static unsigned int serial8250_get_baud_rate(struct
> uart_port *port,
>*/
> return uart_get_baud_rate(port, termios, old,
> port->uartclk / 16 / 0x,
> - (port->uartclk + tolerance) / 16);
> + port->uartclk);
> }
>
> void
Ping? Any reaction to the above?
Regards, thanks.
Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support
On 17 June 2016 at 05:16, Pramod Gurav wrote:
> @@ -1635,6 +1732,7 @@ static int msm_serial_remove(struct platform_device
> *pdev)
> struct uart_port *port = platform_get_drvdata(pdev);
>
> uart_remove_one_port(&msm_uart_driver, port);
> + pm_runtime_disable(&pdev->dev);
>
> return 0;
> }
> @@ -1645,12 +1743,67 @@ static const struct of_device_id msm_match_table[] = {
> {}
> };
>
> +#ifdef CONFIG_PM
> +static int msm_serial_runtime_suspend(struct device *dev)
> +{
> + struct uart_port *port = dev_get_drvdata(dev);
> + struct msm_port *msm_port = UART_TO_MSM(port);
> +
> + if (msm_port->is_uartdm)
> + clk_disable(msm_port->pclk);
You don't need to check, just clk_disable it.
> +
> + return 0;
> +}
> +
> +static int msm_serial_runtime_resume(struct device *dev)
> +{
> + struct uart_port *port = dev_get_drvdata(dev);
> + struct msm_port *msm_port = UART_TO_MSM(port);
> + int ret;
> +
> + if (msm_port->is_uartdm) {
> + ret = clk_enable(msm_port->pclk);
Ditto here.
> + if (ret)
> + return ret;
> + }
> +
> + return 0;
> +}
> +#endif
> +
Regards,
Andy
[RESEND PATCH, v5 5/5] arm64: dts: mediatek: add USB3 DRD driver
USB3 DRD driver is added for MT8173-EVB, and xHCI driver
becomes its subnode
Signed-off-by: Chunfeng Yun
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 46 +--
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 29 +
2 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index 7453a47..682dfd7 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -34,6 +34,11 @@
chosen { };
+ extcon_usb: extcon_iddig {
+ compatible = "linux,extcon-usb-gpio";
+ id-gpio = <&pio 16 GPIO_ACTIVE_HIGH>;
+ };
+
usb_p1_vbus: regulator@0 {
compatible = "regulator-fixed";
regulator-name = "usb_vbus";
@@ -42,6 +47,16 @@
gpio = <&pio 130 GPIO_ACTIVE_HIGH>;
enable-active-high;
};
+
+ usb_p0_vbus: regulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = <&pio 9 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
};
&i2c1 {
@@ -205,6 +220,20 @@
bias-pull-down = ;
};
};
+
+ usb_id_pins_float: usb_iddig_pull_up {
+ pins_iddig {
+ pinmux = ;
+ bias-pull-up;
+ };
+ };
+
+ usb_id_pins_ground: usb_iddig_pull_down {
+ pins_iddig {
+ pinmux = ;
+ bias-pull-down;
+ };
+ };
};
&pwm0 {
@@ -431,12 +460,25 @@
status = "okay";
};
+&ssusb {
+ vusb33-supply = <&mt6397_vusb_reg>;
+ vbus-supply = <&usb_p0_vbus>;
+ extcon = <&extcon_usb>;
+ dr_mode = "otg";
+ mediatek,enable-wakeup;
+ pinctrl-names = "default", "id_float", "id_ground";
+ pinctrl-0 = <&usb_id_pins_float>;
+ pinctrl-1 = <&usb_id_pins_float>;
+ pinctrl-2 = <&usb_id_pins_ground>;
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
-&usb30 {
+&usb_host {
vusb33-supply = <&mt6397_vusb_reg>;
vbus-supply = <&usb_p1_vbus>;
- mediatek,wakeup-src = <1>;
+ status = "okay";
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 10f638f..925948a 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -668,11 +668,14 @@
status = "disabled";
};
- usb30: usb@1127 {
- compatible = "mediatek,mt8173-xhci";
- reg = <0 0x1127 0 0x1000>,
+ ssusb: usb@11271000 {
+ compatible = "mediatek,mt8173-mtu3";
+ reg = <0 0x11271000 0 0x3000>,
<0 0x11280700 0 0x0100>;
- interrupts = ;
+ reg-names = "mac", "ippc";
+ interrupts = ;
+ phys = <&phy_port0 PHY_TYPE_USB3>,
+ <&phy_port1 PHY_TYPE_USB2>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_USB>;
clocks = <&topckgen CLK_TOP_USB30_SEL>,
<&pericfg CLK_PERI_USB0>,
@@ -680,10 +683,22 @@
clock-names = "sys_ck",
"wakeup_deb_p0",
"wakeup_deb_p1";
- phys = <&phy_port0 PHY_TYPE_USB3>,
- <&phy_port1 PHY_TYPE_USB2>;
mediatek,syscon-wakeup = <&pericfg>;
- status = "okay";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ status = "disabled";
+
+ usb_host: xhci@1127 {
+ compatible = "mediatek,mt8173-xhci";
+ reg = <0 0x1127 0 0x1000>;
+ reg-names = "mac";
+ interrupts = ;
+ power-domains = <&scpsys
MT8173_POWER_DOMAIN_USB>;
+ clocks = <&topckgen CLK_TOP_USB30_SEL>;
+ clock-names = "sys_ck";
+ status = "disabled";
+ };
};
u3phy: usb-phy@1129 {
--
1.7.9.5
Re: what is the purpose of SLAB and SLUB (was: Re: [PATCH v3] mm/slab: Improve performance of gathering slabinfo) stats
On Wed, 24 Aug 2016, Mel Gorman wrote: > If/when I get back to the page allocator, the priority would be a bulk > API for faster allocs of batches of order-0 pages instead of allocating > a large page and splitting. > OMG. Do we really want to continue this? There are billions of Linux devices out there that require a reboot at least once a week. This is now standard with certain Android phones. In our company we reboot all machines every week because fragmentation degrades performance significantly. We need to finally face up to it and deal with the issue instead of continuing to produce more half ass-ed solutions. Managing memory in 4K chunks is not reasonable if you have machines with terabytes of memory and thus billions of individual page structs to manage. I/O devices are throttling because they cannot manage so much meta data and we get grotesque devices. The kernel needs an effective way to handle large contiguous memory. It needs the ability to do effective defragmentation for that. And the way forward has been clear also for awhile. All objects must be either movable or be reclaimable so that things can be moved to allow contiguity to be restored. We have support for that for the page cache and interestingly enough for CMA now. So this is gradually developing because it is necessary. We need to go with that and provide a full fledged implementation in the kernel that allows effective handling of large objects in the page allocator and we need general logic in the kernel for effective handling of large sized chunks of memory. Lets stop churning tiny 4k segments in the world where even our cell phones have capacities measured in Gigabytes which certainly then already means millions of 4k objects whose management one by one is a drag on performance and makes operating system coding extremely complex. The core of Linux must support that for the future in which we will see even larger memory capacities.
Re: [PATCH net-next] net: dsa: rename switch operations structure
From: Vivien Didelot
Date: Tue, 23 Aug 2016 12:38:56 -0400
> Now that the dsa_switch_driver structure contains only function pointers
> as it is supposed to, rename it to the more appropriate dsa_switch_ops,
> uniformly to any other operations structure in the kernel.
>
> No functional changes here, basically just the result of something like:
> s/dsa_switch_driver *drv/dsa_switch_ops *ops/g
>
> However keep the {un,}register_switch_driver functions and their
> dsa_switch_drivers list as is, since they represent the -- likely to be
> deprecated soon -- legacy DSA registration framework.
>
> In the meantime, also fix the following checks from checkpatch.pl to
> make it happy with this patch:
...
> Signed-off-by: Vivien Didelot
Applied, thanks Vivien.
Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support
On 25 August 2016 at 10:05, Andy Gross wrote:
> On 17 June 2016 at 05:16, Pramod Gurav wrote:
>
>> + if (msm_port->is_uartdm) {
>> + ret = clk_enable(msm_port->pclk);
>
> Ditto here.
Thanks Andy, will include these two changes in v2.
>
>> + if (ret)
Re: [PATCH] mm: clarify COMPACTION Kconfig text
On Tue, 23 Aug 2016, Michal Hocko wrote: > From: Michal Hocko > > The current wording of the COMPACTION Kconfig help text doesn't > emphasise that disabling COMPACTION might cripple the page allocator > which relies on the compaction quite heavily for high order requests and > an unexpected OOM can happen with the lack of compaction. Make sure > we are vocal about that. > Since when has this been an issue? I don't believe it has been an issue in the past for any archs that don't use thp. > Signed-off-by: Michal Hocko > --- > mm/Kconfig | 9 - > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/mm/Kconfig b/mm/Kconfig > index 78a23c5c302d..0dff2f05b6d1 100644 > --- a/mm/Kconfig > +++ b/mm/Kconfig > @@ -262,7 +262,14 @@ config COMPACTION > select MIGRATION > depends on MMU > help > - Allows the compaction of memory for the allocation of huge pages. > + Compaction is the only memory management component to form > + high order (larger physically contiguous) memory blocks > + reliably. Page allocator relies on the compaction heavily and > + the lack of the feature can lead to unexpected OOM killer > + invocation for high order memory requests. You shouldnm't > + disable this option unless there is really a strong reason for > + it and then we are really interested to hear about that at > + linux...@kvack.org. > > # > # support for page migration This seems to strongly suggest that all kernels should be built with CONFIG_COMPACTION and its requirement, CONFIG_MIGRATION. Migration has a dependency of NUMA or memory hot-remove (not all popular). Compaction can defragment memory within single zone without reliance on NUMA. This seems like a very bizarre requirement and I'm wondering where we regressed from this thp-only behavior.
Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery
On 13 January 2016 at 19:18, Nishanth Menon wrote: > As you already see it is ridiculously round about way of protecting RTC > time.. but anyways, for what ever reason, that was mandatory function to > support on certain product lines. Having secure date/time is probably necessary for some digital rights management schemes; e.g. you rent a movie for limited time, but it may not always be acceptable to require working internet connectivity to be able to hit the play button hence the need to rely on a secure RTC. There wouldn't even be an SMC for setting the RTC, probably it would synchronize when the secure-world shizzle contacts the Big Server O'Secrety Bits. :P Protecting pinmux through the L4 firewall sounds hilarious: the whole ctrl_core module (0x4a002000 - 0x4a002fff) is a single firewall region. All permitted access to it by linux would have to be redirected to an SMC or similar. On 13 January 2016 at 20:05, Nishanth Menon wrote: > An internal feedback I got some time back on AM57 (not OMAP5) - context > was that we were discussing if an external pull up resistor was needed > for a GPIO button: > "Internal pull-ups are relatively weak (ranging to 100kOhm or higher) Unlike the OMAP5, AM57xx uses 1.8V/3.3V drivers for its generic IOs, which have to do magic to not get fried by such high voltages. Crappier specs result, especially for pulling up to 3.3V: 1.8V mode, pull-down current while pin is held high: 50-210 uA 3.3V mode, pull-down current while pin is held high: 40-200 uA 1.8V mode, pull-up current while pin is held low: 60-200 uA 3.3V mode, pull-up current while pin is held low: 10-290 uA Note the worst-case equivalent pull-up resistance in 3.3V mode is 330 kOhm, eleven times higher than in 1.8V mode. Matthijs
Re: [PATCH] livepatch/module: make TAINT_LIVEPATCH module-specific
On Wed, 24 Aug 2016, Josh Poimboeuf wrote: > There's no reliable way to determine which module tainted the kernel > with CONFIG_LIVEPATCH. For example, /sys/module//taint > doesn't report it. Neither does the "mod -t" command in the crash tool. > > Make it crystal clear who the guilty party is by converting > CONFIG_LIVEPATCH to a module taint flag. > > This changes the behavior a bit: now the the flag gets set when the > module is loaded, rather than when it's enabled. > > Reviewed-by: Chunyu Hu > Signed-off-by: Josh Poimboeuf I like this change. Rusty, in case you're okay with it as well, could you please either provide your Ack so that I could take it through livepatching.git? Alternatively, if you prefer to merge this through your tree, please feel free to add Acked-by: Jiri Kosina Thanks, -- Jiri Kosina SUSE Labs
Re: [kbuild-all] make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//dax.o'.
On Wed, Aug 24, 2016 at 07:59:05AM -0700, Dan Williams wrote: On Tue, Aug 23, 2016 at 7:47 PM, Fengguang Wu wrote: On Tue, Aug 23, 2016 at 04:42:15PM -0700, Dan Williams wrote: I was not able to reproduce this, I tried on Fedora 23 and Fedora 24 and both attempts succeeded. Hi Dan, it looks the error only happens with separated obj dir, when KBUILD_OUTPUT or "-C .. O=.." is used in make command line. The following worked for me, what am I missing? $ make -j 64 O=$HOME/git/obj 2>out; make -j 64 O=$HOME/git/obj M=tools/testing/nvdimm 2>>out; In 0day builds, $PWD is the obj dir and so we used "-C" too: wfg@inn ~/linux/obj-compiletest% ls -l source lrwxrwxrwx 1 wfg wfg 2 Aug 24 10:40 source -> .. wfg@inn ~/linux/obj-compiletest% make M=tools/testing/nvdimm/ ==> /usr/bin/make -C source O=/home/wfg/linux/obj-compiletest ARCH=x86_64 -j32 M=tools/testing/nvdimm/ make: Entering directory '/c/wfg/linux' make[1]: Entering directory '/c/wfg/linux/obj-compiletest' make[2]: *** No rule to make target 'tools/testing/nvdimm//config_check.o', needed by 'tools/testing/nvdimm//libnvdimm.o'. Stop. /c/wfg/linux/Makefile:1478: recipe for target '_module_tools/testing/nvdimm/' failed make[1]: *** [_module_tools/testing/nvdimm/] Error 2 make[1]: Leaving directory '/c/wfg/linux/obj-compiletest' Makefile:150: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 make: Leaving directory '/c/wfg/linux' Thanks, Fengguang
Re: [PATCH 2/2] ARM: dts: sun8i: enable UART1 for iNet D978 Rev2 board
On Thu, Aug 25, 2016 at 7:58 AM, Icenowy Zheng wrote:
>
>
> 25.08.2016, 03:36, "Maxime Ripard" :
>> Hi,
>>
>> On Tue, Aug 23, 2016 at 02:44:51PM +0800, Icenowy Zheng wrote:
>>> UART1 is connected to the bluetooth part of RTL8723BS WiFi/BT combo card
>>> on iNet D978 Rev2 board.
>>>
>>> Enable the UART1 to make it possible to use the modified hciattach by
>>> Realtek to drive the BT part of RTL8723BS.
>>>
>>> Signed-off-by: Icenowy Zheng
>>
>> I guess you could fold that patch into the previous one.
>>
>>> ---
>>> arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 11 +++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>> b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>> index 78823d8..3ac22d4 100644
>>> --- a/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>> +++ b/arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts
>>> @@ -48,6 +48,10 @@
>>> model = "INet-D978 Rev 02";
>>> compatible = "primux,inet-d978-rev2", "allwinner,sun8i-a33";
>>>
>>> + aliases {
>>> + serial1 = &uart1;
>>> + };
>>> +
>>
>> Is there any other UART in the system?
>
> serial0 is defined in sun8i-reference-design-tablet.dtsi, as r_uart.
If your board does not have r_uart pads, then the right thing to do
would be to disable it. You can then have uart1 as serial0.
AFAIK Linux requires a console, but that console can be simplefb.
ChenYu
>>
>> The alias is not supposed to be about the controller index, but the
>> index in the board, meaning that if you only have a single UART, that
>> would be serial0.
>>
>> Thanks!
>> Maxime
>>
>> --
>> Maxime Ripard, Free Electrons
>> Embedded Linux and Kernel engineering
>> http://free-electrons.com
Re: [PATCH for-next 0/2] {IB,net}/hns: Add support of ACPI to the Hisilicon RoCE Driver
From: Salil Mehta Date: Wed, 24 Aug 2016 04:44:48 +0800 > This patch is meant to add support of ACPI to the Hisilicon RoCE driver. > Following changes have been made in the driver(s): > > Patch 1/2: HNS Ethernet Driver: changes to support ACPI have been done in >the RoCE reset function part of the HNS ethernet driver. Earlier it only >supported DT/syscon. > > Patch 2/2. HNS RoCE driver: changes done in RoCE driver are meant to detect >the type and then either use DT specific or ACPI spcific functions. Where >ever possible, this patch tries to make use of "Unified Device Property >Interface" APIs to support both DT and ACPI through single interface. > > NOTE 1: ACPI changes done in both of the drivers depend upon the ACPI Table > (DSDT and IORT tables) changes part of UEFI/BIOS. These changes are NOT > part of this patch-set. > NOTE 2: Reset function in Patch 1/2 depends upon the reset function added in > ACPI tables(basically DSDT table) part of the UEFI/BIOS. Again, this > change is NOT reflected in this patch-set. I can't apply this series to my tree because the hns infiniband driver doesn't exist in it.
Re: [PATCH 2/5] Drivers: hv: balloon: account for gaps in hot add regions
Hi, kys!
> On Wed, 24 Aug 2016 16:23:10 -0700, kys wrote:
[...]
> -static bool pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
> +static int pfn_covered(unsigned long start_pfn, unsigned long pfn_cnt)
> {
> struct list_head *cur;
> struct hv_hotadd_state *has;
> +struct hv_hotadd_gap *gap;
> unsigned long residual, new_inc;
> if (list_empty(&dm_device.ha_region_list))
One "return false;" left here.
[...]
> -if (has->covered_end_pfn != start_pfn)
> -has->covered_end_pfn = start_pfn;
> -
> -return true;
> -
> +return 1;
> }
> -return false;
> +return 0;
> }
[...]
--
WBR,
Yauheni Kaliuta
[PATCH v2 2/2] arm64: dts: hi6220: add resets property into dwmmc nodes
Add resets property into dwmmc_0, dwmmc_1 and dwmmc_2 for hi6220 Code and documentation to this property were confirmed by maintainers. See: [1] https://patchwork.kernel.org/patch/9276607/ [2] https://patchwork.kernel.org/patch/8487151/ [3] https://lkml.org/lkml/2016/8/12/91 cc: Jaehoon Chung cc: Rob Herring Signed-off-by: Guodong Xu --- arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi index d0b887a..63608e9 100644 --- a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi +++ b/arch/arm64/boot/dts/hisilicon/hi6220.dtsi @@ -771,6 +771,7 @@ interrupts = <0x0 0x48 0x4>; clocks = <&sys_ctrl 2>, <&sys_ctrl 1>; clock-names = "ciu", "biu"; + resets = <&sys_ctrl PERIPH_RSTDIS0_MMC0>; bus-width = <0x8>; vmmc-supply = <&ldo19>; pinctrl-names = "default"; @@ -790,6 +791,7 @@ #size-cells = <0x0>; clocks = <&sys_ctrl 4>, <&sys_ctrl 3>; clock-names = "ciu", "biu"; + resets = <&sys_ctrl PERIPH_RSTDIS0_MMC1>; vqmmc-supply = <&ldo7>; vmmc-supply = <&ldo10>; bus-width = <0x4>; @@ -807,6 +809,7 @@ interrupts = <0x0 0x4a 0x4>; clocks = <&sys_ctrl HI6220_MMC2_CIUCLK>, <&sys_ctrl HI6220_MMC2_CLK>; clock-names = "ciu", "biu"; + resets = <&sys_ctrl PERIPH_RSTDIS0_MMC2>; bus-width = <0x4>; broken-cd; pinctrl-names = "default", "idle"; -- 1.9.1
Re: [PATCH] tty: serial: msm: Add runtime PM and system sleep support
Hi, On 17 June 2016 at 15:46, Pramod Gurav wrote: > Add runtime pm and suspend/resume callback support to serial msm > driver so that clock resources are managed runtime to save power. > Any comments on this patch? > Signed-off-by: Pramod Gurav > --- > drivers/tty/serial/msm_serial.c | 183 > > 1 file changed, 168 insertions(+), 15 deletions(-) > >
Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap
On 2016/8/24 18:30, Catalin Marinas wrote: > On Wed, Aug 24, 2016 at 05:00:50PM +0800, Leizhen (ThunderTown) wrote: >> >> >> On 2016/8/24 1:28, Catalin Marinas wrote: >>> On Mon, Aug 22, 2016 at 12:19:04PM +0800, Leizhen (ThunderTown) wrote: On 2016/7/20 17:19, Catalin Marinas wrote: > On Wed, Jul 20, 2016 at 10:46:27AM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/8 21:54, Catalin Marinas wrote: >>> 8< >>> diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c >>> index dbd12ea8ce68..c753fa804165 100644 >>> --- a/arch/arm64/mm/flush.c >>> +++ b/arch/arm64/mm/flush.c >>> @@ -75,7 +75,8 @@ void __sync_icache_dcache(pte_t pte, unsigned >>> long addr) >>> if (!page_mapping(page)) >>> return; >>> >>> - if (!test_and_set_bit(PG_dcache_clean, &page->flags)) >>> + if (!test_and_set_bit(PG_dcache_clean, &page->flags) || >>> + PageDirty(page)) >>> sync_icache_aliases(page_address(page), >>> PAGE_SIZE << compound_order(page)); >>> else if (icache_is_aivivt()) >>> 8<- >> >> Do you plan to send this patch? My colleagues told me that if our >> patches are quite different, it should be Signed-off-by you. > > The reason I'm not sending it is that I don't fully understand how it > solves the problem for a shared file mmap(), not just hugetlbfs. As I > said in an earlier email: after an msync() in user space we > should flush the pages to disk via write_cache_pages(). This function Hi Catalin: I'm so sorry for my fault. The previous small pages test result I actually ran on ramfs. Today, I ran the case on harddisk fs, it worked well without this patch. Summarized as follows: small pages on ramfs: need this patch small pages on harddisk fs: no need this patch hugetlbfs: need this patch >>> >>> I would add: >>> >>> small pages over nfs: fails with or without this patch >>> >>> (tested on Juno, Cortex-A57; seems to be fixed if I remove the >>> PG_dcache_clean test altogether but, well, we end up over-flushing) >>> >>> I assume that when using a hard drive, it goes through the block I/O >>> layer and we may have a flush_dcache_page() called when the kernel is >>> about to read a page that has been mapped in user space. This would >>> clear the PG_dcache_clean bit and subsequent __sync_icache_dcache() >>> would perform cache maintenance. >>> >>> Could you try on your system the test case without the msync() call? I'm >> >> According to my test results: without msync, the test case may failed. > > Thanks. Just to be clear, does the test generate a file on on a hard > drive? Yes. I checked that the intermediate file had been generated. > >> 10-175-112-211:~ # ./tst_small_page_no_msync >> Test is Failed: The result is 0x316b9, expect = 0x365a5 >> 10-175-112-211:~ # ./tst_small_page_no_msync >> Test is Failed: The result is 0x31023, expect = 0x31efa >> 10-175-112-211:~ # ./tst_small_page_no_msync >> Test is Passed: The result is 0x31efa, expect = 0x31efa >> >> 10-175-112-211:~ # ./tst_small_page >> Test is Passed: The result is 0x31eb7, expect = 0x31eb7 >> 10-175-112-211:~ # ./tst_small_page >> Test is Passed: The result is 0x3111f, expect = 0x3111f >> 10-175-112-211:~ # ./tst_small_page >> Test is Passed: The result is 0x3111f, expect = 0x3111f > > How many tests did you run for the "passed" case? With NFS it may I ran ./tst_small_page_no_msync and ./tst_small_page 10 times for each. > sometime take minutes before a failure (I use the "watch" command with a > slightly modified test to return non-zero in case of value mismatch). > > While we indeed see failures on multiple filesystem types, I wonder > whether this test case is actually expected to work. If I modify the > test to pass O_TRUNC to open(), I can no longer see failures. So any > standard tool that copies/creates executable files (gcc, dpkg, cp, rsync > etc.) wouldn't encounter such issues since they truncate the original > file and old page cache pages would be removed. > > Do you have a real use-case where a task mmap's an executable file, > modifies it in place and expects another task to see the new > instructions without user-space cache maintenance? No, it's just a test case created by testers. >
Re: [PATCH 00/13] arm64: Allwinner A64 support based on sunxi-ng
Hi Maxime, thanks for your answer, much appreciated! On 23/08/16 20:31, Maxime Ripard wrote: > Hi Andre, > > On Mon, Aug 01, 2016 at 02:43:06AM +0100, André Przywara wrote: >> Hi Maxime, >> >> On 26/07/16 21:30, Maxime Ripard wrote: >>> Hi, >>> >>> Here is the previous A64 patches made by Andre [1], reworked to use >>> the new sunxi-ng clock framework. >>> >>> This uses the current H3 clock code, as both are really similar. The >>> first patches are just meant to rework slightly the H3 code, before >>> introducing the A64-related patches. >>> >>> Some WiP stuff have been removed, such as the MMC part, but this serie >>> already has a decent amount of devices supported: uart, i2c, rsb, etc. >> >> Thanks very much for looking into this and compiling this series! >> >> In general this looks good to me - apart from the sunxi-ng clock usage. >> I think I have some small fixes to the DT (have to compare against my >> latest local branch), I will comment on this later. >> >> As I think I never officially expressed my concerns about the new sunxi >> clock system, so I use that opportunity here ;-) >> >> As this became quite a long read, here a TL;DR: >> - We consider using an SCPI based clock system for the A64, alongside >> allwinner,simple-gates and fixed clocks. We try to avoid any Allwinner >> specific clocks (apart from the simple-gates). >> - ARM Trusted Firmware provides the SCPI implementation - for now, later >> we may move this into a possible arisc firmware. >> - We upstream some basic DT first, possibly omitting any controversial >> clock parts at all. >> >> Let me know what you think! >> >> >> Now the long part >> >> Basically I see those issues with the new clocks: >> - sunxi-ng requires a complicated SoC specific source file in the >> kernel. Although that makes the DT pretty easy (and avoids breaking it >> the future), it ultimately requires an explicit code drop for every new >> SoC, even if they share 95% of the clocks (as H3 and A64 do, for instance). >> - This code file does not actually contain any code, instead it's just >> data and looks like it should really be presented in DT - which brings >> us back to something like the old sunxi clock scheme, which is >> apparently not considered good enough. I still wonder if we could create >> a generic sunxi-ng user, which explains the needed clocks in the DT >> instead of in code. I admit that looks like quite some work. >> - It makes it quite hard for any other DT user (*BSD, U-Boot) to use the >> clocks, since they would have to copy quite verbatim the Linux >> implementation choice. This is admittedly also true for the old clock >> framework, but still unfortunate. > > 3 - You never get a complete clock support for any SoC, requirining > for pretty much every driver to create from scratch a new clock > driver. I don't understand this. Are you referring to the old clock system? Or to the proposed SCPI approach? Or to sunxi-ng with DT descriptions? And why would a *driver* care about a specific clock if it's using the common clock framework? Confused ... > 4 - You require for all these clocks drivers some Ack from both the DT > and clocks maintainers, who both said they were fed up with this. Again which new clock drivers? The old sunxi-clks? For the SCPI version I propose we don't need any ACKs (apart from the new .dtsi, maybe), because the clocks are already there. > 5 - If you realise some day down the road that the parenting > relationship is not right, or that some clock is not doing what > you thought it was, you can't really fix it properly because of > the DT stability you wanted us to enforce. > >> So as mentioned several times before, I am looking into a more firmware >> driven clock system using the SCPI[1] framework. >> The idea is: >> - The basic clocks (OSC24M, OSC32K, AHB1, APB1, APB2, PERIPH0) are >> expressed as fixed clocks. If I am not mistaken, Allwinner recommends >> certain frequencies for them anyway, so we just use that and set them up >> before booting Linux, for instance in ATF. >> - The gates clocks are expressed as before, but by defining a generic DT >> compatible fallback name. I have no idea why every SoC enters its name >> into the simple_gates.c source file, while just mentioning the >> compatible string in the DT bindings and using the SoC specific name >> together with a generic fallback like "allwinner,sunxi-simple-gates" >> would suffice. This means that we don't need to touch simple-gates.c >> anymore most of the time. >> - Any clock that can (and has to) be programmed with a variable >> frequency is expressed as an SCPI clock. This interface allows basically >> querying and setting a frequency - not very powerful, but sufficient for >> the clocks I checked. Firmware then takes the burden of programming the >> respective clock register - which is not rocket science if we lock the >> base clocks to a certain frequency. >> >> The advantage of this approach would be: >> - Th
Re: [PATCH 1/2] clk: samsung: exynos5260: Move struct samsung_cmu_info to init section
On 08/24, Chanwoo Choi wrote: > On 2016년 08월 24일 13:43, Stephen Boyd wrote: > > On 08/23, Sylwester Nawrocki wrote: > >> So the saving is rather insignificant but the patch doesn't make > >> things worse and I'd say it might be worth applying. > >> > > > > Sounds good. This sort of information should be in the commit > > text though. Talking about const doesn't make any sense to me. > > Do you mean that 'const' is initconst secion? No. Marking it as initconst in the patch is correct. > If possible, could you explain the anything > why you don't make sense about 'const'? > I'm just saying that the reasoning to move it from the text section to the data section shouldn't be because of const. There should be better reasons to do this, like size benefits. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH v2 1/2] arm64: dts: hikey: extend default cma size to 128MB
To support display in Debian on HiKey, cma heap is used to allocate
graphic buffers. The default size of CMA is 16 MB which is not enough.
Increase the default CMA size to 128 MB.
cc: Fathi Boudra
cc: John Stultz
cc: Xinliang Liu
Signed-off-by: Guodong Xu
Acked-by: Rob Herring
---
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 9e4e06a..dba3c13 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -57,8 +57,15 @@
console-size= <0x0002>;
ftrace-size = <0x0002>;
};
- };
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x 0x0800>;
+ linux,cma-default;
+ };
+ };
reboot-mode-syscon@5f01000 {
compatible = "syscon", "simple-mfd";
--
1.9.1
Re: [dm-devel] [PATCH v05 04/72] dm-log-userspace.h: use __u32, __s32 and __u64 from linux/types.h
On 08/23/16 13:42, Mikko Rapeli wrote: > On Tue, Aug 23, 2016 at 02:28:19PM +, Bart Van Assche wrote: >> On 08/23/16 06:57, Bart Van Assche wrote: >>> On 08/22/16 11:32, Mikko Rapeli wrote: - * uint32_t (*get_region_size)(struct dm_dirty_log *log); + * __u32 (*get_region_size)(struct dm_dirty_log *log); >>> >>> uint32_t is a type that is defined by ANSI C but __u32 not. So this >>> change looks wrong to me. Would it have been sufficient to add "#include >>> " and keep the uint32_t etc. type names? >> >> Answering my own question: adding "#include " wouldn't be >> sufficient. How about adding the following code that also occurs in a >> few other uapi header files? >> >> #ifndef __KERNEL__ >> #include >> #endif >> #include > > I have tried that before but I was instructed to use the linux/types.h > versions. For example https://lkml.org/lkml/2015/6/1/160 > > But lately drm and fuse and some others have questioned this approach and > would like to use/continue using C99 stdint.h types. Hello Mikko, Thanks for the feedback. I have a minor comment though about your patch: are you aware that you have changed uint64_t into __u64 in source code comments but that int64_t has not been changed into __s64? Bart.
Re: [PATCH 3/5] hwrng: amd: Be consitent with the driver name
On Wed, Aug 24, 2016 at 03:51:22PM +0200, LABBE Corentin wrote:
> On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote:
> > On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote:
> > > The driver name is displayed each time differently.
> > > This patch make use of the same name everywhere.
> > >
> > > Signed-off-by: LABBE Corentin
> > > ---
> > > drivers/char/hw_random/amd-rng.c | 13 ++---
> > > 1 file changed, 6 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/char/hw_random/amd-rng.c
> > > b/drivers/char/hw_random/amd-rng.c
> > > index d0042f5..d0a806a 100644
> > > --- a/drivers/char/hw_random/amd-rng.c
> > > +++ b/drivers/char/hw_random/amd-rng.c
> > > @@ -31,7 +31,7 @@
> > > #include
> > > #include
> > >
> > > -#define PFX KBUILD_MODNAME ": "
> > > +#define DRV_NAME "AMD768-HWRNG"
> > >
> > > /*
> > > * Data for PCI driver interface
> > > @@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
> > > }
> > >
> > > static struct hwrng amd_rng = {
> > > - .name = "amd",
> > > + .name = DRV_NAME,
> >
> > Hmm, this changes a sysfs-exported name which has the potential
> > to break user-space. So I think you'd need to a stronger argument
> > to do it other than just cleaning it up.
> >
>
> amd is really really too generic.
Well this would have been a good reason to change it before it
went into the kernel.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH] arm64: dts: hikey: extend default cma size to 128MB
On 24 August 2016 at 23:10, Rob Herring wrote:
> On Wed, Aug 24, 2016 at 8:35 AM, Guodong Xu wrote:
>> To support display in Debian on HiKey, cma heap is used to allocate
>> graphic buffers. The default size of CMA is 16 MB which is not enought.
>
> s/enought/enough/
>
>>
>> Increase the default CMA size to 128 MB.
>>
>> cc: Rob Herring
>> cc: Fathi Boudra
>> cc: John Stultz
>> cc: Xinliang Liu
>> Signed-off-by: Guodong Xu
>> ---
>> arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 14 ++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> index 4a51058..abb3434 100644
>> --- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> +++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
>> @@ -45,6 +45,20 @@
>> <0x 0x2200 0x 0x1c00>;
>> };
>>
>> + reserved-memory {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + /* global autoconfigured region for contiguous allocations */
>> + linux,cma {
>> + compatible = "shared-dma-pool";
>> + reusable;
>> + size = <0x 0x0800>;
>> + linux,cma-default;
>> + };
>> + };
>> +
>> pstore: pstore@0x21f0 {
>
> So what is upstream (as of 4.8) for ramoops also uses reserved-memory,
> so you should separately fix this.
>
Got it. I will fix and resend.
> Acked-by: Rob Herring
>
Thanks.
-Guodong
> Rob
Re: [PATCH 2/2] clk: mvebu: dynamically allocate resources in Armada CP110 system controller
On 08/23, Marcin Wojtas wrote:
> Original commit, which added support for Armada CP110 system controller
> used global variables for storing all clock information. It worked
> fine for Armada 7k SoC, with single CP110 block. After dual-CP110 Armada 8k
> was introduced, the data got overwritten and corrupted.
>
> This patch fixes the issue by allocating resources dynamically in the
> driver probe and storing it as platform drvdata.
>
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
>
Please drop the space between fixes tag and the signoff.
> Signed-off-by: Marcin Wojtas
> ---
> drivers/clk/mvebu/cp110-system-controller.c | 29
> -
> 1 file changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/clk/mvebu/cp110-system-controller.c
> b/drivers/clk/mvebu/cp110-system-controller.c
> index 0835e1d..2bd87d2 100644
> --- a/drivers/clk/mvebu/cp110-system-controller.c
> +++ b/drivers/clk/mvebu/cp110-system-controller.c
> @@ -81,13 +81,6 @@ enum {
> #define CP110_GATE_EIP15025
> #define CP110_GATE_EIP19726
>
> -static struct clk *cp110_clks[CP110_CLK_NUM];
> -
> -static struct clk_onecell_data cp110_clk_data = {
> - .clks = cp110_clks,
> - .clk_num = CP110_CLK_NUM,
> -};
> -
> struct cp110_gate_clk {
> struct clk_hw hw;
> struct regmap *regmap;
> @@ -195,7 +188,8 @@ static int cp110_syscon_clk_probe(struct platform_device
> *pdev)
> struct regmap *regmap;
> struct device_node *np = pdev->dev.of_node;
> const char *ppv2_name, *apll_name, *core_name, *eip_name, *nand_name;
> - struct clk *clk;
> + struct clk_onecell_data *cp110_clk_data;
> + struct clk *clk, **cp110_clks;
> u32 nand_clk_ctrl;
> int i, ret;
>
> @@ -208,6 +202,20 @@ static int cp110_syscon_clk_probe(struct platform_device
> *pdev)
> if (ret)
> return ret;
>
> + cp110_clks = devm_kcalloc(&pdev->dev, sizeof(struct clk *),
> + CP110_CLK_NUM, GFP_KERNEL);
> + if (IS_ERR(cp110_clks))
Doesn't that return NULL on error?
> + return PTR_ERR(cp110_clks);
> +
> + cp110_clk_data = devm_kzalloc(&pdev->dev,
> + sizeof(struct clk_onecell_data),
sizeof(*cp110_clk_data) please
> + GFP_KERNEL);
> + if (IS_ERR(cp110_clk_data))
Doesn't that return NULL on error?
> + return PTR_ERR(cp110_clk_data);
> +
> + cp110_clk_data->clks = cp110_clks;
> + cp110_clk_data->clk_num = CP110_CLK_NUM;
> +
> /* Register the APLL which is the root of the clk tree */
> of_property_read_string_index(np, "core-clock-output-names",
> CP110_CORE_APLL, &apll_name);
> @@ -335,10 +343,12 @@ static int cp110_syscon_clk_probe(struct
> platform_device *pdev)
> cp110_clks[CP110_MAX_CORE_CLOCKS + i] = clk;
> }
>
> - ret = of_clk_add_provider(np, cp110_of_clk_get, &cp110_clk_data);
> + ret = of_clk_add_provider(np, cp110_of_clk_get, cp110_clk_data);
It would be nice if this could be converted to
of_clk_add_hw_provider().
> if (ret)
> goto fail_clk_add;
>
> + platform_set_drvdata(pdev, cp110_clks);
> +
> return 0;
>
> fail_clk_add:
> @@ -365,6 +375,7 @@ fail0:
>
> static int cp110_syscon_clk_remove(struct platform_device *pdev)
> {
> + struct clk **cp110_clks = platform_get_drvdata(pdev);
Is this variable unused now?
> int i;
>
> of_clk_del_provider(pdev->dev.of_node);
> --
> 1.8.3.1
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: + stackdepot-fix-mempolicy-use-after-free.patch added to -mm tree
On Fri, 19 Aug 2016, a...@linux-foundation.org wrote: > From: Vegard Nossum > Subject: stackdepot: fix mempolicy use-after-free > > This patch fixes the following: > > BUG: KASAN: use-after-free in alloc_pages_current+0x363/0x370 at addr > 88010b48102c > Read of size 2 by task trinity-c2/15425 > CPU: 0 PID: 15425 Comm: trinity-c2 Not tainted 4.8.0-rc2+ #140 > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > rel-1.9.3-0-ge2fc41e-prebuilt.qemu-proje > ct.org 04/01/2014 > 88010b481040 88010b557650 81f08d11 88011a40d380 > 88010b481028 88010b557678 815dac7c 88010b557708 > 88010b481028 88011a40d380 88010b5576f8 815daf15 > Call Trace: > [] dump_stack+0x65/0x84 > [] kasan_object_err+0x1c/0x70 > [] kasan_report_error+0x1f5/0x4c0 > [] __asan_report_load2_noabort+0x3e/0x40 > [] alloc_pages_current+0x363/0x370< > use-after-free > [] depot_save_stack+0x3f4/0x490 > [] save_stack+0xb5/0xd0 > [] kasan_slab_free+0x71/0xb0 > [] kmem_cache_free+0xa3/0x290 > [] __mpol_put+0x19/0x20 < free > [] do_exit+0x1515/0x2b70 > [] do_group_exit+0xf4/0x2f0 > [] get_signal+0x53d/0x1120 > [] do_signal+0x83/0x1e20 > [] exit_to_usermode_loop+0xaf/0x140 > [] syscall_return_slowpath+0x144/0x170 > [] ret_from_fork+0x2f/0x40 > Read of size 2 by task trinity-c2/15425 > > The problem is that we may be calling alloc_pages() in a code path where > current->mempolicy has already been freed. > > By passing __GFP_THISNODE we will always use default_mempolicy (which > cannot be freed). > > Link: https://lkml.org/lkml/2016/7/29/277 > Link: https://github.com/google/kasan/issues/35 > Link: > http://lkml.kernel.org/r/1471603265-31804-1-git-send-email-vegard.nos...@oracle.com > Signed-off-by: Vegard Nossum > Acked-by: Dmitry Vyukov > Cc: Alexander Potapenko > Cc: Andrey Ryabinin > Signed-off-by: Andrew Morton > --- > > lib/stackdepot.c |6 ++ > 1 file changed, 6 insertions(+) > > diff -puN lib/stackdepot.c~stackdepot-fix-mempolicy-use-after-free > lib/stackdepot.c > --- a/lib/stackdepot.c~stackdepot-fix-mempolicy-use-after-free > +++ a/lib/stackdepot.c > @@ -243,6 +243,12 @@ depot_stack_handle_t depot_save_stack(st > alloc_flags &= ~GFP_ZONEMASK; > alloc_flags &= (GFP_ATOMIC | GFP_KERNEL); > alloc_flags |= __GFP_NOWARN; > + /* > + * Avoid using current->mempolicy which may already have > + * been freed -- we may be in the process of saving the > + * stack for exactly that __mpol_put() call. > + */ > + alloc_flags |= __GFP_THISNODE; > page = alloc_pages(alloc_flags, STACK_ALLOC_ORDER); > if (page) > prealloc = page_address(page); This is wrong, it unnecessarily restricts the allocation to a local node and has a greater chance to fail. Passing __GFP_THISNODE here is only an implementation detail of mempolicies to avoid reference to freed policy. It is easy to fix by using alloc_pages_node(NUMA_NO_NODE, alloc_flags, STACK_ALLOC_ORDER) instead of alloc_pages() directly.
MAINTAINERS without commits in the last 3 years
Many email addresses in MAINTAINERS no longer work so many sections in MAINTAINERS could likely be considered either obsolete or unmaintained. Marking these sections appropriately or simply removing the sections would make MAINTAINERS and get_maintainer.pl more useful. These M: entries in MAINTAINERS haven't authored or had any -by: signature entries in git log for the last 3 years. Some of these, like sta...@kernel.org and triv...@kernel.org, are obviously addresses that should not be deleted from MAINTAINERS, but most of them are candidates for removal or update. The email addresses below are also bcc'd here to see what bounces. The list of the bounces will be collected. Thoughts? aacr...@adaptec.com aacr...@microsemi.com achim_leub...@adaptec.com adap...@gmail.com adilger.ker...@dilger.ca a...@cwi.nl ag...@suse.com a...@comnets.uni-bremen.de a...@alarsen.net ali...@web.de alist...@devzero.co.uk aloisio.alme...@openbossa.org andrew.d.henr...@intel.com andrew.hen...@gmail.com andre...@usa.net anil.s.keshavamur...@intel.com arhu...@freaks-unidos.net arvin...@gmail.com ath9k-de...@qca.qualcomm.com ballabio_da...@emc.com bcm-kernel-feedback-l...@broadcom.com ber...@plugable.com bi...@melbpc.org.au brij...@gmail.com brk...@us.ibm.com brucech...@via.com.tw castet.matth...@free.fr ccaul...@redhat.com cezary.jackiew...@gmail.com chaoming...@realsil.com.cn char...@alacritech.com chess...@tux.org chr...@sous-sol.org c...@cs.cmu.edu co...@colino.net courmi...@gmail.com dept-gelinuxnic...@qlogic.com dept-hsglinuxnic...@qlogic.com dev...@lanana.org dh.herrm...@googlemail.com d...@opfer-online.de dm-de...@redhat.com dmitry.tarnya...@lockless.no d...@syst.com.br d...@dotat.at douglas_warze...@dell.com dougthomp...@xmission.com drw...@gmail.com dsax...@plexity.net d...@gentoo.org duncan.sa...@free.fr e...@pasemi.com eib...@gdsys.de epa...@parisplace.org erik.and...@gmail.com everest-linux...@qlogic.com fa...@cs.unc.edu f...@drama.obuda.kando.hu fisc...@norbit.de fiz...@tin.it florian.c.schilha...@googlemail.com florianschandi...@gmx.de for...@alittletooquiet.net fr...@f-seidel.de fujita.tomon...@lab.ntt.co.jp fun...@jurai.org gilles.mul...@lip6.fr go...@debian.or.jp guillaume.lign...@gmail.com gust...@padovan.org hal.rosenst...@gmail.com haraldwe...@viatech.com henk.vergo...@gmail.com her...@canonical.com hlhun...@gmail.com hskinnem...@gmail.com hswon...@gmail.com hubert.feurst...@contec.at ibm-a...@hmh.eng.br inaky.perez-gonza...@intel.com infinip...@intel.com i...@jurassic.park.msu.ru intel-linux-...@intel.com io...@badula.org jansimon.moel...@gmx.de jarkko.lavi...@nokia.com ja...@wilsonet.com jayakumar.a...@gmail.com jay...@intworks.biz jclib...@gmail.com jd...@addtoit.com j.du...@option.com j...@parisc-linux.org jens.tapro...@taprogge.org jer...@goop.org j...@trained-monkey.org ji...@cam.ac.uk jirisl...@gmail.com jjcia...@raiz.uncu.edu.ar joc...@scram.de jo...@lazybastard.org johan.hedb...@gmail.com j...@johnmccutchan.com jonat...@buzzard.org.uk jon.nettle...@gmail.com josh.h.mor...@us.ibm.com j...@f6fbb.org jreu...@yaina.de j...@vanzandt.mv.com jtp.p...@samsung.com jue...@gmail.com juhle...@akamai.com k...@fi.muni.cz ker...@savoirfairelinux.com kevin.cur...@farsite.co.uk k...@gmx.de k...@reisers.ca klass...@mathematik.tu-chemnitz.de kou.ishiz...@toshiba.co.jp k...@deine-taler.de kuz...@ms2.inr.ac.ru lafo...@gnumonks.org lafo...@openezx.org lauro.venan...@openbossa.org lcostant...@gmail.com l...@flatcap.org l...@kernel.org lene...@twibble.org linasveps...@gmail.com linux-dri...@qlogic.com linuxdriv...@attotech.com linux-graphics-maintai...@vmware.com linux-ker...@hansmi.ch linux-net-driv...@solarflare.com linuxr...@lsi.com li...@simtec.co.uk linuxw...@intel.com linux-wi...@intel.com lio...@gmail.com liqin.li...@gmail.com m...@melware.de maintain...@bluecherrydvr.com mal...@foss.arm.com manohar.va...@gmail.com mark.brown...@gmail.com matt...@wil.cx m...@qti.qualcomm.com mbroe...@plusserver.de mcg...@gmail.com mche...@kernel.org mdharm-...@one-eyed-alien.net m...@sgi.com m.huls...@tudelft.nl miguel.ojeda.sando...@gmail.com m...@compulab.co.il miq...@df.uba.ar mi...@sfgoth.com m...@volny.cz m...@ucw.cz mkpe...@internode.on.net mostr...@earthlink.net m...@selenic.com mpor...@kernel.crashing.org mr.swami.re...@ti.com neepa...@cisco.com nic_s...@realtek.com ning@intel.com n...@holomorphy.com oa...@yahoo.com o...@artecdesign.ee o.lo...@laposte.net o...@riede.org pantelis.anton...@gmail.com pau...@au.ibm.com p...@vandrovec.name p...@sgi.com pgaik...@nvidia.com ph...@gnu.org p...@gelato.unsw.edu.au p...@eslack.org pv-driv...@vmware.com qla2xxx-upstr...@qlogic.com qlogic-storage-upstr...@qlogic.com r...@jetztechnologies.com riverful@samsung.com ri...@nvidia.com rl...@rlove.org rminn...@sandia.gov r...@tech9.net ron.mer...@qlogic.com roy...@zerezo.com rub...@unipv.it saff...@us.ibm.com sako...@gmail.com sam...@sortiz.org sant...@chelsio.com sc...@spiteful.org secur...@kernel.org sfre...@samba.org shiraz.linux.ker
Re: MAINTAINERS without commits in the last 3 years
> Am 24.08.2016 um 19:33 schrieb Joe Perches : > > Many email addresses in MAINTAINERS no longer work so many > sections in > MAINTAINERS could likely be considered either > obsolete or unmaintained. > > Marking these sections appropriately or simply removing the > sections would make MAINTAINERS and get_maintainer.pl more > useful. > > These M: entries in MAINTAINERS haven't authored or had any > -by: signature entries in git log for the last 3 years. > > Some of these, like sta...@kernel.org and triv...@kernel.org, are > obviously addresses that should not be deleted from MAINTAINERS, > but most of them are candidates for removal or update. > > The email addresses below are also bcc'd here to see what bounces. > The list of the bounces will be collected. > > Thoughts? > > aacr...@adaptec.com > aacr...@microsemi.com > achim_leub...@adaptec.com > adap...@gmail.com > adilger.ker...@dilger.ca > a...@cwi.nl > ag...@suse.com This is an alias for suse.de, so I guess it's safe to remove from the list ;). Alex
Re: [PATCH 13/34] clk: clps711x: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Alexander Shiyan > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
linux-next: Tree for Aug 25
Hi all, Changes since 20160824: The kbuild tree still had its build warnings for PowerPC, for which I reverted a commit. Non-merge commits (relative to Linus' tree): 3682 3689 files changed, 170524 insertions(+), 63738 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc and sparc64 defconfig. Below is a summary of the state of the merge. I am currently merging 240 trees (counting Linus' and 34 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (4935e04ef431 Merge branch 'for-linus-4.8-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rw/uml) Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when not configured) Merging arc-current/for-curr (c57653dc94d0 ARC: export __udivdi3 for modules) Merging arm-current/fixes (87eed3c74d7c ARM: fix address limit restoration for undefined instructions) Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs for v4.7-rc2) Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init()) Merging powerpc-fixes/fixes (ca49e64f0cb1 selftests/powerpc: Specify we expect to build with std=gnu99) Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support is disabled) Merging net/master (51af96b53469 mlxsw: router: Enable neighbors to be created on stacked devices) Merging ipsec/master (11d7a0bb95ea xfrm: Only add l3mdev oif to dst lookups) Merging netfilter/master (b75911b66ad5 netfilter: cttimeout: fix use after free error when delete netns) Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes') Merging wireless-drivers/master (b64abcb7dae6 brcmfmac: Change vif_event_lock to spinlock) Merging mac80211/master (4d0bd46a4d55 Revert "wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel") Merging sound-current/for-linus (abaa2274811d ALSA: hda/realtek - fix headset mic detection for MSI MS-B120) Merging pci-current/for-linus (21c80c9fefc3 x86/PCI: VMD: Fix infinite loop executing irq's) Merging driver-core.current/driver-core-linus (694d0d0bb203 Linux 4.8-rc2) Merging tty.current/tty-linus (87a713c8ffca 8250/fintek: rename IRQ_MODE macro) Merging usb.current/usb-linus (53e5f36fbd24 USB: avoid left shift by -1) Merging usb-gadget-fixes/fixes (a0ad85ae866f usb: dwc3: gadget: stop processing on HWO set) Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add WeTelecom 0x6802 and 0x6803 products) Merging usb-chipidea-fixes/ci-for-usb-stable (c4e94174983a usb: chipidea: udc: don't touch DP when controller is in host mode) Merging staging.current/staging-linus (eafe5cfe7189 Merge tag 'iio-fixes-for-4.8a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into work-linus) Merging char-misc.current/char-misc-linus (51c70261b257 Revert "android: binder: fix dangling pointer comparison") Merging input-current/for-linus (e3a888a4bff0 Input: ads7846 - remove redundant regulator_disable call) Merging crypto-current/master (901d3d4fee83 crypto: vmx - fix null dereference in p8_aes_xts_crypt) Merging ide/master (797cee982eef Merge branch 'stable-4.8' of git://git.infradead.org/users/pcmoore/audit) Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms v
Re: [PATCH v2] clk: fixed-factor: add optional dt-binding clock-flags
On 07/04, Jongsung Kim wrote: > On 2016년 07월 02일 09:20, Stephen Boyd wrote: > > Do you actually have an IC on the board that is doing some fixed > > factor calculation? Or is this a clk driver design where we are > > listing out each piece of an SoC's clk controller in DT? > > > The SoC has several PLLs of identical design, and one of them is divided > to half and used for CPUs. The fixed-factor-clock represents the divider. > Ok, so it sounds like we can have the driver that registers the CPU PLL also register the fixed factor clk? I fail to see why we need this from DT in that case. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3 0/5] dts patches for qcom tsens support
On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote:
> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
> > > Hey Andy,
> > >
> > > This is a respin of v2 with some minor fixes pointed out by Rob.
> > > Please pull these in for 4.9
> > >
> > > Thanks,
> > > Rajendra
> >
> > I pulled these in.
>
> Did you try to read the content of the qfprom from userspace?
>
> $ uname -a
> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016
> aarch64
> aarch64 aarch64 GNU/Linux
> $ lsmod
> Module Size Used by
> nvmem_qfprom 16384 0
> nvmem_core 24576 1 nvmem_qfprom
> $ ls -la /sys/bus/nvmem/devices/
>
> total 0
> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
> ../../../devices/platform/soc/5c000.qfprom/qfprom0
> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem
>
> [spontaneous reboot]
>
> This using agross's for-next tree as of today ("54ba896 Merge branch
> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.
This was reported in some other forum as well, after some investigation
we concluded that it looks like one of the entries are locked down -
probably from some security reason.
I'm not aware of any way to query this configuration. But the main use
case for the qfprom is in-kernel access to certain elements and that we
do get from the driver as is...
Regards,
Bjorn
Re: [PATCH 15/34] clk: efm32gg: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Uwe Kleine-König > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 1/2] clk: mvebu: set flags in CP110 gate clock
On 08/23, Marcin Wojtas wrote:
> Armada CP110 system controller comprise its own routine responsble
> for registering gate clocks. Among others 'flags' field in
> struct clk_init_data was not set, using a random values, which
> may cause an unpredicted behavior.
>
> This patch fixes the problem by setting CLK_IS_BASIC flag for
> all gated clocks of Armada 7k/8k SoCs family.
>
> Fixes: d3da3eaef7f4 ("clk: mvebu: new driver for Armada CP110 system ...")
>
> Signed-off-by: Marcin Wojtas
> ---
> drivers/clk/mvebu/cp110-system-controller.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/clk/mvebu/cp110-system-controller.c
> b/drivers/clk/mvebu/cp110-system-controller.c
> index 7fa42d6..0835e1d 100644
> --- a/drivers/clk/mvebu/cp110-system-controller.c
> +++ b/drivers/clk/mvebu/cp110-system-controller.c
> @@ -144,6 +144,7 @@ static struct clk *cp110_register_gate(const char *name,
>
> init.name = name;
> init.ops = &cp110_gate_ops;
> + init.flags = CLK_IS_BASIC;
Please don't use CLK_IS_BASIC unless you need it (so far only TI
clks seem to want it?). Just set it to 0 if possible.
> init.parent_names = &parent_name;
> init.num_parents = 1;
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCH 14/34] clk: cs2000: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Kuninori Morimoto > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v3 0/5] dts patches for qcom tsens support
On 24 August 2016 at 22:13, Bjorn Andersson wrote:
> On Wed 24 Aug 03:22 PDT 2016, Paolo Pisati wrote:
>
>> On Wed, Aug 17, 2016 at 02:33:40PM -0500, Andy Gross wrote:
>> > On Wed, Aug 17, 2016 at 10:48:43AM +0530, Rajendra Nayak wrote:
>> > > Hey Andy,
>> > >
>> > > This is a respin of v2 with some minor fixes pointed out by Rob.
>> > > Please pull these in for 4.9
>> > >
>> > > Thanks,
>> > > Rajendra
>> >
>> > I pulled these in.
>>
>> Did you try to read the content of the qfprom from userspace?
>>
>> $ uname -a
>> Linux dragon410c 4.8.0-rc1+ #6 SMP PREEMPT Wed Aug 24 11:11:02 CEST 2016
>> aarch64
>> aarch64 aarch64 GNU/Linux
>> $ lsmod
>> Module Size Used by
>> nvmem_qfprom 16384 0
>> nvmem_core 24576 1 nvmem_qfprom
>> $ ls -la /sys/bus/nvmem/devices/
>> total 0
>> drwxr-xr-x 2 root root 0 Aug 24 10:17 .
>> drwxr-xr-x 4 root root 0 Aug 24 10:15 ..
>> lrwxrwxrwx 1 root root 0 Aug 24 10:17 qfprom0 ->
>> ../../../devices/platform/soc/5c000.qfprom/qfprom0
>> $ cat /sys/bus/nvmem/devices/qfprom0/nvmem
>>
>> [spontaneous reboot]
>>
>> This using agross's for-next tree as of today ("54ba896 Merge branch
>> 'arm64-defconfig-for-4.9' into all-for-4.8") and defconfig.
>
> This was reported in some other forum as well, after some investigation
> we concluded that it looks like one of the entries are locked down -
> probably from some security reason.
>
> I'm not aware of any way to query this configuration. But the main use
> case for the qfprom is in-kernel access to certain elements and that we
> do get from the driver as is...
Yeah this appears to be the case. So I guess the response is 'don't
do that'. At least don't cat or od the file. You need to seek and
read.
Andy
Re: [PATCH 3/4] dt-binding: remoteproc: venus rproc dt binding document
On Wed 24 Aug 08:36 PDT 2016, Stanimir Varbanov wrote:
> Hi Rob,
>
> On 08/23/2016 08:32 PM, Rob Herring wrote:
> > On Fri, Aug 19, 2016 at 06:53:19PM +0300, Stanimir Varbanov wrote:
> >> Add devicetree binding document for Venus remote processor.
> >>
> >> Signed-off-by: Stanimir Varbanov
> >> ---
> >> .../devicetree/bindings/remoteproc/qcom,venus.txt | 33
> >> ++
> >> 1 file changed, 33 insertions(+)
> >> create mode 100644
> >> Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >> b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >> new file mode 100644
> >> index ..06a2db60fa38
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,venus.txt
> >> @@ -0,0 +1,33 @@
> >> +Qualcomm Venus Peripheral Image Loader
> >> +
> >> +This document defines the binding for a component that loads and boots
> >> firmware
> >> +on the Qualcomm Venus remote processor core.
> >
> > This does not make sense to me. Venus is the video encoder/decoder h/w,
> > right? Why is the firmware loader separate from the codec block? Why
> > rproc is used? Are there multiple clients? Naming it rproc_venus implies
> > there aren't. And why does the firmware loading need 8MB of memory at a
> > fixed address?
> >
>
> The firmware for Venus case is 5MB. And here is 8MB because of
> dma_alloc_from_coherent size restriction.
>
Then you should specify it 5MB large and we'll have to deal with this
implementation issue in the code. I've created a JIRA ticket for
the dma_alloc_from_coherent() behavior.
> The address is not really fixed, cause the firmware could support
> relocation. In this example I just picked up the next free memory region
> in memory-reserved from msm8916.dtsi.
>
In 8974 we do have a physical region where it's expected to be loaded.
So in line with upcoming remoteproc work we should support referencing a
reserved-memory node with either reg or size.
In the case of spotting a "reg" we're currently better off using
ioremap. We're looking at getting the remoteproc core to deal with this
mess.
So, on 8916 I think you should use the form:
venus_mem: venus {
size = <0x50>;
};
And I don't think you should use the shared-dma-pool compatible, because
this is not a region for multiple devices to allocate dma memory out of.
Regards,
Bjorn
Re: [PATCH 28/34] clk: si5351: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth > Cc: Guenter Roeck > Cc: Sören Brinkmann > Cc: Mike Looijmans > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
linux-next: build warning after merge of the crypto tree
Hi Herbert,
After merging the crypto tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
crypto/xor.c: In function 'calibrate_xor_blocks':
crypto/xor.c:156:1: warning: label 'out' defined but not used [-Wunused-label]
out:
^
Introduced by commit
39457acda913 ("crypto: xor - skip speed test if the xor function is selected
automatically")
This build does not have XOR_SELECT_TEMPLATE set.
--
Cheers,
Stephen Rothwell
Re: [PATCH] kexec: Fix double-free when failing to relocate the purgatory.
It's reasonable. Ack. Acked-by: Baoquan He On 08/24/16 at 09:05pm, Thiago Jung Bauermann wrote: > If kexec_apply_relocations fails, kexec_load_purgatory frees pi->sechdrs > and pi->purgatory_buf. This is redundant, because in case of error > kimage_file_prepare_segments calls kimage_file_post_load_cleanup, > which will also free those buffers. > > This causes two warnings like the following, one for pi->sechdrs and the > other for pi->purgatory_buf: > > [ 18.112843] kexec-bzImage64: Loading purgatory failed > [ 18.113257] [ cut here ] > [ 18.113263] WARNING: CPU: 1 PID: 2119 at mm/vmalloc.c:1490 > __vunmap+0xc1/0xd0 > [ 18.113264] Trying to vfree() nonexistent vm area (c9e91000) > [ 18.113367] Modules linked in: > [ 18.113371] CPU: 1 PID: 2119 Comm: kexec Not tainted 4.8.0-rc3+ #5 > [ 18.113372] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS > Bochs 01/01/2011 > [ 18.113373] 88003bbb7dc8 8132eca8 > 88003bbb7e18 > [ 18.113376] 88003bbb7e08 8105f1bb > 05d281175bf8 > [ 18.113377] c9e91000 0001 > 88003e5f8c00 > [ 18.113379] Call Trace: > [ 18.113384] [] dump_stack+0x4d/0x65 > [ 18.113386] [] __warn+0xcb/0xf0 > [ 18.113388] [] warn_slowpath_fmt+0x4f/0x60 > [ 18.113390] [] ? find_vmap_area+0x19/0x70 > [ 18.113393] [] ? kimage_file_post_load_cleanup+0x47/0xb0 > [ 18.113394] [] __vunmap+0xc1/0xd0 > [ 18.113396] [] vfree+0x2e/0x70 > [ 18.113397] [] kimage_file_post_load_cleanup+0x5e/0xb0 > [ 18.113398] [] SyS_kexec_file_load+0x448/0x680 > [ 18.113401] [] ? putname+0x54/0x60 > [ 18.113403] [] ? do_sys_open+0x190/0x1f0 > [ 18.113407] [] entry_SYSCALL_64_fastpath+0x13/0x8f > [ 18.113408] ---[ end trace 158bb74f5950ca2b ]--- > > Fix by setting pi->sechdrs an pi->purgatory_buf to NULL, since vfree > won't try to free a NULL pointer. > > Signed-off-by: Thiago Jung Bauermann > --- > kernel/kexec_file.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c > index 503bc2d348e5..037c321c5618 100644 > --- a/kernel/kexec_file.c > +++ b/kernel/kexec_file.c > @@ -887,7 +887,10 @@ int kexec_load_purgatory(struct kimage *image, unsigned > long min, > return 0; > out: > vfree(pi->sechdrs); > + pi->sechdrs = NULL; > + > vfree(pi->purgatory_buf); > + pi->purgatory_buf = NULL; > return ret; > } > > -- > 1.9.1 > > > ___ > kexec mailing list > ke...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 24/34] clk: rk808: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Chris Zhong > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 29/34] clk: si570: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Guenter Roeck > Cc: Sören Brinkmann > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH V3] leds: trigger: Introduce an USB port trigger
On 24 August 2016 at 23:04, Greg KH wrote:
> On Wed, Aug 24, 2016 at 11:29:51AM +0200, Rafał Miłecki wrote:
>> On 24 August 2016 at 11:22, Greg KH wrote:
>> > On Wed, Aug 24, 2016 at 12:03:29AM +0200, Rafał Miłecki wrote:
>> >> +static ssize_t ports_show(struct device *dev, struct device_attribute
>> >> *attr,
>> >> + char *buf)
>> >> +{
>> >> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
>> >> + struct usbport_trig_data *usbport_data = led_cdev->trigger_data;
>> >> + struct usbport_trig_port *port;
>> >> + ssize_t ret = 0;
>> >> + int len;
>> >> +
>> >> + list_for_each_entry(port, &usbport_data->ports, list) {
>> >> + len = sprintf(buf + ret, "%s\n", port->name);
>> >> + if (len >= 0)
>> >> + ret += len;
>> >> + }
>> >> +
>> >> + return ret;
>> >> +}
>> >
>> > sysfs is "one value per file", here you are listing a bunch of things in
>> > one sysfs file. Please don't do that.
>>
>> OK. What do you think about creating "ports" subdirectory and creating
>> file-per-port in it? Then I'd need to bring back something like
>> "new_port" and "remove_port". Does it sound OK?
>
> Maybe, I don't know. Why is "USB" somehow unique here? Why isn't this
> the same for PCI slots/ports? pccard? sdcard? thunderbolt?
Good question. I would like to extend this USB port trigger in the
future by reacting to USB activity. This involves playing with URBs
and I believe that at that point it'd be getting too much USB specific
to /rule them all/.
--
Rafał
Re: [PATCH 27/34] clk: si514: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth > Cc: Guenter Roeck > Cc: Sören Brinkmann > Cc: Mike Looijmans > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 26/34] clk: scpi: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sudeep Holla > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
[PATCH] PCI: Export pci_enable_ptm
Export symbol so device drivers outside of the core pci subsystem can use it. Signed-off-by: Yong, Jonathan --- drivers/pci/pcie/ptm.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pci/pcie/ptm.c b/drivers/pci/pcie/ptm.c index 3b83024..bab8ac6 100644 --- a/drivers/pci/pcie/ptm.c +++ b/drivers/pci/pcie/ptm.c @@ -139,3 +139,4 @@ int pci_enable_ptm(struct pci_dev *dev, u8 *granularity) *granularity = dev->ptm_granularity; return 0; } +EXPORT_SYMBOL(pci_enable_ptm); -- 2.7.3
[PATCH] Allow pci_enable_ptm to be called outside of the pci subsystem
Allow external drivers to enable PTM bits on their respective devices. Please CC me when replying, thanks. Yong, Jonathan (1): PCI: Export pci_enable_ptm drivers/pci/pcie/ptm.c | 1 + 1 file changed, 1 insertion(+) -- 2.7.3
Re: [PATCH 33/34] clk: vt8500: Migrate to clk_hw based registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Sebastian Hesselbarth > Cc: Tony Prisk > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 34/34] clk: wm831x: Migrate to clk_hw based registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Mark Brown > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [RESEND PATCH v2 02/13] drivers: clk: st: Simplify clock binding of STiH4xx platforms
Quoting Gabriel Fernandez (2016-08-22 09:06:20) > Hi Mike, > > you forgot me ? > > Best Regards > > Gabriel > > > On 07/11/2016 08:58 AM, Gabriel Fernandez wrote: > > > > > > On 07/08/2016 06:08 PM, Michael Turquette wrote: > >> Quoting Gabriel Fernandez (2016-07-08 02:12:35) > >>> Hi Mike, > >>> > >>> On 07/08/2016 03:43 AM, Michael Turquette wrote: > Quoting Rob Herring (2016-06-19 08:04:58) > > On Thu, Jun 16, 2016 at 11:20:22AM +0200, Gabriel Fernandez wrote: > >> This patch reworks the clock binding to avoid too much detail in DT. > >> Now we have only compatible string per type of clock > >> (remark from Rob https://lkml.org/lkml/2016/5/25/492) > >> > > I have no idea what the clock trees and clock controller in these > > chips > > look like, so it's hard to say if the changes here are good. It still > > looks like things are somewhat fine grained clocks in DT. I'll leave > > it up to the platform maintainers to decide... > Is this series breaking ABI? If yes, why not do what Maxime did for > the > Allwinner/sunxi clocks and just fully convert over to a > one-node-per-clock-controller binding? This one-node-per-clock > stuff is > pretty unfortunate, and if we're deprecating platforms (patch #1) then > now might be a good time to re-evaluate the whole thing. > >>> The goal of my patchset was to be aligned with DRM / KMS development > >>> and > >>> to offer > >>> the possibility to make a correct video playback on STiH407/STiH410 > >>> platform. > >>> Our milestone is the 4.8 for that. > >>> > >>> Currently people need these patches to work. > >>> I'm not sure it's a good time to re-evaluate the whole thing. > >>> > >>> Is it possible to re-evaluate later ? > >> Are you OK to break ABI later? Or at a minimum, deprecate the current > >> binding (maintain it forever for legacy platforms) and create a new > >> clock controller binding description that supersedes the legacy binding > >> for all new platforms? > >> > >> If the answer to either question is "yes", then I'm OK to put it aside > >> for now. But if the answer to both is "no", and this patch series is > >> breaking ABI, then we really should fix it now. > > > > Hi Mike, > > i m ok to break ABI later. Hi Gabriel, This change never received any other reviews, and no pings before v4.7 was released. Sorry that it fell through the cracks, but always feel free to re-ping leading up to the merge window. Can you rebase this against -rc1? Also, do you have a plan to rework the binding to move away from the one-node-per-clock style? Regards, Mike > > > > Many Thanks ! > > > > Best Regards > > > > Gabriel. > > > >> Regards, > >> Mike > >> > >>> Best regards, > >>> Gabriel > >>> > Regards, > Mike > > >> Signed-off-by: Gabriel Fernandez > >> --- > >>.../devicetree/bindings/clock/st/st,clkgen-mux.txt | 2 +- > >>.../devicetree/bindings/clock/st/st,clkgen-pll.txt | 11 ++-- > >>.../devicetree/bindings/clock/st/st,clkgen.txt | 2 +- > >>.../devicetree/bindings/clock/st/st,quadfs.txt | 6 +-- > >>drivers/clk/st/clkgen-fsyn.c | 41 > >> ++ > >>drivers/clk/st/clkgen-mux.c| 28 > >> -- > >>drivers/clk/st/clkgen-pll.c| 62 > >> ++ > >>7 files changed, 65 insertions(+), 87 deletions(-) > >> > >> diff --git > >> a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt > >> b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt > >> index 4d277d6..9a46cb1d7 100644 > >> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt > >> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt > >> @@ -10,7 +10,7 @@ This binding uses the common clock binding[1]. > >>Required properties: > >> - compatible : shall be: > >> - "st,stih407-clkgen-a9-mux", "st,clkgen-mux" > >> + "st,stih407-clkgen-a9-mux" > >> - #clock-cells : from common clock binding; shall be set to 0. > >>diff --git > >> a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt > >> b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt > >> index c9fd674..be0b043 100644 > >> --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt > >> +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt > >> @@ -9,11 +9,10 @@ Base address is located to the parent node. See > >> clock binding[2] > >>Required properties: > >> - compatible : shall be: > >> - "st,stih407-plls-c32-a0", "st,clkgen-plls-c32" > >> - "st,stih407-plls-c32-a9", "st,clkgen-plls-c32" > >> - "sst,plls-c32-cx_0", "st,clkgen-plls-c32" > >> - "sst,plls-c32-cx_1", "st,clkgen-plls-c32" > >> - "st,stih418-plls-c28-a9
Re: [PATCH v2 0/3] *** Latency histograms - IRQSOFF,PREEMPTOFF ***
Hi Binoy, On 08/24/2016 01:17 PM, Binoy Jayan wrote: Histogram output: cat /sys/kernel/debug/tracing/events/latency/latency_irqs/hist cat /sys/kernel/debug/tracing/events/latency/latency_preempt/hist cat /sys/kernel/debug/tracing/events/latency/latency_critical_timings/hist cat /sys/kernel/debug/tracing/events/latency/latency_hrtimer_interrupt/hist [...] Changes from v1 as per comments from Steven/Daniel - Use single tracepoint for irq/preempt/critical timings by introducing a trace type field to differentiate trace type in the same tracepoint. Did you send out the right patches? This version still looks like the previous one in this regard. And wouldn't be the 'Histogram output' have only one file? Maybe I just understood something wrong here. cheers, daniel
Re: linux-next: Tree for Aug 25
Hi all, On Thu, 25 Aug 2016 14:54:59 +1000 Stephen Rothwell wrote: > > Changes since 20160824: Just a reminder that I will not doing a linux-next release until next-20160905 (i.e. Monday week my time). -- Cheers, Stephen Rothwell
Re: [PATCH v2] clk: qcom: Migrate to clk_hw based registration and OF APIs
On 08/16, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers in this driver, allowing us to > move closer to a clear split of consumer and provider clk APIs. > > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 06/34] clk: bcm: kona: Migrate to clk_hw based registration and OF APIs
On 06/01, Stephen Boyd wrote: > Now that we can use clk_hw pointers we don't need to have two > duplicate arrays holding the same mapping of clk index to clk_hw > pointer. Implement a custom clk_hw provider function to map the > OF specifier to the clk_hw instance for it. > > Cc: Alex Elder > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH 2/3] docs: split up the driver book
Em Wed, 24 Aug 2016 16:46:22 -0600
Jonathan Corbet escreveu:
> On Tue, 23 Aug 2016 11:30:16 -0300
> Mauro Carvalho Chehab wrote:
>
> > On the output text, you'll see two places with "@:c:func:threadfn()".
> >
> > The problem here is that threadfn() is a function argument. While this
> > used to work with DocBooks, now with Sphinx this is not handled well.
> >
> > I got some other similar cases on media. There, I opted to just remove
> > the () on some places, or to replace it by \(\) to avoid kernel-doc
> > to do the wrong thing.
>
> I have a different idea: why not just add another regexp to the
> kernel-doc house of cards? :)
Yeah, we can do that, but still we need to check if the references
are being properly solved (e. g. if the parser is doing the right
thing).
Ideally, the regex should also check for the next symbols, as
things like: @foo->bar should be translated to:
:c:type:`foo`\ ->bar
As Sphinx doesn't handle well non-space chars[1] before :c: or after the
grave accent ("`").
[1] Actually, it seems to work fine with a few symbols, like commas
and dots.
> The following seems to make these issues
> go away pretty nicely, and didn't cause any change at all to the
> media/gpu output...
>
> Stacking up ordering-dependent regexps is not a path to long-term joy; at
> some point, we will likely want a smarter parser for kerneldoc comments.
> But this seems to improve things for the moment.
Good!
>
> jon
>
> From 5dccd4fb9f3c0b6468f38efab8c1d6232d3e701b Mon Sep 17 00:00:00 2001
> From: Jonathan Corbet
> Date: Wed, 24 Aug 2016 16:31:15 -0600
> Subject: [PATCH] docs: Special-case function-pointer parameters in kernel-doc
>
> Add yet another regex to kernel-doc to trap @param() references separately
> and not produce corrupt RST markup.
>
> Signed-off-by: Jonathan Corbet
> ---
> scripts/kernel-doc | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/scripts/kernel-doc b/scripts/kernel-doc
> index 4f2e9049e8fa..c681e8f0ecc2 100755
> --- a/scripts/kernel-doc
> +++ b/scripts/kernel-doc
> @@ -212,6 +212,7 @@ my $anon_struct_union = 0;
> my $type_constant = '\%([-_\w]+)';
> my $type_func = '(\w+)\(\)';
> my $type_param = '\@(\w+)';
> +my $type_fp_param = '\@(\w+)\(\)'; # Special RST handling for func ptr
> params
> my $type_struct = '\&((struct\s*)*[_\w]+)';
> my $type_struct_xml = '\\&((struct\s*)*[_\w]+)';
> my $type_env = '(\$\w+)';
> @@ -292,6 +293,7 @@ my @highlights_rst = (
> # Note: need to escape () to avoid func matching later
> [$type_member_func, "\\:c\\:type\\:`\$1\$2()
> <\$1>`"],
> [$type_member, "\\:c\\:type\\:`\$1\$2 <\$1>`"],
> +[$type_fp_param, "**\$1()**"],
Hmm... shoudn't it be a reference to the struct (or to the struct member),
instead of bold?
> [$type_func, "\\:c\\:func\\:`\$1()`"],
> [$type_struct_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"],
> [$type_enum_full, "\\:c\\:type\\:`\$1 \$2 <\$2>`"],
Thanks,
Mauro
Re: [PATCH 21/34] clk: nspire: Migrate to clk_hw based OF and registration APIs
On 06/01, Stephen Boyd wrote: > Now that we have clk_hw based provider APIs to register clks, we > can get rid of struct clk pointers while registering clks in > these drivers, allowing us to move closer to a clear split of > consumer and provider clk APIs. > > Cc: Daniel Tang > Signed-off-by: Stephen Boyd > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2] PCI: altera: Retrain link in rootport mode only
On Thu, Aug 25, 2016 at 1:54 AM, Bjorn Helgaas wrote: > [+cc Ray, Scott, Jon, bcm-kernel-feedback-list] > > On Wed, Aug 24, 2016 at 03:07:52PM +0800, Ley Foon Tan wrote: >> On Mon, Aug 22, 2016 at 11:47 PM, Bjorn Helgaas wrote: >> > On Fri, Aug 19, 2016 at 04:24:38PM +0800, Ley Foon Tan wrote: >> >> Altera PCIe IP can be configured as rootport or device and they might have >> >> same vendor ID. It will cause the system hang issue if Altera PCIe is in >> >> endpoint mode and work with other PCIe rootport that from other vendors. >> >> So, add the rootport mode checking in link retrain fixup function. >> >> >> >> Signed-off-by: Ley Foon Tan >> >> --- >> >> v2: change to check PCIe type is PCI_EXP_TYPE_ROOT_PORT >> >> --- >> >> drivers/pci/host/pcie-altera.c | 3 +++ >> >> 1 file changed, 3 insertions(+) >> >> >> >> diff --git a/drivers/pci/host/pcie-altera.c >> >> b/drivers/pci/host/pcie-altera.c >> >> index 58eef99..33b6968 100644 >> >> --- a/drivers/pci/host/pcie-altera.c >> >> +++ b/drivers/pci/host/pcie-altera.c >> >> @@ -139,6 +139,9 @@ static void altera_pcie_retrain(struct pci_dev *dev) >> >> u16 linkcap, linkstat; >> >> struct altera_pcie *pcie = dev->bus->sysdata; >> >> >> >> + if (pci_pcie_type(dev) != PCI_EXP_TYPE_ROOT_PORT) >> >> + return; >> >> + >> >> if (!altera_pcie_link_is_up(pcie)) >> >> return; >> > >> > Instead of making this a PCI fixup, can you make an >> > altera_pcie_host_init() function, call it from altera_pcie_probe(), >> > and do the link retrain there? Then you wouldn't need to worry about >> > whether this is a Root Port or an Endpoint, plus it would make the >> > altera driver structure more like the other drivers. >> > >> > You would call altera_pcie_host_init() before pci_scan_root_bus(), so >> > you wouldn't have a pci_dev yet, so you wouldn't be able to use >> > pcie_capability_set_word() to set the PCI_EXP_LNKCTL_RL bit. But I >> > assume there's some device-dependent way to access it using >> > cra_writel()? >> We can't use cra_write() to set PCI_EXP_LNKCTL_RL bit. > > Why not? I don't mean it has to be cra_write(), but isn't there some > way you can write that bit before we scan the root bus? It doesn't > make sense that we have to scan the bus before we can train the link. > > We want to be able to tell the PCI core "all the device-specific root > complex initialization has been done, here are the config accessors > you need, please scan for devices." I want to keep device-specific > things like this quirk directly in the driver and out of the > enumeration process. We don't have internal register bit to trigger link retrain, but need to set PCI_EXP_LNKCTL_RL bit in Link Control register of PCIe Capabilities Structure. So, this requires the altera_pcie_cfg_read() and altera_pcie_cfg_write(). I can restructure the altera_pcie_cfg_read() and altera_pcie_cfg_write() and have new _altera_pcie_cfg_read() and _altera_pcie_cfg_write() that avoid the dependency of struct pci_bus. By doing this, we can retrain the link before pci_scan_root_bus and remove _FIXUP() Will send new v3 patch, please take a look. > >> We can use >> pci_bus_find_capability() and pci_bus_read_config_word() with struct >> pci_bus instead. >> But this only can be called after pci_scan_root_bus(). > >> Found >> iproc_pcie_check_link() have similar implementation. > > You're right, and I don't like iproc_pcie_check_link() either, for the > same reasons. > > The iproc_pcie_check_link() is a little better because it's called > before enumeration: > > pci_create_root_bus() > iproc_pcie_check_link() > pci_scan_child_bus() > > But it would be a lot better if iproc_pcie_check_link() were done > first, before pci_create_root_bus(). Then it would be more like the > structure of other drivers, and we could use pci_scan_root_bus() > instead. > > Comments, iproc folks? > > Bjorn > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [IA64] MCA: Use kmalloc_array() in init_record_index_pools()
From: Markus Elfring Date: Thu, 25 Aug 2016 07:37:46 +0200 * A multiplication for the size determination of a memory allocation indicated that an array data structure should be processed. Thus reuse the corresponding function "kmalloc_array". This issue was detected by using the Coccinelle software. * Replace the specification of a data structure by a pointer dereference to make the corresponding size determination a bit safer according to the Linux coding style convention. Signed-off-by: Markus Elfring --- arch/ia64/kernel/mca_drv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/ia64/kernel/mca_drv.c b/arch/ia64/kernel/mca_drv.c index 94f8bf7..e4ce128 100644 --- a/arch/ia64/kernel/mca_drv.c +++ b/arch/ia64/kernel/mca_drv.c @@ -349,9 +349,9 @@ init_record_index_pools(void) /* - 3 - */ slidx_pool.max_idx = (rec_max_size/sect_min_size) * 2 + 1; - slidx_pool.buffer = - kmalloc(slidx_pool.max_idx * sizeof(slidx_list_t), GFP_KERNEL); - + slidx_pool.buffer = kmalloc_array(slidx_pool.max_idx, + sizeof(*slidx_pool.buffer), + GFP_KERNEL); return slidx_pool.buffer ? 0 : -ENOMEM; } -- 2.9.3
Re: [patch 1/2] i2c: add master driver for mellanox systems
Hi Vadim,
[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.8-rc3 next-20160824]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for
convenience) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/vadimp-mellanox-com/i2c-add-master-driver-for-mellanox-systems/20160824-200057
base: https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
i2c/for-next
config: x86_64-randconfig-s1-08242121 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_lpc_write_buf':
>> drivers/i2c/busses/i2c-mlxcpld.c:148: error: implicit declaration of
>> function 'outl'
>> drivers/i2c/busses/i2c-mlxcpld.c:153: error: implicit declaration of
>> function 'outb'
drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_lpc_read_buf':
>> drivers/i2c/busses/i2c-mlxcpld.c:163: error: implicit declaration of
>> function 'inl'
>> drivers/i2c/busses/i2c-mlxcpld.c:168: error: implicit declaration of
>> function 'inb'
drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_read_comm':
>> drivers/i2c/busses/i2c-mlxcpld.c:181: error: implicit declaration of
>> function 'inw'
drivers/i2c/busses/i2c-mlxcpld.c: In function 'mlxcpld_i2c_write_comm':
>> drivers/i2c/busses/i2c-mlxcpld.c:206: error: implicit declaration of
>> function 'outw'
vim +/outl +148 drivers/i2c/busses/i2c-mlxcpld.c
142 {
143 int i, nbyte, ndword;
144
145 nbyte = len % 4;
146 ndword = len / 4;
147 for (i = 0; i < ndword; i++)
> 148 outl(*((u32 *)data + i), addr + i * 4);
149 ndword *= 4;
150 addr += ndword;
151 data += ndword;
152 for (i = 0; i < nbyte; i++)
> 153 outb(*(data + i), addr + i);
154 }
155
156 static void mlxcpld_i2c_lpc_read_buf(u8 *data, u8 len, u32 addr)
157 {
158 int i, nbyte, ndword;
159
160 nbyte = len % 4;
161 ndword = len / 4;
162 for (i = 0; i < ndword; i++)
> 163 *((u32 *)data + i) = inl(addr + i * 4);
164 ndword *= 4;
165 addr += ndword;
166 data += ndword;
167 for (i = 0; i < nbyte; i++)
> 168 *(data + i) = inb(addr + i);
169 }
170
171 static void mlxcpld_i2c_read_comm(struct mlxcpld_i2c_priv *priv, u8
offs,
172u8 *data, u8 datalen)
173 {
174 u32 addr = priv->base_addr + offs;
175
176 switch (datalen) {
177 case 1:
178 *(data) = inb(addr);
179 break;
180 case 2:
> 181 *((u16 *)data) = inw(addr);
182 break;
183 case 3:
184 *((u16 *)data) = inw(addr);
185 *(data + 2) = inb(addr + 2);
186 break;
187 case 4:
188 *((u32 *)data) = inl(addr);
189 break;
190 default:
191 mlxcpld_i2c_lpc_read_buf(data, datalen, addr);
192 break;
193 }
194 }
195
196 static void mlxcpld_i2c_write_comm(struct mlxcpld_i2c_priv *priv, u8
offs,
197 u8 *data, u8 datalen)
198 {
199 u32 addr = priv->base_addr + offs;
200
201 switch (datalen) {
202 case 1:
203 outb(*(data), addr);
204 break;
205 case 2:
> 206 outw(*((u16 *)data), addr);
207 break;
208 case 3:
209 outw(*((u16 *)data), addr);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [RFC PATCH v2 02/20] x86: Set the write-protect cache mode for full PAT support
On Mon, Aug 22, 2016 at 05:35:50PM -0500, Tom Lendacky wrote: > For processors that support PAT, set the write-protect cache mode > (_PAGE_CACHE_MODE_WP) entry to the actual write-protect value (x05). > > Signed-off-by: Tom Lendacky > --- > arch/x86/mm/pat.c |4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Borislav Petkov -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --
[PATCH v2] iio: adc: ltc2485: add support for Linear Technology LTC2485 ADC
Adds basic support for the LTC2485 ADC - a delta-sigma analog-to-digital
converter with an I2C interface that operates in single shot conversion
mode.
The driver supports an on board 5V reference and the power-on default
configuration which rejects both 50hz & 60hz line frequencies and
operates in 1x speed mode.
Signed-off-by: Alison Schofield
Cc: Daniel Baluta
---
Changes in v2:
- changed the wait conversion time function to use monotonic rather than
real time and to use milliseconds rather than nanoseconds.
- made conv time a constant int.
Same notes as in v1:
Reviewers: In addition to commenting on what is present, please comment
on what is absent and the priority in which you would like to see
additional features added to this driver, or needed in this first submittal.
Not supported:
1. External Vref
2. Additional Configuration Modes
Temperature Sensor Mode: report temp data (not voltage).
Line Frequency Rejection Mode: select to reject 50Hz or 60Hz
or both. (both is default)
Speed Mode: Default speed mode (1x) performs two conversions each
cycle and combines the results. 2x speed mode only does one
conversion each cycle.
3. Power management
4. DT Bindings
5. Triggered buffers
6. What else?
drivers/iio/adc/Kconfig | 9 +++
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/ltc2485.c | 146 ++
3 files changed, 156 insertions(+)
create mode 100644 drivers/iio/adc/ltc2485.c
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 1de31bd..a042611 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -264,6 +264,15 @@ config LPC18XX_ADC
To compile this driver as a module, choose M here: the module will be
called lpc18xx_adc.
+config LTC2485
+ tristate "Linear Technology LTC2485 ADC driver"
+ depends on I2C
+ help
+ Say yes here to build support for Linear Technology LTC2485 ADC.
+
+ To compile this driver as a module, choose M here: the module will be
+ called ltc2485.
+
config MAX1027
tristate "Maxim max1027 ADC driver"
depends on SPI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 0ba0d50..1be5747 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_IMX7D_ADC) += imx7d_adc.o
obj-$(CONFIG_INA2XX_ADC) += ina2xx-adc.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_LPC18XX_ADC) += lpc18xx_adc.o
+obj-$(CONFIG_LTC2485) += ltc2485.o
obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MAX1363) += max1363.o
obj-$(CONFIG_MCP320X) += mcp320x.o
diff --git a/drivers/iio/adc/ltc2485.c b/drivers/iio/adc/ltc2485.c
new file mode 100644
index 000..d8f9dac
--- /dev/null
+++ b/drivers/iio/adc/ltc2485.c
@@ -0,0 +1,146 @@
+/*
+ * ltc2485.c - Driver for Linear Technology LTC2485 ADC
+ *
+ * Copyright (C) 2016 Alison Schofield
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Datasheet: http://cds.linear.com/docs/en/datasheet/2485fd.pdf
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+/* Power-on configuration: rejects both 50/60Hz, operates at 1x speed */
+#define LTC2485_CONFIG_DEFAULT 0
+
+struct ltc2485_data {
+ struct i2c_client *client;
+ ktime_t time_prev; /* last conversion */
+};
+
+static void ltc2485_wait_conv(struct ltc2485_data *data)
+{
+ const unsigned int conv_time = 147; /* conversion time ms */
+ unsigned int time_elapsed;
+
+ /* delay if conversion time not passed since last read or write */
+ time_elapsed = ktime_ms_delta(ktime_get(), data->time_prev);
+
+ if (time_elapsed < conv_time)
+ msleep(conv_time - time_elapsed);
+}
+
+static int ltc2485_read(struct ltc2485_data *data, int *val)
+{
+ struct i2c_client *client = data->client;
+ __be32 buf = 0;
+ int ret;
+
+ ltc2485_wait_conv(data);
+
+ ret = i2c_master_recv(client, (char *)&buf, 4);
+ if (ret < 0) {
+ dev_err(&client->dev, "i2c_master_recv failed\n");
+ return ret;
+ }
+ data->time_prev = ktime_get();
+ *val = sign_extend32(be32_to_cpu(buf) >> 6, 24);
+ return ret;
+}
+
+static int ltc2485_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct ltc2485_data *data = iio_priv(indio_dev);
+ int ret;
+
+ if (mask == IIO_CHAN_INFO_RAW) {
+ ret = ltc2485_read(data, val);
+ if (ret < 0)
+ return ret;
+
+ return IIO_VAL_INT;
+
+ } else if (mask == IIO_CHAN_INFO_SCALE) {
+ *val = 5000;
[PATCH] softirq: fix tasklet_kill() and its users
Semantically the expectation from the tasklet init/kill API
should be as below.
tasklet_init() == Init and Enable scheduling
tasklet_kill() == Disable scheduling and Destroy
tasklet_init() API exibit above behavior but not the
tasklet_kill(). The tasklet handler can still get scheduled
and run even after the tasklet_kill().
There are 2, 3 places where drivers are working around
this issue by calling tasklet_disable() which will add an
usecount and there by avoiding the handlers being called.
tasklet_enable/tasklet_disable is a pair API and expected
to be used together. Usage of tasklet_disable() *just* to
workround tasklet scheduling after kill is probably not the
correct and inteded use of the API as done the API.
We also happen to see similar issue where in shutdown path
the tasklet_handler was getting called even after the
tasklet_kill().
We fix this be making sure tasklet_kill() does right
thing and there by ensuring tasklet handler won't run after
tasklet_kil() with very simple change. Patch fixes the tasklet
code and also few drivers workarounds.
Cc: Greg Kroah-Hartman
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Tadeusz Struk
Cc: Herbert Xu
Cc: "David S. Miller"
Cc: Paul Bolle
Cc: Giovanni Cabiddu
Cc: Salvatore Benedetto
Cc: Karsten Keil
Cc: "Peter Zijlstra (Intel)"
Signed-off-by: Santosh Shilimkar
---
Removed RFC tag from last post and dropped atmel serial
driver which seems to have been fixed in 4.8
https://lkml.org/lkml/2016/8/7/7
drivers/crypto/qat/qat_common/adf_isr.c| 1 -
drivers/crypto/qat/qat_common/adf_sriov.c | 1 -
drivers/crypto/qat/qat_common/adf_vf_isr.c | 2 --
drivers/isdn/gigaset/interface.c | 1 -
kernel/softirq.c | 7 ---
5 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/adf_isr.c
b/drivers/crypto/qat/qat_common/adf_isr.c
index 06d4901..fd5e900 100644
--- a/drivers/crypto/qat/qat_common/adf_isr.c
+++ b/drivers/crypto/qat/qat_common/adf_isr.c
@@ -296,7 +296,6 @@ static void adf_cleanup_bh(struct adf_accel_dev *accel_dev)
int i;
for (i = 0; i < hw_data->num_banks; i++) {
- tasklet_disable(&priv_data->banks[i].resp_handler);
tasklet_kill(&priv_data->banks[i].resp_handler);
}
}
diff --git a/drivers/crypto/qat/qat_common/adf_sriov.c
b/drivers/crypto/qat/qat_common/adf_sriov.c
index 9320ae1..bc7c2fa 100644
--- a/drivers/crypto/qat/qat_common/adf_sriov.c
+++ b/drivers/crypto/qat/qat_common/adf_sriov.c
@@ -204,7 +204,6 @@ void adf_disable_sriov(struct adf_accel_dev *accel_dev)
}
for (i = 0, vf = accel_dev->pf.vf_info; i < totalvfs; i++, vf++) {
- tasklet_disable(&vf->vf2pf_bh_tasklet);
tasklet_kill(&vf->vf2pf_bh_tasklet);
mutex_destroy(&vf->pf2vf_lock);
}
diff --git a/drivers/crypto/qat/qat_common/adf_vf_isr.c
b/drivers/crypto/qat/qat_common/adf_vf_isr.c
index bf99e11..6e38bff 100644
--- a/drivers/crypto/qat/qat_common/adf_vf_isr.c
+++ b/drivers/crypto/qat/qat_common/adf_vf_isr.c
@@ -191,7 +191,6 @@ static int adf_setup_pf2vf_bh(struct adf_accel_dev
*accel_dev)
static void adf_cleanup_pf2vf_bh(struct adf_accel_dev *accel_dev)
{
- tasklet_disable(&accel_dev->vf.pf2vf_bh_tasklet);
tasklet_kill(&accel_dev->vf.pf2vf_bh_tasklet);
mutex_destroy(&accel_dev->vf.vf2pf_lock);
}
@@ -268,7 +267,6 @@ static void adf_cleanup_bh(struct adf_accel_dev *accel_dev)
{
struct adf_etr_data *priv_data = accel_dev->transport;
- tasklet_disable(&priv_data->banks[0].resp_handler);
tasklet_kill(&priv_data->banks[0].resp_handler);
}
diff --git a/drivers/isdn/gigaset/interface.c b/drivers/isdn/gigaset/interface.c
index 600c79b..2ce63b6 100644
--- a/drivers/isdn/gigaset/interface.c
+++ b/drivers/isdn/gigaset/interface.c
@@ -524,7 +524,6 @@ void gigaset_if_free(struct cardstate *cs)
if (!drv->have_tty)
return;
- tasklet_disable(&cs->if_wake_tasklet);
tasklet_kill(&cs->if_wake_tasklet);
cs->tty_dev = NULL;
tty_unregister_device(drv->tty, cs->minor_index);
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 17caf4b..21397eb 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -498,7 +498,7 @@ static void tasklet_action(struct softirq_action *a)
list = list->next;
if (tasklet_trylock(t)) {
- if (!atomic_read(&t->count)) {
+ if (atomic_read(&t->count) == 1) {
if (!test_and_clear_bit(TASKLET_STATE_SCHED,
&t->state))
BUG();
@@ -534,7 +534,7 @@ static void tasklet_hi_action(struct softirq_action *a)
list = list->next;
if (tasklet_trylock(t)) {
- if (!atomic_read(&t->count)) {
+ if (atomic_read(&t
Partnership Cooperation
Dear Friend, Your contact details came to me by recommendation, I am interested in investing in your country and I believe you have the capabilities of providing the needed assistance, solutions and advise in actualizing this, Let me know if you are willing to understake this task for me so we can discuss more. I hope to hear from you soon. Regards, Sheikh Maktoum Hasher Al Maktoum Chairman/Chief Executive Officer Dubai International Holding Company. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
[PATCH] f2fs: invalidate inode and data pages if inode is no longer used
When a file is closed, let's deactivate inode page to mitigate further memory pressure. We can do data pages as well in the corner case of f2fs_drop_inode. Signed-off-by: Jaegeuk Kim --- fs/f2fs/file.c | 4 fs/f2fs/super.c | 1 + 2 files changed, 5 insertions(+) diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c index e460211..5f9a6dc 100644 --- a/fs/f2fs/file.c +++ b/fs/f2fs/file.c @@ -1465,6 +1465,10 @@ static int f2fs_release_file(struct inode *inode, struct file *filp) filemap_fdatawrite(inode->i_mapping); clear_inode_flag(inode, FI_DROP_CACHE); } + + /* deactivate written inode page */ + invalidate_mapping_pages(NODE_MAPPING(F2FS_I_SB(inode)), + inode->i_ino, inode->i_ino); return 0; } diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index 7f863a6..f84696d 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -618,6 +618,7 @@ static int f2fs_drop_inode(struct inode *inode) sb_end_intwrite(inode->i_sb); fscrypt_put_encryption_info(inode, NULL); + invalidate_mapping_pages(inode->i_mapping, 0, -1); spin_lock(&inode->i_lock); atomic_dec(&inode->i_count); } -- 2.8.3
Re: [RFC 0/4] ZRAM: make it just store the high compression rate page
Hello, On (08/22/16 16:25), Hui Zhu wrote: > > Current ZRAM just can store all pages even if the compression rate > of a page is really low. So the compression rate of ZRAM is out of > control when it is running. > In my part, I did some test and record with ZRAM. The compression rate > is about 40%. > > This series of patches make ZRAM can just store the page that the > compressed size is smaller than a value. > With these patches, I set the value to 2048 and did the same test with > before. The compression rate is about 20%. The times of lowmemorykiller > also decreased. I haven't looked at the patches in details yet. can you educate me a bit? is your test stable? why the number of lowmemorykill-s has decreased? ... or am reading "The times of lowmemorykiller also decreased" wrong? suppose you have X pages that result in bad compression size (from zram point of view). zram stores such pages uncompressed, IOW we have no memory savings - swapped out page lands in zsmalloc PAGE_SIZE class. now you don't try to store those pages in zsmalloc, but keep them as unevictable. so the page still occupies PAGE_SIZE; no memory saving again. why did it improve LMK? -ss
Re: Memory (skb) leak in kernel 4.8-rc2
Hi Larry, On 24/08/2016 22:02, Larry Finger wrote: On 08/21/2016 07:09 AM, Frederic Dalleau wrote: I am unable to unload module bluetooth to verify that the second leak is not a false positive; however, the one in btusb is a real memory leak. I have a patch on the grill. Any progress on this patch? Yes, it is in bluetooth-stable. http://marc.info/?l=linux-bluetooth&m=147205068529234&w=2 Regards Fred
[PATCH] powerpc: Remove suspect CONFIG_PPC_BOOK3E #ifdefs in nohash/64/pgtable.h
There are three #ifdef CONFIG_PPC_BOOK3E sections in nohash/64/pgtable.h. And there should be no configurations possible which use nohash/64/pgtable.h but don't also enable CONFIG_PPC_BOOK3E. Suggested-by: Michael Ellerman Signed-off-by: Rui Teng --- arch/powerpc/include/asm/nohash/64/pgtable.h | 14 +- 1 file changed, 1 insertion(+), 13 deletions(-) diff --git a/arch/powerpc/include/asm/nohash/64/pgtable.h b/arch/powerpc/include/asm/nohash/64/pgtable.h index d4d808c..6213fc1 100644 --- a/arch/powerpc/include/asm/nohash/64/pgtable.h +++ b/arch/powerpc/include/asm/nohash/64/pgtable.h @@ -26,15 +26,11 @@ #else #define PMD_CACHE_INDEXPMD_INDEX_SIZE #endif + /* * Define the address range of the kernel non-linear virtual area */ - -#ifdef CONFIG_PPC_BOOK3E #define KERN_VIRT_START ASM_CONST(0x8000) -#else -#define KERN_VIRT_START ASM_CONST(0xD000) -#endif #define KERN_VIRT_SIZE ASM_CONST(0x1000) /* @@ -43,11 +39,7 @@ * (we keep a quarter for the virtual memmap) */ #define VMALLOC_START KERN_VIRT_START -#ifdef CONFIG_PPC_BOOK3E #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 2) -#else -#define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1) -#endif #define VMALLOC_END(VMALLOC_START + VMALLOC_SIZE) /* @@ -85,12 +77,8 @@ * Defines the address of the vmemap area, in its own region on * hash table CPUs and after the vmalloc space on Book3E */ -#ifdef CONFIG_PPC_BOOK3E #define VMEMMAP_BASE VMALLOC_END #define VMEMMAP_ENDKERN_IO_START -#else -#define VMEMMAP_BASE (VMEMMAP_REGION_ID << REGION_SHIFT) -#endif #define vmemmap((struct page *)VMEMMAP_BASE) -- 2.7.4
Re: [PATCH v6 1/4] libata: Safely overwrite attached page in WRITE SAME xlat
On 25 August 2016 at 05:28, Shaun Tancheff wrote: > On Wed, Aug 24, 2016 at 12:31 AM, Tom Yan wrote: >> On 24 August 2016 at 11:33, Martin K. Petersen >> wrote: "Tom" == Tom Yan writes: >>> >>> Tom> Nope, SCSI Write Same commands does not have payload (or in SCSI >>> Tom> terms, parameter list / data-out buffer). >>> >>> WRITE SAME has a a payload of 1 logical block (unless NDOB is set but we >>> have had no good reason to support that yet). >> >> Interesting, I wasn't aware of the bit. I just didn't see any >> parameter list defined for any of the Write Same commands. Ah wait, it >> carries the pattern (the "same") and so. >> >> Hmm, it doesn't seem like the translation implemented in this patch >> series cares about the payload though? > > As repeated here and elsewhere the payload is: > scsi_sglist(cmd) > and it was put there by scsi_init_io() when it called scsi_init_sgtable() What I mean is: put_unaligned_le32(0u, &sctpg[10]); So even if the payload of the SCSI Write Same commands instruct a non-zero pattern writing, SCT Write Same will conveniently ignore that do zero-filling anyway. That's what I mean by "doesn't care about the payload". Though that would only be case with SG_IO though. SCSI Write Same issued from block layer (BLKZEROOUT) will be instructing zero-filling anyway. > >>> UNMAP has a payload that varies based on the number of range >>> descriptors. The SCSI disk driver only ever issues a single descriptor >>> but since libata doesn't support UNMAP this doesn't really come into >>> play. >>> >>> Ideally there would be a way to distinguish between device limits for >>> WRITE SAME with the UNMAP bit and for "regular" WRITE SAME. One way to >>> do that would be to transition the libata discard implementation over to >>> single-range UNMAP, fill out the relevant VPD page B0 fields and leave >>> the WRITE SAME bits for writing zeroes. >>> >>> One reason that has not been particularly compelling is that the WRITE >>> SAME payload buffer does double duty to hold the ATA DSM TRIM range >> >> Huh? Why would the SATL care about its payload buffer for TRIM (i.e. >> when the UNMAP bit is set)? Doesn't it just read the LBA and NUMBER OF >> BLOCKS field and pack TRIM ranges/payload according to that? >> >>> descriptors and matches the required ATA payload size. Whereas the UNMAP >> >> Why would it need to "matches the required ATA payload size"? >> >>> command would only provide 24 bytes of TRIM range space. >> >> I don't really follow. The UNMAP descriptor has LBA (8 bytes / 64-bit) >> and NUMBER OF BLOCKS (4 bytes / 32-bit) field of the same length as >> Write Same (16). Even if the SCSI disk driver will only send one >> descriptor, it should work as good as Write Same (16). > > The "payload" is the data block transferred with the command. > The "descriptor" is, in this context, the contents of the payload as > it "describes" what the action the command is supposed to perform. > I know right. > The "payload" contains the "descriptor" that "describes" how > DSM TRIM should determine which logical blocks it should UNMAP. This should only be the case of UNMAP command, but not SCSI Write Same with UNMAP bit set. And either way it should not affect how large the ATA TRIM payload can be. > >>> Also, please be careful with transfer lengths, __data_len, etc. As >>> mentioned, the transfer length WRITE SAME is typically 512 bytes and >>> that's the number of bytes that need to be DMA'ed and transferred over >>> the wire by the controller. But from a command completion perspective we >>> need to complete however many bytes the command acted upon. Unlike reads >>> and writes there is not a 1:1 mapping between the transfer length and >>> the affected area. So we do a bit of magic after the buffer has been >>> mapped to ensure that the completion byte count matches the number of >>> blocks that were affected by the command rather than the size of the >>> data buffer in bytes. >>> >>> -- >>> Martin K. Petersen Oracle Linux Engineering > -- > Shaun Tancheff
Re: [PATCH v2 0/3] *** Latency histograms - IRQSOFF,PREEMPTOFF ***
On 25 August 2016 at 10:56, Daniel Wagner wrote: > Hi Binoy, > > On 08/24/2016 01:17 PM, Binoy Jayan wrote: >> >> Histogram output: >> cat /sys/kernel/debug/tracing/events/latency/latency_irqs/hist >> cat /sys/kernel/debug/tracing/events/latency/latency_preempt/hist >> cat /sys/kernel/debug/tracing/events/latency/latency_critical_timings/hist >> cat >> /sys/kernel/debug/tracing/events/latency/latency_hrtimer_interrupt/hist > > > [...] > >> Changes from v1 as per comments from Steven/Daniel >> - Use single tracepoint for irq/preempt/critical timings by introducing >> a trace type field to differentiate trace type in the same tracepoint. > > > Did you send out the right patches? This version still looks like the > previous one in this regard. And wouldn't be the 'Histogram output' have > only one file? Maybe I just understood something wrong here. > > cheers, > daniel Hi Daniel, This patch is after incorporating changes w.r.t. comments by steven. And regarding using one tracepoint, I have mentioned the same in the cover letter. I have sent you (only) another patch with that change. When I do it like that I get an RCU error, the first time the "type" key is used. It is weird that it happens only for the first time something is echo-ed to the trigger file. I haven't been able to figure out why yet. Binoy
