[char-misc-next 2/6] mei: get rid of most of the pci dependencies in mei
For purpose of adding testing HW we would like
to get rid of pci dependency in generic mei code
This patch provides only straight forward changes
FW status and prob quirks need to be handled separately
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/amthif.c| 68 ++--
drivers/misc/mei/bus.c | 10 +++
drivers/misc/mei/client.c| 46 +++---
drivers/misc/mei/client.h| 4 +--
drivers/misc/mei/debugfs.c | 6 ++--
drivers/misc/mei/hbm.c | 66 +-
drivers/misc/mei/hw-me.c | 30 +--
drivers/misc/mei/hw-txe.c| 53 --
drivers/misc/mei/init.c | 42 +--
drivers/misc/mei/interrupt.c | 44 ++--
drivers/misc/mei/main.c | 40 +-
drivers/misc/mei/nfc.c | 43 +---
drivers/misc/mei/pci-me.c| 2 +-
drivers/misc/mei/pci-txe.c | 2 +-
drivers/misc/mei/wd.c| 34 ++
15 files changed, 239 insertions(+), 251 deletions(-)
diff --git a/drivers/misc/mei/amthif.c b/drivers/misc/mei/amthif.c
index 1f80873..5d47d1b 100644
--- a/drivers/misc/mei/amthif.c
+++ b/drivers/misc/mei/amthif.c
@@ -78,7 +78,7 @@ int mei_amthif_host_init(struct mei_device *dev)
me_cl = mei_me_cl_by_uuid(dev, _amthif_guid);
if (!me_cl) {
- dev_info(>pdev->dev, "amthif: failed to find the client");
+ dev_info(dev->dev, "amthif: failed to find the client");
return -ENOTTY;
}
@@ -88,7 +88,7 @@ int mei_amthif_host_init(struct mei_device *dev)
/* Assign iamthif_mtu to the value received from ME */
dev->iamthif_mtu = me_cl->props.max_msg_length;
- dev_dbg(>pdev->dev, "IAMTHIF_MTU = %d\n", dev->iamthif_mtu);
+ dev_dbg(dev->dev, "IAMTHIF_MTU = %d\n", dev->iamthif_mtu);
kfree(dev->iamthif_msg_buf);
dev->iamthif_msg_buf = NULL;
@@ -104,7 +104,7 @@ int mei_amthif_host_init(struct mei_device *dev)
ret = mei_cl_link(cl, MEI_IAMTHIF_HOST_CLIENT_ID);
if (ret < 0) {
- dev_err(>pdev->dev,
+ dev_err(dev->dev,
"amthif: failed link client %d\n", ret);
return ret;
}
@@ -164,11 +164,11 @@ int mei_amthif_read(struct mei_device *dev, struct file
*file,
/* Only possible if we are in timeout */
if (!cl) {
- dev_err(>pdev->dev, "bad file ext.\n");
+ dev_err(dev->dev, "bad file ext.\n");
return -ETIME;
}
- dev_dbg(>pdev->dev, "checking amthif data\n");
+ dev_dbg(dev->dev, "checking amthif data\n");
cb = mei_amthif_find_read_list_entry(dev, file);
/* Check for if we can block or not*/
@@ -176,7 +176,7 @@ int mei_amthif_read(struct mei_device *dev, struct file
*file,
return -EAGAIN;
- dev_dbg(>pdev->dev, "waiting for amthif data\n");
+ dev_dbg(dev->dev, "waiting for amthif data\n");
while (cb == NULL) {
/* unlock the Mutex */
mutex_unlock(>device_lock);
@@ -190,21 +190,21 @@ int mei_amthif_read(struct mei_device *dev, struct file
*file,
if (wait_ret)
return -ERESTARTSYS;
- dev_dbg(>pdev->dev, "woke up from sleep\n");
+ dev_dbg(dev->dev, "woke up from sleep\n");
}
- dev_dbg(>pdev->dev, "Got amthif data\n");
+ dev_dbg(dev->dev, "Got amthif data\n");
dev->iamthif_timer = 0;
if (cb) {
timeout = cb->read_time +
mei_secs_to_jiffies(MEI_IAMTHIF_READ_TIMER);
- dev_dbg(>pdev->dev, "amthif timeout = %lud\n",
+ dev_dbg(dev->dev, "amthif timeout = %lud\n",
timeout);
if (time_after(jiffies, timeout)) {
- dev_dbg(>pdev->dev, "amthif Time out\n");
+ dev_dbg(dev->dev, "amthif Time out\n");
/* 15 sec for the message has expired */
list_del(>list);
rets = -ETIME;
@@ -224,16 +224,16 @@ int mei_amthif_read(struct mei_device *dev, struct file
*file,
* remove message from deletion list
*/
- dev_dbg(>pdev->dev, "amthif cb->response_buffer size - %d\n",
+ dev_dbg(dev->dev, "amthif cb->response_buffer size - %d\n",
cb->response_buffer.size);
- dev_dbg(>pdev->dev, "amthif cb->buf_idx - %lu\n", cb->buf_idx);
+ dev_dbg(dev->dev, "amthif cb->buf_idx - %lu\n", cb->buf_idx);
/* length is being truncated to PAGE_SIZE, however,
* the buf_idx may point beyond */
length = min_t(size_t, length, (cb->buf_idx - *offset));
if (copy_to_user(ubuf,
[PATCH] staging: et131x: et131x.c: sparse warning of incompatible types
fixed sparse warning: incompatible types in comparison expression
(different address spaces)
wolw and reg both are being used only for the initialization of
the __iomem area.
Signed-off-by: Sudip Mukherjee
---
drivers/staging/et131x/et131x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 52abe33..1037d93 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -1135,7 +1135,7 @@ static void et1310_config_rxmac_regs(struct
et131x_adapter *adapter)
u32 sa_lo;
u32 sa_hi = 0;
u32 pf_ctrl = 0;
- u32 *wolw;
+ u32 __iomem *wolw;
/* Disable the MAC while it is being configured (also disable WOL) */
writel(0x8, >ctrl);
@@ -1255,7 +1255,7 @@ static void et1310_config_txmac_regs(struct
et131x_adapter *adapter)
static void et1310_config_macstat_regs(struct et131x_adapter *adapter)
{
struct macstat_regs __iomem *macstat = >regs->macstat;
- u32 *reg;
+ u32 __iomem *reg;
/* initialize all the macstat registers to zero on the device */
for (reg = >txrx_0_64_byte_frames;
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[char-misc-next 1/6] mei: push all standard settings into mei_device_init
Setting of hw_ops and device has should be in
mei_device_init.
We add reference to the parent device and remove
pci dependent cfg
Signed-off-by: Tomas Winkler
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/hw-me.c | 6 ++
drivers/misc/mei/hw-txe.c | 5 ++---
drivers/misc/mei/init.c| 14 --
drivers/misc/mei/mei_dev.h | 6 +-
4 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 56a9caa..df42b6f 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -824,10 +824,8 @@ struct mei_device *mei_me_dev_init(struct pci_dev *pdev,
if (!dev)
return NULL;
- mei_device_init(dev, cfg);
-
- dev->ops = _me_hw_ops;
-
+ mei_device_init(dev, >dev, _me_hw_ops);
+ dev->cfg = cfg;
dev->pdev = pdev;
return dev;
}
diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c
index 1855b3b..fc1a51f 100644
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -1123,14 +1123,13 @@ struct mei_device *mei_txe_dev_init(struct pci_dev
*pdev,
if (!dev)
return NULL;
- mei_device_init(dev, cfg);
+ mei_device_init(dev, >dev, _txe_hw_ops);
hw = to_txe_hw(dev);
init_waitqueue_head(>wait_aliveness_resp);
- dev->ops = _txe_hw_ops;
-
+ dev->cfg = cfg;
dev->pdev = pdev;
return dev;
}
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 5c41f58..ac65976 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -365,7 +365,16 @@ int mei_fw_status(struct mei_device *dev, struct
mei_fw_status *fw_status)
}
EXPORT_SYMBOL_GPL(mei_fw_status);
-void mei_device_init(struct mei_device *dev, const struct mei_cfg *cfg)
+/**
+ * mei_device_init -- initialize mei_device structure
+ *
+ * @dev: the mei device
+ * @device: the device structure
+ * @hw_ops: hw operations
+ */
+void mei_device_init(struct mei_device *dev,
+struct device *device,
+const struct mei_hw_ops *hw_ops)
{
/* setup our list array */
INIT_LIST_HEAD(>file_list);
@@ -404,7 +413,8 @@ void mei_device_init(struct mei_device *dev, const struct
mei_cfg *cfg)
bitmap_set(dev->host_clients_map, 0, 1);
dev->pg_event = MEI_PG_EVENT_IDLE;
- dev->cfg = cfg;
+ dev->ops = hw_ops;
+ dev->dev = device;
}
EXPORT_SYMBOL_GPL(mei_device_init);
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index be7b147..7051430 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -399,6 +399,7 @@ struct mei_cfg {
* struct mei_device - MEI private device struct
* @pdev - pointer to pci device struct
+ * @dev - device on a bus
* @cdev - character device
* @minor - minor number allocated for device
*
@@ -417,6 +418,7 @@ struct mei_cfg {
*/
struct mei_device {
struct pci_dev *pdev; /* pointer to pci device struct */
+ struct device *dev;
struct cdev cdev;
int minor;
@@ -560,7 +562,9 @@ static inline u32 mei_slots2data(int slots)
/*
* mei init function prototypes
*/
-void mei_device_init(struct mei_device *dev, const struct mei_cfg *cfg);
+void mei_device_init(struct mei_device *dev,
+struct device *device,
+const struct mei_hw_ops *hw_ops);
int mei_reset(struct mei_device *dev);
int mei_start(struct mei_device *dev);
int mei_restart(struct mei_device *dev);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[char-misc-next 6/6] mei: remove include to pci header from mei module files
Remove inclusion of linux/pci.h in mei layer however we need to include the headers that before got included implicitly from linux/pci.h. Signed-off-by: Tomas Winkler --- drivers/misc/mei/amthif.c| 2 +- drivers/misc/mei/bus.c | 1 - drivers/misc/mei/client.c| 2 +- drivers/misc/mei/debugfs.c | 1 - drivers/misc/mei/hbm.c | 5 +++-- drivers/misc/mei/init.c | 1 - drivers/misc/mei/interrupt.c | 2 +- drivers/misc/mei/main.c | 2 +- drivers/misc/mei/nfc.c | 3 ++- drivers/misc/mei/wd.c| 1 - include/linux/mei_cl_bus.h | 1 + 11 files changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/misc/mei/amthif.c b/drivers/misc/mei/amthif.c index 5d47d1b..d9b0e761f 100644 --- a/drivers/misc/mei/amthif.c +++ b/drivers/misc/mei/amthif.c @@ -20,7 +20,6 @@ #include #include #include -#include #include #include #include @@ -29,6 +28,7 @@ #include #include #include +#include #include diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c index 4cc1a66..4d20d60 100644 --- a/drivers/misc/mei/bus.c +++ b/drivers/misc/mei/bus.c @@ -22,7 +22,6 @@ #include #include #include -#include #include #include "mei_dev.h" diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c index 03c1e14..4b58fce 100644 --- a/drivers/misc/mei/client.c +++ b/drivers/misc/mei/client.c @@ -14,10 +14,10 @@ * */ -#include #include #include #include +#include #include #include diff --git a/drivers/misc/mei/debugfs.c b/drivers/misc/mei/debugfs.c index e14a7db..aca7847 100644 --- a/drivers/misc/mei/debugfs.c +++ b/drivers/misc/mei/debugfs.c @@ -17,7 +17,6 @@ #include #include #include -#include #include diff --git a/drivers/misc/mei/hbm.c b/drivers/misc/mei/hbm.c index 209650b..c874fdd 100644 --- a/drivers/misc/mei/hbm.c +++ b/drivers/misc/mei/hbm.c @@ -15,11 +15,12 @@ */ #include -#include #include #include -#include #include +#include + +#include #include "mei_dev.h" #include "hbm.h" diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c index dd233fd..76ef8ff 100644 --- a/drivers/misc/mei/init.c +++ b/drivers/misc/mei/init.c @@ -15,7 +15,6 @@ */ #include -#include #include #include #include diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c index 8dac769..8844e17 100644 --- a/drivers/misc/mei/interrupt.c +++ b/drivers/misc/mei/interrupt.c @@ -16,11 +16,11 @@ #include -#include #include #include #include #include +#include #include diff --git a/drivers/misc/mei/main.c b/drivers/misc/mei/main.c index 4d738c8..d31f271 100644 --- a/drivers/misc/mei/main.c +++ b/drivers/misc/mei/main.c @@ -17,12 +17,12 @@ #include #include #include +#include #include #include #include #include #include -#include #include #include #include diff --git a/drivers/misc/mei/nfc.c b/drivers/misc/mei/nfc.c index 9f32fd6..5b369f4 100644 --- a/drivers/misc/mei/nfc.c +++ b/drivers/misc/mei/nfc.c @@ -19,7 +19,8 @@ #include #include #include -#include +#include + #include #include "mei_dev.h" diff --git a/drivers/misc/mei/wd.c b/drivers/misc/mei/wd.c index d28511b..626b4c1 100644 --- a/drivers/misc/mei/wd.c +++ b/drivers/misc/mei/wd.c @@ -17,7 +17,6 @@ #include #include #include -#include #include #include diff --git a/include/linux/mei_cl_bus.h b/include/linux/mei_cl_bus.h index d14af7b..164aad1 100644 --- a/include/linux/mei_cl_bus.h +++ b/include/linux/mei_cl_bus.h @@ -3,6 +3,7 @@ #include #include +#include struct mei_cl_device; -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[char-misc-next 3/6] mei: move fw_status back to hw ops handlers
fw status retrieval has pci specific implementation
so we push it back to the hw layer
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw-me.c | 28
drivers/misc/mei/hw-txe.c | 30 ++
drivers/misc/mei/init.c| 21 -
drivers/misc/mei/mei_dev.h | 9 -
4 files changed, 66 insertions(+), 22 deletions(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 1247be7..678531c 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -101,6 +101,33 @@ static inline void mei_hcsr_set(struct mei_me_hw *hw, u32
hcsr)
mei_me_reg_write(hw, H_CSR, hcsr);
}
+/**
+ * mei_me_fw_status - read fw status register from pci config space
+ *
+ * @dev: mei device
+ * @fw_status: fw status register values
+ */
+static int mei_me_fw_status(struct mei_device *dev,
+ struct mei_fw_status *fw_status)
+{
+ const struct mei_fw_status *fw_src = >cfg->fw_status;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+ int ret;
+ int i;
+
+ if (!fw_status)
+ return -EINVAL;
+
+ fw_status->count = fw_src->count;
+ for (i = 0; i < fw_src->count && i < MEI_FW_STATUS_MAX; i++) {
+ ret = pci_read_config_dword(pdev,
+ fw_src->status[i], _status->status[i]);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
/**
* mei_me_hw_config - configure hw dependent settings
@@ -714,6 +741,7 @@ end:
static const struct mei_hw_ops mei_me_hw_ops = {
+ .fw_status = mei_me_fw_status,
.pg_state = mei_me_pg_state,
.host_is_ready = mei_me_host_is_ready,
diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c
index acc475e..e4cb9dc 100644
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -573,6 +573,35 @@ static int mei_txe_readiness_wait(struct mei_device *dev)
return 0;
}
+
+/**
+ * mei_txe_fw_status - read fw status register from pci config space
+ *
+ * @dev: mei device
+ * @fw_status: fw status register values
+ */
+static int mei_txe_fw_status(struct mei_device *dev,
+struct mei_fw_status *fw_status)
+{
+ const struct mei_fw_status *fw_src = >cfg->fw_status;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
+ int ret;
+ int i;
+
+ if (!fw_status)
+ return -EINVAL;
+
+ fw_status->count = fw_src->count;
+ for (i = 0; i < fw_src->count && i < MEI_FW_STATUS_MAX; i++) {
+ ret = pci_read_config_dword(pdev,
+ fw_src->status[i], _status->status[i]);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
/**
* mei_txe_hw_config - configure hardware at the start of the devices
*
@@ -1064,6 +1093,7 @@ static const struct mei_hw_ops mei_txe_hw_ops = {
.host_is_ready = mei_txe_host_is_ready,
+ .fw_status = mei_txe_fw_status,
.pg_state = mei_txe_pg_state,
.hw_is_ready = mei_txe_hw_is_ready,
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index 29aae7b..dd233fd 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -344,27 +344,6 @@ bool mei_write_is_idle(struct mei_device *dev)
}
EXPORT_SYMBOL_GPL(mei_write_is_idle);
-int mei_fw_status(struct mei_device *dev, struct mei_fw_status *fw_status)
-{
- const struct mei_fw_status *fw_src = >cfg->fw_status;
- int ret;
- int i;
-
- if (!fw_status)
- return -EINVAL;
-
- fw_status->count = fw_src->count;
- for (i = 0; i < fw_src->count && i < MEI_FW_STATUS_MAX; i++) {
- ret = pci_read_config_dword(dev->pdev,
- fw_src->status[i], _status->status[i]);
- if (ret)
- return ret;
- }
-
- return 0;
-}
-EXPORT_SYMBOL_GPL(mei_fw_status);
-
/**
* mei_device_init -- initialize mei_device structure
*
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 7051430..7080fff 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -233,6 +233,7 @@ struct mei_cl {
* @hw_start - start hw after reset
* @hw_config- configure hw
+ * @fw_status- get fw status registers
* @pg_state - power gating state of the device
* @pg_is_enabled- is power gating enabled
@@ -260,6 +261,8 @@ struct mei_hw_ops {
int (*hw_start)(struct mei_device *dev);
void (*hw_config)(struct mei_device *dev);
+
+ int (*fw_status)(struct mei_device *dev, struct mei_fw_status *fw_sts);
enum mei_pg_state (*pg_state)(struct mei_device *dev);
bool (*pg_is_enabled)(struct mei_device *dev);
@@ -731,7 +734,11 @@ static inline int mei_count_full_read_slots(struct
mei_device *dev)
return dev->ops->rdbuf_full_slots(dev);
}
-int
[char-misc-next 4/6] mei: remove the reference to pdev from mei_deivce
For purpose of adding testing HW we would like
to get rid of pci dependency in generic mei code.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw-me.c | 3 +--
drivers/misc/mei/hw-txe.c | 3 +--
drivers/misc/mei/mei_dev.h | 2 --
drivers/misc/mei/pci-me.c | 2 +-
drivers/misc/mei/pci-txe.c | 2 +-
5 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 678531c..da86310 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -676,7 +676,7 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void *dev_id)
/* Ack the interrupt here
* In case of MSI we don't go through the quick handler */
- if (pci_dev_msi_enabled(dev->pdev))
+ if (pci_dev_msi_enabled(to_pci_dev(dev->dev)))
mei_clear_interrupts(dev);
/* check if ME wants a reset */
@@ -854,7 +854,6 @@ struct mei_device *mei_me_dev_init(struct pci_dev *pdev,
mei_device_init(dev, >dev, _me_hw_ops);
dev->cfg = cfg;
- dev->pdev = pdev;
return dev;
}
diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c
index e4cb9dc..6eef676 100644
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -998,7 +998,7 @@ irqreturn_t mei_txe_irq_thread_handler(int irq, void
*dev_id)
mutex_lock(>device_lock);
mei_io_list_init(_list);
- if (pci_dev_msi_enabled(dev->pdev))
+ if (pci_dev_msi_enabled(to_pci_dev(dev->dev)))
mei_txe_check_and_ack_intrs(dev, true);
/* show irq events */
@@ -1157,7 +1157,6 @@ struct mei_device *mei_txe_dev_init(struct pci_dev *pdev,
init_waitqueue_head(>wait_aliveness_resp);
dev->cfg = cfg;
- dev->pdev = pdev;
return dev;
}
diff --git a/drivers/misc/mei/mei_dev.h b/drivers/misc/mei/mei_dev.h
index 7080fff..5a16cc4 100644
--- a/drivers/misc/mei/mei_dev.h
+++ b/drivers/misc/mei/mei_dev.h
@@ -401,7 +401,6 @@ struct mei_cfg {
/**
* struct mei_device - MEI private device struct
- * @pdev - pointer to pci device struct
* @dev - device on a bus
* @cdev - character device
* @minor - minor number allocated for device
@@ -420,7 +419,6 @@ struct mei_cfg {
* @cfg - per device generation config and ops
*/
struct mei_device {
- struct pci_dev *pdev; /* pointer to pci device struct */
struct device *dev;
struct cdev cdev;
int minor;
diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
index 83e8892..a910717 100644
--- a/drivers/misc/mei/pci-me.c
+++ b/drivers/misc/mei/pci-me.c
@@ -430,7 +430,7 @@ static int mei_me_pm_runtime_resume(struct device *device)
*/
static inline void mei_me_set_pm_domain(struct mei_device *dev)
{
- struct pci_dev *pdev = dev->pdev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
if (pdev->dev.bus && pdev->dev.bus->pm) {
dev->pg_domain.ops = *pdev->dev.bus->pm;
diff --git a/drivers/misc/mei/pci-txe.c b/drivers/misc/mei/pci-txe.c
index a1f60be..cd9dda7 100644
--- a/drivers/misc/mei/pci-txe.c
+++ b/drivers/misc/mei/pci-txe.c
@@ -378,7 +378,7 @@ static int mei_txe_pm_runtime_resume(struct device *device)
*/
static inline void mei_txe_set_pm_domain(struct mei_device *dev)
{
- struct pci_dev *pdev = dev->pdev;
+ struct pci_dev *pdev = to_pci_dev(dev->dev);
if (pdev->dev.bus && pdev->dev.bus->pm) {
dev->pg_domain.ops = *pdev->dev.bus->pm;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trickle charging for rtc-bq32k
> Do you have example how to acces of_ from i2c driver?
>
> Platform drivers do:
>
> if (pdev->dev.of_node) {
As I said, this is basically the same. Just use the node from the
client's device. Nothing special here.
signature.asc
Description: Digital signature
[char-misc-next 0/6] mei: remove pci dependency from mei module
In order to support testing hw module we remove dependency on pci from mei module Tomas Winkler (6): mei: push all standard settings into mei_device_init mei: get rid of most of the pci dependencies in mei mei: move fw_status back to hw ops handlers mei: remove the reference to pdev from mei_deivce mei: push pci cfg structure me hw mei: remove include to pci header from mei module files drivers/misc/mei/amthif.c| 70 +-- drivers/misc/mei/bus.c | 11 ++--- drivers/misc/mei/client.c| 48 +-- drivers/misc/mei/client.h| 4 +- drivers/misc/mei/debugfs.c | 7 ++- drivers/misc/mei/hbm.c | 71 ++-- drivers/misc/mei/hw-me.c | 70 ++- drivers/misc/mei/hw-me.h | 26 ++- drivers/misc/mei/hw-txe.c| 109 +-- drivers/misc/mei/hw-txe.h| 5 +- drivers/misc/mei/init.c | 78 +-- drivers/misc/mei/interrupt.c | 46 +- drivers/misc/mei/main.c | 42 - drivers/misc/mei/mei_dev.h | 37 ++- drivers/misc/mei/nfc.c | 46 +- drivers/misc/mei/pci-me.c| 4 +- drivers/misc/mei/pci-txe.c | 10 ++-- drivers/misc/mei/wd.c| 35 ++ include/linux/mei_cl_bus.h | 1 + 19 files changed, 377 insertions(+), 343 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 2/2] usb: phy: Temporarily hold wakeupsource on charger connect and disconnect events
From: Todd Poynor
usb: phy: Temporarily hold wakeupsource on charger connect and disconnect
events
Allow other parts of the system to react to the charger connect/disconnect
event without allowing the system to suspend before the other parts can process
the event. This wakeup_source times out after 2 seconds; if nobody else holds a
wakeup_source by that time then the device can sleep.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Signed-off-by: Todd Poynor
[kiran: Added context to commit message
wakeupsource handling implemented per PHY in phy core]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/otg-wakeupsource.c | 2 +-
drivers/usb/phy/phy.c | 10 ++
include/linux/usb/phy.h| 3 +++
3 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
index fca2010..70fa05e 100644
--- a/drivers/usb/phy/otg-wakeupsource.c
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -48,7 +48,7 @@ static void otgws_handle_event(struct usb_phy *otgws_xceiv,
unsigned long event)
case USB_EVENT_NONE:
case USB_EVENT_ID:
case USB_EVENT_CHARGER:
- usb_drop_wsource(otgws_xceiv);
+ usb_temporary_hold_wsource(otgws_xceiv);
break;
default:
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 659b1e8..c488716 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -483,3 +483,13 @@ void usb_drop_wsource(struct usb_phy *x)
__pm_relax(>wsource);
}
EXPORT_SYMBOL_GPL(usb_drop_wsource);
+
+/**
+ * usb_temporary_hold_wsource - temporarily hold wakeupsource
+ * @usb_phy: the phy returned by usb_get_phy()
+ */
+void usb_temporary_hold_wsource(struct usb_phy *x)
+{
+ __pm_wakeup_event(>wsource, msecs_to_jiffies(TEMPORARY_HOLD_TIME));
+}
+EXPORT_SYMBOL_GPL(usb_temporary_hold_wsource);
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 6c680e6..5f9b70e 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -13,6 +13,8 @@
#include
#include
+#define TEMPORARY_HOLD_TIME2000
+
enum usb_phy_interface {
USBPHY_INTERFACE_MODE_UNKNOWN,
USBPHY_INTERFACE_MODE_UTMI,
@@ -218,6 +220,7 @@ void usb_wsource_init(struct usb_phy *x, char
*phy_dev_name);
void usb_wsource_trash(struct usb_phy *x);
void usb_grab_wsource(struct usb_phy *x);
void usb_drop_wsource(struct usb_phy *x);
+void usb_temporary_hold_wsource(struct usb_phy *x);
#else
static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
{
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 1/2] usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
From: Todd Poynor
usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode
Purpose of this is to prevent the system to enter into suspend state from USB
peripheral traffic by hodling a wakeupsource when USB is connected and
enumerated in peripheral mode(say adb).
Disabled by default, can enable with:
echo Y > /sys/module/otg_wakeupsource/parameters/enabled
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Cc: Arve Hj�nnev�g
Cc: Benoit Goby
Signed-off-by: Todd Poynor
[kiran: Added context to commit message.
Included build fix from Benoit Goby and Arve Hj�nnev�g.
Removed lock->held field in driver as this mechanism is
provided in wakeupsource driver.
wakelock(wl) terminology replaced with wakeup_source(ws).
changed to "disabled by default" from "enable by default".
sys entry(module param) field modified to otg_wakeupsource.
included Todd's refactoring logic.
Introduced get_phy_hook to handle otgws_xceiv per-PHY.
otgws_nb moved to otg_wakeupsource_init function.
wakeupsource handling implemeted per-PHY(in phy core).
modified Kconfig help text]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/Kconfig| 8 +++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/otg-wakeupsource.c | 140 +
drivers/usb/phy/phy.c | 42 +++
include/linux/usb/phy.h| 8 +++
5 files changed, 199 insertions(+)
create mode 100644 drivers/usb/phy/otg-wakeupsource.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index e253fa0..d9ddd85 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -6,6 +6,14 @@ menu "USB Physical Layer drivers"
config USB_PHY
def_bool n
+config USB_OTG_WAKEUPSOURCE
+ bool "Hold wakeupsource when USB is enumerated in peripheral mode"
+ depends on PM_SLEEP
+ select USB_PHY
+ help
+ Prevent the system going into automatic suspend while
+ it is attached as a USB peripheral by holding a wakeupsource.
+
#
# USB Transceiver Drivers
#
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 24a9133..ca2fbaf 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_USB_PHY) += phy.o
obj-$(CONFIG_OF) += of.o
+obj-$(CONFIG_USB_OTG_WAKEUPSOURCE) += otg-wakeupsource.o
# transceiver drivers, keep the list sorted
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
new file mode 100644
index 000..fca2010
--- /dev/null
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -0,0 +1,140 @@
+/*
+ * otg-wakeupsource.c
+ *
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+bool enabled = false;
+
+static DEFINE_SPINLOCK(otgws_spinlock);
+static struct usb_phy *get_phy_hook(void);
+
+static void otgws_handle_event(struct usb_phy *otgws_xceiv, unsigned long
event)
+{
+ unsigned long irqflags;
+
+ spin_lock_irqsave(_spinlock, irqflags);
+
+ if (!enabled) {
+ usb_drop_wsource(otgws_xceiv);
+ spin_unlock_irqrestore(_spinlock, irqflags);
+ return;
+ }
+
+ switch (event) {
+ case USB_EVENT_VBUS:
+ case USB_EVENT_ENUMERATED:
+ usb_grab_wsource(otgws_xceiv);
+ break;
+
+ case USB_EVENT_NONE:
+ case USB_EVENT_ID:
+ case USB_EVENT_CHARGER:
+ usb_drop_wsource(otgws_xceiv);
+ break;
+
+ default:
+ break;
+ }
+
+ spin_unlock_irqrestore(_spinlock, irqflags);
+}
+static struct usb_phy *get_phy_hook(void)
+{
+ struct usb_phy *phy;
+
+ phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+ if (IS_ERR(phy)) {
+ pr_err("%s: No OTG transceiver found\n", __func__);
+ return NULL;
+ }
+
+ return phy;
+}
+static int otgws_otg_notifications(struct notifier_block *nb,
+ unsigned long event, void *unused)
+{
+ static struct usb_phy *otgws_xceiv;
+
+ otgws_xceiv = get_phy_hook();
+
+ if (otgws_xceiv)
+ otgws_handle_event(otgws_xceiv, event);
+
+ return NOTIFY_OK;
+}
+
+static int set_enabled(const char *val,
Re: [PATCH v10 03/19] arm: fiq: Replace default FIQ handler
On 28/08/14 16:01, Russell King - ARM Linux wrote:
> On Tue, Aug 19, 2014 at 07:12:07PM +0100, Daniel Thompson wrote:
>> On 19/08/14 18:37, Russell King - ARM Linux wrote:
>>> On Tue, Aug 19, 2014 at 05:45:53PM +0100, Daniel Thompson wrote:
+int register_fiq_nmi_notifier(struct notifier_block *nb)
+{
+ return atomic_notifier_chain_register(_nmi_chain, nb);
+}
+
+asmlinkage void __exception_irq_entry fiq_nmi_handler(struct pt_regs
*regs)
+{
+ struct pt_regs *old_regs = set_irq_regs(regs);
+
+ nmi_enter();
+ atomic_notifier_call_chain(_nmi_chain, (unsigned long)regs, NULL);
+ nmi_exit();
+ set_irq_regs(old_regs);
+}
>>>
>>> Really not happy with this. What happens if a FIQ occurs while we're
>>> inside register_fiq_nmi_notifier() - more specifically inside
>>> atomic_notifier_chain_register() ?
>>
>> Should depend on which side of the rcu update we're on.
>
> I just asked Paul McKenney, our RCU expert... essentially, yes, RCU
> stuff itself is safe in this context. However, RCU stuff can call into
> lockdep if lockdep is configured, and there are questions over lockdep.
>
> There's some things which can be done to reduce the lockdep exposure
> to it, such as ensuring that rcu_read_lock() is first called outside
> of FIQ context.
>
> There's concerns with whether either printk() in check_flags() could
> be reached too (flags there should always indicate that IRQs were
> disabled, so that reduces down to a question about just the first
> printk() there.)
>
> There's also the very_verbose() stuff for RCU lockdep classes which
> Paul says must not be enabled.
>
> Lastly, Paul isn't a lockdep expert, but he sees nothing that prevents
> lockdep doing the deadlock checking as a result of the above call.
>
> So... this coupled with my feeling that notifiers make it too easy for
> unreviewed code to be hooked into this path, I'm fairly sure that we
> don't want to be calling atomic notifier chains from FIQ context.
Having esablished (elsewhere in the thread) that RCU usage is safe
from FIQ I have been working on the assumption that your feeling
regarding unreviewed code is sufficient on its own to avoid using
notifiers (and also to avoid a list of function pointers like on x86).
Therefore I have made the changes requested and produced a
before/after patch to show the impact of this. I will merge this
into the FIQ patchset shortly (I need to run a few more build tests
first).
Personally I still favour using notifiers and think the coupling below is
excessive. Nevertheless I've run a couple of basic tests on the code
below and it works fine.
diff --git a/arch/arm/include/asm/fiq.h b/arch/arm/include/asm/fiq.h
index 175bfed..a25c952 100644
--- a/arch/arm/include/asm/fiq.h
+++ b/arch/arm/include/asm/fiq.h
@@ -54,7 +54,6 @@ extern void disable_fiq(int fiq);
extern int ack_fiq(int fiq);
extern void eoi_fiq(int fiq);
extern bool has_fiq(int fiq);
-extern int register_fiq_nmi_notifier(struct notifier_block *nb);
extern void fiq_register_mapping(int irq, struct fiq_chip *chip);
/* helpers defined in fiqasm.S: */
diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
index 6563da0..cb5ccd6 100644
--- a/arch/arm/include/asm/kgdb.h
+++ b/arch/arm/include/asm/kgdb.h
@@ -51,6 +51,7 @@ extern void kgdb_handle_bus_error(void);
extern int kgdb_fault_expected;
extern int kgdb_register_fiq(unsigned int fiq);
+extern void kgdb_handle_fiq(struct pt_regs *regs);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index b2bd1c7..7422b58 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -43,12 +43,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#define FIQ_OFFSET ({ \
@@ -65,7 +67,6 @@ static unsigned long no_fiq_insn;
static int fiq_start = -1;
static RADIX_TREE(fiq_data_tree, GFP_KERNEL);
static DEFINE_MUTEX(fiq_data_mutex);
-static ATOMIC_NOTIFIER_HEAD(fiq_nmi_chain);
/* Default reacquire function
* - we always relinquish FIQ control
@@ -218,17 +219,23 @@ bool has_fiq(int fiq)
}
EXPORT_SYMBOL(has_fiq);
-int register_fiq_nmi_notifier(struct notifier_block *nb)
-{
- return atomic_notifier_chain_register(_nmi_chain, nb);
-}
-
asmlinkage void __exception_irq_entry fiq_nmi_handler(struct pt_regs *regs)
{
struct pt_regs *old_regs = set_irq_regs(regs);
nmi_enter();
- atomic_notifier_call_chain(_nmi_chain, (unsigned long)regs, NULL);
+
+ /* these callbacks deliberately avoid using a notifier chain in
+* order to ensure code review happens (drivers cannot "secretly"
+* employ FIQ without modifying this chain of calls).
+*/
+#ifdef CONFIG_KGDB_FIQ
+ kgdb_handle_fiq(regs);
+#endif
+#ifdef CONFIG_ARM_GIC
+ gic_handle_fiq_ipi();
+#endif
+
nmi_exit();
Re: [PATCH v3 13/17] ARM64 / ACPI: Add GICv2 specific ACPI boot support
On 01.09.2014 19:35, Marc Zyngier wrote:
On 01/09/14 15:57, Hanjun Guo wrote:
From: Tomasz Nowicki
ACPI kernel uses MADT table for proper GIC initialization. It needs to
parse GIC related subtables, collect CPU interface and distributor
addresses and call driver initialization function (which is hardware
abstraction agnostic). In a similar way, FDT initialize GICv1/2.
NOTE: This commit allow to initialize GICv1/2 only.
I cannot help but notice that there is no support for KVM here. It'd be
good to add a note to that effect, so that people do not expect
virtualization support to be working when booting with ACPI.
yes, it is worth mentioning!
Signed-off-by: Tomasz Nowicki
Signed-off-by: Hanjun Guo
---
arch/arm64/include/asm/acpi.h|2 -
arch/arm64/kernel/acpi.c | 23 +++
arch/arm64/kernel/irq.c |5 ++
drivers/irqchip/irq-gic.c| 114 ++
include/linux/irqchip/arm-gic-acpi.h | 33 ++
5 files changed, 175 insertions(+), 2 deletions(-)
create mode 100644 include/linux/irqchip/arm-gic-acpi.h
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index a867467..5d2ab63 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -97,8 +97,6 @@ void __init acpi_smp_init_cpus(void);
extern int (*acpi_suspend_lowlevel)(void);
#define acpi_wakeup_address 0
-#define ACPI_MAX_GIC_CPU_INTERFACE_ENTRIES 65535
-
#else
static inline bool acpi_psci_present(void) { return false; }
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 354b912..b3b82b0 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include
@@ -313,6 +314,28 @@ void __init acpi_boot_table_init(void)
pr_err("Can't find FADT or error happened during parsing
FADT\n");
}
+void __init acpi_gic_init(void)
+{
+ struct acpi_table_header *table;
+ acpi_status status;
+ acpi_size tbl_size;
+ int err;
+
+ status = acpi_get_table_with_size(ACPI_SIG_MADT, 0, , _size);
+ if (ACPI_FAILURE(status)) {
+ const char *msg = acpi_format_exception(status);
+
+ pr_err("Failed to get MADT table, %s\n", msg);
+ return;
+ }
+
+ err = gic_v2_acpi_init(table);
+ if (err)
+ pr_err("Failed to initialize GIC IRQ controller");
What will happen when you get to implement GICv3 support? Another entry
like this? Why isn't this entirely contained in the GIC driver? Do I
sound like a stuck record?
There will be another call to GICv3 init:
[...]
err = gic_v3_acpi_init(table);
if (err)
err = gic_v2_acpi_init(table);
if (err)
pr_err("Failed to initialize GIC IRQ controller");
[...]
This is the main reason I put common code here.
+
+ early_acpi_os_unmap_memory((char *)table, tbl_size);
+}
+
/*
* acpi_suspend_lowlevel() - save kernel state and suspend.
*
diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
index 0f08dfd..c074d60 100644
--- a/arch/arm64/kernel/irq.c
+++ b/arch/arm64/kernel/irq.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
unsigned long irq_err_count;
@@ -78,6 +79,10 @@ void __init set_handle_irq(void (*handle_irq)(struct pt_regs
*))
void __init init_IRQ(void)
{
irqchip_init();
+
+ if (!handle_arch_irq)
+ acpi_gic_init();
+
Why isn't this called from irqchip_init? It would seem like the logical
spot to probe an interrupt controller.
irqchip.c is OF dependent, I want to decouple these from the very
beginning.
if (!handle_arch_irq)
panic("No interrupt controller found.");
}
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 4b959e6..85cbf43 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -33,12 +33,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
#include
@@ -1029,3 +1031,115 @@ IRQCHIP_DECLARE(msm_8660_qgic, "qcom,msm-8660-qgic",
gic_of_init);
IRQCHIP_DECLARE(msm_qgic2, "qcom,msm-qgic2", gic_of_init);
#endif
+
+#ifdef CONFIG_ACPI
+static u64 dist_phy_base, cpu_phy_base = ULONG_MAX;
Please use phys_addr_t for physical addresses. The use of ULONG_MAX
looks dodgy. Please have a proper symbol to flag the fact that it hasn't
been assigned yet.
Sure, will do.
+
+static int __init
+gic_acpi_parse_madt_cpu(struct acpi_subtable_header *header,
+ const unsigned long end)
+{
+ struct acpi_madt_generic_interrupt *processor;
+ u64 gic_cpu_base;
phys_addr_t
+ processor = (struct acpi_madt_generic_interrupt *)header;
+
+ if (BAD_MADT_ENTRY(processor, end))
+ return -EINVAL;
+
+
Re: [PATCH v3] drm/i915: Fix lock dropping in intel_tv_detect()
On Tue, 02 Sep 2014, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When intel_tv_detect() fails to do load detection it would forget to
> drop the locks and clean up the acquire context. Fix it up.
>
> This is a regression from:
> commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44
> Author: Ville Syrjälä
> Date: Mon Aug 11 13:15:35 2014 +0300
>
> drm/i915: Fix locking for intel_enable_pipe_a()
>
> v2: Make the code more readable (Chris)
> v3: Drop WARN_ON(type < 0) (Chris)
>
> Cc: sta...@vger.kernel.org
> Cc: Tibor Billes
> Reported-by: Tibor Billes
> Tested-by: Tibor Billes
> Reviewed-by: Chris Wilson
> Signed-off-by: Ville Syrjälä
Pushed to drm-intel-fixes, thanks for the patch, review, and testing.
BR,
Jani.
> ---
> drivers/gpu/drm/i915/intel_tv.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 32186a6..c69d3ce 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1311,6 +1311,7 @@ intel_tv_detect(struct drm_connector *connector, bool
> force)
> {
> struct drm_display_mode mode;
> struct intel_tv *intel_tv = intel_attached_tv(connector);
> + enum drm_connector_status status;
> int type;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force=%d\n",
> @@ -1328,16 +1329,19 @@ intel_tv_detect(struct drm_connector *connector, bool
> force)
> if (intel_get_load_detect_pipe(connector, , , )) {
> type = intel_tv_detect_type(intel_tv, connector);
> intel_release_load_detect_pipe(connector, );
> + status = type < 0 ?
> + connector_status_disconnected :
> + connector_status_connected;
> } else
> - return connector_status_unknown;
> + status = connector_status_unknown;
>
> drm_modeset_drop_locks();
> drm_modeset_acquire_fini();
> } else
> return connector->status;
>
> - if (type < 0)
> - return connector_status_disconnected;
> + if (status != connector_status_connected)
> + return status;
>
> intel_tv->type = type;
> intel_tv_find_better_format(connector);
> --
> 1.8.5.5
>
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] i2c: rk3x: fix bug that cause transfer fails in master receive mode
On Sat, Aug 23, 2014 at 02:00:52AM +0800, Addy Ke wrote: > In rk3x SOC, the I2C controller can receive/transmit up to 32 bytes data > in one chunk, so the size of data to be write/read to/from TXDATAx/RXDATAx > must be less than or equal 32 bytes at a time. > > Tested on rk3288-pinky board, elan receive 158 bytes data. > > Suggested-by: Dmitry Torokhov > Signed-off-by: Addy Ke > Acked-by: Max Schwarz Applied to for-current, thanks! Please don't send new versions of a patch as reply-to of a previous version. signature.asc Description: Digital signature
Re: [PATCH v10 03/19] arm: fiq: Replace default FIQ handler
On Tue, Sep 02, 2014 at 12:03:11PM +0100, Daniel Thompson wrote: > On 28/08/14 17:15, Paul E. McKenney wrote: > > On Thu, Aug 28, 2014 at 04:54:25PM +0100, Daniel Thompson wrote: > >> On 28/08/14 16:01, Russell King - ARM Linux wrote: > >>> There's concerns with whether either printk() in check_flags() could > >>> be reached too (flags there should always indicate that IRQs were > >>> disabled, so that reduces down to a question about just the first > >>> printk() there.) > >>> > >>> There's also the very_verbose() stuff for RCU lockdep classes which > >>> Paul says must not be enabled. > >>> > >>> Lastly, Paul isn't a lockdep expert, but he sees nothing that prevents > >>> lockdep doing the deadlock checking as a result of the above call. > >>> > >>> So... this coupled with my feeling that notifiers make it too easy for > >>> unreviewed code to be hooked into this path, I'm fairly sure that we > >>> don't want to be calling atomic notifier chains from FIQ context. > > Having esablished (above) that RCU usage is safe from FIQ I have been > working on the assumption that your feeling regarding unreviewed code > is sufficient on its own to avoid using notifiers (and also to avoid > a list of function pointers like on x86). I'm assuming that "your" above refers to Paul here, since you addressed your message To: Paul and only copied me for information purposes. If not, please address your message more appropriately so as to avoid confusion. Thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/2] tty: serial: 8250: Add Mediatek UART driver
[...]
> +static int mtk8250_probe_of(struct platform_device *pdev, struct uart_port
> *p,
> +struct mtk8250_data *data)
> +{
> + int err;
> + struct device_node *np = pdev->dev.of_node;
> +
> + data->clk = of_clk_get(np, 0);
> + if (IS_ERR(data->clk)) {
> + dev_warn(>dev, "Can't get timer clock\n");
> + return PTR_ERR(data->clk);
> + }
Elsewhere you use devm_ interfaces. Can we not use devm_clk_get?
You might need to give the clock a name, but that's generally a good
thing -- it helps if a future revision has multiple clocks.
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sparc32, leon: Make leom_dma_ops avaiable when !CONFIG_PCI
The leon_dma_ops struct is needed for leon regardless of PCI configuration.
Signed-off-by: Andreas Larsson
---
arch/sparc/include/asm/dma-mapping.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/sparc/include/asm/dma-mapping.h
b/arch/sparc/include/asm/dma-mapping.h
index 1ee0271..5b1b52a 100644
--- a/arch/sparc/include/asm/dma-mapping.h
+++ b/arch/sparc/include/asm/dma-mapping.h
@@ -20,10 +20,12 @@ extern struct bus_type pci_bus_type;
static inline struct dma_map_ops *get_dma_ops(struct device *dev)
{
-#if defined(CONFIG_SPARC32) && defined(CONFIG_PCI)
+#ifdef CONFIG_SPARC_LEON
if (sparc_cpu_model == sparc_leon)
return leon_dma_ops;
- else if (dev->bus == _bus_type)
+#endif
+#if defined(CONFIG_SPARC32) && defined(CONFIG_PCI)
+ if (dev->bus == _bus_type)
return _dma_ops;
#endif
return dma_ops;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/4] ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code.
On 09/02/2014 02:09 PM, Jean-Francois Moine wrote:
On Tue, 02 Sep 2014 16:12:40 +0530
Varka Bhadram wrote:
+ switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
+ case 0x11:
+ return SND_SOC_DAIFMT_CBS_CFS;
+ case 0x10:
+ return SND_SOC_DAIFMT_CBS_CFM;
+ case 0x01:
+ return SND_SOC_DAIFMT_CBM_CFS;
+ default:
+ return SND_SOC_DAIFMT_CBM_CFM;
+ }
+
+ /* Shouldn't be here */
+ return -EINVAL;
+}
It will be nice if we declare the switch case numbers as macros (specific
name)...
I don't see which macros: the values are just 2 booleans.
I am talking about 0x11, 0x10, 0x01 values.. We can give any understandable
names to those...?
#define TRUE_TRUE 0x11
#define TRUE_FALSE 0x10
#define FALSE_TRUE 0x01
or
case ((TRUE << 4) | TRUE:
...
case ((TRUE << 4) | FALSE:
...
case ((FALSE << 4) | TRUE:
...
I would vote for this. Even over the options suggested by Takashi, but
then again this really a matter of taste.
The fact that frame and bit-clock master boolean values are bundled into
a single "enum" field, instead of two dedicated bits, makes all options
bit inconvenient.
Best regards,
Jyri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/2] DTS: serial: Add bindings documention for the Mediatek UARTs
On Tue, Aug 12, 2014 at 03:12:17PM +0100, Matthias Brugger wrote:
> This patch adds the devicetree documentation for the Mediatek UART.
>
> Signed-off-by: Matthias Brugger
> ---
> .../devicetree/bindings/serial/mtk-uart.txt| 20
>
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/serial/mtk-uart.txt
>
> diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt
> b/Documentation/devicetree/bindings/serial/mtk-uart.txt
> new file mode 100644
> index 000..6ca0e15
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt
> @@ -0,0 +1,20 @@
> +* Mediatek Universal Asynchronous Receiver/Transmitter (UART)
> +
> +Required properties:
> +- compatible: "mediatek,mt6577-uart"
> + Compatibility with mt6577, mt6589, mt6582
> +
> +- reg: The base address of the UART register bank.
> +
> +- interrupts: A single interrupt specifier.
> +
> +- clocks: Clock driving the hardware.
> +
> +Example:
> +
> + uart0: serial@11006000 {
> + compatible = "mediatek,mt6577-uart";
> + reg = <0x11006000 0x400>;
> + interrupts = ;
> + clocks = <_clk>;
> + };
This looks generally sane to me. It's simple and doesn't seem to have
any of the usual problems bindings have.
For the mt6577, mt6589, and mt6582, Do you expect to have specific
strings like:
compatible = "mediatek,mt6589-uart", "mediatek,mt6577-uart";
If so, could you update the compatible description to something like:
- compatible: should contain:
* "mediatek,mt6589-uart" for ...
* "mediatek,mt6582-uart" for ...
* "mediatek,mt6577-uart" for all compatible UARTS (mt6589,mt6582,mt6577)
That way the driver just needs to recognise "mediatek,mt6577-uart" for
now but can have quirks later if we discover integration differences.
Cheers,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
On 2 September 2014 21:03, Theodore Ts'o wrote:
> On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote:
>> On 2 September 2014 14:05, Theodore Ts'o wrote:
>> > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
>> > longer see the my Dell 30" monitor when it is connected via the
>> > docking station using a Displayport connector. This worked using 3.16
>> > kernel.
>> >
>> > If I connect to the monitor using the mini-display, by passing the
>> > docking station, things work fine (but of course it's annoying not to
>> > be able to use the docking station).
>> >
>> > Is this a known problem? This is not the first time that we've had
>> > regressions with this docking station. It's vaguely reminsicent of
>> >
>> > https://bugs.freedesktop.org/show_bug.cgi?id=71267
>> >
>> > Except the system isn't hanging; it's just not seeing the monitor at all.
>>
>> Have you the Dell 30" set to Displayport 1.2 enabled mode?
>
> No, it DP 1.2 was disabled. If I enable it, it breaks things when I
> try connecting via the MiniDP port (bypassing the dock), and it is
> still broken when I try to talk via the DisplayPort in the dock.
>
> If I disable DP 1.2 again, it works via the MiniDP port, but if I try
> to connect through the dock (which has a DP Hub which I believe is
> MST/DP 1.2 capable), it is still broken.
>
> It does seem that this might be related to 3.17-rc3 trying to talk DP
> 1.2 if it is available, since I can't control what the DP hub in the
> docking station advertises --- is there a commit or some kind of hack
> I can try to force talking to the DP hub using DP 1.1?
>
Interesting, I have the same combo of hw available on my desk at work,
but it might be a couple of days before I can get to the office to
debug it,
can you boot with drm.debug=6 and get me the dmesg?
The attached hack turns off mst so might be useful as a workaround,
but I should be able to fix this once I sit down at my desk.
Dave.
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6db84bf..568249e 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3392,6 +3392,7 @@ intel_dp_probe_mst(struct intel_dp *intel_dp)
{
u8 buf[1];
+ return false;
if (!intel_dp->can_mst)
return false;
Re: [PATCH 01/12] Staging: rtl8821ae: hal_bt_coexist: fix commenting style
I see, thanks, I will fix it, I was just worried about the subjects being too long so I just stuck with the same subject; is there a character limit on how long the subject line should be? Or as long as it's reasonable, it'll be fine? On Tue, Sep 02, 2014 at 12:19:40PM +0300, Dan Carpenter wrote: > Hm... Now you've broken it into *too* many separate patches. Also the > subjects are the same. Also the subjects are too vague. Which coding > style issue is addressed? > > It should be something like: > patch 1: comments > patch 2: add/remove spaces > patch 3: fix quoted text > patch 4: braces > patch 5: add a blank line > > regards, > dan carpenter > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] usb: dwc3: add ST dwc3 glue layer to manage dwc3 HC
Hi Felipe,
Sorry for the delay in replying to this mail, I've been trying to get answers
to the suspend/resume
questions you had.
> > +config USB_DWC3_ST
> > + tristate "STMicroelectronics Platforms"
> > + depends on ARCH_STI && OF
> > + default USB_DWC3_HOST
>
> this seems wrong as USB_DWC3_{HOST,GADGET,DUAL_ROLE} are booleans and
> USB_DWC3_ST is a tristate. Better to stick with defaulting to USB_DWC3
> instead like all the others.
Ok will fix.
> > +static inline void st_dwc3_writel(void __iomem *base, u32 offset, u32
> > value)
> > +{
> > + writel_relaxed(value, base + offset);
>
> why relaxed ?
The writel and readl implementations on ARM are quite expensive.
The writel, does a memory barrier, and also a outer_sync(), which involves
taking a spinlock, and draining the cache store buffers.
The readl also does a memory barrier.
These barriers / cache operations are unnecessary here as the peripheral memory
has been ioremap'ed as device memory, and
it is only one device we are writing to, so the writel/readl_relaxed variants
are good enough as the ARM arch guarentees they
will arrive in program order.
There is some more info about this here
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/117658
Note: It's only possible when we know the driver is not being used on other
architectures which may have different constraints.
However for this driver, we know this IP (st glue logic) has only been used on
ARM based SoC's.
>
> > +}
> > +
> > +/**
> > + * st_dwc3_drd_init: program the port
> > + * @dwc3_data: driver private structure
> > + * Description: this function is to program the port as either host or
> > device
> > + * according to the static configuration passed from devicetree.
> > + * OTG and dual role are not yet supported!
> > + */
> > +static int st_dwc3_drd_init(struct st_dwc3 *dwc3_data)
> > +{
> > + u32 val;
> > + int err;
> > +
> > + err = regmap_read(dwc3_data->regmap, dwc3_data->syscfg_reg_off, );
> > + if (err)
> > + return err;
> > +
> > + switch (dwc3_data->dr_mode) {
> > + case USB_DR_MODE_PERIPHERAL:
> > + val |= USB_SET_PORT_DEVICE;
> > + dev_dbg(dwc3_data->dev, "Configuring as Device\n");
> > + break;
> > +
> > + case USB_DR_MODE_HOST:
> > + val &= USB_HOST_DEFAULT_MASK;
>
> are you missing a ~ here ? Also, shouldn't you mask off the bits before
> this switch ?
Yes your right, good spot! In the next iteration I've defined macros for the
bits in
this control register and explitcitly set/clear them for both cases, also
adding a comment regarding
the USB3_DELAY_VBUSVALID bit.
By chance host mode still worked with this bug present as the reset value of
the register on
this SoC is OK to have working host mode.
>
> > + dev_dbg(dwc3_data->dev, "Configuring as Host\n");
> > + break;
> > +
> > + default:
> > + dev_err(dwc3_data->dev, "Unsupported mode of operation %d\n",
> > + dwc3_data->dr_mode);
> > + return -EINVAL;
> > + }
> > +
> > + return regmap_write(dwc3_data->regmap, dwc3_data->syscfg_reg_off, val);
> > +}
> > +
> > +/**
> > + * st_dwc3_init: init the controller via glue logic
> > + * @dwc3_data: driver private structure
> > + */
> > +static void st_dwc3_init(struct st_dwc3 *dwc3_data)
> > +{
> > +
>
> this blank line isn't necessary.
Ok, removed in next iteration
> > +
> > + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "syscfg-reg");
> > + if (!res) {
> > + ret = -ENXIO;
> > + goto undo_platform_dev_alloc;
> > + }
> > +
> > + dwc3_data->syscfg_reg_off = res->start;
> > +
> > + dev_dbg(>dev, "glue-logic addr 0x%p, syscfg-reg offset 0x%x\n",
> > + dwc3_data->glue_base, dwc3_data->syscfg_reg_off);
>
> looks like this message would be more of a dev_vdbg().
Ok, changed to dev_vdbg in next iteration
> > +
> > +#ifdef CONFIG_PM_SLEEP
> > +static int st_dwc3_suspend(struct device *dev)
> > +{
> > + struct st_dwc3 *dwc3_data = dev_get_drvdata(dev);
> > +
> > + reset_control_assert(dwc3_data->rstc_pwrdn);
> > + reset_control_assert(dwc3_data->rstc_rst);
>
> Two questions:
>
> 1) how would you handle the case when this device is a wakeup source ?
I've confirmed with ST the usb3 IP can't be a wakeup source on this SoC.
> 2) when resuming, wouldn't you have to reinitialize the entire core ?
I asked ST to test this, as a full working suspend / resume setup involves some
firmware for the
standby controller which I don't currently have access to (and it is only with
the SBC running that all
power will be removed from this part of the SoC). They have confirmed that the
usb3 port works after a suspend / resume
and devices are correctly enumerated etc after a resume with the code as it was
submitted.
What I did notice though after re-reading it, is that we are not re-configuring
the ST glue logic registers
on a resume. So the controller could end up with
Re: [PATCH] Input: cap1106 - fix register definition
On Sep 2, 2014, at 9:43 AM, Daniel Mack wrote: > On 09/02/2014 08:32 AM, Klaus Goger wrote: >> Use the correct register address for Calibration Active and Interrupt >> Enable >> >> Signed-off-by: Klaus Goger > > These register definitions are currently unused, but your fix is > correct. Just curious - are you planning to send patches that make use > of them? I want to use CAP1106_REG_SENSITIVITY_CONTROL but I have yet to decide how to expose it to the user. Probably adding another device tree option. But somehow it feels like cluttering up the dts. Once I have settled about that I will send patches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 3/4] usb: hcd: Calibrate PHY post hcd reset
Some quirky PHYs may require to be calibrated post the
hcd initialization.
The USB 3.0 DRD PHY on Exynos5420/5800 systems, coming along
with Synopsys's DWC3 controller, is one such PHY which needs
to be calibrated post xhci's reset at initialization time and
at resume time, to get the controller work at SuperSpeed.
So facilitating the HCDs to calibrate the PHY.
Signed-off-by: Vivek Gautam
---
drivers/usb/core/hcd.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index c4ed66c..6e01d09 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2202,6 +2202,7 @@ int hcd_bus_resume(struct usb_device *rhdev, pm_message_t
msg)
struct usb_hcd *hcd = container_of(rhdev->bus, struct usb_hcd, self);
int status;
int old_state = hcd->state;
+ int ret;
dev_dbg(>dev, "usb %sresume\n",
(PMSG_IS_AUTO(msg) ? "auto-" : ""));
@@ -2216,6 +2217,15 @@ int hcd_bus_resume(struct usb_device *rhdev,
pm_message_t msg)
hcd->state = HC_STATE_RESUMING;
status = hcd->driver->bus_resume(hcd);
+
+ /* calibrate the phy here */
+ ret = phy_calibrate(hcd->gen_phy);
+ if (ret < 0 && ret != -ENOTSUPP) {
+ dev_err(hcd->self.controller,
+ "failed to calibrate USB PHY\n");
+ return ret;
+ }
+
clear_bit(HCD_FLAG_WAKEUP_PENDING, >flags);
if (status == 0) {
struct usb_device *udev;
@@ -2738,6 +2748,14 @@ int usb_add_hcd(struct usb_hcd *hcd,
}
hcd->rh_pollable = 1;
+ /* calibrate the phy here */
+ retval = phy_calibrate(hcd->gen_phy);
+ if (retval < 0 && retval != -ENOTSUPP) {
+ dev_err(hcd->self.controller,
+ "failed to calibrate USB PHY\n");
+ return retval;
+ }
+
/* NOTE: root hub and controller capabilities may not be the same */
if (device_can_wakeup(hcd->self.controller)
&& device_can_wakeup(>self.root_hub->dev))
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 2/4] usb: host: xhci-plat: Get PHYs for xhci's hcds
The host controller by itself may sometimes need to handle PHY
and/or calibrate some of the PHY settings to get full support out
of the PHY controller. The PHY core provides a calibration
funtionality now to do so.
Therefore, facilitate getting the two possible PHYs, viz.
USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3).
Signed-off-by: Vivek Gautam
---
drivers/usb/host/xhci-plat.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 1a0cf9f..6afd508 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include
#include
@@ -180,6 +181,19 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto put_hcd;
}
+ /* Get possile USB 2.0 type PHY (UTMI+) available with xhci */
+ hcd->gen_phy = devm_phy_get(>dev, "usb2-phy");
+ if (IS_ERR(hcd->gen_phy)) {
+ ret = PTR_ERR(hcd->gen_phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS && ret != -ENODEV) {
+ hcd->gen_phy = NULL;
+ dev_warn(>dev,
+"Error retrieving usb2 phy: %d\n", ret);
+ }
+ }
+
ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto disable_clk;
@@ -209,6 +223,19 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
+ /* Get possile USB 3.0 type PHY (PIPE3) available with xhci */
+ xhci->shared_hcd->gen_phy = devm_phy_get(>dev, "usb3-phy");
+ if (IS_ERR(xhci->shared_hcd->gen_phy)) {
+ ret = PTR_ERR(xhci->shared_hcd->gen_phy);
+ if (ret == -EPROBE_DEFER) {
+ return ret;
+ } else if (ret != -ENOSYS && ret != -ENODEV) {
+ xhci->shared_hcd->gen_phy = NULL;
+ dev_warn(>dev,
+"Error retrieving usb3 phy: %d\n", ret);
+ }
+ }
+
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
if (ret)
goto put_usb3_hcd;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 4/4] phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800
Adding phy calibrate callback, which facilitates setting certain PHY settings post initialization of the PHY controller. Exynos5420 and Exynos5800 have 28nm USB 3.0 DRD PHY for which the Loss-of-Signal (LOS) Detector Threshold Level as well as Tx-Vboost-Level should be controlled for Super-Speed operations. Additionally set proper time to wait for RxDetect measurement, for desired PHY reference clock, so as to solve issue with enumeration of few USB 3.0 devices, like Samsung SUM-TSB16S 3.0 USB drive on the controller. We are using CR_port for this purpose to send required data to override the LOS values. On testing with USB 3.0 devices on USB 3.0 port present on SMDK5420, and peach-pit boards should see following message: usb 2-1: new SuperSpeed USB device number 2 using xhci-hcd and without this patch, should see below shown message: usb 1-1: new high-speed USB device number 2 using xhci-hcd [Also removed unnecessary extra lines in the register macro definitions] Signed-off-by: Vivek Gautam --- drivers/phy/phy-exynos5-usbdrd.c | 185 ++ 1 file changed, 170 insertions(+), 15 deletions(-) diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c index 47f47fe..85742b0 100644 --- a/drivers/phy/phy-exynos5-usbdrd.c +++ b/drivers/phy/phy-exynos5-usbdrd.c @@ -37,13 +37,11 @@ /* EXYNOS5: USB 3.0 DRD PHY registers */ #define EXYNOS5_DRD_LINKSYSTEM 0x04 - #define LINKSYSTEM_FLADJ_MASK (0x3f << 1) #define LINKSYSTEM_FLADJ(_x) ((_x) << 1) #define LINKSYSTEM_XHCI_VERSION_CONTROLBIT(27) #define EXYNOS5_DRD_PHYUTMI0x08 - #define PHYUTMI_OTGDISABLE BIT(6) #define PHYUTMI_FORCESUSPEND BIT(1) #define PHYUTMI_FORCESLEEP BIT(0) @@ -51,26 +49,20 @@ #define EXYNOS5_DRD_PHYPIPE0x0c #define EXYNOS5_DRD_PHYCLKRST 0x10 - #define PHYCLKRST_EN_UTMISUSPEND BIT(31) - #define PHYCLKRST_SSC_REFCLKSEL_MASK (0xff << 23) #define PHYCLKRST_SSC_REFCLKSEL(_x)((_x) << 23) - #define PHYCLKRST_SSC_RANGE_MASK (0x03 << 21) #define PHYCLKRST_SSC_RANGE(_x)((_x) << 21) - #define PHYCLKRST_SSC_EN BIT(20) #define PHYCLKRST_REF_SSP_EN BIT(19) #define PHYCLKRST_REF_CLKDIV2 BIT(18) - #define PHYCLKRST_MPLL_MULTIPLIER_MASK (0x7f << 11) #define PHYCLKRST_MPLL_MULTIPLIER_100MHZ_REF (0x19 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_50M_REF (0x32 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_24MHZ_REF(0x68 << 11) #define PHYCLKRST_MPLL_MULTIPLIER_20MHZ_REF(0x7d << 11) #define PHYCLKRST_MPLL_MULTIPLIER_19200KHZ_REF (0x02 << 11) - #define PHYCLKRST_FSEL_UTMI_MASK (0x7 << 5) #define PHYCLKRST_FSEL_PIPE_MASK (0x7 << 8) #define PHYCLKRST_FSEL(_x) ((_x) << 5) @@ -78,46 +70,68 @@ #define PHYCLKRST_FSEL_PAD_24MHZ (0x2a << 5) #define PHYCLKRST_FSEL_PAD_20MHZ (0x31 << 5) #define PHYCLKRST_FSEL_PAD_19_2MHZ (0x38 << 5) - #define PHYCLKRST_RETENABLEN BIT(4) - #define PHYCLKRST_REFCLKSEL_MASK (0x03 << 2) #define PHYCLKRST_REFCLKSEL_PAD_REFCLK (0x2 << 2) #define PHYCLKRST_REFCLKSEL_EXT_REFCLK (0x3 << 2) - #define PHYCLKRST_PORTRESETBIT(1) #define PHYCLKRST_COMMONONNBIT(0) #define EXYNOS5_DRD_PHYREG00x14 +#define PHYREG0_SSC_REF_CLK_SELBIT(21) +#define PHYREG0_SSC_RANGE BIT(20) +#define PHYREG0_CR_WRITE BIT(19) +#define PHYREG0_CR_READBIT(18) +#define PHYREG0_CR_DATA_IN(_x) ((_x) << 2) +#define PHYREG0_CR_CAP_DATABIT(1) +#define PHYREG0_CR_CAP_ADDRBIT(0) + #define EXYNOS5_DRD_PHYREG10x18 +#define PHYREG1_CR_DATA_OUT(_x)((_x) << 1) +#define PHYREG1_CR_ACK BIT(0) #define EXYNOS5_DRD_PHYPARAM0 0x1c - #define PHYPARAM0_REF_USE_PAD BIT(31) #define PHYPARAM0_REF_LOSLEVEL_MASK(0x1f << 26) #define PHYPARAM0_REF_LOSLEVEL (0x9 << 26) #define EXYNOS5_DRD_PHYPARAM1 0x20 - #define PHYPARAM1_PCS_TXDEEMPH_MASK(0x1f << 0) #define PHYPARAM1_PCS_TXDEEMPH (0x1c) #define EXYNOS5_DRD_PHYTERM0x24 #define EXYNOS5_DRD_PHYTEST0x28 - #define PHYTEST_POWERDOWN_SSP BIT(3) #define PHYTEST_POWERDOWN_HSP BIT(2) #define EXYNOS5_DRD_PHYADP 0x2c #define EXYNOS5_DRD_PHYUTMICLKSEL 0x30 - #define PHYUTMICLKSEL_UTMI_CLKSEL
[PATCH v6 1/4] phy: Add provision for calibrating phy.
Some PHY controllers may need to calibrate certain
PHY settings after initialization of the controller and
sometimes even after initializing the PHY-consumer too.
Add support for the same in order to let consumers do so in need.
Signed-off-by: vivek Gautam
---
drivers/phy/phy-core.c | 36
include/linux/phy/phy.h |8
2 files changed, 44 insertions(+)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 834b337..c8cb3de 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -393,6 +393,42 @@ int phy_power_off(struct phy *phy)
EXPORT_SYMBOL_GPL(phy_power_off);
/**
+ * phy_calibrate - calibrate a phy post initialization
+ * @phy: Pointer to 'phy' from consumer
+ *
+ * For certain PHYs, it may be needed to calibrate few phy parameters
+ * post initialization. The need to calibrate may arise after the
+ * initialization of consumer itself, in order to prevent further any
+ * loss of phy settings post consumer-initialization.
+ * example: USB 3.0 DRD PHY on Exynos5420/5800 systems is one such
+ * phy which needs calibration after the host controller reset
+ * has happened.
+ */
+int phy_calibrate(struct phy *phy)
+{
+ int ret = -ENOTSUPP;
+
+ if (!phy)
+ return 0;
+
+ mutex_lock(>mutex);
+ if (phy->ops->calibrate) {
+ ret = phy->ops->calibrate(phy);
+ if (ret < 0) {
+ dev_err(>dev,
+ "phy calibration failed --> %d\n", ret);
+ goto out;
+ }
+ }
+
+out:
+ mutex_unlock(>mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(phy_calibrate);
+
+/**
* _of_phy_get() - lookup and obtain a reference to a phy by phandle
* @np: device_node for which to get the phy
* @index: the index of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index d983051..c70a311 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -28,6 +28,7 @@ struct phy;
* @exit: operation to be performed while exiting
* @power_on: powering on the phy
* @power_off: powering off the phy
+ * @calibrate: calibrate the phy post init
* @owner: the module owner containing the ops
*/
struct phy_ops {
@@ -35,6 +36,7 @@ struct phy_ops {
int (*exit)(struct phy *phy);
int (*power_on)(struct phy *phy);
int (*power_off)(struct phy *phy);
+ int (*calibrate)(struct phy *phy);
struct module *owner;
};
@@ -126,6 +128,7 @@ int phy_init(struct phy *phy);
int phy_exit(struct phy *phy);
int phy_power_on(struct phy *phy);
int phy_power_off(struct phy *phy);
+int phy_calibrate(struct phy *phy);
static inline int phy_get_bus_width(struct phy *phy)
{
return phy->attrs.bus_width;
@@ -231,6 +234,11 @@ static inline int phy_power_off(struct phy *phy)
return -ENOSYS;
}
+static inline int phy_calibrate(struct phy *phy)
+{
+ return -ENOSYS;
+}
+
static inline int phy_get_bus_width(struct phy *phy)
{
return -ENOSYS;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v6 0/4] Fine tune USB 3.0 PHY on exynos5420
This series is based on Heikki's patches for simpliefied phy lookup table: [PATCHv3 0/6] phy: simplified phy lookup [1], applied against 'usb-next' branch alongwith Sergei's patch for adding generic phy support to usb hcd [2]. NOTE: We need to get above dependencies merged first in order to merge this series. As of now patches @ [1] are posted with all the comments addressed and we are waiting for an ACK on them, but patch @ [2] needs to be re-spined as Sergie says in [3]: "Yes, I'm planning this since Greg has lost v4." Changes since v5: - Assigned NULL to hcd->gen_phy in error path in xhci-plat.c, so that we don't need to check for IS_ERR() while calibrating the PHYs in core/hcd.c - Removed extra empty lines in register definitions in exynos5-usbdrd phy driver. - Added write access for EXYNOS5_DRD_PHYREG0 register before any crport_handshake() call as suggested by Jingoo Han. - Renamed member 'calibrate' to 'phy_exynos_calibrate' of struct exynos5_usbdrd_phy_drvdata. Changes since v4: - Rebased on latest patches by Heikki. - Took care of handling -EPROBE_DEFER error number while getting PHY in xhci plat. Changes from v3: - Modified error message as per review comments from Julius. Changes since v2: - Removed any check for DWC3 in xhci-plat for getting usb2-phy and usb3-phy, in order to make it more generic. - Moved the phy_calibration calls to core/hcd.c to enable a more generic solution for issues of calibrating the PHYs. Changes since v1: - Using 'gen_phy' member of 'hcd' instead of declaring more variables to hold phys. - Added a check for compatible match for 'Synopsys-dwc3' controller, since the 'gen_phy' member of 'hcd' already gets the 'usb' PHY in core/hcd.c; but XHCI on Synopsys-dwc3 doesn't need that, instead two separate PHYs for UTMI+ and PIPE3 for the two HCDs (main hcd and shared hcd). - Restructured the code in 'xhci_plat_setup()' and 'xhci_plat_resume()' to use hcd->gen_phy directly. Also added the check for Synopsys's DWC3 controller while trying to calibrate the PHY. Explanation for the need of this patch-series: "The DWC3-exynos eXtensible host controller present on Exynos5420/5800 SoCs is quirky. The PHY serving this controller operates at High-Speed by default, so it detects even Super-speed devices as high-speed ones. Certain PHY parameters like Tx LOS levels and Boost levels need to be calibrated further post initialization of xHCI controller, to get SuperSpeed operations working." [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg710094.html [2] http://comments.gmane.org/gmane.linux.ports.sh.devel/35932 [3] http://www.spinics.net/lists/linux-usb/msg112300.html Vivek Gautam (4): phy: Add provision for calibrating phy. usb: host: xhci-plat: Get PHYs for xhci's hcds usb: hcd: Calibrate PHY post hcd reset phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800 drivers/phy/phy-core.c | 36 drivers/phy/phy-exynos5-usbdrd.c | 185 ++ drivers/usb/core/hcd.c | 18 drivers/usb/host/xhci-plat.c | 27 ++ include/linux/phy/phy.h |8 ++ 5 files changed, 259 insertions(+), 15 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/4] ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code.
On 09/02/2014 12:26 PM, Xiubo Li wrote:
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 61 -
1 file changed, 29 insertions(+), 32 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 986d2c7..cad2b30 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -163,6 +163,26 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
return 0;
}
+static inline unsigned int
+asoc_simple_card_fmt_master(struct device_node *np,
+ struct device_node *bitclkmaster,
+ struct device_node *framemaster)
+{
+ switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
+ case 0x11:
+ return SND_SOC_DAIFMT_CBS_CFS;
+ case 0x10:
+ return SND_SOC_DAIFMT_CBS_CFM;
+ case 0x01:
+ return SND_SOC_DAIFMT_CBM_CFS;
+ default:
+ return SND_SOC_DAIFMT_CBM_CFM;
+ }
+
+ /* Shouldn't be here */
+ return -EINVAL;
+}
+
+ fmt = asoc_simple_card_fmt_master(np, bitclkmaster, framemaster);
+ dai_props->cpu_dai.fmt = daifmt | fmt;
...
+ fmt = asoc_simple_card_fmt_master(np, bitclkmaster,
+ framemaster);
+ dai_props->codec_dai.fmt = daifmt | fmt;
This won't work. The logic for cpu node needs to be negated for codec node.
Best regards,
Jyri
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: unisys: uislib: uisqueue.c: fixed sparse warning of context imbalance
fixed sparse warning : context imbalance in 'do_locked_client_insert' different lock contexts for basic block spin_unlock_irqrestore is called at a later stage before returning from the function if locked is 1. Signed-off-by: Sudip Mukherjee --- drivers/staging/unisys/uislib/uisqueue.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/unisys/uislib/uisqueue.c b/drivers/staging/unisys/uislib/uisqueue.c index f52bca1..63dbe7c 100644 --- a/drivers/staging/unisys/uislib/uisqueue.c +++ b/drivers/staging/unisys/uislib/uisqueue.c @@ -96,8 +96,6 @@ do_locked_client_insert(struct uisqueue_info *queueinfo, goto Away; ULTRA_CHANNEL_CLIENT_RELEASE_OS(queueinfo->chan, channelId, NULL); acquired = 0; - spin_unlock_irqrestore(lock, flags); - locked = 0; queueinfo->packets_sent++; -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: rk808: Fix n_voltages for DCDC4
On Tue, Sep 02, 2014 at 08:47:31AM +0800, Axel Lin wrote: > The min_sel is 0, max_sel is 15, so n_voltages should be 16. Applied, thanks. signature.asc Description: Digital signature
Re: [PATCHv2 1/4] ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code.
On Tue, 02 Sep 2014 16:12:40 +0530
Varka Bhadram wrote:
> >>> + switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
> >>> + case 0x11:
> >>> + return SND_SOC_DAIFMT_CBS_CFS;
> >>> + case 0x10:
> >>> + return SND_SOC_DAIFMT_CBS_CFM;
> >>> + case 0x01:
> >>> + return SND_SOC_DAIFMT_CBM_CFS;
> >>> + default:
> >>> + return SND_SOC_DAIFMT_CBM_CFM;
> >>> + }
> >>> +
> >>> + /* Shouldn't be here */
> >>> + return -EINVAL;
> >>> +}
> >> It will be nice if we declare the switch case numbers as macros (specific
> >> name)...
> > I don't see which macros: the values are just 2 booleans.
> >
> I am talking about 0x11, 0x10, 0x01 values.. We can give any understandable
> names to those...?
#define TRUE_TRUE 0x11
#define TRUE_FALSE 0x10
#define FALSE_TRUE 0x01
or
case ((TRUE << 4) | TRUE:
...
case ((TRUE << 4) | FALSE:
...
case ((FALSE << 4) | TRUE:
...
??
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 4/4] ftracetest: Add XFAIL/XPASS and POSIX.3 std. result codes
Add XFAIL, XPASS and POSIX 1003.3 std. codes (UNRESOLVED/
UNTESTED/UNSUPPORTED) as a result code. These are
used for the results that test case is expected to fail or
unsupported feature (by config).
This also introduces PASS/FAIL/XFAIL/XPASS/UNSUP/UNTST/UNRES
result codes for each testcase. Since the results are not
binary, each testcase must use these codes to return the
test result.
Changes in v3:
- Add UNRESOLVED/UNTESTED codes.
- Fix to handle undefined codes.
- Add a document about return codes.
- Fix to show failure logs.
- Don't use -e option for echo since dash doesn't support it.
Signed-off-by: Masami Hiramatsu
---
tools/testing/ftrace/README| 33 +++
tools/testing/ftrace/ftracetest| 95 +---
tools/testing/ftrace/test.d/basic1.tc |6 +
tools/testing/ftrace/test.d/basic2.tc |6 +
tools/testing/ftrace/test.d/basic3.tc |9 +-
.../testing/ftrace/test.d/kprobe/add_and_remove.tc | 15 ++-
tools/testing/ftrace/test.d/kprobe/busy_check.tc | 20 ++--
tools/testing/ftrace/test.d/template |8 +-
8 files changed, 152 insertions(+), 40 deletions(-)
diff --git a/tools/testing/ftrace/README b/tools/testing/ftrace/README
index 5d5de16..758c0c6 100644
--- a/tools/testing/ftrace/README
+++ b/tools/testing/ftrace/README
@@ -37,6 +37,39 @@ and rewrite test description line.
* The test cases should run on dash (busybox shell) for testing on
minimal cross-build environments.
+ * The test cases must return one of result codes described below.
+
+Return codes
+
+
+Ftracetest supports following return codes, which are defined as shell
+variables (do not overwrite them.)
+
+ * PASS: The test succeeded as expected.
+
+ * FAIL: The test failed, but was expected to succeed.
+
+ * UNRESOLVED: The test produced unclear or intermidiate results.
+ for example, the test was interrupted
+ or the test depends on a previous test, which failed.
+ or the test was set up incorrectly
+
+ * UNTESTED: The test was not run, currently just a placeholder.
+
+ * UNSUPPORTED: The test failed because of lack of feature.
+
+ * XFAIL: The test failed, and was expected to fail.
+
+ * XPASS: The test succeeded, but was expected to fail.
+
+Below shortened valiables are also available.
+
+ * UNRES: means UNRESOLVED.
+
+ * UNTST: means UNTESTED.
+
+ * UNSUP: means UNSUPPORTED.
+
TODO
diff --git a/tools/testing/ftrace/ftracetest b/tools/testing/ftrace/ftracetest
index 8d92e74..3db77c5 100755
--- a/tools/testing/ftrace/ftracetest
+++ b/tools/testing/ftrace/ftracetest
@@ -107,22 +107,79 @@ catlog() { #file
}
# Testcase management
+# Test result codes - Dejagnu extended code
+PASS=0 # The test succeeded.
+FAIL=1 # The test failed, but was expected to succeed.
+UNRESOLVED=2 # The test produced indeterminate results. (e.g. interrupted)
+UNTESTED=3# The test was not run, currently just a placeholder.
+UNSUPPORTED=4 # The test failed because of lack of feature.
+XFAIL=5# The test failed, and was expected to fail.
+XPASS=6# The test succeeded, but was expected to fail.
+# Shortened codes
+UNRES=$UNRESOLVED
+UNTST=$UNTESTED
+UNSUP=$UNSUPPORTED
+
+# Accumulations
PASSED_CASES=
FAILED_CASES=
+UNRESOLVED_CASES=
+UNTESTED_CASES=
+UNSUPPORTED_CASES=
+XFAILED_CASES=
+XPASSED_CASES=
+UNDEFINED_CASES=
+
CASENO=0
testcase() { # testfile
CASENO=$((CASENO+1))
prlog -n "[$CASENO]"`grep "^#[ \t]*description:" $1 | cut -f2 -d:`
}
-failed() {
- prlog " [FAIL]"
- FAILED_CASES="$FAILED_CASES $CASENO"
-}
-passed() {
- prlog " [PASS]"
- PASSED_CASES="$PASSED_CASES $CASENO"
-}
+eval_result() { # retval
+ case $1 in
+$PASS)
+ prlog " [PASS]"
+ PASSED_CASES="$PASSED_CASES $CASENO"
+ return 0
+;;
+$FAIL)
+ prlog " [FAIL]"
+ FAILED_CASES="$FAILED_CASES $CASENO"
+ return 1 # this is a bug.
+;;
+$UNRESOLVED)
+ prlog " [UNRESOLVED]"
+ UNRESOLVED_CASES="$UNRESOLVED_CASES $CASENO"
+ return 1 # this is a kind of bug.. something happened.
+;;
+$UNTESTED)
+ prlog " [UNTESTED]"
+ UNTESTED_CASES="$UNTESTED_CASES $CASENO"
+ return 0
+;;
+$UNSUPPORTED)
+ prlog " [UNSUPPORTED]"
+ UNSUPPORTED_CASES="$UNSUPPORTED_CASES $CASENO"
+ return 0 # this is not a bug
+;;
+$XFAIL)
+ prlog " [XFAIL]"
+ XFAILED_CASES="$XFAILED_CASES $CASENO"
+ return 0
+;;
+$XPASS)
+ prlog " [XPASS]"
+ XPASSED_CASES="$XPASSED_CASES $CASENO"
+ return 1 # this can be a bug
+;;
+*)
+ prlog " [UNDEFINED]"
+ UNDEFINED_CASES="$UNDEFINED_CASES $CASENO"
+ return 1 # this must be a test bug
+;;
+ esac
+}
# Run one test case
run_test() { # testfile
@@ -132,12 +189,12 @@ run_test() { # testfile
echo "execute: "$1 > $testlog
(cd $TRACING_DIR; set -x ; .
[RFC PATCH v3 1/4] ftracetest: Initial commit for ftracetest
ftracetest is a collection of testcase shell-scripts for ftrace.
To avoid regressions of ftrace, these testcases check correct
ftrace behaviors. If someone would like to add any features on
ftrace, the patch series should have at least one testcase for
checking the new behavior.
Changes in v3:
- Use "." instead of "source".
- Don't use -e option for echo since dash doesn't support it.
Changes in v2:
- Remove unneeded 'function' keyword.
- Add abspath and find_testcases.
- Make OPT_TEST_CASES a local var.
- Ensure given testcase ended with .tc.
- Accept a directory option which has multiple testcases.
- Change [PASSED]/[FAILED] to [PASS]/[FAIL]
- Change the basic shell to sh (dash).
Signed-off-by: Masami Hiramatsu
---
tools/testing/ftrace/README | 45 ++
tools/testing/ftrace/ftracetest | 152 ++
tools/testing/ftrace/test.d/template |4 +
3 files changed, 201 insertions(+)
create mode 100644 tools/testing/ftrace/README
create mode 100755 tools/testing/ftrace/ftracetest
create mode 100644 tools/testing/ftrace/test.d/template
diff --git a/tools/testing/ftrace/README b/tools/testing/ftrace/README
new file mode 100644
index 000..5d5de16
--- /dev/null
+++ b/tools/testing/ftrace/README
@@ -0,0 +1,45 @@
+Linux Ftrace Testcases
+
+This is a collection of testcases for ftrace tracing feature in the Linux
+kernel. Since ftrace exports interfaces via the debugfs, we just need
+shell scripts for testing. Feel free to add new test cases.
+
+Running the ftrace testcases
+
+
+At first, you need to be the root user to run this script.
+To run all testcases:
+
+ $ sudo ./ftracetest
+
+To run specific testcases:
+
+ # ./ftracetest test.d/basic3.tc
+
+Or you can also run testcases under given directory:
+
+ # ./ftracetest test.d/kprobe/
+
+Contributing new testcases
+==
+
+Copy test.d/template to your testcase (whose filename must has *.tc extension)
+and rewrite test description line.
+
+ * The working directory of the script is /tracing/.
+
+ * Take care about the side effect, because that is run with root privilege.
+
+ * Don't take too long. It's a kind of unit test.
+
+ * You can add a directory for your testcases under test.d/ if needed.
+
+ * The test cases should run on dash (busybox shell) for testing on
+ minimal cross-build environments.
+
+TODO
+
+
+ * Fancy colored output :)
+
+ * Integrate with selftest?
diff --git a/tools/testing/ftrace/ftracetest b/tools/testing/ftrace/ftracetest
new file mode 100755
index 000..8d92e74
--- /dev/null
+++ b/tools/testing/ftrace/ftracetest
@@ -0,0 +1,152 @@
+#!/bin/sh
+# ftracetest - Ftrace test shell scripts
+# Written by Masami Hiramatsu
+
+usage() { # errno [message]
+[ "$2" ] && echo $2
+echo "Usage: ftracetest [options] [testcase(s)] [testcase-directory(s)]"
+echo " Options:"
+echo " -h|--help Show help message"
+echo " -k|--keep Keep passed test logs"
+echo " -d|--debug Debug mode (trace all shell commands)"
+exit $1
+}
+
+errexit() { # message
+ echo "Error: $1" 1>&2
+ exit 1
+}
+
+# Ensuring user privilege
+if [ `id -u` -ne 0 ]; then
+ errexit "this must be run by root user"
+fi
+
+# Utilities
+absdir() { # file_path
+ (cd `dirname $1`; pwd)
+}
+
+abspath() {
+ echo `absdir $1`/`basename $1`
+}
+
+find_testcases() { #directory
+ echo `find $1 -name \*.tc`
+}
+
+parse_opts() { # opts
+ local OPT_TEST_CASES=
+ local OPT_TEST_DIR=
+
+ while [ "$1" ]; do
+case "$1" in
+--help|-h)
+ usage 0
+;;
+--keep|-k)
+ KEEP_LOG=1
+ shift 1
+;;
+--debug|-d)
+ DEBUG=1
+ shift 1
+;;
+*.tc)
+ if [ -f "$1" ]; then
+OPT_TEST_CASES="$OPT_TEST_CASES `abspath $1`"
+shift 1
+ else
+usage 1 "$1 is not a testcase"
+ fi
+ ;;
+*)
+ if [ -d "$1" ]; then
+OPT_TEST_DIR=`abspath $1`
+OPT_TEST_CASES="$OPT_TEST_CASES `find_testcases $OPT_TEST_DIR`"
+shift 1
+ else
+usage 1 "Invalid option ($1)"
+ fi
+;;
+esac
+ done
+ if [ "$OPT_TEST_CASES" ]; then
+TEST_CASES=$OPT_TEST_CASES
+ fi
+}
+
+# Parameters
+DEBUGFS_DIR=`grep debugfs /proc/mounts | cut -f2 -d' '`
+TRACING_DIR=$DEBUGFS_DIR/tracing
+TOP_DIR=`absdir $0`
+TEST_DIR=$TOP_DIR/test.d
+TEST_CASES=`find_testcases $TEST_DIR`
+LOG_DIR=$TOP_DIR/logs/`date +%Y%m%d-%H%M%S`/
+KEEP_LOG=0
+DEBUG=0
+# Parse command-line options
+parse_opts $*
+
+[ $DEBUG -ne 0 ] && set -x
+
+# Verify parameters
+if [ -z "$DEBUGFS_DIR" -o ! -d "$TRACING_DIR" ]; then
+ errexit "No ftrace directory found"
+fi
+
+# Preparing logs
+LOG_FILE=$LOG_DIR/ftracetest.log
+mkdir -p $LOG_DIR || errexit "Failed to make a log directory: $LOG_DIR"
+date > $LOG_FILE
+prlog() { # messages
+ echo "$@" | tee -a $LOG_FILE
+}
+catlog() { #file
+ cat $1 | tee -a $LOG_FILE
+}
+
+# Testcase management
+PASSED_CASES=
+FAILED_CASES=
+CASENO=0
+testcase() { #
[RFC PATCH v3 2/4] ftracetest: Add ftrace basic testcases
Add ftrace basic testcases. This just checks ftrace debugfs interface works as it is designed. Changes in v2: - Change shell to sh instead of bash. Signed-off-by: Masami Hiramatsu --- tools/testing/ftrace/test.d/basic1.tc |3 +++ tools/testing/ftrace/test.d/basic2.tc |6 ++ tools/testing/ftrace/test.d/basic3.tc |8 3 files changed, 17 insertions(+) create mode 100644 tools/testing/ftrace/test.d/basic1.tc create mode 100644 tools/testing/ftrace/test.d/basic2.tc create mode 100644 tools/testing/ftrace/test.d/basic3.tc diff --git a/tools/testing/ftrace/test.d/basic1.tc b/tools/testing/ftrace/test.d/basic1.tc new file mode 100644 index 000..9980ff1 --- /dev/null +++ b/tools/testing/ftrace/test.d/basic1.tc @@ -0,0 +1,3 @@ +#!/bin/sh +# description: Basic trace file check +test -f README -a -f trace -a -f tracing_on -a -f trace_pipe diff --git a/tools/testing/ftrace/test.d/basic2.tc b/tools/testing/ftrace/test.d/basic2.tc new file mode 100644 index 000..b04f30d --- /dev/null +++ b/tools/testing/ftrace/test.d/basic2.tc @@ -0,0 +1,6 @@ +#!/bin/sh +# description: Basic test for tracers +for t in `cat available_tracers`; do + echo $t > current_tracer || exit 1 +done +echo nop > current_tracer diff --git a/tools/testing/ftrace/test.d/basic3.tc b/tools/testing/ftrace/test.d/basic3.tc new file mode 100644 index 000..0c1a3a2 --- /dev/null +++ b/tools/testing/ftrace/test.d/basic3.tc @@ -0,0 +1,8 @@ +#!/bin/sh +# description: Basic trace clock test +[ -f trace_clock ] || exit 1 +for c in `cat trace_clock | tr -d \[\]`; do + echo $c > trace_clock || exit 1 + grep '\['$c'\]' trace_clock || exit 1 +done +echo local > trace_clock -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 3/4] ftracetest: Add kprobe basic testcases
Add basic testcases for kprobe dynamic events. This also shows that the ftracetest accepts sub-directory for new testcases. Changes in v2: - Change shell to sh instead of bash. Signed-off-by: Masami Hiramatsu --- .../testing/ftrace/test.d/kprobe/add_and_remove.tc | 11 +++ tools/testing/ftrace/test.d/kprobe/busy_check.tc | 14 ++ 2 files changed, 25 insertions(+) create mode 100644 tools/testing/ftrace/test.d/kprobe/add_and_remove.tc create mode 100644 tools/testing/ftrace/test.d/kprobe/busy_check.tc diff --git a/tools/testing/ftrace/test.d/kprobe/add_and_remove.tc b/tools/testing/ftrace/test.d/kprobe/add_and_remove.tc new file mode 100644 index 000..5ddfb47 --- /dev/null +++ b/tools/testing/ftrace/test.d/kprobe/add_and_remove.tc @@ -0,0 +1,11 @@ +#!/bin/sh +# description: Kprobe dynamic event - adding and removing + +[ -f kprobe_events ] || exit 1 + +echo 0 > events/enable || exit 1 +echo > kprobe_events || exit 1 +echo p:myevent do_fork > kprobe_events || exit 1 +grep myevent kprobe_events || exit 1 +[ -d events/kprobes/myevent ] || exit 1 +echo > kprobe_events diff --git a/tools/testing/ftrace/test.d/kprobe/busy_check.tc b/tools/testing/ftrace/test.d/kprobe/busy_check.tc new file mode 100644 index 000..588fde97 --- /dev/null +++ b/tools/testing/ftrace/test.d/kprobe/busy_check.tc @@ -0,0 +1,14 @@ +#!/bin/sh +# description: Kprobe dynamic event - busy event check + +[ -f kprobe_events ] || exit 1 + +echo 0 > events/enable || exit 1 +echo > kprobe_events || exit 1 +echo p:myevent do_fork > kprobe_events || exit 1 +[ -d events/kprobes/myevent ] || exit 1 +echo 1 > events/kprobes/myevent/enable || exit 1 +echo > kprobe_events && exit 1 # this must fail +echo 0 > events/kprobes/myevent/enable || exit 1 +echo > kprobe_events # this must succeed + -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH v3 0/4] ftrace: Add a ftrace test collection
Hi, Here is the collection of testcases for ftrace version 3. This is just some updates and fixes according to the discussion at previous version. https://lkml.org/lkml/2014/8/26/304 The major updates are: - Fix some expressions to work on dash (Thanks Luis!) - Support UNRESOLVED/UNTESTED/UNSUPPORTED results for testcase. Those are POSIX 1003.3 standard. (see http://www.gnu.org/software/dejagnu/manual/x47.html for more details) - Fix to show error logs. ftracetest is a small dash script for testing ftrace features. It will be required to add a unit test for each new feature after this is merged, because of preventing feature regressions. This version still be out of the selftest. However, at the kernel summit, I talked with Shuah about that. And since the kselftest will be the standard kernel unit test framework, I agreed to move this under the selftest. But I also would like to ask Steven and Namhyung to agree with it before moving. Actually, since we've already has similar shell-script base testcase under kselftest, we can easily move this under selftests. Thank you, --- Masami Hiramatsu (4): ftracetest: Initial commit for ftracetest ftracetest: Add ftrace basic testcases ftracetest: Add kprobe basic testcases ftracetest: Add XFAIL/XPASS and POSIX.3 std. result codes tools/testing/ftrace/README| 78 +++ tools/testing/ftrace/ftracetest| 217 tools/testing/ftrace/test.d/basic1.tc |7 + tools/testing/ftrace/test.d/basic2.tc |8 + tools/testing/ftrace/test.d/basic3.tc |9 + .../testing/ftrace/test.d/kprobe/add_and_remove.tc | 12 + tools/testing/ftrace/test.d/kprobe/busy_check.tc | 14 + tools/testing/ftrace/test.d/template | 10 + 8 files changed, 355 insertions(+) create mode 100644 tools/testing/ftrace/README create mode 100755 tools/testing/ftrace/ftracetest create mode 100644 tools/testing/ftrace/test.d/basic1.tc create mode 100644 tools/testing/ftrace/test.d/basic2.tc create mode 100644 tools/testing/ftrace/test.d/basic3.tc create mode 100644 tools/testing/ftrace/test.d/kprobe/add_and_remove.tc create mode 100644 tools/testing/ftrace/test.d/kprobe/busy_check.tc create mode 100644 tools/testing/ftrace/test.d/template -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] i915: failure to see Dell 30" monitor connected to a Lenovo Haswell docking station
On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote: > On 2 September 2014 14:05, Theodore Ts'o wrote: > > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no > > longer see the my Dell 30" monitor when it is connected via the > > docking station using a Displayport connector. This worked using 3.16 > > kernel. > > > > If I connect to the monitor using the mini-display, by passing the > > docking station, things work fine (but of course it's annoying not to > > be able to use the docking station). > > > > Is this a known problem? This is not the first time that we've had > > regressions with this docking station. It's vaguely reminsicent of > > > > https://bugs.freedesktop.org/show_bug.cgi?id=71267 > > > > Except the system isn't hanging; it's just not seeing the monitor at all. > > Have you the Dell 30" set to Displayport 1.2 enabled mode? No, it DP 1.2 was disabled. If I enable it, it breaks things when I try connecting via the MiniDP port (bypassing the dock), and it is still broken when I try to talk via the DisplayPort in the dock. If I disable DP 1.2 again, it works via the MiniDP port, but if I try to connect through the dock (which has a DP Hub which I believe is MST/DP 1.2 capable), it is still broken. It does seem that this might be related to 3.17-rc3 trying to talk DP 1.2 if it is available, since I can't control what the DP hub in the docking station advertises --- is there a commit or some kind of hack I can try to force talking to the DP hub using DP 1.1? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/4] ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code.
At Tue, 02 Sep 2014 16:12:40 +0530,
Varka Bhadram wrote:
>
> On 09/02/2014 04:08 PM, Jean-Francois Moine wrote:
> > On Tue, 02 Sep 2014 15:51:41 +0530
> > Varka Bhadram wrote:
> >
> >>> + switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
> >>> + case 0x11:
> >>> + return SND_SOC_DAIFMT_CBS_CFS;
> >>> + case 0x10:
> >>> + return SND_SOC_DAIFMT_CBS_CFM;
> >>> + case 0x01:
> >>> + return SND_SOC_DAIFMT_CBM_CFS;
> >>> + default:
> >>> + return SND_SOC_DAIFMT_CBM_CFM;
> >>> + }
> >>> +
> >>> + /* Shouldn't be here */
> >>> + return -EINVAL;
> >>> +}
> >> It will be nice if we declare the switch case numbers as macros (specific
> >> name)...
> > I don't see which macros: the values are just 2 booleans.
> >
> I am talking about 0x11, 0x10, 0x01 values.. We can give any understandable
> names to those...?
The whole switch block is too hackish, makes unnecessarily complex.
It can be more strightforwardly like:
if (np == bitclkmaster)
return np == framemater ?
SND_SOC_DAIFMT_CBS_CFS : SND_SOC_DAIFMT_CBS_CFM;
else
return np == framemaster ?
SND_SOC_DAIFMT_CBM_CFS : SND_SOC_DAIFMT_CBM_CFM;
Or, if you love efficiency and complexity, something like:
#define SND_SOC_DAIFMT(_np, _clk, _frame) \
_np) != (_clk)) | (((_np) != (_frame)) << 1) << 12) + (1 << 12)
Then
return SND_SOC_DAIFMT(np, blkclkmaster, framemaster);
Takashi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 03/19] arm: fiq: Replace default FIQ handler
On 28/08/14 17:15, Paul E. McKenney wrote:
> On Thu, Aug 28, 2014 at 04:54:25PM +0100, Daniel Thompson wrote:
>> On 28/08/14 16:01, Russell King - ARM Linux wrote:
>>> On Tue, Aug 19, 2014 at 07:12:07PM +0100, Daniel Thompson wrote:
On 19/08/14 18:37, Russell King - ARM Linux wrote:
> On Tue, Aug 19, 2014 at 05:45:53PM +0100, Daniel Thompson wrote:
>> +int register_fiq_nmi_notifier(struct notifier_block *nb)
>> +{
>> +return atomic_notifier_chain_register(_nmi_chain, nb);
>> +}
>> +
>> +asmlinkage void __exception_irq_entry fiq_nmi_handler(struct pt_regs
>> *regs)
>> +{
>> +struct pt_regs *old_regs = set_irq_regs(regs);
>> +
>> +nmi_enter();
>> +atomic_notifier_call_chain(_nmi_chain, (unsigned long)regs,
>> NULL);
>> +nmi_exit();
>> +set_irq_regs(old_regs);
>> +}
>
> Really not happy with this. What happens if a FIQ occurs while we're
> inside register_fiq_nmi_notifier() - more specifically inside
> atomic_notifier_chain_register() ?
Should depend on which side of the rcu update we're on.
>>>
>>> I just asked Paul McKenney, our RCU expert... essentially, yes, RCU
>>> stuff itself is safe in this context. However, RCU stuff can call into
>>> lockdep if lockdep is configured, and there are questions over lockdep.
>>
>> Thanks for following this up.
>>
>> I originally formed the opinion RCU was safe from FIQ because it is also
>> used to manage the NMI notification handlers for x86
>> (register_nmi_handler) and I understood the runtime constraints on FIQ
>> to be very similar.
>>
>> Note that x86 manages the notifiers itself so it uses
>> list_for_each_entry_rcu() rather atomic_notifier_call_chain() but
>> nevertheless I think this boils down to the same thing w.r.t. safety
>> concerns.
>>
>>
>>> There's some things which can be done to reduce the lockdep exposure
>>> to it, such as ensuring that rcu_read_lock() is first called outside
>>> of FIQ context.
>>
>> lockdep is automatically disabled by calling nmi_enter() so all the
>> lockdep calls should end up following the early exit path based on
>> current->lockdep_recursion.
>
> Ah, that was what I was missing. Then the notification should be
> safe from NMI, so have at it! ;-)
>
> Thanx, Paul
>
>>> There's concerns with whether either printk() in check_flags() could
>>> be reached too (flags there should always indicate that IRQs were
>>> disabled, so that reduces down to a question about just the first
>>> printk() there.)
>>>
>>> There's also the very_verbose() stuff for RCU lockdep classes which
>>> Paul says must not be enabled.
>>>
>>> Lastly, Paul isn't a lockdep expert, but he sees nothing that prevents
>>> lockdep doing the deadlock checking as a result of the above call.
>>>
>>> So... this coupled with my feeling that notifiers make it too easy for
>>> unreviewed code to be hooked into this path, I'm fairly sure that we
>>> don't want to be calling atomic notifier chains from FIQ context.
Having esablished (above) that RCU usage is safe from FIQ I have been
working on the assumption that your feeling regarding unreviewed code
is sufficient on its own to avoid using notifiers (and also to avoid
a list of function pointers like on x86).
Therefore I have made these changes I've produced a before/after patch
to show the impact of this. I will merge this into the FIQ patchset
shortly.
Personally I still favour using notifiers and think the coupling below is
excessive. Nevertheless I've run a couple of basic tests on the code
below and it works fine.
diff --git a/arch/arm/include/asm/fiq.h b/arch/arm/include/asm/fiq.h
index 175bfed..a25c952 100644
--- a/arch/arm/include/asm/fiq.h
+++ b/arch/arm/include/asm/fiq.h
@@ -54,7 +54,6 @@ extern void disable_fiq(int fiq);
extern int ack_fiq(int fiq);
extern void eoi_fiq(int fiq);
extern bool has_fiq(int fiq);
-extern int register_fiq_nmi_notifier(struct notifier_block *nb);
extern void fiq_register_mapping(int irq, struct fiq_chip *chip);
/* helpers defined in fiqasm.S: */
diff --git a/arch/arm/include/asm/kgdb.h b/arch/arm/include/asm/kgdb.h
index 6563da0..cb5ccd6 100644
--- a/arch/arm/include/asm/kgdb.h
+++ b/arch/arm/include/asm/kgdb.h
@@ -51,6 +51,7 @@ extern void kgdb_handle_bus_error(void);
extern int kgdb_fault_expected;
extern int kgdb_register_fiq(unsigned int fiq);
+extern void kgdb_handle_fiq(struct pt_regs *regs);
#endif /* !__ASSEMBLY__ */
diff --git a/arch/arm/kernel/fiq.c b/arch/arm/kernel/fiq.c
index b2bd1c7..7422b58 100644
--- a/arch/arm/kernel/fiq.c
+++ b/arch/arm/kernel/fiq.c
@@ -43,12 +43,14 @@
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#define FIQ_OFFSET ({ \
@@ -65,7 +67,6 @@ static unsigned long no_fiq_insn;
static int fiq_start = -1;
static
Re: [Xen-devel] [PATCH] x86/xen: Fix 64bit kernel pagetable setup of PV guests
On 01/09/14 18:34, David Vrabel wrote: > On 29/08/14 16:17, Stefan Bader wrote: >> >> This change might not be the fully correct approach as it basically >> removes the pre-set page table entry for the fixmap that is compile >> time set (level2_fixmap_pgt[506]->level1_fixmap_pgt). For one the >> level1 page table is not yet declared in C headers (that might be >> fixed). But also with the current bug, it was removed, too. Since >> the Xen mappings for level2_kernel_pgt only covered kernel + initrd >> and some Xen data this did never reach that far. And still, something >> does create entries at level2_fixmap_pgt[506..507]. So it should be >> ok. At least I was able to successfully boot a kernel with 1G kernel >> image size without any vmalloc whinings. > [...] >> --- a/arch/x86/xen/mmu.c >> +++ b/arch/x86/xen/mmu.c >> @@ -1902,8 +1902,22 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, >> unsigned long max_pfn) >> /* L3_i[0] -> level2_ident_pgt */ >> convert_pfn_mfn(level3_ident_pgt); >> /* L3_k[510] -> level2_kernel_pgt >> - * L3_i[511] -> level2_fixmap_pgt */ >> + * L3_k[511] -> level2_fixmap_pgt */ >> convert_pfn_mfn(level3_kernel_pgt); >> + >> +/* level2_fixmap_pgt contains a single entry for the >> + * fixmap area at offset 506. The correct way would >> + * be to convert level2_fixmap_pgt to mfn and set the >> + * level1_fixmap_pgt (which is completely empty) to RO, >> + * too. But currently this page table is not declared, >> + * so it would be a bit of voodoo to get its address. >> + * And also the fixmap entry was never set due to using >> + * the wrong l2 when getting Xen's tables. So let's just >> + * just nuke it. >> + * This orphans level1_fixmap_pgt, but that was basically >> + * done before the change as well. >> + */ >> +memset(level2_fixmap_pgt, 0, 512*sizeof(long)); > > level2_fixmap_pgt etc. are defined for the benefit of Xen only so I > think you should add an extern for level1_fixmap_pgt and fix this up > properly. > > It might not matter now, but it might in the future... I found some time to look into this and test it. Including without enabling KSLAR, but reproing the vmalloc failure with a large (800 MiB module). I've clarified the change description, can you review my edits? Thanks for investigating and fixing this! David 8<-- x86/xen: don't copy junk into kernel page tables When RANDOMIZE_BASE (KASLR) is enabled; or the sum of all loaded modules exceeds 512 MiB, then loading modules fails with a warning (and hence a vmalloc allocation failure) because the PTEs for the newly-allocated vmalloc address space are not zero. WARNING: CPU: 0 PID: 494 at linux/mm/vmalloc.c:128 vmap_page_range_noflush+0x2a1/0x360() This is caused by xen_setup_kernel_pagetables() copying junk into the page tables (to level2_fixmap_pgt), overwriting many non-present entries. Without KASLR, the normal kernel image size only covers the first half of level2_kernel_pgt and module space starts after that. L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[ 0..255]->kernel [256..511]->module [511]->level2_fixmap_pgt[ 0..505]->module This allows 512 MiB of of module vmalloc space to be used before having to use the corrupted level2_fixmap_pgt entries. With KASLR enabled, the kernel image uses the full PUD range of 1G and module space starts in the level2_fixmap_pgt. So basically: L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[0..511]->kernel [511]->level2_fixmap_pgt[0..505]->module And now no module vmalloc space can be used without using the corrupt level2_fixmap_pgt entries. Fix this by properly converting the level2_fixmap_pgt entries to MFNs, and setting level1_fixmap_pgt as read-only. Signed-off-by: Stefan Bader Cc: sta...@vger.kernel.org Signed-off-by: David Vrabel --- arch/x86/include/asm/pgtable_64.h |1 + arch/x86/xen/mmu.c| 27 --- 2 files changed, 13 insertions(+), 15 deletions(-) diff --git a/arch/x86/include/asm/pgtable_64.h b/arch/x86/include/asm/pgtable_64.h index 5be9063..3874693 100644 --- a/arch/x86/include/asm/pgtable_64.h +++ b/arch/x86/include/asm/pgtable_64.h @@ -19,6 +19,7 @@ extern pud_t level3_ident_pgt[512]; extern pmd_t level2_kernel_pgt[512]; extern pmd_t level2_fixmap_pgt[512]; extern pmd_t level2_ident_pgt[512]; +extern pte_t level1_fixmap_pgt[512]; extern pgd_t init_level4_pgt[]; #define swapper_pg_dir init_level4_pgt diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c index e8a1201..16fb009 100644 --- a/arch/x86/xen/mmu.c +++ b/arch/x86/xen/mmu.c @@ -1866,12 +1866,11 @@ static void __init check_pt_base(unsigned long *pt_base,
Re: [PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
On Tue, Sep 02, 2014 at 11:39:08AM +0100, Vivek Gautam wrote:
> Hi,
>
>
> On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland wrote:
> > On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
> >> Exynos7 also has a separate special gate clock going to the IP
> >> apart from the usual AHB clock. So add support for the same.
> >>
> >> Signed-off-by: Vivek Gautam
> >> ---
> >> drivers/usb/dwc3/dwc3-exynos.c | 16
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/drivers/usb/dwc3/dwc3-exynos.c
> >> b/drivers/usb/dwc3/dwc3-exynos.c
> >> index f9fb8ad..bab6395 100644
> >> --- a/drivers/usb/dwc3/dwc3-exynos.c
> >> +++ b/drivers/usb/dwc3/dwc3-exynos.c
> >> @@ -35,6 +35,7 @@ struct dwc3_exynos {
> >> struct device *dev;
> >>
> >> struct clk *clk;
> >> + struct clk *sclk;
> >> struct regulator*vdd33;
> >> struct regulator*vdd10;
> >> };
> >> @@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
> >> *pdev)
> >> return -EINVAL;
> >> }
> >>
> >> + /* Exynos7 has a special gate clock going to this IP */
> >> + exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk");
> >> + if (IS_ERR(exynos->sclk))
> >> + dev_warn(dev, "couldn't get sclk\n");
> >
> > Doesn't this introduce a pointless warning for Exynos SoCs other than
> > Exynos7?
>
> True, it will introduce an unnecessary warning for non-Exynos7 systems.
> I initially thought of introducing a compatible check for Exynos7-dwc3, but
> that
> way we may end up adding such checks for future SoCs which have similar
> controller but have some clock difference or some other small change, no ?
Perhaps. I don't know what your future hardware will look like.
Is the usbdrd30_sclk input unique to Exynos7, or was it previously there
but just without an input?
If the latter you could just reduce this to:
dev_info(dev, "no sclk specified");
Mark.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] cgroup: check cgroup liveliness before unbreaking kernfs protection
When cgroup_kn_lock_live() is called through some kernfs operation and
another thread is calling cgroup_rmdir(), we may trigger the warning in
cgroup_get().
[ cut here ]
WARNING: CPU: 1 PID: 1228 at kernel/cgroup.c:1034 cgroup_get+0x89/0xa0()
...
Call Trace:
[] dump_stack+0x41/0x52
[] warn_slowpath_common+0x7f/0xa0
[] warn_slowpath_null+0x1d/0x20
[] cgroup_get+0x89/0xa0
[] cgroup_kn_lock_live+0x28/0x70
[] __cgroup_procs_write.isra.26+0x51/0x230
[] cgroup_tasks_write+0x12/0x20
[] cgroup_file_write+0x40/0x130
[] kernfs_fop_write+0xd1/0x160
[] vfs_write+0x98/0x1e0
[] SyS_write+0x4d/0xa0
[] sysenter_do_call+0x12/0x12
---[ end trace 6f2e0c38c2108a74 ]---
Fix this by calling css_tryget() instead of cgroup_get().
Reported-by: Toralf Förster
Signed-off-by: Li Zefan
---
kernel/cgroup.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index e03fc62..c8d07e5 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -1025,6 +1025,11 @@ static umode_t cgroup_file_mode(const struct cftype *cft)
return mode;
}
+static bool cgroup_tryget(struct cgroup *cgrp)
+{
+ return css_tryget(>self);
+}
+
static void cgroup_get(struct cgroup *cgrp)
{
WARN_ON_ONCE(cgroup_is_dead(cgrp));
@@ -1091,7 +1096,8 @@ static struct cgroup *cgroup_kn_lock_live(struct
kernfs_node *kn)
* protection against removal. Ensure @cgrp stays accessible and
* break the active_ref protection.
*/
- cgroup_get(cgrp);
+ if (!cgroup_tryget(cgrp))
+ return NULL;
kernfs_break_active_protection(kn);
mutex_lock(_mutex);
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c:at91: Fix a race condition during signal handling in at91_do_twi_xfer.
On Tue, Aug 26, 2014 at 09:13:24PM +0200, Simon Lindgren wrote: > There is a race condition in at91_do_twi_xfer when signals arrive. > If a signal is recieved while waiting for a transfer to complete > wait_for_completion_interruptible_timeout() will return -ERESTARTSYS. > This is not handled correctly resulting in interrupts still being > enabled and a transfer being in flight when we return. > > Symptoms include a range of oopses and bus lockups. Oopses can happen > when the transfer completes because the interrupt handler will corrupt > the stack. If a new transfer is started before the interrupt fires > the controller will start a new transfer in the middle of the old one, > resulting in confused slaves and a locked bus. > > To avoid this, use wait_for_completion_io_timeout instead so that we > don't have to deal with gracefully shutting down the transfer and > disabling the interrupts. > > Signed-off-by: Simon Lindgren Applied to for-current, thanks! signature.asc Description: Digital signature
[PATCH 1/2] cgroup: Delay the clearing of cgrp->kn->priv
Run these two scripts concurrently:
for ((; ;))
{
mkdir /cgroup/sub
rmdir /cgroup/sub
}
for ((; ;))
{
echo $$ > /cgroup/sub/cgroup.procs
ech $$ > /cgce 6f2e0c38c2108a74 ]---
}
A kernel bug will be triggered:
BUG: unable to handle kernel NULL pointer dereference at 0038
IP: [] cgroup_put+0x9/0x80
...
Call Trace:
[] cgroup_kn_unlock+0x39/0x50
[] cgroup_kn_lock_live+0x61/0x70
[] __cgroup_procs_write.isra.26+0x51/0x230
[] cgroup_tasks_write+0x12/0x20
[] cgroup_file_write+0x40/0x130
[] kernfs_fop_write+0xd1/0x160
[] vfs_write+0x98/0x1e0
[] SyS_write+0x4d/0xa0
[] sysenter_do_call+0x12/0x12
We clear cgrp->kn->priv in the end of cgroup_rmdir(), but another
concurrent thread can access kn->priv after the clearing.
We should move the clearing to css_release_work_fn(). At that time
no one is holding reference to the cgroup and no one can gain a new
reference to access it.
Reported-by: Toralf Förster
Signed-off-by: Li Zefan
---
Toralf, Thanks for reporting the bug. I'm not able to repy to your email,
because I was kicked out of the cgroup mailing list so didn't receive
emails from mailing list for a week.
---
kernel/cgroup.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 1c56924..e03fc62 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4185,6 +4185,15 @@ static void css_release_work_fn(struct work_struct *work)
mutex_unlock(_mutex);
+ /*
+* There are two control paths which try to determine cgroup from
+* dentry without going through kernfs - cgroupstats_build() and
+* css_tryget_online_from_dir(). Those are supported by RCU
+* protecting clearing of cgrp->kn->priv backpointer.
+*/
+ if (!ss && cgroup_parent(cgrp))
+ RCU_INIT_POINTER(*(void __rcu __force **)>kn->priv, NULL);
+
call_rcu(>rcu_head, css_free_rcu_fn);
}
@@ -4601,16 +4610,6 @@ static int cgroup_rmdir(struct kernfs_node *kn)
cgroup_kn_unlock(kn);
- /*
-* There are two control paths which try to determine cgroup from
-* dentry without going through kernfs - cgroupstats_build() and
-* css_tryget_online_from_dir(). Those are supported by RCU
-* protecting clearing of cgrp->kn->priv backpointer, which should
-* happen after all files under it have been removed.
-*/
- if (!ret)
- RCU_INIT_POINTER(*(void __rcu __force **)>priv, NULL);
-
cgroup_put(cgrp);
return ret;
}
--
1.8.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: magn: ak8975: fix unnecessary casting between char* and const char*
Use const char* instead of casting const char* to char*.
Signed-off-by: Irina Tirdea
---
drivers/iio/magnetometer/ak8975.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iio/magnetometer/ak8975.c
b/drivers/iio/magnetometer/ak8975.c
index a235792..61edc66 100644
--- a/drivers/iio/magnetometer/ak8975.c
+++ b/drivers/iio/magnetometer/ak8975.c
@@ -477,7 +477,7 @@ static const struct acpi_device_id ak_acpi_match[] = {
};
MODULE_DEVICE_TABLE(acpi, ak_acpi_match);
-static char *ak8975_match_acpi_device(struct device *dev,
+static const char *ak8975_match_acpi_device(struct device *dev,
enum asahi_compass_chipset *chipset)
{
const struct acpi_device_id *id;
@@ -487,7 +487,7 @@ static char *ak8975_match_acpi_device(struct device *dev,
return NULL;
*chipset = (int)id->driver_data;
- return (char *)dev_name(dev);
+ return dev_name(dev);
}
static int ak8975_probe(struct i2c_client *client,
@@ -497,7 +497,7 @@ static int ak8975_probe(struct i2c_client *client,
struct iio_dev *indio_dev;
int eoc_gpio;
int err;
- char *name = NULL;
+ const char *name = NULL;
/* Grab and set up the supplied GPIO. */
if (client->dev.platform_data)
@@ -539,7 +539,7 @@ static int ak8975_probe(struct i2c_client *client,
if (id) {
data->chipset =
(enum asahi_compass_chipset)(id->driver_data);
- name = (char *) id->name;
+ name = id->name;
} else if (ACPI_HANDLE(>dev))
name = ak8975_match_acpi_device(>dev, >chipset);
else
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: gyro: bmg160: only set power state if PM_RUNTIME is defined
When CONFIG_PM_RUNTIME is not defined and bmg160 tries to power
off the device, bmg160_set_power_state will call pm_runtime_put_autosuspend,
which is not implemented (wil return -ENOSYS).
Only call bmg160_set_power_state when CONFIG_PM_RUNTIME is defined.
Signed-off-by: Irina Tirdea
Reviewed-by: Srinivas Pandruvada
---
drivers/iio/gyro/bmg160.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iio/gyro/bmg160.c b/drivers/iio/gyro/bmg160.c
index 7524698..e41d6b5 100644
--- a/drivers/iio/gyro/bmg160.c
+++ b/drivers/iio/gyro/bmg160.c
@@ -235,6 +235,7 @@ static int bmg160_chip_init(struct bmg160_data *data)
return 0;
}
+#ifdef CONFIG_PM_RUNTIME
static int bmg160_set_power_state(struct bmg160_data *data, bool on)
{
int ret;
@@ -254,6 +255,12 @@ static int bmg160_set_power_state(struct bmg160_data
*data, bool on)
return 0;
}
+#else
+static int bmg160_set_power_state(struct bmg160_data *data, bool on)
+{
+ return 0;
+}
+#endif
static int bmg160_setup_any_motion_interrupt(struct bmg160_data *data,
bool status)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/9] perf: Deny optimized switch for events read by PERF_SAMPLE_READ
On Mon, Aug 25, 2014 at 04:45:36PM +0200, Jiri Olsa wrote: > The optimized task context switch for cloned perf events just > swaps whole perf event contexts (of current and next process) > if it finds them suitable. Events from the 'current' context > will now measure data of the 'next' context and vice versa. > > This is ok for cases where we are not directly interested in > the event->count value of separate child events, like: > - standard sampling, where we take 'period' value for the > event count > - counting, where we accumulate all events (children) > into a single count value > > But in case we read event by using the PERF_SAMPLE_READ sample > type, we are interested in direct event->count value measured > in specific task. Switching events within tasks for this kind > of measurements corrupts data. > > Fixing this by setting/unsetting pin_count for perf event context > once cloned event with PERF_SAMPLE_READ read is added/removed. > The pin_count value != 0 makes the context not suitable for > optimized switch. no.. so the value of the counter is the sum of all the inherited events. It doesn't matter if you flip it or not the sum is not affected. PERF_SAMPLE_READ should return the value. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: at91/dt: at91sam9m10g45ek add rtc node
Signed-off-by: Erik van Luijk
---
arch/arm/boot/dts/at91sam9g45.dtsi | 7 +++
arch/arm/boot/dts/at91sam9m10g45ek.dts | 3 +++
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/at91sam9g45.dtsi
b/arch/arm/boot/dts/at91sam9g45.dtsi
index 932a669..bf62c18 100644
--- a/arch/arm/boot/dts/at91sam9g45.dtsi
+++ b/arch/arm/boot/dts/at91sam9g45.dtsi
@@ -1070,6 +1070,13 @@
status = "disabled";
};
+ rtc@fdb0 {
+ compatible = "atmel,at91rm9200-rtc";
+ reg = <0xfdb0 0x30>;
+ interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+ status = "disabled";
+ };
+
spi0: spi@fffa4000 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/at91sam9m10g45ek.dts
b/arch/arm/boot/dts/at91sam9m10g45ek.dts
index 96ccc7d..2dd2347 100644
--- a/arch/arm/boot/dts/at91sam9m10g45ek.dts
+++ b/arch/arm/boot/dts/at91sam9m10g45ek.dts
@@ -70,6 +70,9 @@
watchdog@fd40 {
status = "okay";
+
+ rtc@fdb0 {
+ status = "okay";
};
mmc0: mmc@fff8 {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Next branch: authgss: authgss.c: Fix warnings for uninitizlized variable expire
On 09/01/2014 04:50 PM, Trond Myklebust wrote: > On Mon, Sep 1, 2014 at 7:32 AM, Shakil A Khan wrote: >> Signed-off-by : Shakil A Khan >> --- >> net/sunrpc/auth_gss/auth_gss.c |2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c >> index afb292c..bea0951 100644 >> --- a/net/sunrpc/auth_gss/auth_gss.c >> +++ b/net/sunrpc/auth_gss/auth_gss.c >> @@ -1387,7 +1387,7 @@ gss_key_timeout(struct rpc_cred *rc) >> struct gss_cred *gss_cred = container_of(rc, struct gss_cred, >> gc_base); >> struct gss_cl_ctx *ctx; >> unsigned long now = jiffies; >> - unsigned long expire; >> + unsigned long expire = 0; >> >> rcu_read_lock(); >> ctx = rcu_dereference(gss_cred->gc_ctx); >> -- >> 1.7.1 > > That would be a compiler bug, not a kernel bug. The kernel code is > perfectly correct as it stands, and will never access the > uninitialised variable. > Than you will need the infamous uninitialised_var() diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c index afb292c..bea0951 100644 --- a/net/sunrpc/auth_gss/auth_gss.c +++ b/net/sunrpc/auth_gss/auth_gss.c @@ -1387,7 +1387,7 @@ gss_key_timeout(struct rpc_cred *rc) struct gss_cred *gss_cred = container_of(rc, struct gss_cred, gc_base); struct gss_cl_ctx *ctx; unsigned long now = jiffies; - unsigned long expire; + unsigned long uninitialised_var(expire); rcu_read_lock(); ctx = rcu_dereference(gss_cred->gc_ctx); Cheers Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] iio: gyro: bmi055 gyro sensor driver
Add support for the BMI055 gyroscope sensor. BMI055 is a package
consisting of an acceleration sensor and a gyroscope. This patch
adds support for the gyroscope only.
Spec downloaded from:
http://ae-bst.resource.bosch.com/media/products/dokumente/bmi055/BST-BMI055-DS000-06.pdf
The BMI055 gyroscope uses the same register definition as BMG160,
but does not specify a temp register. However, the temp register
seems to be working in the same way as for BMG160, so this patch
does not remove the temp channel for BMI055.
Signed-off-by: Irina Tirdea
Reviewed-by: Srinivas Pandruvada
---
drivers/iio/gyro/Kconfig |2 +-
drivers/iio/gyro/bmg160.c | 39 +++
2 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/gyro/Kconfig b/drivers/iio/gyro/Kconfig
index d630ae9..b3d0e94 100644
--- a/drivers/iio/gyro/Kconfig
+++ b/drivers/iio/gyro/Kconfig
@@ -56,7 +56,7 @@ config BMG160
select IIO_TRIGGERED_BUFFER if IIO_BUFFER
help
Say yes here to build support for Bosch BMG160 Tri-axis Gyro Sensor
- driver.
+ driver. This driver also supports BMI055 gyroscope.
This driver can also be built as a module. If so, the module
will be called bmg160.
diff --git a/drivers/iio/gyro/bmg160.c b/drivers/iio/gyro/bmg160.c
index 80f92a6..7524698 100644
--- a/drivers/iio/gyro/bmg160.c
+++ b/drivers/iio/gyro/bmg160.c
@@ -947,10 +947,10 @@ static irqreturn_t bmg160_data_rdy_trig_poll(int irq,
void *private)
}
-static int bmg160_acpi_gpio_probe(struct i2c_client *client,
- struct bmg160_data *data)
+static int bmg160_gpio_probe(struct i2c_client *client,
+struct bmg160_data *data)
+
{
- const struct acpi_device_id *id;
struct device *dev;
struct gpio_desc *gpio;
int ret;
@@ -959,12 +959,6 @@ static int bmg160_acpi_gpio_probe(struct i2c_client
*client,
return -EINVAL;
dev = >dev;
- if (!ACPI_HANDLE(dev))
- return -ENODEV;
-
- id = acpi_match_device(dev->driver->acpi_match_table, dev);
- if (!id)
- return -ENODEV;
/* data ready gpio interrupt pin */
gpio = devm_gpiod_get_index(dev, BMG160_GPIO_NAME, 0);
@@ -984,12 +978,24 @@ static int bmg160_acpi_gpio_probe(struct i2c_client
*client,
return ret;
}
+static const char *bmg160_match_acpi_device(struct device *dev)
+{
+ const struct acpi_device_id *id;
+
+ id = acpi_match_device(dev->driver->acpi_match_table, dev);
+ if (!id)
+ return NULL;
+
+ return dev_name(dev);
+}
+
static int bmg160_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct bmg160_data *data;
struct iio_dev *indio_dev;
int ret;
+ const char *name = NULL;
indio_dev = devm_iio_device_alloc(>dev, sizeof(*data));
if (!indio_dev)
@@ -1005,15 +1011,21 @@ static int bmg160_probe(struct i2c_client *client,
mutex_init(>mutex);
+ if (id)
+ name = id->name;
+
+ if (ACPI_HANDLE(>dev))
+ name = bmg160_match_acpi_device(>dev);
+
indio_dev->dev.parent = >dev;
indio_dev->channels = bmg160_channels;
indio_dev->num_channels = ARRAY_SIZE(bmg160_channels);
- indio_dev->name = BMG160_DRV_NAME;
+ indio_dev->name = name;
indio_dev->modes = INDIO_DIRECT_MODE;
indio_dev->info = _info;
if (client->irq <= 0)
- client->irq = bmg160_acpi_gpio_probe(client, data);
+ client->irq = bmg160_gpio_probe(client, data);
if (client->irq > 0) {
ret = devm_request_threaded_irq(>dev,
@@ -1183,12 +1195,15 @@ static const struct dev_pm_ops bmg160_pm_ops = {
static const struct acpi_device_id bmg160_acpi_match[] = {
{"BMG0160", 0},
- { },
+ {"BMI055B", 0},
+ {},
};
+
MODULE_DEVICE_TABLE(acpi, bmg160_acpi_match);
static const struct i2c_device_id bmg160_id[] = {
{"bmg160", 0},
+ {"bmi055_gyro", 0},
{}
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] perf: Remove redundant parent context check from context_equiv
On Mon, Aug 25, 2014 at 04:45:35PM +0200, Jiri Olsa wrote:
> As described in commit:
> 1f9a7268c67f perf: Do not allow optimized switch for non-cloned events
> we dont allow optimized switch for non cloned contexts.
>
> There's no need now to check if one of the context is parent
> of the other in context_equiv function.
>
OK, so talk to me about that patch; it looks like you're slowly
reverting: 5a3126d4fe7c ("perf: Fix the perf context switch
optimization").
So what exactly is the problem? I'm still jet-lagged and not seeing it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/4] pci_ids: add support for Intel Quark ILB
From: Josef Ahmad This patch adds the PCI id for Intel Quark ILB. It will be used for GPIO and Multifunction device driver. Signed-off-by: Josef Ahmad Acked-by: Bjorn Helgaas Signed-off-by: Andy Shevchenko --- include/linux/pci_ids.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 6ed0bb7..4e82195 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -2557,6 +2557,7 @@ #define PCI_DEVICE_ID_INTEL_MFD_EMMC0 0x0823 #define PCI_DEVICE_ID_INTEL_MFD_EMMC1 0x0824 #define PCI_DEVICE_ID_INTEL_MRST_SD2 0x084F +#define PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB0x095E #define PCI_DEVICE_ID_INTEL_I960 0x0960 #define PCI_DEVICE_ID_INTEL_I960RM 0x0962 #define PCI_DEVICE_ID_INTEL_CENTERTON_ILB 0x0c60 -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver
On Tue, Sep 02, 2014 at 11:06:30AM +0100, Andre Przywara wrote: > Hi Rob, > > thanks for looking at this. > > On 02/09/14 04:06, Rob Herring wrote: > > On Fri, Aug 29, 2014 at 11:13 AM, Andre Przywara > > wrote: > >> The ARM Server Base System Architecture (SBSA) describes a generic > >> UART which all compliant level 1 systems should implement. This is > >> actually a PL011 subset, so a full PL011 implementation will satisfy > >> this requirement. > >> However if a system does not have a PL011, a very stripped down > >> implementation complying to the SBSA defined specification will > >> suffice. The Linux PL011 driver is not guaranteed to drive this > >> limited device (and indeed the fast model implentation hangs the > >> kernel if driven by the PL011 driver). > >> So introduce a new driver just implementing the part specified by the > >> SBSA (which lacks DMA, the modem control signals and many of the > >> registers including baud rate control). This driver has been derived > >> by the actual PL011 one, removing all unnecessary code. > >> > >> Signed-off-by: Andre Przywara > >> --- > >> .../devicetree/bindings/serial/arm_sbsa_uart.txt |6 + > >> drivers/tty/serial/Kconfig | 28 + > >> drivers/tty/serial/Makefile|1 + > >> drivers/tty/serial/sbsa_uart.c | 793 > >> > >> include/uapi/linux/serial_core.h |1 + > > > > Sorry, but I think this is all wrong. We've now just duplicated some > > subset of the pl011 driver leaving out the parts like setting baudrate > > which can never be added since those things could be different for > > every vendor. > > > > The original intent of the SBSA uart was to provide a common early > > debug uart. It was not to have a full fledged driver. I think the SBSA > > has failed in this area and created the potential to create a mess of > > serial drivers different for every vendor. Reality will hopefully not > > be that extreme and most vendors will just use the pl011 and create > > their value add somewhere besides the uart. For the purpose of debug > > output, we already support that as the pl011 earlycon only touches > > SBSA compatible registers. I agree that we don't want a proliferation of not-quite-pl011 devices that we end up having to drive differently. If we do have such devices I wouldn't want to call them a pl011s for the sake of earlycon if they aren't actually pl011s. > I see your point (and was actually looking for those kind of comments > when posting this). > I agree to that debug aspect and understand that earlycon already does > this, but I think we need some support beyond earlycon, to be able to > login and use it as a console (which is not possible with earlycon, > right?) This is probably still for debugging or emergency access to the > system only, but maybe also for logging - actually quite similar to how > UARTs are used on today's x86 servers. > So after having written three incarnations of this driver (goldfish > based, PL010 based, PL011 based) I wonder if supporting the SBSA subset > in the real PL011 driver is an option. Either this would be enabled by a > new explicit DT property or preferably by a clever compatible string. > Ideally we would just provide a different set of "struct uart_ops" > members, with some pointing to generic PL011 routines, some to SBSA UART > specific ones. > Maybe we make the full featured PL011 support a config option > (defaulting to y), allowing people to only use the SBSA subset in their > kernel? > > Does that make more sense? (for a general SBSA h/w rationale see below) > > >> 5 files changed, 829 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt > >> create mode 100644 drivers/tty/serial/sbsa_uart.c > >> > >> diff --git a/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt > >> b/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt > >> new file mode 100644 > >> index 000..8e2c5d6 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt > >> @@ -0,0 +1,6 @@ > >> +* ARM SBSA defined generic UART > >> + > >> +Required properties: > >> +- compatible: must be "arm,sbsa-uart" > > > > This alone is not okay. There is no such implementation of hardware. Do you want something like: - compatible: must contain an "arm,sbsa-uart" following a more specific entry from the following list: * "arm,pl011" Or do we need to restructure the pl011 docs entirely? Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/4] mfd: lpc_sch: Intel Quark support
This brings support of the LPC SCH device found on Intel Quark SoC. Patches were compile tested, and driver runs on actual hardware. Please, note that PCI ID will be used in future in the gpio-sch driver. Changelog v2: - squash patches 1/5 and 2/5 into 1/4 - add Acked-by Bjorn - address Lee's comments against 3/4 (former 4/5) - rebase on newest linux-next Andy Shevchenko (3): mfd: lpc_sch: reduce duplicate code and improve manageability mfd: lpc_sch: Add support for Intel Quark X1000 mfd: lpc_sch: remove FSF address Josef Ahmad (1): pci_ids: add support for Intel Quark ILB drivers/mfd/lpc_sch.c | 211 include/linux/pci_ids.h | 1 + 2 files changed, 126 insertions(+), 86 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/4] mfd: lpc_sch: reduce duplicate code and improve manageability
This patch refactors the driver to use helper functions instead of
copy'n'pasted pieces of code.
It also introduces an additional struct to hold a chipset info. The chipset
info will be used to store features that are supported by specific processor or
chipset. LPC_SCH supports SMBUS, GPIO and WDT features. As this code base might
expand further to support more processors, this implementation will help to
keep code base clean and manageable.
The patch is partially based on the work done by Chang Rebecca Swee Fun.
Tested-by: Chang Rebecca Swee Fun
Signed-off-by: Andy Shevchenko
---
drivers/mfd/lpc_sch.c | 181 +++---
1 file changed, 99 insertions(+), 82 deletions(-)
diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c
index 4ee7550..bde070a 100644
--- a/drivers/mfd/lpc_sch.c
+++ b/drivers/mfd/lpc_sch.c
@@ -40,120 +40,137 @@
#define WDTBASE0x84
#define WDT_IO_SIZE64
-static struct resource smbus_sch_resource = {
- .flags = IORESOURCE_IO,
+enum sch_chipsets {
+ LPC_SCH = 0,/* Intel Poulsbo SCH */
+ LPC_ITC,/* Intel Tunnel Creek */
+ LPC_CENTERTON, /* Intel Centerton */
};
-static struct resource gpio_sch_resource = {
- .flags = IORESOURCE_IO,
+struct lpc_sch_info {
+ unsigned int io_size_smbus;
+ unsigned int io_size_gpio;
+ unsigned int io_size_wdt;
};
-static struct resource wdt_sch_resource = {
- .flags = IORESOURCE_IO,
-};
-
-static struct mfd_cell lpc_sch_cells[3];
-
-static struct mfd_cell isch_smbus_cell = {
- .name = "isch_smbus",
- .num_resources = 1,
- .resources = _sch_resource,
- .ignore_resource_conflicts = true,
-};
-
-static struct mfd_cell sch_gpio_cell = {
- .name = "sch_gpio",
- .num_resources = 1,
- .resources = _sch_resource,
- .ignore_resource_conflicts = true,
-};
-
-static struct mfd_cell wdt_sch_cell = {
- .name = "ie6xx_wdt",
- .num_resources = 1,
- .resources = _sch_resource,
- .ignore_resource_conflicts = true,
+static struct lpc_sch_info sch_chipset_info[] = {
+ [LPC_SCH] = {
+ .io_size_smbus = SMBUS_IO_SIZE,
+ .io_size_gpio = GPIO_IO_SIZE,
+ },
+ [LPC_ITC] = {
+ .io_size_smbus = SMBUS_IO_SIZE,
+ .io_size_gpio = GPIO_IO_SIZE,
+ .io_size_wdt = WDT_IO_SIZE,
+ },
+ [LPC_CENTERTON] = {
+ .io_size_smbus = SMBUS_IO_SIZE,
+ .io_size_gpio = GPIO_IO_SIZE_CENTERTON,
+ .io_size_wdt = WDT_IO_SIZE,
+ },
};
static const struct pci_device_id lpc_sch_ids[] = {
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SCH_LPC) },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ITC_LPC) },
- { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_CENTERTON_ILB) },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SCH_LPC), LPC_SCH },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ITC_LPC), LPC_ITC },
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_CENTERTON_ILB), LPC_CENTERTON
},
{ 0, }
};
MODULE_DEVICE_TABLE(pci, lpc_sch_ids);
-static int lpc_sch_probe(struct pci_dev *dev,
- const struct pci_device_id *id)
+#define LPC_NO_RESOURCE1
+#define LPC_SKIP_RESOURCE 2
+
+static int lpc_sch_get_io(struct pci_dev *pdev, int where, const char *name,
+ struct resource *res, int size)
{
unsigned int base_addr_cfg;
unsigned short base_addr;
- int i, cells = 0;
- int ret;
- pci_read_config_dword(dev, SMBASE, _addr_cfg);
+ if (size == 0)
+ return LPC_NO_RESOURCE;
+
+ pci_read_config_dword(pdev, where, _addr_cfg);
base_addr = 0;
if (!(base_addr_cfg & (1 << 31)))
- dev_warn(>dev, "Decode of the SMBus I/O range disabled\n");
+ dev_warn(>dev, "Decode of the %s I/O range disabled\n",
+name);
else
base_addr = (unsigned short)base_addr_cfg;
if (base_addr == 0) {
- dev_warn(>dev, "I/O space for SMBus uninitialized\n");
- } else {
- lpc_sch_cells[cells++] = isch_smbus_cell;
- smbus_sch_resource.start = base_addr;
- smbus_sch_resource.end = base_addr + SMBUS_IO_SIZE - 1;
+ dev_warn(>dev, "I/O space for %s uninitialized\n", name);
+ return LPC_SKIP_RESOURCE;
}
- pci_read_config_dword(dev, GPIOBASE, _addr_cfg);
- base_addr = 0;
- if (!(base_addr_cfg & (1 << 31)))
- dev_warn(>dev, "Decode of the GPIO I/O range disabled\n");
- else
- base_addr = (unsigned short)base_addr_cfg;
+ res->start = base_addr;
+ res->end = base_addr + size - 1;
+ res->flags = IORESOURCE_IO;
-
[PATCH v2 4/4] mfd: lpc_sch: remove FSF address
This patch removes FSF address because it can be changed. While here, update the copyright lines by adding Intel Corp. to them. There is no functional change. Signed-off-by: Andy Shevchenko --- drivers/mfd/lpc_sch.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c index ae614b2..c980da4 100644 --- a/drivers/mfd/lpc_sch.c +++ b/drivers/mfd/lpc_sch.c @@ -7,6 +7,7 @@ * Configuration Registers. * * Copyright (c) 2010 CompuLab Ltd + * Copyright (c) 2014 Intel Corp. * Author: Denis Turischev * * This program is free software; you can redistribute it and/or modify @@ -17,10 +18,6 @@ * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; see the file COPYING. If not, write to - * the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. */ #include -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/4] mfd: lpc_sch: Add support for Intel Quark X1000
Intel Quark X1000 SoC supports IRQ based GPIO. This patch will
enable MFD support for Quark X1000 and provide IRQ resources
to Quark X1000 GPIO device driver.
Signed-off-by: Chang Rebecca Swee Fun
Tested-by: Chang Rebecca Swee Fun
Signed-off-by: Andy Shevchenko
---
drivers/mfd/lpc_sch.c | 37 +++--
1 file changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/lpc_sch.c b/drivers/mfd/lpc_sch.c
index bde070a..ae614b2 100644
--- a/drivers/mfd/lpc_sch.c
+++ b/drivers/mfd/lpc_sch.c
@@ -37,6 +37,9 @@
#define GPIO_IO_SIZE 64
#define GPIO_IO_SIZE_CENTERTON 128
+/* Intel Quark X1000 GPIO IRQ Number */
+#define GPIO_IRQ_QUARK_X1000 9
+
#define WDTBASE0x84
#define WDT_IO_SIZE64
@@ -44,28 +47,37 @@ enum sch_chipsets {
LPC_SCH = 0,/* Intel Poulsbo SCH */
LPC_ITC,/* Intel Tunnel Creek */
LPC_CENTERTON, /* Intel Centerton */
+ LPC_QUARK_X1000,/* Intel Quark X1000 */
};
struct lpc_sch_info {
unsigned int io_size_smbus;
unsigned int io_size_gpio;
unsigned int io_size_wdt;
+ int irq_gpio;
};
static struct lpc_sch_info sch_chipset_info[] = {
[LPC_SCH] = {
.io_size_smbus = SMBUS_IO_SIZE,
.io_size_gpio = GPIO_IO_SIZE,
+ .irq_gpio = -1,
},
[LPC_ITC] = {
.io_size_smbus = SMBUS_IO_SIZE,
.io_size_gpio = GPIO_IO_SIZE,
.io_size_wdt = WDT_IO_SIZE,
+ .irq_gpio = -1,
},
[LPC_CENTERTON] = {
.io_size_smbus = SMBUS_IO_SIZE,
.io_size_gpio = GPIO_IO_SIZE_CENTERTON,
.io_size_wdt = WDT_IO_SIZE,
+ .irq_gpio = -1,
+ },
+ [LPC_QUARK_X1000] = {
+ .io_size_gpio = GPIO_IO_SIZE,
+ .irq_gpio = GPIO_IRQ_QUARK_X1000,
},
};
@@ -73,6 +85,7 @@ static const struct pci_device_id lpc_sch_ids[] = {
{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SCH_LPC), LPC_SCH },
{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_ITC_LPC), LPC_ITC },
{ PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_CENTERTON_ILB), LPC_CENTERTON
},
+ { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB),
LPC_QUARK_X1000 },
{ 0, }
};
MODULE_DEVICE_TABLE(pci, lpc_sch_ids);
@@ -110,13 +123,13 @@ static int lpc_sch_get_io(struct pci_dev *pdev, int
where, const char *name,
}
static int lpc_sch_populate_cell(struct pci_dev *pdev, int where,
-const char *name, int size, int id,
-struct mfd_cell *cell)
+const char *name, int size, int irq,
+int id, struct mfd_cell *cell)
{
struct resource *res;
int ret;
- res = devm_kzalloc(>dev, sizeof(*res), GFP_KERNEL);
+ res = devm_kcalloc(>dev, 2, sizeof(*res), GFP_KERNEL);
if (!res)
return -ENOMEM;
@@ -132,6 +145,18 @@ static int lpc_sch_populate_cell(struct pci_dev *pdev, int
where,
cell->ignore_resource_conflicts = true;
cell->id = id;
+ /* Check if we need to add an IRQ resource */
+ if (irq < 0)
+ return 0;
+
+ res++;
+
+ res->start = irq;
+ res->end = irq;
+ res->flags = IORESOURCE_IRQ;
+
+ cell->num_resources++;
+
return 0;
}
@@ -143,7 +168,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const struct
pci_device_id *id)
int ret;
ret = lpc_sch_populate_cell(dev, SMBASE, "isch_smbus",
- info->io_size_smbus,
+ info->io_size_smbus, -1,
id->device, _sch_cells[cells]);
if (ret < 0)
return ret;
@@ -151,7 +176,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const struct
pci_device_id *id)
cells++;
ret = lpc_sch_populate_cell(dev, GPIOBASE, "sch_gpio",
- info->io_size_gpio,
+ info->io_size_gpio, info->irq_gpio,
id->device, _sch_cells[cells]);
if (ret < 0)
return ret;
@@ -159,7 +184,7 @@ static int lpc_sch_probe(struct pci_dev *dev, const struct
pci_device_id *id)
cells++;
ret = lpc_sch_populate_cell(dev, WDTBASE, "ie6xx_wdt",
- info->io_size_wdt,
+ info->io_size_wdt, -1,
id->device, _sch_cells[cells]);
if (ret < 0)
return ret;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [PATCHv2 1/4] ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code.
On 09/02/2014 04:08 PM, Jean-Francois Moine wrote:
On Tue, 02 Sep 2014 15:51:41 +0530
Varka Bhadram wrote:
+ switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
+ case 0x11:
+ return SND_SOC_DAIFMT_CBS_CFS;
+ case 0x10:
+ return SND_SOC_DAIFMT_CBS_CFM;
+ case 0x01:
+ return SND_SOC_DAIFMT_CBM_CFS;
+ default:
+ return SND_SOC_DAIFMT_CBM_CFM;
+ }
+
+ /* Shouldn't be here */
+ return -EINVAL;
+}
It will be nice if we declare the switch case numbers as macros (specific
name)...
I don't see which macros: the values are just 2 booleans.
I am talking about 0x11, 0x10, 0x01 values.. We can give any understandable
names to those...?
--
Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 3/4] ASoC: simple-card: Adjust the comments of simple card.
On Tue, 2 Sep 2014 17:26:08 +0800 Xiubo Li wrote: > @@ -285,11 +287,11 @@ static int asoc_simple_card_dai_link_of(struct > device_node *node, > dai_props->codec_dai.sysclk); > > /* > - * soc_bind_dai_link() will check cpu name > - * after of_node matching if dai_link has cpu_dai_name. > - * but, it will never match if name was created by fmt_single_name() > - * remove cpu_dai_name to escape name matching. > - * see > + * In soc_bind_dai_link() will check cpu name after > + * of_node matching if dai_link has cpu_dai_name. > + * but, it will never match if name was created by > + * fmt_single_name() remove cpu_dai_name to escape > + * name matching. Please see: >* fmt_single_name() >* fmt_multiple_name() >*/ The patch done by Kuninori, setting the cpu_dai_name to NULL in all cases, does not work. This sequence should be replaced where is was previously. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.16/3.16.1: Kernel Oops in nft_do_chain
On Tue, Sep 02, 2014 at 12:14:27PM +0200, leroy christophe wrote: > Calling 'iptables-compat -L', first time nothing is listed on the screen. > Second try, it generates following Oops. I'm going to pass this patch to -stable asap: commit b88825de8545ad252c31543fef13cadf4de7a2bc Author: Pablo Neira Ayuso Date: Tue Aug 5 17:25:59 2014 +0200 netfilter: nf_tables: don't update chain with unset counters Fix possible replacement of the per-cpu chain counters by null pointer when updating an existing chain in the commit path. Reported-by: Matteo Croce Signed-off-by: Pablo Neira Ayuso I think it's the root cause for this problem. > c7ff3c30 c7ff3d98 > [ 191.490095] NIP [c02f9924] nft_do_chain+0x438/0x4f4 > [ 191.494890] LR [c0365b54] nft_do_chain_ipv4+0x6c/0x7c > [ 191.499833] Call Trace: > [ 191.502295] [c7ff3c20] [c02f9970] nft_do_chain+0x484/0x4f4 (unreliable) > [ 191.508830] [c7ff3d90] [c0365b54] nft_do_chain_ipv4+0x6c/0x7c > [ 191.514514] [c7ff3de0] [c02e134c] nf_iterate+0xe4/0x12c > [ 191.519673] [c7ff3e20] [c02e15c8] nf_hook_slow+0xa0/0x1f4 > [ 191.525034] [c7ff3e60] [c030dd70] ip_local_deliver+0xa0/0xac > [ 191.530613] [c7ff3e70] [c030d4f4] ip_rcv_finish+0x130/0x350 > [ 191.536128] [c7ff3e90] [c02b5304] __netif_receive_skb_core+0x4c4/0x600 > [ 191.542595] [c7ff3ef0] [c0237824] fs_enet_rx_napi+0x30c/0x448 > [ 191.548252] [c7ff3f50] [c02b5c38] net_rx_action+0x140/0x20c > [ 191.553771] [c7ff3f90] [c001c918] __do_softirq+0x13c/0x2b4 > [ 191.559177] [c7ff3ff0] [c000b660] call_do_softirq+0x24/0x3c > [ 191.564696] [c79e5e50] [c0003e04] do_softirq_own_stack+0x3c/0x7c > [ 191.570625] [c79e5e70] [c001c7d8] do_softirq+0x58/0x5c > [ 191.575705] [c79e5e80] [c001cd34] __local_bh_enable_ip+0xa0/0xc4 > [ 191.581649] [c79e5e90] [c00525cc] irq_forced_thread_fn+0x64/0x84 > [ 191.587577] [c79e5eb0] [c00521fc] irq_thread+0x130/0x188 > [ 191.592848] [c79e5ef0] [c0039190] kthread+0xd0/0xe4 > [ 191.597651] [c79e5f40] [c000c6d0] ret_from_kernel_thread+0x5c/0x64 > [ 191.603706] Instruction dump: > [ 191.606636] 83210014 4bfffc90 813f 80090060 74090001 40820070 > 54290024 8009000c > [ 191.614294] 3200 9009000c 8130fff8 3960 <80690008> > 8089000c 80a9 31040001 > [ 191.622147] ---[ end trace 86fcabb2513eb932 ]--- > [ 191.626687] > [ 192.599223] Kernel panic - not syncing: Fatal exception in interrupt > [ 192.605305] Rebooting in 180 seconds.. > > if (unlikely(pkt->skb->nf_trace)) > c02f98fc:81 3f 00 00 lwz r9,0(r31) > c02f9900:80 09 00 60 lwz r0,96(r9) > c02f9904:74 09 00 01 andis. r9,r0,1 > c02f9908:40 82 00 70 bne-c02f9978 > c02f990c:54 29 00 24 rlwinm r9,r1,0,0,18 > c02f9910:80 09 00 0c lwz r0,12(r9) > c02f9914:30 00 02 00 addic r0,r0,512 > c02f9918:90 09 00 0c stw r0,12(r9) > nft_trace_packet(pkt, basechain, -1, NFT_TRACE_POLICY); > > rcu_read_lock_bh(); > stats = > this_cpu_ptr(rcu_dereference(nft_base_chain(basechain)->stats)); > c02f991c:81 30 ff f8 lwz r9,-8(r16) > u64_stats_update_begin(>syncp); > stats->pkts++; > stats->bytes += pkt->skb->len; > c02f9920:39 60 00 00 li r11,0 > nft_trace_packet(pkt, basechain, -1, NFT_TRACE_POLICY); > > rcu_read_lock_bh(); > stats = > this_cpu_ptr(rcu_dereference(nft_base_chain(basechain)->stats)); > u64_stats_update_begin(>syncp); > stats->pkts++; > ==> c02f9924:80 69 00 08 lwz r3,8(r9) > c02f9928:80 89 00 0c lwz r4,12(r9) > stats->bytes += pkt->skb->len; > c02f992c:80 a9 00 00 lwz r5,0(r9) > nft_trace_packet(pkt, basechain, -1, NFT_TRACE_POLICY); > > rcu_read_lock_bh(); > stats = > this_cpu_ptr(rcu_dereference(nft_base_chain(basechain)->stats)); > u64_stats_update_begin(>syncp); > stats->pkts++; > c02f9930:31 04 00 01 addic r8,r4,1 > c02f9934:7c e3 01 94 addze r7,r3 > c02f9938:90 e9 00 08 stw r7,8(r9) > c02f993c:91 09 00 0c stw r8,12(r9) > stats->bytes += pkt->skb->len; > c02f9940:80 c9 00 04 lwz r6,4(r9) > c02f9944:81 5f 00 00 lwz r10,0(r31) > __local_bh_enable_ip(ip, SOFTIRQ_DISABLE_OFFSET); > } > > > Christophe > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] ASoC: simple-card: binding: update binding to support the new style.
On Tue, 2 Sep 2014 17:26:09 +0800
Xiubo Li wrote:
> +Example 4 - many DAI links:
> sound {
> compatible = "simple-audio-card";
> simple-audio-card,name = "Cubox Audio";
> @@ -128,6 +195,7 @@ sound {
> };
> codec {
> sound-dai = < 0>;
> + frame-inversion;
> };
> };
This is not useful: there is no clock/frame handling in the kirkwood
audio controller.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] i2c: mv64xxx: continue probe when clock-frequency is missing
On Mon, Sep 01, 2014 at 10:28:13PM +0800, Chen-Yu Tsai wrote:
> The "clock-frequency" DT property is listed as optional, However,
> the current code stores the return value of of_property_read_u32 in
> the return code of mv64xxx_of_config, but then forgets to clear it
> after setting the default value of "clock-frequency". It is then
> passed out to the main probe function, resulting in a probe failure
> when "clock-frequency" is missing.
>
> This patch checks and then throws away the return value of
> of_property_read_u32, instead of storing it and having to clear it
> afterwards.
>
> This issue was discovered after the property was removed from all
> sunxi DTs.
Hmm, I don't like that removal. Probably I should take care that this
property is not "optional" but "recommended". The default value is
depending on the driver, mostly because of historic reasons. It is
definately better to explicitly state it. Despite all that...
>
> Fixes: 4c730a06c19bb ("i2c: mv64xxx: Set bus frequency to 100kHz if
> clock-frequency is not provided")
> Signed-off-by: Chen-Yu Tsai
> Cc: sta...@vger.kernel.org
> Acked-by: Andrew Lunn
> Acked-by: Maxime Ripard
Applied to for-current, thanks!
signature.asc
Description: Digital signature
Re: [PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
Hi,
On Fri, Aug 29, 2014 at 12:18 AM, Mark Rutland wrote:
> On Thu, Aug 28, 2014 at 09:01:56AM +0100, Vivek Gautam wrote:
>> Exynos7 also has a separate special gate clock going to the IP
>> apart from the usual AHB clock. So add support for the same.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> drivers/usb/dwc3/dwc3-exynos.c | 16
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
>> index f9fb8ad..bab6395 100644
>> --- a/drivers/usb/dwc3/dwc3-exynos.c
>> +++ b/drivers/usb/dwc3/dwc3-exynos.c
>> @@ -35,6 +35,7 @@ struct dwc3_exynos {
>> struct device *dev;
>>
>> struct clk *clk;
>> + struct clk *sclk;
>> struct regulator*vdd33;
>> struct regulator*vdd10;
>> };
>> @@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device
>> *pdev)
>> return -EINVAL;
>> }
>>
>> + /* Exynos7 has a special gate clock going to this IP */
>> + exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk");
>> + if (IS_ERR(exynos->sclk))
>> + dev_warn(dev, "couldn't get sclk\n");
>
> Doesn't this introduce a pointless warning for Exynos SoCs other than
> Exynos7?
True, it will introduce an unnecessary warning for non-Exynos7 systems.
I initially thought of introducing a compatible check for Exynos7-dwc3, but that
way we may end up adding such checks for future SoCs which have similar
controller but have some clock difference or some other small change, no ?
>
>> +
>> exynos->dev = dev;
>> exynos->clk = clk;
>>
>> clk_prepare_enable(exynos->clk);
>> + if (!IS_ERR(exynos->sclk))
>> + clk_prepare_enable(exynos->sclk);
>
> If you replaced the returned err value with NULL you could avoid these
> IS_ERR cases.
Right, point taken.
[snip]
--
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/4] ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code.
On Tue, 02 Sep 2014 15:51:41 +0530
Varka Bhadram wrote:
> > + switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
> > + case 0x11:
> > + return SND_SOC_DAIFMT_CBS_CFS;
> > + case 0x10:
> > + return SND_SOC_DAIFMT_CBS_CFM;
> > + case 0x01:
> > + return SND_SOC_DAIFMT_CBM_CFS;
> > + default:
> > + return SND_SOC_DAIFMT_CBM_CFM;
> > + }
> > +
> > + /* Shouldn't be here */
> > + return -EINVAL;
> > +}
>
> It will be nice if we declare the switch case numbers as macros (specific
> name)...
I don't see which macros: the values are just 2 booleans.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/3] iio: accel: BMC150: add support for other Bosch chips
On Mon, Sep 01, 2014 at 08:51:36AM -0700, Srinivas Pandruvada wrote:
> On Mon, 2014-09-01 at 08:36 -0700, Joe Perches wrote:
> > On Mon, 2014-09-01 at 12:11 +0300, Laurentiu Palcu wrote:
> > > The following chips are either similar or have only the resolution
> > > different. Hence, change this driver to support these chips too:
> > >
> > > BMI055 - combo chip (accelerometer part is identical to BMC150's)
> > > BMA255 - identical to BMC150's accelerometer
> > > BMA222E - 8 bit resolution
> > > BMA250E - 10 bit resolution
> > > BMA280 - 14 bit resolution
> > >
> > > Additionally:
> > > * add bmc150_accel_match_acpi_device() function to check that the device
> > >has been enumerated through ACPI;
> > > * rename bmc150_accel_acpi_gpio_probe() to bmc150_accel_gpio_probe()
> > >since the ACPI matching has been moved to the new function. Also, this
> > >will allow for the GPIO matching to be done against a device tree too,
> > > not only
> > >ACPI tree;
> > []
> > > diff --git a/drivers/iio/accel/bmc150-accel.c
> > > b/drivers/iio/accel/bmc150-accel.c
> > []
> > > @@ -647,12 +659,13 @@ static int bmc150_accel_read_raw(struct iio_dev
> > > *indio_dev,
> > > {
> > > int i;
> > >
> > > - for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table);
> > > - ++i) {
> > > - if (bmc150_accel_scale_table[i].range ==
> > > + for (i = 0;
> > > + i < ARRAY_SIZE(data->chip_info->scale_table);
> > > + ++i) {
> > > + if (data->chip_info->scale_table[i].range ==
> > > data->range) {
> > > *val2 =
> > > - bmc150_accel_scale_table[i].scale;
> > > + data->chip_info->scale_table[i].scale;
> > > return IIO_VAL_INT_PLUS_MICRO;
> > > }
> > > }
> >
> > This looks like it would read a lot better with
> > a temporary for data->chip_info->scale_table[i]
> >
> > so these could become:
> >
> > for (i = 0; i < etc; i++) {
> > type *temp = >chip_info->scale_table[i];
> > if (temp->range == data->range) {
> > *val2 = temp->scale;
> > return IIO_VAL_INT_PLUS_MICRO;
> > }
Rewrote this part in v5. Thanks for the suggestion.
> >
> > Maybe all the bmc150_ variable names could be removed.
> > The prefixes don't seem to serve a purpose other than
> > to make the code longer.
> >
> > The filename could be changed to be more generic.
> Then this will also require change in the CONFIG name to match. This
> will require all current users to change the config file once they
> update to new version of the driver, which they don't like to change
> once product config is finalized. Since the most of the chips will just
> differ by a number at the end and they may not be compatible to each
> other, finding a common name will be challenge.
> Instead the CONFIG description for this module should explicitly state
> the names of chips it is compatible to.
v5 contains the changed CONFIG description that includes the new added chips.
thanks,
laurentiu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: xillybus: Move out of staging
Hello, Arend. On 01/09/14 16:08, Arend van Spriel wrote: Maybe it would be better to use the DMA-API instead of the PCI wrappers. I just found out that the PCI wrappers were indeed removed from the DMA-API.txt documentation back in 2010, saying that "driver writers are always able to use the DMA API with any bus": https://lkml.org/lkml/2010/3/8/470 On the other hand, I was under the impression that the PCI API is for (future?) platforms which may need a distinction between PCI and non-PCI. That is why the Xillybus driver does some acrobatics, so that the PCI API is used for PCI devices, and the general DMA API for non-PCI devices. Given that the distinction is already there, is it wise to remove it, and use the plain DMA API for all? That will simplify the code, of course, but if there's any esoteric platform that needs a different treatment for PCI devices, it's better to stay as is, I suppose. Thanks, Eli -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On Tue, Sep 02, 2014 at 12:03:42PM +0800, Jason Wang wrote: > On 09/01/2014 06:19 PM, Peter Zijlstra wrote: > > OK I suppose that more or less makes sense, the contextual behaviour is > > of course tedious in that it makes behaviour less predictable. The > > 'other' tasks might not want to generate data and you then destroy > > throughput by not spinning. > > The patch try to make sure: > - the the performance of busy read was not worse than it was disabled in > any cases. > - the performance improvement of a single socket was not achieved by > sacrificing the total performance (all other processes) of the system > > If 'other' tasks are also CPU or I/O intensive jobs, we switch to do > them so the total performance were kept or even increased, and the > performance of current process were guaranteed not worse than when busy > read was disabled (or even better since it may still do busy read > sometimes when it was the only runnable process). If 'other' task are > not intensive, they just do little work and sleep soon, then the busy > read can still work in most of the time during the future reads, we may > still get obvious improvements. Not entirely true; the select/poll whatever will now block, which means we need a wakeup, which increases the latency immensely. > > I'm not entirely sure I see how its all supposed to work though; the > > various poll functions call sk_busy_poll() and do_select() also loops. > > > > The patch only kills the sk_busy_poll() loop, but then do_select() will > > still loop and not sleep, so how is this helping? > > Yes, the patch only help for processes who did a blocking reads (busy > read). For select(), maybe we can do the same thing but need more test > and thoughts. What's the blocking read callgraph, how so we end up in sk_busy_poll() there? But that's another reason the patch is wrong. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/4] ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code.
On 09/02/2014 02:56 PM, Xiubo Li wrote:
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 61 -
1 file changed, 29 insertions(+), 32 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 986d2c7..cad2b30 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -163,6 +163,26 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
return 0;
}
+static inline unsigned int
+asoc_simple_card_fmt_master(struct device_node *np,
+ struct device_node *bitclkmaster,
+ struct device_node *framemaster)
+{
+ switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
+ case 0x11:
+ return SND_SOC_DAIFMT_CBS_CFS;
+ case 0x10:
+ return SND_SOC_DAIFMT_CBS_CFM;
+ case 0x01:
+ return SND_SOC_DAIFMT_CBM_CFS;
+ default:
+ return SND_SOC_DAIFMT_CBM_CFM;
+ }
+
+ /* Shouldn't be here */
+ return -EINVAL;
+}
It will be nice if we declare the switch case numbers as macros (specific
name)...
--
Regards,
Varka Bhadram.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 8/9] usb: chipidea: move usb_otg into struct ci_hdrc
On Tue, Sep 02, 2014 at 11:08:32AM +0200, Antoine Tenart wrote: > Hi, > > On Mon, Sep 01, 2014 at 09:13:43AM +0800, Peter Chen wrote: > > On Fri, Aug 29, 2014 at 04:25:35PM +0200, Antoine Tenart wrote: > > > On Tue, Aug 26, 2014 at 06:22:40PM +0800, Peter Chen wrote: > > > > On Fri, Aug 22, 2014 at 05:50:19PM +0200, Antoine Ténart wrote: > > > > > > > > If the common usb_otg and usb_phy struct still has another's pointer, > > > > you > > > > may not need to add this patch. > > > > > > Except if we want to access the OTG member when not using an USB PHY. > > > > If there is no USB PHY, the probe at core.c will turn error. > > I meant if we use a PHY from the common PHY framework (struct phy) and > not one from the USB one (struct usb_phy). The 'struct phy' does not > have a pointer to an OTG structure. > Ok, agree. -- Best Regards, Peter Chen -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 0/4] simple-card: simplify the code.
And comment and advice are welcome. Change in v2: - Maintian compatibility with the old DTs. Change in v1: - Add simple-card dts node patches. - Fix format parsing bug from Jean-Francois's comment. - Rebase to Kuninori-san's newest changes in next branch. Xiubo Li (4): ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code. ASoC: simple-card: Merge single and muti DAI link(s) code. ASoC: simple-card: Adjust the comments of simple card. ASoC: simple-card: binding: update binding to support the new style. .../devicetree/bindings/sound/simple-card.txt | 184 ++--- sound/soc/generic/simple-card.c| 131 --- 2 files changed, 191 insertions(+), 124 deletions(-) -- 1.8.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 2/4] ASoC: simple-card: Merge single and muti DAI link(s) code.
This patch will split the DT node into old style and new style:
The new style will merge the single DAI link and muti DAI links code
together, the new style will be easier to add muti DAI links from old
single DAI link DTs.
This patch will maintian compatibility with the old DTs.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index cad2b30..667fa49 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -198,6 +198,7 @@ static int asoc_simple_card_dai_link_of(struct device_node
*node,
char *prefix = "";
int ret;
+ /* For single DAI link & old style of DT node */
if (is_top_level_node)
prefix = "simple-audio-card,";
@@ -306,14 +307,16 @@ dai_link_of_err:
static int asoc_simple_card_parse_of(struct device_node *node,
struct simple_card_data *priv,
-struct device *dev,
-int multi)
+struct device *dev)
{
struct snd_soc_dai_link *dai_link = priv->snd_card.dai_link;
struct simple_dai_props *dai_props = priv->dai_props;
u32 val;
int ret;
+ if (!node)
+ return -EINVAL;
+
/* parsing the card name from DT */
snd_soc_of_parse_card_name(>snd_card, "simple-audio-card,name");
@@ -341,7 +344,8 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
dev_dbg(dev, "New simple-card: %s\n", priv->snd_card.name ?
priv->snd_card.name : "");
- if (multi) {
+ /* Single/Muti DAI link(s) & New style of DT node */
+ if (of_get_child_by_name(node, "simple-audio-card,dai-link")) {
struct device_node *np = NULL;
int i = 0;
@@ -358,6 +362,7 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
i++;
}
} else {
+ /* For single DAI link & old style of DT node */
ret = asoc_simple_card_dai_link_of(node, dev,
dai_link, dai_props, true);
if (ret < 0)
@@ -397,16 +402,13 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
struct snd_soc_dai_link *dai_link;
struct device_node *np = pdev->dev.of_node;
struct device *dev = >dev;
- int num_links, multi, ret;
+ int num_links, ret;
/* get the number of DAI links */
- if (np && of_get_child_by_name(np, "simple-audio-card,dai-link")) {
+ if (np && of_get_child_by_name(np, "simple-audio-card,dai-link"))
num_links = of_get_child_count(np);
- multi = 1;
- } else {
+ else
num_links = 1;
- multi = 0;
- }
/* allocate the private data and the DAI link array */
priv = devm_kzalloc(dev,
@@ -433,7 +435,7 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
if (np && of_device_is_available(np)) {
- ret = asoc_simple_card_parse_of(np, priv, dev, multi);
+ ret = asoc_simple_card_parse_of(np, priv, dev);
if (ret < 0) {
if (ret != -EPROBE_DEFER)
dev_err(dev, "parse error %d\n", ret);
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 4/4] ASoC: simple-card: binding: update binding to support the new style.
This update patch will split the DT node into old style and new style: The new style will will be easier to add muti DAI links from old single DAI link DTs. This patch will maintian compatibility with the old DTs. Signed-off-by: Xiubo Li --- .../devicetree/bindings/sound/simple-card.txt | 184 ++--- 1 file changed, 126 insertions(+), 58 deletions(-) diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt index c2e9841..6fb8966 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.txt +++ b/Documentation/devicetree/bindings/sound/simple-card.txt @@ -1,15 +1,19 @@ -Simple-Card: +Device-Tree bindings for Simple Card Simple-Card specifies audio DAI connections of SoC <-> codec. -Required properties: +=== Top level's properties and subnodes === +*** Required properties *** - compatible : "simple-audio-card" -Optional properties: - +*** Optional properties *** - simple-audio-card,name : User specified audio sound card name, one string property. +- simple-audio-card,format : CPU/CODEC common audio format. + "i2s", "right_j", "left_j" , "dsp_a" + "dsp_b", "ac97", "pdm", "msb", "lsb" + (This is used for single DAI link & old style.) - simple-audio-card,widgets: Please refer to widgets.txt. - simple-audio-card,routing: A list of the connections between audio components. Each entry is a pair of strings, the first being the @@ -17,63 +21,85 @@ Optional properties: source. - simple-audio-card,mclk-fs : Multiplication factor between stream rate and codec mclk. - -Optional subnodes: - -- simple-audio-card,dai-link : Container for dai-link level - properties and the CPU and CODEC - sub-nodes. This container may be - omitted when the card has only one - DAI link. See the examples and the - section bellow. - -Dai-link subnode properties and subnodes: - -If dai-link subnode is omitted and the subnode properties are directly -under "sound"-node the subnode property and subnode names have to be -prefixed with "simple-audio-card,"-prefix. - -Required dai-link subnodes: - -- cpu : CPU sub-node -- codec: CODEC sub-node - -Optional dai-link subnode properties: - +- simple-audio-card,frame-master : Indicates DAI link frame master. One phandle to a cpu + or codec subnode. + (This is used for single DAI link & old style.) +- simple-audio-card,bitclock-master: Indicates DAI link bit clock master. One phandle to a + cpu or codec subnode. + (This is used for single DAI link & old style.) + +*** Optional subnodes *** +- simple-audio-card,dai-link : Container for DAI link level properties and the CPU + and CODEC sub-nodes. This container may be omitted + when the card has only one DAI link and using the old + style. See the examples and the section bellow. +- simple-audio-card,cpu: CPU DAI sub-node. + (This is used for single DAI link & old style.) +- simple-audio-card,codec : CODEC DAI sub-node. + (This is used for single DAI link & old style.) + +=== DAI link node's properties and its subnodes === + +*** Required subnodes *** +- cpu : CPU DAI sub-node +- codec: CODEC DAI sub-node + +*** Optional properties *** - format : CPU/CODEC common audio format. "i2s", "right_j", "left_j" , "dsp_a" "dsp_b", "ac97", "pdm", "msb", "lsb" -- frame-master : Indicates dai-link frame master. - phandle to a cpu or codec subnode. -- bitclock-master : Indicates dai-link bit clock master. - phandle to a cpu or codec subnode. -- bitclock-inversion : bool property. Add this if the - dai-link uses bit
[PATCHv2 3/4] ASoC: simple-card: Adjust the comments of simple card.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 48 -
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 667fa49..e6976a0 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -120,7 +120,7 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
int ret;
/*
-* get node via "sound-dai = < port>"
+* Get node via "sound-dai = < port>"
* it will be used as xxx_of_node on soc_bind_dai_link()
*/
node = of_parse_phandle(np, "sound-dai", 0);
@@ -128,19 +128,19 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
return -ENODEV;
*p_node = node;
- /* get dai->name */
+ /* Get dai->name */
ret = snd_soc_of_get_dai_name(np, name);
if (ret < 0)
return ret;
- /* parse TDM slot */
+ /* Parse TDM slot */
ret = snd_soc_of_parse_tdm_slot(np, >slots, >slot_width);
if (ret)
return ret;
/*
-* dai->sysclk come from
-* "clocks = <>" (if system has common clock)
+* Parse dai->sysclk come from "clocks = <>"
+* (if system has common clock)
* or "system-clock-frequency = "
* or device's module clock.
*/
@@ -241,9 +241,11 @@ static int asoc_simple_card_dai_link_of(struct device_node
*node,
goto dai_link_of_err;
if (strlen(prefix) && !bitclkmaster && !framemaster) {
- /* No dai-link level and master setting was not found from
- sound node level, revert back to legacy DT parsing and
- take the settings from codec node. */
+ /*
+* No DAI link level and master setting was found
+* from sound node level, revert back to legacy DT
+* parsing and take the settings from codec node.
+*/
dev_dbg(dev, "%s: Revert to legacy daifmt parsing\n",
__func__);
dai_props->cpu_dai.fmt = dai_props->codec_dai.fmt =
@@ -260,10 +262,10 @@ static int asoc_simple_card_dai_link_of(struct
device_node *node,
goto dai_link_of_err;
}
- /* simple-card assumes platform == cpu */
+ /* Simple Card assumes platform == cpu */
dai_link->platform_of_node = dai_link->cpu_of_node;
- /* Link name is created from CPU/CODEC dai name */
+ /* DAI link name is created from CPU/CODEC dai name */
name = devm_kzalloc(dev,
strlen(dai_link->cpu_dai_name) +
strlen(dai_link->codec_dai_name) + 2,
@@ -285,11 +287,11 @@ static int asoc_simple_card_dai_link_of(struct
device_node *node,
dai_props->codec_dai.sysclk);
/*
-* soc_bind_dai_link() will check cpu name
-* after of_node matching if dai_link has cpu_dai_name.
-* but, it will never match if name was created by fmt_single_name()
-* remove cpu_dai_name to escape name matching.
-* see
+* In soc_bind_dai_link() will check cpu name after
+* of_node matching if dai_link has cpu_dai_name.
+* but, it will never match if name was created by
+* fmt_single_name() remove cpu_dai_name to escape
+* name matching. Please see:
* fmt_single_name()
* fmt_multiple_name()
*/
@@ -317,10 +319,10 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
if (!node)
return -EINVAL;
- /* parsing the card name from DT */
+ /* Parse the card name from DT */
snd_soc_of_parse_card_name(>snd_card, "simple-audio-card,name");
- /* off-codec widgets */
+ /* The off-codec widgets */
if (of_property_read_bool(node, "simple-audio-card,widgets")) {
ret = snd_soc_of_parse_audio_simple_widgets(>snd_card,
"simple-audio-card,widgets");
@@ -375,7 +377,7 @@ static int asoc_simple_card_parse_of(struct device_node
*node,
return 0;
}
-/* update the reference count of the devices nodes at end of probe */
+/* Decrease the reference count of the device nodes */
static int asoc_simple_card_unref(struct platform_device *pdev)
{
struct snd_soc_card *card = platform_get_drvdata(pdev);
@@ -404,29 +406,27 @@ static int asoc_simple_card_probe(struct platform_device
*pdev)
struct device *dev = >dev;
int num_links, ret;
- /* get the number of DAI links */
+ /* Get the number of DAI links */
if (np && of_get_child_by_name(np, "simple-audio-card,dai-link"))
num_links = of_get_child_count(np);
else
num_links = 1;
- /* allocate the private data and the DAI link array */
+
[PATCHv2 1/4] ASoC: simple-card: add asoc_simple_card_fmt_master() to simplify the code.
Signed-off-by: Xiubo Li
---
sound/soc/generic/simple-card.c | 61 -
1 file changed, 29 insertions(+), 32 deletions(-)
diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 986d2c7..cad2b30 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -163,6 +163,26 @@ asoc_simple_card_sub_parse_of(struct device_node *np,
return 0;
}
+static inline unsigned int
+asoc_simple_card_fmt_master(struct device_node *np,
+ struct device_node *bitclkmaster,
+ struct device_node *framemaster)
+{
+ switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
+ case 0x11:
+ return SND_SOC_DAIFMT_CBS_CFS;
+ case 0x10:
+ return SND_SOC_DAIFMT_CBS_CFM;
+ case 0x01:
+ return SND_SOC_DAIFMT_CBM_CFS;
+ default:
+ return SND_SOC_DAIFMT_CBM_CFM;
+ }
+
+ /* Shouldn't be here */
+ return -EINVAL;
+}
+
static int asoc_simple_card_dai_link_of(struct device_node *node,
struct device *dev,
struct snd_soc_dai_link *dai_link,
@@ -172,7 +192,7 @@ static int asoc_simple_card_dai_link_of(struct device_node
*node,
struct device_node *np = NULL;
struct device_node *bitclkmaster = NULL;
struct device_node *framemaster = NULL;
- unsigned int daifmt;
+ unsigned int daifmt, fmt;
char *name;
char prop[128];
char *prefix = "";
@@ -185,6 +205,7 @@ static int asoc_simple_card_dai_link_of(struct device_node
*node,
, );
daifmt &= ~SND_SOC_DAIFMT_MASTER_MASK;
+ /* Parse CPU DAI sub-node */
snprintf(prop, sizeof(prop), "%scpu", prefix);
np = of_get_child_by_name(node, prop);
if (!np) {
@@ -199,23 +220,11 @@ static int asoc_simple_card_dai_link_of(struct
device_node *node,
if (ret < 0)
goto dai_link_of_err;
- dai_props->cpu_dai.fmt = daifmt;
- switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
- case 0x11:
- dai_props->cpu_dai.fmt |= SND_SOC_DAIFMT_CBS_CFS;
- break;
- case 0x10:
- dai_props->cpu_dai.fmt |= SND_SOC_DAIFMT_CBS_CFM;
- break;
- case 0x01:
- dai_props->cpu_dai.fmt |= SND_SOC_DAIFMT_CBM_CFS;
- break;
- default:
- dai_props->cpu_dai.fmt |= SND_SOC_DAIFMT_CBM_CFM;
- break;
- }
-
+ fmt = asoc_simple_card_fmt_master(np, bitclkmaster, framemaster);
+ dai_props->cpu_dai.fmt = daifmt | fmt;
of_node_put(np);
+
+ /* Parse CODEC DAI sub-node */
snprintf(prop, sizeof(prop), "%scodec", prefix);
np = of_get_child_by_name(node, prop);
if (!np) {
@@ -240,21 +249,9 @@ static int asoc_simple_card_dai_link_of(struct device_node
*node,
snd_soc_of_parse_daifmt(np, NULL, NULL, NULL) |
(daifmt & ~SND_SOC_DAIFMT_CLOCK_MASK);
} else {
- dai_props->codec_dai.fmt = daifmt;
- switch (((np == bitclkmaster) << 4) | (np == framemaster)) {
- case 0x11:
- dai_props->codec_dai.fmt |= SND_SOC_DAIFMT_CBM_CFM;
- break;
- case 0x10:
- dai_props->codec_dai.fmt |= SND_SOC_DAIFMT_CBM_CFS;
- break;
- case 0x01:
- dai_props->codec_dai.fmt |= SND_SOC_DAIFMT_CBS_CFM;
- break;
- default:
- dai_props->codec_dai.fmt |= SND_SOC_DAIFMT_CBS_CFS;
- break;
- }
+ fmt = asoc_simple_card_fmt_master(np, bitclkmaster,
+ framemaster);
+ dai_props->codec_dai.fmt = daifmt | fmt;
}
if (!dai_link->cpu_dai_name || !dai_link->codec_dai_name) {
--
1.8.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
3.16/3.16.1: Kernel Oops in nft_do_chain
Calling 'iptables-compat -L', first time nothing is listed on the screen. Second try, it generates following Oops. See below the console dump and the disassembled code around the failing address root@vgoip:~# /usr/local/sbin/iptables-compat -L root@vgoip:~# /usr/local/sbin/iptables-compat -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination root@vgoip:~# [ 191.400860] Unable to handle kernel paging request for data at address 0x0008 [ 191.408022] Faulting instruction address: 0xc02f9924 [ 191.413126] Oops: Kernel access of bad area, sig: 11 [#1] [ 191.418245] PREEMPT CMPC885 [ 191.421002] Modules linked in: [ 191.424060] CPU: 0 PID: 69 Comm: irq/38-fs_enet- Not tainted 3.16.1 #236 [ 191.433166] task: c793ab50 ti: c7ff2000 task.ti: c79e4000 [ 191.438487] NIP: c02f9924 LR: c0365b54 CTR: c0365ae8 [ 191.443407] REGS: c7ff3b70 TRAP: 0300 Not tainted (3.16.1) [ 191.451554] MSR: 9032 CR: 28002082 XER: [ 191.458102] DAR: 0008 DSISR: c000 GPR00: 0300 c7ff3c20 c793ab50 c7ff3d98 c7a9d540 c791a000 c030db0c GPR08: c7ff3e28 0011 004e 005c 0044 GPR16: c7a9d590 c7ff3c80 fffc 0001 c7ff3c28 c7ff3c74 GPR24: c7a9d590 c7a9d590 c041252c c041242c c7ff3c30 c7ff3d98 [ 191.490095] NIP [c02f9924] nft_do_chain+0x438/0x4f4 [ 191.494890] LR [c0365b54] nft_do_chain_ipv4+0x6c/0x7c [ 191.499833] Call Trace: [ 191.502295] [c7ff3c20] [c02f9970] nft_do_chain+0x484/0x4f4 (unreliable) [ 191.508830] [c7ff3d90] [c0365b54] nft_do_chain_ipv4+0x6c/0x7c [ 191.514514] [c7ff3de0] [c02e134c] nf_iterate+0xe4/0x12c [ 191.519673] [c7ff3e20] [c02e15c8] nf_hook_slow+0xa0/0x1f4 [ 191.525034] [c7ff3e60] [c030dd70] ip_local_deliver+0xa0/0xac [ 191.530613] [c7ff3e70] [c030d4f4] ip_rcv_finish+0x130/0x350 [ 191.536128] [c7ff3e90] [c02b5304] __netif_receive_skb_core+0x4c4/0x600 [ 191.542595] [c7ff3ef0] [c0237824] fs_enet_rx_napi+0x30c/0x448 [ 191.548252] [c7ff3f50] [c02b5c38] net_rx_action+0x140/0x20c [ 191.553771] [c7ff3f90] [c001c918] __do_softirq+0x13c/0x2b4 [ 191.559177] [c7ff3ff0] [c000b660] call_do_softirq+0x24/0x3c [ 191.564696] [c79e5e50] [c0003e04] do_softirq_own_stack+0x3c/0x7c [ 191.570625] [c79e5e70] [c001c7d8] do_softirq+0x58/0x5c [ 191.575705] [c79e5e80] [c001cd34] __local_bh_enable_ip+0xa0/0xc4 [ 191.581649] [c79e5e90] [c00525cc] irq_forced_thread_fn+0x64/0x84 [ 191.587577] [c79e5eb0] [c00521fc] irq_thread+0x130/0x188 [ 191.592848] [c79e5ef0] [c0039190] kthread+0xd0/0xe4 [ 191.597651] [c79e5f40] [c000c6d0] ret_from_kernel_thread+0x5c/0x64 [ 191.603706] Instruction dump: [ 191.606636] 83210014 4bfffc90 813f 80090060 74090001 40820070 54290024 8009000c [ 191.614294] 3200 9009000c 8130fff8 3960 <80690008> 8089000c 80a9 31040001 [ 191.622147] ---[ end trace 86fcabb2513eb932 ]--- [ 191.626687] [ 192.599223] Kernel panic - not syncing: Fatal exception in interrupt [ 192.605305] Rebooting in 180 seconds.. if (unlikely(pkt->skb->nf_trace)) c02f98fc:81 3f 00 00 lwz r9,0(r31) c02f9900:80 09 00 60 lwz r0,96(r9) c02f9904:74 09 00 01 andis. r9,r0,1 c02f9908:40 82 00 70 bne-c02f9978 c02f990c:54 29 00 24 rlwinm r9,r1,0,0,18 c02f9910:80 09 00 0c lwz r0,12(r9) c02f9914:30 00 02 00 addic r0,r0,512 c02f9918:90 09 00 0c stw r0,12(r9) nft_trace_packet(pkt, basechain, -1, NFT_TRACE_POLICY); rcu_read_lock_bh(); stats = this_cpu_ptr(rcu_dereference(nft_base_chain(basechain)->stats)); c02f991c:81 30 ff f8 lwz r9,-8(r16) u64_stats_update_begin(>syncp); stats->pkts++; stats->bytes += pkt->skb->len; c02f9920:39 60 00 00 li r11,0 nft_trace_packet(pkt, basechain, -1, NFT_TRACE_POLICY); rcu_read_lock_bh(); stats = this_cpu_ptr(rcu_dereference(nft_base_chain(basechain)->stats)); u64_stats_update_begin(>syncp); stats->pkts++; ==> c02f9924:80 69 00 08 lwz r3,8(r9) c02f9928:80 89 00 0c lwz r4,12(r9) stats->bytes += pkt->skb->len; c02f992c:80 a9 00 00 lwz r5,0(r9) nft_trace_packet(pkt, basechain, -1, NFT_TRACE_POLICY); rcu_read_lock_bh(); stats = this_cpu_ptr(rcu_dereference(nft_base_chain(basechain)->stats)); u64_stats_update_begin(>syncp); stats->pkts++; c02f9930:31 04 00 01 addic r8,r4,1 c02f9934:7c e3 01 94 addze r7,r3 c02f9938:90 e9 00 08 stw r7,8(r9) c02f993c:91 09 00 0c stw r8,12(r9) stats->bytes += pkt->skb->len; c02f9940:80 c9 00 04 lwz r6,4(r9) c02f9944:81 5f 00 00 lwz r10,0(r31) __local_bh_enable_ip(ip, SOFTIRQ_DISABLE_OFFSET); } Christophe -- To unsubscribe from this
Re: [PATCH v4 0/2] tty: serial: Add mediatek UART driver
2014-08-12 16:12 GMT+02:00 Matthias Brugger : > This patch set adds support for the UART found in Mediatek SoCs. > The chip is a changed version of a 8250 controller. > Especially it introduces a new register called highspeed. The value > in this register has to be set depending on the baudrate. The value > in the register influences the way the divisor has to be calculated. > > The patch series is build against v3.16-rc1 and tested on mt6589. Should > work as well on mt6577 and mt6582. > > Thanks, > Matthias Ping: Does anyone has any comment on this series? Sorry, last mail was HTML by accident. > > Changes for v4: > - delete owner in platform driver instance > - pass plattform_device to mtk8250_probe_of > - reorganise probe function to error out early > - Fix DTS documentation > > Changes for v3: > - use dev_warn instead of pr_warn > - use 8250_core function to update termios > > Changes for v2: > - drop 8250_core capability extension for the chip > - encapsulate set_termios in the driver method > > --- > > Matthias Brugger (2): > tty: serial: 8250: Add Mediatek UART driver > DTS: serial: Add bindings documention for the Mediatek UARTs > > .../devicetree/bindings/serial/mtk-uart.txt| 20 ++ > drivers/tty/serial/8250/8250_mtk.c | 294 > > drivers/tty/serial/8250/Kconfig|7 + > drivers/tty/serial/8250/Makefile |1 + > 4 files changed, 322 insertions(+) > create mode 100644 Documentation/devicetree/bindings/serial/mtk-uart.txt > create mode 100644 drivers/tty/serial/8250/8250_mtk.c > > -- > 1.7.9.5 > -- motzblog.wordpress.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net v2] ipv6: fix rtnl locking in setsockopt for anycast and multicast
On Di, 2014-09-02 at 10:29 +0200, Sabrina Dubroca wrote: > Calling setsockopt with IPV6_JOIN_ANYCAST or IPV6_LEAVE_ANYCAST > triggers the assertion in addrconf_join_solict()/addrconf_leave_solict() > > ipv6_sock_ac_join(), ipv6_sock_ac_drop(), ipv6_sock_ac_close() need to > take RTNL before calling ipv6_dev_ac_inc/dec. Same thing with > ipv6_sock_mc_join(), ipv6_sock_mc_drop(), ipv6_sock_mc_close() before > calling ipv6_dev_mc_inc/dec. > > This patch moves ASSERT_RTNL() up a level in the call stack. > > Signed-off-by: Cong Wang > Signed-off-by: Sabrina Dubroca > Reported-by: Tommi Rantala > --- > As was said earlier, this should go in stable. > > v2: > - based on net > - keep dev_get_by_flags_rcu and RCU in ipv6_sock_ac_* > - remove two ASSERT_RTNL() that are not necessary > > Thank you for your help, Hannes! Thanks for fixing! ;) Acked-by: Hannes Frederic Sowa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/1] drivers: introduce ARM SBSA generic UART driver
Hi Rob, thanks for looking at this. On 02/09/14 04:06, Rob Herring wrote: > On Fri, Aug 29, 2014 at 11:13 AM, Andre Przywara > wrote: >> The ARM Server Base System Architecture (SBSA) describes a generic >> UART which all compliant level 1 systems should implement. This is >> actually a PL011 subset, so a full PL011 implementation will satisfy >> this requirement. >> However if a system does not have a PL011, a very stripped down >> implementation complying to the SBSA defined specification will >> suffice. The Linux PL011 driver is not guaranteed to drive this >> limited device (and indeed the fast model implentation hangs the >> kernel if driven by the PL011 driver). >> So introduce a new driver just implementing the part specified by the >> SBSA (which lacks DMA, the modem control signals and many of the >> registers including baud rate control). This driver has been derived >> by the actual PL011 one, removing all unnecessary code. >> >> Signed-off-by: Andre Przywara >> --- >> .../devicetree/bindings/serial/arm_sbsa_uart.txt |6 + >> drivers/tty/serial/Kconfig | 28 + >> drivers/tty/serial/Makefile|1 + >> drivers/tty/serial/sbsa_uart.c | 793 >> >> include/uapi/linux/serial_core.h |1 + > > Sorry, but I think this is all wrong. We've now just duplicated some > subset of the pl011 driver leaving out the parts like setting baudrate > which can never be added since those things could be different for > every vendor. > > The original intent of the SBSA uart was to provide a common early > debug uart. It was not to have a full fledged driver. I think the SBSA > has failed in this area and created the potential to create a mess of > serial drivers different for every vendor. Reality will hopefully not > be that extreme and most vendors will just use the pl011 and create > their value add somewhere besides the uart. For the purpose of debug > output, we already support that as the pl011 earlycon only touches > SBSA compatible registers. I see your point (and was actually looking for those kind of comments when posting this). I agree to that debug aspect and understand that earlycon already does this, but I think we need some support beyond earlycon, to be able to login and use it as a console (which is not possible with earlycon, right?) This is probably still for debugging or emergency access to the system only, but maybe also for logging - actually quite similar to how UARTs are used on today's x86 servers. So after having written three incarnations of this driver (goldfish based, PL010 based, PL011 based) I wonder if supporting the SBSA subset in the real PL011 driver is an option. Either this would be enabled by a new explicit DT property or preferably by a clever compatible string. Ideally we would just provide a different set of "struct uart_ops" members, with some pointing to generic PL011 routines, some to SBSA UART specific ones. Maybe we make the full featured PL011 support a config option (defaulting to y), allowing people to only use the SBSA subset in their kernel? Does that make more sense? (for a general SBSA h/w rationale see below) >> 5 files changed, 829 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt >> create mode 100644 drivers/tty/serial/sbsa_uart.c >> >> diff --git a/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt >> b/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt >> new file mode 100644 >> index 000..8e2c5d6 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/serial/arm_sbsa_uart.txt >> @@ -0,0 +1,6 @@ >> +* ARM SBSA defined generic UART >> + >> +Required properties: >> +- compatible: must be "arm,sbsa-uart" > > This alone is not okay. There is no such implementation of hardware. But the SBSA explicitly allows this. I don't know of any vendor who just implements the subset, but I've been told that this has been asked for. > The DT must specify the implementation such as pl011. If it is a full featured PL011: sure. Then we don't need this driver at all and just use the SBSA UART spec as a guideline for our earlycon implementation. I will try to learn if there is someone actually implementing only the subset. Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] drm/i915: Fix lock dropping in intel_tv_detect()
From: Ville Syrjälä
When intel_tv_detect() fails to do load detection it would forget to
drop the locks and clean up the acquire context. Fix it up.
This is a regression from:
commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44
Author: Ville Syrjälä
Date: Mon Aug 11 13:15:35 2014 +0300
drm/i915: Fix locking for intel_enable_pipe_a()
v2: Make the code more readable (Chris)
v3: Drop WARN_ON(type < 0) (Chris)
Cc: sta...@vger.kernel.org
Cc: Tibor Billes
Reported-by: Tibor Billes
Tested-by: Tibor Billes
Reviewed-by: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_tv.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 32186a6..c69d3ce 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
+++ b/drivers/gpu/drm/i915/intel_tv.c
@@ -1311,6 +1311,7 @@ intel_tv_detect(struct drm_connector *connector, bool
force)
{
struct drm_display_mode mode;
struct intel_tv *intel_tv = intel_attached_tv(connector);
+ enum drm_connector_status status;
int type;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force=%d\n",
@@ -1328,16 +1329,19 @@ intel_tv_detect(struct drm_connector *connector, bool
force)
if (intel_get_load_detect_pipe(connector, , , )) {
type = intel_tv_detect_type(intel_tv, connector);
intel_release_load_detect_pipe(connector, );
+ status = type < 0 ?
+ connector_status_disconnected :
+ connector_status_connected;
} else
- return connector_status_unknown;
+ status = connector_status_unknown;
drm_modeset_drop_locks();
drm_modeset_acquire_fini();
} else
return connector->status;
- if (type < 0)
- return connector_status_disconnected;
+ if (status != connector_status_connected)
+ return status;
intel_tv->type = type;
intel_tv_find_better_format(connector);
--
1.8.5.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Aug 23
On Tue, Sep 02, 2014 at 11:40:16AM +0200, Peter Zijlstra wrote: > On Mon, Sep 01, 2014 at 09:04:38PM +0200, Peter Zijlstra wrote: > > On Mon, Sep 01, 2014 at 09:46:42AM -0700, Guenter Roeck wrote: > > > Yes, the problem is still seen in next-140829. See qemu test results at > > > http://server.roeck-us.net:8010/builders. > > > > > > I provided sparc64 images at http://server.roeck-us.net/qemu/sparc64/. > > > The README file includes instructions on how to run the image in qemu > > > and how to build a kernel. > > > > > > I can do the same for mips and mips64 if needed; let me know. > > > > Thanks, that's enough to get started. > > This makes sparc64 go again, silly oversight indeed. > The same for mips. Can you either provide the mips image or verify this works? --- diff --git a/arch/mips/include/asm/atomic.h b/arch/mips/include/asm/atomic.h index 476fe3b..b3dd612 100644 --- a/arch/mips/include/asm/atomic.h +++ b/arch/mips/include/asm/atomic.h @@ -93,7 +93,7 @@ static __inline__ int atomic_##op##_return(int i, atomic_t * v) \ " " #asm_op " %0, %1, %3 \n" \ " sc %0, %2 \n" \ " beqzl %0, 1b \n" \ - " addu%0, %1, %3 \n" \ + " " #asm_op " %0, %1, %3 \n" \ " .setmips0 \n" \ : "=" (result), "=" (temp), "+m" (v->counter) \ : "Ir" (i)); \ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/2] r8152: use eth_hw_addr_random
If the hw doesn't have a valid MAC address, give a random one and
set it to the hw.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 39 ---
1 file changed, 24 insertions(+), 15 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index b5ff933..2bc1b8d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -992,32 +992,41 @@ static int rtl8152_set_mac_address(struct net_device
*netdev, void *p)
return 0;
}
-static inline void set_ethernet_addr(struct r8152 *tp)
+static int set_ethernet_addr(struct r8152 *tp)
{
struct net_device *dev = tp->netdev;
+ struct sockaddr sa;
int ret;
- u8 node_id[8] = {0};
if (tp->version == RTL_VER_01)
- ret = pla_ocp_read(tp, PLA_IDR, sizeof(node_id), node_id);
+ ret = pla_ocp_read(tp, PLA_IDR, 8, sa.sa_data);
else
- ret = pla_ocp_read(tp, PLA_BACKUP, sizeof(node_id), node_id);
+ ret = pla_ocp_read(tp, PLA_BACKUP, 8, sa.sa_data);
if (ret < 0) {
- netif_notice(tp, probe, dev, "inet addr fail\n");
+ netif_err(tp, probe, dev, "Get ether addr fail\n");
+ } else if (!is_valid_ether_addr(sa.sa_data)) {
+ netif_err(tp, probe, dev,
+ "Invalid ether addr %02x:%02x:%02x:%02x:%02x:%02x\n",
+ sa.sa_data[0], sa.sa_data[1], sa.sa_data[2],
+ sa.sa_data[3], sa.sa_data[4], sa.sa_data[5]);
+ eth_hw_addr_random(dev);
+ ether_addr_copy(sa.sa_data, dev->dev_addr);
+ ret = rtl8152_set_mac_address(dev, );
+ netif_info(tp, probe, dev,
+ "Random ether addr %02x:%02x:%02x:%02x:%02x:%02x\n",
+ sa.sa_data[0], sa.sa_data[1], sa.sa_data[2],
+ sa.sa_data[3], sa.sa_data[4], sa.sa_data[5]);
} else {
- if (tp->version != RTL_VER_01) {
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR,
- CRWECR_CONFIG);
- pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES,
- sizeof(node_id), node_id);
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR,
- CRWECR_NORAML);
- }
+ if (tp->version == RTL_VER_01)
+ ether_addr_copy(dev->dev_addr, sa.sa_data);
+ else
+ ret = rtl8152_set_mac_address(dev, );
- memcpy(dev->dev_addr, node_id, dev->addr_len);
- memcpy(dev->perm_addr, dev->dev_addr, dev->addr_len);
+ ether_addr_copy(dev->perm_addr, dev->dev_addr);
}
+
+ return ret;
}
static void read_bulk_callback(struct urb *urb)
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 1/2] r8152: change the location of rtl8152_set_mac_address
Exchange the location of rtl8152_set_mac_address() and
set_ethernet_addr(). Then, the set_ethernet_addr() could
set the MAC address by calling rtl8152_set_mac_address()
later.
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 80b0179..b5ff933 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -975,6 +975,23 @@ void write_mii_word(struct net_device *netdev, int phy_id,
int reg, int val)
static int
r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags);
+static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
+{
+ struct r8152 *tp = netdev_priv(netdev);
+ struct sockaddr *addr = p;
+
+ if (!is_valid_ether_addr(addr->sa_data))
+ return -EADDRNOTAVAIL;
+
+ memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
+
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
+ pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES, 8, addr->sa_data);
+ ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
+
+ return 0;
+}
+
static inline void set_ethernet_addr(struct r8152 *tp)
{
struct net_device *dev = tp->netdev;
@@ -1003,23 +1020,6 @@ static inline void set_ethernet_addr(struct r8152 *tp)
}
}
-static int rtl8152_set_mac_address(struct net_device *netdev, void *p)
-{
- struct r8152 *tp = netdev_priv(netdev);
- struct sockaddr *addr = p;
-
- if (!is_valid_ether_addr(addr->sa_data))
- return -EADDRNOTAVAIL;
-
- memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
-
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_CONFIG);
- pla_ocp_write(tp, PLA_IDR, BYTE_EN_SIX_BYTES, 8, addr->sa_data);
- ocp_write_byte(tp, MCU_TYPE_PLA, PLA_CRWECR, CRWECR_NORAML);
-
- return 0;
-}
-
static void read_bulk_callback(struct urb *urb)
{
struct net_device *netdev;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 0/2] r8152: random MAC address
If the interface has invalid MAC address, it couldn't be used. In order to let it work normally, give a random one. Hayes Wang (2): r8152: change the location of rtl8152_set_mac_address r8152: use eth_hw_addr_random drivers/net/usb/r8152.c | 65 - 1 file changed, 37 insertions(+), 28 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: calxedaxgmac: fix driver dependencies
Hi, On Monday, September 01, 2014 09:36:39 PM Rob Herring wrote: > On Mon, Sep 1, 2014 at 10:39 AM, Bartlomiej Zolnierkiewicz > wrote: > > Calxeda 1G/10G XGMAC Ethernet support should be available only on > > Calxeda ECX-1000/2000 (Highbank/Midway) platforms. > > > > Signed-off-by: Bartlomiej Zolnierkiewicz > > Acked-by: Kyungmin Park > > Cc: Rob Herring > > --- > > drivers/net/ethernet/calxeda/Kconfig |1 + > > 1 file changed, 1 insertion(+) > > > > Index: b/drivers/net/ethernet/calxeda/Kconfig > > === > > --- a/drivers/net/ethernet/calxeda/Kconfig 2014-07-30 > > 14:31:12.159522474 +0200 > > +++ b/drivers/net/ethernet/calxeda/Kconfig 2014-09-01 > > 17:33:49.232810483 +0200 > > @@ -1,6 +1,7 @@ > > config NET_CALXEDA_XGMAC > > tristate "Calxeda 1G/10G XGMAC Ethernet driver" > > depends on HAS_IOMEM && HAS_DMA > > + depends on ARCH_HIGHBANK || COMPILE_TEST > > Opinions differ on whether drivers should be restricted in this way. > There is no actual dependency requiring ARCH_HIGHBANK. So I leave it > to David. The hardware is specific to ARCH_HIGHBANK and it is just unavailble on any other platform (i.e. I have completely no use for this option on ARM Exynos platform). In such cases we restrict drivers to the specific hardware platform so they don't pollute configs for other platforms (i.e. this option is enabled by default in multi_v7_defconfig and once I go from multi defconfing to single platform one, the option stays enabled). Best regards, -- Bartlomiej Zolnierkiewicz Samsung R Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 20/41] perf tools: Let a user specify a PMU event without any config terms
On Tue, Sep 02, 2014 at 08:39:56AM +0300, Adrian Hunter wrote: SNIP > >>> -e intel_pt/tsc=1,noretcomp=0/ > >>> > >>> I guess I wanted to hear more elaboration why is this better > >>> than the current way we have by defining an alias, like: > >>> > >>> krava alias: "tsc=1,noretcomp=0" > >>> > >>> -e intel_pt/krava/ > >>> > >>> which gives the same result > >> > >> The default value must be provided by perf tools not the kernel e.g. > >> an older version of perf tools will not be aware of new hardware > >> features that the kernel may know about. If the kernel enables > >> new features by default then the tool may fail. Thus the default > >> value has to be under the control of the tools not the kernel, so > >> a sysfs alias will not work. > >> > > > > I dont follow, could u provide some example? > > Imagine that the 'tsc' term did not exist. Intel PT trace data > would not contain TSC packets, and the decoder would not know how to > decode them. Then imagine that a new version of the hardware adds > 'tsc'. It is such a useful feature that we want it by default, but > older versions of the tools don't know how to decode it, so the > kernel cannot turn it on by default. > > > > > why the tool needs to understand.. it will just take the alias > > and apply/use it? The alias follows the format logic, which tells > > how to apply values on perf_event_attr.. and the kernel knows best > > what's supported in its version.. > > It is similar to why the kernel does not select mmap2 by default. The > kernel doesn't know whether the tool supports it. > ook, could you please add some kind of this explanation to the changelog? thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Aug 23
On Mon, Sep 01, 2014 at 09:04:38PM +0200, Peter Zijlstra wrote:
> On Mon, Sep 01, 2014 at 09:46:42AM -0700, Guenter Roeck wrote:
> > Yes, the problem is still seen in next-140829. See qemu test results at
> > http://server.roeck-us.net:8010/builders.
> >
> > I provided sparc64 images at http://server.roeck-us.net/qemu/sparc64/.
> > The README file includes instructions on how to run the image in qemu
> > and how to build a kernel.
> >
> > I can do the same for mips and mips64 if needed; let me know.
>
> Thanks, that's enough to get started.
This makes sparc64 go again, silly oversight indeed.
---
Subject: sparc64: Fix atomics
The patch folding the atomic ops had a silly fail in the _return primitives.
Fixes: 4f3316c2b5fe ("locking,arch,sparc: Fold atomic_ops")
Signed-off-by: Peter Zijlstra (Intel)
---
diff --git a/arch/sparc/lib/atomic_64.S b/arch/sparc/lib/atomic_64.S
index 96d70b4..05dac43 100644
--- a/arch/sparc/lib/atomic_64.S
+++ b/arch/sparc/lib/atomic_64.S
@@ -37,7 +37,7 @@ ENTRY(atomic_##op##_return) /* %o0 = increment, %o1 =
atomic_ptr */ \
cas [%o1], %g1, %g7;\
cmp %g1, %g7; \
bne,pn %icc, BACKOFF_LABEL(2f, 1b);\
-add%g1, %o0, %g1; \
+op %g1, %o0, %g1; \
retl; \
sra%g1, 0, %o0;\
2: BACKOFF_SPIN(%o2, %o3, 1b); \
@@ -76,7 +76,7 @@ ENTRY(atomic64_##op##_return) /* %o0 = increment, %o1 =
atomic_ptr */ \
bne,pn %xcc, BACKOFF_LABEL(2f, 1b);\
nop; \
retl; \
-add%g1, %o0, %o0; \
+op %g1, %o0, %o0; \
2: BACKOFF_SPIN(%o2, %o3, 1b); \
ENDPROC(atomic64_##op##_return);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 03/12] of: Add binding document for MIPS GIC
On Tue, Sep 02, 2014 at 01:53:18AM +0100, Andrew Bresticker wrote:
> On Mon, Sep 1, 2014 at 4:01 AM, Mark Rutland wrote:
> > On Fri, Aug 29, 2014 at 11:14:30PM +0100, Andrew Bresticker wrote:
> >> The Global Interrupt Controller (GIC) present on certain MIPS systems
> >> can be used to route external interrupts to individual VPEs and CPU
> >> interrupt vectors. It also supports a timer and software-generated
> >> interrupts.
> >>
> >> Signed-off-by: Andrew Bresticker
> >> ---
> >> Documentation/devicetree/bindings/mips/gic.txt | 50
> >> ++
> >> 1 file changed, 50 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/mips/gic.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/mips/gic.txt
> >> b/Documentation/devicetree/bindings/mips/gic.txt
> >> new file mode 100644
> >> index 000..725f1ef
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/mips/gic.txt
> >> @@ -0,0 +1,50 @@
> >> +MIPS Global Interrupt Controller (GIC)
> >> +
> >> +The MIPS GIC routes external interrupts to individual VPEs and IRQ pins.
> >> +It also supports a timer and software-generated interrupts which can be
> >> +used as IPIs.
> >> +
> >> +Required properties:
> >> +- compatible : Should be "mti,global-interrupt-controller"
> >
> > I couldn't find "mti" in vendor-prefixes.txt (as of v3.17-rc3). If
> > there's not a patch to add it elsewhere, would you mind providing one
> > with this series?
>
> Sure. As James points out, "img" could also be used but I chose "mti"
> since the CPU interrupt controller also uses "mti" and I believe the
> GIC IP was developed before the acquisition by Imagination (though I'm
> not sure if that actually matters).
Using 'mti' sounds like the right choice to me given both of those
points.
> >> +- reg : Base address and length of the GIC registers.
> >> +- interrupts : Core interrupts to which the GIC may route external
> >> interrupts.
> >
> > How many?
>
> Up to 6, one for each of the possible core hardware interrupts (i.e.
> interrupt vectors 2 - 7). Which ones are available to the GIC depend
> on the system, for example Malta has an i8259 PIC hooked up to CPU
> interrupt vector 2, so that vector should not be used by the GIC.
>
> > In any order?
>
> They can technically be in any order, but when in strictly
> increasing/decreasing order they can be used along with the 3rd cell
> (described below) to prioritize interrupts.
Ok. Could you try to place that into the property description?
> >> +- interrupt-controller : Identifies the node as an interrupt controller
> >> +- #interrupt-cells : Specifies the number of cells needed to encode an
> >> + interrupt specifier. Should be 3.
> >> + - The first cell is the GIC interrupt number.
> >> + - The second cell encodes the interrupt flags.
> >> +See for a list of
> >> valid
> >> +flags.
> >
> > Are all the flags valid for this interrupt controller?
>
> Yes.
Ok.
> >> + - The optional third cell indicates which CPU interrupt vector the GIC
> >> +interrupt should be routed to. It is a 0-based index into the list of
> >> +GIC-to-CPU interrupts specified in the "interrupts" property described
> >> +above. For example, a '2' in this cell will route the interrupt to
> >> the
> >> +3rd core interrupt listed in 'interrupts'. If omitted, the interrupt
> >> will
> >> +be routed to the 1st core interrupt.
> >
> > I don't follow why this should be in the DT. Why is this necessary?
>
> Since the GIC can route external interrupts to any of the CPU hardware
> interrupt vectors, it can be used to assign priorities to external
> interrupts. If the CPU is in vectored interrupt mode, the highest
> numbered interrupt vector (7) has the highest priority. An example:
>
> gic: interrupt-controller@1bdc {
> ...
> interrupts = <3>, <4>;
> ...
> };
>
> uart {
> ...
> interrupt-parent = <>;
> interrupts = <24 IRQ_TYPE_LEVEL_HIGH 1>;
> ...
> };
>
> i2c {
> ...
> interrupt-parent = <>;
> interrupts = <33 IRQ_TYPE_LEVEL_HIGH 0>;
> ...
> };
>
> Since the third cell for the UART is '1', it maps to CPU interrupt
> vector 4 and thus has a higher priority than the I2C (whose third cell
> is 0, mapping to CPU interrupt vector 3).
>
> Perhaps, though, this is an instance of software policy being
> specified in device-tree. Other options would be to a) evenly
> distribute the GIC external interrupts across the CPU interrupt
> vectors available to the GIC, or b) just map all GIC external
> interrupts to a single interrupt vector.
As a user I don't see why the DT author should be in charge of whether
my UART gets higher priority than my I2C controller. That priority is
not a fixed property of the interrupt (as the line and flags are).
That said, this is a grey area. Are there any cases where this
prioritisation is critical on existing devices?
> > I also don't follow how
Re: [PATCH v6 2/6] arm64: ptrace: allow tracer to skip a system call
On Tue, Sep 02, 2014 at 10:16:22AM +0100, Russell King - ARM Linux wrote: > On Tue, Sep 02, 2014 at 05:47:29PM +0900, AKASHI Takahiro wrote: > > On 09/01/2014 08:47 PM, Russell King - ARM Linux wrote: > >> On Wed, Aug 27, 2014 at 02:55:46PM +0900, AKASHI Takahiro wrote: > >>> 1) > >>> setting x0 to -ENOSYS is necessary because, otherwise, user-issued > >>> syscall(-1) will > >>> return a bogus value when audit tracing is on. > >>> > >>> Please note that, on arm, > >>> not traced traced > >>> -- -- > >>> syscall(-1) aborted OOPs(BUG_ON) > >>> syscall(-3000) aborted aborted > >>> syscall(1000)ENOSYS ENOSYS > >> > >> Two points here: > >> > >> 1. You've found a case which causes a BUG_ON(). Where is the bug report > >> for this, so the problem can be investigated and resolved? > > > > I think that I mentioned it could also happen on arm somewhere in a talk > > with Will, but don't remember exactly when. > > Sorry, not good enough. Please report this bug so it can be investigated > and fixed. I'm going to go further than this, and tell you that you have been downright irresponsible here, and I'm disgusted by your behaviour over this. You have revealed a potential security problem publically, effectively giving details about how to cause it, but without having first reported it to people who can fix it, nor providing a fix for it. Why is it a security problem? Although it can't be used to gain information, it can be used potentially to deny service. Any user can trace a task which they own, and then set the task's syscall to -1, which according to you results in a kernel oops. If the kernel oops happens while holding any locks, that part of the system becomes non-functional and can result in all userland stopping dead. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/3] iio: accel: BMC150: add support for other Bosch chips
The following chips are either similar or have only the resolution
different. Hence, change this driver to support these chips too:
BMI055 - combo chip (accelerometer part is identical to BMC150's)
BMA255 - identical to BMC150's accelerometer
BMA222E - 8 bit resolution
BMA250E - 10 bit resolution
BMA280 - 14 bit resolution
Additionally:
* add bmc150_accel_match_acpi_device() function to check that the device
has been enumerated through ACPI;
* rename bmc150_accel_acpi_gpio_probe() to bmc150_accel_gpio_probe()
since the ACPI matching has been moved to the new function. Also, this
will allow for the GPIO matching to be done against a device tree too, not
only
ACPI tree;
* rename bmc150_scale_info struct member 'range' to 'reg_range' to be
consistent with the naming convention used elsewhere in the driver
and declare it u8, instead of int;
* change CONFIG description to list all supported chips;
Signed-off-by: Laurentiu Palcu
---
Changes in v5:
* addressed Joe's suggestion to rewrite a small portion of the code to make it
more readable;
* changed the CONFIG description according to Srinivas's advise;
Changes in v4:
* address Peter's comments: see 3rd bullet in the commit's message. As a
result, do
some re-indentation to make lines fit 80 chars;
Changes in v3:
* remove the chip id macros since they were not used anywhere else and put the
id
values directly in the chip info table;
* fix the unnecessary casting from const char * to char * and back;
laurentiu
drivers/iio/accel/Kconfig| 4 +-
drivers/iio/accel/bmc150-accel.c | 234 +--
2 files changed, 178 insertions(+), 60 deletions(-)
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 01b857e..01a2151 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -23,7 +23,9 @@ config BMC150_ACCEL
select IIO_BUFFER
select IIO_TRIGGERED_BUFFER
help
- Say yes here to build support for the Bosch BMC150 accelerometer.
+ Say yes here to build support for the following Bosch accelerometers:
+ BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
+
Currently this only supports the device via an i2c interface.
This is a combo module with both accelerometer and magnetometer.
diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
index 0e6566a..22c096c 100644
--- a/drivers/iio/accel/bmc150-accel.c
+++ b/drivers/iio/accel/bmc150-accel.c
@@ -1,5 +1,12 @@
/*
- * BMC150 3-axis accelerometer driver
+ * 3-axis accelerometer driver supporting following Bosch-Sensortec chips:
+ * - BMC150
+ * - BMI055
+ * - BMA255
+ * - BMA250E
+ * - BMA222E
+ * - BMA280
+ *
* Copyright (c) 2014, Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify it
@@ -34,7 +41,6 @@
#define BMC150_ACCEL_GPIO_NAME "bmc150_accel_int"
#define BMC150_ACCEL_REG_CHIP_ID 0x00
-#define BMC150_ACCEL_CHIP_ID_VAL 0xFA
#define BMC150_ACCEL_REG_INT_STATUS_2 0x0B
#define BMC150_ACCEL_ANY_MOTION_MASK 0x07
@@ -126,6 +132,18 @@ enum bmc150_power_modes {
BMC150_ACCEL_SLEEP_MODE_SUSPEND = 0x04,
};
+struct bmc150_scale_info {
+ int scale;
+ u8 reg_range;
+};
+
+struct bmc150_accel_chip_info {
+ u8 chip_id;
+ const struct iio_chan_spec *channels;
+ int num_channels;
+ const struct bmc150_scale_info scale_table[4];
+};
+
struct bmc150_accel_data {
struct i2c_client *client;
struct iio_trigger *dready_trig;
@@ -140,6 +158,7 @@ struct bmc150_accel_data {
bool dready_trigger_on;
bool motion_trigger_on;
int64_t timestamp;
+ const struct bmc150_accel_chip_info *chip_info;
};
static const struct {
@@ -168,16 +187,8 @@ static const struct {
{0x0F, 1} };
static const struct {
- int scale;
- int range;
-} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
-{19122, BMC150_ACCEL_DEF_RANGE_4G},
-{38344, BMC150_ACCEL_DEF_RANGE_8G},
-{76590, BMC150_ACCEL_DEF_RANGE_16G} };
-
-static const struct {
int sleep_dur;
- int reg_value;
+ u8 reg_value;
} bmc150_accel_sleep_value_table[] = { {0, 0},
{500, BMC150_ACCEL_SLEEP_500_MICRO},
{1000, BMC150_ACCEL_SLEEP_1_MS},
@@ -267,7 +278,7 @@ static int bmc150_accel_chip_init(struct bmc150_accel_data
*data)
}
dev_dbg(>client->dev, "Chip Id %x\n", ret);
- if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
+ if (ret != data->chip_info->chip_id) {
dev_err(>client->dev, "Invalid chip %x\n", ret);
return -ENODEV;
}
@@ -541,19 +552,19 @@ static int
Re: [PATCH net-next 2/2] net: exit busy loop when another process is runnable
On Tue, Sep 02, 2014 at 09:15:18AM +0300, Eliezer Tamir wrote: > On 02/09/2014 06:29, Jason Wang wrote: > > On 09/01/2014 02:39 PM, Eliezer Tamir wrote: > >> On 29/08/2014 06:08, Jason Wang wrote: > Yes, but rx busy polling only works in process context and does not > disable bh, so it may be not an issue. > >> sk_busy_loop() uses rcu_read_lock_bh(), so it does run with bh disabled. > > > > True, so we need probably also exit the loop when there are pending bhs. > > I'm not so sure, in the typical busy poll scenario, the incoming > traffic is the most time-critical thing in the system. > It's so important that you are willing to trade lots of CPU power > for better latency. The user has decided that he wants to dedicate > this CPU mostly for that. This is not something that plays nice with > other apps, but this is what the user wants. I think most applications wouldn't interpret this flag as "burn up CPU I don't care what is the result", what apps want is more of "maximise throughput and minimise latency even if throughput/CPU ratio goes down". Jason posted benchmarks that show throughput going up because other processes get more of a chance to run, so this seems consistent with that goal. > So, you definitely don't want to starve any bh, and you should > regularly re-enable bh's, but you also don't want to stop everything > at any time a bh is scheduled. > > You also want network processing on the queues that are busy polled > to come through busy polling and not through NAPI, which is run in bh > context. > > -Eliezer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build regressions/improvements in v3.17-rc3
On Tue, Sep 2, 2014 at 11:21 AM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v3.17-rc3[1] to v3.17-rc2[3], the summaries are:
> - build errors: +10/-22
Only known randconfig and new R_PPC64_REL24 relocation truncations.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mmc:sdhci: handle busy-end interrupt during command
On 30 August 2014 05:40, Chanho Min wrote:
> It is fully legal for a controller to start handling busy-end interrupt
> before it has signaled that the command has completed. So make sure
> we do things in the proper order, Or it results that command interrupt
> is ignored so it can cause unexpected operations. This is founded at some
> toshiba emmc with the bellow warning.
>
> "mmc0: Got command interrupt 0x0001 even though
> no command operation was in progress."
>
> This issue has been also reported by Youssef TRIKI:
> It is not specific to Toshiba devices, and happens with eMMC devices
> as well as SD card which support Auto-CMD12 rather than CMD23.
>
> Also, similar patch is submitted by:
> Gwendal Grignou
>
> Changes since v1:
> Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git
> and Tested if issue is fixed again.
>
> Signed-off-by: Hankyung Yu
> Signed-off-by: Chanho Min
> Tested-by: Youssef TRIKI
Thanks! Applied for next.
Kind regards
Uffe
> ---
> drivers/mmc/host/sdhci.c | 17 +++--
> include/linux/mmc/sdhci.h |1 +
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
> index f6a683b..8428148 100644
> --- a/drivers/mmc/host/sdhci.c
> +++ b/drivers/mmc/host/sdhci.c
> @@ -1016,6 +1016,7 @@ void sdhci_send_command(struct sdhci_host *host, struct
> mmc_command *cmd)
> mod_timer(>timer, timeout);
>
> host->cmd = cmd;
> + host->busy_handle = 0;
>
> sdhci_prepare_data(host, cmd);
>
> @@ -2261,8 +2262,12 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32
> intmask)
> if (host->cmd->data)
> DBG("Cannot wait for busy signal when also "
> "doing a data transfer");
> - else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ))
> + else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ)
> + && !host->busy_handle) {
> + /* Mark that command complete before busy is ended */
> + host->busy_handle = 1;
> return;
> + }
>
> /* The controller does not support the end-of-busy IRQ,
> * fall through and take the SDHCI_INT_RESPONSE */
> @@ -2330,7 +2335,15 @@ static void sdhci_data_irq(struct sdhci_host *host,
> u32 intmask)
> return;
> }
> if (intmask & SDHCI_INT_DATA_END) {
> - sdhci_finish_command(host);
> + /*
> +* Some cards handle busy-end interrupt
> +* before the command completed, so make
> +* sure we do things in the proper order.
> +*/
> + if (host->busy_handle)
> + sdhci_finish_command(host);
> + else
> + host->busy_handle = 1;
> return;
> }
> }
> diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
> index 09ebe57..0aa85ca 100644
> --- a/include/linux/mmc/sdhci.h
> +++ b/include/linux/mmc/sdhci.h
> @@ -146,6 +146,7 @@ struct sdhci_host {
> struct mmc_command *cmd;/* Current command */
> struct mmc_data *data; /* Current data request */
> unsigned int data_early:1; /* Data finished before cmd */
> + unsigned int busy_handle:1; /* Handling the order of Busy-end */
>
> struct sg_mapping_iter sg_miter;/* SG state for PIO */
> unsigned int blocks;/* remaining PIO blocks */
> --
> 1.7.9.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] videobuf-dma-contig: replace vm_iomap_memory() with remap_pfn_range().
When user requests V4L2_MEMORY_MMAP type buffers, the videobuf-core
will assign the corresponding offset to the 'boff' field of the
videobuf_buffer for each requested buffer sequentially. Later, user
may call mmap() to map one or all of the buffers with the 'offset'
parameter which is equal to its 'boff' value. Obviously, the 'offset'
value is only used to find the matched buffer instead of to be the
real offset from the buffer's physical start address as used by
vm_iomap_memory(). So, in some case that if the offset is not zero,
vm_iomap_memory() will fail.
Signed-off-by: Fancy Fang
---
drivers/media/v4l2-core/videobuf-dma-contig.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/videobuf-dma-contig.c
index bf80f0f..8bd9889 100644
--- a/drivers/media/v4l2-core/videobuf-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf-dma-contig.c
@@ -305,7 +305,9 @@ static int __videobuf_mmap_mapper(struct videobuf_queue *q,
/* Try to remap memory */
size = vma->vm_end - vma->vm_start;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
- retval = vm_iomap_memory(vma, mem->dma_handle, size);
+ retval = remap_pfn_range(vma, vma->vm_start,
+mem->dma_handle >> PAGE_SHIFT,
+size, vma->vm_page_prot);
if (retval) {
dev_err(q->dev, "mmap: remap failed with error %d. ",
retval);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Build regressions/improvements in v3.17-rc3
Below is the list of build error/warning regressions/improvements in v3.17-rc3[1] compared to v3.16[2]. Summarized: - build errors: +17/-39 - build warnings: +131/-73 JFYI, when comparing v3.17-rc3[1] to v3.17-rc2[3], the summaries are: - build errors: +10/-22 - build warnings: +49/-48 As I haven't mastered kup yet, there's no verbose summary at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v3.17-rc3.summary.gz Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/7824/ (all 119 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/7732/ (all 119 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/7808/ (all 119 configs) *** ERRORS *** 17 regressions: + /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error: 'cached_to_uncached' undeclared (first use in this function): => 99:17 + /scratch/kisskb/src/arch/sh/mm/cache-sh4.c: error: implicit declaration of function 'cpu_context' [-Werror=implicit-function-declaration]: => 192:2 + /scratch/kisskb/src/drivers/edac/ppc4xx_edac.c: error: request for member 'dimm' in something not a structure or union: => 977:45 + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: 'AT_FDCWD' undeclared (first use in this function): => 378 + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: (Each undeclared identifier is reported only once: => 378 + /scratch/kisskb/src/fs/hostfs/hostfs_user.c: error: for each function it appears in.): => 378 + error: No rule to make target /etc/sound/trxpro.hex: => N/A + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.__dev_kfree_skb_irq' defined in .text section in net/built-in.o: => (.text+0x1ff9c68) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.add_timer' defined in .text section in kernel/built-in.o: => (.text+0x1ff9e68) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.alloc_etherdev_mqs' defined in .text section in net/built-in.o: => (.text+0x1ffa274) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.debug_dma_sync_single_for_device' defined in .text section in lib/built-in.o: => (.text+0x1ff950c) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.memcpy' defined in .text section in arch/powerpc/lib/built-in.o: => (.text+0x1ff9434) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.netif_rx' defined in .text section in net/built-in.o: => (.text+0x1ff9670) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.pci_iounmap' defined in .text section in lib/built-in.o: => (.text+0x1ffac10) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `.register_netdev' defined in .text section in net/built-in.o: => (.text+0x1ffa9bc) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_14' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ffac60) + error: fealnx.c: relocation truncated to fit: R_PPC64_REL24 against symbol `_restgpr0_30' defined in .text.save.restore section in arch/powerpc/lib/built-in.o: => (.text+0x1ff88b4) 30 improvements: - /scratch/kisskb/src/drivers/net/wireless/libertas/if_cs.c: error: implicit declaration of function 'ioport_map' [-Werror=implicit-function-declaration]: 878:2 => - /scratch/kisskb/src/drivers/net/wireless/libertas/if_cs.c: error: implicit declaration of function 'ioport_unmap' [-Werror=implicit-function-declaration]: 826:3 => - /scratch/kisskb/src/drivers/net/wireless/orinoco/orinoco_cs.c: error: implicit declaration of function 'ioport_map' [-Werror=implicit-function-declaration]: 153:2 => - /scratch/kisskb/src/drivers/net/wireless/orinoco/orinoco_cs.c: error: implicit declaration of function 'ioport_unmap' [-Werror=implicit-function-declaration]: 205:3 => - /scratch/kisskb/src/drivers/net/wireless/orinoco/spectrum_cs.c: error: implicit declaration of function 'ioport_map' [-Werror=implicit-function-declaration]: 216:2 => - /scratch/kisskb/src/drivers/net/wireless/orinoco/spectrum_cs.c: error: implicit declaration of function 'ioport_unmap' [-Werror=implicit-function-declaration]: 273:3 => - /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add' [-Werror=implicit-function-declaration]: 176:2 => - /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add_negative' [-Werror=implicit-function-declaration]: 211:2 => - /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_add_return' [-Werror=implicit-function-declaration]: 218:2 => - /scratch/kisskb/src/include/asm-generic/atomic-long.h: error: implicit declaration of function 'atomic_dec'
Re: [PATCH 01/12] Staging: rtl8821ae: hal_bt_coexist: fix commenting style
Hm... Now you've broken it into *too* many separate patches. Also the subjects are the same. Also the subjects are too vague. Which coding style issue is addressed? It should be something like: patch 1: comments patch 2: add/remove spaces patch 3: fix quoted text patch 4: braces patch 5: add a blank line regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [alsa-devel] [PATCHv1 1/7] ASoC: simple-card: Merge single and muti DAI link code.
Hi Kuninori-san
This patch series will break the old DTs, and I will follow Mark's
Advice to maintain compatibility with the old DTs.
I will send another version, please help me to review it. And I will also
split the update patch series to many small ones.
Thanks very much,
BRs
Xiubo
> -Original Message-
> From: Kuninori Morimoto [mailto:kuninori.morimoto...@gmail.com]
> Sent: Monday, September 01, 2014 3:43 PM
> To: Xiubo Li-B47053
> Cc: broo...@kernel.org; lgirdw...@gmail.com; pe...@perex.cz; ti...@suse.de;
> kuninori.morimoto...@renesas.com; moin...@free.fr; and...@lunn.ch;
> jsa...@ti.com; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux...@vger.kernel.org; alsa-devel@alsa-
> project.org; Guo Shawn-R65073; Nicolin Chen; linux-kernel@vger.kernel.org
> Subject: Re: [alsa-devel] [PATCHv1 1/7] ASoC: simple-card: Merge single and
> muti DAI link code.
>
>
> Hi Xiubo
>
> Thank you for your patch.
> This clean-up is very nice for me.
> But, I have 1 small comment
>
> > asoc_simple_card_sub_parse_of(struct device_node *np,
> > struct asoc_simple_dai *dai,
> > struct device_node **p_node,
> > - const char **name)
> > + const char **name,
> > + unsigned int *daifmt)
> > {
> > struct device_node *node;
> > struct clk *clk;
> > u32 val;
> > int ret;
> >
> > + if (!daifmt)
> > + return -EINVAL;
> > +
> > + /*
> > +* Parse format, bitclock-inversion and frame-inversion
> > +* for DAI each device.
> > +*/
> > + *daifmt = snd_soc_of_parse_daifmt(np, NULL, NULL, NULL);
> > + *daifmt &= ~(SND_SOC_DAIFMT_MASTER_MASK | SND_SOC_DAIFMT_FORMAT_MASK);
> (snip)
> > ret = asoc_simple_card_sub_parse_of(np, _props->cpu_dai,
> > _link->cpu_of_node,
> > - _link->cpu_dai_name);
> > + _link->cpu_dai_name,
> > + );
> (snip)
> > + dai_props->cpu_dai.fmt |= daifmt;
> (snip)
> > ret = asoc_simple_card_sub_parse_of(np, _props->codec_dai,
> > _link->codec_of_node,
> > - _link->codec_dai_name);
> > + _link->codec_dai_name,
> > + );
> (snip)
> > + dai_props->codec_dai.fmt |= daifmt;
>
> These are using
>
> asoc_simple_card_sub_parse_of(np, _props->cpu_dai, xxx)
> asoc_simple_card_sub_parse_of(np, _props->codec_dai, xxx)
>
> I guess, asoc_simple_card_sub_parse_of() can update
> below inside function
>
> dai_props->cpu_dai.fmt |= daifmt;
> dai_props->codec_dai.fmt |= daifmt;
>
>
> Best regards
> ---
> Kuninori Morimoto
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/6] arm64: ptrace: allow tracer to skip a system call
On Tue, Sep 02, 2014 at 05:47:29PM +0900, AKASHI Takahiro wrote: > On 09/01/2014 08:47 PM, Russell King - ARM Linux wrote: >> On Wed, Aug 27, 2014 at 02:55:46PM +0900, AKASHI Takahiro wrote: >>> 1) >>> setting x0 to -ENOSYS is necessary because, otherwise, user-issued >>> syscall(-1) will >>> return a bogus value when audit tracing is on. >>> >>> Please note that, on arm, >>> not traced traced >>> -- -- >>> syscall(-1) aborted OOPs(BUG_ON) >>> syscall(-3000) aborted aborted >>> syscall(1000)ENOSYS ENOSYS >> >> Two points here: >> >> 1. You've found a case which causes a BUG_ON(). Where is the bug report >> for this, so the problem can be investigated and resolved? > > I think that I mentioned it could also happen on arm somewhere in a talk > with Will, but don't remember exactly when. Sorry, not good enough. Please report this bug so it can be investigated and fixed. >> 2. What do you mean by "aborted" ? > > I mean that the process will receive SIGILL and get aborted. > A system call number, like -1 and -3000, won't be trapped by *switch* > statement in asm_syscall() and end up with being signaled. That is correct behaviour - because numbers greater than 0xf (or 0x9f for OABI - the 0x90 offset on the syscalls on OABI is to distinguish them from syscalls used by RISC OS) are not intended to be Linux syscalls per-se. >> Please, if you find a problem with 32-bit ARM, report it. Don't hide it, >> because hiding it can be a security issue or in the case of BUG_ON(), it >> could be a denial of service issue. >> >> As you're part of Linaro, I would have thought you'd be more responsible >> in this regard - after all, Linaro is supposed to be about improving the >> ARM kernel... Maybe I got that wrong, and Linaro is actually about >> ensuring that the ARM kernel is stuffed full of broken features? > > I thought my first priority was on arm64 (and then arm), but now that > you and Will seem to want to see the fix first on arm, okey, I will > start with arm issue. So what you're saying there is that if you find a bug in ARM code, which everyone is currently using, you can ignore it until you've sorted out ARM64 which almost no one is using. This is absurd, and whoever has set your priorities is clearly on drugs. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] gpu: ipu-v3: Select GENERIC_IRQ_CHIP to fix build error
Hi, Am Montag, den 01.09.2014, 20:28 -0700 schrieb Greg Kroah-Hartman: [...] > > I checked the MAINTAINERS file, > > I can only find the maintainer for some subfolders of drivers/gpu but no > > entry > > for drivers/gpu/ipu-v3. > > So I'm not sure who is the maintainer for drivers/gpu/ipu-v3. > > Who moved the file out of staging? I don't think it was me... > > I think it is Philipp, who sent the patches through the drm tree, so try > those developers. I'll collect gpu/ipu-v3 patches and send them on. I've pushed this patch to: git://git.pengutronix.de/git/pza/linux.git topic/ipu-fixes regards Philipp -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] perf tools: parse the pmu event prefix and surfix
On Mon, Sep 01, 2014 at 12:29:46PM -0400, kan.li...@intel.com wrote: > From: Kan Liang > > There are two types of event formats for PMU events. E.g. el-abort OR > cpu/el-abort/. However, the lexer mistakenly recognizes the simple style > format as two events. > > The parse_events_pmu_check function uses bsearch to search the name in > known pmu event list. It can tell the lexer that the name is a PE_NAME > or a PMU event name prefix or a PMU event name suffix. All these > information will be used for accurately parsing kernel PMU events. > > The pmu events list will be read from sysfs at runtime. this one does not apply to latest acme's perf/core could you please rebase your patchset to: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux perf/core thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
